From: Sasha Levin <levinsasha928@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: penberg@kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 3/5] tools/kvm/9p: Don't follow symlink on server
Date: Sun, 19 Jun 2011 02:41:51 -0400 [thread overview]
Message-ID: <1308465711.2899.17.camel@lappy> (raw)
In-Reply-To: <87aade1jte.fsf@linux.vnet.ibm.com>
On Sun, 2011-06-19 at 10:47 +0530, Aneesh Kumar K.V wrote:
> On Sat, 18 Jun 2011 14:51:13 -0400, Sasha Levin <levinsasha928@gmail.com> wrote:
> > On Sat, 2011-06-18 at 23:19 +0530, Aneesh Kumar K.V wrote:
> > > Use lstat instead of stat
> >
> > This patch should probably come after 9p2000.u support is added, since
> > now we transparently work 'through' symlinks (because legacy 9p2000
> > doesn't support them).
> > Once 9p2000.u support is added we could represent symlinks and then a
> > switch to lstat might be due.
> >
>
> Shouldn't we aim to support 9p2000.L directly rather than supporting all
> the three versions of protocol ? Linux guest have good support for
> 9p2000.L
I'm perfectly fine with adding support directly for 9p2000.L, I just
figured that we'd need to go through the 9p2000.u milestone before
getting there instead of getting to 9p2000.L directly.
> Do you think the patch breaks any of the expectation of 9p2000 ?. It
> would be nice to get the correct file attributes when fetching
> attributes from the server, irrespective of whether client support symlink
> or not.
The idea behind following symlinks was that we could make them
transparently work even without protocol support (yes, not exactly what
the protocol defines - but it made it much more useful).
Removing symlink following also changes more than just the lstat thing,
you'd also need O_NOFOLLOW when opening files for example.
--
Sasha.
next prev parent reply other threads:[~2011-06-19 6:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-18 17:49 [PATCH 1/5] tools/kvm/9p: Use the same #define as the kernel Aneesh Kumar K.V
2011-06-18 17:49 ` [PATCH 2/5] tools/kvm/virtio: Add new iov helper Aneesh Kumar K.V
2011-06-18 17:49 ` [PATCH 3/5] tools/kvm/9p: Don't follow symlink on server Aneesh Kumar K.V
2011-06-18 18:51 ` Sasha Levin
2011-06-19 5:17 ` Aneesh Kumar K.V
2011-06-19 6:41 ` Sasha Levin [this message]
2011-06-19 9:11 ` Aneesh Kumar K.V
2011-06-18 17:49 ` [PATCH 4/5] tools/kvm/9p: Fix the pdu len Aneesh Kumar K.V
2011-06-18 18:51 ` Sasha Levin
2011-06-19 5:11 ` Aneesh Kumar K.V
2011-06-19 6:41 ` Sasha Levin
2011-06-18 17:49 ` [PATCH 5/5] tools/kvm/9p: Simplify the handler Aneesh Kumar K.V
2011-06-18 18:51 ` Sasha Levin
2011-06-19 5:13 ` Aneesh Kumar K.V
2011-06-19 6:41 ` Sasha Levin
2011-06-18 18:50 ` [PATCH 1/5] tools/kvm/9p: Use the same #define as the kernel Sasha Levin
2011-06-19 5:14 ` Aneesh Kumar K.V
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=1308465711.2899.17.camel@lappy \
--to=levinsasha928@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=penberg@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.