* [PATCH net-next v2 05/10] r8169: use phy_ethtool_nway_reset
From: Heiner Kallweit @ 2018-07-10 18:39 UTC (permalink / raw)
To: David Miller, Florian Fainelli, Andrew Lunn,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <84ac1cb7-bafd-5f15-8cda-e8dfd7d0deb3@gmail.com>
Switch to using phy_ethtool_nway_reset().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/ethernet/realtek/Kconfig | 1 -
drivers/net/ethernet/realtek/r8169.c | 9 +--------
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig
index 7fb1af1f..e1cd934c 100644
--- a/drivers/net/ethernet/realtek/Kconfig
+++ b/drivers/net/ethernet/realtek/Kconfig
@@ -100,7 +100,6 @@ config R8169
select FW_LOADER
select CRC32
select PHYLIB
- select MII
---help---
Say Y here if you have a Realtek 8169 PCI Gigabit Ethernet adapter.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 5282e413..f0aa1b54 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1984,13 +1984,6 @@ static void rtl8169_get_strings(struct net_device *dev, u32 stringset, u8 *data)
}
}
-static int rtl8169_nway_reset(struct net_device *dev)
-{
- struct rtl8169_private *tp = netdev_priv(dev);
-
- return mii_nway_restart(&tp->mii);
-}
-
/*
* Interrupt coalescing
*
@@ -2221,7 +2214,7 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
.get_sset_count = rtl8169_get_sset_count,
.get_ethtool_stats = rtl8169_get_ethtool_stats,
.get_ts_info = ethtool_op_get_ts_info,
- .nway_reset = rtl8169_nway_reset,
+ .nway_reset = phy_ethtool_nway_reset,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = phy_ethtool_set_link_ksettings,
};
--
2.18.0
^ permalink raw reply related
* [PATCH net-next v2 06/10] r8169: use phy_mii_ioctl
From: Heiner Kallweit @ 2018-07-10 18:39 UTC (permalink / raw)
To: David Miller, Florian Fainelli, Andrew Lunn,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <84ac1cb7-bafd-5f15-8cda-e8dfd7d0deb3@gmail.com>
Switch to using phy_mii_ioctl().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/ethernet/realtek/r8169.c | 25 +++----------------------
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f0aa1b54..deed477e 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4283,31 +4283,12 @@ static int rtl_set_mac_address(struct net_device *dev, void *p)
return 0;
}
-static int rtl_xmii_ioctl(struct rtl8169_private *tp,
- struct mii_ioctl_data *data, int cmd)
-{
- switch (cmd) {
- case SIOCGMIIPHY:
- data->phy_id = 32; /* Internal PHY */
- return 0;
-
- case SIOCGMIIREG:
- data->val_out = rtl_readphy(tp, data->reg_num & 0x1f);
- return 0;
-
- case SIOCSMIIREG:
- rtl_writephy(tp, data->reg_num & 0x1f, data->val_in);
- return 0;
- }
- return -EOPNOTSUPP;
-}
-
static int rtl8169_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
- struct rtl8169_private *tp = netdev_priv(dev);
- struct mii_ioctl_data *data = if_mii(ifr);
+ if (!netif_running(dev))
+ return -ENODEV;
- return netif_running(dev) ? rtl_xmii_ioctl(tp, data, cmd) : -ENODEV;
+ return phy_mii_ioctl(dev->phydev, ifr, cmd);
}
static void rtl_init_mdio_ops(struct rtl8169_private *tp)
--
2.18.0
^ permalink raw reply related
* [PATCH net-next v2 07/10] r8169: migrate speed_down function to phylib
From: Heiner Kallweit @ 2018-07-10 18:39 UTC (permalink / raw)
To: David Miller, Florian Fainelli, Andrew Lunn,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <84ac1cb7-bafd-5f15-8cda-e8dfd7d0deb3@gmail.com>
Change rtl_speed_down() to use phylib.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 33 +++++++++++++---------------
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index deed477e..1eb761a8 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4233,6 +4233,10 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
rtl_writephy(tp, 0x0b, 0x0000); //w 0x0b 15 0 0
}
+ /* We may have called rtl_speed_down before */
+ dev->phydev->advertising = dev->phydev->supported;
+ genphy_config_aneg(dev->phydev);
+
genphy_soft_reset(dev->phydev);
rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
@@ -4316,28 +4320,21 @@ static void rtl_init_mdio_ops(struct rtl8169_private *tp)
}
}
+#define BASET10 (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full)
+#define BASET100 (ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full)
+#define BASET1000 (ADVERTISED_1000baseT_Half | ADVERTISED_1000baseT_Full)
+
static void rtl_speed_down(struct rtl8169_private *tp)
{
- u32 adv;
- int lpa;
+ struct phy_device *phydev = tp->dev->phydev;
+ u32 adv = phydev->lp_advertising & phydev->supported;
- rtl_writephy(tp, 0x1f, 0x0000);
- lpa = rtl_readphy(tp, MII_LPA);
+ if (adv & BASET10)
+ phydev->advertising &= ~(BASET100 | BASET1000);
+ else if (adv & BASET100)
+ phydev->advertising &= ~BASET1000;
- if (lpa & (LPA_10HALF | LPA_10FULL))
- adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full;
- else if (lpa & (LPA_100HALF | LPA_100FULL))
- adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
- ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full;
- else
- adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
- ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
- (tp->mii.supports_gmii ?
- ADVERTISED_1000baseT_Half |
- ADVERTISED_1000baseT_Full : 0);
-
- rtl8169_set_speed(tp->dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
- adv);
+ genphy_config_aneg(phydev);
}
static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
--
2.18.0
^ permalink raw reply related
* [PATCH net-next v2 08/10] r8169: remove rtl8169_set_speed_xmii
From: Heiner Kallweit @ 2018-07-10 18:39 UTC (permalink / raw)
To: David Miller, Florian Fainelli, Andrew Lunn,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <84ac1cb7-bafd-5f15-8cda-e8dfd7d0deb3@gmail.com>
We can remove rtl8169_set_speed_xmii() now that phylib handles all this.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- no changes
---
drivers/net/ethernet/realtek/r8169.c | 90 ----------------------------
1 file changed, 90 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 1eb761a8..3a13c1da 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1663,89 +1663,6 @@ static int rtl8169_get_regs_len(struct net_device *dev)
return R8169_REGS_SIZE;
}
-static int rtl8169_set_speed_xmii(struct net_device *dev,
- u8 autoneg, u16 speed, u8 duplex, u32 adv)
-{
- struct rtl8169_private *tp = netdev_priv(dev);
- int giga_ctrl, bmcr;
- int rc = -EINVAL;
-
- rtl_writephy(tp, 0x1f, 0x0000);
-
- if (autoneg == AUTONEG_ENABLE) {
- int auto_nego;
-
- auto_nego = rtl_readphy(tp, MII_ADVERTISE);
- auto_nego &= ~(ADVERTISE_10HALF | ADVERTISE_10FULL |
- ADVERTISE_100HALF | ADVERTISE_100FULL);
-
- if (adv & ADVERTISED_10baseT_Half)
- auto_nego |= ADVERTISE_10HALF;
- if (adv & ADVERTISED_10baseT_Full)
- auto_nego |= ADVERTISE_10FULL;
- if (adv & ADVERTISED_100baseT_Half)
- auto_nego |= ADVERTISE_100HALF;
- if (adv & ADVERTISED_100baseT_Full)
- auto_nego |= ADVERTISE_100FULL;
-
- auto_nego |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
-
- giga_ctrl = rtl_readphy(tp, MII_CTRL1000);
- giga_ctrl &= ~(ADVERTISE_1000FULL | ADVERTISE_1000HALF);
-
- /* The 8100e/8101e/8102e do Fast Ethernet only. */
- if (tp->mii.supports_gmii) {
- if (adv & ADVERTISED_1000baseT_Half)
- giga_ctrl |= ADVERTISE_1000HALF;
- if (adv & ADVERTISED_1000baseT_Full)
- giga_ctrl |= ADVERTISE_1000FULL;
- } else if (adv & (ADVERTISED_1000baseT_Half |
- ADVERTISED_1000baseT_Full)) {
- netif_info(tp, link, dev,
- "PHY does not support 1000Mbps\n");
- goto out;
- }
-
- bmcr = BMCR_ANENABLE | BMCR_ANRESTART;
-
- rtl_writephy(tp, MII_ADVERTISE, auto_nego);
- rtl_writephy(tp, MII_CTRL1000, giga_ctrl);
- } else {
- if (speed == SPEED_10)
- bmcr = 0;
- else if (speed == SPEED_100)
- bmcr = BMCR_SPEED100;
- else
- goto out;
-
- if (duplex == DUPLEX_FULL)
- bmcr |= BMCR_FULLDPLX;
- }
-
- rtl_writephy(tp, MII_BMCR, bmcr);
-
- if (tp->mac_version == RTL_GIGA_MAC_VER_02 ||
- tp->mac_version == RTL_GIGA_MAC_VER_03) {
- if ((speed == SPEED_100) && (autoneg != AUTONEG_ENABLE)) {
- rtl_writephy(tp, 0x17, 0x2138);
- rtl_writephy(tp, 0x0e, 0x0260);
- } else {
- rtl_writephy(tp, 0x17, 0x2108);
- rtl_writephy(tp, 0x0e, 0x0000);
- }
- }
-
- rc = 0;
-out:
- return rc;
-}
-
-static int rtl8169_set_speed(struct net_device *dev,
- u8 autoneg, u16 speed, u8 duplex, u32 advertising)
-{
- return rtl8169_set_speed_xmii(dev, autoneg, speed, duplex, advertising);
-}
-
static netdev_features_t rtl8169_fix_features(struct net_device *dev,
netdev_features_t features)
{
@@ -4238,13 +4155,6 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
genphy_config_aneg(dev->phydev);
genphy_soft_reset(dev->phydev);
-
- rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
- ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
- ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
- (tp->mii.supports_gmii ?
- ADVERTISED_1000baseT_Half |
- ADVERTISED_1000baseT_Full : 0));
}
static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
--
2.18.0
^ permalink raw reply related
* [PATCH net-next v2 09/10] r8169: remove mii_if_info member from struct rtl8169_private
From: Heiner Kallweit @ 2018-07-10 18:40 UTC (permalink / raw)
To: David Miller, Florian Fainelli, Andrew Lunn,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <84ac1cb7-bafd-5f15-8cda-e8dfd7d0deb3@gmail.com>
The only remaining usage of the struct mii_if_info member is to store the
information whether the chip is GMII-capable. So we can replace it with
a simple flag.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- no changes
--
drivers/net/ethernet/realtek/r8169.c | 38 +++++-----------------------
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3a13c1da..6600edfb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -15,7 +15,6 @@
#include <linux/etherdevice.h>
#include <linux/delay.h>
#include <linux/ethtool.h>
-#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/if_vlan.h>
#include <linux/crc32.h>
@@ -754,7 +753,7 @@ struct rtl8169_private {
struct work_struct work;
} wk;
- struct mii_if_info mii;
+ unsigned supports_gmii:1;
struct mii_bus *mii_bus;
dma_addr_t counters_phys_addr;
struct rtl8169_counters *counters;
@@ -1106,21 +1105,6 @@ static void rtl_w0w1_phy(struct rtl8169_private *tp, int reg_addr, int p, int m)
rtl_writephy(tp, reg_addr, (val & ~m) | p);
}
-static void rtl_mdio_write(struct net_device *dev, int phy_id, int location,
- int val)
-{
- struct rtl8169_private *tp = netdev_priv(dev);
-
- rtl_writephy(tp, location, val);
-}
-
-static int rtl_mdio_read(struct net_device *dev, int phy_id, int location)
-{
- struct rtl8169_private *tp = netdev_priv(dev);
-
- return rtl_readphy(tp, location);
-}
-
DECLARE_RTL_COND(rtl_ephyar_cond)
{
return RTL_R32(tp, EPHYAR) & EPHYAR_FLAG;
@@ -2246,15 +2230,15 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
"unknown MAC, using family default\n");
tp->mac_version = default_version;
} else if (tp->mac_version == RTL_GIGA_MAC_VER_42) {
- tp->mac_version = tp->mii.supports_gmii ?
+ tp->mac_version = tp->supports_gmii ?
RTL_GIGA_MAC_VER_42 :
RTL_GIGA_MAC_VER_43;
} else if (tp->mac_version == RTL_GIGA_MAC_VER_45) {
- tp->mac_version = tp->mii.supports_gmii ?
+ tp->mac_version = tp->supports_gmii ?
RTL_GIGA_MAC_VER_45 :
RTL_GIGA_MAC_VER_47;
} else if (tp->mac_version == RTL_GIGA_MAC_VER_46) {
- tp->mac_version = tp->mii.supports_gmii ?
+ tp->mac_version = tp->supports_gmii ?
RTL_GIGA_MAC_VER_46 :
RTL_GIGA_MAC_VER_48;
}
@@ -6707,7 +6691,7 @@ static int r8169_phy_connect(struct rtl8169_private *tp)
phy_interface_t phy_mode;
int ret;
- phy_mode = tp->mii.supports_gmii ? PHY_INTERFACE_MODE_GMII :
+ phy_mode = tp->supports_gmii ? PHY_INTERFACE_MODE_GMII :
PHY_INTERFACE_MODE_MII;
phydev = mdiobus_get_phy(tp->mii_bus, 0);
@@ -6719,7 +6703,7 @@ static int r8169_phy_connect(struct rtl8169_private *tp)
if (ret)
return ret;
- if (!tp->mii.supports_gmii && phydev->supported & PHY_1000BT_FEATURES) {
+ if (!tp->supports_gmii && phydev->supported & PHY_1000BT_FEATURES) {
netif_info(tp, probe, tp->dev,
"Restrict PHY to 100Mbit because MAC doesn't support 1GBit\n");
phy_set_max_speed(phydev, SPEED_100);
@@ -7322,7 +7306,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data;
struct rtl8169_private *tp;
- struct mii_if_info *mii;
struct net_device *dev;
int chipset, region, i;
int rc;
@@ -7342,14 +7325,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->dev = dev;
tp->pci_dev = pdev;
tp->msg_enable = netif_msg_init(debug.msg_enable, R8169_MSG_DEFAULT);
-
- mii = &tp->mii;
- mii->dev = dev;
- mii->mdio_read = rtl_mdio_read;
- mii->mdio_write = rtl_mdio_write;
- mii->phy_id_mask = 0x1f;
- mii->reg_num_mask = 0x1f;
- mii->supports_gmii = cfg->has_gmii;
+ tp->supports_gmii = cfg->has_gmii;
/* enable device (incl. PCI PM wakeup and hotplug setup) */
rc = pcim_enable_device(pdev);
--
2.18.0
^ permalink raw reply related
* [PATCH net-next v2 10/10] r8169: don't read chip phy status register
From: Heiner Kallweit @ 2018-07-10 18:40 UTC (permalink / raw)
To: David Miller, Florian Fainelli, Andrew Lunn,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <84ac1cb7-bafd-5f15-8cda-e8dfd7d0deb3@gmail.com>
Instead of accessing the PHYstatus register we can use the information
phylib stores in the phy_device structure.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- no changes
---
drivers/net/ethernet/realtek/r8169.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6600edfb..25a834fa 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1428,18 +1428,19 @@ static void rtl8169_irq_mask_and_ack(struct rtl8169_private *tp)
static void rtl_link_chg_patch(struct rtl8169_private *tp)
{
struct net_device *dev = tp->dev;
+ struct phy_device *phydev = dev->phydev;
if (!netif_running(dev))
return;
if (tp->mac_version == RTL_GIGA_MAC_VER_34 ||
tp->mac_version == RTL_GIGA_MAC_VER_38) {
- if (RTL_R8(tp, PHYstatus) & _1000bpsF) {
+ if (phydev->speed == SPEED_1000) {
rtl_eri_write(tp, 0x1bc, ERIAR_MASK_1111, 0x00000011,
ERIAR_EXGMAC);
rtl_eri_write(tp, 0x1dc, ERIAR_MASK_1111, 0x00000005,
ERIAR_EXGMAC);
- } else if (RTL_R8(tp, PHYstatus) & _100bps) {
+ } else if (phydev->speed == SPEED_100) {
rtl_eri_write(tp, 0x1bc, ERIAR_MASK_1111, 0x0000001f,
ERIAR_EXGMAC);
rtl_eri_write(tp, 0x1dc, ERIAR_MASK_1111, 0x00000005,
@@ -1457,7 +1458,7 @@ static void rtl_link_chg_patch(struct rtl8169_private *tp)
ERIAR_EXGMAC);
} else if (tp->mac_version == RTL_GIGA_MAC_VER_35 ||
tp->mac_version == RTL_GIGA_MAC_VER_36) {
- if (RTL_R8(tp, PHYstatus) & _1000bpsF) {
+ if (phydev->speed == SPEED_1000) {
rtl_eri_write(tp, 0x1bc, ERIAR_MASK_1111, 0x00000011,
ERIAR_EXGMAC);
rtl_eri_write(tp, 0x1dc, ERIAR_MASK_1111, 0x00000005,
@@ -1469,7 +1470,7 @@ static void rtl_link_chg_patch(struct rtl8169_private *tp)
ERIAR_EXGMAC);
}
} else if (tp->mac_version == RTL_GIGA_MAC_VER_37) {
- if (RTL_R8(tp, PHYstatus) & _10bps) {
+ if (phydev->speed == SPEED_10) {
rtl_eri_write(tp, 0x1d0, ERIAR_MASK_0011, 0x4d02,
ERIAR_EXGMAC);
rtl_eri_write(tp, 0x1dc, ERIAR_MASK_0011, 0x0060,
--
2.18.0
^ permalink raw reply related
* KMSAN: uninit-value in p9_client_rpc
From: syzbot @ 2018-07-10 18:41 UTC (permalink / raw)
To: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
Hello,
syzbot found the following crash on:
HEAD commit: b64f7ec04e12 kmsan: implement kmsan_memmove_shadow() and k..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=127179b2400000
kernel config: https://syzkaller.appspot.com/x/.config?x=93d57043084eee38
dashboard link: https://syzkaller.appspot.com/bug?extid=4de40388f584432bf004
compiler: clang version 7.0.0 (trunk 334104)
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+4de40388f584432bf004@syzkaller.appspotmail.com
==================================================================
BUG: KMSAN: uninit-value in p9_client_rpc+0x194c/0x1dc0 net/9p/client.c:818
CPU: 0 PID: 14601 Comm: syz-executor4 Not tainted 4.18.0-rc4+ #24
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+0x185/0x1e0 lib/dump_stack.c:113
kmsan_report+0x195/0x2c0 mm/kmsan/kmsan.c:1092
__msan_warning_32+0x7d/0xe0 mm/kmsan/kmsan_instr.c:640
p9_client_rpc+0x194c/0x1dc0 net/9p/client.c:818
p9_client_attach+0x35b/0xc30 net/9p/client.c:1147
v9fs_session_init+0x24b9/0x2970 fs/9p/v9fs.c:449
v9fs_mount+0x107/0x11b0 fs/9p/vfs_super.c:135
mount_fs+0x29b/0x780 fs/super.c:1277
vfs_kern_mount+0x222/0x990 fs/namespace.c:1037
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0xd30/0x5310 fs/namespace.c:2848
ksys_mount+0x32e/0x3d0 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0x157/0x1c0 fs/namespace.c:3075
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x455e29
Code: 1d ba 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 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2b81f7fc68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f2b81f806d4 RCX: 0000000000455e29
RDX: 0000000020000080 RSI: 0000000020000000 RDI: 0000000000000000
RBP: 000000000072bea0 R08: 0000000020000380 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004c05ca R14: 00000000004d0070 R15: 0000000000000000
Local variable description: ----ecode.i@p9_client_rpc
Variable was created at:
p9_client_rpc+0x183/0x1dc0 net/9p/client.c:750
p9_client_attach+0x35b/0xc30 net/9p/client.c:1147
==================================================================
---
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#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH rdma-next 4/9] IB/mlx5: Introduce flow steering matcher object
From: Jason Gunthorpe @ 2018-07-10 17:34 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180708102445.25496-5-leon@kernel.org>
On Sun, Jul 08, 2018 at 01:24:40PM +0300, Leon Romanovsky wrote:
> From: Yishai Hadas <yishaih@mellanox.com>
>
> Introduce flow steering matcher object and its create and destroy
> methods.
>
> This matcher object holds some mlx5 specific driver properties that
> matches the underlay device specification when an mlx5 flow steering
> group is created.
>
> It will be used in downstream patches to be part of mlx5 specific create
> flow method.
>
> Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> drivers/infiniband/hw/mlx5/Makefile | 1 +
> drivers/infiniband/hw/mlx5/flow.c | 132 +++++++++++++++++++++++++++++++
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 11 +++
> include/uapi/rdma/mlx5_user_ioctl_cmds.h | 33 +++++++-
> 4 files changed, 176 insertions(+), 1 deletion(-)
> create mode 100644 drivers/infiniband/hw/mlx5/flow.c
>
> diff --git a/drivers/infiniband/hw/mlx5/Makefile b/drivers/infiniband/hw/mlx5/Makefile
> index 577e4c418bae..b8e4b15e2674 100644
> +++ b/drivers/infiniband/hw/mlx5/Makefile
> @@ -4,3 +4,4 @@ mlx5_ib-y := main.o cq.o doorbell.o qp.o mem.o srq.o mr.o ah.o mad.o gsi.o ib_vi
> mlx5_ib-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += odp.o
> mlx5_ib-$(CONFIG_MLX5_ESWITCH) += ib_rep.o
> mlx5_ib-$(CONFIG_INFINIBAND_USER_ACCESS) += devx.o
> +mlx5_ib-$(CONFIG_INFINIBAND_USER_ACCESS) += flow.o
> diff --git a/drivers/infiniband/hw/mlx5/flow.c b/drivers/infiniband/hw/mlx5/flow.c
> new file mode 100644
> index 000000000000..99409e516c7f
> +++ b/drivers/infiniband/hw/mlx5/flow.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
> +/*
> + * Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
> + */
> +
> +#include <rdma/ib_user_verbs.h>
> +#include <rdma/ib_verbs.h>
> +#include <rdma/uverbs_types.h>
> +#include <rdma/uverbs_ioctl.h>
> +#include <rdma/mlx5_user_ioctl_cmds.h>
> +#include <rdma/ib_umem.h>
> +#include <linux/mlx5/driver.h>
> +#include <linux/mlx5/fs.h>
> +#include "mlx5_ib.h"
> +
> +#define UVERBS_MODULE_NAME mlx5_ib
> +#include <rdma/uverbs_named_ioctl.h>
> +
> +static const struct uverbs_attr_spec mlx5_ib_flow_type[] = {
> + [MLX5_IB_FLOW_TYPE_NORMAL] = {
> + .type = UVERBS_ATTR_TYPE_PTR_IN,
> + UVERBS_ATTR_TYPE(u16),
> + },
> + [MLX5_IB_FLOW_TYPE_SNIFFER] = {
> + /* No need to specify any data */
> + .type = UVERBS_ATTR_TYPE_PTR_IN,
I think this deserves a macro rather than a repeated
comment.. Especially since we now have have a different version in
uverbs_flow_action_esp_replay:
.type = UVERBS_ATTR_TYPE_PTR_IN,
/* No need to specify any data */
UVERBS_ATTR_SIZE(0, 0),
Something simple like:
#define UVERBS_ATTR_NO_DATA() UVERBS_ATTR_SIZE(0, 0)
> +static int flow_matcher_cleanup(struct ib_uobject *uobject,
> + enum rdma_remove_reason why)
> +{
> + struct mlx5_ib_flow_matcher *obj = uobject->object;
> + int ret = atomic_read(&obj->usecnt) ? -EBUSY : 0;
> +
> + if (ib_is_destroy_retryable(ret, why, uobject))
> + return ret;
This is ib_destroy_usecnt() now
> +static int UVERBS_HANDLER(MLX5_IB_METHOD_FLOW_MATCHER_CREATE)(struct ib_device *ib_dev,
> + struct ib_uverbs_file *file,
> + struct uverbs_attr_bundle *attrs)
> +{
> + struct mlx5_ib_dev *dev = to_mdev(ib_dev);
I have a patch changing these - when working with uobj's the ib_dev
argument should not be used, the ib_dev must come from the ucontext
instead.
> + void *cmd_in = uverbs_attr_get_alloced_ptr(attrs,
> + MLX5_IB_ATTR_FLOW_MATCHER_MATCH_MASK);
> + struct ib_uobject *uobj;
> + struct mlx5_ib_flow_matcher *obj;
> + int mask_len;
> + int err;
So this is to be written as
struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
MLX5_IB_ATTR_FLOW_MATCHER_CREATE_HANDLE);
struct mlx5_ib_dev *dev = to_mdev(uobj->context->device);
> +
> + obj = kzalloc(sizeof(struct mlx5_ib_flow_matcher), GFP_KERNEL);
> + if (!obj)
> + return -ENOMEM;
> +
> + obj->mask_len = uverbs_attr_get_len(attrs,
> + MLX5_IB_ATTR_FLOW_MATCHER_MATCH_MASK);
> + memcpy(obj->matcher_mask.match_params, cmd_in, obj->mask_len);
As noted before, memcpying an alloced_ptr doesn't make sense, use the
copy from user version instead.
Jason
^ permalink raw reply
* Re: [PATCH rdma-next 6/9] IB/mlx5: Introduce vendor create and destroy flow methods
From: Jason Gunthorpe @ 2018-07-10 17:44 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180708102445.25496-7-leon@kernel.org>
On Sun, Jul 08, 2018 at 01:24:42PM +0300, Leon Romanovsky wrote:
> +static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(struct ib_device *ib_dev,
> + struct ib_uverbs_file *file,
> + struct uverbs_attr_bundle *attrs)
> +{
> + struct mlx5_ib_dev *dev = to_mdev(ib_dev);
Same comment as before, the dev needs to come from uboj->context->device
> -/* Used by drivers to declare a complete parsing tree for a single method that
> - * differs only in having additional driver specific attributes.
> +/* Used by drivers to declare a complete parsing tree for new methods
> */
> -#define ADD_UVERBS_ATTRIBUTES_SIMPLE(_name, _object_id, _method_id, ...) \
> - static const struct uverbs_attr_def *const UVERBS_METHOD_ATTRS( \
> - _method_id)[] = { __VA_ARGS__ }; \
> - static const struct uverbs_method_def UVERBS_METHOD(_method_id) = { \
> - .id = _method_id, \
> - .num_attrs = ARRAY_SIZE(UVERBS_METHOD_ATTRS(_method_id)), \
> - .attrs = &UVERBS_METHOD_ATTRS(_method_id), \
> - }; \
> +#define ADD_UVERBS_METHODS(_name, _object_id, ...) \
> static const struct uverbs_method_def *const UVERBS_OBJECT_METHODS( \
> - _object_id)[] = { &UVERBS_METHOD(_method_id) }; \
> + _object_id)[] = { __VA_ARGS__ }; \
> static const struct uverbs_object_def _name##_struct = { \
> .id = _object_id, \
> - .num_methods = 1, \
> + .num_methods = ARRAY_SIZE(UVERBS_OBJECT_METHODS(_object_id)), \
> .methods = &UVERBS_OBJECT_METHODS(_object_id) \
> }; \
> static const struct uverbs_object_def *const _name##_ptrs[] = { \
> @@ -123,4 +115,17 @@
> .objects = &_name##_ptrs, \
> }
>
> +/* Used by drivers to declare a complete parsing tree for a single method that
> + * differs only in having additional driver specific attributes.
> + */
> +#define ADD_UVERBS_ATTRIBUTES_SIMPLE(_name, _object_id, _method_id, ...) \
> + static const struct uverbs_attr_def *const UVERBS_METHOD_ATTRS( \
> + _method_id)[] = { __VA_ARGS__ }; \
> + static const struct uverbs_method_def UVERBS_METHOD(_method_id) = { \
> + .id = _method_id, \
> + .num_attrs = ARRAY_SIZE(UVERBS_METHOD_ATTRS(_method_id)), \
> + .attrs = &UVERBS_METHOD_ATTRS(_method_id), \
> + }; \
> + ADD_UVERBS_METHODS(_name, _object_id, _method_id)
Wow. How does that even compile? Oh I see, the only two users are
passing in a 0 constant which the compiler will understand as NULL
without a warning.
I guess this is an instant crash at runtime?
Should be:
ADD_UVERBS_METHODS(_name, _object_id, &UVERBS_METHOD(_method_id)
Jason
^ permalink raw reply
* Re: Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
From: Siwei Liu @ 2018-07-10 18:56 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: si-wei liu, Roman Kagan, Venu Busireddy, Marcel Apfelbaum,
virtio-dev, qemu-devel, Samudrala, Sridhar, Alexander Duyck,
Netdev
In-Reply-To: <20180710045614-mutt-send-email-mst@kernel.org>
On Mon, Jul 9, 2018 at 6:58 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote:
>> What do we buy
>> for using a random address during initial discovery and requiring VF to
>> complete the handshake?
>
> I don't see advantages to using a random address that is then
> changed either: changing a MAC causes network downtime for most users.
>
Definitely.
I see Linux host stack fundamentally different with Windows, it's
non-sense to duplicate what Hyper-V is doing especially if there's no
extra benefit.
>> Less network downtime during datapath switching?
>> Sorry but that's not a key factor at all for our main goal - live migration.
>
> Isn't avoiding downtime what makes the migration "live"?
> If you don't care about it at all just remove the device
> and migrate without all these tricks.
Apparently this downtime is not avoidable even if guest initiates the
switch-over when it is done on Linux host stack. Unless the NIC
supports adding duplicate MAC filters with one has higher priority
than the other when both are present. I feel there's very little or
perhaps zero improvement for the downtime if moving to a
guest-initiated datapath switching model.
However, since this downtime is intermittent and generally
unnoticeable with a few packet drops, network should be resilient in
recovering from the drops. My point is that unless we can move to a
datapath switching model with zero downtime theoretically, this kind
of minor optimization offers very little help in general.
Regards,
-Siwei
>
>
> --
> MST
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] r8169: add basic phylib support
From: Andrew Lunn @ 2018-07-10 19:10 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David Miller, Florian Fainelli, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <9816ca13-1347-5a1c-62d6-1d7c799bde60@gmail.com>
> +static int r8169_mdio_read_reg(struct mii_bus *mii_bus, int phyaddr, int phyreg)
> +{
> + struct rtl8169_private *tp = mii_bus->priv;
> +
> + if (phyaddr > 0)
> + return -EINVAL;
Please use ENODEV.
The mdio bus is scanned for devices in __mdiobus_register(). If
mdiobus_scan() returns -ENODEV, it is not considered an error, and it
will continue scanning other addresses on the bus. Any other error is
a real error, and will abort the scan. That will probably abort the
bus registration.
> +static int r8169_mdio_register(struct rtl8169_private *tp)
> +{
> + struct pci_dev *pdev = tp->pci_dev;
> + struct mii_bus *new_bus;
> + int ret;
> +
> + new_bus = devm_mdiobus_alloc(&pdev->dev);
> + if (!new_bus)
> + return -ENOMEM;
> +
> + new_bus->name = "r8169";
> + new_bus->phy_mask = ~1;
Once your handling of addr > 0 is correct, you don't need this. Let
is scan all addresses, just like a normal MDIO bus. The more we can
keep it normal, the better.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 08/13] ARM: net: bpf: use immediate forms of instructions where possible
From: kbuild test robot @ 2018-07-10 19:12 UTC (permalink / raw)
To: Russell King; +Cc: netdev, Daniel Borkmann, kbuild-all, linux-arm-kernel
In-Reply-To: <E1fcrsq-0005V7-Pp@rmk-PC.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3984 bytes --]
Hi Russell,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Russell-King/ARM-net-bpf-enumerate-the-JIT-scratch-stack-layout/20180710-203859
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/timer.h:5,
from include/linux/workqueue.h:9,
from include/linux/bpf.h:12,
from arch/arm/net/bpf_jit_32.c:12:
In function 'emit_bpf_tail_call',
inlined from 'build_insn' at arch/arm/net/bpf_jit_32.c:1601:7:
>> include/linux/compiler.h:339:38: error: call to '__compiletime_assert_1045' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct bpf_array, ptrs) > ARM_ALU_IMM
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:319:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:339:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:45:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
>> arch/arm/net/bpf_jit_32.c:1045:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(offsetof(struct bpf_array, ptrs) > ARM_ALU_IMM);
^~~~~~~~~~~~
vim +/__compiletime_assert_1045 +339 include/linux/compiler.h
9a8ab1c3 Daniel Santos 2013-02-21 325
9a8ab1c3 Daniel Santos 2013-02-21 326 #define _compiletime_assert(condition, msg, prefix, suffix) \
9a8ab1c3 Daniel Santos 2013-02-21 327 __compiletime_assert(condition, msg, prefix, suffix)
9a8ab1c3 Daniel Santos 2013-02-21 328
9a8ab1c3 Daniel Santos 2013-02-21 329 /**
9a8ab1c3 Daniel Santos 2013-02-21 330 * compiletime_assert - break build and emit msg if condition is false
9a8ab1c3 Daniel Santos 2013-02-21 331 * @condition: a compile-time constant condition to check
9a8ab1c3 Daniel Santos 2013-02-21 332 * @msg: a message to emit if condition is false
9a8ab1c3 Daniel Santos 2013-02-21 333 *
9a8ab1c3 Daniel Santos 2013-02-21 334 * In tradition of POSIX assert, this macro will break the build if the
9a8ab1c3 Daniel Santos 2013-02-21 335 * supplied condition is *false*, emitting the supplied error message if the
9a8ab1c3 Daniel Santos 2013-02-21 336 * compiler has support to do so.
9a8ab1c3 Daniel Santos 2013-02-21 337 */
9a8ab1c3 Daniel Santos 2013-02-21 338 #define compiletime_assert(condition, msg) \
9a8ab1c3 Daniel Santos 2013-02-21 @339 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
9a8ab1c3 Daniel Santos 2013-02-21 340
:::::: The code at line 339 was first introduced by commit
:::::: 9a8ab1c39970a4938a72d94e6fd13be88a797590 bug.h, compiler.h: introduce compiletime_assert & BUILD_BUG_ON_MSG
:::::: TO: Daniel Santos <daniel.santos@pobox.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 66073 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v2 02/10] r8169: use phy_resume/phy_suspend
From: Andrew Lunn @ 2018-07-10 19:15 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David Miller, Florian Fainelli, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <a5f58c73-fcfa-8f19-99d6-a0860ca91fc3@gmail.com>
> static void r8168_pll_power_down(struct rtl8169_private *tp)
> {
> if (r8168_check_dash(tp))
> @@ -4503,7 +4462,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
> if (rtl_wol_pll_power_down(tp))
> return;
>
> - r8168_phy_power_down(tp);
> + /* cover the case that PHY isn't connected */
> + phy_suspend(mdiobus_get_phy(tp->mii_bus, 0));
I don't particularly like this, because no other MAC driver does it.
Why is it powered up, but not connected? Is it powered down before it
is disconnected? Is it the bootloader which is powering it up?
Andrew
^ permalink raw reply
* general protection fault in vsscanf
From: syzbot @ 2018-07-10 19:19 UTC (permalink / raw)
To: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
Hello,
syzbot found the following crash on:
HEAD commit: 092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1260ef34400000
kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
dashboard link: https://syzkaller.appspot.com/bug?extid=0ec640a6eebcf1c82417
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=14c2f50c400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14fe4c58400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0ec640a6eebcf1c82417@syzkaller.appspotmail.com
9pnet: p9_fd_create_tcp (4481): problem connecting socket to 127.0.0.1
9pnet: p9_fd_create_tcp (4506): problem connecting socket to 127.0.0.1
kasan: CONFIG_KASAN_INLINE enabled
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
kasan: GPF could be caused by NULL-ptr deref or user memory access
CPU: 1 PID: 4502 Comm: syz-executor518 Not tainted 4.18.0-rc4+ #42
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:vsscanf+0x3c1/0x2af0 lib/vsprintf.c:2966
Code: f9 44 89 ee bf 6e 00 00 00 e8 5b 82 eb f9 41 80 fd 6e 0f 84 ce 02 00
00 e8 7c 81 eb f9 4c 89 f0 4c 89 f2 48 c1 e8 03 83 e2 07 <42> 0f b6 04 38
38 d0 7f 08 84 c0 0f 85 e8 1c 00 00 45 0f b6 26 31
RSP: 0018:ffff8801bf93f0a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffffff888364c1 RCX: ffffffff87908a15
RDX: 0000000000000000 RSI: ffffffff87908a24 RDI: 0000000000000001
RBP: ffff8801bf93f270 R08: ffff8801b5e9a140 R09: ffff8801bf93f464
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff888364c1
R13: 0000000000000064 R14: 0000000000000000 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8801daf00000(0063) knlGS:00000000f7efcb40
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f7f3dcc4 CR3: 00000001b6883000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sscanf+0xab/0xe0 lib/vsprintf.c:3172
valid_ipaddr4 net/9p/trans_fd.c:903 [inline]
p9_fd_create_tcp+0x113/0x8a0 net/9p/trans_fd.c:943
p9_client_create+0x915/0x16c9 net/9p/client.c:1062
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x581/0x30e0 fs/namespace.c:2848
__do_compat_sys_mount fs/compat.c:125 [inline]
__se_compat_sys_mount fs/compat.c:92 [inline]
__ia32_compat_sys_mount+0x5d5/0x860 fs/compat.c:92
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f42cb9
Code: 55 08 8b 88 64 cd ff ff 8b 98 68 cd ff ff 89 c8 85 d2 74 02 89 0a 5b
5d c3 8b 04 24 c3 8b 1c 24 c3 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000f7efc1ec EFLAGS: 00000296 ORIG_RAX: 0000000000000015
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000200000c0
RDX: 0000000020000340 RSI: 0000000000000000 RDI: 0000000020000180
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
general protection fault: 0000 [#2] SMP KASAN
---[ end trace 603612217fadf6c1 ]---
CPU: 0 PID: 4504 Comm: syz-executor518 Tainted: G D
4.18.0-rc4+ #42
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:vsscanf+0x3c1/0x2af0 lib/vsprintf.c:2966
RIP: 0010:vsscanf+0x3c1/0x2af0 lib/vsprintf.c:2966
Code: f9 44 89 ee bf 6e 00 00 00 e8
Code:
5b 82 eb f9 41 80
f9
fd 6e 0f 84 ce 02
44
00 00 e8 7c 81 eb
89
f9 4c 89 f0 4c 89
ee
f2 48 c1 e8 03 83
bf
e2 07 <42> 0f b6 04
6e
38 38 d0 7f 08 84
00
c0 0f 85 e8 1c 00 00
00
45 0f b6 26 31
RSP: 0018:ffff8801af7ff0a0 EFLAGS: 00010246
00
RAX: 0000000000000000 RBX: ffffffff888364c1 RCX: ffffffff87908a15
RDX: 0000000000000000 RSI: ffffffff87908a24 RDI: 0000000000000001
RBP: ffff8801af7ff270 R08: ffff8801b5e2a1c0 R09: ffff8801af7ff464
e8
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff888364c1
R13: 0000000000000064 R14: 0000000000000000 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8801dae00000(0063) knlGS:00000000f7efcb40
5b
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000008090b10 CR3: 00000001b5f70000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
82
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
eb
f9
41
80
sscanf+0xab/0xe0 lib/vsprintf.c:3172
fd
6e
valid_ipaddr4 net/9p/trans_fd.c:903 [inline]
p9_fd_create_tcp+0x113/0x8a0 net/9p/trans_fd.c:943
0f
84
ce
02
p9_client_create+0x915/0x16c9 net/9p/client.c:1062
00
00
e8
7c
81
eb
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
f9
4c
89
f0
4c
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
mount_fs+0xae/0x328 fs/super.c:1277
89
vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
f2
48
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x581/0x30e0 fs/namespace.c:2848
c1
e8
03
83
__do_compat_sys_mount fs/compat.c:125 [inline]
__se_compat_sys_mount fs/compat.c:92 [inline]
__ia32_compat_sys_mount+0x5d5/0x860 fs/compat.c:92
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
e2
07
<42>
0f
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
b6
RIP: 0023:0xf7f42cb9
Code: 55 08
04
8b 88 64 cd ff ff
38
8b 98 68 cd ff ff 89
38
c8 85 d2 74 02 89 0a
d0
5b 5d c3 8b 04 24
7f
c3 8b 1c 24 c3 51 52
08
55 89 e5 0f 34 cd
84
80 <5d> 5a 59 c3 90 90
c0
90 90 eb 0d 90 90 90
0f
90 90 90 90 90 90
85
90 90 90
RSP: 002b:00000000f7efc1ec EFLAGS: 00000296 ORIG_RAX: 0000000000000015
e8
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000200000c0
RDX: 0000000020000340 RSI: 0000000000000000 RDI: 0000000020000180
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
1c
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
00
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 603612217fadf6c2 ]---
00
RIP: 0010:vsscanf+0x3c1/0x2af0 lib/vsprintf.c:2966
Code:
45
f9 44 89 ee bf
0f
6e 00
b6
00 00
26
e8
31
5b 82
eb f9
RSP: 0018:ffff8801bf93f0a0 EFLAGS: 00010246
41 80
fd 6e
RAX: 0000000000000000 RBX: ffffffff888364c1 RCX: ffffffff87908a15
0f 84
RDX: 0000000000000000 RSI: ffffffff87908a24 RDI: 0000000000000001
ce 02
RBP: ffff8801bf93f270 R08: ffff8801b5e9a140 R09: ffff8801bf93f464
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff888364c1
00 00
R13: 0000000000000064 R14: 0000000000000000 R15: dffffc0000000000
e8 7c
FS: 0000000000000000(0000) GS:ffff8801daf00000(0063) knlGS:00000000f7efcb40
81 eb
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
f9 4c
CR2: 00000000f7f3dcc4 CR3: 00000001b6883000 CR4: 00000000001406e0
89 f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
4c 89
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
f2 48
---
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#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* general protection fault in in_aton
From: syzbot @ 2018-07-10 19:19 UTC (permalink / raw)
To: axboe, bart.vanassche, davem, linux-kernel, netdev, sagi,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1687b168400000
kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
dashboard link: https://syzkaller.appspot.com/bug?extid=2a831e062bb4aebd8755
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=158cc2c2400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16e7ef48400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 4524 Comm: syz-executor617 Not tainted 4.18.0-rc4+ #42
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:in_aton+0x3e/0x180 net/core/utils.c:63
Code: f6 41 55 41 54 49 89 fc 53 48 83 ec 08 c7 45 d4 00 00 00 00 e8 a3 a5
7c fb 4c 89 e0 4c 89 e2 c1 65 d4 08 48 c1 e8 03 83 e2 07 <42> 0f b6 04 38
38 d0 7f 08 84 c0 0f 85 1a 01 00 00 41 0f be 1c 24
RSP: 0018:ffff8801a8f171a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801acc613a4 RCX: ffffffff87685d49
RDX: 0000000000000000 RSI: ffffffff85ff65fd RDI: 0000000000000000
RBP: ffff8801a8f171d0 R08: ffff8801ac928040 R09: ffffed00351e2df9
R10: ffffed00351e2df9 R11: 0000000000000003 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000000 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8801dae00000(0063) knlGS:000000000961b840
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000020000140 CR3: 00000001ac93c000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
rdma_create_trans+0xdbe/0x1ed0 net/9p/trans_rdma.c:678
p9_client_create+0x915/0x16c9 net/9p/client.c:1062
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x581/0x30e0 fs/namespace.c:2848
__do_compat_sys_mount fs/compat.c:125 [inline]
__se_compat_sys_mount fs/compat.c:92 [inline]
__ia32_compat_sys_mount+0x5d5/0x860 fs/compat.c:92
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f65cb9
Code: 55 08 8b 88 64 cd ff ff 8b 98 68 cd ff ff 89 c8 85 d2 74 02 89 0a 5b
5d c3 8b 04 24 c3 8b 1c 24 c3 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000ffb9d3bc EFLAGS: 00000282 ORIG_RAX: 0000000000000015
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000200000c0
RDX: 0000000020000340 RSI: 0000000000000000 RDI: 0000000020000180
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 5db7de5a7d39bf0a ]---
RIP: 0010:in_aton+0x3e/0x180 net/core/utils.c:63
Code: f6 41 55 41 54 49 89 fc 53 48 83 ec 08 c7 45 d4 00 00 00 00 e8 a3 a5
7c fb 4c 89 e0 4c 89 e2 c1 65 d4 08 48 c1 e8 03 83 e2 07 <42> 0f b6 04 38
38 d0 7f 08 84 c0 0f 85 1a 01 00 00 41 0f be 1c 24
RSP: 0018:ffff8801a8f171a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801acc613a4 RCX: ffffffff87685d49
RDX: 0000000000000000 RSI: ffffffff85ff65fd RDI: 0000000000000000
RBP: ffff8801a8f171d0 R08: ffff8801ac928040 R09: ffffed00351e2df9
R10: ffffed00351e2df9 R11: 0000000000000003 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000000 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8801dae00000(0063) knlGS:000000000961b840
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000020000140 CR3: 00000001ac93c000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] r8169: add basic phylib support
From: Heiner Kallweit @ 2018-07-10 19:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, Florian Fainelli, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <20180710191051.GB11754@lunn.ch>
On 10.07.2018 21:10, Andrew Lunn wrote:
>> +static int r8169_mdio_read_reg(struct mii_bus *mii_bus, int phyaddr, int phyreg)
>> +{
>> + struct rtl8169_private *tp = mii_bus->priv;
>> +
>> + if (phyaddr > 0)
>> + return -EINVAL;
>
> Please use ENODEV.
>
> The mdio bus is scanned for devices in __mdiobus_register(). If
> mdiobus_scan() returns -ENODEV, it is not considered an error, and it
> will continue scanning other addresses on the bus. Any other error is
> a real error, and will abort the scan. That will probably abort the
> bus registration.
>
OK
>> +static int r8169_mdio_register(struct rtl8169_private *tp)
>> +{
>> + struct pci_dev *pdev = tp->pci_dev;
>> + struct mii_bus *new_bus;
>> + int ret;
>> +
>> + new_bus = devm_mdiobus_alloc(&pdev->dev);
>> + if (!new_bus)
>> + return -ENOMEM;
>> +
>> + new_bus->name = "r8169";
>> + new_bus->phy_mask = ~1;
>
> Once your handling of addr > 0 is correct, you don't need this. Let
> is scan all addresses, just like a normal MDIO bus. The more we can
> keep it normal, the better.
>
Sounds good. I'll wait for feedback on other patches of the
series and then prepare a v3.
Heiner
> Andrew
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: better availability probing for seg6 helpers
From: Daniel Borkmann @ 2018-07-10 19:20 UTC (permalink / raw)
To: Mathieu Xhonneux, netdev; +Cc: alexei.starovoitov
In-Reply-To: <20180710165402.26605-1-m.xhonneux@gmail.com>
On 07/10/2018 06:54 PM, Mathieu Xhonneux wrote:
> bpf_lwt_seg6_* helpers require CONFIG_IPV6_SEG6_BPF, and currently
> return -EOPNOTSUPP to indicate unavailability. This patch forces the
> BPF verifier to reject programs using these helpers when
> !CONFIG_IPV6_SEG6_BPF, allowing users to more easily probe if they are
> available or not.
>
> Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
Note, just fyi, this would need to go to bpf tree (and not bpf-next) as
otherwise there's a change in behavior.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net-next v2 02/10] r8169: use phy_resume/phy_suspend
From: Heiner Kallweit @ 2018-07-10 19:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, Florian Fainelli, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <20180710191509.GC11754@lunn.ch>
On 10.07.2018 21:15, Andrew Lunn wrote:
>> static void r8168_pll_power_down(struct rtl8169_private *tp)
>> {
>> if (r8168_check_dash(tp))
>> @@ -4503,7 +4462,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
>> if (rtl_wol_pll_power_down(tp))
>> return;
>>
>> - r8168_phy_power_down(tp);
>> + /* cover the case that PHY isn't connected */
>> + phy_suspend(mdiobus_get_phy(tp->mii_bus, 0));
>
> I don't particularly like this, because no other MAC driver does it.
>
I have to agree, it doesn't look too nice.
In general quite few network drivers seem to use runtime pm.
> Why is it powered up, but not connected? Is it powered down before it
> is disconnected? Is it the bootloader which is powering it up?
>
Exactly, if the device is active when driver is loaded and the
interface isn't used and therefore not brought up, then, when runtime-
suspending, we face this situation.
This could be changed by connecting the PHY in probe() already instead
of doing it in open(). I had this in the beginning, based on a
recommendation from Florian or you (don't remember) I changed this to
connect in open() only.
Do you have any preference or see a good way to deal with the situation?
Heiner
> Andrew
>
^ permalink raw reply
* Re: general protection fault in in_aton
From: Linus Torvalds @ 2018-07-10 19:44 UTC (permalink / raw)
To: syzbot+2a831e062bb4aebd8755, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov
Cc: Jens Axboe, Bart Van Assche, David Miller,
Linux Kernel Mailing List, Network Development, Sagi Grimberg,
syzkaller-bugs
In-Reply-To: <000000000000c242e90570aa0062@google.com>
On Tue, Jul 10, 2018 at 12:19 PM syzbot
<syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com> wrote:
> RIP: 0010:in_aton+0x3e/0x180 net/core/utils.c:63
That's
if (*str != '\0') {
in in_aton().
The code disassembles to
movzbl (%rax,%r15,1),%eax
which is a bit odd, because
> RAX: 0000000000000000
Ok, NULL pointer, looks sane, but:
> R15: dffffc0000000000
Yeah, that's unusual. But I'm guessing it's some KASAN artifact. One
of the big problemns with KASAN is that it makes the generated code
completely illegible because 90% of the code is just KASAN overhead.
> Call Trace:
> rdma_create_trans+0xdbe/0x1ed0 net/9p/trans_rdma.c:678
Well, rdma_create_trans() certainly doesn't verify 'addr' before using it.
> p9_client_create+0x915/0x16c9 net/9p/client.c:1062
p9_client_create() just blindly passes on "dev_name"
> v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
> v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
.. as does v9fs_session_init() and v9fs_mount()
> mount_fs+0xae/0x328 fs/super.c:1277
> vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
> vfs_kern_mount fs/namespace.c:1027 [inline]
> do_new_mount fs/namespace.c:2518 [inline]
> do_mount+0x581/0x30e0 fs/namespace.c:2848
This is "name" in mount_fs(), vfs_kern_mount(), do_new_mount() and
do_mount(), also just passed through.
> __do_compat_sys_mount fs/compat.c:125 [inline]
> __se_compat_sys_mount fs/compat.c:92 [inline]
> __ia32_compat_sys_mount+0x5d5/0x860 fs/compat.c:92
And here we have the source:
kernel_dev = copy_mount_string(dev_name);
Note that copy_mount_string() just passes a NULL user space pointer
through as a NULL kernel pointer (otherwise it does a
"strndup_user()".
And no, this is not a compat issue. The native mount does the same thing.
So yes. The device name can trivially be NULL, and either rdma or the
p9 code should check for NULL.
Adding in the 9p people, because I think it's for them. Note the
syzbot info below.
Linus
--
syzbot found the following crash on:
HEAD commit: 092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1687b168400000
kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
dashboard link: https://syzkaller.appspot.com/bug?extid=2a831e062bb4aebd8755
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=158cc2c2400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16e7ef48400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com
^ permalink raw reply
* Re: general protection fault in in_aton
From: Dmitry Vyukov @ 2018-07-10 19:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: syzbot+2a831e062bb4aebd8755, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, Jens Axboe, Bart Van Assche, David Miller,
Linux Kernel Mailing List, Network Development, Sagi Grimberg,
syzkaller-bugs, kasan-dev
In-Reply-To: <CA+55aFyEZR=v2GySzWWF3uh9ZB53CFFv460Wzg4n8DGze8GFfw@mail.gmail.com>
On Tue, Jul 10, 2018 at 9:44 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jul 10, 2018 at 12:19 PM syzbot
> <syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com> wrote:
>> RIP: 0010:in_aton+0x3e/0x180 net/core/utils.c:63
>
> That's
>
> if (*str != '\0') {
>
> in in_aton().
>
> The code disassembles to
>
> movzbl (%rax,%r15,1),%eax
>
> which is a bit odd, because
>
>> RAX: 0000000000000000
>
> Ok, NULL pointer, looks sane, but:
>
>> R15: dffffc0000000000
>
> Yeah, that's unusual. But I'm guessing it's some KASAN artifact. One
> of the big problemns with KASAN is that it makes the generated code
> completely illegible because 90% of the code is just KASAN overhead.
Yes, there is a problem with paging faults under KASAN.
For more complex bugs like use-after-frees and out-of-bounds there is
usually no need to look at disasm at all because KASAN provides all
relevant info in the report (actual access address, object start,
object size, where is was allocated/freed). But for paging faults
(notably NULL derefs), that's handled by the standard handler which
does not know about KASAN (except for printing "kasan: GPF could be
caused by NULL-ptr deref or user memory access"). Long time ago I
asked if it's possible to get the fault address in the handler, but I
got reply that it's close to impossible.
What KASAN does is reasonably simple: before each access to address
ADDR it inserts:
if (*(0xdffffc0000000000 + ADDR/8))
report_error();
... *ADDR ... // original access
So if we would have the fault address, and we see that it's
[0xdffffc0000000000; 0xdffffc0000000000+PAGE_SIZE/8), then we could
simply say that it's NULL deref.
Is it really hard to get fault address? I know that userspace
generally receives fault address in siginfo.
>> Call Trace:
>> rdma_create_trans+0xdbe/0x1ed0 net/9p/trans_rdma.c:678
>
> Well, rdma_create_trans() certainly doesn't verify 'addr' before using it.
>
>> p9_client_create+0x915/0x16c9 net/9p/client.c:1062
>
> p9_client_create() just blindly passes on "dev_name"
>
>> v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
>> v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
>
> .. as does v9fs_session_init() and v9fs_mount()
>
>> mount_fs+0xae/0x328 fs/super.c:1277
>> vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
>> vfs_kern_mount fs/namespace.c:1027 [inline]
>> do_new_mount fs/namespace.c:2518 [inline]
>> do_mount+0x581/0x30e0 fs/namespace.c:2848
>
> This is "name" in mount_fs(), vfs_kern_mount(), do_new_mount() and
> do_mount(), also just passed through.
>
>> __do_compat_sys_mount fs/compat.c:125 [inline]
>> __se_compat_sys_mount fs/compat.c:92 [inline]
>> __ia32_compat_sys_mount+0x5d5/0x860 fs/compat.c:92
>
> And here we have the source:
>
> kernel_dev = copy_mount_string(dev_name);
>
> Note that copy_mount_string() just passes a NULL user space pointer
> through as a NULL kernel pointer (otherwise it does a
> "strndup_user()".
>
> And no, this is not a compat issue. The native mount does the same thing.
>
> So yes. The device name can trivially be NULL, and either rdma or the
> p9 code should check for NULL.
>
> Adding in the 9p people, because I think it's for them. Note the
> syzbot info below.
>
> Linus
>
> --
>
> syzbot found the following crash on:
>
> HEAD commit: 092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1687b168400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
> dashboard link: https://syzkaller.appspot.com/bug?extid=2a831e062bb4aebd8755
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> userspace arch: i386
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=158cc2c2400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16e7ef48400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CA%2B55aFyEZR%3Dv2GySzWWF3uh9ZB53CFFv460Wzg4n8DGze8GFfw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH bpf 1/1] bpf: btf: Fix bitfield extraction for big endian
From: Daniel Borkmann @ 2018-07-10 20:02 UTC (permalink / raw)
To: Okash Khawaja
Cc: Martin KaFai Lau, Alexei Starovoitov, Yonghong Song,
Jakub Kicinski, David S. Miller, netdev, kernel-team,
linux-kernel
In-Reply-To: <20180710174904.GA3247@w1t1fb>
On 07/10/2018 07:49 PM, Okash Khawaja wrote:
> On Tue, Jul 10, 2018 at 10:21:02AM +0200, Daniel Borkmann wrote:
>> On 07/09/2018 08:32 PM, Martin KaFai Lau wrote:
>>> On Sun, Jul 08, 2018 at 05:22:03PM -0700, Okash Khawaja wrote:
>>>> When extracting bitfield from a number, btf_int_bits_seq_show() builds
>>>> a mask and accesses least significant byte of the number in a way
>>>> specific to little-endian. This patch fixes that by checking endianness
>>>> of the machine and then shifting left and right the unneeded bits.
>>>>
>>>> Thanks to Martin Lau for the help in navigating potential pitfalls when
>>>> dealing with endianess and for the final solution.
>>>>
>>>> Fixes: b00b8daec828 ("bpf: btf: Add pretty print capability for data with BTF type info")
>>>> Signed-off-by: Okash Khawaja <osk@fb.com>
>>>>
>>>> ---
>>>> kernel/bpf/btf.c | 32 +++++++++++++++-----------------
>>>> 1 file changed, 15 insertions(+), 17 deletions(-)
>>>>
>>>> --- a/kernel/bpf/btf.c
>>>> +++ b/kernel/bpf/btf.c
>>>> @@ -162,6 +162,8 @@
>>>> #define BITS_ROUNDDOWN_BYTES(bits) ((bits) >> 3)
>>>> #define BITS_ROUNDUP_BYTES(bits) \
>>>> (BITS_ROUNDDOWN_BYTES(bits) + !!BITS_PER_BYTE_MASKED(bits))
>>>> +const int one = 1;
>>>> +#define is_big_endian() ((*(char *)&one) == 0)
>>
>> Also here, in the kernel archs provide proper definitions.
> Is this the __BIG_ENDIAN #define or are there better ways to check that?
Given this deals with bitfields, should be __{BIG,LITTLE}_ENDIAN_BITFIELD.
^ permalink raw reply
* Re: general protection fault in in_aton
From: Linus Torvalds @ 2018-07-10 20:15 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot+2a831e062bb4aebd8755, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, Jens Axboe, Bart Van Assche, David Miller,
Linux Kernel Mailing List, Network Development, Sagi Grimberg,
syzkaller-bugs, kasan-dev
In-Reply-To: <CACT4Y+bOJx+SnkMqzDDUTU1iztQ7DpMBG7Z-oV5wArRaSEzh+Q@mail.gmail.com>
On Tue, Jul 10, 2018 at 12:57 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> Is it really hard to get fault address? I know that userspace
> generally receives fault address in siginfo.
For an actual page fault it's trivial.
However, for invalid addresses (aka "non-canonical"), you don't even
get a page fault, you get a GP like in this case. And then the actual
address is not available.
Linus
^ permalink raw reply
* Re: [PATCH iproute2-next] net:sched: add action inheritdsfield to skbedit
From: Cong Wang @ 2018-07-10 20:25 UTC (permalink / raw)
To: Fu, Qiaobin
Cc: David Ahern, Stephen Hemminger, David Miller,
Linux Kernel Network Developers, Jamal Hadi Salim, Michel Machado,
Marcelo Ricardo Leitner, Davide Caratti
In-Reply-To: <20180708212623.31494-1-qiaobinf@bu.edu>
On Sun, Jul 8, 2018 at 2:27 PM Qiaobin Fu <qiaobinf@bu.edu> wrote:
> @@ -111,6 +114,9 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
> }
> flags |= SKBEDIT_F_PTYPE;
> ok++;
> + } else if (matches(*argv, "inheritdsfield") == 0) {
> + pure_flags |= SKBEDIT_F_INHERITDSFIELD;
> + ok++;
> } else if (matches(*argv, "help") == 0) {
> usage();
> } else {
[...]
> @@ -214,6 +224,11 @@ static int print_skbedit(struct action_util *au, FILE *f, struct rtattr *arg)
> else
> print_uint(PRINT_ANY, "ptype", " ptype %u", ptype);
> }
> + if (tb[TCA_SKBEDIT_FLAGS] != NULL) {
> + flags = RTA_DATA(tb[TCA_SKBEDIT_FLAGS]);
> + if (*flags & SKBEDIT_F_INHERITDSFIELD)
> + fprintf(f, " inherit DS field ");
> + }
Please align the output syntax with the input syntax. Traditionally
iproute2 command output can be just used for input, even though
it is no longer true now.
^ permalink raw reply
* info!!
From: Lee Morrow @ 2018-07-11 17:18 UTC (permalink / raw)
To: netdev
Top of the day to you, this is in respect of a very beneficial transaction which you would not want to let go reply for more details,
Regards,
Lee
^ permalink raw reply
* Re: [net] sch_fq_codel: zero q->flows_cnt when fq_codel_init fails
From: Cong Wang @ 2018-07-10 20:32 UTC (permalink / raw)
To: Jacob Keller; +Cc: Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <20180709153559.22279-1-jacob.e.keller@intel.com>
On Mon, Jul 9, 2018 at 8:37 AM Jacob Keller <jacob.e.keller@intel.com> wrote:
> +alloc_failure:
> + kfree(q->flows);
You need to call kvfree() instead.
Other than this,
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
For net-next, I will send a patch to skip ->reset() for ->init() failure
case, there is no reason to reset queues since qdisc is not even
activated.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox