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
| ||
|
Date: Tue, 25 Jul 2006 20:03:14 -0400 From: Neil Horman <nhorman@...driver.com> To: "H. Peter Anvin" <hpa@...or.com> Cc: Dave Airlie <airlied@...il.com>, Segher Boessenkool <segher@...nel.crashing.org>, linux-kernel@...r.kernel.org, a.zummo@...ertech.it, jg@...edesktop.org Subject: Re: [PATCH] RTC: Add mmap method to rtc character driver On Tue, Jul 25, 2006 at 04:22:31PM -0700, H. Peter Anvin wrote: > Neil Horman wrote: > >>> > >>Quick hacks are frowned upon in the Linux universe. The kernel-user > >>space interface is supposed to be stable, and thus a hack like this has > >>to be maintained indefinitely. > >> > >>Putting temporary hacks like this in is not a good idea. > >> > >Only if you make the mental leap that this is a hack; its not. Its a new > >feature for a driver. mmap on device drivers is a well known and > >understood > >interface. There is nothing hackish about it. And there is no need for > >it to > >be temporary either. Why shouldn't the rtc driver be able to export a > >monotonic > >counter via the mmap interface? mmtimer does it already, as do many other > >drivers. Theres nothing unstable about this interface, and it need not be > >short > >lived. It can live in perpituity, and applications can choose to use it, > >or > >migrate away from it should something else more efficient become available > >(a > >gettimeofday vsyscall). More importantly, it can continue to be used in > >those > >situations where a vsyscall is not feasable, or simply maps to the nominal > >slow > >path kernel trap that one would find to heavy-weight to use in comparison > >to an > >mmaped page. > > > > The reason it is a hack is because you're hard-coding the fact that > you're taking a global, periodic interrupt. Yes, it can be dealt with > scheduler hacks in tickless case, but that seems really heavyweight. > I think that is an enormous overstatement. My patch most certainly does not export that fact. The only thing it provides to userspace is a regular monotonically increasing counter independent of any userspace scheduling. The implementation using a regular interrupt is completely hidden from userspace. The rtc driver itself is whats responsible for the global periodic interrupt. By your logic the driver itself is a hack. Honestly, this patch doesn't do any harm. Any application using it currently creates the same interrupt behavior that it would if it used the mmap interface. I think the only argument here is that applications using other timing facilities would create additional interrupts, but given that those applications are using interfaces with more overhead than this one, making the switch would be a net gain. Neil > -hpa - 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