linux-toradex.git/net/9p, branch v4.9.62 Linux kernel for Apalis and Colibri modules p9_client_readdir() fix 2017-05-03T15:36:38+00:00 Al Viro viro@zeniv.linux.org.uk 2017-04-14T21:22:18+00:00 b2b93bbeec2de7d0f6a0c404295fd1572de8caee commit 71d6ad08379304128e4bdfaf0b4185d54375423e upstream. Don't assume that server is sane and won't return more data than asked for. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 71d6ad08379304128e4bdfaf0b4185d54375423e upstream.

Don't assume that server is sane and won't return more data than
asked for.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
IB/core: add support to create a unsafe global rkey to ib_create_pd 2016-09-23T17:47:44+00:00 Christoph Hellwig hch@lst.de 2016-09-05T10:56:17+00:00 ed082d36a7b2c27d1cda55fdfb28af18040c4a89 Instead of exposing ib_get_dma_mr to ULPs and letting them use it more or less unchecked, this moves the capability of creating a global rkey into the RDMA core, where it can be easily audited. It also prints a warning everytime this feature is used as well. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Reviewed-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Doug Ledford <dledford@redhat.com> 
Instead of exposing ib_get_dma_mr to ULPs and letting them use it more or
less unchecked, this moves the capability of creating a global rkey into
the RDMA core, where it can be easily audited.  It also prints a warning
everytime this feature is used as well.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
9p/trans_virtio: use kvfree() for iov_iter_get_pages_alloc() 2016-08-09T10:42:36+00:00 Vegard Nossum vegard.nossum@oracle.com 2016-08-03T16:59:47+00:00 1b8553c04bf95180eb91be94f089a1e8b38cfd62 The memory allocated by iov_iter_get_pages_alloc() can be allocated with vmalloc() if kmalloc() failed -- see get_pages_array(). In that case we need to free it with vfree(), so let's use kvfree(). The bug manifests like this: BUG: unable to handle kernel paging request at ffffeb0400072da0 IP: [<ffffffff8139c67b>] kfree+0x4b/0x140 PGD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 2 PID: 675 Comm: trinity-c2 Not tainted 4.7.0-rc7+ #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 task: ffff8800badef2c0 ti: ffff880069208000 task.ti: ffff880069208000 RIP: 0010:[<ffffffff8139c67b>] [<ffffffff8139c67b>] kfree+0x4b/0x140 RSP: 0000:ffff88006920f3f0 EFLAGS: 00010282 RAX: ffffea0000000000 RBX: ffffc90001cb6000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffffc90001cb6000 RBP: ffff88006920f410 R08: 0000000000000000 R09: dffffc0000000000 R10: ffff8800badefa30 R11: 0000056a3d3b0d9f R12: ffff88006920f620 R13: ffffeb0400072d80 R14: ffff8800baa94078 R15: 0000000000000000 FS: 00007fbd2b437700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffeb0400072da0 CR3: 000000006926d000 CR4: 00000000000006e0 Stack: 0000000000000001 ffff88006920f620 ffffed001755280f ffff8800baa94078 ffff88006920f6a8 ffffffff8310442b dffffc0000000000 ffff8800badefa30 ffff8800badefa28 ffff88011af1fba0 1ffff1000d241e98 ffff8800ba892150 Call Trace: [<ffffffff8310442b>] p9_virtio_zc_request+0x72b/0xdb0 [<ffffffff830f2116>] p9_client_zc_rpc.constprop.8+0x246/0xb10 [<ffffffff830f5d79>] p9_client_read+0x4c9/0x750 [<ffffffff8175ceac>] v9fs_fid_readpage+0x14c/0x320 [<ffffffff8175d0b6>] v9fs_vfs_readpage+0x36/0x50 [<ffffffff812c6f13>] filemap_fault+0x9a3/0xe60 [<ffffffff81331878>] __do_fault+0x158/0x300 [<ffffffff81339e01>] handle_mm_fault+0x1cf1/0x3c80 [<ffffffff810c0aaa>] __do_page_fault+0x30a/0x8e0 [<ffffffff810c10df>] do_page_fault+0x2f/0x80 [<ffffffff810b5b07>] do_async_page_fault+0x27/0xa0 [<ffffffff83296c48>] async_page_fault+0x28/0x30 Code: 00 80 41 54 53 49 01 fd 48 0f 42 05 b0 39 67 02 48 89 fb 49 01 c5 48 b8 00 00 00 00 00 ea ff ff 49 c1 ed 0c 49 c1 e5 06 49 01 c5 <49> 8b 45 20 48 8d 50 ff a8 01 4c 0f 45 ea 49 8b 55 20 48 8d 42 RIP [<ffffffff8139c67b>] kfree+0x4b/0x140 RSP <ffff88006920f3f0> CR2: ffffeb0400072da0 ---[ end trace f3d59a04bafec038 ]--- Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> 
The memory allocated by iov_iter_get_pages_alloc() can be allocated with
vmalloc() if kmalloc() failed -- see get_pages_array().

In that case we need to free it with vfree(), so let's use kvfree().

The bug manifests like this:

BUG: unable to handle kernel paging request at ffffeb0400072da0
IP: [<ffffffff8139c67b>] kfree+0x4b/0x140
PGD 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 2 PID: 675 Comm: trinity-c2 Not tainted 4.7.0-rc7+ #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
task: ffff8800badef2c0 ti: ffff880069208000 task.ti: ffff880069208000
RIP: 0010:[<ffffffff8139c67b>]  [<ffffffff8139c67b>] kfree+0x4b/0x140
RSP: 0000:ffff88006920f3f0  EFLAGS: 00010282
RAX: ffffea0000000000 RBX: ffffc90001cb6000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffffc90001cb6000
RBP: ffff88006920f410 R08: 0000000000000000 R09: dffffc0000000000
R10: ffff8800badefa30 R11: 0000056a3d3b0d9f R12: ffff88006920f620
R13: ffffeb0400072d80 R14: ffff8800baa94078 R15: 0000000000000000
FS:  00007fbd2b437700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffeb0400072da0 CR3: 000000006926d000 CR4: 00000000000006e0
Stack:
 0000000000000001 ffff88006920f620 ffffed001755280f ffff8800baa94078
 ffff88006920f6a8 ffffffff8310442b dffffc0000000000 ffff8800badefa30
 ffff8800badefa28 ffff88011af1fba0 1ffff1000d241e98 ffff8800ba892150
Call Trace:
 [<ffffffff8310442b>] p9_virtio_zc_request+0x72b/0xdb0
 [<ffffffff830f2116>] p9_client_zc_rpc.constprop.8+0x246/0xb10
 [<ffffffff830f5d79>] p9_client_read+0x4c9/0x750
 [<ffffffff8175ceac>] v9fs_fid_readpage+0x14c/0x320
 [<ffffffff8175d0b6>] v9fs_vfs_readpage+0x36/0x50
 [<ffffffff812c6f13>] filemap_fault+0x9a3/0xe60
 [<ffffffff81331878>] __do_fault+0x158/0x300
 [<ffffffff81339e01>] handle_mm_fault+0x1cf1/0x3c80
 [<ffffffff810c0aaa>] __do_page_fault+0x30a/0x8e0
 [<ffffffff810c10df>] do_page_fault+0x2f/0x80
 [<ffffffff810b5b07>] do_async_page_fault+0x27/0xa0
 [<ffffffff83296c48>] async_page_fault+0x28/0x30
Code: 00 80 41 54 53 49 01 fd 48 0f 42 05 b0 39 67 02 48 89 fb 49 01 c5 48 b8 00 00 00 00 00 ea ff ff 49 c1 ed 0c 49 c1 e5 06 49 01 c5 <49> 8b 45 20 48 8d 50 ff a8 01 4c 0f 45 ea 49 8b 55 20 48 8d 42
RIP  [<ffffffff8139c67b>] kfree+0x4b/0x140
 RSP <ffff88006920f3f0>
CR2: ffffeb0400072da0
---[ end trace f3d59a04bafec038 ]---

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
remove lots of IS_ERR_VALUE abuses 2016-05-27T22:26:11+00:00 Arnd Bergmann arnd@arndb.de 2016-05-27T21:23:25+00:00 287980e49ffc0f6d911601e7e352a812ed27768e Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
net/9p: convert to new CQ API 2016-03-11T01:54:09+00:00 Christoph Hellwig hch@lst.de 2016-03-03T08:36:06+00:00 7cf20fc62428367bbf853a8d968804a6ec6a4973 Trivial conversion to the new RDMA CQ API. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Dominique Martinet <dominique.martinet@cea.fr> Signed-off-by: Doug Ledford <dledford@redhat.com> 
Trivial conversion to the new RDMA CQ API.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Dominique Martinet <dominique.martinet@cea.fr>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Merge tag 'for-linus-4.5-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs 2016-01-24T20:39:09+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-01-24T20:39:09+00:00 c52cb4311f20538fcb69420e55a19ac622546a08 Pull 9p updates from Eric Van Hensbergen: "Sorry for the last minute pull request, there's was a change that didn't get pulled into for-next until two weeks ago and I wanted to give it some bake time. Summary: Rework and error handling fixes, primarily in the fscatch and fd transports" * tag 'for-linus-4.5-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs: fs/9p: use fscache mutex rather than spinlock 9p: trans_fd, bail out if recv fcall if missing 9p: trans_fd, read rework to use p9_parse_header net/9p: Add device name details on error 
Pull 9p updates from Eric Van Hensbergen:
 "Sorry for the last minute pull request, there's was a change that
  didn't get pulled into for-next until two weeks ago and I wanted to
  give it some bake time.

  Summary:

  Rework and error handling fixes, primarily in the fscatch and fd
  transports"

* tag 'for-linus-4.5-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs:
  fs/9p: use fscache mutex rather than spinlock
  9p: trans_fd, bail out if recv fcall if missing
  9p: trans_fd, read rework to use p9_parse_header
  net/9p: Add device name details on error
... and a couple in net/9p 2016-01-04T15:29:17+00:00 Al Viro viro@zeniv.linux.org.uk 2016-01-02T18:31:21+00:00 222e4adec52418dc1c80a30eff80b33ec954745e Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
9p/trans_virtio: don't bother with p9_tag_lookup() 2015-12-07T02:17:11+00:00 Al Viro viro@zeniv.linux.org.uk 2015-07-13T01:06:44+00:00 474fe9f7f551b151222db07a968b15bf05ffe4c4 Just store the pointer to req instead of that to req->tc as opaque data. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Just store the pointer to req instead of that to req->tc as opaque
data.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
9p: trans_fd, bail out if recv fcall if missing 2015-11-14T14:12:41+00:00 Dominique Martinet dominique.martinet@cea.fr 2015-09-07T15:06:54+00:00 3053600ed4f71115631258f0d64eca0d10b11bdc req->rc is pre-allocated early on with p9_tag_alloc and shouldn't be missing Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr> Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com> 
req->rc is pre-allocated early on with p9_tag_alloc and shouldn't be missing

Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
9p: trans_fd, read rework to use p9_parse_header 2015-11-14T14:12:41+00:00 Dominique Martinet dominique.martinet@cea.fr 2015-09-03T09:28:20+00:00 947867aa195b65471f4767fdf761e3841577f90e Most of the changes here are no-op and just renaming to use a fcall struct, needed for p9_parse_header It fixes the unaligned memory access to read the tag and defers to common functions for part of the protocol knowledge (although header length is still hard-coded...) Reported-By: Rob Landley <rob@landley.net> Signed-Off-By: Dominique Martinet <dominique.martinet@cea.fr> Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com> 
Most of the changes here are no-op and just renaming to use a
fcall struct, needed for p9_parse_header

It fixes the unaligned memory access to read the tag and defers to
common functions for part of the protocol knowledge (although header
length is still hard-coded...)

Reported-By: Rob Landley <rob@landley.net>
Signed-Off-By: Dominique Martinet <dominique.martinet@cea.fr>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>