* Re: general protection fault in dev_map_hash_update_elem
From: Jesper Dangaard Brouer @ 2019-09-06 12:54 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: syzbot, bpf, Daniel Borkmann, Jesper Dangaard Brouer, LKML,
Network Development, syzkaller-bugs,
Toke Høiland-Jørgensen
In-Reply-To: <CAADnVQK94boXD8Y=g1LsBtNG4wrYQ0Jnjxhq7hdxvyBKZuPwXw@mail.gmail.com>
On Thu, 5 Sep 2019 14:44:37 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Thu, Sep 5, 2019 at 1:08 PM syzbot
> <syzbot+4e7a85b1432052e8d6f8@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 6d028043 Add linux-next specific files for 20190830
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=135c1a92600000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69
> > dashboard link: https://syzkaller.appspot.com/bug?extid=4e7a85b1432052e8d6f8
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=109124e1600000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+4e7a85b1432052e8d6f8@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: 10235 Comm: syz-executor.0 Not tainted 5.3.0-rc6-next-20190830
> > #75
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:__write_once_size include/linux/compiler.h:203 [inline]
> > RIP: 0010:__hlist_del include/linux/list.h:795 [inline]
> > RIP: 0010:hlist_del_rcu include/linux/rculist.h:475 [inline]
> > RIP: 0010:__dev_map_hash_update_elem kernel/bpf/devmap.c:668 [inline]
> > RIP: 0010:dev_map_hash_update_elem+0x3c8/0x6e0 kernel/bpf/devmap.c:691
> > Code: 48 89 f1 48 89 75 c8 48 c1 e9 03 80 3c 11 00 0f 85 d3 02 00 00 48 b9
> > 00 00 00 00 00 fc ff df 48 8b 53 10 48 89 d6 48 c1 ee 03 <80> 3c 0e 00 0f
> > 85 97 02 00 00 48 85 c0 48 89 02 74 38 48 89 55 b8
> > RSP: 0018:ffff88808d607c30 EFLAGS: 00010046
> > RAX: 0000000000000000 RBX: ffff8880a7f14580 RCX: dffffc0000000000
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8880a7f14588
> > RBP: ffff88808d607c78 R08: 0000000000000004 R09: ffffed1011ac0f73
> > R10: ffffed1011ac0f72 R11: 0000000000000003 R12: ffff88809f4e9400
> > R13: ffff88809b06ba00 R14: 0000000000000000 R15: ffff88809f4e9528
> > FS: 00007f3a3d50c700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007feb3fcd0000 CR3: 00000000986b9000 CR4: 00000000001406e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > map_update_elem+0xc82/0x10b0 kernel/bpf/syscall.c:966
> > __do_sys_bpf+0x8b5/0x3350 kernel/bpf/syscall.c:2854
> > __se_sys_bpf kernel/bpf/syscall.c:2825 [inline]
> > __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:2825
> > do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x459879
> > 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:00007f3a3d50bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459879
> > RDX: 0000000000000020 RSI: 0000000020000040 RDI: 0000000000000002
> > RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3a3d50c6d4
> > R13: 00000000004bfc86 R14: 00000000004d1960 R15: 00000000ffffffff
> > Modules linked in:
> > ---[ end trace 083223e21dbd0ae5 ]---
> > RIP: 0010:__write_once_size include/linux/compiler.h:203 [inline]
> > RIP: 0010:__hlist_del include/linux/list.h:795 [inline]
> > RIP: 0010:hlist_del_rcu include/linux/rculist.h:475 [inline]
> > RIP: 0010:__dev_map_hash_update_elem kernel/bpf/devmap.c:668 [inline]
> > RIP: 0010:dev_map_hash_update_elem+0x3c8/0x6e0 kernel/bpf/devmap.c:691
>
> Toke,
> please take a look.
> Thanks!
Hi Toke,
I think the problem is that you read:
old_dev = __dev_map_hash_lookup_elem(map, idx);
Before holding the lock dtab->index_lock...
I'm not sure this is the correct fix, but I think below change should
solve the issue (not even compile tested):
[bpf-next]$ git diff
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index 9af048a932b5..c41854a68e9e 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -664,6 +664,9 @@ static int __dev_map_hash_update_elem(struct net *net, struct bpf_map *map,
spin_lock_irqsave(&dtab->index_lock, flags);
+ /* Re-read old_dev while holding lock*/
+ old_dev = __dev_map_hash_lookup_elem(map, idx);
+
if (old_dev) {
hlist_del_rcu(&old_dev->index_hlist);
} else {
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply related
* Re: [PATCH v1 net-next 00/15] tc-taprio offload for SJA1105 DSA
From: David Miller @ 2019-09-06 12:54 UTC (permalink / raw)
To: olteanv
Cc: f.fainelli, vivien.didelot, andrew, vinicius.gomes, vedang.patel,
richardcochran, weifeng.voon, jiri, m-karicheri2, Jose.Abreu,
ilias.apalodimas, jhs, xiyou.wangcong, kurt.kanzenbach, netdev
In-Reply-To: <20190902162544.24613-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Mon, 2 Sep 2019 19:25:29 +0300
> This is the first attempt to submit the tc-taprio offload model for
> inclusion in the net tree.
Someone really needs to review this.
I'm not applying this patch series until someone knowledgable in this
area does some kind of review.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] vhost: re-introducing metadata acceleration through kernel virtual address
From: Jason Wang @ 2019-09-06 12:51 UTC (permalink / raw)
To: Hillf Danton
Cc: mst, kvm, virtualization, netdev, linux-kernel, jgg, aarcange,
jglisse, linux-mm, James Bottomley, Christoph Hellwig,
David Miller, linux-arm-kernel, linux-parisc
In-Reply-To: <20190906032154.9376-1-hdanton@sina.com>
On 2019/9/6 上午11:21, Hillf Danton wrote:
> On Thu, 5 Sep 2019 20:27:36 +0800 From: Jason Wang <jasowang@redhat.com>
>> +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]);
>> + }
> Not sure need to set page dirty under page lock.
Just to make sure I understand the issue. Do you mean there's no need
for set_page_dirty() here? If yes, is there any other function that
already did this?
Thanks
^ permalink raw reply
* [PATCH] net: stmmac: socfpga: re-use the `interface` parameter from platform data
From: Alexandru Ardelean @ 2019-09-06 12:30 UTC (permalink / raw)
To: netdev, linux-stm32, linux-arm-kernel, linux-kernel
Cc: peppe.cavallaro, alexandre.torgue, joabreu, mcoquelin.stm32,
davem, Alexandru Ardelean
The socfpga sub-driver defines an `interface` field in the `socfpga_dwmac`
struct and parses it on init.
The shared `stmmac_probe_config_dt()` function also parses this from the
device-tree and makes it available on the returned `plat_data` (which is
the same data available via `netdev_priv()`).
All that's needed now is to dig that information out, via some
`dev_get_drvdata()` && `netdev_priv()` calls and re-use it.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index c141fe783e87..3094bb1f77e5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -46,7 +46,6 @@ struct socfpga_dwmac_ops {
};
struct socfpga_dwmac {
- int interface;
u32 reg_offset;
u32 reg_shift;
struct device *dev;
@@ -110,8 +109,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
struct resource res_tse_pcs;
struct resource res_sgmii_adapter;
- dwmac->interface = of_get_phy_mode(np);
-
sys_mgr_base_addr =
altr_sysmgr_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
if (IS_ERR(sys_mgr_base_addr)) {
@@ -231,8 +228,12 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
return ret;
}
-static int socfpga_set_phy_mode_common(int phymode, u32 *val)
+static int socfpga_set_phy_mode_common(struct socfpga_dwmac *dwmac, u32 *val)
{
+ struct net_device *ndev = dev_get_drvdata(dwmac->dev);
+ struct stmmac_priv *priv = netdev_priv(ndev);
+ int phymode = priv->plat->interface;
+
switch (phymode) {
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
@@ -255,12 +256,11 @@ static int socfpga_set_phy_mode_common(int phymode, u32 *val)
static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
- int phymode = dwmac->interface;
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
u32 ctrl, val, module;
- if (socfpga_set_phy_mode_common(phymode, &val)) {
+ if (socfpga_set_phy_mode_common(dwmac, &val)) {
dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
return -EINVAL;
}
@@ -314,12 +314,11 @@ static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
- int phymode = dwmac->interface;
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
u32 ctrl, val, module;
- if (socfpga_set_phy_mode_common(phymode, &val))
+ if (socfpga_set_phy_mode_common(dwmac, &val))
return -EINVAL;
/* Overwrite val to GMII if splitter core is enabled. The phymode here
--
2.20.1
^ permalink raw reply related
* Apply@ 5% Fixed Interest Rate,no Cre-dit Review,From R20,000.00 to R30million*
From: RCS Finance @ 2019-09-06 12:29 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1: Type: text/plain, Size: 497 bytes --]
To Whom It May Concern:
Kindly find attached for more info on our 5% Fixed Interest Rate.
*NOTE that our current calculated 5% interest rate is our on-going promotional interest rate and has been extended to the End of Sept 2019.
Don't miss this opportunity as we look forward to welcoming you to the RCS FAMILY.
PLEASE NOTE: This is an automated email message, please do NOT reply to the sender ***
*Kindly direct all required details to : info@rcsgroupsa.com
Sincerely,
RCS GROUP
[-- Attachment #1.2: Type: text/html, Size: 1238 bytes --]
[-- Attachment #2: RCS_FINANCE SA.pdf --]
[-- Type: application/octet-stream, Size: 148257 bytes --]
^ permalink raw reply
* [PATCH] mt76: mt76x0e: make array mt76x0_chan_map static const, makes object smaller
From: Colin King @ 2019-09-06 12:19 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo, Kalle Valo,
David S . Miller, Matthias Brugger, linux-wireless, netdev,
linux-arm-kernel, linux-mediatek
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the array mt76x0_chan_map on the stack but instead make it
static const. Makes the object code smaller by 80 bytes.
Before:
text data bss dec hex filename
7685 1192 0 8877 22ad mediatek/mt76/mt76x0/eeprom.o
After:
text data bss dec hex filename
7541 1256 0 8797 225d mediatek/mt76/mt76x0/eeprom.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
index 9d4426f6905f..96368fac4228 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
@@ -212,7 +212,7 @@ void mt76x0_get_tx_power_per_rate(struct mt76x02_dev *dev,
void mt76x0_get_power_info(struct mt76x02_dev *dev,
struct ieee80211_channel *chan, s8 *tp)
{
- struct mt76x0_chan_map {
+ static const struct mt76x0_chan_map {
u8 chan;
u8 offset;
} chan_map[] = {
--
2.20.1
^ permalink raw reply related
* RE: [RFC PATCH 3/3] Enable ptp_kvm for arm64
From: Jianyong Wu (Arm Technology China) @ 2019-09-06 11:58 UTC (permalink / raw)
To: Marc Zyngier, netdev@vger.kernel.org, pbonzini@redhat.com,
sean.j.christopherson@intel.com, richardcochran@gmail.com,
Mark Rutland, Will Deacon, Suzuki Poulose
Cc: linux-kernel@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China)
In-Reply-To: <4d04867c-2188-9574-fbd1-2356c6b99b7d@kernel.org>
Hi Marc,
Very sorry to have missed this comments.
> -----Original Message-----
> From: Marc Zyngier <maz@kernel.org>
> Sent: Thursday, August 29, 2019 6:33 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; pbonzini@redhat.com;
> sean.j.christopherson@intel.com; richardcochran@gmail.com; Mark Rutland
> <Mark.Rutland@arm.com>; Will Deacon <Will.Deacon@arm.com>; Suzuki
> Poulose <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>;
> Kaly Xin (Arm Technology China) <Kaly.Xin@arm.com>; Justin He (Arm
> Technology China) <Justin.He@arm.com>
> Subject: Re: [RFC PATCH 3/3] Enable ptp_kvm for arm64
>
> On 29/08/2019 07:39, Jianyong Wu wrote:
> > Currently in arm64 virtualization environment, there is no mechanism
> > to keep time sync between guest and host. Time in guest will drift
> > compared with host after boot up as they may both use third party time
> > sources to correct their time respectively. The time deviation will be
> > in order of milliseconds but some scenarios ask for higher time
> > precision, like in cloud envirenment, we want all the VMs running in
> > the host aquire the same level accuracy from host clock.
> >
> > Use of kvm ptp clock, which choose the host clock source clock as a
> > reference clock to sync time clock between guest and host has been
> > adopted by x86 which makes the time sync order from milliseconds to
> nanoseconds.
> >
> > This patch enable kvm ptp on arm64 and we get the similar clock drift
> > as found with x86 with kvm ptp.
> >
> > Test result comparison between with kvm ptp and without it in arm64
> > are as follows. This test derived from the result of command 'chronyc
> > sources'. we should take more cure of the last sample column which
> > shows the offset between the local clock and the source at the last
> measurement.
> >
> > no kvm ptp in guest:
> > MS Name/IP address Stratum Poll Reach LastRx Last sample
> >
> ==========================================================
> ==============
> > ^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/- 21ms
> > ^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/- 21ms
> >
> > in host:
> > MS Name/IP address Stratum Poll Reach LastRx Last sample
> >
> ==========================================================
> ==============
> > ^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/- 18ms
> > ^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/- 18ms
> > ^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/- 18ms
> > ^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/- 17ms
> > ^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/- 17ms
> >
> > The dns1.synet.edu.cn is the network reference clock for guest and
> > 120.25.115.20 is the network reference clock for host. we can't get
> > the clock error between guest and host directly, but a roughly
> > estimated value will be in order of hundreds of us to ms.
> >
> > with kvm ptp in guest:
> > chrony has been disabled in host to remove the disturb by network clock.
>
> Is that a realistic use case? Why should the host not use NTP?
>
Not really, NTP will change the the host clock which will contaminate the data of sync between
Host and guest. But in reality, we will keep NTP online.
> >
> > MS Name/IP address Stratum Poll Reach LastRx Last sample
> >
> ==========================================================
> ==============
> > * PHC0 0 3 377 8 -7ns[ +1ns] +/- 3ns
> > * PHC0 0 3 377 8 +1ns[ +16ns] +/- 3ns
> > * PHC0 0 3 377 6 -4ns[ -0ns] +/- 6ns
> > * PHC0 0 3 377 6 -8ns[ -12ns] +/- 5ns
> > * PHC0 0 3 377 5 +2ns[ +4ns] +/- 4ns
> > * PHC0 0 3 377 13 +2ns[ +4ns] +/- 4ns
> > * PHC0 0 3 377 12 -4ns[ -6ns] +/- 4ns
> > * PHC0 0 3 377 11 -8ns[ -11ns] +/- 6ns
> > * PHC0 0 3 377 10 -14ns[ -20ns] +/- 4ns
> > * PHC0 0 3 377 8 +4ns[ +5ns] +/- 4ns
> >
> > The PHC0 is the ptp clock which choose the host clock as its source
> > clock. So we can be sure to say that the clock error between host and
> > guest is in order of ns.
> >
> > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> > ---
> > arch/arm64/include/asm/arch_timer.h | 3 ++
> > arch/arm64/kvm/arch_ptp_kvm.c | 76
> ++++++++++++++++++++++++++++
> > drivers/clocksource/arm_arch_timer.c | 6 ++-
> > drivers/ptp/Kconfig | 2 +-
> > include/linux/arm-smccc.h | 14 +++++
> > virt/kvm/arm/psci.c | 17 +++++++
> > 6 files changed, 115 insertions(+), 3 deletions(-) create mode
> > 100644 arch/arm64/kvm/arch_ptp_kvm.c
>
> Please split this patch into two parts: the hypervisor code in a patch and the
> guest code in another patch. Having both of them together is confusing.
>
Ok, really better.
> >
> > diff --git a/arch/arm64/include/asm/arch_timer.h
> > b/arch/arm64/include/asm/arch_timer.h
> > index 6756178c27db..880576a814b6 100644
> > --- a/arch/arm64/include/asm/arch_timer.h
> > +++ b/arch/arm64/include/asm/arch_timer.h
> > @@ -229,4 +229,7 @@ static inline int arch_timer_arch_init(void)
> > return 0;
> > }
> >
> > +extern struct clocksource clocksource_counter; extern u64
> > +arch_counter_read(struct clocksource *cs);
>
> I'm definitely not keen on exposing the internals of the arch_timer driver to
> random subsystems. Furthermore, you seem to expect that the guest kernel
> will only use the arch timer as a clocksource, and nothing really guarantees
> that (in which case get_device_system_crosststamp will fail).
>
The code here is really ugly, I need a better solution to offer a clock source
For the guest.
> It looks to me that we'd be better off exposing a core timekeeping API that
> populates a struct system_counterval_t based on the *current* timekeeper
> monotonic clocksource. This would simplify the split between generic and
> arch-specific code.
>
I think it really necessary.
> Whether or not tglx will be happy with the idea is another problem, but I'm
> certainly not taking any change to the arch timer code based on this.
>
I can have a try, but the detail is not clear for me now.
> > +
> > #endif
> > diff --git a/arch/arm64/kvm/arch_ptp_kvm.c
> > b/arch/arm64/kvm/arch_ptp_kvm.c
>
> We don't put non-hypervisor in arch/arm64/kvm. Please move it back to
> drivers/ptp (as well as its x86 counterpart), and just link the two parts there.
> This should also allow this to be enabled for 32bit guests.
>
Err, sorry, what's mean of "link the two parts there"? should I add another two file update driver/ptp/
Both for arm64 and x86 to contains these arch-specific code or pack them all into ptp_kvm.c?
> > new file mode 100644
> > index 000000000000..6b2165ebce62
> > --- /dev/null
> > +++ b/arch/arm64/kvm/arch_ptp_kvm.c
> > @@ -0,0 +1,76 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Virtual PTP 1588 clock for use with KVM guests
> > + * Copyright (C) 2019 ARM Ltd.
> > + * All Rights Reserved
> > + */
> > +
> > +#include <asm/hypervisor.h>
> > +#include <linux/module.h>
> > +#include <linux/psci.h>
> > +#include <linux/arm-smccc.h>
> > +#include <linux/timecounter.h>
> > +#include <linux/sched/clock.h>
> > +#include <asm/arch_timer.h>
> > +
> > +/*
> > + * as trap call cause delay, this function will return the delay in
> > +nanosecond */ static u64 arm_smccc_1_1_invoke_delay(u32 id, struct
> > +arm_smccc_res *res) {
> > + u64 ns, t1, t2;
> > +
> > + t1 = sched_clock();
> > + arm_smccc_1_1_invoke(id, res);
> > + t2 = sched_clock();
> > + t2 -= t1;
> > + ns = t2;
> > + return ns;
>
> I think you can get rid of the ns variable here...
Yeah, ns is really redundant.
>
> > +}
> > +
> > +int kvm_arch_ptp_init(void)
> > +{
> > + return 0;
> > +}
> > +
> > +int kvm_arch_ptp_get_clock(struct timespec64 *ts) {
> > + u64 ns;
> > + struct arm_smccc_res hvc_res;
> > +
> > + if (!kvm_arm_hyp_service_available(
> > + ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID)) {
> > + return -EOPNOTSUPP;
> > + }
> > + ns =
> arm_smccc_1_1_invoke_delay(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FU
> NC_ID,
> > + &hvc_res);
> > + ts->tv_sec = hvc_res.a0;
> > + ts->tv_nsec = hvc_res.a1;
> > + timespec64_add_ns(ts, ns);
> > + return 0;
> > +}
> > +
> > +int kvm_arch_ptp_get_clock_fn(long *cycle, struct timespec64 *ts,
> > + struct clocksource **cs)
> > +{
> > + u64 ns;
> > + struct arm_smccc_res hvc_res;
> > +
> > + if (!kvm_arm_hyp_service_available(
> > + ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID)) {
> > + return -EOPNOTSUPP;
> > + }
> > + ns =
> arm_smccc_1_1_invoke_delay(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FU
> NC_ID,
> > + &hvc_res);
> > + ts->tv_sec = hvc_res.a0;
> > + ts->tv_nsec = hvc_res.a1;
> > + timespec64_add_ns(ts, ns);
> > + *cycle = hvc_res.a2;
> > + *cs = &clocksource_counter;
> > +
> > + return 0;
> > +}
>
> Why do we have two functions doing almost the same thing? Why do you call
> kvm_arm_hyp_service_available on each and every time? Isn't it enough to
> check in kvm_arch_ptp_init()?
>
Yeah, it's better.
> > +
> > +MODULE_AUTHOR("Marcelo Tosatti <mtosatti@redhat.com>");
> > +MODULE_DESCRIPTION("PTP clock using KVMCLOCK");
> > +MODULE_LICENSE("GPL");
>
> This should only exist in the generic code.
Ok. I will remove them.
>
> > diff --git a/drivers/clocksource/arm_arch_timer.c
> > b/drivers/clocksource/arm_arch_timer.c
> > index 07e57a49d1e8..021e3f69364c 100644
> > --- a/drivers/clocksource/arm_arch_timer.c
> > +++ b/drivers/clocksource/arm_arch_timer.c
> > @@ -175,23 +175,25 @@ static notrace u64 arch_counter_get_cntvct(void)
> > u64 (*arch_timer_read_counter)(void) = arch_counter_get_cntvct;
> > EXPORT_SYMBOL_GPL(arch_timer_read_counter);
> >
> > -static u64 arch_counter_read(struct clocksource *cs)
> > +u64 arch_counter_read(struct clocksource *cs)
> > {
> > return arch_timer_read_counter();
> > }
> > +EXPORT_SYMBOL(arch_counter_read);
> >
> > static u64 arch_counter_read_cc(const struct cyclecounter *cc) {
> > return arch_timer_read_counter();
> > }
> >
> > -static struct clocksource clocksource_counter = {
> > +struct clocksource clocksource_counter = {
> > .name = "arch_sys_counter",
> > .rating = 400,
> > .read = arch_counter_read,
> > .mask = CLOCKSOURCE_MASK(56),
> > .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> > };
> > +EXPORT_SYMBOL(clocksource_counter);
>
> I've said what I thought about this. Not happening.
>
Ok.
> >
> > static struct cyclecounter cyclecounter __ro_after_init = {
> > .read = arch_counter_read_cc,
> > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index
> > 9b8fee5178e8..e032fafdafa7 100644
> > --- a/drivers/ptp/Kconfig
> > +++ b/drivers/ptp/Kconfig
> > @@ -110,7 +110,7 @@ config PTP_1588_CLOCK_PCH config
> > PTP_1588_CLOCK_KVM
> > tristate "KVM virtual PTP clock"
> > depends on PTP_1588_CLOCK
> > - depends on KVM_GUEST && X86
> > + depends on KVM_GUEST && X86 || ARM64
> > default y
> > help
> > This driver adds support for using kvm infrastructure as a PTP
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index a6e4d3e3d10a..2a222a1a8594 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -94,6 +94,7 @@
> >
> > /* KVM "vendor specific" services */
> > #define ARM_SMCCC_KVM_FUNC_FEATURES 0
> > +#define ARM_SMCCC_KVM_PTP 1
> > #define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
> > #define ARM_SMCCC_KVM_NUM_FUNCS 128
> >
> > @@ -102,6 +103,16 @@
> > ARM_SMCCC_SMC_32,
> \
> > ARM_SMCCC_OWNER_VENDOR_HYP,
> \
> > ARM_SMCCC_KVM_FUNC_FEATURES)
> > +/*
> > + * This ID used for virtual ptp kvm clock and it will pass second
> > +value
> > + * and nanosecond value of host real time and system counter by vcpu
> > + * register to guest.
> > + */
> > +#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID
> \
> > + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,
> \
> > + ARM_SMCCC_SMC_32,
> \
> > + ARM_SMCCC_OWNER_VENDOR_HYP,
> \
> > + ARM_SMCCC_KVM_PTP)
> >
> > #ifndef __ASSEMBLY__
> >
> > @@ -373,5 +384,8 @@ asmlinkage void __arm_smccc_hvc(unsigned long
> a0, unsigned long a1,
> > method;
> \
> > })
> >
> > +#include <linux/psci.h>
> > +#include <linux/clocksource.h>
> > +
> > #endif /*__ASSEMBLY__*/
> > #endif /*__LINUX_ARM_SMCCC_H*/
> > diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c index
> > 0debf49bf259..7fffdb25d32c 100644
> > --- a/virt/kvm/arm/psci.c
> > +++ b/virt/kvm/arm/psci.c
> > @@ -392,6 +392,8 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > u32 func_id = smccc_get_function(vcpu);
> > u32 val[4] = {};
> > u32 option;
> > + struct timespec *ts;
> > + u64 cnt;
> >
> > val[0] = SMCCC_RET_NOT_SUPPORTED;
> >
> > @@ -431,6 +433,21 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > break;
> > + /*
> > + * This will used for virtual ptp kvm clock. three
> > + * values will be passed back.
> > + * reg0 stores seconds of host real time;
> > + * reg1 stores nanoseconds of host real time;
> > + * reg2 stotes system counter cycle value.
>
> stores
Yeah
>
> > + */
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + getnstimeofday(ts);
> > + cnt = arch_timer_read_counter();
> > + val[0] = ts->tv_sec;
> > + val[1] = ts->tv_nsec;
> > + val[2] = cnt;
>
> Can you explain what the purpose of exposing this counter is? The guest
> should have access to the physical counter already.
One api of ptp_kvm called ptp_kvm_get_time_fn need a clock sources passed from host as system_counter.
>
> > + val[3] = 0;
> > + break;
>
> This will probably conflict with Steven's stolen time series. Not a big deal
> though.
Err, sorry I am not familiar with this theory. Let me check it.
>
> > default:
> > return kvm_psci_call(vcpu);
> > }
> >
>
> Other questions: how does this works with VM migration? Specially when
> moving from a hypervisor that supports the feature to one that doesn't?
>
I think it won't solve the problem generated by VM migration and only for VMs in a single machine.
Ptp_kvm only works for VMs in the same machine.
But using ptp (not ptp_kvm) clock, all the machines in a low latency network environment can keep time sync in high precision,
Then VMs move from one machine to another will obtain a high precision time sync.
Thanks
Jianyong Wu
> Thanks,
>
> M.
> --
> Jazz is not dead, it just smells funny...
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: Fix error checks in hidp_get/set_raw_report
From: Dan Carpenter @ 2019-09-06 10:58 UTC (permalink / raw)
To: Dan Elkouby
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, Fabian Henneke,
Brian Norris, Al Viro, Andrea Parri, linux-bluetooth, netdev,
linux-kernel
In-Reply-To: <CANnEQ3HX0SNG+Hzs2b+BzLwuewsC8-3sF2urWV+bqUahXq0hVA@mail.gmail.com>
On Fri, Sep 06, 2019 at 01:40:15PM +0300, Dan Elkouby wrote:
> On Fri, Sep 6, 2019 at 1:14 PM Dan Carpenter wrote:
> > I think we also need to update update ms_ff_worker() which assumes that
> > hid_hw_output_report() returns zero on success.
>
> Yes, it looks like that's the case. Should I amend my patch to include
> this fix, or should it be a separate patch? I don't have access to any
> hardware covered by hid-microsoft, so I won't be able to test it.
>
Yes. Please amend the patch. We all understand that you don't have
the hardware so it's not a problem. If you want to blame me in the
commit message that's fine. "Dan Carpenter pointed out a related issue
in ms_ff_worker()". But we're only silencing a warning so it can't
really break anything.
You can add my Reviewed-by tag as well when you resend.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] net/mlx4_en: ethtool: make array modes static const, makes object smaller
From: Colin King @ 2019-09-06 11:53 UTC (permalink / raw)
To: Tariq Toukan, David S . Miller, netdev, linux-rdma
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the array modes on the stack but instead make it
static const. Makes the object code smaller by 303 bytes.
Before:
text data bss dec hex filename
51240 5008 1312 57560 e0d8 mellanox/mlx4/en_ethtool.o
After:
text data bss dec hex filename
50937 5008 1312 57257 dfa9 mellanox/mlx4/en_ethtool.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 94c59939a8cf..d8313e2ee600 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -639,7 +639,7 @@ static unsigned long *ptys2ethtool_link_mode(struct ptys2ethtool_config *cfg,
#define MLX4_BUILD_PTYS2ETHTOOL_CONFIG(reg_, speed_, ...) \
({ \
struct ptys2ethtool_config *cfg; \
- const unsigned int modes[] = { __VA_ARGS__ }; \
+ static const unsigned int modes[] = { __VA_ARGS__ }; \
unsigned int i; \
cfg = &ptys2ethtool_map[reg_]; \
cfg->speed = speed_; \
--
2.20.1
^ permalink raw reply related
* [PATCH] net/ixgbevf: make array api static const, makes object smaller
From: Colin King @ 2019-09-06 11:33 UTC (permalink / raw)
To: gJeff Kirsher, David S . Miller, intel-wired-lan, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the array api on the stack but instead make it
static const. Makes the object code smaller by 58 bytes.
Before:
text data bss dec hex filename
82969 9763 256 92988 16b3c ixgbevf/ixgbevf_main.o
After:
text data bss dec hex filename
82815 9859 256 92930 16b02 ixgbevf/ixgbevf_main.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 8c011d4ce7a9..46c8e2501084 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -2261,12 +2261,14 @@ static void ixgbevf_init_last_counter_stats(struct ixgbevf_adapter *adapter)
static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
- int api[] = { ixgbe_mbox_api_14,
- ixgbe_mbox_api_13,
- ixgbe_mbox_api_12,
- ixgbe_mbox_api_11,
- ixgbe_mbox_api_10,
- ixgbe_mbox_api_unknown };
+ static const int api[] = {
+ ixgbe_mbox_api_14,
+ ixgbe_mbox_api_13,
+ ixgbe_mbox_api_12,
+ ixgbe_mbox_api_11,
+ ixgbe_mbox_api_10,
+ ixgbe_mbox_api_unknown
+ };
int err, idx = 0;
spin_lock_bh(&adapter->mbx_lock);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hidp: Fix assumptions on the return value of hidp_send_message
From: Jiri Kosina @ 2019-09-06 11:31 UTC (permalink / raw)
To: Dan Elkouby
Cc: Dan Carpenter, Benjamin Tissoires, Marcel Holtmann, Johan Hedberg,
David S. Miller, Brian Norris, Fabian Henneke, Al Viro,
Andrea Parri, linux-input, linux-kernel, linux-bluetooth, netdev
In-Reply-To: <20190906110645.27601-1-streetwalkermc@gmail.com>
On Fri, 6 Sep 2019, Dan Elkouby wrote:
> hidp_send_message was changed to return non-zero values on success,
> which some other bits did not expect. This caused spurious errors to be
> propagated through the stack, breaking some drivers, such as hid-sony
> for the Dualshock 4 in Bluetooth mode.
>
> As pointed out by Dan Carpenter, hid-microsoft directly relied on that
> assumption as well.
>
> Fixes: 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return number of queued bytes")
>
> Signed-off-by: Dan Elkouby <streetwalkermc@gmail.com>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Marcel, are you taking this through your tree?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] net: hns3: make array spec_opcode static const, makes object smaller
From: Colin King @ 2019-09-06 11:28 UTC (permalink / raw)
To: Yisen Zhuang, Salil Mehta, David S . Miller, Peng Li, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the array spec_opcode on the stack but instead make it
static const. Makes the object code smaller by 48 bytes.
Before:
text data bss dec hex filename
6914 1040 128 8082 1f92 hns3/hns3vf/hclgevf_cmd.o
After:
text data bss dec hex filename
6866 1040 128 8034 1f62 hns3/hns3vf/hclgevf_cmd.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
index 4c2c9458648f..d5d1cc5d1b6e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -74,7 +74,7 @@ static bool hclgevf_cmd_csq_done(struct hclgevf_hw *hw)
static bool hclgevf_is_special_opcode(u16 opcode)
{
- u16 spec_opcode[] = {0x30, 0x31, 0x32};
+ static const u16 spec_opcode[] = {0x30, 0x31, 0x32};
int i;
for (i = 0; i < ARRAY_SIZE(spec_opcode); i++) {
--
2.20.1
^ permalink raw reply related
* Re: r8169: Performance regression and latency instability
From: Juliana Rodrigueiro @ 2019-09-06 11:25 UTC (permalink / raw)
To: Heiner Kallweit, Holger Hoffstätte, Eric Dumazet, netdev
Cc: Thomas Jarosch, Gerd v. Egidy
In-Reply-To: <a757135b-ec79-0ad5-5886-2989330424ee@intra2net.com>
Hi all!
I would like to kindly ask your help to understand this subject, since my
familiarity with the network stack is limited. I'm still
trying to find a solution for the latency problems with Realtek cards I
reported earlier.
Why does the GSO have to be forced on the socket level
if drivers for high performance chips will have it enabled by default?
A consequence of forcing GSO is that TSO is also forced [1] in
sk_setup_caps() via the NETIF_F_GSO_SOFTWARE flag (list of features with
software fallbacks). I'm sorry for my ignorance, but I wonder if TSO
will really be done in software in case the card does have NETIF_F_TSO
capability but "might not work properly" [2]. (Plus tx-checksum and SG
are all off)
Effectively for me, the following patch shows the same good performance
as the 3.14 kernel (or kernel 4.19 with reverted "tcp: switch to GSO
being always on").
diff --git a/net/core/sock.c b/net/core/sock.c
index 9c32e8eb64da..d792d12e0f66 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1770,7 +1770,7 @@ void sk_setup_caps(struct sock *sk, struct
dst_entry *dst)
sk_dst_set(sk, dst);
sk->sk_route_caps = dst->dev->features | sk->sk_route_forced_caps;
if (sk->sk_route_caps & NETIF_F_GSO)
- sk->sk_route_caps |= NETIF_F_GSO_SOFTWARE;
+ sk->sk_route_caps |= (NETIF_F_GSO_SOFTWARE &
~NETIF_F_ALL_TSO);
sk->sk_route_caps &= ~sk->sk_route_nocaps;
if (sk_can_gso(sk)) {
if (dst->header_len && !xfrm_dst_offload_ok(dst)) {
Any help is highly appreciated.
Best regards,
Juliana.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/core/sock.c?h=linux-4.19.y#n1773
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/realtek/r8169.c?h=linux-4.19.y#n7590
^ permalink raw reply related
* [PATCH] be2net: make two arrays static const, makes object smaller
From: Colin King @ 2019-09-06 11:19 UTC (permalink / raw)
To: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur,
David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the arrays on the stack but instead make them
static const. Makes the object code smaller by 281 bytes.
Before:
text data bss dec hex filename
87553 5672 0 93225 16c29 benet/be_cmds.o
After:
text data bss dec hex filename
87112 5832 0 92944 16b10 benet/be_cmds.o
(gcc version 9.2.1, amd64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 323976c811e9..701c12c9e033 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -2756,7 +2756,7 @@ static int be_flash_BEx(struct be_adapter *adapter,
bool crc_match;
const u8 *p;
- struct flash_comp gen3_flash_types[] = {
+ static const struct flash_comp gen3_flash_types[] = {
{ BE3_ISCSI_PRIMARY_IMAGE_START, OPTYPE_ISCSI_ACTIVE,
BE3_COMP_MAX_SIZE, IMAGE_FIRMWARE_ISCSI},
{ BE3_REDBOOT_START, OPTYPE_REDBOOT,
@@ -2779,7 +2779,7 @@ static int be_flash_BEx(struct be_adapter *adapter,
BE3_PHY_FW_COMP_MAX_SIZE, IMAGE_FIRMWARE_PHY}
};
- struct flash_comp gen2_flash_types[] = {
+ static const struct flash_comp gen2_flash_types[] = {
{ BE2_ISCSI_PRIMARY_IMAGE_START, OPTYPE_ISCSI_ACTIVE,
BE2_COMP_MAX_SIZE, IMAGE_FIRMWARE_ISCSI},
{ BE2_REDBOOT_START, OPTYPE_REDBOOT,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hidp: Fix assumptions on the return value of hidp_send_message
From: Dan Carpenter @ 2019-09-06 11:11 UTC (permalink / raw)
To: Dan Elkouby
Cc: Jiri Kosina, Benjamin Tissoires, Marcel Holtmann, Johan Hedberg,
David S. Miller, Brian Norris, Fabian Henneke, Al Viro,
Andrea Parri, linux-input, linux-kernel, linux-bluetooth, netdev
In-Reply-To: <20190906110645.27601-1-streetwalkermc@gmail.com>
On Fri, Sep 06, 2019 at 02:06:44PM +0300, Dan Elkouby wrote:
> hidp_send_message was changed to return non-zero values on success,
> which some other bits did not expect. This caused spurious errors to be
> propagated through the stack, breaking some drivers, such as hid-sony
> for the Dualshock 4 in Bluetooth mode.
>
> As pointed out by Dan Carpenter, hid-microsoft directly relied on that
> assumption as well.
>
> Fixes: 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return number of queued bytes")
>
> Signed-off-by: Dan Elkouby <streetwalkermc@gmail.com>
Thanks!
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
regards,
dan carpenter
^ permalink raw reply
* [PATCH] Bluetooth: hidp: Fix assumptions on the return value of hidp_send_message
From: Dan Elkouby @ 2019-09-06 11:06 UTC (permalink / raw)
To: Dan Carpenter
Cc: Dan Elkouby, Jiri Kosina, Benjamin Tissoires, Marcel Holtmann,
Johan Hedberg, David S. Miller, Brian Norris, Fabian Henneke,
Al Viro, Andrea Parri, linux-input, linux-kernel, linux-bluetooth,
netdev
In-Reply-To: <20190906101306.GA12017@kadam>
hidp_send_message was changed to return non-zero values on success,
which some other bits did not expect. This caused spurious errors to be
propagated through the stack, breaking some drivers, such as hid-sony
for the Dualshock 4 in Bluetooth mode.
As pointed out by Dan Carpenter, hid-microsoft directly relied on that
assumption as well.
Fixes: 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return number of queued bytes")
Signed-off-by: Dan Elkouby <streetwalkermc@gmail.com>
---
drivers/hid/hid-microsoft.c | 2 +-
net/bluetooth/hidp/core.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 8b3a922bdad3..2cf83856f2e4 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -303,7 +303,7 @@ static void ms_ff_worker(struct work_struct *work)
r->magnitude[MAGNITUDE_WEAK] = ms->weak; /* right actuator */
ret = hid_hw_output_report(hdev, (__u8 *)r, sizeof(*r));
- if (ret)
+ if (ret < 0)
hid_warn(hdev, "failed to send FF report\n");
}
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 8d889969ae7e..bef84b95e2c4 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -267,7 +267,7 @@ static int hidp_get_raw_report(struct hid_device *hid,
set_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
data[0] = report_number;
ret = hidp_send_ctrl_message(session, report_type, data, 1);
- if (ret)
+ if (ret < 0)
goto err;
/* Wait for the return of the report. The returned report
@@ -343,7 +343,7 @@ static int hidp_set_raw_report(struct hid_device *hid, unsigned char reportnum,
data[0] = reportnum;
set_bit(HIDP_WAITING_FOR_SEND_ACK, &session->flags);
ret = hidp_send_ctrl_message(session, report_type, data, count);
- if (ret)
+ if (ret < 0)
goto err;
/* Wait for the ACK from the device. */
--
2.23.0
^ permalink raw reply related
* Re: [PATCH net-next,v3 0/4] flow_offload: update mangle action representation
From: Pablo Neira Ayuso @ 2019-09-06 10:56 UTC (permalink / raw)
To: Edward Cree
Cc: netfilter-devel, davem, netdev, jakub.kicinski, jiri, saeedm,
vishal, vladbu
In-Reply-To: <679ced4b-8bcd-5479-2773-7c75452c2a32@solarflare.com>
On Fri, Sep 06, 2019 at 11:02:18AM +0100, Edward Cree wrote:
> On 06/09/2019 01:03, Pablo Neira Ayuso wrote:
> > This patch updates the mangle action representation:
> >
> > Patch 1) Undo bitwise NOT operation on the mangle mask (coming from tc
> > pedit userspace).
> >
> > Patch 2) mangle value &= mask from the front-end side.
> >
> > Patch 3) adjust offset, length and coalesce consecutive pedit keys into
> > one single action.
> >
> > Patch 4) add support for payload mangling for netfilter.
> >
> > After this patchset:
> >
> > * Offset to payload does not need to be on the 32-bits boundaries anymore.
> > This patchset adds front-end code to adjust the offset and length coming
> > from the tc pedit representation, so drivers get an exact header field
> > offset and length.
> >
> > * This new front-end code coalesces consecutive pedit actions into one
> > single action, so drivers can mangle IPv6 and ethernet address fields
> > in one go, instead once for each 32-bit word.
> >
> > On the driver side, diffstat -t shows that drivers code to deal with
> > payload mangling gets simplified:
> >
> > INSERTED,DELETED,MODIFIED,FILENAME
> > 46,116,0,drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c (-70 LOC)
> > 12,28,0,drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h (-16 LOC)
> > 26,54,0,drivers/net/ethernet/mellanox/mlx5/core/en_tc.c (-27 LOC)
> > 89,111,0,drivers/net/ethernet/netronome/nfp/flower/action.c (-17 LOC)
> >
> > While, on the front-end side the balance is the following:
> >
> > 123,22,0,net/sched/cls_api.c (+101 LOC)
> >
> > Changes since v2:
> >
> > * Fix is_action_keys_supported() breakage in mlx5 reported by Vlad Buslov.
>
> Still NAK for the same reasons as three versions ago (when it was called
> "netfilter: payload mangling offload support"), you've never managed to
> explain why this extra API complexity is useful. (Reducing LOC does not
> mean you've reduced complexity.)
Oh well...
Patch 1) Mask is inverted for no reason, just because tc pedit needs
this in this way. All drivers reverse this mask.
Patch 2) All drivers mask out meaningless fields in the value field.
Patch 3) Without this patchset, offsets are on the 32-bit boundary.
Drivers need to play with the 32-bit mask to infer what field they are
supposed to mangle... eg. with 32-bit offset alignment, checking if
the use want to alter the ttl/hop_limit need for helper structures to
check the 32-bit mask. Mangling a IPv6 address comes with one single
action...
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: Fix error checks in hidp_get/set_raw_report
From: Dan Elkouby @ 2019-09-06 10:40 UTC (permalink / raw)
To: Dan Carpenter
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, Fabian Henneke,
Brian Norris, Al Viro, Andrea Parri, linux-bluetooth, netdev,
linux-kernel
In-Reply-To: <20190906101306.GA12017@kadam>
On Fri, Sep 6, 2019 at 1:14 PM Dan Carpenter wrote:
> I think we also need to update update ms_ff_worker() which assumes that
> hid_hw_output_report() returns zero on success.
Yes, it looks like that's the case. Should I amend my patch to include
this fix, or should it be a separate patch? I don't have access to any
hardware covered by hid-microsoft, so I won't be able to test it.
> Please use the Fixes
> tag for this since a lot of scripts rely on it to decide what to
> backport.
>
> Fixes: 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return number of queued bytes")
Will do.
> Otherwise, it looks good. Thanks for catching this.
Thanks for taking a look!
(Sorry for sending this twice, I'm not used to mailing lists and forgot
to reply to all.)
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_disconnect() not clear tp->fastopen_rsk sometimes
From: Eric Dumazet @ 2019-09-06 10:33 UTC (permalink / raw)
To: chunguo feng, Yuchung Cheng, Neal Cardwell
Cc: David Miller, Alexei Starovoitov, Daniel Borkmann, netdev,
Yonghong Song, LKML
In-Reply-To: <20190906093429.930-1-chunguo.feng@amlogic.com>
On Fri, Sep 6, 2019 at 11:34 AM chunguo feng <chunguo.feng@amlogic.com> wrote:
>
> From: fengchunguo <chunguo.feng@amlogic.com>
>
> This patch avoids fastopen_rsk not be cleared every times, then occur
> the below BUG_ON:
> tcp_v4_destroy_sock
> ->BUG_ON(tp->fastopen_rsk);
>
> When playback some videos from netwrok,used tcp_disconnect continually.
Wow, tcp_disconnect() being used by something else than syzkaller !
> kthread+0x114/0x140
> ret_from_fork+0x10/0x18
>
> Signed-off-by: fengchunguo <chunguo.feng@amlogic.com>
> ---
> net/ipv4/tcp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 61082065b26a..f5c354c0b24c 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2655,6 +2655,7 @@ int tcp_disconnect(struct sock *sk, int flags)
> /* Clean up fastopen related fields */
> tcp_free_fastopen_req(tp);
> inet->defer_connect = 0;
> + tp->fastopen_rsk = 0;
>
> WARN_ON(inet->inet_num && !icsk->icsk_bind_hash);
>
This seems suspicious to me.
Are we leaking a block of memory after your patch ?
If the block of memory has been freed, maybe clear the pointer at the
place the free happened ?
I am traveling to Lisbon for LPC, maybe Yuchung or Neal can take a look.
^ permalink raw reply
* Re: [PATCH iproute2-next] bpf: fix snprintf truncation warning
From: Andrea Claudi @ 2019-09-06 10:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Ahern, linux-netdev, David Ahern
In-Reply-To: <20190905085147.72772bba@hermes.lan>
On Thu, Sep 5, 2019 at 5:51 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Thu, 5 Sep 2019 13:44:55 +0200
> Andrea Claudi <aclaudi@redhat.com> wrote:
>
> > On Thu, Sep 5, 2019 at 12:15 AM David Ahern <dsahern@gmail.com> wrote:
> > >
> > > On 9/4/19 9:50 AM, Andrea Claudi wrote:
> > > > gcc v9.2.1 produces the following warning compiling iproute2:
> > > >
> > > > bpf.c: In function ‘bpf_get_work_dir’:
> > > > bpf.c:784:49: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
> > > > 784 | snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir), "%s/", mnt);
> > > > | ^
> > > > bpf.c:784:2: note: ‘snprintf’ output between 2 and 4097 bytes into a destination of size 4096
> > > > 784 | snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir), "%s/", mnt);
> > > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >
> > > > Fix it extending bpf_wrk_dir size by 1 byte for the extra "/" char.
> > > >
> > > > Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
> > > > ---
> > > > lib/bpf.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/lib/bpf.c b/lib/bpf.c
> > > > index 7d2a322ffbaec..95de7894a93ce 100644
> > > > --- a/lib/bpf.c
> > > > +++ b/lib/bpf.c
> > > > @@ -742,7 +742,7 @@ static int bpf_gen_hierarchy(const char *base)
> > > > static const char *bpf_get_work_dir(enum bpf_prog_type type)
> > > > {
> > > > static char bpf_tmp[PATH_MAX] = BPF_DIR_MNT;
> > > > - static char bpf_wrk_dir[PATH_MAX];
> > > > + static char bpf_wrk_dir[PATH_MAX + 1];
> > > > static const char *mnt;
> > > > static bool bpf_mnt_cached;
> > > > const char *mnt_env = getenv(BPF_ENV_MNT);
> > > >
> > >
> > > PATH_MAX is meant to be the max length for a filesystem path including
> > > the null terminator, so I think it would be better to change the
> > > snprintf to 'sizeof(bpf_wrk_dir) - 1'.
> >
> > With 'sizeof(bpf_wrk_dir) - 1' snprintf simply truncates at byte 4095
> > instead of byte 4096.
> > This means that bpf_wrk_dir can again be truncated before the final
> > "/", as it is by now.
> > Am I missing something?
> >
> > Trying your suggestion I have this slightly different warning message:
> >
> > bpf.c: In function ‘bpf_get_work_dir’:
> > bpf.c:784:52: warning: ‘/’ directive output may be truncated writing 1
> > byte into a region of size between 0 and 4095 [-Wformat-truncation=]
> > 784 | snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir) - 1, "%s/", mnt);
> > | ^
> > bpf.c:784:2: note: ‘snprintf’ output between 2 and 4097 bytes into a
> > destination of size 4095
> > 784 | snprintf(bpf_wrk_dir, sizeof(bpf_wrk_dir) - 1, "%s/", mnt);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Why not rework this to use asprintf and avoid having huge buffers on stack?
Thanks for the suggestion. There are a lot of similar usages in
lib/bpf.c, I'll send a v2 to rework them all.
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: Fix error checks in hidp_get/set_raw_report
From: Dan Carpenter @ 2019-09-06 10:13 UTC (permalink / raw)
To: Dan Elkouby
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, Fabian Henneke,
Brian Norris, Al Viro, Andrea Parri, linux-bluetooth, netdev,
linux-kernel
In-Reply-To: <20190906094158.8854-1-streetwalkermc@gmail.com>
On Fri, Sep 06, 2019 at 12:41:57PM +0300, Dan Elkouby wrote:
> Commit 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return
> number of queued bytes") changed hidp_send_message to return non-zero
> values on success, which some other bits did not expect. This caused
> spurious errors to be propagated through the stack, breaking some (all?)
> drivers, such as hid-sony for the Dualshock 4 in Bluetooth mode.
>
> Signed-off-by: Dan Elkouby <streetwalkermc@gmail.com>
I think we also need to update update ms_ff_worker() which assumes that
hid_hw_output_report() returns zero on success. Please use the Fixes
tag for this since a lot of scripts rely on it to decide what to
backport.
Fixes: 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return number of queued bytes")
Otherwise, it looks good. Thanks for catching this.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCHv3 net-next] ipmr: remove hard code cache_resolve_queue_len limit
From: Nikolay Aleksandrov @ 2019-09-06 10:08 UTC (permalink / raw)
To: Hangbin Liu, netdev
Cc: Phil Karn, Sukumar Gopalakrishnan, David S . Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Eric Dumazet
In-Reply-To: <20190906073601.10525-1-liuhangbin@gmail.com>
On 06/09/2019 10:36, Hangbin Liu wrote:
> This is a re-post of previous patch wrote by David Miller[1].
>
> Phil Karn reported[2] that on busy networks with lots of unresolved
> multicast routing entries, the creation of new multicast group routes
> can be extremely slow and unreliable.
>
> The reason is we hard-coded multicast route entries with unresolved source
> addresses(cache_resolve_queue_len) to 10. If some multicast route never
> resolves and the unresolved source addresses increased, there will
> be no ability to create new multicast route cache.
>
> To resolve this issue, we need either add a sysctl entry to make the
> cache_resolve_queue_len configurable, or just remove cache_resolve_queue_len
> limit directly, as we already have the socket receive queue limits of mrouted
> socket, pointed by David.
>
> From my side, I'd perfer to remove the cache_resolve_queue_len limit instead
> of creating two more(IPv4 and IPv6 version) sysctl entry.
>
> [1] https://lkml.org/lkml/2018/7/22/11
> [2] https://lkml.org/lkml/2018/7/21/343
>
> v3: instead of remove cache_resolve_queue_len totally, let's only remove
> the hard code limit when allocate the unresolved cache, as Eric Dumazet
> suggested, so we don't need to re-count it in other places.
>
> v2: hold the mfc_unres_lock while walking the unresolved list in
> queue_count(), as Nikolay Aleksandrov remind.
>
> Reported-by: Phil Karn <karn@ka9q.net>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> net/ipv4/ipmr.c | 4 ++--
> net/ipv6/ip6mr.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
Please CC all interested parties who have reviewed/commented on previous versions.
I'd also add a Suggested-by tag such as:
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks good to me, thanks!
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH 0/2] Revert and rework on the metadata accelreation
From: Jason Wang @ 2019-09-06 10:02 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: mst@redhat.com, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, aarcange@redhat.com,
jglisse@redhat.com, linux-mm@kvack.org
In-Reply-To: <20190905135907.GB6011@mellanox.com>
On 2019/9/5 下午9:59, Jason Gunthorpe wrote:
> On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote:
>> Hi:
>>
>> Per request from Michael and Jason, the metadata accelreation is
>> reverted in this version and rework in next version.
>>
>> Please review.
>>
>> Thanks
>>
>> Jason Wang (2):
>> Revert "vhost: access vq metadata through kernel virtual address"
>> vhost: re-introducing metadata acceleration through kernel virtual
>> address
> There are a bunch of patches in the queue already that will help
> vhost, and I a working on one for next cycle that will help alot more
> too.
I will check those patches, but if you can give me some pointers or
keywords it would be much appreciated.
>
> I think you should apply the revert this cycle and rebase the other
> patch for next..
>
> Jason
Yes, the plan is to revert in this release cycle.
Thanks
^ permalink raw reply
* Re: [PATCH net-next,v3 0/4] flow_offload: update mangle action representation
From: Edward Cree @ 2019-09-06 10:02 UTC (permalink / raw)
To: Pablo Neira Ayuso, netfilter-devel
Cc: davem, netdev, jakub.kicinski, jiri, saeedm, vishal, vladbu
In-Reply-To: <20190906000403.3701-1-pablo@netfilter.org>
On 06/09/2019 01:03, Pablo Neira Ayuso wrote:
> This patch updates the mangle action representation:
>
> Patch 1) Undo bitwise NOT operation on the mangle mask (coming from tc
> pedit userspace).
>
> Patch 2) mangle value &= mask from the front-end side.
>
> Patch 3) adjust offset, length and coalesce consecutive pedit keys into
> one single action.
>
> Patch 4) add support for payload mangling for netfilter.
>
> After this patchset:
>
> * Offset to payload does not need to be on the 32-bits boundaries anymore.
> This patchset adds front-end code to adjust the offset and length coming
> from the tc pedit representation, so drivers get an exact header field
> offset and length.
>
> * This new front-end code coalesces consecutive pedit actions into one
> single action, so drivers can mangle IPv6 and ethernet address fields
> in one go, instead once for each 32-bit word.
>
> On the driver side, diffstat -t shows that drivers code to deal with
> payload mangling gets simplified:
>
> INSERTED,DELETED,MODIFIED,FILENAME
> 46,116,0,drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c (-70 LOC)
> 12,28,0,drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h (-16 LOC)
> 26,54,0,drivers/net/ethernet/mellanox/mlx5/core/en_tc.c (-27 LOC)
> 89,111,0,drivers/net/ethernet/netronome/nfp/flower/action.c (-17 LOC)
>
> While, on the front-end side the balance is the following:
>
> 123,22,0,net/sched/cls_api.c (+101 LOC)
>
> Changes since v2:
>
> * Fix is_action_keys_supported() breakage in mlx5 reported by Vlad Buslov.
Still NAK for the same reasons as three versions ago (when it was called
"netfilter: payload mangling offload support"), you've never managed to
explain why this extra API complexity is useful. (Reducing LOC does not
mean you've reduced complexity.)
As Jakub said, 'We suffered through enough haphazard "updates"'. Please
can you fix the problems your previous API changes caused (I still haven't
had an answer about the flow block changes since sending you my driver code
two weeks ago) before trying to ram new ones through.
-Ed
^ permalink raw reply
* [PATCH net v2] bridge/mdb: remove wrong use of NLM_F_MULTI
From: Nicolas Dichtel @ 2019-09-06 9:47 UTC (permalink / raw)
To: davem; +Cc: roopa, netdev, bridge, Nicolas Dichtel, Nikolay Aleksandrov
NLM_F_MULTI must be used only when a NLMSG_DONE message is sent at the end.
In fact, NLMSG_DONE is sent only at the end of a dump.
Libraries like libnl will wait forever for NLMSG_DONE.
Fixes: 949f1e39a617 ("bridge: mdb: notify on router port add and del")
CC: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
v2:
add netdev and bridge ml :D
remove Satish Ashok <sashok@cumulusnetworks.com> (its mail bounces)
net/bridge/br_mdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index bf6acd34234d..63f9c08625f0 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -437,7 +437,7 @@ static int nlmsg_populate_rtr_fill(struct sk_buff *skb,
struct nlmsghdr *nlh;
struct nlattr *nest;
- nlh = nlmsg_put(skb, pid, seq, type, sizeof(*bpm), NLM_F_MULTI);
+ nlh = nlmsg_put(skb, pid, seq, type, sizeof(*bpm), 0);
if (!nlh)
return -EMSGSIZE;
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox