* RE: general protection fault in tipc_nametbl_unsubscribe
From: Jon Maloy @ 2018-04-03 17:16 UTC (permalink / raw)
To: syzbot, davem@davemloft.net, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com,
tipc-discussion@lists.sourceforge.net, ying.xue@windriver.com
In-Reply-To: <000000000000a7c16a0568d750ce@google.com>
#syz dup: general protection fault in __list_del_entry_valid (3)
> -----Original Message-----
> From: syzbot
> [mailto:syzbot+4859fe19555ea87c42f3@syzkaller.appspotmail.com]
> Sent: Monday, April 02, 2018 02:01
> To: davem@davemloft.net; Jon Maloy <jon.maloy@ericsson.com>; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org; syzkaller-
> bugs@googlegroups.com; tipc-discussion@lists.sourceforge.net;
> ying.xue@windriver.com
> Subject: general protection fault in tipc_nametbl_unsubscribe
>
> Hello,
>
> syzbot hit the following crash on upstream commit
> 10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 2018
> +0000) Merge branch 'perf-urgent-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=4859fe19555ea87c42f3
>
> So far this crash happened 3 times on upstream.
> C reproducer:
> https://syzkaller.appspot.com/x/repro.c?id=4775372465897472
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=4868734988582912
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5073802094444544
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
> compiler: gcc (GCC) 7.1.1 20170620
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4859fe19555ea87c42f3@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.
>
> R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000 Name
> sequence creation failed, no memory Failed to create subscription for
> {24576,0,4294967295}
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 4447 Comm: syzkaller851181 Not tainted 4.16.0-rc7+ #374
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
> RSP: 0018:ffff8801ae1aef48 EFLAGS: 00010246
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffff8801cf54c760 RDI: ffff8801cf54c768
> RBP: ffff8801ae1aef60 R08: 1ffff10035c35cff R09: ffffffff89956150
> R10: ffff8801ae1aee28 R11: 000000000000168a R12: ffffffff87745ea0
> R13: ffff8801ae1af100 R14: ffff8801cf54c760 R15: ffff8801cf4c8cc0
> FS: 0000000000000000(0000) GS:ffff8801db100000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055dce15c3090 CR3: 000000000846a002 CR4: 00000000001606e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call
> Trace:
> __list_del_entry include/linux/list.h:117 [inline]
> list_del_init include/linux/list.h:159 [inline]
> tipc_nametbl_unsubscribe+0x318/0x990 net/tipc/name_table.c:848
> tipc_subscrb_subscrp_delete+0x1e9/0x460 net/tipc/subscr.c:212
> tipc_subscrb_delete net/tipc/subscr.c:242 [inline]
> tipc_subscrb_release_cb+0x17/0x30 net/tipc/subscr.c:321
> tipc_topsrv_kern_unsubscr+0x2c3/0x430 net/tipc/server.c:535
> tipc_group_delete+0x2c0/0x3d0 net/tipc/group.c:231
> tipc_sk_leave+0x10b/0x200 net/tipc/socket.c:2795
> tipc_release+0x154/0xff0 net/tipc/socket.c:577
> sock_release+0x8d/0x1e0 net/socket.c:595
> sock_close+0x16/0x20 net/socket.c:1149
> __fput+0x327/0x7e0 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x199/0x270 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x9bb/0x1ad0 kernel/exit.c:865
> do_group_exit+0x149/0x400 kernel/exit.c:968
> SYSC_exit_group kernel/exit.c:979 [inline]
> SyS_exit_group+0x1d/0x20 kernel/exit.c:977
> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x43f228
> RSP: 002b:00007ffde31217e8 EFLAGS: 00000246 ORIG_RAX:
> 00000000000000e7
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f228
> RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
> RBP: 00000000004bf308 R08: 00000000000000e7 R09: ffffffffffffffd0
> R10: 00000000204ee000 R11: 0000000000000246 R12: 0000000000000001
> R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
> Code: 00 00 00 00 ad de 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de 48 89 da 48
> 39 c3 74 65 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df <80> 3c 02 00
> 75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8
> RIP: __list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51 RSP:
> ffff8801ae1aef48
> ---[ end trace ba18c1598e2d5535 ]---
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch and provide the patch inline or as an
> attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report If it's a one-off invalid bug report,
> please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug report.
> Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH v15 ] net/veth/XDP: Line-rate packet forwarding in kernel
From: David Ahern @ 2018-04-03 17:14 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: John Fastabend, Md. Islam, netdev, David Miller, stephen, agaceph,
Pavel Emelyanov, Eric Dumazet, brouer
In-Reply-To: <20180403170624.ojofd737zh5pul5m@ast-mbp.dhcp.thefacebook.com>
On 4/3/18 11:06 AM, Alexei Starovoitov wrote:
>> For 3 and 4 above I was referring to the route lookup part of it; sorry
>> for not being clear.
>>
>> For example, eth1 is enslaved to bond1 which is in VRF red. The lookup
>> needs to go to the table associated with the VRF. That is not known by
>> just looking at eth1. The code exists to walk the upper layers and do
>> the effective translations, just need to cover those cases.
>>
>> The VLAN part of it is a bit more difficult - ingress device for the
>> lookup should be eth1.100 for example not eth1, and then if eth1.100 is
>> enslaved to a VRF, ...
>>
>> None of it is that complex, just need to walk through the various use
>> cases and make sure bpf_ipv4_fwd_lookup and bpf_ipv6_fwd_lookup can do
>> the right thing for these common use cases.
> I'm a bit lost here. Why this is a concern?
> 'index' as argument that bpf prog is passing into the helper.
> The clsbpf program may choose to pass ifindex of the netdev
> it's attached to or some other one.
> In your patch you have:
> +BPF_CALL_3(bpf_ipv4_fwd_lookup, int, index, const struct iphdr *, iph,
> + struct ethhdr *, eth)
> +{
> + struct flowi4 fl4 = {
> + .daddr = iph->daddr,
> + .saddr = iph->saddr,
> + .flowi4_iif = index,
> + .flowi4_tos = iph->tos & IPTOS_RT_MASK,
> + .flowi4_scope = RT_SCOPE_UNIVERSE,
> + };
>
> As you saying there is concern with .flowi4_iif = index line ?
yes. BPF / XDP programs are installed on the bottom device ... e.g.,
eth1. The L3 lookup is not necessarily done on that device index.
> In the above the only thing Daniel and myself pointed out that
> passing struct iphdr * like this is not safe.
> We either need size argument which would be a bit cumbersome or
> extend verifier a little to specify size as part of helper proto,
> so that verifier can eforce it without having program to pass it.
> imo that's the only bit missing from that patch to upstream it.
sure. I did not mean that item 1. was a big deal, just something that
needed to be fixed.
>
> Also the helper isn't really related to XDP. It should work as-is
> for clsbpf and xdp programs as far as I can tell.
>
yes.
^ permalink raw reply
* [net-next 1/1] tipc: Fix missing list initializations in struct tipc_subscription
From: Jon Maloy @ 2018-04-03 17:11 UTC (permalink / raw)
To: davem, netdev
Cc: mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen, hoang.h.le,
jon.maloy, canh.d.luu, ying.xue, tipc-discussion
When an item of struct tipc_subscription is created, we fail to
initialize the two lists aggregated into the struct. This has so far
never been a problem, since the items are just added to a root
object by list_add(), which does not require the addee list to be
pre-initialized. However, syzbot is provoking situations where this
addition fails, whereupon the attempted removal if the item from
the list causes a crash.
This problem seems to always have been around, despite that the code
for creating this object was rewritten in commit 242e82cc95f6 ("tipc:
collapse subscription creation functions"), which is still in net-next.
We fix this for that commit by initializing the two lists properly.
Fixes: 242e82cc95f6 ("tipc: collapse subscription creation functions")
Reported-by: syzbot+0bb443b74ce09197e970@syzkaller.appspotmail.com
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/subscr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tipc/subscr.c b/net/tipc/subscr.c
index 6925a98..b7d80bc 100644
--- a/net/tipc/subscr.c
+++ b/net/tipc/subscr.c
@@ -145,6 +145,8 @@ struct tipc_subscription *tipc_sub_subscribe(struct net *net,
pr_warn("Subscription rejected, no memory\n");
return NULL;
}
+ INIT_LIST_HEAD(&sub->service_list);
+ INIT_LIST_HEAD(&sub->sub_list);
sub->net = net;
sub->conid = conid;
sub->inactive = false;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v15 ] net/veth/XDP: Line-rate packet forwarding in kernel
From: Alexei Starovoitov @ 2018-04-03 17:06 UTC (permalink / raw)
To: David Ahern
Cc: John Fastabend, Md. Islam, netdev, David Miller, stephen, agaceph,
Pavel Emelyanov, Eric Dumazet, brouer
In-Reply-To: <8832a8a4-24bb-7841-bb84-31f7c05c2b72@gmail.com>
On Tue, Apr 03, 2018 at 11:00:20AM -0600, David Ahern wrote:
> On 4/3/18 10:41 AM, John Fastabend wrote:
> > On 04/03/2018 08:07 AM, David Ahern wrote:
> >> On 4/2/18 12:16 PM, Alexei Starovoitov wrote:
> >>> On Mon, Apr 02, 2018 at 12:09:44PM -0600, David Ahern wrote:
> >>>> On 4/2/18 12:03 PM, John Fastabend wrote:
> >>>>>
> >>>>> Can the above be a normal BPF helper that returns an
> >>>>> ifindex? Then something roughly like this patter would
> >>>>> work for all drivers with redirect support,
> >>>>>
> >>>>>
> >>>>> route_ifindex = ip_route_lookup(__daddr, ....)
> >>>>> if (!route_ifindex)
> >>>>> return do_foo()
> >>>>> return xdp_redirect(route_ifindex);
> >>>>>
> >>>>> So my suggestion is,
> >>>>>
> >>>>> 1. enable veth xdp (including redirect support)
> >>>>> 2. add a helper to lookup route from routing table
> >>>>>
> >>>>> Alternatively you can skip step (2) and encode the routing
> >>>>> table in BPF directly. Maybe we need a more efficient data
> >>>>> structure but that should also work.
> >>>>>
> >>>>
> >>>> That's what I have here:
> >>>>
> >>>> https://github.com/dsahern/linux/commit/bab42f158c0925339f7519df7fb2cde8eac33aa8
> >>>
> >>> was wondering what's up with the delay and when are you going to
> >>> submit them officially...
> >>> The use case came up several times.
> >>>
> >>
> >> I need to find time to come back to that set. As I recall there a number
> >> of outstanding issues:
> >>
> >> 1. you and Daniel had comments about the bpf_func_proto declarations
> >>
> >> 2. Jesper had concerns about xdp redirect to any netdev. e.g., How does
> >> the lookup know the egress netdev supports xdp? Right now you can try
> >> and the packet is dropped if it is not supported.
> >>
> >
> > There should probably be a tracepoint there if not already. Otherwise
> > I think the orchestration/loader layer should be ensuring that xdp
> > support is sufficient. I don't think we need anything specific in the
> > XDP/BPF code to handle unsupported devices.
>
> ok. I am fine with starting with that.
>
> >
> >> 3. VLAN devices. I suspect these will affect the final bpf function
> >> prototype. It would awkward to have 1 forwarding API for non-vlan
> >> devices and a second for vlan devices, hence the need to resolve this
> >> before it goes in.
> >>
> >
> > Interesting. Do we need stacked XDP, I could imagine having 802.1Q
> > simply call the lower dev XDP xmit routine. Possibly adding the 8021q
> > header first.
> >
> > Or alternatively a new dev type could let users query things like
> > vlan-id from the dev rather than automatically doing the tagging. I
> > suspect though if you forward to a vlan device automatically adding
> > the tag is the correct behavior.
> >
> >
> >> 4. What about other stacked devices - bonds and bridges - will those
> >> just work with the bpf helper? VRF is already handled of course. ;-)
> >>
> >
> > So if we simply handle this like other stacked devices and call the
> > lower devs xdp_xmit routine we should get reasonable behavior. For
> > bonds and bridges I guess some generalization is needed though because
> > everything at the moment is skb centric. I don't think its necessary
> > in the first series though. It can be added later.
> >
>
> For 3 and 4 above I was referring to the route lookup part of it; sorry
> for not being clear.
>
> For example, eth1 is enslaved to bond1 which is in VRF red. The lookup
> needs to go to the table associated with the VRF. That is not known by
> just looking at eth1. The code exists to walk the upper layers and do
> the effective translations, just need to cover those cases.
>
> The VLAN part of it is a bit more difficult - ingress device for the
> lookup should be eth1.100 for example not eth1, and then if eth1.100 is
> enslaved to a VRF, ...
>
> None of it is that complex, just need to walk through the various use
> cases and make sure bpf_ipv4_fwd_lookup and bpf_ipv6_fwd_lookup can do
> the right thing for these common use cases.
I'm a bit lost here. Why this is a concern?
'index' as argument that bpf prog is passing into the helper.
The clsbpf program may choose to pass ifindex of the netdev
it's attached to or some other one.
In your patch you have:
+BPF_CALL_3(bpf_ipv4_fwd_lookup, int, index, const struct iphdr *, iph,
+ struct ethhdr *, eth)
+{
+ struct flowi4 fl4 = {
+ .daddr = iph->daddr,
+ .saddr = iph->saddr,
+ .flowi4_iif = index,
+ .flowi4_tos = iph->tos & IPTOS_RT_MASK,
+ .flowi4_scope = RT_SCOPE_UNIVERSE,
+ };
As you saying there is concern with .flowi4_iif = index line ?
In the above the only thing Daniel and myself pointed out that
passing struct iphdr * like this is not safe.
We either need size argument which would be a bit cumbersome or
extend verifier a little to specify size as part of helper proto,
so that verifier can eforce it without having program to pass it.
imo that's the only bit missing from that patch to upstream it.
Also the helper isn't really related to XDP. It should work as-is
for clsbpf and xdp programs as far as I can tell.
^ permalink raw reply
* Re: [net-next V9 PATCH 00/16] XDP redirect memory return API
From: Saeed Mahameed @ 2018-04-03 17:03 UTC (permalink / raw)
To: David Miller
Cc: Jesper Dangaard Brouer, Linux Netdev List, bjorn.topel,
magnus.karlsson, Eugenia Emantayev, jasowang, John Fastabend,
Eran Ben Elisha, Saeed Mahameed, Gal Pressman, Daniel Borkmann,
Alexei Starovoitov, Tariq Toukan
In-Reply-To: <20180403.122338.1130037886539379926.davem@davemloft.net>
On Tue, Apr 3, 2018 at 9:23 AM, David Miller <davem@davemloft.net> wrote:
> From: Jesper Dangaard Brouer <brouer@redhat.com>
> Date: Tue, 3 Apr 2018 18:07:16 +0200
>
>> On Tue, 03 Apr 2018 10:54:27 -0400 (EDT)
>> David Miller <davem@davemloft.net> wrote:
>>
>>> Don't worry, just resubmit when net-next opens back up.
>>
>> At that point in time, should I got back to posting it against the
>> bpf-next git-tree again? Any preferences from Mellanox or BPF-guys?
>
> I have no personal preference, although it's probably best to go
> through the bpf-next tree.
>
>> ... It have been a bit of a pain to keep track of driver changes in
>> net-next, and waiting for them to get merged into bpf-next.
>
> I totally understand :)
it depends on how often bpf-next gets synced with net-next, mlx5
constantly changes and
I can't gurantee no merge conflicts will occur.
IMHO, this series is more focused on device drivers and less on XDP or BPF,
so it makes more sense to post it to net-next, it will be less pain
for everyone,
especially for you Jesper :).
^ permalink raw reply
* Re: [PATCH net] net: dsa: mt7530: Use NULL instead of plain integer
From: Florian Fainelli @ 2018-04-03 17:02 UTC (permalink / raw)
To: Sean Wang; +Cc: netdev, Andrew Lunn, Vivien Didelot, open list, linux-mediatek
In-Reply-To: <1522721904.18424.51.camel@mtkswgap22>
On 04/02/2018 07:18 PM, Sean Wang wrote:
> On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote:
>> We would be passing 0 instead of NULL as the rsp argument to
>> mt7530_fdb_cmd(), fix that.
>>
>
> Acked-by: Sean Wang <sean.wang@mediatek.com>
>
> BTW, does the part of the commit message should be updated with "passing
> NULL instead of 0"?
I don't follow you, the commit message indicates what we were doing
which implies it was wrong and fixes it. Would you want me to reword
that part?
--
Florian
^ permalink raw reply
* Re: [PATCH v15 ] net/veth/XDP: Line-rate packet forwarding in kernel
From: David Ahern @ 2018-04-03 17:00 UTC (permalink / raw)
To: John Fastabend, Alexei Starovoitov
Cc: Md. Islam, netdev, David Miller, stephen, agaceph,
Pavel Emelyanov, Eric Dumazet, brouer
In-Reply-To: <4f0c0f20-ce25-4996-4f28-14a73c988446@gmail.com>
On 4/3/18 10:41 AM, John Fastabend wrote:
> On 04/03/2018 08:07 AM, David Ahern wrote:
>> On 4/2/18 12:16 PM, Alexei Starovoitov wrote:
>>> On Mon, Apr 02, 2018 at 12:09:44PM -0600, David Ahern wrote:
>>>> On 4/2/18 12:03 PM, John Fastabend wrote:
>>>>>
>>>>> Can the above be a normal BPF helper that returns an
>>>>> ifindex? Then something roughly like this patter would
>>>>> work for all drivers with redirect support,
>>>>>
>>>>>
>>>>> route_ifindex = ip_route_lookup(__daddr, ....)
>>>>> if (!route_ifindex)
>>>>> return do_foo()
>>>>> return xdp_redirect(route_ifindex);
>>>>>
>>>>> So my suggestion is,
>>>>>
>>>>> 1. enable veth xdp (including redirect support)
>>>>> 2. add a helper to lookup route from routing table
>>>>>
>>>>> Alternatively you can skip step (2) and encode the routing
>>>>> table in BPF directly. Maybe we need a more efficient data
>>>>> structure but that should also work.
>>>>>
>>>>
>>>> That's what I have here:
>>>>
>>>> https://github.com/dsahern/linux/commit/bab42f158c0925339f7519df7fb2cde8eac33aa8
>>>
>>> was wondering what's up with the delay and when are you going to
>>> submit them officially...
>>> The use case came up several times.
>>>
>>
>> I need to find time to come back to that set. As I recall there a number
>> of outstanding issues:
>>
>> 1. you and Daniel had comments about the bpf_func_proto declarations
>>
>> 2. Jesper had concerns about xdp redirect to any netdev. e.g., How does
>> the lookup know the egress netdev supports xdp? Right now you can try
>> and the packet is dropped if it is not supported.
>>
>
> There should probably be a tracepoint there if not already. Otherwise
> I think the orchestration/loader layer should be ensuring that xdp
> support is sufficient. I don't think we need anything specific in the
> XDP/BPF code to handle unsupported devices.
ok. I am fine with starting with that.
>
>> 3. VLAN devices. I suspect these will affect the final bpf function
>> prototype. It would awkward to have 1 forwarding API for non-vlan
>> devices and a second for vlan devices, hence the need to resolve this
>> before it goes in.
>>
>
> Interesting. Do we need stacked XDP, I could imagine having 802.1Q
> simply call the lower dev XDP xmit routine. Possibly adding the 8021q
> header first.
>
> Or alternatively a new dev type could let users query things like
> vlan-id from the dev rather than automatically doing the tagging. I
> suspect though if you forward to a vlan device automatically adding
> the tag is the correct behavior.
>
>
>> 4. What about other stacked devices - bonds and bridges - will those
>> just work with the bpf helper? VRF is already handled of course. ;-)
>>
>
> So if we simply handle this like other stacked devices and call the
> lower devs xdp_xmit routine we should get reasonable behavior. For
> bonds and bridges I guess some generalization is needed though because
> everything at the moment is skb centric. I don't think its necessary
> in the first series though. It can be added later.
>
For 3 and 4 above I was referring to the route lookup part of it; sorry
for not being clear.
For example, eth1 is enslaved to bond1 which is in VRF red. The lookup
needs to go to the table associated with the VRF. That is not known by
just looking at eth1. The code exists to walk the upper layers and do
the effective translations, just need to cover those cases.
The VLAN part of it is a bit more difficult - ingress device for the
lookup should be eth1.100 for example not eth1, and then if eth1.100 is
enslaved to a VRF, ...
None of it is that complex, just need to walk through the various use
cases and make sure bpf_ipv4_fwd_lookup and bpf_ipv6_fwd_lookup can do
the right thing for these common use cases.
Handling lwt and mpls for example, can certainly be a follow on.
^ permalink raw reply
* RE: [PATCH v5 03/14] PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth
From: Keller, Jacob E @ 2018-04-03 16:54 UTC (permalink / raw)
To: Bjorn Helgaas, Jacob Keller
Cc: Tal Gilboa, Tariq Toukan, Ariel Elior, Ganesh Goudar,
Kirsher, Jeffrey T, everest-linux-l2@cavium.com,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <20180403140552.GB60020@bhelgaas-glaptop.roam.corp.google.com>
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> Sent: Tuesday, April 03, 2018 7:06 AM
> To: Jacob Keller <jacob.keller@gmail.com>
> Cc: Tal Gilboa <talgi@mellanox.com>; Tariq Toukan <tariqt@mellanox.com>;
> Keller, Jacob E <jacob.e.keller@intel.com>; Ariel Elior <ariel.elior@cavium.com>;
> Ganesh Goudar <ganeshgr@chelsio.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; everest-linux-l2@cavium.com; intel-wired-
> lan@lists.osuosl.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-pci@vger.kernel.org
> Subject: Re: [PATCH v5 03/14] PCI: Add pcie_bandwidth_capable() to compute
> max supported link bandwidth
>
> On Mon, Apr 02, 2018 at 05:30:54PM -0700, Jacob Keller wrote:
> > On Mon, Apr 2, 2018 at 7:05 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > +/* PCIe speed to Mb/s reduced by encoding overhead */
> > > +#define PCIE_SPEED2MBS_ENC(speed) \
> > > + ((speed) == PCIE_SPEED_16_0GT ? (16000*(128/130)) : \
> > > + (speed) == PCIE_SPEED_8_0GT ? (8000*(128/130)) : \
> > > + (speed) == PCIE_SPEED_5_0GT ? (5000*(8/10)) : \
> > > + (speed) == PCIE_SPEED_2_5GT ? (2500*(8/10)) : \
> > > + 0)
> > > +
> >
> > Should this be "(speed * x ) / y" instead? wouldn't they calculate
> > 128/130 and truncate that to zero before multiplying by the speed? Or
> > are compilers smart enough to do this the other way to avoid the
> > losses?
>
> Yep, thanks for saving me yet more embarrassment.
That's what patch review is for :D
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()
From: Al Viro @ 2018-04-03 16:45 UTC (permalink / raw)
To: David Miller; +Cc: f.fainelli, netdev, opendmb, linux-kernel
In-Reply-To: <20180403.123305.1783530733365447500.davem@davemloft.net>
On Tue, Apr 03, 2018 at 12:33:05PM -0400, David Miller wrote:
> Yes Al, however the pattern choosen here is probably cheaper on little endian:
>
> __beXX val = x;
> switch (val) {
> case htons(ETH_P_FOO):
> ...
> }
>
> This way only the compiler byte swaps the constants at compile time,
> no code is actually generated to do it.
That's not obvious, actually - depends upon how sparse the switch ends
up being. You can easily lose more than a single byteswap insn on
worse cascase of comparisons.
^ permalink raw reply
* Re: [PATCH v15 ] net/veth/XDP: Line-rate packet forwarding in kernel
From: David Miller @ 2018-04-03 16:45 UTC (permalink / raw)
To: john.fastabend
Cc: dsahern, alexei.starovoitov, mislam4, netdev, stephen, agaceph,
xemul, edumazet, brouer
In-Reply-To: <4f0c0f20-ce25-4996-4f28-14a73c988446@gmail.com>
From: John Fastabend <john.fastabend@gmail.com>
Date: Tue, 3 Apr 2018 09:41:08 -0700
> On 04/03/2018 08:07 AM, David Ahern wrote:
>> 4. What about other stacked devices - bonds and bridges - will those
>> just work with the bpf helper? VRF is already handled of course. ;-)
>
> So if we simply handle this like other stacked devices and call the
> lower devs xdp_xmit routine we should get reasonable behavior. For
> bonds and bridges I guess some generalization is needed though because
> everything at the moment is skb centric. I don't think its necessary
> in the first series though. It can be added later.
I wonder if we need some feature bit gating this passthrough, just
like the various ->vlan_features and ->hw_enc_features.
^ permalink raw reply
* Re: [PATCH v15 ] net/veth/XDP: Line-rate packet forwarding in kernel
From: John Fastabend @ 2018-04-03 16:41 UTC (permalink / raw)
To: David Ahern, Alexei Starovoitov
Cc: Md. Islam, netdev, David Miller, stephen, agaceph,
Pavel Emelyanov, Eric Dumazet, brouer
In-Reply-To: <9cb8a162-3b6a-abfa-4f6e-524995bbfb8d@gmail.com>
On 04/03/2018 08:07 AM, David Ahern wrote:
> On 4/2/18 12:16 PM, Alexei Starovoitov wrote:
>> On Mon, Apr 02, 2018 at 12:09:44PM -0600, David Ahern wrote:
>>> On 4/2/18 12:03 PM, John Fastabend wrote:
>>>>
>>>> Can the above be a normal BPF helper that returns an
>>>> ifindex? Then something roughly like this patter would
>>>> work for all drivers with redirect support,
>>>>
>>>>
>>>> route_ifindex = ip_route_lookup(__daddr, ....)
>>>> if (!route_ifindex)
>>>> return do_foo()
>>>> return xdp_redirect(route_ifindex);
>>>>
>>>> So my suggestion is,
>>>>
>>>> 1. enable veth xdp (including redirect support)
>>>> 2. add a helper to lookup route from routing table
>>>>
>>>> Alternatively you can skip step (2) and encode the routing
>>>> table in BPF directly. Maybe we need a more efficient data
>>>> structure but that should also work.
>>>>
>>>
>>> That's what I have here:
>>>
>>> https://github.com/dsahern/linux/commit/bab42f158c0925339f7519df7fb2cde8eac33aa8
>>
>> was wondering what's up with the delay and when are you going to
>> submit them officially...
>> The use case came up several times.
>>
>
> I need to find time to come back to that set. As I recall there a number
> of outstanding issues:
>
> 1. you and Daniel had comments about the bpf_func_proto declarations
>
> 2. Jesper had concerns about xdp redirect to any netdev. e.g., How does
> the lookup know the egress netdev supports xdp? Right now you can try
> and the packet is dropped if it is not supported.
>
There should probably be a tracepoint there if not already. Otherwise
I think the orchestration/loader layer should be ensuring that xdp
support is sufficient. I don't think we need anything specific in the
XDP/BPF code to handle unsupported devices.
> 3. VLAN devices. I suspect these will affect the final bpf function
> prototype. It would awkward to have 1 forwarding API for non-vlan
> devices and a second for vlan devices, hence the need to resolve this
> before it goes in.
>
Interesting. Do we need stacked XDP, I could imagine having 802.1Q
simply call the lower dev XDP xmit routine. Possibly adding the 8021q
header first.
Or alternatively a new dev type could let users query things like
vlan-id from the dev rather than automatically doing the tagging. I
suspect though if you forward to a vlan device automatically adding
the tag is the correct behavior.
> 4. What about other stacked devices - bonds and bridges - will those
> just work with the bpf helper? VRF is already handled of course. ;-)
>
So if we simply handle this like other stacked devices and call the
lower devs xdp_xmit routine we should get reasonable behavior. For
bonds and bridges I guess some generalization is needed though because
everything at the moment is skb centric. I don't think its necessary
in the first series though. It can be added later.
.John
^ permalink raw reply
* Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()
From: David Miller @ 2018-04-03 16:33 UTC (permalink / raw)
To: viro; +Cc: f.fainelli, netdev, opendmb, linux-kernel
In-Reply-To: <20180403162933.GJ30522@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Tue, 3 Apr 2018 17:29:33 +0100
> On Mon, Apr 02, 2018 at 03:58:55PM -0700, Florian Fainelli wrote:
>> skb->protocol is a __be16 which we would be calling htons() against,
>> while this is not wrong per-se as it correctly results in swapping the
>> value on LE hosts, this still upsets sparse. Adopt a similar pattern to
>> what other drivers do and just assign ip_ver to skb->protocol, and then
>> use htons() against the different constants such that the compiler can
>> resolve the values at build time.
>
> Fuck that and fuck other drivers sharing that "pattern". It's not hard
> to remember:
> host-endian to net-endian short is htons
> host-endian to net-endian long is htonl
> net-endian to host-endian short is ntohs
> net-endian to host-endian long is ntohl
>
> That's *it*. No convoluted changes needed, just use the right primitive.
> You are turning trivial one-liners ("conversions between host- and net-endian
> are the same in both directions, so the current code works even though we
> are using the wrong primitive, confusing the readers. Use the right one")
> which are absolutely self-contained and safe into much more massive changes
> that are harder to follow and which are *not* self-contained at all.
>
> Don't do it.
Yes Al, however the pattern choosen here is probably cheaper on little endian:
__beXX val = x;
switch (val) {
case htons(ETH_P_FOO):
...
}
This way only the compiler byte swaps the constants at compile time,
no code is actually generated to do it.
^ permalink raw reply
* Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()
From: Al Viro @ 2018-04-03 16:29 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Doug Berger, open list
In-Reply-To: <20180402225856.4351-2-f.fainelli@gmail.com>
On Mon, Apr 02, 2018 at 03:58:55PM -0700, Florian Fainelli wrote:
> skb->protocol is a __be16 which we would be calling htons() against,
> while this is not wrong per-se as it correctly results in swapping the
> value on LE hosts, this still upsets sparse. Adopt a similar pattern to
> what other drivers do and just assign ip_ver to skb->protocol, and then
> use htons() against the different constants such that the compiler can
> resolve the values at build time.
Fuck that and fuck other drivers sharing that "pattern". It's not hard
to remember:
host-endian to net-endian short is htons
host-endian to net-endian long is htonl
net-endian to host-endian short is ntohs
net-endian to host-endian long is ntohl
That's *it*. No convoluted changes needed, just use the right primitive.
You are turning trivial one-liners ("conversions between host- and net-endian
are the same in both directions, so the current code works even though we
are using the wrong primitive, confusing the readers. Use the right one")
which are absolutely self-contained and safe into much more massive changes
that are harder to follow and which are *not* self-contained at all.
Don't do it.
^ permalink raw reply
* Re: [net-next V9 PATCH 00/16] XDP redirect memory return API
From: David Miller @ 2018-04-03 16:23 UTC (permalink / raw)
To: brouer
Cc: netdev, bjorn.topel, magnus.karlsson, eugenia, jasowang,
john.fastabend, eranbe, saeedm, galp, borkmann,
alexei.starovoitov, tariqt
In-Reply-To: <20180403180716.66c3daee@redhat.com>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Tue, 3 Apr 2018 18:07:16 +0200
> On Tue, 03 Apr 2018 10:54:27 -0400 (EDT)
> David Miller <davem@davemloft.net> wrote:
>
>> Don't worry, just resubmit when net-next opens back up.
>
> At that point in time, should I got back to posting it against the
> bpf-next git-tree again? Any preferences from Mellanox or BPF-guys?
I have no personal preference, although it's probably best to go
through the bpf-next tree.
> ... It have been a bit of a pain to keep track of driver changes in
> net-next, and waiting for them to get merged into bpf-next.
I totally understand :)
^ permalink raw reply
* Re: [PATCH net 2/2] net: systemport: Fix sparse warnings in bcm_sysport_insert_tsb()
From: Al Viro @ 2018-04-03 16:23 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Doug Berger, open list
In-Reply-To: <20180402225856.4351-3-f.fainelli@gmail.com>
On Mon, Apr 02, 2018 at 03:58:56PM -0700, Florian Fainelli wrote:
> skb->protocol is a __be16 which we would be calling htons() against,
> while this is not wrong per-se as it correctly results in swapping the
> value on LE hosts, this still upsets sparse. Adopt a similar pattern to
> what other drivers do and just assign ip_ver to skb->protocol, and then
> use htons() against the different constants such that the compiler can
> resolve the values at build time.
This is completely bogus. What sparse is complaining about is htons used
to convert from big-endian to host-endian. Which is what ntohs is for.
IOW, instead of all that crap just
- ip_ver = htons(skb->protocol);
+ ip_ver = ntohs(skb->protocol);
and be done with that. Same in other drivers with the same problem.
^ permalink raw reply
* Re: [PATCH net v6 0/4] ipv6: udp: set dst cache for a connected sk if current not valid
From: Martin KaFai Lau @ 2018-04-03 16:14 UTC (permalink / raw)
To: Alexey Kodanev; +Cc: netdev, Eric Dumazet, David Miller
In-Reply-To: <1522756810-24985-1-git-send-email-alexey.kodanev@oracle.com>
On Tue, Apr 03, 2018 at 03:00:06PM +0300, Alexey Kodanev wrote:
> A new RTF_CACHE route can be created with the socket's dst cache
> update between the below calls in udpv6_sendmsg(), when datagram
> sending results to ICMPV6_PKT_TOOBIG error:
>
> dst = ip6_sk_dst_lookup_flow(...)
> ...
> release_dst:
> if (dst) {
> if (connected) {
> ip6_dst_store(sk, dst)
>
> Therefore, the new socket's dst cache reset to the old one on
> "release_dst:".
>
> The first three patches prepare the code to store dst cache
> with ip6_sk_dst_lookup_flow():
>
> * the first patch adds ip6_sk_dst_store_flow() function with
> commonly used source and destiantion addresses checks using
> the flow information.
>
> * the second patch adds a new argument to ip6_sk_dst_lookup_flow()
> and ability to store dst in the socket's cache. Also, the two
> users of the function are updated without enabling the new
> behavior: pingv6_sendmsg() and udpv6_sendmsg().
>
> * the third patch makes 'connected' variable in udpv6_sendmsg()
> to be consistent with ip6_sk_dst_store_flow(), changes its type
> from int to bool.
>
> The last patch contains the actual fix that removes sk dst cache
> update in the end of udpv6_sendmsg(), and allows to do it in
> ip6_sk_dst_lookup_flow().
Thanks for the patches!
Acked-by: Martin KaFai Lau <kafai@fb.com>
>
> v6: * use bool type for a new parameter in ip_sk_dst_lookup_flow()
> * add one more patch to convert 'connected' variable in
> udpv6_sendmsg() from int to bool type. If it shouldn't be
> here I will resend it when the net-next is opened.
>
> v5: * relocate ip6_sk_dst_store_flow() to net/ipv6/route.c and
> rename ip6_dst_store_flow() to ip6_sk_dst_store_flow() as
> suggested by Martin
>
> v4: * fix the error in the build of ip_dst_store_flow() reported by
> kbuild test robot due to missing checks for CONFIG_IPV6: add
> new function to ip6_output.c instead of ip6_route.h
> * add 'const' to struct flowi6 in ip6_dst_store_flow()
> * minor commit messages fixes
>
> v3: * instead of moving ip6_dst_store() above udp_v6_send_skb(),
> update socket's dst cache inside ip6_sk_dst_lookup_flow()
> if the current one is invalid
> * the issue not reproduced in 4.1, but starting from 4.2. Add
> one more 'Fixes:' commit that creates new RTF_CACHE route.
> Though, it is also mentioned in the first one
>
> Alexey Kodanev (4):
> ipv6: add a wrapper for ip6_dst_store() with flowi6 checks
> ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()
> ipv6: udp: convert 'connected' to bool type in udpv6_sendmsg()
> ipv6: udp: set dst cache for a connected sk if current not valid
>
> include/net/ip6_route.h | 3 +++
> include/net/ipv6.h | 3 ++-
> net/ipv6/datagram.c | 9 +--------
> net/ipv6/ip6_output.c | 15 ++++++++++++---
> net/ipv6/ping.c | 2 +-
> net/ipv6/route.c | 17 +++++++++++++++++
> net/ipv6/udp.c | 31 +++++++------------------------
> 7 files changed, 43 insertions(+), 37 deletions(-)
>
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [net-next V9 PATCH 00/16] XDP redirect memory return API
From: Jesper Dangaard Brouer @ 2018-04-03 16:07 UTC (permalink / raw)
To: David Miller
Cc: netdev, bjorn.topel, magnus.karlsson, eugenia, jasowang,
john.fastabend, eranbe, saeedm, galp, borkmann,
alexei.starovoitov, tariqt, brouer
In-Reply-To: <20180403.105427.1908874085989267860.davem@davemloft.net>
On Tue, 03 Apr 2018 10:54:27 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Jesper Dangaard Brouer <brouer@redhat.com>
> Date: Tue, 03 Apr 2018 13:07:36 +0200
>
> > This is V9, but it's worth mentioning that V8 was send against
> > net-next, because i40e got XDP_REDIRECT support in-between V6, and it
> > doesn't exist in bpf-next yet. Most significant change in V8 was that
> > page_pool only gets compiled into the kernel when a drivers Kconfig
> > 'select' the feature.
>
> Jesper, this series now looks good to me, however the net-next tree is
> closed at this point.
I noticed, but though that in-flight patchset's were still allowed...
> Don't worry, just resubmit when net-next opens back up.
At that point in time, should I got back to posting it against the
bpf-next git-tree again? Any preferences from Mellanox or BPF-guys?
... It have been a bit of a pain to keep track of driver changes in
net-next, and waiting for them to get merged into bpf-next.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: Socket error queue with timestamping and SOF_TIMESTAMPING_OPT_CMSG
From: Soheil Hassas Yeganeh @ 2018-04-03 15:51 UTC (permalink / raw)
To: Miroslav Lichvar
Cc: netdev, Willem de Bruijn, Richard Cochran, Keller, Jacob E
In-Reply-To: <20180403151928.GA22379@localhost>
On Tue, Apr 3, 2018 at 11:19 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:
>
> I came across an interesting issue with error messages in sockets with
> enabled timestamping using the SOF_TIMESTAMPING_OPT_CMSG option. When
> the socket is connected and there is an error (e.g. due to destination
> unreachable ICMP), select() indicates there is an exception on the
> socket, but recvmsg() reading from the error queue returns with EAGAIN
> and the application gets stuck in an infinite loop.
>
> Some observations:
> - it happens on both AF_INET and AF_INET6 SOCK_DGRAM sockets
> - enabling the IP_RECVERR option avoids getting EAGAIN
> - using recvmmsg() instead of recvmsg() avoids getting EAGAIN
> (that is why I didn't notice it earlier)
> - disabling TX timestamping doesn't prevent the socket from having an
> exception
> - reading from the non-error queue stops the loop
>
> Is this a bug?
POLLERR and select exceptions on an FD indicate that either (a) there
is a message on the error queue, or (b) sk_err is set. Because of (b),
it's not sufficient to only call recvmsg(MSG_ERRQUEUE). For TCP, we
must always read or write from the socket after POLLERR. For UDP,
getsockopt(SO_ERROR) would return the actual socket error and will
clear the sk_err value.
recvmmsg had a bug and was checking sk_err when we read from error
queue, before actually reading the error queue. That was really a bug
in recvmmsg which should be fixed after:
https://patchwork.ozlabs.org/patch/878861/
> It looks to me like SOF_TIMESTAMPING_OPT_CMSG implicitly, but only
> partially, enables IP_RECVERR. Are applications required to use
> IP_RECVERR in this case? My expectation was that without IP_RECVERR
> the error queue would only have messages with transmit timestamps, and
> nothing would change with reporting of real errors.
No, IP_RECVERR and SOF_TIMESTAMPING_OPT_CMSG are completely
orthogonal. When we have IP_RECVERR, the ICMP packet is simply added
to the error queue. Without IP_RECVERR, an ICMP error packet results
in setting the sk_err and the ICMP packet is discarded. This behavior is
completely unrelated to SOF_TIMESTAMPING_OPT_CMSG, and sk_err is
always set in response to ICMP packets regardless of transmit
timestamps.
Since you're only checking the error queue upon a socket
error/exception, you will need to set IP_RECVERR to make sure the ICMP
packet is kept on the error queue. You wouldn't need that if you also
check getsockopt(SO_ERROR).
> Also, from the
> documentation I had an impression that SOF_TIMESTAMPING_OPT_CMSG is a
> no-op on AF_INET6 sockets.
No, it should work for both v4 and v6.
Thanks,
Soheil
> --
> Miroslav Lichvar
^ permalink raw reply
* Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
From: Jiri Pirko @ 2018-04-03 15:42 UTC (permalink / raw)
To: David Ahern
Cc: Si-Wei Liu, mst, stephen, alexander.h.duyck, davem,
jesse.brandeburg, kubakici, jasowang, sridhar.samudrala, netdev,
virtualization, virtio-dev
In-Reply-To: <8b589cd2-1abc-59c2-99f1-96df8174bb6b@gmail.com>
Sun, Apr 01, 2018 at 06:11:29PM CEST, dsahern@gmail.com wrote:
>On 4/1/18 3:13 AM, Si-Wei Liu wrote:
>> Hidden netdevice is not visible to userspace such that
>> typical network utilites e.g. ip, ifconfig and et al,
>> cannot sense its existence or configure it. Internally
>> hidden netdev may associate with an upper level netdev
>> that userspace has access to. Although userspace cannot
>> manipulate the lower netdev directly, user may control
>> or configure the underlying hidden device through the
>> upper-level netdev. For identification purpose, the
>> kobject for hidden netdev still presents in the sysfs
>> hierarchy, however, no uevent message will be generated
>> when the sysfs entry is created, modified or destroyed.
>>
>> For that end, a separate namescope needs to be carved
>> out for IFF_HIDDEN netdevs. As of now netdev name that
>> starts with colon i.e. ':' is invalid in userspace,
>> since socket ioctls such as SIOCGIFCONF use ':' as the
>> separator for ifname. The absence of namescope started
>> with ':' can rightly be used as the namescope for
>> the kernel-only IFF_HIDDEN netdevs.
>>
>> Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
>> ---
>> include/linux/netdevice.h | 12 ++
>> include/net/net_namespace.h | 2 +
>> net/core/dev.c | 281 ++++++++++++++++++++++++++++++++++++++------
>> net/core/net_namespace.c | 1 +
>> 4 files changed, 263 insertions(+), 33 deletions(-)
>>
>
>There are other use cases that want to hide a device from userspace. I
What usecases do you have in mind?
>would prefer a better solution than playing games with name prefixes and
>one that includes an API for users to list all devices -- even ones
>hidden by default.
Netdevice hiding feels a bit scarry for me. This smells like a workaround
for userspace issues. Why can't the netdevice be visible always and
userspace would know what is it and what should it do with it?
Once we start with hiding, there are other things related to that which
appear. Like who can see what, levels of visibility etc...
>
>https://github.com/dsahern/linux/commit/48a80a00eac284e58bae04af10a5a932dd7aee00
>
>https://github.com/dsahern/iproute2/commit/7563f5b26f5539960e99066e34a995d22ea908ed
>
>Also, why are you suggesting that the device should still be visible via
>/sysfs? That leads to inconsistent views of networking state - /sys
>shows a device but a link dump does not.
^ permalink raw reply
* [PATCH iproute2] ip/l2tp: remove offset and peer-offset options
From: Guillaume Nault @ 2018-04-03 15:39 UTC (permalink / raw)
To: netdev; +Cc: James Chapman, Stephen Hemminger
Ignore options "peer-offset" and "offset" when creating sessions. Keep
them when dumping sessions in order to avoid breaking external scripts.
"peer-offset" has always been a noop in iproute2. "offset" is now
ignored in Linux 4.16 (and was broken before that).
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
---
ip/ipl2tp.c | 23 ++++-------------------
man/man8/ip-l2tp.8 | 16 ----------------
2 files changed, 4 insertions(+), 35 deletions(-)
diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index 750f912a..427e0249 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -42,8 +42,6 @@ struct l2tp_parm {
uint32_t peer_tunnel_id;
uint32_t session_id;
uint32_t peer_session_id;
- uint32_t offset;
- uint32_t peer_offset;
enum l2tp_encap_type encap;
uint16_t local_udp_port;
uint16_t peer_udp_port;
@@ -174,8 +172,6 @@ static int create_session(struct l2tp_parm *p)
if (p->reorder_timeout)
addattr64(&req.n, 1024, L2TP_ATTR_RECV_TIMEOUT,
p->reorder_timeout);
- if (p->offset)
- addattr16(&req.n, 1024, L2TP_ATTR_OFFSET, p->offset);
if (p->cookie_len)
addattr_l(&req.n, 1024, L2TP_ATTR_COOKIE,
p->cookie, p->cookie_len);
@@ -310,8 +306,8 @@ static void print_session(struct l2tp_data *data)
print_string(PRINT_FP, NULL, "%s", _SL_);
}
- print_uint(PRINT_ANY, "offset", " offset %u,", p->offset);
- print_uint(PRINT_ANY, "peer_offset", " peer offset %u\n", p->peer_offset);
+ print_uint(PRINT_ANY, "offset", " offset %u,", 0);
+ print_uint(PRINT_ANY, "peer_offset", " peer offset %u\n", 0);
if (p->cookie_len > 0)
print_cookie("cookie", "cookie",
@@ -362,8 +358,6 @@ static int get_response(struct nlmsghdr *n, void *arg)
p->pw_type = rta_getattr_u16(attrs[L2TP_ATTR_PW_TYPE]);
if (attrs[L2TP_ATTR_ENCAP_TYPE])
p->encap = rta_getattr_u16(attrs[L2TP_ATTR_ENCAP_TYPE]);
- if (attrs[L2TP_ATTR_OFFSET])
- p->offset = rta_getattr_u16(attrs[L2TP_ATTR_OFFSET]);
if (attrs[L2TP_ATTR_DATA_SEQ])
p->data_seq = rta_getattr_u16(attrs[L2TP_ATTR_DATA_SEQ]);
if (attrs[L2TP_ATTR_CONN_ID])
@@ -550,7 +544,6 @@ static void usage(void)
" tunnel_id ID\n"
" session_id ID peer_session_id ID\n"
" [ cookie HEXSTR ] [ peer_cookie HEXSTR ]\n"
- " [ offset OFFSET ] [ peer_offset OFFSET ]\n"
" [ seq { none | send | recv | both } ]\n"
" [ l2spec_type L2SPEC ]\n"
" ip l2tp del tunnel tunnel_id ID\n"
@@ -678,19 +671,11 @@ static int parse_args(int argc, char **argv, int cmd, struct l2tp_parm *p)
invarg("invalid option for udp6_csum_tx\n"
, *argv);
} else if (strcmp(*argv, "offset") == 0) {
- __u8 uval;
-
+ fprintf(stderr, "Ignoring option \"offset\"\n");
NEXT_ARG();
- if (get_u8(&uval, *argv, 0))
- invarg("invalid offset\n", *argv);
- p->offset = uval;
} else if (strcmp(*argv, "peer_offset") == 0) {
- __u8 uval;
-
+ fprintf(stderr, "Ignoring option \"peer_offset\"\n");
NEXT_ARG();
- if (get_u8(&uval, *argv, 0))
- invarg("invalid offset\n", *argv);
- p->peer_offset = uval;
} else if (strcmp(*argv, "cookie") == 0) {
int slen;
diff --git a/man/man8/ip-l2tp.8 b/man/man8/ip-l2tp.8
index 8ce630a6..9aba6bec 100644
--- a/man/man8/ip-l2tp.8
+++ b/man/man8/ip-l2tp.8
@@ -59,12 +59,6 @@ ip-l2tp - L2TPv3 static unmanaged tunnel configuration
.br
.RB "[ " seq " { " none " | " send " | " recv " | " both " } ]"
.br
-.RB "[ " offset
-.IR OFFSET
-.RB " ] [ " peer_offset
-.IR OFFSET
-.RB " ]"
-.br
.ti -8
.BR "ip l2tp del tunnel"
.B tunnel_id
@@ -285,16 +279,6 @@ Default is
.br
Valid values are:
.BR none ", " send ", " recv ", " both "."
-.TP
-.BI offset " OFFSET"
-sets the byte offset from the L2TP header where user data starts in
-transmitted L2TP data packets. This is hardly ever used. If set, the
-value must match the peer_offset value used at the peer. Default is 0.
-.TP
-.BI peer_offset " OFFSET"
-sets the byte offset from the L2TP header where user data starts in
-received L2TP data packets. This is hardly ever used. If set, the
-value must match the offset value used at the peer. Default is 0.
.SS ip l2tp del session - destroy a session
.TP
.BI tunnel_id " ID"
--
2.16.3
^ permalink raw reply related
* Re: [PATCH 02/15] ARM: pxa: add dma slave map
From: Arnd Bergmann @ 2018-04-03 15:39 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Ulf Hansson, alsa-devel, Jaroslav Kysela, IDE-ML, Networking,
linux-mtd, devel, Boris Brezillon, Vinod Koul, Richard Weinberger,
Takashi Iwai, Russell King, Marek Vasut, Ezequiel Garcia,
Linux Media Mailing List, Samuel Ortiz, Bartlomiej Zolnierkiewicz,
Haojian Zhuang, dmaengine, Mark Brown, Mauro Carvalho Chehab,
Linux ARM, Nicolas
In-Reply-To: <87tvss48ti.fsf@belgarion.home>
On Tue, Apr 3, 2018 at 5:18 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>>> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
>>> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
>>> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
>>
>> This one is interesting, as you are dealing with an off-chip device,
>> and the channel number is '-'1. How does this even work? Does it
>> mean
>
> This relies on pxa_dma, in which the "-1" for a requestor line means "no
> requestor" or said in another way "always requesting". As a consequence, as soon
> as the DMA descriptors are queued, the transfer begins, and it is supposed
> implicitely that the FIFO output availability is at least as quick as the system
> bus and the DMA size is perfectly fit for the FIFO available bytes.
>
> This is what has been the underlying of DMA transfers of smc91x(x) on the PXA
> platforms, where the smc91x(s) are directly wired on the system bus (the same
> bus having DRAM, SRAM, IO-mapped devices).
Ok, I looked at the driver in more detail now and found the scary parts.
So it's using the async DMA interface to do synchronous DMA in
interrupt context in order to transfer the rx data faster than an readsl()
would, correct?
It still feels odd to me that there is an entry in the slave map for
a device that does not have a request line. However, it also seems
that the entire code in those two drivers that deals with DMA is specific
to PXA anyway, so maybe it can be done differently: instead of
calling dma_request_slave_channel_compat() or dma_request_chan()
with a fake request line, how about calling dma_request_channel()
with an NULL filter function and data, and have the driver handle
the empty data case the same way as the rq=-1 case today?
>>> + /* PXA25x specific map */
>>> + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) },
>>> + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) },
>>> + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) },
>>> + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) },
>>> + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) },
>>> + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) },
>>> + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) },
>>> + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) },
>>> + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) },
>>> + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) },
>>> +
>>> + /* PXA27x specific map */
>>> + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) },
>>> + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) },
>>> + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) },
>>> + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) },
>>> + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) },
>>> +
>>> + /* PXA3xx specific map */
>>> + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) },
>>> + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) },
>>> + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) },
>>> + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) },
>>> + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) },
>>> + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) },
>>> + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) },
>>> +};
>>
>> Since more than half the entries in here are chip specific, maybe it would be
>> better to split that table into three and have a copy for each one in
>> arch/arm/mach-pxa/pxa{25x.27x.3xx}.c?
> Mmmh, today the split is :
> - 16 common entries
> - 10 pxa25x specific entries
> - 5 pxa27x specific entries
> - 7 pxa3xx specific entries
> => total of 38 lines
>
> After the split we'll have :
> - 26 pxa25x specific entries
> - 21 pxa27x specific entries
> - 23 pxa3xx specific entries
> => total of 70 lines
>
> That doubles the number of lines, not counting the declarations, and amending of
> pxa2xx_set_dmac_info().
>
> If you think it's worth it, what is the driving benefit behind ?
It seems a bit cleaner to only register the tables for the dma lines that
are actually present on a given chip.
>> Does that mean it's actually a memory-to-memory transfer with a device being
>> on the external SRAM interface?
> I'm taking this is the follow up to the "-1" question :0
Right.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 09/11] devlink: convert occ_get op to separate registration
From: Jiri Pirko @ 2018-04-03 15:30 UTC (permalink / raw)
To: David Ahern; +Cc: Ido Schimmel, netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <a17e5ad7-e79d-0e83-43d3-0c06b0400ed6@gmail.com>
Tue, Apr 03, 2018 at 04:33:11PM CEST, dsahern@gmail.com wrote:
>On 4/3/18 1:32 AM, Jiri Pirko wrote:
>> Fri, Mar 30, 2018 at 04:45:50PM CEST, dsahern@gmail.com wrote:
>>> On 3/29/18 2:33 PM, Ido Schimmel wrote:
>>>> From: Jiri Pirko <jiri@mellanox.com>
>>>>
>>>> This resolves race during initialization where the resources with
>>>> ops are registered before driver and the structures used by occ_get
>>>> op is initialized. So keep occ_get callbacks registered only when
>>>> all structs are initialized.
>>>
>>> Why can't the occ_get handler look at some flag in an mlxsw struct to
>>> know if the system has initialized?
>>>
>>> Separate registration here is awkward. You register a resource and then
>>> register its op later.
>>
>> The separation is exactly why this patch is made. Note that devlink
>> resouce is registered by core way before the initialization is done and
>> the driver is actually able to perform the op. Also consider "reload"
>
>That's how you have chose to code it. I hit this problem adding devlink
>to netdevsim; the solution was to fix the init order.
This is not about init order, at all. On reaload netdevs and internal
driver structures disappear and appear again. And in between currently,
the op is working with memory which is freed. That's the reason for this
patch.
>
>> case, when the resource is still registered and the driver unloads and
>> loads again. For that makes perfect sense to have that separated.
>> Flag would just make things odd. Also, the priv could not be used in
>> that case.
>>
>
>I am not aware of any other API where you invoked the register function
>at point A and then later add the operations at point B. In every API
>that comes to mind the ops are part of the register.
I think that you just don't see any similar API.
>
>I am sure there are options for you to fix the init order of mlxsw
>without making the devlink API awkward.
Again, not about init order, at all. I have no clue why you think so...
^ permalink raw reply
* Socket error queue with timestamping and SOF_TIMESTAMPING_OPT_CMSG
From: Miroslav Lichvar @ 2018-04-03 15:19 UTC (permalink / raw)
To: netdev
Cc: Willem de Bruijn, Soheil Hassas Yeganeh, Richard Cochran,
Keller, Jacob E
I came across an interesting issue with error messages in sockets with
enabled timestamping using the SOF_TIMESTAMPING_OPT_CMSG option. When
the socket is connected and there is an error (e.g. due to destination
unreachable ICMP), select() indicates there is an exception on the
socket, but recvmsg() reading from the error queue returns with EAGAIN
and the application gets stuck in an infinite loop.
Some observations:
- it happens on both AF_INET and AF_INET6 SOCK_DGRAM sockets
- enabling the IP_RECVERR option avoids getting EAGAIN
- using recvmmsg() instead of recvmsg() avoids getting EAGAIN
(that is why I didn't notice it earlier)
- disabling TX timestamping doesn't prevent the socket from having an
exception
- reading from the non-error queue stops the loop
Is this a bug?
It looks to me like SOF_TIMESTAMPING_OPT_CMSG implicitly, but only
partially, enables IP_RECVERR. Are applications required to use
IP_RECVERR in this case? My expectation was that without IP_RECVERR
the error queue would only have messages with transmit timestamps, and
nothing would change with reporting of real errors. Also, from the
documentation I had an impression that SOF_TIMESTAMPING_OPT_CMSG is a
no-op on AF_INET6 sockets.
--
Miroslav Lichvar
^ permalink raw reply
* Re: [PATCH 02/15] ARM: pxa: add dma slave map
From: Robert Jarzmik @ 2018-04-03 15:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ulf Hansson, alsa-devel, Jaroslav Kysela, IDE-ML, Networking,
linux-mtd, devel, Boris Brezillon, Vinod Koul, Richard Weinberger,
Takashi Iwai, Russell King, Linux Kernel Mailing List,
Marek Vasut, Ezequiel Garcia, Linux Media Mailing List,
Samuel Ortiz, Bartlomiej Zolnierkiewicz, Haojian Zhuang,
dmaengine, Mark Brown, Mauro Carvalho Chehab
In-Reply-To: <CAK8P3a3pSitVqfiF2LK0cMrAKLOeCWXXJBLeVc5f_Tg=vALkUA@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> writes:
>> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
>> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
>> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
>
> This one is interesting, as you are dealing with an off-chip device,
> and the channel number is '-'1. How does this even work? Does it
> mean
This relies on pxa_dma, in which the "-1" for a requestor line means "no
requestor" or said in another way "always requesting". As a consequence, as soon
as the DMA descriptors are queued, the transfer begins, and it is supposed
implicitely that the FIFO output availability is at least as quick as the system
bus and the DMA size is perfectly fit for the FIFO available bytes.
This is what has been the underlying of DMA transfers of smc91x(x) on the PXA
platforms, where the smc91x(s) are directly wired on the system bus (the same
bus having DRAM, SRAM, IO-mapped devices).
>
>> + /* PXA25x specific map */
>> + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) },
>> + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) },
>> + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) },
>> + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) },
>> + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) },
>> + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) },
>> + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) },
>> + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) },
>> + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) },
>> + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) },
>> +
>> + /* PXA27x specific map */
>> + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) },
>> + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) },
>> + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) },
>> + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) },
>> + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) },
>> +
>> + /* PXA3xx specific map */
>> + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) },
>> + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) },
>> + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) },
>> + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) },
>> + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) },
>> + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) },
>> + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) },
>> +};
>
> Since more than half the entries in here are chip specific, maybe it would be
> better to split that table into three and have a copy for each one in
> arch/arm/mach-pxa/pxa{25x.27x.3xx}.c?
Mmmh, today the split is :
- 16 common entries
- 10 pxa25x specific entries
- 5 pxa27x specific entries
- 7 pxa3xx specific entries
=> total of 38 lines
After the split we'll have :
- 26 pxa25x specific entries
- 21 pxa27x specific entries
- 23 pxa3xx specific entries
=> total of 70 lines
That doubles the number of lines, not counting the declarations, and amending of
pxa2xx_set_dmac_info().
If you think it's worth it, what is the driving benefit behind ?
> Does that mean it's actually a memory-to-memory transfer with a device being
> on the external SRAM interface?
I'm taking this is the follow up to the "-1" question :0
Cheers.
--
Robert
^ permalink raw reply
* Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps
From: Ulf Hansson @ 2018-04-03 15:08 UTC (permalink / raw)
To: Robert Jarzmik
Cc: alsa-devel, Jaroslav Kysela, linux-ide, netdev, linux-mtd,
driverdevel, Boris Brezillon, Vinod Koul, Richard Weinberger,
Takashi Iwai, Marek Vasut, Ezequiel Garcia, linux-media,
Samuel Ortiz, Arnd Bergmann, Bartlomiej Zolnierkiewicz,
Haojian Zhuang, dmaengine, Mark Brown, Mauro Carvalho Chehab,
Linux ARM, Nicolas Pitre, Greg Kroah-Hartman,
"linux-mmc@vger.ke
In-Reply-To: <20180402142656.26815-1-robert.jarzmik@free.fr>
On 2 April 2018 at 16:26, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Hi,
>
> This serie is aimed at removing the dmaengine slave compat use, and transfer
> knowledge of the DMA requestors into architecture code.
>
> This was discussed/advised by Arnd a couple of years back, it's almost time.
>
> The serie is divided in 3 phasees :
> - phase 1 : patch 1/15 and patch 2/15
> => this is the preparation work
> - phase 2 : patches 3/15 .. 10/15
> => this is the switch of all the drivers
> => this one will require either an Ack of the maintainers or be taken by them
> once phase 1 is merged
> - phase 3 : patches 11/15
> => this is the last part, cleanup and removal of export of the DMA filter
> function
>
> As this looks like a patch bomb, each maintainer expressing for his tree either
> an Ack or "I want to take through my tree" will be spared in the next iterations
> of this serie.
Perhaps an option is to send this hole series as PR for 3.17 rc1, that
would removed some churns and make this faster/easier? Well, if you
receive the needed acks of course.
For the mmc change:
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
>
> Several of these changes have been tested on actual hardware, including :
> - pxamci
> - pxa_camera
> - smc*
> - ASoC and SSP
>
> Happy review.
>
> Robert Jarzmik (15):
> dmaengine: pxa: use a dma slave map
> ARM: pxa: add dma slave map
> mmc: pxamci: remove the dmaengine compat need
> media: pxa_camera: remove the dmaengine compat need
> mtd: nand: pxa3xx: remove the dmaengine compat need
> net: smc911x: remove the dmaengine compat need
> net: smc91x: remove the dmaengine compat need
> ASoC: pxa: remove the dmaengine compat need
> net: irda: pxaficp_ir: remove the dmaengine compat need
> ata: pata_pxa: remove the dmaengine compat need
> dmaengine: pxa: document pxad_param
> dmaengine: pxa: make the filter function internal
> ARM: pxa: remove the DMA IO resources
> ARM: pxa: change SSP devices allocation
> ARM: pxa: change SSP DMA channels allocation
>
> arch/arm/mach-pxa/devices.c | 269 ++++++++++++++----------------
> arch/arm/mach-pxa/devices.h | 14 +-
> arch/arm/mach-pxa/include/mach/audio.h | 12 ++
> arch/arm/mach-pxa/pxa25x.c | 4 +-
> arch/arm/mach-pxa/pxa27x.c | 4 +-
> arch/arm/mach-pxa/pxa3xx.c | 5 +-
> arch/arm/plat-pxa/ssp.c | 50 +-----
> drivers/ata/pata_pxa.c | 10 +-
> drivers/dma/pxa_dma.c | 13 +-
> drivers/media/platform/pxa_camera.c | 22 +--
> drivers/mmc/host/pxamci.c | 29 +---
> drivers/mtd/nand/pxa3xx_nand.c | 10 +-
> drivers/net/ethernet/smsc/smc911x.c | 16 +-
> drivers/net/ethernet/smsc/smc91x.c | 12 +-
> drivers/net/ethernet/smsc/smc91x.h | 1 -
> drivers/staging/irda/drivers/pxaficp_ir.c | 14 +-
> include/linux/dma/pxa-dma.h | 20 +--
> include/linux/platform_data/mmp_dma.h | 4 +
> include/linux/pxa2xx_ssp.h | 4 +-
> sound/arm/pxa2xx-ac97.c | 14 +-
> sound/arm/pxa2xx-pcm-lib.c | 6 +-
> sound/soc/pxa/pxa-ssp.c | 5 +-
> sound/soc/pxa/pxa2xx-ac97.c | 32 +---
> 23 files changed, 196 insertions(+), 374 deletions(-)
>
> --
> 2.11.0
>
^ 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