From: Richard Gooch <rgooch@ras.ucalgary.ca>
To: Alexander Viro <viro@math.psu.edu>
Cc: linux-kernel@vger.kernel.org,
devfs-announce-list@vindaloo.ras.ucalgary.ca
Subject: Re: [PATCH] devfs v181 available
Date: Mon, 18 Jun 2001 09:15:38 -0600 [thread overview]
Message-ID: <200106181515.f5IFFcA00598@vindaloo.ras.ucalgary.ca> (raw)
In-Reply-To: <Pine.GSO.4.21.0106180246360.17131-100000@weyl.math.psu.edu>
In-Reply-To: <200106180640.f5I6eLS30459@vindaloo.ras.ucalgary.ca> <Pine.GSO.4.21.0106180246360.17131-100000@weyl.math.psu.edu>
Alexander Viro writes:
> On Mon, 18 Jun 2001, Richard Gooch wrote:
> > Alexander Viro writes:
> > > On Mon, 18 Jun 2001, Richard Gooch wrote:
> > > > - Widened locking in <devfs_readlink> and <devfs_follow_link>
> > >
> > > No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking
> > > functions, so BKL is worthless there.
> >
> > Huh? The BKL will protect against other operations which might cause
> > the devfs entry to be unregistered, where those other operations also
> > grab the BKL. So, it's an improvement.
>
> BKL is released as soon as you block. You _do_ regain it when you get
> the next timeslice, but in the meanwhile anything could happen.
>
> > Sure, some operations may cause unregistration without grabbing the
>
> Irrelevant. BKL provides an exclusion only on non-blocking areas.
Yeah, I know all that.
> > BKL, but that's orthogonal (and requires more extensive changes). If
> > this "widening" is of no use, then what use are the existing grabs of
> > the BKL in those functions? You're the one who added them in the first
> > place.
>
> _Moved_ them there from the callers of these functions. And AFAICS
> you do need BKL for get_devfs_entry_...(); otherwise relocation of
> the table will be able to screw you inside of that function. Now, it
> will merrily screw you anyway in a lot of places, but that's another
> story.
OK, so it was another global change.
> BTW, free advice: when you are checking some condition treat the
> result as something that can expire. And don't rely on it past the
> moment when it might expired. E.g. in case of de->registered result
> expires as soon as you do unlock_kernel() _or_ do anything that
> might block.
Yeah, I know. Fear not: I'll be adding proper locks (spinlocks and
semaphores) to the code, continuing the work I started this weekend. I
don't like the BKL anyway (too coarse grained), and hope to see it
removed entirely one day.
Question: assuming data fed to vfs_follow_link() is "safe", does it
need the BKL? I can see that vfs_readlink() obviously doesn't need
it. From reading Documentation/filesystems/Locking I suspect it
doesn't need the BKL, but the way I read it says "follow_link() method
does not *have* the BKL already". But that doesn't explicitely say
whether vfs_follow_link() needs it.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
next prev parent reply other threads:[~2001-06-18 15:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-18 6:01 Richard Gooch
2001-06-18 6:33 ` Alexander Viro
2001-06-18 6:40 ` Richard Gooch
2001-06-18 7:09 ` Alexander Viro
2001-06-18 15:15 ` Richard Gooch [this message]
2001-06-18 16:55 ` Alexander Viro
2001-06-18 18:53 ` Richard Gooch
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=200106181515.f5IFFcA00598@vindaloo.ras.ucalgary.ca \
--to=rgooch@ras.ucalgary.ca \
--cc=devfs-announce-list@vindaloo.ras.ucalgary.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/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
all inboxes | Powered by JetHome®