From: Steve French <smfrench@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arthur Marsh <arthur.marsh@internode.on.net>,
SCSI development list <linux-scsi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
CIFS <linux-cifs@vger.kernel.org>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
ronnie sahlberg <ronniesahlberg@gmail.com>
Subject: Re: refcount_t: underflow; use-after-free with CIFS umount after scsi-misc commit ef2cc88e2a205b8a11a19e78db63a70d3728cdf5
Date: Sun, 8 Dec 2019 21:18:51 -0600 [thread overview]
Message-ID: <CAH2r5mvAv651DcX0--8oRYR8BXmBr8F=ymeBVDXm5YoQfcnK2A@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wjj8SQx4YzS8yw7ZJJKiVLBY0g=d8rCSyPCM=8Pzmz+Zg@mail.gmail.com>
On Sun, Dec 8, 2019 at 8:23 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sun, Dec 8, 2019 at 5:49 PM Arthur Marsh
> <arthur.marsh@internode.on.net> wrote:
> >
> > This still happens with 5.5.0-rc1:
>
> Does it happen 100% of the time?
I can reproduce it (although it was a little more difficult since WiFi doesn't
work on RC1 on some of my hardware - due to the 802.11 driver regression oops.
I was able to reproduce it to Samba localhost).
> Your bisection result looks pretty nonsensical - not that it's
> impossible (anything is possible), but it really doesn't look very
> likely. Which makes me think maybe it's slightly timing-sensitive or
> something?
The bisection result is implausible. I just did some experiments and
it looks far more likely is that it is related to commit
72e73c78c446e ("cifs: close the shared root handle on tree disconnect")
so added Ronnie to the cc. That patch added a call (at unmount time)
to close_shroot.
The idea of that patch made sense - although tree disconnect (and then
logoff of the session)
will indirectly free any open handles on the server for that session,
it is a little
cleaner to close the cached root SMB3 file handle explicitly.
void close_shroot(struct cached_fid *cfid)
{
mutex_lock(&cfid->fid_mutex);
kref_put(&cfid->refcount, smb2_close_cached_fid);
mutex_unlock(&cfid->fid_mutex);
}
Taking out the one line change in the patch from last week that calls
close_shroot from
umount (SMB2_tdis, ie tree_disconnect) I don't see the problem so far
more likely
that it is related to that commit. The problem seems to be related
to servers which
don't support directory leases. Will spin up a patch to fix this if
Ronnie hasn't already fixed it
next prev parent reply other threads:[~2019-12-09 3:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <30808b0b-367a-266a-7ef4-de69c08e1319@internode.on.net>
2019-12-09 1:49 ` refcount_t: underflow; use-after-free with CIFS umount after scsi-misc commit ef2cc88e2a205b8a11a19e78db63a70d3728cdf5 Arthur Marsh
2019-12-09 2:23 ` Linus Torvalds
2019-12-09 2:52 ` Al Viro
2019-12-09 3:10 ` Linus Torvalds
2019-12-09 3:15 ` Linus Torvalds
2019-12-09 3:18 ` Steve French [this message]
2019-12-09 3:27 ` Steve French
2019-12-09 14:45 ` Arthur Marsh
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='CAH2r5mvAv651DcX0--8oRYR8BXmBr8F=ymeBVDXm5YoQfcnK2A@mail.gmail.com' \
--to=smfrench@gmail.com \
--cc=arthur.marsh@internode.on.net \
--cc=jejb@linux.ibm.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ronniesahlberg@gmail.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).