BMC/Intel-BMC/linux.git/net/9p, branch dev-4.7

remove lots of IS_ERR_VALUE abuses

2016-05-27T22:26:11+00:00

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 Cc: Andrzej Hajda Cc: Andrew Morton Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla # For nvmem part Signed-off-by: Linus Torvalds

net/9p: convert to new CQ API

2016-03-11T01:54:09+00:00

Trivial conversion to the new RDMA CQ API. Signed-off-by: Christoph Hellwig Acked-by: Dominique Martinet Signed-off-by: Doug Ledford

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

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

Signed-off-by: Al Viro

9p/trans_virtio: don't bother with p9_tag_lookup()

2015-12-07T02:17:11+00:00

Just store the pointer to req instead of that to req->tc as opaque data. Signed-off-by: Al Viro

9p: trans_fd, bail out if recv fcall if missing

2015-11-14T14:12:41+00:00

req->rc is pre-allocated early on with p9_tag_alloc and shouldn't be missing Signed-off-by: Dominique Martinet Signed-off-by: Eric Van Hensbergen

9p: trans_fd, read rework to use p9_parse_header

2015-11-14T14:12:41+00:00

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 Signed-Off-By: Dominique Martinet Signed-off-by: Eric Van Hensbergen

net/9p: Add device name details on error

2015-11-14T14:12:41+00:00

If we use wrong device name 9p mount fails with error "9pnet_virtio: no channels available" Improve the error output as below "9pnet_virtio: no channels available for device /dev/root" Signed-off-by: Aneesh Kumar K.V Signed-off-by: Eric Van Hensbergen

IB/cma: Add support for network namespaces

2015-10-28T16:32:48+00:00

Add support for network namespaces in the ib_cma module. This is accomplished by: 1. Adding network namespace parameter for rdma_create_id. This parameter is used to populate the network namespace field in rdma_id_private. rdma_create_id keeps a reference on the network namespace. 2. Using the network namespace from the rdma_id instead of init_net inside of ib_cma, when listening on an ID and when looking for an ID for an incoming request. 3. Decrementing the reference count for the appropriate network namespace when calling rdma_destroy_id. In order to preserve the current behavior init_net is passed when calling from other modules. Signed-off-by: Guy Shapiro Signed-off-by: Haggai Eran Signed-off-by: Yotam Kenneth Signed-off-by: Shachar Raindel Signed-off-by: Doug Ledford

net/9p: Remove ib_get_dma_mr calls

2015-08-30T22:12:36+00:00

The pd now has a local_dma_lkey member which completely replaces ib_get_dma_mr, use it instead. Signed-off-by: Jason Gunthorpe Tested-by: Dominique Martinet Signed-off-by: Doug Ledford