linux-kernel - Re: Re: [PATCH] mm: modify the method to search addr in unmapped

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

Date:   Sun, 24 Apr 2022 18:33:46 +0800
From:   "lipeifeng@...o.com" <lipeifeng@...o.com>
To:     akpm <akpm@...ux-foundation.org>
Cc:     peifeng55 <peifeng55@...il.com>, linux-mm <linux-mm@...ck.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Barry Song" <21cnbao@...il.com>,
        zhangshiming <zhangshiming@...o.com>,
        lipeifeng <lipeifeng@...o.corp-partner.google.com>
Subject: Re: Re: [PATCH] mm: modify the method to search addr in unmapped_area

>> Unfortunately this part of the code is undergoing a lot of change
>> lately.  How serious is this problem?  Please tell us how often the
>> problem is being observed, under what circumstances, etc.

> I have observed some problems in process-TIF_32BIT, such as Wechat
> and others Android APP.

> In the above processes which the single largest remaining free-addr-space
> is 12Mbytes in some case, we found that the processes wound fail to alloc
> a 12Mbytes(align 1M) in the old methods so that Out-of-Memory.

> The idea of this patch is the same as the following patch which is used for
> unmapped_area_topdown, as follows:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/mmap.c?id=5c6c46912cc0182fadd4b5f0eab029ccbbcc1ba3 

> Thank you very much indeed to ask such nice question and I wish I have given
> a clear reply. Pls let me know If there are any problems you found.

Hi Andrew Morton：

Pls help to review the patch and can it be merged into next-line?
Thanks very much.

lipeifeng@...o.com
 
From: lipeifeng@...o.com
Date: 2022-04-21 10:20
To: akpm
CC: peifeng55; linux-mm; linux-kernel; Barry Song; zhangshiming
Subject: Re: Re: [PATCH] mm: modify the method to search addr in unmapped_area
Hi Andrew Morton：

> Unfortunately this part of the code is undergoing a lot of change
> lately.  How serious is this problem?  Please tell us how often the
> problem is being observed, under what circumstances, etc.

I have observed some problems in process-TIF_32BIT, such as Wechat
and others Android APP.

In the above processes which the single largest remaining free-addr-space
is 12Mbytes in some case, we found that the processes wound fail to alloc
a 12Mbytes(align 1M) in the old methods so that Out-of-Memory.

The idea of this patch is the same as the following patch which is used for
unmapped_area_topdown, as follows:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/mmap.c?id=5c6c46912cc0182fadd4b5f0eab029ccbbcc1ba3 

Thank you very much indeed to ask such nice question and I wish I have given
a clear reply. Pls let me know If there are any problems you found.

lipeifeng@...o.com
 
From: Andrew Morton
Date: 2022-04-21 05:57
To: lipeifeng
CC: peifeng55; linux-mm; linux-kernel; 21cnbao; zhangshiming
Subject: Re: [PATCH] mm: modify the method to search addr in unmapped_area
On Wed, 20 Apr 2022 16:40:39 +0800 lipeifeng@...o.com wrote:
 
> The old method will firstly find the space in len(info->length
> + info->align_mask), and get address at the desired alignment.
>
> Sometime, addr  would be failed if there are enough
> addr space in kernel by above method, e.g., you can't get a
> addr sized in 1Mbytes, align_mask 1Mbytes successfully although
> there are still (2M-1)bytes space in kernel.
>
> This patch would fix thr problem above by the new method: find the
> space in info->length and judge if at the desired info->align_mask
> at the same time.
>
> Do a simple test in TIF_32BIT with unmapped_area:
> - Try to take addr (size:1M align:2M) until allocation fails;
> - Try to take addr (size:1M align:1M) and account how to space can
> be alloced successfully.
>
> Before optimization: alloced 0     bytes.
> After  optimization: alloced 1.9+G bytes.
 
Thanks.
 
Unfortunately this part of the code is undergoing a lot of change
lately.  How serious is this problem?  Please tell us how often the
problem is being observed, under what circumstances, etc.