Re: [V9fs-developer] [PATCH] net: trans_rdma: remove unused function

the rdma_cancelled function again when this is sorted out :) Regards, -- Dominique Martinet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

Re: [V9fs-developer] [PATCH] net: trans_rdma: remove unused function

Hard morning, sorry for the double mail. Dominique Martinet wrote on Thu, Jul 25, 2013 : Well, I do care - but I couldn't find where the trans-cancelled member function was supposed to be called anyway... So adding it to the struct and fixing the warning is well and fine, but if it's still

Re: [V9fs-developer] [PATCH] net: trans_rdma: remove unused function

- TCP sessions timed out, I even got IO errors on the local disk :D) Regards, -- Dominique Martinet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please

Re: [V9fs-developer] [PATCH] net: trans_rdma: remove unused function

I think I need to stop sending mails before triple-checking things! So sorry for the multiple mails again. Dominique Martinet wrote on Thu, Jul 25, 2013 : [rdma_cancelled] There is one problem though - if the server handles the original request before getting the flush, the receive buffer

Re: [V9fs-developer] [PATCH] net: trans_rdma: remove unused function

Eric Van Hensbergen wrote on Fri, Jul 26, 2013 : It depends on the flags you use with 9p. If you mount with nodevmap it'll treat them like normal files. Alternatively you can use synthetics from fuse or even 9p file systems from Plan 9 port. Ok, thank you for the explanation. Now I need to

[PATCH RESEND] 9P: introduction of a new cache=mmap model.

- Add cache=mmap option - Make mmap read-write while keeping it as synchronous as possible - Build writeback fid on mmap creation if it is writable Signed-off-by: Dominique Martinet dominique.marti...@cea.fr Signed-off-by: Eric Van Hensbergen eri...@gmail.com --- The patch has been taken

[PATCH V2] 9P: introduction of a new cache=mmap model.

- Add cache=mmap option - Make mmap read-write while keeping it as synchronous as possible - Build writeback fid on mmap creation if it is writable Signed-off-by: Dominique Martinet dominique.marti...@cea.fr Signed-off-by: Eric Van Hensbergen eri...@gmail.com --- Same as previous

Re: [V9fs-developer] Unable to load modules from 9p filesystem with kmod 16

/lists/linux-virtualization/msg21716.html Which quotes This patch enables 9p-virtio to correctly handle this case. This not only enables us to load Linux kernel modules off virtfs, Perhaps would it be what you need to support this syscall_313? Good luck, -- Dominique Martinet -- To unsubscribe

[PATCH] 9P: fix return value in v9fs_fid_xattr_set

v9fs_fid_xattr_set is supposed to return 0 on success. This corrects the behaviour introduced in commit bdd5c28dcb8330b9074404cc92a0b83aae5606a 9p: fix return value in case in v9fs_fid_xattr_set() (The function returns a negative error on error, as expected) Signed-off-by: Dominique Martinet

[PATCH] 9P: Add memory barriers to protect request fields over cb/rpc threads handoff

. Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- include/net/9p/client.h | 2 +- net/9p/client.c | 16 +++- net/9p/trans_fd.c | 15 ++- net/9p/trans_rdma.c | 3 +-- net/9p/trans_virtio.c | 3 +-- 5 files changed, 24 insertions(+), 15

[PATCH 0/1] 9P: Add memory barriers to protect request fields over cb/rpc threads handoff

need to run more tests...) I'm also interested in any comment to make the commit message better; I tried to sum this whole thing up but I'm not sure I made it clear enough (the whole reason I need a 0/1 patch message!) Thank you for your time if you have read this far! :) Dominique Martinet (1

Re: [V9fs-developer] [PATCH] 9P: Add memory barriers to protect request fields over cb/rpc threads handoff

Hi, Dominique Martinet wrote on Fri, Jan 17, 2014 : We need barriers to guarantee this pattern works as intended: [w] req-rc, 1[r] req-status, 1 wmb rmb [w] req-status, 1[r] req-rc Where the wmb ensures that rc gets written before status, and the rmb

Re: v9fs does not honor open file handles on anonymous files

, -- Dominique Martinet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [V9fs-developer] [PATCH 1/8] fs/9p: Deletion of unnecessary checks before the function call p9_client_clunk

Dominique Martinet wrote on Tue, Jan 06, 2015 at 09:12:53AM +0100: Simple example, without even looking at the multiple possible interactions with multiple clients hammering the server, can be taken from v9fs_create in fs/9p/vfs_inode.c https://git.kernel.org/cgit/linux/kernel/git/next/linux

Re: [V9fs-developer] [PATCH 1/8] fs/9p: Deletion of unnecessary checks before the function call p9_client_clunk

. -- Dominique Martinet, CEA -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [V9fs-developer] [PATCH 1/8] fs/9p: Deletion of unnecessary checks before the function call p9_client_clunk

to suggest anything else, sorry :) Thanks, -- Dominique Martinet, CEA -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

