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]
Message-Id: <20080501184905.b7e0dade.akpm@linux-foundation.org>
Date:	Thu, 1 May 2008 18:49:05 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, peterz@...radead.org,
	hch@...radead.org, adobriyan@...il.com, bunk@...nel.org
Subject: Re: [PATCH] add typecheck on irqsave and friends for correct flags

On Thu, 1 May 2008 21:16:48 -0400 (EDT) Steven Rostedt <rostedt@...dmis.org> wrote:

> 
> On Thu, 1 May 2008, Andrew Morton wrote:
> > > This patch adds a typecheck inside the irqsave and restore functions
> > > to flag these cases.
> >
> > hm, not exactly a thing of beauty, but it could have been worse.
> 
> Beauty is in the eye of the beholder.
>  (a mother always thinks their kid is beautiful ;-).

As long as your patch doesn't soil its diaper.

> >
> >
> > If we had implemeted these things properly, as
> >
> > 	unsigned long spin_lock_irqsave(spinlock_t *lock);
> 
> Then we would have been forced to do the
> 
> 	irqflags_t spin_lock_irqsave(spinlock_t *lock);
> 
> trick. Which would probably be the better long term solution, but the
> biggest PITA for you in the short term.

We should have done that from day one.  If there's an architecture out
there which cannot fit its interrupt state into its unsigned long (hard to
believe) then it'll need to pull stunts with cookies and lookups or
something.  And on 64-bit architectures we're using 4 more bytes of local
storage than is needed.

But I don't think we've had enough problems with this particular issue to
justify a kernel-wide edit like that.  And this patch should settle the
issue.


--
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