On 11/18, Ian Kent wrote:
>
> It might be sufficient to surround the contents of show_options() with a
> lock on wq_mutex and update the check at the top to
>
> "lock; if (!sbi || sbi->catatonic) {unlock, return 0; } ..."
Or perhaps you can add synchronize_rcu() after swap(oz_pgrp, new_pid),
then
On Sat, 2013-11-16 at 17:03 +0100, Oleg Nesterov wrote:
> On 11/15, Andrew Morton wrote:
> >
> > Enable autofs4 to work in a "container". oz_pgrp is converted from pid_t
> > to struct pid and this is stored at mount time based on the "pgrp=" option
> > or if the option is missing then the current
On 11/15, Andrew Morton wrote:
>
> Enable autofs4 to work in a "container". oz_pgrp is converted from pid_t
> to struct pid and this is stored at mount time based on the "pgrp=" option
> or if the option is missing then the current pgrp.
I don't understand this code, so I am probably wrong. And t
Quoting Miklos Szeredi (mik...@szeredi.hu):
> From: Sukadev Bhattiprolu
>
> This patch enables autofs4 to work in a "container". oz_pgrp is converted
> from
> pid_t to struct pid and this is stored at mount time based on the "pgrp="
> option
> or if the option is missing then the current pgrp.
From: Sukadev Bhattiprolu
This patch enables autofs4 to work in a "container". oz_pgrp is converted from
pid_t to struct pid and this is stored at mount time based on the "pgrp=" option
or if the option is missing then the current pgrp.
The "pgrp=" option is interpreted in the PID namespace of
On Mon, Nov 26, 2012 at 3:38 PM, Eric W. Biederman
wrote:
>
> So I don't know how much MS_UNBINDABLE helps over MS_PRIVATE. Both
> prevent propogation of changes to other namespaces. I don't know how
> much using MS_UNBINDABLE to also prevent bind mounts helps.
MS_PRIVATE says ops on children
Miklos Szeredi writes:
> On Mon, Nov 26, 2012 at 3:29 AM, Ian Kent wrote:
>>> > > MS_UNBINDABLE says: skip this mount when copying a mount tree, such
>>> > > as when the mount namespace is cloned.
>>> > >
>>> > > If you set MS_UNBINDABLE on autofs mounts then they will simply not
>>> > > appear
On Mon, Nov 26, 2012 at 3:29 AM, Ian Kent wrote:
>> > > MS_UNBINDABLE says: skip this mount when copying a mount tree, such
>> > > as when the mount namespace is cloned.
>> > >
>> > > If you set MS_UNBINDABLE on autofs mounts then they will simply not
>> > > appear in a cloned namespace. Which s
On Mon, 2012-11-26 at 07:25 +0800, Ian Kent wrote:
> On Sat, 2012-11-24 at 14:35 -0800, Eric W. Biederman wrote:
> > Miklos Szeredi writes:
> >
> > > On Sat, Nov 24, 2012 at 1:07 PM, Eric W. Biederman
> > > wrote:
> > >> Ian Kent writes:
> > >>
> > >>> On Sat, 2012-11-24 at 10:23 +0800, Ian Ken
On Sat, 2012-11-24 at 14:35 -0800, Eric W. Biederman wrote:
> Miklos Szeredi writes:
>
> > On Sat, Nov 24, 2012 at 1:07 PM, Eric W. Biederman
> > wrote:
> >> Ian Kent writes:
> >>
> >>> On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
> On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi w
Miklos Szeredi writes:
> On Sat, Nov 24, 2012 at 1:07 PM, Eric W. Biederman
> wrote:
>> Ian Kent writes:
>>
>>> On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
>
AFAICS autofs mounts mounted with MS_PRIVATE in the initial nam
On Sat, Nov 24, 2012 at 1:07 PM, Eric W. Biederman
wrote:
> Ian Kent writes:
>
>> On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
>>> On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
>>> AFAICS autofs mounts mounted with MS_PRIVATE in the initial namespace do
>>> propagate to the clon
Ian Kent writes:
> On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
>> On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
>> > Ian Kent writes:
>> >
>> > > On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
>> > >> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
>> > >> > Patch
On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
> On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
> > Ian Kent writes:
> >
> > > On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
> > >> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
> > >> > Patches were tested by the custo
On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
> Ian Kent writes:
>
> > On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
> >> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
> >> > Patches were tested by the customer.
> >> >
> >> > Ian, Eric, do these patches look OK?
> >>
Ian Kent writes:
> On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
>> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
>> > Patches were tested by the customer.
>> >
>> > Ian, Eric, do these patches look OK?
>>
>> They look OK to me but I'm still a bit concerned about changing the wa
On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
> > Patches were tested by the customer.
> >
> > Ian, Eric, do these patches look OK?
>
> They look OK to me but I'm still a bit concerned about changing the way
> this behaves, but I als
On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
> Patches were tested by the customer.
>
> Ian, Eric, do these patches look OK?
They look OK to me but I'm still a bit concerned about changing the way
this behaves, but I also believe this is the way we want it to behave.
Give me a little
Patches were tested by the customer.
Ian, Eric, do these patches look OK?
Thanks,
Miklos
From: Sukadev Bhattiprolu
This patch enables autofs4 to work in a "container". oz_pgrp is converted from
pid_t to struct pid and this is stored at mount time based on the "pgrp=" option
or if the opti
Gone over this issue once again, with a deeper understanding of what's
actually needed and updated the patches.
And I think these patches clearly fix the requirement of the customer:
autofs4 can be started in a "container" and it will be able to serve
mounts in that container.
If second patch mak
20 matches
Mail list logo
