Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp432700pxb; Thu, 14 Jan 2021 09:17:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJyAdXsuVzxRW8BQEnzgKChtXEAlf0T/uXhL1a5cCoRWSguu6yu39fqX795iISH9V8yhDSPm X-Received: by 2002:aa7:d803:: with SMTP id v3mr954001edq.153.1610644668860; Thu, 14 Jan 2021 09:17:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610644668; cv=none; d=google.com; s=arc-20160816; b=L6wyiSSaf8AgxhR3y8P7L+AETI4xX3W4RxTNzPYdPl/jH8VWZnwbJ5msku12TuLFS/ iHd/VV8DXUq0M/WL8jpW+pxqDicKdnfCnH8gsW+G70Xk0bPMH5zEwNPL9Xc6hmyPRvL/ yT4mW9f9iM4yp1v38LvyvigHHCYBcdo3bnYEKJCgNLzdH85ZzaNP3zJDCSaHnVuGUSKi TKrOFBr2wlU14C9SQRRZ/1gL4utJq+NaboTrjBxLlBZcdEWGaG2sgAqDyjM6o2I+y+BI szsBDTqlS6c2furvYvRVNcSZVf7OrTDaVgZypNUru2aUGcO3Q+eB6fZyCCtQiqmtFmaS 7Qcw== 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=iJ6Ow9w/oibqt9qjlxfetdI2OC+nxHfGgwpqOaX8hsE=; b=tgDTZ8qAvXq9hWvbonRencobsMldpZDZYtLnSHbVCzeP2YMOE8FTHBoGPh9D3tDHiT t3EyT9zEQbDViQX4xHKJERhVYJC/orQZxtmPOcKVRy/wIL7zB/quFzc96EXsif+gEptK ZfdQOaUt0kV8vFJrTSjZG7oZuAqmRVhvztmNsCKJNM3gBHaCc3+PbD0+0ufCafK3xuFT SAwbNFL1ma7BHUlL3dpHCIImRAv5V1cf0kenobxoSzonAJx79wn6MNv9FBg1TDRbQD+N hgr7Wa0A1nPWcxzxHfLG+2tvaWoaP1gwhXyVqOmuxZw7lB2QJV0LiwbZKQwJ2XnoItsM dd1g== 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 z7si1726998edm.477.2021.01.14.09.17.24; Thu, 14 Jan 2021 09:17:48 -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 S1728926AbhANRQB (ORCPT + 99 others); Thu, 14 Jan 2021 12:16:01 -0500 Received: from mx2.suse.de ([195.135.220.15]:34832 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727194AbhANRQA (ORCPT ); Thu, 14 Jan 2021 12:16:00 -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 78C12AFFA; Thu, 14 Jan 2021 17:15:19 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id C31601E053E; Thu, 14 Jan 2021 18:15:17 +0100 (CET) Date: Thu, 14 Jan 2021 18:15:17 +0100 From: Jan Kara To: lianzhi chang Cc: jack@suse.cz, magnani@ieee.org, linux-kernel@vger.kernel.org, 282827961@qq.com Subject: Re: [PATCH] udf: fix the problem that the disc content is not displayed Message-ID: <20210114171517.GC27380@quack2.suse.cz> References: <20210114132615.16522-1-changlianzhi@uniontech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210114132615.16522-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 21:26:15, 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 There was no need to resend the patch (I've fixed up the problem locally - it was easy enough) but thanks anyway :). Honza > --- > 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; > + 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