linux-stable.git/drivers/md/md.c, branch v3.12

md: avoid deadlock when md_set_badblocks.

2013-10-24T01:57:11+00:00

When operate harddisk and hit errors, md_set_badblocks is called after
scsi_restart_operations which already disabled the irq. but md_set_badblocks
will call write_sequnlock_irq and enable irq. so softirq can preempt the
current thread and that may cause a deadlock. I think this situation should
use write_sequnlock_irqsave/irqrestore instead.

I met the situation and the call trace is below:
[  638.919974] BUG: spinlock recursion on CPU#0, scsi_eh_13/1010
[  638.921923]  lock: 0xffff8800d4d51fc8, .magic: dead4ead, .owner: scsi_eh_13/1010, .owner_cpu: 0
[  638.923890] CPU: 0 PID: 1010 Comm: scsi_eh_13 Not tainted 3.12.0-rc5+ #37
[  638.925844] Hardware name: To be filled by O.E.M. To be filled by O.E.M./MAHOBAY, BIOS 4.6.5 03/05/2013
[  638.927816]  ffff880037ad4640 ffff880118c03d50 ffffffff8172ff85 0000000000000007
[  638.929829]  ffff8800d4d51fc8 ffff880118c03d70 ffffffff81730030 ffff8800d4d51fc8
[  638.931848]  ffffffff81a72eb0 ffff880118c03d90 ffffffff81730056 ffff8800d4d51fc8
[  638.933884] Call Trace:
[  638.935867]    [] dump_stack+0x55/0x76
[  638.937878]  [] spin_dump+0x8a/0x8f
[  638.939861]  [] spin_bug+0x21/0x26
[  638.941836]  [] do_raw_spin_lock+0xa4/0xc0
[  638.943801]  [] _raw_spin_lock+0x66/0x80
[  638.945747]  [] ? scsi_device_unbusy+0x9d/0xd0
[  638.947672]  [] ? _raw_spin_unlock+0x2b/0x50
[  638.949595]  [] scsi_device_unbusy+0x9d/0xd0
[  638.951504]  [] scsi_finish_command+0x37/0xe0
[  638.953388]  [] scsi_softirq_done+0xa8/0x140
[  638.955248]  [] blk_done_softirq+0x7b/0x90
[  638.957116]  [] __do_softirq+0xfd/0x330
[  638.958987]  [] ? __lock_release+0x6f/0x100
[  638.960861]  [] call_softirq+0x1c/0x30
[  638.962724]  [] do_softirq+0x8d/0xc0
[  638.964565]  [] irq_exit+0x10e/0x150
[  638.966390]  [] smp_apic_timer_interrupt+0x4a/0x60
[  638.968223]  [] apic_timer_interrupt+0x6f/0x80
[  638.970079]    [] ? __lock_release+0x6f/0x100
[  638.971899]  [] ? _raw_spin_unlock_irq+0x3a/0x50
[  638.973691]  [] ? _raw_spin_unlock_irq+0x30/0x50
[  638.975475]  [] md_set_badblocks+0x1f3/0x4a0
[  638.977243]  [] rdev_set_badblocks+0x27/0x80
[  638.978988]  [] raid5_end_read_request+0x36b/0x4e0 [raid456]
[  638.980723]  [] bio_endio+0x1d/0x40
[  638.982463]  [] req_bio_endio.isra.65+0x83/0xa0
[  638.984214]  [] blk_update_request+0x7f/0x350
[  638.985967]  [] blk_update_bidi_request+0x31/0x90
[  638.987710]  [] __blk_end_bidi_request+0x20/0x50
[  638.989439]  [] __blk_end_request_all+0x1f/0x30
[  638.991149]  [] blk_peek_request+0x106/0x250
[  638.992861]  [] ? scsi_kill_request.isra.32+0xe9/0x130
[  638.994561]  [] scsi_request_fn+0x4a/0x3d0
[  638.996251]  [] __blk_run_queue+0x37/0x50
[  638.997900]  [] blk_run_queue+0x2f/0x50
[  638.999553]  [] scsi_run_queue+0xe0/0x1c0
[  639.001185]  [] scsi_run_host_queues+0x21/0x40
[  639.002798]  [] scsi_restart_operations+0x177/0x200
[  639.004391]  [] scsi_error_handler+0xc9/0xe0
[  639.005996]  [] ? scsi_unjam_host+0xd0/0xd0
[  639.007600]  [] kthread+0xdb/0xe0
[  639.009205]  [] ? flush_kthread_worker+0x170/0x170
[  639.010821]  [] ret_from_fork+0x7c/0xb0
[  639.012437]  [] ? flush_kthread_worker+0x170/0x170

