* Re: [PATCH][net-next] net: avoid to call skb_queue_len again
From: Sergei Shtylyov @ 2014-12-08 11:28 UTC (permalink / raw)
To: Li RongQing, Eric Dumazet; +Cc: netdev
In-Reply-To: <CAJFZqHzeESfMBqb1gQr4DsE-v_fSfUX+AyWbt_VriJJ8Dj2FnA@mail.gmail.com>
Hello.
On 12/8/2014 3:46 AM, Li RongQing wrote:
>>>> From: Li RongQing <roy.qing.li@gmail.com>
>>>> the queue length of sd->input_pkt_queue has been putted into qlen,
>>> s/putted/put/, it's irregular verb.
> I will fix it and resend this patch
>>>> and impossible to change, since hold the lock
>>> I can't parse that. Who holds the lock?
>> This thread/cpu holds the lock to manipulate input_pkt_queue.
>> Otherwise, the following would break horribly....
>> __skb_queue_tail(&sd->input_pkt_queue, skb);
> Thanks Eric
I expect you to also refine the description, so that it's meaningful,
unlike now.
> -Roy
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net v2 3/5] cxgb4i: handle non-pdu-aligned rx and additional types of negative advice
From: Sergei Shtylyov @ 2014-12-08 11:36 UTC (permalink / raw)
To: kxie, linux-scsi, netdev
Cc: hariprasad, anish, hch, James.Bottomley, michaelc, davem
In-Reply-To: <201412080958.sB89wEsj005499@localhost6.localdomain6>
Hello.
On 12/8/2014 12:58 PM, kxie@chelsio.com wrote:
> [PATCH net v2 3/5] cxgb4i: handle non-pdu-aligned rx data and additional types of negative advice
The patch summary shouldn't be duplicated in the change log, at least not
like this...
> From: Karen Xie <kxie@chelsio.com>
> - abort the connection upon receiving of cpl_rx_data, which means the pdu cannot be recovered from the tcp stream. This could be due to pdu header corruption.
> - handle additional types of negative advice returned by h/w.
> Signed-off-by: Karen Xie <kxie@chelsio.com>
> ---
> drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 34 +++++++++++++++++++++++++++++++---
> 1 files changed, 31 insertions(+), 3 deletions(-)
> diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> index b834bde..051adab 100644
> --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> @@ -845,6 +845,13 @@ static void csk_act_open_retry_timer(unsigned long data)
>
> }
>
> +static inline int is_neg_adv(unsigned int status)
'bool' fits better.
> +{
> + return status == CPL_ERR_RTX_NEG_ADVICE ||
> + status == CPL_ERR_KEEPALV_NEG_ADVICE ||
> + status == CPL_ERR_PERSIST_NEG_ADVICE;
> +}
> +
[...]
> @@ -1027,6 +1033,27 @@ rel_skb:
> __kfree_skb(skb);
> }
>
> +static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
> +{
> + struct cxgbi_sock *csk;
> + struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
> + unsigned int tid = GET_TID(cpl);
> + struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
> + struct tid_info *t = lldi->tids;
> +
> + csk = lookup_tid(t, tid);
> + if (!csk) {
> + pr_err("can't find connection for tid %u.\n", tid);
> + } else {
> + /* not expecting this, reset the connection. */
> + pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
Both situations considered an error?
> + spin_lock_bh(&csk->lock);
> + send_abort_req(csk);
> + spin_unlock_bh(&csk->lock);
> + }
> + __kfree_skb(skb);
> +}
> +
> static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
> {
> struct cxgbi_sock *csk;
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rocker: remove swdev mode
From: Daniel Borkmann @ 2014-12-08 11:41 UTC (permalink / raw)
To: Jiri Pirko
Cc: Thomas Graf, roopa, sfeldma, jhs, bcrl, john.fastabend, stephen,
linville, vyasevic, netdev, davem, shm, gospo
In-Reply-To: <20141208110301.GA1885@nanopsycho.brq.redhat.com>
On 12/08/2014 12:03 PM, Jiri Pirko wrote:
> Sun, Dec 07, 2014 at 09:19:28AM CET, tgraf@suug.ch wrote:
>> On 12/06/14 at 10:54pm, roopa@cumulusnetworks.com wrote:
>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>
Please provide a normal, non-empty commit message as
everyone else ...
>>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
...
>>> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
>>> index fded127..9f1d256 100644
>>> --- a/drivers/net/ethernet/rocker/rocker.c
>>> +++ b/drivers/net/ethernet/rocker/rocker.c
>>> @@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
>>> u32 filter_mask)
>>> {
>>> struct rocker_port *rocker_port = netdev_priv(dev);
>>> - u16 mode = BRIDGE_MODE_SWDEV;
>>> + u16 mode = -1;
>> ^^^
>> I assume you meant s16
>
> well, I see no problem in using u16. IFLA_BRIDGE_MODE attr is u16 so
> mode should stay u16.
>
> But maybe better to add:
> #define BRIDGE_MODE_UNDEF 0xFFFF
Yep, something along these lines seems better.
^ permalink raw reply
* Re: [PATCH v2] sh_eth: Optimization for RX excess judgement
From: Sergei Shtylyov @ 2014-12-08 11:47 UTC (permalink / raw)
To: Yoshihiro Kaneko, netdev
Cc: David S. Miller, Simon Horman, Magnus Damm, linux-sh
In-Reply-To: <1418035701-3871-1-git-send-email-ykaneko0929@gmail.com>
Hello.
On 12/8/2014 1:48 PM, Yoshihiro Kaneko wrote:
> From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> Both of 'boguscnt' and 'quota' have nearly meaning as the condition of
> the reception loop.
> In order to cut down redundant processing, this patch changes excess
> judgement.
> Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> ---
> This patch is based on net-next tree.
> v2 [Yoshihiro Kaneko]
> * re-spin for net-next.
> * remove unneeded check of "quota".
This is not a complete list. :-/
> drivers/net/ethernet/renesas/sh_eth.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index dbe8606..266c9b2 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
[...]
> @@ -1501,6 +1499,8 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
> sh_eth_write(ndev, EDRRR_R, EDRRR);
> }
>
> + *quota -= limit - boguscnt + 1;
> +
Sorry for the wrong previous suggestion, it clearly should have been -1,
not +1. :-<
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next V1] net/mlx4_en: ethtool force speed when asking for autoneg=off
From: Saeed Mahameed @ 2014-12-08 11:42 UTC (permalink / raw)
To: David Laight
Cc: Amir Vadai, David S. Miller, netdev@vger.kernel.org, Or Gerlitz,
Yevgeny Petrilin
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA04B67@AcuExch.aculab.com>
> On Dec 8, 2014, at 12:57 PM, David Laight <David.Laight@ACULAB.COM> wrote:
>
> From: Amir Vadai
>> From: Saeed Mahameed <saeedm@mellanox.com>
>>
>> Use cmd->autoneg == AUTONEG_DISABLE as a user hint to force specific speed.
>> We don't want to rely on ethtool to calculate advertised link modes when
>> forcing specific speed, a user can request a specific speed and specify
>> "autoneg off" in ethtool command to give a hint for forcing this speed.
>
> I'm not 100% sure what you are trying to achieve?
Hey David
I am not trying to fix the operating mode of the phy with this patch.
Here i am trying to give the user the ability To let the driver choose what to advertise when user want to force a specific speed using cmd->autoneg =off .
In the driver :
If (cmd->autoneg==off) advertise_according_speed(cmd->speed)
Else advertise(cmd->advertise)
Thanks
-Saeed
> By far the safest way to 'force' a specific speed is to set the
> advertised modes to contain only the desired speed.
> Doing anything else on links that are capable of auto-negotiation
> is a complete recipe for disaster.
>
> Even if you fix the operating mode of the PHY and MAC you almost
> certainly want to advertise that mode to the remote system.
>
> Yes, I know this is made all the more complicated by 10/100M autodetect.
>
> David
>
>
>
^ permalink raw reply
* Re: [PATCH v2] sh_eth: Optimization for RX excess judgement
From: Yoshihiro Kaneko @ 2014-12-08 12:16 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, David S. Miller, Simon Horman, Magnus Damm, Linux-sh list
In-Reply-To: <54858FCD.3080206@cogentembedded.com>
Hello Sergei,
2014-12-08 20:47 GMT+09:00 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>:
> Hello.
>
> On 12/8/2014 1:48 PM, Yoshihiro Kaneko wrote:
>
>> From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>
>
>> Both of 'boguscnt' and 'quota' have nearly meaning as the condition of
>> the reception loop.
>> In order to cut down redundant processing, this patch changes excess
>> judgement.
>
>
>> Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>> ---
>
>
>> This patch is based on net-next tree.
>
>
>> v2 [Yoshihiro Kaneko]
>> * re-spin for net-next.
>> * remove unneeded check of "quota".
>
>
> This is not a complete list. :-/
Sorry, I'll update on the next time.
>
>> drivers/net/ethernet/renesas/sh_eth.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>
>
>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c
>> b/drivers/net/ethernet/renesas/sh_eth.c
>> index dbe8606..266c9b2 100644
>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>
> [...]
>>
>> @@ -1501,6 +1499,8 @@ static int sh_eth_rx(struct net_device *ndev, u32
>> intr_status, int *quota)
>> sh_eth_write(ndev, EDRRR_R, EDRRR);
>> }
>>
>> + *quota -= limit - boguscnt + 1;
>> +
>
>
> Sorry for the wrong previous suggestion, it clearly should have been -1,
> not +1. :-<
Oh, I agree.
Thanks,
Kaneko
>
> [...]
>
> WBR, Sergei
>
^ permalink raw reply
* Q: need effective backlog for listen()
From: Ulrich Windl @ 2014-12-08 12:51 UTC (permalink / raw)
To: netdev
(not subscribed to the list, plese keep me on CC:)
Hi!
I have a problem I could not find the answer. I suspect the problem arises from Linux derivating from standard functionality...
I have written a server that should accept n TCP connections at most. I was expecting that the backlog parameter of listen will cause extra connection requests either
1) to be refused
or
2) to time out eventually
(The standard seems to say that extra connections are refused)
However none of the above see ms true. Even if my server delays accept()ing new connections, no client ever sees a "connection refused" or "connection timed out". Is there any chance to signal the client that no more connections are accepted at the moment?
Regards,
Ulrich Windl
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Wei Yang @ 2014-12-08 14:42 UTC (permalink / raw)
To: David Laight
Cc: 'Eric Dumazet', David Miller, weiyang@linux.vnet.ibm.com,
netdev@vger.kernel.org, gideonn@mellanox.com, edumazet@google.com,
amirv@mellanox.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA04A51@AcuExch.aculab.com>
On Mon, Dec 08, 2014 at 10:00:19AM +0000, David Laight wrote:
>From: Eric Dumazet
>> On Fri, 2014-12-05 at 21:31 -0800, David Miller wrote:
>>
>> > Guys, let's figure out what we are doing with this patch.
>> > --
>>
>> Oh well, patch is fine, please apply it, thanks !
>
>I'm not to sure that the patch doesn't generate a software byteswap
>followed by a byteswapping write on ppc - clearly not ideal.
>It might even generate back to back software byteswaps.
>
>If the write to the doorbell register includes a byteswap on BE (ppc)
>then there is no real value in keeping the value as BE.
>
>OTOH ppc ought to have ways of doing IO writes without the byteswap
>(and byteswapping accesses to non-io memory for that matter).
>
>What happens on a BE system with BE peripherals is another matter.
David
Thanks for your comment.
How about use __raw_writel() to replace the iowrite32()? Looks this is better,
if so, I will make up another version for this.
>
> David
>
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH][net-next] net: avoid to call skb_queue_len again
From: Eric Dumazet @ 2014-12-08 15:10 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Li RongQing, netdev
In-Reply-To: <54858B56.1020607@cogentembedded.com>
On Mon, 2014-12-08 at 14:28 +0300, Sergei Shtylyov wrote:
>
> I expect you to also refine the description, so that it's meaningful,
> unlike now.
It seems obvious to me Li is not a native English speaker. I understood
the patch very well, and the changelog seemed fine to me.
What about you provide this description instead, since you seem to care
very much ?
Thanks !
^ permalink raw reply
* Re: [PATCH net-next 2/3] netlink: IFLA_PHYS_SWITCH_ID to IFLA_PHYS_PARENT_ID
From: Jiri Pirko @ 2014-12-08 15:17 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, sfeldma, jpirko
In-Reply-To: <1417802537-20020-2-git-send-email-gospo@cumulusnetworks.com>
Fri, Dec 05, 2014 at 07:02:16PM CET, gospo@cumulusnetworks.com wrote:
>There has been much discussion about proper nomenclature to use for this
>and I would prefer parent rather than calling every forwarding element a
>switch.
Andy, I must say I really do not like just plain "parent". It is really
not clear what it means as it can mean 1000 things.
I know "switch" is not ideal but everytime anyone is talking about these
kind of forwarding devices, they use word "switch" even if it is not
accurate and everyone knows what they are talking about. Nobody uses
"parent".
For me this is nack for this patchset.
Jiri
>
>Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
>---
> include/uapi/linux/if_link.h | 2 +-
> net/core/rtnetlink.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>index f7d0d2d..3d8edd8 100644
>--- a/include/uapi/linux/if_link.h
>+++ b/include/uapi/linux/if_link.h
>@@ -145,7 +145,7 @@ enum {
> IFLA_CARRIER,
> IFLA_PHYS_PORT_ID,
> IFLA_CARRIER_CHANGES,
>- IFLA_PHYS_SWITCH_ID,
>+ IFLA_PHYS_PARENT_ID,
> __IFLA_MAX
> };
>
>diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>index 61cb7e7..1fe0a16 100644
>--- a/net/core/rtnetlink.c
>+++ b/net/core/rtnetlink.c
>@@ -982,7 +982,7 @@ static int rtnl_phys_switch_id_fill(struct sk_buff *skb, struct net_device *dev)
> return err;
> }
>
>- if (nla_put(skb, IFLA_PHYS_SWITCH_ID, psid.id_len, psid.id))
>+ if (nla_put(skb, IFLA_PHYS_PARENT_ID, psid.id_len, psid.id))
> return -EMSGSIZE;
>
> return 0;
>@@ -1222,7 +1222,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
> [IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
> [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> [IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
>- [IFLA_PHYS_SWITCH_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>+ [IFLA_PHYS_PARENT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> };
>
> static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
>--
>1.9.3
>
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-12-08 15:18 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Greg Kroah-Hartman, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412061402.21514@pali>
On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
>
> /**
> + * request_firmware_prefer_user: - prefer usermode helper for loading firmware
> + * @firmware_p: pointer to firmware image
> + * @name: name of firmware file
> + * @device: device for which firmware is being loaded
> + *
> + * This function works pretty much like request_firmware(), but it prefer
> + * usermode helper. If usermode helper fails then it fallback to direct access.
> + * Usefull for dynamic or model specific firmware data.
> + **/
> +int request_firmware_prefer_user(const struct firmware **firmware_p,
> + const char *name, struct device *device)
> +{
> + int ret;
> + __module_get(THIS_MODULE);
> + ret = _request_firmware(firmware_p, name, device,
> + FW_OPT_UEVENT | FW_OPT_PREFER_USER);
> + module_put(THIS_MODULE);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
I'd like to introduce request_firmware_user() which only requests
firmware from user space, and this way is simpler and more flexible
since we have request_firmware_direct() already.
Thanks,
Ming Lei
^ permalink raw reply
* Re: Q: need effective backlog for listen()
From: Eric Dumazet @ 2014-12-08 15:18 UTC (permalink / raw)
To: Ulrich Windl; +Cc: netdev
In-Reply-To: <5485ACC9020000A100018394@gwsmtp1.uni-regensburg.de>
On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
> (not subscribed to the list, plese keep me on CC:)
>
> Hi!
>
> I have a problem I could not find the answer. I suspect the problem
> arises from Linux derivating from standard functionality...
>
> I have written a server that should accept n TCP connections at most.
> I was expecting that the backlog parameter of listen will cause extra
> connection requests either
> 1) to be refused
> or
> 2) to time out eventually
>
> (The standard seems to say that extra connections are refused)
>
> However none of the above see ms true. Even if my server delays
> accept()ing new connections, no client ever sees a "connection
> refused" or "connection timed out". Is there any chance to signal the
> client that no more connections are accepted at the moment?
This 'standard' makes no sense to me, in light of SYNFLOOD attacks.
It actually makes SYNFLOOD attacks very effective.
Have you tried to disable syncookies for a start ?
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 15:22 UTC (permalink / raw)
To: Ming Lei
Cc: Pavel Machek, Greg Kroah-Hartman, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <CACVXFVPOLfDuqc0nLb-zM8vH618DLXy0xtZbUOn5_XvdxRZSDw@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1626 bytes --]
On Monday 08 December 2014 16:18:18 Ming Lei wrote:
> On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
<pali.rohar@gmail.com> wrote:
> > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
> > /**
> >
> > + * request_firmware_prefer_user: - prefer usermode helper
> > for loading firmware + * @firmware_p: pointer to firmware
> > image
> > + * @name: name of firmware file
> > + * @device: device for which firmware is being loaded
> > + *
> > + * This function works pretty much like request_firmware(),
> > but it prefer + * usermode helper. If usermode helper fails
> > then it fallback to direct access. + * Usefull for dynamic
> > or model specific firmware data. + **/
> > +int request_firmware_prefer_user(const struct firmware
> > **firmware_p, + const char *name,
> > struct device *device) +{
> > + int ret;
> > + __module_get(THIS_MODULE);
> > + ret = _request_firmware(firmware_p, name, device,
> > + FW_OPT_UEVENT |
> > FW_OPT_PREFER_USER); + module_put(THIS_MODULE);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
>
> I'd like to introduce request_firmware_user() which only
> requests firmware from user space, and this way is simpler
> and more flexible since we have request_firmware_direct()
> already.
>
> Thanks,
> Ming Lei
Ming, for wl1251 NVS data we need to load use usermode helper and
fallback to direct load. So I think it is better to handle this
request in firmware code and not in driver.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] bridge: Remove BR_PROXYARP flooding check code
From: Jouni Malinen @ 2014-12-08 15:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Kyeyoon Park, Jouni Malinen
From: Kyeyoon Park <kyeyoonp@codeaurora.org>
Because dropping broadcast packets for IEEE 802.11 Proxy ARP is more
selective than previously thought, it is better to remove the direct
dropping logic in the bridge code in favor of using the netfilter
infrastructure to provide more control on which frames get dropped. This
code was added in commit 958501163ddd ("bridge: Add support for IEEE
802.11 Proxy ARP").
Signed-off-by: Kyeyoon Park <kyeyoonp@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
---
net/bridge/br_forward.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index f96933a..8a025a7 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -185,10 +185,6 @@ static void br_flood(struct net_bridge *br, struct sk_buff *skb,
if (unicast && !(p->flags & BR_FLOOD))
continue;
- /* Do not flood to ports that enable proxy ARP */
- if (p->flags & BR_PROXYARP)
- continue;
-
prev = maybe_deliver(prev, p, skb, __packet_hook);
if (IS_ERR(prev))
goto out;
--
1.9.1
^ permalink raw reply related
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-12-08 15:35 UTC (permalink / raw)
To: Pali Rohár
Cc: Pavel Machek, Greg Kroah-Hartman, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412081622.25541@pali>
On Mon, Dec 8, 2014 at 11:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Monday 08 December 2014 16:18:18 Ming Lei wrote:
>> On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
>> > /**
>> >
>> > + * request_firmware_prefer_user: - prefer usermode helper
>> > for loading firmware + * @firmware_p: pointer to firmware
>> > image
>> > + * @name: name of firmware file
>> > + * @device: device for which firmware is being loaded
>> > + *
>> > + * This function works pretty much like request_firmware(),
>> > but it prefer + * usermode helper. If usermode helper fails
>> > then it fallback to direct access. + * Usefull for dynamic
>> > or model specific firmware data. + **/
>> > +int request_firmware_prefer_user(const struct firmware
>> > **firmware_p, + const char *name,
>> > struct device *device) +{
>> > + int ret;
>> > + __module_get(THIS_MODULE);
>> > + ret = _request_firmware(firmware_p, name, device,
>> > + FW_OPT_UEVENT |
>> > FW_OPT_PREFER_USER); + module_put(THIS_MODULE);
>> > + return ret;
>> > +}
>> > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
>>
>> I'd like to introduce request_firmware_user() which only
>> requests firmware from user space, and this way is simpler
>> and more flexible since we have request_firmware_direct()
>> already.
>>
>> Thanks,
>> Ming Lei
>
> Ming, for wl1251 NVS data we need to load use usermode helper and
> fallback to direct load. So I think it is better to handle this
> request in firmware code and not in driver.
Please do that in driver and don't mess firmware loader.
With introducing request_firmware_user(), it is even possible to
clean up firmware loader further.
Thanks,
Ming Lei
^ permalink raw reply
* [PATCH nf-next 1/2] netfilter: conntrack: cache route for forwarded connections
From: Florian Westphal @ 2014-12-08 15:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, brouer, Florian Westphal
In-Reply-To: <1418052964-4632-1-git-send-email-fw@strlen.de>
... to avoid per-packet FIB lookup if possible.
The cached dst is re-used provided the input interface
is the same as that of the previous packet in the same direction.
If not, the cached dst is invalidated.
For ipv6 we also need to store sernum, else dst_check doesn't work,
pointed out by Eric Dumazet.
This should speed up forwarding when conntrack is already in use
anyway, especially when using reverse path filtering -- active RPF
enforces two FIB lookups for each packet.
Before the routing cache removal this didn't matter since RPF was performed
only when route cache didn't yield a result; but without route cache it
comes at higher price.
Julian Anastasov suggested to add NETDEV_UNREGISTER handler to
avoid holding on to dsts of 'frozen' conntracks.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
Changes since RFC:
- add NETDEV_UNREGISTER, suggested by Julian
- cache fib sernum to make ipv6 work, pointed out by Eric
- make module unload work
- remove ASSURED test, in case of -j DROP in prerouting or forward
cache forward hook won't be reached anyway
include/net/netfilter/nf_conntrack_extend.h | 4 +
include/net/netfilter/nf_conntrack_rtcache.h | 34 +++
net/netfilter/Kconfig | 12 +
net/netfilter/Makefile | 3 +
net/netfilter/nf_conntrack_rtcache.c | 387 +++++++++++++++++++++++++++
5 files changed, 440 insertions(+)
create mode 100644 include/net/netfilter/nf_conntrack_rtcache.h
create mode 100644 net/netfilter/nf_conntrack_rtcache.c
diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h
index 55d1504..1b00d57 100644
--- a/include/net/netfilter/nf_conntrack_extend.h
+++ b/include/net/netfilter/nf_conntrack_extend.h
@@ -30,6 +30,9 @@ enum nf_ct_ext_id {
#if IS_ENABLED(CONFIG_NETFILTER_SYNPROXY)
NF_CT_EXT_SYNPROXY,
#endif
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
+ NF_CT_EXT_RTCACHE,
+#endif
NF_CT_EXT_NUM,
};
@@ -43,6 +46,7 @@ enum nf_ct_ext_id {
#define NF_CT_EXT_TIMEOUT_TYPE struct nf_conn_timeout
#define NF_CT_EXT_LABELS_TYPE struct nf_conn_labels
#define NF_CT_EXT_SYNPROXY_TYPE struct nf_conn_synproxy
+#define NF_CT_EXT_RTCACHE_TYPE struct nf_conn_rtcache
/* Extensions: optional stuff which isn't permanently in struct. */
struct nf_ct_ext {
diff --git a/include/net/netfilter/nf_conntrack_rtcache.h b/include/net/netfilter/nf_conntrack_rtcache.h
new file mode 100644
index 0000000..e2fb302
--- /dev/null
+++ b/include/net/netfilter/nf_conntrack_rtcache.h
@@ -0,0 +1,34 @@
+#include <linux/gfp.h>
+#include <net/netfilter/nf_conntrack.h>
+#include <net/netfilter/nf_conntrack_extend.h>
+
+struct dst_entry;
+
+struct nf_conn_dst_cache {
+ struct dst_entry *dst;
+ int iif;
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+ u32 cookie;
+#endif
+
+};
+
+struct nf_conn_rtcache {
+ struct nf_conn_dst_cache cached_dst[IP_CT_DIR_MAX];
+};
+
+static inline
+struct nf_conn_rtcache *nf_ct_rtcache_find(const struct nf_conn *ct)
+{
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
+ return nf_ct_ext_find(ct, NF_CT_EXT_RTCACHE);
+#else
+ return NULL;
+#endif
+}
+
+static inline int nf_conn_rtcache_iif_get(const struct nf_conn_rtcache *rtc,
+ enum ip_conntrack_dir dir)
+{
+ return rtc->cached_dst[dir].iif;
+}
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index b02660f..c213a61 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -106,6 +106,18 @@ config NF_CONNTRACK_EVENTS
If unsure, say `N'.
+config NF_CONNTRACK_RTCACHE
+ tristate "Cache route entries in conntrack objects"
+ depends on NETFILTER_ADVANCED
+ depends on NF_CONNTRACK
+ help
+ If this option is enabled, the connection tracking code will
+ cache routing information for each connection that is being
+ forwarded, at a cost of 32 bytes per conntrack object.
+
+ To compile it as a module, choose M here. If unsure, say N.
+ The module will be called nf_conntrack_rtcache.
+
config NF_CONNTRACK_TIMEOUT
bool 'Connection tracking timeout'
depends on NETFILTER_ADVANCED
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 89f73a9..c174ab2 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -18,6 +18,9 @@ obj-$(CONFIG_NETFILTER_NETLINK_LOG) += nfnetlink_log.o
# connection tracking
obj-$(CONFIG_NF_CONNTRACK) += nf_conntrack.o
+# optional conntrack route cache extension
+obj-$(CONFIG_NF_CONNTRACK_RTCACHE) += nf_conntrack_rtcache.o
+
# SCTP protocol connection tracking
obj-$(CONFIG_NF_CT_PROTO_DCCP) += nf_conntrack_proto_dccp.o
obj-$(CONFIG_NF_CT_PROTO_GRE) += nf_conntrack_proto_gre.o
diff --git a/net/netfilter/nf_conntrack_rtcache.c b/net/netfilter/nf_conntrack_rtcache.c
new file mode 100644
index 0000000..65fef44
--- /dev/null
+++ b/net/netfilter/nf_conntrack_rtcache.c
@@ -0,0 +1,387 @@
+/* route cache for netfilter.
+ *
+ * (C) 2014 Red Hat GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/types.h>
+#include <linux/netfilter.h>
+#include <linux/skbuff.h>
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/export.h>
+#include <linux/module.h>
+
+#include <net/dst.h>
+
+#include <net/netfilter/nf_conntrack.h>
+#include <net/netfilter/nf_conntrack_core.h>
+#include <net/netfilter/nf_conntrack_extend.h>
+#include <net/netfilter/nf_conntrack_rtcache.h>
+
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+#include <net/ip6_fib.h>
+#endif
+
+static void __nf_conn_rtcache_destroy(struct nf_conn_rtcache *rtc,
+ enum ip_conntrack_dir dir)
+{
+ struct dst_entry *dst = rtc->cached_dst[dir].dst;
+
+ dst_release(dst);
+}
+
+static void nf_conn_rtcache_destroy(struct nf_conn *ct)
+{
+ struct nf_conn_rtcache *rtc = nf_ct_rtcache_find(ct);
+
+ if (!rtc)
+ return;
+
+ __nf_conn_rtcache_destroy(rtc, IP_CT_DIR_ORIGINAL);
+ __nf_conn_rtcache_destroy(rtc, IP_CT_DIR_REPLY);
+}
+
+static void nf_ct_rtcache_ext_add(struct nf_conn *ct)
+{
+ struct nf_conn_rtcache *rtc;
+
+ rtc = nf_ct_ext_add(ct, NF_CT_EXT_RTCACHE, GFP_ATOMIC);
+ if (rtc) {
+ rtc->cached_dst[IP_CT_DIR_ORIGINAL].iif = -1;
+ rtc->cached_dst[IP_CT_DIR_ORIGINAL].dst = NULL;
+ rtc->cached_dst[IP_CT_DIR_REPLY].iif = -1;
+ rtc->cached_dst[IP_CT_DIR_REPLY].dst = NULL;
+ }
+}
+
+static struct nf_conn_rtcache *nf_ct_rtcache_find_usable(struct nf_conn *ct)
+{
+ if (nf_ct_is_untracked(ct))
+ return NULL;
+ return nf_ct_rtcache_find(ct);
+}
+
+static struct dst_entry *
+nf_conn_rtcache_dst_get(const struct nf_conn_rtcache *rtc,
+ enum ip_conntrack_dir dir)
+{
+ return rtc->cached_dst[dir].dst;
+}
+
+static u32 nf_rtcache_get_cookie(int pf, const struct dst_entry *dst)
+{
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+ if (pf == NFPROTO_IPV6) {
+ const struct rt6_info *rt = (const struct rt6_info *)dst;
+
+ if (rt->rt6i_node)
+ return (u32)rt->rt6i_node->fn_sernum;
+ }
+#endif
+ return 0;
+}
+
+static void nf_conn_rtcache_dst_set(int pf,
+ struct nf_conn_rtcache *rtc,
+ struct dst_entry *dst,
+ enum ip_conntrack_dir dir, int iif)
+{
+ if (rtc->cached_dst[dir].iif != iif)
+ rtc->cached_dst[dir].iif = iif;
+
+ if (rtc->cached_dst[dir].dst != dst) {
+ struct dst_entry *old;
+
+ dst_hold(dst);
+
+ old = xchg(&rtc->cached_dst[dir].dst, dst);
+ dst_release(old);
+
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+ if (pf == NFPROTO_IPV6)
+ rtc->cached_dst[dir].cookie =
+ nf_rtcache_get_cookie(pf, dst);
+#endif
+ }
+}
+
+static void nf_conn_rtcache_dst_obsolete(struct nf_conn_rtcache *rtc,
+ enum ip_conntrack_dir dir)
+{
+ struct dst_entry *old;
+
+ pr_debug("Invalidate iif %d for dir %d on cache %p\n",
+ rtc->cached_dst[dir].iif, dir, rtc);
+
+ old = xchg(&rtc->cached_dst[dir].dst, NULL);
+ dst_release(old);
+ rtc->cached_dst[dir].iif = -1;
+}
+
+static unsigned int nf_rtcache_in(const struct nf_hook_ops *ops,
+ struct sk_buff *skb,
+ const struct net_device *in,
+ const struct net_device *out,
+ int (*okfn)(struct sk_buff *))
+{
+ struct nf_conn_rtcache *rtc;
+ enum ip_conntrack_info ctinfo;
+ enum ip_conntrack_dir dir;
+ struct dst_entry *dst;
+ struct nf_conn *ct;
+ int iif;
+ u32 cookie;
+
+ if (skb_dst(skb) || skb->sk)
+ return NF_ACCEPT;
+
+ ct = nf_ct_get(skb, &ctinfo);
+ if (!ct)
+ return NF_ACCEPT;
+
+ rtc = nf_ct_rtcache_find_usable(ct);
+ if (!rtc)
+ return NF_ACCEPT;
+
+ /* if iif changes, don't use cache and let ip stack
+ * do route lookup.
+ *
+ * If rp_filter is enabled it might toss skb, so
+ * we don't want to avoid these checks.
+ */
+ dir = CTINFO2DIR(ctinfo);
+ iif = nf_conn_rtcache_iif_get(rtc, dir);
+ if (in->ifindex != iif) {
+ pr_debug("ct %p, iif %d, cached iif %d, skip cached entry\n",
+ ct, iif, in->ifindex);
+ return NF_ACCEPT;
+ }
+ dst = nf_conn_rtcache_dst_get(rtc, dir);
+ if (dst == NULL)
+ return NF_ACCEPT;
+
+ cookie = nf_rtcache_get_cookie(ops->pf, dst);
+
+ dst = dst_check(dst, cookie);
+ pr_debug("obtained dst %p for skb %p, cookie %d\n", dst, skb, cookie);
+ if (likely(dst))
+ skb_dst_set_noref_force(skb, dst);
+ else
+ nf_conn_rtcache_dst_obsolete(rtc, dir);
+
+ return NF_ACCEPT;
+}
+
+static unsigned int nf_rtcache_forward(const struct nf_hook_ops *ops,
+ struct sk_buff *skb,
+ const struct net_device *in,
+ const struct net_device *out,
+ int (*okfn)(struct sk_buff *))
+{
+ struct nf_conn_rtcache *rtc;
+ enum ip_conntrack_info ctinfo;
+ enum ip_conntrack_dir dir;
+ struct nf_conn *ct;
+ int iif;
+
+ ct = nf_ct_get(skb, &ctinfo);
+ if (!ct)
+ return NF_ACCEPT;
+
+ if (!nf_ct_is_confirmed(ct)) {
+ if (WARN_ON(nf_ct_rtcache_find(ct)))
+ return NF_ACCEPT;
+ nf_ct_rtcache_ext_add(ct);
+ return NF_ACCEPT;
+ }
+
+ rtc = nf_ct_rtcache_find_usable(ct);
+ if (!rtc)
+ return NF_ACCEPT;
+
+ dir = CTINFO2DIR(ctinfo);
+ iif = nf_conn_rtcache_iif_get(rtc, dir);
+ pr_debug("ct %p, skb %p, dir %d, iif %d, cached iif %d\n",
+ ct, skb, dir, iif, in->ifindex);
+ if (likely(in->ifindex == iif))
+ return NF_ACCEPT;
+
+ nf_conn_rtcache_dst_set(ops->pf, rtc, skb_dst(skb), dir, in->ifindex);
+ return NF_ACCEPT;
+}
+
+static int nf_rtcache_dst_remove(struct nf_conn *ct, void *data)
+{
+ struct nf_conn_rtcache *rtc = nf_ct_rtcache_find(ct);
+ struct net_device *dev = data;
+
+ if (!rtc)
+ return 0;
+
+ if (dev->ifindex == rtc->cached_dst[IP_CT_DIR_ORIGINAL].iif ||
+ dev->ifindex == rtc->cached_dst[IP_CT_DIR_REPLY].iif) {
+ nf_conn_rtcache_dst_obsolete(rtc, IP_CT_DIR_ORIGINAL);
+ nf_conn_rtcache_dst_obsolete(rtc, IP_CT_DIR_REPLY);
+ }
+
+ return 0;
+}
+
+static int nf_rtcache_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+ struct net *net = dev_net(dev);
+
+ if (event == NETDEV_DOWN)
+ nf_ct_iterate_cleanup(net, nf_rtcache_dst_remove, dev, 0, 0);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block nf_rtcache_notifier = {
+ .notifier_call = nf_rtcache_netdev_event,
+};
+
+static struct nf_hook_ops rtcache_ops[] = {
+ {
+ .hook = nf_rtcache_in,
+ .owner = THIS_MODULE,
+ .pf = NFPROTO_IPV4,
+ .hooknum = NF_INET_PRE_ROUTING,
+ .priority = NF_IP_PRI_LAST,
+ },
+ {
+ .hook = nf_rtcache_forward,
+ .owner = THIS_MODULE,
+ .pf = NFPROTO_IPV4,
+ .hooknum = NF_INET_FORWARD,
+ .priority = NF_IP_PRI_LAST,
+ },
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
+ {
+ .hook = nf_rtcache_in,
+ .owner = THIS_MODULE,
+ .pf = NFPROTO_IPV6,
+ .hooknum = NF_INET_PRE_ROUTING,
+ .priority = NF_IP_PRI_LAST,
+ },
+ {
+ .hook = nf_rtcache_forward,
+ .owner = THIS_MODULE,
+ .pf = NFPROTO_IPV6,
+ .hooknum = NF_INET_FORWARD,
+ .priority = NF_IP_PRI_LAST,
+ },
+#endif
+};
+
+static struct nf_ct_ext_type rtcache_extend __read_mostly = {
+ .len = sizeof(struct nf_conn_rtcache),
+ .align = __alignof__(struct nf_conn_rtcache),
+ .id = NF_CT_EXT_RTCACHE,
+ .destroy = nf_conn_rtcache_destroy,
+};
+
+static int __init nf_conntrack_rtcache_init(void)
+{
+ int ret = nf_ct_extend_register(&rtcache_extend);
+
+ if (ret < 0) {
+ pr_err("nf_conntrack_rtcache: Unable to register extension\n");
+ return ret;
+ }
+
+ ret = nf_register_hooks(rtcache_ops, ARRAY_SIZE(rtcache_ops));
+ if (ret < 0) {
+ nf_ct_extend_unregister(&rtcache_extend);
+ return ret;
+ }
+
+ ret = register_netdevice_notifier(&nf_rtcache_notifier);
+ if (ret) {
+ nf_unregister_hooks(rtcache_ops, ARRAY_SIZE(rtcache_ops));
+ nf_ct_extend_unregister(&rtcache_extend);
+ }
+
+ return ret;
+}
+
+static int nf_rtcache_ext_remove(struct nf_conn *ct, void *data)
+{
+ struct nf_conn_rtcache *rtc = nf_ct_rtcache_find(ct);
+
+ return rtc != NULL;
+}
+
+static bool __exit nf_conntrack_rtcache_wait_for_dying(struct net *net)
+{
+ bool wait = false;
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+ struct nf_conntrack_tuple_hash *h;
+ struct hlist_nulls_node *n;
+ struct nf_conn *ct;
+ struct ct_pcpu *pcpu = per_cpu_ptr(net->ct.pcpu_lists, cpu);
+
+ rcu_read_lock();
+ spin_lock_bh(&pcpu->lock);
+
+ hlist_nulls_for_each_entry(h, n, &pcpu->dying, hnnode) {
+ ct = nf_ct_tuplehash_to_ctrack(h);
+ if (nf_ct_rtcache_find(ct) != NULL) {
+ wait = true;
+ break;
+ }
+ }
+ spin_unlock_bh(&pcpu->lock);
+ rcu_read_unlock();
+ }
+
+ return wait;
+}
+
+static void __exit nf_conntrack_rtcache_fini(void)
+{
+ struct net *net;
+ int count = 0;
+
+ /* remove hooks so no new connections get rtcache extension */
+ nf_unregister_hooks(rtcache_ops, ARRAY_SIZE(rtcache_ops));
+
+ synchronize_net();
+
+ unregister_netdevice_notifier(&nf_rtcache_notifier);
+
+ rtnl_lock();
+
+ /* zap all conntracks with rtcache extension */
+ for_each_net(net)
+ nf_ct_iterate_cleanup(net, nf_rtcache_ext_remove, NULL, 0, 0);
+
+ for_each_net(net) {
+ /* .. and make sure they're gone from dying list, too */
+ while (nf_conntrack_rtcache_wait_for_dying(net)) {
+ msleep(200);
+ WARN_ONCE(++count > 25, "Waiting for all rtcache conntracks to go away\n");
+ }
+ }
+
+ rtnl_unlock();
+ synchronize_net();
+ nf_ct_extend_unregister(&rtcache_extend);
+}
+module_init(nf_conntrack_rtcache_init);
+module_exit(nf_conntrack_rtcache_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Florian Westphal <fw@strlen.de>");
+MODULE_DESCRIPTION("Conntrack route cache extension");
--
2.0.4
^ permalink raw reply related
* [PATCH nf-next 0/2] netfilter: conntrack: route cache for forwarded connections
From: Florian Westphal @ 2014-12-08 15:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, brouer
[ Pablo, in case you deem this too late for -next just let me know
and I will resend once its open again ]
This adds an optional forward routing cache extension for netfilter
connection tracking.
The memory cost is an additional 32 bytes per conntrack entry
on x86_64.
Unlike any other currently implemented connection tracking
extension the rtcache has no run-time tunables, it is always active.
Also, unlike other conntrack extensions, it can be built as a module,
in this case modprobe/rmmod are used to enable/disable the cache.
Forward test using netperf UDP_STREAM between two network namespaces
(connected via veth devices), tput:
With conntrack + reverse path filtering (rp_filter sysctl=1):
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.1.12.2 () port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 64 120.00 26333996 0 112.36
212992 120.00 26279399 112.13
same, but with rtcache (this patch series):
212992 64 120.00 34508693 0 147.24
212992 120.00 34507838 147.23
same but with rp_filter=0 and no conntrack modules active:
212992 64 120.00 42288748 0 180.43
212992 120.00 42283439 180.41
IOW, this is only useful if conntrack is used anyway.
^ permalink raw reply
* [PATCH nf-next 2/2] netfilter: use conntrack rtcache if available
From: Florian Westphal @ 2014-12-08 15:36 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, brouer, Florian Westphal
In-Reply-To: <1418052964-4632-1-git-send-email-fw@strlen.de>
skip the reverse lookup if the iif matches the cached one.
In this case we know that a previous rpfilter check did not result
in packet drop.
This shortcut only works if rtcache is available and rule is placed
in mangle table (raw table is too early; skb->nfct will not be set).
While it would be possible to enforce rtcache, it would a)
force a dependency on conntrack and b) break backwards compatibility
since we'd have to restrict it to mangle table.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
include/net/netfilter/nf_conntrack_rtcache.h | 12 +++++++++++
net/ipv4/netfilter/ipt_rpfilter.c | 4 +++-
net/ipv6/netfilter/ip6t_rpfilter.c | 4 +++-
net/netfilter/core.c | 30 ++++++++++++++++++++++++++++
4 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_rtcache.h b/include/net/netfilter/nf_conntrack_rtcache.h
index e2fb302..19265ad 100644
--- a/include/net/netfilter/nf_conntrack_rtcache.h
+++ b/include/net/netfilter/nf_conntrack_rtcache.h
@@ -27,6 +27,18 @@ struct nf_conn_rtcache *nf_ct_rtcache_find(const struct nf_conn *ct)
#endif
}
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
+bool nf_conn_rtcache_match_dev(const struct sk_buff *skb,
+ const struct net_device *dev);
+#else
+static inline bool
+nf_conn_rtcache_match_dev(const struct sk_buff *skb,
+ const struct net_device *dev)
+{
+ return false;
+}
+#endif
+
static inline int nf_conn_rtcache_iif_get(const struct nf_conn_rtcache *rtc,
enum ip_conntrack_dir dir)
{
diff --git a/net/ipv4/netfilter/ipt_rpfilter.c b/net/ipv4/netfilter/ipt_rpfilter.c
index 4bfaedf..f39e934 100644
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -19,6 +19,8 @@
#include <linux/netfilter/xt_rpfilter.h>
#include <linux/netfilter/x_tables.h>
+#include <net/netfilter/nf_conntrack_rtcache.h>
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Florian Westphal <fw@strlen.de>");
MODULE_DESCRIPTION("iptables: ipv4 reverse path filter match");
@@ -82,7 +84,7 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
info = par->matchinfo;
invert = info->flags & XT_RPFILTER_INVERT;
- if (rpfilter_is_local(skb))
+ if (rpfilter_is_local(skb) || nf_conn_rtcache_match_dev(skb, par->in))
return true ^ invert;
iph = ip_hdr(skb);
diff --git a/net/ipv6/netfilter/ip6t_rpfilter.c b/net/ipv6/netfilter/ip6t_rpfilter.c
index 790e0c6..8db9fe7 100644
--- a/net/ipv6/netfilter/ip6t_rpfilter.c
+++ b/net/ipv6/netfilter/ip6t_rpfilter.c
@@ -16,6 +16,8 @@
#include <linux/netfilter/xt_rpfilter.h>
#include <linux/netfilter/x_tables.h>
+#include <net/netfilter/nf_conntrack_rtcache.h>
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Florian Westphal <fw@strlen.de>");
MODULE_DESCRIPTION("Xtables: IPv6 reverse path filter match");
@@ -85,7 +87,7 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
struct ipv6hdr *iph;
bool invert = info->flags & XT_RPFILTER_INVERT;
- if (rpfilter_is_local(skb))
+ if (rpfilter_is_local(skb) || nf_conn_rtcache_match_dev(skb, par->in))
return true ^ invert;
iph = ipv6_hdr(skb);
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index fea9ef5..651b4c6 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -25,6 +25,8 @@
#include <net/net_namespace.h>
#include <net/sock.h>
+#include <net/netfilter/nf_conntrack_rtcache.h>
+
#include "nf_internals.h"
static DEFINE_MUTEX(afinfo_mutex);
@@ -267,6 +269,34 @@ EXPORT_SYMBOL_GPL(nfq_ct_hook);
struct nfq_ct_nat_hook __rcu *nfq_ct_nat_hook __read_mostly;
EXPORT_SYMBOL_GPL(nfq_ct_nat_hook);
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
+/* returns true if dev matches the last recorded
+ * input interface of the conntrack attached to skb.
+ *
+ * This is not in conntrack to avoid module dependency.
+ */
+bool nf_conn_rtcache_match_dev(const struct sk_buff *skb,
+ const struct net_device *dev)
+{
+ struct nf_conn_rtcache *rtc;
+ enum ip_conntrack_info ctinfo;
+ enum ip_conntrack_dir dir;
+ struct nf_conn *ct;
+ int iif;
+
+ ct = nf_ct_get(skb, &ctinfo);
+ rtc = nf_ct_rtcache_find(ct);
+ if (!rtc)
+ return false;
+
+ dir = CTINFO2DIR(ctinfo);
+ iif = nf_conn_rtcache_iif_get(rtc, dir);
+
+ return iif == dev->ifindex;
+}
+EXPORT_SYMBOL_GPL(nf_conn_rtcache_match_dev);
+#endif
+
#endif /* CONFIG_NF_CONNTRACK */
#ifdef CONFIG_NF_NAT_NEEDED
--
2.0.4
^ permalink raw reply related
* Re: [PATCH net-next 2/3] netlink: IFLA_PHYS_SWITCH_ID to IFLA_PHYS_PARENT_ID
From: Andy Gospodarek @ 2014-12-08 15:37 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, sfeldma
In-Reply-To: <20141208151714.GG1885@nanopsycho.brq.redhat.com>
On Mon, Dec 08, 2014 at 04:17:14PM +0100, Jiri Pirko wrote:
> Fri, Dec 05, 2014 at 07:02:16PM CET, gospo@cumulusnetworks.com wrote:
> >There has been much discussion about proper nomenclature to use for this
> >and I would prefer parent rather than calling every forwarding element a
> >switch.
>
> Andy, I must say I really do not like just plain "parent". It is really
> not clear what it means as it can mean 1000 things.
>
> I know "switch" is not ideal but everytime anyone is talking about these
> kind of forwarding devices, they use word "switch" even if it is not
> accurate and everyone knows what they are talking about. Nobody uses
> "parent".
Well of course they are not going to use it until it's committed. ;-)
> For me this is nack for this patchset.
Thanks for the review. I am not big marketing person, so it was not
clear to me what was ideal. Due to parent already being in the code
and having as a logical description of the relationship (parent
switch/router device and sibling network interfaces -- like sibling CPU
cores on the same socket).
I do really want to collectively come up with something other than
switch for everything. Those L3 ops with 'switch' in the name will
feel really awkward....
>
> Jiri
>
> >
> >Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
> >---
> > include/uapi/linux/if_link.h | 2 +-
> > net/core/rtnetlink.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> >diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> >index f7d0d2d..3d8edd8 100644
> >--- a/include/uapi/linux/if_link.h
> >+++ b/include/uapi/linux/if_link.h
> >@@ -145,7 +145,7 @@ enum {
> > IFLA_CARRIER,
> > IFLA_PHYS_PORT_ID,
> > IFLA_CARRIER_CHANGES,
> >- IFLA_PHYS_SWITCH_ID,
> >+ IFLA_PHYS_PARENT_ID,
> > __IFLA_MAX
> > };
> >
> >diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> >index 61cb7e7..1fe0a16 100644
> >--- a/net/core/rtnetlink.c
> >+++ b/net/core/rtnetlink.c
> >@@ -982,7 +982,7 @@ static int rtnl_phys_switch_id_fill(struct sk_buff *skb, struct net_device *dev)
> > return err;
> > }
> >
> >- if (nla_put(skb, IFLA_PHYS_SWITCH_ID, psid.id_len, psid.id))
> >+ if (nla_put(skb, IFLA_PHYS_PARENT_ID, psid.id_len, psid.id))
> > return -EMSGSIZE;
> >
> > return 0;
> >@@ -1222,7 +1222,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
> > [IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
> > [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> > [IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
> >- [IFLA_PHYS_SWITCH_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> >+ [IFLA_PHYS_PARENT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
> > };
> >
> > static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
> >--
> >1.9.3
> >
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rocker: remove swdev mode
From: Thomas Graf @ 2014-12-08 16:18 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jiri Pirko, roopa, sfeldma, jhs, bcrl, john.fastabend, stephen,
linville, vyasevic, netdev, davem, shm, gospo
In-Reply-To: <54858E6E.7010707@redhat.com>
On 12/08/14 at 12:41pm, Daniel Borkmann wrote:
> On 12/08/2014 12:03 PM, Jiri Pirko wrote:
> >well, I see no problem in using u16. IFLA_BRIDGE_MODE attr is u16 so
> >mode should stay u16.
> >
> >But maybe better to add:
> >#define BRIDGE_MODE_UNDEF 0xFFFF
>
> Yep, something along these lines seems better.
Using u16 is fine but then all occurences should use it as opposed
to mixed s16/u16 usage as in v3.
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: George Spelvin @ 2014-12-08 16:19 UTC (permalink / raw)
To: hannes, linux
Cc: davem, dborkman, herbert, linux-kernel, netdev, tgraf, tytso
In-Reply-To: <1418037908.190744.200156353.5DD668E8@webmail.messagingengine.com>
>>> In case of openvswitch it shows a performance improvment. The seed
>>> parameter could be used as an initial biasing of the crc32 function, but
>>> in case of openvswitch it is only set to 0.
>> NACK. [...]
> Sorry for being unclear, I understood that and didn't bother patching
> that '0' with a random seed exactly because of this.
And I'm sorry for delivering a long lecture on a subject you already
understood perfectly well.
I'd just been thinking about it because of Herbert's comments, so it was
conveniently at hand. :-)
Out of curiousity, what *were* you referring to when you talked
about biasing the crc32 function? "Biasing" is a good term becuase
it just applies an offset, but what do you gain from doing that?
There are nifty things one can do with the CRC32 instruction, however.
A lot of ciphers these days use an ARX (add, rotate, XOR) kernel.
A crc32 instruction, although linear, does some very powerful rotate &
xor operations, and could replace the XOR and rotate.
^ permalink raw reply
* Re: [PATCH] drivers:atm Remove two FIXMES in the function, top_off_fp for the file, firestream.c
From: chas williams - CONTRACTOR @ 2014-12-08 16:20 UTC (permalink / raw)
To: Nicholas Krause; +Cc: linux-atm-general, netdev, linux-kernel
In-Reply-To: <1417923348-13807-1-git-send-email-xerofoify@gmail.com>
I don't see any reason to promote qe_tmp to a u64. I think you can
just remove the comment. Anyone trying to build this into a 64-bit
kernel will see errors from the virt_to_bus()/bus_to_virt() usage.
fp->n seems to only be manipulated in interrupt context (after driving
initialization) so it doesn't need locking or to be atomic.
On Sat, 6 Dec 2014 22:35:48 -0500
Nicholas Krause <xerofoify@gmail.com> wrote:
> Removes two FIXMES in the function.top_off_fp. The first being that of needing the variable, qe_tmp needing to be a
> u64 type and not u32 as encoding will not work if using a 32 bit register rather then 64 bit as stated in the first
> fix me comment. In addition the second being a no longer needed comment due to not needing to atomically increment
> the variable, n as passed to the function by the pointer of fp, as part of a structure of type,freepool.
>
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> ---
> drivers/atm/firestream.c | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/atm/firestream.c b/drivers/atm/firestream.c
> index 82f2ae0..06c23f6 100644
> --- a/drivers/atm/firestream.c
> +++ b/drivers/atm/firestream.c
> @@ -1477,7 +1477,7 @@ static void top_off_fp (struct fs_dev *dev, struct freepool *fp,
> struct FS_BPENTRY *qe, *ne;
> struct sk_buff *skb;
> int n = 0;
> - u32 qe_tmp;
> + u64 qe_tmp;
>
> fs_dprintk (FS_DEBUG_QUEUE, "Topping off queue at %x (%d-%d/%d)\n",
> fp->offset, read_fs (dev, FP_CNT (fp->offset)), fp->n,
> @@ -1505,14 +1505,8 @@ static void top_off_fp (struct fs_dev *dev, struct freepool *fp,
> ne->skb = skb;
> ne->fp = fp;
>
> - /*
> - * FIXME: following code encodes and decodes
> - * machine pointers (could be 64-bit) into a
> - * 32-bit register.
> - */
> -
> qe_tmp = read_fs (dev, FP_EA(fp->offset));
> - fs_dprintk (FS_DEBUG_QUEUE, "link at %x\n", qe_tmp);
> + fs_dprintk(FS_DEBUG_QUEUE, "link at %llx\n", qe_tmp);
> if (qe_tmp) {
> qe = bus_to_virt ((long) qe_tmp);
> qe->next = virt_to_bus(ne);
> @@ -1521,7 +1515,7 @@ static void top_off_fp (struct fs_dev *dev, struct freepool *fp,
> write_fs (dev, FP_SA(fp->offset), virt_to_bus(ne));
>
> write_fs (dev, FP_EA(fp->offset), virt_to_bus (ne));
> - fp->n++; /* XXX Atomic_inc? */
> + fp->n++;
> write_fs (dev, FP_CTU(fp->offset), 1);
> }
>
^ permalink raw reply
* Antw: Re: Q: need effective backlog for listen()
From: Ulrich Windl @ 2014-12-08 16:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1418051901.15618.46.camel@edumazet-glaptop2.roam.corp.google.com>
>>> Eric Dumazet <eric.dumazet@gmail.com> schrieb am 08.12.2014 um 16:18 in
Nachricht <1418051901.15618.46.camel@edumazet-glaptop2.roam.corp.google.com>:
> On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
>> (not subscribed to the list, plese keep me on CC:)
>>
>> Hi!
>>
>> I have a problem I could not find the answer. I suspect the problem
>> arises from Linux derivating from standard functionality...
>>
>> I have written a server that should accept n TCP connections at most.
>> I was expecting that the backlog parameter of listen will cause extra
>> connection requests either
>> 1) to be refused
>> or
>> 2) to time out eventually
>>
>> (The standard seems to say that extra connections are refused)
>>
>> However none of the above see ms true. Even if my server delays
>> accept()ing new connections, no client ever sees a "connection
>> refused" or "connection timed out". Is there any chance to signal the
>> client that no more connections are accepted at the moment?
>
> This 'standard' makes no sense to me, in light of SYNFLOOD attacks.
>
> It actually makes SYNFLOOD attacks very effective.
>
> Have you tried to disable syncookies for a start ?
No, I tries to temporarily close the listening socket. My priority is not to overload the server with connections. At the sime time I _want_ that the clients see that the server resfuses connections. Before you wonder: The client will actually be a load balancer.
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: Hannes Frederic Sowa @ 2014-12-08 16:32 UTC (permalink / raw)
To: George Spelvin
Cc: davem, dborkman, herbert, linux-kernel, netdev, tgraf, tytso
In-Reply-To: <20141208161959.8852.qmail@ns.horizon.com>
On Mon, Dec 8, 2014, at 17:19, George Spelvin wrote:
> >>> In case of openvswitch it shows a performance improvment. The seed
> >>> parameter could be used as an initial biasing of the crc32 function, but
> >>> in case of openvswitch it is only set to 0.
>
> >> NACK. [...]
>
> > Sorry for being unclear, I understood that and didn't bother patching
> > that '0' with a random seed exactly because of this.
>
> And I'm sorry for delivering a long lecture on a subject you already
> understood perfectly well.
I learned something, so your time wasn't completely wasted. ;)
> I'd just been thinking about it because of Herbert's comments, so it was
> conveniently at hand. :-)
>
> Out of curiousity, what *were* you referring to when you talked
> about biasing the crc32 function? "Biasing" is a good term becuase
> it just applies an offset, but what do you gain from doing that?
Actually, I don't know why the seed parameter was added. I just wanted
to mention that there is a way to bias the crc32 function which fits
into the style of the other hashing functions, like jhash with its
initval parameter.
I just kept it around during the rewrite.
The only use case I can imagine would be if one would like to calculate
a crc32c over a non-contiguous array, thus feeding the result of one crc
operation into the next one.
> There are nifty things one can do with the CRC32 instruction, however.
> A lot of ciphers these days use an ARX (add, rotate, XOR) kernel.
> A crc32 instruction, although linear, does some very powerful rotate &
> xor operations, and could replace the XOR and rotate.
Yes, I have seen it being used in cityhash.
There is also a proposal by Intel, but the hash seems too weak, too:
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/hash-method-performance-paper.pdf
Bye,
Hannes
^ permalink raw reply
* [PATCH net] netlink: use jhash as hashfn for rhashtable
From: Daniel Borkmann @ 2014-12-08 16:30 UTC (permalink / raw)
To: davem; +Cc: netdev, Herbert Xu, Thomas Graf, Hannes Frederic Sowa
For netlink, we shouldn't be using arch_fast_hash() as a hashing
discipline, but rather jhash() instead.
Since netlink sockets can be opened by any user, a local attacker
would be able to easily create collisions with the DPDK-derived
arch_fast_hash(), which trades off performance for security by
using crc32 CPU instructions on x86_64.
While it might have a legimite use case in other places, it should
be avoided in netlink context, though. As rhashtable's API is very
flexible, we could later on still decide on other hashing disciplines,
if legitimate.
Reference: http://thread.gmane.org/gmane.linux.kernel/1844123
Fixes: e341694e3eb5 ("netlink: Convert netlink_lookup() to use RCU protected hash table")
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/netlink/af_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 0007b81..b6bf8e8 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -3130,7 +3130,7 @@ static int __init netlink_proto_init(void)
.head_offset = offsetof(struct netlink_sock, node),
.key_offset = offsetof(struct netlink_sock, portid),
.key_len = sizeof(u32), /* portid */
- .hashfn = arch_fast_hash,
+ .hashfn = jhash,
.max_shift = 16, /* 64K */
.grow_decision = rht_grow_above_75,
.shrink_decision = rht_shrink_below_30,
--
1.7.11.7
^ 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