Re: Respawn crashed PUFFS filesystems?

2012-02-11 Thread David Holland
On Sun, Feb 12, 2012 at 07:12:25AM +0100, Emmanuel Dreyfus wrote: > One of the benefits of userland filesystems is that a bug in a > filesystem will just crash the filesystem, not the whole kernel. But a > crashed filesystem causes an unmount, and leaves the system non fully > functionnal. >

Re: Respawn crashed PUFFS filesystems?

2012-02-11 Thread Mouse
>> Is there any way it could be set as an option at mount time? > The problem is that mount(8) passes the options verbatim to > /sbin/mount_xxx, which is supposed to start the xxx filesystem. The > filesystem will parse the options on its own before passing > appropriate flags to mount(2). We have

Re: Respawn crashed PUFFS filesystems?

2012-02-11 Thread Emmanuel Dreyfus
Mouse wrote: > > Of course the feature would be broken in some cases, but we could > > make the thing optional using a vfs.puffs.respawn sysctl, which would > > contain a colon-separated mount points subjected to respawn. > > What happens if a mount point contains a colon? Then you have serious

Re: Respawn crashed PUFFS filesystems?

2012-02-11 Thread Matthew Mondor
On Sun, 12 Feb 2012 01:02:38 -0500 (EST) Mouse wrote: > > Of course the feature would be broken in some cases, but we could > > make the thing optional using a vfs.puffs.respawn sysctl, which would > > contain a colon-separated mount points subjected to respawn. > > What happens if a mount point

Re: Respawn crashed PUFFS filesystems?

2012-02-11 Thread Mouse
> Of course the feature would be broken in some cases, but we could > make the thing optional using a vfs.puffs.respawn sysctl, which would > contain a colon-separated mount points subjected to respawn. What happens if a mount point contains a colon? More to the point, I think this puts the infor

Respawn crashed PUFFS filesystems?

2012-02-11 Thread Emmanuel Dreyfus
One of the benefits of userland filesystems is that a bug in a filesystem will just crash the filesystem, not the whole kernel. But a crashed filesystem causes an unmount, and leaves the system non fully functionnal. I thought that we could respawn a crashed userland filesystem, lookup all active

Re: O_NOACCESS?

2012-02-11 Thread Mouse
>> fexecve() makes a lot of sense too. So would an flink(), [...] > We'd want to be a bit careful about adding these as there are > permission checks that are implied by specifying a path which you do > not get with the f* calls mentioned. Not per se, but the fd on the directory proxies for them,

Re: O_NOACCESS?

2012-02-11 Thread Roland C. Dowdeswell
On Sat, Feb 11, 2012 at 07:12:32PM -0500, Mouse wrote: > > > (Note that while there may be no use for #2 in userlevel code, unless > > perhaps if we add an fexecve() call, having it would be convenient in > > the kernel.) > > fexecve() makes a lot of sense too. So would an flink(), and indeed f*

Re: O_NOACCESS?

2012-02-11 Thread Mouse
> There are, however, at least three possible things there's currently > no open flags for. > (1) search/lookup on a directory, as described; > (2) execute on an (executable) regular file; > (3) really nothing at all. > #1 and #2 could be legitimately combined (as the --x permission > setting is

Re: O_NOACCESS?

2012-02-11 Thread Mouse
> There is no problem. O_NOACCESS would be 3. When converted from O_* > to F* it becomes 0. And that is indeed what I did. FFLAGS() and OFLAGS() become more complex than just adding and subtracting 1, but that's not difficult to deal with. (If anyone's curious exactly what I did, look at the t

Re: O_NOACCESS?

2012-02-11 Thread David Holland
On Sat, Feb 11, 2012 at 05:02:27PM -0500, Steven Bellovin wrote: > The fine details (per later messages in the thread) are very important > and do need to be resolved. That said, there's a strong philosophical > case for something like this (but perhaps not exactly this) to exist, > in that we

Re: O_NOACCESS?

2012-02-11 Thread David Holland
On Sat, Feb 11, 2012 at 10:27:42PM +, David Laight wrote: > On Sat, Feb 11, 2012 at 02:04:23AM -0500, Mouse wrote: > > I find myself wanting something I'm tentatively calling O_NOACCESS, > > which is basically "open for neither read nor write". (I want this > > mostly so I can open a --x d

Re: O_NOACCESS?

2012-02-11 Thread David Laight
On Sat, Feb 11, 2012 at 02:04:23AM -0500, Mouse wrote: > I find myself wanting something I'm tentatively calling O_NOACCESS, > which is basically "open for neither read nor write". (I want this > mostly so I can open a --x directory for fchdir() purposes.) > > Looking at sys_open(), I see that on

Re: O_NOACCESS?

2012-02-11 Thread Steven Bellovin
On Feb 11, 2012, at 2:04 AM, Mouse wrote: > I find myself wanting something I'm tentatively calling O_NOACCESS, > which is basically "open for neither read nor write". (I want this > mostly so I can open a --x directory for fchdir() purposes.) > > Looking at sys_open(), I see that one of the fi

Problem with i2c bus rescan - iic_search()

2012-02-11 Thread Paul Goyette
While working on another problem, I've noticed that rescanning an i2c bus (such as when loading an i2c device's driver module) cause an awful lot of redundant calls to driver *_match() funtion. In particular, when the spdmem(4) driver with its 8 possible attachments is loaded, each possible spd

Re: O_NOACCESS?

2012-02-11 Thread Mouse
> Right. You add O_DIRECTORY to that check. Ah, I misunderstood. My apologies. > if ((flags & (FREAD|FWRITE)) == 0 && (flags & O_DIRECTORY) == 0) > return EINVAL; > if ((flags & O_DIRECTORY) != 0 && (flags & (FREAD|FWRITE)) != 0) > return EINVAL; Actually, what I have now skips the

Re: O_NOACCESS?

2012-02-11 Thread Matt Thomas
On Feb 11, 2012, at 12:31 AM, Mouse wrote: Why not use O_DIRECTORY (which is part of -current) and add that to flags? >>> Backporting that might be a better alternative. What are its >>> semantics? >> It means the open will only succeed is the file is a directory. > > Worth having, bu

Re: O_NOACCESS?

2012-02-11 Thread Mouse
>>> Why not use O_DIRECTORY (which is part of -current) and add that to >>> flags? >> Backporting that might be a better alternative. What are its >> semantics? > It means the open will only succeed is the file is a directory. Worth having, but not sufficient by itself, because it still requires

Re: O_NOACCESS?

2012-02-11 Thread Matt Thomas
On Feb 10, 2012, at 11:49 PM, Mouse wrote: >> Why not use O_DIRECTORY (which is part of -current) and add that to >> flags? > > Backporting that might be a better alternative. What are its > semantics? It means the open will only succeed is the file is a directory.