1 #468

gs0510 · 2017-09-21T10:56:20Z

No description provided.

mutexes are sleeping locks. This can result in the kernel scheduling in an atomic context, which would be an error. Because idr_alloc_cyclic is called with GFP_KERNEL anyway, there is no need to preload the IDR, and the preload code can simply be removed to get rid of the scheduling while atomic problem.

errer path in alloc_pid. Found through code review.

which makes it impossible to use a mutex (sleeping lock). Change the pid idr locking to use the pidmap_lock, which means putting the radix tree preload back in place.

Use GFP_ATOMIC instead. This will also cause the radix tree code to use the pre-allocated radix tree nodes, if required.

be called with a NULL mnt parameter. In that case, not only is there nothing to unhash, but trying to do so will oops the kernel with a null pointer dereference.

to RESERVED_PIDS after reaching the maximum. Giving init a PID other than 1 breaks everything, and causes the system to fail booting.

out to be necessary because find_ge_pid returns a struct pid pointer, while idr_get_next does not. There may be some synchronization issues at task exit time too, but I am not entirely sure. With this last fix, the kernel boots.

This closes a hole in our SMAP implementation. This patch comes from grsecurity. Good catch! Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/314cc9f294e8f14ed85485727556ad4f15bb1659.1502159503.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>

A hang on CPU0 onlining after a preceding offlining is observed. Trace shows that CPU0 is stuck in check_tsc_sync_target() waiting for source CPU to run check_tsc_sync_source() but this never happens. Source CPU, in its turn, is stuck on synchronize_sched() which is called from native_cpu_up() -> do_boot_cpu() -> unregister_nmi_handler(). So it's a classic ABBA deadlock, due to the use of synchronize_sched() in unregister_nmi_handler(). Fix the bug by moving unregister_nmi_handler() from do_boot_cpu() to native_cpu_up() after cpu onlining is done. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170803105818.9934-1-vkuznets@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>

…/VMLOAD" CPUID flag "virtual_vmload_vmsave" is what is going to land in /proc/cpuinfo now as per v4.13-rc4, for a single feature bit which is clearly too long. So rename it to what it is called in the processor manual. "v_vmsave_vmload" is a bit shorter, after all. We could go more aggressively here but having it the same as in the processor manual is advantageous. Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Radim Krčmář <rkrcmar@redhat.com> Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com> Cc: Jörg Rödel <joro@8bytes.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kvm-ML <kvm@vger.kernel.org> Link: http://lkml.kernel.org/r/20170801185552.GA3743@nazgul.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>

Mark a couple of structures and functions as 'static', pointed out by Sparse: warning: symbol 'bts_pmu' was not declared. Should it be static? warning: symbol 'p4_event_aliases' was not declared. Should it be static? warning: symbol 'rapl_attr_groups' was not declared. Should it be static? symbol 'process_uv2_message' was not declared. Should it be static? Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Andrew Banman <abanman@hpe.com> # for the UV change Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: kernel-janitors@vger.kernel.org Link: http://lkml.kernel.org/r/20170810155709.7094-1-colin.king@canonical.com Signed-off-by: Ingo Molnar <mingo@kernel.org>

Larry reported a CPU hotplug lock recursion in the MTRR code. ============================================ WARNING: possible recursive locking detected systemd-udevd/153 is trying to acquire lock: (cpu_hotplug_lock.rw_sem){.+.+.+}, at: [<c030fc26>] stop_machine+0x16/0x30 but task is already holding lock: (cpu_hotplug_lock.rw_sem){.+.+.+}, at: [<c0234353>] mtrr_add_page+0x83/0x470 .... cpus_read_lock+0x48/0x90 stop_machine+0x16/0x30 mtrr_add_page+0x18b/0x470 mtrr_add+0x3e/0x70 mtrr_add_page() holds the hotplug rwsem already and calls stop_machine() which acquires it again. Call stop_machine_cpuslocked() instead. Reported-and-tested-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1708140920250.1865@nanos Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Borislav Petkov <bp@suse.de>

Documentation/admin-guide/kernel-parameters.txt says: norandmaps Don't use address space randomization. Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space but it doesn't work because arch_rnd() which is used to randomize mm->mmap_base returns a random value unconditionally. And as Kirill pointed out, ADDR_NO_RANDOMIZE is broken by the same reason. Just shift the PF_RANDOMIZE check from arch_mmap_rnd() to arch_rnd(). Fixes: 1b028f7 ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()") Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Cyrill Gorcunov <gorcunov@openvz.org> Reviewed-by: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: stable@vger.kernel.org Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20170815153952.GA1076@redhat.com

The ADDR_NO_RANDOMIZE checks in stack_maxrandom_size() and randomize_stack_top() are not required. PF_RANDOMIZE is set by load_elf_binary() only if ADDR_NO_RANDOMIZE is not set, no need to re-check after that. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: stable@vger.kernel.org Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Link: http://lkml.kernel.org/r/20170815154011.GB1076@redhat.com

__startup_64() is normally using fixup_pointer() to access globals in a position-independent fashion. However 'next_early_pgt' was accessed directly, which wasn't guaranteed to work. Luckily GCC was generating a R_X86_64_PC32 PC-relative relocation for 'next_early_pgt', but Clang emitted a R_X86_64_32S, which led to accessing invalid memory and rebooting the kernel. Signed-off-by: Alexander Potapenko <glider@google.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Davidson <md@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: c88d715 ("x86/boot/64: Rewrite startup_64() in C") Link: http://lkml.kernel.org/r/20170816190808.131748-1-glider@google.com Signed-off-by: Ingo Molnar <mingo@kernel.org>

