All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Dalessandro <dennis.dalessandro@intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Doug Ledford <dledford@redhat.com>,
	linux-rdma@vger.kernel.org,
	"Michael J. Ruhl" <michael.j.ruhl@intel.com>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	stable@vger.kernel.org, Kaike Wan <kaike.wan@intel.com>
Subject: Re: [PATCH for-rc 0/2] IB/hfi1: Fixes for rc or next if too late
Date: Thu, 31 May 2018 16:29:55 -0400	[thread overview]
Message-ID: <471e8387-77bc-35e6-1cc5-e30d27cae2d7@intel.com> (raw)
In-Reply-To: <20180531202109.GE4485@ziepe.ca>

On 5/31/2018 4:21 PM, Jason Gunthorpe wrote:
> On Thu, May 31, 2018 at 03:08:56PM -0400, Dennis Dalessandro wrote:
>> On 5/31/2018 2:47 PM, Doug Ledford wrote:
>>> On Thu, 2018-05-31 at 11:29 -0700, Dennis Dalessandro wrote:
>>>> Hi Doug and Jason,
>>>>
>>>> We have two more late breaking fix up patches. The DMA_RTAIL fix is the more
>>>> serious of the two. I realize we are at the tail end of 4.17 so I would not be
>>>> against holding off till 4.18 for these, but if there is another rdma
>>>> pull request we may want to tack these on.
>>>>
>>>>
>>>> Kaike Wan (1):
>>>>        IB/hfi1: Ensure VL index is within bounds
>>>>
>>>> Mike Marciniszyn (1):
>>>>        IB/hfi1: Fix user context tail allocation for DMA_RTAIL
>>>>
>>>>
>>>>   drivers/infiniband/hw/hfi1/chip.c     |    8 ++++----
>>>>   drivers/infiniband/hw/hfi1/file_ops.c |    2 +-
>>>>   drivers/infiniband/hw/hfi1/init.c     |    9 ++++-----
>>>>   drivers/infiniband/hw/hfi1/sdma.c     |   12 +++---------
>>>>   4 files changed, 12 insertions(+), 19 deletions(-)
>>>>
>>>
>>> Hi Denny,
>>>
>>> These two patches look fine in terms of the patches themselves.  In
>>> terms of whether to put them in for-rc or for-next, what's the
>>> consequences of hitting each of these bugs?
>>>
>>
>> The VL index, could be bad because it would jump beyond the end of the
>> array. However, we won't actually hit that with the code the way it
>> currently is because of the way we validate the VL in other areas of the
>> code. This is more of a we better fix it before we do end up with a problem
>> sort of thing.
> 
> Theoretical future bugs are not rc or stable material

The VL index one is not marked as stable, however the other one is. That 
is because it is a real bug, as Mike said to me earlier, we provide the 
tools to play, the concern is if someone does. So I think it meets 
stable bar, but not necessarily this late of an -rc.

>> In the other one, the DMA_RTAIL one, the driver ends up mmaping NULL and
>> handing that user space. This only happens though if users muck with the
>> CAP_MASK and enable the dma of the rtail. Which is not the default. Mike
>> found this through code inspection I believe.
> 
>> So they do fix serious flaws, but the likelihood of actually hitting them is
>> very slim. Based on the stable tag on Mike's patch we have had this since
>> 4.9.
> 
> I think it is too late for more -rc stuff..
> 
> The last -rc (assuming rc7 is the end) pull request needs to go
> tomorrow morning and we like it to have -rc stuff sit in -next for at
> least a day before sending to Linus :\

Agree, and fine with me.

-Denny

  reply	other threads:[~2018-05-31 20:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-31 18:29 [PATCH for-rc 0/2] IB/hfi1: Fixes for rc or next if too late Dennis Dalessandro
2018-05-31 18:29 ` Dennis Dalessandro
2018-05-31 18:30 ` [PATCH for-rc 1/2] IB/hfi1: Fix user context tail allocation for DMA_RTAIL Dennis Dalessandro
2018-05-31 18:47 ` [PATCH for-rc 0/2] IB/hfi1: Fixes for rc or next if too late Doug Ledford
2018-05-31 19:08   ` Dennis Dalessandro
2018-05-31 20:21     ` Jason Gunthorpe
2018-05-31 20:29       ` Dennis Dalessandro [this message]
2018-06-04 19:34 ` Jason Gunthorpe

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=471e8387-77bc-35e6-1cc5-e30d27cae2d7@intel.com \
    --to=dennis.dalessandro@intel.com \
    --cc=dledford@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=kaike.wan@intel.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michael.j.ruhl@intel.com \
    --cc=mike.marciniszyn@intel.com \
    --cc=stable@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 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.