1. 29 8月, 2021 2 次提交
  2. 28 8月, 2021 3 次提交
  3. 27 8月, 2021 4 次提交
  4. 26 8月, 2021 8 次提交
  5. 25 8月, 2021 11 次提交
    • P
      net: add accept helper not installing fd · d32f89da
      Pavel Begunkov 提交于
      Introduce and reuse a helper that acts similarly to __sys_accept4_file()
      but returns struct file instead of installing file descriptor. Will be
      used by io_uring.
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Acked-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Link: https://lore.kernel.org/r/c57b9e8e818d93683a3d24f8ca50ca038d1da8c4.1629888991.git.asml.silence@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      d32f89da
    • V
      net: dsa: tag_sja1105: stop asking the sja1105 driver in sja1105_xmit_tpid · 8ded9160
      Vladimir Oltean 提交于
      Introduced in commit 38b5beea ("net: dsa: sja1105: prepare tagger
      for handling DSA tags and VLAN simultaneously"), the sja1105_xmit_tpid
      function solved quite a different problem than our needs are now.
      
      Then, we used best-effort VLAN filtering and we were using the xmit_tpid
      to tunnel packets coming from an 8021q upper through the TX VLAN allocated
      by tag_8021q to that egress port. The need for a different VLAN protocol
      depending on switch revision came from the fact that this in itself was
      more of a hack to trick the hardware into accepting tunneled VLANs in
      the first place.
      
      Right now, we deny 8021q uppers (see sja1105_prechangeupper). Even if we
      supported them again, we would not do that using the same method of
      {tunneling the VLAN on egress, retagging the VLAN on ingress} that we
      had in the best-effort VLAN filtering mode. It seems rather simpler that
      we just allocate a VLAN in the VLAN table that is simply not used by the
      bridge at all, or by any other port.
      
      Anyway, I have 2 gripes with the current sja1105_xmit_tpid:
      
      1. When sending packets on behalf of a VLAN-aware bridge (with the new
         TX forwarding offload framework) plus untagged (with the tag_8021q
         VLAN added by the tagger) packets, we can see that on SJA1105P/Q/R/S
         and later (which have a qinq_tpid of ETH_P_8021AD), some packets sent
         through the DSA master have a VLAN protocol of 0x8100 and others of
         0x88a8. This is strange and there is no reason for it now. If we have
         a bridge and are therefore forced to send using that bridge's TPID,
         we can as well blend with that bridge's VLAN protocol for all packets.
      
      2. The sja1105_xmit_tpid introduces a dependency on the sja1105 driver,
         because it looks inside dp->priv. It is desirable to keep as much
         separation between taggers and switch drivers as possible. Now it
         doesn't do that anymore.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ded9160
    • V
      net: dsa: sja1105: drop untagged packets on the CPU and DSA ports · b0b8c67e
      Vladimir Oltean 提交于
      The sja1105 driver is a bit special in its use of VLAN headers as DSA
      tags. This is because in VLAN-aware mode, the VLAN headers use an actual
      TPID of 0x8100, which is understood even by the DSA master as an actual
      VLAN header.
      
      Furthermore, control packets such as PTP and STP are transmitted with no
      VLAN header as a DSA tag, because, depending on switch generation, there
      are ways to steer these control packets towards a precise egress port
      other than VLAN tags. Transmitting control packets as untagged means
      leaving a door open for traffic in general to be transmitted as untagged
      from the DSA master, and for it to traverse the switch and exit a random
      switch port according to the FDB lookup.
      
      This behavior is a bit out of line with other DSA drivers which have
      native support for DSA tagging. There, it is to be expected that the
      switch only accepts DSA-tagged packets on its CPU port, dropping
      everything that does not match this pattern.
      
      We perhaps rely a bit too much on the switches' hardware dropping on the
      CPU port, and place no other restrictions in the kernel data path to
      avoid that. For example, sja1105 is also a bit special in that STP/PTP
      packets are transmitted using "management routes"
      (sja1105_port_deferred_xmit): when sending a link-local packet from the
      CPU, we must first write a SPI message to the switch to tell it to
      expect a packet towards multicast MAC DA 01-80-c2-00-00-0e, and to route
      it towards port 3 when it gets it. This entry expires as soon as it
      matches a packet received by the switch, and it needs to be reinstalled
      for the next packet etc. All in all quite a ghetto mechanism, but it is
      all that the sja1105 switches offer for injecting a control packet.
      The driver takes a mutex for serializing control packets and making the
      pairs of SPI writes of a management route and its associated skb atomic,
      but to be honest, a mutex is only relevant as long as all parties agree
      to take it. With the DSA design, it is possible to open an AF_PACKET
      socket on the DSA master net device, and blast packets towards
      01-80-c2-00-00-0e, and whatever locking the DSA switch driver might use,
      it all goes kaput because management routes installed by the driver will
      match skbs sent by the DSA master, and not skbs generated by the driver
      itself. So they will end up being routed on the wrong port.
      
      So through the lens of that, maybe it would make sense to avoid that
      from happening by doing something in the network stack, like: introduce
      a new bit in struct sk_buff, like xmit_from_dsa. Then, somewhere around
      dev_hard_start_xmit(), introduce the following check:
      
      	if (netdev_uses_dsa(dev) && !skb->xmit_from_dsa)
      		kfree_skb(skb);
      
      Ok, maybe that is a bit drastic, but that would at least prevent a bunch
      of problems. For example, right now, even though the majority of DSA
      switches drop packets without DSA tags sent by the DSA master (and
      therefore the majority of garbage that user space daemons like avahi and
      udhcpcd and friends create), it is still conceivable that an aggressive
      user space program can open an AF_PACKET socket and inject a spoofed DSA
      tag directly on the DSA master. We have no protection against that; the
      packet will be understood by the switch and be routed wherever user
      space says. Furthermore: there are some DSA switches where we even have
      register access over Ethernet, using DSA tags. So even user space
      drivers are possible in this way. This is a huge hole.
      
      However, the biggest thing that bothers me is that udhcpcd attempts to
      ask for an IP address on all interfaces by default, and with sja1105, it
      will attempt to get a valid IP address on both the DSA master as well as
      on sja1105 switch ports themselves. So with IP addresses in the same
      subnet on multiple interfaces, the routing table will be messed up and
      the system will be unusable for traffic until it is configured manually
      to not ask for an IP address on the DSA master itself.
      
      It turns out that it is possible to avoid that in the sja1105 driver, at
      least very superficially, by requesting the switch to drop VLAN-untagged
      packets on the CPU port. With the exception of control packets, all
      traffic originated from tag_sja1105.c is already VLAN-tagged, so only
      STP and PTP packets need to be converted. For that, we need to uphold
      the equivalence between an untagged and a pvid-tagged packet, and to
      remember that the CPU port of sja1105 uses a pvid of 4095.
      
      Now that we drop untagged traffic on the CPU port, non-aggressive user
      space applications like udhcpcd stop bothering us, and sja1105 effectively
      becomes just as vulnerable to the aggressive kind of user space programs
      as other DSA switches are (ok, users can also create 8021q uppers on top
      of the DSA master in the case of sja1105, but in future patches we can
      easily deny that, but it still doesn't change the fact that VLAN-tagged
      packets can still be injected over raw sockets).
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0b8c67e
    • G
      net-next: When a bond have a massive amount of VLANs with IPv6 addresses,... · 406f42fa
      Gilad Naaman 提交于
      net-next: When a bond have a massive amount of VLANs with IPv6 addresses, performance of changing link state, attaching a VRF, changing an IPv6 address, etc. go down dramtically.
      
      The source of most of the slow down is the `dev_addr_lists.c` module,
      which mainatins a linked list of HW addresses.
      When using IPv6, this list grows for each IPv6 address added on a
      VLAN, since each IPv6 address has a multicast HW address associated with
      it.
      
      When performing any modification to the involved links, this list is
      traversed many times, often for nothing, all while holding the RTNL
      lock.
      
      Instead, this patch adds an auxilliary rbtree which cuts down
      traversal time significantly.
      
      Performance can be seen with the following script:
      
      	#!/bin/bash
      	ip netns del test || true 2>/dev/null
      	ip netns add test
      
      	echo 1 | ip netns exec test tee /proc/sys/net/ipv6/conf/all/keep_addr_on_down > /dev/null
      
      	set -e
      
      	ip -n test link add foo type veth peer name bar
      	ip -n test link add b1 type bond
      	ip -n test link add florp type vrf table 10
      
      	ip -n test link set bar master b1
      	ip -n test link set foo up
      	ip -n test link set bar up
      	ip -n test link set b1 up
      	ip -n test link set florp up
      
      	VLAN_COUNT=1500
      	BASE_DEV=b1
      
      	echo Creating vlans
      	ip netns exec test time -p bash -c "for i in \$(seq 1 $VLAN_COUNT);
      	do ip -n test link add link $BASE_DEV name foo.\$i type vlan id \$i; done"
      
      	echo Bringing them up
      	ip netns exec test time -p bash -c "for i in \$(seq 1 $VLAN_COUNT);
      	do ip -n test link set foo.\$i up; done"
      
      	echo Assiging IPv6 Addresses
      	ip netns exec test time -p bash -c "for i in \$(seq 1 $VLAN_COUNT);
      	do ip -n test address add dev foo.\$i 2000::\$i/64; done"
      
      	echo Attaching to VRF
      	ip netns exec test time -p bash -c "for i in \$(seq 1 $VLAN_COUNT);
      	do ip -n test link set foo.\$i master florp; done"
      
      On an Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz machine, the performance
      before the patch is (truncated):
      
      	Creating vlans
      	real 108.35
      	Bringing them up
      	real 4.96
      	Assiging IPv6 Addresses
      	real 19.22
      	Attaching to VRF
      	real 458.84
      
      After the patch:
      
      	Creating vlans
      	real 5.59
      	Bringing them up
      	real 5.07
      	Assiging IPv6 Addresses
      	real 5.64
      	Attaching to VRF
      	real 25.37
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Lu Wei <luwei32@huawei.com>
      Cc: Xiongfeng Wang <wangxiongfeng2@huawei.com>
      Cc: Taehee Yoo <ap420073@gmail.com>
      Signed-off-by: NGilad Naaman <gnaaman@drivenets.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      406f42fa
    • G
      crash_dump: Make elfcorehdr address/size symbols always visible · 33709413
      Geert Uytterhoeven 提交于
      Make the forward declarations of elfcorehdr_addr and elfcorehdr_size,
      and the definitions of ELFCORE_ADDR_MAX and ELFCORE_ADDR_ERR always
      available, like is done for phys_initrd_start and phys_initrd_size.
      Code referring to these symbols can then just check for
      IS_ENABLED(CONFIG_CRASH_DUMP), instead of requiring conditional
      compilation using an #ifdef, thus preparing to increase compile
      coverage.
      Suggested-by: NRob Herring <robh+dt@kernel.org>
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/ba965ca613c0cc82c1ec2fe353ee34fb13b36474.1628670468.git.geert+renesas@glider.be
      33709413
    • V
      PCI: Add pcie_ptm_enabled() · 014408cd
      Vinicius Costa Gomes 提交于
      Add a predicate that returns if PCIe PTM (Precision Time Measurement)
      is enabled.
      
      It will only return true if it's enabled in all the ports in the path
      from the device to the root.
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      014408cd
    • V
      Revert "PCI: Make pci_enable_ptm() private" · 1d71eb53
      Vinicius Costa Gomes 提交于
      Make pci_enable_ptm() accessible from the drivers.
      
      Exposing this to the driver enables the driver to use the
      'ptm_enabled' field of 'pci_dev' to check if PTM is enabled or not.
      
      This reverts commit ac6c26da ("PCI: Make pci_enable_ptm() private").
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      1d71eb53
    • J
      include:libata: fix boolreturn.cocci warnings · 62283c6c
      Jing Yangyang 提交于
      ./include/linux/libata.h:1462:8-9:WARNING: return of 0/1 in function
      'ata_is_host_link' with return type bool
      
      Return statements in functions returning bool should use true/false
      instead of 1/0.
      
      Generated by: scripts/coccinelle/misc/boolreturn.cocci
      Reported-by: NZeal Robot <zealci@zte.com.cn>
      Signed-off-by: NJing Yangyang <jing.yangyang@zte.com.cn>
      Link: https://lore.kernel.org/r/20210824060702.59006-1-deng.changcheng@zte.com.cnSigned-off-by: NJens Axboe <axboe@kernel.dk>
      62283c6c
    • C
      block: mark blkdev_fsync static · 158ee7b6
      Christoph Hellwig 提交于
      blkdev_fsync is only used inside of block_dev.c since the
      removal of the raw drіver.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Link: https://lore.kernel.org/r/20210824151823.1575100-1-hch@lst.deSigned-off-by: NJens Axboe <axboe@kernel.dk>
      158ee7b6
    • D
      mmc: block: Support alternative_gpt_sector() operation · dc913385
      Dmitry Osipenko 提交于
      Support generic alternative_gpt_sector() block device operation.
      It calculates location of GPT entry for eMMC of NVIDIA Tegra Android
      devices. Add new MMC_CAP2_ALT_GPT_TEGRA flag that enables scanning of
      alternative GPT sector and add raw_boot_mult field to mmc_ext_csd
      which allows to get size of the boot partitions that is needed for
      the calculation.
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Link: https://lore.kernel.org/r/20210820004536.15791-4-digetx@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      dc913385
    • D
      block: Add alternative_gpt_sector() operation · 0bdfbca8
      Dmitry Osipenko 提交于
      Add alternative_gpt_sector() block device operation which specifies
      alternative location of a GPT entry. This allows us to support Android
      devices that have GPT entry at a non-standard location and can't be
      repartitioned easily.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Suggested-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Link: https://lore.kernel.org/r/20210820004536.15791-2-digetx@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
      0bdfbca8
  6. 24 8月, 2021 12 次提交
反馈
建议
客服 返回
顶部