public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [3.4-rc1] attempt to access beyond end of device and livelock
       [not found] <CAMVG2ss5WzwhgPunD5greRii1HFuEYt1TMQwxgUNitrpHtguVA@mail.gmail.com>
@ 2012-04-06 11:36 ` Daniel J Blueman
  2012-04-08  8:49   ` Liu Bo
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel J Blueman @ 2012-04-06 11:36 UTC (permalink / raw)
  To: Josef Bacik, Chris Mason; +Cc: Linux BTRFS, Linux Kernel

Hi Josef, Chris,

When testing BTRFS with RAID 0 metadata on linux-3.4-rc1, we see
discard ranges exceeding the end of the block device [1], potentially
causing dataloss; when this occurs, filesystem writeback becomes
catatonic due to continual resubmission.

Simply mounting with discard a raid0 metadata filesystem and copying
some data in [2] provokes the issue.

Thanks,
 Daniel

--- [1]

attempt to access beyond end of device
ram0: rw=129, want=8452072, limit=4096000
...

--- [2]

modprobe brd rd_size=2048000 (or boot with ramdisk_size=2048000)
mkfs.btrfs -m raid0 /dev/ram0 /dev/ram1
mount /dev/ram0 /mnt -o discard
cd /mnt && tar -xvzf linux.tar.gz
<access beyond end of device and livelock>
-- 
Daniel J Blueman

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [3.4-rc1] attempt to access beyond end of device and livelock
  2012-04-06 11:36 ` [3.4-rc1] attempt to access beyond end of device and livelock Daniel J Blueman
@ 2012-04-08  8:49   ` Liu Bo
  2012-04-09 14:44     ` Daniel J Blueman
  0 siblings, 1 reply; 3+ messages in thread
From: Liu Bo @ 2012-04-08  8:49 UTC (permalink / raw)
  To: Daniel J Blueman; +Cc: Josef Bacik, Chris Mason, Linux BTRFS, Linux Kernel

On 04/06/2012 07:36 PM, Daniel J Blueman wrote:
> Hi Josef, Chris,
> 
> When testing BTRFS with RAID 0 metadata on linux-3.4-rc1, we see
> discard ranges exceeding the end of the block device [1], potentially
> causing dataloss; when this occurs, filesystem writeback becomes
> catatonic due to continual resubmission.
> 
> Simply mounting with discard a raid0 metadata filesystem and copying
> some data in [2] provokes the issue.
> 
> Thanks,
>  Daniel
> 
> --- [1]
> 
> attempt to access beyond end of device
> ram0: rw=129, want=8452072, limit=4096000
> ...
> 
> --- [2]
> 
> modprobe brd rd_size=2048000 (or boot with ramdisk_size=2048000)
> mkfs.btrfs -m raid0 /dev/ram0 /dev/ram1
> mount /dev/ram0 /mnt -o discard
> cd /mnt && tar -xvzf linux.tar.gz
> <access beyond end of device and livelock>

Thanks for the report, this bug shows we've miscalculated the length of discard extents.

I'll send a patch for this soon.

thanks,
-- 
liubo 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [3.4-rc1] attempt to access beyond end of device and livelock
  2012-04-08  8:49   ` Liu Bo
@ 2012-04-09 14:44     ` Daniel J Blueman
  0 siblings, 0 replies; 3+ messages in thread
From: Daniel J Blueman @ 2012-04-09 14:44 UTC (permalink / raw)
  To: Liu Bo; +Cc: Josef Bacik, Chris Mason, Linux BTRFS, Linux Kernel

On 8 April 2012 16:49, Liu Bo <liubo2009@cn.fujitsu.com> wrote:
> On 04/06/2012 07:36 PM, Daniel J Blueman wrote:
>> Hi Josef, Chris,
>>
>> When testing BTRFS with RAID 0 metadata on linux-3.4-rc1, we see
>> discard ranges exceeding the end of the block device [1], potentially
>> causing dataloss; when this occurs, filesystem writeback becomes
>> catatonic due to continual resubmission.
[]
> Thanks for the report, this bug shows we've miscalculated the length of discard extents.
>
> I'll send a patch for this soon.

The patch test out well here on 3.4-rc2. Thanks Bo!

Daniel
-- 
Daniel J Blueman

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-04-09 14:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <CAMVG2ss5WzwhgPunD5greRii1HFuEYt1TMQwxgUNitrpHtguVA@mail.gmail.com>
2012-04-06 11:36 ` [3.4-rc1] attempt to access beyond end of device and livelock Daniel J Blueman
2012-04-08  8:49   ` Liu Bo
2012-04-09 14:44     ` Daniel J Blueman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox