linux-kernel - Re: [git pull] core fixes

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: <200808122042.21482.nickpiggin@yahoo.com.au>
Date:	Tue, 12 Aug 2008 20:42:21 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [git pull] core fixes

On Tuesday 12 August 2008 19:25, Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@...oo.com.au> wrote:
> > On Tuesday 12 August 2008 16:13, Nick Piggin wrote:
> > > On Tuesday 12 August 2008 08:20, Ingo Molnar wrote:
> > > > Nick Piggin (1):
> > > >       generic-ipi: fix stack and rcu interaction bug in
> > > > smp_call_function_mask()
> > >
> > > I'm still not 100% sure that I have this patch right... I might have
> > > seen a lockup trace implicating the smp call function path... which
> > > may have been due to some other problem or a different bug in the
> > > new call function code, but if some more people can take a look at
> > > it before merging?
> >
> > OK indeed it did have a couple of bugs. Firstly, I wasn't freeing the
> > data properly in the alloc && wait case. Secondly, I wasn't resetting
> > CSD_FLAG_WAIT in the for each cpu loop (so only the first CPU would
> > wait).
> >
> > After those fixes, the patch boots and runs with the kmalloc commented
> > out (so it always executes the slowpath).
>
> thanks! I've applied the delta fix below to tip/core/urgent. In my
> testing the previous version didnt cause problems either because we
> seldom excercise this slowpath. (Jeremy had trouble reproducing the
> on-stack corruption even with targeted tests.)
>
> We'll soon start using the generic-ipi facilities for TLB flushes on x86
> and perhaps even reuse the IPI itself for the reschedule IPI - that
> should put it all under heavier scrutiny.

Well, hopefully. At the moment it is significantly slower though.
--
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/