On Mittwoch, 4. September 2019 15:02:30 CEST Christian Schoenebeck wrote:
> > > Well, mailman is handling this correctly. It replaces the "From:" field
> > > with a placeholder and instead adds my actual email address as
> > > "Reply-To:" field. That's the common way to handle this on mailing
> > >
From: Christian Schoenebeck
stat_to_qid attempts via qid_path_prefixmap to map unique files (which are
identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value.
However this implementation makes some assumptions about inode number
generation on the host.
If qid_path_prefixmap f
This is v7 of a proposed patch set for fixing file ID collisions with 9pfs.
v6->v7:
* Rebased to https://github.com/gkurz/qemu/commits/9p-next
(SHA1 7fc4c49e91).
* Be pedantic and abort with error on wrong value for new command line
argument 'multidevs'.
* Adjusted patches to qemu
From: Christian Schoenebeck
Use variable length suffixes for inode remapping instead of the fixed
16 bit size prefixes before. With this change the inode numbers on guest
will typically be much smaller (e.g. around >2^1 .. >2^7 instead of >2^48
with the previous fixed size inode remapping.
Addit
From: Christian Schoenebeck
'warn' (default): Only log an error message (once) on host if more than one
device is shared by same export, except of that just ignore this config
error though. This is the default behaviour for not breaking existing
installations implying that they really know what t
On Dienstag, 3. September 2019 21:38:15 CEST Eric Blake wrote:
> On 9/2/19 5:29 PM, Christian Schoenebeck via Qemu-devel wrote:
> >>>>> === OUTPUT BEGIN ===
> >>>>> 1/4 Checking commit bb69de63f788 (9p: Treat multiple devices on one
> >>>>>
s to have some coding style problems. See output below
> > > > for
> >
> > > > more information:
> > [snip]
> >
> > > > === OUTPUT BEGIN ===
> > > > 1/4 Checking commit bb69de63f788 (9p: Treat multiple devices on one
> > > &g
On Montag, 2. September 2019 13:49:34 CEST Greg Kurz wrote:
> On Sun, 01 Sep 2019 20:56:16 +0200
>
> Christian Schoenebeck wrote:
> > On Freitag, 30. August 2019 14:22:38 CEST Greg Kurz wrote:
> > > Some more comments below.
> >
> > [snip]
> >
> > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
>
On Montag, 2. September 2019 12:16:26 CEST Greg Kurz wrote:
> > > > @@ -571,22 +572,109 @@ static void coroutine_fn virtfs_reset(V9fsPDU
> > > > *pdu)
> > > >
> > > > P9_STAT_MODE_NAMED_PIPE | \
> > > > P9_STAT_MODE_SOCKET)
> > >
On Freitag, 30. August 2019 13:48:27 CEST Greg Kurz wrote:
> > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > > index 8cc65c2c67..39c6c2a894 100644
> > > --- a/hw/9pfs/9p.c
> > > +++ b/hw/9pfs/9p.c
> >
> > [snip]
> >
> > > @@ -1940,6 +2041,19 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU
> >
problem? I mean every patch still has my signed-off-by tag with the correct
email address ending up in git history.
The cause for this issue is that the domain is configured to require DKIM
signatures for all outgoing emails. That's why mailman replaces my address by
"Christian Schoene
On Freitag, 30. August 2019 14:22:38 CEST Greg Kurz wrote:
> Some more comments below.
[snip]
> > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > index 8cc65c2c67..c96ea51116 100644
> > --- a/hw/9pfs/9p.c
> > +++ b/hw/9pfs/9p.c
> > @@ -25,6 +25,7 @@
> >
> > #include "trace.h"
> > #include "migratio
On Donnerstag, 29. August 2019 18:55:28 CEST Greg Kurz wrote:
> > diff --git a/fsdev/qemu-fsdev-opts.c b/fsdev/qemu-fsdev-opts.c
> > index 7c31af..07a18c6e48 100644
> > --- a/fsdev/qemu-fsdev-opts.c
> > +++ b/fsdev/qemu-fsdev-opts.c
> > @@ -31,7 +31,9 @@ static QemuOptsList qemu_fsdev_opts = {
On Donnerstag, 29. August 2019 18:27:30 CEST Greg Kurz wrote:
> > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > index 586a6dccba..8cc65c2c67 100644
> > --- a/hw/9pfs/9p.c
> > +++ b/hw/9pfs/9p.c
> > @@ -572,10 +572,18 @@ static void coroutine_fn virtfs_reset(V9fsPDU *pdu)
> >
> >
Use variable length suffixes for inode remapping instead of the fixed
16 bit size prefixes before. With this change the inode numbers on guest
will typically be much smaller (e.g. around >2^1 .. >2^7 instead of >2^48
with the previous fixed size inode remapping.
Additionally this solution is more
This is v6 of a proposed patch set for fixing file ID collisions with 9pfs.
v5->v6:
* Rebased to https://github.com/gkurz/qemu/commits/9p-next
(SHA1 177fd3b6a8).
* Replaced previous boolean option 'remap_inodes' by tertiary option
'multidevs=remap|forbid|warn', where 'warn' is the ne
The QID path should uniquely identify a file. However, the
inode of a file is currently used as the QID path, which
on its own only uniquely identifies files within a device.
Here we track the device hosting the 9pfs share, in order
to prevent security issues with QID path collisions from
other dev
stat_to_qid attempts via qid_path_prefixmap to map unique files (which are
identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value.
However this implementation makes some assumptions about inode number
generation on the host.
If qid_path_prefixmap fails, we still have 48 bits av
'warn' (default): Only log an error message (once) on host if more than one
device is shared by same export, except of that just ignore this config
error though. This is the default behaviour for not breaking existing
installations implying that they really know what they are doing.
'forbid': Like
On Mittwoch, 3. Juli 2019 13:13:26 CEST Christian Schoenebeck wrote:
> To support multiple devices on the 9p share, and avoid
> qid path collisions we take the device id as input
[snip]
> - Fixed v9fs_do_readdir() having exposed info outside
>export root with '..' entry.
[snip]
> diff
Use variable length suffixes for inode remapping instead of the fixed
16 bit size prefixes before. With this change the inode numbers on guest
will typically be much smaller (e.g. around >2^1 .. >2^7 instead of >2^48
with the previous fixed size inode remapping.
Additionally this solution is more
The QID path should uniquely identify a file. However, the
inode of a file is currently used as the QID path, which
on its own only uniquely identifies files within a device.
Here we track the device hosting the 9pfs share, in order
to prevent security issues with QID path collisions from
other dev
To support multiple devices on the 9p share, and avoid
qid path collisions we take the device id as input
to generate a unique QID path. The lowest 48 bits of
the path will be set equal to the file inode, and the
top bits will be uniquely assigned based on the top
16 bits of the inode and the devic
There is no need for signedness on these QID fields for 9p.
Signed-off-by: Antonios Motakis
[CS: - Also make QID type unsigned.
- Adjust donttouch_stat() to new types.
- Adjust trace-events to new types. ]
Signed-off-by: Christian Schoenebeck
---
fsdev/9p-marshal.h | 6 +++---
hw/9
stat_to_qid attempts via qid_path_prefixmap to map unique files (which are
identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value.
However this implementation makes some assumptions about inode number
generation on the host.
If qid_path_prefixmap fails, we still have 48 bits av
This is v5 of a proposed patch set for fixing file ID collisions with 9pfs.
v4->v5:
All Patches:
* Added details to individual commit logs of what has been changed
exactly by me on top of Antonios' original 4 patches.
Patch 1:
* Fixed format specifiers in hw/9pfs/trace-events.
P
On Freitag, 28. Juni 2019 16:56:15 CEST Christian Schoenebeck via Qemu-devel
> > > + */
> > > +#define EXP_GOLOMB_K0
> > > +
> > > +# if !EXP_GOLOMB_K
> > > +
> > > +/** @brief Exponential Golomb algorithm limited to the case k=0.
> &g
On Freitag, 28. Juni 2019 16:23:08 CEST Greg Kurz wrote:
> > > This feature applies to all backends IIUC. We don't really care for the
> > > synth backend since it generates non-colliding inode numbers by design,
> > > but the proxy backend has the same issue as local. So...
> >
> > Yeah, I was no
On Freitag, 28. Juni 2019 13:50:15 CEST Greg Kurz wrote:
> > And with k=5 they would look like:
> >
> > Index Dec/Bin -> Generated Suffix Bin
> > 1 [1] -> [01] (6 bits)
> > 2 [10] -> [11] (6 bits)
> > 3 [11] -> [010001] (6 bits)
> > 4 [100] -> [110001] (6 bits)
> > 5 [101] -> [001001] (6 b
On Freitag, 28. Juni 2019 12:09:31 CEST Greg Kurz wrote:
> On Wed, 26 Jun 2019 20:42:13 +0200
>
> Christian Schoenebeck via Qemu-devel wrote:
> > To support multiple devices on the 9p share, and avoid
> > qid path collisions we take the device id as input
> > to gene
On Freitag, 28. Juni 2019 12:21:20 CEST Greg Kurz wrote:
> > +static int qid_path_fullmap(V9fsPDU *pdu, const struct stat *stbuf,
> > +uint64_t *path)
> > +{
> > +QpfEntry lookup = {
> > +.dev = stbuf->st_dev,
> > +.ino = stbuf->st_ino
> > +}, *va
On Donnerstag, 27. Juni 2019 19:26:22 CEST Greg Kurz wrote:
> On Wed, 26 Jun 2019 20:30:41 +0200
>
> Christian Schoenebeck via Qemu-devel wrote:
> > The QID path should uniquely identify a file. However, the
> > inode of a file is currently used as the QID path, whic
On Donnerstag, 27. Juni 2019 18:12:03 CEST Greg Kurz wrote:
> On Wed, 26 Jun 2019 20:25:55 +0200
> Christian Schoenebeck via Qemu-devel wrote:
> > There is no need for signedness on these QID fields for 9p.
> >
> > Signed-off-by: Antonios Motakis
>
> You shoul
This is v4 of a proposed patch set for fixing file ID collisions with 9pfs.
v3->v4:
* Rebased to latest git master head.
* Splitted Antonios' patch set to its original 4 individual patches.
(was merged previously as only 1 patch).
* Addressed discussed issues directly on Antonios' pat
stat_to_qid attempts via qid_path_prefixmap to map unique files (which are
identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value.
However this implementation makes some assumptions about inode number
generation on the host.
If qid_path_prefixmap fails, we still have 48 bits av
To support multiple devices on the 9p share, and avoid
qid path collisions we take the device id as input
to generate a unique QID path. The lowest 48 bits of
the path will be set equal to the file inode, and the
top bits will be uniquely assigned based on the top
16 bits of the inode and the devic
Use variable length suffixes for inode remapping instead of the fixed 16
bit size prefixes before. With this change the inode numbers on guest will
typically be much smaller (e.g. around >2^1 .. >2^7 instead of >2^48 with
the previous fixed size inode remapping.
Additionally this solution should b
The QID path should uniquely identify a file. However, the
inode of a file is currently used as the QID path, which
on its own only uniquely identifies wiles within a device.
Here we track the device hosting the 9pfs share, in order
to prevent security issues with QID path collisions from
other dev
There is no need for signedness on these QID fields for 9p.
Signed-off-by: Antonios Motakis
Signed-off-by: Christian Schoenebeck
---
fsdev/9p-marshal.h | 6 +++---
hw/9pfs/9p.c | 6 +++---
hw/9pfs/trace-events | 14 +++---
3 files changed, 13 insertions(+), 13 deletions(-)
On Montag, 3. Juni 2019 08:57:15 CEST Greg Kurz wrote:
> > Ok, I will extend Antonios' patch to log that error on host. I thought
> > about limiting that error message to once per session (for not flooding
> > the logs), but it is probably not worth it, so if you don't veto then I
> > will just log
On Montag, 20. Mai 2019 16:05:09 CEST Greg Kurz wrote:
> Hi Christian,
Hi Greg,
> On the other hand, I'm afraid that having a functional solution won't
> motivate people to come up with a new spec... Anyway, I agree that the
> data corruption/loss issues must be prevented, ie, the 9p server shoul
On Freitag, 17. Mai 2019 16:47:46 CEST Greg Kurz wrote:
> Potentially yes if another approach is satisfying enough, as I wouldn't
> want to over-engineer too much around this 9p imposed limitation. The
> right thing to do would be to come up with a new version of the protocol
> with variable sized
On Freitag, 17. Mai 2019 14:30:29 CEST Greg Kurz wrote:
> Then, we come to the bulk problem: how to handle the case where we
> have multiple devices involved in a directory we want to share ?
> Antonios's proposal is a clever way to address the collisions, but
> your work proves it isn't enough...
On Dienstag, 7. Mai 2019 18:16:08 CEST Christian Schoenebeck wrote:
> Here are the archive links for latest v3 patch set [5(+1) patches total]:
>
> [PATCH v3 0/5] 9p: Fix file ID collisions:
> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01143.html
>
> [PATCH v3 1/5] 9p: mitigates mos
On Dienstag, 7. Mai 2019 17:42:39 CEST Greg Kurz wrote:
> > Sorry that I caused a bit of confusion, You were actually commenting
> > mostly on v2 of the patch set, where my email client replaced the message
> > IDs and hence screwed threading.
> >
> > This is v3 that I sent yesterday and which has
On Dienstag, 7. Mai 2019 13:57:56 CEST Daniel P. Berrangé wrote:
> > ...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Like with the vii qemu virtfs command line argument, the order of the
> > "importan
On Dienstag, 7. Mai 2019 13:42:47 CEST Daniel P. Berrangé wrote:
> > This first patch here is an updated version of Antonios Motakis'
> > original 4-patch set (using fixed length 16 bit prefixes), merged to one
> > patch:
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
On Dienstag, 7. Mai 2019 11:55:56 CEST Greg Kurz wrote:
> > support the 'vii' feature of patch 5, which introduces the XML config
>
> What is patch 5 ?!? What is 'vii' ? I am a bit lost here...
Hi Greg,
Sorry that I caused a bit of confusion, You were actually commenting mostly on
v2 of the pat
This is the counter part patch against latest libvirt git master head to
support the 'vii' feature of patch 5, which introduces the XML config
XML tag "important" on libvirt side.
To stick with the previous example mentioned with patch 5, likewise
libvirt XML configuration might then look like thi
This is v3 of a proposed patch set for fixing file ID collisions with 9pfs.
That's it from my side for now regarding this overall issue. I am waiting for
your comments on this patch set before doing anything else.
Patch 1 to 4 are identical to the previous version. New patch 5 adds an
optional q
This patch aims to keep QID path identical beyond the scope of reboots and
guest suspensions. With the 1st patch alone the QID path of the same files
might change after reboots / suspensions, since 9p would restart with
empty qpp_table and the resulting QID path depends on the precise sequence
of f
This first patch here is an updated version of Antonios Motakis'
original 4-patch set (using fixed length 16 bit prefixes), merged to one
patch:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
* Updated to latest git master, specifically to new qht interface.
* Merged the ori
This patch introduces variable length suffixes for being used for inode mapping
instead of the fixed 16 bit size prefixes of patch 1. With this patch the inode
numbers on guest will typically be much smaller (e.g. around >2^1 .. >2^7
instead of >2^48 with patch 1).
I preserved both solutions in th
Addresses trivial changes regarding the previous patch as requested
on the mailing list a while ago.
* Removed unneccessary parantheses:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02661.html
* Removed unneccessary g_malloc() result checks:
https://lists.gnu.org/archive/html/qemu
This patch adds an optional qemu device parameter "vii" (very important
inode[s]), which accepts a colon separated list of pathes relative below
the 9p export root, which shall be given the smallest inode suffix (and
hence largest possible inode namespace on guest) according to the given
order. Tha
This patch introduces variable length suffixes for being used for inode mapping
instead of the fixed 16 bit size prefixes of patch 1. With this patch the inode
numbers on guest will typically be much smaller (e.g. around >2^1 .. >2^7
instead of >2^48 with patch 1).
I preserved both solutions in th
This patch aims to keep QID path identical beyond the scope of reboots and
guest suspensions. With the 1st patch alone the QID path of the same files
might change after reboots / suspensions, since 9p would restart with
empty qpp_table and the resulting QID path depends on the precise sequence
of f
Addresses trivial changes regarding the previous patch as requested
on the mailing list a while ago.
* Removed unneccessary parantheses:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02661.html
* Removed unneccessary g_malloc() result checks:
https://lists.gnu.org/archive/html/qemu
Hi!
This is v2 of a proposed patch set for fixing file ID collisions with 9pfs.
Patch 1 to 3 are identical to the previous version. New in this v2 is patch 4
which introduces variable length suffixes for inode mapping instead of fixed
length prefixes.
Also: patch 4 disables file ID persistency a
This first patch here is an updated version of Antonios Motakis'
original 4-patch set, merged to one patch:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
* Updated to latest git master, specifically to new qht interface.
* Merged the original 4 patches to this single patch.
On Dienstag, 23. April 2019 13:44:42 CEST Greg Kurz wrote:
> Hi Christian,
>
> Sorry for the late response. I'm quite busy on other topics these days...
Absolutely no problem. We probably all share the same fate of constant work
load on endless battle fields popping up everywhere. :-)
> > I int
This patch aims to keep QID path identical beyond the scope of reboots and
guest suspensions. With the 1st patch alone the QID path of the same files
might change after reboots / suspensions, since 9p would restart with
empty qpp_table and the resulting QID path depends on the precise sequence
of f
Addresses trivial changes regarding the previous patch as requested
on the mailing list a while ago.
* Removed unneccessary parantheses:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02661.html
* Removed unneccessary g_malloc() result checks:
https://lists.gnu.org/archive/html/qemu
I am attempting to revive Antonios Motakis' effort to fix the current file
ID collisions with 9p. My patch set does not fix all the concerns you had
with his original patch set, especially if there is still some (very rare)
case of QID path collision the affected files are still visible on guest.
H
On Samstag, 30. März 2019 21:01:28 CEST Christian Schoenebeck wrote:
> On Samstag, 30. März 2019 17:47:51 CET Greg Kurz wrote:
> > Maybe have a look at this tentative to fix QID collisions:
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
[snip]
> Question: so far I just
On Samstag, 30. März 2019 17:47:51 CET Greg Kurz wrote:
> Maybe have a look at this tentative to fix QID collisions:
>
> https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
Interesting! My idea would have been different, based on my presumption that
the amount of devices on a 9p
Hi list,
currently the 9p implementation in qemu causes inode number collisions on
guest OS level if the directory exported by 9p consists on host level of more
than one file system being mounted inside that exported directory tree; which
leads to severe misbehaviours on guest side with all kin
67 matches
Mail list logo
