From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751822AbdEPHgf (ORCPT ); Tue, 16 May 2017 03:36:35 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:33823 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751760AbdEPHg2 (ORCPT ); Tue, 16 May 2017 03:36:28 -0400 Date: Tue, 16 May 2017 16:36:17 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org, Joonsoo Kim , Sergey Senozhatsky , kernel-team Subject: Re: [PATCH 2/2] zram: do not count duplicated pages as compressed Message-ID: <20170516073616.GB767@jagdpanzerIV.localdomain> References: <1494834068-27004-1-git-send-email-minchan@kernel.org> <1494834068-27004-2-git-send-email-minchan@kernel.org> <20170516013022.GB10262@jagdpanzerIV.localdomain> <20170516015919.GA5233@bbox> <20170516023615.GC10262@jagdpanzerIV.localdomain> <20170516052605.GA5429@bbox> <20170516054533.GA767@jagdpanzerIV.localdomain> <20170516071644.GA6224@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170516071644.GA6224@bbox> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (05/16/17 16:16), Minchan Kim wrote: > > but would this be correct? the data is not valid - we failed to store > > the valid one. but instead we assure application that read()/swapin/etc., > > depending on the usage scenario, is successful (even though the data is > > not what application really expects to see), application tries to use the > > data from that page and probably crashes (dunno, for example page contained > > hash tables with pointers that are not valid anymore, etc. etc.). > > > > I'm not optimistic about stale data reads; it basically will look like > > data corruption to the application. > > Hmm, I don't understand what you say. > My point is zram_free_page should be done only if whoe write operation > is successful. > With you change, following situation can happens. > > write block 4, 'all A' -> success > read block 4, 'all A' verified -> Good > write block 4, 'all B' -> but failed with ENOMEM > read block 4 expected 'all A' but 'all 0' -> Oops yes. 'all A' in #4 can be incorrect. zram can be used as a block device with a file system, and pid that does write op not necessarily does read op later. it can be a completely different application. e.g. compilation, or anything else. suppose PID A does wr block 1 all a wr block 2 all a + 1 wr block 3 all a + 2 wr block 4 all a + 3 now PID A does wr block 1 all m wr block 2 all m + 1 wr block 3 all m + 2 wr block 4 failed. block still has 'all a + 3'. exit another application, PID C, reads in the file and tries to do something sane with it rd block 1 all m rd block 2 all m + 1 rd block 3 all m + 3 rd block 4 all a + 3 << this is dangerous. we should return error from read() here; not stale data. what we can return now is a `partially updated' data, with some new and some stale pages. this is quite unlikely to end up anywhere good. am I wrong? why does `rd block 4' in your case causes Oops? as a worst case scenario? application does not expect page to be 'all A' at this point. pages are likely to belong to some mappings/files/etc., and there is likely a data dependency between them, dunno C++ objects that span across pages or JPEG images, etc. so returning "new data new data stale data" is a bit fishy. -ss