Al Viro writes:
> On Tue, Dec 19, 2017 at 07:40:43PM +0100, Giuseppe Scrivano wrote:
>> Giuseppe Scrivano writes:
>>
>> > The only issue I've seen with my version is that if I do:
>> >
>> > # unshare -im /bin/sh
>> > # mount -t mqueue mqueue /dev/mqueue
>> > # touch /dev/mqueue/foo
>> > # umoun
Al Viro writes:
> On Tue, Dec 19, 2017 at 03:49:24PM -0600, Eric W. Biederman wrote:
>> > what would you be delaying? kmem_cache_alloc() for struct mount and
>> > assignments
>> > to its fields? That's noise; if anything, I would expect the main cost
>> > with
>> > a plenty of containers to b
On Tue, Dec 19, 2017 at 03:49:24PM -0600, Eric W. Biederman wrote:
> > what would you be delaying? kmem_cache_alloc() for struct mount and
> > assignments
> > to its fields? That's noise; if anything, I would expect the main cost with
> > a plenty of containers to be in sget() scanning the list
Al Viro writes:
> On Tue, Dec 19, 2017 at 07:40:43PM +0100, Giuseppe Scrivano wrote:
>> Giuseppe Scrivano writes:
>>
>> > The only issue I've seen with my version is that if I do:
>> >
>> > # unshare -im /bin/sh
>> > # mount -t mqueue mqueue /dev/mqueue
>> > # touch /dev/mqueue/foo
>> > # umoun
On Tue, Dec 19, 2017 at 07:40:43PM +0100, Giuseppe Scrivano wrote:
> Giuseppe Scrivano writes:
>
> > The only issue I've seen with my version is that if I do:
> >
> > # unshare -im /bin/sh
> > # mount -t mqueue mqueue /dev/mqueue
> > # touch /dev/mqueue/foo
> > # umount /dev/mqueue
> > # mount -t
Giuseppe Scrivano writes:
> The only issue I've seen with my version is that if I do:
>
> # unshare -im /bin/sh
> # mount -t mqueue mqueue /dev/mqueue
> # touch /dev/mqueue/foo
> # umount /dev/mqueue
> # mount -t mqueue mqueue /dev/mqueue
>
> then /dev/mqueue/foo doesn't exist at this point. You
Dmitry Vyukov writes:
>> Unrelated issue, but register_filesystem() should be the last thing
>> module_init() of a filesystem driver does. It's a separate story,
>> in any case...
>
> Giuseppe, what report is this?
> If there is a reproducer, you can ask syzbot to test a patch.
I have tried loc
Al Viro writes:
> On Tue, Dec 19, 2017 at 11:48:19AM +, Al Viro wrote:
>> On Tue, Dec 19, 2017 at 11:14:40AM +0100, Giuseppe Scrivano wrote:
>> > mqueue_evict_inode() doesn't access the ipc namespace if it was
>> > already freed. It can happen if in a new IPC namespace the inode was
>> > cre
On Tue, Dec 19, 2017 at 4:44 PM, Al Viro wrote:
> On Tue, Dec 19, 2017 at 03:32:25PM +, Al Viro wrote:
>> + m = mq_internal_mount();
>> + if (IS_ERR(m))
>> + return ERR_CAST(m);
>> + atomic_inc(&m->mnt_sb->s_active);
>> + down_write(&m->mnt_sb->s_umount);
>> + r
On Tue, Dec 19, 2017 at 03:32:25PM +, Al Viro wrote:
> + m = mq_internal_mount();
> + if (IS_ERR(m))
> + return ERR_CAST(m);
> + atomic_inc(&m->mnt_sb->s_active);
> + down_write(&m->mnt_sb->s_umount);
> + return dget(m->mnt_root);
Note: this is stripped down mou
On Tue, Dec 19, 2017 at 11:48:19AM +, Al Viro wrote:
> On Tue, Dec 19, 2017 at 11:14:40AM +0100, Giuseppe Scrivano wrote:
> > mqueue_evict_inode() doesn't access the ipc namespace if it was
> > already freed. It can happen if in a new IPC namespace the inode was
> > created without a prior mq_
On Tue, Dec 19, 2017 at 11:14:40AM +0100, Giuseppe Scrivano wrote:
> mqueue_evict_inode() doesn't access the ipc namespace if it was
> already freed. It can happen if in a new IPC namespace the inode was
> created without a prior mq_open() which creates the vfsmount used to
> access the superblock
mqueue_evict_inode() doesn't access the ipc namespace if it was
already freed. It can happen if in a new IPC namespace the inode was
created without a prior mq_open() which creates the vfsmount used to
access the superblock from mq_clear_sbinfo().
Keep a direct pointer to the superblock used by t
13 matches
Mail list logo