* [PATCH] [media] v4l2-core: fix use-after-free error
From: Sumit Gupta @ 2019-04-10 14:28 UTC (permalink / raw)
To: mchehab, hverkuil-cisco, sakari.ailus, paul.kocialkowski, tfiga,
keiichiw, sumitg
Cc: linux-media, linux-kernel
From: sumitg <sumitg@nvidia.com>
Fixing use-after-free within __v4l2_ctrl_handler_setup().
Memory is being freed with kfree(new_ref) for duplicate
control reference entry but cluster is still referring
to the duplicate entry. Change done to point cluster to
original reference instead of duplicate which is freed.
==================================================================
BUG: KASAN: use-after-free in __v4l2_ctrl_handler_setup+0x388/0x428
Read of size 8 at addr ffffffc324e78618 by task systemd-udevd/312
Allocated by task 312:
Freed by task 312:
The buggy address belongs to the object at ffffffc324e78600
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 24 bytes inside of
64-byte region [ffffffc324e78600, ffffffc324e78640)
The buggy address belongs to the page:
page:ffffffbf0c939e00 count:1 mapcount:0 mapping:
(null) index:0xffffffc324e78f80
flags: 0x4000000000000100(slab)
raw: 4000000000000100 0000000000000000 ffffffc324e78f80 000000018020001a
raw: 0000000000000000 0000000100000001 ffffffc37040fb80 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffc324e78500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffffffc324e78580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffffffc324e78600: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffffffc324e78680: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffffffc324e78700: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Signed-off-by: sumitg <sumitg@nvidia.com>
---
drivers/media/v4l2-core/v4l2-ctrls.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index 5e3806f..e971bab 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2182,6 +2182,7 @@ static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
continue;
/* Don't add duplicates */
if (ref->ctrl->id == id) {
+ ctrl->cluster = &ref->ctrl;
kfree(new_ref);
goto unlock;
}
--
2.7.4
^ permalink raw reply related
* [Xen-devel] [OSSTEST PATCH 62/62] Switch to Debian Stretch
From: Ian Jackson @ 2019-04-10 14:24 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson, Wei Liu
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
Osstest.pm | 2 +-
production-config | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index 92b1a0ea..7ce53fcb 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -87,7 +87,7 @@ our %c = qw(
Images images
- DebianSuite jessie
+ DebianSuite stretch
DebianMirrorSubpath debian
TestHostKeypairPath id_rsa_osstest
diff --git a/production-config b/production-config
index fadfe8b9..5b9f5c82 100644
--- a/production-config
+++ b/production-config
@@ -90,12 +90,14 @@ TftpNetbootGroup osstest
# Update with ./mg-debian-installer-update(-all)
TftpDiVersion_wheezy 2016-06-08
TftpDiVersion_jessie 2018-06-26
+TftpDiVersion_stretch 2018-11-27
DebianSnapshotBackports_jessie http://snapshot.debian.org/archive/debian/20190206T211314Z/
# For ISO installs
DebianImageVersion_wheezy 7.2.0
DebianImageVersion_jessie 8.2.0
+DebianImageVersion_stretch 9.4.0
# These should normally be the same.
# Update with ./mg-cpu-microcode-update
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [OSSTEST PATCH 28/62] ts-host-install: Unconditionally mkdir -p /etc/udev/rules.d
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
We are going to want this directory to exist so that we can put a
canary in 70-persistent-net.rules.
In the cases where the behaviour of osstest changes, the empty
directory does not result in any overall change.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
ts-host-install | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ts-host-install b/ts-host-install
index f80a151c..7423eb9b 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -198,6 +198,8 @@ sub setup_netboot_firstboot($) {
my $persistent_net_rules =
"$initrd_overlay.d/etc/udev/rules.d/70-persistent-net.rules";
+ system_checked(qw(mkdir -p --), "$initrd_overlay.d/etc/udev/rules.d");
+
my $ipappend = 2;
my $wantphysif= get_host_property($ho,'interface force','auto');
logm("Forcing interface $wantphysif");
@@ -205,7 +207,6 @@ sub setup_netboot_firstboot($) {
$ipappend = 0;
die "need Ether for $ho->{Name} ($wantphysif)"
unless defined $ho->{Ether};
- system_checked(qw(mkdir -p --), "$initrd_overlay.d/etc/udev/rules.d");
# ip(8) moved to /sbin in Jessie
my $ipcmd = $ho->{Suite} =~ m/wheezy/ ? "/bin/ip" : "/sbin/ip";
file_simple_write_contents
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [Xen-devel] [OSSTEST PATCH 28/62] ts-host-install: Unconditionally mkdir -p /etc/udev/rules.d
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
We are going to want this directory to exist so that we can put a
canary in 70-persistent-net.rules.
In the cases where the behaviour of osstest changes, the empty
directory does not result in any overall change.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
ts-host-install | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ts-host-install b/ts-host-install
index f80a151c..7423eb9b 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -198,6 +198,8 @@ sub setup_netboot_firstboot($) {
my $persistent_net_rules =
"$initrd_overlay.d/etc/udev/rules.d/70-persistent-net.rules";
+ system_checked(qw(mkdir -p --), "$initrd_overlay.d/etc/udev/rules.d");
+
my $ipappend = 2;
my $wantphysif= get_host_property($ho,'interface force','auto');
logm("Forcing interface $wantphysif");
@@ -205,7 +207,6 @@ sub setup_netboot_firstboot($) {
$ipappend = 0;
die "need Ether for $ho->{Name} ($wantphysif)"
unless defined $ho->{Ether};
- system_checked(qw(mkdir -p --), "$initrd_overlay.d/etc/udev/rules.d");
# ip(8) moved to /sbin in Jessie
my $ipcmd = $ho->{Suite} =~ m/wheezy/ ? "/bin/ip" : "/sbin/ip";
file_simple_write_contents
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [OSSTEST PATCH 14/62] adjust how to skip bootloader installation for arm32, in Stretch
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v4: Change case of suite names in comment.
---
Osstest/Debian.pm | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 91bffdff..85b1890d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1041,7 +1041,11 @@ END
# actually does what we need, but the installer doesn't treat
# that as a "bootloader".
$preseed_file.= (<<END);
+ # jessie and earlier
d-i nobootloader/confirmation_common boolean true
+ # stretch and later
+d-i grub-installer/skip boolean true
+d-i lilo-installer/skip boolean true
END
# Debian Bug #771949 means that update-menu-list always
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [Xen-devel] [OSSTEST PATCH 14/62] adjust how to skip bootloader installation for arm32, in Stretch
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v4: Change case of suite names in comment.
---
Osstest/Debian.pm | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 91bffdff..85b1890d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1041,7 +1041,11 @@ END
# actually does what we need, but the installer doesn't treat
# that as a "bootloader".
$preseed_file.= (<<END);
+ # jessie and earlier
d-i nobootloader/confirmation_common boolean true
+ # stretch and later
+d-i grub-installer/skip boolean true
+d-i lilo-installer/skip boolean true
END
# Debian Bug #771949 means that update-menu-list always
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [OSSTEST PATCH 31/62] persistent-net: Set net.ifnames=0 in di_installcmdline_core
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu, Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Osstest/Debian.pm | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 6309b246..aff5acd5 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -81,6 +81,11 @@ sub debian_boot_setup ($$$$$;$) {
$kopt .= ' '.$targkopt;
}
+ # https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
+ # In fact these are anything but predictable. We use the scheme
+ # from Debian jessie and earlier, persistent-net-generator etc.
+ $kopt .= ' net.ifnames=0';
+
foreach my $hook ($hooks ? @$hooks : ()) {
my $bo_hook= $hook->{EditBootOptions};
$bo_hook->($ho, \$xenhopt, \$kopt) if $bo_hook;
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH for-4.1] q35: acpi: do not create dummy MCFG table
From: Wei Yang @ 2019-04-10 14:27 UTC (permalink / raw)
To: Igor Mammedov; +Cc: ehabkost, richardw.yang, qemu-devel, mst
In-Reply-To: <1554822037-329838-1-git-send-email-imammedo@redhat.com>
On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
>Dummy table (with signature "QEMU") creation came from original SeaBIOS
>codebase. And QEMU would have to keep it around if there were Q35 machine
>that depended on keeping ACPI tables blob constant size. Luckily there
>were no versioned Q35 machine types before commit:
> (since 2.3) a1666142db acpi-build: make ROMs RAM blocks resizeable
>which obsoleted need to keep ACPI tables blob the same size on source/destination.
I think we should keep table blob the same size on source/destination.
But with resizable MemoryRegion, we don't need to reserve some dummy space.
Because we can expand it later.
>
>Considering the 1st versioned machine is pc-q35-2.4, the dummy table
>is not really necessary and it's safe to drop it without breaking
>cross version migration in both directions unconditionally.
>
>Signed-off-by: Igor Mammedov <imammedo@redhat.com>
>---
> hw/i386/acpi-build.c | 18 ++++--------------
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
>diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>index 416da31..8671e25 100644
>--- a/hw/i386/acpi-build.c
>+++ b/hw/i386/acpi-build.c
>@@ -2401,7 +2401,6 @@ static void
> build_mcfg_q35(GArray *table_data, BIOSLinker *linker, AcpiMcfgInfo *info)
> {
> AcpiTableMcfg *mcfg;
>- const char *sig;
> int len = sizeof(*mcfg) + 1 * sizeof(mcfg->allocation[0]);
>
> mcfg = acpi_data_push(table_data, len);
>@@ -2411,19 +2410,7 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, AcpiMcfgInfo *info)
> mcfg->allocation[0].start_bus_number = 0;
> mcfg->allocation[0].end_bus_number = PCIE_MMCFG_BUS(info->mcfg_size - 1);
>
>- /* MCFG is used for ECAM which can be enabled or disabled by guest.
I want to cnfirm what is "enabled or disabled by guest" here.
If we don't reserve mcfg and "guest" enable mcfg during running, the ACPI
table size changed. But the destination still has the original table size,
since destination "guest" keep sleep during this period.
Now the migration would face table size difference and break migration?
>- * To avoid table size changes (which create migration issues),
>- * always create the table even if there are no allocations,
>- * but set the signature to a reserved value in this case.
>- * ACPI spec requires OSPMs to ignore such tables.
>- */
>- if (info->mcfg_base == PCIE_BASE_ADDR_UNMAPPED) {
>- /* Reserved signature: ignored by OSPM */
>- sig = "QEMU";
>- } else {
>- sig = "MCFG";
>- }
>- build_header(linker, table_data, (void *)mcfg, sig, len, 1, NULL, NULL);
>+ build_header(linker, table_data, (void *)mcfg, "MCFG", len, 1, NULL, NULL);
> }
>
> /*
>@@ -2592,6 +2579,9 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
> }
> mcfg->mcfg_base = qnum_get_uint(qobject_to(QNum, o));
> qobject_unref(o);
>+ if (mcfg->mcfg_base == PCIE_BASE_ADDR_UNMAPPED) {
>+ return false;
>+ }
>
> o = object_property_get_qobject(pci_host, PCIE_HOST_MCFG_SIZE, NULL);
> assert(o);
>--
>2.7.4
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: Boris Brezillon @ 2019-04-10 14:29 UTC (permalink / raw)
To: YueHaibing
Cc: miquel.raynal, richard, computersforpeace, marek.vasut,
paul.burton, bbrezillon, linux-kernel, linux-mtd
In-Reply-To: <8b020124-4008-6081-c04c-eaefb7875878@huawei.com>
On Wed, 10 Apr 2019 22:22:16 +0800
YueHaibing <yuehaibing@huawei.com> wrote:
> On 2019/4/10 21:58, Boris Brezillon wrote:
> > On Wed, 10 Apr 2019 15:39:28 +0200
> > Boris Brezillon <boris.brezillon@collabora.com> wrote:
> >
> >> On Wed, 10 Apr 2019 21:07:47 +0800
> >> Yue Haibing <yuehaibing@huawei.com> wrote:
> >>
> >>> From: YueHaibing <yuehaibing@huawei.com>
> >>>
> >>> Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> >>> is set to module:
> >>>
> >>> drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> >>> (.text+0xef6): undefined reference to `nand_bch_free'
> >>> drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> >>> nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
> >>> nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> >>> nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> >>>
> >>> CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> >>> because MTD_RAW_NAND need it while linked.
> >>>
> >>> Reported-by: Hulk Robot <hulkci@huawei.com>
> >>> Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
> >>
> >> Nope, it's not this one that introduced the regression.
> >>
> >>
> >>
> >>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> >>> ---
> >>> drivers/mtd/nand/raw/Kconfig | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> >>> index 615d738..0500c42 100644
> >>> --- a/drivers/mtd/nand/raw/Kconfig
> >>> +++ b/drivers/mtd/nand/raw/Kconfig
> >>> @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> >>> if MTD_RAW_NAND
> >>>
> >>> config MTD_NAND_ECC_SW_BCH
> >>> - tristate "Support software BCH ECC"
> >>> + bool "Support software BCH ECC"
> >>> select BCH
> >>> default n
> >>> help
> >>
> >> Should be fixed with the following diff squashed into:
> >>
> >> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
> >>
> >> --->8---
> >> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> >> index b8106651f807..06ce2b655c13 100644
> >> --- a/include/linux/mtd/nand_bch.h
> >> +++ b/include/linux/mtd/nand_bch.h
> >> @@ -15,7 +15,7 @@ struct mtd_info;
> >> struct nand_chip;
> >> struct nand_bch_control;
> >>
> >> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> >> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
> >>
> >> static inline int mtd_nand_has_bch(void) { return 1; }
> >>
> >> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
> >> */
> >> void nand_bch_free(struct nand_bch_control *nbc);
> >>
> >> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> >> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
> >>
> >> static inline int mtd_nand_has_bch(void) { return 0; }
> >>
> >> @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> >>
> >> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
> >>
> >> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> >> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
> >>
> >> #endif /* __MTD_NAND_BCH_H__ */
> >
> > Sorry, I didn't look at the right branch, this part of the code was
> > correct, but we still have a problem to express the RAW_NAND(y) ->
> > SW_BCH(y) dependency.
>
> It seems this dependency is not always need,
>
> case MTD_RAW_NAND set to y works well while CONFIG_MTD_NAND_ECC_SW_BCH is not set.
Yes, I know, but forcing nand_bch to a be a boolean is not the right
solution either, hence my suggestion to use 'imply'.
^ permalink raw reply
* ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/icl: Handle rps interrupts without irq lock
From: Patchwork @ 2019-04-10 14:29 UTC (permalink / raw)
To: Mika Kuoppala; +Cc: intel-gfx
In-Reply-To: <20190410132124.21795-1-mika.kuoppala@linux.intel.com>
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/icl: Handle rps interrupts without irq lock
URL : https://patchwork.freedesktop.org/series/59288/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5899 -> Patchwork_12753
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/59288/revisions/1/mbox/
Known issues
------------
Here are the changes found in Patchwork_12753 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_create@basic-files:
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106
* igt@gem_exec_basic@readonly-bsd1:
- fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] +57
* igt@gem_exec_basic@readonly-bsd2:
- fi-pnv-d510: NOTRUN -> SKIP [fdo#109271] +76
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-c:
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_force_connector_basic@force-edid:
- fi-glk-dsi: NOTRUN -> SKIP [fdo#109271] +26
* igt@kms_frontbuffer_tracking@basic:
- fi-glk-dsi: NOTRUN -> FAIL [fdo#103167]
#### Possible fixes ####
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: INCOMPLETE [fdo#108602] / [fdo#108744] -> PASS
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] -> PASS
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (48 -> 44)
------------------------------
Additional (3): fi-gdg-551 fi-snb-2520m fi-pnv-d510
Missing (7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-dsi fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_5899 -> Patchwork_12753
CI_DRM_5899: dc1c6a83767fa712be1d32b06047f2f2087b9ff1 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4939: 64d0ff7247497ae6d726e4535fe74d4bb6ae914a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12753: 4a8a319db124f9329bc62f981e9006dba79e5623 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4a8a319db124 drm/i915/icl: Don't warn on spurious interrupts
e74ab3267e47 drm/i915/icl: Handle rps interrupts without irq lock
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12753/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v4 3/4] ASoC: imx-audmix: fix object reference leaks in probe
From: Fabio Estevam @ 2019-04-10 14:26 UTC (permalink / raw)
To: Viorel Suman
Cc: Mark Rutland, Viorel Suman, alsa-devel@alsa-project.org,
linuxppc-dev@lists.ozlabs.org, Timur Tabi, Xiubo Li,
linux-kernel@vger.kernel.org, Sascha Hauer, Takashi Iwai,
Liam Girdwood, Rob Herring, Jaroslav Kysela, Nicolin Chen,
Julia Lawall, devicetree@vger.kernel.org, Mark Brown,
dl-linux-imx, Pengutronix Kernel Team, Shawn Guo,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1554894380-25153-4-git-send-email-viorel.suman@nxp.com>
On Wed, Apr 10, 2019 at 8:06 AM Viorel Suman <viorel.suman@nxp.com> wrote:
>
> Release the reference to the underlying device taken
> by of_find_device_by_node() call.
>
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> Reported-by: Julia Lawall <Julia.Lawall@lip6.fr>
> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Please provide a Fixes tag.
^ permalink raw reply
* Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: Boris Brezillon @ 2019-04-10 14:29 UTC (permalink / raw)
To: YueHaibing
Cc: bbrezillon, richard, linux-kernel, marek.vasut, paul.burton,
linux-mtd, miquel.raynal, computersforpeace
In-Reply-To: <8b020124-4008-6081-c04c-eaefb7875878@huawei.com>
On Wed, 10 Apr 2019 22:22:16 +0800
YueHaibing <yuehaibing@huawei.com> wrote:
> On 2019/4/10 21:58, Boris Brezillon wrote:
> > On Wed, 10 Apr 2019 15:39:28 +0200
> > Boris Brezillon <boris.brezillon@collabora.com> wrote:
> >
> >> On Wed, 10 Apr 2019 21:07:47 +0800
> >> Yue Haibing <yuehaibing@huawei.com> wrote:
> >>
> >>> From: YueHaibing <yuehaibing@huawei.com>
> >>>
> >>> Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> >>> is set to module:
> >>>
> >>> drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> >>> (.text+0xef6): undefined reference to `nand_bch_free'
> >>> drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> >>> nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
> >>> nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> >>> nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> >>>
> >>> CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> >>> because MTD_RAW_NAND need it while linked.
> >>>
> >>> Reported-by: Hulk Robot <hulkci@huawei.com>
> >>> Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
> >>
> >> Nope, it's not this one that introduced the regression.
> >>
> >>
> >>
> >>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> >>> ---
> >>> drivers/mtd/nand/raw/Kconfig | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> >>> index 615d738..0500c42 100644
> >>> --- a/drivers/mtd/nand/raw/Kconfig
> >>> +++ b/drivers/mtd/nand/raw/Kconfig
> >>> @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> >>> if MTD_RAW_NAND
> >>>
> >>> config MTD_NAND_ECC_SW_BCH
> >>> - tristate "Support software BCH ECC"
> >>> + bool "Support software BCH ECC"
> >>> select BCH
> >>> default n
> >>> help
> >>
> >> Should be fixed with the following diff squashed into:
> >>
> >> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
> >>
> >> --->8---
> >> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> >> index b8106651f807..06ce2b655c13 100644
> >> --- a/include/linux/mtd/nand_bch.h
> >> +++ b/include/linux/mtd/nand_bch.h
> >> @@ -15,7 +15,7 @@ struct mtd_info;
> >> struct nand_chip;
> >> struct nand_bch_control;
> >>
> >> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> >> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
> >>
> >> static inline int mtd_nand_has_bch(void) { return 1; }
> >>
> >> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
> >> */
> >> void nand_bch_free(struct nand_bch_control *nbc);
> >>
> >> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> >> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
> >>
> >> static inline int mtd_nand_has_bch(void) { return 0; }
> >>
> >> @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> >>
> >> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
> >>
> >> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> >> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
> >>
> >> #endif /* __MTD_NAND_BCH_H__ */
> >
> > Sorry, I didn't look at the right branch, this part of the code was
> > correct, but we still have a problem to express the RAW_NAND(y) ->
> > SW_BCH(y) dependency.
>
> It seems this dependency is not always need,
>
> case MTD_RAW_NAND set to y works well while CONFIG_MTD_NAND_ECC_SW_BCH is not set.
Yes, I know, but forcing nand_bch to a be a boolean is not the right
solution either, hence my suggestion to use 'imply'.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [Xen-devel] [OSSTEST PATCH 31/62] persistent-net: Set net.ifnames=0 in di_installcmdline_core
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu, Ian Jackson
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Osstest/Debian.pm | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 6309b246..aff5acd5 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -81,6 +81,11 @@ sub debian_boot_setup ($$$$$;$) {
$kopt .= ' '.$targkopt;
}
+ # https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
+ # In fact these are anything but predictable. We use the scheme
+ # from Debian jessie and earlier, persistent-net-generator etc.
+ $kopt .= ' net.ifnames=0';
+
foreach my $hook ($hooks ? @$hooks : ()) {
my $bo_hook= $hook->{EditBootOptions};
$bo_hook->($ho, \$xenhopt, \$kopt) if $bo_hook;
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH] ASoC: pcm: fix error handling when try_module_get() fails.
From: Ranjani Sridharan @ 2019-04-10 14:30 UTC (permalink / raw)
To: Mark Brown; +Cc: tiwai, alsa-devel, pierre-louis.bossart
In-Reply-To: <20190410095010.GD6106@sirena.org.uk>
On Wed, 2019-04-10 at 10:50 +0100, Mark Brown wrote:
> On Mon, Apr 08, 2019 at 12:30:25PM -0700, Ranjani Sridharan wrote:
> > Handle error before returning when try_module_get() fails
> > to prevent inconsistent mutex lock/unlock.
> >
> > Fixes: 52034add7 (ASoC: pcm: update module refcount if
> > module_get_upon_open is set)
> >
> > Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com
> > >
>
> You keep on adding blank lines after your Fixes: lines for some
> reason,
> this is unusual and will probably confuse some tooling.
Sorry about that. Will send v2 without the line.
Thanks,
Ranjani
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* [OSSTEST PATCH 04/62] ts-xen-build-prep: install packages for suites >jessie
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
The stubdom build needs texinfo.
The libvirt build needs autopoint.
The QEMU build needs libpciaccess-dev.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
ts-xen-build-prep | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index a15ab3df..ca5735a1 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -222,6 +222,10 @@ sub prep () {
# jessie (>jessie?)
push(@packages, "libnl-route-3-dev");
}
+ if ($ho->{Suite} !~ m/squeeze|wheezy|jessie/) {
+ push(@packages, qw(texinfo autopoint libpciaccess-dev));
+ }
+
target_install_packages($ho, @packages);
target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
# workaround for Debian #595728
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [Xen-devel] [OSSTEST PATCH 04/62] ts-xen-build-prep: install packages for suites >jessie
From: Ian Jackson @ 2019-04-10 14:23 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu
In-Reply-To: <20190410142408.22848-1-ian.jackson@eu.citrix.com>
From: Wei Liu <wei.liu2@citrix.com>
The stubdom build needs texinfo.
The libvirt build needs autopoint.
The QEMU build needs libpciaccess-dev.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
ts-xen-build-prep | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index a15ab3df..ca5735a1 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -222,6 +222,10 @@ sub prep () {
# jessie (>jessie?)
push(@packages, "libnl-route-3-dev");
}
+ if ($ho->{Suite} !~ m/squeeze|wheezy|jessie/) {
+ push(@packages, qw(texinfo autopoint libpciaccess-dev));
+ }
+
target_install_packages($ho, @packages);
target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
# workaround for Debian #595728
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [PATCH 1/3] bpf: Use spinlock_t in bpf_lru_list
From: Sebastian Andrzej Siewior @ 2019-04-10 14:30 UTC (permalink / raw)
To: bpf
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, tglx, Steven Rostedt, Sebastian Andrzej Siewior
There is no difference between spinlock_t and raw_spinlock_t for !RT
kernels. It is possible that bpf_lru_list_pop_free_to_local() invokes
at least three list walks which look unbounded it probably makes sense
to use spinlock_t.
Make bpf_lru_list use a spinlock_t.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
kernel/bpf/bpf_lru_list.c | 38 +++++++++++++++++++-------------------
kernel/bpf/bpf_lru_list.h | 4 ++--
2 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/kernel/bpf/bpf_lru_list.c b/kernel/bpf/bpf_lru_list.c
index e6ef4401a1380..40f47210c3817 100644
--- a/kernel/bpf/bpf_lru_list.c
+++ b/kernel/bpf/bpf_lru_list.c
@@ -313,9 +313,9 @@ static void bpf_lru_list_push_free(struct bpf_lru_list *l,
if (WARN_ON_ONCE(IS_LOCAL_LIST_TYPE(node->type)))
return;
- raw_spin_lock_irqsave(&l->lock, flags);
+ spin_lock_irqsave(&l->lock, flags);
__bpf_lru_node_move(l, node, BPF_LRU_LIST_T_FREE);
- raw_spin_unlock_irqrestore(&l->lock, flags);
+ spin_unlock_irqrestore(&l->lock, flags);
}
static void bpf_lru_list_pop_free_to_local(struct bpf_lru *lru,
@@ -325,7 +325,7 @@ static void bpf_lru_list_pop_free_to_local(struct bpf_lru *lru,
struct bpf_lru_node *node, *tmp_node;
unsigned int nfree = 0;
- raw_spin_lock(&l->lock);
+ spin_lock(&l->lock);
__local_list_flush(l, loc_l);
@@ -344,7 +344,7 @@ static void bpf_lru_list_pop_free_to_local(struct bpf_lru *lru,
local_free_list(loc_l),
BPF_LRU_LOCAL_LIST_T_FREE);
- raw_spin_unlock(&l->lock);
+ spin_unlock(&l->lock);
}
static void __local_list_add_pending(struct bpf_lru *lru,
@@ -410,7 +410,7 @@ static struct bpf_lru_node *bpf_percpu_lru_pop_free(struct bpf_lru *lru,
l = per_cpu_ptr(lru->percpu_lru, cpu);
- raw_spin_lock_irqsave(&l->lock, flags);
+ spin_lock_irqsave(&l->lock, flags);
__bpf_lru_list_rotate(lru, l);
@@ -426,7 +426,7 @@ static struct bpf_lru_node *bpf_percpu_lru_pop_free(struct bpf_lru *lru,
__bpf_lru_node_move(l, node, BPF_LRU_LIST_T_INACTIVE);
}
- raw_spin_unlock_irqrestore(&l->lock, flags);
+ spin_unlock_irqrestore(&l->lock, flags);
return node;
}
@@ -443,7 +443,7 @@ static struct bpf_lru_node *bpf_common_lru_pop_free(struct bpf_lru *lru,
loc_l = per_cpu_ptr(clru->local_list, cpu);
- raw_spin_lock_irqsave(&loc_l->lock, flags);
+ spin_lock_irqsave(&loc_l->lock, flags);
node = __local_list_pop_free(loc_l);
if (!node) {
@@ -454,7 +454,7 @@ static struct bpf_lru_node *bpf_common_lru_pop_free(struct bpf_lru *lru,
if (node)
__local_list_add_pending(lru, loc_l, cpu, node, hash);
- raw_spin_unlock_irqrestore(&loc_l->lock, flags);
+ spin_unlock_irqrestore(&loc_l->lock, flags);
if (node)
return node;
@@ -472,13 +472,13 @@ static struct bpf_lru_node *bpf_common_lru_pop_free(struct bpf_lru *lru,
do {
steal_loc_l = per_cpu_ptr(clru->local_list, steal);
- raw_spin_lock_irqsave(&steal_loc_l->lock, flags);
+ spin_lock_irqsave(&steal_loc_l->lock, flags);
node = __local_list_pop_free(steal_loc_l);
if (!node)
node = __local_list_pop_pending(lru, steal_loc_l);
- raw_spin_unlock_irqrestore(&steal_loc_l->lock, flags);
+ spin_unlock_irqrestore(&steal_loc_l->lock, flags);
steal = get_next_cpu(steal);
} while (!node && steal != first_steal);
@@ -486,9 +486,9 @@ static struct bpf_lru_node *bpf_common_lru_pop_free(struct bpf_lru *lru,
loc_l->next_steal = steal;
if (node) {
- raw_spin_lock_irqsave(&loc_l->lock, flags);
+ spin_lock_irqsave(&loc_l->lock, flags);
__local_list_add_pending(lru, loc_l, cpu, node, hash);
- raw_spin_unlock_irqrestore(&loc_l->lock, flags);
+ spin_unlock_irqrestore(&loc_l->lock, flags);
}
return node;
@@ -516,10 +516,10 @@ static void bpf_common_lru_push_free(struct bpf_lru *lru,
loc_l = per_cpu_ptr(lru->common_lru.local_list, node->cpu);
- raw_spin_lock_irqsave(&loc_l->lock, flags);
+ spin_lock_irqsave(&loc_l->lock, flags);
if (unlikely(node->type != BPF_LRU_LOCAL_LIST_T_PENDING)) {
- raw_spin_unlock_irqrestore(&loc_l->lock, flags);
+ spin_unlock_irqrestore(&loc_l->lock, flags);
goto check_lru_list;
}
@@ -527,7 +527,7 @@ static void bpf_common_lru_push_free(struct bpf_lru *lru,
node->ref = 0;
list_move(&node->list, local_free_list(loc_l));
- raw_spin_unlock_irqrestore(&loc_l->lock, flags);
+ spin_unlock_irqrestore(&loc_l->lock, flags);
return;
}
@@ -543,11 +543,11 @@ static void bpf_percpu_lru_push_free(struct bpf_lru *lru,
l = per_cpu_ptr(lru->percpu_lru, node->cpu);
- raw_spin_lock_irqsave(&l->lock, flags);
+ spin_lock_irqsave(&l->lock, flags);
__bpf_lru_node_move(l, node, BPF_LRU_LIST_T_FREE);
- raw_spin_unlock_irqrestore(&l->lock, flags);
+ spin_unlock_irqrestore(&l->lock, flags);
}
void bpf_lru_push_free(struct bpf_lru *lru, struct bpf_lru_node *node)
@@ -627,7 +627,7 @@ static void bpf_lru_locallist_init(struct bpf_lru_locallist *loc_l, int cpu)
loc_l->next_steal = cpu;
- raw_spin_lock_init(&loc_l->lock);
+ spin_lock_init(&loc_l->lock);
}
static void bpf_lru_list_init(struct bpf_lru_list *l)
@@ -642,7 +642,7 @@ static void bpf_lru_list_init(struct bpf_lru_list *l)
l->next_inactive_rotation = &l->lists[BPF_LRU_LIST_T_INACTIVE];
- raw_spin_lock_init(&l->lock);
+ spin_lock_init(&l->lock);
}
int bpf_lru_init(struct bpf_lru *lru, bool percpu, u32 hash_offset,
diff --git a/kernel/bpf/bpf_lru_list.h b/kernel/bpf/bpf_lru_list.h
index 7d4f89b7cb841..4e1e4608f1bb0 100644
--- a/kernel/bpf/bpf_lru_list.h
+++ b/kernel/bpf/bpf_lru_list.h
@@ -36,13 +36,13 @@ struct bpf_lru_list {
/* The next inacitve list rotation starts from here */
struct list_head *next_inactive_rotation;
- raw_spinlock_t lock ____cacheline_aligned_in_smp;
+ spinlock_t lock ____cacheline_aligned_in_smp;
};
struct bpf_lru_locallist {
struct list_head lists[NR_BPF_LRU_LOCAL_LIST_T];
u16 next_steal;
- raw_spinlock_t lock;
+ spinlock_t lock;
};
struct bpf_common_lru {
--
2.20.1
^ permalink raw reply related
* [PATCH 2/3] bpf: Use spinlock_t in hashtab
From: Sebastian Andrzej Siewior @ 2019-04-10 14:30 UTC (permalink / raw)
To: bpf
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, tglx, Steven Rostedt, Sebastian Andrzej Siewior
In-Reply-To: <20190410143025.11997-1-bigeasy@linutronix.de>
There is no difference between spinlock_t and raw_spinlock_t for !RT
kernels. htab_map_update_elem() may allocate memory while it is holding
the ->lock which is not possible on RT kernels.
Make the ->lock a spinlock_t.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
kernel/bpf/hashtab.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index f9274114c88d3..b4f903a5ef36e 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -27,7 +27,7 @@
struct bucket {
struct hlist_nulls_head head;
- raw_spinlock_t lock;
+ spinlock_t lock;
};
struct bpf_htab {
@@ -385,7 +385,7 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
for (i = 0; i < htab->n_buckets; i++) {
INIT_HLIST_NULLS_HEAD(&htab->buckets[i].head, i);
- raw_spin_lock_init(&htab->buckets[i].lock);
+ spin_lock_init(&htab->buckets[i].lock);
}
if (prealloc) {
@@ -580,7 +580,7 @@ static bool htab_lru_map_delete_node(void *arg, struct bpf_lru_node *node)
b = __select_bucket(htab, tgt_l->hash);
head = &b->head;
- raw_spin_lock_irqsave(&b->lock, flags);
+ spin_lock_irqsave(&b->lock, flags);
hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
if (l == tgt_l) {
@@ -588,7 +588,7 @@ static bool htab_lru_map_delete_node(void *arg, struct bpf_lru_node *node)
break;
}
- raw_spin_unlock_irqrestore(&b->lock, flags);
+ spin_unlock_irqrestore(&b->lock, flags);
return l == tgt_l;
}
@@ -842,7 +842,7 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value,
head = &b->head;
/* bpf_map_update_elem() can be called in_irq() */
- raw_spin_lock_irqsave(&b->lock, flags);
+ spin_lock_irqsave(&b->lock, flags);
l_old = lookup_elem_raw(head, hash, key, key_size);
@@ -869,7 +869,7 @@ static int htab_map_update_elem(struct bpf_map *map, void *key, void *value,
}
ret = 0;
err:
- raw_spin_unlock_irqrestore(&b->lock, flags);
+ spin_unlock_irqrestore(&b->lock, flags);
return ret;
}
@@ -908,7 +908,7 @@ static int htab_lru_map_update_elem(struct bpf_map *map, void *key, void *value,
memcpy(l_new->key + round_up(map->key_size, 8), value, map->value_size);
/* bpf_map_update_elem() can be called in_irq() */
- raw_spin_lock_irqsave(&b->lock, flags);
+ spin_lock_irqsave(&b->lock, flags);
l_old = lookup_elem_raw(head, hash, key, key_size);
@@ -927,7 +927,7 @@ static int htab_lru_map_update_elem(struct bpf_map *map, void *key, void *value,
ret = 0;
err:
- raw_spin_unlock_irqrestore(&b->lock, flags);
+ spin_unlock_irqrestore(&b->lock, flags);
if (ret)
bpf_lru_push_free(&htab->lru, &l_new->lru_node);
@@ -963,7 +963,7 @@ static int __htab_percpu_map_update_elem(struct bpf_map *map, void *key,
head = &b->head;
/* bpf_map_update_elem() can be called in_irq() */
- raw_spin_lock_irqsave(&b->lock, flags);
+ spin_lock_irqsave(&b->lock, flags);
l_old = lookup_elem_raw(head, hash, key, key_size);
@@ -986,7 +986,7 @@ static int __htab_percpu_map_update_elem(struct bpf_map *map, void *key,
}
ret = 0;
err:
- raw_spin_unlock_irqrestore(&b->lock, flags);
+ spin_unlock_irqrestore(&b->lock, flags);
return ret;
}
@@ -1027,7 +1027,7 @@ static int __htab_lru_percpu_map_update_elem(struct bpf_map *map, void *key,
}
/* bpf_map_update_elem() can be called in_irq() */
- raw_spin_lock_irqsave(&b->lock, flags);
+ spin_lock_irqsave(&b->lock, flags);
l_old = lookup_elem_raw(head, hash, key, key_size);
@@ -1049,7 +1049,7 @@ static int __htab_lru_percpu_map_update_elem(struct bpf_map *map, void *key,
}
ret = 0;
err:
- raw_spin_unlock_irqrestore(&b->lock, flags);
+ spin_unlock_irqrestore(&b->lock, flags);
if (l_new)
bpf_lru_push_free(&htab->lru, &l_new->lru_node);
return ret;
@@ -1087,7 +1087,7 @@ static int htab_map_delete_elem(struct bpf_map *map, void *key)
b = __select_bucket(htab, hash);
head = &b->head;
- raw_spin_lock_irqsave(&b->lock, flags);
+ spin_lock_irqsave(&b->lock, flags);
l = lookup_elem_raw(head, hash, key, key_size);
@@ -1097,7 +1097,7 @@ static int htab_map_delete_elem(struct bpf_map *map, void *key)
ret = 0;
}
- raw_spin_unlock_irqrestore(&b->lock, flags);
+ spin_unlock_irqrestore(&b->lock, flags);
return ret;
}
@@ -1119,7 +1119,7 @@ static int htab_lru_map_delete_elem(struct bpf_map *map, void *key)
b = __select_bucket(htab, hash);
head = &b->head;
- raw_spin_lock_irqsave(&b->lock, flags);
+ spin_lock_irqsave(&b->lock, flags);
l = lookup_elem_raw(head, hash, key, key_size);
@@ -1128,7 +1128,7 @@ static int htab_lru_map_delete_elem(struct bpf_map *map, void *key)
ret = 0;
}
- raw_spin_unlock_irqrestore(&b->lock, flags);
+ spin_unlock_irqrestore(&b->lock, flags);
if (l)
bpf_lru_push_free(&htab->lru, &l->lru_node);
return ret;
--
2.20.1
^ permalink raw reply related
* [PATCH 3/3] bpf: Use spinlock_t in lpm_trie
From: Sebastian Andrzej Siewior @ 2019-04-10 14:30 UTC (permalink / raw)
To: bpf
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, tglx, Steven Rostedt, Sebastian Andrzej Siewior
In-Reply-To: <20190410143025.11997-1-bigeasy@linutronix.de>
There is no difference between spinlock_t and raw_spinlock_t for !RT
kernels. trie_update_elem() will allocate memory while holding ->lock
which is not possible on RT kernels.
Make the ->lock a spinlock_t.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
kernel/bpf/lpm_trie.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
index 93a5cbbde421c..2ceb32452b594 100644
--- a/kernel/bpf/lpm_trie.c
+++ b/kernel/bpf/lpm_trie.c
@@ -37,7 +37,7 @@ struct lpm_trie {
size_t n_entries;
size_t max_prefixlen;
size_t data_size;
- raw_spinlock_t lock;
+ spinlock_t lock;
};
/* This trie implements a longest prefix match algorithm that can be used to
@@ -318,7 +318,7 @@ static int trie_update_elem(struct bpf_map *map,
if (key->prefixlen > trie->max_prefixlen)
return -EINVAL;
- raw_spin_lock_irqsave(&trie->lock, irq_flags);
+ spin_lock_irqsave(&trie->lock, irq_flags);
/* Allocate and fill a new node */
@@ -425,7 +425,7 @@ static int trie_update_elem(struct bpf_map *map,
kfree(im_node);
}
- raw_spin_unlock_irqrestore(&trie->lock, irq_flags);
+ spin_unlock_irqrestore(&trie->lock, irq_flags);
return ret;
}
@@ -445,7 +445,7 @@ static int trie_delete_elem(struct bpf_map *map, void *_key)
if (key->prefixlen > trie->max_prefixlen)
return -EINVAL;
- raw_spin_lock_irqsave(&trie->lock, irq_flags);
+ spin_lock_irqsave(&trie->lock, irq_flags);
/* Walk the tree looking for an exact key/length match and keeping
* track of the path we traverse. We will need to know the node
@@ -521,7 +521,7 @@ static int trie_delete_elem(struct bpf_map *map, void *_key)
kfree_rcu(node, rcu);
out:
- raw_spin_unlock_irqrestore(&trie->lock, irq_flags);
+ spin_unlock_irqrestore(&trie->lock, irq_flags);
return ret;
}
@@ -583,7 +583,7 @@ static struct bpf_map *trie_alloc(union bpf_attr *attr)
if (ret)
goto out_err;
- raw_spin_lock_init(&trie->lock);
+ spin_lock_init(&trie->lock);
return &trie->map;
out_err:
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] btrfs: Remove redundant inode argument from btrfs_add_ordered_sum
From: Johannes Thumshirn @ 2019-04-10 14:30 UTC (permalink / raw)
To: Nikolay Borisov; +Cc: linux-btrfs
In-Reply-To: <20190410131611.18149-1-nborisov@suse.com>
Looks good,
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
--
Johannes Thumshirn SUSE Labs Filesystems
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* [Bug 107325] Reported temperature of nvidia card with nouveau driver is wrong
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2019-04-10 14:31 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-107325-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
[-- Attachment #1.1: Type: text/plain, Size: 463 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=107325
--- Comment #6 from Karol Herbst <karolherbst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
this is a runtime suspend issue. While the GPU is suspended the temperature
reading fails, but we don't actually check for that, so we return the error
value (-1 & 0x1ff = 511).
I think I had a patch for that somewhere, let me see.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1252 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* Re: [PATCH V2] ASoC: fsl_esai: replace fall-through with break
From: Gustavo A. R. Silva @ 2019-04-10 14:31 UTC (permalink / raw)
To: S.j. Wang, timur@kernel.org, nicoleotsuka@gmail.com,
Xiubo.Lee@gmail.com, festevam@gmail.com, broonie@kernel.org,
alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <46e9b55edb223894392a90c7cdb6241a43cb9cff.1554864022.git.shengjiu.wang@nxp.com>
On 4/9/19 9:42 PM, S.j. Wang wrote:
> case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent of
> each other, so replace fall-through with break.
>
I think you should change the subject line to:
fix missing break in switch statement
...because you are fixing a bug, and it's important to put emphasis on
that in the subject line.
Also, notice that this bug has been out there for more than 5 years now,
so you should also tag this for stable.
Thanks
--
Gustavo
> Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> Changes in v2
> - fix the fixes tag.
>
> sound/soc/fsl/fsl_esai.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index c7410bbfd2af..bad0dfed6b68 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -251,7 +251,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
> break;
> case ESAI_HCKT_EXTAL:
> ecr |= ESAI_ECR_ETI;
> - /* fall through */
> + break;
> case ESAI_HCKR_EXTAL:
> ecr |= esai_priv->synchronous ? ESAI_ECR_ETI : ESAI_ECR_ERI;
> break;
>
^ permalink raw reply
* Re: [PATCH] ASoC: wcd9335: Fix missing regmap requirement
From: Srinivas Kandagatla @ 2019-04-10 14:31 UTC (permalink / raw)
To: Marc Gonzalez, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai
Cc: LKML, alsa-devel, Arnd Bergmann
In-Reply-To: <8c0b22e2-2c67-8d45-a57d-dfc54043fbc9@free.fr>
On 10/04/2019 15:23, Marc Gonzalez wrote:
> wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip'
>
> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
> ---
Thanks for Fix,
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> sound/soc/codecs/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index 419142111b6d..33778dc99108 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -1162,6 +1162,7 @@ config SND_SOC_WCD9335
> tristate "WCD9335 Codec"
> depends on SLIMBUS
> select REGMAP_SLIMBUS
> + select REGMAP_IRQ
> help
> The WCD9335 is a standalone Hi-Fi audio CODEC IC, supports
> Qualcomm Technologies, Inc. (QTI) multimedia solutions,
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v5 2/5] virtio-pmem: Add virtio pmem driver
From: Cornelia Huck @ 2019-04-10 14:31 UTC (permalink / raw)
To: Pankaj Gupta
Cc: Michael S. Tsirkin, jack, kvm, david, jasowang, david, qemu-devel,
virtualization, adilger kernel, zwisler, aarcange, dave jiang,
linux-nvdimm, vishal l verma, willy, hch, linux-acpi, jmoyer,
linux-ext4, lenb, kilobyte, riel, yuval shaia, stefanha, pbonzini,
dan j williams, lcapitulino, kwolf, nilal, tytso,
xiaoguangrong eric <xiaogu>
In-Reply-To: <127904196.20807948.1554904981681.JavaMail.zimbra@redhat.com>
On Wed, 10 Apr 2019 10:03:01 -0400 (EDT)
Pankaj Gupta <pagupta@redhat.com> wrote:
> >
> > On Wed, Apr 10, 2019 at 09:38:22AM +0530, Pankaj Gupta wrote:
> > > This patch adds virtio-pmem driver for KVM guest.
> > >
> > > Guest reads the persistent memory range information from
> > > Qemu over VIRTIO and registers it on nvdimm_bus. It also
> > > creates a nd_region object with the persistent memory
> > > range information so that existing 'nvdimm/pmem' driver
> > > can reserve this into system memory map. This way
> > > 'virtio-pmem' driver uses existing functionality of pmem
> > > driver to register persistent memory compatible for DAX
> > > capable filesystems.
> > >
> > > This also provides function to perform guest flush over
> > > VIRTIO from 'pmem' driver when userspace performs flush
> > > on DAX memory range.
> > >
> > > Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> > > diff --git a/include/uapi/linux/virtio_ids.h
> > > b/include/uapi/linux/virtio_ids.h
> > > index 6d5c3b2d4f4d..346389565ac1 100644
> > > --- a/include/uapi/linux/virtio_ids.h
> > > +++ b/include/uapi/linux/virtio_ids.h
> > > @@ -43,5 +43,6 @@
> > > #define VIRTIO_ID_INPUT 18 /* virtio input */
> > > #define VIRTIO_ID_VSOCK 19 /* virtio vsock transport */
> > > #define VIRTIO_ID_CRYPTO 20 /* virtio crypto */
> > > +#define VIRTIO_ID_PMEM 25 /* virtio pmem */
> > >
> > > #endif /* _LINUX_VIRTIO_IDS_H */
> >
> > Didn't Paolo point out someone is using 25 for audio?
>
>
> Sorry! I did not notice this.
>
> >
> > Please, reserve an ID with the Virtio TC before using it.
>
> I thought I requested[1] ID 25.
>
> [1] https://github.com/oasis-tcs/virtio-spec/issues/38
> [2] https://lists.oasis-open.org/archives/virtio-dev/201805/threads.html
>
> In that case I will send request for next available ID i.e 26?
Have the folks using this for audio sent a reservation request as well?
If not, I'd say the first requester should get the id...
(And yes, we need to be quicker with voting on/applying id
reservations :/)
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v5 2/5] virtio-pmem: Add virtio pmem driver
From: Cornelia Huck @ 2019-04-10 14:31 UTC (permalink / raw)
To: Pankaj Gupta
Cc: jack, kvm, david, qemu-devel, virtualization, adilger kernel,
zwisler, aarcange, dave jiang, linux-nvdimm, vishal l verma,
Michael S. Tsirkin, willy, hch, linux-acpi, jmoyer, linux-ext4,
lenb, kilobyte, riel, yuval shaia, stefanha, imammedo,
dan j williams, lcapitulino, nilal, tytso, xiaoguangrong eric,
darrick wong, rjw, linux-kernel, linux-xfs, linux-fsdevel
In-Reply-To: <127904196.20807948.1554904981681.JavaMail.zimbra@redhat.com>
On Wed, 10 Apr 2019 10:03:01 -0400 (EDT)
Pankaj Gupta <pagupta@redhat.com> wrote:
> >
> > On Wed, Apr 10, 2019 at 09:38:22AM +0530, Pankaj Gupta wrote:
> > > This patch adds virtio-pmem driver for KVM guest.
> > >
> > > Guest reads the persistent memory range information from
> > > Qemu over VIRTIO and registers it on nvdimm_bus. It also
> > > creates a nd_region object with the persistent memory
> > > range information so that existing 'nvdimm/pmem' driver
> > > can reserve this into system memory map. This way
> > > 'virtio-pmem' driver uses existing functionality of pmem
> > > driver to register persistent memory compatible for DAX
> > > capable filesystems.
> > >
> > > This also provides function to perform guest flush over
> > > VIRTIO from 'pmem' driver when userspace performs flush
> > > on DAX memory range.
> > >
> > > Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> > > diff --git a/include/uapi/linux/virtio_ids.h
> > > b/include/uapi/linux/virtio_ids.h
> > > index 6d5c3b2d4f4d..346389565ac1 100644
> > > --- a/include/uapi/linux/virtio_ids.h
> > > +++ b/include/uapi/linux/virtio_ids.h
> > > @@ -43,5 +43,6 @@
> > > #define VIRTIO_ID_INPUT 18 /* virtio input */
> > > #define VIRTIO_ID_VSOCK 19 /* virtio vsock transport */
> > > #define VIRTIO_ID_CRYPTO 20 /* virtio crypto */
> > > +#define VIRTIO_ID_PMEM 25 /* virtio pmem */
> > >
> > > #endif /* _LINUX_VIRTIO_IDS_H */
> >
> > Didn't Paolo point out someone is using 25 for audio?
>
>
> Sorry! I did not notice this.
>
> >
> > Please, reserve an ID with the Virtio TC before using it.
>
> I thought I requested[1] ID 25.
>
> [1] https://github.com/oasis-tcs/virtio-spec/issues/38
> [2] https://lists.oasis-open.org/archives/virtio-dev/201805/threads.html
>
> In that case I will send request for next available ID i.e 26?
Have the folks using this for audio sent a reservation request as well?
If not, I'd say the first requester should get the id...
(And yes, we need to be quicker with voting on/applying id
reservations :/)
^ 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.