Re: [PATCH 3.2 019/102] xfs: don't dirty buffers beyond EOF
On Tue, 2014-11-04 at 18:09 +1100, Dave Chinner wrote: > On Sat, Nov 01, 2014 at 10:28:03PM +, Ben Hutchings wrote: > > 3.2.64-rc1 review patch. If anyone has any objections, please let me know. > > I'm not sure it's a good idea to pull stuff like this back into > really old stable kernels. OK, then I'll drop this. > This was part of a much larger series of > bug fixes that were fairly carefully tested. I very much doubt that > there is specific XFS test coverage on these older kernels that > would determine if this has introduced problems or not [...] No, I'm not testing XFS at all. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Re: [PATCH 3.2 019/102] xfs: don't dirty buffers beyond EOF
On Tue, 2014-11-04 at 18:09 +1100, Dave Chinner wrote: On Sat, Nov 01, 2014 at 10:28:03PM +, Ben Hutchings wrote: 3.2.64-rc1 review patch. If anyone has any objections, please let me know. I'm not sure it's a good idea to pull stuff like this back into really old stable kernels. OK, then I'll drop this. This was part of a much larger series of bug fixes that were fairly carefully tested. I very much doubt that there is specific XFS test coverage on these older kernels that would determine if this has introduced problems or not [...] No, I'm not testing XFS at all. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Re: [PATCH 3.2 019/102] xfs: don't dirty buffers beyond EOF
On Sat, Nov 01, 2014 at 10:28:03PM +, Ben Hutchings wrote: > 3.2.64-rc1 review patch. If anyone has any objections, please let me know. I'm not sure it's a good idea to pull stuff like this back into really old stable kernels. This was part of a much larger series of bug fixes that were fairly carefully tested. I very much doubt that there is specific XFS test coverage on these older kernels that would determine if this has introduced problems or not > > -- > > From: Dave Chinner > > commit 22e757a49cf010703fcb9c9b4ef793248c39b0c2 upstream. > > generic/263 is failing fsx at this point with a page spanning > EOF that cannot be invalidated. The operations are: > > 1190 mapwrite 0x52c00 thru0x5e569 (0xb96a bytes) > 1191 mapread0x5c000 thru0x5d636 (0x1637 bytes) > 1192 write 0x5b600 thru0x771ff (0x1bc00 bytes) I've got no idea whether generic/263 even exposes this problem on 3.2 kernels, or whether there's a bunch of the other upstream changes that need to be added first to expose it... :/ Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 019/102] xfs: don't dirty buffers beyond EOF
On Sat, Nov 01, 2014 at 10:28:03PM +, Ben Hutchings wrote: 3.2.64-rc1 review patch. If anyone has any objections, please let me know. I'm not sure it's a good idea to pull stuff like this back into really old stable kernels. This was part of a much larger series of bug fixes that were fairly carefully tested. I very much doubt that there is specific XFS test coverage on these older kernels that would determine if this has introduced problems or not -- From: Dave Chinner dchin...@redhat.com commit 22e757a49cf010703fcb9c9b4ef793248c39b0c2 upstream. generic/263 is failing fsx at this point with a page spanning EOF that cannot be invalidated. The operations are: 1190 mapwrite 0x52c00 thru0x5e569 (0xb96a bytes) 1191 mapread0x5c000 thru0x5d636 (0x1637 bytes) 1192 write 0x5b600 thru0x771ff (0x1bc00 bytes) I've got no idea whether generic/263 even exposes this problem on 3.2 kernels, or whether there's a bunch of the other upstream changes that need to be added first to expose it... :/ Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
