linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Hannes Reinecke <hare@suse.de>, Jens Axboe <axboe@kernel.dk>,
	Tejun Heo <tj@kernel.org>,
	mwilck@suse.com
Cc: James Bottomley <jejb@linux.vnet.ibm.com>,
	Christoph Hellwig <hch@lst.de>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Bart Van Assche <Bart.VanAssche@sandisk.com>,
	linux-block@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/4] block: disk_events: introduce event flags
Date: Mon, 28 Jan 2019 14:54:34 +0100	[thread overview]
Message-ID: <8ae008d68e4c532af57a5065a9ff96280e81e309.camel@suse.com> (raw)
In-Reply-To: <be93f1f5-cb79-04b2-5fc1-140678245197@suse.de>

On Sat, 2019-01-26 at 11:09 +0100, Hannes Reinecke wrote:
> On 1/18/19 10:32 PM, Martin Wilck wrote:
> > Currently, an empty disk->events field tells the block layer not to
> > forward
> > media change events to user space. This was done in commit
> > 7c88a168da80 ("block:
> > don't propagate unlisted DISK_EVENTs to userland") in order to
> > avoid events
> > from "fringe" drivers to be forwarded to user space. By doing so,
> > the block
> > layer lost the information which events were supported by a
> > particular
> > block device, and most importantly, whether or not a given device
> > supports
> > media change events at all.
> > 
> > Prepare for not interpreting the "events" field this way in the
> > future any
> > more. This is done by adding two flag bits that can be set to have
> > the
> > device treated like one that has the "events" field set to a non-
> > zero value
> > before. This applies only to the sd and sr drivers, which are
> > changed to
> > set the new flags.
> > 
> > The new flags are DISK_EVENT_FLAG_POLL to enforce polling of the
> > device for
> > synchronous events, and DISK_EVENT_FLAG_UEVENT to tell the
> > blocklayer to
> > generate udev events from kernel events. They can easily be fit in
> > the int
> > reserved for event bits.
> > 
> > This patch doesn't change behavior.
> > 
> > Signed-off-by: Martin Wilck <mwilck@suse.com>
> > ---
> >   block/genhd.c         | 22 ++++++++++++++++------
> >   drivers/scsi/sd.c     |  3 ++-
> >   drivers/scsi/sr.c     |  3 ++-
> >   include/linux/genhd.h |  7 +++++++
> >   4 files changed, 27 insertions(+), 8 deletions(-)
> > 
> > diff --git a/block/genhd.c b/block/genhd.c
> > index 1dd8fd6..bcd16f6 100644
> > --- a/block/genhd.c
> > +++ b/block/genhd.c
> > @@ -1631,7 +1631,8 @@ static unsigned long
> > disk_events_poll_jiffies(struct gendisk *disk)
> >   	 */
> >   	if (ev->poll_msecs >= 0)
> >   		intv_msecs = ev->poll_msecs;
> > -	else if (disk->events & ~disk->async_events)
> > +	else if (disk->events & DISK_EVENT_FLAG_POLL
> > +		 && disk->events & ~disk->async_events)
> >   		intv_msecs = disk_events_dfl_poll_msecs;
> >   
> >   	return msecs_to_jiffies(intv_msecs);
> Hmm. That is an ... odd condition.
> Clearly it's pointless to have the event bit set in the ->events mask
> if 
> it's already part of the ->async_events mask.

The "events" bit has to be set in that case. "async_events" is defined
as a subset of "events", see genhd.h. You can trivially verify that
this is currently true, as NO driver that sets any bit in the
"async_events" field. I was wondering if "async_events" can't be
ditched completely, but I didn't want to make that aggressive a change
in this patch set.

> But shouldn't we better _prevent_ this from happening, ie refuse to
> set
> DISK_EVENT_FLAG_POLL in events if it's already in ->async_events?
> Then the above check would be simplified.

Asynchronous events need not be polled for, therefore setting the POLL
flag in async_events makes no sense. My intention was to use these
"flag" bits in the "events" field only. Perhaps I should have expressed
that more clearly?

Anyway, unless I'm really blind, the condition above is actually the
same as before, just that I now require the POLL flag to be set as
well, which is the main point of the patch.

Regards
Martin


> 
> Cheers,
> 
> Hannes
> 

-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)



  reply	other threads:[~2019-01-28 13:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 21:32 [PATCH 0/4] block: skip media change event handling if unsupported Martin Wilck
2019-01-18 21:32 ` [PATCH 1/4] block: disk_events: introduce event flags Martin Wilck
2019-01-26 10:09   ` Hannes Reinecke
2019-01-28 13:54     ` Martin Wilck [this message]
2019-02-01 15:12       ` Martin Wilck
2019-01-18 21:32 ` [PATCH 2/4] Revert "ide: unexport DISK_EVENT_MEDIA_CHANGE for ide-gd and ide-cd" Martin Wilck
2019-01-26 10:10   ` Hannes Reinecke
2019-01-18 21:32 ` [PATCH 3/4] Revert "block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe drivers" Martin Wilck
2019-01-26 10:11   ` Hannes Reinecke
2019-01-18 21:32 ` [PATCH 4/4] block: check_events: don't bother with events if unsupported Martin Wilck
2019-01-26 10:15   ` Hannes Reinecke

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=8ae008d68e4c532af57a5065a9ff96280e81e309.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=Bart.VanAssche@sandisk.com \
    --cc=axboe@kernel.dk \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=tj@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).