Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp329441pxb; Wed, 13 Jan 2021 04:56:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJxMgUJRrDsISy6yIFBFMnBkGC6EVVRDUr9FLZuFODsqiFKeCQHLWbqtkT79WfrV7+io5bsU X-Received: by 2002:a17:906:5796:: with SMTP id k22mr1413145ejq.435.1610542578105; Wed, 13 Jan 2021 04:56:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610542578; cv=none; d=google.com; s=arc-20160816; b=ELcXJPgaN3lZKb7GWtz88h/tqdjy0Y0/1mcU3RiI+9qVoLP1cNdnmgPm6tT3m32w0t TOC7jNIrJM4GJksUaaCS/W9aUTLa7hX+IL2uRWOm29Bk9SX+5pVd8SIRjC+7WS4YHEm4 XpGdJmcZWD63zg4cpeeTLGTZamQmVx9niyh7vthWVvGFvH0w4klrXArPYp4JRA0iiXkL VYDjalW6zds+CR0DztDY39FR4eXLwFKA3nAm8Nra9yBARDMRjDHaTzhvq6Hk29dARRzw 3dcmVzQMUi/5560YXSea/TYfYHnUoX07buZ32RFueTdij/AQdhOjvvk18T8dTRaTb7rr yRlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:user-agent :references:in-reply-to:subject:cc:to:from:date:mime-version :dkim-signature; bh=qhkEqXsTfNFQu3YiKYv8ypbqP4b1UyaJYi0d3q+UtuE=; b=IswVqZQdv4TozC8pGiUFVG6wOnyVA+UC7syIbsbx9gwQ6QJUURStZmHiyi8Yn1INv6 9HHHtWCG8PzGF+mndozlr06/XCegCE53vWMyIUtBwFI4M4ngKz7NKlrlBeeufnfuWt2D Nx4sm0FP7HqqbCVW7ORaUPnytPepgMJQpxBc/fXZ84NEb0e+RsNUd8xvB1QFtfzey106 e0yhjCiFmuPstrrG+aKvT+JG0wexqw8yTqNEc4aMSu44TkCEpxP2l6xARpiTYGOuIc9f 0iX5vt0Ifed7UN4DSYwTBkz5NVM8zurmD7Ffinx+BSqfSpPeP9g7n5GI9vnl0AAiwNoY QoCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ieee.org header.s=google header.b=HQoaVygr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ieee.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rk15si879854ejb.170.2021.01.13.04.55.54; Wed, 13 Jan 2021 04:56:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ieee.org header.s=google header.b=HQoaVygr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ieee.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726641AbhAMMwc (ORCPT + 99 others); Wed, 13 Jan 2021 07:52:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725902AbhAMMwb (ORCPT ); Wed, 13 Jan 2021 07:52:31 -0500 Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE694C061575 for ; Wed, 13 Jan 2021 04:51:51 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id o6so3730495iob.10 for ; Wed, 13 Jan 2021 04:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:date:from:to:cc:subject:in-reply-to:references :user-agent:message-id:content-transfer-encoding; bh=qhkEqXsTfNFQu3YiKYv8ypbqP4b1UyaJYi0d3q+UtuE=; b=HQoaVygrHNpMPVy7m82be4EHt4wuqT4sodTPkyC0QpcnxHenhODLCbTXKxnmf9rxDA OWXCqZxIHOjBfZojF7bDkqu1l2QaA+5ti2inxc5Y87bYWTmkIh/6Jl9RlOpz17r34kq7 O6rjrbEQCEwvrZNxpi8JLmP+BNpPRcPgUo20o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:from:to:cc:subject:in-reply-to :references:user-agent:message-id:content-transfer-encoding; bh=qhkEqXsTfNFQu3YiKYv8ypbqP4b1UyaJYi0d3q+UtuE=; b=oXxjxK7EVh2rR9jM38nJiYc4oLLbodGOIuNgT9q9jRg1l+8FLHaGbJG7M+LnQ2cM+s O7oPtauak+/LR6nTt0EWVg+9VS2vuatVpMr26Jl4xiwIm09ynxMCqNIblMLygJK1I31I xXQ7QAbePZJzfbZXv2KI5xIJs1EoLZg6Zrav/N6wCFVeOJ7yjFDyf7k1mRp3V/Xd1ZfC XcjiyqRXLA1odFPiiU4d5dA2GnAYwHjc6N1pp5Y35qHUP5u+krHlJgyx+egcxF2Q49vC qygEoKqK8WwNjaQoZzCqBlzlMDPcEBDQ4Er0HeE7EM6m19va3zzxTa88NucTOYL4ZXaR bZlw== X-Gm-Message-State: AOAM530gUwcafHXDX8CuCoojFurgnHJiCZSQ3P23fILfMy2t5o8za3+0 OOWizP+gNhOSxwP4LJQubj8dag== X-Received: by 2002:a05:6e02:1787:: with SMTP id y7mr2102033ilu.233.1610542311012; Wed, 13 Jan 2021 04:51:51 -0800 (PST) Received: from sunraycer.home ([2601:246:4400:318::100]) by smtp.gmail.com with ESMTPSA id s12sm1483834ilp.66.2021.01.13.04.51.50 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 13 Jan 2021 04:51:50 -0800 (PST) Received: from 10.10.2.100 (sunraycer [10.10.2.100]) by sunraycer.home (Postfix) with ESMTPSA id 9BCFF3749EC; Wed, 13 Jan 2021 06:51:49 -0600 (CST) MIME-Version: 1.0 Date: Wed, 13 Jan 2021 06:51:49 -0600 From: Steve Magnani To: lianzhi chang Cc: jack@suse.com, linux-kernel@vger.kernel.org, 282827961@qq.com Subject: Re: [PATCH] udf: fix the problem that the disc content is not displayed In-Reply-To: <20210112055304.31842-1-changlianzhi@uniontech.com> References: <20210112055304.31842-1-changlianzhi@uniontech.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: <9495f2dcd2882a43678532eb8df356bc@ieee.org> X-Sender: magnani@ieee.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-01-11 23:53, lianzhi chang wrote: > When the capacity of the disc is too large (assuming the 4.7G > specification), the disc (UDF file system) will be burned > multiple times in the windows (Multisession Usage). When the > remaining capacity of the CD is less than 300M (estimated > value, for reference only), open the CD in the Linux system, > the content of the CD is displayed as blank (the kernel will > say "No VRS found"). Windows can display the contents of the > CD normally. > Through analysis, in the "fs/udf/super.c": udf_check_vsd > function, the actual value of VSD_MAX_SECTOR_OFFSET may > be much larger than 0x800000. According to the current code > logic, it is found that the type of sbi->s_session is "__s32", > when the remaining capacity of the disc is less than 300M > (take a set of test values: sector=3154903040, > sbi->s_session=1540464, sb->s_blocksize_bits=11 ), the > calculation result of "sbi->s_session << sb->s_blocksize_bits" > will overflow. Therefore, it is necessary to convert the > type of s_session to "loff_t" (when udf_check_vsd starts, > assign a value to _sector, which is also converted in this > way), so that the result will not overflow, and then the > content of the disc can be displayed normally. > > Signed-off-by: lianzhi chang > --- > fs/udf/super.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/udf/super.c b/fs/udf/super.c > index 5bef3a68395d..6c3069cd1321 100644 > --- a/fs/udf/super.c > +++ b/fs/udf/super.c > @@ -757,7 +757,7 @@ static int udf_check_vsd(struct super_block *sb) > > if (nsr > 0) > return 1; > - else if (!bh && sector - (sbi->s_session << sb->s_blocksize_bits) == > + else if (!bh && sector - ((loff_t)sbi->s_session << > sb->s_blocksize_bits) == > VSD_FIRST_SECTOR_OFFSET) > return -1; > else Looks good. Perhaps consider factoring out the conversion (which also occurs earlier in the function) so that the complexity of this "else if" can be reduced? Reviewed-by: Steven J. Magnani ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! Earthling, return my space modulator!" #include