On Wed, May 10, 2017 at 3:48 PM, Jeff Layton wrote:
> I was thinking that you'd need some well-defined way to tell whether the
> string should be replaced. If the thing just hangs out across syscalls,
> then you don't know when it got put there. Is it a leftover from a
> previous syscall or did a
On Wed, 2017-05-10 at 15:30 +0200, Miklos Szeredi wrote:
> On Wed, May 10, 2017 at 3:20 PM, Jeff Layton wrote:
> > On Wed, 2017-05-10 at 09:05 +0100, David Howells wrote:
> > > Miklos Szeredi wrote:
> > >
> > > > Possible rule of thumb: use it only at the place where the error
> > > > originates
On Wed, 2017-05-10 at 14:31 +0100, David Howells wrote:
> Jeff Layton wrote:
>
> > One idea might be to always kfree it on syscall entry
>
> You can't do that otherwise there's no way to retrieve the strings.
>
>
True...you'd have to exempt the syscall that does the retrieving.
--
Jeff Layto
> That's why I liked the static string thing. It's just one assignment
> and no worries about freeing. Not sure what to do about modules,
> though. Can we somehow move the cost of checking the validity to the
> place where the error is retrieved?
I'm thinking along the lines of not allowing mod
Jeff Layton wrote:
> One idea might be to always kfree it on syscall entry
You can't do that otherwise there's no way to retrieve the strings.
David
On Wed, May 10, 2017 at 3:20 PM, Jeff Layton wrote:
> On Wed, 2017-05-10 at 09:05 +0100, David Howells wrote:
>> Miklos Szeredi 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 mo
On Wed, 2017-05-10 at 09:05 +0100, David Howells wrote:
> Miklos Szeredi 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
On Tue, May 09, 2017 at 10:03:43AM +0200, Miklos Szeredi wrote:
> On Tue, May 9, 2017 at 12:57 AM, David Howells wrote:
> > Miklos Szeredi wrote:
> >
> >> > + (3) Validate and pre-process the mount context.
> >>
> >> (3.5) Create super block
> >>
> >> I think this need to be triggered by somethin
Miklos Szeredi wrote:
> 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
On Tue, May 9, 2017 at 8:51 PM, Jeff Layton wrote:
> On Tue, 2017-05-09 at 14:02 +0200, Miklos Szeredi wrote:
>> On Tue, May 9, 2017 at 11:41 AM, David Howells wrote:
>> > Miklos Szeredi wrote:
>> >
>> > > I think that's crazy. We don't return detailed errors for any other
>> > > syscall for pa
On Tue, 2017-05-09 at 14:02 +0200, Miklos Szeredi wrote:
> On Tue, May 9, 2017 at 11:41 AM, David Howells wrote:
> > Miklos Szeredi wrote:
> >
> > > I think that's crazy. We don't return detailed errors for any other
> > > syscall for path lookup, so why would path lookup for mount be
> > > spe
On Tue, May 9, 2017 at 11:56 AM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> So say we have commands like
>>
>> "o+ foo"
>> "o- bar"
>
> The convention seems to be to prepend "no" to things you want to disable, so
> let's stick with that, e.g.:
>
> "o foo"
> "o nobar"
>
> ot
On Tue, May 9, 2017 at 11:41 AM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> I think that's crazy. We don't return detailed errors for any other
>> syscall for path lookup, so why would path lookup for mount be
>> special.
>
> Firstly, we don't return detailed errors for mount() at the mom
On Tue, May 9, 2017 at 11:32 AM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> Forget remount, it's a historical remnant.
>
> I don't think it can't be set aside so lightly. Within the kernel, the option
> parsing should share as much code as possible between new superblock config,
> old new
Miklos Szeredi wrote:
> So say we have commands like
>
> "o+ foo"
> "o- bar"
The convention seems to be to prepend "no" to things you want to disable, so
let's stick with that, e.g.:
"o foo"
"o nobar"
otherwise we will have to have separate parsers for old mount() and the new
Miklos Szeredi wrote:
> I think that's crazy. We don't return detailed errors for any other
> syscall for path lookup, so why would path lookup for mount be
> special.
Firstly, we don't return detailed errors for mount() at the moment either.
Secondly, path lookup might entail automounts, so p
Miklos Szeredi wrote:
> Forget remount, it's a historical remnant.
I don't think it can't be set aside so lightly. Within the kernel, the option
parsing should share as much code as possible between new superblock config,
old new mount and old remount.
The 'trickiest' function we need to suppo
On Tue, May 9, 2017 at 12:57 AM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> > + (3) Validate and pre-process the mount context.
>>
>> (3.5) Create super block
>>
>> I think this need to be triggered by something like a "commit" command
>> from userspace. Basically this is where the option
Miklos Szeredi wrote:
> > + (3) Validate and pre-process the mount context.
>
> (3.5) Create super block
>
> I think this need to be triggered by something like a "commit" command
> from userspace. Basically this is where the options are atomically
> set on the new (create) or existing (reconf
On Wed, May 3, 2017 at 6:04 PM, David Howells wrote:
> Introduce a mount context concept. This is allocated at the beginning of
> the mount procedure and into it is placed:
>
> (1) Filesystem type.
>
> (2) Namespaces.
>
> (3) Device name.
>
> (4) Superblock flags (MS_*) and mount flags (MNT_*
On Thu, 2017-05-04 at 10:27 +0100, David Howells wrote:
> Joe Perches wrote:
>
> > krealloc would probably be more efficient and possible
> > readable as likely there's already padding in the original
> > allocation.
>
> Given there's a maximum of 3 slots, I think it makes better sense to just
>
Rasmus Villemoes wrote:
> > + if (fs_type->fsopen && fs_type->mc_size < sizeof(*mc))
> > + BUG();
>
> So ->mc_size can be 0 (i.e. not explicitly initialized) if fs_type does
> not have ->fsopen. OK.
I need to be able to handle filesystems that don't support this yet. Once all
files
Joe Perches wrote:
> krealloc would probably be more efficient and possible
> readable as likely there's already padding in the original
> allocation.
Given there's a maximum of 3 slots, I think it makes better sense to just
allocate them all up front.
David
On Wed, 3 May 2017, Joe Perches wrote:
> (adding Julia Lawall and cocci)
>
> On Wed, 2017-05-03 at 13:38 -0700, Matthew Wilcox wrote:
> > On Wed, May 03, 2017 at 11:26:38AM -0700, Joe Perches wrote:
> > > On Wed, 2017-05-03 at 14:13 -0400, Jeff Layton wrote:
> > > > On Wed, 2017-05-03 at 17:04 +
On Wed, May 03 2017, David Howells wrote:
> fs_type->fsopen() is called to set it up. fs_type->mc_size says how much
> should be added on to the mount context for the filesystem's use.
This is repeated several times in the documentation, but the code says
that ->mc_size should be the full size
(adding Julia Lawall and cocci)
On Wed, 2017-05-03 at 13:38 -0700, Matthew Wilcox wrote:
> On Wed, May 03, 2017 at 11:26:38AM -0700, Joe Perches wrote:
> > On Wed, 2017-05-03 at 14:13 -0400, Jeff Layton wrote:
> > > On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote:
> > > > + oo
Matthew Wilcox wrote:
> On Wed, May 03, 2017 at 11:26:38AM -0700, Joe Perches wrote:
> > On Wed, 2017-05-03 at 14:13 -0400, Jeff Layton wrote:
> > > On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote:
> > > > + oo = kmalloc((opts->num_mnt_opts + 1) * sizeof(char *),
> > > > +
On Wed, May 03, 2017 at 11:26:38AM -0700, Joe Perches wrote:
> On Wed, 2017-05-03 at 14:13 -0400, Jeff Layton wrote:
> > On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote:
> > > + oo = kmalloc((opts->num_mnt_opts + 1) * sizeof(char *),
> > > + GFP_KERNEL);
If we'r
Joe Perches wrote:
> > > krealloc would probably be more efficient and possible
> > > readable as likely there's already padding in the original
> > > allocation.
> >
> > The problem is if krealloc() fails: you've lost all those pointers to things
> > you then need to free.
>
> Huh? How could
On Wed, 2017-05-03 at 19:37 +0100, David Howells wrote:
> Joe Perches wrote:
>
> > krealloc would probably be more efficient and possible
> > readable as likely there's already padding in the original
> > allocation.
>
> The problem is if krealloc() fails: you've lost all those pointers to thing
Joe Perches wrote:
> krealloc would probably be more efficient and possible
> readable as likely there's already padding in the original
> allocation.
The problem is if krealloc() fails: you've lost all those pointers to things
you then need to free.
> Are there no locking constraints?
General
On Wed, 2017-05-03 at 14:13 -0400, Jeff Layton wrote:
> On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote:
> > Introduce a mount context concept.
trivia:
> > static int selinux_mount_ctx_option(struct mount_context *mc, char *opt)
> > +{
[]
> > + if (opts->mnt_opts) {
> > + oo =
On Wed, 2017-05-03 at 17:04 +0100, David Howells wrote:
> Introduce a mount context concept. This is allocated at the beginning of
> the mount procedure and into it is placed:
>
> (1) Filesystem type.
>
> (2) Namespaces.
>
> (3) Device name.
>
> (4) Superblock flags (MS_*) and mount flags
Introduce a mount context concept. This is allocated at the beginning of
the mount procedure and into it is placed:
(1) Filesystem type.
(2) Namespaces.
(3) Device name.
(4) Superblock flags (MS_*) and mount flags (MNT_*).
(5) Security details.
(6) Filesystem-specific data, as set by t
34 matches
Mail list logo
