All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: eric.auger.pro@gmail.com, m.szyprowski@samsung.com,
	robin.murphy@arm.com, mst@redhat.com, jasowang@redhat.com,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dma-mapping: Protect dma_addressing_limited against NULL dma_mask
Date: Mon, 22 Jul 2019 17:46:00 +0200	[thread overview]
Message-ID: <e1e02286-ccf9-3335-28c8-0c6b122b05a1@redhat.com> (raw)
In-Reply-To: <20190722152637.GA3780@lst.de>

Hi Christoph,

On 7/22/19 5:26 PM, Christoph Hellwig wrote:
>>  static inline bool dma_addressing_limited(struct device *dev)
>>  {
>> -	return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) <
>> -		dma_get_required_mask(dev);
>> +	return WARN_ON_ONCE(!dev->dma_mask) ? false :
>> +		min_not_zero(*dev->dma_mask, dev->bus_dma_mask) <
>> +			dma_get_required_mask(dev);
> 
> This should really use a separate if statement, but I can fix that
> up when applying it.
> 
Just wondering why we don't use the dma_get_mask() accessor which
returns DMA_BIT_MASK(32) in case the dma_mask is not set.

Do you foresee any issue and would it still mandate to add dma_mask
checks on each call sites?

Thanks

Eric

WARNING: multiple messages have this Message-ID (diff)
From: Auger Eric <eric.auger@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: mst@redhat.com, jasowang@redhat.com,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	iommu@lists.linux-foundation.org, eric.auger.pro@gmail.com,
	robin.murphy@arm.com
Subject: Re: [PATCH 1/2] dma-mapping: Protect dma_addressing_limited against NULL dma_mask
Date: Mon, 22 Jul 2019 17:46:00 +0200	[thread overview]
Message-ID: <e1e02286-ccf9-3335-28c8-0c6b122b05a1@redhat.com> (raw)
In-Reply-To: <20190722152637.GA3780@lst.de>

Hi Christoph,

On 7/22/19 5:26 PM, Christoph Hellwig wrote:
>>  static inline bool dma_addressing_limited(struct device *dev)
>>  {
>> -	return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) <
>> -		dma_get_required_mask(dev);
>> +	return WARN_ON_ONCE(!dev->dma_mask) ? false :
>> +		min_not_zero(*dev->dma_mask, dev->bus_dma_mask) <
>> +			dma_get_required_mask(dev);
> 
> This should really use a separate if statement, but I can fix that
> up when applying it.
> 
Just wondering why we don't use the dma_get_mask() accessor which
returns DMA_BIT_MASK(32) in case the dma_mask is not set.

Do you foresee any issue and would it still mandate to add dma_mask
checks on each call sites?

Thanks

Eric
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2019-07-22 15:46 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22 14:55 [PATCH 0/2] Fix NULL pointer dereference with virtio-blk-pci and virtual IOMMU Eric Auger
2019-07-22 14:55 ` Eric Auger
2019-07-22 14:55 ` [PATCH 1/2] dma-mapping: Protect dma_addressing_limited against NULL dma_mask Eric Auger
2019-07-22 14:55   ` Eric Auger
2019-07-22 15:26   ` Christoph Hellwig
2019-07-22 15:26     ` Christoph Hellwig
2019-07-22 15:46     ` Auger Eric [this message]
2019-07-22 15:46       ` Auger Eric
2019-07-22 15:46     ` Auger Eric
2019-07-22 15:26   ` Christoph Hellwig
2019-07-22 14:55 ` Eric Auger
2019-07-22 14:55 ` [PATCH 2/2] virtio/virtio_ring: Fix the dma_max_mapping_size call Eric Auger
2019-07-22 14:55 ` Eric Auger
2019-07-22 14:55   ` Eric Auger
2019-07-22 15:27   ` Christoph Hellwig
2019-07-22 15:27     ` Christoph Hellwig
2019-07-22 15:39     ` Michael S. Tsirkin
2019-07-22 15:39       ` Michael S. Tsirkin
2019-07-22 15:39     ` Michael S. Tsirkin
2019-07-22 15:27   ` Christoph Hellwig
2019-07-22 15:33   ` Michael S. Tsirkin
2019-07-22 15:33   ` Michael S. Tsirkin
2019-07-22 15:33     ` Michael S. Tsirkin
2019-07-23 15:38     ` Christoph Hellwig
2019-07-23 15:38       ` Christoph Hellwig
2019-07-23 15:47       ` Michael S. Tsirkin
2019-07-23 15:47       ` Michael S. Tsirkin
2019-07-23 15:47         ` Michael S. Tsirkin
2019-07-23 15:38     ` Christoph Hellwig
2019-07-22 15:36   ` Robin Murphy
2019-07-22 15:36   ` Robin Murphy
2019-07-22 15:36     ` Robin Murphy
2019-07-22 15:45     ` Michael S. Tsirkin
2019-07-22 15:45       ` Michael S. Tsirkin
2019-07-22 15:45     ` Michael S. Tsirkin
2019-07-23 15:38     ` Christoph Hellwig
2019-07-23 15:38       ` Christoph Hellwig
2019-07-23 15:38       ` Christoph Hellwig
2019-07-24 22:10       ` Michael S. Tsirkin
2019-07-24 22:10       ` Michael S. Tsirkin
2019-07-24 22:10         ` Michael S. Tsirkin
2019-07-25  5:25         ` Christoph Hellwig
2019-07-25  5:25         ` Christoph Hellwig
2019-07-25  5:25           ` Christoph Hellwig
2019-07-25 11:53       ` Auger Eric
2019-07-25 11:53         ` Auger Eric
2019-07-25 13:04         ` Christoph Hellwig
2019-07-25 13:04         ` Christoph Hellwig
2019-07-25 13:04           ` Christoph Hellwig
2019-07-25 16:32           ` Auger Eric
2019-07-25 16:32           ` Auger Eric
2019-07-25 16:32             ` Auger Eric
2019-07-25 11:53       ` Auger Eric

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=e1e02286-ccf9-3335-28c8-0c6b122b05a1@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mst@redhat.com \
    --cc=robin.murphy@arm.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.