linux-kernel - Re: 2.6.25-rc7-git2: Reported regressions from 2.6.24

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: <Pine.LNX.4.64.0803272002090.11979@schroedinger.engr.sgi.com>
Date:	Thu, 27 Mar 2008 20:24:22 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Pawel Staszewski <pstaszewski@...com.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>
Subject: Re: 2.6.25-rc7-git2: Reported regressions from 2.6.24

On Thu, 27 Mar 2008, Linus Torvalds wrote:

> 
> 
> On Thu, 27 Mar 2008, Rafael J. Wysocki wrote:
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=9412
> > Subject		: commit a878539ef994787c447a98c2e3ba0fe3dad984ec breaks boot on SB600 AHCI
> > Submitter	: Srihari Vijayaraghavan <sriharivijayaraghavan@...oo.com.au>
> > Date		: 2008-03-12 17:15 (16 days old)
> > Handled-By	: Jeff Garzik <jgarzik@...ox.com>
> > 		  Richard Zhao <richard.zhao@....com>
> 
> Fixed by 4cde32fc4b32e96a99063af3183acdfd54c563f0, methinks.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=9962
> > Subject		: mount: could not find filesystem
> > Submitter	: Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
> > Date		: 2008-02-12 14:34 (45 days old)
> > References	: http://lkml.org/lkml/2008/2/12/91
> > Handled-By	: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
> > 		  Yinghai Lu <yhlu.kernel@...il.com>
> 
> Needs more info. The original oops that opened it is fixed, but..
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=9976
> > Subject		: BUG: 2.6.25-rc1: iptables postrouting setup causes oops
> > Submitter	: Ben Nizette <bn@...sdigital.com>
> > Date		: 2008-02-12 12:46 (45 days old)
> > References	: http://lkml.org/lkml/2008/2/12/148
> > Handled-By	: Haavard Skinnemoen <hskinnemoen@...el.com>
> 
> This one seems gone (and was apparently AVR-only):
> 
> http://lkml.org/lkml/2008/2/13/607:
>   "What ever the problem is it isn't immediately apparent in latest git so
>    I guess we'll just have to keep our eyes peeled."
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=9978
> > Subject		: 2.6.25-rc1: volanoMark regression
> > Submitter	: Zhang, Yanmin <yanmin_zhang@...ux.intel.com>
> > Date		: 2008-02-13 10:30 (44 days old)
> > References	: http://lkml.org/lkml/2008/2/13/128
> > 		  http://lkml.org/lkml/2008/3/12/52
> > 		  http://lkml.org/lkml/2008/3/18/81
> > Handled-By	: Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
> > 		  Balbir Singh <balbir@...ux.vnet.ibm.com>
> 
> Hmm. It is a regression on one machine (2x quad-core stoakley), but not 
> another (4x quad-core tigerton).
> 
> Interestingly, the stoakley box numbers have apparently been all over the 
> map.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10318
> > Subject		: WARNING: at arch/x86/mm/highmem_32.c:43 kmap_atomic_prot+0x87/0x184()
> > Submitter	: Pawel Staszewski <pstaszewski@...com.pl>
> > Date		: 2008-03-25 02:50 (3 days old)
> 
> Andrew and seems to have debugged this down to a kzalloc(GFP_ATOMIC) or 
> similar.

Slab allocations can never use GFP_HIGHMEM. Slab allocators BUG 
if either of these bits are set (checks on the slowpaths):

#define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)

GFP flags are not masked/checked if either inline fallback to the page 
allocator occurs (SLUB for >4k allocs) or if an allocation is forwarded
to the page allocator (SLOB, SLUB). They are also not checked on the 
fastpaths.


AFAICT the check in kmap_atomic_prot is simply too strict.

void *kmap_atomic_prot(struct page *page, enum km_type type, pgprot_t 
prot)
{
        enum fixed_addresses idx;
        unsigned long vaddr;
        /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */

        debug_kmap_atomic_prot(type);

        pagefault_disable();

        if (!PageHighMem(page))
                return page_address(page);


The check for PageHighMem(page) needs to either come before the 
debug_kmap_atomic_prot() or kmap_atomic_prot should only be called for 
HIGHMEM allocations. Otherwise any get_zeroed_page() alloc from an 
interrupt context may cause a false positive here.

Seems to be a reoccurrence of something that I discussed with Andrew a 
while back.

http://marc.info/?t=118790336700011&r=1&w=2
--
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/