* Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Andy Shevchenko @ 2017-04-24 21:27 UTC (permalink / raw)
To: Jan Kiszka
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev,
Linux Kernel Mailing List, Sascha Weisenberger
In-Reply-To: <8c536123-6189-e0b6-1977-dc7a521718dd@siemens.com>
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.
>
> Based on patch by Sascha Weisenberger.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Signed-off-by: Sascha Weisenberger <sascha.weisenberger@siemens.com>
Shoudn't be ordered other way around?
> + 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.
> + {
> + .name = "SIMATIC IOT2000",
> + .asset_tag = "6ES7647-0AA00-1YA2",
> + .func = 6,
> + .phy_addr = 1,
> + },
> + {
> + .name = "SIMATIC IOT2000",
> + .asset_tag = "6ES7647-0AA00-1YA2",
> + .func = 7,
> + .phy_addr = 1,
> + },
How this supposed to work if phy_addr is the same?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net 2/3] net: dsa: b53: Implement software reset for 58xx devices
From: Florian Fainelli @ 2017-04-24 21:27 UTC (permalink / raw)
To: netdev; +Cc: andrew, vivien.didelot, eric, jon.mason, Florian Fainelli
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
Implement the correct software reset sequence for 58xx devices by
setting all 3 reset bits and polling for the SW_RST bit to clear itself
without a given timeout. We cannot use is58xx() here because that would
also include the 7445/7278 Starfighter 2 which have their own driver
doing the reset earlier on due to the HW specific integration.
Fixes: 991a36bb4645 ("net: dsa: b53: Add support for BCM585xx/586xx/88312 integrated switch")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 25 ++++++++++++++++++++++++-
drivers/net/dsa/b53/b53_regs.h | 1 +
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index ca7f3b005a29..b66ee18cbe49 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -608,7 +608,8 @@ static void b53_switch_reset_gpio(struct b53_device *dev)
static int b53_switch_reset(struct b53_device *dev)
{
- u8 mgmt;
+ unsigned int timeout = 1000;
+ u8 mgmt, reg;
b53_switch_reset_gpio(dev);
@@ -617,6 +618,28 @@ static int b53_switch_reset(struct b53_device *dev)
b53_write8(dev, B53_CTRL_PAGE, B53_SOFTRESET, 0x00);
}
+ /* This is specific to 58xx devices here, do not use is58xx() which
+ * covers the larger Starfigther 2 family, including 7445/7278 which
+ * still use this driver as a library and need to perform the reset
+ * earlier.
+ */
+ if (dev->chip_id == BCM58XX_DEVICE_ID) {
+ b53_read8(dev, B53_CTRL_PAGE, B53_SOFTRESET, ®);
+ reg |= SW_RST | EN_SW_RST | EN_CH_RST;
+ b53_write8(dev, B53_CTRL_PAGE, B53_SOFTRESET, reg);
+
+ do {
+ b53_read8(dev, B53_CTRL_PAGE, B53_SOFTRESET, ®);
+ if (!(reg & SW_RST))
+ break;
+
+ usleep_range(1000, 2000);
+ } while (timeout-- > 0);
+
+ if (timeout == 0)
+ return -ETIMEDOUT;
+ }
+
b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
if (!(mgmt & SM_SW_FWD_EN)) {
diff --git a/drivers/net/dsa/b53/b53_regs.h b/drivers/net/dsa/b53/b53_regs.h
index f2a060e7a637..e5c86d44667a 100644
--- a/drivers/net/dsa/b53/b53_regs.h
+++ b/drivers/net/dsa/b53/b53_regs.h
@@ -143,6 +143,7 @@
/* Software reset register (8 bit) */
#define B53_SOFTRESET 0x79
#define SW_RST BIT(7)
+#define EN_CH_RST BIT(6)
#define EN_SW_RST BIT(4)
/* Fast Aging Control register (8 bit) */
--
2.9.3
^ permalink raw reply related
* [PATCH net 3/3] net: dsa: b53: Fix CPU port for 58xx devices
From: Florian Fainelli @ 2017-04-24 21:27 UTC (permalink / raw)
To: netdev; +Cc: andrew, vivien.didelot, eric, jon.mason, Florian Fainelli
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
The 58xx devices (Northstar Plus) do actually have their CPU port wired
at port 8, it was unfortunately set to port 5 (B53_CPU_PORT_25) which is
incorrect, since that is the second possible management port.
Fixes: 991a36bb4645 ("net: dsa: b53: Add support for BCM585xx/586xx/88312 integrated switch")
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index b66ee18cbe49..fa0eece21eef 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1764,7 +1764,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.vlans = 4096,
.enabled_ports = 0x1ff,
.arl_entries = 4,
- .cpu_port = B53_CPU_PORT_25,
+ .cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
.jumbo_pm_reg = B53_JUMBO_PORT_MASK,
--
2.9.3
^ permalink raw reply related
* [PATCH net 1/3] net: dsa: b53: Include IMP/CPU port in dumb forwarding mode
From: Florian Fainelli @ 2017-04-24 21:27 UTC (permalink / raw)
To: netdev; +Cc: andrew, vivien.didelot, eric, jon.mason, Florian Fainelli
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
Since Broadcom tags are not enabled in b53 (DSA_PROTO_TAG_NONE), we need
to make sure that the IMP/CPU port is included in the forwarding
decision.
Without this change, switching between non-management ports would work,
but not between management ports and non-management ports thus breaking
the default state in which DSA switch are brought up.
Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 10 ++++++++++
drivers/net/dsa/b53/b53_regs.h | 4 ++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 8cf4801994e8..ca7f3b005a29 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -326,6 +326,7 @@ static void b53_get_vlan_entry(struct b53_device *dev, u16 vid,
static void b53_set_forwarding(struct b53_device *dev, int enable)
{
+ struct dsa_switch *ds = dev->ds;
u8 mgmt;
b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
@@ -336,6 +337,15 @@ static void b53_set_forwarding(struct b53_device *dev, int enable)
mgmt &= ~SM_SW_FWD_EN;
b53_write8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, mgmt);
+
+ /* Include IMP port in dumb forwarding mode when no tagging protocol is
+ * set
+ */
+ if (ds->ops->get_tag_protocol(ds) == DSA_TAG_PROTO_NONE) {
+ b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_CTRL, &mgmt);
+ mgmt |= B53_MII_DUMB_FWDG_EN;
+ b53_write8(dev, B53_CTRL_PAGE, B53_SWITCH_CTRL, mgmt);
+ }
}
static void b53_enable_vlan(struct b53_device *dev, bool enable)
diff --git a/drivers/net/dsa/b53/b53_regs.h b/drivers/net/dsa/b53/b53_regs.h
index 9fd24c418fa4..f2a060e7a637 100644
--- a/drivers/net/dsa/b53/b53_regs.h
+++ b/drivers/net/dsa/b53/b53_regs.h
@@ -104,6 +104,10 @@
#define B53_UC_FWD_EN BIT(6)
#define B53_MC_FWD_EN BIT(7)
+/* Switch control (8 bit) */
+#define B53_SWITCH_CTRL 0x22
+#define B53_MII_DUMB_FWDG_EN BIT(6)
+
/* (16 bit) */
#define B53_UC_FLOOD_MASK 0x32
#define B53_MC_FLOOD_MASK 0x34
--
2.9.3
^ permalink raw reply related
* [PATCH net 0/3] net: dsa: b53: BCM58xx devices fixes
From: Florian Fainelli @ 2017-04-24 21:27 UTC (permalink / raw)
To: netdev; +Cc: andrew, vivien.didelot, eric, jon.mason, Florian Fainelli
Hi David,
This patch series contains fixes for the 58xx devices (Broadcom Northstar
Plus), which were identified thanks to the help of Eric Anholt.
Florian Fainelli (3):
net: dsa: b53: Include IMP/CPU port in dumb forwarding mode
net: dsa: b53: Implement software reset for 58xx devices
net: dsa: b53: Fix CPU port for 58xx devices
drivers/net/dsa/b53/b53_common.c | 37 +++++++++++++++++++++++++++++++++++--
drivers/net/dsa/b53/b53_regs.h | 5 +++++
2 files changed, 40 insertions(+), 2 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH v3 net] net: ipv6: regenerate host route if moved to gc list
From: Martin KaFai Lau @ 2017-04-24 21:08 UTC (permalink / raw)
To: David Ahern; +Cc: Eric Dumazet, netdev, dvyukov, andreyknvl, mmanning
In-Reply-To: <0ebdefd9-3f89-1876-ba03-1a8277ff79e2@cumulusnetworks.com>
On Mon, Apr 24, 2017 at 01:37:00PM -0600, David Ahern wrote:
> On 4/24/17 10:39 AM, Eric Dumazet wrote:
> >
> > Very nice changelog !
>
>
> Thanks. Given my aggressive brain cell recycling program, I needed to
> write down the analysis.
>
>
>
> >> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> >> index 80ce478c4851..93f81d9cd85f 100644
> >> --- a/net/ipv6/addrconf.c
> >> +++ b/net/ipv6/addrconf.c
> >> @@ -3271,14 +3271,25 @@ static void addrconf_gre_config(struct net_device *dev)
> >> static int fixup_permanent_addr(struct inet6_dev *idev,
> >> struct inet6_ifaddr *ifp)
> >> {
> >> - if (!ifp->rt) {
> >> - struct rt6_info *rt;
> >> + /* rt6i_ref == 0 means the host route was removed from the
> >> + * FIB, for example, if 'lo' device is taken down. In that
> >> + * case regenerate the host route.
> >> + */
> >> + if (!ifp->rt || !atomic_read(&ifp->rt->rt6i_ref)) {
> >> + struct rt6_info *rt, *prev;
> >>
> >> rt = addrconf_dst_alloc(idev, &ifp->addr, false);
> >> if (unlikely(IS_ERR(rt)))
> >> return PTR_ERR(rt);
> >>
> >> + prev = ifp->rt;
> >
> > I would feel more comfortable if this was moved after the spin_lock() ?
>
> That's what I had in v2; it reads better to me even if it is not
> technically required (all changes to ifp->rt happen under rtnl).
>
> Martin you agree?
Agree.
My question was mainly on the added spin_lock.
>
> I'll send a v3 tomorrow -- allow more time for other comments.
^ permalink raw reply
* Re: Get amount of fast retransmissions from TCP info
From: Neal Cardwell @ 2017-04-24 21:00 UTC (permalink / raw)
To: Lars Erik Storbukås; +Cc: LKML, Netdev
In-Reply-To: <CAF0XkCDTexCTxPmGvM4+FZtVhQg13Ggsbm0QSbcKCSR5LGbs9w@mail.gmail.com>
"
On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås
<storbukas.dev@gmail.com> wrote:
> 2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
>> <storbukas.dev@gmail.com> wrote:
>>> I'm trying to get amount of congestion events in TCP caused by
>>> DUPACK's (fast retransmissions), and can't seem to find any variable
>>> in the TCP info struct which hold that value. There are three
>>> variables in the TCP info struct that seem to hold similar congestion
>>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32
>>> tcpi_total_retrans;
>>>
>>> Does anyone have any pointers on how to find this value in the TCP code?
>>>
>>> Please CC me personally if answering this question. Any help is
>>> greatly appreciated.
>>
>> [I'm cc-ing the netdev list.]
>>
>> Do you need this per-socket? On a per-socket basis, I do not think
>> there are separate totals for fast retransmits and timeout
>> retransmits.
>>
>> If a global number is good enough, then you can get that number from
>> the global network statistics. In "nstat" output they look like:
>>
>> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery
>>
>> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery
>>
>> It sounds like TcpExtTCPFastRetrans is what you are after.
>>
>> Hope that helps,
>> neal
>
> Thanks for your answer Neal.
>
> Yes, I need this information per-socket. What would be the most
> appropriate place to update this value?
Is this for a custom kernel you are building? Or are you proposing
this for upstream?
IMHO the best place to add this for your custom kernel would be in
_tcp_retransmit_skb() around the spot with the comment "Update global
and local TCP statistics". Something like:
/* Update global and local TCP statistics. */
...
tp->total_retrans += segs;
if (icsk->icsk_ca_state == TCP_CA_Loss)
tp->slow_retrans += segs;
else
tp->fast_retrans += segs;
> If none of the variables (mentioned above) contain any value in
> regards to fast retransmits, what does the different values represent?
tcpi_retransmits: consecutive retransmits of lowest-sequence outstanding packet
tcpi_retrans: retransmitted packets estimated to be in-flight in the network now
tcpi_total_retrans: total number of retransmitted packets over the
life of the connection
Can you sketch out why you need to have separate counts for fast
retransmits and timeout/slow-start retransmits?
neal
^ permalink raw reply
* [PATCH] net: ethernet: ti: netcp_core: remove unused compl queue mapping
From: Ivan Khoronzhuk @ 2017-04-24 20:54 UTC (permalink / raw)
To: netdev, w-kwok2, m-karicheri2
Cc: linux-kernel, grygorii.strashko, Ivan Khoronzhuk
This code is unused and probably was unintentionally left while
moving completion queue mapping in submit function.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
Based on net-next/master
drivers/net/ethernet/ti/netcp_core.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 9027c9c..729a7da 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1134,7 +1134,6 @@ netcp_tx_map_skb(struct sk_buff *skb, struct netcp_intf *netcp)
u32 buf_len = skb_frag_size(frag);
dma_addr_t desc_dma;
u32 desc_dma_32;
- u32 pkt_info;
dma_addr = dma_map_page(dev, page, page_offset, buf_len,
DMA_TO_DEVICE);
@@ -1151,9 +1150,6 @@ netcp_tx_map_skb(struct sk_buff *skb, struct netcp_intf *netcp)
}
desc_dma = knav_pool_desc_virt_to_dma(netcp->tx_pool, ndesc);
- pkt_info =
- (netcp->tx_compl_qid & KNAV_DMA_DESC_RETQ_MASK) <<
- KNAV_DMA_DESC_RETQ_SHIFT;
set_pkt_info(dma_addr, buf_len, 0, ndesc);
desc_dma_32 = (u32)desc_dma;
set_words(&desc_dma_32, 1, &pdesc->next_desc);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: David Miller @ 2017-04-24 20:30 UTC (permalink / raw)
To: jhs; +Cc: simon.horman, jiri, xiyou.wangcong, eric.dumazet, netdev, tom,
pablo
In-Reply-To: <2ca4266f-a164-d2ad-37fa-45f7ae354eb8@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 24 Apr 2017 08:49:00 -0400
> Yes, space is important and if i can express upto 32 flags
> with one TLV rather than 32 TLVs i choose one TLV.
Which is fine. But two things:
1) Again, bits you aren't using now, make sure userspace doesn't
set them. And if it does, reject.
2) If you are worried about performance, we're talking about a TLV in
the request here not the dump response itself so performance isn't
a real issue as Pablo mentioned.
^ permalink raw reply
* Re: [PATCH net-next 0/3] Misc BPF cleanup
From: David Miller @ 2017-04-24 20:20 UTC (permalink / raw)
To: alexander; +Cc: netdev, daniel, ast
In-Reply-To: <20170424133108.31595-1-alexander@alemayhu.com>
From: Alexander Alemayhu <alexander@alemayhu.com>
Date: Mon, 24 Apr 2017 15:31:05 +0200
> while looking into making the Makefile in samples/bpf better handle O= I saw
> several warnings when running `make clean && make samples/bpf/`. This series
> reduces those warnings.
Series applied, thanks.
^ permalink raw reply
* Re: Get amount of fast retransmissions from TCP info
From: Lars Erik Storbukås @ 2017-04-24 20:20 UTC (permalink / raw)
To: Neal Cardwell; +Cc: LKML, Netdev
In-Reply-To: <CADVnQyk9-OGKBKBvQ76itP5JwbVBPt40S8KJ+6oY506hVpMEYA@mail.gmail.com>
2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
> <storbukas.dev@gmail.com> wrote:
>> I'm trying to get amount of congestion events in TCP caused by
>> DUPACK's (fast retransmissions), and can't seem to find any variable
>> in the TCP info struct which hold that value. There are three
>> variables in the TCP info struct that seem to hold similar congestion
>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32
>> tcpi_total_retrans;
>>
>> Does anyone have any pointers on how to find this value in the TCP code?
>>
>> Please CC me personally if answering this question. Any help is
>> greatly appreciated.
>
> [I'm cc-ing the netdev list.]
>
> Do you need this per-socket? On a per-socket basis, I do not think
> there are separate totals for fast retransmits and timeout
> retransmits.
>
> If a global number is good enough, then you can get that number from
> the global network statistics. In "nstat" output they look like:
>
> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery
>
> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery
>
> It sounds like TcpExtTCPFastRetrans is what you are after.
>
> Hope that helps,
> neal
Thanks for your answer Neal.
Yes, I need this information per-socket. What would be the most
appropriate place to update this value?
If none of the variables (mentioned above) contain any value in
regards to fast retransmits, what does the different values represent?
/Lars Erik
^ permalink raw reply
* Re: [PATCH net-next] bpf: make bpf_xdp_adjust_head support mandatory
From: David Miller @ 2017-04-24 20:18 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <6e25ef44c5de02d1feb8b4cc8a2cf60adb4a596e.1493064530.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 24 Apr 2017 22:14:35 +0200
> Now that also the last in-tree user of the xdp_adjust_head bit has
> been removed, we can remove the flag from struct bpf_prog altogether.
>
> This, at the same time, also makes sure that any future driver for
> XDP comes with bpf_xdp_adjust_head() support right away.
>
> A rejection based on this flag would also mean that tail calls
> couldn't be used with such driver as per c2002f983767 ("bpf: fix
> checking xdp_adjust_head on tail calls") fix, thus lets not allow
> for it in the first place.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks Daniel.
^ permalink raw reply
* EXTREMELY IMPORTANT
From: Ms. Katherine @ 2017-04-24 18:59 UTC (permalink / raw)
To: Recipients
Dear Beloved, Sorry for the inconvenience, I am getting in touch with you regarding an extremely important and urgent matter, Please I need your urgent assistance and idea to finish up a project (Orphanage Home) Due to my health condition, Everything is available to finish up the project, All I need is your idea and trust.
Sehr geehrte Geliebte, traurig für die Unannehmlichkeiten, ich bin in Kontakt mit Ihnen über eine äußerst wichtige und dringende Angelegenheit, Bitte brauche ich Ihre dringende Hilfe und Idee, um ein Projekt zu beenden (Orphanage Home) Wegen meines Gesundheitszustandes ist alles verfügbar Beenden Sie das Projekt, Alles was ich brauche ist Ihre Idee und Vertrauen.
Please contact me for more details.
Contact Email: kathrynnmison@gmail.com
Thanks
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* [PATCH net-next] bpf: make bpf_xdp_adjust_head support mandatory
From: Daniel Borkmann @ 2017-04-24 20:14 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
Now that also the last in-tree user of the xdp_adjust_head bit has
been removed, we can remove the flag from struct bpf_prog altogether.
This, at the same time, also makes sure that any future driver for
XDP comes with bpf_xdp_adjust_head() support right away.
A rejection based on this flag would also mean that tail calls
couldn't be used with such driver as per c2002f983767 ("bpf: fix
checking xdp_adjust_head on tail calls") fix, thus lets not allow
for it in the first place.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/linux/filter.h | 3 +--
kernel/bpf/verifier.c | 3 ---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 511fe91..9a7786d 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -413,8 +413,7 @@ struct bpf_prog {
locked:1, /* Program image locked? */
gpl_compatible:1, /* Is filter GPL compatible? */
cb_access:1, /* Is control block accessed? */
- dst_needed:1, /* Do we need dst entry? */
- xdp_adjust_head:1; /* Adjusting pkt head? */
+ dst_needed:1; /* Do we need dst entry? */
kmemcheck_bitfield_end(meta);
enum bpf_prog_type type; /* Type of BPF program */
u32 len; /* Number of filter blocks */
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index ca15cf2..6f8b6ed 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3346,8 +3346,6 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
prog->dst_needed = 1;
if (insn->imm == BPF_FUNC_get_prandom_u32)
bpf_user_rnd_init_once();
- if (insn->imm == BPF_FUNC_xdp_adjust_head)
- prog->xdp_adjust_head = 1;
if (insn->imm == BPF_FUNC_tail_call) {
/* If we tail call into other programs, we
* cannot make any assumptions since they can
@@ -3355,7 +3353,6 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
* the program array.
*/
prog->cb_access = 1;
- prog->xdp_adjust_head = 1;
/* mark bpf_tail_call as different opcode to avoid
* conditional branch in the interpeter for every normal
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 1/1] qlcnic: fix unchecked return value
From: David Miller @ 2017-04-24 20:11 UTC (permalink / raw)
To: bianpan201602
Cc: harish.patil, manish.chopra, Dept-GELinuxNICDev, netdev,
linux-kernel, bianpan2016
In-Reply-To: <1492949044-23580-1-git-send-email-bianpan201602@163.com>
aFrom: Pan Bian <bianpan201602@163.com>
Date: Sun, 23 Apr 2017 20:04:04 +0800
> From: Pan Bian <bianpan2016@163.com>
>
> Function pci_find_ext_capability() may return 0, which is an invalid
> address. In function qlcnic_sriov_virtid_fn(), its return value is used
> without validation. This may result in invalid memory access bugs. This
> patch fixes the bug.
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
Applied.
^ permalink raw reply
* Re: Networking security fixes
From: David Miller @ 2017-04-24 20:07 UTC (permalink / raw)
To: ben.hutchings; +Cc: stable, netdev
In-Reply-To: <1493063249.10415.78.camel@codethink.co.uk>
From: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date: Mon, 24 Apr 2017 20:47:29 +0100
> Please queue up these fixes for 4.10.y:
>
> 8605330aac5a tcp: fix SCM_TIMESTAMPING_OPT_STATS for normal skbs
> 4ef1b2869447 tcp: mark skbs with SCM_TIMESTAMPING_OPT_STATS
Ok, queued up, thanks.
> Please can you also send the pending fixes to Greg soon, as the
> AF_PACKET issue is quite serious?
I will get to it as soon as I can.
^ permalink raw reply
* Re: PATCH drivers:net:cris/eth_v10: alternate string char arrary
From: David Miller @ 2017-04-24 20:04 UTC (permalink / raw)
To: karim.eshapa
Cc: felipe.balbi, paul.gortmaker, mugunthanvnm, jarod, fw, netdev,
linux-kernel
In-Reply-To: <1493063682-8560-1-git-send-email-karim.eshapa@gmail.com>
From: Karim Eshapa <karim.eshapa@gmail.com>
Date: Mon, 24 Apr 2017 21:54:42 +0200
> On Mon, 24 Apr 2017 14:18:58 -0400 (EDT), David Miller wrote:
>> Mon, 24 Apr 2017 19:49:39 +0200, Karim Eshapa wrote:
>>>
>>> static char pointer creates two variables in final assembly.
>>> static string and pointer to it according to
>>> Jeff Garzik janitors TODO.
>>
>> Instead of trusting some document written more than 10 years ago on
>> the internet, why don't you build the source file in question and take
>> a look at what actually happens?
>>
>
> I've just dumped the assembly and symbols. I didn't find
> extraordinary difference between the two strings.
> sorry for that, but why is that still there in
> TODO kerneljanitors at kernelnewbies.
Because nobody is updating the documentation.
^ permalink raw reply
* Re: [pull request][net 0/7] Mellanox, mlx5 fixes 2017-04-22
From: David Miller @ 2017-04-24 20:01 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20170423100802.27630-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Sun, 23 Apr 2017 13:07:55 +0300
> This series contains some mlx5 fixes for net.
>
> For your convenience, the series doesn't introduce any conflict with
> the ongoing net-next pull request.
>
> Please pull and let me know if there's any problem.
Pulled.
> For -stable:
> ("net/mlx5: E-Switch, Correctly deal with inline mode on ConnectX-5") kernels >= 4.10
> ("net/mlx5e: Fix ETHTOOL_GRXCLSRLALL handling") kernels >= 4.8
> ("net/mlx5e: Fix small packet threshold") kernels >= 4.7
> ("net/mlx5: Fix driver load bad flow when having fw initializing timeout") kernels >= 4.4
Queued up, thanks.
^ permalink raw reply
* Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it
From: Dennis Dalessandro @ 2017-04-24 20:00 UTC (permalink / raw)
To: Christoph Hellwig, Byczkowski, Jakub
Cc: Bjorn Helgaas, Cabiddu, Giovanni, Benedetto, Salvatore,
Marciniszyn, Mike, Derek Chickles, Satanand Burla, Felix Manlunas,
Raghu Vatsavayi, Kirsher, Jeffrey T,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, qat-linux,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170424143507.GA28812-jcswGhMUV9g@public.gmane.org>
On 04/24/2017 10:35 AM, Christoph Hellwig wrote:
> On Mon, Apr 24, 2017 at 02:16:31PM +0000, Byczkowski, Jakub wrote:
>> Tested-by: Jakub Byczkowski <jakub.byczkowski-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> Are you (and Doug) ok with queueing this up in the PCI tree?
We are fine however Doug wants to handle it.
-Denny
--
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 drivers:net:cris/eth_v10: alternate string char arrary
From: Karim Eshapa @ 2017-04-24 19:54 UTC (permalink / raw)
To: davem
Cc: felipe.balbi, paul.gortmaker, mugunthanvnm, jarod, fw, netdev,
linux-kernel, Karim Eshapa
In-Reply-To: <1493056179-6460-1-git-send-email-karim.eshapa@gmail.com>
On Mon, 24 Apr 2017 14:18:58 -0400 (EDT), David Miller wrote:
> Mon, 24 Apr 2017 19:49:39 +0200, Karim Eshapa wrote:
>>
>> static char pointer creates two variables in final assembly.
>> static string and pointer to it according to
>> Jeff Garzik janitors TODO.
>
> Instead of trusting some document written more than 10 years ago on
> the internet, why don't you build the source file in question and take
> a look at what actually happens?
>
I've just dumped the assembly and symbols. I didn't find
extraordinary difference between the two strings.
sorry for that, but why is that still there in
TODO kerneljanitors at kernelnewbies.
Thanks,
Karim
^ permalink raw reply
* Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled
From: Nikolay Aleksandrov @ 2017-04-24 19:52 UTC (permalink / raw)
To: Mike Manning, netdev; +Cc: David S. Miller, roopa
In-Reply-To: <1493042944-4005-1-git-send-email-mmanning@brocade.com>
On 24/04/17 17:09, Mike Manning wrote:
> Flood suppression for packets that are not unicast needs to be handled
> consistently by also not flooding broadcast packets. As broadcast is a
> special case of multicast, the same kernel parameter should be used to
> suppress flooding for both of these packet types.
>
> Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag")
> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Signed-off-by: Mike Manning <mmanning@brocade.com>
> ---
> net/bridge/br_forward.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
I do not agree that this is a bug fix, the behaviour was intentional and is close to how HW
handles this flag. It has been like that for a few releases and changing it may impact setups
that use the flag since up until now they've seen the broadcast but not multicast packets and
suddenly their broadcast will stop.
I think it would be better to introduce a third flag for bcast in net-next and use that to
filter it since that would give us the ability to program HW that can distinguish these
and have both options available, moreover it will not break any user setups relying on
the current flag behaviour and we have such setups.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH 1/1] net: bcmgenet: fix incorrect return value checks
From: Florian Fainelli @ 2017-04-24 19:52 UTC (permalink / raw)
To: David Miller, bianpan201602; +Cc: netdev, linux-kernel, bianpan2016
In-Reply-To: <20170424.154806.387657447648095027.davem@davemloft.net>
On 04/24/2017 12:48 PM, David Miller wrote:
> From: Pan Bian <bianpan201602@163.com>
> Date: Sun, 23 Apr 2017 18:01:05 +0800
>
>> From: Pan Bian <bianpan2016@163.com>
>>
>> Function platform_get_irq() will return a negative value on errors.
>> However, in function bcmgenet_probe(), 0 is considered as a flag of
>> error. This patch fixes the bug by checking whether the return value of
>> platform_get_irq() is less than 0.
>>
>> Signed-off-by: Pan Bian <bianpan2016@163.com>
>
> I'm definitely not confident enough to apply this.
>
> On some platform zero IRQs are invalid.
>
> There are also lots of pieces of code that check the return value ">
> 0" as success.
>
I don't think we are fixing any real issue by applying this patch, but I
will do a check on ARM, ARM64 and MIPS where this driver is used to see
if it is even remotely possible to have a 0 IRQ.
--
Florian
^ permalink raw reply
* Re: [PATCH 1/1] wan: pc300too: abort path on failure
From: David Miller @ 2017-04-24 19:51 UTC (permalink / raw)
To: bianpan201602; +Cc: khc, netdev, linux-kernel, bianpan2016
In-Reply-To: <1492940315-1462-1-git-send-email-bianpan201602@163.com>
From: Pan Bian <bianpan201602@163.com>
Date: Sun, 23 Apr 2017 17:38:35 +0800
> From: Pan Bian <bianpan2016@163.com>
>
> In function pc300_pci_init_one(), on the ioremap error path, function
> pc300_pci_remove_one() is called to free the allocated memory. However,
> the path is not terminated, and the freed memory will be used later,
> resulting in use-after-free bugs. This path fixes the bug.
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] tipc: check return value of nlmsg_new
From: David Miller @ 2017-04-24 19:51 UTC (permalink / raw)
To: bianpan2016; +Cc: jon.maloy, ying.xue, netdev, tipc-discussion, linux-kernel
In-Reply-To: <1492931359-25004-1-git-send-email-bianpan2016@163.com>
From: Pan Bian <bianpan2016@163.com>
Date: Sun, 23 Apr 2017 15:09:19 +0800
> Function nlmsg_new() will return a NULL pointer if there is no enough
> memory, and its return value should be checked before it is used.
> However, in function tipc_nl_node_get_monitor(), the validation of the
> return value of function nlmsg_new() is missed. This patch fixes the
> bug.
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] lwtunnel: check return value of nla_nest_start
From: David Miller @ 2017-04-24 19:51 UTC (permalink / raw)
To: bianpan2016
Cc: dsa, roopa, ast, david.lebrun, tom, rshearma, netdev,
linux-kernel
In-Reply-To: <1492928917-25628-1-git-send-email-bianpan2016@163.com>
From: Pan Bian <bianpan2016@163.com>
Date: Sun, 23 Apr 2017 14:28:37 +0800
> Function nla_nest_start() may return a NULL pointer on error. However,
> in function lwtunnel_fill_encap(), the return value of nla_nest_start()
> is not validated before it is used. This patch checks the return value
> of nla_nest_start() against NULL.
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
Applied.
^ 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