linux-kernel - Re: Is module refcounting racy?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 31 Mar 2010 14:14:49 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Nick Piggin <npiggin@...il.com>
Cc:	Nick Piggin <npiggin@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Jon Masters <jonathan@...masters.org>
Subject: Re: Is module refcounting racy?

On Tue, 30 Mar 2010 03:28:49 am Nick Piggin wrote:
> On Mon, Mar 29, 2010 at 8:12 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> > On Thu, 18 Mar 2010 09:25:34 pm Nick Piggin wrote:
> >> Hey,
> >>
> >> I've been looking at weird and wonderful ways to do scalable refcounting,
> >> for the vfs...
> >>
> >> Sadly, module refcounting doesn't fit my bill. But as far as I could see,
> >> it is racy.
> >
> > Other than for advisory purposes, the refcount is only checked against zero
> > under stop_machine.  For exactly this reason.
> 
> There definitely looks to me like there is code that checks the refcount
> *without* stop_machine. module_refcount is an exported function, and you
> expect drivers to get this right (scsi_device_put for a trivial example)

No, but there's a lot of history of crap drivers which wanted to poke at it.
And it's cute for debugging.

The scsi code is simply wrong.  But noone cares, since module removal is
so rare.

> , but
> it even looks like it is used in a racy way in kernel/module.c code.

Yep, though I don't know if anyone uses waiting module removal AFAICT
though; there's not even a modprobe option for it.

> Either we need to take my patch, or audit t, and put a WARN_ON
> if it is called while not under stop_machine.

So can you send me a proper annotated signed-off patch to queue?

Note that years ago it was decided that module reference counting would be
best effort, rather than perfect.  I disagreed, but we've lived with it
surprisingly well.

I wonder if by caring even *less*, we can lose a lot of complexity without
noticeably increasing the bug count.  Make modules run their own reference
counts and just sleep for a while to see if the reference count changes.
If not, assume it's good to be removed.  If reference count still hasn't
moved after another minute or so, actually free the memory.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/