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]
Date:	Sun, 28 Oct 2007 00:24:49 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] irq_flags_t: intro and core annotations

On Thu, Oct 25, 2007 at 05:40:03PM +0200, Jan Engelhardt wrote:
> On Oct 21 2007, Alexey Dobriyan wrote:
> >
> >One of type of bugs steadily being fought is the following one:
> >
> >	unsigned int flags;
> >	spin_lock_irqsave(&lock, flags);
> >
> >where "flags" should be "unsigned long". Here is far from complete list 
> >of commits fixing such bugs:
> >
> 
> How about making spin_lock_irqsave actually take a pointer to flags? 

How would you do it without flag day?

> (Which would be the logical choice if it were a function and not a 
> macro...) That would flag up all violations ("without cast to different 
> pointer" or so) while usually not breaking compilation.
> 
> Of course, irq_flags_t is probably the best long-term solution if one 
> wants to hide a struct. (Even then perhaps, use a pointer instead?)

IIRC, Christoph mentioned:

	irq_flags_t flags;

	flags = spin_lock_irqXXX(&lock);
	spin_unlock_irqYYY(&lock, flags);

where XXX and YYY are still to be found good names :^) It's also a solution
without flag day and with more sane lock part -- "how flags are modified
if they are passed by value?"

I start to like this proposal but I can't come up with good names.
-
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