linux-kernel - Re: Top kernel oopses/warnings for the week of May 30th 2008

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0806101318110.30867@blonde.site>
Date:	Tue, 10 Jun 2008 13:42:00 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <greg@...ah.com>, Jeff Garzik <jeff@...zik.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: Top kernel oopses/warnings for the week of May 30th 2008

On Mon, 9 Jun 2008, Ingo Molnar wrote:
> * Hugh Dickins <hugh@...itas.com> wrote:
> 
> > Veering off at a tangent away from the oops: I was rather sobered to 
> > see all those traces of execve using kmap, I thought we were avoiding 
> > kmap like BKL in common paths these days (though it is convenient for 
> > symlinks).  Would a patch something like that below, copying the 
> > filemap.c trick, be welcome?
> 
> FYI, i stuck this into -tip for testing and after some time i started 
> getting:

Thanks for giving it a try.

> [   12.368096] BUG: scheduling while atomic: ifup-eth/1820/0x10000001
> [   12.374144] Modules linked in:
> [   12.377175] Pid: 1820, comm: ifup-eth Not tainted 2.6.26-rc5-00029-ga252672-dirty #3490
> [   12.384031]  [<c0131a39>] __schedule_bug+0x59/0x60
> [   12.388031]  [<c06b1375>] schedule+0x465/0x8c0
> [   12.392031]  [<c013eecf>] ? update_process_times+0x4f/0x60
> [   12.396031]  [<c013b50f>] ? irq_exit+0x3f/0x70
> [   12.400451]  [<c012164b>] ? smp_apic_timer_interrupt+0x5b/0x90
> [   12.406248]  [<c0117038>] ? apic_timer_interrupt+0x28/0x30
> [   12.411702]  [<c0131a58>] __cond_resched+0x18/0x30
> [   12.416466]  [<c06b1838>] _cond_resched+0x28/0x30
> [   12.421141]  [<c03720bb>] strnlen_user+0x2b/0x60
> [   12.425728]  [<c018dd53>] copy_strings+0x63/0x210
> [   12.430403]  [<c018f986>] do_execve+0x176/0x200
> [   12.434903]  [<c0372007>] ? strncpy_from_user+0x37/0x60
> [   12.440031]  [<c0114ade>] sys_execve+0x2e/0x60
> [   12.444447]  [<c01165ae>] sysenter_past_esp+0x6a/0x90
> [   12.449469]  =======================
> [   12.736676] eth1: link down
> [   12.736919] ADDRCONF(NETDEV_UP): eth1: link is not ready
> 
> it would occur about every 10 bootups with the same config. Bisection 
> led me to your patch.

Right, that would be with CONFIG_PREEMPT_VOLUNTARY.  Or in my case
with CONFIG_DEBUG_SPINLOCK_SLEEP, strnlen_user's might_sleep gives
BUG: sleeping function called from invalid context...

At first I thought it was just falling foul of our zeal for might_sleep.
But no, the warning is correct: the get_user(str) and strnlen_user(str)
can perfectly well fault, but my suggested patch lets them be called
with a kmap_atomic outstanding.

I doubt it would be cost-effective to kunmap_atomic for each little
string there.  I don't see a quick and effective way to fix it up.
I don't have the patience to go about adding get_user_inatomic and
strnlen_user_inatomic, there's more urgent things to be doing.

It would be nice to use a per-process kmap; or use an efficient
one-page mapping in the exec'ers userspace; or maybe just having
a kunmap_and_flush would help (to slow the cycling around pkmap
page table), though it would still involve the global spinlock.

Sorry, no quick and effective fix: please just drop the patch.

Thanks,
Hugh
--
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/