- 03 Nov, 2015 1 commit
-
-
Joe Thornber authored
commit 2871c69e upstream. Commit 4c7e3093 ("dm btree remove: fix bug in redistribute3") wasn't a complete fix for redistribute3(). The redistribute3 function takes 3 btree nodes and shares out the entries evenly between them. If the three nodes in total contained (MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in the center. Fix this issue by being more careful about calculating the target number of entries for the left and right nodes. Unit tested in userspace using this program: https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.cSigned-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
- 28 Oct, 2015 39 commits
-
-
Jiri Slaby authored
-
Daniel Lezcano authored
commit 2c2b24d9 upstream. The dbx500_cpuidle_probe is tagged as an __init section but the variable dbx500_cpuidle_plat_driver is not. The dbx500_cpuidle_probe could not be declared as __init because of macro module_platform_driver builds the exit function, tags as __exit and this one refers to the dbx500_cpuidle_plat_driver which is an __initdata. That leads to a section mismatch. Fix it by removing the __init tag for the probe function. Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Felix Fietkau authored
commit 029cd037 upstream. ath9k inserts padding between the 802.11 header and the data area (to align it). Since it didn't declare this extra required headroom, this led to some nasty issues like randomly dropped packets in some setups. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Jiri Slaby authored
This reverts commit e25ecd21 in 3.12, upstream commit ddbe1fca (USB: Add device quirk for ASUS T100 Base Station keyboard). It was applied twice to 3.12 and one backport is bogus. Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Macpaul Lin authored
commit e5dff0e8 upstream. OTG device shall support this device for allowing compliance automated testing. The modification is derived from Pavankumar and Vijayavardhans' previous work. Signed-off-by:
Macpaul Lin <macpaul@gmail.com> Cc: Pavankumar Kondeti <pkondeti@codeaurora.org> Cc: Vijayavardhan Vennapusa <vvreddy@codeaurora.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Oliver Neukum authored
commit e0e6a356 upstream. This reverts commit 614ced91. The units on this was seen were prototypes and the issue is not seen on younger units. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Huang Rui authored
commit 7868943d upstream. The following patch is required to resolve remote wake issues with certain devices. Issue description: If the remote wake is issued from the device in a specific timing condition while the system is entering sleep state then it may cause system to auto wake on subsequent sleep cycle. Root cause: Host controller rebroadcasts the Resume signal > 100 µseconds after receiving the original resume event from the device. For proper function, some devices may require the rebroadcast of resume event within the USB spec of 100µS. Workaroud: 1. Filter the AMD platforms with Yangtze chipset, then judge of all the usb devices are mouse or not. And get out the port id which attached a mouse with Pixart controller. 2. Then reset the port which attached issue device during system resume from S3. [Q] Why the special devices are only mice? Would high speed devices such as 3G modem or USB Bluetooth adapter trigger this issue? - Current this sensitivity is only confined to devices that use Pixart controllers. This controller is designed for use with LS mouse devices only. We have not observed any other devices failing. There may be a small risk for other devices also but this patch (reset device in resume phase) will cover the cases if required. [Q] Shouldn’t the resume signal be sent within 100 us for every device? - The Host controller may not send the resume signal within 100us, this our host controller specification change. This is why we require the patch to prevent side effects on certain known devices. [Q] Why would clicking mouse INTENSELY to wake the system up trigger this issue? - This behavior is specific to the devices that use Pixart controller. It is timing dependent on when the resume event is triggered during the sleep state. [Q] Is it a host controller issue or mouse? - It is the host controller behavior during resume that triggers the device incorrect behavior on the next resume. This patch sets USB_QUIRK_RESET_RESUME flag for these Pixart-based mice when they attached to platforms with AMD Yangtze chipset. Signed-off-by:
Huang Rui <ray.huang@amd.com> Suggested-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Nicholas Mc Guire authored
commit 63f2f417 upstream. API compliance scanning with coccinelle flagged: ./drivers/media/usb/gspca/m5602/m5602_s5k83a.c:180:9-25: WARNING: timeout (100) seems HZ dependent Numeric constants passed to schedule_timeout() make the effective timeout HZ dependent which makes little sense in a polling loop for the cameras rotation state. Fixed up by converting the constant to jiffies with msecs_to_jiffies() Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Nobuhiro Iwamatsu authored
commit 03b36e4d upstream. Clipping size bit of VI6_WPFn _HSZCLIP and VI6_WPFn _VSZCLIP register are from 0 bit to 11 bit. But VI6_WPF_SZCLIP_SIZE_MASK is set to 0x1FFF, this will mask until the reserve bits. This fixes size for VI6_WPF_SZCLIP_SIZE_MASK. Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Nobuhiro Iwamatsu authored
commit 1aa78903 upstream. FP bit of VI6_DPR_mod_ROUTE register is 6bit. But VI6_DPR_ROUTE_FP_MASK is set to 0xFF, this will mask until the reserve bit. This fixes size for VI6_DPR_ROUTE_FP_MASK. Signed-off-by:
-
Nobuhiro Iwamatsu authored
commit 45008ee9 upstream. FXA bit of VI6_DPR_mod_ROUTE register starts from 16bit. But VI6_DPR_ROUTE_FXA_MASK is set to become start from 8bit. This fixes shift size for VI6_DPR_ROUTE_FXA_MASK. Signed-off-by:
-
Hans Verkuil authored
commit e2c84ccb upstream. If remove_pending is non-zero, then the v4l2_lock is never unlocked. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Andrew Morton authored
commit d3b367bc upstream. It uses bitrev8(), so it must ensure that lib/bitrev.o gets included in vmlinux. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Sudip Mukherjee authored
commit d79bdc7f upstream. If omap4_keypad_parse_dt() fails we returned the error code but we missed releasing keypad_data. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Sudip Mukherjee authored
commit 1a5e2519 upstream. If parkbd_allocate_serio() fails to allocate memory we are releasing the parport but we missed unregistering the device. As a result this device with exclusive access to that parport remains registered. And no other device will be able to use that parport even though this driver has failed to load. Signed-off-by:
-
Stefan Assmann authored
commit 66bc2f51 upstream. There are trackpoint devices that fail to respond to the PS2 command PSMOUSE_CMD_GETID if immediately queried after the parent device is deactivated. Add a small delay for the hardware to get in a sane state before sending any PS2 commands. One example of such a system is: Lenovo ThinkPad X120e, model 30515QG synaptics: Touchpad model: 1, fw: 8.0, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x121c00, board id: 1811, fw id: 797391 Signed-off-by:
Stefan Assmann <sassmann@kpanic.de> Signed-off-by:
-
Benjamin Tissoires authored
commit c9b57724 upstream. Looks like 0x8882 needs the same quirk than 0x8883. Given that both devices claim they are "TPV OpticalTouchScreen" rename the 0x8883 to add its PID in the #define. Reported-by:
Blaine Lee <blaine.j.lee@medtronic.com> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Henrik Rydberg authored
commit a4a2c545 upstream. This patch adds keyboard support for MacbookPro12,1 as WELLSPRING9 (0x0272, 0x0273, 0x0274). The touchpad is handled in a separate bcm5974 patch, as usual. Tested-by:
John Horan <knasher@gmail.com> Tested-by:
Jochen Radmacher <jradmacher@gmx.de> Tested-by:
Yang Hongyang <burnef@gmail.com> Tested-by:
Yen-Chin, Lee <coldnew.tw@gmail.com> Tested-by:
George Hilios <ghilios@gmail.com> Tested-by:
Janez Urevc <janez@janezurevc.name> Signed-off-by:
Henrik Rydberg <rydberg@bitmath.org> Acked-by:
Jiri Kosina <jkosina@suse.com> Signed-off-by:
-
Bin Liu authored
commit b431ba88 upstream. After a few iterations of start/stop UVC camera streaming, the streaming stops. This patch adds 250us delay in the cppi channel abort path to let cppi drain properly. Using 50us delay seems to be too aggressive, some webcams are still broken. 250us is the original value used in TI 3.2 kernel. Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Cc: Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Bin Liu authored
commit cb83df77 upstream. 1. set AUTOREQ to NONE at the beginning of teardown; 2. add delay for dma pipeline to drain; 3. Do not set USB_TDOWN bit for RX teardown. The CPPI hw has an issue that when tearing down a RX channel, if another RX channel is receiving data, the CPPI will lockup. To workaround the issue, do not set the CPPI TD bit. The steps before this point ensures the CPPI channel will be torn down properly. Signed-off-by:
-
Philipp Hachtmann authored
commit 8ae25a35 upstream. The scanner (here DS3508) always returns 64 bytes per urb buffer. The first byte indicates the data length used in the current buffer. There even was a comment describing this. But the comment also said that we'll send everything in the buffer to the tty layer. That means sending the actual barcode data and lots of trailing zeroes. This patch lets the driver only send the real data. Signed-off-by:
Philipp Hachtmann <hachti@hachti.de> Acked-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Li Jun authored
commit bc249379 upstream. Add runtime pm operations for registers access to avoid system hang. Signed-off-by:
Li Jun <jun.li@freescale.com> Cc: Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Ilya Dryomov authored
commit 3ebe138a upstream. If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name is freed twice: once in rbd_dev_probe_parent() and then in its caller rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to handle parent images). rbd_dev_probe_parent() is responsible for probing the parent, so it shouldn't muck with clone's fields. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Mike Snitzer authored
commit ba30670f upstream. Fixes: ac8c3f3d ("dm thin: generate event when metadata threshold passed") Signed-off-by:
-
Ben Skeggs authored
commit f231976c upstream. We need to do this in order to prevent accesses to the device while it's powered down. Userspace may have an mmap of the fb, and there's no good way (that I know of) to prevent it from touching the device otherwise. This fixes some nasty races between runpm and plymouth on some systems, which result in the GPU getting very upset and hanging the boot. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Shaohua Li authored
commit 874bbfe6 upstream. My system keeps crashing with below message. vmstat_update() schedules a delayed work in current cpu and expects the work runs in the cpu. schedule_delayed_work() is expected to make delayed work run in local cpu. The problem is timer can be migrated with NO_HZ. __queue_work() queues work in timer handler, which could run in a different cpu other than where the delayed work is scheduled. The end result is the delayed work runs in different cpu. The patch makes __queue_delayed_work records local cpu earlier. Where the timer runs doesn't change where the work runs with the change. [ 28.010131] ------------[ cut here ]------------ [ 28.010609] kernel BUG at ../mm/vmstat.c:1392! [ 28.011099] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [ 28.011860] Modules linked in: [ 28.012245] CPU: 0 PID: 289 Comm: kworker/0:3 Tainted: G W4.3.0-rc3+ #634 [ 28.013065] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014 [ 28.014160] Workqueue: events vmstat_update [ 28.014571] task: ffff880117682580 ti: ffff8800ba428000 task.ti: ffff8800ba428000 [ 28.015445] RIP: 0010:[<ffffffff8115f921>] [<ffffffff8115f921>]vmstat_update+0x31/0x80 [ 28.016282] RSP: 0018:ffff8800ba42fd80 EFLAGS: 00010297 [ 28.016812] RAX: 0000000000000000 RBX: ffff88011a858dc0 RCX:0000000000000000 [ 28.017585] RDX: ffff880117682580 RSI: ffffffff81f14d8c RDI:ffffffff81f4df8d [ 28.018366] RBP: ffff8800ba42fd90 R08: 0000000000000001 R09:0000000000000000 [ 28.019169] R10: 0000000000000000 R11: 0000000000000121 R12:ffff8800baa9f640 [ 28.019947] R13: ffff88011a81e340 R14: ffff88011a823700 R15:0000000000000000 [ 28.020071] FS: 0000000000000000(0000) GS:ffff88011a800000(0000)knlGS:0000000000000000 [ 28.020071] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 28.020071] CR2: 00007ff6144b01d0 CR3: 00000000b8e93000 CR4:00000000000006f0 [ 28.020071] Stack: [ 28.020071] ffff88011a858dc0 ffff8800baa9f640 ffff8800ba42fe00ffffffff8106bd88 [ 28.020071] ffffffff8106bd0b 0000000000000096 0000000000000000ffffffff82f9b1e8 [ 28.020071] ffffffff829f0b10 0000000000000000 ffffffff81f18460ffff88011a81e340 [ 28.020071] Call Trace: [ 28.020071] [<ffffffff8106bd88>] process_one_work+0x1c8/0x540 [ 28.020071] [<ffffffff8106bd0b>] ? process_one_work+0x14b/0x540 [ 28.020071] [<ffffffff8106c214>] worker_thread+0x114/0x460 [ 28.020071] [<ffffffff8106c100>] ? process_one_work+0x540/0x540 [ 28.020071] [<ffffffff81071bf8>] kthread+0xf8/0x110 [ 28.020071] [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200 [ 28.020071] [<ffffffff81a6522f>] ret_from_fork+0x3f/0x70 [ 28.020071] [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200 Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Mika Westerberg authored
commit 56d4b8a2 upstream. ACPI SSCN/FMCN methods were originally added because then the platform can provide the most accurate HCNT/LCNT values to the driver. However, this seems not to be true for Dell Inspiron 7348 where using these causes the touchpad to fail in boot: i2c_hid i2c-DLL0675:00: failed to retrieve report from device. i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0675:00: failed to retrieve report from device. i2c_designware INT3433:00: controller timed out The values received from ACPI are (in fast mode): HCNT: 72 LCNT: 160 this translates to following timings (input clock is 100MHz on Broadwell): tHIGH: 720 ns (spec min 600 ns) tLOW: 1600 ns (spec min 1300 ns) Bus period: 2920 ns (assuming 300 ns tf and tr) Bus speed: 342.5 kHz Both tHIGH and tLOW are within the I2C specification. The calculated values when ACPI parameters are not used are (in fast mode): HCNT: 87 LCNT: 159 which translates to: tHIGH: 870 ns (spec min 600 ns) tLOW: 1590 ns (spec min 1300 ns) Bus period 3060 ns (assuming 300 ns tf and tr) Bus speed 326.8 kHz These values are also within the I2C specification. Since both ACPI and calculated values meet the I2C specification timing requirements it is hard to say why the touchpad does not function properly with the ACPI values except that the bus speed is higher in this case (but still well below the max 400kHz). Solve this by adding DMI quirk to the driver that disables using ACPI parameters on this particulare machine. Reported-by:
Pavel Roskin <plroskin@gmail.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Wolfram Sang authored
commit eadd709f upstream. The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. While here, move drvdata, too. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by:
Kukjin Kim <kgene@kernel.org> Signed-off-by:
-
Wolfram Sang authored
commit 4f7effdd upstream. The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. While here, move drvdata, too. Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Will Deacon authored
commit b6dd8e07 upstream. Commit df057cc7 ("arm64: errata: add module build workaround for erratum #843419") sets CFLAGS_MODULE to ensure that the large memory model is used by the compiler when building kernel modules. However, CFLAGS_MODULE is an environment variable and intended to be overridden on the command line, which appears to be the case with the Ubuntu kernel packaging system, so use KBUILD_CFLAGS_MODULE instead. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Fixes: df057cc7 ("arm64: errata: add module build workaround for erratum #843419") Reported-by:
Dann Frazier <dann.frazier@canonical.com> Tested-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Chris Mason authored
commit dc6c5fb3 upstream. The code for btrfs inode-resolve has never worked properly for files with enough hard links to trigger extrefs. It was trying to get the leaf out of a path after freeing the path: btrfs_release_path(path); leaf = path->nodes[0]; item_size = btrfs_item_size_nr(leaf, slot); The fix here is to use the extent buffer we cloned just a little higher up to avoid deadlocks caused by using the leaf in the path. Signed-off-by:
Chris Mason <clm@fb.com> cc: Mark Fasheh <mfasheh@suse.de> Reviewed-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
Mark Fasheh <mfasheh@suse.de> Signed-off-by:
-
Russell King authored
commit 8996eafd upstream. Unlike shash algorithms, ahash drivers must implement export and import as their descriptors may contain hardware state and cannot be exported as is. Unfortunately some ahash drivers did not provide them and end up causing crashes with algif_hash. This patch adds a check to prevent these drivers from registering ahash algorithms until they are fixed. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Dave Kleikamp authored
commit a66d7f72 upstream. Some of the crypto algorithms write to the initialization vector, but no space has been allocated for it. This clobbers adjacent memory. Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by:
-
Charles Keepax authored
[ Upstream commit 436c2a50 ] commit 3cc81d85 ("asix: Don't reset PHY on if_up for ASIX 88772") causes the ethernet on Arndale to no longer function. This appears to be because the Arndale ethernet requires a full reset before it will function correctly, however simply reverting the above patch causes problems with ethtool settings getting reset. It seems the problem is that the ethernet is not properly reset during bind, and indeed the code in ax88772_bind that resets the device is a very small subset of the actual ax88772_reset function. This patch uses ax88772_reset in place of the existing reset code in ax88772_bind which removes some code duplication and fixes the ethernet on Arndale. It is still possible that the original patch causes some issues with suspend and resume but that seems like a separate issue and I haven't had a chance to test that yet. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Tested-by:
Riku Voipio <riku.voipio@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Michel Stam authored
[ Upstream commit 3cc81d85 ] I've noticed every time the interface is set to 'up,', the kernel reports that the link speed is set to 100 Mbps/Full Duplex, even when ethtool is used to set autonegotiation to 'off', half duplex, 10 Mbps. It can be tested by: ifconfig eth0 down ethtool -s eth0 autoneg off speed 10 duplex half ifconfig eth0 up Then checking 'dmesg' for the link speed. Signed-off-by:
Michel Stam <m.stam@fugro.nl> Signed-off-by:
-
Joe Perches authored
[ Upstream commit 077cb37f ] It seems that kernel memory can leak into userspace by a kmalloc, ethtool_get_strings, then copy_to_user sequence. Avoid this by using kcalloc to zero fill the copied buffer. Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Guillaume Nault authored
[ Upstream commit e6740165 ] Since commit 2b018d57 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"), pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the following oops: [ 570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0 [ 570.142931] IP: [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0 [ 570.144601] Oops: 0000 [#1] SMP [ 570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio [ 570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1 [ 570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [ 570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000 [ 570.144601] RIP: 0010:[<ffffffffa018c701>] [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] RSP: 0018:ffff880036b63e08 EFLAGS: 00010202 [ 570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206 [ 570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20 [ 570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000 [ 570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780 [ 570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0 [ 570.144601] FS: 00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000 [ 570.144601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0 [ 570.144601] Stack: [ 570.144601] ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0 [ 570.144601] ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008 [ 570.144601] ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5 [ 570.144601] Call Trace: [ 570.144601] [<ffffffff812caabe>] sock_release+0x1a/0x75 [ 570.144601] [<ffffffff812cabad>] sock_close+0xd/0x11 [ 570.144601] [<ffffffff811347f5>] __fput+0xff/0x1a5 [ 570.144601] [<ffffffff811348cb>] ____fput+0x9/0xb [ 570.144601] [<ffffffff81056682>] task_work_run+0x66/0x90 [ 570.144601] [<ffffffff8100189e>] prepare_exit_to_usermode+0x8c/0xa7 [ 570.144601] [<ffffffff81001a26>] syscall_return_slowpath+0x16d/0x19b [ 570.144601] [<ffffffff813babb1>] int_ret_from_sys_call+0x25/0x9f [ 570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00 [ 570.144601] RIP [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] RSP <ffff880036b63e08> [ 570.144601] CR2: 00000000000004e0 [ 570.200518] ---[ end trace 46956baf17349563 ]--- pppoe_flush_dev() has no reason to override sk->sk_state with PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to PPPOX_DEAD, which is the correct state given that sk is unbound and po->pppoe_dev is NULL. Fixes: 2b018d57 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release") Tested-by:
Oleksii Berezhniak <core@irc.lg.ua> Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit c7c49b8f ] Greg reported crashes hitting the following check in __sk_backlog_rcv() BUG_ON(!sock_flag(sk, SOCK_MEMALLOC)); The pfmemalloc bit is currently checked in sk_filter(). This works correctly for TCP, because sk_filter() is ran in tcp_v[46]_rcv() before hitting the prequeue or backlog checks. For UDP or other protocols, this does not work, because the sk_filter() is ran from sock_queue_rcv_skb(), which might be called _after_ backlog queuing if socket is owned by user by the time packet is processed by softirq handler. Fixes: b4b9e355 ("netvm: set PF_MEMALLOC as appropriate during SKB processing") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Greg Thelen <gthelen@google.com> Signed-off-by:
-
Pravin B Shelar authored
[ Upstream commit 31b33dfb ] Earlier patch 6ae459bd tried to detect void ckecksum partial skb by comparing pull length to checksum offset. But it does not work for all cases since checksum-offset depends on updates to skb->data. Following patch fixes it by validating checksum start offset after skb-data pointer is updated. Negative value of checksum offset start means there is no need to checksum. Fixes: 6ae459bd ("skbuff: Fix skb checksum flag on skb pull") Reported-by:
Andrew Vagin <avagin@odin.com> Signed-off-by:
Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
