* Re: [tip: core/objtool] objtool: Fail the kernel build on fatal errors
From: Nick Desaulniers @ 2020-02-20 19:09 UTC (permalink / raw)
To: Philip Li; +Cc: Chen Rong, clang-built-linux
In-Reply-To: <20200220004434.GA5687@intel.com>
(everyone else to bcc)
On Wed, Feb 19, 2020 at 4:44 PM Philip Li <philip.li@intel.com> wrote:
>
> On Wed, Feb 19, 2020 at 02:43:39PM -0800, Nick Desaulniers wrote:
> > On Fri, Feb 14, 2020 at 9:58 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > >
> > > On Fri, Feb 14, 2020 at 01:10:26AM +0100, Thomas Gleixner wrote:
> > > > Josh Poimboeuf <jpoimboe@redhat.com> writes:
> > > > > On Tue, Feb 11, 2020 at 12:47:38PM -0000, tip-bot2 for Josh Poimboeuf wrote:
> > > > >> The following commit has been merged into the core/objtool branch of tip:
> > > > >>
> > > > >> Commit-ID: 644592d328370af4b3e027b7b1ae9f81613782d8
> > > > >> Gitweb: https://git.kernel.org/tip/644592d328370af4b3e027b7b1ae9f81613782d8
> > > > >> Author: Josh Poimboeuf <jpoimboe@redhat.com>
> > > > >> AuthorDate: Mon, 10 Feb 2020 12:32:38 -06:00
> > > > >> Committer: Borislav Petkov <bp@suse.de>
> > > > >> CommitterDate: Tue, 11 Feb 2020 13:27:03 +01:00
> > > > >>
> > > > >> objtool: Fail the kernel build on fatal errors
> > > > >>
> > > > >> When objtool encounters a fatal error, it usually means the binary is
> > > > >> corrupt or otherwise broken in some way. Up until now, such errors were
> > > > >> just treated as warnings which didn't fail the kernel build.
> > > > >>
> > > > >> However, objtool is now stable enough that if a fatal error is
> > > > >> discovered, it most likely means something is seriously wrong and it
> > > > >> should fail the kernel build.
> > > > >>
> > > > >> Note that this doesn't apply to "normal" objtool warnings; only fatal
> > > > >> ones.
> > > > >
> > > > > Clang still has some toolchain issues which need to be sorted out, so
> > > > > upgrading the fatal errors is causing their CI to fail.
> > > >
> > > > Good. Last time we made it fail they just fixed their stuff.
> > > >
> > > > > So I think we need to drop this one for now.
> > > >
> > > > Why? It's our decision to define which level of toolchain brokeness is
> > > > tolerable.
> > > >
> > > > > Boris, are you able to just drop it or should I send a revert?
> > > >
> > > > I really want to see a revert which has a proper justification why the
> > > > issues of clang are tolerable along with a clear statement when this
> > > > fatal error will come back. And 'when' means a date, not 'when clang is
> > > > fixed'.
> > >
> > > Fair enough. The root cause was actually a bug in binutils which gets
> > > triggered by a new clang feature. So instead of reverting the above
> > > patch, I think I've figured out a way to work around the binutils bug,
> > > while also improving objtool at the same time (win-win).
> > >
> > > The binutils bug will be fixed in binutils 2.35.
> > >
> > > BTW, to be fair, this was less "Clang has issues" and more "Josh is
> > > lazy". I didn't test the patch with Clang -- I tend to rely on 0-day
> > > bot reports because I don't have the bandwidth to test the
> > > kernel/config/toolchain combinations. Nick tells me Clang will soon be
> > > integrated with the 0-day bot, which should help prevent this type of
> > > thing in the future.
> >
> > Hi Rong, Philip,
> > Do you have any status updates on turning on the 0day bot emails to
> > the patch authors in production? It's been quite handy in helping us
> > find issues, for the private mails we've been triaging daily.
> Hi Nick, this is on our schedule in a new 2-3 weeks, sorry not to update
> your in another mail loop earlier.
No worries.
>
> What I plan to do is to cc you for the clang reports when 0-day ci sends
> to kernel patch author. If you notice something may be related to clang (since
> we always integrate newer clang version), you can help filter it out. How
> do you think?
If you would kindly cc our mailing list "clang-built-linux
<clang-built-linux@googlegroups.com>" we'd be happy to continue to
triage and provide suggestions. That level of indirection better
allows us to deal with subscriptions and change of email addresses
without having to disturb you.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v2 2/4] drm/ast: Use simple encoder
From: Sam Ravnborg @ 2020-02-20 19:09 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: airlied, dri-devel, maarten.lankhorst, mripard, virtualization,
noralf, daniel, alexander.deucher, spice-devel, emil.velikov
In-Reply-To: <20200218084815.2137-3-tzimmermann@suse.de>
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:13AM +0100, Thomas Zimmermann wrote:
> The ast driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
From browsign the code - looks good:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
> ---
> drivers/gpu/drm/ast/ast_drv.h | 6 +-----
> drivers/gpu/drm/ast/ast_mode.c | 25 ++++++++-----------------
> 2 files changed, 9 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index f5d8780776ae..656d591b154b 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -121,6 +121,7 @@ struct ast_private {
> unsigned int next_index;
> } cursor;
>
> + struct drm_encoder encoder;
> struct drm_plane primary_plane;
> struct drm_plane cursor_plane;
>
> @@ -238,13 +239,8 @@ struct ast_crtc {
> u8 offset_x, offset_y;
> };
>
> -struct ast_encoder {
> - struct drm_encoder base;
> -};
> -
> #define to_ast_crtc(x) container_of(x, struct ast_crtc, base)
> #define to_ast_connector(x) container_of(x, struct ast_connector, base)
> -#define to_ast_encoder(x) container_of(x, struct ast_encoder, base)
>
> struct ast_vbios_stdtable {
> u8 misc;
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 562ea6d9df13..7a9f20a2fd30 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -40,6 +40,7 @@
> #include <drm/drm_gem_vram_helper.h>
> #include <drm/drm_plane_helper.h>
> #include <drm/drm_probe_helper.h>
> +#include <drm/drm_simple_kms_helper.h>
>
> #include "ast_drv.h"
> #include "ast_tables.h"
> @@ -968,28 +969,18 @@ static int ast_crtc_init(struct drm_device *dev)
> * Encoder
> */
>
> -static void ast_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> - kfree(encoder);
> -}
> -
> -static const struct drm_encoder_funcs ast_enc_funcs = {
> - .destroy = ast_encoder_destroy,
> -};
> -
> static int ast_encoder_init(struct drm_device *dev)
> {
> - struct ast_encoder *ast_encoder;
> + struct ast_private *ast = dev->dev_private;
> + struct drm_encoder *encoder = &ast->encoder;
> + int ret;
>
> - ast_encoder = kzalloc(sizeof(struct ast_encoder), GFP_KERNEL);
> - if (!ast_encoder)
> - return -ENOMEM;
> + ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
> + if (ret)
> + return ret;
>
> - drm_encoder_init(dev, &ast_encoder->base, &ast_enc_funcs,
> - DRM_MODE_ENCODER_DAC, NULL);
> + encoder->possible_crtcs = 1;
>
> - ast_encoder->base.possible_crtcs = 1;
> return 0;
> }
>
> --
> 2.25.0
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for sw_sync: Use fixed runtime for sync_expired_merge
From: Patchwork @ 2020-02-20 19:09 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20200220165721.2056191-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: sw_sync: Use fixed runtime for sync_expired_merge
URL : https://patchwork.freedesktop.org/series/73724/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7975 -> IGTPW_4201
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/index.html
Known issues
------------
Here are the changes found in IGTPW_4201 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_addfb_basic@addfb25-x-tiled-mismatch:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402]) +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-y/igt@kms_addfb_basic@addfb25-x-tiled-mismatch.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-tgl-y/igt@kms_addfb_basic@addfb25-x-tiled-mismatch.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][3] -> [DMESG-WARN][4] ([i915#44])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
#### Possible fixes ####
* igt@gem_close_race@basic-threads:
- fi-hsw-4770r: [TIMEOUT][5] ([fdo#112271] / [i915#1084]) -> [PASS][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-hsw-4770r/igt@gem_close_race@basic-threads.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-hsw-4770r/igt@gem_close_race@basic-threads.html
- fi-byt-n2820: [INCOMPLETE][7] ([i915#45]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-byt-n2820/igt@gem_close_race@basic-threads.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-byt-n2820/igt@gem_close_race@basic-threads.html
* igt@i915_selftest@live_execlists:
- fi-icl-y: [DMESG-FAIL][9] ([fdo#108569]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-icl-y/igt@i915_selftest@live_execlists.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-icl-y/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [FAIL][11] ([i915#262]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-cml-u2/igt@kms_chamelium@dp-crc-fast.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-cml-u2/igt@kms_chamelium@dp-crc-fast.html
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [DMESG-WARN][13] ([CI#94] / [i915#402]) -> [PASS][14] +1 similar issue
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
#### Warnings ####
* igt@i915_selftest@live_gt_lrc:
- fi-tgl-y: [DMESG-FAIL][15] ([CI#94] / [i915#1233]) -> [INCOMPLETE][16] ([CI#94] / [i915#1233])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-y/igt@i915_selftest@live_gt_lrc.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-tgl-y/igt@i915_selftest@live_gt_lrc.html
* igt@runner@aborted:
- fi-tgl-y: [FAIL][17] ([CI#94] / [i915#529] / [i915#584]) -> [FAIL][18] ([CI#94] / [i915#584])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-y/igt@runner@aborted.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/fi-tgl-y/igt@runner@aborted.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#529]: https://gitlab.freedesktop.org/drm/intel/issues/529
[i915#584]: https://gitlab.freedesktop.org/drm/intel/issues/584
Participating hosts (47 -> 44)
------------------------------
Additional (4): fi-glk-dsi fi-bwr-2160 fi-snb-2520m fi-kbl-r
Missing (7): fi-ilk-m540 fi-tgl-u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4201
CI-20190529: 20190529
CI_DRM_7975: f66891f7bdc3c60bb6f06fd6bc0718a0bd975896 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4201: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4201/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v2 2/4] drm/ast: Use simple encoder
From: Sam Ravnborg @ 2020-02-20 19:09 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: airlied, dri-devel, virtualization, kraxel, alexander.deucher,
spice-devel, emil.velikov
In-Reply-To: <20200218084815.2137-3-tzimmermann@suse.de>
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:13AM +0100, Thomas Zimmermann wrote:
> The ast driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
From browsign the code - looks good:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
> ---
> drivers/gpu/drm/ast/ast_drv.h | 6 +-----
> drivers/gpu/drm/ast/ast_mode.c | 25 ++++++++-----------------
> 2 files changed, 9 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index f5d8780776ae..656d591b154b 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -121,6 +121,7 @@ struct ast_private {
> unsigned int next_index;
> } cursor;
>
> + struct drm_encoder encoder;
> struct drm_plane primary_plane;
> struct drm_plane cursor_plane;
>
> @@ -238,13 +239,8 @@ struct ast_crtc {
> u8 offset_x, offset_y;
> };
>
> -struct ast_encoder {
> - struct drm_encoder base;
> -};
> -
> #define to_ast_crtc(x) container_of(x, struct ast_crtc, base)
> #define to_ast_connector(x) container_of(x, struct ast_connector, base)
> -#define to_ast_encoder(x) container_of(x, struct ast_encoder, base)
>
> struct ast_vbios_stdtable {
> u8 misc;
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 562ea6d9df13..7a9f20a2fd30 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -40,6 +40,7 @@
> #include <drm/drm_gem_vram_helper.h>
> #include <drm/drm_plane_helper.h>
> #include <drm/drm_probe_helper.h>
> +#include <drm/drm_simple_kms_helper.h>
>
> #include "ast_drv.h"
> #include "ast_tables.h"
> @@ -968,28 +969,18 @@ static int ast_crtc_init(struct drm_device *dev)
> * Encoder
> */
>
> -static void ast_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> - kfree(encoder);
> -}
> -
> -static const struct drm_encoder_funcs ast_enc_funcs = {
> - .destroy = ast_encoder_destroy,
> -};
> -
> static int ast_encoder_init(struct drm_device *dev)
> {
> - struct ast_encoder *ast_encoder;
> + struct ast_private *ast = dev->dev_private;
> + struct drm_encoder *encoder = &ast->encoder;
> + int ret;
>
> - ast_encoder = kzalloc(sizeof(struct ast_encoder), GFP_KERNEL);
> - if (!ast_encoder)
> - return -ENOMEM;
> + ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
> + if (ret)
> + return ret;
>
> - drm_encoder_init(dev, &ast_encoder->base, &ast_enc_funcs,
> - DRM_MODE_ENCODER_DAC, NULL);
> + encoder->possible_crtcs = 1;
>
> - ast_encoder->base.possible_crtcs = 1;
> return 0;
> }
>
> --
> 2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: is hibernation usable?
From: Chris Murphy @ 2020-02-20 19:09 UTC (permalink / raw)
To: Luigi Semenzato; +Cc: Linux Memory Management List, Linux PM
In-Reply-To: <CAA25o9T2wwqoopoNRySdZoYkD+vtqRPsB1YPnag=TkOp5D9sYA@mail.gmail.com>
On Thu, Feb 20, 2020 at 10:16 AM Luigi Semenzato <semenzato@google.com> wrote:
>
> I think this is the right group for the memory issues.
>
> I suspect that the problem with failed allocations (ENOMEM) boils down
> to the unreliability of the page allocator. In my experience, under
> pressure (i.e. pages must be swapped out to be reclaimed) allocations
> can fail even when in theory they should succeed. (I wish I were
> wrong and that someone would convincingly correct me.)
What is vm.swappiness set to on your system? A fellow Fedora
contributor who has consistently reproduced what you describe, has
discovered he has vm.swappiness=0, and even if it's set to 1, the
problem no longer happens. And this is not a documented consequence of
using a value of 0.
> I have a workaround in which I use memcgroups to free pages before
> starting hibernation. The cgroup request "echo $limit >
> .../memory.limit_in_bytes" blocks until memory usage in the chosen
> cgroup is below $limit. However, I have seen this request fail even
> when there is extra available swap space.
>
> The callback for the operation is mem_cgroup_resize_limit() (BTW I am
> looking at kernel version 4.3.5) and that code has a loop where
> try_to_free_pages() is called up to retry_count, which is at least 5.
> Why 5? One suspects that the writer of that code must have also
> realized that the page freeing request is unreliable and it's worth
> trying multiple times.
>
> So you could try something similar. I don't know if there are
> interfaces to try_to_free_pages() other than those in cgroups. If
> not, and you aren't using cgroups, one way might be to start several
> memory-eating processes (such as "dd if=/dev/zero bs=1G count=1 |
> sleep infinity") and monitor allocation, then when they use more than
> 50% of RAM kill them and immediately hibernate before the freed pages
> are reused. If you can build your custom kernel, maybe it's worth
> adding a sysfs entry to invoke try_to_free_pages(). You could also
> change the hibernation code to do that, but having the user-level hook
> may be more flexible.
Fedora 31+ now uses cgroupsv2. In any case, my use case is making sure
this works correctly, sanely, with mainline kernels because Fedora
doesn't do custom things with the kernel.
--
Chris Murphy
^ permalink raw reply
* [igt-dev] ✗ GitLab.Pipeline: warning for lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support (rev3)
From: Patchwork @ 2020-02-20 19:10 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev
In-Reply-To: <20200220173056.23088-1-janusz.krzysztofik@linux.intel.com>
== Series Details ==
Series: lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support (rev3)
URL : https://patchwork.freedesktop.org/series/73719/
State : warning
== Summary ==
Did not get list of undocumented tests for this run, something is wrong!
Other than that, pipeline status: FAILED.
see https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/110989 for the overview.
build-containers:build-debian-mips has failed (https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/1690042):
^[[0KRunning with gitlab-runner 12.6.0 (ac8e767a)
^[[0;m^[[0K on gst-gitlab-htz-runner7 eBGGUWcX
^[[0;msection_start:1582225738:prepare_executor
^[[0K^[[0KUsing Docker executor with image registry.freedesktop.org/wayland/ci-templates/buildah:2019-08-13.0 ...
^[[0;m^[[0KAuthenticating with credentials from job payload (GitLab Registry)
^[[0;m^[[0KPulling docker image registry.freedesktop.org/wayland/ci-templates/buildah:2019-08-13.0 ...
^[[0;m^[[0KUsing docker image sha256:594aa868d31ee3304dee8cae8a3433c89a6fcfcf6c7d420c04cce22f60147176 for registry.freedesktop.org/wayland/ci-templates/buildah:2019-08-13.0 ...
^[[0;msection_end:1582225740:prepare_executor
^[[0Ksection_start:1582225740:prepare_script
^[[0KRunning on runner-eBGGUWcX-project-3185-concurrent-1 via gst-gitlab-htz-runner7...
section_end:1582225741:prepare_script
^[[0Ksection_start:1582225741:get_sources
^[[0Ksection_end:1582225741:get_sources
^[[0Ksection_start:1582225741:upload_artifacts_on_failure
^[[0Ksection_end:1582225743:upload_artifacts_on_failure
^[[0K^[[31;1mERROR: Job failed (system failure): Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/56cce20ad06e949191451b0b18948701ff4ae79facfa8b339fac38a7a4359952/merged: device or resource busy (executor_docker.go:742:0s)
^[[0;m
== Logs ==
For more details see: https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/110989
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v2 4/4] drm/qxl: Use simple encoder
From: Sam Ravnborg @ 2020-02-20 19:10 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: airlied, dri-devel, maarten.lankhorst, mripard, virtualization,
noralf, daniel, alexander.deucher, spice-devel, emil.velikov
In-Reply-To: <20200218084815.2137-5-tzimmermann@suse.de>
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:15AM +0100, Thomas Zimmermann wrote:
> The qxl driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
I looked at best_encoder - but could not see we could do anything.
So from browsing the code:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 18 +++---------------
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
> index ab4f8dd00400..9c0e1add59fb 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -31,6 +31,7 @@
> #include <drm/drm_gem_framebuffer_helper.h>
> #include <drm/drm_plane_helper.h>
> #include <drm/drm_probe_helper.h>
> +#include <drm/drm_simple_kms_helper.h>
>
> #include "qxl_drv.h"
> #include "qxl_object.h"
> @@ -1007,9 +1008,6 @@ static struct drm_encoder *qxl_best_encoder(struct drm_connector *connector)
> return &qxl_output->enc;
> }
>
> -static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {
> -};
> -
> static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
> .get_modes = qxl_conn_get_modes,
> .mode_valid = qxl_conn_mode_valid,
> @@ -1059,15 +1057,6 @@ static const struct drm_connector_funcs qxl_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static void qxl_enc_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs qxl_enc_funcs = {
> - .destroy = qxl_enc_destroy,
> -};
> -
> static int qxl_mode_create_hotplug_mode_update_property(struct qxl_device *qdev)
> {
> if (qdev->hotplug_mode_update_property)
> @@ -1098,15 +1087,14 @@ static int qdev_output_init(struct drm_device *dev, int num_output)
> drm_connector_init(dev, &qxl_output->base,
> &qxl_connector_funcs, DRM_MODE_CONNECTOR_VIRTUAL);
>
> - drm_encoder_init(dev, &qxl_output->enc, &qxl_enc_funcs,
> - DRM_MODE_ENCODER_VIRTUAL, NULL);
> + drm_simple_encoder_init(dev, &qxl_output->enc,
> + DRM_MODE_ENCODER_VIRTUAL);
>
> /* we get HPD via client monitors config */
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> encoder->possible_crtcs = 1 << num_output;
> drm_connector_attach_encoder(&qxl_output->base,
> &qxl_output->enc);
> - drm_encoder_helper_add(encoder, &qxl_enc_helper_funcs);
> drm_connector_helper_add(connector, &qxl_connector_helper_funcs);
>
> drm_object_attach_property(&connector->base,
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH v2 4/4] drm/qxl: Use simple encoder
From: Sam Ravnborg @ 2020-02-20 19:10 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: airlied, dri-devel, virtualization, kraxel, alexander.deucher,
spice-devel, emil.velikov
In-Reply-To: <20200218084815.2137-5-tzimmermann@suse.de>
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:15AM +0100, Thomas Zimmermann wrote:
> The qxl driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
I looked at best_encoder - but could not see we could do anything.
So from browsing the code:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 18 +++---------------
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
> index ab4f8dd00400..9c0e1add59fb 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -31,6 +31,7 @@
> #include <drm/drm_gem_framebuffer_helper.h>
> #include <drm/drm_plane_helper.h>
> #include <drm/drm_probe_helper.h>
> +#include <drm/drm_simple_kms_helper.h>
>
> #include "qxl_drv.h"
> #include "qxl_object.h"
> @@ -1007,9 +1008,6 @@ static struct drm_encoder *qxl_best_encoder(struct drm_connector *connector)
> return &qxl_output->enc;
> }
>
> -static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {
> -};
> -
> static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
> .get_modes = qxl_conn_get_modes,
> .mode_valid = qxl_conn_mode_valid,
> @@ -1059,15 +1057,6 @@ static const struct drm_connector_funcs qxl_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static void qxl_enc_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs qxl_enc_funcs = {
> - .destroy = qxl_enc_destroy,
> -};
> -
> static int qxl_mode_create_hotplug_mode_update_property(struct qxl_device *qdev)
> {
> if (qdev->hotplug_mode_update_property)
> @@ -1098,15 +1087,14 @@ static int qdev_output_init(struct drm_device *dev, int num_output)
> drm_connector_init(dev, &qxl_output->base,
> &qxl_connector_funcs, DRM_MODE_CONNECTOR_VIRTUAL);
>
> - drm_encoder_init(dev, &qxl_output->enc, &qxl_enc_funcs,
> - DRM_MODE_ENCODER_VIRTUAL, NULL);
> + drm_simple_encoder_init(dev, &qxl_output->enc,
> + DRM_MODE_ENCODER_VIRTUAL);
>
> /* we get HPD via client monitors config */
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> encoder->possible_crtcs = 1 << num_output;
> drm_connector_attach_encoder(&qxl_output->base,
> &qxl_output->enc);
> - drm_encoder_helper_add(encoder, &qxl_enc_helper_funcs);
> drm_connector_helper_add(connector, &qxl_connector_helper_funcs);
>
> drm_object_attach_property(&connector->base,
> --
> 2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] media: tegra: Add Tegra210 Video input driver
From: Sowjanya Komatineni @ 2020-02-20 19:11 UTC (permalink / raw)
To: Hans Verkuil, thierry.reding, jonathanh, frankc, helen.koike,
sboyd
Cc: linux-media, devicetree, linux-clk, linux-tegra, linux-kernel
In-Reply-To: <dc592f29-3109-d10c-7df7-ffdb2755ade0@xs4all.nl>
On 2/20/20 5:33 AM, Hans Verkuil wrote:
> External email: Use caution opening links or attachments
>
>
> (Replying to myself so I can explain this a bit more)
>
> On 2/20/20 1:44 PM, Hans Verkuil wrote:
>>> +
>>> +static int tegra_csi_tpg_channels_alloc(struct tegra_csi *csi)
>>> +{
>>> + struct device_node *node = csi->dev->of_node;
>>> + unsigned int port_num;
>>> + int ret;
>>> + struct tegra_csi_channel *item;
>>> + unsigned int tpg_channels = csi->soc->csi_max_channels;
>>> +
>>> + /* allocate CSI channel for each CSI x2 ports */
>>> + for (port_num = 0; port_num < tpg_channels; port_num++) {
>>> + item = devm_kzalloc(csi->dev, sizeof(*item), GFP_KERNEL);
>> Using devm_*alloc can be dangerous. If someone unbinds the driver, then
>> all memory allocated with devm_ is immediately freed. But if an application
>> still has a filehandle open, then when it closes it it might still reference
>> this already-freed memory.
>>
>> I recommend that you avoid using devm_*alloc for media drivers.
> A good test is to unbind & bind the driver:
>
> cd /sys/devices/platform/50000000.host1x/54080000.vi/driver
> echo -n 54080000.vi >unbind
> echo -n 54080000.vi >bind
>
> First just do this without the driver being used. That already
> gives me 'list_del corruption' kernel messages (list debugging
> is turned on in my kernel).
>
> Note that this first test is basically identical to a rmmod/modprobe
> of the driver. But when I compiled the driver as a module it didn't
> create any video device nodes! Nor did I see any errors in the kernel
> log. I didn't pursue this, and perhaps I did something wrong, but it's
> worth taking a look at.
>
> The next step would be to have a video node open with:
>
> v4l2-ctl --sleep 10
>
> then while it is sleeping unbind the driver and see what happens
> when v4l2-ctl exits.
>
> Worst case is when you are streaming:
>
> v4l2-ctl --stream-mmap
>
> and then unbind.
>
> In general, the best way to get this to work correctly is:
>
> 1) don't use devm_*alloc
> 2) set the release callback of struct v4l2_device and do all freeing there.
> 3) in the platform remove() callback you call media_device_unregister()
> and video_unregister_device().
Reg 3, in current patch, media_device_unregister is called in
host1x_video_remove
video_unregister_device happens during host1x_video_remove ->
host1x_device_exit -> tegra_vi_exit -> tegra_vi_channels_cleanup
> It's worth getting this right in this early stage, rather than fixing it
> in the future.
>
> Regards,
>
> Hans
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] media: tegra: Add Tegra210 Video input driver
From: Sowjanya Komatineni @ 2020-02-20 19:11 UTC (permalink / raw)
To: Hans Verkuil, thierry.reding, jonathanh, frankc, helen.koike,
sboyd
Cc: linux-media, devicetree, linux-clk, linux-tegra, linux-kernel
In-Reply-To: <dc592f29-3109-d10c-7df7-ffdb2755ade0@xs4all.nl>
On 2/20/20 5:33 AM, Hans Verkuil wrote:
> External email: Use caution opening links or attachments
>
>
> (Replying to myself so I can explain this a bit more)
>
> On 2/20/20 1:44 PM, Hans Verkuil wrote:
>>> +
>>> +static int tegra_csi_tpg_channels_alloc(struct tegra_csi *csi)
>>> +{
>>> + struct device_node *node = csi->dev->of_node;
>>> + unsigned int port_num;
>>> + int ret;
>>> + struct tegra_csi_channel *item;
>>> + unsigned int tpg_channels = csi->soc->csi_max_channels;
>>> +
>>> + /* allocate CSI channel for each CSI x2 ports */
>>> + for (port_num = 0; port_num < tpg_channels; port_num++) {
>>> + item = devm_kzalloc(csi->dev, sizeof(*item), GFP_KERNEL);
>> Using devm_*alloc can be dangerous. If someone unbinds the driver, then
>> all memory allocated with devm_ is immediately freed. But if an application
>> still has a filehandle open, then when it closes it it might still reference
>> this already-freed memory.
>>
>> I recommend that you avoid using devm_*alloc for media drivers.
> A good test is to unbind & bind the driver:
>
> cd /sys/devices/platform/50000000.host1x/54080000.vi/driver
> echo -n 54080000.vi >unbind
> echo -n 54080000.vi >bind
>
> First just do this without the driver being used. That already
> gives me 'list_del corruption' kernel messages (list debugging
> is turned on in my kernel).
>
> Note that this first test is basically identical to a rmmod/modprobe
> of the driver. But when I compiled the driver as a module it didn't
> create any video device nodes! Nor did I see any errors in the kernel
> log. I didn't pursue this, and perhaps I did something wrong, but it's
> worth taking a look at.
>
> The next step would be to have a video node open with:
>
> v4l2-ctl --sleep 10
>
> then while it is sleeping unbind the driver and see what happens
> when v4l2-ctl exits.
>
> Worst case is when you are streaming:
>
> v4l2-ctl --stream-mmap
>
> and then unbind.
>
> In general, the best way to get this to work correctly is:
>
> 1) don't use devm_*alloc
> 2) set the release callback of struct v4l2_device and do all freeing there.
> 3) in the platform remove() callback you call media_device_unregister()
> and video_unregister_device().
Reg 3, in current patch, media_device_unregister is called in
host1x_video_remove
video_unregister_device happens during host1x_video_remove ->
host1x_device_exit -> tegra_vi_exit -> tegra_vi_channels_cleanup
> It's worth getting this right in this early stage, rather than fixing it
> in the future.
>
> Regards,
>
> Hans
^ permalink raw reply
* Re: crash on connect
From: Jens Axboe @ 2020-02-20 19:12 UTC (permalink / raw)
To: Glauber Costa; +Cc: io-uring, Avi Kivity
In-Reply-To: <CAD-J=zbdrZJ2nKgH3Ob=QAAM9Ci439T9DduNxvetK9B_52LDOQ@mail.gmail.com>
On 2/20/20 11:45 AM, Glauber Costa wrote:
> On Thu, Feb 20, 2020 at 12:28 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 2/20/20 9:52 AM, Glauber Costa wrote:
>>> On Thu, Feb 20, 2020 at 11:39 AM Jens Axboe <axboe@kernel.dk> wrote:
>>>>
>>>> On 2/20/20 9:34 AM, Glauber Costa wrote:
>>>>> On Thu, Feb 20, 2020 at 11:29 AM Jens Axboe <axboe@kernel.dk> wrote:
>>>>>>
>>>>>> On 2/20/20 9:17 AM, Jens Axboe wrote:
>>>>>>> On 2/20/20 7:19 AM, Glauber Costa wrote:
>>>>>>>> Hi there, me again
>>>>>>>>
>>>>>>>> Kernel is at 043f0b67f2ab8d1af418056bc0cc6f0623d31347
>>>>>>>>
>>>>>>>> This test is easier to explain: it essentially issues a connect and a
>>>>>>>> shutdown right away.
>>>>>>>>
>>>>>>>> It currently fails due to no fault of io_uring. But every now and then
>>>>>>>> it crashes (you may have to run more than once to get it to crash)
>>>>>>>>
>>>>>>>> Instructions are similar to my last test.
>>>>>>>> Except the test to build is now "tests/unit/connect_test"
>>>>>>>> Code is at git@github.com:glommer/seastar.git branch io-uring-connect-crash
>>>>>>>>
>>>>>>>> Run it with ./build/release/tests/unit/connect_test -- -c1
>>>>>>>> --reactor-backend=uring
>>>>>>>>
>>>>>>>> Backtrace attached
>>>>>>>
>>>>>>> Perfect thanks, I'll take a look!
>>>>>>
>>>>>> Haven't managed to crash it yet, but every run complains:
>>>>>>
>>>>>> got to shutdown of 10 with refcnt: 2
>>>>>> Refs being all dropped, calling forget for 10
>>>>>> terminate called after throwing an instance of 'fmt::v6::format_error'
>>>>>> what(): argument index out of range
>>>>>> unknown location(0): fatal error: in "unixdomain_server": signal: SIGABRT (application abort requested)
>>>>>>
>>>>>> Not sure if that's causing it not to fail here.
>>>>>
>>>>> Ok, that means it "passed". (I was in the process of figuring out
>>>>> where I got this wrong when I started seeing the crashes)
>>>>
>>>> Can you do, in your kernel dir:
>>>>
>>>> $ gdb vmlinux
>>>> [...]
>>>> (gdb) l *__io_queue_sqe+0x4a
>>>>
>>>> and see what it says?
>>>
>>> 0xffffffff81375ada is in __io_queue_sqe (fs/io_uring.c:4814).
>>> 4809 struct io_kiocb *linked_timeout;
>>> 4810 struct io_kiocb *nxt = NULL;
>>> 4811 int ret;
>>> 4812
>>> 4813 again:
>>> 4814 linked_timeout = io_prep_linked_timeout(req);
>>> 4815
>>> 4816 ret = io_issue_sqe(req, sqe, &nxt, true);
>>> 4817
>>> 4818 /*
>>>
>>> (I am not using timeouts, just async_cancel)
>>
>> Can't seem to hit it here, went through thousands of iterations...
>> I'll keep trying.
>>
>> If you have time, you can try and enable CONFIG_KASAN=y and see if
>> you can hit it with that.
>
> I can
>
> Attaching full dmesg
Can you try the latest? It's sha d8154e605f84. Before you do, can you
do the lookup on __io_queue_sqe+0x639 with gdb?
--
Jens Axboe
^ permalink raw reply
* Re: [External] Re: [PATCH] thinkpad_acpi: Add sysfs entry for lcdshadow feature
From: Rajat Jain @ 2020-02-20 19:13 UTC (permalink / raw)
To: Mark Pearson
Cc: Andy Shevchenko, Nitin Joshi, Mat King, Jani Nikula,
Daniel Thompson, Jingoo Han, Henrique de Moraes Holschuh,
Darren Hart, Andy Shevchenko, Thinkpad-acpi devel ML,
Platform Driver, Nitin Joshi1, Benjamin Berg,
Linux Kernel Mailing List, dri-devel, Greg Kroah-Hartman
In-Reply-To: <PS1PR0302MB260492DDE243BE0A64A39AA7BD130@PS1PR0302MB2604.apcprd03.prod.outlook.com>
Hi Mark,
On Thu, Feb 20, 2020 at 11:03 AM Mark Pearson <mpearson@lenovo.com> wrote:
>
> Hi Rajat,
>
> > -----Original Message-----
> > From: Rajat Jain <rajatja@google.com>
> > Sent: Thursday, February 20, 2020 1:39 PM
> > >
> > > For this particular issue what is the best way to contribute and get
> > > involved? We'd like to make it so ePrivacy can be used more easily from
> > > Linux. I agree a more generic way of controlling it would be good.
> > > I looked at the proposed patch from Rajat
> > > (https://lkml.org/lkml/2019/10/22/967) - it seems like a good solution to me.
> > > We can help with testing that on our platforms if that would be useful.
> >
> > Thanks you, just so that you know, the latest patchset is at:
> > https://lkml.org/lkml/2019/12/20/794
> >
> > It would be great to get some additional testing if possible. I can
> > send a sample ACPI (for our platform) in case it helps.
> >
> Sounds good - we'll definitely try this out and see how it goes. I suspect we'll have some questions once we try it out and get more familiar.
>
> > >
> > > I need to understand how we connect that implementation with the ACPI
> > > controls we have (as I believe what we have are thinkpad specific and not to
> > > a drm spec; we need to confirm that). We also have the ACPI events that
> > > notify if ePrivacy was changed by the hotkeys and that seems like something
> > > that should be done in thinkpad_acpi.c and not the drm code.
> > >
> > > Not sure if the two need to be connected somehow (or if handling the
> > > event is actually not important and polling is acceptable)?
> >
> > So there was some brief discussion about this on my patches - but
> > atleast on the platforms I have seen, there was no way to change the
> > privacy screen out of software / kernel control. Essentially, if there
> > are hotkeys, they would send an input event to the kernel, who'd send
> > them to userspace, who'd use the DRM method to toggle the privacy
> > screen. Thus the current version of the patch only supports
> > controlling the privacy screen via set() method. The get() method just
> > returns the cached value.I hope that works for you.
> >
> OK - on the thinkpads we have function+D as a 'hotkey' to control the feature...and my understanding is that bypasses everything and goes straight to the firmware.
>
> The changes Nitin had been working on in thinkpad_acpi.c was to make this more Linux and friendly - provide a sysfs hook for user space to connect to with the aim of allowing it to be configured from user space and have on screen display when it was triggered etc.
>
> I'm personally not sure yet how this ties up with the DRM method - more digging required. I'm intrigued to see if it works on our systems (sadly I don't have anything with that feature available on my desk right now...I need to get my hands on one)
Just FYI, Here is the brief discussion we had about an interrupt
mechanism to support a (hardware based) "kill switch" for the privacy
screen.
https://lkml.org/lkml/2019/10/25/992
Thanks,
Rajat
>
> Thanks
> Mark
^ permalink raw reply
* Re: [PATCH v6 2/7] mm: introduce external memory hinting API
From: kbuild test robot @ 2020-02-20 19:13 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20200219014433.88424-3-minchan@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 5129 bytes --]
Hi Minchan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on m68k/for-next]
[also build test WARNING on powerpc/next s390/features linus/master v5.6-rc2 next-20200220]
[cannot apply to arm64/for-next/core tip/x86/asm arm/for-next hp-parisc/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Minchan-Kim/introduce-memory-hinting-API-for-external-process/20200220-225155
base: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-next
config: nds32-randconfig-a001-20200220 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.2.0 make.cross ARCH=nds32
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from arch/nds32/kernel/vdso/sigreturn.S:6:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
--
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from <stdin>:2:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
>> <stdin>:1520:2: warning: #warning syscall process_madvise not implemented [-Wcpp]
--
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from <stdin>:2:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
>> <stdin>:1520:2: warning: #warning syscall process_madvise not implemented [-Wcpp]
16 real 2 user 4 sys 39.01% cpu make modules_prepare
--
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from <stdin>:2:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
>> <stdin>:1520:2: warning: #warning syscall process_madvise not implemented [-Wcpp]
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from arch/nds32/kernel/vdso/sigreturn.S:6:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from arch/nds32/kernel/vdso/gettimeofday.c:11:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
17 real 4 user 6 sys 59.28% cpu make prepare
vim +/__NR_pidfd_getfd +858 include/uapi/asm-generic/unistd.h
853
854 #define __NR_openat2 437
855 __SYSCALL(__NR_openat2, sys_openat2)
856 #define __NR_pidfd_getfd 438
857 __SYSCALL(__NR_pidfd_getfd, sys_pidfd_getfd)
> 858 #define __NR_pidfd_getfd 439
859 __SYSCALL(__NR_process_madvise, sys_process_madvise)
860
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 24985 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: sun4i-tcon: Add LVDS Dual Link property
From: Laurent Pinchart @ 2020-02-20 19:13 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, dri-devel, Maarten Lankhorst, Sean Paul,
Daniel Vetter, David Airlie, devicetree, Mark Rutland,
Rob Herring, Frank Rowand, linux-arm-kernel
In-Reply-To: <20200220175307.qool442lm7qjqb5h@gilmour.lan>
Hi Maxime,
On Thu, Feb 20, 2020 at 06:53:07PM +0100, Maxime Ripard wrote:
> On Mon, Feb 17, 2020 at 08:10:06PM +0200, Laurent Pinchart wrote:
> > On Mon, Feb 17, 2020 at 06:42:53PM +0100, Maxime Ripard wrote:
> >> On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb 14, 2020 at 04:44:05PM +0100, Maxime Ripard wrote:
> >>>> On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote:
> >>>>> On Fri, Feb 14, 2020 at 01:32:43PM +0100, Maxime Ripard wrote:
> >>>>>> SoCs that have multiple TCONs can use the two set of pins on the first TCON
> >>>>>> to drive a dual-link display. Add a property to enable the dual link.
> >>>>>>
> >>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>>>> ---
> >>>>>> .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 7 +++++++
> >>>>>> 1 file changed, 7 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> index 86ad617d2327..aa6dd8409dbc 100644
> >>>>>> --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> @@ -105,6 +105,13 @@ properties:
> >>>>>> - const: edp
> >>>>>> - const: lvds
> >>>>>>
> >>>>>> + allwinner,lvds-dual-link:
> >>>>>> + type: boolean
> >>>>>> + description: |
> >>>>>> + On a SoC with two TCON with LVDS support, the first TCON can
> >>>>>> + operate over both pins sets to output in a dual-link setup. This
> >>>>>> + will be triggered by setting this property.
> >>>>>
> >>>>> Could you maybe provide an example of how this property is supposed to
> >>>>> be used ? I'm especially wondering what ports are used in that case and
> >>>>> how they're connected.
> >>>>
> >>>> It's pretty trivial to support, it's only a property to set on the
> >>>> encoder node itself.
> >>>>
> >>>> I'm not really sure what you meant by your question with the ports
> >>>> though :/
> >>>
> >>> I assume that, in the single-link case, you have two TCON instances that
> >>> operate independently, each of them with one port that models an LVDS
> >>> connection to a panel.
> >>
> >> Indeed,
> >>
> >>> In the dual-link mode, how does that look like ? Does the TCON
> >>> instance that operate in dual-link mode have two ports in DT ? There
> >>> are two physical ports, so I think it makes sense to always have two
> >>> ports in DT. That's what we're doing for the LVDS encoders on R-Car
> >>> Gen3, in order to specify in DT which LVDS input of the dual-link
> >>> panel is connected to which LVDS output of the SoC. That allows
> >>> configuring the LVDS encoder to send the even and odd pixels on the
> >>> right port.
> >>
> >> As far as I can tell, you can't control that in our TCON. It just on
> >> more lanes, that's it. Also, we currently have multiple ports, to map
> >> another feature of the TCON, which is that it can drive directly a
> >> panel, or will send its output to the HDMI / TV encoders. Adding
> >> another port in that will break the current binding we have.
> >
> > This will create one issue though, in that the dual-link sinks are
> > supposed to have two input ports, in order to expose the odd and even
> > pixels ordering. If you have a single ouput port in your TCON, how will
> > you interface with such sinks ?
>
> I guess we could create multiple endpoints in the same port? That's
> not going to be trivial either though given the current binding we
> have :/
That's however not really how endpoints are supposed to be used.
Let's try to find a solution. Could you show me a DT example that
explains why having two ports would create backward-compatibility issues
?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] media: staging: rkisp1: capture: remove support to userptr memory
From: Helen Koike @ 2020-02-20 19:14 UTC (permalink / raw)
To: Dafna Hirschfeld, linux-media
Cc: ezequiel, hverkuil, kernel, dafna3, sakari.ailus, linux-rockchip,
mchehab
In-Reply-To: <20200220185603.26968-1-dafna.hirschfeld@collabora.com>
On 2/20/20 3:56 PM, Dafna Hirschfeld wrote:
> The dma_contig memory operations which is used by the capture
> should not support userptr. Therefore remove it.
I would just re-word this a bit, something like:
VB2_USERPTR support doesn't make sense for drivers based on
vb2_dma_contig, so just drop it.
Otherwise, queues using vb2_dma_contig_memops causes v4l2-compliance
to fail for VB2_USERPTR mode, due to buffer misalignment.
>
> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
> ---
> drivers/staging/media/rkisp1/rkisp1-capture.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/rkisp1/rkisp1-capture.c b/drivers/staging/media/rkisp1/rkisp1-capture.c
> index 5f97af5cd95f..a006cd03228d 100644
> --- a/drivers/staging/media/rkisp1/rkisp1-capture.c
> +++ b/drivers/staging/media/rkisp1/rkisp1-capture.c
> @@ -1349,7 +1349,7 @@ static int rkisp1_register_capture(struct rkisp1_capture *cap)
>
> q = &node->buf_queue;
> q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> - q->io_modes = VB2_MMAP | VB2_DMABUF | VB2_USERPTR;
> + q->io_modes = VB2_MMAP | VB2_DMABUF;
> q->drv_priv = cap;
> q->ops = &rkisp1_vb2_ops;
> q->mem_ops = &vb2_dma_contig_memops;
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: sun4i-tcon: Add LVDS Dual Link property
From: Laurent Pinchart @ 2020-02-20 19:13 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, David Airlie, dri-devel, Chen-Yu Tsai,
Rob Herring, Sean Paul, Daniel Vetter, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20200220175307.qool442lm7qjqb5h@gilmour.lan>
Hi Maxime,
On Thu, Feb 20, 2020 at 06:53:07PM +0100, Maxime Ripard wrote:
> On Mon, Feb 17, 2020 at 08:10:06PM +0200, Laurent Pinchart wrote:
> > On Mon, Feb 17, 2020 at 06:42:53PM +0100, Maxime Ripard wrote:
> >> On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb 14, 2020 at 04:44:05PM +0100, Maxime Ripard wrote:
> >>>> On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote:
> >>>>> On Fri, Feb 14, 2020 at 01:32:43PM +0100, Maxime Ripard wrote:
> >>>>>> SoCs that have multiple TCONs can use the two set of pins on the first TCON
> >>>>>> to drive a dual-link display. Add a property to enable the dual link.
> >>>>>>
> >>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>>>> ---
> >>>>>> .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 7 +++++++
> >>>>>> 1 file changed, 7 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> index 86ad617d2327..aa6dd8409dbc 100644
> >>>>>> --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> @@ -105,6 +105,13 @@ properties:
> >>>>>> - const: edp
> >>>>>> - const: lvds
> >>>>>>
> >>>>>> + allwinner,lvds-dual-link:
> >>>>>> + type: boolean
> >>>>>> + description: |
> >>>>>> + On a SoC with two TCON with LVDS support, the first TCON can
> >>>>>> + operate over both pins sets to output in a dual-link setup. This
> >>>>>> + will be triggered by setting this property.
> >>>>>
> >>>>> Could you maybe provide an example of how this property is supposed to
> >>>>> be used ? I'm especially wondering what ports are used in that case and
> >>>>> how they're connected.
> >>>>
> >>>> It's pretty trivial to support, it's only a property to set on the
> >>>> encoder node itself.
> >>>>
> >>>> I'm not really sure what you meant by your question with the ports
> >>>> though :/
> >>>
> >>> I assume that, in the single-link case, you have two TCON instances that
> >>> operate independently, each of them with one port that models an LVDS
> >>> connection to a panel.
> >>
> >> Indeed,
> >>
> >>> In the dual-link mode, how does that look like ? Does the TCON
> >>> instance that operate in dual-link mode have two ports in DT ? There
> >>> are two physical ports, so I think it makes sense to always have two
> >>> ports in DT. That's what we're doing for the LVDS encoders on R-Car
> >>> Gen3, in order to specify in DT which LVDS input of the dual-link
> >>> panel is connected to which LVDS output of the SoC. That allows
> >>> configuring the LVDS encoder to send the even and odd pixels on the
> >>> right port.
> >>
> >> As far as I can tell, you can't control that in our TCON. It just on
> >> more lanes, that's it. Also, we currently have multiple ports, to map
> >> another feature of the TCON, which is that it can drive directly a
> >> panel, or will send its output to the HDMI / TV encoders. Adding
> >> another port in that will break the current binding we have.
> >
> > This will create one issue though, in that the dual-link sinks are
> > supposed to have two input ports, in order to expose the odd and even
> > pixels ordering. If you have a single ouput port in your TCON, how will
> > you interface with such sinks ?
>
> I guess we could create multiple endpoints in the same port? That's
> not going to be trivial either though given the current binding we
> have :/
That's however not really how endpoints are supposed to be used.
Let's try to find a solution. Could you show me a DT example that
explains why having two ports would create backward-compatibility issues
?
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] pwm: bcm2835: Dynamically allocate base
From: Florian Fainelli @ 2020-02-20 19:14 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Florian Fainelli, linux-kernel,
Thierry Reding
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:PWM SUBSYSTEM, Bart Tanghe, Scott Branden,
Stephen Warren, Ray Jui,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Uwe Kleine-König
In-Reply-To: <08e2b640f0a7713d905295fc4f75df49617be6c1.camel@suse.de>
On 2/4/20 1:17 AM, Nicolas Saenz Julienne wrote:
> On Mon, 2020-02-03 at 13:35 -0800, Florian Fainelli wrote:
>> The newer 2711 and 7211 chips have two PWM controllers and failure to
>> dynamically allocate the PWM base would prevent the second PWM
>> controller instance being probed for succeeding with an -EEXIST error
>> from alloc_pwms().
>>
>> Fixes: e5a06dc5ac1f ("pwm: Add BCM2835 PWM driver")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>
> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Thierry, is there any chance we can get this applied for an upcoming
5.6-rcX? Thank you!
--
Florian
^ permalink raw reply
* Re: [PATCH] pwm: bcm2835: Dynamically allocate base
From: Florian Fainelli @ 2020-02-20 19:14 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Florian Fainelli, linux-kernel,
Thierry Reding
Cc: open list:PWM SUBSYSTEM, Bart Tanghe, Scott Branden,
Stephen Warren, Ray Jui,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Uwe Kleine-König,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <08e2b640f0a7713d905295fc4f75df49617be6c1.camel@suse.de>
On 2/4/20 1:17 AM, Nicolas Saenz Julienne wrote:
> On Mon, 2020-02-03 at 13:35 -0800, Florian Fainelli wrote:
>> The newer 2711 and 7211 chips have two PWM controllers and failure to
>> dynamically allocate the PWM base would prevent the second PWM
>> controller instance being probed for succeeding with an -EEXIST error
>> from alloc_pwms().
>>
>> Fixes: e5a06dc5ac1f ("pwm: Add BCM2835 PWM driver")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>
> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Thierry, is there any chance we can get this applied for an upcoming
5.6-rcX? Thank you!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] ceph: simplify calling of ceph_get_fmode()
From: Jeff Layton @ 2020-02-20 19:14 UTC (permalink / raw)
To: Yan, Zheng, ceph-devel
In-Reply-To: <20200220122630.63170-3-zyan@redhat.com>
On Thu, 2020-02-20 at 20:26 +0800, Yan, Zheng wrote:
> Call ceph_get_fmode() when initializing file. Because fill_inode()
> already calls ceph_touch_fmode() for open file request. It affects
You mean __ceph_touch_fmode()
> __ceph_caps_file_wanted() for 'caps_wanted_delay_min' seconds, enough
> for ceph_get_fmode() to get called by ceph_init_file_info().
>
I don't understand this changelog. Are you saying there is a potential
race of some sort, but that you don't think it's something we can hit in
practice?
> Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
> ---
> fs/ceph/caps.c | 26 +++-----------------------
> fs/ceph/file.c | 21 +++++----------------
> fs/ceph/inode.c | 8 +-------
> fs/ceph/super.h | 3 +--
> 4 files changed, 10 insertions(+), 48 deletions(-)
>
> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> index ccdc47bd7cf0..2f4ff7e9508e 100644
> --- a/fs/ceph/caps.c
> +++ b/fs/ceph/caps.c
> @@ -606,7 +606,7 @@ static void __check_cap_issue(struct ceph_inode_info *ci, struct ceph_cap *cap,
> */
> void ceph_add_cap(struct inode *inode,
> struct ceph_mds_session *session, u64 cap_id,
> - int fmode, unsigned issued, unsigned wanted,
> + unsigned issued, unsigned wanted,
> unsigned seq, unsigned mseq, u64 realmino, int flags,
> struct ceph_cap **new_cap)
> {
> @@ -622,13 +622,6 @@ void ceph_add_cap(struct inode *inode,
> dout("add_cap %p mds%d cap %llx %s seq %d\n", inode,
> session->s_mds, cap_id, ceph_cap_string(issued), seq);
>
> - /*
> - * If we are opening the file, include file mode wanted bits
> - * in wanted.
> - */
> - if (fmode >= 0)
> - wanted |= ceph_caps_for_mode(fmode);
> -
> spin_lock(&session->s_gen_ttl_lock);
> gen = session->s_cap_gen;
> spin_unlock(&session->s_gen_ttl_lock);
> @@ -753,9 +746,6 @@ void ceph_add_cap(struct inode *inode,
> cap->issue_seq = seq;
> cap->mseq = mseq;
> cap->cap_gen = gen;
> -
> - if (fmode >= 0)
> - __ceph_get_fmode(ci, fmode);
> }
>
> /*
> @@ -3726,7 +3716,7 @@ static void handle_cap_export(struct inode *inode, struct ceph_mds_caps *ex,
> /* add placeholder for the export tagert */
> int flag = (cap == ci->i_auth_cap) ? CEPH_CAP_FLAG_AUTH : 0;
> tcap = new_cap;
> - ceph_add_cap(inode, tsession, t_cap_id, -1, issued, 0,
> + ceph_add_cap(inode, tsession, t_cap_id, issued, 0,
> t_seq - 1, t_mseq, (u64)-1, flag, &new_cap);
>
> if (!list_empty(&ci->i_cap_flush_list) &&
> @@ -3831,7 +3821,7 @@ static void handle_cap_import(struct ceph_mds_client *mdsc,
> __ceph_caps_issued(ci, &issued);
> issued |= __ceph_caps_dirty(ci);
>
> - ceph_add_cap(inode, session, cap_id, -1, caps, wanted, seq, mseq,
> + ceph_add_cap(inode, session, cap_id, caps, wanted, seq, mseq,
> realmino, CEPH_CAP_FLAG_AUTH, &new_cap);
>
> ocap = peer >= 0 ? __get_cap_for_mds(ci, peer) : NULL;
> @@ -4186,16 +4176,6 @@ void ceph_get_fmode(struct ceph_inode_info *ci, int fmode, int count)
> spin_unlock(&ci->i_ceph_lock);
> }
>
> -void __ceph_get_fmode(struct ceph_inode_info *ci, int fmode)
> -{
> - int i;
> - int bits = (fmode << 1) | 1;
> - for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> - if (bits & (1 << i))
> - ci->i_file_by_mode[i].nr++;
> - }
> -}
> -
> /*
> * Drop open file reference. If we were the last open file,
> * we may need to release capabilities to the MDS (or schedule
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index f28f420bad23..60a2dfa02ba2 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -212,10 +212,8 @@ static int ceph_init_file_info(struct inode *inode, struct file *file,
> if (isdir) {
> struct ceph_dir_file_info *dfi =
> kmem_cache_zalloc(ceph_dir_file_cachep, GFP_KERNEL);
> - if (!dfi) {
> - ceph_put_fmode(ci, fmode, 1); /* clean up */
> + if (!dfi)
> return -ENOMEM;
> - }
>
> file->private_data = dfi;
> fi = &dfi->file_info;
> @@ -223,15 +221,15 @@ static int ceph_init_file_info(struct inode *inode, struct file *file,
> dfi->readdir_cache_idx = -1;
> } else {
> fi = kmem_cache_zalloc(ceph_file_cachep, GFP_KERNEL);
> - if (!fi) {
> - ceph_put_fmode(ci, fmode, 1); /* clean up */
> + if (!fi)
> return -ENOMEM;
> - }
>
> file->private_data = fi;
> }
>
> + ceph_get_fmode(ci, fmode, 1);
> fi->fmode = fmode;
> +
> spin_lock_init(&fi->rw_contexts_lock);
> INIT_LIST_HEAD(&fi->rw_contexts);
> fi->meta_err = errseq_sample(&ci->i_meta_err);
> @@ -263,7 +261,6 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> case S_IFLNK:
> dout("init_file %p %p 0%o (symlink)\n", inode, file,
> inode->i_mode);
> - ceph_put_fmode(ceph_inode(inode), fmode, 1); /* clean up */
> break;
>
> default:
> @@ -273,7 +270,6 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> * we need to drop the open ref now, since we don't
> * have .release set to ceph_release.
> */
> - ceph_put_fmode(ceph_inode(inode), fmode, 1); /* clean up */
> BUG_ON(inode->i_fop->release == ceph_release);
>
> /* call the proper open fop */
> @@ -327,7 +323,6 @@ int ceph_renew_caps(struct inode *inode, int fmode)
> req->r_inode = inode;
> ihold(inode);
> req->r_num_caps = 1;
> - req->r_fmode = -1;
>
> err = ceph_mdsc_do_request(mdsc, NULL, req);
> ceph_mdsc_put_request(req);
> @@ -373,9 +368,6 @@ int ceph_open(struct inode *inode, struct file *file)
>
> /* trivially open snapdir */
> if (ceph_snap(inode) == CEPH_SNAPDIR) {
> - spin_lock(&ci->i_ceph_lock);
> - __ceph_get_fmode(ci, fmode);
> - spin_unlock(&ci->i_ceph_lock);
> return ceph_init_file(inode, file, fmode);
> }
>
> @@ -393,7 +385,7 @@ int ceph_open(struct inode *inode, struct file *file)
> dout("open %p fmode %d want %s issued %s using existing\n",
> inode, fmode, ceph_cap_string(wanted),
> ceph_cap_string(issued));
> - __ceph_get_fmode(ci, fmode);
> + __ceph_touch_fmode(ci, mdsc, fmode);
> spin_unlock(&ci->i_ceph_lock);
>
> /* adjust wanted? */
> @@ -405,7 +397,6 @@ int ceph_open(struct inode *inode, struct file *file)
> return ceph_init_file(inode, file, fmode);
> } else if (ceph_snap(inode) != CEPH_NOSNAP &&
> (ci->i_snap_caps & wanted) == wanted) {
> - __ceph_get_fmode(ci, fmode);
> __ceph_touch_fmode(ci, mdsc, fmode);
> spin_unlock(&ci->i_ceph_lock);
> return ceph_init_file(inode, file, fmode);
> @@ -526,8 +517,6 @@ int ceph_atomic_open(struct inode *dir, struct dentry *dentry,
> err = finish_open(file, dentry, ceph_open);
> }
> out_req:
> - if (!req->r_err && req->r_target_inode)
> - ceph_put_fmode(ceph_inode(req->r_target_inode), req->r_fmode, 1);
> ceph_mdsc_put_request(req);
> out_ctx:
> ceph_release_acl_sec_ctx(&as_ctx);
> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> index b279bd8e168e..bb73b0c8c4d9 100644
> --- a/fs/ceph/inode.c
> +++ b/fs/ceph/inode.c
> @@ -969,7 +969,7 @@ static int fill_inode(struct inode *inode, struct page *locked_page,
> if (ceph_snap(inode) == CEPH_NOSNAP) {
> ceph_add_cap(inode, session,
> le64_to_cpu(info->cap.cap_id),
> - cap_fmode, info_caps,
> + info_caps,
> le32_to_cpu(info->cap.wanted),
> le32_to_cpu(info->cap.seq),
> le32_to_cpu(info->cap.mseq),
> @@ -994,13 +994,7 @@ static int fill_inode(struct inode *inode, struct page *locked_page,
> dout(" %p got snap_caps %s\n", inode,
> ceph_cap_string(info_caps));
> ci->i_snap_caps |= info_caps;
> - if (cap_fmode >= 0)
> - __ceph_get_fmode(ci, cap_fmode);
> }
> - } else if (cap_fmode >= 0) {
> - pr_warn("mds issued no caps on %llx.%llx\n",
> - ceph_vinop(inode));
> - __ceph_get_fmode(ci, cap_fmode);
> }
>
> if (iinfo->inline_version > 0 &&
> diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> index 029823643b8b..1ea76466efcb 100644
> --- a/fs/ceph/super.h
> +++ b/fs/ceph/super.h
> @@ -1038,7 +1038,7 @@ extern struct ceph_cap *ceph_get_cap(struct ceph_mds_client *mdsc,
> struct ceph_cap_reservation *ctx);
> extern void ceph_add_cap(struct inode *inode,
> struct ceph_mds_session *session, u64 cap_id,
> - int fmode, unsigned issued, unsigned wanted,
> + unsigned issued, unsigned wanted,
> unsigned cap, unsigned seq, u64 realmino, int flags,
> struct ceph_cap **new_cap);
> extern void __ceph_remove_cap(struct ceph_cap *cap, bool queue_release);
> @@ -1080,7 +1080,6 @@ extern int ceph_try_get_caps(struct inode *inode,
> int need, int want, bool nonblock, int *got);
>
> /* for counting open files by mode */
> -extern void __ceph_get_fmode(struct ceph_inode_info *ci, int mode);
> extern void ceph_get_fmode(struct ceph_inode_info *ci, int mode, int count);
> extern void ceph_put_fmode(struct ceph_inode_info *ci, int mode, int count);
> extern void __ceph_touch_fmode(struct ceph_inode_info *ci,
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap().
From: Minchan Kim @ 2020-02-20 19:14 UTC (permalink / raw)
To: Brian Geffon
Cc: Andrew Morton, Michael S . Tsirkin, Arnd Bergmann, LKML, linux-mm,
Linux API, Andy Lutomirski, Will Deacon, Andrea Arcangeli,
Sonny Rao, Joel Fernandes, Yu Zhao, Jesse Barnes, Florian Weimer,
Kirill A . Shutemov
In-Reply-To: <CADyq12zUEq9kcyuR_Qm9MrU1ii-+9n8T2hK6QNzj=kH5zn0VrA@mail.gmail.com>
On Thu, Feb 20, 2020 at 10:36:38AM -0800, Brian Geffon wrote:
> Hi Minchan,
>
> > And here we got error if the addr is in non-anonymous-private vma so the
> > syscall will fail but old vma is gone? I guess it's not your intention?
>
> This is exactly what happens today in several situations, because
> vma_to_resize is called unconditionally. For example if the old vma
> has VM_HUGETLB and old_len < new_len it would have unmapped a portion
> and then in vma_to_resize returned -EINVAL, similarly when old_len = 0
> with a non-sharable mapping it will have called do_munmap only to fail
> in vma_to_resize, if the vma has VM_DONTEXPAND set and you shrink the
> size with old_len < new_len it would return -EFAULT after having done
> the unmap on the decreased portion. So I followed the pattern to keep
> the change simple and maintain consistency with existing behavior.
Fair enough. It seems to be very old existing behavior but man page
never mention about it. :(
>
> But with that being said, Kirill made the point that resizing a VMA
> while also using MREMAP_DONTUNMAP doesn't have any clear use case and
> I agree with that, I'm unable to think of a situation where you'd want
> to resize a VMA and use MREMAP_DONTUNMAP. So I'm tempted to mail a new
> version which returns -EINVAL if old_len != new_len that would resolve
> this concern here as nothing would be unmapped ever at the old
> position add it would clean up the change to very few lines of code.
>
> What do you think?
Agreed. That makes code more simple/clean.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: sun4i-tcon: Add LVDS Dual Link property
From: Laurent Pinchart @ 2020-02-20 19:13 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, David Airlie, Maarten Lankhorst,
dri-devel, Chen-Yu Tsai, Rob Herring, Sean Paul, Daniel Vetter,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20200220175307.qool442lm7qjqb5h@gilmour.lan>
Hi Maxime,
On Thu, Feb 20, 2020 at 06:53:07PM +0100, Maxime Ripard wrote:
> On Mon, Feb 17, 2020 at 08:10:06PM +0200, Laurent Pinchart wrote:
> > On Mon, Feb 17, 2020 at 06:42:53PM +0100, Maxime Ripard wrote:
> >> On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb 14, 2020 at 04:44:05PM +0100, Maxime Ripard wrote:
> >>>> On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote:
> >>>>> On Fri, Feb 14, 2020 at 01:32:43PM +0100, Maxime Ripard wrote:
> >>>>>> SoCs that have multiple TCONs can use the two set of pins on the first TCON
> >>>>>> to drive a dual-link display. Add a property to enable the dual link.
> >>>>>>
> >>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>>>> ---
> >>>>>> .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 7 +++++++
> >>>>>> 1 file changed, 7 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> index 86ad617d2327..aa6dd8409dbc 100644
> >>>>>> --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> >>>>>> @@ -105,6 +105,13 @@ properties:
> >>>>>> - const: edp
> >>>>>> - const: lvds
> >>>>>>
> >>>>>> + allwinner,lvds-dual-link:
> >>>>>> + type: boolean
> >>>>>> + description: |
> >>>>>> + On a SoC with two TCON with LVDS support, the first TCON can
> >>>>>> + operate over both pins sets to output in a dual-link setup. This
> >>>>>> + will be triggered by setting this property.
> >>>>>
> >>>>> Could you maybe provide an example of how this property is supposed to
> >>>>> be used ? I'm especially wondering what ports are used in that case and
> >>>>> how they're connected.
> >>>>
> >>>> It's pretty trivial to support, it's only a property to set on the
> >>>> encoder node itself.
> >>>>
> >>>> I'm not really sure what you meant by your question with the ports
> >>>> though :/
> >>>
> >>> I assume that, in the single-link case, you have two TCON instances that
> >>> operate independently, each of them with one port that models an LVDS
> >>> connection to a panel.
> >>
> >> Indeed,
> >>
> >>> In the dual-link mode, how does that look like ? Does the TCON
> >>> instance that operate in dual-link mode have two ports in DT ? There
> >>> are two physical ports, so I think it makes sense to always have two
> >>> ports in DT. That's what we're doing for the LVDS encoders on R-Car
> >>> Gen3, in order to specify in DT which LVDS input of the dual-link
> >>> panel is connected to which LVDS output of the SoC. That allows
> >>> configuring the LVDS encoder to send the even and odd pixels on the
> >>> right port.
> >>
> >> As far as I can tell, you can't control that in our TCON. It just on
> >> more lanes, that's it. Also, we currently have multiple ports, to map
> >> another feature of the TCON, which is that it can drive directly a
> >> panel, or will send its output to the HDMI / TV encoders. Adding
> >> another port in that will break the current binding we have.
> >
> > This will create one issue though, in that the dual-link sinks are
> > supposed to have two input ports, in order to expose the odd and even
> > pixels ordering. If you have a single ouput port in your TCON, how will
> > you interface with such sinks ?
>
> I guess we could create multiple endpoints in the same port? That's
> not going to be trivial either though given the current binding we
> have :/
That's however not really how endpoints are supposed to be used.
Let's try to find a solution. Could you show me a DT example that
explains why having two ports would create backward-compatibility issues
?
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 2/7] mm: introduce external memory hinting API
From: kbuild test robot @ 2020-02-20 19:13 UTC (permalink / raw)
To: Minchan Kim; +Cc: kbuild-all, Andrew Morton, Linux Memory Management List
In-Reply-To: <20200219014433.88424-3-minchan@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 5021 bytes --]
Hi Minchan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on m68k/for-next]
[also build test WARNING on powerpc/next s390/features linus/master v5.6-rc2 next-20200220]
[cannot apply to arm64/for-next/core tip/x86/asm arm/for-next hp-parisc/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Minchan-Kim/introduce-memory-hinting-API-for-external-process/20200220-225155
base: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-next
config: nds32-randconfig-a001-20200220 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.2.0 make.cross ARCH=nds32
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from arch/nds32/kernel/vdso/sigreturn.S:6:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
--
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from <stdin>:2:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
>> <stdin>:1520:2: warning: #warning syscall process_madvise not implemented [-Wcpp]
--
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from <stdin>:2:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
>> <stdin>:1520:2: warning: #warning syscall process_madvise not implemented [-Wcpp]
16 real 2 user 4 sys 39.01% cpu make modules_prepare
--
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from <stdin>:2:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
>> <stdin>:1520:2: warning: #warning syscall process_madvise not implemented [-Wcpp]
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from arch/nds32/kernel/vdso/sigreturn.S:6:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
In file included from arch/nds32/include/uapi/asm/unistd.h:10,
from arch/nds32/include/asm/unistd.h:6,
from arch/nds32/kernel/vdso/gettimeofday.c:11:
>> include/uapi/asm-generic/unistd.h:858: warning: "__NR_pidfd_getfd" redefined
858 | #define __NR_pidfd_getfd 439
|
include/uapi/asm-generic/unistd.h:856: note: this is the location of the previous definition
856 | #define __NR_pidfd_getfd 438
|
17 real 4 user 6 sys 59.28% cpu make prepare
vim +/__NR_pidfd_getfd +858 include/uapi/asm-generic/unistd.h
853
854 #define __NR_openat2 437
855 __SYSCALL(__NR_openat2, sys_openat2)
856 #define __NR_pidfd_getfd 438
857 __SYSCALL(__NR_pidfd_getfd, sys_pidfd_getfd)
> 858 #define __NR_pidfd_getfd 439
859 __SYSCALL(__NR_process_madvise, sys_process_madvise)
860
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24985 bytes --]
^ permalink raw reply
* Re: [PATCH v26 10/22] x86/sgx: Linux Enclave Driver
From: Sean Christopherson @ 2020-02-20 19:15 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jordan Hand, Jarkko Sakkinen, LKML, X86 ML, linux-sgx,
Andrew Morton, Dave Hansen, Neil Horman, npmccallum,
Huang, Haitao, Andy Shevchenko, Thomas Gleixner, Svahn, Kai,
Borislav Petkov, Josh Triplett, Huang, Kai, David Rientjes,
Xing, Cedric, puiterwijk, LSM List, Suresh Siddha, Haitao Huang
In-Reply-To: <CALCETrVXnSR8fBQtqv=3zFxJCFhcHE-6XNAy3suPW+uPgFvfvg@mail.gmail.com>
On Thu, Feb 20, 2020 at 10:51:37AM -0800, Andy Lutomirski wrote:
> On Thu, Feb 20, 2020 at 10:13 AM Sean Christopherson
> <sean.j.christopherson@intel.com> wrote:
> > More than likely, the READ_IMPLIES_EXECUTE (RIE) crud rears its head
> > because part of the enclave loader is written in assembly. Unless
> > explicitly told otherwise, the linker assumes that any program with
> > assembly code may need an executable stack, which leads to the RIE
> > personality being set for the process. Here's a fantastic write up for
> > more details: https://www.airs.com/blog/archives/518
> >
> > There are essentially two paths we can take:
> >
> > 1) Exempt EPC pages from RIE during mmap()/mprotect(), i.e. don't add
> > PROT_EXEC for enclaves.
>
> Seems reasonable.
>
> Honestly, it probably makes sense to try to exempt almost everything
> from RIE. I'd be a bit surprised if RIE is actually useful for
> anything other than plain anonymous pages and private file mappings.
Hmm, last I looked at this I was focused on adding a generic protections
manipulator, e.g. vm_ops->mprotect_adjust() and f_op->???, and I thought
those options were too ugly to pursue.
But if we want to start killing RIE specifically, adding a boolean flag
to and f_op wouldn't be _that_ heinous, e.g.
static int do_mprotect_pkey(...)
{
...
/* Does the application expect PROT_READ to imply PROT_EXEC */
if (rier && (vma->vm_flags & VM_MAYEXEC) &&
(!vma->vm_file || !vma->vm_file->f_op->no_read_implies_exec))
prot |= PROT_EXEC;
}
unsigned long do_mmap(...)
{
if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
if (!file || (!path_noexec(&file->f_path) &&
!file->f_op->no_read_implies_exec))
prot |= PROT_EXEC;
}
^ permalink raw reply
* Re: [PATCH] Revert "PM / devfreq: Modify the device name as devfreq(X) for sysfs"
From: Greg Kroah-Hartman @ 2020-02-20 19:15 UTC (permalink / raw)
To: Orson Zhai
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, John Stultz,
mingmin.ling, orsonzhai, jingchao.ye, linux-pm, linux-kernel,
stable
In-Reply-To: <1582220224-1904-1-git-send-email-orson.unisoc@gmail.com>
On Fri, Feb 21, 2020 at 01:37:04AM +0800, Orson Zhai wrote:
> This reverts commit 4585fbcb5331fc910b7e553ad3efd0dd7b320d14.
>
> The name changing as devfreq(X) breaks some user space applications,
> such as Android HAL from Unisoc and Hikey [1].
> The device name will be changed unexpectly after every boot depending
> on module init sequence. It will make trouble to setup some system
> configuration like selinux for Android.
>
> So we'd like to revert it back to old naming rule before any better
> way being found.
>
> [1] https://lkml.org/lkml/2018/5/8/1042
>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Orson Zhai <orson.unisoc@gmail.com>
>
> ---
> drivers/devfreq/devfreq.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index cceee8b..7dcf209 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -738,7 +738,6 @@ struct devfreq *devfreq_add_device(struct device *dev,
> {
> struct devfreq *devfreq;
> struct devfreq_governor *governor;
> - static atomic_t devfreq_no = ATOMIC_INIT(-1);
> int err = 0;
>
> if (!dev || !profile || !governor_name) {
> @@ -800,8 +799,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
> atomic_set(&devfreq->suspend_count, 0);
>
> - dev_set_name(&devfreq->dev, "devfreq%d",
> - atomic_inc_return(&devfreq_no));
> + dev_set_name(&devfreq->dev, "%s", dev_name(dev));
> err = device_register(&devfreq->dev);
> if (err) {
> mutex_unlock(&devfreq->lock);
> --
> 2.7.4
>
Thanks for this, I agree, this needs to get back to the way things were
as it seems to break too many existing systems as-is.
I'll queue this up in my tree now, thanks.
greg k-h
^ permalink raw reply
* Re: [CRASH] crypto: virtio: crash when modprobing tcrypt on 5.5-rc7 / next-20200122
From: LABBE Corentin @ 2020-02-20 19:15 UTC (permalink / raw)
To: arei.gonglei
Cc: jasowang, herbert, davem, virtualization, linux-crypto,
linux-kernel, mst
In-Reply-To: <20200204041419-mutt-send-email-mst@kernel.org>
On Tue, Feb 04, 2020 at 04:15:22AM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 23, 2020 at 11:10:00AM +0100, LABBE Corentin wrote:
> > Hello
> >
> > When modprobing tcrypt on qemu 4.1.0 I get a kernel panic on 5.5-rc7 and next-20200122
> > qemu is started by:
> > /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic -net nic,model=e1000,macaddr=52:54:00:12:34:58 -net tap -m 512 -monitor none -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -append 'console=ttyS0 root=/dev/ram0 ip=dhcp' -kernel /var/lib/lava/dispatcher/tmp/41332/deployimages-td18675m/kernel/bzImage -initrd /var/lib/lava/dispatcher/tmp/41332/deployimages-td18675m/ramdisk/rootfs.cpio.gz -drive format=qcow2,file=/var/lib/lava/dispatcher/tmp/41332/apply-overlay-guest-icy4k1ol/lava-guest.qcow2,media=disk,if=ide,id=lavatest
> >
> > [ 112.771925] general protection fault: 0000 [#1] SMP PTI
> > [ 112.772686] CPU: 0 PID: 126 Comm: virtio0-engine Not tainted 5.5.0-rc7+ #1
> > [ 112.773576] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31 04/01/2014
> > [ 112.775319] RIP: 0010:sg_next+0x0/0x20
> > [ 112.775821] Code: cc cc cc cc cc cc cc cc cc cc c7 47 10 00 00 00 00 89 57 0c 48 89 37 89 4f 08 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 <f6> 07 02 75 17 48 8b 57 20 48 8d 47 20 48 89 d1 48 83 e1 fc 83 e2
> > [ 112.778330] RSP: 0018:ffffa92440237d90 EFLAGS: 00010006
> > [ 112.779071] RAX: fefefefe00000000 RBX: 000000000000000a RCX: fefefefe00000000
> > [ 112.780081] RDX: 0000000000000001 RSI: ffff9b19da1a2180 RDI: fefefefe00000000
> > [ 112.781081] RBP: ffff9b19da1a2198 R08: ffff9b19dfb24ee8 R09: 0000000000000a20
> > [ 112.782079] R10: ffff9b19da125010 R11: 0000000000000000 R12: ffff9b19da1a21b8
> > [ 112.783079] R13: 0000000000000003 R14: ffff9b19da1a2180 R15: 0000000000000004
> > [ 112.784077] FS: 0000000000000000(0000) GS:ffff9b19de400000(0000) knlGS:0000000000000000
> > [ 112.785202] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 112.786030] CR2: 00007f18a157b050 CR3: 000000001040a004 CR4: 0000000000060ef0
> > [ 112.787034] Call Trace:
> > [ 112.787393] virtqueue_add_sgs+0x4c/0x90
> > [ 112.787998] virtio_crypto_skcipher_crypt_req+0x310/0x3e0
> > [ 112.788817] crypto_pump_work+0x10c/0x240
> > [ 112.789420] ? __kthread_init_worker+0x50/0x50
> > [ 112.790082] kthread_worker_fn+0x89/0x180
> > [ 112.790690] kthread+0x10e/0x130
> > [ 112.791182] ? kthread_park+0x80/0x80
> > [ 112.791736] ret_from_fork+0x35/0x40
> > [ 112.792282] Modules linked in: cts lzo salsa20_generic camellia_x86_64 camellia_generic fcrypt pcbc tgr192 anubis wp512 khazad tea michael_mic arc4 cast6_generic cast5_generic cast_common deflate sha512_ssse3 sha512_generic cfb ofb serpent_sse2_x86_64 serpent_generic lrw twofish_x86_64_3way twofish_x86_64 crypto_simd cryptd glue_helper twofish_generic twofish_common blowfish_x86_64 blowfish_generic blowfish_common md4 tcrypt(+)
> > [ 112.797652] ---[ end trace 4a8142d4a08c2518 ]---
> > [ 112.798320] RIP: 0010:sg_next+0x0/0x20
> > [ 112.798865] Code: cc cc cc cc cc cc cc cc cc cc c7 47 10 00 00 00 00 89 57 0c 48 89 37 89 4f 08 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 <f6> 07 02 75 17 48 8b 57 20 48 8d 47 20 48 89 d1 48 83 e1 fc 83 e2
> > [ 112.801452] RSP: 0018:ffffa92440237d90 EFLAGS: 00010006
> > [ 112.802189] RAX: fefefefe00000000 RBX: 000000000000000a RCX: fefefefe00000000
> > [ 112.803190] RDX: 0000000000000001 RSI: ffff9b19da1a2180 RDI: fefefefe00000000
> > [ 112.804192] RBP: ffff9b19da1a2198 R08: ffff9b19dfb24ee8 R09: 0000000000000a20
> > [ 112.805201] R10: ffff9b19da125010 R11: 0000000000000000 R12: ffff9b19da1a21b8
> > [ 112.806195] R13: 0000000000000003 R14: ffff9b19da1a2180 R15: 0000000000000004
> > [ 112.807222] FS: 0000000000000000(0000) GS:ffff9b19de400000(0000) knlGS:0000000000000000
> > [ 112.808352] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 112.809169] CR2: 00007f18a157b050 CR3: 000000001040a004 CR4: 0000000000060ef0
> >
> > I have tested also 5.4.14
> > and I got random freeze with:
> > qemu-system-x86_64: virtio: zero sized buffers are not allowed
> >
> > Regards
>
> Cc: Gonglei <arei.gonglei@huawei.com>
>
Hello Gonglei
Any plan to fix the driver ? It is broken since its introduction.
Regards
^ 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.