Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3225158ybb; Sun, 22 Mar 2020 18:52:43 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvoH2oGhnfrdaQ1MGFJiMWNg3JEXAFHcLieNHhtu+yNT2pFssKU1U2Tb5NAGpFY1BzMDzcF X-Received: by 2002:a9d:6945:: with SMTP id p5mr3610378oto.268.1584928363231; Sun, 22 Mar 2020 18:52:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584928363; cv=none; d=google.com; s=arc-20160816; b=HAGj2xnYBpQ401qkTxpX5NDiYeqttwpIrwkGp4DxHngTPaqLgixS4vBEuxhJhFv48d okUYx2jlVyQf+1CmvY44Qf0DOtzH22xyPZOUmkXGrUyfRF8t5fcl/YpiZmW0kjM7EEBF b9T+fH7Fgj32iC5JLuZnab5fUAf4UgwUfeeGP15sAFUnZ8cdToUsOUMHC0jqA1rcdOL/ Xj1FICQiFk/uefzf8Vt/Y1Jla7wDVEaNzm4LbYAIW+sbVYY+H5iDCZF69KduxIFDthM9 SHKed4cQg7AFrI/uJ5lE4y9eJr+Hr5Ei1PdOR6Aw2yUR5xVocu9lBFOXtUdHVxuXVIAC zaKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:dkim-signature; bh=8SLsMW47j3XkXoi43JnisWomCv/kF8xRgMCVOPZ4FUI=; b=eQYuCt4qzOG+MZJQBrnA+pfsej7OGyQ/5l68ilGWKVX8HlVdtzPjDFmJs95YCpqHvo 3jshBfyl1aR8li68BPSjxCyw+WfDL7kB13c/dd/aTjfYWuJ3uNCkJ31KkIww4nBo8NkQ xcNHs6BnPnSkuzo5QqKllBjLnhb1n7qRNv82wGOf4Tv9TQkRc4YjC0MT+/0WFqpmw9Y7 73zeA3US6tLqXy8Esw57sbVXsdrnIrfRGRv/v8irK1siO4sfp6dHoZmQuXVqH0Qg5W7j CLF06T5oMdlJDti75mKCrlGBVfeLoK4ikX3UrCkv8YmwBrbYAitcoElF7JYpBgZazqI6 nubw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@xff.cz header.s=mail header.b=RWwGJOKf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=xff.cz Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 109si1635209otv.36.2020.03.22.18.52.30; Sun, 22 Mar 2020 18:52:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@xff.cz header.s=mail header.b=RWwGJOKf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=xff.cz Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726976AbgCWBui (ORCPT + 99 others); Sun, 22 Mar 2020 21:50:38 -0400 Received: from vps.xff.cz ([195.181.215.36]:37720 "EHLO vps.xff.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726954AbgCWBui (ORCPT ); Sun, 22 Mar 2020 21:50:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xff.cz; s=mail; t=1584928236; bh=1N30fcEiZZHKBwEnOj8WWoevPWmYxyTUVcPdUGEd8VE=; h=Date:From:To:Cc:Subject:References:X-My-GPG-KeyId:From; b=RWwGJOKfp8Gr8AiVOHHK7dNKWIZF6ArzehJDlzDMofSgs5dGvdFPbF8uLA46sy7+d FC6NjOMYhiCFGsUgEimFwvK1Pohb6g+OehoXJ8QMdkjysSzdA41/i5Qhs/sCE/behe qJnW95oq0YmXDfKASbPTNv7dvLxQKugaEmHkMMSE= Date: Mon, 23 Mar 2020 02:50:36 +0100 From: =?utf-8?Q?Ond=C5=99ej?= Jirman To: Chao Yu Cc: jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, chao@kernel.org Subject: Re: [PATCH v3] f2fs: fix potential .flags overflow on 32bit architecture Message-ID: <20200323015036.pniupuucfl3dug4m@core.my.home> Mail-Followup-To: =?utf-8?Q?Ond=C5=99ej?= Jirman , Chao Yu , jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, chao@kernel.org References: <20200323012519.41536-1-yuchao0@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200323012519.41536-1-yuchao0@huawei.com> X-My-GPG-KeyId: EBFBDDE11FB918D44D1F56C1F9F0A873BE9777ED Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Chao Yu, On Mon, Mar 23, 2020 at 09:25:19AM +0800, Chao Yu wrote: > [snip] > > +static inline void __set_inode_flag(struct inode *inode, int flag) > +{ > + test_and_set_bit(flag % BITS_PER_LONG, > + &F2FS_I(inode)->flags[BIT_WORD(flag)]); This can simply be: test_and_set_bit(flag, F2FS_I(inode)->flags); all of these bitmap manipulation functions already will do the right thing to access the correct location in the flags array: https://elixir.bootlin.com/linux/latest/source/include/asm-generic/bitops/atomic.h#L32 see BIT_MASK and BIT_WORD use in that function. > +} > + > static inline void set_inode_flag(struct inode *inode, int flag) > { > - if (!test_bit(flag, &F2FS_I(inode)->flags)) > - set_bit(flag, &F2FS_I(inode)->flags); > + __set_inode_flag(inode, flag); > __mark_inode_dirty_flag(inode, flag, true); > } > > static inline int is_inode_flag_set(struct inode *inode, int flag) > { > - return test_bit(flag, &F2FS_I(inode)->flags); > + return test_bit(flag % BITS_PER_LONG, > + &F2FS_I(inode)->flags[BIT_WORD(flag)]); ditto > } > > static inline void clear_inode_flag(struct inode *inode, int flag) > { > - if (test_bit(flag, &F2FS_I(inode)->flags)) > - clear_bit(flag, &F2FS_I(inode)->flags); > + test_and_clear_bit(flag % BITS_PER_LONG, > + &F2FS_I(inode)->flags[BIT_WORD(flag)]); ditto I'm going to test the patch. It looks like that this was really the root cause of all those locking issues I was seeing on my 32-bit tablet. It seems to explain why my 64-bit systems were not affected, and why reverting compession fixed it too. Great job figuring this out. I'll let you know soon. thank you and regards, o. > __mark_inode_dirty_flag(inode, flag, false); > } >