* [PATCH net-next v7 3/3] net sched actions: add time filter for action dumping
From: Jamal Hadi Salim @ 2017-04-25 11:49 UTC (permalink / raw)
To: davem; +Cc: jiri, xiyou.wangcong, eric.dumazet, netdev, Jamal Hadi Salim
In-Reply-To: <1493120988-11765-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
This adds support for filtering based on time since last used.
When we are dumping a large number of actions it is useful to
have the option of filtering based on when the action was last
used to reduce the amount of data crossing to user space.
With this patch the user space app sets the TCA_ROOT_TIME_DELTA
attribute with the value in milliseconds with "time of interest
since now". The kernel converts this to jiffies and does the
filtering comparison matching entries that have seen activity
since then and returns them to user space.
Old kernels and old tc continue to work in legacy mode since
they dont specify this attribute.
Some example (we have 400 actions bound to 400 filters); at
installation time using hacked tc which sets the time of
interest to 120 seconds:
prompt$ hackedtc actions ls action gact | grep index | wc -l
400
go get some coffee and wait for > 120 seconds and try again:
prompt$ hackedtc actions ls action gact | grep index | wc -l
0
Lets see a filter bound to one of these actions:
..
filter pref 10 u32
filter pref 10 u32 fh 800: ht divisor 1
filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 2 success 1)
match 7f000002/ffffffff at 12 (success 1 )
action order 1: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1145 sec used 802 sec
Action statistics:
Sent 84 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
....
that coffee took long, no? It was good.
Now lets ping -c 1 127.0.0.2, then run the actions again:
prompt$ hackedtc actions ls action gact | grep index | wc -l
1
More details please:
prompt$ hackedtc -s actions ls action gact
action order 0: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1270 sec used 30 sec
Action statistics:
Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
And the filter?
filter pref 10 u32
filter pref 10 u32 fh 800: ht divisor 1
filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 4 success 2)
match 7f000002/ffffffff at 12 (success 2 )
action order 1: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1324 sec used 84 sec
Action statistics:
Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
include/uapi/linux/rtnetlink.h | 1 +
net/sched/act_api.c | 22 ++++++++++++++++++++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 5875467..39c7499 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -681,6 +681,7 @@ enum {
#define TCA_ACT_TAB TCA_ROOT_TAB
TCA_ROOT_FLAGS,
TCA_ROOT_COUNT,
+ TCA_ROOT_TIME_DELTA, /* in msecs */
__TCA_ROOT_MAX,
#define TCA_ROOT_MAX (__TCA_ROOT_MAX - 1)
};
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 2756213..c0aee2c 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -84,6 +84,7 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
{
int err = 0, index = -1, i = 0, s_i = 0, n_i = 0;
u32 act_flags = cb->args[2];
+ unsigned long jiffy_since = cb->args[3];
struct nlattr *nest;
spin_lock_bh(&hinfo->lock);
@@ -101,6 +102,11 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
if (index < s_i)
continue;
+ if (jiffy_since &&
+ time_after(jiffy_since,
+ (unsigned long)p->tcfa_tm.lastuse))
+ continue;
+
nest = nla_nest_start(skb, n_i);
if (nest == NULL)
goto nla_put_failure;
@@ -118,9 +124,11 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
}
}
done:
+ if (index > 0)
+ cb->args[0] = index + 1;
+
spin_unlock_bh(&hinfo->lock);
if (n_i) {
- cb->args[0] += n_i;
if (act_flags & TCA_FLAG_LARGE_DUMP_ON)
cb->args[1] = n_i;
}
@@ -999,7 +1007,8 @@ static int tcf_action_add(struct net *net, struct nlattr *nla,
}
static const struct nla_policy tcaa_policy[TCA_ROOT_MAX + 1] = {
- [TCA_ROOT_FLAGS] = { .type = NLA_U32 },
+ [TCA_ROOT_FLAGS] = { .type = NLA_U32 },
+ [TCA_ROOT_TIME_DELTA] = { .type = NLA_U32 },
};
static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
@@ -1099,7 +1108,9 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
struct tcamsg *t = (struct tcamsg *) nlmsg_data(cb->nlh);
struct nlattr *count_attr = NULL;
struct nlattr *tb[TCA_ROOT_MAX + 1];
+ unsigned long jiffy_since = 0;
struct nlattr *kind = NULL;
+ u32 msecs_since = 0;
u32 act_flags = 0;
u32 act_count = 0;
@@ -1124,12 +1135,19 @@ static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
if (act_flags && !tca_flags_valid(act_flags))
return -EINVAL;
+ if (tb[TCA_ROOT_TIME_DELTA])
+ msecs_since = nla_get_u32(tb[TCA_ROOT_TIME_DELTA]);
+
nlh = nlmsg_put(skb, NETLINK_CB(cb->skb).portid, cb->nlh->nlmsg_seq,
cb->nlh->nlmsg_type, sizeof(*t), 0);
if (!nlh)
goto out_module_put;
+ if (msecs_since)
+ jiffy_since = jiffies - msecs_to_jiffies(msecs_since);
+
cb->args[2] = act_flags;
+ cb->args[3] = jiffy_since;
t = nlmsg_data(nlh);
t->tca_family = AF_UNSPEC;
t->tca__pad1 = 0;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v7 1/3] net sched actions: Use proper root attribute table for actions
From: Jamal Hadi Salim @ 2017-04-25 11:49 UTC (permalink / raw)
To: davem; +Cc: jiri, xiyou.wangcong, eric.dumazet, netdev, Jamal Hadi Salim
In-Reply-To: <1493120988-11765-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Bug fix for an issue which has been around for about a decade.
We got away with it because the enumeration was larger than needed.
Fixes: 7ba699c604ab ("[NET_SCHED]: Convert actions from rtnetlink to new netlink API")
Suggested-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
net/sched/act_api.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 82b1d48..9ce22b7 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -997,7 +997,7 @@ static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
struct netlink_ext_ack *extack)
{
struct net *net = sock_net(skb->sk);
- struct nlattr *tca[TCA_ACT_MAX + 1];
+ struct nlattr *tca[TCAA_MAX + 1];
u32 portid = skb ? NETLINK_CB(skb).portid : 0;
int ret = 0, ovr = 0;
@@ -1005,7 +1005,7 @@ static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
!netlink_capable(skb, CAP_NET_ADMIN))
return -EPERM;
- ret = nlmsg_parse(n, sizeof(struct tcamsg), tca, TCA_ACT_MAX, NULL,
+ ret = nlmsg_parse(n, sizeof(struct tcamsg), tca, TCAA_MAX, NULL,
extack);
if (ret < 0)
return ret;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v7 1/3] net sched actions: Use proper root attribute table for actions
From: Jamal Hadi Salim @ 2017-04-25 11:49 UTC (permalink / raw)
To: davem; +Cc: jiri, xiyou.wangcong, eric.dumazet, netdev, Jamal Hadi Salim
In-Reply-To: <1493120988-11765-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Bug fix for an issue which has been around for about a decade.
We got away with it because the enumeration was larger than needed.
Fixes: 7ba699c604ab ("[NET_SCHED]: Convert actions from rtnetlink to new netlink API")
Suggested-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
net/sched/act_api.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 82b1d48..9ce22b7 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -997,7 +997,7 @@ static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
struct netlink_ext_ack *extack)
{
struct net *net = sock_net(skb->sk);
- struct nlattr *tca[TCA_ACT_MAX + 1];
+ struct nlattr *tca[TCAA_MAX + 1];
u32 portid = skb ? NETLINK_CB(skb).portid : 0;
int ret = 0, ovr = 0;
@@ -1005,7 +1005,7 @@ static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
!netlink_capable(skb, CAP_NET_ADMIN))
return -EPERM;
- ret = nlmsg_parse(n, sizeof(struct tcamsg), tca, TCA_ACT_MAX, NULL,
+ ret = nlmsg_parse(n, sizeof(struct tcamsg), tca, TCAA_MAX, NULL,
extack);
if (ret < 0)
return ret;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v7 0/3] net sched actions: improve dump performance
From: Jamal Hadi Salim @ 2017-04-25 11:49 UTC (permalink / raw)
To: davem; +Cc: jiri, xiyou.wangcong, eric.dumazet, netdev, Jamal Hadi Salim
From: Jamal Hadi Salim <jhs@mojatatu.com>
changes since v6:
-----------------
1) DaveM:
New rules for netlink messages. From now on we are going to start
checking for bits that are not used and rejecting anything we dont
understand. In the future this is going to require major changes
to user space code (tc etc). This is just a start.
To quote, David:
"
Again, bits you aren't using now, make sure userspace doesn't
set them. And if it does, reject.
"
2) Jiri:
a)Fix the commit message to properly use "Fixes" description
b)Align assignments for nla_policy
Changes since v5:
----------------
0)
Remove use of BIT() because it is kernel specific. Requires a separate
patch (Jiri can submit that in his cleanups)
1)To paraphrase Eric D.
"memcpy(nla_data(count_attr), &cb->args[1], sizeof(u32));
wont work on 64bit BE machines because cb->args[1]
(which is 64 bit is larger in size than sizeof(u32))"
Fixed
2) Jiri Pirko
i) Spotted a bug fix mixed in the patch for wrong TLV
fix. Add patch 1/3 to address this. Make part of this
series because of dependencies.
ii) Rename ACT_LARGE_DUMP_ON -> TCA_FLAG_LARGE_DUMP_ON
iii) Satisfy Jiri's obsession against the noun "tcaa"
a)Rename struct nlattr *tcaa --> struct nlattr *tb
b)Rename TCAA_ACT_XXX -> TCA_ROOT_XXX
Changes since v4:
-----------------
1) Eric D.
pointed out that when all skb space is used up by the dump
there will be no space to insert the TCAA_ACT_COUNT attribute.
2) Jiri:
i) Change:
enum {
TCAA_UNSPEC,
TCAA_ACT_TAB,
TCAA_ACT_FLAGS,
TCAA_ACT_COUNT,
TCAA_ACT_TIME_FILTER,
__TCAA_MAX
};
#define TCAA_MAX (__TCAA_MAX - 1)
#define ACT_LARGE_DUMP_ON (1 << 0)
to:
enum {
TCAA_UNSPEC,
TCAA_ACT_TAB,
#define TCA_ACT_TAB TCAA_ACT_TAB
TCAA_ACT_FLAGS,
TCAA_ACT_COUNT,
__TCAA_MAX,
#define TCAA_MAX (__TCAA_MAX - 1)
};
#define ACT_LARGE_DUMP_ON BIT(0)
Jiri plans to followup with the rest of the code to make the
style consistent.
ii) Rename attribute TCAA_ACT_TIME_FILTER --> TCAA_ACT_TIME_DELTA
iii) Rename variable jiffy_filter --> jiffy_since
iv) Rename msecs_filter --> msecs_since
v) get rid of unused cb->args[0] and rename cb->args[4] to cb->args[0]
Jamal Hadi Salim (3):
net sched actions: User proper root attribute table for actions
net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
net sched actions: add time filter for action dumping
include/uapi/linux/rtnetlink.h | 22 ++++++++++++--
net/sched/act_api.c | 66 +++++++++++++++++++++++++++++++++++-------
2 files changed, 75 insertions(+), 13 deletions(-)
--
1.9.1
Jamal Hadi Salim (3):
net sched actions: Use proper root attribute table for actions
net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
net sched actions: add time filter for action dumping
include/uapi/linux/rtnetlink.h | 23 ++++++++++--
net/sched/act_api.c | 79 ++++++++++++++++++++++++++++++++++++------
2 files changed, 89 insertions(+), 13 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Erez Shitrit @ 2017-04-25 11:43 UTC (permalink / raw)
To: Or Gerlitz
Cc: Honggang LI, Erez Shitrit, Doug Ledford, Hefty, Sean,
Hal Rosenstock, Paolo Abeni,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel,
Linux Netdev List
In-Reply-To: <CAJ3xEMgw=9sj3rdahPEiST_yDfDJPNSZZLRn43tnb3bK4_RPzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 25, 2017 at 2:14 PM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Apr 25, 2017 at 2:11 PM, Erez Shitrit <erezsh-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>> On Tue, Apr 25, 2017 at 1:32 PM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Tue, Apr 25, 2017 at 12:55 PM, Honggang LI <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>> From: Honggang Li <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>
>>>> Minimal hard_header_len set by bond_compute_features is ETH_HLEN, which
>>>> is smaller than IPOIB_HARD_LEN. ipoib_hard_header should check the
>>>> size of headroom to avoid skb_under_panic.
>>>
>>> sounds terrible, ipoib bonding is supported since ~2007, thanks for
>>> reporting on that.
>>>
>>>> [ 122.871493] ipoib_hard_header: skb->head= ffff8808179d9400, skb->data= ffff8808179d9420, skb_headroom= 0x20
>>>> [ 123.055400] bond0: Releasing backup interface mthca_ib1
>>>> [ 123.560529] bond_compute_features:1112 bond0 bond_dev->hard_header_len = 14
>>>> [ 123.568822] CPU: 0 PID: 12336 Comm: ifdown-ib Not tainted 4.9.0-debug #1
>>>
>>> did you generate this trace by calling dump_stack or this is existing
>>> kernel code.
>>>
>>>> Fixes: fc791b633515 ('IB/ipoib: move back IB LL address into the hard header')
>>>
>>> this is more of WA to avoid some crash or failure but not fixing the
>>> actual problem
>>>
>>> Erez, can you comment?
>>
>> We saw that after commit fc791b633515, it happened while removing bond
>> interface after its slaves (ipoib interface) removed.
>> At that point the bond interface sets its dev_harheader_len to be as
>> eth interfaces (14 instead of 24), and if a process which doesn't
>> aware of the slaves removal or was at the middle of the sending tries
>> to send (igmp) packet it goes to ipoib with no space in the skb for
>> it, and here comes the panic.
>
> thanks for the info. Is this bug there since ipoib/bonding day one
> (and hence my bug...)
> or was indeed introduced later? if later, can you explain how
> fc791b633515 introduced
> that or you only know it by bisection?
commit "fc791b633515" changes the size of the dev_hardlen to be 24 and
required 24 extra bytes in the skb, before it was only 4, if skb is
aligned to eth "mode" it already has 14 bytes for hard-header.
So only after that commit we have the issue.
>
>> I agree with you that this fix is w/a, and it is a fix in the data
>> path for all the packets while the panic is in a control flow. It
>> probably should be fixed in the bonding driver.
>
> so what's your suggestion? fc791b633515 is 6m old, and it means the bug
> is in stable kernels and probably also in inbox drivers
>
> Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Andy Shevchenko @ 2017-04-25 11:42 UTC (permalink / raw)
To: Jan Kiszka
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev,
Linux Kernel Mailing List, Sascha Weisenberger
In-Reply-To: <3eae5626-1ef2-03ae-635e-27faed085c68@siemens.com>
On Tue, Apr 25, 2017 at 1:09 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-04-25 12:07, Jan Kiszka wrote:
>> On 2017-04-25 11:46, Andy Shevchenko wrote:
>>> On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> On 2017-04-25 09:30, Andy Shevchenko wrote:
>>>>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>> On 2017-04-24 23:27, Andy Shevchenko wrote:
>>>>>>> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> {
>>> .name = "SIMATIC IOT2000",
>>> .func = 6,
>>> .phy_addr = 1,
>>> },
>>> {
>>> .name = "SIMATIC IOT2000",
>>> .func = 7,
>>> .phy_addr = 1,
>>> },
>>>
>>> That's all what you need.
>>
>> Nope. Again: the asset tag is the way to tell both apart AND to ensure
>> that we do not match on future devices.
> To be more verbose: your version (which is our old one) would even
> enable the second, not connected port on the IOT2020. Incorrectly.
So, name has 2000 for 2020 device? It's clear bug in DMI table you have. :-(
What else do you have in DMI which can be used to distinguish those devices?
> Plus
> the risk to match different future devices.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Andy Shevchenko @ 2017-04-25 11:40 UTC (permalink / raw)
To: Jan Kiszka
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev,
Linux Kernel Mailing List, Sascha Weisenberger
In-Reply-To: <42fd4a72-526c-cbd9-52db-9d8b495035ee@siemens.com>
On Tue, Apr 25, 2017 at 1:07 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-04-25 11:46, Andy Shevchenko wrote:
>> On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-04-25 09:30, Andy Shevchenko wrote:
>>>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> On 2017-04-24 23:27, Andy Shevchenko wrote:
>>>>>> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>> + {
>>>>>>> + .name = "SIMATIC IOT2000",
>>>>>>> + .asset_tag = "6ES7647-0AA00-0YA2",
>>>>>>> + .func = 6,
>>>>>>> + .phy_addr = 1,
>>>>>>> + },
>>>>>>
>>>>>> The below has same definition disregard on asset_tag.
>>>>>>
>>>>>
>>>>> There is a small difference in the asset tag, just not at the last digit
>>>>> where one may expect it, look:
>>>>>
>>>>> ...-0YA2 -> IOT2020
>>>>> ...-1YA2 -> IOT2040
>>>>
>>>> Yes. And how does it change my statement? You may use one record here
>>>> instead of two.
>>>
>>> How? Please be more verbose in your comments.
>>
>> {
>> .name = "SIMATIC IOT2000",
>> .func = 6,
>> .phy_addr = 1,
>> },
>> {
>> .name = "SIMATIC IOT2000",
>> .func = 7,
>> .phy_addr = 1,
>> },
>>
>> That's all what you need.
>
> Nope. Again: the asset tag is the way to tell both apart AND to ensure
> that we do not match on future devices.
One step at a time. We don't care of future devices. When we will have
an issue we will look at it.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net-next] drivers: net: xgene-v2: Fix error return code in xge_mdio_config()
From: Wei Yongjun @ 2017-04-25 11:36 UTC (permalink / raw)
To: Iyappan Subramanian, Keyur Chudgar; +Cc: Wei Yongjun, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return error code -ENODEV from the no PHY found error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/apm/xgene-v2/mdio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/apm/xgene-v2/mdio.c b/drivers/net/ethernet/apm/xgene-v2/mdio.c
index a583c6a..f5fe3bb 100644
--- a/drivers/net/ethernet/apm/xgene-v2/mdio.c
+++ b/drivers/net/ethernet/apm/xgene-v2/mdio.c
@@ -135,6 +135,7 @@ int xge_mdio_config(struct net_device *ndev)
phydev = phy_find_first(mdio_bus);
if (!phydev) {
dev_err(dev, "no PHY found\n");
+ ret = -ENODEV;
goto err;
}
phydev = phy_connect(ndev, phydev_name(phydev),
^ permalink raw reply related
* Re: [PATCH net-next] rhashtable: remove insecure_max_entries param
From: Florian Westphal @ 2017-04-25 11:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: Florian Westphal, netdev
In-Reply-To: <20170425110415.GA25167@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Florian Westphal <fw@strlen.de> wrote:
> > no users in the tree, insecure_max_entries is always set to
> > ht->p.max_size * 2 in rhtashtable_init().
> >
> > Replace only spot that uses it with a ht->p.max_size check.
>
> I'd suggest that as this needs to be computed every time we insert
> an element that you keep the value in struct rhashtable, but as an
> internal value as opposed to a paramter that is set by the user.
What extra cost?
The only change is that ht->nelems has to be right-shifted by one,
I don't think that warrants extra space in struct rhashtable, its
already way too large (I think we can reduce its size further).
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Or Gerlitz @ 2017-04-25 11:14 UTC (permalink / raw)
To: Erez Shitrit
Cc: Honggang LI, Erez Shitrit, Doug Ledford, Hefty, Sean,
Hal Rosenstock, Paolo Abeni,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel,
Linux Netdev List
In-Reply-To: <CAAk-MO8O19iC2Yn-BMn5pKTAYxaSzGPMyta=fwes3XSvzmz_cQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 25, 2017 at 2:11 PM, Erez Shitrit <erezsh-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
> On Tue, Apr 25, 2017 at 1:32 PM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Tue, Apr 25, 2017 at 12:55 PM, Honggang LI <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> From: Honggang Li <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>
>>> Minimal hard_header_len set by bond_compute_features is ETH_HLEN, which
>>> is smaller than IPOIB_HARD_LEN. ipoib_hard_header should check the
>>> size of headroom to avoid skb_under_panic.
>>
>> sounds terrible, ipoib bonding is supported since ~2007, thanks for
>> reporting on that.
>>
>>> [ 122.871493] ipoib_hard_header: skb->head= ffff8808179d9400, skb->data= ffff8808179d9420, skb_headroom= 0x20
>>> [ 123.055400] bond0: Releasing backup interface mthca_ib1
>>> [ 123.560529] bond_compute_features:1112 bond0 bond_dev->hard_header_len = 14
>>> [ 123.568822] CPU: 0 PID: 12336 Comm: ifdown-ib Not tainted 4.9.0-debug #1
>>
>> did you generate this trace by calling dump_stack or this is existing
>> kernel code.
>>
>>> Fixes: fc791b633515 ('IB/ipoib: move back IB LL address into the hard header')
>>
>> this is more of WA to avoid some crash or failure but not fixing the
>> actual problem
>>
>> Erez, can you comment?
>
> We saw that after commit fc791b633515, it happened while removing bond
> interface after its slaves (ipoib interface) removed.
> At that point the bond interface sets its dev_harheader_len to be as
> eth interfaces (14 instead of 24), and if a process which doesn't
> aware of the slaves removal or was at the middle of the sending tries
> to send (igmp) packet it goes to ipoib with no space in the skb for
> it, and here comes the panic.
thanks for the info. Is this bug there since ipoib/bonding day one
(and hence my bug...)
or was indeed introduced later? if later, can you explain how
fc791b633515 introduced
that or you only know it by bisection?
> I agree with you that this fix is w/a, and it is a fix in the data
> path for all the packets while the panic is in a control flow. It
> probably should be fixed in the bonding driver.
so what's your suggestion? fc791b633515 is 6m old, and it means the bug
is in stable kernels and probably also in inbox drivers
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Erez Shitrit @ 2017-04-25 11:11 UTC (permalink / raw)
To: Or Gerlitz
Cc: Honggang LI, Erez Shitrit, Doug Ledford, Hefty, Sean,
Hal Rosenstock, Paolo Abeni,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel,
Linux Netdev List
In-Reply-To: <CAJ3xEMg4_2ph7QwPsUb-tX-K4d2ppkqz98sPzytsmBCK=29WHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 25, 2017 at 1:32 PM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Apr 25, 2017 at 12:55 PM, Honggang LI <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> From: Honggang Li <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>
>> Minimal hard_header_len set by bond_compute_features is ETH_HLEN, which
>> is smaller than IPOIB_HARD_LEN. ipoib_hard_header should check the
>> size of headroom to avoid skb_under_panic.
>
> sounds terrible, ipoib bonding is supported since ~2007, thanks for
> reporting on that.
>
>> [ 122.871493] ipoib_hard_header: skb->head= ffff8808179d9400, skb->data= ffff8808179d9420, skb_headroom= 0x20
>> [ 123.055400] bond0: Releasing backup interface mthca_ib1
>> [ 123.560529] bond_compute_features:1112 bond0 bond_dev->hard_header_len = 14
>> [ 123.568822] CPU: 0 PID: 12336 Comm: ifdown-ib Not tainted 4.9.0-debug #1
>
> did you generate this trace by calling dump_stack or this is existing
> kernel code.
>
>> Fixes: fc791b633515 ('IB/ipoib: move back IB LL address into the hard header')
>
> this is more of WA to avoid some crash or failure but not fixing the
> actual problem
>
> Erez, can you comment?
We saw that after commit fc791b633515, it happened while removing bond
interface after its slaves (ipoib interface) removed.
At that point the bond interface sets its dev_harheader_len to be as
eth interfaces (14 instead of 24), and if a process which doesn't
aware of the slaves removal or was at the middle of the sending tries
to send (igmp) packet it goes to ipoib with no space in the skb for
it, and here comes the panic.
I agree with you that this fix is w/a, and it is a fix in the data
path for all the packets while the panic is in a control flow. It
probably should be fixed in the bonding driver.
>
> Or.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] rhashtable: remove insecure_max_entries param
From: Herbert Xu @ 2017-04-25 11:04 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev, fw
In-Reply-To: <20170425094134.21885-1-fw@strlen.de>
Florian Westphal <fw@strlen.de> wrote:
> no users in the tree, insecure_max_entries is always set to
> ht->p.max_size * 2 in rhtashtable_init().
>
> Replace only spot that uses it with a ht->p.max_size check.
I'd suggest that as this needs to be computed every time we insert
an element that you keep the value in struct rhashtable, but as an
internal value as opposed to a paramter that is set by the user.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Honggang LI @ 2017-04-25 10:57 UTC (permalink / raw)
To: Or Gerlitz
Cc: Erez Shitrit, Doug Ledford, Hefty, Sean, Hal Rosenstock,
Paolo Abeni, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel, Linux Netdev List
In-Reply-To: <CAJ3xEMg4_2ph7QwPsUb-tX-K4d2ppkqz98sPzytsmBCK=29WHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 25, 2017 at 01:32:59PM +0300, Or Gerlitz wrote:
> On Tue, Apr 25, 2017 at 12:55 PM, Honggang LI <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > From: Honggang Li <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >
> > Minimal hard_header_len set by bond_compute_features is ETH_HLEN, which
> > is smaller than IPOIB_HARD_LEN. ipoib_hard_header should check the
> > size of headroom to avoid skb_under_panic.
>
> sounds terrible, ipoib bonding is supported since ~2007, thanks for
> reporting on that.
>
> > [ 122.871493] ipoib_hard_header: skb->head= ffff8808179d9400, skb->data= ffff8808179d9420, skb_headroom= 0x20
> > [ 123.055400] bond0: Releasing backup interface mthca_ib1
> > [ 123.560529] bond_compute_features:1112 bond0 bond_dev->hard_header_len = 14
> > [ 123.568822] CPU: 0 PID: 12336 Comm: ifdown-ib Not tainted 4.9.0-debug #1
>
> did you generate this trace by calling dump_stack or this is existing
> kernel code.
I inserted dump_stack to print this stack for debug.
>
> > Fixes: fc791b633515 ('IB/ipoib: move back IB LL address into the hard header')
>
> this is more of WA to avoid some crash or failure but not fixing the
> actual problem
>
> Erez, can you comment?
>
> Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 2/2] l2tp: define "l2tpeth" device type
From: James Chapman @ 2017-04-25 10:41 UTC (permalink / raw)
To: netdev; +Cc: Guillaume Nault
In-Reply-To: <f9c1eb350915a145978d7f5d485ad210c11ba5ca.1493035407.git.g.nault@alphalink.fr>
On 24/04/17 13:16, Guillaume Nault wrote:
> Export type of l2tpeth interfaces to userspace
> (/sys/class/net/<iface>/uevent).
>
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Acked-by: James Chapman <jchapman@katalix.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] l2tp: set name_assign_type for devices created by l2tp_eth.c
From: James Chapman @ 2017-04-25 10:40 UTC (permalink / raw)
To: netdev; +Cc: Guillaume Nault
In-Reply-To: <062e3c5c1c8b9d6ddea34de74e98c159f78a2f0b.1493035407.git.g.nault@alphalink.fr>
On 24/04/17 13:16, Guillaume Nault wrote:
> Export naming scheme used when creating l2tpeth interfaces
> (/sys/class/net/<iface>/name_assign_type). This let userspace know if
> the device's name has been generated automatically or defined manually.
>
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Acked-by: James Chapman <jchapman@katalix.com>
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Or Gerlitz @ 2017-04-25 10:32 UTC (permalink / raw)
To: Honggang LI, Erez Shitrit
Cc: Doug Ledford, Hefty, Sean, Hal Rosenstock, Paolo Abeni,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel,
Linux Netdev List
In-Reply-To: <1493114155-12101-1-git-send-email-honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Apr 25, 2017 at 12:55 PM, Honggang LI <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> From: Honggang Li <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Minimal hard_header_len set by bond_compute_features is ETH_HLEN, which
> is smaller than IPOIB_HARD_LEN. ipoib_hard_header should check the
> size of headroom to avoid skb_under_panic.
sounds terrible, ipoib bonding is supported since ~2007, thanks for
reporting on that.
> [ 122.871493] ipoib_hard_header: skb->head= ffff8808179d9400, skb->data= ffff8808179d9420, skb_headroom= 0x20
> [ 123.055400] bond0: Releasing backup interface mthca_ib1
> [ 123.560529] bond_compute_features:1112 bond0 bond_dev->hard_header_len = 14
> [ 123.568822] CPU: 0 PID: 12336 Comm: ifdown-ib Not tainted 4.9.0-debug #1
did you generate this trace by calling dump_stack or this is existing
kernel code.
> Fixes: fc791b633515 ('IB/ipoib: move back IB LL address into the hard header')
this is more of WA to avoid some crash or failure but not fixing the
actual problem
Erez, can you comment?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Yuval Shaia @ 2017-04-25 10:11 UTC (permalink / raw)
To: Honggang LI
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
pabeni-H+wXaHxf7aLQT0dZR+AlfA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493114155-12101-1-git-send-email-honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Apr 25, 2017 at 05:55:55PM +0800, Honggang LI wrote:
> From: Honggang Li <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Minimal hard_header_len set by bond_compute_features is ETH_HLEN, which
> is smaller than IPOIB_HARD_LEN. ipoib_hard_header should check the
> size of headroom to avoid skb_under_panic.
>
> [ 122.871493] ipoib_hard_header: skb->head= ffff8808179d9400, skb->data= ffff8808179d9420, skb_headroom= 0x20
> [ 123.055400] bond0: Releasing backup interface mthca_ib1
> [ 123.560529] bond_compute_features:1112 bond0 bond_dev->hard_header_len = 14
> [ 123.568822] CPU: 0 PID: 12336 Comm: ifdown-ib Not tainted 4.9.0-debug #1
> [ 123.576668] Hardware name: Dell Inc. PowerEdge R415/0GXH08, BIOS 2.0.2 10/22/2012
> [ 123.585284] ffffc90009027be8 ffffffff81362d6c ffff8808198b7000 0000000000010000
> [ 123.593845] ffffc90009027c50 ffffffffa06cf833 ffff8808198b7000 ffff8808198b78c0
> [ 123.602392] ffffc90009027c30 ffffffff815ed725 ffff8808158a9c00 00000000a67486bf
> [ 123.610926] Call Trace:
> [ 123.614454] [<ffffffff81362d6c>] dump_stack+0x63/0x87
> [ 123.620661] [<ffffffffa06cf833>] bond_compute_features.isra.42+0x243/0x260 [bonding]
> [ 123.629546] [<ffffffff815ed725>] ? call_netdevice_notifiers_info+0x35/0x60
> [ 123.637557] [<ffffffffa06d3a7b>] __bond_release_one+0x2db/0x530 [bonding]
> [ 123.645483] [<ffffffffa06d3ce0>] bond_release+0x10/0x20 [bonding]
> [ 123.652711] [<ffffffffa06de038>] bond_option_slaves_set+0xe8/0x130 [bonding]
> [ 123.660874] [<ffffffffa06df336>] __bond_opt_set+0xd6/0x320 [bonding]
> [ 123.668357] [<ffffffffa06df5d6>] bond_opt_tryset_rtnl+0x56/0xa0 [bonding]
> [ 123.676284] [<ffffffffa06dbba5>] bonding_sysfs_store_option+0x35/0x60 [bonding]
> [ 123.684748] [<ffffffff814b0bd8>] dev_attr_store+0x18/0x30
> [ 123.691311] [<ffffffff812b6c5a>] sysfs_kf_write+0x3a/0x50
> [ 123.697879] [<ffffffff812b678b>] kernfs_fop_write+0x10b/0x190
> [ 123.704801] [<ffffffff81231647>] __vfs_write+0x37/0x160
> [ 123.711213] [<ffffffff812f0235>] ? selinux_file_permission+0xe5/0x120
> [ 123.718856] [<ffffffff812e5a8b>] ? security_file_permission+0x3b/0xc0
> [ 123.726506] [<ffffffff81231d72>] vfs_write+0xb2/0x1b0
> [ 123.732776] [<ffffffff81003510>] ? syscall_trace_enter+0x1d0/0x2b0
> [ 123.740148] [<ffffffff812331c5>] SyS_write+0x55/0xc0
> [ 123.746288] [<ffffffff81003a47>] do_syscall_64+0x67/0x180
> [ 123.752846] [<ffffffff8170f7ab>] entry_SYSCALL64_slow_path+0x25/0x25
> [ 123.760421] bond0: last VLAN challenged slave mthca_ib1 left bond bond0 - VLAN blocking is removed
> [ 124.023489] dump_LL_RESERVED_SPACE, bond0, dev->hard_header_len = 0xe, dev->needed_headroom= 0x0, HH_DATA_MOD= 0x10
> [ 124.023490] dump_LL_RESERVED_SPACE, bond0, LL_RESERVED_SPACE(dev) = 0x10
> [ 124.023491] dump_LL_RESERVED_SPACE, bond0, dev->hard_header_len = 0xe, dev->needed_headroom= 0x0, HH_DATA_MOD= 0x10
> [ 124.023492] dump_LL_RESERVED_SPACE, bond0, LL_RESERVED_SPACE(dev) = 0x10
> [ 124.023494] arp_create:547 skb->head= ffff8808179dac00, skb->data= ffff8808179dac00, skb_headroom= 0x0, <NULL>
> [ 124.023495] arp_create:549 skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10, <NULL>
> [ 124.023496] arp_create:551 skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10, <NULL>
> [ 124.023497] arp_create:553 skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10, <NULL>
> [ 124.023498] arp_create:564 skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10, bond0
> [ 124.023500] ipoib_hard_header: skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10
> [ 124.023502] skbuff: skb_under_panic: text:ffffffffa040f6a9 len:80 put:20 head:ffff8808179dac00 data:ffff8808179dabf8 tail:0x48 end:0xc0 dev:bond0
> [ 124.023536] ------------[ cut here ]------------
> [ 124.023537] kernel BUG at net/core/skbuff.c:105!
> [ 124.023539] invalid opcode: 0000 [#1] SMP
> [ 124.023563] Modules linked in: bonding amd64_edac_mod edac_mce_amd edac_core kvm_amd kvm ib_mthca ipmi_ssif ipmi_devintf irqbypass ipmi_si dcdbas acpi_power_meter sp5100_tco ipmi_msghandler sg pcspkr i2c_piix4 k10temp shpchp acpi_cpufreq rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib nfsd rdma_ucm auth_rpcgss ib_ucm nfs_acl ib_uverbs lockd grace ib_umad rdma_cm sunrpc ib_cm iw_cm ib_core ip_tables xfs libcrc32c sd_mod ata_generic pata_acpi mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ahci drm libahci pata_atiixp serio_raw libata i2c_core bnx2 fjes dm_mirror dm_region_hash dm_log dm_mod
> [ 124.023567] CPU: 2 PID: 12265 Comm: ping Not tainted 4.9.0-debug #1
> [ 124.023567] Hardware name: Dell Inc. PowerEdge R415/0GXH08, BIOS 2.0.2 10/22/2012
> [ 124.023569] task: ffff880818214080 task.stack: ffffc900085e0000
> [ 124.023577] RIP: 0010:[<ffffffff817005c4>] [<ffffffff817005c4>] skb_panic+0x66/0x68
> [ 124.023578] RSP: 0018:ffffc900085e38e0 EFLAGS: 00010246
> [ 124.023578] RAX: 0000000000000085 RBX: ffff880816a72500 RCX: 0000000000000000
> [ 124.023579] RDX: 0000000000000000 RSI: 0000000000000296 RDI: 0000000000000296
> [ 124.023580] RBP: ffffc900085e3900 R08: 0000000000000085 R09: ffffffff82012ce5
> [ 124.023581] R10: 00000000000003ed R11: 0000000000000000 R12: ffff8808198b7368
> [ 124.023581] R13: 0000000000000608 R14: 000000000701de0a R15: ffff8808198b7000
> [ 124.023583] FS: 00002b3922409b00(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
> [ 124.023584] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 124.023584] CR2: 00002ac965af0072 CR3: 0000000814472000 CR4: 00000000000006e0
> [ 124.023585] Stack:
> [ 124.023588] ffff8808179dabf8 0000000000000048 00000000000000c0 ffff8808198b7000
> [ 124.023590] ffffc900085e3910 ffffffff815dcb5d ffffc900085e3938 ffffffffa040f6a9
> [ 124.023592] ffff8808179dac10 ffff8808198b7368 000000000601de0a ffffc900085e3990
> [ 124.023592] Call Trace:
> [ 124.023598] [<ffffffff815dcb5d>] skb_push+0x3d/0x40
> [ 124.023607] [<ffffffffa040f6a9>] ipoib_hard_header+0x69/0x90 [ib_ipoib]
> [ 124.023611] [<ffffffff8166c7ee>] arp_create+0x2ae/0x3e0
> [ 124.023613] [<ffffffff8166cd28>] arp_send_dst.part.19+0x28/0x50
> [ 124.023615] [<ffffffff8166ce65>] arp_solicit+0x115/0x290
> [ 124.023618] [<ffffffff815e050c>] ? skb_clone+0x4c/0xa0
> [ 124.023619] [<ffffffff815dd92e>] ? __skb_clone+0x2e/0x140
> [ 124.023622] [<ffffffff815ff235>] neigh_probe+0x45/0x60
> [ 124.023624] [<ffffffff81600117>] __neigh_event_send+0xa7/0x230
> [ 124.023625] [<ffffffff8160081e>] neigh_resolve_output+0x12e/0x1c0
> [ 124.023628] [<ffffffff8163bc2b>] ip_finish_output2+0x14b/0x370
> [ 124.023630] [<ffffffff8163d2e6>] ip_finish_output+0x136/0x1e0
> [ 124.023632] [<ffffffff8163dd7e>] ip_output+0x6e/0xf0
> [ 124.023633] [<ffffffff8163d402>] ? __ip_local_out+0x72/0x120
> [ 124.023635] [<ffffffff8163d1b0>] ? ip_fragment.constprop.49+0x80/0x80
> [ 124.023636] [<ffffffff8163d4e5>] ip_local_out+0x35/0x40
> [ 124.023638] [<ffffffff8163e819>] ip_send_skb+0x19/0x40
> [ 124.023640] [<ffffffff8163e873>] ip_push_pending_frames+0x33/0x40
> [ 124.023641] [<ffffffff81665dfa>] raw_sendmsg+0x77a/0xb00
> [ 124.023644] [<ffffffff815e6131>] ? skb_recv_datagram+0x41/0x60
> [ 124.023645] [<ffffffff81665044>] ? raw_recvmsg+0x94/0x1d0
> [ 124.023650] [<ffffffff812e9280>] ? sock_has_perm+0x70/0x90
> [ 124.023653] [<ffffffff815d6502>] ? ___sys_recvmsg+0xf2/0x1f0
> [ 124.023655] [<ffffffff816753b7>] inet_sendmsg+0x67/0xa0
> [ 124.023657] [<ffffffff815d5aa8>] sock_sendmsg+0x38/0x50
> [ 124.023659] [<ffffffff815d5f62>] SYSC_sendto+0x102/0x190
> [ 124.023662] [<ffffffff8113ed6f>] ? __audit_syscall_entry+0xaf/0x100
> [ 124.023665] [<ffffffff81003510>] ? syscall_trace_enter+0x1d0/0x2b0
> [ 124.023667] [<ffffffff8113ef9b>] ? __audit_syscall_exit+0x1db/0x260
> [ 124.023669] [<ffffffff815d6b0e>] SyS_sendto+0xe/0x10
> [ 124.023670] [<ffffffff81003a47>] do_syscall_64+0x67/0x180
> [ 124.023673] [<ffffffff8170f7ab>] entry_SYSCALL64_slow_path+0x25/0x25
> [ 124.023688] Code: 00 00 48 89 44 24 10 8b 87 c8 00 00 00 48 89 44 24 08 48 8b 87 d8 00 00 00 48 c7 c7 50 83 ab 81 48 89 04 24 31 c0 e8 5f e6 a9 ff <0f> 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 0f 1f 44 00 00 55 48
> [ 124.023690] RIP [<ffffffff817005c4>] skb_panic+0x66/0x68
> [ 124.023691] RSP <ffffc900085e38e0>
> [ 124.023696] ---[ end trace 95c238901cb322be ]---
> [ 124.026071] Kernel panic - not syncing: Fatal exception in interrupt
> [ 124.026368] Kernel Offset: disabled
> [ 124.644414] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
>
> Fixes: fc791b633515 ('IB/ipoib: move back IB LL address into the hard header')
> Reported-by: Norbert P <noe-PRwTpj6vllL463JZfw7VRw@public.gmane.org>
> Signed-off-by: Honggang Li <honli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> index d1d3fb7..3668e1e 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> @@ -1161,6 +1161,9 @@ static int ipoib_hard_header(struct sk_buff *skb,
> {
> struct ipoib_header *header;
>
> + if (unlikely(skb_headroom(skb) < IPOIB_HARD_LEN))
> + return -EINVAL;
> +
> header = (struct ipoib_header *) skb_push(skb, sizeof *header);
>
> header->proto = htons(type);
> --
> 1.8.3.1
Reviewed-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Jan Kiszka @ 2017-04-25 10:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev,
Linux Kernel Mailing List, Sascha Weisenberger
In-Reply-To: <42fd4a72-526c-cbd9-52db-9d8b495035ee@siemens.com>
On 2017-04-25 12:07, Jan Kiszka wrote:
> On 2017-04-25 11:46, Andy Shevchenko wrote:
>> On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-04-25 09:30, Andy Shevchenko wrote:
>>>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> On 2017-04-24 23:27, Andy Shevchenko wrote:
>>>>>> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>> The IOT2000 is industrial controller platform, derived from the Intel
>>>>>>> Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the
>>>>>>> IOT2040 has two of them. They can be told apart based on the board asset
>>>>>>> tag in the DMI table.
>>>>
>>>>>>> + const char *asset_tag;
>>>>>>
>>>>>> I guess this is redundant. See below.
>>>>>>
>>>>>>> + {
>>>>>>> + .name = "SIMATIC IOT2000",
>>>>>>> + .asset_tag = "6ES7647-0AA00-0YA2",
>>>>>>> + .func = 6,
>>>>>>> + .phy_addr = 1,
>>>>>>> + },
>>>>>>
>>>>>> The below has same definition disregard on asset_tag.
>>>>>>
>>>>>
>>>>> There is a small difference in the asset tag, just not at the last digit
>>>>> where one may expect it, look:
>>>>>
>>>>> ...-0YA2 -> IOT2020
>>>>> ...-1YA2 -> IOT2040
>>>>
>>>> Yes. And how does it change my statement? You may use one record here
>>>> instead of two.
>>>
>>> How? Please be more verbose in your comments.
>>
>> {
>> .name = "SIMATIC IOT2000",
>> .func = 6,
>> .phy_addr = 1,
>> },
>> {
>> .name = "SIMATIC IOT2000",
>> .func = 7,
>> .phy_addr = 1,
>> },
>>
>> That's all what you need.
>
> Nope. Again: the asset tag is the way to tell both apart AND to ensure
> that we do not match on future devices.
To be more verbose: your version (which is our old one) would even
enable the second, not connected port on the IOT2020. Incorrectly. Plus
the risk to match different future devices.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Jan Kiszka @ 2017-04-25 10:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev,
Linux Kernel Mailing List, Sascha Weisenberger
In-Reply-To: <CAHp75VfqC166E57nZRsx97EQCCGnqYTk+4nRX3H2-rsnCohPfQ@mail.gmail.com>
On 2017-04-25 11:46, Andy Shevchenko wrote:
> On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2017-04-25 09:30, Andy Shevchenko wrote:
>>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> On 2017-04-24 23:27, Andy Shevchenko wrote:
>>>>> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>> The IOT2000 is industrial controller platform, derived from the Intel
>>>>>> Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the
>>>>>> IOT2040 has two of them. They can be told apart based on the board asset
>>>>>> tag in the DMI table.
>>>
>>>>>> + const char *asset_tag;
>>>>>
>>>>> I guess this is redundant. See below.
>>>>>
>>>>>> + {
>>>>>> + .name = "SIMATIC IOT2000",
>>>>>> + .asset_tag = "6ES7647-0AA00-0YA2",
>>>>>> + .func = 6,
>>>>>> + .phy_addr = 1,
>>>>>> + },
>>>>>
>>>>> The below has same definition disregard on asset_tag.
>>>>>
>>>>
>>>> There is a small difference in the asset tag, just not at the last digit
>>>> where one may expect it, look:
>>>>
>>>> ...-0YA2 -> IOT2020
>>>> ...-1YA2 -> IOT2040
>>>
>>> Yes. And how does it change my statement? You may use one record here
>>> instead of two.
>>
>> How? Please be more verbose in your comments.
>
> {
> .name = "SIMATIC IOT2000",
> .func = 6,
> .phy_addr = 1,
> },
> {
> .name = "SIMATIC IOT2000",
> .func = 7,
> .phy_addr = 1,
> },
>
> That's all what you need.
Nope. Again: the asset tag is the way to tell both apart AND to ensure
that we do not match on future devices.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH] net: hso: fix module unloading
From: Johan Hovold @ 2017-04-25 10:04 UTC (permalink / raw)
To: Andreas Kemnade
Cc: davem, joe, peter, linux-usb, netdev, linux-kernel,
Discussions about the Letux Kernel
In-Reply-To: <1493061519-15785-1-git-send-email-andreas@kemnade.info>
On Mon, Apr 24, 2017 at 09:18:39PM +0200, Andreas Kemnade wrote:
> keep tty driver until usb driver is unregistered
> rmmod hso
> produces traces like this without that:
Yeah, a blatant use-after-free.
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Reviewed-by: Johan Hovold <johan@kernel.org>
> ---
> drivers/net/usb/hso.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index 2e66340..b75e23f 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -3293,9 +3293,9 @@ static void __exit hso_exit(void)
> pr_info("unloaded\n");
>
> tty_unregister_driver(tty_drv);
> - put_tty_driver(tty_drv);
> /* deregister the usb driver */
> usb_deregister(&hso_driver);
> + put_tty_driver(tty_drv);
> }
>
> /* Module definitions */
Thanks,
Johan
^ permalink raw reply
* [PATCH] IB/IPoIB: Check the headroom size
From: Honggang LI @ 2017-04-25 9:55 UTC (permalink / raw)
To: dledford, sean.hefty, hal.rosenstock, pabeni, linux-rdma
Cc: linux-kernel, netdev, Honggang Li
From: Honggang Li <honli@redhat.com>
Minimal hard_header_len set by bond_compute_features is ETH_HLEN, which
is smaller than IPOIB_HARD_LEN. ipoib_hard_header should check the
size of headroom to avoid skb_under_panic.
[ 122.871493] ipoib_hard_header: skb->head= ffff8808179d9400, skb->data= ffff8808179d9420, skb_headroom= 0x20
[ 123.055400] bond0: Releasing backup interface mthca_ib1
[ 123.560529] bond_compute_features:1112 bond0 bond_dev->hard_header_len = 14
[ 123.568822] CPU: 0 PID: 12336 Comm: ifdown-ib Not tainted 4.9.0-debug #1
[ 123.576668] Hardware name: Dell Inc. PowerEdge R415/0GXH08, BIOS 2.0.2 10/22/2012
[ 123.585284] ffffc90009027be8 ffffffff81362d6c ffff8808198b7000 0000000000010000
[ 123.593845] ffffc90009027c50 ffffffffa06cf833 ffff8808198b7000 ffff8808198b78c0
[ 123.602392] ffffc90009027c30 ffffffff815ed725 ffff8808158a9c00 00000000a67486bf
[ 123.610926] Call Trace:
[ 123.614454] [<ffffffff81362d6c>] dump_stack+0x63/0x87
[ 123.620661] [<ffffffffa06cf833>] bond_compute_features.isra.42+0x243/0x260 [bonding]
[ 123.629546] [<ffffffff815ed725>] ? call_netdevice_notifiers_info+0x35/0x60
[ 123.637557] [<ffffffffa06d3a7b>] __bond_release_one+0x2db/0x530 [bonding]
[ 123.645483] [<ffffffffa06d3ce0>] bond_release+0x10/0x20 [bonding]
[ 123.652711] [<ffffffffa06de038>] bond_option_slaves_set+0xe8/0x130 [bonding]
[ 123.660874] [<ffffffffa06df336>] __bond_opt_set+0xd6/0x320 [bonding]
[ 123.668357] [<ffffffffa06df5d6>] bond_opt_tryset_rtnl+0x56/0xa0 [bonding]
[ 123.676284] [<ffffffffa06dbba5>] bonding_sysfs_store_option+0x35/0x60 [bonding]
[ 123.684748] [<ffffffff814b0bd8>] dev_attr_store+0x18/0x30
[ 123.691311] [<ffffffff812b6c5a>] sysfs_kf_write+0x3a/0x50
[ 123.697879] [<ffffffff812b678b>] kernfs_fop_write+0x10b/0x190
[ 123.704801] [<ffffffff81231647>] __vfs_write+0x37/0x160
[ 123.711213] [<ffffffff812f0235>] ? selinux_file_permission+0xe5/0x120
[ 123.718856] [<ffffffff812e5a8b>] ? security_file_permission+0x3b/0xc0
[ 123.726506] [<ffffffff81231d72>] vfs_write+0xb2/0x1b0
[ 123.732776] [<ffffffff81003510>] ? syscall_trace_enter+0x1d0/0x2b0
[ 123.740148] [<ffffffff812331c5>] SyS_write+0x55/0xc0
[ 123.746288] [<ffffffff81003a47>] do_syscall_64+0x67/0x180
[ 123.752846] [<ffffffff8170f7ab>] entry_SYSCALL64_slow_path+0x25/0x25
[ 123.760421] bond0: last VLAN challenged slave mthca_ib1 left bond bond0 - VLAN blocking is removed
[ 124.023489] dump_LL_RESERVED_SPACE, bond0, dev->hard_header_len = 0xe, dev->needed_headroom= 0x0, HH_DATA_MOD= 0x10
[ 124.023490] dump_LL_RESERVED_SPACE, bond0, LL_RESERVED_SPACE(dev) = 0x10
[ 124.023491] dump_LL_RESERVED_SPACE, bond0, dev->hard_header_len = 0xe, dev->needed_headroom= 0x0, HH_DATA_MOD= 0x10
[ 124.023492] dump_LL_RESERVED_SPACE, bond0, LL_RESERVED_SPACE(dev) = 0x10
[ 124.023494] arp_create:547 skb->head= ffff8808179dac00, skb->data= ffff8808179dac00, skb_headroom= 0x0, <NULL>
[ 124.023495] arp_create:549 skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10, <NULL>
[ 124.023496] arp_create:551 skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10, <NULL>
[ 124.023497] arp_create:553 skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10, <NULL>
[ 124.023498] arp_create:564 skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10, bond0
[ 124.023500] ipoib_hard_header: skb->head= ffff8808179dac00, skb->data= ffff8808179dac10, skb_headroom= 0x10
[ 124.023502] skbuff: skb_under_panic: text:ffffffffa040f6a9 len:80 put:20 head:ffff8808179dac00 data:ffff8808179dabf8 tail:0x48 end:0xc0 dev:bond0
[ 124.023536] ------------[ cut here ]------------
[ 124.023537] kernel BUG at net/core/skbuff.c:105!
[ 124.023539] invalid opcode: 0000 [#1] SMP
[ 124.023563] Modules linked in: bonding amd64_edac_mod edac_mce_amd edac_core kvm_amd kvm ib_mthca ipmi_ssif ipmi_devintf irqbypass ipmi_si dcdbas acpi_power_meter sp5100_tco ipmi_msghandler sg pcspkr i2c_piix4 k10temp shpchp acpi_cpufreq rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib nfsd rdma_ucm auth_rpcgss ib_ucm nfs_acl ib_uverbs lockd grace ib_umad rdma_cm sunrpc ib_cm iw_cm ib_core ip_tables xfs libcrc32c sd_mod ata_generic pata_acpi mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ahci drm libahci pata_atiixp serio_raw libata i2c_core bnx2 fjes dm_mirror dm_region_hash dm_log dm_mod
[ 124.023567] CPU: 2 PID: 12265 Comm: ping Not tainted 4.9.0-debug #1
[ 124.023567] Hardware name: Dell Inc. PowerEdge R415/0GXH08, BIOS 2.0.2 10/22/2012
[ 124.023569] task: ffff880818214080 task.stack: ffffc900085e0000
[ 124.023577] RIP: 0010:[<ffffffff817005c4>] [<ffffffff817005c4>] skb_panic+0x66/0x68
[ 124.023578] RSP: 0018:ffffc900085e38e0 EFLAGS: 00010246
[ 124.023578] RAX: 0000000000000085 RBX: ffff880816a72500 RCX: 0000000000000000
[ 124.023579] RDX: 0000000000000000 RSI: 0000000000000296 RDI: 0000000000000296
[ 124.023580] RBP: ffffc900085e3900 R08: 0000000000000085 R09: ffffffff82012ce5
[ 124.023581] R10: 00000000000003ed R11: 0000000000000000 R12: ffff8808198b7368
[ 124.023581] R13: 0000000000000608 R14: 000000000701de0a R15: ffff8808198b7000
[ 124.023583] FS: 00002b3922409b00(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
[ 124.023584] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 124.023584] CR2: 00002ac965af0072 CR3: 0000000814472000 CR4: 00000000000006e0
[ 124.023585] Stack:
[ 124.023588] ffff8808179dabf8 0000000000000048 00000000000000c0 ffff8808198b7000
[ 124.023590] ffffc900085e3910 ffffffff815dcb5d ffffc900085e3938 ffffffffa040f6a9
[ 124.023592] ffff8808179dac10 ffff8808198b7368 000000000601de0a ffffc900085e3990
[ 124.023592] Call Trace:
[ 124.023598] [<ffffffff815dcb5d>] skb_push+0x3d/0x40
[ 124.023607] [<ffffffffa040f6a9>] ipoib_hard_header+0x69/0x90 [ib_ipoib]
[ 124.023611] [<ffffffff8166c7ee>] arp_create+0x2ae/0x3e0
[ 124.023613] [<ffffffff8166cd28>] arp_send_dst.part.19+0x28/0x50
[ 124.023615] [<ffffffff8166ce65>] arp_solicit+0x115/0x290
[ 124.023618] [<ffffffff815e050c>] ? skb_clone+0x4c/0xa0
[ 124.023619] [<ffffffff815dd92e>] ? __skb_clone+0x2e/0x140
[ 124.023622] [<ffffffff815ff235>] neigh_probe+0x45/0x60
[ 124.023624] [<ffffffff81600117>] __neigh_event_send+0xa7/0x230
[ 124.023625] [<ffffffff8160081e>] neigh_resolve_output+0x12e/0x1c0
[ 124.023628] [<ffffffff8163bc2b>] ip_finish_output2+0x14b/0x370
[ 124.023630] [<ffffffff8163d2e6>] ip_finish_output+0x136/0x1e0
[ 124.023632] [<ffffffff8163dd7e>] ip_output+0x6e/0xf0
[ 124.023633] [<ffffffff8163d402>] ? __ip_local_out+0x72/0x120
[ 124.023635] [<ffffffff8163d1b0>] ? ip_fragment.constprop.49+0x80/0x80
[ 124.023636] [<ffffffff8163d4e5>] ip_local_out+0x35/0x40
[ 124.023638] [<ffffffff8163e819>] ip_send_skb+0x19/0x40
[ 124.023640] [<ffffffff8163e873>] ip_push_pending_frames+0x33/0x40
[ 124.023641] [<ffffffff81665dfa>] raw_sendmsg+0x77a/0xb00
[ 124.023644] [<ffffffff815e6131>] ? skb_recv_datagram+0x41/0x60
[ 124.023645] [<ffffffff81665044>] ? raw_recvmsg+0x94/0x1d0
[ 124.023650] [<ffffffff812e9280>] ? sock_has_perm+0x70/0x90
[ 124.023653] [<ffffffff815d6502>] ? ___sys_recvmsg+0xf2/0x1f0
[ 124.023655] [<ffffffff816753b7>] inet_sendmsg+0x67/0xa0
[ 124.023657] [<ffffffff815d5aa8>] sock_sendmsg+0x38/0x50
[ 124.023659] [<ffffffff815d5f62>] SYSC_sendto+0x102/0x190
[ 124.023662] [<ffffffff8113ed6f>] ? __audit_syscall_entry+0xaf/0x100
[ 124.023665] [<ffffffff81003510>] ? syscall_trace_enter+0x1d0/0x2b0
[ 124.023667] [<ffffffff8113ef9b>] ? __audit_syscall_exit+0x1db/0x260
[ 124.023669] [<ffffffff815d6b0e>] SyS_sendto+0xe/0x10
[ 124.023670] [<ffffffff81003a47>] do_syscall_64+0x67/0x180
[ 124.023673] [<ffffffff8170f7ab>] entry_SYSCALL64_slow_path+0x25/0x25
[ 124.023688] Code: 00 00 48 89 44 24 10 8b 87 c8 00 00 00 48 89 44 24 08 48 8b 87 d8 00 00 00 48 c7 c7 50 83 ab 81 48 89 04 24 31 c0 e8 5f e6 a9 ff <0f> 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 0f 1f 44 00 00 55 48
[ 124.023690] RIP [<ffffffff817005c4>] skb_panic+0x66/0x68
[ 124.023691] RSP <ffffc900085e38e0>
[ 124.023696] ---[ end trace 95c238901cb322be ]---
[ 124.026071] Kernel panic - not syncing: Fatal exception in interrupt
[ 124.026368] Kernel Offset: disabled
[ 124.644414] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Fixes: fc791b633515 ('IB/ipoib: move back IB LL address into the hard header')
Reported-by: Norbert P <noe@physik.uzh.ch>
Signed-off-by: Honggang Li <honli@redhat.com>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index d1d3fb7..3668e1e 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1161,6 +1161,9 @@ static int ipoib_hard_header(struct sk_buff *skb,
{
struct ipoib_header *header;
+ if (unlikely(skb_headroom(skb) < IPOIB_HARD_LEN))
+ return -EINVAL;
+
header = (struct ipoib_header *) skb_push(skb, sizeof *header);
header->proto = htons(type);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Andy Shevchenko @ 2017-04-25 9:46 UTC (permalink / raw)
To: Jan Kiszka
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev,
Linux Kernel Mailing List, Sascha Weisenberger
In-Reply-To: <d7216317-e749-1347-972f-28dfe57038c0@siemens.com>
On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-04-25 09:30, Andy Shevchenko wrote:
>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-04-24 23:27, Andy Shevchenko wrote:
>>>> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> The IOT2000 is industrial controller platform, derived from the Intel
>>>>> Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the
>>>>> IOT2040 has two of them. They can be told apart based on the board asset
>>>>> tag in the DMI table.
>>
>>>>> + const char *asset_tag;
>>>>
>>>> I guess this is redundant. See below.
>>>>
>>>>> + {
>>>>> + .name = "SIMATIC IOT2000",
>>>>> + .asset_tag = "6ES7647-0AA00-0YA2",
>>>>> + .func = 6,
>>>>> + .phy_addr = 1,
>>>>> + },
>>>>
>>>> The below has same definition disregard on asset_tag.
>>>>
>>>
>>> There is a small difference in the asset tag, just not at the last digit
>>> where one may expect it, look:
>>>
>>> ...-0YA2 -> IOT2020
>>> ...-1YA2 -> IOT2040
>>
>> Yes. And how does it change my statement? You may use one record here
>> instead of two.
>
> How? Please be more verbose in your comments.
{
.name = "SIMATIC IOT2000",
.func = 6,
.phy_addr = 1,
},
{
.name = "SIMATIC IOT2000",
.func = 7,
.phy_addr = 1,
},
That's all what you need.
>> Got it, though asset_tag here is redundant as well.
> It's not as it is the only differentiating criteria to tell the
> two-ports variant apart from the one-port (and to avoid confusing it
> with any potential future variant).
And why exactly is it needed?
Sorry, but I don't see any reason to blow the code for no benefit.
> We could leave out the name, but I
> kept it for documentation purposes.
Nobody prevents you to add a comment.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Sergei Shtylyov @ 2017-04-25 9:41 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev, Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-3-eric@anholt.net>
On 4/25/2017 12:50 AM, Eric Anholt wrote:
> Cygnus has a single amac controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..318899df9972 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
[...]
> @@ -295,6 +345,16 @@
> status = "disabled";
> };
>
> + eth0: enet@18042000 {
Oh, and this one should be named "ethernet", according to the DT spec.
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1000>;
> + status = "disabled";
> + };
> +
> nand: nand@18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] rhashtable: remove insecure_max_entries param
From: Florian Westphal @ 2017-04-25 9:41 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
no users in the tree, insecure_max_entries is always set to
ht->p.max_size * 2 in rhtashtable_init().
Replace only spot that uses it with a ht->p.max_size check.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
include/linux/rhashtable.h | 6 ++----
lib/rhashtable.c | 6 ------
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index ae87dcdf52d2..ae93b65d13d7 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -125,7 +125,6 @@ struct rhashtable;
* @key_len: Length of key
* @key_offset: Offset of key in struct to be hashed
* @head_offset: Offset of rhash_head in struct to be hashed
- * @insecure_max_entries: Maximum number of entries (may be exceeded)
* @max_size: Maximum size while expanding
* @min_size: Minimum size while shrinking
* @nulls_base: Base value to generate nulls marker
@@ -140,7 +139,6 @@ struct rhashtable_params {
size_t key_len;
size_t key_offset;
size_t head_offset;
- unsigned int insecure_max_entries;
unsigned int max_size;
unsigned int min_size;
u32 nulls_base;
@@ -329,8 +327,8 @@ static inline bool rht_grow_above_100(const struct rhashtable *ht,
static inline bool rht_grow_above_max(const struct rhashtable *ht,
const struct bucket_table *tbl)
{
- return ht->p.insecure_max_entries &&
- atomic_read(&ht->nelems) >= ht->p.insecure_max_entries;
+ return ht->p.max_size &&
+ (atomic_read(&ht->nelems) / 2u) >= ht->p.max_size;
}
/* The bucket lock is selected based on the hash and protects mutations
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index d22a5ef109fb..f3b82e0d417b 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -961,12 +961,6 @@ int rhashtable_init(struct rhashtable *ht,
if (params->max_size)
ht->p.max_size = rounddown_pow_of_two(params->max_size);
- if (params->insecure_max_entries)
- ht->p.insecure_max_entries =
- rounddown_pow_of_two(params->insecure_max_entries);
- else
- ht->p.insecure_max_entries = ht->p.max_size * 2;
-
ht->p.min_size = max(ht->p.min_size, HASH_MIN_SIZE);
if (params->nelem_hint)
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Sergei Shtylyov @ 2017-04-25 9:40 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev, Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-3-eric@anholt.net>
Hello.
On 4/25/2017 12:50 AM, Eric Anholt wrote:
> Cygnus has a single amac controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
My spell checker trips on "amac" and "ethernet" -- perhaps they need
capitalization?
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..318899df9972 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -142,6 +142,56 @@
> interrupts = <0>;
> };
>
> + mdio: mdio@18002000 {
> + compatible = "brcm,iproc-mdio";
> + reg = <0x18002000 0x8>;
> + #size-cells = <1>;
> + #address-cells = <0>;
> +
> + gphy0: eth-gphy@0 {
The node anmes must be generic, the DT spec has standardized
"ethernet-phy" name for this case.
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +
> + gphy1: eth-gphy@1 {
> + reg = <1>;
> + max-speed = <1000>;
> + };
> + };
[...]
> @@ -295,6 +345,16 @@
> status = "disabled";
> };
>
> + eth0: enet@18042000 {
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
I don't think "_base" suffixes are necessary here.
[...]
MBR, Sergei
^ 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