* fs_struct refcounting: spinlock vs atomic
@ 2018-02-14 21:13 Enrico Weigelt
2018-02-15 9:14 ` Richard Weinberger
0 siblings, 1 reply; 5+ messages in thread
From: Enrico Weigelt @ 2018-02-14 21:13 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fs_struct refcounting: spinlock vs atomic
2018-02-14 21:13 fs_struct refcounting: spinlock vs atomic Enrico Weigelt
@ 2018-02-15 9:14 ` Richard Weinberger
2018-02-15 13:46 ` Enrico Weigelt
0 siblings, 1 reply; 5+ messages in thread
From: Richard Weinberger @ 2018-02-15 9:14 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fs_struct refcounting: spinlock vs atomic
2018-02-15 9:14 ` Richard Weinberger
@ 2018-02-15 13:46 ` Enrico Weigelt
2018-02-15 18:39 ` Al Viro
0 siblings, 1 reply; 5+ messages in thread
From: Enrico Weigelt @ 2018-02-15 13:46 UTC (permalink / raw)
To: Richard Weinberger; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fs_struct refcounting: spinlock vs atomic
2018-02-15 13:46 ` Enrico Weigelt
@ 2018-02-15 18:39 ` Al Viro
2018-02-15 18:52 ` Al Viro
0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2018-02-15 18:39 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Richard Weinberger, linux-kernel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fs_struct refcounting: spinlock vs atomic
2018-02-15 18:39 ` Al Viro
@ 2018-02-15 18:52 ` Al Viro
0 siblings, 0 replies; 5+ messages in thread
From: Al Viro @ 2018-02-15 18:52 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Richard Weinberger, linux-kernel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-02-15 18:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-14 21:13 fs_struct refcounting: spinlock vs atomic Enrico Weigelt
2018-02-15 9:14 ` Richard Weinberger
2018-02-15 13:46 ` Enrico Weigelt
2018-02-15 18:39 ` Al Viro
2018-02-15 18:52 ` Al Viro
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.