ot;Structurally dead code")
> Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support")
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Sowmini Varadhan
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,
>
#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 like
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 easy
On (03/14/18 14:28), Eric Dumazet wrote:
>
>
> spin_lock_bh(&rds_tcp_conn_lock);/spin_unlock_bh(&rds_tcp_conn_lock); in
> rds_tcp_conn_free()
>
> is in conflict with the spin_lock_irqsave(&rds_conn_lock, flags);
> in __rds_conn_create()
yes I was going to look into this and fix it later.
> Har
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 kbuild-robot
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
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
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 syzbot
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 taken
#syz dup: WARNING: suspicious RCU usage in rds_loop_conn_alloc
#syz dup: 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 critica
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
> loo
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
> 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
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 no
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 th
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 WARN_
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
> >ov
> 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
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 (in
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 returne
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 deadlock
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 net/rds
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
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 yo
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, I
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..
>
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 -
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 sock_cr
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 i
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, i
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...) might
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 net/core/dev.c
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 been
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 ot
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
igned-off-by: Joe Perches
Acked-by: Sowmini Varadhan
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
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
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 mp
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.
Th
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
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 an
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
lag 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
lag 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
ned-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
eld 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
On (12/03/15 16:53), Bowers, AndrewX wrote:
>
> I get an error -11 on driver init with this patch applied, I can
> revert it and everything works normally. Dmesg screenshot is attached,
> can supply complete dmesg log if needed.
Yes, that's the same thing that I'm running into as well.
Using th
On (11/24/15 12:20), Hannes Frederic Sowa wrote:
> There are some crypto acclerators out there so that putting tls into the
> kernel would give a net benefit, because otherwise user space has to
> copy data into the kernel for device access and back to user space until
> it can finally be send out
On (11/23/15 13:43), Dave Watson wrote:
>
> For kcm, opfd is the fd you would pass along in kcm_attach.
> For rds, it looks like you'd want to use opfd as the sock instead of
> the new one created by sock_create_kern in rds_tcp_conn_connect.
I see.
It's something to consider, and it would certai
On (11/23/15 09:43), Dave Watson wrote:
> Currently gcm(aes) represents ~80% of our SSL connections.
>
> Userspace interface:
>
> 1) A transform and op socket are created using the userspace crypto interface
> 2) Setsockopt ALG_SET_AUTHSIZE is called
> 3) Setsockopt ALG_SET_KEY is called twice, s
> Neat. Though, in my case, I'm not actually just prepending a header.
> I'm doing some more substantial transformations of a packet. And this
> needs to work with v4 too. So I'm not sure implementing a v6 spec will
Understood, that spec was just referenced to indicate that there
are more issues (
On (11/16/15 21:14), Jason A. Donenfeld wrote:
>
> But what about in devices for which self-routing might actually be
> useful? For example, let's say that if an incoming skb is headed for
> dst X, it gets encapsulated and sent to dst A, and for dst Y it gets
> encapsulated and sent to dst B, and
On (11/05/15 11:29), David Miller wrote:
>
> The intention is to let your patch go in as-is, then try and update
> ixgbe/i40e later in net-next or similar.
Sounds good, I can take care of ixgbe/i40e after that happens.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On (11/05/15 11:05), David Miller wrote:
> From: David Miller
> Date: Thu, 05 Nov 2015 10:31:26 -0500 (EST)
>
> > I'll see if I can cook something up.
>
> How does this look?
Looks good to me,
Do you want me to respin patch v7 with this? Or update ixgbe/i40e to use
this later, after this goes
. Petersen
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
drivers/net/ethernet/intel/i40e/i40e_mai
On (11/04/15 21:59), Andy Shevchenko wrote:
>
> Usually the structure of kernel doc is something like following
>
> /**
> * func - summary
> * @paramx: desc
> *
> * Description:
> * Long description in many lines and / or paragraphs
> *
> * Returns:
> * 0 on success or errno otherwise.
>
. Petersen
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
drivers/net/ethernet/intel/i40e/i40e_main.c | 84 ++-
1 files changed, 83
f invoking i40e_macaddr_init() on
platforms that use the default mac address (i.e., when it is not from
OF or idprom) will cause harm, and if it is necessary/possible to
move this invocation to an earlier point in i40e_probe().
Reviewed-by: Martin K. Petersen
Signed-off-by: Sowmini Varadhan
---
v2
On (10/30/15 19:13), Sowmini Varadhan wrote:
> > In looking at a couple other drivers, I see the difference being that
> > they typically are writing the primary mac filter on probe (and any
> > other reset), whereas the i40e "knows" that the default mac address is
>
On (10/30/15 22:03), Nelson, Shannon wrote:
> The more common idiom in our driver would be
>
> err = i40e_get_platform_mac_addr(..);
> if (err) {
Ok.
> Have you tested this beyond a compile?
> Do you have a DT model to try this against?
yes.
> In looking at a couple other drivers,
On (10/30/15 18:57), Nelson, Shannon wrote:
> > >
> > > Going along with this being the equivalent of the ixgbe patch, I'd
> > > prefer the new code to be in i40e_main.c, rather than in i40e_common.c.
> > > In the design of our drivers, the common file is essentially a device
> > > specific layer,
On (10/30/15 18:28), Nelson, Shannon wrote:
>
> Going along with this being the equivalent of the ixgbe patch, I'd
> prefer the new code to be in i40e_main.c, rather than in i40e_common.c.
> In the design of our drivers, the common file is essentially a device
> specific layer, and the OS and plat
On (10/30/15 20:06), Andy Shevchenko wrote:
>
> > +#include "i40e.h"
>
> Why do you need this one exactly?
I needed it to find pf->pdev below.
> > + struct device_node *dp = pci_device_to_OF_node(pf->pdev);
Without it, you will get:
:
CC [M] drivers/net/ethernet/intel
. Petersen
Signed-off-by: Sowmini Varadhan
---
v2: andy shevchenko comments
v3: more andy shevchenko comments
drivers/net/ethernet/intel/i40e/i40e_common.c | 30 +
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
. Petersen
Signed-off-by: Sowmini Varadhan
---
v2: review comments from Andy Shevchenko
drivers/net/ethernet/intel/i40e/i40e_common.c | 32 +
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
b/drivers/net/ethe
On (10/30/15 02:14), Andy Shevchenko wrote:
>
> Does the following has no stubs?
>
> > + struct i40e_pf *pf = hw->back;
> > + struct device_node *dp = pci_device_to_OF_node(pf->pdev);
> > + const unsigned char *addr;
> > +
> > + addr = of_get_mac_address(dp);
>
> ^^^
I w
. Petersen
Signed-off-by: Sowmini Varadhan
---
drivers/net/ethernet/intel/i40e/i40e_common.c | 36 +
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 2d74c6
same
manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and
retry via the deferred call to rds_send_worker() that gets set up on
ENOMEM from rds_tcp_read_sock()
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp_recv.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions
On (10/21/15 21:12), Geert Uytterhoeven wrote:
>
> Does this function really need to return DMA_ERROR_CODE in case of
> failure?
fwiw, this came up very early in code review:
http://marc.info/?l=linux-sparc&m=142613044704833&w=2
--Sowmini
--
To unsubscribe from this list: send the line "unsub
d, and this
cannot be changed for nla_data() that is passed up to userspace.
As a result, the put_unaligned() macro needs to be used to
set up potentially unaligned fields such as the xfrm_stats in
copy_to_user_state()
Signed-off-by: Sowmini Varadhan
---
v2: review comment from thread: cann
On (10/21/15 06:22), David Miller wrote:
> memcpy() _never_ works for avoiding unaligned accessed.
>
> I repeat, no matter what you do, no matter what kinds of casts or
> fancy typing you use, memcpy() _never_ works for this purpose.
:
> There is one and only one portable way to access unaligned
On (10/21/15 06:54), Sowmini Varadhan wrote:
> But __alignof__(*p) is 8 on sparc, and without the patch I get
> all types of unaligned access. So what do you suggest as the fix?
Even though the alignment is, in fact, 8 (and that comes from
struct xfrm_lifetime_cfg), if uspace is firmly at
On (10/21/15 08:57), Steffen Klassert wrote:
> > --- a/net/xfrm/xfrm_user.c
> > +++ b/net/xfrm/xfrm_user.c
> > @@ -2659,7 +2659,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, const
> > struct km_event *c)
> > if (attr == NULL)
> > goto out_free_skb;
> >
> >
A two-part patchset that fixes some "unaligned access" warnings
that showed up my sparc test machines with ipsec set up.
Sowmini Varadhan (2):
crypto/x509: Fix unaligned access in x509_get_sig_params()
Fix unaligned access in xfrm_notify_sa() for DELSA
crypto/asymm
On sparc, deleting established SAs (e.g., by restarting ipsec
at the peer) results in unaligned access messages via
xfrm_del_sa -> km_state_notify -> xfrm_send_state_notify().
Use an aligned pointer to xfrm_usersa_info for this case.
Signed-off-by: Sowmini Varadhan
---
net/xfrm/xfrm_
alignment values into consideration when doing kzalloc()
Signed-off-by: Sowmini Varadhan
---
crypto/asymmetric_keys/x509_public_key.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_public_key.c
b/crypto/asymmetric_keys/x509_public_key.c
ind
transport like IB.
Acked-by: Sowmini Varadhan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
explaining
that the pong has already been added to the sendq earlier..
in the case of IB, if RDS_LL_SEND_FULL has been set, it takes some
head-scratching to figure out how the pong gets sent, and a few
comments could help clarify that.
but other than that, the contents look good to me, thus
On (10/16/15 01:39), Mikko Rapeli wrote:
> "uint32_t vs __u32" nail is:
> https://lkml.org/lkml/2015/6/1/160
shrug. BTW, doesn't having the exported rds.h use __foo everywhere
actually end up with the result that "the kernel use the same names
as user space"
--Sowmini
--
To unsubscribe from this
On (10/16/15 01:00), Mikko Rapeli wrote:
>
> What kind of portability should exported userspace headers from Linux kernel
> need?
>
> Reviews to my previous changes NACKed usage and
> Documentation/CodingStyle chapter 5 says:
>
> (e) Types safe for use in userspace.
>
> In certain struct
On (10/15/15 07:56), Mikko Rapeli wrote:
> Fixes userspace compilation errors like:
>
> error: unknown type name ‘__be32’
> error: field ‘dest_addr’ has incomplete type
>struct sockaddr_storage dest_addr;
Acked-by: Sowmini Varadhan
--
To unsubscribe from this list
On (10/15/15 07:56), Mikko Rapeli wrote:
> Date: Thu, 15 Oct 2015 07:56:01 +0200
> From: Mikko Rapeli
> To: linux-kernel@vger.kernel.org
> Cc: mikko.rap...@iki.fi, "David S. Miller" , Sowmini
> Varadhan , linux-...@vger.kernel.org
> Subject: [PATCH v4 23/79] rds.h: u
needs to make sure that desc is pointing
at an aligned value past the digest_size, and kzalloc appropriately,
taking alignment values into consideration.
Signed-off-by: Sowmini Varadhan
---
crypto/asymmetric_keys/pkcs7_verify.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff
s set to 0 so that we do not trigger any reconnect attempts on the
passive side of the tcp socket in the future, in conformance with
commit c82ac7e69efe ("net/rds: RDS-TCP: only initiate reconnect attempt
on outgoing TCP socket.")
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp_l
terfaces.
Signed-off-by: Sowmini Varadhan
---
net/rds/bind.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/rds/bind.c b/net/rds/bind.c
index bc6b93e..6192566 100644
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -196,7 +196,14 @@ int rds_bind(struct sock
socket with other parts of the kernel stack.
v2: fix kbuild-test-robot warnings, comments from Sergei Shtylov
and Santosh Shilimkar.
Sowmini Varadhan (3):
Use a single TCP socket for both send and receive.
Do not bloat sndbuf/rcvbuf in rds_tcp_tune
Set up MSG_MORE and
p_sendpage()
Signed-off-by: Sowmini Varadhan
---
v2: Sergei Shtylov, Santosh Shilimkar comments (some parens retained for
readability)
net/rds/tcp_send.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/net/rds/tcp_send.c b/net/rds/tcp_send.c
index 53b17ca..2894
ge in
rds_tcp_accept_one() has been modified to emulate the BGP state
machine: the smaller IP address should back off from the connection attempt.
Signed-off-by: Sowmini Varadhan
---
v2: kbuild-test-robot warning around __be32, modify subject line per
Santosh Shilimkar
-by: Sowmini Varadhan
---
net/rds/tcp.c | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index c42b60b..9d6ddba 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -67,21 +67,13 @@ void rds_tcp_nonagle(struct socket *sock
On (09/30/15 08:50), santosh shilimkar wrote:
> > rs_tcp = (struct rds_tcp_connection *)conn->c_transport_data;
> >-WARN_ON(!rs_tcp || rs_tcp->t_sock);
> >+if (rs_tcp->t_sock && inet->inet_saddr < inet->inet_daddr) {
> >+struct sock *nsk = new_sock->sk;
> >
> Any reason you
On (09/30/15 08:56), santosh shilimkar wrote:
> Your checkpatch.pl should have complained about commit
> reference in the change-log. You might want to fix that
> for consistency.
It didnt. But ok, I'll fix this nit as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
" or
> - RDS TCP can use "RDS: TCP" or "RDS/TCP:"
Ok, but in this case patch 1/3 the changes affect both core and rds-tcp
modules.
Working on patchv2 that will address Sergei's comments and the
kbuild-test-robot warning as well
>
> $subject
> s/net/rds:/RD
For the same reasons as 2f53384424 and 35f9c09fe9, rds_tcp_xmit
may have multiple pages to send, so use the MSG_MORE and
MSG_SENDPAGE_NOTLAST as hints to tcp_sendpage()
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp_send.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff
-by: Sowmini Varadhan
---
net/rds/tcp.c | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index c42b60b..9d6ddba 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -67,21 +67,13 @@ void rds_tcp_nonagle(struct socket *sock
socket with other parts of the kernel stack.
Sowmini Varadhan (3):
Use a single TCP socket for both send and receive.
Do not bloat sndbuf/rcvbuf in rds_tcp_tune
Set up MSG_MORE and MSG_SENDPAGE_NOTLAST as appropriate in
rds_tcp_xmit
net/rds/connection.c | 22
ge in
rds_tcp_accept_one() has been modified to emulate the BGP state
machine: the smaller IP address should back off from the connection attempt.
Signed-off-by: Sowmini Varadhan
---
net/rds/connection.c | 22 ++
net/rds/rds.h|4 +++-
net/rds/tcp_listen.c | 1
1 - 100 of 175 matches
Mail list logo
