* [PATCH] net: bluetooth: hci_sock: Fix a possible null-pointer dereference in hci_mgmt_cmd()
From: Jia-Ju Bai @ 2019-07-25 9:22 UTC (permalink / raw)
To: marcel, johan.hedberg, davem
Cc: linux-bluetooth, netdev, linux-kernel, Jia-Ju Bai
In hci_mgmt_cmd(), there is an if statement on line 1570 to check
whether hdev is NULL:
if (hdev && chan->hdev_init)
When hdev is NULL, it is used on line 1575:
err = handler->func(sk, hdev, cp, len);
Some called functions of handler->func use hdev, such as:
set_appearance(), add_device() and remove_device() in mgmt.c.
Thus, a possible null-pointer dereference may occur.
To fix this bug, hdev is checked before calling handler->func().
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/bluetooth/hci_sock.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index d32077b28433..18ea1e47ea48 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -1570,11 +1570,12 @@ static int hci_mgmt_cmd(struct hci_mgmt_chan *chan, struct sock *sk,
if (hdev && chan->hdev_init)
chan->hdev_init(sk, hdev);
- cp = buf + sizeof(*hdr);
-
- err = handler->func(sk, hdev, cp, len);
- if (err < 0)
- goto done;
+ if (hdev) {
+ cp = buf + sizeof(*hdr);
+ err = handler->func(sk, hdev, cp, len);
+ if (err < 0)
+ goto done;
+ }
err = msglen;
--
2.17.0
^ permalink raw reply related
* RE: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: David Laight @ 2019-07-25 9:21 UTC (permalink / raw)
To: 'Jian-Hong Pan', Yan-Hsuan Chuang, Kalle Valo,
David S . Miller
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com,
stable@vger.kernel.org
In-Reply-To: <20190725080925.6575-1-jian-hong@endlessm.com>
From: Jian-Hong Pan
> Sent: 25 July 2019 09:09
> 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.
...
> for (i = 0; i < len; i++) {
> - skb = dev_alloc_skb(buf_sz);
> - if (!skb) {
> + buf = devm_kzalloc(rtwdev->dev, buf_sz, GFP_ATOMIC);
You should do this allocation somewhere than can sleep.
So you don't need GFP_ATOMIC, making the allocate (and dma map)
much less likely to fail.
If they do fail using a smaller ring might be better than failing
completely.
I suspect that buf_sz gets rounded up somewhat.
Also you almost certainly want 'buf' to be cache-line aligned.
I don't think devm_kzalloc() guarantees that at all.
While allocating all 512 buffers in one block (just over 4MB)
is probably not a good idea, you may need to allocated (and dma map)
then in groups.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* [PATCH] net: tipc: Fix a possible null-pointer dereference in tipc_publ_purge()
From: Jia-Ju Bai @ 2019-07-25 9:20 UTC (permalink / raw)
To: jon.maloy, ying.xue, davem
Cc: netdev, tipc-discussion, linux-kernel, Jia-Ju Bai
In tipc_publ_purge(), there is an if statement on 215 to
check whether p is NULL:
if (p)
When p is NULL, it is used on line 226:
kfree_rcu(p, rcu);
Thus, a possible null-pointer dereference may occur.
To fix this bug, p is checked before being used.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/tipc/name_distr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index 44abc8e9c990..241ed2274473 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -223,7 +223,8 @@ static void tipc_publ_purge(struct net *net, struct publication *publ, u32 addr)
publ->key);
}
- kfree_rcu(p, rcu);
+ if (p)
+ kfree_rcu(p, rcu);
}
/**
--
2.17.0
^ permalink raw reply related
* Re: [RFC] performance regression with commit-id<adb03115f459> ("net: get rid of an signed integer overflow in ip_idents_reserve()")
From: Zhangshaokun @ 2019-07-25 9:05 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet, Jiri Pirko, netdev, linux-kernel
Cc: David S. Miller, guoyang (C), zhudacai@hisilicon.com
In-Reply-To: <3d77a08a-22e9-16e8-4091-c5ba4851ff13@gmail.com>
Hi Eric,
Thanks your quick reply.
On 2019/7/24 16:56, Eric Dumazet wrote:
>
>
> On 7/24/19 10:38 AM, Zhangshaokun wrote:
>> Hi,
>>
>> I've observed an significant performance regression with the following commit-id <adb03115f459>
>> ("net: get rid of an signed integer overflow in ip_idents_reserve()").
>
> Yes this UBSAN false positive has been painful
>
>
>
>>
>> Here are my test scenes:
>> ----Server----
>> Cmd: iperf3 -s xxx.xxx.xxxx.xxx -p 10000 -i 0 -A 0
>> Kenel: 4.19.34
>> Server number: 32
>> Port: 10000 – 10032
>> CPU affinity: 0 – 32
>> CPU architecture: aarch64
>> NUMA node0 CPU(s): 0-23
>> NUMA node1 CPU(s): 24-47
>>
>> ----Client----
>> Cmd: iperf3 -u -c xxx.xxx.xxxx.xxx -p 10000 -l 16 -b 0 -t 0 -i 0 -A 8
>> Kenel: 4.19.34
>> Client number: 32
>> Port: 10000 – 10032
>> CPU affinity: 0 – 32
>> CPU architecture: aarch64
>> NUMA node0 CPU(s): 0-23
>> NUMA node1 CPU(s): 24-47
>>
>> Firstly, With patch <adb03115f459> ("net: get rid of an signed integer overflow in ip_idents_reserve()") ,
>> client’s cpu is 100%, and function ip_idents_reserve() cpu usage is very high, but the result is not good.
>> 03:08:32 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
>> 03:08:33 AM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
>> 03:08:33 AM eth1 0.00 3461296.00 0.00 196049.97 0.00 0.00 0.00 0.00
>> 03:08:33 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
>>
>> Secondly, revert that patch, use atomic_add_return() instead, the result is better, as below:
>> 03:23:24 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
>> 03:23:25 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
>> 03:23:25 AM eth1 0.00 12834590.00 0.00 726959.20 0.00 0.00 0.00 0.00
>> 03:23:25 AM eth0 7.00 11.00 0.40 2.95 0.00 0.00 0.00 0.00
>>
>> Thirdly, atomic is not used in ip_idents_reserve() completely ,while each cpu core allocates its own ID segment,
>> Such as: cpu core0 allocate ID 0 – 1023, cpu core1 allocate 1024 – 2047, …,etc
>> the result is the best:
>
> Not sure what you mean.
>
> Less entropy in IPv4 ID is not going to help when fragments _are_ needed.
>
> Send 40,000 datagrams of 2000 bytes each, add delays, reorders, and boom, most of the packets will be lost.
>
> This is not because your use case does not need proper IP ID that we can mess with them.
>
Got it, thanks your more explanation.
> If you need to send packets very fast, maybe use AF_PACKET ?
>
Ok, I will try it later.
>> 03:27:06 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
>> 03:27:07 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
>> 03:27:07 AM eth1 0.00 14275505.00 0.00 808573.53 0.00 0.00 0.00 0.00
>> 03:27:07 AM eth0 0.00 2.00 0.00 0.18 0.00 0.00 0.00 0.00
>>
>> Because atomic operation performance is bottleneck when cpu core number increase, Can we revert the patch or
>> use ID segment for each cpu core instead?
>
>
> This has been discussed in the past.
>
> https://lore.kernel.org/lkml/b0160f4b-b996-b0ee-405a-3d5f1866272e@gmail.com/
>
> We can revert now UBSAN has been fixed.
>
> Or even use Peter patch : https://lore.kernel.org/lkml/20181101172739.GA3196@hirez.programming.kicks-ass.net/
>
I have tried this patch under the condition that I remove try_cmpxchg because there is no this API in arm64 :
09:21:16 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
09:21:17 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
09:21:17 PM eth1 0.00 10434613.00 0.00 591023.00 0.00 0.00 0.00 0.00
09:21:17 PM eth0 1.00 0.00 0.12 0.00 0.00 0.00 0.00 0.00
The result is 10434613.00 pps and it is less than the atomic_add_return(12834590.00 pps).
Any thoughts?
Thanks,
Shaokun
> However, you will still hit badly a shared cache line, not matter what.
>
> Some arches are known to have terrible LL/SC implementation :/
>
>
> .
>
^ permalink raw reply
* Re: [PATCH net-next] can: ti_hecc: remove set but not used variable 'mbx_mask'
From: Jeroen Hofstee @ 2019-07-25 8:19 UTC (permalink / raw)
To: YueHaibing, Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org, Hulk Robot
In-Reply-To: <20190725070044.2692-1-yuehaibing@huawei.com>
On 7/25/19 9:00 AM, YueHaibing wrote:
> 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;
>
>
Indeed, mbx_mask is no longer used after including
"can: ti_hecc: use timestamp based rx-offloading".
Reviewed-by: Jeroen Hofstee <jhofstee@victronenergy.com>
^ permalink raw reply
* [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
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