Skip to content

L
linux
Switch branch/tag
  1. 05 Aug, 2019 8 commits
    • Jesper Dangaard Brouer's avatar
      net: fix bpf_xdp_adjust_head regression for generic-XDP · 065af355
      Jesper Dangaard Brouer authored 
      When generic-XDP was moved to a later processing step by commit
458bf2f2 ("net: core: support XDP generic on stacked devices.")
a regression was introduced when using bpf_xdp_adjust_head.

The issue is that after this commit the skb->network_header is now
changed prior to calling generic XDP and not after. Thus, if the header
is changed by XDP (via bpf_xdp_adjust_head), then skb->network_header
also need to be updated again.  Fix by calling skb_reset_network_header().

Fixes: 458bf2f2 ("net: core: support XDP generic on stacked devices.")
Reported-by: default avatarBrandon Cazander <brandon.cazander@multapplied.net>
Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      065af355
    • Jesper Dangaard Brouer's avatar
      selftests/bpf: reduce time to execute test_xdp_vlan.sh · 13978d1e
      Jesper Dangaard Brouer authored 
      Given the increasing number of BPF selftests, it makes sense to
reduce the time to execute these tests.  The ping parameters are
adjusted to reduce the time from measures 9 sec to approx 2.8 sec.
Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13978d1e
    • Jesper Dangaard Brouer's avatar
      selftests/bpf: add wrapper scripts for test_xdp_vlan.sh · d35661fc
      Jesper Dangaard Brouer authored 
      In-order to test both native-XDP (xdpdrv) and generic-XDP (xdpgeneric)
create two wrapper test scripts, that start the test_xdp_vlan.sh script
with these modes.
Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d35661fc
    • Jesper Dangaard Brouer's avatar
      bpf: fix XDP vlan selftests test_xdp_vlan.sh · 4de9c89a
      Jesper Dangaard Brouer authored 
      Change BPF selftest test_xdp_vlan.sh to (default) use generic XDP.

This selftest was created together with a fix for generic XDP, in commit
29724956 ("net: fix generic XDP to handle if eth header was
mangled"). And was suppose to catch if generic XDP was broken again.

The tests are using veth and assumed that veth driver didn't support
native driver XDP, thus it used the (ip link set) 'xdp' attach that fell
back to generic-XDP. But veth gained native-XDP support in 948d4f21
("veth: Add driver XDP"), which caused this test script to use
native-XDP.

Fixes: 948d4f21 ("veth: Add driver XDP")
Fixes: 97396ff0 ("selftests/bpf: add XDP selftests for modifying and popping VLAN headers")
Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4de9c89a
    • Qian Cai's avatar
      net/mlx5e: always initialize frag->last_in_page · 60d60c8f
      Qian Cai authored 
      The commit 069d1146 ("net/mlx5e: RX, Enhance legacy Receive Queue
memory scheme") introduced an undefined behaviour below due to
"frag->last_in_page" is only initialized in mlx5e_init_frags_partition()
when,

if (next_frag.offset + frag_info[f].frag_stride > PAGE_SIZE)

or after bailed out the loop,

for (i = 0; i < mlx5_wq_cyc_get_size(&rq->wqe.wq); i++)

As the result, there could be some "frag" have uninitialized
value of "last_in_page".

Later, get_frag() obtains those "frag" and check "frag->last_in_page" in
mlx5e_put_rx_frag() and triggers the error during boot. Fix it by always
initializing "frag->last_in_page" to "false" in
mlx5e_init_frags_partition().

UBSAN: Undefined behaviour in
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:325:12
load of value 170 is not a valid value for type 'bool' (aka '_Bool')
Call trace:
 dump_backtrace+0x0/0x264
 show_stack+0x20/0x2c
 dump_stack+0xb0/0x104
 __ubsan_handle_load_invalid_value+0x104/0x128
 mlx5e_handle_rx_cqe+0x8e8/0x12cc [mlx5_core]
 mlx5e_poll_rx_cq+0xca8/0x1a94 [mlx5_core]
 mlx5e_napi_poll+0x17c/0xa30 [mlx5_core]
 net_rx_action+0x248/0x940
 __do_softirq+0x350/0x7b8
 irq_exit+0x200/0x26c
 __handle_domain_irq+0xc8/0x128
 gic_handle_irq+0x138/0x228
 el1_irq+0xb8/0x140
 arch_cpu_idle+0x1a4/0x348
 do_idle+0x114/0x1b0
 cpu_startup_entry+0x24/0x28
 rest_init+0x1ac/0x1dc
 arch_call_rest_init+0x10/0x18
 start_kernel+0x4d4/0x57c

Fixes: 069d1146 ("net/mlx5e: RX, Enhance legacy Receive Queue memory scheme")
Signed-off-by: default avatarQian Cai <cai@lca.pw>
Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60d60c8f
    • Dmytro Linkin's avatar
      net: sched: use temporary variable for actions indexes · 7be8ef2c
      Dmytro Linkin authored 
      Currently init call of all actions (except ipt) init their 'parm'
structure as a direct pointer to nla data in skb. This leads to race
condition when some of the filter actions were initialized successfully
(and were assigned with idr action index that was written directly
into nla data), but then were deleted and retried (due to following
action module missing or classifier-initiated retry), in which case
action init code tries to insert action to idr with index that was
assigned on previous iteration. During retry the index can be reused
by another action that was inserted concurrently, which causes
unintended action sharing between filters.
To fix described race condition, save action idr index to temporary
stack-allocated variable instead on nla data.

Fixes: 0190c1d4 ("net: sched: atomically check-allocate action")
Signed-off-by: default avatarDmytro Linkin <dmitrolin@mellanox.com>
Signed-off-by: default avatarVlad Buslov <vladbu@mellanox.com>
Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7be8ef2c
    • Hubert Feurstein's avatar
      net: dsa: mv88e6xxx: drop adjust_link to enabled phylink · 7fb5a711
      Hubert Feurstein authored 
      We have to drop the adjust_link callback in order to finally migrate to
phylink.

Otherwise we get the following warning during startup:
  "mv88e6xxx 2188000.ethernet-1:10: Using legacy PHYLIB callbacks. Please
   migrate to PHYLINK!"

The warning is generated in the function dsa_port_link_register_of in
dsa/port.c:

  int dsa_port_link_register_of(struct dsa_port *dp)
  {
  	struct dsa_switch *ds = dp->ds;

  	if (!ds->ops->adjust_link)
  		return dsa_port_phylink_register(dp);

  	dev_warn(ds->dev,
  		 "Using legacy PHYLIB callbacks. Please migrate to PHYLINK!\n");
  	[...]
  }
Signed-off-by: default avatarHubert Feurstein <h.feurstein@gmail.com>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7fb5a711
    • Johan Hovold's avatar
      NFC: nfcmrvl: fix gpio-handling regression · c3953a3c
      Johan Hovold authored 
      Fix two reset-gpio sanity checks which were never converted to use
gpio_is_valid(), and make sure to use -EINVAL to indicate a missing
reset line also for the UART-driver module parameter and for the USB
driver.

This specifically prevents the UART and USB drivers from incidentally
trying to request and use gpio 0, and also avoids triggering a WARN() in
gpio_to_desc() during probe when no valid reset line has been specified.

Fixes: e33a3f84 ("NFC: nfcmrvl: allow gpio 0 for reset signalling")
Reported-by: syzbot+cf35b76f35e068a1107f@syzkaller.appspotmail.com
Tested-by: syzbot+cf35b76f35e068a1107f@syzkaller.appspotmail.com
Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      c3953a3c
  3. 03 Aug, 2019 7 commits
    • Qian Cai's avatar
      net/socket: fix GCC8+ Wpacked-not-aligned warnings · 5e5412c3
      Qian Cai authored 
      There are a lot of those warnings with GCC8+ 64-bit,

In file included from ./include/linux/sctp.h:42,
                 from net/core/skbuff.c:47:
./include/uapi/linux/sctp.h:395:1: warning: alignment 4 of 'struct
sctp_paddr_change' is less than 8 [-Wpacked-not-aligned]
 } __attribute__((packed, aligned(4)));
 ^
./include/uapi/linux/sctp.h:728:1: warning: alignment 4 of 'struct
sctp_setpeerprim' is less than 8 [-Wpacked-not-aligned]
 } __attribute__((packed, aligned(4)));
 ^
./include/uapi/linux/sctp.h:727:26: warning: 'sspp_addr' offset 4 in
'struct sctp_setpeerprim' isn't aligned to 8 [-Wpacked-not-aligned]
  struct sockaddr_storage sspp_addr;
                          ^~~~~~~~~
./include/uapi/linux/sctp.h:741:1: warning: alignment 4 of 'struct
sctp_prim' is less than 8 [-Wpacked-not-aligned]
 } __attribute__((packed, aligned(4)));
 ^
./include/uapi/linux/sctp.h:740:26: warning: 'ssp_addr' offset 4 in
'struct sctp_prim' isn't aligned to 8 [-Wpacked-not-aligned]
  struct sockaddr_storage ssp_addr;
                          ^~~~~~~~
./include/uapi/linux/sctp.h:792:1: warning: alignment 4 of 'struct
sctp_paddrparams' is less than 8 [-Wpacked-not-aligned]
 } __attribute__((packed, aligned(4)));
 ^
./include/uapi/linux/sctp.h:784:26: warning: 'spp_address' offset 4 in
'struct sctp_paddrparams' isn't aligned to 8 [-Wpacked-not-aligned]
  struct sockaddr_storage spp_address;
                          ^~~~~~~~~~~
./include/uapi/linux/sctp.h:905:1: warning: alignment 4 of 'struct
sctp_paddrinfo' is less than 8 [-Wpacked-not-aligned]
 } __attribute__((packed, aligned(4)));
 ^
./include/uapi/linux/sctp.h:899:26: warning: 'spinfo_address' offset 4
in 'struct sctp_paddrinfo' isn't aligned to 8 [-Wpacked-not-aligned]
  struct sockaddr_storage spinfo_address;
                          ^~~~~~~~~~~~~~

This is because the commit 20c9c825 ("[SCTP] Fix SCTP socket options
to work with 32-bit apps on 64-bit kernels.") added "packed, aligned(4)"
GCC attributes to some structures but one of the members, i.e, "struct
sockaddr_storage" in those structures has the attribute,
"aligned(__alignof__ (struct sockaddr *)" which is 8-byte on 64-bit
systems, so the commit overwrites the designed alignments for
"sockaddr_storage".

To fix this, "struct sockaddr_storage" needs to be aligned to 4-byte as
it is only used in those packed sctp structure which is part of UAPI,
and "struct __kernel_sockaddr_storage" is used in some other
places of UAPI that need not to change alignments in order to not
breaking userspace.

Use an implicit alignment for "struct __kernel_sockaddr_storage" so it
can keep the same alignments as a member in both packed and un-packed
structures without breaking UAPI.
Suggested-by: default avatarDavid Laight <David.Laight@ACULAB.COM>
Signed-off-by: default avatarQian Cai <cai@lca.pw>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e5412c3
    • Kevin Lo's avatar
      r8152: fix typo in register name · 59c0b47a
      Kevin Lo authored 
      It is likely that PAL_BDC_CR should be PLA_BDC_CR.
Signed-off-by: default avatarKevin Lo <kevlo@kevlo.org>
Acked-by: default avatarHayes Wang <hayeswang@realtek.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59c0b47a
    • Heiner Kallweit's avatar
      net: phy: fix race in genphy_update_link · aa6b1956
      Heiner Kallweit authored 
      In phy_start_aneg() autoneg is started, and immediately after that
link and autoneg status are read. As reported in [0] it can happen that
at time of this read the PHY has reset the "aneg complete" bit but not
yet the "link up" bit, what can result in a false link-up detection.
To fix this don't report link as up if we're in aneg mode and PHY
doesn't signal "aneg complete".

[0] https://marc.info/?t=156413509900003&r=1&w=2

Fixes: 4950c2ba ("net: phy: fix autoneg mismatch case in genphy_read_status")
Reported-by: default avatarliuyonglong <liuyonglong@huawei.com>
Tested-by: default avatarliuyonglong <liuyonglong@huawei.com>
Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa6b1956
    • YueHaibing's avatar
      enetc: Select PHYLIB while CONFIG_FSL_ENETC_VF is set · 2802d2cf
      YueHaibing authored 
      Like FSL_ENETC, when CONFIG_FSL_ENETC_VF is set,
we should select PHYLIB, otherwise building still fails:

drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_open':
enetc.c:(.text+0x2744): undefined reference to `phy_start'
enetc.c:(.text+0x282c): undefined reference to `phy_disconnect'
drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_close':
enetc.c:(.text+0x28f8): undefined reference to `phy_stop'
enetc.c:(.text+0x2904): undefined reference to `phy_disconnect'
drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x3f8): undefined reference to `phy_ethtool_get_link_ksettings'
drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x400): undefined reference to `phy_ethtool_set_link_ksettings'
Reported-by: default avatarHulk Robot <hulkci@huawei.com>
Fixes: d4fd0404 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2802d2cf
    • Wang Xiayang's avatar
      net/ethernet/qlogic/qed: force the string buffer NULL-terminated · 3690c8c9
      Wang Xiayang authored 
      strncpy() does not ensure NULL-termination when the input string
