Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2974839pxb; Tue, 12 Jan 2021 03:19:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJzkjDDk0fKHBbIhAgmjy5cHLke2oK7Bglk+eHIpU9P0ovXG96YvKpQRnZbnTA57R5/2cn5f X-Received: by 2002:a17:906:81ca:: with SMTP id e10mr3025598ejx.10.1610450367251; Tue, 12 Jan 2021 03:19:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610450367; cv=none; d=google.com; s=arc-20160816; b=qfw5TxPKAErBjI1ArbJKsGO0naYQRegwU5FoCiq/Y0y9AAhsaMDJW4jYQ52FZy1lGz taQG+Cy6eSjJ5BgcVqqiEQuPiIBLxn1G8lwqmDDiiXWU/9BV2B5/wa7oeF5qtJKFTaou oMDagS//YWILPuU4T3Pv0fZC6qFsJVwP8CRxUl6C5fyif+uYZwwvuwL+RwD7GnvNd//s dRMGSps8iSdaib3/5Z3gj3YoGgAo1r+zK7yOMz3tRupyLDk/X86d+Av/eDntpT7qh2cd 5xi4nHs6SFfGCeIOkXIkUwsG8ecOo9NgcdAjM3YU4dbq5Z+muhP91WYUAYAgGXdrj8U1 ySBg== 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=F18ed9EmAAmcM0+efZ3MUtyFSUnK1+PCgeG4RlIpx7Q=; b=MbJsr/iGWtrCOIKKnvWBre/JziGe99XElqRw5YRg5lys87uhm5/HqOJaQfI2Y8LdtS x71NPzhQDqZtEx7dxA4ffPUOwnGq3dD+pNxuoGvu5aO9Aon0SOWPnEB0CU6E0x9VvxRW qhCSAA+M5/vKhHQaf2dcAdBDA1rqB1lbWZv1jvTmCt0MB4xvZEdrxmwGq9XikYLbLiWI LE4Ecd/SSYYAUoqxQ01ob88T+XdaWHHIjYq/4x7rixpqEET8vWqO56o2pwVJirrr4VQY rYfnJhMsbGcrrDIk++1KkPFsfcr7U9YTysIt9jz3rHQTpZv62P3HLtL6c5ANe99Ah5TU H2Xw== 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 kt11si993081ejb.445.2021.01.12.03.19.03; Tue, 12 Jan 2021 03:19:27 -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 S1732197AbhALFzf (ORCPT + 99 others); Tue, 12 Jan 2021 00:55:35 -0500 Received: from lucky1.263xmail.com ([211.157.147.131]:45220 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731219AbhALFzf (ORCPT ); Tue, 12 Jan 2021 00:55:35 -0500 Received: from localhost (unknown [192.168.167.225]) by lucky1.263xmail.com (Postfix) with ESMTP id 4475BB6A91; Tue, 12 Jan 2021 13:53:13 +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 P21842T140225080706816S1610430788033883_; Tue, 12 Jan 2021 13:53:13 +0800 (CST) X-IP-DOMAINF: 1 X-UNIQUE-TAG: <0174191929b4418778d53ebba37a606c> X-RL-SENDER: changlianzhi@uniontech.com X-SENDER: changlianzhi@uniontech.com X-LOGIN-NAME: changlianzhi@uniontech.com X-FST-TO: jack@suse.com X-SENDER-IP: 113.57.152.160 X-ATTACHMENT-NUM: 0 X-System-Flag: 0 From: lianzhi chang To: 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: Tue, 12 Jan 2021 13:53:04 +0800 Message-Id: <20210112055304.31842-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 | 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 -- 2.20.1