- 29 May, 2015 25 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dmLinus Torvalds authored
Pull device-mapper fixes from Mike Snitzer: "Quite a few fixes for DM's blk-mq support thanks to extra DM multipath testing from Junichi Nomura and Bart Van Assche. Also fix a casting bug in dm_merge_bvec() that could cause only a single page to be added to a bio (Joe identified this while testing dm-cache writeback)" * tag 'dm-4.1-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm: fix casting bug in dm_merge_bvec() dm: fix reload failure of 0 path multipath mapping on blk-mq devices dm: fix false warning in free_rq_clone() for unmapped requests dm: requeue from blk-mq dm_mq_queue_rq() using BLK_MQ_RQ_QUEUE_BUSY dm mpath: fix leak of dm_mpath_io structure in blk-mq .queue_rq error path dm: fix NULL pointer when clone_and_map_rq returns !DM_MAPIO_REMAPPED dm: run queue on re-queue
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton: "10 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: scripts/gdb: fix lx-lsmod refcnt omfs: fix potential integer overflow in allocator omfs: fix sign confusion for bitmap loop counter omfs: set error return when d_make_root() fails fs, omfs: add NULL terminator in the end up the token list MAINTAINERS: update CAPABILITIES pattern fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings tracing/mm: don't trace mm_page_pcpu_drain on offline cpus tracing/mm: don't trace mm_page_free on offline cpus tracing/mm: don't trace kmem_cache_free on offline cpus
-
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linuxLinus Torvalds authored
Pull fixes for cpumask and modules from Rusty Russell: "** NOW WITH TESTING! ** Two fixes which got lost in my recent distraction. One is a weird cpumask function which needed to be rewritten, the other is a module bug which is cc:stable" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: cpumask_set_cpu_local_first => cpumask_local_spread, lament module: Call module notifier on failure after complete_formation()
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "This is made up 4 groups of fixes detailed below. vgem: Due to some misgivings about possible bad use cases this allow, backout a chunk of the interface to stop those use cases for now. radeon: Fix for an oops regression in the audio code, and a partial revert for a fix that was cauing problems. nouveau: regression fix for Fermi, and display-less Maxwell boot fixes. drm core: a fix for i915 cursor vblank waiting in the atomic helpers" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau/gr/gm204: remove a stray printk drm/nouveau/devinit/gm100-: force devinit table execution on boards without PDISP drm/nouveau/devinit/gf100: make the force-post condition more obvious drm/nouveau/gr/gf100-: fix wrong constant definition drm/radeon: partially revert "fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling" drm/radeon/audio: make sure connector is valid in hotplug case Revert "drm/radeon: only mark audio as connected if the monitor supports it (v3)" drm/radeon: don't share plls if monitors differ in audio support drm/vgem: drop DRIVER_PRIME (v2) drm/plane-helper: Adapt cursor hack to transitional helpers
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
Pull sound fixes from Takashi Iwai: "No big surprise here, just a bunch of small fixes for HD-audio and USB-audio: - partial revert of widget power-saving for IDT codecs - revert mute-LED enum ctl for Thinkpads due to confusion - a quirk for a new Radeon HDMI controller - Realtek codec name fix for Dell - a workaround for headphone mic boost on some laptops - stream_pm ops setup (and its fix for regression) - another quirk for MS LifeCam USB-audio" * tag 'sound-4.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Fix lost sound due to stream_pm ops cleanup ALSA: hda - Disable Headphone Mic boost for ALC662 ALSA: hda - Disable power_save_node for IDT92HD71bxx ALSA: hda - Fix noise on AMD radeon 290x controller ALSA: hda - Set stream_pm ops automatically by generic parser ALSA: hda/realtek - Add ALC256 alias name for Dell Revert "ALSA: hda - Add mute-LED mode control to Thinkpad" ALSA: usb-audio: Add quirk for MS LifeCam HD-3000
-
Joe Thornber authored
dm_merge_bvec() was originally added in f6fccb ("dm: introduce merge_bvec_fn"). In that commit a value in sectors is converted to bytes using << 9, and then assigned to an int. This code made assumptions about the value of BIO_MAX_SECTORS. A later commit 148e51 ("dm: improve documentation and code clarity in dm_merge_bvec") was meant to have no functional change but it removed the use of BIO_MAX_SECTORS in favor of using queue_max_sectors(). At this point the cast from sector_t to int resulted in a zero value. The fallout being dm_merge_bvec() would only allow a single page to be added to a bio. This interim fix is minimal for the benefit of stable@ because the more comprehensive cleanup of passing a sector_t to all DM targets' merge function will impact quite a few DM targets. Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org # 3.19+
-
Junichi Nomura authored
dm-multipath accepts 0 path mapping. # echo '0 2097152 multipath 0 0 0 0' | dmsetup create newdev Such a mapping can be used to release underlying devices while still holding requests in its queue until working paths come back. However, once the multipath device is created over blk-mq devices, it rejects reloading of 0 path mapping: # echo '0 2097152 multipath 0 0 1 1 queue-length 0 1 1 /dev/sda 1' \ | dmsetup create mpath1 # echo '0 2097152 multipath 0 0 0 0' | dmsetup load mpath1 device-mapper: reload ioctl on mpath1 failed: Invalid argument Command failed With following kernel message: device-mapper: ioctl: can't change device type after initial table load. DM tries to inherit the current table type using dm_table_set_type() but it doesn't work as expected because of unnecessary check about whether the target type is hybrid or not. Hybrid type is for targets that work as either request-based or bio-based and not required for blk-mq or non blk-mq checking. Fixes: 65803c20 ("dm table: train hybrid target type detection to select blk-mq if appropriate") Signed-off-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com>
-
git://neil.brown.name/mdLinus Torvalds authored
Pull m,ore md bugfixes gfrom Neil Brown: "Assorted fixes for new RAID5 stripe-batching functionality. Unfortunately this functionality was merged a little prematurely. The necessary testing and code review is now complete (or as complete as it can be) and to code passes a variety of tests and looks quite sensible. Also a fix for some recent locking changes - a race was introduced which causes a reshape request to sometimes fail. No data safety issues" * tag 'md/4.1-rc5-fixes' of git://neil.brown.name/md: md: fix race when unfreezing sync_action md/raid5: break stripe-batches when the array has failed. md/raid5: call break_stripe_batch_list from handle_stripe_clean_event md/raid5: be more selective about distributing flags across batch. md/raid5: add handle_flags arg to break_stripe_batch_list. md/raid5: duplicate some more handle_stripe_clean_event code in break_stripe_batch_list md/raid5: remove condition test from check_break_stripe_batch_list. md/raid5: Ensure a batch member is not handled prematurely. md/raid5: close race between STRIPE_BIT_DELAY and batching. md/raid5: ensure whole batch is delayed for all required bitmap updates.
-
Mike Snitzer authored
When stacking request-based dm device on non blk-mq device and device-mapper target could not map the request (error target is used, multipath target with all paths down, etc), the WARN_ON_ONCE() in free_rq_clone() will trigger when it shouldn't. The warning was added by commit aa6df8dd ("dm: fix free_rq_clone() NULL pointer when requeueing unmapped request"). But free_rq_clone() with clone->q == NULL is valid usage for the case where dm_kill_unmapped_request() initiates request cleanup. Fix this false warning by just removing the WARN_ON -- it only generated false positives and was never useful in catching the intended case (completing clone request not being mapped e.g. clone->q being NULL). Fixes: aa6df8dd ("dm: fix free_rq_clone() NULL pointer when requeueing unmapped request") Reported-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reported-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com>
-
Takashi Iwai authored
The commit [49fb1897: ALSA: hda - Set stream_pm ops automatically by generic parser] resulted in regressions on some Realtek and VIA codecs because these drivers set patch_ops after calling the generic parser, thus stream_pm got cleared to NULL again. I haven't noticed since I tested with IDT codec. Restore (partial revert) the stream_pm ops for them to fix the regression. Fixes: 49fb1897 ('ALSA: hda - Set stream_pm ops automatically by generic parser') Reported-by:
Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Adrien Schildknecht authored
Commit 2f35c41f ("module: Replace module_ref with atomic_t refcnt") changes the way refcnt is handled but did not update the gdb script to use the new variable. Since refcnt is not per-cpu anymore, we can directly read its value. Signed-off-by:
Adrien Schildknecht <adrien+dev@schischi.me> Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Cc: Pantelis Koukousoulas <pktoss@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Bob Copeland authored
Both 'i' and 'bits_per_entry' are signed integers but the result is a u64 block number. Cast i to u64 to avoid truncation on 32-bit targets. Found by Coverity (CID 200679). Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Bob Copeland authored
The count variable is used to iterate down to (below) zero from the size of the bitmap and handle the one-filling the remainder of the last partial bitmap block. The loop conditional expects count to be signed in order to detect when the final block is processed, after which count goes negative. Unfortunately, a recent change made this unsigned along with some other related fields. The result of is this is that during mount, omfs_get_imap will overrun the bitmap array and corrupt memory unless number of blocks happens to be a multiple of 8 * blocksize. Fix by changing count back to signed: it is guaranteed to fit in an s32 without overflow due to an enforced limit on the number of blocks in the filesystem. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Bob Copeland authored
A static checker found the following issue in the error path for omfs_fill_super: fs/omfs/inode.c:552 omfs_fill_super() warn: missing error code here? 'd_make_root()' failed. 'ret' = '0' Fix by returning -ENOMEM in this case. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sasha Levin authored
match_token() expects a NULL terminator at the end of the token list so that it would know where to stop. Not having one causes it to overrun to invalid memory. In practice, passing a mount option that omfs didn't recognize would sometimes panic the system. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
Commit 1ddd3b4e ("LSM: Remove unused capability.c") removed the file, remove the file pattern. Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrew Morton authored
load_elf_binary() returns `retval', not `error'. Fixes: a87938b2 ("fs/binfmt_elf.c: fix bug in loading of PIE binaries") Reported-by:
James Hogan <james.hogan@imgtec.com> Cc: Michael Davidson <md@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Shreyas B. Prabhu authored
Since tracepoints use RCU for protection, they must not be called on offline cpus. trace_mm_page_pcpu_drain can be called on an offline cpu in this scenario caught by LOCKDEP: =============================== [ INFO: suspicious RCU usage. ] 4.1.0-rc1+ #9 Not tainted ------------------------------- include/trace/events/kmem.h:265 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 1 lock held by swapper/5/0: #0: (&(&zone->lock)->rlock){..-...}, at: [<c0000000002073b0>] .free_pcppages_bulk+0x70/0x920 stack backtrace: CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.1.0-rc1+ #9 Call Trace: .dump_stack+0x98/0xd4 (unreliable) .lockdep_rcu_suspicious+0x108/0x170 .free_pcppages_bulk+0x60c/0x920 .free_hot_cold_page+0x208/0x280 .destroy_context+0x90/0xd0 .__mmdrop+0x58/0x160 .idle_task_exit+0xf0/0x100 .pnv_smp_cpu_kill_self+0x58/0x2c0 .cpu_die+0x34/0x50 .arch_cpu_idle_dead+0x20/0x40 .cpu_startup_entry+0x708/0x7a0 .start_secondary+0x36c/0x3a0 start_secondary_prolog+0x10/0x14 Fix this by converting mm_page_pcpu_drain trace point into TRACE_EVENT_CONDITION where condition is cpu_online(smp_processor_id()) Signed-off-by:
Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com> Reviewed-by:
Preeti U Murthy <preeti@linux.vnet.ibm.com> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Shreyas B. Prabhu authored
Since tracepoints use RCU for protection, they must not be called on offline cpus. trace_mm_page_free can be called on an offline cpu in this scenario caught by LOCKDEP: =============================== [ INFO: suspicious RCU usage. ] 4.1.0-rc1+ #9 Not tainted ------------------------------- include/trace/events/kmem.h:170 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/1/0. stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9 Call Trace: .dump_stack+0x98/0xd4 (unreliable) .lockdep_rcu_suspicious+0x108/0x170 .free_pages_prepare+0x494/0x680 .free_hot_cold_page+0x50/0x280 .destroy_context+0x90/0xd0 .__mmdrop+0x58/0x160 .idle_task_exit+0xf0/0x100 .pnv_smp_cpu_kill_self+0x58/0x2c0 .cpu_die+0x34/0x50 .arch_cpu_idle_dead+0x20/0x40 .cpu_startup_entry+0x708/0x7a0 .start_secondary+0x36c/0x3a0 start_secondary_prolog+0x10/0x14 Fix this by converting mm_page_free trace point into TRACE_EVENT_CONDITION where condition is cpu_online(smp_processor_id()) Signed-off-by:
Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com> Reviewed-by:
Preeti U Murthy <preeti@linux.vnet.ibm.com> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Shreyas B. Prabhu authored
Since tracepoints use RCU for protection, they must not be called on offline cpus. trace_kmem_cache_free can be called on an offline cpu in this scenario caught by LOCKDEP: =============================== [ INFO: suspicious RCU usage. ] 4.1.0-rc1+ #9 Not tainted ------------------------------- include/trace/events/kmem.h:148 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/1/0. stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9 Call Trace: .dump_stack+0x98/0xd4 (unreliable) .lockdep_rcu_suspicious+0x108/0x170 .kmem_cache_free+0x344/0x4b0 .__mmdrop+0x4c/0x160 .idle_task_exit+0xf0/0x100 .pnv_smp_cpu_kill_self+0x58/0x2c0 .cpu_die+0x34/0x50 .arch_cpu_idle_dead+0x20/0x40 .cpu_startup_entry+0x708/0x7a0 .start_secondary+0x36c/0x3a0 start_secondary_prolog+0x10/0x14 Fix this by converting kmem_cache_free trace point into TRACE_EVENT_CONDITION where condition is cpu_online(smp_processor_id()) Signed-off-by:
Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com> Reported-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Reviewed-by:
Preeti U Murthy <preeti@linux.vnet.ibm.com> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://anongit.freedesktop.org/git/nouveau/linux-2.6Dave Airlie authored
Regression fix for Fermi acceleration, and fixes important to bringing up display-less Maxwell boards. * 'linux-4.1' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nouveau/gr/gm204: remove a stray printk drm/nouveau/devinit/gm100-: force devinit table execution on boards without PDISP drm/nouveau/devinit/gf100: make the force-post condition more obvious drm/nouveau/gr/gf100-: fix wrong constant definition
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Should fix fdo#89558 Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
And also more generic, so it can be used on newer chipsets. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lars Seipel authored
Commit 3740c825 ("drm/nouveau/gr/gf100-: add symbolic names for classes") introduced a wrong macro definition causing acceleration setup to fail. Fix it. Signed-off-by:
Lars Seipel <ls@slrz.net> Fixes: 3740c825 ("drm/nouveau/gr/gf100-: add symbolic names for classes") Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 28 May, 2015 15 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
one more regression fix, partial revert. * 'drm-fixes-4.1' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: partially revert "fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling"
-
git://github.com/czankel/xtensa-linuxLinus Torvalds authored
Pull Xtensa fix from Chris Zankel: "This fixes allmodconfig, which fails to build due to missing dma_alloc_attrs() and dma_free_attrs() functions" * tag 'xtensa-20150526' of git://github.com/czankel/xtensa-linux: xtensa: Provide dummy dma_alloc_attrs() and dma_free_attrs()
-
Linus Torvalds authored
Merge tag 'platform-drivers-x86-v4.1-3' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86 Pull x86 platform driver fix from Darren Hart: "thinkpad_acpi: Revert unintentional device attribute renaming" * tag 'platform-drivers-x86-v4.1-3' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86: thinkpad_acpi: Revert unintentional device attribute renaming
-
Christian König authored
We have that bug for years and some users report side effects when fixing it on older hardware. So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15. Signed-off-by:
Christian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
David Henningsson authored
When headphone mic boost is above zero, some 10 - 20 second delay might occur before the headphone mic is operational. Therefore disable the headphone mic boost control (recording gain is sufficient even without it). (Note: this patch is not about the headset mic, it's about the less common mic-in only mode.) BugLink: https://bugs.launchpad.net/bugs/1454235Suggested-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
NeilBrown authored
A recent change removed the need for locking around writing to "sync_action" (and various other places), but introduced a subtle race. When e.g. setting 'reshape' on a 'frozen' array, the 'frozen' flag is cleared before 'reshape' is set, so the md thread can get in and start trying recovery - which isn't wanted. So instead of clearing MD_RECOVERY_FROZEN for any command except 'frozen', only clear it when each specific command is parsed. This allows the handling of 'reshape' to clear the bit while a lock is held. Also remove some places where we set MD_RECOVERY_NEEDED, as it is always set on non-error exit of the function. Signed-off-by:
NeilBrown <neilb@suse.de> Fixes: 6791875e ("md: make reconfig_mutex optional for writes to md sysfs files.")
-
NeilBrown authored
Once the array has too much failure, we need to break stripe-batches up so they can all be dealt with. Signed-off-by:
NeilBrown <neilb@suse.de>
-
NeilBrown authored
Now that the code in break_stripe_batch_list() is nearly identical to the end of handle_stripe_clean_event, replace the later with a function call. The only remaining difference of any interest is the masking that is applieds to dev[i].flags copied from head_sh. R5_WriteError certainly isn't wanted as it is set per-stripe, not per-patch. R5_Overlap isn't wanted as it is explicitly handled. Signed-off-by:
NeilBrown <neilb@suse.de>
-
NeilBrown authored
When a batch of stripes is broken up, we keep some of the flags that were per-stripe, and copy other flags from the head to all others. This only happens while a stripe is being handled, so many of the flags are irrelevant. The "SYNC_FLAGS" (which I've renamed to make it clear there are several) and STRIPE_DEGRADED are set per-stripe and so need to be preserved. STRIPE_INSYNC is the only flag that is set on the head that needs to be propagated to all others. For safety, add a WARN_ON if others are set, except: STRIPE_HANDLE - this is safe and per-stripe and we are going to set in several cases anyway STRIPE_INSYNC STRIPE_IO_STARTED - this is just a hint and doesn't hurt. STRIPE_ON_PLUG_LIST STRIPE_ON_RELEASE_LIST - It is a point pointless for a batched stripe to be on one of these lists, but it can happen as can be safely ignored. Signed-off-by:
NeilBrown <neilb@suse.de>
-
NeilBrown authored
When we break a stripe_batch_list we sometimes want to set STRIPE_HANDLE on the individual stripes, and sometimes not. So pass a 'handle_flags' arg. If it is zero, always set STRIPE_HANDLE (on non-head stripes). If not zero, only set it if any of the given flags are present. Signed-off-by:
NeilBrown <neilb@suse.de>
-
NeilBrown authored
break_stripe_batch list didn't clear head_sh->batch_head. This was probably a bug. Also clear all R5_Overlap flags and if any were cleared, wake up 'wait_for_overlap'. This isn't always necessary but the worst effect is a little extra checking for code that is waiting on wait_for_overlap. Also, don't use wake_up_nr() because that does the wrong thing if 'nr' is zero, and it number of flags cleared doesn't strongly correlate with the number of threads to wake. Signed-off-by:
NeilBrown <neilb@suse.de>
-
NeilBrown authored
handle_stripe_clean_event() contains a chunk of code very similar to check_break_stripe_batch_list(). If we make the latter more like the former, we can end up with just one copy of this code. This first step removed the condition (and the 'check_') part of the name. This has the added advantage of making it clear what check is being performed at the point where the function is called. Signed-off-by:
NeilBrown <neilb@suse.de>
-
NeilBrown authored
If a stripe is a member of a batch, but not the head, it must not be handled separately from the rest of the batch. 'clear_batch_ready()' handles this requirement to some extent but not completely. If a member is passed to handle_stripe() a second time it returns '0' indicating the stripe can be handled, which is wrong. So add an extra test. Signed-off-by:
NeilBrown <neilb@suse.de>
-
Rusty Russell authored
da91309e (cpumask: Utility function to set n'th cpu...) created a genuinely weird function. I never saw it before, it went through DaveM. (He only does this to make us other maintainers feel better about our own mistakes.) cpumask_set_cpu_local_first's purpose is say "I need to spread things across N online cpus, choose the ones on this numa node first"; you call it in a loop. It can fail. One of the two callers ignores this, the other aborts and fails the device open. It can fail in two ways: allocating the off-stack cpumask, or through a convoluted codepath which AFAICT can only occur if cpu_online_mask changes. Which shouldn't happen, because if cpu_online_mask can change while you call this, it could return a now-offline cpu anyway. It contains a nonsensical test "!cpumask_of_node(numa_node)". This was drawn to my attention by Geert, who said this causes a warning on Sparc. It sets a single bit in a cpumask instead of returning a cpu number, because that's what the callers want. It could be made more efficient by passing the previous cpu rather than an index, but that would be more invasive to the callers. Fixes: da91309e Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased) Tested-by:
Amir Vadai <amirv@mellanox.com> Acked-by:
Amir Vadai <amirv@mellanox.com> Acked-by:
David S. Miller <davem@davemloft.net>
-
NeilBrown authored
When we add a write to a stripe we need to make sure the bitmap bit is set. While doing that the stripe is not locked so it could be added to a batch after which further changes to STRIPE_BIT_DELAY and ->bm_seq are ineffective. So we need to hold off adding to a stripe until bitmap_startwrite has completed at least once, and we need to avoid further changes to STRIPE_BIT_DELAY once the stripe has been added to a batch. If a bitmap_startwrite() completes after the stripe was added to a batch, it will not have set the bit, only incremented a counter, so no extra delay of the stripe is needed. Reported-by:
Shaohua Li <shli@kernel.org> Signed-off-by:
NeilBrown <neilb@suse.de>
-