public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Sungjong Seo" <sj1557.seo@samsung.com>
To: "'dongliang cui'" <cuidongliang390@gmail.com>
Cc: "'Dongliang Cui'" <dongliang.cui@unisoc.com>,
	<linkinjeon@kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <niuzhiguo84@gmail.com>,
	<hao_hao.wang@unisoc.com>, <ke.wang@unisoc.com>,
	"'Zhiguo	Niu'" <zhiguo.niu@unisoc.com>, <sj1557.seo@samsung.com>
Subject: RE: [PATCH v2] exfat: check disk status during buffer write
Date: Wed, 24 Jul 2024 16:50:06 +0900	[thread overview]
Message-ID: <162ee01dadd9e$19cbaa40$4d62fec0$@samsung.com> (raw)
In-Reply-To: <CAPqOJe3mdz_heMQe09uZTf-E40ZBTMDuf49jE+hd10qYOjURmg@mail.gmail.com>

> On Wed, Jul 24, 2024 at 3:03 PM Sungjong Seo <sj1557.seo@samsung.com>
> wrote:
> >
[snip]
> > >
> > > +static int exfat_block_device_ejected(struct super_block *sb)
> > > +{
> > > +     struct backing_dev_info *bdi = sb->s_bdi;
> > > +
> > > +     return bdi->dev == NULL;
> > > +}
> > Have you tested with this again?
> Yes, I tested it in this way. The user side can receive the -ENODEV error
> after the device is ejected.
> dongliang.cui@deivice:/data/tmp # dd if=/dev/zero of=test.img bs=1M
> count=10240
> dd: test.img: write error: No such device
> 1274+0 records in
> 1273+1 records out
> 1335635968 bytes (1.2 G) copied, 8.060 s, 158 M/s
Oops!, write() seems to return ENODEV that man page does not have.
In exfat_map_cluster, it was necessary to distinguish and return error
values, but now that explicitly differentiated error messages will be
printed. So, why not return EIO again? It seem appropriate to return EIO
instead of ENODEV from the read/write syscall.

> 
> >
> > > +
> > >  static int exfat_get_block(struct inode *inode, sector_t iblock,
> > >               struct buffer_head *bh_result, int create)
> > >  {
> > > @@ -290,6 +298,9 @@ static int exfat_get_block(struct inode *inode,
> > > sector_t iblock,
> > >       sector_t valid_blks;
> > >       loff_t pos;
> > >
> > > +     if (exfat_block_device_ejected(sb))
> > This looks better than the modified location in the last patch.
> > However, the caller of this function may not be interested in exfat
> > error handling, so here we should call exfat_fs_error_ratelimit()
> > with an appropriate error message.
> Thank you for the reminder. I will make the changes in the next version.
Sounds good!

> 
> >
> > > +             return -ENODEV;
> > > +
> > >       mutex_lock(&sbi->s_lock);
> > >       last_block = EXFAT_B_TO_BLK_ROUND_UP(i_size_read(inode), sb);
> > >       if (iblock >= last_block && !create)
> > > --
> > > 2.25.1
> >
> >



  reply	other threads:[~2024-07-24  7:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20240723105423epcas1p4d4ee53975fbc4644e969b5c9b7514c9b@epcas1p4.samsung.com>
2024-07-23 10:54 ` [PATCH v2] exfat: check disk status during buffer write Dongliang Cui
2024-07-24  7:03   ` Sungjong Seo
2024-07-24  7:24     ` dongliang cui
2024-07-24  7:50       ` Sungjong Seo [this message]
2024-07-24  8:27         ` dongliang cui
2024-07-24 13:07   ` Christoph Hellwig
2024-07-25  6:00     ` Sungjong Seo
2024-07-26  6:18       ` dongliang cui

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='162ee01dadd9e$19cbaa40$4d62fec0$@samsung.com' \
    --to=sj1557.seo@samsung.com \
    --cc=cuidongliang390@gmail.com \
    --cc=dongliang.cui@unisoc.com \
    --cc=hao_hao.wang@unisoc.com \
    --cc=ke.wang@unisoc.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=niuzhiguo84@gmail.com \
    --cc=zhiguo.niu@unisoc.com \
    /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