Re: more devfs fun (Piled Higher and Deeper)

[Richard Gooch <rgooch@ras.ucalgary.ca>]

Alexander Viro writes:
> ... and one more - devfs_unregister() on a directory happening when
> mknod() in that directory sleeps in create_entry() (on kmalloc()).
> 
> Do you ever read your own code?  It's not like this stuff was hard
> to find - I'm just poking into random places and every damn one
> contains a hole.  Sigh...
> 
> Oh, BTW - here's another one:  think what happens if tree-walking in
> unregister() steps on the entry we are currently removing in
> devfs_unlink().

Yep, as I've long ago admitted, there are races in the old devfs
code, which couldn't be fixed without proper locking. And that's why
I've been wanting to add said locking for ages, and have been
frustrated at interruptions which delayed that work. And I'm very
happy to get the first cut of the new code released.

That said, try to understand (before getting emotional and launching
off a tirade such as the one last week) that different people have
different priorities, and mine was to provide functionality first, and
worry about hostile attacks/exploits later. This is not unreasonable
if you consider that the initial target machines for devfs were:
- my personal boxes (which are not public machines)
- big-iron machines sitting behind a firewall
- small university group sitting behind a firewall (and I know where
  all the users live:-)

I know your favourite horror scenario is the public machines available
to the undergrads, but not everyone works in such a hostile
environment.

Anyway, I hope Linus wasn't bored by all the messages you Cc:ed to
him for your^H^H^H^Hhis benefit :-O

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca