All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com>
To: Song Liu <song@kernel.org>,
	"heming.zhao@suse.com" <heming.zhao@suse.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"lidong.zhong@suse.com" <lidong.zhong@suse.com>,
	"xni@redhat.com" <xni@redhat.com>,
	"colyli@suse.com" <colyli@suse.com>,
	Martin Petersen <martin.petersen@oracle.com>
Subject: RE: [PATCH] md/bitmap: wait for bitmap writes to complete during the tear down sequence
Date: Mon, 12 Apr 2021 09:38:27 +0000	[thread overview]
Message-ID: <CY4PR10MB200755C47FFA2EA54F82E8DCFD709@CY4PR10MB2007.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CAPhsuW4S-FERHGfj6ENC3K70+9tMsupWVmc9yhLoLWB6qX0jMA@mail.gmail.com>

> > In my opinion, using a special wait is more clear than calling general md_bitmap_wait_writes(). the md_bitmap_wait_writes makes people
> feel bitmap module does repetitive clean job.
> >
> > My idea like:
> > ```
> > diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
> > index 200c5d0f08bf..ea6fa5a2cb6b 100644
> > --- a/drivers/md/md-bitmap.c
> > +++ b/drivers/md/md-bitmap.c
> > @@ -1723,6 +1723,8 @@ void md_bitmap_flush(struct mddev *mddev)
> >          bitmap->daemon_lastrun -= sleep;
> >          md_bitmap_daemon_work(mddev);
> >          md_bitmap_update_sb(bitmap);
> > +       if (mddev->bitmap_info.external)
> > +               md_super_wait(mddev);

Agreed. This looks much cleaner.

> >   }
> >
> >   /*
> > @@ -1746,6 +1748,7 @@ void md_bitmap_free(struct bitmap *bitmap)
> >          /* Shouldn't be needed - but just in case.... */
> >          wait_event(bitmap->write_wait,
> >                     atomic_read(&bitmap->pending_writes) == 0);
> > +       wait_event(mddev->sb_wait, atomic_read(&mddev->pending_writes)==0);

I think this call looks redundant as this wait is already covered by md_update_sb() for non-external bitmaps and the proposed change in md_bitmap_flush() for external bitmaps. So, can we omit this change? 

> >
> >          /* release the bitmap file  */
> >          md_bitmap_file_unmap(&bitmap->storage);
> > ```
> 
> I like Heming's version better.
> 
> Hi Sudhakar,
> 
> Are you able to reproduce the issue? If so, could you please verify
> that Heming's
> change fixes the issue?

Hi Song, Heming,

Please review my comments above. I can try to reproduce the issue with the fix once we agree on the final fix.

Thanks
Sudhakar

> 
> Thanks,
> Song

  reply	other threads:[~2021-04-12  9:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08 21:39 [PATCH] md/bitmap: wait for bitmap writes to complete during the tear down sequence Sudhakar Panneerselvam
2021-04-10 15:27 ` heming.zhao
2021-04-10 21:35   ` Sudhakar Panneerselvam
2021-04-11  9:04     ` heming.zhao
2021-04-12  6:06       ` Song Liu
2021-04-12  9:38         ` Sudhakar Panneerselvam [this message]
2021-04-12  9:59           ` heming.zhao
2021-04-13  0:17             ` Sudhakar Panneerselvam

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=CY4PR10MB200755C47FFA2EA54F82E8DCFD709@CY4PR10MB2007.namprd10.prod.outlook.com \
    --to=sudhakar.panneerselvam@oracle.com \
    --cc=colyli@suse.com \
    --cc=heming.zhao@suse.com \
    --cc=lidong.zhong@suse.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=song@kernel.org \
    --cc=xni@redhat.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 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.