Re: [PATCH] rds: send: Fix dead code in rds_sendmsg

ot;Structurally dead code") > Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support") > Signed-off-by: Gustavo A. R. Silva Acked-by: Sowmini Varadhan

Re: [PATCH] rds: send: Fix dead code in rds_sendmsg

ot;Structurally dead code") > Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support") > Signed-off-by: Gustavo A. R. Silva Acked-by: Sowmini Varadhan

Re: [rds-devel] KASAN: null-ptr-deref Read in rds_ib_get_mr

On (05/11/18 15:48), Yanjun Zhu wrote: > diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c > index e678699..2228b50 100644 > --- a/net/rds/ib_rdma.c > +++ b/net/rds/ib_rdma.c > @@ -539,11 +539,17 @@ void rds_ib_flush_mrs(void) >void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,

Re: [rds-devel] KASAN: null-ptr-deref Read in rds_ib_get_mr

On (05/11/18 15:48), Yanjun Zhu wrote: > diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c > index e678699..2228b50 100644 > --- a/net/rds/ib_rdma.c > +++ b/net/rds/ib_rdma.c > @@ -539,11 +539,17 @@ void rds_ib_flush_mrs(void) >void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,

Re: KASAN: use-after-free Read in inet_create

#syz dup: KASAN: use-after-free Read in rds_cong_queue_updates There are a number of manifestations of this bug, basically all suggest that the connect/reconnect etc workqs are somehow being scheduled after the netns is deleted, despite the code refactoring in Commit 3db6e0d172c (and looks

Re: KASAN: use-after-free Read in inet_create

#syz dup: KASAN: use-after-free Read in rds_cong_queue_updates There are a number of manifestations of this bug, basically all suggest that the connect/reconnect etc workqs are somehow being scheduled after the netns is deleted, despite the code refactoring in Commit 3db6e0d172c (and looks

Re: KASAN: slab-out-of-bounds Read in rds_cong_queue_updates

On (03/19/18 09:29), Dmitry Vyukov wrote: > > This looks the same as: > > #syz dup: KASAN: use-after-free Read in rds_cong_queue_updates correct, seems like the rds_destroy_pending() fixes did not seal this race condition. I need to look at this more carefully to see what race I missed.. no

Re: KASAN: slab-out-of-bounds Read in rds_cong_queue_updates

On (03/19/18 09:29), Dmitry Vyukov wrote: > > This looks the same as: > > #syz dup: KASAN: use-after-free Read in rds_cong_queue_updates correct, seems like the rds_destroy_pending() fixes did not seal this race condition. I need to look at this more carefully to see what race I missed.. no

Re: WARNING in __local_bh_enable_ip (2)

On (03/14/18 14:28), Eric Dumazet wrote: > > > spin_lock_bh(_tcp_conn_lock);/spin_unlock_bh(_tcp_conn_lock); in > rds_tcp_conn_free() > > is in conflict with the spin_lock_irqsave(_conn_lock, flags); > in __rds_conn_create() yes I was going to look into this and fix it later. > Hard to

Re: WARNING in __local_bh_enable_ip (2)

On (03/14/18 14:28), Eric Dumazet wrote: > > > spin_lock_bh(_tcp_conn_lock);/spin_unlock_bh(_tcp_conn_lock); in > rds_tcp_conn_free() > > is in conflict with the spin_lock_irqsave(_conn_lock, flags); > in __rds_conn_create() yes I was going to look into this and fix it later. > Hard to

Re: [PATCH][rds-next] rds: make functions rds_info_from_znotifier and rds_message_zcopy_from_user static

On (03/11/18 18:03), Colin King wrote: > From: Colin Ian King > > Functions rds_info_from_znotifier and rds_message_zcopy_from_user are > local to the source and do not need to be in global scope, so make them > static. the rds_message_zcopy_from_user warning was

Re: [PATCH][rds-next] rds: make functions rds_info_from_znotifier and rds_message_zcopy_from_user static

On (03/11/18 18:03), Colin King wrote: > From: Colin Ian King > > Functions rds_info_from_znotifier and rds_message_zcopy_from_user are > local to the source and do not need to be in global scope, so make them > static. the rds_message_zcopy_from_user warning was already flagged by

