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

Date:	Sun, 20 Feb 2011 17:53:16 +0100
From:	Javier Martinez Canillas <martinez.javier@...il.com>
To:	Greg Kroah-Hartman <gregkh@...e.de>
Cc:	Bill Pemberton <wfp5p@...ginia.edu>,
	Arnaud Patard <apatard@...driva.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
	kernel-janitors@...r.kernel.org
Subject: [PATCH 0/2] Staging: xgifb: Remove CRIT[FLAGS | BEGIN | END] defines nd conditional spinlock compilation logic

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.

This patchset first replaces all the defines used with explicit definitions,
then removes all the defines and the spinlocks optional compilation logic.

The patchset is composed of the following patches:

[PATCH 1/2] Staging: xgifb: Remove CRIT[FLAGS | BEGIN | END] defines usage
[PATCH 2/2] Staging: xgifb: Removes CRIT[FLAGS | BEGIN | END] defines and conditional spinlock compilation logic
--
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/