- 12 Apr, 2016 40 commits
-
-
Adrian Hunter authored
commit 99513624 upstream. Normally the timeout clock frequency is read from the capabilities register. It is also possible to set the value prior to calling sdhci_add_host() in which case that value will override the capabilities register value. However that was being done after calculating max_busy_timeout so that max_busy_timeout was being calculated using the wrong value of timeout_clk. Fix that by moving the override before max_busy_timeout is calculated. The result is that the max_busy_timeout and max_discard increase for BSW devices so that, for example, the time for mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds to about 20 seconds. Note, in the future, the capabilities setting will be tidied up and this override won't be used anymore. However this fix is needed for stable. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lucas Stach authored
commit 3491b690 upstream. The new code to do the clock rate setting externally to the SDMMC module has a shortcut to not propagate changes with a 0 rate to the CAR by simply bailing out. This breaks proper cutting of the card clock. Fix it by directly calling the correct sdhci function. Fixes: a8e326a9 "mmc: tegra: implement module external clock change" Signed-off-by:
Lucas Stach <dev@lynxeye.de> Acked-by:
-
Jon Hunter authored
commit 7bf037d6 upstream. SD card support for Tegra114 started failing after commit a8e326a9 ("mmc: tegra: implement module external clock change") was merged. This commit was part of a series to enable UHS-I modes for Tegra. To workaround this problem for now, disable UHS-I modes for Tegra114 by separating the soc data structures for Tegra114 and Tegra124 so that UHS-I is still enabled for Tegra124 but not Tegra114. Fixes: a8e326a9 ("mmc: tegra: implement module external clock change") Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Russell King authored
commit 0ca33b4a upstream. Commit 1140011e ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes") broke any chance of the SDR50 or DDR50 modes being used. The commit claims that SDR50 and DDR50 require clock adjustments in the SDIO3 Configuration register, which is located via the "conf-sdio3" resource. However, when this resource is given, we fail to read the host capabilities 1 register, resulting in host->caps1 being zero. Hence, both SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50 bits remain zero, disabling the SDR50 and DDR50 modes. The underlying idea in this function appears to be to read the device capabilities, modify them, and set SDHCI_QUIRK_MISSING_CAPS to cause our modified capabilities to be used. Implement exactly that. Fixes: 1140011e ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes") Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Russell King authored
commit 7f05538a upstream. The calculation for the timeout based on the number of card clocks is incorrect. The calculation assumed: timeout in microseconds = clock cycles / clock in Hz which is clearly a several orders of magnitude wrong. Fix this by multiplying the clock cycles by 1000000 prior to dividing by the Hz based clock. Also, as per part 1, ensure that the division rounds up. As this needs 64-bit math via do_div(), avoid it if the clock cycles is zero. Signed-off-by:
-
Russell King authored
commit fafcfda9 upstream. The data timeout gives the minimum amount of time that should be waited before timing out if no data is received from the card. Simply dividing the nanosecond part by 1000 does not give this required guarantee, since such a division rounds down. Use DIV_ROUND_UP() to give the desired timeout. Signed-off-by:
-
Russell King authored
commit 054cedff upstream. If we terminate a command early, we fail to properly clean up the DMA mappings for the data part of the request. Put this clean up to the tasklet, which is the common path for finishing a request so we always clean up after ourselves. Signed-off-by:
-
Russell King authored
commit edd63fcc upstream. Unnecessarily mapping and unmapping the align buffer for SD cards is expensive: performance measurements on iMX6 show that this gives a hit of 10% on hdparm buffered disk reads. MMC/SD card IO comes from the mm/vfs which gives us page based IO, so for this case, the align buffer is not going to be used. However, we still map and unmap this buffer. Eliminate this by switching the align buffer to be a DMA coherent buffer, which needs no DMA maintenance to access the buffer. Signed-off-by:
-
Russell King authored
commit 771a3dc2 upstream. sdhci_post_req() exists to unmap a previously mapped but already finished request, while the next request is in progress. However, the state of the SDHCI_REQ_USE_DMA flag depends on the last submitted request. This means we can end up clearing the flag due to a quirk, which then means that sdhci_post_req() fails to unmap the DMA buffer, potentially leading to data corruption. We can safely ignore the SDHCI_REQ_USE_DMA here, as testing data->host_cookie is entirely sufficient. Signed-off-by:
-
Russell King authored
commit 71fcbda0 upstream. When we get a response CRC error on a command, it means that the response we received back from the card was not correct. It does not mean that the card did not receive the command correctly. If the command is one which initiates a data transfer, the card can enter the data transfer state, and start sending data. Moreover, if the request contained a data phase, we do not clean this up, and this results in the driver triggering DMA API debug warnings, and also creates a race condition in the driver, between running the finish_tasklet and the data transfer interrupts, which can trigger a "Got data interrupt" state dump. Fix this by handing a response CRC error slightly differently: record the failure of the data initiating command, but allow the remainder of the request to be processed normally. This is safe as core MMC checks the status of all commands and data transfer phases of the request. If the card does not initiate a data transfer, then we should time out according to the data transfer parameters. Signed-off-by:
-
Russell King authored
commit ec014cba upstream. Avoid multiple tests while handling a command error; simplify the code. Signed-off-by:
-
Russell King authored
commit 96776200 upstream. When a command is started, logically it has no error. Initialise the command's error member to zero whenever we start a command. Signed-off-by:
-
Magnus Damm authored
commit bcdc9f26 upstream. This patch fixes the MMC SPI driver from doing polling card detect when a CD GPIO that supports interrupts is specified using the gpios DT property. Without this patch the DT node below results in the following output: spi_gpio: spi-gpio { /* SD2 @ CN12 */ compatible = "spi-gpio"; #address-cells = <1>; #size-cells = <0>; gpio-sck = <&gpio6 16 GPIO_ACTIVE_HIGH>; gpio-mosi = <&gpio6 17 GPIO_ACTIVE_HIGH>; gpio-miso = <&gpio6 18 GPIO_ACTIVE_HIGH>; num-chipselects = <1>; cs-gpios = <&gpio6 21 GPIO_ACTIVE_LOW>; status = "okay"; spi@0 { compatible = "mmc-spi-slot"; reg = <0>; voltage-ranges = <3200 3400>; spi-max-frequency = <25000000>; gpios = <&gpio6 22 GPIO_ACTIVE_LOW>; /* CD */ }; }; # dmesg | grep mmc mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling mmc0: host does not support reading read-only switch, assuming write-enable mmc0: new SDHC card on SPI mmcblk0: mmc0:0000 SU04G 3.69 GiB mmcblk0: p1 With this patch applied the "cd polling" portion above disappears. Signed-off-by:
Magnus Damm <damm+renesas@opensource.se> Signed-off-by:
-
Shawn Lin authored
commit 83c742c3 upstream. If mmc_blk_ioctl returns -EINVAL, blkdev_ioctl continues to work without returning err to user-space. But now we check CAP_SYS_RAWIO firstly, so we return -EPERM to blkdev_ioctl, which make blkdev_ioctl return -EPERM to user-space directly. So this will break all the ioctl with BLKROSET. Now we find Android-adb suffer it for the following log: remount of /system failed; couldn't make block device writable: Operation not permitted openat(AT_FDCWD, "/dev/block/platform/ff420000.dwmmc/by-name/system", O_RDONLY) = 3 ioctl(3, BLKROSET, 0) = -1 EPERM (Operation not permitted) Fixes: a5f5774c ("mmc: block: Add new ioctl to send multi commands") Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
-
John Dahlstrom authored
commit 4db9675d upstream. Some Lenovo ideapad models lack a physical rfkill switch. On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK, ideapad-laptop would wrongly report all radios as blocked by hardware which caused wireless network connections to fail. Add these models without an rfkill switch to the no_hw_rfkill list. Signed-off-by:
John Dahlstrom <jodarom@sdf.org> Cc: <stable@vger.kernel.org> # 3.17.x-: 4fa9dabc: ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Guenter Roeck authored
commit 968ce1b1 upstream. The old web page for the hwmon subsystem is no longer operational, and the mailing list has become unreliable. Move both to kernel.org. Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jiri Kosina authored
commit c8b08ca5 upstream. mkspec is copying built kernel to temporrary location /boot/vmlinuz-$KERNELRELEASE-rpm and runs installkernel on it. This however directly leads to grub2 menuentry for this suffixed binary being generated as well during the run of installkernel script. Later in the process the temporary -rpm suffixed files are removed, and therefore we end up with spurious (and non-functional) grub2 menu entries for each installed kernel RPM. Fix that by using a different temporary name (prefixed by '.'), so that the binary is not recognized as an actual kernel binary and no menuentry is created for it. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Fixes: 3c9c7a14 ("rpm-pkg: add %post section to create initramfs and grub hooks") Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
-
Jan Beulich authored
commit 42f9d3c6 upstream. Documentation/Changes still lists this as the minimal required version, so it ought to remain usable for the time being. Fixes: d2036f30 ("scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target") Signed-off-by:
Jan Beulich <jbeulich@suse.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Julia Lawall authored
commit 1b669e71 upstream. & is no longer allowed in column 0, since Coccinelle 1.0.4. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Tested-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Peter Zijlstra authored
commit f75d4864 upstream. __clear_bit_unlock() is a special little snowflake. While it carries the non-atomic '__' prefix, it is specifically documented to pair with test_and_set_bit() and therefore should be 'somewhat' atomic. Therefore the generic implementation of __clear_bit_unlock() cannot use the fully non-atomic __clear_bit() as a default. If an arch is able to do better; is must provide an implementation of __clear_bit_unlock() itself. Specifically, this came up as a result of hackbench livelock'ing in slab_lock() on ARC with SMP + SLUB + !LLSC. The issue was incorrect pairing of atomic ops. slab_lock() -> bit_spin_lock() -> test_and_set_bit() slab_unlock() -> __bit_spin_unlock() -> __clear_bit() The non serializing __clear_bit() was getting "lost" 80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked is set 80543b90: or r3,r2,1 <--- (B) other core unlocks right here 80543b94: st_s r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock) Fixes ARC STAR 9000817404 (and probably more). Reported-by:
Vineet Gupta <Vineet.Gupta1@synopsys.com> Tested-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Christoph Lameter <cl@linux.com> Cc: David Rientjes <rientjes@google.com> Cc: Helge Deller <deller@gmx.de> Cc: James E.J. Bottomley <jejb@parisc-linux.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Noam Camus <noamc@ezchip.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20160309114054.GJ6356@twins.programming.kicks-ass.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 3debb0a9 upstream. The trace_printk() code will allocate extra buffers if the compile detects that a trace_printk() is used. To do this, the format of the trace_printk() is saved to the __trace_printk_fmt section, and if that section is bigger than zero, the buffers are allocated (along with a message that this has happened). If trace_printk() uses a format that is not a constant, and thus something not guaranteed to be around when the print happens, the compiler optimizes the fmt out, as it is not used, and the __trace_printk_fmt section is not filled. This means the kernel will not allocate the special buffers needed for the trace_printk() and the trace_printk() will not write anything to the tracing buffer. Adding a "__used" to the variable in the __trace_printk_fmt section will keep it around, even though it is set to NULL. This will keep the string from being printed in the debugfs/tracing/printk_formats section as it is not needed. Reported-by:
Vlastimil Babka <vbabka@suse.cz> Fixes: 07d777fe "tracing: Add percpu buffers for trace_printk()" Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit a29054d9 upstream. If tracing contains data and the trace_pipe file is read with sendfile(), then it can trigger a NULL pointer dereference and various BUG_ON within the VM code. There's a patch to fix this in the splice_to_pipe() code, but it's also a good idea to not let that happen from trace_pipe either. Link: http://lkml.kernel.org/r/1457641146-9068-1-git-send-email-rabin@rab.inReported-by:
Rabin Vincent <rabin.vincent@gmail.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit cb86e053 upstream. Joel Fernandes reported that the function tracing of preempt disabled sections was not being reported when running either the preemptirqsoff or preemptoff tracers. This was due to the fact that the function tracer callback for those tracers checked if irqs were disabled before tracing. But this fails when we want to trace preempt off locations as well. Joel explained that he wanted to see funcitons where interrupts are enabled but preemption was disabled. The expected output he wanted: <...>-2265 1d.h1 3419us : preempt_count_sub <-irq_exit <...>-2265 1d..1 3419us : __do_softirq <-irq_exit <...>-2265 1d..1 3419us : msecs_to_jiffies <-__do_softirq <...>-2265 1d..1 3420us : irqtime_account_irq <-__do_softirq <...>-2265 1d..1 3420us : __local_bh_disable_ip <-__do_softirq <...>-2265 1..s1 3421us : run_timer_softirq <-__do_softirq <...>-2265 1..s1 3421us : hrtimer_run_pending <-run_timer_softirq <...>-2265 1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq <...>-2265 1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq <...>-2265 1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq <...>-2265 1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq <...>-2265 1..s1 3423us : rcu_bh_qs <-__do_softirq <...>-2265 1d.s1 3423us : irqtime_account_irq <-__do_softirq <...>-2265 1d.s1 3423us : __local_bh_enable <-__do_softirq There's a comment saying that the irq disabled check is because there's a possible race that tracing_cpu may be set when the function is executed. But I don't remember that race. For now, I added a check for preemption being enabled too to not record the function, as there would be no race if that was the case. I need to re-investigate this, as I'm now thinking that the tracing_cpu will always be correct. But no harm in keeping the check for now, except for the slight performance hit. Link: http://lkml.kernel.org/r/1457770386-88717-1-git-send-email-agnel.joel@gmail.com Fixes: 5e6d2b9c "tracing: Use one prologue for the preempt irqs off tracer function tracers" Reported-by:
Joel Fernandes <agnel.joel@gmail.com> Signed-off-by:
-
Eric Huang authored
commit 60123300 upstream. Set the UVD and VCE DPM flags otherwise UVD and VCE DPM won't get enabled. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Eric Huang <JinHuiEric.Huang@amd.com> Signed-off-by:
-
Ken Wang authored
commit 16a8a49b upstream. Signed-off-by:
Ken Wang <Qingqing.Wang@amd.com> Reviewed-by:
-
Alex Deucher authored
commit bedf2a65 upstream. Some PX laptops don't provide an ACPI method to control dGPU power. On those systems, the driver is responsible for handling the dGPU power state. Disable runtime PM on them until support for this is implemented. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Dave Airlie authored
commit b36f7d26 upstream. The function this used changed in 092c96a8 drm/radeon: fix dp link rate selection (v2) However for MST we should just always train to the max link/rate. Though we probably need to limit this for future hw, in theory radeon won't support it. This fixes my 30" monitor with MST enabled. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit e5f243bd upstream. Move all the logic to radeon_fb.c and add checks to functions called frome elsewhere. bug: https://bugzilla.kernel.org/show_bug.cgi?id=112781Signed-off-by:
-
Mario Kleiner authored
commit 459ee1c3 upstream. As observed on Apple iMac10,1, DCE-3.2, RV-730, link rate of 2.7 Ghz is not selected, because the args.v1.ucConfig flag setting for 2.7 Ghz gets overwritten by a following assignment of the transmitter to use. Move link rate setup a few lines down to fix this. In practice this didn't have any positive or negative effect on display setup on the tested iMac10,1 so i don't know if backporting to stable makes sense or not. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit e64c952e upstream. Some PX laptops don't provide an ACPI method to control dGPU power. On those systems, the driver is responsible for handling the dGPU power state. Disable runtime PM on them until support for this is implemented. Reviewed-by:
-
Dan Carpenter authored
commit 585cb132 upstream. The copy_from_user() function returns the number of bytes not copied but we want to return a negative error code. Fixes: 463873d5 ('drm/vc4: Add an API for creating GPU shaders in GEM BOs.') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Aurelien Jacquiot authored
commit 36915976 upstream. Fix deadlocking during concurrent receive and transmit operations on SMP platforms caused by the use of incorrect lock: on transmit 'tx_lock' spinlock should be used instead of 'lock' which is used for receive operation. This fix is applicable to kernel versions starting from v2.15. Signed-off-by:
Aurelien Jacquiot <a-jacquiot@ti.com> Signed-off-by:
Alexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Andre van Herk <andre.van.herk@prodrive-technologies.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jann Horn authored
commit 378c6520 upstream. This commit fixes the following security hole affecting systems where all of the following conditions are fulfilled: - The fs.suid_dumpable sysctl is set to 2. - The kernel.core_pattern sysctl's value starts with "/". (Systems where kernel.core_pattern starts with "|/" are not affected.) - Unprivileged user namespace creation is permitted. (This is true on Linux >=3.8, but some distributions disallow it by default using a distro patch.) Under these conditions, if a program executes under secure exec rules, causing it to run with the SUID_DUMP_ROOT flag, then unshares its user namespace, changes its root directory and crashes, the coredump will be written using fsuid=0 and a path derived from kernel.core_pattern - but this path is interpreted relative to the root directory of the process, allowing the attacker to control where a coredump will be written with root privileges. To fix the security issue, always interpret core_pattern for dumps that are written under SUID_DUMP_ROOT relative to the root directory of init. Signed-off-by:
Jann Horn <jann@thejh.net> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Jan Kiszka authored
commit ad4db3b2 upstream. Commit 7523e4dc ("module: use a structure to encapsulate layout.") factored out the module_layout structure. Adjust the symbol loader and the lsmod command to this. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by:
Kieran Bingham <kieran.bingham@linaro.org> Tested-by: Kieran Bingham <kieran.bingham@linaro.org> (qemu-{ARM,x86}) Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
-
Seth Forshee authored
commit 744742d6 upstream. The 'reqs' member of fuse_io_priv serves two purposes. First is to track the number of oustanding async requests to the server and to signal that the io request is completed. The second is to be a reference count on the structure to know when it can be freed. For sync io requests these purposes can be at odds. fuse_direct_IO() wants to block until the request is done, and since the signal is sent when 'reqs' reaches 0 it cannot keep a reference to the object. Yet it needs to use the object after the userspace server has completed processing requests. This leads to some handshaking and special casing that it needlessly complicated and responsible for at least one race condition. It's much cleaner and safer to maintain a separate reference count for the object lifecycle and to let 'reqs' just be a count of outstanding requests to the userspace server. Then we can know for sure when it is safe to free the object without any handshaking or special cases. The catch here is that most of the time these objects are stack allocated and should not be freed. Initializing these objects with a single reference that is never released prevents accidental attempts to free the objects. Fixes: 9d5722b7 ("fuse: handle synchronous iocbs internally") Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Robert Doebbelin authored
commit 7cabc61e upstream. There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an iocb that could have been freed if async io has already completed. The fix in this case is simple and obvious: cache the result before starting io. It was discovered by KASan: kernel: ================================================================== kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr ffff88036c414390 Signed-off-by:
Robert Doebbelin <robert@quobyte.com> Signed-off-by:
-
Ming Lei authored
commit fafcde3a upstream. Inside multipath_make_request(), multipath maps the incoming bio into low level device's bio, but it is totally wrong to copy the bio into mapped bio via '*mapped_bio = *bio'. For example, .__bi_remaining is kept in the copy, especially if the incoming bio is chained to via bio splitting, so .bi_end_io can't be called for the mapped bio at all in the completing path in this kind of situation. This patch fixes the issue by using clone style. Reported-and-tested-by:
Andrea Righi <righi.andrea@gmail.com> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
-
NeilBrown authored
commit 550da24f upstream. break_stripe_batch_list breaks up a batch and copies some flags from the batch head to the members, preserving others. It doesn't preserve or copy STRIPE_PREREAD_ACTIVE. This is not normally a problem as STRIPE_PREREAD_ACTIVE is cleared when a stripe_head is added to a batch, and is not set on stripe_heads already in a batch. However there is no locking to ensure one thread doesn't set the flag after it has just been cleared in another. This does occasionally happen. md/raid5 maintains a count of the number of stripe_heads with STRIPE_PREREAD_ACTIVE set: conf->preread_active_stripes. When break_stripe_batch_list clears STRIPE_PREREAD_ACTIVE inadvertently this could becomes incorrect and will never again return to zero. md/raid5 delays the handling of some stripe_heads until preread_active_stripes becomes zero. So when the above mention race happens, those stripe_heads become blocked and never progress, resulting is write to the array handing. So: change break_stripe_batch_list to preserve STRIPE_PREREAD_ACTIVE in the members of a batch. URL: https://bugzilla.kernel.org/show_bug.cgi?id=108741 URL: https://bugzilla.redhat.com/show_bug.cgi?id=1258153 URL: http://thread.gmane.org/5649C0E9.2030204@zoner.cz Reported-by: Martin Svec <martin.svec@zoner.cz> (and others) Tested-by:
Tom Weber <linux@junkyard.4t2.com> Fixes: 1b956f7a ("md/raid5: be more selective about distributing flags across batch.") Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
-
Shaohua Li authored
commit 23ddba80 upstream. This is the raid10 counterpart of the bug fixed by Nate (raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang) Fixes: 95af587e(md/raid10: ensure device failure recorded before write request returns) Cc: Nate Dailey <nate.dailey@stratus.com> Signed-off-by:
-
Shaohua Li authored
commit 6ab2a4b8 upstream. Revert commit e9e4c377(md/raid5: per hash value and exclusive wait_for_stripe) The problem is raid5_get_active_stripe waits on conf->wait_for_stripe[hash]. Assume hash is 0. My test release stripes in this order: - release all stripes with hash 0 - raid5_get_active_stripe still sleeps since active_stripes > max_nr_stripes * 3 / 4 - release all stripes with hash other than 0. active_stripes becomes 0 - raid5_get_active_stripe still sleeps, since nobody wakes up wait_for_stripe[0] The system live locks. The problem is active_stripes isn't a per-hash count. Revert the patch makes the live lock go away. Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com> Cc: NeilBrown <neilb@suse.de> Signed-off-by:
-
