On Wed, Jun 26, 2019 at 02:27:16PM +0200, Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> p2pdma.c.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
> ---
> drivers/pci/p2pdma.c | 57
> 1
On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> device-dax.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
> ---
> drivers/dax/dax-private.h | 4
> drivers/dax/device.c | 43
On Wed, Jun 26, 2019 at 02:27:14PM +0200, Christoph Hellwig wrote:
> Provide an internal refcounting logic if no ->ref field is provided
> in the pagemap passed into devm_memremap_pages so that callers don't
> have to reinvent it poorly.
>
> Signed-off-by: Christoph Hellwig
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=111007
--- Comment #5 from joinlaw ---
I put photo tutorial to reproduce the bug in the attachment
steps and arrange by their number from 1 to 8
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111007
--- Comment #4 from joinlaw ---
Created attachment 144649
--> https://bugs.freedesktop.org/attachment.cgi?id=144649=edit
Photo tutorial to reproduce the bug
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are
On Wed, Jun 26, 2019 at 02:27:23PM +0200, Christoph Hellwig wrote:
> All the mm/hmm.c code is better keyed off HMM_MIRROR. Also let nouveau
> depend on it instead of the mix of a dummy dependency symbol plus the
> actually selected one. Drop various odd dependencies, as the code is
> pretty
On Wed, Jun 26, 2019 at 02:27:22PM +0200, Christoph Hellwig wrote:
> The ZONE_DEVICE support doesn't depend on anything HMM related, just on
> various bits of arch support as indicated by the architecture. Also
> don't select the option from nouveau as it isn't present in many setups,
> and
https://bugs.freedesktop.org/show_bug.cgi?id=111007
--- Comment #3 from joinlaw ---
this bug hang my system and i can't even go to virtual terminal as it appear in
the system hang attachment
so i cant record apitrace because when i did that the trace file was corrupted
and i cant replay it
--
https://bugs.freedesktop.org/show_bug.cgi?id=111007
--- Comment #2 from joinlaw ---
Created attachment 144648
--> https://bugs.freedesktop.org/attachment.cgi?id=144648=edit
system hang
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
On Wed, Jun 26, 2019 at 02:27:13PM +0200, Christoph Hellwig wrote:
> Add a flags field to struct dev_pagemap to replace the altmap_valid
> boolean to be a little more extensible. Also add a pgmap_altmap() helper
> to find the optional altmap and clean up the code using the altmap using
> it.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=101778
Karol Herbst changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #10 from Karol
https://bugs.freedesktop.org/show_bug.cgi?id=100567
--- Comment #35 from Harry Coin ---
On 'disco' aka:
uname -a
Linux ceo1homenx 5.0.0-19-generic #20-Ubuntu SMP Wed Jun 19 17:04:04 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
The following trace shows a nouveau problem, then two mintues later a
On Wed, Jun 26, 2019 at 02:27:10PM +0200, Christoph Hellwig wrote:
> Just check if there is a ->page_free operation set and take care of the
> static key enable, as well as the put using device managed resources.
> Also check that a ->page_free is provided for the pgmaps types that
> require it,
https://bugs.freedesktop.org/show_bug.cgi?id=111007
--- Comment #1 from Ilia Mirkin ---
Unfortunately blender can be very difficult to use for someone who has no idea
about any of that stuff (like me). Can you make an apitrace which reproduces
the crash when replayed?
Failing that, can you
https://bugs.freedesktop.org/show_bug.cgi?id=111007
Bug ID: 111007
Summary: Blender crash when opening material tab GTX 750Ti --
NV117 (GM107)
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux
On Wed, Jun 26, 2019 at 10:14:45AM -0700, 'Ira Weiny' wrote:
> On Wed, Jun 26, 2019 at 09:00:47AM -0700, Dan Williams wrote:
> > [ add Ira ]
> >
> > On Wed, Jun 26, 2019 at 5:27 AM Christoph Hellwig wrote:
> > >
> > > The code hasn't been used since it was added to the tree, and doesn't
> > >
It turns out that while disabling i2c bus access from software when the
GPU is suspended was a step in the right direction with:
commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")
We also ended up accidentally breaking the vbios init scripts on some
older Tesla GPUs,
On Wed, Jun 26, 2019 at 02:27:07PM +0200, Christoph Hellwig wrote:
> Most pgmap types are only supported when certain config options are
> enabled. Check for a type that is valid for the current configuration
> before setting up the pagemap. For this the usage of the 0 type for
> device dax gets
On Wed, Jun 26, 2019 at 09:00:47AM -0700, Dan Williams wrote:
> [ add Ira ]
>
> On Wed, Jun 26, 2019 at 5:27 AM Christoph Hellwig wrote:
> >
> > The code hasn't been used since it was added to the tree, and doesn't
> > appear to actually be usable.
> >
> > Signed-off-by: Christoph Hellwig
> >
On Tue, Jun 25, 2019 at 10:46 PM Michal Hocko wrote:
>
> On Tue 25-06-19 12:52:18, Dan Williams wrote:
> [...]
> > > Documentation/process/stable-api-nonsense.rst
> >
> > That document has failed to preclude symbol export fights in the past
> > and there is a reasonable argument to try not to
[ add Ira ]
On Wed, Jun 26, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> The code hasn't been used since it was added to the tree, and doesn't
> appear to actually be usable.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Jason Gunthorpe
> Acked-by: Michal Hocko
[..]
> diff --git
Ilia et al.,
it's been quiet for quite some time regarding this topic. Is there anything I can do to identify the problem or to improve the display, or do I have to give up?
Best regards
Harald
Gesendet: Freitag, 21. Juni 2019 um 15:40 Uhr
Von: "Harald Harders"
An:
On Wed 26-06-19 14:27:05, Christoph Hellwig wrote:
> nouveau is currently using this through an odd hmm wrapper, and I plan
> to switch it to the real thing later in this series.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: John Hubbard
Acked-by: Michal Hocko
Thanks!
> ---
>
The ZONE_DEVICE support doesn't depend on anything HMM related, just on
various bits of arch support as indicated by the architecture. Also
don't select the option from nouveau as it isn't present in many setups,
and depend on it instead.
Signed-off-by: Christoph Hellwig
---
The migrate_vma helper is only used by noveau to migrate device private
pages around. Other HMM_MIRROR users like amdgpu or infiniband don't
need it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/Kconfig | 1 +
mm/Kconfig | 1 -
Remove the clumsy hmm_devmem_page_{get,set}_drvdata helpers, and
instead just access the page directly. Also make the page data
a void pointer, and thus much easier to use.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 18 ++-
include/linux/hmm.h
The functionality is identical to the one currently open coded in
device-dax.
Signed-off-by: Christoph Hellwig
---
drivers/dax/dax-private.h | 4
drivers/dax/device.c | 43 ---
2 files changed, 47 deletions(-)
diff --git
The only user of it has just been removed, and there wasn't really any need
to wrap a basic memory allocator to start with.
Signed-off-by: Christoph Hellwig
---
include/linux/hmm.h | 3 ---
mm/hmm.c| 14 --
2 files changed, 17 deletions(-)
diff --git
The functionality is identical to the one currently open coded in
p2pdma.c.
Signed-off-by: Christoph Hellwig
---
drivers/pci/p2pdma.c | 57
1 file changed, 4 insertions(+), 53 deletions(-)
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
Provide an internal refcounting logic if no ->ref field is provided
in the pagemap passed into devm_memremap_pages so that callers don't
have to reinvent it poorly.
Signed-off-by: Christoph Hellwig
---
include/linux/memremap.h | 4 ++
kernel/memremap.c | 64
There isn't really much value add in the hmm_devmem_add wrapper and
more, as using devm_memremap_pages directly now is just as simple.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 26
include/linux/hmm.h | 129
hmm_vma_alloc_locked_page is scheduled to go away, use the proper
mm function directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Just use devm_memremap_pages instead of hmm_devmem_add pages to allow
killing that wrapper which doesn't provide a whole lot of benefits.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 82 --
1 file changed, 38 insertions(+), 44
All the mm/hmm.c code is better keyed off HMM_MIRROR. Also let nouveau
depend on it instead of the mix of a dummy dependency symbol plus the
actually selected one. Drop various odd dependencies, as the code is
pretty portable.
Signed-off-by: Christoph Hellwig
---
Passing the actual typed structure leads to more understandable code
vs just passing the ref member.
Reported-by: Logan Gunthorpe
Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
Reviewed-by: Jason Gunthorpe
Reviewed-by: Dan Williams
---
drivers/dax/device.c | 12
nouveau is currently using this through an odd hmm wrapper, and I plan
to switch it to the real thing later in this series.
Signed-off-by: Christoph Hellwig
Reviewed-by: John Hubbard
---
mm/mempolicy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index
Hi Dan, Jérôme and Jason,
below is a series that cleans up the dev_pagemap interface so that
it is more easily usable, which removes the need to wrap it in hmm
and thus allowing to kill a lot of code
Note: this series is on top of Linux 5.2-rc5 and has some minor
conflicts with the hmm tree that
Add a flags field to struct dev_pagemap to replace the altmap_valid
boolean to be a little more extensible. Also add a pgmap_altmap() helper
to find the optional altmap and clean up the code using the altmap using
it.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/mm/mem.c | 10
struct dev_pagemap is always embedded into a containing structure, so
there is no need to an additional private data field.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/nvdimm/pmem.c| 2 +-
include/linux/memremap.h | 3 +--
kernel/memremap.c| 2 +-
This replaces the hacky ->fault callback, which is currently directly
called from common code through a hmm specific data structure as an
exercise in layering violations.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/hmm.h | 6 --
This code is a trivial wrapper around device model helpers, which
should have been integrated into the driver device model usage from
the start. Assuming it actually had users, which it never had since
the code was added more than 1 1/2 years ago.
Signed-off-by: Christoph Hellwig
Reviewed-by:
Just check if there is a ->page_free operation set and take care of the
static key enable, as well as the put using device managed resources.
Also check that a ->page_free is provided for the pgmaps types that
require it, and check for a valid type as well while we are at it.
Note that this also
The dev_pagemap is a growing too many callbacks. Move them into a
separate ops structure so that they are not duplicated for multiple
instances, and an attacker can't easily overwrite them.
Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
Reviewed-by: Jason Gunthorpe
---
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
mm/Kconfig | 10 --
1 file changed, 10 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index f0c76ba47695..0d2ba7e1f43e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -675,16 +675,6 @@ config ARCH_HAS_HMM_MIRROR
Keep the physical address allocation that hmm_add_device does with the
rest of the resource code, and allow future reuse of it without the hmm
wrapper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: John Hubbard
---
include/linux/ioport.h | 2 ++
kernel/resource.c
This function has never been used since it was first added to the kernel
more than a year and a half ago, and if we ever grow a consumer of the
MEMORY_DEVICE_PUBLIC infrastructure it can easily use devm_memremap_pages
directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Most pgmap types are only supported when certain config options are
enabled. Check for a type that is valid for the current configuration
before setting up the pagemap. For this the usage of the 0 type for
device dax gets replaced with an explicit MEMORY_DEVICE_DEVDAX type.
Signed-off-by:
The code hasn't been used since it was added to the tree, and doesn't
appear to actually be usable.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Acked-by: Michal Hocko
---
include/linux/hmm.h | 4 ++--
include/linux/ioport.h | 1 -
include/linux/memremap.h | 8
->mapping isn't even used by HMM users, and the field at the same offset
in the zone_device part of the union is declared as pad. (Which btw is
rather confusing, as DAX uses ->pgmap and ->mapping from two different
sides of the union, but DAX doesn't use hmm_devmem_free).
Signed-off-by:
On 6/25/19 10:45 PM, Michal Hocko wrote:
> On Tue 25-06-19 20:15:28, John Hubbard wrote:
>> On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
>>> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
On 6/13/19 5:43 PM, Ira Weiny wrote:
> On Thu, Jun 13, 2019 at 07:58:29PM +, Jason
50 matches
Mail list logo
