From: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
To: Mike Marciniszyn <infinipath-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: races in ipathfs
Date: Sun, 18 Mar 2012 18:45:47 +0000 [thread overview]
Message-ID: <20120318184547.GA6814@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20120119202003.GZ23916-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
On Thu, Jan 19, 2012 at 08:20:04PM +0000, Al Viro wrote:
> Use of qib_super is seriously racy. qibfs_add() (and worse,
> qibfs_remove()) can happen during qibfs_mount() and qibfs_kill_super().
[snip]
FWIW, I've put a completely untested patchset into
git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git qibfs
It tries to avoid that kind of crap by getting rid of "populate at mount
time" logics - we keep (internal) mount of that sucker for as long as
there are any devices owned by ib_qib, adding them on add_device() and
removing on remove_device(). The only complication is with module
use counts - that fs has to be a separate module, or we'll have ib_qib
impossible to rmmod, because fs keeps its module pinned and any devices
held by ib_qib PCI driver will keep the fs pinned, so we never get
to unregistering said PCI driver. With skeleton of qibfs (static parts
only) taken to ib_qib_fs.c we avoid that problem - it is what ends up
being pinned down for as long as ib_qib owns any devices, but then it's
pinned down by ib_qib using exports from ib_qib_fs anyway. And once
ib_qib is removed, all internal references to that vfsmount and superblock
disappear as well...
This stuff is completely untested; I don't have the hardware in question.
It does compile and survive modpost, but that's it. Please, review and
comment...
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mike Marciniszyn <infinipath@qlogic.com>
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: races in ipathfs
Date: Sun, 18 Mar 2012 18:45:47 +0000 [thread overview]
Message-ID: <20120318184547.GA6814@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20120119202003.GZ23916@ZenIV.linux.org.uk>
On Thu, Jan 19, 2012 at 08:20:04PM +0000, Al Viro wrote:
> Use of qib_super is seriously racy. qibfs_add() (and worse,
> qibfs_remove()) can happen during qibfs_mount() and qibfs_kill_super().
[snip]
FWIW, I've put a completely untested patchset into
git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git qibfs
It tries to avoid that kind of crap by getting rid of "populate at mount
time" logics - we keep (internal) mount of that sucker for as long as
there are any devices owned by ib_qib, adding them on add_device() and
removing on remove_device(). The only complication is with module
use counts - that fs has to be a separate module, or we'll have ib_qib
impossible to rmmod, because fs keeps its module pinned and any devices
held by ib_qib PCI driver will keep the fs pinned, so we never get
to unregistering said PCI driver. With skeleton of qibfs (static parts
only) taken to ib_qib_fs.c we avoid that problem - it is what ends up
being pinned down for as long as ib_qib owns any devices, but then it's
pinned down by ib_qib using exports from ib_qib_fs anyway. And once
ib_qib is removed, all internal references to that vfsmount and superblock
disappear as well...
This stuff is completely untested; I don't have the hardware in question.
It does compile and survive modpost, but that's it. Please, review and
comment...
next prev parent reply other threads:[~2012-03-18 18:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 20:20 races in ipathfs Al Viro
2012-01-19 20:20 ` Al Viro
[not found] ` <20120119202003.GZ23916-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2012-01-20 13:55 ` Mike Marciniszyn
2012-01-20 13:55 ` Mike Marciniszyn
2012-03-18 18:45 ` Al Viro [this message]
2012-03-18 18:45 ` Al Viro
[not found] ` <20120318184547.GA6814-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2012-03-18 22:40 ` Al Viro
2012-03-18 22:40 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120318184547.GA6814@ZenIV.linux.org.uk \
--to=viro-3bdd1+5odreifsdqtta3olvcufugdwfn@public.gmane.org \
--cc=infinipath-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.