On Mon, 1 Jul 2019 at 12:37, Yongxin Liu wrote:
>
> In nouveau_conn_reset(), if connector->state is true,
> __drm_atomic_helper_connector_destroy_state() will be called,
> but the memory pointed by asyc isn't freed. Memory leak happens
> in the following function
Currently nouveau_svm_fault expects nouveau_range_fault to never unlock
mmap_sem, but the latter unlocks it for a random selection of error
codes. Fix this up by always unlocking mmap_sem for non-zero return
values in nouveau_range_fault, and only unlocking it in the caller
for successful returns.
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which fixes up the mmap_sem
locking in nouveau and while at it also removes leftover legacy HMM APIs
only used by nouveau.
Changes since v1:
- don't return the valid state from hmm_range_unregister
- additional nouveau cleanups
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 34
These two functions are marked as a legacy APIs to get rid of, but seem
to suit the current nouveau flow. Move it to the only user in
preparation for fixing a locking bug involving caller and callee.
All comments referring to the old API have been removed as this now
is a driver private helper.
-EAGAIN has a magic meaning for non-blocking faults, so don't overload
it. Given that the caller doesn't check for specific error codes this
change is purely cosmetic.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
1 file changed, 1 insertion(+), 1
The parameter is always false, so remove it as well as the -EAGAIN
handling that can only happen for the non-blocking case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
On Wed, Jul 03, 2019 at 01:46:02PM -0700, Ralph Campbell wrote:
> You can delete the comment "With the old API the driver must ..."
> (not visible in the patch here).
Sure.
> I suggest moving the two assignments:
> range->default_flags = 0;
> range->pfn_flags_mask = -1UL;
> to just
On 7/3/19 11:45 AM, Christoph Hellwig wrote:
Currently nouveau_svm_fault expects nouveau_range_fault to never unlock
mmap_sem, but the latter unlocks it for a random selection of error
codes. Fix this up by always unlocking mmap_sem for non-zero return
values in nouveau_range_fault, and only
On Wed, Jul 03, 2019 at 10:28:57PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 03, 2019 at 07:00:50PM +, Jason Gunthorpe wrote:
> > I don't think the API should be encouraging some shortcut here..
> >
> > We can't do the above pattern because the old hmm_vma API didn't allow
> > it, which
DMA_ATTR_SKIP_CPU_SYNC should only be used when the driver manually
performs dma cache maintainance operations using the dma_sync_*
calls. Nouveau doesn't do that, and generally just assumes DMA
is coherent. Use plain dma_map_page which doesn't make this code
correct but at least a little less
On Wed, Jul 03, 2019 at 07:00:50PM +, Jason Gunthorpe wrote:
> I don't think the API should be encouraging some shortcut here..
>
> We can't do the above pattern because the old hmm_vma API didn't allow
> it, which is presumably a reason why it is obsolete.
>
> I'd rather see drivers move to
On 7/3/19 11:45 AM, Christoph Hellwig wrote:
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
https://bugs.freedesktop.org/show_bug.cgi?id=111044
JM9 changed:
What|Removed |Added
Assignee|nouveau@lists.freedesktop.o |ch...@chris-wilson.co.uk
|rg
https://bugs.freedesktop.org/show_bug.cgi?id=111044
--- Comment #9 from JM9 ---
Yes, on resume, I typically don't have the external monitors connected, so it
is the internal screen that displays the nouveau messages and appears to
freeze.
I'm using Wayland compositor (SwayWM:
https://bugs.freedesktop.org/show_bug.cgi?id=111044
--- Comment #8 from Ilia Mirkin ---
(In reply to JM9 from comment #7)
> ok, thanks. This is what it looks like with all the monitors connected:
>
> /sys/class/drm/card0-eDP-1/status:connected
> /sys/class/drm/card0-VGA-1/status:connected
>
On Wed, Jul 03, 2019 at 11:44:58AM -0700, Christoph Hellwig wrote:
> Checking range->valid is trivial and has no meaningful cost, but
> nicely simplifies the fastpath in typical callers.
It should not be the typical caller..
> hmm_vma_range_done function, which now is a trivial wrapper around
https://bugs.freedesktop.org/show_bug.cgi?id=111044
--- Comment #7 from JM9 ---
ok, thanks. This is what it looks like with all the monitors connected:
/sys/class/drm/card0-eDP-1/status:connected
/sys/class/drm/card0-VGA-1/status:connected
/sys/class/drm/card1-DP-1/status:connected
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which fixes up the mmap_sem
locking in nouveau and while at it also removes leftover legacy HMM APIs
only used by nouveau.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 34 --
2 files
hmm_vma_fault is marked as a legacy API to get rid of, but seems to suit
the current nouveau flow. Move it to the only user in preparation for
fixing a locking bug involving caller and callee.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
Checking range->valid is trivial and has no meaningful cost, but
nicely simplifies the fastpath in typical callers. Also remove the
hmm_vma_range_done function, which now is a trivial wrapper around
hmm_range_unregister.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
Currently nouveau_svm_fault expects nouveau_range_fault to never unlock
mmap_sem, but the latter unlocks it for a random selection of error
codes. Fix this up by always unlocking mmap_sem for non-zero return
values in nouveau_range_fault, and only unlocking it in the caller
for successful returns.
On Wed, Jul 03, 2019 at 08:03:08PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 03, 2019 at 03:01:25PM -0300, Jason Gunthorpe wrote:
> > Christoph, I guess you didn't mean to send this branch to the mailing
> > list?
> >
> > In any event some of these, like this one, look obvious and I could
> >
On Wed, Jul 03, 2019 at 08:05:25PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 03, 2019 at 03:03:56PM -0300, Jason Gunthorpe wrote:
> > I was thinking about doing exactly this too, but amdgpu started using
> > this already obsolete API in their latest driver :(
> >
> > So, we now need to get
On Wed, Jul 03, 2019 at 03:03:56PM -0300, Jason Gunthorpe wrote:
> I was thinking about doing exactly this too, but amdgpu started using
> this already obsolete API in their latest driver :(
>
> So, we now need to get both drivers to move to the modern API.
Actually the AMD folks fixed this up
On Mon, Jul 01, 2019 at 08:20:18AM +0200, Christoph Hellwig wrote:
> hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
> the current nouvea flow. Move it to the only user in preparation for
> fixing a locking bug involving caller and callee.
>
> Signed-off-by: Christoph
On Wed, Jul 03, 2019 at 03:01:25PM -0300, Jason Gunthorpe wrote:
> Christoph, I guess you didn't mean to send this branch to the mailing
> list?
>
> In any event some of these, like this one, look obvious and I could
> still grab a few for hmm.git.
>
> Let me know what you'd like please
>
>
On Mon, Jul 01, 2019 at 08:20:20AM +0200, Christoph Hellwig wrote:
> Switch the one remaining user in nouveau over to its replacement,
> and remove all the wrappers.
>
> Signed-off-by: Christoph Hellwig
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
> include/linux/hmm.h|
On Wed, Jul 3, 2019 at 1:49 PM Ralph Campbell wrote:
> On 6/30/19 11:20 PM, Christoph Hellwig wrote:
> > hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
> > the current nouvea flow. Move it to the only user in preparation for
>
> I didn't quite parse the phrase "quite
On 6/30/19 11:20 PM, Christoph Hellwig wrote:
hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
the current nouvea flow. Move it to the only user in preparation for
I didn't quite parse the phrase "quite suites the current nouvea flow."
s/nouvea/nouveau/
fixing a
On 6/30/19 11:20 PM, Christoph Hellwig wrote:
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by:
On 6/30/19 11:20 PM, Christoph Hellwig wrote:
Checking range->valid is trivial and has no meaningful cost, but
nicely simplifies the fastpath in typical callers. Also remove the
hmm_vma_range_done function, which now is a trivial wrapper around
hmm_range_unregister.
Signed-off-by: Christoph
https://bugs.freedesktop.org/show_bug.cgi?id=111044
--- Comment #6 from Ilia Mirkin ---
(In reply to JM9 from comment #5)
> I believe all screens (Display Ports) are wired to intel. If you think this
> is an intel issue, I can file a bug there, but the nouveau message threw me.
The error
https://bugs.freedesktop.org/show_bug.cgi?id=111044
--- Comment #5 from JM9 ---
I believe all screens (Display Ports) are wired to intel. If you think this is
an intel issue, I can file a bug there, but the nouveau message threw me.
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=110714
--- Comment #7 from Ilia Mirkin ---
(In reply to Peter Draganov from comment #5)
> @Ilia Mirkin
> Additionally you're not using xf86-video-nouveau. (If you were, you wouldn't
> be using glamor.)
> I am not sure about this, but here is the log
https://bugs.freedesktop.org/show_bug.cgi?id=110714
--- Comment #6 from Karol Herbst ---
(In reply to Peter Draganov from comment #4)
> The problem persists in xorg-x11-server-Xorg-1.20.5-3.fc30.x86_64:
>
> [113930.196] (EE) glamor0: GL error: GL_OUT_OF_MEMORY in glTexSubImage
> [113930.198]
https://bugs.freedesktop.org/show_bug.cgi?id=110714
--- Comment #5 from Peter Draganov ---
@Ilia Mirkin
Additionally you're not using xf86-video-nouveau. (If you were, you wouldn't be
using glamor.)
I am not sure about this, but here is the log for nouveau:
[ 148.426] (II) modeset(0): [DRI2]
https://bugs.freedesktop.org/show_bug.cgi?id=110714
Peter Draganov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTOURBUG
41 matches
Mail list logo