attribute_groups are not supposed to change at runtime and none of the groups is modified. Mark the non-const structs as const. [ tglx: Folded into one big patch ] Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: tony.luck@intel.com Cc: bp@alien8.de Link: http://lkml.kernel.org/r/1500550238-15655-2-git-send-email-arvind.yadav.cs@gmail.com

The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability). That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid. So change the access checks to the more common 'ptrace_may_access()' model instead. This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice. Famous last words. Reported-by: Otto Ebeling <otto.ebeling@iki.fi> Acked-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mutexes are sleeping locks. This can result in the kernel scheduling in an atomic context, which would be an error. Because idr_alloc_cyclic is called with GFP_KERNEL anyway, there is no need to preload the IDR, and the preload code can simply be removed to get rid of the scheduling while atomic problem.

errer path in alloc_pid. Found through code review.

which makes it impossible to use a mutex (sleeping lock). Change the pid idr locking to use the pidmap_lock, which means putting the radix tree preload back in place.

Use GFP_ATOMIC instead. This will also cause the radix tree code to use the pre-allocated radix tree nodes, if required.

fix proc_flush_task oops

Fix checkpatch warnings: WARNING: Use #include <linux/io.h> instead of <asm/io.h> torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38: +#include <asm/io.h> WARNING: line over 80 characters torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109: +#define ZILOG_CHANNEL_FROM_PORT(PORT) ((struct zilog_channel __iomem *)((PORT)->membase)) WARNING: line over 80 characters torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116: +#define ZS_WANTS_MODEM_STATUS(UP) ((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS) WARNING: line over 80 characters torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179: +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs) WARNING: Missing a blank line after declarations torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188: + unsigned char stat = read_zsreg(channel, R1); + if (stat & ALL_SNT) ERROR: trailing whitespace torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231: +^I$ WARNING: braces {} are not necessary for any arm of this statement torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276: + if (ZS_TX_ACTIVE(up)) { [...] + } else { [...] ERROR: else should follow close brace '}' torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378: + } + else if (r1 & PAR_ERR) ERROR: code indent should use tabs where possible torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397: +^I^I ^Itty_insert_flip_char(port, ch, flag);$ WARNING: please, no space before tabs torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397: +^I^I ^Itty_insert_flip_char(port, ch, flag);$ WARNING: line over 80 characters torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440: + /* The Zilog just gives us an interrupt when DCD/CTS/etc. change. WARNING: line over 80 characters torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441: + * But it does not tell us which bit has changed, we have to keep WARNING: Missing a blank line after declarations torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464: + unsigned char status = readb(&channel->control); + ZSDELAY(); WARNING: line over 80 characters torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468: + * It can occur because of how we do serial console writes. It would WARNING: line over 80 characters torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469: + * be nice to transmit console writes just like we normally would for WARNING: line over 80 characters torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470: + * a TTY line. (ie. buffered and TX interrupt driven). That is not WARNING: line over 80 characters torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471: + * easy because console writes cannot sleep. One solution might be WARNING: line over 80 characters torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593: +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port) WARNING: plain inline is preferred over __inline__ torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593: +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port) ERROR: trailing whitespace torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664: +^I/* NOTE: Not subject to 'transmitter active' rule. */ $ ERROR: trailing whitespace torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752: +^I^I/* NOTE: Not subject to 'transmitter active' rule. */ $ ERROR: trailing whitespace torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779: +^I^I/* NOTE: Not subject to 'transmitter active' rule. */ $ WARNING: line over 80 characters #999: FILE: drivers/tty/serial/sunzilog.c:999: +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser) WARNING: Missing a blank line after declarations #1142: FILE: drivers/tty/serial/sunzilog.c:1142: + unsigned char val = readb(&channel->control); + if (val & Tx_BUF_EMP) { WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ... #1230: FILE: drivers/tty/serial/sunzilog.c:1230: + printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n", WARNING: braces {} are not necessary for single statement blocks #1383: FILE: drivers/tty/serial/sunzilog.c:1383: + if (__load_zsregs(channel, up->curregs)) { + up->flags |= SUNZILOG_FLAG_ESCC; + } WARNING: quoted string split across lines #1493: FILE: drivers/tty/serial/sunzilog.c:1493: + dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) " + "is a %s\n", WARNING: quoted string split across lines #1497: FILE: drivers/tty/serial/sunzilog.c:1497: + dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) " + "is a %s\n", WARNING: Missing a blank line after declarations #1581: FILE: drivers/tty/serial/sunzilog.c:1581: + struct uart_sunzilog_port *up = sunzilog_irq_chain; + err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED, WARNING: line over 80 characters #1590: FILE: drivers/tty/serial/sunzilog.c:1590: + /* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */ WARNING: line over 80 characters #1627: FILE: drivers/tty/serial/sunzilog.c:1627: + /* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */ ERROR: trailing statements should be on next line #1248: FILE: drivers/tty/serial/sunzilog.c:1248: + case B150: baud = 150; break; ERROR: trailing statements should be on next line #1249: FILE: drivers/tty/serial/sunzilog.c:1249: + case B300: baud = 300; break; ERROR: trailing statements should be on next line #1250: FILE: drivers/tty/serial/sunzilog.c:1250: + case B600: baud = 600; break; ERROR: trailing statements should be on next line #1251: FILE: drivers/tty/serial/sunzilog.c:1251: + case B1200: baud = 1200; break; ERROR: trailing statements should be on next line #1252: FILE: drivers/tty/serial/sunzilog.c:1252: + case B2400: baud = 2400; break; ERROR: trailing statements should be on next line #1253: FILE: drivers/tty/serial/sunzilog.c:1253: + case B4800: baud = 4800; break; ERROR: trailing statements should be on next line #1254: FILE: drivers/tty/serial/sunzilog.c:1254: + default: case B9600: baud = 9600; break; ERROR: trailing statements should be on next line #1255: FILE: drivers/tty/serial/sunzilog.c:1255: + case B19200: baud = 19200; break; ERROR: trailing statements should be on next line #1256: FILE: drivers/tty/serial/sunzilog.c:1256: + case B38400: baud = 38400; break; Signed-off-by: Enrico Weigelt <info@metux.net>

Merge 5.0

Fix checkpatch warnings: WARNING: Use #include <linux/io.h> instead of <asm/io.h> torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38: +#include <asm/io.h> WARNING: line over 80 characters torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109: +#define ZILOG_CHANNEL_FROM_PORT(PORT) ((struct zilog_channel __iomem *)((PORT)->membase)) WARNING: line over 80 characters torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116: +#define ZS_WANTS_MODEM_STATUS(UP) ((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS) WARNING: line over 80 characters torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179: +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs) WARNING: Missing a blank line after declarations torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188: + unsigned char stat = read_zsreg(channel, R1); + if (stat & ALL_SNT) ERROR: trailing whitespace torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231: +^I$ WARNING: braces {} are not necessary for any arm of this statement torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276: + if (ZS_TX_ACTIVE(up)) { [...] + } else { [...] ERROR: else should follow close brace '}' torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378: + } + else if (r1 & PAR_ERR) ERROR: code indent should use tabs where possible torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397: +^I^I ^Itty_insert_flip_char(port, ch, flag);$ WARNING: please, no space before tabs torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397: +^I^I ^Itty_insert_flip_char(port, ch, flag);$ WARNING: line over 80 characters torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440: + /* The Zilog just gives us an interrupt when DCD/CTS/etc. change. WARNING: line over 80 characters torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441: + * But it does not tell us which bit has changed, we have to keep WARNING: Missing a blank line after declarations torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464: + unsigned char status = readb(&channel->control); + ZSDELAY(); WARNING: line over 80 characters torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468: + * It can occur because of how we do serial console writes. It would WARNING: line over 80 characters torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469: + * be nice to transmit console writes just like we normally would for WARNING: line over 80 characters torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470: + * a TTY line. (ie. buffered and TX interrupt driven). That is not WARNING: line over 80 characters torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471: + * easy because console writes cannot sleep. One solution might be WARNING: line over 80 characters torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593: +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port) WARNING: plain inline is preferred over __inline__ torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593: +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port) ERROR: trailing whitespace torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664: +^I/* NOTE: Not subject to 'transmitter active' rule. */ $ ERROR: trailing whitespace torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752: +^I^I/* NOTE: Not subject to 'transmitter active' rule. */ $ ERROR: trailing whitespace torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779: +^I^I/* NOTE: Not subject to 'transmitter active' rule. */ $ WARNING: line over 80 characters #999: FILE: drivers/tty/serial/sunzilog.c:999: +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser) WARNING: Missing a blank line after declarations #1142: FILE: drivers/tty/serial/sunzilog.c:1142: + unsigned char val = readb(&channel->control); + if (val & Tx_BUF_EMP) { WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ... #1230: FILE: drivers/tty/serial/sunzilog.c:1230: + printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n", WARNING: braces {} are not necessary for single statement blocks #1383: FILE: drivers/tty/serial/sunzilog.c:1383: + if (__load_zsregs(channel, up->curregs)) { + up->flags |= SUNZILOG_FLAG_ESCC; + } WARNING: quoted string split across lines #1493: FILE: drivers/tty/serial/sunzilog.c:1493: + dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) " + "is a %s\n", WARNING: quoted string split across lines #1497: FILE: drivers/tty/serial/sunzilog.c:1497: + dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) " + "is a %s\n", WARNING: Missing a blank line after declarations #1581: FILE: drivers/tty/serial/sunzilog.c:1581: + struct uart_sunzilog_port *up = sunzilog_irq_chain; + err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED, WARNING: line over 80 characters #1590: FILE: drivers/tty/serial/sunzilog.c:1590: + /* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */ WARNING: line over 80 characters #1627: FILE: drivers/tty/serial/sunzilog.c:1627: + /* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */ ERROR: trailing statements should be on next line #1248: FILE: drivers/tty/serial/sunzilog.c:1248: + case B150: baud = 150; break; ERROR: trailing statements should be on next line #1249: FILE: drivers/tty/serial/sunzilog.c:1249: + case B300: baud = 300; break; ERROR: trailing statements should be on next line #1250: FILE: drivers/tty/serial/sunzilog.c:1250: + case B600: baud = 600; break; ERROR: trailing statements should be on next line #1251: FILE: drivers/tty/serial/sunzilog.c:1251: + case B1200: baud = 1200; break; ERROR: trailing statements should be on next line #1252: FILE: drivers/tty/serial/sunzilog.c:1252: + case B2400: baud = 2400; break; ERROR: trailing statements should be on next line #1253: FILE: drivers/tty/serial/sunzilog.c:1253: + case B4800: baud = 4800; break; ERROR: trailing statements should be on next line #1254: FILE: drivers/tty/serial/sunzilog.c:1254: + default: case B9600: baud = 9600; break; ERROR: trailing statements should be on next line #1255: FILE: drivers/tty/serial/sunzilog.c:1255: + case B19200: baud = 19200; break; ERROR: trailing statements should be on next line #1256: FILE: drivers/tty/serial/sunzilog.c:1256: + case B38400: baud = 38400; break; Signed-off-by: Enrico Weigelt <info@metux.net>

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#47: FILE: hal/HalBtcOutSrc.h:47: +typedef enum _BTC_POWERSAVE_TYPE { WARNING: do not add new typedefs torvalds#54: FILE: hal/HalBtcOutSrc.h:54: +typedef enum _BTC_BT_REG_TYPE { WARNING: do not add new typedefs torvalds#63: FILE: hal/HalBtcOutSrc.h:63: +typedef enum _BTC_CHIP_INTERFACE { WARNING: do not add new typedefs torvalds#71: FILE: hal/HalBtcOutSrc.h:71: +typedef enum _BTC_CHIP_TYPE { WARNING: do not add new typedefs torvalds#81: FILE: hal/HalBtcOutSrc.h:81: +typedef enum _BTC_MSG_TYPE { WARNING: do not add new typedefs torvalds#167: FILE: hal/HalBtcOutSrc.h:167: +typedef struct _BTC_BOARD_INFO { WARNING: do not add new typedefs torvalds#177: FILE: hal/HalBtcOutSrc.h:177: +typedef enum _BTC_DBG_OPCODE { WARNING: do not add new typedefs torvalds#187: FILE: hal/HalBtcOutSrc.h:187: +typedef enum _BTC_RSSI_STATE { WARNING: do not add new typedefs torvalds#200: FILE: hal/HalBtcOutSrc.h:200: +typedef enum _BTC_WIFI_ROLE { WARNING: do not add new typedefs torvalds#208: FILE: hal/HalBtcOutSrc.h:208: +typedef enum _BTC_WIFI_BW_MODE { WARNING: do not add new typedefs torvalds#215: FILE: hal/HalBtcOutSrc.h:215: +typedef enum _BTC_WIFI_TRAFFIC_DIR { WARNING: do not add new typedefs torvalds#221: FILE: hal/HalBtcOutSrc.h:221: +typedef enum _BTC_WIFI_PNP { WARNING: do not add new typedefs torvalds#228: FILE: hal/HalBtcOutSrc.h:228: +typedef enum _BT_WIFI_COEX_STATE { WARNING: do not add new typedefs torvalds#239: FILE: hal/HalBtcOutSrc.h:239: +typedef enum _BTC_GET_TYPE { WARNING: do not add new typedefs torvalds#281: FILE: hal/HalBtcOutSrc.h:281: +typedef enum _BTC_SET_TYPE { WARNING: do not add new typedefs torvalds#321: FILE: hal/HalBtcOutSrc.h:321: +typedef enum _BTC_DBG_DISP_TYPE { WARNING: do not add new typedefs torvalds#328: FILE: hal/HalBtcOutSrc.h:328: +typedef enum _BTC_NOTIFY_TYPE_IPS { WARNING: do not add new typedefs torvalds#334: FILE: hal/HalBtcOutSrc.h:334: +typedef enum _BTC_NOTIFY_TYPE_LPS { WARNING: do not add new typedefs torvalds#340: FILE: hal/HalBtcOutSrc.h:340: +typedef enum _BTC_NOTIFY_TYPE_SCAN { WARNING: do not add new typedefs torvalds#346: FILE: hal/HalBtcOutSrc.h:346: +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE { WARNING: do not add new typedefs torvalds#352: FILE: hal/HalBtcOutSrc.h:352: +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS { WARNING: do not add new typedefs torvalds#358: FILE: hal/HalBtcOutSrc.h:358: +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET { WARNING: do not add new typedefs torvalds#366: FILE: hal/HalBtcOutSrc.h:366: +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION { WARNING: do not add new typedefs torvalds#374: FILE: hal/HalBtcOutSrc.h:374: +typedef enum _BTC_ANTENNA_POS { WARNING: do not add new typedefs torvalds#412: FILE: hal/HalBtcOutSrc.h:412: +typedef struct _BTC_BT_INFO { WARNING: do not add new typedefs torvalds#440: FILE: hal/HalBtcOutSrc.h:440: +typedef struct _BTC_STACK_INFO { WARNING: do not add new typedefs torvalds#455: FILE: hal/HalBtcOutSrc.h:455: +typedef struct _BTC_BT_LINK_INFO { WARNING: do not add new typedefs torvalds#468: FILE: hal/HalBtcOutSrc.h:468: +typedef struct _BTC_STATISTICS { WARNING: do not add new typedefs torvalds#487: FILE: hal/HalBtcOutSrc.h:487: +typedef struct _BTC_COEXIST { Signed-off-by: Marco Cesati <marco.cesati@gmail.com>

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#47: FILE: hal/HalBtcOutSrc.h:47: +typedef enum _BTC_POWERSAVE_TYPE { WARNING: do not add new typedefs torvalds#54: FILE: hal/HalBtcOutSrc.h:54: +typedef enum _BTC_BT_REG_TYPE { WARNING: do not add new typedefs torvalds#63: FILE: hal/HalBtcOutSrc.h:63: +typedef enum _BTC_CHIP_INTERFACE { WARNING: do not add new typedefs torvalds#71: FILE: hal/HalBtcOutSrc.h:71: +typedef enum _BTC_CHIP_TYPE { WARNING: do not add new typedefs torvalds#81: FILE: hal/HalBtcOutSrc.h:81: +typedef enum _BTC_MSG_TYPE { WARNING: do not add new typedefs torvalds#167: FILE: hal/HalBtcOutSrc.h:167: +typedef struct _BTC_BOARD_INFO { WARNING: do not add new typedefs torvalds#177: FILE: hal/HalBtcOutSrc.h:177: +typedef enum _BTC_DBG_OPCODE { WARNING: do not add new typedefs torvalds#187: FILE: hal/HalBtcOutSrc.h:187: +typedef enum _BTC_RSSI_STATE { WARNING: do not add new typedefs torvalds#200: FILE: hal/HalBtcOutSrc.h:200: +typedef enum _BTC_WIFI_ROLE { WARNING: do not add new typedefs torvalds#208: FILE: hal/HalBtcOutSrc.h:208: +typedef enum _BTC_WIFI_BW_MODE { WARNING: do not add new typedefs torvalds#215: FILE: hal/HalBtcOutSrc.h:215: +typedef enum _BTC_WIFI_TRAFFIC_DIR { WARNING: do not add new typedefs torvalds#221: FILE: hal/HalBtcOutSrc.h:221: +typedef enum _BTC_WIFI_PNP { WARNING: do not add new typedefs torvalds#228: FILE: hal/HalBtcOutSrc.h:228: +typedef enum _BT_WIFI_COEX_STATE { WARNING: do not add new typedefs torvalds#239: FILE: hal/HalBtcOutSrc.h:239: +typedef enum _BTC_GET_TYPE { WARNING: do not add new typedefs torvalds#281: FILE: hal/HalBtcOutSrc.h:281: +typedef enum _BTC_SET_TYPE { WARNING: do not add new typedefs torvalds#321: FILE: hal/HalBtcOutSrc.h:321: +typedef enum _BTC_DBG_DISP_TYPE { WARNING: do not add new typedefs torvalds#328: FILE: hal/HalBtcOutSrc.h:328: +typedef enum _BTC_NOTIFY_TYPE_IPS { WARNING: do not add new typedefs torvalds#334: FILE: hal/HalBtcOutSrc.h:334: +typedef enum _BTC_NOTIFY_TYPE_LPS { WARNING: do not add new typedefs torvalds#340: FILE: hal/HalBtcOutSrc.h:340: +typedef enum _BTC_NOTIFY_TYPE_SCAN { WARNING: do not add new typedefs torvalds#346: FILE: hal/HalBtcOutSrc.h:346: +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE { WARNING: do not add new typedefs torvalds#352: FILE: hal/HalBtcOutSrc.h:352: +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS { WARNING: do not add new typedefs torvalds#358: FILE: hal/HalBtcOutSrc.h:358: +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET { WARNING: do not add new typedefs torvalds#366: FILE: hal/HalBtcOutSrc.h:366: +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION { WARNING: do not add new typedefs torvalds#374: FILE: hal/HalBtcOutSrc.h:374: +typedef enum _BTC_ANTENNA_POS { WARNING: do not add new typedefs torvalds#412: FILE: hal/HalBtcOutSrc.h:412: +typedef struct _BTC_BT_INFO { WARNING: do not add new typedefs torvalds#440: FILE: hal/HalBtcOutSrc.h:440: +typedef struct _BTC_STACK_INFO { WARNING: do not add new typedefs torvalds#455: FILE: hal/HalBtcOutSrc.h:455: +typedef struct _BTC_BT_LINK_INFO { WARNING: do not add new typedefs torvalds#468: FILE: hal/HalBtcOutSrc.h:468: +typedef struct _BTC_STATISTICS { WARNING: do not add new typedefs torvalds#487: FILE: hal/HalBtcOutSrc.h:487: +typedef struct _BTC_COEXIST { Signed-off-by: Marco Cesati <marco.cesati@gmail.com> Link: https://lore.kernel.org/r/20210312082638.25512-2-marco.cesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#26: FILE: ./hal/odm_HWConfig.c:26: +s32 odm_SignalScaleMapping(struct DM_ODM_T * pDM_Odm, s32 CurrSig) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#80: FILE: ./hal/odm_HWConfig.c:80: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#93: FILE: ./hal/odm_HWConfig.c:93: + struct PHY_STATUS_RPT_8192CD_T * pPhyStaRpt = (struct PHY_STATUS_RPT_8192CD_T *)pPhyStatus; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#250: FILE: ./hal/odm_HWConfig.c:250: + struct DM_ODM_T * pDM_Odm, struct odm_phy_info *pPhyInfo, struct odm_packet_info *pPktinfo ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#404: FILE: ./hal/odm_HWConfig.c:404: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#418: FILE: ./hal/odm_HWConfig.c:418: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#434: FILE: ./hal/odm_HWConfig.c:434: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #453: FILE: ./hal/odm_HWConfig.c:453: +enum HAL_STATUS ODM_ConfigRFWithTxPwrTrackHeaderFile(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#468: FILE: ./hal/odm_HWConfig.c:468: + struct DM_ODM_T * pDM_Odm, enum ODM_BB_Config_Type ConfigType Signed-off-by: Marco Cesati <marcocesati@gmail.com>