This bug was introduce in commit  2e8ac30312973dd20e68073653
(the first time rdev_set_badblock was call from interrupt context),
so this patch is appropriate for 3.5 and subsequent kernels.

Cc:  (3.5+)
Signed-off-by: Bian Yu 
Reviewed-by: Jianpeng Ma 
Signed-off-by: NeilBrown

md: avoid deadlock when dirty buffers during md_stop.

2013-08-27T06:45:00+00:00

When the last process closes /dev/mdX sync_blockdev will be called so
that all buffers get flushed.
So if it is then opened for the STOP_ARRAY ioctl to be sent there will
be nothing to flush.

However if we open /dev/mdX in order to send the STOP_ARRAY ioctl just
moments before some other process which was writing closes their file
descriptor, then there won't be a 'last close' and the buffers might
not get flushed.

So do_md_stop() calls sync_blockdev().  However at this point it is
holding ->reconfig_mutex.  So if the array is currently 'clean' then
the writes from sync_blockdev() will not complete until the array
can be marked dirty and that won't happen until some other thread
can get ->reconfig_mutex.  So we deadlock.

We need to move the sync_blockdev() call to before we take
->reconfig_mutex.
However then some other thread could open /dev/mdX and write to it
after we call sync_blockdev() and before we actually stop the array.
This can leave dirty data in the page cache which is awkward.

So introduce new flag MD_STILL_CLOSED.  Set it before calling
sync_blockdev(), clear it if anyone does open the file, and abort the
STOP_ARRAY attempt if it gets set before we lock against further
opens.

It is still possible to get problems if you open /dev/mdX, write to
it, then issue the STOP_ARRAY ioctl.  Just don't do that.

Signed-off-by: NeilBrown

md: Don't test all of mddev->flags at once.

2013-08-27T06:28:23+00:00

mddev->flags is mostly used to record if an update of the
metadata is needed.  Sometimes the whole field is tested
instead of just the important bits.  This makes it difficult
to introduce more state bits.

So replace all bare tests of mddev->flags with tests for the bits
that actually need testing.

Signed-off-by: NeilBrown

md: Fix apparent cut-and-paste error in super_90_validate

2013-08-27T06:06:17+00:00

Setting a variable to itself probably wasn't the intention here.

Signed-off-by: Dave Jones 
Signed-off-by: NeilBrown

md: fix safe_mode buglet.

2013-08-27T06:05:43+00:00

Whe we set the safe_mode_timeout to a smaller value we trigger a timeout
immediately - otherwise the small value might not be honoured.
However if the previous timeout was 0 meaning "no timeout", we didn't.
This would mean that no timeout happens until the next write completes,
which could be a long time.

Signed-off-by: NeilBrown

md: don't call md_allow_write in get_bitmap_file.

2013-08-27T06:05:32+00:00

There is no really need as GFP_NOIO is very likely sufficient,
and failure is not catastrophic.

Calling md_allow_write here will convert a read-auto array to
read/write which could be confusing when you are just performing
a read operation.

Signed-off-by: NeilBrown

md: Remove recent change which allows devices to skip recovery.

2013-07-18T04:18:03+00:00

commit 7ceb17e87bde79d285a8b988cfed9eaeebe60b86
    md: Allow devices to be re-added to a read-only array.

allowed a bit more than just that.  It also allows devices to be added
to a read-write array and to end up skipping recovery.

This patch removes the offending piece of code pending a rewrite for a
subsequent release.

More specifically:
 If the array has a bitmap, then the device will still need a bitmap
 based resync ('saved_raid_disk' is set under different conditions
 is a bitmap is present).
 If the array doesn't have a bitmap, then this is correct as long as
 nothing has been written to the array since the metadata was checked
 by ->validate_super.  However there is no locking to ensure that there
 was no write.

Bug was introduced in 3.10 and causes data corruption so
patch is suitable for 3.10-stable.

Cc: stable@vger.kernel.org (3.10)
Reported-by: Joe Lawrence 
Signed-off-by: NeilBrown

MD: Remember the last sync operation that was performed

2013-06-26T02:38:24+00:00

MD:  Remember the last sync operation that was performed

This patch adds a field to the mddev structure to track the last
sync operation that was performed.  This is especially useful when
it comes to what is recorded in mismatch_cnt in sysfs.  If the
last operation was "data-check", then it reports the number of
descrepancies found by the user-initiated check.  If it was a
"repair" operation, then it is reporting the number of
descrepancies repaired.  etc.

Signed-off-by: Jonathan Brassow 
Signed-off-by: NeilBrown

md: replace strict_strto() with kstrto()

2013-06-13T22:10:26+00:00

The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.

Signed-off-by: Jingoo Han 
Signed-off-by: NeilBrown

md: Wait for md_check_recovery before attempting device removal.