- 14 Dec, 2015 1 commit
-
-
Eric Dumazet authored
[ Upstream commit 4ece9009 ] sit0 device allocates its percpu storage twice : - One time in ipip6_tunnel_init() - One time in ipip6_fb_tunnel_init() Thus we leak 48 bytes per possible cpu per network namespace dismantle. ipip6_fb_tunnel_init() can be much simpler and does not return an error, and should be called after register_netdev() Note that ipip6_tunnel_clone_6rd() also needs to be called after register_netdev() (calling ipip6_tunnel_init()) Fixes: ebe084aa ("sit: Use ipip6_tunnel_init as the ndo_init function.") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
- 03 Dec, 2015 39 commits
-
-
Eric Dumazet authored
[ Upstream commit 7e3b6e74 ] gre_gso_segment() chokes if SIT frames were aggregated by GRO engine. Fixes: 61c1db7f ("ipv6: sit: add GSO/TSO support") Signed-off-by:
-
Bjørn Mork authored
[ Upstream commit 0db65fcf ] New device IDs shamelessly lifted from the vendor driver. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Jason Wang authored
[ Upstream commit 48900cb6 ] virtio declares support for NETIF_F_FRAGLIST, but assumes that there are at most MAX_SKB_FRAGS + 2 fragments which isn't always true with a fraglist. A longer fraglist in the skb will make the call to skb_to_sgvec overflow the sg array, leading to memory corruption. Drop NETIF_F_FRAGLIST so we only get what we can handle. Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit d69bbf88 ] Only cpu seeing dst refcount going to 0 can safely dereference dst->flags. Otherwise an other cpu might already have freed the dst. Fixes: 27b75c95 ("net: avoid RCU for NOCACHE dst") Reported-by:
Greg Thelen <gthelen@google.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 8fa677d2 ] Under low memory conditions, tcp_sk_init() and icmp_sk_init() can both iterate on all possible cpus and call inet_ctl_sock_destroy(), with eventual NULL pointer. Signed-off-by:
-
Bjørn Mork authored
[ Upstream commit 70910791 ] The lt4112 is a HP branded Huawei me906e modem. Like other Huawei modems, it does not have a fixed interface to function mapping. Instead it uses a Huawei specific scheme: functions are mapped by subclass and protocol. However, the HP vendor ID is used for modems from many different manufacturers using different schemes, so we cannot apply a generic vendor rule like we do for the Huawei vendor ID. Replace the previous lt4112 entry pointing to an arbitrary interface number with a device specific subclass + protocol match. Reported-and-tested-by:
Muri Nicanor <muri+libqmi@immerda.ch> Tested-by:
Martin Hauke <mardnh@gmx.de> Fixes: bb2bdeb8 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem") Signed-off-by:
-
Ani Sinha authored
[ Upstream commit 44f49dd8 ] Fixes the following kernel BUG : BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758 caller is __this_cpu_preempt_check+0x13/0x15 CPU: 0 PID: 2758 Comm: bash Tainted: P O 3.18.19 #2 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8 Call Trace: [<ffffffff81482b2a>] dump_stack+0x52/0x80 [<ffffffff812010ae>] check_preemption_disabled+0xce/0xe1 [<ffffffff812010d4>] __this_cpu_preempt_check+0x13/0x15 [<ffffffff81419d60>] ipmr_queue_xmit+0x647/0x70c [<ffffffff8141a154>] ip_mr_forward+0x32f/0x34e [<ffffffff8141af76>] ip_mroute_setsockopt+0xe03/0x108c [<ffffffff810553fc>] ? get_parent_ip+0x11/0x42 [<ffffffff810e6974>] ? pollwake+0x4d/0x51 [<ffffffff81058ac0>] ? default_wake_function+0x0/0xf [<ffffffff810553fc>] ? get_parent_ip+0x11/0x42 [<ffffffff810613d9>] ? __wake_up_common+0x45/0x77 [<ffffffff81486ea9>] ? _raw_spin_unlock_irqrestore+0x1d/0x32 [<ffffffff810618bc>] ? __wake_up_sync_key+0x4a/0x53 [<ffffffff8139a519>] ? sock_def_readable+0x71/0x75 [<ffffffff813dd226>] do_ip_setsockopt+0x9d/0xb55 [<ffffffff81429818>] ? unix_seqpacket_sendmsg+0x3f/0x41 [<ffffffff813963fe>] ? sock_sendmsg+0x6d/0x86 [<ffffffff813959d4>] ? sockfd_lookup_light+0x12/0x5d [<ffffffff8139650a>] ? SyS_sendto+0xf3/0x11b [<ffffffff810d5738>] ? new_sync_read+0x82/0xaa [<ffffffff813ddd19>] compat_ip_setsockopt+0x3b/0x99 [<ffffffff813fb24a>] compat_raw_setsockopt+0x11/0x32 [<ffffffff81399052>] compat_sock_common_setsockopt+0x18/0x1f [<ffffffff813c4d05>] compat_SyS_setsockopt+0x1a9/0x1cf [<ffffffff813c4149>] compat_SyS_socketcall+0x180/0x1e3 [<ffffffff81488ea1>] cstar_dispatch+0x7/0x1e Signed-off-by:
Ani Sinha <ani@arista.com> Acked-by:
-
Phil Reid authored
[ Upstream commit e6dbe1eb ] priv->hwts_*_en indicate if timestamping is enabled/disabled at run time. But priv->dma_cap.time_stamp and priv->dma_cap.atime_stamp indicates HW is support for PTPv1/PTPv2. Signed-off-by:
Phil Reid <preid@electromag.com.au> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Carol L Soto authored
[ Upstream commit c02b0501 ] When doing memcpy/memset of EQEs, we should use sizeof struct mlx4_eqe as the base size and not caps.eqe_size which could be bigger. If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt data in the master context. When using a 64 byte stride, the memcpy copied over 63 bytes to the slave_eq structure. This resulted in copying over the entire eqe of interest, including its ownership bit -- and also 31 bytes of garbage into the next WQE in the slave EQ -- which did NOT include the ownership bit (and therefore had no impact). However, once the stride is increased to 128, we are overwriting the ownership bits of *three* eqes in the slave_eq struct. This results in an incorrect ownership bit for those eqes, which causes the eq to seem to be full. The issue therefore surfaced only once 128-byte EQEs started being used in SRIOV and (overarchitectures that have 128/256 byte cache-lines such as PPC) - e.g after commit 77507aa2 "net/mlx4_core: Enable CQE/EQE stride support". Fixes: 08ff3235 ('mlx4: 64-byte CQE/EQE support') Signed-off-by:
Carol L Soto <clsoto@linux.vnet.ibm.com> Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Sowmini Varadhan authored
[ Upstream commit 8ce675ff ] Either of pskb_pull() or pskb_trim() may fail under low memory conditions. If rds_tcp_data_recv() ignores such failures, the application will receive corrupted data because the skb has not been correctly carved to the RDS datagram size. Avoid this by handling pskb_pull/pskb_trim failure in the same manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and retry via the deferred call to rds_send_worker() that gets set up on ENOMEM from rds_tcp_read_sock() Signed-off-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Guillaume Nault authored
[ Upstream commit 1acea4f6 ] We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev. PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies (po->pppoe_dev != NULL). Since we're releasing a PPPoE socket, we want to release the pppoe_dev if it exists and reset sk_state to PPPOX_DEAD, no matter the previous value of sk_state. So we can just check for po->pppoe_dev and avoid any assumption on sk->sk_state. Fixes: 2b018d57 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release") Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Jason Wang authored
[ Upstream commit f23d538b ] We don't have fraglist support in TAP_FEATURES. This will lead software segmentation of gro skb with frag list. Fixes by having frag list support in TAP_FEATURES. With this patch single session of netperf receiving were restored from about 5Gb/s to about 12Gb/s on mlx4. Fixes a567dd62 ("macvtap: simplify usage of tap_features") Cc: Vlad Yasevich <vyasevic@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 50010c20 ] This is decrementing the pointer, instead of the value stored in the pointer. KASan detects it as an out of bounds reference. Reported-by:
"Berry Cheng 程君(成淼)" <chengmiao.cj@alibaba-inc.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Paul Moore authored
[ Upstream commit fcf22d82 ] Unfortunately, while commit 4a928436 ("audit: correctly record file names with different path name types") fixed a problem where we were not recording filenames, it created a new problem by attempting to use these file names after they had been freed. This patch resolves the issue by creating a copy of the filename which the audit subsystem frees after it is done with the string. At some point it would be nice to resolve this issue with refcounts, or something similar, instead of having to allocate/copy strings, but that is almost surely beyond the scope of a -rcX patch so we'll defer that for later. On the plus side, only audit users should be impacted by the string copying. Reported-by:
Toralf Foerster <toralf.foerster@gmx.de> Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Paul Moore authored
[ Upstream commit 4a928436 ] There is a problem with the audit system when multiple audit records are created for the same path, each with a different path name type. The root cause of the problem is in __audit_inode() when an exact match (both the path name and path name type) is not found for a path name record; the existing code creates a new path name record, but it never sets the path name in this record, leaving it NULL. This patch corrects this problem by assigning the path name to these newly created records. There are many ways to reproduce this problem, but one of the easiest is the following (assuming auditd is running): # mkdir /root/tmp/test # touch /root/tmp/test/567 # auditctl -a always,exit -F dir=/root/tmp/test # touch /root/tmp/test/567 Afterwards, or while the commands above are running, check the audit log and pay special attention to the PATH records. A faulty kernel will display something like the following for the file creation: type=SYSCALL msg=audit(1416957442.025:93): arch=c000003e syscall=2 success=yes exit=3 ... comm="touch" exe="/usr/bin/touch" type=CWD msg=audit(1416957442.025:93): cwd="/root/tmp" type=PATH msg=audit(1416957442.025:93): item=0 name="test/" inode=401409 ... nametype=PARENT type=PATH msg=audit(1416957442.025:93): item=1 name=(null) inode=393804 ... nametype=NORMAL type=PATH msg=audit(1416957442.025:93): item=2 name=(null) inode=393804 ... nametype=NORMAL While a patched kernel will show the following: type=SYSCALL msg=audit(1416955786.566:89): arch=c000003e syscall=2 success=yes exit=3 ... comm="touch" exe="/usr/bin/touch" type=CWD msg=audit(1416955786.566:89): cwd="/root/tmp" type=PATH msg=audit(1416955786.566:89): item=0 name="test/" inode=401409 ... nametype=PARENT type=PATH msg=audit(1416955786.566:89): item=1 name="test/567" inode=393804 ... nametype=NORMAL This issue was brought up by a number of people, but special credit should go to hujianyang@huawei.com for reporting the problem along with an explanation of the problem and a patch. While the original patch did have some problems (see the archive link below), it did demonstrate the problem and helped kickstart the fix presented here. * https://lkml.org/lkml/2014/9/5/66Reported-by:
hujianyang <hujianyang@huawei.com> Signed-off-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit e819cdb1 ] These are signed values the come from the user, we put a cap on the upper bounds but not on the lower bounds. We use "karg.dataSgeOffset" to calculate "sz". We verify "sz" and proceed as if that means that "karg.dataSgeOffset" is correct but this fails to consider that the "sz" calculations can have integer overflows. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Charles Keepax authored
[ Upstream commit 81207880 ] Add a register patch for rev E and above that configures the location of some write sequences to assist with the headphone enables. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Nicholas Mc Guire authored
[ Upstream commit 63f2f417 ] 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> Signed-off-by:
-
Nobuhiro Iwamatsu authored
[ Upstream commit 03b36e4d ] 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
[ Upstream commit 1aa78903 ] 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
[ Upstream commit 45008ee9 ] 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
[ Upstream commit e2c84ccb ] 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
[ Upstream commit d3b367bc ] 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> Signed-off-by:
-
Sudip Mukherjee authored
[ Upstream commit d79bdc7f ] 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
[ Upstream commit 1a5e2519 ] 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
[ Upstream commit 66bc2f51 ] 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
[ Upstream commit c9b57724 ] 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> Signed-off-by:
-
Henrik Rydberg authored
[ Upstream commit a4a2c545 ] 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
[ Upstream commit b431ba88 ] 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> Signed-off-by:
-
Bin Liu authored
[ Upstream commit cb83df77 ] 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
[ Upstream commit 8ae25a35 ] 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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Li Jun authored
[ Upstream commit bc249379 ] Add runtime pm operations for registers access to avoid system hang. Signed-off-by:
Li Jun <jun.li@freescale.com> Signed-off-by:
-
Martin Schwidefsky authored
[ Upstream commit 05bfd70b ] If a 3270 terminal is disconnected and later reconnected again, it gets an unsolicited device end. This is currently ignored and you have to hit the clear key to get the screen redrawn. Add an automatic full redraw of the screen for this case. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Joerg Roedel authored
[ Upstream commit e6aabee0 ] Handle this case to make sure boundary_size does not become 0 and trigger a BUG_ON later. Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Noel Power authored
[ Upstream commit f291095f ] [MS-SMB] 2.2.4.5.2.1 states: "ChallengeLength (1 byte): When the CAP_EXTENDED_SECURITY bit is set, the server MUST set this value to zero and clients MUST ignore this value." Signed-off-by:
Noel Power <noel.power@suse.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Teunis van Beelen authored
[ Upstream commit f5042022 ] Recently we purchased the Rigol DS6104 and when I try to operate it from my Linux pc, everything works well with the default usbtmc driver, except when I want to download a big datachunk like a screenshot. This bitmapfile has a size of 1152054 bytes but I receive a smaller file and no new packets can be read. When I took a look at the driver source, I found this "Rigol quirk" and I added the id of the new DS series oscilloscopes to this list. I compiled it and loaded the new driver and now everything seems to work fine. Signed-off-by:
Teunis van Beelen <teuniz@gmail.com> Signed-off-by:
-
Jan H. Schönherr authored
[ Upstream commit dd9d3843 ] There is a race condition in SMP bootup code, which may result in WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418 workqueue_cpu_up_callback() or kernel BUG at kernel/smpboot.c:135! It can be triggered with a bit of luck in Linux guests running on busy hosts. CPU0 CPUn ==== ==== _cpu_up() __cpu_up() start_secondary() set_cpu_online() cpumask_set_cpu(cpu, to_cpumask(cpu_online_bits)); cpu_notify(CPU_ONLINE) <do stuff, see below> cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits)); During the various CPU_ONLINE callbacks CPUn is online but not active. Several things can go wrong at that point, depending on the scheduling of tasks on CPU0. Variant 1: cpu_notify(CPU_ONLINE) workqueue_cpu_up_callback() rebind_workers() set_cpus_allowed_ptr() This call fails because it requires an active CPU; rebind_workers() ends with a warning: WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418 workqueue_cpu_up_callback() Variant 2: cpu_notify(CPU_ONLINE) smpboot_thread_call() smpboot_unpark_threads() .. __kthread_unpark() __kthread_bind() wake_up_state() .. select_task_rq() select_fallback_rq() The ->wake_cpu of the unparked thread is not allowed, making a call to select_fallback_rq() necessary. Then, select_fallback_rq() cannot find an allowed, active CPU and promptly resets the allowed CPUs, so that the task in question ends up on CPU0. When those unparked tasks are eventually executed, they run immediately into a BUG: kernel BUG at kernel/smpboot.c:135! Just changing the order in which the online/active bits are set (and adding some memory barriers), would solve the two issues above. However, it would change the order of operations back to the one before commit 6acbfb96 ("sched: Fix hotplug vs. set_cpus_allowed_ptr()"), thus, reintroducing that particular problem. Going further back into history, we have at least the following commits touching this topic: - commit 2baab4e9 ("sched: Fix select_fallback_rq() vs cpu_active/cpu_online") - commit 5fbd036b ("sched: Cleanup cpu_active madness") Together, these give us the following non-working solutions: - secondary CPU sets active before online, because active is assumed to be a subset of online; - secondary CPU sets online before active, because the primary CPU assumes that an online CPU is also active; - secondary CPU sets online and waits for primary CPU to set active, because it might deadlock. Commit 875ebe94 ("powerpc/smp: Wait until secondaries are active & online") introduces an arch-specific solution to this arch-independent problem. Now, go for a more general solution without explicit waiting and simply set active twice: once on the secondary CPU after online was set and once on the primary CPU after online was seen. set_cpus_allowed_ptr()") Signed-off-by:
Jan H. Schönherr <jschoenh@amazon.de> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: <stable@vger.kernel.org> Cc: Anton Blanchard <anton@samba.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Joerg Roedel <jroedel@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Wilson <msw@amazon.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 6acbfb96 ("sched: Fix hotplug vs. set_cpus_allowed_ptr()") Link: http://lkml.kernel.org/r/1439408156-18840-1-git-send-email-jschoenh@amazon.deSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Mark Rustad authored
[ Upstream commit 7aa6ca4d ] Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device functions other than function 0, so that on multi-function devices, we will always read VPD from function 0 instead of from the other functions. [bhelgaas: changelog] Signed-off-by:
Mark Rustad <mark.d.rustad@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Alexander Duyck <alexander.h.duyck@redhat.com> CC: stable@vger.kernel.org Signed-off-by:
-
Mark Rustad authored
[ Upstream commit 91a37c79 ] commit 932c435c upstream. Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through function 0 to provide VPD access on other functions. This is for hardware devices that provide copies of the same VPD capability registers in multiple functions. Because the kernel expects that each function has its own registers, both the locking and the state tracking are affected by VPD accesses to different functions. On such devices for example, if a VPD write is performed on function 0, *any* later attempt to read VPD from any other function of that device will hang. This has to do with how the kernel tracks the expected value of the F bit per function. Concurrent accesses to different functions of the same device can not only hang but also corrupt both read and write VPD data. When hangs occur, typically the error message: vpd r/w failed. This is likely a firmware bug on this device. will be seen. Never set this bit on function 0 or there will be an infinite recursion. Signed-off-by:
-
