All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	Janosch Frank <frankja@linux.ibm.com>,
	Marc Hartmayer <mhartmay@linux.ibm.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 1/1] virtio/s390: fix race on airq_areas[]
Date: Wed, 24 Jul 2019 13:17:37 +0200	[thread overview]
Message-ID: <20190724131737.24347915.pasic@linux.ibm.com> (raw)
In-Reply-To: <4a6d82b5-db9d-ed2e-2d07-e14aee3884af@de.ibm.com>

On Wed, 24 Jul 2019 10:39:13 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> 
> 
> On 24.07.19 10:34, Cornelia Huck wrote:
> > On Wed, 24 Jul 2019 08:44:19 +0200
> > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> > 
> >> On 24.07.19 00:58, Halil Pasic wrote:
> >>> The access to airq_areas was racy ever since the adapter interrupts got
> >>> introduced to virtio-ccw, but since commit 39c7dcb15892 ("virtio/s390:
> >>> make airq summary indicators DMA") this became an issue in practice as
> >>> well. Namely before that commit the airq_info that got overwritten was
> >>> still functional. After that commit however the two infos share a
> >>> summary_indicator, which aggravates the situation. Which means
> >>> auto-online mechanism occasionally hangs the boot with virtio_blk.
> >>>
> >>> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> >>> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
> >>> Fixes: 96b14536d935 ("virtio-ccw: virtio-ccw adapter interrupt support.")
> >>> ---
> >>> * We need definitely this fixed for 5.3. For older stable kernels it is
> >>> to be discussed. @Connie what do you think: do we need a cc stable?  
> >>
> >> Unless you can prove that the problem could never happen on old version
> >> we absolutely do need cc stable. 
> > 
> > Yes, this needs to be cc:stable.
> > 
> >>
> >>>
> >>> * I have a variant that does not need the extra mutex but uses cmpxchg().
> >>> Decided to post this one because that one is more complex. But if there
> >>> is interest we can have a look at it as well.  
> >>
> >> This is slow path (startup) and never called in hot path. Correct? Mutex should be
> >> fine.
> > 
> > Yes, this is ultimately called through the ->probe functions of virtio
> > drivers.
> > 
> >>> ---
> >>>  drivers/s390/virtio/virtio_ccw.c | 4 ++++
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c
> >>> index 1a55e5942d36..d97742662755 100644
> >>> --- a/drivers/s390/virtio/virtio_ccw.c
> >>> +++ b/drivers/s390/virtio/virtio_ccw.c
> >>> @@ -145,6 +145,8 @@ struct airq_info {
> >>>  	struct airq_iv *aiv;
> >>>  };
> >>>  static struct airq_info *airq_areas[MAX_AIRQ_AREAS];
> >>> +DEFINE_MUTEX(airq_areas_lock);
> >>> +
> >>>  static u8 *summary_indicators;
> >>>  
> >>>  static inline u8 *get_summary_indicator(struct airq_info *info)
> >>> @@ -265,9 +267,11 @@ static unsigned long get_airq_indicator(struct virtqueue *vqs[], int nvqs,
> >>>  	unsigned long bit, flags;
> >>>  
> >>>  	for (i = 0; i < MAX_AIRQ_AREAS && !indicator_addr; i++) {
> >>> +		mutex_lock(&airq_areas_lock);
> >>>  		if (!airq_areas[i])
> >>>  			airq_areas[i] = new_airq_info(i);
> >>>  		info = airq_areas[i];
> >>> +		mutex_unlock(&airq_areas_lock);
> >>>  		if (!info)
> >>>  			return 0;
> >>>  		write_lock_irqsave(&info->lock, flags);
> >>>   
> >>
> > 
> > Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> > 
> > Should I pick this and send a pull request, or is it quicker to just
> > take this directly?
> 
> I think we can you did via a fast path. Halil, can you push to the s390 tree?

Sure!

Regards,
Halil

> 

WARNING: multiple messages have this Message-ID (diff)
From: Halil Pasic <pasic@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-s390@vger.kernel.org, Janosch Frank <frankja@linux.ibm.com>,
	kvm@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
	virtualization@lists.linux-foundation.org,
	Marc Hartmayer <mhartmay@linux.ibm.com>
Subject: Re: [PATCH 1/1] virtio/s390: fix race on airq_areas[]
Date: Wed, 24 Jul 2019 13:17:37 +0200	[thread overview]
Message-ID: <20190724131737.24347915.pasic@linux.ibm.com> (raw)
In-Reply-To: <4a6d82b5-db9d-ed2e-2d07-e14aee3884af@de.ibm.com>

On Wed, 24 Jul 2019 10:39:13 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> 
> 
> On 24.07.19 10:34, Cornelia Huck wrote:
> > On Wed, 24 Jul 2019 08:44:19 +0200
> > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> > 
> >> On 24.07.19 00:58, Halil Pasic wrote:
> >>> The access to airq_areas was racy ever since the adapter interrupts got
> >>> introduced to virtio-ccw, but since commit 39c7dcb15892 ("virtio/s390:
> >>> make airq summary indicators DMA") this became an issue in practice as
> >>> well. Namely before that commit the airq_info that got overwritten was
> >>> still functional. After that commit however the two infos share a
> >>> summary_indicator, which aggravates the situation. Which means
> >>> auto-online mechanism occasionally hangs the boot with virtio_blk.
> >>>
> >>> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> >>> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
> >>> Fixes: 96b14536d935 ("virtio-ccw: virtio-ccw adapter interrupt support.")
> >>> ---
> >>> * We need definitely this fixed for 5.3. For older stable kernels it is
> >>> to be discussed. @Connie what do you think: do we need a cc stable?  
> >>
> >> Unless you can prove that the problem could never happen on old version
> >> we absolutely do need cc stable. 
> > 
> > Yes, this needs to be cc:stable.
> > 
> >>
> >>>
> >>> * I have a variant that does not need the extra mutex but uses cmpxchg().
> >>> Decided to post this one because that one is more complex. But if there
> >>> is interest we can have a look at it as well.  
> >>
> >> This is slow path (startup) and never called in hot path. Correct? Mutex should be
> >> fine.
> > 
> > Yes, this is ultimately called through the ->probe functions of virtio
> > drivers.
> > 
> >>> ---
> >>>  drivers/s390/virtio/virtio_ccw.c | 4 ++++
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c
> >>> index 1a55e5942d36..d97742662755 100644
> >>> --- a/drivers/s390/virtio/virtio_ccw.c
> >>> +++ b/drivers/s390/virtio/virtio_ccw.c
> >>> @@ -145,6 +145,8 @@ struct airq_info {
> >>>  	struct airq_iv *aiv;
> >>>  };
> >>>  static struct airq_info *airq_areas[MAX_AIRQ_AREAS];
> >>> +DEFINE_MUTEX(airq_areas_lock);
> >>> +
> >>>  static u8 *summary_indicators;
> >>>  
> >>>  static inline u8 *get_summary_indicator(struct airq_info *info)
> >>> @@ -265,9 +267,11 @@ static unsigned long get_airq_indicator(struct virtqueue *vqs[], int nvqs,
> >>>  	unsigned long bit, flags;
> >>>  
> >>>  	for (i = 0; i < MAX_AIRQ_AREAS && !indicator_addr; i++) {
> >>> +		mutex_lock(&airq_areas_lock);
> >>>  		if (!airq_areas[i])
> >>>  			airq_areas[i] = new_airq_info(i);
> >>>  		info = airq_areas[i];
> >>> +		mutex_unlock(&airq_areas_lock);
> >>>  		if (!info)
> >>>  			return 0;
> >>>  		write_lock_irqsave(&info->lock, flags);
> >>>   
> >>
> > 
> > Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> > 
> > Should I pick this and send a pull request, or is it quicker to just
> > take this directly?
> 
> I think we can you did via a fast path. Halil, can you push to the s390 tree?

Sure!

Regards,
Halil

> 

  reply	other threads:[~2019-07-24 11:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-23 22:58 [PATCH 1/1] virtio/s390: fix race on airq_areas[] Halil Pasic
2019-07-23 22:58 ` Halil Pasic
2019-07-24  6:44 ` Christian Borntraeger
2019-07-24  6:44   ` Christian Borntraeger
2019-07-24  8:34   ` Cornelia Huck
2019-07-24  8:34     ` Cornelia Huck
2019-07-24  8:39     ` Christian Borntraeger
2019-07-24  8:39       ` Christian Borntraeger
2019-07-24 11:17       ` Halil Pasic [this message]
2019-07-24 11:17         ` Halil Pasic
2019-07-24 11:01   ` Halil Pasic
2019-07-24 11:01   ` Halil Pasic

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=20190724131737.24347915.pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mhartmay@linux.ibm.com \
    --cc=virtualization@lists.linux-foundation.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.