From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Robert Beckett <bob.beckett@collabora.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
kernel@collabora.com,
Thomas Hellstrom <thomas.hellstrom@intel.com>,
Matthew Auld <matthew.auld@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/i915: stop using swiotlb
Date: Fri, 22 Jul 2022 11:13:59 +0100 [thread overview]
Message-ID: <a71371c5-8b56-a8a6-64eb-180180edfb89@linux.intel.com> (raw)
In-Reply-To: <20220722095859.GB14113@lst.de>
On 22/07/2022 10:58, Christoph Hellwig wrote:
> On Fri, Jul 22, 2022 at 10:45:54AM +0100, Tvrtko Ursulin wrote:
>>> - unsigned int size = swiotlb_max_segment();
>>> -
>>> - if (size == 0)
>>> - size = UINT_MAX;
>>
>> On a more detailed look, there was a CI failure which makes me think this
>> cap might need to stay. Because max sg segment is unsigned int. So I wonder
>> if sg contstruction overflows without it.
>>
>> If this quick analysis is right, you could leave i915_sg_segment_size
>> helper and cap the return from dma_max_mapping_size to UINT_MAX in it.
>
> As dma_max_mapping_size retuns a size_t it would be good to make
> all variables using it a size_t as well. In places where that gets
> lower to an unsigned int your probably want this cap.
Yep. Problem we have is struct scatterlist length field, which is
unsigned int, since all our backing storage handling is built on top of
it. Therefore I think capping in this helper should be good.
Regards,
Tvrtko
next prev parent reply other threads:[~2022-07-22 10:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-21 17:43 [PATCH] drm/i915: stop using swiotlb Robert Beckett
2022-07-22 9:13 ` Tvrtko Ursulin
2022-07-22 10:00 ` Christoph Hellwig
2022-07-22 9:45 ` Tvrtko Ursulin
2022-07-22 9:58 ` Christoph Hellwig
2022-07-22 10:13 ` Tvrtko Ursulin [this message]
2022-07-22 9:57 ` Christoph Hellwig
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=a71371c5-8b56-a8a6-64eb-180180edfb89@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=airlied@linux.ie \
--cc=bob.beckett@collabora.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.auld@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox