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: Sat, 13 Mar 2010 10:41:28 +0100 From: Florian Mickler <florian@...kler.org> To: Dmitry Torokhov <dmitry.torokhov@...il.com> Cc: "John W. Linville" <linville@...driver.com>, Marcel Holtmann <marcel@...tmann.org>, Henrique de Moraes Holschuh <hmh@....eng.br>, Johannes Berg <johannes@...solutions.net>, linux-wireless@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>, Alan Jenkins <alan-jenkins@...fmail.co.uk>, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, Valdis.Kletnieks@...edu Subject: Re: [PATCH 2/2] enhance sysfs rfkill interface On Fri, 12 Mar 2010 14:48:28 -0800 Dmitry Torokhov <dmitry.torokhov@...il.com> wrote: > On Fri, Mar 12, 2010 at 11:39:25PM +0100, Florian Mickler wrote: > > On Fri, 12 Mar 2010 13:20:26 -0800 > > Dmitry Torokhov <dmitry.torokhov@...il.com> wrote: > > > > > On Fri, Mar 12, 2010 at 09:57:43PM +0100, Florian Mickler wrote: > > > > On Fri, 12 Mar 2010 10:22:09 -0800 > > > > Dmitry Torokhov <dmitry.torokhov@...il.com> wrote: > > > > > > > > > On Fri, Mar 12, 2010 at 07:03:08PM +0100, florian@...kler.org wrote: > > > > > > > > > > > > +static ssize_t rfkill_hard_show(struct device *dev, > > > > > > + struct device_attribute *attr, > > > > > > + char *buf) > > > > > > +{ > > > > > > + struct rfkill *rfkill = to_rfkill(dev); > > > > > > + unsigned long flags; > > > > > > + u32 state; > > > > > > + > > > > > > + spin_lock_irqsave(&rfkill->lock, flags); > > > > > > + state = rfkill->state; > > > > > > + spin_unlock_irqrestore(&rfkill->lock, flags); > > > > > > > > > > Why exactly is this lock needed? > > > > > > > > The rfkill state is updated from multiple contexts... Am I overlooking > > > > smth obvious here? > > > > > > > > > > You are not updating but reading... Are you concerned about seeing > > > a partial write to u32? It does not happen. > > > > > Hm.. You shure? On every arch that supports wireless drivers? > > > > I've just copied that code from the old sysfs state-file handler. > > So I assumed that reading partial updated state can happen... Also I > > just searched a little but did not find anything, cause i didn't know > > where to look. Who garantees this? Is it a gcc thing? > > > > None of the arches would do byte-by-byte writes to a u32, they'd write > dword at once. Also, even if they could, you are interested in a single > flag (bit). You do realize that once you leave spinlock whatever you > fetched is stale data and may not be trusted? On Fri, 12 Mar 2010 18:48:19 -0500 Valdis.Kletnieks@...edu wrote: > If a u32 load or store from memory isn't atomic, the Linux kernel is screwed > anyhow. Hint - imagine if every 32-bit reference had to be treated the way > we currently treat 64-bit references on a 32-bit system. i presume, there is no way any digital device could write _one bit_ partial :) so this _may_ actually be safe *g* how about the write in the _store() function? there we read,update and write back the whole 32 bit which then potentially overwrites some other flag concurrently set by an driver interrupt on another cpu? i think the lock there is needed. cheers, Flo -- 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