aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2013-06-27spi/pxa2xx: fix memory corruption due to wrong size used in devm_kzalloc()Mika Westerberg
commit cc0ee9873c6afafb387379ca1df25da78a08c603 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>
2013-06-27spi/pxa2xx: use GFP_ATOMIC in sg table allocationMika Westerberg
commit 5548f98c46538d1da04eff179a52e50537d11465 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: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27drivers: uio: Fix UIO device registration failureDamian Hobson-Garcia
commit 5ed0505c713805f89473cdc0bbfb5110dfd840cb 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27rbd: use the correct length for format 2 object namesJosh Durgin
commit 3a96d5cd7bdce45d5dded75c3a62d4fb98050280 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 78c2a44 since 3.10-rc1, and 78c2a44 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer()Joern Engel
commit 574780fd5e6ec52bd43e0bdb777a19e4c4c6aa9c 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>
2013-06-27tty: Fix transient pty write() EIOPeter Hurley
commit 7c61c3d8f44d5d822f758754287af644307b4af9 upstream. Commit 699390354da6c258b65bf8fa79cfd5feaede50b6 ('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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27tcm_qla2xxx: Fix residual for underrun commands that failRoland Dreier
commit b5aff3d2747bea08b386edd070941a45611ffe51 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: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27firmware loader: fix use-after-free by double abortMing Lei
commit 875979368eb4cfecff9f0e97625b90cc6009269d 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cableAnders Hammarquist
commit 35a2fbc941accd0e9f1bfadd669311786118d874 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27Input: xpad - fix for "Mad Catz Street Fighter IV FightPad" controllersShawn Joseph
commit be66227151c0cd4da536098c3ee07809101c6faa 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27Input: add missing dependencies on CONFIG_HAS_IOMEMBen Hutchings
commit 150e5928d6063b273a80d9d6722417ac3c93ff82 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: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27Input: cyttsp - fix memcpy size paramFerruh Yigit
commit d2983cdb480157f637df07723f28aaa657b1080d 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: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27netback: set transport header before passing it to kernelJason Wang
[ Upstream commit f9ca8f74399f9195fd8e01f67a8424a8d33efa55 ] 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 <jasowang@redhat.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27tuntap: set transport header before passing it to kernelJason Wang
[ Upstream commit 38502af77e07b5d6650b9ff99a0b482d86366592 ] 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 <jasowang@redhat.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27macvtap: set transport header before passing skb to lower deviceJason Wang
[ Upstream commit 9b4d669bc06c215d64f56f1eb0d4eb96e14d689d ] 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 <jasowang@redhat.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27tuntap: correct the return value in tun_set_iff()Jason Wang
[ Upstream commit e8dbad66ef56074eadb41ed5998acd2320447018 ] 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: Jason Wang <jasowang@redhat.com> Acked-by: Jerry Chu <hkchu@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27net: sh_eth: fix incorrect RX length error if R8A7740Yoshihiro Shimoda
[ Upstream commit dd019897358b815f7828dab90b51d51df4d3658d ] 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: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27team: move add to port list before port enablementJiri Pirko
[ Upstream commit 72df935d985c1575ed44ad2c8c653b28147993fa ] 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: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27team: check return value of team_get_port_by_index_rcu() for NULLJiri Pirko
[ Upstream commit 76c455decbbad31de21c727edb184a963f42b40b ] 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 3d249d4ca "net: introduce ethernet teaming device" and commit 753f993911b "team: introduce random mode" (for random mode) Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27tuntap: set SOCK_ZEROCOPY flag during openJason Wang
[ Upstream commit 19a6afb23e5d323e1245baa4e62755492b2f1200 ] Commit 54f968d6efdbf7dec36faa44fc11f01b0e4d1990 (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: Jason Wang <jasowang@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27vhost_net: clear msg.control for non-zerocopy case during txJason Wang
[ Upstream commit 4364d5f96eed7994a2c625bd9216656e55fba0cb ] 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 cedb9bdce099206290a2bdd02ce47a7b253b6a84 (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: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27tuntap: forbid changing mq flag for persistent deviceJason Wang
[ Upstream commit 8e6d91ae0917bf934ed86411148f79d904728d51 ] 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 edfb6a148ce62e5e19354a1dcd9a34e00815c2a1 (tuntap: reduce memory using of queues). Reported-by: Sriram Narasimhan <sriram.narasimhan@hp.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27net: phy: fix a bug when verify the EEE supportGiuseppe CAVALLARO
[ Upstream commit 9a9c56cb34e65000d1f0a4b7553399bfcf7c5a52 ] The phy_init_eee has to exit with an error when the local device and its link partner both do not support EEE. So this patch fixes a problem when verify this. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-278139cp: reset BQL when ring tx ring clearedstephen hemminger
[ Upstream commit 98962baad72fd6d393bf39dbb7c2076532c363c6 ] This patch cures transmit timeout's with DHCP observed while running under KVM. When the transmit ring is cleaned out, the Byte Queue Limit values need to be reset. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27r8169: fix offloaded tx checksum for small packets.Francois Romieu
[ Upstream commit b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 ] 8168evl offloaded checksums are wrong since commit e5195c1f31f399289347e043d6abf3ffa80f0005 ("r8169: fix 8168evl frame padding.") pads small packets to 60 bytes (without ethernet checksum). Typical symptoms appear as UDP checksums which are wrong by the count of added bytes. It isn't worth compensating. Let the driver checksum. Due to the skb length changes, TSO code is moved before the Tx descriptor gets written. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Holger Hoffstätte <holger.hoffstaette@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27vxlan: Update vxlan fdb 'used' field after each usageSridhar Samudrala
[ Upstream commit 014be2c8eac3381e202f684c1f35ae184a8b152b ] Fix some instances where vxlan fdb 'used' field is not updated after the entry is used. v2: rename vxlan_find_mac() as __vxlan_find_mac() and create a new vxlan_find_mac() that also updates ->used field. Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27gianfar: add missing iounmap() on error in gianfar_ptp_probe()Wei Yongjun
[ Upstream commit e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e ] Add the missing iounmap() before return from gianfar_ptp_probe() in the error handling case. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27net: fec: fix kernel oops when plug/unplug cable many timesFrank Li
[ Upstream commits 54309fa60b5f57b90c1842176f6045e665d21142 and 3169134478a9638baf0dbb4fdca5a0718cbe8e27 ] reproduce steps 1. flood ping from other machine ping -f -s 41000 IP 2. run below script while [ 1 ]; do ethtool -s eth0 autoneg off; sleep 3;ethtool -s eth0 autoneg on; sleep 4; done; You can see oops in one hour. The reason is fec_restart clear BD but NAPI may use it. The solution is disable NAPI and stop xmit when reset BD. disable NAPI may sleep, so fec_restart can't be call in atomic context. Signed-off-by: Frank Li <Frank.Li@freescale.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27drm/radeon: update lockup tracking when scheduling in empty ringJerome Glisse
commit 8444d5c69549aa0f0b574cc608742d4669e1cc01 upstream. There might be issue with lockup detection when scheduling on an empty ring that have been sitting idle for a while. Thus update the lockup tracking data when scheduling new work in an empty ring. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Tested-by: Andy Lutomirski <luto@amacapital.net> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27drm/radeon: do not try to uselessly update virtual memory pagetableJerome Glisse
commit 3813f5ca9ab7a00e80a17aab34f155453c66c78a upstream. If a buffer is never bound to a virtual memory pagetable than don't try to unbind it. Only drawback is that we don't update the pagetable when unbinding the ib pool buffer which is fine because it only happens at suspend or module unload/shutdown. Fixes spurious messages about buffers without VM mappings. E.g.: radeon 0000:01:00.0: bo ffff88020afac400 don't has a mapping in vm ffff88021ca2b900 Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27drm/prime: Honor requested file flags when exporting a bufferLaurent Pinchart
commit ebc0bad4a05ad63979e8bc115cea3b8abdf814c7 upstream. The DRM PRIME API passes file flags to the driver for the exported buffer. Honor them instead of hardcoding 0600. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27ACPI / PM: Fix error code path for power resources initializationRafael J. Wysocki
commit 6ee22e9d59151550a55d370b14109bdae8b58bda upstream. Commit 781d737 (ACPI: Drop power resources driver) introduced a bug in the power resources initialization error code path causing a NULL pointer to be referenced in acpi_release_power_resource() if there's an error triggering a jump to the 'err' label in acpi_add_power_resource(). This happens because the list_node field of struct acpi_power_resource has not been initialized yet at this point and doing a list_del() on it is a bad idea. To prevent this problem from occuring, initialize the list_node field of struct acpi_power_resource upfront. Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27ACPI / dock: Take ACPI scan lock in write_undock()Rafael J. Wysocki
commit 8112006f41fd76ddf4988f8ddd904563db85613c upstream. Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be called under acpi_scan_lock, but currently the following scenario violating that requirement is possible: write_undock() handle_eject_request() hotplug_dock_devices() dock_remove_acpi_device() acpi_bus_trim() Fix that by making write_undock() acquire acpi_scan_lock before calling handle_eject_request() as appropriate (begin_undock() is under the lock too in analogy with acpi_dock_deferred_cb()). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resourcesMika Westerberg
commit 204ebc0aa30a7115f300cac39fbb7eeb66524881 upstream. acpi_get_override_irq() was added because there was a problem with buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The commit that added the workaround was 61fd47e0c8476 (ACPI: fix two IRQ8 issues in IOAPIC mode). With ACPI 5 enumerated devices there are typically one or more extended IRQ resources per device (and these IRQs can be shared). However, the acpi_get_override_irq() workaround forces all IRQs in range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high as can be seen from the dmesg below: ACPI: IRQ 6 override to edge, high ACPI: IRQ 7 override to edge, high ACPI: IRQ 7 override to edge, high ACPI: IRQ 13 override to edge, high Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows the same thing: 7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00 The _CSR method for INT33C2 (and INT33C3) device returns following resource: Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, ) { 0x00000007, } which states that this is supposed to be level triggered, active low, shared IRQ instead. Fix this by making sure that acpi_get_override_irq() gets only called when we are dealing with legacy IRQ() or IRQNoFlags() descriptors. While we are there, correct pr_warning() to print the right triggering value. This change turns out to be necessary to make DMA work correctly on systems based on the Intel Lynxpoint PCH (Platform Controller Hub). [rjw: Changelog] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27carl9170: fix frame drop and WARN due to minstrel_ht changeChristian Lamparter
commit 5f34608fa2acbfef5a06d0072a978c9943c28a2d upstream. With "mac80211/minstrel_ht: add support for using CCK rates" minstrel_ht selects legacy CCK rates as viable rates for outgoing frames which might be sent as part of an A-MPDU [IEEE80211_TX_CTL_AMPDU is set]. This behavior triggered the following WARN_ON in the driver: > WARNING: at carl9170/tx.c:995 carl9170_op_tx+0x1dd/0x6fd The driver assumed that the rate control algorithm made a mistake and dropped the frame. This patch removes the noisy warning altogether and allows said A-MPDU frames with CCK sample and/or fallback rates to be transmitted seamlessly. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27parisc: fix serial ports on C8000 workstationThomas Bogendoerfer
commit 9a66d1869d90f13fbaf83dcce5b1aeec86fbc699 upstream. The C8000 workstation (64 bit kernel only) has a somewhat different serial port configuration than other models. Thomas Bogendoerfer sent a patch to fix this in September 2010, which was now minimally modified by me. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27parisc: parport0: fix this legacy no-device port driver!Helge Deller
commit 4edb38695d9a3cd62739f8595e21f36f0aabf4c2 upstream. Fix the above kernel error from parport_announce_port() on 32bit GSC machines (e.g. B160L). The parport driver requires now a pointer to the device struct. Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27brcmfmac: Turn off ARP offloading when configured for AP.Hante Meuleman
commit b3657453f16a7b84eab9b93bb9a9a2901ffc70af upstream. ARP offloading should only be used in STA or P2P client mode. It is currently configured once at init. When being configured for AP ARP offloading should be turned off and when AP mode is left it can be turned back on. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1) networksLarry Finger
commit 5b8df24e22e0b00b599cb9ae63dbb96e1959be30 upstream. Driver rtl8192cu can connect to WPA2 networks, but fails for any other encryption method. The cause is a failure to set the rate control data blocks. These changes fix https://bugzilla.redhat.com/show_bug.cgi?id=952793 and https://bugzilla.redhat.com/show_bug.cgi?id=761525. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27clk: remove notifier from list before freeing itLai Jiangshan
commit 72b5322f11ff0abf6a52b3007486656578d2c982 upstream. The @cn is stay in @clk_notifier_list after it is freed, it cause memory corruption. Example, if @clk is registered(first), unregistered(first), registered(second), unregistered(second). The freed @cn will be used when @clk is registered(second), and the bug will be happened when @clk is unregistered(second): [ 517.040000] clk_notif_dbg clk_notif_dbg.1: clk_notifier_unregister() [ 517.040000] Unable to handle kernel paging request at virtual address 00df3008 [ 517.050000] pgd = ed858000 [ 517.050000] [00df3008] *pgd=00000000 [ 517.060000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 517.060000] Modules linked in: clk_notif_dbg(O-) [last unloaded: clk_notif_dbg] [ 517.060000] CPU: 1 PID: 499 Comm: modprobe Tainted: G O 3.10.0-rc3-00119-ga93cb29-dirty #85 [ 517.060000] task: ee1e0180 ti: ee3e6000 task.ti: ee3e6000 [ 517.060000] PC is at srcu_readers_seq_idx+0x48/0x84 [ 517.060000] LR is at srcu_readers_seq_idx+0x60/0x84 [ 517.060000] pc : [<c0052720>] lr : [<c0052738>] psr: 80070013 [ 517.060000] sp : ee3e7d48 ip : 00000000 fp : ee3e7d6c [ 517.060000] r10: 00000000 r9 : ee3e6000 r8 : 00000000 [ 517.060000] r7 : ed84fe4c r6 : c068ec90 r5 : c068e430 r4 : 00000000 [ 517.060000] r3 : 00df3000 r2 : 00000000 r1 : 00000002 r0 : 00000000 [ 517.060000] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 517.060000] Control: 18c5387d Table: 2d85804a DAC: 00000015 [ 517.060000] Process modprobe (pid: 499, stack limit = 0xee3e6238) [ 517.060000] Stack: (0xee3e7d48 to 0xee3e8000) .... [ 517.060000] [<c0052720>] (srcu_readers_seq_idx+0x48/0x84) from [<c0052790>] (try_check_zero+0x34/0xfc) [ 517.060000] [<c0052790>] (try_check_zero+0x34/0xfc) from [<c00528b0>] (srcu_advance_batches+0x58/0x114) [ 517.060000] [<c00528b0>] (srcu_advance_batches+0x58/0x114) from [<c0052c30>] (__synchronize_srcu+0x114/0x1ac) [ 517.060000] [<c0052c30>] (__synchronize_srcu+0x114/0x1ac) from [<c0052d14>] (synchronize_srcu+0x2c/0x34) [ 517.060000] [<c0052d14>] (synchronize_srcu+0x2c/0x34) from [<c0053a08>] (srcu_notifier_chain_unregister+0x68/0x74) [ 517.060000] [<c0053a08>] (srcu_notifier_chain_unregister+0x68/0x74) from [<c0375a78>] (clk_notifier_unregister+0x7c/0xc0) [ 517.060000] [<c0375a78>] (clk_notifier_unregister+0x7c/0xc0) from [<bf008034>] (clk_notif_dbg_remove+0x34/0x9c [clk_notif_dbg]) [ 517.060000] [<bf008034>] (clk_notif_dbg_remove+0x34/0x9c [clk_notif_dbg]) from [<c02bb974>] (platform_drv_remove+0x24/0x28) [ 517.060000] [<c02bb974>] (platform_drv_remove+0x24/0x28) from [<c02b9bf8>] (__device_release_driver+0x8c/0xd4) [ 517.060000] [<c02b9bf8>] (__device_release_driver+0x8c/0xd4) from [<c02ba680>] (driver_detach+0x9c/0xc4) [ 517.060000] [<c02ba680>] (driver_detach+0x9c/0xc4) from [<c02b99c4>] (bus_remove_driver+0xcc/0xfc) [ 517.060000] [<c02b99c4>] (bus_remove_driver+0xcc/0xfc) from [<c02bace4>] (driver_unregister+0x54/0x78) [ 517.060000] [<c02bace4>] (driver_unregister+0x54/0x78) from [<c02bbb44>] (platform_driver_unregister+0x1c/0x20) [ 517.060000] [<c02bbb44>] (platform_driver_unregister+0x1c/0x20) from [<bf0081f8>] (clk_notif_dbg_driver_exit+0x14/0x1c [clk_notif_dbg]) [ 517.060000] [<bf0081f8>] (clk_notif_dbg_driver_exit+0x14/0x1c [clk_notif_dbg]) from [<c00835e4>] (SyS_delete_module+0x200/0x28c) [ 517.060000] [<c00835e4>] (SyS_delete_module+0x200/0x28c) from [<c000edc0>] (ret_fast_syscall+0x0/0x48) [ 517.060000] Code: e5973004 e7911102 e0833001 e2881002 (e7933101) Reported-by: Sören Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Tested-by: Sören Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Mike Turquette <mturquette@linaro.org> [mturquette@linaro.org: shortened $SUBJECT] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20tg3: Wait for boot code to finish after power onNithin Sujir
commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917 upstream. Some systems that don't need wake-on-lan may choose to power down the chip on system standby. Upon resume, the power on causes the boot code to startup and initialize the hardware. On one new platform, this is causing the device to go into a bad state due to a race between the driver and boot code, once every several hundred resumes. The same race exists on open since we come up from a power on. This patch adds a wait for boot code signature at the beginning of tg3_init_hw() which is common to both cases. If there has not been a power-off or the boot code has already completed, the signature will be present and poll_fw() returns immediately. Also return immediately if the device does not have firmware. Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20USB: spcp8x5: fix device initialisation at openJohan Hovold
commit 5e4211f1c47560c36a8b3d4544dfd866dcf7ccd0 upstream. Do not use uninitialised termios data to determine when to configure the device at open. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20USB: f81232: fix device initialisation at openJohan Hovold
commit 21886725d58e92188159731c7c1aac803dd6b9dc upstream. Do not use uninitialised termios data to determine when to configure the device at open. This also prevents stack data from leaking to userspace. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20USB: pl2303: fix device initialisation at openJohan Hovold
commit 2d8f4447b58bba5f8cb895c07690434c02307eaf upstream. Do not use uninitialised termios data to determine when to configure the device at open. This also prevents stack data from leaking to userspace in the OOM error path. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20usb: chipidea: fix id change handlingAlexander Shishkin
commit 0c3f3dc68bb6e6950e8cd7851e7778c550e8dfb4 upstream. Re-enable chipidea irq even if there's no role changing to do. This is a problem since b183c19f ("USB: chipidea: re-order irq handling to avoid unhandled irqs"); when it manifests, chipidea irq gets disabled for good. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20drm/nv50/kms: use dac loadval from vbios, where it's availableBen Skeggs
commit d40ee48acde16894fb3b241d7e896d5fa84e0f10 upstream. Regression from merging the old nv50/nvd9 code together, and may be needed to fully fix fdo#64904. The value is ignored completely by the hardware starting from nva3. Reported-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-06-20drm/nv50/disp: force dac power state during load detectBen Skeggs
commit ea9197cc323839ef3d5280c0453b2c622caa6bc7 upstream. fdo#64904 Reported-by: Gerhard Bräunlich <wippbox@gmx.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-06-20md/raid1,raid10: use freeze_array in place of raise_barrier in various places.NeilBrown
commit e2d59925221cd562e07fee38ec8839f7209ae603 upstream. Various places in raid1 and raid10 are calling raise_barrier when they really should call freeze_array. The former is only intended to be called from "make_request". The later has extra checks for 'nr_queued' and makes a call to flush_pending_writes(), so it is safe to call it from within the management thread. Using raise_barrier will sometimes deadlock. Using freeze_array should not. As 'freeze_array' currently expects one request to be pending (in handle_read_error - the only previous caller), we need to pass it the number of pending requests (extra) to ignore. The deadlock was made particularly noticeable by commits 050b66152f87c7 (raid10) and 6b740b8d79252f13 (raid1) which appeared in 3.4, so the fix is appropriate for any -stable kernel since then. This patch probably won't apply directly to some early kernels and will need to be applied by hand. Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20md/raid1,5,10: Disable WRITE SAME until a recovery strategy is in placeH. Peter Anvin
commit 5026d7a9b2f3eb1f9bda66c18ac6bc3036ec9020 upstream. There are cases where the kernel will believe that the WRITE SAME command is supported by a block device which does not, in fact, support WRITE SAME. This currently happens for SATA drivers behind a SAS controller, but there are probably a hundred other ways that can happen, including drive firmware bugs. After receiving an error for WRITE SAME the block layer will retry the request as a plain write of zeroes, but mdraid will consider the failure as fatal and consider the drive failed. This has the effect that all the mirrors containing a specific set of data are each offlined in very rapid succession resulting in data loss. However, just bouncing the request back up to the block layer isn't ideal either, because the whole initial request-retry sequence should be inside the write bitmap fence, which probably means that md needs to do its own conversion of WRITE SAME to write zero. Until the failure scenario has been sorted out, disable WRITE SAME for raid1, raid5, and raid10. [neilb: added raid5] This patch is appropriate for any -stable since 3.7 when write_same support was added. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-20md/raid1: consider WRITE as successful only if at least one non-Faulty and ↵Alex Lyakas
non-rebuilding drive completed it. commit 3056e3aec8d8ba61a0710fb78b2d562600aa2ea7 upstream. Without that fix, the following scenario could happen: - RAID1 with drives A and B; drive B was freshly-added and is rebuilding - Drive A fails - WRITE request arrives to the array. It is failed by drive A, so r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B succeeds in writing it, so the same r1_bio is marked as R1BIO_Uptodate. - r1_bio arrives to handle_write_finished, badblocks are disabled, md_error()->error() does nothing because we don't fail the last drive of raid1 - raid_end_bio_io() calls call_bio_endio() - As a result, in call_bio_endio(): if (!test_bit(R1BIO_Uptodate, &r1_bio->state)) clear_bit(BIO_UPTODATE, &bio->bi_flags); this code doesn't clear the BIO_UPTODATE flag, and the whole master WRITE succeeds, back to the upper layer. So we returned success to the upper layer, even though we had written the data onto the rebuilding drive only. But when we want to read the data back, we would not read from the rebuilding drive, so this data is lost. [neilb - applied identical change to raid10 as well] This bug can result in lost data, so it is suitable for any -stable kernel. Signed-off-by: Alex Lyakas <alex@zadarastorage.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-03-28 10:36:36 +0000