* Re: [cip-dev] [PATCH 4.19.y-cip 17/23] usb: typec: add dependency for TYPEC_HD3SS3220
From: Marian-Cristian Rotariu @ 2020-02-20 11:40 UTC (permalink / raw)
To: Pavel Machek; +Cc: cip-dev@lists.cip-project.org
In-Reply-To: <20200219081627.GE31996@amd>
Hi!
> -----Original Message-----
> From: Pavel Machek <pavel@denx.de>
> Sent: 19 February 2020 08:16
> To: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Cc: cip-dev@lists.cip-project.org
> Subject: Re: [cip-dev] [PATCH 4.19.y-cip 17/23] usb: typec: add dependency
> for TYPEC_HD3SS3220
>
> On Tue 2020-02-18 14:05:14, Marian-Cristian Rotariu wrote:
> > From: Mao Wenan <maowenan@huawei.com>
> >
> > commit da4b5d18dd949abdda7c8ea76c9483b5edd49616 upstream.
> >
> > If CONFIG_TYPEC_HD3SS3220=y, CONFIG_USB_ROLE_SWITCH=m, below
> errors
> > can be found:
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_remove':
> > hd3ss3220.c:(.text+0x64): undefined reference to `usb_role_switch_put'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_dr_set':
> > hd3ss3220.c:(.text+0x154): undefined reference to
> `usb_role_switch_set_role'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_set_role':
> > hd3ss3220.c:(.text+0x294): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x2f4): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x348): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x390): undefined reference to
> `usb_role_switch_set_role'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_probe':
> > hd3ss3220.c:(.text+0x5e8): undefined reference to
> `fwnode_usb_role_switch_get'
> > hd3ss3220.c:(.text+0x8a4): undefined reference to `usb_role_switch_put'
> > make: *** [vmlinux] Error 1
>
> I guess it is okay here, but for more serious bugs it would be nice to merge
> the buggy patch with a fix -- not to break bisect.
I kind of forgot about bisect. I was mostly focused on keeping the original patches
from upstream (in this case, it is more about the commit message as the fix is trivial).
I will send this patch in v2 also, since you mostly agreed with it. Please let me know
if otherwise.
Cheers,
Marian
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
^ permalink raw reply
* Re: [PATCH 0/5] Support metric group constraint
From: Jiri Olsa @ 2020-02-20 11:39 UTC (permalink / raw)
To: kan.liang
Cc: acme, mingo, peterz, linux-kernel, mark.rutland, namhyung,
ravi.bangoria, yao.jin, ak
In-Reply-To: <1582139320-75181-1-git-send-email-kan.liang@linux.intel.com>
On Wed, Feb 19, 2020 at 11:08:35AM -0800, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
>
> Some metric groups, e.g. Page_Walks_Utilization, will never count when
> NMI watchdog is enabled.
>
> $echo 1 > /proc/sys/kernel/nmi_watchdog
> $perf stat -M Page_Walks_Utilization
>
> Performance counter stats for 'system wide':
>
> <not counted> itlb_misses.walk_pending (0.00%)
> <not counted> dtlb_load_misses.walk_pending (0.00%)
> <not counted> dtlb_store_misses.walk_pending (0.00%)
> <not counted> ept.walk_pending (0.00%)
> <not counted> cycles (0.00%)
>
> 2.343460588 seconds time elapsed
>
> Some events weren't counted. Try disabling the NMI watchdog:
> echo 0 > /proc/sys/kernel/nmi_watchdog
> perf stat ...
> echo 1 > /proc/sys/kernel/nmi_watchdog
> The events in group usually have to be from the same PMU. Try
> reorganizing the group.
>
> A metric group is a weak group, which relies on group validation
> code in the kernel to determine whether to be opened as a group or
> a non-group. However, group validation code may return false-positives,
> especially when NMI watchdog is enabled. (The metric group is allowed
> as a group but will never be scheduled.)
>
> The attempt to fix the group validation code has been rejected.
> https://lore.kernel.org/lkml/20200117091341.GX2827@hirez.programming.kicks-ass.net/
> Because we cannot accurately predict whether the group can be scheduled
> as a group, only by checking current status.
>
> This patch set provides another solution to mitigate the issue.
> Add "MetricConstraint" in event list, which provides a hint for perf tool,
> e.g. "MetricConstraint": "NO_NMI_WATCHDOG". Perf tool can change the
> metric group to non-group (standalone metrics) if NMI watchdog is enabled.
the problem is in the missing counter, that's taken by NMI watchdog, right?
and it's problem for any metric that won't fit to the available
counters.. shouldn't we rather do this workaround for any metric
that wouldn't fit in available counters? not just for chosen
ones..?
thanks,
jirka
^ permalink raw reply
* Re: [Xen-devel] [PATCH 2/5] libxl/PCI: establish per-device reserved memory policy earlier
From: Wei Liu @ 2020-02-20 11:38 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <2124c861-bd26-1ec4-3b38-0cf24ee87c79@suse.com>
On Tue, Feb 18, 2020 at 04:46:44PM +0100, Jan Beulich wrote:
> Reserved device memory region processing as well as E820 table creation
> happen earlier than the adding of (PCI) devices, yet they consume the
> policy (e.g. to decide whether to add entries to the E820 table). But so
> far it was only at the stage of PCI device addition that the final
> policy was established (i.e. if not explicitly specified by the guest
> config file).
>
> Note that I couldn't find the domain ID to be available in
> libxl__domain_device_construct_rdm(), but observing that
> libxl__device_pci_setdefault() also doesn't use it, for the time being
> DOMID_INVALID gets passed. An obvious alternative would be to drop the
> unused parameter/argument, yet at that time the question would be
> whether to also drop other unused ones.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wl@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH] selftests/rseq: Fix out-of-tree compilation
From: Michael Ellerman @ 2020-02-20 11:37 UTC (permalink / raw)
To: linux-kselftest
Cc: skhan, linux-kernel, mathieu.desnoyers, peterz, paulmck,
boqun.feng
Currently if you build with O=... the rseq tests don't build:
$ make O=$PWD/output -C tools/testing/selftests/ TARGETS=rseq
make: Entering directory '/linux/tools/testing/selftests'
...
make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ -shared -fPIC rseq.c -lpthread -o /linux/output/rseq/librseq.so
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/output/rseq/basic_test
/usr/bin/ld: cannot find -lrseq
collect2: error: ld returned 1 exit status
This is because the library search path points to the source
directory, not the output.
We can fix it by changing the library search path to $(OUTPUT).
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
This works in all cases.
With O= set:
$ make O=$PWD/output -C tools/testing/selftests/ TARGETS=rseq
...
make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/output/rseq/basic_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ basic_percpu_ops_test.c -lpthread -lrseq -o /linux/output/rseq/basic_percpu_ops_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ param_test.c -lpthread -lrseq -o /linux/output/rseq/param_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ -DBENCHMARK param_test.c -lpthread -lrseq -o /linux/output/rseq/param_test_benchmark
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE param_test.c -lpthread -lrseq -o /linux/output/rseq/param_test_compare_twice
make[1]: Leaving directory '/linux/tools/testing/selftests/rseq'
make: Leaving directory '/linux/tools/testing/selftests'
And also without, in which case the selftest makefiles set OUTPUT to
the full path of the source directory:
$ make -C tools/testing/selftests/ TARGETS=rseq
...
make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -shared -fPIC rseq.c -lpthread -o /linux/tools/testing/selftests/rseq/librseq.so
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_percpu_ops_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_percpu_ops_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DBENCHMARK param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_benchmark
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_compare_twice
make[1]: Leaving directory '/linux/tools/testing/selftests/rseq'
make: Leaving directory '/linux/tools/testing/selftests'
And finally, it also works if you build directly in the rseq
directory, eg:
$ cd tools/testing/selftests/rseq
$ make
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -shared -fPIC rseq.c -lpthread -o /linux/tools/testing/selftests/rseq/librseq.so
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_percpu_ops_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_percpu_ops_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DBENCHMARK param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_benchmark
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_compare_twice
---
tools/testing/selftests/rseq/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rseq/Makefile b/tools/testing/selftests/rseq/Makefile
index d6469535630a..708c1b345245 100644
--- a/tools/testing/selftests/rseq/Makefile
+++ b/tools/testing/selftests/rseq/Makefile
@@ -4,7 +4,7 @@ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
CLANG_FLAGS += -no-integrated-as
endif
-CFLAGS += -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ \
+CFLAGS += -O2 -Wall -g -I./ -I../../../../usr/include/ -L$(OUTPUT) -Wl,-rpath=./ \
$(CLANG_FLAGS)
LDLIBS += -lpthread
base-commit: 11a48a5a18c63fd7621bb050228cebf13566e4d8
--
2.21.1
^ permalink raw reply related
* Re: [dpdk-dev] 17.11.10 (LTS) patches review and test
From: Trahe, Fiona @ 2020-02-20 11:37 UTC (permalink / raw)
To: Luca Boccassi, dpdk stable, dev@dpdk.org; +Cc: Trahe, Fiona
In-Reply-To: <CAMw=ZnTExpkbzZRBwwejPXy1MQf2X37XzLbM12XyKBpQqQ6aFw@mail.gmail.com>
Hi Luca,
> -----Original Message-----
>
> Postponing again by one week to give more time to look into the QAT issue.
>
> Apologies again for any issue it might cause.
Thanks for that and sorry about the delay.
We're hoping to send a fix for that today.
Fiona
^ permalink raw reply
* Re: [yocto] Bitbake returning non-zero due to sstate errors
From: Richard Purdie @ 2020-02-20 11:36 UTC (permalink / raw)
To: Paul Barker, Yocto discussion list
In-Reply-To: <CAM9ZRVvDHTvvKr1Tdc+C1ZdTv2DSX8JJ9bYhHc0c-wre4qg5LA@mail.gmail.com>
On Thu, 2020-02-20 at 11:26 +0000, Paul Barker wrote:
> In my new CI setup I'm using an sstate mirror which seems to have
> some
> occasional download issues. This results in the setscene task
> failing.
> For example:
>
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: Fetcher failure: Unable to find file
> file://fd/sstate:qt3d:armv7at2hf-neon-linux-
> gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> 74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-
> neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> 74_package_write_ipk.tgz
> anywhere. The paths that were searched were:
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: No suitable staging package found
> ERROR: Logfile of failure stored in:
> /builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-
> linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-
> r0/temp/log.do_package_write_ipk_setscene.10524
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk_setscene: Failed
> WARNING: Setscene task
> (/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-
> qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
> failed with exit code '1' - real task will be run instead
>
> As indicated in the final warning message there the real tasks run
> since no sstate artifact is available. These tasks succeed:
>
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk: Succeeded
>
> The result is a successful build of the desired images. However, the
> build is marked as a failure due to those sstate errors:
>
> Summary: There were 11 ERROR messages shown, returning a non-zero
> exit code.
>
> Is this the expected behaviour? The final images are built correctly.
> I can't see any simple way to mask those setscene errors but I might
> be missing something.
>
> The full log can be seen at
> https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
> I'm on the zeus branch here, I'll try to re-test on master later if I
> can.
We've discussed this before and it can be argued either way.
Personally, I worry about why artefacts "disappear" and this is why its
an error, files should not be disappearing part way through a build.
From a bitbake perspective, a task really did fail and task failures
are errors. The fact it was able to recover is a bonus.
Perhaps it should be a warning now we have levels of warnings that are
meaningful. Previously we threw so many, this would have been one more
lost amongst many. I know many people don't like the behaviour.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH v3 16/17] s390x: protvirt: Handle SIGP store status correctly
From: Cornelia Huck @ 2020-02-20 11:34 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <cf0c8c3c-06d9-cc49-886e-c54281759dff@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]
On Thu, 20 Feb 2020 12:30:28 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:
> On 2/20/20 12:02 PM, Cornelia Huck wrote:
> > On Fri, 14 Feb 2020 10:16:35 -0500
> > Janosch Frank <frankja@linux.ibm.com> wrote:
> >
> >> Status storing is not done by QEMU anymore, but is handled by SIE.
> >>
> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> >> Reviewed-by: Thomas Huth <thuth@redhat.com>
> >> ---
> >> target/s390x/helper.c | 4 ++++
> >> target/s390x/sigp.c | 1 +
> >> 2 files changed, 5 insertions(+)
> >>
> >> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> >> index a3a49164e4..3800c4b395 100644
> >> --- a/target/s390x/helper.c
> >> +++ b/target/s390x/helper.c
> >> @@ -246,6 +246,10 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool store_arch)
> >> hwaddr len = sizeof(*sa);
> >> int i;
> >>
> >> + if (cpu->env.pv) {
> >> + return 0;
> >> + }
> >> +
> >> sa = cpu_physical_memory_map(addr, &len, 1);
> >> if (!sa) {
> >> return -EFAULT;
> >> diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
> >> index c604f17710..da0cfb97de 100644
> >> --- a/target/s390x/sigp.c
> >> +++ b/target/s390x/sigp.c
> >> @@ -497,6 +497,7 @@ void do_stop_interrupt(CPUS390XState *env)
> >> if (s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu) == 0) {
> >> qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN);
> >> }
> >> + /* Storing will occur on next SIE entry for fmt 4 */
> >
> > What's fmt 4?
>
> PVMs are using a FMT 4 SCB instead of the normal format 2 one.
>
> So I guess this should read:
> /* Storing will occur on next SIE entry for protected VMs */
Better :)
>
> >
> >> if (cpu->env.sigp_order == SIGP_STOP_STORE_STATUS) {
> >> s390_store_status(cpu, S390_STORE_STATUS_DEF_ADDR, true);
> >> }
> >
> >
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/3] VLANs, DSA switches and multiple bridges
From: Russell King - ARM Linux admin @ 2020-02-20 11:35 UTC (permalink / raw)
To: Vivien Didelot
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, Ido Schimmel,
David S. Miller, Ivan Vecera, Jakub Kicinski, Jiri Pirko, netdev
In-Reply-To: <20200219130707.GB245247@t480s.localdomain>
On Wed, Feb 19, 2020 at 01:07:07PM -0500, Vivien Didelot wrote:
> Hi Russell,
>
> Some switches like the Marvell 88E6060 don't have a VTU, so programming the
> default PVID would return -EOPNOTSUPP.
The 88e6060 has its own driver separate from mv88e6xxx.
> Switches supporting only global VLAN
> filtering cannot have a VLAN filtering aware bridge as well as a non VLAN
> filtering aware bridge spanning their ports at the same time. But all this
> shouldn't be a problem because drivers inform the stack whether they support
> ds->vlan_filtering per-port, globally or not. We should simply reject the
> operation when vlan_filtering is being enabled on unsupported hardware.
>
> Linux bridge is the reference for the implementation of an Ethernet bridge,
> if it programs VLAN entries, supported DSA hardware must do so. I'm not a
> fan of having our own bridge logic in DSA, so the limitation implemented by
> 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
> needs to go in my opinion.
... which is basically what patch 3 is doing, but in a per-driver
manner.
The checks introduced in 2ea7a679ca2a ("net: dsa: Don't add vlans when
vlan filtering is disabled") were raised up a level by c5335d737ff3
("net: dsa: check bridge VLAN in slave operations") to their present
positions, which are then touched by my patch 3 to make the checks
conditional.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCHv5 29/34] drm/arm/malidp: Make verify funcitons invocations independent
From: Boris Brezillon @ 2020-02-20 11:35 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: Mihail Atanassov, kernel, David Airlie, Liviu Dudau, Sandy Huang,
dri-devel, James Wang, Ayan Halder, Sean Paul
In-Reply-To: <20200220122913.5cd80425@collabora.com>
On Thu, 20 Feb 2020 12:29:13 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Thu, 20 Feb 2020 12:26:01 +0100
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
>
> > In the subject: s/funcitons/functions/
> >
> > On Tue, 17 Dec 2019 15:50:15 +0100
> > Andrzej Pietrasiewicz <andrzej.p@collabora.com> wrote:
> >
> > > This will make it easier to transition to generic afbc-aware helpers.
> > >
> > > Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> >
> > Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
>
> Wait, patch 30 is this patch completely irrelevant, so I take R-b back
s/patch 30 is this patch completely irrelevant/this patch is completely
irrelevant if patch 30 is applied/
> :-). You can just squash that one in patch 30.
>
> >
> > > ---
> > > drivers/gpu/drm/arm/malidp_drv.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> > > index 37d92a06318e..961e5a3f5b08 100644
> > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > @@ -362,10 +362,10 @@ static bool
> > > malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
> > > const struct drm_mode_fb_cmd2 *mode_cmd)
> > > {
> > > - if (malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> > > - return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> > > + if (!malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> > > + return false;
> > >
> > > - return false;
> > > + return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> > > }
> > >
> > > static struct drm_framebuffer *
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 4/5] perf metricgroup: Support metric constraint
From: Jiri Olsa @ 2020-02-20 11:35 UTC (permalink / raw)
To: kan.liang
Cc: acme, mingo, peterz, linux-kernel, mark.rutland, namhyung,
ravi.bangoria, yao.jin, ak
In-Reply-To: <1582139320-75181-5-git-send-email-kan.liang@linux.intel.com>
On Wed, Feb 19, 2020 at 11:08:39AM -0800, kan.liang@linux.intel.com wrote:
SNIP
> +static bool violate_nmi_constraint;
> +
> +static bool metricgroup__has_constraint(struct pmu_event *pe)
> +{
> + if (!pe->metric_constraint)
> + return false;
> +
> + if (!strcmp(pe->metric_constraint, "NO_NMI_WATCHDOG") &&
> + sysctl__nmi_watchdog_enabled()) {
> + pr_warning("Splitting metric group %s into standalone metrics.\n",
> + pe->metric_name);
> + violate_nmi_constraint = true;
no static flags plz.. can't you just print that rest of the warning in here?
jirka
> + return true;
> + }
> +
> + return false;
> +}
> +
> static int metricgroup__add_metric(const char *metric, struct strbuf *events,
> struct list_head *group_list)
> {
> @@ -460,7 +490,10 @@ static int metricgroup__add_metric(const char *metric, struct strbuf *events,
> if (events->len > 0)
> strbuf_addf(events, ",");
>
> - metricgroup__add_metric_weak_group(events, ids, idnum);
> + if (metricgroup__has_constraint(pe))
> + metricgroup__add_metric_non_group(events, ids, idnum);
> + else
> + metricgroup__add_metric_weak_group(events, ids, idnum);
>
> eg = malloc(sizeof(struct egroup));
> if (!eg) {
> @@ -544,6 +577,13 @@ int metricgroup__parse_groups(const struct option *opt,
> strbuf_release(&extra_events);
> ret = metricgroup__setup_events(&group_list, perf_evlist,
> metric_events);
> +
> + if (violate_nmi_constraint) {
> + pr_warning("Try disabling the NMI watchdog to comply NO_NMI_WATCHDOG metric constraint:\n"
> + " echo 0 > /proc/sys/kernel/nmi_watchdog\n"
> + " perf stat ...\n"
> + " echo 1 > /proc/sys/kernel/nmi_watchdog\n");
> + }
> out:
> metricgroup__free_egroups(&group_list);
> return ret;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v3 16/17] s390x: protvirt: Handle SIGP store status correctly
From: Janosch Frank @ 2020-02-20 11:30 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220120244.2ea06cec.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1703 bytes --]
On 2/20/20 12:02 PM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:35 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> Status storing is not done by QEMU anymore, but is handled by SIE.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> Reviewed-by: Thomas Huth <thuth@redhat.com>
>> ---
>> target/s390x/helper.c | 4 ++++
>> target/s390x/sigp.c | 1 +
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
>> index a3a49164e4..3800c4b395 100644
>> --- a/target/s390x/helper.c
>> +++ b/target/s390x/helper.c
>> @@ -246,6 +246,10 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool store_arch)
>> hwaddr len = sizeof(*sa);
>> int i;
>>
>> + if (cpu->env.pv) {
>> + return 0;
>> + }
>> +
>> sa = cpu_physical_memory_map(addr, &len, 1);
>> if (!sa) {
>> return -EFAULT;
>> diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
>> index c604f17710..da0cfb97de 100644
>> --- a/target/s390x/sigp.c
>> +++ b/target/s390x/sigp.c
>> @@ -497,6 +497,7 @@ void do_stop_interrupt(CPUS390XState *env)
>> if (s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu) == 0) {
>> qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN);
>> }
>> + /* Storing will occur on next SIE entry for fmt 4 */
>
> What's fmt 4?
PVMs are using a FMT 4 SCB instead of the normal format 2 one.
So I guess this should read:
/* Storing will occur on next SIE entry for protected VMs */
>
>> if (cpu->env.sigp_order == SIGP_STOP_STORE_STATUS) {
>> s390_store_status(cpu, S390_STORE_STATUS_DEF_ADDR, true);
>> }
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [dpdk-dev] [PATCH v2] net/mlx5: fix match on Ethertype and CVLAN tag
From: Dekel Peled @ 2020-02-20 11:33 UTC (permalink / raw)
To: matan, viacheslavo, rasland; +Cc: dev, stable
In-Reply-To: <15d7594cc67448389e09213b2ed13e907c471e3a.1582124890.git.dekelp@mellanox.com>
HW supports match on one Ethertype, the Ethertype following the last
VLAN tag of the packet (see PRM).
Previous patch added specific handling for packets with VLAN tag,
after setting match on Ethertype.
This patch moves the handling of packets with VLAN tag, to be done
before and instead of setting match on Ethertype.
Previous patch also added, as part of specific handling for packets
with VLAN tag, the setting of cvlan_tag mask bit in translation of
L3 items.
In case of L3 tunnel there is no inner L2 header, so setting this
mask bit is wrong and causes match failures.
This patch adds check to make sure L2 header exists before setting
cvlan_tag mask bit for L3 items.
Fixes: 00f75a40576b ("net/mlx5: fix VLAN match for DV mode")
Cc: stable@dpdk.org
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
---
drivers/net/mlx5/mlx5_flow_dv.c | 42 ++++++++++++++++++++++++++++++++---------
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 467d1ce..6f15a91 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -5213,19 +5213,27 @@ struct field_modify_info modify_tcp[] = {
/* The value must be in the range of the mask. */
for (i = 0; i < sizeof(eth_m->dst); ++i)
l24_v[i] = eth_m->src.addr_bytes[i] & eth_v->src.addr_bytes[i];
- MLX5_SET(fte_match_set_lyr_2_4, headers_m, ethertype,
- rte_be_to_cpu_16(eth_m->type));
- l24_v = MLX5_ADDR_OF(fte_match_set_lyr_2_4, headers_v, ethertype);
- *(uint16_t *)(l24_v) = eth_m->type & eth_v->type;
if (eth_v->type) {
/* When ethertype is present set mask for tagged VLAN. */
MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
/* Set value for tagged VLAN if ethertype is 802.1Q. */
if (eth_v->type == RTE_BE16(RTE_ETHER_TYPE_VLAN) ||
- eth_v->type == RTE_BE16(RTE_ETHER_TYPE_QINQ))
+ eth_v->type == RTE_BE16(RTE_ETHER_TYPE_QINQ)) {
MLX5_SET(fte_match_set_lyr_2_4, headers_v, cvlan_tag,
1);
+ /* Return here to avoid setting match on ethertype. */
+ return;
+ }
}
+ /*
+ * HW supports match on one Ethertype, the Ethertype following the last
+ * VLAN tag of the packet (see PRM).
+ * Set match on ethertype only if ETH header is not followed by VLAN.
+ */
+ MLX5_SET(fte_match_set_lyr_2_4, headers_m, ethertype,
+ rte_be_to_cpu_16(eth_m->type));
+ l24_v = MLX5_ADDR_OF(fte_match_set_lyr_2_4, headers_v, ethertype);
+ *(uint16_t *)(l24_v) = eth_m->type & eth_v->type;
}
/**
@@ -5299,6 +5307,8 @@ struct field_modify_info modify_tcp[] = {
* Flow matcher value.
* @param[in] item
* Flow pattern to translate.
+ * @param[in] item_flags
+ * Bit-fields that holds the items detected until now.
* @param[in] inner
* Item is inner pattern.
* @param[in] group
@@ -5307,6 +5317,7 @@ struct field_modify_info modify_tcp[] = {
static void
flow_dv_translate_item_ipv4(void *matcher, void *key,
const struct rte_flow_item *item,
+ const uint64_t item_flags,
int inner, uint32_t group)
{
const struct rte_flow_item_ipv4 *ipv4_m = item->mask;
@@ -5366,7 +5377,12 @@ struct field_modify_info modify_tcp[] = {
ipv4_m->hdr.next_proto_id);
MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_protocol,
ipv4_v->hdr.next_proto_id & ipv4_m->hdr.next_proto_id);
- MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
+ /*
+ * On outer header (which must contains L2), or inner header with L2,
+ * set cvlan_tag mask bit to mark this packet as untagged.
+ */
+ if (!inner || item_flags & MLX5_FLOW_LAYER_INNER_L2)
+ MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
}
/**
@@ -5378,6 +5394,8 @@ struct field_modify_info modify_tcp[] = {
* Flow matcher value.
* @param[in] item
* Flow pattern to translate.
+ * @param[in] item_flags
+ * Bit-fields that holds the items detected until now.
* @param[in] inner
* Item is inner pattern.
* @param[in] group
@@ -5386,6 +5404,7 @@ struct field_modify_info modify_tcp[] = {
static void
flow_dv_translate_item_ipv6(void *matcher, void *key,
const struct rte_flow_item *item,
+ const uint64_t item_flags,
int inner, uint32_t group)
{
const struct rte_flow_item_ipv6 *ipv6_m = item->mask;
@@ -5471,7 +5490,12 @@ struct field_modify_info modify_tcp[] = {
ipv6_m->hdr.proto);
MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_protocol,
ipv6_v->hdr.proto & ipv6_m->hdr.proto);
- MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
+ /*
+ * On outer header (which must contains L2), or inner header with L2,
+ * set cvlan_tag mask bit to mark this packet as untagged.
+ */
+ if (!inner || item_flags & MLX5_FLOW_LAYER_INNER_L2)
+ MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
}
/**
@@ -7574,7 +7598,7 @@ struct field_modify_info modify_tcp[] = {
mlx5_flow_tunnel_ip_check(items, next_protocol,
&item_flags, &tunnel);
flow_dv_translate_item_ipv4(match_mask, match_value,
- items, tunnel,
+ items, item_flags, tunnel,
dev_flow->group);
matcher.priority = MLX5_PRIORITY_MAP_L3;
last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV4 :
@@ -7597,7 +7621,7 @@ struct field_modify_info modify_tcp[] = {
mlx5_flow_tunnel_ip_check(items, next_protocol,
&item_flags, &tunnel);
flow_dv_translate_item_ipv6(match_mask, match_value,
- items, tunnel,
+ items, item_flags, tunnel,
dev_flow->group);
matcher.priority = MLX5_PRIORITY_MAP_L3;
last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV6 :
--
1.8.3.1
^ permalink raw reply related
* [PATCH] powerpc: Include .BTF section
From: Naveen N. Rao @ 2020-02-20 11:31 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
Selecting CONFIG_DEBUG_INFO_BTF results in the below warning from ld:
ld: warning: orphan section `.BTF' from `.btf.vmlinux.bin.o' being placed in section `.BTF'
Include .BTF section in vmlinux explicitly to fix the same.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/kernel/vmlinux.lds.S | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index b4c89a1acebb..a32d478a7f41 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -303,6 +303,12 @@ SECTIONS
*(.branch_lt)
}
+#ifdef CONFIG_DEBUG_INFO_BTF
+ .BTF : AT(ADDR(.BTF) - LOAD_OFFSET) {
+ *(.BTF)
+ }
+#endif
+
.opd : AT(ADDR(.opd) - LOAD_OFFSET) {
__start_opd = .;
KEEP(*(.opd))
--
2.24.1
^ permalink raw reply related
* Re: [PATCH] Avoid cpu_physical_memory_rw() with a constant is_write argument
From: Paolo Bonzini @ 2020-02-20 11:32 UTC (permalink / raw)
To: Peter Maydell, Stefan Weil
Cc: Stefano Stabellini, Eduardo Habkost, Paul Durrant,
QEMU Developers, Anthony Perard, open list:X86,
Philippe Mathieu-Daudé, Richard Henderson
In-Reply-To: <CAFEAcA9Jr2Yi1K8_9MGUJYt8C=OcKbWDh1UJjTQG1EspLux3JQ@mail.gmail.com>
On 18/02/20 19:49, Peter Maydell wrote:
> Depending on which way we go we would either want to remove these
> casts, or not.
>
> I guess that we have more cases of 'void*', and that would
> certainly be the easier way to convert (otherwise we probably
> need to add a bunch of new casts to uint8_t* in various callsites),
> but I don't have a strong opinion. Paolo ?
I agree we should use void* (possibly const).
Paolo
^ permalink raw reply
* Re: [Xen-devel] [PATCH] Avoid cpu_physical_memory_rw() with a constant is_write argument
From: Paolo Bonzini @ 2020-02-20 11:32 UTC (permalink / raw)
To: Peter Maydell, Stefan Weil
Cc: Stefano Stabellini, Eduardo Habkost, Paul Durrant,
QEMU Developers, Anthony Perard, open list:X86,
Philippe Mathieu-Daudé, Richard Henderson
In-Reply-To: <CAFEAcA9Jr2Yi1K8_9MGUJYt8C=OcKbWDh1UJjTQG1EspLux3JQ@mail.gmail.com>
On 18/02/20 19:49, Peter Maydell wrote:
> Depending on which way we go we would either want to remove these
> casts, or not.
>
> I guess that we have more cases of 'void*', and that would
> certainly be the easier way to convert (otherwise we probably
> need to add a bunch of new casts to uint8_t* in various callsites),
> but I don't have a strong opinion. Paolo ?
I agree we should use void* (possibly const).
Paolo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: Device Tree Evolution Project - call notes - 12th February
From: Steve McIntyre @ 2020-02-20 11:32 UTC (permalink / raw)
To: Frank Rowand
Cc: devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
dte-all-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <6391cf01-ebf0-fcb7-9c86-679d335c16d2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Feb 19, 2020 at 12:26:54PM -0600, Frank Rowand wrote:
>On 2/19/20 12:05 PM, Steve McIntyre wrote:
>>
>> Do you have any pointers to previous discussions about the format
>> update please? The only relevant things I can find are in the thread
>> "DTBO magic and dtbo format options" but that's back in the middle of
>> 2016.
>
>Documenting all the previous proposals in one place is the next item
>on my todo list after finishing my "why I don't want .dts to move out
>of the kernel tree" document. Once the format discussion history
>document exists then I intend to restart the discussion on the mail
>lists.
ACK. It's taking a while to get there - is there anything we can do to
help?
Cheers,
--
Steve McIntyre steve.mcintyre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
^ permalink raw reply
* Re: [PATCH v5 07/12] ceph: perform asynchronous unlink if we have sufficient caps
From: Jeff Layton @ 2020-02-20 11:32 UTC (permalink / raw)
To: Yan, Zheng
Cc: ceph-devel, Ilya Dryomov, Sage Weil, Zheng Yan, Patrick Donnelly,
Xiubo Li
In-Reply-To: <CAAM7YAnLELDoaWdO38Jez_HxiuC6mQhUgBJHspgkFYzVD7fnNQ@mail.gmail.com>
On Thu, 2020-02-20 at 14:44 +0800, Yan, Zheng wrote:
> On Wed, Feb 19, 2020 at 9:27 PM Jeff Layton <jlayton@kernel.org> wrote:
> > The MDS is getting a new lock-caching facility that will allow it
> > to cache the necessary locks to allow asynchronous directory operations.
> > Since the CEPH_CAP_FILE_* caps are currently unused on directories,
> > we can repurpose those bits for this purpose.
> >
> > When performing an unlink, if we have Fx on the parent directory,
> > and CEPH_CAP_DIR_UNLINK (aka Fr), and we know that the dentry being
> > removed is the primary link, then then we can fire off an unlink
> > request immediately and don't need to wait on reply before returning.
> >
> > In that situation, just fix up the dcache and link count and return
> > immediately after issuing the call to the MDS. This does mean that we
> > need to hold an extra reference to the inode being unlinked, and extra
> > references to the caps to avoid races. Those references are put and
> > error handling is done in the r_callback routine.
> >
> > If the operation ends up failing, then set a writeback error on the
> > directory inode, and the inode itself that can be fetched later by
> > an fsync on the dir.
> >
> > The behavior of dir caps is slightly different from caps on normal
> > files. Because these are just considered an optimization, if the
> > session is reconnected, we will not automatically reclaim them. They
> > are instead considered lost until we do another synchronous op in the
> > parent directory.
> >
> > Async dirops are enabled via the "nowsync" mount option, which is
> > patterned after the xfs "wsync" mount option. For now, the default
> > is "wsync", but eventually we may flip that.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/ceph/dir.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++--
> > fs/ceph/super.c | 20 ++++++++++
> > fs/ceph/super.h | 5 ++-
> > 3 files changed, 123 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> > index 5b83bda57056..37ab09d223fc 100644
> > --- a/fs/ceph/dir.c
> > +++ b/fs/ceph/dir.c
> > @@ -1036,6 +1036,73 @@ static int ceph_link(struct dentry *old_dentry, struct inode *dir,
> > return err;
> > }
> >
> > +static void ceph_async_unlink_cb(struct ceph_mds_client *mdsc,
> > + struct ceph_mds_request *req)
> > +{
> > + int result = req->r_err ? req->r_err :
> > + le32_to_cpu(req->r_reply_info.head->result);
> > +
> > + /* If op failed, mark everyone involved for errors */
> > + if (result) {
>
> I think this function will get called for -EJUKEBOX case.
>
Good catch. I'll have another look at how to handle this better.
>
> > + int pathlen;
> > + u64 base;
> > + char *path = ceph_mdsc_build_path(req->r_dentry, &pathlen,
> > + &base, 0);
> > +
> > + /* mark error on parent + clear complete */
> > + mapping_set_error(req->r_parent->i_mapping, result);
> > + ceph_dir_clear_complete(req->r_parent);
> > +
> > + /* drop the dentry -- we don't know its status */
> > + if (!d_unhashed(req->r_dentry))
> > + d_drop(req->r_dentry);
> > +
> > + /* mark inode itself for an error (since metadata is bogus) */
> > + mapping_set_error(req->r_old_inode->i_mapping, result);
> > +
> > + pr_warn("ceph: async unlink failure path=(%llx)%s result=%d!\n",
> > + base, IS_ERR(path) ? "<<bad>>" : path, result);
> > + ceph_mdsc_free_path(path, pathlen);
> > + }
> > + iput(req->r_old_inode);
> > +}
> > +
> > +static int get_caps_for_async_unlink(struct inode *dir, struct dentry *dentry)
> > +{
> > + struct ceph_inode_info *ci = ceph_inode(dir);
> > + struct ceph_dentry_info *di;
> > + int got = 0, want = CEPH_CAP_FILE_EXCL | CEPH_CAP_DIR_UNLINK;
> > +
> > + spin_lock(&ci->i_ceph_lock);
> > + if ((__ceph_caps_issued(ci, NULL) & want) == want) {
> > + ceph_take_cap_refs(ci, want, false);
> > + got = want;
> > + }
> > + spin_unlock(&ci->i_ceph_lock);
> > +
> > + /* If we didn't get anything, return 0 */
> > + if (!got)
> > + return 0;
> > +
> > + spin_lock(&dentry->d_lock);
> > + di = ceph_dentry(dentry);
> > + /*
> > + * - We are holding Fx, which implies Fs caps.
> > + * - Only support async unlink for primary linkage
> > + */
> > + if (atomic_read(&ci->i_shared_gen) != di->lease_shared_gen ||
> > + !(di->flags & CEPH_DENTRY_PRIMARY_LINK))
> > + want = 0;
> > + spin_unlock(&dentry->d_lock);
> > +
> > + /* Do we still want what we've got? */
> > + if (want == got)
> > + return got;
> > +
> > + ceph_put_cap_refs(ci, got);
> > + return 0;
> > +}
> > +
> > /*
> > * rmdir and unlink are differ only by the metadata op code
> > */
> > @@ -1045,6 +1112,7 @@ static int ceph_unlink(struct inode *dir, struct dentry *dentry)
> > struct ceph_mds_client *mdsc = fsc->mdsc;
> > struct inode *inode = d_inode(dentry);
> > struct ceph_mds_request *req;
> > + bool try_async = ceph_test_mount_opt(fsc, ASYNC_DIROPS);
> > int err = -EROFS;
> > int op;
> >
> > @@ -1059,6 +1127,7 @@ static int ceph_unlink(struct inode *dir, struct dentry *dentry)
> > CEPH_MDS_OP_RMDIR : CEPH_MDS_OP_UNLINK;
> > } else
> > goto out;
> > +retry:
> > req = ceph_mdsc_create_request(mdsc, op, USE_AUTH_MDS);
> > if (IS_ERR(req)) {
> > err = PTR_ERR(req);
> > @@ -1067,13 +1136,39 @@ static int ceph_unlink(struct inode *dir, struct dentry *dentry)
> > req->r_dentry = dget(dentry);
> > req->r_num_caps = 2;
> > req->r_parent = dir;
> > - set_bit(CEPH_MDS_R_PARENT_LOCKED, &req->r_req_flags);
> > req->r_dentry_drop = CEPH_CAP_FILE_SHARED;
> > req->r_dentry_unless = CEPH_CAP_FILE_EXCL;
> > req->r_inode_drop = ceph_drop_caps_for_unlink(inode);
> > - err = ceph_mdsc_do_request(mdsc, dir, req);
> > - if (!err && !req->r_reply_info.head->is_dentry)
> > - d_delete(dentry);
> > +
> > + if (try_async && op == CEPH_MDS_OP_UNLINK &&
> > + (req->r_dir_caps = get_caps_for_async_unlink(dir, dentry))) {
> > + dout("async unlink on %lu/%.*s caps=%s", dir->i_ino,
> > + dentry->d_name.len, dentry->d_name.name,
> > + ceph_cap_string(req->r_dir_caps));
> > + set_bit(CEPH_MDS_R_ASYNC, &req->r_req_flags);
> > + req->r_callback = ceph_async_unlink_cb;
> > + req->r_old_inode = d_inode(dentry);
> > + ihold(req->r_old_inode);
> > + err = ceph_mdsc_submit_request(mdsc, dir, req);
> > + if (!err) {
> > + /*
> > + * We have enough caps, so we assume that the unlink
> > + * will succeed. Fix up the target inode and dcache.
> > + */
> > + drop_nlink(inode);
> > + d_delete(dentry);
> > + } else if (err == -EJUKEBOX) {
> > + try_async = false;
> > + ceph_mdsc_put_request(req);
> > + goto retry;
> > + }
> > + } else {
> > + set_bit(CEPH_MDS_R_PARENT_LOCKED, &req->r_req_flags);
> > + err = ceph_mdsc_do_request(mdsc, dir, req);
> > + if (!err && !req->r_reply_info.head->is_dentry)
> > + d_delete(dentry);
> > + }
> > +
> > ceph_mdsc_put_request(req);
> > out:
> > return err;
> > diff --git a/fs/ceph/super.c b/fs/ceph/super.c
> > index b1329cd5388a..c9784eb1159a 100644
> > --- a/fs/ceph/super.c
> > +++ b/fs/ceph/super.c
> > @@ -155,6 +155,7 @@ enum {
> > Opt_acl,
> > Opt_quotadf,
> > Opt_copyfrom,
> > + Opt_wsync,
> > };
> >
> > enum ceph_recover_session_mode {
> > @@ -194,6 +195,7 @@ static const struct fs_parameter_spec ceph_mount_parameters[] = {
> > fsparam_string ("snapdirname", Opt_snapdirname),
> > fsparam_string ("source", Opt_source),
> > fsparam_u32 ("wsize", Opt_wsize),
> > + fsparam_flag_no ("wsync", Opt_wsync),
> > {}
> > };
> >
> > @@ -444,6 +446,12 @@ static int ceph_parse_mount_param(struct fs_context *fc,
> > fc->sb_flags &= ~SB_POSIXACL;
> > }
> > break;
> > + case Opt_wsync:
> > + if (!result.negated)
> > + fsopt->flags &= ~CEPH_MOUNT_OPT_ASYNC_DIROPS;
> > + else
> > + fsopt->flags |= CEPH_MOUNT_OPT_ASYNC_DIROPS;
> > + break;
> > default:
> > BUG();
> > }
> > @@ -567,6 +575,9 @@ static int ceph_show_options(struct seq_file *m, struct dentry *root)
> > if (fsopt->flags & CEPH_MOUNT_OPT_CLEANRECOVER)
> > seq_show_option(m, "recover_session", "clean");
> >
> > + if (fsopt->flags & CEPH_MOUNT_OPT_ASYNC_DIROPS)
> > + seq_puts(m, ",nowsync");
> > +
> > if (fsopt->wsize != CEPH_MAX_WRITE_SIZE)
> > seq_printf(m, ",wsize=%u", fsopt->wsize);
> > if (fsopt->rsize != CEPH_MAX_READ_SIZE)
> > @@ -1115,6 +1126,15 @@ static void ceph_free_fc(struct fs_context *fc)
> >
> > static int ceph_reconfigure_fc(struct fs_context *fc)
> > {
> > + struct ceph_parse_opts_ctx *pctx = fc->fs_private;
> > + struct ceph_mount_options *fsopt = pctx->opts;
> > + struct ceph_fs_client *fsc = ceph_sb_to_client(fc->root->d_sb);
> > +
> > + if (fsopt->flags & CEPH_MOUNT_OPT_ASYNC_DIROPS)
> > + ceph_set_mount_opt(fsc, ASYNC_DIROPS);
> > + else
> > + ceph_clear_mount_opt(fsc, ASYNC_DIROPS);
> > +
> > sync_filesystem(fc->root->d_sb);
> > return 0;
> > }
> > diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> > index 2393803c38de..1b4996efc111 100644
> > --- a/fs/ceph/super.h
> > +++ b/fs/ceph/super.h
> > @@ -43,13 +43,16 @@
> > #define CEPH_MOUNT_OPT_MOUNTWAIT (1<<12) /* mount waits if no mds is up */
> > #define CEPH_MOUNT_OPT_NOQUOTADF (1<<13) /* no root dir quota in statfs */
> > #define CEPH_MOUNT_OPT_NOCOPYFROM (1<<14) /* don't use RADOS 'copy-from' op */
> > +#define CEPH_MOUNT_OPT_ASYNC_DIROPS (1<<15) /* allow async directory ops */
> >
> > #define CEPH_MOUNT_OPT_DEFAULT \
> > (CEPH_MOUNT_OPT_DCACHE | \
> > CEPH_MOUNT_OPT_NOCOPYFROM)
> >
> > #define ceph_set_mount_opt(fsc, opt) \
> > - (fsc)->mount_options->flags |= CEPH_MOUNT_OPT_##opt;
> > + (fsc)->mount_options->flags |= CEPH_MOUNT_OPT_##opt
> > +#define ceph_clear_mount_opt(fsc, opt) \
> > + (fsc)->mount_options->flags &= ~CEPH_MOUNT_OPT_##opt
> > #define ceph_test_mount_opt(fsc, opt) \
> > (!!((fsc)->mount_options->flags & CEPH_MOUNT_OPT_##opt))
> >
> > --
> > 2.24.1
> >
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver #16]
From: Ian Kent @ 2020-02-20 11:30 UTC (permalink / raw)
To: Christian Brauner
Cc: David Howells, viro, mszeredi, christian, linux-api,
linux-fsdevel, linux-kernel
In-Reply-To: <20200220090939.4e2mpmdixcyruzda@wittgenstein>
On Thu, 2020-02-20 at 10:09 +0100, Christian Brauner wrote:
> On Thu, Feb 20, 2020 at 12:42:15PM +0800, Ian Kent wrote:
> > On Wed, 2020-02-19 at 15:46 +0100, Christian Brauner wrote:
> > > On Tue, Feb 18, 2020 at 05:04:55PM +0000, David Howells wrote:
> > > > Here are a set of patches that adds system calls, that (a)
> > > > allow
> > > > information about the VFS, mount topology, superblock and files
> > > > to
> > > > be
> > > > retrieved and (b) allow for notifications of mount topology
> > > > rearrangement
> > > > events, mount and superblock attribute changes and other
> > > > superblock
> > > > events,
> > > > such as errors.
> > > >
> > > > ============================
> > > > FILESYSTEM INFORMATION QUERY
> > > > ============================
> > > >
> > > > The first system call, fsinfo(), allows information about the
> > > > filesystem at
> > > > a particular path point to be queried as a set of attributes,
> > > > some
> > > > of which
> > > > may have more than one value.
> > > >
> > > > Attribute values are of four basic types:
> > > >
> > > > (1) Version dependent-length structure (size defined by type).
> > > >
> > > > (2) Variable-length string (up to 4096, including NUL).
> > > >
> > > > (3) List of structures (up to INT_MAX size).
> > > >
> > > > (4) Opaque blob (up to INT_MAX size).
> > >
> > > I mainly have an organizational question. :) This is a huge
> > > patchset
> > > with lots and lots of (good) features. Wouldn't it make sense to
> > > make
> > > the fsinfo() syscall a completely separate patchset from the
> > > watch_mount() and watch_sb() syscalls? It seems that they don't
> > > need
> > > to
> > > depend on each other at all. This would make reviewing this so
> > > much
> > > nicer and likely would mean that fsinfo() could proceed a little
> > > faster.
> >
> > The remainder of the fsinfo() series would need to remain useful
> > if this was done.
> >
> > For context I want work on improving handling of large mount
> > tables.
>
> Yeah, I've talked to David about this; polling on a large mountinfo
> file
> is not great, I agree.
>
> > Ultimately I expect to solve a very long standing autofs problem
> > of using large direct mount maps without prohibitive performance
> > overhead (and there a lot of rather challenging autofs changes to
> > do for this too) and I believe the fsinfo() system call, and
> > related bits, is the way to do this.
> >
> > But improving the handling of large mount tables for autofs
> > will have the side effect of improvements for other mount table
> > users, even in the early stages of this work.
> >
> > For example I want to use this for mount table handling
> > improvements
> > in libmount. Clearly that ultimately needs mount change
> > notification
> > in the end but ...
> >
> > There's a bunch of things that need to be done alone the way
> > to even get started.
> >
> > One thing that's needed is the ability to call fsinfo() to get
> > information on a mount to avoid constant reading of the proc based
> > mount table, which happens a lot (since the mount info. needs
> > to be up to date) so systemd (and others) would see an improvement
> > with the fsinfo() system call alone able to be used in libmount.
> >
> > But for the fsinfo() system call to be used for this the file
> > system specific mount options need to also be obtained when
> > using fsinfo(). That means the super block operation fsinfo uses
> > to provide this must be implemented for at least most file systems.
> >
> > So separating out the notifications part, leaving whatever is
> > needed
> > to still be able to do this, should be fine and the system call
> > would be immediately useful once the super operation is implemented
> > for the needed file systems.
> >
> > Whether the implementation of the super operation should be done
> > as part of this series is another question but would certainly
> > be a challenge and make the series more complicated. But is needed
> > for the change to be useful in my case.
>
> I think what would might work - and what David had already brought up
> briefly - is to either base the fsinfo branch on top of the mount
> notificaiton branch or break the notification counters pieces into a
> separate patch and base both mount notifications and fsinfo on top of
> it.
Possibly, but I'm pretty sure David has more fsinfo patches.
So I suspect there will be a right time to post patches for the
fsinfo super block operation that David doesn't already have. I'm
going to have to find time for that ...
The post was more to let David know what my first goal is and what
I need for it, and to let others know there is someone wanting to
use this for user space improvements and give some initial insight
into my longer term goals.
Ian
^ permalink raw reply
* Re: [PATCH v5 05/12] ceph: cap tracking for async directory operations
From: Jeff Layton @ 2020-02-20 11:30 UTC (permalink / raw)
To: Yan, Zheng
Cc: ceph-devel, Ilya Dryomov, Sage Weil, Zheng Yan, Patrick Donnelly,
Xiubo Li
In-Reply-To: <CAAM7YAk-cjnPqH0UhBRvzvZdk4JTXwuVzxBD8ObunQqVxm2NuQ@mail.gmail.com>
On Thu, 2020-02-20 at 14:42 +0800, Yan, Zheng wrote:
> On Wed, Feb 19, 2020 at 9:27 PM Jeff Layton <jlayton@kernel.org> wrote:
> > Track and correctly handle directory caps for asynchronous operations.
> > Add aliases for Frc caps that we now designate at Dcu caps (when dealing
> > with directories).
> >
> > Unlike file caps, we don't reclaim these when the session goes away, and
> > instead preemptively release them. In-flight async dirops are instead
> > handled during reconnect phase. The client needs to re-do a synchronous
> > operation in order to re-get directory caps.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/ceph/caps.c | 29 ++++++++++++++++++++---------
> > fs/ceph/mds_client.c | 31 ++++++++++++++++++++++++++-----
> > fs/ceph/mds_client.h | 6 +++++-
> > include/linux/ceph/ceph_fs.h | 6 ++++++
> > 4 files changed, 57 insertions(+), 15 deletions(-)
> >
> > diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> > index 295837215a3a..d6c5ee33f30f 100644
> > --- a/fs/ceph/caps.c
> > +++ b/fs/ceph/caps.c
> > @@ -992,7 +992,11 @@ int __ceph_caps_file_wanted(struct ceph_inode_info *ci)
> > int __ceph_caps_wanted(struct ceph_inode_info *ci)
> > {
> > int w = __ceph_caps_file_wanted(ci) | __ceph_caps_used(ci);
> > - if (!S_ISDIR(ci->vfs_inode.i_mode)) {
> > + if (S_ISDIR(ci->vfs_inode.i_mode)) {
> > + /* we want EXCL if holding caps of dir ops */
> > + if (w & CEPH_CAP_ANY_DIR_OPS)
> > + w |= CEPH_CAP_FILE_EXCL;
> > + } else {
> > /* we want EXCL if dirty data */
> > if (w & CEPH_CAP_FILE_BUFFER)
> > w |= CEPH_CAP_FILE_EXCL;
> > @@ -1890,10 +1894,13 @@ void ceph_check_caps(struct ceph_inode_info *ci, int flags,
> > * revoking the shared cap on every create/unlink
> > * operation.
> > */
> > - if (IS_RDONLY(inode))
> > + if (IS_RDONLY(inode)) {
> > want = CEPH_CAP_ANY_SHARED;
> > - else
> > - want = CEPH_CAP_ANY_SHARED | CEPH_CAP_FILE_EXCL;
> > + } else {
> > + want = CEPH_CAP_ANY_SHARED |
> > + CEPH_CAP_FILE_EXCL |
> > + CEPH_CAP_ANY_DIR_OPS;
> > + }
> > retain |= want;
> > } else {
> >
> > @@ -2750,13 +2757,17 @@ int ceph_try_get_caps(struct inode *inode, int need, int want,
> > int ret;
> >
> > BUG_ON(need & ~CEPH_CAP_FILE_RD);
> > - BUG_ON(want & ~(CEPH_CAP_FILE_CACHE|CEPH_CAP_FILE_LAZYIO|CEPH_CAP_FILE_SHARED));
> > - ret = ceph_pool_perm_check(inode, need);
> > - if (ret < 0)
> > - return ret;
> > + if (need) {
> > + ret = ceph_pool_perm_check(inode, need);
> > + if (ret < 0)
> > + return ret;
> > + }
> >
> > + BUG_ON(want & ~(CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_LAZYIO |
> > + CEPH_CAP_FILE_SHARED | CEPH_CAP_FILE_EXCL |
> > + CEPH_CAP_ANY_DIR_OPS));
> > ret = try_get_cap_refs(inode, need, want, 0,
> > - (nonblock ? NON_BLOCKING : 0), got);
> > + nonblock ? NON_BLOCKING : 0, got);
> > return ret == -EAGAIN ? 0 : ret;
> > }
> >
> > diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> > index 38eb9dd5062b..ef3dd6fe2f4d 100644
> > --- a/fs/ceph/mds_client.c
> > +++ b/fs/ceph/mds_client.c
> > @@ -699,6 +699,7 @@ void ceph_mdsc_release_request(struct kref *kref)
> > struct ceph_mds_request *req = container_of(kref,
> > struct ceph_mds_request,
> > r_kref);
> > + ceph_mdsc_release_dir_caps(req);
>
> I think we can do this in complete_request()
>
That's what I was doing originally, but doing it there complicates the
error handling in the case where we end up tearing down the request
before it's ever submitted for transmission. It's also weird, as
ceph_mdsc_release_request is where other resources for the request are
released.
It's safe to call it more than once though, so I suppose we could do it
in complete_request and here.
> > destroy_reply_info(&req->r_reply_info);
> > if (req->r_request)
> > ceph_msg_put(req->r_request);
> > @@ -3280,6 +3281,17 @@ static void handle_session(struct ceph_mds_session *session,
> > return;
> > }
> >
> > +void ceph_mdsc_release_dir_caps(struct ceph_mds_request *req)
> > +{
> > + int dcaps;
> > +
> > + dcaps = xchg(&req->r_dir_caps, 0);
> > + if (dcaps) {
> > + dout("releasing r_dir_caps=%s\n", ceph_cap_string(dcaps));
> > + ceph_put_cap_refs(ceph_inode(req->r_parent), dcaps);
> > + }
> > +}
> > +
> > /*
> > * called under session->mutex.
> > */
> > @@ -3307,9 +3319,14 @@ static void replay_unsafe_requests(struct ceph_mds_client *mdsc,
> > continue;
> > if (req->r_attempts == 0)
> > continue; /* only old requests */
> > - if (req->r_session &&
> > - req->r_session->s_mds == session->s_mds)
> > - __send_request(mdsc, session, req, true);
> > + if (!req->r_session)
> > + continue;
> > + if (req->r_session->s_mds != session->s_mds)
> > + continue;
> > +
> > + ceph_mdsc_release_dir_caps(req);
> > +
> > + __send_request(mdsc, session, req, true);
> > }
> > mutex_unlock(&mdsc->mutex);
> > }
> > @@ -3393,7 +3410,7 @@ static int send_reconnect_partial(struct ceph_reconnect_state *recon_state)
> > /*
> > * Encode information about a cap for a reconnect with the MDS.
> > */
> > -static int encode_caps_cb(struct inode *inode, struct ceph_cap *cap,
> > +static int reconnect_caps_cb(struct inode *inode, struct ceph_cap *cap,
> > void *arg)
> > {
> > union {
> > @@ -3416,6 +3433,10 @@ static int encode_caps_cb(struct inode *inode, struct ceph_cap *cap,
> > cap->mseq = 0; /* and migrate_seq */
> > cap->cap_gen = cap->session->s_cap_gen;
> >
> > + /* These are lost when the session goes away */
> > + if (S_ISDIR(inode->i_mode))
> > + cap->issued &= ~CEPH_CAP_ANY_DIR_OPS;
> > +
> > if (recon_state->msg_version >= 2) {
> > rec.v2.cap_id = cpu_to_le64(cap->cap_id);
> > rec.v2.wanted = cpu_to_le32(__ceph_caps_wanted(ci));
> > @@ -3712,7 +3733,7 @@ static void send_mds_reconnect(struct ceph_mds_client *mdsc,
> > recon_state.msg_version = 2;
> > }
> > /* trsaverse this session's caps */
> > - err = ceph_iterate_session_caps(session, encode_caps_cb, &recon_state);
> > + err = ceph_iterate_session_caps(session, reconnect_caps_cb, &recon_state);
> >
> > spin_lock(&session->s_cap_lock);
> > session->s_cap_reconnect = 0;
> > diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h
> > index 8043f2b439b1..f10d342ea585 100644
> > --- a/fs/ceph/mds_client.h
> > +++ b/fs/ceph/mds_client.h
> > @@ -284,8 +284,11 @@ struct ceph_mds_request {
> > struct ceph_msg *r_request; /* original request */
> > struct ceph_msg *r_reply;
> > struct ceph_mds_reply_info_parsed r_reply_info;
> > - struct page *r_locked_page;
> > int r_err;
> > +
> > +
> > + struct page *r_locked_page;
> > + int r_dir_caps;
> > int r_num_caps;
> > u32 r_readdir_offset;
> >
> > @@ -489,6 +492,7 @@ extern int ceph_mdsc_submit_request(struct ceph_mds_client *mdsc,
> > extern int ceph_mdsc_do_request(struct ceph_mds_client *mdsc,
> > struct inode *dir,
> > struct ceph_mds_request *req);
> > +extern void ceph_mdsc_release_dir_caps(struct ceph_mds_request *req);
> > static inline void ceph_mdsc_get_request(struct ceph_mds_request *req)
> > {
> > kref_get(&req->r_kref);
> > diff --git a/include/linux/ceph/ceph_fs.h b/include/linux/ceph/ceph_fs.h
> > index 94cc4b047987..91d09cf37649 100644
> > --- a/include/linux/ceph/ceph_fs.h
> > +++ b/include/linux/ceph/ceph_fs.h
> > @@ -663,6 +663,12 @@ int ceph_flags_to_mode(int flags);
> > #define CEPH_CAP_LOCKS (CEPH_LOCK_IFILE | CEPH_LOCK_IAUTH | CEPH_LOCK_ILINK | \
> > CEPH_LOCK_IXATTR)
> >
> > +/* cap masks async dir operations */
> > +#define CEPH_CAP_DIR_CREATE CEPH_CAP_FILE_CACHE
> > +#define CEPH_CAP_DIR_UNLINK CEPH_CAP_FILE_RD
> > +#define CEPH_CAP_ANY_DIR_OPS (CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_RD | \
> > + CEPH_CAP_FILE_WREXTEND | CEPH_CAP_FILE_LAZYIO)
> > +
> > int ceph_caps_for_mode(int mode);
> >
> > enum {
> > --
> > 2.24.1
> >
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 13/17] s390x: protvirt: Move diag 308 data over SIDAD
From: Janosch Frank @ 2020-02-20 11:29 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220120052.7691f6f8.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 3988 bytes --]
On 2/20/20 12:00 PM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:32 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> For protected guests the IPIB is written/read to/from the satellite
>> block, so we need to make those accesses virtual to make them go
>> through KVM mem ops.
..we need those accesses to go through s390_cpu_pv_mem_read/write() so
we use the memop IOCTL to access the sattelite block.
>
> Confused. What does 'make those accesses virtual' mean?
I need to update the patch description.
Virtual memory access was needed when I overloaded the normal memops to
access the SIDA. Real access would have accessed guest memory directly
which results in a guest crash for protected VMs.
>
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ---
>> target/s390x/diag.c | 32 +++++++++++++++++++++++++-------
>> 1 file changed, 25 insertions(+), 7 deletions(-)
>>
>> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
>> index 6aaeef6029..59ae122e82 100644
>> --- a/target/s390x/diag.c
>> +++ b/target/s390x/diag.c
>> @@ -88,6 +88,7 @@ static int diag308_parm_check(CPUS390XState *env, uint64_t r1, uint64_t addr,
>> void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
>> {
>> CPUState *cs = env_cpu(env);
>> + S390CPU *cpu = S390_CPU(cs);
>> uint64_t addr = env->regs[r1];
>> uint64_t subcode = env->regs[r3];
>> IplParameterBlock *iplb;
>> @@ -118,14 +119,24 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
>> if (diag308_parm_check(env, r1, addr, ra, false)) {
>> return;
>> }
>> +
>
> Whitespace.
Ack.
>
>> iplb = g_new0(IplParameterBlock, 1);
>> - cpu_physical_memory_read(addr, iplb, sizeof(iplb->len));
>> + if (!env->pv) {
>> + cpu_physical_memory_read(addr, iplb, sizeof(iplb->len));
>> + } else {
>> + s390_cpu_pv_mem_read(cpu, 0, iplb, sizeof(iplb->len));
>> + }
>> +
>> if (!iplb_valid_len(iplb)) {
>> env->regs[r1 + 1] = DIAG_308_RC_INVALID;
>> goto out;
>> }
>>
>> - cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
>> + if (!env->pv) {
>> + cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
>> + } else {
>> + s390_cpu_pv_mem_read(cpu, 0, iplb, be32_to_cpu(iplb->len));
>> + }
>>
>> if (!iplb_valid_ccw(iplb) && !iplb_valid_fcp(iplb) &&
>> !(iplb_valid_pv(iplb) && s390_ipl_pv_check_components(iplb) >= 0)) {
>> @@ -137,23 +148,30 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
>> env->regs[r1 + 1] = DIAG_308_RC_OK;
>> out:
>> g_free(iplb);
>> - return;
>> + break;
>> case DIAG308_STORE:
>> case DIAG308_PV_STORE:
>> if (diag308_parm_check(env, r1, addr, ra, true)) {
>> return;
>> }
>> +
>
> Whitespace.
Ack.
>
>> if (subcode == DIAG308_PV_STORE) {
>> iplb = s390_ipl_get_iplb_secure();
>> } else {
>> iplb = s390_ipl_get_iplb();
>> }
>> - if (iplb) {
>> - cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
>> - env->regs[r1 + 1] = DIAG_308_RC_OK;
>> - } else {
>> + if (!iplb) {
>> env->regs[r1 + 1] = DIAG_308_RC_NO_CONF;
>> + return;
>> }
>> +
>> + if (!env->pv) {
>> + cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
>> + } else {
>> + s390_cpu_pv_mem_write(cpu, 0, iplb, be32_to_cpu(iplb->len));
>> + }
>> +
>> + env->regs[r1 + 1] = DIAG_308_RC_OK;
>> break;
>> case DIAG308_PV_START:
>> iplb = s390_ipl_get_iplb_secure();
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/4] nvmem: fix memory leak in error path
From: Srinivas Kandagatla @ 2020-02-20 11:30 UTC (permalink / raw)
To: Bartosz Golaszewski, Linus Walleij, Khouloud Touil,
Geert Uytterhoeven
Cc: linux-gpio, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20200220100141.5905-2-brgl@bgdev.pl>
On 20/02/2020 10:01, Bartosz Golaszewski wrote:
> - if (IS_ERR(nvmem->wp_gpio))
> + if (IS_ERR(nvmem->wp_gpio)) {
> + ida_simple_remove(&nvmem_ida, nvmem->id);
> + kfree(nvmem);
> return ERR_CAST(nvmem->wp_gpio);
You freed nvmem just before this statement, how can nvmem->wp_gpio be
still be valid?
Are you able to test this changes at your end?
Or
these are just compile tested?
--srini
> + }
>
^ permalink raw reply
* Re: [PATCH v2] Avoid address_space_rw() with a constant is_write argument
From: Paolo Bonzini @ 2020-02-20 11:28 UTC (permalink / raw)
To: Laurent Vivier, Peter Maydell, qemu-devel
Cc: Thomas Huth, Alistair Francis, Eduardo Habkost, Cornelia Huck,
Halil Pasic, Christian Borntraeger, Cédric Le Goater,
Edgar E. Iglesias, David Gibson
In-Reply-To: <fc70075c-0098-632e-7d60-4534202bf2f5@redhat.com>
On 18/02/20 14:13, Laurent Vivier wrote:
> There is one in target/i386/hvf/vmx.h: macvm_set_cr0() you didn't change.
>
> You must update the script name in the script comment (as suggested by
> Philippe) and in the commit message.
>
> Anyway:
>
> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Thanks, I squashed the change to vmx.h.
Paolo
^ permalink raw reply
* Re: [PATCHv5 29/34] drm/arm/malidp: Make verify funcitons invocations independent
From: Boris Brezillon @ 2020-02-20 11:29 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: Mihail Atanassov, David Airlie, Liviu Dudau, Sandy Huang,
dri-devel, Ayan Halder, James Wang, kernel, Sean Paul
In-Reply-To: <20200220122601.1e2212a4@collabora.com>
On Thu, 20 Feb 2020 12:26:01 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> In the subject: s/funcitons/functions/
>
> On Tue, 17 Dec 2019 15:50:15 +0100
> Andrzej Pietrasiewicz <andrzej.p@collabora.com> wrote:
>
> > This will make it easier to transition to generic afbc-aware helpers.
> >
> > Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Wait, patch 30 is this patch completely irrelevant, so I take R-b back
:-). You can just squash that one in patch 30.
>
> > ---
> > drivers/gpu/drm/arm/malidp_drv.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> > index 37d92a06318e..961e5a3f5b08 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -362,10 +362,10 @@ static bool
> > malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
> > const struct drm_mode_fb_cmd2 *mode_cmd)
> > {
> > - if (malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> > - return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> > + if (!malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> > + return false;
> >
> > - return false;
> > + return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> > }
> >
> > static struct drm_framebuffer *
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* w83627ehf crash in 5.6.0-rc2-00055-gca7e1fd1026c
From: Meelis Roos @ 2020-02-20 11:18 UTC (permalink / raw)
To: linux-hwmon; +Cc: LKML, Dr. David Alan Gilbert, Chen Zhou
While reading w83627ehf sensors output on D425KT mainboard, I consistently get NULL dereference as below.
5.5.0 worked OK but gave a warning on driver load:
[ 104.514954] w83627ehf: Found W83627DHG-P chip at 0x290
[ 104.515634] w83627ehf w83627ehf.656: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
This is dmesg from current git (loading the driver and reading sensors with lm-sensors - no driver loading warning any more):
[ 764.718192] w83627ehf: Found W83627DHG-P chip at 0x290
[ 774.574874] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 774.574889] #PF: supervisor read access in kernel mode
[ 774.574895] #PF: error_code(0x0000) - not-present page
[ 774.574901] PGD 0 P4D 0
[ 774.574909] Oops: 0000 [#1] SMP NOPTI
[ 774.574917] CPU: 0 PID: 604 Comm: sensors Not tainted 5.6.0-rc2-00055-gca7e1fd1026c #29
[ 774.574923] Hardware name: /D425KT, BIOS MWPNT10N.86A.0132.2013.0726.1534 07/26/2013
[ 774.574939] RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
[ 774.574947] Code: 00 00 00 55 53 48 8d 64 24 f0 83 fa 15 48 8b 5f 78 75 29 83 fe 01 75 24 48 63 c9 48 8b 6b 58 48 83 f9 03 77 24 0f b6 44 0b 50 <48> 8b 44 c5 00 49 89 00 48 8d 64 24 10 5b 31 c0 5d c3 48 8d 64 24
[ 774.574958] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
[ 774.574965] RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
[ 774.574972] RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
[ 774.574978] RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
[ 774.574985] R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
[ 774.574991] R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
[ 774.574999] FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
[ 774.575008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 774.575015] CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
[ 774.575021] Call Trace:
[ 774.575036] ? cp_new_stat+0x12d/0x160
[ 774.575048] hwmon_attr_show_string+0x37/0x70 [hwmon]
[ 774.575060] dev_attr_show+0x14/0x50
[ 774.575071] sysfs_kf_seq_show+0xb5/0x1b0
[ 774.575081] seq_read+0xcf/0x460
[ 774.575091] vfs_read+0x9b/0x150
[ 774.575100] ksys_read+0x5f/0xe0
[ 774.575111] do_syscall_64+0x48/0x190
[ 774.575121] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 774.575130] RIP: 0033:0x7fbc7c715871
[ 774.575138] Code: fe ff ff 50 48 8d 3d 76 e5 09 00 e8 e9 ef 01 00 66 0f 1f 84 00 00 00 00 00 48 8d 05 69 3b 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
[ 774.575151] RSP: 002b:00007ffe5092d848 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 774.575161] RAX: ffffffffffffffda RBX: 00005630bdfb1330 RCX: 00007fbc7c715871
[ 774.575168] RDX: 0000000000001000 RSI: 00007ffe5092d8e0 RDI: 0000000000000003
[ 774.575175] RBP: 00007fbc7c7e5560 R08: 0000000000000003 R09: 00007fbc7c7e43b0
[ 774.575182] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001000
[ 774.575190] R13: 00007ffe5092d8e0 R14: 0000000000000d68 R15: 00007fbc7c7e4960
[ 774.575199] Modules linked in: w83627ehf hwmon_vid snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_pcsp snd_hda_core ir_rc6_decoder rc_rc6_mce uas r8169 mceusb snd_pcm
iTCO_wdt rc_core snd_timer iTCO_vendor_support realtek snd libphy soundcore i2c_i801 lpc_ich parport_pc mfd_core parport coretemp hwmon autofs4
[ 774.575247] CR2: 0000000000000000
[ 774.575254] ---[ end trace 607462057ab8a988 ]---
[ 774.575264] RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf]
[ 774.575273] Code: 00 00 00 55 53 48 8d 64 24 f0 83 fa 15 48 8b 5f 78 75 29 83 fe 01 75 24 48 63 c9 48 8b 6b 58 48 83 f9 03 77 24 0f b6 44 0b 50 <48> 8b 44 c5 00 49 89 00 48 8d 64 24 10 5b 31 c0 5d c3 48 8d 64 24
[ 774.575287] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293
[ 774.575294] RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000
[ 774.575301] RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08
[ 774.575308] RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001
[ 774.575316] R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00
[ 774.575323] R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40
[ 774.575331] FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000
[ 774.575340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 774.575347] CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0
--
Meelis Roos <mroos@linux.ee>
^ permalink raw reply
* Re: Race condition in overlayed qcow2?
From: Vladimir Sementsov-Ogievskiy @ 2020-02-20 11:26 UTC (permalink / raw)
To: Pavel Dovgalyuk; +Cc: kwolf, qemu-devel, mreitz
In-Reply-To: <003701d5e7d4$90bcc130$b2364390$@ru>
20.02.2020 13:00, Pavel Dovgalyuk wrote:
>> From: Vladimir Sementsov-Ogievskiy [mailto:vsementsov@virtuozzo.com]
>> 20.02.2020 11:31, dovgaluk wrote:
>>> Vladimir Sementsov-Ogievskiy писал 2020-02-19 19:07:
>>>> 19.02.2020 17:32, dovgaluk wrote:
>>>>> I encountered a problem with record/replay of QEMU execution and figured out the
>> following, when
>>>>> QEMU is started with one virtual disk connected to the qcow2 image with applied 'snapshot'
>> option.
>>>>>
>>>>> The patch d710cf575ad5fb3ab329204620de45bfe50caa53 "block/qcow2: introduce parallel
>> subrequest handling in read and write"
>>>>> introduces some kind of race condition, which causes difference in the data read from the
>> disk.
>>>>>
>>>>> I detected this by adding the following code, which logs IO operation checksum. And this
>> checksum may be different in different runs of the same recorded execution.
>>>>>
>>>>> logging in blk_aio_complete function:
>>>>> qemu_log("%"PRId64": blk_aio_complete\n", replay_get_current_icount());
>>>>> QEMUIOVector *qiov = acb->rwco.iobuf;
>>>>> if (qiov && qiov->iov) {
>>>>> size_t i, j;
>>>>> uint64_t sum = 0;
>>>>> int count = 0;
>>>>> for (i = 0 ; i < qiov->niov ; ++i) {
>>>>> for (j = 0 ; j < qiov->iov[i].iov_len ; ++j) {
>>>>> sum += ((uint8_t*)qiov->iov[i].iov_base)[j];
>>>>> ++count;
>>>>> }
>>>>> }
>>>>> qemu_log("--- iobuf offset %"PRIx64" len %x sum: %"PRIx64"\n", acb-
>>> rwco.offset, count, sum);
>>>>> }
>>>>>
>>>>> I tried to get rid of aio task by patching qcow2_co_preadv_part:
>>>>> ret = qcow2_co_preadv_task(bs, ret, cluster_offset, offset, cur_bytes, qiov, qiov_offset);
>>>>>
>>>>> That change fixed a bug, but I have no idea what to debug next to figure out the exact
>> reason of the failure.
>>>>>
>>>>> Do you have any ideas or hints?
>>>>>
>>>>
>>>> Hi!
>>>>
>>>> Hmm, do mean that read from the disk may return wrong data? It would
>>>> be very bad of course :(
>>>> Could you provide a reproducer, so that I can look at it and debug?
>>>
>>> It is just a winxp-32 image. I record the execution and replay it with the following command
>> lines:
>>>
>>> qemu-system-i386 -icount shift=7,rr=record,rrfile=replay.bin -m 512M -drive
>> file=xp.qcow2,if=none,id=device-34-file,snapshot -drive driver=blkreplay,if=none,image=device-
>> 34-file,id=device-34-driver -device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -net
>> none
>>>
>>> qemu-system-i386 -icount shift=7,rr=replay,rrfile=replay.bin -m 512M -drive
>> file=xp.qcow2,if=none,id=device-34-file,snapshot -drive driver=blkreplay,if=none,image=device-
>> 34-file,id=device-34-driver -device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -net
>> none
>>>
>>> Replay stalls at some moment due to the non-determinism of the execution (probably caused by
>> the wrong data read).
>>
>> Hmm.. I tried it (with x86_64 qemu and centos image). I waited for some time for a first
>> command, than Ctrl+C it. After it replay.bin was 4M. Than started the second command. It
>> works, not failing, not finishing. Is it bad? What is expected behavior and what is wrong?
>
> The second command should finish. There is no replay introspection yet (in master), but you can
> stop qemu with gdb and inspect replay_state.current_icount field. It should increase with every
> virtual CPU instruction execution. If that counter has stopped, it means that replay hangs.
It hangs for me even with QCOW2_MAX_WORKERS = 1..
>
>>>> What is exactly the case? May be you have other parallel aio
>>>> operations to the same region?
>>>
>>> As far as I understand, all aio operations, initiated by IDE controller, are performed one-
>> by-one.
>>> I don't see anything else in the logs.
>>>
>>>> Ideas to experiment:
>>>>
>>>> 1. change QCOW2_MAX_WORKERS to 1 or to 2, will it help?
>>>
>>> 1 or 2 are ok, and 4 or 8 lead to the failures.
>>>
>>>> 2. understand what is the case in code: is it read from one or several
>>>> clusters, is it aligned,
>>>> what is the type of clusters, is encryption in use, compression?
>>>
>>> There is no encryption and I thinks compression is not enabled too.
>>> Clusters are read from the temporary overlay:
>>>
>>> blk_aio_prwv
>>> blk_aio_read_entry
>>> bdrv_co_preadv_part complete offset: 26300000 qiov_offset: 1c200 len: 1e00
>>> bdrv_co_preadv_part complete offset: 24723e00 qiov_offset: 0 len: 1c200
>>> bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000
>>> bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000
>>> bdrv_co_preadv_part complete offset: c0393e00 qiov_offset: 0 len: 1e000
>>>
>>>
>>>> 3. understand what kind of data corruption. What we read instead of
>>>> correct data? Just garbage, or may be zeroes, or what..
>>>
>>> Most bytes are the same, but some are different:
>>>
>>> < 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00
>>> < 46 49 4c 45 30 00 03 00 18 d1 33 02 00 00 00 00
>>> < 01 00 01 00 38 00 01 00 68 01 00 00 00 04 00 00
>>> < 00 00 00 00 00 00 00 00 04 00 00 00 9d 0e 00 00
>>> < 02 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00
>>> ---
>>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00
>>>> 46 49 4c 45 30 00 03 00 86 78 35 03 00 00 00 00
>>>> 01 00 01 00 38 00 01 00 60 01 00 00 00 04 00 00
>>>> 00 00 00 00 00 00 00 00 04 00 00 00 a1 0e 00 00
>>>> 04 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00
>>>
>>> That is strange. I could think, that it was caused by the bugs in
>>> deterministic CPU execution, but the first difference in logs
>>> occur in READ operation (I dump read/write buffers in blk_aio_complete).
>>>
>>
>> Aha, yes, looks strange.
>>
>> Then next steps:
>>
>> 1. Does problem hit into the same offset every time?
>
> Yes, almost the same offset, almost the same phase of the execution.
>
>> 2. Do we write to this region before this strange read?
>
> No.
>
>> 2.1. If yes, we need to check that we read what we write.. You say you dump buffers
>> in blk_aio_complete... I think it would be more reliable to dump at start of
>> bdrv_co_pwritev and at end of bdrv_co_preadv. Also, guest may modify its buffers
>> during operation which would be strange but possible.
>
> I dumped every write in file-posix.c handle_aiocb_rw_linear and qemu_pwritev
> and found no difference in executions.
>
>> 2.2 If not, hmm...
>
> Exactly.
>
> Pavel Dovgalyuk
>
--
Best regards,
Vladimir
^ 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.