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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Jan 2009 17:35:11 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Mike Travis <travis@....com>, Ingo Molnar <mingo@...hat.com>,
	Dave Jones <davej@...hat.com>, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.

On Monday 26 January 2009 17:31:30 Andrew Morton wrote:
> On Mon, 26 Jan 2009 17:11:43 +1030 Rusty Russell <rusty@...tcorp.com.au> wrote:
> 
> > On Saturday 24 January 2009 18:45:37 Andrew Morton wrote:
> > > Pity the poor reader who comes along trying to work out why this exists.
> 
> (chirp, chirp)

I disagree.  It's simple; we create a workqueue and we use it.  There's no
confusion here.

> > None of these options are appealing...
> 
> Can we try harder please?  10 screenfuls of kernel threads in the ps
> output is just irritating.
> 
> How about banning the use of work_on_cpu() from schedule_work()
> handlers and then fixing that driver somehow?

Again, that's how we got here in the first place.  I didn't realize the
twisty path by which the acpi cpufreq code could be called.  And there
may well be others.  So I want work_on_cpu to be completely generic.

Using the existing infrastructure seemed like the right thing.

But since you asked nicely, I'll come up with something cleverer.  It'll
take some serious testing though.

> What _is_ the bug anyway?

There is no "bug".  See the commit message.

> The only description we were given was
> 
>   Impact: remove potential clashes with generic kevent workqueue
> 
>   Annoyingly, some places we want to use work_on_cpu are already in
>   workqueues.  As per Ingo's suggestion, we create a different
>   workqueue for work_on_cpu.
> 
> which didn't bother telling anyone squat.

Well, it could have referred to the currently-known case:
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c should be using work_on_cpu,
but we reverted the change because of this problem.

But it's a general comment about fixing a general issue.  The currently
known case is not directly relevent; that it can happen and it's restricting
the use of this otherwise-general API is.

> When was this bug added?  Was it added into that driver or was it due
> to infrastructural changes?

I'm not hiding a bug from you.  Really.

A little confused at all this vitriol,
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/

Powered by blists - more mailing lists