02 Sep, 2020

1 commit


08 Aug, 2020

1 commit

  • Add a drgn-based tool to display slab information for a given memcg. Can
    replace cgroup v1 memory.kmem.slabinfo interface on cgroup v2, but in a
    more flexiable way.

    Currently supports only SLUB configuration, but SLAB can be trivially
    added later.

    Output example:
    $ sudo ./tools/cgroup/memcg_slabinfo.py /sys/fs/cgroup/user.slice/user-111017.slice/user\@111017.service
    shmem_inode_cache 92 92 704 46 8 : tunables 0 0 0 : slabdata 2 2 0
    eventpoll_pwq 56 56 72 56 1 : tunables 0 0 0 : slabdata 1 1 0
    eventpoll_epi 32 32 128 32 1 : tunables 0 0 0 : slabdata 1 1 0
    kmalloc-8 0 0 8 512 1 : tunables 0 0 0 : slabdata 0 0 0
    kmalloc-96 0 0 96 42 1 : tunables 0 0 0 : slabdata 0 0 0
    kmalloc-2048 0 0 2048 16 8 : tunables 0 0 0 : slabdata 0 0 0
    kmalloc-64 128 128 64 64 1 : tunables 0 0 0 : slabdata 2 2 0
    mm_struct 160 160 1024 32 8 : tunables 0 0 0 : slabdata 5 5 0
    signal_cache 96 96 1024 32 8 : tunables 0 0 0 : slabdata 3 3 0
    sighand_cache 45 45 2112 15 8 : tunables 0 0 0 : slabdata 3 3 0
    files_cache 138 138 704 46 8 : tunables 0 0 0 : slabdata 3 3 0
    task_delay_info 153 153 80 51 1 : tunables 0 0 0 : slabdata 3 3 0
    task_struct 27 27 3520 9 8 : tunables 0 0 0 : slabdata 3 3 0
    radix_tree_node 56 56 584 28 4 : tunables 0 0 0 : slabdata 2 2 0
    btrfs_inode 140 140 1136 28 8 : tunables 0 0 0 : slabdata 5 5 0
    kmalloc-1024 64 64 1024 32 8 : tunables 0 0 0 : slabdata 2 2 0
    kmalloc-192 84 84 192 42 2 : tunables 0 0 0 : slabdata 2 2 0
    inode_cache 54 54 600 27 4 : tunables 0 0 0 : slabdata 2 2 0
    kmalloc-128 0 0 128 32 1 : tunables 0 0 0 : slabdata 0 0 0
    kmalloc-512 32 32 512 32 4 : tunables 0 0 0 : slabdata 1 1 0
    skbuff_head_cache 32 32 256 32 2 : tunables 0 0 0 : slabdata 1 1 0
    sock_inode_cache 46 46 704 46 8 : tunables 0 0 0 : slabdata 1 1 0
    cred_jar 378 378 192 42 2 : tunables 0 0 0 : slabdata 9 9 0
    proc_inode_cache 96 96 672 24 4 : tunables 0 0 0 : slabdata 4 4 0
    dentry 336 336 192 42 2 : tunables 0 0 0 : slabdata 8 8 0
    filp 697 864 256 32 2 : tunables 0 0 0 : slabdata 27 27 0
    anon_vma 644 644 88 46 1 : tunables 0 0 0 : slabdata 14 14 0
    pid 1408 1408 64 64 1 : tunables 0 0 0 : slabdata 22 22 0
    vm_area_struct 1200 1200 200 40 2 : tunables 0 0 0 : slabdata 30 30 0

    Signed-off-by: Roman Gushchin
    Signed-off-by: Andrew Morton
    Acked-by: Tejun Heo
    Cc: Christoph Lameter
    Cc: Johannes Weiner
    Cc: Michal Hocko
    Cc: Shakeel Butt
    Cc: Vlastimil Babka
    Link: http://lkml.kernel.org/r/20200623174037.3951353-20-guro@fb.com
    Signed-off-by: Linus Torvalds

    Roman Gushchin
     

31 Jul, 2020

1 commit


10 May, 2020

1 commit

  • Pull in block-5.7 fixes for 5.8. Mostly to resolve a conflict with
    the blk-iocost changes, but we also need the base of the bdi
    use-after-free as well as we build on top of it.

    * block-5.7:
    nvme: fix possible hang when ns scanning fails during error recovery
    nvme-pci: fix "slimmer CQ head update"
    bdi: add a ->dev_name field to struct backing_dev_info
    bdi: use bdi_dev_name() to get device name
    bdi: move bdi_dev_name out of line
    vboxsf: don't use the source name in the bdi name
    iocost: protect iocg->abs_vdebt with iocg->waitq.lock
    block: remove the bd_openers checks in blk_drop_partitions
    nvme: prevent double free in nvme_alloc_ns() error handling
    null_blk: Cleanup zoned device initialization
    null_blk: Fix zoned command handling
    block: remove unused header
    blk-iocost: Fix error on iocost_ioc_vrate_adj
    bdev: Reduce time holding bd_mutex in sync in blkdev_close()
    buffer: remove useless comment and WB_REASON_FREE_MORE_MEM, reason.

    Signed-off-by: Jens Axboe

    Jens Axboe
     

05 May, 2020

1 commit

  • abs_vdebt is an atomic_64 which tracks how much over budget a given cgroup
    is and controls the activation of use_delay mechanism. Once a cgroup goes
    over budget from forced IOs, it has to pay it back with its future budget.
    The progress guarantee on debt paying comes from the iocg being active -
    active iocgs are processed by the periodic timer, which ensures that as time
    passes the debts dissipate and the iocg returns to normal operation.

    However, both iocg activation and vdebt handling are asynchronous and a
    sequence like the following may happen.

    1. The iocg is in the process of being deactivated by the periodic timer.

    2. A bio enters ioc_rqos_throttle(), calls iocg_activate() which returns
    without anything because it still sees that the iocg is already active.

    3. The iocg is deactivated.

    4. The bio from #2 is over budget but needs to be forced. It increases
    abs_vdebt and goes over the threshold and enables use_delay.

    5. IO control is enabled for the iocg's subtree and now IOs are attributed
    to the descendant cgroups and the iocg itself no longer issues IOs.

    This leaves the iocg with stuck abs_vdebt - it has debt but inactive and no
    further IOs which can activate it. This can end up unduly punishing all the
    descendants cgroups.

    The usual throttling path has the same issue - the iocg must be active while
    throttled to ensure that future event will wake it up - and solves the
    problem by synchronizing the throttling path with a spinlock. abs_vdebt
    handling is another form of overage handling and shares a lot of
    characteristics including the fact that it isn't in the hottest path.

    This patch fixes the above and other possible races by strictly
    synchronizing abs_vdebt and use_delay handling with iocg->waitq.lock.

    Signed-off-by: Tejun Heo
    Reported-by: Vlad Dmitriev
    Cc: stable@vger.kernel.org # v5.4+
    Fixes: e1518f63f246 ("blk-iocost: Don't let merges push vtime into the future")
    Signed-off-by: Jens Axboe

    Tejun Heo
     

01 May, 2020

2 commits


25 Mar, 2020

1 commit


18 Jan, 2020

1 commit


11 Sep, 2019

3 commits


29 Aug, 2019

2 commits


22 Feb, 2018

1 commit

  • Currently a number of Makefiles break when used with toolchains that
    pass extra flags in CC and other cross-compile related variables (such
    as --sysroot).

    Thus we get this error when we use a toolchain that puts --sysroot in
    the CC var:

    ~/src/linux/tools$ make iio
    [snip]
    iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory
    #include
    ^~~~~~~~~~

    This occurs because we clobber several env vars related to
    cross-compiling with lines like this:

    CC = $(CROSS_COMPILE)gcc

    Although this will point to a valid cross-compiler, we lose any extra
    flags that might exist in the CC variable, which can break toolchains
    that rely on them (for example, those that use --sysroot).

    This easily shows up using a Yocto SDK:

    $ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi

    $ echo $CC
    arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
    -mcpu=cortex-a8
    --sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi

    $ echo $CROSS_COMPILE
    arm-poky-linux-gnueabi-

    $ echo ${CROSS_COMPILE}gcc
    krm-poky-linux-gnueabi-gcc

    Although arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the
    --sysroot and other flags that enable us to find the right libraries to
    link against, so we can't find unistd.h and other libraries and headers.
    Normally with the --sysroot flag we would find unistd.h in the sdk
    directory in the sysroot:

    $ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h'
    [snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.h

    The perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not
    already set, and it compiles correctly with the above toolchain.

    So, generalize the logic that perf uses in the common Makefile and
    remove the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile.

    Note that this patch does not fix cross-compile for all the tools (some
    have other bugs), but it does fix it for all except usb and acpi, which
    still have other unrelated issues.

    I tested both with and without the patch on native and cross-build and
    there appear to be no regressions.

    Link: http://lkml.kernel.org/r/20180107214028.23771-1-martin@martingkelly.com
    Signed-off-by: Martin Kelly
    Acked-by: Mark Brown
    Cc: Tejun Heo
    Cc: Li Zefan
    Cc: Johannes Weiner
    Cc: Linus Walleij
    Cc: "K. Y. Srinivasan"
    Cc: Haiyang Zhang
    Cc: Stephen Hemminger
    Cc: Jonathan Cameron
    Cc: Pali Rohar
    Cc: Richard Purdie
    Cc: Jacek Anaszewski
    Cc: Pavel Machek
    Cc: Peter Zijlstra
    Cc: Ingo Molnar
    Cc: Arnaldo Carvalho de Melo
    Cc: Robert Moore
    Cc: Lv Zheng
    Cc: "Rafael J. Wysocki"
    Cc: Greg Kroah-Hartman
    Cc: Valentina Manea
    Cc: Shuah Khan
    Cc: Mario Limonciello
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Martin Kelly
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

09 Jan, 2013

1 commit

  • The error handling in cgroup_event_listener.c did not correctly deal
    with either an error opening either or
    cgroup.event_control. Due to an uninitialized variable the program
    exit code was undefined if either of these opens failed.

    This patch simplifies and corrects cgroup_event_listener.c error
    handling by:
    1. using err*() rather than printf(),exit()
    2. depending on process exit to close open files

    With this patch failures always return non-zero error.

    Signed-off-by: Greg Thelen
    Acked-by: Li Zefan
    Signed-off-by: Tejun Heo

    Greg Thelen
     

08 Jan, 2013

1 commit