linux-kernel - Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

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:	Mon, 7 May 2007 23:03:42 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Simon Arlott <simon@...e.lp0.eu>, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...e.de>
Subject: Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)

On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III <wli@...omorphy.com> wrote:
>> I think Andi's handling the mergework on those patches, but I'll check
>> in to see if I should rediff vs. -mm or what if you want them.
>> Andi, what's the verdict on those stack patches?

On Mon, May 07, 2007 at 10:37:38PM -0700, Andrew Morton wrote:
> Whoa. The verdict is usually "don't use so much stack".
> Do we know what has gone wrong here?
> Last week Jens said he was picking up the ancient
> md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't
> seem to have done so yet.
> XFS is frequently implicated.

Well, the culmination of those patches is a patch to use vmallocspace
to establish guard pages for stacks so overflows are immediately trapped
and the potential for silent corruption greatly reduced. That would be
where I suspect it's most relevant, as that's the focal point of the
series. The bit about unconditional IRQ stacks arose as part of review.

It started life as a set of patches intended to help with debugging
stack overflows, which is how the only tangentially-related unconditional
IRQ stacks came about: originally they were optional as a debug option
for differential diagnosis of interrupt-time overflows. For mainline, hch
suggested that they should rather be made unconditional.

The third part of the series that survived review was dynamic boot-time
allocation of IRQ stacks, which was originally motivated by the need
for indirection when remapping IRQ stacks into vmallocspace, but also
served the purpose of mitigating space overhead when using IRQ stacks
because cpu_possible_map is not set up as it should be to avoid the
allocation via per_cpu array variables' dynamic boot-time allocation
on i386 and (AFAIK) x86-64.

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