linux-kernel - Re: [PATCH] add typecheck on irqsave and friends for correct flags

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