Messages in this thread | | | Subject | Re: Important for fs devs: rcu-walk merged upstream | From | Miklos Szeredi <> | Date | Fri, 14 Jan 2011 10:38:44 +0100 |
| |
On Fri, 14 Jan 2011, Nick Piggin wrote: > On Fri, Jan 14, 2011 at 7:45 PM, Miklos Szeredi <miklos@szeredi.hu> wrote: > > On Fri, 14 Jan 2011, Nick Piggin wrote: > >> On Fri, Jan 14, 2011 at 3:18 AM, Miklos Szeredi <miklos@szeredi.hu> wrote: > > >> Surely you'd need some filtering anyway? I don't think any function > >> involving path lookup could sanely return -ECHILD. > > > > No, but not filtering doesn't normally hurt. And it's not quite > > trivial deciding what should be allowed and what shoudln't, and the > > filter would have to be updated for each addition of a new errno. So > > I'm not sure I want to go there. > > Well if you allow untrusted filesystems it is possible that > -ECHILD return will do something a bit silly. So it would be > good to filter it I guess.
What could it do (other than resulting in a silly error printout)?
If we'd want errno filtering for fuse how would you define "sane"?
> >> That said, it probably is a good idea to have a new errno. > > > > Yeah, that makes the fitering much easier. > > How so? Would -ECHILD ever be sane to return? I'm not > arguing against changing it but I just want to know what > the issue is there.
All kernel private errnos are >=512 (see <linux/errno.h), filtering out those is quite easy and clearly desirable.
Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |