Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs\:\s+fix\s+ASSERTION\s+failure\s+in\s+xfs_vm_write

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs\:\s+fix\s+ASSERTION\s+failure\s+in\s+xfs_vm_write_failed\s*$/: 4 ]

Total 4 documents matching your query.

1. [PATCH] xfs: fix ASSERTION failure in xfs_vm_write_failed() (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Sun, 17 Mar 2013 23:01:08 +0800; Hello, Yesterday, Michael reported that ran xfstest-078 got kernel panic when growing a small partition to a huge size(64-bit) on 32-bit system, this issue can be easily reproduced on the latest upst; /archives/xfs/2013-03/msg00531.html (10,620 bytes)
2. Re: [PATCH] xfs: fix ASSERTION failure in xfs_vm_write_failed() (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Mon, 18 Mar 2013 10:53:02 +1100; Hi Jeff, Nice work finding the root of the problem, but I think your fix is wrong. Here's how I look at the problem - all the parameters are loff_t, so everything should validate cleanly as 64 bit va; /archives/xfs/2013-03/msg00535.html (11,326 bytes)
3. Re: [PATCH] xfs: fix ASSERTION failure in xfs_vm_write_failed() (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Mon, 18 Mar 2013 12:12:47 +0800; Hi Dave, Exactly. It's not an overflow as the block_offset is 64-bit, but the original evaluated value missing the high 32-bits of pos. Yep. so we figure the 'from' out with the lower 12 bits in pos; /archives/xfs/2013-03/msg00538.html (12,258 bytes)
4. Re: [PATCH] xfs: fix ASSERTION failure in xfs_vm_write_failed() (score: 1): Author: "Michael L. Semon" <mlsemon35@xxxxxxxxx>; Date: Mon, 18 Mar 2013 00:17:14 -0400; On 03/17/2013 11:01 AM, Jeff Liu wrote: On 32-bit system, if the request pos is 64-bit and evaluate block_offset with (pos & PAGE_MASK) will result in overflows, therefore the assertion will failed.; /archives/xfs/2013-03/msg00539.html (11,259 bytes)

Current List: 1 - 4
Page: [1]