* Re: [PATCH V3 net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission
From: Neal Cardwell @ 2017-07-29 14:04 UTC (permalink / raw)
To: maowenan
Cc: Netdev, David Miller, Yuchung Cheng, Nandita Dukkipati,
weiyongjun (A), Chenweilong, Wangkefeng (Kevin)
In-Reply-To: <F95AC9340317A84688A5F0DF0246F3F2029326B6@DGGEMI512-MBX.china.huawei.com>
On Fri, Jul 28, 2017 at 9:39 PM, maowenan <maowenan@huawei.com> wrote:
> [Mao Wenan]ok, We have reproduced this issue with packetdrill yesterday,
> there is no the same issue when TLP send new data packet, RTO will be fired and
> retransmit packet.
That's great to hear that you were able to reproduce this with
packetdrill. Would you be able to share the packetdrill scripts that
reproduce your issues? I would like to make sure our proposed patch
addresses your scenarios as well.
thanks,
neal
^ permalink raw reply
* Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open
From: Måns Rullgård @ 2017-07-29 12:51 UTC (permalink / raw)
To: Mason; +Cc: Marc Gonzalez, Florian Fainelli, David S. Miller, netdev,
Linux ARM
In-Reply-To: <bfc5678a-0536-7964-0d45-8f6b104e2f1a@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 29/07/2017 14:05, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I'll take this opportunity to change flow control to
>>> off by default (it breaks several 100 Mbps switches).
>>
>> I was told to have it on by default. This is what most other drivers
>> do too. If you have faulty switches, that's your problem.
>
> Or maybe the fault is in the HW implementation, and
> it is the board's fault that the connection is hosed.
>
> How many switches did you test the driver on?
>
> We tested 4 switches, and DHCP failed on 3 of them.
> Disabling pause frames "fixed" that.
Do those switches work with other NICs?
> I could spend weeks testing dozens of switches, but
> I have to prioritize. Ethernet flow control is simply
> not an important feature in the market the SoC is
> intended for.
Sure, flow control is rarely needed with well behaved systems.
--
Måns Rullgård
^ permalink raw reply
* Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open
From: Mason @ 2017-07-29 12:44 UTC (permalink / raw)
To: Mans Rullgard
Cc: Marc Gonzalez, Florian Fainelli, David S. Miller, netdev,
Linux ARM
In-Reply-To: <yw1x379fla7r.fsf@mansr.com>
On 29/07/2017 14:05, Måns Rullgård wrote:
> Mason writes:
>
>> I'll take this opportunity to change flow control to
>> off by default (it breaks several 100 Mbps switches).
>
> I was told to have it on by default. This is what most other drivers
> do too. If you have faulty switches, that's your problem.
Or maybe the fault is in the HW implementation, and
it is the board's fault that the connection is hosed.
How many switches did you test the driver on?
We tested 4 switches, and DHCP failed on 3 of them.
Disabling pause frames "fixed" that.
I could spend weeks testing dozens of switches, but
I have to prioritize. Ethernet flow control is simply
not an important feature in the market the SoC is
intended for.
Regards.
^ permalink raw reply
* [PATCH] ss: Enclose IPv6 address in brackets
From: Florian Lehner @ 2017-07-29 12:29 UTC (permalink / raw)
To: netdev
This patch adds support for RFC2732 IPv6 address format with brackets
for the tool ss. So output for ss changes from
2a00:1450:400a:804::200e:443 to [2a00:1450:400a:804::200e]:443 for IPv6
addresses with attached port number.
Signed-off-by: Lehner Florian <dev@der-flo.net>
---
misc/ss.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/misc/ss.c b/misc/ss.c
index 12763c9..db39c93 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -1059,7 +1059,11 @@ static void inet_addr_print(const inet_prefix *a,
int port, unsigned int ifindex
ap = format_host(AF_INET, 4, a->data);
}
} else {
- ap = format_host(a->family, 16, a->data);
+ if (a->family == AF_INET6) {
+ sprintf(buf, "[%s]", format_host(a->family, 16, a->data));
+ } else {
+ ap = format_host(a->family, 16, a->data);
+ }
est_len = strlen(ap);
if (est_len <= addr_width)
est_len = addr_width;
--
2.9.4
^ permalink raw reply related
* Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open
From: Måns Rullgård @ 2017-07-29 12:05 UTC (permalink / raw)
To: Mason; +Cc: Marc Gonzalez, Florian Fainelli, David S. Miller, netdev,
Linux ARM
In-Reply-To: <f04a0cba-6c09-e9e4-f2d1-d8b2a7e276c9@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 29/07/2017 13:24, Måns Rullgård wrote:
>
>> Until you figure out why it's getting stuck, we can't be sure
>> it isn't caused by something that could trigger at any time.
> Would you take a look at it, if I can reproduce on tango4?
>
> I have identified a 100% reproducible flaw.
> I have proposed a work-around that brings this down to 0
> (tested 1000 cycles of link up / ping / link down).
>
> In my opinion, upstream should consider this work-around
> for inclusion. I'd like to hear David's and Florian's
> opinion on the topic. It's always a pain to maintain
> out-of-tree patches.
I'm not saying it shouldn't be fixed. I am saying we should make sure
we make the right fix, not just paper over one instance of a wider issue.
>> Yes, but by then you've reset those parameters to the defaults.
>
> Good catch. There is some non HW-related init in
> nb8800_hw_init().
>
> I'll take this opportunity to change flow control to
> off by default (it breaks several 100 Mbps switches).
I was told to have it on by default. This is what most other drivers do
too. If you have faulty switches, that's your problem.
--
Måns Rullgård
^ permalink raw reply
* Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open
From: Mason @ 2017-07-29 12:02 UTC (permalink / raw)
To: Mans Rullgard
Cc: Marc Gonzalez, Florian Fainelli, David S. Miller, netdev,
Linux ARM
In-Reply-To: <yw1x7eyrlc3s.fsf@mansr.com>
On 29/07/2017 13:24, Måns Rullgård wrote:
> Until you figure out why it's getting stuck, we can't be sure
> it isn't caused by something that could trigger at any time.
Would you take a look at it, if I can reproduce on tango4?
I have identified a 100% reproducible flaw.
I have proposed a work-around that brings this down to 0
(tested 1000 cycles of link up / ping / link down).
In my opinion, upstream should consider this work-around
for inclusion. I'd like to hear David's and Florian's
opinion on the topic. It's always a pain to maintain
out-of-tree patches.
> Yes, but by then you've reset those parameters to the defaults.
Good catch. There is some non HW-related init in
nb8800_hw_init().
I'll take this opportunity to change flow control to
off by default (it breaks several 100 Mbps switches).
I'll take a closer look at priv assignments on Monday.
Regards.
^ permalink raw reply
* Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open
From: Måns Rullgård @ 2017-07-29 11:24 UTC (permalink / raw)
To: Mason; +Cc: Marc Gonzalez, Florian Fainelli, David S. Miller, netdev,
Linux ARM
In-Reply-To: <446e3a95-80c3-0742-9cb1-69a8dfc9b1ae@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 28/07/2017 20:56, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> On 28/07/2017 18:17, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez wrote:
>>>>
>>>>> ndo_stop breaks RX in a way that ndo_open is unable to undo.
>>>>
>>>> Please elaborate. Why can't it be fixed in a less heavy-handed way?
>>>
>>> I'm not sure what "elaborate" means. After we've been through
>>> ndo_stop once, the board can send packets, but it doesn't see
>>> any replies from remote systems. RX is wedged.
>>
>> So you say, but you have not explained why this happens. Until we know
>> why, we can't decide on the proper fix.
>
> I'll try adding delays in strategic places, and see if
> I can trigger the same bug on tango4. If I can't, then
> this work around is all we've got.
>
> And I need nb8800_init for resume anyway, so I might
> as well use it in ndo_open.
>
> TODO: test power savings from holding HW in reset.
>
>>> I think ndo_stop is rare enough an event that doing a full
>>> reset is not an issue, in terms of performance.
>>
>> Performance isn't the issue. Doing the right thing is.
>
> I don't have always have time to figure out exactly how
> broken HW is broken. It's already bad enough that disabling
> DMA requires sending a fake packet through the loop back...
Until you figure out why it's getting stuck, we can't be sure it isn't
caused by something that could trigger at any time.
>>>> I'm pretty sure this doesn't preserve everything it should.
>>>
>>> Hmmm, we're supposed to start fresh ("full reset").
>>> What could there be to preserve?
>>> You mentioned flow control and multicast elsewhere.
>>> I will take a closer look. Thanks for the heads up.
>>
>> Yes, those settings are definitely lost with your patch. Now I'm not
>> sure whether the networking core expects these to survive a stop/start
>> cycle, so please check that. There might also be other less obvious
>> things that need to be preserved.
>
> The original code calls nb8800_pause_config() every
> time the link comes up. The proposed patch doesn't
> change that.
Yes, but by then you've reset those parameters to the defaults.
--
Måns Rullgård
^ permalink raw reply
* Re: [PATCH net-next v11 3/4] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jamal Hadi Salim @ 2017-07-29 11:21 UTC (permalink / raw)
To: Jiri Pirko
Cc: davem, netdev, xiyou.wangcong, dsahern, eric.dumazet, mrv,
simon.horman, alex.aring
In-Reply-To: <20170729071958.GA1858@nanopsycho>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
On 17-07-29 03:19 AM, Jiri Pirko wrote:
> That is what the code I wrote above do. And I think that your code does
> not (if you don't assume that allowed flags are always starting from the
> least significant bit)
Ok, here's how it looks now..
I still have to move things around in the other patches and do testing
but i think this looks good.
cheers,
jamal
[-- Attachment #2: patchlet --]
[-- Type: text/plain, Size: 4976 bytes --]
commit 79e3e2a9d292179513df1591fb50b5bbe3bf8cc3
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sun Jul 23 08:58:04 2017 -0400
net netlink: Add new type NLA_BITFIELD32
Generic bitflags attribute content sent to the kernel by user.
With this netlink attr type the user can either set or unset a
flag in the kernel.
The value is a bitmap that defines the bit values being set
The selector is a bitmask that defines which value bit is to be
considered.
A check is made to ensure the rules that a kernel subsystem always
conforms to bitflags the kernel already knows about. i.e
if the user tries to set a bit flag that is not understood then
the _it will be rejected_.
In the most basic form, the user specifies the attribute policy as:
[ATTR_GOO] = { .type = NLA_BITFIELD32, .validation_data = &myvalidflags },
where myvalidflags is the bit mask of the flags the kernel understands.
If the user _does not_ provide myvalidflags then the attribute will
also be rejected.
Examples:
value = 0x0, and selector = 0x1
implies we are selecting bit 1 and we want to set its value to 0.
value = 0x2, and selector = 0x2
implies we are selecting bit 2 and we want to set its value to 1.
Suggested-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
diff --git a/include/net/netlink.h b/include/net/netlink.h
index ef8e6c3..82dd298 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -178,6 +178,7 @@ enum {
NLA_S16,
NLA_S32,
NLA_S64,
+ NLA_BITFIELD32,
__NLA_TYPE_MAX,
};
@@ -206,6 +207,7 @@ enum {
* NLA_MSECS Leaving the length field zero will verify the
* given type fits, using it verifies minimum length
* just like "All other"
+ * NLA_BITFIELD32 A 32-bit bitmap/bitselector attribute
* All other Minimum length of attribute payload
*
* Example:
@@ -213,11 +215,13 @@ enum {
* [ATTR_FOO] = { .type = NLA_U16 },
* [ATTR_BAR] = { .type = NLA_STRING, .len = BARSIZ },
* [ATTR_BAZ] = { .len = sizeof(struct mystruct) },
+ * [ATTR_GOO] = { .type = NLA_BITFIELD32, .validation_data = &myvalidflags },
* };
*/
struct nla_policy {
u16 type;
u16 len;
+ void *validation_data;
};
/**
@@ -1203,6 +1207,18 @@ static inline struct in6_addr nla_get_in6_addr(const struct nlattr *nla)
}
/**
+ * nla_get_bitfield32 - return payload of 32 bitfield attribute
+ * @nla: nla_bitfield32 attribute
+ */
+static inline struct nla_bitfield32 nla_get_bitfield32(const struct nlattr *nla)
+{
+ struct nla_bitfield32 tmp;
+
+ nla_memcpy(&tmp, nla, sizeof(tmp));
+ return tmp;
+}
+
+/**
* nla_memdup - duplicate attribute memory (kmemdup)
* @src: netlink attribute to duplicate from
* @gfp: GFP mask
diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index f86127a..f4fc9c9 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -226,5 +226,22 @@ struct nlattr {
#define NLA_ALIGN(len) (((len) + NLA_ALIGNTO - 1) & ~(NLA_ALIGNTO - 1))
#define NLA_HDRLEN ((int) NLA_ALIGN(sizeof(struct nlattr)))
+/* Generic 32 bitflags attribute content sent to the kernel.
+ *
+ * The value is a bitmap that defines the values being set
+ * The selector is a bitmask that defines which value is legit
+ *
+ * Examples:
+ * value = 0x0, and selector = 0x1
+ * implies we are selecting bit 1 and we want to set its value to 0.
+ *
+ * value = 0x2, and selector = 0x2
+ * implies we are selecting bit 2 and we want to set its value to 1.
+ *
+ */
+struct nla_bitfield32 {
+ __u32 value;
+ __u32 selector;
+};
#endif /* _UAPI__LINUX_NETLINK_H */
diff --git a/lib/nlattr.c b/lib/nlattr.c
index fb52435..ee79b7a 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -27,6 +27,30 @@
[NLA_S64] = sizeof(s64),
};
+static int validate_nla_bitfield32(const struct nlattr *nla,
+ u32 *valid_flags_allowed)
+{
+ const struct nla_bitfield32 *bf = nla_data(nla);
+ u32 *valid_flags_mask = valid_flags_allowed;
+
+ if (!valid_flags_allowed)
+ return -EINVAL;
+
+ /*disallow invalid bit selector */
+ if (bf->selector & ~*valid_flags_mask)
+ return -EINVAL;
+
+ /*disallow invalid bit values */
+ if (bf->value & ~*valid_flags_mask)
+ return -EINVAL;
+
+ /*disallow valid bit values that are not selected*/
+ if (bf->value & ~bf->selector)
+ return -EINVAL;
+
+ return 0;
+}
+
static int validate_nla(const struct nlattr *nla, int maxtype,
const struct nla_policy *policy)
{
@@ -46,6 +70,12 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
return -ERANGE;
break;
+ case NLA_BITFIELD32:
+ if (attrlen != sizeof(struct nla_bitfield32))
+ return -ERANGE;
+
+ return validate_nla_bitfield32(nla, pt->validation_data);
+
case NLA_NUL_STRING:
if (pt->len)
minlen = min_t(int, attrlen, pt->len + 1);
^ permalink raw reply related
* [PATCH 4/6] net: moxa: Remove extra space after a cast
From: SZ Lin @ 2017-07-29 10:42 UTC (permalink / raw)
To: davem
Cc: jarod, jonas.jensen, edumazet, bhumirks, tklauser, netdev,
linux-kernel, SZ Lin
In-Reply-To: <20170729104239.14999-1-sz.lin@moxa.com>
No space is necessary after a cast
This warning is found using checkpatch.pl
Signed-off-by: SZ Lin <sz.lin@moxa.com>
---
drivers/net/ethernet/moxa/moxart_ether.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 1d6384873393..31e179a651ae 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -311,7 +311,7 @@ static void moxart_tx_finished(struct net_device *ndev)
static irqreturn_t moxart_mac_interrupt(int irq, void *dev_id)
{
- struct net_device *ndev = (struct net_device *) dev_id;
+ struct net_device *ndev = (struct net_device *)dev_id;
struct moxart_mac_priv_t *priv = netdev_priv(ndev);
unsigned int ists = readl(priv->base + REG_INTERRUPT_STATUS);
--
2.13.3
^ permalink raw reply related
* [PATCH 6/6] net: moxa: Add spaces preferred around that '{+,-}'
From: SZ Lin @ 2017-07-29 10:42 UTC (permalink / raw)
To: davem
Cc: jarod, jonas.jensen, edumazet, bhumirks, tklauser, netdev,
linux-kernel, SZ Lin
In-Reply-To: <20170729104239.14999-1-sz.lin@moxa.com>
This patch fixes all checkpatch occurences of
"CHECK: spaces preferred around that '{+,-}' (ctx:VxV)"
in moxart_ether code.
Signed-off-by: SZ Lin <sz.lin@moxa.com>
---
drivers/net/ethernet/moxa/moxart_ether.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
index 686b8957d5cf..bee608b547d1 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.h
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -55,17 +55,17 @@
#define RX_DESC2_ADDRESS_VIRT 4
#define TX_DESC_NUM 64
-#define TX_DESC_NUM_MASK (TX_DESC_NUM-1)
+#define TX_DESC_NUM_MASK (TX_DESC_NUM - 1)
#define TX_NEXT(N) (((N) + 1) & (TX_DESC_NUM_MASK))
#define TX_BUF_SIZE 1600
-#define TX_BUF_SIZE_MAX (TX_DESC1_BUF_SIZE_MASK+1)
+#define TX_BUF_SIZE_MAX (TX_DESC1_BUF_SIZE_MASK + 1)
#define TX_WAKE_THRESHOLD 16
#define RX_DESC_NUM 64
-#define RX_DESC_NUM_MASK (RX_DESC_NUM-1)
+#define RX_DESC_NUM_MASK (RX_DESC_NUM - 1)
#define RX_NEXT(N) (((N) + 1) & (RX_DESC_NUM_MASK))
#define RX_BUF_SIZE 1600
-#define RX_BUF_SIZE_MAX (RX_DESC1_BUF_SIZE_MASK+1)
+#define RX_BUF_SIZE_MAX (RX_DESC1_BUF_SIZE_MASK + 1)
#define REG_INTERRUPT_STATUS 0
#define REG_INTERRUPT_MASK 4
--
2.13.3
^ permalink raw reply related
* [PATCH 5/6] net: moxa: Fix for typo in comment to function moxart_mac_setup_desc_ring()
From: SZ Lin @ 2017-07-29 10:42 UTC (permalink / raw)
To: davem
Cc: jarod, jonas.jensen, edumazet, bhumirks, tklauser, netdev,
linux-kernel, SZ Lin
In-Reply-To: <20170729104239.14999-1-sz.lin@moxa.com>
Signed-off-by: SZ Lin <sz.lin@moxa.com>
---
drivers/net/ethernet/moxa/moxart_ether.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 31e179a651ae..2e4effa9fe45 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -161,7 +161,7 @@ static void moxart_mac_setup_desc_ring(struct net_device *ndev)
priv->rx_head = 0;
- /* reset the MAC controller TX/RX desciptor base address */
+ /* reset the MAC controller TX/RX descriptor base address */
writel(priv->tx_base, priv->base + REG_TXR_BASE_ADDRESS);
writel(priv->rx_base, priv->base + REG_RXR_BASE_ADDRESS);
}
--
2.13.3
^ permalink raw reply related
* [PATCH 3/6] net: moxa: Fix comparison to NULL could be written with !
From: SZ Lin @ 2017-07-29 10:42 UTC (permalink / raw)
To: davem
Cc: jarod, jonas.jensen, edumazet, bhumirks, tklauser, netdev,
linux-kernel, SZ Lin
In-Reply-To: <20170729104239.14999-1-sz.lin@moxa.com>
Fixed coding style for null comparisons in moxart_ether driver
to be more consistent with the rest of the kernel coding style
Signed-off-by: SZ Lin <sz.lin@moxa.com>
---
drivers/net/ethernet/moxa/moxart_ether.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 9997e72103d5..1d6384873393 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -494,7 +494,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
priv->tx_desc_base = dma_alloc_coherent(NULL, TX_REG_DESC_SIZE *
TX_DESC_NUM, &priv->tx_base,
GFP_DMA | GFP_KERNEL);
- if (priv->tx_desc_base == NULL) {
+ if (!priv->tx_desc_base) {
ret = -ENOMEM;
goto init_fail;
}
@@ -502,7 +502,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
priv->rx_desc_base = dma_alloc_coherent(NULL, RX_REG_DESC_SIZE *
RX_DESC_NUM, &priv->rx_base,
GFP_DMA | GFP_KERNEL);
- if (priv->rx_desc_base == NULL) {
+ if (!priv->rx_desc_base) {
ret = -ENOMEM;
goto init_fail;
}
--
2.13.3
^ permalink raw reply related
* [PATCH 2/6] net: moxa: Prefer 'unsigned int' to bare use of 'unsigned'
From: SZ Lin @ 2017-07-29 10:42 UTC (permalink / raw)
To: davem
Cc: jarod, jonas.jensen, edumazet, bhumirks, tklauser, netdev,
linux-kernel, SZ Lin
In-Reply-To: <20170729104239.14999-1-sz.lin@moxa.com>
Use 'unsigned int' instead of 'unsigned'
This warning is found using checkpatch.pl
Signed-off-by: SZ Lin <sz.lin@moxa.com>
---
drivers/net/ethernet/moxa/moxart_ether.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 105215862949..9997e72103d5 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -288,8 +288,8 @@ static int moxart_tx_queue_space(struct net_device *ndev)
static void moxart_tx_finished(struct net_device *ndev)
{
struct moxart_mac_priv_t *priv = netdev_priv(ndev);
- unsigned tx_head = priv->tx_head;
- unsigned tx_tail = priv->tx_tail;
+ unsigned int tx_head = priv->tx_head;
+ unsigned int tx_tail = priv->tx_tail;
while (tx_tail != tx_head) {
dma_unmap_single(&ndev->dev, priv->tx_mapping[tx_tail],
--
2.13.3
^ permalink raw reply related
* [PATCH 1/6] net: moxa: Remove braces from single-line body
From: SZ Lin @ 2017-07-29 10:42 UTC (permalink / raw)
To: davem
Cc: jarod, jonas.jensen, edumazet, bhumirks, tklauser, netdev,
linux-kernel, SZ Lin
In-Reply-To: <20170729104239.14999-1-sz.lin@moxa.com>
Remove unnecessary braces from single-line if statement
This warning is found using checkpatch.pl
Signed-off-by: SZ Lin <sz.lin@moxa.com>
---
drivers/net/ethernet/moxa/moxart_ether.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index c0d7d5eec7e7..105215862949 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -269,9 +269,8 @@ static int moxart_rx_poll(struct napi_struct *napi, int budget)
priv->rx_head = rx_head;
}
- if (rx < budget) {
+ if (rx < budget)
napi_complete_done(napi, rx);
- }
priv->reg_imr |= RPKT_FINISH_M;
writel(priv->reg_imr, priv->base + REG_INTERRUPT_MASK);
--
2.13.3
^ permalink raw reply related
* [PATCH 0/6] net: moxa: Fix style issues
From: SZ Lin @ 2017-07-29 10:42 UTC (permalink / raw)
To: davem
Cc: jarod, jonas.jensen, edumazet, bhumirks, tklauser, netdev,
linux-kernel, SZ Lin
This patch set fixs the WARNINGs found by the checkpatch.pl tool
SZ Lin (6):
net: moxa: Remove braces from single-line body
net: moxa: Prefer 'unsigned int' to bare use of 'unsigned'
net: moxa: Fix comparison to NULL could be written with !
net: moxa: Remove extra space after a cast
net: moxa: Fix for typo in comment to function
moxart_mac_setup_desc_ring()
net: moxa: Add spaces preferred around that '{+,-}'
drivers/net/ethernet/moxa/moxart_ether.c | 15 +++++++--------
drivers/net/ethernet/moxa/moxart_ether.h | 8 ++++----
2 files changed, 11 insertions(+), 12 deletions(-)
--
2.13.3
^ permalink raw reply
* Re: [PATCH 0/2] constify nf_hook_ops structures
From: Julia Lawall @ 2017-07-29 9:56 UTC (permalink / raw)
To: Florian Westphal
Cc: Julia Lawall, linux-decnet-user, bhumirks, kernel-janitors,
Pablo Neira Ayuso, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20170729094136.GG28392@breakpoint.cc>
On Sat, 29 Jul 2017, Florian Westphal wrote:
> Julia Lawall <julia.lawall@lip6.fr> wrote:
> > On Sat, 29 Jul 2017, Florian Westphal wrote:
> > > From a quick glance I don't see why we can't e.g. constify
> > > nf_conntrack_l3/4_proto too. It is not going to be as simple
> > > as just placing const everywhere, but I see no requirement for
> > > having these writeable.
> >
> > I will take a look.
>
> Thanks.
For the protos, the functions nf_ct_l3proto_register and
nf_ct_l4proto_register_one update the nla_size field. I don't know how
many structures reach these functions.
julia
>
> nf_logger and nf_loginfo also look like constify candidates.
>
> If there is a way to add "const" qualifier to pointer-to-structs
> that are not modified this would good as well to have IMO, if just
> for purpose of documentation. For instance:
>
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1177,8 +1177,8 @@ void nf_conntrack_free(struct nf_conn *ct)
> static noinline struct nf_conntrack_tuple_hash *
> init_conntrack(struct net *net, struct nf_conn *tmpl,
> const struct nf_conntrack_tuple *tuple,
> - struct nf_conntrack_l3proto *l3proto,
> - struct nf_conntrack_l4proto *l4proto,
> + const struct nf_conntrack_l3proto *l3proto,
> + const struct nf_conntrack_l4proto *l4proto,
>
>
> (its only passed as arg to a function that expects
> "const struct nf_conntrack_x *").
>
> I think we have several (also non-static helpers) that
> take "struct foo *" arg while they could use "const struct foo*"
> instead.
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 0/2] constify nf_hook_ops structures
From: Florian Westphal @ 2017-07-29 9:41 UTC (permalink / raw)
To: Julia Lawall
Cc: Florian Westphal, linux-decnet-user, bhumirks, kernel-janitors,
Pablo Neira Ayuso, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.20.1707291120580.2002@hadrien>
Julia Lawall <julia.lawall@lip6.fr> wrote:
> On Sat, 29 Jul 2017, Florian Westphal wrote:
> > From a quick glance I don't see why we can't e.g. constify
> > nf_conntrack_l3/4_proto too. It is not going to be as simple
> > as just placing const everywhere, but I see no requirement for
> > having these writeable.
>
> I will take a look.
Thanks.
nf_logger and nf_loginfo also look like constify candidates.
If there is a way to add "const" qualifier to pointer-to-structs
that are not modified this would good as well to have IMO, if just
for purpose of documentation. For instance:
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1177,8 +1177,8 @@ void nf_conntrack_free(struct nf_conn *ct)
static noinline struct nf_conntrack_tuple_hash *
init_conntrack(struct net *net, struct nf_conn *tmpl,
const struct nf_conntrack_tuple *tuple,
- struct nf_conntrack_l3proto *l3proto,
- struct nf_conntrack_l4proto *l4proto,
+ const struct nf_conntrack_l3proto *l3proto,
+ const struct nf_conntrack_l4proto *l4proto,
(its only passed as arg to a function that expects
"const struct nf_conntrack_x *").
I think we have several (also non-static helpers) that
take "struct foo *" arg while they could use "const struct foo*"
instead.
^ permalink raw reply
* Re: [PATCH 0/2] constify nf_hook_ops structures
From: Julia Lawall @ 2017-07-29 9:21 UTC (permalink / raw)
To: Florian Westphal
Cc: linux-decnet-user, bhumirks, kernel-janitors, Pablo Neira Ayuso,
Jozsef Kadlecsik, David S. Miller, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <20170729091618.GF28392@breakpoint.cc>
On Sat, 29 Jul 2017, Florian Westphal wrote:
> Julia Lawall <julia.lawall@lip6.fr> wrote:
> >
> >
> > On Sat, 29 Jul 2017, Florian Westphal wrote:
> >
> > > Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> > > > The nf_hook_ops structure is only passed as the second argument to
> > > > nf_register_net_hook or nf_unregister_net_hook, both of which are
> > > > declared as const. Thus the nf_hook_ops structure itself can be
> > > > const.
> > >
> > > Right, also see
> > > http://patchwork.ozlabs.org/patch/793767/
> > >
> > > This series misses most of them (all arrays perhaps)?
> >
> > Yes, my rule doesn't look for arrays. I guess they are all done already
> > anyway?
>
> I think so (the patch is not yet applied though).
OK, just drop my patch then.
>
> From a quick glance I don't see why we can't e.g. constify
> nf_conntrack_l3/4_proto too. It is not going to be as simple
> as just placing const everywhere, but I see no requirement for
> having these writeable.
I will take a look.
thanks,
julia
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 0/2] constify nf_hook_ops structures
From: Florian Westphal @ 2017-07-29 9:16 UTC (permalink / raw)
To: Julia Lawall
Cc: Florian Westphal, linux-decnet-user, bhumirks, kernel-janitors,
Pablo Neira Ayuso, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.20.1707291049370.2002@hadrien>
Julia Lawall <julia.lawall@lip6.fr> wrote:
>
>
> On Sat, 29 Jul 2017, Florian Westphal wrote:
>
> > Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> > > The nf_hook_ops structure is only passed as the second argument to
> > > nf_register_net_hook or nf_unregister_net_hook, both of which are
> > > declared as const. Thus the nf_hook_ops structure itself can be
> > > const.
> >
> > Right, also see
> > http://patchwork.ozlabs.org/patch/793767/
> >
> > This series misses most of them (all arrays perhaps)?
>
> Yes, my rule doesn't look for arrays. I guess they are all done already
> anyway?
I think so (the patch is not yet applied though).
>From a quick glance I don't see why we can't e.g. constify
nf_conntrack_l3/4_proto too. It is not going to be as simple
as just placing const everywhere, but I see no requirement for
having these writeable.
^ permalink raw reply
* Re: [PATCH 0/2] constify nf_hook_ops structures
From: Julia Lawall @ 2017-07-29 8:50 UTC (permalink / raw)
To: Florian Westphal
Cc: linux-decnet-user, bhumirks, kernel-janitors, Pablo Neira Ayuso,
Jozsef Kadlecsik, David S. Miller, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <20170729084429.GE28392@breakpoint.cc>
On Sat, 29 Jul 2017, Florian Westphal wrote:
> Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> > The nf_hook_ops structure is only passed as the second argument to
> > nf_register_net_hook or nf_unregister_net_hook, both of which are
> > declared as const. Thus the nf_hook_ops structure itself can be
> > const.
>
> Right, also see
> http://patchwork.ozlabs.org/patch/793767/
>
> This series misses most of them (all arrays perhaps)?
Yes, my rule doesn't look for arrays. I guess they are all done already
anyway?
thanks,
julia
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net] ipv4: fib: Fix NULL pointer deref during fib_sync_down_dev()
From: Michał Mirosław @ 2017-07-29 8:48 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, xiyou.wangcong
In-Reply-To: <20170728202744.2729-1-idosch@mellanox.com>
On Fri, Jul 28, 2017 at 11:27:44PM +0300, Ido Schimmel wrote:
> Michał reported a NULL pointer deref during fib_sync_down_dev() when
> unregistering a netdevice. The problem is that we don't check for
> 'in_dev' being NULL, which can happen in very specific cases.
>
> Usually routes are flushed upon NETDEV_DOWN sent in either the netdev or
> the inetaddr notification chains. However, if an interface isn't
> configured with any IP address, then it's possible for host routes to be
> flushed following NETDEV_UNREGISTER, after NULLing dev->ip_ptr in
> inetdev_destroy().
>
> To reproduce:
> $ ip link add type dummy
> $ ip route add local 1.1.1.0/24 dev dummy0
> $ ip link del dev dummy0
>
> Fix this by checking for the presence of 'in_dev' before referencing it.
>
> Fixes: 982acb97560c ("ipv4: fib: Notify about nexthop status changes")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Reported-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Tested-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Thanks!
^ permalink raw reply
* Re: [PATCH 0/2] constify nf_hook_ops structures
From: Florian Westphal @ 2017-07-29 8:44 UTC (permalink / raw)
To: Julia Lawall
Cc: linux-decnet-user, bhumirks, kernel-janitors, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <1501310455-7896-1-git-send-email-Julia.Lawall@lip6.fr>
Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> The nf_hook_ops structure is only passed as the second argument to
> nf_register_net_hook or nf_unregister_net_hook, both of which are
> declared as const. Thus the nf_hook_ops structure itself can be
> const.
Right, also see
http://patchwork.ozlabs.org/patch/793767/
This series misses most of them (all arrays perhaps)?
^ permalink raw reply
* Re: [PATCH net] bpf: fix bpf_prog_get_info_by_fd to dump correct xlated_prog_len
From: Martin KaFai Lau @ 2017-07-29 8:18 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, kafai, alexei.starovoitov, netdev
In-Reply-To: <a88afb3f19e16a937683bc2bfa80100144fb3792.1501254197.git.daniel@iogearbox.net>
On Fri, Jul 28, 2017 at 11:05 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> bpf_prog_size(prog->len) is not the correct length we want to dump
> back to user space. The code in bpf_prog_get_info_by_fd() uses this
> to copy prog->insnsi to user space, but bpf_prog_size(prog->len) also
> includes the size of struct bpf_prog itself plus program instructions
> and is usually used either in context of accounting or for bpf_prog_alloc()
> et al, thus we copy out of bounds in bpf_prog_get_info_by_fd()
> potentially. Use the correct bpf_prog_insn_size() instead.
Acked-by: Martin KaFai Lau <kafai@fb.com>
>
> Fixes: 1e2709769086 ("bpf: Add BPF_OBJ_GET_INFO_BY_FD")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> kernel/bpf/syscall.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 84bb399..6c772ad 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -1312,7 +1312,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
> }
>
> ulen = info.xlated_prog_len;
> - info.xlated_prog_len = bpf_prog_size(prog->len);
> + info.xlated_prog_len = bpf_prog_insn_size(prog);
> if (info.xlated_prog_len && ulen) {
> uinsns = u64_to_user_ptr(info.xlated_prog_insns);
> ulen = min_t(u32, info.xlated_prog_len, ulen);
> --
> 1.9.3
>
^ permalink raw reply
* Re: [PATCH net] bpf: don't indicate success when copy_from_user fails
From: Martin KaFai Lau @ 2017-07-29 8:17 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, kafai, alexei.starovoitov, netdev
In-Reply-To: <af76c90679bef1488ffb97b9b80f250b6738db57.1501182003.git.daniel@iogearbox.net>
On Fri, Jul 28, 2017 at 3:02 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> err in bpf_prog_get_info_by_fd() still holds 0 at that time from prior
> check_uarg_tail_zero() check. Explicitly return -EFAULT instead, so
> user space can be notified of buggy behavior.
Thanks for fixing it. (I am on PTO and cannot use my usual email account).
Acked-by: Martin KaFai Lau <kafai@fb.com>
>
> Fixes: 1e2709769086 ("bpf: Add BPF_OBJ_GET_INFO_BY_FD")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> kernel/bpf/syscall.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 045646d..84bb399 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -1289,7 +1289,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
> info_len = min_t(u32, sizeof(info), info_len);
>
> if (copy_from_user(&info, uinfo, info_len))
> - return err;
> + return -EFAULT;
>
> info.type = prog->type;
> info.id = prog->aux->id;
> --
> 1.9.3
>
^ permalink raw reply
* Re: [PATCH][V2] batman-adv: fix various spelling mistakes
From: Sven Eckelmann @ 2017-07-29 8:03 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: Marek Lindner, netdev-u79uwXL29TY76Z2rM5mHXA, Antonio Quartulli,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Colin King, David S . Miller
In-Reply-To: <20170626102644.11337-1-colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Montag, 26. Juni 2017 11:26:44 CEST Colin King wrote:
> From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
>
> Trivial fix to spelling mistakes in batadv_dbg debug messages and
> also in a comment and ensure comment line is not wider than 80
> characters
>
> "ourselve" -> "ourselves"
> "surpressed" -> "suppressed"
> "troughput" -> "throughput"
>
> Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Applied as f25cbb2a6ac1ce702d8c39222bc13c24a69bb5ef [1]
Thanks,
Sven
[1] https://git.open-mesh.org/linux-merge.git/commit/f25cbb2a6ac1ce702d8c39222bc13c24a69bb5ef
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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