Re: [PATCH] arch: unexport asm/shmparam.h for all architectures
Hi Yamada-san,
On Tue, Jan 8, 2019 at 12:41 AM Masahiro Yamada
wrote:
> Most architectures do not export shmparam.h to user-space.
>
> $ find arch -name shmparam.h | sort
> arch/alpha/include/asm/shmparam.h
> arch/arc/include/asm/shmparam.h
> arch/arm64/include/asm/shmparam.h
> arch/arm/include/asm/shmparam.h
> arch/csky/include/asm/shmparam.h
> arch/ia64/include/asm/shmparam.h
> arch/mips/include/asm/shmparam.h
> arch/nds32/include/asm/shmparam.h
> arch/nios2/include/asm/shmparam.h
> arch/parisc/include/asm/shmparam.h
> arch/powerpc/include/asm/shmparam.h
> arch/s390/include/asm/shmparam.h
> arch/sh/include/asm/shmparam.h
> arch/sparc/include/asm/shmparam.h
> arch/x86/include/asm/shmparam.h
> arch/xtensa/include/asm/shmparam.h
>
> Strangely, some users of the asm-generic wrapper export shmparam.h
>
> $ git grep 'generic-y += shmparam.h'
> arch/c6x/include/uapi/asm/Kbuild:generic-y += shmparam.h
> arch/h8300/include/uapi/asm/Kbuild:generic-y += shmparam.h
> arch/hexagon/include/uapi/asm/Kbuild:generic-y += shmparam.h
> arch/m68k/include/uapi/asm/Kbuild:generic-y += shmparam.h
> arch/microblaze/include/uapi/asm/Kbuild:generic-y += shmparam.h
> arch/openrisc/include/uapi/asm/Kbuild:generic-y += shmparam.h
> arch/riscv/include/asm/Kbuild:generic-y += shmparam.h
> arch/unicore32/include/uapi/asm/Kbuild:generic-y += shmparam.h
>
> The newly added riscv correctly creates the asm-generic wrapper
> in the kernel space, but the others (c6x, h8300, hexagon, m68k,
> microblaze, openrisc, unicore32) create the one in the uapi directory.
>
> Digging into the git history, now I guess fcc8487d477a ("uapi:
> export all headers under uapi directories") was the misconversion.
> Prior to that commit, no architecture exported to shmparam.h
> As its commit description said, that commit exported shmparam.h
> for c6x, h8300, hexagon, m68k, openrisc, unicore32.
>
> 83f0124ad81e ("microblaze: remove asm-generic wrapper headers")
> accidentally exported shmparam.h for microblaze.
>
> This commit unexports shmparam.h for those architectures.
>
> There is no more reason to export include/uapi/asm-generic/shmparam.h,
> so it has been moved to include/asm-generic/shmparam.h
>
> Signed-off-by: Masahiro Yamada
Thanks for your patch!
include/uapi/asm-generic/shmparam.h contains a single definition:
#define SHMLBA PAGE_SIZE /* attach addr a multiple of this */
So this definition is not used by userspace?
Note that it is refered to by include/uapi/linux/shm.h, albeit in a comment:
#define SHM_RND 02 /* round attach address to SHMLBA
boundary */
Glibc provides its own definition in /usr/include/x86_64-linux-gnu/bits/shm.h
#define SHMLBA (__getpagesize ())
So probably this is safe.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 4.9 00/71] 4.9.149-stable review
On Mon, 7 Jan 2019 at 21:23, Greg Kroah-Hartman wrote: > > On Mon, Jan 07, 2019 at 01:32:29PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.149 release. > > There are 71 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 Wed Jan 9 10:53:04 UTC 2019. > > 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.9.149-rc1.gz > > Ok, hopefully this is better, at least it builds on x86-64 properly > now, -rc3: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.149-rc3.gz Test results report of 4.9.149-rc3, Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.9.149-rc3 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: d1d800b1ed7ab74a26df74ce1f95d5f49f36d717 git describe: v4.9.148-69-gd1d800b1ed7a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.148-69-gd1d800b1ed7a No regressions (compared to build v4.9.148) No fixes (compared to build v4.9.148) Ran 19740 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [RFC v2 0/6] x86: dynamic indirect branch promotion
On 7/01/19 6:32 PM, Peter Zijlstra wrote: > On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote: >> Nadav Amit writes: >>> >>> - Do we use periodic learning or not? Josh suggested to reconfigure the >>> branches whenever a new target is found. However, I do not know at >>> this time how to do learning efficiently, without making learning much >>> more expensive. >> >> FWIW frequent patching will likely completely break perf Processor Trace >> decoding, which needs a somewhat stable kernel text image to decode the >> traces generated by the CPU. Right now it relies on kcore dumped after >> the trace usually being stable because jumplabel changes happen only >> infrequently. But if you start patching frequently this assumption will >> break. >> >> You would either need a way to turn this off, or provide >> updates for every change to the trace, so that the decoder can >> keep track. > > I'm thining it would be entirely possible to create and feed text_poke > events into the regular (!aux) buffer which can be timestamp correlated > to the PT data. To rebuild kernel text from such events would require a starting point. What is the starting point? The problem with kcore is that people can deconfig it without realising it is needed to enable the tracing of kernel self-modifying code. It would be nice if it was all tied together, so that if someone selects the ability to trace kernel self-modifying code, then all the bits needed are also selected. Perhaps we should expose another ELF image that contains only kernel executable code, and take the opportunity to put the symbols in it also. Also what about BPF jitted code? Will it always fit in an event? I was thinking of trying to add a way to prevent temporarily the unload of modules or jitted code, which would be a good-enough solution for now.
Re: [PATCH v2 1/2] mm: add probe_user_read()
On Tue, Jan 08, 2019 at 07:37:44AM +, Christophe Leroy wrote:
> In powerpc code, there are several places implementing safe
> access to user data. This is sometimes implemented using
> probe_kernel_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a pagefault_disable()/enable()
> pair, etc. :
> show_user_instructions()
> bad_stack_expansion()
> p9_hmi_special_emu()
> fsl_pci_mcheck_exception()
> read_user_stack_64()
> read_user_stack_32() on PPC64
> read_user_stack_32() on PPC32
> power_pmu_bhrb_to()
>
> In the same spirit as probe_kernel_read(), this patch adds
> probe_user_read().
>
> probe_user_read() does the same as probe_kernel_read() but
> first checks that it is really a user address.
>
> Signed-off-by: Christophe Leroy
> ---
> v2: Added "Returns:" comment and removed probe_user_address()
>
> Changes since RFC: Made a static inline function instead of weak function as
> recommended by Kees.
>
> include/linux/uaccess.h | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> index 37b226e8df13..07f4f0ed69bc 100644
> --- a/include/linux/uaccess.h
> +++ b/include/linux/uaccess.h
> @@ -263,6 +263,40 @@ extern long strncpy_from_unsafe(char *dst, const void
> *unsafe_addr, long count);
> #define probe_kernel_address(addr, retval) \
> probe_kernel_read(, addr, sizeof(retval))
>
> +/**
> + * probe_user_read(): safely attempt to read from a user location
> + * @dst: pointer to the buffer that shall take the data
> + * @src: address to read from
> + * @size: size of the data chunk
> + *
> + * Returns: 0 on success, -EFAULT on error.
Nit: please put the "Returns:" comment after the description, otherwise
kernel-doc considers it a part of the elaborate description.
> + *
> + * Safely read from address @src to the buffer at @dst. If a kernel fault
> + * happens, handle that and return -EFAULT.
> + *
> + * We ensure that the copy_from_user is executed in atomic context so that
> + * do_page_fault() doesn't attempt to take mmap_sem. This makes
> + * probe_user_read() suitable for use within regions where the caller
> + * already holds mmap_sem, or other locks which nest inside mmap_sem.
> + */
> +
> +#ifndef probe_user_read
> +static __always_inline long probe_user_read(void *dst, const void __user
> *src,
> + size_t size)
> +{
> + long ret;
> +
> + if (!access_ok(src, size))
> + return -EFAULT;
> +
> + pagefault_disable();
> + ret = __copy_from_user_inatomic(dst, src, size);
> + pagefault_enable();
> +
> + return ret ? -EFAULT : 0;
> +}
> +#endif
> +
> #ifndef user_access_begin
> #define user_access_begin(ptr,len) access_ok(ptr, len)
> #define user_access_end() do { } while (0)
> --
> 2.13.3
>
--
Sincerely yours,
Mike.
Re: [PATCH v4 05/10] KVM/x86: expose MSR_IA32_PERF_CAPABILITIES to the guest
On 01/08/2019 02:48 AM, Jim Mattson wrote: On Mon, Jan 7, 2019 at 10:20 AM Andi Kleen wrote: The issue is compatibility. Prior to your change, reading this MSR from a VM would raise #GP. After your change, it won't. That means that if you have a VM migrating between hosts with kernel versions before and after this change, the results will be inconsistent. In the No it will not be. All Linux kernel uses of this MSR are guarded by a CPUID check. Linux usage is irrelevant to the architected behavior of the virtual CPU. According to volume 4 of the SDM, this MSR is only supported when CPUID.01H:ECX.PDCM [bit 15] is set. Therefore, kvm should raise #GP whenever a guest tries to read this MSR and the guest's CPUID.01H:ECX.PDCM [bit 15] is clear. Probably one more check would be better: if (!boot_cpu_has(X86_FEATURE_PDCM) || !guest_cpuid_has(vcpu, X86_FEATURE_PDCM)) return 1; (host isn't expected to read this MSR when PDCM is not supported by the guest, so don't have "!msr_info->host_initiate" added to above) Best, Wei
Re: [PATCH 4.20 000/145] 4.20.1-stable review
On Mon, Jan 07, 2019 at 03:36:48PM -0700, shuah wrote: > On 1/7/19 5:30 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.20.1 release. > > There are 145 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 Wed Jan 9 10:43:39 UTC 2019. > > 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.20.1-rc1.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.20.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.20 000/145] 4.20.1-stable review
On Mon, Jan 07, 2019 at 01:17:49PM -0800, Guenter Roeck wrote: > On Mon, Jan 07, 2019 at 01:30:37PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.20.1 release. > > There are 145 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 Wed Jan 9 10:43:39 UTC 2019. > > Anything received after that time might be too late. > > > > Build results: > total: 158 pass: 154 fail: 4 > Failed builds: > arm:allmodconfig > mips:allmodconfig > parisc:allmodconfig > xtensa:allmodconfig > Qemu test results: > total: 332 pass: 327 fail: 5 > Failed tests: > mipsel64:fuloong2e_defconfig:fulong2e:rootfs > sh:rts7751r2dplus_defconfig:nvme:rootfs > sh:rts7751r2dplus_defconfig:usb:rootfs > sh:rts7751r2dplus_defconfig:usb-hub:rootfs > sh:rts7751r2dplus_defconfig:usb-ohci:rootfs > > --- > Build errors: > > ERROR: "__bad_cmpxchg" [drivers/spi/spi-bcm2835.ko] undefined! Found the fix for this thanks. > Qemu errors: > > Building mipsel64:fuloong2e_defconfig:fulong2e:rootfs ... failed > > Error log: > In file included from ./arch/mips/include/asm/mmzone.h:10:0, > from ./arch/mips/include/asm/r4kcache.h:23, >from arch/mips/mm/c-r4k.c:33: > ./arch/mips/include/asm/mach-loongson64/mmzone.h:48:0: error: "NODE_DATA" > redefined This one is odd, let me dig... thanks, greg k-h
Re: [PATCH] parisc: remove meaningless ccflags-y in arch/parisc/boot/Makefile
On 08.01.19 07:45, Masahiro Yamada wrote: > This ccflags-y is never used because arch/parisc/boot/Makefile > only contains objcopy and install targets. > > Signed-off-by: Masahiro Yamada I've added this patch to the parisc for-next tree. Thanks, Helge > --- > > arch/parisc/boot/Makefile | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/arch/parisc/boot/Makefile b/arch/parisc/boot/Makefile > index cad68a5..41cce07 100644 > --- a/arch/parisc/boot/Makefile > +++ b/arch/parisc/boot/Makefile > @@ -2,12 +2,6 @@ > # Makefile for the linux parisc-specific parts of the boot image creator. > # > > -COMPILE_VERSION := __linux_compile_version_id__`hostname | \ > - tr -c '[0-9A-Za-z]' '_'`__`date | \ > - tr -c '[0-9A-Za-z]' '_'`_t > - > -ccflags-y := -DCOMPILE_VERSION=$(COMPILE_VERSION) -gstabs -I. > - > targets := image > targets += bzImage > subdir- := compressed >
Re: [PATCH] parisc: replace oops_in_progress manipulation with bust_spinlocks()
On 07.01.19 10:56, Sergey Senozhatsky wrote:
> Use bust_spinlocks() function to set oops_in_progress.
>
> Signed-off-by: Sergey Senozhatsky
I've added this patch to the parisc for-next tree.
Thanks,
Helge
> ---
> arch/parisc/kernel/traps.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
> index 472a818e8c17..7e1ccafadf57 100644
> --- a/arch/parisc/kernel/traps.c
> +++ b/arch/parisc/kernel/traps.c
> @@ -218,7 +218,7 @@ void die_if_kernel(char *str, struct pt_regs *regs, long
> err)
> return;
> }
>
> - oops_in_progress = 1;
> + bust_spinlocks(1);
>
> oops_enter();
>
> @@ -396,7 +396,7 @@ void parisc_terminate(char *msg, struct pt_regs *regs,
> int code, unsigned long o
> {
> static DEFINE_SPINLOCK(terminate_lock);
>
> - oops_in_progress = 1;
> + bust_spinlocks(1);
>
> set_eiem(0);
> local_irq_disable();
>
Re: [PATCH 4.14 002/101] net: core: Fix Spectre v1 vulnerability
On Mon, Jan 07, 2019 at 04:36:26PM -0800, David Miller wrote:
> From: Sudip Mukherjee
> Date: Mon, 7 Jan 2019 21:13:06 +
>
> > Hi Greg,
> >
> > On Mon, Jan 7, 2019 at 1:00 PM Greg Kroah-Hartman
> > wrote:
> >>
> >> 4.14-stable review patch. If anyone has any objections, please let me
> >> know.
> >>
> >> --
> >>
> >> From: "Gustavo A. R. Silva"
> >>
> >> [ Upstream commit 50d5258634aee2e62832aa086d2fb0de00e72b91 ]
> >
> > This has been reverted upstream by f2ab95814103 ("net: Revert recent
> > Spectre-v1 patches.")
>
> Greg please drop this too.
>
> Thanks Sudip for spotting this.
Now dropped from everywhere, thanks.
greg k-h
Re: [PATCH 4.14 001/101] phonet: af_phonet: Fix Spectre v1 vulnerability
On Mon, Jan 07, 2019 at 04:36:15PM -0800, David Miller wrote:
> From: Sudip Mukherjee
> Date: Mon, 7 Jan 2019 21:11:33 +
>
> > Hi Greg,
> >
> > On Mon, Jan 7, 2019 at 1:16 PM Greg Kroah-Hartman
> > wrote:
> >>
> >> 4.14-stable review patch. If anyone has any objections, please let me
> >> know.
> >>
> >> --
> >>
> >> From: "Gustavo A. R. Silva"
> >>
> >> [ Upstream commit d686026b1e6ed4ea27d630d8f54f9a694db088b2 ]
> >
> > This has been reverted upstream by f2ab95814103 ("net: Revert recent
> > Spectre-v1 patches.")
>
> Indeed, Greg please drop this.
Now dropped from everywhere, thanks.
greg k-h
Re: [PATCH] ARM: mach-s3c24xx: Fix boolean expressions in osiris_dvs_notify
On Mon, 7 Jan 2019 at 21:33, Gustavo A. R. Silva wrote:
>
> Hi Krzysztof,
>
> On 1/7/19 1:43 PM, Krzysztof Kozlowski wrote:
> > On Thu, Jan 03, 2019 at 02:14:08PM -0600, Gustavo A. R. Silva wrote:
> >> Fix boolean expressions by using logical AND operator '&&'
> >> instead of bitwise operator '&'.
> >>
> >> This issue was detected with the help of Coccinelle.
> >>
> >> Fixes: 4fa084af28ca ("ARM: OSIRIS: DVS (Dynamic Voltage Scaling) supoort.")
> >> Cc: sta...@vger.kernel.org
> >> Signed-off-by: Gustavo A. R. Silva
> >> ---
> >> arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 8
> >
> > Thanks, applied with fixing up -Wparentheses warning. I think you should
> > update your GCC.
> >
>
> Thanks for that.
>
> I wonder if you could take these too:
>
> https://lore.kernel.org/lkml/418252fcd77472413ce15ac3df167e448a4defe9.1546667177.git.gust...@embeddedor.com/
> https://lore.kernel.org/lkml/2795c5ba939fe23dda6c86135d56e68433f7d68a.1546667177.git.gust...@embeddedor.com/
Can't do. I am maintainer only for ARM/Samsung platform and these are
for Integrator.
Best regards,
Krzysztof
[PATCH] Input: elan_i2c - Add auto recovery handle for absolute mode
Sometimes touchpad will be reset to mouse mode unexpectedly. And cause invalid report detection. I add a mouse report detection and send mode-switching command again. Signed-off-by: KT Liao --- drivers/input/mouse/elan_i2c_core.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c index 2690a4b..56b5766 100644 --- a/drivers/input/mouse/elan_i2c_core.c +++ b/drivers/input/mouse/elan_i2c_core.c @@ -51,6 +51,7 @@ #define ETP_MAX_FINGERS5 #define ETP_FINGER_DATA_LEN5 +#define ETP_MOUSE_REPORT_ID0x01 #define ETP_REPORT_ID 0x5D #define ETP_TP_REPORT_ID 0x5E #define ETP_REPORT_ID_OFFSET 2 @@ -988,6 +989,14 @@ static irqreturn_t elan_isr(int irq, void *dev_id) case ETP_TP_REPORT_ID: elan_report_trackpoint(data, report); break; + case ETP_MOUSE_REPORT_ID: + dev_info(dev, "Mouse report now, mode switch again\n"); + data->mode |= ETP_ENABLE_ABS; + error = data->ops->set_mode(data->client, data->mode); + if (error) + dev_err(dev, "fail to switch to absolute mode(%d)\n", + error); + break; default: dev_err(dev, "invalid report id data (%x)\n", report[ETP_REPORT_ID_OFFSET]); -- 2.7.4
Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399
Sent from my iPad > On Jan 8, 2019, at 2:33 PM, Tomasz Figa wrote: > >> On Mon, Jan 7, 2019 at 2:30 AM Ayaka wrote: >> >> Hello Ezequiel >> >> Sent from my iPad >> On Jan 7, 2019, at 1:21 AM, Ezequiel Garcia wrote: On Sun, 6 Jan 2019 at 13:16, Ayaka wrote: Sent from my iPad > On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia > wrote: > > On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote: >>> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia >>> wrote: >>> >>> Hi Randy, >>> >>> Thanks a lot for this patches. They are really useful >>> to provide more insight into the VPU hardware. >>> >>> This change will make the vpu encoder and vpu decoder >>> completely independent, can they really work in parallel? >> As I said it depends on the platform, but with this patch, the user >> space would think they can work at the same time. > > > I think there is some confusion. > > The devicetree is one thing: it is a hardware representation, > a way to describe the hardware, for the kernel/bootloader to > parse. > > The userspace view will depend on the driver implementation. > > The current devicetree and driver (without your patches), > model the VPU as a single piece of hardware, exposing a decoder > and an encoder. > > The V4L driver will then create two video devices, i.e. /dev/videoX > and /dev/videoY. So userspace sees an independent view of the > devices. > I knew that, the problem is that the driver should not always create a decoder and encoder pair, they may not exist at some platforms, even some platforms doesn’t have a encoder. You may have a look on the rk3328 I post on the first email as example. >>> >>> That is correct. But that still doesn't tackle my question: is the >>> hardware able to run a decoding and an encoding job in parallel? >>> >> For rk3328, yes, you see I didn’t draw them in the same box. >>> If not, then it's wrong to describe them as independent entities. >>> > However, they are internally connected, and thus we can > easily avoid two jobs running in parallel. > That is what the mpp service did in my patches, handing the relationship between each devices. And it is not a easy work, maybe a 4k decoder would be blocked by another high frame rate encoding work or another decoder session. The vendor kernel have more worry about this, but not in this version. >>> >>> Right. That is one way to design it. Another way is having a single >>> devicetree node for the VPU encoder/decoder "complex". >> No, you can’t assume which one is in the combo group, it can be various. you >> see, in the rk3328, the vdpu is paired with an avs+ decoder. That is why I >> use a virtual device standing for scheduler. > > First of all, thanks for all the input. Having more understanding of > the hardware and shortcomings of the current V4L2 APIs is really > important to let us further evolve the API and make sure that it works > for further use cases. I replied the problems of the v4l2 request API in the other threads. I am waiting the feedback from those threads. > > As for the Device Tree itself, it doesn't always describe the hardware > in 100%. Also please note the merged device tree for the video codec won’t fix for most of the rockchip platform. > Most of the time it's just the necessary information to > choose and instantiate the right drivers and bind to the right > hardware resources. The information on which hardware instances on the > SoC can work independently can of course be described in DT (e.g. by > sub-nodes of a video-codec complex OR a set of phandles, e.g. > rockchip,shared-instances), but it's also perfectly fine to defer this > kind of knowledge to the drivers themselves. I wish there is a common mechanism for those device would share some resources. Although there is a multiple functions framework, but that is not I want. They are multiple functions but they are used at the same time not separately. > > Best regards, > Tomasz
Re: [PATCH 4.14 090/101] MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3
On Mon, Jan 07, 2019 at 09:17:22PM +, Sudip Mukherjee wrote:
> Hi Greg,
>
> On Mon, Jan 7, 2019 at 1:14 PM Greg Kroah-Hartman
> wrote:
> >
> > 4.14-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Huacai Chen
> >
> > commit bb53fdf395eed103f85061bfff3b116cee123895 upstream.
>
> This has been fixed by 66a4059ba72c ("MIPS: Only include mmzone.h when
> CONFIG_NEED_MULTIPLE_NODES=y")
That commit is already in the queues for 4.14, 4.19, and 4.20, so all
should be fine, right?
thanks,
greg k-h
[PATCH v2 2/2] powerpc: use probe_user_read()
Instead of opencoding, use probe_user_read() to failessly
read a user location.
Signed-off-by: Christophe Leroy
---
v2: Using probe_user_read() instead of probe_user_address()
arch/powerpc/kernel/process.c | 12 +---
arch/powerpc/mm/fault.c | 6 +-
arch/powerpc/perf/callchain.c | 20 +++-
arch/powerpc/perf/core-book3s.c | 8 +---
arch/powerpc/sysdev/fsl_pci.c | 10 --
5 files changed, 10 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index ce393df243aa..6a4b59d574c2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1298,16 +1298,6 @@ void show_user_instructions(struct pt_regs *regs)
pc = regs->nip - (NR_INSN_TO_PRINT * 3 / 4 * sizeof(int));
- /*
-* Make sure the NIP points at userspace, not kernel text/data or
-* elsewhere.
-*/
- if (!__access_ok(pc, NR_INSN_TO_PRINT * sizeof(int), USER_DS)) {
- pr_info("%s[%d]: Bad NIP, not dumping instructions.\n",
- current->comm, current->pid);
- return;
- }
-
seq_buf_init(, buf, sizeof(buf));
while (n) {
@@ -1318,7 +1308,7 @@ void show_user_instructions(struct pt_regs *regs)
for (i = 0; i < 8 && n; i++, n--, pc += sizeof(int)) {
int instr;
- if (probe_kernel_address((const void *)pc, instr)) {
+ if (probe_user_read(, (void __user *)pc,
sizeof(instr))) {
seq_buf_printf(, " ");
continue;
}
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 887f11bcf330..ec74305fa330 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -276,12 +276,8 @@ static bool bad_stack_expansion(struct pt_regs *regs,
unsigned long address,
if ((flags & FAULT_FLAG_WRITE) && (flags & FAULT_FLAG_USER) &&
access_ok(nip, sizeof(*nip))) {
unsigned int inst;
- int res;
- pagefault_disable();
- res = __get_user_inatomic(inst, nip);
- pagefault_enable();
- if (!res)
+ if (!probe_user_read(, nip, sizeof(inst)))
return !store_updates_sp(inst);
*must_retry = true;
}
diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
index 0af051a1974e..0680efb2237b 100644
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -159,12 +159,8 @@ static int read_user_stack_64(unsigned long __user *ptr,
unsigned long *ret)
((unsigned long)ptr & 7))
return -EFAULT;
- pagefault_disable();
- if (!__get_user_inatomic(*ret, ptr)) {
- pagefault_enable();
+ if (!probe_user_read(ret, ptr, sizeof(*ret)))
return 0;
- }
- pagefault_enable();
return read_user_stack_slow(ptr, ret, 8);
}
@@ -175,12 +171,8 @@ static int read_user_stack_32(unsigned int __user *ptr,
unsigned int *ret)
((unsigned long)ptr & 3))
return -EFAULT;
- pagefault_disable();
- if (!__get_user_inatomic(*ret, ptr)) {
- pagefault_enable();
+ if (!probe_user_read(ret, ptr, sizeof(*ret)))
return 0;
- }
- pagefault_enable();
return read_user_stack_slow(ptr, ret, 4);
}
@@ -307,17 +299,11 @@ static inline int current_is_64bit(void)
*/
static int read_user_stack_32(unsigned int __user *ptr, unsigned int *ret)
{
- int rc;
-
if ((unsigned long)ptr > TASK_SIZE - sizeof(unsigned int) ||
((unsigned long)ptr & 3))
return -EFAULT;
- pagefault_disable();
- rc = __get_user_inatomic(*ret, ptr);
- pagefault_enable();
-
- return rc;
+ return probe_user_read(ret, ptr, sizeof(*ret));
}
static inline void perf_callchain_user_64(struct perf_callchain_entry_ctx
*entry,
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index b0723002a396..4b64ddf0db68 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -416,7 +416,6 @@ static void power_pmu_sched_task(struct perf_event_context
*ctx, bool sched_in)
static __u64 power_pmu_bhrb_to(u64 addr)
{
unsigned int instr;
- int ret;
__u64 target;
if (is_kernel_addr(addr)) {
@@ -427,13 +426,8 @@ static __u64 power_pmu_bhrb_to(u64 addr)
}
/* Userspace: need copy instruction here then translate it */
- pagefault_disable();
- ret = __get_user_inatomic(instr, (unsigned int __user *)addr);
- if (ret) {
- pagefault_enable();
+ if
[PATCH v2 1/2] mm: add probe_user_read()
In powerpc code, there are several places implementing safe
access to user data. This is sometimes implemented using
probe_kernel_address() with additional access_ok() verification,
sometimes with get_user() enclosed in a pagefault_disable()/enable()
pair, etc. :
show_user_instructions()
bad_stack_expansion()
p9_hmi_special_emu()
fsl_pci_mcheck_exception()
read_user_stack_64()
read_user_stack_32() on PPC64
read_user_stack_32() on PPC32
power_pmu_bhrb_to()
In the same spirit as probe_kernel_read(), this patch adds
probe_user_read().
probe_user_read() does the same as probe_kernel_read() but
first checks that it is really a user address.
Signed-off-by: Christophe Leroy
---
v2: Added "Returns:" comment and removed probe_user_address()
Changes since RFC: Made a static inline function instead of weak function as
recommended by Kees.
include/linux/uaccess.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 37b226e8df13..07f4f0ed69bc 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -263,6 +263,40 @@ extern long strncpy_from_unsafe(char *dst, const void
*unsafe_addr, long count);
#define probe_kernel_address(addr, retval) \
probe_kernel_read(, addr, sizeof(retval))
+/**
+ * probe_user_read(): safely attempt to read from a user location
+ * @dst: pointer to the buffer that shall take the data
+ * @src: address to read from
+ * @size: size of the data chunk
+ *
+ * Returns: 0 on success, -EFAULT on error.
+ *
+ * Safely read from address @src to the buffer at @dst. If a kernel fault
+ * happens, handle that and return -EFAULT.
+ *
+ * We ensure that the copy_from_user is executed in atomic context so that
+ * do_page_fault() doesn't attempt to take mmap_sem. This makes
+ * probe_user_read() suitable for use within regions where the caller
+ * already holds mmap_sem, or other locks which nest inside mmap_sem.
+ */
+
+#ifndef probe_user_read
+static __always_inline long probe_user_read(void *dst, const void __user *src,
+ size_t size)
+{
+ long ret;
+
+ if (!access_ok(src, size))
+ return -EFAULT;
+
+ pagefault_disable();
+ ret = __copy_from_user_inatomic(dst, src, size);
+ pagefault_enable();
+
+ return ret ? -EFAULT : 0;
+}
+#endif
+
#ifndef user_access_begin
#define user_access_begin(ptr,len) access_ok(ptr, len)
#define user_access_end() do { } while (0)
--
2.13.3
Re: [PATCH 4.14 069/101] spi: bcm2835: Fix race on DMA termination
On Mon, Jan 07, 2019 at 09:15:20PM +, Sudip Mukherjee wrote:
> HI Greg,
>
> On Mon, Jan 7, 2019 at 1:15 PM Greg Kroah-Hartman
> wrote:
> >
> > 4.14-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Lukas Wunner
> >
> > commit e82b0b3828451c1cd331d9f304c6078fcd43b62e upstream.
>
> This has been fixed later by 29bdedfd9cf4 ("spi: bcm2835: Unbreak the
> build of esoteric configs")
Thanks for this, now queued up.
greg k-h
Re: [PATCH v1 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2
On Mon, 2019-01-07 at 11:08 +0100, Daniel Vetter wrote:
> > > > @@ -1654,6 +1712,40 @@ int drm_fb_helper_check_var(struct
> > > > fb_var_screeninfo *var,
> > > > return -EINVAL;
> > > > }
> > > >
> > > > + /*
> > > > +* Workaround for SDL 1.2, which is known to be setting all
> > > > pixel format
> > > > +* fields values to zero in some cases. We treat this situation
> > > > as a
> > > > +* kind of "use some reasonable autodetected values".
> > > > +*/
> > > > + if (!var->red.offset && !var->green.offset&&
> > > > + !var->blue.offset&& !var->transp.offset &&
> > > > + !var->red.length && !var->green.length&&
> > > > + !var->blue.length&& !var->transp.length &&
> > > > + !var->red.msb_right && !var->green.msb_right &&
> > > > + !var->blue.msb_right && !var->transp.msb_right) {
> > > > + u8 depth;
> > > > +
> > > > + /*
> > > > +* There is no way to guess the right value for depth
> > > > when
> > > > +* bpp is 16 or 32. So we just restore the behaviour
> > > > previously
> > > > +* introduced here by commit . In fact, this was
> > > > +* implemented even earlier in various device drivers.
> > > > +*/
> > > > + switch (var->bits_per_pixel) {
> > > > + case 16:
> > > > + depth = 15;
> > > > + break;
> > > > + case 32:
> > > > + depth = 24;
> > > > + break;
> > > > + default:
> > > > + depth = var->bits_per_pixel;
> > > > + break;
> > > > + }
> > > > +
> > > > + drm_fb_helper_fill_pixel_fmt(var, depth);
> > >
> > > Please use fb->format->depth here instead of guessing.
> > > -Daniel
> >
> > I do not think that this is the right way.
> >
> > Without guessing, if SDL1 makes a request with bits_per_pixel == 16
> > (for example) and current fb->format->depth == 24, ioctl() will succeed
> > while actual pixel format will remain the same. As a result, SDL1 will
> > display garbage because of invalid pixel format.
> >
> > Or am I missing something here?
>
> This is supposed to be the case where SDL didn't set any of this stuff.
> Guess is definitely not what we want to do, we should use the actual
> depth, which is stored in fb->format->depth. Older code did guess, but we
> fixed that, and shouldn't reintroduce that guess game.
> -Daniel
>
Done. See the v2 patch series.
[PATCH] ARM: dts: sun6i: Add clock-output-names to osc24M clock
The osc24M clock does not have a "clock-output-names" property, which
means that the clock name is derived from the node name in Linux. The
node name was changed in commit acfd5bbe2641 ("ARM: dts: sun6i: Change
clock node names to avoid warnings"). This breaks Linux as the sunxi-ng
clock driver implicitly depends on the external clock being named
"osc24M".
Add a "clock-output-names" property to restore the previous behavior.
Fixes: acfd5bbe2641 ("ARM: dts: sun6i: Change clock node names to avoid
warnings")
Signed-off-by: Chen-Yu Tsai
---
This is a critical fix for v5.0-rc. Without it the A31 boots up to the
UART failing to get its clock rate, and thus failing to setup a console.
Also the timer-sun5i init code hits a divide by zero exception. I'll
send a separate patch to make this one fail gracefully.
---
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 353d90f99b40..13304b8c5139 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -216,6 +216,7 @@
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <2400>;
+ clock-output-names = "osc24M";
};
osc32k: clk-32k {
--
2.20.1
[PATCH v2 1/2] drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2
SDL 1.2 sets all fields related to the pixel format to zero in some
cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
pixel format changing requests"), there was an unintentional workaround
for this that existed for more than a decade. First in device-specific DRM
drivers, then here in drm_fb_helper.c.
Previous code containing this workaround just ignores pixel format fields
from userspace code. Not a good thing either, as this way, driver may
silently use pixel format different from what client actually requested,
and this in turn will lead to displaying garbage on the screen. I think
that returning EINVAL to userspace in this particular case is the right
option, so I decided to left code from problematic commit untouched
instead of just reverting it entirely.
Here is the steps required to reproduce this problem exactly:
1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL
support. SDL should be compiled with fbdev support (which is
on by default).
2) Create /etc/fb.modes with following contents (values seems
not used, and just required to trigger problematic code in
SDL):
mode "test"
geometry 1 1 1 1 1
timings 1 1 1 1 1 1 1
endmode
3) Create ~/.fceux/fceux.cfg with following contents:
SDL.Hotkeys.Quit = 27
SDL.DoubleBuffering = 1
4) Ensure that screen resolution is at least 1280x960 (e.g.
append "video=Virtual-1:1280x960-32" to the kernel cmdline
for qemu/QXL).
5) Try to run fceux on VT with some ROM file[3]:
# ./fceux color_test.nes
[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
FB_SetVideoMode()
[2] http://www.fceux.com
[3] Example ROM:
https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nes
Reported-by: saahriktu
Suggested-by: saahriktu
Cc: sta...@vger.kernel.org
Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing
requests")
Signed-off-by: Ivan Mironov
---
drivers/gpu/drm/drm_fb_helper.c | 142
1 file changed, 89 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d3af098b0922..ed7e91423258 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(const struct
fb_var_screeninfo *var_1,
var_1->transp.msb_right == var_2->transp.msb_right;
}
+static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
+u8 depth)
+{
+ switch (depth) {
+ case 8:
+ var->red.offset = 0;
+ var->green.offset = 0;
+ var->blue.offset = 0;
+ var->red.length = 8; /* 8bit DAC */
+ var->green.length = 8;
+ var->blue.length = 8;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ break;
+ case 15:
+ var->red.offset = 10;
+ var->green.offset = 5;
+ var->blue.offset = 0;
+ var->red.length = 5;
+ var->green.length = 5;
+ var->blue.length = 5;
+ var->transp.offset = 15;
+ var->transp.length = 1;
+ break;
+ case 16:
+ var->red.offset = 11;
+ var->green.offset = 5;
+ var->blue.offset = 0;
+ var->red.length = 5;
+ var->green.length = 6;
+ var->blue.length = 5;
+ var->transp.offset = 0;
+ break;
+ case 24:
+ var->red.offset = 16;
+ var->green.offset = 8;
+ var->blue.offset = 0;
+ var->red.length = 8;
+ var->green.length = 8;
+ var->blue.length = 8;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ break;
+ case 32:
+ var->red.offset = 16;
+ var->green.offset = 8;
+ var->blue.offset = 0;
+ var->red.length = 8;
+ var->green.length = 8;
+ var->blue.length = 8;
+ var->transp.offset = 24;
+ var->transp.length = 8;
+ break;
+ default:
+ break;
+ }
+}
+
/**
* drm_fb_helper_check_var - implementation for _ops.fb_check_var
* @var: screeninfo to check
@@ -1654,6 +1712,36 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
return -EINVAL;
}
+ /*
+* Workaround for SDL 1.2, which is known to be setting all pixel format
+* fields values to zero in some cases. We treat this situation as a
+* kind of "use some reasonable autodetected values".
+
[PATCH v2 2/2] drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock
Strict requirement of pixclock to be zero breaks support of SDL 1.2
which contains hardcoded table of supported video modes with non-zero
pixclock values[1].
To better understand which pixclock values are considered valid and how
driver should handle these values, I briefly examined few existing fbdev
drivers and documentation in Documentation/fb/. And it looks like there
are no strict rules on that and actual behaviour varies:
* some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c);
* some treat (pixclock == 0) as invalid value which leads to
-EINVAL (clps711x-fb.c);
* some pass converted pixclock value to hardware (uvesafb.c);
* some are trying to find nearest value from predefined table
(vga16fb.c, video_gx.c).
Given this, I believe that it should be safe to just ignore this value if
changing is not supported. It seems that any portable fbdev application
which was not written only for one specific device working under one
specific kernel version should not rely on any particular behaviour of
pixclock anyway.
However, while enabling SDL1 applications to work out of the box when
there is no /etc/fb.modes with valid settings, this change affects the
video mode choosing logic in SDL. Depending on current screen
resolution, contents of /etc/fb.modes and resolution requested by
application, this may lead to user-visible difference (not always):
image will be displayed in a right way, but it will be aligned to the
left instead of center. There is no "right behaviour" here as well, as
emulated fbdev, opposing to old fbdev drivers, simply ignores any
requsts of video mode changes with resolutions smaller than current.
The easiest way to reproduce this problem is to install sdl-sopwith[2],
remove /etc/fb.modes file if it exists, and then try to run sopwith
from console without X. At least in Fedora 29, sopwith may be simply
installed from standard repositories.
[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings
[2] http://sdl-sopwith.sourceforge.net/
Signed-off-by: Ivan Mironov
Cc: sta...@vger.kernel.org
Fixes: 79e539453b34e ("DRM: i915: add mode setting support")
Fixes: 771fe6b912fca ("drm/radeon: introduce kernel modesetting for radeon
hardware")
Fixes: 785b93ef8c309 ("drm/kms: move driver specific fb common code to helper
functions (v2)")
---
drivers/gpu/drm/drm_fb_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ed7e91423258..2d4c2b38508e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1690,9 +1690,14 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
struct drm_fb_helper *fb_helper = info->par;
struct drm_framebuffer *fb = fb_helper->fb;
- if (var->pixclock != 0 || in_dbg_master())
+ if (in_dbg_master())
return -EINVAL;
+ if (var->pixclock != 0) {
+ DRM_DEBUG("fbdev emulation doesn't support changing the pixel
clock, value of pixclock is ignored\n");
+ var->pixclock = 0;
+ }
+
if ((drm_format_info_block_width(fb->format, 0) > 1) ||
(drm_format_info_block_height(fb->format, 0) > 1))
return -EINVAL;
--
2.20.1
[PATCH v2 0/2] Fix SDL 1.2 on emulated fbdev devices (broken in kernels >=4.19)
Hi,
Originally this issue was brought up on linux.org.ru forum by user
saahriktu, he is on Cc. He discovered that commit db05c48197759
("drm: fb-helper: Reject all pixel format changing requests") breaks
support of SDL1 programs, like various old games and emulators of old
game consoles. First patch contains fix for that commit.
I tried to reproduce the same issue in a VM under qemu, and found yet
another part of kernel code which prevents SDL1 apps from running
normally. Second patch in this series fixes this problem.
Also, it seems that at least in some cases both problems could be
circumvented by adding appropriate modes into /etc/fb.modes. But without
examining the kernel code it is not clear which values are correct. I am
not sure that such circumvention covers all possible cases, and it is
definitely far from any user-friendliness.
First patch in this series fixes a clear regression. Second patch is
optional, please read commit message carefully before applying it.
Changes in v2:
- Added "Cc: stable" to the second patch.
- Proposed by Daniel Vetter: always use current depth (fb->format->depth)
in a case of zero pixel format values and do not perform any guessing.
Changes in v1:
- Added "Cc: stable" to the patch which fixes known regression.
- Added more information and detailed reproduction steps in commit
messages.
Changes in v0:
- RFC patch series introduced.
Ivan Mironov (2):
drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2
drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock
drivers/gpu/drm/drm_fb_helper.c | 149
1 file changed, 95 insertions(+), 54 deletions(-)
--
2.20.1
Re: [PATCH v3 16/16] power: supply: olpc_battery: Add OLPC XO 1.75 support
Hi Lubomir, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.0-rc1 next-20190108] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Lubomir-Rintel/Add-support-for-OLPC-XO-1-75-Embedded-Controller/20190108-114514 config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): >> arch/x86/platform/olpc/olpc.c:325:1: warning: 'postcore_initcall()' has >> implicit return type >> arch/x86/platform/olpc/olpc.c:30:24: warning: symbol 'olpc_platform_info' >> was not declared. Should it be static? >> arch/x86/platform/olpc/olpc.c:294:14: error: undefined identifier >> 'olpc_ofw_present' >> arch/x86/platform/olpc/olpc.c:298:43: error: undefined identifier >> 'olpc_board_pre' >> arch/x86/platform/olpc/olpc.c:299:17: error: undefined identifier >> 'olpc_ec_driver_register' arch/x86/platform/olpc/olpc.c:301:17: error: undefined identifier 'olpc_ec_driver_register' >> arch/x86/platform/olpc/olpc.c:305:13: error: undefined identifier >> 'olpc_board_at_least' arch/x86/platform/olpc/olpc.c:316:43: error: undefined identifier 'olpc_board_pre' -- >> arch/x86/platform/olpc/olpc_ofw.c:17:5: warning: symbol 'olpc_ofw_pgd' was >> not declared. Should it be static? >> arch/x86/platform/olpc/olpc_ofw.c:31:14: warning: incorrect type in >> assignment (different address spaces) arch/x86/platform/olpc/olpc_ofw.c:31:14:expected struct pgd_t [usertype] *base arch/x86/platform/olpc/olpc_ofw.c:31:14:got void [noderef] * >> arch/x86/platform/olpc/olpc_ofw.c:43:23: warning: incorrect type in argument >> 1 (different address spaces) arch/x86/platform/olpc/olpc_ofw.c:43:23:expected void [noderef] *addr arch/x86/platform/olpc/olpc_ofw.c:43:23:got struct pgd_t [usertype] *base >> arch/x86/platform/olpc/olpc_ofw.c:23:13: warning: symbol >> 'setup_olpc_ofw_pgd' was not declared. Should it be static? >> arch/x86/platform/olpc/olpc_ofw.c:46:5: warning: symbol '__olpc_ofw' was not >> declared. Should it be static? >> arch/x86/platform/olpc/olpc_ofw.c:80:6: warning: symbol 'olpc_ofw_present' >> was not declared. Should it be static? >> arch/x86/platform/olpc/olpc_ofw.c:92:13: warning: symbol 'olpc_ofw_detect' >> was not declared. Should it be static? >> arch/x86/platform/olpc/olpc_ofw.c:117:13: warning: symbol >> 'olpc_ofw_is_installed' was not declared. Should it be static? >> arch/x86/platform/olpc/olpc_ofw.c:58:28: warning: non size-preserving >> pointer to integer cast >> arch/x86/platform/olpc/olpc_ofw.c:101:40: warning: non size-preserving >> integer to pointer cast -- >> arch/x86/platform/olpc/olpc_dt.c:34:13: error: undefined identifier >> 'olpc_ofw' arch/x86/platform/olpc/olpc_dt.c:48:13: error: undefined identifier 'olpc_ofw' arch/x86/platform/olpc/olpc_dt.c:65:13: error: undefined identifier 'olpc_ofw' arch/x86/platform/olpc/olpc_dt.c:85:21: error: undefined identifier 'olpc_ofw' arch/x86/platform/olpc/olpc_dt.c:105:13: error: undefined identifier 'olpc_ofw' arch/x86/platform/olpc/olpc_dt.c:120:13: error: undefined identifier 'olpc_ofw' arch/x86/platform/olpc/olpc_dt.c:173:13: error: undefined identifier 'olpc_ofw' arch/x86/platform/olpc/olpc_dt.c:190:13: error: undefined identifier 'olpc_ofw' >> arch/x86/platform/olpc/olpc_dt.c:220:5: warning: symbol >> 'olpc_dt_compatible_match' was not declared. Should it be static? >> arch/x86/platform/olpc/olpc_dt.c:253:26: error: undefined identifier >> 'olpc_board_pre' >> arch/x86/platform/olpc/olpc_dt.c:300:14: error: undefined identifier >> 'olpc_ofw_is_installed' -- >> drivers/power/supply/olpc_battery.c:328:24: warning: cast to restricted >> __le16 >> drivers/power/supply/olpc_battery.c:330:24: warning: cast to restricted >> __be16 >> drivers/power/supply/olpc_battery.c:330:24: warning: cast to restricted >> __be16 >> drivers/power/supply/olpc_battery.c:330:24: warning: cast to restricted >> __be16 >> drivers/power/supply/olpc_battery.c:330:24: warning: cast to restricted >> __be16 >> drivers/power/supply/olpc_battery.c:405:51: warning: incorrect type in >> argument 2 (different base types) drivers/power/supply/olpc_battery.c:405:51:expected unsigned short [usertype] ec_word drivers/power/supply/olpc_battery.c:405:51:got restricted __be16 [addressable] [usertype] ec_word drivers/power/supply/olpc_battery.c:413:51: warning: incorrect type in argument 2 (different base types) drivers/power/supply/olpc_battery.c:413:51:expected unsigned short [usertype] ec_word drivers/power/supply/olpc_battery.c:413:51:got restricted __be16 [addressable] [usertype] ec_word drivers/power/supply/olpc_battery.c:444:51: warning: incorrect type in argument 2
Re: [PATCH v4 2/3] virtio-balloon: improve update_balloon_size_func
On Tue, Jan 08, 2019 at 12:50:04PM +0800, Wei Wang wrote: > There is no need to update the balloon actual register when there is no > ballooning request. This patch avoids update_balloon_size when diff is 0. > > Signed-off-by: Wei Wang > Reviewed-by: Cornelia Huck > Reviewed-by: Halil Pasic > Tested-by: Christian Borntraeger > --- > drivers/virtio/virtio_balloon.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c > index 45d32f5..d48c12c 100644 > --- a/drivers/virtio/virtio_balloon.c > +++ b/drivers/virtio/virtio_balloon.c > @@ -457,9 +457,12 @@ static void update_balloon_size_func(struct work_struct > *work) > update_balloon_size_work); > diff = towards_target(vb); > > + if (!diff) > + return; > + > if (diff > 0) > diff -= fill_balloon(vb, diff); > - else if (diff < 0) > + else > diff += leak_balloon(vb, -diff); > update_balloon_size(vb); > > -- > 2.7.4 > This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
Re: [PATCH v4 3/3] virtio_balloon: remove the unnecessary 0-initialization
On Tue, Jan 08, 2019 at 12:50:05PM +0800, Wei Wang wrote:
> We've changed to kzalloc the vb struct, so no need to 0-initialize
> this field one more time.
>
> Signed-off-by: Wei Wang
> Reviewed-by: Cornelia Huck
> ---
> drivers/virtio/virtio_balloon.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index d48c12c..048959a 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -925,7 +925,6 @@ static int virtballoon_probe(struct virtio_device *vdev)
> VIRTIO_BALLOON_CMD_ID_STOP);
> vb->cmd_id_stop = cpu_to_virtio32(vb->vdev,
> VIRTIO_BALLOON_CMD_ID_STOP);
> - vb->num_free_page_blocks = 0;
> spin_lock_init(>free_page_list_lock);
> INIT_LIST_HEAD(>free_page_list);
> if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
> --
> 2.7.4
>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH v4 1/3] virtio-balloon: tweak config_changed implementation
On Tue, Jan 08, 2019 at 12:50:03PM +0800, Wei Wang wrote:
> virtio-ccw has deadlock issues with reading the config space inside the
> interrupt context, so we tweak the virtballoon_changed implementation
> by moving the config read operations into the related workqueue contexts.
> The config_read_bitmap is used as a flag to the workqueue callbacks
> about the related config fields that need to be read.
>
> The cmd_id_received is also renamed to cmd_id_received_cache, and
> the value should be obtained via virtio_balloon_cmd_id_received.
>
> Fixes: 86a559787e6f ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT")
> Reported-by: Christian Borntraeger
> Signed-off-by: Wei Wang
> Reviewed-by: Cornelia Huck
> Reviewed-by: Halil Pasic
> Tested-by: Christian Borntraeger
> ---
> drivers/virtio/virtio_balloon.c | 98
> +++--
> 1 file changed, 65 insertions(+), 33 deletions(-)
>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler
Am Dienstag, 8. Januar 2019, 06:03:58 CET schrieb Herbert Xu: Hi Herbert, > Are we going to have multiple implementations for the same KDF? > If not then the crypto API is not a good fit. To consolidate > multiple implementations of the same KDF, simply provide helpers > for them. It is unlikely to have multiple implementations of a KDF. However, KDFs relate to hashes like block chaining modes to raw block ciphers. Thus a KDF can be applied with different hashes. My idea was to add template support to RNGs (because KDFs are effectively a type of RNG since they produce an arbitrary output from a fixed input). The KDFs would be a template wrapping hashes. For example, the CTR-KDF from SP800-108 could be instantiated like kdf-ctr(sha256). Ciao Stephan
[PATCH] NFC: fdp: Use signed max_size to catch fail
The variable max_size's type is unsigned char,can not catch error number, change it to signed int. Signed-off-by: wangbo --- drivers/nfc/fdp/fdp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c index d5784a4..ba32a59 100644 --- a/drivers/nfc/fdp/fdp.c +++ b/drivers/nfc/fdp/fdp.c @@ -192,8 +192,9 @@ static int fdp_nci_send_patch(struct nci_dev *ndev, u8 conn_id, u8 type) const struct firmware *fw; struct sk_buff *skb; unsigned long len; - u8 max_size, payload_size; + u8 payload_size; int rc = 0; + int max_size = 0; if ((type == NCI_PATCH_TYPE_OTP && !info->otp_patch) || (type == NCI_PATCH_TYPE_RAM && !info->ram_patch)) -- 2.7.4
Re: [RESEND PATCH v3 2/2] sysctl: handle overflow for file-max
On Mon, Jan 07, 2019 at 11:27:00PM +0100, Christian Brauner wrote:
> @@ -2833,6 +2836,10 @@ static int __do_proc_doulongvec_minmax(void *data,
> struct ctl_table *table, int
> break;
> if (neg)
> continue;
> + if ((max && val > *max) || (min && val < *min)) {
> + err = -EINVAL;
> + break;
> + }
> val = convmul * val / convdiv;
> if ((min && val < *min) || (max && val > *max))
> continue;
This is a generic change which affects all users of
do_proc_doulongvec_minmax() that have extra1 or extra2 set. In sysctl.c, I
do not see another user of proc_doulongvec_minmax() that has extra1 or
extra2 set. However, have you verified whether your patch changes the
behaviour for other files that make use of proc_doulongvec_minmax() or
proc_doulongvec_ms_jiffies_minmax(), and not only of the file-max sysctl?
Thanks,
Dominik
Re: [PATCH v4 2/2] dts: arm64/sdm845: Add node for arm,mmu-500
On Thu 11 Oct 02:49 PDT 2018, Vivek Gautam wrote:
> Add device node for arm,mmu-500 available on sdm845.
> This MMU-500 with single TCU and multiple TBU architecture
> is shared among all the peripherals except gpu.
>
Hi Vivek,
Applying this patch together with UFS ([1] and [2]) ontop of v5.0-rc1
causes my MTP reboot once the UFSHCD module is inserted and probed.
Independently the patches seems to work fine.
Do you have any suggestion to why this would be?
[1] https://lore.kernel.org/lkml/20181210192826.241350-4-evgr...@chromium.org/
[2] https://lore.kernel.org/lkml/20181210192826.241350-5-evgr...@chromium.org/
Regards,
Bjorn
> Signed-off-by: Vivek Gautam
> ---
>
> Changes since v3:
> - none.
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 72
>
> 1 file changed, 72 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index b72bdb0a31a5..0aace729643d 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1297,6 +1297,78 @@
> cell-index = <0>;
> };
>
> + apps_smmu: iommu@1500 {
> + compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
> + reg = <0x1500 0x8>;
> + #iommu-cells = <2>;
> + #global-interrupts = <1>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + };
> +
> apss_shared: mailbox@1799 {
> compatible = "qcom,sdm845-apss-shared";
> reg = <0x1799 0x1000>;
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
Re: [PATCH 13/20] xenbus: drop useless LIST_HEAD
On 23/12/2018 09:57, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> The declarations were introduced with the file, but the declared
> variables were not used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
>
> Fixes: 1107ba885e46 ("xen: add xenfs to allow usermode <-> Xen interaction")
> Signed-off-by: Julia Lawall
Reviewed-by: Juergen Gross
Juergen
[PATCH v4 1/2] crypto: talitos - reorder code in talitos_edesc_alloc()
This patch moves the mapping of IV after the kmalloc(). This
avoids having to unmap in case kmalloc() fails.
Signed-off-by: Christophe Leroy
---
new in v4
drivers/crypto/talitos.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 45e20707cef8..54d80e7edb86 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1361,23 +1361,18 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
struct talitos_private *priv = dev_get_drvdata(dev);
bool is_sec1 = has_ftr_sec1(priv);
int max_len = is_sec1 ? TALITOS1_MAX_DATA_LEN : TALITOS2_MAX_DATA_LEN;
- void *err;
if (cryptlen + authsize > max_len) {
dev_err(dev, "length exceeds h/w max limit\n");
return ERR_PTR(-EINVAL);
}
- if (ivsize)
- iv_dma = dma_map_single(dev, iv, ivsize, DMA_TO_DEVICE);
-
if (!dst || dst == src) {
src_len = assoclen + cryptlen + authsize;
src_nents = sg_nents_for_len(src, src_len);
if (src_nents < 0) {
dev_err(dev, "Invalid number of src SG.\n");
- err = ERR_PTR(-EINVAL);
- goto error_sg;
+ return ERR_PTR(-EINVAL);
}
src_nents = (src_nents == 1) ? 0 : src_nents;
dst_nents = dst ? src_nents : 0;
@@ -1387,16 +1382,14 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
src_nents = sg_nents_for_len(src, src_len);
if (src_nents < 0) {
dev_err(dev, "Invalid number of src SG.\n");
- err = ERR_PTR(-EINVAL);
- goto error_sg;
+ return ERR_PTR(-EINVAL);
}
src_nents = (src_nents == 1) ? 0 : src_nents;
dst_len = assoclen + cryptlen + (encrypt ? authsize : 0);
dst_nents = sg_nents_for_len(dst, dst_len);
if (dst_nents < 0) {
dev_err(dev, "Invalid number of dst SG.\n");
- err = ERR_PTR(-EINVAL);
- goto error_sg;
+ return ERR_PTR(-EINVAL);
}
dst_nents = (dst_nents == 1) ? 0 : dst_nents;
}
@@ -1425,10 +1418,10 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
alloc_len += sizeof(struct talitos_desc);
edesc = kmalloc(alloc_len, GFP_DMA | flags);
- if (!edesc) {
- err = ERR_PTR(-ENOMEM);
- goto error_sg;
- }
+ if (!edesc)
+ return ERR_PTR(-ENOMEM);
+ if (ivsize)
+ iv_dma = dma_map_single(dev, iv, ivsize, DMA_TO_DEVICE);
memset(>desc, 0, sizeof(edesc->desc));
edesc->src_nents = src_nents;
@@ -1445,10 +1438,6 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
DMA_BIDIRECTIONAL);
}
return edesc;
-error_sg:
- if (iv_dma)
- dma_unmap_single(dev, iv_dma, ivsize, DMA_TO_DEVICE);
- return err;
}
static struct talitos_edesc *aead_edesc_alloc(struct aead_request *areq, u8
*iv,
--
2.13.3
[PATCH v4 2/2] crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK
[2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
dma_nommu_map_page+0x44/0xd4
[2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
[2.384740] NIP: c000c540 LR: c000c584 CTR:
[2.389743] REGS: c95abab0 TRAP: 0700 Tainted: GW
(4.20.0-rc5-00560-g6bfb52e23a00-dirty)
[2.400042] MSR: 00029032 CR: 24042204 XER:
[2.406669]
[2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001
0001 0001
[2.406669] GPR08: 2000 0010 0010 24042202
0100 c95abd88
[2.406669] GPR16: c05569d4 0001 0010 c95abc88 c0615664
0004
[2.406669] GPR24: 0010 c95abc88 c95abc88 c61ae210 c7ff6d40
c61ae210 3d68
[2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4
[2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4
[2.451762] Call Trace:
[2.454195] [c95abb60] [82000808] 0x82000808 (unreliable)
[2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8
[2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c
[2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64
[2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08
[2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc
[2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc
[2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8
[2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50
[2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110
[2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
[2.515532] Instruction dump:
[2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076
7c84e850
[2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e 54847022
7c84fa14
[2.533960] ---[ end trace bf78d94af73fe3b8 ]---
[2.539123] talitos ff02.crypto: master data transfer error
[2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040
[2.551625] alg: skcipher: encryption failed on test 1 for ecb-aes-talitos:
ret=22
IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
cannot be DMA mapped anymore.
This patch copies the IV into the extended descriptor.
Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
v4: Split in two patches ; made the copy unconditional.
v3: Using struct edesc buffer.
v2: Using per-request context.
drivers/crypto/talitos.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 54d80e7edb86..f8e2c5c3f4eb 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1416,12 +1416,15 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
/* if its a ahash, add space for a second desc next to the first one */
if (is_sec1 && !dst)
alloc_len += sizeof(struct talitos_desc);
+ alloc_len += ivsize;
edesc = kmalloc(alloc_len, GFP_DMA | flags);
if (!edesc)
return ERR_PTR(-ENOMEM);
- if (ivsize)
+ if (ivsize) {
+ iv = memcpy(((u8 *)edesc) + alloc_len - ivsize, iv, ivsize);
iv_dma = dma_map_single(dev, iv, ivsize, DMA_TO_DEVICE);
+ }
memset(>desc, 0, sizeof(edesc->desc));
edesc->src_nents = src_nents;
--
2.13.3
[tip:x86/urgent] samples/seccomp: Fix 32-bit build
Commit-ID: a77d1d196bc63b37d9b4d1b614884669e8e79d32
Gitweb: https://git.kernel.org/tip/a77d1d196bc63b37d9b4d1b614884669e8e79d32
Author: Tycho Andersen
AuthorDate: Mon, 7 Jan 2019 16:16:31 -0700
Committer: Ingo Molnar
CommitDate: Tue, 8 Jan 2019 07:45:01 +0100
samples/seccomp: Fix 32-bit build
Both the .o and the actual executable need to be built with -m32 in order
to link correctly.
Reported-by: Ingo Molnar
Signed-off-by: Tycho Andersen
Reviewed-by: Kees Cook
Cc: Borislav Petkov
Cc: James Morris
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: fec7b6690541 ("samples: add an example of seccomp user trap")
Link: http://lkml.kernel.org/r/20190107231631.1849-1-ty...@tycho.ws
Signed-off-by: Ingo Molnar
---
samples/seccomp/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
index 4920903c8009..fb43a814d4c0 100644
--- a/samples/seccomp/Makefile
+++ b/samples/seccomp/Makefile
@@ -34,6 +34,7 @@ HOSTCFLAGS_bpf-direct.o += $(MFLAG)
HOSTCFLAGS_dropper.o += $(MFLAG)
HOSTCFLAGS_bpf-helper.o += $(MFLAG)
HOSTCFLAGS_bpf-fancy.o += $(MFLAG)
+HOSTCFLAGS_user-trap.o += $(MFLAG)
HOSTLDLIBS_bpf-direct += $(MFLAG)
HOSTLDLIBS_bpf-fancy += $(MFLAG)
HOSTLDLIBS_dropper += $(MFLAG)
Re: [GIT PULL] security: seccomp changes for v4.21
* Tycho Andersen wrote: > Hi, > > On Mon, Jan 07, 2019 at 01:09:09PM -0800, Kees Cook wrote: > > On Mon, Jan 7, 2019 at 2:15 AM Ingo Molnar wrote: > > > > > > > > > * James Morris wrote: > > > > > > > From Kees: > > > > > > > > "- Add SECCOMP_RET_USER_NOTIF > > > > > > > > - seccomp fixes for sparse warnings and s390 build (Tycho)" > > > > > > > > > > > > > > > > The following changes since commit > > > > 1072bd678547f8663cfb81a22fdb50c589e4976e: > > > > > > > > security: fs: make inode explicitly non-modular (2018-12-12 14:58:51 > > > > -0800) > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git > > > > next-seccomp > > > > > > > > for you to fetch changes up to 55b8cbe470d103b44104c64dbf89e5cad525d4e0: > > > > > > > > Merge tag 'seccomp-next-part2' of > > > > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into > > > > next-seccomp (2018-12-17 11:36:26 -0800) > > > > > > > > > > > > James Morris (2): > > > > Merge tag 'seccomp-next' of https://git.kernel.org/.../kees/linux > > > > into next-seccomp > > > > Merge tag 'seccomp-next-part2' of > > > > https://git.kernel.org/.../kees/linux into next-seccomp > > > > > > > > Tycho Andersen (6): > > > > seccomp: hoist struct seccomp_data recalculation higher > > > > seccomp: switch system call argument type to void * > > > > seccomp: add a return code to trap to userspace > > > > samples: add an example of seccomp user trap > > > > seccomp: fix poor type promotion > > > > seccomp, s390: fix build for syscall type change > > > > > > > > Documentation/ioctl/ioctl-number.txt | 1 + > > > > Documentation/userspace-api/seccomp_filter.rst | 84 + > > > > arch/s390/kernel/compat_wrapper.c | 2 +- > > > > include/linux/seccomp.h| 9 +- > > > > include/linux/syscalls.h | 2 +- > > > > include/uapi/linux/seccomp.h | 40 ++- > > > > kernel/seccomp.c | 467 > > > > - > > > > samples/seccomp/.gitignore | 1 + > > > > samples/seccomp/Makefile | 7 +- > > > > samples/seccomp/user-trap.c| 375 > > > > > > > > tools/testing/selftests/seccomp/seccomp_bpf.c | 447 > > > > ++- > > > > 11 files changed, 1411 insertions(+), 24 deletions(-) > > > > create mode 100644 samples/seccomp/user-trap.c > > > > > > 32-bit x86 allyesconfig doesn't build: > > > > > > /usr/bin/ld: i386:x86-64 architecture of input file > > > `samples/seccomp/user-trap.o' is incompatible with i386 output > > > /usr/bin/ld: samples/seccomp/user-trap.o: file class ELFCLASS64 > > > incompatible with ELFCLASS32 > > > /usr/bin/ld: final link failed: File in wrong format > > > collect2: error: ld returned 1 exit status > > > scripts/Makefile.host:99: recipe for target 'samples/seccomp/user-trap' > > > failed > > > make[2]: *** [samples/seccomp/user-trap] Error 1 > > > > > > Is this a known regression? > > > > That looks like something is busted in the samples Makefile? Tycho, > > are you able to reproduce this? > > Given that the samples build only happens when CROSS_COMPILE is not > set, I'll see about digging up a 32-bit box. But I think the patch > below should fix it, I'll send it out when I actually get it tested. > > Sorry for the breakage! > > Tycho > > > From b53b390ab554ef6e5b995ac050718fd62ed0803e Mon Sep 17 00:00:00 2001 > From: Tycho Andersen > Date: Mon, 7 Jan 2019 14:46:34 -0700 > Subject: [PATCH] samples/seccomp: fix 32-bit build > > Both the .o and the actual executable need to be built with -m32 in order > to link correctly. > > Signed-off-by: Tycho Andersen > Reported-by: Ingo Molnar > --- > samples/seccomp/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile > index 4920903c8009..a5607668a5c7 100644 > --- a/samples/seccomp/Makefile > +++ b/samples/seccomp/Makefile > @@ -37,6 +37,7 @@ HOSTCFLAGS_bpf-fancy.o += $(MFLAG) > HOSTLDLIBS_bpf-direct += $(MFLAG) > HOSTLDLIBS_bpf-fancy += $(MFLAG) > HOSTLDLIBS_dropper += $(MFLAG) > +HOSTLDLIBS_user-trap.o += $(MFLAG) That did the trick - thanks! Ingo
[PATCH] parisc: remove meaningless ccflags-y in arch/parisc/boot/Makefile
This ccflags-y is never used because arch/parisc/boot/Makefile only contains objcopy and install targets. Signed-off-by: Masahiro Yamada --- arch/parisc/boot/Makefile | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/parisc/boot/Makefile b/arch/parisc/boot/Makefile index cad68a5..41cce07 100644 --- a/arch/parisc/boot/Makefile +++ b/arch/parisc/boot/Makefile @@ -2,12 +2,6 @@ # Makefile for the linux parisc-specific parts of the boot image creator. # -COMPILE_VERSION := __linux_compile_version_id__`hostname | \ - tr -c '[0-9A-Za-z]' '_'`__`date | \ - tr -c '[0-9A-Za-z]' '_'`_t - -ccflags-y := -DCOMPILE_VERSION=$(COMPILE_VERSION) -gstabs -I. - targets := image targets += bzImage subdir- := compressed -- 2.7.4
Re: [PATCH] samples/seccomp: fix 32-bit build
* Kees Cook wrote:
> On Mon, Jan 7, 2019 at 3:16 PM Tycho Andersen wrote:
> >
> > Both the .o and the actual executable need to be built with -m32 in order
> > to link correctly.
> >
> > Signed-off-by: Tycho Andersen
> > Reported-by: Ingo Molnar
> > Fixes: fec7b6690541 ("samples: add an example of seccomp user trap")
>
> Reviewed-by: Kees Cook
>
> > ---
> > I guess x86 can pick this up directly? Not sure where it should go
> > exactly.
>
> Ingo, can you snag this? (It's a more direct path, otherwise I can
> take it via seccomp, which will go through my tree then James's
> tree...)
Sure - applied it to x86/urgent.
Thanks,
Ingo
Re: [PATCH 0/2] Add board support for Chameleon96 Board
On Sat, Dec 15, 2018 at 08:31:50AM +0530, Manivannan Sadhasivam wrote: > Hello, > > This patchset adds board support for Chameleon96 board from Novetech > based on Intel Cyclone V SoC FPGA. This board is one of the Consumer > Edition boards of the 96Boards family and has the following key features: > > * SoC - Intel Cyclone V SoC FPGA > * GPU - Graphics based on Intel Video Suite for FPGA > * RAM - 512MB DDR3L > * USB - 2x USB2.0 Host, 1x USB2.0 OTG > * Wireless - Wifi, BT > > More information about this board can be found in 96Boards product > page: https://www.96boards.org/product/chameleon96/ > > This patchset has been tested on Chameleon96 board and the board boots > into a distro on SD card with USB ports working. > Hi, Ping on this series! Thanks, Mani > Thanks, > Mani > > Manivannan Sadhasivam (2): > dt-bindings: vendor-prefixes: Add Novtech Vendor Prefix > ARM: dts: Add support for 96Boards Chameleon96 board > > .../devicetree/bindings/vendor-prefixes.txt | 1 + > arch/arm/boot/dts/Makefile| 1 + > .../boot/dts/socfpga_cyclone5_chameleon96.dts | 130 ++ > 3 files changed, 132 insertions(+) > create mode 100644 arch/arm/boot/dts/socfpga_cyclone5_chameleon96.dts > > -- > 2.17.1 >
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
On Mon, Jan 07, 2019 at 07:38:20PM +0100, Vitaly Kuznetsov wrote: > (I remember Greg disliked when people were tagging patches for stable@ > themselves, he prefered maintainers deciding if the particular commit > deserves stable@ or not - but as you have a tree now we may as well have > different rules :-) I don't recall ever saying I disliked that, unless people were tagging stuff that were obviously not stable material. Which, given the history of this codebase, was probably the case :) greg k-h
general protection fault in ipcomp_init_state
Hello, syzbot found the following crash on: HEAD commit:b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=17f383bb40 kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76 dashboard link: https://syzkaller.appspot.com/bug?extid=0864346ae616fffdd602 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+0864346ae616fffdd...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access sit: non-ECT from 172.20.255.187 with TOS=0x1 general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 25310 Comm: syz-executor0 Not tainted 4.20.0+ #3 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:strcmp+0x3a/0xb0 lib/string.c:328 Code: 41 55 41 54 53 48 89 fb 48 83 ec 08 eb 08 45 84 e4 74 5f 4c 89 ee 48 89 df 48 83 c3 01 48 89 f8 48 89 fa 48 c1 e8 03 83 e2 07 <42> 0f b6 04 30 38 d0 7f 04 84 c0 75 54 44 0f b6 63 ff 4c 8d 6e 01 RSP: 0018:88806190f3b0 EFLAGS: 00010246 RAX: 0007 RBX: 0039 RCX: 111010bdaced RDX: RSI: 88809c33d000 RDI: 0038 RBP: 88806190f3d8 R08: 8880642ba040 R09: fbfff1478e45 R10: 88806190f3d8 R11: 8a3c7227 R12: dc00 R13: 8880a6199380 R14: dc00 R15: 88806190f4a8 FS: 7f6f19d31700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 02908c10 CR3: 90cb7000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: ipcomp_alloc_tfms net/xfrm/xfrm_ipcomp.c:288 [inline] ipcomp_init_state+0x244/0xbc0 net/xfrm/xfrm_ipcomp.c:363 ipcomp4_init_state+0x10d/0xb10 net/ipv4/ipcomp.c:137 __xfrm_init_state+0x62a/0x1060 net/xfrm/xfrm_state.c:2302 xfrm_init_state+0x1e/0x80 net/xfrm/xfrm_state.c:2328 pfkey_msg2xfrm_state net/key/af_key.c:1307 [inline] pfkey_add+0x1da8/0x3180 net/key/af_key.c:1524 pfkey_process+0x6d2/0x810 net/key/af_key.c:2844 pfkey_sendmsg+0x5bb/0xfc0 net/key/af_key.c:3683 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:631 sit: non-ECT from 172.20.255.187 with TOS=0x1 ___sys_sendmsg+0x7ec/0x910 net/socket.c:2116 __sys_sendmsg+0x112/0x270 net/socket.c:2154 __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg net/socket.c:2161 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457ec9 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 kobject: 'loop3' (958bbf02): kobject_uevent_env RSP: 002b:7f6f19d30c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00457ec9 RDX: RSI: 2000 RDI: 0005 RBP: 0073bfa0 R08: R09: R10: R11: 0246 R12: 7f6f19d316d4 R13: 004c5305 R14: 004d8d70 R15: Modules linked in: ---[ end trace b27bff8084733df2 ]--- kobject: 'loop3' (958bbf02): fill_kobj_path: path = '/devices/virtual/block/loop3' RIP: 0010:strcmp+0x3a/0xb0 lib/string.c:328 kobject: 'loop4' (a9a61426): kobject_uevent_env Code: 41 55 41 54 53 48 89 fb 48 83 ec 08 eb 08 45 84 e4 74 5f 4c 89 ee 48 89 df 48 83 c3 01 48 89 f8 48 89 fa 48 c1 e8 03 83 e2 07 <42> 0f b6 04 30 38 d0 7f 04 84 c0 75 54 44 0f b6 63 ff 4c 8d 6e 01 TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending cookies. Check SNMP counters. netlink: 'syz-executor1': attribute type 1 has an invalid length. kobject: 'loop4' (a9a61426): fill_kobj_path: path = '/devices/virtual/block/loop4' sit: non-ECT from 172.20.255.187 with TOS=0x1 netlink: 'syz-executor1': attribute type 1 has an invalid length. kobject: 'loop1' (79f16328): kobject_uevent_env RSP: 0018:88806190f3b0 EFLAGS: 00010246 kobject: 'loop1' (79f16328): fill_kobj_path: path = '/devices/virtual/block/loop1' RAX: 0007 RBX: 0039 RCX: 111010bdaced kobject: 'loop2' (ab521588): kobject_uevent_env sit: non-ECT from 172.20.255.187 with TOS=0x1 RDX: RSI: 88809c33d000 RDI: 0038 kobject: 'loop2' (ab521588): fill_kobj_path: path = '/devices/virtual/block/loop2' netlink: 'syz-executor1': attribute type 1 has an invalid length. RBP:
Re: [PATCH v1] arm64: dts: qcom: msm8996: Disable USB2 PHY suspend by core
On Thu, Jan 3, 2019 at 6:18 PM Manu Gautam wrote: > > QUSB2 PHY on msm8996 doesn't work well when autosuspend by > dwc3 core using USB2PHYCFG register is enabled. One of the > issue seen is that PHY driver reports PLL lock failure and > fails phy_init() if dwc3 core has USB2 PHY suspend enabled. > Fix this by using quirks to disable USB2 PHY LPM/suspend and > dwc3 core already takes care of explicitly suspending PHY > during suspend if quirks are specified. > > Signed-off-by: Manu Gautam > --- This works well for db820c [1]. Tested-by: Vivek Gautam [1] https://github.com/vivekgautam1/linux/commits/origin/v4.20-rc5/db820c Best regards Vivek > arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi > b/arch/arm64/boot/dts/qcom/msm8996.dtsi > index b29fe80d7288..1f14ca35afc2 100644 > --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi > +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi > @@ -911,6 +911,8 @@ > interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>; > phys = <_phy2>; > phy-names = "usb2-phy"; > + snps,dis_u2_susphy_quirk; > + snps,dis_enblslpm_quirk; > }; > }; > > @@ -940,6 +942,8 @@ > interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>; > phys = <_phy1>, <_phy_0>; > phy-names = "usb2-phy", "usb3-phy"; > + snps,dis_u2_susphy_quirk; > + snps,dis_enblslpm_quirk; > }; > }; > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
general protection fault in ax25_send_control
Hello, syzbot found the following crash on: HEAD commit:b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=174ccdbb40 kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76 dashboard link: https://syzkaller.appspot.com/bug?extid=d0b03d6dbe11a950e0ce compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d0b03d6dbe11a950e...@syzkaller.appspotmail.com ax25_connect(): syz-executor5 uses autobind, please contact jreu...@yaina.de ax25_connect(): syz-executor4 uses autobind, please contact jreu...@yaina.de kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN kobject: 'loop5' (0a8c8c40): kobject_uevent_env CPU: 0 PID: 13309 Comm: syz-executor0 Not tainted 4.20.0+ #3 kobject: 'loop5' (0a8c8c40): fill_kobj_path: path = '/devices/virtual/block/loop5' Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ax25_send_control+0x5a/0x560 net/ax25/ax25_subr.c:155 Code: ff df 48 c1 ea 03 80 3c 02 00 0f 85 b1 04 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 28 49 8d 7c 24 08 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 83 04 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b RSP: 0018:888042c377f8 EFLAGS: 00010202 RAX: dc00 RBX: 0043 RCX: c90005de9000 RDX: 0001 RSI: 87058725 RDI: 0008 RBP: 888042c37830 R08: 888064a5c380 R09: 888064a5cc48 R10: 888064a5c380 R11: R12: kobject: 'loop4' (5a2eed4e): kobject_uevent_env R13: 88808baaa040 R14: 0001 R15: 88808baaa068 FS: 7f25a1e3a700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 01f01e80 CR3: a4311000 CR4: 001406f0 DR0: DR1: DR2: kobject: 'loop4' (5a2eed4e): fill_kobj_path: path = '/devices/virtual/block/loop4' DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: ax25_release+0x503/0x680 net/ax25/af_ax25.c:974 __sock_release+0xd3/0x250 net/socket.c:579 sock_close+0x1b/0x30 net/socket.c:1141 __fput+0x3c5/0xaf0 fs/file_table.c:278 fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x1f4/0x2b0 kernel/task_work.c:113 get_signal+0x168d/0x19b0 kernel/signal.c:2347 do_signal+0x91/0x1e80 arch/x86/kernel/signal.c:816 exit_to_usermode_loop+0x2f7/0x3b0 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x696/0x800 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457ec9 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f25a1e39c78 EFLAGS: 0246 ORIG_RAX: 002a RAX: RBX: 0003 RCX: 00457ec9 RDX: 0048 RSI: 2140 RDI: 0004 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7f25a1e3a6d4 R13: 004be2ae R14: 004ce648 R15: Modules linked in: ---[ end trace dcff9655958a2d47 ]--- RIP: 0010:ax25_send_control+0x5a/0x560 net/ax25/ax25_subr.c:155 Code: ff df 48 c1 ea 03 80 3c 02 00 0f 85 b1 04 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 28 49 8d 7c 24 08 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 83 04 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b RSP: 0018:888042c377f8 EFLAGS: 00010202 RAX: dc00 RBX: 0043 RCX: c90005de9000 RDX: 0001 RSI: 87058725 RDI: 0008 RBP: 888042c37830 R08: 888064a5c380 R09: 888064a5cc48 R10: 888064a5c380 R11: R12: R13: 88808baaa040 R14: 0001 R15: 88808baaa068 FS: 7f25a1e3a700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7ff3c6de5db8 CR3: a4311000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
Re: [PATCH V6 2/2] iio: accell: mma8452: add vdd/vddio regulator operation support
On 05.01.19 18:29, Jonathan Cameron wrote:
> On Sun, 23 Dec 2018 09:02:32 +
> Anson Huang wrote:
>
>> The accelerometer's power supply could be controllable on some
>> platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
>> are controlled by a GPIO fixed regulator, need to make sure the
>> regulators are enabled before any communication with mma8451, this
>> patch adds vdd/vddio regulator operation support.
>>
>> Signed-off-by: Anson Huang
>> Acked-by: Martin Kepplinger
>
> I'm fine with the general approach now, though I would like separate
> error handling for the two different regulators.
>
> Also, this has obviously changed a fair bit since Martin originally gave
> that Ack. Martin, could you confirm you are still happy with the code?
I'd like to have the change you mention below too. I'll build, review
and confirm after that. thanks!
>
> Thanks,
>
> Jonathan
>
>
>> ---
>> ChangeLog since V5:
>> - ONLY enable vdd/vddio regulators after both of them are aquired;
>> - Since the suspend/resume operations are same as runtime
>> suspend/resume, so just use the
>> pm_runtime_force_suspend/resume for suspend/resuem callback to simply
>> the code.
>> ---
>> drivers/iio/accel/mma8452.c | 99
>> +++--
>> 1 file changed, 77 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
>> index 421a0a8..7519ed5 100644
>> --- a/drivers/iio/accel/mma8452.c
>> +++ b/drivers/iio/accel/mma8452.c
>> @@ -31,6 +31,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #define MMA8452_STATUS 0x00
>> #define MMA8452_STATUS_DRDY(BIT(2) | BIT(1) |
>> BIT(0))
>> @@ -107,6 +108,8 @@ struct mma8452_data {
>> u8 data_cfg;
>> const struct mma_chip_info *chip_info;
>> int sleep_val;
>> +struct regulator *vdd_reg;
>> +struct regulator *vddio_reg;
>> };
>>
>> /**
>> @@ -1534,9 +1537,33 @@ static int mma8452_probe(struct i2c_client *client,
>> mutex_init(>lock);
>> data->chip_info = match->data;
>>
>> +data->vdd_reg = devm_regulator_get(>dev, "vdd");
>> +data->vddio_reg = devm_regulator_get(>dev, "vddio");
>> +if (IS_ERR(data->vdd_reg) || IS_ERR(data->vddio_reg)) {
>> +if (PTR_ERR(data->vdd_reg) == -EPROBE_DEFER ||
>> +PTR_ERR(data->vddio_reg) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>> +
>> +dev_err(>dev, "failed to get VDD/VDDIO regulator!\n");
>> +return IS_ERR(data->vdd_reg) ?
>> + PTR_ERR(data->vdd_reg) : PTR_ERR(data->vddio_reg);
>
> This is overly complex. It'll be more lines of code, but I'd prefer
> you handle the two separately as the result will be more readable / less
> fragile.
>
>> +}
>> +
>> +ret = regulator_enable(data->vdd_reg);
>> +if (ret) {
>> +dev_err(>dev, "failed to enable VDD regulator!\n");
>> +return ret;
>> +}
>> +
>> +ret = regulator_enable(data->vddio_reg);
>> +if (ret) {
>> +dev_err(>dev, "failed to enable VDDIO regulator!\n");
>> +goto disable_regulator_vdd;
>> +}
>> +
>> ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
>> if (ret < 0)
>> -return ret;
>> +goto disable_regulators;
>>
>> switch (ret) {
>> case MMA8451_DEVICE_ID:
>> @@ -1549,7 +1576,8 @@ static int mma8452_probe(struct i2c_client *client,
>> break;
>> /* else: fall through */
>> default:
>> -return -ENODEV;
>> +ret = -ENODEV;
>> +goto disable_regulators;
>> }
>>
>> dev_info(>dev, "registering %s accelerometer; ID 0x%x\n",
>> @@ -1566,13 +1594,13 @@ static int mma8452_probe(struct i2c_client *client,
>>
>> ret = mma8452_reset(client);
>> if (ret < 0)
>> -return ret;
>> +goto disable_regulators;
>>
>> data->data_cfg = MMA8452_DATA_CFG_FS_2G;
>> ret = i2c_smbus_write_byte_data(client, MMA8452_DATA_CFG,
>> data->data_cfg);
>> if (ret < 0)
>> -return ret;
>> +goto disable_regulators;
>>
>> /*
>> * By default set transient threshold to max to avoid events if
>> @@ -1581,7 +1609,7 @@ static int mma8452_probe(struct i2c_client *client,
>> ret = i2c_smbus_write_byte_data(client, MMA8452_TRANSIENT_THS,
>> MMA8452_TRANSIENT_THS_MASK);
>> if (ret < 0)
>> -return ret;
>> +goto disable_regulators;
>>
>> if (client->irq) {
>> int irq2;
>> @@ -1595,7 +1623,7 @@ static int mma8452_probe(struct i2c_client *client,
>> MMA8452_CTRL_REG5,
>> data->chip_info->all_events);
>>
Re: [PATCH v5 13/15] KVM: s390: add function process_gib_alert_list()
On Mon, Jan 07, 2019 at 08:19:26PM +0100, Michael Mueller wrote: > > On 03.01.19 15:43, Pierre Morel wrote: > >On 19/12/2018 20:17, Michael Mueller wrote: > >>This function processes the Gib Alert List (GAL). It is required > >>to run when either a gib alert interruption has been received or > >>a gisa that is in the alert list is cleared or dropped. > >> > >>The GAL is build up by millicode, when the respective ISC bit is > >>set in the Interruption Alert Mask (IAM) and an interruption of > >>that class is observed. > >> > >>Signed-off-by: Michael Mueller > >>--- > >> arch/s390/kvm/interrupt.c | 140 > >>++ > >> 1 file changed, 140 insertions(+) > >> > >>diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c > >>index 48a93f5e5333..03e7ba4f215a 100644 > >>--- a/arch/s390/kvm/interrupt.c > >>+++ b/arch/s390/kvm/interrupt.c > >>@@ -2941,6 +2941,146 @@ int kvm_s390_get_irq_state(struct kvm_vcpu > >>*vcpu, __u8 __user *buf, int len) > >> return n; > >> } > >> +static int __try_airqs_kick(struct kvm *kvm, u8 ipm) > > > >static inline ? Why? In general it is a good idea to leave it up to the compiler to decide if it is worth to inline a function or not, unless you have a good reason to force inlining.
Re: [RFC PATCH 4/4] x86/mm: remove bottom-up allocation style for x86_64
On 08/01/2019 07:13, Pingfan Liu wrote:
> On Tue, Jan 8, 2019 at 1:42 AM Dave Hansen wrote:
>>
>> On 1/7/19 12:24 AM, Pingfan Liu wrote:
>>> There are two acheivements by this patch.
>>> -1st. keep the subtree of pgtable away from movable node.
>>> Background about the defect of the current bottom-up allocation style, take
>>> the following scenario:
>>> | unmovable node | movable node |
>>> | kaslr-kernel |subtree of pgtable for phy<->virt |
>>
>>
>>
>>> Although kaslr-kernel can avoid to stain the movable node. [1] But the
>>> pgtable can still stain the movable node. That is a probability problem,
>>> with low probability, but still exist. This patch tries to eliminate the
>>> probability. With the previous patch, at the point of init_mem_mapping(),
>>> memblock allocator can work with the knowledge of acpi memory hotmovable
>>> info, and avoid to stain the movable node. As a result,
>>> memory_map_bottom_up() is not needed any more.
>>>
>>> -2nd. simplify the logic of memory_map_top_down()
>>> Thanks to the help of early_make_pgtable(), x86_64 can directly set up the
>>> subtree of pgtable at any place, hence the careful iteration in
>>> memory_map_top_down() can be discard.
>>
>>> void __init init_mem_mapping(void)
>>> {
>>> unsigned long end;
>>> @@ -663,6 +540,7 @@ void __init init_mem_mapping(void)
>>>
>>> #ifdef CONFIG_X86_64
>>> end = max_pfn << PAGE_SHIFT;
>>> + set_alloc_range(0x10, end);
>>> #else
>>
>> Why is this 0x10 open-coded? Why is this needed *now*?
>>
>
> Memory under 1MB should be used by BIOS. For x86_64, after
Xen PV- and PVH-guests don't have that BIOS restriction.
Juergen
Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399
On Mon, Jan 7, 2019 at 2:30 AM Ayaka wrote: > > Hello Ezequiel > > Sent from my iPad > > > On Jan 7, 2019, at 1:21 AM, Ezequiel Garcia > > wrote: > > > >> On Sun, 6 Jan 2019 at 13:16, Ayaka wrote: > >> > >> > >> > >> Sent from my iPad > >> > >>> On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia > >>> wrote: > >>> > >>> On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote: > > On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia > > wrote: > > > > Hi Randy, > > > > Thanks a lot for this patches. They are really useful > > to provide more insight into the VPU hardware. > > > > This change will make the vpu encoder and vpu decoder > > completely independent, can they really work in parallel? > As I said it depends on the platform, but with this patch, the user > space would think they can work at the same time. > >>> > >>> > >>> I think there is some confusion. > >>> > >>> The devicetree is one thing: it is a hardware representation, > >>> a way to describe the hardware, for the kernel/bootloader to > >>> parse. > >>> > >>> The userspace view will depend on the driver implementation. > >>> > >>> The current devicetree and driver (without your patches), > >>> model the VPU as a single piece of hardware, exposing a decoder > >>> and an encoder. > >>> > >>> The V4L driver will then create two video devices, i.e. /dev/videoX > >>> and /dev/videoY. So userspace sees an independent view of the > >>> devices. > >>> > >> I knew that, the problem is that the driver should not always create a > >> decoder and encoder pair, they may not exist at some platforms, even some > >> platforms doesn’t have a encoder. You may have a look on the rk3328 I post > >> on the first email as example. > > > > That is correct. But that still doesn't tackle my question: is the > > hardware able to run a decoding and an encoding job in parallel? > > > For rk3328, yes, you see I didn’t draw them in the same box. > > If not, then it's wrong to describe them as independent entities. > > > >>> However, they are internally connected, and thus we can > >>> easily avoid two jobs running in parallel. > >>> > >> That is what the mpp service did in my patches, handing the relationship > >> between each devices. And it is not a easy work, maybe a 4k decoder would > >> be blocked by another high frame rate encoding work or another decoder > >> session. The vendor kernel have more worry about this, but not in this > >> version. > > > > Right. That is one way to design it. Another way is having a single > > devicetree node for the VPU encoder/decoder "complex". > No, you can’t assume which one is in the combo group, it can be various. you > see, in the rk3328, the vdpu is paired with an avs+ decoder. That is why I > use a virtual device standing for scheduler. First of all, thanks for all the input. Having more understanding of the hardware and shortcomings of the current V4L2 APIs is really important to let us further evolve the API and make sure that it works for further use cases. As for the Device Tree itself, it doesn't always describe the hardware in 100%. Most of the time it's just the necessary information to choose and instantiate the right drivers and bind to the right hardware resources. The information on which hardware instances on the SoC can work independently can of course be described in DT (e.g. by sub-nodes of a video-codec complex OR a set of phandles, e.g. rockchip,shared-instances), but it's also perfectly fine to defer this kind of knowledge to the drivers themselves. Best regards, Tomasz
Re: [RFC PATCH 2/4] x86/setup: parse acpi to get hotplug info before init_mem_mapping()
On Tue, Jan 8, 2019 at 1:11 AM Dave Hansen wrote:
>
>
> On 1/7/19 12:24 AM, Pingfan Liu wrote:
> > At present, memblock bottom-up allocation can help us against stamping over
> > movable node in very high probability.
>
> Is this what you are fixing? Making a "high probability", a certainty?
> Is this the problem?
>
Yes, as my reply on another mail in detail.
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index acbcd62..df4132c 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -805,6 +805,20 @@ dump_kernel_offset(struct notifier_block *self,
> > unsigned long v, void *p)
> > return 0;
> > }
> >
> > +/* only need the effect of acpi_numa_memory_affinity_init()
> > + * ->memblock_mark_hotplug()
> > + */
>
> CodingStyle, please.
>
Will fix.
> > +static int early_detect_acpi_memhotplug(void)
> > +{
> > +#ifdef CONFIG_ACPI_NUMA
> > + acpi_table_upgrade(__va(get_ramdisk_image()), get_ramdisk_size());
>
> This adds a new, early, call to acpi_table_upgrade(), and presumably all
> the following functions. However, it does not remove any of the later
> calls. How do they interact with each other now that they are
> presumably called twice?
>
ACPI is a big subsystem, I have a hurry through these functions. This
group seems not to allocate extra memory, and using static data. So if
called twice, just overwriting the effect of previous one. The only
issue is printk some info twice. I will pay more time on this for the
next version.
> > + acpi_table_init();
> > + acpi_numa_init();
> > + acpi_tb_terminate();
> > +#endif
> > + return 0;
> > +}
>
> Why does this return an 'int' that is unconsumed by its lone caller?
>
No special purpose about the return. Just a habit.
> There seems to be a lack of comments on this newly-added code.
>
> > /*
> > * Determine if we were loaded by an EFI loader. If so, then we have also
> > been
> > * passed the efi memmap, systab, etc., so we should use these data
> > structures
> > @@ -1131,6 +1145,7 @@ void __init setup_arch(char **cmdline_p)
> > trim_platform_memory_ranges();
> > trim_low_memory_range();
> >
> > + early_detect_acpi_memhotplug();
>
> Comments, please. Why is this call here, specifically? What is it doing?
>
It parses the acpi srat to extract memory hotmovable info, and feed
those info to memory allocator. The exactly effect is:
acpi_numa_memory_affinity_init() ->memblock_mark_hotplug(). So later
when memblock allocator allocates range, in __next_mem_range(), there
is cond check to skip movable node: if (movable_node_is_enabled() &&
memblock_is_hotpluggable(m)) continue;
Thanks,
Pingfan
I WANT YOU TO USE THIS DONATION TO HELP THE POOR URGENT.
My Sincere Greetings, I am MRS. SONIA AVIS IBRAHIM, I decided to donate what I have to you for investment towards the good work of charity organization, and also to help the motherless and the less privileged ones and to carry out a charitable works in your Country and around the World on my Behalf. I am diagnosing of throat Cancer, hospitalize for good 2 years and some months now and quite obvious that I have few days to live, and I am a Widow no child; I decided to will/donate the sum of $9.5 million to you for the good work of God, and also to help the motherless and less privilege and also forth assistance of the widows. At the moment I can not take any telephone calls right now due to the fact that my relatives (that have squandered the funds for this purpose before) are around me and my health status also. I have adjusted my will and my lawyer is aware. I have willed those properties to you by quoting my Personal File Routing and Account Information. And I have also notified the bank that I am willing that properties to you for a good, effective and prudent work. It is right to say that I have been directed to do this by God. I will be going in for a surgery soon and I want to make sure that I make this donation before undergoing this surgery. I will need your support to make this dream come through, could you let me know your interest to enable me give you further information. And I hereby advice to contact me by this email address ( soniaavi...@citromail.hu ) Looking forward to hearing from you soon, Yours sincerely, MRS. SONIA AVIS IBRAHIM
Re: [PATCH v3 05/16] Platform: OLPC: Add XO-1.75 EC driver
Hi Lubomir, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.0-rc1 next-20190107] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Lubomir-Rintel/Add-support-for-OLPC-XO-1-75-Embedded-Controller/20190108-114514 config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> drivers/platform/olpc/olpc-xo175-ec.c:26:10: fatal error: asm/system_misc.h: >> No such file or directory #include ^~~ compilation terminated. coccinelle warnings: (new ones prefixed by >>) >> drivers/platform/olpc/olpc-xo175-ec.c:496:5-13: WARNING: Unsigned expression >> compared with zero: nr_bytes < 0 vim +26 drivers/platform/olpc/olpc-xo175-ec.c > 26 #include 27 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: WARNING in ep_poll_callback
syzbot has found a reproducer for the following crash on: HEAD commit:139287cc2cc0 Add linux-next specific files for 20190108 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=14c9dd4b40 kernel config: https://syzkaller.appspot.com/x/.config?x=1521b074ff5a5bdf dashboard link: https://syzkaller.appspot.com/bug?extid=aea82bf9ee6ffd9a79d9 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1776034b40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14c2e580c0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+aea82bf9ee6ffd9a7...@syzkaller.appspotmail.com [ cut here ] IRQs not disabled as expected WARNING: CPU: 0 PID: 7862 at fs/eventpoll.c:1224 ep_poll_callback+0x77e/0x1450 fs/eventpoll.c:1224 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 7862 Comm: syz-executor245 Not tainted 5.0.0-rc1-next-20190108 #7 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+0x1db/0x2d0 lib/dump_stack.c:113 panic+0x2cb/0x65c kernel/panic.c:214 __warn.cold+0x20/0x48 kernel/panic.c:571 report_bug+0x263/0x2b0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] fixup_bug arch/x86/kernel/traps.c:173 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 RIP: 0010:ep_poll_callback+0x77e/0x1450 fs/eventpoll.c:1224 Code: ff 44 89 ee e8 63 84 98 ff 45 84 ed 0f 85 4a fa ff ff e8 15 83 98 ff 48 c7 c7 00 69 56 88 c6 05 a1 b2 6e 08 01 e8 52 c8 61 ff <0f> 0b e9 2b fa ff ff e8 f6 82 98 ff 48 8d 7b 30 48 b8 00 00 00 00 RSP: 0018:8880924ff6a0 EFLAGS: 00010282 RAX: RBX: 88809241f480 RCX: RDX: RSI: 816869f6 RDI: 0005 RBP: 8880924ff880 R08: 888099776640 R09: 888099776f30 R10: 888099776640 R11: R12: 8880924ff858 R13: R14: 88809241f4d0 R15: __wake_up_common+0x1d3/0x7d0 kernel/sched/wait.c:92 __wake_up_locked+0x11/0x20 kernel/sched/wait.c:154 fuse_abort_conn+0xd01/0x1200 fs/fuse/dev.c:2212 fuse_sb_destroy+0xd3/0x1d0 fs/fuse/inode.c:1245 fuse_kill_sb_anon+0x16/0x30 fs/fuse/inode.c:1256 deactivate_locked_super+0x9a/0x100 fs/super.c:331 deactivate_super fs/super.c:362 [inline] deactivate_super+0x2ab/0x320 fs/super.c:358 cleanup_mnt+0xbf/0x160 fs/namespace.c:1140 __cleanup_mnt+0x16/0x20 fs/namespace.c:1147 task_work_run+0x1f4/0x2b0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x32a/0x3b0 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x696/0x800 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440229 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fffbe5bdb08 EFLAGS: 0217 ORIG_RAX: 00a6 RAX: RBX: 004002c8 RCX: 00440229 RDX: 00440229 RSI: RDI: 2040 RBP: 006ca018 R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0217 R12: 00401ab0 R13: 00401b40 R14: R15: Kernel Offset: disabled Rebooting in 86400 seconds..
Re: [PATCH v4] USB: Don't enable LPM if it's already enabled
> On Jan 8, 2019, at 00:16, Greg KH wrote:
>
> On Mon, Dec 03, 2018 at 06:26:43PM +0800, Kai-Heng Feng wrote:
>> USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working
>> after S3:
>> [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_0302.bin
>> [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110)
>>
>> After some experiments, I found that disabling LPM can workaround the
>> issue.
>>
>> On some platforms, the USB power is cut during S3, so the driver uses
>> reset-resume to resume the device. During port resume, LPM gets enabled
>> twice, by usb_reset_and_verify_device() and usb_port_resume().
>>
>> So let's enable LPM for just once, as this solves the issue for the
>> device in question.
>>
>> Also consolidate USB2 LPM functions to usb_enable_usb2_hardware_lpm()
>> and usb_disable_usb2_hardware_lpm().
>>
>> Signed-off-by: Kai-Heng Feng
>
> What kernel patch does this one "fix"? Adding a "Fixes:" tag would be
> good to try to figure out how far back in the kernel releases this
> should be backported.
Fixes: de68bab4fa96 ("usb: Don't enable USB 2.0 Link PM by default.”)
The usb_set_usb2_hardware_lpm() was added to usb_reset_and_verify_device()
by this commit.
Kai-Heng
>
> thanks,
>
> greg k-h
Re: [RFC PATCH 4/4] x86/mm: remove bottom-up allocation style for x86_64
On Tue, Jan 8, 2019 at 1:42 AM Dave Hansen wrote:
>
> On 1/7/19 12:24 AM, Pingfan Liu wrote:
> > There are two acheivements by this patch.
> > -1st. keep the subtree of pgtable away from movable node.
> > Background about the defect of the current bottom-up allocation style, take
> > the following scenario:
> > | unmovable node | movable node |
> > | kaslr-kernel |subtree of pgtable for phy<->virt |
>
>
>
> > Although kaslr-kernel can avoid to stain the movable node. [1] But the
> > pgtable can still stain the movable node. That is a probability problem,
> > with low probability, but still exist. This patch tries to eliminate the
> > probability. With the previous patch, at the point of init_mem_mapping(),
> > memblock allocator can work with the knowledge of acpi memory hotmovable
> > info, and avoid to stain the movable node. As a result,
> > memory_map_bottom_up() is not needed any more.
> >
> > -2nd. simplify the logic of memory_map_top_down()
> > Thanks to the help of early_make_pgtable(), x86_64 can directly set up the
> > subtree of pgtable at any place, hence the careful iteration in
> > memory_map_top_down() can be discard.
>
> > void __init init_mem_mapping(void)
> > {
> > unsigned long end;
> > @@ -663,6 +540,7 @@ void __init init_mem_mapping(void)
> >
> > #ifdef CONFIG_X86_64
> > end = max_pfn << PAGE_SHIFT;
> > + set_alloc_range(0x10, end);
> > #else
>
> Why is this 0x10 open-coded? Why is this needed *now*?
>
Memory under 1MB should be used by BIOS. For x86_64, after
e820__memblock_setup(), the memblock allocator has already been ready
to work. But there are two factors to in order to
set_alloc_range(0x10, end). The major one is to be compatible with
x86_32, please refer to alloc_low_pages->memblock_find_in_range() uses
[min_pfn_mapped, max_pfn_mapped] to limit the range, which is ready to
be allocated from. The minor one is to prevent unexpected allocation
from memblock allocator through allow_low_pages() at very early stage.
>
> > /*
> >* If the allocation is in bottom-up direction, we setup direct
> > mapping
> >* in bottom-up, otherwise we setup direct mapping in top-down.
> > @@ -692,13 +577,6 @@ void __init init_mem_mapping(void)
> > } else {
> > memory_map_top_down(ISA_END_ADDRESS, end);
> > }
> > -
> > -#ifdef CONFIG_X86_64
> > - if (max_pfn > max_low_pfn) {
> > - /* can we preseve max_low_pfn ?*/
> > - max_low_pfn = max_pfn;
> > - }
> > -#else
> > early_ioremap_page_table_range_init();
> > #endif
> >
> > diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> > index 85c94f9..ecf7243 100644
> > --- a/arch/x86/mm/init_32.c
> > +++ b/arch/x86/mm/init_32.c
> > @@ -58,6 +58,8 @@ unsigned long highstart_pfn, highend_pfn;
> >
> > bool __read_mostly __vmalloc_start_set = false;
> >
> > +static unsigned long min_pfn_mapped;
> > +
> > /*
> > * Creates a middle page table and puts a pointer to it in the
> > * given global directory entry. This only returns the gd entry
> > @@ -516,6 +518,127 @@ void __init native_pagetable_init(void)
> > paging_init();
> > }
> >
> > +static unsigned long __init get_new_step_size(unsigned long step_size)
> > +{
> > + /*
> > + * Initial mapped size is PMD_SIZE (2M).
> > + * We can not set step_size to be PUD_SIZE (1G) yet.
> > + * In worse case, when we cross the 1G boundary, and
> > + * PG_LEVEL_2M is not set, we will need 1+1+512 pages (2M + 8k)
> > + * to map 1G range with PTE. Hence we use one less than the
> > + * difference of page table level shifts.
> > + *
> > + * Don't need to worry about overflow in the top-down case, on 32bit,
> > + * when step_size is 0, round_down() returns 0 for start, and that
> > + * turns it into 0x1ULL.
> > + * In the bottom-up case, round_up(x, 0) returns 0 though too, which
> > + * needs to be taken into consideration by the code below.
> > + */
> > + return step_size << (PMD_SHIFT - PAGE_SHIFT - 1);
> > +}
> > +
> > +/**
> > + * memory_map_top_down - Map [map_start, map_end) top down
> > + * @map_start: start address of the target memory range
> > + * @map_end: end address of the target memory range
> > + *
> > + * This function will setup direct mapping for memory range
> > + * [map_start, map_end) in top-down. That said, the page tables
> > + * will be allocated at the end of the memory, and we map the
> > + * memory in top-down.
> > + */
> > +void __init memory_map_top_down(unsigned long map_start,
> > +unsigned long map_end)
> > +{
> > + unsigned long real_end, start, last_start;
> > + unsigned long step_size;
> > + unsigned long addr;
> > + unsigned long mapped_ram_size = 0;
> > +
> > + /* xen has big range in reserved near end of ram, skip it at first.*/
> > + addr = memblock_find_in_range(map_start,
Re: [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable
On 01/07/2019 10:22 PM, Liang, Kan wrote:
Thanks for sharing. I understand the point of maintaining those
models at one place,
but this factor-out doesn't seem very elegant to me, like below
__intel_pmu_init (int model, struct x86_pmu *x86_pmu)
{
...
switch (model)
case INTEL_FAM6_NEHALEM:
case INTEL_FAM6_NEHALEM_EP:
case INTEL_FAM6_NEHALEM_EX:
intel_pmu_lbr_init(x86_pmu);
if (model != boot_cpu_data.x86_model)
return;
/* Other a lot of things init like below..*/
memcpy(hw_cache_event_ids, nehalem_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
memcpy(hw_cache_extra_regs, nehalem_hw_cache_extra_regs,
sizeof(hw_cache_extra_regs));
x86_pmu.event_constraints = intel_nehalem_event_constraints;
x86_pmu.pebs_constraints =
intel_nehalem_pebs_event_constraints;
x86_pmu.enable_all = intel_pmu_nhm_enable_all;
x86_pmu.extra_regs = intel_nehalem_extra_regs;
...
Case...
}
We need insert "if (model != boot_cpu_data.x86_model)" in every "Case
xx".
What would be the rationale that we only do lbr_init for "x86_pmu"
when model != boot_cpu_data.x86_model?
(It looks more like a workaround to factor-out the function and get
what we want)
I thought the new function may be extended to support fake pmu as below.
It's not only for lbr. PMU has many CPU specific features. It can be
used for other features, if you want to check the compatibility in
future. But I don't have an example now.
__intel_pmu_init (int model, struct x86_pmu *x86_pmu)
{
bool fake_pmu = (model != boot_cpu_data.x86_model) ? true : false;
...
switch (model)
case INTEL_FAM6_NEHALEM:
case INTEL_FAM6_NEHALEM_EP:
case INTEL_FAM6_NEHALEM_EX:
intel_pmu_lbr_init(x86_pmu);
x86_pmu->event_constraints = intel_nehalem_event_constraints;
x86_pmu->pebs_constraints = intel_nehalem_pebs_event_constraints;
x86_pmu->enable_all = intel_pmu_nhm_enable_all;
x86_pmu->extra_regs = intel_nehalem_extra_regs;
if (fake_pmu)
return;
It looks similar as the one I shared above, the difference is that more
things
(e.g. constraints) are assigned to x86_fake_pmu.
I'm not sure about the logic behind it (still look like a workaround).
/* Global variables should not be updated for fake PMU */
memcpy(hw_cache_event_ids, nehalem_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
memcpy(hw_cache_extra_regs, nehalem_hw_cache_extra_regs,
sizeof(hw_cache_extra_regs));
I would prefer having them separated as this patch for now - it is
logically more clear to me.
But it will be a problem for maintenance. Perf developer probably
forget to update the list in KVM. I think you have to regularly check
the perf code.
It's been very common in hypervisor development. That's why we have
hypervisor developers here.
When a new platform is added, we will definitely get some work like this
to do.
Best,
Wei
Re: [PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]
On Mon, Jan 07, 2019 at 09:01:29PM -0700, Jason Gunthorpe wrote: > On Sun, Jan 06, 2019 at 09:43:46AM +1100, Benjamin Herrenschmidt wrote: > > On Sat, 2019-01-05 at 10:51 -0700, Jason Gunthorpe wrote: > > > > > > > Interesting. I've investigated this further, though I don't have as > > > > many new clues as I'd like. The problem occurs reliably, at least on > > > > one particular type of machine (a POWER8 "Garrison" with ConnectX-4). > > > > I don't yet know if it occurs with other machines, I'm having trouble > > > > getting access to other machines with a suitable card. I didn't > > > > manage to reproduce it on a different POWER8 machine with a > > > > ConnectX-5, but I don't know if it's the difference in machine or > > > > difference in card revision that's important. > > > > > > Make sure the card has the latest firmware is always good advice.. > > > > > > > So possibilities that occur to me: > > > > * It's something specific about how the vfio-pci driver uses D3 > > > > state - have you tried rebinding your device to vfio-pci? > > > > * It's something specific about POWER, either the kernel or the PCI > > > > bridge hardware > > > > * It's something specific about this particular type of machine > > > > > > Does the EEH indicate what happend to actually trigger it? > > > > In a very cryptic way that requires manual parsing using non-public > > docs sadly but yes. From the look of it, it's a completion timeout. > > > > Looks to me like we don't get a response to a config space access > > during the change of D state. I don't know if it's the write of the D3 > > state itself or the read back though (it's probably detected on the > > read back or a subsequent read, but that doesn't tell me which specific > > one failed). > > If it is just one card doing it (again, check you have latest > firmware) I wonder if it is a sketchy PCI-E electrical link that is > causing a long re-training cycle? Can you tell if the PCI-E link is > permanently gone or does it eventually return? > > Does the card work in Gen 3 when it starts? Is there any indication of > PCI-E link errors? > > Everytime or sometimes? > > POWER 8 firmware is good? If the link does eventually come back, is > the POWER8's D3 resumption timeout long enough? > > If this doesn't lead to an obvious conclusion you'll probably need to > connect to IBM's Mellanox support team to get more information from > the card side. +1, I tried to find any Mellanox-internal bugs related to your issue and didn't find anything concrete. Thanks > > Jason signature.asc Description: PGP signature
[PATCH 2/3] usb: ehci: fsl: Update register accessing for arm/arm64 platforms
arm/arm64's io.h doesn't define clrbits32() and clrsetbits_be32(), which
causing compile failure on some Layerscape Platforms (such as LS1021A and
LS2012A which also integrates FSL EHCI controller). So use
ioread32be()/iowrite32be() instead to make it workable on both
powerpc and arm.
Signed-off-by: Ran Wang
---
drivers/usb/host/ehci-fsl.c | 64 ---
1 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 0a9fd20..59ebe1b 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "ehci.h"
#include "ehci-fsl.h"
@@ -50,6 +51,7 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev)
struct resource *res;
int irq;
int retval;
+ u32 tmp;
pr_debug("initializing FSL-SOC USB Controller\n");
@@ -114,18 +116,23 @@ static int fsl_ehci_drv_probe(struct platform_device
*pdev)
}
/* Enable USB controller, 83xx or 8536 */
- if (pdata->have_sysif_regs && pdata->controller_ver < FSL_USB_VER_1_6)
- clrsetbits_be32(hcd->regs + FSL_SOC_USB_CTRL,
- CONTROL_REGISTER_W1C_MASK, 0x4);
-
+ if (pdata->have_sysif_regs && pdata->controller_ver < FSL_USB_VER_1_6) {
+ tmp = ioread32be(hcd->regs + FSL_SOC_USB_CTRL);
+ tmp &= ~CONTROL_REGISTER_W1C_MASK;
+ tmp |= 0x4;
+ iowrite32be(tmp, hcd->regs + FSL_SOC_USB_CTRL);
+ }
/*
* Enable UTMI phy and program PTS field in UTMI mode before asserting
* controller reset for USB Controller version 2.5
*/
if (pdata->has_fsl_erratum_a007792) {
- clrsetbits_be32(hcd->regs + FSL_SOC_USB_CTRL,
- CONTROL_REGISTER_W1C_MASK, CTRL_UTMI_PHY_EN);
- writel(PORT_PTS_UTMI, hcd->regs + FSL_SOC_USB_PORTSC1);
+ tmp = ioread32be(hcd->regs + FSL_SOC_USB_CTRL);
+ tmp &= ~CONTROL_REGISTER_W1C_MASK;
+ tmp |= CTRL_UTMI_PHY_EN;
+ iowrite32be(tmp, hcd->regs + FSL_SOC_USB_CTRL);
+
+ iowrite32be(PORT_PTS_UTMI, hcd->regs + FSL_SOC_USB_PORTSC1);
}
/* Don't need to set host mode here. It will be done by tdi_reset() */
@@ -174,7 +181,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
enum fsl_usb2_phy_modes phy_mode,
unsigned int port_offset)
{
- u32 portsc;
+ u32 portsc, tmp;
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
void __iomem *non_ehci = hcd->regs;
struct device *dev = hcd->self.controller;
@@ -192,11 +199,16 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
case FSL_USB2_PHY_ULPI:
if (pdata->have_sysif_regs && pdata->controller_ver) {
/* controller version 1.6 or above */
- clrbits32(non_ehci + FSL_SOC_USB_CTRL,
- CONTROL_REGISTER_W1C_MASK | UTMI_PHY_EN);
- clrsetbits_be32(non_ehci + FSL_SOC_USB_CTRL,
- CONTROL_REGISTER_W1C_MASK,
- ULPI_PHY_CLK_SEL | USB_CTRL_USB_EN);
+ /* turn off UTMI PHY first */
+ tmp = ioread32be(non_ehci + FSL_SOC_USB_CTRL);
+ tmp &= ~(CONTROL_REGISTER_W1C_MASK | UTMI_PHY_EN);
+ iowrite32be(tmp, non_ehci + FSL_SOC_USB_CTRL);
+
+ /* then turn on ULPI and enable USB controller */
+ tmp = ioread32be(non_ehci + FSL_SOC_USB_CTRL);
+ tmp &= ~(CONTROL_REGISTER_W1C_MASK);
+ tmp |= ULPI_PHY_CLK_SEL | USB_CTRL_USB_EN;
+ iowrite32be(tmp, non_ehci + FSL_SOC_USB_CTRL);
}
portsc |= PORT_PTS_ULPI;
break;
@@ -210,16 +222,21 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
case FSL_USB2_PHY_UTMI_DUAL:
if (pdata->have_sysif_regs && pdata->controller_ver) {
/* controller version 1.6 or above */
- clrsetbits_be32(non_ehci + FSL_SOC_USB_CTRL,
- CONTROL_REGISTER_W1C_MASK, UTMI_PHY_EN);
+ tmp = ioread32be(non_ehci + FSL_SOC_USB_CTRL);
+ tmp &= ~(CONTROL_REGISTER_W1C_MASK);
+ tmp |= UTMI_PHY_EN;
+ iowrite32be(tmp, non_ehci + FSL_SOC_USB_CTRL);
+
mdelay(FSL_UTMI_PHY_DLY); /* Delay for UTMI PHY CLK to
become stable - 10ms*/
}
/* enable UTMI PHY */
- if (pdata->have_sysif_regs)
-
[PATCH 3/3] drivers: usb :fsl: Remove USB Errata checking code
From: yinbo.zhu
Remove USB errata checking code from driver. Applicability of erratum
is retrieved by reading corresponding property in device tree.
This property is written during device tree fixup.
Signed-off-by: Ramneek Mehresh
Signed-off-by: Nikhil Badola
Signed-off-by: yinbo.zhu
Signed-off-by: Ran Wang
---
drivers/usb/host/ehci-fsl.c |7 +--
drivers/usb/host/fsl-mph-dr-of.c |6 ++
include/linux/fsl_devices.h |7 ---
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 59ebe1b..2aa408a 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -304,14 +304,9 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
return -EINVAL;
if (pdata->operating_mode == FSL_USB2_MPH_HOST) {
- unsigned int chip, rev, svr;
-
- svr = mfspr(SPRN_SVR);
- chip = svr >> 16;
- rev = (svr >> 4) & 0xf;
/* Deal with USB Erratum #14 on MPC834x Rev 1.0 & 1.1 chips */
- if ((rev == 1) && (chip >= 0x8050) && (chip <= 0x8055))
+ if (pdata->has_fsl_erratum_14 == 1)
ehci->has_fsl_port_bug = 1;
if (pdata->port_enables & FSL_USB2_PORT0_ENABLED)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 677f9d5..4f8b8a0 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -225,6 +225,12 @@ static int fsl_usb2_mph_dr_of_probe(struct platform_device
*ofdev)
pdata->has_fsl_erratum_a005697 =
of_property_read_bool(np, "fsl,usb_erratum-a005697");
+ if (of_get_property(np, "fsl,usb_erratum_14", NULL))
+ pdata->has_fsl_erratum_14 = 1;
+ else
+ pdata->has_fsl_erratum_14 = 0;
+
+
/*
* Determine whether phy_clk_valid needs to be checked
* by reading property in device tree
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 60cef82..7aa51bc 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -98,10 +98,11 @@ struct fsl_usb2_platform_data {
unsignedsuspended:1;
unsignedalready_suspended:1;
- unsignedhas_fsl_erratum_a007792:1;
- unsignedhas_fsl_erratum_a005275:1;
+ unsignedhas_fsl_erratum_a007792:1;
+ unsignedhas_fsl_erratum_14:1;
+ unsignedhas_fsl_erratum_a005275:1;
unsignedhas_fsl_erratum_a005697:1;
- unsignedcheck_phy_clk_valid:1;
+ unsignedcheck_phy_clk_valid:1;
/* register save area for suspend/resume */
u32 pm_command;
--
1.7.1
Re: [PATCH 1/1] net: bridge: fix a bug on using a neighbour cache entry without checking its state
From: David Miller
Date: Mon, 07 Jan 2019 09:10:31 -0800
> From: David Miller
>
From: kchen
Date: Sun, 6 Jan 2019 11:28:13 +0800
From: JianJhen Chen
When handling DNAT'ed packets on a bridge device, the neighbour cache entry
from lookup was used without checking its state. It means that a cache entry
in the NUD_STALE state will be used directly instead of entering the NUD_DELAY
state to confirm the reachability of the neighbor.
This problem becomes worse after commit 2724680bceee ("neigh: Keep neighbour
cache entries if number of them is small enough."), since all neighbour cache
entries in the NUD_STALE state will be kept in the neighbour table as long as
the number of cache entries does not exceed the value specified in gc_thresh1.
This commit validates the state of a neighbour cache entry before using
the entry.
Signed-off-by: JianJhen Chen
Reviewed-by: JinLin Chen
Indeed, this looks correct.
Applied and queued up for -stable, thanks.
Thank you for the confirmation.
[PATCH 1/3] usb: kconfig: remove dependency FSL_SOC for ehci fsl driver
From: Rajesh Bhagat CONFIG_USB_EHCI_FSL is not dependent on FSL_SOC, it can be built on non-PPC platforms. Signed-off-by: Rajesh Bhagat Signed-off-by: Ran Wang --- drivers/usb/host/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 16758b1..53cbc0c 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -179,8 +179,8 @@ config XPS_USB_HCD_XILINX devices only. config USB_EHCI_FSL - tristate "Support for Freescale PPC on-chip EHCI USB controller" - depends on FSL_SOC + tristate "Support for Freescale on-chip EHCI USB controller" + depends on USB_EHCI_HCD select USB_EHCI_ROOT_HUB_TT ---help--- Variation of ARC USB block used in some Freescale chips. -- 1.7.1
Re: WARNING in ep_poll_callback
On Tue, Jan 8, 2019 at 6:59 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:139287cc2cc0 Add linux-next specific files for 20190108 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=16f563d740 > kernel config: https://syzkaller.appspot.com/x/.config?x=1521b074ff5a5bdf > dashboard link: https://syzkaller.appspot.com/bug?extid=aea82bf9ee6ffd9a79d9 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. Looks like caused by: commit f92cacf118171208f62519d92502a8dd0341286d Author: Roman Penyaev Date: Tue Jan 8 12:15:44 2019 +1100 epoll: loosen irq safety in ep_poll_callback() > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+aea82bf9ee6ffd9a7...@syzkaller.appspotmail.com > > [ cut here ] > IRQs not disabled as expected > WARNING: CPU: 1 PID: 27199 at fs/eventpoll.c:1224 > ep_poll_callback+0x77e/0x1450 fs/eventpoll.c:1224 > Kernel panic - not syncing: panic_on_warn set ... > CPU: 1 PID: 27199 Comm: syz-executor4 Not tainted 5.0.0-rc1-next-20190108 #7 > 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+0x1db/0x2d0 lib/dump_stack.c:113 > panic+0x2cb/0x65c kernel/panic.c:214 > __warn.cold+0x20/0x48 kernel/panic.c:571 > report_bug+0x263/0x2b0 lib/bug.c:186 > fixup_bug arch/x86/kernel/traps.c:178 [inline] > fixup_bug arch/x86/kernel/traps.c:173 [inline] > do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 > do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290 > invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 > RIP: 0010:ep_poll_callback+0x77e/0x1450 fs/eventpoll.c:1224 > Code: ff 44 89 ee e8 63 84 98 ff 45 84 ed 0f 85 4a fa ff ff e8 15 83 98 ff > 48 c7 c7 00 69 56 88 c6 05 a1 b2 6e 08 01 e8 52 c8 61 ff <0f> 0b e9 2b fa > ff ff e8 f6 82 98 ff 48 8d 7b 30 48 b8 00 00 00 00 > RSP: 0018:8880533776a0 EFLAGS: 00010282 > RAX: RBX: 88804df7ee40 RCX: c9000de3b000 > RDX: 00012c8d RSI: 816869f6 RDI: 0005 > RBP: 888053377880 R08: 8880a078a700 R09: 8880a078aff0 > R10: 8880a078a700 R11: R12: 888053377858 > R13: R14: 88804df7ee90 R15: > __wake_up_common+0x1d3/0x7d0 kernel/sched/wait.c:92 > __wake_up_locked+0x11/0x20 kernel/sched/wait.c:154 > fuse_abort_conn+0xd01/0x1200 fs/fuse/dev.c:2212 > fuse_sb_destroy+0xd3/0x1d0 fs/fuse/inode.c:1245 > fuse_kill_sb_anon+0x16/0x30 fs/fuse/inode.c:1256 > deactivate_locked_super+0x9a/0x100 fs/super.c:331 > deactivate_super fs/super.c:362 [inline] > deactivate_super+0x2ab/0x320 fs/super.c:358 > cleanup_mnt+0xbf/0x160 fs/namespace.c:1140 > __cleanup_mnt+0x16/0x20 fs/namespace.c:1147 > task_work_run+0x1f4/0x2b0 kernel/task_work.c:113 > tracehook_notify_resume include/linux/tracehook.h:188 [inline] > exit_to_usermode_loop+0x32a/0x3b0 arch/x86/entry/common.c:166 > prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] > syscall_return_slowpath arch/x86/entry/common.c:268 [inline] > do_syscall_64+0x696/0x800 arch/x86/entry/common.c:293 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x457ec9 > Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7f19fdcaec78 EFLAGS: 0246 ORIG_RAX: 00a6 > RAX: RBX: 0002 RCX: 00457ec9 > RDX: RSI: RDI: 2040 > RBP: 0073bf00 R08: R09: > R10: R11: 0246 R12: 7f19fdcaf6d4 > R13: 004c6ab2 R14: 004dbdb8 R15: > Kernel Offset: disabled > Rebooting in 86400 seconds.. > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with > syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/d8bec0057eec0a92%40google.com. > For more options, visit https://groups.google.com/d/optout.
WARNING in ep_poll_callback
Hello, syzbot found the following crash on: HEAD commit:139287cc2cc0 Add linux-next specific files for 20190108 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=16f563d740 kernel config: https://syzkaller.appspot.com/x/.config?x=1521b074ff5a5bdf dashboard link: https://syzkaller.appspot.com/bug?extid=aea82bf9ee6ffd9a79d9 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+aea82bf9ee6ffd9a7...@syzkaller.appspotmail.com [ cut here ] IRQs not disabled as expected WARNING: CPU: 1 PID: 27199 at fs/eventpoll.c:1224 ep_poll_callback+0x77e/0x1450 fs/eventpoll.c:1224 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 27199 Comm: syz-executor4 Not tainted 5.0.0-rc1-next-20190108 #7 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+0x1db/0x2d0 lib/dump_stack.c:113 panic+0x2cb/0x65c kernel/panic.c:214 __warn.cold+0x20/0x48 kernel/panic.c:571 report_bug+0x263/0x2b0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] fixup_bug arch/x86/kernel/traps.c:173 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 RIP: 0010:ep_poll_callback+0x77e/0x1450 fs/eventpoll.c:1224 Code: ff 44 89 ee e8 63 84 98 ff 45 84 ed 0f 85 4a fa ff ff e8 15 83 98 ff 48 c7 c7 00 69 56 88 c6 05 a1 b2 6e 08 01 e8 52 c8 61 ff <0f> 0b e9 2b fa ff ff e8 f6 82 98 ff 48 8d 7b 30 48 b8 00 00 00 00 RSP: 0018:8880533776a0 EFLAGS: 00010282 RAX: RBX: 88804df7ee40 RCX: c9000de3b000 RDX: 00012c8d RSI: 816869f6 RDI: 0005 RBP: 888053377880 R08: 8880a078a700 R09: 8880a078aff0 R10: 8880a078a700 R11: R12: 888053377858 R13: R14: 88804df7ee90 R15: __wake_up_common+0x1d3/0x7d0 kernel/sched/wait.c:92 __wake_up_locked+0x11/0x20 kernel/sched/wait.c:154 fuse_abort_conn+0xd01/0x1200 fs/fuse/dev.c:2212 fuse_sb_destroy+0xd3/0x1d0 fs/fuse/inode.c:1245 fuse_kill_sb_anon+0x16/0x30 fs/fuse/inode.c:1256 deactivate_locked_super+0x9a/0x100 fs/super.c:331 deactivate_super fs/super.c:362 [inline] deactivate_super+0x2ab/0x320 fs/super.c:358 cleanup_mnt+0xbf/0x160 fs/namespace.c:1140 __cleanup_mnt+0x16/0x20 fs/namespace.c:1147 task_work_run+0x1f4/0x2b0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x32a/0x3b0 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x696/0x800 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457ec9 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f19fdcaec78 EFLAGS: 0246 ORIG_RAX: 00a6 RAX: RBX: 0002 RCX: 00457ec9 RDX: RSI: RDI: 2040 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7f19fdcaf6d4 R13: 004c6ab2 R14: 004dbdb8 R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
Re: [PATCH v3 04/16] Platform: OLPC: Move OLPC config symbol out of x86 tree
Hi Lubomir,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc1 next-20190107]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Lubomir-Rintel/Add-support-for-OLPC-XO-1-75-Embedded-Controller/20190108-114514
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
>> sound/pci/cs5535audio/cs5535audio_olpc.c:28:6: error: redefinition of
>> 'olpc_analog_input'
void olpc_analog_input(struct snd_ac97 *ac97, int on)
^
In file included from sound/pci/cs5535audio/cs5535audio_olpc.c:19:0:
sound/pci/cs5535audio/cs5535audio.h:131:20: note: previous definition of
'olpc_analog_input' was here
static inline void olpc_analog_input(struct snd_ac97 *ac97, int on) { }
^
>> sound/pci/cs5535audio/cs5535audio_olpc.c:51:6: error: redefinition of
>> 'olpc_mic_bias'
void olpc_mic_bias(struct snd_ac97 *ac97, int on)
^
In file included from sound/pci/cs5535audio/cs5535audio_olpc.c:19:0:
sound/pci/cs5535audio/cs5535audio.h:132:20: note: previous definition of
'olpc_mic_bias' was here
static inline void olpc_mic_bias(struct snd_ac97 *ac97, int on) { }
^
>> sound/pci/cs5535audio/cs5535audio_olpc.c:137:6: error: redefinition of
>> 'olpc_prequirks'
void olpc_prequirks(struct snd_card *card,
^~
In file included from sound/pci/cs5535audio/cs5535audio_olpc.c:19:0:
sound/pci/cs5535audio/cs5535audio.h:124:20: note: previous definition of
'olpc_prequirks' was here
static inline void olpc_prequirks(struct snd_card *card,
^~
sound/pci/cs5535audio/cs5535audio_olpc.c: In function 'olpc_prequirks':
>> sound/pci/cs5535audio/cs5535audio_olpc.c:144:6: error: implicit declaration
>> of function 'olpc_board_at_least' [-Werror=implicit-function-declaration]
if (olpc_board_at_least(olpc_board_pre(0xb3)))
^~~
>> sound/pci/cs5535audio/cs5535audio_olpc.c:144:26: error: implicit declaration
>> of function 'olpc_board_pre'; did you mean 'olpc_mic_put'?
>> [-Werror=implicit-function-declaration]
if (olpc_board_at_least(olpc_board_pre(0xb3)))
^~
olpc_mic_put
sound/pci/cs5535audio/cs5535audio_olpc.c: At top level:
>> sound/pci/cs5535audio/cs5535audio_olpc.c:148:5: error: redefinition of
>> 'olpc_quirks'
int olpc_quirks(struct snd_card *card, struct snd_ac97 *ac97)
^~~
In file included from sound/pci/cs5535audio/cs5535audio_olpc.c:19:0:
sound/pci/cs5535audio/cs5535audio.h:126:19: note: previous definition of
'olpc_quirks' was here
static inline int olpc_quirks(struct snd_card *card, struct snd_ac97 *ac97)
^~~
>> sound/pci/cs5535audio/cs5535audio_olpc.c:189:6: error: redefinition of
>> 'olpc_quirks_cleanup'
void olpc_quirks_cleanup(void)
^~~
In file included from sound/pci/cs5535audio/cs5535audio_olpc.c:19:0:
sound/pci/cs5535audio/cs5535audio.h:130:20: note: previous definition of
'olpc_quirks_cleanup' was here
static inline void olpc_quirks_cleanup(void) { }
^~~
cc1: some warnings being treated as errors
--
In file included from include/linux/export.h:45:0,
from include/linux/linkage.h:7,
from include/linux/kernel.h:7,
from drivers/staging/olpc_dcon/olpc_dcon.c:13:
drivers/staging/olpc_dcon/olpc_dcon.c: In function 'dcon_bus_stabilize':
>> drivers/staging/olpc_dcon/olpc_dcon.c:141:10: error: implicit declaration of
>> function 'olpc_board_at_least' [-Werror=implicit-function-declaration]
BUG_ON(olpc_board_at_least(olpc_board(0xc2)));
^
include/linux/compiler.h:77:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
>> drivers/staging/olpc_dcon/olpc_dcon.c:141:3: note: in expansion of macro
>> 'BUG_ON'
BUG_ON(olpc_board_at_least(olpc_board(0xc2)));
^~
>> drivers/staging/olpc_dcon/olpc_dcon.c:141:30: error: implicit declaration of
>> function 'olpc_board'; did you mean 'olpc_ec_cmd'?
>> [-Werror=implicit-function-declaration]
BUG_ON(olpc_board_at_least(olpc_board(0xc2)));
^
include/linux/compiler.h:77:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_e
Re: [PATCH v3 15/16] power: supply: olpc_battery: Avoid using platform_info
Hi Lubomir, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.0-rc1 next-20190107] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Lubomir-Rintel/Add-support-for-OLPC-XO-1-75-Embedded-Controller/20190108-114514 config: i386-randconfig-s3-201901 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): >> WARNING: vmlinux.o(.text+0x49efd): Section mismatch in reference from the >> function olpc_dt_compatible_match() to the function >> .init.text:olpc_dt_getproperty() The function olpc_dt_compatible_match() references the function __init olpc_dt_getproperty(). This is often because olpc_dt_compatible_match lacks a __init annotation or the annotation of olpc_dt_getproperty is wrong. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [RFC PATCH 0/4] x86_64/mm: remove bottom-up allocation style by pushing forward the parsing of mem hotplug info
On Tue, Jan 8, 2019 at 1:04 AM Dave Hansen wrote: > > On 1/7/19 12:24 AM, Pingfan Liu wrote: > > Background about the defect of the current bottom-up allocation style, take > > the following scenario: > > | unmovable node | movable node | > > | kaslr-kernel |subtree of pgtable for phy<->virt | > > > > Although kaslr-kernel can avoid to stain the movable node. But the > > pgtable can still stain the movable node. That is a probability problem, > > with low probability, but still exist. This patch tries to eliminate the > > probability. With the previous patch, at the point of init_mem_mapping(), > > memblock allocator can work with the knowledge of acpi memory hotmovable > > info, and avoid to stain the movable node. As a result, > > memory_map_bottom_up() is not needed any more. > > I'm really missing the basic problem statement. What's the problem this > is fixing? What is the end-user-visible impact of this problem? > Sorry for the misaligned figure. It should be | kaslr-kernel|subtree of pgtable for phy<->virt| |--- boundary between unmovable node and movable node Where kaslr kernel can be guaranteed to sit inside unmovable node after patch: https://lore.kernel.org/patchwork/patch/1029376/. But if kaslr kernel is located near the end of the movable node, then bottom-up allocator may create pagetable which crosses the boundary between unmovable node and movable node. It is a probability issue, the factors include -1. how big the gap between kernel end and unmovable node's end. -2. how many memory does the system own. Alternative way to fix this issue is by increasing the gap by boot/compressed/kaslr*. But taking the scenario of PB level memory, the pagetable will take server MB even if using 1GB page, so it is hard to decide how much should the gap increase. In a word, this series fix the probability with certainty, by allocating pagetable on unmovable node, instead of following kernel end. > To make memory hot-remove work, we want as much memory as possible to he > hot-removable, which is basically what movable nodes are used for. But, > it sounds like, maybe, that KASLR can place the kernel image inside the > movable node. This is somehow related to the bottom-up allocation style > currently in use. Yes, currently kaslr kernel can stain the movable node, but it will not do this soon after the patch: https://lore.kernel.org/patchwork/patch/1029376/ Thanks, Pingfan
Re: [PATCH v4 5/6] usb: musb: gadget: implement optional explicit status stage
On Sun, Jan 06, 2019 at 03:03:09PM -0500, Alan Stern wrote: > On Sun, 6 Jan 2019, Paul Elder wrote: > > > Implement the mechanism for optional explicit status stage for the MUSB > > driver. This allows a function driver to specify what to reply for the > > status stage. The functionality for an implicit status stage is > > retained. > > > > Signed-off-by: Paul Elder > > v1 Reviewed-by: Laurent Pinchart > > v1 Acked-by: Bin Liu > > --- > > No change from v3 > > > > Changes from v2: > > - update call to usb_gadget_control_complete to include status > > - since sending STALL from the function driver is now done with > > usb_ep_set_halt, there is no need for the internal ep0_send_response to > > take a stall/ack parameter; remove the parameter and make the function > > only send ack, and remove checking for the status reply in the > > usb_request for the status stage > > > > Changes from v1: > > - obvious change to implement v2 mechanism laid out by 4/6 of this > > series (send_response, and musb_g_ep0_send_response function has > > been removed, call to usb_gadget_control_complete has been added) > > - ep0_send_response's ack argument has been changed from stall > > - last_packet flag in ep0_rxstate has been removed, since it is equal to > > req != NULL > > > > drivers/usb/musb/musb_gadget.c | 2 ++ > > drivers/usb/musb/musb_gadget_ep0.c | 23 +++ > > 2 files changed, 25 insertions(+) > > > > diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c > > index d3f33f449445..a7a992ab0c9d 100644 > > --- a/drivers/usb/musb/musb_gadget.c > > +++ b/drivers/usb/musb/musb_gadget.c > > @@ -145,6 +145,8 @@ __acquires(ep->musb->lock) > > > > trace_musb_req_gb(req); > > usb_gadget_giveback_request(>ep->end_point, >request); > > + usb_gadget_control_complete(>g, request->explicit_status, > > + request->status); > > I haven't paid much attention to this part of the patch series, not > knowing much about musb. Still, it's clear that > usb_gadget_control_complete should be called only for transfers on > ep0. You need to test the endpoint value. Oh oops, yeah, you're right. > Another problem: the completion handler may deallocate the request. > Dereferencing request->expicit_status and request->status would then > cause errors. Would it be preferable to call > usb_gadget_control_complete before usb_gadget_giveback_request? If > it gets done that way then the arguments could be simplified: we could > pass a pointer to the request instead of the separate explicit_status > and status values. I thought that usb_gadget_control_complete needs to check the status of the request that was given back. Doesn't that mean that usb_gadget_giveback_request must be called first? I was thinking that maybe we could save explicit_status before calling usb_gadget_giveback_request, and if request is still valid then we can pull status from it otherwise use 0, but then would that be considered adding complexity to UDCs that want to implement optional status stage delay? Or add a wrapper function? On the other hand, if we do put usb_gadget_control_complete before usb_gadget_giveback_request, then the control transfer would complete before the function driver has a chance to complete, but if the function driver wanted to intervene/determine the status stage then it would have gone through the new mechanism that we're making here. So it could be fine to switch the order. My tests for it work too, so I guess we'll go with usb_gadget_control_complete before usb_gadget_giveback_request then. In that case usb_gadget_control_complete doesn't need to check the status of the request, since there isn't any, right? Thanks, Paul Elder
[PATCH] x86:kernel:e820c:kmemdup instead of duplicating its function
From: "huang.zijiang" kmemdup has implemented the function that kmalloc() and memcpy(). Signed-off-by: huang.zijiang --- arch/x86/kernel/e820.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 50895c2..a687d10 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -671,21 +671,18 @@ __init void e820__reallocate_tables(void) int size; size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table->nr_entries; - n = kmalloc(size, GFP_KERNEL); + n = kmemdup(e820_table, size, GFP_KERNEL); BUG_ON(!n); - memcpy(n, e820_table, size); e820_table = n; size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table_kexec->nr_entries; - n = kmalloc(size, GFP_KERNEL); + n = kmemdup(e820_table_kexec, size, GFP_KERNEL); BUG_ON(!n); - memcpy(n, e820_table_kexec, size); e820_table_kexec = n; size = offsetof(struct e820_table, entries) + sizeof(struct e820_entry)*e820_table_firmware->nr_entries; - n = kmalloc(size, GFP_KERNEL); + n = kmemdup(e820_table_firmware, size, GFP_KERNEL); BUG_ON(!n); - memcpy(n, e820_table_firmware, size); e820_table_firmware = n; } -- 1.8.3.1
[PATCH] virtio:linux:kernel:NULL check after kmalloc is needed
From: "huang.zijiang"
NULL check is needed because kmalloc maybe return NULL.
Signed-off-by: huang.zijiang
---
tools/virtio/linux/kernel.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/virtio/linux/kernel.h b/tools/virtio/linux/kernel.h
index 7ef45a4..2afcad8 100644
--- a/tools/virtio/linux/kernel.h
+++ b/tools/virtio/linux/kernel.h
@@ -65,6 +65,8 @@ static inline void *kzalloc(size_t s, gfp_t gfp)
{
void *p = kmalloc(s, gfp);
+ if (!p)
+ return -ENOMEM;
memset(p, 0, s);
return p;
}
--
1.8.3.1
Re: CFS scheduler: spin_lock usage causes dead lock when smp_apic_timer_interrupt occurs
On Mon, 2019-01-07 at 13:52 +0100, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 01:28:34PM +0100, Mike Galbraith wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 960ad0ce77d7..420624c49f38 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -5007,9 +5007,9 @@ void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
> > cfs_b->period = ns_to_ktime(default_cfs_period());
> >
> > INIT_LIST_HEAD(_b->throttled_cfs_rq);
> > - hrtimer_init(_b->period_timer, CLOCK_MONOTONIC,
> > HRTIMER_MODE_ABS_PINNED);
> > + hrtimer_init(_b->period_timer, CLOCK_MONOTONIC,
> > HRTIMER_MODE_ABS_PINNED_HARD);
> > cfs_b->period_timer.function = sched_cfs_period_timer;
> > - hrtimer_init(_b->slack_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> > + hrtimer_init(_b->slack_timer, CLOCK_MONOTONIC,
> > HRTIMER_MODE_REL_HARD);
> > cfs_b->slack_timer.function = sched_cfs_slack_timer;
> > }
>
> Right, that should sort it. But I'm not sure this is the best solution
> though. That cfs-runtime crud can (IIRC) iterate lists etc.. so running
> it from the softirq isn't a bad idea. We just need to fix that locking
> up a bit.
>
> Something a wee bit like so perhaps..
I plugged that into 4.19-rt along with revert of hard irq context, and
it (as expected) does the trick.
> ---
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 13776fac7b74..3cfe26aa098a 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4566,7 +4566,7 @@ static u64 distribute_cfs_runtime(struct cfs_bandwidth
> *cfs_b,
> struct rq *rq = rq_of(cfs_rq);
> struct rq_flags rf;
>
> - rq_lock(rq, );
> + rq_lock_irqsave(rq, );
> if (!cfs_rq_throttled(cfs_rq))
> goto next;
>
> @@ -4583,7 +4583,7 @@ static u64 distribute_cfs_runtime(struct cfs_bandwidth
> *cfs_b,
> unthrottle_cfs_rq(cfs_rq);
>
> next:
> - rq_unlock(rq, );
> + rq_unlock_irqrestore(rq, );
>
> if (!remaining)
> break;
> @@ -4599,7 +4599,7 @@ static u64 distribute_cfs_runtime(struct cfs_bandwidth
> *cfs_b,
> * period the timer is deactivated until scheduling resumes; cfs_b->idle is
> * used to track this state.
> */
> -static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int
> overrun)
> +static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int
> overrun, unsigned long flags)
> {
> u64 runtime, runtime_expires;
> int throttled;
> @@ -4641,11 +4641,11 @@ static int do_sched_cfs_period_timer(struct
> cfs_bandwidth *cfs_b, int overrun)
> while (throttled && cfs_b->runtime > 0 && !cfs_b->distribute_running) {
> runtime = cfs_b->runtime;
> cfs_b->distribute_running = 1;
> - raw_spin_unlock(_b->lock);
> + raw_spin_unlock_irqrestore(_b->lock, flags);
> /* we can't nest cfs_b->lock while distributing bandwidth */
> runtime = distribute_cfs_runtime(cfs_b, runtime,
>runtime_expires);
> - raw_spin_lock(_b->lock);
> + raw_spin_lock_irqsave(_b->lock, flags);
>
> cfs_b->distribute_running = 0;
> throttled = !list_empty(_b->throttled_cfs_rq);
> @@ -4754,17 +4754,18 @@ static __always_inline void
> return_cfs_rq_runtime(struct cfs_rq *cfs_rq)
> static void do_sched_cfs_slack_timer(struct cfs_bandwidth *cfs_b)
> {
> u64 runtime = 0, slice = sched_cfs_bandwidth_slice();
> + unsigned long flags;
> u64 expires;
>
> /* confirm we're still not at a refresh boundary */
> - raw_spin_lock(_b->lock);
> + raw_spin_lock_irqsave(_b->lock, flags);
> if (cfs_b->distribute_running) {
> - raw_spin_unlock(_b->lock);
> + raw_spin_unlock_irqrestore(_b->lock, flags);
> return;
> }
>
> if (runtime_refresh_within(cfs_b, min_bandwidth_expiration)) {
> - raw_spin_unlock(_b->lock);
> + raw_spin_unlock_irqrestore(_b->lock, flags);
> return;
> }
>
> @@ -4775,18 +4776,18 @@ static void do_sched_cfs_slack_timer(struct
> cfs_bandwidth *cfs_b)
> if (runtime)
> cfs_b->distribute_running = 1;
>
> - raw_spin_unlock(_b->lock);
> + raw_spin_unlock_irqrestore(_b->lock, flags);
>
> if (!runtime)
> return;
>
> runtime = distribute_cfs_runtime(cfs_b, runtime, expires);
>
> - raw_spin_lock(_b->lock);
> + raw_spin_lock_irqsave(_b->lock, flags);
> if (expires == cfs_b->runtime_expires)
> lsub_positive(_b->runtime, runtime);
> cfs_b->distribute_running = 0;
> - raw_spin_unlock(_b->lock);
> + raw_spin_unlock_irqrestore(_b->lock, flags);
> }
>
> /*
> @@ -4864,20 +4865,21 @@ static enum hrtimer_restart
>
Re: [PATCH v3 1/3] virtio-balloon: tweak config_changed implementation
On 01/07/2019 09:49 PM, Christian Borntraeger wrote: On 07.01.2019 08:01, Wei Wang wrote: virtio-ccw has deadlock issues with reading the config space inside the interrupt context, so we tweak the virtballoon_changed implementation by moving the config read operations into the related workqueue contexts. The config_read_bitmap is used as a flag to the workqueue callbacks about the related config fields that need to be read. The cmd_id_received is also renamed to cmd_id_received_cache, and the value should be obtained via virtio_balloon_cmd_id_received. Reported-by: Christian Borntraeger Signed-off-by: Wei Wang Reviewed-by: Cornelia Huck Reviewed-by: Halil Pasic Together with virtio_pci: use queue idx instead of array idx to set up the vq virtio: don't allocate vqs when names[i] = NULL Tested-by: Christian Borntraeger OK. I don't plan to send a new version of the above patches as no changes needed so far. Michael, if the above two patches look good to you, please help add the related tested-by and reviewed-by tags. Thanks. Best, Wei
[RFC v2 5/6] mfd: add EC host command support using rpmsg.
Add EC host command support through rpmsg.
Cc: Enric Balletbo Serra
Cc: Guenter Roeck
Signed-off-by: Pi-Hsun Shih
---
Changes from v1:
- Code format fix based on feedback for cros_ec_rpmsg.c.
- Extract feature detection for SCP into separate patch (Patch 6).
---
drivers/platform/chrome/Kconfig | 8 ++
drivers/platform/chrome/Makefile| 1 +
drivers/platform/chrome/cros_ec_rpmsg.c | 159
3 files changed, 168 insertions(+)
create mode 100644 drivers/platform/chrome/cros_ec_rpmsg.c
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index 16b1615958aa2d..e3f63f3d67711b 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -72,6 +72,14 @@ config CROS_EC_SPI
response time cannot be guaranteed, we support ignoring
'pre-amble' bytes before the response actually starts.
+config CROS_EC_RPMSG
+ tristate "ChromeOS Embedded Controller (rpmsg)"
+ depends on MFD_CROS_EC && RPMSG && OF
+ help
+ If you say Y here, you get support for talking to the ChromeOS EC
+ through rpmsg. This uses a simple byte-level protocol with a
+ checksum.
+
config CROS_EC_LPC
tristate "ChromeOS Embedded Controller (LPC)"
depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST)
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index cd591bf872bbe9..3e3190af2b50f4 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -8,6 +8,7 @@ cros_ec_ctl-objs:= cros_ec_sysfs.o
cros_ec_lightbar.o \
obj-$(CONFIG_CROS_EC_CTL) += cros_ec_ctl.o
obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
+obj-$(CONFIG_CROS_EC_RPMSG)+= cros_ec_rpmsg.o
cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_reg.o
cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpcs.o
diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c
b/drivers/platform/chrome/cros_ec_rpmsg.c
new file mode 100644
index 00..92c967b4db4862
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_rpmsg.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright 2018 Google LLC.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * cros_ec_cmd_xfer_rpmsg - Transfer a message over rpmsg and receive the reply
+ *
+ * This is only used for old EC proto version, and is not supported for this
+ * driver.
+ *
+ * @ec_dev: ChromeOS EC device
+ * @ec_msg: Message to transfer
+ */
+static int cros_ec_cmd_xfer_rpmsg(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *ec_msg)
+{
+ return -EINVAL;
+}
+
+/**
+ * cros_ec_pkt_xfer_rpmsg - Transfer a packet over rpmsg and receive the reply
+ *
+ * @ec_dev: ChromeOS EC device
+ * @ec_msg: Message to transfer
+ */
+static int cros_ec_pkt_xfer_rpmsg(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *ec_msg)
+{
+ struct ec_host_response *response;
+ struct rpmsg_device *rpdev = ec_dev->priv;
+ int len;
+ u8 sum;
+ int ret;
+ int i;
+
+ ec_msg->result = 0;
+ len = cros_ec_prepare_tx(ec_dev, ec_msg);
+ dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
+
+ /*
+* TODO: This currently relies on that mtk_rpmsg send actually blocks
+* until ack. Should do the wait here instead.
+*/
+ ret = rpmsg_send(rpdev->ept, ec_dev->dout, len);
+ if (ret) {
+ dev_err(ec_dev->dev, "rpmsg send failed\n");
+ return ret;
+ }
+
+ /* check response error code */
+ response = (struct ec_host_response *)ec_dev->din;
+ ec_msg->result = response->result;
+
+ ret = cros_ec_check_result(ec_dev, ec_msg);
+ if (ret)
+ goto exit;
+
+ if (response->data_len > ec_msg->insize) {
+ dev_err(ec_dev->dev, "packet too long (%d bytes, expected %d)",
+ response->data_len, ec_msg->insize);
+ ret = -EMSGSIZE;
+ goto exit;
+ }
+
+ /* copy response packet payload and compute checksum */
+ memcpy(ec_msg->data, ec_dev->din + sizeof(*response),
+ response->data_len);
+
+ sum = 0;
+ for (i = 0; i < sizeof(*response) + response->data_len; i++)
+ sum += ec_dev->din[i];
+
+ if (sum) {
+ dev_err(ec_dev->dev, "bad packet checksum, calculated %x\n",
+ sum);
+ ret = -EBADMSG;
+ goto exit;
+ }
+
+ ret = response->data_len;
+exit:
+ if (ec_msg->command == EC_CMD_REBOOT_EC)
+ msleep(EC_REBOOT_DELAY_MS);
+
+ return ret;
+}
+
+static int
[RFC v2 2/6] remoteproc/mediatek: add SCP support for mt8183
From: Erin Lo
Provide a basic driver to control Cortex M4 co-processor
Signed-off-by: Erin Lo
Signed-off-by: Nicolas Boichat
---
Changes from v1:
- Extract functions and rename variables in mtk_scp.c.
---
drivers/remoteproc/Kconfig| 9 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/mtk_scp.c | 587 ++
include/linux/platform_data/mtk_scp.h | 122 ++
4 files changed, 719 insertions(+)
create mode 100644 drivers/remoteproc/mtk_scp.c
create mode 100644 include/linux/platform_data/mtk_scp.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f0abd260804473..ee0bda23768938 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -22,6 +22,15 @@ config IMX_REMOTEPROC
It's safe to say N here.
+config MTK_SCP
+tristate "Mediatek SCP support"
+depends on ARCH_MEDIATEK
+help
+ Say y here to support Mediatek's SCP (Cortex M4
+ on MT8183) via the remote processor framework.
+
+ It's safe to say N here.
+
config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
depends on ARCH_OMAP4 || SOC_OMAP5
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ce5d061e92be52..98e3498dbbe0e2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -10,6 +10,7 @@ remoteproc-y += remoteproc_sysfs.o
remoteproc-y += remoteproc_virtio.o
remoteproc-y += remoteproc_elf_loader.o
obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
+obj-$(CONFIG_MTK_SCP) += mtk_scp.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
new file mode 100644
index 00..6e2e17a227d018
--- /dev/null
+++ b/drivers/remoteproc/mtk_scp.c
@@ -0,0 +1,587 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018 MediaTek Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "remoteproc_internal.h"
+
+#define MT8183_SW_RSTN 0x0
+#define MT8183_SW_RSTN_BIT BIT(0)
+#define MT8183_SCP_TO_HOST 0x1C
+#define MT8183_SCP_IPC_INT_BIT BIT(0)
+#define MT8183_SCP_WDT_INT_BIT BIT(8)
+#define MT8183_HOST_TO_SCP 0x28
+#define MT8183_HOST_IPC_INT_BITBIT(0)
+#define MT8183_SCP_SRAM_PDN0x402C
+
+#define SCP_FW_VER_LEN 32
+
+#define MAX_CODE_SIZE 0x50
+
+struct scp_run {
+ u32 signaled;
+ s8 fw_ver[SCP_FW_VER_LEN];
+ u32 dec_capability;
+ u32 enc_capability;
+ wait_queue_head_t wq;
+};
+
+struct scp_ipi_desc {
+ scp_ipi_handler_t handler;
+ const char *name;
+ void *priv;
+};
+
+struct mtk_scp {
+ struct device *dev;
+ struct rproc *rproc;
+ struct clk *clk;
+ void __iomem *reg_base;
+ void __iomem *sram_base;
+ size_t sram_size;
+
+ struct share_obj *recv_buf;
+ struct share_obj *send_buf;
+ struct scp_run run;
+ struct mutex scp_mutex; /* for protecting mtk_scp data structure */
+ struct scp_ipi_desc ipi_desc[SCP_IPI_MAX];
+ bool ipi_id_ack[SCP_IPI_MAX];
+ wait_queue_head_t ack_wq;
+
+ void __iomem *cpu_addr;
+ phys_addr_t phys_addr;
+ size_t dram_size;
+};
+
+/**
+ * struct share_obj - SRAM buffer shared with
+ * AP and SCP
+ *
+ * @id:IPI id
+ * @len: share buffer length
+ * @share_buf: share buffer data
+ */
+struct share_obj {
+ s32 id;
+ u32 len;
+ u8 share_buf[288];
+};
+
+int scp_ipi_register(struct platform_device *pdev,
+enum scp_ipi_id id,
+scp_ipi_handler_t handler,
+const char *name,
+void *priv)
+{
+ struct mtk_scp *scp = platform_get_drvdata(pdev);
+ struct scp_ipi_desc *ipi_desc;
+
+ if (!scp) {
+ dev_err(>dev, "scp device is not ready\n");
+ return -EPROBE_DEFER;
+ }
+
+ if (WARN(id < 0 || id >= SCP_IPI_MAX || handler == NULL,
+ "register scp ipi id %d with invalid arguments\n", id))
+ return -EINVAL;
+
+ ipi_desc = scp->ipi_desc;
+ ipi_desc[id].name = name;
+ ipi_desc[id].handler = handler;
+ ipi_desc[id].priv = priv;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(scp_ipi_register);
+
+int scp_ipi_send(struct platform_device *pdev,
+enum scp_ipi_id id,
+void *buf,
+unsigned int len,
+unsigned int wait)
+{
+ struct mtk_scp *scp = platform_get_drvdata(pdev);
+ struct share_obj
[RFC v2 4/6] rpmsg: add rpmsg support for mt8183 SCP.
Add a simple rpmsg support for mt8183 SCP, that use IPI / IPC directly.
Lots of TODO, and I'm not sure on all file / type / variable namings.
Signed-off-by: Pi-Hsun Shih
---
Changes from v1:
- Do cleanup properly in mtk_rpmsg.c, which also removes the problem of
short-lived work items.
- Fix several issues checkpatch found.
---
drivers/remoteproc/mtk_common.h | 3 +
drivers/remoteproc/mtk_scp.c | 29 +-
drivers/remoteproc/mtk_scp_ipi.c | 2 +-
drivers/rpmsg/Kconfig | 5 +
drivers/rpmsg/Makefile| 1 +
drivers/rpmsg/mtk_rpmsg.c | 382 ++
include/linux/platform_data/mtk_scp.h | 12 +-
include/linux/rpmsg/mtk_rpmsg.h | 35 +++
8 files changed, 464 insertions(+), 5 deletions(-)
create mode 100644 drivers/rpmsg/mtk_rpmsg.c
create mode 100644 include/linux/rpmsg/mtk_rpmsg.h
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index e97287a4eb25cc..3e9688082edbdc 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -54,6 +54,9 @@ struct mtk_scp {
void __iomem *cpu_addr;
phys_addr_t phys_addr;
size_t dram_size;
+
+ struct platform_device *pdev;
+ struct rproc_subdev *rpmsg_subdev;
};
/**
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 3e84c696523436..7f4d9261504c30 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "mtk_common.h"
#include "remoteproc_internal.h"
@@ -296,6 +297,23 @@ static int scp_map_memory_region(struct mtk_scp *scp)
return 0;
}
+static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
+{
+ scp->rpmsg_subdev =
+ mtk_rpmsg_create_rproc_subdev(scp->pdev, scp->rproc);
+ if (scp->rpmsg_subdev)
+ rproc_add_subdev(scp->rproc, scp->rpmsg_subdev);
+}
+
+static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
+{
+ if (scp->rpmsg_subdev) {
+ rproc_remove_subdev(scp->rproc, scp->rpmsg_subdev);
+ mtk_rpmsg_destroy_rproc_subdev(scp->rpmsg_subdev);
+ scp->rpmsg_subdev = NULL;
+ }
+}
+
static int mtk_scp_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -319,6 +337,7 @@ static int mtk_scp_probe(struct platform_device *pdev)
scp = (struct mtk_scp *)rproc->priv;
scp->rproc = rproc;
scp->dev = dev;
+ scp->pdev = pdev;
platform_set_drvdata(pdev, scp);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
@@ -390,13 +409,16 @@ static int mtk_scp_probe(struct platform_device *pdev)
init_waitqueue_head(>run.wq);
init_waitqueue_head(>ack_wq);
+ scp_add_rpmsg_subdev(scp);
+
ret = rproc_add(rproc);
if (ret)
- goto destroy_mutex;
+ goto remove_subdev;
- return ret;
+ return 0;
-destroy_mutex:
+remove_subdev:
+ scp_remove_rpmsg_subdev(scp);
mutex_destroy(>scp_mutex);
free_rproc:
rproc_free(rproc);
@@ -408,6 +430,7 @@ static int mtk_scp_remove(struct platform_device *pdev)
{
struct mtk_scp *scp = platform_get_drvdata(pdev);
+ scp_remove_rpmsg_subdev(scp);
rproc_del(scp->rproc);
rproc_free(scp->rproc);
diff --git a/drivers/remoteproc/mtk_scp_ipi.c b/drivers/remoteproc/mtk_scp_ipi.c
index 3aa18a387056d3..e51d0b970e500f 100644
--- a/drivers/remoteproc/mtk_scp_ipi.c
+++ b/drivers/remoteproc/mtk_scp_ipi.c
@@ -49,7 +49,7 @@ int scp_ipi_send(struct platform_device *pdev,
unsigned long timeout;
int ret;
- if (WARN(id <= SCP_IPI_INIT || id >= SCP_IPI_MAX ||
+ if (WARN(id <= SCP_IPI_NS_SERVICE || id >= SCP_IPI_MAX ||
len > sizeof(send_obj->share_buf) || !buf,
"failed to send ipi message\n"))
return -EINVAL;
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index d0322b41eca54c..b8364a397bb606 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -55,4 +55,9 @@ config RPMSG_VIRTIO
select RPMSG
select VIRTIO
+config RPMSG_MTK_SCP
+ tristate "MediaTek SCP"
+ depends on MTK_SCP
+ select RPMSG
+
endmenu
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index 9aa859502d2752..a0c1dcefa36ee4 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_RPMSG_QCOM_GLINK_NATIVE) += qcom_glink_native.o
obj-$(CONFIG_RPMSG_QCOM_GLINK_SMEM) += qcom_glink_smem.o
obj-$(CONFIG_RPMSG_QCOM_SMD) += qcom_smd.o
obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
+obj-$(CONFIG_RPMSG_MTK_SCP)+= mtk_rpmsg.o
diff --git a/drivers/rpmsg/mtk_rpmsg.c b/drivers/rpmsg/mtk_rpmsg.c
new file mode 100644
index 00..d7330f5626d8b5
--- /dev/null
+++ b/drivers/rpmsg/mtk_rpmsg.c
@@ -0,0 +1,382 @@
+//
[RFC v2 3/6] remoteproc: move IPI interface into separate file.
Move the IPI interface into a separate file mtk_scp_ipi.c, so the things
that use the interface only can depend on the module only.
Signed-off-by: Pi-Hsun Shih
---
Changes from v1:
- Resolved conflict because of change in Patch 2.
---
drivers/remoteproc/Makefile | 2 +-
drivers/remoteproc/mtk_common.h | 73 +++
drivers/remoteproc/mtk_scp.c | 154 +--
drivers/remoteproc/mtk_scp_ipi.c | 108 ++
4 files changed, 183 insertions(+), 154 deletions(-)
create mode 100644 drivers/remoteproc/mtk_common.h
create mode 100644 drivers/remoteproc/mtk_scp_ipi.c
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 98e3498dbbe0e2..16b3e5e7a81c8e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -10,7 +10,7 @@ remoteproc-y += remoteproc_sysfs.o
remoteproc-y += remoteproc_virtio.o
remoteproc-y += remoteproc_elf_loader.o
obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
-obj-$(CONFIG_MTK_SCP) += mtk_scp.o
+obj-$(CONFIG_MTK_SCP) += mtk_scp.o mtk_scp_ipi.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
new file mode 100644
index 00..e97287a4eb25cc
--- /dev/null
+++ b/drivers/remoteproc/mtk_common.h
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018 MediaTek Inc.
+
+#ifndef __RPROC_MTK_COMMON_H
+#define __RPROC_MTK_COMMON_H
+
+#include
+#include
+#include
+#include
+
+#define MT8183_SW_RSTN 0x0
+#define MT8183_SW_RSTN_BIT BIT(0)
+#define MT8183_SCP_TO_HOST 0x1C
+#define MT8183_SCP_IPC_INT_BIT BIT(0)
+#define MT8183_SCP_WDT_INT_BIT BIT(8)
+#define MT8183_HOST_TO_SCP 0x28
+#define MT8183_HOST_IPC_INT_BITBIT(0)
+#define MT8183_SCP_SRAM_PDN0x402C
+
+#define SCP_FW_VER_LEN 32
+
+struct scp_run {
+ u32 signaled;
+ s8 fw_ver[SCP_FW_VER_LEN];
+ u32 dec_capability;
+ u32 enc_capability;
+ wait_queue_head_t wq;
+};
+
+struct scp_ipi_desc {
+ scp_ipi_handler_t handler;
+ const char *name;
+ void *priv;
+};
+
+struct mtk_scp {
+ struct device *dev;
+ struct rproc *rproc;
+ struct clk *clk;
+ void __iomem *reg_base;
+ void __iomem *sram_base;
+ size_t sram_size;
+
+ struct share_obj *recv_buf;
+ struct share_obj *send_buf;
+ struct scp_run run;
+ struct mutex scp_mutex; /* for protecting mtk_scp data structure */
+ struct scp_ipi_desc ipi_desc[SCP_IPI_MAX];
+ bool ipi_id_ack[SCP_IPI_MAX];
+ wait_queue_head_t ack_wq;
+
+ void __iomem *cpu_addr;
+ phys_addr_t phys_addr;
+ size_t dram_size;
+};
+
+/**
+ * struct share_obj - SRAM buffer shared with
+ * AP and SCP
+ *
+ * @id:IPI id
+ * @len: share buffer length
+ * @share_buf: share buffer data
+ */
+struct share_obj {
+ s32 id;
+ u32 len;
+ u8 share_buf[288];
+};
+
+#endif
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 6e2e17a227d018..3e84c696523436 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -13,163 +13,11 @@
#include
#include
+#include "mtk_common.h"
#include "remoteproc_internal.h"
-#define MT8183_SW_RSTN 0x0
-#define MT8183_SW_RSTN_BIT BIT(0)
-#define MT8183_SCP_TO_HOST 0x1C
-#define MT8183_SCP_IPC_INT_BIT BIT(0)
-#define MT8183_SCP_WDT_INT_BIT BIT(8)
-#define MT8183_HOST_TO_SCP 0x28
-#define MT8183_HOST_IPC_INT_BITBIT(0)
-#define MT8183_SCP_SRAM_PDN0x402C
-
-#define SCP_FW_VER_LEN 32
-
#define MAX_CODE_SIZE 0x50
-struct scp_run {
- u32 signaled;
- s8 fw_ver[SCP_FW_VER_LEN];
- u32 dec_capability;
- u32 enc_capability;
- wait_queue_head_t wq;
-};
-
-struct scp_ipi_desc {
- scp_ipi_handler_t handler;
- const char *name;
- void *priv;
-};
-
-struct mtk_scp {
- struct device *dev;
- struct rproc *rproc;
- struct clk *clk;
- void __iomem *reg_base;
- void __iomem *sram_base;
- size_t sram_size;
-
- struct share_obj *recv_buf;
- struct share_obj *send_buf;
- struct scp_run run;
- struct mutex scp_mutex; /* for protecting mtk_scp data structure */
- struct scp_ipi_desc ipi_desc[SCP_IPI_MAX];
- bool ipi_id_ack[SCP_IPI_MAX];
- wait_queue_head_t ack_wq;
-
- void __iomem *cpu_addr;
- phys_addr_t phys_addr;
- size_t dram_size;
-};
-
-/**
- * struct share_obj - SRAM buffer
[RFC v2 6/6] cros_ec: differentiate SCP from EC by feature bit.
Since a SCP and EC would both exist on a system, and use the cros_ec_dev
driver, we need to differentiate between them for the userspace, or they
would both be registered at /dev/cros_ec, causing a conflict.
Cc: Enric Balletbo Serra
Cc: Guenter Roeck
Signed-off-by: Pi-Hsun Shih
---
Changes from v1:
- New patch extracted from Patch 5.
---
drivers/mfd/cros_ec_dev.c| 9 +
include/linux/mfd/cros_ec.h | 1 +
include/linux/mfd/cros_ec_commands.h | 2 ++
3 files changed, 12 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 2d0fee488c5aa8..67983853413d07 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -414,6 +414,15 @@ static int ec_device_probe(struct platform_device *pdev)
device_initialize(>class_dev);
cdev_init(>cdev, );
+ if (cros_ec_check_features(ec, EC_FEATURE_SCP)) {
+ dev_info(dev, "SCP detected.\n");
+ /*
+* Help userspace differentiating ECs from SCP,
+* regardless of the probing order.
+*/
+ ec_platform->ec_name = CROS_EC_DEV_SCP_NAME;
+ }
+
/*
* Add the class device
* Link to the character device for creating the /dev entry
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index de8b588c8776da..fd297cf8f97295 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -24,6 +24,7 @@
#define CROS_EC_DEV_NAME "cros_ec"
#define CROS_EC_DEV_PD_NAME "cros_pd"
+#define CROS_EC_DEV_SCP_NAME "cros_scp"
/*
* The EC is unresponsive for a time after a reboot command. Add a
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index fc91082d4c357b..3e5da6e93b2f42 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -856,6 +856,8 @@ enum ec_feature_code {
EC_FEATURE_RTC = 27,
/* EC supports CEC commands */
EC_FEATURE_CEC = 35,
+ /* The MCU exposes a SCP */
+ EC_FEATURE_SCP = 39,
};
#define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
--
2.20.1.97.g81188d93c3-goog
[RFC v2 1/6] dt-bindings: Add a binding for Mediatek SCP
From: Erin Lo Add a DT binding documentation of SCP for the MT8183 SoC from Mediatek. Signed-off-by: Erin Lo --- Changes from v1: - no change --- .../devicetree/bindings/remoteproc/mtk,scp.txt | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt new file mode 100644 index 00..b07e5c4ca9af1d --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt @@ -0,0 +1,10 @@ +Mediatek SCP Bindings + + +This binding provides support for ARM Cortex M4 Co-processor found on some +Mediatek SoCs. + +Required properties: +- compatible Should be "mediatek,mt8183-scp" +- clocks Clock for co-processor (See: ../clock/clock-bindings.txt) + -- 2.20.1.97.g81188d93c3-goog
[PATCH v2] dt-bindings: input: ti-tsc-adc: Add new compatible for AM654 SoCs
AM654 SoCs has ADC IP which is similar to AM335x, but without the touchscreen part. Add new compatible to handle AM654 SoCs. Also, it seems that existing compatible strings used in the kernel DTs were never documented. So, document them now. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- v2: Fix subject line to include subsystem name Rebase onto v5.0-rc1 v1: https://lkml.org/lkml/2018/11/19/313 .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt index b1163bf97146..aad5e34965eb 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt @@ -2,7 +2,12 @@ ~~ Required properties: +- mfd + compatible: Should be + "ti,am3359-tscadc" for AM335x/AM437x SoCs + "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs - child "tsc" + compatible: Should be "ti,am3359-tsc". ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen support on the platform. ti,x-plate-resistance: X plate resistance @@ -25,6 +30,9 @@ Required properties: AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. XP = 0, XN = 1, YP = 2, YN = 3. - child "adc" + compatible: Should be + "ti,am3359-adc" for AM335x/AM437x SoCs + "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs ti,adc-channels: List of analog inputs available for ADC. AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. -- 2.20.1
[PATCH v4 3/3] virtio_balloon: remove the unnecessary 0-initialization
We've changed to kzalloc the vb struct, so no need to 0-initialize
this field one more time.
Signed-off-by: Wei Wang
Reviewed-by: Cornelia Huck
---
drivers/virtio/virtio_balloon.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index d48c12c..048959a 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -925,7 +925,6 @@ static int virtballoon_probe(struct virtio_device *vdev)
VIRTIO_BALLOON_CMD_ID_STOP);
vb->cmd_id_stop = cpu_to_virtio32(vb->vdev,
VIRTIO_BALLOON_CMD_ID_STOP);
- vb->num_free_page_blocks = 0;
spin_lock_init(>free_page_list_lock);
INIT_LIST_HEAD(>free_page_list);
if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
--
2.7.4
[PATCH v4 0/3] virtio-balloon: tweak config_changed
Since virtio-ccw doesn't work with accessing to the config space inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. v3->v4 ChangeLog: - change virtio32_to_cpu to cpu_to_virtio_32 in send_cmd_id_start; v2->v3 ChangeLog: - rename cmd_id_received to cmd_id_received_cache, and have call sites read the latest value via virtio_balloon_cmd_id_received. (Still kept Cornelia and Halil's reviewed-by as it's a minor change) - remove zeroing vb->num_free_page_blocks in probe since vb is allocated via kzalloc. v1->v2 ChangeLog: - add config_read_bitmap to indicate to the workqueue callbacks about the necessity of reading the related config fields. Wei Wang (3): virtio-balloon: tweak config_changed implementation virtio-balloon: improve update_balloon_size_func virtio_balloon: remove the unnecessary 0-initialization drivers/virtio/virtio_balloon.c | 104 ++-- 1 file changed, 69 insertions(+), 35 deletions(-) -- 2.7.4
Re: [PATCH V2] x86/kexec: fix a kexec_file_load failure
On 12/28/18 at 09:12am, Dave Young wrote:
> The code cleanup mentioned in Fixes tag changed the behavior of
> kexec_locate_mem_hole. The kexec_locate_mem_hole will try to
> allocate free memory only when kbuf.mem is initialized as zero.
>
> But in x86 kexec_file_load implementation there are a few places
> the kbuf.mem is reused like below:
> /* kbuf initialized, kbuf.mem = 0 */
> ...
> kexec_add_buffer()
> ...
> kexec_add_buffer()
>
> The second kexec_add_buffer will reuse previous kbuf but not
> reinitialize the kbuf.mem.
>
> Thus kexec_file_load failed because the sanity check failed.
>
> So explictily reset kbuf.mem to fix the issue.
>
> Fixes: b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
> Signed-off-by: Dave Young
> Cc:
> ---
> V1 -> V2: use KEXEC_BUF_MEM_UNKNOWN in code.
> arch/x86/kernel/crash.c | 1 +
> arch/x86/kernel/kexec-bzimage64.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index f631a3f15587..6b7890c7889b 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -469,6 +469,7 @@ int crash_load_segments(struct kimage *image)
>
Wondering why this place doesn't need the initialization assignment.
Isn't it to assign in all places before kexec_add_buffer() calling?
/* Add backup segment. */
if (image->arch.backup_src_sz) {
}
> kbuf.memsz = kbuf.bufsz;
> kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> + kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer();
> if (ret) {
> vfree((void *)image->arch.elf_headers);
> diff --git a/arch/x86/kernel/kexec-bzimage64.c
> b/arch/x86/kernel/kexec-bzimage64.c
> index 278cd07228dd..0d5efa34f359 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -434,6 +434,7 @@ static void *bzImage64_load(struct kimage *image, char
> *kernel,
> kbuf.memsz = PAGE_ALIGN(header->init_size);
> kbuf.buf_align = header->kernel_alignment;
> kbuf.buf_min = MIN_KERNEL_LOAD_ADDR;
Same question for bzImage64_load(), there are three kexec_add_buffer()
calling, I only saw two initialization in this patch.
> + kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer();
> if (ret)
> goto out_free_params;
> @@ -448,6 +449,7 @@ static void *bzImage64_load(struct kimage *image, char
> *kernel,
> kbuf.bufsz = kbuf.memsz = initrd_len;
> kbuf.buf_align = PAGE_SIZE;
> kbuf.buf_min = MIN_INITRD_LOAD_ADDR;
> + kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer();
> if (ret)
> goto out_free_params;
> --
> 2.17.0
>
[PATCH v4 2/3] virtio-balloon: improve update_balloon_size_func
There is no need to update the balloon actual register when there is no ballooning request. This patch avoids update_balloon_size when diff is 0. Signed-off-by: Wei Wang Reviewed-by: Cornelia Huck Reviewed-by: Halil Pasic Tested-by: Christian Borntraeger --- drivers/virtio/virtio_balloon.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 45d32f5..d48c12c 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -457,9 +457,12 @@ static void update_balloon_size_func(struct work_struct *work) update_balloon_size_work); diff = towards_target(vb); + if (!diff) + return; + if (diff > 0) diff -= fill_balloon(vb, diff); - else if (diff < 0) + else diff += leak_balloon(vb, -diff); update_balloon_size(vb); -- 2.7.4
[PATCH v4 1/3] virtio-balloon: tweak config_changed implementation
virtio-ccw has deadlock issues with reading the config space inside the
interrupt context, so we tweak the virtballoon_changed implementation
by moving the config read operations into the related workqueue contexts.
The config_read_bitmap is used as a flag to the workqueue callbacks
about the related config fields that need to be read.
The cmd_id_received is also renamed to cmd_id_received_cache, and
the value should be obtained via virtio_balloon_cmd_id_received.
Fixes: 86a559787e6f ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT")
Reported-by: Christian Borntraeger
Signed-off-by: Wei Wang
Reviewed-by: Cornelia Huck
Reviewed-by: Halil Pasic
Tested-by: Christian Borntraeger
---
drivers/virtio/virtio_balloon.c | 98 +++--
1 file changed, 65 insertions(+), 33 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 728ecd1..45d32f5 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -61,6 +61,10 @@ enum virtio_balloon_vq {
VIRTIO_BALLOON_VQ_MAX
};
+enum virtio_balloon_config_read {
+ VIRTIO_BALLOON_CONFIG_READ_CMD_ID = 0,
+};
+
struct virtio_balloon {
struct virtio_device *vdev;
struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
@@ -77,14 +81,20 @@ struct virtio_balloon {
/* Prevent updating balloon when it is being canceled. */
spinlock_t stop_update_lock;
bool stop_update;
+ /* Bitmap to indicate if reading the related config fields are needed */
+ unsigned long config_read_bitmap;
/* The list of allocated free pages, waiting to be given back to mm */
struct list_head free_page_list;
spinlock_t free_page_list_lock;
/* The number of free page blocks on the above list */
unsigned long num_free_page_blocks;
- /* The cmd id received from host */
- u32 cmd_id_received;
+ /*
+* The cmd id received from host.
+* Read it via virtio_balloon_cmd_id_received to get the latest value
+* sent from host.
+*/
+ u32 cmd_id_received_cache;
/* The cmd id that is actively in use */
__virtio32 cmd_id_active;
/* Buffer to store the stop sign */
@@ -390,37 +400,31 @@ static unsigned long return_free_pages_to_mm(struct
virtio_balloon *vb,
return num_returned;
}
+static void virtio_balloon_queue_free_page_work(struct virtio_balloon *vb)
+{
+ if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
+ return;
+
+ /* No need to queue the work if the bit was already set. */
+ if (test_and_set_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID,
+>config_read_bitmap))
+ return;
+
+ queue_work(vb->balloon_wq, >report_free_page_work);
+}
+
static void virtballoon_changed(struct virtio_device *vdev)
{
struct virtio_balloon *vb = vdev->priv;
unsigned long flags;
- s64 diff = towards_target(vb);
-
- if (diff) {
- spin_lock_irqsave(>stop_update_lock, flags);
- if (!vb->stop_update)
- queue_work(system_freezable_wq,
- >update_balloon_size_work);
- spin_unlock_irqrestore(>stop_update_lock, flags);
- }
- if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
- virtio_cread(vdev, struct virtio_balloon_config,
-free_page_report_cmd_id, >cmd_id_received);
- if (vb->cmd_id_received == VIRTIO_BALLOON_CMD_ID_DONE) {
- /* Pass ULONG_MAX to give back all the free pages */
- return_free_pages_to_mm(vb, ULONG_MAX);
- } else if (vb->cmd_id_received != VIRTIO_BALLOON_CMD_ID_STOP &&
- vb->cmd_id_received !=
- virtio32_to_cpu(vdev, vb->cmd_id_active)) {
- spin_lock_irqsave(>stop_update_lock, flags);
- if (!vb->stop_update) {
- queue_work(vb->balloon_wq,
- >report_free_page_work);
- }
- spin_unlock_irqrestore(>stop_update_lock, flags);
- }
+ spin_lock_irqsave(>stop_update_lock, flags);
+ if (!vb->stop_update) {
+ queue_work(system_freezable_wq,
+ >update_balloon_size_work);
+ virtio_balloon_queue_free_page_work(vb);
}
+ spin_unlock_irqrestore(>stop_update_lock, flags);
}
static void update_balloon_size(struct virtio_balloon *vb)
@@ -527,6 +531,17 @@ static int init_vqs(struct virtio_balloon *vb)
return 0;
}
+static u32 virtio_balloon_cmd_id_received(struct virtio_balloon *vb)
+{
+ if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID,
+
[PATCH 0/3] net: y2038-safe socket timeout options
The series is aimed at adding y2038-safe timeout options: SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW. This is similar to the previous series adding y2038-safe SO_TIMESTAMP* options. The series needs to be applied after the socket timestamp series: https://lore.kernel.org/lkml/20190108032657.8331-1-deepa.ker...@gmail.com Deepa Dinamani (3): socket: Use old_timeval types for socket timeouts socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW arch/alpha/include/uapi/asm/socket.h | 13 - arch/mips/include/uapi/asm/socket.h| 13 - arch/parisc/include/uapi/asm/socket.h | 13 - arch/powerpc/include/uapi/asm/socket.h | 4 +- arch/sparc/include/uapi/asm/socket.h | 13 - fs/dlm/lowcomms.c | 4 +- include/uapi/asm-generic/socket.h | 13 - net/compat.c | 14 ++--- net/core/sock.c| 78 +++--- net/vmw_vsock/af_vsock.c | 4 +- 10 files changed, 126 insertions(+), 43 deletions(-) base-commit: a4983672f9ca4c8393f26b6b80710e6c78886b8c prerequisite-patch-id: a03ec6afbdd328cd90557f7ee6675016a5f5c653 prerequisite-patch-id: 724d26c3036e6f3a38f810c2f10db3f7ddbf843b prerequisite-patch-id: 14017867b6eb4d5231eec1b563edcd840a1be26e prerequisite-patch-id: 8df0edfd9b973ff5aae91c7709c8223be096a5bc prerequisite-patch-id: 9850ad48d41bf068f074c0dd3c7610fb7177c89f prerequisite-patch-id: bd31f35bba11902d1cc3e8726492b54df34b5c59 prerequisite-patch-id: ea4b005c5ad188a4e0899d728357c114710a3a8e prerequisite-patch-id: cc3ee912c1ee1ea502ca079de81236a467950501 -- 2.17.1 Cc: ccaul...@redhat.com Cc: cluster-de...@redhat.com Cc: da...@davemloft.net Cc: del...@gmx.de Cc: linux-al...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-m...@vger.kernel.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: pau...@samba.org Cc: r...@linux-mips.org Cc: r...@twiddle.net Cc: sparcli...@vger.kernel.org
[PATCH 3/3] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW
Add new socket timeout options that are y2038 safe. Signed-off-by: Deepa Dinamani Cc: ccaul...@redhat.com Cc: da...@davemloft.net Cc: del...@gmx.de Cc: pau...@samba.org Cc: r...@linux-mips.org Cc: r...@twiddle.net Cc: cluster-de...@redhat.com Cc: linuxppc-...@lists.ozlabs.org Cc: linux-al...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-m...@vger.kernel.org Cc: linux-par...@vger.kernel.org Cc: sparcli...@vger.kernel.org --- arch/alpha/include/uapi/asm/socket.h | 12 +++-- arch/mips/include/uapi/asm/socket.h | 11 - arch/parisc/include/uapi/asm/socket.h | 11 - arch/sparc/include/uapi/asm/socket.h | 11 - include/net/sock.h| 4 +- include/uapi/asm-generic/socket.h | 11 - net/core/sock.c | 64 +-- 7 files changed, 98 insertions(+), 26 deletions(-) diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h index ea3ba981d8a0..3d800d5d3d5d 100644 --- a/arch/alpha/include/uapi/asm/socket.h +++ b/arch/alpha/include/uapi/asm/socket.h @@ -118,19 +118,25 @@ #define SO_TIMESTAMPNS_NEW 63 #define SO_TIMESTAMPING_NEW 64 -#if !defined(__KERNEL__) +#define SO_RCVTIMEO_NEW 65 +#define SO_SNDTIMEO_NEW 66 -#defineSO_RCVTIMEO SO_RCVTIMEO_OLD -#defineSO_SNDTIMEO SO_SNDTIMEO_OLD +#if !defined(__KERNEL__) #if __BITS_PER_LONG == 64 #define SO_TIMESTAMP SO_TIMESTAMP_OLD #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD #define SO_TIMESTAMPINGSO_TIMESTAMPING_OLD + +#defineSO_RCVTIMEO SO_RCVTIMEO_OLD +#defineSO_SNDTIMEO SO_SNDTIMEO_OLD #else #define SO_TIMESTAMP (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMP_OLD : SO_TIMESTAMP_NEW) #define SO_TIMESTAMPNS (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMPNS_OLD : SO_TIMESTAMPNS_NEW) #define SO_TIMESTAMPING (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMPING_OLD : SO_TIMESTAMPING_NEW) + +#define SO_RCVTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_RCVTIMEO_OLD : SO_RCVTIMEO_NEW) +#define SO_SNDTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_SNDTIMEO_OLD : SO_SNDTIMEO_NEW) #endif #define SCM_TIMESTAMP SO_TIMESTAMP diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h index 4dde20d64690..5a7f9010c090 100644 --- a/arch/mips/include/uapi/asm/socket.h +++ b/arch/mips/include/uapi/asm/socket.h @@ -128,18 +128,25 @@ #define SO_TIMESTAMPNS_NEW 63 #define SO_TIMESTAMPING_NEW 64 +#define SO_RCVTIMEO_NEW 65 +#define SO_SNDTIMEO_NEW 66 + #if !defined(__KERNEL__) -#defineSO_RCVTIMEO SO_RCVTIMEO_OLD -#defineSO_SNDTIMEO SO_SNDTIMEO_OLD #if __BITS_PER_LONG == 64 #define SO_TIMESTAMP SO_TIMESTAMP_OLD #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD #define SO_TIMESTAMPINGSO_TIMESTAMPING_OLD + +#defineSO_RCVTIMEO SO_RCVTIMEO_OLD +#defineSO_SNDTIMEO SO_SNDTIMEO_OLD #else #define SO_TIMESTAMP (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMP_OLD : SO_TIMESTAMP_NEW) #define SO_TIMESTAMPNS (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMPNS_OLD : SO_TIMESTAMPNS_NEW) #define SO_TIMESTAMPING (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMPING_OLD : SO_TIMESTAMPING_NEW) + +#defineSO_RCVTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_RCVTIMEO_OLD : SO_RCVTIMEO_NEW) +#defineSO_SNDTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_SNDTIMEO_OLD : SO_SNDTIMEO_NEW) #endif #define SCM_TIMESTAMP SO_TIMESTAMP diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h index 546937fa0d8b..bd35de5b4666 100644 --- a/arch/parisc/include/uapi/asm/socket.h +++ b/arch/parisc/include/uapi/asm/socket.h @@ -109,18 +109,25 @@ #define SO_TIMESTAMPNS_NEW 0x4038 #define SO_TIMESTAMPING_NEW 0x4039 +#define SO_RCVTIMEO_NEW 0x4040 +#define SO_SNDTIMEO_NEW 0x4041 + #if !defined(__KERNEL__) -#defineSO_RCVTIMEO SO_RCVTIMEO_OLD -#defineSO_SNDTIMEO SO_SNDTIMEO_OLD #if __BITS_PER_LONG == 64 #define SO_TIMESTAMP SO_TIMESTAMP_OLD #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD #define SO_TIMESTAMPINGSO_TIMESTAMPING_OLD + +#defineSO_RCVTIMEO SO_RCVTIMEO_OLD +#defineSO_SNDTIMEO SO_SNDTIMEO_OLD #else #define SO_TIMESTAMP (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMP_OLD : SO_TIMESTAMP_NEW) #define SO_TIMESTAMPNS (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMPNS_OLD : SO_TIMESTAMPNS_NEW) #define SO_TIMESTAMPING (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_TIMESTAMPING_OLD : SO_TIMESTAMPING_NEW) + +#defineSO_RCVTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_RCVTIMEO_OLD : SO_RCVTIMEO_NEW) +#defineSO_SNDTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ?
[PATCH 1/3] socket: Use old_timeval types for socket timeouts
As part of y2038 solution, all internal uses of
struct timeval are replaced by struct __kernel_old_timeval
and struct compat_timeval by struct old_timeval32.
Make socket timeouts use these new types.
This is mainly to be able to verify that the kernel build
is y2038 safe when such non y2038 safe types are not
supported anymore.
Signed-off-by: Deepa Dinamani
---
net/compat.c | 10 +-
net/core/sock.c | 8
net/vmw_vsock/af_vsock.c | 4 ++--
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/net/compat.c b/net/compat.c
index b6ff0899e424..cbc15f65033c 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -351,8 +351,8 @@ static int do_set_attach_filter(struct socket *sock, int
level, int optname,
static int do_set_sock_timeout(struct socket *sock, int level,
int optname, char __user *optval, unsigned int optlen)
{
- struct compat_timeval __user *up = (struct compat_timeval __user
*)optval;
- struct timeval ktime;
+ struct old_timeval32 __user *up = (struct old_timeval32 __user *)optval;
+ struct __kernel_old_timeval ktime;
mm_segment_t old_fs;
int err;
@@ -420,12 +420,12 @@ COMPAT_SYSCALL_DEFINE5(setsockopt, int, fd, int, level,
int, optname,
static int do_get_sock_timeout(struct socket *sock, int level, int optname,
char __user *optval, int __user *optlen)
{
- struct compat_timeval __user *up;
- struct timeval ktime;
+ struct old_timeval32 __user *up;
+ struct __kernel_old_timeval ktime;
mm_segment_t old_fs;
int len, err;
- up = (struct compat_timeval __user *)optval;
+ up = (struct old_timeval32 __user *)optval;
if (get_user(len, optlen))
return -EFAULT;
if (len < sizeof(*up))
diff --git a/net/core/sock.c b/net/core/sock.c
index 78df5228ffbd..af0fb33624e2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -337,7 +337,7 @@ EXPORT_SYMBOL(__sk_backlog_rcv);
static int sock_set_timeout(long *timeo_p, char __user *optval, int optlen)
{
- struct timeval tv;
+ struct __kernel_old_timeval tv;
if (optlen < sizeof(tv))
return -EINVAL;
@@ -1113,7 +1113,7 @@ int sock_getsockopt(struct socket *sock, int level, int
optname,
int val;
u64 val64;
struct linger ling;
- struct timeval tm;
+ struct __kernel_old_timeval tm;
struct sock_txtime txtime;
} v;
@@ -1223,7 +1223,7 @@ int sock_getsockopt(struct socket *sock, int level, int
optname,
break;
case SO_RCVTIMEO:
- lv = sizeof(struct timeval);
+ lv = sizeof(struct __kernel_old_timeval);
if (sk->sk_rcvtimeo == MAX_SCHEDULE_TIMEOUT) {
v.tm.tv_sec = 0;
v.tm.tv_usec = 0;
@@ -1234,7 +1234,7 @@ int sock_getsockopt(struct socket *sock, int level, int
optname,
break;
case SO_SNDTIMEO:
- lv = sizeof(struct timeval);
+ lv = sizeof(struct __kernel_old_timeval);
if (sk->sk_sndtimeo == MAX_SCHEDULE_TIMEOUT) {
v.tm.tv_sec = 0;
v.tm.tv_usec = 0;
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 43a1dec08825..e1149bf1b57b 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1439,7 +1439,7 @@ static int vsock_stream_setsockopt(struct socket *sock,
break;
case SO_VM_SOCKETS_CONNECT_TIMEOUT: {
- struct timeval tv;
+ struct __kernel_old_timeval tv;
COPY_IN(tv);
if (tv.tv_sec >= 0 && tv.tv_usec < USEC_PER_SEC &&
tv.tv_sec < (MAX_SCHEDULE_TIMEOUT / HZ - 1)) {
@@ -1517,7 +1517,7 @@ static int vsock_stream_getsockopt(struct socket *sock,
break;
case SO_VM_SOCKETS_CONNECT_TIMEOUT: {
- struct timeval tv;
+ struct __kernel_old_timeval tv;
tv.tv_sec = vsk->connect_timeout / HZ;
tv.tv_usec =
(vsk->connect_timeout -
--
2.17.1
[PATCH 2/3] socket: Rename SO_RCVTIMEO/ SO_SNDTIMEO with _OLD suffixes
SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval as the time format. struct timeval is not y2038 safe. The subsequent patches in the series add support for new socket timeout options with _NEW suffix that are y2038 safe. Rename the existing options with _OLD suffix forms so that the right option is enabled for userspace applications according to the architecture and time_t definition of libc. Signed-off-by: Deepa Dinamani Cc: ccaul...@redhat.com Cc: del...@gmx.de Cc: pau...@samba.org Cc: r...@linux-mips.org Cc: r...@twiddle.net Cc: cluster-de...@redhat.com Cc: linuxppc-...@lists.ozlabs.org Cc: linux-al...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-m...@vger.kernel.org Cc: linux-par...@vger.kernel.org Cc: sparcli...@vger.kernel.org --- arch/alpha/include/uapi/asm/socket.h | 7 +-- arch/mips/include/uapi/asm/socket.h| 6 -- arch/parisc/include/uapi/asm/socket.h | 6 -- arch/powerpc/include/uapi/asm/socket.h | 4 ++-- arch/sparc/include/uapi/asm/socket.h | 6 -- fs/dlm/lowcomms.c | 4 ++-- include/net/sock.h | 4 ++-- include/uapi/asm-generic/socket.h | 6 -- net/compat.c | 4 ++-- net/core/sock.c| 8 10 files changed, 33 insertions(+), 22 deletions(-) diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h index da08412bd49f..ea3ba981d8a0 100644 --- a/arch/alpha/include/uapi/asm/socket.h +++ b/arch/alpha/include/uapi/asm/socket.h @@ -31,8 +31,8 @@ #define SO_RCVBUFFORCE 0x100b #defineSO_RCVLOWAT 0x1010 #defineSO_SNDLOWAT 0x1011 -#defineSO_RCVTIMEO 0x1012 -#defineSO_SNDTIMEO 0x1013 +#defineSO_RCVTIMEO_OLD 0x1012 +#defineSO_SNDTIMEO_OLD 0x1013 #define SO_ACCEPTCONN 0x1014 #define SO_PROTOCOL0x1028 #define SO_DOMAIN 0x1029 @@ -120,6 +120,9 @@ #if !defined(__KERNEL__) +#defineSO_RCVTIMEO SO_RCVTIMEO_OLD +#defineSO_SNDTIMEO SO_SNDTIMEO_OLD + #if __BITS_PER_LONG == 64 #define SO_TIMESTAMP SO_TIMESTAMP_OLD #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h index 1e48f67f1052..4dde20d64690 100644 --- a/arch/mips/include/uapi/asm/socket.h +++ b/arch/mips/include/uapi/asm/socket.h @@ -39,8 +39,8 @@ #define SO_RCVBUF 0x1002 /* Receive buffer. */ #define SO_SNDLOWAT0x1003 /* send low-water mark */ #define SO_RCVLOWAT0x1004 /* receive low-water mark */ -#define SO_SNDTIMEO0x1005 /* send timeout */ -#define SO_RCVTIMEO0x1006 /* receive timeout */ +#define SO_SNDTIMEO_OLD0x1005 /* send timeout */ +#define SO_RCVTIMEO_OLD0x1006 /* receive timeout */ #define SO_ACCEPTCONN 0x1009 #define SO_PROTOCOL0x1028 /* protocol type */ #define SO_DOMAIN 0x1029 /* domain/socket family */ @@ -130,6 +130,8 @@ #if !defined(__KERNEL__) +#defineSO_RCVTIMEO SO_RCVTIMEO_OLD +#defineSO_SNDTIMEO SO_SNDTIMEO_OLD #if __BITS_PER_LONG == 64 #define SO_TIMESTAMP SO_TIMESTAMP_OLD #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h index e8d6cf20f9a4..546937fa0d8b 100644 --- a/arch/parisc/include/uapi/asm/socket.h +++ b/arch/parisc/include/uapi/asm/socket.h @@ -22,8 +22,8 @@ #define SO_RCVBUFFORCE 0x100b #define SO_SNDLOWAT0x1003 #define SO_RCVLOWAT0x1004 -#define SO_SNDTIMEO0x1005 -#define SO_RCVTIMEO0x1006 +#define SO_SNDTIMEO_OLD0x1005 +#define SO_RCVTIMEO_OLD0x1006 #define SO_ERROR 0x1007 #define SO_TYPE0x1008 #define SO_PROTOCOL0x1028 @@ -111,6 +111,8 @@ #if !defined(__KERNEL__) +#defineSO_RCVTIMEO SO_RCVTIMEO_OLD +#defineSO_SNDTIMEO SO_SNDTIMEO_OLD #if __BITS_PER_LONG == 64 #define SO_TIMESTAMP SO_TIMESTAMP_OLD #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h index 94de465e0920..12aa0c43e775 100644 --- a/arch/powerpc/include/uapi/asm/socket.h +++ b/arch/powerpc/include/uapi/asm/socket.h @@ -11,8 +11,8 @@ #define SO_RCVLOWAT16 #define SO_SNDLOWAT17 -#define SO_RCVTIMEO18 -#define SO_SNDTIMEO19 +#define SO_RCVTIMEO_OLD18 +#define SO_SNDTIMEO_OLD19 #define SO_PASSCRED20 #define SO_PEERCRED21 diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h index fc65bf6b6440..bdc396211627 100644 --- a/arch/sparc/include/uapi/asm/socket.h +++ b/arch/sparc/include/uapi/asm/socket.h @@ -21,8 +21,8 @@ #define SO_BSDCOMPAT0x0400 #define SO_RCVLOWAT 0x0800 #define SO_SNDLOWAT 0x1000 -#define SO_RCVTIMEO 0x2000 -#define SO_SNDTIMEO 0x4000 +#define SO_RCVTIMEO_OLD 0x2000 +#define SO_SNDTIMEO_OLD
Re: [PATCH] nfit: Hide unused functions behind CONFIG_X86
On Mon, Jan 07, 2019 at 09:14:05PM -0800, Dan Williams wrote: > On Mon, Jan 7, 2019 at 8:59 PM Nathan Chancellor > wrote: > > > > On arm64 little endian allyesconfig: > > > > drivers/acpi/nfit/intel.c:149:12: warning: unused function > > 'intel_security_unlock' [-Wunused-function] > > static int intel_security_unlock(struct nvdimm *nvdimm, > >^ > > drivers/acpi/nfit/intel.c:230:12: warning: unused function > > 'intel_security_erase' [-Wunused-function] > > static int intel_security_erase(struct nvdimm *nvdimm, > >^ > > drivers/acpi/nfit/intel.c:279:12: warning: unused function > > 'intel_security_query_overwrite' [-Wunused-function] > > static int intel_security_query_overwrite(struct nvdimm *nvdimm) > >^ > > drivers/acpi/nfit/intel.c:316:12: warning: unused function > > 'intel_security_overwrite' [-Wunused-function] > > static int intel_security_overwrite(struct nvdimm *nvdimm, > >^ > > 4 warnings generated. > > > > These functions are only used in __intel_security_ops when CONFIG_X86 is > > set so only define these functions under that same condition. > > Thanks for the report, not sure how the kbuild robot missed this. I'd > prefer marking the functions __maybe_unused rather than expanding the > ifdef guards. allyesconfig defaults to big endian, which doesn't built the nfit folder (haven't looked into the dependency chain to see why). I have been working with Clang and have a local patch to avoid turning on big endian mode with it for now (avoids a few other warnings for now). I can send a v2 with that change if you would like. Thanks for the quick reply, Nathan
Re: [PATCH v4 1/6] arm64/kvm: preserve host HCR_EL2 value
Hi,
On Sat, Jan 5, 2019 at 12:05 AM James Morse wrote:
>
> Hi Amit,
>
> On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
> > When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
> > is a constant value. This works today, as the host HCR_EL2 value is
> > always the same, but this will get in the way of supporting extensions
> > that require HCR_EL2 bits to be set conditionally for the host.
> >
> > To allow such features to work without KVM having to explicitly handle
> > every possible host feature combination, this patch has KVM save/restore
> > the host HCR when switching to/from a guest HCR. The saving of the
> > register is done once during cpu hypervisor initialization state and is
> > just restored after switch from guest.
> >
> > For fetching HCR_EL2 during kvm initilisation, a hyp call is made using
>
> (initialisation)
>
>
> > kvm_call_hyp and is helpful in NHVE case.
> >
> > For the hyp TLB maintenance code, __tlb_switch_to_host_vhe() is updated
> > to toggle the TGE bit with a RMW sequence, as we already do in
> > __tlb_switch_to_guest_vhe().
>
>
> > diff --git a/arch/arm64/include/asm/kvm_asm.h
> > b/arch/arm64/include/asm/kvm_asm.h
> > index aea01a0..25ac9fa 100644
> > --- a/arch/arm64/include/asm/kvm_asm.h
> > +++ b/arch/arm64/include/asm/kvm_asm.h
> > @@ -73,6 +73,8 @@ extern void __vgic_v3_init_lrs(void);
> >
> > extern u32 __kvm_get_mdcr_el2(void);
> >
> > +extern u64 __read_hyp_hcr_el2(void);
>
> How come this isn't __kvm_get_hcr_el2() like mdcr?
yes.
>
>
> > diff --git a/arch/arm64/include/asm/kvm_host.h
> > b/arch/arm64/include/asm/kvm_host.h
> > index 52fbc82..1b9eed9 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -196,13 +196,17 @@ enum vcpu_sysreg {
> >
> > #define NR_COPRO_REGS(NR_SYS_REGS * 2)
> >
> > +struct kvm_cpu_init_host_regs {
> > + u64 hcr_el2;
> > +};
> > +
> > struct kvm_cpu_context {
> > struct kvm_regs gp_regs;
> > union {
> > u64 sys_regs[NR_SYS_REGS];
> > u32 copro[NR_COPRO_REGS];
> > };
> > -
> > + struct kvm_cpu_init_host_regs init_regs;
> > struct kvm_vcpu *__hyp_running_vcpu;
> > };
>
> Hmm, so we grow every vcpu's struct kvm_cpu_context with some host-only
> registers...
>
>
> > @@ -211,7 +215,7 @@ typedef struct kvm_cpu_context kvm_cpu_context_t;
> > struct kvm_vcpu_arch {
> > struct kvm_cpu_context ctxt;
> >
> > - /* HYP configuration */
> > + /* Guest HYP configuration */
> > u64 hcr_el2;
> > u32 mdcr_el2;
>
> ... but they aren't actually host-only.
>
>
> I think it would be tidier to move these two into struct kvm_cpu_context (not
> as
> some init_host state), as both host and vcpu's have these values.
> You could then add the mdcr_el2 stashing to your __cpu_copy_host_registers()
> too. This way they both work in the same way, otherwise one is per-cpu, the
> other is in a special bit of only the host's kvm_cpu_context.
>
Your suggestion looks doable. I will implement in next iteration.
>
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> > index f6e02cc..85a2a5c 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -139,15 +139,15 @@ static void __hyp_text __activate_traps(struct
> > kvm_vcpu *vcpu)
> > __activate_traps_nvhe(vcpu);
> > }
> >
> > -static void deactivate_traps_vhe(void)
> > +static void deactivate_traps_vhe(struct kvm_cpu_context *host_ctxt)
> > {
> > extern char vectors[]; /* kernel exception vectors */
> > - write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
> > + write_sysreg(host_ctxt->init_regs.hcr_el2, hcr_el2);
> > write_sysreg(CPACR_EL1_DEFAULT, cpacr_el1);
> > write_sysreg(vectors, vbar_el1);
> > }
> >
> > -static void __hyp_text __deactivate_traps_nvhe(void)
> > +static void __hyp_text __deactivate_traps_nvhe(struct kvm_cpu_context
> > *host_ctxt)
> > {
> > u64 mdcr_el2 = read_sysreg(mdcr_el2);
> >
> > @@ -157,12 +157,15 @@ static void __hyp_text __deactivate_traps_nvhe(void)
> > mdcr_el2 |= MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT;
> >
> > write_sysreg(mdcr_el2, mdcr_el2);
>
> Strangely we try to rebuild the host's mdcr value here. If we had the host
> mdcr
> value in host_ctxt we could restore it directly.
yes. I will check if initial value host value is same as calculated.
>
>
> > - write_sysreg(HCR_HOST_NVHE_FLAGS, hcr_el2);
> > + write_sysreg(host_ctxt->init_regs.hcr_el2, hcr_el2);
> > write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
> > }
>
> > static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
> > {
> > + struct kvm_cpu_context *host_ctxt;
> > +
> > + host_ctxt = vcpu->arch.host_cpu_context;
> > /*
> >* If we pended a virtual abort, preserve it until it gets
> >* cleared. See D1.14.3 (Virtual Interrupts) for details, but
> > @@ -173,9 +176,9 @@ static void __hyp_text
Re: [PATCH] xfs: correct statx's result_mask value
On 1/8/2019 1:07 PM, Darrick J. Wong wrote: On Tue, Jan 08, 2019 at 12:58:43PM +0800, Su Yanjun wrote: On 1/8/2019 2:04 AM, Eric Sandeen wrote: On 1/7/19 11:52 AM, Darrick J. Wong wrote: On Mon, Jan 07, 2019 at 04:53:10AM -0500, Su Yanjun wrote: For statx syscall, xfs return the wrong result_mask. Signed-off-by: Su Yanjun --- fs/xfs/xfs_iops.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index f48ffd7..3811457 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -521,6 +521,9 @@ xfs_vn_getattr( stat->btime.tv_nsec = ip->i_d.di_crtime.t_nsec; } } + + /* Only return mask that we care */ + stat->result_mask &= request_mask; Why not just: stat->result_mask = STATX_BASIC_STATS; at the top of the function? I don't see the need to mask off result_mask at all, since we could some day elect to return more than what's in request_mask... When we run xfstests with nfs, the generic/423 case runs failed. So i review the nfs' nfs_getattr code it does validate the request_mask. Then i review the xfs' getattr code, it has no such check. Whatever request_mask is set, the stat's result_mask always the 0x7ff. Yes, statx can return more data than what userspace callers ask for: Maybe it has Unclear semantics about statx's result_mask. "A filesystem may also fill in fields that the caller didn't ask for if it has values for them available and the information is available at no extra cost. If this happens, the corresponding bits will be set in stx_mask." --D I get it, then the testcase generic/423 may need update in xfstests. Thanks for your reply. ...waitaminute, are you seeing garbage in the result_mask that's returned to userspace? I also noticed the vfs stat functions declare "struct kstat stat;" without explicitly zeroing the structure fields, which means (I think) that we can leak stack information if the kernel isn't built with the stackleak plugin? No such problem. A clear problem statement and reproducer steps would be hugely useful here. -Eric Thanks, Su
Re: [PATCH] nfit: Hide unused functions behind CONFIG_X86
On Mon, Jan 7, 2019 at 8:59 PM Nathan Chancellor wrote: > > On arm64 little endian allyesconfig: > > drivers/acpi/nfit/intel.c:149:12: warning: unused function > 'intel_security_unlock' [-Wunused-function] > static int intel_security_unlock(struct nvdimm *nvdimm, >^ > drivers/acpi/nfit/intel.c:230:12: warning: unused function > 'intel_security_erase' [-Wunused-function] > static int intel_security_erase(struct nvdimm *nvdimm, >^ > drivers/acpi/nfit/intel.c:279:12: warning: unused function > 'intel_security_query_overwrite' [-Wunused-function] > static int intel_security_query_overwrite(struct nvdimm *nvdimm) >^ > drivers/acpi/nfit/intel.c:316:12: warning: unused function > 'intel_security_overwrite' [-Wunused-function] > static int intel_security_overwrite(struct nvdimm *nvdimm, >^ > 4 warnings generated. > > These functions are only used in __intel_security_ops when CONFIG_X86 is > set so only define these functions under that same condition. Thanks for the report, not sure how the kbuild robot missed this. I'd prefer marking the functions __maybe_unused rather than expanding the ifdef guards.
Re: [PATCH] xfs: correct statx's result_mask value
On Tue, Jan 08, 2019 at 12:58:43PM +0800, Su Yanjun wrote: > > > On 1/8/2019 2:04 AM, Eric Sandeen wrote: > > On 1/7/19 11:52 AM, Darrick J. Wong wrote: > > > On Mon, Jan 07, 2019 at 04:53:10AM -0500, Su Yanjun wrote: > > > > For statx syscall, xfs return the wrong result_mask. > > > > > > > > Signed-off-by: Su Yanjun > > > > --- > > > > fs/xfs/xfs_iops.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c > > > > index f48ffd7..3811457 100644 > > > > --- a/fs/xfs/xfs_iops.c > > > > +++ b/fs/xfs/xfs_iops.c > > > > @@ -521,6 +521,9 @@ xfs_vn_getattr( > > > > stat->btime.tv_nsec = ip->i_d.di_crtime.t_nsec; > > > > } > > > > } > > > > + > > > > + /* Only return mask that we care */ > > > > + stat->result_mask &= request_mask; > > > Why not just: > > > > > > stat->result_mask = STATX_BASIC_STATS; > > > > > > at the top of the function? > > > > > > I don't see the need to mask off result_mask at all, since we could some > > > day elect to return more than what's in request_mask... > When we run xfstests with nfs, the generic/423 case runs failed. So i review > the nfs' > nfs_getattr code it does validate the request_mask. > > Then i review the xfs' getattr code, it has no such check. Whatever > request_mask > is set, the stat's result_mask always the 0x7ff. Yes, statx can return more data than what userspace callers ask for: > Maybe it has Unclear semantics about statx's result_mask. "A filesystem may also fill in fields that the caller didn't ask for if it has values for them available and the information is available at no extra cost. If this happens, the corresponding bits will be set in stx_mask." --D > > > ...waitaminute, are you seeing garbage in the result_mask that's > > > returned to userspace? I also noticed the vfs stat functions declare > > > "struct kstat stat;" without explicitly zeroing the structure fields, > > > which means (I think) that we can leak stack information if the kernel > > > isn't built with the stackleak plugin? > No such problem. > > A clear problem statement and reproducer steps would be hugely useful > > here. > > > > -Eric > Thanks, > Su > >
[PATCH] isdn: avm: Fix string plus integer warning from Clang
A recent commit in Clang expanded the -Wstring-plus-int warning, showing some odd behavior in this file. drivers/isdn/hardware/avm/b1.c:426:30: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] cinfo->version[j] = "\0\0" + 1; ~~~^~~ drivers/isdn/hardware/avm/b1.c:426:30: note: use array indexing to silence this warning cinfo->version[j] = "\0\0" + 1; ^ & [ ] 1 warning generated. This is equivalent to just "\0" so fix it to clean up the warning. Link: https://github.com/ClangBuiltLinux/linux/issues/309 Signed-off-by: Nathan Chancellor --- drivers/isdn/hardware/avm/b1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/isdn/hardware/avm/b1.c b/drivers/isdn/hardware/avm/b1.c index 4ac378e48902..7fa8141e2019 100644 --- a/drivers/isdn/hardware/avm/b1.c +++ b/drivers/isdn/hardware/avm/b1.c @@ -423,7 +423,7 @@ void b1_parse_version(avmctrl_info *cinfo) int i, j; for (j = 0; j < AVM_MAXVERSION; j++) - cinfo->version[j] = "\0\0" + 1; + cinfo->version[j] = "\0"; for (i = 0, j = 0; j < AVM_MAXVERSION && i < cinfo->versionlen; j++, i += cinfo->versionbuf[i] + 1) -- 2.20.1
Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler
On Mon, Jan 07, 2019 at 04:52:00PM +0100, Stephan Mueller wrote: > > Would it make sense to polish these mentioned KDF patches and add them to the > kernel crypto API? The sprawl of key derivation logic here and there which > seemingly does not comply to any standard and thus possibly have issues > should > be prevented and cleaned up. Are we going to have multiple implementations for the same KDF? If not then the crypto API is not a good fit. To consolidate multiple implementations of the same KDF, simply provide helpers for them. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3] crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK
On Fri, Dec 21, 2018 at 08:07:52AM +, Christophe Leroy wrote: > [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837 > dma_nommu_map_page+0x44/0xd4 > [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW > 4.20.0-rc5-00560-g6bfb52e23a00-dirty #531 > [2.384740] NIP: c000c540 LR: c000c584 CTR: > [2.389743] REGS: c95abab0 TRAP: 0700 Tainted: GW > (4.20.0-rc5-00560-g6bfb52e23a00-dirty) > [2.400042] MSR: 00029032 CR: 24042204 XER: > [2.406669] > [2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001 > 0001 0001 > [2.406669] GPR08: 2000 0010 0010 24042202 > 0100 c95abd88 > [2.406669] GPR16: c05569d4 0001 0010 c95abc88 c0615664 > 0004 > [2.406669] GPR24: 0010 c95abc88 c95abc88 c61ae210 c7ff6d40 > c61ae210 3d68 > [2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4 > [2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4 > [2.451762] Call Trace: > [2.454195] [c95abb60] [82000808] 0x82000808 (unreliable) > [2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8 > [2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c > [2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64 > [2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08 > [2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc > [2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc > [2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8 > [2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50 > [2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110 > [2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c > [2.515532] Instruction dump: > [2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076 > 7c84e850 > [2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e > 54847022 7c84fa14 > [2.533960] ---[ end trace bf78d94af73fe3b8 ]--- > [2.539123] talitos ff02.crypto: master data transfer error > [2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040 > [2.551625] alg: skcipher: encryption failed on test 1 for > ecb-aes-talitos: ret=22 > > IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack > cannot be DMA mapped anymore. > > This patch copies the IV into the extended descriptor when iv is not > a valid linear address. Please make the copy unconditional. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH net-next 2/5] net: 8021q: vlan_dev: add vid tag for uc and mc address lists
Le 12/4/18 à 4:04 PM, Ivan Khoronzhuk a écrit : > On Tue, Dec 04, 2018 at 11:49:27AM -0800, Florian Fainelli wrote: > > ... > >>> >>> I was thinking also about pinned list of vlans to the address, but in >>> this case this information also has to be synced by members of device >>> chain, >>> because it can be modified on any device level and it looks not very >>> friendly, >>> and at the end address space has addresses with pinned lists of vlans >>> with >>> their pointers. But keeping this stuff in sync is not simplest decision. >>> >>> >> >> I really think we are not communicating properly, it really seems to me >> that if you had the information about the upper device trying to add an >> address to the lower device filter's either through notification or call >> to ndo_set_rxmode, you could be solving your problems. What are we >> missing here? > > Sry, missed this one. The problem in getting the owner of address. > Just simple case: vlan/macvlan/real_dev or vlan/.../.../real_dev > > The real dev hasn't simple way to get vid the address belong to, or it has? Humm looks like your right, by the time the address lists are synchronized (e.g: from = vlan_dev, to = real_dev), we lost that information. It looks like I just managed to find such an use case myself with VLAN filtering enabled on a bridge (so switch is VLAN aware) and a VLAN device created on the bridge (br0.42) but with IGMP snooping turned off (so we don't get HOST_MDB notifications with correct VLAN ID). Maybe keeping the "from" net_device within the address list that is processed by ndo_set_rx_mode() will do the job though? Then you can do things like: if (is_vlan_dev(ha->dev) && ha->dev != dev) vid = vlan_dev_vlan_id(ha->dev); and it should scale to any type of stacked device, regardless of VID or something else that we need? Can you remind me of your use case again? Is it because your switch has VLAN filtering enabled and you need to make sure that MC addresses on VLAN device get programmed into the switch's multicast database with correct VID? -- Florian
Re: [PATCH] cpufreq: e_powersaver: Use struct_size() in kzalloc()
On 07-01-19, 11:33, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/cpufreq/e_powersaver.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/e_powersaver.c b/drivers/cpufreq/e_powersaver.c
> index 60bea302abbe..2d3ef208dd70 100644
> --- a/drivers/cpufreq/e_powersaver.c
> +++ b/drivers/cpufreq/e_powersaver.c
> @@ -323,9 +323,8 @@ static int eps_cpu_init(struct cpufreq_policy *policy)
> states = 2;
>
> /* Allocate private data and frequency table for current cpu */
> - centaur = kzalloc(sizeof(*centaur)
> - + (states + 1) * sizeof(struct cpufreq_frequency_table),
> - GFP_KERNEL);
> + centaur = kzalloc(struct_size(centaur, freq_table, states + 1),
> + GFP_KERNEL);
> if (!centaur)
> return -ENOMEM;
> eps_cpu[0] = centaur;
Acked-by: Viresh Kumar
--
viresh
[PATCH] nfit: Hide unused functions behind CONFIG_X86
On arm64 little endian allyesconfig:
drivers/acpi/nfit/intel.c:149:12: warning: unused function
'intel_security_unlock' [-Wunused-function]
static int intel_security_unlock(struct nvdimm *nvdimm,
^
drivers/acpi/nfit/intel.c:230:12: warning: unused function
'intel_security_erase' [-Wunused-function]
static int intel_security_erase(struct nvdimm *nvdimm,
^
drivers/acpi/nfit/intel.c:279:12: warning: unused function
'intel_security_query_overwrite' [-Wunused-function]
static int intel_security_query_overwrite(struct nvdimm *nvdimm)
^
drivers/acpi/nfit/intel.c:316:12: warning: unused function
'intel_security_overwrite' [-Wunused-function]
static int intel_security_overwrite(struct nvdimm *nvdimm,
^
4 warnings generated.
These functions are only used in __intel_security_ops when CONFIG_X86 is
set so only define these functions under that same condition.
Fixes: 4c6926a23b76 ("acpi/nfit, libnvdimm: Add unlock of nvdimm support for
Intel DIMMs")
Signed-off-by: Nathan Chancellor
---
drivers/acpi/nfit/intel.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/nfit/intel.c b/drivers/acpi/nfit/intel.c
index 850b2927b4e7..2ba0f1543940 100644
--- a/drivers/acpi/nfit/intel.c
+++ b/drivers/acpi/nfit/intel.c
@@ -144,6 +144,7 @@ static int intel_security_change_key(struct nvdimm *nvdimm,
}
}
+#ifdef CONFIG_X86
static void nvdimm_invalidate_cache(void);
static int intel_security_unlock(struct nvdimm *nvdimm,
@@ -186,6 +187,7 @@ static int intel_security_unlock(struct nvdimm *nvdimm,
return 0;
}
+#endif
static int intel_security_disable(struct nvdimm *nvdimm,
const struct nvdimm_key_data *key_data)
@@ -227,6 +229,7 @@ static int intel_security_disable(struct nvdimm *nvdimm,
return 0;
}
+#ifdef CONFIG_X86
static int intel_security_erase(struct nvdimm *nvdimm,
const struct nvdimm_key_data *key,
enum nvdimm_passphrase_type ptype)
@@ -360,16 +363,10 @@ static int intel_security_overwrite(struct nvdimm *nvdimm,
* TODO: define a cross arch wbinvd equivalent when/if
* NVDIMM_FAMILY_INTEL command support arrives on another arch.
*/
-#ifdef CONFIG_X86
static void nvdimm_invalidate_cache(void)
{
wbinvd_on_all_cpus();
}
-#else
-static void nvdimm_invalidate_cache(void)
-{
- WARN_ON_ONCE("cache invalidation required after unlock\n");
-}
#endif
static const struct nvdimm_security_ops __intel_security_ops = {
--
2.20.1
Re: [PATCH 4.14 000/101] 4.14.92-stable review
On 1/7/19 4:31 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.92 release. There are 101 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 Wed Jan 9 10:53:00 UTC 2019. Anything received after that time might be too late. For v4.14.91-100-g31e3578310df: Build results: total: 171 pass: 167 fail: 4 Failed builds: arm:allmodconfig mips:allmodconfig parisc:allmodconfig xtensa:allmodconfig Qemu test results: total: 317 pass: 316 fail: 1 Failed tests: mipsel64:fuloong2e_defconfig:fulong2e:rootfs Failures are reported earlier for other releases. Guenter
Re: [PATCH] xfs: correct statx's result_mask value
On 1/8/2019 2:04 AM, Eric Sandeen wrote: On 1/7/19 11:52 AM, Darrick J. Wong wrote: On Mon, Jan 07, 2019 at 04:53:10AM -0500, Su Yanjun wrote: For statx syscall, xfs return the wrong result_mask. Signed-off-by: Su Yanjun --- fs/xfs/xfs_iops.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index f48ffd7..3811457 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -521,6 +521,9 @@ xfs_vn_getattr( stat->btime.tv_nsec = ip->i_d.di_crtime.t_nsec; } } + + /* Only return mask that we care */ + stat->result_mask &= request_mask; Why not just: stat->result_mask = STATX_BASIC_STATS; at the top of the function? I don't see the need to mask off result_mask at all, since we could some day elect to return more than what's in request_mask... When we run xfstests with nfs, the generic/423 case runs failed. So i review the nfs' nfs_getattr code it does validate the request_mask. Then i review the xfs' getattr code, it has no such check. Whatever request_mask is set, the stat's result_mask always the 0x7ff. Maybe it has Unclear semantics about statx's result_mask. ...waitaminute, are you seeing garbage in the result_mask that's returned to userspace? I also noticed the vfs stat functions declare "struct kstat stat;" without explicitly zeroing the structure fields, which means (I think) that we can leak stack information if the kernel isn't built with the stackleak plugin? No such problem. A clear problem statement and reproducer steps would be hugely useful here. -Eric Thanks, Su
Re: [PATCH 4.9 00/71] 4.9.149-stable review
On 1/7/19 4:32 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.149 release. There are 71 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 Wed Jan 9 10:53:04 UTC 2019. Anything received after that time might be too late. For v4.9.148-69-gd1d800b1ed7a: Build results: total: 171 pass: 165 fail: 6 Failed builds: arm:allmodconfig mips:allmodconfig parisc:allmodconfig powerpc:allmodconfig sparc64:allmodconfig xtensa:allmodconfig Qemu test results: total: 305 pass: 305 fail: 0 Failures as reported earlier for other releases. Guenter
Re: linux-next: build failure after merge of the akpm-current tree
On 01/08/2019 07:41 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (native
> perf) failed like this:
>
> bench/numa.c: In function 'bind_to_node':
> bench/numa.c:301:21: error: 'NUMA_NO_NODE' undeclared (first use in this
> function); did you mean 'NUMA_NUM_NODES'?
> if (target_node == NUMA_NO_NODE) {
> ^~~~
> NUMA_NUM_NODES
> bench/numa.c:301:21: note: each undeclared identifier is reported only once
> for each function it appears in
> bench/numa.c: In function 'bind_to_memnode':
> bench/numa.c:342:14: error: 'NUMA_NO_NODE' undeclared (first use in this
> function); did you mean 'NUMA_NUM_NODES'?
> if (node == NUMA_NO_NODE)
> ^~~~
> NUMA_NUM_NODES
> bench/numa.c: In function 'init_thread_data':
> bench/numa.c:1366:19: error: 'NUMA_NO_NODE' undeclared (first use in this
> function); did you mean 'NUMA_NUM_NODES'?
>td->bind_node = NUMA_NO_NODE;
>^~~~
>NUMA_NUM_NODES
>
> Caused by commit
>
> 3856193d8452 ("tools/: replace open encodings for NUMA_NO_NODE")
>
> [BTW, I did not write that patch, just added fixes last time]
Yes I had consolidated parts from the original patch into the build failure fix.
> [BTW 2, there are lots of cc's that probably no longer apply since this
> was split form the previous patch]
Hmm. I had sent it as a series. So the second patch just carried over all the CC
for the first one as well.
>
> I have applied the following fix patch:
>
> From: Stephen Rothwell
> Date: Tue, 8 Jan 2019 13:08:32 +1100
> Subject: [PATCH] tools/: fix for replace open encodings for NUMA_NO_NODE
>
> Signed-off-by: Stephen Rothwell
> ---
> tools/perf/bench/numa.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
> index e0ad5f1de226..98ad783efc69 100644
> --- a/tools/perf/bench/numa.c
> +++ b/tools/perf/bench/numa.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
Just curious why the NUMA_NO_NODE definition did not get resolved from the local
numa.h which had the same ones copied over from linux/numa.h but anyways the fix
looks okay.