[PATCH] fs/9p: Initialize status in v9fs_file_do_lock.

If p9_client_lock_dotl returns an error, status is possibly never filled but will be used in the following switch. Initializing it to P9_LOCK_ERROR makes sur we will return an error and cleanup (and not hit the default case). Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- fs/9p

[PATCH] net/9p: Initialize opts-privport as it should be.

We're currently using an uninitialized value if option privport is not set, thus (almost) always using a privileged port. Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- net/9p/trans_fd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c

[PATCH] net/9p: add a privport option for RDMA transport.

RDMA can use the same kind of weak security as TCP by checking the client can bind to a privileged port, which is better than nothing if TAUTH isn't implemented. Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- Please note that this does NOT checkpatch because option tokens

Re: [PATCH] fs/9p: Initialize status in v9fs_file_do_lock.

Kirill A. Shutemov wrote on Fri, Jan 09, 2015 at 02:33:53PM +0200: On Fri, Jan 09, 2015 at 12:56:07PM +0100, Dominique Martinet wrote: If p9_client_lock_dotl returns an error, status is possibly never filled but will be used in the following switch. Initializing it to P9_LOCK_ERROR makes

Re: [PATCH] fs/9p: Initialize status in v9fs_file_do_lock.

. No, if p9_client_lock_dotl() return 0 it must set status. If it's not, that's bug on p9_client_lock_dotl() side and must be fixed. I had that bit right, but I only remembered your second patch -- sorry. It should be fine with your patchES, please disregard this one. -- Dominique Martinet, CEA

[PATCH 2/2] net/9p: add a privport option for RDMA transport.

RDMA can use the same kind of weak security as TCP by checking the client can bind to a privileged port, which is better than nothing if TAUTH isn't implemented. Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- YES, this does not checkpatch, but I'm not changing all the old Opt_

[PATCH 1/2] net/9p: Initialize opts-privport as it should be.

We're currently using an uninitialized value if option privport is not set, thus (almost) always using a privileged port. Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- net/9p/trans_fd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c

[PATCH] NFSv4: handle nfs4_get_referral failure

nfs4_proc_lookup_common is supposed to return a posix error, we have to handle any error returned that isn't errno Reported-by: Olga Kornievskaia ko...@netapp.com Signed-off-by: Frank S. Filz ffilz...@mindspring.com Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- Other way

Re: [git pull] vfs part 2

Jeff Layton wrote on Thu, Jul 02, 2015: So p9_idpool_create should take an argument for the end value, and then store that in a new field in p9_idpool. Then they can pass that in as the end parm in idr_alloc. Or, they could give up using the same function there and use a different one for tags

Re: [git pull] vfs part 2

Al Viro wrote on Thu, Jul 02, 2015: On Thu, Jul 02, 2015 at 07:56:29PM +0200, Dominique Martinet wrote: Using cache=none here so behavious is likely different with cache, but basically you can't get more than one tag per user thread accessing the 9P mount... Yes, and...? You can get

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

Hugh Dickins wrote on Fri, Jul 31, 2015: On Fri, 31 Jul 2015, Linus Torvalds wrote: I'd be more suspicious about other effects. For example, iot's not at all obvious that the commit in question just changes the order of the flags/inode field accesses, there are potentialy bigger changes there.

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

Dominique Martinet wrote on Sat, Aug 01, 2015: I had to adapt a bit because using an old kernel (4bf46a272), will try again with a recent master to doublecheck There have been more changes than what I thought, can't seem to reproduce in a while on linus' HEAD with that fix (it fell

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

Hugh Dickins wrote on Fri, Jul 31, 2015: It will indeed be weird and odd if it confirms that DCACHE_DISCONNECTED revert is good. I agree that Dominique's 4bf46a272647 seems now more likely, if still unlikely; but that was included in v4.1, and I saw no problem with v4.1 once the rmap_walk()

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

a 9P/virtio mount and with multiple level of caches (memory barrier), I was able to track it down to 4bf46a272647d (VFS: Impose ordering on accesses of d_inode and d_flags) and debug a bit, but this isn't code I'm familiar with so would appreciate if you could tell me what you think. -- Dominique

[PATCH RESEND] 9p: do not overwrite return code when locking fails

If the remote locking fail, we run a local vfs unlock that should work and return success to userland when we didn't actually lock at all. We need to tell the application that tried to lock that it didn't get it, not that all went well. Signed-off-by: Dominique Martinet dominique.marti...@cea.fr

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

Al Viro wrote on Sat, Aug 01, 2015: And that has turned the check done to an inode that *was* ours at some point (i.e. fetching it had been followed by checking that -d_seq had been still valid) into something completely unprotected. Suppose we are in lazy mode and somebody had evicted

[PATCH] 9p: do not overwrite return code when locking fails

If the remote locking fail, we run a local vfs unlock that should work We need to tell the application that tried to lock that it didn't get it, not that all went well. Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- fs/9p/vfs_file.c | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH v2] 9p: trans_fd, bail out if recv fcall if missing

req->rc is pre-allocated early on with p9_tag_alloc and shouldn't be missing Signed-off-by: Dominique Martinet <dominique.marti...@cea.fr> --- net/9p/trans_fd.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) Feel free to adapt error code/message if you

[PATCH] 9p: trans_fd, read rework to use p9_parse_header

<r...@landley.net> Signed-Off-By: Dominique Martinet <dominique.marti...@cea.fr> --- net/9p/trans_fd.c | 75 +-- 1 file changed, 40 insertions(+), 35 deletions(-) It ended up alot bigger than I thought it'd be, submitting it anyw

[PATCH] 9p: trans_fd, initialize recv fcall properly if not set

That code really should never be called (rc is allocated in tag_alloc), but if it had been it couldn't have worked... Signed-off-by: Dominique Martinet <dominique.marti...@cea.fr> --- net/9p/trans_fd.c | 3 +++ 1 file changed, 3 insertions(+) To be honest, I think it might be better t

Re: [V9fs-developer] [PATCH] 9p: trans_fd, initialize recv fcall properly if not set

Eric Van Hensbergen wrote on Sat, Sep 05, 2015: > On Thu, Sep 3, 2015 at 4:38 AM, Dominique Martinet > <dominique.marti...@cea.fr> wrote: > > To be honest, I think it might be better to just bail out if we get in > > this switch (m->req->rc == NULL after p9_tag_looku

Re: [V9fs-developer] Hang triggered by udev coldplug, looks like a race

Dominique Martinet wrote on Wed, Dec 09, 2015: > Andy Lutomirski wrote on Tue, Dec 08, 2015: > > Trace attached. I don't see anything wrong, but I also don't know > > what I'm looking for. > > Actually doesn't look good, not sure if trace could be missing messages > bu

Re: [V9fs-developer] Hang triggered by udev coldplug, looks like a race

^[0-9]* R/ { if (! $5 in tag ) { print "MISSTAG " $0; } else { delete tag[$5]; } }' -- Dominique Martinet 9pdoubles.xz Description: Binary data

Re: [V9fs-developer] Hang triggered by udev coldplug, looks like a race

-P 1024 -I{} cat /sbin/foo >&/dev/null` ? (trying execs might be closer to your workload, not sure how much this or using umh might change) Also, what qemu version please just to try to match your environment ? -- Dominique Martinet -- To unsubscribe from this list: send the line "unsu

Re: [V9fs-developer] Hang triggered by udev coldplug, looks like a race

Peter Zijlstra wrote on Mon, Jan 04, 2016 at 04:59:15PM +0100: > On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote: > > [add cc's] > > > > Hi scheduler people: > > > > This is relatively easy for me to reproduce. Any hints for debugging > > it? Could we really have a bug in which

Re: [V9fs-developer] Hang triggered by udev coldplug, looks like a race

3 or 4 and both can reproduce it; cpu usage on the host is always low so it doesn't look like there's any busy-polling involved.. This is a pretty subtle bug we have there.. -- Dominique Martinet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a m

Re: [PATCH 0/3] fs/9p: fix setattr/getattr issues with open files

Hi Greg, Greg Kurz wrote on Mon, Jul 04, 2016 at 05:08:49PM +0200: > On Mon, 4 Jul 2016 16:16:55 +0200 > Dominique Martinet <dominique.marti...@cea.fr> wrote: > > > I *think* this introduces a race somewhere, I'm getting errors like: > > cat: f.05: No such file

Re: [PATCH 0/3] fs/9p: fix setattr/getattr issues with open files

I *think* this introduces a race somewhere, I'm getting errors like: cat: f.05: No such file or directory cat: f.14: No such file or directory cat: f.13: No such file or directory cat: f.39: No such file or directory cat: f.05: No such file or directory when doing: for file in {01..50}; do

Re: [V9fs-developer] [PATCH 4/5] 9p: introduce async read requests

Stefano Stabellini wrote on Thu, Dec 08, 2016: > If the read is an async operation, send a 9p request and return > EIOCBQUEUED. Do not wait for completion. > > Complete the read operation from a callback instead. > > Signed-off-by: Stefano Stabellini > --- >

Re: [V9fs-developer] [PATCH 2/5] 9p: store req details and callback in struct p9_req_t

EXPORT_SYMBOL(p9_client_cb); Mostly a warning here, but p9_client_cb is called from an interrupt context in 9P/RDMA. This has been working up till now because we only do a wake_up and there's no waiting, but (looking at later patches), p9_client_read_complete for example does allocations and possibly other unsafe operations from an interrupt context. I don't know if the way forward is to move p9_client_cb from that context or to have the callback be scheduled in a work queue instead; but we'll need to fix that later. -- Dominique Martinet

Re: [V9fs-developer] [PATCH 2/2] net/9p: add a per-client fcall kmem_cache

Greg Kurz wrote on Wed, Aug 01, 2018: > > diff --git a/net/9p/client.c b/net/9p/client.c > > index ba99a94a12c9..215e3b1ed7b4 100644 > > --- a/net/9p/client.c > > +++ b/net/9p/client.c > > @@ -231,15 +231,34 @@ static int parse_opts(char *opts, struct p9_client > > *clnt) > > return ret; > >

Re: [V9fs-developer] [PATCH 1/2] net/9p: embed fcall in req to round down buffer allocs

Greg Kurz wrote on Wed, Aug 01, 2018: > > @@ -263,13 +261,13 @@ p9_tag_alloc(struct p9_client *c, int8_t type, > > unsigned int max_size) > > if (!req) > > return NULL; > > > > - req->tc = p9_fcall_alloc(alloc_msize); > > - req->rc = p9_fcall_alloc(alloc_msize); > > - if

Re: [PATCH v2 1/2] net/9p: embed fcall in req to round down buffer allocs

Greg Kurz wrote on Thu, Aug 02, 2018: > > @@ -443,9 +444,9 @@ static int rdma_request(struct p9_client *client, > > struct p9_req_t *req) > > **/ > > if (unlikely(atomic_read(>excess_rc) > 0)) { > > if ((atomic_sub_return(1, >excess_rc) >= 0)) { > > - /* Got

Re: [V9fs-developer] INFO: task hung in grab_super

Dmitry Vyukov via V9fs-developer wrote on Wed, Jul 18, 2018: > >> Btw, I see that p9_client_rpc uses wait_event_killable, why wasn't it > >> killed along with the whole process? > >> > > > > wait_event_killable() would return -ERESTARTSYS if got SIGKILL. > > But if (c->status == Connected) &&

Re: [V9fs-developer] [PATCH v2] net/9p/trans_virtio.c: add null terminal for mount tag

piaojun wrote on Fri, Aug 03, 2018: > We'd better reach an agreement about the patch fix. The way I read Greg's comment was that he agreed to the proposed changes and is waiting for a new version. I'm writing a longer reply than I should because I don't like people saying strncmp is safe just

Re: [V9fs-developer] [PATCH v2] net/9p/trans_virtio.c: add null terminal for mount tag

Dominique Martinet wrote on Fri, Aug 03, 2018: > (the code is currently not safe if it returns an error, I'm sending > another mail about it right after this one as we already have a partial > fix) I take that one back, ksys_mount() does check for error properly so just the null check

Re: [PATCH v3] net/9p/trans_virtio.c: add null terminal for mount tag

piaojun wrote on Fri, Aug 03, 2018: > chan->tag is Non-null terminated which will result in printing messy code > when debugging code. So we should add '\0' for tag to make the code more > convenient and robust. In addition, I drop char->tag_len to simplify the > code. LGTM, I'll pick this up.

Re: [V9fs-developer] [PATCH 1/2] net/9p: embed fcall in req to round down buffer allocs

piaojun wrote on Tue, Jul 31, 2018: > This is really a *big* patch, but the modification seems no harm. And I > suggest running testcases to cover this. Please see my comments below. I'm always running tests, but more never hurt - please help ;) For reference I'm running a subset of cthon04[1],

Re: [V9fs-developer] [PATCH 2/2] net/9p: add a per-client fcall kmem_cache

piaojun wrote on Tue, Jul 31, 2018: > Could you help paste some test result before-and-after the patch applied? The only performance tests I did were sent to the list a couple of mails earlier, you can find it here: http://lkml.kernel.org/r/20180730093101.GA7894@nautica In particular, the

Re: [PATCH] net/9p/trans_virtio.c: add a terminal char for mount tag

piaojun wrote on Wed, Aug 01, 2018: > chan->tag has no terminal char at last which will result in printing messy > code when debugging code. So we should add '\0' for tag. 9p is full of non null-terminated string so I'm not sure how I feel about it, is there anything wrong with how this is used

Re: [PATCH] net/9p/trans_virtio.c: add a terminal char for mount tag

Greg Kurz wrote on Wed, Aug 01, 2018: > So this patch basically turns chan->tag into a nul terminated string, > which is indeed more convenient and robust. Maybe you can update the > rest of the code accordingly and drop chan->tag_len then ? If we can use that to simplify some other part of the

Re: [PATCH v2] net/9p/trans_virtio.c: add null terminal for mount tag

piaojun wrote on Thu, Aug 02, 2018: > chan->tag is Non-null terminated which will result in printing messy code > when debugging code. So we should add '\0' for tag to make the code more > convenient and robust. In addition, I drop char->tag_len to simplify the > code. Some new lines in commit

Re: [V9fs-developer] [PATCH v2 2/2] net/9p: add a per-client fcall kmem_cache

Dominique Martinet wrote on Thu, Aug 02, 2018: > [...] > + clnt->fcall_cache = kmem_cache_create("9p-fcall-cache", clnt->msize, > + 0, 0, NULL); Well, my gut feeling that I'd need a v3 was right, after a bit more time te

[PATCH v2 1/2] net/9p: embed fcall in req to round down buffer allocs

From: Dominique Martinet 'msize' is often a power of two, or at least page-aligned, so avoiding an overhead of two dozen bytes for each allocation will help the allocator do its work and reduce memory fragmentation. Suggested-by: Matthew Wilcox Signed-off-by: Dominique Martinet Cc: Matthew

[PATCH v2 2/2] net/9p: add a per-client fcall kmem_cache

From: Dominique Martinet Having a specific cache for the fcall allocations helps speed up allocations a bit, especially in case of non-"round" msizes. The caches will automatically be merged if there are multiple caches of items with the same size so we do not need to try to sha

Re: [PATCH 2/2] net/9p: add a per-client fcall kmem_cache

Matthew Wilcox wrote on Mon, Jul 30, 2018: > On Mon, Jul 30, 2018 at 11:34:23AM +0200, Dominique Martinet wrote: > > -static int p9_fcall_alloc(struct p9_fcall *fc, int alloc_msize) > > +static int p9_fcall_alloc(struct p9_client *c, struct p9_fcall *fc, > > +

Re: [PATCH v2 5/6] 9p: Use a slab for allocating requests

Dominique Martinet wrote on Mon, Jul 23, 2018: > I'll try to get figures for various approaches before the merge window > for 4.19 starts, it's getting closer though... Here's some numbers; with v4.18-rc7 + current test tree (my 9p-next) as a base. For the context, I'm running on VMs tha

[PATCH 1/2] net/9p: embed fcall in req to round down buffer allocs

From: Dominique Martinet 'msize' is often a power of two, or at least page-aligned, so avoiding an overhead of two dozen bytes for each allocation will help the allocator do its work and reduce memory fragmentation. Suggested-by: Matthew Wilcox Signed-off-by: Dominique Martinet --- include

[PATCH 2/2] net/9p: add a per-client fcall kmem_cache

From: Dominique Martinet Having a specific cache for the fcall allocations helps speed up allocations a bit, especially in case of non-"round" msizes. The caches will automatically be merged if there are multiple caches of items with the same size so we do not need to try to sha

Re: [PATCH] net/9p/trans_virtio.c: decrease the refcount of 9p virtio device when removing it

piaojun wrote on Thu, Aug 09, 2018: > > What exact kernel commit are you running? > > My kernel commit id 6edf1d4cb0acde, and I replace the 9p code with > 9p-next. And I wonder if this will work well? That is somewhere on top of 4.18-rc1 and got merged in 4.18-rc4, which are close enough so while

[PATCH v3 2/2] net/9p: add a per-client fcall kmem_cache

From: Dominique Martinet Having a specific cache for the fcall allocations helps speed up allocations a bit, especially in case of non-"round" msizes. The caches will automatically be merged if there are multiple caches of items with the same size so we do not need to try to sha

[PATCH v3 1/2] net/9p: embed fcall in req to round down buffer allocs

From: Dominique Martinet 'msize' is often a power of two, or at least page-aligned, so avoiding an overhead of two dozen bytes for each allocation will help the allocator do its work and reduce memory fragmentation. Suggested-by: Matthew Wilcox Signed-off-by: Dominique Martinet Reviewed

[PATCH] 9p: Remove Ron Minnich from MAINTAINERS

From: Dominique Martinet Ron Minnich has left Sandia in 2011, and has not been involved in any 9p commit in the recent years. Signed-off-by: Dominique Martinet Cc: Eric Van Hensbergen Cc: Ron Minnich Cc: Ronald G. Minnich Cc: Latchesar Ionkov --- Thanks for agreeing Ron. MAINTAINERS | 1

Re: [PATCH] net/9p/trans_virtio.c: decrease the refcount of 9p virtio device when removing it

piaojun wrote on Wed, Aug 08, 2018: > I try to remove 9pnet_virtio.ko by 'rmmod 9pnet_virtio' as I want to > replace it without rebooting system. I do that all the time when testing, it works for me. What exact kernel commit are you running? > Here I have not mount 9pfs yet, so the refcount is

Re: [PATCH] net/9p/trans_virtio.c: decrease the refcount of 9p virtio device when removing it

piaojun wrote on Wed, Aug 08, 2018: > I found that 9pnet_virtio.ko could not be removed by rmmod command, and I > could still found it by lsmod. The reason is that we forgot decrease the > refcount of 9p virtio device by kobject_put. So we should put refcount in > p9_virtio_remove. Hmm, I cannot

Re: [PATCH 18/18] cpupower: change strncpy+truncation to strlcpy

ch for now. Shuah, could you take the patch off please if you haven't pushed it to linus yet? Sorry for the time you might have spent on this, -- Dominique Martinet

[PATCH v2] 9p: Remove Ron Minnich from MAINTAINERS

From: Dominique Martinet Ron Minnich has left Sandia in 2011, and has not been involved in any 9p commit in the recent years. Signed-off-by: Dominique Martinet Cc: Eric Van Hensbergen Cc: Ron Minnich Cc: Ronald G. Minnich Cc: Latchesar Ionkov To: Andrew Morton --- v2: added CREDITS entry

Re: [PATCH v3 2/2] net/9p: add a per-client fcall kmem_cache

piaojun wrote on Fri, Aug 10, 2018: > Could you help paste the test result of before-after-applied this patch in > comment? And please see my comments below. Thanks the the review, do you mean the commit message? I'll add the summary I wrote in reply to your question a few mails before. > >

[PATCH] 9p: Add Dominique Martinet to MAINTAINERS

From: Dominique Martinet Signed-off-by: Dominique Martinet Cc: Eric Van Hensbergen Cc: Latchesar Ionkov Cc: Ron Minnich Cc: Andrew Morton --- I've had an off-list Ack from Lucho and Eric about adding myself, and got reminded I should probably do it sooner than later by Andrew. Could

Re: [PATCH] compiler-gcc: get back Clang build

meanwhile.. -- Dominique Martinet

Re: [PATCH] compiler-gcc: get back Clang build

Joe Perches wrote on Tue, Aug 21, 2018: > On Wed, 2018-08-22 at 06:16 +0200, Dominique Martinet wrote: > > I think that could work, but at the point making a separate > > compiler-common.h and not including compiler-gcc.h for clang sounds > > better to me... More importantly

Re: [PATCH] compiler-gcc: get back Clang build

r is necessary to compiler-clang.h? I think that could work, but at the point making a separate compiler-common.h and not including compiler-gcc.h for clang sounds better to me... More importantly here, either solution sound complex enough to require more than a few days and proper testing for all archs etc when compared to the partial revert we have here. -- Dominique Martinet

Re: [PATCH] compiler-gcc: get back Clang build

, they weren't here in the compiler-gcc.h file in the previous version? There might be other defines the simple examples I ran do not use but from a quick glance it doesn't look like it, thank you for the split work! -- Dominique Martinet

Re: [PATCH] include/linux/compiler*.h: make compiler-*.h mutually exclusive

Nick Desaulniers wrote on Wed, Aug 22, 2018: > Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6") > recently exposed a brittle part of the build for supporting non-gcc > compilers. > > Both Clang and ICC define __GNUC__, __GNUC_MINOR__, and > __GNUC_PATCHLEVEL__ for quick

Re: [PATCH] include/linux/compiler*.h: make compiler-*.h mutually exclusive

Linus Torvalds wrote on Wed, Aug 22, 2018: > I've fixed that manually, but when I tried to test it I just hit the > > arch/x86/Makefile:179: *** Compiler lacks asm-goto support.. Stop. > > error. > > Do you have some experimental clang build with asm goto support? What > version? Or is it

Re: [PATCH] include/linux/compiler*.h: make compiler-*.h mutually exclusive

is case it looks like the arguments are only used for sanity with __asmeq but in the first place the original commit for trusted foundations talks about it not respecting the API so naked makes sense but they're not making the API function naked (and the one which takes an argument does use its argument) so this all feels a bit weird to me. It might be worth asking the original authors on this one... -- Dominique Martinet

KASAN error in [PATCH v3 7/8] proc/kcore: optimize multiple page reads

+ if (start >= m->addr && > + start < m->addr + m->size) > + break; > + } > } > > if (>list == _head) { -- Dominique Martinet

[PATCH] proc/kcore: fix invalid memory access in multi-page read optimization

ze multiple page reads") Signed-off-by: Dominique Martinet --- I guess now I'm looking at bf991c2231117 again that it would be slightly more efficient to remove the !m check and initialize m to point to kclist_head like this: m = list_entry(_head, struct kcore_list, list); but it feels a

Re: KASAN: invalid-free in p9stat_free

of pattern nowadays? The struct is cleanly zeroed before being read so there is no risk of double-frees between iterations so zeroing pointers is not strictly required, but it does make things safer in general. -- Dominique Martinet

Re: [V9fs-developer] KASAN: use-after-free Read in generic_perform_write

ght now (the design assumes that the write has to have finished by the time reply came), but if we want to protect ourselves from rogue servers we'll have to think about something. I'll write it down to not forget, thanks for the cc. -- Dominique Martinet

Re: [V9fs-developer] [PATCH v2] net/9p: Fix a deadlock case in the virtio transport

jiangyiwen wrote on Tue, Jul 17, 2018: > On 2018/7/17 19:42, Dominique Martinet wrote: > > > >> Subject: net/9p: Fix a deadlock case in the virtio transport > > > > I hadn't noticed in the v1, but how is that a deadlock fix? > > The previous code doesn't look

Re: [PATCH] net/9p/trans_virtio.c: fix some spell mistakes in comments

hat should be used for zero copy write > * @inlen: read buffer size > * @outlen: write buffer size > * @in_hdr_len: reader header size, This is the size of response protocol > data -- Dominique Martinet

[v9fs] Pull request for linux-next

v9fs and linux-kernel lists, - have been reviewed, - have been tested (*cough* a bit, I need to improve the process), - and are destined to the 4.19 merge window [1] https://sourceforge.net/p/v9fs/mailman/message/36370423/ Thanks, -- Dominique Martinet

Re: [PATCH] net/9p/trans_virtio.c: replace mutex_lock with spin_lock to protect 'virtio_chan_list'

?) reason. -- Dominique Martinet

Re: [PATCH v2] Fix zero-copy path in the 9p virtio transport

nt so add it in now. > + */ > + sz = cpu_to_le32(req->tc->size + outlen); > + memcpy(>tc->sdata[0], , sizeof(sz)); > } else if (uidata) { > int n = p9_get_mapped_pages(chan, _pages, uidata, > inlen, , _drop); -- Dominique Martinet

Re: [PATCH] fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed

piaojun wrote on Wed, Jul 25, 2018: > In my testing, v9fs_fid_xattr_set will return successfully even if the > backend ext4 filesystem has no space to store xattr key-value. That will > cause inconsistent behavior between front end and back end. The reason is > that lsetxattr will be triggered by

Re: [PATCH] fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed

piaojun wrote on Wed, Jul 25, 2018: > On 2018/7/25 11:32, Dominique Martinet wrote: > >>p9_client_write(fid, 0, , ); > > > > I'm not sure what to do about this but it's also possible for > > p9_client_write to not write the full length without setting

Re: [PATCH] 9p: validate PDU length

Tomas Bortoli wrote on Mon, Jul 23, 2018: > diff --git a/net/9p/client.c b/net/9p/client.c > index 18c5271910dc..92240ccf476b 100644 > --- a/net/9p/client.c > +++ b/net/9p/client.c > @@ -524,6 +525,12 @@ static int p9_check_errors(struct p9_client *c, struct > p9_req_t *req) > int ecode; >

Re: [PATCH v2 5/6] 9p: Use a slab for allocating requests

Greg Kurz wrote on Mon, Jul 23, 2018: > The patch is quite big and I'm not sure I can find time to review it > carefully, but I'll try to help anyway. No worry, thanks for this already. > > Sorry for coming back to this patch now, I just noticed something that's > > actually probably a fairly

Re: [PATCH] net/9p/trans_virtio.c: replace mutex_lock with spin_lock to protect 'virtio_chan_list'

piaojun wrote on Thu, Jul 19, 2018: > > piaojun wrote on Wed, Jul 18, 2018: > > That's not a fast path operation, I don't mind changing things but I'd > > like to understand why - these functions are only ever called at unmount > > time or when something happens on the virtio bus (probe will

Re: [V9fs-developer] [PATCH] net/9p: Fix a deadlock case in the virtio transport

spin on it until this thread is done. If we do go this way I'd want setting chan->ring_bufs_avail to be done just before unlocking and the wakeup to be done just after unlocking out of the loop iff we processed at least one iteration here. That should also save you precious cpu cycles while under lock :) -- Dominique Martinet

Re: [PATCH 05/18] iio: change strncpy+truncation to strlcpy

Jonathan Cameron wrote on Sun, Jul 15, 2018: > On Fri, 13 Jul 2018 03:25:34 +0200 > Dominique Martinet wrote: > > Generated by scripts/coccinelle/misc/strncpy_truncation.cocci > > > > Signed-off-by: Dominique Martinet > > Applied to the togreg branch of iio

Re: [V9fs-developer] [PATCH] net/9p: Fix a deadlock case in the virtio transport

jiangyiwen wrote on Mon, Jul 16, 2018: > You're right, this wake up operation should be put after the unlocking, > I will resend it. In addition, whether I should resend this patch based > on your 9p-next branch? There is a trivial conflict with Thomas' validate PDU length patch, but as it is

Re: [V9fs-developer] [PATCH] net/9p: Fix a deadlock case in the virtio transport

jiangyiwen wrote on Sat, Jul 14, 2018: > On 2018/7/14 17:05, Dominique Martinet wrote: > > jiangyiwen wrote on Sat, Jul 14, 2018: > >> When client has multiple threads that issue io requests all the > >> time, and the server has a very good performance, it may cause >

  1   2   3   4   5   >