linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: David Howells <dhowells@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>
Cc: viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-nfs@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/9] VFS: Introduce a mount context
Date: Wed, 10 May 2017 09:20:09 -0400	[thread overview]
Message-ID: <1494422409.2688.13.camel@redhat.com> (raw)
In-Reply-To: <30059.1494403518@warthog.procyon.org.uk>

On Wed, 2017-05-10 at 09:05 +0100, David Howells wrote:
> Miklos Szeredi <mszeredi@redhat.com> wrote:
>
> > Possible rule of thumb: use it only at the place where the error
> > originates and not where errors are just passed on.  This would result
> > in at most one report per syscall, normally.
> >

That might be hard to enforce in practice once you get into some
complicated layering. What if we have device_mapper setting this along
with filesystems too? We need clear rules here.

> > And the static string thing that David implemented is also a very good
> > idea, IMO.
> 
> There is an issue with it: it's fine as long as you keep a ref on the module
> that generated it or clear all strings as part of module removal (which the
> mount context in this patchset does).  With the NFS mount context I did, I
> have to keep a ref on the NFS protocol module as well as the NFS filesystem
> module.
> 
> I'm tempted to make it conditionally copy the string using kvasprintf_const()
> - which would also permit format substitution.
> 

On balance, I think this is a reasonable way to pass back detailed
errors. Up until now, we've mostly relied on just printk'ing them. Now
though, a lot of larger machines are running containerized setups. Good
luck scraping dmesg for _your_ error in that situation. There may be
tons of mounts failing all over the place.

That said, I have some concerns here:

What's the lifetime of these strings? Do they just hang around forever
until the process goes away or they're replaced? If this becomes common,
then you could easily end up with an extra string allocation per task in
some cases. That could add up.

One idea might be to always kfree it on syscall entry, and that might
mitigate the problem assuming that not everything is erroring out. Then
you could always do some trivial syscall to clear it manually.

There's also the problem of how these should be formatted. Is English ok
everywhere? Do we need a facility to allow translating these things?
-- 
Jeff Layton <jlayton@redhat.com>

  reply	other threads:[~2017-05-10 13:20 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03 16:04 [RFC][PATCH 0/9] VFS: Introduce mount context David Howells
2017-05-03 16:04 ` [PATCH 1/9] Provide a function to create a NUL-terminated string from unterminated data David Howells
2017-05-03 16:55   ` Jeff Layton
2017-05-03 19:26   ` Rasmus Villemoes
2017-05-03 20:13   ` David Howells
2017-05-03 16:04 ` [PATCH 2/9] Clean up whitespace in fs/namespace.c David Howells
2017-05-03 16:04 ` [PATCH 3/9] VFS: Introduce a mount context David Howells
2017-05-03 18:13   ` Jeff Layton
2017-05-03 18:26     ` Joe Perches
2017-05-03 20:38       ` Matthew Wilcox
2017-05-03 21:36         ` Joe Perches
2017-05-04  6:28           ` Julia Lawall
2017-05-03 21:17       ` David Howells
2017-05-03 18:37     ` David Howells
2017-05-03 18:43       ` Joe Perches
2017-05-03 20:11       ` David Howells
2017-05-04  9:27     ` David Howells
2017-05-04 14:34       ` Joe Perches
2017-05-03 21:43   ` Rasmus Villemoes
2017-05-04 10:22   ` David Howells
2017-05-08 15:05   ` Miklos Szeredi
2017-05-08 22:57   ` David Howells
2017-05-09  8:03     ` Miklos Szeredi
2017-05-10 12:41       ` Karel Zak
2017-05-09  9:32     ` David Howells
2017-05-09 11:04       ` Miklos Szeredi
2017-05-09  9:41     ` David Howells
2017-05-09 12:02       ` Miklos Szeredi
2017-05-09 18:51         ` Jeff Layton
2017-05-10  7:24           ` Miklos Szeredi
2017-05-10  8:05           ` David Howells
2017-05-10 13:20             ` Jeff Layton [this message]
2017-05-10 13:30               ` Miklos Szeredi
2017-05-10 13:33                 ` Miklos Szeredi
2017-05-10 13:48                 ` Jeff Layton
2017-05-12  8:15                   ` Miklos Szeredi
2017-05-10 13:31             ` David Howells
2017-05-10 13:37               ` Jeff Layton
2017-05-09  9:56     ` David Howells
2017-05-09 12:38       ` Miklos Szeredi
2017-05-03 16:05 ` [PATCH 4/9] Implement fsopen() to prepare for a mount David Howells
2017-05-03 18:37   ` Jeff Layton
2017-05-03 18:41   ` David Howells
2017-05-03 20:44   ` Rasmus Villemoes
2017-05-04 10:40   ` Karel Zak
2017-05-04 12:55   ` David Howells
2017-05-04 12:58   ` David Howells
2017-05-04 13:06   ` David Howells
2017-05-04 13:34     ` Karel Zak
2017-05-09 18:40       ` Jeff Layton
2017-05-08 15:10   ` Miklos Szeredi
2017-05-08 23:09   ` David Howells
2017-05-03 16:05 ` [PATCH 5/9] Implement fsmount() to effect a pre-configured mount David Howells
2017-05-03 16:05 ` [PATCH 6/9] Sample program for driving fsopen/fsmount David Howells
2017-05-03 16:05 ` [PATCH 7/9] procfs: Move proc_fill_super() to fs/proc/root.c David Howells
2017-05-03 16:05 ` [PATCH 8/9] proc: Support the mount context in procfs David Howells
2017-05-03 16:05 ` [PATCH 9/9] NFS: Support the mount context and fsopen() David Howells
2017-05-03 16:44 ` [RFC][PATCH 0/9] VFS: Introduce mount context Jeff Layton
2017-05-03 16:50 ` David Howells
2017-05-03 17:27   ` Jeff Layton
2017-05-05 14:35 ` Miklos Szeredi
2017-05-05 15:47 ` David Howells
2017-05-08  8:25   ` Miklos Szeredi
2017-05-08  8:35 ` David Howells
2017-05-08  8:43   ` Miklos Szeredi
2017-05-08 17:03 ` Djalal Harouni

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=1494422409.2688.13.camel@redhat.com \
    --to=jlayton@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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).