Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp86675pxb; Thu, 14 Jan 2021 00:11:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJxDFKASx1Igis7ZIIv0+TbSm5DXV6d9z2ZPEr7NFKknLq2gdvfbphwfmCPVY+TYJdfRDXEx X-Received: by 2002:a17:906:279a:: with SMTP id j26mr4382582ejc.203.1610611864261; Thu, 14 Jan 2021 00:11:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610611864; cv=none; d=google.com; s=arc-20160816; b=HT8gq7/l46FM0+EuwlpLeGOlvMosuU4m/vCdMvFFMeOYhUuF29Dr8aASxt+Xj64X4T l+Kuu8CP30XEKckPSQt79V/KNoYH9s6UTWhSyJoKTFlikrcxOkQKXJwXWPIGZPcbCQI2 dN3utGpcbIGqaX0DB1bOacguPQjf73FgKyOrYGII83HXomJ0wAZq+qZdALAI7BdSlAvk LTJf9iQBOZKwbK6147kHhwXDIT+kD4DhFP3VUA7jZMMcmtAlMnNcmJu29QhN4XfLGCNI Nedt8EsXoM7ONSSr4HYKNTXlrhxVCDo8+D2yYHttug7XTmyP9C6sp/ogI2mKgnVVMfd0 1TOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=eeVcbdHHi/fyXwcScObbeHRFB79zyx/eaPE94eJG1rQ=; b=JXeIoghOiEvago2bYFWWm9S5pVwuyeYW1RMbHfGYi9eLQDW+EFCOSWG5g1U2jBwXB7 fnm2HGQeR4gbTvtSt3uzDNSpotJ+H1uL8AgAN2Vp4X0ceRduU5XyVdJQJ6yOKs/YFtxV LxxxmZ1kSl1W+iTuyBDK0OaWBg/U7/FHaRjunDKyVaLw4Bubhe6nR4KgqNTRKlG7mmbR 59lOkPcsQX6IwklHWujNieunZBFMNNe1leUR15303C0yw9FLG7mJw3aEBedZFEQLeXdY hmDw6bjoQE5nzm3B2zebXBxAX+0A3H6gCd85JftC5CgMha0SPHk8U/f9X88N3HaVIyVl MpDQ== 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 b16si2088595ejc.710.2021.01.14.00.10.41; Thu, 14 Jan 2021 00:11:04 -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 S1727543AbhANIIU (ORCPT + 99 others); Thu, 14 Jan 2021 03:08:20 -0500 Received: from lucky1.263xmail.com ([211.157.147.130]:49396 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727184AbhANIIT (ORCPT ); Thu, 14 Jan 2021 03:08:19 -0500 X-Greylist: delayed 482 seconds by postgrey-1.27 at vger.kernel.org; Thu, 14 Jan 2021 03:08:17 EST Received: from localhost (unknown [192.168.167.70]) by lucky1.263xmail.com (Postfix) with ESMTP id 8ED3ACF362; Thu, 14 Jan 2021 15:57:50 +0800 (CST) X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-ADDR-CHECKED4: 1 X-ANTISPAM-LEVEL: 2 X-ABS-CHECKED: 0 Received: from localhost.localdomain (unknown [61.183.83.60]) by smtp.263.net (postfix) whith ESMTP id P28428T139696474674944S1610611064544086_; Thu, 14 Jan 2021 15:57:50 +0800 (CST) X-IP-DOMAINF: 1 X-UNIQUE-TAG: <5be0634fd358803b15393d18bafb6cea> X-RL-SENDER: changlianzhi@uniontech.com X-SENDER: changlianzhi@uniontech.com X-LOGIN-NAME: changlianzhi@uniontech.com X-FST-TO: magnani@ieee.org X-SENDER-IP: 61.183.83.60 X-ATTACHMENT-NUM: 0 X-System-Flag: 0 From: lianzhi chang To: magnani@ieee.org, jack@suse.com Cc: linux-kernel@vger.kernel.org, 282827961@qq.com, lianzhi chang Subject: [PATCH] udf: fix the problem that the disc content is not displayed Date: Thu, 14 Jan 2021 15:57:41 +0800 Message-Id: <20210114075741.30448-1-changlianzhi@uniontech.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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); + 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