All of lore.kernel.org
 help / color / mirror / Atom feed
From: "changlianzhi@uniontech.com" <changlianzhi@uniontech.com>
To: magnani <magnani@ieee.org>
Cc: jack <jack@suse.com>, linux-kernel <linux-kernel@vger.kernel.org>,
	282827961 <282827961@qq.com>
Subject: Re: [PATCH] udf: fix the problem that the disc content is not displayed
Date: Thu, 14 Jan 2021 06:25:57 +0800	[thread overview]
Message-ID: <202101140625555106736@uniontech.com> (raw)
In-Reply-To: 25d238d333d16079d4cc992c8dc0ff94@ieee.org

On 2021-01-13 20:51, 常廉志 wrote:

>> On 2021-01-11 23:53, 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
>>> l>ogic, 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 <changlianzhi@uniontech.com>
>>>> ---
>>>> 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
>>>
>>>
>>> Looks good. Perhaps consider factoring out the conversion (which also
>>> occurs
>>> earlier in the function) so that the complexity of this "else if" can
>>> be
>>> reduced?
>>>
>>
>>> Reviewed-by: Steven J. Magnani <magnani@xxxxxxxx>
>>
>> Thank you very much! So, which one of the following methods do you
>> think is better:
>>
>> (1) Change the type of s_session in struct udf_sb_info to __s64. If you
>> modify this way, it may involve some memory copy problems of the
>> structure, and there are more modifications.
>>
>> (2) Definition: loff_t sector_offset=sbi->s_session <<
>> sb->s_blocksize_bits, and then put sector_offset into the "else if"
>> statement.
>>
>> (3) Or is there any other better way?

>I had #2 in mind.
>------------------------------------------------------------------------
>  Steven J. Magnani               "I claim this network for MARS!

Thank you very much for your suggestion, I will submit a new patch



  reply	other threads:[~2021-01-14  6:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12  5:53 [PATCH] udf: fix the problem that the disc content is not displayed lianzhi chang
2021-01-13 12:51 ` Steve Magnani
     [not found]   ` <1400033179.660265.1610592703732.JavaMail.xmail@bj-wm-cp-9>
2021-01-14  3:21     ` Steve Magnani
2021-01-13 22:25       ` changlianzhi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-01-14  7:57 lianzhi chang
2021-01-14 10:41 ` Jan Kara
2021-01-14 11:06 ` kernel test robot
2021-01-14 11:06   ` kernel test robot
2021-01-14 13:26 lianzhi chang
2021-01-14 17:15 ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202101140625555106736@uniontech.com \
    --to=changlianzhi@uniontech.com \
    --cc=282827961@qq.com \
    --cc=jack@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnani@ieee.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.