* [PATCH] tipc: fix an interrupt unsafe locking scenario
From: Ying Xue @ 2018-08-07 7:52 UTC (permalink / raw)
To: netdev, jon.maloy; +Cc: tipc-discussion, davem
Commit 9faa89d4ed9d ("tipc: make function tipc_net_finalize() thread
safe") tries to make it thread safe to set node address, so it uses
node_list_lock lock to serialize the whole process of setting node
address in tipc_net_finalize(). But it causes the following interrupt
unsafe locking scenario:
CPU0 CPU1
---- ----
rht_deferred_worker()
rhashtable_rehash_table()
lock(&(&ht->lock)->rlock)
tipc_nl_compat_doit()
tipc_net_finalize()
local_irq_disable();
lock(&(&tn->node_list_lock)->rlock);
tipc_sk_reinit()
rhashtable_walk_enter()
lock(&(&ht->lock)->rlock);
<Interrupt>
tipc_disc_rcv()
tipc_node_check_dest()
tipc_node_create()
lock(&(&tn->node_list_lock)->rlock);
*** DEADLOCK ***
When rhashtable_rehash_table() holds ht->lock on CPU0, it doesn't
disable BH. So if an interrupt happens after the lock, it can create
an inverse lock ordering between ht->lock and tn->node_list_lock. As
a consequence, deadlock might happen.
The reason causing the inverse lock ordering scenario above is because
the initial purpose of node_list_lock is not designed to do the
serialization of node address setting.
As cmpxchg() can guarantee CAS (compare-and-swap) process is atomic,
we use it to replace node_list_lock to ensure setting node address can
be atomically finished. It turns out the potential deadlock can be
avoided as well.
Fixes: 9faa89d4ed9d ("tipc: make function tipc_net_finalize() thread safe")
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/net.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/tipc/net.c b/net/tipc/net.c
index a7f6964..62199cf 100644
--- a/net/tipc/net.c
+++ b/net/tipc/net.c
@@ -123,15 +123,13 @@ void tipc_net_finalize(struct net *net, u32 addr)
{
struct tipc_net *tn = tipc_net(net);
- spin_lock_bh(&tn->node_list_lock);
- if (!tipc_own_addr(net)) {
+ if (!cmpxchg(&tn->node_addr, 0, addr)) {
tipc_set_node_addr(net, addr);
tipc_named_reinit(net);
tipc_sk_reinit(net);
tipc_nametbl_publish(net, TIPC_CFG_SRV, addr, addr,
TIPC_CLUSTER_SCOPE, 0, addr);
}
- spin_unlock_bh(&tn->node_list_lock);
}
void tipc_net_stop(struct net *net)
--
2.7.4
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* Re: e1000e driver stuck at 10Mbps after reconnection
From: Camille Bordignon @ 2018-08-07 6:42 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Jeff Kirsher, David S. Miller, intel-wired-lan, Netdev
In-Reply-To: <CAKgT0UcUV8bQRAhyevfnvwE+yWnWjwAkH0WumUoUK4Fa9SCzhg@mail.gmail.com>
Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> <camille.bordignon@easymile.com> wrote:
> > Hello,
> >
> > Recently we experienced some issues with intel NIC (I219-LM and I219-V).
> > It seems that after a wire reconnection, auto-negotation "fails" and
> > link speed drips to 10 Mbps.
> >
> > From kernel logs:
> > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
> > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
> >
> >
> > $ethtool enp0s31f6
> > Settings for enp0s31f6:
> > Supported ports: [ TP ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Supported pause frame use: No
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Advertised pause frame use: No
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Speed: 10Mb/s
> > Duplex: Full
> > Port: Twisted Pair
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > MDI-X: on (auto)
> > Supports Wake-on: pumbg
> > Wake-on: g
> > Current message level: 0x00000007 (7)
> > drv probe link
> > Link detected: yes
> >
> >
> > Notice that if disconnection last less than about 5 seconds,
> > nothing wrong happens.
> > And if after last failure, disconnection / connection occurs again and
> > last less than 5 seconds, link speed is back to 1000 Mbps.
> >
> > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
> >
> > The following patch seems to fix this issue.
> > However I don't clearly understand why.
> >
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> > index 3ba0c90e7055..763c013960f1 100644
> > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
> > case e1000_media_type_copper:
> > if (hw->mac.get_link_status) {
> > ret_val = hw->mac.ops.check_for_link(hw);
> > - link_active = !hw->mac.get_link_status;
> > + link_active = false;
> > } else {
> > link_active = true;
> > }
> >
> > Maybe this is related to watchdog task.
> >
> > I've found out this fix by comparing with last commit that works fine :
> > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > However I don't know if this information is relevant.
> >
> > Thank you.
> > Camille Bordignon
>
> What kernel were you testing this on? I know there have been a number
> of changes over the past few months in this area and it would be
> useful to know exactly what code base you started out with and what
> the latest version of the kernel is you have tested.
>
> Looking over the code change the net effect of it should be to add a 2
> second delay from the time the link has changed until you actually
> check the speed/duplex configuration. It is possible we could be
> seeing some sort of timing issue and adding the 2 second delay after
> the link event is enough time for things to stabilize and detect the
> link at 1000 instead of 10/100.
>
> - Alex
We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
Then I've tested wth a more recent version of the driver v4.18-rc7 but
behavior looks the same.
Thanks for you reply.
Camille Bordignon
^ permalink raw reply
* [PATCH 0/3] net: macb: add pad and fcs support
From: Claudiu Beznea @ 2018-08-07 9:25 UTC (permalink / raw)
To: nicolas.ferre, davem
Cc: netdev, linux-kernel, harinik, jennifer.dahm, nathan.sullivan,
rafalo, harinikatakamlinux, Claudiu Beznea
Hi,
In [1] it was reported that UDP checksum is offloaded to hardware no mather
it was previously computed in software or not. The proposal on [1] was to
disable TX checksum offload.
This series (mostly patch 3/3) address the issue described at [1] by
setting NOCRC bit to TX buffer descriptor for SKBs that arrived from
networking stack with checksum computed. For these packets padding and FCS
need to be added (hardware doesn't compute them if NOCRC bit is set). The
minimum packet size that hardware expects is 64 bytes (including FCS).
This feature could not be used in case of GSO, so, it was used only for
no GSO SKBs.
For SKBs wich requires padding and FCS computation macb_pad_and_fcs()
checks if there is enough headroom and tailroom in SKB to avoid copying
SKB structure. Since macb_pad_and_fcs() may change SKB the
macb_pad_and_fcs() was places in macb_start_xmit() b/w macb_csum_clear()
and skb_headlen() calls.
This patch was tested with pktgen in kernel tool in a script like this:
(pktgen_sample01_simple.sh is at [2]):
minSize=1
maxSize=1500
for i in `seq $minSize $maxSize` ; do
copy="$(shuf -i 1-2000 -n 1)"
./pktgen_sample01_simple.sh -i eth0 \
-m <dst-mac-addr> -d <dst-ip-addr> -x -s $i -c $copy
done
minStep=1
maxStep=200
for i in `seq $minStep $maxStep` ; do
copy="$(shuf -i 1-2000 -n 1)"
size="$(shuf -i 1-1500 -n 1)"
./pktgen_sample01_simple.sh -i eth0 \
-m <dst-mac-addr> -d <dst-ip-addr> -x -s $size -c $copy
done
Changes since RFC:
- in patch 3/3 order local variables by their lenght (reverse christmas tree
format)
[1] https://www.spinics.net/lists/netdev/msg505065.html
[2] https://github.com/netoptimizer/network-testing/blob/master/pktgen/pktgen_sample01_simple.sh
Claudiu Beznea (3):
net: macb: use netdev_tx_t return type for ndo_start_xmit functions
net: macb: move checksum clearing outside of spinlock.
net: macb: add support for padding and fcs computation
drivers/net/ethernet/cadence/macb_main.c | 88 +++++++++++++++++++++++++++++---
1 file changed, 80 insertions(+), 8 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] net: macb: use netdev_tx_t return type for ndo_start_xmit functions
From: Claudiu Beznea @ 2018-08-07 9:25 UTC (permalink / raw)
To: nicolas.ferre, davem
Cc: netdev, linux-kernel, harinik, jennifer.dahm, nathan.sullivan,
rafalo, harinikatakamlinux, Claudiu Beznea
In-Reply-To: <1533633914-30264-1-git-send-email-claudiu.beznea@microchip.com>
Use netdev_tx_t return type for ndo_start_xmit function of macb driver.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
drivers/net/ethernet/cadence/macb_main.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 96cc03a6d942..860436474c3e 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1651,7 +1651,7 @@ static inline int macb_clear_csum(struct sk_buff *skb)
return 0;
}
-static int macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
u16 queue_index = skb_get_queue_mapping(skb);
struct macb *bp = netdev_priv(dev);
@@ -1660,6 +1660,7 @@ static int macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
unsigned int desc_cnt, nr_frags, frag_size, f;
unsigned int hdrlen;
bool is_lso, is_udp = 0;
+ netdev_tx_t ret = NETDEV_TX_OK;
is_lso = (skb_shinfo(skb)->gso_size != 0);
@@ -1739,7 +1740,7 @@ static int macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
unlock:
spin_unlock_irqrestore(&bp->lock, flags);
- return NETDEV_TX_OK;
+ return ret;
}
static void macb_init_rx_buffer_size(struct macb *bp, size_t size)
@@ -3547,7 +3548,8 @@ static int at91ether_close(struct net_device *dev)
}
/* Transmit packet */
-static int at91ether_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t at91ether_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
struct macb *lp = netdev_priv(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] net: macb: add support for padding and fcs computation
From: Claudiu Beznea @ 2018-08-07 9:25 UTC (permalink / raw)
To: nicolas.ferre, davem
Cc: netdev, linux-kernel, harinik, jennifer.dahm, nathan.sullivan,
rafalo, harinikatakamlinux, Claudiu Beznea
In-Reply-To: <1533633914-30264-1-git-send-email-claudiu.beznea@microchip.com>
For packets with computed IP/TCP/UDP checksum there is no need to tell
hardware to recompute it. For such kind of packets hardware expects the
packet to be at least 64 bytes and FCS to be computed.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
drivers/net/ethernet/cadence/macb_main.c | 70 ++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 1c12afe4a0ce..c16a4b947688 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -10,6 +10,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/clk.h>
+#include <linux/crc32.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/kernel.h>
@@ -1565,6 +1566,9 @@ static unsigned int macb_tx_map(struct macb *bp,
if (i == queue->tx_head) {
ctrl |= MACB_BF(TX_LSO, lso_ctrl);
ctrl |= MACB_BF(TX_TCP_SEQ_SRC, seq_ctrl);
+ if ((bp->dev->features & NETIF_F_HW_CSUM) &&
+ skb->ip_summed != CHECKSUM_PARTIAL && !lso_ctrl)
+ ctrl |= MACB_BIT(TX_NOCRC);
} else
/* Only set MSS/MFS on payload descriptors
* (second or later descriptor)
@@ -1651,6 +1655,67 @@ static inline int macb_clear_csum(struct sk_buff *skb)
return 0;
}
+static int macb_pad_and_fcs(struct sk_buff **skb, struct net_device *ndev)
+{
+ bool cloned = skb_cloned(*skb) || skb_header_cloned(*skb);
+ int padlen = ETH_ZLEN - (*skb)->len;
+ int headroom = skb_headroom(*skb);
+ int tailroom = skb_tailroom(*skb);
+ struct sk_buff *nskb;
+ u32 fcs;
+
+ if (!(ndev->features & NETIF_F_HW_CSUM) ||
+ !((*skb)->ip_summed != CHECKSUM_PARTIAL) ||
+ skb_shinfo(*skb)->gso_size) /* Not available for GSO */
+ return 0;
+
+ if (padlen <= 0) {
+ /* FCS could be appeded to tailroom. */
+ if (tailroom >= ETH_FCS_LEN)
+ goto add_fcs;
+ /* FCS could be appeded by moving data to headroom. */
+ else if (!cloned && headroom + tailroom >= ETH_FCS_LEN)
+ padlen = 0;
+ /* No room for FCS, need to reallocate skb. */
+ else
+ padlen = ETH_FCS_LEN - tailroom;
+ } else {
+ /* Add room for FCS. */
+ padlen += ETH_FCS_LEN;
+ }
+
+ if (!cloned && headroom + tailroom >= padlen) {
+ (*skb)->data = memmove((*skb)->head, (*skb)->data, (*skb)->len);
+ skb_set_tail_pointer(*skb, (*skb)->len);
+ } else {
+ nskb = skb_copy_expand(*skb, 0, padlen, GFP_ATOMIC);
+ if (!nskb)
+ return -ENOMEM;
+
+ dev_kfree_skb_any(*skb);
+ *skb = nskb;
+ }
+
+ if (padlen) {
+ if (padlen >= ETH_FCS_LEN)
+ skb_put_zero(*skb, padlen - ETH_FCS_LEN);
+ else
+ skb_trim(*skb, ETH_FCS_LEN - padlen);
+ }
+
+add_fcs:
+ /* set FCS to packet */
+ fcs = crc32_le(~0, (*skb)->data, (*skb)->len);
+ fcs = ~fcs;
+
+ skb_put_u8(*skb, fcs & 0xff);
+ skb_put_u8(*skb, (fcs >> 8) & 0xff);
+ skb_put_u8(*skb, (fcs >> 16) & 0xff);
+ skb_put_u8(*skb, (fcs >> 24) & 0xff);
+
+ return 0;
+}
+
static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
u16 queue_index = skb_get_queue_mapping(skb);
@@ -1667,6 +1732,11 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
return ret;
}
+ if (macb_pad_and_fcs(&skb, dev)) {
+ dev_kfree_skb_any(skb);
+ return ret;
+ }
+
is_lso = (skb_shinfo(skb)->gso_size != 0);
if (is_lso) {
--
2.7.4
^ permalink raw reply related
* [PATCH v4] can: sja1000: plx_pci: add support for ASEM CAN raw device
From: Flavio Suligoi @ 2018-08-07 7:17 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: David S . Miller, linux-can, netdev, linux-kernel, Flavio Suligoi
In-Reply-To: <53dae6d6-c25b-71d5-b43f-1d444d9c352b@pengutronix.de>
This patch adds support for ASEM opto-isolated dual channels
CAN raw device (http://www.asem.it)
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
v2: - rename ASEM_... constants to reduce space size;
- remove "else" in "plx_pci_reset_asem_dual_can_raw" function to avoid
strings breaking
v3: - fix wrong comment for PLX_LINT2_POL
- put string into just one line in "plx_pci_reset_asem_dual_can_raw"
function
v4: - remove unnecessary variable "reset_bar" in
"plx_pci_reset_asem_dual_can_raw" function
drivers/net/can/sja1000/Kconfig | 1 +
drivers/net/can/sja1000/plx_pci.c | 66 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
index 1e65cb6..f6dc899 100644
--- a/drivers/net/can/sja1000/Kconfig
+++ b/drivers/net/can/sja1000/Kconfig
@@ -88,6 +88,7 @@ config CAN_PLX_PCI
- TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/)
- IXXAT Automation PC-I 04/PCI card (http://www.ixxat.com/)
- Connect Tech Inc. CANpro/104-Plus Opto (CRG001) card (http://www.connecttech.com)
+ - ASEM CAN raw - 2 isolated CAN channels (www.asem.it)
config CAN_TSCAN1
tristate "TS-CAN1 PC104 boards"
diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
index f8ff25c..79fc327 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -46,7 +46,8 @@ MODULE_SUPPORTED_DEVICE("Adlink PCI-7841/cPCI-7841, "
"esd CAN-PCIe/2000, "
"Connect Tech Inc. CANpro/104-Plus Opto (CRG001), "
"IXXAT PC-I 04/PCI, "
- "ELCUS CAN-200-PCI")
+ "ELCUS CAN-200-PCI, "
+ "ASEM DUAL CAN-RAW")
MODULE_LICENSE("GPL v2");
#define PLX_PCI_MAX_CHAN 2
@@ -70,7 +71,9 @@ struct plx_pci_card {
*/
#define PLX_LINT1_EN 0x1 /* Local interrupt 1 enable */
+#define PLX_LINT1_POL (1 << 1) /* Local interrupt 1 polarity */
#define PLX_LINT2_EN (1 << 3) /* Local interrupt 2 enable */
+#define PLX_LINT2_POL (1 << 4) /* Local interrupt 2 polarity */
#define PLX_PCI_INT_EN (1 << 6) /* PCI Interrupt Enable */
#define PLX_PCI_RESET (1 << 30) /* PCI Adapter Software Reset */
@@ -92,6 +95,9 @@ struct plx_pci_card {
*/
#define PLX_PCI_OCR (OCR_TX0_PUSHPULL | OCR_TX1_PUSHPULL)
+/* OCR setting for ASEM Dual CAN raw */
+#define ASEM_PCI_OCR 0xfe
+
/*
* In the CDR register, you should set CBP to 1.
* You will probably also want to set the clock divider value to 7
@@ -145,10 +151,20 @@ struct plx_pci_card {
#define MOXA_PCI_VENDOR_ID 0x1393
#define MOXA_PCI_DEVICE_ID 0x0100
+#define ASEM_RAW_CAN_VENDOR_ID 0x10b5
+#define ASEM_RAW_CAN_DEVICE_ID 0x9030
+#define ASEM_RAW_CAN_SUB_VENDOR_ID 0x3000
+#define ASEM_RAW_CAN_SUB_DEVICE_ID 0x1001
+#define ASEM_RAW_CAN_SUB_DEVICE_ID_BIS 0x1002
+#define ASEM_RAW_CAN_RST_REGISTER 0x54
+#define ASEM_RAW_CAN_RST_MASK_CAN1 0x20
+#define ASEM_RAW_CAN_RST_MASK_CAN2 0x04
+
static void plx_pci_reset_common(struct pci_dev *pdev);
static void plx9056_pci_reset_common(struct pci_dev *pdev);
static void plx_pci_reset_marathon_pci(struct pci_dev *pdev);
static void plx_pci_reset_marathon_pcie(struct pci_dev *pdev);
+static void plx_pci_reset_asem_dual_can_raw(struct pci_dev *pdev);
struct plx_pci_channel_map {
u32 bar;
@@ -269,6 +285,14 @@ static struct plx_pci_card_info plx_pci_card_info_moxa = {
/* based on PLX9052 */
};
+static struct plx_pci_card_info plx_pci_card_info_asem_dual_can = {
+ "ASEM Dual CAN raw PCI", 2,
+ PLX_PCI_CAN_CLOCK, ASEM_PCI_OCR, PLX_PCI_CDR,
+ {0, 0x00, 0x00}, { {2, 0x00, 0x00}, {4, 0x00, 0x00} },
+ &plx_pci_reset_asem_dual_can_raw
+ /* based on PLX9030 */
+};
+
static const struct pci_device_id plx_pci_tbl[] = {
{
/* Adlink PCI-7841/cPCI-7841 */
@@ -375,6 +399,20 @@ static const struct pci_device_id plx_pci_tbl[] = {
0, 0,
(kernel_ulong_t)&plx_pci_card_info_moxa
},
+ {
+ /* ASEM Dual CAN raw */
+ ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
+ ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID,
+ 0, 0,
+ (kernel_ulong_t)&plx_pci_card_info_asem_dual_can
+ },
+ {
+ /* ASEM Dual CAN raw -new model */
+ ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
+ ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID_BIS,
+ 0, 0,
+ (kernel_ulong_t)&plx_pci_card_info_asem_dual_can
+ },
{ 0,}
};
MODULE_DEVICE_TABLE(pci, plx_pci_tbl);
@@ -524,6 +562,32 @@ static void plx_pci_reset_marathon_pcie(struct pci_dev *pdev)
}
}
+/* Special reset function for ASEM Dual CAN raw card */
+static void plx_pci_reset_asem_dual_can_raw(struct pci_dev *pdev)
+{
+ void __iomem *bar0_addr;
+ u8 tmpval;
+
+ plx_pci_reset_common(pdev);
+
+ bar0_addr = pci_iomap(pdev, 0, 0);
+ if (!bar0_addr) {
+ dev_err(&pdev->dev, "Failed to remap reset space %d (BAR%d)\n",
+ 0, 0);
+ return;
+ }
+
+ /* reset the two SJA1000 chips */
+ tmpval = ioread8(bar0_addr + ASEM_RAW_CAN_RST_REGISTER);
+ tmpval &= ~(ASEM_RAW_CAN_RST_MASK_CAN1 | ASEM_RAW_CAN_RST_MASK_CAN2);
+ iowrite8(tmpval, bar0_addr + ASEM_RAW_CAN_RST_REGISTER);
+ usleep_range(300, 400);
+ tmpval |= ASEM_RAW_CAN_RST_MASK_CAN1 | ASEM_RAW_CAN_RST_MASK_CAN2;
+ iowrite8(tmpval, bar0_addr + ASEM_RAW_CAN_RST_REGISTER);
+ usleep_range(300, 400);
+ pci_iounmap(pdev, bar0_addr);
+}
+
static void plx_pci_del_card(struct pci_dev *pdev)
{
struct plx_pci_card *card = pci_get_drvdata(pdev);
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH 0/2] net: macb: Disable TX checksum offloading on all Zynq
From: Claudiu Beznea @ 2018-08-07 8:50 UTC (permalink / raw)
To: Harini Katakam, Jennifer Dahm
Cc: netdev, David S . Miller, Nathan Sullivan, Rafal Ozieblo,
Harini Katakam, Nicolas Ferre
In-Reply-To: <CAFcVEC+q1Z=QBD67afVgXrh5khMUDoRmt9c2we2=780JEW0njA@mail.gmail.com>
Hi Harini,
On 01.08.2018 15:53, Harini Katakam wrote:
> Hi Jennifer,
>
> On Tue, Jun 5, 2018 at 10:21 AM, Harini Katakam <harinik@xilinx.com> wrote:
>> Hi Jeniffer,
>>
>> On Mon, Jun 4, 2018 at 8:35 PM, Nicolas Ferre
>> <nicolas.ferre@microchip.com> wrote:
>>> Jennifer,
>>>
>>> On 25/05/2018 at 23:44, Jennifer Dahm wrote:
>>>>
>>>> During testing, I discovered that the Zynq GEM hardware overwrites all
>>>> outgoing UDP packet checksums, which is illegal in packet forwarding
>>>> cases. This happens both with and without the checksum-zeroing
>>>> behavior introduced in 007e4ba3ee137f4700f39aa6dbaf01a71047c5f6
>>>> ("net: macb: initialize checksum when using checksum offloading"). The
>>>> only solution to both the small packet bug and the packet forwarding
>>>> bug that I can find is to disable TX checksum offloading entirely.
>>>
>>>
>>
>> Thanks for the extensive testing.
>> I'll try to reproduce and see if it is something to be fixed in the driver.
>>
>>> Are the bugs listed above present in all revisions of the GEM IP, only for
>>> some revisions?
>>> Is there an errata that describe this issue for the Zynq GEM?
>>
>> @Nicolas, AFAIK, there is no errata for this in either Cadence or
>> Zynq documentation.
>
> I was unable to reproduce this issue on Zynq.
> Although I do not have HW with two GEM ports,
> I tried by routing one GEM via PL and another via on board RGMII.
> Since there was no specific errata related to this, I also tried on
> subsequent ZynqMP versions with multiple GEM ports but dint find any
> checksum issues. I discussed the same with cadence and they
> tried the test with 2 bytes of UDP payload on the Zynq GEM IP
> version in their regressions and did not hit any issue either.
>
> I tried to reach out earlier to see if you can share your exact
> application. Could you please let me know if you have any
> further updates?
I manage to reproduce the issue and provide a patch for this (see patch 3/3
from [1]).
[1] https://www.spinics.net/lists/netdev/msg513848.html
>
> Regards,
> Harini
>
^ permalink raw reply
* KASAN: use-after-free Read in iotlb_access_ok
From: syzbot @ 2018-08-07 11:16 UTC (permalink / raw)
To: jasowang, kvm, linux-kernel, mst, netdev, syzkaller-bugs,
virtualization
Hello,
syzbot found the following crash on:
HEAD commit: e30cb13c5a09 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10a153e0400000
kernel config: https://syzkaller.appspot.com/x/.config?x=2dc0cd7c2eefb46f
dashboard link: https://syzkaller.appspot.com/bug?extid=c51e6736a1bf614b3272
compiler: gcc (GCC) 8.0.1 20180413 (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+c51e6736a1bf614b3272@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in vhost_vq_meta_fetch drivers/vhost/vhost.c:702
[inline]
BUG: KASAN: use-after-free in iotlb_access_ok+0x5c9/0x600
drivers/vhost/vhost.c:1177
Read of size 8 at addr ffff880197df2fc0 by task vhost-8938/8941
CPU: 0 PID: 8941 Comm: vhost-8938 Not tainted 4.18.0-rc7+ #174
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+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
vhost_vq_meta_fetch drivers/vhost/vhost.c:702 [inline]
iotlb_access_ok+0x5c9/0x600 drivers/vhost/vhost.c:1177
vq_iotlb_prefetch+0x10e/0x230 drivers/vhost/vhost.c:1214
handle_rx+0x247/0x1f80 drivers/vhost/net.c:799
handle_rx_net+0x19/0x20 drivers/vhost/net.c:934
vhost_worker+0x283/0x490 drivers/vhost/vhost.c:360
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
Allocated by task 8938:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
vhost_new_umem_range+0xcb/0x7c0 drivers/vhost/vhost.c:911
vhost_process_iotlb_msg drivers/vhost/vhost.c:1000 [inline]
vhost_chr_write_iter+0xe53/0x1a00 drivers/vhost/vhost.c:1043
vhost_net_chr_write_iter+0x59/0x70 drivers/vhost/net.c:1399
call_write_iter include/linux/fs.h:1793 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6c6/0x9f0 fs/read_write.c:487
vfs_write+0x1f8/0x560 fs/read_write.c:549
ksys_write+0x101/0x260 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 8950:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
vhost_umem_free+0x944/0x14d0 drivers/vhost/vhost.c:576
vhost_umem_clean+0x83/0xf0 drivers/vhost/vhost.c:588
vhost_init_device_iotlb+0x1d7/0x290 drivers/vhost/vhost.c:1568
vhost_net_set_features drivers/vhost/net.c:1292 [inline]
vhost_net_ioctl+0xff3/0x1a80 drivers/vhost/net.c:1357
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
__do_sys_ioctl fs/ioctl.c:708 [inline]
__se_sys_ioctl fs/ioctl.c:706 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff880197df2f80
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 64 bytes inside of
96-byte region [ffff880197df2f80, ffff880197df2fe0)
The buggy address belongs to the page:
page:ffffea00065f7c80 count:1 mapcount:0 mapping:ffff8801dac004c0 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea0007530148 ffffea000663b888 ffff8801dac004c0
raw: 0000000000000000 ffff880197df2000 0000000100000020 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff880197df2e80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff880197df2f00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff880197df2f80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff880197df3000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff880197df3080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
---
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
* [PATCH 0/3] net: remove unneeded variable for return value
From: zhong jiang @ 2018-08-07 11:20 UTC (permalink / raw)
To: davem, anna.schumaker; +Cc: netdev, linux-kernel
zhong jiang (3):
net:svc_rdma_transport: remove unneeded variable 'ret' in
rdma_listen_handler
net:af_iucv: get rid of the unneeded variable 'err' in
afiucv_pm_freeze
net:mod: remove unneeded variable 'ret' in init_p9
net/9p/mod.c | 4 +---
net/iucv/af_iucv.c | 3 +--
net/sunrpc/xprtrdma/svc_rdma_transport.c | 3 +--
3 files changed, 3 insertions(+), 7 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH 1/3] net:svc_rdma_transport: remove unneeded variable 'ret' in rdma_listen_handler
From: zhong jiang @ 2018-08-07 11:20 UTC (permalink / raw)
To: davem, anna.schumaker; +Cc: netdev, linux-kernel
In-Reply-To: <1533640809-1221-1-git-send-email-zhongjiang@huawei.com>
The ret is not modified after initalization, So just remove the variable
and return 0.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/sunrpc/xprtrdma/svc_rdma_transport.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
index 547b2cd..2848caf 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
@@ -296,7 +296,6 @@ static int rdma_listen_handler(struct rdma_cm_id *cma_id,
struct rdma_cm_event *event)
{
struct sockaddr *sap = (struct sockaddr *)&cma_id->route.addr.src_addr;
- int ret = 0;
trace_svcrdma_cm_event(event, sap);
@@ -315,7 +314,7 @@ static int rdma_listen_handler(struct rdma_cm_id *cma_id,
break;
}
- return ret;
+ return 0;
}
static int rdma_cma_handler(struct rdma_cm_id *cma_id,
--
1.7.12.4
^ permalink raw reply related
* [PATCH 3/3] net:mod: remove unneeded variable 'ret' in init_p9
From: zhong jiang @ 2018-08-07 11:20 UTC (permalink / raw)
To: davem, anna.schumaker; +Cc: netdev, linux-kernel
In-Reply-To: <1533640809-1221-1-git-send-email-zhongjiang@huawei.com>
The ret is modified after initalization, so just remove it and
return 0.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/9p/mod.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/9p/mod.c b/net/9p/mod.c
index eb9777f..253ba82 100644
--- a/net/9p/mod.c
+++ b/net/9p/mod.c
@@ -171,13 +171,11 @@ void v9fs_put_trans(struct p9_trans_module *m)
*/
static int __init init_p9(void)
{
- int ret = 0;
-
p9_error_init();
pr_info("Installing 9P2000 support\n");
p9_trans_fd_init();
- return ret;
+ return 0;
}
/**
--
1.7.12.4
^ permalink raw reply related
* RE: [RFC PATCH 0/2] net: macb: Disable TX checksum offloading on all Zynq
From: Harini Katakam @ 2018-08-07 9:09 UTC (permalink / raw)
To: Claudiu Beznea, Jennifer Dahm
Cc: netdev@vger.kernel.org, David S . Miller, Nathan Sullivan,
Rafal Ozieblo, Nicolas Ferre,
'harinikatakamlinux@gmail.com'
In-Reply-To: <2fa65708-31f4-9236-3ed5-f2f87cdfe3b7@microchip.com>
Hi Claudiu,
> -----Original Message-----
> From: Claudiu Beznea [mailto:Claudiu.Beznea@microchip.com]
> Sent: Tuesday, August 7, 2018 2:21 PM
> To: Harini Katakam <harinik@xilinx.com>; Jennifer Dahm
> <jennifer.dahm@ni.com>
> Cc: netdev@vger.kernel.org; David S . Miller <davem@davemloft.net>; Nathan
> Sullivan <nathan.sullivan@ni.com>; Rafal Ozieblo <rafalo@cadence.com>;
> Harini Katakam <harinik@xilinx.com>; Nicolas Ferre
> <nicolas.ferre@microchip.com>
> Subject: Re: [RFC PATCH 0/2] net: macb: Disable TX checksum offloading on all
> Zynq
>
> Hi Harini,
>
> On 01.08.2018 15:53, Harini Katakam wrote:
> > Hi Jennifer,
> >
> > On Tue, Jun 5, 2018 at 10:21 AM, Harini Katakam <harinik@xilinx.com> wrote:
> >> Hi Jeniffer,
> >>
> >> On Mon, Jun 4, 2018 at 8:35 PM, Nicolas Ferre
> >> <nicolas.ferre@microchip.com> wrote:
> >>> Jennifer,
> >>>
> >>> On 25/05/2018 at 23:44, Jennifer Dahm wrote:
> >>>>
> >>>> During testing, I discovered that the Zynq GEM hardware overwrites
> >>>> all outgoing UDP packet checksums, which is illegal in packet
> >>>> forwarding cases. This happens both with and without the
> >>>> checksum-zeroing behavior introduced in
> >>>> 007e4ba3ee137f4700f39aa6dbaf01a71047c5f6
> >>>> ("net: macb: initialize checksum when using checksum offloading").
> >>>> The only solution to both the small packet bug and the packet
> >>>> forwarding bug that I can find is to disable TX checksum offloading
> entirely.
> >>>
> >>>
> >>
> >> Thanks for the extensive testing.
> >> I'll try to reproduce and see if it is something to be fixed in the driver.
> >>
> >>> Are the bugs listed above present in all revisions of the GEM IP,
> >>> only for some revisions?
> >>> Is there an errata that describe this issue for the Zynq GEM?
> >>
> >> @Nicolas, AFAIK, there is no errata for this in either Cadence or
> >> Zynq documentation.
> >
> > I was unable to reproduce this issue on Zynq.
> > Although I do not have HW with two GEM ports, I tried by routing one
> > GEM via PL and another via on board RGMII.
> > Since there was no specific errata related to this, I also tried on
> > subsequent ZynqMP versions with multiple GEM ports but dint find any
> > checksum issues. I discussed the same with cadence and they tried the
> > test with 2 bytes of UDP payload on the Zynq GEM IP version in their
> > regressions and did not hit any issue either.
> >
> > I tried to reach out earlier to see if you can share your exact
> > application. Could you please let me know if you have any further
> > updates?
>
> I manage to reproduce the issue and provide a patch for this (see patch 3/3 from
> [1]).
>
> [1] https://www.spinics.net/lists/netdev/msg513848.html
Sorry, I missed your series. Thanks.
Regards,
Harini
^ permalink raw reply
* [PATCH net-next] RDS: IB: fix 'passing zero to ERR_PTR()' warning
From: YueHaibing @ 2018-08-07 11:34 UTC (permalink / raw)
To: santosh.shilimkar, davem
Cc: linux-kernel, netdev, linux-rdma, rds-devel, YueHaibing
Fix a static code checker warning:
net/rds/ib_frmr.c:82 rds_ib_alloc_frmr() warn: passing zero to 'ERR_PTR'
The error path for ib_alloc_mr failure should set err to PTR_ERR.
Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/rds/ib_frmr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/rds/ib_frmr.c b/net/rds/ib_frmr.c
index b371cf0..6431a02 100644
--- a/net/rds/ib_frmr.c
+++ b/net/rds/ib_frmr.c
@@ -61,6 +61,7 @@ static struct rds_ib_mr *rds_ib_alloc_frmr(struct rds_ib_device *rds_ibdev,
pool->fmr_attr.max_pages);
if (IS_ERR(frmr->mr)) {
pr_warn("RDS/IB: %s failed to allocate MR", __func__);
+ err = PTR_ERR(frmr->mr);
goto out_no_cigar;
}
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] Use Kconfig flag to remove support of deprecated BE2/BE3 adapters
From: Ivan Vecera @ 2018-08-07 11:35 UTC (permalink / raw)
To: Christoph Hellwig, Petr Oros
Cc: netdev, Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna,
Somnath Kotur, David S. Miller, linux-kernel
In-Reply-To: <20180806162153.GA22040@infradead.org>
On 6.8.2018 18:21, Christoph Hellwig wrote:
> On Mon, Aug 06, 2018 at 02:12:28PM +0200, Petr Oros wrote:
>> Add flags to remove support of deprecated BE2/BE3 adapters.
>> BE2 disable will reduce .ko size by 2kb and BE3 by 3kb.
>> Disable both will reduce .ko size by 9kb.
>>
>> With dissabled support is also removed coresponding PCI IDs
>> and codepath with [BE2|BE3|BEx]_chip checks.
>
> deprecated seems like a really odd world for hardware.
>
> Are they just old? Did they never ship in large numbers?
>
> If you just make some cards optional why not also add options
> for families of newer cards for those who only have the older ones
> in their systems?
>
This also makes sense.
I.
^ permalink raw reply
* [PATCH 2/3] net: macb: move checksum clearing outside of spinlock
From: Claudiu Beznea @ 2018-08-07 9:25 UTC (permalink / raw)
To: nicolas.ferre, davem
Cc: netdev, linux-kernel, harinik, jennifer.dahm, nathan.sullivan,
rafalo, harinikatakamlinux, Claudiu Beznea
In-Reply-To: <1533633914-30264-1-git-send-email-claudiu.beznea@microchip.com>
Move checksum clearing outside of spinlock. The SKB is protected by
networking lock (HARD_TX_LOCK()).
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
drivers/net/ethernet/cadence/macb_main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 860436474c3e..1c12afe4a0ce 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1662,6 +1662,11 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
bool is_lso, is_udp = 0;
netdev_tx_t ret = NETDEV_TX_OK;
+ if (macb_clear_csum(skb)) {
+ dev_kfree_skb_any(skb);
+ return ret;
+ }
+
is_lso = (skb_shinfo(skb)->gso_size != 0);
if (is_lso) {
@@ -1717,11 +1722,6 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_BUSY;
}
- if (macb_clear_csum(skb)) {
- dev_kfree_skb_any(skb);
- goto unlock;
- }
-
/* Map socket buffer for DMA transfer */
if (!macb_tx_map(bp, queue, skb, hdrlen)) {
dev_kfree_skb_any(skb);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] Use Kconfig flag to remove support of deprecated BE2/BE3 adapters
From: Ivan Vecera @ 2018-08-07 11:44 UTC (permalink / raw)
To: David Miller, poros
Cc: netdev, sathya.perla, ajit.khaparde, sriharsha.basavapatna,
somnath.kotur, linux-kernel
In-Reply-To: <20180806.134620.124956510948789350.davem@davemloft.net>
On 6.8.2018 22:46, David Miller wrote:
> From: Petr Oros <poros@redhat.com>
> Date: Mon, 6 Aug 2018 14:12:28 +0200
>
>> Add flags to remove support of deprecated BE2/BE3 adapters.
>> BE2 disable will reduce .ko size by 2kb and BE3 by 3kb.
>> Disable both will reduce .ko size by 9kb.
>>
>> With dissabled support is also removed coresponding PCI IDs
>> and codepath with [BE2|BE3|BEx]_chip checks.
>>
>> New help style in Kconfig
>>
>> Signed-off-by: Petr Oros <poros@redhat.com>
>
> Sorry, I'm not too hot about this.
Why? This patch does not remove support for older chips, it just gives an
ability to disable support for certain chip families. In other words an user is
able to customize the driver for his/her needs - it could be fine to add this
ability also for the rest of chip families.
> Imagine being one of the people who has one of these cards.
Such people leave this configs as they are (enabled by default).
> Pulling out detection and working'ness of devices from a driver
> is a big step backwards, and I'm sorry I will don't want to be
> part of something that facilitates this.
>
> The S390 folks tried something similar in the past and I reject
> those changes too.
This patch is practically the same as "a1b8714593b6 ("net/mlx4: Use Kconfig flag
to remove support of old gen2 Mellanox devices")" for mlx4 and that was accepted
without any objections.
Thanks,
Ivan
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: introduce update_effective_progs()
From: Daniel Borkmann @ 2018-08-07 12:31 UTC (permalink / raw)
To: Roman Gushchin, netdev; +Cc: linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <20180806212728.8514-1-guro@fb.com>
On 08/06/2018 11:27 PM, Roman Gushchin wrote:
> __cgroup_bpf_attach() and __cgroup_bpf_detach() functions have
> a good amount of duplicated code, which is possible to eliminate
> by introducing the update_effective_progs() helper function.
>
> The update_effective_progs() calls compute_effective_progs()
> and then in case of success it calls activate_effective_progs()
> for each descendant cgroup. In case of failure (OOM), it releases
> allocated prog arrays and return the error code.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Song Liu <songliubraving@fb.com>
Applied to bpf-next, thanks Roman!
^ permalink raw reply
* [PATCH net-next] ceph: remove unnecessary non NULL check for request_key
From: YueHaibing @ 2018-08-07 13:02 UTC (permalink / raw)
To: davem, idryomov, zyan, sage; +Cc: linux-kernel, netdev, ceph-devel, YueHaibing
request_key never return NULL,so no need do non-NULL check.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/ceph/ceph_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ceph/ceph_common.c b/net/ceph/ceph_common.c
index 584fdbe..9834edc 100644
--- a/net/ceph/ceph_common.c
+++ b/net/ceph/ceph_common.c
@@ -304,7 +304,7 @@ static int get_secret(struct ceph_crypto_key *dst, const char *name) {
struct ceph_crypto_key *ckey;
ukey = request_key(&key_type_ceph, name, NULL);
- if (!ukey || IS_ERR(ukey)) {
+ if (IS_ERR(ukey)) {
/* request_key errors don't map nicely to mount(2)
errors; don't even try, but still printk */
key_err = PTR_ERR(ukey);
--
2.7.0
^ permalink raw reply related
* Re: [RFC bpf-next v2 3/3] docs: Split filter.txt into separate documents.
From: Jonathan Corbet @ 2018-08-07 13:14 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Daniel Borkmann, Alexei Starovoitov, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180807024844.GW3088@eros>
On Tue, 7 Aug 2018 12:48:44 +1000
"Tobin C. Harding" <me@tobin.cc> wrote:
> How about these steps:
>
> 1. start with foo.txt
> 2. do typo and grammar fixes (any number of patches).
> 3. rename to foo.rst, do whitespace changes, code snippet
> indentation, heading adornments, update references to this file.
> (single patch).
> 4. Fix up references in the file text to use RST (i.e :ref: blah)
> 5. Fix up RST markers (backticks etc). (any number of patches)
That can certainly work; just don't call it foo.rst until it actually is a
valid RST file.
And, of course, go easy with the later steps and try to avoid the
temptation to mark up everything; we really want to preserve the
readability of the plain-text files.
Thanks for doing this work!
jon
^ permalink raw reply
* AW: AW: AW: PROBLEM: Kernel Oops in UDP stack
From: Marcel Hellwig @ 2018-08-07 13:42 UTC (permalink / raw)
To: 'Eric Dumazet', 'David Laight',
'davem@davemloft.net', 'kuznet@ms2.inr.ac.ru',
'yoshfuji@linux-ipv6.org', 'andrew@lunn.ch'
Cc: 'netdev@vger.kernel.org',
'linux-kernel@vger.kernel.org', Matthias Wystrik
In-Reply-To: <936fbc1f39424adea318bcd95f50d63d@ZCOM03.mut-group.com>
>>
>> Well, this driver does not use NET_IP_ALIGN reservation, meaning IP header is not 4-byte aligned.
>>
>> No idea why mis-alignments are okay in IP layer, but not in UDP
>>
>> You could try to patch it to use netdev_alloc_skb_ip_align() instead of dev_alloc_skb()
>
> Looks very promising! CPU runs for 3 hours and no panic so far. Let's hope it survives the weekend! *fingers crossed* The strange thing I don't understand is, why does the 3.5.7 kernel does not crash (or 4.17.12, yes I managed to run a recent kernel on our machine! \o/ )? It does not use netdev_alloc_skb_ip_align either[0][1], but one thing, that I noticed it, that there is a difference in /proc/iomem
>
> 3.4.113
> # cat /proc/iomem
> 08000000-0801ffff : lpc-eth.0
> 31060000-31060fff : lpc-eth.0
> 40088000-4008801f : serial
> [...]
>
> 3.5.7
> # cat /proc/iomem
> 20084000-20084fff : /ahb/apb/ssp@20084000
> 2008c000-2008cfff : /ahb/apb/ssp@2008c000
> 31000000-31000fff : /ahb/dma@31000000
> 40088000-4008801f : serial
> [...]
>
> As you notice lpc-eth.0 (or 31060000.ethernet as it's called nowadays) is not listed, so my guess it is served by DMA?
>
> May that the reason why it does not crash (Notice: 3.5.7 runs via device tree file)?
>
> So just my thought: If I would disable dma (somehow) would the error still occur in today's kernel?
I think, that it is implicitly aligned today (I think!), so that's the reason why the oops does not occur anymore.
Our machines survived the 4 days now, so we are very confident, that this solved the problem for us!
Thank you very much, you all helped us a lot!
Mit freundlichen Grüßen / With kind regards
Marcel Hellwig
B. Sc. Informatik
Entwickler
m-u-t GmbH
Am Marienhof 2
22880 Wedel
Germany
Phone: +49 4103 9308 - 474
Fax: +49 4103 9308 - 99
mhellwig@mut-group.com
www.mut-group.com
Geschäftsführer (Managing Director): Fabian Peters Amtsgericht Pinneberg (Commercial Register No.): HRB 10304 PI USt-IdNr. (VAT-No.): DE228275390
WEEE-Reg-Nr.: DE 72271808
^ permalink raw reply
* [PATCH 2/3] net:af_iucv: get rid of the unneeded variable 'err' in afiucv_pm_freeze
From: zhong jiang @ 2018-08-07 11:20 UTC (permalink / raw)
To: davem, anna.schumaker; +Cc: netdev, linux-kernel
In-Reply-To: <1533640809-1221-1-git-send-email-zhongjiang@huawei.com>
We will not use the variable 'err' after initalization, So remove it and
return 0.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/iucv/af_iucv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index 92ee91e..a21d8ed 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -150,7 +150,6 @@ static int afiucv_pm_freeze(struct device *dev)
{
struct iucv_sock *iucv;
struct sock *sk;
- int err = 0;
#ifdef CONFIG_PM_DEBUG
printk(KERN_WARNING "afiucv_pm_freeze\n");
@@ -175,7 +174,7 @@ static int afiucv_pm_freeze(struct device *dev)
skb_queue_purge(&iucv->backlog_skb_q);
}
read_unlock(&iucv_sk_list.lock);
- return err;
+ return 0;
}
/**
--
1.7.12.4
^ permalink raw reply related
* RE: [PATCH net-next] [RFC] dpaa2-eth: Move DPAA2 Ethernet driver from staging to drivers/net
From: Ioana Ciocoi Radulescu @ 2018-08-07 13:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: devel@driverdev.osuosl.org, Horia Geanta,
gregkh@linuxfoundation.org, netdev@vger.kernel.org,
Madalin-cristian Bucur, linux-kernel@vger.kernel.org,
Ioana Ciornei, davem@davemloft.net, Laurentiu Tudor
In-Reply-To: <20180803164239.GG15029@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, August 3, 2018 7:43 PM
> To: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
> Cc: netdev@vger.kernel.org; davem@davemloft.net;
> gregkh@linuxfoundation.org; devel@driverdev.osuosl.org; linux-
> kernel@vger.kernel.org; Ioana Ciornei <ioana.ciornei@nxp.com>; Laurentiu
> Tudor <laurentiu.tudor@nxp.com>; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Horia Geanta <horia.geanta@nxp.com>
> Subject: Re: [PATCH net-next] [RFC] dpaa2-eth: Move DPAA2 Ethernet driver
> from staging to drivers/net
>
> > +static int dpaa2_eth_probe(struct fsl_mc_device *dpni_dev)
> > +{
> > + struct device *dev;
> > + struct net_device *net_dev = NULL;
> > + struct dpaa2_eth_priv *priv = NULL;
> > + int err = 0;
> > +
> > + dev = &dpni_dev->dev;
> > +
> > + /* Net device */
> > + net_dev = alloc_etherdev_mq(sizeof(*priv),
> DPAA2_ETH_MAX_TX_QUEUES);
> > + if (!net_dev) {
> > + dev_err(dev, "alloc_etherdev_mq() failed\n");
> > + return -ENOMEM;
> > + }
> > +
> > + SET_NETDEV_DEV(net_dev, dev);
> > + dev_set_drvdata(dev, net_dev);
> > +
> > + priv = netdev_priv(net_dev);
> > + priv->net_dev = net_dev;
> > +
> > + priv->iommu_domain = iommu_get_domain_for_dev(dev);
> > +
> > + /* Obtain a MC portal */
> > + err = fsl_mc_portal_allocate(dpni_dev,
> FSL_MC_IO_ATOMIC_CONTEXT_PORTAL,
> > + &priv->mc_io);
> > + if (err) {
> > + if (err == -ENXIO)
> > + err = -EPROBE_DEFER;
> > + else
> > + dev_err(dev, "MC portal allocation failed\n");
> > + goto err_portal_alloc;
> > + }
> > +
> > + /* MC objects initialization and configuration */
> > + err = setup_dpni(dpni_dev);
> > + if (err)
> > + goto err_dpni_setup;
> > +
> > + err = setup_dpio(priv);
> > + if (err)
> > + goto err_dpio_setup;
> > +
> > + setup_fqs(priv);
> > +
> > + err = setup_dpbp(priv);
> > + if (err)
> > + goto err_dpbp_setup;
> > +
> > + err = bind_dpni(priv);
> > + if (err)
> > + goto err_bind;
> > +
> > + /* Add a NAPI context for each channel */
> > + add_ch_napi(priv);
> > +
> > + /* Percpu statistics */
> > + priv->percpu_stats = alloc_percpu(*priv->percpu_stats);
> > + if (!priv->percpu_stats) {
> > + dev_err(dev, "alloc_percpu(percpu_stats) failed\n");
> > + err = -ENOMEM;
> > + goto err_alloc_percpu_stats;
> > + }
> > + priv->percpu_extras = alloc_percpu(*priv->percpu_extras);
> > + if (!priv->percpu_extras) {
> > + dev_err(dev, "alloc_percpu(percpu_extras) failed\n");
> > + err = -ENOMEM;
> > + goto err_alloc_percpu_extras;
> > + }
> > +
> > + err = netdev_init(net_dev);
> > + if (err)
> > + goto err_netdev_init;
>
> At the end of netdev_init() you call netdev_register(). From that
> point on, you device is live. Its .ndo's can be called....
>
> > +
> > + /* Configure checksum offload based on current interface flags */
> > + err = set_rx_csum(priv, !!(net_dev->features & NETIF_F_RXCSUM));
> > + if (err)
> > + goto err_csum;
> > +
> > + err = set_tx_csum(priv, !!(net_dev->features &
> > + (NETIF_F_IP_CSUM |
> NETIF_F_IPV6_CSUM)));
> > + if (err)
> > + goto err_csum;
> > +
> > + err = alloc_rings(priv);
> > + if (err)
> > + goto err_alloc_rings;
>
> How well does the device work if it has not allocated the rings yet,
> when it is asked to do something?
>
> > +
> > + net_dev->ethtool_ops = &dpaa2_ethtool_ops;
> > +
> > + err = setup_irqs(dpni_dev);
>
> How well do it work without interrupts being set up?
>
> > + if (err) {
> > + netdev_warn(net_dev, "Failed to set link interrupt, fall back
> to polling\n");
> > + priv->poll_thread = kthread_run(poll_link_state, priv,
> > + "%s_poll_link", net_dev-
> >name);
> > + if (IS_ERR(priv->poll_thread)) {
> > + netdev_err(net_dev, "Error starting polling
> thread\n");
> > + goto err_poll_thread;
> > + }
> > + priv->do_link_poll = true;
> > + }
>
> Probably the correct place to register the netdev is here.
Good point, I'll fix it in v2.
Thanks a lot,
Ioana
^ permalink raw reply
* Re: [PATCH v4] can: sja1000: plx_pci: add support for ASEM CAN raw device
From: Marc Kleine-Budde @ 2018-08-07 14:11 UTC (permalink / raw)
To: Flavio Suligoi, Wolfgang Grandegger
Cc: David S . Miller, linux-can, netdev, linux-kernel
In-Reply-To: <1533626239-4065-1-git-send-email-f.suligoi@asem.it>
[-- Attachment #1.1: Type: text/plain, Size: 5641 bytes --]
On 08/07/2018 09:17 AM, Flavio Suligoi wrote:
> This patch adds support for ASEM opto-isolated dual channels
> CAN raw device (http://www.asem.it)
>
> Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
> ---
>
> v2: - rename ASEM_... constants to reduce space size;
> - remove "else" in "plx_pci_reset_asem_dual_can_raw" function to avoid
> strings breaking
> v3: - fix wrong comment for PLX_LINT2_POL
> - put string into just one line in "plx_pci_reset_asem_dual_can_raw"
> function
> v4: - remove unnecessary variable "reset_bar" in
> "plx_pci_reset_asem_dual_can_raw" function
>
> drivers/net/can/sja1000/Kconfig | 1 +
> drivers/net/can/sja1000/plx_pci.c | 66 ++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
> index 1e65cb6..f6dc899 100644
> --- a/drivers/net/can/sja1000/Kconfig
> +++ b/drivers/net/can/sja1000/Kconfig
> @@ -88,6 +88,7 @@ config CAN_PLX_PCI
> - TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/)
> - IXXAT Automation PC-I 04/PCI card (http://www.ixxat.com/)
> - Connect Tech Inc. CANpro/104-Plus Opto (CRG001) card (http://www.connecttech.com)
> + - ASEM CAN raw - 2 isolated CAN channels (www.asem.it)
>
> config CAN_TSCAN1
> tristate "TS-CAN1 PC104 boards"
> diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
> index f8ff25c..79fc327 100644
> --- a/drivers/net/can/sja1000/plx_pci.c
> +++ b/drivers/net/can/sja1000/plx_pci.c
> @@ -46,7 +46,8 @@ MODULE_SUPPORTED_DEVICE("Adlink PCI-7841/cPCI-7841, "
> "esd CAN-PCIe/2000, "
> "Connect Tech Inc. CANpro/104-Plus Opto (CRG001), "
> "IXXAT PC-I 04/PCI, "
> - "ELCUS CAN-200-PCI")
> + "ELCUS CAN-200-PCI, "
> + "ASEM DUAL CAN-RAW")
> MODULE_LICENSE("GPL v2");
>
> #define PLX_PCI_MAX_CHAN 2
> @@ -70,7 +71,9 @@ struct plx_pci_card {
> */
>
> #define PLX_LINT1_EN 0x1 /* Local interrupt 1 enable */
> +#define PLX_LINT1_POL (1 << 1) /* Local interrupt 1 polarity */
> #define PLX_LINT2_EN (1 << 3) /* Local interrupt 2 enable */
> +#define PLX_LINT2_POL (1 << 4) /* Local interrupt 2 polarity */
> #define PLX_PCI_INT_EN (1 << 6) /* PCI Interrupt Enable */
> #define PLX_PCI_RESET (1 << 30) /* PCI Adapter Software Reset */
>
> @@ -92,6 +95,9 @@ struct plx_pci_card {
> */
> #define PLX_PCI_OCR (OCR_TX0_PUSHPULL | OCR_TX1_PUSHPULL)
>
> +/* OCR setting for ASEM Dual CAN raw */
> +#define ASEM_PCI_OCR 0xfe
> +
> /*
> * In the CDR register, you should set CBP to 1.
> * You will probably also want to set the clock divider value to 7
> @@ -145,10 +151,20 @@ struct plx_pci_card {
> #define MOXA_PCI_VENDOR_ID 0x1393
> #define MOXA_PCI_DEVICE_ID 0x0100
>
> +#define ASEM_RAW_CAN_VENDOR_ID 0x10b5
> +#define ASEM_RAW_CAN_DEVICE_ID 0x9030
> +#define ASEM_RAW_CAN_SUB_VENDOR_ID 0x3000
> +#define ASEM_RAW_CAN_SUB_DEVICE_ID 0x1001
> +#define ASEM_RAW_CAN_SUB_DEVICE_ID_BIS 0x1002
> +#define ASEM_RAW_CAN_RST_REGISTER 0x54
> +#define ASEM_RAW_CAN_RST_MASK_CAN1 0x20
> +#define ASEM_RAW_CAN_RST_MASK_CAN2 0x04
> +
> static void plx_pci_reset_common(struct pci_dev *pdev);
> static void plx9056_pci_reset_common(struct pci_dev *pdev);
> static void plx_pci_reset_marathon_pci(struct pci_dev *pdev);
> static void plx_pci_reset_marathon_pcie(struct pci_dev *pdev);
> +static void plx_pci_reset_asem_dual_can_raw(struct pci_dev *pdev);
>
> struct plx_pci_channel_map {
> u32 bar;
> @@ -269,6 +285,14 @@ static struct plx_pci_card_info plx_pci_card_info_moxa = {
> /* based on PLX9052 */
> };
>
> +static struct plx_pci_card_info plx_pci_card_info_asem_dual_can = {
> + "ASEM Dual CAN raw PCI", 2,
> + PLX_PCI_CAN_CLOCK, ASEM_PCI_OCR, PLX_PCI_CDR,
> + {0, 0x00, 0x00}, { {2, 0x00, 0x00}, {4, 0x00, 0x00} },
> + &plx_pci_reset_asem_dual_can_raw
> + /* based on PLX9030 */
> +};
> +
> static const struct pci_device_id plx_pci_tbl[] = {
> {
> /* Adlink PCI-7841/cPCI-7841 */
> @@ -375,6 +399,20 @@ static const struct pci_device_id plx_pci_tbl[] = {
> 0, 0,
> (kernel_ulong_t)&plx_pci_card_info_moxa
> },
> + {
> + /* ASEM Dual CAN raw */
> + ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> + ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID,
> + 0, 0,
> + (kernel_ulong_t)&plx_pci_card_info_asem_dual_can
> + },
> + {
> + /* ASEM Dual CAN raw -new model */
> + ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> + ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID_BIS,
> + 0, 0,
> + (kernel_ulong_t)&plx_pci_card_info_asem_dual_can
> + },
> { 0,}
> };
> MODULE_DEVICE_TABLE(pci, plx_pci_tbl);
> @@ -524,6 +562,32 @@ static void plx_pci_reset_marathon_pcie(struct pci_dev *pdev)
> }
> }
>
> +/* Special reset function for ASEM Dual CAN raw card */
> +static void plx_pci_reset_asem_dual_can_raw(struct pci_dev *pdev)
> +{
> + void __iomem *bar0_addr;
> + u8 tmpval;
> +
> + plx_pci_reset_common(pdev);
> +
> + bar0_addr = pci_iomap(pdev, 0, 0);
> + if (!bar0_addr) {
> + dev_err(&pdev->dev, "Failed to remap reset space %d (BAR%d)\n",
> + 0, 0);
I've put both 0 directly into the string while applying the patch.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] rtlwifi: btcoex: Fix if == else warnings in halbtc8723b2ant.c
From: Larry Finger @ 2018-08-07 14:23 UTC (permalink / raw)
To: valdis.kletnieks, YueHaibing
Cc: pkshih, kvalo, linux-kernel, netdev, davem, colin.king,
linux-wireless
In-Reply-To: <63216.1533591775@turing-police.cc.vt.edu>
On 08/06/2018 04:42 PM, valdis.kletnieks@vt.edu wrote:
> On Mon, 06 Aug 2018 12:54:40 +0800, YueHaibing said:
>> Fix following coccinelle warning:
>>
>> ./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2952:2-4: WARNING: possible condition with no effect (if == else)
>
>> /* sw mechanism */
>> if (BTC_WIFI_BW_HT40 == wifi_bw) {
>> - if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
>> - (wifi_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
>> - btc8723b2ant_sw_mechanism(btcoexist, true, true,
>> - false, false);
>> - } else {
>> - btc8723b2ant_sw_mechanism(btcoexist, true, true,
>> - false, false);
>> - }
>> + btc8723b2ant_sw_mechanism(btcoexist, true, true,
>> + false, false);
>> } else {
>
> Rather than blindly fixing this, perhaps a bit of thought needs to be
> applied to why this code looks like this in the first place.
>
> See commit c6821613e653a (which looks like the bletcherous "do too many
> things at once" commit indeed), although the actual diff appears to be a
> "no harm, no foul" against this commit, where the issue already existed.
>
> commit aa45a673b291fd761275493bc15316d79555ed55
> Author: Larry Finger <Larry.Finger@lwfinger.net>
> Date: Fri Feb 28 15:16:43 2014 -0600
>
> rtlwifi: btcoexist: Add new mini driver
>
> Larry? Can you reach back to 2014 and remember why this code
> looked like this in the first place?
The base code came from Realtek. My only part in getting it into the kernel was
to clean up the checkpatch and Sparse errors and warnings, and submit it. I was
a "script kiddy" just like the authors of the current patches. The only
difference is that I was getting drivers into the kernel so that users hardware
would work.
Any record of whether these duplicate branches are the result of incorrect copy
and paste, or just extraneous code, would be at Realtek in their version control
history. I have never had access to such archives, nor have I ever had an
non-disclosure agreement with Realtek.
Ping-Ke Shih, who is Cc'd on these messages, might be able to answer these
questions.
For the moment, these simplifications could be applied as long as they are
correctly done. After all, they are not changing what is already there and that
stops any other person that knows how to run coccinelle from submitting the same
patch in the future. Why "kick the can down the road"? If PK can find that there
was an error in the original code, he can submit a "Fixes" patch.
Larry
^ permalink raw reply
* WARNING: refcount bug in llc_sap_find
From: syzbot @ 2018-08-07 14:59 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 0585df468e8f Merge tag 'media/v4.18-3' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15927272400000
kernel config: https://syzkaller.appspot.com/x/.config?x=2dc0cd7c2eefb46f
dashboard link: https://syzkaller.appspot.com/bug?extid=278893f3f7803871f7ce
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1064ef78400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17d0fa8c400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+278893f3f7803871f7ce@syzkaller.appspotmail.com
------------[ cut here ]------------
refcount_t: increment on 0; use-after-free.
WARNING: CPU: 0 PID: 25217 at lib/refcount.c:153 refcount_inc+0x5d/0x70
lib/refcount.c:153
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 25217 Comm: syz-executor271 Not tainted 4.18.0-rc7+ #175
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+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:refcount_inc+0x5d/0x70 lib/refcount.c:153
Code: 1d 9c ef 25 05 31 ff 89 de e8 6f b0 1c fe 84 db 75 df e8 96 af 1c fe
48 c7 c7 40 4b 3a 87 c6 05 7c ef 25 05 01 e8 93 c8 e7 fd <0f> 0b eb c3 0f
1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89
RSP: 0018:ffff8801d6cd7af8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff81632481 RDI: ffff8801d6cd77d0
RBP: ffff8801d6cd7b00 R08: ffff8801bfbf65c0 R09: 0000000000000002
R10: ffff8801bfbf65c0 R11: 0000000000000000 R12: 00000000000000ff
R13: dffffc0000000000 R14: 00000000000000ff R15: ffff8801d6cd7d17
llc_sap_hold include/net/llc.h:116 [inline]
llc_sap_find+0x1ec/0x2a0 net/llc/llc_core.c:77
llc_ui_bind+0x6c7/0xf10 net/llc/af_llc.c:362
__sys_bind+0x331/0x440 net/socket.c:1493
__do_sys_bind net/socket.c:1504 [inline]
__se_sys_bind net/socket.c:1502 [inline]
__x64_sys_bind+0x73/0xb0 net/socket.c:1502
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445ca9
Code: e8 ac e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 fb 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff435ebcdb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
RAX: ffffffffffffffda RBX: 00000000006dac28 RCX: 0000000000445ca9
RDX: 0000000000000010 RSI: 00000000200000c0 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac2c
R13: 00007ffe0636e23f R14: 00007ff435ebd9c0 R15: 00000000006dac20
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
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
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