Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp31853447rwd; Fri, 7 Jul 2023 05:30:59 -0700 (PDT) X-Google-Smtp-Source: APBJJlH9lIHpDEJSu/1UEwg/IXX/1Ac+N7BLTqut4a3FsWZOWdandNBdneEBoE3eKcss86f027vA X-Received: by 2002:a05:6a21:999d:b0:125:4d74:cd6a with SMTP id ve29-20020a056a21999d00b001254d74cd6amr12368570pzb.3.1688733059234; Fri, 07 Jul 2023 05:30:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688733059; cv=none; d=google.com; s=arc-20160816; b=b8jIGWmYEPP4EWC9XZukANZUJ5HfAQjuDP6ZeKVX6Xu8cJfnZH+DKFP+pNDUSU7hgA HZsVPOCK/eOmoeD/UomryAqAMJF+Rb4joIkQmmGAOULSgouoCTtJ/XksnMuuup2iZqfD dqkQdpp75Fizya9fVt7DikQbHOIDR4gBVUp1v91jwaI5dWeQJ7UVIq49ERkkFyQR6hSJ Sd8EXw3nIx1ES7FcPCxdbPVHlYnkdKsYTiuKO14eaUFz/OcQLKzTs5xRSW/LGFZjGgHw aeOGLEpzBBJ/Tm5WvA+b/Slc46kx8gyoU1BqIzKQUDPEDNAzedI/AfMbrP/7HqDrC4E6 g/ZA== 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:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=xOXr7QoWpZ3X2+T8tGBbRIhretiWSAYNHeNZqoiPNpk=; fh=bJiZynuYCQqI1hUZxx35nihIbMqyfGW02MUvONY5Ur4=; b=qOjpEMsBCXE28e4132G5yQ9Td3Uph1myImg3SddqOE6lAfG0sk6RpeoHSN2sjT9JPx K2PiXwiVxgtSi4rmcDRQVBw+ov9QkwBiZxDBrEvu+ilvQrHFZHBWyYlS/rM0Ai18bnVR lzENfHiHxdea0rz8ujRR0ae1SVIAa2TSBhy9w1+AGHE7JAvdG1ac7a36nUGOZnBtjxf2 jPfwiiNjYVxvuuT3zVO1eLM5ovYd0be80/K/sB7AKAukcfcETUqnjXCpJguzZQ42GfzC Y8gF9HmiPzohXLF72cILWWsBIdX1v1qQPnu7+P7znDGqHIVcO9LFajQ/3m7QqzEQoBos I1+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=BRNi36lT; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=nD19oLnf; 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 m16-20020a63fd50000000b0055bc2561b74si3512657pgj.262.2023.07.07.05.30.47; Fri, 07 Jul 2023 05:30:59 -0700 (PDT) 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=BRNi36lT; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=nD19oLnf; 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 S229914AbjGGMTy (ORCPT + 99 others); Fri, 7 Jul 2023 08:19:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229584AbjGGMTv (ORCPT ); Fri, 7 Jul 2023 08:19:51 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EF031BC9 for ; Fri, 7 Jul 2023 05:19:49 -0700 (PDT) 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 4F49F1FD93; Fri, 7 Jul 2023 12:19:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1688732388; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xOXr7QoWpZ3X2+T8tGBbRIhretiWSAYNHeNZqoiPNpk=; b=BRNi36lT7Q3aNxOPhHXQxg4RjJtIDxqLfxcfF+RMliSPCaJV0+EPPv4thI13XlfZ97KToL 7UJRsjkr6gTJ0jgjpuzdyrUph6QMhcH4of496QQ/Ri2dwjGZ/s5MBWSFcg1SJWuGigIA2F bPCOaUi5RSB3Xc4HgzLVD9by3BxVxP0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1688732388; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xOXr7QoWpZ3X2+T8tGBbRIhretiWSAYNHeNZqoiPNpk=; b=nD19oLnfglya0Z8LJqdXocAxqQQQp9LIitNCIQD5c+mbP20ilyRzQHV0WTT18pgAXNAoJl k8LgIX+3Ty+OkmBQ== 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 4079D139E0; Fri, 7 Jul 2023 12:19:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 8nyvD+QCqGSDNAAAMHmgww (envelope-from ); Fri, 07 Jul 2023 12:19:48 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id C9F62A0717; Fri, 7 Jul 2023 14:19:47 +0200 (CEST) Date: Fri, 7 Jul 2023 14:19:47 +0200 From: Jan Kara To: Lu Hongfei Cc: Jan Kara , linux-kernel@vger.kernel.org, opensource.kernel@vivo.com Subject: Re: [PATCH] fs/udf: Change the type of blocksize from 'int' to 'unsigned int' in udf_discard_prealloc Message-ID: <20230707121947.sa2l3y3b5d2kwmdj@quack3> References: <20230707110752.13436-1-luhongfei@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230707110752.13436-1-luhongfei@vivo.com> 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,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 On Fri 07-07-23 19:07:52, Lu Hongfei wrote: > The return value type of i_blocksize() is 'unsigned int', so the > type of blocksize has been modified from 'int' to 'unsigned int' > to ensure data type consistency. > > Signed-off-by: Lu Hongfei Thanks for the patch but I'm sorry but how does this make a difference? Blocksize is a small positive integer (512-64k). So it doesn't matter whether you store it in int or unsigned it. I agree sometimes there are nasty issues in C with signed comparisons, sign extension and other complex logic and there it is beneficial to really be sure to match signedness etc. to avoid subtle issues. But in this particular case I don't see the point so I'd just keep the code as is... But please tell me if you see some readability or other benefit in this change. Honza > --- > fs/udf/truncate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/udf/truncate.c b/fs/udf/truncate.c > index a686c10fd709..c80dfcc583f6 100644 > --- a/fs/udf/truncate.c > +++ b/fs/udf/truncate.c > @@ -123,7 +123,7 @@ void udf_discard_prealloc(struct inode *inode) > uint64_t lbcount = 0; > int8_t etype = -1; > struct udf_inode_info *iinfo = UDF_I(inode); > - int bsize = i_blocksize(inode); > + unsigned int bsize = i_blocksize(inode); > > if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB || > ALIGN(inode->i_size, bsize) == ALIGN(iinfo->i_lenExtents, bsize)) > -- > 2.39.0 > -- Jan Kara SUSE Labs, CR