linux-kernel - Re: fanotify - overall design before I start sending patches

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

Date:	Thu, 6 Aug 2009 13:24:38 +0200
From:	Pavel Machek <pavel@....cz>
To:	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Douglas Leeder <douglas.leeder@...hos.com>,
	Eric Paris <eparis@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"malware-list@...sg.printk.net" <malware-list@...sg.printk.net>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>,
	"greg@...ah.com" <greg@...ah.com>,
	"jcm@...hat.com" <jcm@...hat.com>, "tytso@....edu" <tytso@....edu>,
	"arjan@...radead.org" <arjan@...radead.org>,
	"david@...g.hm" <david@...g.hm>,
	"jengelh@...ozas.de" <jengelh@...ozas.de>,
	"aviro@...hat.com" <aviro@...hat.com>,
	"mrkafk@...il.com" <mrkafk@...il.com>,
	"alexl@...hat.com" <alexl@...hat.com>,
	"hch@...radead.org" <hch@...radead.org>,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>,
	"mmorley@....in" <mmorley@....in>
Subject: Re: fanotify - overall design before I start sending patches


> > > > Of course, I'm worried about failing to meet this on loaded
> > > > system. And the fact that I _have_ to worry about that means that
> > > > interface is ugly/broken.
> > >
> > > You mean that in 5 seconds, you won't have any point when you can tell
> > > the kernel, "I'm still working"?
> >
> > I have to agree with Pavel here, either you demand the monitor process
> > is RT/mlock and can respond in time, in which case the interface doesn't
> > need a 5 second timeout, or you cannot and you have a hole somewhere.
> >
> > Now having the kernel depend on any user task to guarantee process is of
> > course utterly insane too.
> >
> > Sounds like a bad place to be, and I'd rather not have it.
> >
> > If you really need the intermediate you might as well use a FUSE
> > filesystem, but I suspect there's plenty of problems there as well.
> 
> So you mount FUSE on top of everything if you want to have systemwide 
> monitoring and then you _again_ depend on _userspace_, no? By this logic 
> everything has to be in kernel. But even if it was, and the CPUs are so 
> overloaded that an userspace thread does not get to run at all for X seconds, 
> are kernel threads scheduled differently eg. with priority other than nice 
> levels?

Userspace app not running for 5 seconds != CPU not being available for
5 seconds. I'd worry about swap behaviour here.

> If the timeout is made configurable I think this is the best that can be done 
> here. I don't think the problem is so huge as you are presenting it.

It is ugly. FUSE is more elegant, being already in kernel. Of course,
if your userspace daemon fails, you are doomed, but...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/