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
     

26 Aug, 2017

2 commits

  • kernel/irq/proc.c: In function ‘show_irq_affinity’:
    include/linux/cpumask.h:24:29: warning: ‘mask’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    #define cpumask_bits(maskp) ((maskp)->bits)

    gcc is silly, but admittedly it can't know that this won't be called with
    anything else than the enumerated constants.

    Shut up the warning by creating a default clause.

    Fixes: 6bc6d4abd22e ("genirq/proc: Use the the accessor to report the effective affinity
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • kernel/irq/proc.c:69:2-3: Unneeded semicolon

    Remove unneeded semicolon.

    Generated by: scripts/coccinelle/misc/semicolon.cocci

    Fixes: 0d3f54257dc3 ("genirq: Introduce effective affinity mask")
    Signed-off-by: Fengguang Wu
    Signed-off-by: Thomas Gleixner
    Cc: kbuild-all@01.org
    Link: http://lkml.kernel.org/r/20170822075053.GA93890@lkp-hsx02

    kbuild test robot
     

18 Aug, 2017

1 commit

  • If CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK is defined, but that the
    interrupt is not single target, the effective affinity reported in
    /proc/irq/x/effective_affinity will be empty, which is not the truth.

    Instead, use the accessor to report the affinity, which will pick
    the right mask.

    Signed-off-by: Marc Zyngier
    Signed-off-by: Thomas Gleixner
    Cc: Andrew Lunn
    Cc: James Hogan
    Cc: Jason Cooper
    Cc: Paul Burton
    Cc: Chris Zankel
    Cc: Kevin Cernekee
    Cc: Wei Xu
    Cc: Max Filippov
    Cc: Florian Fainelli
    Cc: Gregory Clement
    Cc: Matt Redfearn
    Cc: Sebastian Hesselbarth
    Link: http://lkml.kernel.org/r/20170818083925.10108-3-marc.zyngier@arm.com

    Marc Zyngier
     

23 Jun, 2017

4 commits

  • There is currently no way to evaluate the effective affinity mask of a
    given interrupt. Many irq chips allow only a single target CPU or a subset
    of CPUs in the affinity mask.

    Updating the mask at the time of setting the affinity to the subset would
    be counterproductive because information for cpu hotplug about assigned
    interrupt affinities gets lost. On CPU hotplug it's also pointless to force
    migrate an interrupt, which is not targeted at the CPU effectively. But
    currently the information is not available.

    Provide a seperate mask to be updated by the irq_chip->irq_set_affinity()
    implementations. Implement the read only proc files so the user can see the
    effective mask as well w/o trying to deduce it from /proc/interrupts.

    Signed-off-by: Thomas Gleixner
    Cc: Jens Axboe
    Cc: Marc Zyngier
    Cc: Michael Ellerman
    Cc: Keith Busch
    Cc: Peter Zijlstra
    Cc: Christoph Hellwig
    Link: http://lkml.kernel.org/r/20170619235446.247834245@linutronix.de

    Thomas Gleixner
     
  • The proc file setup repeats the same ugly type cast for the irq number over
    and over. Do it once and hand in the local void pointer.

    Signed-off-by: Thomas Gleixner
    Cc: Jens Axboe
    Cc: Marc Zyngier
    Cc: Michael Ellerman
    Cc: Keith Busch
    Cc: Peter Zijlstra
    Cc: Christoph Hellwig
    Link: http://lkml.kernel.org/r/20170619235446.160866358@linutronix.de

    Thomas Gleixner
     
  • The third argument of the internal helper function is unused. Remove it.

    Signed-off-by: Thomas Gleixner
    Cc: Jens Axboe
    Cc: Marc Zyngier
    Cc: Michael Ellerman
    Cc: Keith Busch
    Cc: Peter Zijlstra
    Cc: Christoph Hellwig
    Link: http://lkml.kernel.org/r/20170619235446.004958600@linutronix.de

    Thomas Gleixner
     
  • No point to have this alloc/free dance of cpumasks. Provide a static mask
    for setup_affinity() and protect it proper.

    Signed-off-by: Thomas Gleixner
    Cc: Jens Axboe
    Cc: Marc Zyngier
    Cc: Michael Ellerman
    Cc: Keith Busch
    Cc: Peter Zijlstra
    Cc: Christoph Hellwig
    Link: http://lkml.kernel.org/r/20170619235444.851571573@linutronix.de

    Thomas Gleixner
     

11 Feb, 2017

1 commit


04 Jul, 2016

2 commits

  • Pull the irq affinity managing code which is in a seperate branch for block
    developers to pull.

    Thomas Gleixner
     
  • Interupts marked with this flag are excluded from user space interrupt
    affinity changes. Contrary to the IRQ_NO_BALANCING flag, the kernel internal
    affinity mechanism is not blocked.

    This flag will be used for multi-queue device interrupts.

    Signed-off-by: Thomas Gleixner
    Cc: Christoph Hellwig
    Cc: linux-block@vger.kernel.org
    Cc: linux-pci@vger.kernel.org
    Cc: linux-nvme@lists.infradead.org
    Cc: axboe@fb.com
    Cc: agordeev@redhat.com
    Link: http://lkml.kernel.org/r/1467621574-8277-3-git-send-email-hch@lst.de
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

10 Jun, 2016

2 commits

  • sprintf() and snprintf() implementation of kernel guarantees that
    its result is terminated with null byte if size is larger than 0. So we
    don't need to call memset() at all.

    Signed-off-by: Weongyo Jeong
    Link: http://lkml.kernel.org/r/1459451703-5744-1-git-send-email-weongyo.linux@gmail.com
    Signed-off-by: Thomas Gleixner

    Weongyo Jeong
     
  • for_each_irq_desc() macro has already skipped NULL irq_desc, don't
    bother to check it again.

    Signed-off-by: Jianyu Zhan
    Cc: mingo@kernel.org
    Cc: yhlu.kernel@gmail.com
    Link: http://lkml.kernel.org/r/1458395959-7046-1-git-send-email-nasa4836@gmail.com
    Signed-off-by: Thomas Gleixner

    Jianyu Zhan
     

15 Feb, 2016

1 commit

  • The irq code browses the list of actions differently to inspect the element
    one by one. Even if it is not a problem, for the sake of consistent code,
    provide a macro similar to for_each_irq_desc in order to have the same loop to
    go through the actions list and use it in the code.

    [ tglx: Renamed the macro ]

    Signed-off-by: Daniel Lezcano
    Link: http://lkml.kernel.org/r/1452765253-31148-1-git-send-email-daniel.lezcano@linaro.org
    Signed-off-by: Thomas Gleixner

    Daniel Lezcano
     

10 Nov, 2015

1 commit

  • Commit e509bd7da149 ("genirq: Allow migration of chained interrupts
    by installing default action") breaks PCS wake up IRQ behaviour on
    TI OMAP based platforms (dra7-evm).

    TI OMAP IRQ wake up configuration:
    GIC-irqchip->PCM_IRQ
    |- omap_prcm_register_chain_handler
    |- PRCM-irqchip -> PRCM_IO_IRQ
    |- pcs_irq_chain_handler
    |- pinctrl-irqchip -> PCS_uart1_wakeup_irq

    This happens because IRQ PM code (irq/pm.c) is expected to ignore
    chained interrupts by default:
    static bool suspend_device_irq(struct irq_desc *desc)
    {
    if (!desc->action || desc->no_suspend_depth)
    return false;
    - it's expected !desc->action = true for chained interrupts;

    but, after above change, all chained interrupt descriptors will
    have default action handler installed - chained_action.
    As result, chained interrupts will be silently disabled during system
    suspend.

    Hence, fix it by introducing helper function irq_desc_is_chained() and
    use it in suspend_device_irq() for chained interrupts identification
    and skip them, once detected.

    Fixes: e509bd7da149 ("genirq: Allow migration of chained interrupts..")
    Signed-off-by: Grygorii Strashko
    Reviewed-by: Mika Westerberg
    Cc: Tony Lindgren
    Cc:
    Cc:
    Cc: Tony Lindgren
    Link: http://lkml.kernel.org/r/1447149492-20699-1-git-send-email-grygorii.strashko@ti.com
    Signed-off-by: Thomas Gleixner

    Grygorii Strashko
     

14 Oct, 2015

1 commit


10 Oct, 2015

1 commit

  • When a CPU is offlined all interrupts that have an action are migrated to
    other still online CPUs. However, if the interrupt has chained handler
    installed this is not done. Chained handlers are used by GPIO drivers which
    support interrupts, for instance.

    When the affinity is not corrected properly we end up in situation where
    most interrupts are not arriving to the online CPUs anymore. For example on
    Intel Braswell system which has SD-card card detection signal connected to
    a GPIO the IO-APIC routing entries look like below after CPU1 is offlined:

    pin30, enabled , level, low , V(52), IRR(0), S(0), logical , D(03), M(1)
    pin31, enabled , level, low , V(42), IRR(0), S(0), logical , D(03), M(1)
    pin32, enabled , level, low , V(62), IRR(0), S(0), logical , D(03), M(1)
    pin5b, enabled , level, low , V(72), IRR(0), S(0), logical , D(03), M(1)

    The problem here is that the destination mask still contains both CPUs even
    if CPU1 is already offline. This means that the IO-APIC still routes
    interrupts to the other CPU as well.

    We solve the problem by providing a default action for chained interrupts.
    This action allows the migration code to correct affinity (as it finds
    desc->action != NULL).

    Also make the default action handler to emit a warning if for some reason a
    chained handler ends up calling it.

    Signed-off-by: Mika Westerberg
    Cc: Jiang Liu
    Link: http://lkml.kernel.org/r/1444039935-30475-1-git-send-email-mika.westerberg@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Mika Westerberg
     

01 Oct, 2015

1 commit

  • Per-IRQ directories in procfs are created only when a handler is first
    added to the irqdesc, not when the irqdesc is created. In the case of
    a shared IRQ, multiple tasks can race to create a directory. This
    race condition seems to have been present forever, but is easier to
    hit with async probing.

    Signed-off-by: Ben Hutchings
    Link: http://lkml.kernel.org/r/1443266636.2004.2.camel@decadent.org.uk
    Signed-off-by: Thomas Gleixner
    Cc: stable@vger.kernel.org

    Ben Hutchings
     

16 Sep, 2015

1 commit

  • Irq affinity mask is per-irq instead of per irqchip, so move it into
    struct irq_common_data.

    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Bjorn Helgaas
    Cc: Benjamin Herrenschmidt
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Borislav Petkov
    Cc: Jason Cooper
    Cc: Kevin Cernekee
    Cc: Arnd Bergmann
    Link: http://lkml.kernel.org/r/1433303281-27688-1-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

12 Jun, 2015

1 commit

  • Introduce helper function irq_data_get_node() and variants thereof to
    hide struct irq_data implementation details.

    Convert the core code to use them.

    Signed-off-by: Jiang Liu
    Cc: Konrad Rzeszutek Wilk
    Cc: Tony Luck
    Cc: Bjorn Helgaas
    Cc: Benjamin Herrenschmidt
    Cc: Randy Dunlap
    Cc: Yinghai Lu
    Cc: Borislav Petkov
    Cc: Jason Cooper
    Cc: Kevin Cernekee
    Cc: Arnd Bergmann
    Link: http://lkml.kernel.org/r/1433145945-789-5-git-send-email-jiang.liu@linux.intel.com
    Signed-off-by: Thomas Gleixner

    Jiang Liu
     

14 Feb, 2015

1 commit

  • printk and friends can now format bitmaps using '%*pb[l]'. cpumask
    and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
    respectively which can be used to generate the two printf arguments
    necessary to format the specified cpu/nodemask.

    Signed-off-by: Tejun Heo
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tejun Heo
     

13 Dec, 2014

1 commit

  • Since the rework of the sparse interrupt code to actually free the
    unused interrupt descriptors there exists a race between the /proc
    interfaces to the irq subsystem and the code which frees the interrupt
    descriptor.

    CPU0 CPU1
    show_interrupts()
    desc = irq_to_desc(X);
    free_desc(desc)
    remove_from_radix_tree();
    kfree(desc);
    raw_spinlock_irq(&desc->lock);

    /proc/interrupts is the only interface which can actively corrupt
    kernel memory via the lock access. /proc/stat can only read from freed
    memory. Extremly hard to trigger, but possible.

    The interfaces in /proc/irq/N/ are not affected by this because the
    removal of the proc file is serialized in procfs against concurrent
    readers/writers. The removal happens before the descriptor is freed.

    For architectures which have CONFIG_SPARSE_IRQ=n this is a non issue
    as the descriptor is never freed. It's merely cleared out with the irq
    descriptor lock held. So any concurrent proc access will either see
    the old correct value or the cleared out ones.

    Protect the lookup and access to the irq descriptor in
    show_interrupts() with the sparse_irq_lock.

    Provide kstat_irqs_usr() which is protecting the lookup and access
    with sparse_irq_lock and switch /proc/stat to use it.

    Document the existing kstat_irqs interfaces so it's clear that the
    caller needs to take care about protection. The users of these
    interfaces are either not affected due to SPARSE_IRQ=n or already
    protected against removal.

    Fixes: 1f5a5b87f78f "genirq: Implement a sane sparse_irq allocator"
    Signed-off-by: Thomas Gleixner
    Cc: stable@vger.kernel.org

    Thomas Gleixner
     

19 Mar, 2014

1 commit

  • Includes:
    - /proc/irq/default_smp_affinity
    - /proc/irq/*/affinity_hint
    - /proc/irq/*/smp_affinity
    - /proc/irq/*/smp_affinity_list

    Users can distill the same information by reading /proc/interrupts.

    Signed-off-by: Chema Gonzalez
    Cc: Eric Dumazet
    Link: http://lkml.kernel.org/r/1394765455-1217-1-git-send-email-chema@google.com
    Signed-off-by: Thomas Gleixner

    Chema Gonzalez
     

24 Jun, 2013

1 commit

  • Add the hardware interrupt number to the output of /proc/interrupts.
    It is often important to have access to the hardware interrupt number because
    it identifies exactly how an interrupt signal is wired up to the interrupt
    controller. This is especially important when using irq_domains since irq
    numbers get dynamically allocated in that case, and have no relation to the
    actual hardware number.

    Note: This output is currently conditional on whether or not the irq_domain
    pointer is set; however hwirq could still be used without irq_domain. It
    may be worthwhile to always output the hwirq number regardless of the
    domain pointer.

    Signed-off-by: Grant Likely
    Tested-by: Olof Johansson
    Cc: Ben Herrenschmidt
    Cc: Thomas Gleixner

    Grant Likely
     

02 May, 2013

1 commit

  • Supply a function (proc_remove()) to remove a proc entry (and any subtree
    rooted there) by proc_dir_entry pointer rather than by name and (optionally)
    root dir entry pointer. This allows us to eliminate all remaining pde->name
    accesses outside of procfs.

    Signed-off-by: David Howells
    Acked-by: Grant Likely
    cc: linux-acpi@vger.kernel.org
    cc: openipmi-developer@lists.sourceforge.net
    cc: devicetree-discuss@lists.ozlabs.org
    cc: linux-pci@vger.kernel.org
    cc: netdev@vger.kernel.org
    cc: netfilter-devel@vger.kernel.org
    cc: alsa-devel@alsa-project.org
    Signed-off-by: Al Viro

    David Howells
     

10 Apr, 2013

1 commit

  • The only part of proc_dir_entry the code outside of fs/proc
    really cares about is PDE(inode)->data. Provide a helper
    for that; static inline for now, eventually will be moved
    to fs/proc, along with the knowledge of struct proc_dir_entry
    layout.

    Signed-off-by: Al Viro

    Al Viro
     

23 Feb, 2013

1 commit


26 May, 2011

1 commit

  • commit 4b06042(bitmap, irq: add smp_affinity_list interface to
    /proc/irq) causes the following warning:

    [ 274.239500] WARNING: at fs/proc/generic.c:850 remove_proc_entry+0x24c/0x27a()
    [ 274.251761] remove_proc_entry: removing non-empty directory 'irq/184',
    leaking at least 'smp_affinity_list'

    Remove the new file in the exit path.

    Signed-off-by: Yinghai Lu
    Cc: Mike Travis
    Link: http://lkml.kernel.org/r/4DDDE094.6050505@kernel.org
    Signed-off-by: Thomas Gleixner

    Yinghai Lu
     

25 May, 2011

1 commit

  • Manually adjusting the smp_affinity for IRQ's becomes unwieldy when the
    cpu count is large.

    Setting smp affinity to cpus 256 to 263 would be:

    echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity

    instead of:

    echo 256-263 > smp_affinity_list

    Think about what it looks like for cpus around say, 4088 to 4095.

    We already have many alternate "list" interfaces:

    /sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
    /sys/devices/system/cpu/cpuX/topology/thread_siblings_list
    /sys/devices/system/cpu/cpuX/topology/core_siblings_list
    /sys/devices/system/node/nodeX/cpulist
    /sys/devices/pci***/***/local_cpulist

    Add a companion interface, smp_affinity_list to use cpu lists instead of
    cpu maps. This conforms to other companion interfaces where both a map
    and a list interface exists.

    This required adding a bitmap_parselist_user() function in a manner
    similar to the bitmap_parse_user() function.

    [akpm@linux-foundation.org: make __bitmap_parselist() static]
    Signed-off-by: Mike Travis
    Cc: Thomas Gleixner
    Cc: Jack Steiner
    Cc: Lee Schermerhorn
    Cc: Andy Shevchenko
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Travis
     

03 May, 2011

1 commit

  • commit ab7798ffcf98b11a9525cf65bacdae3fd58d357f ("genirq: Expand generic
    show_interrupts()") added the Kconfig option GENERIC_IRQ_SHOW_LEVEL to
    accomodate PowerPC, but this doesn't actually enable the functionality due
    to a typo in the #ifdef check.

    Signed-off-by: Geert Uytterhoeven
    Cc: Linux/PPC Development
    Link: http://lkml.kernel.org/r/%3Calpine.DEB.2.00.1104302251370.19068%40ayla.of.borg%3E
    Signed-off-by: Thomas Gleixner

    Geert Uytterhoeven
     

29 Mar, 2011

1 commit

  • The only subtle difference is that alpha uses ACTUAL_NR_IRQS and
    prints the IRQF_DISABLED flag.

    Change the generic implementation to deal with ACTUAL_NR_IRQS if
    defined.

    The IRQF_DISABLED printing is pointless, as we nowadays run all
    interrupts with irqs disabled.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

26 Mar, 2011

1 commit

  • Some archs want to print extra information for certain irq_chips which
    is per irq and not per chip. Allow them to provide a chip callback to
    print the chip name and the extra information.

    PowerPC wants to print the LEVEL/EDGE type information. Make it configurable.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

17 Mar, 2011

1 commit


19 Feb, 2011

4 commits

  • Add a !desc check while at it.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • chip implementations need to know about it. Keep status in sync until
    all users are fixed.

    Accessor function: irqd_is_setaffinity_pending(irqdata)

    Coders who access them directly will be tracked down and slapped with
    stinking trouts.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • All archs implement show_interrupts() in more or less the same
    way. That's tons of duplicated code with different bugs with no
    value. Implement a generic version and deprecate show_interrupts()

    Unfortunately we need some ifdeffery for !GENERIC_HARDIRQ archs.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • While rumaging through arch code I found that there are a few
    workarounds which deal with the fact that the initial affinity setting
    from request_irq() copies the mask into irq_data->affinity before the
    chip code is called. In the normal path we unconditionally copy the
    mask when the chip code returns 0.

    Copy after the code is called and add a return code
    IRQ_SET_MASK_OK_NOCOPY for the chip functions, which prevents the
    copy. That way we see the real mask when the chip function decided to
    truncate it further as some arches do. IRQ_SET_MASK_OK is 0, which is
    the current behaviour.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

01 Dec, 2010

1 commit

  • Since commit a1afb637(switch /proc/irq/*/spurious to seq_file) all
    /proc/irq/XX/spurious files show the information of irq 0.

    Current irq_spurious_proc_open() passes on NULL as the 3rd argument,
    which is used as an IRQ number in irq_spurious_proc_show(), to the
    single_open(). Because of this, all the /proc/irq/XX/spurious file
    shows IRQ 0 information regardless of the IRQ number.

    To fix the problem, irq_spurious_proc_open() must pass on the
    appropreate data (IRQ number) to single_open().

    Signed-off-by: Kenji Kaneshige
    Reviewed-by: Yong Zhang
    LKML-Reference:
    Cc: stable@kernel.org [2.6.33+]
    Signed-off-by: Thomas Gleixner

    Kenji Kaneshige
     

12 Oct, 2010

1 commit


04 Oct, 2010

1 commit