- 24 Feb, 2015 15 commits
-
-
Jiri Kosina authored
commit 8e7b3410 upstream. The ignore check that got added in 6ce901eb ("HID: input: fix confusion on conflicting mappings") needs to properly check for VARIABLE reports as well (ARRAY reports should be ignored), otherwise legitimate keyboards might break. Fixes: 6ce901eb ("HID: input: fix confusion on conflicting mappings") Reported-by:
Fredrik Hallenberg <megahallon@gmail.com> Reported-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
David Herrmann authored
commit 6ce901eb upstream. On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its neighbours look like this: +---+ +---+ +-------+ | 1 | | 2 | | 5 | +---+ +---+ +-------+ +---+ +-----------+ | 3 | | 4 | +---+ +-----------+ On a PC-102/105 keyboard (European layout) it looks like this: +---+ +---+ +-------+ | 1 | | 2 | | | +---+ +---+ +-+ 4 | +---+ +---+ | | | 3 | | 5 | | | +---+ +---+ +-----+ (Note that the number of keys is the same, but key '5' is moved down and the shape of key '4' is changed. Keys '1' to '3' are exactly the same.) The keys 1-4 report the same scan-code in HID in both layouts, even though the keysym they produce is usually different depending on the XKB-keymap used by user-space. However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout and 0x32 for the lower layout, as defined by the HID spec. This is highly confusing as the linux-input API uses a single keycode for both. So far, this was never a problem as there never has been a keyboard with both of those keys present at the same time. It would have to look something like this: +---+ +---+ +-------+ | 1 | | 2 | | x31 | +---+ +---+ +-------+ +---+ +---+ +-----+ | 3 | |x32| | 4 | +---+ +---+ +-----+ HID can represent such a keyboard, but the linux-input API cannot. Furthermore, any user-space mapping would be confused by this and, luckily, no-one ever produced such hardware. Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys is present on a hardware, this works just fine. Lets introduce hardware-vendors into this: ------------------------------------------ Unfortunately, it seems way to expensive to produce a different device for American and European layouts. Therefore, hardware-vendors put both keys, (0x31 and 0x32) on the same keyboard, but only one of them is hooked up to the physical button, the other one is 'dead'. This means, they can use the same hardware, with a different button-layout and automatically produce the correct HID events for American *and* European layouts. This is unproblematic for normal keyboards, as the 'dead' key will never report any KEY-DOWN events. But RollOver keyboards send the whole matrix on each key-event, allowing n-key roll-over mode. This means, we get a 0x31 and 0x32 event on each key-press. One of them will always be 0, the other reports the real state. As we map both to the same keycode, we will get spurious key-events, even though the real key-state never changed. The easiest way would be to blacklist 'dead' keys and never handle those. We could simply read the 'country' tag of USB devices and blacklist either key according to the layout. But... hardware vendors... want the same device for all countries and thus many of them set 'country' to 0 for all devices. Meh.. So we have to deal with this properly. As we cannot know which of the keys is 'dead', we either need a heuristic and track those keys, or we simply make use of our value-tracking for HID fields. We simply ignore HID events for absolute data if the data didn't change. As HID tracks events on the HID level, we haven't done the keycode translation, yet. Therefore, the 'dead' key is tracked independently of the real key, therefore, any events on it will be ignored. This patch simply discards any HID events for absolute data if it didn't change compared to the last report. We need to ignore relative and buffered-byte reports for obvious reasons. But those cannot be affected by this bug, so we're fine. Preferably, we'd do this filtering on the HID-core level. But this might break a lot of custom drivers, if they do not follow the HID specs. Therefore, we do this late in hid-input just before we inject it into the input layer (which does the exact same filtering, but on the keycode level). If this turns out to break some devices, we might have to limit filtering to EV_KEY events. But lets try to do the Right Thing first, and properly filter any absolute data that didn't change. This patch is tagged for 'stable' as it fixes a lot of n-key RollOver hardware. We might wanna wait with backporting for a while, before we know it doesn't break anything else, though. Reported-by:
Adam Goode <adam@spicenitz.org> Reported-by:
-
Martin Vajnar authored
commit a52d2093 upstream. Since the removal of CONFIG_REGULATOR_DUMMY option, the touchscreen stopped working. This patch enables the "replacement" for REGULATOR_DUMMY and allows the touchscreen to work even though there is no regulator for "vcc". Signed-off-by:
Martin Vajnar <martin.vajnar@gmail.com> Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit baad2dc4 upstream. Add regulator_has_full_constraints() call to spitz board file to let regulator core know that we do not have any additional regulators left. This lets it substitute unprovided regulators with dummy ones. This fixes the following warnings that can be seen on spitz if regulators are enabled: ads7846 spi2.0: unable to get regulator: -517 spi spi2.0: Driver ads7846 requests probe deferral Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit 9bc78f32 upstream. Add regulator_has_full_constraints() call to poodle board file to let regulator core know that we do not have any additional regulators left. This lets it substitute unprovided regulators with dummy ones. This fixes the following warnings that can be seen on poodle if regulators are enabled: ads7846 spi1.0: unable to get regulator: -517 spi spi1.0: Driver ads7846 requests probe deferral wm8731 0-001b: Failed to get supply 'AVDD': -517 wm8731 0-001b: Failed to request supplies: -517 wm8731 0-001b: ASoC: failed to probe component -517 Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit 271e8017 upstream. Add regulator_has_full_constraints() call to corgi board file to let regulator core know that we do not have any additional regulators left. This lets it substitute unprovided regulators with dummy ones. This fixes the following warnings that can be seen on corgi if regulators are enabled: ads7846 spi1.0: unable to get regulator: -517 spi spi1.0: Driver ads7846 requests probe deferral wm8731 0-001b: Failed to get supply 'AVDD': -517 wm8731 0-001b: Failed to request supplies: -517 wm8731 0-001b: ASoC: failed to probe component -517 corgi-audio corgi-audio: ASoC: failed to instantiate card -517 Signed-off-by:
-
Russell King authored
commit 32e63f03 upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-video. Fix these. Fixes: a61f6811 ("[media] em28xx-video: implement em28xx_ops: suspend/resume hooks") Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Russell King authored
commit a084c57f upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-dvb. Fix these. Fixes: ca2b46da ("[media] em28xx-dvb: implement em28xx_ops: suspend/resume hooks") Signed-off-by:
-
Russell King authored
commit fbaa48d1 upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-audio. Fix these. Fixes: 6d746f91 ("[media] em28xx-audio: implement em28xx_ops: suspend/resume hooks") Signed-off-by:
-
Russell King authored
commit 7818b0aa upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-audio. Fix these. Fixes: 1b3fd2d3 ("[media] em28xx-audio: don't hardcode audio URB calculus") Signed-off-by:
-
Russell King authored
commit 522adc7c upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-core. Fix these. Fixes: 9c669b73 ("[media] em28xx: add suspend/resume to em28xx_ops") Signed-off-by:
-
Russell King authored
commit ebfd59cf upstream. Inspection shows that newlines are missing from several kernel messages in em28xx-input. Fix these. Fixes: 5025076a ("[media] em28xx-input: implement em28xx_ops: suspend/resume hooks") Signed-off-by:
-
Russell King authored
commit 0418ca60 upstream. The lockdep splat addressed in a previous commit revealed that at least one message in em28xx-input.c was missing a new line: em28178 #0: Closing input extensionINFO: trying to register non-static key. Further inspection shows several other messages also miss a new line. These will be fixed in a subsequent patch. Fixes: aa929ad7 ("[media] em28xx: print a message at disconnect") Signed-off-by:
-
Russell King authored
commit bbfebeea upstream. Removing the em28xx-rc module results in the following lockdep splat, which is caused by trying to call cancel_delayed_work_sync() on an uninitialised delayed work. Fix this by ensuring we always initialise the work. INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 2183 Comm: rmmod Not tainted 3.18.0+ #1464 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<c0012228>] (dump_backtrace) from [<c00123c0>] (show_stack+0x18/0x1c) r6:c1419d2c r5:00000000 r4:00000000 r3:00000000 [<c00123a8>] (show_stack) from [<c06e2550>] (dump_stack+0x7c/0x98) [<c06e24d4>] (dump_stack) from [<c0061c94>] (__lock_acquire+0x16d4/0x1bb0) r4:edf19f74 r3:df049380 [<c00605c0>] (__lock_acquire) from [<c00626d4>] (lock_acquire+0xb0/0x124) r10:00000000 r9:c003ba90 r8:00000000 r7:00000000 r6:00000000 r5:edf19f74 r4:00000000 [<c0062624>] (lock_acquire) from [<c003bad4>] (flush_work+0x44/0x264) r10:00000000 r9:eaa86000 r8:edf190b0 r7:edf19f74 r6:00000001 r5:edf19f64 r4:00000000 [<c003ba90>] (flush_work) from [<c003d8f0>] (__cancel_work_timer+0x8c/0x124) r7:00000000 r6:00000001 r5:00000000 r4:edf19f64 [<c003d864>] (__cancel_work_timer) from [<c003d99c>] (cancel_delayed_work_sync+0x14/0x18) r7:00000000 r6:eccc3600 r5:00000000 r4:edf19000 [<c003d988>] (cancel_delayed_work_sync) from [<bf0b5c10>] (em28xx_ir_fini+0x48/0xd8 [em28xx_rc]) [<bf0b5bc8>] (em28xx_ir_fini [em28xx_rc]) from [<bf08a0a8>] (em28xx_unregister_extension+0x40/0x94 [em28xx]) r8:c000edc4 r7:00000081 r6:bf092bf4 r5:bf0b6a2c r4:edf19000 r3:bf0b5bc8 [<bf08a068>] (em28xx_unregister_extension [em28xx]) from [<bf0b64dc>] (em28xx_rc_unregister+0x14/0x1c [em28xx_rc]) r6:00000800 r5:00000000 r4:bf0b6a50 r3:bf0b64c8 [<bf0b64c8>] (em28xx_rc_unregister [em28xx_rc]) from [<c0096710>] (SyS_delete_module+0x11c/0x180) [<c00965f4>] (SyS_delete_module) from [<c000ec00>] (ret_fast_syscall+0x0/0x48) r6:00000001 r5:beb0f813 r4:b8b17d00 Fixes: f5222609 ("[media] em28xx: extend the support for device buttons") Signed-off-by:
-
Luis Henriques authored
Signed-off-by:
-
- 19 Feb, 2015 2 commits
-
-
Michael S. Tsirkin authored
commit a1eb03f5 upstream. The reason we defer kfree until release function is because it's a general rule for kobjects: kfree of the reference counter itself is only legal in the release function. Previous patch didn't make this clear, document this in code. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> [ luis: backported to 3.16: - file rename: virtio_pci_legacy.c -> virtio_pci.c ] Signed-off-by:
-
Sasha Levin authored
commit 63bd62a0 upstream. A struct device which has just been unregistered can live on past the point at which a driver decides to drop it's initial reference to the kobject gained on allocation. This implies that when releasing a virtio device, we can't free a struct virtio_device until the underlying struct device has been released, which might not happen immediately on device_unregister(). Unfortunately, this is exactly what virtio pci does: it has an empty release callback, and frees memory immediately after unregistering the device. This causes an easy to reproduce crash if CONFIG_DEBUG_KOBJECT_RELEASE it enabled. To fix, free the memory only once we know the device is gone in the release callback. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
- 18 Feb, 2015 1 commit
-
-
Ani Sinha authored
commit 6a2a2b3a upstream. Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will break old binaries and any code for which there is no access to source code. To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland. Signed-off-by:
Ani Sinha <ani@arista.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by:
-
- 17 Feb, 2015 4 commits
-
-
Anantha Krishnan authored
commit 4b552bc9 upstream. Add support for the QCA6174 chip. T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e078 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
Anantha Krishnan <ananthk@codeaurora.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Janne Heikkinen authored
commit 134d3b35 upstream. Asus X553MA has USB device 04ca:3010 that is Atheros AR3012 or compatible. Device from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 27 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3010 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Janne Heikkinen <janne.m.heikkinen@gmail.com> Signed-off-by:
-
Thomas Hellstrom authored
commit 1f563a6a upstream. Kernel side fence objects are used when unbinding resources and may thus be created as part of a memory reclaim operation. This might trigger recursive memory reclaims and result in the kernel running out of stack space. So a simple way out is to avoid accounting of these fence objects. In principle this is OK since while user-space can trigger the creation of such objects, it can't really hold on to them. However, their lifetime is quite long, so some form of accounting should perhaps be implemented in the future. Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 with low system memory settings. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
Yan, Zheng authored
commit 97c85a82 upstream. Current snaphost code does not properly handle moving inode from one empty snap realm to another empty snap realm. After changing inode's snap realm, some dirty pages' snap context can be not equal to inode's i_head_snap. This can trigger BUG() in ceph_put_wrbuffer_cap_refs() The fix is introduce a global empty snap context for all empty snap realm. This avoids triggering the BUG() for filesystem with no snapshot. Fixes: http://tracker.ceph.com/issues/9928Signed-off-by:
Yan, Zheng <zyan@redhat.com> Reviewed-by:
Ilya Dryomov <idryomov@redhat.com> Cc: Markus Blank-Burian <burian@muenster.de> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
- 16 Feb, 2015 12 commits
-
-
Adrian Hunter authored
commit 7147eaf3 upstream. Add a HID (INT33BB) and UID (3) for a SD Card host controller. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Maurice Petallo authored
commit d61b5946 upstream. "SDHCI_QUIRK2_PRESET_VALUE_BROKEN" quirk is added to prohibit preset value enabling for Baytrail eMMC controller. Signed-off-by:
Maurice Petallo <mauricex.r.petallo@intel.com> Acked-by:
-
Adrian Hunter authored
commit d0ed8e6b upstream. Add ACPI HID INT344D for an Intel SDIO host controller. Signed-off-by:
-
Adrian Hunter authored
commit 1f7f2652 upstream. Add PCI IDs for SPT eMMC, SDIO and SD card. Signed-off-by:
-
Adrian Hunter authored
commit a06586b6 upstream. Braswell eMMC host controller specifies an incorrect timeout clock frequncy in the capabilities registers. The correct value is 1 MHz. Signed-off-by:
-
Alan Cox authored
commit 066173b6 upstream. The hardware is the same as used in Baytrail. Add these new PCI IDs to the driver's list of supported IDs. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Adam Lee authored
commit c561a575 upstream. BugLink: https://bugs.launchpad.net/bugs/1400215 ath3k devices fail to load firmwares on xHCI buses, but work well on EHCI, this might be a compatibility issue between xHCI and ath3k chips. As my testing result, those chips will work on xHCI buses again with this patch. This workaround is from Qualcomm, they also did some workarounds in Windows driver. Signed-off-by:
Adam Lee <adam.lee@canonical.com> Signed-off-by:
-
Austin Lund authored
commit a8f29e89 upstream. Userspace expects to see a long space before the first pulse is sent on the lirc device. Currently, if a long time has passed and a new packet is started, the lirc codec just returns and doesn't send anything. This makes lircd ignore many perfectly valid signals unless they are sent in quick sucession. When a reset event is delivered, we cannot know anything about the duration of the space. But it should be safe to assume it has been a long time and we just set the duration to maximum. Signed-off-by:
Austin Lund <austin.lund@gmail.com> Signed-off-by:
-
Marcelo Tosatti authored
commit 7f187922 upstream. When the guest writes to the TSC, the masterclock TSC copy must be updated as well along with the TSC_OFFSET update, otherwise a negative tsc_timestamp is calculated at kvm_guest_time_update. Once "if (!vcpus_matched && ka->use_master_clock)" is simplified to "if (ka->use_master_clock)", the corresponding "if (!ka->use_master_clock)" becomes redundant, so remove the do_request boolean and collapse everything into a single condition. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Hui Wang authored
commit 2c609999 upstream. Cc: David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
David Henningsson authored
commit 42304474 upstream. This makes the mute LED work on a HP 15 touchsmart machine. BugLink: https://bugs.launchpad.net/bugs/1334950Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Linus Torvalds authored
commit 7fb08eca upstream. This replaces four copies in various stages of mm_fault_error() handling with just a single one. It will also allow for more natural placement of the unlocking after some further cleanup. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
-
- 10 Feb, 2015 6 commits
-
-
Haiyang Zhang authored
commit d953ca4d upstream. The existing code frees the skb in EAGAIN case, in which the skb will be retried from upper layer and used again. Also, the existing code doesn't free send buffer slot in error case, because there is no completion message for unsent packets. This patch fixes these problems. (Please also include this patch for stable trees. Thanks!) Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Saran Maruti Ramanara authored
commit cfbf654e upstream. When making use of RFC5061, section 4.2.4. for setting the primary IP address, we're passing a wrong parameter header to param_type2af(), resulting always in NULL being returned. At this point, param.p points to a sctp_addip_param struct, containing a sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation id. Followed by that, as also presented in RFC5061 section 4.2.4., comes the actual sctp_addr_param, which also contains a sctp_paramhdr, but this time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that param_type2af() can make use of. Since we already hold a pointer to addr_param from previous line, just reuse it for param_type2af(). Fixes: d6de3097 ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT") Signed-off-by:
Saran Maruti Ramanara <saran.neti@telus.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Florian Westphal authored
commit e2a4800e upstream. When we've run out of space in the output buffer to store more data, we will call zlib_deflate with a NULL output buffer until we've consumed remaining input. When this happens, olen contains the size the output buffer would have consumed iff we'd have had enough room. This can later cause skb_over_panic when ppp_generic skb_put()s the returned length. Reported-by:
Iain Douglas <centos@1n6.org.uk> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Eric Dumazet authored
commit bdbbb852 upstream. In commit be9f4a44 ("ipv4: tcp: remove per net tcp_sock") I tried to address contention on a socket lock, but the solution I chose was horrible : commit 3a7c384f ("ipv4: tcp: unicast_sock should not land outside of TCP stack") addressed a selinux regression. commit 0980e56e ("ipv4: tcp: set unicast_sock uc_ttl to -1") took care of another regression. commit b5ec8eea ("ipv4: fix ip_send_skb()") fixed another regression. commit 811230cd ("tcp: ipv4: initialize unicast_sock sk_pacing_rate") was another shot in the dark. Really, just use a proper socket per cpu, and remove the skb_orphan() call, to re-enable flow control. This solves a serious problem with FQ packet scheduler when used in hostile environments, as we do not want to allocate a flow structure for every RST packet sent in response to a spoofed packet. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
commit 811230cd upstream. When I added sk_pacing_rate field, I forgot to initialize its value in the per cpu unicast_sock used in ip_send_unicast_reply() This means that for sch_fq users, RST packets, or ACK packets sent on behalf of TIME_WAIT sockets might be sent to slowly or even dropped once we reach the per flow limit. Signed-off-by:
-
Roopa Prabhu authored
commit 59ccaaaa upstream. Reported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081 This patch avoids calling rtnl_notify if the device ndo_bridge_getlink handler does not return any bytes in the skb. Alternately, the skb->len check can be moved inside rtnl_notify. For the bridge vlan case described in 92081, there is also a fix needed in bridge driver to generate a proper notification. Will fix that in subsequent patch. v2: rebase patch on net tree Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
