* [PATCH 5/5] ISDN-CAPI: Delete unnecessary braces
From: SF Markus Elfring @ 2016-09-25 11:15 UTC (permalink / raw)
To: netdev, Karsten Keil; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <be07f84d-fc84-e47d-207e-aedd8c960151@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 25 Sep 2016 12:50:21 +0200
Do not use curly brackets at eight source code places
where a single statement should be sufficient.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/isdn/capi/capidrv.c | 30 +++++++++++-------------------
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index 83f756d..7f58644 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -470,9 +470,8 @@ static int capidrv_add_ack(struct capidrv_ncci *nccip,
struct ncci_datahandle_queue *n, **pp;
n = kmalloc(sizeof(struct ncci_datahandle_queue), GFP_ATOMIC);
- if (!n) {
+ if (!n)
return -1;
- }
n->next = NULL;
n->datahandle = datahandle;
n->len = len;
@@ -511,9 +510,8 @@ static void send_message(capidrv_contr *card, _cmsg *cmsg)
}
len = CAPIMSG_LEN(cmsg->buf);
skb = alloc_skb(len, GFP_ATOMIC);
- if (!skb) {
+ if (!skb)
return;
- }
memcpy(skb_put(skb, len), cmsg->buf, len);
if (capi20_put_message(&global.ap, skb) != CAPI_NOERROR)
kfree_skb(skb);
@@ -976,13 +974,12 @@ static void handle_controller(_cmsg *cmsg)
if (debugmode)
printk(KERN_DEBUG "capidrv-%d: listenconf Info=0x%4x (%s) cipmask=0x%x\n",
card->contrnr, cmsg->Info, capi_info2str(cmsg->Info), card->cipmask);
- if (cmsg->Info) {
+ if (cmsg->Info)
listen_change_state(card, EV_LISTEN_CONF_ERROR);
- } else if (card->cipmask == 0) {
+ else if (card->cipmask == 0)
listen_change_state(card, EV_LISTEN_CONF_EMPTY);
- } else {
+ else
listen_change_state(card, EV_LISTEN_CONF_OK);
- }
break;
case CAPI_MANUFACTURER_IND: /* Controller */
@@ -1263,11 +1260,10 @@ static void handle_plci(_cmsg *cmsg)
goto notfound;
plcip->plci = cmsg->adr.adrPLCI;
- if (cmsg->Info) {
+ if (cmsg->Info)
plci_change_state(card, plcip, EV_PLCI_CONNECT_CONF_ERROR);
- } else {
+ else
plci_change_state(card, plcip, EV_PLCI_CONNECT_CONF_OK);
- }
break;
case CAPI_CONNECT_ACTIVE_IND: /* plci */
@@ -1476,10 +1472,9 @@ static void handle_ncci(_cmsg *cmsg)
goto ignored;
case CAPI_DATA_B3_CONF: /* ncci */
- if (cmsg->Info) {
+ if (cmsg->Info)
printk(KERN_WARNING "CAPI_DATA_B3_CONF: Info %x - %s\n",
cmsg->Info, capi_info2str(cmsg->Info));
- }
nccip = find_ncci(card, cmsg->adr.adrNCCI);
if (!nccip)
goto notfound;
@@ -2319,9 +2314,8 @@ static int capidrv_addcontr(u16 contr, struct capi_profile *profp)
}
card->myid = card->interface.channels;
memset(card->bchans, 0, sizeof(capidrv_bchan) * card->nbchan);
- for (i = 0; i < card->nbchan; i++) {
+ for (i = 0; i < card->nbchan; i++)
card->bchans[i].contr = card;
- }
spin_lock_irqsave(&global_lock, flags);
card->next = global.contr_list;
@@ -2354,10 +2348,9 @@ static int capidrv_delcontr(u16 contr)
isdn_ctrl cmd;
spin_lock_irqsave(&global_lock, flags);
- for (card = global.contr_list; card; card = card->next) {
+ for (card = global.contr_list; card; card = card->next)
if (card->contrnr == contr)
break;
- }
if (!card) {
spin_unlock_irqrestore(&global_lock, flags);
printk(KERN_ERR "capidrv: delcontr: no contr %u\n", contr);
@@ -2504,9 +2497,8 @@ static int __init capidrv_init(void)
global.ap.recv_message = capidrv_recv_message;
errcode = capi20_register(&global.ap);
- if (errcode) {
+ if (errcode)
return -EIO;
- }
register_capictr_notifier(&capictr_nb);
--
2.10.0
^ permalink raw reply related
* Re: [PATCH 5/5] ISDN-CAPI: Delete unnecessary braces
From: Sergei Shtylyov @ 2016-09-25 11:18 UTC (permalink / raw)
To: SF Markus Elfring, netdev, Karsten Keil
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <06e7637c-f682-bfa2-82b6-47d071bd58c4@users.sourceforge.net>
Hello.
On 9/25/2016 2:15 PM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 25 Sep 2016 12:50:21 +0200
>
> Do not use curly brackets at eight source code places
> where a single statement should be sufficient.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/isdn/capi/capidrv.c | 30 +++++++++++-------------------
> 1 file changed, 11 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
> index 83f756d..7f58644 100644
> --- a/drivers/isdn/capi/capidrv.c
> +++ b/drivers/isdn/capi/capidrv.c
[...]
> @@ -976,13 +974,12 @@ static void handle_controller(_cmsg *cmsg)
> if (debugmode)
> printk(KERN_DEBUG "capidrv-%d: listenconf Info=0x%4x (%s) cipmask=0x%x\n",
> card->contrnr, cmsg->Info, capi_info2str(cmsg->Info), card->cipmask);
> - if (cmsg->Info) {
> + if (cmsg->Info)
> listen_change_state(card, EV_LISTEN_CONF_ERROR);
> - } else if (card->cipmask == 0) {
> + else if (card->cipmask == 0)
> listen_change_state(card, EV_LISTEN_CONF_EMPTY);
> - } else {
> + else
Indented too much.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH nf-next v3 0/7] Compact netfilter hooks list
From: Pablo Neira Ayuso @ 2016-09-25 11:30 UTC (permalink / raw)
To: Aaron Conole; +Cc: netfilter-devel, netdev, Florian Westphal
In-Reply-To: <1474472107-12992-1-git-send-email-aconole@bytheb.org>
On Wed, Sep 21, 2016 at 11:35:00AM -0400, Aaron Conole wrote:
> This series makes a simple change to shrink the netfilter hook list
> from a double linked list, to a singly linked list. Since the hooks
> are always traversed in-order, there is no need to maintain a previous
> pointer.
>
> This was jointly developed by Florian Westphal.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH nf v5] netfilter: seqadj: Fix the wrong ack adjust for the RST packet without ack
From: Pablo Neira Ayuso @ 2016-09-25 11:31 UTC (permalink / raw)
To: fgao; +Cc: kaber, netfilter-devel, netdev, gfree.wind
In-Reply-To: <1474527233-21988-1-git-send-email-fgao@ikuai8.com>
On Thu, Sep 22, 2016 at 02:53:53PM +0800, fgao@ikuai8.com wrote:
> From: Gao Feng <fgao@ikuai8.com>
>
> It is valid that the TCP RST packet which does not set ack flag, and bytes
> of ack number are zero. But current seqadj codes would adjust the "0" ack
> to invalid ack number. Actually seqadj need to check the ack flag before
> adjust it for these RST packets.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Jamal Hadi Salim @ 2016-09-25 11:32 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Tom Herbert, davem, netdev, kernel-team, tariqt, bblanco,
alexei.starovoitov, eric.dumazet, Thomas Graf
In-Reply-To: <20160923150040.0e3dc7d5@redhat.com>
On 16-09-23 09:00 AM, Jesper Dangaard Brouer wrote:
> On Fri, 23 Sep 2016 07:13:30 -0400
> Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
[..]
>> Tom,
>> perused the thread and it seems you are serious ;->
>> Are we heading towards Frankenstein Avenue?
>> The whole point behind letting in XDP is so that _small programs_
>> can be written to do some quick thing. eBPF 4K program limit was
>> touted as the check and bound. eBPF sounded fine.
>> This sounds like a huge contradiction.
>>
>> cheers,
>> jamal
>
> Hi Jamal,
>
> I don't understand why you think this is so controversial. The way I
> see it (after reading the thread): This is about allowing kernel
> components to _also_ use the XDP hook.
>
The initial push was XDP to support very small programs that did
very simple things fast (to be extreme: for example running a whole
network stack is a no-no). EBPF with the 4K program limit was pointed
as the limit.
What Tom is presenting is implying this constraint is now being
removed. Thats the controversy.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v3 2/2] netfilter: Create revision 2 of xt_hashlimit to support higher pps rates
From: Pablo Neira Ayuso @ 2016-09-25 11:35 UTC (permalink / raw)
To: Vishwanath Pai
Cc: Jan Engelhardt, kaber, kadlec, johunt, netfilter-devel, coreteam,
netdev, pai.vishwain
In-Reply-To: <57E42571.1060502@akamai.com>
On Thu, Sep 22, 2016 at 02:39:45PM -0400, Vishwanath Pai wrote:
> Thanks for pointing this out, I will reorder the fields to:
>
> struct hashlimit_cfg2 {
> __u64 avg; /* Average secs between packets * scale */
> __u64 burst;
> __u32 mode; /* bitmask of XT_HASHLIMIT_HASH_* */
>
> This should fix the hole and avoid padding.
I have manually mangled this here, and applied, to get this change in
this in merge window.
I also have to revert the rename of XT_HASHLIMIT_SCALE to
XT_HASHLIMIT_SCALE_v1. This is exposed through uapi, this change would
break userspace.
Please, follow up in case of any fallout, thanks.
^ permalink raw reply
* RE: [PATCH net 0/2] Fix tc-ife bugs
From: Yotam Gigi @ 2016-09-25 11:41 UTC (permalink / raw)
To: jhs@mojatatu.com, davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1474548926-22815-1-git-send-email-yotamg@mellanox.com>
>-----Original Message-----
>From: Yotam Gigi
>Sent: Thursday, September 22, 2016 3:55 PM
>To: jhs@mojatatu.com; davem@davemloft.net; netdev@vger.kernel.org
>Cc: Yotam Gigi <yotamg@mellanox.com>
>Subject: [PATCH net 0/2] Fix tc-ife bugs
>
>This patch-set contains two bugfixes in the tc-ife action, one fixing some
>random behaviour in encode side, and one fixing the decode side packet
>parsing logic.
I have to rebase the patches. I will send v2 soon.
Thanks!
>
>Yotam Gigi (2):
> act_ife: Fix external mac header on encode
> act_ife: Fix false parsing on decode side
>
> net/sched/act_ife.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
>--
>2.4.11
^ permalink raw reply
* Re: [PATCH] netfilter: xt_socket: fix transparent match for IPv6 request sockets
From: Pablo Neira Ayuso @ 2016-09-25 11:47 UTC (permalink / raw)
To: KOVACS Krisztian; +Cc: netfilter-devel, netdev, Alex Badics, Eric Dumazet
In-Reply-To: <20160923092742.88262-1-hidden@balabit.com>
On Fri, Sep 23, 2016 at 11:27:42AM +0200, KOVACS Krisztian wrote:
> The introduction of TCP_NEW_SYN_RECV state, and the addition of request
> sockets to the ehash table seems to have broken the --transparent option
> of the socket match for IPv6 (around commit a9407000).
>
> Now that the socket lookup finds the TCP_NEW_SYN_RECV socket instead of the
> listener, the --transparent option tries to match on the no_srccheck flag
> of the request socket.
>
> Unfortunately, that flag was only set for IPv4 sockets in tcp_v4_init_req()
> by copying the transparent flag of the listener socket. This effectively
> causes '-m socket --transparent' not match on the ACK packet sent by the
> client in a TCP handshake.
>
> Based on the suggestion from Eric Dumazet, this change moves the code
> initializing no_srccheck to tcp_conn_request(), rendering the above
> scenario working again.
Applied, thanks Krisztian.
^ permalink raw reply
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Jamal Hadi Salim @ 2016-09-25 12:29 UTC (permalink / raw)
To: Tom Herbert
Cc: David S. Miller, Linux Kernel Network Developers, Kernel Team,
Tariq Toukan, Brenden Blanco, Alexei Starovoitov, Eric Dumazet,
Jesper Dangaard Brouer
In-Reply-To: <CALx6S36rFUaaeFU4sE7gNaPn2Jxf-FaOESy_rrDpLKRx-SWkDA@mail.gmail.com>
On 16-09-23 10:14 AM, Tom Herbert wrote:
> On Fri, Sep 23, 2016 at 4:13 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> On 16-09-20 06:00 PM, Tom Herbert wrote:
>> Tom,
>> perused the thread and it seems you are serious ;->
>> Are we heading towards Frankenstein Avenue?
>
> I'm surprised. I thought you'd like democratizing an interface. :-)
>
I do;-> challenge here is the worry about the classical camel's nose
metaphor[1]. The original intent was for simplicity. Do one very
simple thing. Do it fast.
Note: this is code that is sitting in a critical driver path
[Democratizing the interfaces is a bigger scope discussion we can have
not just for XDP but tc, netfilter etc.]
>> The whole point behind letting in XDP is so that _small programs_
>> can be written to do some quick thing. eBPF 4K program limit was
>> touted as the check and bound. eBPF sounded fine.
>> This sounds like a huge contradiction.
>
> Jamal, thanks for the feedback.
>
> IMO, XDP != BPF. XDP is an interface in drivers that allow raw packet
> processing in the receive path,. This is akin to DPDK in the kernel.
Understood.
Most of these DPDK apps do simple things. EX: show ILA forwarding with
high throughput on a single core - which can be achieved with XDP as is
right now. With DPDK you start doing more generic things and shit starts
slowing down. We can have the best of both worlds In Linux (with 2-3
other modular interfaces above XDP).
Getting both {performance, flexibility} is hard. Add a third dimension
of usability and everything starts spiralling on the z-axis.
i.e pick one and a quarter of those 3 features; anything else is a
an art project. Example: you start adding flexibility we will no doubt
need a northbound control interface, etc.
So I see XDP as this "fast and specific blob" and things above are more
generic.
Our biggest issue, as the netmap and other folks have shown,
is the obesity of the skb. On XDP, I would bet things
get faster because there is no skb - the danger is turning it into
"move your stack to XDP to avoid skbs"
> BPF is critical use case of the interface.
> As for the 4K limit that still allows for a lot of damage and abuse
> that the user can do with a loadable program and, yes, code in the
> kernel can do significant damage as well.
But we have at least a handwavy insurance limit.
A determined person could circumvent the limit - but it is more a
deterrent than enforcement.
> However, unlike BPF programs
> being set from userspace, kernel code has a well established process
> for acceptance, any suggested code gets review, and if it's going
> "Frankenstein Avenue" I'd expect it to be rejected. I get a little
> worried that we are going to start artificially limiting what we can
> do in the kernel on the basis that we don't trust kernel programmers
> to be competent enough not to abuse kernel interfaces-- the fact that
> we are enabling userspace to arbitrarily program the kernel but
> purposely limiting what the kernel itself can do would be a huge irony
> to me.
My concern is not incompentency. We already allow people to shoot
their little finger if they want to. And just to be clear I am
not concerned with allowing other people to save the world their
way ;->
So lets say we said ebpf was one use case:
If you wrote an XDP "app" in plain C, could you still enforce this
limit so bigcorp doesnt start building islands around Linux?
Again, the camel metaphor applies.
Note, comparison with kernel modules at tc or netfilter hooks doesnt
apply because:
a) it is a lot harder to avoid kernel interfaces (skbs etc) in those
places. XDP for example totally avoids the skb. So contributing to the
Linux base is a given with kernel modules.
b) Programs that are usable as kernel modules tend to be geared towards
inclusion into the kernel because of the complexity. It is more
maintainance to keep them off tree.
XDP is such a simple interface that the opportunity to move a whole
DPDK-like industry into the kernel is huge (at the detriment of the
Linux kernel networking).
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v5 02/16] IB/pvrdma: Add user-level shared functions
From: Leon Romanovsky @ 2016-09-25 12:29 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford, linux-rdma, pv-drivers, netdev, linux-pci, jhansen,
asarwade, georgezhang, bryantan
In-Reply-To: <20160925072624.GV4088@leon.nu>
[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]
On Sun, Sep 25, 2016 at 10:26:24AM +0300, Leon Romanovsky wrote:
<...>
> > +
> > +/* PVRDMA send queue work request */
> > +struct pvrdma_sq_wqe_hdr {
> > + __u64 wr_id; /* wr id */
> > + __u32 num_sge; /* size of s/g array */
> > + __u32 total_len; /* reserved */
> > + __u32 opcode; /* operation type */
> > + __u32 send_flags; /* wr flags */
> > + union {
> > + __u32 imm_data;
> > + __u32 invalidate_rkey;
> > + } ex;
> > + __u32 reserved;
> > + union {
> > + struct {
> > + __u64 remote_addr;
> > + __u32 rkey;
> > + __u8 reserved[4];
> > + } rdma;
> > + struct {
> > + __u64 remote_addr;
> > + __u64 compare_add;
> > + __u64 swap;
> > + __u32 rkey;
> > + __u32 reserved;
> > + } atomic;
> > + struct {
> > + __u64 remote_addr;
> > + __u32 log_arg_sz;
> > + __u32 rkey;
> > + union {
> > + struct pvrdma_exp_cmp_swap cmp_swap;
> > + struct pvrdma_exp_fetch_add fetch_add;
> > + } wr_data;
> > + } masked_atomics;
> > + struct {
> > + __u64 iova_start;
> > + __u64 pl_pdir_dma;
> > + __u32 page_shift;
> > + __u32 page_list_len;
> > + __u32 length;
> > + __u32 access_flags;
> > + __u32 rkey;
> > + } fast_reg;
> > + struct {
> > + __u32 remote_qpn;
> > + __u32 remote_qkey;
> > + struct pvrdma_av av;
> > + } ud;
> > + } wr;
> > +};
>
> No, I have half-baked patch series which refactors this structure in kernel.
Sorry, this patch series is not needed in kernel.
> There is no need to put this structure in UAPI.
This is still relevant.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net v2 0/2] Fix tc-ife bugs
From: Yotam Gigi @ 2016-09-25 12:31 UTC (permalink / raw)
To: jhs, davem, netdev, yotamg
This patch-set contains two bugfixes in the tc-ife action, one fixing some
random behaviour in encode side, and one fixing the decode side packet
parsing logic.
Yotam Gigi (2):
act_ife: Fix external mac header on encode
act_ife: Fix false parsing on decode side
net/sched/act_ife.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--
2.4.11
^ permalink raw reply
* [PATCH net v2 1/2] act_ife: Fix external mac header on encode
From: Yotam Gigi @ 2016-09-25 12:31 UTC (permalink / raw)
To: jhs, davem, netdev, yotamg
In-Reply-To: <1474806711-64660-1-git-send-email-yotamg@mellanox.com>
On ife encode side, external mac header is copied from the original packet
and may be overridden if the user requests. Before, the mac header copy
was done from memory region that might not be accessible anymore, as
skb_cow_head might free it and copy the packet. This led to random values
in the external mac header once the values were not set by user.
This fix takes the internal mac header from the packet, after the call to
skb_cow_head.
Fixes: ef6980b6becb ("net sched: introduce IFE action")
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
---
net/sched/act_ife.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
index ccf7b4b..b949d97 100644
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -766,8 +766,6 @@ static int tcf_ife_encode(struct sk_buff *skb, const struct tc_action *a,
return TC_ACT_SHOT;
}
- iethh = eth_hdr(skb);
-
err = skb_cow_head(skb, hdrm);
if (unlikely(err)) {
ife->tcf_qstats.drops++;
@@ -778,6 +776,7 @@ static int tcf_ife_encode(struct sk_buff *skb, const struct tc_action *a,
if (!(at & AT_EGRESS))
skb_push(skb, skb->dev->hard_header_len);
+ iethh = (struct ethhdr *)skb->data;
__skb_push(skb, hdrm);
memcpy(skb->data, iethh, skb->mac_len);
skb_reset_mac_header(skb);
--
2.4.11
^ permalink raw reply related
* [PATCH net v2 2/2] act_ife: Fix false parsing on decode side
From: Yotam Gigi @ 2016-09-25 12:31 UTC (permalink / raw)
To: jhs, davem, netdev, yotamg
In-Reply-To: <1474806711-64660-1-git-send-email-yotamg@mellanox.com>
On ife decode side, the action iterates over the tlvs in the ife header
and parses them one by one, where in each iteration the current pointer is
advanced according to the tlv size.
Before, the pointer was advanced in a wrong way, as the tlv type and size
bytes were not taken into account. This led to false parsing of ife
header. In addition, due to the fact that the loop counter was unsigned,
it could lead to infinite parsing loop.
This fix changes the loop counter to be signed and fixes the parsing to
take into account the tlv type and size.
Fixes: ef6980b6becb ("net sched: introduce IFE action")
Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
---
net/sched/act_ife.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
index b949d97..1a055ea 100644
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -653,7 +653,7 @@ static int tcf_ife_decode(struct sk_buff *skb, const struct tc_action *a,
struct tcf_ife_info *ife = to_ife(a);
int action = ife->tcf_action;
struct ifeheadr *ifehdr = (struct ifeheadr *)skb->data;
- u16 ifehdrln = ifehdr->metalen;
+ int ifehdrln = (int)ifehdr->metalen;
struct meta_tlvhdr *tlv = (struct meta_tlvhdr *)(ifehdr->tlv_data);
spin_lock(&ife->tcf_lock);
@@ -694,8 +694,8 @@ static int tcf_ife_decode(struct sk_buff *skb, const struct tc_action *a,
ife->tcf_qstats.overlimits++;
}
- tlvdata += alen;
- ifehdrln -= alen;
+ tlvdata += alen + sizeof(struct meta_tlvhdr);
+ ifehdrln -= alen + sizeof(struct meta_tlvhdr);
tlv = (struct meta_tlvhdr *)tlvdata;
}
--
2.4.11
^ permalink raw reply related
* pull request: bluetooth-next 2016-09-25
From: Johan Hedberg @ 2016-09-25 12:42 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
Hi Dave,
Here are a few more Bluetooth & 802.15.4 patches for the 4.9 kernel that
have popped up during the past week:
- New USB ID for QCA_ROME Bluetooth device
- NULL pointer dereference fix for Bluetooth mgmt sockets
- Fixes for BCSP driver
- Fix for updating LE scan response
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit cdd0766d7da19085e88df86d1e5e21d9fe3d374f:
Merge branch 'ftgmac100-ast2500-support' (2016-09-22 03:31:22 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
for you to fetch changes up to 056506944a58814e5767d55ef6389aa2ab06908c:
Bluetooth: Use single return in hci_uart_tty_ioctl() call (2016-09-24 06:40:24 +0200)
----------------------------------------------------------------
Arek Lichwa (1):
Bluetooth: Fix NULL pointer dereference in mgmt context
Dean Jenkins (2):
Bluetooth: Tidy-up coding style in hci_bcsp.c
Bluetooth: BCSP fails to ACK re-transmitted frames from the peer
Dmitry Tunin (1):
Bluetooth: Add a new 04ca:3011 QCA_ROME device
Laura Abbott (1):
Bluetooth: btwilink: Save the packet type before sending
Michał Narajowski (1):
Bluetooth: Fix not updating scan rsp when adv off
Vignesh Raman (1):
Bluetooth: Use single return in hci_uart_tty_ioctl() call
drivers/bluetooth/btusb.c | 1 +
drivers/bluetooth/btwilink.c | 4 +-
drivers/bluetooth/hci_bcsp.c | 128 ++++++++++++++++++++---------------
drivers/bluetooth/hci_ldisc.c | 28 ++++----
net/bluetooth/mgmt.c | 4 +-
5 files changed, 96 insertions(+), 69 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] ISDN-CAPI: Delete unnecessary braces
From: SF Markus Elfring @ 2016-09-25 12:47 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, Karsten Keil, LKML, kernel-janitors, Julia Lawall
In-Reply-To: <52dd5000-2bda-a1b6-aa97-1868e1193d35@cogentembedded.com>
>> @@ -976,13 +974,12 @@ static void handle_controller(_cmsg *cmsg)
>> if (debugmode)
>> printk(KERN_DEBUG "capidrv-%d: listenconf Info=0x%4x (%s) cipmask=0x%x\n",
>> card->contrnr, cmsg->Info, capi_info2str(cmsg->Info), card->cipmask);
>> - if (cmsg->Info) {
>> + if (cmsg->Info)
>> listen_change_state(card, EV_LISTEN_CONF_ERROR);
>> - } else if (card->cipmask == 0) {
>> + else if (card->cipmask == 0)
>> listen_change_state(card, EV_LISTEN_CONF_EMPTY);
>> - } else {
>> + else
>
> Indented too much.
How do you think about an alignment of this "else"
with the corresponding if statement three lines above?
Regards,
Markus
^ permalink raw reply
* (unknown)
From: David Miller @ 2016-09-25 12:51 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, ek, lorenzo
In-Reply-To: <1474800749-2306-1-git-send-email-zenczykowski@gmail.com>
This posting needs an actual Subject line, saying something like:
[PATCH net-next v3 0/7] Add RFC7559 style ipv6 soliciation backoff support
This text will go into the merge commit I create should I apply
this patch series.
In any event, using a blank Subject line is never appropriate.
^ permalink raw reply
* Re: [PATCH v3 2/2] netfilter: Create revision 2 of xt_hashlimit to support higher pps rates
From: Pablo Neira Ayuso @ 2016-09-25 12:58 UTC (permalink / raw)
To: Vishwanath Pai
Cc: Jan Engelhardt, kaber, kadlec, johunt, netfilter-devel, coreteam,
netdev, pai.vishwain
In-Reply-To: <20160925113501.GD8331@salvia>
On Sun, Sep 25, 2016 at 01:35:01PM +0200, Pablo Neira Ayuso wrote:
> On Thu, Sep 22, 2016 at 02:39:45PM -0400, Vishwanath Pai wrote:
> > Thanks for pointing this out, I will reorder the fields to:
> >
> > struct hashlimit_cfg2 {
> > __u64 avg; /* Average secs between packets * scale */
> > __u64 burst;
> > __u32 mode; /* bitmask of XT_HASHLIMIT_HASH_* */
> >
> > This should fix the hole and avoid padding.
>
> I have manually mangled this here, and applied, to get this change in
> this in merge window.
>
> I also have to revert the rename of XT_HASHLIMIT_SCALE to
> XT_HASHLIMIT_SCALE_v1. This is exposed through uapi, this change would
> break userspace.
This requires that you rebase and resubmit your userspace patches for
iptables though.
Thanks for your patience to get this in, btw.
^ permalink raw reply
* Re: [PATCH net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Jamal Hadi Salim @ 2016-09-25 13:05 UTC (permalink / raw)
To: Shmulik Ladkani
Cc: David S. Miller, WANG Cong, Eric Dumazet, netdev,
Florian Westphal
In-Reply-To: <20160923184030.75124289@halley>
On 16-09-23 11:40 AM, Shmulik Ladkani wrote:
> On Fri, 23 Sep 2016 08:48:33 -0400 Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>>> Even today, one may create loops using existing 'egress redirect',
>>> e.g. this rediculously errorneous construct:
>>>
>>> # ip l add v0 type veth peer name v0p
>>> # tc filter add dev v0p parent ffff: basic \
>>> action mirred egress redirect dev v0
>>
>> I think we actually recover from this one by eventually
>> dropping (theres a ttl field).
>
> [off topic]
>
> Don't know about that :) cpu fan got very noisy, 3 of 4 cores at 100%,
> and after one second I got:
>
> # ip -s l show type veth
> 16: v0p@v0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
> link/ether a2:64:ff:10:dd:85 brd ff:ff:ff:ff:ff:ff
> RX: bytes packets errors dropped overrun mcast
> 71660305923 469890864 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 3509 24 0 0 0 0
> 17: v0@v0p: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
> link/ether 52:a2:34:f6:7c:ec brd ff:ff:ff:ff:ff:ff
> RX: bytes packets errors dropped overrun mcast
> 3509 24 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 71660713017 469893555 0 0 0 0
>
I think this is still on topic!
Now I realize that code we took out around 4.2.x is still useful
for such a use case (I wasnt thinking about veth when Florian was
slimming the skb);
+Cc Florian W.
This snippet from 4.2:
-------------
3525 static int ing_filter(struct sk_buff *skb, struct netdev_queue *rxq)
3526 {
3527 struct net_device *dev = skb->dev;
3528 u32 ttl = G_TC_RTTL(skb->tc_verd);
3529 int result = TC_ACT_OK;
3530 struct Qdisc *q;
3531
3532 if (unlikely(MAX_RED_LOOP < ttl++)) {
3533 net_warn_ratelimited("Redir loop detected Dropping
packet (%d->%d)\n",
3534 skb->skb_iif, dev->ifindex);
3535 return TC_ACT_SHOT;
3536 }
3537
3538 skb->tc_verd = SET_TC_RTTL(skb->tc_verd, ttl);
3539 skb->tc_verd = SET_TC_AT(skb->tc_verd, AT_INGRESS);
3540
3541 q = rcu_dereference(rxq->qdisc);
3542 if (q != &noop_qdisc) {
3543 spin_lock(qdisc_lock(q));
3544 if (likely(!test_bit(__QDISC_STATE_DEACTIVATED,
&q->state)))
3545 result = qdisc_enqueue_root(skb, q);
3546 spin_unlock(qdisc_lock(q));
3547 }
3548
3549 return result;
3550 }
--------------------
MAX_RED_LOOP (stands for "Maximum Redirect loop") still exists in
current code. The idea above was that we would increment the rttl
counter once and if we saw it again upto MAX_RED_LOOP we would assume
a loop and drop the packet (at the time i didnt think it was wise to
let the actions be in charge of setting the RTTL; it had to be central
core code - but it may not be neccessary)
Florian, when we discussed I said it was fine to reclaim those 3 bits
on tc verdict for RTTL at the time because i had taken out the
feature and never added it back. Your comment at the time was we can
add it back when someone shows up with the feature.
Shmulik is looking to add it.
> Similarly to all constructs injecting skbs to device rx (bond/team,
> vlan, macvlan, tunnels, ifb, __dev_forward_skb callers, etc..), we are
> obligated to assign 'skb2->dev' as the new rx device.
>
> Regarding 'skb2->skb_iif', original act_mirred code already has:
>
> skb2->skb_iif = skb->dev->ifindex; <--- THIS IS ORIG DEV IIF
> skb2->dev = dev; <--- THIS IS TARGET DEV
> err = dev_queue_xmit(skb2);
>
> I'm preserving this; OTOH the suggested modification in the patch is
>
> - err = dev_queue_xmit(skb2);
> + if (tcf_mirred_act_direction(m->tcfm_eaction) & AT_EGRESS)
> + err = dev_queue_xmit(skb2);
> + else
> + netif_receive_skb(skb2);
>
> now, the call to 'netif_receive_skb' will eventually override skb_iif to
> the target RX dev's index, upon entry to __netif_receive_skb_core.
>
> I think this IS the expected behavior - as done by other "rx injection"
> constructs.
>
Sounds fine.
I am wondering if we can have a tracing feature to show the lifetime of
the packet as it is being cycled around the kernel? It would help
debugging if some policy misbehaves.
> My doubts were around whether we should call 'dev_forward_skb' instead
> of 'netif_receive_skb'.
> The former does some things I assumed we're not interested of, like
> testing 'is_skb_forwardable' and re-running 'eth_type_trans'.
> OTOH, it DOES scrub the skb.
> Maybe we should scrub it as well prior the netif_receive_skb call?
>
Scrubbing the skb could be a bad idea if it gets rid of global state
like the RTTL if you add it back.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Jamal Hadi Salim @ 2016-09-25 13:39 UTC (permalink / raw)
To: Cong Wang, Shmulik Ladkani
Cc: David S. Miller, Eric Dumazet, Linux Kernel Network Developers,
Florian Westphal
In-Reply-To: <CAM_iQpU+7NDoGGPkkDHA=v5XW5z98GHQhstFg5H=WCyiBzA-eA@mail.gmail.com>
On 16-09-24 08:07 PM, Cong Wang wrote:
> On Thu, Sep 22, 2016 at 10:11 PM, Shmulik Ladkani
>
> One problem to use your code for us is that, the RX side of veth
> is inside containers, not visible to outside, perhaps we need some
> more parameter to tell the netns before the device name/index?
> Thoughts?
>
Intriguing - but this would apply for only veth?
>>
>>> It may be around preventing loops maybe.
>>
>> Could be, but personally, I treat these constructs as (powerful)
>> building blocks, and "with great power comes great responsibility".
>>
>> Even today, one may create loops using existing 'egress redirect',
>> e.g. this rediculously errorneous construct:
>>
>> # ip l add v0 type veth peer name v0p
>> # tc filter add dev v0p parent ffff: basic \
>> action mirred egress redirect dev v0
>
> Detecting such loops should not be hard technically, like we do
> for reclassification. We might need some bits in skb to detect
> this specific case.
Note my other email. We had the feature but we took it out to save bits
on the skb.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net v2 0/2] Fix tc-ife bugs
From: Jamal Hadi Salim @ 2016-09-25 13:46 UTC (permalink / raw)
To: Yotam Gigi, davem, netdev, yotamg
In-Reply-To: <1474806711-64660-1-git-send-email-yotamg@mellanox.com>
On 16-09-25 08:31 AM, Yotam Gigi wrote:
> This patch-set contains two bugfixes in the tc-ife action, one fixing some
> random behaviour in encode side, and one fixing the decode side packet
> parsing logic.
>
> Yotam Gigi (2):
> act_ife: Fix external mac header on encode
> act_ife: Fix false parsing on decode side
>
> net/sched/act_ife.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
Yotam, did you run the test i proposed? I am worried about the TLV one.
Note:
Encoder includes the length of the TLV header length in the L part.
If you are reaching a conclusion that you need this in the decoding:
+ tlvdata += alen + sizeof(struct meta_tlvhdr);
then very likely whoever is sending that packet is not encoding
correctly.
cheers,
jamal
^ permalink raw reply
* [PATCH net-next] net/sched: pkt_cls: change tc actions order to be as the user sets
From: Hadar Hen Zion @ 2016-09-25 14:08 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Jamal Hadi Salim, Cong Wang, Or Gerlitz, Hadar Hen Zion
Currently the created tc actions list is reversed against the order
set by the user.
Change the actions list order to be the same as was set by the user.
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
---
include/net/pkt_cls.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index 5ccaa4b..767b03a 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -123,7 +123,7 @@ static inline void tcf_exts_to_list(const struct tcf_exts *exts,
for (i = 0; i < exts->nr_actions; i++) {
struct tc_action *a = exts->actions[i];
- list_add(&a->list, actions);
+ list_add_tail(&a->list, actions);
}
#endif
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] net/sched: pkt_cls: change tc actions order to be as the user sets
From: Jamal Hadi Salim @ 2016-09-25 14:39 UTC (permalink / raw)
To: Hadar Hen Zion, David S. Miller; +Cc: netdev, Cong Wang, Or Gerlitz
In-Reply-To: <1474812524-29089-1-git-send-email-hadarh@mellanox.com>
On 16-09-25 10:08 AM, Hadar Hen Zion wrote:
> Currently the created tc actions list is reversed against the order
> set by the user.
> Change the actions list order to be the same as was set by the user.
>
Did something break? It seems to matter most for dumping. But even that
didnt breaking. Looking at the latest net tree, i tried:
====
sudo $TC filter add dev $ETH parent 1: protocol ip prio 10 u32 \
match ip protocol 1 0xff flowid 1:2 \
action skbedit prio 33 \
action ife encode type 0xDEAD \
use mark 12 allow prio dst 02:15:15:15:15:15
Then I dump:
=====
jhs@jhs-foobar:~$ sudo $TC -s filter ls dev $ETH parent 1: protocol ip
filter pref 10 u32
filter pref 10 u32 fh 800: ht divisor 1
filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2
(rule hit 12 success 2)
match 00010000/00ff0000 at 8 (success 2 )
action order 1: skbedit priority :33
index 2 ref 1 bind 1 installed 604 sec used first 589 sec last 583 sec
Action statistics:
Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 2: ife encode action pipe type 0xDEAD
use mark 12 allow prio dst 02:15:15:15:15:15
index 2 ref 1 bind 1 installed 604 sec used first 589 sec last 583 sec
Action statistics:
Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
-----
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next] Revert "net: ethernet: bcmgenet: use phydev from struct net_device"
From: Florian Fainelli @ 2016-09-25 15:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, tremyfr, jaedon.shin
In-Reply-To: <20160925.053531.2196576594458792866.davem@davemloft.net>
Le 25/09/2016 à 02:35, David Miller a écrit :
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sat, 24 Sep 2016 20:06:12 -0700
>
>> This reverts commit 62469c76007e ("net: ethernet: bcmgenet: use phydev
>> from struct net_device") because it causes GENETv1/2/3 adapters to
>> expose the following behavior after an ifconfig down/up sequence:
>
> This breaks the conversion of this driver to ethtool ksettings.
I must be missing something here, the proposed patch passes priv->phydev
to the ethtool ksettings helpers, is there something else that needs to
be taken care of?
Sorry for being slow to understand here...
--
Florian
^ permalink raw reply
* [PATCH 0/3] ethernet: net: bcmgenet: only use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2016-09-25 15:36 UTC (permalink / raw)
To: f.fainelli, jaedon.shin, davem; +Cc: netdev, linux-kernel, Philippe Reynes
Some times ago, a serie of patches were committed :
- commit 62469c76007e ("net: ethernet: bcmgenet: use phydev from struct net_device")
- commit 6b352ebccbcf ("net: ethernet: broadcom: bcmgenet: use new api ethtool_{get|set}_link_ksettings")
The first patch add a regression on this driver, so it should be reverted.
As the second patch depend on the former, it should be reverted too.
The first patch is buggy because there is a "trick" in this driver.
The structure phydev is kept in the private data when the interface
go down, and used when the interface go up to enable the phy before
the function phy_connect is called.
I don't have this hardware, neither the datasheet. So I won't
update the driver to avoid this trick.
But the real goal of the first serie was to move to the new api
ethtool_{get|set}_link_ksettings. So I provide a new version of
the patch without the "cleaning" of driver to use the phydev
store in the net_device structure.
Jaedon Shin (1):
Revert "net: ethernet: bcmgenet: use phydev from struct net_device"
Philippe Reynes (2):
Revert "net: ethernet: bcmgenet: use new api
ethtool_{get|set}_link_ksettings"
net: ethernet: broadcom: bcmgenet: use new api
ethtool_{get|set}_link_ksettings
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 33 ++++++++++++-----------
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 1 +
drivers/net/ethernet/broadcom/genet/bcmmii.c | 24 +++++++++--------
3 files changed, 31 insertions(+), 27 deletions(-)
--
1.7.4.4
^ permalink raw reply
* [PATCH 1/3] Revert "net: ethernet: bcmgenet: use new api ethtool_{get|set}_link_ksettings"
From: Philippe Reynes @ 2016-09-25 15:36 UTC (permalink / raw)
To: f.fainelli, jaedon.shin, davem; +Cc: netdev, linux-kernel, Philippe Reynes
In-Reply-To: <1474817794-31791-1-git-send-email-tremyfr@gmail.com>
This reverts commit 6b352ebccbcf ("net: ethernet: broadcom: bcmgenet:
use new api ethtool_{get|set}_link_ksettings").
We needs to revert the commit 62469c76007e ("net: ethernet: bcmgenet:
use phydev from struct net_device"), because this commit add a
regression. As the commit 6b352ebccbcf ("net: ethernet: broadcom:
bcmgenet: use new api ethtool_{get|set}_link_ksettings") depend
on the first one, we also need to revert it first.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 2013474..46f9043 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -450,8 +450,8 @@ static inline void bcmgenet_rdma_ring_writel(struct bcmgenet_priv *priv,
genet_dma_ring_regs[r]);
}
-static int bcmgenet_get_link_ksettings(struct net_device *dev,
- struct ethtool_link_ksettings *cmd)
+static int bcmgenet_get_settings(struct net_device *dev,
+ struct ethtool_cmd *cmd)
{
if (!netif_running(dev))
return -EINVAL;
@@ -459,11 +459,11 @@ static int bcmgenet_get_link_ksettings(struct net_device *dev,
if (!dev->phydev)
return -ENODEV;
- return phy_ethtool_ksettings_get(dev->phydev, cmd);
+ return phy_ethtool_gset(dev->phydev, cmd);
}
-static int bcmgenet_set_link_ksettings(struct net_device *dev,
- const struct ethtool_link_ksettings *cmd)
+static int bcmgenet_set_settings(struct net_device *dev,
+ struct ethtool_cmd *cmd)
{
if (!netif_running(dev))
return -EINVAL;
@@ -471,7 +471,7 @@ static int bcmgenet_set_link_ksettings(struct net_device *dev,
if (!dev->phydev)
return -ENODEV;
- return phy_ethtool_ksettings_set(dev->phydev, cmd);
+ return phy_ethtool_sset(dev->phydev, cmd);
}
static int bcmgenet_set_rx_csum(struct net_device *dev,
@@ -977,6 +977,8 @@ static const struct ethtool_ops bcmgenet_ethtool_ops = {
.get_strings = bcmgenet_get_strings,
.get_sset_count = bcmgenet_get_sset_count,
.get_ethtool_stats = bcmgenet_get_ethtool_stats,
+ .get_settings = bcmgenet_get_settings,
+ .set_settings = bcmgenet_set_settings,
.get_drvinfo = bcmgenet_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_msglevel = bcmgenet_get_msglevel,
@@ -988,8 +990,6 @@ static const struct ethtool_ops bcmgenet_ethtool_ops = {
.nway_reset = bcmgenet_nway_reset,
.get_coalesce = bcmgenet_get_coalesce,
.set_coalesce = bcmgenet_set_coalesce,
- .get_link_ksettings = bcmgenet_get_link_ksettings,
- .set_link_ksettings = bcmgenet_set_link_ksettings,
};
/* Power down the unimac, based on mode. */
--
1.7.4.4
^ permalink raw reply related
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