Messages in this thread | | | Date | Mon, 21 Jan 2019 23:14:17 +0100 | From | David Sterba <> | Subject | Re: [PATCH v4 1/3] fs: hoist EFSCORRUPTED definition into uapi header |
| |
On Mon, Jan 21, 2019 at 04:54:54PM -0500, Theodore Y. Ts'o wrote: > On Fri, Jan 18, 2019 at 05:14:38PM +0100, Jann Horn wrote: > > Multiple filesystems can already return EFSCORRUPTED errors to userspace; > > however, so far, definitions of EFSCORRUPTED were in filesystem-private > > headers. > > > > I wanted to use EUCLEAN to indicate data corruption in the VFS layer; > > Dave Chinner says that I should instead hoist the definitions of > > EFSCORRUPTED into the UAPI header and then use EFSCORRUPTED. > > > > This patch is marked for stable backport because it is a prerequisite for > > the following patch. > > > > Cc: stable@vger.kernel.org > > Suggested-by: Dave Chinner <david@fromorbit.com> > > Signed-off-by: Jann Horn <jannh@google.com> > > Before we enshrine the overloading of EUCLEAN and EFSCORRUPTED, I > wonder if we should at least consider the option of assigning a new > error code number for EFSCORRUPTED. The downside of doing this is > that for a while, older versions glibc won't have strerror/perror > translation for the new error code. On the other hand, I'm not sure > it will be that much more confusing to the average user than > "Structure needs cleaning". :-) > > The upside of assigning a new error code is that in a year or two, > we'll actually have an intelligible error message showing up in log > files and in user's terminals.
I vote for a new code with a better message than EUCLEAN provides.
| |