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] [day] [month] [year] [list]
Date:	Wed, 23 Apr 2014 14:00:12 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Weijie Yang <weijie.yang.kh@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Weijie Yang <weijie.yang@...sung.com>,
	Minchan Kim <minchan@...nel.org>,
	Nitin Gupta <ngupta@...are.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Bob Liu <bob.liu@...cle.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] zram: correct offset usage in zram_bio_discard

On Wed, Apr 23, 2014 at 11:52:08AM +0800, Weijie Yang wrote:
> On Wed, Apr 23, 2014 at 11:08 AM, Joonsoo Kim <iamjoonsoo.kim@....com> wrote:
> > On Wed, Apr 23, 2014 at 10:32:30AM +0800, Weijie Yang wrote:
> >> On Wed, Apr 23, 2014 at 3:55 AM, Andrew Morton
> >> <akpm@...ux-foundation.org> wrote:
> >> > On Tue, 22 Apr 2014 11:14:02 +0800 Weijie Yang <weijie.yang@...sung.com> wrote:
> >> >
> >> >> we want to skip the logical block which is partially covered by
> >> >> the discard bio, so check the remaining size and subtract it if
> >> >> there is a need to goto the next logical block.
> >> >>
> >> >> This patch corrects the offset usage in zram_bio_discard.
> >> >>
> >> >
> >> > What were the end-user visible effects of the bug?
> >> >
> >> > Please always include this information when fixing something so that
> >> > others can work out which kernel(s) need patching.
> >> >
> >>
> >> Thanks for your advise, I will resend this patch and add the end-user
> >> visible effect information.
> >
> > Thanks for fixing it.
> >
> > As far as I understand, there is no end-user visible effect, because
> > request size is alway PAGE_SIZE aligned and if n < PAGE_SIZE,
> > no real operation happens. Am I missing?
> 
> The zram only limit ZRAM_LOGICAL_BLOCK_SIZE(4K) aligned,
> not PAGE_SIZE aligned.
> 
> Consider the following scenario:
> on some architecture or config, PAGE_SIZE is 64K for example
> filesystem is set up on zram disk without PAGE_SIZE aligned.
> a discard bio leads to a offset = 4K, size=72K
> normally, it should not really discard any physical block as it partially
> cover two physical blocks.
> However, with the current offset usage, it will discard the second
> physical block and free its memory, which will cause filesystem breakdown.
> 

I misunderstood what discard_granularity means. I thought that if I set
discard_granularity=PAGE_SIZE, the size of discard request is aligned to
PAGE_SIZE. But, by looking at the code, I notice that isn't true. So now, I
understand your patch compeletely. Thanks again.

Thanks.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