linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Hatayama\, Daisuke" <d.hatayama@jp.fujitsu.com>
Cc: "'gregkh\@linuxfoundation.org'" <gregkh@linuxfoundation.org>,
	"'tj\@kernel.org'" <tj@kernel.org>, "Okajima\,
	Toshiyuki" <toshi.okajima@jp.fujitsu.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"'ebiederm\@aristanetworks.com'" <ebiederm@aristanetworks.com>
Subject: Re: [CFT][PATCH] kernfs: Correct kernfs directory seeks.
Date: Tue, 05 Jun 2018 10:31:36 -0500	[thread overview]
Message-ID: <87h8mhgsh3.fsf@xmission.com> (raw)
In-Reply-To: <33710E6CAA200E4583255F4FB666C4E21B66BAC8@G01JPEXMBYT03> (Daisuke Hatayama's message of "Tue, 5 Jun 2018 05:45:54 +0000")

"Hatayama, Daisuke" <d.hatayama@jp.fujitsu.com> writes:

>> >> +
>> >> +	/* Is the saved position usable? */
>> >> +	if (saved) {
>> >> +		/* Proper parent and hash? */
>> >> +		if ((parent != saved->parent) || (saved->hash != hash)) {
>> >> +			saved = NULL;
>> >
>> > name is uninitialized in this path.
>> 
>> It is.  name is initialized to "" see above.
>> 
>
> Or when either of the conditions is true, it has resulted in some inconsistent state, right?
> So, why not terminating this session of readdir() immediately by
> returning NULL just as when off is turned out to be invalid?

What I have above is not the clearest, and in fact the logic could be
better.

The fundamental challenge is because hash collisions are possible a file
offset does not hold complete position information in a directory.

So the kernfs node that is to be read/displayed next is saved in the
struct file.  The it is tested if the saved kernfs node is usable
for finding the location in the directory.  Several things may have
gone wrong.

- Someone may have called seekdir.
- The saved kernfs node may have been renamed.
- The saved kernfs node may have been moved to a different directory in
  kernfs.
- the saved kernfs node may have been deleted.

If any of those are true the code needs to do the rbtree lookup.

If the kernfs node has been deleted or moved to a different directory we
can safely use it's name while performing the rbtree lookup.  Which in
the event of a hash collision will be more accurate in finding our old
location, and preventing the same directory entry being returned
multiple times.

Which is completely different than if the directory offset is an invalid
value that will never point to any directory entries.

Eric

  reply	other threads:[~2018-06-05 15:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-28 12:54 [RESEND PATCH v2] kernfs: fix dentry unexpected skip Hatayama, Daisuke
2018-05-28 13:08 ` Hatayama, Daisuke
2018-05-29 16:26 ` 'tj@kernel.org'
2018-06-01  9:25   ` Hatayama, Daisuke
2018-06-01 17:07     ` 'tj@kernel.org'
2018-06-04  9:46       ` Hatayama, Daisuke
2018-06-02 17:25 ` Eric W. Biederman
2018-06-03 18:51   ` [CFT][PATCH] kernfs: Correct kernfs directory seeks Eric W. Biederman
2018-06-04  9:34     ` Hatayama, Daisuke
2018-06-04 14:44       ` Eric W. Biederman
2018-06-05  2:02         ` Eric W. Biederman
2018-06-05  5:52           ` Hatayama, Daisuke
2018-06-05  5:45         ` Hatayama, Daisuke
2018-06-05 15:31           ` Eric W. Biederman [this message]
2018-06-05 15:42             ` 'tj@kernel.org'
2018-06-05 17:47               ` Eric W. Biederman
2018-06-07 18:36                 ` 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=87h8mhgsh3.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@aristanetworks.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=toshi.okajima@jp.fujitsu.com \
    /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).