From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH 3/5] tools/kvm/9p: Don't follow symlink on server Date: Sun, 19 Jun 2011 02:41:51 -0400 Message-ID: <1308465711.2899.17.camel@lappy> References: <1308419348-31934-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1308419348-31934-3-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1308423073.3766.6.camel@lappy> <87aade1jte.fsf@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: penberg@kernel.org, kvm@vger.kernel.org To: "Aneesh Kumar K.V" Return-path: Received: from mail-vw0-f46.google.com ([209.85.212.46]:62069 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751528Ab1FSGlz (ORCPT ); Sun, 19 Jun 2011 02:41:55 -0400 Received: by mail-vw0-f46.google.com with SMTP id 1so276939vws.19 for ; Sat, 18 Jun 2011 23:41:55 -0700 (PDT) In-Reply-To: <87aade1jte.fsf@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 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.