size equals to the destination buffer size 30.
The output string is passed to qed_int_deassertion_aeu_bit()
which calls DP_INFO() and relies NULL-termination.

Use strlcpy instead. The other conditional branch above strncpy()
needs no fix as snprintf() ensures NULL-termination.

This issue is identified by a Coccinelle script.
Signed-off-by: default avatarWang Xiayang <xywang.sjtu@sjtu.edu.cn>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3690c8c9
    • Gustavo A. R. Silva's avatar
      atm: iphase: Fix Spectre v1 vulnerability · ea443e5e
      Gustavo A. R. Silva authored 
      board is controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/atm/iphase.c:2765 ia_ioctl() warn: potential spectre issue 'ia_dev' [r] (local cap)
drivers/atm/iphase.c:2774 ia_ioctl() warn: possible spectre second half.  'iadev'
drivers/atm/iphase.c:2782 ia_ioctl() warn: possible spectre second half.  'iadev'
drivers/atm/iphase.c:2816 ia_ioctl() warn: possible spectre second half.  'iadev'
drivers/atm/iphase.c:2823 ia_ioctl() warn: possible spectre second half.  'iadev'
drivers/atm/iphase.c:2830 ia_ioctl() warn: potential spectre issue '_ia_dev' [r] (local cap)
drivers/atm/iphase.c:2845 ia_ioctl() warn: possible spectre second half.  'iadev'
drivers/atm/iphase.c:2856 ia_ioctl() warn: possible spectre second half.  'iadev'

Fix this by sanitizing board before using it to index ia_dev and _ia_dev

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ea443e5e
    • Dexuan Cui's avatar
      hv_sock: Fix hang when a connection is closed · 685703b4
      Dexuan Cui authored 
      There is a race condition for an established connection that is being closed
by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the
'remove_sock' is false):

1 for the initial value;
1 for the sk being in the bound list;
1 for the sk being in the connected list;
1 for the delayed close_work.

After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may*
decrease the refcnt to 3.

Concurrently, hvs_close_connection() runs in another thread:
  calls vsock_remove_sock() to decrease the refcnt by 2;
  call sock_put() to decrease the refcnt to 0, and free the sk;
  next, the "release_sock(sk)" may hang due to use-after-free.

In the above, after hvs_release() finishes, if hvs_close_connection() runs
faster than "__vsock_release() -> sock_put(sk)", then there is not any issue,
because at the beginning of hvs_close_connection(), the refcnt is still 4.

The issue can be resolved if an extra reference is taken when the
connection is established.

Fixes: a9eeb998 ("hv_sock: Add support for delayed close")
Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
Reviewed-by: default avatarSunil Muthuswamy <sunilmut@microsoft.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      685703b4
  5. 01 Aug, 2019 12 commits
  7. 31 Jul, 2019 13 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7