Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2554885rwb; Mon, 7 Nov 2022 14:57:18 -0800 (PST) X-Google-Smtp-Source: AMsMyM5reS9dzV7eN+H9ayJUYjTBdpgxohHBkf2BW2dn+FSFSxUFgY4Ibz1Zyb0YXYw4XJ1R1MAn X-Received: by 2002:aa7:d80a:0:b0:462:2c1c:8716 with SMTP id v10-20020aa7d80a000000b004622c1c8716mr53623994edq.185.1667861838300; Mon, 07 Nov 2022 14:57:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667861838; cv=none; d=google.com; s=arc-20160816; b=eKf3RA/qqnz9aBsf2IN1VQydf4ANj2tIItmv08Sv2lnwMotooNf2NX5MNbiON97McG WF5sZTQQhJckQmjjMCr+FHxNhw6G5jzMeBJxp2sfPNIaw748FYvvyGUQRqH8FZ5DG0WJ uwqVhJwi7t+wB0qCMgXPFntNdBaHmKP+2VfBZJvNTjaEfC12zyzWjgQ5x6c91OC7Vle6 pI/2ZGVCfItQvZ/sISf6RUkeLbw/2BeyBdKxZNqHYOirFCM6rEj24Rd/K6ETRXFxpghi 6rLny39GuUXpk8qMvvtMHTKLrr11Y8gTusA0RyAy9ieM6DSXHPeRcMfV21B5fj5aT3kQ z5dA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:to:from:date:dkim-signature :dkim-signature; bh=heeLIqfHkxyg8vSslC2bUlS87rdacKF796SQBLNeRn4=; b=pdU2xbeAgcmLphHo7BPc/lYporhjOJ2xJk+aDwrcJngNk2RacHAGVrt7+eiLZoGzsQ UnIfO329PaZDmnydkpafiRodRtYU0bHioNWnrVkSaBDr2JRyZmwaQWkM95HdYz77CJ1X F+zPffQwMpvOOhFYD0fJriiXaVBUJGQQtsVd4I3tHCktnQsmcpSAr822klEVhFRyuvNk y5nL0a/ui9z0qmb8H3AXbyF3+ICGu5nrM/gFN3KYaHhBOH0HT/YZ5OFTc3t3mXD75hFt 1rvaNVF6tE5EcmuTz2wwkMK9uqYMI/FBFy8lkDySh1LgPKyID0eMErEzomYYmHYiAGEb yjsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=ipvwXWdo; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=XIo8CdBv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s16-20020aa7d790000000b00458e87a1d83si9740879edq.54.2022.11.07.14.56.56; Mon, 07 Nov 2022 14:57:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=ipvwXWdo; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=XIo8CdBv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232505AbiKGWmv (ORCPT + 91 others); Mon, 7 Nov 2022 17:42:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232476AbiKGWms (ORCPT ); Mon, 7 Nov 2022 17:42:48 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72AF222285; Mon, 7 Nov 2022 14:42:47 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 31E991F383; Mon, 7 Nov 2022 22:42:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1667860966; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=heeLIqfHkxyg8vSslC2bUlS87rdacKF796SQBLNeRn4=; b=ipvwXWdog3WNEK98N0mV2ZiUWIsWjXKSdc8tZ/NHABZqdGBGiypmIwnxjQ5GGHgv6a/ehY u9ixUh76+Csd7LwN/K80zIDzp0sqIWM8maU19/jyMS2BpIJRX8JZhZszDnMm8S1Dhe/YbI IBYwIWXQ1kMYzxkUUXt+/YlSHCVfrcM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1667860966; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=heeLIqfHkxyg8vSslC2bUlS87rdacKF796SQBLNeRn4=; b=XIo8CdBv5q5LFZ6wnsziOp1KPnSFTTo5I7Ph1t44gC0M0d74H9KdxtenFdbtIR9PaB8Hxk zNmYVqe7u5pz4dCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C34EE13494; Mon, 7 Nov 2022 22:42:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id I9/OLeWJaWM6RAAAMHmgww (envelope-from ); Mon, 07 Nov 2022 22:42:45 +0000 Date: Mon, 7 Nov 2022 23:42:43 +0100 From: Petr Vorel To: Minchan Kim , ltp@lists.linux.it, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Nitin Gupta , Sergey Senozhatsky , Jens Axboe , OGAWA Hirofumi , Martin Doucha , Yang Xu Subject: Re: [PATCH 0/1] Possible bug in zram on ppc64le on vfat Message-ID: Reply-To: Petr Vorel References: <20221107191136.18048-1-pvorel@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Hi Minchan, > > On Mon, Nov 07, 2022 at 08:11:35PM +0100, Petr Vorel wrote: > > > Hi all, > > > following bug is trying to workaround an error on ppc64le, where > > > zram01.sh LTP test (there is also kernel selftest > > > tools/testing/selftests/zram/zram01.sh, but LTP test got further > > > updates) has often mem_used_total 0 although zram is already filled. > > Hi, Petr, > > Is it happening on only ppc64le? > I haven't seen it on other archs (x86_64, aarch64). > > Is it a new regression? What kernel version did you use? > Found on openSUSE kernel, which uses stable kernel releases 6.0.x. > It's probably much older, first I've seen it some years ago (I'm not able to find kernel version), but it was random. Now it's much more common. I tested it on bare metal machine with some older SLES kernel (based on 4.12.14, with thousands of patches) and it fails: # PATH="/opt/ltp/testcases/bin:$PATH" LTP_SINGLE_FS_TYPE=vfat zram01.sh ... zram01 5 TINFO: make vfat filesystem on /dev/zram0 zram01 5 TPASS: zram_makefs succeeded zram01 6 TINFO: mount /dev/zram0 zram01 6 TPASS: mount of zram device(s) succeeded zram01 7 TINFO: filling zram0 (it can take long time) zram01 7 TPASS: zram0 was filled with '25568' KB /opt/ltp/testcases/bin/zram01.sh: line 137: 100 * 1024 * 25568 / 0: division by 0 (error token is "0") ... My patch does not help, obviously the value does not change. zram01 5 TINFO: make vfat filesystem on /dev/zram1 zram01 5 TPASS: zram_makefs succeeded zram01 6 TINFO: mount /dev/zram1 zram01 6 TPASS: mount of zram device(s) succeeded zram01 7 TINFO: filling zram1 (it can take long time) zram01 7 TPASS: zram1 was filled with '25568' KB zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TINFO: /sys/block/zram1/mm_stat 15859712 0 0 26214400 196608 242 0 zram01 7 TBROK: "loop_read_mem_used_total /sys/block/zram1/mm_stat" timed out This is just to demonstrate, that the problem has been here long time, and it's not QEMU related (although it could be theoretically related to openSUSE/SLES user space, but it's very unlikely). I'll debug if page_same_filled() is being called on mainline kernel. Kind regards, Petr > Test runs on VM (I can give qemu command or whatever you need to know about it) > I'll try to verify it on some bare metal ppc64le. > > Actually, mem_used_total indicates how many *physical memory* were > > currently used to keep original data size. > > However, if the test data is repeated pattern of unsigned long > > (https://github.com/torvalds/linux/blob/master/drivers/block/zram/zram_drv.c#L210) > > zram doesn't allocate the physical memory but just mark the unsigned long's value > > in meta area for decompression later. > > Not sure you hit the this case. > Thanks for a hint, I'll try to debug it. > Kind regards, > Petr > > > Patch tries to repeatedly read /sys/block/zram*/mm_stat for 1 sec, > > > waiting for mem_used_total > 0. The question if this is expected and > > > should be workarounded or a bug which should be fixed. > > > REPRODUCE THE ISSUE > > > Quickest way to install only zram tests and their dependencies: > > > make autotools && ./configure && for i in testcases/lib/ testcases/kernel/device-drivers/zram/; do cd $i && make -j$(getconf _NPROCESSORS_ONLN) && make install && cd -; done > > > Run the test (only on vfat) > > > PATH="/opt/ltp/testcases/bin:$PATH" LTP_SINGLE_FS_TYPE=vfat zram01.sh > > > Petr Vorel (1): > > > zram01.sh: Workaround division by 0 on vfat on ppc64le > > > .../kernel/device-drivers/zram/zram01.sh | 27 +++++++++++++++++-- > > > 1 file changed, 25 insertions(+), 2 deletions(-) > > > -- > > > 2.38.0