[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1MZSQZ-0002as-FA@pomaz-ex.szeredi.hu>
Date: Fri, 07 Aug 2009 18:36:23 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: eparis@...hat.com
CC: a.p.zijlstra@...llo.nl, tvrtko.ursulin@...hos.com,
douglas.leeder@...hos.com, pavel@....cz,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
malware-list@...sg.printk.net, Valdis.Kletnieks@...edu,
greg@...ah.com, jcm@...hat.com, tytso@....edu, arjan@...radead.org,
david@...g.hm, jengelh@...ozas.de, aviro@...hat.com,
mrkafk@...il.com, alexl@...hat.com, hch@...radead.org,
alan@...rguk.ukuu.org.uk, mmorley@....in
Subject: Re: fanotify - overall design before I start sending patches
On Thu, 06 Aug 2009, Eric Paris wrote:
> just work. The whole reason for the timeout is because I don't trust
> userspace not to get it wrong and I'd rather not lose my box because of
> it.
IMO this has nothing to do with userspace(*) and everything to do with
complexity. Virus scanning is complex and any such code, whether
runing in userspace or not, can easily screw up and freeze the system.
The way to solve that is not to implement hacks on the kernel
interface, but rather by separating the complex parts and implementing
a simple watchdog layer on top of that, that makes sure things don't
go wrong.
(*) We _must_ trust privileged userspace not to screw up. System
scripts can easily do much worse damage than freezing filesystem
operations. Just think "rm -rf /".
Thanks,
Miklos
--
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/
Powered by blists - more mailing lists