* [PATCH v2] io-mapping: Indicate mapping failure
@ 2020-07-21 17:19 ` Michael J. Ruhl
0 siblings, 0 replies; 12+ messages in thread
From: Michael J. Ruhl @ 2020-07-21 17:19 UTC (permalink / raw)
To: dri-devel
Cc: Michael J. Ruhl, Andrew Morton, Mike Rapoport, Andy Shevchenko,
Chris Wilson, stable
The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.
Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.
During a device probe, where the ioremap failed, a crash can look
like this:
BUG: unable to handle page fault for address: 0000000000210000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 177 Comm:
RIP: 0010:fill_page_dma [i915]
gen8_ppgtt_create [i915]
i915_ppgtt_create [i915]
intel_gt_init [i915]
i915_gem_init [i915]
i915_driver_probe [i915]
pci_device_probe
really_probe
driver_probe_device
The remap failure occurred much earlier in the probe. If it had
been propagated, the driver would have exited with an error.
Return NULL on ioremap failure.
Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about the io-mapping")
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
---
v2: reflect review comments
---
include/linux/io-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 0beaa3eba155..5641e06cbcf7 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->prot = pgprot_noncached(PAGE_KERNEL);
#endif
- return iomap;
+ return iomap->iomem ? iomap : NULL;
}
static inline void
--
2.21.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v2] io-mapping: Indicate mapping failure
@ 2020-07-21 17:19 ` Michael J. Ruhl
0 siblings, 0 replies; 12+ messages in thread
From: Michael J. Ruhl @ 2020-07-21 17:19 UTC (permalink / raw)
To: dri-devel
Cc: Mike Rapoport, stable, Chris Wilson, Michael J. Ruhl,
Andrew Morton, Andy Shevchenko
The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.
Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.
During a device probe, where the ioremap failed, a crash can look
like this:
BUG: unable to handle page fault for address: 0000000000210000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 177 Comm:
RIP: 0010:fill_page_dma [i915]
gen8_ppgtt_create [i915]
i915_ppgtt_create [i915]
intel_gt_init [i915]
i915_gem_init [i915]
i915_driver_probe [i915]
pci_device_probe
really_probe
driver_probe_device
The remap failure occurred much earlier in the probe. If it had
been propagated, the driver would have exited with an error.
Return NULL on ioremap failure.
Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about the io-mapping")
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
---
v2: reflect review comments
---
include/linux/io-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 0beaa3eba155..5641e06cbcf7 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->prot = pgprot_noncached(PAGE_KERNEL);
#endif
- return iomap;
+ return iomap->iomem ? iomap : NULL;
}
static inline void
--
2.21.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2] io-mapping: Indicate mapping failure
2020-07-21 17:19 ` Michael J. Ruhl
@ 2020-07-21 20:56 ` Andrew Morton
-1 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-07-21 20:56 UTC (permalink / raw)
To: Michael J. Ruhl
Cc: dri-devel, Mike Rapoport, Andy Shevchenko, Chris Wilson, stable
On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl" <michael.j.ruhl@intel.com> wrote:
> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
> success, even when the ioremap fails.
>
> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
> callers check for a NULL return on error this is unexpected.
>
> During a device probe, where the ioremap failed, a crash can look
> like this:
>
> BUG: unable to handle page fault for address: 0000000000210000
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> Oops: 0002 [#1] PREEMPT SMP
> CPU: 0 PID: 177 Comm:
> RIP: 0010:fill_page_dma [i915]
> gen8_ppgtt_create [i915]
> i915_ppgtt_create [i915]
> intel_gt_init [i915]
> i915_gem_init [i915]
> i915_driver_probe [i915]
> pci_device_probe
> really_probe
> driver_probe_device
>
> The remap failure occurred much earlier in the probe. If it had
> been propagated, the driver would have exited with an error.
>
> Return NULL on ioremap failure.
>
> ...
>
> --- a/include/linux/io-mapping.h
> +++ b/include/linux/io-mapping.h
> @@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
> iomap->prot = pgprot_noncached(PAGE_KERNEL);
> #endif
>
> - return iomap;
> + return iomap->iomem ? iomap : NULL;
> }
>
> static inline void
LGTM. However I do think it would be stylistically better/typical to
detect and handle the error early, rather than to blunder on,
pointlessly initializing things?
--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
+++ a/include/linux/io-mapping.h
@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
resource_size_t base,
unsigned long size)
{
+ iomap->iomem = ioremap_wc(base, size);
+ if (!iomap->iomem)
+ return NULL;
+
iomap->base = base;
iomap->size = size;
- iomap->iomem = ioremap_wc(base, size);
#if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */
iomap->prot = pgprot_noncached_wc(PAGE_KERNEL);
#elif defined(pgprot_writecombine)
@@ -118,7 +121,7 @@ io_mapping_init_wc(struct io_mapping *io
iomap->prot = pgprot_noncached(PAGE_KERNEL);
#endif
- return iomap->iomem ? iomap : NULL;
+ return iomap;
}
static inline void
_
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] io-mapping: Indicate mapping failure
@ 2020-07-21 20:56 ` Andrew Morton
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-07-21 20:56 UTC (permalink / raw)
To: Michael J. Ruhl
Cc: Andy Shevchenko, Chris Wilson, stable, dri-devel, Mike Rapoport
On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl" <michael.j.ruhl@intel.com> wrote:
> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
> success, even when the ioremap fails.
>
> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
> callers check for a NULL return on error this is unexpected.
>
> During a device probe, where the ioremap failed, a crash can look
> like this:
>
> BUG: unable to handle page fault for address: 0000000000210000
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> Oops: 0002 [#1] PREEMPT SMP
> CPU: 0 PID: 177 Comm:
> RIP: 0010:fill_page_dma [i915]
> gen8_ppgtt_create [i915]
> i915_ppgtt_create [i915]
> intel_gt_init [i915]
> i915_gem_init [i915]
> i915_driver_probe [i915]
> pci_device_probe
> really_probe
> driver_probe_device
>
> The remap failure occurred much earlier in the probe. If it had
> been propagated, the driver would have exited with an error.
>
> Return NULL on ioremap failure.
>
> ...
>
> --- a/include/linux/io-mapping.h
> +++ b/include/linux/io-mapping.h
> @@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
> iomap->prot = pgprot_noncached(PAGE_KERNEL);
> #endif
>
> - return iomap;
> + return iomap->iomem ? iomap : NULL;
> }
>
> static inline void
LGTM. However I do think it would be stylistically better/typical to
detect and handle the error early, rather than to blunder on,
pointlessly initializing things?
--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
+++ a/include/linux/io-mapping.h
@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
resource_size_t base,
unsigned long size)
{
+ iomap->iomem = ioremap_wc(base, size);
+ if (!iomap->iomem)
+ return NULL;
+
iomap->base = base;
iomap->size = size;
- iomap->iomem = ioremap_wc(base, size);
#if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */
iomap->prot = pgprot_noncached_wc(PAGE_KERNEL);
#elif defined(pgprot_writecombine)
@@ -118,7 +121,7 @@ io_mapping_init_wc(struct io_mapping *io
iomap->prot = pgprot_noncached(PAGE_KERNEL);
#endif
- return iomap->iomem ? iomap : NULL;
+ return iomap;
}
static inline void
_
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] io-mapping: Indicate mapping failure
2020-07-21 20:56 ` Andrew Morton
@ 2020-07-21 21:02 ` Ruhl, Michael J
-1 siblings, 0 replies; 12+ messages in thread
From: Ruhl, Michael J @ 2020-07-21 21:02 UTC (permalink / raw)
To: Andrew Morton
Cc: dri-devel, Mike Rapoport, Andy Shevchenko, Chris Wilson, stable
>-----Original Message-----
>From: Andrew Morton <akpm@linux-foundation.org>
>Sent: Tuesday, July 21, 2020 4:57 PM
>To: Ruhl, Michael J <michael.j.ruhl@intel.com>
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport <rppt@linux.ibm.com>;
>Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Chris Wilson
><chris@chris-wilson.co.uk>; stable@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl"
><michael.j.ruhl@intel.com> wrote:
>
>> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
>> success, even when the ioremap fails.
>>
>> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
>> callers check for a NULL return on error this is unexpected.
>>
>> During a device probe, where the ioremap failed, a crash can look
>> like this:
>>
>> BUG: unable to handle page fault for address: 0000000000210000
>> #PF: supervisor write access in kernel mode
>> #PF: error_code(0x0002) - not-present page
>> Oops: 0002 [#1] PREEMPT SMP
>> CPU: 0 PID: 177 Comm:
>> RIP: 0010:fill_page_dma [i915]
>> gen8_ppgtt_create [i915]
>> i915_ppgtt_create [i915]
>> intel_gt_init [i915]
>> i915_gem_init [i915]
>> i915_driver_probe [i915]
>> pci_device_probe
>> really_probe
>> driver_probe_device
>>
>> The remap failure occurred much earlier in the probe. If it had
>> been propagated, the driver would have exited with an error.
>>
>> Return NULL on ioremap failure.
>>
>> ...
>>
>> --- a/include/linux/io-mapping.h
>> +++ b/include/linux/io-mapping.h
>> @@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
>> iomap->prot = pgprot_noncached(PAGE_KERNEL);
>> #endif
>>
>> - return iomap;
>> + return iomap->iomem ? iomap : NULL;
>> }
>>
>> static inline void
>
>LGTM. However I do think it would be stylistically better/typical to
>detect and handle the error early, rather than to blunder on,
>pointlessly initializing things?
Yeah, I pondered that, and then didn't do it...
>--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
>+++ a/include/linux/io-mapping.h
>@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> resource_size_t base,
> unsigned long size)
> {
>+ iomap->iomem = ioremap_wc(base, size);
>+ if (!iomap->iomem)
>+ return NULL;
>+
This does make more sense.
I am confused by the two follow up emails I just got.
Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
now in the tree. 😊
Thanks,
Mike
> iomap->base = base;
> iomap->size = size;
>- iomap->iomem = ioremap_wc(base, size);
> #if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */
> iomap->prot = pgprot_noncached_wc(PAGE_KERNEL);
> #elif defined(pgprot_writecombine)
>@@ -118,7 +121,7 @@ io_mapping_init_wc(struct io_mapping *io
> iomap->prot = pgprot_noncached(PAGE_KERNEL);
> #endif
>
>- return iomap->iomem ? iomap : NULL;
>+ return iomap;
> }
>
> static inline void
>_
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] io-mapping: Indicate mapping failure
@ 2020-07-21 21:02 ` Ruhl, Michael J
0 siblings, 0 replies; 12+ messages in thread
From: Ruhl, Michael J @ 2020-07-21 21:02 UTC (permalink / raw)
To: Andrew Morton
Cc: Andy Shevchenko, Chris Wilson, stable, dri-devel, Mike Rapoport
>-----Original Message-----
>From: Andrew Morton <akpm@linux-foundation.org>
>Sent: Tuesday, July 21, 2020 4:57 PM
>To: Ruhl, Michael J <michael.j.ruhl@intel.com>
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport <rppt@linux.ibm.com>;
>Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Chris Wilson
><chris@chris-wilson.co.uk>; stable@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl"
><michael.j.ruhl@intel.com> wrote:
>
>> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
>> success, even when the ioremap fails.
>>
>> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
>> callers check for a NULL return on error this is unexpected.
>>
>> During a device probe, where the ioremap failed, a crash can look
>> like this:
>>
>> BUG: unable to handle page fault for address: 0000000000210000
>> #PF: supervisor write access in kernel mode
>> #PF: error_code(0x0002) - not-present page
>> Oops: 0002 [#1] PREEMPT SMP
>> CPU: 0 PID: 177 Comm:
>> RIP: 0010:fill_page_dma [i915]
>> gen8_ppgtt_create [i915]
>> i915_ppgtt_create [i915]
>> intel_gt_init [i915]
>> i915_gem_init [i915]
>> i915_driver_probe [i915]
>> pci_device_probe
>> really_probe
>> driver_probe_device
>>
>> The remap failure occurred much earlier in the probe. If it had
>> been propagated, the driver would have exited with an error.
>>
>> Return NULL on ioremap failure.
>>
>> ...
>>
>> --- a/include/linux/io-mapping.h
>> +++ b/include/linux/io-mapping.h
>> @@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
>> iomap->prot = pgprot_noncached(PAGE_KERNEL);
>> #endif
>>
>> - return iomap;
>> + return iomap->iomem ? iomap : NULL;
>> }
>>
>> static inline void
>
>LGTM. However I do think it would be stylistically better/typical to
>detect and handle the error early, rather than to blunder on,
>pointlessly initializing things?
Yeah, I pondered that, and then didn't do it...
>--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
>+++ a/include/linux/io-mapping.h
>@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> resource_size_t base,
> unsigned long size)
> {
>+ iomap->iomem = ioremap_wc(base, size);
>+ if (!iomap->iomem)
>+ return NULL;
>+
This does make more sense.
I am confused by the two follow up emails I just got.
Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
now in the tree. 😊
Thanks,
Mike
> iomap->base = base;
> iomap->size = size;
>- iomap->iomem = ioremap_wc(base, size);
> #if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */
> iomap->prot = pgprot_noncached_wc(PAGE_KERNEL);
> #elif defined(pgprot_writecombine)
>@@ -118,7 +121,7 @@ io_mapping_init_wc(struct io_mapping *io
> iomap->prot = pgprot_noncached(PAGE_KERNEL);
> #endif
>
>- return iomap->iomem ? iomap : NULL;
>+ return iomap;
> }
>
> static inline void
>_
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] io-mapping: Indicate mapping failure
2020-07-21 21:02 ` Ruhl, Michael J
@ 2020-07-21 21:24 ` Andrew Morton
-1 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-07-21 21:24 UTC (permalink / raw)
To: Ruhl, Michael J
Cc: dri-devel, Mike Rapoport, Andy Shevchenko, Chris Wilson, stable
On Tue, 21 Jul 2020 21:02:44 +0000 "Ruhl, Michael J" <michael.j.ruhl@intel.com> wrote:
> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> >+++ a/include/linux/io-mapping.h
> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> > resource_size_t base,
> > unsigned long size)
> > {
> >+ iomap->iomem = ioremap_wc(base, size);
> >+ if (!iomap->iomem)
> >+ return NULL;
> >+
>
> This does make more sense.
>
> I am confused by the two follow up emails I just got.
One was your original patch, the other is my suggested alteration.
> Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
> now in the tree.
All is OK. If my alteration is acceptable (and, preferably, tested!)
then when the time comes, I'll fold it into the base patch, add a
note indicating this change and shall then send it to Linus.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] io-mapping: Indicate mapping failure
@ 2020-07-21 21:24 ` Andrew Morton
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2020-07-21 21:24 UTC (permalink / raw)
To: Ruhl, Michael J
Cc: Andy Shevchenko, Chris Wilson, stable, dri-devel, Mike Rapoport
On Tue, 21 Jul 2020 21:02:44 +0000 "Ruhl, Michael J" <michael.j.ruhl@intel.com> wrote:
> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> >+++ a/include/linux/io-mapping.h
> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> > resource_size_t base,
> > unsigned long size)
> > {
> >+ iomap->iomem = ioremap_wc(base, size);
> >+ if (!iomap->iomem)
> >+ return NULL;
> >+
>
> This does make more sense.
>
> I am confused by the two follow up emails I just got.
One was your original patch, the other is my suggested alteration.
> Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
> now in the tree.
All is OK. If my alteration is acceptable (and, preferably, tested!)
then when the time comes, I'll fold it into the base patch, add a
note indicating this change and shall then send it to Linus.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] io-mapping: Indicate mapping failure
2020-07-21 21:24 ` Andrew Morton
@ 2020-07-22 5:25 ` Daniel Vetter
-1 siblings, 0 replies; 12+ messages in thread
From: Daniel Vetter @ 2020-07-22 5:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Ruhl, Michael J, Andy Shevchenko, Chris Wilson, stable,
dri-devel, Mike Rapoport
On Tue, Jul 21, 2020 at 11:24 PM Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> On Tue, 21 Jul 2020 21:02:44 +0000 "Ruhl, Michael J" <michael.j.ruhl@intel.com> wrote:
>
> > >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> > >+++ a/include/linux/io-mapping.h
> > >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> > > resource_size_t base,
> > > unsigned long size)
> > > {
> > >+ iomap->iomem = ioremap_wc(base, size);
> > >+ if (!iomap->iomem)
> > >+ return NULL;
> > >+
> >
> > This does make more sense.
> >
> > I am confused by the two follow up emails I just got.
>
> One was your original patch, the other is my suggested alteration.
>
> > Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
> > now in the tree.
>
> All is OK. If my alteration is acceptable (and, preferably, tested!)
> then when the time comes, I'll fold it into the base patch, add a
> note indicating this change and shall then send it to Linus.
Your alternative also matches the other implementation of
io_mapping_init_wc, I was kinda tempted to do that suggestion too just
because of that. But then didn't send out that email.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] io-mapping: Indicate mapping failure
@ 2020-07-22 5:25 ` Daniel Vetter
0 siblings, 0 replies; 12+ messages in thread
From: Daniel Vetter @ 2020-07-22 5:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Chris Wilson, dri-devel, Mike Rapoport, Ruhl, Michael J, stable,
Andy Shevchenko
On Tue, Jul 21, 2020 at 11:24 PM Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> On Tue, 21 Jul 2020 21:02:44 +0000 "Ruhl, Michael J" <michael.j.ruhl@intel.com> wrote:
>
> > >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> > >+++ a/include/linux/io-mapping.h
> > >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> > > resource_size_t base,
> > > unsigned long size)
> > > {
> > >+ iomap->iomem = ioremap_wc(base, size);
> > >+ if (!iomap->iomem)
> > >+ return NULL;
> > >+
> >
> > This does make more sense.
> >
> > I am confused by the two follow up emails I just got.
>
> One was your original patch, the other is my suggested alteration.
>
> > Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
> > now in the tree.
>
> All is OK. If my alteration is acceptable (and, preferably, tested!)
> then when the time comes, I'll fold it into the base patch, add a
> note indicating this change and shall then send it to Linus.
Your alternative also matches the other implementation of
io_mapping_init_wc, I was kinda tempted to do that suggestion too just
because of that. But then didn't send out that email.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] io-mapping: Indicate mapping failure
2020-07-21 21:24 ` Andrew Morton
@ 2020-07-22 11:54 ` Ruhl, Michael J
-1 siblings, 0 replies; 12+ messages in thread
From: Ruhl, Michael J @ 2020-07-22 11:54 UTC (permalink / raw)
To: Andrew Morton
Cc: dri-devel, Mike Rapoport, Andy Shevchenko, Chris Wilson, stable
>-----Original Message-----
>From: Andrew Morton <akpm@linux-foundation.org>
>Sent: Tuesday, July 21, 2020 5:24 PM
>To: Ruhl, Michael J <michael.j.ruhl@intel.com>
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport <rppt@linux.ibm.com>;
>Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Chris Wilson
><chris@chris-wilson.co.uk>; stable@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21 Jul 2020 21:02:44 +0000 "Ruhl, Michael J"
><michael.j.ruhl@intel.com> wrote:
>
>> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
>> >+++ a/include/linux/io-mapping.h
>> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
>> > resource_size_t base,
>> > unsigned long size)
>> > {
>> >+ iomap->iomem = ioremap_wc(base, size);
>> >+ if (!iomap->iomem)
>> >+ return NULL;
>> >+
>>
>> This does make more sense.
>>
>> I am confused by the two follow up emails I just got.
>
>One was your original patch, the other is my suggested alteration.
>
>> Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
>> now in the tree.
>
>All is OK. If my alteration is acceptable (and, preferably, tested!)
>then when the time comes, I'll fold it into the base patch, add a
>note indicating this change and shall then send it to Linus.
I am good with the change and have tested it.
Instead of the system crashing I get:
i915 0000:01:00.0: [drm] *ERROR* Failed to setup region(-5) type=1
i915 0000:01:00.0: Device initialization failed (-5)
i915: probe of 0000:01:00.0 failed with error -5
Which is the expected error.
If you would like this for the updated patch:
Tested-By: Michael J. Ruhl <michael.j.ruhl@intel.com>
Thanks!
Mike
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v2] io-mapping: Indicate mapping failure
@ 2020-07-22 11:54 ` Ruhl, Michael J
0 siblings, 0 replies; 12+ messages in thread
From: Ruhl, Michael J @ 2020-07-22 11:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Andy Shevchenko, Chris Wilson, stable, dri-devel, Mike Rapoport
>-----Original Message-----
>From: Andrew Morton <akpm@linux-foundation.org>
>Sent: Tuesday, July 21, 2020 5:24 PM
>To: Ruhl, Michael J <michael.j.ruhl@intel.com>
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport <rppt@linux.ibm.com>;
>Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Chris Wilson
><chris@chris-wilson.co.uk>; stable@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21 Jul 2020 21:02:44 +0000 "Ruhl, Michael J"
><michael.j.ruhl@intel.com> wrote:
>
>> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
>> >+++ a/include/linux/io-mapping.h
>> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
>> > resource_size_t base,
>> > unsigned long size)
>> > {
>> >+ iomap->iomem = ioremap_wc(base, size);
>> >+ if (!iomap->iomem)
>> >+ return NULL;
>> >+
>>
>> This does make more sense.
>>
>> I am confused by the two follow up emails I just got.
>
>One was your original patch, the other is my suggested alteration.
>
>> Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
>> now in the tree.
>
>All is OK. If my alteration is acceptable (and, preferably, tested!)
>then when the time comes, I'll fold it into the base patch, add a
>note indicating this change and shall then send it to Linus.
I am good with the change and have tested it.
Instead of the system crashing I get:
i915 0000:01:00.0: [drm] *ERROR* Failed to setup region(-5) type=1
i915 0000:01:00.0: Device initialization failed (-5)
i915: probe of 0000:01:00.0 failed with error -5
Which is the expected error.
If you would like this for the updated patch:
Tested-By: Michael J. Ruhl <michael.j.ruhl@intel.com>
Thanks!
Mike
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-07-22 11:54 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-21 17:19 [PATCH v2] io-mapping: Indicate mapping failure Michael J. Ruhl
2020-07-21 17:19 ` Michael J. Ruhl
2020-07-21 20:56 ` Andrew Morton
2020-07-21 20:56 ` Andrew Morton
2020-07-21 21:02 ` Ruhl, Michael J
2020-07-21 21:02 ` Ruhl, Michael J
2020-07-21 21:24 ` Andrew Morton
2020-07-21 21:24 ` Andrew Morton
2020-07-22 5:25 ` Daniel Vetter
2020-07-22 5:25 ` Daniel Vetter
2020-07-22 11:54 ` Ruhl, Michael J
2020-07-22 11:54 ` Ruhl, Michael J
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.