linux-kernel - RFE: __alloc_pages() SLAB_PANIC & gfp

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

Date:	Fri, 22 Feb 2008 17:07:06 -0800 (GMT-08:00)
From:	erblichs <erblichs@...thlink.net>
To:	linux-kernel@...r.kernel.org
Cc:	erblichs@...thlink.net
Subject: RFE: __alloc_pages() SLAB_PANIC & gfp_mask

Group,


           Currrently I do not subscribe to this mail alias, so please
           keep the cc.

           Currently a few calls exist where WAIT is specified (
           (GFP_KERNEL)for the slab/slob allocators and also as an
           additional argument, SLAB_PANIC is checked against the
           return of the request for memory allocation. SLAB_PANIC
           is not passed to __alloc_pages() as part of the gfp_mask.

           If the memory allocation fails, and the flag is turned
           on, then a panic will ensure.. There is a very simple fix
           for this. The assumption is too basicly ASSERT a guarantee
           that memory failure in this case will not occur.

           The suggestion is to add the SLAB_PANIC arg to the gfp_mask,
           add it to the mask in the SLAB/SLUB callers,
           and have that checked within __alloc_pages 
           if a mem alloc failure is about to occur 
           after the check for no WAITers.

           If it is set, then force additional loops within the function.

           This would remove new cache creates from causing a panic when
           a low memory condition exists.

           Mitchell Erblich
--
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/