Re: [PATCH net-next] virtio-net: restrict build_skb() use to some arches
On Tue, Apr 20, 2021 at 01:01:44PM -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> build_skb() is supposed to be followed by
> skb_reserve(skb, NET_IP_ALIGN), so that IP headers are word-aligned.
> (Best practice is to reserve NET_IP_ALIGN+NET_SKB_PAD, but the NET_SKB_PAD
> part is only a performance optimization if tunnel encaps are added.)
>
> Unfortunately virtio_net has not provisioned this reserve.
> We can only use build_skb() for arches where NET_IP_ALIGN == 0
>
> We might refine this later, with enough testing.
>
> Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's
> sufficient tailroom")
> Signed-off-by: Eric Dumazet
> Reported-by: Guenter Roeck
> Cc: Xuan Zhuo
> Cc: Jason Wang
> Cc: "Michael S. Tsirkin"
> Cc: virtualizat...@lists.linux-foundation.org
Tested-by: Guenter Roeck
on alpha, sh4 (little endian).
Thanks!
Guenter
Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
On 4/20/21 9:31 AM, Eric Dumazet wrote: > On Tue, Apr 20, 2021 at 5:42 PM Guenter Roeck wrote: >> >> On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote: >>> On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck wrote: >>>> >>>> On 4/20/21 2:43 AM, Eric Dumazet wrote: >>> >>>>> >>>> >>>> Unfortunately that doesn't fix the problem for me. With this patch applied >>>> on top of next-20210419, I still get the same crash as before: >>>> >>>> udhcpc: sending discover^M >>>> Unable to handle kernel paging request at virtual address >>>> 0004^M >>>> udhcpc(169): Oops -1^M >>>> pc = [<0004>] ra = [] ps = Not >>>> tainted^M >>>> pc is at 0x4^M >>>> ra is at napi_gro_receive+0x68/0x150^M >>>> v0 = t0 = 0008 t1 = ^M >>>> t2 = t3 = 000e t4 = 0038^M >>>> t5 = t6 = fc2f298a t7 = fc0002c78000^M >>>> s0 = fc00010b3ca0 s1 = s2 = fc00011267e0^M >>>> s3 = s4 = fc00025f2008 s5 = fc2f2940^M >>>> s6 = fc00025f2040^M >>>> a0 = fc00025f2008 a1 = fc2f2940 a2 = fc0002ca000c^M >>>> a3 = fc0250d0 a4 = 000e0008 a5 = ^M >>>> t8 = fc00010b3c80 t9 = fc0002ca04cc t10= ^M >>>> t11= 04c0 pv = fcb8bc40 at = ^M >>>> gp = fc00010f9fb8 sp = df74db09^M >>>> Disabling lock debugging due to kernel taint^M >>>> Trace:^M >>>> [] napi_gro_receive+0x68/0x150^M >>>> [] receive_buf+0x50c/0x1b80^M >>>> [] virtnet_poll+0x1a8/0x5b0^M >>>> [] virtnet_poll+0x1dc/0x5b0^M >>>> [] __napi_poll+0x4c/0x270^M >>>> [] net_rx_action+0x130/0x2c0^M >>>> [] sch_direct_xmit+0x170/0x360^M >>>> [] __qdisc_run+0x160/0x6c0^M >>>> [] do_softirq+0xa4/0xd0^M >>>> [] __local_bh_enable_ip+0x114/0x120^M >>>> [] __dev_queue_xmit+0x484/0xa60^M >>>> [] packet_sendmsg+0xe7c/0x1ba0^M >>>> [] __sys_sendto+0xf8/0x170^M >>>> [] _raw_spin_unlock+0x18/0x30^M >>>> [] ehci_irq+0x2cc/0x5c0^M >>>> [] usb_hcd_irq+0x34/0x50^M >>>> [] move_addr_to_kernel+0x3c/0x60^M >>>> [] __sys_sendto+0xa4/0x170^M >>>> [] sys_sendto+0x24/0x40^M >>>> [] _raw_spin_lock+0x18/0x30^M >>>> [] _raw_spin_unlock+0x18/0x30^M >>>> [] clipper_enable_irq+0x98/0x100^M >>>> [] _raw_spin_unlock+0x18/0x30^M >>>> [] entSys+0xa4/0xc0^M >>> >>> OK, it would be nice if you could get line number from this stack trace. >>> >> >> Here you are: >> >> napi_gro_receive (net/core/dev.c:6196) >> receive_buf (drivers/net/virtio_net.c:1150) >> virtnet_poll (drivers/net/virtio_net.c:1414 drivers/net/virtio_net.c:1519) >> clipper_srm_device_interrupt (arch/alpha/kernel/sys_dp264.c:256) >> virtnet_poll (drivers/net/virtio_net.c:1413 drivers/net/virtio_net.c:1519) >> __napi_poll (net/core/dev.c:6962) >> net_rx_action (net/core/dev.c:7029 net/core/dev.c:7116) >> __qdisc_run (net/sched/sch_generic.c:376 net/sched/sch_generic.c:384) >> do_softirq (./include/asm-generic/softirq_stack.h:10 kernel/softirq.c:460 >> kernel/softirq.c:447) >> __local_bh_enable_ip (kernel/softirq.c:384) >> __dev_queue_xmit (./include/linux/bottom_half.h:32 >> ./include/linux/rcupdate.h:746 net/core/dev.c:4272) >> packet_sendmsg (net/packet/af_packet.c:3009 net/packet/af_packet.c:3034) >> __sys_sendto (net/socket.c:654 net/socket.c:674 net/socket.c:1977) >> __d_alloc (fs/dcache.c:1744) >> packet_create (net/packet/af_packet.c:1192 net/packet/af_packet.c:3296) >> move_addr_to_kernel (./include/linux/uaccess.h:192 net/socket.c:198 >> net/socket.c:192) >> __sys_sendto (net/socket.c:1968) >> sys_sendto (net/socket.c:1989 net/socket.c:1985) >> sys_bind (net/socket.c:1648 net/socket.c:1646) >> entSys (arch/alpha/kernel/entry.S:477) >> >> Guenter > > OK, I guess we are back to unaligned access, right ? > I guess sh arch should have failed as well ? > sh does indeed fail, with the same symptoms as before, but so far I was not able to track it down to a specific commit. The alpha failure is different, though. It is a NULL pointer access. Anyway, testing ... The patch b
Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote: > On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck wrote: > > > > On 4/20/21 2:43 AM, Eric Dumazet wrote: > > > > > > > > Unfortunately that doesn't fix the problem for me. With this patch applied > > on top of next-20210419, I still get the same crash as before: > > > > udhcpc: sending discover^M > > Unable to handle kernel paging request at virtual address 0004^M > > udhcpc(169): Oops -1^M > > pc = [<0004>] ra = [] ps = Not > > tainted^M > > pc is at 0x4^M > > ra is at napi_gro_receive+0x68/0x150^M > > v0 = t0 = 0008 t1 = ^M > > t2 = t3 = 000e t4 = 0038^M > > t5 = t6 = fc2f298a t7 = fc0002c78000^M > > s0 = fc00010b3ca0 s1 = s2 = fc00011267e0^M > > s3 = s4 = fc00025f2008 s5 = fc2f2940^M > > s6 = fc00025f2040^M > > a0 = fc00025f2008 a1 = fc2f2940 a2 = fc0002ca000c^M > > a3 = fc0250d0 a4 = 000e0008 a5 = ^M > > t8 = fc00010b3c80 t9 = fc0002ca04cc t10= ^M > > t11= 04c0 pv = fcb8bc40 at = ^M > > gp = fc00010f9fb8 sp = df74db09^M > > Disabling lock debugging due to kernel taint^M > > Trace:^M > > [] napi_gro_receive+0x68/0x150^M > > [] receive_buf+0x50c/0x1b80^M > > [] virtnet_poll+0x1a8/0x5b0^M > > [] virtnet_poll+0x1dc/0x5b0^M > > [] __napi_poll+0x4c/0x270^M > > [] net_rx_action+0x130/0x2c0^M > > [] sch_direct_xmit+0x170/0x360^M > > [] __qdisc_run+0x160/0x6c0^M > > [] do_softirq+0xa4/0xd0^M > > [] __local_bh_enable_ip+0x114/0x120^M > > [] __dev_queue_xmit+0x484/0xa60^M > > [] packet_sendmsg+0xe7c/0x1ba0^M > > [] __sys_sendto+0xf8/0x170^M > > [] _raw_spin_unlock+0x18/0x30^M > > [] ehci_irq+0x2cc/0x5c0^M > > [] usb_hcd_irq+0x34/0x50^M > > [] move_addr_to_kernel+0x3c/0x60^M > > [] __sys_sendto+0xa4/0x170^M > > [] sys_sendto+0x24/0x40^M > > [] _raw_spin_lock+0x18/0x30^M > > [] _raw_spin_unlock+0x18/0x30^M > > [] clipper_enable_irq+0x98/0x100^M > > [] _raw_spin_unlock+0x18/0x30^M > > [] entSys+0xa4/0xc0^M > > OK, it would be nice if you could get line number from this stack trace. > Here you are: napi_gro_receive (net/core/dev.c:6196) receive_buf (drivers/net/virtio_net.c:1150) virtnet_poll (drivers/net/virtio_net.c:1414 drivers/net/virtio_net.c:1519) clipper_srm_device_interrupt (arch/alpha/kernel/sys_dp264.c:256) virtnet_poll (drivers/net/virtio_net.c:1413 drivers/net/virtio_net.c:1519) __napi_poll (net/core/dev.c:6962) net_rx_action (net/core/dev.c:7029 net/core/dev.c:7116) __qdisc_run (net/sched/sch_generic.c:376 net/sched/sch_generic.c:384) do_softirq (./include/asm-generic/softirq_stack.h:10 kernel/softirq.c:460 kernel/softirq.c:447) __local_bh_enable_ip (kernel/softirq.c:384) __dev_queue_xmit (./include/linux/bottom_half.h:32 ./include/linux/rcupdate.h:746 net/core/dev.c:4272) packet_sendmsg (net/packet/af_packet.c:3009 net/packet/af_packet.c:3034) __sys_sendto (net/socket.c:654 net/socket.c:674 net/socket.c:1977) __d_alloc (fs/dcache.c:1744) packet_create (net/packet/af_packet.c:1192 net/packet/af_packet.c:3296) move_addr_to_kernel (./include/linux/uaccess.h:192 net/socket.c:198 net/socket.c:192) __sys_sendto (net/socket.c:1968) sys_sendto (net/socket.c:1989 net/socket.c:1985) sys_bind (net/socket.c:1648 net/socket.c:1646) entSys (arch/alpha/kernel/entry.S:477) Guenter
Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
On 4/20/21 2:43 AM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191
> [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70
> drivers/net/virtio_net.c:480
> Read of size 12 at addr 888014a5f800 by task systemd-udevd/8445
>
> CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted
> 5.12.0-rc8-next-20210419-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
> __kasan_report mm/kasan/report.c:419 [inline]
> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
> check_region_inline mm/kasan/generic.c:180 [inline]
> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186
> memcpy+0x20/0x60 mm/kasan/shadow.c:65
> memcpy include/linux/fortify-string.h:191 [inline]
> page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> receive_mergeable drivers/net/virtio_net.c:1009 [inline]
> receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119
> virtnet_receive drivers/net/virtio_net.c:1411 [inline]
> virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516
> __napi_poll+0xaf/0x440 net/core/dev.c:6962
> napi_poll net/core/dev.c:7029 [inline]
> net_rx_action+0x801/0xb40 net/core/dev.c:7116
> __do_softirq+0x29b/0x9fe kernel/softirq.c:559
> invoke_softirq kernel/softirq.c:433 [inline]
> __irq_exit_rcu+0x136/0x200 kernel/softirq.c:637
> irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
> common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
>
> Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's
> sufficient tailroom")
> Signed-off-by: Eric Dumazet
> Reported-by: syzbot
> Reported-by: Guenter Roeck
> Reported-by: Mat Martineau
> Cc: Xuan Zhuo
> Cc: Jason Wang
> Cc: "Michael S. Tsirkin"
> Cc: virtualizat...@lists.linux-foundation.org
> ---
> drivers/net/virtio_net.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index
> 8cd76037c72481200ea3e8429e9fdfec005dad85..2e28c04aa6351d2b4016f7d277ce104c4970069d
> 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -385,6 +385,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info
> *vi,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> unsigned int copy, hdr_len, hdr_padded_len;
> + struct page *page_to_free = NULL;
> int tailroom, shinfo_size;
> char *p, *hdr_p;
>
> @@ -445,7 +446,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info
> *vi,
> if (len)
> skb_add_rx_frag(skb, 0, page, offset, len, truesize);
> else
> - put_page(page);
> + page_to_free = page;
> goto ok;
> }
>
> @@ -479,6 +480,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info
> *vi,
> hdr = skb_vnet_hdr(skb);
> memcpy(hdr, hdr_p, hdr_len);
> }
> + if (page_to_free)
> + put_page(page_to_free);
>
> if (metasize) {
> __skb_pull(skb, metasize);
>
Unfortunately that doesn't fix the problem for me. With this patch applied
on top of next-20210419, I still get the same crash as before:
udhcpc: sending discover^M
Unable to handle kernel paging request at virtual address 0004^M
udhcpc(169): Oops -1^M
pc = [<0004>] ra = [] ps = Not tainted^M
pc is at 0x4^M
ra is at napi_gro_receive+0x68/0x150^M
v0 = t0 = 0008 t1 = ^M
t2 = t3 = 000e t4 = 0038^M
t5 = t6 = fc2f298a t7 = fc0002c78000^M
s0 = fc00010b3ca0 s1 = s2 = fc00011267e0^M
s3 = s4 = fc00025f2008 s5 = fc2f2940^M
s6 = fc00025f2040^M
a0 = fc00025f2008 a1 = fc2f2940 a2 = fc0002ca000c^M
a3 = fc0250d0 a4 = 000e0008 a5 = ^M
t8 = fc00010b3c80 t9 = fc0002ca04cc t10= ^M
t11= 04c0 pv = fcb8bc40 at = ^M
gp = fc00010f9fb8 sp = df74db09^M
Disabling lock debugging due to kernel taint^M
Trace:^M
[] napi_gro_receive+0x68/0x150^M
[] receive_buf+0x50c/0x1b80^M
[] virtnet_poll+0x1a8/0x5b0^M
[] virtnet_poll+0x1dc/0x5b0^M
[] __napi_poll+0x4c/0x270^M
[] net_rx_action+0x130/0x2c0^M
[
Re: [net-next, v2] virtio-net: page_to_skb() use build_skb when there's sufficient tailroom
On Wed, Apr 14, 2021 at 09:52:21AM +0800, Xuan Zhuo wrote: > In page_to_skb(), if we have enough tailroom to save skb_shared_info, we > can use build_skb to create skb directly. No need to alloc for > additional space. And it can save a 'frags slot', which is very friendly > to GRO. > > Here, if the payload of the received package is too small (less than > GOOD_COPY_LEN), we still choose to copy it directly to the space got by > napi_alloc_skb. So we can reuse these pages. > > Testing Machine: > The four queues of the network card are bound to the cpu1. > > Test command: > for ((i=0;i<5;++i)); do sockperf tp --ip 192.168.122.64 -m 1000 -t 150& > done > > The size of the udp package is 1000, so in the case of this patch, there > will always be enough tailroom to use build_skb. The sent udp packet > will be discarded because there is no port to receive it. The irqsoftd > of the machine is 100%, we observe the received quantity displayed by > sar -n DEV 1: > > no build_skb: 956864.00 rxpck/s > build_skb:1158465.00 rxpck/s > > Signed-off-by: Xuan Zhuo > Suggested-by: Jason Wang Booting qemu-system-alpha with virtio-net interface instantiated results in: udhcpc: sending discover Unable to handle kernel paging request at virtual address 0004 udhcpc(169): Oops -1 pc = [<0004>] ra = [] ps = Not tainted pc is at 0x4 ra is at napi_gro_receive+0x68/0x150 v0 = t0 = 0008 t1 = t2 = t3 = 000e t4 = 0038 t5 = t6 = fc2f220a t7 = fc0002cd s0 = fc00010b3ca0 s1 = s2 = fc00011267e0 s3 = s4 = fc00025f2008 s5 = fc2f21c0 s6 = fc00025f2040 a0 = fc00025f2008 a1 = fc2f21c0 a2 = fc0002cc800c a3 = fc0250d0 a4 = 000e0008 a5 = t8 = fc00010b3c80 t9 = fc0002cc84cc t10= t11= 04c0 pv = fcb8bc10 at = gp = fc00010f9fb8 sp = aefe3f8a Disabling lock debugging due to kernel taint Trace: [] napi_gro_receive+0x68/0x150 [] receive_buf+0x50c/0x1b80 [] virtnet_poll+0x1a8/0x5b0 [] virtnet_poll+0x1dc/0x5b0 [] __napi_poll+0x4c/0x270 [] net_rx_action+0x130/0x2c0 [] __qdisc_run+0x90/0x6c0 [] do_softirq+0xa4/0xd0 [] __local_bh_enable_ip+0x114/0x120 [] __dev_queue_xmit+0x484/0xa60 [] packet_sendmsg+0xe7c/0x1ba0 [] __sys_sendto+0xf8/0x170 [] __d_alloc+0x40/0x270 [] packet_create+0x17c/0x3c0 [] move_addr_to_kernel+0x3c/0x60 [] __sys_sendto+0xa4/0x170 [] sys_sendto+0x24/0x40 [] sys_bind+0x20/0x40 [] entSys+0xa4/0xc0 Bisect log attached. Guenter --- # bad: [50b8b1d699ac313c0a07a3c185ffb23aecab8abb] Add linux-next specific files for 20210419 # good: [bf05bf16c76bb44ab5156223e1e58e26dfe30a88] Linux 5.12-rc8 git bisect start 'HEAD' 'v5.12-rc8' # bad: [c4bb91fc07e59241cde97f913d7a2fbedc248f0d] Merge remote-tracking branch 'crypto/master' git bisect bad c4bb91fc07e59241cde97f913d7a2fbedc248f0d # good: [499f739ad70f2a58aac985dceb25ca7666da88be] Merge remote-tracking branch 'jc_docs/docs-next' git bisect good 499f739ad70f2a58aac985dceb25ca7666da88be # good: [17e1be342d46eb0b7c3df4c7e623493483080b63] bnxt_en: Treat health register value 0 as valid in bnxt_try_reover_fw(). git bisect good 17e1be342d46eb0b7c3df4c7e623493483080b63 # good: [cf6d6925625755029cdf4bb0d0028f0b6e713242] Merge remote-tracking branch 'rdma/for-next' git bisect good cf6d6925625755029cdf4bb0d0028f0b6e713242 # good: [fb8517f4fade44fa5e42e29ca4d6e4a7ed50b512] rtw88: 8822c: add CFO tracking git bisect good fb8517f4fade44fa5e42e29ca4d6e4a7ed50b512 # bad: [d168b61fb769d10306b6118ec7623d2911d45690] Merge remote-tracking branch 'gfs2/for-next' git bisect bad d168b61fb769d10306b6118ec7623d2911d45690 # bad: [ee3e875f10fca68fb7478c23c75b553e56da319c] net: enetc: increase TX ring size git bisect bad ee3e875f10fca68fb7478c23c75b553e56da319c # good: [4a51b0e8a0143b0e83d51d9c58c6416c3818a9f2] r8152: support PHY firmware for RTL8156 series git bisect good 4a51b0e8a0143b0e83d51d9c58c6416c3818a9f2 # bad: [03e481e88b194296defdff3600b2fcebb04bd6cf] Merge tag 'mlx5-updates-2021-04-16' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux git bisect bad 03e481e88b194296defdff3600b2fcebb04bd6cf # bad: [70c183759b2cece2f9ba82e63e38fa32bebc9db2] Merge branch 'gianfar-mq-polling' git bisect bad 70c183759b2cece2f9ba82e63e38fa32bebc9db2 # bad: [d8604b209e9b3762280b8321162f0f64219d51c9] dt-bindings: net: qcom,ipa: add firmware-name property git bisect bad d8604b209e9b3762280b8321162f0f64219d51c9 # good: [4ad29b1a484e0c58acfffdcd87172ed17f35c1dd] net: mvpp2: Add parsing support for different IPv4 IHL values git bisect good 4ad29b1a484e0c58acfffdcd87172ed17f35c1dd # good: [fa588eba632df14d296436995e6bbea0c146ae77] net: Add Qcom WWAN control driver git bisect good fa588eba632df14d296436995e6bbea0c146ae77 # bad: [fb32856b16ad9d5bcd75b7
Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
On 4/18/21 9:27 PM, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
[ ... ]
> drivers/watchdog/renesas_wdt.c| 2 +-
> 48 files changed, 131 insertions(+), 52 deletions(-)
>
[ ... ]
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index 5791198960e6..fdc534dc4024 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -197,7 +197,7 @@ static bool rwdt_blacklisted(struct device *dev)
> const struct soc_device_attribute *attr;
>
> attr = soc_device_match(rwdt_quirks_match);
> - if (attr && setup_max_cpus > (uintptr_t)attr->data) {
> + if (!IS_ERR(attr) && attr && setup_max_cpus > (uintptr_t)attr->data) {
This is wrong. We can not make the decision below without having access
to attr. The function may wrongly return false if soc_device_match()
returns an error.
Guenter
> dev_info(dev, "Watchdog blacklisted on %s %s\n", attr->soc_id,
>attr->revision);
> return true;
>
Re: [PATCH net] gro: ensure frag0 meets IP header alignment
On 4/13/21 5:41 AM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> After commit 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head")
> Guenter Roeck reported one failure in his tests using sh architecture.
>
> After much debugging, we have been able to spot silent unaligned accesses
> in inet_gro_receive()
>
> The issue at hand is that upper networking stacks assume their header
> is word-aligned. Low level drivers are supposed to reserve NET_IP_ALIGN
> bytes before the Ethernet header to make that happen.
>
> This patch hardens skb_gro_reset_offset() to not allow frag0 fast-path
> if the fragment is not properly aligned.
>
> Some arches like x86, arm64 and powerpc do not care and define NET_IP_ALIGN
> as 0, this extra check will be a NOP for them.
>
> Note that if frag0 is not used, GRO will call pskb_may_pull()
> as many times as needed to pull network and transport headers.
>
> Fixes: 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head")
> Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual
> address")
> Signed-off-by: Eric Dumazet
> Reported-by: Guenter Roeck
> Cc: Xuan Zhuo
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
Nice catch.
Tested-by: Guenter Roeck
and thanks a lot for tracking this down!
Guenter
> ---
> net/core/dev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index
> af8c1ea040b9364b076e2d72f04dc3de2d7e2f11..1f79b9aa9a3f2392fddd1401f95ad098b5e03204
> 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5924,7 +5924,8 @@ static void skb_gro_reset_offset(struct sk_buff *skb)
> NAPI_GRO_CB(skb)->frag0_len = 0;
>
> if (!skb_headlen(skb) && pinfo->nr_frags &&
> - !PageHighMem(skb_frag_page(frag0))) {
> + !PageHighMem(skb_frag_page(frag0)) &&
> + (!NET_IP_ALIGN || !(skb_frag_off(frag0) & 3))) {
> NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
> NAPI_GRO_CB(skb)->frag0_len = min_t(unsigned int,
> skb_frag_size(frag0),
>
Re: Linux 5.12-rc7
On 4/12/21 10:38 AM, Eric Dumazet wrote: [ ... ] > Yes, I think this is the real issue here. This smells like some memory > corruption. > > In my traces, packet is correctly received in AF_PACKET queue. > > I have checked the skb is well formed. > > But the user space seems to never call poll() and recvmsg() on this > af_packet socket. > After sprinkling the kernel with debug messages: 424 00:01:33.674181 sendto(6, "E\0\1H\0\0\0\0@\21y\246\0\0\0\0\377\377\377\377\0D\0C\00148\346\1\1\6\0\246\336\333\v\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0RT\0\ 424 00:01:33.693873 close(6) = 0 424 00:01:33.694652 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 424 00:01:33.695213 clock_gettime64(CLOCK_MONOTONIC, 0x7be18a18) = -1 EFAULT (Bad address) 424 00:01:33.695889 write(2, "udhcpc: clock_gettime(MONOTONIC) failed\n", 40) = -1 EFAULT (Bad address) 424 00:01:33.697311 exit_group(1) = ? 424 00:01:33.698346 +++ exited with 1 +++ I only see that after adding debug messages in the kernel, so I guess there must be a heisenbug somehere. Anyway, indeed, I see (another kernel debug message): __do_sys_clock_gettime: Returning -EFAULT on address 0x7bacc9a8 So udhcpc doesn't even try to read the reply because it crashes after sendto() when trying to read the current time. Unless I am missing something, that means that the problem happens somewhere on the send side. To make things even more interesting, it looks like the failing system call isn't always clock_gettime(). Guenter
Re: Linux 5.12-rc7
On 4/12/21 9:31 AM, Eric Dumazet wrote:
> On Mon, Apr 12, 2021 at 6:28 PM Linus Torvalds
> wrote:
>>
>> On Sun, Apr 11, 2021 at 10:14 PM Guenter Roeck wrote:
>>>
>>> Qemu test results:
>>> total: 460 pass: 459 fail: 1
>>> Failed tests:
>>> sh:rts7751r2dplus_defconfig:ata:net,virtio-net:rootfs
>>>
>>> The failure bisects to commit 0f6925b3e8da ("virtio_net: Do not pull
>>> payload in
>>> skb->head"). It is a spurious problem - the test passes roughly every other
>>> time. When the failure is seen, udhcpc fails to get an IP address and aborts
>>> with SIGTERM. So far I have only seen this with the "sh" architecture.
>>
>> Hmm. Let's add in some more of the people involved in that commit, and
>> also netdev.
>>
>> Nothing in there looks like it should have any interaction with
>> architecture, so that "it happens on sh" sounds odd, but maybe it's
>> some particular interaction with the qemu environment.
>
> Yes, maybe.
>
> I spent few hours on this, and suspect a buggy memcpy() implementation
> on SH, but this was not conclusive.
>
I replaced all memcpy() calls in skbuff.h with calls to
static inline void __my_memcpy(unsigned char *to, const unsigned char *from,
unsigned int len)
{
while (len--)
*to++ = *from++;
}
That made no difference, so unless you have some other memcpy() in mind that
seems to be unlikely.
> By pulling one extra byte, the problem goes away.
>
> Strange thing is that the udhcpc process does not go past sendto().
>
I have been trying to debug that one. Unfortunately gdb doesn't work with sh,
so I can't use it to debug the problem. I'll spend some more time on this today.
Thanks,
Guenter
Re: [PATCH net] virtio_net: Do not pull payload in skb->head
Hi Eric,
On Mon, Apr 12, 2021 at 07:53:43AM +0200, Eric Dumazet wrote:
> On Mon, Apr 12, 2021 at 7:48 AM Eric Dumazet wrote:
> >
>
> > give a verdict.
> >
> > Please post the whole strace output.
> >
> > Thanks.
>
> Also please add -tt option to strace so that we have an idea of time
> delays just in case.
>
The exact command as executed is:
strace -tt -o /tmp/STRACE -f -s 1000 udhcpc -n -q
Log is below. This is the complete log: nothing was truncated, neither
at the beginning nor at the end. The log ends with sendto().
Hope this helps,
Guenter
---
148 00:01:14.802467 execve("/sbin/udhcpc", ["udhcpc", "-n", "-q"], 0x7e10
/* 11 vars */) = 0
148 00:01:14.804496 set_tid_address(0x295faf94) = 148
148 00:01:14.805081 brk(NULL) = 0x4c
148 00:01:14.805495 brk(0x4c2000) = 0x4c2000
148 00:01:14.805998 mmap2(0x4c, 4096, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4c
148 00:01:14.806750 mprotect(0x295f8000, 4096, PROT_READ) = 0
148 00:01:14.807524 mprotect(0x4be000, 4096, PROT_READ) = 0
148 00:01:14.808169 getuid32()= 0
148 00:01:14.808670 open("/dev/null", O_RDWR|O_LARGEFILE) = 3
148 00:01:14.809415 close(3) = 0
148 00:01:14.809886 pipe([3, 0]) = 3
148 00:01:14.810373 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
148 00:01:14.810827 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
148 00:01:14.811274 fcntl64(3, F_GETFL) = 0 (flags O_RDONLY)
148 00:01:14.811703 fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
148 00:01:14.812156 fcntl64(4, F_GETFL) = 0x1 (flags O_WRONLY)
148 00:01:14.812602 fcntl64(4, F_SETFL, O_WRONLY|O_NONBLOCK|O_LARGEFILE) = 0
148 00:01:14.813088 rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 8) = 0
148 00:01:14.813648 rt_sigaction(SIGUSR1, {sa_handler=0x4328b0, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x295b6a2a}, {sa_handler=SIG_DFL,
sa_mask=[], sa_flags=0}, 8) = 0
148 00:01:14.814381 rt_sigaction(SIGUSR2, {sa_handler=0x4328b0, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x295b6a2a}, {sa_handler=SIG_DFL,
sa_mask=[], sa_flags=0}, 8) = 0
148 00:01:14.815106 rt_sigaction(SIGTERM, {sa_handler=0x4328b0, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x295b6a2a}, {sa_handler=SIG_DFL,
sa_mask=[], sa_flags=0}, 8) = 0
148 00:01:14.815910 socket(AF_INET, SOCK_RAW, IPPROTO_RAW) = 5
148 00:01:14.816484 ioctl(5, SIOCGIFINDEX, {ifr_name="eth0", }) = 0
148 00:01:14.817111 ioctl(5, SIOCGIFHWADDR, {ifr_name="eth0",
ifr_hwaddr={sa_family=ARPHRD_ETHER, sa_data=52:54:00:12:34:56}}) = 0
148 00:01:14.818042 close(5) = 0
148 00:01:14.818660 write(2, "udhcpc: started, v1.33.0\n", 25) = 25
148 00:01:14.819387 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=74,
tv_nsec=819590988}) = 0
148 00:01:14.820117 vfork(
149 00:01:14.820652 execve("/usr/share/udhcpc/default.script",
["/usr/share/udhcpc/default.script", "deconfig"], 0x295fbfb0 /* 12 vars */
148 00:01:14.821800 <... vfork resumed>) = 149
148 00:01:14.822606 wait4(149,
149 00:01:14.823007 <... execve resumed>) = 0
149 00:01:14.823559 set_tid_address(0x295faf94) = 149
149 00:01:14.824135 brk(NULL) = 0x4c
149 00:01:14.824568 brk(0x4c2000) = 0x4c2000
149 00:01:14.824983 mmap2(0x4c, 4096, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4c
149 00:01:14.825728 mprotect(0x295f8000, 4096, PROT_READ) = 0
149 00:01:14.826526 mprotect(0x4be000, 4096, PROT_READ) = 0
149 00:01:14.827180 getuid32()= 0
149 00:01:14.827748 getpid() = 149
149 00:01:14.828221 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x295ea000
149 00:01:14.828963 rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 8) = 0
149 00:01:14.829549 rt_sigaction(SIGCHLD, {sa_handler=0x4379f4,
sa_mask=~[RTMIN RT_1 RT_2], sa_flags=SA_RESTORER, sa_restorer=0x295b6a2a},
NULL, 8) = 0
149 00:01:14.830347 getppid() = 148
149 00:01:14.830837 uname({sysname="Linux", nodename="buildroot", ...}) = 0
149 00:01:14.831484 statx(AT_FDCWD, "/tmp", AT_STATX_SYNC_AS_STAT,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID,
stx_attributes=STATX_ATTR_MOUNT_ROOT, stx_mode=S_IFDIR|S_ISVTX|0777,
stx_size=140, ...}) = 0
149 00:01:14.832588 statx(AT_FDCWD, ".", AT_STATX_SYNC_AS_STAT,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID,
stx_attributes=STATX_ATTR_MOUNT_ROOT, stx_mode=S_IFDIR|S_ISVTX|0777,
stx_size=140, ...}) = 0
149 00:01:14.833685 open("/usr/share/udhcpc/default.script",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
149 00:01:14.834370 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
149 00:01:14.834866 fcntl64(3, F_DUPFD_CLOEXEC, 10) = 10
149 00:01:14.835292 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
149 00:01:14.835741 close(3) = 0
149 00:01:14.836188 rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL,
sa_mask=[], sa_flags=0}, 8) = 0
149 00:01:14.836753 rt_sigaction(SIGINT, {sa_handler=0x4379f4,
sa_mask=~[RTMIN RT_1 R
Re: [PATCH net] virtio_net: Do not pull payload in skb->head
On 4/11/21 2:43 PM, Eric Dumazet wrote:
> On Sun, Apr 11, 2021 at 11:32 PM Guenter Roeck wrote:
>>
>> On 4/11/21 2:23 PM, Eric Dumazet wrote:
>>> On Sun, Apr 11, 2021 at 10:37 PM Guenter Roeck wrote:
>>>>
>>>> On 4/11/21 8:06 AM, Eric Dumazet wrote:
>>>>> On Sun, Apr 11, 2021 at 3:43 PM Guenter Roeck wrote:
>>>>>
>>>>>> This patch causes a virtio-net interface failure when booting sh4 images
>>>>>> in qemu. The test case is nothing special: Just try to get an IP address
>>>>>> using udhcpc. If it fails, udhcpc reports:
>>>>>>
>>>>>> udhcpc: started, v1.33.0
>>>>>> udhcpc: sending discover
>>>>>> FAIL
>>>>>>
>>>>>
>>>>> Can you investigate where the incoming packet is dropped ?
>>>>>
>>>>
>>>> Unless I am missing something, packets are not dropped. It looks more
>>>> like udhcpc gets bad indigestion in the receive path and exits immediately.
>>>> Plus, it doesn't happen all the time; sometimes it receives the discover
>>>> response and is able to obtain an IP address.
>>>>
>>>> Overall this is quite puzzling since udhcpc exits immediately when the
>>>> problem
>>>> is seen, no matter which option I give it on the command line; it should
>>>> not
>>>> really do that.
>>>
>>>
>>> Could you strace both cases and report differences you can spot ?
>>>
>>> strace -o STRACE -f -s 1000 udhcpc
>>>
>>
>> I'll give it a try. It will take a while; I'll need to add strace to my root
>> file systems first.
>>
>> As a quick hack, I added some debugging into the kernel; it looks like
>> the data part of the dhcp discover response may get lost with your patch
>> in place.
>
> Data is not lost, the payload is whole contained in skb frags, which
> was expected from my patch.
>
> Maybe this sh arch does something wrong in this case.
>
> This could be checksuming...
>
> Please check
>
> nstat -n
>
> nstat
>
Does that tell you anything ?
/ # nstat -n
/ # udhcpc -n -q
udhcpc: started, v1.33.0
udhcpc: sending discover
/ # nstat
#kernel
IpInReceives1 0.0
IpInDelivers1 0.0
UdpIgnoredMulti 1 0.0
IpExtInBcastPkts1 0.0
IpExtInOctets 5760.0
IpExtInBcastOctets 5760.0
IpExtInNoECTPkts1 0.0
Also, one interesting detail is that the problem is not seen all the time,
even with your patch in place. Not sure if I mentioned that before. strace
output in the success case (same image, with patch in place) looks as follows.
130 write(2, "udhcpc: sending discover\n", 25) = 25
130 socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_IP)) = 6
130 bind(6, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_IP),
sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM,
sll_pkttype=PACKET_HOST, sll_halen=6, sll_addr=[0xff, 0xff, 0xff, 0xf
130 sendto(6,
"E\0\1H\0\0\0\0@\21y\246\0\0\0\0\377\377\377\377\0D\0C\0014\227r\1\1\6\0\5\16\36P\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0RT\0\0224V\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
130 close(6) = 0
130 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
130 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=25, tv_nsec=202168729}) = 0
130 poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}], 2, 3000) = 1
([{fd=5, revents=POLLIN}])
130 read(3, 0x7bf47a73, 1)= -1 EAGAIN (Resource temporarily
unavailable)
130 recvmsg(5, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="E\20\2@\0\10\0\0@\21l\224\n\0\2\2\377\377\377\377\0C\0D\2,\230\23\2\1\6\0\5\16\36P\0\0\0\0\0\0\0\0\n\0\2\17\n\0\2\2\0\0\0\0RT\0\0
130 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=25, tv_nsec=205504062}) = 0
130 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
130 socket(AF_INET, SOCK_RAW, IPPROTO_RAW) = 6
130 ioctl(6, SIOCGIFINDEX, {ifr_name="eth0", }) = 0
130 ioctl(6, SIOCGIFHWADDR, {ifr_name="eth0",
ifr_hwaddr={sa_family=ARPHRD_ETHER, sa_data=52:54:00:12:34:56}}) = 0
130 close(6) = 0
130 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=25, tv_nsec=208676862}) = 0
130 write(2, "udhcpc: sending select for 10.0.2.15\n", 37) = 37
130 socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_IP)) = 6
130 bind(6, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_IP),
sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM,
sll_pkttype=PACKET_HOST, sll_
Re: [PATCH net] virtio_net: Do not pull payload in skb->head
On 4/11/21 2:43 PM, Eric Dumazet wrote:
> On Sun, Apr 11, 2021 at 11:32 PM Guenter Roeck wrote:
>>
>> On 4/11/21 2:23 PM, Eric Dumazet wrote:
>>> On Sun, Apr 11, 2021 at 10:37 PM Guenter Roeck wrote:
>>>>
>>>> On 4/11/21 8:06 AM, Eric Dumazet wrote:
>>>>> On Sun, Apr 11, 2021 at 3:43 PM Guenter Roeck wrote:
>>>>>
>>>>>> This patch causes a virtio-net interface failure when booting sh4 images
>>>>>> in qemu. The test case is nothing special: Just try to get an IP address
>>>>>> using udhcpc. If it fails, udhcpc reports:
>>>>>>
>>>>>> udhcpc: started, v1.33.0
>>>>>> udhcpc: sending discover
>>>>>> FAIL
>>>>>>
>>>>>
>>>>> Can you investigate where the incoming packet is dropped ?
>>>>>
>>>>
>>>> Unless I am missing something, packets are not dropped. It looks more
>>>> like udhcpc gets bad indigestion in the receive path and exits immediately.
>>>> Plus, it doesn't happen all the time; sometimes it receives the discover
>>>> response and is able to obtain an IP address.
>>>>
>>>> Overall this is quite puzzling since udhcpc exits immediately when the
>>>> problem
>>>> is seen, no matter which option I give it on the command line; it should
>>>> not
>>>> really do that.
>>>
>>>
>>> Could you strace both cases and report differences you can spot ?
>>>
>>> strace -o STRACE -f -s 1000 udhcpc
>>>
>>
>> I'll give it a try. It will take a while; I'll need to add strace to my root
>> file systems first.
>>
>> As a quick hack, I added some debugging into the kernel; it looks like
>> the data part of the dhcp discover response may get lost with your patch
>> in place.
>
> Data is not lost, the payload is whole contained in skb frags, which
> was expected from my patch.
>
> Maybe this sh arch does something wrong in this case.
>
> This could be checksuming...
>
> Please check
>
> nstat -n
>
> nstat
>
Another tool to install.
While that builds, output from strace:
# strace -o /tmp/STRACE -f -s 1000 udhcpc -n -q
udhcpc: started, v1.33.0
udhcpc: sending discover
udhcpc: received SIGTERM
and:
...
136 socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_IP)) = 5
136 bind(5, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_IP),
sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM,
sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
136 setsockopt(5, SOL_PACKET, PACKET_AUXDATA, [1], 4) = 0
136 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
136 socket(AF_INET, SOCK_RAW, IPPROTO_RAW) = 6
136 ioctl(6, SIOCGIFINDEX, {ifr_name="eth0", }) = 0
136 ioctl(6, SIOCGIFHWADDR, {ifr_name="eth0",
ifr_hwaddr={sa_family=ARPHRD_ETHER, sa_data=52:54:00:12:34:56}}) = 0
136 close(6) = 0
136 clock_gettime64(CLOCK_MONOTONIC, {tv_sec=161, tv_nsec=2180242}) = 0
136 write(2, "udhcpc: sending discover\n", 25) = 25
136 socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_IP)) = 6
136 bind(6, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_IP),
sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM,
sll_pkttype=PACKET_HOST, sll_halen=6, sll_addr=[0xff, 0xff, 0xff, 0xff, 0xff,
0xff]}, 20) = 0
136 sendto(6,
"E\0\1H\0\0\0\0@\21y\246\0\0\0\0\377\377\377\377\0D\0C\0014\200\256\1\1\6\0\257\321\212P\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0RT\0\0224V\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0c\202Sc5\1\1=\7\1RT\0\0224V9\2\2@7\7\1\3\6\f\17\34*<\fudhcp
1.33.0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 328, 0,
{sa_family=AF_PACKET, sll_protocol=htons(ETH_P_IP),
sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM,
sll_pkttype=PACKET_HOST, sll_halen=6, sll_addr=[0xff, 0xff, 0xff, 0xff, 0xff,
0xff]}, 20
Guenter
Re: [PATCH net] virtio_net: Do not pull payload in skb->head
On 4/11/21 2:23 PM, Eric Dumazet wrote:
> On Sun, Apr 11, 2021 at 10:37 PM Guenter Roeck wrote:
>>
>> On 4/11/21 8:06 AM, Eric Dumazet wrote:
>>> On Sun, Apr 11, 2021 at 3:43 PM Guenter Roeck wrote:
>>>
>>>> This patch causes a virtio-net interface failure when booting sh4 images
>>>> in qemu. The test case is nothing special: Just try to get an IP address
>>>> using udhcpc. If it fails, udhcpc reports:
>>>>
>>>> udhcpc: started, v1.33.0
>>>> udhcpc: sending discover
>>>> FAIL
>>>>
>>>
>>> Can you investigate where the incoming packet is dropped ?
>>>
>>
>> Unless I am missing something, packets are not dropped. It looks more
>> like udhcpc gets bad indigestion in the receive path and exits immediately.
>> Plus, it doesn't happen all the time; sometimes it receives the discover
>> response and is able to obtain an IP address.
>>
>> Overall this is quite puzzling since udhcpc exits immediately when the
>> problem
>> is seen, no matter which option I give it on the command line; it should not
>> really do that.
>
>
> Could you strace both cases and report differences you can spot ?
>
> strace -o STRACE -f -s 1000 udhcpc
>
I'll give it a try. It will take a while; I'll need to add strace to my root
file systems first.
As a quick hack, I added some debugging into the kernel; it looks like
the data part of the dhcp discover response may get lost with your patch
in place.
dhcp discover response with patch in place (bad):
virtio_net virtio0 eth0: __udp4_lib_rcv: data 0x8ca4cc44 head 0x8ca4cc00 tail
0x8ca4cc4c len 556 datalen 548 caller ip_protocol_deliver_rcu+0xac/0x178
: 70 c1 a9 8c 00 00 00 00 00 00 00 00 20 ee c3 7b 34 00 e0 7b 08 00 00
00 00 00 00 00 00 00 00 00 p... ..{4..{
0020: 60 c8 ff ff ff ff ff ff 52 55 0a 00 02 02 08 00 45 10 02 40 00 00 00
00 40 11 6c 9c 0a 00 02 02 `...RU..E..@@.l.
0040: ff ff ff ff 00 43 00 44 02 2c e1 21 00 00 00 00 f0 6f a4 7b 00 00 80
00 ff ff ff ff 7f 45 4c 46 .C.D.,.!.o.{.ELF
^^ udp header
^ UDP length (556)
^^ start of UDP data (dhcp
discover reply)
0060: 01 01 01 00 00 00 00 00 00 00 00 00 02 00 2a 00 01 00 00 00 b0 6e 40
00 34 00 00 00 2c f6 0a 00 ..*..n@.4...,...
0080: 17 00 00 00 34 00 20 00 08 00 28 00 16 00 15 00 06 00 00 00 34 00 00
00 34 00 40 00 34 00 40 00 4. ...(.4...4.@.4.@.
00a0: 00 01 00 00 00 01 00 00 04 00 00 00 04 00 00 00 03 00 00 00 34 01 00
00 34 01 40 00 34 01 40 00 4...4.@.4.@.
00c0: 15 00 00 00 15 00 00 00 04 00 00 00 01 00 00 00 01 00 00 00 00 00 00
00 00 00 40 00 00 00 40 00 ..@...@.
00e0: 1c e2 0a 00 1c e2 0a 00 05 00 00 00 00 00 01 00 01 00 00 00 38 ef 0a
00 38 ef 4b 00 38 ef 4b 00 8...8.K.8.K.
0100: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 01 00 00 00
0120: b8 00 00 00 00 4c f9 8f 24 02 00 00 36 00 00 00 50 e5 74 64 88 e0 0a
00 88 e0 4a 00 88 e0 4a 00 .L..$...6...P.td..J...J.
0140: 2c 00 00 00 2c 00 00 00 04 00 00 00 04 00 00 00 51 e5 74 64 00 00 00
00 00 00 00 00 00 00 00 00 ,...,...Q.td
0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
0200: 1c 63 5a 8c 00 3e a4 8c 88 f9 50 8c 0c ce a4 8c 0c ce a4 8c 24 81 a1
8c 00 00 00 00 1c 5c 5a 8c .cZ..>P.$\Z.
0220: 04 b8 a5 8c 01 00 00 00 03 00 00 00
dhcp discover response with patch reverted (ok):
virtio_net virtio0 eth0: __udp4_lib_rcv: data 0x8ca4ca44 head 0x8ca4ca00 tail
0x8ca4cb00 len 556 datalen 368 caller ip_protocol_deliver_rcu+0xac/0x178
^^
^^ ^^^
: 4c bd ab 8c 00 00 00 00 00 00 00 00 20 2e 85 7b 34 00 e0 7b 08 00 00
00 00 00 00 00 00 00 00 00 L... ..{4..{.
Re: [PATCH net] virtio_net: Do not pull payload in skb->head
On 4/11/21 8:06 AM, Eric Dumazet wrote: > On Sun, Apr 11, 2021 at 3:43 PM Guenter Roeck wrote: > >> This patch causes a virtio-net interface failure when booting sh4 images >> in qemu. The test case is nothing special: Just try to get an IP address >> using udhcpc. If it fails, udhcpc reports: >> >> udhcpc: started, v1.33.0 >> udhcpc: sending discover >> FAIL >> > > Can you investigate where the incoming packet is dropped ? > Unless I am missing something, packets are not dropped. It looks more like udhcpc gets bad indigestion in the receive path and exits immediately. Plus, it doesn't happen all the time; sometimes it receives the discover response and is able to obtain an IP address. Overall this is quite puzzling since udhcpc exits immediately when the problem is seen, no matter which option I give it on the command line; it should not really do that. Guenter
Re: [PATCH net] virtio_net: Do not pull payload in skb->head
Hi,
On Fri, Apr 02, 2021 at 06:26:02AM -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Xuan Zhuo reported that commit 3226b158e67c ("net: avoid 32 x truesize
> under-estimation for tiny skbs") brought a ~10% performance drop.
>
> The reason for the performance drop was that GRO was forced
> to chain sk_buff (using skb_shinfo(skb)->frag_list), which
> uses more memory but also cause packet consumers to go over
> a lot of overhead handling all the tiny skbs.
>
> It turns out that virtio_net page_to_skb() has a wrong strategy :
> It allocates skbs with GOOD_COPY_LEN (128) bytes in skb->head, then
> copies 128 bytes from the page, before feeding the packet to GRO stack.
>
> This was suboptimal before commit 3226b158e67c ("net: avoid 32 x truesize
> under-estimation for tiny skbs") because GRO was using 2 frags per MSS,
> meaning we were not packing MSS with 100% efficiency.
>
> Fix is to pull only the ethernet header in page_to_skb()
>
> Then, we change virtio_net_hdr_to_skb() to pull the missing
> headers, instead of assuming they were already pulled by callers.
>
> This fixes the performance regression, but could also allow virtio_net
> to accept packets with more than 128bytes of headers.
>
> Many thanks to Xuan Zhuo for his report, and his tests/help.
>
> Fixes: 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny
> skbs")
> Reported-by: Xuan Zhuo
> Link: https://www.spinics.net/lists/netdev/msg731397.html
> Co-Developed-by: Xuan Zhuo
> Signed-off-by: Xuan Zhuo
> Signed-off-by: Eric Dumazet
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: virtualizat...@lists.linux-foundation.org
This patch causes a virtio-net interface failure when booting sh4 images
in qemu. The test case is nothing special: Just try to get an IP address
using udhcpc. If it fails, udhcpc reports:
udhcpc: started, v1.33.0
udhcpc: sending discover
FAIL
After the failure, ifconfig shows no error:
eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:590 (590.0 B) TX bytes:342 (342.0 B)
This happens with almost every boot. The problem disappears after reverting
this patch.
Guenter
---
bisect log:
# bad: [52e44129fba5cfc4e351fdb5e45849afc74d9a53] Merge branch 'for-5.12-fixes'
of git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu
# good: [f40ddce88593482919761f74910f42f4b84c004b] Linux 5.11
git bisect start 'HEAD' 'v5.11'
# good: [d99676af540c2dc82928fb81c58c80a1dce4] Merge tag
'drm-next-2021-02-19' of git://anongit.freedesktop.org/drm/drm
git bisect good d99676af540c2dc82928fb81c58c80a1dce4
# good: [c4fbde84fedeaf513ec96f0c6ed3f352bdcd61d6] Merge tag
'sfi-removal-5.12-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect good c4fbde84fedeaf513ec96f0c6ed3f352bdcd61d6
# good: [b1dd9bf688b0dcc5a34dca660de46c7570bd9243] net: phy: broadcom: Fix
RGMII delays for BCM50160 and BCM50610M
git bisect good b1dd9bf688b0dcc5a34dca660de46c7570bd9243
# good: [e138138003eb3b3d06cc91cf2e8c5dec77e2a31e] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
git bisect good e138138003eb3b3d06cc91cf2e8c5dec77e2a31e
# good: [dbaa5d1c254e1b565caee9ac7b526a9b7267d4c4] Merge branch 'parisc-5.12-3'
of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
git bisect good dbaa5d1c254e1b565caee9ac7b526a9b7267d4c4
# bad: [1ffbc7ea91606e4abd10eb60de5367f1c86daf5e] net: sched: sch_teql: fix
null-pointer dereference
git bisect bad 1ffbc7ea91606e4abd10eb60de5367f1c86daf5e
# good: [9256ce33110174decc04caf6ef733409012e5b1c] Merge branch '40GbE' of
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
git bisect good 9256ce33110174decc04caf6ef733409012e5b1c
# bad: [3cf1482852825bdf8cc4e4f09346262c80ad5cbe] Merge branch
'ethtool-link_mode'
git bisect bad 3cf1482852825bdf8cc4e4f09346262c80ad5cbe
# bad: [0f6925b3e8da0dbbb52447ca8a8b42b371aac7db] virtio_net: Do not pull
payload in skb->head
git bisect bad 0f6925b3e8da0dbbb52447ca8a8b42b371aac7db
# good: [6dcc4e38386950abf9060784631622dfc4df9577] Merge branch 'AF_XDP Socket
Creation Fixes'
git bisect good 6dcc4e38386950abf9060784631622dfc4df9577
# good: [630e4576f83accf90366686f39808d665d8dbecc] net-ipv6: bugfix - raw &
sctp - switch to ipv6_can_nonlocal_bind()
git bisect good 630e4576f83accf90366686f39808d665d8dbecc
# good: [22f69de18ee86e81dc41253869e5dd963ccea429] Merge branch 'hns3-fixes'
git bisect good 22f69de18ee86e81dc41253869e5dd963ccea429
# good: [b25b343db0526669947a427e9a31bac91d29bb06] net: broadcom: bcm4908enet:
Fix a double free in bcm4908_enet_dma_alloc
git bisect good b25b343db0526669947a427e9a31bac91d29bb06
# first bad commit: [0f6925b3e8da0dbbb52447ca8a8b42b371aac7db] virtio_net: Do
not pull payload in skb->head
---
qemu command line:
qemu-sys
Re: [PATCH v3 08/15] arm64: socfpga: merge Agilex and N5X into ARCH_INTEL_SOCFPGA
On Thu, Mar 11, 2021 at 04:25:38PM +0100, Krzysztof Kozlowski wrote: > Agilex, N5X and Stratix 10 share all quite similar arm64 hard cores and > SoC-part. Up to a point that N5X uses the same DTSI as Agilex. From > the Linux kernel point of view these are flavors of the same > architecture so there is no need for three top-level arm64 > architectures. Simplify this by merging all three architectures into > ARCH_INTEL_SOCFPGA and dropping the other ARCH* arm64 Kconfig entries. > > The side effect is that the INTEL_STRATIX10_SERVICE will now be > available for both 32-bit and 64-bit Intel SoCFPGA, even though it is > used only for 64-bit. Did you try to compile, say, arm:allmodconfig with this patch applied ? Because for me that results in: In file included from : drivers/firmware/stratix10-rsu.c: In function 'rsu_status_callback': include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_177' declared with attribute error: FIELD_GET: type of reg too small for mask and lots of similar errors. Guenter > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm64/Kconfig.platforms | 21 - > arch/arm64/boot/dts/intel/Makefile | 6 +++--- > arch/arm64/configs/defconfig | 3 +-- > drivers/clk/Makefile | 2 -- > drivers/clk/socfpga/Kconfig| 4 ++-- > drivers/firmware/Kconfig | 2 +- > drivers/fpga/Kconfig | 2 +- > drivers/reset/Kconfig | 2 +- > 8 files changed, 13 insertions(+), 29 deletions(-) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index ecab67a1afb8..ce50dd129eec 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -8,16 +8,6 @@ config ARCH_ACTIONS > help > This enables support for the Actions Semiconductor S900 SoC family. > > -config ARCH_AGILEX > - bool "Intel's Agilex SoCFPGA Family" > - help > - This enables support for Intel's Agilex SoCFPGA Family. > - > -config ARCH_N5X > - bool "Intel's eASIC N5X SoCFPGA Family" > - help > - This enables support for Intel's eASIC N5X SoCFPGA Family. > - > config ARCH_SUNXI > bool "Allwinner sunxi 64-bit SoC Family" > select ARCH_HAS_RESET_CONTROLLER > @@ -254,14 +244,11 @@ config ARCH_SEATTLE > help > This enables support for AMD Seattle SOC Family > > -config ARCH_STRATIX10 > - bool "Altera's Stratix 10 SoCFPGA Family" > - select ARCH_INTEL_SOCFPGA > - help > - This enables support for Altera's Stratix 10 SoCFPGA Family. > - > config ARCH_INTEL_SOCFPGA > - bool > + bool "Intel's SoCFPGA ARMv8 Families" > + help > + This enables support for Intel's SoCFPGA ARMv8 families: > + Stratix 10 (ex. Altera), Agilex and eASIC N5X. > > config ARCH_SYNQUACER > bool "Socionext SynQuacer SoC Family" > diff --git a/arch/arm64/boot/dts/intel/Makefile > b/arch/arm64/boot/dts/intel/Makefile > index 3a052540605b..0b5477442263 100644 > --- a/arch/arm64/boot/dts/intel/Makefile > +++ b/arch/arm64/boot/dts/intel/Makefile > @@ -1,5 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0-only > -dtb-$(CONFIG_ARCH_AGILEX) += socfpga_agilex_socdk.dtb \ > - socfpga_agilex_socdk_nand.dtb > +dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_socdk.dtb \ > + socfpga_agilex_socdk_nand.dtb \ > + socfpga_n5x_socdk.dtb > dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb > -dtb-$(CONFIG_ARCH_N5X) += socfpga_n5x_socdk.dtb > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index d612f633b771..cf8a3009b858 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -28,7 +28,6 @@ CONFIG_KALLSYMS_ALL=y > # CONFIG_COMPAT_BRK is not set > CONFIG_PROFILING=y > CONFIG_ARCH_ACTIONS=y > -CONFIG_ARCH_AGILEX=y > CONFIG_ARCH_SUNXI=y > CONFIG_ARCH_ALPINE=y > CONFIG_ARCH_BCM2835=y > @@ -50,7 +49,7 @@ CONFIG_ARCH_RENESAS=y > CONFIG_ARCH_ROCKCHIP=y > CONFIG_ARCH_S32=y > CONFIG_ARCH_SEATTLE=y > -CONFIG_ARCH_STRATIX10=y > +CONFIG_ARCH_INTEL_SOCFPGA=y > CONFIG_ARCH_SYNQUACER=y > CONFIG_ARCH_TEGRA=y > CONFIG_ARCH_SPRD=y > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile > index 1e29e5ad107a..96802294d35a 100644 > --- a/drivers/clk/Makefile > +++ b/drivers/clk/Makefile > @@ -105,8 +105,6 @@ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ > obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/ > obj-$(CONFIG_CLK_SIFIVE) += sifive/ > obj-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga/ > -obj-$(CONFIG_ARCH_AGILEX)+= socfpga/ > -obj-$(CONFIG_ARCH_N5X) += socfpga/ > obj-$(CONFIG_PLAT_SPEAR) += spear/ > obj-y+= sprd/ > obj-$(CONFIG_ARCH_STI) += st/ > diff --git a/drivers/clk/socfpga/Kconfig b/drivers/clk/socfpga/Kconfig > index bc102e0f
[PATCH] pcnet32: Use pci_resource_len to validate PCI resource
pci_resource_start() is not a good indicator to determine if a PCI
resource exists or not, since the resource may start at address 0.
This is seen when trying to instantiate the driver in qemu for riscv32
or riscv64.
pci :00:01.0: reg 0x10: [io 0x-0x001f]
pci :00:01.0: reg 0x14: [mem 0x-0x001f]
...
pcnet32: card has no PCI IO resources, aborting
Use pci_resouce_len() instead.
Signed-off-by: Guenter Roeck
---
drivers/net/ethernet/amd/pcnet32.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet/amd/pcnet32.c
index 187b0b9a6e1d..f78daba60b35 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -1534,8 +1534,7 @@ pcnet32_probe_pci(struct pci_dev *pdev, const struct
pci_device_id *ent)
}
pci_set_master(pdev);
- ioaddr = pci_resource_start(pdev, 0);
- if (!ioaddr) {
+ if (!pci_resource_len(pdev, 0)) {
if (pcnet32_debug & NETIF_MSG_PROBE)
pr_err("card has no PCI IO resources, aborting\n");
err = -ENODEV;
@@ -1548,6 +1547,8 @@ pcnet32_probe_pci(struct pci_dev *pdev, const struct
pci_device_id *ent)
pr_err("architecture does not support 32bit PCI
busmaster DMA\n");
goto err_disable_dev;
}
+
+ ioaddr = pci_resource_start(pdev, 0);
if (!request_region(ioaddr, PCNET32_TOTAL_SIZE, "pcnet32_probe_pci")) {
if (pcnet32_debug & NETIF_MSG_PROBE)
pr_err("io address range already allocated\n");
--
2.17.1
Re: [PATCH] ptp_qoriq: fix overflow in ptp_qoriq_adjfine() u64 calcalation
On Thu, Mar 25, 2021 at 03:23:07AM -0700, Guenter Roeck wrote: > On Tue, Mar 23, 2021 at 04:02:29PM +0800, Yangbo Lu wrote: > > Current calculation for diff of TMR_ADD register value may have > > 64-bit overflow in this code line, when long type scaled_ppm is > > large. > > > > adj *= scaled_ppm; > > > > This patch is to resolve it by using mul_u64_u64_div_u64(). > > > > Signed-off-by: Yangbo Lu > > Acked-by: Richard Cochran > > --- > > drivers/ptp/ptp_qoriq.c | 13 +++-- > > 1 file changed, 7 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/ptp/ptp_qoriq.c b/drivers/ptp/ptp_qoriq.c > > index 68beb1bd07c0..f7f220700cb5 100644 > > --- a/drivers/ptp/ptp_qoriq.c > > +++ b/drivers/ptp/ptp_qoriq.c > > @@ -189,15 +189,16 @@ int ptp_qoriq_adjfine(struct ptp_clock_info *ptp, > > long scaled_ppm) > > tmr_add = ptp_qoriq->tmr_add; > > adj = tmr_add; > > > > - /* calculate diff as adj*(scaled_ppm/65536)/100 > > -* and round() to the nearest integer > > + /* > > +* Calculate diff and round() to the nearest integer > > +* > > +* diff = adj * (ppb / 10) > > +* = adj * scaled_ppm / 6553600 > > */ > > - adj *= scaled_ppm; > > - diff = div_u64(adj, 800); > > - diff = (diff >> 13) + ((diff >> 12) & 1); > > + diff = mul_u64_u64_div_u64(adj, scaled_ppm, 3276800); > > mul_u64_u64_div_u64() is not exported. As result, every build with > CONFIG_PTP_1588_CLOCK_QORIQ=m (ie every allmodconfig build) fails with: > > ERROR: modpost: "mul_u64_u64_div_u64" [drivers/ptp/ptp-qoriq.ko] undefined! > > or a similar error. > Ah, never mind. I see this is fixed in mainline (export added). I see the problem in pending-fixes and in next-20210325. Sorry for the noise. Guenter
Re: [PATCH] ptp_qoriq: fix overflow in ptp_qoriq_adjfine() u64 calcalation
On Tue, Mar 23, 2021 at 04:02:29PM +0800, Yangbo Lu wrote: > Current calculation for diff of TMR_ADD register value may have > 64-bit overflow in this code line, when long type scaled_ppm is > large. > > adj *= scaled_ppm; > > This patch is to resolve it by using mul_u64_u64_div_u64(). > > Signed-off-by: Yangbo Lu > Acked-by: Richard Cochran > --- > drivers/ptp/ptp_qoriq.c | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/ptp/ptp_qoriq.c b/drivers/ptp/ptp_qoriq.c > index 68beb1bd07c0..f7f220700cb5 100644 > --- a/drivers/ptp/ptp_qoriq.c > +++ b/drivers/ptp/ptp_qoriq.c > @@ -189,15 +189,16 @@ int ptp_qoriq_adjfine(struct ptp_clock_info *ptp, long > scaled_ppm) > tmr_add = ptp_qoriq->tmr_add; > adj = tmr_add; > > - /* calculate diff as adj*(scaled_ppm/65536)/100 > - * and round() to the nearest integer > + /* > + * Calculate diff and round() to the nearest integer > + * > + * diff = adj * (ppb / 10) > + * = adj * scaled_ppm / 6553600 >*/ > - adj *= scaled_ppm; > - diff = div_u64(adj, 800); > - diff = (diff >> 13) + ((diff >> 12) & 1); > + diff = mul_u64_u64_div_u64(adj, scaled_ppm, 3276800); mul_u64_u64_div_u64() is not exported. As result, every build with CONFIG_PTP_1588_CLOCK_QORIQ=m (ie every allmodconfig build) fails with: ERROR: modpost: "mul_u64_u64_div_u64" [drivers/ptp/ptp-qoriq.ko] undefined! or a similar error. Guenter
Re: [PATCH v2 net-next 2/2] net: socket: change MSG_CMSG_COMPAT to BIT(21)
On 3/21/21 6:43 AM, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> Currently, MSG_CMSG_COMPAT is defined as '1 << 31'. However, 'msg_flags'
> is defined with type of 'int' somewhere, such as 'packet_recvmsg' and
> other recvmsg functions:
>
> static int packet_recvmsg(struct socket *sock, struct msghdr *msg,
> size_t len,
> int flags)
>
> If MSG_CMSG_COMPAT is set in 'flags', it's value will be negative.
> Once it perform bit operations with MSG_*, the upper 32 bits of
> the result will be set, just like what Guenter Roeck explained
> here:
>
> https://lore.kernel.org/netdev/20210317013758.ga134...@roeck-us.net
>
> As David Laight suggested, fix this by change MSG_CMSG_COMPAT to
> some value else. MSG_CMSG_COMPAT is an internal value, which is't
> used in userspace, so this change works.
>
Maybe I am overly concerned (or maybe call it pessimistic),
but I do wonder if this change is worth the added risk. Personally
I'd rather start changing all 'int flag' uses to 'unsigned int flag'
and, only after that is complete, make the switch to BIT().
Of course, that is just my personal opinion, and, as I said,
I may be overly concerned.
Guenter
> Reported-by: Guenter Roeck
> Signed-off-by: Menglong Dong
> ---
> v2:
> - add comment to stop people from trying to use BIT(31)
> ---
> include/linux/socket.h | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index d5ebfe30d96b..61b2694d68dd 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -312,17 +312,21 @@ struct ucred {
>* plain text and require encryption
>*/
>
> +#if defined(CONFIG_COMPAT)
> +#define MSG_CMSG_COMPAT BIT(21) /* This message needs 32 bit
> fixups */
> +#else
> +#define MSG_CMSG_COMPAT 0 /* We never have 32 bit fixups
> */
> +#endif
> +
> #define MSG_ZEROCOPY BIT(26) /* Use user data in kernel path */
> #define MSG_FASTOPEN BIT(29) /* Send data in TCP SYN */
> #define MSG_CMSG_CLOEXEC BIT(30) /* Set close_on_exec for file
>* descriptor received through
>* SCM_RIGHTS
>*/
> -#if defined(CONFIG_COMPAT)
> -#define MSG_CMSG_COMPAT BIT(31) /* This message needs 32 bit
> fixups */
> -#else
> -#define MSG_CMSG_COMPAT 0 /* We never have 32 bit fixups
> */
> -#endif
> +/* Attention: Don't use BIT(31) for MSG_*, as 'msg_flags' is defined
> + * as 'int' somewhere and BIT(31) will make it become negative.
> + */
>
>
> /* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */
>
Re: [PATCH v2 net-next 1/2] net: socket: use BIT() for MSG_*
On 3/21/21 6:43 AM, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> The bit mask for MSG_* seems a little confused here. Replace it
> with BIT() to make it clear to understand.
>
> Signed-off-by: Menglong Dong
With this patch sent as patch 1/2, any code trying to bisect
a compat related network problem will fail at this commit.
Guenter
> ---
> include/linux/socket.h | 71 ++
> 1 file changed, 37 insertions(+), 34 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 385894b4a8bb..d5ebfe30d96b 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -283,42 +283,45 @@ struct ucred {
> Added those for 1003.1g not all are supported yet
> */
>
> -#define MSG_OOB 1
> -#define MSG_PEEK 2
> -#define MSG_DONTROUTE4
> -#define MSG_TRYHARD 4 /* Synonym for MSG_DONTROUTE for DECnet */
> -#define MSG_CTRUNC 8
> -#define MSG_PROBE0x10/* Do not send. Only probe path f.e. for MTU */
> -#define MSG_TRUNC0x20
> -#define MSG_DONTWAIT 0x40/* Nonblocking io*/
> -#define MSG_EOR 0x80 /* End of record */
> -#define MSG_WAITALL 0x100 /* Wait for a full request */
> -#define MSG_FIN 0x200
> -#define MSG_SYN 0x400
> -#define MSG_CONFIRM 0x800 /* Confirm path validity */
> -#define MSG_RST 0x1000
> -#define MSG_ERRQUEUE 0x2000 /* Fetch message from error queue */
> -#define MSG_NOSIGNAL 0x4000 /* Do not generate SIGPIPE */
> -#define MSG_MORE 0x8000 /* Sender will send more */
> -#define MSG_WAITFORONE 0x1 /* recvmmsg(): block until 1+ packets
> avail */
> -#define MSG_SENDPAGE_NOPOLICY 0x1 /* sendpage() internal : do no apply
> policy */
> -#define MSG_SENDPAGE_NOTLAST 0x2 /* sendpage() internal : not the last
> page */
> -#define MSG_BATCH0x4 /* sendmmsg(): more messages coming */
> -#define MSG_EOF MSG_FIN
> -#define MSG_NO_SHARED_FRAGS 0x8 /* sendpage() internal : page frags are
> not shared */
> -#define MSG_SENDPAGE_DECRYPTED 0x10 /* sendpage() internal : page
> may carry
> - * plain text and require encryption
> - */
> -
> -#define MSG_ZEROCOPY 0x400 /* Use user data in kernel path */
> -#define MSG_FASTOPEN 0x2000 /* Send data in TCP SYN */
> -#define MSG_CMSG_CLOEXEC 0x4000 /* Set close_on_exec for file
> -descriptor received through
> -SCM_RIGHTS */
> +#define MSG_OOB BIT(0)
> +#define MSG_PEEK BIT(1)
> +#define MSG_DONTROUTEBIT(2)
> +#define MSG_TRYHARD BIT(2) /* Synonym for MSG_DONTROUTE for DECnet
> */
> +#define MSG_CTRUNC BIT(3)
> +#define MSG_PROBEBIT(4) /* Do not send. Only probe path f.e. for MTU
> */
> +#define MSG_TRUNCBIT(5)
> +#define MSG_DONTWAIT BIT(6) /* Nonblocking io */
> +#define MSG_EOR BIT(7) /* End of record*/
> +#define MSG_WAITALL BIT(8) /* Wait for a full request */
> +#define MSG_FIN BIT(9)
> +#define MSG_SYN BIT(10)
> +#define MSG_CONFIRM BIT(11) /* Confirm path validity*/
> +#define MSG_RST BIT(12)
> +#define MSG_ERRQUEUE BIT(13) /* Fetch message from error queue */
> +#define MSG_NOSIGNAL BIT(14) /* Do not generate SIGPIPE */
> +#define MSG_MORE BIT(15) /* Sender will send more*/
> +#define MSG_WAITFORONE BIT(16) /* recvmmsg(): block until 1+ packets
> avail */
> +#define MSG_SENDPAGE_NOPOLICYBIT(16) /* sendpage() internal : do no
> apply policy */
> +#define MSG_SENDPAGE_NOTLAST BIT(17) /* sendpage() internal : not the last
> page */
> +#define MSG_BATCHBIT(18) /* sendmmsg(): more messages coming */
> +#define MSG_EOF MSG_FIN
> +#define MSG_NO_SHARED_FRAGS BIT(19) /* sendpage() internal : page frags
> + * are not shared
> + */
> +#define MSG_SENDPAGE_DECRYPTED BIT(20) /* sendpage() internal : page
> may carry
> + * plain text and require encryption
> + */
> +
> +#define MSG_ZEROCOPY BIT(26) /* Use user data in kernel path */
> +#define MSG_FASTOPEN BIT(29) /* Send data in TCP SYN */
> +#define MSG_CMSG_CLOEXEC BIT(30) /* Set close_on_exec for file
> + * descriptor received through
> + * SCM_RIGHTS
> + */
> #if defined(CONFIG_COMPAT)
> -#define MSG_CMSG_COMPAT 0x8000 /* This message needs 32 bit
> fixups */
> +#define MSG_CMSG_COMPAT BIT(31) /* This message needs 32 bit
> fixups */
> #else
> -#define MSG_CMSG_COMPAT
Re: [PATCH] watchdog: Remove MV64x60 watchdog driver
On 3/18/21 10:25 AM, Christophe Leroy wrote:
> Commit 92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
> removed the last selector of CONFIG_MV64X60.
>
> Therefore CONFIG_MV64X60_WDT cannot be selected anymore and
> can be removed.
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Guenter Roeck
> ---
> drivers/watchdog/Kconfig | 4 -
> drivers/watchdog/Makefile | 1 -
> drivers/watchdog/mv64x60_wdt.c | 324 -
> include/linux/mv643xx.h| 8 -
> 4 files changed, 337 deletions(-)
> delete mode 100644 drivers/watchdog/mv64x60_wdt.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 1fe0042a48d2..178296bda151 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1831,10 +1831,6 @@ config 8xxx_WDT
>
> For BookE processors (MPC85xx) use the BOOKE_WDT driver instead.
>
> -config MV64X60_WDT
> - tristate "MV64X60 (Marvell Discovery) Watchdog Timer"
> - depends on MV64X60 || COMPILE_TEST
> -
> config PIKA_WDT
> tristate "PIKA FPGA Watchdog"
> depends on WARP || (PPC64 && COMPILE_TEST)
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f3a6540e725e..752c6513f731 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -175,7 +175,6 @@ obj-$(CONFIG_PIC32_DMT) += pic32-dmt.o
> # POWERPC Architecture
> obj-$(CONFIG_GEF_WDT) += gef_wdt.o
> obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
> -obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
> obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
> obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
> obj-$(CONFIG_MEN_A21_WDT) += mena21_wdt.o
> diff --git a/drivers/watchdog/mv64x60_wdt.c b/drivers/watchdog/mv64x60_wdt.c
> deleted file mode 100644
> index 894aa63488d3..
> --- a/drivers/watchdog/mv64x60_wdt.c
> +++ /dev/null
> @@ -1,324 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * mv64x60_wdt.c - MV64X60 (Marvell Discovery) watchdog userspace interface
> - *
> - * Author: James Chapman
> - *
> - * Platform-specific setup code should configure the dog to generate
> - * interrupt or reset as required. This code only enables/disables
> - * and services the watchdog.
> - *
> - * Derived from mpc8xx_wdt.c, with the following copyright.
> - *
> - * 2002 (c) Florian Schirmer
> - */
> -
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#define MV64x60_WDT_WDC_OFFSET 0
> -
> -/*
> - * The watchdog configuration register contains a pair of 2-bit fields,
> - * 1. a reload field, bits 27-26, which triggers a reload of
> - * the countdown register, and
> - * 2. an enable field, bits 25-24, which toggles between
> - * enabling and disabling the watchdog timer.
> - * Bit 31 is a read-only field which indicates whether the
> - * watchdog timer is currently enabled.
> - *
> - * The low 24 bits contain the timer reload value.
> - */
> -#define MV64x60_WDC_ENABLE_SHIFT 24
> -#define MV64x60_WDC_SERVICE_SHIFT26
> -#define MV64x60_WDC_ENABLED_SHIFT31
> -
> -#define MV64x60_WDC_ENABLED_TRUE 1
> -#define MV64x60_WDC_ENABLED_FALSE0
> -
> -/* Flags bits */
> -#define MV64x60_WDOG_FLAG_OPENED 0
> -
> -static unsigned long wdt_flags;
> -static int wdt_status;
> -static void __iomem *mv64x60_wdt_regs;
> -static int mv64x60_wdt_timeout;
> -static int mv64x60_wdt_count;
> -static unsigned int bus_clk;
> -static char expect_close;
> -static DEFINE_SPINLOCK(mv64x60_wdt_spinlock);
> -
> -static bool nowayout = WATCHDOG_NOWAYOUT;
> -module_param(nowayout, bool, 0);
> -MODULE_PARM_DESC(nowayout,
> - "Watchdog cannot be stopped once started (default="
> - __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> -
> -static int mv64x60_wdt_toggle_wdc(int enabled_predicate, int field_shift)
> -{
> - u32 data;
> - u32 enabled;
> - int ret = 0;
> -
> - spin_lock(&mv64x60_wdt_spinlock);
> - data = readl(mv64x60_wdt_regs + MV64x60_WDT_WDC_OFFSET);
> - enabled = (data >> MV64x60_WDC_ENABLED_SHIFT) & 1;
> -
> - /* only toggle the requested field if enabled state matches predicate */
> - if ((enabled ^ enabled_predicate) == 0) {
> - /* We write a 1, then a 2 -- to the appropriate field */
> - data = (1 << field_shift) | mv64x60_wdt_count;
> - writel(data, mv64x6
Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*
On Wed, Mar 17, 2021 at 09:53:23PM +0800, Menglong Dong wrote: > On Wed, Mar 17, 2021 at 5:36 PM Andy Shevchenko > wrote: > > > ... > > > > The problematic code is negation of the flags when it's done in > > operations like &. > > It maybe fixed by swapping positions of the arguments, i.e. ~(FOO | > > BAR) & flags. > > > > All this is a beast called "integer promotions" in the C standard. > > > > The best is to try to get flags to be unsigned. By how invasive it may be? > > Seems that the inconsistent usages of 'msg_flags' is a lot, for example the > 'recvmsg()' in 'struct proto' and 'recvmsg()' in 'struct proto_ops': > > int (*recvmsg)(struct sock *sk, struct msghdr *msg, > size_t len, int noblock, int flags, > int *addr_len); > > This function prototype is used in many places, It's not easy to fix them. Also, flags is used in several other functions, not just recvmsg. > This patch is already reverted, and I think maybe > I can resend it after I fix these 'int' flags. I would suggest to consult with Dave on that. While much of the conversion could be handled automatically with coccinelle, it touches a lot of files. I don't think that is worth the effort (or risk). Guenter
Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*
On 3/17/21 2:40 AM, Andy Shevchenko wrote: > On Wed, Mar 17, 2021 at 11:36 AM Andy Shevchenko > wrote: >> On Wed, Mar 17, 2021 at 10:21 AM Menglong Dong >> wrote: > > ... > >> It maybe fixed by swapping positions of the arguments, i.e. ~(FOO | >> BAR) & flags. > > ...and type casting will be needed anyway here... > > I was thinking about this case > > drivers/i2c/busses/i2c-designware-common.c:420: > dev->sda_hold_time & ~(u32)DW_IC_SDA_HOLD_RX_MASK > , > > but sda_hold_time there is unsigned. > That is needed because of the %d. Without the (u32), the expression is promoted to unsigned long and the compiler wants to see %ld. Guenter
Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*
On Wed, Mar 17, 2021 at 01:02:51AM +0200, Andy Shevchenko wrote: > On Wednesday, March 17, 2021, Guenter Roeck wrote: > > > Hi, > > > > On Tue, Mar 09, 2021 at 05:51:35PM -0800, menglong8.d...@gmail.com wrote: > > > From: Menglong Dong > > > > > > The bit mask for MSG_* seems a little confused here. Replace it > > > with BIT() to make it clear to understand. > > > > > > Signed-off-by: Menglong Dong > > > > I must admit that I am a bit puzzled, > > > I have checked the values and don’t see a problem. So, the only difference > is the type int vs. unsigned long. I think this simply reveals an issue > somewhere in the code. > The problem is in net/packet/af_packet.c:packet_recvmsg(). This function, as well as all other rcvmsg functions, is declared as static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, int flags) MSG_CMSG_COMPAT (0x8000) is set in flags, meaning its value is negative. This is then evaluated in if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE)) goto out; If any of those flags is declared as BIT() and thus long, flags is sign-extended to long. Since it is negative, its upper 32 bits will be set, the if statement evaluates as true, and the function bails out. This is relatively easy to fix here with, for example, if ((unsigned int)flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE)) goto out; but that is just a hack, and it doesn't solve the real problem: Each function in struct proto_ops which passes flags passes it as int (see include/linux/net.h:struct proto_ops). Each such function, if called with MSG_CMSG_COMPAT set, will fail a match against ~(MSG_anything) if MSG_anything is declared as BIT() or long. As it turns out, I was kind of lucky to catch the problem: So far I have seen it only on mips64 kernels with N32 userspace. Guenter
Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*
On 3/16/21 4:02 PM, Andy Shevchenko wrote: > > > On Wednesday, March 17, 2021, Guenter Roeck <mailto:li...@roeck-us.net>> wrote: > > Hi, > > On Tue, Mar 09, 2021 at 05:51:35PM -0800, menglong8.d...@gmail.com > <mailto:menglong8.d...@gmail.com> wrote: > > From: Menglong Dong <mailto:dong.mengl...@zte.com.cn>> > > > > The bit mask for MSG_* seems a little confused here. Replace it > > with BIT() to make it clear to understand. > > > > Signed-off-by: Menglong Dong <mailto:dong.mengl...@zte.com.cn>> > > I must admit that I am a bit puzzled, > > > I have checked the values and don’t see a problem. So, the only difference is > the type int vs. unsigned long. I think this simply reveals an issue > somewhere in the code. > I am currently trying to "bisect" the individual bits. We'll see if I can find the culprit(s). Guenter > > > but with this patch in the tree > (in next-20210316) several of my qemu network interface tests fail > to get an IP address. So far I have only seen this with mips64 > tests, but that may be because I only started running those tests > on various architectures. > > The tests do nothing special: With CONFIG_IP_PNP_DHCP=n, run udhcpc > in qemu to get an IP address. With this patch in place, udhcpc fails. > With this patch reverted, udhcpc gets the IP address as expected. > The error reported by udhcpc is: > > udhcpc: sending discover > udhcpc: read error: Invalid argument, reopening socket > > Reverting this patch fixes the problem. > > Guenter > > --- > bisect log: > > # bad: [0f4b0bb396f6f424a7b074d00cb71f5966edcb8a] Add linux-next specific > files for 20210316 > # good: [1e28eed17697bcf343c6743f0028cc3b5dd88bf0] Linux 5.12-rc3 > git bisect start 'HEAD' 'v5.12-rc3' > # bad: [edd84c42baeffe66740143a04f24588fded94241] Merge remote-tracking > branch 'drm-misc/for-linux-next' > git bisect bad edd84c42baeffe66740143a04f24588fded94241 > # good: [a76f62d56da82bee1a4c35dd6375a8fdd57eca4e] Merge remote-tracking > branch 'cel/for-next' > git bisect good a76f62d56da82bee1a4c35dd6375a8fdd57eca4e > # good: [e2924c67bae0cc15ca64dbe1ed791c96eed6d149] Merge remote-tracking > branch 'rdma/for-next' > git bisect good e2924c67bae0cc15ca64dbe1ed791c96eed6d149 > # bad: [a8f9952d218d816ff1a13c9385edd821a8da527d] selftests: > fib_nexthops: List each test case in a different line > git bisect bad a8f9952d218d816ff1a13c9385edd821a8da527d > # bad: [4734a750f4674631ab9896189810b57700597aa7] mlxsw: Adjust some MFDE > fields shift and size to fw implementation > git bisect bad 4734a750f4674631ab9896189810b57700597aa7 > # good: [32e76b187a90de5809d68c2ef3e3964176dacaf0] bpf: Document > BPF_PROG_ATTACH syscall command > git bisect good 32e76b187a90de5809d68c2ef3e3964176dacaf0 > # good: [ee75aef23afe6e88497151c127c13ed69f41aaa2] bpf, xdp: Restructure > redirect actions > git bisect good ee75aef23afe6e88497151c127c13ed69f41aaa2 > # bad: [90d181ca488f466904ea59dd5c836f766b69c71b] net: rose: Fix > fall-through warnings for Clang > git bisect bad 90d181ca488f466904ea59dd5c836f766b69c71b > # bad: [537a0c5c4218329990dc8973068f3bfe5c882623] net: fddi: skfp: smt: > Replace one-element array with flexible-array member > git bisect bad 537a0c5c4218329990dc8973068f3bfe5c882623 > # bad: [97c2c69e1926260c78c7f1c0b2c987934f1dc7a1] virtio-net: support XDP > when not more queues > git bisect bad 97c2c69e1926260c78c7f1c0b2c987934f1dc7a1 > # good: [c1acda9807e2bbe1d2026b44f37d959d6d8266c8] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next > <http://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next> > git bisect good c1acda9807e2bbe1d2026b44f37d959d6d8266c8 > # bad: [0bb3262c0248d44aea3be31076f44beb82a7b120] net: socket: use BIT() > for MSG_* > git bisect bad 0bb3262c0248d44aea3be31076f44beb82a7b120 > # first bad commit: [0bb3262c0248d44aea3be31076f44beb82a7b120] net: > socket: use BIT() for MSG_* > > > > -- > With Best Regards, > Andy Shevchenko > >
Re: [PATCH v4 RESEND net-next] net: socket: use BIT() for MSG_*
Hi, On Tue, Mar 09, 2021 at 05:51:35PM -0800, menglong8.d...@gmail.com wrote: > From: Menglong Dong > > The bit mask for MSG_* seems a little confused here. Replace it > with BIT() to make it clear to understand. > > Signed-off-by: Menglong Dong I must admit that I am a bit puzzled, but with this patch in the tree (in next-20210316) several of my qemu network interface tests fail to get an IP address. So far I have only seen this with mips64 tests, but that may be because I only started running those tests on various architectures. The tests do nothing special: With CONFIG_IP_PNP_DHCP=n, run udhcpc in qemu to get an IP address. With this patch in place, udhcpc fails. With this patch reverted, udhcpc gets the IP address as expected. The error reported by udhcpc is: udhcpc: sending discover udhcpc: read error: Invalid argument, reopening socket Reverting this patch fixes the problem. Guenter --- bisect log: # bad: [0f4b0bb396f6f424a7b074d00cb71f5966edcb8a] Add linux-next specific files for 20210316 # good: [1e28eed17697bcf343c6743f0028cc3b5dd88bf0] Linux 5.12-rc3 git bisect start 'HEAD' 'v5.12-rc3' # bad: [edd84c42baeffe66740143a04f24588fded94241] Merge remote-tracking branch 'drm-misc/for-linux-next' git bisect bad edd84c42baeffe66740143a04f24588fded94241 # good: [a76f62d56da82bee1a4c35dd6375a8fdd57eca4e] Merge remote-tracking branch 'cel/for-next' git bisect good a76f62d56da82bee1a4c35dd6375a8fdd57eca4e # good: [e2924c67bae0cc15ca64dbe1ed791c96eed6d149] Merge remote-tracking branch 'rdma/for-next' git bisect good e2924c67bae0cc15ca64dbe1ed791c96eed6d149 # bad: [a8f9952d218d816ff1a13c9385edd821a8da527d] selftests: fib_nexthops: List each test case in a different line git bisect bad a8f9952d218d816ff1a13c9385edd821a8da527d # bad: [4734a750f4674631ab9896189810b57700597aa7] mlxsw: Adjust some MFDE fields shift and size to fw implementation git bisect bad 4734a750f4674631ab9896189810b57700597aa7 # good: [32e76b187a90de5809d68c2ef3e3964176dacaf0] bpf: Document BPF_PROG_ATTACH syscall command git bisect good 32e76b187a90de5809d68c2ef3e3964176dacaf0 # good: [ee75aef23afe6e88497151c127c13ed69f41aaa2] bpf, xdp: Restructure redirect actions git bisect good ee75aef23afe6e88497151c127c13ed69f41aaa2 # bad: [90d181ca488f466904ea59dd5c836f766b69c71b] net: rose: Fix fall-through warnings for Clang git bisect bad 90d181ca488f466904ea59dd5c836f766b69c71b # bad: [537a0c5c4218329990dc8973068f3bfe5c882623] net: fddi: skfp: smt: Replace one-element array with flexible-array member git bisect bad 537a0c5c4218329990dc8973068f3bfe5c882623 # bad: [97c2c69e1926260c78c7f1c0b2c987934f1dc7a1] virtio-net: support XDP when not more queues git bisect bad 97c2c69e1926260c78c7f1c0b2c987934f1dc7a1 # good: [c1acda9807e2bbe1d2026b44f37d959d6d8266c8] Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next git bisect good c1acda9807e2bbe1d2026b44f37d959d6d8266c8 # bad: [0bb3262c0248d44aea3be31076f44beb82a7b120] net: socket: use BIT() for MSG_* git bisect bad 0bb3262c0248d44aea3be31076f44beb82a7b120 # first bad commit: [0bb3262c0248d44aea3be31076f44beb82a7b120] net: socket: use BIT() for MSG_*
Re: [net-next V2 12/17] net/mlx5e: Extract tc tunnel encap/decap code to dedicated file
On Fri, Feb 05, 2021 at 09:02:35PM -0800, Saeed Mahameed wrote: > From: Vlad Buslov > > Following patches in series extend the extracted code with routing > infrastructure. To improve code modularity created a dedicated > tc_tun_encap.c source file and move encap/decap related code to the new > file. Export code that is used by both regular TC code and encap/decap code > into tc_priv.h (new header intended to be used only by TC module). Rename > some exported functions by adding "mlx5e_" prefix to their names. > > Signed-off-by: Vlad Buslov > Signed-off-by: Dmytro Linkin > Reviewed-by: Roi Dayan > Signed-off-by: Saeed Mahameed When building s390:defconfig, this patch results in: In file included from drivers/net/ethernet/mellanox/mlx5/core/en_tc.h:40, from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:45: drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.h:24:29: error: field 'match_level' has incomplete type Bisect log attached. Guenter --- # bad: [a4bfd8d46ac357c12529e4eebb6c89502b03ecc9] Add linux-next specific files for 20210209 # good: [92bf22614b21a2706f4993b278017e437f7785b3] Linux 5.11-rc7 git bisect start 'HEAD' 'v5.11-rc7' # bad: [a8eb921ba7e8e77d994a1c6c69c8ef08456ecf53] Merge remote-tracking branch 'crypto/master' git bisect bad a8eb921ba7e8e77d994a1c6c69c8ef08456ecf53 # good: [b68df186dae8ae890df08059bb068b78252b053a] Merge remote-tracking branch 'hid/for-next' git bisect good b68df186dae8ae890df08059bb068b78252b053a # good: [1299616023a0db19be4ff5588db4fb61d8cd51f9] Merge tag 'mt76-for-kvalo-2021-01-29' of https://github.com/nbd168/wireless git bisect good 1299616023a0db19be4ff5588db4fb61d8cd51f9 # good: [db9deabba7a9a6fded1aeda51dda1ce9b78f0711] Merge remote-tracking branch 'v4l-dvb-next/master' git bisect good db9deabba7a9a6fded1aeda51dda1ce9b78f0711 # good: [ed19e2282476b1e0dc01c67fc19010ab791a7a46] Merge remote-tracking branch 'rdma/for-next' git bisect good ed19e2282476b1e0dc01c67fc19010ab791a7a46 # bad: [ae3b49168f93b4432b852ca6f2f7323fead45e8d] Merge remote-tracking branch 'bluetooth/master' git bisect bad ae3b49168f93b4432b852ca6f2f7323fead45e8d # good: [215cb7d3823e798de327e3232e396434fab84f42] bpf/benchs/bench_ringbufs: Remove unneeded semicolon git bisect good 215cb7d3823e798de327e3232e396434fab84f42 # good: [de71a6cb4bf24d8993b9ca90d1ddb131b60251a1] Bluetooth: btusb: Fix memory leak in btusb_mtk_wmt_recv git bisect good de71a6cb4bf24d8993b9ca90d1ddb131b60251a1 # bad: [8914add2c9e5518f6a864936658bba5752510b39] net/mlx5e: Handle FIB events to update tunnel endpoint device git bisect bad 8914add2c9e5518f6a864936658bba5752510b39 # good: [4ad9116c84ed3243f7b706f07646a995f3bca502] net/mlx5e: Remove redundant match on tunnel destination mac git bisect good 4ad9116c84ed3243f7b706f07646a995f3bca502 # bad: [0d9f96471493d5483d116c137693f03604332a04] net/mlx5e: Extract tc tunnel encap/decap code to dedicated file git bisect bad 0d9f96471493d5483d116c137693f03604332a04 # good: [48d216e5596a58e3cfa6d4548343f982c5921b79] net/mlx5e: Refactor reg_c1 usage git bisect good 48d216e5596a58e3cfa6d4548343f982c5921b79 # good: [8e404fefa58b6138531e3d4b5647ee79f75ae9a8] net/mlx5e: Match recirculated packet miss in slow table using reg_c1 git bisect good 8e404fefa58b6138531e3d4b5647ee79f75ae9a8 # first bad commit: [0d9f96471493d5483d116c137693f03604332a04] net/mlx5e: Extract tc tunnel encap/decap code to dedicated file
Re: [PATCH 2/3] mac80211: Add support to trigger sta disconnect on hardware restart
On Tue, Dec 15, 2020 at 10:53:52PM +0530, Youghandhar Chintala wrote:
> Currently in case of target hardware restart, we just reconfig and
> re-enable the security keys and enable the network queues to start
> data traffic back from where it was interrupted.
>
> Many ath10k wifi chipsets have sequence numbers for the data
> packets assigned by firmware and the mac sequence number will
> restart from zero after target hardware restart leading to mismatch
> in the sequence number expected by the remote peer vs the sequence
> number of the frame sent by the target firmware.
>
> This mismatch in sequence number will cause out-of-order packets
> on the remote peer and all the frames sent by the device are dropped
> until we reach the sequence number which was sent before we restarted
> the target hardware
>
> In order to fix this, we trigger a sta disconnect, for the targets
> which expose this corresponding wiphy flag, in case of target hw
> restart. After this there will be a fresh connection and thereby
> avoiding the dropping of frames by remote peer.
>
> The right fix would be to pull the entire data path into the host
> which is not feasible or would need lots of complex changes and
> will still be inefficient.
>
> Tested on ath10k using WCN3990, QCA6174
>
> Signed-off-by: Youghandhar Chintala
> Reviewed-by: Abhishek Kumar
> ---
> net/mac80211/ieee80211_i.h | 3 +++
> net/mac80211/mlme.c| 9 +
> net/mac80211/util.c| 22 +++---
> 3 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index cde2e3f..8cbeb5f 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -748,6 +748,8 @@ struct ieee80211_if_mesh {
> * back to wireless media and to the local net stack.
> * @IEEE80211_SDATA_DISCONNECT_RESUME: Disconnect after resume.
> * @IEEE80211_SDATA_IN_DRIVER: indicates interface was added to driver
> + * @IEEE80211_SDATA_DISCONNECT_HW_RESTART: Disconnect after hardware restart
> + * recovery
> */
> enum ieee80211_sub_if_data_flags {
> IEEE80211_SDATA_ALLMULTI= BIT(0),
> @@ -755,6 +757,7 @@ enum ieee80211_sub_if_data_flags {
> IEEE80211_SDATA_DONT_BRIDGE_PACKETS = BIT(3),
> IEEE80211_SDATA_DISCONNECT_RESUME = BIT(4),
> IEEE80211_SDATA_IN_DRIVER = BIT(5),
> + IEEE80211_SDATA_DISCONNECT_HW_RESTART = BIT(6),
> };
>
> /**
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 6adfcb9..e4d0d16 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -4769,6 +4769,15 @@ void ieee80211_sta_restart(struct
> ieee80211_sub_if_data *sdata)
> true);
> sdata_unlock(sdata);
> return;
> + } else if (sdata->flags & IEEE80211_SDATA_DISCONNECT_HW_RESTART) {
> + sdata->flags &= ~IEEE80211_SDATA_DISCONNECT_HW_RESTART;
> + mlme_dbg(sdata, "driver requested disconnect after hardware
> restart\n");
> + ieee80211_sta_connection_lost(sdata,
> + ifmgd->associated->bssid,
> + WLAN_REASON_UNSPECIFIED,
> + true);
> + sdata_unlock(sdata);
> + return;
> }
> sdata_unlock(sdata);
> }
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 8c3c01a..98567a3 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -2567,9 +2567,12 @@ int ieee80211_reconfig(struct ieee80211_local *local)
> }
> mutex_unlock(&local->sta_mtx);
>
> - /* add back keys */
> - list_for_each_entry(sdata, &local->interfaces, list)
> - ieee80211_reenable_keys(sdata);
> +
> + if (!(hw->wiphy->flags & WIPHY_FLAG_STA_DISCONNECT_ON_HW_RESTART)) {
> + /* add back keys */
> + list_for_each_entry(sdata, &local->interfaces, list)
> + ieee80211_reenable_keys(sdata);
> + }
>
> /* Reconfigure sched scan if it was interrupted by FW restart */
> mutex_lock(&local->mtx);
> @@ -2643,6 +2646,19 @@ int ieee80211_reconfig(struct ieee80211_local *local)
> IEEE80211_QUEUE_STOP_REASON_SUSPEND,
> false);
>
> + if ((hw->wiphy->flags & WIPHY_FLAG_STA_DISCONNECT_ON_HW_RESTART) &&
> + !reconfig_due_to_wowlan) {
> + list_for_each_entry(sdata, &local->interfaces, list) {
> + if (!ieee80211_sdata_running(sdata))
> + continue;
> + if (sdata->vif.type == NL80211_IFTYPE_STATION) {
> + sdata->flags |=
> + IEEE80211_SDATA_DISCONNECT_HW_RESTART;
> + ieee80211_sta_restart(sdata);
If CONFIG_PM=n:
ERROR: "ieee8021
Re: [PATCH v1 2/2] mei: bus: change remove callback to return void
On 2/7/21 2:22 PM, Uwe Kleine-König wrote:
> The driver core ignores the return value of mei_cl_device_remove() so
> passing an error value doesn't solve any problem. As most mei drivers'
> remove callbacks return 0 unconditionally and returning a different value
> doesn't have any effect, change this prototype to return void and return 0
> unconditionally in mei_cl_device_remove(). The only driver that could
> return an error value is modified to emit an explicit warning in the error
> case.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/misc/mei/bus.c | 5 ++---
> drivers/misc/mei/hdcp/mei_hdcp.c | 7 +--
> drivers/nfc/microread/mei.c | 4 +---
> drivers/nfc/pn544/mei.c | 4 +---
> drivers/watchdog/mei_wdt.c | 4 +---
Acked-by: Guenter Roeck
> include/linux/mei_cl_bus.h | 2 +-
> 6 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
> index 50d617e7467e..54dddae46705 100644
> --- a/drivers/misc/mei/bus.c
> +++ b/drivers/misc/mei/bus.c
> @@ -879,17 +879,16 @@ static int mei_cl_device_remove(struct device *dev)
> {
> struct mei_cl_device *cldev = to_mei_cl_device(dev);
> struct mei_cl_driver *cldrv = to_mei_cl_driver(dev->driver);
> - int ret = 0;
>
> if (cldrv->remove)
> - ret = cldrv->remove(cldev);
> + cldrv->remove(cldev);
>
> mei_cldev_unregister_callbacks(cldev);
>
> mei_cl_bus_module_put(cldev);
> module_put(THIS_MODULE);
>
> - return ret;
> + return 0;
> }
>
> static ssize_t name_show(struct device *dev, struct device_attribute *a,
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 9ae9669e46ea..6a455ebe4891 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -845,16 +845,19 @@ static int mei_hdcp_probe(struct mei_cl_device *cldev,
> return ret;
> }
>
> -static int mei_hdcp_remove(struct mei_cl_device *cldev)
> +static void mei_hdcp_remove(struct mei_cl_device *cldev)
> {
> struct i915_hdcp_comp_master *comp_master =
> mei_cldev_get_drvdata(cldev);
> + int ret;
>
> component_master_del(&cldev->dev, &mei_component_master_ops);
> kfree(comp_master);
> mei_cldev_set_drvdata(cldev, NULL);
>
> - return mei_cldev_disable(cldev);
> + ret = mei_cldev_disable(cldev);
> + if (ret)
> + dev_warn(&cldev->dev, "mei_cldev_disable() failed\n")
> }
>
> #define MEI_UUID_HDCP GUID_INIT(0xB638AB7E, 0x94E2, 0x4EA2, 0xA5, \
> diff --git a/drivers/nfc/microread/mei.c b/drivers/nfc/microread/mei.c
> index 5dad8847a9b3..8fa7771085eb 100644
> --- a/drivers/nfc/microread/mei.c
> +++ b/drivers/nfc/microread/mei.c
> @@ -44,15 +44,13 @@ static int microread_mei_probe(struct mei_cl_device
> *cldev,
> return 0;
> }
>
> -static int microread_mei_remove(struct mei_cl_device *cldev)
> +static void microread_mei_remove(struct mei_cl_device *cldev)
> {
> struct nfc_mei_phy *phy = mei_cldev_get_drvdata(cldev);
>
> microread_remove(phy->hdev);
>
> nfc_mei_phy_free(phy);
> -
> - return 0;
> }
>
> static struct mei_cl_device_id microread_mei_tbl[] = {
> diff --git a/drivers/nfc/pn544/mei.c b/drivers/nfc/pn544/mei.c
> index 579bc599f545..5c10aac085a4 100644
> --- a/drivers/nfc/pn544/mei.c
> +++ b/drivers/nfc/pn544/mei.c
> @@ -42,7 +42,7 @@ static int pn544_mei_probe(struct mei_cl_device *cldev,
> return 0;
> }
>
> -static int pn544_mei_remove(struct mei_cl_device *cldev)
> +static void pn544_mei_remove(struct mei_cl_device *cldev)
> {
> struct nfc_mei_phy *phy = mei_cldev_get_drvdata(cldev);
>
> @@ -51,8 +51,6 @@ static int pn544_mei_remove(struct mei_cl_device *cldev)
> pn544_hci_remove(phy->hdev);
>
> nfc_mei_phy_free(phy);
> -
> - return 0;
> }
>
> static struct mei_cl_device_id pn544_mei_tbl[] = {
> diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> index 5391bf3e6b11..53165e49c298 100644
> --- a/drivers/watchdog/mei_wdt.c
> +++ b/drivers/watchdog/mei_wdt.c
> @@ -619,7 +619,7 @@ static int mei_wdt_probe(struct mei_cl_device *cldev,
> return ret;
> }
>
> -static int mei_wdt_remove(struct mei_cl_device *cldev)
> +static void mei_wdt_remove(struct mei_cl_device *cldev)
> {
> struct mei_wdt *wdt = mei_cldev_get_drvdata(cldev);
>
> @@ -636,8 +636,6 @@ static int mei_wdt_remove(struct mei_c
Re: [PATCH] net: fec: Silence M5272 build warnings
On Tue, Feb 02, 2021 at 02:06:50PM +0100, Geert Uytterhoeven wrote:
> If CONFIG_M5272=y:
>
> drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_restart’:
> drivers/net/ethernet/freescale/fec_main.c:948:6: warning: unused variable
> ‘val’ [-Wunused-variable]
> 948 | u32 val;
> | ^~~
> drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_get_mac’:
> drivers/net/ethernet/freescale/fec_main.c:1667:28: warning: unused
> variable ‘pdata’ [-Wunused-variable]
> 1667 | struct fec_platform_data *pdata =
> dev_get_platdata(&fep->pdev->dev);
> |^
>
> Fix this by moving the variable declarations inside the existing #ifdef
> blocks.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Guenter Roeck
> ---
> drivers/net/ethernet/freescale/fec_main.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 9ebdb0e54291b204..3db882322b2bd3e8 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -945,7 +945,6 @@ static void
> fec_restart(struct net_device *ndev)
> {
> struct fec_enet_private *fep = netdev_priv(ndev);
> - u32 val;
> u32 temp_mac[2];
> u32 rcntl = OPT_FRAME_SIZE | 0x04;
> u32 ecntl = 0x2; /* ETHEREN */
> @@ -997,7 +996,8 @@ fec_restart(struct net_device *ndev)
>
> #if !defined(CONFIG_M5272)
> if (fep->quirks & FEC_QUIRK_HAS_RACC) {
> - val = readl(fep->hwp + FEC_RACC);
> + u32 val = readl(fep->hwp + FEC_RACC);
> +
> /* align IP header */
> val |= FEC_RACC_SHIFT16;
> if (fep->csum_flags & FLAG_RX_CSUM_ENABLED)
> @@ -1664,7 +1664,6 @@ static int fec_enet_rx_napi(struct napi_struct *napi,
> int budget)
> static void fec_get_mac(struct net_device *ndev)
> {
> struct fec_enet_private *fep = netdev_priv(ndev);
> - struct fec_platform_data *pdata = dev_get_platdata(&fep->pdev->dev);
> unsigned char *iap, tmpaddr[ETH_ALEN];
>
> /*
> @@ -1695,6 +1694,8 @@ static void fec_get_mac(struct net_device *ndev)
> if (FEC_FLASHMAC)
> iap = (unsigned char *)FEC_FLASHMAC;
> #else
> + struct fec_platform_data *pdata =
> dev_get_platdata(&fep->pdev->dev);
> +
> if (pdata)
> iap = (unsigned char *)&pdata->mac;
> #endif
> --
> 2.25.1
>
Re: [PATCH] dt-bindings: Cleanup standard unit properties
On Thu, Jan 28, 2021 at 01:45:15PM -0600, Rob Herring wrote: > Properties with standard unit suffixes already have a type and don't need > type definitions. They also default to a single entry, so 'maxItems: 1' > can be dropped. > > adi,ad5758 is an oddball which defined an enum of arrays. While a valid > schema, it is simpler as a whole to only define scalar constraints. > > Cc: Jean Delvare > Cc: Guenter Roeck > Cc: Jonathan Cameron > Cc: Lars-Peter Clausen > Cc: Alexandre Torgue > Cc: Dmitry Torokhov > Cc: Ulf Hansson > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Sebastian Reichel > Cc: Mark Brown > Cc: Alexandre Belloni > Cc: Greg Kroah-Hartman > Cc: Serge Semin > Cc: Wolfram Sang > Cc: linux-hw...@vger.kernel.org Acked-by: Guenter Roeck > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-in...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: netdev@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-ser...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-watch...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/cpus.yaml | 1 - > .../bindings/extcon/wlf,arizona.yaml | 1 - > .../bindings/hwmon/adi,ltc2947.yaml | 1 - > .../bindings/hwmon/baikal,bt1-pvt.yaml| 8 ++-- > .../devicetree/bindings/hwmon/ti,tmp513.yaml | 1 - > .../devicetree/bindings/i2c/i2c-gpio.yaml | 2 - > .../bindings/i2c/snps,designware-i2c.yaml | 3 -- > .../bindings/iio/adc/maxim,max9611.yaml | 1 - > .../bindings/iio/adc/st,stm32-adc.yaml| 1 - > .../bindings/iio/adc/ti,palmas-gpadc.yaml | 2 - > .../bindings/iio/dac/adi,ad5758.yaml | 41 --- > .../bindings/iio/health/maxim,max30100.yaml | 1 - > .../input/touchscreen/touchscreen.yaml| 2 - > .../bindings/mmc/mmc-controller.yaml | 1 - > .../bindings/mmc/mmc-pwrseq-simple.yaml | 2 - > .../bindings/net/ethernet-controller.yaml | 2 - > .../devicetree/bindings/net/snps,dwmac.yaml | 1 - > .../bindings/power/supply/battery.yaml| 3 -- > .../bindings/power/supply/bq2515x.yaml| 1 - > .../bindings/regulator/dlg,da9121.yaml| 1 - > .../bindings/regulator/fixed-regulator.yaml | 2 - > .../devicetree/bindings/rtc/rtc.yaml | 2 - > .../devicetree/bindings/serial/pl011.yaml | 2 - > .../devicetree/bindings/sound/sgtl5000.yaml | 2 - > .../bindings/watchdog/watchdog.yaml | 1 - > 25 files changed, 29 insertions(+), 56 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml > b/Documentation/devicetree/bindings/arm/cpus.yaml > index 14cd727d3c4b..f02fd10de604 100644 > --- a/Documentation/devicetree/bindings/arm/cpus.yaml > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml > @@ -232,7 +232,6 @@ properties: >by this cpu (see ./idle-states.yaml). > >capacity-dmips-mhz: > -$ref: '/schemas/types.yaml#/definitions/uint32' > description: >u32 value representing CPU capacity (see ./cpu-capacity.txt) in >DMIPS/MHz, relative to highest capacity-dmips-mhz > diff --git a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml > b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml > index 5fe784f487c5..efdf59abb2e1 100644 > --- a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml > +++ b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml > @@ -85,7 +85,6 @@ properties: >wlf,micd-timeout-ms: > description: >Timeout for microphone detection, specified in milliseconds. > -$ref: "/schemas/types.yaml#/definitions/uint32" > >wlf,micd-force-micbias: > description: > diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml > b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml > index eef614962b10..bf04151b63d2 100644 > --- a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml > +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml > @@ -49,7 +49,6 @@ properties: > description: >This property controls the Accumulation Dead band which allows to set > the >level of current below which no accumulation takes place. > -$ref: /schemas/types.yaml#/definitions/uint32 > maximum: 255 > default: 0 > > diff --git a/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml > b/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml > index 00a6511354e6..5d3ce641fcde 100644 > --- a/Documentation/de
Re: [PATCH 01/10] MIPS: TX49xx: Drop support
On 1/5/21 6:02 AM, Thomas Bogendoerfer wrote: > Looks like there are no boards with TX49xx CPUS other than reference > boards available. So it's time to drop Linux support for it. > > Signed-off-by: Thomas Bogendoerfer > --- > drivers/watchdog/Kconfig | 2 +- Acked-by: Guenter Roeck Guenter
Re: [patch 02/30] genirq: Move status flag checks to core
On Thu, Dec 10, 2020 at 08:25:38PM +0100, Thomas Gleixner wrote:
> These checks are used by modules and prevent the removal of the export of
> irq_to_desc(). Move the accessor into the core.
>
> Signed-off-by: Thomas Gleixner
Yes, but that means that irq_check_status_bit() may be called from modules,
but it is not exported, resulting in build errors such as the following.
arm64:allmodconfig:
ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] undefined!
Guenter
> ---
> include/linux/irqdesc.h | 17 +
> kernel/irq/manage.c | 17 +
> 2 files changed, 22 insertions(+), 12 deletions(-)
>
> --- a/include/linux/irqdesc.h
> +++ b/include/linux/irqdesc.h
> @@ -223,28 +223,21 @@ irq_set_chip_handler_name_locked(struct
> data->chip = chip;
> }
>
> +bool irq_check_status_bit(unsigned int irq, unsigned int bitmask);
> +
> static inline bool irq_balancing_disabled(unsigned int irq)
> {
> - struct irq_desc *desc;
> -
> - desc = irq_to_desc(irq);
> - return desc->status_use_accessors & IRQ_NO_BALANCING_MASK;
> + return irq_check_status_bit(irq, IRQ_NO_BALANCING_MASK);
> }
>
> static inline bool irq_is_percpu(unsigned int irq)
> {
> - struct irq_desc *desc;
> -
> - desc = irq_to_desc(irq);
> - return desc->status_use_accessors & IRQ_PER_CPU;
> + return irq_check_status_bit(irq, IRQ_PER_CPU);
> }
>
> static inline bool irq_is_percpu_devid(unsigned int irq)
> {
> - struct irq_desc *desc;
> -
> - desc = irq_to_desc(irq);
> - return desc->status_use_accessors & IRQ_PER_CPU_DEVID;
> + return irq_check_status_bit(irq, IRQ_PER_CPU_DEVID);
> }
>
> static inline void
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -2769,3 +2769,23 @@ bool irq_has_action(unsigned int irq)
> return res;
> }
> EXPORT_SYMBOL_GPL(irq_has_action);
> +
> +/**
> + * irq_check_status_bit - Check whether bits in the irq descriptor status
> are set
> + * @irq: The linux irq number
> + * @bitmask: The bitmask to evaluate
> + *
> + * Returns: True if one of the bits in @bitmask is set
> + */
> +bool irq_check_status_bit(unsigned int irq, unsigned int bitmask)
> +{
> + struct irq_desc *desc;
> + bool res = false;
> +
> + rcu_read_lock();
> + desc = irq_to_desc(irq);
> + if (desc)
> + res = !!(desc->status_use_accessors & bitmask);
> + rcu_read_unlock();
> + return res;
> +}
Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
On 12/20/20 10:18 PM, Masahiro Yamada wrote: > On Mon, Dec 14, 2020 at 12:27 AM Miguel Ojeda > wrote: >> >> On Sun, Dec 13, 2020 at 4:16 PM Greg KH wrote: >>> >>> Because if you get a report of something breaking for your change, you >>> need to work to resolve it, not argue about it. Otherwise it needs to >>> be dropped/reverted. >> >> Nobody has argued that. In fact, I explicitly said the opposite: "So I >> think we can fix them as they come.". >> >> I am expecting Masahiro to follow up. It has been less than 24 hours >> since the report, on a weekend. >> >> Cheers, >> Miguel > > > Sorry for the delay. > > Now I sent out the fix for lantiq_etop.c > > https://lore.kernel.org/patchwork/patch/1355595/ > next-20201218, alpha:allmodconfig: fs/binfmt_em86.c: In function 'load_em86': fs/binfmt_em86.c:66:2: error: ignoring return value of 'remove_arg_zero' declared with attribute 'warn_unused_result' With a change like this, I'd have expected that there is a coccinelle script or similar to ensure that claims made in the commit message are true. Guenter
Re: [PATCH] dt-bindings: Fix JSON pointers
On 12/17/20 2:34 PM, Rob Herring wrote: > The correct syntax for JSON pointers begins with a '/' after the '#'. > Without a '/', the string should be interpretted as a subschema > identifier. The jsonschema module currently doesn't handle subschema > identifiers and incorrectly allows JSON pointers to begin without a '/'. > Let's fix this before it becomes a problem when jsonschema module is > fixed. > > Converted with: > perl -p -i -e 's/yaml#definitions/yaml#\/definitions/g' `find > Documentation/devicetree/bindings/ -name "*.yaml"` > > Cc: Maxime Ripard > Cc: Vinod Koul > Cc: Guenter Roeck > Cc: Jonathan Cameron > Cc: Lars-Peter Clausen > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Pavel Machek > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Andrew Lunn > Cc: Florian Fainelli > Cc: Sebastian Reichel > Cc: Greg Kroah-Hartman > Cc: Mark Brown > Cc: netdev@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../bindings/hwmon/moortec,mr75203.yaml | 2 +- > .../bindings/hwmon/sensirion,shtc1.yaml | 4 +- > .../devicetree/bindings/hwmon/ti,tmp513.yaml | 2 +- Acked-by: Guenter Roeck
Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
On 12/12/20 9:04 PM, Miguel Ojeda wrote: > On Sat, Dec 12, 2020 at 5:18 PM Guenter Roeck wrote: >> >> This patch results in: >> >> arch/sh/kernel/cpu/sh4a/smp-shx3.c: In function 'shx3_prepare_cpus': >> arch/sh/kernel/cpu/sh4a/smp-shx3.c:76:3: error: ignoring return value of >> 'request_irq' declared with attribute 'warn_unused_result' >> >> when building sh:defconfig. Checking for calls to request_irq() >> suggests that there will be other similar errors in various builds. >> Reverting the patch fixes the problem. > > Which ones? From a quick grep and some filtering I could only find one > file with wrong usage apart from this one: > > drivers/net/ethernet/lantiq_etop.c: > request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv); > drivers/net/ethernet/lantiq_etop.c: > request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv); > > Of course, this does not cover other functions, but it means there > aren't many issues and/or people building the code if nobody complains > within a few weeks. So I think we can fix them as they come. > Witz komm raus, Du bist umzingelt. The key here is "if nobody complains". I would argue that it is _your_ responsibility to do those builds, and not the reponsibility of others to do it for you. But, sure, your call. Please feel free to ignore my report. Guenter
Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
On Sun, Nov 29, 2020 at 04:33:35AM +0900, Masahiro Yamada wrote:
> Revert commit cebc04ba9aeb ("add CONFIG_ENABLE_MUST_CHECK").
>
> A lot of warn_unused_result warnings existed in 2006, but until now
> they have been fixed thanks to people doing allmodconfig tests.
>
> Our goal is to always enable __must_check where appropriate, so this
> CONFIG option is no longer needed.
>
> I see a lot of defconfig (arch/*/configs/*_defconfig) files having:
>
> # CONFIG_ENABLE_MUST_CHECK is not set
>
> I did not touch them for now since it would be a big churn. If arch
> maintainers want to clean them up, please go ahead.
>
> While I was here, I also moved __must_check to compiler_attributes.h
> from compiler_types.h
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Jason A. Donenfeld
> Acked-by: Nathan Chancellor
> Reviewed-by: Nick Desaulniers
This patch results in:
arch/sh/kernel/cpu/sh4a/smp-shx3.c: In function 'shx3_prepare_cpus':
arch/sh/kernel/cpu/sh4a/smp-shx3.c:76:3: error: ignoring return value of
'request_irq' declared with attribute 'warn_unused_result'
when building sh:defconfig. Checking for calls to request_irq()
suggests that there will be other similar errors in various builds.
Reverting the patch fixes the problem.
Guenter
Re: [PATCH v2 0/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring
On Wed, Nov 18, 2020 at 05:01:19PM -0800, Guenter Roeck wrote: > On Wed, Nov 18, 2020 at 03:42:53PM -0800, Tao Ren wrote: > > On Thu, Nov 19, 2020 at 12:27:19AM +0100, Andrew Lunn wrote: > > > On Wed, Nov 18, 2020 at 03:09:27PM -0800, rentao.b...@gmail.com wrote: > > > > From: Tao Ren > > > > > > > > The patch series adds hardware monitoring driver for the Maxim MAX127 > > > > chip. > > > > > > Hi Tao > > > > > > Why are using sending a hwmon driver to the networking mailing list? > > > > > > Andrew > > > > Hi Andrew, > > > > I added netdev because the mailing list is included in "get_maintainer.pl > > Documentation/hwmon/index.rst" output. Is it the right command to find > > reviewers? Could you please suggest? Thank you. > > I have no idea why running get_maintainer.pl on > Documentation/hwmon/index.rst returns such a large list of mailing > lists and people. For some reason it includes everyone in the XDP > maintainer list. If anyone has an idea how that happens, please > let me know - we'll want to get this fixed to avoid the same problem > in the future. > I found it. The XDP maintainer entry has: K:xdp This matches Documentation/hwmon/index.rst. $ grep xdp Documentation/hwmon/index.rst xdpe12284 It seems to me that a context match such as "xdp" in MAINTAINERS isn't really appropriate. "xdp" matches a total of 348 files in the kernel. The large majority of those is not XDP related. The maintainers of XDP (and all the listed mailing lists) should not be surprised to get a large number of odd review requests if they want to review every single patch on files which include the term "xdp". Guenter
Re: [PATCH v2 0/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring
On Wed, Nov 18, 2020 at 03:42:53PM -0800, Tao Ren wrote: > On Thu, Nov 19, 2020 at 12:27:19AM +0100, Andrew Lunn wrote: > > On Wed, Nov 18, 2020 at 03:09:27PM -0800, rentao.b...@gmail.com wrote: > > > From: Tao Ren > > > > > > The patch series adds hardware monitoring driver for the Maxim MAX127 > > > chip. > > > > Hi Tao > > > > Why are using sending a hwmon driver to the networking mailing list? > > > > Andrew > > Hi Andrew, > > I added netdev because the mailing list is included in "get_maintainer.pl > Documentation/hwmon/index.rst" output. Is it the right command to find > reviewers? Could you please suggest? Thank you. I have no idea why running get_maintainer.pl on Documentation/hwmon/index.rst returns such a large list of mailing lists and people. For some reason it includes everyone in the XDP maintainer list. If anyone has an idea how that happens, please let me know - we'll want to get this fixed to avoid the same problem in the future. Guenter
Re: [PATCH 1/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring driver
On Mon, Nov 16, 2020 at 05:09:43PM -0800, rentao.b...@gmail.com wrote:
> From: Tao Ren
>
> Add hardware monitoring driver for the Maxim MAX127 chip.
>
> MAX127 min/max range handling code is inspired by the max197 driver.
>
> Signed-off-by: Tao Ren
> ---
> drivers/hwmon/Kconfig | 9 ++
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/max127.c | 286 +
> 3 files changed, 296 insertions(+)
> create mode 100644 drivers/hwmon/max127.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 9d600e0c5584..716df51edc87 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -950,6 +950,15 @@ config SENSORS_MAX
> This driver can also be built as a module. If so, the module
> will be called max.
>
> +config SENSORS_MAX127
> + tristate "Maxim MAX127 12-bit 8-channel Data Acquisition System"
> + depends on I2C
> + help
> + Say y here to support Maxim's MAX127 DAS chips.
> +
> + This driver can also be built as a module. If so, the module
> + will be called max127.
> +
> config SENSORS_MAX16065
> tristate "Maxim MAX16065 System Manager and compatibles"
> depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 1083bbfac779..01ca5d3fbad4 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -127,6 +127,7 @@ obj-$(CONFIG_SENSORS_LTC4260) += ltc4260.o
> obj-$(CONFIG_SENSORS_LTC4261)+= ltc4261.o
> obj-$(CONFIG_SENSORS_LTQ_CPUTEMP) += ltq-cputemp.o
> obj-$(CONFIG_SENSORS_MAX)+= max.o
> +obj-$(CONFIG_SENSORS_MAX127) += max127.o
> obj-$(CONFIG_SENSORS_MAX16065) += max16065.o
> obj-$(CONFIG_SENSORS_MAX1619)+= max1619.o
> obj-$(CONFIG_SENSORS_MAX1668)+= max1668.o
> diff --git a/drivers/hwmon/max127.c b/drivers/hwmon/max127.c
> new file mode 100644
> index ..df74a95bcf28
> --- /dev/null
> +++ b/drivers/hwmon/max127.c
> @@ -0,0 +1,286 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Hardware monitoring driver for MAX127.
> + *
> + * Copyright (c) 2020 Facebook Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* MAX127 Control Byte. */
> +#define MAX127_CTRL_STARTBIT(7)
> +#define MAX127_CTRL_SEL_OFFSET 4
That would better be named _SHIFT.
> +#define MAX127_CTRL_RNG BIT(3)
> +#define MAX127_CTRL_BIP BIT(2)
> +#define MAX127_CTRL_PD1 BIT(1)
> +#define MAX127_CTRL_PD0 BIT(0)
> +
> +#define MAX127_NUM_CHANNELS 8
> +#define MAX127_SET_CHANNEL(ch) (((ch) & 7) << (MAX127_CTRL_SEL_OFFSET))
() around MAX127_CTRL_SEL_OFFSET is unnecessary.
> +
> +#define MAX127_INPUT_LIMIT 10 /* 10V */
> +
> +/*
> + * MAX127 returns 2 bytes at read:
> + * - the first byte contains data[11:4].
> + * - the second byte contains data[3:0] (MSB) and 4 dummy 0s (LSB).
> + */
> +#define MAX127_DATA1_SHIFT 4
> +
> +struct max127_data {
> + struct mutex lock;
> + struct i2c_client *client;
> + int input_limit;
> + u8 ctrl_byte[MAX127_NUM_CHANNELS];
> +};
> +
> +static int max127_select_channel(struct max127_data *data, int channel)
> +{
> + int status;
> + struct i2c_client *client = data->client;
> + struct i2c_msg msg = {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = &data->ctrl_byte[channel],
> + };
> +
> + status = i2c_transfer(client->adapter, &msg, 1);
> + if (status != 1)
> + return status;
> +
Other drivers assume that this function can return 0. Please
take that into account as well.
> + return 0;
> +}
> +
> +static int max127_read_channel(struct max127_data *data, int channel, u16
> *vin)
> +{
> + int status;
> + u8 i2c_data[2];
> + struct i2c_client *client = data->client;
> + struct i2c_msg msg = {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = 2,
> + .buf = i2c_data,
> + };
> +
> + status = i2c_transfer(client->adapter, &msg, 1);
> + if (status != 1)
> + return status;
Same as above.
> +
> + *vin = ((i2c_data[0] << 8) | i2c_data[1]) >> MAX127_DATA1_SHIFT;
THis seems wrong. D4..D11 end up in but 8..15, and D0..D3 end up in bit
0..3. Seems to me the upper byte should be left shifted 4 bit.
The result then needs to be scaled to mV (see below).
Also, for consistency I would suggest to either use () for both
parts of the logical or operation or for none.
> + return 0;
> +}
> +
> +static ssize_t max127_input_show(struct device *dev,
> + struct device_attribute *dev_attr,
> + char *buf)
> +{
> + u16 vin;
> + int status;
> + struct max127_data *data = dev_get_drvdata(dev);
> + struct sensor_device_attribute *attr = to_sensor_dev_at
Re: [PATCH] hwmon: pmbus: shrink code and remove pmbus_do_remove()
On Mon, Oct 26, 2020 at 11:53:52AM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The only action currently performed in pmbus_do_remove() is removing the
> debugfs hierarchy. We can schedule a devm action at probe time and remove
> pmbus_do_remove() entirely from all pmbus drivers.
>
> Signed-off-by: Bartosz Golaszewski
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/pmbus/adm1266.c | 1 -
> drivers/hwmon/pmbus/adm1275.c | 1 -
> drivers/hwmon/pmbus/bel-pfe.c | 1 -
> drivers/hwmon/pmbus/ibm-cffps.c| 1 -
> drivers/hwmon/pmbus/inspur-ipsps.c | 1 -
> drivers/hwmon/pmbus/ir35221.c | 1 -
> drivers/hwmon/pmbus/ir38064.c | 1 -
> drivers/hwmon/pmbus/irps5401.c | 1 -
> drivers/hwmon/pmbus/isl68137.c | 1 -
> drivers/hwmon/pmbus/lm25066.c | 1 -
> drivers/hwmon/pmbus/ltc2978.c | 1 -
> drivers/hwmon/pmbus/ltc3815.c | 1 -
> drivers/hwmon/pmbus/max16064.c | 1 -
> drivers/hwmon/pmbus/max16601.c | 1 -
> drivers/hwmon/pmbus/max20730.c | 1 -
> drivers/hwmon/pmbus/max20751.c | 1 -
> drivers/hwmon/pmbus/max31785.c | 1 -
> drivers/hwmon/pmbus/max34440.c | 1 -
> drivers/hwmon/pmbus/max8688.c | 1 -
> drivers/hwmon/pmbus/mp2975.c | 1 -
> drivers/hwmon/pmbus/pmbus.c| 1 -
> drivers/hwmon/pmbus/pmbus.h| 1 -
> drivers/hwmon/pmbus/pmbus_core.c | 20 +---
> drivers/hwmon/pmbus/pxe1610.c | 1 -
> drivers/hwmon/pmbus/tps40422.c | 1 -
> drivers/hwmon/pmbus/tps53679.c | 1 -
> drivers/hwmon/pmbus/ucd9000.c | 1 -
> drivers/hwmon/pmbus/ucd9200.c | 1 -
> drivers/hwmon/pmbus/xdpe12284.c| 1 -
> drivers/hwmon/pmbus/zl6100.c | 1 -
> 30 files changed, 9 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/hwmon/pmbus/adm1266.c b/drivers/hwmon/pmbus/adm1266.c
> index c7b373ba92f2..4d2e4ddcfbfd 100644
> --- a/drivers/hwmon/pmbus/adm1266.c
> +++ b/drivers/hwmon/pmbus/adm1266.c
> @@ -502,7 +502,6 @@ static struct i2c_driver adm1266_driver = {
> .of_match_table = adm1266_of_match,
> },
> .probe_new = adm1266_probe,
> - .remove = pmbus_do_remove,
> .id_table = adm1266_id,
> };
>
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index e7997f37b266..38a6515b0763 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
> @@ -797,7 +797,6 @@ static struct i2c_driver adm1275_driver = {
> .name = "adm1275",
> },
> .probe_new = adm1275_probe,
> - .remove = pmbus_do_remove,
> .id_table = adm1275_id,
> };
>
> diff --git a/drivers/hwmon/pmbus/bel-pfe.c b/drivers/hwmon/pmbus/bel-pfe.c
> index 2c5b853d6c7f..aed7542d7ce5 100644
> --- a/drivers/hwmon/pmbus/bel-pfe.c
> +++ b/drivers/hwmon/pmbus/bel-pfe.c
> @@ -121,7 +121,6 @@ static struct i2c_driver pfe_pmbus_driver = {
> .name = "bel-pfe",
> },
> .probe_new = pfe_pmbus_probe,
> - .remove = pmbus_do_remove,
> .id_table = pfe_device_id,
> };
>
> diff --git a/drivers/hwmon/pmbus/ibm-cffps.c b/drivers/hwmon/pmbus/ibm-cffps.c
> index 2fb7540ee952..d6223871 100644
> --- a/drivers/hwmon/pmbus/ibm-cffps.c
> +++ b/drivers/hwmon/pmbus/ibm-cffps.c
> @@ -617,7 +617,6 @@ static struct i2c_driver ibm_cffps_driver = {
> .of_match_table = ibm_cffps_of_match,
> },
> .probe_new = ibm_cffps_probe,
> - .remove = pmbus_do_remove,
> .id_table = ibm_cffps_id,
> };
>
> diff --git a/drivers/hwmon/pmbus/inspur-ipsps.c
> b/drivers/hwmon/pmbus/inspur-ipsps.c
> index be493182174d..88c5865c4d6f 100644
> --- a/drivers/hwmon/pmbus/inspur-ipsps.c
> +++ b/drivers/hwmon/pmbus/inspur-ipsps.c
> @@ -216,7 +216,6 @@ static struct i2c_driver ipsps_driver = {
> .of_match_table = of_match_ptr(ipsps_of_match),
> },
> .probe_new = ipsps_probe,
> - .remove = pmbus_do_remove,
> .id_table = ipsps_id,
> };
>
> diff --git a/drivers/hwmon/pmbus/ir35221.c b/drivers/hwmon/pmbus/ir35221.c
> index 5fadb1def49f..3aebeb1443fd 100644
> --- a/drivers/hwmon/pmbus/ir35221.c
> +++ b/drivers/hwmon/pmbus/ir35221.c
> @@ -137,7 +137,6 @@ static struct i2c_driver ir35221_driver = {
> .name = "ir35221",
> },
> .probe_new = ir35221_probe,
> - .remove = pmbus_do_remove,
> .id_table = ir35221_id,
> };
>
> diff --git a/drivers/hwmon/pmbus/ir38064.c b/drivers/hwmon/pmbus/ir38064.c
> index 9ac563ce7dd8..46f17c4b4873 100644
> --- a/drivers/hwmon/pmbus/ir38064.c
> +++ b/drivers/hwmon/pmbus/ir38064.c
> @@ -53,7 +53,6 @@ static struct i2c_driver ir38064_driver = {
> .name = "ir38064",
> },
> .probe_new = ir38064_probe,
> - .remove = pmbus_do_remove,
> .id_table = ir38064_id,
> };
>
> diff --git a/drivers/hwmon/pmbus/irps5401.c b/drivers/hwmon/pmbus/irps5401.c
> index
Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
On 10/2/20 4:41 PM, Rob Herring wrote: > Another round of wack-a-mole. The json-schema default is additional > unknown properties are allowed, but for DT all properties should be > defined. > > Cc: Thierry Reding > Cc: Linus Walleij > Cc: Stephen Boyd > Cc: Shawn Guo > Cc: Bjorn Andersson > Cc: Baolin Wang > Cc: Guenter Roeck > Cc: Jonathan Cameron > Cc: Mauro Carvalho Chehab > Cc: Laurent Pinchart > Cc: Lee Jones > Cc: Ulf Hansson > Cc: "David S. Miller" > Cc: Bjorn Helgaas > Cc: Vinod Koul > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Greg Kroah-Hartman > Cc: Daniel Lezcano > Cc: linux-...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-hw...@vger.kernel.org For hwmon: Reviewed-by: Guenter Roeck > Cc: linux-...@vger.kernel.org > Cc: openipmi-develo...@lists.sourceforge.net > Cc: linux-l...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-m...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: netdev@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-remotep...@vger.kernel.org > Cc: linux-ser...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring > --- > > I'll take this thru the DT tree. > > .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 2 ++ > .../arm/mediatek/mediatek,pericfg.yaml| 2 ++ > .../devicetree/bindings/arm/pmu.yaml | 2 ++ > .../devicetree/bindings/arm/primecell.yaml| 3 +++ > .../bindings/arm/samsung/sysreg.yaml | 2 ++ > .../arm/tegra/nvidia,tegra20-pmc.yaml | 2 ++ > .../bindings/bus/mti,mips-cdmm.yaml | 2 ++ > .../bus/socionext,uniphier-system-bus.yaml| 7 +++ > .../bindings/clock/arm,syscon-icst.yaml | 2 ++ > .../bindings/clock/idt,versaclock5.yaml | 20 ++- > .../bindings/clock/imx6q-clock.yaml | 2 ++ > .../bindings/clock/imx6sl-clock.yaml | 2 ++ > .../bindings/clock/imx6sll-clock.yaml | 2 ++ > .../bindings/clock/imx6sx-clock.yaml | 2 ++ > .../bindings/clock/imx6ul-clock.yaml | 2 ++ > .../bindings/clock/intel,cgu-lgm.yaml | 2 ++ > .../bindings/clock/qcom,gcc-sm8250.yaml | 2 ++ > .../bindings/clock/sprd,sc9863a-clk.yaml | 2 ++ > .../bindings/clock/ti,am654-ehrpwm-tbclk.yaml | 2 ++ > .../bindings/display/bridge/ite,it6505.yaml | 5 + > .../bindings/display/bridge/lvds-codec.yaml | 3 +++ > .../devicetree/bindings/display/msm/gmu.yaml | 2 ++ > .../devicetree/bindings/edac/dmc-520.yaml | 2 ++ > .../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 2 ++ > .../gpio/socionext,uniphier-gpio.yaml | 2 ++ > .../bindings/hwmon/adi,axi-fan-control.yaml | 2 ++ > .../devicetree/bindings/hwmon/adt7475.yaml| 2 ++ > .../bindings/iio/accel/kionix,kxsd9.yaml | 4 > .../bindings/iio/adc/maxim,max1238.yaml | 2 ++ > .../bindings/iio/adc/maxim,max1363.yaml | 2 ++ > .../bindings/iio/adc/qcom,spmi-vadc.yaml | 4 > .../bindings/iio/adc/samsung,exynos-adc.yaml | 2 ++ > .../bindings/iio/adc/ti,ads8688.yaml | 4 > .../bindings/iio/amplifiers/adi,hmc425a.yaml | 2 ++ > .../bindings/iio/imu/invensense,icm42600.yaml | 6 ++ > .../bindings/iio/light/amstaos,tsl2563.yaml | 2 ++ > .../bindings/iio/light/dynaimage,al3010.yaml | 2 ++ > .../bindings/iio/light/dynaimage,al3320a.yaml | 2 ++ > .../bindings/iio/light/sharp,gp2ap002.yaml| 2 ++ > .../iio/magnetometer/asahi-kasei,ak8975.yaml | 2 ++ > .../iio/proximity/vishay,vcnl3020.yaml| 2 ++ > .../interrupt-controller/ingenic,intc.yaml| 2 ++ > .../loongson,pch-msi.yaml | 2 ++ > .../loongson,pch-pic.yaml | 2 ++ > .../devicetree/bindings/ipmi/ipmi-smic.yaml | 2 ++ > .../devicetree/bindings/leds/leds-lp55xx.yaml | 8 > .../bindings/media/i2c/chrontel,ch7322.yaml | 2 ++ > .../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 2 ++ > .../bindings/media/nxp,imx8mq-vpu.yaml| 2 ++ > .../bindings/media/qcom,msm8916-venus.yaml| 2 ++ > .../bindings/media/qcom,msm8996-venus.yaml| 2 ++ > .../bindings/media/qcom,sc7180-venus.yaml | 2 ++ > .../bindings/media/qcom,sdm845-venus-v2.yaml | 2 ++ > .../bindings/media/qcom,sdm845-venus.yaml | 2 ++ > .../bindings/memory-controllers/fsl/mmdc.yaml | 2 ++ > .../memory-controllers/st,stm32-fmc2-ebi.yaml | 2 ++ > .../bindi
skb_under_panic with corrupt (?) head/data pointers
Hi, we are seeing situations where skb_under_panic is reported with bad data pointers. A recent example is [1], but we have seen more of the same. Some random examples: skb_under_panic: text:39ea4f04 len:272 put:48 head:bdd3f564 data:f70d12b8 tail:0x102 end:0x2c0 dev:wlan0 skb_under_panic: text:63ae0b92 len:822 put:48 head:4ae66619 data:82f8ca57 tail:0x328 end:0x6c0 dev:wlan0 skb_under_panic: text:56205094 len:272 put:48 head:3aad43d6 data:e8cd088c tail:0x102 end:0x2c0 dev:wlan0 skb_under_panic: text:413c3f8c len:368 put:48 head:ddd1266f data:f13009ae tail:0x162 end:0x2c0 dev:wlan0 skb_under_panic: text:917c4645 len:520 put:48 head:7108f7f3 data:3d260246 tail:0x1fa end:0x6c0 dev:wlan0 This specific condition happens rarely; we do see lots of 'normal' skb_under_panic crashes (with valid head and data pointers) in the same driver. I would assume that the skbs are corrupted, but then I noticed a similar pattern in some kernel commit logs. commit 7901cd97963d: skb_under_panic: text:ca46ad8a len:80 put:20 head:cd28494e data:9366fd6b tail:0x3c end:0xec0 dev:veth0 commit 7901cd97963d: skb_under_panic: text:1d390b3a len:31 put:24 head:d8ed776f data:8150e823 tail:0x7 end:0xc0 dev:gre0 Is there some situation where skb->head and possibly skb->data may not be initialized correctly ? Thanks, Guenter --- [1] https://www.spinics.net/lists/linux-wireless/msg200403.html
Re: [PATCH NET] net: atlantic: Use readx_poll_timeout() for large timeout
On Tue, Aug 18, 2020 at 06:14:39PM +0200, Sebastian Andrzej Siewior wrote:
> Commit
>8dcf2ad39fdb2 ("net: atlantic: add hwmon getter for MAC temperature")
>
> implemented a read callback with an udelay(1U). This fails to
> compile on ARM because the delay is >1ms. I doubt that it is needed to
> spin for 10ms even if possible on x86.
>
> >From looking at the code, the context appears to be preemptible so using
> usleep() should work and avoid busy spinning.
>
> Use readx_poll_timeout() in the poll loop.
>
> Cc: Mark Starovoytov
> Cc: Igor Russkikh
> Signed-off-by: Sebastian Andrzej Siewior
Fixes: 8dcf2ad39fdb2 ("net: atlantic: add hwmon getter for MAC temperature")
Acked-by: Guenter Roeck
As in: This patch does not cause any additional trouble and will fix the
observed compile failure. However, the submitter of 8dcf2ad39fdb2 might
consider adding a mutex either into hw_atl_b0_get_mac_temp() or into
the calling code.
Thanks,
Guenter
> ---
>
> Could someone with hardware please verify it? It compiles, yes.
>
> drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
> b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
> index 16a944707ba90..8941ac4df9e37 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
> @@ -1631,8 +1631,8 @@ static int hw_atl_b0_get_mac_temp(struct aq_hw_s *self,
> u32 *temp)
> hw_atl_ts_reset_set(self, 0);
> }
>
> - err = readx_poll_timeout_atomic(hw_atl_b0_ts_ready_and_latch_high_get,
> - self, val, val == 1, 1U, 50U);
> + err = readx_poll_timeout(hw_atl_b0_ts_ready_and_latch_high_get, self,
> + val, val == 1, 1U, 50U);
> if (err)
> return err;
>
> --
> 2.28.0
>
Re: [PATCH net] sfc: fix ef100 design-param checking
On Wed, Aug 12, 2020 at 10:32:49AM +0100, Edward Cree wrote:
> The handling of the RXQ/TXQ size granularity design-params had two
> problems: it had a 64-bit divide that didn't build on 32-bit platforms,
> and it could divide by zero if the NIC supplied 0 as the value of the
> design-param. Fix both by checking for 0 and for a granularity bigger
> than our min-size; if the granularity <= EFX_MIN_DMAQ_SIZE then it fits
> in 32 bits, so we can cast it to u32 for the divide.
>
> Reported-by: kernel test robot
> Signed-off-by: Edward Cree
Reviewed-by: Guenter Roeck
> ---
> I've only build-tested this, and then only on 64-bit, since our lab's
> cooling system can't cope with the heatwave and we keep having to shut
> everything down :(
>
> drivers/net/ethernet/sfc/ef100_nic.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/sfc/ef100_nic.c
> b/drivers/net/ethernet/sfc/ef100_nic.c
> index 36598d0542ed..206d70f9d95b 100644
> --- a/drivers/net/ethernet/sfc/ef100_nic.c
> +++ b/drivers/net/ethernet/sfc/ef100_nic.c
> @@ -979,7 +979,8 @@ static int ef100_process_design_param(struct efx_nic *efx,
>* EFX_MIN_DMAQ_SIZE is divisible by GRANULARITY.
>* This is very unlikely to fail.
>*/
> - if (EFX_MIN_DMAQ_SIZE % reader->value) {
> + if (!reader->value || reader->value > EFX_MIN_DMAQ_SIZE ||
> + EFX_MIN_DMAQ_SIZE % (u32)reader->value) {
> netif_err(efx, probe, efx->net_dev,
> "%s size granularity is %llu, can't guarantee
> safety\n",
> reader->type ==
> ESE_EF100_DP_GZ_RXQ_SIZE_GRANULARITY ? "RXQ" : "TXQ",
Re: [linux-next:master 13398/13940] drivers/net/ethernet/sfc/ef100_nic.c:610: undefined reference to `__umoddi3'
On Thu, Aug 06, 2020 at 07:17:43PM +0100, Edward Cree wrote:
> On 06/08/2020 00:48, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > master
> > head: d15fe4ec043588beee823781602ddb51d0bc84c8
> > commit: adcfc3482813fa2c34e5902005853f79c2aa [13398/13940] sfc_ef100:
> > read Design Parameters at probe time
> > config: microblaze-randconfig-r032-20200805 (attached as .config)
> > compiler: microblaze-linux-gcc (GCC) 9.3.0
> > reproduce (this is a W=1 build):
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout adcfc3482813fa2c34e5902005853f79c2aa
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> > ARCH=microblaze
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> >
> > All errors (new ones prefixed by >>):
> >
> >microblaze-linux-ld: drivers/net/ethernet/sfc/ef100_nic.o: in function
> > `ef100_process_design_param':
> >>> drivers/net/ethernet/sfc/ef100_nic.c:610: undefined reference to
> >>> `__umoddi3'
> >605 /* Our TXQ and RXQ sizes are always
> > power-of-two and thus divisible by
> >606 * EFX_MIN_DMAQ_SIZE, so we just need to check
> > that
> >607 * EFX_MIN_DMAQ_SIZE is divisible by
> > GRANULARITY.
> >608 * This is very unlikely to fail.
> >609 */
> > > 610 if (EFX_MIN_DMAQ_SIZE % reader->value) {
> So, this is (unsigned long) % (u64), whichI guess doesn't go quite
> as smoothly 32-bit microcontrollers (though the thought of plugging
> a 100-gig smartNIC into a microblaze boggles the mind a little ;).
> And none of the math64.h functions seem to have the shape we want —
> div_u64_rem() wants to write the remainder through a pointer, and
> do_div() wants to modify the dividend (which is a constant in this
> case). So whatever I do, it's gonna be ugly :(
>
> Maybe I should add a
>
> static inline u32 mod_u64(u64 dividend, u32 divisor)
> {
> return do_div(dividend, divisor);
> }
Your proposed function is an exact replicate of do_div() and thus doesn't
make much sense. Also, in your case, divisor is a 64-bit value, which is
causing the problem to start with. You could try something like
if (reader->value > EFX_MIN_DMAQ_SIZE || EFX_MIN_DMAQ_SIZE %
(u32)reader->value)
If EFX_MIN_DMAQ_SIZE is indeed known to be a power of 2, you could also use
the knowledge that a 2^n value can only be divided by a smaller 2^n value,
meaning that reader->value must have exactly one bit set. This would also
avoid divide-by-0 issues if reader->value can be 0.
if (reader->value > EFX_MIN_DMAQ_SIZE || hweight64(reader->value) != 1)
Guenter
Re: [PATCH v3 net-next 03/11] sfc_ef100: read Design Parameters at probe time
On Mon, Aug 10, 2020 at 09:15:20AM +0100, Edward Cree wrote:
> On 09/08/2020 01:29, Guenter Roeck wrote:
> > On Mon, Aug 03, 2020 at 09:33:20PM +0100, Edward Cree wrote:
> >> + if (EFX_MIN_DMAQ_SIZE % reader->value) {
> > This is a 64-bit operation (value is 64 bit). Result on 32-bit builds:
> >
> > ERROR: modpost: "__umoddi3" [drivers/net/ethernet/sfc/sfc.ko] undefined!
> >
> > Guenter
> Yep, kbuild robot already spotted this, and I'm trying to figureout
> the cleanest way to deal with it.
> See
> https://lore.kernel.org/netdev/487d9159-41f8-2757-2e93-01426a527...@solarflare.com/
> Any advice would be welcome...
>
Answered there.
Guenter
Re: [PATCH v3 net-next 03/11] sfc_ef100: read Design Parameters at probe time
On Mon, Aug 03, 2020 at 09:33:20PM +0100, Edward Cree wrote:
> Several parts of the EF100 architecture are parameterised (to allow
> varying capabilities on FPGAs according to resource constraints), and
> these parameters are exposed to the driver through a TLV-encoded
> region of the BAR.
> For the most part we either don't care about these values at all or
> just need to sanity-check them against the driver's assumptions, but
> there are a number of TSO limits which we record so that we will be
> able to check against them in the TX path when handling GSO skbs.
>
> Signed-off-by: Edward Cree
> ---
> drivers/net/ethernet/sfc/ef100_nic.c | 216 +++
> drivers/net/ethernet/sfc/ef100_nic.h | 4 +
> 2 files changed, 220 insertions(+)
>
> diff --git a/drivers/net/ethernet/sfc/ef100_nic.c
> b/drivers/net/ethernet/sfc/ef100_nic.c
> index c2bec2bdbc1f..9b5e4b42fe51 100644
> --- a/drivers/net/ethernet/sfc/ef100_nic.c
> +++ b/drivers/net/ethernet/sfc/ef100_nic.c
[ ... ]
> + if (EFX_MIN_DMAQ_SIZE % reader->value) {
This is a 64-bit operation (value is 64 bit). Result on 32-bit builds:
ERROR: modpost: "__umoddi3" [drivers/net/ethernet/sfc/sfc.ko] undefined!
Guenter
Re: [PATCH 16/20] dt-bindings: watchdog: renesas,wdt: Document r8a774e1 support
On Wed, Jul 15, 2020 at 12:09:06PM +0100, Lad Prabhakar wrote: > RZ/G2H (a.k.a. R8A774E1) watchdog implementation is compatible > with R-Car Gen3, therefore add the relevant documentation. > > Signed-off-by: Lad Prabhakar > Reviewed-by: Geert Uytterhoeven Reviewed-by: Guenter Roeck > --- > Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml > b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml > index 572f4c912fef..6933005b52bd 100644 > --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml > +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml > @@ -41,6 +41,7 @@ properties: >- renesas,r8a774a1-wdt # RZ/G2M >- renesas,r8a774b1-wdt # RZ/G2N >- renesas,r8a774c0-wdt # RZ/G2E > + - renesas,r8a774e1-wdt # RZ/G2H >- renesas,r8a7795-wdt # R-Car H3 >- renesas,r8a7796-wdt # R-Car M3-W >- renesas,r8a77961-wdt # R-Car M3-W+
Re: [Patch net v2] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
On Thu, Jul 09, 2020 at 11:59:09AM -0700, Cong Wang wrote: > On Thu, Jul 9, 2020 at 11:51 AM Cong Wang wrote: > > > > On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote: > > > > > > Something seems fishy with the use of skcd->val on big endian systems. > > > > > > Some debug output: > > > > > > [ 22.643703] sock: # sk_alloc(sk=1be28100): Calling > > > cgroup_sk_alloc(1be28550) > > > [ 22.643807] cgroup: # cgroup_sk_alloc(skcd=1be28550): > > > cgroup_sk_alloc_disabled=0, in_interrupt: 0 > > > [ 22.643886] cgroup: cgroup_sk_alloc(skcd=1be28550): > > > cset->dfl_cgrp=01224040, skcd->val=0x1224040 > > > [ 22.643957] cgroup: ## cgroup_bpf_get(cgrp=01224040) > > > [ 22.646451] sock: # sk_prot_free(sk=1be28100): Calling > > > cgroup_sk_free(1be28550) > > > [ 22.646607] cgroup: sock_cgroup_ptr(skcd=1be28550) -> > > > 00014040 [v=14040, skcd->val=14040] > > > [ 22.646632] cgroup: ### cgroup_sk_free(): skcd=1be28550, > > > cgrp=00014040 > > > [ 22.646739] cgroup: ### cgroup_sk_free(): skcd->no_refcnt=0 > > > [ 22.646814] cgroup: ### cgroup_sk_free(): Calling > > > cgroup_bpf_put(cgrp=00014040) > > > [ 22.646886] cgroup: ## cgroup_bpf_put(cgrp=00014040) > > > > Excellent debugging! I thought it was a double put, but it seems to > > be an endian issue. I didn't realize the bit endian machine actually > > packs bitfields in a big endian way too... > > > > Does the attached patch address this? > > Ah, this is too ugly. We just have to always make them the last two bits. > > Please test this attached patch instead and ignore the previous one. > FWIW: Tested and working. Guenter
Re: [Patch net v2] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
On Thu, Jul 09, 2020 at 11:59:09AM -0700, Cong Wang wrote: > On Thu, Jul 9, 2020 at 11:51 AM Cong Wang wrote: > > > > On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote: > > > > > > Something seems fishy with the use of skcd->val on big endian systems. > > > > > > Some debug output: > > > > > > [ 22.643703] sock: # sk_alloc(sk=1be28100): Calling > > > cgroup_sk_alloc(1be28550) > > > [ 22.643807] cgroup: # cgroup_sk_alloc(skcd=1be28550): > > > cgroup_sk_alloc_disabled=0, in_interrupt: 0 > > > [ 22.643886] cgroup: cgroup_sk_alloc(skcd=1be28550): > > > cset->dfl_cgrp=01224040, skcd->val=0x1224040 > > > [ 22.643957] cgroup: ## cgroup_bpf_get(cgrp=01224040) > > > [ 22.646451] sock: # sk_prot_free(sk=1be28100): Calling > > > cgroup_sk_free(1be28550) > > > [ 22.646607] cgroup: sock_cgroup_ptr(skcd=1be28550) -> > > > 00014040 [v=14040, skcd->val=14040] > > > [ 22.646632] cgroup: ### cgroup_sk_free(): skcd=1be28550, > > > cgrp=00014040 > > > [ 22.646739] cgroup: ### cgroup_sk_free(): skcd->no_refcnt=0 > > > [ 22.646814] cgroup: ### cgroup_sk_free(): Calling > > > cgroup_bpf_put(cgrp=00014040) > > > [ 22.646886] cgroup: ## cgroup_bpf_put(cgrp=00014040) > > > > Excellent debugging! I thought it was a double put, but it seems to > > be an endian issue. I didn't realize the bit endian machine actually > > packs bitfields in a big endian way too... > > > > Does the attached patch address this? > > Ah, this is too ugly. We just have to always make them the last two bits. > > Please test this attached patch instead and ignore the previous one. > Sorry, that one came too late; I was already about to leave when I got the first one. It looks correct, though. I'll be back Monday night and will have another look then (and I guess my builders will pick it up after Dave sends it all to Linus). I'll let you know if I still see a problem. Thanks, Guenter
Re: [Patch net v2] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
On 7/9/20 11:51 AM, Cong Wang wrote: > On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote: >> >> Something seems fishy with the use of skcd->val on big endian systems. >> >> Some debug output: >> >> [ 22.643703] sock: # sk_alloc(sk=1be28100): Calling >> cgroup_sk_alloc(1be28550) >> [ 22.643807] cgroup: # cgroup_sk_alloc(skcd=1be28550): >> cgroup_sk_alloc_disabled=0, in_interrupt: 0 >> [ 22.643886] cgroup: cgroup_sk_alloc(skcd=1be28550): >> cset->dfl_cgrp=01224040, skcd->val=0x1224040 >> [ 22.643957] cgroup: ## cgroup_bpf_get(cgrp=01224040) >> [ 22.646451] sock: # sk_prot_free(sk=1be28100): Calling >> cgroup_sk_free(1be28550) >> [ 22.646607] cgroup: sock_cgroup_ptr(skcd=1be28550) -> >> 00014040 [v=14040, skcd->val=14040] >> [ 22.646632] cgroup: ### cgroup_sk_free(): skcd=1be28550, >> cgrp=00014040 >> [ 22.646739] cgroup: ### cgroup_sk_free(): skcd->no_refcnt=0 >> [ 22.646814] cgroup: ### cgroup_sk_free(): Calling >> cgroup_bpf_put(cgrp=00014040) >> [ 22.646886] cgroup: ## cgroup_bpf_put(cgrp=00014040) > > Excellent debugging! I thought it was a double put, but it seems to > be an endian issue. I didn't realize the bit endian machine actually > packs bitfields in a big endian way too... > > Does the attached patch address this? > Partially. I don't see the crash anymore, but something is still odd - some of my tests require a retry with this patch applied, which previously never happened. I don't know if this is another problem with this patch, or a different problem. Unfortunately, I'll be unable to debug this further until next Tuesday. Guenter
Re: [Patch net v2] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
On 7/8/20 12:32 PM, Cong Wang wrote: > On Wed, Jul 8, 2020 at 12:07 PM Guenter Roeck wrote: >> >> On 7/8/20 11:34 AM, Cong Wang wrote: >>> Hi, >>> >>> On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote: >>>> This patch causes all my s390 boot tests to crash. Reverting it fixes >>>> the problem. Please see bisect results and and crash log below. >>>> >>> ... >>>> Crash log: >>> >>> Interesting. I don't see how unix socket is any special here, it creates >>> a peer sock with sk_alloc(), but this is not any different from two >>> separated >>> sockets. >>> >>> What is your kernel config? Do you enable CONFIG_CGROUP_NET_PRIO >>> or CONFIG_CGROUP_NET_CLASSID? I can see there might be a problem >>> if you don't enable either of them but enable CONFIG_CGROUP_BPF. >>> >> >> cgroup specific configuration bits: >> >> CONFIG_CGROUPS=y >> CONFIG_BLK_CGROUP=y >> CONFIG_CGROUP_WRITEBACK=y >> CONFIG_CGROUP_SCHED=y >> CONFIG_CGROUP_PIDS=y >> CONFIG_CGROUP_RDMA=y >> CONFIG_CGROUP_FREEZER=y >> CONFIG_CGROUP_HUGETLB=y >> CONFIG_CGROUP_DEVICE=y >> CONFIG_CGROUP_CPUACCT=y >> CONFIG_CGROUP_PERF=y >> CONFIG_CGROUP_BPF=y >> # CONFIG_CGROUP_DEBUG is not set >> CONFIG_SOCK_CGROUP_DATA=y >> CONFIG_BLK_CGROUP_RWSTAT=y >> CONFIG_BLK_CGROUP_IOLATENCY=y >> CONFIG_BLK_CGROUP_IOCOST=y >> # CONFIG_BFQ_CGROUP_DEBUG is not set >> # CONFIG_NETFILTER_XT_MATCH_CGROUP is not set >> CONFIG_NET_CLS_CGROUP=y >> CONFIG_CGROUP_NET_PRIO=y >> CONFIG_CGROUP_NET_CLASSID=y >> >> This originates from arch/s390/configs/defconfig; I don't touch >> any cgroup specific configuration in my tests. > > Good to know you enable everything related here. > >> >>> And if you have the full kernel log, it would be helpful too. >>> >> >> https://kerneltests.org/builders/qemu-s390-pending-fixes/builds/222/steps/qemubuildcommand/logs/stdio > > It looks like cgroup_sk_alloc_disabled is always false in your case. > This makes the bug even more weird. Unless there is a refcnt bug > prior to my commit, I don't see how it could happen. > >> >> Interestingly, enabling CONFIG_BFQ_CGROUP_DEBUG makes the problem disappear. > > Yeah, I guess there might be some cgroup refcnt bug which could > just paper out with CONFIG_BFQ_CGROUP_DEBUG=y. > > If you can test patches, I can send you a debugging patch for you > to collect more data. I assume this is 100% reproducible on your > side? > Something seems fishy with the use of skcd->val on big endian systems. Some debug output: [ 22.643703] sock: # sk_alloc(sk=1be28100): Calling cgroup_sk_alloc(1be28550) [ 22.643807] cgroup: # cgroup_sk_alloc(skcd=1be28550): cgroup_sk_alloc_disabled=0, in_interrupt: 0 [ 22.643886] cgroup: cgroup_sk_alloc(skcd=1be28550): cset->dfl_cgrp=01224040, skcd->val=0x1224040 [ 22.643957] cgroup: ## cgroup_bpf_get(cgrp=01224040) [ 22.646451] sock: # sk_prot_free(sk=1be28100): Calling cgroup_sk_free(1be28550) [ 22.646607] cgroup: sock_cgroup_ptr(skcd=1be28550) -> 00014040 [v=14040, skcd->val=14040] [ 22.646632] cgroup: ### cgroup_sk_free(): skcd=1be28550, cgrp=00014040 [ 22.646739] cgroup: ### cgroup_sk_free(): skcd->no_refcnt=0 [ 22.646814] cgroup: ### cgroup_sk_free(): Calling cgroup_bpf_put(cgrp=00014040) [ 22.646886] cgroup: ## cgroup_bpf_put(cgrp=00014040) Guenter
Re: [Patch net v2] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
On 7/8/20 12:32 PM, Cong Wang wrote: > On Wed, Jul 8, 2020 at 12:07 PM Guenter Roeck wrote: >> >> On 7/8/20 11:34 AM, Cong Wang wrote: >>> Hi, >>> >>> On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote: >>>> This patch causes all my s390 boot tests to crash. Reverting it fixes >>>> the problem. Please see bisect results and and crash log below. >>>> >>> ... >>>> Crash log: >>> >>> Interesting. I don't see how unix socket is any special here, it creates >>> a peer sock with sk_alloc(), but this is not any different from two >>> separated >>> sockets. >>> >>> What is your kernel config? Do you enable CONFIG_CGROUP_NET_PRIO >>> or CONFIG_CGROUP_NET_CLASSID? I can see there might be a problem >>> if you don't enable either of them but enable CONFIG_CGROUP_BPF. >>> >> >> cgroup specific configuration bits: >> >> CONFIG_CGROUPS=y >> CONFIG_BLK_CGROUP=y >> CONFIG_CGROUP_WRITEBACK=y >> CONFIG_CGROUP_SCHED=y >> CONFIG_CGROUP_PIDS=y >> CONFIG_CGROUP_RDMA=y >> CONFIG_CGROUP_FREEZER=y >> CONFIG_CGROUP_HUGETLB=y >> CONFIG_CGROUP_DEVICE=y >> CONFIG_CGROUP_CPUACCT=y >> CONFIG_CGROUP_PERF=y >> CONFIG_CGROUP_BPF=y >> # CONFIG_CGROUP_DEBUG is not set >> CONFIG_SOCK_CGROUP_DATA=y >> CONFIG_BLK_CGROUP_RWSTAT=y >> CONFIG_BLK_CGROUP_IOLATENCY=y >> CONFIG_BLK_CGROUP_IOCOST=y >> # CONFIG_BFQ_CGROUP_DEBUG is not set >> # CONFIG_NETFILTER_XT_MATCH_CGROUP is not set >> CONFIG_NET_CLS_CGROUP=y >> CONFIG_CGROUP_NET_PRIO=y >> CONFIG_CGROUP_NET_CLASSID=y >> >> This originates from arch/s390/configs/defconfig; I don't touch >> any cgroup specific configuration in my tests. > > Good to know you enable everything related here. > Maybe, but on the other side I would argue that not having everything enabled should not result in a crash. >> >>> And if you have the full kernel log, it would be helpful too. >>> >> >> https://kerneltests.org/builders/qemu-s390-pending-fixes/builds/222/steps/qemubuildcommand/logs/stdio > > It looks like cgroup_sk_alloc_disabled is always false in your case. > This makes the bug even more weird. Unless there is a refcnt bug > prior to my commit, I don't see how it could happen. > >> >> Interestingly, enabling CONFIG_BFQ_CGROUP_DEBUG makes the problem disappear. > > Yeah, I guess there might be some cgroup refcnt bug which could > just paper out with CONFIG_BFQ_CGROUP_DEBUG=y. > > If you can test patches, I can send you a debugging patch for you > to collect more data. I assume this is 100% reproducible on your > side? > Sure, I'll be happy to do that. And, yes, it is always reproducible. Guenter
Re: [Patch net v2] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
On 7/8/20 11:34 AM, Cong Wang wrote: > Hi, > > On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote: >> This patch causes all my s390 boot tests to crash. Reverting it fixes >> the problem. Please see bisect results and and crash log below. >> > ... >> Crash log: > > Interesting. I don't see how unix socket is any special here, it creates > a peer sock with sk_alloc(), but this is not any different from two separated > sockets. > > What is your kernel config? Do you enable CONFIG_CGROUP_NET_PRIO > or CONFIG_CGROUP_NET_CLASSID? I can see there might be a problem > if you don't enable either of them but enable CONFIG_CGROUP_BPF. > cgroup specific configuration bits: CONFIG_CGROUPS=y CONFIG_BLK_CGROUP=y CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_CGROUP_PIDS=y CONFIG_CGROUP_RDMA=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_HUGETLB=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_BPF=y # CONFIG_CGROUP_DEBUG is not set CONFIG_SOCK_CGROUP_DATA=y CONFIG_BLK_CGROUP_RWSTAT=y CONFIG_BLK_CGROUP_IOLATENCY=y CONFIG_BLK_CGROUP_IOCOST=y # CONFIG_BFQ_CGROUP_DEBUG is not set # CONFIG_NETFILTER_XT_MATCH_CGROUP is not set CONFIG_NET_CLS_CGROUP=y CONFIG_CGROUP_NET_PRIO=y CONFIG_CGROUP_NET_CLASSID=y This originates from arch/s390/configs/defconfig; I don't touch any cgroup specific configuration in my tests. > And if you have the full kernel log, it would be helpful too. > https://kerneltests.org/builders/qemu-s390-pending-fixes/builds/222/steps/qemubuildcommand/logs/stdio Interestingly, enabling CONFIG_BFQ_CGROUP_DEBUG makes the problem disappear. Guenter
Re: [Patch net v2] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
Hi,
On Thu, Jul 02, 2020 at 11:52:56AM -0700, Cong Wang wrote:
> When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
> copied, so the cgroup refcnt must be taken too. And, unlike the
> sk_alloc() path, sock_update_netprioidx() is not called here.
> Therefore, it is safe and necessary to grab the cgroup refcnt
> even when cgroup_sk_alloc is disabled.
>
> sk_clone_lock() is in BH context anyway, the in_interrupt()
> would terminate this function if called there. And for sk_alloc()
> skcd->val is always zero. So it's safe to factor out the code
> to make it more readable.
>
> The global variable 'cgroup_sk_alloc_disabled' is used to determine
> whether to take these reference counts. It is impossible to make
> the reference counting correct unless we save this bit of information
> in skcd->val. So, add a new bit there to record whether the socket
> has already taken the reference counts. This obviously relies on
> kmalloc() to align cgroup pointers to at least 4 bytes,
> ARCH_KMALLOC_MINALIGN is certainly larger than that.
>
> This bug seems to be introduced since the beginning, commit
> d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets")
> tried to fix it but not compeletely. It seems not easy to trigger until
> the recent commit 090e28b229af
> ("netprio_cgroup: Fix unlimited memory leak of v2 cgroups") was merged.
>
This patch causes all my s390 boot tests to crash. Reverting it fixes
the problem. Please see bisect results and and crash log below.
Guenter
---
bisect results (from pending-fixes branch) in -next repository):
# bad: [1432f824c2db44ef35b26caa9f81dd05211a75fc] Merge remote-tracking branch
'drm-misc-fixes/for-linux-next-fixes'
# good: [dcb7fd82c75ee2d6e6f9d8cc71c52519ed52e258] Linux 5.8-rc4
git bisect start 'HEAD' 'v5.8-rc4'
# bad: [fe12f8184e7265e2d24e5ed5b255275dfe4c1c04] Merge remote-tracking branch
'net/master'
git bisect bad fe12f8184e7265e2d24e5ed5b255275dfe4c1c04
# good: [474112d57c70520ebd81a5ca578fee1d93fafd07] Documentation: networking:
ipvs-sysctl: drop doubled word
git bisect good 474112d57c70520ebd81a5ca578fee1d93fafd07
# good: [6d12075ddeedc38d25c5b74e929e686158da728c] Merge tag
'mtd/fixes-for-5.8-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
git bisect good 6d12075ddeedc38d25c5b74e929e686158da728c
# good: [74478ea4ded519db35cb1f059948b1e713bb4abf] net: ipa: fix QMI structure
definition bugs
git bisect good 74478ea4ded519db35cb1f059948b1e713bb4abf
# bad: [9c29e36152748fd623fcff6cc8f538550f9eeafc] mptcp: fix DSS map generation
on fin retransmission
git bisect bad 9c29e36152748fd623fcff6cc8f538550f9eeafc
# good: [aea23c323d89836bcdcee67e49def997ffca043b] ipv6: Fix use of anycast
address with loopback
git bisect good aea23c323d89836bcdcee67e49def997ffca043b
# bad: [28b18e4eb515af7c6661c3995c6e3c34412c2874] net: sky2: initialize return
of gm_phy_read
git bisect bad 28b18e4eb515af7c6661c3995c6e3c34412c2874
# bad: [ad0f75e5f57ccbceec13274e1e242f2b5a6397ed] cgroup: fix cgroup_sk_alloc()
for sk_clone_lock()
git bisect bad ad0f75e5f57ccbceec13274e1e242f2b5a6397ed
# first bad commit: [ad0f75e5f57ccbceec13274e1e242f2b5a6397ed] cgroup: fix
cgroup_sk_alloc() for sk_clone_lock()
---
Crash log:
[ 22.390674] Run /sbin/init as init process
[ 22.497551] Unable to handle kernel pointer dereference in virtual kernel
address space
[ 22.497738] Failing address: 5010f0b45fa93000 TEID: 5010f0b45fa93803
[ 22.497813] Fault in home space mode while using kernel ASCE.
[ 22.497958] AS:01774007 R3:0024
[ 22.498300] Oops: 0038 ilc:3 [#1] SMP
[ 22.498405] Modules linked in:
[ 22.499027] CPU: 0 PID: 153 Comm: init Not tainted
5.8.0-rc4-00328-g1432f824c2db4 #1
[ 22.499112] Hardware name: QEMU 2964 QEMU (KVM/Linux)
[ 22.499261] Krnl PSW : 0704e0018000 00259be0
(cgroup_sk_free+0xa8/0x1e8)
[ 22.499405]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0
RI:0 EA:3
[ 22.499506] Krnl GPRS: 48a38585 5010f0b45fa93094 0002
1c228bd8
[ 22.499585]1c228bb0
011c2eda
[ 22.499665]f000 011c1f72 011deef0
00014040
[ 22.499744]1c228100 00e76bf0 00259c82
03e0002c3c00
[ 22.500270] Krnl Code: 00259bd2: a72a0001ahi %r2,1
[ 22.500270]00259bd6: 502003a8st %r2,936
[ 22.500270] #00259bda: e31003b80008ag %r1,952
[ 22.500270] >00259be0: e3201004lg
%r2,0(%r1)
[ 22.500270]00259be6: a7f40004brc
15,00259bee
[ 22.500270]00259bea: b9040023lgr %r2,%r3
[ 22.500270]00259bee: b9040032lgr %r3,%r2
[ 22.500270]00259bf2: b9040042lgr %r4,%r2
[
Re: [PATCH] hwmon: (pmbus) fix a typo in Kconfig SENSORS_IR35221 option
On Thu, Jul 02, 2020 at 03:13:49PM -0700, rentao.b...@gmail.com wrote:
> From: Tao Ren
>
> Fix a typo in SENSORS_IR35221 option: module name should be "ir35221"
> instead of "ir35521".
>
> Fixes: 8991ebd9c9a6 ("hwmon: (pmbus) Add client driver for IR35221")
>
> Cc: Samuel Mendoza-Jonas
> Signed-off-by: Tao Ren
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/pmbus/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 3ad97fd5ce03..e35db489b76f 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -71,7 +71,7 @@ config SENSORS_IR35221
> Infineon IR35221 controller.
>
> This driver can also be built as a module. If so, the module will
> - be called ir35521.
> + be called ir35221.
>
> config SENSORS_IR38064
> tristate "Infineon IR38064"
Re: [PATCH v4 05/11] thermal: remove get_mode() operation of drivers
On Thu, May 28, 2020 at 09:20:45PM +0200, Andrzej Pietrasiewicz wrote:
> get_mode() is now redundant, as the state is stored in struct
> thermal_zone_device.
>
> Consequently the "mode" attribute in sysfs can always be visible, because
> it is always possible to get the mode from struct tzd.
>
> Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Guenter Roeck
> ---
> drivers/acpi/thermal.c| 9 --
> .../ethernet/mellanox/mlxsw/core_thermal.c| 19
> drivers/platform/x86/acerhdf.c| 12
> drivers/thermal/da9062-thermal.c | 8 -
> drivers/thermal/imx_thermal.c | 9 --
> .../intel/int340x_thermal/int3400_thermal.c | 9 --
> .../thermal/intel/intel_quark_dts_thermal.c | 8 -
> drivers/thermal/thermal_core.c| 7 +
> drivers/thermal/thermal_of.c | 9 --
> drivers/thermal/thermal_sysfs.c | 30 ++-
> include/linux/thermal.h | 2 --
> 11 files changed, 3 insertions(+), 119 deletions(-)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 4ba273f49d87..592be97c4456 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -525,14 +525,6 @@ static int thermal_get_temp(struct thermal_zone_device
> *thermal, int *temp)
> return 0;
> }
>
> -static int thermal_get_mode(struct thermal_zone_device *thermal,
> - enum thermal_device_mode *mode)
> -{
> - *mode = thermal->mode;
> -
> - return 0;
> -}
> -
> static int thermal_set_mode(struct thermal_zone_device *thermal,
> enum thermal_device_mode mode)
> {
> @@ -847,7 +839,6 @@ static struct thermal_zone_device_ops
> acpi_thermal_zone_ops = {
> .bind = acpi_thermal_bind_cooling_device,
> .unbind = acpi_thermal_unbind_cooling_device,
> .get_temp = thermal_get_temp,
> - .get_mode = thermal_get_mode,
> .set_mode = thermal_set_mode,
> .get_trip_type = thermal_get_trip_type,
> .get_trip_temp = thermal_get_trip_temp,
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> index aa082e8a0b13..6e26678ac312 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> @@ -275,14 +275,6 @@ static int mlxsw_thermal_unbind(struct
> thermal_zone_device *tzdev,
> return 0;
> }
>
> -static int mlxsw_thermal_get_mode(struct thermal_zone_device *tzdev,
> - enum thermal_device_mode *mode)
> -{
> - *mode = tzdev->mode;
> -
> - return 0;
> -}
> -
> static int mlxsw_thermal_set_mode(struct thermal_zone_device *tzdev,
> enum thermal_device_mode mode)
> {
> @@ -403,7 +395,6 @@ static int mlxsw_thermal_trend_get(struct
> thermal_zone_device *tzdev,
> static struct thermal_zone_device_ops mlxsw_thermal_ops = {
> .bind = mlxsw_thermal_bind,
> .unbind = mlxsw_thermal_unbind,
> - .get_mode = mlxsw_thermal_get_mode,
> .set_mode = mlxsw_thermal_set_mode,
> .get_temp = mlxsw_thermal_get_temp,
> .get_trip_type = mlxsw_thermal_get_trip_type,
> @@ -462,14 +453,6 @@ static int mlxsw_thermal_module_unbind(struct
> thermal_zone_device *tzdev,
> return err;
> }
>
> -static int mlxsw_thermal_module_mode_get(struct thermal_zone_device *tzdev,
> - enum thermal_device_mode *mode)
> -{
> - *mode = tzdev->mode;
> -
> - return 0;
> -}
> -
> static int mlxsw_thermal_module_mode_set(struct thermal_zone_device *tzdev,
>enum thermal_device_mode mode)
> {
> @@ -591,7 +574,6 @@ mlxsw_thermal_module_trip_hyst_set(struct
> thermal_zone_device *tzdev, int trip,
> static struct thermal_zone_device_ops mlxsw_thermal_module_ops = {
> .bind = mlxsw_thermal_module_bind,
> .unbind = mlxsw_thermal_module_unbind,
> - .get_mode = mlxsw_thermal_module_mode_get,
> .set_mode = mlxsw_thermal_module_mode_set,
> .get_temp = mlxsw_thermal_module_temp_get,
> .get_trip_type = mlxsw_thermal_module_trip_type_get,
> @@ -630,7 +612,6 @@ static int mlxsw_thermal_gearbox_temp_get(struct
> thermal_zone_device *tzdev,
> static struct thermal_zone_device_ops mlxsw_thermal_gearbox_ops = {
> .bind = mlxsw_thermal_module_bind,
> .unbind = mlxsw_thermal_module_unbind,
> - .get_mode = m
Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device
On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote:
> Prepare for eliminating get_mode().
>
> Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Guenter Roeck
> ---
> drivers/acpi/thermal.c| 18 ++--
> .../ethernet/mellanox/mlxsw/core_thermal.c| 21 +++
> drivers/platform/x86/acerhdf.c| 15 ++---
> drivers/thermal/da9062-thermal.c | 6 ++
> drivers/thermal/imx_thermal.c | 17 +++
> .../intel/int340x_thermal/int3400_thermal.c | 12 +++
> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++---
> drivers/thermal/thermal_of.c | 10 +++--
> 8 files changed, 44 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index fb46070c66d8..4ba273f49d87 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -172,7 +172,6 @@ struct acpi_thermal {
> struct acpi_thermal_trips trips;
> struct acpi_handle_list devices;
> struct thermal_zone_device *thermal_zone;
> - enum thermal_device_mode mode;
> int kelvin_offset; /* in millidegrees */
> struct work_struct thermal_check_work;
> };
> @@ -500,7 +499,7 @@ static void acpi_thermal_check(void *data)
> {
> struct acpi_thermal *tz = data;
>
> - if (tz->mode != THERMAL_DEVICE_ENABLED)
> + if (tz->thermal_zone->mode != THERMAL_DEVICE_ENABLED)
> return;
>
> thermal_zone_device_update(tz->thermal_zone,
> @@ -529,12 +528,7 @@ static int thermal_get_temp(struct thermal_zone_device
> *thermal, int *temp)
> static int thermal_get_mode(struct thermal_zone_device *thermal,
> enum thermal_device_mode *mode)
> {
> - struct acpi_thermal *tz = thermal->devdata;
> -
> - if (!tz)
> - return -EINVAL;
> -
> - *mode = tz->mode;
> + *mode = thermal->mode;
>
> return 0;
> }
> @@ -556,11 +550,11 @@ static int thermal_set_mode(struct thermal_zone_device
> *thermal,
> if (mode == THERMAL_DEVICE_DISABLED)
> pr_warn("thermal zone will be disabled\n");
>
> - if (mode != tz->mode) {
> - tz->mode = mode;
> + if (mode != tz->thermal_zone->mode) {
> + tz->thermal_zone->mode = mode;
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "%s kernel ACPI thermal control\n",
> - tz->mode == THERMAL_DEVICE_ENABLED ?
> + tz->thermal_zone->mode == THERMAL_DEVICE_ENABLED ?
> "Enable" : "Disable"));
> acpi_thermal_check(tz);
> }
> @@ -912,7 +906,7 @@ static int acpi_thermal_register_thermal_zone(struct
> acpi_thermal *tz)
> goto remove_dev_link;
> }
>
> - tz->mode = THERMAL_DEVICE_ENABLED;
> + tz->thermal_zone->mode = THERMAL_DEVICE_ENABLED;
>
> dev_info(&tz->device->dev, "registered as thermal_zone%d\n",
>tz->thermal_zone->id);
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> index ce0a6837daa3..aa082e8a0b13 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> @@ -98,7 +98,6 @@ struct mlxsw_thermal_module {
> struct mlxsw_thermal *parent;
> struct thermal_zone_device *tzdev;
> struct mlxsw_thermal_trip trips[MLXSW_THERMAL_NUM_TRIPS];
> - enum thermal_device_mode mode;
> int module; /* Module or gearbox number */
> };
>
> @@ -110,7 +109,6 @@ struct mlxsw_thermal {
> struct thermal_cooling_device *cdevs[MLXSW_MFCR_PWMS_MAX];
> u8 cooling_levels[MLXSW_THERMAL_MAX_STATE + 1];
> struct mlxsw_thermal_trip trips[MLXSW_THERMAL_NUM_TRIPS];
> - enum thermal_device_mode mode;
> struct mlxsw_thermal_module *tz_module_arr;
> u8 tz_module_num;
> struct mlxsw_thermal_module *tz_gearbox_arr;
> @@ -280,9 +278,7 @@ static int mlxsw_thermal_unbind(struct
> thermal_zone_device *tzdev,
> static int mlxsw_thermal_get_mode(struct thermal_zone_device *tzdev,
> enum thermal_device_mode *mode)
> {
> - struct mlxsw_thermal *thermal = tzdev->devdata;
> -
> - *mode = thermal->mode;
> + *mode = tzdev->mode;
>
> return 0;
> }
> @@ -299,9 +295,9 @@ static int mlxsw_thermal_set_mode(s
Re: [PATCH v4 06/11] thermal: Add mode helpers
On 6/1/20 4:16 AM, Andrzej Pietrasiewicz wrote: > Hi Guenter, > > W dniu 29.05.2020 o 17:52, Guenter Roeck pisze: >> On Thu, May 28, 2020 at 09:20:46PM +0200, Andrzej Pietrasiewicz wrote: >>> Prepare for making the drivers not access tzd's private members. >>> >>> Signed-off-by: Andrzej Pietrasiewicz > > > >>> + >> Nit: unnecessary empty line. >> >>> + return ret; > > > >>> + return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_ENABLED); >>> +} >>> +EXPORT_SYMBOL(thermal_zone_device_enable); >> >> Other exports in thermal/ use EXPORT_SYMBOL_GPL. > > Other than that does it look good to you? Yes, it does. > I can send a v5 where the two above will be corrected, but did you have > a chance to review patches 7-11? > Not yet. I got distracted, sorry. Hopefully I'll get to it today or tomorrow. Guenter
Re: [PATCH v4 05/11] thermal: remove get_mode() operation of drivers
On Thu, May 28, 2020 at 09:20:45PM +0200, Andrzej Pietrasiewicz wrote:
> get_mode() is now redundant, as the state is stored in struct
> thermal_zone_device.
>
> Consequently the "mode" attribute in sysfs can always be visible, because
> it is always possible to get the mode from struct tzd.
>
> Signed-off-by: Andrzej Pietrasiewicz
Based on separate feedback/dscussion:
Reviewed-by: Guenter Roeck
Guenter
> ---
> drivers/acpi/thermal.c| 9 --
> .../ethernet/mellanox/mlxsw/core_thermal.c| 19
> drivers/platform/x86/acerhdf.c| 12
> drivers/thermal/da9062-thermal.c | 8 -
> drivers/thermal/imx_thermal.c | 9 --
> .../intel/int340x_thermal/int3400_thermal.c | 9 --
> .../thermal/intel/intel_quark_dts_thermal.c | 8 -
> drivers/thermal/thermal_core.c| 7 +
> drivers/thermal/thermal_of.c | 9 --
> drivers/thermal/thermal_sysfs.c | 30 ++-
> include/linux/thermal.h | 2 --
> 11 files changed, 3 insertions(+), 119 deletions(-)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 4ba273f49d87..592be97c4456 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -525,14 +525,6 @@ static int thermal_get_temp(struct thermal_zone_device
> *thermal, int *temp)
> return 0;
> }
>
> -static int thermal_get_mode(struct thermal_zone_device *thermal,
> - enum thermal_device_mode *mode)
> -{
> - *mode = thermal->mode;
> -
> - return 0;
> -}
> -
> static int thermal_set_mode(struct thermal_zone_device *thermal,
> enum thermal_device_mode mode)
> {
> @@ -847,7 +839,6 @@ static struct thermal_zone_device_ops
> acpi_thermal_zone_ops = {
> .bind = acpi_thermal_bind_cooling_device,
> .unbind = acpi_thermal_unbind_cooling_device,
> .get_temp = thermal_get_temp,
> - .get_mode = thermal_get_mode,
> .set_mode = thermal_set_mode,
> .get_trip_type = thermal_get_trip_type,
> .get_trip_temp = thermal_get_trip_temp,
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> index aa082e8a0b13..6e26678ac312 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> @@ -275,14 +275,6 @@ static int mlxsw_thermal_unbind(struct
> thermal_zone_device *tzdev,
> return 0;
> }
>
> -static int mlxsw_thermal_get_mode(struct thermal_zone_device *tzdev,
> - enum thermal_device_mode *mode)
> -{
> - *mode = tzdev->mode;
> -
> - return 0;
> -}
> -
> static int mlxsw_thermal_set_mode(struct thermal_zone_device *tzdev,
> enum thermal_device_mode mode)
> {
> @@ -403,7 +395,6 @@ static int mlxsw_thermal_trend_get(struct
> thermal_zone_device *tzdev,
> static struct thermal_zone_device_ops mlxsw_thermal_ops = {
> .bind = mlxsw_thermal_bind,
> .unbind = mlxsw_thermal_unbind,
> - .get_mode = mlxsw_thermal_get_mode,
> .set_mode = mlxsw_thermal_set_mode,
> .get_temp = mlxsw_thermal_get_temp,
> .get_trip_type = mlxsw_thermal_get_trip_type,
> @@ -462,14 +453,6 @@ static int mlxsw_thermal_module_unbind(struct
> thermal_zone_device *tzdev,
> return err;
> }
>
> -static int mlxsw_thermal_module_mode_get(struct thermal_zone_device *tzdev,
> - enum thermal_device_mode *mode)
> -{
> - *mode = tzdev->mode;
> -
> - return 0;
> -}
> -
> static int mlxsw_thermal_module_mode_set(struct thermal_zone_device *tzdev,
>enum thermal_device_mode mode)
> {
> @@ -591,7 +574,6 @@ mlxsw_thermal_module_trip_hyst_set(struct
> thermal_zone_device *tzdev, int trip,
> static struct thermal_zone_device_ops mlxsw_thermal_module_ops = {
> .bind = mlxsw_thermal_module_bind,
> .unbind = mlxsw_thermal_module_unbind,
> - .get_mode = mlxsw_thermal_module_mode_get,
> .set_mode = mlxsw_thermal_module_mode_set,
> .get_temp = mlxsw_thermal_module_temp_get,
> .get_trip_type = mlxsw_thermal_module_trip_type_get,
> @@ -630,7 +612,6 @@ static int mlxsw_thermal_gearbox_temp_get(struct
> thermal_zone_device *tzdev,
> static struct thermal_zone_device_ops mlxsw_thermal_gearbox_ops = {
> .bind = mlxsw_thermal_module_bind,
> .unbind = mlxsw_thermal
Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device
On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote:
> Prepare for eliminating get_mode().
>
> Signed-off-by: Andrzej Pietrasiewicz
Based on discussion:
Reviewed-by: Guenter Roeck
Guenter
> ---
> drivers/acpi/thermal.c| 18 ++--
> .../ethernet/mellanox/mlxsw/core_thermal.c| 21 +++
> drivers/platform/x86/acerhdf.c| 15 ++---
> drivers/thermal/da9062-thermal.c | 6 ++
> drivers/thermal/imx_thermal.c | 17 +++
> .../intel/int340x_thermal/int3400_thermal.c | 12 +++
> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++---
> drivers/thermal/thermal_of.c | 10 +++--
> 8 files changed, 44 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index fb46070c66d8..4ba273f49d87 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -172,7 +172,6 @@ struct acpi_thermal {
> struct acpi_thermal_trips trips;
> struct acpi_handle_list devices;
> struct thermal_zone_device *thermal_zone;
> - enum thermal_device_mode mode;
> int kelvin_offset; /* in millidegrees */
> struct work_struct thermal_check_work;
> };
> @@ -500,7 +499,7 @@ static void acpi_thermal_check(void *data)
> {
> struct acpi_thermal *tz = data;
>
> - if (tz->mode != THERMAL_DEVICE_ENABLED)
> + if (tz->thermal_zone->mode != THERMAL_DEVICE_ENABLED)
> return;
>
> thermal_zone_device_update(tz->thermal_zone,
> @@ -529,12 +528,7 @@ static int thermal_get_temp(struct thermal_zone_device
> *thermal, int *temp)
> static int thermal_get_mode(struct thermal_zone_device *thermal,
> enum thermal_device_mode *mode)
> {
> - struct acpi_thermal *tz = thermal->devdata;
> -
> - if (!tz)
> - return -EINVAL;
> -
> - *mode = tz->mode;
> + *mode = thermal->mode;
>
> return 0;
> }
> @@ -556,11 +550,11 @@ static int thermal_set_mode(struct thermal_zone_device
> *thermal,
> if (mode == THERMAL_DEVICE_DISABLED)
> pr_warn("thermal zone will be disabled\n");
>
> - if (mode != tz->mode) {
> - tz->mode = mode;
> + if (mode != tz->thermal_zone->mode) {
> + tz->thermal_zone->mode = mode;
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "%s kernel ACPI thermal control\n",
> - tz->mode == THERMAL_DEVICE_ENABLED ?
> + tz->thermal_zone->mode == THERMAL_DEVICE_ENABLED ?
> "Enable" : "Disable"));
> acpi_thermal_check(tz);
> }
> @@ -912,7 +906,7 @@ static int acpi_thermal_register_thermal_zone(struct
> acpi_thermal *tz)
> goto remove_dev_link;
> }
>
> - tz->mode = THERMAL_DEVICE_ENABLED;
> + tz->thermal_zone->mode = THERMAL_DEVICE_ENABLED;
>
> dev_info(&tz->device->dev, "registered as thermal_zone%d\n",
>tz->thermal_zone->id);
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> index ce0a6837daa3..aa082e8a0b13 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> @@ -98,7 +98,6 @@ struct mlxsw_thermal_module {
> struct mlxsw_thermal *parent;
> struct thermal_zone_device *tzdev;
> struct mlxsw_thermal_trip trips[MLXSW_THERMAL_NUM_TRIPS];
> - enum thermal_device_mode mode;
> int module; /* Module or gearbox number */
> };
>
> @@ -110,7 +109,6 @@ struct mlxsw_thermal {
> struct thermal_cooling_device *cdevs[MLXSW_MFCR_PWMS_MAX];
> u8 cooling_levels[MLXSW_THERMAL_MAX_STATE + 1];
> struct mlxsw_thermal_trip trips[MLXSW_THERMAL_NUM_TRIPS];
> - enum thermal_device_mode mode;
> struct mlxsw_thermal_module *tz_module_arr;
> u8 tz_module_num;
> struct mlxsw_thermal_module *tz_gearbox_arr;
> @@ -280,9 +278,7 @@ static int mlxsw_thermal_unbind(struct
> thermal_zone_device *tzdev,
> static int mlxsw_thermal_get_mode(struct thermal_zone_device *tzdev,
> enum thermal_device_mode *mode)
> {
> - struct mlxsw_thermal *thermal = tzdev->devdata;
> -
> - *mode = thermal->mode;
> + *mode = tzdev->mode;
>
> return 0;
> }
> @@ -299,9 +295,9 @@ static int mlxsw_thermal_set_mode(s
Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device
On 5/29/20 10:21 AM, Andrzej Pietrasiewicz wrote: > Hi again, > > W dniu 29.05.2020 o 18:08, Andrzej Pietrasiewicz pisze: >> Hi Guenter, >> >> W dniu 29.05.2020 o 17:42, Guenter Roeck pisze: >>> On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote: >>>> Prepare for eliminating get_mode(). >>>> >>> Might be worthwhile to explain (not only in the subject) what you are >>> doing here. >>> >>>> Signed-off-by: Andrzej Pietrasiewicz >>>> --- >>>> drivers/acpi/thermal.c | 18 ++-- >>>> .../ethernet/mellanox/mlxsw/core_thermal.c | 21 +++ >>>> drivers/platform/x86/acerhdf.c | 15 ++--- >>>> drivers/thermal/da9062-thermal.c | 6 ++ >>>> drivers/thermal/imx_thermal.c | 17 +++ >>>> .../intel/int340x_thermal/int3400_thermal.c | 12 +++ >>>> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++--- >>>> drivers/thermal/thermal_of.c | 10 +++-- >>> >>> After this patch is applied on top of the thermal 'testing' branch, >>> there are still local instances of thermal_device_mode in >>> drivers/thermal/st/stm_thermal.c >>> drivers/thermal/ti-soc-thermal/ti-thermal-common.c >>> >>> If there is a reason not to replace those, it might make sense to explain >>> it here. >>> >> >> My understanding is that these two are sensor devices which are "plugged" >> into their "parent" thermal zone device. The latter is the "proper" tzd. >> They both use thermal_zone_of_device_ops instead of thermal_zone_device_ops. >> The former doesn't even have get_mode(). The thermal core, when it calls >> get_mode(), operates on the "parent" thermal zone devices. >> >> Consequently, the drivers you mention use their "mode" members for >> their private purpose, not for the purpose of storing the "parent" >> thermal zone device mode. >> > > Let me also say it differently. > > Both drivers which you mention use devm_thermal_zone_of_sensor_register(). > It calls thermal_zone_of_sensor_register(), which "will search the list of > thermal zones described in device tree and look for the zone that refer to > the sensor device pointed by @dev->of_node as temperature providers. For > the zone pointing to the sensor node, the sensor will be added to the DT > thermal zone device." When a match is found thermal_zone_of_add_sensor() > is invoked, which (using thermal_zone_get_zone_by_name()) iterates over > all registered thermal_zone_devices. The one eventually found will be > returned and propagated to the original caller of > devm_thermal_zone_of_sensor_register(). The state of this returned > device is managed elsewhere (in that device's struct tzd). The "mode" > member you are referring to is thus unrelated. > Quite confusing, especially since the ti-soc driver doesn't seem to use the variable at all after setting it, and the stm_thermal driver uses it to reflect power status associated with suspend/resume. So, yes, I agree this is fine. Thanks, Guenter > Regards, > > Andrzej
Re: [PATCH v4 06/11] thermal: Add mode helpers
On Thu, May 28, 2020 at 09:20:46PM +0200, Andrzej Pietrasiewicz wrote:
> Prepare for making the drivers not access tzd's private members.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/thermal/thermal_core.c | 53 ++
> include/linux/thermal.h| 13 +
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 14d3b1b94c4f..f2a5c5ee3455 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -459,6 +459,59 @@ static void thermal_zone_device_reset(struct
> thermal_zone_device *tz)
> thermal_zone_device_init(tz);
> }
>
> +int thermal_zone_device_set_mode(struct thermal_zone_device *tz,
> + enum thermal_device_mode mode)
> +{
> + int ret = 0;
> +
> + mutex_lock(&tz->lock);
> +
> + /* do nothing if mode isn't changing */
> + if (mode == tz->mode) {
> + mutex_unlock(&tz->lock);
> +
Nit: unnecessary empty line.
> + return ret;
> + }
> +
> + if (tz->ops->set_mode)
> + ret = tz->ops->set_mode(tz, mode);
> +
> + if (!ret)
> + tz->mode = mode;
> +
> + mutex_unlock(&tz->lock);
> +
> + thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
> +
> + return ret;
> +}
> +
> +int thermal_zone_device_enable(struct thermal_zone_device *tz)
> +{
> + return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_ENABLED);
> +}
> +EXPORT_SYMBOL(thermal_zone_device_enable);
Other exports in thermal/ use EXPORT_SYMBOL_GPL.
> +
> +int thermal_zone_device_disable(struct thermal_zone_device *tz)
> +{
> + return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_DISABLED);
> +}
> +EXPORT_SYMBOL(thermal_zone_device_disable);
> +
> +int thermal_zone_device_is_enabled(struct thermal_zone_device *tz)
> +{
> + enum thermal_device_mode mode;
> +
> + mutex_lock(&tz->lock);
> +
> + mode = tz->mode;
> +
> + mutex_unlock(&tz->lock);
> +
> + return mode == THERMAL_DEVICE_ENABLED;
> +}
> +EXPORT_SYMBOL(thermal_zone_device_is_enabled);
> +
> void thermal_zone_device_update(struct thermal_zone_device *tz,
> enum thermal_notify_event event)
> {
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index a808f6fa2777..df013c39ba9b 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -416,6 +416,9 @@ int thermal_zone_get_offset(struct thermal_zone_device
> *tz);
>
> void thermal_cdev_update(struct thermal_cooling_device *);
> void thermal_notify_framework(struct thermal_zone_device *, int);
> +int thermal_zone_device_enable(struct thermal_zone_device *tz);
> +int thermal_zone_device_disable(struct thermal_zone_device *tz);
> +int thermal_zone_device_is_enabled(struct thermal_zone_device *tz);
> #else
> static inline struct thermal_zone_device *thermal_zone_device_register(
> const char *type, int trips, int mask, void *devdata,
> @@ -463,6 +466,16 @@ static inline void thermal_cdev_update(struct
> thermal_cooling_device *cdev)
> static inline void thermal_notify_framework(struct thermal_zone_device *tz,
> int trip)
> { }
> +
> +static inline int thermal_zone_device_enable(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> +
> +static inline int thermal_zone_device_disable(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> +
> +static inline int
> +thermal_zone_device_is_enabled(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> #endif /* CONFIG_THERMAL */
>
> #endif /* __THERMAL_H__ */
Re: [PATCH v4 05/11] thermal: remove get_mode() operation of drivers
On Thu, May 28, 2020 at 09:20:45PM +0200, Andrzej Pietrasiewicz wrote:
> get_mode() is now redundant, as the state is stored in struct
> thermal_zone_device.
>
> Consequently the "mode" attribute in sysfs can always be visible, because
> it is always possible to get the mode from struct tzd.
>
> Signed-off-by: Andrzej Pietrasiewicz
There is a slight semantic change for the two drivers which still have
a local copy of enum thermal_device_mode: Previously trying to read the
mode for those would return -EPERM since they don't have a get_mode
function. Now the global value for mode is returned, but I am not sure
if it matches the local value.
Guenter
> ---
> drivers/acpi/thermal.c| 9 --
> .../ethernet/mellanox/mlxsw/core_thermal.c| 19
> drivers/platform/x86/acerhdf.c| 12
> drivers/thermal/da9062-thermal.c | 8 -
> drivers/thermal/imx_thermal.c | 9 --
> .../intel/int340x_thermal/int3400_thermal.c | 9 --
> .../thermal/intel/intel_quark_dts_thermal.c | 8 -
> drivers/thermal/thermal_core.c| 7 +
> drivers/thermal/thermal_of.c | 9 --
> drivers/thermal/thermal_sysfs.c | 30 ++-
> include/linux/thermal.h | 2 --
> 11 files changed, 3 insertions(+), 119 deletions(-)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 4ba273f49d87..592be97c4456 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -525,14 +525,6 @@ static int thermal_get_temp(struct thermal_zone_device
> *thermal, int *temp)
> return 0;
> }
>
> -static int thermal_get_mode(struct thermal_zone_device *thermal,
> - enum thermal_device_mode *mode)
> -{
> - *mode = thermal->mode;
> -
> - return 0;
> -}
> -
> static int thermal_set_mode(struct thermal_zone_device *thermal,
> enum thermal_device_mode mode)
> {
> @@ -847,7 +839,6 @@ static struct thermal_zone_device_ops
> acpi_thermal_zone_ops = {
> .bind = acpi_thermal_bind_cooling_device,
> .unbind = acpi_thermal_unbind_cooling_device,
> .get_temp = thermal_get_temp,
> - .get_mode = thermal_get_mode,
> .set_mode = thermal_set_mode,
> .get_trip_type = thermal_get_trip_type,
> .get_trip_temp = thermal_get_trip_temp,
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> index aa082e8a0b13..6e26678ac312 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> @@ -275,14 +275,6 @@ static int mlxsw_thermal_unbind(struct
> thermal_zone_device *tzdev,
> return 0;
> }
>
> -static int mlxsw_thermal_get_mode(struct thermal_zone_device *tzdev,
> - enum thermal_device_mode *mode)
> -{
> - *mode = tzdev->mode;
> -
> - return 0;
> -}
> -
> static int mlxsw_thermal_set_mode(struct thermal_zone_device *tzdev,
> enum thermal_device_mode mode)
> {
> @@ -403,7 +395,6 @@ static int mlxsw_thermal_trend_get(struct
> thermal_zone_device *tzdev,
> static struct thermal_zone_device_ops mlxsw_thermal_ops = {
> .bind = mlxsw_thermal_bind,
> .unbind = mlxsw_thermal_unbind,
> - .get_mode = mlxsw_thermal_get_mode,
> .set_mode = mlxsw_thermal_set_mode,
> .get_temp = mlxsw_thermal_get_temp,
> .get_trip_type = mlxsw_thermal_get_trip_type,
> @@ -462,14 +453,6 @@ static int mlxsw_thermal_module_unbind(struct
> thermal_zone_device *tzdev,
> return err;
> }
>
> -static int mlxsw_thermal_module_mode_get(struct thermal_zone_device *tzdev,
> - enum thermal_device_mode *mode)
> -{
> - *mode = tzdev->mode;
> -
> - return 0;
> -}
> -
> static int mlxsw_thermal_module_mode_set(struct thermal_zone_device *tzdev,
>enum thermal_device_mode mode)
> {
> @@ -591,7 +574,6 @@ mlxsw_thermal_module_trip_hyst_set(struct
> thermal_zone_device *tzdev, int trip,
> static struct thermal_zone_device_ops mlxsw_thermal_module_ops = {
> .bind = mlxsw_thermal_module_bind,
> .unbind = mlxsw_thermal_module_unbind,
> - .get_mode = mlxsw_thermal_module_mode_get,
> .set_mode = mlxsw_thermal_module_mode_set,
> .get_temp = mlxsw_thermal_module_temp_get,
> .get_trip_type = mlxsw_thermal_module_trip_type_get,
> @@ -630,7 +612,6 @@ static int mlxsw_thermal_gearbox_temp_get(struct
> thermal_zone_device *tzdev,
> static struct thermal_zone_device_ops mlxsw_thermal_gearbox_ops = {
> .bind = mlxsw_thermal_module_bind,
> .unbind = mlxsw_thermal_module_unbind,
> - .get_mode = mlxsw_thermal_module_mode_get,
> .set_mode = mlxsw
Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device
On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote:
> Prepare for eliminating get_mode().
>
Might be worthwhile to explain (not only in the subject) what you are
doing here.
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/acpi/thermal.c| 18 ++--
> .../ethernet/mellanox/mlxsw/core_thermal.c| 21 +++
> drivers/platform/x86/acerhdf.c| 15 ++---
> drivers/thermal/da9062-thermal.c | 6 ++
> drivers/thermal/imx_thermal.c | 17 +++
> .../intel/int340x_thermal/int3400_thermal.c | 12 +++
> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++---
> drivers/thermal/thermal_of.c | 10 +++--
After this patch is applied on top of the thermal 'testing' branch,
there are still local instances of thermal_device_mode in
drivers/thermal/st/stm_thermal.c
drivers/thermal/ti-soc-thermal/ti-thermal-common.c
If there is a reason not to replace those, it might make sense to explain
it here.
Thanks,
Guenter
> 8 files changed, 44 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index fb46070c66d8..4ba273f49d87 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -172,7 +172,6 @@ struct acpi_thermal {
> struct acpi_thermal_trips trips;
> struct acpi_handle_list devices;
> struct thermal_zone_device *thermal_zone;
> - enum thermal_device_mode mode;
> int kelvin_offset; /* in millidegrees */
> struct work_struct thermal_check_work;
> };
> @@ -500,7 +499,7 @@ static void acpi_thermal_check(void *data)
> {
> struct acpi_thermal *tz = data;
>
> - if (tz->mode != THERMAL_DEVICE_ENABLED)
> + if (tz->thermal_zone->mode != THERMAL_DEVICE_ENABLED)
> return;
>
> thermal_zone_device_update(tz->thermal_zone,
> @@ -529,12 +528,7 @@ static int thermal_get_temp(struct thermal_zone_device
> *thermal, int *temp)
> static int thermal_get_mode(struct thermal_zone_device *thermal,
> enum thermal_device_mode *mode)
> {
> - struct acpi_thermal *tz = thermal->devdata;
> -
> - if (!tz)
> - return -EINVAL;
> -
> - *mode = tz->mode;
> + *mode = thermal->mode;
>
> return 0;
> }
> @@ -556,11 +550,11 @@ static int thermal_set_mode(struct thermal_zone_device
> *thermal,
> if (mode == THERMAL_DEVICE_DISABLED)
> pr_warn("thermal zone will be disabled\n");
>
> - if (mode != tz->mode) {
> - tz->mode = mode;
> + if (mode != tz->thermal_zone->mode) {
> + tz->thermal_zone->mode = mode;
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "%s kernel ACPI thermal control\n",
> - tz->mode == THERMAL_DEVICE_ENABLED ?
> + tz->thermal_zone->mode == THERMAL_DEVICE_ENABLED ?
> "Enable" : "Disable"));
> acpi_thermal_check(tz);
> }
> @@ -912,7 +906,7 @@ static int acpi_thermal_register_thermal_zone(struct
> acpi_thermal *tz)
> goto remove_dev_link;
> }
>
> - tz->mode = THERMAL_DEVICE_ENABLED;
> + tz->thermal_zone->mode = THERMAL_DEVICE_ENABLED;
>
> dev_info(&tz->device->dev, "registered as thermal_zone%d\n",
>tz->thermal_zone->id);
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> index ce0a6837daa3..aa082e8a0b13 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
> @@ -98,7 +98,6 @@ struct mlxsw_thermal_module {
> struct mlxsw_thermal *parent;
> struct thermal_zone_device *tzdev;
> struct mlxsw_thermal_trip trips[MLXSW_THERMAL_NUM_TRIPS];
> - enum thermal_device_mode mode;
> int module; /* Module or gearbox number */
> };
>
> @@ -110,7 +109,6 @@ struct mlxsw_thermal {
> struct thermal_cooling_device *cdevs[MLXSW_MFCR_PWMS_MAX];
> u8 cooling_levels[MLXSW_THERMAL_MAX_STATE + 1];
> struct mlxsw_thermal_trip trips[MLXSW_THERMAL_NUM_TRIPS];
> - enum thermal_device_mode mode;
> struct mlxsw_thermal_module *tz_module_arr;
> u8 tz_module_num;
> struct mlxsw_thermal_module *tz_gearbox_arr;
> @@ -280,9 +278,7 @@ static int mlxsw_thermal_unbind(struct
> thermal_zone_device *tzdev,
> static int mlxsw_thermal_get_mode(struct thermal_zone_device *tzdev,
> enum thermal_device_mode *mode)
> {
> - struct mlxsw_thermal *thermal = tzdev->devdata;
> -
> - *mode = thermal->mode;
> + *mode = tzdev->mode;
>
> return 0;
> }
> @@ -299,9 +295,9 @@ static int mlxsw_thermal_set_mode(struct
> thermal_zone_device *tzdev,
> else
> tzdev->polling_delay = 0;
>
> + tzdev->mode = m
Re: [PATCH v4 02/11] thermal: Store thermal mode in a dedicated enum
On 5/29/20 8:13 AM, Andrzej Pietrasiewicz wrote:
> Hi Guenter,
>
> W dniu 29.05.2020 o 16:48, Guenter Roeck pisze:
>> On Thu, May 28, 2020 at 09:20:42PM +0200, Andrzej Pietrasiewicz wrote:
>>> Prepare for storing mode in struct thermal_zone_device.
>>>
>>> Signed-off-by: Andrzej Pietrasiewicz
>>> ---
>>> drivers/acpi/thermal.c | 27 +--
>>> drivers/platform/x86/acerhdf.c | 8 --
>>> .../intel/int340x_thermal/int3400_thermal.c | 18 +
>>> 3 files changed, 25 insertions(+), 28 deletions(-)
>
>
>
>>> @@ -544,27 +543,25 @@ static int thermal_set_mode(struct
>>> thermal_zone_device *thermal,
>>> enum thermal_device_mode mode)
>>> {
>>> struct acpi_thermal *tz = thermal->devdata;
>>> - int enable;
>>> if (!tz)
>>> return -EINVAL;
>>> + if (mode != THERMAL_DEVICE_DISABLED &&
>>> + mode != THERMAL_DEVICE_ENABLED)
>>> + return -EINVAL;
>>
>> Personally I find this check unnecessary: The enum has no other values,
>> and it is verifyable that the callers provide the enum and not some other
>> value.
>
> It is getting removed in PATCH 10/11.
>
>
>>> + if (mode != THERMAL_DEVICE_ENABLED &&
>>> + mode != THERMAL_DEVICE_DISABLED)
>>> return -EINVAL;
>>
>> Same as above.
>
> ditto.
Hmm, I think that would be better done with this patch. But I guess
that is a bit of PoV, so
Reviewed-by: Guenter Roeck
since I don't have any other objections/observations.
Guenter
Re: [PATCH v4 02/11] thermal: Store thermal mode in a dedicated enum
On 5/29/20 8:08 AM, Andrzej Pietrasiewicz wrote: > W dniu 29.05.2020 o 17:05, Guenter Roeck pisze: >> On Thu, May 28, 2020 at 09:20:42PM +0200, Andrzej Pietrasiewicz wrote: >>> Prepare for storing mode in struct thermal_zone_device. >>> >>> Signed-off-by: Andrzej Pietrasiewicz >> >> What is the baseline for this series ? I can't get this patch to apply >> on top of current mainline, nor on v5.6, nor on top of linux-next. >> >> Thanks, >> Guenter >> > > git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git, branch > "testing". > > base-commit: 351f4911a477ae01239c42f771f621d85b06ea10 > Thanks! Guenter
Re: [PATCH v4 02/11] thermal: Store thermal mode in a dedicated enum
On Thu, May 28, 2020 at 09:20:42PM +0200, Andrzej Pietrasiewicz wrote: > Prepare for storing mode in struct thermal_zone_device. > > Signed-off-by: Andrzej Pietrasiewicz What is the baseline for this series ? I can't get this patch to apply on top of current mainline, nor on v5.6, nor on top of linux-next. Thanks, Guenter
Re: [PATCH v4 03/11] thermal: Add current mode to thermal zone device
On Thu, May 28, 2020 at 09:20:43PM +0200, Andrzej Pietrasiewicz wrote:
> Prepare for changing the place where the mode is stored: now it is in
> drivers, which might or might not implement get_mode()/set_mode() methods.
> A lot of cleanup can be done thanks to storing it in struct tzd. The
> get_mode() methods will become redundant.
>
> Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Guenter Roeck
> ---
> include/linux/thermal.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 216185bb3014..5f91d7f04512 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -128,6 +128,7 @@ struct thermal_cooling_device {
> * @trip_temp_attrs: attributes for trip points for sysfs: trip temperature
> * @trip_type_attrs: attributes for trip points for sysfs: trip type
> * @trip_hyst_attrs: attributes for trip points for sysfs: trip hysteresis
> + * @mode:current mode of this thermal zone
> * @devdata: private pointer for device private data
> * @trips: number of trip points the thermal zone supports
> * @trips_disabled; bitmap for disabled trips
> @@ -170,6 +171,7 @@ struct thermal_zone_device {
> struct thermal_attr *trip_temp_attrs;
> struct thermal_attr *trip_type_attrs;
> struct thermal_attr *trip_hyst_attrs;
> + enum thermal_device_mode mode;
> void *devdata;
> int trips;
> unsigned long trips_disabled; /* bitmap for disabled trips */
Re: [PATCH v4 01/11] acpi: thermal: Fix error handling in the register function
On Thu, May 28, 2020 at 09:20:41PM +0200, Andrzej Pietrasiewicz wrote:
> The acpi_thermal_register_thermal_zone() is missing any error handling.
> This needs to be fixed.
>
> Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Guenter Roeck
> ---
> drivers/acpi/thermal.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 19067a5e5293..6de8066ca1e7 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -901,23 +901,35 @@ static int acpi_thermal_register_thermal_zone(struct
> acpi_thermal *tz)
> result = sysfs_create_link(&tz->device->dev.kobj,
> &tz->thermal_zone->device.kobj,
> "thermal_zone");
> if (result)
> - return result;
> + goto unregister_tzd;
>
> result = sysfs_create_link(&tz->thermal_zone->device.kobj,
> &tz->device->dev.kobj, "device");
> if (result)
> - return result;
> + goto remove_tz_link;
>
> status = acpi_bus_attach_private_data(tz->device->handle,
> tz->thermal_zone);
> - if (ACPI_FAILURE(status))
> - return -ENODEV;
> + if (ACPI_FAILURE(status)) {
> + result = -ENODEV;
> + goto remove_dev_link;
> + }
>
> tz->tz_enabled = 1;
>
> dev_info(&tz->device->dev, "registered as thermal_zone%d\n",
>tz->thermal_zone->id);
> +
> return 0;
> +
> +remove_dev_link:
> + sysfs_remove_link(&tz->thermal_zone->device.kobj, "device");
> +remove_tz_link:
> + sysfs_remove_link(&tz->device->dev.kobj, "thermal_zone");
> +unregister_tzd:
> + thermal_zone_device_unregister(tz->thermal_zone);
> +
> + return result;
> }
>
> static void acpi_thermal_unregister_thermal_zone(struct acpi_thermal *tz)
Re: [PATCH v4 02/11] thermal: Store thermal mode in a dedicated enum
On Thu, May 28, 2020 at 09:20:42PM +0200, Andrzej Pietrasiewicz wrote:
> Prepare for storing mode in struct thermal_zone_device.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/acpi/thermal.c| 27 +--
> drivers/platform/x86/acerhdf.c| 8 --
> .../intel/int340x_thermal/int3400_thermal.c | 18 +
> 3 files changed, 25 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 6de8066ca1e7..fb46070c66d8 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -172,7 +172,7 @@ struct acpi_thermal {
> struct acpi_thermal_trips trips;
> struct acpi_handle_list devices;
> struct thermal_zone_device *thermal_zone;
> - int tz_enabled;
> + enum thermal_device_mode mode;
> int kelvin_offset; /* in millidegrees */
> struct work_struct thermal_check_work;
> };
> @@ -500,7 +500,7 @@ static void acpi_thermal_check(void *data)
> {
> struct acpi_thermal *tz = data;
>
> - if (!tz->tz_enabled)
> + if (tz->mode != THERMAL_DEVICE_ENABLED)
> return;
>
> thermal_zone_device_update(tz->thermal_zone,
> @@ -534,8 +534,7 @@ static int thermal_get_mode(struct thermal_zone_device
> *thermal,
> if (!tz)
> return -EINVAL;
>
> - *mode = tz->tz_enabled ? THERMAL_DEVICE_ENABLED :
> - THERMAL_DEVICE_DISABLED;
> + *mode = tz->mode;
>
> return 0;
> }
> @@ -544,27 +543,25 @@ static int thermal_set_mode(struct thermal_zone_device
> *thermal,
> enum thermal_device_mode mode)
> {
> struct acpi_thermal *tz = thermal->devdata;
> - int enable;
>
> if (!tz)
> return -EINVAL;
>
> + if (mode != THERMAL_DEVICE_DISABLED &&
> + mode != THERMAL_DEVICE_ENABLED)
> + return -EINVAL;
Personally I find this check unnecessary: The enum has no other values,
and it is verifyable that the callers provide the enum and not some other
value.
> /*
>* enable/disable thermal management from ACPI thermal driver
>*/
> - if (mode == THERMAL_DEVICE_ENABLED)
> - enable = 1;
> - else if (mode == THERMAL_DEVICE_DISABLED) {
> - enable = 0;
> + if (mode == THERMAL_DEVICE_DISABLED)
> pr_warn("thermal zone will be disabled\n");
> - } else
> - return -EINVAL;
>
> - if (enable != tz->tz_enabled) {
> - tz->tz_enabled = enable;
> + if (mode != tz->mode) {
> + tz->mode = mode;
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "%s kernel ACPI thermal control\n",
> - tz->tz_enabled ? "Enable" : "Disable"));
> + tz->mode == THERMAL_DEVICE_ENABLED ?
> + "Enable" : "Disable"));
> acpi_thermal_check(tz);
> }
> return 0;
> @@ -915,7 +912,7 @@ static int acpi_thermal_register_thermal_zone(struct
> acpi_thermal *tz)
> goto remove_dev_link;
> }
>
> - tz->tz_enabled = 1;
> + tz->mode = THERMAL_DEVICE_ENABLED;
>
> dev_info(&tz->device->dev, "registered as thermal_zone%d\n",
>tz->thermal_zone->id);
> diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
> index 8cc86f4e3ac1..830a8b060e74 100644
> --- a/drivers/platform/x86/acerhdf.c
> +++ b/drivers/platform/x86/acerhdf.c
> @@ -68,6 +68,7 @@ static int kernelmode = 1;
> #else
> static int kernelmode;
> #endif
> +static enum thermal_device_mode thermal_mode;
>
> static unsigned int interval = 10;
> static unsigned int fanon = 6;
> @@ -397,6 +398,7 @@ static inline void acerhdf_revert_to_bios_mode(void)
> {
> acerhdf_change_fanstate(ACERHDF_FAN_AUTO);
> kernelmode = 0;
> + thermal_mode = THERMAL_DEVICE_DISABLED;
> if (thz_dev)
> thz_dev->polling_delay = 0;
> pr_notice("kernel mode fan control OFF\n");
> @@ -404,6 +406,7 @@ static inline void acerhdf_revert_to_bios_mode(void)
> static inline void acerhdf_enable_kernelmode(void)
> {
> kernelmode = 1;
> + thermal_mode = THERMAL_DEVICE_ENABLED;
>
> thz_dev->polling_delay = interval*1000;
> thermal_zone_device_update(thz_dev, THERMAL_EVENT_UNSPECIFIED);
> @@ -416,8 +419,7 @@ static int acerhdf_get_mode(struct thermal_zone_device
> *thermal,
> if (verbose)
> pr_notice("kernel mode fan control %d\n", kernelmode);
>
> - *mode = (kernelmode) ? THERMAL_DEVICE_ENABLED
> - : THERMAL_DEVICE_DISABLED;
> + *mode = thermal_mode;
>
> return 0;
> }
> @@ -739,6 +741,8 @@ static int __init acerhdf_register_thermal(void)
> if (IS_ERR(cl_dev))
> return -EINVAL;
>
> + thermal_mode = kernelmode ?
> + THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED;
> thz_dev = thermal_
Re: [PATCH 16/17] dt-bindings: watchdog: renesas,wdt: Document r8a7742 support
On Fri, May 15, 2020 at 04:08:56PM +0100, Lad Prabhakar wrote: > RZ/G1H (R8A7742) watchdog implementation is compatible with R-Car Gen2, > therefore add relevant documentation. > > Signed-off-by: Lad Prabhakar > Reviewed-by: Marian-Cristian Rotariu > > Reviewed-by: Wolfram Sang > Reviewed-by: Geert Uytterhoeven Reviewed-by: Guenter Roeck > --- > Documentation/devicetree/bindings/watchdog/renesas,wdt.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt > b/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt > index 79b3c62..e42fd30 100644 > --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt > @@ -5,6 +5,7 @@ Required properties: > fallback compatible string when compatible with the generic > version. > Examples with soctypes are: > + - "renesas,r8a7742-wdt" (RZ/G1H) >- "renesas,r8a7743-wdt" (RZ/G1M) >- "renesas,r8a7744-wdt" (RZ/G1N) >- "renesas,r8a7745-wdt" (RZ/G1E)
Re: [PATCH 2/2] Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe
On Sun, Sep 01, 2019 at 11:06:05AM +0300, Kalle Valo wrote:
> Guenter Roeck writes:
>
> > Hi,
> >
> > On Sat, Aug 03, 2019 at 08:31:01PM -0400, Hui Peng wrote:
> >> The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
> >> are initialized to point to the containing `ath10k_usb` object
> >> according to endpoint descriptors read from the device side, as shown
> >> below in `ath10k_usb_setup_pipe_resources`:
> >>
> >> for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
> >> endpoint = &iface_desc->endpoint[i].desc;
> >>
> >> // get the address from endpoint descriptor
> >> pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb,
> >> endpoint->bEndpointAddress,
> >> &urbcount);
> >> ..
> >> // select the pipe object
> >> pipe = &ar_usb->pipes[pipe_num];
> >>
> >> // initialize the ar_usb field
> >> pipe->ar_usb = ar_usb;
> >> }
> >>
> >> The driver assumes that the addresses reported in endpoint
> >> descriptors from device side to be complete. If a device is
> >> malicious and does not report complete addresses, it may trigger
> >> NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and
> >> `ath10k_usb_free_urb_to_pipe`.
> >>
> >> This patch fixes the bug by preventing potential NULL-ptr-deref.
> >>
> >> Signed-off-by: Hui Peng
> >> Reported-by: Hui Peng
> >> Reported-by: Mathias Payer
> >
> > This patch fixes CVE-2019-15099, which has CVSS scores of 7.5 (CVSS 3.0)
> > and 7.8 (CVSS 2.0). Yet, I don't find it in the upstream kernel or in Linux
> > next.
> >
> > Is the patch going to be applied to the upstream kernel anytime soon ?
>
> Same answer as in patch 1:
>
> https://patchwork.kernel.org/patch/11074655/
>
Sorry to bring this up again. The ath6k patch made it into the upstream
kernel, but the ath10k patch didn't. Did it get lost, or was there a
reason not to apply this patch ?
Thanks,
Guenter
Re: [PATCH v2 1/2] net: phy: realtek: Add rtl8211e rx/tx delays config
Hi,
On Sat, Apr 27, 2019 at 12:21:11AM +0300, Serge Semin wrote:
> There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
> delays to TXC and RXC for TXD/RXD latching. Alas this is the only
> documented info regarding the RGMII timing control configurations the PHY
> provides. It turns out the same settings can be setup via MDIO registers
> hidden in the extension pages layout. Particularly the extension page 0xa4
> provides a register 0x1c, which bits 1 and 2 control the described delays.
> They are used to implement the "rgmii-{id,rxid,txid}" phy-mode.
>
> The hidden RGMII configs register utilization was found in the rtl8211e
> U-boot driver:
> https://elixir.bootlin.com/u-boot/v2019.01/source/drivers/net/phy/realtek.c#L99
>
> There is also a freebsd-folks discussion regarding this register:
> https://reviews.freebsd.org/D13591
>
> It confirms that the register bits field must control the so called
> configuration pins described in the table 12-13 of the official PHY
> datasheet:
> 8:6 = PHY Address
> 5:4 = Auto-Negotiation
> 3 = Interface Mode Select
> 2 = RX Delay
> 1 = TX Delay
> 0 = SELRGV
>
> Signed-off-by: Serge Semin
> Reviewed-by: Andrew Lunn
This patch results in a crash when running arm:ast2500-evb in qemu.
[4.894572] [] *pgd=
[4.895329] Internal error: Oops: 8005 [#1] ARM
[4.896066] CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-09698-g1fb3b52 #1
[4.896364] Hardware name: Generic DT based system
[4.896823] PC is at 0x0
[4.897037] LR is at phy_select_page+0x3c/0x7c
Debugging shows that phydev->drv->write_page and phydev->drv->read_page
are NULL, so the crash isn't entirely surprising.
What I don't understand is how this can work in the first place.
The modified entry in realtek_drvs[] doesn't have read_page/write_page
functions defined, yet rtl8211e_config_init() depends on it.
What am I missing here ?
Thanks,
Guenter
Re: [PATCH] bpf: enable program stats
On Fri, Mar 01, 2019 at 02:17:40PM -0800, Eric Dumazet wrote:
>
>
> On 03/01/2019 02:03 PM, Guenter Roeck wrote:
> > Hi,
> >
> > On Mon, Feb 25, 2019 at 02:28:39PM -0800, Alexei Starovoitov wrote:
> >> JITed BPF programs are indistinguishable from kernel functions, but unlike
> >> kernel code BPF code can be changed often.
> >> Typical approach of "perf record" + "perf report" profiling and tuning of
> >> kernel code works just as well for BPF programs, but kernel code doesn't
> >> need to be monitored whereas BPF programs do.
> >> Users load and run large amount of BPF programs.
> >> These BPF stats allow tools monitor the usage of BPF on the server.
> >> The monitoring tools will turn sysctl kernel.bpf_stats_enabled
> >> on and off for few seconds to sample average cost of the programs.
> >> Aggregated data over hours and days will provide an insight into cost of
> >> BPF
> >> and alarms can trigger in case given program suddenly gets more expensive.
> >>
> >> The cost of two sched_clock() per program invocation adds ~20 nsec.
> >> Fast BPF progs (like selftests/bpf/progs/test_pkt_access.c) will slow down
> >> from ~10 nsec to ~30 nsec.
> >> static_key minimizes the cost of the stats collection.
> >> There is no measurable difference before/after this patch
> >> with kernel.bpf_stats_enabled=0
> >>
> >
> > This patch causes my qemu tests for 'parisc' to crash. Reverting this patch
> > as well as "bpf: expose program stats via bpf_prog_info" fixes the problem.
> >
> > Crash log and bisect results are attached. Bisect ends with the merge;
> > I identified the two patches manually.
> >
> > I suspect that
> > prog->aux->stats = alloc_percpu_gfp(struct bpf_prog_stats, gfp_flags);
> > ...
> > u64_stats_init(&prog->aux->stats->syncp);
> > may be wrong. At the very least it looks odd, and I don't find a similar use
> > of u64_stats_init() anywhere else in the kernel.
>
> Yes, a loop is needed there.
>
> Something like :
>
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index
> 1c14c347f3cfe1f7c0cf8a7eccff8135b16df81f..3f08c257858e1570339cd64a6351824bcc332ee3
> 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -109,6 +109,7 @@ struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t
> gfp_extra_flags)
> {
> gfp_t gfp_flags = GFP_KERNEL | __GFP_ZERO | gfp_extra_flags;
> struct bpf_prog *prog;
> + int cpu;
>
> prog = bpf_prog_alloc_no_stats(size, gfp_extra_flags);
> if (!prog)
> @@ -121,7 +122,12 @@ struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t
> gfp_extra_flags)
> return NULL;
> }
>
> - u64_stats_init(&prog->aux->stats->syncp);
> + for_each_possible_cpu(cpu) {
> + struct bpf_prog_stats *pstats;
> +
> + pstats = per_cpu_ptr(prog->aux->stats, cpu);
> + u64_stats_init(&pstats->syncp);
> + }
> return prog;
> }
> EXPORT_SYMBOL_GPL(bpf_prog_alloc);
>
Yes, that works, or at least my test no longer crashes after applying the
above patch. Feel free to add
Tested-by: Guenter Roeck
Thanks,
Guenter
Re: [PATCH] bpf: enable program stats
Hi, On Mon, Feb 25, 2019 at 02:28:39PM -0800, Alexei Starovoitov wrote: > JITed BPF programs are indistinguishable from kernel functions, but unlike > kernel code BPF code can be changed often. > Typical approach of "perf record" + "perf report" profiling and tuning of > kernel code works just as well for BPF programs, but kernel code doesn't > need to be monitored whereas BPF programs do. > Users load and run large amount of BPF programs. > These BPF stats allow tools monitor the usage of BPF on the server. > The monitoring tools will turn sysctl kernel.bpf_stats_enabled > on and off for few seconds to sample average cost of the programs. > Aggregated data over hours and days will provide an insight into cost of BPF > and alarms can trigger in case given program suddenly gets more expensive. > > The cost of two sched_clock() per program invocation adds ~20 nsec. > Fast BPF progs (like selftests/bpf/progs/test_pkt_access.c) will slow down > from ~10 nsec to ~30 nsec. > static_key minimizes the cost of the stats collection. > There is no measurable difference before/after this patch > with kernel.bpf_stats_enabled=0 > This patch causes my qemu tests for 'parisc' to crash. Reverting this patch as well as "bpf: expose program stats via bpf_prog_info" fixes the problem. Crash log and bisect results are attached. Bisect ends with the merge; I identified the two patches manually. I suspect that prog->aux->stats = alloc_percpu_gfp(struct bpf_prog_stats, gfp_flags); ... u64_stats_init(&prog->aux->stats->syncp); may be wrong. At the very least it looks odd, and I don't find a similar use of u64_stats_init() anywhere else in the kernel. Guenter --- Crash logs: .. PDC_CHASSIS: Fault (1), CHASSIS 0 Backtrace: [<109c6dac>] bpf_prog_create+0x58/0xc4 [<10131fd0>] 0x10131fd0 [<101314ac>] 0x101314ac [<1018e1c4>] do_one_initcall+0x54/0x1a8 [<101011e8>] 0x101011e8 [<10b218d0>] kernel_init+0x1c/0x150 [<1019601c>] ret_from_kernel_thread+0x1c/0x24 Kernel Fault: Code=18 (Data memory protection/unaligned access trap) at addr 10193fd0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc8-next-20190301 #1 Hardware name: 9000/778/B160L YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 0111 Not tainted r00-03 00043f0f 1017ec10 10260078 2f83c380 r04-07 0dc0 0081 2f834620 10dbbb44 r08-11 10dcf000 0002 10179528 10e4cc10 r12-15 10e4cc10 1013c010 0008 f0018f04 r16-19 f001672e 0001 0028 1131d000 r20-23 11370fd8 0018 0006 r24-27 0018 2f834620 10db9c10 r28-31 10193fc0 0400 2f83c400 11370fc0 sr00-03 sr04-07 IASQ: IAOQ: 10260088 1026008c IIR: 6b800020ISR: IOR: 10193fd0 CPU:0 CR30: 2f83c000 CR31: ORIG_R28: IAOQ[0]: bpf_prog_alloc+0x50/0x8c IAOQ[1]: bpf_prog_alloc+0x54/0x8c RP(r2): bpf_prog_alloc+0x40/0x8c Backtrace: [<109c6dac>] bpf_prog_create+0x58/0xc4 [<10131fd0>] 0x10131fd0 [<101314ac>] 0x101314ac [<1018e1c4>] do_one_initcall+0x54/0x1a8 [<101011e8>] 0x101011e8 [<10b218d0>] kernel_init+0x1c/0x150 [<1019601c>] ret_from_kernel_thread+0x1c/0x24 SeaBIOS wants SYSTEM HALT. Note: The missing call is from ptp_classifier_init(), called from sock_init(). The actual crash occurs in u64_stats_init(). --- Another crash log: ... random: get_random_u32 called from bucket_table_alloc+0xa0/0x1e4 with crng_init=0 clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns futex hash table entries: 1024 (order: 3, 49152 bytes) xor: measuring software checksum speed 8regs : 1326.000 MB/sec 8regs_prefetch: 719.000 MB/sec 32regs: 722.000 MB/sec 32regs_prefetch: 690.000 MB/sec xor: using function: 8regs (1326.000 MB/sec) PDC_CHASSIS: Fault (1), CHASSIS 0 Backtrace: [<109c6dac>] bpf_prog_create+0x58/0xc4 [<10131fd0>] 0x10131fd0 [<101314ac>] 0x101314ac [<1018e1c4>] do_one_initcall+0x54/0x1a8 [<101011e8>] 0x101011e8 [<10b218d0>] kernel_init+0x1c/0x150 [<1019601c>] ret_from_kernel_thread+0x1c/0x24 Kernel Fault: Code=18 (Data memory protection/unaligned access trap) at addr 10193fd0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc8-next-20190301 #1 Hardware name: 9000/778/B160L YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 01100011 Not tainted r00-03 00063f0f 1017ec10 10260078 2fc3c380 r04-07 0dc0 0081 2fc356e0 10dbbb44 r08-11 10dcf000 0002 10179528 10e4cc10 r12-15 10e4cc10 1013c010 0008 f0018f04 r16-19 f001672e 0001 0028 1131d000 r20-23 11370fd8 0018 0006 r24-27 0018 2fc356e0 10db9c10 r28-31 10193fc0 0400 2fc3c400 11370fc0 sr00-03 sr04-07 IASQ: IAOQ: 10260088 1026008c IIR: 6b800020ISR: IOR: 10193fd0 CPU:0 CR30: 2fc3c000
Re: [PATCH] bpfilter: re-add header search paths to tools include to fix build error
On 2/21/19 7:23 PM, Masahiro Yamada wrote:
I thought header search paths to tools/include(/uapi) were unneeded,
but it looks like a build error occurs depending on the compiler.
Commit 303a339f30a9 ("bpfilter: remove extra header search paths for
bpfilter_umh") reintroduced the build error fixed by commit ae40832e53c3
("bpfilter: fix a build err").
Apology for the breakage, and thanks to Guenter for reporting this.
Fixes: 303a339f30a9 ("bpfilter: remove extra header search paths for
bpfilter_umh")
Reported-by: Guenter Roeck
Signed-off-by: Masahiro Yamada
Tested-by: Guenter Roeck
---
Guenter,
Sorry for bothering you, but
could you please test this with your compiler?
I am also using GCC 7.3, but my compiler cannot
reproduce the build error.
net/bpfilter/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
index 5d6c776..854395f 100644
--- a/net/bpfilter/Makefile
+++ b/net/bpfilter/Makefile
@@ -5,6 +5,7 @@
hostprogs-y := bpfilter_umh
bpfilter_umh-objs := main.o
+KBUILD_HOSTCFLAGS += -Itools/include/ -Itools/include/uapi
HOSTCC := $(CC)
ifeq ($(CONFIG_BPFILTER_UMH), y)
Re: [PATCH] bpfilter: remove extra header search paths for bpfilter_umh
On Fri, Feb 22, 2019 at 12:54:47AM +0900, Masahiro Yamada wrote:
> On Thu, Feb 21, 2019 at 11:46 PM Guenter Roeck wrote:
> >
> > On Thu, Jan 31, 2019 at 12:15:35PM +0900, Masahiro Yamada wrote:
> > > Currently, the header search paths -Itools/include and
> > > -Itools/include/uapi are not used. Let's drop the unused code.
> > >
> > > We can remove -I. too by fixing up one C file.
> > >
> >
> > This patch reintroduces the problem last fixed with commit ae40832e53c3
> > ("bpfilter: fix a build err"). Seen (at least) with gcc 7.4.0, 8.2.0.
> > binutils version is 2.31.1. Reverting this patch fixes the problem.
>
>
> Hmm. I cannot reproduce the build error with my gcc,
> but you are right.
>
Maybe it has less to do with the gcc version and more with how the
toolchain is built. I see the problem with toolchains generated
using buildroot.
>
> I'd like to get back only
> 'KBUILD_HOSTCFLAGS += -Itools/include/ -Itools/include/uapi'
> instead of the full revert.
>
That doesn't work for me. I need
KBUILD_HOSTCFLAGS += -I. -Itools/include/uapi
Just don't ask me why.
Guenter
> If David is fine with it, I can send a patch with filling commit log.
>
>
>
> Thanks.
>
>
>
> > Guenter
> >
> > > Signed-off-by: Masahiro Yamada
> > > Signed-off-by: David S. Miller
> > > ---
> > > net/bpfilter/Makefile | 1 -
> > > net/bpfilter/main.c | 2 +-
> > > 2 files changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> > > index 0947ee7f70d5..5d6c7760142d 100644
> > > --- a/net/bpfilter/Makefile
> > > +++ b/net/bpfilter/Makefile
> > > @@ -5,7 +5,6 @@
> > >
> > > hostprogs-y := bpfilter_umh
> > > bpfilter_umh-objs := main.o
> > > -KBUILD_HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
> > > HOSTCC := $(CC)
> > >
> > > ifeq ($(CONFIG_BPFILTER_UMH), y)
> > > diff --git a/net/bpfilter/main.c b/net/bpfilter/main.c
> > > index 1317f108df8a..61ce8454a88e 100644
> > > --- a/net/bpfilter/main.c
> > > +++ b/net/bpfilter/main.c
> > > @@ -6,7 +6,7 @@
> > > #include
> > > #include
> > > #include
> > > -#include "include/uapi/linux/bpf.h"
> > > +#include "../../include/uapi/linux/bpf.h"
> > > #include
> > > #include "msgfmt.h"
> > >
> > > --
> > > 2.7.4
>
>
>
> --
> Best Regards
>
> Masahiro Yamada
Re: [PATCH] bpfilter: remove extra header search paths for bpfilter_umh
On Thu, Jan 31, 2019 at 12:15:35PM +0900, Masahiro Yamada wrote:
> Currently, the header search paths -Itools/include and
> -Itools/include/uapi are not used. Let's drop the unused code.
>
> We can remove -I. too by fixing up one C file.
>
This patch reintroduces the problem last fixed with commit ae40832e53c3
("bpfilter: fix a build err"). Seen (at least) with gcc 7.4.0, 8.2.0.
binutils version is 2.31.1. Reverting this patch fixes the problem.
Guenter
> Signed-off-by: Masahiro Yamada
> Signed-off-by: David S. Miller
> ---
> net/bpfilter/Makefile | 1 -
> net/bpfilter/main.c | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> index 0947ee7f70d5..5d6c7760142d 100644
> --- a/net/bpfilter/Makefile
> +++ b/net/bpfilter/Makefile
> @@ -5,7 +5,6 @@
>
> hostprogs-y := bpfilter_umh
> bpfilter_umh-objs := main.o
> -KBUILD_HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
> HOSTCC := $(CC)
>
> ifeq ($(CONFIG_BPFILTER_UMH), y)
> diff --git a/net/bpfilter/main.c b/net/bpfilter/main.c
> index 1317f108df8a..61ce8454a88e 100644
> --- a/net/bpfilter/main.c
> +++ b/net/bpfilter/main.c
> @@ -6,7 +6,7 @@
> #include
> #include
> #include
> -#include "include/uapi/linux/bpf.h"
> +#include "../../include/uapi/linux/bpf.h"
> #include
> #include "msgfmt.h"
>
> --
> 2.7.4
Re: [PATCH net-next 09/12] mlxsw: core: Extend hwmon interface with fan fault attribute
On 2/13/19 11:06 PM, Vadim Pasternak wrote:
-Original Message-
From: Guenter Roeck On Behalf Of Guenter Roeck
Sent: Wednesday, February 13, 2019 5:03 PM
To: Andrew Lunn ; Ido Schimmel
Cc: netdev@vger.kernel.org; da...@davemloft.net; Jiri Pirko
; mlxsw ; Vadim Pasternak
Subject: Re: [PATCH net-next 09/12] mlxsw: core: Extend hwmon interface with
fan fault attribute
On 2/13/19 5:53 AM, Andrew Lunn wrote:
On Wed, Feb 13, 2019 at 11:28:53AM +, Ido Schimmel wrote:
From: Vadim Pasternak
Add new fan hwmon attribute for exposing fan faults (fault indication
is read from Fan Out of Range Event Register).
Signed-off-by: Vadim Pasternak
Reviewed-by: Jiri Pirko
Signed-off-by: Ido Schimmel
Hi Ido
You should include the HWMON maintainer in the Cc: list.
I would not be too surprised if he says to use
hwmon_device_register_with_info().
I would ask to do that for new drivers, but this is is not a new driver.
On top of that, I wasn't included in its initial review. Since I wasn't
involved, I
have no idea what shape the driver is in, and for sure won't review it now (to
retain my sanity).
Only comment I have is that using the _with_info API and using devm_ functions
might simplify the driver a lot. I'll be happy to do a review if/when that is
done.
Guenter
Hi Guenter,
Thank you for your comments.
But, this patch adds one new FAN attribute to the existing infrastructure.
At the time mlxsw core_hwmon module has been submitted, the API
hwmon_device_register_with_info() was not available yet.
Of course in a new modules we are using this API, like in
our mlxreg-fan for example.
The same is relevant for the patch 10/12 from this series – it also extends
the existing infrastructure.
But there, even in case of a new code the config structure for
hwmon_device_register_with_info() would be look like:
{
/* 3 entries like below - for chip ambient temperatures (could be from
1 to 3. */
HWMON_F_INPUT | HWMON_T_HIGHEST | HWMON_T_RESET_HISTORY,
...
/* 128 entries like below - for modules temperatures (could be from 16
to 128. */
HWMON_F_INPUT | HWMON_T_CRIT | HWMON_T_EMERGENCY, HWMON_T_FAULT |
HWMON_T_LABEL,
...
/* 64 entries like below - for interconnects temperatures (could be
from 0 to 64). */
HWMON_F_INPUT | HWMON_T_HIGHEST | HWMON_T_RESET_HISTORY | HWMON_T_LABEL,
0
};
I would probably have created the above dynamically, just like the current code
does,
except it now generates all the attributes. AFAICS the current code doesn't
leave holes
in attribute numbering, so allocating everything statically doesn't really make
much
sense. Note that you would need separate arrays, one per sensor type
(temperature, fan,
pwm).
Means we'll have 195 lines for configuration description and in case future
systems will
be equipped with the bigger number of port slots and/or with the bigger number
of
interconnects devices, the below structure will require modification.
Modification will be not necessary, in case we'll keep configuration like it is
now.
Regarding devm_ API - it has been used initially in core_hwmon module, but the
in
commit (9b3bc7db759e) it has been removed. And it was a good reason for that.
Chip can be re-programmed after initialization in case driver determines it
needs to
flash a new firmware version. In such case after re-programming driver will make
registration again and among the other stuff it will make new registration with
hwmon subsystem. And in case it 's registered with
hwmon subsystem using devm_hwmon_device_register_with_groups(), the old
hwmon device (registered before the flashing) was never unregistered and was
referencing stale data, resulting in a use-after free.
Well, devm_ obviously doesn't work if the object lifetime doesn't match device
lifetime.
Guenter
Re: [PATCH net-next 09/12] mlxsw: core: Extend hwmon interface with fan fault attribute
On 2/13/19 5:53 AM, Andrew Lunn wrote: On Wed, Feb 13, 2019 at 11:28:53AM +, Ido Schimmel wrote: From: Vadim Pasternak Add new fan hwmon attribute for exposing fan faults (fault indication is read from Fan Out of Range Event Register). Signed-off-by: Vadim Pasternak Reviewed-by: Jiri Pirko Signed-off-by: Ido Schimmel Hi Ido You should include the HWMON maintainer in the Cc: list. I would not be too surprised if he says to use hwmon_device_register_with_info(). I would ask to do that for new drivers, but this is is not a new driver. On top of that, I wasn't included in its initial review. Since I wasn't involved, I have no idea what shape the driver is in, and for sure won't review it now (to retain my sanity). Only comment I have is that using the _with_info API and using devm_ functions might simplify the driver a lot. I'll be happy to do a review if/when that is done. Guenter
Re: [PATCH ghak90 (was ghak32) V4 01/10] audit: collect audit task parameters
On Fri, Jan 04, 2019 at 09:57:35AM -0500, Richard Guy Briggs wrote: > On 2019-01-03 18:50, Guenter Roeck wrote: > > Hi Richard, > > > > On Tue, Jul 31, 2018 at 04:07:36PM -0400, Richard Guy Briggs wrote: > > > The audit-related parameters in struct task_struct should ideally be > > > collected together and accessed through a standard audit API. > > > > > > Collect the existing loginuid, sessionid and audit_context together in a > > > new struct audit_task_info called "audit" in struct task_struct. > > > > > > Use kmem_cache to manage this pool of memory. > > > Un-inline audit_free() to be able to always recover that memory. > > > > > > See: https://github.com/linux-audit/audit-kernel/issues/81 > > > > > > Signed-off-by: Richard Guy Briggs > > > > Overall I am not sure if keeping task_struct a bit smaller is worth > > the added complexity, but I guess that is just me. > > The motivation was to consolidate all the audit bits into one pointer, > isolating them from the rest of the kernel, restricting access only to > helper functions to prevent abuse by other subsystems and trying to > reduce kABI issues in the future. I agree it is a bit more complex. It > was provoked by the need to add contid which seemed to make the most > sense as a peer to loginuid and sessionid, and adding it to task_struct > would have made it a bit too generic and available. > > This is addressed at some length by Paul Moore here in v2: > https://lkml.org/lkml/2018/4/18/759 > That makes sense. Thanks a lot for the clarification. Guenter
Re: [PATCH ghak90 (was ghak32) V4 01/10] audit: collect audit task parameters
Hi Richard,
On Tue, Jul 31, 2018 at 04:07:36PM -0400, Richard Guy Briggs wrote:
> The audit-related parameters in struct task_struct should ideally be
> collected together and accessed through a standard audit API.
>
> Collect the existing loginuid, sessionid and audit_context together in a
> new struct audit_task_info called "audit" in struct task_struct.
>
> Use kmem_cache to manage this pool of memory.
> Un-inline audit_free() to be able to always recover that memory.
>
> See: https://github.com/linux-audit/audit-kernel/issues/81
>
> Signed-off-by: Richard Guy Briggs
Overall I am not sure if keeping task_struct a bit smaller is worth
the added complexity, but I guess that is just me.
Anyway, couple of nitpicks. Please feel free to ignore, and my apologies
if some of all of the comments are duplicates.
Guenter
> ---
> include/linux/audit.h | 34 --
> include/linux/sched.h | 5 +
> init/init_task.c | 3 +--
> init/main.c | 2 ++
> kernel/auditsc.c | 51
> ++-
> kernel/fork.c | 4 +++-
> 6 files changed, 73 insertions(+), 26 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 9334fbe..8964332 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -219,8 +219,15 @@ static inline void audit_log_task_info(struct
> audit_buffer *ab,
>
> /* These are defined in auditsc.c */
> /* Public API */
Not sure if the structure below belongs after "Public API".
Is it part of the public API ?
> +struct audit_task_info {
> + kuid_t loginuid;
> + unsigned intsessionid;
> + struct audit_context*ctx;
> +};
Add empty line ?
> +extern struct audit_task_info init_struct_audit;
> +extern void __init audit_task_init(void);
> extern int audit_alloc(struct task_struct *task);
> -extern void __audit_free(struct task_struct *task);
> +extern void audit_free(struct task_struct *task);
> extern void __audit_syscall_entry(int major, unsigned long a0, unsigned long
> a1,
> unsigned long a2, unsigned long a3);
> extern void __audit_syscall_exit(int ret_success, long ret_value);
> @@ -242,12 +249,15 @@ extern void audit_seccomp_actions_logged(const char
> *names,
>
> static inline void audit_set_context(struct task_struct *task, struct
> audit_context *ctx)
> {
> - task->audit_context = ctx;
> + task->audit->ctx = ctx;
> }
>
> static inline struct audit_context *audit_context(void)
> {
> - return current->audit_context;
> + if (current->audit)
> + return current->audit->ctx;
> + else
> + return NULL;
Unnecessary else (and static checkers may complain).
> }
>
> static inline bool audit_dummy_context(void)
> @@ -255,11 +265,7 @@ static inline bool audit_dummy_context(void)
> void *p = audit_context();
> return !p || *(int *)p;
> }
> -static inline void audit_free(struct task_struct *task)
> -{
> - if (unlikely(task->audit_context))
> - __audit_free(task);
> -}
> +
> static inline void audit_syscall_entry(int major, unsigned long a0,
> unsigned long a1, unsigned long a2,
> unsigned long a3)
> @@ -331,12 +337,18 @@ extern int auditsc_get_stamp(struct audit_context *ctx,
>
> static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
> {
> - return tsk->loginuid;
> + if (tsk->audit)
> + return tsk->audit->loginuid;
> + else
> + return INVALID_UID;
Unnecessary else.
> }
>
> static inline unsigned int audit_get_sessionid(struct task_struct *tsk)
> {
> - return tsk->sessionid;
> + if (tsk->audit)
> + return tsk->audit->sessionid;
> + else
> + return AUDIT_SID_UNSET;
Unnecessary else.
> }
>
> extern void __audit_ipc_obj(struct kern_ipc_perm *ipcp);
> @@ -461,6 +473,8 @@ static inline void audit_fanotify(unsigned int response)
> extern int audit_n_rules;
> extern int audit_signals;
> #else /* CONFIG_AUDITSYSCALL */
> +static inline void __init audit_task_init(void)
> +{ }
> static inline int audit_alloc(struct task_struct *task)
> {
> return 0;
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 87bf02d..e117272 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -30,7 +30,6 @@
> #include
>
> /* task_struct member predeclarations (sorted alphabetically): */
> -struct audit_context;
> struct backing_dev_info;
> struct bio_list;
> struct blk_plug;
> @@ -873,10 +872,8 @@ struct task_struct {
>
> struct callback_head*task_works;
>
> - struct audit_context*audit_context;
> #ifdef CONFIG_AUDITSYSCALL
> - kuid_t loginuid;
> - unsigned intsessionid;
> + struct a
Re: [PATCH ghak90 (was ghak32) V4 00/10] audit: implement container identifier
Hi Richard, On Thu, Jan 03, 2019 at 12:36:13PM -0500, Richard Guy Briggs wrote: > On 2019-01-03 08:15, Guenter Roeck wrote: > > Hi, > > > > On Tue, Jul 31, 2018 at 04:07:35PM -0400, Richard Guy Briggs wrote: > > > Implement kernel audit container identifier. > > > > I don't see a follow-up submission of this patch series. Has it been > > abandoned, > > or do I use the wrong search terms ? > > Guenter, thanks for your interest in this patchset. I haven't > abandoned it. I've pushed some updates to my own (ill-publicized) > public git repo. This effort has been going on more than 5 years with 8 Oh man :-(. Not sure if I would be that patient. Can you point me to your repository ? > previous revisions trying to document task namespaces and deciding that > was insufficient. > My interest is mostly thanks to having some of the patches of your series in my incoming code review queue: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1379654/3 As background, some of the patches in the series are needed by GCP (Google Cloud Platform) as a prerequisite for some security features. Having to maintain out-of-tree code is always a pain, even more so in a subsystem related to security. So it would be quite useful to understand if we are going to be stuck with this forever or if there is a change for the code to find its way upstream. Also, it would be useful to know if there are some upcoming changes/improvements which should be included in our version. Thanks, Guenter > For this patchset I waited 11.5 weeks (80 days, Jules Verne anyone?) > before the primary intended maintainer did the first review, then I > responded within 2 weeks with further questions and a followup patch > proposal and then waited another 8 weeks for any response before adding > another query for that followup patch proposal review at which point I > got a rude answer saying I had disappointed and exhausted the > maintainer's goodwill with some hints at how to proceed just before new > year's. > > I'd be delighted with other upstream review to get other angles and to > take some of the load and responsibility off the primary maintainer. > > I expect to submit a v5 within a week without having had those questions > directly answered, but with some ideas of what to check and verify > before I resubmit. Most of the changes have been sitting in that branch > for two months, already rebased one kernel version and will need > updating again. > > > Thanks, > > Guenter > > > > > This patchset is a fourth based on the proposal document (V3) > > > posted: > > > https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html > > > > > > The first patch is the last patch from ghak81 that is included here as a > > > convenience. > > > > > > The second patch implements the proc fs write to set the audit container > > > identifier of a process, emitting an AUDIT_CONTAINER_OP record to > > > announce the > > > registration of that audit container identifier on that process. This > > > patch > > > requires userspace support for record acceptance and proper type > > > display. > > > > > > The third implements the auxiliary record AUDIT_CONTAINER if an > > > audit container identifier is identifiable with an event. This patch > > > requires userspace support for proper type display. > > > > > > The 4th adds signal and ptrace support. > > > > > > The 5th creates a local audit context to be able to bind a standalone > > > record with a locally created auxiliary record. > > > > > > The 6th patch adds audit container identifier records to the tty > > > standalone record. > > > > > > The 7th adds audit container identifier filtering to the exit, > > > exclude and user lists. This patch adds the AUDIT_CONTID field and > > > requires auditctl userspace support for the --contid option. > > > > > > The 8th adds network namespace audit container identifier labelling > > > based on member tasks' audit container identifier labels. > > > > > > The 9th adds audit container identifier support to standalone netfilter > > > records that don't have a task context and lists each container to which > > > that net namespace belongs. > > > > > > The 10th implements reading the audit container identifier from the proc > > > filesystem for debugging. This patch isn't planned for upstream > > > inclusion. > > > > > > > > > Example: Set an
Re: [PATCH ghak90 (was ghak32) V4 00/10] audit: implement container identifier
Hi, On Tue, Jul 31, 2018 at 04:07:35PM -0400, Richard Guy Briggs wrote: > Implement kernel audit container identifier. > I don't see a follow-up submission of this patch series. Has it been abandoned, or do I use the wrong search terms ? Thanks, Guenter > This patchset is a fourth based on the proposal document (V3) > posted: > https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html > > The first patch is the last patch from ghak81 that is included here as a > convenience. > > The second patch implements the proc fs write to set the audit container > identifier of a process, emitting an AUDIT_CONTAINER_OP record to announce the > registration of that audit container identifier on that process. This patch > requires userspace support for record acceptance and proper type > display. > > The third implements the auxiliary record AUDIT_CONTAINER if an > audit container identifier is identifiable with an event. This patch > requires userspace support for proper type display. > > The 4th adds signal and ptrace support. > > The 5th creates a local audit context to be able to bind a standalone > record with a locally created auxiliary record. > > The 6th patch adds audit container identifier records to the tty > standalone record. > > The 7th adds audit container identifier filtering to the exit, > exclude and user lists. This patch adds the AUDIT_CONTID field and > requires auditctl userspace support for the --contid option. > > The 8th adds network namespace audit container identifier labelling > based on member tasks' audit container identifier labels. > > The 9th adds audit container identifier support to standalone netfilter > records that don't have a task context and lists each container to which > that net namespace belongs. > > The 10th implements reading the audit container identifier from the proc > filesystem for debugging. This patch isn't planned for upstream > inclusion. > > > Example: Set an audit container identifier of 123456 to the "sleep" task: > > sleep 2& > child=$! > echo 123456 > /proc/$child/audit_containerid; echo $? > ausearch -ts recent -m container > echo child:$child contid:$( cat /proc/$child/audit_containerid) > > This should produce a record such as: > > type=CONTAINER_OP msg=audit(2018-06-06 12:39:29.636:26949) : op=set > opid=2209 old-contid=18446744073709551615 contid=123456 pid=628 auid=root > uid=root tty=ttyS0 ses=1 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash > exe=/usr/bin/bash res=yes > > > Example: Set a filter on an audit container identifier 123459 on > /tmp/tmpcontainerid: > > contid=123459 > key=tmpcontainerid > auditctl -a exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\"); > close(\$tmpfile);" & > child=$! > echo $contid > /proc/$child/audit_containerid > sleep 2 > ausearch -i -ts recent -k $key > auditctl -d exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > rm -f /tmp/$key > > This should produce an event such as: > > type=CONTAINER msg=audit(2018-06-06 12:46:31.707:26953) : op=task > contid=123459 > type=PROCTITLE msg=audit(2018-06-06 12:46:31.707:26953) : proctitle=perl -e > sleep 1; open(my $tmpfile, '>', "/tmp/tmpcontainerid"); close($tmpfile); > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=1 > name=/tmp/tmpcontainerid inode=25656 dev=00:26 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE > cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=0 name=/tmp/ > inode=8985 dev=00:26 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 > obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none > cap_fe=0 cap_fver=0 > type=CWD msg=audit(2018-06-06 12:46:31.707:26953) : cwd=/root > type=SYSCALL msg=audit(2018-06-06 12:46:31.707:26953) : arch=x86_64 > syscall=openat success=yes exit=3 a0=0xff9c a1=0x5621f2b81900 > a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=2 ppid=628 pid=2232 auid=root > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=tmpcontainerid > > > Includes: https://github.com/linux-audit/audit-kernel/issues/81 > See: https://github.com/linux-audit/audit-kernel/issues/90 > See: https://github.com/linux-audit/audit-userspace/issues/40 > See: https://github.com/linux-audit/audit-testsuite/issues/64 > See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID > > Changelog: > > v4 > - preface set with ghak81:"collect audit task parameters" > - add shallyn and sgrubb acks > - rename feature bitmap macro > - rename cid_valid() to audit_contid_valid() > - rename AUDIT_CONTAINER_ID to AUDIT_CONTAINER_OP > - delete audit_get_contid_list
Re: [PATCH net-next] staging: octeon: fix build failure with XFRM enabled
On Fri, Dec 21, 2018 at 09:57:26PM +0100, Florian Westphal wrote:
> skb->sp doesn't exist anymore in the next-next tree, so mips defconfig
> no longer builds. Use helper instead to reset the secpath.
>
> Not even compile tested.
>
It does fix the build error.
Tested-by: Guenter Roeck
> Cc: Greg Kroah-Hartman
> Reported-by: Guenter Roeck
> Fixes: 4165079ba328d ("net: switch secpath to use skb extension
> infrastructure")
> Signed-off-by: Florian Westphal
> ---
> Greg, David:
>
> The patch will not break build for a tree that lacks the 'Fixes'
> commit, so this can also go in via staging tree.
> OTOH, net-next build is broken for mips/octeon, so I think in
> this case net-next might make more sense?
>
> diff --git a/drivers/staging/octeon/ethernet-tx.c
> b/drivers/staging/octeon/ethernet-tx.c
> index df3441b815bb..317c9720467c 100644
> --- a/drivers/staging/octeon/ethernet-tx.c
> +++ b/drivers/staging/octeon/ethernet-tx.c
> @@ -359,8 +359,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device
> *dev)
> dst_release(skb_dst(skb));
> skb_dst_set(skb, NULL);
> #ifdef CONFIG_XFRM
> - secpath_put(skb->sp);
> - skb->sp = NULL;
> + secpath_reset(skb);
> #endif
> nf_reset(skb);
>
> --
> 2.19.2
>
Re: [PATCH] netfilter: check if the socket netns is correct.
On Thu, Sep 27, 2018 at 07:58:24PM -0300, Flavio Leitner wrote:
> On Thu, Sep 27, 2018 at 01:46:29PM -0700, Guenter Roeck wrote:
> > Hi Flavio,
> >
> > On Wed, Jun 27, 2018 at 10:34:25AM -0300, Flavio Leitner wrote:
> > > Netfilter assumes that if the socket is present in the skb, then
> > > it can be used because that reference is cleaned up while the skb
> > > is crossing netns.
> > >
> > > We want to change that to preserve the socket reference in a future
> > > patch, so this is a preparation updating netfilter to check if the
> > > socket netns matches before use it.
> > >
> > > Signed-off-by: Flavio Leitner
> > > Acked-by: Florian Westphal
> > > Signed-off-by: David S. Miller
> > > ---
> > ...
> > > --- a/net/netfilter/xt_socket.c
> > > +++ b/net/netfilter/xt_socket.c
> > > @@ -56,8 +56,12 @@ socket_match(const struct sk_buff *skb, struct
> > > xt_action_param *par,
> > > struct sk_buff *pskb = (struct sk_buff *)skb;
> > > struct sock *sk = skb->sk;
> > >
> > > + if (!net_eq(xt_net(par), sock_net(sk)))
> > > + sk = NULL;
> > > +
> >
> > I am having trouble with this code. With CONFIG_NET_NS enabled, it crashes
> > for me in read_pnet() because sk is NULL.
> >
> > > if (!sk)
> > > sk = nf_sk_lookup_slow_v4(xt_net(par), skb, xt_in(par));
> >
> > The old code seems to suggest that sk == NULL was possible.
> >
> > I see the problem with the Chrome OS kernel rebased to v4.19-rc5, so I
> > can not guarantee that this really an upstream problem. The change seems
> > odd, though. Are you sure that it is not (or, rather, no longer) necessary
> > to check if sk == NULL before dereferencing it in sock_net() ?
>
> Oops, it is necessary but if it's not and the netns doesn't match, we need
> do the lookup. So, could you check if this fixes the problem for you?
>
> From a5f927e7f1368d753f87cb978d630d786d5adb62 Mon Sep 17 00:00:00 2001
> From: Flavio Leitner
> Date: Thu, 27 Sep 2018 19:36:28 -0300
> Subject: [PATCH] xt_socket: check sk before checking for netns.
>
> Only check for the network namespace if the socket is available.
>
> Fixes: f564650106a6 ("netfilter: check if the socket netns is correct.")
> Reported-by: Guenter Roeck
> Signed-off-by: Flavio Leitner
This fixes the problem for me.
Tested-by: Guenter Roeck
Thanks,
Guenter
> ---
> net/netfilter/xt_socket.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
> index 0472f3472842..ada144e5645b 100644
> --- a/net/netfilter/xt_socket.c
> +++ b/net/netfilter/xt_socket.c
> @@ -56,7 +56,7 @@ socket_match(const struct sk_buff *skb, struct
> xt_action_param *par,
> struct sk_buff *pskb = (struct sk_buff *)skb;
> struct sock *sk = skb->sk;
>
> - if (!net_eq(xt_net(par), sock_net(sk)))
> + if (sk && !net_eq(xt_net(par), sock_net(sk)))
> sk = NULL;
>
> if (!sk)
> @@ -117,7 +117,7 @@ socket_mt6_v1_v2_v3(const struct sk_buff *skb, struct
> xt_action_param *par)
> struct sk_buff *pskb = (struct sk_buff *)skb;
> struct sock *sk = skb->sk;
>
> - if (!net_eq(xt_net(par), sock_net(sk)))
> + if (sk && !net_eq(xt_net(par), sock_net(sk)))
> sk = NULL;
>
> if (!sk)
> --
> 2.14.4
>
Re: [PATCH] netfilter: check if the socket netns is correct.
Hi Flavio,
On Wed, Jun 27, 2018 at 10:34:25AM -0300, Flavio Leitner wrote:
> Netfilter assumes that if the socket is present in the skb, then
> it can be used because that reference is cleaned up while the skb
> is crossing netns.
>
> We want to change that to preserve the socket reference in a future
> patch, so this is a preparation updating netfilter to check if the
> socket netns matches before use it.
>
> Signed-off-by: Flavio Leitner
> Acked-by: Florian Westphal
> Signed-off-by: David S. Miller
> ---
...
> --- a/net/netfilter/xt_socket.c
> +++ b/net/netfilter/xt_socket.c
> @@ -56,8 +56,12 @@ socket_match(const struct sk_buff *skb, struct
> xt_action_param *par,
> struct sk_buff *pskb = (struct sk_buff *)skb;
> struct sock *sk = skb->sk;
>
> + if (!net_eq(xt_net(par), sock_net(sk)))
> + sk = NULL;
> +
I am having trouble with this code. With CONFIG_NET_NS enabled, it crashes
for me in read_pnet() because sk is NULL.
> if (!sk)
> sk = nf_sk_lookup_slow_v4(xt_net(par), skb, xt_in(par));
The old code seems to suggest that sk == NULL was possible.
I see the problem with the Chrome OS kernel rebased to v4.19-rc5, so I
can not guarantee that this really an upstream problem. The change seems
odd, though. Are you sure that it is not (or, rather, no longer) necessary
to check if sk == NULL before dereferencing it in sock_net() ?
> +
> if (sk) {
> bool wildcard;
> bool transparent = true;
> @@ -113,8 +117,12 @@ socket_mt6_v1_v2_v3(const struct sk_buff *skb, struct
> xt_action_param *par)
> struct sk_buff *pskb = (struct sk_buff *)skb;
> struct sock *sk = skb->sk;
>
> + if (!net_eq(xt_net(par), sock_net(sk)))
> + sk = NULL;
> +
Same here.
> if (!sk)
> sk = nf_sk_lookup_slow_v6(xt_net(par), skb, xt_in(par));
> +
> if (sk) {
> bool wildcard;
> bool transparent = true;
Thanks,
Guenter
Re: [PATCH bpf-next] tools: include reallocarray feature test in FEATURE_TESTS_BASIC
On 07/13/2018 07:08 PM, Jakub Kicinski wrote:
perf propagates its feature check results to libbpf. This means
features for which perf probes must be a superset of libbpf's
required features. perf depends on FEATURE_TESTS_BASIC for its list
of features.
commit 531b014e7a2f ("tools: bpf: make use of reallocarray") added
reallocarray use to libbpf, make perf also perform the reallocarray
feature check.
Fixes: 531b014e7a2f ("tools: bpf: make use of reallocarray")
Reported-by: Guenter Roeck
Signed-off-by: Jakub Kicinski
Tested-by: Guenter Roeck
---
tools/build/Makefile.feature | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 5b6dda3b1ca8..f216b2f5c3d7 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -57,6 +57,7 @@ FEATURE_TESTS_BASIC := \
libunwind-aarch64 \
pthread-attr-setaffinity-np \
pthread-barrier \
+reallocarray\
stackprotector-all \
timerfd \
libdw-dwarf-unwind \
Re: [bpf-next,v3,11/13] tools: bpf: make use of reallocarray
On 07/13/2018 05:07 PM, Jakub Kicinski wrote: On Fri, 13 Jul 2018 16:53:05 -0700, Guenter Roeck wrote: Hi, On Tue, Jul 10, 2018 at 02:43:05PM -0700, Jakub Kicinski wrote: reallocarray() is a safer variant of realloc which checks for multiplication overflow in case of array allocation. Since it's not available in Glibc < 2.26 import kernel's overflow.h and add a static inline implementation when needed. Use feature detection to probe for existence of reallocarray. This probe doesn't work on my system (Ubuntu 16.04). libbpf.c: In function ‘bpf_object__add_program’: libbpf.c:326:10: error: implicit declaration of function ‘reallocarray’ No way :( :( Maybe you have to clean the build directory hard? Maybe you have old feature check results or some such? Unlikely. This is seen by my test builders which always start from a clean state. $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 16.04.4 LTS Release:16.04 Codename: xenial $ gcc --version gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ld --version GNU ld (GNU Binutils for Ubuntu) 2.26.1 Copyright (C) 2015 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. $ git describe next-20180713 $ git clean -d -x -f -q $ make allmodconfig $ make tools/perf ... libbpf.c: In function ‘bpf_object__add_program’: libbpf.c:326:10: error: implicit declaration of function ‘reallocarray’ Guenter
Re: [bpf-next,v3,11/13] tools: bpf: make use of reallocarray
Hi, On Tue, Jul 10, 2018 at 02:43:05PM -0700, Jakub Kicinski wrote: > reallocarray() is a safer variant of realloc which checks for > multiplication overflow in case of array allocation. Since it's > not available in Glibc < 2.26 import kernel's overflow.h and > add a static inline implementation when needed. Use feature > detection to probe for existence of reallocarray. > This probe doesn't work on my system (Ubuntu 16.04). libbpf.c: In function ‘bpf_object__add_program’: libbpf.c:326:10: error: implicit declaration of function ‘reallocarray’ bisect points to this patch. Guenter
Re: [net] bpfilter: include bpfilter_umh in assembly instead of using objcopy
On Tue, Jun 26, 2018 at 08:13:48PM -0700, Alexei Starovoitov wrote:
> From: Masahiro Yamada
>
> What we want here is to embed a user-space program into the kernel.
> Instead of the complex ELF magic, let's simply wrap it in the assembly
> with the '.incbin' directive.
>
> Signed-off-by: Masahiro Yamada
> Signed-off-by: Alexei Starovoitov
> ---
> I think this patch should 'fix' bpfilter build issue on all archs.
> cflags for cross CC may still be incorrect and embedded blob
> may fail to execute via fork_usermode_blob()
> (like in case of 'make ARCH=i386 net/bpfilter/' CC will build and link 64-bit
> binary that will be included into bpfilter.o or vmlinux and that binary
> will fail to run on 32-bit kernel),
> but that is separate issue that will be addressed in net-next time frame.
> Long term we've discussed to switch to something like klibc and keep it
> as part of the kernel to avoid relying on glibc and cc-can-link.sh.
>
At the very least it fixes the build issue when building i386 images
on x86_64 systems.
(Build-)Tested-by: Guenter Roeck
> net/bpfilter/Makefile| 17 ++---
> net/bpfilter/bpfilter_kern.c | 11 +--
> net/bpfilter/bpfilter_umh_blob.S | 7 +++
> 3 files changed, 14 insertions(+), 21 deletions(-)
> create mode 100644 net/bpfilter/bpfilter_umh_blob.S
>
> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> index 051dc18b8ccb..39c6980b5d99 100644
> --- a/net/bpfilter/Makefile
> +++ b/net/bpfilter/Makefile
> @@ -15,20 +15,7 @@ ifeq ($(CONFIG_BPFILTER_UMH), y)
> HOSTLDFLAGS += -static
> endif
>
> -# a bit of elf magic to convert bpfilter_umh binary into a binary blob
> -# inside bpfilter_umh.o elf file referenced by
> -# _binary_net_bpfilter_bpfilter_umh_start symbol
> -# which bpfilter_kern.c passes further into umh blob loader at run-time
> -quiet_cmd_copy_umh = GEN $@
> - cmd_copy_umh = echo ':' > $(obj)/.bpfilter_umh.o.cmd; \
> - $(OBJCOPY) -I binary \
> - `LC_ALL=C $(OBJDUMP) -f net/bpfilter/bpfilter_umh \
> - |awk -F' |,' '/file format/{print "-O",$$NF} \
> - /^architecture:/{print "-B",$$2}'` \
> - --rename-section .data=.init.rodata $< $@
> -
> -$(obj)/bpfilter_umh.o: $(obj)/bpfilter_umh
> - $(call cmd,copy_umh)
> +$(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
>
> obj-$(CONFIG_BPFILTER_UMH) += bpfilter.o
> -bpfilter-objs += bpfilter_kern.o bpfilter_umh.o
> +bpfilter-objs += bpfilter_kern.o bpfilter_umh_blob.o
> diff --git a/net/bpfilter/bpfilter_kern.c b/net/bpfilter/bpfilter_kern.c
> index 09522573f611..f0fc182d3db7 100644
> --- a/net/bpfilter/bpfilter_kern.c
> +++ b/net/bpfilter/bpfilter_kern.c
> @@ -10,11 +10,8 @@
> #include
> #include "msgfmt.h"
>
> -#define UMH_start _binary_net_bpfilter_bpfilter_umh_start
> -#define UMH_end _binary_net_bpfilter_bpfilter_umh_end
> -
> -extern char UMH_start;
> -extern char UMH_end;
> +extern char bpfilter_umh_start;
> +extern char bpfilter_umh_end;
>
> static struct umh_info info;
> /* since ip_getsockopt() can run in parallel, serialize access to umh */
> @@ -93,7 +90,9 @@ static int __init load_umh(void)
> int err;
>
> /* fork usermode process */
> - err = fork_usermode_blob(&UMH_start, &UMH_end - &UMH_start, &info);
> + err = fork_usermode_blob(&bpfilter_umh_start,
> + &bpfilter_umh_end - &bpfilter_umh_start,
> + &info);
> if (err)
> return err;
> pr_info("Loaded bpfilter_umh pid %d\n", info.pid);
> diff --git a/net/bpfilter/bpfilter_umh_blob.S
> b/net/bpfilter/bpfilter_umh_blob.S
> new file mode 100644
> index ..40311d10d2f2
> --- /dev/null
> +++ b/net/bpfilter/bpfilter_umh_blob.S
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> + .section .init.rodata, "a"
> + .global bpfilter_umh_start
> +bpfilter_umh_start:
> + .incbin "net/bpfilter/bpfilter_umh"
> + .global bpfilter_umh_end
> +bpfilter_umh_end:
Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface with FAN fault attribute
On Tue, Jun 26, 2018 at 04:47:05PM +, Vadim Pasternak wrote:
>
>
> > -Original Message-
> > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > Sent: Tuesday, June 26, 2018 7:33 PM
> > To: Vadim Pasternak
> > Cc: Andrew Lunn ; da...@davemloft.net;
> > netdev@vger.kernel.org; rui.zh...@intel.com; edubez...@gmail.com;
> > j...@resnulli.us; mlxsw ; Michael Shych
> >
> > Subject: Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface
> > with FAN fault attribute
> >
> > On Tue, Jun 26, 2018 at 02:47:01PM +, Vadim Pasternak wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Andrew Lunn [mailto:and...@lunn.ch]
> > > > Sent: Tuesday, June 26, 2018 5:29 PM
> > > > To: Vadim Pasternak
> > > > Cc: da...@davemloft.net; netdev@vger.kernel.org; li...@roeck-us.net;
> > > > rui.zh...@intel.com; edubez...@gmail.com; j...@resnulli.us; mlxsw
> > > > ; Michael Shych
> > > > Subject: Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon
> > > > interface with FAN fault attribute
> > > >
> > > > > +static ssize_t mlxsw_hwmon_fan_fault_show(struct device *dev,
> > > > > + struct device_attribute *attr,
> > > > > + char *buf)
> > > > > +{
> > > > > + struct mlxsw_hwmon_attr *mlwsw_hwmon_attr =
> > > > > + container_of(attr, struct mlxsw_hwmon_attr,
> > > > dev_attr);
> > > > > + struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> > > > > + char mfsm_pl[MLXSW_REG_MFSM_LEN];
> > > > > + u16 tach;
> > > > > + int err;
> > > > > +
> > > > > + mlxsw_reg_mfsm_pack(mfsm_pl, mlwsw_hwmon_attr->type_index);
> > > > > + err = mlxsw_reg_query(mlxsw_hwmon->core, MLXSW_REG(mfsm),
> > > > mfsm_pl);
> > > > > + if (err) {
> > > > > + dev_err(mlxsw_hwmon->bus_info->dev, "Failed to query
> > > > fan\n");
> > > > > + return err;
> > > > > + }
> > > > > + tach = mlxsw_reg_mfsm_rpm_get(mfsm_pl);
> > > > > +
> > > > > + return sprintf(buf, "%u\n", (tach < mlxsw_hwmon->tach_min) ? 1 :
> > > > > +0); }
> > > >
> > > > Documentation/hwmon/sysfs-interface says:
> > > >
> > > > Alarms are direct indications read from the chips. The drivers do
> > > > NOT make comparisons of readings to thresholds. This allows
> > > > violations between readings to be caught and alarmed. The exact
> > > > definition of an alarm (for example, whether a threshold must be met
> > > > or must be exceeded to cause an alarm) is chip-dependent.
> > > >
> > > > Now, this is a fault, not an alarm. But does the same apply?
> > >
> > Yes, it does. There are no "soft" alarms / faults.
> >
> > > Hi Andrew,
> > >
> > > Hardware provides minimum value for tachometer.
> > > Tachometer is considered as faulty in case it's below this value.
> >
> > This is for user space to decide, not for the kernel.
>
> Hi Guenter,
>
> Do you suggest to expose provide fan{x}_min, instead of fan{x}_fault
> and give to user to compare fan{x}_input versus fan{x}_min for the
> fault decision?
>
fanX_min only makes sense if programmed into or reported by the chip
or controller (that is what the attribute is for), usually to enable
the chip/controller to set an alarm. If the chip or controller does
not have a minimum speed register, the attribute should not exist,
and any decision based on a comparison between a minimum fan speed
and the actual fan speed is a user space problem.
I don't know what the tach_min calculation is about, but setting
it to the minimum of all tachometer speeds (or of all reported
minimums ?) is not the task of a hwmon driver. A hwmon driver
reports what it gets from hardware; the interpretation is up
to other parts of the system (eg userspace or the thermal
subsystem). That includes a software-based decision if an alarm
or fault should be reported or not.
> >
> > > In case any tachometer is faulty, PWM according to the system
> > > requirements should be set to 100% until the fault
> >
> > system requirements. Again, this is for user space to decide.
>
>
> Yes, user should decide in this case and I wanted to provide to user
> fan{x}_fault for this matter. But it could do it based on input and min
> attributes, of course.
>
Note that "fault" and "alarm" do have distinct different meanings.
Many fan controllers can detect if a fan is faulty (eg no sensor
connected or it is deemed faulty) or if it just runs too slow.
The typical remedy is also different: A slow fan may just need
more pwm or voltage, a faulty fan needs to be replaced.
Guenter
> >
> > > is not recovered (f.e. by physical replacing of bad unit).
> > > This is the motivation to expose fan{x}_fault in the way it's exposed.
> > >
> > > Thanks,
> > > Vadim.
> > >
> > > >
> > > > Andrew
Re: [patch net-next RFC 03/12] mlxsw: core: Add core environment module for port temperature reading
On Tue, Jun 26, 2018 at 04:22:38PM +0200, Andrew Lunn wrote: > On Tue, Jun 26, 2018 at 12:10:28PM +, Vadim Pasternak wrote: > > Adding the linux...@vger.kernel.org list. > > > Add new core_env module to allow port temperature reading. This > > information has most critical impact on system's thermal monitoring and > > is to be used by core_hwmon and core_thermal modules. > > > > New internal API reads the temperature from all the modules, which are > > equipped with the thermal sensor and exposes temperature according to > > the worst measure. All individual temperature values are normalized to > > pre-defined range. > > This patchset has been sent to the netdev list before. I raised a few > questions about this, which is why it is now being posted to a bigger > group for review. > > The hardware has up to 64 temperature sensors. These sensors are > hot-plugable, since they are inside SFP modules, which are > hot-plugable. Different SFP modules can have different operating > temperature ranges. They contain an EEPROM which lists upper and lower > warning and fail temperatures, and report alarms when these thresholds > a reached. > > This code takes the 64 sensors readings and calculates a single value > it passes to one thermal zone. That thermal zone then controls one fan > to keep this single value in range. > > I queried is this is the correct way to do this? Would it not be > better to have up to 64 thermal zones? Leave the thermal core to > iterate over all the zones in order to determine how the fan should be > driven? > I very much think so. This problem must exist elsewhere; essentially it is the bundling of multiple temperature sensors into a single thermal zone. I am not sure if this should be 64 thermal zones or one thermal zone with up to 64 sensors and some algorithm to select the relevant temperature; that would be up to the thermal subsystem maintainers to decide. Either case, the sensors should be handled and reported as individual sensors, with appropriate limits, not as single sensor. Yes, I understand that means we'll have hundreds of hwmon devices, but that should not be a problem (and if it is, we'll have to fix the problem, not the code exposing it). I understand that the thermal subsystem does not currently support handling this problem. There may also be some missing pieces between the hwmon and thermal subsystems, such as reporting limits or alarms when a hwmon driver register with the thermal subsystem. Maybe it is time to add this support as part of this patch series ? > This is possibly the first board with so many sensors. However, i > doubt it is totally unique. Other big Ethernet switches with lots of > SFP modules may be added later. Also, 10G copper PHYs often have > temperature sensors, so this is not limited to just boards with > optical ports. So having a generic solution would be good. Agreed. Thanks, Guenter > > What do the Linux PM exports say about this? > > Thanks > Andrew
Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface with FAN fault attribute
On Tue, Jun 26, 2018 at 02:47:01PM +, Vadim Pasternak wrote:
>
>
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Tuesday, June 26, 2018 5:29 PM
> > To: Vadim Pasternak
> > Cc: da...@davemloft.net; netdev@vger.kernel.org; li...@roeck-us.net;
> > rui.zh...@intel.com; edubez...@gmail.com; j...@resnulli.us; mlxsw
> > ; Michael Shych
> > Subject: Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface
> > with FAN fault attribute
> >
> > > +static ssize_t mlxsw_hwmon_fan_fault_show(struct device *dev,
> > > + struct device_attribute *attr,
> > > + char *buf)
> > > +{
> > > + struct mlxsw_hwmon_attr *mlwsw_hwmon_attr =
> > > + container_of(attr, struct mlxsw_hwmon_attr,
> > dev_attr);
> > > + struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> > > + char mfsm_pl[MLXSW_REG_MFSM_LEN];
> > > + u16 tach;
> > > + int err;
> > > +
> > > + mlxsw_reg_mfsm_pack(mfsm_pl, mlwsw_hwmon_attr->type_index);
> > > + err = mlxsw_reg_query(mlxsw_hwmon->core, MLXSW_REG(mfsm),
> > mfsm_pl);
> > > + if (err) {
> > > + dev_err(mlxsw_hwmon->bus_info->dev, "Failed to query
> > fan\n");
> > > + return err;
> > > + }
> > > + tach = mlxsw_reg_mfsm_rpm_get(mfsm_pl);
> > > +
> > > + return sprintf(buf, "%u\n", (tach < mlxsw_hwmon->tach_min) ? 1 : 0);
> > > +}
> >
> > Documentation/hwmon/sysfs-interface says:
> >
> > Alarms are direct indications read from the chips. The drivers do NOT make
> > comparisons of readings to thresholds. This allows violations between
> > readings
> > to be caught and alarmed. The exact definition of an alarm (for example,
> > whether a threshold must be met or must be exceeded to cause an alarm) is
> > chip-dependent.
> >
> > Now, this is a fault, not an alarm. But does the same apply?
>
Yes, it does. There are no "soft" alarms / faults.
> Hi Andrew,
>
> Hardware provides minimum value for tachometer.
> Tachometer is considered as faulty in case it's below this
> value.
This is for user space to decide, not for the kernel.
> In case any tachometer is faulty, PWM according to the
> system requirements should be set to 100% until the fault
system requirements. Again, this is for user space to decide.
> is not recovered (f.e. by physical replacing of bad unit).
> This is the motivation to expose fan{x}_fault in the way
> it's exposed.
>
> Thanks,
> Vadim.
>
> >
> > Andrew
Re: [PATCH v0 03/12] mlxsw: core: Add core environment module for port temperature reading
On Thu, Jun 21, 2018 at 08:34:40PM +0200, Andrew Lunn wrote: > > Hi Andrew, > > Adding Guenter Roeck, the HWMON maintainer. > > > The temperature of each individual module can be obtained > > through ethtool. > > You mean via --module-info? > > FYI: I plan to add hwmon support to the kernel SFP code. So if you > ever decide to swap to the kernel SFP code, not your own, the raw > temperatures will be exported. > As should be. Unless adjustments are made by the hardware (eg a thermal diode temperature offset register), all adjustments should be made in userspace. > > The worst temperature is necessary for the system cooling > > control decision. > > I would expect the system cooling would understand that. > > > Up to 64 SFP/QSFP modules could be connected to the system. > > Some of them could cooper modules, which doesn't provide > > temperature measurement. > > SFP modules are hot-plugable. So i would also expect the hwmon devices > to hotplug. If there is no sensor, then there is no hwmon device... If > there is no hwmon device, it plays no part in the thermal control > loop. > One hardware monitoring device per SFP, and I would assume that the hwmon device for an SFP is only instantiated if a thermal sensor is present. > > Some of them could be optical modules, providing untrusted > > temperature measurement, which could impact thermal > > control of the system. > > Why would you not trust it? Are you saying some modules simply have > broken temperature sensors? Do you have a whitelist/blacklist of > modules? > > > Also optical modules could be from the different vendors, and > > this is real situation, when, f.e. one module has the warning and > > critical thresholds 75C and 85C, while another 70C and 80C. > > But hwmon exports both the actual temperature and the alarm > temperatures. I would expect the thermal control code to use all this > information when making its decisions, not just the current > temperature. > The respective information would either be provided by hardware and reported to userspace, or userspace needs to determine the limits and write them into the hardware. Either case, that is only relevant if the hardware has limit registers. Otherwise all limits can and should be handled in the thermal subsystem. > > So, nominal temperature is not the case here, we should know the > > "worst" value for the thermal control decision. > > What it sounds like to me is you are working around problems in the > thermal control by fudging the raw temperatures. That is the wrong > thing to do. hwmon should export the raw data, and you should fix the > thermal control code to use it correctly. > Agreed. From the context it sounds like there should be some kind of temperature aggregator which would probably reside in the thermal subsystem (definitely not in hwmon). I have not seen any hwmon specific patches. For new drivers, please use [devm_]hwmon_device_register_with_info(). Guenter
Re: [net] vhost: Use kzalloc() to allocate vhost_msg_node
On 05/29/2018 08:01 PM, Michael S. Tsirkin wrote:
On Tue, May 29, 2018 at 03:19:08PM -0700, Guenter Roeck wrote:
On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to ensure all structure padding
is zeroed.
Signed-off-by: Kevin Easton
Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com
Is this patch going anywhere ?
The patch fixes CVE-2018-1118. It would be useful to understand if and when
this problem is going to be fixed.
Thanks,
Guenter
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e9..1b84dcff 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
/* Create a new message. */
struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
{
- struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
+ struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
node->vq = vq;
As I pointed out, we don't need to init the whole structure. The proper
fix is thus (I think) below.
Could you use your testing infrastructure to confirm this fixes the issue?
Sorry, I don't have the means to test the fix.
Guenter
Thanks!
Signed-off-by: Michael S. Tsirkin
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e941224..58d9aec90afb 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2342,6 +2342,9 @@ struct vhost_msg_node *vhost_new_msg(struct
vhost_virtqueue *vq, int type)
struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
+
+ /* Make sure all padding within the structure is initialized. */
+ memset(&node->msg, 0, sizeof node->msg);
node->vq = vq;
node->msg.type = type;
return node;
Re: [net 1/1] net/mlx5: Fix build break when CONFIG_SMP=n
On Mon, May 14, 2018 at 03:38:10PM -0700, Saeed Mahameed wrote:
> Avoid using the kernel's irq_descriptor and return IRQ vector affinity
> directly from the driver.
>
> This fixes the following build break when CONFIG_SMP=n
>
> include/linux/mlx5/driver.h: In function ‘mlx5_get_vector_affinity_hint’:
> include/linux/mlx5/driver.h:1299:13: error:
> ‘struct irq_desc’ has no member named ‘affinity_hint’
>
> Fixes: 6082d9c9c94a ("net/mlx5: Fix mlx5_get_vector_affinity function")
> Signed-off-by: Saeed Mahameed
> CC: Randy Dunlap
> CC: Guenter Roeck
> CC: Thomas Gleixner
> Tested-by: Israel Rukshin
Tested-by: Guenter Roeck
> ---
>
> For -stable v4.14
>
> include/linux/mlx5/driver.h | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
> index 2a156c5dfadd..d703774982ca 100644
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@ -1286,17 +1286,7 @@ enum {
> static inline const struct cpumask *
> mlx5_get_vector_affinity_hint(struct mlx5_core_dev *dev, int vector)
> {
> - struct irq_desc *desc;
> - unsigned int irq;
> - int eqn;
> - int err;
> -
> - err = mlx5_vector2eqn(dev, vector, &eqn, &irq);
> - if (err)
> - return NULL;
> -
> - desc = irq_to_desc(irq);
> - return desc->affinity_hint;
> + return dev->priv.irq_info[vector].mask;
> }
>
> #endif /* MLX5_DRIVER_H */
> --
> 2.17.0
>
