fs_struct refcounting: spinlock vs atomic

fs_struct refcounting: spinlock vs atomic

[Enrico Weigelt]

Hi folks,


in fork.c, a spinlock is held for fs_struct refcounting, while other
places - eg. switch_task_namespaces uses atomic_dec_and_test() on
the nsproxy.

What's the exact difference here ? Could the atomic counting also used
for fs_struct ?


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: fs_struct refcounting: spinlock vs atomic

[Richard Weinberger]

On Wed, Feb 14, 2018 at 10:13 PM, Enrico Weigelt <lkml@metux.net> wrote:
> Hi folks,
>
>
> in fork.c, a spinlock is held for fs_struct refcounting, while other
> places - eg. switch_task_namespaces uses atomic_dec_and_test() on
> the nsproxy.
>
> What's the exact difference here ? Could the atomic counting also used
> for fs_struct ?

Well, the spinlock protects more than just the counter. So atomic won't do it.

-- 
Thanks,
//richard

Re: fs_struct refcounting: spinlock vs atomic

[Enrico Weigelt]

On 15.02.2018 10:14, Richard Weinberger wrote:
> On Wed, Feb 14, 2018 at 10:13 PM, Enrico Weigelt <lkml@metux.net> wrote:
>> Hi folks,
>>
>>
>> in fork.c, a spinlock is held for fs_struct refcounting, while other
>> places - eg. switch_task_namespaces uses atomic_dec_and_test() on
>> the nsproxy.
>>
>> What's the exact difference here ? Could the atomic counting also used
>> for fs_struct ?
> 
> Well, the spinlock protects more than just the counter. So atomic won't do it.

Okay. Is that needed in that case ?

See unshare() syscall:

if (new_fs) {
	fs = current->fs;
	spin_lock(&fs->lock);
	current->fs = new_fs;
	if (--fs->users)
		new_fs = NULL;
	else
		new_fs = fs;
	spin_unlock(&fs->lock);
}

Seems to me, that we're just refcounting here, and once it went dont to
zero, nobody else can access it anymore.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: fs_struct refcounting: spinlock vs atomic

[Al Viro]

On Thu, Feb 15, 2018 at 02:46:19PM +0100, Enrico Weigelt wrote:
> On 15.02.2018 10:14, Richard Weinberger wrote:
> > On Wed, Feb 14, 2018 at 10:13 PM, Enrico Weigelt <lkml@metux.net> wrote:
> > > Hi folks,
> > > 
> > > 
> > > in fork.c, a spinlock is held for fs_struct refcounting, while other
> > > places - eg. switch_task_namespaces uses atomic_dec_and_test() on
> > > the nsproxy.
> > > 
> > > What's the exact difference here ? Could the atomic counting also used
> > > for fs_struct ?
> > 
> > Well, the spinlock protects more than just the counter. So atomic won't do it.
> 
> Okay. Is that needed in that case ?
> 
> See unshare() syscall:
> 
> if (new_fs) {
> 	fs = current->fs;
> 	spin_lock(&fs->lock);
> 	current->fs = new_fs;
> 	if (--fs->users)
> 		new_fs = NULL;
> 	else
> 		new_fs = fs;
> 	spin_unlock(&fs->lock);
> }
> 
> Seems to me, that we're just refcounting here, and once it went dont to
> zero, nobody else can access it anymore.

Not true.  We also assume that once fs_struct has been locked, the number of
tasks with reference to it won't change.  See fs/exec.c:check_unsafe_exec(),
for example.

Re: fs_struct refcounting: spinlock vs atomic

[Al Viro]

On Thu, Feb 15, 2018 at 06:39:57PM +0000, Al Viro wrote:

> Not true.  We also assume that once fs_struct has been locked, the number of
> tasks with reference to it won't change.  See fs/exec.c:check_unsafe_exec(),
> for example.

PS: any discussion of VFS and filesystems stuff belongs on fsdevel; Cc to l-k
is fine, but don't expect anyone to be able to reliably spot it there.

l-k is far too high volume (and low S/N) to keep up with it; some of us have
entirely given up on it (Linus is certainly not the only one who'd unsubscribed
from l-k many years ago), some try to scan it for something relevant, but
latency and reliability of such scans inevitably sucks.