* Re: [PATCH] s390/sclp: improve special wait psw logic
From: Christian Borntraeger @ 2020-02-20 13:35 UTC (permalink / raw)
To: David Hildenbrand, Cornelia Huck
Cc: Janosch Frank, qemu-s390x, qemu-stable, qemu-devel,
Richard Henderson
In-Reply-To: <7b3478cc-7d74-49af-dfad-bd0349371517@redhat.com>
On 20.02.20 14:26, David Hildenbrand wrote:
> On 20.02.20 14:16, Christian Borntraeger wrote:
>> There is a special quiesce PSW that we check for "shutdown". Otherwise disabled
>> wait is detected as "crashed". Architecturally we must only check PSW bits
>> 116-127. Fix this.
>>
>> Cc: qemu-stable@nongnu.org
>
> Is this really stable material?
Guests that end with lets say 0xaafffUL would be considered "crashed" instead of "shutdown".
I will let Conny decide.
>
> Reviewed-by: David Hildenbrand <david@redhat.com>
>
^ permalink raw reply
* [Buildroot] Analysis of build results
From: Giulio Benetti @ 2020-02-20 13:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20200220034343.2370e4e4@windsurf>
Hi All,
Il 20/02/2020 03:43, Thomas Petazzoni ha scritto:
> Hello,
>
> On Wed, 19 Feb 2020 07:48:39 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
>> master | 92 | 67 | 0 | 159 |
>
> These results are not really good, so we need to put some effort into
> reducing the number of build failures in the autobuilders. See below
> for an analysis of the different build failures. Your help is
> appreciated to fix those issues.
>
>> m68k | acpica-20191018 | NOK | http://autobuild.buildroot.net/results/81ee33eb606062a62765d95b66a26f130d280c53 |
>
> Segmentation fault in elf2flt:
>
> ld (ld-elf2flt): /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault]
>
> Romain, I am wondering if you already had a look into this. Could you
> comment?
>
>> powerpc64 | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/d10a06addfdd927fd2ac772b25aaf9a057d20158 |
>> mips64el | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/16d2a2efed3b13ca648c83b64150da4c2c53afd7 |
>> powerpc64le | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/603f1be80822977f3181c99b8b01b3f2d531ace7 |
>> sparc | apr-util-1.6.1 | NOK | http://autobuild.buildroot.net/results/7b4780dd10b471243451f7f89c6b7de0c7e7ec4e |
>
> Per-package directories issue, fixed by
> https://git.buildroot.org/buildroot/commit/?id=84b4c19e551288911a230c2b73e96bc6e2ed12f9
>
>> m68k | augeas-1.12.0 | NOK | http://autobuild.buildroot.net/results/4e1f7f335d2c853e2a5e6ad96c14157ba8f003c7 |
>
> Another elf2flt issue:
>
> ld (ld-elf2flt): /home/giuliobenetti/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault], core dumped
>
> Romain ? :-)
>
>> microblazeel | bash-5.0 | NOK | http://autobuild.buildroot.net/results/b9edb405f6cf3322ddbb640c8e89cca57e840fc2 | ORPH
>
> ../input.h:76:3: error: unknown type name 'FILE'
>
> Not clear what is happening here. Could anyone investigate ?
>
>> i686 | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/16129b6d867578fc1cbcd36ed3a6cad806c21b10 |
>> powerpc | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/7442b75921b95f5772520b62ff4004bc98251ee4 |
>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/979be1e697bb75cc018141e8fa83905696e738cf |
>> arm | brltty-6.0 | NOK | http://autobuild.buildroot.net/results/240de32ee2a20b56db535147c98220783c48295f |
>
> I have submitted http://patchwork.ozlabs.org/patch/1241072/ to fix this.
>
>> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/9552e97cd64c447c8582efbe326ddafa42bf9a01 |
>> m68k | cairo-1.16.0 | NOK | http://autobuild.buildroot.net/results/976d99bc9b052f8d9429e666ac7fff7768ffff6b |
>
> Another elf2flt segfault. Why are we seeing these segfaults? I don't
> think we used to have so many. Is it due to the relatively recent
> rebuild of all Buildroot toolchains, which perhaps mean we're using a
> newer version of elf2flt ?
>
>> arm | efl-1.22.3 | NOK | http://autobuild.buildroot.net/results/4d7861fd5908c59546de19f6af3c27d061fed60b |
>
> /data/buildroot/buildroot-test/instance-0/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/poppler/cpp/poppler-page.h:39:22: error: expected ',' or '...' before '&&' token
>
> Some C++ mess it seems. Romain, any idea ?
>
>> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/3cd8e2c64e8051a95e0e097cdd0878b00afacf8e |
>> sparc64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/edde1b609fd6b0e6be9870f78c71a6ababa49884 |
>> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/b24891ac2f7b661db63c54f52024efc1e23f0339 |
>> arm | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/491215f51a2f1c725099c53685b34513e3ff55e7 |
>> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/d3552e742381c737e5cacc5ca421c154ef93cde1 |
>> x86_64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/385f0b988fc1ffbf918fb9adc4dd556b2fb367ab |
>> mipsel | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/26137934eb18531985f5b648f391501835445331 |
>> powerpc | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/32b5aacc2cae822d169b9a61ec4d7c1292caf877 |
>> aarch64 | erlang-22.2 | NOK | http://autobuild.buildroot.net/results/cc1e3df1eec85a9eca98b992f646061fb888512b |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=607040e91381aae35205659e8edd7b2eeb45d420
>
>> arm | fontconfig-2.13.1 | NOK | http://autobuild.buildroot.net/results/4a5a8cb6411d709acb7ea8c83b3c8e45fdc0a10b | ORPH
>
> Another elf2flt issue.
>
>> nios2 | git-2.24.1 | NOK | http://autobuild.buildroot.net/results/432a2766836107ed5536f861a8fbcab33e1f8cf6 |
>
> Wonderful, another compiler segfault:
>
> ref-filter.c: In function 'find_longest_prefixes_1':
> ref-filter.c:1914:1: internal compiler error: Segmentation fault
>
> Giulio or Romain, any idea ?
Going to deal with this and let you know when gcc bug is reported and I
have a decent work around.
--
Giulio Benetti
>> m68k | gptfdisk-1.0.4 | NOK | http://autobuild.buildroot.net/results/6db5f9d8663730a54b04c1e624438095598b2573 | ORPH
>
> Our friend elf2flt strikes again. We really need to fix this issue.
>
>> arm | gst1-plugins-base-1.16.2 | NOK | http://autobuild.buildroot.net/results/b97923f7db5e0d7d5609152078573360937e0318 |
>
> Static linking issue. It may be the same problem as the one affecting
> libglib2. See below.
>
>> powerpc64le | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/89a2785352caae69cdf6aa02d55475aa4ed506d1 |
>> riscv64 | host-grpc-1.25.0 | NOK | http://autobuild.buildroot.net/results/6e8ef0be643e030434474b58b15b3eff43081e5a |
>
> Still this mysterious failure that happens only on Yann's machine. Yann? :-)
>
>> riscv64 | host-llvm-9.0.1 | NOK | http://autobuild.buildroot.net/results/b922547540022a6fbde238053e2e5373a96ad48b |
>
> CMake Error at cmake/config-ix.cmake:438 (message):
> Unknown architecture
>
> Something not careful enough is using host-llvm even though the target
> architecture is not supported. Romain ?
>
>> i586 | host-pango-1.44.6 | NOK | http://autobuild.buildroot.net/results/30699ba23805d2b267644dc321b8aaec72a6bc89 | ORPH
>
> cannot delete non-empty directory: share/gettext
> could not make way for new symlink: share/gettext
>
> This is a per-package directory issue.
>
>> x86_64 | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/bc06573718c7b05bb2ea081089cb3afa6b3cd2c2 |
>> mips | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/929fb828553ca99c9fe3480286627f149226b857 |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/3cba9e7e96aeb5ca6c68a82b972988a7bc1dc87a |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/0e67255cc1b184273749e8fdb721f815b144031d |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/6216d389edff9893f8f791ab2fbfe46d8e1276fc |
>> arm | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/34644e28467ac49eb4bc676ac0eb48c0978d4eb9 |
>> microblazeel | host-sdbusplus-4212292bcf13... | NOK | http://autobuild.buildroot.net/results/7ba2762786c08231a69a07558274e52750b7627c |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=6bf74ce3dbfec8979e379bc1b919f29d09f0d87b
>
>> xtensa | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/17cb7ca0e7ca1359fc2b575a6b6c93d493dd54fb |
>> riscv64 | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/5b619163f23e356c790a04c027f9b9ba8b650c43 |
>> arm | libgdiplus-5.6 | NOK | http://autobuild.buildroot.net/results/d9dca72127a005952a7f97ec0297cec2fd3968f4 |
>
> /data/buildroot/buildroot-test/instance-0/output/host/lib/gcc/arm-buildroot-linux-musleabihf/8.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: ../src/.libs/libgdiplus.so: undefined reference to `GifQuantizeBuffer'
>
> Sergio, could you have a look ?
>
>> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/68b4aa933fd5a60f4ac2ea023079053f805c621b |
>> sparc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/279f4f8f293a4aa73b6534e4cbc90e5583951daa |
>> sh4 | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/1610673bc92f3cab2b858af8c4b1d0b6c871e614 |
>> arc | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/e27bf4715cc68ef976b2124663cc1c2d08a06d04 |
>> arm | libglib2-2.62.4 | NOK | http://autobuild.buildroot.net/results/b43ef2ad840c5bf897d0453f86026b58654f9377 |
>
> This is a static linking issue caused by a change in the pkg-config
> handling in our meson logic. I have reported this to Arnout at
> http://lists.busybox.net/pipermail/buildroot/2020-February/274491.html.
> However now I see that Fabrice has proposed
> http://lists.busybox.net/pipermail/buildroot/2020-February/274178.html
> to resolve the problem, which seems like a good approach.
>
> Arnout?
>
>> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/673d2a580afb774c39faf69c859418579cefccde |
>> powerpc | libnss-3.50 | NOK | http://autobuild.buildroot.net/results/7afbb81c0ebc93a75ec58c067f9758369bcae5d6 |
>
> These would be fixed by http://patchwork.ozlabs.org/patch/1235413/.
>
>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/f9d3d8534d090a575d163f92920b6ad6cc1531a2 |
>> m68k | libopenssl-1.1.1d | NOK | http://autobuild.buildroot.net/results/acf87e81130e85e7fb05edf5f6dedf095f16e226 |
>
> elf2flt I love you.
>
>> arc | libsvgtiny-ea9d99fc8b231c22... | NOK | http://autobuild.buildroot.net/results/67d341c0cc272323d6e231a20796a6848c21d760 | ORPH
>
> src/svgtiny.c:21:10: fatal error: autogenerated_colors.c: No such file or directory
> 21 | #include "autogenerated_colors.c"
>
> Some generated file is not here. Parallel build issue? Something else?
>
> We don't have any maintainer of libsvgtiny. Any volunteer ?
>
>> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/49c150649fa50e9dc67939e072cd5a1d3a7aa661 |
>> x86_64 | mesa3d-19.3.4 | NOK | http://autobuild.buildroot.net/results/86036e0e4e29eeffbe4aa10ca6e075155b675e72 |
>
> I would suspect these would be fixed by http://patchwork.ozlabs.org/patch/1240964/.
>
>> m68k | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/61f53630ed85ee0d0d6dbf71012db77f4d7986ad |
>
> elf2flt issue.
>
>> xtensa | opencv3-3.4.9 | NOK | http://autobuild.buildroot.net/results/8c49a36b1fe423561473395d8f055c90436d2a5f |
>
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
> #error This file was generated by an older version of protoc which is
> ^~~~~
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please
> #error incompatible with your Protocol Buffer headers. Please
> ^~~~~
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/opencv3-3.4.9/modules/dnn/misc/caffe/opencv-caffe.pb.h:19:2: error: #error regenerate this file with a newer version of protoc.
> #error regenerate this file with a newer version of protoc.
> ^~~~~
>
> OK, needs to be investigated. opencv3 used to be maintained by Samuel
> Martin, but Samuel is no longer active in Buildroot. Any volunteer?
>
>> i586 | openvmtools-10.3.5-10430147 | NOK | http://autobuild.buildroot.net/results/e0e7ed448df8bdd6cb13a0989d7a6c7dbaa5bc4e |
>
> /home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/8.3.0/../../../../i586-buildroot-linux-musl/bin/ld: vmtoolsd-cmdLine.o: undefined reference to symbol 'libintl_gettext'
>
> Needs to link against the proper libintl library. Anyone to look into this ?
>
>> powerpc64 | ripgrep-0.8.1 | NOK | http://autobuild.buildroot.net/results/1ee145c19ee2cd5e6c237bc2864bae75e9ee4115 |
>
> Fails while downloading stuff during the build. I guess this is what is
> being fixed by the work on Cargo integration in Buildroot.
>
>> i686 | sdl2-2.0.10 | NOK | http://autobuild.buildroot.net/results/0996643e6d235168ca77271f15b21f8c167e400f |
>
> /home/buildroot/autobuild/instance-1/output-1/host/i686-buildroot-linux-uclibc/sysroot/usr/include/EGL/eglplatform.h:134:10: fatal error: X11/Xlib.h: No such file or directory
> #include <X11/Xlib.h>
>
> Anybody to have a look ?
>
>> sparc | tio-1.32 | NOK | http://autobuild.buildroot.net/results/7612824c472bd34f352a83aea50a9707442b1b42 |
>
> /home/peko/autobuild/instance-0/output-1/host/sparc-buildroot-linux-uclibc/sysroot/usr/include/asm/termbits.h:16:8: error: redefinition of 'struct termio'
> struct termio {
>
>
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/cba93a681d10692c4e4c5584e4c962bd18a608d4 | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/efd344724a244010e3411bb6599dec42adb8acaa | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/3f7c9d3738db5154cad27e548495643225dde0bc | ORPH
>> arm | toolchain-external-codesour... | NOK | http://autobuild.buildroot.net/results/7513ce8a3c501aa31aa1bd1a9908ad090b2b11b1 | ORPH
>
> These would be fixed by my series:
>
> http://patchwork.ozlabs.org/project/buildroot/list/?series=159621
>
>> riscv32 | unknown | NOK | http://autobuild.buildroot.net/results/f0c62cf7edda5c811c7f2eda6212d3889f2920df |
>
> Not clear why it failed. This is not a reproducible build issue, there
> are no errors in the logs. It was built with
> BR2_PER_PACKAGE_DIRECTORIES=y, so possibly with top-level parallel
> build, and therefore the error might be outside of the log.
>
>> arm | unknown | NOK | http://autobuild.buildroot.net/results/593c94c707508b549547e4b42727ce669229c820 |
>
> This one is a reproducible build issue due to elf2flt storing the build
> date in the BFLT header. I have already fixed this in upstream elf2flt
> https://github.com/uclinux-dev/elf2flt/commit/453398f917d167f8c308c8f997270c48ae8f8b12,
> we need to backport this in BR and rebuild our noMMU toolchains.
>
>> powerpc | unknown | NOK | http://autobuild.buildroot.net/results/47667ea26dc4ed87d4aeb4ac9ae86fcd42223c6b |
>
> Also no visible error here, also probably a top-level parallel build.
> We need to somehow fix the logic we use to extract the error when doing
> top-level parallel builds.
>
>> arm | vlc-3.0.8 | NOK | http://autobuild.buildroot.net/results/ad8058cd98378d8813ab72bc292c8c5b9e41d7a0 |
>
> video_filter/opencv_example.cpp:200:46: error: could not convert 'cv::Scalar_<double>((double)0, (double)0, (double)0, (double)0)' from 'cv::Scalar' {aka 'cv::Scalar_<double>'} to 'CvScalar'
> cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 );
>
> Meh. VLC/OpenCV issue.
>
> Thomas
>
^ permalink raw reply
* [LTP] ksm03, ksm04 testcases don't work with cgroup
From: Cyril Hrubis @ 2020-02-20 13:36 UTC (permalink / raw)
To: ltp
In-Reply-To: <BM1PR0101MB145982BF4AAC059931EA2013EE130@BM1PR0101MB1459.INDPRD01.PROD.OUTLOOK.COM>
Hi!
> I am running ksm03 and kms04 on my RISC v system wth linux 5.4.3,LTP Version: 20200120-55-g537fb6535
> with custom Yocto distro,the test is getting failed with following errors.why it is failing?
>
> root@exaleapsemi:~/pankaj_ltp/ltp/testcases/kernel/mem/ksm# ./ksm03
> tst_test.c:1215: INFO: Timeout per run is 0h 05m 00s
> safe_macros.c:167: BROK: mem.c:750: mkdir(/dev/cgroup,0777) failed: EEXIST (17)
That's more of the system problem than anything else, kernel itself does
not mount cgroups anywhere, that's usually done it the boot process and
it ends up under /sys/fs/cgroups/ on most of the recent distributions.
It looks like something has mounted cgroups over the /dev/cgroup on your
system, it's up to you to figure out why is it mounted there.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply
* [PATCH v5 3/6] doc: board: apalis-imx8: convert readme to reST
From: Bin Meng @ 2020-02-20 13:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200212151433.9713-4-igor.opaniuk@gmail.com>
On Wed, Feb 12, 2020 at 11:14 PM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
>
> From: Igor Opaniuk <igor.opaniuk@toradex.com>
>
> Convert README to reStructuredText format.
>
> Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
> ---
>
> board/toradex/apalis-imx8/README | 66 -------------------------
> doc/board/toradex/apalix-imx8.rst | 82 +++++++++++++++++++++++++++++++
> doc/board/toradex/index.rst | 1 +
> 3 files changed, 83 insertions(+), 66 deletions(-)
> delete mode 100644 board/toradex/apalis-imx8/README
> create mode 100644 doc/board/toradex/apalix-imx8.rst
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply
* 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
From: Liu, Monk @ 2020-02-20 13:35 UTC (permalink / raw)
To: Liu, Monk, Li, Dennis, Koenig, Christian, Zhang, Hawking,
amd-gfx@lists.freedesktop.org, Deucher, Alexander, Zhou1, Tao,
Chen, Guchun
In-Reply-To: <DM6PR12MB39317635C3FB63265B9216D084130@DM6PR12MB3931.namprd12.prod.outlook.com>
Sorry, my previous idea still leave RQ null, please check if below method works:
29 static struct drm_sched_rq *
130 drm_sched_entity_get_free_sched(struct drm_sched_entity *entity)
131 {
132 struct drm_sched_rq *rq = NULL;
133 unsigned int min_jobs = UINT_MAX, num_jobs;
134 int i;
135
While (!mutex_trylock(....))
Sleep()
136 for (i = 0; i < entity->num_rq_list; ++i) {
137 struct drm_gpu_scheduler *sched = entity->rq_list[i]->sched;
138
139 if (!entity->rq_list[i]->sched->ready) { //we take the gpu reset mutex lock, so now sched->ready won't be set to "not ready"
140 DRM_WARN("sched%s is not ready, skipping", sched->name);
141 continue;
142 }
143
144 num_jobs = atomic_read(&sched->num_jobs);
145 if (num_jobs < min_jobs) {
146 min_jobs = num_jobs;
147 rq = entity->rq_list[i];
148 }
149 }
Mutex_unlock(...)
150
151 return rq;
152 }
-----邮件原件-----
发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Liu, Monk
发送时间: 2020年2月20日 21:28
收件人: Li, Dennis <Dennis.Li@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; Zhang, Hawking <Hawking.Zhang@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
主题: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
so the scenario is:
KMD doing page update -> ECC -> baco reset (mute SDMA scheduler) -> drm_sched_entity_get_free_sched() return NULL -> you get your NULL pointer
And your approach is to introduce a bail out in the amdgpu_vm_sdma_commit() so the original amdgpu vm update jobs will be dropped,
That really can fix your NULL pointer issue, but actually bring another issue: you didn't finish the vm update work !
my initial idea is you do something like:
static int amdgpu_vm_sdma_commit(struct amdgpu_vm_update_params *p,
...
struct amdgpu_device *adev = p->adev;
while (!mutex_trylock(&adev->lock_reset)) //means GPU is under recovering
msleep(xxx);
....
mutex_unlock(&adev->lock_reset); //this put at the end of this routine }
that do make our implement more complicated, but at least it doesn't drop the necessary vm update, otherwise you will run into other problems ...
@Koenig, Christian do you have another solution ?
Thanks
-----邮件原件-----
发件人: Li, Dennis <Dennis.Li@amd.com>
发送时间: 2020年2月20日 16:41
收件人: Liu, Monk <Monk.Liu@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; Zhang, Hawking <Hawking.Zhang@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
主题: RE: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
[AMD Official Use Only - Internal Distribution Only]
Hi, Christian and Monk,
When doing SDMA copy, a RAS uncorrectable error happens, which will cause this issue. The RAS uncorrectable error event will trigger driver to do BACO reset which will set the status of SDMA scheduler to no ready. And then drm_sched_entity_get_free_sched will return NULL in drm_sched_entity_select_rq, which cause entity->rq to NULL.
Best Regards
Dennis Li
-----Original Message-----
From: Liu, Monk <Monk.Liu@amd.com>
Sent: Wednesday, February 19, 2020 7:30 PM
To: Koenig, Christian <Christian.Koenig@amd.com>; Zhang, Hawking <Hawking.Zhang@amd.com>; Li, Dennis <Dennis.Li@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
Subject: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
> + if (!entity->rq)
> + return 0;
> +
Yes, supposedly we shouldn't get 'entity->rq == NULL' case , that looks the true bug
-----邮件原件-----
发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Christian K?nig
发送时间: 2020年2月19日 18:50
收件人: Zhang, Hawking <Hawking.Zhang@amd.com>; Li, Dennis <Dennis.Li@amd.com>; amd-gfx@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
主题: Re: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
Well of hand this patch looks like a clear NAK to me.
Returning without raising an error is certainly the wrong thing to do here because we just drop the necessary page table updates.
How does the entity->rq ends up as NULL in the first place?
Regards,
Christian.
Am 19.02.20 um 07:26 schrieb Zhang, Hawking:
> [AMD Official Use Only - Internal Distribution Only]
>
> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
>
> Regards,
> Hawking
> -----Original Message-----
> From: Dennis Li <Dennis.Li@amd.com>
> Sent: Wednesday, February 19, 2020 12:05
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Zhou1, Tao <Tao.Zhou1@amd.com>; Zhang,
> Hawking <Hawking.Zhang@amd.com>; Chen, Guchun <Guchun.Chen@amd.com>
> Cc: Li, Dennis <Dennis.Li@amd.com>
> Subject: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
>
> check whether the queue of entity is null to avoid null pointer dereference.
>
> Change-Id: I08d56774012cf229ba2fe7a011c1359e8d1e2781
> Signed-off-by: Dennis Li <Dennis.Li@amd.com>
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> index 4cc7881f438c..67cca463ddcc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> @@ -95,6 +95,9 @@ static int amdgpu_vm_sdma_commit(struct amdgpu_vm_update_params *p,
> int r;
>
> entity = p->direct ? &p->vm->direct : &p->vm->delayed;
> + if (!entity->rq)
> + return 0;
> +
> ring = container_of(entity->rq->sched, struct amdgpu_ring, sched);
>
> WARN_ON(ib->length_dw == 0);
> --
> 2.17.1
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> nk.liu%40amd.com%7C28e7260af3a24eec758f08d7b52975e3%7C3dd8961fe4884e60
> 8e11a82d994e183d%7C0%7C0%7C637177062003213431&sdata=vMXmhwTlN8lAav
> uqhYhpmKLM6V%2F%2B2%2FubFBbsk%2BGY%2Bjw%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7C7acd21e839804ca7b70e08d7b608b9af%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178021336998643&sdata=cxadPi08Q1dqMZYtodebNWm55GruAr5BOmcsZR%2BFR3M%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7C7acd21e839804ca7b70e08d7b608b9af%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178021336998643&sdata=cxadPi08Q1dqMZYtodebNWm55GruAr5BOmcsZR%2BFR3M%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [RFC PATCH v3 02/27] qcow2: Split cluster_needs_cow() out of count_cow_clusters()
From: Max Reitz @ 2020-02-20 13:32 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <7c18e5c5faed0fd0a630bcaeeac7b175fe4918a7.1577014346.git.berto@igalia.com>
[-- Attachment #1.1: Type: text/plain, Size: 389 bytes --]
On 22.12.19 12:36, Alberto Garcia wrote:
> We are going to need it in other places.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> block/qcow2-cluster.c | 34 +++++++++++++++++++---------------
> 1 file changed, 19 insertions(+), 15 deletions(-)
Reviewed-by: Max Reitz <mreitz@redhat.com>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 02/42] KVM: s390/interrupt: do not pin adapter interrupt pages
From: David Hildenbrand @ 2020-02-20 13:34 UTC (permalink / raw)
To: Christian Borntraeger, Janosch Frank
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
linux-s390, Michael Mueller, Vasily Gorbik
In-Reply-To: <45954200-ccfe-cfac-200d-d1b903d9fc39@de.ibm.com>
>> AFAIK, leaving e->adapter.summary_addr set is not an issue.
>>
>> Interesting, in kvm_s390_adapter_map(), we didn't synchronize again slot
>> updates when doing the gmap_translate(), which looks wrong to me ...
>>
>> It seems to be the same thing here. I do wonder if it is safe to do a
>> gmap_translate() here, looks like this can race with
>> kvm_arch_commit_memory_region().
>>
>> I would have assumed we need e.g., the slots_lock while doing the
>> gmap_translate() - or a srcu_read_lock(&vcpu->kvm->srcu) or similar ...
>
> gmap_translate does this via the gmap and it holds the mm sem. gmap_unmap_segment
> takes the same lock. So I think we are ok here.
Ahh, I was looking at __gmap_translate(). Makes sense.
--
Thanks,
David / dhildenb
^ permalink raw reply
* [igt-dev] [PATCH i-g-t v2] tools/i915-perf: workaround overzelous compiler warnings
From: Lionel Landwerlin @ 2020-02-20 13:34 UTC (permalink / raw)
To: igt-dev
Take 2.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
---
tools/i915-perf/i915_perf_recorder_commands.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/i915-perf/i915_perf_recorder_commands.h b/tools/i915-perf/i915_perf_recorder_commands.h
index 4855d80f..44dd4438 100644
--- a/tools/i915-perf/i915_perf_recorder_commands.h
+++ b/tools/i915-perf/i915_perf_recorder_commands.h
@@ -35,5 +35,6 @@ struct recorder_command_base {
};
struct recorder_command_dump {
- uint8_t path[0];
+ uint8_t unused;
+ uint8_t path[];
};
--
2.25.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH] drm/i915/selftest: Analyse timestamp behaviour across context switches
From: kbuild test robot @ 2020-02-20 13:34 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20200217105631.613471-1-chris@chris-wilson.co.uk>
[-- Attachment #1: Type: text/plain, Size: 9479 bytes --]
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to drm-tip/drm-tip v5.6-rc2 next-20200220]
[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/Chris-Wilson/drm-i915-selftest-Analyse-timestamp-behaviour-across-context-switches/20200219-105719
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-c002-20200220 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5367:0:
drivers/gpu/drm/i915/gt/selftest_lrc.c: In function 'emit_timestamp_release':
>> drivers/gpu/drm/i915/gt/selftest_lrc.c:4517:6: error: unused variable 'err' [-Werror=unused-variable]
int err;
^~~
Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_read
Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_write
Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:arch_set_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:arch___set_bit
Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:arch_clear_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:arch_clear_bit_unlock
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:arch_test_and_set_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:variable_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:__ffs
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:ffs
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-atomic.h:set_bit
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-atomic.h:clear_bit
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-atomic.h:test_and_set_bit
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-non-atomic.h:__set_bit
Cyclomatic Complexity 1 include/asm-generic/bitops/instrumented-lock.h:clear_bit_unlock
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
Cyclomatic Complexity 1 arch/x86/include/asm/div64.h:mul_u32_u32
Cyclomatic Complexity 1 arch/x86/include/asm/string_32.h:memset32
Cyclomatic Complexity 1 include/linux/string.h:memset_p
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_read
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_inc
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec_and_test
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_fetch_add
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_fetch_sub
Cyclomatic Complexity 2 arch/x86/include/asm/atomic.h:arch_atomic_try_cmpxchg
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_read
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_fetch_add
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_fetch_sub
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_inc
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_dec
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_try_cmpxchg
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_dec_and_test
Cyclomatic Complexity 1 include/linux/atomic-fallback.h:atomic_fetch_inc
Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
Cyclomatic Complexity 1 include/linux/list.h:__list_del
Cyclomatic Complexity 1 include/linux/list.h:list_is_last
Cyclomatic Complexity 1 include/linux/list.h:list_empty
Cyclomatic Complexity 1 arch/x86/include/asm/special_insns.h:clflush
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 1 include/linux/err.h:ERR_CAST
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:native_irq_disable
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:native_irq_enable
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_local_irq_disable
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_local_irq_enable
Cyclomatic Complexity 1 arch/x86/include/asm/processor.h:rep_nop
Cyclomatic Complexity 1 arch/x86/include/asm/processor.h:cpu_relax
Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_add
Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_sub
Cyclomatic Complexity 1 include/linux/bottom_half.h:__local_bh_disable_ip
Cyclomatic Complexity 1 include/linux/bottom_half.h:local_bh_disable
Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_irq
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irq
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readl
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writel
Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_lock
Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_unlock
Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_read_lock
Cyclomatic Complexity 1 include/linux/rbtree.h:rb_link_node
Cyclomatic Complexity 3 include/linux/overflow.h:__ab_c_size
Cyclomatic Complexity 1 include/linux/seqlock.h:raw_write_seqcount_begin
Cyclomatic Complexity 1 include/linux/seqlock.h:raw_write_seqcount_end
Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
Cyclomatic Complexity 1 include/linux/ktime.h:ktime_to_ns
Cyclomatic Complexity 3 include/linux/ktime.h:ktime_compare
Cyclomatic Complexity 1 include/linux/ktime.h:ktime_after
Cyclomatic Complexity 1 include/linux/timer.h:timer_pending
Cyclomatic Complexity 1 include/linux/interrupt.h:tasklet_disable_nosync
Cyclomatic Complexity 1 include/linux/interrupt.h:tasklet_enable
Cyclomatic Complexity 3 include/linux/slab.h:kmalloc_type
Cyclomatic Complexity 28 include/linux/slab.h:kmalloc_index
Cyclomatic Complexity 1 include/linux/slab.h:kmalloc_large
Cyclomatic Complexity 4 include/linux/slab.h:kmalloc
Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
Cyclomatic Complexity 1 include/linux/dma-resv.h:dma_resv_get_list
Cyclomatic Complexity 1 include/drm/drm_print.h:drm_info_printer
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_reg.h:i915_mmio_reg_offset
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_utils.h:msecs_to_jiffies_timeout
Cyclomatic Complexity 3 drivers/gpu/drm/i915/i915_utils.h:timer_expired
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_gem.h:__tasklet_is_enabled
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_gem.h:__tasklet_enable
Cyclomatic Complexity 1 drivers/gpu/drm/i915/gt/intel_engine_types.h:intel_engine_has_preemption
Cyclomatic Complexity 1 drivers/gpu/drm/i915/gt/intel_engine_types.h:intel_engine_has_semaphores
Cyclomatic Complexity 1 drivers/gpu/drm/i915/gt/intel_engine_types.h:intel_engine_has_relative_mmio
Cyclomatic Complexity 1 drivers/gpu/drm/i915/gt/intel_context_types.h:ewma_runtime_read
Cyclomatic Complexity 2 drivers/gpu/drm/i915/gt/intel_context_types.h:ewma_runtime_add
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_request.h:to_request
Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_request.h:i915_seqno_passed
vim +/err +4517 drivers/gpu/drm/i915/gt/selftest_lrc.c
4508
4509 static int
4510 emit_timestamp_release(struct intel_context *ce, void *slot)
4511 {
4512 const u32 offset =
4513 i915_ggtt_offset(ce->engine->status_page.vma) +
4514 offset_in_page(slot);
4515 struct i915_request *rq;
4516 u32 *cs;
> 4517 int err;
4518
4519 rq = intel_context_create_request(ce);
4520 if (IS_ERR(rq))
4521 return PTR_ERR(rq);
4522
4523 cs = intel_ring_begin(rq, 4);
4524 if (IS_ERR(cs)) {
4525 i915_request_add(rq);
4526 return PTR_ERR(cs);
4527 }
4528
4529 *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
4530 *cs++ = offset;
4531 *cs++ = 0;
4532 *cs++ = 1;
4533
4534 intel_ring_advance(rq, cs);
4535 i915_request_add(rq);
4536 return 0;
4537 }
4538
---
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: 39529 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next 1/2] RDMA/ipoib: Don't set constant driver version
From: Dennis Dalessandro @ 2020-02-20 13:34 UTC (permalink / raw)
To: Leon Romanovsky, Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list
In-Reply-To: <20200220071239.231800-2-leon@kernel.org>
On 2/20/2020 2:12 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> There is no need to set driver version in in-tree kernel code.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/infiniband/ulp/ipoib/ipoib.h | 2 --
> drivers/infiniband/ulp/ipoib/ipoib_ethtool.c | 3 ---
> drivers/infiniband/ulp/ipoib/ipoib_main.c | 4 ----
> 3 files changed, 9 deletions(-)
>
Same comments as the other patch, can we just remove the field from the
drvinfo struct altogether.
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
^ permalink raw reply
* Re: [PATCH v5 03/12] ceph: add infrastructure for waiting for async create to complete
From: Yan, Zheng @ 2020-02-20 13:33 UTC (permalink / raw)
To: Jeff Layton
Cc: ceph-devel, Ilya Dryomov, Sage Weil, Zheng Yan, Patrick Donnelly,
Xiubo Li
In-Reply-To: <89ba8857af29c0e877d22e2188f86142f316454a.camel@kernel.org>
On Thu, Feb 20, 2020 at 9:01 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Thu, 2020-02-20 at 11:32 +0800, Yan, Zheng wrote:
> > On Wed, Feb 19, 2020 at 9:27 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > When we issue an async create, we must ensure that any later on-the-wire
> > > requests involving it wait for the create reply.
> > >
> > > Expand i_ceph_flags to be an unsigned long, and add a new bit that
> > > MDS requests can wait on. If the bit is set in the inode when sending
> > > caps, then don't send it and just return that it has been delayed.
> > >
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > > fs/ceph/caps.c | 13 ++++++++++++-
> > > fs/ceph/dir.c | 2 +-
> > > fs/ceph/mds_client.c | 20 +++++++++++++++++++-
> > > fs/ceph/mds_client.h | 7 +++++++
> > > fs/ceph/super.h | 4 +++-
> > > 5 files changed, 42 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> > > index d05717397c2a..85e13aa359d2 100644
> > > --- a/fs/ceph/caps.c
> > > +++ b/fs/ceph/caps.c
> > > @@ -511,7 +511,7 @@ static void __cap_delay_requeue(struct ceph_mds_client *mdsc,
> > > struct ceph_inode_info *ci,
> > > bool set_timeout)
> > > {
> > > - dout("__cap_delay_requeue %p flags %d at %lu\n", &ci->vfs_inode,
> > > + dout("__cap_delay_requeue %p flags 0x%lx at %lu\n", &ci->vfs_inode,
> > > ci->i_ceph_flags, ci->i_hold_caps_max);
> > > if (!mdsc->stopping) {
> > > spin_lock(&mdsc->cap_delay_lock);
> > > @@ -1294,6 +1294,13 @@ static int __send_cap(struct ceph_mds_client *mdsc, struct ceph_cap *cap,
> > > int delayed = 0;
> > > int ret;
> > >
> > > + /* Don't send anything if it's still being created. Return delayed */
> > > + if (ci->i_ceph_flags & CEPH_I_ASYNC_CREATE) {
> > > + spin_unlock(&ci->i_ceph_lock);
> > > + dout("%s async create in flight for %p\n", __func__, inode);
> > > + return 1;
> > > + }
> > > +
> >
> > Maybe it's better to check this in ceph_check_caps(). Other callers
> > of __send_cap() shouldn't encounter async creating inode
> >
>
> I've been looking, but what actually guarantees that?
>
> Only ceph_check_caps calls it for UPDATE, but the other two callers call
> it for FLUSH. I don't see what prevents the kernel from (e.g.) calling
> write_inode before the create reply comes in, particularly if we just
> create and then close the file.
>
I missed write_inode case. but make __send_cap() skip sending message
can cause problem. For example, if we skip a message that flush dirty
caps. call ceph_check_caps() again may not re-do the flush.
> As a side note, I still struggle with the fact thatthere seems to be no
> coherent overall description of the cap protocol. What distinguishes a
> FLUSH from an UPDATE, for instance? The MDS code and comments seem to
> treat them somewhat interchangeably.
>
UPDATE is super set of FLUSH, UPDATE can always replace FLUSH.
>
> > > held = cap->issued | cap->implemented;
> > > revoking = cap->implemented & ~cap->issued;
> > > retain &= ~revoking;
> > > @@ -2250,6 +2257,10 @@ int ceph_fsync(struct file *file, loff_t start, loff_t end, int datasync)
> > > if (datasync)
> > > goto out;
> > >
> > > + ret = ceph_wait_on_async_create(inode);
> > > + if (ret)
> > > + goto out;
> > > +
> > > dirty = try_flush_caps(inode, &flush_tid);
> > > dout("fsync dirty caps are %s\n", ceph_cap_string(dirty));
> > >
> > > diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> > > index a87274935a09..5b83bda57056 100644
> > > --- a/fs/ceph/dir.c
> > > +++ b/fs/ceph/dir.c
> > > @@ -752,7 +752,7 @@ static struct dentry *ceph_lookup(struct inode *dir, struct dentry *dentry,
> > > struct ceph_dentry_info *di = ceph_dentry(dentry);
> > >
> > > spin_lock(&ci->i_ceph_lock);
> > > - dout(" dir %p flags are %d\n", dir, ci->i_ceph_flags);
> > > + dout(" dir %p flags are 0x%lx\n", dir, ci->i_ceph_flags);
> > > if (strncmp(dentry->d_name.name,
> > > fsc->mount_options->snapdir_name,
> > > dentry->d_name.len) &&
> > > diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> > > index 94d18e643a3d..38eb9dd5062b 100644
> > > --- a/fs/ceph/mds_client.c
> > > +++ b/fs/ceph/mds_client.c
> > > @@ -2730,7 +2730,7 @@ static void kick_requests(struct ceph_mds_client *mdsc, int mds)
> > > int ceph_mdsc_submit_request(struct ceph_mds_client *mdsc, struct inode *dir,
> > > struct ceph_mds_request *req)
> > > {
> > > - int err;
> > > + int err = 0;
> > >
> > > /* take CAP_PIN refs for r_inode, r_parent, r_old_dentry */
> > > if (req->r_inode)
> > > @@ -2743,6 +2743,24 @@ int ceph_mdsc_submit_request(struct ceph_mds_client *mdsc, struct inode *dir,
> > > ceph_get_cap_refs(ceph_inode(req->r_old_dentry_dir),
> > > CEPH_CAP_PIN);
> > >
> > > + if (req->r_inode) {
> > > + err = ceph_wait_on_async_create(req->r_inode);
> > > + if (err) {
> > > + dout("%s: wait for async create returned: %d\n",
> > > + __func__, err);
> > > + return err;
> > > + }
> > > + }
> > > +
> > > + if (!err && req->r_old_inode) {
> > > + err = ceph_wait_on_async_create(req->r_old_inode);
> > > + if (err) {
> > > + dout("%s: wait for async create returned: %d\n",
> > > + __func__, err);
> > > + return err;
> > > + }
> > > + }
> > > +
> > > dout("submit_request on %p for inode %p\n", req, dir);
> > > mutex_lock(&mdsc->mutex);
> > > __register_request(mdsc, req, dir);
> > > diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h
> > > index 95ac00e59e66..8043f2b439b1 100644
> > > --- a/fs/ceph/mds_client.h
> > > +++ b/fs/ceph/mds_client.h
> > > @@ -538,4 +538,11 @@ extern void ceph_mdsc_open_export_target_sessions(struct ceph_mds_client *mdsc,
> > > extern int ceph_trim_caps(struct ceph_mds_client *mdsc,
> > > struct ceph_mds_session *session,
> > > int max_caps);
> > > +static inline int ceph_wait_on_async_create(struct inode *inode)
> > > +{
> > > + struct ceph_inode_info *ci = ceph_inode(inode);
> > > +
> > > + return wait_on_bit(&ci->i_ceph_flags, CEPH_ASYNC_CREATE_BIT,
> > > + TASK_INTERRUPTIBLE);
> > > +}
> > > #endif
> > > diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> > > index 3430d7ffe8f7..bfb03adb4a08 100644
> > > --- a/fs/ceph/super.h
> > > +++ b/fs/ceph/super.h
> > > @@ -316,7 +316,7 @@ struct ceph_inode_info {
> > > u64 i_inline_version;
> > > u32 i_time_warp_seq;
> > >
> > > - unsigned i_ceph_flags;
> > > + unsigned long i_ceph_flags;
> > > atomic64_t i_release_count;
> > > atomic64_t i_ordered_count;
> > > atomic64_t i_complete_seq[2];
> > > @@ -524,6 +524,8 @@ static inline struct inode *ceph_find_inode(struct super_block *sb,
> > > #define CEPH_I_ERROR_WRITE (1 << 10) /* have seen write errors */
> > > #define CEPH_I_ERROR_FILELOCK (1 << 11) /* have seen file lock errors */
> > > #define CEPH_I_ODIRECT (1 << 12) /* inode in direct I/O mode */
> > > +#define CEPH_ASYNC_CREATE_BIT (13) /* async create in flight for this */
> > > +#define CEPH_I_ASYNC_CREATE (1 << CEPH_ASYNC_CREATE_BIT)
> > >
> > > /*
> > > * Masks of ceph inode work.
> > > --
> > > 2.24.1
> > >
>
> --
> Jeff Layton <jlayton@kernel.org>
>
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] media: tegra: Add Tegra210 Video input driver
From: Hans Verkuil @ 2020-02-20 13:33 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, frankc,
helen.koike, sboyd
Cc: linux-media, devicetree, linux-clk, linux-tegra, linux-kernel
In-Reply-To: <b301c247-537d-d78e-b057-a3225b10de7e@xs4all.nl>
(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().
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: Hans Verkuil @ 2020-02-20 13:33 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, frankc-DDmLM1+adcrQT0dZR+AlfA,
helen.koike-ZGY8ohtN/8qB+jHODAdFcQ, sboyd-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b301c247-537d-d78e-b057-a3225b10de7e-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
(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().
It's worth getting this right in this early stage, rather than fixing it
in the future.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v9 1/3] Acceptance tests: introduce BUILD_DIR and SOURCE_DIR
From: Wainer dos Santos Moschetta @ 2020-02-20 13:31 UTC (permalink / raw)
To: Cleber Rosa, qemu-devel
Cc: Fam Zheng, Eduardo Habkost, Alex Bennée, Willian Rampazzo,
Philippe Mathieu-Daudé, Beraldo Leal
In-Reply-To: <20200220020652.16276-2-crosa@redhat.com>
On 2/19/20 11:06 PM, Cleber Rosa wrote:
> Some tests may benefit from using resources from a build directory.
> This introduces three variables that can help tests find resources in
> those directories.
>
> First, a BUILD_DIR is assumed to exist, given that the primary form of
> running the acceptance tests is from a build directory (which may or
> may not be the same as the source tree, that is, the SOURCE_DIR).
>
> If the directory containing the acceptance tests happens to be a link
> to a directory, it's assumed to it points to the source tree
> (SOURCE_DIR), which is the behavior defined on the QEMU Makefiles. If
> the directory containing the acceptance tests is not a link, then a
> in-tree build is assumed, and the BUILD_DIR and SOURCE_DIR have the
> same value.
>
> Signed-off-by: Cleber Rosa <crosa@redhat.com>
> ---
> tests/acceptance/avocado_qemu/__init__.py | 25 +++++++++++++++++------
> 1 file changed, 19 insertions(+), 6 deletions(-)
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Also tested with QEMU built outside of source dir:
Tested-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
>
> diff --git a/tests/acceptance/avocado_qemu/__init__.py b/tests/acceptance/avocado_qemu/__init__.py
> index d4358eb431..59e7b4f763 100644
> --- a/tests/acceptance/avocado_qemu/__init__.py
> +++ b/tests/acceptance/avocado_qemu/__init__.py
> @@ -16,8 +16,21 @@ import tempfile
>
> import avocado
>
> -SRC_ROOT_DIR = os.path.join(os.path.dirname(__file__), '..', '..', '..')
> -sys.path.append(os.path.join(SRC_ROOT_DIR, 'python'))
> +#: The QEMU build root directory. It may also be the source directory
> +#: if building from the source dir, but it's safer to use BUILD_DIR for
> +#: that purpose. Be aware that if this code is moved outside of a source
> +#: and build tree, it will not be accurate.
> +BUILD_DIR = os.path.dirname(os.path.dirname(os.path.dirname(os.path.dirname(__file__))))
> +
> +if os.path.islink(os.path.dirname(os.path.dirname(__file__))):
> + # The link to the acceptance tests dir in the source code directory
> + lnk = os.path.dirname(os.path.dirname(__file__))
> + #: The QEMU root source directory
> + SOURCE_DIR = os.path.dirname(os.path.dirname(os.readlink(lnk)))
> +else:
> + SOURCE_DIR = BUILD_DIR
> +
> +sys.path.append(os.path.join(SOURCE_DIR, 'python'))
>
> from qemu.machine import QEMUMachine
>
> @@ -49,10 +62,10 @@ def pick_default_qemu_bin(arch=None):
> if is_readable_executable_file(qemu_bin_relative_path):
> return qemu_bin_relative_path
>
> - qemu_bin_from_src_dir_path = os.path.join(SRC_ROOT_DIR,
> + qemu_bin_from_bld_dir_path = os.path.join(BUILD_DIR,
> qemu_bin_relative_path)
> - if is_readable_executable_file(qemu_bin_from_src_dir_path):
> - return qemu_bin_from_src_dir_path
> + if is_readable_executable_file(qemu_bin_from_bld_dir_path):
> + return qemu_bin_from_bld_dir_path
>
>
> def _console_interaction(test, success_message, failure_message,
> @@ -153,7 +166,7 @@ class Test(avocado.Test):
> self.qemu_bin = self.params.get('qemu_bin',
> default=default_qemu_bin)
> if self.qemu_bin is None:
> - self.cancel("No QEMU binary defined or found in the source tree")
> + self.cancel("No QEMU binary defined or found in the build tree")
>
> def _new_vm(self, *args):
> vm = QEMUMachine(self.qemu_bin, sock_dir=tempfile.mkdtemp())
^ permalink raw reply
* Re: [PATCH rdma-next 2/2] RDMA/opa_vnic: Delete driver version
From: Dennis Dalessandro @ 2020-02-20 13:32 UTC (permalink / raw)
To: Leon Romanovsky, Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list
In-Reply-To: <20200220071239.231800-3-leon@kernel.org>
On 2/20/2020 2:12 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> The default version provided by "ethtool -i" it the correct way
> to identify Driver version. There is no need to overwrite it.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c | 2 --
> drivers/infiniband/ulp/opa_vnic/opa_vnic_internal.h | 1 -
> drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c | 5 -----
> 3 files changed, 8 deletions(-)
>
> diff --git a/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c b/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c
> index 8ad7da989a0e..42d557dff19d 100644
> --- a/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c
> +++ b/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c
> @@ -125,8 +125,6 @@ static void vnic_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *drvinfo)
> {
> strlcpy(drvinfo->driver, opa_vnic_driver_name, sizeof(drvinfo->driver));
> - strlcpy(drvinfo->version, opa_vnic_driver_version,
> - sizeof(drvinfo->version));
> strlcpy(drvinfo->bus_info, dev_name(netdev->dev.parent),
> sizeof(drvinfo->bus_info));
> }
Is there a patch series to get rid of drvinfo->version? Seems to me if
we don't want drivers to set it then we don't need it to begin with do we?
Regardless I don't have any objections to the patch. We've been down
this road with version numbers and I believe this was added to vnic
specifically to fill in something for ethtool.
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
-Denny
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 13:32 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Vladimir Murzin, Russell King, kvm, Arnd Bergmann, Quentin Perret,
Suzuki K Poulose, Christoffer Dall, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, James Morse, linux-arm-kernel,
Paolo Bonzini, Will Deacon, kvmarm, Julien Thierry
In-Reply-To: <43446bd5e884ae92f243799cbe748871@kernel.org>
On 20/02/2020 1:15 pm, Marc Zyngier wrote:
> Hi Marek,
>
> On 2020-02-20 12:44, Marek Szyprowski wrote:
>> Hi Marc,
>>
>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
>
> The current proposal is to still have KVM support in 5.6, as well as
> ongoing support for stable kernels. If that's not enough, can you please
> explain your precise use case?
Presumably there's no *technical* reason why the stable subset of v7
support couldn't be stripped down and brought back private to arch/arm
if somebody really wants and is willing to step up and look after it?
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 13:32 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Russell King, kvm, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, linux-arm-kernel, Paolo Bonzini,
Will Deacon, kvmarm
In-Reply-To: <43446bd5e884ae92f243799cbe748871@kernel.org>
On 20/02/2020 1:15 pm, Marc Zyngier wrote:
> Hi Marek,
>
> On 2020-02-20 12:44, Marek Szyprowski wrote:
>> Hi Marc,
>>
>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
>
> The current proposal is to still have KVM support in 5.6, as well as
> ongoing support for stable kernels. If that's not enough, can you please
> explain your precise use case?
Presumably there's no *technical* reason why the stable subset of v7
support couldn't be stripped down and brought back private to arch/arm
if somebody really wants and is willing to step up and look after it?
Robin.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 13:32 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Vladimir Murzin, Russell King, kvm, Arnd Bergmann,
Suzuki K Poulose, Quentin Perret, Christoffer Dall,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz, James Morse,
Julien Thierry, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <43446bd5e884ae92f243799cbe748871@kernel.org>
On 20/02/2020 1:15 pm, Marc Zyngier wrote:
> Hi Marek,
>
> On 2020-02-20 12:44, Marek Szyprowski wrote:
>> Hi Marc,
>>
>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
>
> The current proposal is to still have KVM support in 5.6, as well as
> ongoing support for stable kernels. If that's not enough, can you please
> explain your precise use case?
Presumably there's no *technical* reason why the stable subset of v7
support couldn't be stripped down and brought back private to arch/arm
if somebody really wants and is willing to step up and look after it?
Robin.
^ permalink raw reply
* [PATCH] mt76: mt76u: rely only on data buffer for usb control messagges
From: Lorenzo Bianconi @ 2020-02-20 13:31 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, stf_xl
Starting from commit 'a6bfb6d13f33 ("mt76: usb: use max packet length
for m76u_copy")' reg_val does not share memory with usb data buffer.
On non-coherent devices this approach can corrupt data pointer since data
and reg_val share the same cache-line, resulting in the following crash:
[ 371.544901] CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 8042fbb0
[ 371.558521] CPU: 0 PID: 11 Comm: kworker/u2:2 Not tainted 4.14.160 #0
[ 371.565204] Workqueue: mt76u mt76u_deinit [mt76_usb]
[ 371.570331] task: 83823ac0 task.stack: 8386c000
[ 371.575004] $ 0 : 00000000 80590000 00000000 00000000
[ 371.580407] $ 4 : 82edaad0 00000002 83823ac0 fffffff8
[ 371.585810] $ 8 : fffffffd 0000fc00 8052da00 00000000
[ 371.591212] $12 : 000b2285 ae53a1a9 00108845 89da44c4
[ 371.596615] $16 : 82edaad0 82ed9d20 00001798 832edf00
[ 371.602019] $20 : 00000000 8386dda8 80530000 fffffffe
[ 371.607421] $24 : 8051d040 76274d1b
[ 371.612824] $28 : 8386c000 8386dd88 82edaad4 830d4d50
[ 371.618228] Hi : 000000f7
[ 371.621203] Lo : 33333371
[ 371.624196] epc : 8042fbb0 __mutex_lock.isra.2+0x134/0x378
[ 371.630043] ra : 830d4d50 mt76u_deinit+0x418/0xa6c [mt76_usb]
[ 371.636237] Status: 1000fc03KERNEL EXL IE
[ 371.640557] Cause : 0080000c (ExcCode 03)
[ 371.644696] BadVA : 00000000
[ 371.647671] PrId : 00019374 (MIPS 24Kc)
[ 371.726123] usbcore nls_base usb_common
[ 371.730180] Process kworker/u2:2 (pid: 11, threadinfo=8386c000, task=83823ac0, tls=00000000)
[ 371.738884] Stack : 833d009c 83210b4c 82ed8bc0 8386ddac 000001ff 8008ac50 8386ddac 83b74b00
[ 371.747519] 82edaad4 00000000 83b74b48 83210c38 82edaad0 82ed9d20 00001798 832edf00
[ 371.756157] 00000000 00000000 80530000 fffffffe 80530000 830d4d50 00000040 8389d850
[ 371.764794] 8052d9d8 8389d850 8386de30 82ed9d20 8386de5f 831c27bc 833d48ec 8052d9d8
[ 371.773431] 83823ac0 83823af0 82edab00 82ed9d20 8386de5f 831c5c30 00000000 8052d9a8
[ 371.782069] ...
[ 371.784598] Call Trace:
[ 371.787130] [<8042fbb0>] __mutex_lock.isra.2+0x134/0x378
[ 371.792622] [<830d4d50>] mt76u_deinit+0x418/0xa6c [mt76_usb]
[ 371.808546]
[ 371.810920] ---[ end trace c62f0601f6730eb0 ]---
[ 371.818101] Kernel panic - not syncing: Fatal exception
[ 371.824420] Rebooting in 3 seconds..
Fix the issue relying only on data buffer to send/receive usb control messages
Fixes: a6bfb6d13f33 ("mt76: usb: use max packet length for m76u_copy")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 1 -
drivers/net/wireless/mediatek/mt76/usb.c | 8 ++++----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 2e57e7c6bd29..aca477434858 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -403,7 +403,6 @@ struct mt76_mcu {
#define MCU_RESP_URB_SIZE 1024
struct mt76_usb {
struct mutex usb_ctrl_mtx;
- __le32 reg_val;
u8 *data;
u16 data_len;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 2c0dbc36f9aa..3535577db1c6 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -70,10 +70,10 @@ static u32 ___mt76u_rr(struct mt76_dev *dev, u8 req, u32 addr)
ret = __mt76u_vendor_request(dev, req,
USB_DIR_IN | USB_TYPE_VENDOR,
- addr >> 16, addr, &usb->reg_val,
+ addr >> 16, addr, usb->data,
sizeof(__le32));
if (ret == sizeof(__le32))
- data = le32_to_cpu(usb->reg_val);
+ data = get_unaligned_le32(usb->data);
trace_usb_reg_rr(dev, addr, data);
return data;
@@ -125,10 +125,10 @@ static void ___mt76u_wr(struct mt76_dev *dev, u8 req,
{
struct mt76_usb *usb = &dev->usb;
- usb->reg_val = cpu_to_le32(val);
+ put_unaligned_le32(val, usb->data);
__mt76u_vendor_request(dev, req,
USB_DIR_OUT | USB_TYPE_VENDOR,
- addr >> 16, addr, &usb->reg_val,
+ addr >> 16, addr, usb->data,
sizeof(__le32));
trace_usb_reg_wr(dev, addr, val);
}
--
2.24.1
^ permalink raw reply related
* [Xen-devel] [XEN PATCH v2] libxl: wait for console path before firing console_available
From: Paweł Marczewski @ 2020-02-20 13:31 UTC (permalink / raw)
To: xen-devel
Cc: Anthony PERARD, Paweł Marczewski, Ian Jackson,
Marek Marczykowski-Górecki, Wei Liu
If we skip the bootloader, the TTY path will be set for xenconsoled.
However, there is no guarantee that this will happen by the time we
want to call the console_available callback, so we have to wait.
Signed-off-by: Paweł Marczewski <pawel@invisiblethingslab.com>
---
Changed since v1:
* use xswait mechanism to add a timeout
As mentioned before, this is to fix a race condition that appears when
using libxl via libvirt and not using bootloader (console_available
fires too early).
I have tested the patch on Qubes OS 4.1 (with Xen 4.13), and it seems
to solve the problem. I also checked the timeout: when xenconsoled is
stopped, libxl waits for 10 seconds and then aborts domain creation.
tools/libxl/libxl_create.c | 43 +++++++++++++++++++++++++++++++++---
tools/libxl/libxl_internal.h | 1 +
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3a7364e2ac..4b150d92b9 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1190,6 +1190,33 @@ static void domcreate_console_available(libxl__egc *egc,
dcs->aop_console_how.for_event));
}
+static void console_xswait_callback(libxl__egc *egc, libxl__xswait_state *xswa,
+ int rc, const char *p)
+{
+ EGC_GC;
+ libxl__domain_create_state *dcs = CONTAINER_OF(xswa, *dcs, console_xswait);
+ char *dompath = libxl__xs_get_dompath(gc, dcs->guest_domid);
+ char *tty_path = GCSPRINTF("%s/console/tty", dompath);
+ char *tty;
+
+ if (rc) {
+ if (rc == ERROR_TIMEDOUT)
+ LOG(ERROR, "%s: timed out", xswa->what);
+ libxl__xswait_stop(gc, xswa);
+ domcreate_complete(egc, dcs, rc);
+ return;
+ }
+
+ tty = libxl__xs_read(gc, XBT_NULL, tty_path);
+
+ if (tty && tty[0] != '\0') {
+ libxl__xswait_stop(gc, xswa);
+
+ domcreate_console_available(egc, dcs);
+ domcreate_complete(egc, dcs, 0);
+ }
+}
+
static void domcreate_bootloader_done(libxl__egc *egc,
libxl__bootloader_state *bl,
int rc)
@@ -1728,9 +1755,18 @@ static void domcreate_attach_devices(libxl__egc *egc,
return;
}
- domcreate_console_available(egc, dcs);
-
- domcreate_complete(egc, dcs, 0);
+ dcs->console_xswait.ao = ao;
+ dcs->console_xswait.what = GCSPRINTF("domain %d console tty", domid);
+ dcs->console_xswait.path = GCSPRINTF("%s/console/tty",
+ libxl__xs_get_dompath(gc, domid));
+ dcs->console_xswait.timeout_ms = 10 * 1000;
+ dcs->console_xswait.callback = console_xswait_callback;
+ ret = libxl__xswait_start(gc, &dcs->console_xswait);
+ if (ret) {
+ LOG(ERROR, "unable to set up watch for domain %d console path",
+ domid);
+ goto error_out;
+ }
return;
@@ -1861,6 +1897,7 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
cdcs->domid_out = domid;
+ libxl__xswait_init(&cdcs->dcs.console_xswait);
initiate_domain_create(egc, &cdcs->dcs);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4936446069..d8129417dc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4180,6 +4180,7 @@ struct libxl__domain_create_state {
/* necessary if the domain creation failed and we have to destroy it */
libxl__domain_destroy_state dds;
libxl__multidev multidev;
+ libxl__xswait_state console_xswait;
};
_hidden int libxl__device_nic_set_devids(libxl__gc *gc,
--
2.21.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH v2 02/42] KVM: s390/interrupt: do not pin adapter interrupt pages
From: Christian Borntraeger @ 2020-02-20 13:31 UTC (permalink / raw)
To: David Hildenbrand, Janosch Frank
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
linux-s390, Michael Mueller, Vasily Gorbik
In-Reply-To: <073d3666-480e-5ba5-a46b-4cbd615f4174@redhat.com>
On 17.02.20 10:43, David Hildenbrand wrote:
> On 14.02.20 23:26, Christian Borntraeger wrote:
>> From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
>>
>> The adapter interrupt page containing the indicator bits is currently
>> pinned. That means that a guest with many devices can pin a lot of
>> memory pages in the host. This also complicates the reference tracking
>> which is needed for memory management handling of protected virtual
>> machines. It might also have some strange side effects for madvise
>> MADV_DONTNEED and other things.
>>
>> We can simply try to get the userspace page set the bits and free the
>> page. By storing the userspace address in the irq routing entry instead
>> of the guest address we can actually avoid many lookups and list walks
>> so that this variant is very likely not slower.
>>
>> If userspace messes around with the memory slots the worst thing that
>> can happen is that we write to some other memory within that process.
>> As we get the the page with FOLL_WRITE this can also not be used to
>> write to shared read-only pages.
>>
>> Signed-off-by: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
>> [borntraeger@de.ibm.com: patch simplification]
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>> Documentation/virt/kvm/devices/s390_flic.rst | 11 +-
>> arch/s390/include/asm/kvm_host.h | 3 -
>> arch/s390/kvm/interrupt.c | 170 ++++++-------------
>> 3 files changed, 53 insertions(+), 131 deletions(-)
>>
>> diff --git a/Documentation/virt/kvm/devices/s390_flic.rst b/Documentation/virt/kvm/devices/s390_flic.rst
>> index 954190da7d04..ea96559ba501 100644
>> --- a/Documentation/virt/kvm/devices/s390_flic.rst
>> +++ b/Documentation/virt/kvm/devices/s390_flic.rst
>> @@ -108,16 +108,9 @@ Groups:
>> mask or unmask the adapter, as specified in mask
>>
>> KVM_S390_IO_ADAPTER_MAP
>> - perform a gmap translation for the guest address provided in addr,
>> - pin a userspace page for the translated address and add it to the
>> - list of mappings
>> -
>> - .. note:: A new mapping will be created unconditionally; therefore,
>> - the calling code should avoid making duplicate mappings.
>> -
>> + This is now a no-op. The mapping is purely done by the irq route.
>> KVM_S390_IO_ADAPTER_UNMAP
>> - release a userspace page for the translated address specified in addr
>> - from the list of mappings
>> + This is now a no-op. The mapping is purely done by the irq route.
>>
>
> The interface should have accepted a hva from the very start and not
> guest addresses ...
right, but that is history.
>
> [...]
>> + /*
>> + * We resolve the gpa to hva when setting the IRQ routing. the set_irq
>> + * code uses get_user_pages_remote to do the actual write.
>
> nit: "get_user_pages_remote()"
ack.
>
>> + */
>> case KVM_S390_IO_ADAPTER_MAP:
>> - ret = kvm_s390_adapter_map(dev->kvm, req.id, req.addr);
>> - break;
>> case KVM_S390_IO_ADAPTER_UNMAP:
>> - ret = kvm_s390_adapter_unmap(dev->kvm, req.id, req.addr);
>> - break;
>> + return 0;
>> default:
>> ret = -EINVAL;
>> }
>> @@ -2699,19 +2622,21 @@ static unsigned long get_ind_bit(__u64 addr, unsigned long bit_nr, bool swap)
>> return swap ? (bit ^ (BITS_PER_LONG - 1)) : bit;
>> }
>>
>> -static struct s390_map_info *get_map_info(struct s390_io_adapter *adapter,
>> - u64 addr)
>> +static struct page *get_map_page(struct kvm *kvm,
>> + struct s390_io_adapter *adapter,
>> + u64 uaddr)
>> {
>> - struct s390_map_info *map;
>> + struct page *page = NULL;
>>
>> if (!adapter)
>> return NULL;
>
> AFAIKs, this check is not necessary.
Right otherwise we would crash earlier.
>
>> -
>> - list_for_each_entry(map, &adapter->maps, list) {
>> - if (map->guest_addr == addr)
>> - return map;
>> - }
>> - return NULL;
>> + if (!uaddr)
>> + return NULL;
>
> I do wonder if that check is necessary. I don't think so but might be
> missing something.
Nothing should break when we remove this check. get_user_pages_remote will
also return NULL (as newer kernels usually forbid mapping things at 0).
Will remove.
[...]
>> @@ -2818,23 +2746,27 @@ int kvm_set_routing_entry(struct kvm *kvm,
>> struct kvm_kernel_irq_routing_entry *e,
>> const struct kvm_irq_routing_entry *ue)
>> {
>> - int ret;
>> + u64 uaddr;
>>
>> switch (ue->type) {
>> + /* we store the userspace addresses instead of the guest addresses */
>> case KVM_IRQ_ROUTING_S390_ADAPTER:
>> e->set = set_adapter_int;
>> - e->adapter.summary_addr = ue->u.adapter.summary_addr;
>> - e->adapter.ind_addr = ue->u.adapter.ind_addr;
>> + uaddr = gmap_translate(kvm->arch.gmap, ue->u.adapter.summary_addr);
>> + if (uaddr == -EFAULT)
>> + return -EFAULT;
>> + e->adapter.summary_addr = uaddr;
>> + uaddr = gmap_translate(kvm->arch.gmap, ue->u.adapter.ind_addr);
>> + if (uaddr == -EFAULT)
>> + return -EFAULT;
>
> AFAIK, leaving e->adapter.summary_addr set is not an issue.
>
> Interesting, in kvm_s390_adapter_map(), we didn't synchronize again slot
> updates when doing the gmap_translate(), which looks wrong to me ...
>
> It seems to be the same thing here. I do wonder if it is safe to do a
> gmap_translate() here, looks like this can race with
> kvm_arch_commit_memory_region().
>
> I would have assumed we need e.g., the slots_lock while doing the
> gmap_translate() - or a srcu_read_lock(&vcpu->kvm->srcu) or similar ...
gmap_translate does this via the gmap and it holds the mm sem. gmap_unmap_segment
takes the same lock. So I think we are ok here.
>
> Apart from that, looks good to me.
>
^ permalink raw reply
* Re: [PATCH v3 1/5] powerpc: Rename current_stack_pointer() to current_stack_frame()
From: Christophe Leroy @ 2020-02-20 13:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200220115141.2707-1-mpe@ellerman.id.au>
Le 20/02/2020 à 12:51, Michael Ellerman a écrit :
> current_stack_pointer(), which was called __get_SP(), used to just
> return the value in r1.
>
> But that caused problems in some cases, so it was turned into a
> function in commit bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a
> function not a define").
>
> Because it's a function in a separate compilation unit to all its
> callers, it has the effect of causing a stack frame to be created, and
> then returns the address of that frame. This is good in some cases
> like those described in the above commit, but in other cases it's
> overkill, we just need to know what stack page we're on.
>
> On some other arches current_stack_pointer is just a register global
> giving the stack pointer, and we'd like to do that too. So rename our
> current_stack_pointer() to current_stack_frame() to make that
> possible.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
LGTM
I was afraid to do that and risk invisible conflicts hence bugs by
reusing the same name for different purpose, but that's the best
solution for sure.
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/include/asm/perf_event.h | 2 +-
> arch/powerpc/include/asm/reg.h | 2 +-
> arch/powerpc/kernel/irq.c | 4 ++--
> arch/powerpc/kernel/misc.S | 4 ++--
> arch/powerpc/kernel/process.c | 2 +-
> arch/powerpc/kernel/stacktrace.c | 6 +++---
> 6 files changed, 10 insertions(+), 10 deletions(-)
>
> v3: New.
>
> diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
> index 7426d7a90e1e..eed3954082fa 100644
> --- a/arch/powerpc/include/asm/perf_event.h
> +++ b/arch/powerpc/include/asm/perf_event.h
> @@ -32,7 +32,7 @@
> do { \
> (regs)->result = 0; \
> (regs)->nip = __ip; \
> - (regs)->gpr[1] = current_stack_pointer(); \
> + (regs)->gpr[1] = current_stack_frame(); \
> asm volatile("mfmsr %0" : "=r" ((regs)->msr)); \
> } while (0)
>
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 1aa46dff0957..1b1ffdba6097 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -1448,7 +1448,7 @@ static inline void mtsrin(u32 val, u32 idx)
>
> #define proc_trap() asm volatile("trap")
>
> -extern unsigned long current_stack_pointer(void);
> +extern unsigned long current_stack_frame(void);
>
> extern unsigned long scom970_read(unsigned int address);
> extern void scom970_write(unsigned int address, unsigned long value);
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 5c9b11878555..02118c18434d 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -602,7 +602,7 @@ static inline void check_stack_overflow(void)
> #ifdef CONFIG_DEBUG_STACKOVERFLOW
> long sp;
>
> - sp = current_stack_pointer() & (THREAD_SIZE-1);
> + sp = current_stack_frame() & (THREAD_SIZE-1);
>
> /* check for stack overflow: is there less than 2KB free? */
> if (unlikely(sp < 2048)) {
> @@ -647,7 +647,7 @@ void do_IRQ(struct pt_regs *regs)
> void *cursp, *irqsp, *sirqsp;
>
> /* Switch to the irq stack to handle this */
> - cursp = (void *)(current_stack_pointer() & ~(THREAD_SIZE - 1));
> + cursp = (void *)(current_stack_frame() & ~(THREAD_SIZE - 1));
> irqsp = hardirq_ctx[raw_smp_processor_id()];
> sirqsp = softirq_ctx[raw_smp_processor_id()];
>
> diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
> index 974f65f79a8e..65f9f731c229 100644
> --- a/arch/powerpc/kernel/misc.S
> +++ b/arch/powerpc/kernel/misc.S
> @@ -110,7 +110,7 @@ _GLOBAL(longjmp)
> li r3, 1
> blr
>
> -_GLOBAL(current_stack_pointer)
> +_GLOBAL(current_stack_frame)
> PPC_LL r3,0(r1)
> blr
> -EXPORT_SYMBOL(current_stack_pointer)
> +EXPORT_SYMBOL(current_stack_frame)
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index e730b8e522b0..110db94cdf3c 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -2051,7 +2051,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
> sp = (unsigned long) stack;
> if (sp == 0) {
> if (tsk == current)
> - sp = current_stack_pointer();
> + sp = current_stack_frame();
> else
> sp = tsk->thread.ksp;
> }
> diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
> index e2a46cfed5fd..c477b8585a29 100644
> --- a/arch/powerpc/kernel/stacktrace.c
> +++ b/arch/powerpc/kernel/stacktrace.c
> @@ -57,7 +57,7 @@ void save_stack_trace(struct stack_trace *trace)
> {
> unsigned long sp;
>
> - sp = current_stack_pointer();
> + sp = current_stack_frame();
>
> save_context_stack(trace, sp, current, 1);
> }
> @@ -71,7 +71,7 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
> return;
>
> if (tsk == current)
> - sp = current_stack_pointer();
> + sp = current_stack_frame();
> else
> sp = tsk->thread.ksp;
>
> @@ -131,7 +131,7 @@ static int __save_stack_trace_tsk_reliable(struct task_struct *tsk,
> }
>
> if (tsk == current)
> - sp = current_stack_pointer();
> + sp = current_stack_frame();
> else
> sp = tsk->thread.ksp;
>
>
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for tools/i915-perf: workaround overzelous compiler warnings
From: Patchwork @ 2020-02-20 13:31 UTC (permalink / raw)
To: Lionel Landwerlin; +Cc: igt-dev
In-Reply-To: <20200220125152.1188880-1-lionel.g.landwerlin@intel.com>
== Series Details ==
Series: tools/i915-perf: workaround overzelous compiler warnings
URL : https://patchwork.freedesktop.org/series/73709/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4192
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/index.html
Known issues
------------
Here are the changes found in IGTPW_4192 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s0:
- fi-ilk-650: [PASS][1] -> [DMESG-WARN][2] ([i915#116])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-ilk-650/igt@gem_exec_suspend@basic-s0.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-ilk-650/igt@gem_exec_suspend@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][3] -> [DMESG-WARN][4] ([i915#92]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [PASS][5] -> [DMESG-FAIL][6] ([i915#1052])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-guc: [PASS][7] -> [INCOMPLETE][8] ([fdo#108744])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-guc/igt@i915_selftest@live_hangcheck.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-skl-guc/igt@i915_selftest@live_hangcheck.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-skl-6770hq: [PASS][9] -> [SKIP][10] ([fdo#109271]) +4 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6770hq/igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-skl-6770hq/igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-skl-6770hq: [PASS][11] -> [DMESG-WARN][12] ([i915#106])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6770hq/igt@kms_pipe_crc_basic@read-crc-pipe-c.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-skl-6770hq/igt@kms_pipe_crc_basic@read-crc-pipe-c.html
* igt@kms_prop_blob@basic:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([CI#94] / [i915#402])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@kms_prop_blob@basic.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-tgl-y/igt@kms_prop_blob@basic.html
#### Possible fixes ####
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][15] ([i915#877]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][17] ([i915#217]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
#### Warnings ####
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][19] ([fdo#109315]) -> [SKIP][20] ([fdo#109315] / [i915#585])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@amdgpu/amd_prime@amd-to-i915.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-icl-u3/igt@amdgpu/amd_prime@amd-to-i915.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][21] ([fdo#111407]) -> [FAIL][22] ([fdo#111096] / [i915#323])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
[i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106
[i915#116]: https://gitlab.freedesktop.org/drm/intel/issues/116
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
Participating hosts (49 -> 47)
------------------------------
Additional (4): fi-kbl-soraka fi-skl-lmem fi-ivb-3770 fi-pnv-d510
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4192
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4192: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/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_4192/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v1 1/2] scsi: ufs: add required delay after gating reference clock
From: Stanley Chu @ 2020-02-20 13:30 UTC (permalink / raw)
To: Can Guo
Cc: chun-hung.wu, linux-scsi, martin.petersen, andy.teng, jejb,
peter.wang, kuohong.wang, linux-kernel, avri.altman,
linux-mediatek, linux-arm-kernel, alim.akhtar, matthias.bgg,
beanhuo, bvanassche, hongwus, Asutosh Das
In-Reply-To: <bbb0b0637d9667d4691a9a28f9988dea@codeaurora.org>
Hi Can,
On Wed, 2020-02-19 at 18:33 +0800, Can Guo wrote:
> Hi Stanley,
>
> On 2020-02-19 17:11, Stanley Chu wrote:
> > Hi Can,
> >
> > On Wed, 2020-02-19 at 10:35 +0800, Can Guo wrote:
> >
> >> Since we all need this delay here, how about put the delay in the
> >> entrence of ufshcd_setup_clocks(), before vops_setup_clocks()?
> >> If so, we can remove all the delays we added in our vops since the
> >> delay anyways delays everything inside ufshcd_setup_clocks().
> >>
> >
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
> >
> > I think current patch is more reasonable because the delay is applied
> > to
> > clock only named as "ref_clk" specifically.
> >
> > If you needs to keep "ref_clk" in DT, would you consider to remove the
> > delay in your ufs_qcom_dev_ref_clk_ctrl() and let the delay happens via
> > common ufshcd_setup_clocks() only? However you may still need delay if
> > call path comes from ufs_qcom_pwr_change_notify().
> >
> > What do you think?
> >
>
> I agree current change is more reasonable from what it looks, but the
> fact
> is that I canont remove the delay in ufs_qcom_dev_ref_clk_ctrl() even
> with
> this change. On our platforms, ref_clk in DT serves multipule purposes,
> the ref_clk provided to UFS device is actually controlled in
> ufs_qcom_dev_ref_clk_ctrl(), which comes before where this change kicks
> start,
> so if I remove the delay in ufs_qcom_dev_ref_clk_ctrl(), this change
> cannot
> provide us the correct delay before gate the ref_clk provided to UFS
> device.
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
>
> I meant if we put the delay in the entrance, I will be able to remove
> the delay in ufs_qcom_dev_ref_clk_ctrl(). Meanwhile, we can add proper
> checks before the delay to make sure it is initiated only if ref_clk
> needs
> to be disabled, i.e:
>
> if(!on && !skip_ref_clk && hba->dev_info.clk_gating_wait_us)
> usleep_range();
>
> Does this look better to you?
Firstly thanks so much for above details.
Again this statement may also add unwanted delay if some other vendors
does not have "ref_clk" in DT or they don't/can't disable the reference
clock provided to UFS device.
>
> Anyways, we will see regressions with this change on our platforms, can
> we
> have more discussions before get it merged? It should be OK if you go
> with
> patch #2 alone first, right? Thanks.
Now the fact is that this change will impact your flow and it seems no
solid conclusion yet. Sure I could drop patch #1 and submit patch #2
only first : )
Thanks,
Stanley Chu
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v1 1/2] scsi: ufs: add required delay after gating reference clock
From: Stanley Chu @ 2020-02-20 13:30 UTC (permalink / raw)
To: Can Guo
Cc: chun-hung.wu, linux-scsi, martin.petersen, andy.teng, jejb,
peter.wang, kuohong.wang, linux-kernel, avri.altman,
linux-mediatek, linux-arm-kernel, alim.akhtar, matthias.bgg,
beanhuo, bvanassche, hongwus, Asutosh Das
In-Reply-To: <bbb0b0637d9667d4691a9a28f9988dea@codeaurora.org>
Hi Can,
On Wed, 2020-02-19 at 18:33 +0800, Can Guo wrote:
> Hi Stanley,
>
> On 2020-02-19 17:11, Stanley Chu wrote:
> > Hi Can,
> >
> > On Wed, 2020-02-19 at 10:35 +0800, Can Guo wrote:
> >
> >> Since we all need this delay here, how about put the delay in the
> >> entrence of ufshcd_setup_clocks(), before vops_setup_clocks()?
> >> If so, we can remove all the delays we added in our vops since the
> >> delay anyways delays everything inside ufshcd_setup_clocks().
> >>
> >
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
> >
> > I think current patch is more reasonable because the delay is applied
> > to
> > clock only named as "ref_clk" specifically.
> >
> > If you needs to keep "ref_clk" in DT, would you consider to remove the
> > delay in your ufs_qcom_dev_ref_clk_ctrl() and let the delay happens via
> > common ufshcd_setup_clocks() only? However you may still need delay if
> > call path comes from ufs_qcom_pwr_change_notify().
> >
> > What do you think?
> >
>
> I agree current change is more reasonable from what it looks, but the
> fact
> is that I canont remove the delay in ufs_qcom_dev_ref_clk_ctrl() even
> with
> this change. On our platforms, ref_clk in DT serves multipule purposes,
> the ref_clk provided to UFS device is actually controlled in
> ufs_qcom_dev_ref_clk_ctrl(), which comes before where this change kicks
> start,
> so if I remove the delay in ufs_qcom_dev_ref_clk_ctrl(), this change
> cannot
> provide us the correct delay before gate the ref_clk provided to UFS
> device.
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
>
> I meant if we put the delay in the entrance, I will be able to remove
> the delay in ufs_qcom_dev_ref_clk_ctrl(). Meanwhile, we can add proper
> checks before the delay to make sure it is initiated only if ref_clk
> needs
> to be disabled, i.e:
>
> if(!on && !skip_ref_clk && hba->dev_info.clk_gating_wait_us)
> usleep_range();
>
> Does this look better to you?
Firstly thanks so much for above details.
Again this statement may also add unwanted delay if some other vendors
does not have "ref_clk" in DT or they don't/can't disable the reference
clock provided to UFS device.
>
> Anyways, we will see regressions with this change on our platforms, can
> we
> have more discussions before get it merged? It should be OK if you go
> with
> patch #2 alone first, right? Thanks.
Now the fact is that this change will impact your flow and it seems no
solid conclusion yet. Sure I could drop patch #1 and submit patch #2
only first : )
Thanks,
Stanley Chu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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.