Re: [rds-devel] [PATCH][rds-next] rds: remove redundant variable 'sg_off'

On (03/11/18 17:27), Colin King wrote: > Variable sg_off is assigned a value but it is never read, hence it is > redundant and can be removed. > Acked-by: Sowmini Varadhan <sowmini.varad...@oracle.com>

Re: [rds-devel] [PATCH][rds-next] rds: remove redundant variable 'sg_off'

On (03/11/18 17:27), Colin King wrote: > Variable sg_off is assigned a value but it is never read, hence it is > redundant and can be removed. > Acked-by: Sowmini Varadhan

Re: [PATCH] rds: send: mark expected switch fall-through in rds_rm_size

On (02/19/18 12:10), Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. Acked-by: Sowmini Varadhan <sowmini.varad...@oracle.com>

Re: [PATCH] rds: send: mark expected switch fall-through in rds_rm_size

On (02/19/18 12:10), Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. Acked-by: Sowmini Varadhan

Re: KASAN: use-after-free Read in rds_tcp_tune

On (02/14/18 16:28), Dmitry Vyukov wrote: > syzbot is probably not seeing this problem. However if you don't add > the Reported-by tag to commit, nor provide syz fix tag, it will > consider it as "open". One consequence of this is that it is still on > our radars. Another consequence is that

Re: KASAN: use-after-free Read in rds_tcp_tune

On (02/14/18 16:28), Dmitry Vyukov wrote: > syzbot is probably not seeing this problem. However if you don't add > the Reported-by tag to commit, nor provide syz fix tag, it will > consider it as "open". One consequence of this is that it is still on > our radars. Another consequence is that

Re: KASAN: use-after-free Read in rds_tcp_tune

On (02/14/18 16:11), Dmitry Vyukov wrote: > > Hi Sowmini, > > Was this ever fixed? What's the fix? This still hangs as open. Please > provide "syz fix" tag. Are you still seeing this problem? I had expected that the changes around rds_destroy_pending - see commit ebeeb1ad9b8a - would have

Re: KASAN: use-after-free Read in rds_tcp_tune

On (02/14/18 16:11), Dmitry Vyukov wrote: > > Hi Sowmini, > > Was this ever fixed? What's the fix? This still hangs as open. Please > provide "syz fix" tag. Are you still seeing this problem? I had expected that the changes around rds_destroy_pending - see commit ebeeb1ad9b8a - would have

Re: WARNING: suspicious RCU usage in rds_tcp_conn_alloc

#syz dup: WARNING: suspicious RCU usage in rds_loop_conn_alloc

Re: WARNING: suspicious RCU usage in rds_tcp_conn_alloc

#syz dup: WARNING: suspicious RCU usage in rds_loop_conn_alloc

Re: BUG: sleeping function called from invalid context at mm/slab.h:LINE (3)

#syz dup: WARNING: suspicious RCU usage in rds_loop_conn_alloc

Re: BUG: sleeping function called from invalid context at mm/slab.h:LINE (3)

#syz dup: WARNING: suspicious RCU usage in rds_loop_conn_alloc

Re: WARNING: suspicious RCU usage in rds_loop_conn_alloc

> rcu_scheduler_active = 2, debug_locks = 1 > 1 lock held by syzkaller563791/4086: > #0: (rcu_read_lock){}, at: [] > __rds_conn_create+0xe46/0x1b50 net/rds/connection.c:218 > the rcu_read_lock() was added by ebeeb1ad9b. After we add that, everything in the rcu read

Re: WARNING: suspicious RCU usage in rds_loop_conn_alloc

> rcu_scheduler_active = 2, debug_locks = 1 > 1 lock held by syzkaller563791/4086: > #0: (rcu_read_lock){}, at: [] > __rds_conn_create+0xe46/0x1b50 net/rds/connection.c:218 > the rcu_read_lock() was added by ebeeb1ad9b. After we add that, everything in the rcu read

Re: [rds-devel] BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit

On (01/30/18 14:22), Eric Biggers wrote: > > I assume you weren't able to reproduce this? This crash hasn't been > seen again, : > I am invalidating the bug for syzbot so it will report the same crash > signature > again if it occurs, but if you think there is a real bug feel free to keep >

Re: [rds-devel] BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit

On (01/30/18 14:22), Eric Biggers wrote: > > I assume you weren't able to reproduce this? This crash hasn't been > seen again, : > I am invalidating the bug for syzbot so it will report the same crash > signature > again if it occurs, but if you think there is a real bug feel free to keep >

Re: KASAN: use-after-free Read in rds_tcp_tune

On (01/11/18 21:29), syzbot wrote: > == > BUG: KASAN: use-after-free in rds_tcp_tune+0x491/0x520 net/rds/tcp.c:397 > Read of size 4 at addr 8801cd5f6c58 by task kworker/u4:4/4954 Just had an offline discussion with santosh around

Re: KASAN: use-after-free Read in rds_tcp_tune

On (01/11/18 21:29), syzbot wrote: > == > BUG: KASAN: use-after-free in rds_tcp_tune+0x491/0x520 net/rds/tcp.c:397 > Read of size 4 at addr 8801cd5f6c58 by task kworker/u4:4/4954 Just had an offline discussion with santosh around

Re: [rds-devel] BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit

> From: Santosh Shilimkar > Date: Mon, 18 Dec 2017 08:28:05 -0800 : > > Looks like another one tripping on empty transport. Mostly below > > should > > address it but we will test it if it does. that was my first thought, but it cannot be the case here:

Re: [rds-devel] BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit

> From: Santosh Shilimkar > Date: Mon, 18 Dec 2017 08:28:05 -0800 : > > Looks like another one tripping on empty transport. Mostly below > > should > > address it but we will test it if it does. that was my first thought, but it cannot be the case here: rds_sendmsg etc itself would have bombed

Re: KASAN: use-after-free Read in rds_tcp_dev_event

On (11/13/17 19:30), Girish Moodalbail wrote: > (L538-540). However, it leaves behind some of the rds_tcp connections that > shared the same underlying RDS connection (L534 and 535). These connections > with pointer to stale network namespace are left behind in the global list. It leaves behind

Re: KASAN: use-after-free Read in rds_tcp_dev_event

On (11/13/17 19:30), Girish Moodalbail wrote: > (L538-540). However, it leaves behind some of the rds_tcp connections that > shared the same underlying RDS connection (L534 and 535). These connections > with pointer to stale network namespace are left behind in the global list. It leaves behind

Re: [PATCH net] rds: Make sure updates to cp_send_gen can be observed

On (07/20/17 12:28), H??kon Bugge wrote: > cp->cp_send_gen is treated as a normal variable, although it may be > used by different threads. I'm confused by that assertion. If you look at the comments right above the change in your patch, there is a note that acquire_in_xmit/release_in_xmit are

Re: [PATCH net] rds: Make sure updates to cp_send_gen can be observed

On (07/20/17 12:28), H??kon Bugge wrote: > cp->cp_send_gen is treated as a normal variable, although it may be > used by different threads. I'm confused by that assertion. If you look at the comments right above the change in your patch, there is a note that acquire_in_xmit/release_in_xmit are

Re: [GIT] Networking

On (07/10/17 18:05), Herbert Xu wrote: > > Hmm, I can't see the problem in af_alg_accept. The struct socket > comes directly from sys_accept() which creates it using sock_alloc. > > So the only thing I can think of is that the memory returned by > sock_alloc is not zeroed and therefore the

Re: [GIT] Networking

On (07/10/17 18:05), Herbert Xu wrote: > > Hmm, I can't see the problem in af_alg_accept. The struct socket > comes directly from sys_accept() which creates it using sock_alloc. > > So the only thing I can think of is that the memory returned by > sock_alloc is not zeroed and therefore the

Re: [GIT] Networking

On (07/09/17 11:49), Linus Torvalds wrote: > > On Sat, Jul 8, 2017 at 3:36 AM, David Miller <da...@davemloft.net> wrote: > > > > 8) Fix socket leak on accept() in RDS, from Sowmini Varadhan. Also > >add a WARN_ON() to sock_graft() so other protocol stacks don't

Re: [GIT] Networking

On (07/09/17 11:49), Linus Torvalds wrote: > > On Sat, Jul 8, 2017 at 3:36 AM, David Miller wrote: > > > > 8) Fix socket leak on accept() in RDS, from Sowmini Varadhan. Also > >add a WARN_ON() to sock_graft() so other protocol stacks don't trip > >over th

Re: RDS: TCP: Delete an error message for a failed memory allocation in rds_tcp_init_net()

> Do you find information from a Linux allocation failure report sufficient > for such an use case? yes, I suppose that would cover the needed cases. Your change looks good to me. Acked-by: Sowmini Varadhan <sowmini.varad...@oracle.com>

Re: RDS: TCP: Delete an error message for a failed memory allocation in rds_tcp_init_net()

> Do you find information from a Linux allocation failure report sufficient > for such an use case? yes, I suppose that would cover the needed cases. Your change looks good to me. Acked-by: Sowmini Varadhan

Re: [PATCH 3/3] RDS: TCP: Delete an error message for a failed memory allocation in rds_tcp_init_net()

On (05/22/17 16:13), SF Markus Elfring wrote: > > Omit an extra message for a memory allocation failure in this function. The change itself is harmless, but I'm curious about the "extra" part: "extra" from what? If this happens, hopefully this will be logged somewhere? Note that this type of

Re: [PATCH 3/3] RDS: TCP: Delete an error message for a failed memory allocation in rds_tcp_init_net()

On (05/22/17 16:13), SF Markus Elfring wrote: > > Omit an extra message for a memory allocation failure in this function. The change itself is harmless, but I'm curious about the "extra" part: "extra" from what? If this happens, hopefully this will be logged somewhere? Note that this type of

Re: Question about SOCK_SEQPACKET

On (05/05/17 10:45), Steven Whitehouse wrote: > > I do wonder if the man page for recvmsg is wrong, or at least a bit > confusing. SOCK_SEQPACKET is stream based not message based - it just > happens to have EOR markers in the stream. There is no reason that the whole > message needs to be

Re: Question about SOCK_SEQPACKET

On (05/05/17 10:45), Steven Whitehouse wrote: > > I do wonder if the man page for recvmsg is wrong, or at least a bit > confusing. SOCK_SEQPACKET is stream based not message based - it just > happens to have EOR markers in the stream. There is no reason that the whole > message needs to be

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

On (03/15/17 10:08), Dmitry Vyukov wrote: > After I've applied the patch these reports stopped to happen, and I > have not seem any other reports that look relevant. > However, it there was one, but it looks like a different issue and it > was probably masked by massive amounts of original

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

On (03/15/17 10:08), Dmitry Vyukov wrote: > After I've applied the patch these reports stopped to happen, and I > have not seem any other reports that look relevant. > However, it there was one, but it looks like a different issue and it > was probably masked by massive amounts of original

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

