- 14 Nov, 2015 24 commits
-
-
hayeswang authored
commit b51ecea8 upstream. For RTL8411, RTL8111G, RTL8402, RTL8105, and RTL8106, disable the feature of entering the L2/L3 link state of the PCIe. When the nic starts the process of entering the L2/L3 link state and the PCI reset occurs before the work is finished, the work would be queued and continue after the next the PCI reset occurs. This causes the device stays in L2/L3 link state, and the system couldn't find the device. Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Acked-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
hayeswang authored
commit f75761b6 upstream. The tx descriptor version of RTL8111B belong to RTL_TD_0. Signed-off-by:
-
Wei Yongjun authored
commit 06a2feb9 upstream. Add missing platform_set_drvdata() in mace_probe(), otherwise calling platform_get_drvdata() in mac_mace_device_remove() may returns NULL. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Marc Zyngier authored
commit 2670cc69 upstream. Upon reception of a new frame, the emac driver checks for a number of error conditions, and flag the packet as "bad" if any of these are present. It then allocates a skb unconditionally, but only uses it if the packet is "good". On the error path, the skb is just forgotten, and the system leaks memory. The piece of junk I have on my desk seems to encounter such error frequently enough so that the box goes OOM after a couple of days, which makes me grumpy. Fix this by moving the allocation on the "good_packet" path (and convert it to netdev_alloc_skb while we're at it). Tested on a random Allwinner A20 board. Cc: Stefan Roese <sr@denx.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Yan, Zheng authored
commit 282c1052 upstream. __do_request() may unregister the request. So we should update iterator 'p' before calling __do_request() Signed-off-by:
"Yan, Zheng" <zheng.z.yan@intel.com> Signed-off-by:
-
Yan, Zheng authored
commit 656e4382 upstream. Signed-off-by:
"Yan, Zheng" <zyan@redhat.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
-
Yan, Zheng authored
commit 03974e81 upstream. we may corrupt waiting list if a request in the waiting list is kicked. Signed-off-by:
-
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:
-
Vasily Averin authored
commit aff09ce3 upstream. Currently bridge can silently drop ipv4 fragments. If node have loaded nf_defrag_ipv4 module but have no nf_conntrack_ipv4, br_nf_pre_routing defragments incoming ipv4 fragments but nfct check in br_nf_dev_queue_xmit does not allow re-fragment combined packet back, and therefore it is dropped in br_dev_queue_push_xmit without incrementing of any failcounters It seems the only way to hit the ip_fragment code in the bridge xmit path is to have a fragment list whose reassembled fragments go over the mtu. This only happens if nf_defrag is enabled. Thanks to Florian Westphal for providing feedback to clarify this. Defragmentation ipv4 is required not only in conntracks but at least in TPROXY target and socket match, therefore #ifdef is changed from NF_CONNTRACK_IPV4 to NF_DEFRAG_IPV4 Signed-off-by:
Vasily Averin <vvs@openvz.org> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Anton Blanchard authored
commit 733187e2 upstream. commit f13c13a0 (powerpc: Stop using non-architected shared_proc field in lppaca) fixed a potential issue with shared/dedicated partition detection. The old method of detection relied on an unarchitected field (shared_proc), and this patch switched to using something architected (a non zero yield_count). Unfortunately the assertion in the Linux header that yield_count is only non zero on shared processor partitions is not true. It turns out dedicated processor partitions can increment yield_count and as such we falsely detect dedicated partitions as shared. Fix the comment, and switch back to using the old method. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Holger Eitzenberger authored
commit d9547773 upstream. V3 of the NFQUEUE target ignores the --queue-bypass flag, causing packets to be dropped when the userspace listener isn't running. Regression is in since 8746ddcf ("netfilter: xt_NFQUEUE: introduce CPU fanout"). Reported-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Holger Eitzenberger <holger@eitzenberger.org> Signed-off-by:
-
Sasha Levin authored
[ Upstream commit 74e98eb0 ] There was no verification that an underlying transport exists when creating a connection, this would cause dereferencing a NULL ptr. It might happen on sockets that weren't properly bound before attempting to send a message, which will cause a NULL ptr deref: [135546.047719] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [135546.051270] Modules linked in: [135546.051781] CPU: 4 PID: 15650 Comm: trinity-c4 Not tainted 4.2.0-next-20150902-sasha-00041-gbaa1222-dirty #2527 [135546.053217] task: ffff8800835bc000 ti: ffff8800bc708000 task.ti: ffff8800bc708000 [135546.054291] RIP: __rds_conn_create (net/rds/connection.c:194) [135546.055666] RSP: 0018:ffff8800bc70fab0 EFLAGS: 00010202 [135546.056457] RAX: dffffc0000000000 RBX: 0000000000000f2c RCX: ffff8800835bc000 [135546.057494] RDX: 0000000000000007 RSI: ffff8800835bccd8 RDI: 0000000000000038 [135546.058530] RBP: ffff8800bc70fb18 R08: 0000000000000001 R09: 0000000000000000 [135546.059556] R10: ffffed014d7a3a23 R11: ffffed014d7a3a21 R12: 0000000000000000 [135546.060614] R13: 0000000000000001 R14: ffff8801ec3d0000 R15: 0000000000000000 [135546.061668] FS: 00007faad4ffb700(0000) GS:ffff880252000000(0000) knlGS:0000000000000000 [135546.062836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [135546.063682] CR2: 000000000000846a CR3: 000000009d137000 CR4: 00000000000006a0 [135546.064723] Stack: [135546.065048] ffffffffafe2055c ffffffffafe23fc1 ffffed00493097bf ffff8801ec3d0008 [135546.066247] 0000000000000000 00000000000000d0 0000000000000000 ac194a24c0586342 [135546.067438] 1ffff100178e1f78 ffff880320581b00 ffff8800bc70fdd0 ffff880320581b00 [135546.068629] Call Trace: [135546.069028] ? __rds_conn_create (include/linux/rcupdate.h:856 net/rds/connection.c:134) [135546.069989] ? rds_message_copy_from_user (net/rds/message.c:298) [135546.071021] rds_conn_create_outgoing (net/rds/connection.c:278) [135546.071981] rds_sendmsg (net/rds/send.c:1058) [135546.072858] ? perf_trace_lock (include/trace/events/lock.h:38) [135546.073744] ? lockdep_init (kernel/locking/lockdep.c:3298) [135546.074577] ? rds_send_drop_to (net/rds/send.c:976) [135546.075508] ? __might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3795) [135546.076349] ? __might_fault (mm/memory.c:3795) [135546.077179] ? rds_send_drop_to (net/rds/send.c:976) [135546.078114] sock_sendmsg (net/socket.c:611 net/socket.c:620) [135546.078856] SYSC_sendto (net/socket.c:1657) [135546.079596] ? SYSC_connect (net/socket.c:1628) [135546.080510] ? trace_dump_stack (kernel/trace/trace.c:1926) [135546.081397] ? ring_buffer_unlock_commit (kernel/trace/ring_buffer.c:2479 kernel/trace/ring_buffer.c:2558 kernel/trace/ring_buffer.c:2674) [135546.082390] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749) [135546.083410] ? trace_event_raw_event_sys_enter (include/trace/events/syscalls.h:16) [135546.084481] ? do_audit_syscall_entry (include/trace/events/syscalls.h:16) [135546.085438] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749) [135546.085515] rds_ib_laddr_check(): addr 36.74.25.172 ret -99 node type -1 Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> 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 <edumazet@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:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
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:
-
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:
Bjørn Mork <bjorn@mork.no> 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:
-
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:
-
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:
-
- 12 Nov, 2015 16 commits
-
-
Tom Tucker authored
commit 7e4359e2 upstream. The server regression was caused by the addition of rq_next_page (afc59400). There were a few places that were missed with the update of the rq_respages array. Signed-off-by:
Tom Tucker <tom@ogc.us> Tested-by:
Steve Wise <swise@ogc.us> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Dan Williams authored
commit dbfe8ef5 upstream. Avoton AHCI occasionally sees drive probe timeouts at driver load time. When this happens SCR_STATUS indicates device detected, but no D2H FIS reception. Reset the internal link state machines by bouncing port-enable in the PCS register when this occurs. Cc: <stable@vger.kernel.org> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Hans de Goede authored
commit 039ece38 upstream. Allwinner A10 and A20 ARM SoCs have an AHCI sata controller which needs a special register to be poked before starting the DMA engine. This register gets reset on an ahci_stop_engine call, so there is no other place then ahci_start_engine where this poking can be done. This commit allows drivers to override ahci_start_engine behavior for use by the Allwinner AHCI driver (and potentially other drivers in the future). Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Paul Moore authored
commit fcf22d82 upstream. 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
commit 4a928436 upstream. 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
commit e819cdb1 upstream. 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> Cc: Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Charles Keepax authored
commit 81207880 upstream. 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> Cc: Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Charles Keepax authored
commit 02915661 upstream. Evaluation of revision D of WM5110 suggests updates to the register patch for optimal performance. For the sake of clarity rev C of the chip does not require a register patch. Signed-off-by:
-
Soeren Grunewald authored
commit be32c0cf upstream. The Exar XR17V358 can also be combined with a XR17V354 chip to act as a single 12 port chip. This works the same way as the combining two XR17V358 chips. But the reported device id then is 0x4358. Signed-off-by:
Soeren Grunewald <soeren.grunewald@desy.de> Signed-off-by:
-
Soeren Grunewald authored
commit 96a5d18b upstream. The Exar XR17V358 chip usually provides only 8 ports. But two chips can be combined to act as a single 16 port chip. Therefor one chip is configured as master the second as slave by connecting the mode pin to VCC (master) or GND (slave). Then the master chip is reporting a different device-id depending on whether a slave is detected or not. The UARTs 8-15 are addressed from 0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to address all 16 ports as before. See: https://www.exar.com/common/content/document.ashx?id=1587 page 11 Signed-off-by:
-
Doron Tsur authored
commit 0ca81a28 upstream. ib_send_cm_sidr_rep could sometimes erase the node from the sidr (depending on errors in the process). Since ib_send_cm_sidr_rep is called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv could be either erased from the rb_tree twice or not erased at all. Fixing that by making sure it's erased only once before freeing cm_id_priv. Fixes: a977049d ('[PATCH] IB: Add the kernel CM implementation') Signed-off-by:
Doron Tsur <doront@mellanox.com> Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Dāvis Mosāns authored
commit 22805217 upstream. When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays NULL but it's later used in mvs_abort_task as slot which is passed to mvs_slot_task_free causing NULL pointer dereference. Just return from mvs_slot_task_free when passed with NULL slot. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891Signed-off-by:
Dāvis Mosāns <davispuh@gmail.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Reviewed-by:
-
Jes Sorensen authored
commit 681ab469 upstream. This was introduced with 9e882242 which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242 ("block: Add submit_bio_wait(), remove from md") Reported-by:
Bill Kuzeja <William.Kuzeja@stratus.com> Signed-off-by:
Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
-
Jes Sorensen authored
commit 203d27b0 upstream. This was introduced with 9e882242 which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242 ("block: Add submit_bio_wait(), remove from md") Reported-by:
-
Herbert Xu authored
commit 3fc89adb upstream. Currently a number of Crypto API operations may fail when a signal occurs. This causes nasty problems as the caller of those operations are often not in a good position to restart the operation. In fact there is currently no need for those operations to be interrupted by user signals at all. All we need is for them to be killable. This patch replaces the relevant calls of signal_pending with fatal_signal_pending, and wait_for_completion_interruptible with wait_for_completion_killable, respectively. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Peter Zijlstra authored
commit 275d7d44 upstream. Poma (on the way to another bug) reported an assertion triggering: [<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90 [<ffffffff81150822>] __module_address+0x32/0x150 [<ffffffff81150956>] __module_text_address+0x16/0x70 [<ffffffff81150f19>] symbol_put_addr+0x29/0x40 [<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core] Laura Abbott <labbott@redhat.com> produced a patch which lead us to inspect symbol_put_addr(). This function has a comment claiming it doesn't need to disable preemption around the module lookup because it holds a reference to the module it wants to find, which therefore cannot go away. This is wrong (and a false optimization too, preempt_disable() is really rather cheap, and I doubt any of this is on uber critical paths, otherwise it would've retained a pointer to the actual module anyway and avoided the second lookup). While its true that the module cannot go away while we hold a reference on it, the data structure we do the lookup in very much _CAN_ change while we do the lookup. Therefore fix the comment and add the required preempt_disable(). Reported-by:
poma <pomidorabelisima@gmail.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Fixes: a6e6abd5 ("module: remove module_text_address()") Signed-off-by:
-
