do add_timer() *before* unlocking dev->lock, or unpleasant things can
happen if misdn_del_timer() on another CPU finds the sucker, calls
del_timer_sync() (which does nothing, since we hadn't started the
timer yet) and frees it, just as we get around to add_timer()...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

mark the victim with negative ->id if misdn_del_timer() finds it on
the list, have timer callback *not* move ones so marked to dev->expired
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

timer callback in timerdev.c both accesses struct mISDNtimer it's
called for *and* moves it to dev->expired.  We need del_timer_sync(),
or we risk kfree() freeing it right under dev_expire_timer() *and*
dev->expired getting corrupted.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

mind you, I'm not sure WTF would anybody _need_ that miscdevice
at all - no IO is possible for it, opening it only pins the module
down and is seriously racy, at that.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

... it's done already by __fput()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

... if not since 0.99 or so.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

it is not (and it has never been) an ->fsync() instance...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

it has grown by accident - directories there do *not* use page cache, so
there's nothing to write.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

we need to close the underlying procfs file and free ->private_data
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

switch binfmts that use ->read() to that (and to kernel_read()
in several cases in binfmt_flat - sure, it's nommu, but still,
doing ->read() into kmalloc'ed buffer...)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

* serialize the call of ->release() on per-pdeo mutex
* don't remove pdeo from per-pde list until we are through with it
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

* leave ->proc_fops alone; make ->pde_users negative instead
* trim pde_opener
* move relevant code in fs/proc/inode.c
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Switch huge if-statement in __proc_file_read() around.  This then puts the
single line loop break immediately after the if-statement and allows us to
de-indent the huge comment and make it take fewer lines.  The code following
the if-statement then follows naturally from the call to dp->read_proc().
Signed-off-by: David Howells <dhowells@redhat.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Just reading - parsing the results is left alone (and unspeakably
lousy).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

it's opened read-only and never installed into any descriptor tables;
fput() will do just as well.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

no need to do that anymore...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

misc device gets ->private_data pointing to struct miscdevice
on open(), so we can use that to get to per-device structure
instead of relying on file_operations being copied into it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Remove device_open/close() functions as they don't really do anything and
remove Device_Open as it isn't counted atomically and the value isn't used.
Signed-off-by: David Howells <dhowells@redhat.com>

Kill create_proc_entry() in favour of create_proc_read_entry(), proc_create()
and proc_create_data().
Signed-off-by: David Howells <dhowells@redhat.com>

create_proc_entry() shouldn't be used.  Rather proc_create_data() should be
used.  The proc_write() function is only used by #if'd out code, so delete it
for now.
Signed-off-by: David Howells <dhowells@redhat.com>

Don't use create_proc_entry() in nubus_proc_subdir().  The files created aren't
given any way to use them, so for the moment use create_proc_read_entry() with
a NULL accessor and generate a compile-time warning.
Signed-off-by: David Howells <dhowells@redhat.com>

Adjust printk in create_proc_mconsole() to reflect it is now using
proc_create() not create_proc_mconsole().
Signed-off-by: David Howells <dhowells@redhat.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

use proc_create_data() rather than set ->data after the file has
been created
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>