* [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: Jian-Hong Pan @ 2019-07-25 8:09 UTC (permalink / raw)
To: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, David Laight
Cc: linux-wireless, netdev, linux-kernel, linux, Jian-Hong Pan,
stable
Each skb as the element in RX ring was expected with sized buffer 8216
(RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
16640 bytes for alignment after allocated, x86_64 for example. And, the
difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM).
To prevent that much wasted memory, this patch follows David's
suggestion [1] and uses general buffer arrays, instead of skbs as the
elements in RX ring.
[1] https://www.spinics.net/lists/linux-wireless/msg187870.html
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
---
drivers/net/wireless/realtek/rtw88/pci.c | 132 +++++++++++++----------
drivers/net/wireless/realtek/rtw88/pci.h | 2 +-
2 files changed, 75 insertions(+), 59 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 23dd06afef3d..e953010f0179 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -111,25 +111,49 @@ static void rtw_pci_free_tx_ring(struct rtw_dev *rtwdev,
tx_ring->r.head = NULL;
}
+static struct rtw_pci_rx_buffer_desc *rtw_pci_get_rx_desc(
+ struct rtw_pci_rx_ring *rx_ring,
+ u32 idx)
+{
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ u32 desc_sz = rx_ring->r.desc_size;
+
+ buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
+ idx * desc_sz);
+ return buf_desc;
+}
+
+static dma_addr_t rtw_pci_get_rx_bufdma(struct rtw_pci_rx_ring *rx_ring,
+ u32 idx)
+{
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ dma_addr_t dma;
+
+ buf_desc = rtw_pci_get_rx_desc(rx_ring, idx);
+ dma = le32_to_cpu(buf_desc->dma);
+
+ return dma;
+}
+
static void rtw_pci_free_rx_ring(struct rtw_dev *rtwdev,
struct rtw_pci_rx_ring *rx_ring)
{
struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
- struct sk_buff *skb;
+ u8 *buf;
dma_addr_t dma;
u8 *head = rx_ring->r.head;
int buf_sz = RTK_PCI_RX_BUF_SIZE;
int ring_sz = rx_ring->r.desc_size * rx_ring->r.len;
- int i;
+ u32 i;
for (i = 0; i < rx_ring->r.len; i++) {
- skb = rx_ring->buf[i];
- if (!skb)
+ buf = rx_ring->buf[i];
+ if (!buf)
continue;
- dma = *((dma_addr_t *)skb->cb);
- pci_unmap_single(pdev, dma, buf_sz, PCI_DMA_FROMDEVICE);
- dev_kfree_skb(skb);
+ dma = rtw_pci_get_rx_bufdma(rx_ring, i);
+ pci_unmap_single(pdev, dma, buf_sz, DMA_FROM_DEVICE);
+ devm_kfree(rtwdev->dev, buf);
rx_ring->buf[i] = NULL;
}
@@ -180,27 +204,24 @@ static int rtw_pci_init_tx_ring(struct rtw_dev *rtwdev,
return 0;
}
-static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb,
- struct rtw_pci_rx_ring *rx_ring,
- u32 idx, u32 desc_sz)
+static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, u8 *buf,
+ struct rtw_pci_rx_ring *rx_ring, u32 idx)
{
struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
struct rtw_pci_rx_buffer_desc *buf_desc;
int buf_sz = RTK_PCI_RX_BUF_SIZE;
dma_addr_t dma;
- if (!skb)
+ if (!buf)
return -EINVAL;
- dma = pci_map_single(pdev, skb->data, buf_sz, PCI_DMA_FROMDEVICE);
+ dma = pci_map_single(pdev, buf, buf_sz, DMA_FROM_DEVICE);
if (pci_dma_mapping_error(pdev, dma))
return -EBUSY;
- *((dma_addr_t *)skb->cb) = dma;
- buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
- idx * desc_sz);
- memset(buf_desc, 0, sizeof(*buf_desc));
+ buf_desc = rtw_pci_get_rx_desc(rx_ring, idx);
buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
+ buf_desc->total_pkt_size = cpu_to_le16(0);
buf_desc->dma = cpu_to_le32(dma);
return 0;
@@ -208,7 +229,7 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb,
static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
struct rtw_pci_rx_ring *rx_ring,
- u32 idx, u32 desc_sz)
+ u32 idx)
{
struct device *dev = rtwdev->dev;
struct rtw_pci_rx_buffer_desc *buf_desc;
@@ -216,10 +237,9 @@ static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
dma_sync_single_for_device(dev, dma, buf_sz, DMA_FROM_DEVICE);
- buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
- idx * desc_sz);
- memset(buf_desc, 0, sizeof(*buf_desc));
+ buf_desc = rtw_pci_get_rx_desc(rx_ring, idx);
buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
+ buf_desc->total_pkt_size = cpu_to_le16(0);
buf_desc->dma = cpu_to_le32(dma);
}
@@ -228,12 +248,12 @@ static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev,
u8 desc_size, u32 len)
{
struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
- struct sk_buff *skb = NULL;
+ u8 *buf = NULL;
dma_addr_t dma;
u8 *head;
int ring_sz = desc_size * len;
int buf_sz = RTK_PCI_RX_BUF_SIZE;
- int i, allocated;
+ u32 i, allocated;
int ret = 0;
head = pci_zalloc_consistent(pdev, ring_sz, &dma);
@@ -242,41 +262,39 @@ static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev,
return -ENOMEM;
}
rx_ring->r.head = head;
+ rx_ring->r.dma = dma;
+ rx_ring->r.len = len;
+ rx_ring->r.desc_size = desc_size;
+ rx_ring->r.wp = 0;
+ rx_ring->r.rp = 0;
for (i = 0; i < len; i++) {
- skb = dev_alloc_skb(buf_sz);
- if (!skb) {
+ buf = devm_kzalloc(rtwdev->dev, buf_sz, GFP_ATOMIC);
+ if (!buf) {
allocated = i;
ret = -ENOMEM;
goto err_out;
}
- memset(skb->data, 0, buf_sz);
- rx_ring->buf[i] = skb;
- ret = rtw_pci_reset_rx_desc(rtwdev, skb, rx_ring, i, desc_size);
+ rx_ring->buf[i] = buf;
+ ret = rtw_pci_reset_rx_desc(rtwdev, buf, rx_ring, i);
if (ret) {
allocated = i;
- dev_kfree_skb_any(skb);
+ devm_kfree(rtwdev->dev, buf);
goto err_out;
}
}
- rx_ring->r.dma = dma;
- rx_ring->r.len = len;
- rx_ring->r.desc_size = desc_size;
- rx_ring->r.wp = 0;
- rx_ring->r.rp = 0;
-
return 0;
err_out:
for (i = 0; i < allocated; i++) {
- skb = rx_ring->buf[i];
- if (!skb)
+ buf = rx_ring->buf[i];
+ if (!buf)
continue;
- dma = *((dma_addr_t *)skb->cb);
- pci_unmap_single(pdev, dma, buf_sz, PCI_DMA_FROMDEVICE);
- dev_kfree_skb_any(skb);
+ dma = rtw_pci_get_rx_bufdma(rx_ring, i);
+ pci_unmap_single(pdev, dma, buf_sz, DMA_FROM_DEVICE);
+ devm_kfree(rtwdev->dev, buf);
rx_ring->buf[i] = NULL;
}
pci_free_consistent(pdev, ring_sz, head, dma);
@@ -776,13 +794,12 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
struct rtw_pci_rx_ring *ring;
struct rtw_rx_pkt_stat pkt_stat;
struct ieee80211_rx_status rx_status;
- struct sk_buff *skb, *new;
+ struct sk_buff *skb;
u32 cur_wp, cur_rp, tmp;
u32 count;
u32 pkt_offset;
u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
- u32 buf_desc_sz = chip->rx_buf_desc_sz;
- u32 new_len;
+ u32 len;
u8 *rx_desc;
dma_addr_t dma;
@@ -799,11 +816,11 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
cur_rp = ring->r.rp;
while (count--) {
rtw_pci_dma_check(rtwdev, ring, cur_rp);
- skb = ring->buf[cur_rp];
- dma = *((dma_addr_t *)skb->cb);
+ /* buffer is already filled as rx_desc */
+ rx_desc = ring->buf[cur_rp];
+ dma = rtw_pci_get_rx_bufdma(ring, cur_rp);
dma_sync_single_for_cpu(rtwdev->dev, dma, RTK_PCI_RX_BUF_SIZE,
DMA_FROM_DEVICE);
- rx_desc = skb->data;
chip->ops->query_rx_desc(rtwdev, rx_desc, &pkt_stat, &rx_status);
/* offset from rx_desc to payload */
@@ -813,32 +830,31 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci,
/* allocate a new skb for this frame,
* discard the frame if none available
*/
- new_len = pkt_stat.pkt_len + pkt_offset;
- new = dev_alloc_skb(new_len);
- if (WARN_ONCE(!new, "rx routine starvation\n"))
+ len = pkt_stat.pkt_len + pkt_offset;
+ skb = dev_alloc_skb(len);
+ if (WARN_ONCE(!skb, "rx routine starvation\n"))
goto next_rp;
/* put the DMA data including rx_desc from phy to new skb */
- skb_put_data(new, skb->data, new_len);
+ skb_put_data(skb, rx_desc, len);
if (pkt_stat.is_c2h) {
/* pass rx_desc & offset for further operation */
- *((u32 *)new->cb) = pkt_offset;
- skb_queue_tail(&rtwdev->c2h_queue, new);
+ *((u32 *)skb->cb) = pkt_offset;
+ skb_queue_tail(&rtwdev->c2h_queue, skb);
ieee80211_queue_work(rtwdev->hw, &rtwdev->c2h_work);
} else {
/* remove rx_desc */
- skb_pull(new, pkt_offset);
+ skb_pull(skb, pkt_offset);
- rtw_rx_stats(rtwdev, pkt_stat.vif, new);
- memcpy(new->cb, &rx_status, sizeof(rx_status));
- ieee80211_rx_irqsafe(rtwdev->hw, new);
+ rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
+ memcpy(skb->cb, &rx_status, sizeof(rx_status));
+ ieee80211_rx_irqsafe(rtwdev->hw, skb);
}
next_rp:
- /* new skb delivered to mac80211, re-enable original skb DMA */
- rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp,
- buf_desc_sz);
+ /* new skb delivered to mac80211, re-enable original buf DMA */
+ rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp);
/* host read next element in ring */
if (++cur_rp >= ring->r.len)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.h b/drivers/net/wireless/realtek/rtw88/pci.h
index 87824a4caba9..283685421a64 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.h
+++ b/drivers/net/wireless/realtek/rtw88/pci.h
@@ -174,7 +174,7 @@ struct rtw_pci_rx_buffer_desc {
struct rtw_pci_rx_ring {
struct rtw_pci_ring r;
- struct sk_buff *buf[RTK_MAX_RX_DESC_NUM];
+ u8 *buf[RTK_MAX_RX_DESC_NUM];
};
#define RX_TAG_MAX 8192
--
2.22.0
^ permalink raw reply related
* Re: [PATCH bpf-next v4 3/6] xdp: Add devmap_hash map type for looking up devices by hashed index
From: Jesper Dangaard Brouer @ 2019-07-25 8:07 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, David Miller,
Jakub Kicinski, Björn Töpel, Yonghong Song, brouer
In-Reply-To: <156379636866.12332.6546616116016146789.stgit@alrua-x1>
On Mon, 22 Jul 2019 13:52:48 +0200
Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> +static inline struct hlist_head *dev_map_index_hash(struct bpf_dtab *dtab,
> + int idx)
> +{
> + return &dtab->dev_index_head[idx & (NETDEV_HASHENTRIES - 1)];
> +}
It is good for performance that our "hash" function is simply an AND
operation on the idx. We want to keep it this way.
I don't like that you are using NETDEV_HASHENTRIES, because the BPF map
infrastructure already have a way to specify the map size (struct
bpf_map_def .max_entries). BUT for performance reasons, to keep the
AND operation, we would need to round up the hash-array size to nearest
power of 2 (or reject if user didn't specify a power of 2, if we want
to "expose" this limit to users).
> +struct bpf_dtab_netdev *__dev_map_hash_lookup_elem(struct bpf_map *map, u32 key)
> +{
> + struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
> + struct hlist_head *head = dev_map_index_hash(dtab, key);
> + struct bpf_dtab_netdev *dev;
> +
> + hlist_for_each_entry_rcu(dev, head, index_hlist)
> + if (dev->idx == key)
> + return dev;
> +
> + return NULL;
> +}
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 0/8] can: flexcan: add CAN FD support for NXP Flexcan
From: Marc Kleine-Budde @ 2019-07-25 7:53 UTC (permalink / raw)
To: Joakim Zhang, linux-can@vger.kernel.org
Cc: wg@grandegger.com, dl-linux-imx, netdev@vger.kernel.org
In-Reply-To: <DB7PR04MB461831872271A98E741FF68AE6C10@DB7PR04MB4618.eurprd04.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 1545 bytes --]
On 7/25/19 9:38 AM, Joakim Zhang wrote:
> Kindly pinging...
>
> After you git pull request for linux-can-next-for-5.4-20190724, some patches are missing from linux-can-next/testing.
> can: flexcan: flexcan_mailbox_read() make use of flexcan_write64() to mark the mailbox as read
> can: flexcan: flexcan_irq(): add support for TX mailbox in iflag1
> can: flexcan: flexcan_read_reg_iflag_rx(): optimize reading
> can: flexcan: introduce struct flexcan_priv::tx_mask and make use of it
> can: flexcan: convert struct flexcan_priv::rx_mask{1,2} to rx_mask
> can: flexcan: remove TX mailbox bit from struct flexcan_priv::rx_mask{1,2}
> can: flexcan: rename struct flexcan_priv::reg_imask{1,2}_default to rx_mask{1,2}
> can: flexcan: flexcan_irq(): rename variable reg_iflag -> reg_iflag_rx
> can: flexcan: rename macro FLEXCAN_IFLAG_MB() -> FLEXCAN_IFLAG2_MB()
>
> You can refer to below link for the reason of adding above patches:
> https://www.spinics.net/lists/linux-can/msg00777.html
> https://www.spinics.net/lists/linux-can/msg01150.html
>
> Are you prepared to add back these patches as they are necessary for
> Flexcan CAN FD? And this Flexcan CAN FD patch set is based on these
> patches.
Yes, these patches will be added back.
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
* [PATCH net-next] net: mvneta: use devm_platform_ioremap_resource() to simplify code
From: Jisheng Zhang @ 2019-07-25 7:48 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
devm_platform_ioremap_resource() wraps platform_get_resource() and
devm_ioremap_resource() in a single helper, let's use that helper to
simplify the code.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
drivers/net/ethernet/marvell/mvneta.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 15cc678f5e5b..e49820675c8c 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4469,7 +4469,6 @@ static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
/* Device initialization routine */
static int mvneta_probe(struct platform_device *pdev)
{
- struct resource *res;
struct device_node *dn = pdev->dev.of_node;
struct device_node *bm_node;
struct mvneta_port *pp;
@@ -4553,8 +4552,7 @@ static int mvneta_probe(struct platform_device *pdev)
if (!IS_ERR(pp->clk_bus))
clk_prepare_enable(pp->clk_bus);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- pp->base = devm_ioremap_resource(&pdev->dev, res);
+ pp->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(pp->base)) {
err = PTR_ERR(pp->base);
goto err_clk;
--
2.22.0
^ permalink raw reply related
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-25 7:44 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, Ilias Apalodimas
Cc: David Miller, robin.murphy@arm.com, lists@bofh.nu,
Joao.Pinto@synopsys.com, alexandre.torgue@st.com,
maxime.ripard@bootlin.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <a07c3480-af03-a61b-4e9c-d9ceb29ce622@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
Date: Jul/24/2019, 12:58:15 (UTC+00:00)
>
> On 24/07/2019 12:34, Jose Abreu wrote:
> > From: Jon Hunter <jonathanh@nvidia.com>
> > Date: Jul/24/2019, 12:10:47 (UTC+00:00)
> >
> >>
> >> On 24/07/2019 11:04, Jose Abreu wrote:
> >>
> >> ...
> >>
> >>> Jon, I was able to replicate (at some level) your setup:
> >>>
> >>> # dmesg | grep -i arm-smmu
> >>> [ 1.337322] arm-smmu 70040000.iommu: probing hardware
> >>> configuration...
> >>> [ 1.337330] arm-smmu 70040000.iommu: SMMUv2 with:
> >>> [ 1.337338] arm-smmu 70040000.iommu: stage 1 translation
> >>> [ 1.337346] arm-smmu 70040000.iommu: stage 2 translation
> >>> [ 1.337354] arm-smmu 70040000.iommu: nested translation
> >>> [ 1.337363] arm-smmu 70040000.iommu: stream matching with 128
> >>> register groups
> >>> [ 1.337374] arm-smmu 70040000.iommu: 1 context banks (0
> >>> stage-2 only)
> >>> [ 1.337383] arm-smmu 70040000.iommu: Supported page sizes:
> >>> 0x61311000
> >>> [ 1.337393] arm-smmu 70040000.iommu: Stage-1: 48-bit VA ->
> >>> 48-bit IPA
> >>> [ 1.337402] arm-smmu 70040000.iommu: Stage-2: 48-bit IPA ->
> >>> 48-bit PA
> >>>
> >>> # dmesg | grep -i stmmac
> >>> [ 1.344106] stmmaceth 70000000.ethernet: Adding to iommu group 0
> >>> [ 1.344233] stmmaceth 70000000.ethernet: no reset control found
> >>> [ 1.348276] stmmaceth 70000000.ethernet: User ID: 0x10, Synopsys ID:
> >>> 0x51
> >>> [ 1.348285] stmmaceth 70000000.ethernet: DWMAC4/5
> >>> [ 1.348293] stmmaceth 70000000.ethernet: DMA HW capability register
> >>> supported
> >>> [ 1.348302] stmmaceth 70000000.ethernet: RX Checksum Offload Engine
> >>> supported
> >>> [ 1.348311] stmmaceth 70000000.ethernet: TX Checksum insertion
> >>> supported
> >>> [ 1.348320] stmmaceth 70000000.ethernet: TSO supported
> >>> [ 1.348328] stmmaceth 70000000.ethernet: Enable RX Mitigation via HW
> >>> Watchdog Timer
> >>> [ 1.348337] stmmaceth 70000000.ethernet: TSO feature enabled
> >>> [ 1.348409] libphy: stmmac: probed
> >>> [ 4159.140990] stmmaceth 70000000.ethernet eth0: PHY [stmmac-0:01]
> >>> driver [Generic PHY]
> >>> [ 4159.141005] stmmaceth 70000000.ethernet eth0: phy: setting supported
> >>> 00,00000000,000062ff advertising 00,00000000,000062ff
> >>> [ 4159.142359] stmmaceth 70000000.ethernet eth0: No Safety Features
> >>> support found
> >>> [ 4159.142369] stmmaceth 70000000.ethernet eth0: IEEE 1588-2008 Advanced
> >>> Timestamp supported
> >>> [ 4159.142429] stmmaceth 70000000.ethernet eth0: registered PTP clock
> >>> [ 4159.142439] stmmaceth 70000000.ethernet eth0: configuring for
> >>> phy/gmii link mode
> >>> [ 4159.142452] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
> >>> mode=phy/gmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0
> >>> an=1
> >>> [ 4159.142466] stmmaceth 70000000.ethernet eth0: phy link up
> >>> gmii/1Gbps/Full
> >>> [ 4159.142475] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
> >>> mode=phy/gmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> >>> [ 4159.142481] stmmaceth 70000000.ethernet eth0: Link is Up - 1Gbps/Full
> >>> - flow control rx/tx
> >>>
> >>> The only missing point is the NFS boot that I can't replicate with this
> >>> setup. But I did some sanity checks:
> >>>
> >>> Remote Enpoint:
> >>> # dd if=/dev/urandom of=output.dat bs=128M count=1
> >>> # nc -c 192.168.0.2 1234 < output.dat
> >>> # md5sum output.dat
> >>> fde9e0818281836e4fc0edfede2b8762 output.dat
> >>>
> >>> DUT:
> >>> # nc -l -c -p 1234 > output.dat
> >>> # md5sum output.dat
> >>> fde9e0818281836e4fc0edfede2b8762 output.dat
> >>
> >> On my setup, if I do not use NFS to mount the rootfs, but then manually
> >> mount the NFS share after booting, I do not see any problems reading or
> >> writing to files on the share. So I am not sure if it is some sort of
> >> race that is occurring when mounting the NFS share on boot. It is 100%
> >> reproducible when using NFS for the root file-system.
> >
> > I don't understand how can there be corruption then unless the IP AXI
> > parameters are misconfigured which can lead to sporadic undefined
> > behavior.
> >
> > These prints from your logs:
> > [ 14.579392] Run /init as init process
> > /init: line 58: chmod: command not found
> > [ 10:22:46 ] L4T-INITRD Build DATE: Mon Jul 22 10:22:46 UTC 2019
> > [ 10:22:46 ] Root device found: nfs
> > [ 10:22:46 ] Ethernet interfaces: eth0
> > [ 10:22:46 ] IP Address: 10.21.140.41
> >
> > Where are they coming from ? Do you have any extra init script ?
>
> By default there is an initial ramdisk that is loaded first and then the
> rootfs is mounted over NFS. However, even if I remove this ramdisk and
> directly mount the rootfs via NFS without it the problem persists. So I
> don't see any issue with the ramdisk and whats more is we have been
> using this for a long long time. Nothing has changed here.
OK. Can you please test what Ilias mentioned ?
Basically you can hard-code the order to 0 in
alloc_dma_rx_desc_resources():
- pp_params.order = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
+ pp_params.order = 0;
Unless you use a MTU > PAGE_SIZE.
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* RE: [PATCH 0/8] can: flexcan: add CAN FD support for NXP Flexcan
From: Joakim Zhang @ 2019-07-25 7:38 UTC (permalink / raw)
To: mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, dl-linux-imx, netdev@vger.kernel.org
In-Reply-To: <20190712075926.7357-1-qiangqing.zhang@nxp.com>
Hi Marc,
Kindly pinging...
After you git pull request for linux-can-next-for-5.4-20190724, some patches are missing from linux-can-next/testing.
can: flexcan: flexcan_mailbox_read() make use of flexcan_write64() to mark the mailbox as read
can: flexcan: flexcan_irq(): add support for TX mailbox in iflag1
can: flexcan: flexcan_read_reg_iflag_rx(): optimize reading
can: flexcan: introduce struct flexcan_priv::tx_mask and make use of it
can: flexcan: convert struct flexcan_priv::rx_mask{1,2} to rx_mask
can: flexcan: remove TX mailbox bit from struct flexcan_priv::rx_mask{1,2}
can: flexcan: rename struct flexcan_priv::reg_imask{1,2}_default to rx_mask{1,2}
can: flexcan: flexcan_irq(): rename variable reg_iflag -> reg_iflag_rx
can: flexcan: rename macro FLEXCAN_IFLAG_MB() -> FLEXCAN_IFLAG2_MB()
You can refer to below link for the reason of adding above patches:
https://www.spinics.net/lists/linux-can/msg00777.html
https://www.spinics.net/lists/linux-can/msg01150.html
Are you prepared to add back these patches as they are necessary for Flexcan CAN FD? And this Flexcan CAN FD patch set is based on these patches.
Thanks a lot!
Best Regards,
Joakim Zhang
> -----Original Message-----
> From: Joakim Zhang
> Sent: 2019年7月12日 16:03
> To: mkl@pengutronix.de; linux-can@vger.kernel.org
> Cc: wg@grandegger.com; dl-linux-imx <linux-imx@nxp.com>;
> netdev@vger.kernel.org; Joakim Zhang <qiangqing.zhang@nxp.com>
> Subject: [PATCH 0/8] can: flexcan: add CAN FD support for NXP Flexcan
>
> Hi Marc,
>
> This patch set intends to add support for NXP Flexcan CAN FD, it has been
> validated on three NXP platform(i.MX8QM/QXP, S32V234, LX2160AR1).
> After discussed with another two Fexcan owner, we sorted out this version.
>
> I hope you can pick up the patch set as it can fully meet requirement of above
> three platform. And after that, we can start to do upstream about CAN FD.
>
> Thanks a lot!
>
> BRs,
> Joakim Zhang
>
> Joakim Zhang (8):
> can: flexcan: allocate skb in flexcan_mailbox_read
> can: flexcan: use struct canfd_frame for CAN classic frame
> can: flexcan: add CAN FD mode support
> can: flexcan: add CANFD BRS support
> can: flexcan: add ISO CAN FD feature support
> can: flexcan: add Transceiver Delay Compensation suopport
> can: flexcan: add imx8qm support
> can: flexcan: add lx2160ar1 support
>
> drivers/net/can/flexcan.c | 340 ++++++++++++++++++++++++++++-----
> drivers/net/can/rx-offload.c | 33 +---
> include/linux/can/rx-offload.h | 5 +-
> 3 files changed, 305 insertions(+), 73 deletions(-)
>
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH net-next v3 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: Antoine Tenart @ 2019-07-25 7:24 UTC (permalink / raw)
To: David Miller
Cc: antoine.tenart, richardcochran, alexandre.belloni, UNGLinuxDriver,
ralf, paul.burton, jhogan, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190724.115226.478045379512899769.davem@davemloft.net>
Hi David,
On Wed, Jul 24, 2019 at 11:52:26AM -0700, David Miller wrote:
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Date: Wed, 24 Jul 2019 10:17:15 +0200
>
> > +static int ocelot_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
> > +{
> > + struct ocelot *ocelot = container_of(ptp, struct ocelot, ptp_info);
> > + u32 unit = 0, direction = 0;
> > + unsigned long flags;
> ^^^^
> > + u64 adj = 0;
> > +
> > + if (!scaled_ppm)
> > + goto disable_adj;
> ...
> > +disable_adj:
> > + ocelot_write(ocelot, 0, PTP_CLK_CFG_ADJ_CFG);
> > +
> > + spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
> ^^^^^
> Did GCC really not warn about this in your build like it did immediately
> on mine?
I was using gcc8 for mips32, and it did not warn about this. Sorry about
that.
> drivers/net/ethernet/mscc/ocelot.c: In function ‘ocelot_ptp_adjfine’:
> ./include/linux/spinlock.h:288:3: warning: ‘flags’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> _raw_spin_unlock_irqrestore(lock, flags); \
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Please fix this and when you respin please just elide the MIPS tree
> patches and just keep all the ones that I should apply to net-next.
OK, will do.
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v12 1/5] can: m_can: Create a m_can platform framework
From: Marc Kleine-Budde @ 2019-07-25 7:09 UTC (permalink / raw)
To: Greg KH, Dan Murphy; +Cc: wg, davem, linux-can, netdev, linux-kernel
In-Reply-To: <20190725062834.GC5647@kroah.com>
[-- Attachment #1.1: Type: text/plain, Size: 3044 bytes --]
On 7/25/19 8:28 AM, Greg KH wrote:
> On Wed, Jul 24, 2019 at 10:36:02AM -0500, Dan Murphy wrote:
>> Hello
>>
>> On 7/24/19 1:47 AM, Greg KH wrote:
>>> On Tue, Jul 23, 2019 at 10:14:14AM -0500, Dan Murphy wrote:
>>>> Hello
>>>>
>>>> On 7/10/19 7:08 AM, Dan Murphy wrote:
>>>>> Hello
>>>>>
>>>>> On 6/17/19 10:09 AM, Dan Murphy wrote:
>>>>>> Marc
>>>>>>
>>>>>> On 6/10/19 11:35 AM, Dan Murphy wrote:
>>>>>>> Bump
>>>>>>>
>>>>>>> On 6/6/19 8:16 AM, Dan Murphy wrote:
>>>>>>>> Marc
>>>>>>>>
>>>>>>>> Bump
>>>>>>>>
>>>>>>>> On 5/31/19 6:51 AM, Dan Murphy wrote:
>>>>>>>>> Marc
>>>>>>>>>
>>>>>>>>> On 5/15/19 3:54 PM, Dan Murphy wrote:
>>>>>>>>>> Marc
>>>>>>>>>>
>>>>>>>>>> On 5/9/19 11:11 AM, Dan Murphy wrote:
>>>>>>>>>>> Create a m_can platform framework that peripheral
>>>>>>>>>>> devices can register to and use common code and register sets.
>>>>>>>>>>> The peripheral devices may provide read/write and configuration
>>>>>>>>>>> support of the IP.
>>>>>>>>>>>
>>>>>>>>>>> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
>>>>>>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> v12 - Update the m_can_read/write functions to
>>>>>>>>>>> create a backtrace if the callback
>>>>>>>>>>> pointer is NULL. - https://lore.kernel.org/patchwork/patch/1052302/
>>>>>>>>>>>
>>>>>>>>>> Is this able to be merged now?
>>>>>>>>> ping
>>>>>> Wondering if there is anything else we need to do?
>>>>>>
>>>>>> The part has officially shipped and we had hoped to have driver
>>>>>> support in Linux as part of the announcement.
>>>>>>
>>>>> Is this being sent in a PR for 5.3?
>>>>>
>>>>> Dan
>>>>>
>>>> Adding Greg to this thread as I have no idea what is going on with this.
>>> Why me? What am I supposed to do here? I see no patches at all to do
>>> anything with :(
>>
>> I am not sure who to email. The maintainer seems to be on hiatus or super
>> busy with other work.
>
> Who is the maintainer?
That's me.
>> So I added you to see if you know how to handle this. Wolfgang Acked it but
>> he said Marc needs to pull
>
> Then work with them, again, what can I do if I can't even see the
> patches here?
The patches are included in a pull request to David Miller
(net-next/master, the CAN upstream), which has already have been merged.
>> it in. We have quite a few users of this patchset. I have been hosting the
>> patchset in a different tree.
>>
>> These users keep pinging us for upstream status and all we can do is point
>> them to the
>>
>> LKML to show we are continuing to pursue inclusion.
>>
>> https://lore.kernel.org/patchwork/project/lkml/list/?series=393454
>
> Looks sane, work with the proper developers, good luck!
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 v12 1/5] can: m_can: Create a m_can platform framework
From: Greg KH @ 2019-07-25 6:28 UTC (permalink / raw)
To: Dan Murphy; +Cc: wg, mkl, davem, linux-can, netdev, linux-kernel
In-Reply-To: <443fe5e5-5e5c-f669-1f4b-565d9f3dd6c8@ti.com>
On Wed, Jul 24, 2019 at 10:36:02AM -0500, Dan Murphy wrote:
> Hello
>
> On 7/24/19 1:47 AM, Greg KH wrote:
> > On Tue, Jul 23, 2019 at 10:14:14AM -0500, Dan Murphy wrote:
> > > Hello
> > >
> > > On 7/10/19 7:08 AM, Dan Murphy wrote:
> > > > Hello
> > > >
> > > > On 6/17/19 10:09 AM, Dan Murphy wrote:
> > > > > Marc
> > > > >
> > > > > On 6/10/19 11:35 AM, Dan Murphy wrote:
> > > > > > Bump
> > > > > >
> > > > > > On 6/6/19 8:16 AM, Dan Murphy wrote:
> > > > > > > Marc
> > > > > > >
> > > > > > > Bump
> > > > > > >
> > > > > > > On 5/31/19 6:51 AM, Dan Murphy wrote:
> > > > > > > > Marc
> > > > > > > >
> > > > > > > > On 5/15/19 3:54 PM, Dan Murphy wrote:
> > > > > > > > > Marc
> > > > > > > > >
> > > > > > > > > On 5/9/19 11:11 AM, Dan Murphy wrote:
> > > > > > > > > > Create a m_can platform framework that peripheral
> > > > > > > > > > devices can register to and use common code and register sets.
> > > > > > > > > > The peripheral devices may provide read/write and configuration
> > > > > > > > > > support of the IP.
> > > > > > > > > >
> > > > > > > > > > Acked-by: Wolfgang Grandegger <wg@grandegger.com>
> > > > > > > > > > Signed-off-by: Dan Murphy <dmurphy@ti.com>
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > v12 - Update the m_can_read/write functions to
> > > > > > > > > > create a backtrace if the callback
> > > > > > > > > > pointer is NULL. - https://lore.kernel.org/patchwork/patch/1052302/
> > > > > > > > > >
> > > > > > > > > Is this able to be merged now?
> > > > > > > > ping
> > > > > Wondering if there is anything else we need to do?
> > > > >
> > > > > The part has officially shipped and we had hoped to have driver
> > > > > support in Linux as part of the announcement.
> > > > >
> > > > Is this being sent in a PR for 5.3?
> > > >
> > > > Dan
> > > >
> > > Adding Greg to this thread as I have no idea what is going on with this.
> > Why me? What am I supposed to do here? I see no patches at all to do
> > anything with :(
>
> I am not sure who to email. The maintainer seems to be on hiatus or super
> busy with other work.
Who is the maintainer?
> So I added you to see if you know how to handle this. Wolfgang Acked it but
> he said Marc needs to pull
Then work with them, again, what can I do if I can't even see the
patches here?
> it in. We have quite a few users of this patchset. I have been hosting the
> patchset in a different tree.
>
> These users keep pinging us for upstream status and all we can do is point
> them to the
>
> LKML to show we are continuing to pursue inclusion.
>
> https://lore.kernel.org/patchwork/project/lkml/list/?series=393454
Looks sane, work with the proper developers, good luck!
greg k-h
^ permalink raw reply
* TSN - tc usage for a tbs setup
From: Stéphane Ancelot @ 2019-07-25 6:50 UTC (permalink / raw)
To: netdev
Hi,
I am trying to setup my network queue for offline time based configuration.
initial setup is :
tc qdisc show dev eth1:
qdisc mq 0: root
qdisc pfifo_fast 0: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1
1 1 1
I won't need pfifo , I have to send one frame at a precise xmit time
(high prio), and then maybe some other frames (with low priority)
I want to setup offload time based xmit.
/sbin/tc qdisc add dev eth1 root handle 100:1 etf delta 100000 clockid
CLOCK_REALTIME offload
replies with
RTNETLINK answers: Invalid argument
What is wrong ?
Regards,
S.Ancelot
^ permalink raw reply
* Re: [PATCH net] net: hns: fix LED configuration for marvell phy
From: liuyonglong @ 2019-07-25 6:56 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev, linux-kernel, linuxarm, salil.mehta,
yisen.zhuang, shiju.jose
In-Reply-To: <20190725042829.GB14276@lunn.ch>
On 2019/7/25 12:28, Andrew Lunn wrote:
> On Thu, Jul 25, 2019 at 11:00:08AM +0800, liuyonglong wrote:
>>> Revert "net: hns: fix LED configuration for marvell phy"
>>> This reverts commit f4e5f775db5a4631300dccd0de5eafb50a77c131.
>>>
>>> Andrew Lunn says this should be handled another way.
>>>
>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>>
>> Hi Andrew:
>>
>> I see this patch have been reverted, can you tell me the better way to do this?
>> Thanks very much!
>
> Please take a look at the work Matthias Kaehlcke is doing. It has not
> got too far yet, but when it is complete, it should define a generic
> way to configure PHY LEDs.
>
> Andrew
>
Hi Andrew
https://lore.kernel.org/patchwork/patch/1097185/
You are discussing about the DT configuration, is Matthias Kaehlcke's work
also provide a generic way to configure PHY LEDS using ACPI?
^ permalink raw reply
* [PATCH net-next] can: kvaser_pciefd: Remove unused including <linux/version.h>
From: YueHaibing @ 2019-07-25 7:02 UTC (permalink / raw)
To: Wolfgang Grandegger, Henning Colliander, Marc Kleine-Budde
Cc: YueHaibing, linux-can, netdev, kernel-janitors, Hulk Robot
Remove including <linux/version.h> that don't need it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/can/kvaser_pciefd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/can/kvaser_pciefd.c b/drivers/net/can/kvaser_pciefd.c
index 3af747cbbde4..952a022b8343 100644
--- a/drivers/net/can/kvaser_pciefd.c
+++ b/drivers/net/can/kvaser_pciefd.c
@@ -7,7 +7,6 @@
*/
#include <linux/kernel.h>
-#include <linux/version.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/pci.h>
^ permalink raw reply related
* [PATCH net-next] can: ti_hecc: remove set but not used variable 'mbx_mask'
From: YueHaibing @ 2019-07-25 7:00 UTC (permalink / raw)
To: Wolfgang Grandegger, Jeroen Hofstee, Marc Kleine-Budde
Cc: YueHaibing, linux-can, netdev, kernel-janitors, Hulk Robot
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/can/ti_hecc.c: In function 'ti_hecc_mailbox_read':
drivers/net/can/ti_hecc.c:533:12: warning:
variable 'mbx_mask' set but not used [-Wunused-but-set-variable]
It is never used so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/can/ti_hecc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index b62f75fa03f0..e63e2f86c289 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -530,9 +530,8 @@ static unsigned int ti_hecc_mailbox_read(struct can_rx_offload *offload,
u32 *timestamp, unsigned int mbxno)
{
struct ti_hecc_priv *priv = rx_offload_to_priv(offload);
- u32 data, mbx_mask;
+ u32 data;
- mbx_mask = BIT(mbxno);
data = hecc_read_mbx(priv, mbxno, HECC_CANMID);
if (data & HECC_CANMID_IDE)
cf->can_id = (data & CAN_EFF_MASK) | CAN_EFF_FLAG;
^ permalink raw reply related
* [PATCH net-next] can: sja1000: f81601: remove unused including <linux/version.h>
From: YueHaibing @ 2019-07-25 6:59 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Ji-Ze Hong (Peter Hong)
Cc: YueHaibing, linux-can, netdev, kernel-janitors
Remove including <linux/version.h> that don't need it.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/can/sja1000/f81601.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/can/sja1000/f81601.c b/drivers/net/can/sja1000/f81601.c
index 362a9d4f44d5..8f25e95814ef 100644
--- a/drivers/net/can/sja1000/f81601.c
+++ b/drivers/net/can/sja1000/f81601.c
@@ -14,7 +14,6 @@
#include <linux/pci.h>
#include <linux/can/dev.h>
#include <linux/io.h>
-#include <linux/version.h>
#include "sja1000.h"
^ permalink raw reply related
* [PATCH] ath10k: Fix HOST capability QMI incompatibility
From: Bjorn Andersson @ 2019-07-25 6:31 UTC (permalink / raw)
To: Kalle Valo, David S. Miller, Rob Herring, Mark Rutland
Cc: linux-wireless, netdev, devicetree, linux-kernel, ath10k, stable
The introduction of 768ec4c012ac ("ath10k: update HOST capability QMI
message") served the purpose of supporting the new and extended HOST
capability QMI message.
But while the new message adds a slew of optional members it changes the
data type of the "daemon_support" member, which means that older
versions of the firmware will fail to decode the incoming request
message.
There is no way to detect this breakage from Linux and there's no way to
recover from sending the wrong message (i.e. we can't just try one
format and then fallback to the other), so a quirk is introduced in
DeviceTree to indicate to the driver that the firmware requires the 8bit
version of this message.
Cc: stable@vger.kernel.org
Fixes: 768ec4c012ac ("ath10k: update HOST capability qmi message")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
.../bindings/net/wireless/qcom,ath10k.txt | 6 +++++
drivers/net/wireless/ath/ath10k/qmi.c | 13 ++++++++---
.../net/wireless/ath/ath10k/qmi_wlfw_v01.c | 22 +++++++++++++++++++
.../net/wireless/ath/ath10k/qmi_wlfw_v01.h | 1 +
drivers/net/wireless/ath/ath10k/snoc.c | 11 ++++++++++
drivers/net/wireless/ath/ath10k/snoc.h | 1 +
6 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index ae661e65354e..f9499b20d840 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -81,6 +81,12 @@ Optional properties:
Definition: Name of external front end module used. Some valid FEM names
for example: "microsemi-lx5586", "sky85703-11"
and "sky85803" etc.
+- qcom,snoc-host-cap-8bit-quirk:
+ Usage: Optional
+ Value type: <empty>
+ Definition: Quirk specifying that the firmware expects the 8bit version
+ of the host capability QMI request
+
Example (to supply PCI based wifi block details):
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 3b63b6257c43..545ac1f06997 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -581,22 +581,29 @@ static int ath10k_qmi_host_cap_send_sync(struct ath10k_qmi *qmi)
{
struct wlfw_host_cap_resp_msg_v01 resp = {};
struct wlfw_host_cap_req_msg_v01 req = {};
+ struct qmi_elem_info *req_ei;
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
struct qmi_txn txn;
int ret;
req.daemon_support_valid = 1;
req.daemon_support = 0;
- ret = qmi_txn_init(&qmi->qmi_hdl, &txn,
- wlfw_host_cap_resp_msg_v01_ei, &resp);
+ ret = qmi_txn_init(&qmi->qmi_hdl, &txn, wlfw_host_cap_resp_msg_v01_ei,
+ &resp);
if (ret < 0)
goto out;
+ if (test_bit(ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK, &ar_snoc->flags))
+ req_ei = wlfw_host_cap_8bit_req_msg_v01_ei;
+ else
+ req_ei = wlfw_host_cap_req_msg_v01_ei;
+
ret = qmi_send_request(&qmi->qmi_hdl, NULL, &txn,
QMI_WLFW_HOST_CAP_REQ_V01,
WLFW_HOST_CAP_REQ_MSG_V01_MAX_MSG_LEN,
- wlfw_host_cap_req_msg_v01_ei, &req);
+ req_ei, &req);
if (ret < 0) {
qmi_txn_cancel(&txn);
ath10k_err(ar, "failed to send host capability request: %d\n", ret);
diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
index 1fe05c6218c3..86fcf4e1de5f 100644
--- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
+++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
@@ -1988,6 +1988,28 @@ struct qmi_elem_info wlfw_host_cap_req_msg_v01_ei[] = {
{}
};
+struct qmi_elem_info wlfw_host_cap_8bit_req_msg_v01_ei[] = {
+ {
+ .data_type = QMI_OPT_FLAG,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x10,
+ .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
+ daemon_support_valid),
+ },
+ {
+ .data_type = QMI_UNSIGNED_1_BYTE,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x10,
+ .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
+ daemon_support),
+ },
+ {}
+};
+
struct qmi_elem_info wlfw_host_cap_resp_msg_v01_ei[] = {
{
.data_type = QMI_STRUCT,
diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
index bca1186e1560..4d107e1364a8 100644
--- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
+++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
@@ -575,6 +575,7 @@ struct wlfw_host_cap_req_msg_v01 {
#define WLFW_HOST_CAP_REQ_MSG_V01_MAX_MSG_LEN 189
extern struct qmi_elem_info wlfw_host_cap_req_msg_v01_ei[];
+extern struct qmi_elem_info wlfw_host_cap_8bit_req_msg_v01_ei[];
struct wlfw_host_cap_resp_msg_v01 {
struct qmi_response_type_v01 resp;
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index b491361e6ed4..fc15a0037f0e 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -1261,6 +1261,15 @@ static int ath10k_snoc_resource_init(struct ath10k *ar)
return ret;
}
+static void ath10k_snoc_quirks_init(struct ath10k *ar)
+{
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
+ struct device *dev = &ar_snoc->dev->dev;
+
+ if (of_property_read_bool(dev->of_node, "qcom,snoc-host-cap-8bit-quirk"))
+ set_bit(ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK, &ar_snoc->flags);
+}
+
int ath10k_snoc_fw_indication(struct ath10k *ar, u64 type)
{
struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
@@ -1678,6 +1687,8 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
ar->ce_priv = &ar_snoc->ce;
msa_size = drv_data->msa_size;
+ ath10k_snoc_quirks_init(ar);
+
ret = ath10k_snoc_resource_init(ar);
if (ret) {
ath10k_warn(ar, "failed to initialize resource: %d\n", ret);
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index d62f53501fbb..9db823e46314 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -63,6 +63,7 @@ enum ath10k_snoc_flags {
ATH10K_SNOC_FLAG_REGISTERED,
ATH10K_SNOC_FLAG_UNREGISTERING,
ATH10K_SNOC_FLAG_RECOVERY,
+ ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK,
};
struct ath10k_snoc {
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Eric Dumazet @ 2019-07-25 6:19 UTC (permalink / raw)
To: maowenan, Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <9a8d6a5a-9a9d-9cb5-caa9-5c12ba04a43c@huawei.com>
On 7/25/19 6:29 AM, maowenan wrote:
>
>>>>> Syzkaller reproducer():
>>>>> r0 = socket$packet(0x11, 0x3, 0x300)
>>>>> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
>>>>> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
>>>>> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
>>>>> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
>>>>> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
>>>>> r2 = fcntl$dupfd(r1, 0x0, r0)
>>>>> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
>>>>>
>>
>> It does call tcp_disconnect(), by one of the connect() call.
>
> yes, __inet_stream_connect will call tcp_disconnect when sa_family == AF_UNSPEC, in c repro if it
> passes sa_family with AF_INET it won't call disconnect, and then sk_send_head won't be NULL when tcp_connect.
>
Look again at the Syzkaller reproducer()
It definitely uses tcp_disconnect()
Do not be fooled by connect$unix(), this is a connect() call really, with AF_UNSPEC
^ permalink raw reply
* Re: [PATCH v2 2/2] mwifiex: Make use of the new sdio_trigger_replug() API to reset
From: Kalle Valo @ 2019-07-25 5:56 UTC (permalink / raw)
To: Doug Anderson
Cc: Ulf Hansson, Adrian Hunter, Ganapathi Bhat, linux-wireless,
Andreas Fenkart, Brian Norris, Amitkumar Karwar,
open list:ARM/Rockchip SoC..., Wolfram Sang, Nishant Sarmukadam,
netdev, Avri Altman, Linux MMC List, David Miller, Xinming Hu,
LKML
In-Reply-To: <CAD=FV=WAsrBV9PzUz1qPzQru+AkOYZ5hsaWdhNYRTNqUfDeOmQ@mail.gmail.com>
Doug Anderson <dianders@chromium.org> writes:
> Hi,
>
> On Wed, Jul 24, 2019 at 4:35 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Douglas Anderson <dianders@chromium.org> wrote:
>>
>> > As described in the patch ("mmc: core: Add sdio_trigger_replug()
>> > API"), the current mwifiex_sdio_card_reset() is broken in the cases
>> > where we're running Bluetooth on a second SDIO func on the same card
>> > as WiFi. The problem goes away if we just use the
>> > sdio_trigger_replug() API call.
>> >
>> > NOTE: Even though with this new solution there is less of a reason to
>> > do our work from a workqueue (the unplug / plug mechanism we're using
>> > is possible for a human to perform at any time so the stack is
>> > supposed to handle it without it needing to be called from a special
>> > context), we still need a workqueue because the Marvell reset function
>> > could called from a context where sleeping is invalid and thus we
>> > can't claim the host. One example is Marvell's wakeup_timer_fn().
>> >
>> > Cc: Andreas Fenkart <afenkart@gmail.com>
>> > Cc: Brian Norris <briannorris@chromium.org>
>> > Fixes: b4336a282db8 ("mwifiex: sdio: reset adapter using mmc_hw_reset")
>> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
>> > Reviewed-by: Brian Norris <briannorris@chromium.org>
>>
>> I assume this is going via some other tree so I'm dropping this from my
>> queue. If I should apply this please resend once the dependency is in
>> wireless-drivers-next.
>>
>> Patch set to Not Applicable.
>
> Thanks. For now I'll assume that Ulf will pick it up if/when he is
> happy with patch #1 in this series. Would you be willing to provide
> your Ack on this patch to make it clear to Ulf you're OK with that?
Sure, I was planning to do that already in my previous email but forgot.
Acked-by: Kalle Valo <kvalo@codeaurora.org>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH bpf-next 5/7] sefltests/bpf: support FLOW_DISSECTOR_F_PARSE_1ST_FRAG
From: Song Liu @ 2019-07-25 5:36 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Stanislav Fomichev, Networking, bpf, David S . Miller,
Alexei Starovoitov, Daniel Borkmann, Willem de Bruijn,
Petar Penkov
In-Reply-To: <20190724235254.GB3500@mini-arch>
On Wed, Jul 24, 2019 at 4:52 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 07/24, Song Liu wrote:
> > On Wed, Jul 24, 2019 at 10:11 AM Stanislav Fomichev <sdf@google.com> wrote:
> > >
> > > bpf_flow.c: exit early unless FLOW_DISSECTOR_F_PARSE_1ST_FRAG is passed
> > > in flags. Also, set ip_proto earlier, this makes sure we have correct
> > > value with fragmented packets.
> > >
> > > Add selftest cases to test ipv4/ipv6 fragments and skip eth_get_headlen
> > > tests that don't have FLOW_DISSECTOR_F_PARSE_1ST_FRAG flag.
> > >
> > > eth_get_headlen calls flow dissector with
> > > FLOW_DISSECTOR_F_PARSE_1ST_FRAG flag so we can't run tests that
> > > have different set of input flags against it.
> > >
> > > Cc: Willem de Bruijn <willemb@google.com>
> > > Cc: Petar Penkov <ppenkov@google.com>
> > > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > > ---
> > > .../selftests/bpf/prog_tests/flow_dissector.c | 129 ++++++++++++++++++
> > > tools/testing/selftests/bpf/progs/bpf_flow.c | 28 +++-
> > > 2 files changed, 151 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > > index c938283ac232..966cb3b06870 100644
> > > --- a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > > +++ b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > > @@ -5,6 +5,10 @@
> > > #include <linux/if_tun.h>
> > > #include <sys/uio.h>
> > >
> > > +#ifndef IP_MF
> > > +#define IP_MF 0x2000
> > > +#endif
> > > +
> > > #define CHECK_FLOW_KEYS(desc, got, expected) \
> > > CHECK_ATTR(memcmp(&got, &expected, sizeof(got)) != 0, \
> > > desc, \
> > > @@ -49,6 +53,18 @@ struct ipv6_pkt {
> > > struct tcphdr tcp;
> > > } __packed;
> > >
> > > +struct ipv6_frag_pkt {
> > > + struct ethhdr eth;
> > > + struct ipv6hdr iph;
> > > + struct frag_hdr {
> > > + __u8 nexthdr;
> > > + __u8 reserved;
> > > + __be16 frag_off;
> > > + __be32 identification;
> > > + } ipf;
> > > + struct tcphdr tcp;
> > > +} __packed;
> > > +
> > > struct dvlan_ipv6_pkt {
> > > struct ethhdr eth;
> > > __u16 vlan_tci;
> > > @@ -65,9 +81,11 @@ struct test {
> > > struct ipv4_pkt ipv4;
> > > struct svlan_ipv4_pkt svlan_ipv4;
> > > struct ipv6_pkt ipv6;
> > > + struct ipv6_frag_pkt ipv6_frag;
> > > struct dvlan_ipv6_pkt dvlan_ipv6;
> > > } pkt;
> > > struct bpf_flow_keys keys;
> > > + __u32 flags;
> > > };
> > >
> > > #define VLAN_HLEN 4
> > > @@ -143,6 +161,102 @@ struct test tests[] = {
> > > .n_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > },
> > > },
> > > + {
> > > + .name = "ipv4-frag",
> > > + .pkt.ipv4 = {
> > > + .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> > > + .iph.ihl = 5,
> > > + .iph.protocol = IPPROTO_TCP,
> > > + .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
> > > + .iph.frag_off = __bpf_constant_htons(IP_MF),
> > > + .tcp.doff = 5,
> > > + .tcp.source = 80,
> > > + .tcp.dest = 8080,
> > > + },
> > > + .keys = {
> > > + .flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG,
> > > + .nhoff = ETH_HLEN,
> > > + .thoff = ETH_HLEN + sizeof(struct iphdr),
> > > + .addr_proto = ETH_P_IP,
> > > + .ip_proto = IPPROTO_TCP,
> > > + .n_proto = __bpf_constant_htons(ETH_P_IP),
> > > + .is_frag = true,
> > > + .is_first_frag = true,
> > > + .sport = 80,
> > > + .dport = 8080,
> > > + },
> > > + .flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG,
> > > + },
> > > + {
> > > + .name = "ipv4-no-frag",
> > > + .pkt.ipv4 = {
> > > + .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> > > + .iph.ihl = 5,
> > > + .iph.protocol = IPPROTO_TCP,
> > > + .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
> > > + .iph.frag_off = __bpf_constant_htons(IP_MF),
> > > + .tcp.doff = 5,
> > > + .tcp.source = 80,
> > > + .tcp.dest = 8080,
> > > + },
> > > + .keys = {
> > > + .nhoff = ETH_HLEN,
> > > + .thoff = ETH_HLEN + sizeof(struct iphdr),
> > > + .addr_proto = ETH_P_IP,
> > > + .ip_proto = IPPROTO_TCP,
> > > + .n_proto = __bpf_constant_htons(ETH_P_IP),
> > > + .is_frag = true,
> > > + .is_first_frag = true,
> > > + },
> > > + },
> > > + {
> > > + .name = "ipv6-frag",
> > > + .pkt.ipv6_frag = {
> > > + .eth.h_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > + .iph.nexthdr = IPPROTO_FRAGMENT,
> > > + .iph.payload_len = __bpf_constant_htons(MAGIC_BYTES),
> > > + .ipf.nexthdr = IPPROTO_TCP,
> > > + .tcp.doff = 5,
> > > + .tcp.source = 80,
> > > + .tcp.dest = 8080,
> > > + },
> > > + .keys = {
> > > + .flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG,
> > > + .nhoff = ETH_HLEN,
> > > + .thoff = ETH_HLEN + sizeof(struct ipv6hdr) +
> > > + sizeof(struct frag_hdr),
> > > + .addr_proto = ETH_P_IPV6,
> > > + .ip_proto = IPPROTO_TCP,
> > > + .n_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > + .is_frag = true,
> > > + .is_first_frag = true,
> > > + .sport = 80,
> > > + .dport = 8080,
> > > + },
> > > + .flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG,
> > > + },
> > > + {
> > > + .name = "ipv6-no-frag",
> > > + .pkt.ipv6_frag = {
> > > + .eth.h_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > + .iph.nexthdr = IPPROTO_FRAGMENT,
> > > + .iph.payload_len = __bpf_constant_htons(MAGIC_BYTES),
> > > + .ipf.nexthdr = IPPROTO_TCP,
> > > + .tcp.doff = 5,
> > > + .tcp.source = 80,
> > > + .tcp.dest = 8080,
> > > + },
> > > + .keys = {
> > > + .nhoff = ETH_HLEN,
> > > + .thoff = ETH_HLEN + sizeof(struct ipv6hdr) +
> > > + sizeof(struct frag_hdr),
> > > + .addr_proto = ETH_P_IPV6,
> > > + .ip_proto = IPPROTO_TCP,
> > > + .n_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > + .is_frag = true,
> > > + .is_first_frag = true,
> > > + },
> > > + },
> > > };
> > >
> > > static int create_tap(const char *ifname)
> > > @@ -225,6 +339,13 @@ void test_flow_dissector(void)
> > > .data_size_in = sizeof(tests[i].pkt),
> > > .data_out = &flow_keys,
> > > };
> > > + static struct bpf_flow_keys ctx = {};
> > > +
> > > + if (tests[i].flags) {
> > > + tattr.ctx_in = &ctx;
> > > + tattr.ctx_size_in = sizeof(ctx);
> > > + ctx.flags = tests[i].flags;
> > > + }
> > >
> > > err = bpf_prog_test_run_xattr(&tattr);
> > > CHECK_ATTR(tattr.data_size_out != sizeof(flow_keys) ||
> > > @@ -255,6 +376,14 @@ void test_flow_dissector(void)
> > > struct bpf_prog_test_run_attr tattr = {};
> > > __u32 key = 0;
> > >
> > > + /* Don't run tests that are not marked as
> > > + * FLOW_DISSECTOR_F_PARSE_1ST_FRAG; eth_get_headlen
> > > + * sets this flag.
> > > + */
> > > +
> > > + if (tests[i].flags != FLOW_DISSECTOR_F_PARSE_1ST_FRAG)
> > > + continue;
> >
> > Maybe test flags & FLOW_DISSECTOR_F_PARSE_1ST_FRAG == 0 instead?
> > It is not necessary now, but might be useful in the future.
> I'm not sure about this one. We want flags here to match flags
> from eth_get_headlen:
>
> const unsigned int flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG;
> ...
> if (!skb_flow_dissect_flow_keys_basic(..., flags))
>
> Otherwise the test might break unexpectedly. So I'd rather manually
> adjust a test here if eth_get_headlen flags change.
Could we have
flags == FLOW_DISSECTOR_F_PARSE_1ST_FRAG | some_other_flag
in the future? This flag is not equal to FLOW_DISSECTOR_F_PARSE_1ST_FRAG.
>
> Maybe I should clarify the comment to signify that dependency? Because
> currently it might be read as if we only care about
> FLOW_DISSECTOR_F_PARSE_1ST_FRAG, but we really care about all flags
> in eth_get_headlen; it just happens that it only has one right now.
Some clarification will be great.
Thanks,
Song
^ permalink raw reply
* general protection fault in tls_trim_both_msgs
From: syzbot @ 2019-07-25 5:32 UTC (permalink / raw)
To: ast, aviadye, borisp, bpf, daniel, davejwatson, davem,
john.fastabend, kafai, linux-kernel, netdev, songliubraving,
syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: 9e6dfe80 Add linux-next specific files for 20190724
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1046971fa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=6cbb8fc2cf2842d7
dashboard link: https://syzkaller.appspot.com/bug?extid=0e0fedcad708d12d3032
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0e0fedcad708d12d3032@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 15517 Comm: syz-executor.4 Not tainted 5.3.0-rc1-next-20190724
#50
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:tls_trim_both_msgs+0x54/0x130 net/tls/tls_sw.c:268
Code: 48 c1 ea 03 80 3c 02 00 0f 85 e3 00 00 00 4d 8b b5 b0 06 00 00 48 b8
00 00 00 00 00 fc ff df 49 8d 7e 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 b3 00 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b
RSP: 0018:ffff8880612cfac0 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff8880a8794340 RCX: ffffc9000e7b9000
RDX: 0000000000000005 RSI: ffffffff86298656 RDI: 0000000000000028
RBP: ffff8880612cfae0 R08: ffff88805ae4c580 R09: fffffbfff14a8155
R10: fffffbfff14a8154 R11: ffffffff8a540aa7 R12: 0000000000000000
R13: ffff888061d82e00 R14: 0000000000000000 R15: 00000000ffffffe0
FS: 00007f7d33516700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2fa2f000 CR3: 000000009fcf1000 CR4: 00000000001406e0
Call Trace:
tls_sw_sendmsg+0xe38/0x17b0 net/tls/tls_sw.c:1057
inet6_sendmsg+0x9e/0xe0 net/ipv6/af_inet6.c:576
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
__sys_sendto+0x262/0x380 net/socket.c:1952
__do_sys_sendto net/socket.c:1964 [inline]
__se_sys_sendto net/socket.c:1960 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1960
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f7d33515c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000459829
RDX: ffffffffffffffc1 RSI: 00000000200005c0 RDI: 0000000000000003
RBP: 000000000075bf20 R08: 0000000000000000 R09: 1201000000003618
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7d335166d4
R13: 00000000004c7669 R14: 00000000004dcc70 R15: 00000000ffffffff
Modules linked in:
---[ end trace 2dd728cceb39a185 ]---
RIP: 0010:tls_trim_both_msgs+0x54/0x130 net/tls/tls_sw.c:268
Code: 48 c1 ea 03 80 3c 02 00 0f 85 e3 00 00 00 4d 8b b5 b0 06 00 00 48 b8
00 00 00 00 00 fc ff df 49 8d 7e 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 b3 00 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b
RSP: 0018:ffff8880612cfac0 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff8880a8794340 RCX: ffffc9000e7b9000
RDX: 0000000000000005 RSI: ffffffff86298656 RDI: 0000000000000028
RBP: ffff8880612cfae0 R08: ffff88805ae4c580 R09: fffffbfff14a8155
R10: fffffbfff14a8154 R11: ffffffff8a540aa7 R12: 0000000000000000
R13: ffff888061d82e00 R14: 0000000000000000 R15: 00000000ffffffe0
FS: 00007f7d33516700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000019dbe80 CR3: 000000009fcf1000 CR4: 00000000001406e0
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* KASAN: use-after-free Read in tls_sk_proto_cleanup
From: syzbot @ 2019-07-25 5:32 UTC (permalink / raw)
To: aviadye, borisp, daniel, davejwatson, davem, john.fastabend,
linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 9e6dfe80 Add linux-next specific files for 20190724
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16797ef0600000
kernel config: https://syzkaller.appspot.com/x/.config?x=6cbb8fc2cf2842d7
dashboard link: https://syzkaller.appspot.com/bug?extid=42f653cb62d6b4f1c97b
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+42f653cb62d6b4f1c97b@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in tls_sk_proto_cleanup+0x37f/0x3e0
net/tls/tls_main.c:299
Read of size 1 at addr ffff88808adaacd4 by task syz-executor.2/10709
CPU: 1 PID: 10709 Comm: syz-executor.2 Not tainted 5.3.0-rc1-next-20190724
#50
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+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x17 mm/kasan/common.c:612
__asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:129
tls_sk_proto_cleanup+0x37f/0x3e0 net/tls/tls_main.c:299
tls_sk_proto_unhash+0x90/0x3f0 net/tls/tls_main.c:330
tcp_set_state+0x5b9/0x7d0 net/ipv4/tcp.c:2235
tcp_done+0xe2/0x320 net/ipv4/tcp.c:3824
tcp_reset+0x132/0x500 net/ipv4/tcp_input.c:4080
tcp_validate_incoming+0xa2d/0x1660 net/ipv4/tcp_input.c:5440
tcp_rcv_established+0x6b5/0x1e70 net/ipv4/tcp_input.c:5648
tcp_v6_do_rcv+0x41e/0x12c0 net/ipv6/tcp_ipv6.c:1356
sk_backlog_rcv include/net/sock.h:945 [inline]
__release_sock+0x129/0x390 net/core/sock.c:2418
release_sock+0x59/0x1c0 net/core/sock.c:2934
sk_stream_wait_memory+0x65a/0xfc0 net/core/stream.c:149
tls_sw_sendmsg+0x673/0x17b0 net/tls/tls_sw.c:1054
inet6_sendmsg+0x9e/0xe0 net/ipv6/af_inet6.c:576
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
__sys_sendto+0x262/0x380 net/socket.c:1952
__do_sys_sendto net/socket.c:1964 [inline]
__se_sys_sendto net/socket.c:1960 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1960
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f9e6411bc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000459829
RDX: ffffffffffffffc1 RSI: 00000000200005c0 RDI: 0000000000000005
RBP: 000000000075bf20 R08: 0000000000000000 R09: 1201000000003618
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9e6411c6d4
R13: 00000000004c7669 R14: 00000000004dcc70 R15: 00000000ffffffff
Allocated by task 10709:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
create_ctx+0x46/0x260 net/tls/tls_main.c:657
tls_init net/tls/tls_main.c:851 [inline]
tls_init+0x134/0x560 net/tls/tls_main.c:830
__tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline]
tcp_set_ulp+0x330/0x640 net/ipv4/tcp_ulp.c:160
do_tcp_setsockopt.isra.0+0x363/0x24f0 net/ipv4/tcp.c:2810
tcp_setsockopt+0xbe/0xe0 net/ipv4/tcp.c:3137
sock_common_setsockopt+0x94/0xd0 net/core/sock.c:3130
__sys_setsockopt+0x261/0x4c0 net/socket.c:2084
__do_sys_setsockopt net/socket.c:2100 [inline]
__se_sys_setsockopt net/socket.c:2097 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:2097
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 16209:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
tls_ctx_free.part.0+0x3a/0x40 net/tls/tls_main.c:261
tls_ctx_free net/tls/tls_main.c:256 [inline]
tls_ctx_free_deferred+0x9f/0x130 net/tls/tls_main.c:282
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff88808adaacc0
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 20 bytes inside of
512-byte region [ffff88808adaacc0, ffff88808adaaec0)
The buggy address belongs to the page:
page:ffffea00022b6a80 refcount:1 mapcount:0 mapping:ffff8880aa400a80
index:0xffff88808adaa540
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea0002617408 ffffea00024ed248 ffff8880aa400a80
raw: ffff88808adaa540 ffff88808adaa040 0000000100000005 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88808adaab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88808adaac00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff88808adaac80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff88808adaad00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88808adaad80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: general protection fault in rose_transmit_clear_request
From: Dmitry Vyukov @ 2019-07-25 5:30 UTC (permalink / raw)
To: syzbot, Ralf Baechle, David Miller, linux-hams, netdev
Cc: LKML, syzkaller-bugs
In-Reply-To: <0000000000004f0309058e722b24@google.com>
On Wed, Jul 24, 2019 at 9:18 PM syzbot
<syzbot+a1c743815982d9496393@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10656fa4600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7937b718ddac333b
> dashboard link: https://syzkaller.appspot.com/bug?extid=a1c743815982d9496393
> compiler: clang version 9.0.0 (/home/glider/llvm/clang
> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16f6d348600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12cad91fa00000
>
> Bisection is inconclusive: the bug happens on the oldest tested release.
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1164f2f4600000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1564f2f4600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a1c743815982d9496393@syzkaller.appspotmail.com
+net/rose/rose_link.c maintainers
> 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: 1 PID: 0 Comm: swapper/1 Not tainted 5.2.0+ #37
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:rose_send_frame /net/rose/rose_link.c:101 [inline]
> RIP: 0010:rose_transmit_clear_request+0x1ee/0x460 /net/rose/rose_link.c:255
> Code: fc ff df 80 3c 08 00 74 12 4c 89 f7 e8 8b 57 dd fa 48 b9 00 00 00 00
> 00 fc ff df bb 50 03 00 00 49 03 1e 48 89 d8 48 c1 e8 03 <80> 3c 08 00 74
> 12 48 89 df e8 64 57 dd fa 48 b9 00 00 00 00 00 fc
> RSP: 0018:ffff8880aeb09a28 EFLAGS: 00010206
> RAX: 000000000000006a RBX: 0000000000000350 RCX: dffffc0000000000
> RDX: 0000000080000101 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffff8880aeb09a70 R08: ffffffff86d3c4c5 R09: ffffed101255690d
> R10: ffffed101255690d R11: 0000000000000000 R12: ffff8882167bec80
> R13: ffff888092ab47dc R14: ffff8882167beca0 R15: ffff888092ab47de
> FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000190 CR3: 000000009c1e1000 CR4: 00000000001406e0
> Call Trace:
> <IRQ>
> rose_rx_call_request+0xadb/0x1b00 /net/rose/af_rose.c:998
> rose_loopback_timer+0x2f8/0x480 /net/rose/rose_loopback.c:100
> call_timer_fn+0xec/0x200 /kernel/time/timer.c:1322
> expire_timers /kernel/time/timer.c:1366 [inline]
> __run_timers+0x7cd/0x9c0 /kernel/time/timer.c:1685
> run_timer_softirq+0x1d/0x40 /kernel/time/timer.c:1698
> __do_softirq+0x307/0x774 /./arch/x86/include/asm/paravirt.h:778
> invoke_softirq /kernel/softirq.c:373 [inline]
> irq_exit+0x1e9/0x1f0 /kernel/softirq.c:413
> exiting_irq /./arch/x86/include/asm/apic.h:537 [inline]
> smp_apic_timer_interrupt+0xcc/0x220 /arch/x86/kernel/apic/apic.c:1095
> apic_timer_interrupt+0xf/0x20 /arch/x86/entry/entry_64.S:828
> </IRQ>
> RIP: 0010:native_safe_halt+0xe/0x10 /./arch/x86/include/asm/irqflags.h:61
> Code: 38 46 0a fa eb ae 89 d9 80 e1 07 80 c1 03 38 c1 7c ba 48 89 df e8 22
> 46 0a fa eb b0 e9 07 00 00 00 0f 00 2d e6 b0 5b 00 fb f4 <c3> 90 e9 07 00
> 00 00 0f 00 2d d6 b0 5b 00 f4 c3 90 90 55 48 89 e5
> RSP: 0018:ffff8880a98c7d38 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: 1ffffffff11950f3 RBX: ffff8880a98bc340 RCX: dffffc0000000000
> RDX: 0000000000000000 RSI: ffffffff812cd3ea RDI: ffff8880a98bcb38
> RBP: ffff8880a98c7d40 R08: ffff8880a98bcb50 R09: ffffed1015317869
> R10: ffffed1015317869 R11: 0000000000000000 R12: 1ffff11015317868
> R13: 0000000000000001 R14: dffffc0000000000 R15: 1ffffffff11950f1
> arch_cpu_idle+0xa/0x10 /arch/x86/kernel/process.c:571
> default_idle_call+0x59/0xa0 /kernel/sched/idle.c:94
> cpuidle_idle_call /kernel/sched/idle.c:154 [inline]
> do_idle+0x174/0x770 /kernel/sched/idle.c:263
> cpu_startup_entry+0x25/0x30 /kernel/sched/idle.c:354
> start_secondary+0x3f4/0x490 /arch/x86/kernel/smpboot.c:264
> secondary_startup_64+0xa4/0xb0 /arch/x86/kernel/head_64.S:241
> Modules linked in:
> ---[ end trace fd2ad3b72484e5c3 ]---
> RIP: 0010:rose_send_frame /net/rose/rose_link.c:101 [inline]
> RIP: 0010:rose_transmit_clear_request+0x1ee/0x460 /net/rose/rose_link.c:255
> Code: fc ff df 80 3c 08 00 74 12 4c 89 f7 e8 8b 57 dd fa 48 b9 00 00 00 00
> 00 fc ff df bb 50 03 00 00 49 03 1e 48 89 d8 48 c1 e8 03 <80> 3c 08 00 74
> 12 48 89 df e8 64 57 dd fa 48 b9 00 00 00 00 00 fc
> RSP: 0018:ffff8880aeb09a28 EFLAGS: 00010206
> RAX: 000000000000006a RBX: 0000000000000350 RCX: dffffc0000000000
> RDX: 0000000080000101 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffff8880aeb09a70 R08: ffffffff86d3c4c5 R09: ffffed101255690d
> R10: ffffed101255690d R11: 0000000000000000 R12: ffff8882167bec80
> R13: ffff888092ab47dc R14: ffff8882167beca0 R15: ffff888092ab47de
> FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000190 CR3: 000000009c1e1000 CR4: 00000000001406e0
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> 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/0000000000004f0309058e722b24%40google.com.
^ permalink raw reply
* Re: [PATCH 5/6] vhost: mark dirty pages during map uninit
From: Michael S. Tsirkin @ 2019-07-25 5:21 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <a670cd0d-581d-1aba-41bd-c643c19f9604@redhat.com>
On Tue, Jul 23, 2019 at 09:19:33PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午5:17, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 03:57:17AM -0400, Jason Wang wrote:
> > > We don't mark dirty pages if the map was teared down outside MMU
> > > notifier. This will lead untracked dirty pages. Fixing by marking
> > > dirty pages during map uninit.
> > >
> > > Reported-by: Michael S. Tsirkin<mst@redhat.com>
> > > Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual address")
> > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > > ---
> > > drivers/vhost/vhost.c | 22 ++++++++++++++++------
> > > 1 file changed, 16 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > index 89c9f08b5146..5b8821d00fe4 100644
> > > --- a/drivers/vhost/vhost.c
> > > +++ b/drivers/vhost/vhost.c
> > > @@ -306,6 +306,18 @@ static void vhost_map_unprefetch(struct vhost_map *map)
> > > kfree(map);
> > > }
> > > +static void vhost_set_map_dirty(struct vhost_virtqueue *vq,
> > > + struct vhost_map *map, int index)
> > > +{
> > > + struct vhost_uaddr *uaddr = &vq->uaddrs[index];
> > > + int i;
> > > +
> > > + if (uaddr->write) {
> > > + for (i = 0; i < map->npages; i++)
> > > + set_page_dirty(map->pages[i]);
> > > + }
> > > +}
> > > +
> > > static void vhost_uninit_vq_maps(struct vhost_virtqueue *vq)
> > > {
> > > struct vhost_map *map[VHOST_NUM_ADDRS];
> > > @@ -315,8 +327,10 @@ static void vhost_uninit_vq_maps(struct vhost_virtqueue *vq)
> > > for (i = 0; i < VHOST_NUM_ADDRS; i++) {
> > > map[i] = rcu_dereference_protected(vq->maps[i],
> > > lockdep_is_held(&vq->mmu_lock));
> > > - if (map[i])
> > > + if (map[i]) {
> > > + vhost_set_map_dirty(vq, map[i], i);
> > > rcu_assign_pointer(vq->maps[i], NULL);
> > > + }
> > > }
> > > spin_unlock(&vq->mmu_lock);
> > > @@ -354,7 +368,6 @@ static void vhost_invalidate_vq_start(struct vhost_virtqueue *vq,
> > > {
> > > struct vhost_uaddr *uaddr = &vq->uaddrs[index];
> > > struct vhost_map *map;
> > > - int i;
> > > if (!vhost_map_range_overlap(uaddr, start, end))
> > > return;
> > > @@ -365,10 +378,7 @@ static void vhost_invalidate_vq_start(struct vhost_virtqueue *vq,
> > > map = rcu_dereference_protected(vq->maps[index],
> > > lockdep_is_held(&vq->mmu_lock));
> > > if (map) {
> > > - if (uaddr->write) {
> > > - for (i = 0; i < map->npages; i++)
> > > - set_page_dirty(map->pages[i]);
> > > - }
> > > + vhost_set_map_dirty(vq, map, index);
> > > rcu_assign_pointer(vq->maps[index], NULL);
> > > }
> > > spin_unlock(&vq->mmu_lock);
> > OK and the reason it's safe is because the invalidate counter
> > got incremented so we know page will not get mapped again.
> >
> > But we*do* need to wait for page not to be mapped.
> > And if that means waiting for VQ processing to finish,
> > then I worry that is a very log time.
> >
>
> I'm not sure I get you here. If we don't have such map, we will fall back to
> normal uaccess helper. And in the memory accessor, the rcu critical section
> is pretty small.
>
> Thanks
>
OK. So the trick is that page_mkclean invokes mmu notifiers.
--
MST
^ permalink raw reply
* Re: [PATCH bpf-next 01/10] libbpf: add .BTF.ext offset relocation section loading
From: Song Liu @ 2019-07-25 5:20 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Yonghong Song, Kernel Team
In-Reply-To: <CAEf4BzZsU8qXa08neQ=nrFFTXpSWsxrZuZz=kVjS2BXNUoofUw@mail.gmail.com>
> On Jul 24, 2019, at 5:37 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Wed, Jul 24, 2019 at 5:00 PM Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Jul 24, 2019, at 12:27 PM, Andrii Nakryiko <andriin@fb.com> wrote:
>>>
>>> Add support for BPF CO-RE offset relocations. Add section/record
>>> iteration macros for .BTF.ext. These macro are useful for iterating over
>>> each .BTF.ext record, either for dumping out contents or later for BPF
>>> CO-RE relocation handling.
>>>
>>> To enable other parts of libbpf to work with .BTF.ext contents, moved
>>> a bunch of type definitions into libbpf_internal.h.
>>>
>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>> ---
>>> tools/lib/bpf/btf.c | 64 +++++++++--------------
>>> tools/lib/bpf/btf.h | 4 ++
>>> tools/lib/bpf/libbpf_internal.h | 91 +++++++++++++++++++++++++++++++++
>>> 3 files changed, 118 insertions(+), 41 deletions(-)
>>>
>
> [...]
>
>>> +
>>> static int btf_ext_parse_hdr(__u8 *data, __u32 data_size)
>>> {
>>> const struct btf_ext_header *hdr = (struct btf_ext_header *)data;
>>> @@ -1004,6 +979,13 @@ struct btf_ext *btf_ext__new(__u8 *data, __u32 size)
>>> if (err)
>>> goto done;
>>>
>>> + /* check if there is offset_reloc_off/offset_reloc_len fields */
>>> + if (btf_ext->hdr->hdr_len < sizeof(struct btf_ext_header))
>>
>> This check will break when we add more optional sections to btf_ext_header.
>> Maybe use offsetof() instead?
>
> I didn't do it, because there are no fields after offset_reloc_len.
> But now I though that maybe it would be ok to add zero-sized marker
> field, kind of like marking off various versions of btf_ext header?
>
> Alternatively, I can add offsetofend() macro somewhere in libbpf_internal.h.
>
> Do you have any preference?
We only need a stable number to compare against. offsetofend() works.
Or we can simply have something like
if (btf_ext->hdr->hdr_len <= offsetof(struct btf_ext_header, offset_reloc_off))
goto done;
or
if (btf_ext->hdr->hdr_len < offsetof(struct btf_ext_header, offset_reloc_len))
goto done;
Does this make sense?
Thanks,
Song
^ permalink raw reply
* [PATCH] hv_sock: use HV_HYP_PAGE_SIZE instead of PAGE_SIZE_4K
From: Himadri Pandya @ 2019-07-25 5:11 UTC (permalink / raw)
To: mikelley, kys, haiyangz, sthemmin, sashal, davem
Cc: linux-hyperv, netdev, linux-kernel, Himadri Pandya
Older windows hosts require the hv_sock ring buffer to be defined
using 4K pages. This was achieved by using the symbol PAGE_SIZE_4K
defined specifically for this purpose. But now we have a new symbol
HV_HYP_PAGE_SIZE defined in hyperv-tlfs which can be used for this.
This patch removes the definition of symbol PAGE_SIZE_4K and replaces
its usage with the symbol HV_HYP_PAGE_SIZE. This patch also aligns
sndbuf and rcvbuf to hyper-v specific page size using HV_HYP_PAGE_SIZE
instead of the guest page size(PAGE_SIZE) as hyper-v expects the page
size to be 4K and it might not be the case on ARM64 architecture.
Signed-off-by: Himadri Pandya <himadri18.07@gmail.com>
---
net/vmw_vsock/hyperv_transport.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index f2084e3f7aa4..ecb5d72d8010 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -13,15 +13,16 @@
#include <linux/hyperv.h>
#include <net/sock.h>
#include <net/af_vsock.h>
+#include <asm/hyperv-tlfs.h>
/* Older (VMBUS version 'VERSION_WIN10' or before) Windows hosts have some
- * stricter requirements on the hv_sock ring buffer size of six 4K pages. Newer
- * hosts don't have this limitation; but, keep the defaults the same for compat.
+ * stricter requirements on the hv_sock ring buffer size of six 4K pages.
+ * hyperv-tlfs defines HV_HYP_PAGE_SIZE as 4K. Newer hosts don't have this
+ * limitation; but, keep the defaults the same for compat.
*/
-#define PAGE_SIZE_4K 4096
-#define RINGBUFFER_HVS_RCV_SIZE (PAGE_SIZE_4K * 6)
-#define RINGBUFFER_HVS_SND_SIZE (PAGE_SIZE_4K * 6)
-#define RINGBUFFER_HVS_MAX_SIZE (PAGE_SIZE_4K * 64)
+#define RINGBUFFER_HVS_RCV_SIZE (HV_HYP_PAGE_SIZE * 6)
+#define RINGBUFFER_HVS_SND_SIZE (HV_HYP_PAGE_SIZE * 6)
+#define RINGBUFFER_HVS_MAX_SIZE (HV_HYP_PAGE_SIZE * 64)
/* The MTU is 16KB per the host side's design */
#define HVS_MTU_SIZE (1024 * 16)
@@ -54,7 +55,7 @@ struct hvs_recv_buf {
* ringbuffer APIs that allow us to directly copy data from userspace buffer
* to VMBus ringbuffer.
*/
-#define HVS_SEND_BUF_SIZE (PAGE_SIZE_4K - sizeof(struct vmpipe_proto_header))
+#define HVS_SEND_BUF_SIZE (HV_HYP_PAGE_SIZE - sizeof(struct vmpipe_proto_header))
struct hvs_send_buf {
/* The header before the payload data */
@@ -388,10 +389,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
} else {
sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
- sndbuf = ALIGN(sndbuf, PAGE_SIZE);
+ sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
- rcvbuf = ALIGN(rcvbuf, PAGE_SIZE);
+ rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
}
ret = vmbus_open(chan, sndbuf, rcvbuf, NULL, 0, hvs_channel_cb,
@@ -662,7 +663,7 @@ static ssize_t hvs_stream_enqueue(struct vsock_sock *vsk, struct msghdr *msg,
ssize_t ret = 0;
ssize_t bytes_written = 0;
- BUILD_BUG_ON(sizeof(*send_buf) != PAGE_SIZE_4K);
+ BUILD_BUG_ON(sizeof(*send_buf) != HV_HYP_PAGE_SIZE);
send_buf = kmalloc(sizeof(*send_buf), GFP_KERNEL);
if (!send_buf)
--
2.17.1
^ permalink raw reply related
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Dumazet @ 2019-07-25 5:04 UTC (permalink / raw)
To: David Miller, eric.dumazet, dvyukov, netdev, fw, i.maximets,
edumazet, dsahern, linux-kernel, syzkaller-bugs
In-Reply-To: <20190724210950.GH213255@gmail.com>
On 7/24/19 11:09 PM, Eric Biggers wrote:
> On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote:
>> From: Eric Biggers <ebiggers@kernel.org>
>> Date: Wed, 24 Jul 2019 11:37:12 -0700
>>
>>> We can argue about what words to use to describe this situation, but
>>> it doesn't change the situation itself.
>>
>> And we should argue about those words because it matters to humans and
>> effects how they feel, and humans ultimately fix these bugs.
>>
>> So please stop with the hyperbole.
>>
>> Thank you.
>
> Okay, there are 151 bugs that syzbot saw on the mainline Linux kernel in the
> last 7 days (90.1% with reproducers). Of those, 59 were reported over 3 months
> ago (89.8% with reproducers). Of those, 12 were reported over a year ago (83.3%
> with reproducers).
>
> No opinion on whether those are small/medium/large numbers, in case it would
> hurt someone's feelings.
>
> These numbers do *not* include bugs that are still valid but weren't seen on
> mainline in last 7 days, e.g.:
>
> - Bugs that are seen only rarely, so by chance weren't seen in last 7 days.
> - Bugs only in linux-next and/or subsystem branches.
> - Bugs that were seen in mainline more than 7 days ago, and then only on
> linux-next or subsystem branch in last 7 days.
> - Bugs that stopped being seen due to a change in syzkaller.
> - Bugs that stopped being seen due to a change in kernel config.
> - Bugs that stopped being seen due to other environment changes such as kernel
> command line parameters.
> - Bugs that stopped being seen due to a kernel change that hid the bug but
> didn't actually fix it, i.e. still reachable in other ways.
>
We do not doubt syzkaller is an incredible tool.
But netdev@ and lkml@ are mailing lists for humans to interact,
exchange ideas, send patches and review them.
To me, an issue that was reported to netdev by a real user is _way_ more important
than potential issues that a bot might have found doing crazy things.
We need to keep optimal S/N on mailing lists, so any bots trying to interact
with these lists must be very cautious and damn smart.
When I have time to spare and can work on syzbot reports, I am going to a web
page where I can see them and select the ones it makes sense to fix.
I hate having to set up email filters.
^ 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