Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp263436pxb; Thu, 14 Jan 2021 05:30:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJw4Rn668+EGQXITIimH6LXQvhGCFSjCGfE4yJtUAFUZurLaimfA/Ieo4r+3Bd1KXqhi6YDP X-Received: by 2002:a17:907:b01:: with SMTP id h1mr5156397ejl.450.1610631025876; Thu, 14 Jan 2021 05:30:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610631025; cv=none; d=google.com; s=arc-20160816; b=WrRgqqHxeTUqxZq3QrMH0Ao1Y8sIkCgD1/14ixl7bF7UrR13P8fKNj/SLK3TYnJ8+Y auAo8xT40HLMNBIDZB1Utn+GCvy5GN5RTVWi2jgszeYxrjLIK83h9hg/bi1QjDpQmBIf Aske4sezL6y1V4ab6FJl+/wKEKlxd7Xe3QMukSAXm9pEJnjx6NNU+6tehj2FO6UfZHz8 rLr2jiD2K8gHUhOfe59WPBGvd/M8k2pAmk8iRLzryaQe/0ApySbAArsTwmsGLenp8JSl D+eaE0BcQqksWD+8dXPkJyq1Nyw2F0oPVQmuFz5PXKmFT+WQUxzmdRsxQKO48iRiFyxG 1bPQ== 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=ndjCbPdDB10sNxps+4+MgKFhZK7joNYcq1LPXTvariE=; b=V3DTM01hQy5YZi0JEyDyKZCkdL0fAYnf5oliCfv/Op/wCeMTtQc4IdvSFCCdsgXPGZ WjN4+2yp+xU7EdQK6qO21DMfzyR/lCxEh5ScGIZdvk+euJr3LdY4CYJVY49VV+e11oOz 3hVoApdw+B+6Ia1832xEexJ04u0Dua5tPMnJBblGBsWz9rr1IbdilOiAW1v73/CDj/4+ Pb/lSA90DLxc2HDYu9k+6g0DTDLALwsWLscNrPjf6vzofQiWKrLUgwOYUnUlFz1l2n+o N9qtLvQkFEOVL3kzCZV5r2s7F016s1e0CsfD8Q/KqlNFri3G31dJdAVCB6HFAHDvkNTU iXvQ== 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 dj28si2598627edb.352.2021.01.14.05.30.01; Thu, 14 Jan 2021 05:30:25 -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 S1728304AbhANN2p (ORCPT + 99 others); Thu, 14 Jan 2021 08:28:45 -0500 Received: from lucky1.263xmail.com ([211.157.147.132]:52126 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727255AbhANN2o (ORCPT ); Thu, 14 Jan 2021 08:28:44 -0500 Received: from localhost (unknown [192.168.167.235]) by lucky1.263xmail.com (Postfix) with ESMTP id 1C39BEF870; Thu, 14 Jan 2021 21:26:25 +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 [113.57.152.160]) by smtp.263.net (postfix) whith ESMTP id P25768T139699018872576S1610630781466147_; Thu, 14 Jan 2021 21:26:25 +0800 (CST) X-IP-DOMAINF: 1 X-UNIQUE-TAG: <5f77833fcca4fb1f9b3a37589cb440f1> X-RL-SENDER: changlianzhi@uniontech.com X-SENDER: changlianzhi@uniontech.com X-LOGIN-NAME: changlianzhi@uniontech.com X-FST-TO: jack@suse.cz X-SENDER-IP: 113.57.152.160 X-ATTACHMENT-NUM: 0 X-System-Flag: 0 From: lianzhi chang To: jack@suse.cz, magnani@ieee.org 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 21:26:15 +0800 Message-Id: <20210114132615.16522-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