On (03/14/17 09:14), Dmitry Vyukov wrote: > Another one now involving rds_tcp_listen_stop : > kworker/u4:1/19 is trying to acquire lock: > (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock > include/net/sock.h:1460 [inline] > (sk_lock-AF_INET){+.+.+.}, at: [] > rds_tcp_listen_stop+0x5c/0x150

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

On (03/14/17 09:14), Dmitry Vyukov wrote: > Another one now involving rds_tcp_listen_stop : > kworker/u4:1/19 is trying to acquire lock: > (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock > include/net/sock.h:1460 [inline] > (sk_lock-AF_INET){+.+.+.}, at: [] > rds_tcp_listen_stop+0x5c/0x150

Re: net/rds: use-after-free in inet_create

Actually, I'm not sure if I can assert that these are all manifestations of the same bug- was a netns-delete involved in this one as well? I see: > BUG: KASAN: use-after-free in memcmp+0xe3/0x160 lib/string.c:768 at : > memcmp+0xe3/0x160 lib/string.c:768 : > rds_find_bound+0x4fe/0x8a0

Re: net/rds: use-after-free in inet_create

Actually, I'm not sure if I can assert that these are all manifestations of the same bug- was a netns-delete involved in this one as well? I see: > BUG: KASAN: use-after-free in memcmp+0xe3/0x160 lib/string.c:768 at : > memcmp+0xe3/0x160 lib/string.c:768 : > rds_find_bound+0x4fe/0x8a0

Re: net/rds: use-after-free in inet_create

On (02/28/17 18:45), Dmitry Vyukov wrote: > > Yes, I can now apply custom patches to the bots. However, it fired > only 3 times, so it will give weak signal. But at least it will test > that the patch does not cause other bad things. Ok, let me do my bit of homework on this one and get back to

Re: net/rds: use-after-free in inet_create

On (02/28/17 18:45), Dmitry Vyukov wrote: > > Yes, I can now apply custom patches to the bots. However, it fired > only 3 times, so it will give weak signal. But at least it will test > that the patch does not cause other bad things. Ok, let me do my bit of homework on this one and get back to

Re: net/rds: use-after-free in inet_create

On (02/28/17 17:51), Dmitry Vyukov wrote: > Searching other crashes for "net/rds" I found 2 more crashes that may > be related. They suggest that the delayed works are not properly > stopped when the socket is destroyed. That would explain how > rds_connect_worker accesses freed net, right? yes,

Re: net/rds: use-after-free in inet_create

On (02/28/17 17:51), Dmitry Vyukov wrote: > Searching other crashes for "net/rds" I found 2 more crashes that may > be related. They suggest that the delayed works are not properly > stopped when the socket is destroyed. That would explain how > rds_connect_worker accesses freed net, right? yes,

Re: net/rds: use-after-free in inet_create

On (02/28/17 17:32), Dmitry Vyukov wrote: > Not reproducible so far. > > rds is compiled into kernel (no modules): > CONFIG_RDS=y > CONFIG_RDS_TCP=y I see. So if it never gets unloaded, the rds_connections "should" be around forever.. let me inspect code and see if I spot some race-window.. >

Re: net/rds: use-after-free in inet_create

On (02/28/17 17:32), Dmitry Vyukov wrote: > Not reproducible so far. > > rds is compiled into kernel (no modules): > CONFIG_RDS=y > CONFIG_RDS_TCP=y I see. So if it never gets unloaded, the rds_connections "should" be around forever.. let me inspect code and see if I spot some race-window.. >

Re: net/rds: use-after-free in inet_create

On (02/28/17 16:49), Dmitry Vyukov wrote: > > Grepping "socket" there, it was doing lots of things with sockets. Are > we looking for some particular socket type? If there are few programs > that create sockets of that type, then we can narrow down the set: Yes, we are looking for PF_RDS/AF_RDS

Re: net/rds: use-after-free in inet_create

On (02/28/17 16:49), Dmitry Vyukov wrote: > > Grepping "socket" there, it was doing lots of things with sockets. Are > we looking for some particular socket type? If there are few programs > that create sockets of that type, then we can narrow down the set: Yes, we are looking for PF_RDS/AF_RDS

Re: net/rds: use-after-free in inet_create

On (02/28/17 15:22), Dmitry Vyukov wrote: > > Hello, > > I've got the following report while running syzkaller fuzzer on > linux-next/8d01c069486aca75b8f6018a759215b0ed0c91f0. So far it > happened only once. net was somehow deleted from underneath > inet_create. I've noticed that rds uses

Re: net/rds: use-after-free in inet_create

On (02/28/17 15:22), Dmitry Vyukov wrote: > > Hello, > > I've got the following report while running syzkaller fuzzer on > linux-next/8d01c069486aca75b8f6018a759215b0ed0c91f0. So far it > happened only once. net was somehow deleted from underneath > inet_create. I've noticed that rds uses

Re: [net-next][PATCH] RDS: keep data type consistent in the user visible header

On (02/20/17 10:19), David Miller wrote: > > The correct fix it to use "__u8", "__u64", etc. So the rest of rds.h uses uint8_t, uint32_t etc Perhaps (I'm not sure of the origins) this was because of the shared OpenIB.org BSD license etc using __u8 in one place and uint8_t in another would seem

Re: [net-next][PATCH] RDS: keep data type consistent in the user visible header

On (02/20/17 10:19), David Miller wrote: > > The correct fix it to use "__u8", "__u64", etc. So the rest of rds.h uses uint8_t, uint32_t etc Perhaps (I'm not sure of the origins) this was because of the shared OpenIB.org BSD license etc using __u8 in one place and uint8_t in another would seem

Re: net/packet: use-after-free in packet_rcv_fanout

On (02/10/17 10:00), Cong Wang wrote: > My understanding about the race here is packet_release() doesn't > wait for flying packets correctly, which leads to a flying packet still > refers to the struct sock which is being released. > > This could happen because struct packet_fanout is refcn'ted,

Re: net/packet: use-after-free in packet_rcv_fanout

On (02/10/17 10:00), Cong Wang wrote: > My understanding about the race here is packet_release() doesn't > wait for flying packets correctly, which leads to a flying packet still > refers to the struct sock which is being released. > > This could happen because struct packet_fanout is refcn'ted,

Re: net/packet: use-after-free in packet_rcv_fanout

On (02/09/17 19:19), Eric Dumazet wrote: > > More likely the bug is in fanout_add(), with a buggy sequence in error > case, and not correct locking. > > kfree(po->rollover); > po->rollover = NULL; > > Two cpus entering fanout_add() (using the same af_packet socket, > syzkaller courtesy...)

Re: net/packet: use-after-free in packet_rcv_fanout

On (02/09/17 19:19), Eric Dumazet wrote: > > More likely the bug is in fanout_add(), with a buggy sequence in error > case, and not correct locking. > > kfree(po->rollover); > po->rollover = NULL; > > Two cpus entering fanout_add() (using the same af_packet socket, > syzkaller courtesy...)

Re: net/packet: use-after-free in packet_rcv_fanout

On (02/09/17 14:14), Dmitry Vyukov wrote: > > Call Trace: : > packet_rcv_has_room+0x25/0xb0 net/packet/af_packet.c:1308 > fanout_demux_rollover+0x3bb/0x6b0 net/packet/af_packet.c:1388 > packet_rcv_fanout+0x674/0x800 net/packet/af_packet.c:1490 > dev_queue_xmit_nit+0x73a/0xa90

Re: net/packet: use-after-free in packet_rcv_fanout

On (02/09/17 14:14), Dmitry Vyukov wrote: > > Call Trace: : > packet_rcv_has_room+0x25/0xb0 net/packet/af_packet.c:1308 > fanout_demux_rollover+0x3bb/0x6b0 net/packet/af_packet.c:1388 > packet_rcv_fanout+0x674/0x800 net/packet/af_packet.c:1490 > dev_queue_xmit_nit+0x73a/0xa90

Re: [PATCH v2 net-next 6/9] sunvnet: straighten up message event handling logic

On (02/08/17 08:28), Shannon Nelson wrote: > The existing code does this as well - if it first finds a RESET, it handles > it then hits the return 0. Next if it finds the UP, it does the goto back > to the ldc_ctrl: to process, and hits the same return 0. Only if neither of > these bits have

Re: [PATCH v2 net-next 6/9] sunvnet: straighten up message event handling logic

On (02/08/17 08:28), Shannon Nelson wrote: > The existing code does this as well - if it first finds a RESET, it handles > it then hits the return 0. Next if it finds the UP, it does the goto back > to the ldc_ctrl: to process, and hits the same return 0. Only if neither of > these bits have

Re: [PATCH v2 net-next 6/9] sunvnet: straighten up message event handling logic

On (02/07/17 14:12), Shannon Nelson wrote: > + > + /* we don't expect any other bits */ > + BUG_ON(port->rx_event & ~(LDC_EVENT_DATA_READY | > + LDC_EVENT_RESET | > + LDC_EVENT_UP)); > + > + /* RESET takes precedent over any

Re: [PATCH v2 net-next 6/9] sunvnet: straighten up message event handling logic

On (02/07/17 14:12), Shannon Nelson wrote: > + > + /* we don't expect any other bits */ > + BUG_ON(port->rx_event & ~(LDC_EVENT_DATA_READY | > + LDC_EVENT_RESET | > + LDC_EVENT_UP)); > + > + /* RESET takes precedent over any

Re: [rds-devel] [PATCH 2/2] rds: Remove duplicate prefix from rds_conn_path_error use

On (10/15/16 11:53), Joe Perches wrote: > > rds_conn_path_error already prefixes "RDS:" to the output. > > Signed-off-by: Joe Perches <j...@perches.com> Acked-by: Sowmini Varadhan <sowmini.varad...@oracle.com>

Re: [rds-devel] [PATCH 1/2] rds: Remove unused rds_conn_error

igned-off-by: Joe Perches <j...@perches.com> Acked-by: Sowmini Varadhan <sowmini.varad...@oracle.com>

Re: [rds-devel] [PATCH 2/2] rds: Remove duplicate prefix from rds_conn_path_error use

On (10/15/16 11:53), Joe Perches wrote: > > rds_conn_path_error already prefixes "RDS:" to the output. > > Signed-off-by: Joe Perches Acked-by: Sowmini Varadhan

Re: [rds-devel] [PATCH 1/2] rds: Remove unused rds_conn_error

-off-by: Joe Perches Acked-by: Sowmini Varadhan

Re: [PATCH v05 08/72] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h

On (08/22/16 20:32), Mikko Rapeli wrote: > > Fixes userspace compilation errors like: > > linux/rds.h:96:2: error: unknown type name ‘uint8_t’ > > Signed-off-by: Mikko Rapeli <mikko.rap...@iki.fi> Acked-by: Sowmini Varadhan <sowmini.varad...@oracle.com> I thi

Re: [PATCH v05 08/72] rds.h: use __u8, __u16, __s16, __u32 and __s64 from linux/types.h

On (08/22/16 20:32), Mikko Rapeli wrote: > > Fixes userspace compilation errors like: > > linux/rds.h:96:2: error: unknown type name ‘uint8_t’ > > Signed-off-by: Mikko Rapeli Acked-by: Sowmini Varadhan I think we discussed this some time before, and I certainly dont

Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

On (05/04/16 10:32), Herbert Xu wrote: > > Please base it on cryptodev. > Looks like this got fixed in cryptodev by commit cece762f6f3c ("lib/mpi: mpi_write_sgl(): fix out-of-bounds stack access") Thanks, --Sowmini

Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

On (05/04/16 10:32), Herbert Xu wrote: > > Please base it on cryptodev. > Looks like this got fixed in cryptodev by commit cece762f6f3c ("lib/mpi: mpi_write_sgl(): fix out-of-bounds stack access") Thanks, --Sowmini

Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

On (05/03/16 16:12), Herbert Xu wrote: > > Sorry, but your patch doesn't apply against the current tree at all. > Please rebase it if it is still needed. Hello, I had based my patch off of net-next, which is where I do my work. I'd be happy to rebase it on the "current tree", but given that

Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

On (05/03/16 16:12), Herbert Xu wrote: > > Sorry, but your patch doesn't apply against the current tree at all. > Please rebase it if it is still needed. Hello, I had based my patch off of net-next, which is where I do my work. I'd be happy to rebase it on the "current tree", but given that

Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

On (04/28/16 09:01), Herbert Xu wrote: > Subject: Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in > mpi_write_to_sgl > > Please cc linux-crypto. Just bounced the message to linux-crypto as well. I think get_maintainers.pl might also need to be updated to generate this automatically.

Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

On (04/28/16 09:01), Herbert Xu wrote: > Subject: Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in > mpi_write_to_sgl > > Please cc linux-crypto. Just bounced the message to linux-crypto as well. I think get_maintainers.pl might also need to be updated to generate this automatically.

[PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

Commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") added mpi_write_to_sgl() which generates traps due to unaligned access on some platforms like sparc. Fix this by using the get_unaligned* and put_unaligned* functions. Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") Si

[PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

Commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") added mpi_write_to_sgl() which generates traps due to unaligned access on some platforms like sparc. Fix this by using the get_unaligned* and put_unaligned* functions. Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") Si

Re: [PATCH] lib/mpi: Fix kernel unaligned acces in mpi_write_to_sgl

On (04/21/16 10:23), Tadeusz Struk wrote: > > What if the mpi_limb_t will happen to be 64 bit? > Thanks, When I checked this with cscope, I found typedef unsigned long int mpi_limb_t; thus I used the *32 functions. But you obviously know better, since you wrote this code (and bug). If you

Re: [PATCH] lib/mpi: Fix kernel unaligned acces in mpi_write_to_sgl

On (04/21/16 10:23), Tadeusz Struk wrote: > > What if the mpi_limb_t will happen to be 64 bit? > Thanks, When I checked this with cscope, I found typedef unsigned long int mpi_limb_t; thus I used the *32 functions. But you obviously know better, since you wrote this code (and bug). If you

[PATCH] lib/mpi: Fix kernel unaligned acces in mpi_write_to_sgl

Commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") added mpi_write_to_sgl() which generates traps due to unaligned access on some platforms like sparc. Fix this by using the get_unaligned* and put_unaligned* functions. Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") Si

[PATCH] lib/mpi: Fix kernel unaligned acces in mpi_write_to_sgl

Commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") added mpi_write_to_sgl() which generates traps due to unaligned access on some platforms like sparc. Fix this by using the get_unaligned* and put_unaligned* functions. Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") Si

[PATCH v9] i40e: Look up MAC address in Open Firmware or IDPROM

F_MAC flag in the platform-private i40e_pf structure tracks whether a platform-specific mac address was found, in which case calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan() will be triggered. Reviewed-by: Martin K. Petersen Signed-off-by: Sowmini Varadhan --- v2, v3: Andy Shevchenko comments v

[PATCH v9] i40e: Look up MAC address in Open Firmware or IDPROM

F_MAC flag in the platform-private i40e_pf structure tracks whether a platform-specific mac address was found, in which case calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan() will be triggered. Reviewed-by: Martin K. Petersen <martin.peter...@oracle.com> Signed-off-by: Sowmini Varadha

[PATCH v8] i40e: Look up MAC address in Open Firmware or IDPROM

F_MAC flag in the platform-private i40e_pf structure tracks whether a platform-specific mac address was found, in which case calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan() will be triggered. Reviewed-by: Martin K. Petersen Signed-off-by: Sowmini Varadhan --- v2, v3: Andy Shevchenko comments v

[PATCH v8] i40e: Look up MAC address in Open Firmware or IDPROM

F_MAC flag in the platform-private i40e_pf structure tracks whether a platform-specific mac address was found, in which case calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan() will be triggered. Reviewed-by: Martin K. Petersen <martin.peter...@oracle.com> Signed-off-by: Sowmini Varadha

[PATCH RESEND v7] i40e: Look up MAC address in Open Firmware or IDPROM

Signed-off-by: Sowmini Varadhan --- v2, v3: Andy Shevchenko comments v4: Shannon Nelson review: explicitly set up mac filters before register_netdev v5: Shannon Nelson code style comments v6: Shannon Nelson code style comments v7: Ensure that i40e_macaddr_init() is called only for VSI_MAIN, and only

bar

_mac field in the platform-private i40e_pf structure tracks whether the mac address was default or not, and in the latter case, will trigger the calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan(). Reviewed-by: Martin K. Petersen Signed-off-by: Sowmini Varadhan --- v2, v3: Andy Shevchenko c

[PATCH RESEND v7] i40e: Look up MAC address in Open Firmware or IDPROM

;martin.peter...@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varad...@oracle.com> --- v2, v3: Andy Shevchenko comments v4: Shannon Nelson review: explicitly set up mac filters before register_netdev v5: Shannon Nelson code style comments v6: Shannon Nelson code style comments v7: Ensure

bar

_mac field in the platform-private i40e_pf structure tracks whether the mac address was default or not, and in the latter case, will trigger the calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan(). Reviewed-by: Martin K. Petersen <martin.peter...@oracle.com> Signed-off-by: Sowmini Varadha

  1   2   3   4   >