This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#26: FILE: ./hal/odm_HWConfig.c:26: +s32 odm_SignalScaleMapping(struct DM_ODM_T * pDM_Odm, s32 CurrSig) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#80: FILE: ./hal/odm_HWConfig.c:80: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#93: FILE: ./hal/odm_HWConfig.c:93: + struct PHY_STATUS_RPT_8192CD_T * pPhyStaRpt = (struct PHY_STATUS_RPT_8192CD_T *)pPhyStatus; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#250: FILE: ./hal/odm_HWConfig.c:250: + struct DM_ODM_T * pDM_Odm, struct odm_phy_info *pPhyInfo, struct odm_packet_info *pPktinfo ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#404: FILE: ./hal/odm_HWConfig.c:404: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#418: FILE: ./hal/odm_HWConfig.c:418: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#434: FILE: ./hal/odm_HWConfig.c:434: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #453: FILE: ./hal/odm_HWConfig.c:453: +enum HAL_STATUS ODM_ConfigRFWithTxPwrTrackHeaderFile(struct DM_ODM_T * pDM_Odm) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#468: FILE: ./hal/odm_HWConfig.c:468: + struct DM_ODM_T * pDM_Odm, enum ODM_BB_Config_Type ConfigType Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marco Cesati <marcocesati@gmail.com> Link: https://lore.kernel.org/r/20210315170618.2566-28-marcocesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: add `UniqueRef`.

