* Re: [PATCH net] net: mscc: fix the injection header
From: Alexandre Belloni @ 2018-06-20 11:29 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, f.fainelli, andrew, netdev, linux-kernel, thomas.petazzoni,
quentin.schulz, allan.nielsen
In-Reply-To: <20180620085046.2377-1-antoine.tenart@bootlin.com>
On 20/06/2018 10:50:46+0200, Antoine Ténart wrote:
> When injecting frames in the Ocelot switch driver an injection header
> (IFH) should be used to configure various parameters related to a given
> frame, such as the port onto which the frame should be departed or its
> vlan id. Other parameters in the switch configuration can led to an
> injected frame being sent without an IFH but this led to various issues
> as the per-frame parameters are then not used. This is especially true
> when using multiple ports for injection.
>
> The IFH was injected with the wrong endianness which led to the switch
> not taking it into account as the IFH_INJ_BYPASS bit was then unset.
> (The bit tells the switch to use the IFH over its internal
> configuration). This patch fixes it.
>
> In addition to the endianness fix, the IFH is also fixed. As it was
> (unwillingly) unused, some of its fields were not configured the right
> way.
>
> Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/net/ethernet/mscc/ocelot.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
> index fb2c8f8071e6..52c57e0ff617 100644
> --- a/drivers/net/ethernet/mscc/ocelot.c
> +++ b/drivers/net/ethernet/mscc/ocelot.c
> @@ -344,10 +344,9 @@ static int ocelot_port_stop(struct net_device *dev)
> static int ocelot_gen_ifh(u32 *ifh, struct frame_info *info)
> {
> ifh[0] = IFH_INJ_BYPASS;
> - ifh[1] = (0xff00 & info->port) >> 8;
> + ifh[1] = (0xf00 & info->port) >> 8;
> ifh[2] = (0xff & info->port) << 24;
> - ifh[3] = IFH_INJ_POP_CNT_DISABLE | (info->cpuq << 20) |
> - (info->tag_type << 16) | info->vid;
> + ifh[3] = (info->tag_type << 16) | info->vid;
>
> return 0;
> }
> @@ -370,11 +369,12 @@ static int ocelot_port_xmit(struct sk_buff *skb, struct net_device *dev)
> QS_INJ_CTRL_SOF, QS_INJ_CTRL, grp);
>
> info.port = BIT(port->chip_port);
> - info.cpuq = 0xff;
> + info.tag_type = IFH_TAG_TYPE_C;
> + info.vid = skb_vlan_tag_get(skb);
> ocelot_gen_ifh(ifh, &info);
>
> for (i = 0; i < IFH_LEN; i++)
> - ocelot_write_rix(ocelot, ifh[i], QS_INJ_WR, grp);
> + ocelot_write_rix(ocelot, cpu_to_be32(ifh[i]), QS_INJ_WR, grp);
>
> count = (skb->len + 3) / 4;
> last = skb->len % 4;
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 3/5] batman-adv: use BIT_ULL for NL80211_STA_INFO_* attribute types
From: Sven Eckelmann @ 2018-06-20 11:34 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Omer Efrat
In-Reply-To: <1529491616-23222-1-git-send-email-omer.efrat-CtGflUZwD1xBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
On Mittwoch, 20. Juni 2018 13:46:56 CEST Omer Efrat wrote:
> - if (!(sinfo.filled & BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT)))
> + if (!(sinfo.filled &
> + BIT_ULL(NL80211_STA_INFO_EXPECTED_THROUGHPUT)))
> goto default_throughput;
Please fix the alignment:
* Found wrong alignment at net/batman-adv/bat_v_elp.c:118, was 27 but expected 23
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] net: macb: Fix ptp time adjustment for large negative delta
From: Harini Katakam @ 2018-06-20 11:34 UTC (permalink / raw)
To: nicolas.ferre, davem
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam
When delta passed to gem_ptp_adjtime is negative, the sign is
maintained in the ns_to_timespec64 conversion. Hence timespec_add
should be used directly. timespec_sub will just subtract the negative
value thus increasing the time difference.
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
---
drivers/net/ethernet/cadence/macb_ptp.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
index 2220c77..6788351 100644
--- a/drivers/net/ethernet/cadence/macb_ptp.c
+++ b/drivers/net/ethernet/cadence/macb_ptp.c
@@ -170,10 +170,7 @@ static int gem_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
if (delta > TSU_NSEC_MAX_VAL) {
gem_tsu_get_time(&bp->ptp_clock_info, &now);
- if (sign)
- now = timespec64_sub(now, then);
- else
- now = timespec64_add(now, then);
+ now = timespec64_add(now, then);
gem_tsu_set_time(&bp->ptp_clock_info,
(const struct timespec64 *)&now);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 net-next] net:sched: add action inheritdsfield to skbedit
From: Jamal Hadi Salim @ 2018-06-20 11:53 UTC (permalink / raw)
To: Michel Machado, Fu, Qiaobin, davem@davemloft.net
Cc: netdev@vger.kernel.org, Marcelo Ricardo Leitner,
xiyou.wangcong@gmail.com
In-Reply-To: <785f294c-080a-bfb4-5c7f-3ab48056649f@digirati.com.br>
On 19/06/18 08:39 AM, Michel Machado wrote:
> Notice that, different from skbmod, there's no field parm->flags in
> skbedit. Skbedit infers the flags in d->flags from the presence of the
> parameters of each of its actions. But SKBEDIT_F_INHERITDSFIELD has no
> parameter and adding field parm->flags breaks backward compatibility
> with user space as pointed out by Marcelo Ricardo Leitner. Our solution
> was to add TCA_SKBEDIT_FLAGS, so SKBEDIT_F_INHERITDSFIELD and future
> flag-only actions can be added.
Ok, that makes sense - thanks. I am not so sure about using
64 bits (32 bits would have been fine to match the size of
the kernel flags), but other than that LGTM.
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [PATCH] r8169: Fix netpoll oops
From: Ville Syrjala @ 2018-06-20 12:01 UTC (permalink / raw)
To: netdev
Cc: Realtek linux nic maintainers, Heiner Kallweit, David S . Miller,
Ville Syrjälä
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Pass the correct thing to rtl8169_interrupt() from netpoll.
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
Cc: netdev@vger.kernel.org
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Fixes: ebcd5daa7ffd ("r8169: change interrupt handler argument type")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/net/ethernet/realtek/r8169.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 75dfac0248f4..f4cae2be0fda 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7148,7 +7148,7 @@ static void rtl8169_netpoll(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
- rtl8169_interrupt(pci_irq_vector(tp->pci_dev, 0), dev);
+ rtl8169_interrupt(pci_irq_vector(tp->pci_dev, 0), tp);
}
#endif
--
2.16.4
^ permalink raw reply related
* Re: [PATCH net 1/5] net sched actions: fix coding style in pedit action
From: Davide Caratti @ 2018-06-20 12:29 UTC (permalink / raw)
To: Roman Mashak, davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1529427368-17129-2-git-send-email-mrv@mojatatu.com>
On Tue, 2018-06-19 at 12:56 -0400, Roman Mashak wrote:
> Fix coding style issues in tc pedit action detected by the
> checkpatch script.
>
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
...
> ---
> @@ -316,16 +318,15 @@ static int tcf_pedit(struct sk_buff *skb, const struct tc_action *a,
> hoffset + tkey->at);
> goto bad;
> }
> - d = skb_header_pointer(skb, hoffset + tkey->at, 1,
> - &_d);
> + d = skb_header_pointer(skb, hoffset + tkey->at,
> + 1, &_d);
> if (!d)
> goto bad;
> offset += (*d & tkey->offmask) >> tkey->shift;
> }
hello Roman,
nit: while we are here, what about changing the declaration of _d and *d
to u8, so that the bitwise operation is done on unsigned?
BTW: the patch (and the series) looks ok, but I guess it will better
target net-next when the branch reopens
thanks!
--
davide
^ permalink raw reply
* Re: [PATCH] ceph: use ktime_get_real_seconds()
From: Ilya Dryomov @ 2018-06-20 12:33 UTC (permalink / raw)
To: allen.lkml; +Cc: netdev, David S. Miller, linux-kernel, Ceph Development, y2038
In-Reply-To: <1529488801-22093-1-git-send-email-allen.lkml@gmail.com>
On Wed, Jun 20, 2018 at 12:00 PM Allen Pais <allen.lkml@gmail.com> wrote:
>
> Use ktime_get_real_seconds() as get_seconds() is deprecated.
>
> Signed-off-by: Allen Pais <allen.lkml@gmail.com>
> ---
> net/ceph/auth_x.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/ceph/auth_x.c b/net/ceph/auth_x.c
> index 2f4a1ba..99561c2 100644
> --- a/net/ceph/auth_x.c
> +++ b/net/ceph/auth_x.c
> @@ -154,7 +154,7 @@ static int process_one_ticket(struct ceph_auth_client *ac,
> void **ptp;
> struct ceph_crypto_key new_session_key = { 0 };
> struct ceph_buffer *new_ticket_blob;
> - unsigned long new_expires, new_renew_after;
> + u32 new_expires, new_renew_after;
> u64 new_secret_id;
> int ret;
>
> @@ -191,9 +191,9 @@ static int process_one_ticket(struct ceph_auth_client *ac,
>
> ceph_decode_timespec(&validity, dp);
> dp += sizeof(struct ceph_timespec);
> - new_expires = get_seconds() + validity.tv_sec;
> + new_expires = (u32)ktime_get_real_seconds() + validity.tv_sec;
Why the change to u32 and this cast? If the type has to change,
wouldn't time64_t make more sense? ktime_get_real_seconds() returns
time64_t, after all.
Thanks,
Ilya
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-06-20 12:35 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix crash on bpf_prog_load() errors, from Daniel Borkmann.
2) Fix ATM VCC memory accounting, from David Woodhouse.
3) fib6_info objects need RCU freeing, from Eric Dumazet.
4) Fix SO_BINDTODEVICE handling for TCP sockets, from David Ahern.
5) Fix clobbered error code in enic_open() failure path, from
Govindarajulu Varadarajan.
6) Propagate dev_get_valid_name() error returns properly, from
Li RongQing.
7) Fix suspend/resume in davinci_emac driver, from Bartosz
Golaszewski.
8) Various act_ife fixes (recursive locking, IDR leaks, etc.)
from Davide Caratti.
9) Fix buggy checksum handling in sungem driver, from Eric
Dumazet.
Please pull, thanks a lot!
The following changes since commit 35773c93817c5f2df264d013978e7551056a063a:
Merge branch 'afs-proc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2018-06-16 16:32:04 +0900)
are available in the Git repository at:
gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 9887cba19978a5f288100ef90a37684cc8d5e0a6:
ip: limit use of gso_size to udp (2018-06-20 14:41:04 +0900)
----------------------------------------------------------------
Alexei Starovoitov (1):
Merge branch 'bpf-fixes'
Anders Roxell (1):
selftests: bpf: config: add config fragments
Arnd Bergmann (1):
ptp: replace getnstimeofday64() with ktime_get_real_ts64()
Bartosz Golaszewski (1):
net: ethernet: fix suspend/resume in davinci_emac
Bhadram Varka (1):
stmmac: fix DMA channel hang in half-duplex mode
Björn Töpel (1):
xsk: re-add queue id check for XDP_SKB path
Daniel Borkmann (4):
Merge branch 'bpf-misc-fixes'
bpf: fix panic in prog load calls cleanup
bpf: reject any prog that failed read-only lock
bpf, xdp, i40e: fix i40e_build_skb skb reserve and truesize
Daniel Lezcano (1):
net/usb/drivers: Remove useless hrtimer_active check
David Ahern (1):
net/tcp: Fix socket lookups with SO_BINDTODEVICE
David S. Miller (4):
Merge git://git.kernel.org/.../bpf/bpf
bluetooth: hci_nokia: Don't include linux/unaligned/le_struct.h directly.
Merge branch 'qed-fixes'
Merge branch 'NCSI-silence-warning-messages'
David Woodhouse (1):
atm: Preserve value of skb->truesize when accounting to vcc
Davide Caratti (2):
net/sched: act_ife: fix recursive lock and idr leak
net/sched: act_ife: preserve the action control in case of error
Dinh Nguyen (1):
net: stmmac: socfpga: add additional ocp reset line for Stratix10
Eric Dumazet (2):
net/ipv6: respect rcu grace period before freeing fib6_info
net: sungem: fix rx checksum support
Govindarajulu Varadarajan (2):
enic: initialize enic->rfs_h.lock in enic_probe
enic: do not overwrite error code
Jakub Kicinski (2):
tools: bpftool: improve accuracy of load time
selftests/bpf: test offloads even with BPF programs present
Jian Wang (1):
bpf, selftest: check tunnel type more accurately
Joel Stanley (4):
net/ncsi: Silence debug messages
net/ncsi: Drop no more channels message
net/ncsi: Use netdev_dbg for debug messages
MAINTAINERS: Add Sam as the maintainer for NCSI
Konstantin Khlebnikov (1):
net_sched: blackhole: tell upper qdisc about dropped packets
Li RongQing (1):
net: propagate dev_get_valid_name return code
Liran Alon (1):
net: net_failover: fix typo in net_failover_slave_register()
Matteo Croce (2):
bpfilter: fix build error
bpfilter: ignore binary files
Stefan Agner (1):
net: hamradio: use eth_broadcast_addr
Sudarsana Reddy Kalluru (3):
qed: Fix possible memory leak in Rx error path handling.
qed: Add sanity check for SIMD fastpath handler.
qed: Do not advertise DCBX_LLD_MANAGED capability.
Toshiaki Makita (1):
xdp: Fix handling of devmap in generic XDP
Willem de Bruijn (1):
ip: limit use of gso_size to udp
William Tu (1):
bpf, selftests: delete xfrm tunnel when test exits.
Xin Long (1):
ipvlan: use ETH_MAX_MTU as max mtu
Yonghong Song (1):
tools/bpftool: fix a bug in bpftool perf
MAINTAINERS | 5 +++++
drivers/bluetooth/hci_nokia.c | 2 +-
drivers/net/ethernet/cisco/enic/enic_clsf.c | 3 +--
drivers/net/ethernet/cisco/enic/enic_main.c | 12 ++++++------
drivers/net/ethernet/faraday/ftgmac100.c | 4 ++--
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 7 +++----
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 11 ++++-------
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 11 +++++++++--
drivers/net/ethernet/qlogic/qed/qed_main.c | 12 ++++++++++--
drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 18 ++++++++++++++----
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++++++++++
drivers/net/ethernet/sun/sungem.c | 22 ++++++++++++----------
drivers/net/ethernet/ti/davinci_emac.c | 15 +++++++++++++--
drivers/net/hamradio/bpqether.c | 8 ++------
drivers/net/ipvlan/ipvlan_main.c | 1 +
drivers/net/net_failover.c | 2 +-
drivers/net/usb/cdc_ncm.c | 3 +--
drivers/ptp/ptp_chardev.c | 4 ++--
drivers/ptp/ptp_qoriq.c | 2 +-
include/linux/atmdev.h | 15 +++++++++++++++
include/linux/bpf.h | 12 ++++++++++++
include/linux/filter.h | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------
include/net/ip6_fib.h | 5 +++--
kernel/bpf/core.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
kernel/bpf/devmap.c | 14 ++++++++++++++
kernel/bpf/syscall.c | 12 +++---------
net/atm/br2684.c | 3 +--
net/atm/clip.c | 3 +--
net/atm/common.c | 3 +--
net/atm/lec.c | 3 +--
net/atm/mpc.c | 3 +--
net/atm/pppoatm.c | 3 +--
net/atm/raw.c | 4 ++--
net/bpfilter/.gitignore | 1 +
net/bpfilter/Makefile | 6 ++++--
net/core/dev.c | 4 ++--
net/core/filter.c | 21 ++++-----------------
net/ipv4/inet_hashtables.c | 4 ++--
net/ipv4/ip_output.c | 3 ++-
net/ipv6/inet6_hashtables.c | 4 ++--
net/ipv6/ip6_fib.c | 5 +++--
net/ipv6/ip6_output.c | 3 ++-
net/ncsi/ncsi-aen.c | 10 +++++-----
net/ncsi/ncsi-manage.c | 49 ++++++++++++++++++++++---------------------------
net/sched/act_ife.c | 12 +++++-------
net/sched/sch_blackhole.c | 2 +-
net/xdp/xsk.c | 3 +++
tools/bpf/bpftool/perf.c | 5 +++--
tools/bpf/bpftool/prog.c | 4 +++-
tools/testing/selftests/bpf/config | 10 ++++++++++
tools/testing/selftests/bpf/test_offload.py | 12 ++++++++++--
tools/testing/selftests/bpf/test_tunnel.sh | 26 ++++++++++++++------------
53 files changed, 371 insertions(+), 195 deletions(-)
create mode 100644 net/bpfilter/.gitignore
^ permalink raw reply
* Re: [PATCH] bpfilter: fix build error
From: Stefano Brivio @ 2018-06-20 12:39 UTC (permalink / raw)
To: Matteo Croce; +Cc: netdev, Alexei Starovoitov
In-Reply-To: <20180619151620.1912-1-mcroce@redhat.com>
On Tue, 19 Jun 2018 17:16:20 +0200
Matteo Croce <mcroce@redhat.com> wrote:
> bpfilter Makefile assumes that the system locale is en_US, and the
> parsing of objdump output fails.
> Set LC_ALL=C and, while at it, rewrite the objdump parsing so it spawns
> only 2 processes instead of 7.
>
> Fixes: d2ba09c17a064 ("net: add skeleton of bpfilter kernel module")
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
> ---
> net/bpfilter/Makefile | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> index e0bbe7583e58..dd86b022eff0 100644
> --- a/net/bpfilter/Makefile
> +++ b/net/bpfilter/Makefile
> @@ -21,8 +21,10 @@ endif
> # which bpfilter_kern.c passes further into umh blob loader at run-time
> quiet_cmd_copy_umh = GEN $@
> cmd_copy_umh = echo ':' > $(obj)/.bpfilter_umh.o.cmd; \
> - $(OBJCOPY) -I binary -O `$(OBJDUMP) -f $<|grep format|cut -d' ' -f8` \
> - -B `$(OBJDUMP) -f $<|grep architecture|cut -d, -f1|cut -d' ' -f2` \
> + $(OBJCOPY) -I binary \
> + `LC_ALL=C objdump -f net/bpfilter/bpfilter_umh \
Why do you use objdump instead of $(OBJDUMP) now? I guess this might
cause issues if you're cross-compiling.
--
Stefano
^ permalink raw reply
* Re: [PATCH v4 net-next] net:sched: add action inheritdsfield to skbedit
From: Michel Machado @ 2018-06-20 12:42 UTC (permalink / raw)
To: Jamal Hadi Salim, Fu, Qiaobin, davem@davemloft.net
Cc: netdev@vger.kernel.org, Marcelo Ricardo Leitner,
xiyou.wangcong@gmail.com
In-Reply-To: <e3b8ffa4-bad5-0e35-39e8-84836db7972e@mojatatu.com>
On 06/20/2018 07:53 AM, Jamal Hadi Salim wrote:
> On 19/06/18 08:39 AM, Michel Machado wrote:
>
>> Notice that, different from skbmod, there's no field parm->flags in
>> skbedit. Skbedit infers the flags in d->flags from the presence of the
>> parameters of each of its actions. But SKBEDIT_F_INHERITDSFIELD has no
>> parameter and adding field parm->flags breaks backward compatibility
>> with user space as pointed out by Marcelo Ricardo Leitner. Our
>> solution was to add TCA_SKBEDIT_FLAGS, so SKBEDIT_F_INHERITDSFIELD and
>> future flag-only actions can be added.
>
> Ok, that makes sense - thanks. I am not so sure about using
> 64 bits (32 bits would have been fine to match the size of
> the kernel flags), but other than that LGTM.
The choice for the u64 is meant to keep the interface between kernel
and user space the same for hopefully a longer time than it would be
with a u32. Changing from u32 to u64 in the kernel, when the need
arrives, won't impact applications. This interface choice was motivated
by the backward compatibility issue mentioned above.
Thank you for the review, Jamal.
[ ]'s
Michel Machado
^ permalink raw reply
* Re: [PATCH net] net: sungem: fix rx checksum support
From: Eric Dumazet @ 2018-06-20 12:49 UTC (permalink / raw)
To: Mathieu Malaterre, David S. Miller
Cc: Eric Dumazet, netdev, Meelis Roos, schwab, eric.dumazet
In-Reply-To: <CA+7wUswWV7FJ_n0Dd-p_2aK7m3xcUL0CJsokhCZH0J+scvJO3g@mail.gmail.com>
On 06/20/2018 04:22 AM, Mathieu Malaterre wrote:
> Thanks for the stable tag.
>
> IMHO the commit message should have also reference commit 7ce5a27f2ef8
> ("Revert "net: Handle CHECKSUM_COMPLETE more adequately in
> pskb_trim_rcsum().""). Which means that commit 88078d98d1bb ("net:
> pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends") should be ready
> for stable also, since it seems that the only driver responsible for
> the revert was sungem.
>
> my 2cts
>
I disagree.
commit 88078d98d1bb is a performance improvement, and not needed for stable.
We might also discover another buggy driver later.
Thanks.
^ permalink raw reply
* Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver
From: Ivan Vecera @ 2018-06-20 12:53 UTC (permalink / raw)
To: Jiri Pirko, Grygorii Strashko
Cc: Ilias Apalodimas, netdev, ivan.khoronzhuk, nsekhar, andrew,
f.fainelli, francois.ozog, yogeshs, spatton, Jose.Abreu
In-Reply-To: <20180620070808.GA2119@nanopsycho>
On 20.6.2018 09:08, Jiri Pirko wrote:
> Tue, Jun 19, 2018 at 01:19:00AM CEST, grygorii.strashko@ti.com wrote:
>>
>>
>> On 06/14/2018 06:43 AM, Ilias Apalodimas wrote:
>>> On Thu, Jun 14, 2018 at 01:39:58PM +0200, Jiri Pirko wrote:
>>>> Thu, Jun 14, 2018 at 01:34:04PM CEST, ilias.apalodimas@linaro.org wrote:
>>>>> On Thu, Jun 14, 2018 at 01:30:28PM +0200, Jiri Pirko wrote:
>>>>>> Thu, Jun 14, 2018 at 01:11:30PM CEST, ilias.apalodimas@linaro.org wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> @@ -2711,6 +2789,10 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
>>>>>>> if (of_property_read_bool(node, "dual_emac"))
>>>>>>> data->switch_mode = CPSW_DUAL_EMAC;
>>>>>>>
>>>>>>> + /* switchdev overrides DTS */
>>>>>>> + if (IS_ENABLED(CONFIG_TI_CPSW_SWITCHDEV))
>>>>>>> + data->switch_mode = CPSW_SWITCHDEV;
>>>>>>
>>>>>> So you force CPSW_SWITCHDEV mode if the CONFIG_TI_CPSW_SWITCHDEV is
>>>>>> enabled. That does not sound right. I think that user should tell what
>>>>>> mode does he want regardless what the kernel config is.
>>>>> We discussed this during the V1 of the RFC. Yes it doesn't seem good, but the
>>>>> device currently configures the modes using DTS (which is not correct). I choose
>>>>> the .config due to that. I can't think of anything better, but i am open to
>>>>> suggestions
>>>>
>>>> Agreed that DTS does fit as well. I think that this might be a job for
>>>> devlink parameters (patchset is going to be sent upstream next week).
>>>> You do have 1 bus address for the whole device (both ports), right?
>>>>
>>> Yes devlink sounds reasonable. I thyink there's only one bus for it, but then
>>> again i am far from an expert on the hardware interrnals. Grygorii can correct
>>> me if i am wrong.
>>
>> Devlink and NFS boot are not compatible as per my understanding, so ..
>
> ? Why do you say so?
Why aren't they compatible?? You can have devlink binary in initramfs and
configure the ASIC and ports via devlink batch file - prior mounting NFS root.
>>
>> Again, current driver, as is, supports NFS boot in all modes
>> (how good is the cur driver is question which out of scope of this discussion).
>>
>> And we discussed this in RFC v1 - driver mode selection will be changed
>> if we will proceed and it will be new driver for proper switch support.
>>
>> Not sure about about Devlink (need to study it and we never got any requests from end
>> users for this as I know), and I'd like to note (again) that this is embedded
>> (industrial/automotive etc), so everything preferred to be simple, fast and
>> preferably configured statically (in most of the cases end users what boot time
>> configuration).
>
> You need to study it indeed.
>
>>
>> --
>> regards,
>> -grygorii
^ permalink raw reply
* Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver
From: Ivan Vecera @ 2018-06-20 12:56 UTC (permalink / raw)
To: Ilias Apalodimas, Andrew Lunn
Cc: netdev, grygorii.strashko, ivan.khoronzhuk, nsekhar, jiri,
f.fainelli, francois.ozog, yogeshs, spatton, Jose.Abreu
In-Reply-To: <20180618201940.GA5890@apalos>
On 18.6.2018 22:19, Ilias Apalodimas wrote:
> Jiri proposed using devlink, which makes sense, but i am not sure it's
> applicable on this patchset. This will change the driver completely and will
> totally break backwards compatibility.
Another good reason for a new driver.
I.
^ permalink raw reply
* Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver
From: Ilias Apalodimas @ 2018-06-20 12:59 UTC (permalink / raw)
To: Ivan Vecera
Cc: Jiri Pirko, Grygorii Strashko, netdev, ivan.khoronzhuk, nsekhar,
andrew, f.fainelli, francois.ozog, yogeshs, spatton, Jose.Abreu
In-Reply-To: <77627ca3-3e24-ea0b-7ba6-55f1f2a1114e@redhat.com>
On Wed, Jun 20, 2018 at 02:53:47PM +0200, Ivan Vecera wrote:
> On 20.6.2018 09:08, Jiri Pirko wrote:
> > Tue, Jun 19, 2018 at 01:19:00AM CEST, grygorii.strashko@ti.com wrote:
> >>
> >>
> >> On 06/14/2018 06:43 AM, Ilias Apalodimas wrote:
> >>> On Thu, Jun 14, 2018 at 01:39:58PM +0200, Jiri Pirko wrote:
> >>>> Thu, Jun 14, 2018 at 01:34:04PM CEST, ilias.apalodimas@linaro.org wrote:
> >>>>> On Thu, Jun 14, 2018 at 01:30:28PM +0200, Jiri Pirko wrote:
> >>>>>> Thu, Jun 14, 2018 at 01:11:30PM CEST, ilias.apalodimas@linaro.org wrote:
> >>>>>>
> >>>>>> [...]
> >>>>>>
> >>>>>>> @@ -2711,6 +2789,10 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
> >>>>>>> if (of_property_read_bool(node, "dual_emac"))
> >>>>>>> data->switch_mode = CPSW_DUAL_EMAC;
> >>>>>>>
> >>>>>>> + /* switchdev overrides DTS */
> >>>>>>> + if (IS_ENABLED(CONFIG_TI_CPSW_SWITCHDEV))
> >>>>>>> + data->switch_mode = CPSW_SWITCHDEV;
> >>>>>>
> >>>>>> So you force CPSW_SWITCHDEV mode if the CONFIG_TI_CPSW_SWITCHDEV is
> >>>>>> enabled. That does not sound right. I think that user should tell what
> >>>>>> mode does he want regardless what the kernel config is.
> >>>>> We discussed this during the V1 of the RFC. Yes it doesn't seem good, but the
> >>>>> device currently configures the modes using DTS (which is not correct). I choose
> >>>>> the .config due to that. I can't think of anything better, but i am open to
> >>>>> suggestions
> >>>>
> >>>> Agreed that DTS does fit as well. I think that this might be a job for
> >>>> devlink parameters (patchset is going to be sent upstream next week).
> >>>> You do have 1 bus address for the whole device (both ports), right?
> >>>>
> >>> Yes devlink sounds reasonable. I thyink there's only one bus for it, but then
> >>> again i am far from an expert on the hardware interrnals. Grygorii can correct
> >>> me if i am wrong.
> >>
> >> Devlink and NFS boot are not compatible as per my understanding, so ..
> >
> > ? Why do you say so?
>
> Why aren't they compatible?? You can have devlink binary in initramfs and
> configure the ASIC and ports via devlink batch file - prior mounting NFS root.
This is doable but, are we taking into consideration device reconfiguration
(which was the reason for creating the minimal filesystem) or are we just
talking about device booting/initial config?
>
> >>
> >> Again, current driver, as is, supports NFS boot in all modes
> >> (how good is the cur driver is question which out of scope of this discussion).
> >>
> >> And we discussed this in RFC v1 - driver mode selection will be changed
> >> if we will proceed and it will be new driver for proper switch support.
> >>
> >> Not sure about about Devlink (need to study it and we never got any requests from end
> >> users for this as I know), and I'd like to note (again) that this is embedded
> >> (industrial/automotive etc), so everything preferred to be simple, fast and
> >> preferably configured statically (in most of the cases end users what boot time
> >> configuration).
> >
> > You need to study it indeed.
> >
> >>
> >> --
> >> regards,
> >> -grygorii
>
Regards
Ilias
^ permalink raw reply
* [PATCH] strparser: Don't schedule in workqueue in paused state
From: Vakul Garg @ 2018-06-20 13:04 UTC (permalink / raw)
To: davem
Cc: doronrk, tom, john.fastabend, davejwatson, netdev, ebiggers,
linux-kernel, Vakul Garg
In function strp_data_ready(), it is useless to call queue_work if
the state of strparser is already paused. The state checking should
be done before calling queue_work. The change reduces the context
switches and improves the ktls-rx throughput by approx 20% (measured
on cortex-a53 based platform).
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
net/strparser/strparser.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/strparser/strparser.c b/net/strparser/strparser.c
index 1a9695183599..373836615c57 100644
--- a/net/strparser/strparser.c
+++ b/net/strparser/strparser.c
@@ -392,7 +392,7 @@ static int strp_read_sock(struct strparser *strp)
/* Lower sock lock held */
void strp_data_ready(struct strparser *strp)
{
- if (unlikely(strp->stopped))
+ if (unlikely(strp->stopped) || strp->paused)
return;
/* This check is needed to synchronize with do_strp_work.
@@ -407,9 +407,6 @@ void strp_data_ready(struct strparser *strp)
return;
}
- if (strp->paused)
- return;
-
if (strp->need_bytes) {
if (strp_peek_len(strp) < strp->need_bytes)
return;
--
2.13.6
^ permalink raw reply related
* Re: [PATCH V2] brcmfmac: stop watchdog before detach and free everything
From: Andy Shevchenko @ 2018-06-20 13:15 UTC (permalink / raw)
To: Michael Trimarchi
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, David S. Miller, Pieter-Paul Giesberts,
Ian Molton, open list:TI WILINK WIRELES...,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
brcm80211-dev-list, netdev, Linux Kernel Mailing List
In-Reply-To: <20180530090633.GA15390@panicking>
On Wed, May 30, 2018 at 12:06 PM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> Using built-in in kernel image without a firmware in filesystem
> or in the kernel image can lead to a kernel NULL pointer deference.
> Watchdog need to be stopped in brcmf_sdio_remove
>
> The system is going down NOW!
> [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
> Sent SIGTERM to all processes
> [ 1348.121412] Mem abort info:
> [ 1348.126962] ESR = 0x96000004
> [ 1348.130023] Exception class = DABT (current EL), IL = 32 bits
> [ 1348.135948] SET = 0, FnV = 0
> [ 1348.138997] EA = 0, S1PTW = 0
> [ 1348.142154] Data abort info:
> [ 1348.145045] ISV = 0, ISS = 0x00000004
> [ 1348.148884] CM = 0, WnR = 0
> [ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
> [ 1348.158475] [00000000000002f8] pgd=0000000000000000
> [ 1348.163364] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [ 1348.168927] Modules linked in: ipv6
> [ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted 4.17.0-rc5-next-20180517 #18
> [ 1348.180757] Hardware name: Amarula A64-Relic (DT)
> [ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO)
> [ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20
> [ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290
> [ 1348.200253] sp : ffff00000b85be30
> [ 1348.203561] x29: ffff00000b85be30 x28: 0000000000000000
> [ 1348.208868] x27: ffff00000b6cb918 x26: ffff80003b990638
> [ 1348.214176] x25: ffff0000087b1a20 x24: ffff80003b94f800
> [ 1348.219483] x23: ffff000008e620c8 x22: ffff000008f0b660
> [ 1348.224790] x21: ffff000008c6a858 x20: 00000000fffffe00
> [ 1348.230097] x19: ffff80003b94f800 x18: 0000000000000001
> [ 1348.235404] x17: 0000ffffab2e8a74 x16: ffff0000080d7de8
> [ 1348.240711] x15: 0000000000000000 x14: 0000000000000400
> [ 1348.246018] x13: 0000000000000400 x12: 0000000000000001
> [ 1348.251324] x11: 00000000000002c4 x10: 0000000000000a10
> [ 1348.256631] x9 : ffff00000b85bc40 x8 : ffff80003be11870
> [ 1348.261937] x7 : ffff80003dfc7308 x6 : 000000078ff08b55
> [ 1348.267243] x5 : 00000139e1058400 x4 : 0000000000000000
> [ 1348.272550] x3 : dead000000000100 x2 : 958f2788d6618100
> [ 1348.277856] x1 : 00000000fffffe00 x0 : 0000000000000000
>
It was a 100% (or so) reproducible on Intel Edison with vanilla kernel
and linux-firmware package, while calibration file (*.txt) is not in
distribution.
The system is going down NOW!
Sent SIGTERM to all processes
[ 118.695900] PGD 800000003bc3f067 P4D 800000003bc3f067 PUD 3bc5b067 PMD 0
[ 118.695935] Oops: 0002 [#1] SMP PTI
[ 118.711905] CPU: 1 PID: 1255 Comm: brcmf_wdog/mmc2 Not tainted
4.18.0-rc1-next-20180618+ #59
[ 118.720354] Hardware name: Intel Corporation Merrifield/BODEGA BAY,
BIOS 542 2015.01.21:18.19.48
[ 118.729181] RIP: 0010:brcmf_sdiod_freezer_count+0x7/0x10 [brcmfmac]
After this patch applied problem was gone
Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
P.S. Sorry it took a bit longer.
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 412a05b..061f69d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -4294,6 +4294,13 @@ void brcmf_sdio_remove(struct brcmf_sdio *bus)
> brcmf_dbg(TRACE, "Enter\n");
>
> if (bus) {
> + /* Stop watchdog task */
> + if (bus->watchdog_tsk) {
> + send_sig(SIGTERM, bus->watchdog_tsk, 1);
> + kthread_stop(bus->watchdog_tsk);
> + bus->watchdog_tsk = NULL;
> + }
> +
> /* De-register interrupt handler */
> brcmf_sdiod_intr_unregister(bus->sdiodev);
>
> --
> 2.7.4
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net 1/5] net sched actions: fix coding style in pedit action
From: Roman Mashak @ 2018-06-20 13:25 UTC (permalink / raw)
To: Davide Caratti; +Cc: davem, netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <fccb4f8c0e3070c289c4c110786ac7071f4e61cf.camel@redhat.com>
Davide Caratti <dcaratti@redhat.com> writes:
> On Tue, 2018-06-19 at 12:56 -0400, Roman Mashak wrote:
>> Fix coding style issues in tc pedit action detected by the
>> checkpatch script.
>>
>> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
> ...
>
>> ---
>> @@ -316,16 +318,15 @@ static int tcf_pedit(struct sk_buff *skb, const struct tc_action *a,
>> hoffset + tkey->at);
>> goto bad;
>> }
>> - d = skb_header_pointer(skb, hoffset + tkey->at, 1,
>> - &_d);
>> + d = skb_header_pointer(skb, hoffset + tkey->at,
>> + 1, &_d);
>> if (!d)
>> goto bad;
>> offset += (*d & tkey->offmask) >> tkey->shift;
>> }
>
> hello Roman,
>
> nit: while we are here, what about changing the declaration of _d and *d
> to u8, so that the bitwise operation is done on unsigned?
Yes makes sense, I will send v2 in net-next once opened. Thanks Davide.
> BTW: the patch (and the series) looks ok, but I guess it will better
> target net-next when the branch reopens
^ permalink raw reply
* [PATCH] net: vhost: improve performance when enable busyloop
From: Tonghao Zhang @ 2018-06-20 13:28 UTC (permalink / raw)
To: jasowang; +Cc: netdev, Tonghao Zhang, virtualization
This patch improves the guest receive performance from
host. On the handle_tx side, we poll the sock receive
queue at the same time. handle_rx do that in the same way.
we set the poll-us=100 us and use the iperf3 to test
its throughput. The iperf3 command is shown as below.
iperf3 -s -D
iperf3 -c 192.168.1.100 -i 1 -P 10 -t 10 -M 1400 --bandwidth 100000M
* With the patch: 21.1 Gbits/sec
* Without the patch: 12.7 Gbits/sec
Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
---
drivers/vhost/net.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index e7cf7d2..9364ede 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -429,22 +429,43 @@ static int vhost_net_enable_vq(struct vhost_net *n,
return vhost_poll_start(poll, sock->file);
}
+static int sk_has_rx_data(struct sock *sk);
+
static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
struct vhost_virtqueue *vq,
struct iovec iov[], unsigned int iov_size,
unsigned int *out_num, unsigned int *in_num)
{
unsigned long uninitialized_var(endtime);
+ struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_RX];
+ struct vhost_virtqueue *rvq = &nvq->vq;
+ struct socket *sock = rvq->private_data;
+
int r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
out_num, in_num, NULL, NULL);
if (r == vq->num && vq->busyloop_timeout) {
+ mutex_lock_nested(&rvq->mutex, 1);
+
+ vhost_disable_notify(&net->dev, rvq);
+
preempt_disable();
endtime = busy_clock() + vq->busyloop_timeout;
while (vhost_can_busy_poll(vq->dev, endtime) &&
+ !(sock && sk_has_rx_data(sock->sk)) &&
vhost_vq_avail_empty(vq->dev, vq))
cpu_relax();
preempt_enable();
+
+ if (sock && sk_has_rx_data(sock->sk))
+ vhost_poll_queue(&rvq->poll);
+ else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
+ vhost_disable_notify(&net->dev, rvq);
+ vhost_poll_queue(&rvq->poll);
+ }
+
+ mutex_unlock(&rvq->mutex);
+
r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
out_num, in_num, NULL, NULL);
}
--
1.8.3.1
^ permalink raw reply related
* Re: Route fallback issue
From: David Ahern @ 2018-06-20 13:48 UTC (permalink / raw)
To: Akshat Kakkar, netdev; +Cc: cronolog+lartc, lartc, Erik Auerswald
In-Reply-To: <CAA5aLPiPBTEp4eMs9T6xA3dkOPry3H=oD2svo3Ybon3dEgh3gA@mail.gmail.com>
On 6/20/18 2:26 AM, Akshat Kakkar wrote:
> Hi netdev community,
>
> I have 2 interfaces
> eno1 : 192.168.1.10/24
> eno2 : 192.168.2.10/24
>
> I added routes as
> 172.16.0.0/12 via 192.168.1.254 metric 1
> 172.16.0.0/12 via 192.168.2.254 metric 2
>
> My intention : All traffic to 172.16.0.0/12 should go thru eno1. If
> 192.168.1.254 is not reachable (no arp entry or link down), then it
> should fall back to eno2.
See the ignore_routes_with_linkdown and fib_multipath_use_neigh sysctl
settings.
> On Wed, Jun 20, 2018 at 1:49 PM, Erik Auerswald
> <auerswal@unix-ag.uni-kl.de> wrote:
>> Hi,
>>
>> I have usually used the "replace" keyword of iproute2 for similar
>> purposes. I would suggest a script as well, run via cron unless 1 minute
>> failover times are not acceptable. The logic could be as follows:
>>
>> if ping -c1 $PRIMARY_NH >/dev/null 2>&1; then
>> ip route replace $PREFIX via $PRIMARY_NH
>> elif ping -c1 $SECONDARY_NH >/dev/null 2>&1; then
>> ip route replace $PREFIX via $SECONDARY_NH
>> else
>> ip route del $PREFIX
>> fi
>>
>> Alternatively, one could look into a routing daemon that supports static
>> routing (Zebra/Quagga/FRRouting, BIRD, ...) and check if that supports
>> some form of next-hop tracking or at least removes static routes with
>> unreachable next-hops as one would expect from experience with dedicated
>> networking devices.
A feature is in the works to have fallback nexthops.
>>
>> IMHO static route handling as done by the Linux kernel does not seem
>> useful for networking devices. I have even had bad experiences with
>> Arista switches and static routing because they relied too much on the
>> Linux kernel (probably still do).
Useful how? what did not work as expected?
Do not confuse Arista's NOS with Linux's capabilities or any NOS truly
based on Linux and using a modern kernel. A lot of work has been put
into bringing Linux up to par with NOS features. If something is not
working, demonstrate the problem on the latest kernel and inquire if
someone is working on it.
^ permalink raw reply
* [PATCH v1 1/1] VSOCK: fix loopback on big-endian systems
From: Claudio Imbrenda @ 2018-06-20 13:51 UTC (permalink / raw)
To: stefanha
Cc: davem, jhansen, cavery, borntraeger, fiuczy, linux-kernel, netdev
The dst_cid and src_cid are 64 bits, therefore 64 bit accessors should be
used, and in fact in virtio_transport_common.c only 64 bit accessors are
used. Using 32 bit accessors for 64 bit values breaks big endian systems.
This patch fixes a wrong use of le32_to_cpu in virtio_transport_send_pkt.
Fixes: b9116823189e85ccf384 ("VSOCK: add loopback to virtio_transport")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
---
net/vmw_vsock/virtio_transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 8e03bd3..5d3cce9 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -201,7 +201,7 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt)
return -ENODEV;
}
- if (le32_to_cpu(pkt->hdr.dst_cid) == vsock->guest_cid)
+ if (le64_to_cpu(pkt->hdr.dst_cid) == vsock->guest_cid)
return virtio_transport_send_pkt_loopback(vsock, pkt);
if (pkt->reply)
--
2.7.4
^ permalink raw reply related
* Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver
From: Ivan Vecera @ 2018-06-20 13:54 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Jiri Pirko, Grygorii Strashko, netdev, ivan.khoronzhuk, nsekhar,
andrew, f.fainelli, francois.ozog, yogeshs, spatton, Jose.Abreu
In-Reply-To: <20180620125929.GA8582@apalos>
On 20.6.2018 14:59, Ilias Apalodimas wrote:
> On Wed, Jun 20, 2018 at 02:53:47PM +0200, Ivan Vecera wrote:
>> On 20.6.2018 09:08, Jiri Pirko wrote:
>>> Tue, Jun 19, 2018 at 01:19:00AM CEST, grygorii.strashko@ti.com wrote:
>>>>
>>>>
>>>> On 06/14/2018 06:43 AM, Ilias Apalodimas wrote:
>>>>> On Thu, Jun 14, 2018 at 01:39:58PM +0200, Jiri Pirko wrote:
>>>>>> Thu, Jun 14, 2018 at 01:34:04PM CEST, ilias.apalodimas@linaro.org wrote:
>>>>>>> On Thu, Jun 14, 2018 at 01:30:28PM +0200, Jiri Pirko wrote:
>>>>>>>> Thu, Jun 14, 2018 at 01:11:30PM CEST, ilias.apalodimas@linaro.org wrote:
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> @@ -2711,6 +2789,10 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
>>>>>>>>> if (of_property_read_bool(node, "dual_emac"))
>>>>>>>>> data->switch_mode = CPSW_DUAL_EMAC;
>>>>>>>>>
>>>>>>>>> + /* switchdev overrides DTS */
>>>>>>>>> + if (IS_ENABLED(CONFIG_TI_CPSW_SWITCHDEV))
>>>>>>>>> + data->switch_mode = CPSW_SWITCHDEV;
>>>>>>>>
>>>>>>>> So you force CPSW_SWITCHDEV mode if the CONFIG_TI_CPSW_SWITCHDEV is
>>>>>>>> enabled. That does not sound right. I think that user should tell what
>>>>>>>> mode does he want regardless what the kernel config is.
>>>>>>> We discussed this during the V1 of the RFC. Yes it doesn't seem good, but the
>>>>>>> device currently configures the modes using DTS (which is not correct). I choose
>>>>>>> the .config due to that. I can't think of anything better, but i am open to
>>>>>>> suggestions
>>>>>>
>>>>>> Agreed that DTS does fit as well. I think that this might be a job for
>>>>>> devlink parameters (patchset is going to be sent upstream next week).
>>>>>> You do have 1 bus address for the whole device (both ports), right?
>>>>>>
>>>>> Yes devlink sounds reasonable. I thyink there's only one bus for it, but then
>>>>> again i am far from an expert on the hardware interrnals. Grygorii can correct
>>>>> me if i am wrong.
>>>>
>>>> Devlink and NFS boot are not compatible as per my understanding, so ..
>>>
>>> ? Why do you say so?
>>
>> Why aren't they compatible?? You can have devlink binary in initramfs and
>> configure the ASIC and ports via devlink batch file - prior mounting NFS root.
> This is doable but, are we taking into consideration device reconfiguration
> (which was the reason for creating the minimal filesystem) or are we just
> talking about device booting/initial config?
Devlink calls should be placed in setup.sh
I.
^ permalink raw reply
* Re: [PATCH] net: macb: Fix ptp time adjustment for large negative delta
From: Nicolas Ferre @ 2018-06-20 14:04 UTC (permalink / raw)
To: Harini Katakam, davem
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
Claudiu Beznea - M18063
In-Reply-To: <1529494460-4689-1-git-send-email-harini.katakam@xilinx.com>
On 20/06/2018 at 13:34, Harini Katakam wrote:
> When delta passed to gem_ptp_adjtime is negative, the sign is
> maintained in the ns_to_timespec64 conversion. Hence timespec_add
> should be used directly. timespec_sub will just subtract the negative
> value thus increasing the time difference.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Makes sense:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> drivers/net/ethernet/cadence/macb_ptp.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
> index 2220c77..6788351 100644
> --- a/drivers/net/ethernet/cadence/macb_ptp.c
> +++ b/drivers/net/ethernet/cadence/macb_ptp.c
> @@ -170,10 +170,7 @@ static int gem_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
>
> if (delta > TSU_NSEC_MAX_VAL) {
> gem_tsu_get_time(&bp->ptp_clock_info, &now);
> - if (sign)
> - now = timespec64_sub(now, then);
> - else
> - now = timespec64_add(now, then);
> + now = timespec64_add(now, then);
>
> gem_tsu_set_time(&bp->ptp_clock_info,
> (const struct timespec64 *)&now);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] bpfilter: fix user mode helper cross compilation
From: Matteo Croce @ 2018-06-20 14:04 UTC (permalink / raw)
To: netdev
Use $(OBJDUMP) instead of literal 'objdump' to avoid
using host toolchain when cross compiling.
Fixes: 421780fd4983 ("bpfilter: fix build error")
Signed-off-by: Matteo Croce <mcroce@redhat.com>
---
net/bpfilter/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
index dd86b022eff0..051dc18b8ccb 100644
--- a/net/bpfilter/Makefile
+++ b/net/bpfilter/Makefile
@@ -22,7 +22,7 @@ endif
quiet_cmd_copy_umh = GEN $@
cmd_copy_umh = echo ':' > $(obj)/.bpfilter_umh.o.cmd; \
$(OBJCOPY) -I binary \
- `LC_ALL=C objdump -f net/bpfilter/bpfilter_umh \
+ `LC_ALL=C $(OBJDUMP) -f net/bpfilter/bpfilter_umh \
|awk -F' |,' '/file format/{print "-O",$$NF} \
/^architecture:/{print "-B",$$2}'` \
--rename-section .data=.init.rodata $< $@
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] bpfilter: fix build error
From: Matteo Croce @ 2018-06-20 14:07 UTC (permalink / raw)
To: Stefano Brivio; +Cc: netdev, Alexei Starovoitov
In-Reply-To: <20180620143926.50720aec@elisabeth>
On Wed, Jun 20, 2018 at 12:39 PM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> On Tue, 19 Jun 2018 17:16:20 +0200
> Matteo Croce <mcroce@redhat.com> wrote:
>
> > bpfilter Makefile assumes that the system locale is en_US, and the
> > parsing of objdump output fails.
> > Set LC_ALL=C and, while at it, rewrite the objdump parsing so it spawns
> > only 2 processes instead of 7.
> >
> > Fixes: d2ba09c17a064 ("net: add skeleton of bpfilter kernel module")
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
> > ---
> > net/bpfilter/Makefile | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> > index e0bbe7583e58..dd86b022eff0 100644
> > --- a/net/bpfilter/Makefile
> > +++ b/net/bpfilter/Makefile
> > @@ -21,8 +21,10 @@ endif
> > # which bpfilter_kern.c passes further into umh blob loader at run-time
> > quiet_cmd_copy_umh = GEN $@
> > cmd_copy_umh = echo ':' > $(obj)/.bpfilter_umh.o.cmd; \
> > - $(OBJCOPY) -I binary -O `$(OBJDUMP) -f $<|grep format|cut -d' ' -f8` \
> > - -B `$(OBJDUMP) -f $<|grep architecture|cut -d, -f1|cut -d' ' -f2` \
> > + $(OBJCOPY) -I binary \
> > + `LC_ALL=C objdump -f net/bpfilter/bpfilter_umh \
>
> Why do you use objdump instead of $(OBJDUMP) now? I guess this might
> cause issues if you're cross-compiling.
>
> --
> Stefano
Right, I've sent a proper fix.
Thanks,
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Michael S. Tsirkin @ 2018-06-20 14:11 UTC (permalink / raw)
To: Cornelia Huck
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, konrad.wilk,
Jakub Kicinski, Samudrala, Sridhar, qemu-devel, virtualization,
Siwei Liu, Venu Busireddy, Netdev, boris.ostrovsky, aaron.f.brown,
Joao Martins
In-Reply-To: <20180620115359.1a3bf6fb.cohuck@redhat.com>
On Wed, Jun 20, 2018 at 11:53:59AM +0200, Cornelia Huck wrote:
> On Tue, 19 Jun 2018 23:32:06 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Tue, Jun 19, 2018 at 12:54:53PM +0200, Cornelia Huck wrote:
> > > Sorry about dragging mainframes into this, but this will only work for
> > > homogenous device coupling, not for heterogenous. Consider my vfio-pci
> > > + virtio-net-ccw example again: The guest cannot find out that the two
> > > belong together by checking some group ID, it has to either use the MAC
> > > or some needs-to-be-architectured property.
> > >
> > > Alternatively, we could propose that mechanism as pci-only, which means
> > > we can rely on mechanisms that won't necessarily work on non-pci
> > > transports. (FWIW, I don't see a use case for using vfio-ccw to pass
> > > through a network card anytime in the near future, due to the nature of
> > > network cards currently in use on s390.)
> >
> > That's what it boils down to, yes. If there's need to have this for
> > non-pci devices, then we should put it in config space.
> > Cornelia, what do you think?
> >
>
> I think the only really useful config on s390 is the vfio-pci network
> card coupled with a virtio-net-ccw device: Using an s390 network card
> via vfio-ccw is out due to the nature of the s390 network cards, and
> virtio-ccw is the default transport (virtio-pci is not supported on any
> enterprise distro AFAIK).
>
> For this, having a uuid in the config space could work (vfio-pci
> devices have a config space by virtue of being pci devices, and
> virtio-net-ccw devices have a config space by virtue of being virtio
> devices -- ccw devices usually don't have that concept).
OK so this calls for adding such a field generally (it's
device agnostic right now).
How would you suggest doing that?
--
MST
^ 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