Re: [git pull] vfs pile 3
On Fri, Dec 23, 2016 at 12:03:21AM +, Al Viro wrote: > Assorted cleanups and fixes all over the place. Fix for aio compat in !CONFIG_AIO builds folded in, commit message on seq_file patch unmangled. Other than that, identical to the previous. The following changes since commit e93b1cc8a8965da137ffea0b88e5f62fa1d2a9e6: Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs (2016-12-19 08:23:53 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus for you to fetch changes up to faf0dcebd7b387187f29ff811d47df465ea4c9f9: Merge branch 'work.namespace' into for-linus (2016-12-22 23:04:31 -0500) Al Viro (7): remove a bogus claim about namespace_sem being held by callers of mnt_alloc_id() clone_private_mount() doesn't need to touch namespace_sem reorganize do_make_slave() move aio compat to fs/aio.c [iov_iter] fix iterate_all_kinds() on empty iterators sg_write()/bsg_write() is not fit to be called under KERNEL_DS Merge branch 'work.namespace' into for-linus Aleksa Sarai (1): fs: exec: apply CLOEXEC before changing dumpable task flags Darrick J. Wong (1): vfs: fix isize/pos/len checks for reflink & dedupe Jeff Layton (1): ufs: fix function declaration for ufs_truncate_blocks Tomasz Majchrzak (1): seq_file: reset iterator to first record for zero offset block/bsg.c | 3 ++ drivers/scsi/sg.c | 3 ++ fs/aio.c| 97 - fs/compat.c | 75 -- fs/exec.c | 10 - fs/namespace.c | 8 +--- fs/ocfs2/refcounttree.c | 2 +- fs/pnode.c | 74 ++--- fs/read_write.c | 18 + fs/seq_file.c | 7 fs/ufs/inode.c | 2 +- fs/xfs/xfs_reflink.c| 2 +- include/linux/aio.h | 5 --- kernel/sys_ni.c | 3 ++ lib/iov_iter.c | 55 +--- 15 files changed, 197 insertions(+), 167 deletions(-)
Re: [git pull] vfs pile 3
On Fri, Dec 23, 2016 at 12:03:21AM +, Al Viro wrote: > Assorted cleanups and fixes all over the place. Fix for aio compat in !CONFIG_AIO builds folded in, commit message on seq_file patch unmangled. Other than that, identical to the previous. The following changes since commit e93b1cc8a8965da137ffea0b88e5f62fa1d2a9e6: Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs (2016-12-19 08:23:53 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus for you to fetch changes up to faf0dcebd7b387187f29ff811d47df465ea4c9f9: Merge branch 'work.namespace' into for-linus (2016-12-22 23:04:31 -0500) Al Viro (7): remove a bogus claim about namespace_sem being held by callers of mnt_alloc_id() clone_private_mount() doesn't need to touch namespace_sem reorganize do_make_slave() move aio compat to fs/aio.c [iov_iter] fix iterate_all_kinds() on empty iterators sg_write()/bsg_write() is not fit to be called under KERNEL_DS Merge branch 'work.namespace' into for-linus Aleksa Sarai (1): fs: exec: apply CLOEXEC before changing dumpable task flags Darrick J. Wong (1): vfs: fix isize/pos/len checks for reflink & dedupe Jeff Layton (1): ufs: fix function declaration for ufs_truncate_blocks Tomasz Majchrzak (1): seq_file: reset iterator to first record for zero offset block/bsg.c | 3 ++ drivers/scsi/sg.c | 3 ++ fs/aio.c| 97 - fs/compat.c | 75 -- fs/exec.c | 10 - fs/namespace.c | 8 +--- fs/ocfs2/refcounttree.c | 2 +- fs/pnode.c | 74 ++--- fs/read_write.c | 18 + fs/seq_file.c | 7 fs/ufs/inode.c | 2 +- fs/xfs/xfs_reflink.c| 2 +- include/linux/aio.h | 5 --- kernel/sys_ni.c | 3 ++ lib/iov_iter.c | 55 +--- 15 files changed, 197 insertions(+), 167 deletions(-)
Re: [git pull] vfs pile 3
On Sat, Aug 6, 2016 at 11:46 PM, Al Virowrote: > > I went for the second variant (backmerge), but if you prefer the third one, > just pull #for-linus-2 and I'll send a separate pull request for the last > commit. Or just cherry-pick that last commit from #for-linus after having > pulled #for-linus-2. Please don't do back-merges to avoid conflicts. I'd *much* rather just get the conflict. Especially when it's that trivial. Linus
Re: [git pull] vfs pile 3
On Sat, Aug 6, 2016 at 11:46 PM, Al Viro wrote: > > I went for the second variant (backmerge), but if you prefer the third one, > just pull #for-linus-2 and I'll send a separate pull request for the last > commit. Or just cherry-pick that last commit from #for-linus after having > pulled #for-linus-2. Please don't do back-merges to avoid conflicts. I'd *much* rather just get the conflict. Especially when it's that trivial. Linus
Re: [git pull] vfs pile 3
Il 13/10/2012 19:07, Al Viro ha scritto: On Sat, Oct 13, 2012 at 12:04:55PM -0400, Christoph Hellwig wrote: On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote: You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago. kernel_thread() unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/ I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying ->truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why vmtruncate() was a bad idea, leaving the functionality exactly as it used to be... As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement ->truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece. Umm... That would be what, procfs? Frankly, I'm not sure that ATTR_SIZE for procfs actually should not be silently ignored. ->i_size there is completely synthetic - it's not as if truncation would actually change the contents. And ufs situation is quite different - there vmtruncate() is used only on the ->write_begin() side. ->setattr() is already vmtruncate-free. What's needed there is an analog of e.g. ext2_write_failed(). I'm open to change the series and give any help. My original idea was to do a cleanup patch and after that give to each fs maintainer the possibility to do ad-hoc fix. Each fs maintainer has got a deep knowledge of its fs so it was a safe approach from testing point of view and so on. However if you tell me that in this case another approach is better is ok for me. I'll fix the patches according to the comments of Christoph. Regards, Marco -- 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: [git pull] vfs pile 3
Il 13/10/2012 19:07, Al Viro ha scritto: On Sat, Oct 13, 2012 at 12:04:55PM -0400, Christoph Hellwig wrote: On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote: You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago. kernel_thread() unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/ I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying -truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why vmtruncate() was a bad idea, leaving the functionality exactly as it used to be... As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement -truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece. Umm... That would be what, procfs? Frankly, I'm not sure that ATTR_SIZE for procfs actually should not be silently ignored. -i_size there is completely synthetic - it's not as if truncation would actually change the contents. And ufs situation is quite different - there vmtruncate() is used only on the -write_begin() side. -setattr() is already vmtruncate-free. What's needed there is an analog of e.g. ext2_write_failed(). I'm open to change the series and give any help. My original idea was to do a cleanup patch and after that give to each fs maintainer the possibility to do ad-hoc fix. Each fs maintainer has got a deep knowledge of its fs so it was a safe approach from testing point of view and so on. However if you tell me that in this case another approach is better is ok for me. I'll fix the patches according to the comments of Christoph. Regards, Marco -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 12:04:55PM -0400, Christoph Hellwig wrote: > On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote: > > You know, I'm in the middle of dealing with one such TODO. Yours, as it > > were. From six years ago. kernel_thread() unexporting. TODO comments > > of any form are routinely shat upon and ignored, especially when shuffled > > away into less read parts of the tree... ;-/ > > > > I'd rather see it done fs-by-fs. Starting with something reasonably easy > > to test - minixfs would do nicely. Don't get me wrong - I'm all for > > burying ->truncate(); what I'm worried about is that we'll end up burying > > the warning about the reasons why vmtruncate() was a bad idea, leaving the > > functionality exactly as it used to be... > > As mentioned I agree with the concern in principle. Let's start by > taking Marco's patches for filesystems that use vmtruncate but don't > actually implement ->truncate. There's a few I remember offhand, e.g. > procfs and ufs right now. Then we can do the actual work required ones > piece by piece. Umm... That would be what, procfs? Frankly, I'm not sure that ATTR_SIZE for procfs actually should not be silently ignored. ->i_size there is completely synthetic - it's not as if truncation would actually change the contents. And ufs situation is quite different - there vmtruncate() is used only on the ->write_begin() side. ->setattr() is already vmtruncate-free. What's needed there is an analog of e.g. ext2_write_failed(). -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote: > You know, I'm in the middle of dealing with one such TODO. Yours, as it > were. From six years ago. kernel_thread() unexporting. TODO comments > of any form are routinely shat upon and ignored, especially when shuffled > away into less read parts of the tree... ;-/ > > I'd rather see it done fs-by-fs. Starting with something reasonably easy > to test - minixfs would do nicely. Don't get me wrong - I'm all for > burying ->truncate(); what I'm worried about is that we'll end up burying > the warning about the reasons why vmtruncate() was a bad idea, leaving the > functionality exactly as it used to be... As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement ->truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece. -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 11:48:10AM -0400, Christoph Hellwig wrote: > On Sat, Oct 13, 2012 at 08:51:28AM +0100, Al Viro wrote: > > It's somewhat pointless on its own... If you were doing something with > > the callers afterwards - sure, it would be make sense, but as it is... > > I'd really like to see ->truncate and vmtruncate done, so from that side > I'm absolutely in favour of this series. What I'm a bit concerned about > is that it just does the trivial 1:1 conversion and not actually > converts the sequence of operations to the proper form, which was one > of the two big reasons of moving away from ->truncate to start with. > > I'd love to see the full conversion, but without adequate test coverage > for all the fringe filesystems that might be a bit too much to expect > from Marco. > > I think just doing the easy conversions he did, and putting a TODO > comment explaining how it should be taken further at each of the sites > would be valueable on its own. You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago. kernel_thread() unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/ I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying ->truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why vmtruncate() was a bad idea, leaving the functionality exactly as it used to be... -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 08:51:28AM +0100, Al Viro wrote: > It's somewhat pointless on its own... If you were doing something with > the callers afterwards - sure, it would be make sense, but as it is... I'd really like to see ->truncate and vmtruncate done, so from that side I'm absolutely in favour of this series. What I'm a bit concerned about is that it just does the trivial 1:1 conversion and not actually converts the sequence of operations to the proper form, which was one of the two big reasons of moving away from ->truncate to start with. I'd love to see the full conversion, but without adequate test coverage for all the fringe filesystems that might be a bit too much to expect from Marco. I think just doing the easy conversions he did, and putting a TODO comment explaining how it should be taken further at each of the sites would be valueable on its own. -- 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: [git pull] vfs pile 3
Il 13/10/2012 09:51, Al Viro ha scritto: On Sat, Oct 13, 2012 at 09:20:45AM +0200, Marco Stornelli wrote: Il 13/10/2012 02:20, Al Viro ha scritto: Stuff from Jeff Layton, mostly. Sanitizing interplay between audit and namei, removing a lot of insanity from audit_inode() mess and getting things ready for his ESTALE patchset. Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Al, do you see any problem to apply the patch series "drop vmtruncate"? It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is... The goal of the patch was to remove a deprecated function trying to improve the code, removing the inode operation and doing a general cleanup. It's pointless for me to have "dead"/"old" code, however thanks for you comment. Marco -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 09:20:45AM +0200, Marco Stornelli wrote: > Il 13/10/2012 02:20, Al Viro ha scritto: > > Stuff from Jeff Layton, mostly. Sanitizing interplay between > >audit and namei, removing a lot of insanity from audit_inode() mess > >and getting things ready for his ESTALE patchset. Please, pull from > >the usual place - > >git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus > > > > Al, > > do you see any problem to apply the patch series "drop vmtruncate"? It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is... -- 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: [git pull] vfs pile 3
Il 13/10/2012 02:20, Al Viro ha scritto: Stuff from Jeff Layton, mostly. Sanitizing interplay between audit and namei, removing a lot of insanity from audit_inode() mess and getting things ready for his ESTALE patchset. Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Al, do you see any problem to apply the patch series "drop vmtruncate"? Do you think it's better to push it for 3.8? Thanks, Marco -- 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: [git pull] vfs pile 3
Il 13/10/2012 02:20, Al Viro ha scritto: Stuff from Jeff Layton, mostly. Sanitizing interplay between audit and namei, removing a lot of insanity from audit_inode() mess and getting things ready for his ESTALE patchset. Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Al, do you see any problem to apply the patch series drop vmtruncate? Do you think it's better to push it for 3.8? Thanks, Marco -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 09:20:45AM +0200, Marco Stornelli wrote: Il 13/10/2012 02:20, Al Viro ha scritto: Stuff from Jeff Layton, mostly. Sanitizing interplay between audit and namei, removing a lot of insanity from audit_inode() mess and getting things ready for his ESTALE patchset. Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Al, do you see any problem to apply the patch series drop vmtruncate? It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is... -- 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: [git pull] vfs pile 3
Il 13/10/2012 09:51, Al Viro ha scritto: On Sat, Oct 13, 2012 at 09:20:45AM +0200, Marco Stornelli wrote: Il 13/10/2012 02:20, Al Viro ha scritto: Stuff from Jeff Layton, mostly. Sanitizing interplay between audit and namei, removing a lot of insanity from audit_inode() mess and getting things ready for his ESTALE patchset. Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Al, do you see any problem to apply the patch series drop vmtruncate? It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is... The goal of the patch was to remove a deprecated function trying to improve the code, removing the inode operation and doing a general cleanup. It's pointless for me to have dead/old code, however thanks for you comment. Marco -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 08:51:28AM +0100, Al Viro wrote: It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is... I'd really like to see -truncate and vmtruncate done, so from that side I'm absolutely in favour of this series. What I'm a bit concerned about is that it just does the trivial 1:1 conversion and not actually converts the sequence of operations to the proper form, which was one of the two big reasons of moving away from -truncate to start with. I'd love to see the full conversion, but without adequate test coverage for all the fringe filesystems that might be a bit too much to expect from Marco. I think just doing the easy conversions he did, and putting a TODO comment explaining how it should be taken further at each of the sites would be valueable on its own. -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 11:48:10AM -0400, Christoph Hellwig wrote: On Sat, Oct 13, 2012 at 08:51:28AM +0100, Al Viro wrote: It's somewhat pointless on its own... If you were doing something with the callers afterwards - sure, it would be make sense, but as it is... I'd really like to see -truncate and vmtruncate done, so from that side I'm absolutely in favour of this series. What I'm a bit concerned about is that it just does the trivial 1:1 conversion and not actually converts the sequence of operations to the proper form, which was one of the two big reasons of moving away from -truncate to start with. I'd love to see the full conversion, but without adequate test coverage for all the fringe filesystems that might be a bit too much to expect from Marco. I think just doing the easy conversions he did, and putting a TODO comment explaining how it should be taken further at each of the sites would be valueable on its own. You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago. kernel_thread() unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/ I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying -truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why vmtruncate() was a bad idea, leaving the functionality exactly as it used to be... -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote: You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago. kernel_thread() unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/ I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying -truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why vmtruncate() was a bad idea, leaving the functionality exactly as it used to be... As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement -truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece. -- 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: [git pull] vfs pile 3
On Sat, Oct 13, 2012 at 12:04:55PM -0400, Christoph Hellwig wrote: On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote: You know, I'm in the middle of dealing with one such TODO. Yours, as it were. From six years ago. kernel_thread() unexporting. TODO comments of any form are routinely shat upon and ignored, especially when shuffled away into less read parts of the tree... ;-/ I'd rather see it done fs-by-fs. Starting with something reasonably easy to test - minixfs would do nicely. Don't get me wrong - I'm all for burying -truncate(); what I'm worried about is that we'll end up burying the warning about the reasons why vmtruncate() was a bad idea, leaving the functionality exactly as it used to be... As mentioned I agree with the concern in principle. Let's start by taking Marco's patches for filesystems that use vmtruncate but don't actually implement -truncate. There's a few I remember offhand, e.g. procfs and ufs right now. Then we can do the actual work required ones piece by piece. Umm... That would be what, procfs? Frankly, I'm not sure that ATTR_SIZE for procfs actually should not be silently ignored. -i_size there is completely synthetic - it's not as if truncation would actually change the contents. And ufs situation is quite different - there vmtruncate() is used only on the -write_begin() side. -setattr() is already vmtruncate-free. What's needed there is an analog of e.g. ext2_write_failed(). -- 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/