PD#150081: driver defect clean up: torvalds#20 torvalds#38 torvalds#87 torvalds#468 torvalds#469 torvalds#470 torvalds#471 torvalds#613 torvalds#668 Change-Id: Ifa0756e25088599571761b33efaffb6c2c898dfc Signed-off-by: Evoke Zhang <evoke.zhang@amlogic.com>

The global rwsem dmar_global_lock was introduced by commit 3a5670e ("iommu/vt-d: Introduce a rwsem to protect global data structures"). It is used to protect DMAR related global data from DMAR hotplug operations. Using dmar_global_lock in intel_irq_remapping_alloc() is unnecessary as the DMAR global data structures are not touched there. Remove it to avoid below lockdep warning. ====================================================== WARNING: possible circular locking dependency detected 6.3.0-rc2 torvalds#468 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ff1db4cb40178698 (&domain->mutex){+.+.}-{3:3}, at: __irq_domain_alloc_irqs+0x3b/0xa0 but task is already holding lock: ffffffffa0c1cdf0 (dmar_global_lock){++++}-{3:3}, at: intel_iommu_init+0x58e/0x880 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dmar_global_lock){++++}-{3:3}: lock_acquire+0xd6/0x320 down_read+0x42/0x180 intel_irq_remapping_alloc+0xad/0x750 mp_irqdomain_alloc+0xb8/0x2b0 irq_domain_alloc_irqs_locked+0x12f/0x2d0 __irq_domain_alloc_irqs+0x56/0xa0 alloc_isa_irq_from_domain.isra.7+0xa0/0xe0 mp_map_pin_to_irq+0x1dc/0x330 setup_IO_APIC+0x128/0x210 apic_intr_mode_init+0x67/0x110 x86_late_time_init+0x24/0x40 start_kernel+0x41e/0x7e0 secondary_startup_64_no_verify+0xe0/0xeb -> #0 (&domain->mutex){+.+.}-{3:3}: check_prevs_add+0x160/0xef0 __lock_acquire+0x147d/0x1950 lock_acquire+0xd6/0x320 __mutex_lock+0x9c/0xfc0 __irq_domain_alloc_irqs+0x3b/0xa0 dmar_alloc_hwirq+0x9e/0x120 iommu_pmu_register+0x11d/0x200 intel_iommu_init+0x5de/0x880 pci_iommu_init+0x12/0x40 do_one_initcall+0x65/0x350 kernel_init_freeable+0x3ca/0x610 kernel_init+0x1a/0x140 ret_from_fork+0x29/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(dmar_global_lock); lock(&domain->mutex); lock(dmar_global_lock); lock(&domain->mutex); *** DEADLOCK *** Fixes: 9dbb8e3 ("irqdomain: Switch to per-domain locking") Link: https://lore.kernel.org/r/20230314051836.23817-1-baolu.lu@linux.intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jacob Pan <jacob.jun.pan@linux.intel.com>

The global rwsem dmar_global_lock was introduced by commit 3a5670e ("iommu/vt-d: Introduce a rwsem to protect global data structures"). It is used to protect DMAR related global data from DMAR hotplug operations. Using dmar_global_lock in intel_irq_remapping_alloc() is unnecessary as the DMAR global data structures are not touched there. Remove it to avoid below lockdep warning. ====================================================== WARNING: possible circular locking dependency detected 6.3.0-rc2 #468 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ff1db4cb40178698 (&domain->mutex){+.+.}-{3:3}, at: __irq_domain_alloc_irqs+0x3b/0xa0 but task is already holding lock: ffffffffa0c1cdf0 (dmar_global_lock){++++}-{3:3}, at: intel_iommu_init+0x58e/0x880 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dmar_global_lock){++++}-{3:3}: lock_acquire+0xd6/0x320 down_read+0x42/0x180 intel_irq_remapping_alloc+0xad/0x750 mp_irqdomain_alloc+0xb8/0x2b0 irq_domain_alloc_irqs_locked+0x12f/0x2d0 __irq_domain_alloc_irqs+0x56/0xa0 alloc_isa_irq_from_domain.isra.7+0xa0/0xe0 mp_map_pin_to_irq+0x1dc/0x330 setup_IO_APIC+0x128/0x210 apic_intr_mode_init+0x67/0x110 x86_late_time_init+0x24/0x40 start_kernel+0x41e/0x7e0 secondary_startup_64_no_verify+0xe0/0xeb -> #0 (&domain->mutex){+.+.}-{3:3}: check_prevs_add+0x160/0xef0 __lock_acquire+0x147d/0x1950 lock_acquire+0xd6/0x320 __mutex_lock+0x9c/0xfc0 __irq_domain_alloc_irqs+0x3b/0xa0 dmar_alloc_hwirq+0x9e/0x120 iommu_pmu_register+0x11d/0x200 intel_iommu_init+0x5de/0x880 pci_iommu_init+0x12/0x40 do_one_initcall+0x65/0x350 kernel_init_freeable+0x3ca/0x610 kernel_init+0x1a/0x140 ret_from_fork+0x29/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(dmar_global_lock); lock(&domain->mutex); lock(dmar_global_lock); lock(&domain->mutex); *** DEADLOCK *** Fixes: 9dbb8e3 ("irqdomain: Switch to per-domain locking") Reviewed-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Tested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20230314051836.23817-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20230329134721.469447-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>

The global rwsem dmar_global_lock was introduced by commit 3a5670e ("iommu/vt-d: Introduce a rwsem to protect global data structures"). It is used to protect DMAR related global data from DMAR hotplug operations. Using dmar_global_lock in intel_irq_remapping_alloc() is unnecessary as the DMAR global data structures are not touched there. Remove it to avoid below lockdep warning. ====================================================== WARNING: possible circular locking dependency detected 6.3.0-rc2 torvalds#468 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ff1db4cb40178698 (&domain->mutex){+.+.}-{3:3}, at: __irq_domain_alloc_irqs+0x3b/0xa0 but task is already holding lock: ffffffffa0c1cdf0 (dmar_global_lock){++++}-{3:3}, at: intel_iommu_init+0x58e/0x880 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dmar_global_lock){++++}-{3:3}: lock_acquire+0xd6/0x320 down_read+0x42/0x180 intel_irq_remapping_alloc+0xad/0x750 mp_irqdomain_alloc+0xb8/0x2b0 irq_domain_alloc_irqs_locked+0x12f/0x2d0 __irq_domain_alloc_irqs+0x56/0xa0 alloc_isa_irq_from_domain.isra.7+0xa0/0xe0 mp_map_pin_to_irq+0x1dc/0x330 setup_IO_APIC+0x128/0x210 apic_intr_mode_init+0x67/0x110 x86_late_time_init+0x24/0x40 start_kernel+0x41e/0x7e0 secondary_startup_64_no_verify+0xe0/0xeb -> #0 (&domain->mutex){+.+.}-{3:3}: check_prevs_add+0x160/0xef0 __lock_acquire+0x147d/0x1950 lock_acquire+0xd6/0x320 __mutex_lock+0x9c/0xfc0 __irq_domain_alloc_irqs+0x3b/0xa0 dmar_alloc_hwirq+0x9e/0x120 iommu_pmu_register+0x11d/0x200 intel_iommu_init+0x5de/0x880 pci_iommu_init+0x12/0x40 do_one_initcall+0x65/0x350 kernel_init_freeable+0x3ca/0x610 kernel_init+0x1a/0x140 ret_from_fork+0x29/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(dmar_global_lock); lock(&domain->mutex); lock(dmar_global_lock); lock(&domain->mutex); *** DEADLOCK *** Fixes: 9dbb8e3 ("irqdomain: Switch to per-domain locking") Link: https://lore.kernel.org/r/20230314051836.23817-1-baolu.lu@linux.intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jacob Pan <jacob.jun.pan@linux.intel.com>

The global rwsem dmar_global_lock was introduced by commit 3a5670e ("iommu/vt-d: Introduce a rwsem to protect global data structures"). It is used to protect DMAR related global data from DMAR hotplug operations. Using dmar_global_lock in intel_irq_remapping_alloc() is unnecessary as the DMAR global data structures are not touched there. Remove it to avoid below lockdep warning. ====================================================== WARNING: possible circular locking dependency detected 6.3.0-rc2 torvalds#468 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ff1db4cb40178698 (&domain->mutex){+.+.}-{3:3}, at: __irq_domain_alloc_irqs+0x3b/0xa0 but task is already holding lock: ffffffffa0c1cdf0 (dmar_global_lock){++++}-{3:3}, at: intel_iommu_init+0x58e/0x880 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dmar_global_lock){++++}-{3:3}: lock_acquire+0xd6/0x320 down_read+0x42/0x180 intel_irq_remapping_alloc+0xad/0x750 mp_irqdomain_alloc+0xb8/0x2b0 irq_domain_alloc_irqs_locked+0x12f/0x2d0 __irq_domain_alloc_irqs+0x56/0xa0 alloc_isa_irq_from_domain.isra.7+0xa0/0xe0 mp_map_pin_to_irq+0x1dc/0x330 setup_IO_APIC+0x128/0x210 apic_intr_mode_init+0x67/0x110 x86_late_time_init+0x24/0x40 start_kernel+0x41e/0x7e0 secondary_startup_64_no_verify+0xe0/0xeb -> #0 (&domain->mutex){+.+.}-{3:3}: check_prevs_add+0x160/0xef0 __lock_acquire+0x147d/0x1950 lock_acquire+0xd6/0x320 __mutex_lock+0x9c/0xfc0 __irq_domain_alloc_irqs+0x3b/0xa0 dmar_alloc_hwirq+0x9e/0x120 iommu_pmu_register+0x11d/0x200 intel_iommu_init+0x5de/0x880 pci_iommu_init+0x12/0x40 do_one_initcall+0x65/0x350 kernel_init_freeable+0x3ca/0x610 kernel_init+0x1a/0x140 ret_from_fork+0x29/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(dmar_global_lock); lock(&domain->mutex); lock(dmar_global_lock); lock(&domain->mutex); *** DEADLOCK *** Fixes: 9dbb8e3 ("irqdomain: Switch to per-domain locking") Reviewed-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Tested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20230314051836.23817-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20230329134721.469447-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>

