On Mon, Dec 24, 2018 at 03:46:33PM +0200, Leon Romanovsky wrote: > diff --git a/drivers/infiniband/core/user_mad.c b/drivers/infiniband/core/user_mad.c > index 1a90012b5542..6929796e35e6 100644 > +++ b/drivers/infiniband/core/user_mad.c > @@ -1031,8 +1031,8 @@ static int ib_umad_close(struct inode *inode, struct file *filp) > > mutex_unlock(&file->port->file_mutex); > > - kfree(file); > ib_umad_dev_put(dev); > + kfree(file); > return 0; This doesn't make any sense. The kasn splat is suggesting that 'dev' is the thing that was freed, not file, and ib_umad_dev_put does not touch 'file' memory either, so I don't see how order here matters.. .. and as I said earlier, the put is redundant, so this will not release dev anyhow.. Something else is going wrong to get that trace.. It sure looks like the cdev_put during close() is faulting, which means the 'dev' was freed by the timem close returns, which should not be possible. That points to a problem with the cdev reference chaining and some kind if racing of ib_umad_kill_port ? Jason
