- Jun 27, 2013
-
-
Greg Kroah-Hartman authored
-
Mika Westerberg authored
commit cc0ee987 upstream. ACPI part of the driver accidentally used sizeof(*ssp) instead of the correct sizeof(*pdata). This leads to nasty memory corruptions like the one below: BUG: unable to handle kernel paging request at 0000000749fd30b8 IP: [<ffffffff813fe8a1>] __list_del_entry+0x31/0xd0 PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.0-rc6v3.10-rc6_sdhci_modprobe+ #443 task: ffff8801483a0940 ti: ffff88014839e000 task.ti: ffff88014839e000 RIP: 0010:[<ffffffff813fe8a1>] [<ffffffff813fe8a1>] __list_del_entry+0x31/0xd0 RSP: 0000:ffff88014839fde8 EFLAGS: 00010046 RAX: ffff880149fd30b0 RBX: ffff880149fd3040 RCX: dead000000200200 RDX: 0000000749fd30b0 RSI: ffff880149fd3058 RDI: ffff88014834d640 RBP: ffff88014839fde8 R08: ffff88014834d640 R09: 0000000000000001 R10: ffff8801483a0940 R11: 0000000000000001 R12: ffff880149fd3040 R13: ffffffff810e0b30 R14: ffff8801483a0940 R15: ffff88014834d640 FS: 0000000000000000(0000) GS:ffff880149e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000168 CR3: 0000000001e0b000 CR4: 00000000001407f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffff88014839fe48 ffffffff810e0baf ffffffff81120abd ffff88014839fe20 ffff8801483a0940 ffff8801483a0940 ffff8801483a0940 ffff8801486b1c90 ffff88014834d640 ffffffff810e0b30 0000000000000000 0000000000000000 Call Trace: [<ffffffff810e0baf>] worker_thread+0x7f/0x390 [<ffffffff81120abd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff810e0b30>] ? manage_workers.isra.22+0x2b0/0x2b0 [<ffffffff810e6c09>] kthread+0xd9/0xe0 [<ffffffff810f93df>] ? local_clock+0x3f/0x50 [<ffffffff810e6b30>] ? kthread_create_on_node+0x110/0x110 [<ffffffff818c5dec>] ret_from_fork+0x7c/0xb0 [<ffffffff810e6b30>] ? kthread_create_on_node+0x110/0x110 Fix this by using the right structure size in devm_kzalloc(). Reported-by:
Jerome Blin <jerome.blin@intel.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mika Westerberg authored
commit 5548f98c upstream. pxa2xx_spi_map_dma_buffer() gets called in tasklet context so we can't sleep when we allocate a new sg table. Use GFP_ATOMIC here instead. Signed-off-by:
-
Damian Hobson-Garcia authored
commit 5ed0505c upstream. Until recently uio_get_minor() returned 0 for success and a negative value on failure. This became non-negative for suceess and negative for failure. Restore the original return value spec so that we can successfully initialize UIO devices with a non-zero minor device number. Signed-off-by:
Damian Hobson-Garcia <dhobsong@igel.co.jp> Cc: "Hans J. Koch" <hjk@hansjkoch.de> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Peter Zijlstra authored
commit 9bb5d40c upstream. Vince's fuzzer once again found holes. This time it spotted a leak in the locked page accounting. When an event had redirected output and its close() was the last reference to the buffer we didn't have a vm context to undo accounting. Change the code to destroy the buffer on the last munmap() and detach all redirected events at that time. This provides us the right context to undo the vm accounting. Reported-and-tested-by:
Vince Weaver <vincent.weaver@maine.edu> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20130604084421.GI8923@twins.programming.kicks-ass.net Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Peter Zijlstra authored
commit 26cb63ad upstream. Vince reported a problem found by his perf specific trinity fuzzer. Al noticed 2 problems with perf's mmap(): - it has issues against fork() since we use vma->vm_mm for accounting. - it has an rb refcount leak on double mmap(). We fix the issues against fork() by using VM_DONTCOPY; I don't think there's code out there that uses this; we didn't hear about weird accounting problems/crashes. If we do need this to work, the previously proposed VM_PINNED could make this work. Aside from the rb reference leak spotted by Al, Vince's example prog was indeed doing a double mmap() through the use of perf_event_set_output(). This exposes another problem, since we now have 2 events with one buffer, the accounting gets screwy because we account per event. Fix this by making the buffer responsible for its own accounting. Reported-by:
-
Josh Durgin authored
commit 3a96d5cd upstream. [Backported for 3.9-stable. 'kmalloc(MAX_OBJ_NAME_SIZE + 1, GFP_NOIO)' was changed as 'kmem_cache_alloc(rbd_segment_name_cache, GFP_NOIO)' in 78c2a44a since 3.10-rc1, and 78c2a44a is relied on a big patchset, so restore it as 3.9 did.] Format 2 objects use 16 characters for the object name suffix to be able to express the full 64-bit range of object numbers. Format 1 images only use 12 characters for this. Using 12-character names for format 2 caused userspace and kernel rbd clients to read differently named objects, which made an image written by one client look empty to the other client. Reported-by:
Chris Dunlop <chris@onthe.net.au> Signed-off-by:
Josh Durgin <josh.durgin@inktank.com> Reviewed-by:
Sage Weil <sage@inktank.com> Reviewed-by:
Lingzhu Xiang <lxiang@redhat.com> Signed-off-by:
Zhouping Liu <zliu@redhat.com> Signed-off-by:
-
Joern Engel authored
commit 574780fd upstream. Here is a fun one. Bug seems to have been introduced by commit 140854cb, almost two years ago. I have no idea why we only started seeing it now, but we did. Rough callgraph: core_tpg_set_initiator_node_queue_depth() `-> spin_lock_irqsave(&tpg->session_lock, flags); `-> lio_tpg_shutdown_session() `-> iscsit_stop_time2retain_timer() `-> spin_unlock_bh(&se_tpg->session_lock); `-> spin_lock_bh(&se_tpg->session_lock); `-> spin_unlock_irqrestore(&tpg->session_lock, flags); core_tpg_set_initiator_node_queue_depth() used to call spin_lock_bh(), but 140854cb changed that to spin_lock_irqsave(). However, lio_tpg_shutdown_session() still claims to be called with spin_lock_bh() held, as does iscsit_stop_time2retain_timer(): * Called with spin_lock_bh(&struct se_portal_group->session_lock) held Stale documentation is mostly annoying, but in this case the dropping the lock with the _bh variant is plain wrong. It is also wrong to drop locks two functions below the lock-holder, but I will ignore that bit for now. After some more locking and unlocking we eventually hit this backtrace: ------------[ cut here ]------------ WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xe8/0x100() Pid: 24645, comm: lio_helper.py Tainted: G O 3.6.11+ Call Trace: [<ffffffff8103e5ff>] warn_slowpath_common+0x7f/0xc0 [<ffffffffa040ae37>] ? iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod] [<ffffffff8103e65a>] warn_slowpath_null+0x1a/0x20 [<ffffffff810472f8>] local_bh_enable_ip+0xe8/0x100 [<ffffffff815b8365>] _raw_spin_unlock_bh+0x15/0x20 [<ffffffffa040ae37>] iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod] [<ffffffffa041149a>] iscsit_stop_session+0xfa/0x1c0 [iscsi_target_mod] [<ffffffffa0417fab>] lio_tpg_shutdown_session+0x7b/0x90 [iscsi_target_mod] [<ffffffffa033ede4>] core_tpg_set_initiator_node_queue_depth+0xe4/0x290 [target_core_mod] [<ffffffffa0409032>] iscsit_tpg_set_initiator_node_queue_depth+0x12/0x20 [iscsi_target_mod] [<ffffffffa0415c29>] lio_target_nacl_store_cmdsn_depth+0xa9/0x180 [iscsi_target_mod] [<ffffffffa0331b49>] target_fabric_nacl_base_attr_store+0x39/0x40 [target_core_mod] [<ffffffff811b857d>] configfs_write_file+0xbd/0x120 [<ffffffff81148f36>] vfs_write+0xc6/0x180 [<ffffffff81149251>] sys_write+0x51/0x90 [<ffffffff815c0969>] system_call_fastpath+0x16/0x1b ---[ end trace 3747632b9b164652 ]--- As a pure band-aid, this patch drops the _bh. Signed-off-by:
Joern Engel <joern@logfs.org> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org>
-
Peter Hurley authored
commit 7c61c3d8 upstream. Commit 69939035 ('pty: Ignore slave pty close() if never successfully opened') introduced a bug with ptys whereby a write() in parallel with an open() on an existing pty could mistakenly indicate an I/O error. Only indicate an I/O error if the condition on open() actually exists. Reported-by:
Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Tested-by:
Mikael Pettersson <mikpe@it.uu.se> Signed-off-by:
-
Roland Dreier authored
commit b5aff3d2 upstream. Suppose an initiator sends a DATA IN command with an allocation length shorter than the FC transfer length -- we get a target message like TARGET_CORE[qla2xxx]: Expected Transfer Length: 256 does not match SCSI CDB Length: 0 for SAM Opcode: 0x12 In that case, the target core adjusts the data_length and sets se_cmd->residual_count for the underrun. But now suppose that command fails and we end up in tcm_qla2xxx_queue_status() -- that function unconditionally overwrites residual_count with the already adjusted data_length, and the initiator will burp with a message like qla2xxx [0000:00:06.0]-301d:0: Dropped frame(s) detected (0x100 of 0x100 bytes). Fix this by adding on to the existing underflow residual count instead. Signed-off-by:
Roland Dreier <roland@purestorage.com> Cc: Giridhar Malavali <giridhar.malavali@qlogic.com> Cc: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Ming Lei authored
commit 87597936 upstream. fw_priv->buf is accessed in both request_firmware_load() and writing to sysfs file of 'loading' context, but not protected by 'fw_lock' entirely. The patch makes sure that access on 'fw_priv->buf' is protected by the lock. So fixes the double abort problem reported by nirinA raseliarison: http://lkml.org/lkml/2013/6/14/188 Reported-and-tested-by:
nirinA raseliarison <nirina.raseliarison@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Anders Hammarquist authored
commit 35a2fbc9 upstream. Add product id for Abbott strip port cable for Precision meter which uses the TI 3410 chip. Signed-off-by:
Anders Hammarquist <iko@iko.pp.se> Signed-off-by:
-
Shawn Joseph authored
commit be662271 upstream. Added MAP_TRIGGERS_TO_BUTTONS for Mad Catz Street Fighter IV FightPad device. This controller model was already supported by the xpad driver, but none of the buttons work correctly without this change. Tested on kernel version 3.9.5. Signed-off-by:
Shawn Joseph <jms.576@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Ben Hutchings authored
commit 150e5928 upstream. Several drivers don't build on s390 with CONFIG_PCI disabled as they require MMIO functions. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ferruh Yigit authored
commit d2983cdb upstream. memcpy param is wrong because of offset in bl_cmd, this may corrupt the stack which may cause a crash. Tested-by: Ferruh Yigit <fery@cypress.com> on TMA300-DVK Signed-off-by:
Ferruh Yigit <fery@cypress.com> Acked-by:
Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by:
-
Jason Wang authored
[ Upstream commit 15e5a030 ] gso_segs were reset to zero when kernel receive packets from untrusted source. But we use this zero value to estimate precise packet len which is wrong. So this patch tries to estimate the correct gso_segs value before using it in qdisc_pkt_len_init(). Signed-off-by:
Jason Wang <jasowang@redhat.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jason Wang authored
[ Upstream commit f9ca8f74 ] Currently, for the packets receives from netback, before doing header check, kernel just reset the transport header in netif_receive_skb() which pretends non l4 header. This is suboptimal for precise packet length estimation (introduced in 1def9238 : net_sched: more precise pkt_len computation) which needs correct l4 header for gso packets. The patch just reuse the header probed by netback for partial checksum packets and tries to use skb_flow_dissect() for other cases, if both fail, just pretend no l4 header. Signed-off-by:
-
Jason Wang authored
[ Upstream commit c1aad275 ] Set the transport header for 1) some drivers (e.g ixgbe needs l4 header to do atr) 2) precise packet length estimation (introduced in 1def9238 ) needs l4 header to compute header length. So this patch first tries to get l4 header for packet socket through skb_flow_dissect(), and pretend no l4 header if skb_flow_dissect() fails. Signed-off-by:
-
Jason Wang authored
[ Upstream commit 38502af7 ] Currently, for the packets receives from tuntap, before doing header check, kernel just reset the transport header in netif_receive_skb() which pretends no l4 header. This is suboptimal for precise packet length estimation (introduced in 1def9238 ) which needs correct l4 header for gso packets. So this patch set the transport header to csum_start for partial checksum packets, otherwise it first try skb_flow_dissect(), if it fails, just reset the transport header. Signed-off-by:
-
Jason Wang authored
[ Upstream commit 9b4d669b ] Set the transport header for 1) some drivers (e.g ixgbe) needs l4 header 2) precise packet length estimation (introduced in 1def9238 ) needs l4 header to compute header length. For the packets with partial checksum, the patch just set the transport header to csum_start. Otherwise tries to use skb_flow_dissect() to get l4 offset, if it fails, just pretend no l4 header. Signed-off-by:
-
Jason Wang authored
[ Upstream commit e8dbad66 ] commit (3be8fbab tuntap: fix error return code in tun_set_iff()) breaks the creation of multiqueue tuntap since it forbids to create more than one queues for a multiqueue tuntap device. We need return 0 instead -EBUSY here since we don't want to re-initialize the device when one or more queues has been already attached. Add a comment and correct the return value to zero. Reported-by:
Jerry Chu <hkchu@google.com> Cc: Jerry Chu <hkchu@google.com> Cc: Wei Yongjun <weiyj.lk@gmail.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Yoshihiro Shimoda authored
[ Upstream commit dd019897 ] This patch fixes an issue that the driver increments the "RX length error" on every buffer in sh_eth_rx() if the R8A7740. This patch also adds a description about the Receive Frame Status bits. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Neil Horman authored
[ Upstream commit c5c7774d ] In commit 2f94aabd (refactor sctp_outq_teardown to insure proper re-initalization) we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the outq structure. Steve West recently asked me why I removed the q->error = 0 initalization from sctp_outq_teardown. I did so because I was operating under the impression that sctp_outq_init would properly initalize that value for us, but it doesn't. sctp_outq_init operates under the assumption that the outq struct is all 0's (as it is when called from sctp_association_init), but using it in __sctp_outq_teardown violates that assumption. We should do a memset in sctp_outq_init to ensure that the entire structure is in a known state there instead. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Reported-by:
"West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com> CC: Vlad Yasevich <vyasevich@gmail.com> CC: netdev@vger.kernel.org CC: davem@davemloft.net Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Guillaume Nault authored
[ Upstream commit a6f79d0f ] PPPoL2TP sockets should comply with the standard send*() return values (i.e. return number of bytes sent instead of 0 upon success). Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Guillaume Nault authored
[ Upstream commit 55b92b7a ] Copy user data after PPP framing header. This prevents erasure of the added PPP header and avoids leaking two bytes of uninitialised memory at the end of skb's data buffer. Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 2dc85bf3 ] uaddr->sa_data is exactly of size 14, which is hard-coded here and passed as a size argument to strncpy(). A device name can be of size IFNAMSIZ (== 16), meaning we might leave the destination string unterminated. Thus, use strlcpy() and also sizeof() while we're at it. We need to memset the data area beforehand, since strlcpy does not padd the remaining buffer with zeroes for user space, so that we do not possibly leak anything. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Jiri Pirko authored
[ Upstream commit 72df935d ] team_port_enable() adds port to port_hashlist. Reader sees port in team_get_port_by_index_rcu() and returns it, but team_get_first_port_txable_rcu() tries to go through port_list, where the port is not inserted yet -> NULL pointer dereference. Fix this by reordering port_list and port_hashlist insertion. Panic is easily triggeable when txing packets and adding/removing port in a loop. Introduced by commit 3d249d4c "net: introduce ethernet teaming device" Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Jiri Pirko authored
[ Upstream commit 76c455de ] team_get_port_by_index_rcu() might return NULL due to race between port removal and skb tx path. Panic is easily triggeable when txing packets and adding/removing port in a loop. introduced by commit 3d249d4c "net: introduce ethernet teaming device" and commit 753f9939 "team: introduce random mode" (for random mode) Signed-off-by:
-
Jason Wang authored
[ Upstream commit 19a6afb2 ] Commit 54f968d6 (tuntap: move socket to tun_file) forgets to set SOCK_ZEROCOPY flag, which will prevent vhost_net from doing zercopy w/ tap. This patch fixes this by setting it during file open. Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 1abd165e ] While stress testing sctp sockets, I hit the following panic: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp] PGD 7cead067 PUD 7ce76067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: sctp(F) libcrc32c(F) [...] CPU: 7 PID: 2950 Comm: acc Tainted: GF 3.10.0-rc2+ #1 Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011 task: ffff88007ce0e0c0 ti: ffff88007b568000 task.ti: ffff88007b568000 RIP: 0010:[<ffffffffa0490c4e>] [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp] RSP: 0018:ffff88007b569e08 EFLAGS: 00010292 RAX: 0000000000000000 RBX: ffff88007db78a00 RCX: dead000000200200 RDX: ffffffffa049fdb0 RSI: ffff8800379baf38 RDI: 0000000000000000 RBP: ffff88007b569e18 R08: ffff88007c230da0 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff880077990d00 R14: 0000000000000084 R15: ffff88007db78a00 FS: 00007fc18ab61700(0000) GS:ffff88007fc60000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000020 CR3: 000000007cf9d000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffff88007b569e38 ffff88007db78a00 ffff88007b569e38 ffffffffa049fded ffffffff81abf0c0 ffff88007db78a00 ffff88007b569e58 ffffffff8145b60e 0000000000000000 0000000000000000 ffff88007b569eb8 ffffffff814df36e Call Trace: [<ffffffffa049fded>] sctp_destroy_sock+0x3d/0x80 [sctp] [<ffffffff8145b60e>] sk_common_release+0x1e/0xf0 [<ffffffff814df36e>] inet_create+0x2ae/0x350 [<ffffffff81455a6f>] __sock_create+0x11f/0x240 [<ffffffff81455bf0>] sock_create+0x30/0x40 [<ffffffff8145696c>] SyS_socket+0x4c/0xc0 [<ffffffff815403be>] ? do_page_fault+0xe/0x10 [<ffffffff8153cb32>] ? page_fault+0x22/0x30 [<ffffffff81544e02>] system_call_fastpath+0x16/0x1b Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48> 8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48 RIP [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp] RSP <ffff88007b569e08> CR2: 0000000000000020 ---[ end trace e0d71ec1108c1dd9 ]--- I did not hit this with the lksctp-tools functional tests, but with a small, multi-threaded test program, that heavily allocates, binds, listens and waits in accept on sctp sockets, and then randomly kills some of them (no need for an actual client in this case to hit this). Then, again, allocating, binding, etc, and then killing child processes. This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable'' is set. The cause for that is actually very simple: in sctp_endpoint_init() we enter the path of sctp_auth_init_hmacs(). There, we try to allocate our crypto transforms through crypto_alloc_hash(). In our scenario, it then can happen that crypto_alloc_hash() fails with -EINTR from crypto_larval_wait(), thus we bail out and release the socket via sk_common_release(), sctp_destroy_sock() and hit the NULL pointer dereference as soon as we try to access members in the endpoint during sctp_endpoint_free(), since endpoint at that time is still NULL. Now, if we have that case, we do not need to do any cleanup work and just leave the destruction handler. Signed-off-by:
-
Jason Wang authored
[ Upstream commit 4364d5f9 ] When we decide not use zero-copy, msg.control should be set to NULL otherwise macvtap/tap may set zerocopy callbacks which may decrease the kref of ubufs wrongly. Bug were introduced by commit cedb9bdc (vhost-net: skip head management if no outstanding). This solves the following warnings: WARNING: at include/linux/kref.h:47 handle_tx+0x477/0x4b0 [vhost_net]() Modules linked in: vhost_net macvtap macvlan tun nfsd exportfs bridge stp llc openvswitch kvm_amd kvm bnx2 megaraid_sas [last unloaded: tun] CPU: 5 PID: 8670 Comm: vhost-8668 Not tainted 3.10.0-rc2+ #1566 Hardware name: Dell Inc. PowerEdge R715/00XHKG, BIOS 1.5.2 04/19/2011 ffffffffa0198323 ffff88007c9ebd08 ffffffff81796b73 ffff88007c9ebd48 ffffffff8103d66b 000000007b773e20 ffff8800779f0000 ffff8800779f43f0 ffff8800779f8418 000000000000015c 0000000000000062 ffff88007c9ebd58 Call Trace: [<ffffffff81796b73>] dump_stack+0x19/0x1e [<ffffffff8103d66b>] warn_slowpath_common+0x6b/0xa0 [<ffffffff8103d6b5>] warn_slowpath_null+0x15/0x20 [<ffffffffa0197627>] handle_tx+0x477/0x4b0 [vhost_net] [<ffffffffa0197690>] handle_tx_kick+0x10/0x20 [vhost_net] [<ffffffffa019541e>] vhost_worker+0xfe/0x1a0 [vhost_net] [<ffffffffa0195320>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net] [<ffffffffa0195320>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net] [<ffffffff81061f46>] kthread+0xc6/0xd0 [<ffffffff81061e80>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff817a1aec>] ret_from_fork+0x7c/0xb0 [<ffffffff81061e80>] ? kthread_freezable_should_stop+0x70/0x70 Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 5343a7f8 ] commit 56b765b7 ("htb: improved accuracy at high rates") added another regression for low rates, because it mixes 1ns and 64ns time units. So the maximum delay (mbuffer) was not 60 second, but 937 ms. Lets convert all time fields to 1ns as 64bit arches are becoming the norm. Reported-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Tested-by:
-
Gao feng authored
[ Upstream commit 534c8779 ] Commit 25fb6ca4 "net IPv6 : Fix broken IPv6 routing table after loopback down-up" forgot to assign rt6_info to the inet6_ifaddr. When disable the net device, the rt6_info which allocated in init_loopback will not be destroied in __ipv6_ifa_notify. This will trigger the waring message below [23527.916091] unregister_netdevice: waiting for tap0 to become free. Usage count = 1 Reported-by:
Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Signed-off-by:
Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 01cb71d2 ] commit 56b765b7 ("htb: improved accuracy at high rates") broke the "overhead xxx" handling, as well as the "linklayer atm" attribute. tc class add ... htb rate X ceil Y linklayer atm overhead 10 This patch restores the "overhead xxx" handling, for htb, tbf and act_police The "linklayer atm" thing needs a separate fix. Reported-by:
-
Eric Dumazet authored
[ Upstream commit c87a124a ] Roman Gushchin discovered that udp4_lib_lookup2() was not reloading first item in the rcu protected list, in case the loop was restarted. This produced soft lockups as in https://lkml.org/lkml/2013/4/16/37 rcu_dereference(X)/ACCESS_ONCE(X) seem to not work as intended if X is ptr->field : In some cases, gcc caches the value or ptr->field in a register. Use a barrier() to disallow such caching, as documented in Documentation/atomic_ops.txt line 114 Thanks a lot to Roman for providing analysis and numerous patches. Diagnosed-by:
Roman Gushchin <klamm@yandex-team.ru> Signed-off-by:
Boris Zhmurov <zhmurov@yandex-team.ru> Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Pravin B Shelar authored
[ Upstream commit 1e2bd517 ] udp6 over GRE tunnel does not work after to GRE tso changes. GRE tso handler passes inner packet but keeps track of outer header start in SKB_GSO_CB(skb)->mac_offset. udp6 fragment need to take care of outer header, which start at the mac_offset, while adding fragment header. This bug is introduced by commit 68c33163 (GRE: Add TCP segmentation offload for GRE). Reported-by:
Dmitry Kravkov <dkravkov@gmail.com> Signed-off-by:
Pravin B Shelar <pshelar@nicira.com> Tested-by:
Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by:
-
Jason Wang authored
[ Upstream commit 8e6d91ae ] We currently allow changing the mq flag (IFF_MULTI_QUEUE) for a persistent device. This will result a mismatch between the number the queues in netdev and tuntap. This is because we only allocate a 1q netdevice when IFF_MULTI_QUEUE was not specified, so when we set the IFF_MULTI_QUEUE and try to attach more queues later, netif_set_real_num_tx_queues() may fail which result a single queue netdevice with multiple sockets attached. Solve this by disallowing changing the mq flag for persistent device. Bug was introduced by commit edfb6a14 (tuntap: reduce memory using of queues). Reported-by:
Sriram Narasimhan <sriram.narasimhan@hp.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Federico Vaga authored
[ Upstream commit 456db6a4 ] The three arrays of strings: af_family_key_strings, af_family_slock_key_strings and af_family_clock_key_strings have not VSOCK's string Signed-off-by:
Federico Vaga <federico.vaga@gmail.com> Signed-off-by:
-
Andy Lutomirski authored
[ Upstream commits 1be374a0 and a7526eb5 ] MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API -- it's a hack that steals a bit to indicate to other networking code that a compat entry was used. So don't allow it from a non-compat syscall. This prevents an oops when running this code: int main() { int s; struct sockaddr_in addr; struct msghdr *hdr; char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0); if (highpage == MAP_FAILED) err(1, "mmap"); s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); if (s == -1) err(1, "socket"); addr.sin_family = AF_INET; addr.sin_port = htons(1); addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); if (connect(s, (struct sockaddr*)&addr, sizeof(addr)) != 0) err(1, "connect"); void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE; printf("Evil address is %p\n", evil); if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0) err(1, "sendmmsg"); return 0; } Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Michal Kubecek authored
[ Upstream commit f96ef988 ] Unlike ipv4_redirect() and ipv4_sk_redirect(), ip_do_redirect() doesn't call __build_flow_key() directly but via ip_rt_build_flow_key() wrapper. This leads to __build_flow_key() getting pointer to IPv4 header of the ICMP redirect packet rather than pointer to the embedded IPv4 header of the packet initiating the redirect. As a result, handling of ICMP redirects initiated by TCP packets is broken. Issue was introduced by 4895c771 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
