Fair enough if somebody is running this file system I would be
happy to have someone test my code in order to fix this.
Cheers Nick

On Fri, Jun 20, 2014 at 10:38 PM, Andrew Morton
[off-list ref] wrote:

On Fri, 20 Jun 2014 22:25:47 -0400 Nick Krause [off-list ref] wrote:

quoted

If you have any ideas about what is better
please let me known.

I think the proposed patch was not a good one - it will cause truncate
to silently return, probably leaving the fs in an inconsistent state.
Neither the user nor the running application know this happened so they
will just keep on modifying the filesystem, possibly mangling it
further.

The code as it stands at present is better - if bread() fails we'll get
a nice solid oops and the current app will be terminated (at least).
As we're in truncate it's quite possible that the entire fs will get
wedged up due to now-permanently-held i_mutex, which is even better.


As for the best fix, umm, hard.  We're pretty screwed if we cannot read
that block at this code site.  Perhaps emit loud printks, forcibly turn
the fs read-only then return -EIO/-ENOMEM/etc from the truncate.  Such
a change would require runtime testing, with some form of developer fault
injection.