All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: vfs: Don't copy mount bind mounts of /proc/<pid>/ns/mnt between namespaces
Date: Mon, 02 Sep 2013 14:52:20 -0700	[thread overview]
Message-ID: <8738pmnb6z.fsf@xmission.com> (raw)
In-Reply-To: <20130902204038.GO19256@mwanda> (Dan Carpenter's message of "Mon, 2 Sep 2013 23:40:38 +0300")

Dan Carpenter <dan.carpenter@oracle.com> writes:

> On Mon, Sep 02, 2013 at 01:30:00PM -0700, Eric W. Biederman wrote:
>> Dan Carpenter <dan.carpenter@oracle.com> writes:
>> 
>> > Hello Eric W. Biederman,
>> >
>> > This is a semi-automatic email about new static checker warnings.
>> >
>> > The patch 4ce5d2b1a8fd: "vfs: Don't copy mount bind mounts of
>> > /proc/<pid>/ns/mnt between namespaces" from Mar 30, 2013, leads to
>> > the following Smatch complaint:
>> 
>> Semi-autoautomatic reply.  The test !q is enough to ensure p is valid
>> until p->mnt.mnt_root == q->mnt.mnt_root.
>> 
>> This has been verified through both testing and reading of the code.
>> 
>
> Why not make the test:
>
> 	while (1) { ...

I really don't understand what you are getting at, and it feels
like this conversation is descending into inanity fast.

The way this work is.
p = old
q = new

Where new is a copy of old.

p == NULL means that we have completed the traversal.

The entire point of the loop is to find corresponding entities in new
and old.  Because in a few correr cases I slice off leaf mounts that
are mounted on top of files I need an extra loop, and I made that with
a very small code change.

So yes it does look like the case that except for the first iteration
the test at the top of the while loop is now redundant, because of the
if (!q) break; that I added.

I think any greater change to the loop would have obscured the change
that I made a great deal more.

I think all of this talking about the syntactical elements of the code
instead of brining this up to the level of human beings and talking
about what is going on is extremely dangerous way to look at code.
Especially given that C does not allow everything of importance about
the code to be expressed.

Eric



  reply	other threads:[~2013-09-02 21:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-02 15:20 vfs: Don't copy mount bind mounts of /proc/<pid>/ns/mnt between namespaces Dan Carpenter
2013-09-02 20:30 ` Eric W. Biederman
2013-09-02 20:40   ` Dan Carpenter
2013-09-02 21:52     ` Eric W. Biederman [this message]
2013-09-02 23:10       ` Dan Carpenter

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=8738pmnb6z.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-fsdevel@vger.kernel.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.