* [PATCH net-next v2 0/8] net: phy: mscc: PHC and timestamping support
From: Antoine Tenart @ 2020-06-17 13:31 UTC (permalink / raw)
To: davem, andrew, f.fainelli, hkallweit1, richardcochran,
alexandre.belloni, UNGLinuxDriver
Cc: netdev, linux-kernel, thomas.petazzoni, allan.nielsen, foss,
antoine.tenart
Hello,
This series aims at adding support for PHC and timestamping operations
in the MSCC PHY driver, for the VSC858x and VSC8575. Those PHYs are
capable of timestamping in 1-step and 2-step for both L2 and L4 traffic.
As of this series, only IPv4 support was implemented when using L4 mode.
This is because of an hardware limitation which prevents us for
supporting both IPv4 and IPv6 at the same time. Implementing support for
IPv6 should be quite easy (I do have the modifications needed for the
hardware configuration) but I did not see a way to retrieve this
information in hwtstamp(). What would you suggest?
Those PHYs are distributed in hardware packages containing multiple
times the PHY. The VSC8584 for example is composed of 4 PHYs. With
hardware packages, parts of the logic is usually common and one of the
PHY has to be used for some parts of the initialization. Following this
logic, the 1588 blocks of those PHYs are shared between two PHYs and
accessing the registers has to be done using the "base" PHY of the
group. This is handled thanks to helpers in the PTP code (and locks).
We also need the MDIO bus lock while performing a single read or write
to the 1588 registers as the read/write are composed of multiple MDIO
transactions (and we don't want other threads updating the page).
To get and set the PHC time, a GPIO has to be used and changes are only
retrieved or committed when on a rising edge. The same GPIO is shared by
all PHYs, so the granularity of the lock protecting it has to be
different from the ones protecting the 1588 registers (the VSC8584 PHY
has 2 1588 blocks, and a single load/save pin).
Patch 1 extends the recently added helpers to share information between
PHYs of the same hardware package; to allow having part of the probe to
be shared (in addition to the already supported init part). This will be
used when adding support for PHC/TS to initialize locks.
Patches 2 and 3 are mostly cosmetic.
Patch 4 takes into account the 1588 block in the MACsec initialization,
to allow having both the MACsec and 1588 blocks initialized on a running
system.
Patches 5 and 6 add support for PHC and timestamping operations in the
MSCC driver. An initialization of the 1588 block (plus all the registers
definition; and helpers) is added first; and then comes a patch to
implement the PHC and timestamping API.
Patches 7 and 8 add the required hardware description for device trees,
to be able to use the load/save GPIO pin on the PCB120 board.
To use this on a PCB120 board, two other series are needed and have
already been sent upstream (one is merged). There are no dependency
between all those series.
Thanks!
Antoine
Since v1:
- Removed checks in rxtstamp/txtstamp as skb cannot be NULL here.
- Reworked get_ptp_header_rx/get_ptp_header.
- Reworked the locking logic between the PHC and timestamping
operations.
- Fixed a compilation issue on x86 reported by Jakub.
Antoine Tenart (5):
net: phy: add support for a common probe between shared PHYs
net: phy: mscc: fix copyright and author information in MACsec
net: phy: mscc: take into account the 1588 block in MACsec init
net: phy: mscc: timestamping and PHC support
dt-bindings: net: phy: vsc8531: document the load/save GPIO
Quentin Schulz (3):
net: phy: mscc: remove the TR CLK disable magic value
net: phy: mscc: 1588 block initialization
MIPS: dts: ocelot: describe the load/save GPIO
.../bindings/net/mscc-phy-vsc8531.txt | 3 +
arch/mips/boot/dts/mscc/ocelot_pcb120.dts | 12 +-
drivers/net/phy/mscc/Makefile | 4 +
drivers/net/phy/mscc/mscc.h | 64 +
drivers/net/phy/mscc/mscc_fc_buffer.h | 2 +-
drivers/net/phy/mscc/mscc_mac.h | 2 +-
drivers/net/phy/mscc/mscc_macsec.c | 10 +-
drivers/net/phy/mscc/mscc_macsec.h | 2 +-
drivers/net/phy/mscc/mscc_main.c | 63 +-
drivers/net/phy/mscc/mscc_ptp.c | 1588 +++++++++++++++++
drivers/net/phy/mscc/mscc_ptp.h | 477 +++++
include/linux/phy.h | 18 +-
12 files changed, 2224 insertions(+), 21 deletions(-)
create mode 100644 drivers/net/phy/mscc/mscc_ptp.c
create mode 100644 drivers/net/phy/mscc/mscc_ptp.h
--
2.26.2
^ permalink raw reply
* qmi_wwan not using netif_carrier_*()
From: Tanjeff-Nicolai Moos @ 2020-06-17 13:21 UTC (permalink / raw)
To: netdev
Hi netdevs,
Kernel version:
I'm working with kernel 4.14.137 (OpenWRT project). But I looked at
the source of kernel 5.7 and found the same situation.
Problem:
I'm using the qmi_wwan driver for a Sierra Wireless EM7455 LTE
modem. This driver does not use
netif_carrier_on()/netif_carrier_off() to update its link status.
This confuses ledtrig_netdev which uses netif_carrier_ok() to obtain
the link status.
My solution:
As a solution (or workaround?) I would try:
1) In drivers/net/usb/qmi_wwan.c, lines 904/913: Add the flag
FLAG_LINK_INTR.
2) In drivers/net/usb/usbnet.c, functions usbnet_open() and
usbnet_stop(): Add a call to netif_carrier_*(),
but only if FLAG_LINK_INTR is set.
Question:
Is this the intended way to use FLAG_LINK_INTR and netif_carrier_*()?
Or is there another recommended way to obtain the link status of
network devices (I could change ledtrig_netdev)?
Kind regards, tanjeff
--
Tanjeff-Nicolai Moos
Dipl.-Inf. (FH)
Senior Software Engineer
ELTEC Elektronik AG, Mainz
_________________________
Fon +49 6131 918 342
Fax +49 6131 918 195
Email tmoos@eltec.de
Web www.eltec.de
________________________________
*********************************************************
ELTEC Elektronik AG
Galileo-Galilei-Straße 11
D-55129 Mainz
Vorstand: Peter Albert
Aufsichtsratsvorsitzender: Andreas Kochhäuser
Registergericht: Amtsgericht Mainz
Registernummer: HRB 7038
Ust-ID: DE 149 049 790
*********************************************************
Wichtiger Hinweis:
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Evtl. Anhänge dieser Nachricht wurden auf Viren überprüft!
Jede Form von Vervielfältigung, Abänderung, Verbreitung oder Veröffentlichung dieser E-Mail Nachricht ist untersagt! Das Verwenden von Informationen aus dieser Nachricht für irgendwelche Zwecke ist strengstens untersagt.
Es gelten unsere Allgemeinen Geschäftsbedingungen, zu finden unter www.eltec.de.
^ permalink raw reply
* [PATCH] net: macb: undo operations in case of failure
From: Claudiu Beznea @ 2020-06-17 13:23 UTC (permalink / raw)
To: nicolas.ferre, davem, kuba, linux
Cc: antoine.tenart, netdev, linux-kernel, Claudiu Beznea
Undo previously done operation in case macb_phylink_connect()
fails. Since macb_reset_hw() is the 1st undo operation the
napi_exit label was renamed to reset_hw.
Fixes: b2b041417299 ("net: macb: convert to phylink")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
drivers/net/ethernet/cadence/macb_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 67933079aeea..257c4920cb88 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2558,7 +2558,7 @@ static int macb_open(struct net_device *dev)
err = macb_phylink_connect(bp);
if (err)
- goto napi_exit;
+ goto reset_hw;
netif_tx_start_all_queues(dev);
@@ -2567,9 +2567,11 @@ static int macb_open(struct net_device *dev)
return 0;
-napi_exit:
+reset_hw:
+ macb_reset_hw(bp);
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue)
napi_disable(&queue->napi);
+ macb_free_consistent(bp);
pm_exit:
pm_runtime_put_sync(&bp->pdev->dev);
return err;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/5] Huawei BMA: Adding Huawei BMA driver: host_cdev_drv
From: kernel test robot @ 2020-06-17 13:28 UTC (permalink / raw)
To: yunaixin03610, netdev; +Cc: kbuild-all, yunaixin
In-Reply-To: <20200615145906.1013-3-yunaixin03610@163.com>
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc1 next-20200616]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/yunaixin03610-163-com/Adding-Huawei-BMA-drivers/20200616-102318
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a5dc8300df75e8b8384b4c82225f1e4a0b4d9b55
:::::: branch date: 23 hours ago
:::::: commit date: 23 hours ago
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
cppcheck warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:443:2: warning: Redundant assignment of 'ent' to itself. [selfAssignment]
UNUSED(ent);
^
>> drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:492:2: warning: Redundant assignment of 'pdev' to itself. [selfAssignment]
UNUSED(pdev);
^
>> drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:493:2: warning: Redundant assignment of 'state' to itself. [selfAssignment]
UNUSED(state);
^
drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:500:2: warning: Redundant assignment of 'pdev' to itself. [selfAssignment]
UNUSED(pdev);
^
>> drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:149:3: warning: Shifting signed 32-bit value by 31 bits is undefined behaviour [shiftTooManyBitsSigned]
REGION_DIR_INPUT + (region & REGION_INDEX_MASK));
^
drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:158:55: warning: Shifting signed 32-bit value by 31 bits is undefined behaviour [shiftTooManyBitsSigned]
(void)pci_write_config_dword(pdev, ATU_REGION_CTRL2, REGION_ENABLE);
^
--
>> drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:63:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "lost_count :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:65:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "b2h_int :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:67:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "h2b_int :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:69:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "dma_count :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:71:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "recv_bytes :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:73:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "send_bytes :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:75:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "recv_pkgs :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:77:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "send_pkgs :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:79:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "drop_pkgs :%dn",
^
drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c:81:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint]
len += sprintf(buf + len, "fail_count :%dn",
^
>> drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:326:21: warning: Checking if unsigned variable 'count' is less than zero. [unsignedLessThanZero]
if (!data || count <= 0)
^
drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c:346:21: warning: Checking if unsigned variable 'count' is less than zero. [unsignedLessThanZero]
if (!data || count <= 0)
^
# https://github.com/0day-ci/linux/commit/d0965c4179b69ddd204c1f795f0d6ac080c657af
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout d0965c4179b69ddd204c1f795f0d6ac080c657af
vim +122 drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c
d0965c4179b69d yunaixin 2020-06-15 92
d0965c4179b69d yunaixin 2020-06-15 93 static int cdev_param_get_statics(char *buf, const struct kernel_param *kp)
d0965c4179b69d yunaixin 2020-06-15 94 {
d0965c4179b69d yunaixin 2020-06-15 95 int len = 0;
d0965c4179b69d yunaixin 2020-06-15 96 int i = 0;
d0965c4179b69d yunaixin 2020-06-15 97 __kernel_time_t running_time = 0;
d0965c4179b69d yunaixin 2020-06-15 98
d0965c4179b69d yunaixin 2020-06-15 99 if (!buf)
d0965c4179b69d yunaixin 2020-06-15 100 return 0;
d0965c4179b69d yunaixin 2020-06-15 101
d0965c4179b69d yunaixin 2020-06-15 102 GET_SYS_SECONDS(running_time);
d0965c4179b69d yunaixin 2020-06-15 103 running_time -= g_cdev_set.init_time;
d0965c4179b69d yunaixin 2020-06-15 104 len += sprintf(buf + len,
d0965c4179b69d yunaixin 2020-06-15 105 "============================CDEV_DRIVER_INFO=======================\n");
d0965c4179b69d yunaixin 2020-06-15 106 len += sprintf(buf + len, "version :%s\n", CDEV_VERSION);
d0965c4179b69d yunaixin 2020-06-15 107
d0965c4179b69d yunaixin 2020-06-15 108 len += sprintf(buf + len, "running_time :%luD %02lu:%02lu:%02lu\n",
d0965c4179b69d yunaixin 2020-06-15 109 running_time / (SECONDS_PER_DAY),
d0965c4179b69d yunaixin 2020-06-15 110 running_time % (SECONDS_PER_DAY) / SECONDS_PER_HOUR,
d0965c4179b69d yunaixin 2020-06-15 111 running_time % SECONDS_PER_HOUR / SECONDS_PER_MINUTE,
d0965c4179b69d yunaixin 2020-06-15 112 running_time % SECONDS_PER_MINUTE);
d0965c4179b69d yunaixin 2020-06-15 113
d0965c4179b69d yunaixin 2020-06-15 114 for (i = 0; i < g_cdev_set.dev_num; i++) {
d0965c4179b69d yunaixin 2020-06-15 115 len += sprintf(buf + len,
d0965c4179b69d yunaixin 2020-06-15 116 "===================================================\n");
d0965c4179b69d yunaixin 2020-06-15 117 len += sprintf(buf + len, "name :%s\n",
d0965c4179b69d yunaixin 2020-06-15 118 g_cdev_set.dev_list[i].dev_name);
d0965c4179b69d yunaixin 2020-06-15 119 len +=
d0965c4179b69d yunaixin 2020-06-15 120 sprintf(buf + len, "dev_id :%08x\n",
d0965c4179b69d yunaixin 2020-06-15 121 g_cdev_set.dev_list[i].dev_id);
d0965c4179b69d yunaixin 2020-06-15 @122 len += sprintf(buf + len, "type :%u\n",
d0965c4179b69d yunaixin 2020-06-15 123 g_cdev_set.dev_list[i].type);
d0965c4179b69d yunaixin 2020-06-15 124 len += sprintf(buf + len, "status :%s\n",
d0965c4179b69d yunaixin 2020-06-15 125 g_cdev_set.dev_list[i].s.open_status ==
d0965c4179b69d yunaixin 2020-06-15 126 1 ? "open" : "close");
d0965c4179b69d yunaixin 2020-06-15 127 len += sprintf(buf + len, "send_pkgs :%u\n",
d0965c4179b69d yunaixin 2020-06-15 128 g_cdev_set.dev_list[i].s.send_pkgs);
d0965c4179b69d yunaixin 2020-06-15 129 len +=
d0965c4179b69d yunaixin 2020-06-15 130 sprintf(buf + len, "send_bytes:%u\n",
d0965c4179b69d yunaixin 2020-06-15 131 g_cdev_set.dev_list[i].s.send_bytes);
d0965c4179b69d yunaixin 2020-06-15 132 len += sprintf(buf + len, "send_failed_count:%u\n",
d0965c4179b69d yunaixin 2020-06-15 133 g_cdev_set.dev_list[i].s.send_failed_count);
d0965c4179b69d yunaixin 2020-06-15 134 len += sprintf(buf + len, "recv_pkgs :%u\n",
d0965c4179b69d yunaixin 2020-06-15 135 g_cdev_set.dev_list[i].s.recv_pkgs);
d0965c4179b69d yunaixin 2020-06-15 136 len += sprintf(buf + len, "recv_bytes:%u\n",
d0965c4179b69d yunaixin 2020-06-15 137 g_cdev_set.dev_list[i].s.recv_bytes);
d0965c4179b69d yunaixin 2020-06-15 138 len += sprintf(buf + len, "recv_failed_count:%u\n",
d0965c4179b69d yunaixin 2020-06-15 139 g_cdev_set.dev_list[i].s.recv_failed_count);
d0965c4179b69d yunaixin 2020-06-15 140 }
d0965c4179b69d yunaixin 2020-06-15 141
d0965c4179b69d yunaixin 2020-06-15 142 return len;
d0965c4179b69d yunaixin 2020-06-15 143 }
d0965c4179b69d yunaixin 2020-06-15 144 module_param_call(statistics, NULL, cdev_param_get_statics, &debug, 0444);
d0965c4179b69d yunaixin 2020-06-15 145 MODULE_PARM_DESC(statistics, "Statistics info of cdev driver,readonly");
d0965c4179b69d yunaixin 2020-06-15 146
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* ADQ - comparison to aRFS, clarifications on NAPI ID, binding with busy-polling
From: Maxim Mikityanskiy @ 2020-06-17 13:15 UTC (permalink / raw)
To: Amritha Nambiar, Kiran Patil, Sridhar Samudrala
Cc: Alexander Duyck, Eric Dumazet, Tom Herbert, netdev
Hi,
I discovered Intel ADQ feature [1] that allows to boost performance by
picking dedicated queues for application traffic. We did some research,
and I got some level of understanding how it works, but I have some
questions, and I hope you could answer them.
1. SO_INCOMING_NAPI_ID usage. In my understanding, every connection has
a key (sk_napi_id) that is unique to the NAPI where this connection is
handled, and the application uses that key to choose a handler thread
from the thread pool. If we have a one-to-one relationship between
application threads and NAPI IDs of connections, each application thread
will handle only traffic from a single NAPI. Is my understanding correct?
1.1. I wonder how the application thread gets scheduled on the same core
that NAPI runs at. It currently only works with busy_poll, so when the
application initiates busy polling (calls epoll), does the Linux
scheduler move the thread to the right CPU? Do we have to have a strict
one-to-one relationship between threads and NAPIs, or can one thread
handle multiple NAPIs? When the data arrives, does the scheduler run the
application thread on the same CPU that NAPI ran on?
1.2. I see that SO_INCOMING_NAPI_ID is tightly coupled with busy_poll.
It is enabled only if CONFIG_NET_RX_BUSY_POLL is set. Is there a real
reason why it can't be used without busy_poll? In other words, if we
modify the kernel to drop this requirement, will the kernel still
schedule the application thread on the same CPU as NAPI when busy_poll
is not used?
2. Can you compare ADQ to aRFS+XPS? aRFS provides a way to steer traffic
to the application's CPU in an automatic fashion, and xps_rxqs can be
used to transmit from the corresponding queues. This setup doesn't need
manual configuration of TCs and is not limited to 4 applications. The
difference of ADQ is that (in my understanding) it moves the application
to the RX CPU, while aRFS steers the traffic to the RX queue handled my
the application's CPU. Is there any advantage of ADQ over aRFS, that I
failed to find?
3. At [1], you mention that ADQ can be used to create separate RSS sets.
Could you elaborate about the API used? Does the tc mqprio
configuration also affect RSS? Can it be turned on/off?
4. How is tc flower used in context of ADQ? Does the user need to
reflect the configuration in both mqprio qdisc (for TX) and tc flower
(for RX)? It looks like tc flower maps incoming traffic to TCs, but what
is the mechanism of mapping TCs to RX queues?
I really hope you will be able to shed more light on this feature to
increase my awareness on how to use it and to compare it with aRFS.
Thanks,
Max
[1]:
https://netdevconf.info/0x14/session.html?talk-ADQ-for-system-level-network-io-performance-improvements
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Michal Hocko @ 2020-06-17 12:55 UTC (permalink / raw)
To: Matthew Wilcox
Cc: dsterba, Joe Perches, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
David Rientjes, Johannes Weiner, Dan Carpenter,
Jason A . Donenfeld, linux-mm, keyrings, linux-kernel,
linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200617122321.GJ8681@bombadil.infradead.org>
On Wed 17-06-20 05:23:21, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote:
> > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> > > If you call vfree() under
> > > a spinlock, you're in trouble. in_atomic() only knows if we hold a
> > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
> > > in __vfree(). So we need the warning in order that preempt people can
> > > tell those without that there is a bug here.
> >
> > ... Unless I am missing something in_interrupt depends on preempt_count() as
> > well so neither of the two is reliable without PREEMPT_COUNT configured.
>
> preempt_count() always tracks whether we're in interrupt context,
> regardless of CONFIG_PREEMPT. The difference is that CONFIG_PREEMPT
> will track spinlock acquisitions as well.
Right you are! Thanks for the clarification. I find the situation
around preempt_count quite confusing TBH. Looking at existing users
of in_atomic() (e.g. a random one zd_usb_iowrite16v_async which check
in_atomic and then does GFP_KERNEL allocation which would be obviously
broken on !PREEMPT if the function can be called from an atomic
context), I am wondering whether it would make sense to track atomic
context also for !PREEMPT. This check is just terribly error prone.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: 答复: [PATCH] net: Fix the arp error in some cases
From: David Ahern @ 2020-06-17 12:44 UTC (permalink / raw)
To: Guodeqing (A), davem@davemloft.net
Cc: kuznet@ms2.inr.ac.ru, netdev@vger.kernel.org,
dsa@cumulusnetworks.com, kuba@kernel.org
In-Reply-To: <55929b71c9b24aeeba760585fc59497f@huawei.com>
On 6/16/20 9:38 PM, Guodeqing (A) wrote:
> rt_set_nexthop in __mkroute_output will check the nh->nh_scope value to determine whether to use the gw or not.
> if (nh->nh_gw && nh->nh_scope == RT_SCOPE_LINK) {
> rt->rt_gateway = nh->nh_gw;
> rt->rt_uses_gateway = 1;
> }
>
> (ip_route_output_key_hash-> ip_route_output_key_hash_rcu-> __mkroute_output-> rt_set_nexthop)
>
ok, I see now. Thanks.
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* KASAN: use-after-free Read in cgroup_path_ns_locked
From: syzbot @ 2020-06-17 12:28 UTC (permalink / raw)
To: andriin, ast, bpf, cgroups, christian, daniel, hannes,
john.fastabend, kafai, kpsingh, linux-kernel, lizefan, netdev,
songliubraving, syzkaller-bugs, tj, yhs
Hello,
syzbot found the following crash on:
HEAD commit: 7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12ad963e100000
kernel config: https://syzkaller.appspot.com/x/.config?x=d195fe572fb15312
dashboard link: https://syzkaller.appspot.com/bug?extid=3b66039191adbe4be590
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3b66039191adbe4be590@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in cgroup_path_ns_locked+0xd0/0x110 kernel/cgroup/cgroup.c:2227
Read of size 8 at addr ffff888093fc42b8 by task syz-executor.5/12988
CPU: 0 PID: 12988 Comm: syz-executor.5 Not tainted 5.7.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x188/0x20d lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
cgroup_path_ns_locked+0xd0/0x110 kernel/cgroup/cgroup.c:2227
cgroup_path_ns+0x43/0x70 kernel/cgroup/cgroup.c:2240
proc_cpuset_show+0x2ad/0xad0 kernel/cgroup/cpuset.c:3599
proc_single_show+0x116/0x1e0 fs/proc/base.c:766
seq_read+0x432/0xfd0 fs/seq_file.c:208
do_loop_readv_writev fs/read_write.c:715 [inline]
do_loop_readv_writev fs/read_write.c:702 [inline]
do_iter_read+0x483/0x650 fs/read_write.c:936
vfs_readv+0xf0/0x160 fs/read_write.c:1054
do_preadv+0x1bc/0x270 fs/read_write.c:1146
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x45ca69
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f11f653cc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000127
RAX: ffffffffffffffda RBX: 00000000004fb040 RCX: 000000000045ca69
RDX: 000000000000011c RSI: 00000000200017c0 RDI: 0000000000000004
RBP: 000000000078bfa0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000879 R14: 00000000004cb670 R15: 00007f11f653d6d4
Allocated by task 1:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
kmem_cache_alloc_trace+0x153/0x7d0 mm/slab.c:3551
kmalloc include/linux/slab.h:555 [inline]
kzalloc include/linux/slab.h:669 [inline]
cgroup1_root_to_use kernel/cgroup/cgroup-v1.c:1183 [inline]
cgroup1_get_tree+0xcfd/0x13b6 kernel/cgroup/cgroup-v1.c:1207
vfs_get_tree+0x89/0x2f0 fs/super.c:1547
do_new_mount fs/namespace.c:2874 [inline]
do_mount+0x1306/0x1b40 fs/namespace.c:3199
__do_sys_mount fs/namespace.c:3409 [inline]
__se_sys_mount fs/namespace.c:3386 [inline]
__x64_sys_mount+0x18f/0x230 fs/namespace.c:3386
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
Freed by task 22806:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
kasan_set_free_info mm/kasan/common.c:316 [inline]
__kasan_slab_free+0xf7/0x140 mm/kasan/common.c:455
__cache_free mm/slab.c:3426 [inline]
kfree+0x109/0x2b0 mm/slab.c:3757
cgroup_free_root kernel/cgroup/cgroup.c:1311 [inline]
cgroup_destroy_root kernel/cgroup/cgroup.c:1353 [inline]
css_free_rwork_fn+0x8e6/0xce0 kernel/cgroup/cgroup.c:4980
process_one_work+0x965/0x16a0 kernel/workqueue.c:2268
worker_thread+0x96/0xe20 kernel/workqueue.c:2414
kthread+0x388/0x470 kernel/kthread.c:268
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351
The buggy address belongs to the object at ffff888093fc4000
which belongs to the cache kmalloc-8k of size 8192
The buggy address is located 696 bytes inside of
8192-byte region [ffff888093fc4000, ffff888093fc6000)
The buggy address belongs to the page:
page:ffffea00024ff100 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 head:ffffea00024ff100 order:2 compound_mapcount:0 compound_pincount:0
flags: 0xfffe0000010200(slab|head)
raw: 00fffe0000010200 ffffea00024fe408 ffffea00024ffb08 ffff8880aa0021c0
raw: 0000000000000000 ffff888093fc4000 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888093fc4180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888093fc4200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888093fc4280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888093fc4300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888093fc4380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Matthew Wilcox @ 2020-06-17 12:23 UTC (permalink / raw)
To: Michal Hocko
Cc: dsterba, Joe Perches, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
David Rientjes, Johannes Weiner, Dan Carpenter,
Jason A . Donenfeld, linux-mm, keyrings, linux-kernel,
linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200617113157.GM9499@dhcp22.suse.cz>
On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote:
> On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> > If you call vfree() under
> > a spinlock, you're in trouble. in_atomic() only knows if we hold a
> > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
> > in __vfree(). So we need the warning in order that preempt people can
> > tell those without that there is a bug here.
>
> ... Unless I am missing something in_interrupt depends on preempt_count() as
> well so neither of the two is reliable without PREEMPT_COUNT configured.
preempt_count() always tracks whether we're in interrupt context,
regardless of CONFIG_PREEMPT. The difference is that CONFIG_PREEMPT
will track spinlock acquisitions as well.
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Russell King - ARM Linux admin @ 2020-06-17 12:08 UTC (permalink / raw)
To: Helmut Grohne
Cc: Nicolas Ferre, David S. Miller, Jakub Kicinski, Palmer Dabbelt,
Paul Walmsley, netdev@vger.kernel.org
In-Reply-To: <20200617115201.GA30172@laureti-dev>
On Wed, Jun 17, 2020 at 01:52:01PM +0200, Helmut Grohne wrote:
> On Wed, Jun 17, 2020 at 01:40:25PM +0200, Russell King - ARM Linux admin wrote:
> > > For a fixed-link, the validation function is never called. Therefore, it
> > > cannot reject PHY_INTERFACE_MODE_RGMII. It works in practice.
> >
> > Hmm, I'm not so sure, but then I don't know exactly what code you're
> > using. Looking at mainline, even for a fixed link, you call
> > phylink_create(). phylink_create() will spot the fixed link, and
> > parse the description, calling the validation function. If that
> > fails, it will generate a warning at that point:
> >
> > "fixed link %s duplex %dMbps not recognised"
> >
> > It doesn't cause an operational failure, but it means that you end up
> > with a zero supported mask, which is likely not expected.
> >
> > This is not an expected situation, so I'll modify your claim to "it
> > works but issues a warning" which still means that it's not correct.
>
> I do see that warning. I agree with your correction of my claim. Thank
> you for your attention to detail.
>
> So we have two good reasons for not rejecting delay configuration in the
> validation function now.
>
> The remaining open question seems to be whether configuring a delay on a
> MAC to MAC connection should cause a failure or a only warning. Do you
> have an opinion on that?
>
> All in-tree bindings of the driver seem to use rmii when they specify a
> phy-mode.
This brings up a problem in itself - the phy interface mode is
currently defined in terms of a MAC-to-PHY setup, not a MAC-to-MAC
setup.
With a fixed link, we could be in either a MAC-to-PHY or MAC-to-MAC
setup; we just don't know. However, we don't have is access to the
PHY (if it exists) in the fixed link case to configure it for the
delay.
In the MAC-to-MAC RGMII setup, where neither MAC can insert the
necessary delay, the only way to have a RGMII conformant link is to
have the PCB traces induce the necessary delay. That errs towards
PHY_INTERFACE_MODE_RGMII for this case.
However, considering the MAC-to-PHY RGMII fixed link case, where the
PHY may not be accessible, and may be configured with the necessary
delay, should that case also use PHY_INTERFACE_MODE_RGMII - clearly
that would be as wrong as using PHY_INTERFACE_MODE_RGMII_ID would
be for the MAC-to-MAC RGMII with PCB-delays case.
So, I think a MAC driver should not care about the specific RGMII
mode being asked for in any case, and just accept them all.
I also think that some of this ought to be put in the documentation
as guidance for new implementations.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Russell King - ARM Linux admin @ 2020-06-17 11:57 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Helmut Grohne, Nicolas Ferre, David S. Miller, Jakub Kicinski,
Palmer Dabbelt, Paul Walmsley, netdev
In-Reply-To: <CA+h21hqrDd6FLS7vhBW6GUdi8MvimiisyEbQLE0ZfasoQ1EQbw@mail.gmail.com>
On Wed, Jun 17, 2020 at 02:38:25PM +0300, Vladimir Oltean wrote:
> On Wed, 17 Jun 2020 at 14:34, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
>
> >
> > Why are you so abrasive?
> >
> > Not responding to this until you start behaving more reasonably.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>
> Sorry.
> What I meant to say is: the documentation is unclear. It has been
> interpreted in conflicting ways, where the strict interpretations have
> proven to have practical limitations, and the practical
> interpretations have been accused of being incorrect. In my opinion
> there is no way to fix it without introducing new bindings, which I am
> not sure is really worth doing.
The documentation was added in 2016, many years after we have had users
of this, in an attempt to clear up some of the confusion. It is likely
that it had to cater for existing users though - I'm sure if Florian
cares, he can comment on that.
It would be better if it made a definitive statement about it, but doing
so would likely attract pedants to try to fix everything to conform,
causing breakage in the process.
I've recently had a painful experience of this with the Atheros PHYs,
where there are lots of platforms using "rgmii" when they should have
been using "rgmii-id". A patch changed this in the Atheros code breaking
all these platforms, breakage which persisted over several kernel
versions, needing fixes to DT files that then had to be back-ported.
That's fine if you know what happened to break it, but if you don't, and
you don't know what the fix is, you're mostly stuffed and stuck with non-
working ethernet. That really was not nice.
This is one of the reasons why I press for any new PHY interface mode
to be documented in the phylib documentation right from the start, so
that hopefully we can avoid this kind of thing in the future.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Helmut Grohne @ 2020-06-17 11:52 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Nicolas Ferre, David S. Miller, Jakub Kicinski, Palmer Dabbelt,
Paul Walmsley, netdev@vger.kernel.org
In-Reply-To: <20200617114025.GQ1551@shell.armlinux.org.uk>
On Wed, Jun 17, 2020 at 01:40:25PM +0200, Russell King - ARM Linux admin wrote:
> > For a fixed-link, the validation function is never called. Therefore, it
> > cannot reject PHY_INTERFACE_MODE_RGMII. It works in practice.
>
> Hmm, I'm not so sure, but then I don't know exactly what code you're
> using. Looking at mainline, even for a fixed link, you call
> phylink_create(). phylink_create() will spot the fixed link, and
> parse the description, calling the validation function. If that
> fails, it will generate a warning at that point:
>
> "fixed link %s duplex %dMbps not recognised"
>
> It doesn't cause an operational failure, but it means that you end up
> with a zero supported mask, which is likely not expected.
>
> This is not an expected situation, so I'll modify your claim to "it
> works but issues a warning" which still means that it's not correct.
I do see that warning. I agree with your correction of my claim. Thank
you for your attention to detail.
So we have two good reasons for not rejecting delay configuration in the
validation function now.
The remaining open question seems to be whether configuring a delay on a
MAC to MAC connection should cause a failure or a only warning. Do you
have an opinion on that?
All in-tree bindings of the driver seem to use rmii when they specify a
phy-mode.
Helmut
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Russell King - ARM Linux admin @ 2020-06-17 11:40 UTC (permalink / raw)
To: Helmut Grohne
Cc: Nicolas Ferre, David S. Miller, Jakub Kicinski, Palmer Dabbelt,
Paul Walmsley, netdev@vger.kernel.org
In-Reply-To: <20200617112153.GB28783@laureti-dev>
On Wed, Jun 17, 2020 at 01:21:53PM +0200, Helmut Grohne wrote:
> On Wed, Jun 17, 2020 at 12:55:18PM +0200, Russell King - ARM Linux admin wrote:
> > The individual RGMII delay modes are more about what the PHY itself is
> > asked to do with respect to inserting delays, so I don't think your
> > patch makes sense.
>
> This seems to be the same aspect that Vladimir Oltean remarked. I agree
> that the relevant hunk should be dropped.
>
> > > --- a/drivers/net/ethernet/cadence/macb_main.c
> > > +++ b/drivers/net/ethernet/cadence/macb_main.c
> > > @@ -514,7 +514,7 @@ static void macb_validate(struct phylink_config *config,
> > > state->interface != PHY_INTERFACE_MODE_RMII &&
> > > state->interface != PHY_INTERFACE_MODE_GMII &&
> > > state->interface != PHY_INTERFACE_MODE_SGMII &&
> > > - !phy_interface_mode_is_rgmii(state->interface)) {
> > > + state->interface != PHY_INTERFACE_MODE_RGMII_ID) {
> >
> > Here you reject everything except PHY_INTERFACE_MODE_RGMII_ID.
> >
> > > bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> > > return;
> > > }
> > > @@ -694,6 +694,13 @@ static int macb_phylink_connect(struct macb *bp)
> > > struct phy_device *phydev;
> > > int ret;
> > >
> > > + if (of_phy_is_fixed_link(dn) &&
> > > + phy_interface_mode_is_rgmii(bp->phy_interface) &&
> > > + bp->phy_interface != PHY_INTERFACE_MODE_RGMII) {
> >
> > but here you reject everything except PHY_INTERFACE_MODE_RGMII. These
> > can't both be right. If you start with PHY_INTERFACE_MODE_RGMII, and
> > have a fixed link, you'll have PHY_INTERFACE_MODE_RGMII passed into
> > the validate function, which will then fail.
>
> For a fixed-link, the validation function is never called. Therefore, it
> cannot reject PHY_INTERFACE_MODE_RGMII. It works in practice.
Hmm, I'm not so sure, but then I don't know exactly what code you're
using. Looking at mainline, even for a fixed link, you call
phylink_create(). phylink_create() will spot the fixed link, and
parse the description, calling the validation function. If that
fails, it will generate a warning at that point:
"fixed link %s duplex %dMbps not recognised"
It doesn't cause an operational failure, but it means that you end up
with a zero supported mask, which is likely not expected.
This is not an expected situation, so I'll modify your claim to "it
works but issues a warning" which still means that it's not correct.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Vladimir Oltean @ 2020-06-17 11:38 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Helmut Grohne, Nicolas Ferre, David S. Miller, Jakub Kicinski,
Palmer Dabbelt, Paul Walmsley, netdev
In-Reply-To: <20200617113410.GP1551@shell.armlinux.org.uk>
On Wed, 17 Jun 2020 at 14:34, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
>
> Why are you so abrasive?
>
> Not responding to this until you start behaving more reasonably.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Sorry.
What I meant to say is: the documentation is unclear. It has been
interpreted in conflicting ways, where the strict interpretations have
proven to have practical limitations, and the practical
interpretations have been accused of being incorrect. In my opinion
there is no way to fix it without introducing new bindings, which I am
not sure is really worth doing.
Thanks,
-Vladimir
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Russell King - ARM Linux admin @ 2020-06-17 11:34 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Helmut Grohne, Nicolas Ferre, David S. Miller, Jakub Kicinski,
Palmer Dabbelt, Paul Walmsley, netdev
In-Reply-To: <CA+h21hotpF58RrKsZsET9XT-vVD3EHPZ=kjQ2mKVT2ix5XAt=A@mail.gmail.com>
On Wed, Jun 17, 2020 at 02:32:09PM +0300, Vladimir Oltean wrote:
> On Wed, 17 Jun 2020 at 13:56, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Tue, Jun 16, 2020 at 09:49:56AM +0200, Helmut Grohne wrote:
> > > The macb driver does not support configuring rgmii delays. At least for
> > > the Zynq GEM, delays are not supported by the hardware at all. However,
> > > the driver happily accepts and ignores any such delays.
> > >
> > > When operating in a mac to phy connection, the delay setting applies to
> > > the phy. Since the MAC does not support delays, the phy must provide
> > > them and the only supported mode is rgmii-id. However, in a fixed mac
> > > to mac connection, the delay applies to the mac itself. Therefore the
> > > only supported rgmii mode is rgmii.
> >
> > This seems incorrect - see the phy documentation in
> > Documentation/networking/phy.rst:
> >
> > * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
> > internal delay by itself, it assumes that either the Ethernet MAC (if capable
> > or the PCB traces) insert the correct 1.5-2ns delay
> >
> > * PHY_INTERFACE_MODE_RGMII_TXID: the PHY should insert an internal delay
> > for the transmit data lines (TXD[3:0]) processed by the PHY device
> >
> > * PHY_INTERFACE_MODE_RGMII_RXID: the PHY should insert an internal delay
> > for the receive data lines (RXD[3:0]) processed by the PHY device
> >
> > * PHY_INTERFACE_MODE_RGMII_ID: the PHY should insert internal delays for
> > both transmit AND receive data lines from/to the PHY device
> >
> > Note that PHY_INTERFACE_MODE_RGMII, the delay can be added by _either_
> > the MAC or by PCB trace routing.
> >
>
> What does it mean "can" be added? Is it or is it not added? As a MAC
> driver, what do you do?
I'm just stating what is documented.
> > The individual RGMII delay modes are more about what the PHY itself is
> > asked to do with respect to inserting delays, so I don't think your
> > patch makes sense.
> >
>
> We all read the phy-mode documentation, but we aren't really any
> smarter. That document completely fails to address the existence of
> PCB traces.
> Helmut's link points to some more discussion around this topic.
Why are you so abrasive?
Not responding to this until you start behaving more reasonably.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Vladimir Oltean @ 2020-06-17 11:32 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Helmut Grohne, Nicolas Ferre, David S. Miller, Jakub Kicinski,
Palmer Dabbelt, Paul Walmsley, netdev
In-Reply-To: <20200617105518.GO1551@shell.armlinux.org.uk>
On Wed, 17 Jun 2020 at 13:56, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, Jun 16, 2020 at 09:49:56AM +0200, Helmut Grohne wrote:
> > The macb driver does not support configuring rgmii delays. At least for
> > the Zynq GEM, delays are not supported by the hardware at all. However,
> > the driver happily accepts and ignores any such delays.
> >
> > When operating in a mac to phy connection, the delay setting applies to
> > the phy. Since the MAC does not support delays, the phy must provide
> > them and the only supported mode is rgmii-id. However, in a fixed mac
> > to mac connection, the delay applies to the mac itself. Therefore the
> > only supported rgmii mode is rgmii.
>
> This seems incorrect - see the phy documentation in
> Documentation/networking/phy.rst:
>
> * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
> internal delay by itself, it assumes that either the Ethernet MAC (if capable
> or the PCB traces) insert the correct 1.5-2ns delay
>
> * PHY_INTERFACE_MODE_RGMII_TXID: the PHY should insert an internal delay
> for the transmit data lines (TXD[3:0]) processed by the PHY device
>
> * PHY_INTERFACE_MODE_RGMII_RXID: the PHY should insert an internal delay
> for the receive data lines (RXD[3:0]) processed by the PHY device
>
> * PHY_INTERFACE_MODE_RGMII_ID: the PHY should insert internal delays for
> both transmit AND receive data lines from/to the PHY device
>
> Note that PHY_INTERFACE_MODE_RGMII, the delay can be added by _either_
> the MAC or by PCB trace routing.
>
What does it mean "can" be added? Is it or is it not added? As a MAC
driver, what do you do?
> The individual RGMII delay modes are more about what the PHY itself is
> asked to do with respect to inserting delays, so I don't think your
> patch makes sense.
>
We all read the phy-mode documentation, but we aren't really any
smarter. That document completely fails to address the existence of
PCB traces.
Helmut's link points to some more discussion around this topic.
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Michal Hocko @ 2020-06-17 11:31 UTC (permalink / raw)
To: Matthew Wilcox
Cc: dsterba, Joe Perches, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
David Rientjes, Johannes Weiner, Dan Carpenter,
Jason A . Donenfeld, linux-mm, keyrings, linux-kernel,
linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200617110820.GG8681@bombadil.infradead.org>
On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote:
> > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote:
> > > Not just performance critical, but correctness critical. Since kvfree()
> > > may allocate from the vmalloc allocator, I really think that kvfree()
> > > should assert that it's !in_atomic(). Otherwise we can get into trouble
> > > if we end up calling vfree() and have to take the mutex.
> >
> > FWIW __vfree already checks for atomic context and put the work into a
> > deferred context. So this should be safe. It should be used as a last
> > resort, though.
>
> Actually, it only checks for in_interrupt().
You are right. I have misremembered. You have made me look (thanks) ...
> If you call vfree() under
> a spinlock, you're in trouble. in_atomic() only knows if we hold a
> spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
> in __vfree(). So we need the warning in order that preempt people can
> tell those without that there is a bug here.
... Unless I am missing something in_interrupt depends on preempt_count() as
well so neither of the two is reliable without PREEMPT_COUNT configured.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Helmut Grohne @ 2020-06-17 11:21 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Nicolas Ferre, David S. Miller, Jakub Kicinski, Palmer Dabbelt,
Paul Walmsley, netdev@vger.kernel.org
In-Reply-To: <20200617105518.GO1551@shell.armlinux.org.uk>
On Wed, Jun 17, 2020 at 12:55:18PM +0200, Russell King - ARM Linux admin wrote:
> The individual RGMII delay modes are more about what the PHY itself is
> asked to do with respect to inserting delays, so I don't think your
> patch makes sense.
This seems to be the same aspect that Vladimir Oltean remarked. I agree
that the relevant hunk should be dropped.
> > --- a/drivers/net/ethernet/cadence/macb_main.c
> > +++ b/drivers/net/ethernet/cadence/macb_main.c
> > @@ -514,7 +514,7 @@ static void macb_validate(struct phylink_config *config,
> > state->interface != PHY_INTERFACE_MODE_RMII &&
> > state->interface != PHY_INTERFACE_MODE_GMII &&
> > state->interface != PHY_INTERFACE_MODE_SGMII &&
> > - !phy_interface_mode_is_rgmii(state->interface)) {
> > + state->interface != PHY_INTERFACE_MODE_RGMII_ID) {
>
> Here you reject everything except PHY_INTERFACE_MODE_RGMII_ID.
>
> > bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> > return;
> > }
> > @@ -694,6 +694,13 @@ static int macb_phylink_connect(struct macb *bp)
> > struct phy_device *phydev;
> > int ret;
> >
> > + if (of_phy_is_fixed_link(dn) &&
> > + phy_interface_mode_is_rgmii(bp->phy_interface) &&
> > + bp->phy_interface != PHY_INTERFACE_MODE_RGMII) {
>
> but here you reject everything except PHY_INTERFACE_MODE_RGMII. These
> can't both be right. If you start with PHY_INTERFACE_MODE_RGMII, and
> have a fixed link, you'll have PHY_INTERFACE_MODE_RGMII passed into
> the validate function, which will then fail.
For a fixed-link, the validation function is never called. Therefore, it
cannot reject PHY_INTERFACE_MODE_RGMII. It works in practice.
However, the consensus is to not reject that mode in the validation
function.
Helmut
^ permalink raw reply
* Re: [PATCH] net: macb: reject unsupported rgmii delays
From: Helmut Grohne @ 2020-06-17 11:15 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Nicolas Ferre, David S. Miller, Jakub Kicinski, Russell King,
Palmer Dabbelt, Paul Walmsley, netdev
In-Reply-To: <CA+h21hoTQzGwF5wYx3-0Fa_rUYWw+m2CVcBV8WUQ7OtK3DHpQA@mail.gmail.com>
Hi Vladimir,
On Wed, Jun 17, 2020 at 11:57:23AM +0200, Vladimir Oltean wrote:
> On Tue, 16 Jun 2020 at 11:00, Helmut Grohne <helmut.grohne@intenta.de> wrote:
> > --- a/drivers/net/ethernet/cadence/macb_main.c
> > +++ b/drivers/net/ethernet/cadence/macb_main.c
> > @@ -514,7 +514,7 @@ static void macb_validate(struct phylink_config *config,
> > state->interface != PHY_INTERFACE_MODE_RMII &&
> > state->interface != PHY_INTERFACE_MODE_GMII &&
> > state->interface != PHY_INTERFACE_MODE_SGMII &&
> > - !phy_interface_mode_is_rgmii(state->interface)) {
> > + state->interface != PHY_INTERFACE_MODE_RGMII_ID) {
>
> I don't think this change is correct though?
> What if there were PCB traces in place, for whatever reason? Then the
> driver would need to accept a phy with rgmii-txid, rgmii-rxid or
> rgmii.
I must confess that after rereading the discussion and the other
discussions at
https://patchwork.ozlabs.org/project/netdev/patch/20190410005700.31582-19-olteanv@gmail.com/
and
https://patchwork.ozlabs.org/project/netdev/patch/20190413012822.30931-21-olteanv@gmail.com/,
this is less and less clear to me.
I think we can agree that the current definition of phy-mode is
confusing when it comes to rgmii delays. The documentation doesn't even
mention the possibility of using serpentines.
Your interpretation seems to be that this value is solely meant for the
PHY to operate on and that the MAC should not act upon it (at least the
delay part). That interpetation is consistent with previous discussions
and mostly consistent with the documentation. The phy-mode property is
documented in ethernet-controller.yaml, which suggests that it should
apply to the MAC somehow.
Following this interpretation, I think it would be good to also document
it in ethernet-phy.yaml.
Thank you for the review. I agree that the hunk should be dropped.
However, in the fixed-link case (below) the interpretation regarding
serpentines seems to be well-defined: If serpentines are present, both
MACs should specify rgmii.
> > bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> > return;
> > }
> > @@ -694,6 +694,13 @@ static int macb_phylink_connect(struct macb *bp)
> > struct phy_device *phydev;
> > int ret;
> >
> > + if (of_phy_is_fixed_link(dn) &&
> > + phy_interface_mode_is_rgmii(bp->phy_interface) &&
> > + bp->phy_interface != PHY_INTERFACE_MODE_RGMII) {
> > + netdev_err(dev, "RGMII delays are not supported\n");
> > + return -EINVAL;
> > + }
> > +
>
> Have you checked that this doesn't break any existing in-tree users?
It seems like all the in-tree users of this driver that do specify a
phy-mode, specify rmii.
If possible breakage is to be minimized, I'd be happy with using
netdev_warn instead. The major benefit here is getting a clear
indication of why things don't work. My emphasis is on getting something
to dmesg, not to make things fail.
So what should we prefer here? Failure or warning?
In the long run, it would be nice to refactor the way to denote delays
in a way that is consistently defined for MAC to PHY and MAC to MAC
connections while accounting for serpentines.
Helmut
^ permalink raw reply
* net-next test error: KASAN: use-after-free Write in afs_wake_up_async_call
From: syzbot @ 2020-06-17 11:14 UTC (permalink / raw)
To: davem, dhowells, kuba, linux-afs, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 69119673 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=151b62f1100000
kernel config: https://syzkaller.appspot.com/x/.config?x=b8ad29058cb749bc
dashboard link: https://syzkaller.appspot.com/bug?extid=d3eccef36ddbd02713e9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d3eccef36ddbd02713e9@syzkaller.appspotmail.com
tipc: TX() has been purged, node left!
==================================================================
BUG: KASAN: use-after-free in afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707
Write of size 1 at addr ffff8880946c39e4 by task kworker/u4:1/21
CPU: 0 PID: 21 Comm: kworker/u4:1 Not tainted 5.8.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707
rxrpc_notify_socket+0x1db/0x5d0 net/rxrpc/recvmsg.c:40
__rxrpc_set_call_completion.part.0+0x172/0x410 net/rxrpc/recvmsg.c:76
__rxrpc_call_completed net/rxrpc/recvmsg.c:112 [inline]
rxrpc_call_completed+0xca/0xf0 net/rxrpc/recvmsg.c:111
rxrpc_discard_prealloc+0x781/0xab0 net/rxrpc/call_accept.c:233
rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245
afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110
afs_net_exit+0x1bc/0x310 fs/afs/main.c:155
ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186
cleanup_net+0x511/0xa50 net/core/net_namespace.c:603
process_one_work+0x965/0x1690 kernel/workqueue.c:2269
worker_thread+0x96/0xe10 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Allocated by task 6820:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
kmem_cache_alloc_trace+0x153/0x7d0 mm/slab.c:3551
kmalloc include/linux/slab.h:555 [inline]
kzalloc include/linux/slab.h:669 [inline]
afs_alloc_call+0x55/0x630 fs/afs/rxrpc.c:141
afs_charge_preallocation+0xe9/0x2d0 fs/afs/rxrpc.c:757
afs_open_socket+0x292/0x360 fs/afs/rxrpc.c:92
afs_net_init+0xa6c/0xe30 fs/afs/main.c:125
ops_init+0xaf/0x420 net/core/net_namespace.c:151
setup_net+0x2de/0x860 net/core/net_namespace.c:341
copy_net_ns+0x293/0x590 net/core/net_namespace.c:482
create_new_namespaces+0x3fb/0xb30 kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231
ksys_unshare+0x43d/0x8e0 kernel/fork.c:2983
__do_sys_unshare kernel/fork.c:3051 [inline]
__se_sys_unshare kernel/fork.c:3049 [inline]
__x64_sys_unshare+0x2d/0x40 kernel/fork.c:3049
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 21:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
kasan_set_free_info mm/kasan/common.c:316 [inline]
__kasan_slab_free+0xf7/0x140 mm/kasan/common.c:455
__cache_free mm/slab.c:3426 [inline]
kfree+0x109/0x2b0 mm/slab.c:3757
afs_put_call+0x585/0xa40 fs/afs/rxrpc.c:190
rxrpc_discard_prealloc+0x764/0xab0 net/rxrpc/call_accept.c:230
rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245
afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110
afs_net_exit+0x1bc/0x310 fs/afs/main.c:155
ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186
cleanup_net+0x511/0xa50 net/core/net_namespace.c:603
process_one_work+0x965/0x1690 kernel/workqueue.c:2269
worker_thread+0x96/0xe10 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
The buggy address belongs to the object at ffff8880946c3800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 484 bytes inside of
1024-byte region [ffff8880946c3800, ffff8880946c3c00)
The buggy address belongs to the page:
page:ffffea000251b0c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002546508 ffffea00024fa248 ffff8880aa000c40
raw: 0000000000000000 ffff8880946c3000 0000000100000002 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880946c3880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880946c3900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880946c3980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880946c3a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880946c3a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* net test error: KASAN: use-after-free Write in afs_wake_up_async_call
From: syzbot @ 2020-06-17 11:14 UTC (permalink / raw)
To: davem, dhowells, kuba, linux-afs, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 69119673 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1054fc4e100000
kernel config: https://syzkaller.appspot.com/x/.config?x=b8ad29058cb749bc
dashboard link: https://syzkaller.appspot.com/bug?extid=5e590d73a9d01be6b1a1
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5e590d73a9d01be6b1a1@syzkaller.appspotmail.com
tipc: TX() has been purged, node left!
==================================================================
BUG: KASAN: use-after-free in afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707
Write of size 1 at addr ffff888096b199e4 by task kworker/u4:6/262
CPU: 1 PID: 262 Comm: kworker/u4:6 Not tainted 5.8.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707
rxrpc_notify_socket+0x1db/0x5d0 net/rxrpc/recvmsg.c:40
__rxrpc_set_call_completion.part.0+0x172/0x410 net/rxrpc/recvmsg.c:76
__rxrpc_call_completed net/rxrpc/recvmsg.c:112 [inline]
rxrpc_call_completed+0xca/0xf0 net/rxrpc/recvmsg.c:111
rxrpc_discard_prealloc+0x781/0xab0 net/rxrpc/call_accept.c:233
rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245
afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110
afs_net_exit+0x1bc/0x310 fs/afs/main.c:155
ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186
cleanup_net+0x511/0xa50 net/core/net_namespace.c:603
process_one_work+0x965/0x1690 kernel/workqueue.c:2269
worker_thread+0x96/0xe10 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Allocated by task 6821:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
kmem_cache_alloc_trace+0x153/0x7d0 mm/slab.c:3551
kmalloc include/linux/slab.h:555 [inline]
kzalloc include/linux/slab.h:669 [inline]
afs_alloc_call+0x55/0x630 fs/afs/rxrpc.c:141
afs_charge_preallocation+0xe9/0x2d0 fs/afs/rxrpc.c:757
afs_open_socket+0x292/0x360 fs/afs/rxrpc.c:92
afs_net_init+0xa6c/0xe30 fs/afs/main.c:125
ops_init+0xaf/0x420 net/core/net_namespace.c:151
setup_net+0x2de/0x860 net/core/net_namespace.c:341
copy_net_ns+0x293/0x590 net/core/net_namespace.c:482
create_new_namespaces+0x3fb/0xb30 kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231
ksys_unshare+0x43d/0x8e0 kernel/fork.c:2983
__do_sys_unshare kernel/fork.c:3051 [inline]
__se_sys_unshare kernel/fork.c:3049 [inline]
__x64_sys_unshare+0x2d/0x40 kernel/fork.c:3049
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 262:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
kasan_set_free_info mm/kasan/common.c:316 [inline]
__kasan_slab_free+0xf7/0x140 mm/kasan/common.c:455
__cache_free mm/slab.c:3426 [inline]
kfree+0x109/0x2b0 mm/slab.c:3757
afs_put_call+0x585/0xa40 fs/afs/rxrpc.c:190
rxrpc_discard_prealloc+0x764/0xab0 net/rxrpc/call_accept.c:230
rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245
afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110
afs_net_exit+0x1bc/0x310 fs/afs/main.c:155
ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186
cleanup_net+0x511/0xa50 net/core/net_namespace.c:603
process_one_work+0x965/0x1690 kernel/workqueue.c:2269
worker_thread+0x96/0xe10 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
The buggy address belongs to the object at ffff888096b19800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 484 bytes inside of
1024-byte region [ffff888096b19800, ffff888096b19c00)
The buggy address belongs to the page:
page:ffffea00025ac640 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea00025df7c8 ffffea000261efc8 ffff8880aa000c40
raw: 0000000000000000 ffff888096b19000 0000000100000002 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888096b19880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888096b19900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888096b19980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888096b19a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888096b19a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* [v2][PATCH] e1000e: continue to init phy even when failed to disable ULP
From: Aaron Ma @ 2020-06-17 11:12 UTC (permalink / raw)
To: jeffrey.t.kirsher, davem, kuba, intel-wired-lan, netdev,
linux-kernel, vitaly.lifshits, kai.heng.feng, sasha.neftin
In-Reply-To: <20200616100512.22512-1-aaron.ma@canonical.com>
After commit: e086ba2fccd ("e1000e: disable s0ix entry and exit flows
for ME systems").
ThinkPad P14s always failed to disable ULP by ME.
commit: 0c80cdbf33 ("e1000e: Warn if disabling ULP failed")
break out of init phy:
error log:
[ 42.364753] e1000e 0000:00:1f.6 enp0s31f6: Failed to disable ULP
[ 42.524626] e1000e 0000:00:1f.6 enp0s31f6: PHY Wakeup cause - Unicast Packet
[ 42.822476] e1000e 0000:00:1f.6 enp0s31f6: Hardware Error
When disable s0ix, E1000_FWSM_ULP_CFG_DONE will never be 1.
If continue to init phy like before, it can work as before.
iperf test result good too.
Fixes: 0c80cdbf33 ("e1000e: Warn if disabling ULP failed")
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index f999cca37a8a..be7475c5529d 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -303,7 +303,6 @@ static s32 e1000_init_phy_workarounds_pchlan(struct e1000_hw *hw)
ret_val = e1000_disable_ulp_lpt_lp(hw, true);
if (ret_val) {
e_warn("Failed to disable ULP\n");
- goto out;
}
ret_val = hw->phy.ops.acquire(hw);
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Matthew Wilcox @ 2020-06-17 11:08 UTC (permalink / raw)
To: Michal Hocko
Cc: dsterba, Joe Perches, Waiman Long, Andrew Morton, David Howells,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds,
David Rientjes, Johannes Weiner, Dan Carpenter,
Jason A . Donenfeld, linux-mm, keyrings, linux-kernel,
linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200617071212.GJ9499@dhcp22.suse.cz>
On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote:
> On Tue 16-06-20 17:37:11, Matthew Wilcox wrote:
> > Not just performance critical, but correctness critical. Since kvfree()
> > may allocate from the vmalloc allocator, I really think that kvfree()
> > should assert that it's !in_atomic(). Otherwise we can get into trouble
> > if we end up calling vfree() and have to take the mutex.
>
> FWIW __vfree already checks for atomic context and put the work into a
> deferred context. So this should be safe. It should be used as a last
> resort, though.
Actually, it only checks for in_interrupt(). If you call vfree() under
a spinlock, you're in trouble. in_atomic() only knows if we hold a
spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic()
in __vfree(). So we need the warning in order that preempt people can
tell those without that there is a bug here.
^ permalink raw reply
* [PATCH bpf-next v4 3/3] bpf: add SO_KEEPALIVE and related options to bpf_setsockopt
From: Dmitry Yakunin @ 2020-06-17 11:02 UTC (permalink / raw)
To: daniel, alexei.starovoitov
Cc: davem, brakmo, eric.dumazet, kafai, bpf, netdev
In-Reply-To: <20200617110217.35669-1-zeil@yandex-team.ru>
This patch adds support of SO_KEEPALIVE flag and TCP related options
to bpf_setsockopt() routine. This is helpful if we want to enable or tune
TCP keepalive for applications which don't do it in the userspace code.
v2:
- update kernel-doc (Nikita Vetoshkin <nekto0n@yandex-team.ru>)
Signed-off-by: Dmitry Yakunin <zeil@yandex-team.ru>
Acked-by: Martin KaFai Lau <kafai@fb.com>
---
include/uapi/linux/bpf.h | 7 +++++--
net/core/filter.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index b9ed9f1..3b8815d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1621,10 +1621,13 @@ union bpf_attr {
*
* * **SOL_SOCKET**, which supports the following *optname*\ s:
* **SO_RCVBUF**, **SO_SNDBUF**, **SO_MAX_PACING_RATE**,
- * **SO_PRIORITY**, **SO_RCVLOWAT**, **SO_MARK**.
+ * **SO_PRIORITY**, **SO_RCVLOWAT**, **SO_MARK**,
+ * **SO_BINDTODEVICE**, **SO_KEEPALIVE**.
* * **IPPROTO_TCP**, which supports the following *optname*\ s:
* **TCP_CONGESTION**, **TCP_BPF_IW**,
- * **TCP_BPF_SNDCWND_CLAMP**.
+ * **TCP_BPF_SNDCWND_CLAMP**, **TCP_SAVE_SYN**,
+ * **TCP_KEEPIDLE**, **TCP_KEEPINTVL**, **TCP_KEEPCNT**,
+ * **TCP_SYNCNT**, **TCP_USER_TIMEOUT**.
* * **IPPROTO_IP**, which supports *optname* **IP_TOS**.
* * **IPPROTO_IPV6**, which supports *optname* **IPV6_TCLASS**.
* Return
diff --git a/net/core/filter.c b/net/core/filter.c
index ae82bcb..674272c 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -4249,10 +4249,10 @@ static int _bpf_setsockopt(struct sock *sk, int level, int optname,
char *optval, int optlen, u32 flags)
{
char devname[IFNAMSIZ];
+ int val, valbool;
struct net *net;
int ifindex;
int ret = 0;
- int val;
if (!sk_fullsock(sk))
return -EINVAL;
@@ -4263,6 +4263,7 @@ static int _bpf_setsockopt(struct sock *sk, int level, int optname,
if (optlen != sizeof(int) && optname != SO_BINDTODEVICE)
return -EINVAL;
val = *((int *)optval);
+ valbool = val ? 1 : 0;
/* Only some socketops are supported */
switch (optname) {
@@ -4324,6 +4325,11 @@ static int _bpf_setsockopt(struct sock *sk, int level, int optname,
ret = sock_bindtoindex(sk, ifindex, false);
#endif
break;
+ case SO_KEEPALIVE:
+ if (sk->sk_prot->keepalive)
+ sk->sk_prot->keepalive(sk, valbool);
+ sock_valbool_flag(sk, SOCK_KEEPOPEN, valbool);
+ break;
default:
ret = -EINVAL;
}
@@ -4384,6 +4390,7 @@ static int _bpf_setsockopt(struct sock *sk, int level, int optname,
ret = tcp_set_congestion_control(sk, name, false,
reinit, true);
} else {
+ struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
if (optlen != sizeof(int))
@@ -4412,6 +4419,33 @@ static int _bpf_setsockopt(struct sock *sk, int level, int optname,
else
tp->save_syn = val;
break;
+ case TCP_KEEPIDLE:
+ ret = tcp_sock_set_keepidle_locked(sk, val);
+ break;
+ case TCP_KEEPINTVL:
+ if (val < 1 || val > MAX_TCP_KEEPINTVL)
+ ret = -EINVAL;
+ else
+ tp->keepalive_intvl = val * HZ;
+ break;
+ case TCP_KEEPCNT:
+ if (val < 1 || val > MAX_TCP_KEEPCNT)
+ ret = -EINVAL;
+ else
+ tp->keepalive_probes = val;
+ break;
+ case TCP_SYNCNT:
+ if (val < 1 || val > MAX_TCP_SYNCNT)
+ ret = -EINVAL;
+ else
+ icsk->icsk_syn_retries = val;
+ break;
+ case TCP_USER_TIMEOUT:
+ if (val < 0)
+ ret = -EINVAL;
+ else
+ icsk->icsk_user_timeout = val;
+ break;
default:
ret = -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH bpf-next v4 1/3] sock: move sock_valbool_flag to header
From: Dmitry Yakunin @ 2020-06-17 11:02 UTC (permalink / raw)
To: daniel, alexei.starovoitov
Cc: davem, brakmo, eric.dumazet, kafai, bpf, netdev
This is preparation for usage in bpf_setsockopt.
Signed-off-by: Dmitry Yakunin <zeil@yandex-team.ru>
Acked-by: Martin KaFai Lau <kafai@fb.com>
---
include/net/sock.h | 9 +++++++++
net/core/sock.c | 9 ---------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index c53cc42..8ba438b 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -879,6 +879,15 @@ static inline void sock_reset_flag(struct sock *sk, enum sock_flags flag)
__clear_bit(flag, &sk->sk_flags);
}
+static inline void sock_valbool_flag(struct sock *sk, enum sock_flags bit,
+ int valbool)
+{
+ if (valbool)
+ sock_set_flag(sk, bit);
+ else
+ sock_reset_flag(sk, bit);
+}
+
static inline bool sock_flag(const struct sock *sk, enum sock_flags flag)
{
return test_bit(flag, &sk->sk_flags);
diff --git a/net/core/sock.c b/net/core/sock.c
index 6c4acf1..5ba4753 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -695,15 +695,6 @@ static int sock_getbindtodevice(struct sock *sk, char __user *optval,
return ret;
}
-static inline void sock_valbool_flag(struct sock *sk, enum sock_flags bit,
- int valbool)
-{
- if (valbool)
- sock_set_flag(sk, bit);
- else
- sock_reset_flag(sk, bit);
-}
-
bool sk_mc_loop(struct sock *sk)
{
if (dev_recursion_level())
--
2.7.4
^ permalink raw reply related
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