Re: [PATCH 4.19 00/92] 4.19.126-rc2 review
On Tue, 2 Jun 2020 at 15:54, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.126 release. > There are 92 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 04 Jun 2020 10:16:52 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.126-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.19.126-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 80718197a8a3f9c3b222375e5d1de8adf5422000 git describe: v4.19.125-93-g80718197a8a3 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.125-93-g80718197a8a3 No regressions (compared to build v4.19.125) No fixes (compared to build v4.19.125) Ran 26389 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * kselftest/networking * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * perf * v4l2-compliance * kvm-unit-tests * ltp-cve-tests * ltp-dio-tests * ltp-fs-tests * ltp-io-tests * ltp-syscalls-tests * network-basic-tests * ltp-open-posix-tests -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v4 7/7] mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports for Macronix mx25uw51245g
On 02/06/20 02:44PM, masonccy...@mxic.com.tw wrote:
>
> Hi Pratyush,
>
>
> > Subject
> >
> > Re: [PATCH v4 7/7] mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports
> for
> > Macronix mx25uw51245g
> >
> > On 29/05/20 03:36PM, Mason Yang wrote:
> > > Macronix mx25uw51245g is a SPI NOR that supports 1-1-1/8-8-8 mode.
> > >
> > > Correct the dummy cycles to device for various frequencies
> > > after xSPI profile 1.0 table parsed.
> > >
> > > Enable mx25uw51245g to Octal DTR mode by executing the command
> sequences
> > > to change to octal DTR mode.
> > >
> > > Signed-off-by: Mason Yang
> > > ---
> > > drivers/mtd/spi-nor/macronix.c | 55
> ++
> > > 1 file changed, 55 insertions(+)
> > >
> > > diff --git a/drivers/mtd/spi-nor/macronix.c
> b/drivers/mtd/spi-nor/macronix.c
> > > index 96735d8..6c9a24c 100644
> > > --- a/drivers/mtd/spi-nor/macronix.c
> > > +++ b/drivers/mtd/spi-nor/macronix.c
> > > @@ -8,6 +8,57 @@
> > >
> > > #include "core.h"
> > >
> > > +#define MXIC_CR2_DUMMY_SET_ADDR 0x300
> > > +
> > > +/* Fixup the dummy cycles to device and setup octa_dtr_enable() */
> > > +static void mx25uw51245g_post_sfdp_fixups(struct spi_nor *nor)
> > > +{
> > > + struct spi_nor_flash_parameter *params = nor->params;
> > > + int ret;
> > > + u8 rdc, wdc;
> > > +
> > > + ret = spi_nor_read_cr2(nor, MXIC_CR2_DUMMY_SET_ADDR, );
> > > + if (ret)
> > > + return;
> > > +
> > > + /* Refer to dummy cycle and frequency table(MHz) */
> > > + switch (params->dummy_cycles) {
> > > + case 10: /* 10 dummy cycles for 104 MHz */
> > > + wdc = 5;
> > > + break;
> > > + case 12: /* 12 dummy cycles for 133 MHz */
> > > + wdc = 4;
> > > + break;
> > > + case 16: /* 16 dummy cycles for 166 MHz */
> > > + wdc = 2;
> > > + break;
> > > + case 18: /* 18 dummy cycles for 173 MHz */
> > > + wdc = 1;
> > > + break;
> > > + case 20: /* 20 dummy cycles for 200 MHz */
> > > + default:
> > > + wdc = 0;
> > > + }
> >
> > I don't get the point of this. You already know the fastest the
> > mx25uw51245g flash can run at. Why not just use the maximum dummy
> > cycles? SPI NOR doesn't know the speed the controller is running at so
> > the best it can do is use the maximum dummy cycles possible so it never
> > falls short. Sure, it will be _slightly_ less performance, but we will
> > be sure to read the correct data, which is much much more important.
>
> In general, 200MHz needs 20 dummy cycles but some powerful device may only
>
> needs 18 dummy cycles or less.
Yes, but do different mx25uw51245g chips have different dummy cycle
requirements? Shouldn't all the chips with the same ID have same
performance?
This is a fixup hook for mx25uw51245g, so you should already know how
many cycles are needed for this specific device. Is there any need for
generic code here?
> Set a proper dummy cycles for a better performance.
>
> >
> > Is it possible to have two chips which have _exactly_ the same ID but
> > one supports say 200MHz frequency but the other doesn't? Without that,
> > we can just enable the maximum and move on.
> >
>
--
Regards,
Pratyush Yadav
[PATCH 3/4] random: fix an incorrect __user annotation on proc_do_entropy
No user pointers for sysctls anymore.
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Reported-by: build test robot
Signed-off-by: Christoph Hellwig
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 1e0db78b83baa..cf8a43f5eb2a0 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2087,7 +2087,7 @@ static int proc_do_uuid(struct ctl_table *table, int
write,
* Return entropy available scaled to integral bits
*/
static int proc_do_entropy(struct ctl_table *table, int write,
- void __user *buffer, size_t *lenp, loff_t *ppos)
+ void *buffer, size_t *lenp, loff_t *ppos)
{
struct ctl_table fake_table;
int entropy_count;
--
2.26.2
[PATCH 4/4] trace: fix an incorrect __user annotation on stack_trace_sysctl
No user pointers for sysctls anymore.
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Reported-by: build test robot
Signed-off-by: Christoph Hellwig
---
include/linux/ftrace.h | 5 ++---
kernel/trace/trace_stack.c | 5 ++---
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index ddfc377de0d2c..fce81238f304d 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -319,9 +319,8 @@ static inline void arch_ftrace_set_direct_caller(struct
pt_regs *regs,
extern int stack_tracer_enabled;
-int stack_trace_sysctl(struct ctl_table *table, int write,
- void __user *buffer, size_t *lenp,
- loff_t *ppos);
+int stack_trace_sysctl(struct ctl_table *table, int write, void *buffer,
+ size_t *lenp, loff_t *ppos);
/* DO NOT MODIFY THIS VARIABLE DIRECTLY! */
DECLARE_PER_CPU(int, disable_stack_tracer);
diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index c557f42a93971..98bba4764c527 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -515,9 +515,8 @@ static const struct file_operations stack_trace_filter_fops
= {
#endif /* CONFIG_DYNAMIC_FTRACE */
int
-stack_trace_sysctl(struct ctl_table *table, int write,
- void __user *buffer, size_t *lenp,
- loff_t *ppos)
+stack_trace_sysctl(struct ctl_table *table, int write, void *buffer,
+ size_t *lenp, loff_t *ppos)
{
int was_enabled;
int ret;
--
2.26.2
[PATCH 2/4] net/sysctl: remove leftover __user annotations on neigh_proc_dointvec*
Remove the leftover __user annotation on the prototypes for
neigh_proc_dointvec*. The implementations already got this right, but
the headers kept the __user tags around.
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Reported-by: build test robot
Signed-off-by: Christoph Hellwig
---
include/net/neighbour.h | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index e1476775769c9..81ee17594c329 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -392,13 +392,12 @@ void *neigh_seq_next(struct seq_file *, void *, loff_t *);
void neigh_seq_stop(struct seq_file *, void *);
int neigh_proc_dointvec(struct ctl_table *ctl, int write,
- void __user *buffer, size_t *lenp, loff_t *ppos);
+ void *buffer, size_t *lenp, loff_t *ppos);
int neigh_proc_dointvec_jiffies(struct ctl_table *ctl, int write,
- void __user *buffer,
+ void *buffer,
size_t *lenp, loff_t *ppos);
int neigh_proc_dointvec_ms_jiffies(struct ctl_table *ctl, int write,
- void __user *buffer,
- size_t *lenp, loff_t *ppos);
+ void *buffer, size_t *lenp, loff_t *ppos);
int neigh_sysctl_register(struct net_device *dev, struct neigh_parms *p,
proc_handler *proc_handler);
--
2.26.2
[PATCH 1/4] net/sysctl: use cpumask_parse in flow_limit_cpu_sysctl
cpumask_parse_user works on __user pointers, so this is wrong now.
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Reported-by: build test robot
Signed-off-by: Christoph Hellwig
---
net/core/sysctl_net_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 0ddb13a6282b0..d14d049af52ae 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -126,7 +126,7 @@ static int flow_limit_cpu_sysctl(struct ctl_table *table,
int write,
return -ENOMEM;
if (write) {
- ret = cpumask_parse_user(buffer, *lenp, mask);
+ ret = cpumask_parse(buffer, mask);
if (ret)
goto done;
--
2.26.2
fixes for work.sysctl
Hi Al, a bunch of fixes for the sysctl kernel pointer conversion against your work.sysctl branch. Only the first one is a real behavior fix, the rest just removes left over __user annotations.
Re: [PATCH] h8300: dts: Fix /chosen:stdout-path
On Wed, Mar 25, 2020 at 6:53 PM Geert Uytterhoeven
wrote:
>
> arch/h8300/boot/dts/h8s_sim.dts:11.3-25: Warning
> (chosen_node_stdout_path): /chosen:stdout-path: property is not a string
> arch/h8300/boot/dts/h8300h_sim.dts:11.3-25: Warning
> (chosen_node_stdout_path): /chosen:stdout-path: property is not a string
>
> Drop the angle brackets to fix this.
>
> A similar fix was already applied to arch/h8300/boot/dts/edosk2674.dts
> in commit 780ffcd51cb28717 ("h8300: register address fix").
>
> Fixes: 38d6bded13084d50 ("h8300: devicetree source")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Masahiro Yamada
Unfortunately, h8300 maintainer is not responding...
How to get this in?
Perhaps, Rob can pick this up?
Thanks.
> ---
> arch/h8300/boot/dts/h8300h_sim.dts | 2 +-
> arch/h8300/boot/dts/h8s_sim.dts| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/h8300/boot/dts/h8300h_sim.dts
> b/arch/h8300/boot/dts/h8300h_sim.dts
> index 595398b9d0180a80..e1d4d9b7f6b40c04 100644
> --- a/arch/h8300/boot/dts/h8300h_sim.dts
> +++ b/arch/h8300/boot/dts/h8300h_sim.dts
> @@ -8,7 +8,7 @@
>
> chosen {
> bootargs = "earlyprintk=h8300-sim";
> - stdout-path = <>;
> + stdout-path =
> };
> aliases {
> serial0 =
> diff --git a/arch/h8300/boot/dts/h8s_sim.dts b/arch/h8300/boot/dts/h8s_sim.dts
> index 932cc3c5a81bcdd2..4848e40e607ecc1d 100644
> --- a/arch/h8300/boot/dts/h8s_sim.dts
> +++ b/arch/h8300/boot/dts/h8s_sim.dts
> @@ -8,7 +8,7 @@
>
> chosen {
> bootargs = "earlyprintk=h8300-sim";
> - stdout-path = <>;
> + stdout-path =
> };
> aliases {
> serial0 =
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v5 00/10] workingset protection/detection on the anonymous LRU list
2020년 6월 3일 (수) 오후 12:57, Suren Baghdasaryan 님이 작성: > > On Wed, Apr 8, 2020 at 5:50 PM Joonsoo Kim wrote: > > > > 2020년 4월 9일 (목) 오전 1:55, Vlastimil Babka 님이 작성: > > > > > > On 4/3/20 7:40 AM, js1...@gmail.com wrote: > > > > From: Joonsoo Kim > > > > > > > > Hello, > > > > > > > > This patchset implements workingset protection and detection on > > > > the anonymous LRU list. > > > > > > Hi! > > > > Hi! > > > > > > I did another test to show the performance effect of this patchset. > > > > > > > > - ebizzy (with modified random function) > > > > ebizzy is the test program that main thread allocates lots of memory and > > > > child threads access them randomly during the given times. Swap-in/out > > > > will happen if allocated memory is larger than the system memory. > > > > > > > > The random function that represents the zipf distribution is used to > > > > make hot/cold memory. Hot/cold ratio is controlled by the parameter. If > > > > the parameter is high, hot memory is accessed much larger than cold one. > > > > If the parameter is low, the number of access on each memory would be > > > > similar. I uses various parameters in order to show the effect of > > > > patchset on various hot/cold ratio workload. > > > > > > > > My test setup is a virtual machine with 8 cpus and 1024MB memory. > > > > > > > > Result format is as following. > > > > > > > > Parameter 0.1 ... 1.3 > > > > Allocated memory size > > > > Throughput for base (larger is better) > > > > Throughput for patchset (larger is better) > > > > Improvement (larger is better) > > > > > > > > > > > > * single thread > > > > > > > > 0.1 0.3 0.5 0.7 0.9 1.1 1.3 > > > > <512M> > > > > 7009.0 7372.0 7774.0 8523.0 9569.0 10724.0 11936.0 > > > > 6973.0 7342.0 7745.0 8576.0 9441.0 10730.0 12033.0 > > > >-0.01 -0.0 -0.0 0.01-0.01 0.0 0.01 > > > > <768M> > > > >915.0 1039.0 1275.0 1687.0 2328.0 3486.0 5445.0 > > > >920.0 1037.0 1238.0 1689.0 2384.0 3638.0 5381.0 > > > > 0.01 -0.0-0.03 0.0 0.02 0.04-0.01 > > > > <1024M> > > > >425.0471.0539.0753.0 1183.0 2130.0 3839.0 > > > >414.0468.0553.0770.0 1242.0 2187.0 3932.0 > > > >-0.03-0.01 0.03 0.02 0.05 0.03 0.02 > > > > <1280M> > > > >320.0346.0410.0556.0871.0 1654.0 3298.0 > > > >316.0346.0411.0550.0892.0 1652.0 3293.0 > > > >-0.01 0.0 0.0-0.01 0.02 -0.0 -0.0 > > > > <1536M> > > > >273.0290.0341.0458.0733.0 1381.0 2925.0 > > > >271.0293.0344.0462.0740.0 1398.0 2969.0 > > > >-0.01 0.01 0.01 0.01 0.01 0.01 0.02 > > > > <2048M> > > > > 77.0 79.0 95.0147.0276.0690.0 1816.0 > > > > 91.0 94.0115.0170.0321.0770.0 2018.0 > > > > 0.18 0.19 0.21 0.16 0.16 0.12 0.11 > > > > > > > > > > > > * multi thread (8) > > > > > > > > 0.1 0.3 0.5 0.7 0.9 1.1 1.3 > > > > <512M> > > > > 29083.0 29648.0 30145.0 31668.0 33964.0 38414.0 43707.0 > > > > 29238.0 29701.0 30301.0 31328.0 33809.0 37991.0 43667.0 > > > > 0.01 0.0 0.01-0.01 -0.0-0.01 -0.0 > > > > <768M> > > > > 3332.0 3699.0 4673.0 5830.0 8307.0 12969.0 17665.0 > > > > 3579.0 3992.0 4432.0 6111.0 8699.0 12604.0 18061.0 > > > > 0.07 0.08-0.05 0.05 0.05-0.03 0.02 > > > > <1024M> > > > > 1921.0 2141.0 2484.0 3296.0 5391.0 8227.0 14574.0 > > > > 1989.0 2155.0 2609.0 3565.0 5463.0 8170.0 15642.0 > > > > 0.04 0.01 0.05 0.08 0.01-0.01 0.07 > > > > <1280M> > > > > 1524.0 1625.0 1931.0 2581.0 4155.0 6959.0 12443.0 > > > > 1560.0 1707.0 2016.0 2714.0 4262.0 7518.0 13910.0 > > > > 0.02 0.05 0.04 0.05 0.03 0.08 0.12 > > > > <1536M> > > > > 1303.0 1399.0 1550.0 2137.0 3469.0 6712.0 12944.0 > > > > 1356.0 1465.0 1701.0 2237.0 3583.0 6830.0 13580.0 > > > > 0.04 0.05 0.1 0.05 0.03 0.02 0.05 > > > > <2048M> > > > >172.0184.0215.0289.0514.0 1318.0 4153.0 > > > >175.0190.0225.0329.0606.0 1585.0 5170.0 > > > > 0.02 0.03 0.05 0.14 0.18 0.2 0.24 > > > > > > > > As we can see, as allocated memory grows, patched kernel get the better > > > > result. Maximum improvement is 21% for the single thread test and > > > > 24% for the multi thread test. > > > > > > So, these results seem to be identical since v1. After the various > > > changes up to > > > v5, should the benchmark be redone? And was that with a full patchset or > > > patches 1+2? > > > > It was done with a full patchset. I think
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Wed, Jun 03, 2020 at 01:18:54PM +0800, Jason Wang wrote:
>
> On 2020/6/3 下午12:18, Al Viro wrote:
> > On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote:
> >
> > > > How widely do you hope to stretch the user_access areas, anyway?
> > >
> > > To have best performance for small packets like 64B, if possible, we want
> > > to
> > > disable STAC not only for the metadata access done by vhost accessors but
> > > also the data access via iov iterator.
> > If you want to try and convince Linus to go for that, make sure to Cc
> > me on that thread. Always liked quality flame...
> >
> > The same goes for interval tree lookups with uaccess allowed. IOW, I
> > _really_
> > doubt that it's a good idea.
>
>
> I see. We are just seeking an approach to perform better in order to compete
> with userspace dpdk backends.
>
> I tried another approach of using direct mapping + mmu notifier [1] but the
> synchronization with MMU notifier is not easy to perform well.
>
> [1] https://patchwork.kernel.org/patch/11133009/
>
>
> >
> > > > Incidentally, who had come up with the name __vhost_get_user?
> > > > Makes for lovey WTF moment for readers - esp. in vhost_put_user()...
> > >
> > > I think the confusion comes since it does not accept userspace pointer
> > > (when
> > > IOTLB is enabled).
> > >
> > > How about renaming it as vhost_read()/vhost_write() ?
> > Huh?
> >
> > __vhost_get_user() is IOTLB remapping of userland pointer. It does not
> > access
> > userland memory. Neither for read, nor for write. It is used by
> > vhost_get_user()
> > and vhost_put_user().
> >
> > Why would you want to rename it into vhost_read _or_ vhost_write, and in
> > any case,
> > how do you give one function two names? IDGI...
>
>
> I get you know, I thought you're concerning the names of
> vhost_get_user()/vhost_put_user() but actually __vhost_get_user().
>
> Maybe something like __vhost_fetch_uaddr() is better.
>
> Thanks
It's basically vhost_translate_uaddr isn't it?
BTW now I re-read it I don't understand __vhost_get_user_slow:
static void __user *__vhost_get_user_slow(struct vhost_virtqueue *vq,
void __user *addr, unsigned int size,
int type)
{
int ret;
ret = translate_desc(vq, (u64)(uintptr_t)addr, size, vq->iotlb_iov,
ARRAY_SIZE(vq->iotlb_iov),
VHOST_ACCESS_RO);
..
}
how does this work? how can we cast a pointer to guest address without
adding any offsets?
>
> >
Re: [PATCH] net: can: remove "WITH Linux-syscall-note" from SPDX tag of C files
On Fri, Apr 3, 2020 at 11:35 PM Oliver Hartkopp wrote: > > > > On 03/04/2020 09.37, Masahiro Yamada wrote: > > The "WITH Linux-syscall-note" exception is intended for UAPI headers. > > > > See LICENSES/exceptions/Linux-syscall-note > > > > Signed-off-by: Masahiro Yamada > > Acked-by: Oliver Hartkopp > > Thanks Masahiro! Any chance for this patch picked up? > > > > --- > > > > net/can/bcm.c | 2 +- > > net/can/gw.c | 2 +- > > net/can/proc.c | 2 +- > > net/can/raw.c | 2 +- > > 4 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/net/can/bcm.c b/net/can/bcm.c > > index c96fa0f33db3..d94b2099 100644 > > --- a/net/can/bcm.c > > +++ b/net/can/bcm.c > > @@ -1,4 +1,4 @@ > > -// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR > > BSD-3-Clause) > > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) > > /* > >* bcm.c - Broadcast Manager to filter/send (cyclic) CAN content > >* > > diff --git a/net/can/gw.c b/net/can/gw.c > > index 65d60c93af29..49b4e3d91ad6 100644 > > --- a/net/can/gw.c > > +++ b/net/can/gw.c > > @@ -1,4 +1,4 @@ > > -// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR > > BSD-3-Clause) > > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) > > /* gw.c - CAN frame Gateway/Router/Bridge with netlink interface > >* > >* Copyright (c) 2019 Volkswagen Group Electronic Research > > diff --git a/net/can/proc.c b/net/can/proc.c > > index e6881bfc3ed1..a4eb06c9eb70 100644 > > --- a/net/can/proc.c > > +++ b/net/can/proc.c > > @@ -1,4 +1,4 @@ > > -// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR > > BSD-3-Clause) > > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) > > /* > >* proc.c - procfs support for Protocol family CAN core module > >* > > diff --git a/net/can/raw.c b/net/can/raw.c > > index 59c039d73c6d..ab104cc18562 100644 > > --- a/net/can/raw.c > > +++ b/net/can/raw.c > > @@ -1,4 +1,4 @@ > > -// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR > > BSD-3-Clause) > > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) > > /* raw.c - Raw sockets for protocol family CAN > >* > >* Copyright (c) 2002-2007 Volkswagen Group Electronic Research > > -- Best Regards Masahiro Yamada
Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode
On Tue, Jun 2, 2020 at 10:05 PM Jason Xing wrote:
>
> Hi Eric,
>
> I'm still trying to understand what you're saying before. Would this
> be better as following:
> 1) discard the tcp_internal_pacing() function.
> 2) remove where the tcp_internal_pacing() is called in the
> __tcp_transmit_skb() function.
>
> If we do so, we could avoid 'too late to give up pacing'. Meanwhile,
> should we introduce the tcp_wstamp_ns socket field as commit
> (864e5c090749) does?
>
Please do not top-post on netdev mailing list.
I basically suggested double-checking which point in TCP could end up
calling tcp_internal_pacing()
while the timer was already armed.
I guess this is mtu probing.
Please try the following patch : If we still have another bug, a
WARNING should give us a stack trace.
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index
cc4ba42052c21b206850594db6751810d8fc72b4..8f4081b228486305222767d4d118b9b6ed0ffda3
100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -977,12 +977,26 @@ static void tcp_internal_pacing(struct sock *sk,
const struct sk_buff *skb)
len_ns = (u64)skb->len * NSEC_PER_SEC;
do_div(len_ns, rate);
+
+ /* If hrtimer is already armed, then our caller has not properly
+* used tcp_pacing_check().
+*/
+ if (unlikely(hrtimer_is_queued(_sk(sk)->pacing_timer))) {
+ WARN_ON_ONCE(1);
+ return;
+ }
hrtimer_start(_sk(sk)->pacing_timer,
ktime_add_ns(ktime_get(), len_ns),
HRTIMER_MODE_ABS_PINNED_SOFT);
sock_hold(sk);
}
+static bool tcp_pacing_check(const struct sock *sk)
+{
+ return tcp_needs_internal_pacing(sk) &&
+ hrtimer_is_queued(_sk(sk)->pacing_timer);
+}
+
static void tcp_update_skb_after_send(struct tcp_sock *tp, struct sk_buff *skb)
{
skb->skb_mstamp = tp->tcp_mstamp;
@@ -2117,6 +2131,9 @@ static int tcp_mtu_probe(struct sock *sk)
if (!tcp_can_coalesce_send_queue_head(sk, probe_size))
return -1;
+ if (tcp_pacing_check(sk))
+ return -1;
+
/* We're allowed to probe. Build it now. */
nskb = sk_stream_alloc_skb(sk, probe_size, GFP_ATOMIC, false);
if (!nskb)
@@ -2190,11 +2207,6 @@ static int tcp_mtu_probe(struct sock *sk)
return -1;
}
-static bool tcp_pacing_check(const struct sock *sk)
-{
- return tcp_needs_internal_pacing(sk) &&
- hrtimer_is_queued(_sk(sk)->pacing_timer);
-}
/* TCP Small Queues :
* Control number of packets in qdisc/devices to two packets / or ~1 ms.
> Thanks,
> Jason
>
> On Wed, Jun 3, 2020 at 10:44 AM Eric Dumazet wrote:
> >
> > On Tue, Jun 2, 2020 at 7:42 PM Jason Xing wrote:
> > >
> > > I agree with you. The upstream has already dropped and optimized this
> > > part (commit 864e5c090749), so it would not happen like that. However
> > > the old kernels like LTS still have the problem which causes
> > > large-scale crashes on our thousands of machines after running for a
> > > long while. I will send the fix to the correct tree soon :)
> >
> > If you run BBR at scale (thousands of machines), you probably should
> > use sch_fq instead of internal pacing,
> > just saying ;)
> >
> >
> > >
> > > Thanks again,
> > > Jason
> > >
> > > On Wed, Jun 3, 2020 at 10:29 AM Eric Dumazet wrote:
> > > >
> > > > On Tue, Jun 2, 2020 at 6:53 PM Jason Xing
> > > > wrote:
> > > > >
> > > > > Hi Eric,
> > > > >
> > > > > I'm sorry that I didn't write enough clearly. We're running the
> > > > > pristine 4.19.125 linux kernel (the latest LTS version) and have been
> > > > > haunted by such an issue. This patch is high-important, I think. So
> > > > > I'm going to resend this email with the [patch 4.19] on the headline
> > > > > and cc Greg.
> > > >
> > > > Yes, please always give for which tree a patch is meant for.
> > > >
> > > > Problem is that your patch is not correct.
> > > > In these old kernels, tcp_internal_pacing() is called _after_ the
> > > > packet has been sent.
> > > > It is too late to 'give up pacing'
> > > >
> > > > The packet should not have been sent if the pacing timer is queued
> > > > (otherwise this means we do not respect pacing)
> > > >
> > > > So the bug should be caught earlier. check where tcp_pacing_check()
> > > > calls are missing.
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Jason
> > > > >
> > > > > On Tue, Jun 2, 2020 at 9:05 PM Eric Dumazet
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Jun 2, 2020 at 1:05 AM wrote:
> > > > > > >
> > > > > > > From: Jason Xing
> > > > > > >
> > > > > > > TCP socks cannot be released because of the sock_hold()
> > > > > > > increasing the
> > > > > > > sk_refcnt in the manner of tcp_internal_pacing() when RTO happens.
> > > > > > > Therefore, this situation could increase the slab memory and then
> > > > > > > trigger
> > > > > > > the OOM if the machine has beening running for a long time. This
Re: [PATCH 05/14] mm: workingset: let cache workingset challenge anon
2020년 6월 3일 (수) 오전 1:48, Johannes Weiner 님이 작성:
>
> On Tue, Jun 02, 2020 at 11:34:17AM +0900, Joonsoo Kim wrote:
> > 2020년 6월 2일 (화) 오전 12:56, Johannes Weiner 님이 작성:
> > > On Mon, Jun 01, 2020 at 03:14:24PM +0900, Joonsoo Kim wrote:
> > > > But, I still think that modified refault activation equation isn't
> > > > safe. The next
> > > > problem I found is related to the scan ratio limit patch ("limit the
> > > > range of
> > > > LRU type balancing") on this series. See the below example.
> > > >
> > > > anon: Hot (X M)
> > > > file: Hot (200 M) / dummy (200 M)
> > > > P: 1200 M (3 parts, each one 400 M, P1, P2, P3)
> > > > Access Pattern: A -> F(H) -> P1 -> A -> F(H) -> P2 -> ... ->
> > > >
> > > > Without this patch, A and F(H) are kept on the memory and look like
> > > > it's correct.
> > > >
> > > > With this patch and below fix, refault equation for Pn would be:
> > > >
> > > > Refault dist of Pn = 1200 (from file non-resident) + 1200 * anon scan
> > > > ratio (from anon non-resident)
> > > > anon + active file = X + 200
> > > > 1200 + 1200 * anon scan ratio (0.5 ~ 2) < X + 200
> > >
> > > That doesn't look quite right to me. The anon part of the refault
> > > distance is driven by X, so the left-hand of this formula contains X
> > > as well.
> > >
> > > 1000 file (1200M reuse distance, 200M in-core size) + F(H) reactivations
> > > + X * scan ratio < X + 1000
> >
> > As I said before, there is no X on left-hand of this formula. To
> > access all Pn and
> > re-access P1, we need 1200M file list scan and reclaim. More scan isn't
> > needed.
> > With your patch "limit the range of LRU type balancing", scan ratio
> > between file/anon
> > list is limited to 0.5 ~ 2.0, so, maximum anon scan would be 1200 M *
> > 2.0, that is,
> > 2400 M and not bounded by X. That means that file list cannot be
> > stable with some X.
>
> Oh, no X on the left because you're talking about the number of pages
> scanned until the first refaults, which is fixed - so why are we still
> interpreting the refault distance against a variable anon size X?
Looks like I was confused again. Your formula is correct and mine is
wrong. My mistake is I thought that your patch "limit the range of LRU
type balancing"
which makes scan *ratio* 2:1 leads to actual scan *count* ratio
between anon/file to 2:1.
But, now I realized that 2:1 is just scan ratio and actual scan
*count* ratio could be far
larger with certain list size. It would be X * scan ratio in above example so my
explanation is wrong and you are right.
Sorry for making a trouble.
> Well, that's misleading. We compare against anon because part of the
> cache is already encoded in the refault distance. What we're really
> checking is access distance against total amount of available RAM.
>
> Consider this. We want to activate pages where
>
> access_distance <= RAM
>
> and our measure of access distance is:
>
> access_distance = refault_distance + inactive_file
>
> So the comparison becomes:
>
> refault_distance + inactive_file < RAM
>
> which we simplify to:
>
> refault_distance < active_file + anon
>
> There is a certain threshold for X simply because there is a certain
> threshold for RAM beyond which we need to start activating. X cannot
> be arbitrary, it must be X + cache filling up memory - after all we
> have page reclaim evicting pages.
>
> Again, this isn't new. In the current code, we activate when:
>
> refault_distance < active_file
>
> which is
>
> access_distance <= RAM - anon
>
> You can see, whether things are stable or not always depends on the
> existing workingset size. It's just a proxy for how much total RAM we
> have potentially available to the refaulting page.
>
> > If my lastly found example is a correct example (your confirm is required),
> > it is also related to the correctness issue since cold pages causes
> > eviction of the hot pages repeatedly.
>
> I think your example is correct, but it benefits from the VM
> arbitrarily making an assumption that has a 50/50 shot of being true.
>
> You and I know which pages are hot and which are cold because you
> designed the example.
>
> All the VM sees is this:
>
> - We have an established workingset that has previously shown an
> access distance <= RAM and therefor was activated.
>
> - We now have another set that also appears to have an access distance
> <= RAM. The only way to know for sure, however, is sample the
> established workingset and compare the relative access frequencies.
>
> Currently, we just assume the incoming pages are colder. Clearly
> that's beneficial when it's true. Clearly that can be totally wrong.
>
> We must allow a fair comparison between these two sets.
>
> For cache, that's already the case - that's why I brought up the
> cache-only example: if refault distances are 50M and you have 60M of
> active cache, we activate all refaults and force an even competition
> between the established workingset and the new pages.
>
> Whether
Re: WARNING in snd_usbmidi_submit_urb/usb_submit_urb
syzbot has found a reproducer for the following crash on:
HEAD commit:1ee08de1 Merge tag 'for-5.8/io_uring-2020-06-01' of git://..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15f9e51610
kernel config: https://syzkaller.appspot.com/x/.config?x=b46ebd806238a886
dashboard link: https://syzkaller.appspot.com/bug?extid=5f1d24c49c1d2c427497
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1667dcca10
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13f9e51610
The bug was bisected to:
commit f2c2e717642c66f7fe7e5dd69b2e8ff5849f4d10
Author: Andrey Konovalov
Date: Mon Feb 24 16:13:03 2020 +
usb: gadget: add raw-gadget interface
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=164afcf210
final crash:https://syzkaller.appspot.com/x/report.txt?x=154afcf210
console output: https://syzkaller.appspot.com/x/log.txt?x=114afcf210
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5f1d24c49c1d2c427...@syzkaller.appspotmail.com
Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
[ cut here ]
URB 44767a7f submitted while active
WARNING: CPU: 1 PID: 9186 at drivers/usb/core/urb.c:363
usb_submit_urb+0x10c1/0x13b0 drivers/usb/core/urb.c:363
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 9186 Comm: syz-executor730 Not tainted 5.7.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x188/0x20d lib/dump_stack.c:118
panic+0x2e3/0x75c kernel/panic.c:221
__warn.cold+0x2f/0x35 kernel/panic.c:582
report_bug+0x27b/0x2f0 lib/bug.c:195
fixup_bug arch/x86/kernel/traps.c:105 [inline]
fixup_bug arch/x86/kernel/traps.c:100 [inline]
do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:197
do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:216
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:usb_submit_urb+0x10c1/0x13b0 drivers/usb/core/urb.c:363
Code: 89 de e8 c2 16 66 fc 84 db 0f 85 42 f6 ff ff e8 85 15 66 fc 4c 89 fe 48
c7 c7 40 b3 ab 88 c6 05 98 27 78 05 01 e8 57 29 37 fc <0f> 0b e9 20 f6 ff ff c7
44 24 14 01 00 00 00 e9 d7 f6 ff ff 41 bd
RSP: 0018:c90007dc72b0 EFLAGS: 00010286
RAX: RBX: RCX:
RDX: RSI: 815cd4c7 RDI: f52000fb8e48
RBP: dc00 R08: 888095b144c0 R09: ed1015ce45f1
R10: 8880ae722f83 R11: ed1015ce45f0 R12: 0cc0
R13: fff0 R14: 888095974000 R15: 88809fa06600
snd_usbmidi_submit_urb+0x19/0x60 sound/usb/midi.c:194
snd_usbmidi_input_start_ep sound/usb/midi.c:2313 [inline]
snd_usbmidi_input_start.part.0+0xbe/0x1c0 sound/usb/midi.c:2329
snd_usbmidi_input_start sound/usb/midi.c:1119 [inline]
substream_open.isra.0+0x505/0x830 sound/usb/midi.c:1119
open_substream+0x42e/0x880 sound/core/rawmidi.c:299
rawmidi_open_priv+0x2e8/0x6e0 sound/core/rawmidi.c:342
snd_rawmidi_kernel_open+0x1b5/0x270 sound/core/rawmidi.c:382
midisynth_subscribe+0xf2/0x330 sound/core/seq/seq_midi.c:170
subscribe_port sound/core/seq/seq_ports.c:412 [inline]
check_and_subscribe_port+0x5b5/0x800 sound/core/seq/seq_ports.c:495
snd_seq_port_connect+0x2e4/0x510 sound/core/seq/seq_ports.c:564
snd_seq_ioctl_subscribe_port+0x1df/0x310 sound/core/seq/seq_clientmgr.c:1484
snd_seq_kernel_client_ctl+0xeb/0x130 sound/core/seq/seq_clientmgr.c:2353
snd_seq_oss_midi_open+0x3cb/0x640 sound/core/seq/oss/seq_oss_midi.c:364
snd_seq_oss_synth_setup_midi+0x123/0x520 sound/core/seq/oss/seq_oss_synth.c:269
snd_seq_oss_open+0x7fa/0x980 sound/core/seq/oss/seq_oss_init.c:261
odev_open+0x6c/0x90 sound/core/seq/oss/seq_oss.c:125
soundcore_open+0x446/0x600 sound/sound_core.c:593
chrdev_open+0x219/0x5c0 fs/char_dev.c:414
do_dentry_open+0x546/0x1340 fs/open.c:828
do_open fs/namei.c:3229 [inline]
path_openat+0x1e59/0x27d0 fs/namei.c:3346
do_filp_open+0x192/0x260 fs/namei.c:3373
do_sys_openat2+0x585/0x7d0 fs/open.c:1179
do_sys_open+0xc3/0x140 fs/open.c:1195
do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline]
do_fast_syscall_32+0x270/0xe90 arch/x86/entry/common.c:396
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
Kernel Offset: disabled
Rebooting in 86400 seconds..
Re: [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration
On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrote: > On Tue, 2 Jun 2020 23:19:48 -0400 > Yan Zhao wrote: > > > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote: > > > On Wed, 29 Apr 2020 20:39:50 -0400 > > > Yan Zhao wrote: > > > > > > > On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote: > > > > > > > > > > > > > > > > > > > > > An mdev type is meant to define a software > > > > > > > > > > > > > > > > > compatible interface, so in > > > > > > > > > > > > > > > > > the case of mdev->mdev migration, doesn't > > > > > > > > > > > > > > > > > migrating to a different type > > > > > > > > > > > > > > > > > fail the most basic of compatibility tests > > > > > > > > > > > > > > > > > that we expect userspace to > > > > > > > > > > > > > > > > > perform? IOW, if two mdev types are > > > > > > > > > > > > > > > > > migration compatible, it seems a > > > > > > > > > > > > > > > > > prerequisite to that is that they provide the > > > > > > > > > > > > > > > > > same software interface, > > > > > > > > > > > > > > > > > which means they should be the same mdev type. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the hybrid cases of mdev->phys or > > > > > > > > > > > > > > > > > phys->mdev, how does a > > > > > > > > > > > > > > > > management > > > > > > > > > > > > > > > > > tool begin to even guess what might be > > > > > > > > > > > > > > > > > compatible? Are we expecting > > > > > > > > > > > > > > > > > libvirt to probe ever device with this > > > > > > > > > > > > > > > > > attribute in the system? Is > > > > > > > > > > > > > > > > > there going to be a new class hierarchy > > > > > > > > > > > > > > > > > created to enumerate all > > > > > > > > > > > > > > > > > possible migrate-able devices? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yes, management tool needs to guess and test > > > > > > > > > > > > > > > > migration compatible > > > > > > > > > > > > > > > > between two devices. But I think it's not the > > > > > > > > > > > > > > > > problem only for > > > > > > > > > > > > > > > > mdev->phys or phys->mdev. even for mdev->mdev, > > > > > > > > > > > > > > > > management tool needs > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > first assume that the two mdevs have the same > > > > > > > > > > > > > > > > type of parent devices > > > > > > > > > > > > > > > > (e.g.their pciids are equal). otherwise, it's > > > > > > > > > > > > > > > > still enumerating > > > > > > > > > > > > > > > > possibilities. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > on the other hand, for two mdevs, > > > > > > > > > > > > > > > > mdev1 from pdev1, its mdev_type is 1/2 of pdev1; > > > > > > > > > > > > > > > > mdev2 from pdev2, its mdev_type is 1/4 of pdev2; > > > > > > > > > > > > > > > > if pdev2 is exactly 2 times of pdev1, why not > > > > > > > > > > > > > > > > allow migration between > > > > > > > > > > > > > > > > mdev1 <-> mdev2. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How could the manage tool figure out that 1/2 of > > > > > > > > > > > > > > > pdev1 is equivalent > > > > > > > > > > > > > > > to 1/4 of pdev2? If we really want to allow such > > > > > > > > > > > > > > > thing happen, the best > > > > > > > > > > > > > > > choice is to report the same mdev type on both > > > > > > > > > > > > > > > pdev1 and pdev2. > > > > > > > > > > > > > > I think that's exactly the value of this > > > > > > > > > > > > > > migration_version interface. > > > > > > > > > > > > > > the management tool can take advantage of this > > > > > > > > > > > > > > interface to know if two > > > > > > > > > > > > > > devices are migration compatible, no matter they > > > > > > > > > > > > > > are mdevs, non-mdevs, > > > > > > > > > > > > > > or mix. > > > > > > > > > > > > > > > > > > > > > > > > > > > > as I know, (please correct me if not right), > > > > > > > > > > > > > > current libvirt still > > > > > > > > > > > > > > requires manually generating mdev devices, and it > > > > > > > > > > > > > > just duplicates src vm > > > > > > > > > > > > > > configuration to the target vm. > > > > > > > > > > > > > > for libvirt, currently it's always phys->phys and > > > > > > > > > > > > > > mdev->mdev (and of the > > > > > > > > > > > > > > same mdev type). > > > > > > > > > > > > > > But it does not justify that hybrid cases should > > > > > > > > > > > > > > not be allowed. otherwise, > > > > > > > > > > > > > > why do we need to introduce this migration_version > > > > > > > > > > > > > > interface and leave > > > > > > > > > > > > > > the judgement of migration compatibility to vendor > > > > > > > > > > > > > > driver? why not simply > > > > > > > > > > > > > > set the criteria to something like "pciids of > > > > > > > > > > > > > > parent devices are equal, > > > > > > > > > > > > > > and mdev types are equal" ? > > > > >
[PATCH] efi/libstub: refactor Makefile to not use lib-y syntax
Documentation/kbuild/makefiles.rst says: Use of lib-y is normally restricted to `lib/` and `arch/*/lib`. I want to disallow lib-y outside of them. Add a custom rule to build lib.a, which is linked to the decompressor for ARCH=x86, ARCH=arm. For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary way. Signed-off-by: Masahiro Yamada --- arch/arm64/Makefile | 1 - drivers/firmware/efi/Makefile | 2 +- drivers/firmware/efi/libstub/Makefile | 51 +++ 3 files changed, 30 insertions(+), 24 deletions(-) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 650e1185c190..ab79b20efc8d 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -145,7 +145,6 @@ export TEXT_OFFSET core-y += arch/arm64/ libs-y := arch/arm64/lib/ $(libs-y) -core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a # Default target when executing plain make boot := arch/arm64/boot diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile index 7a216984552b..317a05cd388b 100644 --- a/drivers/firmware/efi/Makefile +++ b/drivers/firmware/efi/Makefile @@ -20,7 +20,7 @@ obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o obj-$(CONFIG_UEFI_CPER)+= cper.o obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o -subdir-$(CONFIG_EFI_STUB) += libstub +obj-$(CONFIG_EFI_STUB) += libstub/ obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_map.o obj-$(CONFIG_EFI_BOOTLOADER_CONTROL) += efibc.o obj-$(CONFIG_EFI_TEST) += test/ diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile index cce4a7436052..e4e9b17fa3b2 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -44,7 +44,7 @@ OBJECT_FILES_NON_STANDARD := y # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in. KCOV_INSTRUMENT:= n -lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \ +stub-obj-y := efi-stub-helper.o gop.o secureboot.o tpm.o \ file.o mem.o random.o randomalloc.o pci.o \ skip_spaces.o lib-cmdline.o lib-ctype.o \ alignedmem.o relocate.o vsprintf.o @@ -55,15 +55,19 @@ efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE $(call if_changed_rule,cc_o_c) -lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \ +stub-obj-$(CONFIG_EFI_GENERIC_STUB)+= efi-stub.o fdt.o string.o \ $(patsubst %.c,lib-%.o,$(efi-deps-y)) -lib-$(CONFIG_ARM) += arm32-stub.o -lib-$(CONFIG_ARM64)+= arm64-stub.o -lib-$(CONFIG_X86) += x86-stub.o +stub-obj-$(CONFIG_ARM) += arm32-stub.o +stub-obj-$(CONFIG_ARM64) += arm64-stub.o +stub-obj-$(CONFIG_X86) += x86-stub.o CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) +targets+= $(stub-obj-y) +stub-obj-y := $(patsubst %.o,%.stub.o, $(stub-obj-y)) +targets+= $(stub-obj-y) + # # For x86, bootloaders like systemd-boot or grub-efi do not zero-initialize the # .bss section, so the .bss section of the EFI stub needs to be included in the @@ -83,23 +87,6 @@ STUBCOPY_FLAGS-$(CONFIG_ARM) += --rename-section .data=.data.efistub \ --rename-section .bss=.bss.efistub,load,alloc STUBCOPY_RELOC-$(CONFIG_ARM) := R_ARM_ABS -# -# arm64 puts the stub in the kernel proper, which will unnecessarily retain all -# code indefinitely unless it is annotated as __init/__initdata/__initconst etc. -# So let's apply the __init annotations at the section level, by prefixing -# the section names directly. This will ensure that even all the inline string -# literals are covered. -# The fact that the stub and the kernel proper are essentially the same binary -# also means that we need to be extra careful to make sure that the stub does -# not rely on any absolute symbol references, considering that the virtual -# kernel mapping that the linker uses is not active yet when the stub is -# executing. So build all C dependencies of the EFI stub into libstub, and do -# a verification pass to see if any absolute relocations exist in any of the -# object files. -# -extra-y:= $(lib-y) -lib-y := $(patsubst %.o,%.stub.o,$(lib-y)) - STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \ --prefix-symbols=__efistub_ STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS @@ -121,3
Re: [PATCH V6 4/5] clk: qcom: Add ipq6018 apss clock controller
Quoting Sivaprakash Murugesan (2020-06-02 03:47:20)
>
> On 6/2/2020 1:06 AM, Stephen Boyd wrote:
> > Quoting Sivaprakash Murugesan (2020-06-01 05:41:15)
> >> On 5/28/2020 7:29 AM, Stephen Boyd wrote:
> >>> Quoting Sivaprakash Murugesan (2020-05-27 05:24:51)
> diff --git a/drivers/clk/qcom/apss-ipq6018.c
> b/drivers/clk/qcom/apss-ipq6018.c
> new file mode 100644
> index 000..004f7e1
> --- /dev/null
> +++ b/drivers/clk/qcom/apss-ipq6018.c
> @@ -0,0 +1,106 @@
> + P_XO,
> + P_APSS_PLL_EARLY,
> +};
> +
> +static const struct clk_parent_data parents_apcs_alias0_clk_src[] = {
> + { .fw_name = "xo" },
> + { .fw_name = "pll" },
> >>> This pll clk is not described in the binding. Please add it there.
> >> Sorry I did not get this, this PLL is not directly defined in this
> >> driver and it comes
> >>
> >> from dts. do you still want to describe it in binding?
> >>
> > Yes, there should be a clock-names property for "pll" and a clocks
> > property in the binding document. I didn't see that.
>
> These are defined in
>
> https://lkml.org/lkml/2020/5/27/658and
>
> https://lkml.org/lkml/2020/5/27/659
>
> it has been defined as part of mailbox binding, since this driver does
>
> not have a dts node and it is child of apcs mailbox driver.
>
Ah alright. Sounds good.
Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
Evan,
Thanks for taking time to review
the series.
On 2020-06-02 23:14, Evan Green wrote:
On Tue, Jun 2, 2020 at 9:33 AM Sibi Sankar
wrote:
Sometimes the stop triggers a watchdog rather than a stop-ack. Update
the running state to false on requesting stop to skip the watchdog
instead.
Error Logs:
$ echo stop > /sys/class/remoteproc/remoteproc0/state
ipa 1e4.ipa: received modem stopping event
remoteproc-modem: watchdog received: sys_m_smsm_mpss.c:291:APPS force
stop
qcom-q6v5-mss 408.remoteproc-modem: port failed halt
ipa 1e4.ipa: received modem offline event
remoteproc0: stopped remote processor 408.remoteproc-modem
Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource
handling")
Cc: sta...@vger.kernel.org
Signed-off-by: Sibi Sankar
---
Are you sure you want to tolerate this behavior from MSS? This is a
graceful shutdown, modem shouldn't have a problem completing the
proper handshake. If they do, isn't that a bug on the modem side?
The graceful shutdown is achieved
though sysmon (enabled using
CONFIG_QCOM_SYSMON). When sysmon is
enabled we get a shutdown-ack when we
try to stop the modem, post which
request stop is a basically a nop.
Request stop is done to force stop
the modem during failure cases (like
rmtfs is not running and so on) and
we do want to mask the wdog that we get
during this scenario ( The locking
already prevents the servicing of the
wdog during shutdown, the check just
prevents the scheduling of crash handler
and err messages associated with it).
Also this check was always present and
was missed during common q6v5 resource
helper migration, hence the unused
running state in mss driver.
I just worry this will mask real issues that happen during graceful
shutdown.
-Evan
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices
On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> +static bool risky_device(struct pci_dev *pdev)
> +{
> + if (pdev->untrusted) {
> + pci_warn(pdev,
> + "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> + " PCI link. Please check with your BIOS/Platform"
> + " vendor about this\n", pdev->vendor, pdev->device);
You should not break user visible strings like this. It makes grepping
for them harder (see also CodingStyle). You can write it like this instead:
pci_info(pdev, "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted
PCI link\n",
pdev->vendor, pdev->device);
pci_info(pdev, "Please check with your BIOS/Platform vendor about
this\n");
Also I guess pci_info() might be better here after all. Your call :)
Rest of the patch looks good to me.
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Wed, Jun 03, 2020 at 02:48:15AM +0100, Al Viro wrote: > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote: > > So vhost needs to poke at userspace *a lot* in a quick succession. It > > is thus benefitial to enable userspace access, do our thing, then > > disable. Except access_ok has already been pre-validated with all the > > relevant nospec checks, so we don't need that. Add an API to allow > > userspace access after access_ok and barrier_nospec are done. > > BTW, what are you going to do about vq->iotlb != NULL case? Because > you sure as hell do *NOT* want e.g. translate_desc() under STAC. > Disable it around the calls of translate_desc()? > > How widely do you hope to stretch the user_access areas, anyway? So ATM I'm looking at adding support for the packed ring format. That does something like: get_user(flags, desc->flags) smp_rmb() if (flags & VALID) copy_from_user(, desc, sizeof adesc); this would be a good candidate I think. > BTW, speaking of possible annotations: looks like there's a large > subset of call graph that can be reached only from vhost_worker() > or from several ioctls, with all uaccess limited to that subgraph > (thankfully). Having that explicitly marked might be a good idea... Sure. What's a good way to do that though? Any examples to follow? Or do you mean code comments? > Unrelated question, while we are at it: is there any point having > vhost_get_user() a polymorphic macro? In all callers the third > argument is __virtio16 __user * and the second one is an explicit > * where is __virtio16 *. Similar for > vhost_put_user(): in all callers the third arugment is > __virtio16 __user * and the second - cpu_to_vhost16(vq, something). > > Incidentally, who had come up with the name __vhost_get_user? > Makes for lovey WTF moment for readers - esp. in vhost_put_user()... Good points, I'll fix these. -- MST
Re: [PATCH 11/15] mmc: sdhci: use PCI_IRQ_MSI_TYPES where appropriate
On Tue, Jun 02, 2020 at 11:20:59AM +0200, Piotr Stankiewicz wrote: > Seeing as there is shorthand available to use when asking for any type > of interrupt, or any type of message signalled interrupt, leverage it. > > Signed-off-by: Piotr Stankiewicz > Reviewed-by: Andy Shevchenko So this crap now shows up piecemail on various lists? Indepent of that it seems like a bad idea to start with, bombing people with patches that apparently depend on something you did first but they are not Cced on is just an amazingly bad idea. Don't do that ever.
[PATCH 2/3] mailbox: imx: Add runtime PM callback to handle MU clocks
Some of i.MX8M SoCs have MU clock, they need to be managed in runtime
to make sure the MU clock can be off in runtime, add runtime PM callback
to handle MU clock.
And on i.MX8MP, the MU clock is combined with power domain and runtime
PM is enabled for the clock driver, during noirq suspend/resume phase,
runtime PM is disabled by device suspend, but the MU context save/restore
needs to enable MU clock for register access, calling clock prepare/enable
will trigger runtime resume failure and lead to system suspend failed.
Actually, the MU context save/restore is ONLY necessary for SCU IPC MU,
other MUs especially on i.MX8MP platforms which have MU clock assigned,
they need to runtime request/free mailbox channel in the consumer driver,
so no need to save/restore MU context for them, hence it can avoid this
issue, so the MU context save/restore is ONLY applied to i.MX platforms
MU instance without clock present.
Signed-off-by: Anson Huang
---
drivers/mailbox/imx-mailbox.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index da90a8e..080b608 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -536,10 +536,13 @@ static int imx_mu_probe(struct platform_device *pdev)
if (ret < 0)
goto disable_runtime_pm;
+ clk_disable_unprepare(priv->clk);
+
return 0;
disable_runtime_pm:
pm_runtime_disable(dev);
+ clk_disable_unprepare(priv->clk);
return ret;
}
@@ -547,7 +550,6 @@ static int imx_mu_remove(struct platform_device *pdev)
{
struct imx_mu_priv *priv = platform_get_drvdata(pdev);
- clk_disable_unprepare(priv->clk);
pm_runtime_disable(priv->dev);
return 0;
@@ -595,7 +597,8 @@ static int imx_mu_suspend_noirq(struct device *dev)
{
struct imx_mu_priv *priv = dev_get_drvdata(dev);
- priv->xcr = imx_mu_read(priv, priv->dcfg->xCR);
+ if (!priv->clk)
+ priv->xcr = imx_mu_read(priv, priv->dcfg->xCR);
return 0;
}
@@ -612,15 +615,38 @@ static int imx_mu_resume_noirq(struct device *dev)
* send failed, may lead to system freeze. This issue
* is observed by testing freeze mode suspend.
*/
- if (!imx_mu_read(priv, priv->dcfg->xCR))
+ if (!imx_mu_read(priv, priv->dcfg->xCR) && !priv->clk)
imx_mu_write(priv, priv->xcr, priv->dcfg->xCR);
return 0;
}
+static int imx_mu_runtime_suspend(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(priv->clk);
+
+ return 0;
+}
+
+static int imx_mu_runtime_resume(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ dev_err(dev, "failed to enable clock\n");
+
+ return ret;
+}
+
static const struct dev_pm_ops imx_mu_pm_ops = {
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_mu_suspend_noirq,
imx_mu_resume_noirq)
+ SET_RUNTIME_PM_OPS(imx_mu_runtime_suspend,
+ imx_mu_runtime_resume, NULL)
};
static struct platform_driver imx_mu_driver = {
--
2.7.4
[PATCH 1/3] mailbox: imx: Add context save/restore for suspend/resume
From: Dong Aisheng
For "mem" mode suspend on i.MX8 SoCs, MU settings could be
lost because its power is off, so save/restore is needed
for MU settings during suspend/resume. However, the restore
can ONLY be done when MU settings are actually lost, for the
scenario of settings NOT lost in "freeze" mode suspend, since
there could be still IPC going on multiple CPUs, restoring the
MU settings could overwrite the TIE by mistake and cause system
freeze, so need to make sure ONLY restore the MU settings when
it is powered off, Anson fixes this by checking whether restore
is actually needed when resume.
Signed-off-by: Dong Aisheng
Signed-off-by: Anson Huang
---
drivers/mailbox/imx-mailbox.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index bd69ecf..da90a8e 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -67,6 +67,8 @@ struct imx_mu_priv {
struct clk *clk;
int irq;
+ u32 xcr;
+
boolside_b;
};
@@ -589,12 +591,45 @@ static const struct of_device_id imx_mu_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
+static int imx_mu_suspend_noirq(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+ priv->xcr = imx_mu_read(priv, priv->dcfg->xCR);
+
+ return 0;
+}
+
+static int imx_mu_resume_noirq(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+ /*
+* ONLY restore MU when context lost, the TIE could
+* be set during noirq resume as there is MU data
+* communication going on, and restore the saved
+* value will overwrite the TIE and cause MU data
+* send failed, may lead to system freeze. This issue
+* is observed by testing freeze mode suspend.
+*/
+ if (!imx_mu_read(priv, priv->dcfg->xCR))
+ imx_mu_write(priv, priv->xcr, priv->dcfg->xCR);
+
+ return 0;
+}
+
+static const struct dev_pm_ops imx_mu_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_mu_suspend_noirq,
+ imx_mu_resume_noirq)
+};
+
static struct platform_driver imx_mu_driver = {
.probe = imx_mu_probe,
.remove = imx_mu_remove,
.driver = {
.name = "imx_mu",
.of_match_table = imx_mu_dt_ids,
+ .pm = _mu_pm_ops,
},
};
module_platform_driver(imx_mu_driver);
--
2.7.4
[PATCH 0/3] Handle mailbox clock/power management related issues
Current i.MX mailbox driver mainly supports 2 series i.MX SoCs with different architecture, one is for i.MX8X platforms with SCU inside, the other is for i.MX6/7/8M series without SCU. For i.MX8X, 2 types of MU are supported, one is for system IPC, such kind of MU has no clock/power assignment, they are both controlled by SCU. The other is for application, such kind of MU has no clock assignment, but have power domain assignment, consumers need to call mailbox APIs to manage MU power in runtime; For i.MX6/7/8M, MU clock or power could be assigned based on different SoCs, but all the MUs are for application, consumers need to call mailbox APIs to manage MU clock/power in runtime. For the power management related issue mentioned above, they are as below: 1. clock should be managed in runtime to make sure MU clock/power can be off on i.MX6/7/8M platforms; 2. ONLY system IPC MU needs to have IRQF_NO_SUSPEND flag set, other application MU no need to have this flag, since the MU clock/power is OFF in noirq suspend phase and if MU interrupt arrives, with IRQF_NO_SUSPEND flag set, the MU ISR will try to access MU register and lead to system hang because of clock/power disabled; To distinguish these different MU instances, use MU's clock/power assignment status to decide whether to save/restore MU context during suspend/resume, whether to have IRQF_NO_SUSPEND flag set, etc.. patch #1 is identical with https://patchwork.kernel.org/patch/11581215/, the patch #2/#3 depend on #1, so I resend #1 in this series to make them as a whole series. Anson Huang (2): mailbox: imx: Add runtime PM callback to handle MU clocks mailbox: imx: ONLY IPC MU needs IRQF_NO_SUSPEND flag Dong Aisheng (1): mailbox: imx: Add context save/restore for suspend/resume drivers/mailbox/imx-mailbox.c | 72 +-- 1 file changed, 69 insertions(+), 3 deletions(-) -- 2.7.4
[PATCH 3/3] mailbox: imx: ONLY IPC MU needs IRQF_NO_SUSPEND flag
IPC MU has no power domain assigned and there could be IPC during
noirq suspend phase, so IRQF_NO_SUSPEND flag is needed for IPC MU.
However, for other MUs, they have power domain assigned and their
power will be turned off during noirq suspend phase, but with
IRQF_NO_SUSPEND set, their interrupts are NOT disabled even after
their power turned off, it will cause system crash when mailbox
driver trys to handle pending interrupts but the MU power is already
turned off.
So, IRQF_NO_SUSPEND flag should ONLY be added to IPC MU which has
power domain managed by SCU, then all other MUs' pending interrupts
after noirq suspend phase will be handled after system resume.
Signed-off-by: Anson Huang
---
drivers/mailbox/imx-mailbox.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 080b608..7205b82 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -292,6 +292,7 @@ static int imx_mu_startup(struct mbox_chan *chan)
{
struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
struct imx_mu_con_priv *cp = chan->con_priv;
+ unsigned long irq_flag = IRQF_SHARED;
int ret;
pm_runtime_get_sync(priv->dev);
@@ -302,8 +303,12 @@ static int imx_mu_startup(struct mbox_chan *chan)
return 0;
}
- ret = request_irq(priv->irq, imx_mu_isr, IRQF_SHARED |
- IRQF_NO_SUSPEND, cp->irq_desc, chan);
+ /* IPC MU should be with IRQF_NO_SUSPEND set */
+ if (!priv->dev->pm_domain)
+ irq_flag |= IRQF_NO_SUSPEND;
+
+ ret = request_irq(priv->irq, imx_mu_isr, irq_flag,
+ cp->irq_desc, chan);
if (ret) {
dev_err(priv->dev,
"Unable to acquire IRQ %d\n", priv->irq);
--
2.7.4
Re: [PATCH] arch/x86: reset MXCSR to default in kernel_fpu_begin()
Hi, > Is it correct to assume the stuff checked differs from test to test > and done in user-space. > > > undo_evil_state(); > > Is it correct to assume undoing evil differs from test to test > and done in user-space, provide it can be done from userspace. Yes, currently the test works like: do_test_setup(); read_from_debugfs_file(); check_results(); and the middle step stays the same. But of course in general case there could be argument passing etc, even though the test for this issue doesn't need them. Myself I don't see the problem with just adding a file under debugfs and bind to its read. -- Petteri
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On 2020/6/3 下午12:18, Al Viro wrote: On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote: How widely do you hope to stretch the user_access areas, anyway? To have best performance for small packets like 64B, if possible, we want to disable STAC not only for the metadata access done by vhost accessors but also the data access via iov iterator. If you want to try and convince Linus to go for that, make sure to Cc me on that thread. Always liked quality flame... The same goes for interval tree lookups with uaccess allowed. IOW, I _really_ doubt that it's a good idea. I see. We are just seeking an approach to perform better in order to compete with userspace dpdk backends. I tried another approach of using direct mapping + mmu notifier [1] but the synchronization with MMU notifier is not easy to perform well. [1] https://patchwork.kernel.org/patch/11133009/ Incidentally, who had come up with the name __vhost_get_user? Makes for lovey WTF moment for readers - esp. in vhost_put_user()... I think the confusion comes since it does not accept userspace pointer (when IOTLB is enabled). How about renaming it as vhost_read()/vhost_write() ? Huh? __vhost_get_user() is IOTLB remapping of userland pointer. It does not access userland memory. Neither for read, nor for write. It is used by vhost_get_user() and vhost_put_user(). Why would you want to rename it into vhost_read _or_ vhost_write, and in any case, how do you give one function two names? IDGI... I get you know, I thought you're concerning the names of vhost_get_user()/vhost_put_user() but actually __vhost_get_user(). Maybe something like __vhost_fetch_uaddr() is better. Thanks
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Tue, Jun 02, 2020 at 11:10:57PM +0100, Al Viro wrote: > On Tue, Jun 02, 2020 at 04:42:03PM -0400, Michael S. Tsirkin wrote: > > On Tue, Jun 02, 2020 at 05:30:48PM +0100, Al Viro wrote: > > > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote: > > > > So vhost needs to poke at userspace *a lot* in a quick succession. It > > > > is thus benefitial to enable userspace access, do our thing, then > > > > disable. Except access_ok has already been pre-validated with all the > > > > relevant nospec checks, so we don't need that. Add an API to allow > > > > userspace access after access_ok and barrier_nospec are done. > > > > > > This is the wrong way to do it, and this API is certain to be abused > > > elsewhere. NAK - we need to sort out vhost-related problems, but > > > this is not an acceptable solution. Sorry. > > > > OK so summarizing what you and Linus both said, we need at > > least a way to make sure access_ok (and preferably the barrier too) > > is not missed. > > > > Another comment is about actually checking that performance impact > > is significant and worth the complexity and risk. > > > > Is that a fair summary? > > > > I'm actually thinking it's doable with a new __unsafe_user type of > > pointer, sparse will then catch errors for us. > > Er... how would sparse keep track of the range? Using types. So you start with a user pointer: struct foo __user *up; Now you validate it, including a speculation barrier: struct foo __valdated_user *p = user_access_validate(up, sizeof *up); and you can save it and use it with something like unsafe_get_user and unsafe_put_user that gets __valdated_user pointers: user_access_begin_validated(p, sizeof *p) valiated_get_user(bar, foo->bar, err_fault) valiated_put_user(baz, foo->baz, err_fault) user_access_end() -- MST
Re: [PATCH 04/15] ahci: use PCI_IRQ_MSI_TYPES where appropriate
On Tue, Jun 02, 2020 at 11:20:12AM +0200, Piotr Stankiewicz wrote: > Seeing as there is shorthand available to use when asking for any type > of interrupt, or any type of message signalled interrupt, leverage it. > > Signed-off-by: Piotr Stankiewicz > Reviewed-by: Andy Shevchenko Im not sure where PCI_IRQ_MSI_TYPES appeared (I can't find it in mainline), but I think replacing the supported list of types with this weird group is no in any way a good idea.
Re: cxl: Fix kobject memory leak in cxl_sysfs_afu_new_cr()
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=f359287765c04711ff54fbd11645271d8e5ff763#n465 >> I just used the original author's label, should I replace all his labels >> like'err','err1' with reasonable one. > > No. Do you insist to deviate from the current Linux coding style? Regards, Markus
Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode
Hi Eric, I'm still trying to understand what you're saying before. Would this be better as following: 1) discard the tcp_internal_pacing() function. 2) remove where the tcp_internal_pacing() is called in the __tcp_transmit_skb() function. If we do so, we could avoid 'too late to give up pacing'. Meanwhile, should we introduce the tcp_wstamp_ns socket field as commit (864e5c090749) does? Thanks, Jason On Wed, Jun 3, 2020 at 10:44 AM Eric Dumazet wrote: > > On Tue, Jun 2, 2020 at 7:42 PM Jason Xing wrote: > > > > I agree with you. The upstream has already dropped and optimized this > > part (commit 864e5c090749), so it would not happen like that. However > > the old kernels like LTS still have the problem which causes > > large-scale crashes on our thousands of machines after running for a > > long while. I will send the fix to the correct tree soon :) > > If you run BBR at scale (thousands of machines), you probably should > use sch_fq instead of internal pacing, > just saying ;) > > > > > > Thanks again, > > Jason > > > > On Wed, Jun 3, 2020 at 10:29 AM Eric Dumazet wrote: > > > > > > On Tue, Jun 2, 2020 at 6:53 PM Jason Xing > > > wrote: > > > > > > > > Hi Eric, > > > > > > > > I'm sorry that I didn't write enough clearly. We're running the > > > > pristine 4.19.125 linux kernel (the latest LTS version) and have been > > > > haunted by such an issue. This patch is high-important, I think. So > > > > I'm going to resend this email with the [patch 4.19] on the headline > > > > and cc Greg. > > > > > > Yes, please always give for which tree a patch is meant for. > > > > > > Problem is that your patch is not correct. > > > In these old kernels, tcp_internal_pacing() is called _after_ the > > > packet has been sent. > > > It is too late to 'give up pacing' > > > > > > The packet should not have been sent if the pacing timer is queued > > > (otherwise this means we do not respect pacing) > > > > > > So the bug should be caught earlier. check where tcp_pacing_check() > > > calls are missing. > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > Jason > > > > > > > > On Tue, Jun 2, 2020 at 9:05 PM Eric Dumazet wrote: > > > > > > > > > > On Tue, Jun 2, 2020 at 1:05 AM wrote: > > > > > > > > > > > > From: Jason Xing > > > > > > > > > > > > TCP socks cannot be released because of the sock_hold() increasing > > > > > > the > > > > > > sk_refcnt in the manner of tcp_internal_pacing() when RTO happens. > > > > > > Therefore, this situation could increase the slab memory and then > > > > > > trigger > > > > > > the OOM if the machine has beening running for a long time. This > > > > > > issue, > > > > > > however, can happen on some machine only running a few days. > > > > > > > > > > > > We add one exception case to avoid unneeded use of sock_hold if the > > > > > > pacing_timer is enqueued. > > > > > > > > > > > > Reproduce procedure: > > > > > > 0) cat /proc/slabinfo | grep TCP > > > > > > 1) switch net.ipv4.tcp_congestion_control to bbr > > > > > > 2) using wrk tool something like that to send packages > > > > > > 3) using tc to increase the delay in the dev to simulate the busy > > > > > > case. > > > > > > 4) cat /proc/slabinfo | grep TCP > > > > > > 5) kill the wrk command and observe the number of objects and slabs > > > > > > in TCP. > > > > > > 6) at last, you could notice that the number would not decrease. > > > > > > > > > > > > Signed-off-by: Jason Xing > > > > > > Signed-off-by: liweishi > > > > > > Signed-off-by: Shujin Li > > > > > > --- > > > > > > net/ipv4/tcp_output.c | 3 ++- > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > > > > > > index cc4ba42..5cf63d9 100644 > > > > > > --- a/net/ipv4/tcp_output.c > > > > > > +++ b/net/ipv4/tcp_output.c > > > > > > @@ -969,7 +969,8 @@ static void tcp_internal_pacing(struct sock > > > > > > *sk, const struct sk_buff *skb) > > > > > > u64 len_ns; > > > > > > u32 rate; > > > > > > > > > > > > - if (!tcp_needs_internal_pacing(sk)) > > > > > > + if (!tcp_needs_internal_pacing(sk) || > > > > > > + hrtimer_is_queued(_sk(sk)->pacing_timer)) > > > > > > return; > > > > > > rate = sk->sk_pacing_rate; > > > > > > if (!rate || rate == ~0U) > > > > > > -- > > > > > > 1.8.3.1 > > > > > > > > > > > > > > > > Hi Jason. > > > > > > > > > > Please do not send patches that do not apply to current upstream > > > > > trees. > > > > > > > > > > Instead, backport to your kernels the needed fixes. > > > > > > > > > > I suspect that you are not using a pristine linux kernel, but some > > > > > heavily modified one and something went wrong in your backports. > > > > > Do not ask us to spend time finding what went wrong. > > > > > > > > > > Thank you.
Re: drm/nouveau/clk/gm20b: Understanding challenges around gm20b_clk_new()
> Ben has explained this problem: > https://lore.kernel.org/patchwork/patch/1249592/ > Since the caller will check "pclk" on failure, we don't need to free > "clk" in gm20b_clk_new() and I think this patch is no longer needed. * I am curious if it can become easier to see the relationships for these variables according to mentioned “destructor” calls. * Did you notice opportunities to improve source code analysis (or software documentation) accordingly? Regards, Markus
Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split
On 06/03/2020 08:27 AM, Matthew Wilcox wrote: > On Wed, Jun 03, 2020 at 06:56:57AM +0530, Anshuman Khandual wrote: >> On 06/02/2020 08:31 PM, Matthew Wilcox wrote: >>> On Fri, May 22, 2020 at 09:04:04AM +0530, Anshuman Khandual wrote: This adds the following two new VM events which will help in validating PMD based THP migration without split. Statistics reported through these events will help in performance debugging. 1. THP_PMD_MIGRATION_SUCCESS 2. THP_PMD_MIGRATION_FAILURE >>> >>> There's nothing actually PMD specific about these events, is there? >>> If we have a THP of a non-PMD size, you'd want that reported through the >>> same statistic, wouldn't you? >> >> Yes, there is nothing PMD specific here and we would use the same statistics >> for non-PMD size THP migration (if any) as well. But is THP migration really >> supported for non-PMD sizes ? CONFIG_ARCH_ENABLE_THP_MIGRATION depends upon >> CONFIG_TRANSPARENT_HUGEPAGE without being specific or denying about possible >> PUD level support. Fair enough, will drop the PMD from the events and their >> functions. > > I guess you haven't read my large pages patchset? I believe you are referring this "[PATCH v5 00/39] Large pages in the page cache" (https://lkml.org/lkml/2020/5/28/1755). Unfortunately, I have not been following the series. But is there something else in particular that needs to be taken care of as well ?
Re: [PATCH RFC 1/3] block: add flag 'nowait_requests' into queue limits
On Mon, Jun 01, 2020 at 03:37:09PM +0300, Konstantin Khlebnikov wrote: > Add flag for marking bio-based queues which support REQ_NOWAIT. > Set for all request based (mq) devices. > > Stacking device should set it after blk_set_stacking_limits() if method > make_request() itself doesn't delay requests or handles REQ_NOWAIT. I don't think this belongs into the queue limits. For example a stacking driver that always defers requests to a workqueue can support REQ_NOWAIT entirely independent of the underlying devices. I think this just needs to be a simple queue flag.
Re: [PATCH v4 4/4] kdb: Switch to use safer dbg_io_ops over console APIs
On Wed, 3 Jun 2020 at 03:02, Doug Anderson wrote:
>
> Hi,
>
> On Fri, May 29, 2020 at 4:27 AM Sumit Garg wrote:
> >
> > In kgdb context, calling console handlers aren't safe due to locks used
> > in those handlers which could in turn lead to a deadlock. Although, using
> > oops_in_progress increases the chance to bypass locks in most console
> > handlers but it might not be sufficient enough in case a console uses
> > more locks (VT/TTY is good example).
> >
> > Currently when a driver provides both polling I/O and a console then kdb
> > will output using the console. We can increase robustness by using the
> > currently active polling I/O driver (which should be lockless) instead
> > of the corresponding console. For several common cases (e.g. an
> > embedded system with a single serial port that is used both for console
> > output and debugger I/O) this will result in no console handler being
> > used.
> >
> > In order to achieve this we need to reverse the order of preference to
> > use dbg_io_ops (uses polling I/O mode) over console APIs. So we just
> > store "struct console" that represents debugger I/O in dbg_io_ops and
> > while emitting kdb messages, skip console that matches dbg_io_ops
> > console in order to avoid duplicate messages. After this change,
> > "is_console" param becomes redundant and hence removed.
> >
> > Suggested-by: Daniel Thompson
> > Signed-off-by: Sumit Garg
> > ---
> > drivers/tty/serial/kgdb_nmi.c | 2 +-
> > drivers/tty/serial/kgdboc.c | 4 ++--
>
> I don't think this will compile against the "kgdboc_earlycon" patches
> that landed, will it? Specifically when I apply your patch I still
> see "is_console" in:
Agree will fix this and rebase this patch-set onto Daniel's tree.
>
> static struct kgdb_io kgdboc_earlycon_io_ops = {
> .name = "kgdboc_earlycon",
> .read_char = kgdboc_earlycon_get_char,
> .write_char = kgdboc_earlycon_put_char,
> .pre_exception = kgdboc_earlycon_pre_exp_handler,
> .deinit = kgdboc_earlycon_deinit,
> .is_console = true,
> };
>
>
> > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
> > index b072aeb..bc0face3 100644
> > --- a/include/linux/kgdb.h
> > +++ b/include/linux/kgdb.h
> > @@ -273,8 +273,7 @@ struct kgdb_arch {
> > * the I/O driver.
> > * @post_exception: Pointer to a function that will do any cleanup work
> > * for the I/O driver.
> > - * @is_console: 1 if the end device is a console 0 if the I/O device is
> > - * not a console
> > + * @cons: valid if the I/O device is a console.
>
> optional nit: add "; else NULL"
>
Okay.
>
> Other than that this looks great. Feel free to add my Reviewed-by:
> tag once you've fixed the error that the bot found and resolved with
> kgdb_earlycon.
>
Thanks.
-Sumit
>
> -Doug
Re: [PATCH v4 1/4] kdb: Re-factor kdb_printf() message write code
On Wed, 3 Jun 2020 at 03:02, Doug Anderson wrote:
>
> Hi,
>
> On Fri, May 29, 2020 at 4:27 AM Sumit Garg wrote:
> >
> > Re-factor kdb_printf() message write code in order to avoid duplication
> > of code and thereby increase readability.
> >
> > Signed-off-by: Sumit Garg
> > ---
> > kernel/debug/kdb/kdb_io.c | 61
> > +--
> > 1 file changed, 32 insertions(+), 29 deletions(-)
> >
> > diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
> > index 924bc92..e46f33e 100644
> > --- a/kernel/debug/kdb/kdb_io.c
> > +++ b/kernel/debug/kdb/kdb_io.c
> > @@ -542,6 +542,33 @@ static int kdb_search_string(char *searched, char
> > *searchfor)
> > return 0;
> > }
> >
> > +static void kdb_io_write(char *cp, int len)
>
> nit: "const char *" just to make it obvious that we don't modify the string?
>
>
> > +{
> > + if (len == 0)
> > + return;
>
> Remove the above check. It's double-overkill. Not only did you just
> check in kdb_msg_write() but also the while loop below will do a
> "no-op" just fine even without your check.
>
I will get rid of kdb_io_write() as per Daniel's comment on patch #4.
>
> > +
> > + while (len--) {
> > + dbg_io_ops->write_char(*cp);
> > + cp++;
> > + }
> > +}
> > +
> > +static void kdb_msg_write(char *msg, int msg_len)
>
> nit: "const char *" just to make it obvious that we don't modify the string?
>
Okay.
>
> Other than those small things, this looks nice to me. Feel free to
> add my Reviewed-by tag once small things are fixed.
>
Thanks.
-Sumit
>
> -Doug
Re: linux-next: manual merge of the akpm-current tree with the tip tree
Hi all,
On Mon, 25 May 2020 21:04:43 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/x86/mm/tlb.c
>
> between commit:
>
> 83ce56f712af ("x86/mm: Refactor cond_ibpb() to support other use cases")
>
> from the tip tree and commit:
>
> 36c8e34d03a1 ("x86/mm: remove vmalloc faulting")
>
> from the akpm-current tree.
>
> diff --cc arch/x86/mm/tlb.c
> index c8524c506ab0,f3fe261e5936..
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@@ -345,48 -161,16 +345,20 @@@ void switch_mm(struct mm_struct *prev,
> local_irq_restore(flags);
> }
>
> - static void sync_current_stack_to_mm(struct mm_struct *mm)
> - {
> - unsigned long sp = current_stack_pointer;
> - pgd_t *pgd = pgd_offset(mm, sp);
> -
> - if (pgtable_l5_enabled()) {
> - if (unlikely(pgd_none(*pgd))) {
> - pgd_t *pgd_ref = pgd_offset_k(sp);
> -
> - set_pgd(pgd, *pgd_ref);
> - }
> - } else {
> - /*
> - * "pgd" is faked. The top level entries are "p4d"s, so sync
> - * the p4d. This compiles to approximately the same code as
> - * the 5-level case.
> - */
> - p4d_t *p4d = p4d_offset(pgd, sp);
> -
> - if (unlikely(p4d_none(*p4d))) {
> - pgd_t *pgd_ref = pgd_offset_k(sp);
> - p4d_t *p4d_ref = p4d_offset(pgd_ref, sp);
> -
> - set_p4d(p4d, *p4d_ref);
> - }
> - }
> - }
> -
> -static inline unsigned long mm_mangle_tif_spec_ib(struct task_struct *next)
> +static inline unsigned long mm_mangle_tif_spec_bits(struct task_struct
> *next)
> {
> unsigned long next_tif = task_thread_info(next)->flags;
> -unsigned long ibpb = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_IBPB;
> +unsigned long spec_bits = (next_tif >> TIF_SPEC_IB) &
> LAST_USER_MM_SPEC_MASK;
>
> -return (unsigned long)next->mm | ibpb;
> +BUILD_BUG_ON(TIF_SPEC_L1D_FLUSH != TIF_SPEC_IB + 1);
> +
> +return (unsigned long)next->mm | spec_bits;
> }
>
> -static void cond_ibpb(struct task_struct *next)
> +static void cond_mitigation(struct task_struct *next)
> {
> +unsigned long prev_mm, next_mm;
> +
> if (!next || !next->mm)
> return;
>
> @@@ -587,20 -343,12 +559,11 @@@ void switch_mm_irqs_off(struct mm_struc
> need_flush = true;
> } else {
> /*
> - * Avoid user/user BTB poisoning by flushing the branch
> - * predictor when switching between processes. This stops
> - * one process from doing Spectre-v2 attacks on another.
> + * Apply process to process speculation vulnerability
> + * mitigations if applicable.
>*/
> -cond_ibpb(tsk);
> +cond_mitigation(tsk);
>
> - if (IS_ENABLED(CONFIG_VMAP_STACK)) {
> - /*
> - * If our current stack is in vmalloc space and isn't
> - * mapped in the new pgd, we'll double-fault. Forcibly
> - * map it.
> - */
> - sync_current_stack_to_mm(next);
> - }
> -
> /*
>* Stop remote flushes for the previous mm.
>* Skip kernel threads; we never send init_mm TLB flushing IPIs,
This is now a conflict between commit
94709049fb84 ("Merge branch 'akpm' (patches from Andrew)")
from Linus' tree and the above tip tree commit.
--
Cheers,
Stephen Rothwell
pgpgZXYeA_qYi.pgp
Description: OpenPGP digital signature
Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split
On 06/02/2020 08:22 PM, Daniel Jordan wrote: > On Mon, Jun 01, 2020 at 09:48:09PM -0700, John Hubbard wrote: >> However, the fact that this is under discussion hints at the need for a >> bit of documentation help. What do you think about adding some notes about >> all of this to, say, Documentation/vm/page_migration.rst ? > > Yes, that would be good. I understand the intent better now but still think > the 'failure' event could be misinterpreted as outright failure instead of > splitting followed by successfully moving the constituent pages. Does this look okay and sufficient ? --- a/Documentation/vm/page_migration.rst +++ b/Documentation/vm/page_migration.rst @@ -253,5 +253,20 @@ which are function pointers of struct address_space_operations. PG_isolated is alias with PG_reclaim flag so driver shouldn't use the flag for own purpose. +Quantifying Migration += +Following events can be used to quantify page migration. + +- PGMIGRATE_SUCCESS +- PGMIGRATE_FAIL +- THP_MIGRATION_SUCCESS +- THP_MIGRATION_FAILURE + +THP_MIGRATION_FAILURE in particular represents an event when a THP could not be +migrated as a single entity following an allocation failure and ended up getting +split into constituent normal pages before being retried. This event, along with +PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will help in quantifying and analyzing THP +migration events including both success and failure cases. + > > It might help to clarify in the changelog as well. > Sure, will update the commit message accordingly.
Re: ARCH=arm64 build breakage for Kbuild for-next branch
Hi Masahiro, On Wed, 3 Jun 2020 13:11:59 +0900 Masahiro Yamada wrote: > > If you pull the latest kbuild for-next branch, > ARCH=arm64 will fail to build. > > I will fix it soon. > > For today's linux-next, you can patch > as follows. > (or, you can use the old branch) > > > diff --git a/Makefile b/Makefile > index f80c4ff93ec9..fbb4b95ae648 100644 > --- a/Makefile > +++ b/Makefile > @@ -1074,7 +1074,7 @@ build-dirs:= $(vmlinux-dirs) > clean-dirs := $(vmlinux-alldirs) > > # Externally visible symbols (used by link-vmlinux.sh) > -KBUILD_VMLINUX_OBJS := $(head-y) $(addsuffix built-in.a, $(core-y)) > +KBUILD_VMLINUX_OBJS := $(head-y) $(patsubst %/,%/built-in.a, $(core-y)) > KBUILD_VMLINUX_OBJS += $(addsuffix built-in.a, $(filter %/, $(libs-y))) > ifdef CONFIG_MODULES > KBUILD_VMLINUX_OBJS += $(patsubst %/, %/lib.a, $(filter %/, $(libs-y))) OK, thanks, I will apply that at some point, since I have already merged your tree. -- Cheers, Stephen Rothwell pgpLgkIcx0mC0.pgp Description: OpenPGP digital signature
Re: [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap
On 2020/6/2 下午9:31, Michael S. Tsirkin wrote:
On Tue, Jun 02, 2020 at 02:49:38PM +0800, Jason Wang wrote:
On 2020/6/2 下午12:56, Michael S. Tsirkin wrote:
On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote:
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on vhost/linux-next]
[also build test ERROR on linus/master v5.7 next-20200529]
[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 seehttps://stackoverflow.com/a/37406982]
url:https://github.com/0day-ci/linux/commits/Jason-Wang/vDPA-doorbell-mapping/20200531-070834
base:https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: m68k-randconfig-r011-20200601 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wgethttps://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
drivers/vhost/vdpa.c: In function 'vhost_vdpa_fault':
drivers/vhost/vdpa.c:754:22: error: implicit declaration of function
'pgprot_noncached' [-Werror=implicit-function-declaration]
754 | vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
| ^~~~
drivers/vhost/vdpa.c:754:22: error: incompatible types when assigning to type
'pgprot_t' {aka 'struct '} from type 'int'
cc1: some warnings being treated as errors
vim +/pgprot_noncached +754 drivers/vhost/vdpa.c
742
743static vm_fault_t vhost_vdpa_fault(struct vm_fault *vmf)
744{
745struct vhost_vdpa *v = vmf->vma->vm_file->private_data;
746struct vdpa_device *vdpa = v->vdpa;
747const struct vdpa_config_ops *ops = vdpa->config;
748struct vdpa_notification_area notify;
749struct vm_area_struct *vma = vmf->vma;
750u16 index = vma->vm_pgoff;
751
752notify = ops->get_vq_notification(vdpa, index);
753
> 754 vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
755if (remap_pfn_range(vma, vmf->address & PAGE_MASK,
756notify.addr >> PAGE_SHIFT,
PAGE_SIZE,
757vma->vm_page_prot))
758return VM_FAULT_SIGBUS;
759
760return VM_FAULT_NOPAGE;
761}
762
Yes well, all this remapping clearly has no chance to work
on systems without CONFIG_MMU.
It looks to me mmap can work according to Documentation/nommu-mmap.txt. But
I'm not sure it's worth to bother.
Thanks
Well
int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t prot)
{
if (addr != (pfn << PAGE_SHIFT))
return -EINVAL;
vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
return 0;
}
EXPORT_SYMBOL(remap_pfn_range);
So things aren't going to work if you have a fixed PFN
which is the case of the hardware device.
Looking at the implementation of some drivers e.g mtd_char. If I read
the code correctly, we can do this by providing get_unmapped_area method
and use physical address directly.
But start form CONFIG_MMU should be fine. Do you prefer making
vhost_vdpa depends on CONFIG_MMU or just fail mmap when CONFIG_MMU is
not configured?
Thanks
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote: > > How widely do you hope to stretch the user_access areas, anyway? > > > To have best performance for small packets like 64B, if possible, we want to > disable STAC not only for the metadata access done by vhost accessors but > also the data access via iov iterator. If you want to try and convince Linus to go for that, make sure to Cc me on that thread. Always liked quality flame... The same goes for interval tree lookups with uaccess allowed. IOW, I _really_ doubt that it's a good idea. > > Incidentally, who had come up with the name __vhost_get_user? > > Makes for lovey WTF moment for readers - esp. in vhost_put_user()... > > > I think the confusion comes since it does not accept userspace pointer (when > IOTLB is enabled). > > How about renaming it as vhost_read()/vhost_write() ? Huh? __vhost_get_user() is IOTLB remapping of userland pointer. It does not access userland memory. Neither for read, nor for write. It is used by vhost_get_user() and vhost_put_user(). Why would you want to rename it into vhost_read _or_ vhost_write, and in any case, how do you give one function two names? IDGI...
Re: [PATCH 1/4] dma-mapping: move the remaining DMA API calls out of line
On 09/05/2020 18:19, Christoph Hellwig wrote: > On Tue, May 05, 2020 at 02:18:37PM +1000, Alexey Kardashevskiy wrote: >> >> >> On 17/04/2020 17:58, Christoph Hellwig wrote: >>> On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote: And the fact they were exported leaves possibility that there is a driver somewhere relying on these symbols or distro kernel won't build because the symbol disappeared from exports (I do not know what KABI guarantees or if mainline kernel cares). >>> >>> We absolutely do not care. In fact for abuses of APIs that drivers >>> should not use we almost care to make them private and break people >>> abusing them. >> >> ok :) >> I do not care in particular but some might, a line separated with empty lines in the commit log would do. >>> >>> I'll add a blurb for the next version. >> >> >> Has it gone anywhere? Thanks, > > I've been hoping for the sg_buf helpers to land first, as they need > backporting and would conflict. Do you urgently need the series? Any progress with sg_buf helpers stuff? Thanks, -- Alexey
ARCH=arm64 build breakage for Kbuild for-next branch
Hi Stephen, If you pull the latest kbuild for-next branch, ARCH=arm64 will fail to build. I will fix it soon. For today's linux-next, you can patch as follows. (or, you can use the old branch) diff --git a/Makefile b/Makefile index f80c4ff93ec9..fbb4b95ae648 100644 --- a/Makefile +++ b/Makefile @@ -1074,7 +1074,7 @@ build-dirs:= $(vmlinux-dirs) clean-dirs := $(vmlinux-alldirs) # Externally visible symbols (used by link-vmlinux.sh) -KBUILD_VMLINUX_OBJS := $(head-y) $(addsuffix built-in.a, $(core-y)) +KBUILD_VMLINUX_OBJS := $(head-y) $(patsubst %/,%/built-in.a, $(core-y)) KBUILD_VMLINUX_OBJS += $(addsuffix built-in.a, $(filter %/, $(libs-y))) ifdef CONFIG_MODULES KBUILD_VMLINUX_OBJS += $(patsubst %/, %/lib.a, $(filter %/, $(libs-y))) Thanks. -- Best Regards Masahiro Yamada
Re: [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor
Hi Andrew-sh.Cheng, On 6/2/20 9:23 PM, andrew-sh.cheng wrote: > On Thu, 2020-05-28 at 16:17 +0900, Chanwoo Choi wrote: >> Hi Andrew-sh.Cheng, >> >> The exynos-bus.c used the passive governor. >> Even if don't make the problem because DEVFREQ_PARENT_DEV is zero, >> you need to initialize the parent_type with DEVFREQ_PARENT_DEV as following: >> >> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c >> index 8fa8eb541373..1c71c47bc2ac 100644 >> --- a/drivers/devfreq/exynos-bus.c >> +++ b/drivers/devfreq/exynos-bus.c >> @@ -369,6 +369,7 @@ static int exynos_bus_profile_init_passive(struct >> exynos_bus *bus, >> return -ENOMEM; >> >> passive_data->parent = parent_devfreq; >> + passive_data->parent_type = DEVFREQ_PARENT_DEV; >> >> /* Add devfreq device for exynos bus with passive governor */ >> bus->devfreq = devm_devfreq_add_device(dev, profile, >> DEVFREQ_GOV_PASSIVE, > Hi Chanwoo Choi, > Do you just remind me to initialize it to DEVFREQ_PARENT_DEV whn use > this governor? Yes. This change was not included in this patchset. > I will do it and thank you for reminding. Thanks. (snip) And, this patchset doesn't include the dt-binding example and any real example in devicetree. If possible, I recommend you better to update dt-binding document with example. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v5 00/10] workingset protection/detection on the anonymous LRU list
On Wed, Apr 8, 2020 at 5:50 PM Joonsoo Kim wrote: > > 2020년 4월 9일 (목) 오전 1:55, Vlastimil Babka 님이 작성: > > > > On 4/3/20 7:40 AM, js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > > > Hello, > > > > > > This patchset implements workingset protection and detection on > > > the anonymous LRU list. > > > > Hi! > > Hi! > > > > I did another test to show the performance effect of this patchset. > > > > > > - ebizzy (with modified random function) > > > ebizzy is the test program that main thread allocates lots of memory and > > > child threads access them randomly during the given times. Swap-in/out > > > will happen if allocated memory is larger than the system memory. > > > > > > The random function that represents the zipf distribution is used to > > > make hot/cold memory. Hot/cold ratio is controlled by the parameter. If > > > the parameter is high, hot memory is accessed much larger than cold one. > > > If the parameter is low, the number of access on each memory would be > > > similar. I uses various parameters in order to show the effect of > > > patchset on various hot/cold ratio workload. > > > > > > My test setup is a virtual machine with 8 cpus and 1024MB memory. > > > > > > Result format is as following. > > > > > > Parameter 0.1 ... 1.3 > > > Allocated memory size > > > Throughput for base (larger is better) > > > Throughput for patchset (larger is better) > > > Improvement (larger is better) > > > > > > > > > * single thread > > > > > > 0.1 0.3 0.5 0.7 0.9 1.1 1.3 > > > <512M> > > > 7009.0 7372.0 7774.0 8523.0 9569.0 10724.0 11936.0 > > > 6973.0 7342.0 7745.0 8576.0 9441.0 10730.0 12033.0 > > >-0.01 -0.0 -0.0 0.01-0.01 0.0 0.01 > > > <768M> > > >915.0 1039.0 1275.0 1687.0 2328.0 3486.0 5445.0 > > >920.0 1037.0 1238.0 1689.0 2384.0 3638.0 5381.0 > > > 0.01 -0.0-0.03 0.0 0.02 0.04-0.01 > > > <1024M> > > >425.0471.0539.0753.0 1183.0 2130.0 3839.0 > > >414.0468.0553.0770.0 1242.0 2187.0 3932.0 > > >-0.03-0.01 0.03 0.02 0.05 0.03 0.02 > > > <1280M> > > >320.0346.0410.0556.0871.0 1654.0 3298.0 > > >316.0346.0411.0550.0892.0 1652.0 3293.0 > > >-0.01 0.0 0.0-0.01 0.02 -0.0 -0.0 > > > <1536M> > > >273.0290.0341.0458.0733.0 1381.0 2925.0 > > >271.0293.0344.0462.0740.0 1398.0 2969.0 > > >-0.01 0.01 0.01 0.01 0.01 0.01 0.02 > > > <2048M> > > > 77.0 79.0 95.0147.0276.0690.0 1816.0 > > > 91.0 94.0115.0170.0321.0770.0 2018.0 > > > 0.18 0.19 0.21 0.16 0.16 0.12 0.11 > > > > > > > > > * multi thread (8) > > > > > > 0.1 0.3 0.5 0.7 0.9 1.1 1.3 > > > <512M> > > > 29083.0 29648.0 30145.0 31668.0 33964.0 38414.0 43707.0 > > > 29238.0 29701.0 30301.0 31328.0 33809.0 37991.0 43667.0 > > > 0.01 0.0 0.01-0.01 -0.0-0.01 -0.0 > > > <768M> > > > 3332.0 3699.0 4673.0 5830.0 8307.0 12969.0 17665.0 > > > 3579.0 3992.0 4432.0 6111.0 8699.0 12604.0 18061.0 > > > 0.07 0.08-0.05 0.05 0.05-0.03 0.02 > > > <1024M> > > > 1921.0 2141.0 2484.0 3296.0 5391.0 8227.0 14574.0 > > > 1989.0 2155.0 2609.0 3565.0 5463.0 8170.0 15642.0 > > > 0.04 0.01 0.05 0.08 0.01-0.01 0.07 > > > <1280M> > > > 1524.0 1625.0 1931.0 2581.0 4155.0 6959.0 12443.0 > > > 1560.0 1707.0 2016.0 2714.0 4262.0 7518.0 13910.0 > > > 0.02 0.05 0.04 0.05 0.03 0.08 0.12 > > > <1536M> > > > 1303.0 1399.0 1550.0 2137.0 3469.0 6712.0 12944.0 > > > 1356.0 1465.0 1701.0 2237.0 3583.0 6830.0 13580.0 > > > 0.04 0.05 0.1 0.05 0.03 0.02 0.05 > > > <2048M> > > >172.0184.0215.0289.0514.0 1318.0 4153.0 > > >175.0190.0225.0329.0606.0 1585.0 5170.0 > > > 0.02 0.03 0.05 0.14 0.18 0.2 0.24 > > > > > > As we can see, as allocated memory grows, patched kernel get the better > > > result. Maximum improvement is 21% for the single thread test and > > > 24% for the multi thread test. > > > > So, these results seem to be identical since v1. After the various changes > > up to > > v5, should the benchmark be redone? And was that with a full patchset or > > patches 1+2? > > It was done with a full patchset. I think that these results would not > be changed > even on v5 since it is improvement from the concept of this patchset and > implementation detail doesn't much matter. However, I will redo. > > > > * EXPERIMENT > > > I made a test program to imitates above scenario and
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On 2020/6/3 上午9:48, Al Viro wrote: On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote: So vhost needs to poke at userspace *a lot* in a quick succession. It is thus benefitial to enable userspace access, do our thing, then disable. Except access_ok has already been pre-validated with all the relevant nospec checks, so we don't need that. Add an API to allow userspace access after access_ok and barrier_nospec are done. BTW, what are you going to do about vq->iotlb != NULL case? Because you sure as hell do *NOT* want e.g. translate_desc() under STAC. Disable it around the calls of translate_desc()? translate_desc() itself doesn't do userspace access, so the idea is probably disabling STAC around a batch of vhost_get_uesr()/vhost_put_user(). How widely do you hope to stretch the user_access areas, anyway? To have best performance for small packets like 64B, if possible, we want to disable STAC not only for the metadata access done by vhost accessors but also the data access via iov iterator. BTW, speaking of possible annotations: looks like there's a large subset of call graph that can be reached only from vhost_worker() or from several ioctls, with all uaccess limited to that subgraph (thankfully). Having that explicitly marked might be a good idea... Unrelated question, while we are at it: is there any point having vhost_get_user() a polymorphic macro? In all callers the third argument is __virtio16 __user * and the second one is an explicit * where is __virtio16 *. Similar for vhost_put_user(): in all callers the third arugment is __virtio16 __user * and the second - cpu_to_vhost16(vq, something). This is because all virtqueue metadata that needs to be accessed atomically is __virtio16 now, but this may not be true for future virtio extension. Incidentally, who had come up with the name __vhost_get_user? Makes for lovey WTF moment for readers - esp. in vhost_put_user()... I think the confusion comes since it does not accept userspace pointer (when IOTLB is enabled). How about renaming it as vhost_read()/vhost_write() ? Thanks
Re: [PATCH 06/12] PM / devfreq: Add cpu based scaling support to passive_governor
Hi Andrew-sh.Cheng,
Do you know that why cannot show the patches sent from you on mailing list?
Even if you sent them to linux-pm mailing list, I cannot find
your patches on linux-pm's patchwork[1] and others.
[1] https://patchwork.kernel.org/project/linux-pm/list/
Could you find you patch on mailing list?
Do you use git send-email when you send these patches?
I used the thunderbird tool and gmail for reading the patches.
When I tried to read the original source of this patch,
it looks like that the body of patch is encoded.
I cannot read the plain text of patch body.
- When gmail, use 'Show original'
- When thunderbird, use 'More -> View Source'
If I'm missing something to check this patch,
please let me know. I'll fix my environment.
It is strange situation on my case.
On 6/2/20 8:43 PM, andrew-sh.cheng wrote:
> On Thu, 2020-05-28 at 15:14 +0900, Chanwoo Choi wrote:
>> Hi Andrew-sh.Cheng,
>>
>> Thanks for your posting. I like this approach absolutely.
>> I think that it is necessary. When I developed the embedded product,
>> I needed this feature always.
>>
>> I add the comments on below.
>>
>>
>> And the following email is not valid. So, I dropped this email
>> from Cc list.
>> Saravana Kannan
>>
>>
>> On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote:
>>> From: Saravana Kannan
>>>
>>> Many CPU architectures have caches that can scale independent of the
>>> CPUs. Frequency scaling of the caches is necessary to make sure that the
>>> cache is not a performance bottleneck that leads to poor performance and
>>> power. The same idea applies for RAM/DDR.
>>>
>>> To achieve this, this patch adds support for cpu based scaling to the
>>> passive governor. This is accomplished by taking the current frequency
>>> of each CPU frequency domain and then adjust the frequency of the cache
>>> (or any devfreq device) based on the frequency of the CPUs. It listens
>>> to CPU frequency transition notifiers to keep itself up to date on the
>>> current CPU frequency.
>>>
>>> To decide the frequency of the device, the governor does one of the
>>> following:
>>> * Derives the optimal devfreq device opp from required-opps property of
>>> the parent cpu opp_table.
>>>
>>> * Scales the device frequency in proportion to the CPU frequency. So, if
>>> the CPUs are running at their max frequency, the device runs at its
>>> max frequency. If the CPUs are running at their min frequency, the
>>> device runs at its min frequency. It is interpolated for frequencies
>>> in between.
>>>
>>> Andrew-sh.Cheng change
>>> dev_pm_opp_xlate_opp to dev_pm_opp_xlate_required_opp devfreq->max_freq
>>> to devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value
>>> for kernel-5.7
>>>
>>> Signed-off-by: Saravana Kannan
>>> [Sibi: Integrated cpu-freqmap governor into passive_governor]
>>> Signed-off-by: Sibi Sankar
>>> Signed-off-by: Andrew-sh.Cheng
>>> ---
>>> drivers/devfreq/Kconfig| 2 +
>>> drivers/devfreq/governor_passive.c | 278
>>> ++---
>>> include/linux/devfreq.h| 40 +-
>>> 3 files changed, 299 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>>> index 0b1df12e0f21..d9067950af6a 100644
>>> --- a/drivers/devfreq/Kconfig
>>> +++ b/drivers/devfreq/Kconfig
>>> @@ -73,6 +73,8 @@ config DEVFREQ_GOV_PASSIVE
>>> device. This governor does not change the frequency by itself
>>> through sysfs entries. The passive governor recommends that
>>> devfreq device uses the OPP table to get the frequency/voltage.
>>> + Alternatively the governor can also be chosen to scale based on
>>> + the online CPUs current frequency.
>>>
>>> comment "DEVFREQ Drivers"
>>>
>>> diff --git a/drivers/devfreq/governor_passive.c
>>> b/drivers/devfreq/governor_passive.c
>>> index 2d67d6c12dce..7dcda02a5bb7 100644
>>> --- a/drivers/devfreq/governor_passive.c
>>> +++ b/drivers/devfreq/governor_passive.c
>>> @@ -8,11 +8,89 @@
>>> */
>>>
>>> #include
>>> +#include
>>> +#include
>>> +#include
>>> #include
>>> #include
>>> +#include
>>> #include "governor.h"
>>>
>>> -static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>> +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data
>>> *data,
>>
>> Need to change 'unsigned int' to 'unsigned long'
> Get it.
If you add the blank line before/after of your reply,
it is better to catch your reply. Please add the blank line for me.
>> .
>>
>>> +unsigned int cpu)
>>> +{
>>> + unsigned int cpu_min, cpu_max, dev_min, dev_max, cpu_percent, max_state;
>>
>> Better to define them separately as following and then need to rename
>> the variable. Usually, use the 'min_freq' and 'max_freq' word for
>> the minimum/maximum frequency.
>>
>> unsigned int cpu_min_freq, cpu_max_freq, cpu_curr_freq, cpu_percent;
>> unsigned long dev_min_freq, dev_max_freq, dev_max_state,
>>
>> The
Re: memory leak in crypto_create_tfm
Probably a bug in crypto/drbg.c. Stephan, can you take a look? On Tue, Jun 02, 2020 at 08:41:21PM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:19409891 Merge tag 'pnp-5.8-rc1' of git://git.kernel.org/p.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=13165aa610 > kernel config: https://syzkaller.appspot.com/x/.config?x=6d41e63a2c7e0715 > dashboard link: https://syzkaller.appspot.com/bug?extid=2e635807decef724a1fa > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17f00ef210 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=170f2ef210 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+2e635807decef724a...@syzkaller.appspotmail.com > > executing program > executing program > BUG: memory leak > unreferenced object 0x8881175bc480 (size 64): > comm "syz-executor064", pid 6388, jiffies 4294941622 (age 13.280s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0 7e 56 84 ff ff ff ff 00 00 00 00 00 00 00 00 .~V. > backtrace: > [<29c7602f>] kmalloc include/linux/slab.h:560 [inline] > [<29c7602f>] kzalloc include/linux/slab.h:669 [inline] > [<29c7602f>] crypto_create_tfm+0x31/0x100 crypto/api.c:448 > [] crypto_alloc_tfm+0x79/0x1a0 crypto/api.c:527 > [<2f9791ba>] drbg_prepare_hrng crypto/drbg.c:1509 [inline] > [<2f9791ba>] drbg_instantiate crypto/drbg.c:1587 [inline] > [<2f9791ba>] drbg_kcapi_seed+0x432/0x6a9 crypto/drbg.c:1980 > [<41302bb8>] crypto_rng_reset+0x35/0x1a0 crypto/rng.c:53 > [<4758c3c4>] alg_setkey crypto/af_alg.c:222 [inline] > [<4758c3c4>] alg_setsockopt+0x149/0x190 crypto/af_alg.c:255 > [<8bc4b5cb>] __sys_setsockopt+0x112/0x230 net/socket.c:2132 > [ ] __do_sys_setsockopt net/socket.c:2148 [inline] > [ ] __se_sys_setsockopt net/socket.c:2145 [inline] > [ ] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2145 > [ ] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295 > [<40e080a1>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0x8881175bc040 (size 64): > comm "syz-executor064", pid 6389, jiffies 4294942172 (age 7.780s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0 7e 56 84 ff ff ff ff 00 00 00 00 00 00 00 00 .~V. > backtrace: > [<29c7602f>] kmalloc include/linux/slab.h:560 [inline] > [<29c7602f>] kzalloc include/linux/slab.h:669 [inline] > [<29c7602f>] crypto_create_tfm+0x31/0x100 crypto/api.c:448 > [ ] crypto_alloc_tfm+0x79/0x1a0 crypto/api.c:527 > [<2f9791ba>] drbg_prepare_hrng crypto/drbg.c:1509 [inline] > [<2f9791ba>] drbg_instantiate crypto/drbg.c:1587 [inline] > [<2f9791ba>] drbg_kcapi_seed+0x432/0x6a9 crypto/drbg.c:1980 > [<41302bb8>] crypto_rng_reset+0x35/0x1a0 crypto/rng.c:53 > [<4758c3c4>] alg_setkey crypto/af_alg.c:222 [inline] > [<4758c3c4>] alg_setsockopt+0x149/0x190 crypto/af_alg.c:255 > [<8bc4b5cb>] __sys_setsockopt+0x112/0x230 net/socket.c:2132 > [ ] __do_sys_setsockopt net/socket.c:2148 [inline] > [ ] __se_sys_setsockopt net/socket.c:2145 [inline] > [ ] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2145 > [ ] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295 > [<40e080a1>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0x88811b3ca080 (size 96): > comm "syz-executor064", pid 6389, jiffies 4294942172 (age 7.780s) > hex dump (first 32 bytes): > 89 c7 08 cb 8a 12 10 6e 00 00 00 00 00 00 00 00 ...n > 71 51 5a c2 1b 00 00 00 35 7d 00 00 00 00 00 00 qQZ.5}.. > backtrace: > [<8ec3eca0>] jent_entropy_collector_alloc+0x1b/0xf8 > crypto/jitterentropy.c:662 > [<26ed401a>] jent_kcapi_init+0x17/0x40 > crypto/jitterentropy-kcapi.c:119 > [ ] crypto_create_tfm+0x89/0x100 crypto/api.c:459 > [ ] crypto_alloc_tfm+0x79/0x1a0 crypto/api.c:527 > [<2f9791ba>] drbg_prepare_hrng crypto/drbg.c:1509 [inline] > [<2f9791ba>] drbg_instantiate crypto/drbg.c:1587 [inline] > [<2f9791ba>] drbg_kcapi_seed+0x432/0x6a9 crypto/drbg.c:1980 > [<41302bb8>] crypto_rng_reset+0x35/0x1a0 crypto/rng.c:53 > [<4758c3c4>] alg_setkey crypto/af_alg.c:222 [inline] > [<4758c3c4>] alg_setsockopt+0x149/0x190 crypto/af_alg.c:255 >
Re: [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration
On Tue, 2 Jun 2020 23:19:48 -0400 Yan Zhao wrote: > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote: > > On Wed, 29 Apr 2020 20:39:50 -0400 > > Yan Zhao wrote: > > > > > On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote: > > > > > > > > > > > > > > > > > > > An mdev type is meant to define a software > > > > > > > > > > > > > > > > compatible interface, so in > > > > > > > > > > > > > > > > the case of mdev->mdev migration, doesn't > > > > > > > > > > > > > > > > migrating to a different type > > > > > > > > > > > > > > > > fail the most basic of compatibility tests that > > > > > > > > > > > > > > > > we expect userspace to > > > > > > > > > > > > > > > > perform? IOW, if two mdev types are migration > > > > > > > > > > > > > > > > compatible, it seems a > > > > > > > > > > > > > > > > prerequisite to that is that they provide the > > > > > > > > > > > > > > > > same software interface, > > > > > > > > > > > > > > > > which means they should be the same mdev type. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the hybrid cases of mdev->phys or > > > > > > > > > > > > > > > > phys->mdev, how does a > > > > > > > > > > > > > > > management > > > > > > > > > > > > > > > > tool begin to even guess what might be > > > > > > > > > > > > > > > > compatible? Are we expecting > > > > > > > > > > > > > > > > libvirt to probe ever device with this > > > > > > > > > > > > > > > > attribute in the system? Is > > > > > > > > > > > > > > > > there going to be a new class hierarchy created > > > > > > > > > > > > > > > > to enumerate all > > > > > > > > > > > > > > > > possible migrate-able devices? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yes, management tool needs to guess and test > > > > > > > > > > > > > > > migration compatible > > > > > > > > > > > > > > > between two devices. But I think it's not the > > > > > > > > > > > > > > > problem only for > > > > > > > > > > > > > > > mdev->phys or phys->mdev. even for mdev->mdev, > > > > > > > > > > > > > > > management tool needs > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > first assume that the two mdevs have the same > > > > > > > > > > > > > > > type of parent devices > > > > > > > > > > > > > > > (e.g.their pciids are equal). otherwise, it's > > > > > > > > > > > > > > > still enumerating > > > > > > > > > > > > > > > possibilities. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > on the other hand, for two mdevs, > > > > > > > > > > > > > > > mdev1 from pdev1, its mdev_type is 1/2 of pdev1; > > > > > > > > > > > > > > > mdev2 from pdev2, its mdev_type is 1/4 of pdev2; > > > > > > > > > > > > > > > if pdev2 is exactly 2 times of pdev1, why not > > > > > > > > > > > > > > > allow migration between > > > > > > > > > > > > > > > mdev1 <-> mdev2. > > > > > > > > > > > > > > > > > > > > > > > > > > > > How could the manage tool figure out that 1/2 of > > > > > > > > > > > > > > pdev1 is equivalent > > > > > > > > > > > > > > to 1/4 of pdev2? If we really want to allow such > > > > > > > > > > > > > > thing happen, the best > > > > > > > > > > > > > > choice is to report the same mdev type on both > > > > > > > > > > > > > > pdev1 and pdev2. > > > > > > > > > > > > > I think that's exactly the value of this > > > > > > > > > > > > > migration_version interface. > > > > > > > > > > > > > the management tool can take advantage of this > > > > > > > > > > > > > interface to know if two > > > > > > > > > > > > > devices are migration compatible, no matter they are > > > > > > > > > > > > > mdevs, non-mdevs, > > > > > > > > > > > > > or mix. > > > > > > > > > > > > > > > > > > > > > > > > > > as I know, (please correct me if not right), current > > > > > > > > > > > > > libvirt still > > > > > > > > > > > > > requires manually generating mdev devices, and it > > > > > > > > > > > > > just duplicates src vm > > > > > > > > > > > > > configuration to the target vm. > > > > > > > > > > > > > for libvirt, currently it's always phys->phys and > > > > > > > > > > > > > mdev->mdev (and of the > > > > > > > > > > > > > same mdev type). > > > > > > > > > > > > > But it does not justify that hybrid cases should not > > > > > > > > > > > > > be allowed. otherwise, > > > > > > > > > > > > > why do we need to introduce this migration_version > > > > > > > > > > > > > interface and leave > > > > > > > > > > > > > the judgement of migration compatibility to vendor > > > > > > > > > > > > > driver? why not simply > > > > > > > > > > > > > set the criteria to something like "pciids of parent > > > > > > > > > > > > > devices are equal, > > > > > > > > > > > > > and mdev types are equal" ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > btw mdev<->phys just brings trouble to upper stack > > > > > > > > > > > > > > as Alex pointed out. > > > > > > > > > > > > > could you help me
Re: [PATCH] xfs/XXX: Add xfs/XXX
On Wed, Jun 03, 2020 at 09:56:13AM +0800, Xiao Yang wrote:
> On 2020/6/3 2:14, Darrick J. Wong wrote:
> > On Tue, Jun 02, 2020 at 04:51:48PM +0800, Xiao Yang wrote:
> > > On 2020/4/14 0:30, Darrick J. Wong wrote:
> > > > This might be a good time to introduce a few new helpers:
> > > >
> > > > _require_scratch_dax ("Does $SCRATCH_DEV support DAX?")
> > > > _require_scratch_dax_mountopt ("Does the fs support the DAX mount
> > > > options?")
> > > > _require_scratch_daX_iflag ("Does the fs support FS_XFLAG_DAX?")
> > > Hi Darrick,
> > >
> > > Now, I am trying to introduce these new helpers and have some questions:
> > > 1) There are five testcases related to old dax implementation, should we
> > > only convert them to new dax implementation or make them compatible with
> > > old
> > > and new dax implementation?
> >
> > What is the 'old' DAX implementation? ext2 XIP?
> Hi Darrick,
>
> Thanks for your quick feedback.
>
> Right, the 'old' DAX implementation means old dax mount option(i.e. -o dax)
>
> Compare new and old dax mount option on ext4 and xfs, is the following logic
> right?
> -o dax=always == -o dax
> -o dax=never == without dax
> -o dax=inode == nothing
No. -o dax=always is the same as -o dax.
dax=inode was and still is the behavior you got with no option at all.
-o dax=never is a new option.
> Of course, we should uses new option if ext4/xfs supports new dax mount
> option on distros. But should we fallback to use old option if ext4/xfs
> doesn't support new dax mount option on some old distros?
> btw:
> it seems hard for testcases to use two different sets of mount options(i.e.
> old and new) so do you have any suggestion?
Try dax=never, it should work on any type of storage device if the
kernel implements the "new" mount options at all.
--D
> >
> > > 2) I think _require_xfs_io_command "chattr" "x" is enough to check if fs
> > > supports FS_XFLAG_DAX. Is it necessary to add
> > > _require_scratch_dax_iflag()?
> > > like this:
> > > _require_scratch_dax_iflag()
> > > {
> > > _require_xfs_io_command "chattr" "x"
> > > }
> >
> > I suggested that list based on the major control knobs that will be
> > visible to userspace programs. Even if this is just a one-line helper,
> > its name is useful for recognizing which of those knobs we're looking
> > for.
> >
> > Yes, you could probably save a trivial amount of time by skipping one
> > iteration of bash function calling, but now everyone has to remember
> > that the xfs_io chattr "x" flag means the dax inode flag, and not
> > confuse it for chmod +x or something else.
>
> Got it, thanks for your detailed explanation.
>
> Best Regards,
> Xiao Yang
> >
> > --D
> >
> > > Best Regards,
> > > Xiao Yang
> > >
> > >
> >
> >
> > .
> >
>
>
>
Re: [GIT PULL] vfs: improve DAX behavior for 5.8, part 2
The pull request you sent on Tue, 2 Jun 2020 10:25:50 -0700: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/vfs-5.8-merge-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8eeae5bae1239c030ba0b34cac97ebd5e7ec1886 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] erofs updates for 5.8-rc1
The pull request you sent on Wed, 3 Jun 2020 09:21:37 +0800: > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git > tags/erofs-for-5.8-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d6f9469a03d832dcd17041ed67774ffb5f3e73b3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] JFS fix for v5.8
The pull request you sent on Tue, 2 Jun 2020 10:22:02 -0500: > git://github.com/kleikamp/linux-shaggy.git tags/jfs-5.8 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cadf32234b6f6dd96a0892bf915e3ee8c438cf07 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Btrfs updates for 5.8
The pull request you sent on Mon, 1 Jun 2020 14:37:21 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.8-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f3cdc8ae116e27d84e1f33c7a2995960cebb73ac Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] xfs: new code for 5.8
The pull request you sent on Tue, 2 Jun 2020 09:09:08 -0700: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.8-merge-8 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/16d91548d1057691979de4686693f0ff92f46000 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH 2/3] ASoC: fsl_easrc: Fix -Wunused-but-set-variable
Obtained with:
$ make W=1
sound/soc/fsl/fsl_easrc.c: In function 'fsl_easrc_set_rs_ratio':
sound/soc/fsl/fsl_easrc.c:182:15: warning: variable 'int_bits' set but not used
[-Wunused-but-set-variable]
unsigned int int_bits;
^
sound/soc/fsl/fsl_easrc.c: In function 'fsl_easrc_set_ctx_organziation':
sound/soc/fsl/fsl_easrc.c:1204:17: warning: variable 'dev' set but not used
[-Wunused-but-set-variable]
struct device *dev;
^
sound/soc/fsl/fsl_easrc.c: In function 'fsl_easrc_release_context':
sound/soc/fsl/fsl_easrc.c:1294:17: warning: variable 'dev' set but not used
[-Wunused-but-set-variable]
struct device *dev;
^
Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
Signed-off-by: Shengjiu Wang
Reported-by: kbuild test robot
---
sound/soc/fsl/fsl_easrc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index f227308a50e2..7d8bf9d47842 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -179,22 +179,21 @@ static int fsl_easrc_set_rs_ratio(struct fsl_asrc_pair
*ctx)
struct fsl_easrc_ctx_priv *ctx_priv = ctx->private;
unsigned int in_rate = ctx_priv->in_params.norm_rate;
unsigned int out_rate = ctx_priv->out_params.norm_rate;
- unsigned int int_bits;
unsigned int frac_bits;
u64 val;
u32 *r;
switch (easrc_priv->rs_num_taps) {
case EASRC_RS_32_TAPS:
- int_bits = 5;
+ /* integer bits = 5; */
frac_bits = 39;
break;
case EASRC_RS_64_TAPS:
- int_bits = 6;
+ /* integer bits = 6; */
frac_bits = 38;
break;
case EASRC_RS_128_TAPS:
- int_bits = 7;
+ /* integer bits = 7; */
frac_bits = 37;
break;
default:
@@ -1201,7 +1200,6 @@ static int fsl_easrc_set_ctx_format(struct fsl_asrc_pair
*ctx,
static int fsl_easrc_set_ctx_organziation(struct fsl_asrc_pair *ctx)
{
struct fsl_easrc_ctx_priv *ctx_priv;
- struct device *dev;
struct fsl_asrc *easrc;
if (!ctx)
@@ -1209,7 +1207,6 @@ static int fsl_easrc_set_ctx_organziation(struct
fsl_asrc_pair *ctx)
easrc = ctx->asrc;
ctx_priv = ctx->private;
- dev = >pdev->dev;
/* input interleaving parameters */
regmap_update_bits(easrc->regmap, REG_EASRC_CIA(ctx->index),
@@ -1291,13 +1288,11 @@ static void fsl_easrc_release_context(struct
fsl_asrc_pair *ctx)
{
unsigned long lock_flags;
struct fsl_asrc *easrc;
- struct device *dev;
if (!ctx)
return;
easrc = ctx->asrc;
- dev = >pdev->dev;
spin_lock_irqsave(>lock, lock_flags);
--
2.21.0
[PATCH 0/3] ASoC: fsl_easrc: Fix several warnings
Fix several warnings with "make W=1" Shengjiu Wang (3): ASoC: fsl_easrc: Fix -Wmissing-prototypes warning ASoC: fsl_easrc: Fix -Wunused-but-set-variable ASoC: fsl_easrc: Fix "Function parameter not described" warnings sound/soc/fsl/fsl_easrc.c | 42 +-- 1 file changed, 18 insertions(+), 24 deletions(-) -- 2.21.0
Re: [GIT PULL] vfs: improve DAX behavior for 5.8, part 1
The pull request you sent on Tue, 2 Jun 2020 09:58:52 -0700: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/vfs-5.8-merge-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/dae2f8ed7992e88c8d62c54e8295ffc8475b4a80 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH 1/3] ASoC: fsl_easrc: Fix -Wmissing-prototypes warning
Obtained with:
$ make W=1
sound/soc/fsl/fsl_easrc.c:967:5: warning: no previous prototype for function
'fsl_easrc_config_context' [-Wmissing-prototypes]
int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id)
^
sound/soc/fsl/fsl_easrc.c:967:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id)
^
static
sound/soc/fsl/fsl_easrc.c:1128:5: warning: no previous prototype for function
'fsl_easrc_set_ctx_format' [-Wmissing-prototypes]
int fsl_easrc_set_ctx_format(struct fsl_asrc_pair *ctx,
^
sound/soc/fsl/fsl_easrc.c:1128:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
int fsl_easrc_set_ctx_format(struct fsl_asrc_pair *ctx,
^
static
sound/soc/fsl/fsl_easrc.c:1201:5: warning: no previous prototype for function
'fsl_easrc_set_ctx_organziation' [-Wmissing-prototypes]
int fsl_easrc_set_ctx_organziation(struct fsl_asrc_pair *ctx)
^
sound/soc/fsl/fsl_easrc.c:1201:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
int fsl_easrc_set_ctx_organziation(struct fsl_asrc_pair *ctx)
^
static
sound/soc/fsl/fsl_easrc.c:1245:5: warning: no previous prototype for function
'fsl_easrc_request_context' [-Wmissing-prototypes]
int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx)
^
sound/soc/fsl/fsl_easrc.c:1245:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx)
^
static
sound/soc/fsl/fsl_easrc.c:1290:6: warning: no previous prototype for function
'fsl_easrc_release_context' [-Wmissing-prototypes]
void fsl_easrc_release_context(struct fsl_asrc_pair *ctx)
^
sound/soc/fsl/fsl_easrc.c:1290:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
void fsl_easrc_release_context(struct fsl_asrc_pair *ctx)
^
static
sound/soc/fsl/fsl_easrc.c:1317:5: warning: no previous prototype for function
'fsl_easrc_start_context' [-Wmissing-prototypes]
int fsl_easrc_start_context(struct fsl_asrc_pair *ctx)
^
sound/soc/fsl/fsl_easrc.c:1317:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
int fsl_easrc_start_context(struct fsl_asrc_pair *ctx)
^
static
sound/soc/fsl/fsl_easrc.c:1335:5: warning: no previous prototype for function
'fsl_easrc_stop_context' [-Wmissing-prototypes]
int fsl_easrc_stop_context(struct fsl_asrc_pair *ctx)
^
sound/soc/fsl/fsl_easrc.c:1335:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
int fsl_easrc_stop_context(struct fsl_asrc_pair *ctx)
^
static
sound/soc/fsl/fsl_easrc.c:1382:18: warning: no previous prototype for function
'fsl_easrc_get_dma_channel' [-Wmissing-prototypes]
struct dma_chan *fsl_easrc_get_dma_channel(struct fsl_asrc_pair *ctx,
^
sound/soc/fsl/fsl_easrc.c:1382:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
struct dma_chan *fsl_easrc_get_dma_channel(struct fsl_asrc_pair *ctx,
^
static
Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
Signed-off-by: Shengjiu Wang
Reported-by: kbuild test robot
---
sound/soc/fsl/fsl_easrc.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index c6b5eb2d2af7..f227308a50e2 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -964,7 +964,7 @@ static int fsl_easrc_release_slot(struct fsl_asrc *easrc,
unsigned int ctx_id)
*
* Configure the register relate with context.
*/
-int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id)
+static int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int
ctx_id)
{
struct fsl_easrc_ctx_priv *ctx_priv;
struct fsl_asrc_pair *ctx;
@@ -1125,9 +1125,9 @@ static int fsl_easrc_process_format(struct fsl_asrc_pair
*ctx,
return 0;
}
-int fsl_easrc_set_ctx_format(struct fsl_asrc_pair *ctx,
-snd_pcm_format_t *in_raw_format,
-snd_pcm_format_t *out_raw_format)
+static int fsl_easrc_set_ctx_format(struct fsl_asrc_pair *ctx,
+ snd_pcm_format_t *in_raw_format,
+ snd_pcm_format_t *out_raw_format)
{
struct fsl_asrc *easrc = ctx->asrc;
struct fsl_easrc_ctx_priv *ctx_priv = ctx->private;
@@ -1198,7 +1198,7 @@ int fsl_easrc_set_ctx_format(struct fsl_asrc_pair *ctx,
* to conform with this format. Interleaving parameters are accessed
* through the ASRC_CTRL_IN_ACCESSa and ASRC_CTRL_OUT_ACCESSa registers
*/
-int fsl_easrc_set_ctx_organziation(struct fsl_asrc_pair *ctx)
+static int
[PATCH 3/3] ASoC: fsl_easrc: Fix "Function parameter not described" warnings
Obtained with:
$ make W=1
sound/soc/fsl/fsl_easrc.c:403: warning: Function parameter or member 'easrc'
not described in 'fsl_easrc_normalize_filter'
sound/soc/fsl/fsl_easrc.c:403: warning: Function parameter or member 'infilter'
not described in 'fsl_easrc_normalize_filter'
sound/soc/fsl/fsl_easrc.c:403: warning: Function parameter or member
'outfilter' not described in 'fsl_easrc_normalize_filter'
sound/soc/fsl/fsl_easrc.c:403: warning: Function parameter or member 'shift'
not described in 'fsl_easrc_normalize_filter'
Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
Signed-off-by: Shengjiu Wang
Reported-by: kbuild test robot
---
sound/soc/fsl/fsl_easrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index 7d8bf9d47842..2f6b3d8bfcfc 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -389,11 +389,11 @@ static int fsl_easrc_resampler_config(struct fsl_asrc
*easrc)
* For input int[16, 24, 32] -> output float32
* scale it by multiplying filter coefficients by 2^-15, 2^-23, 2^-31
* input:
- * asrc: Structure pointer of fsl_asrc
- * infilter : Pointer to non-scaled input filter
- * shift: The multiply factor
+ * @easrc: Structure pointer of fsl_asrc
+ * @infilter : Pointer to non-scaled input filter
+ * @shift: The multiply factor
* output:
- * outfilter: scaled filter
+ * @outfilter: scaled filter
*/
static int fsl_easrc_normalize_filter(struct fsl_asrc *easrc,
u64 *infilter,
--
2.21.0
[PATCH V4 1/2] arm64: dts: imx8m: add mu node
From: Peng Fan
Add mu node to let A53 could communicate with M Core.
Reviewed-by: Dong Aisheng
Signed-off-by: Peng Fan
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 8
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8
4 files changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index aaf6e71101a1..d9e787ea246f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -775,6 +775,14 @@
status = "disabled";
};
+ mu: mailbox@30aa {
+ compatible = "fsl,imx8mm-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa 0x1>;
+ interrupts = ;
+ clocks = < IMX8MM_CLK_MU_ROOT>;
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mm-usdhc",
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 9a4b65a267d4..3dca1fb34ea3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -675,6 +675,14 @@
status = "disabled";
};
+ mu: mailbox@30aa {
+ compatible = "fsl,imx8mn-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa 0x1>;
+ interrupts = ;
+ clocks = < IMX8MN_CLK_MU_ROOT>;
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mn-usdhc",
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 45e2c0a4e889..1bc14bb44d90 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -621,6 +621,14 @@
status = "disabled";
};
+ mu: mailbox@30aa {
+ compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa 0x1>;
+ interrupts = ;
+ clocks = < IMX8MP_CLK_MU_ROOT>;
+ #mbox-cells = <2>;
+ };
+
i2c5: i2c@30ad {
compatible = "fsl,imx8mp-i2c", "fsl,imx21-i2c";
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 978f8122c0d2..3e762919d61f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -959,6 +959,14 @@
status = "disabled";
};
+ mu: mailbox@30aa {
+ compatible = "fsl,imx8mq-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa 0x1>;
+ interrupts = ;
+ clocks = < IMX8MQ_CLK_MU_ROOT>;
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mq-usdhc",
"fsl,imx7d-usdhc";
--
2.16.4
[PATCH V4 2/2] clk: imx8mp: add mu root clk
From: Peng Fan
Add mu root clk for mu mailbox usage.
Reviewed-by: Dong Aisheng
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-imx8mp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index b4d9db9d5bf1..ca747712400f 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -680,6 +680,7 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)
hws[IMX8MP_CLK_I2C2_ROOT] = imx_clk_hw_gate4("i2c2_root_clk", "i2c2",
ccm_base + 0x4180, 0);
hws[IMX8MP_CLK_I2C3_ROOT] = imx_clk_hw_gate4("i2c3_root_clk", "i2c3",
ccm_base + 0x4190, 0);
hws[IMX8MP_CLK_I2C4_ROOT] = imx_clk_hw_gate4("i2c4_root_clk", "i2c4",
ccm_base + 0x41a0, 0);
+ hws[IMX8MP_CLK_MU_ROOT] = imx_clk_hw_gate4("mu_root_clk", "ipg_root",
ccm_base + 0x4210, 0);
hws[IMX8MP_CLK_OCOTP_ROOT] = imx_clk_hw_gate4("ocotp_root_clk",
"ipg_root", ccm_base + 0x4220, 0);
hws[IMX8MP_CLK_PCIE_ROOT] = imx_clk_hw_gate4("pcie_root_clk",
"pcie_aux", ccm_base + 0x4250, 0);
hws[IMX8MP_CLK_PWM1_ROOT] = imx_clk_hw_gate4("pwm1_root_clk", "pwm1",
ccm_base + 0x4280, 0);
--
2.16.4
[PATCH V4 0/2] imx8m: add mu support
From: Peng Fan V4: Drop patch 1/3, since https://lkml.org/lkml/2020/6/1/370 already has the yaml changes V3: Add R-b tag Remove undocumented property V2: Add dt-bindings Merge dts changes into one patch, since all is to add mu node Add mu dt bindings Add mu node Add i.MX8MP mu root clk Peng Fan (2): arm64: dts: imx8m: add mu node clk: imx8mp: add mu root clk arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 8 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8 drivers/clk/imx/clk-imx8mp.c | 1 + 5 files changed, 33 insertions(+) -- 2.16.4
[ANNOUNCE] iproute2-5.7.0 release
The 5.7 kernel has been released, and the last patches have been applied to iproute2. As usual lots of small fixes, across many utilities. Several qdisc now have more parameters available. Devlink get most of the fixes. Download: https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-5.7.0.tar.gz Repository for upcoming release: git://git.kernel.org/pub/scm/network/iproute2/iproute2.git And future release (net-next): git://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git Thanks for all the contributions. Report problems (or enhancements) to the net...@vger.kernel.org mailing list. Andrea Claudi (2): Revert "bpf: replace snprintf with asprintf when dealing with long buffers" bpf: Fixes a snprintf truncation warning Antoine Tenart (4): macsec: report the offloading mode currently selected macsec: add support for changing the offloading mode man: document the ip macsec offload command macsec: add an accessor for validate_str Bastien Roucariès (6): Better documentation of mcast_to_unicast option Improve hairpin mode description Document BPDU filter option Better documentation of BDPU guard Document root_block option State of bridge STP port are now case insensitive Benjamin Lee (4): man: tc-htb.8: add missing qdisc parameter r2q man: tc-htb.8: add missing class parameter quantum man: tc-htb.8: fix class prio is not mandatory tc: fq_codel: fix class stat deficit is signed int Benjamin Poirier (6): bridge: Use consistent column names in vlan output bridge: Fix typo bridge: Fix output with empty vlan lists json_print: Return number of characters printed bridge: Align output columns Replace open-coded instances of print_nl() Brian Norris (2): man: add ip-netns(8) as generation target man: replace $(NETNS_ETC_DIR) and $(NETNS_RUN_DIR) in ip-netns(8) Danielle Ratson (1): bash-completion: devlink: add bash-completion function David Ahern (4): Update kernel headers Update kernel headers Update kernel headers Update kernel headers Donald Sharp (1): nexthop: Fix Deletion display Eric Dumazet (5): tc: fq_codel: add drop_batch parameter tc: fq: add timer_slack parameter ss: add support for Gbit speeds in sprint_bw() tc: fq: fix two issues utils: remove trailing zeros in print_time() and print_time64() Ido Schimmel (3): devlink: Add devlink trap policer set and show commands devlink: Add ability to bind policer to trap group bash-completion: devlink: Extend bash-completion for new commands Jacob Keller (1): devlink: add support for DEVLINK_CMD_REGION_NEW Jakub Kicinski (1): tc: m_action: rename hw stats type uAPI Jiri Pirko (14): devlink: add trap metadata type for flow action cookie tc: m_action: introduce support for hw stats type tc: show used HW stats types devlink: remove custom bool command line options parsing devlink: Fix help and man of "devlink health set" command devlink: fix encap mode manupulation devlink: Add alias "counters_enabled" for "counters" option devlink: rename dpipe_counters_enable struct field to dpipe_counters_enabled devlink: Fix help message for dpipe devlink: remove "dev" object sub help messages man: add man page for devlink dpipe devlink: remove unused "jw" field devlink: fix JSON output of mon command tc: m_action: check cookie hex string len Leslie Monis (2): tc: pie: change maximum integer value of tc_pie_xstats->prob Revert "tc: pie: change maximum integer value of tc_pie_xstats->prob" Moshe Shemesh (1): devlink: Add health error recovery status monitoring Odin Ugedal (3): tc_util: detect overflow in get_size q_cake: Make fwmark uint instead of int q_cake: properly print memlimit Parav Pandit (1): devlink: Introduce devlink port flavour virtual Paul Blakey (1): man: tc-ct.8: Add manual page for ct tc action Petr Machata (5): tc: q_red: Support 'nodrop' flag tc: p_ip6: Support pedit of IPv6 dsfield man: tc-pedit: Add examples for dsfield and retain man: tc-pedit: Drop the claim that pedit ex is only for IPv4 ip: link_gre: Do not send ERSPAN attributes to GRE tunnels Roman Mashak (1): tc: action: fix time values output in JSON format Stephen Hemminger (7): man/tc-actions: fix formatting bridge: man page spelling fixes uapi: update bpf.h ss: update to bw print uapi: update to bpf.h uapi: fix comment in xfrm.h v5.7.0 Xin Long (1): xfrm: also check for ipv6 state in xfrm_state_keep
[PATCH V2 1/3] firmware: imx: scu-pd: fix cm40 power domain
From: Peng Fan
The postfix needs to be false. Alought compiler use 0 for postfix now,
and take start_from as 0, it is better we add explicit false to postfix.
Fixes: 705dcca91d0a("firmware: imx: scu-pd: add power domain for I2C and INTMUX
in CM40 SS")
Signed-off-by: Peng Fan
Reviewed-by: Dong Aisheng
---
drivers/firmware/imx/scu-pd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index fb5523aa16ee..d1b313fa7b96 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -167,8 +167,8 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[]
= {
{ "dc0-pll", IMX_SC_R_DC_0_PLL_0, 2, true, 0 },
/* CM40 SS */
- { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, 0 },
- { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, 0 },
+ { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
+ { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
};
static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
--
2.16.4
[PATCH V2 2/3] firmware: imx: add resource management api
From: Peng Fan
Add resource management API, when we have multiple
partition running together, resources not owned to current
partition should not be used.
Reviewed-by: Leonard Crestez
Signed-off-by: Peng Fan
---
drivers/firmware/imx/Makefile | 2 +-
drivers/firmware/imx/rm.c | 45
include/linux/firmware/imx/sci.h| 1 +
include/linux/firmware/imx/svc/rm.h | 69 +
4 files changed, 116 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/imx/rm.c
create mode 100644 include/linux/firmware/imx/svc/rm.h
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 08bc9ddfbdfb..17ea3613e142 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_IMX_DSP) += imx-dsp.o
-obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
+obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o
obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c
new file mode 100644
index ..a12db6ff323b
--- /dev/null
+++ b/drivers/firmware/imx/rm.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 NXP
+ *
+ * File containing client-side RPC functions for the RM service. These
+ * function are ported to clients that communicate to the SC.
+ */
+
+#include
+
+struct imx_sc_msg_rm_rsrc_owned {
+ struct imx_sc_rpc_msg hdr;
+ u16 resource;
+} __packed __aligned(4);
+
+/*
+ * This function check @resource is owned by current partition or not
+ *
+ * @param[in] ipc IPC handle
+ * @param[in] resourceresource the control is associated with
+ *
+ * @return Returns 0 for not owned and 1 for owned.
+ */
+bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource)
+{
+ struct imx_sc_msg_rm_rsrc_owned msg;
+ struct imx_sc_rpc_msg *hdr =
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_RM;
+ hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
+ hdr->size = 2;
+
+ msg.resource = resource;
+
+ /*
+* SCU firmware only returns value 0 or 1
+* for resource owned check which means not owned or owned.
+* So it is always successful.
+*/
+ imx_scu_call_rpc(ipc, , true);
+
+ return hdr->func;
+}
+EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
diff --git a/include/linux/firmware/imx/sci.h b/include/linux/firmware/imx/sci.h
index 3fa418a4ca67..3c459f54a88f 100644
--- a/include/linux/firmware/imx/sci.h
+++ b/include/linux/firmware/imx/sci.h
@@ -14,6 +14,7 @@
#include
#include
+#include
int imx_scu_enable_general_irq_channel(struct device *dev);
int imx_scu_irq_register_notifier(struct notifier_block *nb);
diff --git a/include/linux/firmware/imx/svc/rm.h
b/include/linux/firmware/imx/svc/rm.h
new file mode 100644
index ..9924216f3e45
--- /dev/null
+++ b/include/linux/firmware/imx/svc/rm.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2020 NXP
+ *
+ * Header file containing the public API for the System Controller (SC)
+ * Power Management (PM) function. This includes functions for power state
+ * control, clock control, reset control, and wake-up event control.
+ *
+ * RM_SVC (SVC) Resource Management Service
+ *
+ * Module for the Resource Management (RM) service.
+ */
+
+#ifndef _SC_RM_API_H
+#define _SC_RM_API_H
+
+#include
+
+/*
+ * This type is used to indicate RPC RM function calls.
+ */
+enum imx_sc_rm_func {
+ IMX_SC_RM_FUNC_UNKNOWN = 0,
+ IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
+ IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
+ IMX_SC_RM_FUNC_PARTITION_FREE = 2,
+ IMX_SC_RM_FUNC_GET_DID = 26,
+ IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
+ IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
+ IMX_SC_RM_FUNC_GET_PARTITION = 5,
+ IMX_SC_RM_FUNC_SET_PARENT = 6,
+ IMX_SC_RM_FUNC_MOVE_ALL = 7,
+ IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
+ IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
+ IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
+ IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
+ IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
+ IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS = 12,
+ IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
+ IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
+ IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
+ IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
+ IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
+ IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
+ IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
+ IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
+ IMX_SC_RM_FUNC_MEMREG_FREE = 18,
+ IMX_SC_RM_FUNC_FIND_MEMREG = 30,
+ IMX_SC_RM_FUNC_ASSIGN_MEMREG = 19,
+ IMX_SC_RM_FUNC_SET_MEMREG_PERMISSIONS = 20,
+ IMX_SC_RM_FUNC_IS_MEMREG_OWNED =
[PATCH V2 3/3] firmware: imx: scu-pd: add more cm4 resources
From: Peng Fan
Add more cm4 resources, then linux could use cm4's i2c/lpuart and
could kick cm4 core.
Reviewed-by: Dong Aisheng
Signed-off-by: Peng Fan
---
drivers/firmware/imx/scu-pd.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index d1b313fa7b96..af3d6d9ead28 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -167,8 +167,18 @@ static const struct imx_sc_pd_range
imx8qxp_scu_pd_ranges[] = {
{ "dc0-pll", IMX_SC_R_DC_0_PLL_0, 2, true, 0 },
/* CM40 SS */
- { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
- { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
+ { "cm40-i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
+ { "cm40-intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
+ { "cm40-pid", IMX_SC_R_M4_0_PID0, 5, true, 0},
+ { "cm40-mu-a1", IMX_SC_R_M4_0_MU_1A, 1, false, 0},
+ { "cm40-lpuart", IMX_SC_R_M4_0_UART, 1, false, 0},
+
+ /* CM41 SS */
+ { "cm41-i2c", IMX_SC_R_M4_1_I2C, 1, false, 0 },
+ { "cm41-intmux", IMX_SC_R_M4_1_INTMUX, 1, false, 0 },
+ { "cm41-pid", IMX_SC_R_M4_1_PID0, 5, true, 0},
+ { "cm41-mu-a1", IMX_SC_R_M4_1_MU_1A, 1, false, 0},
+ { "cm41-lpuart", IMX_SC_R_M4_1_UART, 1, false, 0},
};
static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
--
2.16.4
[PATCH V2 0/3] firmware: imx: fix/update cm4 and add resource check
From: Peng Fan V2: Add R-b tag Drop patch 3/4 from V1 Add comments and update Copyright for patch 2/3 keep code consistency in Patch 3/3 V1: https://patchwork.kernel.org/cover/11505045/ Fix cm40 power domain, update to add more cm4 resources Add resource owner check, to not register if not owned by Linux. Peng Fan (3): firmware: imx: scu-pd: fix cm40 power domain firmware: imx: add resource management api firmware: imx: scu-pd: add more cm4 resources drivers/firmware/imx/Makefile | 2 +- drivers/firmware/imx/rm.c | 45 drivers/firmware/imx/scu-pd.c | 14 ++-- include/linux/firmware/imx/sci.h| 1 + include/linux/firmware/imx/svc/rm.h | 69 + 5 files changed, 128 insertions(+), 3 deletions(-) create mode 100644 drivers/firmware/imx/rm.c create mode 100644 include/linux/firmware/imx/svc/rm.h -- 2.16.4
memory leak in crypto_create_tfm
Hello, syzbot found the following crash on: HEAD commit:19409891 Merge tag 'pnp-5.8-rc1' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13165aa610 kernel config: https://syzkaller.appspot.com/x/.config?x=6d41e63a2c7e0715 dashboard link: https://syzkaller.appspot.com/bug?extid=2e635807decef724a1fa compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17f00ef210 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=170f2ef210 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+2e635807decef724a...@syzkaller.appspotmail.com executing program executing program BUG: memory leak unreferenced object 0x8881175bc480 (size 64): comm "syz-executor064", pid 6388, jiffies 4294941622 (age 13.280s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0 7e 56 84 ff ff ff ff 00 00 00 00 00 00 00 00 .~V. backtrace: [<29c7602f>] kmalloc include/linux/slab.h:560 [inline] [<29c7602f>] kzalloc include/linux/slab.h:669 [inline] [<29c7602f>] crypto_create_tfm+0x31/0x100 crypto/api.c:448 [] crypto_alloc_tfm+0x79/0x1a0 crypto/api.c:527 [<2f9791ba>] drbg_prepare_hrng crypto/drbg.c:1509 [inline] [<2f9791ba>] drbg_instantiate crypto/drbg.c:1587 [inline] [<2f9791ba>] drbg_kcapi_seed+0x432/0x6a9 crypto/drbg.c:1980 [<41302bb8>] crypto_rng_reset+0x35/0x1a0 crypto/rng.c:53 [<4758c3c4>] alg_setkey crypto/af_alg.c:222 [inline] [<4758c3c4>] alg_setsockopt+0x149/0x190 crypto/af_alg.c:255 [<8bc4b5cb>] __sys_setsockopt+0x112/0x230 net/socket.c:2132 [ ] __do_sys_setsockopt net/socket.c:2148 [inline] [ ] __se_sys_setsockopt net/socket.c:2145 [inline] [ ] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2145 [ ] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295 [<40e080a1>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x8881175bc040 (size 64): comm "syz-executor064", pid 6389, jiffies 4294942172 (age 7.780s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0 7e 56 84 ff ff ff ff 00 00 00 00 00 00 00 00 .~V. backtrace: [<29c7602f>] kmalloc include/linux/slab.h:560 [inline] [<29c7602f>] kzalloc include/linux/slab.h:669 [inline] [<29c7602f>] crypto_create_tfm+0x31/0x100 crypto/api.c:448 [ ] crypto_alloc_tfm+0x79/0x1a0 crypto/api.c:527 [<2f9791ba>] drbg_prepare_hrng crypto/drbg.c:1509 [inline] [<2f9791ba>] drbg_instantiate crypto/drbg.c:1587 [inline] [<2f9791ba>] drbg_kcapi_seed+0x432/0x6a9 crypto/drbg.c:1980 [<41302bb8>] crypto_rng_reset+0x35/0x1a0 crypto/rng.c:53 [<4758c3c4>] alg_setkey crypto/af_alg.c:222 [inline] [<4758c3c4>] alg_setsockopt+0x149/0x190 crypto/af_alg.c:255 [<8bc4b5cb>] __sys_setsockopt+0x112/0x230 net/socket.c:2132 [ ] __do_sys_setsockopt net/socket.c:2148 [inline] [ ] __se_sys_setsockopt net/socket.c:2145 [inline] [ ] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2145 [ ] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295 [<40e080a1>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x88811b3ca080 (size 96): comm "syz-executor064", pid 6389, jiffies 4294942172 (age 7.780s) hex dump (first 32 bytes): 89 c7 08 cb 8a 12 10 6e 00 00 00 00 00 00 00 00 ...n 71 51 5a c2 1b 00 00 00 35 7d 00 00 00 00 00 00 qQZ.5}.. backtrace: [<8ec3eca0>] jent_entropy_collector_alloc+0x1b/0xf8 crypto/jitterentropy.c:662 [<26ed401a>] jent_kcapi_init+0x17/0x40 crypto/jitterentropy-kcapi.c:119 [ ] crypto_create_tfm+0x89/0x100 crypto/api.c:459 [ ] crypto_alloc_tfm+0x79/0x1a0 crypto/api.c:527 [<2f9791ba>] drbg_prepare_hrng crypto/drbg.c:1509 [inline] [<2f9791ba>] drbg_instantiate crypto/drbg.c:1587 [inline] [<2f9791ba>] drbg_kcapi_seed+0x432/0x6a9 crypto/drbg.c:1980 [<41302bb8>] crypto_rng_reset+0x35/0x1a0 crypto/rng.c:53 [<4758c3c4>] alg_setkey crypto/af_alg.c:222 [inline] [<4758c3c4>] alg_setsockopt+0x149/0x190 crypto/af_alg.c:255 [<8bc4b5cb>] __sys_setsockopt+0x112/0x230 net/socket.c:2132 [ ] __do_sys_setsockopt net/socket.c:2148 [inline] [ ] __se_sys_setsockopt net/socket.c:2145 [inline] [ ] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2145
[PATCH] drm/connector: notify userspace on hotplug after register complete
drm connector notifies userspace on hotplug event prematurely before late_register and mode_object register completes. This leads to a race between userspace and kernel on updating the IDR list. So, move the notification to end of connector register. Signed-off-by: Jeykumar Sankaran Signed-off-by: Steve Cohen --- drivers/gpu/drm/drm_connector.c | 5 + drivers/gpu/drm/drm_sysfs.c | 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index b1099e1..d877ddc 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -27,6 +27,7 @@ #include #include #include +#include #include @@ -523,6 +524,10 @@ int drm_connector_register(struct drm_connector *connector) drm_mode_object_register(connector->dev, >base); connector->registration_state = DRM_CONNECTOR_REGISTERED; + + /* Let userspace know we have a new connector */ + drm_sysfs_hotplug_event(connector->dev); + goto unlock; err_debugfs: diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index 939f003..f0336c8 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -291,9 +291,6 @@ int drm_sysfs_connector_add(struct drm_connector *connector) return PTR_ERR(connector->kdev); } - /* Let userspace know we have a new connector */ - drm_sysfs_hotplug_event(dev); - if (connector->ddc) return sysfs_create_link(>kdev->kobj, >ddc->dev.kobj, "ddc"); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2] Documentation: kunit: Add some troubleshooting tips to the FAQ
Add an FAQ entry to the KUnit documentation with some tips for troubleshooting KUnit and kunit_tool. These suggestions largely came from an email thread: https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b94...@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03 Signed-off-by: David Gow Reviewed-by: Alan Maguire Reviewed-by: Brendan Higgins --- Changes since v1[1] - Added a section about running KUnit outside UML (based heavily on Alan's suggestion in the thread). [1]: https://lore.kernel.org/linux-kselftest/20200602054216.93122-1-david...@google.com/ Documentation/dev-tools/kunit/faq.rst | 40 +++ 1 file changed, 40 insertions(+) diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index ea55b2467653..1628862e7024 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -61,3 +61,43 @@ test, or an end-to-end test. kernel by installing a production configuration of the kernel on production hardware with a production userspace and then trying to exercise some behavior that depends on interactions between the hardware, the kernel, and userspace. + +KUnit isn't working, what should I do? +== + +Unfortunately, there are a number of things which can break, but here are some +things to try. + +1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output`` + parameter. This might show details or error messages hidden by the kunit_tool + parser. +2. Instead of running ``kunit.py run``, try running ``kunit.py config``, + ``kunit.py build``, and ``kunit.py exec`` independently. This can help track + down where an issue is occurring. (If you think the parser is at fault, you + can run it manually against stdin or a file with ``kunit.py parse``.) +3. Running the UML kernel directly can often reveal issues or error messages + kunit_tool ignores. This should be as simple as running ``./vmlinux`` after + building the UML kernel (e.g., by using ``kunit.py build``). Note that UML + has some unusual requirements (such as the host having a tmpfs filesystem + mounted), and has had issues in the past when built statically and the host + has KASLR enabled. (On older host kernels, you may need to run ``setarch + `uname -m` -R ./vmlinux`` to disable KASLR.) +4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test + (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config + around, so you can see what config was used after running ``kunit.py run``. + It also preserves any config changes you might make, so you can + enable/disable things with ``make ARCH=um menuconfig`` or similar, and then + re-run kunit_tool. +5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This + may help clean up any residual config items which could be causing problems. +6. Finally, try running KUnit outside UML. KUnit and KUnit tests can run be + built into any kernel, or can be built as a module and loaded at runtime. + Doing so should allow you to determine if UML is causing the issue you're + seeing. When tests are built-in, they will execute when the kernel boots, and + modules will automatically execute associated tests when loaded. Test results + can be collected from ``/sys/kernel/debug/kunit//results``, and + can be parsed with ``kunit.py parse``. For more details, see "KUnit on + non-UML architectures" in :doc:`usage`. + +If none of the above tricks help, you are always welcome to email any issues to +kunit-...@googlegroups.com. -- 2.27.0.rc2.251.g90737beb825-goog
Re: [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration
On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote: > On Wed, 29 Apr 2020 20:39:50 -0400 > Yan Zhao wrote: > > > On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote: > > > > > > > > > > > > > > > > > An mdev type is meant to define a software > > > > > > > > > > > > > > > compatible interface, so in > > > > > > > > > > > > > > > the case of mdev->mdev migration, doesn't > > > > > > > > > > > > > > > migrating to a different type > > > > > > > > > > > > > > > fail the most basic of compatibility tests that > > > > > > > > > > > > > > > we expect userspace to > > > > > > > > > > > > > > > perform? IOW, if two mdev types are migration > > > > > > > > > > > > > > > compatible, it seems a > > > > > > > > > > > > > > > prerequisite to that is that they provide the > > > > > > > > > > > > > > > same software interface, > > > > > > > > > > > > > > > which means they should be the same mdev type. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the hybrid cases of mdev->phys or phys->mdev, > > > > > > > > > > > > > > > how does a > > > > > > > > > > > > > > management > > > > > > > > > > > > > > > tool begin to even guess what might be > > > > > > > > > > > > > > > compatible? Are we expecting > > > > > > > > > > > > > > > libvirt to probe ever device with this attribute > > > > > > > > > > > > > > > in the system? Is > > > > > > > > > > > > > > > there going to be a new class hierarchy created > > > > > > > > > > > > > > > to enumerate all > > > > > > > > > > > > > > > possible migrate-able devices? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yes, management tool needs to guess and test > > > > > > > > > > > > > > migration compatible > > > > > > > > > > > > > > between two devices. But I think it's not the > > > > > > > > > > > > > > problem only for > > > > > > > > > > > > > > mdev->phys or phys->mdev. even for mdev->mdev, > > > > > > > > > > > > > > management tool needs > > > > > > > > > > > > > > to > > > > > > > > > > > > > > first assume that the two mdevs have the same type > > > > > > > > > > > > > > of parent devices > > > > > > > > > > > > > > (e.g.their pciids are equal). otherwise, it's still > > > > > > > > > > > > > > enumerating > > > > > > > > > > > > > > possibilities. > > > > > > > > > > > > > > > > > > > > > > > > > > > > on the other hand, for two mdevs, > > > > > > > > > > > > > > mdev1 from pdev1, its mdev_type is 1/2 of pdev1; > > > > > > > > > > > > > > mdev2 from pdev2, its mdev_type is 1/4 of pdev2; > > > > > > > > > > > > > > if pdev2 is exactly 2 times of pdev1, why not allow > > > > > > > > > > > > > > migration between > > > > > > > > > > > > > > mdev1 <-> mdev2. > > > > > > > > > > > > > > > > > > > > > > > > > > How could the manage tool figure out that 1/2 of > > > > > > > > > > > > > pdev1 is equivalent > > > > > > > > > > > > > to 1/4 of pdev2? If we really want to allow such > > > > > > > > > > > > > thing happen, the best > > > > > > > > > > > > > choice is to report the same mdev type on both pdev1 > > > > > > > > > > > > > and pdev2. > > > > > > > > > > > > I think that's exactly the value of this > > > > > > > > > > > > migration_version interface. > > > > > > > > > > > > the management tool can take advantage of this > > > > > > > > > > > > interface to know if two > > > > > > > > > > > > devices are migration compatible, no matter they are > > > > > > > > > > > > mdevs, non-mdevs, > > > > > > > > > > > > or mix. > > > > > > > > > > > > > > > > > > > > > > > > as I know, (please correct me if not right), current > > > > > > > > > > > > libvirt still > > > > > > > > > > > > requires manually generating mdev devices, and it just > > > > > > > > > > > > duplicates src vm > > > > > > > > > > > > configuration to the target vm. > > > > > > > > > > > > for libvirt, currently it's always phys->phys and > > > > > > > > > > > > mdev->mdev (and of the > > > > > > > > > > > > same mdev type). > > > > > > > > > > > > But it does not justify that hybrid cases should not be > > > > > > > > > > > > allowed. otherwise, > > > > > > > > > > > > why do we need to introduce this migration_version > > > > > > > > > > > > interface and leave > > > > > > > > > > > > the judgement of migration compatibility to vendor > > > > > > > > > > > > driver? why not simply > > > > > > > > > > > > set the criteria to something like "pciids of parent > > > > > > > > > > > > devices are equal, > > > > > > > > > > > > and mdev types are equal" ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > btw mdev<->phys just brings trouble to upper stack as > > > > > > > > > > > > > Alex pointed out. > > > > > > > > > > > > could you help me understand why it will bring trouble > > > > > > > > > > > > to upper stack? > > > > > > > > > > > > > > > > > > > > > > > > I think it just needs to read src migration_version > > > > > > > > > > > > under src dev node, > > > > > > > > > >
Re: [PATCH 2/3] arm64: mm: reserve hugetlb CMA after numa_init
On Wed, Jun 03, 2020 at 02:42:30PM +1200, Barry Song wrote: > hugetlb_cma_reserve() is called at the wrong place. numa_init has not been > done yet. so all reserved memory will be located at node0. > > Cc: Roman Gushchin > Signed-off-by: Barry Song Acked-by: Roman Gushchin Thanks! > --- > arch/arm64/mm/init.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index e42727e3568e..8f0e70ebb49d 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -458,11 +458,6 @@ void __init arm64_memblock_init(void) > high_memory = __va(memblock_end_of_DRAM() - 1) + 1; > > dma_contiguous_reserve(arm64_dma32_phys_limit); > - > -#ifdef CONFIG_ARM64_4K_PAGES > - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); > -#endif > - > } > > void __init bootmem_init(void) > @@ -478,6 +473,11 @@ void __init bootmem_init(void) > min_low_pfn = min; > > arm64_numa_init(); > + > +#ifdef CONFIG_ARM64_4K_PAGES > + hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); > +#endif > + > /* >* Sparsemem tries to allocate bootmem in memory_present(), so must be >* done after the fixed reservations. > -- > 2.23.0 > >
Re: [PATCH] pwm: rockchip: simplify rockchip_pwm_get_state()
This change is very good, thank you. The code continues from the original code(get_state_v1 and get_state_v2), didn’t make any changes at that time, and sorry I have not seen linux-rockc...@lists.infradead.org mail recently. 在 2020/6/2 下午8:39, Thierry Reding 写道: On Thu, Sep 19, 2019 at 11:17:27AM +0200, Rasmus Villemoes wrote: The way state->enabled is computed is rather convoluted and hard to read - both branches of the if() actually do the exact same thing. So remove the if(), and further simplify " ? true : false" to "". Signed-off-by: Rasmus Villemoes --- I stumbled on this while trying to understand how the pwm subsystem works. This patch is a semantic no-op, but it's also possible that, say, the first branch simply contains a "double negative" so either the != should be == or the "false : true" should be "true : false". drivers/pwm/pwm-rockchip.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) I've applied this. Irrespective of any feedback David would have this is correct and a nice simplification. Thierry
RE: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
> Subject: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M I'll drop this patch for yaml update, since https://lkml.org/lkml/2020/6/1/370 includes imx8mq/mm/n/p. Thanks, Peng. > > From: Peng Fan > > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs > > Reviewed-by: Dong Aisheng > Signed-off-by: Peng Fan > --- > Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > index 26b7a88c2fea..906377acf2cd 100644 > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > @@ -18,7 +18,8 @@ Messaging Unit Device Node: > Required properties: > --- > - compatible : should be "fsl,-mu", the supported chips include > - imx6sx, imx7s, imx8qxp, imx8qm. > + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn, > + imx8mp. > The "fsl,imx6sx-mu" compatible is seen as generic and should > be included together with SoC specific compatible. > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" > -- > 2.16.4
[PATCH] perf svghelper: fix memory leak in svg_build_topology_map
Fix leak of memory pointed to by t.sib_thr and t.sib_core in svg_build_topology_map in the non-error path. Signed-off-by: Li Bin --- tools/perf/util/svghelper.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/svghelper.c b/tools/perf/util/svghelper.c index 96f941e..d50955f 100644 --- a/tools/perf/util/svghelper.c +++ b/tools/perf/util/svghelper.c @@ -754,6 +754,7 @@ int svg_build_topology_map(struct perf_env *env) int i, nr_cpus; struct topology t; char *sib_core, *sib_thr; + int ret = -1; nr_cpus = min(env->nr_cpus_online, MAX_NR_CPUS); @@ -798,12 +799,11 @@ int svg_build_topology_map(struct perf_env *env) topology_map[i] = -1; scan_core_topology(topology_map, , nr_cpus); - - return 0; + ret = 0; exit: zfree(_core); zfree(_thr); - return -1; + return ret; } -- 1.7.12.4
Re: [LKP] Re: 28307d938f ("percpu: make pcpu_alloc() aware of current gfp .."): BUG: kernel reboot-without-warning in boot stage
On 6/2/20 8:18 PM, Filipe Manana wrote: On 02/06/20 05:37, Li Zhijian wrote: Hi Filipe, LKP checked blow dmesg as the indicator in this problem [ 0.144174] RAMDISK: [mem 0x7fa2e000-0x7fff] [ 0.144559] ACPI: Early table checksum verification disabled [ 0.144985] ACPI: RSDP 0x000F5850 14 (v00 BOCHS ) [ 0.145424] ACPI: RSDT 0xBFFE15C9 30 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [ 0.146051] ACPI: FACP 0xBFFE149D 74 (v01 BOCHS BXPCFACP 0001 BXPC 0001) BUG: kernel reboot-without-warning in boot stage And i have reproduced it with script in attachment. this issue is gone when i reverted this commit 28307d938f Please note that - i reproduced it with kernel compiled by gcc-5 - i failed to reproduce it in kernel compiled by gcc-7 so far Odd. Indeed ! i tested gcc-5 gcc-6 gcc-7, only gcc-5 triggered this issue, kernel built with gcc6 and gcc-7 works well lizhijian@shao2-debian:~$ gcc-6 --version gcc-6 (Debian 6.5.0-2) 6.5.0 20181026 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. lizhijian@shao2-debian:~$ gcc-5 --version gcc-5 (Debian 5.5.0-12) 5.5.0 20171010 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. lizhijian@shao2-debian:~$ gcc-7 --version gcc-7 (Debian 7.5.0-3) 7.5.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks Zhijian Here I tested with: $ gcc --version gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 Copyright (C) 2016 Free Software Foundation, Inc.
Re: [PATCH] sound: usb: pcm: fix incorrect power state when playing sound after PM_AUTO suspend
On Tue, 2020-06-02 at 14:46 +0200, Takashi Iwai wrote: > On Tue, 02 Jun 2020 13:53:41 +0200, > Macpaul Lin wrote: > > > > This patch fix incorrect power state changed by usb_audio_suspend() > > when CONFIG_PM is enabled. > > > > After receiving suspend PM message with auto flag, usb_audio_suspend() > > change card's power state to SNDRV_CTL_POWER_D3hot. Only when the other > > resume PM message with auto flag can change power state to > > SNDRV_CTL_POWER_D0 in __usb_audio_resume(). > > > > However, when system is not under auto suspend, resume PM message with > > auto flag might not be able to receive on time which cause the power > > state was incorrect. At this time, if a player starts to play sound, > > will cause snd_usb_pcm_open() to access the card and setup_hw_info() will > > resume the card. > > > > But even the card is back to work and all function normal, the power > > state is still in SNDRV_CTL_POWER_D3hot. > > Hm, in exactly which situation does this happen? I still don't get > it. Could you elaborate how to trigger this? I'm not sure if this will happen on laptop or on PC. We've found this issue on Android phone (I'm not sure if each Android phone can reproduce this.). After booting the android phone, insert type-c headset without charging and play music at any duration, say, 1 second, then stop. Put phone away to idle about 17~18 minutes. Wait auto pm happened and the power state change to SNDRV_CTL_POWER_D3hot in sound/usb/card.c. Then wake up the phone, play music again. Then you'll probably found the music was not playing and the progress bar keep at the same position. It only happen when power state is SNDRV_CTL_POWER_D3hot. If not (the power state is SNDRV_CTL_POWER_D0), repeat the steps for several times, then it will be produced at some time. When it happened, sound_usb_pcm_open() will wake up the sound card by setup_hw_info()->__usb_audio_resume(). However, the card and the interface is function properly right now, the power state keeps remain SNDRV_CTL_POWER_D3hot. The suggestive parameter settings from upper sound request will be pending since later snd_power_wait() call will still wait the card awaken. Ideally, auto PM should be recovered by sound card itself. But once the card is awaken at this circumstance, it looks like there are not more auto pm event. And the sound system of this interface will stuck here forever until user plug out the headset (reset the hardware). The root cause is that once the card has been resumed, it should inform auto pm change the state back into SNDRV_CTL_POWER_D0 and mark the device is using by some one. > > Which cause the infinite loop > > happened in snd_power_wait() to check the power state. Thus the > > successive setting ioctl cannot be passed to card. > > > > Hence we suggest to change power state to SNDRV_CTL_POWER_D0 when card > > has been resumed successfully. > > This doesn't look like a right solution for the problem, sorry. > The card PM status must be recovered to D0 when the autoresume > succeeds. If not, something is broken there, and it must be fixed > instead of fiddling the status flag externally. Yes, I agreed, but after checking the code in sound drivers, it looks like there is only chance that auto pm triggered by low-level code in sound/usb/card.c. In kernel 4.14, auto pm suspend is triggered by snd_pcm_suspend_all(). In later kernel, it is triggered by snd_usb_pcm_suspend(). However, it looks like there are no any resume trigger to recover auto pm state when the card has been waken by sound_usb_pcm_open(). The remain resume trigger in sound/core/pcm_native.c were all static. I've tried to use these resume function in sound/usb/card.c but it seems cannot get better result than changing the power state when sound card is in use. I've replied another mail earlier includes debug patch and the other work around to verify this issue. The issue has been found on kernel-4.14, but check the code logic here in sound/usb/card.c and sound/usb/pcm.c, I think the same problem still existed in 4.19, 5.4 (used by android), and in current kernel tree. > thanks, > > Takashi If the above explanation were not clear enough, I'll try my best to explain it in more detail. Maybe the better way is to send both auto pm resume and runtime resume when sound_usb_pcm_open() is called. But according to the current codes in card.c, we might need to call __usb_audio_resume() twice in setup_hw_info(). Thanks Macpaul Lin
Re: [PATCH 2/4] perf svghelper: Fix memory leak in svg_build_topology_map
在 2020/5/21 22:15, Arnaldo Carvalho de Melo 写道:
Em Thu, May 21, 2020 at 09:32:16PM +0800, Wei Li escreveu:
From: Li Bin
Fix leak of memory pointed to by t.sib_thr and t.sib_core in
svg_build_topology_map.
Signed-off-by: Li Bin
---
tools/perf/util/svghelper.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/svghelper.c b/tools/perf/util/svghelper.c
index 96f941e01681..e2b3b0e2fafe 100644
--- a/tools/perf/util/svghelper.c
+++ b/tools/perf/util/svghelper.c
@@ -754,6 +754,7 @@ int svg_build_topology_map(struct perf_env *env)
int i, nr_cpus;
struct topology t;
char *sib_core, *sib_thr;
+ int ret;
Please set ret to -1 here
int ret = -1;
So that you don't have to add all those lines below...
nr_cpus = min(env->nr_cpus_online, MAX_NR_CPUS);
@@ -767,12 +768,14 @@ int svg_build_topology_map(struct perf_env *env)
if (!t.sib_core || !t.sib_thr) {
fprintf(stderr, "topology: no memory\n");
+ ret = -1;
goto exit;
}
for (i = 0; i < env->nr_sibling_cores; i++) {
if (str_to_bitmap(sib_core, _core[i], nr_cpus)) {
fprintf(stderr, "topology: can't parse siblings map\n");
+ ret = -1;
goto exit;
}
@@ -782,6 +785,7 @@ int svg_build_topology_map(struct perf_env *env)
for (i = 0; i < env->nr_sibling_threads; i++) {
if (str_to_bitmap(sib_thr, _thr[i], nr_cpus)) {
fprintf(stderr, "topology: can't parse siblings map\n");
+ ret = -1;
goto exit;
}
@@ -791,6 +795,7 @@ int svg_build_topology_map(struct perf_env *env)
topology_map = malloc(sizeof(int) * nr_cpus);
if (!topology_map) {
fprintf(stderr, "topology: no memory\n");
+ ret = -1;
goto exit;
}
@@ -798,12 +803,11 @@ int svg_build_topology_map(struct perf_env *env)
topology_map[i] = -1;
scan_core_topology(topology_map, , nr_cpus);
-
- return 0;
... as you'll set it to zero here :-)
Thank you for your comments. I will fix it.
Thanks,
Li Bin
+ ret = 0;
exit:
zfree(_core);
zfree(_thr);
- return -1;
+ return ret;
}
--
2.17.1
[PATCH] usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
From: Zqiang BUG: memory leak unreferenced object 0x888055046e00 (size 256): comm "kworker/2:9", pid 2570, jiffies 4294942129 (age 1095.500s) hex dump (first 32 bytes): 00 70 04 55 80 88 ff ff 18 bb 5a 81 ff ff ff ff .p.U..Z. f5 96 78 81 ff ff ff ff 37 de 8e 81 ff ff ff ff ..x.7... backtrace: [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [ ] slab_post_alloc_hook mm/slab.h:586 [inline] [ ] slab_alloc_node mm/slub.c:2786 [inline] [ ] slab_alloc mm/slub.c:2794 [inline] [ ] kmem_cache_alloc_trace+0x15e/0x2d0 mm/slub.c:2811 [<5c3c3381>] kmalloc include/linux/slab.h:555 [inline] [<5c3c3381>] usbtest_probe+0x286/0x19d0 drivers/usb/misc/usbtest.c:2790 [<1cec6910>] usb_probe_interface+0x2bd/0x870 drivers/usb/core/driver.c:361 [<7806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551 [ ] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724 [<3ef66004>] __device_attach_driver+0x1b6/0x240 drivers/base/dd.c:831 [ ] bus_for_each_drv+0x14e/0x1e0 drivers/base/bus.c:431 [ ] __device_attach+0x1f9/0x350 drivers/base/dd.c:897 [<838b324a>] device_initial_probe+0x1a/0x20 drivers/base/dd.c:944 [<30d501c1>] bus_probe_device+0x1e1/0x280 drivers/base/bus.c:491 [<5bd7adef>] device_add+0x131d/0x1c40 drivers/base/core.c:2504 [ ] usb_set_configuration+0xe84/0x1ab0 drivers/usb/core/message.c:2030 [ ] generic_probe+0x6a/0xe0 drivers/usb/core/generic.c:210 [<98ade0f1>] usb_probe_device+0x90/0xd0 drivers/usb/core/driver.c:266 [<7806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551 [ ] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724 Fixes: fabbf2196d0d ("USB: usbtest fix coding style") Reported-by: Kyungtae Kim Signed-off-by: Zqiang --- drivers/usb/misc/usbtest.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c index 98ada1a3425c..bae88893ee8e 100644 --- a/drivers/usb/misc/usbtest.c +++ b/drivers/usb/misc/usbtest.c @@ -2873,6 +2873,7 @@ static void usbtest_disconnect(struct usb_interface *intf) usb_set_intfdata(intf, NULL); dev_dbg(>dev, "disconnect\n"); + kfree(dev->buf); kfree(dev); } -- 2.24.1
Re: [PATCH] cxl: Fix kobject memory leak in cxl_sysfs_afu_new_cr()
"wanghai (M)" writes: > 在 2020/6/3 1:20, Markus Elfring 写道: >>> Fix it by adding a call to kobject_put() in the error path of >>> kobject_init_and_add(). >> Thanks for another completion of the exception handling. >> >> Would an other patch subject be a bit nicer? > Thanks for the guidance, I will perfect this description and send a v2 >> >> … >>> +++ b/drivers/misc/cxl/sysfs.c >>> @@ -624,7 +624,7 @@ static struct afu_config_record >>> *cxl_sysfs_afu_new_cr(struct cxl_afu *afu, int c >>> rc = kobject_init_and_add(>kobj, _config_record_type, >>> >dev.kobj, "cr%i", cr->cr); >>> if (rc) >>> - goto err; >>> + goto err1; >> … >> >> Can an other label be more reasonable here? >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=f359287765c04711ff54fbd11645271d8e5ff763#n465 > I just used the original author's label, should I replace all his labels > like'err','err1' with reasonable one. No. cheers
Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split
On Wed, Jun 03, 2020 at 06:56:57AM +0530, Anshuman Khandual wrote: > On 06/02/2020 08:31 PM, Matthew Wilcox wrote: > > On Fri, May 22, 2020 at 09:04:04AM +0530, Anshuman Khandual wrote: > >> This adds the following two new VM events which will help in validating PMD > >> based THP migration without split. Statistics reported through these events > >> will help in performance debugging. > >> > >> 1. THP_PMD_MIGRATION_SUCCESS > >> 2. THP_PMD_MIGRATION_FAILURE > > > > There's nothing actually PMD specific about these events, is there? > > If we have a THP of a non-PMD size, you'd want that reported through the > > same statistic, wouldn't you? > > Yes, there is nothing PMD specific here and we would use the same statistics > for non-PMD size THP migration (if any) as well. But is THP migration really > supported for non-PMD sizes ? CONFIG_ARCH_ENABLE_THP_MIGRATION depends upon > CONFIG_TRANSPARENT_HUGEPAGE without being specific or denying about possible > PUD level support. Fair enough, will drop the PMD from the events and their > functions. I guess you haven't read my large pages patchset?
[PATCH] usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
From: Zqiang BUG: memory leak unreferenced object 0x888055046e00 (size 256): comm "kworker/2:9", pid 2570, jiffies 4294942129 (age 1095.500s) hex dump (first 32 bytes): 00 70 04 55 80 88 ff ff 18 bb 5a 81 ff ff ff ff .p.U..Z. f5 96 78 81 ff ff ff ff 37 de 8e 81 ff ff ff ff ..x.7... backtrace: [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [ ] slab_post_alloc_hook mm/slab.h:586 [inline] [ ] slab_alloc_node mm/slub.c:2786 [inline] [ ] slab_alloc mm/slub.c:2794 [inline] [ ] kmem_cache_alloc_trace+0x15e/0x2d0 mm/slub.c:2811 [<5c3c3381>] kmalloc include/linux/slab.h:555 [inline] [<5c3c3381>] usbtest_probe+0x286/0x19d0 drivers/usb/misc/usbtest.c:2790 [<1cec6910>] usb_probe_interface+0x2bd/0x870 drivers/usb/core/driver.c:361 [<7806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551 [ ] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724 [<3ef66004>] __device_attach_driver+0x1b6/0x240 drivers/base/dd.c:831 [ ] bus_for_each_drv+0x14e/0x1e0 drivers/base/bus.c:431 [ ] __device_attach+0x1f9/0x350 drivers/base/dd.c:897 [<838b324a>] device_initial_probe+0x1a/0x20 drivers/base/dd.c:944 [<30d501c1>] bus_probe_device+0x1e1/0x280 drivers/base/bus.c:491 [<5bd7adef>] device_add+0x131d/0x1c40 drivers/base/core.c:2504 [ ] usb_set_configuration+0xe84/0x1ab0 drivers/usb/core/message.c:2030 [ ] generic_probe+0x6a/0xe0 drivers/usb/core/generic.c:210 [<98ade0f1>] usb_probe_device+0x90/0xd0 drivers/usb/core/driver.c:266 [<7806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551 [ ] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724 Fixes: fabbf2196d0d ("USB: usbtest fix coding style") Reported-by: Kyungtae Kim Signed-off-by: Zqiang --- drivers/usb/misc/usbtest.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c index 98ada1a3425c..bae88893ee8e 100644 --- a/drivers/usb/misc/usbtest.c +++ b/drivers/usb/misc/usbtest.c @@ -2873,6 +2873,7 @@ static void usbtest_disconnect(struct usb_interface *intf) usb_set_intfdata(intf, NULL); dev_dbg(>dev, "disconnect\n"); + kfree(dev->buf); kfree(dev); } -- 2.24.1
Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode
Thanks for reminding me. I will test the cases through using sch_fq. Jason On Wed, Jun 3, 2020 at 10:44 AM Eric Dumazet wrote: > > On Tue, Jun 2, 2020 at 7:42 PM Jason Xing wrote: > > > > I agree with you. The upstream has already dropped and optimized this > > part (commit 864e5c090749), so it would not happen like that. However > > the old kernels like LTS still have the problem which causes > > large-scale crashes on our thousands of machines after running for a > > long while. I will send the fix to the correct tree soon :) > > If you run BBR at scale (thousands of machines), you probably should > use sch_fq instead of internal pacing, > just saying ;) > > > > > > Thanks again, > > Jason > > > > On Wed, Jun 3, 2020 at 10:29 AM Eric Dumazet wrote: > > > > > > On Tue, Jun 2, 2020 at 6:53 PM Jason Xing > > > wrote: > > > > > > > > Hi Eric, > > > > > > > > I'm sorry that I didn't write enough clearly. We're running the > > > > pristine 4.19.125 linux kernel (the latest LTS version) and have been > > > > haunted by such an issue. This patch is high-important, I think. So > > > > I'm going to resend this email with the [patch 4.19] on the headline > > > > and cc Greg. > > > > > > Yes, please always give for which tree a patch is meant for. > > > > > > Problem is that your patch is not correct. > > > In these old kernels, tcp_internal_pacing() is called _after_ the > > > packet has been sent. > > > It is too late to 'give up pacing' > > > > > > The packet should not have been sent if the pacing timer is queued > > > (otherwise this means we do not respect pacing) > > > > > > So the bug should be caught earlier. check where tcp_pacing_check() > > > calls are missing. > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > Jason > > > > > > > > On Tue, Jun 2, 2020 at 9:05 PM Eric Dumazet wrote: > > > > > > > > > > On Tue, Jun 2, 2020 at 1:05 AM wrote: > > > > > > > > > > > > From: Jason Xing > > > > > > > > > > > > TCP socks cannot be released because of the sock_hold() increasing > > > > > > the > > > > > > sk_refcnt in the manner of tcp_internal_pacing() when RTO happens. > > > > > > Therefore, this situation could increase the slab memory and then > > > > > > trigger > > > > > > the OOM if the machine has beening running for a long time. This > > > > > > issue, > > > > > > however, can happen on some machine only running a few days. > > > > > > > > > > > > We add one exception case to avoid unneeded use of sock_hold if the > > > > > > pacing_timer is enqueued. > > > > > > > > > > > > Reproduce procedure: > > > > > > 0) cat /proc/slabinfo | grep TCP > > > > > > 1) switch net.ipv4.tcp_congestion_control to bbr > > > > > > 2) using wrk tool something like that to send packages > > > > > > 3) using tc to increase the delay in the dev to simulate the busy > > > > > > case. > > > > > > 4) cat /proc/slabinfo | grep TCP > > > > > > 5) kill the wrk command and observe the number of objects and slabs > > > > > > in TCP. > > > > > > 6) at last, you could notice that the number would not decrease. > > > > > > > > > > > > Signed-off-by: Jason Xing > > > > > > Signed-off-by: liweishi > > > > > > Signed-off-by: Shujin Li > > > > > > --- > > > > > > net/ipv4/tcp_output.c | 3 ++- > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > > > > > > index cc4ba42..5cf63d9 100644 > > > > > > --- a/net/ipv4/tcp_output.c > > > > > > +++ b/net/ipv4/tcp_output.c > > > > > > @@ -969,7 +969,8 @@ static void tcp_internal_pacing(struct sock > > > > > > *sk, const struct sk_buff *skb) > > > > > > u64 len_ns; > > > > > > u32 rate; > > > > > > > > > > > > - if (!tcp_needs_internal_pacing(sk)) > > > > > > + if (!tcp_needs_internal_pacing(sk) || > > > > > > + hrtimer_is_queued(_sk(sk)->pacing_timer)) > > > > > > return; > > > > > > rate = sk->sk_pacing_rate; > > > > > > if (!rate || rate == ~0U) > > > > > > -- > > > > > > 1.8.3.1 > > > > > > > > > > > > > > > > Hi Jason. > > > > > > > > > > Please do not send patches that do not apply to current upstream > > > > > trees. > > > > > > > > > > Instead, backport to your kernels the needed fixes. > > > > > > > > > > I suspect that you are not using a pristine linux kernel, but some > > > > > heavily modified one and something went wrong in your backports. > > > > > Do not ask us to spend time finding what went wrong. > > > > > > > > > > Thank you.
linux-next: build failure after merge of the v4l-dvb-next tree
Hi all,
After merging the v4l-dvb-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/media/atomisp/pci/atomisp_compat_css20.c: In function
'atomisp_css_isr_thread':
drivers/staging/media/atomisp/pci/atomisp_compat_css20.c:4196:9: error:
'atomisp_hw_is_isp2401' undeclared (first use in this function)
4196 |if (!atomisp_hw_is_isp2401)
| ^
drivers/staging/media/atomisp/pci/atomisp_compat_css20.c:4196:9: note: each
undeclared identifier is reported only once for each function it appears in
Caused by commit
be1fdab273a9 ("media: atomisp: change the detection of ISP2401 at runtime")
interacting with commit
7ef17aa55fc3 ("media: atomisp: atomisp_compat_css20.c: detect ISP at runtime")
I have used the version of the v4l-dvb-next tree from next-20200602
for today.
--
Cheers,
Stephen Rothwell
pgpdqeuigrnbS.pgp
Description: OpenPGP digital signature
[PATCH 3/3] arm64: mm: reserve per-numa CMA after numa_init
Right now, smmu is using dma_alloc_coherent() to get memory to save queues and tables. Typically, on ARM64 server, there is a default CMA located at node0, which could be far away from node2, node3 etc. with this patch, smmu will get memory from local numa node to save command queues and page tables. that means dma_unmap latency will be shrunk much. Meanwhile, when iommu.passthrough is on, device drivers which call dma_ alloc_coherent() will also get local memory and avoid the travel between numa nodes. Cc: Will Deacon Cc: Robin Murphy Signed-off-by: Barry Song --- arch/arm64/mm/init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 8f0e70ebb49d..204a534982b2 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -474,6 +474,8 @@ void __init bootmem_init(void) arm64_numa_init(); + dma_pernuma_cma_reserve(); + #ifdef CONFIG_ARM64_4K_PAGES hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); #endif -- 2.23.0
[PATCH 1/3] dma-direct: provide the ability to reserve per-numa CMA
This is useful for two scenarios:
1. ARM64 smmu will get memory from local numa node, it can save its
command queues and page tables locally. Tests show it can decrease
dma_unmap latency at lot. For example, without this patch, smmu on
node2 will get memory from node0 by calling dma_alloc_coherent(),
typically, it has to wait for more than 560ns for the completion of
CMD_SYNC in an empty command queue; with this patch, it needs 240ns
only.
2. when we set iommu passthrough, drivers will get memory from CMA,
local memory means much less latency.
Cc: Will Deacon
Cc: Robin Murphy
Signed-off-by: Barry Song
---
include/linux/dma-contiguous.h | 4
kernel/dma/Kconfig | 10 +
kernel/dma/contiguous.c| 41 +-
3 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 03f8e98e3bcc..278a80a40456 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -79,6 +79,8 @@ static inline void dma_contiguous_set_default(struct cma *cma)
void dma_contiguous_reserve(phys_addr_t addr_limit);
+void dma_pernuma_cma_reserve(void);
+
int __init dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t base,
phys_addr_t limit, struct cma **res_cma,
bool fixed);
@@ -128,6 +130,8 @@ static inline void dma_contiguous_set_default(struct cma
*cma) { }
static inline void dma_contiguous_reserve(phys_addr_t limit) { }
+static inline void dma_pernuma_cma_reserve(void) { }
+
static inline int dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t
base,
phys_addr_t limit, struct cma **res_cma,
bool fixed)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 4c103a24e380..14f4a1fe4285 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -100,6 +100,16 @@ config DMA_CMA
if DMA_CMA
comment "Default contiguous memory area size:"
+config CMA_PERNUMA_SIZE_MBYTES
+ int "Size in Mega Bytes for per-numa CMA areas"
+ depends on NUMA
+ default 16 if ARM64
+ default 0
+ help
+ Defines the size (in MiB) of the per-numa memory area for Contiguous
+ Memory Allocator. Every numa node will get a separate CMA with this
+ size. If the size of 0 is selected, per-numa CMA is disabled.
+
config CMA_SIZE_MBYTES
int "Size in Mega Bytes"
depends on !CMA_SIZE_SEL_PERCENTAGE
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 8bc6f2d670f9..4b10d0ca0456 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -30,7 +30,14 @@
#define CMA_SIZE_MBYTES 0
#endif
+#ifdef CONFIG_CMA_PERNUMA_SIZE_MBYTES
+#define CMA_SIZE_PERNUMA_MBYTES CONFIG_CMA_PERNUMA_SIZE_MBYTES
+#else
+#define CMA_SIZE_PERNUMA_MBYTES 0
+#endif
+
struct cma *dma_contiguous_default_area;
+struct cma *dma_contiguous_pernuma_area[MAX_NUMNODES];
/*
* Default global CMA area size can be defined in kernel's .config.
@@ -44,6 +51,8 @@ struct cma *dma_contiguous_default_area;
*/
static const phys_addr_t size_bytes __initconst =
(phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;
+static const phys_addr_t pernuma_size_bytes __initconst =
+ (phys_addr_t)CMA_SIZE_PERNUMA_MBYTES * SZ_1M;
static phys_addr_t size_cmdline __initdata = -1;
static phys_addr_t base_cmdline __initdata;
static phys_addr_t limit_cmdline __initdata;
@@ -96,6 +105,31 @@ static inline __maybe_unused phys_addr_t
cma_early_percent_memory(void)
#endif
+void __init dma_pernuma_cma_reserve(void)
+{
+ int nid;
+
+ if (!pernuma_size_bytes || nr_online_nodes <= 1)
+ return;
+
+ for_each_node_state(nid, N_ONLINE) {
+ int ret;
+
+ ret = cma_declare_contiguous_nid(0, pernuma_size_bytes, 0, 0,
+0, false, "pernuma",
+
_contiguous_pernuma_area[nid],
+nid);
+ if (ret) {
+ pr_warn("%s: reservation failed: err %d, node %d",
__func__,
+ ret, nid);
+ continue;
+ }
+
+ pr_debug("%s: reserved %llu MiB on node %d\n", __func__,
+ pernuma_size_bytes / SZ_1M, nid);
+ }
+}
+
/**
* dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
* @limit: End address of the reserved memory (optional, 0 for any).
@@ -223,7 +257,8 @@ bool dma_release_from_contiguous(struct device *dev, struct
page *pages,
*
* This function allocates contiguous memory buffer for specified device. It
* first tries to use device specific contiguous memory area if available or
- * the default global one, then tries a fallback allocation of normal pages.
+ *
[PATCH 2/3] arm64: mm: reserve hugetlb CMA after numa_init
hugetlb_cma_reserve() is called at the wrong place. numa_init has not been done yet. so all reserved memory will be located at node0. Cc: Roman Gushchin Signed-off-by: Barry Song --- arch/arm64/mm/init.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index e42727e3568e..8f0e70ebb49d 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -458,11 +458,6 @@ void __init arm64_memblock_init(void) high_memory = __va(memblock_end_of_DRAM() - 1) + 1; dma_contiguous_reserve(arm64_dma32_phys_limit); - -#ifdef CONFIG_ARM64_4K_PAGES - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); -#endif - } void __init bootmem_init(void) @@ -478,6 +473,11 @@ void __init bootmem_init(void) min_low_pfn = min; arm64_numa_init(); + +#ifdef CONFIG_ARM64_4K_PAGES + hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); +#endif + /* * Sparsemem tries to allocate bootmem in memory_present(), so must be * done after the fixed reservations. -- 2.23.0
Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode
On Tue, Jun 2, 2020 at 7:42 PM Jason Xing wrote: > > I agree with you. The upstream has already dropped and optimized this > part (commit 864e5c090749), so it would not happen like that. However > the old kernels like LTS still have the problem which causes > large-scale crashes on our thousands of machines after running for a > long while. I will send the fix to the correct tree soon :) If you run BBR at scale (thousands of machines), you probably should use sch_fq instead of internal pacing, just saying ;) > > Thanks again, > Jason > > On Wed, Jun 3, 2020 at 10:29 AM Eric Dumazet wrote: > > > > On Tue, Jun 2, 2020 at 6:53 PM Jason Xing wrote: > > > > > > Hi Eric, > > > > > > I'm sorry that I didn't write enough clearly. We're running the > > > pristine 4.19.125 linux kernel (the latest LTS version) and have been > > > haunted by such an issue. This patch is high-important, I think. So > > > I'm going to resend this email with the [patch 4.19] on the headline > > > and cc Greg. > > > > Yes, please always give for which tree a patch is meant for. > > > > Problem is that your patch is not correct. > > In these old kernels, tcp_internal_pacing() is called _after_ the > > packet has been sent. > > It is too late to 'give up pacing' > > > > The packet should not have been sent if the pacing timer is queued > > (otherwise this means we do not respect pacing) > > > > So the bug should be caught earlier. check where tcp_pacing_check() > > calls are missing. > > > > > > > > > > > > > > > Thanks, > > > Jason > > > > > > On Tue, Jun 2, 2020 at 9:05 PM Eric Dumazet wrote: > > > > > > > > On Tue, Jun 2, 2020 at 1:05 AM wrote: > > > > > > > > > > From: Jason Xing > > > > > > > > > > TCP socks cannot be released because of the sock_hold() increasing the > > > > > sk_refcnt in the manner of tcp_internal_pacing() when RTO happens. > > > > > Therefore, this situation could increase the slab memory and then > > > > > trigger > > > > > the OOM if the machine has beening running for a long time. This > > > > > issue, > > > > > however, can happen on some machine only running a few days. > > > > > > > > > > We add one exception case to avoid unneeded use of sock_hold if the > > > > > pacing_timer is enqueued. > > > > > > > > > > Reproduce procedure: > > > > > 0) cat /proc/slabinfo | grep TCP > > > > > 1) switch net.ipv4.tcp_congestion_control to bbr > > > > > 2) using wrk tool something like that to send packages > > > > > 3) using tc to increase the delay in the dev to simulate the busy > > > > > case. > > > > > 4) cat /proc/slabinfo | grep TCP > > > > > 5) kill the wrk command and observe the number of objects and slabs > > > > > in TCP. > > > > > 6) at last, you could notice that the number would not decrease. > > > > > > > > > > Signed-off-by: Jason Xing > > > > > Signed-off-by: liweishi > > > > > Signed-off-by: Shujin Li > > > > > --- > > > > > net/ipv4/tcp_output.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > > > > > index cc4ba42..5cf63d9 100644 > > > > > --- a/net/ipv4/tcp_output.c > > > > > +++ b/net/ipv4/tcp_output.c > > > > > @@ -969,7 +969,8 @@ static void tcp_internal_pacing(struct sock *sk, > > > > > const struct sk_buff *skb) > > > > > u64 len_ns; > > > > > u32 rate; > > > > > > > > > > - if (!tcp_needs_internal_pacing(sk)) > > > > > + if (!tcp_needs_internal_pacing(sk) || > > > > > + hrtimer_is_queued(_sk(sk)->pacing_timer)) > > > > > return; > > > > > rate = sk->sk_pacing_rate; > > > > > if (!rate || rate == ~0U) > > > > > -- > > > > > 1.8.3.1 > > > > > > > > > > > > > Hi Jason. > > > > > > > > Please do not send patches that do not apply to current upstream trees. > > > > > > > > Instead, backport to your kernels the needed fixes. > > > > > > > > I suspect that you are not using a pristine linux kernel, but some > > > > heavily modified one and something went wrong in your backports. > > > > Do not ask us to spend time finding what went wrong. > > > > > > > > Thank you.
[PATCH 0/3] support per-numa CMA for ARM server
Right now, smmu is using dma_alloc_coherent() to get memory to save queues and tables. Typically, on ARM64 server, there is a default CMA located at node0, which could be far away from node2, node3 etc. Saving queues and tables remotely will increase the latency of ARM SMMU significantly. For example, when SMMU is at node2 and the default global CMA is at node0, after sending a CMD_SYNC in an empty command queue, we have to wait more than 550ns for the completion of the command CMD_SYNC. However, if we save them locally, we only need to wait for 240ns. with per-numa CMA, smmu will get memory from local numa node to save command queues and page tables. that means dma_unmap latency will be shrunk much. Meanwhile, when iommu.passthrough is on, device drivers which call dma_ alloc_coherent() will also get local memory and avoid the travel between numa nodes. Barry Song (3): dma-direct: provide the ability to reserve per-numa CMA arm64: mm: reserve hugetlb CMA after numa_init arm64: mm: reserve per-numa CMA after numa_init arch/arm64/mm/init.c | 12 ++ include/linux/dma-contiguous.h | 4 kernel/dma/Kconfig | 10 kernel/dma/contiguous.c| 43 +- 4 files changed, 63 insertions(+), 6 deletions(-) -- 2.23.0
[PATCH] arch: kernel: Replace sg++ with sg = sg_next(sg)
Replace sg++ with sg = sg_next(sg).
Signed-off-by: Xu Wang
---
arch/alpha/kernel/pci_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 7f1925a32c99..81037907268d 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -638,7 +638,7 @@ sg_fill(struct device *dev, struct scatterlist *leader,
struct scatterlist *end,
while (sg+1 < end && (int) sg[1].dma_address == -1) {
size += sg[1].length;
- sg++;
+ sg = sg_next(sg);
}
npages = iommu_num_pages(paddr, size, PAGE_SIZE);
--
2.17.1
Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode
I agree with you. The upstream has already dropped and optimized this part (commit 864e5c090749), so it would not happen like that. However the old kernels like LTS still have the problem which causes large-scale crashes on our thousands of machines after running for a long while. I will send the fix to the correct tree soon :) Thanks again, Jason On Wed, Jun 3, 2020 at 10:29 AM Eric Dumazet wrote: > > On Tue, Jun 2, 2020 at 6:53 PM Jason Xing wrote: > > > > Hi Eric, > > > > I'm sorry that I didn't write enough clearly. We're running the > > pristine 4.19.125 linux kernel (the latest LTS version) and have been > > haunted by such an issue. This patch is high-important, I think. So > > I'm going to resend this email with the [patch 4.19] on the headline > > and cc Greg. > > Yes, please always give for which tree a patch is meant for. > > Problem is that your patch is not correct. > In these old kernels, tcp_internal_pacing() is called _after_ the > packet has been sent. > It is too late to 'give up pacing' > > The packet should not have been sent if the pacing timer is queued > (otherwise this means we do not respect pacing) > > So the bug should be caught earlier. check where tcp_pacing_check() > calls are missing. > > > > > > > > > Thanks, > > Jason > > > > On Tue, Jun 2, 2020 at 9:05 PM Eric Dumazet wrote: > > > > > > On Tue, Jun 2, 2020 at 1:05 AM wrote: > > > > > > > > From: Jason Xing > > > > > > > > TCP socks cannot be released because of the sock_hold() increasing the > > > > sk_refcnt in the manner of tcp_internal_pacing() when RTO happens. > > > > Therefore, this situation could increase the slab memory and then > > > > trigger > > > > the OOM if the machine has beening running for a long time. This issue, > > > > however, can happen on some machine only running a few days. > > > > > > > > We add one exception case to avoid unneeded use of sock_hold if the > > > > pacing_timer is enqueued. > > > > > > > > Reproduce procedure: > > > > 0) cat /proc/slabinfo | grep TCP > > > > 1) switch net.ipv4.tcp_congestion_control to bbr > > > > 2) using wrk tool something like that to send packages > > > > 3) using tc to increase the delay in the dev to simulate the busy case. > > > > 4) cat /proc/slabinfo | grep TCP > > > > 5) kill the wrk command and observe the number of objects and slabs in > > > > TCP. > > > > 6) at last, you could notice that the number would not decrease. > > > > > > > > Signed-off-by: Jason Xing > > > > Signed-off-by: liweishi > > > > Signed-off-by: Shujin Li > > > > --- > > > > net/ipv4/tcp_output.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > > > > index cc4ba42..5cf63d9 100644 > > > > --- a/net/ipv4/tcp_output.c > > > > +++ b/net/ipv4/tcp_output.c > > > > @@ -969,7 +969,8 @@ static void tcp_internal_pacing(struct sock *sk, > > > > const struct sk_buff *skb) > > > > u64 len_ns; > > > > u32 rate; > > > > > > > > - if (!tcp_needs_internal_pacing(sk)) > > > > + if (!tcp_needs_internal_pacing(sk) || > > > > + hrtimer_is_queued(_sk(sk)->pacing_timer)) > > > > return; > > > > rate = sk->sk_pacing_rate; > > > > if (!rate || rate == ~0U) > > > > -- > > > > 1.8.3.1 > > > > > > > > > > Hi Jason. > > > > > > Please do not send patches that do not apply to current upstream trees. > > > > > > Instead, backport to your kernels the needed fixes. > > > > > > I suspect that you are not using a pristine linux kernel, but some > > > heavily modified one and something went wrong in your backports. > > > Do not ask us to spend time finding what went wrong. > > > > > > Thank you.
[PATCH v3 6/7] selftests/ftrace: Support ":tracer" suffix for requires
Add ":tracer" suffix support for the requires list, so that
the testcase can list up the required tracer (e.g. function)
to the requires list.
For example, if the testcase requires function_graph tracer,
it can write requires list as below instead of checking
available_tracers.
# requires: function_graph:tracer
Signed-off-by: Masami Hiramatsu
Reviewed-by: Tom Zanussi
---
Changes in v3:
- Update template according to the previous change in the series.
---
.../ftrace/test.d/ftrace/fgraph-filter-stack.tc|7 +--
.../ftrace/test.d/ftrace/fgraph-filter.tc |7 +--
.../ftrace/test.d/ftrace/func-filter-glob.tc |7 +--
.../test.d/ftrace/func-filter-notrace-pid.tc |7 +--
.../ftrace/test.d/ftrace/func-filter-pid.tc|7 +--
.../selftests/ftrace/test.d/ftrace/func_cpumask.tc |6 +-
.../ftrace/test.d/ftrace/func_profiler.tc |6 +-
tools/testing/selftests/ftrace/test.d/functions| 10 --
.../ftrace/test.d/kprobe/kprobe_ftrace.tc |4 +---
.../ftrace/test.d/preemptirq/irqsoff_tracer.tc |4 +---
tools/testing/selftests/ftrace/test.d/template |3 ++-
.../selftests/ftrace/test.d/tracer/wakeup.tc |6 +-
.../selftests/ftrace/test.d/tracer/wakeup_rt.tc|6 +-
13 files changed, 21 insertions(+), 59 deletions(-)
diff --git
a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
index 62af263fa75e..cf3ea42b12b0 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
@@ -1,16 +1,11 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function graph filters with stack tracer
-# requires: stack_trace set_ftrace_filter
+# requires: stack_trace set_ftrace_filter function_graph:tracer
# Make sure that function graph filtering works, and is not
# affected by other tracers enabled (like stack tracer)
-if ! grep -q function_graph available_tracers; then
-echo "no function graph tracer configured"
-exit_unsupported
-fi
-
do_reset() {
if [ -e /proc/sys/kernel/stack_tracer_enabled ]; then
echo 0 > /proc/sys/kernel/stack_tracer_enabled
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
index 56a86a2fc8ba..b3ccdaec2a61 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
@@ -1,15 +1,10 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function graph filters
-# requires: set_ftrace_filter
+# requires: set_ftrace_filter function_graph:tracer
# Make sure that function graph filtering works
-if ! grep -q function_graph available_tracers; then
-echo "no function graph tracer configured"
-exit_unsupported
-fi
-
fail() { # msg
echo $1
exit_fail
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
index ac3e4d35f181..4b994b6df5ac 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
@@ -1,15 +1,10 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function glob filters
-# requires: set_ftrace_filter
+# requires: set_ftrace_filter function:tracer
# Make sure that function glob matching filter works.
-if ! grep -q function available_tracers; then
-echo "no function tracer configured"
-exit_unsupported
-fi
-
disable_tracing
clear_trace
diff --git
a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
index b7e18d30104a..acb17ce543d2 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
@@ -1,16 +1,11 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function pid notrace filters
-# requires: set_ftrace_notrace_pid set_ftrace_filter
+# requires: set_ftrace_notrace_pid set_ftrace_filter function:tracer
# flags: instance
# Make sure that function pid matching filter with notrace works.
-if ! grep -q function available_tracers; then
-echo "no function tracer configured"
-exit_unsupported
-fi
-
do_function_fork=1
if [ ! -f options/function-fork ]; then
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
index 53ec48a92f39..9f0a9687c773 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
+++
[PATCH v3 4/7] selftests/ftrace: Convert required interface checks into requires list
Convert the required tracefs interface checking code with requires: list. Signed-off-by: Masami Hiramatsu Reviewed-by: Tom Zanussi --- Changes in v2: Fix trigger-onchange-action-hist.tc requires list. --- .../selftests/ftrace/test.d/00basic/snapshot.tc|3 +- .../selftests/ftrace/test.d/00basic/trace_pipe.tc |3 +- .../ftrace/test.d/direct/kprobe-direct.tc |6 +--- .../ftrace/test.d/dynevent/add_remove_kprobe.tc|3 +- .../ftrace/test.d/dynevent/add_remove_synth.tc |3 +- .../ftrace/test.d/dynevent/clear_select_events.tc |6 +--- .../ftrace/test.d/dynevent/generic_clear_event.tc |3 +- .../selftests/ftrace/test.d/event/event-enable.tc |6 +--- .../selftests/ftrace/test.d/event/event-no-pid.tc | 11 +-- .../selftests/ftrace/test.d/event/event-pid.tc | 11 +-- .../ftrace/test.d/event/subsystem-enable.tc|6 +--- .../ftrace/test.d/event/toplevel-enable.tc |6 +--- .../ftrace/test.d/ftrace/fgraph-filter-stack.tc|7 + .../test.d/ftrace/func-filter-notrace-pid.tc |6 +--- .../ftrace/test.d/ftrace/func-filter-pid.tc|6 +--- .../ftrace/test.d/ftrace/func_profile_stat.tc |3 +- .../ftrace/test.d/ftrace/func_profiler.tc |6 +--- .../ftrace/test.d/ftrace/func_stack_tracer.tc |6 +--- .../ftrace/test.d/ftrace/tracing-error-log.tc | 12 ++-- .../ftrace/test.d/instances/instance-event.tc |6 +--- .../selftests/ftrace/test.d/instances/instance.tc |6 +--- .../ftrace/test.d/kprobe/add_and_remove.tc |3 +- .../selftests/ftrace/test.d/kprobe/busy_check.tc |3 +- .../selftests/ftrace/test.d/kprobe/kprobe_args.tc |3 +- .../ftrace/test.d/kprobe/kprobe_args_comm.tc |3 +- .../ftrace/test.d/kprobe/kprobe_args_string.tc |3 +- .../ftrace/test.d/kprobe/kprobe_args_symbol.tc |3 +- .../ftrace/test.d/kprobe/kprobe_args_syntax.tc |3 +- .../ftrace/test.d/kprobe/kprobe_args_type.tc |3 +- .../ftrace/test.d/kprobe/kprobe_args_user.tc |3 +- .../ftrace/test.d/kprobe/kprobe_eventname.tc |3 +- .../ftrace/test.d/kprobe/kprobe_ftrace.tc |2 + .../ftrace/test.d/kprobe/kprobe_module.tc |3 +- .../ftrace/test.d/kprobe/kprobe_multiprobe.tc |3 +- .../ftrace/test.d/kprobe/kprobe_syntax_errors.tc |5 +-- .../ftrace/test.d/kprobe/kretprobe_args.tc |3 +- .../ftrace/test.d/kprobe/kretprobe_maxactive.tc|2 + .../ftrace/test.d/kprobe/multiple_kprobes.tc |3 +- .../selftests/ftrace/test.d/kprobe/probepoint.tc |3 +- .../selftests/ftrace/test.d/kprobe/profile.tc |3 +- .../ftrace/test.d/kprobe/uprobe_syntax_errors.tc |5 +-- .../inter-event/trigger-action-hist-xfail.tc | 11 +-- .../inter-event/trigger-field-variable-support.tc | 16 +- .../trigger-inter-event-combined-hist.tc | 16 +- .../inter-event/trigger-multi-actions-accept.tc| 16 +- .../inter-event/trigger-onchange-action-hist.tc|6 +--- .../inter-event/trigger-onmatch-action-hist.tc | 16 +- .../trigger-onmatch-onmax-action-hist.tc | 16 +- .../inter-event/trigger-onmax-action-hist.tc | 16 +- .../inter-event/trigger-snapshot-action-hist.tc| 16 +- .../trigger-synthetic-event-createremove.tc| 11 +-- .../inter-event/trigger-synthetic-event-syntax.tc | 11 +-- .../inter-event/trigger-trace-action-hist.tc | 16 +- .../ftrace/test.d/trigger/trigger-eventonoff.tc| 11 +-- .../ftrace/test.d/trigger/trigger-filter.tc| 11 +-- .../ftrace/test.d/trigger/trigger-hist-mod.tc | 16 +- .../test.d/trigger/trigger-hist-syntax-errors.tc | 18 +--- .../ftrace/test.d/trigger/trigger-hist.tc | 16 +- .../ftrace/test.d/trigger/trigger-multihist.tc | 16 +- .../ftrace/test.d/trigger/trigger-snapshot.tc | 16 +- .../ftrace/test.d/trigger/trigger-stacktrace.tc| 11 +-- .../test.d/trigger/trigger-trace-marker-hist.tc| 21 +- .../trigger/trigger-trace-marker-snapshot.tc | 21 +- .../trigger-trace-marker-synthetic-kernel.tc | 31 +--- .../trigger/trigger-trace-marker-synthetic.tc | 26 + .../ftrace/test.d/trigger/trigger-traceonoff.tc| 11 +-- 66 files changed, 68 insertions(+), 511 deletions(-) diff --git a/tools/testing/selftests/ftrace/test.d/00basic/snapshot.tc b/tools/testing/selftests/ftrace/test.d/00basic/snapshot.tc index 3b1f45e13a2e..13b4dabcf46e 100644 --- a/tools/testing/selftests/ftrace/test.d/00basic/snapshot.tc +++ b/tools/testing/selftests/ftrace/test.d/00basic/snapshot.tc @@ -1,9 +1,8 @@ #!/bin/sh # description: Snapshot and tracing setting +# requires: snapshot #
Re: [GIT PULL] xfs: new code for 5.8 (now with fixed To line)
On Tue, Jun 2, 2020 at 9:26 AM Darrick J. Wong wrote: > > fs/xfs/xfs_log_recover.c | 2561 ++-- > 102 files changed, 4244 insertions(+), 4817 deletions(-) Interestingly, the changes to that xfs_log_recover.c file really seem to break the default git diff algorithm (the linear-space Myers' algorithm) The default settings give me fs/xfs/xfs_log_recover.c | 2801 ++-- 102 files changed, 4366 insertions(+), 4939 deletions(-) which is not very close to yours. With the extra effort "--minimal" I get fs/xfs/xfs_log_recover.c | 2561 ++-- 102 files changed, 4246 insertions(+), 4819 deletions(-) but based on your output, I suspect you used "--patience", which gives that fs/xfs/xfs_log_recover.c | 2561 ++-- 102 files changed, 4244 insertions(+), 4817 deletions(-) output (the difference there wrt minimal came from fs/xfs/libxfs/xfs_symlink_remote.c). I'm used to seeing small differences in the line counts due to different diff heuristics, but that 250 line difference for "--patience" is more than you usually get. None of this matters, and I'm not at all suggesting you change any of your workflow. I'm just commenting because I was going "why am I not getting a matching diffstat", and while I'm used to seeing small differences from diff algorithms, that 240 line-count change was really a lot more than I normally encounter. Linus
[PATCH v3 7/7] selftests/ftrace: Support ":README" suffix for requires
Add ":README" suffix support for the requires list, so that
the testcase can list up the required string for README file
to the requires list.
Note that the required string is treated as a fixed string,
instead of regular expression. Also, the testcase can specify
a string containing spaces with quotes. E.g.
# requires: "place: [:]":README
Signed-off-by: Masami Hiramatsu
Reviewed-by: Tom Zanussi
---
Changes in v3:
- Update template according to the previous change in the series.
Changes in v2:
- Convert README check in kprobe/kprobe_args_user.tc
---
tools/testing/selftests/ftrace/ftracetest |3 ++-
.../ftrace/test.d/dynevent/add_remove_kprobe.tc|5 +
.../ftrace/test.d/dynevent/add_remove_synth.tc |4 +---
.../ftrace/test.d/dynevent/clear_select_events.tc |7 +--
.../ftrace/test.d/dynevent/generic_clear_event.tc |7 +--
tools/testing/selftests/ftrace/test.d/functions|8 +++-
.../ftrace/test.d/kprobe/kprobe_args_syntax.tc |4 +---
.../ftrace/test.d/kprobe/kprobe_args_type.tc |4 +---
.../ftrace/test.d/kprobe/kprobe_args_user.tc |3 +--
.../ftrace/test.d/kprobe/kprobe_multiprobe.tc |4 +---
.../ftrace/test.d/kprobe/kretprobe_maxactive.tc|4 +---
tools/testing/selftests/ftrace/test.d/template |4 +++-
.../inter-event/trigger-action-hist-xfail.tc |4 +---
.../inter-event/trigger-onchange-action-hist.tc|4 +---
.../inter-event/trigger-snapshot-action-hist.tc|6 +-
.../inter-event/trigger-trace-action-hist.tc |4 +---
16 files changed, 25 insertions(+), 50 deletions(-)
diff --git a/tools/testing/selftests/ftrace/ftracetest
b/tools/testing/selftests/ftrace/ftracetest
index cdf7940b6610..8ec1922e974e 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -269,7 +269,8 @@ testcase() { # testfile
checkreq() { # testfile
requires=`grep "^#[ \t]*requires:" $1 | cut -f2- -d:`
- check_requires $requires
+ # Use eval to pass quoted-patterns correctly.
+ eval check_requires "$requires"
}
test_on_instance() { # testfile
diff --git
a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_kprobe.tc
b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_kprobe.tc
index 1a8c56b197a8..68550f97d3c3 100644
--- a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_kprobe.tc
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_kprobe.tc
@@ -1,10 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: Generic dynamic event - add/remove kprobe events
-# requires: dynamic_events
-
-grep -q "place: \[:\]" README || exit_unsupported
-grep -q "place (kretprobe): \[:\]" README || exit_unsupported
+# requires: dynamic_events "place: [:]":README "place
(kretprobe): [:]":README
echo 0 > events/enable
echo > dynamic_events
diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_synth.tc
b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_synth.tc
index f5018b3afb39..2b94611e1a28 100644
--- a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_synth.tc
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_synth.tc
@@ -1,9 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: Generic dynamic event - add/remove synthetic events
-# requires: dynamic_events
-
-grep -q "s:\[synthetic/\]" README || exit_unsupported
+# requires: dynamic_events "s:[synthetic/]":README
echo 0 > events/enable
echo > dynamic_events
diff --git
a/tools/testing/selftests/ftrace/test.d/dynevent/clear_select_events.tc
b/tools/testing/selftests/ftrace/test.d/dynevent/clear_select_events.tc
index e2484445ddec..c969be9eb7de 100644
--- a/tools/testing/selftests/ftrace/test.d/dynevent/clear_select_events.tc
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/clear_select_events.tc
@@ -1,12 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: Generic dynamic event - selective clear (compatibility)
-# requires: dynamic_events kprobe_events synthetic_events
-
-grep -q "place: \[:\]" README || exit_unsupported
-grep -q "place (kretprobe): \[:\]" README || exit_unsupported
-
-grep -q "s:\[synthetic/\]" README || exit_unsupported
+# requires: dynamic_events kprobe_events synthetic_events "place:
[:]":README "place (kretprobe): [:]":README
"s:[synthetic/]":README
echo 0 > events/enable
echo > dynamic_events
diff --git
a/tools/testing/selftests/ftrace/test.d/dynevent/generic_clear_event.tc
b/tools/testing/selftests/ftrace/test.d/dynevent/generic_clear_event.tc
index e56cb60b4e56..16d543eaac88 100644
--- a/tools/testing/selftests/ftrace/test.d/dynevent/generic_clear_event.tc
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/generic_clear_event.tc
@@ -1,12 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: Generic dynamic event - generic clear event
-# requires: dynamic_events
-
-grep -q "place:
[PATCH v3 5/7] selftests/ftrace: Convert check_filter_file() with requires list
Since check_filter_file() is basically checking the filter
tracefs file, we can convert it into requires list.
Signed-off-by: Masami Hiramatsu
Reviewed-by: Tom Zanussi
---
.../ftrace/test.d/ftrace/fgraph-filter-stack.tc|4 +---
.../ftrace/test.d/ftrace/fgraph-filter.tc |3 +--
.../ftrace/test.d/ftrace/func-filter-glob.tc |3 +--
.../test.d/ftrace/func-filter-notrace-pid.tc |4 +---
.../ftrace/test.d/ftrace/func-filter-pid.tc|4 +---
.../ftrace/test.d/ftrace/func-filter-stacktrace.tc |3 +--
.../ftrace/test.d/ftrace/func_event_triggers.tc|7 +++
.../ftrace/test.d/ftrace/func_mod_trace.tc |3 +--
.../ftrace/test.d/ftrace/func_profiler.tc |4 +---
.../ftrace/test.d/ftrace/func_set_ftrace_file.tc |6 +++---
.../ftrace/test.d/ftrace/func_stack_tracer.tc |4 +---
.../test.d/ftrace/func_traceonoff_triggers.tc |6 +++---
tools/testing/selftests/ftrace/test.d/functions|7 ---
.../ftrace/test.d/kprobe/kprobe_ftrace.tc |4 +---
14 files changed, 19 insertions(+), 43 deletions(-)
diff --git
a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
index 8dd22561d5b0..62af263fa75e 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
@@ -1,7 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function graph filters with stack tracer
-# requires: stack_trace
+# requires: stack_trace set_ftrace_filter
# Make sure that function graph filtering works, and is not
# affected by other tracers enabled (like stack tracer)
@@ -11,8 +11,6 @@ if ! grep -q function_graph available_tracers; then
exit_unsupported
fi
-check_filter_file set_ftrace_filter
-
do_reset() {
if [ -e /proc/sys/kernel/stack_tracer_enabled ]; then
echo 0 > /proc/sys/kernel/stack_tracer_enabled
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
index d610f47edd90..56a86a2fc8ba 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
@@ -1,6 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function graph filters
+# requires: set_ftrace_filter
# Make sure that function graph filtering works
@@ -9,8 +10,6 @@ if ! grep -q function_graph available_tracers; then
exit_unsupported
fi
-check_filter_file set_ftrace_filter
-
fail() { # msg
echo $1
exit_fail
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
index 28936f434ee5..ac3e4d35f181 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
@@ -1,6 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function glob filters
+# requires: set_ftrace_filter
# Make sure that function glob matching filter works.
@@ -9,8 +10,6 @@ if ! grep -q function available_tracers; then
exit_unsupported
fi
-check_filter_file set_ftrace_filter
-
disable_tracing
clear_trace
diff --git
a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
index 799cd1b9c42c..b7e18d30104a 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
@@ -1,7 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function pid notrace filters
-# requires: set_ftrace_notrace_pid
+# requires: set_ftrace_notrace_pid set_ftrace_filter
# flags: instance
# Make sure that function pid matching filter with notrace works.
@@ -11,8 +11,6 @@ if ! grep -q function available_tracers; then
exit_unsupported
fi
-check_filter_file set_ftrace_filter
-
do_function_fork=1
if [ ! -f options/function-fork ]; then
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
index 9497031913bb..53ec48a92f39 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
@@ -1,7 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: ftrace - function pid filters
-# requires: set_ftrace_pid
+# requires: set_ftrace_pid set_ftrace_filter
# flags: instance
# Make sure that function pid matching filter works.
@@ -12,8 +12,6 @@ if ! grep -q function available_tracers; then
exit_unsupported
fi
-check_filter_file set_ftrace_filter
-
[PATCH v3 2/7] selftests/ftrace: Return unsupported for the unconfigured features
As same as other test cases, return unsupported if kprobe_events or argument access feature are not found. There can be a new arch which does not port those features yet, and an older kernel which doesn't support it. Those can not enable the features. Signed-off-by: Masami Hiramatsu Reviewed-by: Tom Zanussi --- .../ftrace/test.d/direct/kprobe-direct.tc |2 +- .../ftrace/test.d/kprobe/kprobe_args_user.tc |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/ftrace/test.d/direct/kprobe-direct.tc b/tools/testing/selftests/ftrace/test.d/direct/kprobe-direct.tc index 801ecb63e84c..e95b744b23e4 100644 --- a/tools/testing/selftests/ftrace/test.d/direct/kprobe-direct.tc +++ b/tools/testing/selftests/ftrace/test.d/direct/kprobe-direct.tc @@ -10,7 +10,7 @@ fi if [ ! -f kprobe_events ]; then echo "No kprobe_events file -please build CONFIG_KPROBE_EVENTS" - exit_unresolved; + exit_unsupported; fi echo "Let the module run a little" diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_user.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_user.tc index 0f60087583d8..b41471f301ab 100644 --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_user.tc +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_user.tc @@ -4,7 +4,7 @@ [ -f kprobe_events ] || exit_unsupported # this is configurable -grep -q '\$arg' README || exit_unresolved # depends on arch +grep -q '\$arg' README || exit_unsupported # depends on arch grep -A10 "fetcharg:" README | grep -q 'ustring' || exit_unsupported grep -A10 "fetcharg:" README | grep -q '\[u\]' || exit_unsupported
[PATCH v3 1/7] selftests/ftrace: Allow ":" in description
Allow ":" in the description line. Currently if there is ":"
in the test description line, the description is cut at that
point, but that was unintended.
Signed-off-by: Masami Hiramatsu
Reviewed-by: Tom Zanussi
---
tools/testing/selftests/ftrace/ftracetest |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/ftracetest
b/tools/testing/selftests/ftrace/ftracetest
index a4605b5ee66d..d3f6652311ef 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -263,7 +263,7 @@ CASENO=0
testcase() { # testfile
CASENO=$((CASENO+1))
- desc=`grep "^#[ \t]*description:" $1 | cut -f2 -d:`
+ desc=`grep "^#[ \t]*description:" $1 | cut -f2- -d:`
prlog -n "[$CASENO]$INSTANCE$desc"
}
[PATCH v3 3/7] selftests/ftrace: Add "requires:" list support
Introduce "requires:" list to check required ftrace interface
for each test. This will simplify the interface checking code
and unify the error message. Another good point is, it can
skip the ftrace initializing.
Note that this requires list must be written as a shell
comment.
Signed-off-by: Masami Hiramatsu
Reviewed-by: Tom Zanussi
---
Changes in v3:
- Fixes a comment in template file.
---
tools/testing/selftests/ftrace/ftracetest |8 +++-
tools/testing/selftests/ftrace/test.d/functions |9 +
tools/testing/selftests/ftrace/test.d/template |1 +
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/ftracetest
b/tools/testing/selftests/ftrace/ftracetest
index d3f6652311ef..cdf7940b6610 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -267,6 +267,11 @@ testcase() { # testfile
prlog -n "[$CASENO]$INSTANCE$desc"
}
+checkreq() { # testfile
+ requires=`grep "^#[ \t]*requires:" $1 | cut -f2- -d:`
+ check_requires $requires
+}
+
test_on_instance() { # testfile
grep -q "^#[ \t]*flags:.*instance" $1
}
@@ -356,7 +361,8 @@ trap 'SIG_RESULT=$XFAIL' $SIG_XFAIL
__run_test() { # testfile
# setup PID and PPID, $$ is not updated.
- (cd $TRACING_DIR; read PID _ < /proc/self/stat; set -e; set -x;
initialize_ftrace; . $1)
+ (cd $TRACING_DIR; read PID _ < /proc/self/stat; set -e; set -x;
+ checkreq $1; initialize_ftrace; . $1)
[ $? -ne 0 ] && kill -s $SIG_FAIL $SIG_PID
}
diff --git a/tools/testing/selftests/ftrace/test.d/functions
b/tools/testing/selftests/ftrace/test.d/functions
index 697c77ef2e2b..5100eb1ada0f 100644
--- a/tools/testing/selftests/ftrace/test.d/functions
+++ b/tools/testing/selftests/ftrace/test.d/functions
@@ -113,6 +113,15 @@ initialize_ftrace() { # Reset ftrace to initial-state
enable_tracing
}
+check_requires() { # Check required files
+for i in $* ; do
+if [ ! -e $i ]; then
+echo "Required feature interface $i doesn't exist."
+exit_unsupported
+fi
+done
+}
+
LOCALHOST=127.0.0.1
yield() {
diff --git a/tools/testing/selftests/ftrace/test.d/template
b/tools/testing/selftests/ftrace/test.d/template
index e1a5d14c4eaf..611423c4e75f 100644
--- a/tools/testing/selftests/ftrace/test.d/template
+++ b/tools/testing/selftests/ftrace/test.d/template
@@ -1,6 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: %HERE DESCRIBE WHAT THIS DOES%
+# requires: %HERE LIST THE REQUIRED FILES%
# you have to add ".tc" extention for your testcase file
# Note that all tests are run with "errexit" option.
