On Sun, Mar 26, 2017 at 09:03:33AM +0200, Djalal Harouni wrote:
> (Cc'ed Kees and Jann for the procfs stacking issue)
>
> > I completely agree with you that it looks wrong when options of one
> > mountpoint affect the others mountpoints.
> >
> >> I'm not sure if that's the right approach, it is
On Sun, Mar 26, 2017 at 09:03:33AM +0200, Djalal Harouni wrote:
> (Cc'ed Kees and Jann for the procfs stacking issue)
>
> > I completely agree with you that it looks wrong when options of one
> > mountpoint affect the others mountpoints.
> >
> >> I'm not sure if that's the right approach, it is
(Cc'ed Kees and Jann for the procfs stacking issue)
On Thu, Mar 23, 2017 at 11:07 PM, Alexey Gladkov
wrote:
> On Thu, Mar 23, 2017 at 05:06:28PM +0100, Djalal Harouni wrote:
>> Hi Alexey,
>>
>> On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
>>
(Cc'ed Kees and Jann for the procfs stacking issue)
On Thu, Mar 23, 2017 at 11:07 PM, Alexey Gladkov
wrote:
> On Thu, Mar 23, 2017 at 05:06:28PM +0100, Djalal Harouni wrote:
>> Hi Alexey,
>>
>> On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
>> wrote:
>> >
>> >
>> > Al Viro, this patch looks
On Thu, Mar 23, 2017 at 05:05:07PM +0100, Oleg Nesterov wrote:
> Again, I can't really review this, I know nothing about vfs, but since
> nobody else replied...
Thanks anyway :)
> On 03/20, Alexey Gladkov wrote:
> >
> > @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct
> >
On Thu, Mar 23, 2017 at 05:05:07PM +0100, Oleg Nesterov wrote:
> Again, I can't really review this, I know nothing about vfs, but since
> nobody else replied...
Thanks anyway :)
> On 03/20, Alexey Gladkov wrote:
> >
> > @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct
> >
On Thu, Mar 23, 2017 at 05:06:28PM +0100, Djalal Harouni wrote:
> Hi Alexey,
>
> On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
> wrote:
> >
> >
> > Al Viro, this patch looks better ?
> >
> > == Overview ==
> >
> > Some of the container virtualization systems are
On Thu, Mar 23, 2017 at 05:06:28PM +0100, Djalal Harouni wrote:
> Hi Alexey,
>
> On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
> wrote:
> >
> >
> > Al Viro, this patch looks better ?
> >
> > == Overview ==
> >
> > Some of the container virtualization systems are mounted /proc inside
> > the
Again, I can't really review this, I know nothing about vfs, but since
nobody else replied...
On 03/20, Alexey Gladkov wrote:
>
> @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct file_system_type
> *fs_type,
> ns = task_active_pid_ns(current);
> }
>
> - return
Again, I can't really review this, I know nothing about vfs, but since
nobody else replied...
On 03/20, Alexey Gladkov wrote:
>
> @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct file_system_type
> *fs_type,
> ns = task_active_pid_ns(current);
> }
>
> - return
Hi Alexey,
On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
wrote:
>
>
> Al Viro, this patch looks better ?
>
> == Overview ==
>
> Some of the container virtualization systems are mounted /proc inside
> the container. This is done in most cases to operate with
Hi Alexey,
On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
wrote:
>
>
> Al Viro, this patch looks better ?
>
> == Overview ==
>
> Some of the container virtualization systems are mounted /proc inside
> the container. This is done in most cases to operate with information
> about the processes.
Al Viro, this patch looks better ?
== Overview ==
Some of the container virtualization systems are mounted /proc inside
the container. This is done in most cases to operate with information
about the processes. Knowing that /proc filesystem is not fully
virtualized they are mounted on top of
Al Viro, this patch looks better ?
== Overview ==
Some of the container virtualization systems are mounted /proc inside
the container. This is done in most cases to operate with information
about the processes. Knowing that /proc filesystem is not fully
virtualized they are mounted on top of
On Mon, Mar 13, 2017 at 6:27 AM, Al Viro wrote:
> On Sun, Mar 12, 2017 at 08:19:33PM -0700, Andy Lutomirski wrote:
>> On Sat, Mar 11, 2017 at 6:13 PM, Al Viro wrote:
>> > PS: AFAICS, simple mount --bind of your pid-only mount will suddenly
>> >
On Mon, Mar 13, 2017 at 6:27 AM, Al Viro wrote:
> On Sun, Mar 12, 2017 at 08:19:33PM -0700, Andy Lutomirski wrote:
>> On Sat, Mar 11, 2017 at 6:13 PM, Al Viro wrote:
>> > PS: AFAICS, simple mount --bind of your pid-only mount will suddenly
>> > expose the full thing. And as for the lifetimes
On Sun, Mar 12, 2017 at 08:19:33PM -0700, Andy Lutomirski wrote:
> On Sat, Mar 11, 2017 at 6:13 PM, Al Viro wrote:
> > PS: AFAICS, simple mount --bind of your pid-only mount will suddenly
> > expose the full thing. And as for the lifetimes making no sense...
> > note
On Sun, Mar 12, 2017 at 08:19:33PM -0700, Andy Lutomirski wrote:
> On Sat, Mar 11, 2017 at 6:13 PM, Al Viro wrote:
> > PS: AFAICS, simple mount --bind of your pid-only mount will suddenly
> > expose the full thing. And as for the lifetimes making no sense...
> > note that you are simply not
On Sat, Mar 11, 2017 at 6:13 PM, Al Viro wrote:
> PS: AFAICS, simple mount --bind of your pid-only mount will suddenly
> expose the full thing. And as for the lifetimes making no sense...
> note that you are simply not freeing these structures of yours.
> Try to handle
On Sat, Mar 11, 2017 at 6:13 PM, Al Viro wrote:
> PS: AFAICS, simple mount --bind of your pid-only mount will suddenly
> expose the full thing. And as for the lifetimes making no sense...
> note that you are simply not freeing these structures of yours.
> Try to handle that and you'll get a
On Sun, Mar 12, 2017 at 01:54:38AM +, Al Viro wrote:
> On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote:
>
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 83de8b6..5bd1b84 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1759,6 +1759,8
On Sun, Mar 12, 2017 at 01:54:38AM +, Al Viro wrote:
> On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote:
>
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 83de8b6..5bd1b84 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1759,6 +1759,8
On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote:
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 83de8b6..5bd1b84 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1759,6 +1759,8 @@ struct super_operations {
> int (*thaw_super) (struct
On Tue, Mar 07, 2017 at 12:05:16AM +0100, Alexey Gladkov wrote:
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 83de8b6..5bd1b84 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1759,6 +1759,8 @@ struct super_operations {
> int (*thaw_super) (struct
On Thu, Mar 09, 2017 at 12:26:49PM +0100, Djalal Harouni wrote:
> I'm bit lost in the two discussion, however the main concern I was
> discussing with Andy was if you have per superblock proc mounts then
> each mount will end up with its own device ID st_dev, right now they
> share the same ID if
On Thu, Mar 09, 2017 at 12:26:49PM +0100, Djalal Harouni wrote:
> I'm bit lost in the two discussion, however the main concern I was
> discussing with Andy was if you have per superblock proc mounts then
> each mount will end up with its own device ID st_dev, right now they
> share the same ID if
On Tue, Mar 07, 2017 at 08:24:12AM -0800, Andy Lutomirski wrote:
> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov
> wrote:
> >
> > After discussion with Oleg Nesterov I reimplement my patch as an additional
> > option for /proc. This option affects the mountpoint. It
On Tue, Mar 07, 2017 at 08:24:12AM -0800, Andy Lutomirski wrote:
> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov
> wrote:
> >
> > After discussion with Oleg Nesterov I reimplement my patch as an additional
> > option for /proc. This option affects the mountpoint. It means that in one
> > pid
On Tue, Mar 07, 2017 at 06:49:09PM +0100, Oleg Nesterov wrote:
> I can't really review this... but in any case I think you should split
> this patch to separate the vfs and proc changes.
>
> On 03/07, Alexey Gladkov wrote:
> >
> > @@ -962,6 +963,14 @@ vfs_kern_mount(struct file_system_type *type,
On Tue, Mar 07, 2017 at 06:49:09PM +0100, Oleg Nesterov wrote:
> I can't really review this... but in any case I think you should split
> this patch to separate the vfs and proc changes.
>
> On 03/07, Alexey Gladkov wrote:
> >
> > @@ -962,6 +963,14 @@ vfs_kern_mount(struct file_system_type *type,
Djalal Harouni writes:
> On Tue, Mar 7, 2017 at 5:24 PM, Andy Lutomirski wrote:
>>
>> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov
>> wrote:
>> >
>> > After discussion with Oleg Nesterov I reimplement my patch as an additional
Djalal Harouni writes:
> On Tue, Mar 7, 2017 at 5:24 PM, Andy Lutomirski wrote:
>>
>> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov
>> wrote:
>> >
>> > After discussion with Oleg Nesterov I reimplement my patch as an additional
>> > option for /proc. This option affects the mountpoint. It
On Tue, Mar 7, 2017 at 5:24 PM, Andy Lutomirski wrote:
>
> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov
> wrote:
> >
> > After discussion with Oleg Nesterov I reimplement my patch as an additional
> > option for /proc. This option affects the
On Tue, Mar 7, 2017 at 5:24 PM, Andy Lutomirski wrote:
>
> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov
> wrote:
> >
> > After discussion with Oleg Nesterov I reimplement my patch as an additional
> > option for /proc. This option affects the mountpoint. It means that in one
> > pid namespace
I can't really review this... but in any case I think you should split
this patch to separate the vfs and proc changes.
On 03/07, Alexey Gladkov wrote:
>
> @@ -962,6 +963,14 @@ vfs_kern_mount(struct file_system_type *type, int flags,
> const char *name, void
> mnt->mnt.mnt_sb = root->d_sb;
I can't really review this... but in any case I think you should split
this patch to separate the vfs and proc changes.
On 03/07, Alexey Gladkov wrote:
>
> @@ -962,6 +963,14 @@ vfs_kern_mount(struct file_system_type *type, int flags,
> const char *name, void
> mnt->mnt.mnt_sb = root->d_sb;
On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov wrote:
>
> After discussion with Oleg Nesterov I reimplement my patch as an additional
> option for /proc. This option affects the mountpoint. It means that in one
> pid namespace it possible to have both the whole
On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov wrote:
>
> After discussion with Oleg Nesterov I reimplement my patch as an additional
> option for /proc. This option affects the mountpoint. It means that in one
> pid namespace it possible to have both the whole traditional /proc and
> /proc with
After discussion with Oleg Nesterov I reimplement my patch as an additional
option for /proc. This option affects the mountpoint. It means that in one
pid namespace it possible to have both the whole traditional /proc and
/proc with only pids subset.
However, it remains an open question about
After discussion with Oleg Nesterov I reimplement my patch as an additional
option for /proc. This option affects the mountpoint. It means that in one
pid namespace it possible to have both the whole traditional /proc and
/proc with only pids subset.
However, it remains an open question about
40 matches
Mail list logo