| 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
| ||
|
Date: Thu, 15 Feb 2007 21:53:50 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: Tim Cullen <timcullen2001@...oo.com> Cc: linux-kernel@...r.kernel.org Subject: Re: possible bug in page allocation mechanism On Thu, 15 Feb 2007 14:11:42 -0800 (PST) Tim Cullen <timcullen2001@...oo.com> wrote: > There appears to be a inconsistenancy with reference > counts on pages allocated with alloc_pages when order > is greater than zero. In buffered_rmqueue when order > != 0 then __rmqueue is called. This returns a page > pointer that is really a pointer to the first page in > a group of pages. Subsequently prep_new_page is called > on the first page of the group but not on any others. > This results in the first page having a reference > count of 1 while all other pages in the allocation > have a reference count of 0. I would think that all > pages in the same allocation should all have the same > reference count at the end of the allocation. > > I've looked at this in the 2.6.20, 2.6.19.1, and the > 2.6.17.7 kernels. They contain the same code in this > area. > That's as-designed. All page refcount manipulations on a higher-order page are supposed to be against the head pageframe. Also, we have the compound page logic in there to force code which tries to manipulate the refcount of a tail page to be redirected to the head page. - 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