linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Magnani <magnani@ieee.org>
To: 常廉志 <changlianzhi@uniontech.com>
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: Wed, 13 Jan 2021 21:21:14 -0600	[thread overview]
Message-ID: <25d238d333d16079d4cc992c8dc0ff94@ieee.org> (raw)
In-Reply-To: <1400033179.660265.1610592703732.JavaMail.xmail@bj-wm-cp-9>

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!
                                   Earthling, return my space modulator!"
  #include <standard.disclaimer>

  parent reply	other threads:[~2021-01-14  3:22 UTC|newest]

Thread overview: 9+ 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 [this message]
2021-01-13 22:25       ` changlianzhi
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 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=25d238d333d16079d4cc992c8dc0ff94@ieee.org \
    --to=magnani@ieee.org \
    --cc=282827961@qq.com \
    --cc=changlianzhi@uniontech.com \
    --cc=jack@suse.com \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).