linux-kernel - Re: [PATCH] rtc: remove BKL for ioctl()

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: <200806251604.49995.david-b@pacbell.net>
Date:	Wed, 25 Jun 2008 16:04:49 -0700
From:	David Brownell <david-b@...bell.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Jonathan Corbet <corbet@....net>,
	lkml <linux-kernel@...r.kernel.org>, rtc-linux@...glegroups.com
Subject: Re: [PATCH] rtc: remove BKL for ioctl()

On Wednesday 25 June 2008, Alan Cox wrote:
> > 
> > Shouldn't that be -EINTR?
> 
> For an ioctl case which should never be blocking for long periods it
> shouldn't be _interruptible in the first place, that will just introduce
> bizarre and weird bugs in application code.
> 
> If there are slow ops they should drop and retake the lock.

What's a "long period"?

RTCs that connect using I2C or SPI will need to queue for access to
that particular serial bus, and then there are transfer costs.
The busses are frequently, but of course not always, idle.  For I2C
at 100 KHz, RTC transfers might take a millisecond or so.

I'd be tempted to say those are all quick enough that the ops don't
need to be interruptible.

- Dave
--
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/