linux-kernel - Re: [PATCH 1/1] cpumask: smp_call_function

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, 20 Nov 2008 15:14:08 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	linux-kernel@...r.kernel.org, Mike Travis <travis@....com>,
	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>,
	schwidefsky@...ibm.com, heiko.carstens@...ibm.com, npiggin@...e.de,
	axboe@...nel.dk
Subject: Re: [PATCH 1/1] cpumask: smp_call_function_many()

On Thursday 20 November 2008 13:51:49 Nick Piggin wrote:
> I don't like changing of this whole smp_call_function_many scheme
> with no justification or even hint of it in the changelog.

Hi Nick,

Hmm, it said "if allocation fails we fallback to smp_call_function_single
rather than using the baroque quiescing code."

More words would have been far less polite :)

> Of course it is obvious that smp_call_function_mask can be implemented
> with multiple call singles. But some architectures that can do
> broadcast IPIs (or otherwise a little extra work eg. in programming
> the interrupt controller) will lose here.
>
> Also the locking and cacheline behaviour is probably actually worse.

Dude, we've failed kmalloc.  To paraphrase Monty Python, the parrot is fucked.   
By this stage the disks are churning, the keyboard isn't responding and the 
OOM killer is killing the mission-critical database and other vital apps.  
Everything else is failing on random syscalls like unlink().  Admins wondering 
how long it'll take to fsck if they just hit the big red switch now.

OK, maybe it's not that bad, but worrying about cacheline behaviour?  I'd 
worry about how recently that failure path has been tested.

I can prepare a separate patch which just changes this over, rather than doing 
it as part of the smp_call_function_many() conversion, but I couldn't stomach 
touching that quiescing code :(

Rusty.
--
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/