Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp164247pxb; Thu, 14 Jan 2021 02:44:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJwmvTzObVB0kVct9kDTxnfjWNT+5ZoGiecaZtMu9bmQQqhkXiUYEpIZloCFTQWtE5dbVDex X-Received: by 2002:a17:906:1308:: with SMTP id w8mr4674366ejb.396.1610621049284; Thu, 14 Jan 2021 02:44:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610621049; cv=none; d=google.com; s=arc-20160816; b=YTQkFOUmKzlimz2CLOmAuxZ2WggoP7MhOX3K2NMlGUIzoT7r0N1u9yhQYWoDDReQRs vtd6oWvCnj8er2H9NR0uwstSS5ofQl1cBl7cNn2fCHuQ1/B/Ml6VgebLYTCnJCr3T7rK DftJ/GmoYYlDQqU+sH87wVtowr3+DT6VPKgYimbSyMO/QH+tadtFmhtwAezHZSVNu68r 2ooS6QeqyOx+2uajrSyyrkXR9x5B6g2L7NcQBa+rXbysNwOvzWOCUz6gwQFXdX+OBLcq AQlARnFcagFpeg1IHFzLejjMnKVuPKb6TLsSk08wGjsgSHC73JVhQIyZCoDIkGU1Q++1 OaXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=VR1/IgkUvByrKfFjOFYlCudlRoKwxwlxFoti1RxVPjc=; b=xymm/UNS25xD5/DvIUVdbngtKgxkVCEZvqueA3HNPXmQRmEhHAdW7wLNpeBsYNkIL1 fccKpNTrwxcrLGr0DGUVgyyjxX3ev9RkyxZUb1XkJYQ54Yco2PvrlhnYy553hDnKanH0 f9tM1x4nKddQ1UJmOS/3lmRP2ngrKoLYwLYQ1NND4stmuB+OelSNUdiPmGxJHtRKn6jx hgAuyAWw0eW/lDEr4qZ2w6xiLEiB8aeMEemiHv7X6B0QvZEtYWE1RpIVtOQYz6Y/grph CWZhNW5H8KyZSZDZ423YGNxS0bnM2x6d7V2jwYjqIZWQoMm/EPL6z0AAdwSyszrzG2/V KL+Q== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r25si482565eds.336.2021.01.14.02.43.45; Thu, 14 Jan 2021 02:44:09 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727324AbhANKmn (ORCPT + 99 others); Thu, 14 Jan 2021 05:42:43 -0500 Received: from mx2.suse.de ([195.135.220.15]:35028 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726236AbhANKmm (ORCPT ); Thu, 14 Jan 2021 05:42:42 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 1E6CEAB7A; Thu, 14 Jan 2021 10:42:01 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 9AC931E086B; Thu, 14 Jan 2021 11:41:57 +0100 (CET) Date: Thu, 14 Jan 2021 11:41:57 +0100 From: Jan Kara To: lianzhi chang Cc: magnani@ieee.org, 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 Message-ID: <20210114104157.GB25790@quack2.suse.cz> References: <20210114075741.30448-1-changlianzhi@uniontech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210114075741.30448-1-changlianzhi@uniontech.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 14-01-21 15:57:41, 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 | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/fs/udf/super.c b/fs/udf/super.c > index 5bef3a68395d..f2ff98f393fb 100644 > --- a/fs/udf/super.c > +++ b/fs/udf/super.c > @@ -705,6 +705,7 @@ static int udf_check_vsd(struct super_block *sb) > struct buffer_head *bh = NULL; > int nsr = 0; > struct udf_sb_info *sbi; > + loff_t sector_offset; > > sbi = UDF_SB(sb); > if (sb->s_blocksize < sizeof(struct volStructDesc)) > @@ -712,7 +713,8 @@ static int udf_check_vsd(struct super_block *sb) > else > sectorsize = sb->s_blocksize; > > - sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits); > + sector_offset = (loff_t)sbi->s_session << sb->s_blocksize_bits); There's imbalanced parentheses here, I'll fix it up on commit. Otherwise the fix looks good to me. Thanks! Honza > + sector += sector_offset; > > udf_debug("Starting at sector %u (%lu byte sectors)\n", > (unsigned int)(sector >> sb->s_blocksize_bits), > @@ -757,8 +759,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) == > - VSD_FIRST_SECTOR_OFFSET) > + else if (!bh && sector - sector_offset == VSD_FIRST_SECTOR_OFFSET) > return -1; > else > return 0; > -- > 2.20.1 > > > -- Jan Kara SUSE Labs, CR