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>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702161544540.20402@CPE00045a9c397f-CM001225dbafb6>
Date:	Fri, 16 Feb 2007 15:55:24 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: removing all "R/W" content from all semaphore.h files?


(can anyone comment on whether i'm thinking about this clearly?)

  as i read it, there is no need for *any* of the semaphore.h files to
include "<linux/rwsem.h>" anymore, since R/W sems now have their own
header file <linux/rwsem.h>.  so i recently submitted a patch to
delete all those inclusions from all semaphore.h files.  IMHO, that's
a fairly safe and reasonable change -- anyone who specifically wants a
R/W semaphore should be including the appropriate header file for it
and not be picking up that definition thru semaphore.h.

  however, some of those semaphore.h files also include the macro
definition:

  #define RW_LOCK_BIAS             0x01000000

that *also* strikes me as inappropriate content for generic
semaphore.h files.  in fact, there's a fascinating variety of header
files that define that macro identically:

$ grep -rl "#define RW_LOCK_BIAS" *
include/asm-frv/semaphore.h
include/asm-arm26/locks.h
include/asm-m68knommu/semaphore.h
include/asm-i386/rwlock.h
include/asm-sh/spinlock_types.h
include/asm-arm/locks.h
include/asm-m32r/spinlock_types.h
include/asm-m68k/semaphore.h
include/asm-h8300/semaphore.h
include/asm-x86_64/rwlock.h
include/asm-cris/arch-v32/spinlock.h
include/asm-cris/semaphore.h

  so, where is the proper place for that macro definition?
semaphore.h?  locks.h?  rwlock.h?  spinlock.h?  spinlock-types.h?
the fact that that macro is defined in such differing locations
*can't* be a good thing.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