- 16 Mar, 2016 12 commits
-
-
Thomas Betker authored
commit 157078f6 upstream. This reverts commit 5ffd3412 ("jffs2: Fix lock acquisition order bug in jffs2_write_begin"). The commit modified jffs2_write_begin() to remove a deadlock with jffs2_garbage_collect_live(), but this introduced new deadlocks found by multiple users. page_lock() actually has to be called before mutex_lock(&c->alloc_sem) or mutex_lock(&f->sem) because jffs2_write_end() and jffs2_readpage() are called with the page locked, and they acquire c->alloc_sem and f->sem, resp. In other words, the lock order in jffs2_write_begin() was correct, and it is the jffs2_garbage_collect_live() path that has to be changed. Revert the commit to get rid of the new deadlocks, and to clear the way for a better fix of the original deadlock. Reported-by:
Deng Chao <deng.chao1@zte.com.cn> Reported-by:
Ming Liu <liu.ming50@gmail.com> Reported-by:
wangzaiwei <wangzaiwei@top-vision.cn> Signed-off-by:
Thomas Betker <thomas.betker@rohde-schwarz.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Peter Chen authored
commit d144dfea upstream. If we use USB ID pin as wakeup source, and there is a USB block device on this USB OTG (ID) cable, the system will be deadlock after system resume. The root cause for this problem is: the workqueue ci_otg may try to remove hcd before the driver resume has finished, and hcd will disconnect the device on it, then, it will call device_release_driver, and holds the device lock "dev->mutex", but it is never unlocked since it waits workqueue writeback to run to flush the block information, but the workqueue writeback is freezable, it is not thawed before driver resume has finished. When the driver (device: sd 0:0:0:0:) resume goes to dpm_complete, it tries to get its device lock "dev->mutex", but it can't get it forever, then the deadlock occurs. Below call stacks show the situation. So, in order to fix this problem, we need to change workqueue ci_otg as freezable, then the work item in this workqueue will be run after driver's resume, this workqueue will not be blocked forever like above case since the workqueue writeback has been thawed too. Tested at: i.mx6qdl-sabresd and i.mx6sx-sdb. [ 555.178869] kworker/u2:13 D c07de74c 0 826 2 0x00000000 [ 555.185310] Workqueue: ci_otg ci_otg_work [ 555.189353] Backtrace: [ 555.191849] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0) [ 555.198912] r10:ee471ba0 r9:00000000 r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 [ 555.206867] r4:ee470000 [ 555.209453] [<c07dec24>] (schedule) from [<c07e2fc4>] (schedule_timeout+0x15c/0x1e0) [ 555.217212] r4:7fffffff r3:edc2b000 [ 555.220862] [<c07e2e68>] (schedule_timeout) from [<c07df6c8>] (wait_for_common+0x94/0x144) [ 555.229140] r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 r4:7fffffff [ 555.235980] [<c07df634>] (wait_for_common) from [<c07df790>] (wait_for_completion+0x18/0x1c) [ 555.244430] r10:00000001 r9:c0b5563c r8:c0042e48 r7:ef086000 r6:eea4372c r5:ef131b00 [ 555.252383] r4:00000000 [ 555.254970] [<c07df778>] (wait_for_completion) from [<c0043cb8>] (flush_work+0x19c/0x234) [ 555.263177] [<c0043b1c>] (flush_work) from [<c0043fac>] (flush_delayed_work+0x48/0x4c) [ 555.271106] r8:ed5b5000 r7:c0b38a3c r6:eea439cc r5:eea4372c r4:eea4372c [ 555.277958] [<c0043f64>] (flush_delayed_work) from [<c00eae18>] (bdi_unregister+0x84/0xec) [ 555.286236] r4:eea43520 r3:20000153 [ 555.289885] [<c00ead94>] (bdi_unregister) from [<c02c2154>] (blk_cleanup_queue+0x180/0x29c) [ 555.298250] r5:eea43808 r4:eea43400 [ 555.301909] [<c02c1fd4>] (blk_cleanup_queue) from [<c0417914>] (__scsi_remove_device+0x48/0xb8) [ 555.310623] r7:00000000 r6:20000153 r5:ededa950 r4:ededa800 [ 555.316403] [<c04178cc>] (__scsi_remove_device) from [<c0415e90>] (scsi_forget_host+0x64/0x68) [ 555.325028] r5:ededa800 r4:ed5b5000 [ 555.328689] [<c0415e2c>] (scsi_forget_host) from [<c0409828>] (scsi_remove_host+0x78/0x104) [ 555.337054] r5:ed5b5068 r4:ed5b5000 [ 555.340709] [<c04097b0>] (scsi_remove_host) from [<c04cdfcc>] (usb_stor_disconnect+0x50/0xb4) [ 555.349247] r6:ed5b56e4 r5:ed5b5818 r4:ed5b5690 r3:00000008 [ 555.355025] [<c04cdf7c>] (usb_stor_disconnect) from [<c04b3bc8>] (usb_unbind_interface+0x78/0x25c) [ 555.363997] r8:c13919b4 r7:edd3c000 r6:edd3c020 r5:ee551c68 r4:ee551c00 r3:c04cdf7c [ 555.371892] [<c04b3b50>] (usb_unbind_interface) from [<c03dc248>] (__device_release_driver+0x8c/0x118) [ 555.381213] r10:00000001 r9:edd90c00 r8:c13919b4 r7:ee551c68 r6:c0b546e0 r5:c0b5563c [ 555.389167] r4:edd3c020 [ 555.391752] [<c03dc1bc>] (__device_release_driver) from [<c03dc2fc>] (device_release_driver+0x28/0x34) [ 555.401071] r5:edd3c020 r4:edd3c054 [ 555.404721] [<c03dc2d4>] (device_release_driver) from [<c03db304>] (bus_remove_device+0xe0/0x110) [ 555.413607] r5:edd3c020 r4:ef17f04c [ 555.417253] [<c03db224>] (bus_remove_device) from [<c03d8128>] (device_del+0x114/0x21c) [ 555.425270] r6:edd3c028 r5:edd3c020 r4:ee551c00 r3:00000000 [ 555.431045] [<c03d8014>] (device_del) from [<c04b1560>] (usb_disable_device+0xa4/0x1e8) [ 555.439061] r8:edd3c000 r7:eded8000 r6:00000000 r5:00000001 r4:ee551c00 [ 555.445906] [<c04b14bc>] (usb_disable_device) from [<c04a8e54>] (usb_disconnect+0x74/0x224) [ 555.454271] r9:edd90c00 r8:ee551000 r7:ee551c68 r6:ee551c9c r5:ee551c00 r4:00000001 [ 555.462156] [<c04a8de0>] (usb_disconnect) from [<c04a8fb8>] (usb_disconnect+0x1d8/0x224) [ 555.470259] r10:00000001 r9:edd90000 r8:ee471e2c r7:ee551468 r6:ee55149c r5:ee551400 [ 555.478213] r4:00000001 [ 555.480797] [<c04a8de0>] (usb_disconnect) from [<c04ae5ec>] (usb_remove_hcd+0xa0/0x1ac) [ 555.488813] r10:00000001 r9:ee471eb0 r8:00000000 r7:ef3d9500 r6:eded810c r5:eded80b0 [ 555.496765] r4:eded8000 [ 555.499351] [<c04ae54c>] (usb_remove_hcd) from [<c04d4158>] (host_stop+0x28/0x64) [ 555.506847] r6:eeb50010 r5:eded8000 r4:eeb51010 [ 555.511563] [<c04d4130>] (host_stop) from [<c04d09b8>] (ci_otg_work+0xc4/0x124) [ 555.518885] r6:00000001 r5:eeb50010 r4:eeb502a0 r3:c04d4130 [ 555.524665] [<c04d08f4>] (ci_otg_work) from [<c00454f0>] (process_one_work+0x194/0x420) [ 555.532682] r6:ef086000 r5:eeb502a0 r4:edc44480 [ 555.537393] [<c004535c>] (process_one_work) from [<c00457b0>] (worker_thread+0x34/0x514) [ 555.545496] r10:edc44480 r9:ef086000 r8:c0b1a100 r7:ef086034 r6:00000088 r5:edc44498 [ 555.553450] r4:ef086000 [ 555.556032] [<c004577c>] (worker_thread) from [<c004bab4>] (kthread+0xdc/0xf8) [ 555.563268] r10:00000000 r9:00000000 r8:00000000 r7:c004577c r6:edc44480 r5:eddc15c0 [ 555.571221] r4:00000000 [ 555.573804] [<c004b9d8>] (kthread) from [<c000fef0>] (ret_from_fork+0x14/0x24) [ 555.581040] r7:00000000 r6:00000000 r5:c004b9d8 r4:eddc15c0 [ 553.429383] sh D c07de74c 0 694 691 0x00000000 [ 553.435801] Backtrace: [ 553.438295] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0) [ 553.445358] r10:edd3c054 r9:edd3c078 r8:edddbd50 r7:edcbbc00 r6:c1377c34 r5:60000153 [ 553.453313] r4:eddda000 [ 553.455896] [<c07dec24>] (schedule) from [<c07deff8>] (schedule_preempt_disabled+0x10/0x14) [ 553.464261] r4:edd3c058 r3:0000000a [ 553.467910] [<c07defe8>] (schedule_preempt_disabled) from [<c07e0bbc>] (mutex_lock_nested+0x1a0/0x3e8) [ 553.477254] [<c07e0a1c>] (mutex_lock_nested) from [<c03e927c>] (dpm_complete+0xc0/0x1b0) [ 553.485358] r10:00561408 r9:edd3c054 r8:c0b4863c r7:edddbd90 r6:c0b485d8 r5:edd3c020 [ 553.493313] r4:edd3c0d0 [ 553.495896] [<c03e91bc>] (dpm_complete) from [<c03e9388>] (dpm_resume_end+0x1c/0x20) [ 553.503652] r9:00000000 r8:c0b1a9d0 r7:c1334ec0 r6:c1334edc r5:00000003 r4:00000010 [ 553.511544] [<c03e936c>] (dpm_resume_end) from [<c0079894>] (suspend_devices_and_enter+0x158/0x504) [ 553.520604] r4:00000000 r3:c1334efc [ 553.524250] [<c007973c>] (suspend_devices_and_enter) from [<c0079e74>] (pm_suspend+0x234/0x2cc) [ 553.532961] r10:00561408 r9:ed6b7300 r8:00000004 r7:c1334eec r6:00000000 r5:c1334ee8 [ 553.540914] r4:00000003 [ 553.543493] [<c0079c40>] (pm_suspend) from [<c0078a6c>] (state_store+0x6c/0xc0) [ 555.703684] 7 locks held by kworker/u2:13/826: [ 555.708140] #0: ("%s""ci_otg"){++++.+}, at: [<c0045484>] process_one_work+0x128/0x420 [ 555.716277] #1: ((&ci->work)){+.+.+.}, at: [<c0045484>] process_one_work+0x128/0x420 [ 555.724317] #2: (usb_bus_list_lock){+.+.+.}, at: [<c04ae5e4>] usb_remove_hcd+0x98/0x1ac [ 555.732626] #3: (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224 [ 555.740403] #4: (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224 [ 555.748179] #5: (&dev->mutex){......}, at: [<c03dc2f4>] device_release_driver+0x20/0x34 [ 555.756487] #6: (&shost->scan_mutex){+.+.+.}, at: [<c04097d0>] scsi_remove_host+0x20/0x104 Cc: Jun Li <jun.li@nxp.com> Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Felix Fietkau authored
commit 7a36b930 upstream. The value 5000 was put here with the addition of the timeout field to ieee80211_start_tx_ba_session. It was originally added in mac80211 to save resources for drivers like iwlwifi, which only supports a limited number of concurrent aggregation sessions. Since iwlwifi does not use minstrel_ht and other drivers don't need this, 0 is a better default - especially since there have been recent reports of aggregation setup related issues reproduced with ath9k. This should improve stability without causing any adverse effects. Acked-by:
Avery Pennarun <apenwarr@gmail.com> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Alexandra Yates authored
commit f5bdd66c upstream. This patch complements the list of device IDs previously added for lewisburg sata. Signed-off-by:
Alexandra Yates <alexandra.yates@linux.intel.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Alexandra Yates authored
commit 4d92f009 upstream. This change was to preserve the ascending order of device IDs. There was an exception with the first two Lewisburg device IDs to keep all device IDs of the same kind grouped by code name. Signed-off-by:
-
Alexandra Yates authored
commit 56e74338 upstream. Adding Intel codename Lewisburg platform device IDs for SATA. Signed-off-by:
-
Hans Verkuil authored
commit 0ba4581c upstream. The 5 volt detect functionality broke in 3.14: the code reads IO register 0x70 again after it has already been cleared. Instead it should use the cached irq_reg_0x70 value and the io_write to 0x71 to clear 0x70 can be dropped since this has already been done. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Liad Kaufman authored
commit fb896c44 upstream. Until this patch, when TXing non-sta the pending_frames counter wasn't increased, but it WAS decreased in iwl_mvm_rx_tx_cmd_single(), what makes it negative in certain conditions. This in turn caused much trouble when we need to remove the station since we won't be waiting forever until pending_frames gets 0. In certain cases, we were exhausting the station table even in BSS mode, because we had a lot of stale stations. Increase the counter also in iwl_mvm_tx_skb_non_sta() after a successful TX to avoid this outcome. Signed-off-by:
Liad Kaufman <liad.kaufman@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> [ kamal: backport to 4.2: file rename ] Signed-off-by:
-
Arnd Bergmann authored
commit 287e6611 upstream. As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not work correctly in compat mode with libata. I have investigated the issue further and found multiple problems that all appeared with the same commit that originally introduced HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy a 'long' variable containing either 0 or 1 to user space. The problems with this are: * On big-endian machines, this will always write a zero because it stores the wrong byte into user space. * In compat mode, the upper three bytes of the variable are updated by the compat_hdio_ioctl() function, but they now contain uninitialized stack data. * The hdparm tool calling this ioctl uses a 'static long' variable to store the result. This means at least the upper bytes are initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT would fill them with data that remains stale when the low byte is overwritten. Fortunately libata doesn't implement any of the affected ioctl commands, so this would only happen when we query both an IDE and an ATA device in the same command such as "hdparm -N -c /dev/hda /dev/sda" * The libata code for unknown reasons started using ATA_IOC_GET_IO32 and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT, while the ioctl commands that were added later use the normal HDIO_* names. This is harmless but rather confusing. This addresses all four issues by changing the code to use put_user() on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem does, and by clarifying the names of the ioctl commands. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reported-by:
Soohoon Lee <Soohoon.Lee@f5.com> Tested-by:
-
Chris Bainbridge authored
commit f39ea269 upstream. Use kzalloc instead of kmalloc for struct tid_ampdu_rx to initialize the "removed" field (all others are initialized manually). That fixes: UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29 load of value 2 is not a valid value for type '_Bool' CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265 Workqueue: phy0 rt2x00usb_work_rxdone 0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007 ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500 ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032 Call Trace: [<ffffffff8181d866>] dump_stack+0x45/0x5f [<ffffffff8188422d>] ubsan_epilogue+0xd/0x40 [<ffffffff81884747>] __ubsan_handle_load_invalid_value+0x67/0x70 [<ffffffff82227b4d>] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730 [<ffffffff8222ca14>] ieee80211_prepare_and_rx_handle+0xd04/0x1c00 [<ffffffff8222db03>] __ieee80211_rx_handle_packet+0x1f3/0x750 [<ffffffff8222e4a7>] ieee80211_rx_napi+0x447/0x990 While at it, convert to use sizeof(*tid_agg_rx) instead. Fixes: 788211d8 ("mac80211: fix RX A-MPDU session reorder timer deletion") Signed-off-by:
Chris Bainbridge <chris.bainbridge@gmail.com> [reword commit message, use sizeof(*tid_agg_rx)] Signed-off-by:
-
Johannes Berg authored
commit cb150b9d upstream. Since cfg80211 frequently takes actions from its netdev notifier call, wireless extensions messages could still be ordered badly since the wext netdev notifier, since wext is built into the kernel, runs before the cfg80211 netdev notifier. For example, the following can happen: 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff 5: wlan1: <BROADCAST,MULTICAST,UP> link/ether when setting the interface down causes the wext message. To also fix this, export the wireless_nlevent_flush() function and also call it from the cfg80211 notifier. Signed-off-by:
-
Johannes Berg authored
commit 8bf86273 upstream. Beniamino reported that he was getting an RTM_NEWLINK message for a given interface, after the RTM_DELLINK for it. It turns out that the message is a wireless extensions message, which was sent because the interface had been connected and disconnection while it was deleted caused a wext message. For its netlink messages, wext uses RTM_NEWLINK, but the message is without all the regular rtnetlink attributes, so "ip monitor link" prints just rudimentary information: 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff Deleted 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff 5: wlan1: <BROADCAST,MULTICAST,UP> link/ether (from my hwsim reproduction) This can cause userspace to get confused since it doesn't expect an RTM_NEWLINK message after RTM_DELLINK. The reason for this is that wext schedules a worker to send out the messages, and the scheduling delay can cause the messages to get out to userspace in different order. To fix this, have wext register a netdevice notifier and flush out any pending messages when netdevice state changes. This fixes any ordering whenever the original message wasn't sent by a notifier itself. Reported-by:
Beniamino Galvani <bgalvani@redhat.com> Signed-off-by:
-
- 15 Mar, 2016 2 commits
-
-
Vladis Dronov authored
commit 8e20cf2b upstream. The aiptek driver crashes in aiptek_probe() when a specially crafted USB device without endpoints is detected. This fix adds a check that the device has proper configuration expected by the driver. Also an error return value is changed to more matching one in one of the error paths. Reported-by:
Ralf Spenneberg <ralf@spenneberg.net> Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
In Linus's tree, the iovec code has been reworked massively, but in older kernels the AIO layer should be checking this before passing the request on to other layers. Many thanks to Ben Hawkes of Google Project Zero for pointing out the issue. Reported-by:
Ben Hawkes <hawkes@google.com> Acked-by:
Benjamin LaHaise <bcrl@kvack.org> Tested-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Moritz Muehlenhoff <jmm@inutil.org> Signed-off-by:
-
- 11 Mar, 2016 1 commit
-
-
Kamal Mostafa authored
Signed-off-by:
-
- 09 Mar, 2016 25 commits
-
-
Willy Tarreau authored
commit 759c0114 upstream. On no-so-small systems, it is possible for a single process to cause an OOM condition by filling large pipes with data that are never read. A typical process filling 4000 pipes with 1 MB of data will use 4 GB of memory. On small systems it may be tricky to set the pipe max size to prevent this from happening. This patch makes it possible to enforce a per-user soft limit above which new pipes will be limited to a single page, effectively limiting them to 4 kB each, as well as a hard limit above which no new pipes may be created for this user. This has the effect of protecting the system against memory abuse without hurting other users, and still allowing pipes to work correctly though with less data at once. The limit are controlled by two new sysctls : pipe-user-pages-soft, and pipe-user-pages-hard. Both may be disabled by setting them to zero. The default soft limit allows the default number of FDs per process (1024) to create pipes of the default size (64kB), thus reaching a limit of 64MB before starting to create only smaller pipes. With 256 processes limited to 1024 FDs each, this results in 1024*64kB + (256*1024 - 1024) * 4kB = 1084 MB of memory allocated for a user. The hard limit is disabled by default to avoid breaking existing applications that make intensive use of pipes (eg: for splicing). Reported-by: socketpair@gmail.com Reported-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Mitigates: CVE-2013-4312 (Linux 2.0+) Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Rasmus Villemoes authored
commit 76a56367 upstream. Ironically, 7d4020c3 ("[media] exynos4-is: fix some warnings when compiling on arm64") fixed some format string bugs but introduced a new one. buf_index is a simple int, so it should be printed with %d, not %pad (which is correctly used for dma_addr_t). Fixes: 7d4020c3 ("[media] exynos4-is: fix some warnings when compiling on arm64") Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Florian Fainelli authored
commit 87bee0ec upstream. Commit 70371cef ("MAINTAINERS: Add entry for BMIPS multiplatform kernel") supersedes this entry for BCM33xx. Fixes: 70371cef ("MAINTAINERS: Add entry for BMIPS multiplatform kernel") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: blogic@openwrt.org Cc: cernekee@gmail.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12301/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Heiko Carstens authored
commit 9900c48c upstream. git commit dc7ee00d ("s390: lowcore stack pointer offsets") introduced a regression in regard to save_stack_trace(). The stack pointer for the asynchronous and the panic stack in the lowcore now have an additional offset applied to them. This offset needs to be taken into account in the calculation for the low and high address for the stacks. This bug was already partially fixed with 9cc5c206 ("s390/dumpstack: fix address ranges for asynchronous and panic stack"). This patch fixes it also for the stacktrace code. Fixes: dc7ee00d ("s390: lowcore stack pointer offsets") Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Tested-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Heinrich Schuchardt authored
commit 9d021c9d upstream. Downstream packages like Debian flash-kernel use /proc/device-tree/model to determine which dtb file to install. Hence each dts in the Linux kernel should provide a unique model identifier. Commit 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") created the new files kirkwood-ds111.dts and kirkwood-ds112.dts using the same model identifier. This patch provides a unique model identifier for the Synology DiskStation DS112. Fixes: 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Ken-ichirou MATSUZAWA authored
commit aa3a0220 upstream. We should not trim skb for mmaped socket since its buf size is fixed and userspace will read as frame which data equals head. mmaped socket will not call recvmsg, means max_recvmsg_len is 0, skb_reserve was not called before commit: db65a3aa. Fixes: db65a3aa (netlink: Trim skb to alloc size to avoid MSG_TRUNC) Signed-off-by:
Ken-ichirou MATSUZAWA <chamas@h4.dion.ne.jp> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Florian Fainelli authored
commit c6dd213a upstream. The PHY entries for BCM7425/29/35 declare the 40nm Ethernet PHY as being 10/100/1000 capable, while this is just a 10/100 capable PHY device, fix that. Fixes: d068b02c ("net: phy: add BCM7425 and BCM7429 PHYs") Fixes: 9458ceab ("net: phy: bcm7xxx: Add entry for BCM7435") Signed-off-by:
-
Florian Fainelli authored
commit d5c3d846 upstream. Commit 2c7b4921 ("phy: fix the use of PHY_IGNORE_INTERRUPT") changed a hunk in phy_state_machine() in the PHY_RUNNING case which was not needed. The change essentially makes the PHY library treat PHY devices with PHY_IGNORE_INTERRUPT to keep polling for the PHY device, even though the intent is not to do it. Fix this by reverting that specific hunk, which makes the PHY state machine wait for state changes, and stay in the PHY_RUNNING state for as long as needed. Fixes: 2c7b4921 ("phy: fix the use of PHY_IGNORE_INTERRUPT") Signed-off-by:
-
Shaohui Xie authored
commit 11e122cb upstream. Currently, if phy state is PHY_RUNNING, we always register a CHANGE when phy works in polling or interrupt ignored, this will make the adjust_link being called even the phy link did Not changed. checking the phy link to make sure the link did changed before we register a CHANGE, if link did not changed, we do nothing. Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by:
-
Florian Fainelli authored
commit deccd16f upstream. Commit 5ea94e76 ("phy: add phy_mac_interrupt()") to use with PHY_IGNORE_INTERRUPT added a cancel_work_sync() into phy_mac_interrupt() which is allowed to sleep, whereas phy_mac_interrupt() is expected to be callable from interrupt context. Now that we have fixed how the PHY state machine treats PHY_IGNORE_INTERRUPT with respect to state changes, we can just set the new link state, and queue the PHY state machine for execution so it is going to read the new link state. For that to work properly, we need to update phy_change() not to try to invoke any interrupt callbacks if we have configured the PHY device for PHY_IGNORE_INTERRUPT, because that PHY device and its driver are not required to implement those. Fixes: 5ea94e76 ("phy: add phy_mac_interrupt() to use with PHY_IGNORE_INTERRUPT") Signed-off-by:
-
Rainer Weikusat authored
commit 1b92ee3d upstream. The present unix_stream_read_generic contains various code sequences of the form err = -EDISASTER; if (<test>) goto out; This has the unfortunate side effect of possibly causing the error code to bleed through to the final out: return copied ? : err; and then to be wrongly returned if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Fixes: 3822b5c2 ("af_unix: Revert 'lock_interruptible' in stream receive code") Reported-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
Rainer Weikusat <rweikusat@mobileactivedefense.com> Signed-off-by:
-
Heiko Carstens authored
commit 1f8cbb9c upstream. git commit dc7ee00d ("s390: lowcore stack pointer offsets") introduced a regression in regard to perf_callchain_kernel(). The stack pointer for the asynchronous stack in the lowcore now has an additional offset applied. This offset needs to be taken into account in the calculation for the low and high address for the stack. This bug was already partially fixed with 9cc5c206 ("s390/dumpstack: fix address ranges for asynchronous and panic stack"). This patch fixes it also for the perf_event code. Fixes: dc7ee00d ("s390: lowcore stack pointer offsets") Signed-off-by:
-
Heiko Carstens authored
commit 232f5dd7 upstream. git commit dc7ee00d ("s390: lowcore stack pointer offsets") introduced a regression in regard to s390_backtrace(). The stack pointer for the asynchronous stack in the lowcore now has an additional offset applied. This offset needs to be taken into account in the calculation for the low and high address for the stack. This bug was already partially fixed with commit 9cc5c206 ("s390/dumpstack: fix address ranges for asynchronous and panic stack"). This patch fixes it also for the oprofile code. Fixes: dc7ee00d ("s390: lowcore stack pointer offsets") Signed-off-by:
-
Florian Fainelli authored
commit 258bf443 upstream. Since we were wrongly advertising gigabit features for these 10/100 only Ethernet PHYs, bcm7xxx_config_init() which is supposed to apply workaround would have not run since the check would be true, now that we have fixed the PHY features, remove that check since it has no reasoning to be there anymore. Fixes: e18556ee ("net: phy: bcm7xxx: do not use PHY_BRCM_100MBPS_WAR") Signed-off-by:
-
Florian Fainelli authored
commit 50d89980 upstream. The clear and set masks in the call to phy_set_clr_bits() called from bcm7xxx_config_init() are inverted. We need to fix this by swapping the two arguments, that is, set 0 bits, but clear the shade mode 2 enable bit. Fixes: b560a58c ("net: phy: add Broadcom BCM7xxx internal PHY driver") Signed-off-by:
-
Neil Horman authored
[ Upstream commit d9749fb5 ] Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in its size computation, observing that the current method never guaranteed that the hashsize (measured in number of entries) would be a power of two, which the input hash function for that table requires. The root cause of the problem is that two values need to be computed (one, the allocation order of the storage requries, as passed to __get_free_pages, and two the number of entries for the hash table). Both need to be ^2, but for different reasons, and the existing code is simply computing one order value, and using it as the basis for both, which is wrong (i.e. it assumes that ((1<<order)*PAGE_SIZE)/sizeof(bucket) is still ^2 when its not). To fix this, we change the logic slightly. We start by computing a goal allocation order (which is limited by the maximum size hash table we want to support. Then we attempt to allocate that size table, decreasing the order until a successful allocation is made. Then, with the resultant successful order we compute the number of buckets that hash table supports, which we then round down to the nearest power of two, giving us the number of entries the table actually supports. I've tested this locally here, using non-debug and spinlock-debug kernels, and the number of entries in the hashtable consistently work out to be powers of two in all cases. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> CC: Dmitry Vyukov <dvyukov@google.com> CC: Vladislav Yasevich <vyasevich@gmail.com> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Dmitry V. Levin authored
[ Upstream commit b5f05492 ] The value passed by unix_diag_get_exact to unix_lookup_by_ino has type __u32, but unix_lookup_by_ino's argument ino has type int, which is not a problem yet. However, when ino is compared with sock_i_ino return value of type unsigned long, ino is sign extended to signed long, and this results to incorrect comparison on 64-bit architectures for inode numbers greater than INT_MAX. This bug was found by strace test suite. Fixes: 5d3cae8b ("unix_diag: Dumping exact socket core") Signed-off-by:
Dmitry V. Levin <ldv@altlinux.org> Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Anton Protopopov authored
[ Upstream commit a97eb33f ] An error response from a RTM_GETNETCONF request can return the positive error value EINVAL in the struct nlmsgerr that can mislead userspace. Signed-off-by:
Anton Protopopov <a.s.protopopov@gmail.com> Acked-by:
-
Xin Long authored
[ Upstream commit deed49df ] Since the gc of ipv4 route was removed, the route cached would has no chance to be removed, and even it has been timeout, it still could be used, cause no code to check it's expires. Fix this issue by checking and removing route cache when we get route. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Guillaume Nault authored
[ Upstream commit 29e73269 ] Drop reference on the relay_po socket when __pppoe_xmit() succeeds. This is already handled correctly in the error path. Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Eugenia Emantayev authored
[ Upstream commit 925ab1aa ] It's forbidden to manually change dev->features in run-time. Currently, this is done in the driver to make sure that GSO_UDP_TUNNEL is advertized only when VXLAN tunnel is set. However, since the stack actually does features intersection with hw_enc_features, we can safely revert to advertizing features early when registering the netdevice. Fixes: f4a1edd5 ('net/mlx4_en: Advertize encapsulation offloads [...]') Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Eugenia Emantayev authored
[ Upstream commit 31c128b6 ] Previously, the shift value used for time-stamping was constant and didn't depend on the HW chip frequency. Change that to take the frequency into account and calculate the maximal value in cycles per wraparound of ten seconds. This time slot was chosen since it gives a good accuracy in time synchronization. Algorithm for shift value calculation: * Round up the maximal value in cycles to nearest power of two * Calculate maximal multiplier by division of all 64 bits set to above result * Then, invert the function clocksource_khz2mult() to get the shift from maximal mult value Fixes: ec693d47 ('net/mlx4_en: Add HW timestamping (TS) support') Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Amir Vadai authored
[ Upstream commit 281e8b2f ] RdropOvflw counts overrun of HW buffer, therefore should be used for rx_fifo_errors only. Currently RdropOvflw counter is mistakenly also set into rx_missed_errors and rx_over_errors too, which makes the device total dropped packets accounting to show wrong results. Fix that. Use it for rx_fifo_errors only. Fixes: c27a02cd ('mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC') Signed-off-by:
Amir Vadai <amir@vadai.me> Signed-off-by:
-
Bjørn Mork authored
[ Upstream commit aac8d3c2 ] Thomas reports: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=05c6 ProdID=6001 Rev=00.00 S: Manufacturer=USB Modem S: Product=USB Modem S: SerialNumber=1234567890ABCDEF C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Reported-by:
Thomas Schäfer <tschaefer@t-online.de> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Rainer Weikusat authored
[ Upstream commit a5527dda ] The unix_dgram_sendmsg routine use the following test if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) { to determine if sk and other are in an n:1 association (either established via connect or by using sendto to send messages to an unrelated socket identified by address). This isn't correct as the specified address could have been bound to the sending socket itself or because this socket could have been connected to itself by the time of the unix_peer_get but disconnected before the unix_state_lock(other). In both cases, the if-block would be entered despite other == sk which might either block the sender unintentionally or lead to trying to unlock the same spin lock twice for a non-blocking send. Add a other != sk check to guard against this. Fixes: 7d267278 ("unix: avoid use-after-free in ep_remove_wait_queue") Reported-By:
Philipp Hahn <pmhahn@pmhahn.de> Signed-off-by:
-