The global rwsem dmar_global_lock was introduced by commit 3a5670e ("iommu/vt-d: Introduce a rwsem to protect global data structures"). It is used to protect DMAR related global data from DMAR hotplug operations. Using dmar_global_lock in intel_irq_remapping_alloc() is unnecessary as the DMAR global data structures are not touched there. Remove it to avoid below lockdep warning. ====================================================== WARNING: possible circular locking dependency detected 6.3.0-rc2 torvalds#468 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ff1db4cb40178698 (&domain->mutex){+.+.}-{3:3}, at: __irq_domain_alloc_irqs+0x3b/0xa0 but task is already holding lock: ffffffffa0c1cdf0 (dmar_global_lock){++++}-{3:3}, at: intel_iommu_init+0x58e/0x880 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dmar_global_lock){++++}-{3:3}: lock_acquire+0xd6/0x320 down_read+0x42/0x180 intel_irq_remapping_alloc+0xad/0x750 mp_irqdomain_alloc+0xb8/0x2b0 irq_domain_alloc_irqs_locked+0x12f/0x2d0 __irq_domain_alloc_irqs+0x56/0xa0 alloc_isa_irq_from_domain.isra.7+0xa0/0xe0 mp_map_pin_to_irq+0x1dc/0x330 setup_IO_APIC+0x128/0x210 apic_intr_mode_init+0x67/0x110 x86_late_time_init+0x24/0x40 start_kernel+0x41e/0x7e0 secondary_startup_64_no_verify+0xe0/0xeb -> #0 (&domain->mutex){+.+.}-{3:3}: check_prevs_add+0x160/0xef0 __lock_acquire+0x147d/0x1950 lock_acquire+0xd6/0x320 __mutex_lock+0x9c/0xfc0 __irq_domain_alloc_irqs+0x3b/0xa0 dmar_alloc_hwirq+0x9e/0x120 iommu_pmu_register+0x11d/0x200 intel_iommu_init+0x5de/0x880 pci_iommu_init+0x12/0x40 do_one_initcall+0x65/0x350 kernel_init_freeable+0x3ca/0x610 kernel_init+0x1a/0x140 ret_from_fork+0x29/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(dmar_global_lock); lock(&domain->mutex); lock(dmar_global_lock); lock(&domain->mutex); *** DEADLOCK *** Fixes: 9dbb8e3 ("irqdomain: Switch to per-domain locking") Link: https://lore.kernel.org/r/20230314051836.23817-1-baolu.lu@linux.intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jacob Pan <jacob.jun.pan@linux.intel.com>

gs0510 and others added 26 commits August 21, 2017 10:06

Replace bitmap PID implementation with IDR API implementation

c57cdfe

Add locking around the idr_remove calls in the out_free

9cb5ff7

errer path in alloc_pid. Found through code review.

The function free_pid is called with irqs and preemption disabled,

ec07a32

which makes it impossible to use a mutex (sleeping lock). Change the pid idr locking to use the pidmap_lock, which means putting the radix tree preload back in place.

GFP_KERNEL can sleep, and cannot be used from an atomic context.

ec9ae10

Use GFP_ATOMIC instead. This will also cause the radix tree code to use the pre-allocated radix tree nodes, if required.

If a task exits before procfs is mounted, proc_flush_task_mnt will

d7885c2

be called with a NULL mnt parameter. In that case, not only is there nothing to unhash, but trying to do so will oops the kernel with a null pointer dereference.

Ensure PID allocation starts at 1 during bootup, and wraps back around

ca41e8f

to RESERVED_PIDS after reaching the maximum. Giving init a PID other than 1 breaks everything, and causes the system to fail booting.

Linux 4.13-rc6

d0e11c3

Replace bitmap PID implementation with IDR API implementation

57d5003

Add locking around the idr_remove calls in the out_free

55c21c5

errer path in alloc_pid. Found through code review.

The function free_pid is called with irqs and preemption disabled,

6efcefe

which makes it impossible to use a mutex (sleeping lock). Change the pid idr locking to use the pidmap_lock, which means putting the radix tree preload back in place.

GFP_KERNEL can sleep, and cannot be used from an atomic context.

fde89ce

Use GFP_ATOMIC instead. This will also cause the radix tree code to use the pre-allocated radix tree nodes, if required.

Merge branch 'master' into master

5dcb605

Merge pull request #2 from rikvanriel/master

4c49fe7

fix proc_flush_task oops

gs0510 closed this Sep 21, 2017

ddiss pushed a commit to ddiss/linux that referenced this pull request Sep 5, 2019

Merge pull request torvalds#468 from libos-nuse/merge-5.0

0875fde

Merge 5.0

sodar pushed a commit to sodar/linux that referenced this pull request Oct 14, 2021

Merge pull request torvalds#468 from wedsonaf/ref-reservation

ad86bf9

rust: add `UniqueRef`.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

1 #468

1 #468

gs0510 commented Sep 21, 2017

1 #468

1 #468

Conversation

gs0510 commented Sep 21, 2017