David Howells [Thu, 4 Apr 2013 15:49:26 +0000 (16:49 +0100)]
wlags49_h2: Don't use create_proc_entry()
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>
David Howells [Thu, 4 Apr 2013 15:44:51 +0000 (16:44 +0100)]
nubus: Don't use create_proc_entry()
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>
Al Viro [Sun, 31 Mar 2013 22:16:14 +0000 (18:16 -0400)]
procfs: new helper - PDE_DATA(inode)
The only part of proc_dir_entry the code outside of fs/proc
really cares about is PDE(inode)->data. Provide a helper
for that; static inline for now, eventually will be moved
to fs/proc, along with the knowledge of struct proc_dir_entry
layout.
Al Viro [Sun, 31 Mar 2013 17:50:52 +0000 (13:50 -0400)]
scsi_proc: make proc_scsi_host_open() preallocate a bigger buffer
Some of the ->show_info() instances really spew a lot; it's not a problem
wrt correctness (seq_read() will grow buffer and call the sucker again),
but in this case it makes sense to start with a somewhat bigger one -
they often do exceed one page worth of output.
Al Viro [Sun, 31 Mar 2013 17:43:23 +0000 (13:43 -0400)]
new helper: single_open_size()
Same as single_open(), but preallocates the buffer of given size.
Doesn't make any sense for sizes up to PAGE_SIZE and doesn't make
sense if output of show() exceeds PAGE_SIZE only rarely - seq_read()
will take care of growing the buffer and redoing show(). If you
_know_ that it will be large, it might make more sense to look into
saner iterator, rather than go with single-shot one. If that's
impossible, single_open_size() might be for you.
Again, don't use that without a good reason; occasionally that's really
the best way to go, but very often there are better solutions.
Al Viro [Sun, 31 Mar 2013 03:58:05 +0000 (23:58 -0400)]
scsi: saner replacements for ->proc_info()
It's still an obsolete interface; don't introduce those in new drivers.
However, it's saner than the ->proc_info() and commits after this one
will convert the existing ->proc_info() users to it.
The read side is ->show_info(seq_file *, struct Scsi_Host *); use
seq_... for generating contents.
The write side is ->write_info(struct Scsi_Host *, char *, int).
Again, this is driven by procfs needs; we are going to kill ->write_proc()
and ->read_proc() and this is the main obstacle to burying that piece of
shit.
Al Viro [Fri, 5 Apr 2013 17:42:42 +0000 (13:42 -0400)]
silicom: bury bp_proc.c
It's a seriously rotten copy of parts of bp_mod.c; had been
ifdefed out all along, lacks a bunch of declarations that would
be needed if ifdef had been removed, all stuff in it is duplicated
in bp_mod.c anyway...
Al Viro [Sat, 30 Mar 2013 00:39:17 +0000 (20:39 -0400)]
dgrp procfs fixes, part 1
proc_create() has shat upon fops argument when mode is S_IFDIR.
Good thing, too, since fops passed to it is completely useless
for any directory. Just use proc_mkdir(), damnit.
Sean MacLennan [Tue, 9 Apr 2013 01:18:06 +0000 (21:18 -0400)]
The rtl8192e procfs-based debug interface seems very broken
The procfs debug code in rtl_debug.c is, ironically, very buggy: it lacks proper locking.
Since the most useful part of the code (the stats) are available through more
standard APIs, I think it is best to just delete the whole mess.
Signed-off-by: Sean MacLennan <seanm@seanm.ca> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Al Viro [Thu, 21 Mar 2013 15:01:38 +0000 (11:01 -0400)]
get rid of pipe->inode
it's used only as a flag to distinguish normal pipes/FIFOs from the
internal per-task one used by file-to-file splice. And pipe->files
would work just as well for that purpose...
Al Viro [Thu, 21 Mar 2013 06:21:19 +0000 (02:21 -0400)]
pipe: take allocation and freeing of pipe_inode_info out of ->i_mutex
* new field - pipe->files; number of struct file over that pipe (all
sharing the same inode, of course); protected by inode->i_lock.
* pipe_release() decrements pipe->files, clears inode->i_pipe when
if the counter has reached 0 (all under ->i_lock) and, in that case,
frees pipe after having done pipe_unlock()
* fifo_open() starts with grabbing ->i_lock, and either bumps pipe->files
if ->i_pipe was non-NULL or allocates a new pipe (dropping and regaining
->i_lock) and rechecks ->i_pipe; if it's still NULL, inserts new pipe
there, otherwise bumps ->i_pipe->files and frees the one we'd allocated.
At that point we know that ->i_pipe is non-NULL and won't go away, so
we can do pipe_lock() on it and proceed as we used to. If we end up
failing, decrement pipe->files and if it reaches 0 clear ->i_pipe and
free the sucker after pipe_unlock().
Al Viro [Thu, 21 Mar 2013 06:16:30 +0000 (02:16 -0400)]
pipe: preparation to new locking rules
* use the fact that file_inode(file)->i_pipe doesn't change
while the file is opened - no locks needed to access that.
* switch to pipe_lock/pipe_unlock where it's easy to do
projects / mirror_ubuntu-jammy-kernel.git / log