linux-kernel - Re: [PATCH] target/user: Add daynmic growing data area featuresupport

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]

Date:   Wed, 1 Mar 2017 18:53:23 +0800
From:   Xiubo Li <lixiubo@...s.chinamobile.com>
To:     Andy Grover <agrover@...hat.com>, nab@...ux-iscsi.org,
        mchristi@...hat.com, shli@...nel.org
Cc:     hch@....de, sheng@...ker.org, namei.unix@...il.com,
        bart.vanassche@...disk.com, linux-scsi@...r.kernel.org,
        target-devel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jianfei Hu <hujianfei@...s.chinamobile.com>
Subject: Re: [PATCH] target/user: Add daynmic growing data area featuresupport

>> For now we will increase the data area size to 1G, and the cmd area
>> size to 128M. The tcmu-runner should mmap() about (128M + 1G) when
>> running and the TCMU will dynamically grows the data area from 0 to
>> max 1G size.
> Cool. This is a good approach for an initial patch but this raises
> concerns about efficiently managing kernel memory usage -- the data area
> grows but never shrinks, and total possible usage increases per
> backstore. (What if there are 1000?) Any ideas how we could also improve
> these aspects of the design? (Global TCMU data area usage limit?)

Sorry for misunderstanding about this on my part before.

If we couldn't get a feasible way from mm to deal with the memories
shrinking. Maybe a global TCMU data area usage limit is a good choice:

We can limit the global physical data area size to 2G as default, and export
one sysfs to configure this as needed(such as 10G size with possible 1000
targets).

Then use one global radix tree to manage all the 2G physical pages(will grow
from 0 to 2G). Each ring buffer will search it's own data area bitmaps, and
if the current block is reusing, then we should get the old page, which has
already mapped to the runner process, from the global radix tree, or should
we get one new page(from global radix tree or system MM). After getting the
page, tcmu in kernel will use it my kmap(). Free it with kumapp() and 
insert to
global radix tree.

BRs
Xiubo