* Re: [PATCH V7] netfilter: h323: avoid potential attack
From: Pablo Neira Ayuso @ 2016-03-12 12:19 UTC (permalink / raw)
To: Zhouyi Zhou
Cc: eric.dumazet, kaber, kadlec, davem, netfilter-devel, coreteam,
netdev, linux-kernel, fw, gnomes, sergei.shtylyov, Zhouyi Zhou
In-Reply-To: <1455984239-5807-1-git-send-email-zhouzhouyi@gmail.com>
On Sun, Feb 21, 2016 at 12:03:59AM +0800, Zhouyi Zhou wrote:
> I think hackers chould build a malicious h323 packet to overflow
> the pointer p which will panic during the memcpy(addr, p, len)
> For example, he may fabricate a very large taddr->ipAddress.ip in
> function get_h225_addr.
>
> To avoid above, I add buffer boundary checking both in get addr
> functions and set addr functions.
>
> Because the temporary h323 buffer is dynamiclly allocated, I remove
> the h323 spin lock in my patch.
>
> Signed-off-by: Zhouyi Zhou <yizhouzhou@ict.ac.cn>
> ---
> include/linux/netfilter/nf_conntrack_h323.h | 17 +-
> net/ipv4/netfilter/nf_nat_h323.c | 33 ++-
> net/netfilter/nf_conntrack_h323_main.c | 328 +++++++++++++++++-----------
> 3 files changed, 244 insertions(+), 134 deletions(-)
>
> diff --git a/include/linux/netfilter/nf_conntrack_h323.h b/include/linux/netfilter/nf_conntrack_h323.h
> index 858d9b2..6c6fea1 100644
> --- a/include/linux/netfilter/nf_conntrack_h323.h
> +++ b/include/linux/netfilter/nf_conntrack_h323.h
> @@ -27,11 +27,17 @@ struct nf_ct_h323_master {
> };
> };
>
> +struct h323_ct_state {
> + unsigned char *buf;
> + unsigned char *data;
> + int buflen;
> +};
> +
> struct nf_conn;
>
> int get_h225_addr(struct nf_conn *ct, unsigned char *data,
> TransportAddress *taddr, union nf_inet_addr *addr,
> - __be16 *port);
> + __be16 *port, struct h323_ct_state *ctstate);
> void nf_conntrack_h245_expect(struct nf_conn *new,
> struct nf_conntrack_expect *this);
> void nf_conntrack_q931_expect(struct nf_conn *new,
> @@ -50,12 +56,14 @@ extern int (*set_sig_addr_hook) (struct sk_buff *skb,
> struct nf_conn *ct,
> enum ip_conntrack_info ctinfo,
> unsigned int protoff, unsigned char **data,
> - TransportAddress *taddr, int count);
> + TransportAddress *taddr, int count,
> + struct h323_ct_state *ctstate);
> extern int (*set_ras_addr_hook) (struct sk_buff *skb,
> struct nf_conn *ct,
> enum ip_conntrack_info ctinfo,
> unsigned int protoff, unsigned char **data,
> - TransportAddress *taddr, int count);
> + TransportAddress *taddr, int count,
> + struct h323_ct_state *ctstate);
> extern int (*nat_rtp_rtcp_hook) (struct sk_buff *skb,
> struct nf_conn *ct,
> enum ip_conntrack_info ctinfo,
> @@ -90,7 +98,8 @@ extern int (*nat_q931_hook) (struct sk_buff *skb, struct nf_conn *ct,
> unsigned int protoff,
> unsigned char **data, TransportAddress *taddr,
> int idx, __be16 port,
> - struct nf_conntrack_expect *exp);
> + struct nf_conntrack_expect *exp,
> + struct h323_ct_state *ctstate);
>
> #endif
>
> diff --git a/net/ipv4/netfilter/nf_nat_h323.c b/net/ipv4/netfilter/nf_nat_h323.c
> index 574f7eb..5ed2d70 100644
> --- a/net/ipv4/netfilter/nf_nat_h323.c
> +++ b/net/ipv4/netfilter/nf_nat_h323.c
> @@ -33,12 +33,20 @@ static int set_addr(struct sk_buff *skb, unsigned int protoff,
> } __attribute__ ((__packed__)) buf;
> const struct tcphdr *th;
> struct tcphdr _tcph;
> + int datalen;
> + struct iphdr *iph = ip_hdr(skb);
>
> buf.ip = ip;
> buf.port = port;
> addroff += dataoff;
>
> if (ip_hdr(skb)->protocol == IPPROTO_TCP) {
> + th = (void *)iph + iph->ihl * 4;
> + datalen = skb->len - (iph->ihl * 4 + th->doff * 4);
You cannot trust the information that is available in the header. If
this is bogus this check will be defeated. That's why we pass this
protoff parameters to each function.
You also refer to get_h225_addr() in your description. That function
always copies 4 or 16 bytes, so I would appreciate if you can describe
the possible issue further.
Thanks.
^ permalink raw reply
* Re: [PATCH net v3.16]r8169: Not enable/disable bus mastering when is enabled on BIOS
From: Francois Romieu @ 2016-03-12 12:15 UTC (permalink / raw)
To: Corcodel Marian; +Cc: netdev
In-Reply-To: <20160312124828.07e467a1@192-168-0-108.rdsnet.ro>
Corcodel Marian <asd@marian1000.go.ro> :
[...]
> For mee this patch is very important , decrease time to autonegociation
> and start nic on full speed alltimes.
Really ? The commit message did not tell much about it.
How much did time decrease ? How did you measure it ?
Against which chipset(s) ?
On which motherboard ?
How does it behave on current kernel ?
How many different patches are you testing at the same time ?
Who was able to reproduce it ?
How do you explain it ?
--
Ueimor
^ permalink raw reply
* Re: userns, netns, and quick physical memory consumption by unprivileged user
From: Pablo Neira Ayuso @ 2016-03-12 11:41 UTC (permalink / raw)
To: Florian Westphal
Cc: Yuriy M. Kaminskiy, netdev, containers, linux-kernel,
netfilter-devel
In-Reply-To: <20160311153406.GB6620@breakpoint.cc>
On Fri, Mar 11, 2016 at 04:34:06PM +0100, Florian Westphal wrote:
> Yuriy M. Kaminskiy <yumkam@gmail.com> wrote:
> > BTW, all those hash/conntrack/etc default sizes was calculated from
> > physical memory size in assumption there will be only *one* instance of
> > those tables. Obviously, introduction of network namespaces (and
> > especially unprivileged user-ns) thrown this assumption in the window
> > (and here comes that "falling back to vmalloc" message again; in pre-netns
> > world, those tables were allocated *once* on early system startup, with
> > typically plenty of free and unfragmented memory).
>
> No idea how to fix this expect by removing conntrack support in net
> namespaces completely.
>
> I'd disallow all write accesses to skb->nfct (NAT, CONNMARK,
> CONNSECMARK, ...) and then no longer clear skb->nfct when forwarding
> packet from init_ns to container.
>
> Containers could then still test conntrack as seen from init namespace pov
> in PREROUTING/FORWARD/INPUT (but not OUTPUT, obviously).
>
> [ OUTPUT *might* be doable as well by allowing NEW creation in output
> but skipping nat and deferring the confirmation/commit of the new
> entry to the table until skb leaves initns ]
>
> We could key conntrack entries to initns conntrack table
> instead of adding one new table per netns, but seems like this only
> replaces one problem with a new one (filling/blocking initns table from
> another netns).
We can add a global perns limit in terms of conntrack entries that can
only be set via CAP_NET_ADMIN from the initns. Thus, we avoid the
filling/blocking from another netns, or hide this knob to
unpriviledged userns somehow.
In the previous netfilter workshop I remember we agreed on going
towards having a single conntrack table for netns, so I suggest we
follow that direction.
^ permalink raw reply
* Re: [PATCH net v3.16]r8169: Not enable/disable bus mastering when is enabled on BIOS
From: Corcodel Marian @ 2016-03-12 10:48 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20160312094401.GA15947@electric-eye.fr.zoreil.com>
On Sat, 12 Mar 2016 10:44:01 +0100
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Corcodel Marian <asd@marian1000.go.ro> :
> > This patch not enable/disable bus mastering when is enabled on
> > BIOS..
>
> It bloats the driver without any benefit.
>
For mee this patch is very important , decrease time to autonegociation
and start nic on full speed alltimes.
^ permalink raw reply
* [patch net-next] rocker: move ageing_time from struct rocker to struct ofdpa
From: Jiri Pirko @ 2016-03-12 11:03 UTC (permalink / raw)
To: netdev; +Cc: davem, sfeldma, idosch, eladr
From: Jiri Pirko <jiri@mellanox.com>
This is OF-DPA specific, used only there, similar to
ofdpa_port->ageing_time. So move it to OF-DPA code.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/rocker/rocker.h | 1 -
drivers/net/ethernet/rocker/rocker_main.c | 2 --
drivers/net/ethernet/rocker/rocker_ofdpa.c | 11 +++++++----
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker.h b/drivers/net/ethernet/rocker/rocker.h
index 011f1b6..1ab995f 100644
--- a/drivers/net/ethernet/rocker/rocker.h
+++ b/drivers/net/ethernet/rocker/rocker.h
@@ -63,7 +63,6 @@ struct rocker {
struct {
u64 id;
} hw;
- unsigned long ageing_time;
spinlock_t cmd_ring_lock; /* for cmd ring accesses */
struct rocker_dma_ring_info cmd_ring;
struct rocker_dma_ring_info event_ring;
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index c8b1bf4..28b775e 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2733,8 +2733,6 @@ static int rocker_probe(struct pci_dev *pdev, const struct pci_device_id *id)
rocker->hw.id = rocker_read64(rocker, SWITCH_ID);
- rocker->ageing_time = BR_DEFAULT_AGEING_TIME;
-
err = rocker_probe_ports(rocker);
if (err) {
dev_err(&pdev->dev, "failed to probe ports\n");
diff --git a/drivers/net/ethernet/rocker/rocker_ofdpa.c b/drivers/net/ethernet/rocker/rocker_ofdpa.c
index cfde525..0e758bc 100644
--- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
+++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
@@ -188,6 +188,7 @@ struct ofdpa {
DECLARE_HASHTABLE(neigh_tbl, 16);
spinlock_t neigh_tbl_lock; /* for neigh tbl accesses */
u32 neigh_tbl_next_index;
+ unsigned long ageing_time;
};
struct ofdpa_port {
@@ -2105,7 +2106,7 @@ static void ofdpa_fdb_cleanup(unsigned long data)
struct ofdpa_port *ofdpa_port;
struct ofdpa_fdb_tbl_entry *entry;
struct hlist_node *tmp;
- unsigned long next_timer = jiffies + ofdpa->rocker->ageing_time;
+ unsigned long next_timer = jiffies + ofdpa->ageing_time;
unsigned long expires;
unsigned long lock_flags;
int flags = OFDPA_OP_FLAG_NOWAIT | OFDPA_OP_FLAG_REMOVE |
@@ -2492,6 +2493,8 @@ static int ofdpa_init(struct rocker *rocker)
(unsigned long) ofdpa);
mod_timer(&ofdpa->fdb_cleanup_timer, jiffies);
+ ofdpa->ageing_time = BR_DEFAULT_AGEING_TIME;
+
return 0;
}
@@ -2648,12 +2651,12 @@ ofdpa_port_attr_bridge_ageing_time_set(struct rocker_port *rocker_port,
struct switchdev_trans *trans)
{
struct ofdpa_port *ofdpa_port = rocker_port->wpriv;
- struct rocker *rocker = rocker_port->rocker;
+ struct ofdpa *ofdpa = ofdpa_port->ofdpa;
if (!switchdev_trans_ph_prepare(trans)) {
ofdpa_port->ageing_time = clock_t_to_jiffies(ageing_time);
- if (ofdpa_port->ageing_time < rocker->ageing_time)
- rocker->ageing_time = ofdpa_port->ageing_time;
+ if (ofdpa_port->ageing_time < ofdpa->ageing_time)
+ ofdpa->ageing_time = ofdpa_port->ageing_time;
mod_timer(&ofdpa_port->ofdpa->fdb_cleanup_timer, jiffies);
}
--
2.5.0
^ permalink raw reply related
* GOOD NEWS!!!
From: harmyusoff @ 2016-03-12 10:52 UTC (permalink / raw)
I,Mrs Gloria Donated $4,000,000.00 to you, Reply To gloria87@foxmail.com
for More details.
^ permalink raw reply
* Re: [PATCH 2/3] net: hns: add Hisilicon RoCE support
From: Leon Romanovsky @ 2016-03-12 10:43 UTC (permalink / raw)
To: Lijun Ou
Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linux-rdma, linux-kernel, netdev, gongyangming,
xiaokun, tangchaofei, haifeng.wei, yisen.zhuang, yankejian,
lisheng011, charles.chenxin, linuxarm
In-Reply-To: <1457692631-9290-3-git-send-email-oulijun@huawei.com>
On Fri, Mar 11, 2016 at 06:37:10PM +0800, Lijun Ou wrote:
> It added hns_dsaf_roce_reset routine for roce driver.
> RoCE is a feature of hns.
> In hip06 SOC, in roce reset process, it's needed to configure
> dsaf channel reset,port and sl map info.
>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> Signed-off-by: Wei Hu(Xavier) <xavier.huwei@huawei.com>
> Signed-off-by: Lisheng <lisheng011@huawei.com>
> ---
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 84 ++++++++++++++++++++++
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 14 ++++
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 62 +++++++++++++---
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 13 ++++
> 4 files changed, 163 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
> index 38fc5be..a0f0d4f 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
> @@ -12,6 +12,7 @@
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/netdevice.h>
> +#include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> @@ -2593,6 +2594,89 @@ static struct platform_driver g_dsaf_driver = {
>
> module_platform_driver(g_dsaf_driver);
>
> +/**
> + * hns_dsaf_roce_reset - reset dsaf and roce
> + * @dsaf_fwnode: Pointer to framework node for the dasf
> + * @val: 0 - request reset , 1 - drop reset
> + * retuen 0 - success , negative --fail
> + */
> +int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, u32 val)
> +{
> + struct dsaf_device *dsaf_dev;
> + struct platform_device *pdev;
> + unsigned int mp;
> + unsigned int sl;
> + unsigned int credit;
> + int i;
> + const u32 port_map[DSAF_ROCE_CREDIT_CHN][DSAF_ROCE_CHAN_MODE] = {
> + {0, 0, 0},
> + {1, 0, 0},
> + {2, 1, 0},
> + {3, 1, 0},
> + {4, 2, 1},
> + {4, 2, 1},
> + {5, 3, 1},
> + {5, 3, 1},
> + };
> + const u32 sl_map[DSAF_ROCE_CREDIT_CHN][DSAF_ROCE_CHAN_MODE] = {
> + {0, 0, 0},
> + {0, 1, 1},
> + {0, 0, 2},
> + {0, 1, 3},
> + {0, 0, 0},
> + {1, 1, 1},
> + {0, 0, 2},
> + {1, 1, 3},
> + };
Do you have a plan to send a version with enums/defines for this
numbers? Especially for _CHAN_MODE.
^ permalink raw reply
* Re: [PATCH 1/3] infiniband: IB/hns: add Hisilicon RoCE support
From: Leon Romanovsky @ 2016-03-12 10:39 UTC (permalink / raw)
To: Lijun Ou
Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linux-rdma, linux-kernel, netdev, gongyangming,
xiaokun, tangchaofei, haifeng.wei, yisen.zhuang, yankejian,
lisheng011, charles.chenxin, linuxarm
In-Reply-To: <1457692631-9290-2-git-send-email-oulijun@huawei.com>
On Fri, Mar 11, 2016 at 06:37:09PM +0800, Lijun Ou wrote:
> The driver for Hisilicon RoCE is a platform driver.
> The driver will support mulitple versions of hardware. Currently only "v1"
> for hip06 SOC is supported.
> The driver includes two parts: common driver and hardware-specific
> operations. hns_roce_v1_hw.c and hns_roce_v1_hw.h are files for
> hardware-specific operations only for v1 engine, and other files(.c and .h)
> for common algorithm and common hardware operations
>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> Signed-off-by: Wei Hu(Xavier) <xavier.huwei@huawei.com>
> Signed-off-by: Znlong <zhaonenglong@huawei.com>
> ---
> drivers/infiniband/Kconfig | 2 +-
> drivers/infiniband/hw/Makefile | 1 +
> drivers/infiniband/hw/hisilicon/hns/Kconfig | 10 +
> drivers/infiniband/hw/hisilicon/hns/Makefile | 9 +
> drivers/infiniband/hw/hisilicon/hns/hns_roce_ah.c | 114 +
> .../infiniband/hw/hisilicon/hns/hns_roce_alloc.c | 253 ++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_cmd.c | 354 +++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_cmd.h | 163 ++
> .../infiniband/hw/hisilicon/hns/hns_roce_common.h | 704 +++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_cq.c | 454 +++
> .../infiniband/hw/hisilicon/hns/hns_roce_device.h | 840 ++++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_eq.c | 798 ++++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_eq.h | 138 +
> drivers/infiniband/hw/hisilicon/hns/hns_roce_icm.c | 608 ++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_icm.h | 121 +
> .../infiniband/hw/hisilicon/hns/hns_roce_main.c | 1124 ++++++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_mr.c | 637 +++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_pd.c | 129 +
> drivers/infiniband/hw/hisilicon/hns/hns_roce_qp.c | 890 ++++++
> .../infiniband/hw/hisilicon/hns/hns_roce_user.h | 31 +
> .../infiniband/hw/hisilicon/hns/hns_roce_v1_hw.c | 2992 ++++++++++++++++++++
> .../infiniband/hw/hisilicon/hns/hns_roce_v1_hw.h | 1068 +++++++
> 22 files changed, 11439 insertions(+), 1 deletion(-)
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/Kconfig
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/Makefile
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_ah.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_alloc.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_cmd.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_cmd.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_common.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_cq.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_device.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_eq.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_eq.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_icm.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_icm.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_main.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_mr.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_pd.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_qp.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_user.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_v1_hw.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_v1_hw.h
>
> diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
> index 8a8440c..c7a24bb 100644
> --- a/drivers/infiniband/Kconfig
> +++ b/drivers/infiniband/Kconfig
> @@ -73,7 +73,7 @@ source "drivers/infiniband/hw/mlx5/Kconfig"
> source "drivers/infiniband/hw/nes/Kconfig"
> source "drivers/infiniband/hw/ocrdma/Kconfig"
> source "drivers/infiniband/hw/usnic/Kconfig"
> -
No need to remove this line. It separates HW from ULPs.
> +source "drivers/infiniband/hw/hisilicon/hns/Kconfig"
> source "drivers/infiniband/ulp/ipoib/Kconfig"
>
> source "drivers/infiniband/ulp/srp/Kconfig"
<snip>
> +int hns_roce_bitmap_alloc_range(
> + struct hns_roce_bitmap *bitmap,
> + int cnt, int align, u32 *obj)
You have indentation issues.
> +{
> + int i;
> + int ret = 0;
> +
> + if (likely(cnt == 1 && align == 1))
> + return hns_roce_bitmap_alloc(bitmap, obj);
> +
> + spin_lock(&bitmap->lock);
> +
> + *obj = bitmap_find_next_zero_area(bitmap->table, bitmap->max,
> + bitmap->last, cnt, align - 1);
> + if (*obj >= bitmap->max) {
> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> + & bitmap->mask;
> + *obj = bitmap_find_next_zero_area(bitmap->table, bitmap->max, 0,
> + cnt, align - 1);
> + }
> +
> + if (*obj < bitmap->max) {
> + for (i = 0; i < cnt; i++)
> + set_bit(*obj + i, bitmap->table);
> +
> + if (*obj == bitmap->last) {
> + bitmap->last = (*obj + cnt);
> + if (bitmap->last >= bitmap->max)
> + bitmap->last = 0;
> + }
> + *obj |= bitmap->top;
> + } else {
> + ret = -1;
> + }
> +
> + spin_unlock(&bitmap->lock);
> +
> + return ret;
> +}
> +
> +void hns_roce_bitmap_free_range(
> + struct hns_roce_bitmap *bitmap,
> + u32 obj,
> + int cnt)
> +{
> + int i;
> +
> + obj &= bitmap->max + bitmap->reserved_top - 1;
> +
> + spin_lock(&bitmap->lock);
> + for (i = 0; i < cnt; i++)
> + clear_bit(obj + i, bitmap->table);
> +
> + bitmap->last = min(bitmap->last, obj);
> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> + & bitmap->mask;
> + spin_unlock(&bitmap->lock);
> +}
> +
> +int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num,
> + u32 mask, u32 reserved_bot,
> + u32 reserved_top)
> +{
> + u32 i;
> +
> + if (num != roundup_pow_of_two(num))
> + return -EINVAL;
> +
> + bitmap->last = 0;
> + bitmap->top = 0;
> + bitmap->max = num - reserved_top;
> + bitmap->mask = mask;
> + bitmap->reserved_top = reserved_top;
> + spin_lock_init(&bitmap->lock);
> + bitmap->table =
> + kzalloc(BITS_TO_LONGS(bitmap->max) * sizeof(long), GFP_KERNEL);
Here and below, please consider to use kcalloc.
> + if (!bitmap->table)
> + return -ENOMEM;
> +
> + for (i = 0; i < reserved_bot; ++i)
^ permalink raw reply
* Re: [PATCHv3 (net.git) 2/2] stmmac: fix MDIO settings
From: Frank Schäfer @ 2016-03-12 10:50 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev
Cc: gabriel.fernandez, afaerber, dinh.linux, davem, preid
In-Reply-To: <1457703196-15008-3-git-send-email-peppe.cavallaro@st.com>
Hi Giuseppe,
Am 11.03.2016 um 14:33 schrieb Giuseppe Cavallaro:
> Initially the phy_bus_name was added to manipulate the
> driver name but It was recently just used to manage the
> fixed-link and then to take some decision at run-time
> inside the main (for example to skip EEE).
> So the patch uses the is_pseudo_fixed_link and removes
> removes the phy_bus_name variable not necessary anymore.
>
> The driver can manage the mdio registration by using phy-handle,
> dwmac-mdio and own parameter e.g. snps,phy-addr.
> This patch takes care about all these possible configurations
> and fixes the mdio registration in case of there is a real
> transceiver or a switch (that needs to be managed by using
> fixed-link).
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Reviewed-by: Andreas Färber <afaerber@suse.de>
> Tested-by: Frank Schäfer <fschaefer.oss@googlemail.com>
> Cc: Gabriel Fernandez <gabriel.fernandez@linaro.org>
> Cc: Dinh Nguyen <dinh.linux@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Phil Reid <preid@electromag.com.au>
> ---
>
> V2: use is_pseudo_fixed_link
> V3: parse device-tree driver parameters to allocate PHY resources considering
> DSA case (+ fixed-link).
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +--
> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 19 +-----
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 77 ++++++++++++++++----
> include/linux/stmmac.h | 2 +-
> 4 files changed, 68 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index c21015b..389d7d0 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -271,7 +271,6 @@ static void stmmac_eee_ctrl_timer(unsigned long arg)
> */
> bool stmmac_eee_init(struct stmmac_priv *priv)
> {
> - char *phy_bus_name = priv->plat->phy_bus_name;
> unsigned long flags;
> bool ret = false;
>
> @@ -283,7 +282,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
> goto out;
>
> /* Never init EEE in case of a switch is attached */
> - if (phy_bus_name && (!strcmp(phy_bus_name, "fixed")))
> + if (priv->phydev->is_pseudo_fixed_link)
> goto out;
>
> /* MAC core supports the EEE feature. */
> @@ -820,12 +819,8 @@ static int stmmac_init_phy(struct net_device *dev)
> phydev = of_phy_connect(dev, priv->plat->phy_node,
> &stmmac_adjust_link, 0, interface);
> } else {
> - if (priv->plat->phy_bus_name)
> - snprintf(bus_id, MII_BUS_ID_SIZE, "%s-%x",
> - priv->plat->phy_bus_name, priv->plat->bus_id);
> - else
> - snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
> - priv->plat->bus_id);
> + snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
> + priv->plat->bus_id);
>
> snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
> priv->plat->phy_addr);
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> index 0faf163..3f5512f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> @@ -198,29 +198,12 @@ int stmmac_mdio_register(struct net_device *ndev)
> struct mii_bus *new_bus;
> struct stmmac_priv *priv = netdev_priv(ndev);
> struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
> + struct device_node *mdio_node = priv->plat->mdio_node;
> int addr, found;
> - struct device_node *mdio_node = NULL;
> - struct device_node *child_node = NULL;
>
> if (!mdio_bus_data)
> return 0;
>
> - if (IS_ENABLED(CONFIG_OF)) {
> - for_each_child_of_node(priv->device->of_node, child_node) {
> - if (of_device_is_compatible(child_node,
> - "snps,dwmac-mdio")) {
> - mdio_node = child_node;
> - break;
> - }
> - }
> -
> - if (mdio_node) {
> - netdev_dbg(ndev, "FOUND MDIO subnode\n");
> - } else {
> - netdev_warn(ndev, "No MDIO subnode found\n");
> - }
> - }
> -
> new_bus = mdiobus_alloc();
> if (new_bus == NULL)
> return -ENOMEM;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 6a52fa1..d2322e9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -96,6 +96,66 @@ static int dwmac1000_validate_ucast_entries(int ucast_entries)
> }
>
> /**
> + * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources
> + * @plat: driver data platform structure
> + * @np: device tree node
> + * @dev: device pointer
> + * Description:
> + * The mdio bus will be allocated in case of a phy transceiver is on board;
> + * it will be NULL if the fixed-link is configured.
> + * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated
> + * in any case (for DSA, mdio must be registered even if fixed-link).
> + * The table below sums the supported configurations:
> + * -------------------------------
> + * snps,phy-addr | Y
> + * -------------------------------
> + * phy-handle | Y
> + * -------------------------------
> + * fixed-link | N
> + * -------------------------------
> + * snps,dwmac-mdio |
> + * even if | Y
> + * fixed-link |
> + * -------------------------------
> + *
> + * It returns true in case of the mdio needs to be registered in the main.
> + */
> +static bool stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> + struct device_node *np, struct device *dev)
> +{
> + bool ret = true;
> +
> + /* If phy-handle property is passed from DT, use it as the PHY */
> + plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
> + if (plat->phy_node)
> + dev_dbg(dev, "Found phy-handle subnode\n");
> +
> + /* If phy-handle is not specified, check if we have a fixed-phy */
> + if (!plat->phy_node && of_phy_is_fixed_link(np)) {
> + if ((of_phy_register_fixed_link(np) < 0))
> + return -ENODEV;
> +
> + dev_dbg(dev, "Found fixed-link subnode\n");
> + plat->phy_node = of_node_get(np);
> +
> + ret = false;
> + }
> +
> + /* If snps,dwmac-mdio is passed from DT, always register the MDIO */
> + for_each_child_of_node(np, plat->mdio_node) {
> + if (of_device_is_compatible(plat->mdio_node, "snps,dwmac-mdio"))
> + break;
> + }
> +
> + if (plat->mdio_node) {
> + dev_dbg(dev, "Found MDIO subnode\n");
> + ret = true;
> + }
> +
> + return ret;
> +}
> +
> +/**
> * stmmac_probe_config_dt - parse device-tree driver parameters
> * @pdev: platform_device structure
> * @plat: driver data platform structure
> @@ -129,30 +189,19 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
> /* Default to phy auto-detection */
> plat->phy_addr = -1;
>
> - /* If we find a phy-handle property, use it as the PHY */
> - plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
> -
> - /* If phy-handle is not specified, check if we have a fixed-phy */
> - if (!plat->phy_node && of_phy_is_fixed_link(np)) {
> - if ((of_phy_register_fixed_link(np) < 0))
> - return ERR_PTR(-ENODEV);
> -
> - plat->phy_node = of_node_get(np);
> - }
> -
> /* "snps,phy-addr" is not a standard property. Mark it as deprecated
> * and warn of its use. Remove this when phy node support is added.
> */
> if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
> dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
>
> - if ((plat->phy_node && !of_phy_is_fixed_link(np)) || plat->phy_bus_name)
> - plat->mdio_bus_data = NULL;
> - else
> + /* To Configure PHY by using all device-tree supported properties */
> + if (stmmac_dt_phy(plat, np, &pdev->dev)) {
> plat->mdio_bus_data =
> devm_kzalloc(&pdev->dev,
> sizeof(struct stmmac_mdio_bus_data),
> GFP_KERNEL);
> + }
>
> of_property_read_u32(np, "tx-fifo-depth", &plat->tx_fifo_size);
>
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index eead8ab..8b1ff2b 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -94,12 +94,12 @@ struct stmmac_dma_cfg {
> };
>
> struct plat_stmmacenet_data {
> - char *phy_bus_name;
> int bus_id;
> int phy_addr;
> int interface;
> struct stmmac_mdio_bus_data *mdio_bus_data;
> struct device_node *phy_node;
> + struct device_node *mdio_node;
> struct stmmac_dma_cfg *dma_cfg;
> int clk_csr;
> int has_gmac;
v3 fixes the "libphy: PHY stmmac-0:ffffffff not found" issue on the
Banana Pi board, too.
Regards,
Frank
^ permalink raw reply
* Re: [PATCH 0/3] infiniband: IB/hns: Hisilicon RoCE support
From: Leon Romanovsky @ 2016-03-12 10:20 UTC (permalink / raw)
To: Lijun Ou
Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linux-rdma, linux-kernel, netdev, gongyangming,
xiaokun, tangchaofei, haifeng.wei, yisen.zhuang, yankejian,
lisheng011, charles.chenxin, linuxarm
In-Reply-To: <1457692631-9290-1-git-send-email-oulijun@huawei.com>
On Fri, Mar 11, 2016 at 06:37:08PM +0800, Lijun Ou wrote:
1) It is redundant to write "infiniband" and "IB" in one title to mention
relevant subsystem, since it is the same.
Please take a look on the other submissions here on the list and use
similar construction.
2) Please use version number in the titles [PATCH vXXX]
> The Hisilicon Network Substem(hns) is a long term evolution IP which is
> supposed to be used in Hisilicon ICT SoC. RoCE is a feature of hns.
> The driver for Hisilicon RoCE engine is a platform driver.
> The driver will support mulitple versions of hns. Currently only "v1"
> for hip06 SOC is supported.
>
>
> Changes v1 -> v2:
> 1. adjust the formats of roce driver code by the experts reviewing
> 2. modify the bindings file with roce dts. add the attribute named
> interrput-names.
> 3. modify the way of defining port mode in hns_dsaf_main.c
> 4. move the Kconfig file into the hns directory and send it with roce
> driver code file together.
>
>
> Lijun Ou (3):
> infiniband: IB/hns: add Hisilicon RoCE support
> net: hns: add Hisilicon RoCE support
> infiniband: IB/hns: add Hisilicon RoCE support with bindings
>
^ permalink raw reply
* [PATCH -next] bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict
From: Florian Westphal @ 2016-03-12 10:14 UTC (permalink / raw)
To: netdev; +Cc: stephen, Florian Westphal, Felix Fietkau, Zefir Kurtisi
Zefir Kurtisi reported kernel panic with an openwrt specific patch.
However, it turns out that mainline has a similar bug waiting to happen.
Once NF_HOOK() returns the skb is in undefined state and must not be
used. Moreover, the okfn must consume the skb to support async
processing (NF_QUEUE).
Current okfn in this spot doesn't consume it and caller assumes that
NF_HOOK return value tells us if skb was freed or not, but thats wrong.
It "works" because no in-tree user registers a NFPROTO_BRIDGE hook at
LOCAL_IN that returns STOLEN or NF_QUEUE verdicts.
Once we add NF_QUEUE support for nftables bridge this will break --
NF_QUEUE holds the skb for async processing, caller will erronoulsy
return RX_HANDLER_PASS and on reinject netfilter will access free'd skb.
Fix this by pushing skb up the stack in the okfn instead.
NB: It also seems dubious to use LOCAL_IN while bypassing PRE_ROUTING
completely in this case but this is how its been forever so it seems
preferable to not change this.
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/bridge/br_input.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f7fba74..1607977 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -222,7 +222,10 @@ static int br_handle_local_finish(struct net *net, struct sock *sk, struct sk_bu
/* check if vlan is allowed, to avoid spoofing */
if (p->flags & BR_LEARNING && br_should_learn(p, skb, &vid))
br_fdb_update(p->br, p, eth_hdr(skb)->h_source, vid, false);
- return 0; /* process further */
+
+ BR_INPUT_SKB_CB(skb)->brdev = p->br->dev;
+ br_pass_frame_up(skb);
+ return 0;
}
/*
@@ -284,14 +287,9 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
}
/* Deliver packet to local host only */
- if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN,
- dev_net(skb->dev), NULL, skb, skb->dev, NULL,
- br_handle_local_finish)) {
- return RX_HANDLER_CONSUMED; /* consumed by filter */
- } else {
- *pskb = skb;
- return RX_HANDLER_PASS; /* continue processing */
- }
+ NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, dev_net(skb->dev),
+ NULL, skb, skb->dev, NULL, br_handle_local_finish);
+ return RX_HANDLER_CONSUMED;
}
forward:
--
2.4.10
^ permalink raw reply related
* Re: [PATCH net 0/3] bridge: ageing timer regression fix
From: Jiri Pirko @ 2016-03-12 9:46 UTC (permalink / raw)
To: David Miller; +Cc: stephen, netdev, jiri
In-Reply-To: <20160311.150448.895454572947313792.davem@davemloft.net>
Fri, Mar 11, 2016 at 09:04:48PM CET, davem@davemloft.net wrote:
>From: Stephen Hemminger <stephen@networkplumber.org>
>Date: Tue, 8 Mar 2016 12:59:32 -0800
>
>> This fixes regression in how ageing timer is managed.
>> Backing out the change required fixing switch drivers as well.
>
>Series applied, thanks.
>
>Jiri, since I applied this to net-next, I had to deal with the conflicts
>created by your world splitup of the rocker driver. I wasn't sure, while
>doing so, whether you'd like this new ageing_time member to remain in the
>rocker struct, as in Stephen's patch, or to be placed in the ofdpa struct.
>I choose the former, send me a patch if you want the latter.
Yeah, it belongs into ofdpa. I'll send you patch in a jiff. Thanks!
^ permalink raw reply
* Re: [PATCH net v3.16]r8169: Not enable/disable bus mastering when is enabled on BIOS
From: Francois Romieu @ 2016-03-12 9:44 UTC (permalink / raw)
To: Corcodel Marian; +Cc: netdev
In-Reply-To: <1457764426-6578-1-git-send-email-asd@marian1000.go.ro>
Corcodel Marian <asd@marian1000.go.ro> :
> This patch not enable/disable bus mastering when is enabled on BIOS..
It bloats the driver without any benefit.
--
Ueimor
^ permalink raw reply
* Re: [PATCH v6 net-next 0/2] tcp: Redundant Data Bundling (RDB)
From: Jonas Markussen @ 2016-03-12 9:23 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Bendik Rønning Opstad, David S. Miller, netdev, Eric Dumazet,
Neal Cardwell, Andreas Petlund, Carsten Griwodz,
Pål Halvorsen, Kristian Evensen, Kenneth Klette Jonassen
In-Reply-To: <CAK6E8=eq3NGJDwreh6UL2hAHXEiPbRZPbXe2pc5aUPBgNoWtGA@mail.gmail.com>
> On 10 Mar 2016, at 03:27, Yuchung Cheng <ycheng@google.com> wrote:
>
> So my question is still if thin-stream app has enough inflight to use
> ack-triggered recovery. i.e., it has to send at least twice within an
> RTT.
>
I see. The thin-stream app must send twice before an RTO in order to
use ACK-triggered recovery, My understanding is that the RTO timer
in many cases can be many times the RTT, e.g., for low-RTT networks
where TCP streams defaults to the default minimal RTT value (200 ms).
Of course, the advantage of RDB is greater when the RTT is high.
The benefit of RDB over other mechanisms that improve how quick
thin-streams are able to discover and recover loss, such as the
tcp_thin_dupack and tcp_early_retrans sysctls, is that the sender
using RDB will already have recovered the lost packet by the time a
regular TCP connection detects the packet loss (from DUPACKs) and
reacts accordingly. This reduces the recovery time by at least one
RTT since it avoids the retransmission all together.
Another impacting mechanism here is delayed ACKs, which also
may affect how long it takes before (S)ACKS arrive at the sender.
My understanding is that delayed ACKs will be disabled when
the incoming packet’s is not the expected sequence number, as is
the case for RDB having packets where old and new data is combined.
This improves ACK feedback for the thin-streams using RDB.
> Also have you tested this with non-Linux receivers? Thanks.
>
We have tested the current version with FreeBSD v10 and Windows 10.
The old version was tested with Windows, FreeBSD, OS X and Linux
back in 2010.
We argue that any TCP implementation complying to the RFCs must
be able to handle segments combining old and new data in the
same way they handle TCP repacketization on retransmissions
(tcp_retrans_collapse).
^ permalink raw reply
* pull request: bluetooth-next 2016-03-12
From: Johan Hedberg @ 2016-03-12 6:39 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]
Hi Dave,
Here's the last bluetooth-next pull request for the 4.6 kernel.
- New USB ID for AR3012 in btusb
- New BCM2E55 ACPI ID
- Buffer overflow fix for the Add Advertising command
- Support for a new Bluetooth LE limited privacy mode
- Fix for firmware activation in btmrvl_sdio
- Cleanups to mac802154 & 6lowpan code
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit 798fee48035f0c5fc6787767ff9e27de7e1a4fbb:
Merge tag 'linux-can-next-for-4.6-20160310' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next (2016-03-10 12:41:33 -0500)
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 6a0e78072c2ae7b20b14e0249d8108441ea928d2:
Bluetooth: Fix potential buffer overflow with Add Advertising (2016-03-11 16:28:43 +0100)
----------------------------------------------------------------
Alexander Aring (3):
mac802154: use put and get unaligned functions
6lowpan: debugfs: add missing static
6lowpan: iphc: fix SAM/DAM bit comment
Dmitry Tunin (1):
Bluetooth: btusb: Add a new AR3012 ID 13d3:3472
Johan Hedberg (6):
Bluetooth: Move memset closer to where it's needed
Bluetooth: Fix adding discoverable to adv instance flags
Bluetooth: Add support for limited privacy mode
Bluetooth: Increment management interface revision
Bluetooth: Fix setting correct flags in AD
Bluetooth: Fix potential buffer overflow with Add Advertising
Jérôme de Bretagne (1):
Bluetooth: hci_bcm: Add BCM2E55 ACPI ID used in Lenovo ThinkPad Tablet 8
Wei-Ning Huang (1):
Bluetooth: btmrvl_sdio: fix firmware activation failure
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btmrvl_sdio.c | 2 +-
drivers/bluetooth/btusb.c | 1 +
drivers/bluetooth/hci_bcm.c | 1 +
include/net/bluetooth/hci.h | 1 +
include/net/mac802154.h | 10 +++----
net/6lowpan/debugfs.c | 4 +--
net/6lowpan/iphc.c | 4 +--
net/bluetooth/hci_conn.c | 17 +++++++++---
net/bluetooth/hci_request.c | 56 +++++++++++++++++++++++++++++++++++-----
net/bluetooth/hci_request.h | 2 +-
net/bluetooth/mgmt.c | 26 ++++++++++++++++---
12 files changed, 102 insertions(+), 24 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net v3.16]r8169: Not enable/disable bus mastering when is enabled on BIOS
From: Corcodel Marian @ 2016-03-12 6:33 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu, Corcodel Marian
This patch not enable/disable bus mastering when is enabled on BIOS..
pci_disable_device function also disable bus mastering for, disable bus mastering
is dedicate function.
Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
---
drivers/net/ethernet/realtek/r8169.c | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 02aec96..ec555e7 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -754,6 +754,7 @@ struct rtl8169_private {
struct timer_list timer;
u16 cp_cmd;
bool pcie;
+ bool bios_support;
u16 event_slow;
@@ -3718,13 +3719,27 @@ static void rtl8169_phy_timer(unsigned long __opaque)
rtl_schedule_task(tp, RTL_FLAG_TASK_PHY_PENDING);
}
+static void rtl_disable_device (struct pci_dev *pdev)
+{
+ dev_WARN_ONCE(&pdev->dev, atomic_read(&pdev->enable_cnt) <= 0,
+ "disabling already-disabled device");
+
+ if (atomic_dec_return(&pdev->enable_cnt) != 0)
+ return;
+}
+
static void rtl8169_release_board(struct pci_dev *pdev, struct net_device *dev,
void __iomem *ioaddr)
{
+ struct rtl8169_private *tp = netdev_priv(dev);
+
iounmap(ioaddr);
pci_release_regions(pdev);
pci_clear_mwi(pdev);
- pci_disable_device(pdev);
+ if (!tp->bios_support)
+ pci_disable_device(pdev);
+ else
+ rtl_disable_device(pdev);
free_netdev(dev);
}
@@ -6779,7 +6794,8 @@ static void rtl_wol_shutdown_quirk(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_11:
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
- pci_clear_master(tp->pci_dev);
+ if (!tp->bios_support)
+ pci_clear_master(tp->pci_dev);
RTL_W8(ChipCmd, CmdRxEnb);
/* PCI commit */
@@ -6996,6 +7012,7 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
void __iomem *ioaddr;
int chipset, i;
int rc;
+ u16 cmd;
if (netif_msg_drv(&debug)) {
printk(KERN_INFO "%s Gigabit Ethernet driver %s loaded\n",
@@ -7103,7 +7120,13 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
rtl_ack_events(tp, 0xffff);
- pci_set_master(pdev);
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ if (cmd & PCI_COMMAND_MASTER)
+ tp->bios_support = true;
+ else {
+ tp->bios_support = false;
+ pci_set_master(pdev);
+ }
/*
* Pretend we are using VLANs; This bypasses a nasty bug where
--
2.1.4
^ permalink raw reply related
* Re: Generic TSO (was Re: [net-next PATCH 0/2] GENEVE/VXLAN: Enable outer Tx checksum by default)
From: Alexander Duyck @ 2016-03-12 5:40 UTC (permalink / raw)
To: Tom Herbert; +Cc: Edward Cree, Linux Kernel Network Developers
In-Reply-To: <CALx6S36wJdFnq=2ZkTfijqro1TM1GTqap=aLQ0+NszgWC6Sznw@mail.gmail.com>
On Fri, Mar 11, 2016 at 2:55 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Fri, Mar 11, 2016 at 2:31 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Fri, Mar 11, 2016 at 1:29 PM, Edward Cree <ecree@solarflare.com> wrote:
>>> On 11/03/16 21:09, Alexander Duyck wrote:
>>>> The only real issue with the "generic" TSO is that it isn't going to
>>>> be so generic. We have different devices that will support different
>>>> levels of stuff. For example the ixgbe drivers will need to treat the
>>>> outer tunnel header as one giant L2 header. As a result we will need
>>>> to populate all the fields in the outer header including the outer IP
>>>> ID, checksum, udp->len, and UDP or GRE checksum if requested. For
>>>> i40e I think this gets a bit simpler as they already handle the outer
>>>> IPv4 ID and checksum. I think there we may need to only populate the
>>>> checksum for it to work out correctly. As such I may look at coming
>>>> up with a number of functions so that we can mix and match based on
>>>> what is needed in order to assemble a partially segmented frame.
>>> AIUI, the point of the design is that we _can_ populate everything,
>>> because we're keeping lengths and outer IP ID fixed, so outer checksums
>>> stay the same and the outer tunnel header _is_ just one giant L2 header
>>> which is bit-for-bit identical for each generated segment. So every
>>> devicegets to just be dumb and treat it as opaque.
>>
>> This works so long as the device isn't trying to do anything like
>> insert VLAN tags. Then I think we might have an issue since we don't
>> want to confuse the device and have it trying to insert the tag on the
>> inner frame's Ethernet header.
>>
> In Edward's giant L2 header mode, couldn't VLAN tags just be part of that?
The problem is things like VFs which aren't allowed to insert their
own tags. Having them try to lie about where the network header
actually starts may trigger things like anti-spoof events.
>> I suspect we may have differing levels of "dumb" that we have to deal
>> with. That is all I am saying. By default we could just populate all
>> of the length and checksum fields in the outer header, we would just
>> have to be consistent about what is provided then. In addition there
>> will be the matter of sorting out the IP ID bits. For example some of
>> the i40e parts support tunnel offloads, but not tunnel offloads with
>> checksums enabled. I suspect those parts will end up wanting to
>> handle the outer IP header and UDP length values. As a result there
>> trying to do a "dumb" send may result in us really messing up the IP
>> ID values if we don't take steps to make it a bit smarter.
>>
>>>> The other issue I am working on at the moment to enable all this is to
>>>> fix the differents between csum_tcpudp_magic and csum_ipv6_magic in
>>>> terms of handling packet lengths greater than 65535. Currently we are
>>>> messing up the checksum in relation to IPv6 since we are using the
>>>> truncated uh->len value. I'll be submitting some patches later today
>>>> that will hopefully get that fixed and that in turn should make the
>>>> rest of the segmentation work easier.
>>> Again, in the superpacket we want to calculate the checksum based on the
>>> subsegment length, rather than the length of the superpacket. The idea
>>> is to create the header for an MSS-sized segment, then follow it with an
>>> inner IP & TCP header, and n*MSS bytes of payload. (This of course
>>> produces a superpacket that's not what you'd send over a link with a 64k
>>> MTU, unlike how we do it today.)
>>
>> The question is at what point do we do the chopping. Should we be
>> doing this in the drivers or somewhere higher in the stack like we do
>> for standard GSO segmentation. I would think we would need to add
>> another bit that says we can do GSO with custom outer headers since I
>> can see VLANs being a possible issue otherwise.
>>
>>> Then hw just chops up the payload, fixes up the inner headers, and glues
>>> the "L2" header on each packet.
>>
>> Yea, it sounds really straight forward and easy. It isn't till you
>> start digging into the actual code that it gets a bit hairy.
>>
>> What this effectively is is another form of TSO where each driver will
>> want to do things a little differently. Alot of it has to do with the
>> fact that this is kind of a nasty hack that we are trying to add since
>> many devices won't like the fact that we are lying about the size of
>> our actual L2 header so things like VLAN tag insertion are going to
>> end up blowing back on us.
>>
> Right, the point is that we're trying to get out of the model where
> every driver/device implements TSO differently, supports ad hoc
> protocols, etc. Do you see any other common invasive technique that we
> need to deal with other than VLAN insertion and IP ID?
Well that is the thing. Before we can actually start tinkering with
the outer header we probably need to make sure we set the DF bit and
that it would be honored on the outer headers for IPv4. I don't
believe any of the tunnels are currently doing that so repeating the
IP ID would be the worst possible scenario until that is resolved
since VXLAN tunneled frames can be fragmented while TCP frames cannot
so we really shouldn't be repeating IP IDs for the outer headers.
- Alex
^ permalink raw reply
* Re: [PATCH V3] net: ezchip: adapt driver to little endian architecture
From: Vineet Gupta @ 2016-03-12 5:23 UTC (permalink / raw)
To: Lada.Trimasova
Cc: David Miller, netdev, linux-kernel, Alexey.Brodkin, noamc, talz,
arnd, arcml
In-Reply-To: <20160303.172043.676796529681577242.davem@davemloft.net>
On Friday 04 March 2016 03:50 AM, David Miller wrote:
> From: Lada Trimasova <Lada.Trimasova@synopsys.com>
> Date: Thu, 3 Mar 2016 17:07:46 +0300
>
>> Since ezchip network driver is written with big endian EZChip platform it
>> is necessary to add support for little endian architecture.
>>
>> The first issue is that the order of the bits in a bit field is
>> implementation specific. So all the bit fields are removed.
>> Named constants are used to access necessary fields.
>>
>> And the second one is that network byte order is big endian.
>> For example, data on ethernet is transmitted with most-significant
>> octet (byte) first. So in case of little endian architecture
>> it is important to swap data byte order when we read it from
>> register. In case of unaligned access we can use "get_unaligned_be32"
>> and in other case we can use function "ioread32_rep" which reads all
>> data from register and works either with little endian or big endian
>> architecture.
>>
>> And then when we are going to write data to register we need to restore
>> byte order using the function "put_unaligned_be32" in case of
>> unaligned access and in other case "iowrite32_rep".
>>
>> The last little fix is a space between type and pointer to observe
>> coding style.
>>
>> Signed-off-by: Lada Trimasova <ltrimas@synopsys.com>
>
> Applied to net-next, thanks.
>
@Lada, could you provide the corresponding arch/arc/{boot/dts,configs}/ updates so
we can switch over to this device-model/driver for OSCI platform for 4.6.
Thx,
-Vineet
^ permalink raw reply
* Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket
From: Sowmini Varadhan @ 2016-03-12 4:39 UTC (permalink / raw)
To: Tom Herbert
Cc: Stephen Hemminger, David S. Miller,
Linux Kernel Network Developers
In-Reply-To: <CALx6S37gHYMJdz3MzfjKwLHsw0Pmg0SxvQ036sg35AjRackARQ@mail.gmail.com>
On (03/11/16 20:07), Tom Herbert wrote:
> You are describing your deployment of RDS, not kernel implementation.
> What I see is a very rigid implementation that would make it hard for
> many us to ever even consider deploying. The abilities of applications
> to tune TCP connections is well understood, very prevalent, and really
> fundamental in making TCP based datacenters at large scale.
sorry, historically, OS DDI/DKI's for kernel modules have always
had some way to set up startup parameters at module load time. And
clusters have been around for a while.
So let's just focus on the technical question around module config here,
which involves more than TCP sockets, btw.
> Any way, it was just an idea... ;-)
Thank you.
Moving on,
> Maybe add one module parameter that indicates the module should just
> load but not start, configure whatever is needed via netlink, and then
> send one more netlink command to start operations.
Even that needs an extra daemon.
Without getting into the vast number of questions that it raises (such
as every module with startup params now needs a uspace counterpart?
modprobe-r behavior, namespace behavior? Why netlink for every kernel
module? etc)..
One module parameter is as much a "distribution management"
problem as 10 of them, yes? I hope you see that I dont need that module
param and daemon baggage- I can just use sysctl to set up all my params,
including one bit for module_can_start_now to achieve the same thing.
But it is still more than the handful of lines of code in my patch,
so it would be nice to understand what is the "distribution" issue.
Stepping back, how do we make sysctl fully namespace friendly?
btw setting kernel socket keepalive params via sysctl is not a problem
to implement at all, if it ever shows up as a requirement for customers.
--Sowmini
^ permalink raw reply
* Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket
From: Tom Herbert @ 2016-03-12 4:07 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Stephen Hemminger, David S. Miller,
Linux Kernel Network Developers
In-Reply-To: <20160312034421.GB26486@oracle.com>
On Fri, Mar 11, 2016 at 7:44 PM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (03/11/16 19:21), Tom Herbert wrote:
>> You could consider and alternate model where connection management
>> (connect, listen, etc.) is performed in a userspace daemon and the
>> attached to the kernel (pretty much like KCM does). This moves
>
> You have to remember that, like it or not, RDS has some IB legacy
> compat requirements that cannot be shed easily. The above suggestion
> suddenly requiring an extra daemon per node in a cluster
> involving 100's of nodes with very complex DB setup procedures and
> rigid HA requirements (nodes in the cluster try to reconnect
> on connection failure). An extra daemon, with its own startup requirements
> and additional latency, would be hard to justify for something
> that can otherwise be done with module_param.
>
You are describing your deployment of RDS, not kernel implementation.
What I see is a very rigid implementation that would make it hard for
many us to ever even consider deploying. The abilities of applications
to tune TCP connections is well understood, very prevalent, and really
fundamental in making TCP based datacenters at large scale. Any way,
it was just an idea... ;-)
> As such, the above suggestion is even non-trivial than the "ugly" code
> I referred to in my previous email.
>
> It is actually far simpler to just tell the cluster-setup scripts to just
> refrain from an ifup of the relevant interfaces till all the config
> is set up.
>
> Besides, the basic problem remains: for an arbitrary kernel module
> that has parameters that need to be customized before module init,
> what are the options today?
>
Maybe add one module parameter that indicates the module should just
load but not start, configure whatever is needed via netlink, and then
send one more netlink command to start operations.
> --Sowmini
^ permalink raw reply
* Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket
From: Sowmini Varadhan @ 2016-03-12 3:44 UTC (permalink / raw)
To: Tom Herbert
Cc: Stephen Hemminger, David S. Miller,
Linux Kernel Network Developers
In-Reply-To: <CALx6S37+Zj-OmApDHzb2hq0jSLsbat4M9Xv6ASzB5VGP9HrQqw@mail.gmail.com>
On (03/11/16 19:21), Tom Herbert wrote:
> You could consider and alternate model where connection management
> (connect, listen, etc.) is performed in a userspace daemon and the
> attached to the kernel (pretty much like KCM does). This moves
You have to remember that, like it or not, RDS has some IB legacy
compat requirements that cannot be shed easily. The above suggestion
suddenly requiring an extra daemon per node in a cluster
involving 100's of nodes with very complex DB setup procedures and
rigid HA requirements (nodes in the cluster try to reconnect
on connection failure). An extra daemon, with its own startup requirements
and additional latency, would be hard to justify for something
that can otherwise be done with module_param.
As such, the above suggestion is even non-trivial than the "ugly" code
I referred to in my previous email.
It is actually far simpler to just tell the cluster-setup scripts to just
refrain from an ifup of the relevant interfaces till all the config
is set up.
Besides, the basic problem remains: for an arbitrary kernel module
that has parameters that need to be customized before module init,
what are the options today?
--Sowmini
^ permalink raw reply
* Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket
From: Tom Herbert @ 2016-03-12 3:21 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Stephen Hemminger, David S. Miller,
Linux Kernel Network Developers
In-Reply-To: <20160312024341.GA26486@oracle.com>
On Fri, Mar 11, 2016 at 6:43 PM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (03/11/16 11:09), Stephen Hemminger wrote:
>> Module parameters are a problem for distributions and should only be used
>> as a last resort.
>
> I dont know the history of what the distibution problem is, but I
> did try to use sysctl as an alternative for this. I'm starting to
> believe that this is one case where module params, with all their
> problems, are the least evil option. Here's what I find if I use sysctl:
>
> - being able to tune the sndbuf and rcvbuf actually gives me a noticeable
> 2X perf improvement over the default for DB/Cluster request/response
> transactions, where the classic req size is 8K bytes, response is 256
> bytes, and there are a large number of such concurrent transactions
> queued up on the kernel tcp socket. (The defaults work well for
> larger packet sizes, but as I noted in the commit, packet sizes vary
> in actual deployment).
>
> Assuming I use sysctl:
>
> - by the time the admin gets to execute the sysctl, the kernel listen
> socket for RDS_TCP_PORT would already have been created, and an
> arbitrary number of accept/connect (kernel) endpoints may have been
> created. According to tcp(7), you should be setting the buf sizes before
> connect/listen. So using sysctl means you have to reset a variable
> number of existing cluster connections. All this can be done, but
> adds a large mass of confusing code to reset kernel sockets and
> also get the cluster HA/failover right.
>
> - at first I thought sysctl was attractive because it was netns aware,
> but found that it is only superficially so. The ->proc_handler does
> not pass in the struct net *, and setting up the ctl_table's ->data
> to a per-net var is not simple thing to do. Thus, even though
> register_net_sysctl() takes a net * pointer, my handler has to do
> extra ugly things to get to per-net vars.
>
> I dont know if there is a better alternative than sysctl/module_param
> for achieving what I'm trying to do, which is to set up the params
> for the kernel sockets before creating them. If yes, some
> hints/rtfms would be helpful.
>
You could consider and alternate model where connection management
(connect, listen, etc.) is performed in a userspace daemon and the
attached to the kernel (pretty much like KCM does). This moves
complexity out of kernel, and gives you the flexibility to configure
arbitrarily configure TCP sockets (like the 4 setsockopts in
rds_tcp_keepalive could be configurable). The other cool thing this
would allow is switching an existing TCP connection into RDS mode
(like is done with several protocols on an http port).
Tom
> --Sowmini
>
^ permalink raw reply
* Re: [PATCH net-next] rds-tcp: Add module parameters to control sndbuf/rcvbuf size of RDS-TCP socket
From: Sowmini Varadhan @ 2016-03-12 2:43 UTC (permalink / raw)
To: Stephen Hemminger, davem; +Cc: netdev
In-Reply-To: <20160311110927.5c559421@xeon-e3>
On (03/11/16 11:09), Stephen Hemminger wrote:
> Module parameters are a problem for distributions and should only be used
> as a last resort.
I dont know the history of what the distibution problem is, but I
did try to use sysctl as an alternative for this. I'm starting to
believe that this is one case where module params, with all their
problems, are the least evil option. Here's what I find if I use sysctl:
- being able to tune the sndbuf and rcvbuf actually gives me a noticeable
2X perf improvement over the default for DB/Cluster request/response
transactions, where the classic req size is 8K bytes, response is 256
bytes, and there are a large number of such concurrent transactions
queued up on the kernel tcp socket. (The defaults work well for
larger packet sizes, but as I noted in the commit, packet sizes vary
in actual deployment).
Assuming I use sysctl:
- by the time the admin gets to execute the sysctl, the kernel listen
socket for RDS_TCP_PORT would already have been created, and an
arbitrary number of accept/connect (kernel) endpoints may have been
created. According to tcp(7), you should be setting the buf sizes before
connect/listen. So using sysctl means you have to reset a variable
number of existing cluster connections. All this can be done, but
adds a large mass of confusing code to reset kernel sockets and
also get the cluster HA/failover right.
- at first I thought sysctl was attractive because it was netns aware,
but found that it is only superficially so. The ->proc_handler does
not pass in the struct net *, and setting up the ctl_table's ->data
to a per-net var is not simple thing to do. Thus, even though
register_net_sysctl() takes a net * pointer, my handler has to do
extra ugly things to get to per-net vars.
I dont know if there is a better alternative than sysctl/module_param
for achieving what I'm trying to do, which is to set up the params
for the kernel sockets before creating them. If yes, some
hints/rtfms would be helpful.
--Sowmini
^ permalink raw reply
* Re: [RFC PATCH net-next 0/2] DT MDIO bus of fixed phys
From: Andrew Lunn @ 2016-03-12 0:12 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <56E35712.5080508@gmail.com>
> >> Humm, if that's the problem we want to solve, we could introduce a
> >> helper function which tries to locate the phy using a 'phy-handle'
> >> property
> >
> > I don't follow you. Where do you get a phandle from to use with
> > phy-handle?
>
> >From the caller of the function: the consumer of that phy-handle and/or
> fixed-link property which is either an Ethernet MAC driver or a DSA's
> switch port node.
I still don't get it. Lets take a real example. I currently have this
in one of my dts files:
&fec1 {
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec1>;
status = "okay";
fixed-link {
speed = <100>;
full-duplex;
};
};
and we now want to use a phy-handle:
&fec1 {
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec1>;
status = "okay";
phy-handle = <XZY>;
};
What do i use as XZY, so that it somehow resolves to a fixed-phy?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH v2 0/3] net/phy: Improvements to Cavium Thunder MDIO code.
From: David Daney @ 2016-03-12 0:08 UTC (permalink / raw)
To: David Daney
Cc: David S. Miller, netdev, linux-arm-kernel, Florian Fainelli,
Robert Richter, Sunil Goutham, Kumar Gala, Ian Campbell,
Mark Rutland, Pawel Moll, Rob Herring, linux-kernel,
Radha Mohan Chintakuntla, David Daney
In-Reply-To: <1457718791-6505-1-git-send-email-ddaney.cavm@gmail.com>
I am going to send a new version of this set.
David Daney
On 03/11/2016 09:53 AM, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> Changes from v1:
>
> - In 1/3 Add back check for non-OF objects in bgx_init_of_phy(). It
> is probably not necessary, but better safe than sorry...
>
> The firmware on many Cavium Thunder systems configures the MDIO bus
> hardware to be probed as a PCI device. In order to use the MDIO bus
> drivers in this configuration, we must add PCI probing to the driver.
>
> There are two parts to this set of three patches:
>
> 1) Cleanup the PHY probing code in thunder_bgx.c to handle the case
> where there is no PHY attached to a port, as well as being more
> robust in the face of driver loading order by use of
> -EPROBE_DEFER.
>
> 2) Split mdio-octeon.c into two drivers, one with platform probing,
> and the other with PCI probing. Common code is shared between the
> two.
>
> Tested on several different Thunder and OCTEON systems, also compile
> tested on x86_64.
>
> David Daney (3):
> net: thunderx: Cleanup PHY probing code.
> phy: mdio-octeon: Refactor into two files/modules
> phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.
>
> .../devicetree/bindings/net/cavium-mdio.txt | 61 ++++-
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 29 ++-
> drivers/net/phy/Kconfig | 22 +-
> drivers/net/phy/Makefile | 2 +
> drivers/net/phy/mdio-cavium.c | 149 +++++++++++
> drivers/net/phy/mdio-cavium.h | 119 +++++++++
> drivers/net/phy/mdio-octeon.c | 280 ++-------------------
> drivers/net/phy/mdio-thunder.c | 154 ++++++++++++
> 8 files changed, 535 insertions(+), 281 deletions(-)
> create mode 100644 drivers/net/phy/mdio-cavium.c
> create mode 100644 drivers/net/phy/mdio-cavium.h
> create mode 100644 drivers/net/phy/mdio-thunder.c
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox