On Wed, Jun 5, 2019 at 10:43 AM Hangbin Liu wrote:
> Although I'm still not clear what's the difference between
>
> a) adding a dup rule and remove it later
> and
> b) return 0 directly if the rule exactally the same.
The Android code updates ip rules by adding the new rule and then
deleting the
On Wed, Jun 5, 2019 at 11:15 AM Hangbin Liu wrote:
> How do you add the rules? with ip cmd it should has NLM_F_EXCL flag and
> you will get -EEXIST error out.
The fact that the code worked before this commit implies that it was
*not* using NLM_F_EXCL. :-)
The code is here if you want to take a lo
On Wed, Jun 5, 2019 at 12:29 PM Hangbin Liu wrote:
> > We rely on being able to add a rule and either have a dup be created
> > (in which case we'll remove it later) or have it fail with EEXIST (in
> > which case we won't remove it later).
>
> With Maciej said, how about add NLM_F_EXCL flag when y
On Wed, Jun 5, 2019 at 12:58 PM David Ahern wrote:
> I think it is crazy to add multiple identical rules given the linear
> effect on performance.
Not sure if this is what you were implying or not, but our code
doesn't maintain multiple identical rules in steady state. It only
uses them for make-
On Sat, Apr 28, 2018 at 10:04 AM, Alexei Starovoitov
wrote:
> Another approach could be to use map-in-map and have almost atomic
> replace of the whole map with new potentially empty map. The prog
> can continue using the new map, while user space walks no longer
> accessed old map.
That sounds l
On Wed, Aug 16, 2017 at 7:25 AM, Jonathan Basseri
wrote:
> If an IPv6 socket has a valid dst cache
Did you look into why IPv4 does not suffer from this problem?
That said, clearing the dst cache entry does seem prudent in general.
quot;)
Tested: https://android-review.googlesource.com/417481
Tested: https://android-review.googlesource.com/418659
Tested: https://android-review.googlesource.com/424463
Tested: https://android-review.googlesource.com/452776 passes on net-next
Signed-off-by: Lorenzo Colitti
---
net/xfrm/xfrm_policy.c |
On Mon, Sep 2, 2019 at 2:55 AM Maciej Żenczykowski
wrote:
> It's not immediately clear to me what is the better approach as I'm
> not immediately certain what RTF_ADDRCONF truly means.
> However the in kernel header file comment does explicitly mention this
> being used to flag routes derived from
On Tue, Sep 3, 2019 at 11:18 AM David Ahern wrote:
> addrconf_f6i_alloc is used for addresses added by userspace
> (ipv6_add_addr) and anycast. ie., from what I can see it is not used for RAs
Isn't ipv6_add_addr called by addrconf_prefix_rcv_add_addr, which is
called by addrconf_prefix_rcv, which
On Fri, Jul 6, 2018 at 11:37 AM Subash Abhinov Kasiviswanathan
wrote:
>
> From the call stack, a TCP socket is being destroyed using netlink_diag.
> The memory dump showed that the socket was an inet request socket (in
> state TCP_NEW_SYN_RECV) with refcount of 0.
> [...]
> 13232.479820: <2>
just remove the free in that
function.
Cc: David Ahern
Tested: passes Android sock_diag_test.py, which exercises this codepath
Fixes: d7226c7a4dd1 ("net: diag: Fix refcnt leak in error path destroying
socket")
Signed-off-by: Lorenzo Colitti
---
net/ipv4/tcp.c | 3 +--
1 file changed, 1
On Fri, Jul 6, 2018 at 7:24 PM Eric Dumazet wrote:
>
> Your patch makes sense to me, please submit it formally with :
>
> Fixes: d7226c7a4dd1 ("net: diag: Fix refcnt leak in error path destroying
> socket")
> Cc: David Ahern
Submitted a patch against net: https://patchwork.ozlabs.org/patch/9407
On Sat, Jul 7, 2018 at 10:29 PM Eric Dumazet wrote:
> >> Tested: passes Android sock_diag_test.py, which exercises this codepath
> >
> > If this Android test case exercises this path, why didn't it trigger
> > the double free and thus cause this bug to be found much sooner?
> >
> > Just curious.
>
On Sat, Jul 7, 2018 at 10:56 PM David Ahern wrote:
> > Here is a packetdrill test :
>
> So I have to either learn how to use packetdrill or install a web server
> and put load on it. If the Android tests are not publicly available then
> the reference should be removed from the commit log.
It is
On Tue, Mar 20, 2018 at 12:57 AM, Chenbo Feng
wrote:
> - if (!capable(CAP_SYS_ADMIN) && sysctl_unprivileged_bpf_disabled)
> + if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
> return -EPERM;
>
Acked-by: Lorenzo Colitti
Sh
tream change to
an include file causes a merge conflict with the delete.
This patch fixes the problem by moving the iproute2 linux headers
from include/linux to include/uapi/linux.
Tested: compiles on ubuntu trusty (glibc)
Signed-off-by: Elliott Hughes
Signed-off-by: Lorenzo Colitti
---
M
On Tue, Oct 3, 2017 at 5:23 AM, enh wrote:
>> Rather than moving everything, why not make kernel headers directory
>> configurable as part of the configure script setup process.
>
> the problem is that C libraries with their our own uapi headers still
> need your app-specific headers. to build ipr
lement the get_exact dumping functionality")
Tested: https://android-review.googlesource.com/c/kernel/tests/+/755889/
Signed-off-by: Lorenzo Colitti
---
net/ipv4/udp_diag.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
i
On Fri, Sep 14, 2018 at 11:30 PM David Miller wrote:
> Unfortunately I think we are stuck with how things are now.
>
> Indisputably, your patch breaks userland components that have
> workarounds in order to work with existing kernels. [...]
> I cannot apply this, sorry.
Understood. We're about t
When using IPsec tunnel mode, VTIs provide many benefits compared
to direct configuration of xfrm policies / states. However, one
limitation is that there can only be one VTI between a given pair
of IP addresses. This does not allow configuring multiple IPsec
tunnels to the same security gateway. T
at
is never set into tunnel parameters.
Signed-off-by: Lorenzo Colitti
---
net/ipv4/ip_tunnel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 5ddb1cb52b..539c8f22c4 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@
s the mark to
select an XFRM state. The state transforms the packet.
Signed-off-by: Lorenzo Colitti
---
net/ipv4/ip_vti.c | 52 ++
net/ipv6/ip6_vti.c | 67 --
2 files changed, 88 insertions(+), 31 dele
design). So attempts to create such duplicate tunnels
- or to change one tunnel in such a way that it would duplicate
another - will fail with EEXIST.
Signed-off-by: Lorenzo Colitti
---
include/uapi/linux/if_tunnel.h | 4
net/ipv4/ip_tunnel.c | 10 +-
net/ipv4/ip_vti.c
eter.
This could also be done by expanding the existing flags parameter
from __be16 to __be32 and ensuring that the new flags are all
above the 16-bit boundary.
Signed-off-by: Lorenzo Colitti
---
include/net/ip_tunnels.h | 6 +-
net/ipv4/ip_gre.c| 6 +++---
net/ipv4/ip_tunnel.
tunnel pointer. The semantics
of the field are:
- When not running a handler that uses tunnels: always null.
- At the beginning of xfrm_input: lookup function pointer.
- After xfrm_input calls the lookup function: tunnel if found,
else null.
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h
the ICMP packet cannot be processed
unless the packet is somehow already marked.
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h| 4
net/xfrm/xfrm_state.c | 33 +
2 files changed, 37 insertions(+)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
This change removes the tunnel parameter from xfrm6_rcv_spi and
deletes xfrm6_rcv_tnl. These were only used by the VTI code and
are now unused.
Tested: https://android-review.googlesource.com/571524
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h | 4 +---
net/ipv6/ip6_vti.c
On Tue, Dec 19, 2017 at 2:56 AM, David Miller wrote:
> > - ICMP errors are similar to input, except the search is for the
> > outbound XFRM state, because the only data that is available is
> > the outbound SPI. Thus, ICMP errors are only processed if the
> > ikey is the same as the same as
On Wed, Jan 3, 2018 at 9:10 PM, Steffen Klassert
wrote:
> The fact that you need new keyed VTIs looks a bit like a workaround
> of the design limitations the VTI interfaces have. Unfortunately
> this is not the only limitation of VTI and I think we don't get what
> we really want by changing VTI w
cu versions of
route lookup")
Tested:
https://android.googlesource.com/kernel/tests/+/master/net/test/multinetwork_test.py
passes again
Signed-off-by: Lorenzo Colitti
---
net/ipv4/route.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 43b69af242..4e153b23bc 10
On Mon, Jun 4, 2018 at 8:51 AM 吉藤英明 wrote:
>
> > + if (ipv6_get_lladdr(dev, &lladdr, IFA_F_TENTATIVE))
> > + get_random_bytes(eui, 8);
>
> Please be aware of I/G bit and G/L bit.
Actually, I think this is fine. RFC 7136 clarified this, and says:
==
Thus, we can conclu
OUTPUT_MARK]);
> +
> + fprintf(fp, "\toutput-mark 0x%x %s", output_mark, _SL_);
> + }
> }
If you wanted to implement the suggestion above, I think you could do
that by moving this code into xfrm_xfrma_print.
Other than that, LGTM.
Acked-by: Lorenzo Col
n");
> + fprintf(stderr, "[ output-mark OUTPUT-MARK]\n");
Nit: I think you want a space between OUTPUT-MARK and ].
Other than that,
Acked-by: Lorenzo Colitti
On Tue, Nov 27, 2018 at 10:17 PM 배석진 wrote:
> >> we saw hundreds of not closed tcp session with FIN_WAIT1 and LAST_ACK.
> >
> > These sessions should have a timer, and eventually disappear.
>
> FIN_WAIT2 and TIME_WAIT have a timer.
> but FIN_WAIT1 and LAST_ACK are have too?
What harm is caused by
x27;t have the same problem.
Fixes: a925aa00a55 ("udp_diag: Implement the get_exact dumping functionality")
Signed-off-by: Lorenzo Colitti
---
net/ipv4/udp_diag.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index d9ad986c7b..5cbb9be052 1
This patch documents the tcp_fwmark_accept sysctl that was
added in 3.15.
Signed-off-by: Lorenzo Colitti
---
Documentation/networking/ip-sysctl.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
.auth = {
> +#if IS_ENABLED(CONFIG_XFRM_HMAC_SHA256_RFC4868)
> + .icv_truncbits = 128,
> +#else
> .icv_truncbits = 96,
> +#endif
Also, consider adding a Tested: line saying that this allows
pf_key_test.py to pass on upstream kernels.
Other than that,
Acked-By: Lorenzo Colitti
clean distclean; ./configure && make
-j64"
Tested: 4.14.1 builds on Android with Android-specific #ifndefs for missing
library code
Signed-off-by: Lorenzo Colitti
---
include/bpf_scm.h | 1 +
include/utils.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/include/bpf_scm.h b
policy and -XFRM_POLICY_OUT (i.e., -1) to clear the output
policy.
Tested: https://android-review.googlesource.com/539816
Signed-off-by: Lorenzo Colitti
---
net/xfrm/xfrm_policy.c | 2 +-
net/xfrm/xfrm_state.c | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/xfrm
On Wed, Sep 4, 2019 at 4:45 AM David Ahern wrote:
>
> exactly. It was shortsighted of me to add the ADDRCONF flag and removing
> it reverts back to the previous behavior.
>
> When I enable radvd, I do see the flag set when it should be and not for
> other addresses. I believe the patch is correct.
Currently, this flag is only shown as "flags 800".
Signed-off-by: Lorenzo Colitti
---
ip/ipaddress.c | 4
1 file changed, 4 insertions(+)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 4900dce09d..8fe2bacde8 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1166,6 +1166
On Sat, Jul 8, 2017 at 12:39 AM, Stephen Hemminger
wrote:
> For the most of the address flags, use a table of bit values rather
> than open coding every value. This allows for easier inevitable
> expansion of flags.
Thanks for doing this.
> +static unsigned int get_ifa_flag_mask(const char *nam
When using IPsec tunnel mode, VTIs provide many benefits compared
to direct configuration of xfrm policies / states. However, one
limitation is that there can only be one VTI between a given pair
of IP addresses. This does not allow configuring multiple IPsec
tunnels to the same security gateway. T
handler that uses tunnels: always null.
- At the beginning of xfrm_input: lookup function pointer.
- After xfrm_input calls the lookup function: tunnel if found,
else null.
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h | 2 ++
net/ipv4/ip_vti.c | 43
the ICMP packet cannot be processed
unless the packet is somehow already marked.
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h| 4
net/xfrm/xfrm_state.c | 32
2 files changed, 36 insertions(+)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
This change removes the tunnel parameter from xfrm6_rcv_spi and
deletes xfrm6_rcv_tnl. These were only used by the VTI code and
are now unused.
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h | 4 +---
net/ipv4/ip_vti.c | 4 ++--
net/ipv6/ip6_vti.c | 2 +-
net/ipv6
ff-by: Lorenzo Colitti
---
include/uapi/linux/if_tunnel.h | 3 ++
net/ipv4/ip_vti.c | 75 +++
net/ipv6/ip6_vti.c | 100 +++--
3 files changed, 136 insertions(+), 42 deletions(-)
diff --git a/include/uapi/
On Thu, Feb 15, 2018 at 1:30 PM, Alexei Starovoitov
wrote:
> Specifically for android we added bpf_lsm hooks, cookie/uid helpers,
> and read-only maps.
> Lorenzo,
> there was a claim in this thread that bpf is disabled on android.
> Can you please clarify ?
It's not compiled out, at least at the
-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h| 9 ++---
include/uapi/linux/xfrm.h | 1 +
net/ipv4/xfrm4_policy.c | 14 +-
net/ipv6/xfrm6_policy.c | 9 ++---
net/xfrm/xfrm_output.c| 3 +++
net/xfrm/xfrm_policy.c| 17
On Mon, Aug 7, 2017 at 8:16 PM, Steffen Klassert
wrote:
> > XFRMA_OFFLOAD_DEV, /* struct xfrm_state_offload */
> > + XFRMA_OUTPUT_MARK, /* __u32 */
> > __XFRMA_MAX
>
> Hm, why don't you use the existing xfrm_mark for this?
> Having two different marks on one SA seems to b
; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h| 9 ++---
include/uapi/linux/xfrm.h | 1 +
net/ipv4/xfrm4_policy.c | 14 +-
net/ipv6/xfrm6_policy.c | 9 ++---
net/xfrm/xfrm_device.c| 3
On Tue, Aug 8, 2017 at 4:51 PM, Steffen Klassert
wrote:
> I thought you can just split the 32 bit mark into two 16 bit marks
> by setting an appropriate mask at the xfrm and the routing mark.
> But this has the drawback that the socket needs to know how possibly
> tunneled packets should be routed
; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti
---
include/net/xfrm.h| 9 ++---
include/uapi/linux/xfrm.h | 1 +
net/ipv4/xfrm4_policy.c | 14 +-
net/ipv6/xfrm6_policy.c | 9 ++---
net/xfrm/xfrm_device.c| 3
On Sun, Jun 4, 2017 at 1:29 AM, Eric Dumazet wrote:
> The problem is that ping sockets should not use udp_poll() in the first
> place, and recent changes in UDP stack finally exposed this old bug.
Acked-By: Lorenzo Colitti
Tested-By: Lorenzo Colitti
On Sun, Jun 11, 2017 at 8:58 PM, Jamal Hadi Salim wrote:
>> Maybe this should both be "inet_request_mark()"?
>>
>
> Challenge is making of a synack requires a new allocated skb;
> and sk is a listening socket - which should/has a mark of
> 0 meaning at ip_build_and_send_pkt() it overrides
> the va
ark already takes that into account. Its semantics (see
inet_request_mark) are:
- If listen socket has a nonzero mark, use that
- Else if sysctl_tcp_fwmark_accept is set and inbound SYN packet has
mark, use that
- Else zero.
which is what you want.
Other than that,
Reviewed-By: Lorenzo Colitt
On Wed, Oct 25, 2017 at 9:49 PM, Nanjappa, Gangadhar
wrote:
> Using linux kernel – 4.4.45 (Blurry Fish Butt), VPN test fails. If I revert
> the attached five patches, VPN test passes.
> [...]
>
> 1. 1-net-core-add-UID-to-flows-rules-and-routes.patch
Those patches don't exist in 4.4, they we
On Tue, May 17, 2016 at 8:53 AM, David Ahern wrote:
> +#else
> +static int tcp_diag_destroy(struct sk_buff *in_skb,
> + const struct inet_diag_req_v2 *req)
> +{
> + return -EOPNOTSUPP;
> +}
> #endif
I don't understand why you need this. inet_diag_cmd_exact already
On Tue, May 17, 2016 at 8:53 AM, David Ahern wrote:
> @@ -2264,7 +2264,7 @@ static int show_one_inet_sock(const struct sockaddr_nl
> *addr,
> if (!(diag_arg->f->families & (1 << r->idiag_family)))
> return 0;
> if (diag_arg->f->kill && kill_inet_sock(h, arg) != 0)
On Tue, May 17, 2016 at 10:14 AM, David Ahern wrote:
>>
>> For example, EOPNOTSUPP can just mean "this socket can't be closed
>> because it's a timewait or NEW_SYN_RECV socket". In hindsight it might
>> have been better to return EBADFD in those cases, but that still
>> doesn't solve the UI proble
On Tue, May 17, 2016 at 10:52 AM, David Ahern wrote:
> code is not setup to handle that. Only option seems to be at least dump an
> error message, but the message can not relate any of the specifics about the
> filter. So something like this though it dumps the message per socket
> matched by the
On Tue, May 17, 2016 at 11:24 AM, David Ahern wrote:
> As I mentioned we can print the unsupported once or per socket matched and
> with the socket params. e.g.,
>
> + } else if (errno == EOPNOTSUPP) {
> + printf("Operation not supported for:\n");
> +
On Wed, May 18, 2016 at 3:35 AM, wrote:
> Would it be acceptable to have a separate column which displays the result of
> the sock destroy operation per socket.
> State... Killed
> ESTAB Y
> TIME_WAIT N
Fine by me, but... what problem are we trying to address? People who
compile
On Thu, May 19, 2016 at 11:06 PM, David Ahern wrote:
> got it. Google does not care about users; don't un-suppress failures.
The users I was trying to care about are the ones that have correctly
configured kernels. It did not seem useful to those users to litter
the dumps with error messages sayi
Without this, using SOCK_DESTROY in enforcing mode results in:
SELinux: unrecognized netlink message type=21 for sclass=32
Signed-off-by: Lorenzo Colitti
---
security/selinux/nlmsgtab.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/selinux/nlmsgtab.c b/security/selinux
type == ICMPV6_ECHO_REQUEST)
> - ping_err(skb, offset, info);
> + ping_err(skb, offset, ntohl(info));
> }
Acked-by: Lorenzo Colitti
On Sun, Apr 3, 2016 at 7:57 AM, Tom Herbert wrote:
> I am curious though, how do you think this would specifically help
> Android with power? Seems like the receiver still needs to be powered
> to receive packets to filter them anyway...
The receiver is powered up, but its wake/sleep cycles are m
;s a UDP socket, or a TIME_WAIT socket),
the socket is silently skipped.
- If an error occurs (e.g., permission denied), the error is
reported and ss exits.
Signed-off-by: Lorenzo Colitti
---
include/linux/sock_diag.h | 1 +
misc/ss.c | 52 +++
like rtnl_talk does.
Signed-off-by: Lorenzo Colitti
---
include/libnetlink.h | 2 ++
lib/libnetlink.c | 14 +++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/libnetlink.h b/include/libnetlink.h
index 431189e..a88cb4d 100644
--- a/include/libnetlink.h
+++ b
esults in EOPNOTSUPP. With this patch, SOCK_DESTROY
succeeds, and after it does, sock_diag reports no child sockets.
Tested-by: Lorenzo Colitti
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordo
On Fri, Dec 18, 2015 at 9:46 PM, Eric Dumazet wrote:
> > Tested-by: Lorenzo Colitti
>
> I am curious, did you use packetdrill for this ?
No, I added this to our existing kernel networking tests:
https://android-review.googlesource.com/#/c/187491/
The tests are written in Python a
sock_diag dumps.
Reported-by: Eric Dumazet
Signed-off-by: Lorenzo Colitti
---
net/ipv4/tcp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index cc7aaa5..7bb1b09 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3099,6 +3099,11 @@ int tcp_abort(struct
igned-off-by: Lorenzo Colitti
---
include/linux/sock_diag.h | 1 +
misc/ss.c | 50 +--
2 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/include/linux/sock_diag.h b/include/linux/sock_diag.h
index 024e1f4..dafcb89 100644
I've just uploaded a new version. The changes from v2 are as
follows:
- Removed the superfluous inline keyword.
- The code now ignores ENOENT from kill_inet_sock. This can
happen if something else closed the socket during the scan, or
if the user requests killing a socket that is not in the ha
like rtnl_talk does.
Signed-off-by: Lorenzo Colitti
---
include/libnetlink.h | 2 ++
lib/libnetlink.c | 16 +---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/include/libnetlink.h b/include/libnetlink.h
index 431189e..a88cb4d 100644
--- a/include/libnetlink.h
On Tue, Dec 22, 2015 at 5:31 PM, Lorenzo Colitti wrote:
> I've just uploaded a new version. The changes from v2 are as
> follows:
> [...]
Also: as requested, kill is now a boolean instead of a bitfield inside a struct.
--
To unsubscribe from this list: send the line "unsubsc
On Thu, Dec 31, 2015 at 5:34 AM, Stephen Hemminger
wrote:
>> + req.nlh.nlmsg_type = SOCK_DESTROY;
>> + req.nlh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
>> + req.nlh.nlmsg_seq = ++rth->seq;
>> + req.r.sdiag_family = d->idiag_family;
>> + req.r.sdiag_protocol = diag_arg->protocol
On Wed, Jan 20, 2016 at 4:25 PM, Eric Dumazet wrote:
> Lorenzo reported that we could not properly find v4mapped sockets
> in inet_diag_find_one_icsk(). This patch fixes the issue.
>
> Reported-by: Lorenzo Colitti
> Signed-off-by: Eric Dumazet
This fixes the problem for me
On Tue, Mar 21, 2017 at 1:08 PM, Chenbo Feng
wrote:
> + if (!sk || !sk_fullsock(sk))
> + return overflowuid;
> + kuid = sock_net_uid(sock_net(sk), sk);
> + return from_kuid_munged(current_user_ns(), kuid);
Is current_user_ns() correct in all the contexts you'll wan
On Wed, Mar 22, 2017 at 6:19 PM, Joel Scherpelz wrote:
> It is useful to prevent misconfigurations from
> unintentionally blackholing too much of the IPv6 address space
> (e.g., home routers announcing RIOs for fc00::/7, which is
> incorrect).
>
> Signed-off-by: Joel Scherpelz
On Wed, Mar 22, 2017 at 8:09 PM, Willem de Bruijn
wrote:
>> + if (!sk || !sk_fullsock(sk))
>> + return overflowuid;
>> + kuid = sock_net_uid(sock_net(sk), sk);
>> + return from_kuid_munged(&init_user_ns, kuid);
>
> Ideally, this would be the user namespace relative
On Fri, Feb 3, 2017 at 6:32 AM, Daniel Borkmann wrote:
>> + sk = skb->sk;
>> + kuid = sock_net_uid(dev_net(skb->dev), sk);
>
>
> Don't you need to test for fullsock? Do you mean something like below?
It should be safe to call sock_net_uid on any type of socket
(including NULL). sk_uid
On Fri, Feb 3, 2017 at 9:31 AM, Eric Dumazet wrote:
>> It should be safe to call sock_net_uid on any type of socket
>> (including NULL). sk_uid was added to struct sock in 86741ec25462
>> ("net: core: Add a UID field to struct sock.")
>
> But a request socket or a timewait socket do not have this
On Fri, Feb 3, 2017 at 9:13 AM, Alexei Starovoitov
wrote:
> I think sk_uid is self explanatory, but cookie is less so.
> Please explain how you plan to use it.
The cookie is the only way to uniquely identify a given socket on the
system (the 5-tuple is not sufficient in the presence of SO_REUSEPO
On Mon, Feb 6, 2017 at 11:17 AM, Chenbo Feng
wrote:
> +BPF_CALL_1(bpf_get_socket_cookie, struct sk_buff *, skb)
> +{
> + return skb->sk ? sock_gen_cookie(skb->sk) : 0;
> +}
> +
Does this code need to increment the socket refcount, or call
ACCESS_ONCE to get skb->sk? The socket filter codepa
On Fri, Feb 3, 2017 at 10:51 AM, Eric Dumazet wrote:
> if (sk) {
> sk = sk_to_full_sk(sk);
> if (sk_fullsock(sk))
> return sk->sk_uid;
> }
Sure, though sk_to_full_sk is in inet_sock.h so I have to move some
core around. Options I see:
1. Move sk_to_full_sk from inet_sock.h to soc
On Sun, Jan 8, 2017 at 1:24 PM, David Ahern wrote:
> Why not use the VRF capability then? create a VRF and assign the interface to
> it. End result is the same -- separate tables and the need to use a
> bind-to-device API to hit those routes.
Requiring that VRFs for this creates additional comp
On Tue, Jan 10, 2017 at 11:08 AM, David Ahern wrote:
> That's news to me. What about IPv6 and VRF is not working or well-supported?
I have no firsthand experience of this myself, but if the problems
that Andrey reports above in this thread are real, then those would
indicate that the code is not
On Tue, Jan 10, 2017 at 12:04 PM, David Ahern wrote:
> > I have no firsthand experience of this myself, but if the problems
> > that Andrey reports above in this thread are real, then those would
> > indicate that the code is not well-supported. Being unable to accept
> > DAD is a pretty serious i
On Tue, Jan 10, 2017 at 5:30 PM, Tobias Klauser wrote:
> -int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
> +static int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
Acked-by: Lorenzo Colitti
On Tue, Jan 10, 2017 at 10:21 PM, Andrey Jr. Melnikov
wrote:
>
> > >>> I have no firsthand experience of this myself, but if the problems
> > >>> that Andrey reports above in this thread are real, then those would
> > >>> indicate that the code is not well-supported. Being unable to accept
> > >>>
On Wed, Jan 11, 2017 at 11:11 PM, David Miller wrote:
> I understand what you're saying, but if you look at how apps can be
> put into hierarchical control groups, and automatically bind to VRF's
> based upon where they are in that cgroup hierarchy, it matches your
> use case precisely.
I think w
cb5e ("net: inet: Support UID-based routing in IP protocols.")
Signed-off-by: Lorenzo Colitti
---
net/ipv4/route.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index fa5c037227..9eabf49013 100644
--- a/net/ipv4/route.c
++
id is
> actually only valid when ATTR_UID is set in ia_valid, indicating that
> the uid is being changed, e.g. by chown.
> [...]
> - if (!err) {
> + if (!err && (iattr->ia_valid & ATTR_UID)) {
Oops. Thanks for fixing this. Unit tested in
https://android-rev
iles allnoconfig, allyesconfig, allmodconfig
Tested: passes existing Android kernel unit tests
Signed-off-by: Lorenzo Colitti
---
Documentation/networking/ip-sysctl.txt | 13 +++
include/linux/ipv6.h | 1 +
include/net/addrconf.h | 2 ++
include/uapi/linux/ipv6.h
On Fri, Dec 16, 2016 at 5:30 PM, Mantas Mikulėnas wrote:
> The protocol field is checked when deleting IPv4 routes, but ignored for
> IPv6, which causes problems with routing daemons accidentally deleting
> externally set routes (observed by multiple bird6 users).
>
> This can be verified using `i
On Wed, Aug 24, 2016 at 12:02 AM, David Ahern wrote:
> +int udp_abort(struct sock *sk, int err)
> +{
> + lock_sock(sk);
> +
> + sk->sk_err = err;
> + sk->sk_error_report(sk);
> + udp_disconnect(sk, 0);
I notice that udp_disconnect does "inet->inet_daddr = 0" but doesn't
to
On Wed, Aug 24, 2016 at 2:02 AM, David Ahern wrote:
>> Looking at the code again, it seems that there's a bug in
>> sock_diag_destroy. If the destroy operation does not occur (e.g., if
>> sock_diag_destroy returns EPERM, or the protocol doesn't support
>> destroy), then it doesn't release the refc
On Wed, Aug 24, 2016 at 2:16 AM, David Ahern wrote:
>> So you'd remove the sock_put and sock_gen_put calls from tcp_abort and
>> just add one sock_gen_put in tcp_diag_destroy? That does seem simpler.
>
> untested and mangled on a copy and paste but the intent is:
...
> if (IS_ERR(sk))
>
This simplifies the code a bit and also allows inet_diag_bc_audit
to send to userspace an error that isn't EINVAL.
Signed-off-by: Lorenzo Colitti
---
net/ipv4/inet_diag.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/net
1 - 100 of 210 matches
Mail list logo
