* Re: [PATCH v2 0/2] net: dsa: Move temperature sensor code into PHY.
From: Vivien Didelot @ 2017-01-20 3:26 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev
In-Reply-To: <20170120004328.GA381@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> Sorry, i forget the net-next in the subject line.
Maybe use this opportunity to resend this thread with the good subject
prefix and the people involved in v1?
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH] virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on xmit
From: Jason Wang @ 2017-01-20 3:29 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Rolf Neugebauer, netdev, davem, rppt
In-Reply-To: <20170120002916-mutt-send-email-mst@kernel.org>
On 2017年01月20日 06:30, Michael S. Tsirkin wrote:
> On Thu, Jan 19, 2017 at 11:06:59AM +0800, Jason Wang wrote:
>>
>> On 2017年01月18日 23:18, Michael S. Tsirkin wrote:
>>> On Wed, Jan 18, 2017 at 11:54:21AM +0800, Jason Wang wrote:
>>>> On 2017年01月18日 02:27, Michael S. Tsirkin wrote:
>>>>> On Tue, Jan 17, 2017 at 06:13:51PM +0000, Rolf Neugebauer wrote:
>>>>>> This patch part reverts fd2a0437dc33 and e858fae2b0b8 which introduced a
>>>>>> subtle change in how the virtio_net flags are derived from the SKBs
>>>>>> ip_summed field.
>>>>>>
>>>>>> With the above commits, the flags are set to VIRTIO_NET_HDR_F_DATA_VALID
>>>>>> when ip_summed == CHECKSUM_UNNECESSARY, thus treating it differently to
>>>>>> ip_summed == CHECKSUM_NONE, which should be the same.
>>>>>>
>>>>>> Further, the virtio spec 1.0 / CS04 explicitly says that
>>>>>> VIRTIO_NET_HDR_F_DATA_VALID must not be set by the driver.
>>>>>>
>>>>>> Signed-off-by: Rolf Neugebauer<rolf.neugebauer@docker.com>
>>>>> Fixes: fd2a0437dc33 ("virtio_net: introduce virtio_net_hdr_{from,to}_skb")
>>>>> Fixes: e858fae2b0b8 (" virtio_net: use common code for virtio_net_hdr and skb GSO conversion")
>>>>> Acked-by: Michael S. Tsirkin<mst@redhat.com>
>>>>>
>>>>> Should be backported into stable as well.
>>>> Looks like a side effect is that we will never see this on receive path?
>>> I thought receive path is using virtio_net_hdr_to_skb - isn't it?
>>>
>> The problem is tun use this on xmit.
>>
>> Thanks
> Oh I missed that. I agree, let's add a flag that allows this.
>
Will post a fix soon.
Thanks
^ permalink raw reply
* Re: [net PATCH v5 6/6] virtio_net: XDP support for adjust_head
From: John Fastabend @ 2017-01-20 3:38 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170119231027-mutt-send-email-mst@kernel.org>
On 17-01-19 01:11 PM, Michael S. Tsirkin wrote:
> On Thu, Jan 19, 2017 at 11:05:40AM +0800, Jason Wang wrote:
>>
>>
>> On 2017年01月18日 23:15, Michael S. Tsirkin wrote:
>>> On Tue, Jan 17, 2017 at 02:22:59PM -0800, John Fastabend wrote:
>>>> Add support for XDP adjust head by allocating a 256B header region
>>>> that XDP programs can grow into. This is only enabled when a XDP
>>>> program is loaded.
>>>>
>>>> In order to ensure that we do not have to unwind queue headroom push
>>>> queue setup below bpf_prog_add. It reads better to do a prog ref
>>>> unwind vs another queue setup call.
>>>>
>>>> At the moment this code must do a full reset to ensure old buffers
>>>> without headroom on program add or with headroom on program removal
>>>> are not used incorrectly in the datapath. Ideally we would only
>>>> have to disable/enable the RX queues being updated but there is no
>>>> API to do this at the moment in virtio so use the big hammer. In
>>>> practice it is likely not that big of a problem as this will only
>>>> happen when XDP is enabled/disabled changing programs does not
>>>> require the reset. There is some risk that the driver may either
>>>> have an allocation failure or for some reason fail to correctly
>>>> negotiate with the underlying backend in this case the driver will
>>>> be left uninitialized. I have not seen this ever happen on my test
>>>> systems and for what its worth this same failure case can occur
>>>> from probe and other contexts in virtio framework.
>>>>
>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>> I've been thinking about it - can't we drop
>>> old buffers without the head room which were posted before
>>> xdp attached?
>>>
>>> Avoiding the reset would be much nicer.
>>>
>>> Thoughts?
>>>
>>
>> As been discussed before, device may use them in the same time so it's not
>> safe. Or do you mean detect them after xdp were set and drop the buffer
>> without head room, this looks sub-optimal.
>>
>> Thanks
>
> Yes, this is what I mean. Why is this suboptimal? It's a single branch
> in code. Yes we might lose some packets but the big hammer of device
> reset will likely lose more.
>
Maybe I'm not following, is the suggestion to drop the packets after XDP
is setup for all outstanding buffers until we have done a reallocation of
all the buffers? In this case we can't just detach the buffers we have to
wait until the backend retires them by using them correct?
But when XDP setup call returns we need to guarantee that buffers and
driver are setup. Otherwise the next n packets get dropped in the future.
If there is no traffic currently this could be at some undetermined point
in the future. This will be very buggy.
Did I miss something?
Thanks,
John
^ permalink raw reply
* Re: [net PATCH v5 6/6] virtio_net: XDP support for adjust_head
From: John Fastabend @ 2017-01-20 3:39 UTC (permalink / raw)
To: Jason Wang, Michael S. Tsirkin
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <d1c43849-0da9-5f03-1eae-09a27c2e9985@redhat.com>
On 17-01-19 07:26 PM, Jason Wang wrote:
>
>
> On 2017年01月20日 05:11, Michael S. Tsirkin wrote:
>> On Thu, Jan 19, 2017 at 11:05:40AM +0800, Jason Wang wrote:
>>>
>>> On 2017年01月18日 23:15, Michael S. Tsirkin wrote:
>>>> On Tue, Jan 17, 2017 at 02:22:59PM -0800, John Fastabend wrote:
>>>>> Add support for XDP adjust head by allocating a 256B header region
>>>>> that XDP programs can grow into. This is only enabled when a XDP
>>>>> program is loaded.
>>>>>
>>>>> In order to ensure that we do not have to unwind queue headroom push
>>>>> queue setup below bpf_prog_add. It reads better to do a prog ref
>>>>> unwind vs another queue setup call.
>>>>>
>>>>> At the moment this code must do a full reset to ensure old buffers
>>>>> without headroom on program add or with headroom on program removal
>>>>> are not used incorrectly in the datapath. Ideally we would only
>>>>> have to disable/enable the RX queues being updated but there is no
>>>>> API to do this at the moment in virtio so use the big hammer. In
>>>>> practice it is likely not that big of a problem as this will only
>>>>> happen when XDP is enabled/disabled changing programs does not
>>>>> require the reset. There is some risk that the driver may either
>>>>> have an allocation failure or for some reason fail to correctly
>>>>> negotiate with the underlying backend in this case the driver will
>>>>> be left uninitialized. I have not seen this ever happen on my test
>>>>> systems and for what its worth this same failure case can occur
>>>>> from probe and other contexts in virtio framework.
>>>>>
>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>> I've been thinking about it - can't we drop
>>>> old buffers without the head room which were posted before
>>>> xdp attached?
>>>>
>>>> Avoiding the reset would be much nicer.
>>>>
>>>> Thoughts?
>>>>
>>> As been discussed before, device may use them in the same time so it's not
>>> safe. Or do you mean detect them after xdp were set and drop the buffer
>>> without head room, this looks sub-optimal.
>>>
>>> Thanks
>> Yes, this is what I mean. Why is this suboptimal? It's a single branch
>> in code. Yes we might lose some packets but the big hammer of device
>> reset will likely lose more.
>>
>
> Maybe I was wrong but I think driver should try their best to avoid dropping
> packets. (And look at mlx4, it did something similar to this patch).
>
> Thanks
+1 sorry didn't see your reply as I was typing mine. Bottom line when XDP
returns I believe the driver must be ready to accept packets or managing
XDP will be problematic.
.John
^ permalink raw reply
* Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff
From: YueHaibing @ 2017-01-20 3:39 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Eric Dumazet, netdev, linux-sctp
In-Reply-To: <alpine.LFD.2.11.1612192203480.3105@ja.home.ssi.bg>
On 2016/12/20 4:37, Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 19 Dec 2016, Eric Dumazet wrote:
>
>> I am still digesting this awesome patch series ;)
>
> Thanks. I don't feel quite comfortable with some
> of the changes (mostly XFRM, dst_confirm usage in CXGB) and
> I hope the discussion can provide adequate solution.
>
>> Not sure why you used an unlikely() here. TCP for example would hit this
>> path quite often.
>
> I was not sure, may be because ACKs can come with lower
> rate than the sent packets. Also because non-TCP rarely uses
> MSG_CONFIRM. If you still think it is better without unlikely,
> I'll remove it.
>
>> So considering sk_dst_pending_confirm might be dirtied quite often,further
>>
>> I am not sure why you placed it in the cache line that contains
>> sk_rx_dst (in 1st patch)
>
> I saw your recent changes and was worried if the
> sk_dst_confirm() calling on RX can cause unwanted dirtying of
> additional cache line. My preliminary analyze pointed
> sk_omem_alloc as good candidate for moving to next cache
> line. I know how critical is to properly place the new flags,
> so I really need recommendations about this.
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
> .
>
Sorry for so late reply.
I have test your new patch, It works well in my scene.
Everybody,Is there any further comment about this awesome patch series?
^ permalink raw reply
* Re: Setting skb->csum in shared skb with csum-complete
From: Tom Herbert @ 2017-01-20 3:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Herbert Xu, Linux Kernel Network Developers
In-Reply-To: <1484877634.16328.71.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Jan 19, 2017 at 6:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2017-01-19 at 17:29 -0800, Tom Herbert wrote:
>> Hi Herbert,
>>
>> I am looking at "net: Fix skb csum races when peeking". The context is
>> that I'm seeing checksum faults after backporting mlx5 from driver.
>> The handling of the checksum faults in interesting in itself. One side
>> effect is that we end up recalculating and doing the dump twice when
>> GRO is enabled. Another is that we validate checksum complete in a
>> shared skbuf with a knowingly bad skb->csum value.
>>
>> In the checksum fault case we recalculate the checksum and find it was
>> actually correct in the packet. If the skb is not shared then we set
>> the skb->csum to the correct value and also set skb->csum_complete_sw
>> and skb->csum_valid. But if skb is shared we don't do any of that.
>> This is kind of odd since __skb_checksum_complete_head then returns
>> zero for an skb with checksum_complete where the checksum complete
>> value is not correct. I'm not sure what the consequences of doing that
>> are (I don't think it's related to issues I'm seeing) but this doesn't
>> seem like a good thing. Maybe we should set skb->csum in this case
>> since we know it's already wrong and the fact that skbuf is shared
>> can't make it more wrong...
>
> Why GRO can not change skb fields ?
>
Sure, I just noted this fact. We don't typically expect the device to
be giving us miscomputed checksum complete values ;-)
> skb can not be shared at GRO layer, so really this should be done there
> if you want to avoid a double checksumming later.
>
> You added all these skb fields, you know better than us ;)
>
>
>
^ permalink raw reply
* Re: Potential issues (security and otherwise) with the current cgroup-bpf API
From: Andy Lutomirski @ 2017-01-20 4:04 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Tejun Heo, Michal Hocko, Peter Zijlstra, David Ahern,
Andy Lutomirski, Daniel Mack, Mickaël Salaün, Kees Cook,
Jann Horn, David S. Miller, Thomas Graf, Michael Kerrisk,
Linux API, linux-kernel@vger.kernel.org, Network Development
In-Reply-To: <20170120023907.GA3294@ast-mbp.thefacebook.com>
On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote:
>> I think it could work by making a single socket cgroup controller that
>> handles all cgroup things that are bound to a socket. Using
>
> Such 'socket cgroup controller' would limit usability of the feature
> to sockets and force all other use cases like landlock to invent
> their own wheel, which is undesirable. Everyone will be
> inventing new 'foo cgroup controller', while all of them
> are really bpf features. They are different bpf program
> types that attach to different hooks and use cgroup for scoping.
Can you elaborate on why that would be a problem? In a cgroup v1
world, users who want different hierarchies for different types of
control could easily want one hierarchy for socket hooks and a
different hierarchy for lsm hooks. In a cgroup v2 delegation world, I
could easily imagine the decision to delegate socket hooks being
different from the decision to delegate lsm hooks. Almost all of the
code would be shared between different bpf-using cgroup controllers.
>
>> Having thought about this some more, I think that making it would
>> alleviate a bunch of my concerns, as it would make the semantics if
>> the capable() check were relaxed to ns_capable() be sane. Here's what
>
> here we're on the same page. For any meaningful discussion about
> 'bpf cgroup controller' to happen bpf itself needs to become
> delegatable in cgroup sense. In other words BPF_PROG_TYPE_CGROUP*
> program types need to become available for unprivileged users.
> The only unprivileged prog type today is BPF_PROG_TYPE_SOCKET_FILTER.
> To make it secure we severely limited its functionality.
> All bpf advances since then (like new map types and verifier extensions)
> were done for root only. If early on the priv vs unpriv bpf features
> were 80/20. Now it's close to 95/5. No work has been done to
> make socket filter type more powerful. It still has to use
> slow-ish ld_abs skb access while tc/xdp have direct packet access.
> Things like register value tracking is root only as well and so on
> and so forth.
> We cannot just flip the switch and allow type_cgroup* to unpriv
> and I don't see any volunteers willing to do this work.
> Until that happens there is no point coming up with designs
> for 'cgroup bpf controller'... whatever that means.
Sure there is. If delegation can be turned on without changing the
API, then the result will be easier to work with and have fewer
compatibility issues.
>
>> I currently should happen before bpf+cgroup is enabled in a release:
>>
>> 1. Make it netns-aware. This could be as simple as making it only
>> work in the root netns because then real netns awareness can be added
>> later without breaking anything. The current situation is bad in that
>> network namespaces are just ignored and it's plausible that people
>> will start writing user code that depends on having network namespaces
>> be ignored.
>
> nothing in bpf today is netns-aware and frankly I don't see
> how cgroup+bpf has anything to do with netns.
> For regular sockets+bpf we don't check netns.
> When tcpdump opens raw socket and attaches bpf there are no netns
> checks, since socket itself gives a scope for the program to run.
> Same thing applies to cgroup+bpf. cgroup gives a scope for the program.
> But, say, we indeed add 'if !root ns' check to BPF_CGROUP_INET_*
> hooks.
Here I completely disagree with you. tcpdump sees packets in its
network namespace. Regular sockets apply bpf filters to the packets
seen by that socket, and the socket itself is scoped to a netns.
Meanwhile, cgroup+bpf actually appears to be buggy in this regard even
regardless of what semantics you think are better. sk_bound_dev_if is
exposed as a u32 value, but sk_bound_dev_if only has meaning within a
given netns. The "ip vrf" stuff will straight-up malfunction if a
process affected by its hook runs in a different netns from the netns
that "ip vrf" was run in.
IOW, the current code is buggy.
> Then if the hooks are used for security, the process
> only needs to do setns() to escape security sandbox. Obviously
> broken semantics.
This could go both ways. If the goal is to filter packets, then it's
not really important to have the filter keep working if the sandboxed
task unshares netns -- in the new netns, there isn't any access to the
network at all. If the goal is to reduce attack surface by
restricting the types of sockets that can be created, then you do want
the filter to work across namespaces, but seccomp can do that too and
the current code doesn't handle netns correctly.
>
>> 2. Make it inherit properly. Inner cgroups should not override outer
>> hooks. As in (1), this could be simplified by preventing the same
>> hook from being configured in both an ancestor and a descendent
>> cgroup. Then inheritance could be added for real later on.
>
> In general it sounds fine, but it seems the reasoning to add
> such restriction now (instead of later), so that program chain can
> be added without breaking abi, since if we don't restrict it now
> there will be no way to add it without breaking abi?!
Adding it the straightforward way (by simply making all the hooks in
scope run) would break ABI. Of course there are more complicated ways
to do it, but those are more complicated and messier. Do actually
have a use case in which overriding of hooks is a good thing? As far
as I can tell, the original version of the patch set didn't have hooks
get overridden by descendents, and I don't know why this changed in
the first place.
>
> Also until bpf_type_cgroup* becomes unprivileged there is no reason
> to add this 'priority/prog chaining' feature, since if it's
> used for security the root can always override it no matter cgroup
> hierarchy.
>
>> 3. Give cgroup delegation support some serious thought. In
>> particular, if delegation would be straightforward but the current API
>> wouldn't work well with delegation, then at least consider whether the
>> API should change before it becomes stable so that two APIs don't need
>> to be supported going forward.
>
> please see example above. Since we went with bpf syscall (instead of
> inextensible ioctl) we can add any new cgroup+bpf logic without
> breaking current abi.
But then you end up with two ABIs. Ideally delegation would just work
-- then programs written now could run unmodified in unprivileged
containers in future kernels.
--Andy
^ permalink raw reply
* Re: [PATCH] Revert "net: qcom/emac: configure the external phy to allow pause frames"
From: David Miller @ 2017-01-20 4:15 UTC (permalink / raw)
To: timur; +Cc: netdev, alokc
In-Reply-To: <1484692279-18289-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Tue, 17 Jan 2017 16:31:19 -0600
> This reverts commit 3e884493448131179a5b7cae1ddca1028ffaecc8.
>
> With commit 529ed1275263 ("net: phy: phy drivers should not set
> SUPPORTED_[Asym_]Pause"), phylib now handles automatically enabling
> pause frame support in the PHY, and the MAC driver should follow suit.
>
> Since the EMAC driver driver does this, we no longer need to force
> pause frames support.
>
> Signed-off-by: Timur Tabi <timur@codeaurora.org>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: support __GFP_MEMALLOC for rx
From: David Miller @ 2017-01-20 4:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, khlebnikov, tariqt
In-Reply-To: <1484712850.13165.86.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 17 Jan 2017 20:14:10 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Commit 04aeb56a1732 ("net/mlx4_en: allocate non 0-order pages for RX
> ring with __GFP_NOMEMALLOC") added code that appears to be not needed at
> that time, since mlx4 never used __GFP_MEMALLOC allocations anyway.
>
> As using memory reserves is a must in some situations (swap over NFS or
> iSCSI), this patch adds this flag.
>
> Note that this driver does not reuse pages (yet) so we do not have to
> add anything else.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Keep nexthop of multipath route on admin down
From: David Miller @ 2017-01-20 4:40 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1484754036-26807-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Wed, 18 Jan 2017 07:40:36 -0800
> IPv6 deletes route entries associated with multipath routes on an
> admin down where IPv4 does not. For example:
...
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Seems reasonable, applied, thanks David.
^ permalink raw reply
* Re: fs, net: deadlock between bind/splice on af_unix
From: Cong Wang @ 2017-01-20 4:57 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Al Viro, linux-fsdevel@vger.kernel.org, LKML, David Miller,
Rainer Weikusat, Hannes Frederic Sowa, netdev, Eric Dumazet,
syzkaller
In-Reply-To: <CACT4Y+Y_3i=PThhVzHXYnCQm_xN72VQ0eN9Ae4uXyORq_a_Z6w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]
On Wed, Jan 18, 2017 at 1:17 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Jan 17, 2017 at 10:21 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>>> On Fri, Dec 9, 2016 at 7:41 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>>>> On Thu, Dec 08, 2016 at 10:32:00PM -0800, Cong Wang wrote:
>>>>
>>>>> > Why do we do autobind there, anyway, and why is it conditional on
>>>>> > SOCK_PASSCRED? Note that e.g. for SOCK_STREAM we can bloody well get
>>>>> > to sending stuff without autobind ever done - just use socketpair()
>>>>> > to create that sucker and we won't be going through the connect()
>>>>> > at all.
>>>>>
>>>>> In the case Dmitry reported, unix_dgram_sendmsg() calls unix_autobind(),
>>>>> not SOCK_STREAM.
>>>>
>>>> Yes, I've noticed. What I'm asking is what in there needs autobind triggered
>>>> on sendmsg and why doesn't the same need affect the SOCK_STREAM case?
>>>>
>>>>> I guess some lock, perhaps the u->bindlock could be dropped before
>>>>> acquiring the next one (sb_writer), but I need to double check.
>>>>
>>>> Bad idea, IMO - do you *want* autobind being able to come through while
>>>> bind(2) is busy with mknod?
>>>
>>>
>>> Ping. This is still happening on HEAD.
>>>
>>
>> Thanks for your reminder. Mind to give the attached patch (compile only)
>> a try? I take another approach to fix this deadlock, which moves the
>> unix_mknod() out of unix->bindlock. Not sure if there is any unexpected
>> impact with this way.
>
>
> I instantly hit:
>
Oh, sorry about it, I forgot to initialize struct path...
Attached is the updated version, I just did a boot test, no crash at least. ;)
Thanks!
[-- Attachment #2: unix.diff --]
[-- Type: text/plain, Size: 1695 bytes --]
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 127656e..cef7987 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -995,6 +995,7 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
unsigned int hash;
struct unix_address *addr;
struct hlist_head *list;
+ struct path path = { NULL, NULL };
err = -EINVAL;
if (sunaddr->sun_family != AF_UNIX)
@@ -1010,9 +1011,20 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
goto out;
addr_len = err;
+ if (sun_path[0]) {
+ umode_t mode = S_IFSOCK |
+ (SOCK_INODE(sock)->i_mode & ~current_umask());
+ err = unix_mknod(sun_path, mode, &path);
+ if (err) {
+ if (err == -EEXIST)
+ err = -EADDRINUSE;
+ goto out;
+ }
+ }
+
err = mutex_lock_interruptible(&u->bindlock);
if (err)
- goto out;
+ goto out_put;
err = -EINVAL;
if (u->addr)
@@ -1029,16 +1041,6 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
atomic_set(&addr->refcnt, 1);
if (sun_path[0]) {
- struct path path;
- umode_t mode = S_IFSOCK |
- (SOCK_INODE(sock)->i_mode & ~current_umask());
- err = unix_mknod(sun_path, mode, &path);
- if (err) {
- if (err == -EEXIST)
- err = -EADDRINUSE;
- unix_release_addr(addr);
- goto out_up;
- }
addr->hash = UNIX_HASH_SIZE;
hash = d_backing_inode(path.dentry)->i_ino & (UNIX_HASH_SIZE - 1);
spin_lock(&unix_table_lock);
@@ -1065,6 +1067,9 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
spin_unlock(&unix_table_lock);
out_up:
mutex_unlock(&u->bindlock);
+out_put:
+ if (err)
+ path_put(&path);
out:
return err;
}
^ permalink raw reply related
* [PATCH net] r8152: fix the rx doesn't work
From: Hayes Wang @ 2017-01-20 6:07 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
The rtl8152_post_reset() doesn't submit the rx urb, so the rx wouldn't work.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..e8f4f88 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3545,6 +3545,7 @@ static int rtl8152_post_reset(struct usb_interface *intf)
if (netif_carrier_ok(netdev)) {
mutex_lock(&tp->control);
tp->rtl_ops.enable(tp);
+ rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(&tp->control);
netif_wake_queue(netdev);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 0/2] net: ipv6: Improve user experience with multipath routes
From: David Ahern @ 2017-01-20 6:10 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
This series closes a couple of gaps between IPv4 and IPv6 with respect
to multipath routes:
1. IPv4 allows all nexthops of multipath routes to be deleted using just
the prefix and length; IPv6 only deletes the first nexthop for the
route if only the prefix and length are given.
2. IPv4 returns multipath routes encoded in the RTA_MULTIPATH attribute.
IPv6 returns a series of routes with the same prefix and length - one
for each nexthop. This happens for both dumps and notifications.
IPv6 does accept RTA_MULTIPATH encoded routes, but installs them as a
series of routes.
Patch 1 addresses the first by allowing IPv6 multipath routes to be
deleted using just the prefix and length. Patch 2 addresses the second
allowing IPv6 multipath routes to be returned encoded in the RTA_MULTIPATH.
In both cases, the new behavior requires users to opt in by setting a new
flag, RTM_F_ALL_NEXTHOPS, in the rtm_flags of struct rtmsg which is
expected to be the ancillary header in the netlink request received from
the user. A program must opt in to the new behavior so as to not break
any existing applications.
The opt-in behavior works for both route deletes and dumps (the two
differences noted above), but not for notifications as notifications
do not take user input to specify flags. The only way to have
notifications generate RTA_MULTIPATH encodings is to have a gobal
flag -- e.g., sysctl. I'd prefer not to add a sysctl knob for this
backwards compatibility.
Notifications can always be handled as a follow on patch since any
existing code that actually works with IPv6 multipath routes (e.g.,
quagga does not) has to be able to handle the series of routes
currently returned by the dump request and notifications.
v2
- fixed locking in patch 1 as noted by DaveM
- changed user API for patch 2 to require an rtmsg with RTM_F_ALL_NEXTHOPS
set in rtm_flags
- revamped explanation of patch 2 and cover letter
David Ahern (2):
net: ipv6: Allow shorthand delete of all nexthops in multipath route
net: ipv6: Add option to dump multipath routes via RTA_MULTIPATH
attribute
include/net/ip6_fib.h | 4 +-
include/net/ip6_route.h | 1 +
include/uapi/linux/rtnetlink.h | 4 ++
net/ipv6/ip6_fib.c | 28 ++++++++-
net/ipv6/route.c | 138 ++++++++++++++++++++++++++++++++++-------
5 files changed, 152 insertions(+), 23 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH net-next v2 1/2] net: ipv6: Allow shorthand delete of all nexthops in multipath route
From: David Ahern @ 2017-01-20 6:10 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
In-Reply-To: <1484892626-14257-1-git-send-email-dsa@cumulusnetworks.com>
IPv4 allows multipath routes to be deleted using just the prefix and
length. For example:
$ ip ro ls vrf red
unreachable default metric 8192
1.1.1.0/24
nexthop via 10.100.1.254 dev eth1 weight 1
nexthop via 10.11.200.2 dev eth11.200 weight 1
10.11.200.0/24 dev eth11.200 proto kernel scope link src 10.11.200.3
10.100.1.0/24 dev eth1 proto kernel scope link src 10.100.1.3
$ ip ro del 1.1.1.0/24 vrf red
$ ip ro ls vrf red
unreachable default metric 8192
10.11.200.0/24 dev eth11.200 proto kernel scope link src 10.11.200.3
10.100.1.0/24 dev eth1 proto kernel scope link src 10.100.1.3
The same notation does not work with IPv6 because of how multipath routes
are implemented for IPv6. For IPv6 only the first nexthop of a multipath
route is deleted if the request contains only a prefix and length. This
leads to unnecessary complexity in userspace dealing with IPv6 multipath
routes.
This patch allows all nexthops to be deleted without specifying each one
in the delete request by passing a new flag, RTM_F_ALL_NEXTHOPS, in
rtm_flags. Internally, this is done by walking the sibling list of the
route matching the specifications given (prefix, length, metric, protocol,
etc).
With this patch (and an updated iproute2 command):
$ ip -6 ro ls vrf red
2001:db8::/120 via 2001:db8:1::62 dev eth1 metric 256 pref medium
2001:db8::/120 via 2001:db8:1::61 dev eth1 metric 256 pref medium
2001:db8::/120 via 2001:db8:1::60 dev eth1 metric 256 pref medium
2001:db8:1::/120 dev eth1 proto kernel metric 256 pref medium
...
$ ip -6 ro del vrf red 1111::1/120
$ ip -6 ro ls vrf red
2001:db8:1::/120 dev eth1 proto kernel metric 256 pref medium
...
The flag is added to fib6_config by converting fc_type to a u16 (as
noted fc_type only uses 8 bits). The new u16 hole is a bitmap with
fc_delete_all_nexthop as the first bit.
v2
- fixed locking deleting route and its siblings as noted by DaveM
v2' (patch originally submitted standalone)
- switched examples to rfc 3849 documentation address per request
- changed delete loop to explicitly look at siblings list for
first route matching specs given (metric, protocol, etc)
Suggested-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
include/net/ip6_fib.h | 4 +++-
include/uapi/linux/rtnetlink.h | 1 +
net/ipv6/route.c | 32 +++++++++++++++++++++++++++++++-
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index a74e2aa40ef4..11ab99e87c5f 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -37,7 +37,9 @@ struct fib6_config {
int fc_ifindex;
u32 fc_flags;
u32 fc_protocol;
- u32 fc_type; /* only 8 bits are used */
+ u16 fc_type; /* only 8 bits are used */
+ u16 fc_delete_all_nexthop : 1,
+ __unused : 15;
struct in6_addr fc_dst;
struct in6_addr fc_src;
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 8c93ad1ef9ab..7fb206bc42f9 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -276,6 +276,7 @@ enum rt_scope_t {
#define RTM_F_EQUALIZE 0x400 /* Multipath equalizer: NI */
#define RTM_F_PREFIX 0x800 /* Prefix addresses */
#define RTM_F_LOOKUP_TABLE 0x1000 /* set rtm_table to FIB lookup result */
+#define RTM_F_ALL_NEXTHOPS 0x2000 /* delete all nexthops (IPv6) */
/* Reserved table identifiers */
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 5585c501a540..f207d4d0a782 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2143,6 +2143,33 @@ int ip6_del_rt(struct rt6_info *rt)
return __ip6_del_rt(rt, &info);
}
+static int __ip6_del_rt_siblings(struct rt6_info *rt, struct fib6_config *cfg)
+{
+ struct fib6_table *table;
+ int err;
+
+ table = rt->rt6i_table;
+ write_lock_bh(&table->tb6_lock);
+
+ if (rt->rt6i_nsiblings && cfg->fc_delete_all_nexthop) {
+ struct rt6_info *sibling, *next_sibling;
+
+ list_for_each_entry_safe(sibling, next_sibling,
+ &rt->rt6i_siblings,
+ rt6i_siblings) {
+ err = fib6_del(sibling, &cfg->fc_nlinfo);
+ if (err)
+ goto out;
+ }
+ }
+
+ err = fib6_del(rt, &cfg->fc_nlinfo);
+out:
+ write_unlock_bh(&table->tb6_lock);
+ ip6_rt_put(rt);
+ return err;
+}
+
static int ip6_route_del(struct fib6_config *cfg)
{
struct fib6_table *table;
@@ -2179,7 +2206,7 @@ static int ip6_route_del(struct fib6_config *cfg)
dst_hold(&rt->dst);
read_unlock_bh(&table->tb6_lock);
- return __ip6_del_rt(rt, &cfg->fc_nlinfo);
+ return __ip6_del_rt_siblings(rt, cfg);
}
}
read_unlock_bh(&table->tb6_lock);
@@ -2849,6 +2876,9 @@ static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
if (rtm->rtm_flags & RTM_F_CLONED)
cfg->fc_flags |= RTF_CACHE;
+ if (rtm->rtm_flags & RTM_F_ALL_NEXTHOPS)
+ cfg->fc_delete_all_nexthop = 1;
+
cfg->fc_nlinfo.portid = NETLINK_CB(skb).portid;
cfg->fc_nlinfo.nlh = nlh;
cfg->fc_nlinfo.nl_net = sock_net(skb->sk);
--
2.1.4
^ permalink raw reply related
* [PATCH net-next v2 2/2] net: ipv6: Add option to dump multipath routes via RTA_MULTIPATH attribute
From: David Ahern @ 2017-01-20 6:10 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
In-Reply-To: <1484892626-14257-1-git-send-email-dsa@cumulusnetworks.com>
IPv6 returns multipath routes as a series of individual routes making
their display and handling by userspace different and more complicated
than IPv4, putting the burden on the user to see that a route is part of
a multipath route and internally creating a multipath route if desired
(e.g., libnl does this as of commit 29b71371e764). This patch addresses
this difference, allowing users to request multipath routes to be
returned using the RTA_MULTIPATH attribute in dump requests.
To maintain backwards compatibility, a user has to opt in to the change
in behavior. Currently, the ancillary header in the netlink request
message is supposed to be an rtmsg, but it could be just an rtgenmsg
since only the family is actually referenced in the code to this point.
But, ip for example sends an ifinfomsg (plus a filter in newer versions)
which is completely wrong, but an established code base at this point.
This patch requires a struct rtmsg for the ancillary header, something it
is able to uniquely detect given the different struct sizes. Within rtmsg,
rtm_flags must have the new (from patch 1) RTM_F_ALL_NEXTHOPS flag set.
The end result is that IPv6 multipath routes can be treated and displayed
in a format similar to IPv4:
$ ip -6 ro ls vrf red
2001:db8::/120 metric 1024
nexthop via 2001:db8:1::62 dev eth1 weight 1
nexthop via 2001:db8:1::61 dev eth1 weight 1
nexthop via 2001:db8:1::60 dev eth1 weight 1
nexthop via 2001:db8:1::59 dev eth1 weight 1
2001:db8:1::/120 dev eth1 proto kernel metric 256 pref medium
...
v2
- changed user api to opt in to new behavior from attribute appended to
the request to requiring an rtmsg struct with the RTM_F_ALL_NEXTHOPS
set
Suggested-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
include/net/ip6_route.h | 1 +
include/uapi/linux/rtnetlink.h | 5 +-
net/ipv6/ip6_fib.c | 28 ++++++++++-
net/ipv6/route.c | 106 +++++++++++++++++++++++++++++++++--------
4 files changed, 118 insertions(+), 22 deletions(-)
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 9dc2c182a263..7620974826a5 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -154,6 +154,7 @@ struct rt6_rtnl_dump_arg {
struct sk_buff *skb;
struct netlink_callback *cb;
struct net *net;
+ unsigned int rtm_flags;
};
int rt6_dump_route(struct rt6_info *rt, void *p_arg);
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 7fb206bc42f9..5a070f24f111 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -276,7 +276,10 @@ enum rt_scope_t {
#define RTM_F_EQUALIZE 0x400 /* Multipath equalizer: NI */
#define RTM_F_PREFIX 0x800 /* Prefix addresses */
#define RTM_F_LOOKUP_TABLE 0x1000 /* set rtm_table to FIB lookup result */
-#define RTM_F_ALL_NEXTHOPS 0x2000 /* delete all nexthops (IPv6) */
+#define RTM_F_ALL_NEXTHOPS 0x2000 /* IPv6 flag:
+ * delete: remove all nexthops
+ * dump: nexthops can use RTA_MULTIPATH
+ */
/* Reserved table identifiers */
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index ef5485204522..ef2bf33e34e8 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -308,16 +308,27 @@ static void __net_init fib6_tables_init(struct net *net)
static int fib6_dump_node(struct fib6_walker *w)
{
+ struct rt6_rtnl_dump_arg *arg = (struct rt6_rtnl_dump_arg *)w->args;
int res;
struct rt6_info *rt;
for (rt = w->leaf; rt; rt = rt->dst.rt6_next) {
- res = rt6_dump_route(rt, w->args);
+ res = rt6_dump_route(rt, arg);
if (res < 0) {
/* Frame is full, suspend walking */
w->leaf = rt;
return 1;
}
+
+ /* if multipath routes are dumped in one route with
+ * the RTA_MULTIPATH attribute, then jump rt to point
+ * to the last sibling of this route (no need to dump
+ * the sibling routes again)
+ */
+ if ((arg->rtm_flags & RTM_F_ALL_NEXTHOPS) && rt->rt6i_nsiblings)
+ rt = list_last_entry(&rt->rt6i_siblings,
+ struct rt6_info,
+ rt6i_siblings);
}
w->leaf = NULL;
return 0;
@@ -398,6 +409,7 @@ static int inet6_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
struct fib6_walker *w;
struct fib6_table *tb;
struct hlist_head *head;
+ unsigned int flags = 0;
int res = 0;
s_h = cb->args[0];
@@ -422,9 +434,23 @@ static int inet6_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
cb->args[2] = (long)w;
}
+ /* sadly, the size of the ancillary header can vary: the correct
+ * header is struct rtmsg as passed by libnl. iproute2 sends
+ * ifinfomsg [+ filter]. Technically, passing only rtgenmsg is
+ * sufficient since the header has not been parsed before. Luckily,
+ * the struct sizes sufficiently vary to detect the permutations.
+ * For the dump request to contain flags, require rtmsg header.
+ */
+ if (nlmsg_len(cb->nlh) == sizeof(struct rtmsg)) {
+ struct rtmsg *rtm = nlmsg_data(cb->nlh);
+
+ flags = rtm->rtm_flags;
+ }
+
arg.skb = skb;
arg.cb = cb;
arg.net = net;
+ arg.rtm_flags = flags;
w->args = &arg;
rcu_read_lock();
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f207d4d0a782..ee57adf1a765 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3195,11 +3195,65 @@ static inline size_t rt6_nlmsg_size(struct rt6_info *rt)
+ lwtunnel_get_encap_size(rt->dst.lwtstate);
}
+static int rt6_nexthop_info(struct sk_buff *skb, struct rt6_info *rt,
+ unsigned int *flags)
+{
+ if (!netif_carrier_ok(rt->dst.dev)) {
+ *flags |= RTNH_F_LINKDOWN;
+ if (rt->rt6i_idev->cnf.ignore_routes_with_linkdown)
+ *flags |= RTNH_F_DEAD;
+ }
+
+ if (rt->rt6i_flags & RTF_GATEWAY) {
+ if (nla_put_in6_addr(skb, RTA_GATEWAY, &rt->rt6i_gateway) < 0)
+ goto nla_put_failure;
+ }
+
+ if (rt->dst.dev &&
+ nla_put_u32(skb, RTA_OIF, rt->dst.dev->ifindex))
+ goto nla_put_failure;
+
+ if (rt->dst.lwtstate &&
+ lwtunnel_fill_encap(skb, rt->dst.lwtstate) < 0)
+ goto nla_put_failure;
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static int rt6_add_nexthop(struct sk_buff *skb, struct rt6_info *rt)
+{
+ struct rtnexthop *rtnh;
+ unsigned int flags = 0;
+
+ rtnh = nla_reserve_nohdr(skb, sizeof(*rtnh));
+ if (!rtnh)
+ goto nla_put_failure;
+
+ rtnh->rtnh_hops = 0;
+ rtnh->rtnh_ifindex = rt->dst.dev ? rt->dst.dev->ifindex : 0;
+
+ if (rt6_nexthop_info(skb, rt, &flags) < 0)
+ goto nla_put_failure;
+
+ rtnh->rtnh_flags = flags;
+
+ /* length of rtnetlink header + attributes */
+ rtnh->rtnh_len = nlmsg_get_pos(skb) - (void *)rtnh;
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
static int rt6_fill_node(struct net *net,
struct sk_buff *skb, struct rt6_info *rt,
struct in6_addr *dst, struct in6_addr *src,
int iif, int type, u32 portid, u32 seq,
- unsigned int flags)
+ unsigned int nlm_flags, unsigned int rtm_flags)
{
u32 metrics[RTAX_MAX];
struct rtmsg *rtm;
@@ -3207,7 +3261,7 @@ static int rt6_fill_node(struct net *net,
long expires;
u32 table;
- nlh = nlmsg_put(skb, portid, seq, type, sizeof(*rtm), flags);
+ nlh = nlmsg_put(skb, portid, seq, type, sizeof(*rtm), nlm_flags);
if (!nlh)
return -EMSGSIZE;
@@ -3246,11 +3300,6 @@ static int rt6_fill_node(struct net *net,
else
rtm->rtm_type = RTN_UNICAST;
rtm->rtm_flags = 0;
- if (!netif_carrier_ok(rt->dst.dev)) {
- rtm->rtm_flags |= RTNH_F_LINKDOWN;
- if (rt->rt6i_idev->cnf.ignore_routes_with_linkdown)
- rtm->rtm_flags |= RTNH_F_DEAD;
- }
rtm->rtm_scope = RT_SCOPE_UNIVERSE;
rtm->rtm_protocol = rt->rt6i_protocol;
if (rt->rt6i_flags & RTF_DYNAMIC)
@@ -3314,17 +3363,36 @@ static int rt6_fill_node(struct net *net,
if (rtnetlink_put_metrics(skb, metrics) < 0)
goto nla_put_failure;
- if (rt->rt6i_flags & RTF_GATEWAY) {
- if (nla_put_in6_addr(skb, RTA_GATEWAY, &rt->rt6i_gateway) < 0)
- goto nla_put_failure;
- }
-
- if (rt->dst.dev &&
- nla_put_u32(skb, RTA_OIF, rt->dst.dev->ifindex))
- goto nla_put_failure;
if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
goto nla_put_failure;
+ /* if user wants nexthops included via the RTA_MULTIPATH
+ * attribute, then walk the siblings list and add each
+ * as a nexthop
+ */
+ if ((rtm_flags & RTM_F_ALL_NEXTHOPS) && rt->rt6i_nsiblings) {
+ struct rt6_info *sibling, *next_sibling;
+ struct nlattr *mp;
+
+ mp = nla_nest_start(skb, RTA_MULTIPATH);
+ if (!mp)
+ goto nla_put_failure;
+
+ if (rt6_add_nexthop(skb, rt) < 0)
+ goto nla_put_failure;
+
+ list_for_each_entry_safe(sibling, next_sibling,
+ &rt->rt6i_siblings, rt6i_siblings) {
+ if (rt6_add_nexthop(skb, sibling) < 0)
+ goto nla_put_failure;
+ }
+
+ nla_nest_end(skb, mp);
+ } else {
+ if (rt6_nexthop_info(skb, rt, &rtm->rtm_flags) < 0)
+ goto nla_put_failure;
+ }
+
expires = (rt->rt6i_flags & RTF_EXPIRES) ? rt->dst.expires - jiffies : 0;
if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
@@ -3333,8 +3401,6 @@ static int rt6_fill_node(struct net *net,
if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(rt->rt6i_flags)))
goto nla_put_failure;
- if (lwtunnel_fill_encap(skb, rt->dst.lwtstate) < 0)
- goto nla_put_failure;
nlmsg_end(skb, nlh);
return 0;
@@ -3362,7 +3428,7 @@ int rt6_dump_route(struct rt6_info *rt, void *p_arg)
return rt6_fill_node(arg->net,
arg->skb, rt, NULL, NULL, 0, RTM_NEWROUTE,
NETLINK_CB(arg->cb->skb).portid, arg->cb->nlh->nlmsg_seq,
- NLM_F_MULTI);
+ NLM_F_MULTI, arg->rtm_flags);
}
static int inet6_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh)
@@ -3453,7 +3519,7 @@ static int inet6_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh)
err = rt6_fill_node(net, skb, rt, &fl6.daddr, &fl6.saddr, iif,
RTM_NEWROUTE, NETLINK_CB(in_skb).portid,
- nlh->nlmsg_seq, 0);
+ nlh->nlmsg_seq, 0, 0);
if (err < 0) {
kfree_skb(skb);
goto errout;
@@ -3480,7 +3546,7 @@ void inet6_rt_notify(int event, struct rt6_info *rt, struct nl_info *info,
goto errout;
err = rt6_fill_node(net, skb, rt, NULL, NULL, 0,
- event, info->portid, seq, nlm_flags);
+ event, info->portid, seq, nlm_flags, 0);
if (err < 0) {
/* -EMSGSIZE implies BUG in rt6_nlmsg_size() */
WARN_ON(err == -EMSGSIZE);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net 1/1] net sched actions: fix refcnt when GETing of action after bind
From: Cong Wang @ 2017-01-20 6:20 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David Miller, Linux Kernel Network Developers
In-Reply-To: <7a55a129-1e96-80f7-373d-1ff6a95b5269@mojatatu.com>
On Wed, Jan 18, 2017 at 3:33 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 17-01-17 01:17 PM, Cong Wang wrote:
>>
>> Why this check for RTM_GETACTION? It does not make sense
>> at least for the error case, that is, when tcf_action_get_1() fails
>> in the middle of the loop, all the previous ones should be destroyed
>> no matter it's GETACTION or DELACTION...
>>
>> Also, for the non-error case of GETACTION, they should be
>> destroyed too after dumping to user-space, otherwise there is no
>> way to use them since 'actions' is local to that function.
>>
>> I thought in commit aecc5cefc389 you grab that refcnt on purpose.
>>
>
> I did.
> The issue there (after your original patch) was destroy() would
> decrement the refcount to zero and a GET was essentially translated
> to a DEL. Incrementing the refcount earlier protected against that
> assuming destroy was going to decrement it.
> However, when an action is bound the destroy() doesnt decrement
> the refcnt. So the refcnt keeps going up forever (and therefore
> deleting fails in the future). So we cant use destroy() as is.
Hmm, tcf_action_destroy() should not touch the refcnt at all in this case,
right? Since the refcnt here is not for readers in kernel code but for
user-space. We mix the use of this refcnt, which leads to problems.
Your patch is not correct either for DEL, tcf_action_destroy() is not
needed to call again after tcf_del_notify() fails, right? Probably
it is not needed at all:
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index e10456ef6f..82eed18 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -907,13 +907,8 @@ tca_action_gd(struct net *net, struct nlattr
*nla, struct nlmsghdr *n,
ret = act_get_notify(net, portid, n, &actions, event);
else { /* delete */
ret = tcf_del_notify(net, n, &actions, portid);
- if (ret)
- goto err;
- return ret;
}
err:
- if (event != RTM_GETACTION)
- tcf_action_destroy(&actions, 0);
return ret;
}
^ permalink raw reply related
* RE: [PATCH net] r8152: fix the rx doesn't work
From: Hayes Wang @ 2017-01-20 6:30 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <1394712342-15778-233-Taiwan-albertk@realtek.com>
> Subject: [PATCH net] r8152: fix the rx doesn't work
>
> The rtl8152_post_reset() doesn't submit the rx urb, so the rx wouldn't work.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Excuse me. Please ignore this patch. I would submit another one.
^ permalink raw reply
* [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving
From: Jason Wang @ 2017-01-20 6:32 UTC (permalink / raw)
To: netdev, linux-kernel, virtualization, mst; +Cc: Rolf Neugebauer
Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
fixing this by adding a hint (has_data_valid) and set it only on the
receiving path.
Cc: Rolf Neugebauer <rolf.neugebauer@docker.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 2 +-
drivers/net/tun.c | 2 +-
drivers/net/virtio_net.c | 2 +-
include/linux/virtio_net.h | 6 +++++-
net/packet/af_packet.c | 4 ++--
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 5c26653..4026185 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
return -EINVAL;
if (virtio_net_hdr_from_skb(skb, &vnet_hdr,
- macvtap_is_little_endian(q)))
+ macvtap_is_little_endian(q), true))
BUG();
if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index cd8e02c..2cd10b2 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
return -EINVAL;
if (virtio_net_hdr_from_skb(skb, &gso,
- tun_is_little_endian(tun))) {
+ tun_is_little_endian(tun), true)) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4a10500..3474243 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
hdr = skb_vnet_hdr(skb);
if (virtio_net_hdr_from_skb(skb, &hdr->hdr,
- virtio_is_little_endian(vi->vdev)))
+ virtio_is_little_endian(vi->vdev), false))
BUG();
if (vi->mergeable_rx_bufs)
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 5643647..5209b5e 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
struct virtio_net_hdr *hdr,
- bool little_endian)
+ bool little_endian,
+ bool has_data_valid)
{
memset(hdr, 0, sizeof(*hdr)); /* no info leak */
@@ -91,6 +92,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
skb_checksum_start_offset(skb));
hdr->csum_offset = __cpu_to_virtio16(little_endian,
skb->csum_offset);
+ } else if (has_data_valid &&
+ skb->ip_summed == CHECKSUM_UNNECESSARY) {
+ hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
return 0;
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index b9e1a13..3d555c7 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1976,7 +1976,7 @@ static int packet_rcv_vnet(struct msghdr *msg, const struct sk_buff *skb,
return -EINVAL;
*len -= sizeof(vnet_hdr);
- if (virtio_net_hdr_from_skb(skb, &vnet_hdr, vio_le()))
+ if (virtio_net_hdr_from_skb(skb, &vnet_hdr, vio_le(), true))
return -EINVAL;
return memcpy_to_msg(msg, (void *)&vnet_hdr, sizeof(vnet_hdr));
@@ -2237,7 +2237,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
if (po->has_vnet_hdr) {
if (virtio_net_hdr_from_skb(skb, h.raw + macoff -
sizeof(struct virtio_net_hdr),
- vio_le())) {
+ vio_le(), true)) {
spin_lock(&sk->sk_receive_queue.lock);
goto drop_n_account;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net] r8152: fix rtl8152_post_reset function
From: Hayes Wang @ 2017-01-20 6:33 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <1394712342-15778-233-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
The rtl8152_post_reset() should sumbit rx urb and interrupt transfer,
otherwise the rx wouldn't work and the linking change couldn't be
detected.
Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/r8152.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..0e99af0 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3545,12 +3545,14 @@ static int rtl8152_post_reset(struct usb_interface *intf)
if (netif_carrier_ok(netdev)) {
mutex_lock(&tp->control);
tp->rtl_ops.enable(tp);
+ rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(&tp->control);
netif_wake_queue(netdev);
}
napi_enable(&tp->napi);
+ usb_submit_urb(tp->intr_urb, GFP_KERNEL);
return 0;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* ipv6_get_ifaddr() not exported
From: Valentine Sinitsyn @ 2017-01-20 6:33 UTC (permalink / raw)
To: netdev
Hi all,
I'm working on a custom Netfilter module which could seemingly use
ipv6_get_ifaddr() function to find a netdev which has a destination IPv6
assigned (if any). The function is public, but not exported, so I can't
use it in my module.
Am I doing anything wrong, or I'm just a first type to use
ipv6_get_ifaddr() outside net/ipv6 code, and it's okay to export it now?
Thanks,
Valentine
^ permalink raw reply
* [PATCH net] macsec: fix validation failed in asynchronous operation.
From: Ryder Lee @ 2017-01-20 7:28 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Sabrina Dubroca, linux-mediatek, Ryder Lee
Add missing "macsec_skb_cb(skb)->valid = true" in callback
function macsec_decrypt_done(), this fixes packet validation
failed while decrypting asynchronously.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/net/macsec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index f83cf66..2a6ab5a 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -880,6 +880,7 @@ static void macsec_decrypt_done(struct crypto_async_request *base, int err)
aead_request_free(macsec_skb_cb(skb)->req);
rcu_read_lock_bh();
+ macsec_skb_cb(skb)->valid = true;
pn = ntohl(macsec_ethhdr(skb)->packet_number);
if (!macsec_post_decrypt(skb, &macsec->secy, pn)) {
rcu_read_unlock_bh();
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] net: ethernet: aquantia: fix alloc_cast.cocci warnings
From: Joe Perches @ 2017-01-20 8:19 UTC (permalink / raw)
To: kbuild test robot, Alexander Loktionov
Cc: kbuild-all, netdev, David VomLehn, David S . Miller,
Simon Edelhaus, Dmitrii Tarakanov, Pavel Belous, Dmitry Bezrukov
In-Reply-To: <20170119090931.GA28354@lkp-ne04.lkp.intel.com>
On Thu, 2017-01-19 at 17:09 +0800, kbuild test robot wrote:
> drivers/net/ethernet/aquantia/atlantic/aq_ring.c:24:20-41: WARNING: casting value returned by memory allocation function to (struct aq_ring_buff_s *) is useless.
>
> Remove casting the values returned by memory allocation functions
> like kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc.
[]
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> @@ -21,7 +21,7 @@ static struct aq_ring_s *aq_ring_alloc(s
> {
> int err = 0;
>
> - self->buff_ring = (struct aq_ring_buff_s *)
> + self->buff_ring =
> kzalloc(sizeof(struct aq_ring_buff_s) * self->size, GFP_KERNEL);
This should likely be kcalloc
^ permalink raw reply
* Re: [PATCHv3 net-next 2/4] sctp: implement sender-side procedures for SSN/TSN Reset Request Parameter
From: Xin Long @ 2017-01-20 8:21 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: network dev, linux-sctp, Neil Horman, Vlad Yasevich, davem
In-Reply-To: <20170119220206.GN3781@localhost.localdomain>
On Fri, Jan 20, 2017 at 6:02 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Fri, Jan 20, 2017 at 01:19:12AM +0800, Xin Long wrote:
>> This patch is to implement Sender-Side Procedures for the SSN/TSN
>> Reset Request Parameter descibed in rfc6525 section 5.1.4.
>>
>> It is also to add sockopt SCTP_RESET_ASSOC in rfc6525 section 6.3.3
>> for users.
>>
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>> ---
>> include/net/sctp/sctp.h | 1 +
>> include/uapi/linux/sctp.h | 1 +
>> net/sctp/socket.c | 29 +++++++++++++++++++++++++++++
>> net/sctp/stream.c | 33 +++++++++++++++++++++++++++++++++
>> 4 files changed, 64 insertions(+)
>>
>> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
>> index 3cfd365b..b93820f 100644
>> --- a/include/net/sctp/sctp.h
>> +++ b/include/net/sctp/sctp.h
>> @@ -198,6 +198,7 @@ int sctp_offload_init(void);
>> */
>> int sctp_send_reset_streams(struct sctp_association *asoc,
>> struct sctp_reset_streams *params);
>> +int sctp_send_reset_assoc(struct sctp_association *asoc);
>>
>> /*
>> * Module global variables
>> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
>> index 03c27ce..c0bd8c3 100644
>> --- a/include/uapi/linux/sctp.h
>> +++ b/include/uapi/linux/sctp.h
>> @@ -117,6 +117,7 @@ typedef __s32 sctp_assoc_t;
>> #define SCTP_PR_ASSOC_STATUS 115
>> #define SCTP_ENABLE_STREAM_RESET 118
>> #define SCTP_RESET_STREAMS 119
>> +#define SCTP_RESET_ASSOC 120
>>
>> /* PR-SCTP policies */
>> #define SCTP_PR_SCTP_NONE 0x0000
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index bee4dd3..2c5c9ca 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -3812,6 +3812,32 @@ static int sctp_setsockopt_reset_streams(struct sock *sk,
>> return retval;
>> }
>>
>> +static int sctp_setsockopt_reset_assoc(struct sock *sk,
>> + char __user *optval,
>> + unsigned int optlen)
>> +{
>> + struct sctp_association *asoc;
>> + sctp_assoc_t associd;
>> + int retval = -EINVAL;
>> +
>> + if (optlen != sizeof(associd))
>> + goto out;
>> +
>> + if (copy_from_user(&associd, optval, optlen)) {
>> + retval = -EFAULT;
>> + goto out;
>> + }
>> +
>> + asoc = sctp_id2assoc(sk, associd);
>> + if (!asoc)
>> + goto out;
>> +
>> + retval = sctp_send_reset_assoc(asoc);
>> +
>> +out:
>> + return retval;
>> +}
>> +
>> /* API 6.2 setsockopt(), getsockopt()
>> *
>> * Applications use setsockopt() and getsockopt() to set or retrieve
>> @@ -3984,6 +4010,9 @@ static int sctp_setsockopt(struct sock *sk, int level, int optname,
>> case SCTP_RESET_STREAMS:
>> retval = sctp_setsockopt_reset_streams(sk, optval, optlen);
>> break;
>> + case SCTP_RESET_ASSOC:
>> + retval = sctp_setsockopt_reset_assoc(sk, optval, optlen);
>> + break;
>> default:
>> retval = -ENOPROTOOPT;
>> break;
>> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
>> index 13d5e07..b368191 100644
>> --- a/net/sctp/stream.c
>> +++ b/net/sctp/stream.c
>> @@ -162,3 +162,36 @@ int sctp_send_reset_streams(struct sctp_association *asoc,
>> out:
>> return retval;
>> }
>> +
>> +int sctp_send_reset_assoc(struct sctp_association *asoc)
>> +{
>> + struct sctp_chunk *chunk = NULL;
>> + int retval;
>> + __u16 i;
>> +
>> + if (!asoc->peer.reconf_capable ||
>> + !(asoc->strreset_enable & SCTP_ENABLE_RESET_ASSOC_REQ))
>> + return -ENOPROTOOPT;
>> +
>> + if (asoc->strreset_outstanding)
>> + return -EINPROGRESS;
>> +
>> + chunk = sctp_make_strreset_tsnreq(asoc);
>> + if (!chunk)
>> + return -ENOMEM;
>> +
>
> Please add a comment here explaining that the for below is to block
> further xmit of data until this request is completed.
sure.
>
>> + for (i = 0; i < asoc->stream->outcnt; i++)
>> + asoc->stream->out[i].state = SCTP_STREAM_CLOSED;
>> +
>> + asoc->strreset_outstanding = 1;
>> + asoc->strreset_chunk = chunk;
>> + sctp_chunk_hold(asoc->strreset_chunk);
>> +
>> + retval = sctp_send_reconf(asoc, chunk);
>> + if (retval) {
>> + sctp_chunk_put(asoc->strreset_chunk);
>> + asoc->strreset_chunk = NULL;
>
> If this happens, the asoc will get stuck, as strreset_outstanding is
> marked as 1, all streams are closed and no packet was even queued
> (I'm assuming so as you're dropping the reference on it).
you're right, I'm planning to move:
>> + for (i = 0; i < asoc->stream->outcnt; i++)
>> + asoc->stream->out[i].state = SCTP_STREAM_CLOSED;
>> +
>> + asoc->strreset_outstanding = 1;
right after this check. so that it will do it only when
the reconf chunk is sent out.
>
>
>> + }
>> +
>> + return retval;
>> +}
>> --
>> 2.1.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* Re: [PATCHv3 net-next 4/4] sctp: implement sender-side procedures for Add Incoming/Outgoing Streams Request Parameter
From: Xin Long @ 2017-01-20 8:51 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: network dev, linux-sctp, Neil Horman, Vlad Yasevich, davem
In-Reply-To: <20170119221534.GO3781@localhost.localdomain>
On Fri, Jan 20, 2017 at 6:15 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Fri, Jan 20, 2017 at 01:19:14AM +0800, Xin Long wrote:
>> This patch is to implement Sender-Side Procedures for the Add
>> Outgoing and Incoming Streams Request Parameter described in
>> rfc6525 section 5.1.5-5.1.6.
>>
>> It is also to add sockopt SCTP_ADD_STREAMS in rfc6525 section
>> 6.3.4 for users.
>>
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>> ---
>> include/net/sctp/sctp.h | 2 +
>> include/uapi/linux/sctp.h | 7 ++++
>> net/sctp/socket.c | 29 ++++++++++++++
>> net/sctp/stream.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 137 insertions(+)
>>
>> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
>> index b93820f..68ee1a6 100644
>> --- a/include/net/sctp/sctp.h
>> +++ b/include/net/sctp/sctp.h
>> @@ -199,6 +199,8 @@ int sctp_offload_init(void);
>> int sctp_send_reset_streams(struct sctp_association *asoc,
>> struct sctp_reset_streams *params);
>> int sctp_send_reset_assoc(struct sctp_association *asoc);
>> +int sctp_send_add_streams(struct sctp_association *asoc,
>> + struct sctp_add_streams *params);
>>
>> /*
>> * Module global variables
>> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
>> index c0bd8c3..a91a9cc 100644
>> --- a/include/uapi/linux/sctp.h
>> +++ b/include/uapi/linux/sctp.h
>> @@ -118,6 +118,7 @@ typedef __s32 sctp_assoc_t;
>> #define SCTP_ENABLE_STREAM_RESET 118
>> #define SCTP_RESET_STREAMS 119
>> #define SCTP_RESET_ASSOC 120
>> +#define SCTP_ADD_STREAMS 121
>>
>> /* PR-SCTP policies */
>> #define SCTP_PR_SCTP_NONE 0x0000
>> @@ -1027,4 +1028,10 @@ struct sctp_reset_streams {
>> uint16_t srs_stream_list[]; /* list if srs_num_streams is not 0 */
>> };
>>
>> +struct sctp_add_streams {
>> + sctp_assoc_t sas_assoc_id;
>> + uint16_t sas_instrms;
>> + uint16_t sas_outstrms;
>> +};
>> +
>> #endif /* _UAPI_SCTP_H */
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index 2c5c9ca..ae0a99e 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -3838,6 +3838,32 @@ static int sctp_setsockopt_reset_assoc(struct sock *sk,
>> return retval;
>> }
>>
>> +static int sctp_setsockopt_add_streams(struct sock *sk,
>> + char __user *optval,
>> + unsigned int optlen)
>> +{
>> + struct sctp_association *asoc;
>> + struct sctp_add_streams params;
>> + int retval = -EINVAL;
>> +
>> + if (optlen != sizeof(params))
>> + goto out;
>> +
>> + if (copy_from_user(¶ms, optval, optlen)) {
>> + retval = -EFAULT;
>> + goto out;
>> + }
>> +
>> + asoc = sctp_id2assoc(sk, params.sas_assoc_id);
>> + if (!asoc)
>> + goto out;
>> +
>> + retval = sctp_send_add_streams(asoc, ¶ms);
>> +
>> +out:
>> + return retval;
>> +}
>> +
>> /* API 6.2 setsockopt(), getsockopt()
>> *
>> * Applications use setsockopt() and getsockopt() to set or retrieve
>> @@ -4013,6 +4039,9 @@ static int sctp_setsockopt(struct sock *sk, int level, int optname,
>> case SCTP_RESET_ASSOC:
>> retval = sctp_setsockopt_reset_assoc(sk, optval, optlen);
>> break;
>> + case SCTP_ADD_STREAMS:
>> + retval = sctp_setsockopt_add_streams(sk, optval, optlen);
>> + break;
>> default:
>> retval = -ENOPROTOOPT;
>> break;
>> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
>> index b368191..ba41837 100644
>> --- a/net/sctp/stream.c
>> +++ b/net/sctp/stream.c
>> @@ -195,3 +195,102 @@ int sctp_send_reset_assoc(struct sctp_association *asoc)
>>
>> return retval;
>> }
>> +
>> +int sctp_send_add_streams(struct sctp_association *asoc,
>> + struct sctp_add_streams *params)
>> +{
>> + struct sctp_stream *stream = asoc->stream;
>> + struct sctp_chunk *chunk = NULL;
>> + int retval = -EINVAL;
>> + __u16 out, in;
>> +
>> + if (!asoc->peer.reconf_capable ||
>> + !(asoc->strreset_enable & SCTP_ENABLE_CHANGE_ASSOC_REQ)) {
>> + retval = -ENOPROTOOPT;
>> + goto out;
>> + }
>> +
>> + if (asoc->strreset_outstanding) {
>> + retval = -EINPROGRESS;
>> + goto out;
>> + }
>> +
>> + out = params->sas_outstrms;
>> + in = params->sas_instrms;
>> +
>> + if (!out && !in)
>> + goto out;
>> +
>> + if (out) {
>> + __u16 nums = stream->outcnt + out;
>> +
>> + /* Check for overflow, can't use nums here */
>> + if (stream->outcnt + out > SCTP_MAX_STREAM)
>> + goto out;
>> +
>> + /* Use ksize to check if stream array really needs to realloc */
>> + if (ksize(stream->out) / sizeof(*stream->out) < nums) {
>> + struct sctp_stream_out *streamout;
>> +
>> + streamout = kcalloc(nums, sizeof(*streamout),
>> + GFP_KERNEL);
>> + if (!streamout) {
>> + retval = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + memcpy(streamout, stream->out,
>> + sizeof(*streamout) * stream->outcnt);
>> +
>> + kfree(stream->out);
>> + stream->out = streamout;
>> + }
>> +
>> + stream->outcnt = nums;
>> + }
>> +
>> + if (in) {
>> + __u16 nums = stream->incnt + in;
>> +
>> + if (stream->incnt + in > SCTP_MAX_STREAM)
>> + goto out;
>> +
>> + if (ksize(stream->in) / sizeof(*stream->in) < nums) {
>> + struct sctp_stream_in *streamin;
>> +
>> + streamin = kcalloc(nums, sizeof(*streamin),
>> + GFP_KERNEL);
>> + if (!streamin) {
>> + retval = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + memcpy(streamin, stream->in,
>> + sizeof(*streamin) * stream->incnt);
>> +
>> + kfree(stream->in);
>> + stream->in = streamin;
>> + }
>> +
>> + stream->incnt = nums;
>> + }
>> +
>> + chunk = sctp_make_strreset_addstrm(asoc, out, in);
>> + if (!chunk) {
>> + retval = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + asoc->strreset_outstanding = !!out + !!in;
>> + asoc->strreset_chunk = chunk;
>> + sctp_chunk_hold(asoc->strreset_chunk);
>> +
>> + retval = sctp_send_reconf(asoc, chunk);
>> + if (retval) {
>> + sctp_chunk_put(asoc->strreset_chunk);
>> + asoc->strreset_chunk = NULL;
>
> Similar comment on recovery steps here. If we are assuming we failed to
> send the request, we should also revert the changes above.
> The memory reallocation seems fine as the streams defaults to closed,
> but shouldn't incnt and outcnt be reset?
yeah, I will set incnt and outcnt only when retval is 0.
>
>> + }
>> +
>> +out:
>> + return retval;
>> +}
>> --
>> 2.1.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* ipv6_get_ifaddr() not exported
From: Valentine Sinitsyn @ 2017-01-20 8:55 UTC (permalink / raw)
To: netdev
Hi all,
I'm working on a custom Netfilter module which could seemingly use
ipv6_get_ifaddr() function to find a netdev which has a destination IPv6
assigned (if any). The function is public, but not exported, so I can't
use it in my module.
Am I doing anything wrong, or I'm just a first type to use
ipv6_get_ifaddr() outside net/ipv6 code, and it's okay to export it now?
Thanks,
Valentine
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox