This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/103
** Changed in: qemu
Status: Confirmed => Expired
**
Closed by accident, Christian just told me that this is not fixed yet.
Sorry for the inconvenience.
** Changed in: qemu
Status: Fix Released => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Released with QEMU v5.2.0.
** Changed in: qemu
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file handles on
For the records.
QEMU patches:
https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg07586.html
Linux patches:
https://sourceforge.net/p/v9fs/mailman/message/35175775/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I haven't worked on this topic in years.
** Changed in: qemu
Status: In Progress => Confirmed
** Changed in: qemu
Assignee: Greg Kurz (gkurz) => (unassigned)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
hi greg,
thanks very much for you answer. i saw the proposed kernel patch from eric van
hensbergen - even tried to build my own kernel with the patch applied, i was
ready to run this on a custom kernel with a custom built qemu, but although the
patch can be applied, there have been too many
Hi Alex,
Well... it's slightly more than one patch in QEMU, and this also
requires some linux kernel side changes. And I really can't^W^Wdon't
want to invest more time there if no one helps. This being said, I see
more and more activity on 9p since Dominique Martinet has taken
maintainership.
hi,
i am probably trying to ride a dead horse here, but is there any chance this
patch will make its way into master?
thanks,
alex
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
Hi Maxim,
No I didn't...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file handles on unlinked files
Status in QEMU:
In Progress
Status in Ubuntu:
Hi Greg,
Did you push the qemu patch upstream, and now it is a matter of fixing
the kernel?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file handles on
** Changed in: qemu
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file handles on unlinked files
Status in QEMU:
** Changed in: qemu
Status: New => Confirmed
** Changed in: qemu
Assignee: (unassigned) => Greg Kurz (gkurz)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not
Latest work on the subject seems to be:
https://github.com/ericvh/linux/commit/eaf70223eac094291169f5a6de580351890162a2
I could verify that this patch still applies to the upstream kernel tree
and fixes the issue.
The fix was verified with upstream QEMU + the following patch:
Apologies - I made the mistake of thinking Ubuntu launchpad was actually
functional, as it is I think they simply throw messages on there back to
the original mailing list!
On Wed, 25 May 2016 at 12:14 Greg Kurz wrote:
> On Thu, 05 May 2016 20:54:31 -
> Server
On Thu, 05 May 2016 20:54:31 -
Server Angels wrote:
> I would appreciate this patch being committed as I *think* it's
> affecting a system i'm building now.
>
> I have a backup host with 2 VMs. For business reasons they need to be
> network isolated from each other
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: ubuntu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does
** Also affects: ubuntu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file handles on unlinked files
Status in
I would appreciate this patch being committed as I *think* it's
affecting a system i'm building now.
I have a backup host with 2 VMs. For business reasons they need to be
network isolated from each other and the host, so each is passed through
a physical NIC. Each VM does need access to a
good to know, thanks dominique. I gave it a sniff test with FSX and a few
other benchmarks, but I need to hit it with some multithreaded
regressions. Any pointers to reproducible failure cases would be
beneficial.
On Wed, Apr 15, 2015 at 6:28 AM Dominique Martinet
dominique.marti...@cea.fr
Eric Van Hensbergen wrote on Mon, Apr 13, 2015 at 04:05:28PM +:
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according to the protocol. fid 3 and fid 2 are both clones of fid 1.
Right, they're clone fids, but nothing in the protocol says what should
happen to
On Mon, Apr 13, 2015 at 04:05:28PM +, Eric Van Hensbergen wrote:
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according to the protocol. fid 3 and fid 2 are both clones of fid 1.
However, thanks for the alternative workaround. If you get a chance, can
you check
That patch looks fine by me. Happy to put it in the queue. Thanks Al.
On Tue, Apr 14, 2015 at 11:07 AM Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Apr 13, 2015 at 04:05:28PM +, Eric Van Hensbergen wrote:
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according
On Tue, Apr 14, 2015 at 04:19:41PM +, Eric Van Hensbergen wrote:
That patch looks fine by me. Happy to put it in the queue. Thanks Al.
OK... Here's one more:
9p: don't bother with __getname() in -follow_link()
We copy there a kmalloc'ed string and proceed to kfree that string
Hi,
for what it's worth, the sample code given works with nfs-ganesha
server, so I'm not sure what's not working here.
Here's the server traces:
TATTACH: tag=1 fid=0 afid=-1 uname='nobody' aname='/export' n_uname=-1
RATTACH: tag=1 fid=0 qid=(type=128,version=0,path=1)
TGETATTR: tag=1 fid=0
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according to the protocol. fid 3 and fid 2 are both clones of fid 1.
However, thanks for the alternative workaround. If you get a chance, can
you check that my change to the client to partially fix this for the other
servers
** Bug watch added: Red Hat Bugzilla #1114221
https://bugzilla.redhat.com/show_bug.cgi?id=1114221
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794
Title:
9pfs does not honor open file
I've done some digging from the client side. As is mentioned in Miklos'
original patch (which appears to have been shot down) the higher level
implementation appear to be broken for this. Here's what the code looks
like for fstat in fs/stat.c:
int vfs_fstat(unsigned int fd, struct kstat *stat)
On Sun, Apr 12, 2015 at 12:42:35PM -, Eric Van Hensbergen wrote:
In other words, it only uses the open fd to derrive a path and then
executes the getattr off of that path. If that path no longer exists
(because of unlink or remove) then you are hosed. In my understanding, the
work
On Sun, Apr 12, 2015 at 9:09 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun, Apr 12, 2015 at 12:42:35PM -, Eric Van Hensbergen wrote:
In other words, it only uses the open fd to derrive a path and then
executes the getattr off of that path. If that path no longer exists
(because
29 matches
Mail list logo