at you were
trying to do in the first place.
Do you want to send a v2 or shall I?
--
Dominique Martinet | Asmadeus
give up and zero the tail; I'm surprised there's no "memcpy
up to x bytes and zero up to y bytes if required" helper but Christian's
suggestion of always doing memset first is probably not that bad
performance-wise if someone's dumping these out already.
I don't have a hard preference here, what do you think?
--
Dominique Martinet | Asmadeus
Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> In some cases, you can use the device_link infrastructure to deal
> with dependencies between devices. Not sure if this would help
> in your case, but have a look at device_link_add() etc in drivers/base/core.c
I'll need to actually
Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
> > This is going to need quite some more work to be acceptable, in my
> > opinion, but I think it should be possible.
>
> In general, this is very hard to do, IMHO. Some drivers may be used on
> multiple platforms, some of them
Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> From: Alice Guo
>
> Update all the code that use soc_device_match
A single patch might be difficult to accept for all components, a each
maintainer will probably want to have a say on their subsystem?
I would suggest to split
First comment overall for the whole serie:
Since it is the solution I had suggested when I reported the problem[1]
I have no qualm on the approach, comments for individual patches
follow.
[1] http://lore.kernel.org/r/YGGZJjAxA1IO+/v...@atmark-techno.com
Alice Guo (OSS) wrote on Mon, Apr 19,
Alice Guo (OSS) wrote on Tue, Mar 30, 2021 at 02:41:23AM +:
> Thanks for reporting this issue, I'll check and add a fix to handle defer
> probe.
I haven't seen any follow up on this, have you had a chance to take a
look?
If this won't make it for 5.12 (in a couple of week probably?) would it
Hi,
First thanks for the patch, it fixes the kexec hang I was looking at...
Unfortunately it means the soc is now init much later and other piece of
drivers that depend on querying the soc will fail, I am getting a BUG in
the caam crypto driver from 7d981405d0fd ("soc: imx8m: change to use
Hi,
Guenter Roeck wrote on Thu, Sep 17, 2020 at 07:16:17PM -0700:
> On 9/17/20 5:47 AM, Laurent Pinchart wrote:
> > On Wed, Sep 16, 2020 at 07:25:42PM -0700, Guenter Roeck wrote:
> >> Something seems to have gone wrong with v3 of this patch series.
> >> I am sure I sent it out, but I don't find
Jisheng Zhang wrote on Tue, Mar 02, 2021 at 03:39:40PM +0800:
> > Rather than make an exception for 0, how about just removing the if as
> > follow ?
>
> IMHO, we may need to keep the "if" in current logic. When count
> reaches zero, we need to break the "while(iov_iter_count(to))" loop, so
>
Jisheng Zhang wrote on Mon, Mar 01, 2021 at 11:01:57AM +0800:
> Per my understanding of iov_iter, we need to call iov_iter_advance()
> even when the read out count is 0. I believe we can see this common style
> in other fs.
I'm not sure where you see this style, but I don't see exceptions for
Jisheng Zhang wrote on Mon, Mar 01, 2021 at 10:33:36AM +0800:
> I met below warning when cating a small size(about 80bytes) txt file
> on 9pfs(msize=2097152 is passed to 9p mount option), the reason is we
> miss iov_iter_advance() if the read count is 0, so we didn't truncate
> the pipe, then
Rikard Falkeborn wrote on Fri, Jan 08, 2021 at 11:46:50PM +0100:
> The only usage of v9fs_attr_group is to pass its address to
> sysfs_create_group() and sysfs_create_group(), both which takes pointers
> to const struct attribute_group. Make it const to allow the compiler to
> put it in
YANG LI wrote on Wed, Dec 30, 2020:
> The pointer p is being used but it isn't being initialized,
> need to assign a NULL to it.
My understanding is p has to be initialized: the only way out of the
while(1) loop below sets it.
I don't mind fixing false positive warnings as it makes maintenance
)
Dan Carpenter (2):
9p: Uninitialized variable in v9fs_writeback_fid()
9p: Remove unnecessary IS_ERR() check
Dominique Martinet (2):
9p: apply review requests for fid refcounting
9p: Fix writeback fid incorrectly being attached
Masahiro Yamada wrote on Sun, Dec 13, 2020:
> This script was written in awk in spite of the file extension '.sh'.
> Rewrite it as a shell script.
Wow! I wasn't expecting so much, would have sent some rework after the
upcoming merge window.
Thank you.
Some comments below that you can probably
Vincenzo Frascino wrote on Thu, Dec 10, 2020:
> On 12/9/20 10:03 PM, David Laight wrote:
>> Why bother with awk?
I wanted to keep the patch minimal, I'm not opposed to rewriting but
that always potentially has more impact (although as you say, this
script is simple enough)
> > I think you can do
Stephen Rothwell wrote on Thu, Dec 10, 2020:
> On Wed, 9 Dec 2020 14:01:30 +0100 Dominique Martinet
> wrote:
> >
> > I guess it's possible to make kbuild check both sbin and PATH, would
> > that be acceptable?
>
> I guess so. But, have you actually found any set
Vincenzo Frascino wrote on Wed, Dec 09, 2020:
> On 12/1/20 1:17 PM, Dominique Martinet wrote:
> > /usr/bin/awk is not garanteed to exist (and doesn't on e.g. nixos),
> > using /usr/bin/env to have it look in PATH is more robust
>
> This patch breaks the compilation on U
ote
it.
Yamada-san, how about this instead?
But to be honest I'm fine with dropping my patch altogether, I'll work
around it locally if it's too much.
---
>From d53ef3b4c55aa2ea5f9ae887b3e1ace368f30f66 Mon Sep 17 00:00:00 2001
From: Dominique Martinet
Date: Wed, 15 Jul 2020 16:00:13 +0200
Subjec
Krzysztof Kozlowski wrote on Wed, Dec 09, 2020:
> Your commit ece075366294 ("ld-version: use /usr/bin/env awk for
> shebank") breaks current linux-next on Ubuntu 16.04:
>
> $ make defconfig
>
> make[1]: Entering directory '/mnt/data2/linux/linux-upstream/out'
> GEN Makefile
>
Stephen Rothwell wrote on Wed, Dec 09, 2020:
> After merging the kbuild tree, today's linux-next build (x86_64
> modules_install) produced this warning:
>
> Warning: 'make modules_install' requires depmod. Please install it.
> This is probably in the kmod package.
>
> Introduced by commit
>
>
Chengguang Xu wrote on Mon, Dec 07, 2020:
> > , VM_MAYWRITE is set anytime we have a shared map where file has
> > been opened read-write, which seems to be what you want with regards to
> > protecting from mprotect calls.
> >
> > How about simply changing check from WRITE to MAYWRITE?
>
>
Dominique Martinet wrote on Sun, Dec 06, 2020:
> Chengguang Xu wrote on Sat, Dec 05, 2020:
> > If vma is shared and the file was opened for writing,
> > we should also create writeback fid because vma may be
> > mprotected writable even if now readonly.
>
> Hm, I g
Chengguang Xu wrote on Sat, Dec 05, 2020:
> If vma is shared and the file was opened for writing,
> we should also create writeback fid because vma may be
> mprotected writable even if now readonly.
Hm, I guess it makes sense.
> Signed-off-by: Chengguang Xu
> ---
> Caveat: Only compile tested.
Linus Torvalds wrote on Thu, Dec 03, 2020:
> Pulled.
Thanks!
> > (Thanks for letting me know my mails got flagged as spam last time, I've
> > taken the time to setup dkim/dmarc which brings its share of problems
> > with some mailing lists but hopefully will help here)
>
> It looks good here,
The default splice operations got removed recently, add it back to 9p
with iter_file_splice_write like many other filesystems do.
Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
Cc: Toke Høiland-Jørgensen
Signed-off-by: Dominique Martinet
---
fs/9p/vfs_
Toke Høiland-Jørgensen wrote on Tue, Dec 01, 2020:
> > This made me test copy_file_range, and it works with both as well (used
> > not to)
> >
> > interestingly on older kernels this came as default somehow? I have
> > splice working on 5.4.67 :/ so this broke somewhat recently...
>
> Huh, no
Dominique Martinet wrote on Tue, Dec 01, 2020:
> > Since generic_file_splice_read() seems to just implement splice_read in
> > terms of the read_iter operation, I simply added the generic implementation
> > to the file operations, which fixed the error I was seeing. A quick
Toke Høiland-Jørgensen wrote on Tue, Dec 01, 2020:
> The v9fs file operations were missing the splice_read operations, which
> breaks sendfile() of files on such a filesystem. I discovered this while
> trying to load an eBPF program using iproute2 inside a 'virtme' environment
> which uses 9pfs
/usr/bin/awk is not garanteed to exist (and doesn't on e.g. nixos),
using /usr/bin/env to have it look in PATH is more robust
Signed-off-by: Dominique Martinet
---
I've been carrying these two patchs for local kernel development on
nixos for a while, I don't think it'd break anything for anyone
depmod is not guaranteed to be in /sbin, just let make look for
it in the path like all the other invoked programs
Signed-off-by: Dominique Martinet
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 9e7fd6a065a7..d7bd114836a9 100644
Fix style issues in parent commit ("apply review requests for fid
refcounting"), no functional change.
Signed-off-by: Dominique Martinet
---
fs/9p/fid.c | 10 --
fs/9p/fid.h | 2 +-
include/net/9p/client.h | 2 +-
net/9p/client.c | 4 ++-
v9fs_dir_release needs fid->ilist to have been initialized for filp's
fid, not the inode's writeback fid's.
With refcounting this can be improved on later but this appears to fix
null deref issues.
Fixes: xxx ("fs/9p: track open fids")
Signed-off-by: Dominique Martinet
---
(no
now, this time for real.
Hopefully not too many other bugs not uncovered... But only one way to
find out, and I think refcounting 9p fid will allow some nice
optimizations in the future if anyone cares to work on it...
Onto fscache now...!
Dominique Martinet (2):
9p: apply review requests
Christian Schoenebeck wrote on Wed, Nov 04, 2020:
> > Greg, Christian - from what I understood (in private, hopefully I'm
> > allowed to repeat!), he won't be able to contribute to qemu because of
> > company policies and I'm unlikely to take the time either right now.
> > I don't think it's a
Jianyong,
Jianyong Wu wrote on Wed, Sep 23, 2020:
> Eric's and Greg's patch offer a mechanism to fix open-unlink-f*syscall
> bug in 9p. But there is race issue in fid comtention.
> As Greg's patch stores all of fids from opened files into according inode,
> so all the lookup fid ops can retrieve
Matthew Wilcox (Oracle) wrote on Sun, Oct 04, 2020:
> On 32-bit systems, this multiplication will overflow for files larger
> than 4GB.
>
> Cc: sta...@vger.kernel.org
> Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.")
> Signed-off-by: Matthew Wilcox (Oracle)
I realize I
Hi Linus,
another harmless cycle.
(sorry latest commit's message isn't great, I was half expecting a v2
but it didn't come and I remembered too late/didn't want to reword it
myself; and it's still worth taking as is)
Thanks,
The following changes since commit
Anant Thazhemadam wrote on Mon, Oct 12, 2020:
> You mentioned how a fully zeroed address isn't exactly faulty. By extension,
> wouldn't that
> mean that an address that simply begins with a 0 isn't faulty as well?
That is correct.
If you have a look at the unix(7) man page that describes
Anant Thazhemadam wrote on Mon, Oct 12, 2020:
> In p9_fd_create_unix, checking is performed to see if the addr (passed
> as an argument) is NULL or not.
> However, no check is performed to see if addr is a valid address, i.e.,
> it doesn't entirely consist of only 0's.
> The initialization of
Jianyong Wu wrote on Thu, Sep 24, 2020:
> > Jianyong Wu wrote on Wed, Sep 23, 2020:
> > > open-unlink-f*syscall test:
> > > I have tested for f*syscall include: ftruncate fstat fchown fchmod
> > > faccessat.
> >
> > Given the other thread, what did you test this with?
>
> Er, I just use Greg's
Overall looks good; a few comments.
Jianyong Wu wrote on Wed, Sep 23, 2020:
> open-unlink-f*syscall test:
> I have tested for f*syscall include: ftruncate fstat fchown fchmod faccessat.
Given the other thread, what did you test this with?
Since qemu doesn't work apparently do you have a
Matthew Wilcox (Oracle) wrote on Thu, Sep 17, 2020:
> The 9p readpage implementation was already synchronous, so use
> AOP_UPDATED_PAGE to avoid cycling the page lock.
>
> Signed-off-by: Matthew Wilcox (Oracle)
Acked-by: Dominique Martinet
(I assume it'll be merged together w
Jianyong Wu wrote on Fri, Sep 18, 2020:
> If we move the counter decrease code into p9_client_clunk and put it
> instead of fid_atomic_dec, we need delete fid off the inode where it
> stores in p9_client_clunk.
> But there is no way can we acquire the inode in p9_client_clunk. Do
> you have any
Matthew Wilcox (Oracle) wrote on Thu, Sep 17, 2020:
> diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
> index cce9ace651a2..506ca0ba2ec7 100644
> --- a/fs/9p/vfs_addr.c
> +++ b/fs/9p/vfs_addr.c
> @@ -280,6 +280,10 @@ static int v9fs_write_begin(struct file *filp, struct
> address_space *mapping,
Jianyong Wu wrote on Mon, Sep 14, 2020:
> > Not having exceptions for that will also make the code around
> > fid_atomic_dec much simpler: just have clunk do an atomic dec and only do
> > the actual clunk if that hit zero, and we should be able to get rid of that
> > helper?
>
> Sorry, I think
Dominique Martinet wrote on Mon, Sep 14, 2020:
> Jianyong Wu wrote on Mon, Sep 14, 2020:
> - Ideally base yourself of my 9p-test branch to have async clunk:
> https://github.com/martinetd/linux/commits/9p-test
> I've been promising to push it to next this week™ for a cou
Jianyong Wu wrote on Mon, Sep 14, 2020:
> Signed-off-by: Greg Kurz
Just on a note on that mail: gk...@linux.vnet.ibm.com has no longer been
working for a while, probably want to update to gr...@kaod.org in both
first two patches.
Greg, sorry I had forgotten to fix Cc earlier, can you confirm?
Thanks for having a look a this!
Jianyong Wu wrote on Mon, Sep 14, 2020:
> Eric's and Greg's patch offer a mechanism to fix open-unlink-f*syscall
> bug in 9p. But there is race issue in fid comtention.
> As Greg's patch stores all of fids from opened files into according inode,
> so all the
Mark Brown wrote on Wed, Aug 26, 2020:
> On Wed, Aug 26, 2020 at 03:38:15AM -0700, syzbot wrote:
>
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10615b3690
> > kernel config: https://syzkaller.appspot.com/x/.config?x=a61d44f28687f508
> > dashboard link:
David Howells wrote on Thu, Aug 27, 2020:
> Christoph Hellwig wrote:
>
> > FYI, a giant rewrite dropping support for existing consumer is always
> > rather awkward. Is there any way you could pre-stage some infrastructure
> > changes, and then do a temporary fscache2, which could then be
Hi Linus,
the usual small stuff.
Thanks!
The following changes since commit 74d6a5d5662975aed7f25952f62efbb6f6dadd29:
9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work
(2020-07-19 14:58:47 +0200)
are available in the Git repository at:
Li Heng wrote on Wed, Jul 29, 2020:
> Remove casting the values returned by memory allocation function.
>
> Coccinelle emits WARNING:
>
> ./fs/9p/vfs_inode.c:226:12-29: WARNING: casting value returned by memory
> allocation function to (struct v9fs_inode *) is useless.
>
> Signed-off-by: Li
Sorry for the late request, I took some time to fix my test setup and to
be convinced these two patches are worth sending now and not wait until
the next merge window.
(the "weird" -2 at the end of the tag is because I had already used
9p-for-5.8 for the original -rc1 pull)
The following
Greg Kurz wrote on Tue, Jul 28, 2020:
> > The "fd" transport layer uses 2 file descriptors passed externally
> > and calls kernel_write()/kernel_read() on these. If files were opened
> > without FMODE_WRITE/FMODE_READ, WARN_ON_ONCE() will fire.
There already is a fix in linux-next as a39c46067c84
Jianyong Wu wrote on Mon, Jul 20, 2020:
> Currently, getting attribute for a file represented by fd is always
> by inode or path which may lead to bug for a certain network file system.
> Adding file struct into struct kstat and assigning file for it in
> vfs_statx_fd can avoid this issue. This
David Miller wrote on Wed, Jul 15, 2020:
> From: Dominique Martinet
> Date: Wed, 15 Jul 2020 15:47:56 +0200
> > It's honestly just a warn on something that would fail anyway so I'd
> > rather let it live in -next first, I don't get why syzbot is so verbose
> > about th
Christoph Hellwig wrote on Wed, Jul 15, 2020:
> FYI, this is now generating daily syzbot reports, so I'd love to see
> the fix going into Linus' tree ASAP..
Yes, I'm getting some syzbot warnings as well now.
I had however only planned to get this in linux-next, since that is what
the syzbot
Victor Hsieh wrote on Tue, Jul 14, 2020:
> Please disregard this patch. I misunderstood the protocol and have
> found the actual problem in the hypervisor's 9P implementation. Sorry
> about the noise.
Ok, thanks for the notice.
Greg KH wrote on Wed, Jul 15, 2020:
> As Eric says, this is fine
Victor Hsieh wrote on Mon, Jul 13, 2020:
> The fid parameter of TCREATE represents the directory that the file
This is not TCREATE, this is TLCREATE.
The fid represents the directory before the call, but on success
represents the file that has been created.
> should be created at. The current
Doug Nazar wrote on Fri, Jul 10, 2020:
> On 2020-07-10 04:57, Christoph Hellwig wrote:
>
> >diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> >index 13cd683a658ab6..1cd8ea0e493617 100644
> >--- a/net/9p/trans_fd.c
> >+++ b/net/9p/trans_fd.c
> >@@ -803,20 +803,28 @@ static int p9_fd_open(struct
Christoph Hellwig wrote on Fri, Jul 10, 2020:
> p9_fd_open just fgets file descriptors passed in from userspace, but
> doesn't verify that they are valid for read or writing. This gets
> cought down in the VFS when actually attemping a read or write, but a
> new warning added in linux-next upsets
Jianyong Wu wrote on Fri, Jul 10, 2020:
> In the current setattr implementation in 9p, fid is always retrieved
> from dentry no matter file instance exists or not. If so, there may be
> some info related to opened file instance dropped. So it's better
> to retrieve fid from file instance when it
Zhengbin (OSKernel) wrote on Thu, Jul 09, 2020:
> Is this OK? I don't see it on linux-next
Yes, I just (still) haven't tested them, sorry.
It's in git://github.com/martinetd/linux branch 9p-test
--
Dominique
Jianyong Wu wrote on Fri, Jul 03, 2020:
> In the current setattr implementation in 9p, fid is always retrieved
> from dentry no matter file instance exists or not. Thus, there may be
> some info related to opened file instance dropped. So it's better
> to retrieve fid from file instance when it
Jianyong Wu wrote on Thu, Jul 02, 2020:
> Yeah, should check fid before "v9fs_fid_lookup", how about
>
> if (iattr->ia_valid & ATTR_FILE) {
> fid = iattr->ia_file->private_data;
> WARN_ON(!fid);
> }
> If (!fid)
> fid = v9fs_fid_lookup(dentry);
Yes, that would be
Jianyong Wu wrote on Wed, Jul 01, 2020:
> In the current setattr implementation in 9p, fid is always retrieved
> from dentry no matter file instance exists or not. There may be
> some info related to opened file instance dropped. so it's better
> to retrieve fid from file instance if file instance
Jianyong Wu wrote on Sun, Jun 28, 2020:
> These codes have been commented out since 2007 and lay in kernel
> since then. So, it's better to remove them.
>
> Signed-off-by: Jianyong Wu
Thanks, queued for 5.9
--
Dominique
Jianyong Wu wrote on Sun, Jun 28, 2020:
> In the current setattr implementation in 9p, fid will always retrieved from
> dentry no matter file instance exist or not when setattr. There will
> be some info related to open file instance dropped. so it's better
> to retrieve fid from file instance if
Jianyong Wu wrote on Sun, Jun 28, 2020:
> These code has been commented out since 2007 and lied in kernel
> since then. it's time to remove thest no used code.
Good point, happy to take this - please resend without RFC separately
(the two commits aren't related) after fixing the commit message
Christian Brauner wrote on Mon, Jun 22, 2020:
> On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote:
>> current->sighand is stable and can't go away. Unless "current" is exiting and
>> has already passed exit_notify(). So I don't think net/9p needs this helper.
>
> From what I can
Alexander Kapshuk wrote on Sun, Jun 21, 2020:
> Fix rcu not being dereferenced cleanly by using the task
> helpers (un)lock_task_sighand instead of spin_lock_irqsave and
> spin_unlock_irqrestore to ensure current->sighand is a valid pointer as
> suggested in the email referenced below.
Ack.
I'll
Alexander Kapshuk wrote on Sun, Jun 21, 2020:
> Export symbol __lock_task_sighand, so it is accessible from code compiled
> as modules.
> This fixes the following modpost error:
> ERROR: modpost: "__lock_task_sighand" [net/9p/9pnet.ko] undefined!
This can't fix something that's not broken (yet)!
Alexander Kapshuk wrote on Sun, Jun 21, 2020:
> Thanks for your feedback.
> Shall I simply resend the v2 patch with the commit message reworded as
> you suggested, or should I make it a v3 patch instead?
Yes please resend the same commit reworded. v2 or v3 doesn't matter
much, the [PATCH
Alexander Kapshuk wrote on Sat, Jun 20, 2020:
> Use (un)lock_task_sighand instead of spin_lock_irqsave and
> spin_unlock_irqrestore to ensure current->sighand is a valid pointer as
> suggested in the email referenced below.
Thanks for v2! Patch itself looks good to me.
I always add another
Alexander Kapshuk wrote on Thu, Jun 18, 2020:
> Address sparse endian warning:
> net/9p/trans_fd.c:932:28: warning: incorrect type in assignment (different
> base types)
> net/9p/trans_fd.c:932:28:expected restricted __be32 [addressable]
> [assigned] [usertype] s_addr
>
Alexander Kapshuk wrote on Thu, Jun 18, 2020:
> Address sparse nonderef rcu warnings:
> net/9p/client.c:790:17: warning: incorrect type in argument 1 (different
> address spaces)
> net/9p/client.c:790:17:expected struct spinlock [usertype] *lock
> net/9p/client.c:790:17:got struct
Zheng Bin wrote on Mon, Jun 15, 2020:
> v9fs_mount
> v9fs_session_init
> v9fs_cache_session_get_cookie
> v9fs_random_cachetag -->alloc cachetag
> v9ses->fscache = fscache_acquire_cookie -->maybe NULL
> sb = sget-->fail,
Hi Linus,
Another very quiet cycle...
Thanks,
The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162:
Linux 5.7 (2020-05-31 16:49:15 -0700)
are available in the Git repository at:
https://github.com/martinetd/linux tags/9p-for-5.8
for you to fetch changes up to
Wang Hai wrote on Fri, Jun 12, 2020:
> p9_read_work and p9_fd_cancelled may be called concurrently.
> In some cases, req->req_list may be deleted by both p9_read_work
> and p9_fd_cancelled.
>
> We can fix it by ignoring replies associated with a cancelled
> request and ignoring cancelled request
wanghai (M) wrote on Fri, Jun 12, 2020:
> You are right, I got a syzkaller bug.
>
> "p9_read_work+0x7c3/0xd90" points to list_del(>rreq->req_list);
>
> [ 62.733598] kasan: CONFIG_KASAN_INLINE enabled
> [ 62.734484] kasan: GPF could be caused by NULL-ptr deref or user memory
> access
> [
Wang Hai wrote on Thu, Jun 11, 2020:
> p9_read_work and p9_fd_cancelled may be called concurrently.
Good catch. I'm sure this fixes some of the old syzbot bugs...
I'll check other transports handle this properly as well.
> Before list_del(>rreq->req_list) in p9_read_work is called,
> the
Stefano Stabellini wrote on Mon, Jun 01, 2020:
> > LGTM, I'll try to find some time to test this by the end of next week or
> > will trust you if I can't make it -- ping me around June 1st if I don't
> > reply again until then...
>
> Ping :-)
I actually did think about this patch this weekend! .
Stefano Stabellini wrote on Thu, May 21, 2020:
> From: Stefano Stabellini
>
> Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> max allowed by the protocol.
>
> We can't assume that all backends will support order 9. The xenstore
> property max-ring-page-order specifies
Stefano Stabellini wrote on Wed, May 20, 2020:
> From: Stefano Stabellini
>
> Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> max allowed by the protocol.
>
> We can't assume that all backends will support order 9. The xenstore
> property max-ring-page-order specifies
wrote yourself)
Cheers,
--
Asmadeus | Dominique Martinet
Hi Linus,
Some of the usual small fixes and cleanup.
I didn't get the target version wrong this time! :)
The following changes since commit 089cf7f6ecb266b6a4164919a2e69bd2f938374a:
Linux 5.3-rc7 (2019-09-02 09:57:40 -0700)
are available in the Git repository at:
Colin King wrote on Fri, Sep 06, 2019:
> From: Colin Ian King
>
> Don't populate the arrays on the stack but instead make them
> static const. Makes the object code smaller by 386 bytes.
>
> Before:
>text data bss dec hex filename
> 17443 2076 0 19519
Bharath Vedartham wrote on Thu, May 23, 2019:
> v9fs_fill_super has a param 'void *data' which is unused in the
> function.
>
> This patch removes the 'void *data' param in v9fs_fill_super and changes
> the parameters in all function calls of v9fs_fill_super.
>
> Signed-off-by: Bharath Vedartham
Jia-Ju,
Dominique Martinet wrote on Wed, Jul 24, 2019:
> Jia-Ju Bai wrote on Wed, Jul 24, 2019:
> > In p9_cm_event_handler(), there is an if statement on 260 to check
> > whether rdma is NULL, which indicates that rdma can be NULL.
> > If so, using rdma->xxx may cause
Chengguang Xu wrote on Tue, Aug 20, 2019:
> Currently on mmap cache policy, we always attach writeback_fid
> whether mmap type is SHARED or PRIVATE. However, in the use case
> of kata-container which combines 9p(Guest OS) with overlayfs(Host OS),
> this behavior will trigger overlayfs' copy-up
Jia-Ju Bai wrote on Wed, Jul 24, 2019:
> In p9_cm_event_handler(), there is an if statement on 260 to check
> whether rdma is NULL, which indicates that rdma can be NULL.
> If so, using rdma->xxx may cause a possible null-pointer dereference.
The final dereference (complete(>cm_done) line 285)
Dominique Martinet wrote on Fri, Jul 12, 2019:
> 9p pull request for inclusion in 5.13
Just noticed this typo in version number here, should I make a new tag
with the correct text?
Sorry,
--
Dominique
Hi Linus,
Here is a 9p update for 5.3, just a couple of fixes that have been
sitting here for too long as I missed the 5.2 merge window.
I have two more patches that I didn't have time to test early enough for
this but also are plain details fix, please let me know if you would
prefer having me
Lu Shuaibing wrote on Thu, Jun 13, 2019:
> The p9_tag_alloc() does not initialize the transport error t_err field.
> The struct p9_req_t *req is allocated and stored in a struct p9_client
> variable. The field t_err is never initialized before p9_conn_cancel()
> checks its value.
>
>
Bharath Vedartham wrote on Thu, May 23, 2019:
> v9fs_cache_session_get_cookie assigns a random cachetag to
> v9ses->cachetag, if the cachetag is not assigned previously.
>
> v9fs_random_cachetag allocates memory to v9ses->cachetag with kmalloc
> and uses scnprintf to fill it up with a cachetag.
>
Bharath Vedartham wrote on Thu, May 23, 2019:
> v9fs_cache_session_get_cookie assigns a random cachetag to v9ses->cachetag,
> if the cachetag is not assigned previously.
>
> v9fs_random_cachetag allocates memory to v9ses->cachetag with kmalloc and uses
> scnprintf to fill it up with a cachetag.
>
Linus Torvalds wrote on Sun, Mar 17, 2019:
> Hmm. I wonder what makes it valid to have concurrent updates to
> i_size? Yes, yes, you added that spinlock to make the update itself
> atomic on 32-bit, but it sounds a bit odd in the first place to have
> two things possibly changing the size of a
Jiri Kosina wrote on Thu, Mar 07, 2019:
> > I'm not sure this is correct in all cases. If
> >
> > addr = 4095
> > vma->vm_end = 4096
> > pages = 1000
> >
> > then `end' is 4096 and `(end - addr) << PAGE_SHIFT' is zero, but it
> > should have been 1.
>
> Good catch! It should
1 - 100 of 446 matches
Mail list logo
