Sync up with Linus #55
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the in-kernel push interface is used we may have a different masks on the device buffer and the kernel buffer and in this case the device should generate data for the reunion of the buffers, which is available at indio_dev->active_scan_mask. Compiled tested only except for bmc150-accel which was tested at runtime with the hardware. Signed-off-by: Octavian Purdila <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
mac80211 now informs the driver when to drop the packets upon flush(). This will happen before disconnecting, or before we shut down the interface. We can now rely on this to drop all the packets including the VO queues. When mac80211 sets drop to false, wait for all the queues to be empty. Signed-off-by: Emmanuel Grumbach <[email protected]>
If this situation ever happens, the mac80211 state machine gets confused because it never clears csa_active. There was a separate bug that lead to this happening with a working connection, but it isn't very robust to try to keep the connection up in this case. When removing the time event the CSA essentially procedure stops, so the safest thing to do is to disconnect in this case. Signed-off-by: Johannes Berg <[email protected]> Reviewed-by: Luciano Coelho <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
Currently driver reports device bandwidth list as available sampling frequency. But sampling frequency is actually twice the device bandwidth. This patch fixes this issue. Signed-off-by: Sathyanarayanan Kuppuswamy <[email protected]> Signed-off-by: Octavian Purdila <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
Without this change file name for hmc5843 is empty in /sys/bus/iio/devices/iio\:device*/name With this change name is reported correctly: cat /sys/bus/iio/devices/iio\:device*/name hmc5843 Signed-off-by: Marek Belisko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
A hardware fifo reset always imply an invalidation of the existing timestamps, so we'll clear timestamps fifo on successfull hardware fifo reset. Signed-off-by: Viorel Suman <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
CONFIG_SIMPLE_DUMMY_BUFFER compiles in iio_simple_dummy_buffer.c file which uses functions from industrialio-trigger.c. So, CONFIG_SIMPLE_DUMMY_BUFFER needs to select IIO_TRIGGER in order to avoid build error like this: > ERROR: "iio_trigger_notify_done" [drivers/staging/iio/iio_dummy.ko] undefined! > ERROR: "iio_triggered_buffer_postenable" [drivers/staging/iio/iio_dummy.ko] undefined! > ERROR: "iio_triggered_buffer_predisable" [drivers/staging/iio/iio_dummy.ko] undefined! > ERROR: "iio_alloc_pollfunc" [drivers/staging/iio/iio_dummy.ko] undefined! > ERROR: "iio_dealloc_pollfunc" [drivers/staging/iio/iio_dummy.ko] undefined! Cc: Arnd Bergmann <[email protected]> Reported-by: kbuild test robot <[email protected]> Signed-off-by: Daniel Baluta <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
Fix inconsistency in the semantics of the scale attribute. For scale the write_raw function was considering the scale table index and writing the appropriate value into the range register, while for read_raw it was outputting the actual scale. Fix this behaviour and adhere to the iio ABI specification. Signed-off-by: Adriana Reus <[email protected]> Reviewed-by: Viorel Suman <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
When an error occurred during event registration memory was freed twice resulting in kernel memory corruption and a crash in unrelated code. The problem was caused by iio_device_unregister_eventset() iio_device_unregister_sysfs() being called twice, once on the error path and then again via iio_dev_release(). Fix this by making these two functions idempotent so they may be called multiple times. The problem was observed before applying 78b3321 iio:core: Handle error when mask type is not separate Signed-off-by: Martin Fuzzey <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
sc->nbcnvifs tracks assigned beacon slots, not enabled beacons. Therefore, it cannot be used to decide if cur_conf->enable_beacon (bool) should be updated, or if beacons have been enabled already. With the current code (depending on the order of calls), beacons often do not get enabled in an AP+STA setup. To fix tracking of enabled beacons, convert cur_conf->enable_beacon to a bitmask of enabled beacon slots. Cc: [email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
TPC support has been observed to cause some tx power fluctuations on some devices with at least AR934x and AR938x chips. Disable it for now until the bugs have been found and fixed Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their SNAP Stick 200 product. Signed-off-by: Doug Goldstein <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
Jan Kara pointed out that if there is an inode which is constantly getting dirtied with I_DIRTY_PAGES, an inode with an updated timestamp will never be written since inode->dirtied_when is constantly getting updated. We fix this by adding an extra field to the inode, dirtied_time_when, so inodes with a stale dirtytime can get detected and handled. In addition, if we have a dirtytime inode caused by an atime update, and there is no write activity on the file system, we need to have a secondary system to make sure these inodes get written out. We do this by setting up a second delayed work structure which wakes up the CPU much more rarely compared to writeback_expire_centisecs. Signed-off-by: Theodore Ts'o <[email protected]> Reviewed-by: Jan Kara <[email protected]>
Add a tuning knob so we can adjust the dirtytime expiration timeout, which is very useful for testing lazytime. Signed-off-by: Theodore Ts'o <[email protected]> Reviewed-by: Jan Kara <[email protected]>
The assumption before this patch was that we don't need to run again the INIT firmware after the system booted. The INIT firmware runs calibrations which impact the physical layer's behavior. Users reported that it may be helpful to run these calibrations again every time the interface is brought up. The penatly is minimal, since the calibrations run fast. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=94341 CC: <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
When the driver callback returns that it's out of space for new stations, the mac80211 IBSS code still keeps the station so it doesn't try to add it over and over again. Since the rate scaling algorithm is separate in mac80211, it also invokes the rate scaling algorithm for such stations. It doesn't know that our rate scaling algorithm is tightly integrated with the MVM code and relies on those data structures, and it cannot as the abstraction doesn't allow for it. This leads to crashes when the rate scaling algorithm tries to use uninitialized data, notably the mvmsta->vif pointer. Protect against this in the rate scaling algorithm. We cannot get good rates with such peers anyway since the firmware cannot do anything with them. This should fix https://bugzilla.kernel.org/show_bug.cgi?id=93461 CC: <[email protected]> Reported-by: Richard Taylor <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
Add new 3165 PCI IDs for new 1x1 cards. Signed-off-by: Oren Givon <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
The firmware frequently manages to trigger this, and there's no known driver workaround, so stop warning. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
Add USB VID/PID for Xircom PGMFHUB USB/serial component. (The hub and SCSI bridge on that hardware are recognized out of the box by existing drivers.) Tested VID/PID using new_id and loopback connection and was met with success, but that's all the testing done. Signed-off-by: Nathaniel Wesley Filardo <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
31ef83d "nfsd: add trace events" had a typo that dropped a trace event and replaced it by an incorrect recursive call to nfsd4_cb_layout_fail. 133d558 "Subject: nfsd: don't recursively call nfsd4_cb_layout_fail" fixed the crash, this restores the tracepoint. Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Kinglong Mee <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
According to RFC5661: " When lr_returntype is LAYOUTRETURN4_FSID, the current filehandle is used to identify the file system and all layouts matching the client ID, the fsid of the file system, lora_layout_type, and lora_iomode are returned. When lr_returntype is LAYOUTRETURN4_ALL, all layouts matching the client ID, lora_layout_type, and lora_iomode are returned and the current filehandle is not used. " When returning client layouts, always check layout type. Signed-off-by: Kinglong Mee <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
Return status after nfsd4_decode_stateid failed. Signed-off-by: Kinglong Mee <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
If register_shrinker() failed, nfsd will cause a NULL pointer access as, [ 9250.875465] nfsd: last server has exited, flushing export cache [ 9251.427270] BUG: unable to handle kernel NULL pointer dereference at (null) [ 9251.427393] IP: [<ffffffff8136fc29>] __list_del_entry+0x29/0xd0 [ 9251.427579] PGD 13e4d067 PUD 13e4c067 PMD 0 [ 9251.427633] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [ 9251.427706] Modules linked in: ip6t_rpfilter ip6t_REJECT bnep bluetooth xt_conntrack cfg80211 rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw btrfs xfs microcode ppdev serio_raw pcspkr xor libcrc32c raid6_pq e1000 parport_pc parport i2c_piix4 i2c_core nfsd(OE-) auth_rpcgss nfs_acl lockd sunrpc(E) ata_generic pata_acpi [ 9251.428240] CPU: 0 PID: 1557 Comm: rmmod Tainted: G OE 3.16.0-rc2+ #22 [ 9251.428366] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 9251.428496] task: ffff880000849540 ti: ffff8800136f4000 task.ti: ffff8800136f4000 [ 9251.428593] RIP: 0010:[<ffffffff8136fc29>] [<ffffffff8136fc29>] __list_del_entry+0x29/0xd0 [ 9251.428696] RSP: 0018:ffff8800136f7ea0 EFLAGS: 00010207 [ 9251.428751] RAX: 0000000000000000 RBX: ffffffffa0116d48 RCX: dead000000200200 [ 9251.428814] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffa0116d48 [ 9251.428876] RBP: ffff8800136f7ea0 R08: ffff8800136f4000 R09: 0000000000000001 [ 9251.428939] R10: 8080808080808080 R11: 0000000000000000 R12: ffffffffa011a5a0 [ 9251.429002] R13: 0000000000000800 R14: 0000000000000000 R15: 00000000018ac090 [ 9251.429064] FS: 00007fb9acef0740(0000) GS:ffff88003fa00000(0000) knlGS:0000000000000000 [ 9251.429164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9251.429221] CR2: 0000000000000000 CR3: 0000000031a17000 CR4: 00000000001407f0 [ 9251.429306] Stack: [ 9251.429410] ffff8800136f7eb8 ffffffff8136fcdd ffffffffa0116d20 ffff8800136f7ed0 [ 9251.429511] ffffffff8118a0f2 0000000000000000 ffff8800136f7ee0 ffffffffa00eb765 [ 9251.429610] ffff8800136f7ef0 ffffffffa010e93c ffff8800136f7f78 ffffffff81104ac2 [ 9251.429709] Call Trace: [ 9251.429755] [<ffffffff8136fcdd>] list_del+0xd/0x30 [ 9251.429896] [<ffffffff8118a0f2>] unregister_shrinker+0x22/0x40 [ 9251.430037] [<ffffffffa00eb765>] nfsd_reply_cache_shutdown+0x15/0x90 [nfsd] [ 9251.430106] [<ffffffffa010e93c>] exit_nfsd+0x9/0x6cd [nfsd] [ 9251.430192] [<ffffffff81104ac2>] SyS_delete_module+0x162/0x200 [ 9251.430280] [<ffffffff81013b69>] ? do_notify_resume+0x59/0x90 [ 9251.430395] [<ffffffff816f2369>] system_call_fastpath+0x16/0x1b [ 9251.430457] Code: 00 00 55 48 8b 17 48 b9 00 01 10 00 00 00 ad de 48 8b 47 08 48 89 e5 48 39 ca 74 29 48 b9 00 02 20 00 00 00 ad de 48 39 c8 74 7a <4c> 8b 00 4c 39 c7 75 53 4c 8b 42 08 4c 39 c7 75 2b 48 89 42 08 [ 9251.430691] RIP [<ffffffff8136fc29>] __list_del_entry+0x29/0xd0 [ 9251.430755] RSP <ffff8800136f7ea0> [ 9251.430805] CR2: 0000000000000000 [ 9251.431033] ---[ end trace 080f3050d082b4ea ]--- Signed-off-by: Kinglong Mee <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
Currently there are only two "tools" that can be specified by a multi-touch driver: MT_TOOL_FINGER and MT_TOOL_PEN. In working with Elan (The touch vendor) and discussing their next-gen devices it seems that it will be useful to have more tools so that their devices can give the upper layers of the stack hints as to what is touching the sensor. In particular they have new experimental firmware that can better differentiate between palms vs fingertips and would like to plumb a patch so that we can use their hints in higher-level gesture soft- ware. The firmware on the device can reasonably do a better job of palm detection because it has access to all of the raw sensor readings as opposed to just the width/pressure/etc that are exposed by the driver. As such, the firmware can characterize what a palm looks like in much finer-grained detail and this change would allow such a device to share its findings with the kernel. Signed-off-by: Charlie Mooney <[email protected]> Acked-by: Peter Hutterer <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
Fix commit 9cf514c (nfsd: implement pNFS operations). Signed-off-by: Kinglong Mee <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]>
The BCM43362 firmware falsely reports it is capable of providing MBSS. As a result AP mode no longer works for this device. Therefor disable MBSS in the driver for this chipset. Cc: [email protected] # 3.19.y Reported-by: Jorg Krause <[email protected]> Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
While attempting to clone a file on a samba server, we receive a STATUS_INVALID_DEVICE_REQUEST. This is mapped to -EOPNOTSUPP which isn't handled in smb2_clone_range(). We end up looping in the while loop making same call to the samba server over and over again. The proposed fix is to exit and return the error value when encountered with an unhandled error. Cc: <[email protected]> Signed-off-by: Sachin Prabhu <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Steve French <[email protected]>
Under intermittent network outages, find_writable_file() is susceptible
to the following race condition, which results in a user-after-free in
the cifs_writepages code-path:
Thread 1 Thread 2
======== ========
inv_file = NULL
refind = 0
spin_lock(&cifs_file_list_lock)
// invalidHandle found on openFileList
inv_file = open_file
// inv_file->count currently 1
cifsFileInfo_get(inv_file)
// inv_file->count = 2
spin_unlock(&cifs_file_list_lock);
cifs_reopen_file() cifs_close()
// fails (rc != 0) ->cifsFileInfo_put()
spin_lock(&cifs_file_list_lock)
// inv_file->count = 1
spin_unlock(&cifs_file_list_lock)
spin_lock(&cifs_file_list_lock);
list_move_tail(&inv_file->flist,
&cifs_inode->openFileList);
spin_unlock(&cifs_file_list_lock);
cifsFileInfo_put(inv_file);
->spin_lock(&cifs_file_list_lock)
// inv_file->count = 0
list_del(&cifs_file->flist);
// cleanup!!
kfree(cifs_file);
spin_unlock(&cifs_file_list_lock);
spin_lock(&cifs_file_list_lock);
++refind;
// refind = 1
goto refind_writable;
At this point we loop back through with an invalid inv_file pointer
and a refind value of 1. On second pass, inv_file is not overwritten on
openFileList traversal, and is subsequently dereferenced.
Signed-off-by: David Disseldorp <[email protected]>
Reviewed-by: Jeff Layton <[email protected]>
CC: <[email protected]>
Signed-off-by: Steve French <[email protected]>
For example, when mount opt is redundently specified (e.g., "user=A,user=B,user=C"), kernel kept allocating new key/val with kstrdup() and overwrite previous ptr (to be freed). Althouhg mount.cifs in userspace performs a bit of sanitization (e.g., forcing one user option), current implementation is not robust. Other options such as iocharset and domainanme are similarly vulnerable. Signed-off-by: Taesoo Kim <[email protected]> Signed-off-by: Steve French <[email protected]>
Transmission of an AP beacon does not call the TX interrupt service routine, which usually does the cleanup. Instead, cleanup is handled in a tasklet completion routine. Unfortunately, this routine has a serious bug in that it does not release the DMA mapping before it frees the skb, thus one IOMMU mapping is leaked for each beacon. The test system failed with no free IOMMU mapping slots approximately one hour after hostapd was used to start an AP. This issue was reported and tested at https://github.com/lwfinger/rtlwifi_new/issues/30. Reported-and-tested-by: Kevin Mullican <[email protected]> Cc: Kevin Mullican <[email protected]> Signed-off-by: Shao Fu <[email protected]> Signed-off-by: Larry Finger <[email protected]> Cc: Stable <[email protected]> [3.18+] Signed-off-by: Kalle Valo <[email protected]>
This reverts commit 4217291 ("netns: don't clear nsid too early on removal"). This is not the right fix, it introduces races. Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
First, let's explain the problem.
Suppose you have an ipip interface that stands in the netns foo and its link
part in the netns bar (so the netns bar has an nsid into the netns foo).
Now, you remove the netns bar:
- the bar nsid into the netns foo is removed
- the netns exit method of ipip is called, thus our ipip iface is removed:
=> a netlink message is built in the netns foo to advertise this deletion
=> this netlink message requests an nsid for bar, thus a new nsid is
allocated for bar and never removed.
This patch adds a check in peernet2id() so that an id cannot be allocated for
a netns which is currently destroyed.
Signed-off-by: Nicolas Dichtel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Pull CIFS fixes from Steve French: "A set of small cifs fixes fixing a memory leak, kernel oops, and infinite loop (and some spotted by Coverity)" * 'for-next' of git://git.samba.org/sfrench/cifs-2.6: Fix warning Fix another dereference before null check warning CIFS: session servername can't be null Fix warning on impossible comparison Fix coverity warning Fix dereference before null check warning Don't ignore errors on encrypting password in SMBTcon Fix warning on uninitialized buftype cifs: potential memory leaks when parsing mnt opts cifs: fix use-after-free bug in find_writable_file cifs: smb2_clone_range() - exit on unhandled error
…x/kernel/git/glikely/linux Pull devicetree fix from Grant Likely: "Simple bugfix for bad device tree data on the PA-Semi platform" * tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux: drivers/of: Add empty ranges quirk for PA-Semi
…linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "Two x86 Intel PMU constraint handling fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Fix Haswell CYCLE_ACTIVITY.* counter constraints perf/x86/intel: Filter branches for PEBS event
…inux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "Misc fixes: a SYSRET single-stepping fix, a dmi-scan robustization fix, a reboot quirk and a kgdb fixlet" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: kgdb/x86: Fix reporting of 'si' in kgdb on x86_64 x86/asm/entry/64: Disable opportunistic SYSRET if regs->flags has TF set x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk MAINTAINERS: Change the x86 microcode loader maintainer firmware: dmi_scan: Prevent dmi_num integer overflow
Pull block layer fix from Jens Axboe: "Just one patch in this pull request, fixing a regression caused by a 'mathematically correct' change to lcm()" * 'for-linus' of git://git.kernel.dk/linux-block: block: fix blk_stack_limits() regression due to lcm() change
…/git/dtor/input Pull input subsystem fixes from Dmitry Torokhov: "A fix for ALPS driver for issue introduced in the latest update and a tweak for yet another Lenovo box in Synaptics. There will be more ALPS tweaks coming.." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: define INPUT_PROP_ACCELEROMETER behavior Input: synaptics - fix min-max quirk value for E440 Input: synaptics - add quirk for Thinkpad E440 Input: ALPS - fix max coordinates for v5 and v7 protocols Input: add MT_TOOL_PALM
…git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are 3 serial driver fixes for 4.0-rc6. They fix some reported issues with the samsung and fsl_lpuart drivers. All have been in linux-next for a while" * tag 'tty-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty: serial: fsl_lpuart: clear receive flag on FIFO flush tty: serial: fsl_lpuart: specify transmit FIFO size serial: samsung: Clear operation mode on UART shutdown
…nel/git/gregkh/staging Pull staging driver fixes from Greg KH: "Here are some staging driver fixes, well, really all just IIO driver fixes, for 4.0-rc6. They fix issues that have been reported with these drivers. All of these patches have been in linux-next for a while" * tag 'staging-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: iio: imu: Use iio_trigger_get for indio_dev->trig assignment iio: adc: vf610: use ADC clock within specification iio/adc/cc10001_adc.c: Fix !HAS_IOMEM build iio: core: Fix double free. iio:inv-mpu6050: Fix inconsistency for the scale channel staging: iio: dummy: Fix undefined symbol build error iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo staging: iio: hmc5843: Set iio name property in sysfs iio: bmc150: change sampling frequency iio: fix drivers that check buffer->scan_mask
…git/gregkh/usb Pull USB fixes from Greg KH: "Here are some small USB fixes and new device ids for 4.0-rc6. Nothing major, some xhci fixes for reported problems, and some usb-serial device ids. All have been in linux-next for a while" * tag 'usb-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: ftdi_sio: Use jtag quirk for SNAP Connect E10 usb: isp1760: fix spin unlock in the error path of isp1760_udc_start usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers usb: xhci: handle Config Error Change (CEC) in xhci driver USB: keyspan_pda: add new device id USB: ftdi_sio: Added custom PID for Synapse Wireless product
Bare packets should be reported via the same evdev device independent on whether they are detected on the beginning of a packet or in the middle of a packet. This has been tested on a Dell Latitude E6400, where the DualPoint Stick reports bare packets, which get reported via dev3 when the touchpad is idle, and via dev2 when the touchpad and stick are used simultaneously. This commit fixes this inconsistency by always reporting bare packets via dev3. Note that since the come from a DualPoint Stick they really should be reported via dev2, this gets fixed in a later commit. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Pali Rohár <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
On V2 devices the DualPoint Stick reports bare packets, these should be reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also has the INPUT_PROP_POINTING_STICK propbit set. Note that since there is no way to distinguish these packets from an external PS/2 mouse (insofar as these laptops have an external PS/2 port) this means that we will be reporting PS/2 mouse events via this evdev node too, as we've been doing in kernel 3.19 and older. This has been tested on a Dell Latitude D620 and a Dell Latitude E6400, which both have a V2 touchpad + a DualPoint Stick which reports bare packets. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Pali Rohár <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
Document that protocol V2 uses standard (bare) PS/2 mouse packets for the DualPoint stick. Signed-off-by: Hans de Goede <[email protected]> Acked-By: Pali Rohár <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
…stack We should not consult skb->sk for output decisions in xmit recursion levels > 0 in the stack. Otherwise local socket settings could influence the result of e.g. tunnel encapsulation process. ipv6 does not conform with this in three places: 1) ip6_fragment: we do consult ipv6_npinfo for frag_size 2) sk_mc_loop in ipv6 uses skb->sk and checks if we should loop the packet back to the local socket 3) ip6_skb_dst_mtu could query the settings from the user socket and force a wrong MTU Furthermore: In sk_mc_loop we could potentially land in WARN_ON(1) if we use a PF_PACKET socket ontop of an IPv6-backed vxlan device. Reuse xmit_recursion as we are currently only interested in protecting tunnel devices. Cc: Jiri Pirko <[email protected]> Signed-off-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]>
mvneta_adjust_link() is a callback for of_phy_connect() and should not be called directly. The result of calling it directly is as below: Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
…/git/dtor/input Pull input fixes from Dmitry Torokhov: "Updates for the input subsystem - two more tweaks for ALPS driver to work out kinks after splitting the touchpad, trackstick, and potential external PS/2 mouse into separate input devices. Changes to support ALPS SS4 devices (protocol V8) will be coming in 4.1..." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: alps - document stick behavior for protocol V2 Input: alps - report V2 Dualpoint Stick events via the right evdev node Input: alps - report interleaved bare PS/2 packets via dev3
According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.
However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.
This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.
To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.
This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.
Signed-off-by: Pavel Nakonechny <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Commit 1daa430 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug") did the deprecation only for port 1 of the card. Need to deprecate for port 2 as well. Fixes: 1daa430 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug") Signed-off-by: Jack Morgenstein <[email protected]> Signed-off-by: Amir Vadai <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Pull networking fixes from David Miller:
1) In TCP, don't register an FRTO for cumulatively ACK'd data that was
previously SACK'd, from Neal Cardwell.
2) Need to hold RNL mutex in ipv4 multicast code namespace cleanup,
from Cong WANG.
3) Similarly we have to hold RNL mutex for fib_rules_unregister(), also
from Cong WANG.
4) Revert and rework netns nsid allocation fix, from Nicolas Dichtel.
5) When we encapsulate for a tunnel device, skb->sk still points to the
user socket. So this leads to cases where we retraverse the
ipv4/ipv6 output path with skb->sk being of some other address
family (f.e. AF_PACKET). This can cause things to crash since the
ipv4 output path is dereferencing an AF_PACKET socket as if it were
an ipv4 one.
The short term fix for 'net' and -stable is to elide these socket
checks once we've entered an encapsulation sequence by testing
xmit_recursion.
Longer term we have a better solution wherein we pass the tunnel's
socket down through the output paths, but that is way too invasive
for 'net' and -stable.
From Hannes Frederic Sowa.
6) l2tp_init() failure path forgets to unregister per-net ops, from
Cong WANG.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
net: dsa: fix filling routing table from OF description
l2tp: unregister l2tp_net_ops on failure path
mvneta: dont call mvneta_adjust_link() manually
ipv6: protect skb->sk accesses from recursive dereference inside the stack
netns: don't allocate an id for dead netns
Revert "netns: don't clear nsid too early on removal"
ip6mr: call del_timer_sync() in ip6mr_free_table()
net: move fib_rules_unregister() under rtnl lock
ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup
tcp: fix FRTO undo on cumulative ACK of SACKed range
xen-netfront: transmit fully GSO-sized packets
dabrace
pushed a commit
that referenced
this pull request
Apr 22, 2015
img_ir_remove() passes a pointer to the ISR function as the 2nd parameter to irq_free() instead of a pointer to the device data structure. This issue causes unloading img-ir module to fail with the below warning after building and loading img-ir as a module. WARNING: CPU: 2 PID: 155 at ../kernel/irq/manage.c:1278 __free_irq+0xb4/0x214() Trying to free already-free IRQ 58 Modules linked in: img_ir(-) CPU: 2 PID: 155 Comm: rmmod Not tainted 3.14.0 #55 ... Call Trace: ... [<8048d420>] __free_irq+0xb4/0x214 [<8048d6b4>] free_irq+0xac/0xf4 [<c009b130>] img_ir_remove+0x54/0xd4 [img_ir] [<8073ded0>] platform_drv_remove+0x30/0x54 ... Fixes: 160a8f8 ("[media] rc: img-ir: add base driver") Signed-off-by: Sifan Naeem <[email protected]> Cc: <[email protected]> # 3.15+ Acked-by: James Hogan <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Sep 4, 2015
Since IRQ chip helpers were introduced drivers lose ability to
register separate lockdep classes for each registered GPIO IRQ
chip and the gpiolib now is using shared lockdep class for
all GPIO IRQ chips (gpiochip_irq_lock_class).
As result, lockdep will produce warning when there are min two
stacked GPIO chips and all of them are interrupt controllers.
HW configuration which generates lockdep warning (TI dra7-evm):
[SOC GPIO bankA.gpioX]
<- irq - [pcf875x.gpioY]
<- irq - DevZ.enable_irq_wake(pcf_gpioY_irq);
The issue was reported in [1] and discussed [2].
=============================================
[ INFO: possible recursive locking detected ]
4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted
---------------------------------------------
sh/63 is trying to acquire lock:
(class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
but task is already holding lock:
(class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(class);
lock(class);
*** DEADLOCK ***
May be due to missing lock nesting notation
7 locks held by sh/63:
#0: (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164
#1: (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0
#2: (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0
#3: (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4
#4: (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398
#5: (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94
#6: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
stack backtrace:
CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55
Hardware name: Generic DRA74X (Flattened Device Tree)
[<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14)
[<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c)
[<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20)
[<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128)
[<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c)
[<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94)
[<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc)
[<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54)
[<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc)
[<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4)
[<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124)
[<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398)
[<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4)
[<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728)
[<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4)
[<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8)
[<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0)
[<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8)
[<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164)
[<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c)
[<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
Lets fix it by using separate lockdep class for each registered GPIO
IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros.
The implementation of this patch inspired by solution done by Nicolas
Boichat for regmap [3]
[1] http://www.spinics.net/lists/linux-gpio/msg05844.html
[2] http://www.spinics.net/lists/linux-gpio/msg06021.html
[3] http://www.spinics.net/lists/arm-kernel/msg429834.html
Cc: Geert Uytterhoeven <[email protected]>
Cc: Roger Quadros <[email protected]>
Reported-by: Roger Quadros <[email protected]>
Tested-by: Roger Quadros <[email protected]>
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Oct 3, 2016
While the driver is probing the adapter, an error may occur before the netdev structure is allocated and attached to pci_dev. In this case, not only netdev isn't available, but the tg3 private structure is also not available as it is just math from the NULL pointer, so dereferences must be skipped. The following trace is seen when the error is triggered: [1.402247] Unable to handle kernel paging request for data at address 0x00001a99 [1.402410] Faulting instruction address: 0xc0000000007e33f8 [1.402450] Oops: Kernel access of bad area, sig: 11 [#1] [1.402481] SMP NR_CPUS=2048 NUMA PowerNV [1.402513] Modules linked in: [1.402545] CPU: 0 PID: 651 Comm: eehd Not tainted 4.4.0-36-generic #55-Ubuntu [1.402591] task: c000001fe4e42a20 ti: c000001fe4e88000 task.ti: c000001fe4e88000 [1.402742] NIP: c0000000007e33f8 LR: c0000000007e3164 CTR: c000000000595ea0 [1.402787] REGS: c000001fe4e8b790 TRAP: 0300 Not tainted (4.4.0-36-generic) [1.402832] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 28000422 XER: 20000000 [1.403058] CFAR: c000000000008468 DAR: 0000000000001a99 DSISR: 42000000 SOFTE: 1 GPR00: c0000000007e3164 c000001fe4e8ba10 c0000000015c5e00 0000000000000000 GPR04: 0000000000000001 0000000000000000 0000000000000039 0000000000000299 GPR08: 0000000000000000 0000000000000001 c000001fe4e88000 0000000000000006 GPR12: 0000000000000000 c00000000fb40000 c0000000000e6558 c000003ca1bffd00 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000d52768 GPR24: c000000000d52740 0000000000000100 c000003ca1b52000 0000000000000002 GPR28: 0000000000000900 0000000000000000 c00000000152a0c0 c000003ca1b52000 [1.404226] NIP [c0000000007e33f8] tg3_io_error_detected+0x308/0x340 [1.404265] LR [c0000000007e3164] tg3_io_error_detected+0x74/0x340 This patch avoids the NULL pointer dereference by moving the access after the netdev NULL pointer check on tg3_io_error_detected(). Also, we add a check for netdev being NULL on tg3_io_resume() [suggested by Michael Chan]. Fixes: 0486a06 ("tg3: prevent ifup/ifdown during PCI error recovery") Fixes: dfc8f37 ("net/tg3: Release IRQs on permanent error") Tested-by: Guilherme G. Piccoli <[email protected]> Signed-off-by: Milton Miller <[email protected]> Signed-off-by: Guilherme G. Piccoli <[email protected]> Acked-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Oct 3, 2016
…age_cache_page() Antonio reports the following crash when using fuse under memory pressure: kernel BUG at /build/linux-a2WvEb/linux-4.4.0/mm/workingset.c:346! invalid opcode: 0000 [#1] SMP Modules linked in: all of them CPU: 2 PID: 63 Comm: kswapd0 Not tainted 4.4.0-36-generic #55-Ubuntu Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904 04/27/2013 task: ffff88040cae6040 ti: ffff880407488000 task.ti: ffff880407488000 RIP: shadow_lru_isolate+0x181/0x190 Call Trace: __list_lru_walk_one.isra.3+0x8f/0x130 list_lru_walk_one+0x23/0x30 scan_shadow_nodes+0x34/0x50 shrink_slab.part.40+0x1ed/0x3d0 shrink_zone+0x2ca/0x2e0 kswapd+0x51e/0x990 kthread+0xd8/0xf0 ret_from_fork+0x3f/0x70 which corresponds to the following sanity check in the shadow node tracking: BUG_ON(node->count & RADIX_TREE_COUNT_MASK); The workingset code tracks radix tree nodes that exclusively contain shadow entries of evicted pages in them, and this (somewhat obscure) line checks whether there are real pages left that would interfere with reclaim of the radix tree node under memory pressure. While discussing ways how fuse might sneak pages into the radix tree past the workingset code, Miklos pointed to replace_page_cache_page(), and indeed there is a problem there: it properly accounts for the old page being removed - __delete_from_page_cache() does that - but then does a raw raw radix_tree_insert(), not accounting for the replacement page. Eventually the page count bits in node->count underflow while leaving the node incorrectly linked to the shadow node LRU. To address this, make sure replace_page_cache_page() uses the tracked page insertion code, page_cache_tree_insert(). This fixes the page accounting and makes sure page-containing nodes are properly unlinked from the shadow node LRU again. Also, make the sanity checks a bit less obscure by using the helpers for checking the number of pages and shadows in a radix tree node. Fixes: 449dd69 ("mm: keep page cache radix tree nodes in check") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Johannes Weiner <[email protected]> Reported-by: Antonio SJ Musumeci <[email protected]> Debugged-by: Miklos Szeredi <[email protected]> Cc: <[email protected]> [3.15+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Sep 14, 2018
When element of verdict map is deleted, the delete routine should
release chain. however, flush element of verdict map routine doesn't
release chain.
test commands:
%nft add table ip filter
%nft add chain ip filter c1
%nft add map ip filter map1 { type ipv4_addr : verdict \; }
%nft add element ip filter map1 { 1 : jump c1 }
%nft flush map ip filter map1
%nft flush ruleset
splat looks like:
[ 4895.170899] kernel BUG at net/netfilter/nf_tables_api.c:1415!
[ 4895.178114] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 4895.178880] CPU: 0 PID: 1670 Comm: nft Not tainted 4.18.0+ #55
[ 4895.178880] RIP: 0010:nf_tables_chain_destroy.isra.28+0x39/0x220 [nf_tables]
[ 4895.178880] Code: fc ff df 53 48 89 fb 48 83 c7 50 48 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 09 3c 03 7f 05 e8 3e 4c 25 e1 8b 43 50 85 c0 74 02 <0f> 0b 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02
[ 4895.228342] RSP: 0018:ffff88010b98f4c0 EFLAGS: 00010202
[ 4895.234841] RAX: 0000000000000001 RBX: ffff8801131c6968 RCX: ffff8801146585b0
[ 4895.234841] RDX: 1ffff10022638d37 RSI: ffff8801191a9348 RDI: ffff8801131c69b8
[ 4895.234841] RBP: ffff8801146585a8 R08: 1ffff1002323526a R09: 0000000000000000
[ 4895.234841] R10: 0000000000000000 R11: 0000000000000000 R12: dead000000000200
[ 4895.234841] R13: dead000000000100 R14: ffffffffa3638af8 R15: dffffc0000000000
[ 4895.234841] FS: 00007f6d188e6700(0000) GS:ffff88011b600000(0000) knlGS:0000000000000000
[ 4895.234841] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4895.234841] CR2: 00007ffe72b8df88 CR3: 000000010e2d4000 CR4: 00000000001006f0
[ 4895.234841] Call Trace:
[ 4895.234841] nf_tables_commit+0x2704/0x2c70 [nf_tables]
[ 4895.234841] ? nfnetlink_rcv_batch+0xa4f/0x11b0 [nfnetlink]
[ 4895.234841] ? nf_tables_setelem_notify.constprop.48+0x1a0/0x1a0 [nf_tables]
[ 4895.323824] ? __lock_is_held+0x9d/0x130
[ 4895.323824] ? kasan_unpoison_shadow+0x30/0x40
[ 4895.333299] ? kasan_kmalloc+0xa9/0xc0
[ 4895.333299] ? kmem_cache_alloc_trace+0x2c0/0x310
[ 4895.333299] ? nfnetlink_rcv_batch+0xa4f/0x11b0 [nfnetlink]
[ 4895.333299] nfnetlink_rcv_batch+0xdb9/0x11b0 [nfnetlink]
[ 4895.333299] ? debug_show_all_locks+0x290/0x290
[ 4895.333299] ? nfnetlink_net_init+0x150/0x150 [nfnetlink]
[ 4895.333299] ? sched_clock_cpu+0xe5/0x170
[ 4895.333299] ? sched_clock_local+0xff/0x130
[ 4895.333299] ? sched_clock_cpu+0xe5/0x170
[ 4895.333299] ? find_held_lock+0x39/0x1b0
[ 4895.333299] ? sched_clock_local+0xff/0x130
[ 4895.333299] ? memset+0x1f/0x40
[ 4895.333299] ? nla_parse+0x33/0x260
[ 4895.333299] ? ns_capable_common+0x6e/0x110
[ 4895.333299] nfnetlink_rcv+0x2c0/0x310 [nfnetlink]
[ ... ]
Fixes: 5910544 ("netfilter: nf_tables: revisit chain/object refcounting from elements")
Signed-off-by: Taehee Yoo <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Aug 27, 2020
We have a number of "uart.port->desc.lock vs desc.lock->uart.port" lockdep reports coming from 8250 driver; this causes a bit of trouble to people, so let's fix it. The problem is reverse lock order in two different call paths: chain #1: serial8250_do_startup() spin_lock_irqsave(&port->lock); disable_irq_nosync(port->irq); raw_spin_lock_irqsave(&desc->lock) chain #2: __report_bad_irq() raw_spin_lock_irqsave(&desc->lock) for_each_action_of_desc() printk() spin_lock_irqsave(&port->lock); Fix this by changing the order of locks in serial8250_do_startup(): do disable_irq_nosync() first, which grabs desc->lock, and grab uart->port after that, so that chain #1 and chain #2 have same lock order. Full lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.4.39 #55 Not tainted ====================================================== swapper/0/0 is trying to acquire lock: ffffffffab65b6c0 (console_owner){-...}, at: console_lock_spinning_enable+0x31/0x57 but task is already holding lock: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&irq_desc_lock_class){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d __irq_get_desc_lock+0x65/0x89 __disable_irq_nosync+0x3b/0x93 serial8250_do_startup+0x451/0x75c uart_startup+0x1b4/0x2ff uart_port_activate+0x73/0xa0 tty_port_open+0xae/0x10a uart_open+0x1b/0x26 tty_open+0x24d/0x3a0 chrdev_open+0xd5/0x1cc do_dentry_open+0x299/0x3c8 path_openat+0x434/0x1100 do_filp_open+0x9b/0x10a do_sys_open+0x15f/0x3d7 kernel_init_freeable+0x157/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d serial8250_console_write+0xa7/0x2a0 console_unlock+0x3b7/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 register_console+0x336/0x3a4 uart_add_one_port+0x51b/0x5be serial8250_register_8250_port+0x454/0x55e dw8250_probe+0x4dc/0x5b9 platform_drv_probe+0x67/0x8b really_probe+0x14a/0x422 driver_probe_device+0x66/0x130 device_driver_attach+0x42/0x5b __driver_attach+0xca/0x139 bus_for_each_dev+0x97/0xc9 bus_add_driver+0x12b/0x228 driver_register+0x64/0xed do_one_initcall+0x20c/0x4a6 do_initcall_level+0xb5/0xc5 do_basic_setup+0x4c/0x58 kernel_init_freeable+0x13f/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #0 (console_owner){-...}: __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 console_lock_spinning_enable+0x51/0x57 console_unlock+0x25d/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 ret_from_intr+0x0/0x1d cpuidle_enter_state+0x12f/0x1fd cpuidle_enter+0x2e/0x3d do_idle+0x1ce/0x2ce cpu_startup_entry+0x1d/0x1f start_kernel+0x406/0x46a secondary_startup_64+0xa4/0xb0 other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &irq_desc_lock_class Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&irq_desc_lock_class); lock(&port_lock_key); lock(&irq_desc_lock_class); lock(console_owner); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba #1: ffffffffab65b5c0 (console_lock){+.+.}, at: console_trylock_spinning+0x20/0x181 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.39 #55 Hardware name: XXXXXX Call Trace: <IRQ> dump_stack+0xbf/0x133 ? print_circular_bug+0xd6/0xe9 check_noncircular+0x1b9/0x1c3 __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 ? console_lock_spinning_enable+0x31/0x57 console_lock_spinning_enable+0x51/0x57 ? console_lock_spinning_enable+0x31/0x57 console_unlock+0x25d/0x528 ? console_trylock+0x18/0x4e vprintk_emit+0x111/0x17f ? lock_acquire+0x203/0x258 printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 common_interrupt+0xf/0xf </IRQ> Signed-off-by: Sergey Senozhatsky <[email protected]> Fixes: 768aec0 ("serial: 8250: fix shared interrupts issues with SMP and RT kernels") Reported-by: Guenter Roeck <[email protected]> Reported-by: Raul Rangel <[email protected]> BugLink: https://bugs.chromium.org/p/chromium/issues/detail?id=1114800 Link: https://lore.kernel.org/lkml/CAHQZ30BnfX+gxjPm1DUd5psOTqbyDh4EJE=2=VAMW_VDafctkA@mail.gmail.com/T/#u Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Tested-by: Guenter Roeck <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.