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, 11 Jul 2019 18:20:02 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: "chenjianhong (A)" <chenjianhong2@...wei.com> Cc: Michel Lespinasse <walken@...gle.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "mhocko@...e.com" <mhocko@...e.com>, "Vlastimil Babka" <vbabka@...e.cz>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Yang Shi <yang.shi@...ux.alibaba.com>, "jannh@...gle.com" <jannh@...gle.com>, "steve.capper@....com" <steve.capper@....com>, "tiny.windzz@...il.com" <tiny.windzz@...il.com>, LKML <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>, "stable@...r.kernel.org" <stable@...r.kernel.org>, "willy@...radead.org" <willy@...radead.org> Subject: Re: [PATCH] mm/mmap: fix the adjusted length error On Sat, 18 May 2019 07:05:07 +0000 "chenjianhong (A)" <chenjianhong2@...wei.com> wrote: > I explain my test code and the problem in detail. This problem is found in > 32-bit user process, because its virtual is limited, 3G or 4G. > > First, I explain the bug I found. Function unmapped_area and > unmapped_area_topdowns adjust search length to account for worst > case alignment overhead, the code is ' length = info->length + info->align_mask; '. > The variable info->length is the length we allocate and the variable > info->align_mask accounts for the alignment, because the gap_start or gap_end > value also should be an alignment address, but we can't know the alignment offset. > So in the current algorithm, it uses the max alignment offset, this value maybe zero > or other(0x1ff000 for shmat function). > Is it reasonable way? The required value is longer than what I allocate. > What's more, why for the first time I can allocate the memory successfully > Via shmat, but after releasing the memory via shmdt and I want to attach > again, it fails. This is not acceptable for many people. > > Second, I explain my test code. The code I have sent an email. The following is > the step. I don't think it's something unusual or unreasonable, because the virtual > memory space is enough, but the process can allocate from it. And we can't pass > explicit addresses to function mmap or shmat, the address is getting from the left > vma gap. > 1, we allocat large virtual memory; > 2, we allocate hugepage memory via shmat, and release one > of the hugepage memory block; > 3, we allocate hugepage memory by shmat again, this will fail. How significant is this problem in real-world use cases? How much trouble is it causing? > Third, I want to introduce my change in the current algorithm. I don't change the > current algorithm. Also, I think there maybe a better way to fix this error. Nowadays, > I can just adjust the gap_start value. Have you looked further into this? Michel is concerned about the performance cost of the current solution.
Powered by blists - more mailing lists