* Re: [PATCH RFC v2] MAINTAINERS: split out s390x sections
From: Eric Farman @ 2022-01-05 18:27 UTC (permalink / raw)
To: Cornelia Huck, qemu-devel, qemu-s390x
Cc: Thomas Huth, David Hildenbrand, Richard Henderson, Halil Pasic,
Christian Borntraeger, Christian Borntraeger,
Philippe Mathieu-Daudé
In-Reply-To: <20211222105548.356852-1-cohuck@redhat.com>
On Wed, 2021-12-22 at 11:55 +0100, Cornelia Huck wrote:
> Split out some more specialized devices etc., so that we can build
> smarter lists of people to be put on cc: in the future.
>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> Acked-by: David Hildenbrand <david@redhat.com>
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Acked-by: Thomas Huth <thuth@redhat.com>
> Acked-by: Halil Pasic <pasic@linux.ibm.com>
> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(Late to the party, Happy New Year!) I like the rearrangement:
Acked-by: Eric Farman <farman@linux.ibm.com>
Of course, you also said in v1:
"""
- The new sections have inherited the maintainers of the sections
they have been split out of (except where people had already
volunteered). That's easy to change, obviously, and I hope that
the cc: list already contains people who might have interest in
volunteering for some sections.
"""
As someone on cc, I could volunteer to help with these sections:
S390 Machines
-------------
S390 Virtio-ccw
S390 channel subsystem
Devices
-------
virtio-ccw
> ---
>
> v1->v2: move some sections to "Devices", some minor tweaks
>
> I guess that can go with the next set of s390x patches.
>
> ---
> MAINTAINERS | 85 ++++++++++++++++++++++++++++++++++++++++++++++-----
> --
> 1 file changed, 74 insertions(+), 11 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5dcefc0d012a..e4d88f7eb2ba 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -297,7 +297,6 @@ M: David Hildenbrand <david@redhat.com>
> S: Maintained
> F: target/s390x/
> F: target/s390x/tcg
> -F: target/s390x/cpu_models_*.[ch]
> F: hw/s390x/
> F: disas/s390.c
> F: tests/tcg/s390x/
> @@ -396,16 +395,10 @@ M: Halil Pasic <pasic@linux.ibm.com>
> M: Christian Borntraeger <borntraeger@linux.ibm.com>
> S: Supported
> F: target/s390x/kvm/
> -F: target/s390x/ioinst.[ch]
> F: target/s390x/machine.c
> F: target/s390x/sigp.c
> -F: target/s390x/cpu_features*.[ch]
> -F: target/s390x/cpu_models.[ch]
> F: hw/s390x/pv.c
> F: include/hw/s390x/pv.h
> -F: hw/intc/s390_flic.c
> -F: hw/intc/s390_flic_kvm.c
> -F: include/hw/s390x/s390_flic.h
> F: gdb-xml/s390*.xml
> T: git https://github.com/borntraeger/qemu.git s390-next
> L: qemu-s390x@nongnu.org
> @@ -1529,12 +1522,8 @@ S390 Virtio-ccw
> M: Halil Pasic <pasic@linux.ibm.com>
> M: Christian Borntraeger <borntraeger@linux.ibm.com>
> S: Supported
> -F: hw/char/sclp*.[hc]
> -F: hw/char/terminal3270.c
> F: hw/s390x/
> F: include/hw/s390x/
> -F: hw/watchdog/wdt_diag288.c
> -F: include/hw/watchdog/wdt_diag288.h
> F: configs/devices/s390x-softmmu/default.mak
> F: tests/avocado/machine_s390_ccw_virtio.py
> T: git https://github.com/borntraeger/qemu.git s390-next
> @@ -1559,6 +1548,37 @@ F: hw/s390x/s390-pci*
> F: include/hw/s390x/s390-pci*
> L: qemu-s390x@nongnu.org
>
> +S390 channel subsystem
> +M: Halil Pasic <pasic@linux.ibm.com>
> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
> +S: Supported
> +F: hw/s390x/ccw-device.[ch]
> +F: hw/s390x/css.c
> +F: hw/s390x/css-bridge.c
> +F: include/hw/s390x/css.h
> +F: include/hw/s390x/css-bridge.h
> +F: include/hw/s390x/ioinst.h
> +F: target/s390x/ioinst.c
> +L: qemu-s390x@nongnu.org
> +
> +S390 CPU models
> +M: David Hildenbrand <david@redhat.com>
> +S: Maintained
> +F: target/s390x/cpu_features*.[ch]
> +F: target/s390x/cpu_models.[ch]
> +L: qemu-s390x@nongnu.org
> +
> +S390 SCLP-backed devices
> +M: Halil Pasic <pasic@linux.ibm.com>
> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
> +S: Supported
> +F: include/hw/s390x/event-facility.h
> +F: include/hw/s390x/sclp.h
> +F: hw/char/sclp*.[hc]
> +F: hw/s390x/event-facility.c
> +F: hw/s390x/sclp*.c
> +L: qemu-s390x@nongnu.org
> +
> X86 Machines
> ------------
> PC
> @@ -1957,6 +1977,7 @@ M: Halil Pasic <pasic@linux.ibm.com>
> S: Supported
> F: hw/s390x/virtio-ccw*.[hc]
> F: hw/s390x/vhost-vsock-ccw.c
> +F: hw/s390x/vhost-user-fs-ccw.c
> T: git https://gitlab.com/cohuck/qemu.git s390-next
> T: git https://github.com/borntraeger/qemu.git s390-next
> L: qemu-s390x@nongnu.org
> @@ -2295,6 +2316,48 @@ F: hw/timer/mips_gictimer.c
> F: include/hw/intc/mips_gic.h
> F: include/hw/timer/mips_gictimer.h
>
> +S390 3270 device
> +M: Halil Pasic <pasic@linux.ibm.com>
> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
> +S: Odd fixes
> +F: include/hw/s390x/3270-ccw.h
> +F: hw/char/terminal3270.c
> +F: hw/s390x/3270-ccw.c
> +L: qemu-s390x@nongnu.org
> +
> +S390 diag 288 watchdog
> +M: Halil Pasic <pasic@linux.ibm.com>
> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
> +S: Supported
> +F: hw/watchdog/wdt_diag288.c
> +F: include/hw/watchdog/wdt_diag288.h
> +L: qemu-s390x@nongnu.org
> +
> +S390 storage key device
> +M: Halil Pasic <pasic@linux.ibm.com>
> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
> +S: Supported
> +F: hw/s390x/storage-keys.h
> +F: hw/390x/s390-skeys*.c
> +L: qemu-s390x@nongnu.org
> +
> +S390 storage attribute device
> +M: Halil Pasic <pasic@linux.ibm.com>
> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
> +S: Supported
> +F: hw/s390x/storage-attributes.h
> +F: hw/s390/s390-stattrib*.c
> +L: qemu-s390x@nongnu.org
> +
> +S390 floating interrupt controller
> +M: Halil Pasic <pasic@linux.ibm.com>
> +M: Christian Borntraeger <borntraeger@linux.ibm.com>
> +M: David Hildenbrand <david@redhat.com>
> +S: Supported
> +F: hw/intc/s390_flic*.c
> +F: include/hw/s390x/s390_flic.h
> +L: qemu-s390x@nongnu.org
> +
> Subsystems
> ----------
> Overall Audio backends
^ permalink raw reply
* Re: [RFC][V9][PATCH 0/6] btrfs: allocation_hint mode
From: Boris Burkov @ 2022-01-05 18:29 UTC (permalink / raw)
To: Goffredo Baroncelli
Cc: Zygo Blaxell, Josef Bacik, linux-btrfs, David Sterba,
Sinnamohideen Shafeeq, Paul Jones
In-Reply-To: <88a62f44-ae3f-f4b4-d2d7-6d82efd60933@inwind.it>
On Wed, Jan 05, 2022 at 07:16:04PM +0100, Goffredo Baroncelli wrote:
> On 05/01/2022 19.07, Zygo Blaxell wrote:
> > On Wed, Jan 05, 2022 at 10:16:08AM +0100, Goffredo Baroncelli wrote:
> > > Hi Boris,
> > >
> > >
> > >
> > > On 1/5/22 03:44, Boris Burkov wrote:
> > > [...]
> > > >
> > > > This is cool, thanks for building it!
> > > >
> > > > I'm playing with setting this up for a test I'm working on where I want
> > > > to send data to a dm-zero device. To that end, I applied this patchset
> > > > on top of misc-next and ran:
> > > >
> > > > $ mkfs.btrfs -f /dev/vg0/lv0 -dsingle -msingle
> > > > $ mount /dev/vg0/lv0 /mnt/lol
> > >
> > > You should mount the filesystem with
> > >
> > > $ mount -o allocation_hint=1 /dev/vg0/lv0 /mnt/lol
> > >
> > > In the previous iteration I missed the patch #6, which activates this option. You can drop patch #6 and avoid to pass this option.
> >
> > Can we drop the mount option from the series? It isn't needed.
> >
> > Or, if we must have it (and I am in no way conceding that we do),
> > at least make it default to enabled. Or turn the mount option into a
> > disable flag under the 'rescue=' option to make it clear this option is
> > not intended to be used in normal operation.
>
> Frankly speaking it was a my mistake to add this patch. It was in the
> queue, but in the last patches sets I dropped it. However in the last
> one I forgot to drop it manually so it reappeared :-)
>
> However I like your suggestion to add as 'rescue' option, where the
> default is "enabled".
A mount option adds a lot of testing burden:
enabling it where it was disabled
disabling it where it was enabled
does the above work on remount
does it always print what's expected in /proc/mounts
etc..
So I think it should have a strong justification for adding it, and the
xfstests will need to reflect the above.
Unless it's the best way to support some otherwise impossible recovery
for a realistic failure mode, I would personally suggest just skipping
it. However, I only skimmed through the discussion about recovery in the
older thread, FWIW.
>
> @Josef,
> do you started to play with this patch ? If not can I send an update
> where the main change is the renaming of the properties from
>
> PREFERRED_<X> to <X>_PREFERRED
>
> (e.g. PREFERRED_DATA to DATA_PREFERRED) which are more correct ?
>
> BR
> G.Baroncelli
> >
> > > Please give me a feedback if this resolve.
> > >
> > > BR
> > > G.Baroncelli
> > >
> > > > $ btrfs device add /dev/mapper/zero-data /mnt/lol
> > > > $ btrfs fi usage /mnt/lol
> > > > Overall:
> > > > Device size: 50.01TiB
> > > > Device allocated: 20.00MiB
> > > > Device unallocated: 50.01TiB
> > > > Device missing: 0.00B
> > > > Used: 128.00KiB
> > > > Free (estimated): 50.01TiB (min: 50.01TiB)
> > > > Free (statfs, df): 50.01TiB
> > > > Data ratio: 1.00
> > > > Metadata ratio: 1.00
> > > > Global reserve: 3.25MiB (used: 0.00B)
> > > > Multiple profiles: no
> > > >
> > > > Data,single: Size:8.00MiB, Used:0.00B (0.00%)
> > > > /dev/mapper/vg0-lv0 8.00MiB
> > > >
> > > > Metadata,single: Size:8.00MiB, Used:112.00KiB (1.37%)
> > > > /dev/mapper/vg0-lv0 8.00MiB
> > > >
> > > > System,single: Size:4.00MiB, Used:16.00KiB (0.39%)
> > > > /dev/mapper/vg0-lv0 4.00MiB
> > > >
> > > > Unallocated:
> > > > /dev/mapper/vg0-lv0 9.98GiB
> > > > /dev/mapper/zero-data 50.00TiB
> > > >
> > > > $ ./btrfs property set -t device /dev/mapper/zero-data allocation_hint DATA_ONLY
> > > > $ ./btrfs property set -t device /dev/vg0/lv0 allocation_hint METADATA_ONLY
> > > >
> > > > $ btrfs balance start --full-balance /mnt/lol
> > > > Done, had to relocate 3 out of 3 chunks
> > > >
> > > > $ btrfs fi usage /mnt/lol
> > > > Overall:
> > > > Device size: 50.01TiB
> > > > Device allocated: 2.03GiB
> > > > Device unallocated: 50.01TiB
> > > > Device missing: 0.00B
> > > > Used: 640.00KiB
> > > > Free (estimated): 50.01TiB (min: 50.01TiB)
> > > > Free (statfs, df): 50.01TiB
> > > > Data ratio: 1.00
> > > > Metadata ratio: 1.00
> > > > Global reserve: 3.25MiB (used: 0.00B)
> > > > Multiple profiles: no
> > > >
> > > > Data,single: Size:1.00GiB, Used:512.00KiB (0.05%)
> > > > /dev/mapper/zero-data 1.00GiB
> > > >
> > > > Metadata,single: Size:1.00GiB, Used:112.00KiB (0.01%)
> > > > /dev/mapper/zero-data 1.00GiB
> > > >
> > > > System,single: Size:32.00MiB, Used:16.00KiB (0.05%)
> > > > /dev/mapper/zero-data 32.00MiB
> > > >
> > > > Unallocated:
> > > > /dev/mapper/vg0-lv0 10.00GiB
> > > > /dev/mapper/zero-data 50.00TiB
> > > >
> > > >
> > > > I expected that I would have data on /dev/mapper/zero-data and metadata
> > > > on /dev/mapper/vg0-lv0, but it seems both of them were written to the zero
> > > > device. Attempting to actually use the file system eventually fails, since
> > > > the metadata is black-holed :)
> > > >
> > > > Did I make some mistake in how I used it, or is this a bug?
> > > >
> > > > Thanks,
> > > > Boris
> > > >
> > > > > BR
> > > > > G.Baroncelli
> > > > >
> > > > > Revision:
> > > > > V9:
> > > > > - rename dev_item->type to dev_item->flags
> > > > > - rename /sys/fs/btrfs/$UUID/devinfo/type -> allocation_hint
> > > > >
> > > > > V8:
> > > > > - drop the ioctl API, instead use a sysfs one
> > > > >
> > > > > V7:
> > > > > - make more room in the struct btrfs_ioctl_dev_properties up to 1K
> > > > > - leave in btrfs_tree.h only the costants
> > > > > - removed the mount option (sic)
> > > > > - correct an 'use before check' in the while loop (signaled
> > > > > by Zygo)
> > > > > - add a 2nd sort to be sure that the device_info array is in the
> > > > > expected order
> > > > >
> > > > > V6:
> > > > > - add further values to the hints: add the possibility to
> > > > > exclude a disk for a chunk type
> > > > >
> > > > >
> > > > > Goffredo Baroncelli (6):
> > > > > btrfs: add flags to give an hint to the chunk allocator
> > > > > btrfs: export the device allocation_hint property in sysfs
> > > > > btrfs: change the device allocation_hint property via sysfs
> > > > > btrfs: add allocation_hint mode
> > > > > btrfs: rename dev_item->type to dev_item->flags
> > > > > btrfs: add allocation_hint option.
> > > > >
> > > > > fs/btrfs/ctree.h | 18 +++++-
> > > > > fs/btrfs/disk-io.c | 4 +-
> > > > > fs/btrfs/super.c | 17 ++++++
> > > > > fs/btrfs/sysfs.c | 73 ++++++++++++++++++++++
> > > > > fs/btrfs/volumes.c | 105 ++++++++++++++++++++++++++++++--
> > > > > fs/btrfs/volumes.h | 7 ++-
> > > > > include/uapi/linux/btrfs_tree.h | 20 +++++-
> > > > > 7 files changed, 232 insertions(+), 12 deletions(-)
> > > > >
> > > > > --
> > > > > 2.34.1
> > > > >
> > >
> > >
> > > --
> > > gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
> > > Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
>
>
> --
> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* [syzbot] KMSAN: kernel-usb-infoleak in usbnet_write_cmd (3)
From: syzbot @ 2022-01-05 18:28 UTC (permalink / raw)
To: glider, gregkh, johan, linux-kernel, linux-usb, stern,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 81c325bbf94e kmsan: hooks: do not check memory in kmsan_in..
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=14a07163b00000
kernel config: https://syzkaller.appspot.com/x/.config?x=2d8b9a11641dc9aa
dashboard link: https://syzkaller.appspot.com/bug?extid=003c0a286b9af5412510
compiler: clang version 14.0.0 (/usr/local/google/src/llvm-git-monorepo 2b554920f11c8b763cd9ed9003f4e19b919b8e1f), GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=100165dbb00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10c97e77b00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+003c0a286b9af5412510@syzkaller.appspotmail.com
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: syz
usb 1-1: Manufacturer: syz
usb 1-1: SerialNumber: syz
usb 1-1: config 0 descriptor??
=====================================================
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
usb_start_wait_urb+0x153/0x4b0 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x487/0x7c0 drivers/usb/core/message.c:153
__usbnet_write_cmd drivers/net/usb/usbnet.c:2050 [inline]
usbnet_write_cmd+0x3d3/0x480 drivers/net/usb/usbnet.c:2088
mcs7830_set_reg drivers/net/usb/mcs7830.c:117 [inline]
mcs7830_hif_set_mac_address drivers/net/usb/mcs7830.c:138 [inline]
mcs7830_apply_base_config+0xd5/0x8a0 drivers/net/usb/mcs7830.c:387
mcs7830_bind+0x753/0xb70 drivers/net/usb/mcs7830.c:492
usbnet_probe+0x1284/0x4140 drivers/net/usb/usbnet.c:1747
usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
really_probe+0x67d/0x1510 drivers/base/dd.c:596
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:751
driver_probe_device drivers/base/dd.c:781 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:898
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:969
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1016
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1d3e/0x2400 drivers/base/core.c:3394
usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
really_probe+0x67d/0x1510 drivers/base/dd.c:596
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:751
driver_probe_device drivers/base/dd.c:781 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:898
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:969
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1016
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1d3e/0x2400 drivers/base/core.c:3394
usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2563
hub_port_connect drivers/usb/core/hub.c:5353 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]
port_event drivers/usb/core/hub.c:5643 [inline]
hub_event+0x5ad2/0x8910 drivers/usb/core/hub.c:5725
process_one_work+0xdb9/0x1820 kernel/workqueue.c:2298
worker_thread+0x10bc/0x21f0 kernel/workqueue.c:2445
kthread+0x721/0x850 kernel/kthread.c:327
ret_from_fork+0x1f/0x30
Uninit was stored to memory at:
kmemdup+0x107/0x140 mm/util.c:130
__usbnet_write_cmd drivers/net/usb/usbnet.c:2039 [inline]
usbnet_write_cmd+0x1a0/0x480 drivers/net/usb/usbnet.c:2088
mcs7830_set_reg drivers/net/usb/mcs7830.c:117 [inline]
mcs7830_hif_set_mac_address drivers/net/usb/mcs7830.c:138 [inline]
mcs7830_apply_base_config+0xd5/0x8a0 drivers/net/usb/mcs7830.c:387
mcs7830_bind+0x753/0xb70 drivers/net/usb/mcs7830.c:492
usbnet_probe+0x1284/0x4140 drivers/net/usb/usbnet.c:1747
usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
really_probe+0x67d/0x1510 drivers/base/dd.c:596
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:751
driver_probe_device drivers/base/dd.c:781 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:898
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:969
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1016
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1d3e/0x2400 drivers/base/core.c:3394
usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
really_probe+0x67d/0x1510 drivers/base/dd.c:596
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:751
driver_probe_device drivers/base/dd.c:781 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:898
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:969
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1016
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1d3e/0x2400 drivers/base/core.c:3394
usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2563
hub_port_connect drivers/usb/core/hub.c:5353 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]
port_event drivers/usb/core/hub.c:5643 [inline]
hub_event+0x5ad2/0x8910 drivers/usb/core/hub.c:5725
process_one_work+0xdb9/0x1820 kernel/workqueue.c:2298
worker_thread+0x10bc/0x21f0 kernel/workqueue.c:2445
kthread+0x721/0x850 kernel/kthread.c:327
ret_from_fork+0x1f/0x30
Uninit was stored to memory at:
__dev_addr_set include/linux/netdevice.h:4655 [inline]
eth_hw_addr_set include/linux/etherdevice.h:319 [inline]
mcs7830_bind+0x230/0xb70 drivers/net/usb/mcs7830.c:488
usbnet_probe+0x1284/0x4140 drivers/net/usb/usbnet.c:1747
usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
really_probe+0x67d/0x1510 drivers/base/dd.c:596
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:751
driver_probe_device drivers/base/dd.c:781 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:898
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:969
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1016
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1d3e/0x2400 drivers/base/core.c:3394
usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
really_probe+0x67d/0x1510 drivers/base/dd.c:596
__driver_probe_device+0x3e9/0x530 drivers/base/dd.c:751
driver_probe_device drivers/base/dd.c:781 [inline]
__device_attach_driver+0x79f/0x1120 drivers/base/dd.c:898
bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
__device_attach+0x593/0x8e0 drivers/base/dd.c:969
device_initial_probe+0x4a/0x60 drivers/base/dd.c:1016
bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
device_add+0x1d3e/0x2400 drivers/base/core.c:3394
usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2563
hub_port_connect drivers/usb/core/hub.c:5353 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]
port_event drivers/usb/core/hub.c:5643 [inline]
hub_event+0x5ad2/0x8910 drivers/usb/core/hub.c:5725
process_one_work+0xdb9/0x1820 kernel/workqueue.c:2298
worker_thread+0x10bc/0x21f0 kernel/workqueue.c:2445
kthread+0x721/0x850 kernel/kthread.c:327
ret_from_fork+0x1f/0x30
Local variable addr created at:
mcs7830_bind+0x9b/0xb70 drivers/net/usb/mcs7830.c:476
usbnet_probe+0x1284/0x4140 drivers/net/usb/usbnet.c:1747
Bytes 0-3 of 6 are uninitialized
Memory access of size 6 starts at ffff88811d26f2b0
CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
=====================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: don't call free_mmap_offset when purging
From: Patchwork @ 2022-01-05 18:27 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
In-Reply-To: <20220105145835.142950-1-matthew.auld@intel.com>
[-- Attachment #1: Type: text/plain, Size: 30300 bytes --]
== Series Details ==
Series: series starting with [1/4] drm/i915: don't call free_mmap_offset when purging
URL : https://patchwork.freedesktop.org/series/98509/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11048_full -> Patchwork_21927_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_21927_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21927_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_21927_full:
### IGT changes ###
#### Possible regressions ####
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl7/igt@i915_suspend@fence-restore-tiled2untiled.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl8/igt@i915_suspend@fence-restore-tiled2untiled.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_whisper@basic-fds-priority-all:
- {shard-rkl}: NOTRUN -> [INCOMPLETE][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-rkl-5/igt@gem_exec_whisper@basic-fds-priority-all.html
* igt@gem_exec_whisper@basic-forked-all:
- {shard-rkl}: [PASS][4] -> [INCOMPLETE][5]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-rkl-1/igt@gem_exec_whisper@basic-forked-all.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-rkl-5/igt@gem_exec_whisper@basic-forked-all.html
* igt@gem_mmap_gtt@close-race:
- {shard-dg1}: NOTRUN -> [SKIP][6] +2 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-dg1-15/igt@gem_mmap_gtt@close-race.html
* igt@i915_pm_dc@dc5-psr:
- {shard-tglu}: NOTRUN -> [SKIP][7]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-7/igt@i915_pm_dc@dc5-psr.html
* igt@i915_pm_rps@waitboost:
- {shard-dg1}: [PASS][8] -> [FAIL][9]
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-dg1-19/igt@i915_pm_rps@waitboost.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-dg1-15/igt@i915_pm_rps@waitboost.html
* igt@prime_busy@hang-wait@bcs0:
- {shard-tglu}: NOTRUN -> [DMESG-WARN][10]
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-7/igt@prime_busy@hang-wait@bcs0.html
* igt@prime_busy@hang-wait@vcs0:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][11]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-7/igt@prime_busy@hang-wait@vcs0.html
* igt@prime_busy@hang@bcs0:
- {shard-tglu}: [PASS][12] -> [INCOMPLETE][13]
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-2/igt@prime_busy@hang@bcs0.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-7/igt@prime_busy@hang@bcs0.html
* igt@runner@aborted:
- {shard-tglu}: ([FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17]) ([i915#3002] / [i915#3690] / [i915#4312]) -> ([FAIL][18], [FAIL][19], [FAIL][20]) ([i915#3002] / [i915#4312])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-8/igt@runner@aborted.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-7/igt@runner@aborted.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-6/igt@runner@aborted.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-3/igt@runner@aborted.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-5/igt@runner@aborted.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-6/igt@runner@aborted.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-3/igt@runner@aborted.html
Known issues
------------
Here are the changes found in Patchwork_21927_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-skl: NOTRUN -> [DMESG-WARN][21] ([i915#3002])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl4/igt@gem_create@create-massive.html
* igt@gem_eio@in-flight-contexts-10ms:
- shard-skl: [PASS][22] -> [TIMEOUT][23] ([i915#3063])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl3/igt@gem_eio@in-flight-contexts-10ms.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl9/igt@gem_eio@in-flight-contexts-10ms.html
* igt@gem_eio@in-flight-contexts-1us:
- shard-tglb: [PASS][24] -> [TIMEOUT][25] ([i915#3063])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglb8/igt@gem_eio@in-flight-contexts-1us.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglb5/igt@gem_eio@in-flight-contexts-1us.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][26] -> [FAIL][27] ([i915#232]) +1 similar issue
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglb6/igt@gem_eio@unwedge-stress.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglb5/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_balancer@parallel:
- shard-iclb: [PASS][28] -> [SKIP][29] ([i915#4525]) +2 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-iclb4/igt@gem_exec_balancer@parallel.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@gem_exec_balancer@parallel.html
* igt@gem_exec_endless@dispatch@bcs0:
- shard-tglb: [PASS][30] -> [INCOMPLETE][31] ([i915#3778])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglb1/igt@gem_exec_endless@dispatch@bcs0.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglb5/igt@gem_exec_endless@dispatch@bcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][32] -> [FAIL][33] ([i915#2842])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-glk8/igt@gem_exec_fair@basic-pace-share@rcs0.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk3/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: [PASS][34] -> [FAIL][35] ([i915#2842])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-kbl1/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl4/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][36] ([i915#2842]) +1 similar issue
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb4/igt@gem_exec_fair@basic-pace@vcs1.html
* igt@gem_exec_schedule@submit-early-slice@vcs0:
- shard-tglb: [PASS][37] -> [INCOMPLETE][38] ([i915#3797])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglb7/igt@gem_exec_schedule@submit-early-slice@vcs0.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglb6/igt@gem_exec_schedule@submit-early-slice@vcs0.html
* igt@gem_exec_whisper@basic-queues-forked:
- shard-iclb: [PASS][39] -> [INCOMPLETE][40] ([i915#1895])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-iclb7/igt@gem_exec_whisper@basic-queues-forked.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb3/igt@gem_exec_whisper@basic-queues-forked.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-skl: NOTRUN -> [SKIP][41] ([fdo#109271] / [i915#4613]) +1 similar issue
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl6/igt@gem_lmem_swapping@heavy-multi.html
* igt@gem_lmem_swapping@parallel-random-verify:
- shard-glk: NOTRUN -> [SKIP][42] ([fdo#109271] / [i915#4613])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk1/igt@gem_lmem_swapping@parallel-random-verify.html
* igt@gem_lmem_swapping@verify-random:
- shard-iclb: NOTRUN -> [SKIP][43] ([i915#4613])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@gem_lmem_swapping@verify-random.html
* igt@gem_pread@exhaustion:
- shard-skl: NOTRUN -> [WARN][44] ([i915#2658])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl8/igt@gem_pread@exhaustion.html
* igt@gem_pxp@display-protected-crc:
- shard-iclb: NOTRUN -> [SKIP][45] ([i915#4270])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@gem_pxp@display-protected-crc.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][46] -> [DMESG-WARN][47] ([i915#180]) +3 similar issues
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-apl1/igt@gem_workarounds@suspend-resume-context.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-apl6/igt@gem_workarounds@suspend-resume-context.html
* igt@gen7_exec_parse@basic-allocation:
- shard-apl: NOTRUN -> [SKIP][48] ([fdo#109271]) +10 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-apl1/igt@gen7_exec_parse@basic-allocation.html
* igt@gen7_exec_parse@batch-without-end:
- shard-iclb: NOTRUN -> [SKIP][49] ([fdo#109289]) +1 similar issue
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@gen7_exec_parse@batch-without-end.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [PASS][50] -> [DMESG-WARN][51] ([i915#1436] / [i915#716])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl3/igt@gen9_exec_parse@allowed-single.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl9/igt@gen9_exec_parse@allowed-single.html
* igt@gen9_exec_parse@shadow-peek:
- shard-iclb: NOTRUN -> [SKIP][52] ([i915#2856])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@gen9_exec_parse@shadow-peek.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][53] -> [FAIL][54] ([i915#454])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-iclb2/igt@i915_pm_dc@dc6-psr.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb3/igt@i915_pm_dc@dc6-psr.html
* igt@i915_selftest@live@gt_pm:
- shard-skl: NOTRUN -> [DMESG-FAIL][55] ([i915#1886] / [i915#2291])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl8/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@mock@requests:
- shard-skl: [PASS][56] -> [INCOMPLETE][57] ([i915#4919])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl5/igt@i915_selftest@mock@requests.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl2/igt@i915_selftest@mock@requests.html
* igt@i915_selftest@perf@region:
- shard-tglb: [PASS][58] -> [DMESG-WARN][59] ([i915#2867])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglb6/igt@i915_selftest@perf@region.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglb8/igt@i915_selftest@perf@region.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl: [PASS][60] -> [FAIL][61] ([i915#2521])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl9/igt@kms_async_flips@alternate-sync-async-flip.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl5/igt@kms_async_flips@alternate-sync-async-flip.html
* igt@kms_big_fb@linear-32bpp-rotate-0:
- shard-glk: [PASS][62] -> [DMESG-WARN][63] ([i915#118]) +1 similar issue
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-glk6/igt@kms_big_fb@linear-32bpp-rotate-0.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk3/igt@kms_big_fb@linear-32bpp-rotate-0.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][64] ([i915#3743]) +1 similar issue
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl10/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-skl: NOTRUN -> [SKIP][65] ([fdo#109271] / [i915#3777]) +1 similar issue
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl4/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
- shard-iclb: NOTRUN -> [SKIP][66] ([fdo#110723]) +1 similar issue
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][67] ([fdo#109271] / [i915#3886]) +5 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl4/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-iclb: NOTRUN -> [SKIP][68] ([fdo#109278] / [i915#3886]) +1 similar issue
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][69] ([fdo#109271] / [i915#3886])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-apl1/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs.html
- shard-kbl: NOTRUN -> [SKIP][70] ([fdo#109271] / [i915#3886]) +1 similar issue
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl3/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][71] ([fdo#109271] / [i915#3886])
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk1/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][72] ([fdo#109271]) +124 similar issues
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl10/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium@hdmi-aspect-ratio:
- shard-skl: NOTRUN -> [SKIP][73] ([fdo#109271] / [fdo#111827]) +9 similar issues
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl6/igt@kms_chamelium@hdmi-aspect-ratio.html
* igt@kms_chamelium@hdmi-crc-nonplanar-formats:
- shard-kbl: NOTRUN -> [SKIP][74] ([fdo#109271] / [fdo#111827]) +4 similar issues
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl4/igt@kms_chamelium@hdmi-crc-nonplanar-formats.html
* igt@kms_chamelium@hdmi-mode-timings:
- shard-glk: NOTRUN -> [SKIP][75] ([fdo#109271] / [fdo#111827])
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk1/igt@kms_chamelium@hdmi-mode-timings.html
* igt@kms_color_chamelium@pipe-c-gamma:
- shard-iclb: NOTRUN -> [SKIP][76] ([fdo#109284] / [fdo#111827]) +2 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@kms_color_chamelium@pipe-c-gamma.html
* igt@kms_color_chamelium@pipe-d-ctm-0-75:
- shard-apl: NOTRUN -> [SKIP][77] ([fdo#109271] / [fdo#111827])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-apl1/igt@kms_color_chamelium@pipe-d-ctm-0-75.html
* igt@kms_cursor_crc@pipe-a-cursor-512x512-offscreen:
- shard-iclb: NOTRUN -> [SKIP][78] ([fdo#109278] / [fdo#109279]) +1 similar issue
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@kms_cursor_crc@pipe-a-cursor-512x512-offscreen.html
* igt@kms_cursor_crc@pipe-d-cursor-512x512-sliding:
- shard-glk: NOTRUN -> [SKIP][79] ([fdo#109271]) +16 similar issues
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk1/igt@kms_cursor_crc@pipe-d-cursor-512x512-sliding.html
* igt@kms_cursor_edge_walk@pipe-d-64x64-left-edge:
- shard-kbl: NOTRUN -> [SKIP][80] ([fdo#109271]) +38 similar issues
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl3/igt@kms_cursor_edge_walk@pipe-d-64x64-left-edge.html
* igt@kms_cursor_legacy@flip-vs-cursor-varying-size:
- shard-iclb: [PASS][81] -> [FAIL][82] ([i915#2346])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-iclb8/igt@kms_cursor_legacy@flip-vs-cursor-varying-size.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-varying-size.html
* igt@kms_cursor_legacy@pipe-d-single-bo:
- shard-skl: NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#533])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl4/igt@kms_cursor_legacy@pipe-d-single-bo.html
* igt@kms_cursor_legacy@short-flip-before-cursor-atomic-transitions:
- shard-skl: [PASS][84] -> [DMESG-WARN][85] ([i915#1982])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl6/igt@kms_cursor_legacy@short-flip-before-cursor-atomic-transitions.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl5/igt@kms_cursor_legacy@short-flip-before-cursor-atomic-transitions.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-tglb: [PASS][86] -> [DMESG-WARN][87] ([i915#2411] / [i915#2867])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglb6/igt@kms_fbcon_fbt@psr-suspend.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglb8/igt@kms_fbcon_fbt@psr-suspend.html
* igt@kms_flip@2x-flip-vs-dpms:
- shard-iclb: NOTRUN -> [SKIP][88] ([fdo#109274])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@kms_flip@2x-flip-vs-dpms.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl: [PASS][89] -> [FAIL][90] ([i915#79])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl: NOTRUN -> [DMESG-WARN][91] ([i915#180]) +1 similar issue
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl6/igt@kms_flip@flip-vs-suspend@c-dp1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1:
- shard-skl: NOTRUN -> [FAIL][92] ([i915#2122])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl6/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1.html
* igt@kms_flip@wf_vblank-ts-check-interruptible@a-edp1:
- shard-skl: [PASS][93] -> [FAIL][94] ([i915#2122]) +1 similar issue
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl10/igt@kms_flip@wf_vblank-ts-check-interruptible@a-edp1.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl7/igt@kms_flip@wf_vblank-ts-check-interruptible@a-edp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling:
- shard-glk: [PASS][95] -> [FAIL][96] ([i915#4911])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-glk9/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling:
- shard-iclb: [PASS][97] -> [SKIP][98] ([i915#3701])
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-iclb1/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-move:
- shard-iclb: NOTRUN -> [SKIP][99] ([fdo#109280]) +7 similar issues
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-move.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: [PASS][100] -> [DMESG-WARN][101] ([i915#180]) +4 similar issues
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [PASS][102] -> [FAIL][103] ([i915#1188])
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl10/igt@kms_hdr@bpc-switch.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl7/igt@kms_hdr@bpc-switch.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> [FAIL][104] ([fdo#108145] / [i915#265]) +2 similar issues
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-glk: NOTRUN -> [FAIL][105] ([fdo#108145] / [i915#265])
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk1/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][106] -> [FAIL][107] ([fdo#108145] / [i915#265])
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
- shard-skl: NOTRUN -> [SKIP][108] ([fdo#109271] / [i915#2733])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl6/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-skl: NOTRUN -> [SKIP][109] ([fdo#109271] / [i915#658])
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-skl6/igt@kms_psr2_sf@plane-move-sf-dmg-area.html
* igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: NOTRUN -> [SKIP][110] ([fdo#109441])
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@kms_psr@psr2_cursor_plane_move.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][111] -> [SKIP][112] ([fdo#109441]) +2 similar issues
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb1/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_setmode@basic:
- shard-glk: [PASS][113] -> [FAIL][114] ([i915#31])
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-glk6/igt@kms_setmode@basic.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk3/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-apl: [PASS][115] -> [DMESG-WARN][116] ([i915#180] / [i915#295])
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-apl4/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-apl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@kms_vblank@pipe-d-ts-continuation-idle-hang:
- shard-iclb: NOTRUN -> [SKIP][117] ([fdo#109278]) +8 similar issues
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb8/igt@kms_vblank@pipe-d-ts-continuation-idle-hang.html
* igt@kms_vblank@pipe-d-wait-idle:
- shard-kbl: NOTRUN -> [SKIP][118] ([fdo#109271] / [i915#533])
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl3/igt@kms_vblank@pipe-d-wait-idle.html
- shard-apl: NOTRUN -> [SKIP][119] ([fdo#109271] / [i915#533])
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-apl1/igt@kms_vblank@pipe-d-wait-idle.html
* igt@sysfs_clients@split-10:
- shard-kbl: NOTRUN -> [SKIP][120] ([fdo#109271] / [i915#2994])
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl4/igt@sysfs_clients@split-10.html
#### Possible fixes ####
* igt@feature_discovery@psr2:
- shard-iclb: [SKIP][121] ([i915#658]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-iclb1/igt@feature_discovery@psr2.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb2/igt@feature_discovery@psr2.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl: [DMESG-WARN][123] ([i915#180]) -> [PASS][124] +1 similar issue
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-apl6/igt@gem_ctx_isolation@preservation-s3@bcs0.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-apl1/igt@gem_ctx_isolation@preservation-s3@bcs0.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [TIMEOUT][125] ([i915#2481] / [i915#3070]) -> [PASS][126]
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-iclb6/igt@gem_eio@unwedge-stress.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-iclb1/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-glk: [FAIL][127] ([i915#2842]) -> [PASS][128]
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-glk3/igt@gem_exec_fair@basic-none-solo@rcs0.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk5/igt@gem_exec_fair@basic-none-solo@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [FAIL][129] ([i915#2842]) -> [PASS][130] +1 similar issue
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-kbl7/igt@gem_exec_fair@basic-none@vcs0.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-kbl3/igt@gem_exec_fair@basic-none@vcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}: [FAIL][131] ([i915#2842]) -> [PASS][132]
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-3/igt@gem_exec_fair@basic-pace-share@rcs0.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-3/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_schedule@submit-golden-slice@vcs1:
- {shard-tglu}: [INCOMPLETE][133] ([i915#3797]) -> [PASS][134]
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-7/igt@gem_exec_schedule@submit-golden-slice@vcs1.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-2/igt@gem_exec_schedule@submit-golden-slice@vcs1.html
* igt@gem_exec_suspend@basic@smem:
- {shard-tglu}: [FAIL][135] ([i915#1888]) -> [PASS][136]
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-2/igt@gem_exec_suspend@basic@smem.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-7/igt@gem_exec_suspend@basic@smem.html
* igt@gem_exec_whisper@basic-contexts-all:
- shard-glk: [DMESG-WARN][137] ([i915#118]) -> [PASS][138] +2 similar issues
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-glk2/igt@gem_exec_whisper@basic-contexts-all.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk7/igt@gem_exec_whisper@basic-contexts-all.html
* igt@gem_madvise@dontneed-before-mmap:
- {shard-dg1}: [INCOMPLETE][139] -> [PASS][140]
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-dg1-17/igt@gem_madvise@dontneed-before-mmap.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-dg1-18/igt@gem_madvise@dontneed-before-mmap.html
* igt@gem_spin_batch@user-each:
- {shard-tglu}: [DMESG-WARN][141] -> [PASS][142]
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-tglu-7/igt@gem_spin_batch@user-each.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-tglu-3/igt@gem_spin_batch@user-each.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [DMESG-WARN][143] ([i915#1436] / [i915#716]) -> [PASS][144]
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11048/shard-glk9/igt@gen9_exec_parse@allowed-all.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/shard-glk1/igt@gen9_exec_parse@allowed-all.html
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- {shard-rkl}: [SKIP][145] ([i915#1397]) -> [PASS][146]
[145]: https://intel-gfx-ci.01.or
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21927/index.html
[-- Attachment #2: Type: text/html, Size: 33449 bytes --]
^ permalink raw reply
* Re: [5.16.0-rc5][ppc][net] kernel oops when hotplug remove of vNIC interface
From: Jakub Kicinski @ 2022-01-05 18:26 UTC (permalink / raw)
To: Abdul Haleem
Cc: dumazet, netdev, linux-kernel, Dany Madden, alexandr.lobakin,
brian King, Sukadev Bhattiprolu, linuxppc-dev
In-Reply-To: <63380c22-a163-2664-62be-2cf401065e73@linux.vnet.ibm.com>
On Wed, 5 Jan 2022 13:56:53 +0530 Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel 5.16.0-rc5 panics when DLPAR ADD of vNIC device on my
> Powerpc LPAR
>
> Perform below dlpar commands in a loop from linux OS
>
> drmgr -r -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
> drmgr -a -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
>
> after 7th iteration, the kernel panics with below messages
>
> console messages:
> [102056] ibmvnic 30000003 env3: Sending CRQ: 801e000864000000
> 0060000000000000
> <intr> ibmvnic 30000003 env3: Handling CRQ: 809e000800000000
> 0000000000000000
> [102056] ibmvnic 30000003 env3: Disabling tx_scrq[0] irq
> [102056] ibmvnic 30000003 env3: Disabling tx_scrq[1] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[0] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[1] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[2] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[3] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[4] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[5] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
> [102056] ibmvnic 30000003 env3: Replenished 8 pools
> Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
> BUG: Kernel NULL pointer dereference on read at 0x00000010
> Faulting instruction address: 0xc000000000a3c840
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: bridge stp llc ib_core rpadlpar_io rpaphp nfnetlink
> tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag
> bonding rfkill ibmvnic sunrpc pseries_rng xts vmx_crypto gf128mul
> sch_fq_codel binfmt_misc ip_tables ext4 mbcache jbd2 dm_service_time
> sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth dm_multipath dm_mirror
> dm_region_hash dm_log dm_mod fuse
> CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted
> 5.16.0-rc5-autotest-g6441998e2e37 #1
> Workqueue: events_long __ibmvnic_reset [ibmvnic]
> NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
> REGS: c0000000548e37e0 TRAP: 0300 Not tainted
> (5.16.0-rc5-autotest-g6441998e2e37)
> MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004
> CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
> GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
> GPR04: c000000c7d1a7e00 fffffffffffffff6 0000000000000027 c000000c7d1a7e08
> GPR08: 0000000000000023 0000000000000000 0000000000000010 c0080000029bdd10
> GPR12: c000000000a3c820 c000000c7fca6680 0000000000000000 c000000133016bf8
> GPR16: 00000000000003fe 0000000000001000 0000000000000002 0000000000000008
> GPR20: c000000133016eb0 0000000000000000 0000000000000000 0000000000000003
> GPR24: c000000133016000 c000000133017168 0000000020000000 c000000133016a00
> GPR28: 0000000000000006 c000000133016a00 0000000000000001 c000000133016000
> NIP [c000000000a3c840] napi_enable+0x20/0xc0
> LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
> Call Trace:
> [c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
> [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
> [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
> [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
> [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
> [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
> [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
> 38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
> ---[ end trace 5f8033b08fd27706 ]---
> radix-mmu: Page sizes from device-tree:
>
> the fault instruction points to
>
> [root@ltcden11-lp1 boot]# gdb -batch
> vmlinuz-5.16.0-rc5-autotest-g6441998e2e37 -ex 'list *(0xc000000000a3c840)'
> 0xc000000000a3c840 is in napi_enable (net/core/dev.c:6966).
> 6961 void napi_enable(struct napi_struct *n)
> 6962 {
> 6963 unsigned long val, new;
> 6964
> 6965 do {
> 6966 val = READ_ONCE(n->state);
If n is NULL here that's gotta be a driver problem.
Adding Dany & Suka.
> 6967 BUG_ON(!test_bit(NAPI_STATE_SCHED, &val));
> 6968
> 6969 new = val & ~(NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC);
> 6970 if (n->dev->threaded && n->thread)
>
^ permalink raw reply
* [PATCH] firmware: edd: remove empty default_attrs array
From: Greg Kroah-Hartman @ 2022-01-05 18:26 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman
The default_attrs array of attributes for the edd sysfs entries is
totally empty for some reason, and a list of attributes is added later
after the object is created (which should be fixed up later as it's
racy). Because this pointer is never used, and is empty, and we are
trying to remove all default_attrs usages, just delete it.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/edd.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/firmware/edd.c b/drivers/firmware/edd.c
index 14d0970a7198..69353dd0ea22 100644
--- a/drivers/firmware/edd.c
+++ b/drivers/firmware/edd.c
@@ -574,14 +574,6 @@ static EDD_DEVICE_ATTR(interface, 0444, edd_show_interface, edd_has_edd30);
static EDD_DEVICE_ATTR(host_bus, 0444, edd_show_host_bus, edd_has_edd30);
static EDD_DEVICE_ATTR(mbr_signature, 0444, edd_show_mbr_signature, edd_has_mbr_signature);
-
-/* These are default attributes that are added for every edd
- * device discovered. There are none.
- */
-static struct attribute * def_attrs[] = {
- NULL,
-};
-
/* These attributes are conditional and only added for some devices. */
static struct edd_attribute * edd_attrs[] = {
&edd_attr_raw_data,
@@ -619,7 +611,6 @@ static void edd_release(struct kobject * kobj)
static struct kobj_type edd_ktype = {
.release = edd_release,
.sysfs_ops = &edd_attr_ops,
- .default_attrs = def_attrs,
};
static struct kset *edd_kset;
--
2.34.1
^ permalink raw reply related
* Re: [5.16.0-rc5][ppc][net] kernel oops when hotplug remove of vNIC interface
From: Jakub Kicinski @ 2022-01-05 18:26 UTC (permalink / raw)
To: Abdul Haleem
Cc: linux-kernel, alexandr.lobakin, dumazet, brian King, linuxppc-dev,
netdev, Sukadev Bhattiprolu, Dany Madden
In-Reply-To: <63380c22-a163-2664-62be-2cf401065e73@linux.vnet.ibm.com>
On Wed, 5 Jan 2022 13:56:53 +0530 Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel 5.16.0-rc5 panics when DLPAR ADD of vNIC device on my
> Powerpc LPAR
>
> Perform below dlpar commands in a loop from linux OS
>
> drmgr -r -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
> drmgr -a -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
>
> after 7th iteration, the kernel panics with below messages
>
> console messages:
> [102056] ibmvnic 30000003 env3: Sending CRQ: 801e000864000000
> 0060000000000000
> <intr> ibmvnic 30000003 env3: Handling CRQ: 809e000800000000
> 0000000000000000
> [102056] ibmvnic 30000003 env3: Disabling tx_scrq[0] irq
> [102056] ibmvnic 30000003 env3: Disabling tx_scrq[1] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[0] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[1] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[2] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[3] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[4] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[5] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
> [102056] ibmvnic 30000003 env3: Replenished 8 pools
> Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
> BUG: Kernel NULL pointer dereference on read at 0x00000010
> Faulting instruction address: 0xc000000000a3c840
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: bridge stp llc ib_core rpadlpar_io rpaphp nfnetlink
> tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag
> bonding rfkill ibmvnic sunrpc pseries_rng xts vmx_crypto gf128mul
> sch_fq_codel binfmt_misc ip_tables ext4 mbcache jbd2 dm_service_time
> sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth dm_multipath dm_mirror
> dm_region_hash dm_log dm_mod fuse
> CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted
> 5.16.0-rc5-autotest-g6441998e2e37 #1
> Workqueue: events_long __ibmvnic_reset [ibmvnic]
> NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
> REGS: c0000000548e37e0 TRAP: 0300 Not tainted
> (5.16.0-rc5-autotest-g6441998e2e37)
> MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004
> CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
> GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
> GPR04: c000000c7d1a7e00 fffffffffffffff6 0000000000000027 c000000c7d1a7e08
> GPR08: 0000000000000023 0000000000000000 0000000000000010 c0080000029bdd10
> GPR12: c000000000a3c820 c000000c7fca6680 0000000000000000 c000000133016bf8
> GPR16: 00000000000003fe 0000000000001000 0000000000000002 0000000000000008
> GPR20: c000000133016eb0 0000000000000000 0000000000000000 0000000000000003
> GPR24: c000000133016000 c000000133017168 0000000020000000 c000000133016a00
> GPR28: 0000000000000006 c000000133016a00 0000000000000001 c000000133016000
> NIP [c000000000a3c840] napi_enable+0x20/0xc0
> LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
> Call Trace:
> [c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
> [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
> [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
> [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
> [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
> [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
> [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
> 38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
> ---[ end trace 5f8033b08fd27706 ]---
> radix-mmu: Page sizes from device-tree:
>
> the fault instruction points to
>
> [root@ltcden11-lp1 boot]# gdb -batch
> vmlinuz-5.16.0-rc5-autotest-g6441998e2e37 -ex 'list *(0xc000000000a3c840)'
> 0xc000000000a3c840 is in napi_enable (net/core/dev.c:6966).
> 6961 void napi_enable(struct napi_struct *n)
> 6962 {
> 6963 unsigned long val, new;
> 6964
> 6965 do {
> 6966 val = READ_ONCE(n->state);
If n is NULL here that's gotta be a driver problem.
Adding Dany & Suka.
> 6967 BUG_ON(!test_bit(NAPI_STATE_SCHED, &val));
> 6968
> 6969 new = val & ~(NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC);
> 6970 if (n->dev->threaded && n->thread)
>
^ permalink raw reply
* Re: [f2fs-dev] [PATCH 5/6] f2fs: implement iomap operations
From: Jaegeuk Kim @ 2022-01-05 18:25 UTC (permalink / raw)
To: Chao Yu; +Cc: linux-kernel, linux-f2fs-devel, Eric Biggers
In-Reply-To: <f8c0d9f8-6a1f-e7b7-4dd3-fcd31272a0df@kernel.org>
On 01/05, Chao Yu wrote:
> On 2022/1/5 5:24, Jaegeuk Kim wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Implement 'struct iomap_ops' for f2fs, in preparation for making f2fs
> > use iomap for direct I/O.
> >
> > Note that this may be used for other things besides direct I/O in the
> > future; however, for now I've only tested it for direct I/O.
> >
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>
> Reviewed-by: Chao Yu <chao@kernel.org>
Ditto. Thanks,
>
> Thanks,
^ permalink raw reply
* Re: [f2fs-dev] [PATCH 5/6] f2fs: implement iomap operations
From: Jaegeuk Kim @ 2022-01-05 18:25 UTC (permalink / raw)
To: Chao Yu; +Cc: Eric Biggers, linux-kernel, linux-f2fs-devel
In-Reply-To: <f8c0d9f8-6a1f-e7b7-4dd3-fcd31272a0df@kernel.org>
On 01/05, Chao Yu wrote:
> On 2022/1/5 5:24, Jaegeuk Kim wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Implement 'struct iomap_ops' for f2fs, in preparation for making f2fs
> > use iomap for direct I/O.
> >
> > Note that this may be used for other things besides direct I/O in the
> > future; however, for now I've only tested it for direct I/O.
> >
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>
> Reviewed-by: Chao Yu <chao@kernel.org>
Ditto. Thanks,
>
> Thanks,
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [f2fs-dev] [PATCH 3/6] f2fs: do not expose unwritten blocks to user by DIO
From: Jaegeuk Kim @ 2022-01-05 18:25 UTC (permalink / raw)
To: Chao Yu; +Cc: linux-kernel, linux-f2fs-devel
In-Reply-To: <a2036978-81f9-fad4-90ce-15dadf048693@kernel.org>
On 01/05, Chao Yu wrote:
> On 2022/1/5 5:24, Jaegeuk Kim wrote:
> > DIO preallocates physical blocks before writing data, but if an error occurrs
> > or power-cut happens, we can see block contents from the disk. This patch tries
> > to fix it by 1) turning to buffered writes for DIO into holes, 2) truncating
> > unwritten blocks from error or power-cut.
> >
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>
> Reviewed-by: Chao Yu <chao@kernel.org>
Thank you for the review tho, I can't ruin the one month git history. Please
chime in if there's any bug in the patch.
>
> Thanks,
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [f2fs-dev] [PATCH 3/6] f2fs: do not expose unwritten blocks to user by DIO
From: Jaegeuk Kim @ 2022-01-05 18:25 UTC (permalink / raw)
To: Chao Yu; +Cc: linux-kernel, linux-f2fs-devel
In-Reply-To: <a2036978-81f9-fad4-90ce-15dadf048693@kernel.org>
On 01/05, Chao Yu wrote:
> On 2022/1/5 5:24, Jaegeuk Kim wrote:
> > DIO preallocates physical blocks before writing data, but if an error occurrs
> > or power-cut happens, we can see block contents from the disk. This patch tries
> > to fix it by 1) turning to buffered writes for DIO into holes, 2) truncating
> > unwritten blocks from error or power-cut.
> >
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>
> Reviewed-by: Chao Yu <chao@kernel.org>
Thank you for the review tho, I can't ruin the one month git history. Please
chime in if there's any bug in the patch.
>
> Thanks,
^ permalink raw reply
* Re: [PATCH v2] libsepol: check for valid sensitivity before lookup
From: James Carter @ 2022-01-05 18:25 UTC (permalink / raw)
To: Christian Göttsche; +Cc: SElinux list
In-Reply-To: <CAP+JOzR-G0mre7PJcf=rvyapEAqP-nbwU3PJr_1TBw87XGQQ=A@mail.gmail.com>
On Mon, Jan 3, 2022 at 1:44 PM James Carter <jwcart2@gmail.com> wrote:
>
> On Fri, Dec 24, 2021 at 8:09 PM Christian Göttsche
> <cgzones@googlemail.com> wrote:
> >
> > Check the sensitivity is valid and thus the lookup in the name array
> > `p_sens_val_to_name` is valid.
> >
> > Found by oss-fuzz (#42729, #42730, #42735, #42741)
> >
> > ==54784==The signal is caused by a READ memory access.
> > #0 0x5a10f3 in mls_semantic_level_expand ./selinux/libsepol/src/expand.c:934:11
> > #1 0x53839e in policydb_user_cache ./selinux/libsepol/src/policydb.c:972:7
> > #2 0x5c6325 in hashtab_map ./selinux/libsepol/src/hashtab.c:236:10
> > #3 0x5392e9 in policydb_index_others ./selinux/libsepol/src/policydb.c:1274:6
> > #4 0x53f90a in policydb_read ./selinux/libsepol/src/policydb.c:4496:6
> > #5 0x50c679 in LLVMFuzzerTestOneInput ./selinux/libsepol/fuzz/binpolicy-fuzzer.c:35:6
> > #6 0x4409e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (./selinux/out/binpolicy-fuzzer+0x4409e3)
> > #7 0x4295bf in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (./selinux/out/binpolicy-fuzzer+0x4295bf)
> > #8 0x42f850 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (./selinux/out/binpolicy-fuzzer+0x42f850)
> > #9 0x45b6d2 in main (./selinux/out/binpolicy-fuzzer+0x45b6d2)
> > #10 0x7f059fcd71c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
> > #11 0x7f059fcd7277 in __libc_start_main csu/../csu/libc-start.c:409:3
> > #12 0x423900 in _start (./out/binpolicy-fuzzer+0x423900)
> >
> > Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> >
>
> Someday it would be nice to have this validation of contexts done with
> the other policydb validation, but I don't want to mess with that
> right now.
>
> Acked-by: James Carter <jwcart2@gmail.com>
>
Merged.
Thanks,
Jim
> > ---
> > v2: also check the entry is non-null
> >
> > ---
> > libsepol/src/expand.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c
> > index 8a7259a0..898e6b87 100644
> > --- a/libsepol/src/expand.c
> > +++ b/libsepol/src/expand.c
> > @@ -929,6 +929,10 @@ int mls_semantic_level_expand(mls_semantic_level_t * sl, mls_level_t * l,
> > if (!sl->sens)
> > return 0;
> >
> > + /* Invalid sensitivity */
> > + if (sl->sens > p->p_levels.nprim || !p->p_sens_val_to_name[sl->sens - 1])
> > + return -1;
> > +
> > l->sens = sl->sens;
> > levdatum = (level_datum_t *) hashtab_search(p->p_levels.table,
> > p->p_sens_val_to_name[l->sens - 1]);
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [PATCH] libsepol/cil: bail out on snprintf failure
From: James Carter @ 2022-01-05 18:24 UTC (permalink / raw)
To: Christian Göttsche; +Cc: SElinux list
In-Reply-To: <CAP+JOzRZRyzDH0vnmSdOqNcf=rxq5gYcwyMeWHqiWYUrXJpJTw@mail.gmail.com>
On Mon, Jan 3, 2022 at 12:45 PM James Carter <jwcart2@gmail.com> wrote:
>
> On Mon, Dec 20, 2021 at 3:16 PM Christian Göttsche
> <cgzones@googlemail.com> wrote:
> >
> > Do not continue with a negative return value once a string append
> > operation fails to avoid increasing the buffer length variable
> > `str_len`, potentially leading to an out-of-bounds write.
> >
> > Found by GitHub CodeQL.
> >
> > Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
>
> Acked-by: James Carter <jwcart2@gmail.com>
>
Merged.
Thanks,
Jim
> > ---
> > libsepol/cil/src/cil.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/libsepol/cil/src/cil.c b/libsepol/cil/src/cil.c
> > index 9916cbee..38edcf8e 100644
> > --- a/libsepol/cil/src/cil.c
> > +++ b/libsepol/cil/src/cil.c
> > @@ -1456,6 +1456,12 @@ int cil_userprefixes_to_string(struct cil_db *db, char **out, size_t *size)
> >
> > buf_pos = snprintf(str_tmp, str_len, "user %s prefix %s;\n", user->datum.fqn,
> > userprefix->prefix_str);
> > + if (buf_pos < 0) {
> > + free(str_tmp);
> > + *size = 0;
> > + *out = NULL;
> > + goto exit;
> > + }
> > str_len -= buf_pos;
> > str_tmp += buf_pos;
> > }
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV
From: Andrey Grodzovsky @ 2022-01-05 18:24 UTC (permalink / raw)
To: Christian König, JingWen Chen, Christian König,
Liu, Monk, Chen, JingWen, Deng, Emily,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
Chen, Horace
In-Reply-To: <821c0b66-8c9c-9dff-a328-bfbc2233d4ef@gmail.com>
On 2022-01-05 2:59 a.m., Christian König wrote:
> Am 05.01.22 um 08:34 schrieb JingWen Chen:
>> On 2022/1/5 上午12:56, Andrey Grodzovsky wrote:
>>> On 2022-01-04 6:36 a.m., Christian König wrote:
>>>> Am 04.01.22 um 11:49 schrieb Liu, Monk:
>>>>> [AMD Official Use Only]
>>>>>
>>>>>>> See the FLR request from the hypervisor is just another source
>>>>>>> of signaling the need for a reset, similar to each job timeout
>>>>>>> on each queue. Otherwise you have a race condition between the
>>>>>>> hypervisor and the scheduler.
>>>>> No it's not, FLR from hypervisor is just to notify guest the hw VF
>>>>> FLR is about to start or was already executed, but host will do
>>>>> FLR anyway without waiting for guest too long
>>>>>
>>>> Then we have a major design issue in the SRIOV protocol and really
>>>> need to question this.
>>>>
>>>> How do you want to prevent a race between the hypervisor resetting
>>>> the hardware and the client trying the same because of a timeout?
>>>>
>>>> As far as I can see the procedure should be:
>>>> 1. We detect that a reset is necessary, either because of a fault a
>>>> timeout or signal from hypervisor.
>>>> 2. For each of those potential reset sources a work item is send to
>>>> the single workqueue.
>>>> 3. One of those work items execute first and prepares the reset.
>>>> 4. We either do the reset our self or notify the hypervisor that we
>>>> are ready for the reset.
>>>> 5. Cleanup after the reset, eventually resubmit jobs etc..
>>>> 6. Cancel work items which might have been scheduled from other
>>>> reset sources.
>>>>
>>>> It does make sense that the hypervisor resets the hardware without
>>>> waiting for the clients for too long, but if we don't follow this
>>>> general steps we will always have a race between the different
>>>> components.
>>>
>>> Monk, just to add to this - if indeed as you say that 'FLR from
>>> hypervisor is just to notify guest the hw VF FLR is about to start
>>> or was already executed, but host will do FLR anyway without waiting
>>> for guest too long'
>>> and there is no strict waiting from the hypervisor for
>>> IDH_READY_TO_RESET to be recived from guest before starting the
>>> reset then setting in_gpu_reset and locking reset_sem from guest
>>> side is not really full proof
>>> protection from MMIO accesses by the guest - it only truly helps if
>>> hypervisor waits for that message before initiation of HW reset.
>>>
>> Hi Andrey, this cannot be done. If somehow guest kernel hangs and
>> never has the chance to send the response back, then other VFs will
>> have to wait it reset. All the vfs will hang in this case. Or
>> sometimes the mailbox has some delay and other VFs will also wait.
>> The user of other VFs will be affected in this case.
>
> Yeah, agree completely with JingWen. The hypervisor is the one in
> charge here, not the guest.
>
> What the hypervisor should do (and it already seems to be designed
> that way) is to send the guest a message that a reset is about to
> happen and give it some time to response appropriately.
>
> The guest on the other hand then tells the hypervisor that all
> processing has stopped and it is ready to restart. If that doesn't
> happen in time the hypervisor should eliminate the guest probably
> trigger even more severe consequences, e.g. restart the whole VM etc...
>
> Christian.
So what's the end conclusion here regarding dropping this particular
patch ? Seems to me we still need to drop it to prevent driver's MMIO access
to the GPU during reset from various places in the code.
Andrey
>
>>> Andrey
>>>
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>> Am 04.01.22 um 11:49 schrieb Liu, Monk:
>>>>> [AMD Official Use Only]
>>>>>
>>>>>>> See the FLR request from the hypervisor is just another source
>>>>>>> of signaling the need for a reset, similar to each job timeout
>>>>>>> on each queue. Otherwise you have a race condition between the
>>>>>>> hypervisor and the scheduler.
>>>>> No it's not, FLR from hypervisor is just to notify guest the hw VF
>>>>> FLR is about to start or was already executed, but host will do
>>>>> FLR anyway without waiting for guest too long
>>>>>
>>>>>>> In other words I strongly think that the current SRIOV reset
>>>>>>> implementation is severely broken and what Andrey is doing is
>>>>>>> actually fixing it.
>>>>> It makes the code to crash ... how could it be a fix ?
>>>>>
>>>>> I'm afraid the patch is NAK from me, but it is welcome if the
>>>>> cleanup do not ruin the logic, Andry or jingwen can try it if needed.
>>>>>
>>>>> Thanks
>>>>> -------------------------------------------------------------------
>>>>> Monk Liu | Cloud GPU & Virtualization Solution | AMD
>>>>> -------------------------------------------------------------------
>>>>> we are hiring software manager for CVS core team
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> -----Original Message-----
>>>>> From: Koenig, Christian <Christian.Koenig@amd.com>
>>>>> Sent: Tuesday, January 4, 2022 6:19 PM
>>>>> To: Chen, JingWen <JingWen.Chen2@amd.com>; Christian König
>>>>> <ckoenig.leichtzumerken@gmail.com>; Grodzovsky, Andrey
>>>>> <Andrey.Grodzovsky@amd.com>; Deng, Emily <Emily.Deng@amd.com>;
>>>>> Liu, Monk <Monk.Liu@amd.com>; dri-devel@lists.freedesktop.org;
>>>>> amd-gfx@lists.freedesktop.org; Chen, Horace <Horace.Chen@amd.com>;
>>>>> Chen, JingWen <JingWen.Chen2@amd.com>
>>>>> Cc: daniel@ffwll.ch
>>>>> Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset
>>>>> protection for SRIOV
>>>>>
>>>>> Hi Jingwen,
>>>>>
>>>>> well what I mean is that we need to adjust the implementation in
>>>>> amdgpu to actually match the requirements.
>>>>>
>>>>> Could be that the reset sequence is questionable in general, but I
>>>>> doubt so at least for now.
>>>>>
>>>>> See the FLR request from the hypervisor is just another source of
>>>>> signaling the need for a reset, similar to each job timeout on
>>>>> each queue. Otherwise you have a race condition between the
>>>>> hypervisor and the scheduler.
>>>>>
>>>>> Properly setting in_gpu_reset is indeed mandatory, but should
>>>>> happen at a central place and not in the SRIOV specific code.
>>>>>
>>>>> In other words I strongly think that the current SRIOV reset
>>>>> implementation is severely broken and what Andrey is doing is
>>>>> actually fixing it.
>>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>> Am 04.01.22 um 10:07 schrieb JingWen Chen:
>>>>>> Hi Christian,
>>>>>> I'm not sure what do you mean by "we need to change SRIOV not the
>>>>>> driver".
>>>>>>
>>>>>> Do you mean we should change the reset sequence in SRIOV? This
>>>>>> will be a huge change for our SRIOV solution.
>>>>>>
>>>>>> From my point of view, we can directly use
>>>>>> amdgpu_device_lock_adev
>>>>>> and amdgpu_device_unlock_adev in flr_work instead of try_lock
>>>>>> since no one will conflict with this thread with reset_domain
>>>>>> introduced.
>>>>>> But we do need the reset_sem and adev->in_gpu_reset to keep
>>>>>> device untouched via user space.
>>>>>>
>>>>>> Best Regards,
>>>>>> Jingwen Chen
>>>>>>
>>>>>> On 2022/1/3 下午6:17, Christian König wrote:
>>>>>>> Please don't. This patch is vital to the cleanup of the reset
>>>>>>> procedure.
>>>>>>>
>>>>>>> If SRIOV doesn't work with that we need to change SRIOV and not
>>>>>>> the driver.
>>>>>>>
>>>>>>> Christian.
>>>>>>>
>>>>>>> Am 30.12.21 um 19:45 schrieb Andrey Grodzovsky:
>>>>>>>> Sure, I guess i can drop this patch then.
>>>>>>>>
>>>>>>>> Andrey
>>>>>>>>
>>>>>>>> On 2021-12-24 4:57 a.m., JingWen Chen wrote:
>>>>>>>>> I do agree with shaoyun, if the host find the gpu engine hangs
>>>>>>>>> first, and do the flr, guest side thread may not know this and
>>>>>>>>> still try to access HW(e.g. kfd is using a lot of
>>>>>>>>> amdgpu_in_reset and reset_sem to identify the reset status).
>>>>>>>>> And this may lead to very bad result.
>>>>>>>>>
>>>>>>>>> On 2021/12/24 下午4:58, Deng, Emily wrote:
>>>>>>>>>> These patches look good to me. JingWen will pull these
>>>>>>>>>> patches and do some basic TDR test on sriov environment, and
>>>>>>>>>> give feedback.
>>>>>>>>>>
>>>>>>>>>> Best wishes
>>>>>>>>>> Emily Deng
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Liu, Monk <Monk.Liu@amd.com>
>>>>>>>>>>> Sent: Thursday, December 23, 2021 6:14 PM
>>>>>>>>>>> To: Koenig, Christian <Christian.Koenig@amd.com>; Grodzovsky,
>>>>>>>>>>> Andrey <Andrey.Grodzovsky@amd.com>;
>>>>>>>>>>> dri-devel@lists.freedesktop.org; amd-
>>>>>>>>>>> gfx@lists.freedesktop.org;
>>>>>>>>>>> Chen, Horace <Horace.Chen@amd.com>; Chen, JingWen
>>>>>>>>>>> <JingWen.Chen2@amd.com>; Deng, Emily <Emily.Deng@amd.com>
>>>>>>>>>>> Cc: daniel@ffwll.ch
>>>>>>>>>>> Subject: RE: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU
>>>>>>>>>>> reset
>>>>>>>>>>> protection for SRIOV
>>>>>>>>>>>
>>>>>>>>>>> [AMD Official Use Only]
>>>>>>>>>>>
>>>>>>>>>>> @Chen, Horace @Chen, JingWen @Deng, Emily
>>>>>>>>>>>
>>>>>>>>>>> Please take a review on Andrey's patch
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> -- Monk Liu | Cloud GPU & Virtualization Solution | AMD
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> -- we are hiring software manager for CVS core team
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Koenig, Christian <Christian.Koenig@amd.com>
>>>>>>>>>>> Sent: Thursday, December 23, 2021 4:42 PM
>>>>>>>>>>> To: Grodzovsky, Andrey <Andrey.Grodzovsky@amd.com>; dri-
>>>>>>>>>>> devel@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
>>>>>>>>>>> Cc: daniel@ffwll.ch; Liu, Monk <Monk.Liu@amd.com>; Chen, Horace
>>>>>>>>>>> <Horace.Chen@amd.com>
>>>>>>>>>>> Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU
>>>>>>>>>>> reset
>>>>>>>>>>> protection for SRIOV
>>>>>>>>>>>
>>>>>>>>>>> Am 22.12.21 um 23:14 schrieb Andrey Grodzovsky:
>>>>>>>>>>>> Since now flr work is serialized against GPU resets there
>>>>>>>>>>>> is no
>>>>>>>>>>>> need for this.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>>>>>>>>> Acked-by: Christian König <christian.koenig@amd.com>
>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 11 -----------
>>>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 11 -----------
>>>>>>>>>>>> 2 files changed, 22 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
>>>>>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
>>>>>>>>>>>> index 487cd654b69e..7d59a66e3988 100644
>>>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
>>>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
>>>>>>>>>>>> @@ -248,15 +248,7 @@ static void
>>>>>>>>>>>> xgpu_ai_mailbox_flr_work(struct
>>>>>>>>>>> work_struct *work)
>>>>>>>>>>>> struct amdgpu_device *adev = container_of(virt,
>>>>>>>>>>>> struct
>>>>>>>>>>> amdgpu_device, virt);
>>>>>>>>>>>> int timeout = AI_MAILBOX_POLL_FLR_TIMEDOUT;
>>>>>>>>>>>>
>>>>>>>>>>>> - /* block amdgpu_gpu_recover till msg FLR COMPLETE
>>>>>>>>>>>> received,
>>>>>>>>>>>> - * otherwise the mailbox msg will be ruined/reseted by
>>>>>>>>>>>> - * the VF FLR.
>>>>>>>>>>>> - */
>>>>>>>>>>>> - if (!down_write_trylock(&adev->reset_sem))
>>>>>>>>>>>> - return;
>>>>>>>>>>>> -
>>>>>>>>>>>> amdgpu_virt_fini_data_exchange(adev);
>>>>>>>>>>>> - atomic_set(&adev->in_gpu_reset, 1);
>>>>>>>>>>>>
>>>>>>>>>>>> xgpu_ai_mailbox_trans_msg(adev,
>>>>>>>>>>>> IDH_READY_TO_RESET, 0,
>>>>>>>>>>>> 0, 0);
>>>>>>>>>>>>
>>>>>>>>>>>> @@ -269,9 +261,6 @@ static void
>>>>>>>>>>>> xgpu_ai_mailbox_flr_work(struct
>>>>>>>>>>> work_struct *work)
>>>>>>>>>>>> } while (timeout > 1);
>>>>>>>>>>>>
>>>>>>>>>>>> flr_done:
>>>>>>>>>>>> - atomic_set(&adev->in_gpu_reset, 0);
>>>>>>>>>>>> - up_write(&adev->reset_sem);
>>>>>>>>>>>> -
>>>>>>>>>>>> /* Trigger recovery for world switch failure if
>>>>>>>>>>>> no TDR
>>>>>>>>>>>> */
>>>>>>>>>>>> if (amdgpu_device_should_recover_gpu(adev)
>>>>>>>>>>>> && (!amdgpu_device_has_job_running(adev) || diff
>>>>>>>>>>>> --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>>>>>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>>>>>>>>>>>> index e3869067a31d..f82c066c8e8d 100644
>>>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>>>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>>>>>>>>>>>> @@ -277,15 +277,7 @@ static void
>>>>>>>>>>>> xgpu_nv_mailbox_flr_work(struct
>>>>>>>>>>> work_struct *work)
>>>>>>>>>>>> struct amdgpu_device *adev = container_of(virt,
>>>>>>>>>>>> struct
>>>>>>>>>>> amdgpu_device, virt);
>>>>>>>>>>>> int timeout = NV_MAILBOX_POLL_FLR_TIMEDOUT;
>>>>>>>>>>>>
>>>>>>>>>>>> - /* block amdgpu_gpu_recover till msg FLR COMPLETE
>>>>>>>>>>>> received,
>>>>>>>>>>>> - * otherwise the mailbox msg will be ruined/reseted by
>>>>>>>>>>>> - * the VF FLR.
>>>>>>>>>>>> - */
>>>>>>>>>>>> - if (!down_write_trylock(&adev->reset_sem))
>>>>>>>>>>>> - return;
>>>>>>>>>>>> -
>>>>>>>>>>>> amdgpu_virt_fini_data_exchange(adev);
>>>>>>>>>>>> - atomic_set(&adev->in_gpu_reset, 1);
>>>>>>>>>>>>
>>>>>>>>>>>> xgpu_nv_mailbox_trans_msg(adev,
>>>>>>>>>>>> IDH_READY_TO_RESET, 0,
>>>>>>>>>>>> 0, 0);
>>>>>>>>>>>>
>>>>>>>>>>>> @@ -298,9 +290,6 @@ static void
>>>>>>>>>>>> xgpu_nv_mailbox_flr_work(struct
>>>>>>>>>>> work_struct *work)
>>>>>>>>>>>> } while (timeout > 1);
>>>>>>>>>>>>
>>>>>>>>>>>> flr_done:
>>>>>>>>>>>> - atomic_set(&adev->in_gpu_reset, 0);
>>>>>>>>>>>> - up_write(&adev->reset_sem);
>>>>>>>>>>>> -
>>>>>>>>>>>> /* Trigger recovery for world switch failure if
>>>>>>>>>>>> no TDR
>>>>>>>>>>>> */
>>>>>>>>>>>> if (amdgpu_device_should_recover_gpu(adev)
>>>>>>>>>>>> && (!amdgpu_device_has_job_running(adev) ||
>
^ permalink raw reply
* Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV
From: Andrey Grodzovsky @ 2022-01-05 18:24 UTC (permalink / raw)
To: Christian König, JingWen Chen, Christian König,
Liu, Monk, Chen, JingWen, Deng, Emily,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
Chen, Horace
Cc: daniel@ffwll.ch
In-Reply-To: <821c0b66-8c9c-9dff-a328-bfbc2233d4ef@gmail.com>
On 2022-01-05 2:59 a.m., Christian König wrote:
> Am 05.01.22 um 08:34 schrieb JingWen Chen:
>> On 2022/1/5 上午12:56, Andrey Grodzovsky wrote:
>>> On 2022-01-04 6:36 a.m., Christian König wrote:
>>>> Am 04.01.22 um 11:49 schrieb Liu, Monk:
>>>>> [AMD Official Use Only]
>>>>>
>>>>>>> See the FLR request from the hypervisor is just another source
>>>>>>> of signaling the need for a reset, similar to each job timeout
>>>>>>> on each queue. Otherwise you have a race condition between the
>>>>>>> hypervisor and the scheduler.
>>>>> No it's not, FLR from hypervisor is just to notify guest the hw VF
>>>>> FLR is about to start or was already executed, but host will do
>>>>> FLR anyway without waiting for guest too long
>>>>>
>>>> Then we have a major design issue in the SRIOV protocol and really
>>>> need to question this.
>>>>
>>>> How do you want to prevent a race between the hypervisor resetting
>>>> the hardware and the client trying the same because of a timeout?
>>>>
>>>> As far as I can see the procedure should be:
>>>> 1. We detect that a reset is necessary, either because of a fault a
>>>> timeout or signal from hypervisor.
>>>> 2. For each of those potential reset sources a work item is send to
>>>> the single workqueue.
>>>> 3. One of those work items execute first and prepares the reset.
>>>> 4. We either do the reset our self or notify the hypervisor that we
>>>> are ready for the reset.
>>>> 5. Cleanup after the reset, eventually resubmit jobs etc..
>>>> 6. Cancel work items which might have been scheduled from other
>>>> reset sources.
>>>>
>>>> It does make sense that the hypervisor resets the hardware without
>>>> waiting for the clients for too long, but if we don't follow this
>>>> general steps we will always have a race between the different
>>>> components.
>>>
>>> Monk, just to add to this - if indeed as you say that 'FLR from
>>> hypervisor is just to notify guest the hw VF FLR is about to start
>>> or was already executed, but host will do FLR anyway without waiting
>>> for guest too long'
>>> and there is no strict waiting from the hypervisor for
>>> IDH_READY_TO_RESET to be recived from guest before starting the
>>> reset then setting in_gpu_reset and locking reset_sem from guest
>>> side is not really full proof
>>> protection from MMIO accesses by the guest - it only truly helps if
>>> hypervisor waits for that message before initiation of HW reset.
>>>
>> Hi Andrey, this cannot be done. If somehow guest kernel hangs and
>> never has the chance to send the response back, then other VFs will
>> have to wait it reset. All the vfs will hang in this case. Or
>> sometimes the mailbox has some delay and other VFs will also wait.
>> The user of other VFs will be affected in this case.
>
> Yeah, agree completely with JingWen. The hypervisor is the one in
> charge here, not the guest.
>
> What the hypervisor should do (and it already seems to be designed
> that way) is to send the guest a message that a reset is about to
> happen and give it some time to response appropriately.
>
> The guest on the other hand then tells the hypervisor that all
> processing has stopped and it is ready to restart. If that doesn't
> happen in time the hypervisor should eliminate the guest probably
> trigger even more severe consequences, e.g. restart the whole VM etc...
>
> Christian.
So what's the end conclusion here regarding dropping this particular
patch ? Seems to me we still need to drop it to prevent driver's MMIO access
to the GPU during reset from various places in the code.
Andrey
>
>>> Andrey
>>>
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>> Am 04.01.22 um 11:49 schrieb Liu, Monk:
>>>>> [AMD Official Use Only]
>>>>>
>>>>>>> See the FLR request from the hypervisor is just another source
>>>>>>> of signaling the need for a reset, similar to each job timeout
>>>>>>> on each queue. Otherwise you have a race condition between the
>>>>>>> hypervisor and the scheduler.
>>>>> No it's not, FLR from hypervisor is just to notify guest the hw VF
>>>>> FLR is about to start or was already executed, but host will do
>>>>> FLR anyway without waiting for guest too long
>>>>>
>>>>>>> In other words I strongly think that the current SRIOV reset
>>>>>>> implementation is severely broken and what Andrey is doing is
>>>>>>> actually fixing it.
>>>>> It makes the code to crash ... how could it be a fix ?
>>>>>
>>>>> I'm afraid the patch is NAK from me, but it is welcome if the
>>>>> cleanup do not ruin the logic, Andry or jingwen can try it if needed.
>>>>>
>>>>> Thanks
>>>>> -------------------------------------------------------------------
>>>>> Monk Liu | Cloud GPU & Virtualization Solution | AMD
>>>>> -------------------------------------------------------------------
>>>>> we are hiring software manager for CVS core team
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> -----Original Message-----
>>>>> From: Koenig, Christian <Christian.Koenig@amd.com>
>>>>> Sent: Tuesday, January 4, 2022 6:19 PM
>>>>> To: Chen, JingWen <JingWen.Chen2@amd.com>; Christian König
>>>>> <ckoenig.leichtzumerken@gmail.com>; Grodzovsky, Andrey
>>>>> <Andrey.Grodzovsky@amd.com>; Deng, Emily <Emily.Deng@amd.com>;
>>>>> Liu, Monk <Monk.Liu@amd.com>; dri-devel@lists.freedesktop.org;
>>>>> amd-gfx@lists.freedesktop.org; Chen, Horace <Horace.Chen@amd.com>;
>>>>> Chen, JingWen <JingWen.Chen2@amd.com>
>>>>> Cc: daniel@ffwll.ch
>>>>> Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset
>>>>> protection for SRIOV
>>>>>
>>>>> Hi Jingwen,
>>>>>
>>>>> well what I mean is that we need to adjust the implementation in
>>>>> amdgpu to actually match the requirements.
>>>>>
>>>>> Could be that the reset sequence is questionable in general, but I
>>>>> doubt so at least for now.
>>>>>
>>>>> See the FLR request from the hypervisor is just another source of
>>>>> signaling the need for a reset, similar to each job timeout on
>>>>> each queue. Otherwise you have a race condition between the
>>>>> hypervisor and the scheduler.
>>>>>
>>>>> Properly setting in_gpu_reset is indeed mandatory, but should
>>>>> happen at a central place and not in the SRIOV specific code.
>>>>>
>>>>> In other words I strongly think that the current SRIOV reset
>>>>> implementation is severely broken and what Andrey is doing is
>>>>> actually fixing it.
>>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>> Am 04.01.22 um 10:07 schrieb JingWen Chen:
>>>>>> Hi Christian,
>>>>>> I'm not sure what do you mean by "we need to change SRIOV not the
>>>>>> driver".
>>>>>>
>>>>>> Do you mean we should change the reset sequence in SRIOV? This
>>>>>> will be a huge change for our SRIOV solution.
>>>>>>
>>>>>> From my point of view, we can directly use
>>>>>> amdgpu_device_lock_adev
>>>>>> and amdgpu_device_unlock_adev in flr_work instead of try_lock
>>>>>> since no one will conflict with this thread with reset_domain
>>>>>> introduced.
>>>>>> But we do need the reset_sem and adev->in_gpu_reset to keep
>>>>>> device untouched via user space.
>>>>>>
>>>>>> Best Regards,
>>>>>> Jingwen Chen
>>>>>>
>>>>>> On 2022/1/3 下午6:17, Christian König wrote:
>>>>>>> Please don't. This patch is vital to the cleanup of the reset
>>>>>>> procedure.
>>>>>>>
>>>>>>> If SRIOV doesn't work with that we need to change SRIOV and not
>>>>>>> the driver.
>>>>>>>
>>>>>>> Christian.
>>>>>>>
>>>>>>> Am 30.12.21 um 19:45 schrieb Andrey Grodzovsky:
>>>>>>>> Sure, I guess i can drop this patch then.
>>>>>>>>
>>>>>>>> Andrey
>>>>>>>>
>>>>>>>> On 2021-12-24 4:57 a.m., JingWen Chen wrote:
>>>>>>>>> I do agree with shaoyun, if the host find the gpu engine hangs
>>>>>>>>> first, and do the flr, guest side thread may not know this and
>>>>>>>>> still try to access HW(e.g. kfd is using a lot of
>>>>>>>>> amdgpu_in_reset and reset_sem to identify the reset status).
>>>>>>>>> And this may lead to very bad result.
>>>>>>>>>
>>>>>>>>> On 2021/12/24 下午4:58, Deng, Emily wrote:
>>>>>>>>>> These patches look good to me. JingWen will pull these
>>>>>>>>>> patches and do some basic TDR test on sriov environment, and
>>>>>>>>>> give feedback.
>>>>>>>>>>
>>>>>>>>>> Best wishes
>>>>>>>>>> Emily Deng
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Liu, Monk <Monk.Liu@amd.com>
>>>>>>>>>>> Sent: Thursday, December 23, 2021 6:14 PM
>>>>>>>>>>> To: Koenig, Christian <Christian.Koenig@amd.com>; Grodzovsky,
>>>>>>>>>>> Andrey <Andrey.Grodzovsky@amd.com>;
>>>>>>>>>>> dri-devel@lists.freedesktop.org; amd-
>>>>>>>>>>> gfx@lists.freedesktop.org;
>>>>>>>>>>> Chen, Horace <Horace.Chen@amd.com>; Chen, JingWen
>>>>>>>>>>> <JingWen.Chen2@amd.com>; Deng, Emily <Emily.Deng@amd.com>
>>>>>>>>>>> Cc: daniel@ffwll.ch
>>>>>>>>>>> Subject: RE: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU
>>>>>>>>>>> reset
>>>>>>>>>>> protection for SRIOV
>>>>>>>>>>>
>>>>>>>>>>> [AMD Official Use Only]
>>>>>>>>>>>
>>>>>>>>>>> @Chen, Horace @Chen, JingWen @Deng, Emily
>>>>>>>>>>>
>>>>>>>>>>> Please take a review on Andrey's patch
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> -- Monk Liu | Cloud GPU & Virtualization Solution | AMD
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> -- we are hiring software manager for CVS core team
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Koenig, Christian <Christian.Koenig@amd.com>
>>>>>>>>>>> Sent: Thursday, December 23, 2021 4:42 PM
>>>>>>>>>>> To: Grodzovsky, Andrey <Andrey.Grodzovsky@amd.com>; dri-
>>>>>>>>>>> devel@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
>>>>>>>>>>> Cc: daniel@ffwll.ch; Liu, Monk <Monk.Liu@amd.com>; Chen, Horace
>>>>>>>>>>> <Horace.Chen@amd.com>
>>>>>>>>>>> Subject: Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU
>>>>>>>>>>> reset
>>>>>>>>>>> protection for SRIOV
>>>>>>>>>>>
>>>>>>>>>>> Am 22.12.21 um 23:14 schrieb Andrey Grodzovsky:
>>>>>>>>>>>> Since now flr work is serialized against GPU resets there
>>>>>>>>>>>> is no
>>>>>>>>>>>> need for this.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>>>>>>>>> Acked-by: Christian König <christian.koenig@amd.com>
>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 11 -----------
>>>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 11 -----------
>>>>>>>>>>>> 2 files changed, 22 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
>>>>>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
>>>>>>>>>>>> index 487cd654b69e..7d59a66e3988 100644
>>>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
>>>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
>>>>>>>>>>>> @@ -248,15 +248,7 @@ static void
>>>>>>>>>>>> xgpu_ai_mailbox_flr_work(struct
>>>>>>>>>>> work_struct *work)
>>>>>>>>>>>> struct amdgpu_device *adev = container_of(virt,
>>>>>>>>>>>> struct
>>>>>>>>>>> amdgpu_device, virt);
>>>>>>>>>>>> int timeout = AI_MAILBOX_POLL_FLR_TIMEDOUT;
>>>>>>>>>>>>
>>>>>>>>>>>> - /* block amdgpu_gpu_recover till msg FLR COMPLETE
>>>>>>>>>>>> received,
>>>>>>>>>>>> - * otherwise the mailbox msg will be ruined/reseted by
>>>>>>>>>>>> - * the VF FLR.
>>>>>>>>>>>> - */
>>>>>>>>>>>> - if (!down_write_trylock(&adev->reset_sem))
>>>>>>>>>>>> - return;
>>>>>>>>>>>> -
>>>>>>>>>>>> amdgpu_virt_fini_data_exchange(adev);
>>>>>>>>>>>> - atomic_set(&adev->in_gpu_reset, 1);
>>>>>>>>>>>>
>>>>>>>>>>>> xgpu_ai_mailbox_trans_msg(adev,
>>>>>>>>>>>> IDH_READY_TO_RESET, 0,
>>>>>>>>>>>> 0, 0);
>>>>>>>>>>>>
>>>>>>>>>>>> @@ -269,9 +261,6 @@ static void
>>>>>>>>>>>> xgpu_ai_mailbox_flr_work(struct
>>>>>>>>>>> work_struct *work)
>>>>>>>>>>>> } while (timeout > 1);
>>>>>>>>>>>>
>>>>>>>>>>>> flr_done:
>>>>>>>>>>>> - atomic_set(&adev->in_gpu_reset, 0);
>>>>>>>>>>>> - up_write(&adev->reset_sem);
>>>>>>>>>>>> -
>>>>>>>>>>>> /* Trigger recovery for world switch failure if
>>>>>>>>>>>> no TDR
>>>>>>>>>>>> */
>>>>>>>>>>>> if (amdgpu_device_should_recover_gpu(adev)
>>>>>>>>>>>> && (!amdgpu_device_has_job_running(adev) || diff
>>>>>>>>>>>> --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>>>>>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>>>>>>>>>>>> index e3869067a31d..f82c066c8e8d 100644
>>>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>>>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>>>>>>>>>>>> @@ -277,15 +277,7 @@ static void
>>>>>>>>>>>> xgpu_nv_mailbox_flr_work(struct
>>>>>>>>>>> work_struct *work)
>>>>>>>>>>>> struct amdgpu_device *adev = container_of(virt,
>>>>>>>>>>>> struct
>>>>>>>>>>> amdgpu_device, virt);
>>>>>>>>>>>> int timeout = NV_MAILBOX_POLL_FLR_TIMEDOUT;
>>>>>>>>>>>>
>>>>>>>>>>>> - /* block amdgpu_gpu_recover till msg FLR COMPLETE
>>>>>>>>>>>> received,
>>>>>>>>>>>> - * otherwise the mailbox msg will be ruined/reseted by
>>>>>>>>>>>> - * the VF FLR.
>>>>>>>>>>>> - */
>>>>>>>>>>>> - if (!down_write_trylock(&adev->reset_sem))
>>>>>>>>>>>> - return;
>>>>>>>>>>>> -
>>>>>>>>>>>> amdgpu_virt_fini_data_exchange(adev);
>>>>>>>>>>>> - atomic_set(&adev->in_gpu_reset, 1);
>>>>>>>>>>>>
>>>>>>>>>>>> xgpu_nv_mailbox_trans_msg(adev,
>>>>>>>>>>>> IDH_READY_TO_RESET, 0,
>>>>>>>>>>>> 0, 0);
>>>>>>>>>>>>
>>>>>>>>>>>> @@ -298,9 +290,6 @@ static void
>>>>>>>>>>>> xgpu_nv_mailbox_flr_work(struct
>>>>>>>>>>> work_struct *work)
>>>>>>>>>>>> } while (timeout > 1);
>>>>>>>>>>>>
>>>>>>>>>>>> flr_done:
>>>>>>>>>>>> - atomic_set(&adev->in_gpu_reset, 0);
>>>>>>>>>>>> - up_write(&adev->reset_sem);
>>>>>>>>>>>> -
>>>>>>>>>>>> /* Trigger recovery for world switch failure if
>>>>>>>>>>>> no TDR
>>>>>>>>>>>> */
>>>>>>>>>>>> if (amdgpu_device_should_recover_gpu(adev)
>>>>>>>>>>>> && (!amdgpu_device_has_job_running(adev) ||
>
^ permalink raw reply
* Re: [PATCH] RDMA/uverbs: Check for null return of kmalloc_array
From: Jason Gunthorpe @ 2022-01-05 18:24 UTC (permalink / raw)
To: Jiasheng Jiang; +Cc: dledford, linux-rdma, linux-kernel
In-Reply-To: <20211231093315.1917667-1-jiasheng@iscas.ac.cn>
On Fri, Dec 31, 2021 at 05:33:15PM +0800, Jiasheng Jiang wrote:
> Because of the possible failure of the allocation, data might be NULL
> pointer and will cause the dereference of the NULL pointer later.
> Therefore, it might be better to check it and return -ENOMEM.
>
> Fixes: 6884c6c4bd09 ("RDMA/verbs: Store the write/write_ex uapi entry points in the uverbs_api")
> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
> Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/infiniband/core/uverbs_uapi.c | 3 +++
> 1 file changed, 3 insertions(+)
Applied to for-rc, thanks
Jason
^ permalink raw reply
* Re: [RFC][V9][PATCH 0/6] btrfs: allocation_hint mode
From: Goffredo Baroncelli @ 2022-01-05 18:16 UTC (permalink / raw)
To: Zygo Blaxell, Josef Bacik
Cc: Boris Burkov, linux-btrfs, David Sterba, Sinnamohideen Shafeeq,
Paul Jones
In-Reply-To: <YdXeepXbRpbADrJf@hungrycats.org>
On 05/01/2022 19.07, Zygo Blaxell wrote:
> On Wed, Jan 05, 2022 at 10:16:08AM +0100, Goffredo Baroncelli wrote:
>> Hi Boris,
>>
>>
>>
>> On 1/5/22 03:44, Boris Burkov wrote:
>> [...]
>>>
>>> This is cool, thanks for building it!
>>>
>>> I'm playing with setting this up for a test I'm working on where I want
>>> to send data to a dm-zero device. To that end, I applied this patchset
>>> on top of misc-next and ran:
>>>
>>> $ mkfs.btrfs -f /dev/vg0/lv0 -dsingle -msingle
>>> $ mount /dev/vg0/lv0 /mnt/lol
>>
>> You should mount the filesystem with
>>
>> $ mount -o allocation_hint=1 /dev/vg0/lv0 /mnt/lol
>>
>> In the previous iteration I missed the patch #6, which activates this option. You can drop patch #6 and avoid to pass this option.
>
> Can we drop the mount option from the series? It isn't needed.
>
> Or, if we must have it (and I am in no way conceding that we do),
> at least make it default to enabled. Or turn the mount option into a
> disable flag under the 'rescue=' option to make it clear this option is
> not intended to be used in normal operation.
Frankly speaking it was a my mistake to add this patch. It was in the
queue, but in the last patches sets I dropped it. However in the last
one I forgot to drop it manually so it reappeared :-)
However I like your suggestion to add as 'rescue' option, where the
default is "enabled".
@Josef,
do you started to play with this patch ? If not can I send an update
where the main change is the renaming of the properties from
PREFERRED_<X> to <X>_PREFERRED
(e.g. PREFERRED_DATA to DATA_PREFERRED) which are more correct ?
BR
G.Baroncelli
>
>> Please give me a feedback if this resolve.
>>
>> BR
>> G.Baroncelli
>>
>>> $ btrfs device add /dev/mapper/zero-data /mnt/lol
>>> $ btrfs fi usage /mnt/lol
>>> Overall:
>>> Device size: 50.01TiB
>>> Device allocated: 20.00MiB
>>> Device unallocated: 50.01TiB
>>> Device missing: 0.00B
>>> Used: 128.00KiB
>>> Free (estimated): 50.01TiB (min: 50.01TiB)
>>> Free (statfs, df): 50.01TiB
>>> Data ratio: 1.00
>>> Metadata ratio: 1.00
>>> Global reserve: 3.25MiB (used: 0.00B)
>>> Multiple profiles: no
>>>
>>> Data,single: Size:8.00MiB, Used:0.00B (0.00%)
>>> /dev/mapper/vg0-lv0 8.00MiB
>>>
>>> Metadata,single: Size:8.00MiB, Used:112.00KiB (1.37%)
>>> /dev/mapper/vg0-lv0 8.00MiB
>>>
>>> System,single: Size:4.00MiB, Used:16.00KiB (0.39%)
>>> /dev/mapper/vg0-lv0 4.00MiB
>>>
>>> Unallocated:
>>> /dev/mapper/vg0-lv0 9.98GiB
>>> /dev/mapper/zero-data 50.00TiB
>>>
>>> $ ./btrfs property set -t device /dev/mapper/zero-data allocation_hint DATA_ONLY
>>> $ ./btrfs property set -t device /dev/vg0/lv0 allocation_hint METADATA_ONLY
>>>
>>> $ btrfs balance start --full-balance /mnt/lol
>>> Done, had to relocate 3 out of 3 chunks
>>>
>>> $ btrfs fi usage /mnt/lol
>>> Overall:
>>> Device size: 50.01TiB
>>> Device allocated: 2.03GiB
>>> Device unallocated: 50.01TiB
>>> Device missing: 0.00B
>>> Used: 640.00KiB
>>> Free (estimated): 50.01TiB (min: 50.01TiB)
>>> Free (statfs, df): 50.01TiB
>>> Data ratio: 1.00
>>> Metadata ratio: 1.00
>>> Global reserve: 3.25MiB (used: 0.00B)
>>> Multiple profiles: no
>>>
>>> Data,single: Size:1.00GiB, Used:512.00KiB (0.05%)
>>> /dev/mapper/zero-data 1.00GiB
>>>
>>> Metadata,single: Size:1.00GiB, Used:112.00KiB (0.01%)
>>> /dev/mapper/zero-data 1.00GiB
>>>
>>> System,single: Size:32.00MiB, Used:16.00KiB (0.05%)
>>> /dev/mapper/zero-data 32.00MiB
>>>
>>> Unallocated:
>>> /dev/mapper/vg0-lv0 10.00GiB
>>> /dev/mapper/zero-data 50.00TiB
>>>
>>>
>>> I expected that I would have data on /dev/mapper/zero-data and metadata
>>> on /dev/mapper/vg0-lv0, but it seems both of them were written to the zero
>>> device. Attempting to actually use the file system eventually fails, since
>>> the metadata is black-holed :)
>>>
>>> Did I make some mistake in how I used it, or is this a bug?
>>>
>>> Thanks,
>>> Boris
>>>
>>>> BR
>>>> G.Baroncelli
>>>>
>>>> Revision:
>>>> V9:
>>>> - rename dev_item->type to dev_item->flags
>>>> - rename /sys/fs/btrfs/$UUID/devinfo/type -> allocation_hint
>>>>
>>>> V8:
>>>> - drop the ioctl API, instead use a sysfs one
>>>>
>>>> V7:
>>>> - make more room in the struct btrfs_ioctl_dev_properties up to 1K
>>>> - leave in btrfs_tree.h only the costants
>>>> - removed the mount option (sic)
>>>> - correct an 'use before check' in the while loop (signaled
>>>> by Zygo)
>>>> - add a 2nd sort to be sure that the device_info array is in the
>>>> expected order
>>>>
>>>> V6:
>>>> - add further values to the hints: add the possibility to
>>>> exclude a disk for a chunk type
>>>>
>>>>
>>>> Goffredo Baroncelli (6):
>>>> btrfs: add flags to give an hint to the chunk allocator
>>>> btrfs: export the device allocation_hint property in sysfs
>>>> btrfs: change the device allocation_hint property via sysfs
>>>> btrfs: add allocation_hint mode
>>>> btrfs: rename dev_item->type to dev_item->flags
>>>> btrfs: add allocation_hint option.
>>>>
>>>> fs/btrfs/ctree.h | 18 +++++-
>>>> fs/btrfs/disk-io.c | 4 +-
>>>> fs/btrfs/super.c | 17 ++++++
>>>> fs/btrfs/sysfs.c | 73 ++++++++++++++++++++++
>>>> fs/btrfs/volumes.c | 105 ++++++++++++++++++++++++++++++--
>>>> fs/btrfs/volumes.h | 7 ++-
>>>> include/uapi/linux/btrfs_tree.h | 20 +++++-
>>>> 7 files changed, 232 insertions(+), 12 deletions(-)
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>
>>
>> --
>> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
>> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: [PATCH][TRIVIAL] btrfs-progs: Allow autodetect_object_types() to handle the link.
From: Goffredo Baroncelli @ 2022-01-05 18:23 UTC (permalink / raw)
To: Boris Burkov; +Cc: linux-btrfs, Goffredo Baroncelli
In-Reply-To: <YdXaZP27ALM6KJ9G@zen>
On 05/01/2022 18.50, Boris Burkov wrote:
> On Wed, Jan 05, 2022 at 02:32:58PM +0100, Goffredo Baroncelli wrote:
>> From: Goffredo Baroncelli <kreijack@inwind.it>
[...]
>
> I took a look at the original lstat and it doesn't seem super strongly
> motivated. It is used to detect a subvolume object (ino==256) so I don't
> see why we would hate to have property get/set work on a symlink to a
> subvol.
It is not so simple: think about a case where the symlink points to a
subvolume of *another* filesystem.
Now, "btrfs prop get" returns the property (e.g. the label) of the *underlining*
filesystem. If we change statl to stat, it still return the property of the
underlining filesystem, thinking that it is a subvolume (of a foreign filesystem).
If fact I added an exception of that rule, because if we pass a block device, we
don't consider the underling filesystem, but the filesystem contained in the block
device. But there is a precedence in get/set label.
Anyway, symlink created some confusion, and I bet that in btrfs there are areas
with incoherence around symlink between the pointed object and the underling
filesystem.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: [PATCH v9 02/10] dax: Introduce holder for dax_device
From: Dan Williams @ 2022-01-05 18:23 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Shiyang Ruan, Linux Kernel Mailing List, linux-xfs, Linux NVDIMM,
Linux MM, linux-fsdevel, david, Christoph Hellwig, Jane Chu
In-Reply-To: <20220105181230.GC398655@magnolia>
On Wed, Jan 5, 2022 at 10:12 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Sun, Dec 26, 2021 at 10:34:31PM +0800, Shiyang Ruan wrote:
> > To easily track filesystem from a pmem device, we introduce a holder for
> > dax_device structure, and also its operation. This holder is used to
> > remember who is using this dax_device:
> > - When it is the backend of a filesystem, the holder will be the
> > instance of this filesystem.
> > - When this pmem device is one of the targets in a mapped device, the
> > holder will be this mapped device. In this case, the mapped device
> > has its own dax_device and it will follow the first rule. So that we
> > can finally track to the filesystem we needed.
> >
> > The holder and holder_ops will be set when filesystem is being mounted,
> > or an target device is being activated.
> >
> > Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> > ---
> > drivers/dax/super.c | 62 +++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/dax.h | 29 +++++++++++++++++++++
> > 2 files changed, 91 insertions(+)
> >
> > diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> > index c46f56e33d40..94c51f2ee133 100644
> > --- a/drivers/dax/super.c
> > +++ b/drivers/dax/super.c
> > @@ -20,15 +20,20 @@
> > * @inode: core vfs
> > * @cdev: optional character interface for "device dax"
> > * @private: dax driver private data
> > + * @holder_data: holder of a dax_device: could be filesystem or mapped device
> > * @flags: state and boolean properties
> > + * @ops: operations for dax_device
> > + * @holder_ops: operations for the inner holder
> > */
> > struct dax_device {
> > struct inode inode;
> > struct cdev cdev;
> > void *private;
> > struct percpu_rw_semaphore rwsem;
> > + void *holder_data;
> > unsigned long flags;
> > const struct dax_operations *ops;
> > + const struct dax_holder_operations *holder_ops;
> > };
> >
> > static dev_t dax_devt;
> > @@ -192,6 +197,29 @@ int dax_zero_page_range(struct dax_device *dax_dev, pgoff_t pgoff,
> > }
> > EXPORT_SYMBOL_GPL(dax_zero_page_range);
> >
> > +int dax_holder_notify_failure(struct dax_device *dax_dev, u64 off,
> > + u64 len, int mf_flags)
> > +{
> > + int rc;
> > +
> > + dax_read_lock(dax_dev);
> > + if (!dax_alive(dax_dev)) {
> > + rc = -ENXIO;
> > + goto out;
> > + }
> > +
> > + if (!dax_dev->holder_ops) {
> > + rc = -EOPNOTSUPP;
> > + goto out;
> > + }
> > +
> > + rc = dax_dev->holder_ops->notify_failure(dax_dev, off, len, mf_flags);
> > +out:
> > + dax_read_unlock(dax_dev);
> > + return rc;
> > +}
> > +EXPORT_SYMBOL_GPL(dax_holder_notify_failure);
> > +
> > #ifdef CONFIG_ARCH_HAS_PMEM_API
> > void arch_wb_cache_pmem(void *addr, size_t size);
> > void dax_flush(struct dax_device *dax_dev, void *addr, size_t size)
> > @@ -254,6 +282,10 @@ void kill_dax(struct dax_device *dax_dev)
> > return;
> > dax_write_lock(dax_dev);
> > clear_bit(DAXDEV_ALIVE, &dax_dev->flags);
> > +
> > + /* clear holder data */
> > + dax_dev->holder_ops = NULL;
> > + dax_dev->holder_data = NULL;
> > dax_write_unlock(dax_dev);
> > }
> > EXPORT_SYMBOL_GPL(kill_dax);
> > @@ -401,6 +433,36 @@ void put_dax(struct dax_device *dax_dev)
> > }
> > EXPORT_SYMBOL_GPL(put_dax);
> >
> > +void dax_register_holder(struct dax_device *dax_dev, void *holder,
> > + const struct dax_holder_operations *ops)
> > +{
> > + if (!dax_alive(dax_dev))
> > + return;
> > +
> > + dax_dev->holder_data = holder;
> > + dax_dev->holder_ops = ops;
>
> Shouldn't this return an error code if the dax device is dead or if
> someone already registered a holder? I'm pretty sure XFS should not
> bind to a dax device if someone else already registered for it...
Agree, yes.
>
> ...unless you want to use a notifier chain for failure events so that
> there can be multiple consumers of dax failure events?
No, I would hope not. It should be 1:1 holders to dax-devices. Similar
ownership semantics like bd_prepare_to_claim().
^ permalink raw reply
* Apparent interaction between recursive submodule push and self-submodules
From: Dave Abrahams @ 2022-01-05 18:22 UTC (permalink / raw)
To: git
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
In your .gitconfig, have
[submodule]
recurse = true
Then follow this script:
```
$ mkdir x
$ cd x; git init
Initialized empty Git repository in /private/tmp/x/.git/
$ touch a
$ git add a
$ git commit -m 'initial'
[main (root-commit) 0afd184] initial
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
$ cd ..
$ git clone x y
Cloning into 'y'...
done.
$ cd y
$ git branch -c b
$ git submodule add ../x self
Cloning into '/private/tmp/y/self'...
done.
$ git submodule update --init
$ git push origin HEAD:refs/heads/b
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To /private/tmp/x
* [new branch] HEAD -> b
$ cd self
$ echo 'first change' >> a
$ git commit -a -m 'first change on main'
[main 80466da] first change on main
1 file changed, 1 insertion(+)
$ cd ..
$ git add .gitmodules self
$ git commit -m 'update to point at new submodule'
[main 4f5a1b7] update to point at new submodule
2 files changed, 4 insertions(+)
create mode 100644 .gitmodules
create mode 160000 self
$ git push origin HEAD:b
Pushing submodule 'self'
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 252 bytes | 252.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To /private/tmp/x
0afd184..80466da HEAD -> b
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 10 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 357 bytes | 357.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: cannot lock ref 'refs/heads/b': is at 80466da48f71630dc87553ca75e216cf6f1dfda9 but expected 0afd18466f353590ae52219e32a712691a59b60b
To /private/tmp/x
! [remote rejected] HEAD -> b (failed to update ref)
error: failed to push some refs to '/private/tmp/x'
$
```
What did you expect to happen? (Expected behavior)
No error
What happened instead? (Actual behavior)
See error above.
What's different between what you expected and what actually happened?
Anything else you want to add:
If I do this with a repository cloned via ssh and a submodule cloned via https,
I get a different error:
```
$ git push -v origin refs/heads/gh-pages\:refs/heads/gh-pages
Pushing to github.com:stlab/adobe-reveal-theme
fatal: bad object f7cc6f9014af46fb9cfcaae26b82ac830593df6d
error: remote unpack failed: eof before pack header was fully read
To github.com:stlab/adobe-reveal-theme
! [remote rejected] gh-pages -> gh-pages (failed)
error: failed to push some refs to 'github.com:stlab/adobe-reveal-theme'
```
The issue appears to be an interaction between recursive submodule push and the fact
that the submodule comes from the same repository as its super-module.
[System Info]
git version:
git version 2.32.0 (Apple Git-132)
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000 arm64
compiler info: clang: 13.0.0 (clang-1300.0.29.30)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
not run from a git repository - no hooks to show
^ permalink raw reply
* Re: [PATCH] arm64: Drop outdated links in comments
From: Catalin Marinas @ 2022-01-05 18:21 UTC (permalink / raw)
To: Joe Perches, Will Deacon, Kees Cook
Cc: linux-kernel, James Morse, Pasha Tatashin, linux-arm-kernel,
Vincenzo Frascino, Fuad Tabba, Russell King
In-Reply-To: <20211215191835.1420010-1-keescook@chromium.org>
On Wed, 15 Dec 2021 11:18:35 -0800, Kees Cook wrote:
> As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org links
> with lore"), an effort was made to replace lkml.org links with lore to
> better use a single source that's more likely to stay available long-term.
> However, it seems these links don't offer much value here, so just
> remove them entirely.
>
>
> [...]
Applied to arm64 (for-next/misc) but without the arch/arm changes.
Please send them separately to Russell's patch system. Thanks!
[1/1] arm64: Drop outdated links in comments
https://git.kernel.org/arm64/c/89d30b11507d
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Trying to understand QOM object creation and property linking
From: Alex Bennée @ 2022-01-05 18:03 UTC (permalink / raw)
To: Paolo Bonzini, Daniel P. Berrange, Eduardo Habkost
Cc: Peter Maydell, qemu-devel
Hi,
I'm having a hell of a time trying to create a new SoC+Board model from
scratch. The problem comes down to trying to expose some properties to
the underlying CPU from my board model. So I have:
static const TypeInfo pipico_machine_types[] = {
{
.name = TYPE_PIPICO_MACHINE,
.parent = TYPE_MACHINE,
.instance_size = sizeof(PiPicoMachineState),
.class_size = sizeof(PiPicoMachineClass),
.class_init = pipico_machine_class_init,
}
};
and the class init sets:
MachineClass *mc = MACHINE_CLASS(oc);
...
mc->desc = g_strdup_printf("Raspberry Pi Pico");
mc->init = pipico_machine_init;
...
and finally when I init the machine I do the following:
static void pipico_machine_init(MachineState *machine)
{
PiPicoMachineState *s = PIPICO_MACHINE(machine);
...
MemoryRegion *system_memory = get_system_memory();
...
/* initialize external Flash device */
memory_region_init_rom(&s->flash, NULL,
"pico.flash0", 256 * KiB, &error_fatal);
memory_region_add_subregion(system_memory, 0, &s->flash);
/* Setup the SOC */
object_initialize_child(OBJECT(machine), "soc", &s->soc, TYPE_RP2040);
/* link properties from machine the SoC needs */
object_property_set_link(OBJECT(&s->soc), "memory",
OBJECT(system_memory), &error_fatal);
sysbus_realize(SYS_BUS_DEVICE(&s->soc), &error_fatal);
The initialisation of the SoC is simple because I can't do much until
things are realised:
static void rp2040_init(Object *obj)
{
RP2040State *s = RP2040(obj);
int n;
fprintf(stderr, "%s: %p\n", __func__, obj);
for (n = 0; n < RP2040_NCPUS; n++) {
object_initialize_child(obj, "cpu[*]", &s->armv7m[n], TYPE_ARMV7M);
qdev_prop_set_string(DEVICE(&s->armv7m[n]), "cpu-type",
ARM_CPU_TYPE_NAME("cortex-m0"));
}
}
However when I get to realize the SoC itself:
static void rp2040_realize(DeviceState *dev, Error **errp)
{
RP2040State *s = RP2040(dev);
Object *obj = OBJECT(dev);
int n;
if (!s->board_memory) {
error_setg(errp, "%s: memory property was not set", __func__);
return;
}
/* initialize internal 16 KB internal ROM */
memory_region_init_rom(&s->rom, obj, "rp2040.rom0", 16 * KiB, errp);
memory_region_add_subregion(s->board_memory, 0, &s->rom);
/* SRAM (Main 256k bank + two 4k banks)*/
memory_region_init_ram(&s->sram03, obj, "rp2040.sram03", 256 * KiB, errp);
memory_region_add_subregion(s->board_memory, RP2040_SRAM_BASE, &s->sram03);
memory_region_init_ram(&s->sram4, obj, "rp2040.sram4", 4 * KiB, errp);
memory_region_add_subregion(s->board_memory, RP2040_SRAM4_BASE, &s->sram4);
memory_region_init_ram(&s->sram5, obj, "rp2040.sram5", 4 * KiB, errp);
memory_region_add_subregion(s->board_memory, RP2040_SRAM5_BASE, &s->sram5);
...
for (n = 0; n < RP2040_NCPUS; n++) {
/* DeviceState *cpudev = DEVICE(&s->armv7m[i]); */
Object *cpuobj = OBJECT(&s->armv7m[n]);
object_property_set_link(cpuobj, "memory",
OBJECT(&s->board_memory), errp);
And this passing of the link down to the CPU I segfault:
rp2040_init: 0x555556d08710
Thread 1 "qemu-system-arm" received signal SIGSEGV, Segmentation fault.
object_get_canonical_path_component (obj=0x555556d0ea28) at ../../qom/object.c:1999
1999 g_hash_table_iter_init(&iter, obj->parent->properties);
(gdb) bt
#0 object_get_canonical_path_component (obj=0x555556d0ea28) at ../../qom/object.c:1999
#1 0x0000555555fb27ea in object_get_canonical_path (obj=0x555556d0ea28) at ../../qom/object.c:2025
#2 0x0000555555fb1250 in object_property_set_link (obj=0x555556d087a0, name=0x5555563190a2 "memory", value=0x555556d0ea28, errp=0x7fffffffe0f0) at ../../qom/object.c:1445
#3 0x0000555555cf3c23 in rp2040_realize (dev=0x555556d08710, errp=0x7fffffffe0f0) at ../../hw/arm/rp2040.c:85
#4 0x0000555555fa9323 in device_set_realized (obj=0x555556d08710, value=true, errp=0x7fffffffe200) at ../../hw/core/qdev.c:532
#5 0x0000555555fb300d in property_set_bool (obj=0x555556d08710, v=0x555556dced10, name=0x5555563822b9 "realized", opaque=0x555556a3a6d0, errp=0x7fffffffe200) at ../../qom/object.c:2268
#6 0x0000555555fb1054 in object_property_set (obj=0x555556d08710, name=0x5555563822b9 "realized", v=0x555556dced10, errp=0x7fffffffe200) at ../../qom/object.c:1403
#7 0x0000555555fb53ff in object_property_set_qobject (obj=0x555556d08710, name=0x5555563822b9 "realized", value=0x555556e79bc0, errp=0x555556918de0 <error_fatal>) at ../../qom/qom-qobject.c:28
#8 0x0000555555fb13b9 in object_property_set_bool (obj=0x555556d08710, name=0x5555563822b9 "realized", value=true, errp=0x555556918de0 <error_fatal>) at ../../qom/object.c:1472
#9 0x0000555555fa8beb in qdev_realize (dev=0x555556d08710, bus=0x555556d0f240, errp=0x555556918de0 <error_fatal>) at ../../hw/core/qdev.c:334
#10 0x00005555559f0e28 in sysbus_realize (dev=0x555556d08710, errp=0x555556918de0 <error_fatal>) at ../../hw/core/sysbus.c:256
#11 0x0000555555cf3f0e in pipico_machine_init (machine=0x555556d08600) at ../../hw/arm/raspi_pico.c:74
#12 0x00005555559ed71b in machine_run_board_init (machine=0x555556d08600) at ../../hw/core/machine.c:1184
#13 0x0000555555e67f2c in qemu_init_board () at ../../softmmu/vl.c:2655
#14 0x0000555555e6814a in qmp_x_exit_preconfig (errp=0x555556918de0 <error_fatal>) at ../../softmmu/vl.c:2743
#15 0x0000555555e6a811 in qemu_init (argc=3, argv=0x7fffffffe6b8, envp=0x7fffffffe6d8) at ../../softmmu/vl.c:3778
#16 0x0000555555884ebd in main (argc=3, argv=0x7fffffffe6b8, envp=0x7fffffffe6d8) at ../../softmmu/main.c:49
So have I discovered a bug in QOM handling or misunderstood the way
properties are meant to be shared from the main machine to the
underlying CPU?
Follow-up questions, does only creating the main memory aliases as part
of the SoC make sense? My rational is most of the memory is part of the
SoC not the board. I assume later RP2040 based boards may have different
flash configs or even external memory.
The current (messy) state of my tree can be seen at:
https://gitlab.com/stsquad/qemu/-/commits/arm/picopi-rfc
--
Alex Bennée
^ permalink raw reply
* [mptcp:export] BUILD SUCCESS 9478f9d57df23cfa5caa4317e75a6efe6e782ab3
From: kernel test robot @ 2022-01-05 18:21 UTC (permalink / raw)
To: Matthieu Baerts; +Cc: mptcp
tree/branch: https://github.com/multipath-tcp/mptcp_net-next.git export
branch HEAD: 9478f9d57df23cfa5caa4317e75a6efe6e782ab3 DO-NOT-MERGE: mptcp: enabled by default
elapsed time: 723m
configs tested: 54
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
xtensa allyesconfig
parisc defconfig
s390 allmodconfig
s390 defconfig
s390 allyesconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allmodconfig
mips allyesconfig
powerpc allnoconfig
powerpc allyesconfig
powerpc allmodconfig
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v11 3/3] media: platform: mtk-mdp3: add Mediatek MDP3 driver
From: kernel test robot @ 2022-01-05 18:21 UTC (permalink / raw)
To: Moudy Ho, Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: kbuild-all, linux-media, Chun-Kuang Hu, Geert Uytterhoeven,
Rob Landley, Laurent Pinchart
In-Reply-To: <20220105093758.6850-4-moudy.ho@mediatek.com>
Hi Moudy,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on robh/for-next v5.16-rc8 next-20220105]
[cannot apply to mbgg-mediatek/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Moudy-Ho/media-mediatek-support-mdp3-on-mt8183-platform/20220105-173918
base: git://linuxtv.org/media_tree.git master
config: ia64-allyesconfig (https://download.01.org/0day-ci/archive/20220106/202201060241.t95Ra9LM-lkp@intel.com/config)
compiler: ia64-linux-gcc (GCC) 11.2.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
# https://github.com/0day-ci/linux/commit/696f7ac402f9778a21202f2b889c3c30a6923b3d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Moudy-Ho/media-mediatek-support-mdp3-on-mt8183-platform/20220105-173918
git checkout 696f7ac402f9778a21202f2b889c3c30a6923b3d
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/media/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:15:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:15:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function); did you mean 'SCP_IPI_MAX'?
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
| SCP_IPI_MAX
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c: In function 'mdp_probe':
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c:192:37: error: implicit declaration of function 'mtk_mutex_mdp_get'; did you mean 'mtk_mutex_get'? [-Werror=implicit-function-declaration]
192 | mdp->mdp_mutex[i] = mtk_mutex_mdp_get(&mm_pdev->dev, i);
| ^~~~~~~~~~~~~~~~~
| mtk_mutex_get
cc1: some warnings being treated as errors
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-vpu.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-vpu.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function); did you mean 'SCP_IPI_MAX'?
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
| SCP_IPI_MAX
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:14,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-regs.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-regs.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:12:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'get_comp_flag':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:35:38: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
35 | if (ctx->comp->id == MDP_COMP_RDMA0)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:35:38: note: each undeclared identifier is reported only once for each function it appears in
In file included from include/linux/bits.h:6,
from include/linux/bitops.h:6,
from include/linux/kernel.h:13,
from include/linux/clk.h:13,
from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:7:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:36:58: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
36 | return BIT(MDP_COMP_RDMA0) | BIT(MDP_COMP_RSZ1);
| ^~~~~~~~~~~~~
include/vdso/bits.h:7:44: note: in definition of macro 'BIT'
7 | #define BIT(nr) (UL(1) << (nr))
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: At top level:
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:41:55: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
41 | static int init_rdma(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'init_rdma':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:48:66: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
48 | struct mdp_comp *prz1 = ctx->comp->mdp_dev->comp[MDP_COMP_RSZ1];
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:51:38: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
51 | if (ctx->comp->id == MDP_COMP_RDMA0 && prz1)
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:52:25: note: in expansion of macro 'MM_REG_WRITE'
52 | MM_REG_WRITE(cmd, subsys_id, prz1->reg_base, PRZ_ENABLE,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:57:9: note: in expansion of macro 'MM_REG_WRITE'
57 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_RESET, BIT(0), BIT(0));
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:34:33: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
34 | cmdq_pkt_poll_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:37:9: note: in expansion of macro 'MM_REG_POLL_MASK'
37 | MM_REG_POLL_MASK((cmd), id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:58:9: note: in expansion of macro 'MM_REG_POLL'
58 | MM_REG_POLL(cmd, subsys_id, base, MDP_RDMA_MON_STA_1, BIT(8), BIT(8));
| ^~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:59:9: note: in expansion of macro 'MM_REG_WRITE'
59 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_RESET, 0x0, BIT(0));
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: At top level:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:64:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
64 | struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:11:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c: In function 'config_rdma_frame':
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:77:25: note: in expansion of macro 'MM_REG_WRITE'
77 | MM_REG_WRITE(cmd, subsys_id, base,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:80:25: note: in expansion of macro 'MM_REG_WRITE'
80 | MM_REG_WRITE(cmd, subsys_id, base,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:85:9: note: in expansion of macro 'MM_REG_WRITE'
85 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_GMCIF_CON,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:91:9: note: in expansion of macro 'MM_REG_WRITE'
91 | MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_CON, rdma->src_ctrl,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:17:9: note: in expansion of macro 'MM_REG_WRITE_MASK'
17 | MM_REG_WRITE_MASK(cmd, id, base, ofst, val, \
| ^~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c:97:25: note: in expansion of macro 'MM_REG_WRITE'
97 | MM_REG_WRITE(cmd, subsys_id,
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:14:34: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
14 | cmdq_pkt_write_mask((cmd)->pkt, id, \
| ^~
--
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:109:41: error: field 'id' has incomplete type
109 | enum mtk_mdp_comp_id id;
| ^~
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:123:59: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
123 | int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:124:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
124 | int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:127:37: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
127 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:129:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
129 | struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:131:38: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd, u32 index);
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:132:62: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
132 | int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:10:
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:43:60: error: 'MDP_PIPE_MAX' undeclared here (not in a function)
43 | struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h:44:55: error: 'MDP_MAX_COMP_COUNT' undeclared here (not in a function); did you mean 'MDP_MAX_EVENT_COUNT'?
44 | struct mdp_comp *comp[MDP_MAX_COMP_COUNT];
| ^~~~~~~~~~~~~~~~~~
| MDP_MAX_EVENT_COUNT
>> drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:47:43: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
47 | struct mmsys_cmdq_cmd *cmd, u32 count)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: In function 'mdp_path_subfrm_require':
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:62:14: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
62 | case MDP_COMP_RDMA0:
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:62:14: note: each undeclared identifier is reported only once for each function it appears in
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:63:28: error: 'MDP_PIPE_RDMA0' undeclared (first use in this function)
63 | mutex_id = MDP_PIPE_RDMA0;
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:65:14: error: 'MDP_COMP_ISP_IMGI' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_IMGI'?
65 | case MDP_COMP_ISP_IMGI:
| ^~~~~~~~~~~~~~~~~
| MDP_COMP_TYPE_IMGI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:66:28: error: 'MDP_PIPE_IMGI' undeclared (first use in this function)
66 | mutex_id = MDP_PIPE_IMGI;
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:68:14: error: 'MDP_COMP_WPEI' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WPEI'?
68 | case MDP_COMP_WPEI:
| ^~~~~~~~~~~~~
| MDP_COMP_TYPE_WPEI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:69:28: error: 'MDP_PIPE_WPEI' undeclared (first use in this function)
69 | mutex_id = MDP_PIPE_WPEI;
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:71:14: error: 'MDP_COMP_WPEI2' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WPEI'?
71 | case MDP_COMP_WPEI2:
| ^~~~~~~~~~~~~~
| MDP_COMP_TYPE_WPEI
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:72:28: error: 'MDP_PIPE_WPEI2' undeclared (first use in this function)
72 | mutex_id = MDP_PIPE_WPEI2;
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:87:22: error: 'MDP_COMP_AAL0' undeclared (first use in this function)
87 | case MDP_COMP_AAL0:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:88:22: error: 'MDP_COMP_CCORR0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_CCORR'?
88 | case MDP_COMP_CCORR0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_CCORR
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:89:22: error: 'MDP_COMP_WDMA' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_WDMA'?
89 | case MDP_COMP_WDMA:
| ^~~~~~~~~~~~~
| MDP_COMP_TYPE_WDMA
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:90:22: error: 'MDP_COMP_WROT0' undeclared (first use in this function)
90 | case MDP_COMP_WROT0:
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:91:22: error: 'MDP_COMP_TDSHP0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_HDR'?
91 | case MDP_COMP_TDSHP0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_HDR
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:92:22: error: 'MDP_COMP_RSZ1' undeclared (first use in this function)
92 | case MDP_COMP_RSZ1:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:93:22: error: 'MDP_COMP_RSZ0' undeclared (first use in this function)
93 | case MDP_COMP_RSZ0:
| ^~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:95:37: error: implicit declaration of function 'mtk_mutex_get_mdp_mod' [-Werror=implicit-function-declaration]
95 | mutex_bit = mtk_mutex_get_mdp_mod(mutex[mutex_id], id);
| ^~~~~~~~~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:104:17: error: implicit declaration of function 'mtk_mutex_add_mod_by_cmdq'; did you mean 'mtk_mutex_add_comp'? [-Werror=implicit-function-declaration]
104 | mtk_mutex_add_mod_by_cmdq(mutex[mutex_id], subfrm->mutex_mod, cmd);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| mtk_mutex_add_comp
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: At top level:
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:131:39: warning: 'struct mmsys_cmdq_cmd' declared inside parameter list will not be visible outside of this definition or declaration
131 | struct mmsys_cmdq_cmd *cmd)
| ^~~~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c: In function 'mdp_path_subfrm_run':
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:149:30: error: 'MDP_COMP_RDMA0' undeclared (first use in this function)
149 | case MDP_COMP_RDMA0:
| ^~~~~~~~~~~~~~
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:35: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:150:33: note: in expansion of macro 'MM_REG_CLEAR'
150 | MM_REG_CLEAR(cmd, RDMA0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:47: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:150:33: note: in expansion of macro 'MM_REG_CLEAR'
150 | MM_REG_CLEAR(cmd, RDMA0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:152:30: error: 'MDP_COMP_TDSHP0' undeclared (first use in this function); did you mean 'MDP_COMP_TYPE_HDR'?
152 | case MDP_COMP_TDSHP0:
| ^~~~~~~~~~~~~~~
| MDP_COMP_TYPE_HDR
In file included from drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:9:
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:35: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:153:33: note: in expansion of macro 'MM_REG_CLEAR'
153 | MM_REG_CLEAR(cmd, TDSHP0_SOF);
| ^~~~~~~~~~~~
drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h:28:47: error: invalid use of undefined type 'struct mmsys_cmdq_cmd'
28 | cmdq_pkt_clear_event((cmd)->pkt, (cmd)->event[(evt)])
| ^~
drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c:153:33: note: in expansion of macro 'MM_REG_CLEAR'
153 | MM_REG_CLEAR(cmd, TDSHP0_SOF);
| ^~~~~~~~~~~~
vim +123 drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h
100
101 struct mdp_comp {
102 struct mdp_dev *mdp_dev;
103 void __iomem *regs;
104 phys_addr_t reg_base;
105 u8 subsys_id;
106 struct clk *clks[6];
107 struct device *comp_dev;
108 enum mdp_comp_type type;
> 109 enum mtk_mdp_comp_id id;
110 u32 alias_id;
111 const struct mdp_comp_ops *ops;
112 };
113
114 struct mdp_comp_ctx {
115 struct mdp_comp *comp;
116 const struct img_compparam *param;
117 const struct img_input *input;
118 const struct img_output *outputs[IMG_MAX_HW_OUTPUTS];
119 };
120
121 struct mdp_comp_ops {
122 s64 (*get_comp_flag)(const struct mdp_comp_ctx *ctx);
> 123 int (*init_comp)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
124 int (*config_frame)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd,
125 const struct v4l2_rect *compose);
126 int (*config_subfrm)(struct mdp_comp_ctx *ctx,
127 struct mmsys_cmdq_cmd *cmd, u32 index);
128 int (*wait_comp_event)(struct mdp_comp_ctx *ctx,
129 struct mmsys_cmdq_cmd *cmd);
130 int (*advance_subfrm)(struct mdp_comp_ctx *ctx,
131 struct mmsys_cmdq_cmd *cmd, u32 index);
132 int (*post_process)(struct mdp_comp_ctx *ctx, struct mmsys_cmdq_cmd *cmd);
133 };
134
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [helgaas-pci:pci/vga2] BUILD SUCCESS 91ca1c7c1e057c0bddffe043c0e74ae9f9ec756e
From: kernel test robot @ 2022-01-05 18:21 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/vga2
branch HEAD: 91ca1c7c1e057c0bddffe043c0e74ae9f9ec756e vgaarb: Use disabled device as last resort
elapsed time: 724m
configs tested: 141
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20220105
mips db1xxx_defconfig
sh apsh4a3a_defconfig
sh microdev_defconfig
arc hsdk_defconfig
powerpc mpc834x_mds_defconfig
arm xcep_defconfig
ia64 zx1_defconfig
sh se7705_defconfig
sh kfr2r09-romimage_defconfig
sh migor_defconfig
xtensa cadence_csp_defconfig
mips rt305x_defconfig
sh defconfig
arc vdk_hs38_defconfig
mips allyesconfig
sh edosk7760_defconfig
arm pleb_defconfig
xtensa alldefconfig
microblaze mmu_defconfig
sh sh7785lcr_32bit_defconfig
arm zeus_defconfig
ia64 defconfig
arm sunxi_defconfig
powerpc tqm8xx_defconfig
powerpc linkstation_defconfig
arm stm32_defconfig
powerpc warp_defconfig
arm lpd270_defconfig
m68k m5475evb_defconfig
m68k apollo_defconfig
m68k allmodconfig
arm rpc_defconfig
sh apsh4ad0a_defconfig
arm shmobile_defconfig
mips fuloong2e_defconfig
arm u8500_defconfig
h8300 defconfig
powerpc allnoconfig
powerpc klondike_defconfig
arm realview_defconfig
powerpc sequoia_defconfig
powerpc makalu_defconfig
arm spear6xx_defconfig
powerpc ppc64_defconfig
powerpc iss476-smp_defconfig
i386 alldefconfig
nds32 defconfig
mips maltasmvp_eva_defconfig
powerpc mpc85xx_cds_defconfig
h8300 allyesconfig
sh sh7770_generic_defconfig
powerpc tqm8555_defconfig
sh shmin_defconfig
arm randconfig-c002-20220105
ia64 allmodconfig
ia64 allyesconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allmodconfig
s390 defconfig
s390 allyesconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a005-20220105
x86_64 randconfig-a001-20220105
x86_64 randconfig-a004-20220105
x86_64 randconfig-a006-20220105
x86_64 randconfig-a003-20220105
x86_64 randconfig-a002-20220105
i386 randconfig-a003-20220105
i386 randconfig-a005-20220105
i386 randconfig-a004-20220105
i386 randconfig-a006-20220105
i386 randconfig-a002-20220105
i386 randconfig-a001-20220105
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
powerpc mpc885_ads_defconfig
arm multi_v5_defconfig
riscv rv32_defconfig
powerpc mpc8313_rdb_defconfig
powerpc akebono_defconfig
arm hackkit_defconfig
arm alldefconfig
powerpc lite5200b_defconfig
arm dove_defconfig
mips qi_lb60_defconfig
arm spitz_defconfig
arm s3c2410_defconfig
x86_64 randconfig-a012-20220105
x86_64 randconfig-a015-20220105
x86_64 randconfig-a014-20220105
x86_64 randconfig-a013-20220105
x86_64 randconfig-a011-20220105
x86_64 randconfig-a016-20220105
i386 randconfig-a012-20220105
i386 randconfig-a016-20220105
i386 randconfig-a015-20220105
i386 randconfig-a014-20220105
i386 randconfig-a011-20220105
i386 randconfig-a013-20220105
hexagon randconfig-r041-20220105
hexagon randconfig-r045-20220105
riscv randconfig-r042-20220105
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.