linux-kernel - Re: [PATCH] RTC: Add mmap method to rtc character driver

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]

Message-ID: <20060726000314.GB5147@localhost.localdomain>
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/