From: Andrew Morton <akpm@linux-foundation.org>
To: Nick Krause <xerofoify@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Dan Carpenter <dan.carpenter@oracle.com>,
viro@zeniv.linux.org.uk, fabf@skynet.be,
kirill.shutemov@linux.intel.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Check for Null return of function of affs_bread in function affs_truncate
Date: Fri, 20 Jun 2014 19:38:19 -0700 [thread overview]
Message-ID: <20140620193819.e379a55b.akpm@linux-foundation.org> (raw)
In-Reply-To: <CAPDOMVihML8uWwBWRTPGG_abHxrW++xP9_Po7B0_KQZmDfHv-Q@mail.gmail.com>
On Fri, 20 Jun 2014 22:25:47 -0400 Nick Krause <xerofoify@gmail.com> wrote:
> 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.
next prev parent reply other threads:[~2014-06-21 2:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 22:08 [PATCH] Check for Null return of function of affs_bread in function affs_truncate Nicholas Krause
2014-06-19 5:21 ` Dan Carpenter
2014-06-20 16:30 ` Nick Krause
2014-06-20 23:59 ` Thomas Gleixner
2014-06-21 2:25 ` Nick Krause
2014-06-21 2:38 ` Andrew Morton [this message]
2014-06-21 2:55 ` Nick Krause
2014-06-21 3:09 ` Andrew Morton
2014-06-21 3:20 ` Nick Krause
2014-06-22 19:12 ` Al Viro
2014-07-11 15:05 ` Dan Carpenter
2014-07-13 6:18 ` Nick Krause
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140620193819.e379a55b.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dan.carpenter@oracle.com \
--cc=fabf@skynet.be \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=xerofoify@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).