Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1684678 > unrolled thread

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [HMM 12/15] mm/migrate: new memory migration helper for use with  device memory v4 Evgeny Baskakov <ebaskakov@nvidia.com> - 2017-07-11 01:00 +0200
    Re: [HMM 12/15] mm/migrate: new memory migration helper for use with  device memory v4 Jerome Glisse <jglisse@redhat.com> - 2017-07-11 01:50 +0200
      Re: [HMM 12/15] mm/migrate: new memory migration helper for use with  device memory v4 Evgeny Baskakov <ebaskakov@nvidia.com> - 2017-07-11 02:20 +0200
        Re: [HMM 12/15] mm/migrate: new memory migration helper for use with  device memory v4 Jerome Glisse <jglisse@redhat.com> - 2017-07-11 03:00 +0200

#1684678 — Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

[Multipart message — attachments visible in raw view] — view raw

On 6/30/17 5:57 PM, Jerome Glisse wrote:
...

Hi Jerome,

I am seeing a strange crash in our code that uses the hmm_device_new() 
helper. After the driver is repeatedly loaded/unloaded, hmm_device_new() 
suddenly returns NULL.

I have reproduced this with the dummy driver from the hmm-next branch:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

(gdb) bt
#0  hmm_devmem_add (ops=0xffffffffa003a140, device=0x0 
<irq_stack_union>, size=0x4000000) at mm/hmm.c:997
#1  0xffffffffa0038236 in dmirror_probe (pdev=<optimized out>) at 
drivers/char/hmm_dmirror.c:1106
#2  0xffffffff815acfcb in platform_drv_probe (_dev=0xffff88081368ca78) 
at drivers/base/platform.c:578
#3  0xffffffff815ab0a4 in really_probe (drv=<optimized out>, 
dev=<optimized out>) at drivers/base/dd.c:385
#4  driver_probe_device (drv=0xffffffffa003b028, dev=0xffff88081368ca78) 
at drivers/base/dd.c:529
#5  0xffffffff815ab1d4 in __driver_attach (dev=0xffff88081368ca78, 
data=0xffffffffa003b028) at drivers/base/dd.c:763
#6  0xffffffff815a911d in bus_for_each_dev (bus=<optimized out>, 
start=<optimized out>, data=0x4000000, fn=0x18 <irq_stack_union+24>) at 
drivers/base/bus.c:313
#7  0xffffffff815aa98e in driver_attach (drv=<optimized out>) at 
drivers/base/dd.c:782
#8  0xffffffff815aa585 in bus_add_driver (drv=0xffffffffa003b028) at 
drivers/base/bus.c:669
#9  0xffffffff815abc10 in driver_register (drv=0xffffffffa003b028) at 
drivers/base/driver.c:168
#10 0xffffffff815acf46 in __platform_driver_register (drv=<optimized 
out>, owner=<optimized out>) at drivers/base/platform.c:636


Can you please look into this?

Here's a command to reproduce, using the kload.sh script (taken from a 
sanity suite you provided earlier, attached):

$ while true; do sudo ./kload.sh; done

Thanks!

Evgeny Baskakov
NVIDIA

[toc] | [next] | [standalone]

#1684696

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 10, 2017 at 03:59:37PM -0700, Evgeny Baskakov wrote:
> On 6/30/17 5:57 PM, Jerome Glisse wrote:
> ...
> 
> Hi Jerome,
> 
> I am seeing a strange crash in our code that uses the hmm_device_new()
> helper. After the driver is repeatedly loaded/unloaded, hmm_device_new()
> suddenly returns NULL.
> 
> I have reproduced this with the dummy driver from the hmm-next branch:
> 
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

Horrible stupid bug in the code, most likely from cut and paste. Attached
patch should fix it. I don't know how long it took for you to trigger it.

Jérôme

[toc] | [prev] | [next] | [standalone]

#1684704

On 7/10/17 4:43 PM, Jerome Glisse wrote:

> On Mon, Jul 10, 2017 at 03:59:37PM -0700, Evgeny Baskakov wrote:
> ...
> Horrible stupid bug in the code, most likely from cut and paste. Attached
> patch should fix it. I don't know how long it took for you to trigger it.
>
> Jérôme
Thanks, this indeed fixes the problem! Yes, it took a nightly run before 
it triggered.

One a side note, should this "return NULL" be replaced with "return 
ERR_PTR(-ENOMEM)"?

struct hmm_device *hmm_device_new(void *drvdata)
{
...
     if (hmm_device->minor >= HMM_DEVICE_MAX) {
         spin_unlock(&hmm_device_lock);
         kfree(hmm_device);
->      return NULL;
     }

Thanks!

Evgeny Baskakov
NVIDIA

[toc] | [prev] | [next] | [standalone]

#1684711

On Mon, Jul 10, 2017 at 05:17:23PM -0700, Evgeny Baskakov wrote:
> On 7/10/17 4:43 PM, Jerome Glisse wrote:
> 
> > On Mon, Jul 10, 2017 at 03:59:37PM -0700, Evgeny Baskakov wrote:
> > ...
> > Horrible stupid bug in the code, most likely from cut and paste. Attached
> > patch should fix it. I don't know how long it took for you to trigger it.
> > 
> > Jérôme
> Thanks, this indeed fixes the problem! Yes, it took a nightly run before it
> triggered.
> 
> One a side note, should this "return NULL" be replaced with "return
> ERR_PTR(-ENOMEM)"?

Or -EBUSY but yes sure.

Jérôme

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web