linux-kernel - RE: [PATCH 0/2] Staging: xgifb: Remove CRIT[FLAGS | BEGIN | END] defines nd conditional spinlock compilation logic

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] [day] [month] [year] [list]

Message-ID: <CA1B555B4D79E3448D96A7C9847C7D98027F2A@008-AM1MPN1-032.mgdnok.nokia.com>
Date:	Sun, 20 Feb 2011 19:36:18 +0000
From:	<aaro.koskinen@...ia.com>
To:	<martinez.javier@...il.com>, <gregkh@...e.de>
CC:	<wfp5p@...ginia.edu>, <apatard@...driva.com>,
	<randy.dunlap@...cle.com>, <devel@...verdev.osuosl.org>,
	<linux-kernel@...r.kernel.org>, <kernel-janitors@...r.kernel.org>
Subject: RE: [PATCH 0/2] Staging: xgifb: Remove CRIT[FLAGS | BEGIN | END]
 defines nd conditional spinlock compilation logic

Hi,

From: Javier Martinez Canillas [martinez.javier@...il.com]:
> xgifb staging driver uses a set of defines that hides the synchronization
> mechanism used to access critical sections. Also, the use of spinlocks
> can be disabled in compile time.
>
> Since the spinlocks ABI only are used in contexts were critical section exists
> (UP with preemption enabled and SMP machines), I think we should always have
> the spinlocks enabled and let the spinlock ABI choose to include the spinlocks
> or not. In the other hand if the driver doesn't need locking at all, then
> maybe we should just delete the spinlock logic.

I think these should be just deleted. The acceleration functions are used by the framebuffer
layer which should take care of concurrent access. Or can you point out some real scenario
where the spinlocks are needed?

A.
--
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/