linux-kernel - Re: [PATCH v5 3/4] zram: zram memory size limitation

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]

Message-ID: <CAFdhcLQce05qi2LGP85N=aaQiKz1ArC3Kn+W-s86R58BkjMr3w@mail.gmail.com>
Date:	Tue, 26 Aug 2014 08:22:29 -0400
From:	David Horner <ds2horner@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Jerome Marchand <jmarchan@...hat.com>, juno.choi@....com,
	seungho1.park@....com, Luigi Semenzato <semenzato@...gle.com>,
	Nitin Gupta <ngupta@...are.org>,
	Seth Jennings <sjennings@...iantweb.net>,
	Dan Streetman <ddstreet@...e.org>
Subject: Re: [PATCH v5 3/4] zram: zram memory size limitation

On Tue, Aug 26, 2014 at 3:55 AM, Minchan Kim <minchan@...nel.org> wrote:
> Hey Joonsoo,
>
> On Tue, Aug 26, 2014 at 04:37:30PM +0900, Joonsoo Kim wrote:
>> On Mon, Aug 25, 2014 at 09:05:55AM +0900, Minchan Kim wrote:
>> > @@ -513,6 +540,14 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
>> >             ret = -ENOMEM;
>> >             goto out;
>> >     }
>> > +
>> > +   if (zram->limit_pages &&
>> > +           zs_get_total_pages(meta->mem_pool) > zram->limit_pages) {
>> > +           zs_free(meta->mem_pool, handle);
>> > +           ret = -ENOMEM;
>> > +           goto out;
>> > +   }
>> > +
>> >     cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO);
>>
>> Hello,
>>
>> I don't follow up previous discussion, so I could be wrong.
>> Why this enforcement should be here?
>>
>> I think that this has two problems.
>> 1) alloc/free happens unnecessarilly if we have used memory over the
>> limitation.
>
> True but firstly, I implemented the logic in zsmalloc, not zram but
> as I described in cover-letter, it's not a requirement of zsmalloc
> but zram so it should be in there. If every user want it in future,
> then we could move the function into zsmalloc. That's what we
> concluded in previous discussion.
>
> Another idea is we could call zs_get_total_pages right before zs_malloc
> but the problem is we cannot know how many of pages are allocated
> by zsmalloc in advance.
> IOW, zram should be blind on zsmalloc's internal.
>

We did however suggest that we could check before hand to see if
max was already exceeded as an optimization.
(possibly with a guess on usage but at least using the minimum of 1 page)
In the contested case, the max may already be exceeded transiently and
therefore we know this one _could_ fail (it could also pass, but odds
aren't good).
As Minchan mentions this was discussed before - but not into great detail.
Testing should be done to determine possible benefit. And as he also
mentions, the better place for it may be in zsmalloc, but that
requires an ABI change.

Certainly a detailed suggestion could happen on this thread and I'm
also interested
in your thoughts, but this patchset should be able to go in as is.
Memory exhaustion avoidance probably trumps the possible thrashing at
threshold.

> About alloc/free cost once if it is over the limit,
> I don't think it's important to consider.
> Do you have any scenario in your mind to consider alloc/free cost
> when the limit is over?
>
>> 2) Even if this request doesn't do new allocation, it could be failed
>> due to other's allocation. There is time gap between allocation and
>> free, so legimate user who want to use preallocated zsmalloc memory
>> could also see this condition true and then he will be failed.
>
> Yeb, we already discussed that. :)
> Such false positive shouldn't be a severe problem if we can keep a
> promise that zram user cannot exceed mem_limit.
>

And we cannot avoid the race, nor can we avoid in a low overhead competitive
concurrent process transient inconsistent states.
Different views for different observers.
 They are a consequence of the theory of "Special Computational Relativity".
 I am working on a String Unification Theory of Quantum and General CR in LISP.
 ;-)



>>
>> Thanks.
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@...ck.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
>
> --
> Kind regards,
> Minchan Kim
--
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/