nd of dropped in priority.
I'll have another look next week
I guess the worst that could happen would be submitting the
rdma_cancelled function again when this is sorted out :)
Regards,
--
Dominique Martinet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
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 fi
s perfectly yet, but a dd with
blocksize 1MB and one with blocksize 10B in parallel brought the
mountpoint down (and the whole server was completely unavailable for the
duration of the dd - TCP sessions timed out, I even got IO errors on the
local disk :D)
Regards,
--
Dominique Martinet
--
To u
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 recei
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
Eric Van Hensbergen wrote on Sat, Sep 05, 2015:
> On Thu, Sep 3, 2015 at 4:38 AM, Dominique Martinet
> 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_lookup) and not try to
> > al
req->rc is pre-allocated early on with p9_tag_alloc and shouldn't be missing
Signed-off-by: Dominique Martinet
---
net/9p/trans_fd.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
Feel free to adapt error code/message if you can think of something better.
diff --g
Signed-Off-By: Dominique Martinet
---
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 anyway
but happy with either version - letting Eric decide w
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
---
net/9p/trans_fd.c | 3 +++
1 file changed, 3 insertions(+)
To be honest, I think it might be better to just bail out if we get in
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(&rdma->excess_rc) > 0)) {
> > if ((atomic_sub_return(1, &rdma->excess_rc) >= 0)) {
> > -
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) && (type
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 be
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 che
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.
Th
bout
this kind 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
_entry(m, &kclist_head, list) {
> + if (start >= m->addr &&
> + start < m->addr + m->size)
> + break;
> + }
> }
>
> if (&m->list == &kclist_head) {
--
Dominique Martinet
re: optimize 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(&kclist_head, struct kcore_list,
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
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 st
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
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
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
R
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.
> > dif
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.
Cou
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
4.19 meanwhile..
--
Dominique Martinet
ceptably with
> adding whatever 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
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
d the expression seems to work, 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
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 compat
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 jus
jhg1476893564298.html
[2] https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html
In this 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
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'
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
--
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
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 happen
ous without any feedback right 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
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], l
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 results
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,
> > +
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 or
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 co
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 (!
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;
> >
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 mes
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
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
C
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 ti
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 big
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 p
piaojun wrote on Wed, Jul 25, 2018:
> On 2018/7/25 11:32, Dominique Martinet wrote:
> >>p9_client_write(fid, 0, &from, &retval);
> >
> > I'm not sure what to do about this but it's also possible for
> > p9_client_write to not
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;
>
Matthew Wilcox wrote on Wed, Jul 11, 2018:
> On Wed, Jul 11, 2018 at 03:33:13PM +0200, Dominique Martinet wrote:
> > Well this appears to work but P9_NOTAG being '(u16)(~0)' I'm not too
> > confident with P9_NOTAG + 1. . . it doesn't look like it's overflow
, I've picked them up for 4.19
( git://github.com/martinetd/linux 9p-next as per mail on
v9fs-developer list, "Current 9P patches - test branch")
This shouldn't stop anyone else from doing more reviews/test, I'm doing
this 9p-patch-gathering on no autority and I've
, flags);
> + spin_lock(&c->lock);
This code doesn't exist anymore with Matthew's idr rework, could you
submit that patch based on top of my 9p-next branch?
(unless you really want Andrew to take this for the next 4.18-rc, but
I'm not convinced this qualifies)
Ple
list_add(&fid->flist, &clnt->fidlist);
> - spin_unlock_irqrestore(&clnt->lock, flags);
> + fid->fid = 0;
>
> - return fid;
> + idr_preload(GFP_KERNEL);
> + spin_lock_irq(&clnt->lock);
> + ret = idr_alloc_u32(&clnt->fids, fid, &fid->fid, P9_NOFID - 1,
> + GFP_NOWAIT);
If you do resend, alignment here was wrong.
Thanks,
--
Dominique Martinet
, feel free
> to adjust the whitespace. I don't care.
I would tend to agree that sometimes checkpatch is overzealous, but
having worked on projects where code style is all over the place it
really feels much more comfortable to have a consistent style
everywhere.
Thanks for the permission, I'll adjust it (assuming this does end up
getting pulled from my branch, but nobody yelled so far)
--
Dominique Martinet
Ville Syrjälä wrote on Thu, Jul 12, 2018:
> On Wed, Jul 11, 2018 at 09:46:15AM +0200, Dominique Martinet wrote:
> > This is effectively no-op as the next line writes a nul at the final
>
> What is "This". Please write self contained commit messages.
This could either be
in the serie removes that
array and allocates even more lazily with a slab, so this was a
no-brainer :)
--
Dominique Martinet
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
drivers/power/supply/test_power.c | 3 +--
1 file
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
kernel/debug/kdb/kdb_support.c | 3 +--
1 file ch
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
drivers/iio/common/st_sensors/st_sensors_co
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
drivers/net/ethernet/myricom/myri10ge/myri10
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
tools/perf/util/bpf-loader.h | 3 +--
tools/p
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
drivers/scsi/ibmvscsi/ibmvscsi.c | 6 ++
IZE);
^
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
kernel/trace
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
tools/accounting/getdelays.c | 3 +--
1 file ch
Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
Signed-off-by: Dominique Martinet
---
Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch
tools/power/cpupower/bench/parse.c | 3 +--
1 file
ugh?
> Also, consider changing Confidence level appropriately.
I am (was?) pretty confident on the change itself, the only exceptions
would be if someone relied on strncpy to fill the end of the buffer with
zero to not leak data somewhere but that is not easy to judge by itself
(although I hope rare enough)
I'm honestly not sure what would be appropriate in this case.
--
Dominique Martinet
tely try to grab the lock, and will needlessly 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
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
>
Adeodato Simó wrote on Tue, Nov 13, 2018:
> This silences -Wmissing-prototypes when defining p9_release_pages.
>
> Signed-off-by: Adeodato Simó
> ---
> net/9p/trans_common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> It was suggested in the kernel-janitors mailing list that silencing
> -Wmissi
e about it. Let me know if you find out more.
There's a saying about giving a fish or teaching how to fish, so let's
have you try if you're motivated :)
I don't think much is left if you can sew the pieces together, the most
difficult part will probably to set the test environment up if you want
to do this properly.
Please ask if you run into any trouble,
--
Dominique Martinet | Asmadeus
ec ("net/9p/client.c: fix potential refcnt problem of
> trans module")
>
> Signed-off-by: Jun Piao
Reviewed-by: Yiwen Jiang
Reviewed-by: Greg Kurz
Reviewed-and-tested-by: Dominique Martinet
> ---
> net/9p/client.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 delet
This is effectively no-op as the next line writes a nul at the final
byte of the buffer, so copying one letter less does not change the
behaviour.
Signed-off-by: Dominique Martinet
---
gcc 8 gives the following warning, which I am not sure why is treated
as error for this file, thus making me
ily from 0 which no longer holds true, that breaks one
serveur (nfs-ganesha just returns ERANGE) but others seem to handle this
just fine so they'll just need to fix that server.
max aside this looks good.
--
Dominique Martinet
Matthew Wilcox wrote on Wed, Jul 11, 2018:
> On Wed, Jul 11, 2018 at 02:40:38PM +0200, Dominique Martinet wrote:
> > > + idr_preload(GFP_KERNEL);
> > > + spin_lock_irq(&clnt->lock);
> > > + ret = idr_alloc_u32(&clnt->fids, fid, &fid->fid, UINT
Matthew Wilcox wrote on Thu, Jun 28, 2018:
> diff --git a/include/net/9p/client.h b/include/net/9p/client.h
> index 0fa0fbab33b0..fd326811ebd4 100644
> --- a/include/net/9p/client.h
> +++ b/include/net/9p/client.h
> @@ -92,24 +85,12 @@ enum p9_req_status_t {
> * struct p9_req_t - request slots
>
x27;ve offered to do it if you aren't
going to but since you're submitting a second version of the other
patchs I suggest you do this one as well.
Thanks for the well-needed cleanup,
--
Dominique Martinet
tus, 1
wmb rmb
[w] req->status, 1 [r] req->rc
Where the wmb ensures that rc gets written before status,
and the rmb ensures that if you observe status == 1, rc is the new value.
-
It might need an update to the comment though, if you thought about
removing it...
--
Dominique Martinet | Asmadeus
lar in
the "SLEEP AND WAKE-UP FUNCTIONS" section so I guess this is fine.
Thanks,
--
Dominique Martinet | Asmadeus
when I get around to it, but I would recommend to just revert
the patch 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
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
Tomas Bortoli wrote on Mon, Dec 17, 2018:
> sorry for the delay, I've been quite busy these days.
No problem.
> The patches looks good to me and should indeed speed up the code a bit.
> I quickly tested them against Syzkaller tuned for the 9p subsystem and
> everything seems fine.
Thanks, can I
From: Dominique Martinet
Make the client flush asynchronous so we don't need to ignore signals in
rpc functions:
- on signal, send a flush request as we previously did but use the new
asynchronous helper and return immediately
- when the reply has been received or connection is destroyed,
From: Dominique Martinet
Add p9_client_async_rpc that will let us send an rpc without waiting
for the reply, as well as an async handler hook.
The work done in the hook could mostly be done in the client callback,
but I prefered not to for a couple of reasons:
- the callback can be called in
From: Dominique Martinet
clunk is defined as making the fid invalid whatever the server returns,
and we should ignore errors so it is a good candidate for async call.
The change should make 9p slightly faster (many vfs systeme calls won't
need to wait for that clunk), but more importantl
sure if that would need restricting as well in
the context of the security issue. Frankly even with mincore someone
could likely tell the difference through timing, if they just do it a
few times. Do magic, probe, flush out, repeat until satisfied.)
Thanks,
--
Dominique Martinet | Asmadeus
Vlastimil Babka wrote on Mon, Jan 07, 2019:
> On 1/7/19 5:32 AM, Dominique Martinet wrote:
> > Linus Torvalds wrote on Sat, Jan 05, 2019:
> >> But I think my patch to just rip out all that page lookup, and just
> >> base it on the page table state has the fundamental
Pavel Tatashin wrote on Mon, Jan 07, 2019:
> I could not reproduce the problem. Did you suspend to memory between
> wake ups? Does this time jump happen every time, even if your laptop
> sleeps for a minute?
I'm not sure I understand "suspend to memory between the wake ups".
The full sequence is:
Pavel Tatashin wrote on Mon, Jan 07, 2019:
> I did exactly the same sequence on Kaby Lake CPU and could not
> reproduce it. What is your host CPU?
skylake consumer laptop CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
I don't have any kaby lake around; I have access to older servers though...
--
small msize
Adeodato Simó (1):
net/9p: include trans_common.h to fix missing prototype warning.
Dominique Martinet (1):
9p/net: put a lower bound on msize
net/9p/client.c | 21 +
net/9p
Pavel Tatashin wrote on Thu, Jan 03, 2019:
> Could you please send the config file and qemu arguments that were
> used to reproduce this problem.
Running qemu by hand, nothing fancy e.g. this works:
# qemu-system-x86_64 -m 1G -smp 4 -drive
file=/root/kvm-wrapper/disks/f2.img,if=virtio -serial mo
waste even if we
only do it for processes in 32bit mode, and a new flag would be a
protocol change with 9p not being designed to catter for subtle protocol
changes so would be rather painful to roll out)
No bright idea here, sorry.
--
Dominique Martinet | Asmadeus
Theodore Y. Ts'o wrote on Fri, Dec 28, 2018:
> On Sat, Dec 29, 2018 at 03:37:21AM +0100, Dominique Martinet wrote:
> > > Are there going to be cases where a process or a thread will sometimes
> > > want the 64-bit interface, and sometimes want the 32-bit interface?
>
run on a real
> hardware. But we can't afford this at the moment.
Sure, I understand that.
> As far as I understand RDMA maintainers run syzkaller on real
> hardware, but I don't know if they are up to including 9p into
> testing. +Leon
I'd be interested in knowing what kind of tests runs there :)
--
Dominique Martinet
Dmitry Vyukov wrote on Wed, Oct 10, 2018:
> > Back to the current patch, since as I said I am not confident this is a
> > good enough fix for the current bug, will I get notified if the bug
> > happens again once the patch hits linux-next with the Reported-by tag ?
> > (I don't have the setup neces
Dmitry Vyukov wrote on Thu, Oct 11, 2018:
> > That's still the tricky part, I'm afraid... Making a separate server
> > would have been easy because I could have reused some of my junk for the
> > actual connection handling (some rdma helper library I wrote ages
> > ago[1]), but if you're going to j
Dmitry Vyukov wrote on Thu, Oct 11, 2018:
> But again we don't need to support all of the available hardware.
I agree with that, I just have no idea what the "librxe-rdmav16.so" lib
could be doing and described something I am slightly more familiar with
(e.g. libmlx5)
I talked about a common subse
Dmitry Vyukov wrote on Thu, Oct 11, 2018:
> > Now we are talking!
> > We generally assume that all modules are simply compiled into kernel.
> > At least that's we have on syzbot. If somebody can't compile them in,
> > we can suggest to add modprobe into init.
> > So this boils down to just writing
1 - 100 of 288 matches
Mail list logo
