linux-kernel - [RFC][PATCH 0/9] File descriptor hot-unplug support

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-next>] [day] [month] [year] [list]

Date:	Sat, 11 Apr 2009 05:01:29 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	<linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>,
	<linux-mm@...ck.org>, <linux-fsdevel@...r.kernel.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	Hugh Dickins <hugh@...itas.com>, Tejun Heo <tj@...nel.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: [RFC][PATCH 0/9] File descriptor hot-unplug support

A couple of weeks ago I found myself looking at the uio, seeing that
it does not support pci hot-unplug, and thinking "Great yet another
implementation of hotunplug logic that needs to be added".

I decided to see what it would take to add a generic implementation of
the code we have for supporting hot unplugging devices in sysfs, proc,
sysctl, tty_io, and now almost in the tun driver.

Not long after I touched the tun driver and made it safe to delete the
network device while still holding it's file descriptor open I someone
else touch the code adding a different feature and my careful work
went up in flames.  Which brought home another point at the best of it
this is ultimately complex tricky code that subsystems should not need
to worry about.

What makes this even more interesting is that in the presence of pci
hot-unplug it looks like most subsystems and most devices will have to
deal with the issue one way or another.

This infrastructure could also be used to implement sys_revoke and
when I could not think of a better name I have drawn on that.

The following changes draw on and generalize the work in tty_io sysfs,
proc, and sysctl and move it into the vfs level.  Where the basic
primitives are running faster, and the solution more general.

The work is not complete.  I have only fully converted proc.  And
there are more places in the vfs that need to be touched.  But it is
close enough the code works in practice and all of the core challenges
should have been solved, and the design should be clear.

 Documentation/filesystems/vfs.txt |    4 +
 drivers/char/pty.c                |    2 +-
 drivers/char/tty_io.c             |    2 +-
 fs/Makefile                       |    2 +-
 fs/compat.c                       |   31 +++-
 fs/fcntl.c                        |   32 +++--
 fs/file_table.c                   |  189 ++++++++++++++++++---
 fs/inode.c                        |    1 +
 fs/ioctl.c                        |   39 +++--
 fs/locks.c                        |   81 +++++++--
 fs/open.c                         |   32 +++-
 fs/proc/generic.c                 |  100 ++++--------
 fs/proc/inode.c                   |  339 +------------------------------------
 fs/proc/internal.h                |    2 +
 fs/proc/root.c                    |    2 +-
 fs/read_write.c                   |  143 ++++++++++++----
 fs/readdir.c                      |   14 ++-
 fs/revoked_file.c                 |  181 ++++++++++++++++++++
 fs/select.c                       |   17 ++-
 fs/super.c                        |   49 +++---
 fs/sysfs/bin.c                    |  193 +---------------------
 include/linux/fs.h                |   31 +++-
 include/linux/mm.h                |    3 +
 include/linux/proc_fs.h           |    4 -
 mm/memory.c                       |   96 +++++++++++
 25 files changed, 841 insertions(+), 748 deletions(-)

Eric

--
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/