Re: [PATCH] sysctl: use min() helper for namecmp()
(CC: Andrew Morton)
A friendly reminder.
This is just a minor clean-up.
If nobody picks it up,
I hope perhaps Andrew Morton will do.
This patch:
https://lore.kernel.org/patchwork/patch/1360092/
On Mon, Jan 4, 2021 at 5:33 PM Masahiro Yamada wrote:
>
> Make it slightly readable by using min().
>
> Signed-off-by: Masahiro Yamada
> ---
>
> fs/proc/proc_sysctl.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> index 317899222d7f..86341c0f0c40 100644
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -94,14 +94,9 @@ static void sysctl_print_dir(struct ctl_dir *dir)
>
> static int namecmp(const char *name1, int len1, const char *name2, int len2)
> {
> - int minlen;
> int cmp;
>
> - minlen = len1;
> - if (minlen > len2)
> - minlen = len2;
> -
> - cmp = memcmp(name1, name2, minlen);
> + cmp = memcmp(name1, name2, min(len1, len2));
> if (cmp == 0)
> cmp = len1 - len2;
> return cmp;
> --
> 2.27.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 5/5] HID: apple-touchbar - Add driver for the Touch Bar on MacBook Pro's.
Hi "Ronald, Thank you for the patch! Yet something to improve: [auto build test ERROR on hid/for-next] [also build test ERROR on iio/togreg jikos-trivial/for-next v5.11 next-20210226] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Ronald-Tschal-r/Touch-Bar-and-ALS-support-for-MacBook-Pro-s/20210228-093451 base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/cfbb470c2977fd10aef2791b57bdfa2d95f627e0 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Ronald-Tschal-r/Touch-Bar-and-ALS-support-for-MacBook-Pro-s/20210228-093451 git checkout cfbb470c2977fd10aef2791b57bdfa2d95f627e0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=m68k If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "__divdi3" [drivers/hid/apple-touchbar.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] copy_file_range.2: Kernel v5.12 updates
On Sun, Feb 28, 2021 at 1:08 AM Steve French wrote:
>
> On Fri, Feb 26, 2021 at 11:43 PM Amir Goldstein wrote:
> >
> > On Sat, Feb 27, 2021 at 12:19 AM Alejandro Colomar (man-pages)
> > wrote:
> > >
> > > Hello Amir, Luis,
> > >
> > > On 2/24/21 5:10 PM, Amir Goldstein wrote:
> > > > On Wed, Feb 24, 2021 at 4:22 PM Luis Henriques
> > > > wrote:
> > > >>
> > > >> Update man-page with recent changes to this syscall.
> > > >>
> > > >> Signed-off-by: Luis Henriques
> > > >> ---
> > > >> Hi!
> > > >>
> > > >> Here's a suggestion for fixing the manpage for copy_file_range().
> > > >> Note that
> > > >> I've assumed the fix will hit 5.12.
> > > >>
> > > >> man2/copy_file_range.2 | 10 +-
> > > >> 1 file changed, 9 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/man2/copy_file_range.2 b/man2/copy_file_range.2
> > > >> index 611a39b8026b..b0fd85e2631e 100644
> > > >> --- a/man2/copy_file_range.2
> > > >> +++ b/man2/copy_file_range.2
> > > >> @@ -169,6 +169,9 @@ Out of memory.
> > > >> .B ENOSPC
> > > >> There is not enough space on the target filesystem to complete the
> > > >> copy.
> > > >> .TP
> > > >> +.B EOPNOTSUPP
> > >
> > > I'll add the kernel version here:
> > >
> > > .BR EOPNOTSUPP " (since Linux 5.12)"
> >
> > Error could be returned prior to 5.3 and would be probably returned
> > by future stable kernels 5.3..5.12 too
> >
> > >
> > > >> +The filesystem does not support this operation >> +.TP
> > > >> .B EOVERFLOW
> > > >> The requested source or destination range is too large to represent
> > > >> in the
> > > >> specified data types.
> > > >> @@ -187,7 +190,7 @@ refers to an active swap file.
> > > >> .B EXDEV
> > > >> The files referred to by
> > > >> .IR fd_in " and " fd_out
> > > >> -are not on the same mounted filesystem (pre Linux 5.3).
> > > >> +are not on the same mounted filesystem (pre Linux 5.3 and post Linux
> > > >> 5.12).
> > >
> > > I'm not sure that 'mounted' adds any value here. Would you remove the
> > > word here?
> >
> > See rename(2). 'mounted' in this context is explained there.
> > HOWEVER, it does not fit here.
> > copy_file_range() IS allowed between two mounts of the same filesystem
> > instance.
> >
> > To make things more complicated, it appears that cross mount clone is not
> > allowed via FICLONE/FICLONERANGE ioctl, so ioctl_ficlonerange(2) man page
> > also uses the 'mounted filesystem' terminology for EXDEV
> >
> > As things stand now, because of the fallback to clone logic,
> > copy_file_range() provides a way for users to clone across different mounts
> > of the same filesystem instance, which they cannot do with the FICLONE
> > ioctl.
> >
> > Fun :)
> >
> > BTW, I don't know if preventing cross mount clone was done intentionally,
> > but as I wrote in a comment in the code once:
> >
> > /*
> > * FICLONE/FICLONERANGE ioctls enforce that src and dest files are
> > on
> > * the same mount. Practically, they only need to be on the same
> > file
> > * system.
> > */
> >
> > >
> > > It reads as if two separate devices with the same filesystem type would
> > > still give this error.
> > >
> > > Per the LWN.net article Amir shared, this is permitted ("When called
> > > from user space, copy_file_range() will only try to copy a file across
> > > filesystems if the two are of the same type").
> > >
> > > This behavior was slightly different before 5.3 AFAICR (was it?) ("until
> > > then, copy_file_range() refused to copy between files that were not
> > > located on the same filesystem."). If that's the case, I'd specify the
> > > difference, or more probably split the error into two, one before 5.3,
> > > and one since 5.12.
> > >
> >
> > True.
> >
> > > >
> > > > I think you need to drop the (Linux range) altogether.
> > >
> > > I'll keep the range. Users of 5.3..5.11 might be surprised if the
> > > filesystems are different and they don't get an error, I think.
> > >
> > > I reworded it to follow other pages conventions:
> > >
> > > .BR EXDEV " (before Linux 5.3; or since Linux 5.12)"
> > >
> > > which renders as:
> > >
> > > EXDEV (before Linux 5.3; or since Linux 5.12)
> > >The files referred to by fd_in and fd_out are not on
> > >the same mounted filesystem.
> > >
> >
> > drop 'mounted'
> >
> > >
> > > > What's missing here is the NFS cross server copy use case.
> > > > Maybe:
>
> At least for the SMB3 kernel server (ksmbd "cifsd") looks like they use
> splice.
> And for the user space CIFS/SMB3 server (like Samba) they have a configurable
> plug in library interface ("Samba VFS modules") that would allow you
> to implement
> cross filesystem copy optimally for your version of Linux and plug
> this into Samba
> with little work on your part.
>
> > >
> > > Again, this wasn't true before 5.3, right?
> > >
> >
> > Right.
> > Actually, v5.3 provides the vfs capabilities for filesystems to support
> > cross fs copy. I am not sure if NFS
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:1403:12: warning: stack frame size of 1088 bytes in function 'cdns_mhdp_link_up'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 commit: fb43aa0acdfd600c75b8c877bdf9f6e9893ffc9b drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge date: 5 months ago config: powerpc-randconfig-r026-20210228 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project e0b1df924ae06d6d88582334087d2eacc6702e8f) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb43aa0acdfd600c75b8c877bdf9f6e9893ffc9b git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout fb43aa0acdfd600c75b8c877bdf9f6e9893ffc9b # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:26: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:43:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insb, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :95:1: note: expanded from here __do_insb ^ arch/powerpc/include/asm/io.h:541:56: note: expanded from macro '__do_insb' #define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:26: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :97:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:26: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :99:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:26: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :101:1: note: expanded from here __do_outsb ^ arch/powerpc/include/asm/io.h:544:58: note: expanded from macro
Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability
On Sun, Feb 28, 2021 at 3:53 PM Nathan Chancellor wrote:
>
> On Sat, Feb 27, 2021 at 11:49:36PM -0700, Nathan Chancellor wrote:
> > On Sun, Feb 28, 2021 at 12:15:16PM +0900, Masahiro Yamada wrote:
> > > On Sun, Feb 28, 2021 at 3:41 AM Masahiro Yamada
> > > wrote:
> > > >
> > > > This commit reverts 0bf6276392e9 ("x32: Warn and disable rather than
> > > > error if binutils too old").
> > > >
> > > > The help text in arch/x86/Kconfig says enabling the X32 ABI support
> > > > needs binutils 2.22 or later. This is met because the minimal binutils
> > > > version is 2.23 according to Documentation/process/changes.rst.
> > > >
> > > > I would not say I am not familiar with toolchain configuration, but
> > >
> > > I mean:
> > > I would not say I am familiar ...
> > > That is why I added RFC.
> > >
> > > I appreciate comments from people who are familiar
> > > with toolchains (binutils, llvm).
> > >
> > > If this change is not safe,
> > > we can move this check to Kconfig at least.
> >
> > Hi Masahiro,
> >
> > As Fangrui pointed out, there are two outstanding issues with x32 with
> > LLVM=1, both seemingly related to LLVM=1.
> ^ llvm-objcopy
>
> Sigh, note to self, don't write emails while tired...
>
Fangrui, Nathan, thanks for your comments.
OK, then we still need to carry this toolchain check.
--
Best Regards
Masahiro Yamada
Re: [PATCH 4/4] kbuild: include Makefile.compiler only when compiler is required
On Sun, Feb 28, 2021 at 3:10 PM Masahiro Yamada wrote:
>
> Since commit f2f02ebd8f38 ("kbuild: improve cc-option to clean up all
> temporary files"), running 'make kernelversion' in a read-only source
> tree emits a bunch of warnings:
>
> mkdir: cannot create directory '.tmp_12345': Permission denied
>
> Non-build targets such as kernelversion, clean, help, etc. do not
> need to evaluate $(call cc-option,) and friends. Do not include
> Makefile.compiler so $(call cc-option,) becomes no-op.
>
> This not only fix the warnings, but also runs non-build targets much
> faster.
>
> Basically, all installation targets should also be non-build targets.
> Unfortunately, vdso_install requires the compiler because it builds
> vdso before installtion. This is a problem that must be fixed by a
> separate patch.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> I am not adding Reported-by for now because a reporter sent me
> an email privately.
>
> If he allows me to add Reported-by, I will add it to record
> the credit.
>
> (Perhaps, another person might have reported a similar issue
> somewhere, but my memory is obsure. I cannot recall it.)
>
Now, I got acknowledge to add this:
Reported-by: Israel Tsadok
> Makefile | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index eec7a94f5c33..20724711dc71 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -263,6 +263,10 @@ no-dot-config-targets := $(clean-targets) \
> $(version_h) headers headers_% archheaders
> archscripts \
> %asm-generic kernelversion %src-pkg dt_binding_check
> \
> outputmakefile
> +# Installation targets should not require compiler. Unfortunately,
> vdso_install
> +# is an exception where build artifacts may be updated. This must be fixed.
> +no-compiler-targets := $(no-dot-config-targets) install dtbs_install \
> + headers_install modules_install kernelrelease
> image_name
> no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease \
> image_name
> single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
> @@ -270,6 +274,7 @@ single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o
> %.s %.symtypes %/
> config-build :=
> mixed-build:=
> need-config:= 1
> +need-compiler := 1
> may-sync-config:= 1
> single-build :=
>
> @@ -279,6 +284,12 @@ ifneq ($(filter $(no-dot-config-targets),
> $(MAKECMDGOALS)),)
> endif
> endif
>
> +ifneq ($(filter $(no-compiler-targets), $(MAKECMDGOALS)),)
> + ifeq ($(filter-out $(no-compiler-targets), $(MAKECMDGOALS)),)
> + need-compiler :=
> + endif
> +endif
> +
> ifneq ($(filter $(no-sync-config-targets), $(MAKECMDGOALS)),)
> ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
> may-sync-config :=
> @@ -584,7 +595,9 @@ endif
>
> # Include this also for config targets because some architectures need
> # cc-cross-prefix to determine CROSS_COMPILE.
> +ifdef need-compiler
> include $(srctree)/scripts/Makefile.compiler
> +endif
>
> ifdef config-build
> # ===
> --
> 2.27.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH] devfreq: rk3399_dmc: Simplify with dev_err_probe()
On 21. 2. 28. 오전 1:35, Krzysztof Kozlowski wrote:
On Sat, 29 Aug 2020 at 15:10, Chanwoo Choi wrote:
On Sat, Aug 29, 2020 at 12:31 AM Krzysztof Kozlowski wrote:
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski
---
drivers/devfreq/rk3399_dmc.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 027769e39f9b..35b3542f1f7b 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -324,22 +324,14 @@ static int rk3399_dmcfreq_probe(struct platform_device
*pdev)
mutex_init(>lock);
data->vdd_center = devm_regulator_get(dev, "center");
- if (IS_ERR(data->vdd_center)) {
- if (PTR_ERR(data->vdd_center) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- dev_err(dev, "Cannot get the regulator \"center\"\n");
- return PTR_ERR(data->vdd_center);
- }
+ if (IS_ERR(data->vdd_center))
+ return dev_err_probe(dev, PTR_ERR(data->vdd_center),
+"Cannot get the regulator \"center\"\n");
data->dmc_clk = devm_clk_get(dev, "dmc_clk");
- if (IS_ERR(data->dmc_clk)) {
- if (PTR_ERR(data->dmc_clk) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- dev_err(dev, "Cannot get the clk dmc_clk\n");
- return PTR_ERR(data->dmc_clk);
- }
+ if (IS_ERR(data->dmc_clk))
+ return dev_err_probe(dev, PTR_ERR(data->dmc_clk),
+"Cannot get the clk dmc_clk\n");
data->edev = devfreq_event_get_edev_by_phandle(dev, 0);
if (IS_ERR(data->edev))
--
2.17.1
Applied it. Thanks.
Hi Chanwoo,
Do you know what happened with this patch? You replied that it is
applied but I cannot find it in the Linus' or next trees.
Hi Krzysztof,
There was some my mistake. I'm sorry.
I applied it again to next branch.
--
Best Regards,
Samsung Electronics
Chanwoo Choi
Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability
On Sat, Feb 27, 2021 at 11:49:36PM -0700, Nathan Chancellor wrote:
> On Sun, Feb 28, 2021 at 12:15:16PM +0900, Masahiro Yamada wrote:
> > On Sun, Feb 28, 2021 at 3:41 AM Masahiro Yamada
> > wrote:
> > >
> > > This commit reverts 0bf6276392e9 ("x32: Warn and disable rather than
> > > error if binutils too old").
> > >
> > > The help text in arch/x86/Kconfig says enabling the X32 ABI support
> > > needs binutils 2.22 or later. This is met because the minimal binutils
> > > version is 2.23 according to Documentation/process/changes.rst.
> > >
> > > I would not say I am not familiar with toolchain configuration, but
> >
> > I mean:
> > I would not say I am familiar ...
> > That is why I added RFC.
> >
> > I appreciate comments from people who are familiar
> > with toolchains (binutils, llvm).
> >
> > If this change is not safe,
> > we can move this check to Kconfig at least.
>
> Hi Masahiro,
>
> As Fangrui pointed out, there are two outstanding issues with x32 with
> LLVM=1, both seemingly related to LLVM=1.
^ llvm-objcopy
Sigh, note to self, don't write emails while tired...
Cheers,
Nathan
>
> https://github.com/ClangBuiltLinux/linux/issues/514
> https://github.com/ClangBuiltLinux/linux/issues/1141
>
> Additionally, there appears to be one from Arnd as well but that one has
> received no triage yet.
>
> https://github.com/ClangBuiltLinux/linux/issues/1205
>
> I intend to test this patch as well as a few others at some point in the
> coming week although I am having to play sysadmin due to moving servers
> so I might not be able to get to it until later in the week.
>
> Cheers,
> Nathan
>
> > > I checked the configure.tgt code in binutils. The elf32_x86_64
> > > emulation mode seems to be included when it is configured for the
> > > x86_64-*-linux-* target.
> > >
> > > I also tried lld and llvm-objcopy, and succeeded in building x32 VDSO.
> > >
> > > I removed the compile-time check in arch/x86/Makefile, in the hope of
> > > elf32_x86_64 being always supported.
> > >
> > > With this, CONFIG_X86_X32 and CONFIG_X86_X32_ABI will be equivalent.
> > > Rename the former to the latter.
> > >
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > arch/x86/Kconfig | 8 ++--
> > > arch/x86/Makefile | 16
> > > arch/x86/include/asm/syscall_wrapper.h | 6 +++---
> > > arch/x86/include/asm/vdso.h| 2 +-
> > > arch/x86/kernel/process_64.c | 2 +-
> > > fs/fuse/file.c | 2 +-
> > > fs/xfs/xfs_ioctl32.c | 2 +-
> > > sound/core/control_compat.c| 16
> > > sound/core/pcm_compat.c| 20 ++--
> > > 9 files changed, 27 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index 2792879d398e..7272cba2744c 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -2865,7 +2865,7 @@ config IA32_AOUT
> > > help
> > > Support old a.out binaries in the 32bit emulation.
> > >
> > > -config X86_X32
> > > +config X86_X32_ABI
> > > bool "x32 ABI for 64-bit mode"
> > > depends on X86_64
> > > help
> > > @@ -2874,10 +2874,6 @@ config X86_X32
> > > full 64-bit register file and wide data path while leaving
> > > pointers at 32 bits for smaller memory footprint.
> > >
> > > - You will need a recent binutils (2.22 or later) with
> > > - elf32_x86_64 support enabled to compile a kernel with this
> > > - option set.
> > > -
> > > config COMPAT_32
> > > def_bool y
> > > depends on IA32_EMULATION || X86_32
> > > @@ -2886,7 +2882,7 @@ config COMPAT_32
> > >
> > > config COMPAT
> > > def_bool y
> > > - depends on IA32_EMULATION || X86_X32
> > > + depends on IA32_EMULATION || X86_X32_ABI
> > >
> > > if COMPAT
> > > config COMPAT_FOR_U64_ALIGNMENT
> > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > > index 2d6d5a28c3bf..e163549f5be7 100644
> > > --- a/arch/x86/Makefile
> > > +++ b/arch/x86/Makefile
> > > @@ -125,22 +125,6 @@ else
> > > KBUILD_CFLAGS += -mcmodel=kernel
> > > endif
> > >
> > > -ifdef CONFIG_X86_X32
> > > - x32_ld_ok := $(call try-run,\
> > > - /bin/echo -e '1: .quad 1b' | \
> > > - $(CC) $(KBUILD_AFLAGS) -c -x assembler -o "$$TMP"
> > > - && \
> > > - $(OBJCOPY) -O elf32-x86-64 "$$TMP" "$$TMPO" && \
> > > - $(LD) -m elf32_x86_64 "$$TMPO" -o "$$TMP",y,n)
> > > -ifeq ($(x32_ld_ok),y)
> > > -CONFIG_X86_X32_ABI := y
> > > -KBUILD_AFLAGS += -DCONFIG_X86_X32_ABI
> > > -KBUILD_CFLAGS += -DCONFIG_X86_X32_ABI
> > > -else
> > > -$(warning CONFIG_X86_X32 enabled but no binutils support)
> > > -endif
> > > -endif
> > >
Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability
On Sun, Feb 28, 2021 at 12:15:16PM +0900, Masahiro Yamada wrote:
> On Sun, Feb 28, 2021 at 3:41 AM Masahiro Yamada wrote:
> >
> > This commit reverts 0bf6276392e9 ("x32: Warn and disable rather than
> > error if binutils too old").
> >
> > The help text in arch/x86/Kconfig says enabling the X32 ABI support
> > needs binutils 2.22 or later. This is met because the minimal binutils
> > version is 2.23 according to Documentation/process/changes.rst.
> >
> > I would not say I am not familiar with toolchain configuration, but
>
> I mean:
> I would not say I am familiar ...
> That is why I added RFC.
>
> I appreciate comments from people who are familiar
> with toolchains (binutils, llvm).
>
> If this change is not safe,
> we can move this check to Kconfig at least.
Hi Masahiro,
As Fangrui pointed out, there are two outstanding issues with x32 with
LLVM=1, both seemingly related to LLVM=1.
https://github.com/ClangBuiltLinux/linux/issues/514
https://github.com/ClangBuiltLinux/linux/issues/1141
Additionally, there appears to be one from Arnd as well but that one has
received no triage yet.
https://github.com/ClangBuiltLinux/linux/issues/1205
I intend to test this patch as well as a few others at some point in the
coming week although I am having to play sysadmin due to moving servers
so I might not be able to get to it until later in the week.
Cheers,
Nathan
> > I checked the configure.tgt code in binutils. The elf32_x86_64
> > emulation mode seems to be included when it is configured for the
> > x86_64-*-linux-* target.
> >
> > I also tried lld and llvm-objcopy, and succeeded in building x32 VDSO.
> >
> > I removed the compile-time check in arch/x86/Makefile, in the hope of
> > elf32_x86_64 being always supported.
> >
> > With this, CONFIG_X86_X32 and CONFIG_X86_X32_ABI will be equivalent.
> > Rename the former to the latter.
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > arch/x86/Kconfig | 8 ++--
> > arch/x86/Makefile | 16
> > arch/x86/include/asm/syscall_wrapper.h | 6 +++---
> > arch/x86/include/asm/vdso.h| 2 +-
> > arch/x86/kernel/process_64.c | 2 +-
> > fs/fuse/file.c | 2 +-
> > fs/xfs/xfs_ioctl32.c | 2 +-
> > sound/core/control_compat.c| 16
> > sound/core/pcm_compat.c| 20 ++--
> > 9 files changed, 27 insertions(+), 47 deletions(-)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 2792879d398e..7272cba2744c 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -2865,7 +2865,7 @@ config IA32_AOUT
> > help
> > Support old a.out binaries in the 32bit emulation.
> >
> > -config X86_X32
> > +config X86_X32_ABI
> > bool "x32 ABI for 64-bit mode"
> > depends on X86_64
> > help
> > @@ -2874,10 +2874,6 @@ config X86_X32
> > full 64-bit register file and wide data path while leaving
> > pointers at 32 bits for smaller memory footprint.
> >
> > - You will need a recent binutils (2.22 or later) with
> > - elf32_x86_64 support enabled to compile a kernel with this
> > - option set.
> > -
> > config COMPAT_32
> > def_bool y
> > depends on IA32_EMULATION || X86_32
> > @@ -2886,7 +2882,7 @@ config COMPAT_32
> >
> > config COMPAT
> > def_bool y
> > - depends on IA32_EMULATION || X86_X32
> > + depends on IA32_EMULATION || X86_X32_ABI
> >
> > if COMPAT
> > config COMPAT_FOR_U64_ALIGNMENT
> > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > index 2d6d5a28c3bf..e163549f5be7 100644
> > --- a/arch/x86/Makefile
> > +++ b/arch/x86/Makefile
> > @@ -125,22 +125,6 @@ else
> > KBUILD_CFLAGS += -mcmodel=kernel
> > endif
> >
> > -ifdef CONFIG_X86_X32
> > - x32_ld_ok := $(call try-run,\
> > - /bin/echo -e '1: .quad 1b' | \
> > - $(CC) $(KBUILD_AFLAGS) -c -x assembler -o "$$TMP" -
> > && \
> > - $(OBJCOPY) -O elf32-x86-64 "$$TMP" "$$TMPO" && \
> > - $(LD) -m elf32_x86_64 "$$TMPO" -o "$$TMP",y,n)
> > -ifeq ($(x32_ld_ok),y)
> > -CONFIG_X86_X32_ABI := y
> > -KBUILD_AFLAGS += -DCONFIG_X86_X32_ABI
> > -KBUILD_CFLAGS += -DCONFIG_X86_X32_ABI
> > -else
> > -$(warning CONFIG_X86_X32 enabled but no binutils support)
> > -endif
> > -endif
> > -export CONFIG_X86_X32_ABI
> > -
> > #
> > # If the function graph tracer is used with mcount instead of fentry,
> > # '-maccumulate-outgoing-args' is needed to prevent a GCC bug
> > diff --git a/arch/x86/include/asm/syscall_wrapper.h
> > b/arch/x86/include/asm/syscall_wrapper.h
> > index a84333adeef2..69bf87c41a0b 100644
> > --- a/arch/x86/include/asm/syscall_wrapper.h
> > +++ b/arch/x86/include/asm/syscall_wrapper.h
> > @@ -158,7 +158,7
[RFC PATCH 17/18] docs: cgroup-v1: Add IOASIDs controller
Signed-off-by: Jacob Pan --- Documentation/admin-guide/cgroup-v1/index.rst | 1 + .../admin-guide/cgroup-v1/ioasids.rst | 110 ++ 2 files changed, 111 insertions(+) create mode 100644 Documentation/admin-guide/cgroup-v1/ioasids.rst diff --git a/Documentation/admin-guide/cgroup-v1/index.rst b/Documentation/admin-guide/cgroup-v1/index.rst index 226f64473e8e..f5e307dc4dbb 100644 --- a/Documentation/admin-guide/cgroup-v1/index.rst +++ b/Documentation/admin-guide/cgroup-v1/index.rst @@ -15,6 +15,7 @@ Control Groups version 1 devices freezer-subsystem hugetlb +ioasids memcg_test memory net_cls diff --git a/Documentation/admin-guide/cgroup-v1/ioasids.rst b/Documentation/admin-guide/cgroup-v1/ioasids.rst new file mode 100644 index ..b30eb41bf1be --- /dev/null +++ b/Documentation/admin-guide/cgroup-v1/ioasids.rst @@ -0,0 +1,110 @@ + +I/O Address Space ID (IOASID) Controller + + +Acronyms + +PASID: + Process Address Space ID, defined by PCIe +SVA: + Shared Virtual Address + +Introduction + + +IOASIDs are used to associate DMA requests with virtual address spaces. As +a system-wide limited¹ resource, its constraints are managed by the IOASIDs +cgroup subsystem. The specific use cases are: + +1. Some user applications exhaust all the available IOASIDs thus depriving + others of the same host. + +2. System admins need to provision VMs based on their needs for IOASIDs, + e.g. the number of VMs with assigned devices that perform DMA requests + with PASID. + +The IOASID subsystem consists of three components: + +- IOASID core: provides APIs for allocation, pool management, + notifications and refcounting. See Documentation/driver-api/ioasid.rst + for details +- IOASID user: provides user allocation interface via /dev/ioasid +- IOASID cgroup controller: manage resource distribution + +Resource Distribution Model +--- +IOASID allocation is process-based in that IOASIDs are tied to page tables², +the threaded model is not supported. The allocation is rejected by the +cgroup hierarchy once a limit is reached. However, organizational changes +such as moving processes across cgroups are exempted. Therefore, it is +possible to have ioasids.current > ioasids.max. It is not possible to do +further allocation after the organizational change that exceeds the max. + +The system capacity of the IOASIDs is default to PCIe PASID size of 20 bits. +IOASID core provides API to adjust the system capacity based on platforms. +IOASIDs are used by both user applications (e.g. VMs and userspace drivers) +and kernel (e.g. supervisor SVA). However, only user allocation is subject +to cgroup constraints. Host kernel allocates a pool of IOASIDs where its +quota is subtracted from the system capacity. IOASIDs cgroup consults with +the IOASID core for available capacity when a new cgroup limit is granted. +Upon creation, no IOASID allocation is allowed by the user processes within +the new cgroup. + +Usage +- +CGroup filesystem has the following IOASIDs controller specific entries: +:: + + ioasids.current + ioasids.events + ioasids.max + +To use the IOASIDs controller, set ioasids.max to the limit of the number +of IOASIDs that can be allocated. The file ioasids.current shows the current +number of IOASIDs allocated within the cgroup. + +Example + +1. Mount the cgroup2 FS :: + + $ mount -t cgroup2 none /mnt/cg2/ + +2. Add ioasids controller :: + + $ echo '+ioasids' > /mnt/cg2/cgroup.subtree_control + +3. Create a hierarchy, set non-zero limit (default 0) :: + + $ mkdir /mnt/cg2/test1 + $ echo 5 > /mnt/cg2/test1/ioasids.max + +4. Allocate IOASIDs within limit should succeed :: + + $echo $$ > /mnt/cg2/test1/cgroup.procs + Do IOASID allocation via /dev/ioasid + ioasids.current:1 + ioasids.max:5 + +5. Attempt to allocate IOASIDs beyond limit should fail :: + + ioasids.current:5 + ioasids.max:5 + +6. Attach a new process with IOASID already allocated to a cgroup could +result in ioasids.current > ioasids.max, e.g. process with PID 1234 under +a cgroup with IOASIDs controller has one IOASID allocated, moving it to +test1 cgroup :: + + $echo 1234 > /mnt/cg2/test1/cgroup.procs + ioasids.current:6 + ioasids.max:5 + +Notes +- +¹ When IOASID is used for PCI Express PASID, the range is limited to the +PASID size of 20 bits. For a device that its resources can be shared across +the platform, the IOASID namespace must be system-wide in order to uniquely +identify DMA request with PASID inside the device. + +² The primary use case is SVA, where CPU page tables are shared with DMA via +IOMMU. -- 2.25.1
[RFC PATCH 18/18] ioasid: Add /dev/ioasid for userspace
From: Liu Yi L
I/O Address Space IDs (IOASIDs) is used to tag DMA requests to target
multiple DMA address spaces for physical devices. Its PCI terminology
is called PASID (Process Address Space ID). Platforms with PASID support
can provide PASID granularity DMA isolation, which is very useful for
efficient and secure device sharing (SVA, subdevice passthrough, etc.).
Today only kernel drivers are allowed to allocate IOASIDs [1]. This patch
aims to extend this capability to userspace as required in device pass-
through scenarios. For example, a userspace driver may want to create its
own DMA address spaces besides the default IOVA address space established
by the kernel on the assigned device (e.g. vDPA control vq [2] and guest
SVA [3]), thus need to get IOASIDs from the kernel IOASID allocator for
tagging. In concept, each device can have its own IOASID space, thus it's
also possible for userspace driver to manage a private IOASID space itself,
say, when PF/VF is assigned. However it doesn't work for subdevice pass-
through, as multiple subdevices under the same parent device share a single
IOASID space thus IOASIDs must be centrally managed by the kernel in such
case.
This patch introduces a /dev/ioasid interface for this purpose (per discussion
in [4]). An IOASID is just a number before it is tagged to a specific DMA
address space. The actual IOASID tagging (to DMA requests) and association
(with DMA address spaces) operations from userspace are scrutinized by specific
device passthrough frameworks, which must ensure that a malicious driver
cannot program arbitrary IOASIDs to its assigned device to access DMA address
spaces that don't belong to it, this is out of the scope of this patch (a
reference VFIO implementation will be posted soon).
Open:
PCIe PASID is 20bit implying a space with 1M IOASIDs. although it's plenty
there was an open [4] on whether this user interface is open to all processes
or only selective processes (e.g. with device assigned). In this patchseries,
a cgroup controller is introduced to manage IOASID quota that a process is
allowed to use. A cgroup-enabled system may by default set quota=0 to disallow
IOASID allocation for most processes, and then having the virt management
stack to adjust the quota for a process which gets device assigned. But yeah,
we are also willing to hear more suggestions.
[1]
https://lore.kernel.org/linux-iommu/156595-62508-8-git-send-email-jacob.jun@linux.intel.com/
[2] https://lore.kernel.org/kvm/20201216064818.48239-1-jasow...@redhat.com/
[3]
https://lore.kernel.org/linux-iommu/1599734733-6431-1-git-send-email-yi.l@intel.com/
[4] https://lore.kernel.org/kvm/20201014171055.328a5...@w520.home/
Signed-off-by: Liu Yi L
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/ioasid.rst | 49
drivers/iommu/Kconfig | 5 +
drivers/iommu/Makefile | 1 +
drivers/iommu/intel/Kconfig| 1 +
drivers/iommu/ioasid_user.c| 297 +
include/linux/ioasid.h | 26 +++
include/linux/miscdevice.h | 1 +
include/uapi/linux/ioasid.h| 98
9 files changed, 479 insertions(+)
create mode 100644 Documentation/userspace-api/ioasid.rst
create mode 100644 drivers/iommu/ioasid_user.c
create mode 100644 include/uapi/linux/ioasid.h
diff --git a/Documentation/userspace-api/index.rst
b/Documentation/userspace-api/index.rst
index acd2cc2a538d..69e1be7c67ee 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -24,6 +24,7 @@ place where this information is gathered.
ioctl/index
iommu
media/index
+ ioasid
.. only:: subproject and html
diff --git a/Documentation/userspace-api/ioasid.rst
b/Documentation/userspace-api/ioasid.rst
new file mode 100644
index ..879d6cbae858
--- /dev/null
+++ b/Documentation/userspace-api/ioasid.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. ioasid:
+
+=
+IOASID Userspace API
+=
+
+The IOASID UAPI is used for userspace IOASID allocation/free requests,
+thus IOASID management is centralized in the IOASID core[1] in the kernel. The
+primary use case is guest Shared Virtual Address (SVA) today.
+
+Requests such as allocation/free can be issued by the users and managed
+on a per-process basis through the ioasid core. Upon opening ("/dev/ioasid"),
+a process obtains a unique handle associated with the process's mm_struct.
+This handle is mapped to an FD in the userspace. Only a single open is
+allowed per process.
+
+File descriptors can be transferred across processes by employing fork() or
+UNIX domain socket. FDs obtained by transfer cannot be used to perform
+IOASID requests. The following behaviors are recommended for the
+applications:
+
+ - forked children close the parent's IOASID FDs immediately, open new
+
[RFC PATCH 16/18] iommu/ioasid: Consult IOASIDs cgroup for allocation
Once IOASIDs cgroup is active, we must consult the limitation set up
by the cgroups during allocation. Freeing IOASIDs also need to return
the quota back to the cgroup.
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index d42b39ca2c8b..fd3f5729c71d 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -782,7 +782,10 @@ ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t
min, ioasid_t max,
spin_lock(_allocator_lock);
/* Check if the IOASID set has been allocated and initialized */
- if (!ioasid_set_is_valid(set))
+ if (!set || !ioasid_set_is_valid(set))
+ goto done_unlock;
+
+ if (set->type == IOASID_SET_TYPE_MM && ioasid_cg_charge(set))
goto done_unlock;
if (set->quota <= atomic_read(>nr_ioasids)) {
@@ -832,6 +835,7 @@ ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min,
ioasid_t max,
goto done_unlock;
exit_free:
kfree(data);
+ ioasid_cg_uncharge(set);
done_unlock:
spin_unlock(_allocator_lock);
return id;
@@ -849,6 +853,7 @@ static void ioasid_do_free_locked(struct ioasid_data *data)
kfree_rcu(ioasid_data, rcu);
}
atomic_dec(>set->nr_ioasids);
+ ioasid_cg_uncharge(data->set);
xa_erase(>set->xa, data->id);
/* Destroy the set if empty */
if (!atomic_read(>set->nr_ioasids))
--
2.25.1
[RFC PATCH 15/18] cgroup: Introduce ioasids controller
IOASIDs are used to associate DMA requests with virtual address spaces.
They are a system-wide limited resource made available to the userspace
applications. Let it be VMs or user-space device drivers.
This RFC patch introduces a cgroup controller to address the following
problems:
1. Some user applications exhaust all the available IOASIDs thus
depriving others of the same host.
2. System admins need to provision VMs based on their needs for IOASIDs,
e.g. the number of VMs with assigned devices that perform DMA requests
with PASID.
This patch is nowhere near its completion, it merely provides the basic
functionality for resource distribution and cgroup hierarchy
organizational changes.
Since this is part of a greater effort to enable Shared Virtual Address
(SVA) virtualization. We would like to have a direction check and
collect feedback early. For details, please refer to the documentation:
Documentation/admin-guide/cgroup-v1/ioasids.rst
Signed-off-by: Jacob Pan
---
include/linux/cgroup_subsys.h | 4 +
include/linux/ioasid.h| 17 ++
init/Kconfig | 7 +
kernel/cgroup/Makefile| 1 +
kernel/cgroup/ioasids.c | 345 ++
5 files changed, 374 insertions(+)
create mode 100644 kernel/cgroup/ioasids.c
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index acb77dcff3b4..cda75ecdcdcb 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -57,6 +57,10 @@ SUBSYS(hugetlb)
SUBSYS(pids)
#endif
+#if IS_ENABLED(CONFIG_CGROUP_IOASIDS)
+SUBSYS(ioasids)
+#endif
+
#if IS_ENABLED(CONFIG_CGROUP_RDMA)
SUBSYS(rdma)
#endif
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index 4547086797df..5ea4710efb02 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -135,8 +135,25 @@ void ioasid_set_for_each_ioasid(struct ioasid_set *sdata,
void *data);
int ioasid_register_notifier_mm(struct mm_struct *mm, struct notifier_block
*nb);
void ioasid_unregister_notifier_mm(struct mm_struct *mm, struct notifier_block
*nb);
+#ifdef CONFIG_CGROUP_IOASIDS
+int ioasid_cg_charge(struct ioasid_set *set);
+void ioasid_cg_uncharge(struct ioasid_set *set);
+#else
+/* No cgroup control, allocation will proceed until run out total pool */
+static inline int ioasid_cg_charge(struct ioasid_set *set)
+{
+ return 0;
+}
+
+static inline int ioasid_cg_uncharge(struct ioasid_set *set)
+{
+ return 0;
+}
+#endif /* CGROUP_IOASIDS */
bool ioasid_queue_work(struct work_struct *work);
+
#else /* !CONFIG_IOASID */
+
static inline void ioasid_install_capacity(ioasid_t total)
{
}
diff --git a/init/Kconfig b/init/Kconfig
index b77c60f8b963..9a23683dad98 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1017,6 +1017,13 @@ config CGROUP_PIDS
since the PIDs limit only affects a process's ability to fork, not to
attach to a cgroup.
+config CGROUP_IOASIDS
+ bool "IOASIDs controller"
+ depends on IOASID
+ help
+ Provides enforcement of IO Address Space ID limits in the scope of a
+ cgroup.
+
config CGROUP_RDMA
bool "RDMA controller"
help
diff --git a/kernel/cgroup/Makefile b/kernel/cgroup/Makefile
index 5d7a76bfbbb7..c5ad7c9a2305 100644
--- a/kernel/cgroup/Makefile
+++ b/kernel/cgroup/Makefile
@@ -3,6 +3,7 @@ obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o freezer.o
obj-$(CONFIG_CGROUP_FREEZER) += legacy_freezer.o
obj-$(CONFIG_CGROUP_PIDS) += pids.o
+obj-$(CONFIG_CGROUP_IOASIDS) += ioasids.o
obj-$(CONFIG_CGROUP_RDMA) += rdma.o
obj-$(CONFIG_CPUSETS) += cpuset.o
obj-$(CONFIG_CGROUP_DEBUG) += debug.o
diff --git a/kernel/cgroup/ioasids.c b/kernel/cgroup/ioasids.c
new file mode 100644
index ..ac43813da6ad
--- /dev/null
+++ b/kernel/cgroup/ioasids.c
@@ -0,0 +1,345 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * IO Address Space ID limiting controller for cgroups.
+ *
+ */
+#define pr_fmt(fmt)"ioasids_cg: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IOASIDS_MAX_STR "max"
+static DEFINE_MUTEX(ioasids_cg_lock);
+
+struct ioasids_cgroup {
+ struct cgroup_subsys_state css;
+ atomic64_t counter;
+ atomic64_t limit;
+ struct cgroup_file events_file;
+ /* Number of times allocations failed because limit was hit. */
+ atomic64_t events_limit;
+};
+
+static struct ioasids_cgroup *css_ioasids(struct cgroup_subsys_state *css)
+{
+ return container_of(css, struct ioasids_cgroup, css);
+}
+
+static struct ioasids_cgroup *parent_ioasids(struct ioasids_cgroup *ioasids)
+{
+ return css_ioasids(ioasids->css.parent);
+}
+
+static struct cgroup_subsys_state *
+ioasids_css_alloc(struct cgroup_subsys_state *parent)
+{
+ struct ioasids_cgroup *ioasids;
+
+ ioasids = kzalloc(sizeof(struct
[PATCH V4 12/18] iommu/vt-d: Remove mm reference for guest SVA
Now that IOASID core keeps track of the IOASID to mm_struct ownership in
the forms of ioasid_set with IOASID_SET_TYPE_MM token type, there is no
need to keep the same mapping in VT-d driver specific data. Native SVM
usage is not affected by the change.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/svm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index c469c24d23f5..f75699ddb923 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -363,12 +363,6 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
ret = -ENOMEM;
goto out;
}
- /* REVISIT: upper layer/VFIO can track host process that bind
-* the PASID. ioasid_set = mm might be sufficient for vfio to
-* check pasid VMM ownership. We can drop the following line
-* once VFIO and IOASID set check is in place.
-*/
- svm->mm = get_task_mm(current);
svm->pasid = data->hpasid;
if (data->flags & IOMMU_SVA_GPASID_VAL) {
svm->gpasid = data->gpasid;
@@ -376,7 +370,6 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
}
ioasid_attach_data(data->hpasid, svm);
INIT_LIST_HEAD_RCU(>devs);
- mmput(svm->mm);
}
sdev = kzalloc(sizeof(*sdev), GFP_KERNEL);
if (!sdev) {
--
2.25.1
[PATCH V4 14/18] iommu/vt-d: Listen to IOASID notifications
On Intel Scalable I/O Virtualization (SIOV) enabled platforms, IOMMU
driver is one of the users of IOASIDs. In normal flow, callers will
perform IOASID allocation, bind, unbind, and free in order. However, for
guest SVA, IOASID free could come before unbind as guest is untrusted.
This patch registers IOASID notification handler such that IOMMU driver
can perform PASID teardown upon receiving an unexpected IOASID free
event.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/iommu.c | 2 +
drivers/iommu/intel/svm.c | 109 +++-
include/linux/intel-iommu.h | 2 +
3 files changed, 111 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index eb9868061545..d602e89c40d2 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3313,6 +3313,8 @@ static int __init init_dmars(void)
pr_err("Failed to allocate host PASID set %lu\n",
PTR_ERR(host_pasid_set));
intel_iommu_sm = 0;
+ } else {
+ intel_svm_add_pasid_notifier();
}
}
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index f75699ddb923..b5bb9b578281 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -96,6 +96,104 @@ static inline bool intel_svm_capable(struct intel_iommu
*iommu)
return iommu->flags & VTD_FLAG_SVM_CAPABLE;
}
+static inline void intel_svm_drop_pasid(ioasid_t pasid)
+{
+ /*
+* Detaching SPID results in UNBIND notification on the set, we must
+* do this before dropping the IOASID reference, otherwise the
+* notification chain may get destroyed.
+*/
+ ioasid_detach_spid(pasid);
+ ioasid_detach_data(pasid);
+ ioasid_put(NULL, pasid);
+}
+
+static DEFINE_MUTEX(pasid_mutex);
+#define pasid_lock_held() lock_is_held(_mutex.dep_map)
+
+static void intel_svm_free_async_fn(struct work_struct *work)
+{
+ struct intel_svm *svm = container_of(work, struct intel_svm, work);
+ struct intel_svm_dev *sdev;
+
+ /*
+* Unbind all devices associated with this PASID which is
+* being freed by other users such as VFIO.
+*/
+ mutex_lock(_mutex);
+ list_for_each_entry_rcu(sdev, >devs, list, pasid_lock_held()) {
+ /* Does not poison forward pointer */
+ list_del_rcu(>list);
+ spin_lock(>iommu->lock);
+ intel_pasid_tear_down_entry(sdev->iommu, sdev->dev,
+ svm->pasid, true);
+ intel_svm_drain_prq(sdev->dev, svm->pasid);
+ spin_unlock(>iommu->lock);
+ kfree_rcu(sdev, rcu);
+ }
+ /*
+* We may not be the last user to drop the reference but since
+* the PASID is in FREE_PENDING state, no one can get new reference.
+* Therefore, we can safely free the private data svm.
+*/
+ intel_svm_drop_pasid(svm->pasid);
+
+ /*
+* Free before unbind can only happen with host PASIDs used for
+* guest SVM. We get here because ioasid_free is called with
+* outstanding references. So we need to drop the reference
+* such that the PASID can be reclaimed. unbind_gpasid() after this
+* will not result in dropping refcount since the private data is
+* already detached.
+*/
+ kfree(svm);
+
+ mutex_unlock(_mutex);
+}
+
+
+static int pasid_status_change(struct notifier_block *nb,
+ unsigned long code, void *data)
+{
+ struct ioasid_nb_args *args = (struct ioasid_nb_args *)data;
+ struct intel_svm *svm = (struct intel_svm *)args->pdata;
+ int ret = NOTIFY_DONE;
+
+ /*
+* Notification private data is a choice of vendor driver when the
+* IOASID is allocated or attached after allocation. When the data
+* type changes, we must make modifications here accordingly.
+*/
+ if (code == IOASID_NOTIFY_FREE) {
+ /*
+* If PASID UNBIND happens before FREE, private data of the
+* IOASID should be NULL, then we don't need to do anything.
+*/
+ if (!svm)
+ goto done;
+ if (args->id != svm->pasid) {
+ pr_warn("Notify PASID does not match data %d : %d\n",
+ args->id, svm->pasid);
+ goto done;
+ }
+ if (!ioasid_queue_work(>work))
+ pr_warn("Cleanup work already queued\n");
+ return NOTIFY_OK;
+ }
+done:
+ return ret;
+}
+
+static struct notifier_block pasid_nb = {
+ .notifier_call = pasid_status_change,
+};
+
+void intel_svm_add_pasid_notifier(void)
+{
+ /* Listen to all PASIDs, not specific to a
[PATCH V4 13/18] iommu/ioasid: Add a workqueue for cleanup work
An IOASID can have multiple users, such as IOMMU driver, KVM, and device
drivers. The atomic IOASID notifier is used to inform users of IOASID
state change. For example, the IOASID_NOTIFY_UNBIND event is issued when
the IOASID is no longer bound to an address space. This requires ordered
actions among users to tear down their contexts.
Not all work can be handled in the atomic notifier handler. This patch
introduces a shared, ordered workqueue for all IOASID users who wish to
perform work asynchronously upon notification.
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 25 +
include/linux/ioasid.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index 28a2e9b6594d..d42b39ca2c8b 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -32,6 +32,9 @@ static ioasid_t ioasid_capacity = PCI_PASID_MAX;
static ioasid_t ioasid_capacity_avail = PCI_PASID_MAX;
static DEFINE_XARRAY_ALLOC(ioasid_sets);
+/* Workqueue for IOASID users to do cleanup upon notification */
+static struct workqueue_struct *ioasid_wq;
+
struct ioasid_set_nb {
struct list_headlist;
struct notifier_block *nb;
@@ -1281,6 +1284,12 @@ int ioasid_register_notifier_mm(struct mm_struct *mm,
struct notifier_block *nb)
}
EXPORT_SYMBOL_GPL(ioasid_register_notifier_mm);
+bool ioasid_queue_work(struct work_struct *work)
+{
+ return queue_work(ioasid_wq, work);
+}
+EXPORT_SYMBOL_GPL(ioasid_queue_work);
+
void ioasid_unregister_notifier_mm(struct mm_struct *mm, struct notifier_block
*nb)
{
struct ioasid_set_nb *curr;
@@ -1303,7 +1312,23 @@ void ioasid_unregister_notifier_mm(struct mm_struct *mm,
struct notifier_block *
}
EXPORT_SYMBOL_GPL(ioasid_unregister_notifier_mm);
+static int __init ioasid_init(void)
+{
+ ioasid_wq = alloc_ordered_workqueue("ioasid_wq", 0);
+ if (!ioasid_wq)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static void __exit ioasid_cleanup(void)
+{
+ destroy_workqueue(ioasid_wq);
+}
+
MODULE_AUTHOR("Jean-Philippe Brucker ");
MODULE_AUTHOR("Jacob Pan ");
MODULE_DESCRIPTION("IO Address Space ID (IOASID) allocator");
MODULE_LICENSE("GPL");
+module_init(ioasid_init);
+module_exit(ioasid_cleanup);
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index 9624b665f810..4547086797df 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -135,6 +135,7 @@ void ioasid_set_for_each_ioasid(struct ioasid_set *sdata,
void *data);
int ioasid_register_notifier_mm(struct mm_struct *mm, struct notifier_block
*nb);
void ioasid_unregister_notifier_mm(struct mm_struct *mm, struct notifier_block
*nb);
+bool ioasid_queue_work(struct work_struct *work);
#else /* !CONFIG_IOASID */
static inline void ioasid_install_capacity(ioasid_t total)
{
--
2.25.1
[PATCH V4 11/18] iommu/ioasid: Add ownership check in guest bind
Bind guest page table call comes with an IOASID provided by the
userspace. To prevent attacks by malicious users, we must ensure the
IOASID was allocated under the same process.
This patch adds a new API that will perform an ownership check that is
based on whether the IOASID belongs to the ioasid_set allocated with the
mm_struct pointer as a token.
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 37 +
drivers/iommu/iommu.c | 16 ++--
include/linux/ioasid.h | 6 ++
3 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index 96e941dfada7..28a2e9b6594d 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/*
* An IOASID can have multiple consumers where each consumer may have
@@ -1028,6 +1029,42 @@ int ioasid_get(struct ioasid_set *set, ioasid_t ioasid)
}
EXPORT_SYMBOL_GPL(ioasid_get);
+/**
+ * ioasid_get_if_owned - obtain a reference to the IOASID if the IOASID belongs
+ * to the ioasid_set with the current mm as token
+ * @ioasid:the IOASID to get reference
+ *
+ *
+ * Return: 0 on success, error if failed.
+ */
+int ioasid_get_if_owned(ioasid_t ioasid)
+{
+ struct ioasid_set *set;
+ int ret;
+
+ spin_lock(_allocator_lock);
+ set = ioasid_find_set(ioasid);
+ if (IS_ERR_OR_NULL(set)) {
+ ret = -ENOENT;
+ goto done_unlock;
+ }
+ if (set->type != IOASID_SET_TYPE_MM) {
+ ret = -EINVAL;
+ goto done_unlock;
+ }
+ if (current->mm != set->token) {
+ ret = -EPERM;
+ goto done_unlock;
+ }
+
+ ret = ioasid_get_locked(set, ioasid);
+done_unlock:
+ spin_unlock(_allocator_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(ioasid_get_if_owned);
+
bool ioasid_put_locked(struct ioasid_set *set, ioasid_t ioasid)
{
struct ioasid_data *data;
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index fd76e2f579fe..18716d856b02 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2169,7 +2169,13 @@ int iommu_uapi_sva_bind_gpasid(struct iommu_domain
*domain, struct device *dev,
if (ret)
return ret;
- return domain->ops->sva_bind_gpasid(domain, dev, );
+ ret = ioasid_get_if_owned(data.hpasid);
+ if (ret)
+ return ret;
+ ret = domain->ops->sva_bind_gpasid(domain, dev, );
+ ioasid_put(NULL, data.hpasid);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_uapi_sva_bind_gpasid);
@@ -2196,7 +2202,13 @@ int iommu_uapi_sva_unbind_gpasid(struct iommu_domain
*domain, struct device *dev
if (ret)
return ret;
- return iommu_sva_unbind_gpasid(domain, dev, data.hpasid);
+ ret = ioasid_get_if_owned(data.hpasid);
+ if (ret)
+ return ret;
+ ret = iommu_sva_unbind_gpasid(domain, dev, data.hpasid);
+ ioasid_put(NULL, data.hpasid);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_uapi_sva_unbind_gpasid);
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index c97e80ff65cc..9624b665f810 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -111,6 +111,7 @@ ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min,
ioasid_t max,
void *private);
int ioasid_get(struct ioasid_set *set, ioasid_t ioasid);
int ioasid_get_locked(struct ioasid_set *set, ioasid_t ioasid);
+int ioasid_get_if_owned(ioasid_t ioasid);
bool ioasid_put(struct ioasid_set *set, ioasid_t ioasid);
bool ioasid_put_locked(struct ioasid_set *set, ioasid_t ioasid);
void ioasid_free(struct ioasid_set *set, ioasid_t ioasid);
@@ -180,6 +181,11 @@ static inline int ioasid_get_locked(struct ioasid_set
*set, ioasid_t ioasid)
return -ENOTSUPP;
}
+static inline int ioasid_get_if_owned(ioasid_t ioasid)
+{
+ return -ENOTSUPP;
+}
+
static inline bool ioasid_put(struct ioasid_set *set, ioasid_t ioasid)
{
return false;
--
2.25.1
[PATCH V4 10/18] iommu/ioasid: Support mm token type ioasid_set notifications
As a system-wide resource, IOASID is often shared by multiple kernel
subsystems that are independent of each other. However, at the
ioasid_set level, these kernel subsystems must communicate with each
other for ownership checking, event notifications, etc. For example, on
Intel Scalable IO Virtualization (SIOV) enabled platforms, KVM and VFIO
instances under the same process/guest must be aware of a shared IOASID
set.
IOASID_SET_TYPE_MM token type was introduced to explicitly mark an
IOASID set that belongs to a process, thus use the same mm_struct
pointer as a token. Users of the same process can then identify with
each other based on this token.
This patch introduces MM token specific event registration APIs. Event
subscribers such as KVM instances can register IOASID event handler
without the knowledge of its ioasid_set. Event handlers are registered
based on its mm_struct pointer as a token. In case when subscribers
register handler *prior* to the creation of the ioasid_set, the
handler’s notification block is stored in a pending list within IOASID
core. Once the ioasid_set of the MM token is created, the notification
block will be registered by the IOASID core.
Signed-off-by: Liu Yi L
Signed-off-by: Wu Hao
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 142 +
include/linux/ioasid.h | 18 ++
2 files changed, 160 insertions(+)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index 56577e745c4b..96e941dfada7 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -21,6 +21,8 @@
* keep local states in sync.
*/
static ATOMIC_NOTIFIER_HEAD(ioasid_notifier);
+/* List to hold pending notification block registrations */
+static LIST_HEAD(ioasid_nb_pending_list);
static DEFINE_SPINLOCK(ioasid_nb_lock);
/* Default to PCIe standard 20 bit PASID */
@@ -574,6 +576,27 @@ static inline bool ioasid_set_is_valid(struct ioasid_set
*set)
return xa_load(_sets, set->id) == set;
}
+static void ioasid_add_pending_nb(struct ioasid_set *set)
+{
+ struct ioasid_set_nb *curr;
+
+ if (set->type != IOASID_SET_TYPE_MM)
+ return;
+ /*
+* Check if there are any pending nb requests for the given token, if so
+* add them to the notifier chain.
+*/
+ spin_lock(_nb_lock);
+ list_for_each_entry(curr, _nb_pending_list, list) {
+ if (curr->token == set->token && !curr->active) {
+ atomic_notifier_chain_register(>nh, curr->nb);
+ curr->set = set;
+ curr->active = true;
+ }
+ }
+ spin_unlock(_nb_lock);
+}
+
/**
* ioasid_set_alloc - Allocate a new IOASID set for a given token
*
@@ -658,6 +681,11 @@ struct ioasid_set *ioasid_set_alloc(void *token, ioasid_t
quota, int type)
atomic_set(>nr_ioasids, 0);
ATOMIC_INIT_NOTIFIER_HEAD(>nh);
+ /*
+* Check if there are any pending nb requests for the given token, if so
+* add them to the notifier chain.
+*/
+ ioasid_add_pending_nb(set);
/*
* Per set XA is used to store private IDs within the set, get ready
* for ioasid_set private ID and system-wide IOASID allocation
@@ -675,6 +703,7 @@ EXPORT_SYMBOL_GPL(ioasid_set_alloc);
static int ioasid_set_free_locked(struct ioasid_set *set)
{
+ struct ioasid_set_nb *curr;
int ret = 0;
if (!ioasid_set_is_valid(set)) {
@@ -688,6 +717,16 @@ static int ioasid_set_free_locked(struct ioasid_set *set)
}
WARN_ON(!xa_empty(>xa));
+ /* Restore pending status of the set NBs */
+ list_for_each_entry(curr, _nb_pending_list, list) {
+ if (curr->token == set->token) {
+ if (curr->active)
+ curr->active = false;
+ else
+ pr_warn("Set token exists but not active!\n");
+ }
+ }
+
/*
* Token got released right away after the ioasid_set is freed.
* If a new set is created immediately with the newly released token,
@@ -1117,6 +1156,22 @@ EXPORT_SYMBOL_GPL(ioasid_register_notifier);
void ioasid_unregister_notifier(struct ioasid_set *set,
struct notifier_block *nb)
{
+ struct ioasid_set_nb *curr;
+
+ spin_lock(_nb_lock);
+ /*
+* Pending list is registered with a token without an ioasid_set,
+* therefore should not be unregistered directly.
+*/
+ list_for_each_entry(curr, _nb_pending_list, list) {
+ if (curr->nb == nb) {
+ pr_warn("Cannot unregister NB from pending list\n");
+ spin_unlock(_nb_lock);
+ return;
+ }
+ }
+ spin_unlock(_nb_lock);
+
if (set)
atomic_notifier_chain_unregister(>nh, nb);
else
[PATCH V4 09/18] iommu/ioasid: Introduce notification APIs
Relations among IOASID users largely follow a publisher-subscriber
pattern. E.g. to support guest SVA on Intel Scalable I/O Virtualization
(SIOV) enabled platforms, VFIO, IOMMU, device drivers, KVM are all users
of IOASIDs. When a state change occurs, VFIO publishes the change event
that needs to be processed by other users/subscribers.
This patch introduced two types of notifications: global and per
ioasid_set. The latter is intended for users who only needs to handle
events related to the IOASID of a given set.
For more information, refer to the kernel documentation at
Documentation/ioasid.rst.
Signed-off-by: Liu Yi L
Signed-off-by: Wu Hao
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 111 +++--
include/linux/ioasid.h | 54
2 files changed, 161 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index 7707bb608bdd..56577e745c4b 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -10,12 +10,33 @@
#include
#include
+/*
+ * An IOASID can have multiple consumers where each consumer may have
+ * hardware contexts associated with the IOASID.
+ * When a status change occurs, like on IOASID deallocation, notifier chains
+ * are used to keep the consumers in sync.
+ * This is a publisher-subscriber pattern where publisher can change the
+ * state of each IOASID, e.g. alloc/free, bind IOASID to a device and mm.
+ * On the other hand, subscribers get notified for the state change and
+ * keep local states in sync.
+ */
+static ATOMIC_NOTIFIER_HEAD(ioasid_notifier);
+static DEFINE_SPINLOCK(ioasid_nb_lock);
+
/* Default to PCIe standard 20 bit PASID */
#define PCI_PASID_MAX 0x10
static ioasid_t ioasid_capacity = PCI_PASID_MAX;
static ioasid_t ioasid_capacity_avail = PCI_PASID_MAX;
static DEFINE_XARRAY_ALLOC(ioasid_sets);
+struct ioasid_set_nb {
+ struct list_headlist;
+ struct notifier_block *nb;
+ void*token;
+ struct ioasid_set *set;
+ boolactive;
+};
+
enum ioasid_state {
IOASID_STATE_IDLE,
IOASID_STATE_ACTIVE,
@@ -415,6 +436,38 @@ void ioasid_detach_data(ioasid_t ioasid)
}
EXPORT_SYMBOL_GPL(ioasid_detach_data);
+/**
+ * ioasid_notify - Send notification on a given IOASID for status change.
+ *
+ * @data: The IOASID data to which the notification will send
+ * @cmd: Notification event sent by IOASID external users, can be
+ * IOASID_BIND or IOASID_UNBIND.
+ *
+ * @flags: Special instructions, e.g. notify within a set or global by
+ * IOASID_NOTIFY_FLAG_SET or IOASID_NOTIFY_FLAG_ALL flags
+ * Caller must hold ioasid_allocator_lock and reference to the IOASID
+ */
+static int ioasid_notify(struct ioasid_data *data,
+enum ioasid_notify_val cmd, unsigned int flags)
+{
+ struct ioasid_nb_args args = { 0 };
+ int ret = 0;
+
+ if (flags & ~(IOASID_NOTIFY_FLAG_ALL | IOASID_NOTIFY_FLAG_SET))
+ return -EINVAL;
+
+ args.id = data->id;
+ args.set = data->set;
+ args.pdata = data->private;
+ args.spid = data->spid;
+ if (flags & IOASID_NOTIFY_FLAG_ALL)
+ ret = atomic_notifier_call_chain(_notifier, cmd, );
+ if (flags & IOASID_NOTIFY_FLAG_SET)
+ ret = atomic_notifier_call_chain(>set->nh, cmd, );
+
+ return ret;
+}
+
static ioasid_t ioasid_find_by_spid_locked(struct ioasid_set *set, ioasid_t
spid, bool get)
{
ioasid_t ioasid = INVALID_IOASID;
@@ -468,7 +521,7 @@ int ioasid_attach_spid(ioasid_t ioasid, ioasid_t spid)
goto done_unlock;
}
data->spid = spid;
-
+ ioasid_notify(data, IOASID_NOTIFY_BIND, IOASID_NOTIFY_FLAG_SET);
done_unlock:
spin_unlock(_allocator_lock);
return ret;
@@ -486,8 +539,8 @@ void ioasid_detach_spid(ioasid_t ioasid)
pr_err("Invalid IOASID entry %d to detach\n", ioasid);
goto done_unlock;
}
+ ioasid_notify(data, IOASID_NOTIFY_UNBIND, IOASID_NOTIFY_FLAG_SET);
data->spid = INVALID_IOASID;
-
done_unlock:
spin_unlock(_allocator_lock);
}
@@ -603,6 +656,8 @@ struct ioasid_set *ioasid_set_alloc(void *token, ioasid_t
quota, int type)
set->quota = quota;
set->id = id;
atomic_set(>nr_ioasids, 0);
+ ATOMIC_INIT_NOTIFIER_HEAD(>nh);
+
/*
* Per set XA is used to store private IDs within the set, get ready
* for ioasid_set private ID and system-wide IOASID allocation
@@ -655,7 +710,9 @@ int ioasid_set_free(struct ioasid_set *set)
int ret = 0;
spin_lock(_allocator_lock);
+ spin_lock(_nb_lock);
ret = ioasid_set_free_locked(set);
+ spin_unlock(_nb_lock);
spin_unlock(_allocator_lock);
return ret;
}
@@ -728,6 +785,7 @@ ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min,
[PATCH V4 06/18] iommu/ioasid: Add free function and states
When an actively used IOASID is freed due to exceptions, users must be
notified to perform the cleanup. The IOASID shall be put in a pending
state until all users completed their cleanup work.
This patch adds ioasid_free() function to let the caller initiate the
freeing process. Both ioasid_free() and ioasid_put() decrements
reference counts. Unlike ioasid_put(), the ioasid_free() function also
transition the IOASID to the free pending state where further
ioasid_get() is prohibited. This paves the way for FREE event
notifications that will be introduced next.
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 73 ++
include/linux/ioasid.h | 5 +++
2 files changed, 78 insertions(+)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index d7b476651027..a10f8154c680 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -15,8 +15,26 @@
static ioasid_t ioasid_capacity = PCI_PASID_MAX;
static ioasid_t ioasid_capacity_avail = PCI_PASID_MAX;
static DEFINE_XARRAY_ALLOC(ioasid_sets);
+
+enum ioasid_state {
+ IOASID_STATE_IDLE,
+ IOASID_STATE_ACTIVE,
+ IOASID_STATE_FREE_PENDING,
+};
+
+/**
+ * struct ioasid_data - Meta data about ioasid
+ *
+ * @id:Unique ID
+ * @refs: Number of active users
+ * @state: Track state of the IOASID
+ * @set: ioasid_set of the IOASID belongs to
+ * @private: Private data associated with the IOASID
+ * @rcu: For free after RCU grace period
+ */
struct ioasid_data {
ioasid_t id;
+ enum ioasid_state state;
struct ioasid_set *set;
void *private;
struct rcu_head rcu;
@@ -597,6 +615,7 @@ ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min,
ioasid_t max,
goto exit_free;
}
data->id = id;
+ data->state = IOASID_STATE_IDLE;
/* Store IOASID in the per set data */
if (xa_err(xa_store(>xa, id, data, GFP_ATOMIC))) {
@@ -631,6 +650,56 @@ static void ioasid_do_free_locked(struct ioasid_data *data)
ioasid_set_free_locked(data->set);
}
+static void ioasid_free_locked(struct ioasid_set *set, ioasid_t ioasid)
+{
+ struct ioasid_data *data;
+
+ data = xa_load(_allocator->xa, ioasid);
+ if (!data) {
+ pr_err_ratelimited("Trying to free unknown IOASID %u\n",
ioasid);
+ return;
+ }
+ if (data->set != set) {
+ pr_warn("Cannot free IOASID %u due to set ownership\n", ioasid);
+ return;
+ }
+ /* Check if the set exists */
+ if (WARN_ON(!xa_load(_sets, data->set->id)))
+ return;
+
+ /* Free is already in progress */
+ if (data->state == IOASID_STATE_FREE_PENDING)
+ return;
+
+ data->state = IOASID_STATE_FREE_PENDING;
+ /*
+* If the refcount is 1, it means there is no other users of the IOASID
+* other than IOASID core itself. There is no need to notify anyone.
+*/
+ if (!refcount_dec_and_test(>refs))
+ return;
+
+ ioasid_do_free_locked(data);
+}
+
+/**
+ * ioasid_free - Drop reference on an IOASID. Free if refcount drops to 0,
+ * including free from its set and system-wide list.
+ * @set: The ioasid_set to check permission with. If not NULL, IOASID
+ * free will fail if the set does not match.
+ * @ioasid:The IOASID to remove
+ *
+ * TODO: return true if all references dropped, false if async work is in
+ * progress, IOASID is in FREE_PENDING state. wait queue to be used for
blocking
+ * free task.
+ */
+void ioasid_free(struct ioasid_set *set, ioasid_t ioasid)
+{
+ spin_lock(_allocator_lock);
+ ioasid_free_locked(set, ioasid);
+ spin_unlock(_allocator_lock);
+}
+EXPORT_SYMBOL_GPL(ioasid_free);
int ioasid_get_locked(struct ioasid_set *set, ioasid_t ioasid)
{
struct ioasid_data *data;
@@ -640,6 +709,10 @@ int ioasid_get_locked(struct ioasid_set *set, ioasid_t
ioasid)
pr_err("Trying to get unknown IOASID %u\n", ioasid);
return -EINVAL;
}
+ if (data->state == IOASID_STATE_FREE_PENDING) {
+ pr_err("Trying to get IOASID being freed%u\n", ioasid);
+ return -EBUSY;
+ }
/* Check set ownership if the set is non-null */
if (set && data->set != set) {
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index 095f4e50dc58..cabaf0b0348f 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -72,6 +72,7 @@ int ioasid_get(struct ioasid_set *set, ioasid_t ioasid);
int ioasid_get_locked(struct ioasid_set *set, ioasid_t ioasid);
bool ioasid_put(struct ioasid_set *set, ioasid_t ioasid);
bool ioasid_put_locked(struct ioasid_set *set, ioasid_t ioasid);
+void ioasid_free(struct ioasid_set *set, ioasid_t ioasid);
void *ioasid_find(struct ioasid_set *set, ioasid_t ioasid,
bool
[PATCH V4 08/18] iommu/ioasid: Introduce ioasid_set private ID
When an IOASID set is used for guest SVA, each VM will acquire its
ioasid_set for IOASID allocations. IOASIDs within the VM must have a
host/physical IOASID backing, mapping between guest and host IOASIDs can
be non-identical. IOASID set private ID (SPID) is introduced in this
patch to be used as guest IOASID. However, the concept of ioasid_set
specific namespace is generic, thus named SPID.
As SPID namespace is within the IOASID set, the IOASID core can provide
lookup services at both directions. SPIDs may not be available when its
IOASID is allocated, the mapping between SPID and IOASID is usually
established when a guest page table is bound to a host PASID.
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 104 +
include/linux/ioasid.h | 18 +++
2 files changed, 122 insertions(+)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index 9a3ba157dec3..7707bb608bdd 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -26,6 +26,7 @@ enum ioasid_state {
* struct ioasid_data - Meta data about ioasid
*
* @id:Unique ID
+ * @spid: Private ID unique within a set
* @refs: Number of active users
* @state: Track state of the IOASID
* @set: ioasid_set of the IOASID belongs to
@@ -34,6 +35,7 @@ enum ioasid_state {
*/
struct ioasid_data {
ioasid_t id;
+ ioasid_t spid;
enum ioasid_state state;
struct ioasid_set *set;
void *private;
@@ -413,6 +415,107 @@ void ioasid_detach_data(ioasid_t ioasid)
}
EXPORT_SYMBOL_GPL(ioasid_detach_data);
+static ioasid_t ioasid_find_by_spid_locked(struct ioasid_set *set, ioasid_t
spid, bool get)
+{
+ ioasid_t ioasid = INVALID_IOASID;
+ struct ioasid_data *entry;
+ unsigned long index;
+
+ if (!xa_load(_sets, set->id)) {
+ pr_warn("Invalid set\n");
+ goto done;
+ }
+
+ xa_for_each(>xa, index, entry) {
+ if (spid == entry->spid) {
+ if (get)
+ refcount_inc(>refs);
+ ioasid = index;
+ }
+ }
+done:
+ return ioasid;
+}
+
+/**
+ * ioasid_attach_spid - Attach ioasid_set private ID to an IOASID
+ *
+ * @ioasid: the system-wide IOASID to attach
+ * @spid: the ioasid_set private ID of @ioasid
+ *
+ * After attching SPID, future lookup can be done via ioasid_find_by_spid().
+ */
+int ioasid_attach_spid(ioasid_t ioasid, ioasid_t spid)
+{
+ struct ioasid_data *data;
+ int ret = 0;
+
+ if (spid == INVALID_IOASID)
+ return -EINVAL;
+
+ spin_lock(_allocator_lock);
+ data = xa_load(_allocator->xa, ioasid);
+
+ if (!data) {
+ pr_err("No IOASID entry %d to attach SPID %d\n",
+ ioasid, spid);
+ ret = -ENOENT;
+ goto done_unlock;
+ }
+ /* Check if SPID is unique within the set */
+ if (ioasid_find_by_spid_locked(data->set, spid, false) !=
INVALID_IOASID) {
+ ret = -EINVAL;
+ goto done_unlock;
+ }
+ data->spid = spid;
+
+done_unlock:
+ spin_unlock(_allocator_lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(ioasid_attach_spid);
+
+void ioasid_detach_spid(ioasid_t ioasid)
+{
+ struct ioasid_data *data;
+
+ spin_lock(_allocator_lock);
+ data = xa_load(_allocator->xa, ioasid);
+
+ if (!data || data->spid == INVALID_IOASID) {
+ pr_err("Invalid IOASID entry %d to detach\n", ioasid);
+ goto done_unlock;
+ }
+ data->spid = INVALID_IOASID;
+
+done_unlock:
+ spin_unlock(_allocator_lock);
+}
+EXPORT_SYMBOL_GPL(ioasid_detach_spid);
+
+/**
+ * ioasid_find_by_spid - Find the system-wide IOASID by a set private ID and
+ * its set.
+ *
+ * @set: the ioasid_set to search within
+ * @spid: the set private ID
+ * @get: flag indicates whether to take a reference once found
+ *
+ * Given a set private ID and its IOASID set, find the system-wide IOASID. Take
+ * a reference upon finding the matching IOASID if @get is true. Return
+ * INVALID_IOASID if the IOASID is not found in the set or the set is not
valid.
+ */
+ioasid_t ioasid_find_by_spid(struct ioasid_set *set, ioasid_t spid, bool get)
+{
+ ioasid_t ioasid;
+
+ spin_lock(_allocator_lock);
+ ioasid = ioasid_find_by_spid_locked(set, spid, get);
+ spin_unlock(_allocator_lock);
+ return ioasid;
+}
+EXPORT_SYMBOL_GPL(ioasid_find_by_spid);
+
static inline bool ioasid_set_is_valid(struct ioasid_set *set)
{
return xa_load(_sets, set->id) == set;
@@ -616,6 +719,7 @@ ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min,
ioasid_t max,
}
data->id = id;
data->state = IOASID_STATE_IDLE;
+ data->spid = INVALID_IOASID;
/* Store IOASID in the per set data */
if (xa_err(xa_store(>xa, id,
[PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs
ioasid_set was introduced as an arbitrary token that is shared by a
group of IOASIDs. For example, two IOASIDs allocated via the same
ioasid_set pointer belong to the same set.
For guest SVA usages, system-wide IOASID resources need to be
partitioned such that each VM can have its own quota and being managed
separately. ioasid_set is the perfect candidate for meeting such
requirements. This patch redefines and extends ioasid_set with the
following new fields:
- Quota
- Reference count
- Storage of its namespace
- The token is now stored in the ioasid_set with types
Basic ioasid_set level APIs are introduced that wire up these new data.
Existing users of IOASID APIs are converted where a host IOASID set is
allocated for bare-metal usages. Including VT-d driver and
iommu-sva-lib.
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 1 +
drivers/iommu/intel/iommu.c | 27 +-
drivers/iommu/intel/pasid.h | 1 +
drivers/iommu/intel/svm.c | 25 +-
drivers/iommu/ioasid.c| 288 +++---
drivers/iommu/iommu-sva-lib.c | 19 +-
include/linux/ioasid.h| 68 -
7 files changed, 361 insertions(+), 68 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index e13b092e6004..588aa66ed5e4 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -459,6 +459,7 @@ int arm_smmu_master_enable_sva(struct arm_smmu_master
*master)
{
mutex_lock(_lock);
master->sva_enabled = true;
+ iommu_sva_init();
mutex_unlock(_lock);
return 0;
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 6f42ff7d171d..eb9868061545 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -103,6 +103,9 @@
*/
#define INTEL_IOMMU_PGSIZES(~0xFFFUL)
+/* PASIDs used by host SVM */
+struct ioasid_set *host_pasid_set;
+
static inline int agaw_to_level(int agaw)
{
return agaw + 2;
@@ -173,6 +176,7 @@ static struct intel_iommu **g_iommus;
static void __init check_tylersburg_isoch(void);
static int rwbf_quirk;
+static bool scalable_mode_support(void);
/*
* set to 1 to panic kernel if can't successfully enable VT-d
@@ -3114,8 +3118,8 @@ static void intel_vcmd_ioasid_free(ioasid_t ioasid, void
*data)
* Sanity check the ioasid owner is done at upper layer, e.g. VFIO
* We can only free the PASID when all the devices are unbound.
*/
- if (ioasid_find(NULL, ioasid, NULL)) {
- pr_alert("Cannot free active IOASID %d\n", ioasid);
+ if (IS_ERR(ioasid_find(host_pasid_set, ioasid, NULL))) {
+ pr_err("IOASID %d to be freed but not in system set\n", ioasid);
return;
}
vcmd_free_pasid(iommu, ioasid);
@@ -3300,8 +3304,17 @@ static int __init init_dmars(void)
goto free_iommu;
/* PASID is needed for scalable mode irrespective to SVM */
- if (intel_iommu_sm)
+ if (scalable_mode_support()) {
ioasid_install_capacity(intel_pasid_max_id);
+ /* We should not run out of IOASIDs at boot */
+ host_pasid_set = ioasid_set_alloc(NULL, PID_MAX_DEFAULT,
+ IOASID_SET_TYPE_NULL);
+ if (IS_ERR_OR_NULL(host_pasid_set)) {
+ pr_err("Failed to allocate host PASID set %lu\n",
+ PTR_ERR(host_pasid_set));
+ intel_iommu_sm = 0;
+ }
+ }
/*
* for each drhd
@@ -3348,7 +3361,7 @@ static int __init init_dmars(void)
disable_dmar_iommu(iommu);
free_dmar_iommu(iommu);
}
-
+ ioasid_set_free(host_pasid_set);
kfree(g_iommus);
error:
@@ -4573,7 +4586,7 @@ static int aux_domain_add_dev(struct dmar_domain *domain,
u32 pasid;
/* No private data needed for the default pasid */
- pasid = ioasid_alloc(NULL, PASID_MIN,
+ pasid = ioasid_alloc(host_pasid_set, PASID_MIN,
pci_max_pasids(to_pci_dev(dev)) - 1,
NULL);
if (pasid == INVALID_IOASID) {
@@ -4630,7 +4643,7 @@ static int aux_domain_add_dev(struct dmar_domain *domain,
link_failed:
spin_unlock_irqrestore(_domain_lock, flags);
if (list_empty(>subdevices) && domain->default_pasid > 0)
- ioasid_put(domain->default_pasid);
+ ioasid_put(host_pasid_set, domain->default_pasid);
return ret;
}
@@ -4660,7 +4673,7 @@ static void aux_domain_remove_dev(struct dmar_domain
*domain,
spin_unlock_irqrestore(_domain_lock, flags);
if
[PATCH V4 07/18] iommu/ioasid: Add ioasid_set iterator helper functions
Users of an ioasid_set may not keep track of all the IOASIDs allocated
under the set. When collective actions are needed for each IOASIDs, it
is useful to iterate over all the IOASIDs within the set. For example,
when the ioasid_set is freed, the user might perform the same cleanup
operation on each IOASID.
This patch adds an API to iterate all the IOASIDs within the set.
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 84 ++
include/linux/ioasid.h | 20 ++
2 files changed, 104 insertions(+)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index a10f8154c680..9a3ba157dec3 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -700,6 +700,61 @@ void ioasid_free(struct ioasid_set *set, ioasid_t ioasid)
spin_unlock(_allocator_lock);
}
EXPORT_SYMBOL_GPL(ioasid_free);
+
+/**
+ * ioasid_free_all_in_set
+ *
+ * @brief
+ * Free all PASIDs from system-wide IOASID pool, all subscribers gets
+ * notified and do cleanup of their own.
+ * Note that some references of the IOASIDs within the set can still
+ * be held after the free call. This is OK in that the IOASIDs will be
+ * marked inactive, the only operations can be done is ioasid_put.
+ * No need to track IOASID set states since there is no reclaim phase.
+ *
+ * @param
+ * struct ioasid_set where all IOASIDs within the set will be freed.
+ */
+void ioasid_free_all_in_set(struct ioasid_set *set)
+{
+ struct ioasid_data *entry;
+ unsigned long index;
+
+ if (!ioasid_set_is_valid(set))
+ return;
+
+ if (xa_empty(>xa))
+ return;
+
+ if (!atomic_read(>nr_ioasids))
+ return;
+ spin_lock(_allocator_lock);
+ xa_for_each(>xa, index, entry) {
+ ioasid_free_locked(set, index);
+ /* Free from per set private pool */
+ xa_erase(>xa, index);
+ }
+ spin_unlock(_allocator_lock);
+}
+EXPORT_SYMBOL_GPL(ioasid_free_all_in_set);
+
+/**
+ * ioasid_set_for_each_ioasid
+ * @brief
+ * Iterate over all the IOASIDs within the set
+ */
+void ioasid_set_for_each_ioasid(struct ioasid_set *set,
+ void (*fn)(ioasid_t id, void *data),
+ void *data)
+{
+ struct ioasid_data *entry;
+ unsigned long index;
+
+ xa_for_each(>xa, index, entry)
+ fn(index, data);
+}
+EXPORT_SYMBOL_GPL(ioasid_set_for_each_ioasid);
+
int ioasid_get_locked(struct ioasid_set *set, ioasid_t ioasid)
{
struct ioasid_data *data;
@@ -789,6 +844,35 @@ bool ioasid_put(struct ioasid_set *set, ioasid_t ioasid)
}
EXPORT_SYMBOL_GPL(ioasid_put);
+/**
+ * @brief
+ * Find the ioasid_set of an IOASID. As long as the IOASID is valid,
+ * the set must be valid since the refcounting is based on the number of IOASID
+ * in the set.
+ *
+ * @param ioasid
+ * @return struct ioasid_set*
+ */
+struct ioasid_set *ioasid_find_set(ioasid_t ioasid)
+{
+ struct ioasid_allocator_data *idata;
+ struct ioasid_data *ioasid_data;
+ struct ioasid_set *set = NULL;
+
+ rcu_read_lock();
+ idata = rcu_dereference(active_allocator);
+ ioasid_data = xa_load(>xa, ioasid);
+ if (!ioasid_data) {
+ set = ERR_PTR(-ENOENT);
+ goto unlock;
+ }
+ set = ioasid_data->set;
+unlock:
+ rcu_read_unlock();
+ return set;
+}
+EXPORT_SYMBOL_GPL(ioasid_find_set);
+
/**
* ioasid_find - Find IOASID data
* @set: the IOASID set
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index cabaf0b0348f..e7f3e6108724 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -73,12 +73,17 @@ int ioasid_get_locked(struct ioasid_set *set, ioasid_t
ioasid);
bool ioasid_put(struct ioasid_set *set, ioasid_t ioasid);
bool ioasid_put_locked(struct ioasid_set *set, ioasid_t ioasid);
void ioasid_free(struct ioasid_set *set, ioasid_t ioasid);
+void ioasid_free_all_in_set(struct ioasid_set *set);
void *ioasid_find(struct ioasid_set *set, ioasid_t ioasid,
bool (*getter)(void *));
+struct ioasid_set *ioasid_find_set(ioasid_t ioasid);
int ioasid_register_allocator(struct ioasid_allocator_ops *allocator);
void ioasid_unregister_allocator(struct ioasid_allocator_ops *allocator);
int ioasid_attach_data(ioasid_t ioasid, void *data);
void ioasid_detach_data(ioasid_t ioasid);
+void ioasid_set_for_each_ioasid(struct ioasid_set *sdata,
+ void (*fn)(ioasid_t id, void *data),
+ void *data);
#else /* !CONFIG_IOASID */
static inline void ioasid_install_capacity(ioasid_t total)
{
@@ -158,5 +163,20 @@ static inline int ioasid_attach_data(ioasid_t ioasid, void
*data)
static inline void ioasid_detach_data(ioasid_t ioasid)
{
}
+
+static inline void ioasid_free_all_in_set(struct ioasid_set *set)
+{
+}
+
+static inline struct ioasid_set *ioasid_find_set(ioasid_t ioasid)
+{
+
[PATCH V4 02/18] iommu/ioasid: Rename ioasid_set_data()
Rename ioasid_set_data() to ioasid_attach_data() to avoid confusion with
struct ioasid_set. ioasid_set is a group of IOASIDs that share a common
token.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/svm.c | 6 +++---
drivers/iommu/ioasid.c| 6 +++---
include/linux/ioasid.h| 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 18a9f05df407..0053df9edffc 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -371,7 +371,7 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
svm->gpasid = data->gpasid;
svm->flags |= SVM_FLAG_GUEST_PASID;
}
- ioasid_set_data(data->hpasid, svm);
+ ioasid_attach_data(data->hpasid, svm);
INIT_LIST_HEAD_RCU(>devs);
mmput(svm->mm);
}
@@ -425,7 +425,7 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
list_add_rcu(>list, >devs);
out:
if (!IS_ERR_OR_NULL(svm) && list_empty(>devs)) {
- ioasid_set_data(data->hpasid, NULL);
+ ioasid_attach_data(data->hpasid, NULL);
kfree(svm);
}
@@ -468,7 +468,7 @@ int intel_svm_unbind_gpasid(struct device *dev, u32 pasid)
* the unbind, IOMMU driver will get notified
* and perform cleanup.
*/
- ioasid_set_data(pasid, NULL);
+ ioasid_attach_data(pasid, NULL);
kfree(svm);
}
}
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index 50ee27bbd04e..eeadf4586e0a 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -259,14 +259,14 @@ void ioasid_unregister_allocator(struct
ioasid_allocator_ops *ops)
EXPORT_SYMBOL_GPL(ioasid_unregister_allocator);
/**
- * ioasid_set_data - Set private data for an allocated ioasid
+ * ioasid_attach_data - Set private data for an allocated ioasid
* @ioasid: the ID to set data
* @data: the private data
*
* For IOASID that is already allocated, private data can be set
* via this API. Future lookup can be done via ioasid_find.
*/
-int ioasid_set_data(ioasid_t ioasid, void *data)
+int ioasid_attach_data(ioasid_t ioasid, void *data)
{
struct ioasid_data *ioasid_data;
int ret = 0;
@@ -288,7 +288,7 @@ int ioasid_set_data(ioasid_t ioasid, void *data)
return ret;
}
-EXPORT_SYMBOL_GPL(ioasid_set_data);
+EXPORT_SYMBOL_GPL(ioasid_attach_data);
/**
* ioasid_alloc - Allocate an IOASID
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index e9dacd4b9f6b..60ea279802b8 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -40,7 +40,7 @@ void *ioasid_find(struct ioasid_set *set, ioasid_t ioasid,
bool (*getter)(void *));
int ioasid_register_allocator(struct ioasid_allocator_ops *allocator);
void ioasid_unregister_allocator(struct ioasid_allocator_ops *allocator);
-int ioasid_set_data(ioasid_t ioasid, void *data);
+int ioasid_attach_data(ioasid_t ioasid, void *data);
#else /* !CONFIG_IOASID */
static inline ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min,
@@ -73,7 +73,7 @@ static inline void ioasid_unregister_allocator(struct
ioasid_allocator_ops *allo
{
}
-static inline int ioasid_set_data(ioasid_t ioasid, void *data)
+static inline int ioasid_attach_data(ioasid_t ioasid, void *data)
{
return -ENOTSUPP;
}
--
2.25.1
[PATCH V4 01/18] docs: Document IO Address Space ID (IOASID) APIs
IOASID is used to identify address spaces that can be targeted by device DMA. It is a system-wide resource that is essential to its many users. This document is an attempt to help developers from all vendors navigate the APIs. At this time, ARM SMMU and Intel’s Scalable IO Virtualization (SIOV) enabled platforms are the primary users of IOASID. Examples of how SIOV components interact with the IOASID APIs are provided. Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Randy Dunlap Signed-off-by: Liu Yi L Signed-off-by: Wu Hao Signed-off-by: Jacob Pan --- Documentation/driver-api/index.rst | 1 + Documentation/driver-api/ioasid.rst | 510 2 files changed, 511 insertions(+) create mode 100644 Documentation/driver-api/ioasid.rst diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 2456d0a97ed8..baeec308cf2c 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -37,6 +37,7 @@ available subsections can be seen below. pci/index spi i2c + ioasid ipmb ipmi i3c/index diff --git a/Documentation/driver-api/ioasid.rst b/Documentation/driver-api/ioasid.rst new file mode 100644 index ..f3ed5bf43fa6 --- /dev/null +++ b/Documentation/driver-api/ioasid.rst @@ -0,0 +1,510 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. ioasid: + += + IO Address Space ID += + +IOASIDs are used to identify virtual address spaces that DMA requests can +target. It is a generic name for PCIe Process Address ID (PASID) or +SubstreamID defined by ARM's SMMU. + +The primary use cases for IOASIDs are Shared Virtual Address (SVA) and +IO Virtual Address (IOVA) when multiple address spaces per device are +desired. Due to hardware architectural differences the requirements for +IOASID management can vary in terms of namespace, state management, and +virtualization usages. + +The IOASID subsystem consists of three components: + +- IOASID core: provides APIs for allocation, pool management, + notifications and refcounting. +- IOASID user: provides user allocation interface via /dev/ioasid +- IOASID cgroup controller: manage resource distribution. + (Documentation/admin-guide/cgroup-v1/ioasids.rst) + +This document covers the features supported by the IOASID core APIs. +Vendor-specific use cases are also illustrated with Intel's VT-d +based platforms as the first example. The term PASID and IOASID are used +interchangeably throughout this document. + +.. contents:: :local: + +Glossary + +PASID - Process Address Space ID + +IOVA - IO Virtual Address + +IOASID - IO Address Space ID (generic term for PCIe PASID and +SubstreamID in SMMU) + +SVA/SVM - Shared Virtual Addressing/Memory + +gSVA - Guest Shared Virtual Addressing + +gIOVA - Guest IO Virtual Addressing + +ENQCMD - Instruction to submit work to shared workqueues. Refer +to "Intel X86 ISA for efficient workqueue submission" [1] + +DSA - Intel Data Streaming Accelerator [2] + +VDCM - Virtual Device Composition Module [3] + +SIOV - Intel Scalable IO Virtualization + +DWQ - Dedicated Work Queue + +SWQ - Shared Work Queue + +1. https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf + +2. https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator + +3. https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification + + +Key Concepts + + +IOASID Set +-- +An IOASID set is a group of IOASIDs allocated from the system-wide +IOASID pool. Refer to section "IOASID Set Level APIs" for more details. + +IOASID set is particularly useful for guest SVA where each guest could +have its own IOASID set for security and efficiency reasons. + +Guest IOASID +-- +IOASID used by the guest, identifies a guest IOVA space or a guest VA +space per guest process. + +Host IOASID +- +IOASID used by the host either for bare metal SVA or as the backing of a +guest IOASID. + +Bind/Unbind +--- +Refer to the process where mappings among IOASID, page tables, and devices +are established/demolished. This usually involes setting up an entry of +the IOMMU's per device PASID table with a given PGD. + +IOASID Set Private ID (SPID) + +Each IOASID set has a private namespace of SPIDs. An SPID maps to a +single system-wide IOASID. Conversely, each IOASID may be associated +with an alias ID, local to the IOASID set, named SPID. +SPIDs can be used as guest IOASIDs where each guest could do +IOASID allocation from its own pool/set and map them to host physical +IOASIDs. SPIDs are particularly useful for supporting live migration +where decoupling guest and host physical resources are necessary. Guest +to Host PASID mapping can be torn down and re-established. Storing the +mapping inside the kernel also provides lookup
[PATCH V4 00/18] IOASID extensions for guest SVA
I/O Address Space ID (IOASID) core code was introduced in v5.5 as a generic kernel allocator service for both PCIe Process Address Space ID (PASID) and ARM SMMU's Substream ID. IOASIDs are used to associate DMA requests with virtual address spaces, including both host and guest. In addition to providing basic ID allocation, ioasid_set was defined as a token that is shared by a group of IOASIDs. This set token can be used for permission checking, but lack some features to address the following needs by guest Shared Virtual Address (SVA). - Manage IOASIDs by group, group ownership, quota, etc. - State synchronization among IOASID users (e.g. IOMMU driver, KVM, device drivers) - Non-identity guest-host IOASID mapping - Lifecycle management This patchset introduces the following extensions as solutions to the problems above. - Redefine and extend IOASID set such that IOASIDs can be managed by groups/pools. - Add notifications for IOASID state synchronization - Extend reference counting for life cycle alignment among multiple users - Support ioasid_set private IDs, which can be used as guest IOASIDs - Add a new cgroup controller for resource distribution Please refer to Documentation/admin-guide/cgroup-v1/ioasids.rst and Documentation/driver-api/ioasid.rst in the enclosed patches for more details. Based on discussions on LKML[1], a direction change was made in v4 such that the user interfaces for IOASID allocation are extracted from VFIO subsystem. The proposed IOASID subsystem now consists of three components: 1. IOASID core[01-14]: provides APIs for allocation, pool management, notifications, and refcounting. 2. IOASID cgroup controller[RFC 15-17]: manage resource distribution[2]. 3. IOASID user[RFC 18]: provides user allocation interface via /dev/ioasid This patchset only included VT-d driver as users of some of the new APIs. VFIO and KVM patches are coming up to fully utilize the APIs introduced here. [1] https://lore.kernel.org/linux-iommu/1599734733-6431-1-git-send-email-yi.l@intel.com/ [2] Note that ioasid quota management code can be removed once the IOASIDs cgroup is ratified. You can find this series, VFIO, KVM, and IOASID user at: https://github.com/jacobpan/linux.git ioasid_v4 (VFIO and KVM patches will be available at this branch when published.) This work is a result of collaboration with many people: Liu, Yi L Wu Hao Ashok Raj Kevin Tian Thanks, Jacob Changelog: v4 - Introduced IOASIDs cgroup controller - Introduced /dev/ioasid user API for allocation/free - Added IOASID states and free function, aligned refcounting on v5.11 introduced by Jean. - Support iommu-sva-lib (will converge VT-d code afterward) - Added a shared ordered workqueue for notification work that requires thread context. Streamlined notification framework among multiple IOASID users. - Added ioasid_set helper functions for taking per set operations V3: - Use consistent ioasid_set_ prefix for ioasid_set level APIs - Make SPID and private detach/attach APIs symmetric - Use the same ioasid_put semantics as Jean-Phillippe IOASID reference patch - Take away the public ioasid_notify() function, notifications are now emitted by IOASID core as a result of certain IOASID APIs - Partition into finer incremental patches - Miscellaneous cleanup, locking, exception handling fixes based on v2 reviews V2: - Redesigned ioasid_set APIs, removed set ID - Added set private ID (SPID) for guest PASID usage. - Add per ioasid_set notification and priority support. - Back to use spinlocks and atomic notifications. - Added async work in VT-d driver to perform teardown outside atomic context Jacob Pan (17): docs: Document IO Address Space ID (IOASID) APIs iommu/ioasid: Rename ioasid_set_data() iommu/ioasid: Add a separate function for detach data iommu/ioasid: Support setting system-wide capacity iommu/ioasid: Redefine IOASID set and allocation APIs iommu/ioasid: Add free function and states iommu/ioasid: Add ioasid_set iterator helper functions iommu/ioasid: Introduce ioasid_set private ID iommu/ioasid: Introduce notification APIs iommu/ioasid: Support mm token type ioasid_set notifications iommu/ioasid: Add ownership check in guest bind iommu/vt-d: Remove mm reference for guest SVA iommu/ioasid: Add a workqueue for cleanup work iommu/vt-d: Listen to IOASID notifications cgroup: Introduce ioasids controller iommu/ioasid: Consult IOASIDs cgroup for allocation docs: cgroup-v1: Add IOASIDs controller Liu Yi L (1): ioasid: Add /dev/ioasid for userspace Documentation/admin-guide/cgroup-v1/index.rst | 1 + .../admin-guide/cgroup-v1/ioasids.rst | 107 ++ Documentation/driver-api/index.rst| 1 + Documentation/driver-api/ioasid.rst | 510 + Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/ioasid.rst| 49 + drivers/iommu/Kconfig | 5 + drivers/iommu/Makefile
[PATCH V4 04/18] iommu/ioasid: Support setting system-wide capacity
IOASID is a system-wide resource that could vary on different systems.
The default capacity is 20 bits as defined in the PCI-E specifications.
This patch adds a function to allow adjusting system IOASID capacity.
For VT-d this is set during boot as part of the Intel IOMMU
initialization. APIs also added to support runtime capacity reservation,
potentially by cgroups.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/iommu.c | 5 +++
drivers/iommu/ioasid.c | 70 +
include/linux/ioasid.h | 18 ++
3 files changed, 93 insertions(+)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index f665322a0991..6f42ff7d171d 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -3298,6 +3299,10 @@ static int __init init_dmars(void)
if (ret)
goto free_iommu;
+ /* PASID is needed for scalable mode irrespective to SVM */
+ if (intel_iommu_sm)
+ ioasid_install_capacity(intel_pasid_max_id);
+
/*
* for each drhd
* enable fault log
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index 4eb9b3dd1b85..28681b99340b 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -10,6 +10,10 @@
#include
#include
+/* Default to PCIe standard 20 bit PASID */
+#define PCI_PASID_MAX 0x10
+static ioasid_t ioasid_capacity = PCI_PASID_MAX;
+static ioasid_t ioasid_capacity_avail = PCI_PASID_MAX;
struct ioasid_data {
ioasid_t id;
struct ioasid_set *set;
@@ -258,6 +262,72 @@ void ioasid_unregister_allocator(struct
ioasid_allocator_ops *ops)
}
EXPORT_SYMBOL_GPL(ioasid_unregister_allocator);
+void ioasid_install_capacity(ioasid_t total)
+{
+ spin_lock(_allocator_lock);
+ if (ioasid_capacity && ioasid_capacity != PCI_PASID_MAX) {
+ pr_warn("IOASID capacity is already set.\n");
+ goto done_unlock;
+ }
+ ioasid_capacity = ioasid_capacity_avail = total;
+done_unlock:
+ spin_unlock(_allocator_lock);
+}
+EXPORT_SYMBOL_GPL(ioasid_install_capacity);
+
+/**
+ * @brief Reserve capacity from the system pool
+ *
+ * @param nr_ioasid Number of IOASIDs requested to be reserved, 0 means
+ * reserve all remaining IDs.
+ *
+ * @return the remaining capacity on success, or errno
+ */
+int ioasid_reserve_capacity(ioasid_t nr_ioasid)
+{
+ int ret = 0;
+
+ spin_lock(_allocator_lock);
+ if (nr_ioasid > ioasid_capacity_avail) {
+ ret = -ENOSPC;
+ goto done_unlock;
+ }
+ if (!nr_ioasid)
+ nr_ioasid = ioasid_capacity_avail;
+ ioasid_capacity_avail -= nr_ioasid;
+ ret = nr_ioasid;
+done_unlock:
+ spin_unlock(_allocator_lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(ioasid_reserve_capacity);
+
+/**
+ * @brief Return capacity to the system pool
+ * We trust the caller not to return more than it has reserved, we could
+ * also track reservation if needed.
+ *
+ * @param nr_ioasid Number of IOASIDs requested to be returned
+ *
+ * @return the remaining capacity on success, or errno
+ */
+int ioasid_cancel_capacity(ioasid_t nr_ioasid)
+{
+ int ret = 0;
+
+ spin_lock(_allocator_lock);
+ if (nr_ioasid + ioasid_capacity_avail > ioasid_capacity) {
+ ret = -EINVAL;
+ goto done_unlock;
+ }
+ ioasid_capacity_avail += nr_ioasid;
+ ret = ioasid_capacity_avail;
+done_unlock:
+ spin_unlock(_allocator_lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(ioasid_cancel_capacity);
+
/**
* ioasid_attach_data - Set private data for an allocated ioasid
* @ioasid: the ID to set data
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index f6e705f832f0..2780bdc84b94 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -32,6 +32,10 @@ struct ioasid_allocator_ops {
#define DECLARE_IOASID_SET(name) struct ioasid_set name = { 0 }
#if IS_ENABLED(CONFIG_IOASID)
+void ioasid_install_capacity(ioasid_t total);
+int ioasid_reserve_capacity(ioasid_t nr_ioasid);
+int ioasid_cancel_capacity(ioasid_t nr_ioasid);
+
ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min, ioasid_t max,
void *private);
void ioasid_get(ioasid_t ioasid);
@@ -43,6 +47,20 @@ void ioasid_unregister_allocator(struct ioasid_allocator_ops
*allocator);
int ioasid_attach_data(ioasid_t ioasid, void *data);
void ioasid_detach_data(ioasid_t ioasid);
#else /* !CONFIG_IOASID */
+static inline void ioasid_install_capacity(ioasid_t total)
+{
+}
+
+static inline int ioasid_reserve_capacity(ioasid_t nr_ioasid)
+{
+ return -ENOSPC;
+}
+
+static inline int ioasid_cancel_capacity(ioasid_t nr_ioasid)
+{
+ return -EINVAL;
+}
+
static inline ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min,
[PATCH V4 03/18] iommu/ioasid: Add a separate function for detach data
IOASID private data can be cleared by ioasid_attach_data() with a NULL
data pointer. A common use case is for a caller to free the data
afterward. ioasid_attach_data() calls synchronize_rcu() before return
such that free data can be sure without outstanding readers.
However, since synchronize_rcu() may sleep, ioasid_attach_data() cannot
be used under spinlocks.
This patch adds ioasid_detach_data() as a separate API where
synchronize_rcu() is called only in this case. ioasid_attach_data() can
then be used under spinlocks. In addition, this change makes the API
symmetrical.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/svm.c | 4 +--
drivers/iommu/ioasid.c| 54 +++
include/linux/ioasid.h| 5 +++-
3 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 0053df9edffc..68372a7eb8b5 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -425,7 +425,7 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
list_add_rcu(>list, >devs);
out:
if (!IS_ERR_OR_NULL(svm) && list_empty(>devs)) {
- ioasid_attach_data(data->hpasid, NULL);
+ ioasid_detach_data(data->hpasid);
kfree(svm);
}
@@ -468,7 +468,7 @@ int intel_svm_unbind_gpasid(struct device *dev, u32 pasid)
* the unbind, IOMMU driver will get notified
* and perform cleanup.
*/
- ioasid_attach_data(pasid, NULL);
+ ioasid_detach_data(pasid);
kfree(svm);
}
}
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index eeadf4586e0a..4eb9b3dd1b85 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -273,23 +273,57 @@ int ioasid_attach_data(ioasid_t ioasid, void *data)
spin_lock(_allocator_lock);
ioasid_data = xa_load(_allocator->xa, ioasid);
- if (ioasid_data)
- rcu_assign_pointer(ioasid_data->private, data);
- else
+
+ if (!ioasid_data) {
ret = -ENOENT;
- spin_unlock(_allocator_lock);
+ goto done_unlock;
+ }
- /*
-* Wait for readers to stop accessing the old private data, so the
-* caller can free it.
-*/
- if (!ret)
- synchronize_rcu();
+ if (ioasid_data->private) {
+ ret = -EBUSY;
+ goto done_unlock;
+ }
+ rcu_assign_pointer(ioasid_data->private, data);
+
+done_unlock:
+ spin_unlock(_allocator_lock);
return ret;
}
EXPORT_SYMBOL_GPL(ioasid_attach_data);
+/**
+ * ioasid_detach_data - Clear the private data of an ioasid
+ *
+ * @ioasid: the IOASIDD to clear private data
+ */
+void ioasid_detach_data(ioasid_t ioasid)
+{
+ struct ioasid_data *ioasid_data;
+
+ spin_lock(_allocator_lock);
+ ioasid_data = xa_load(_allocator->xa, ioasid);
+
+ if (!ioasid_data) {
+ pr_warn("IOASID %u not found to detach data from\n", ioasid);
+ goto done_unlock;
+ }
+
+ if (ioasid_data->private) {
+ rcu_assign_pointer(ioasid_data->private, NULL);
+ goto done_unlock;
+ }
+
+done_unlock:
+ spin_unlock(_allocator_lock);
+ /*
+* Wait for readers to stop accessing the old private data,
+* so the caller can free it.
+*/
+ synchronize_rcu();
+}
+EXPORT_SYMBOL_GPL(ioasid_detach_data);
+
/**
* ioasid_alloc - Allocate an IOASID
* @set: the IOASID set
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index 60ea279802b8..f6e705f832f0 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -41,7 +41,7 @@ void *ioasid_find(struct ioasid_set *set, ioasid_t ioasid,
int ioasid_register_allocator(struct ioasid_allocator_ops *allocator);
void ioasid_unregister_allocator(struct ioasid_allocator_ops *allocator);
int ioasid_attach_data(ioasid_t ioasid, void *data);
-
+void ioasid_detach_data(ioasid_t ioasid);
#else /* !CONFIG_IOASID */
static inline ioasid_t ioasid_alloc(struct ioasid_set *set, ioasid_t min,
ioasid_t max, void *private)
@@ -78,5 +78,8 @@ static inline int ioasid_attach_data(ioasid_t ioasid, void
*data)
return -ENOTSUPP;
}
+static inline void ioasid_detach_data(ioasid_t ioasid)
+{
+}
#endif /* CONFIG_IOASID */
#endif /* __LINUX_IOASID_H */
--
2.25.1
Re: [PATCH v4 2/3] media: uapi: Add VP9 stateless decoder controls
Hi Nicolas, On Thu, Feb 25, 2021 at 6:08 AM Nicolas Dufresne wrote: > > Le jeudi 10 septembre 2020 à 15:04 +0900, Alexandre Courbot a écrit : > > Hi Ezequiel, sorry for the late review! > > > > On Tue, May 19, 2020 at 2:40 AM Ezequiel Garcia > > wrote: > > > > > > From: Boris Brezillon > > > > > > Add the VP9 stateless decoder controls plus the documentation that goes > > > with it. > > > > > > Signed-off-by: Boris Brezillon > > > Signed-off-by: Ezequiel Garcia > > > --- > > > .../userspace-api/media/v4l/biblio.rst| 10 + > > > .../media/v4l/ext-ctrls-codec.rst | 550 ++ > > > drivers/media/v4l2-core/v4l2-ctrls.c | 239 > > > drivers/media/v4l2-core/v4l2-ioctl.c | 1 + > > > include/media/v4l2-ctrls.h| 1 + > > > include/media/vp9-ctrls.h | 485 +++ > > > 6 files changed, 1286 insertions(+) > > > create mode 100644 include/media/vp9-ctrls.h > > > > > > diff --git a/Documentation/userspace-api/media/v4l/biblio.rst > > > b/Documentation/userspace-api/media/v4l/biblio.rst > > > index 3c9634173e82..e09102e572fd 100644 > > > --- a/Documentation/userspace-api/media/v4l/biblio.rst > > > +++ b/Documentation/userspace-api/media/v4l/biblio.rst > > > @@ -414,3 +414,13 @@ VP8 > > > :title: RFC 6386: "VP8 Data Format and Decoding Guide" > > > > > > :author:J. Bankoski et al. > > > + > > > +.. _vp9: > > > + > > > +VP9 > > > +=== > > > + > > > + > > > +:title: VP9 Bitstream & Decoding Process Specification > > > + > > > +:author:Adrian Grange (Google), Peter de Rivaz (Argon Design), > > > Jonathan > > > Hunt (Argon Design) > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > index d0d506a444b1..5c5f7dd868da 100644 > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > @@ -2668,6 +2668,556 @@ enum > > > v4l2_mpeg_video_h264_hierarchical_coding_type - > > >- ``padding[3]`` > > >- Applications and drivers must set this to zero. > > > > > > +.. _v4l2-mpeg-vp9: > > > + > > > +``V4L2_CID_MPEG_VIDEO_VP9_FRAME_CONTEXT(0..3) (struct)`` > > > +Stores VP9 probabilities attached to a specific frame context. The > > > VP9 > > > +specification allows using a maximum of 4 contexts. Each frame being > > > +decoded refers to one of those context. See section '7.1.2 Refresh > > > +probs semantics' section of :ref:`vp9` for more details about these > > > +contexts. > > > + > > > +This control is bi-directional: > > > + > > > +* all 4 contexts must be initialized by userspace just after the > > > + stream is started and before the first decoding request is > > > submitted. > > > +* the referenced context might be read by the kernel when a decoding > > > + request is submitted, and will be updated after the decoder is done > > > + decoding the frame if the `V4L2_VP9_FRAME_FLAG_REFRESH_FRAME_CTX` > > > flag > > > + is set. > > > +* contexts will be read back by user space before each decoding > > > request > > > + to retrieve the updated probabilities. > > > +* userspace will re-initialize the context to their default values > > > when > > > + a reset context is required. > > > > Just to make sure I understand this part correctly, it means that if > > frame A and B use the same context, and frame A has > > V4L2_VP9_FRAME_FLAG_REFRESH_FRAME_CTX set, then user-space must wait > > for frame A to get dequeued and read back this control from the > > completed request before it can submit frame B? > > We are preparing a new version, we believe it was an API mistake to try and > share the probability update between kernel and userspace. It's actually > worst, > you really need to push/pull in a lock step, regardless of the frame context > id. > > As you may know, the probabilities are used to parse the compressed part of > the > stream (also know as entropy decoding). They are probability of a bitstream > symbol of being 0 or 1. On RK3399, the hardware does not parse the compressed > header. The compressed headers contains the bitstream coded updates to the > probabilities. The probabilities are also updated base on the count of > specific > symbols found in the bitstream during decoding, this is currently done in the > driver (counts are returned, and driver updates the probabilities from that). > > What we found is that the symbols in the compress headers are coded with fixed > probabilities, meaning we don't need the probabilities to parse the compressed > headers. Our proposal will be to keep doing the compressed header parsing in > userspace and only store the update value (as found in inv_map_table) to the > kernel. The driver will be responsible of applying this to the current > probabilities along with doing the
[PATCH 3/4] kbuild: spilt cc-option and friends to scripts/Makefile.compiler
scripts/Kbuild.include is included everywhere, but macros such as cc-option are needed by build targets only. For example, when 'make clean' traverses the tree, it does not need to evaluate $(call cc-option,). Split cc-option, ld-option, etc. to scripts/Makefile.compiler, which is only included from the top Makefile and scripts/Makefile.build. Signed-off-by: Masahiro Yamada --- Makefile | 4 ++ scripts/Kbuild.include| 80 --- scripts/Makefile.build| 1 + scripts/Makefile.compiler | 77 + 4 files changed, 82 insertions(+), 80 deletions(-) create mode 100644 scripts/Makefile.compiler diff --git a/Makefile b/Makefile index 2253e31a6bcf..eec7a94f5c33 100644 --- a/Makefile +++ b/Makefile @@ -582,6 +582,10 @@ KBUILD_AFLAGS += $(CLANG_FLAGS) export CLANG_FLAGS endif +# Include this also for config targets because some architectures need +# cc-cross-prefix to determine CROSS_COMPILE. +include $(srctree)/scripts/Makefile.compiler + ifdef config-build # === # *config targets only - make sure prerequisites are updated, and descend diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index 509e0856d653..82dd1b65b7a8 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -67,86 +67,6 @@ define filechk fi endef -## -# gcc support functions -# See documentation in Documentation/kbuild/makefiles.rst - -# cc-cross-prefix -# Usage: CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- m68k-linux-) -# Return first where a gcc is found in PATH. -# If no gcc found in PATH with listed prefixes return nothing -# -# Note: '2>/dev/null' is here to force Make to invoke a shell. Otherwise, it -# would try to directly execute the shell builtin 'command'. This workaround -# should be kept for a long time since this issue was fixed only after the -# GNU Make 4.2.1 release. -cc-cross-prefix = $(firstword $(foreach c, $(1), \ - $(if $(shell command -v -- $(c)gcc 2>/dev/null), $(c - -# output directory for tests below -TMPOUT = $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_ - -# try-run -# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise) -# Exit code chooses option. "$$TMP" serves as a temporary file and is -# automatically cleaned up. -try-run = $(shell set -e; \ - TMP=$(TMPOUT)/tmp; \ - TMPO=$(TMPOUT)/tmp.o; \ - mkdir -p $(TMPOUT); \ - trap "rm -rf $(TMPOUT)" EXIT; \ - if ($(1)) >/dev/null 2>&1; \ - then echo "$(2)"; \ - else echo "$(3)"; \ - fi) - -# as-option -# Usage: cflags-y += $(call as-option,-Wa$(comma)-isa=foo,) - -as-option = $(call try-run,\ - $(CC) $(KBUILD_CFLAGS) $(1) -c -x assembler /dev/null -o "$$TMP",$(1),$(2)) - -# as-instr -# Usage: cflags-y += $(call as-instr,instr,option1,option2) - -as-instr = $(call try-run,\ - printf "%b\n" "$(1)" | $(CC) $(KBUILD_AFLAGS) -c -x assembler -o "$$TMP" -,$(2),$(3)) - -# __cc-option -# Usage: MY_CFLAGS += $(call __cc-option,$(CC),$(MY_CFLAGS),-march=winchip-c6,-march=i586) -__cc-option = $(call try-run,\ - $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4)) - -# cc-option -# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586) - -cc-option = $(call __cc-option, $(CC),\ - $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS),$(1),$(2)) - -# cc-option-yn -# Usage: flag := $(call cc-option-yn,-march=winchip-c6) -cc-option-yn = $(call try-run,\ - $(CC) -Werror $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o "$$TMP",y,n) - -# cc-disable-warning -# Usage: cflags-y += $(call cc-disable-warning,unused-but-set-variable) -cc-disable-warning = $(call try-run,\ - $(CC) -Werror $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -W$(strip $(1)) -c -x c /dev/null -o "$$TMP",-Wno-$(strip $(1))) - -# cc-ifversion -# Usage: EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1) -cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || echo $(4)) - -# ld-option -# Usage: KBUILD_LDFLAGS += $(call ld-option, -X, -Y) -ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3)) - -# ld-ifversion -# Usage: $(call ld-ifversion, -ge, 22252, y) -ld-ifversion = $(shell [ $(CONFIG_LD_VERSION)0 $(1) $(2)0 ] && echo $(3) || echo $(4)) - -## - ### # Shorthand for $(Q)$(MAKE) -f scripts/Makefile.build obj= # Usage: diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 750d6d5225af..d74d3383666e 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -36,6 +36,7 @@ subdir-ccflags-y := -include include/config/auto.conf include $(srctree)/scripts/Kbuild.include +include $(srctree)/scripts/Makefile.compiler # The filename Kbuild has precedence over Makefile kbuild-dir := $(if
[PATCH 2/4] kbuild: prefix $(srctree)/ to some included Makefiles
VPATH is used in Kbuild to make pattern rules to search for prerequisites in both $(objtree) and $(srctree). Some source files may not be real sources, but generated by tools such as flex, bison, perl. In contrast, I doubt the benefit of --include-dir=$(abs_srctree) because it is always clear which Makefiles are real sources, and which are not. So, my hope is to add $(srctree)/ prefix to all check-in Makefiles, then remove --include-dir=$(abs_srctree) flag in the future. I am touching only some Kbuild core parts for now. Treewide fixes will be needed to achieve this goal. Signed-off-by: Masahiro Yamada --- Makefile | 8 scripts/Makefile.asm-generic | 4 ++-- scripts/Makefile.build | 8 scripts/Makefile.clean | 2 +- scripts/Makefile.dtbinst | 2 +- scripts/Makefile.headersinst | 2 +- scripts/Makefile.modinst | 2 +- scripts/Makefile.modpost | 4 ++-- scripts/Makefile.modsign | 2 +- 9 files changed, 17 insertions(+), 17 deletions(-) diff --git a/Makefile b/Makefile index c84a9311df29..2253e31a6bcf 100644 --- a/Makefile +++ b/Makefile @@ -338,14 +338,14 @@ __build_one_by_one: else # !mixed-build -include scripts/Kbuild.include +include $(srctree)/scripts/Kbuild.include # Read KERNELRELEASE from include/config/kernel.release (if it exists) KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null) KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION) export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION -include scripts/subarch.include +include $(srctree)/scripts/subarch.include # Cross compiling and selecting different set of gcc/bin-utils # --- @@ -590,7 +590,7 @@ ifdef config-build # Read arch specific Makefile to set KBUILD_DEFCONFIG as needed. # KBUILD_DEFCONFIG may point out an alternative default configuration # used for 'make defconfig' -include arch/$(SRCARCH)/Makefile +include $(srctree)/arch/$(SRCARCH)/Makefile export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT config: outputmakefile scripts_basic FORCE @@ -677,7 +677,7 @@ RETPOLINE_VDSO_CFLAGS := $(call cc-option,$(RETPOLINE_VDSO_CFLAGS_GCC),$(call cc export RETPOLINE_CFLAGS export RETPOLINE_VDSO_CFLAGS -include arch/$(SRCARCH)/Makefile +include $(srctree)/arch/$(SRCARCH)/Makefile ifdef need-config ifdef may-sync-config diff --git a/scripts/Makefile.asm-generic b/scripts/Makefile.asm-generic index 82ad63dcd62b..1d501c57f9ef 100644 --- a/scripts/Makefile.asm-generic +++ b/scripts/Makefile.asm-generic @@ -14,10 +14,10 @@ src := $(subst /generated,,$(obj)) # $(generic)/Kbuild lists mandatory-y. Exclude um since it is a special case. ifneq ($(SRCARCH),um) -include $(generic)/Kbuild +include $(srctree)/$(generic)/Kbuild endif -include scripts/Kbuild.include +include $(srctree)/scripts/Kbuild.include redundant := $(filter $(mandatory-y) $(generated-y), $(generic-y)) redundant += $(foreach f, $(generic-y), $(if $(wildcard $(srctree)/$(src)/$(f)),$(f))) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 1b6094a13034..750d6d5225af 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -35,27 +35,27 @@ subdir-ccflags-y := # Read auto.conf if it exists, otherwise ignore -include include/config/auto.conf -include scripts/Kbuild.include +include $(srctree)/scripts/Kbuild.include # The filename Kbuild has precedence over Makefile kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src)) kbuild-file := $(if $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile) include $(kbuild-file) -include scripts/Makefile.lib +include $(srctree)/scripts/Makefile.lib # Do not include hostprogs rules unless needed. # $(sort ...) is used here to remove duplicated words and excessive spaces. hostprogs := $(sort $(hostprogs)) ifneq ($(hostprogs),) -include scripts/Makefile.host +include $(srctree)/scripts/Makefile.host endif # Do not include userprogs rules unless needed. # $(sort ...) is used here to remove duplicated words and excessive spaces. userprogs := $(sort $(userprogs)) ifneq ($(userprogs),) -include scripts/Makefile.userprogs +include $(srctree)/scripts/Makefile.userprogs endif ifndef obj diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean index 22a8172bce1f..fd6175322470 100644 --- a/scripts/Makefile.clean +++ b/scripts/Makefile.clean @@ -8,7 +8,7 @@ src := $(obj) PHONY := __clean __clean: -include scripts/Kbuild.include +include $(srctree)/scripts/Kbuild.include # The filename Kbuild has precedence over Makefile kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src)) diff --git a/scripts/Makefile.dtbinst b/scripts/Makefile.dtbinst index ba01f5ba2517..190d781e84f4 100644 --- a/scripts/Makefile.dtbinst +++ b/scripts/Makefile.dtbinst @@ -14,7 +14,7 @@ PHONY := __dtbs_install
[PATCH 4/4] kbuild: include Makefile.compiler only when compiler is required
Since commit f2f02ebd8f38 ("kbuild: improve cc-option to clean up all
temporary files"), running 'make kernelversion' in a read-only source
tree emits a bunch of warnings:
mkdir: cannot create directory '.tmp_12345': Permission denied
Non-build targets such as kernelversion, clean, help, etc. do not
need to evaluate $(call cc-option,) and friends. Do not include
Makefile.compiler so $(call cc-option,) becomes no-op.
This not only fix the warnings, but also runs non-build targets much
faster.
Basically, all installation targets should also be non-build targets.
Unfortunately, vdso_install requires the compiler because it builds
vdso before installtion. This is a problem that must be fixed by a
separate patch.
Signed-off-by: Masahiro Yamada
---
I am not adding Reported-by for now because a reporter sent me
an email privately.
If he allows me to add Reported-by, I will add it to record
the credit.
(Perhaps, another person might have reported a similar issue
somewhere, but my memory is obsure. I cannot recall it.)
Makefile | 13 +
1 file changed, 13 insertions(+)
diff --git a/Makefile b/Makefile
index eec7a94f5c33..20724711dc71 100644
--- a/Makefile
+++ b/Makefile
@@ -263,6 +263,10 @@ no-dot-config-targets := $(clean-targets) \
$(version_h) headers headers_% archheaders archscripts
\
%asm-generic kernelversion %src-pkg dt_binding_check \
outputmakefile
+# Installation targets should not require compiler. Unfortunately, vdso_install
+# is an exception where build artifacts may be updated. This must be fixed.
+no-compiler-targets := $(no-dot-config-targets) install dtbs_install \
+ headers_install modules_install kernelrelease image_name
no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease \
image_name
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
@@ -270,6 +274,7 @@ single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o
%.s %.symtypes %/
config-build :=
mixed-build:=
need-config:= 1
+need-compiler := 1
may-sync-config:= 1
single-build :=
@@ -279,6 +284,12 @@ ifneq ($(filter $(no-dot-config-targets),
$(MAKECMDGOALS)),)
endif
endif
+ifneq ($(filter $(no-compiler-targets), $(MAKECMDGOALS)),)
+ ifeq ($(filter-out $(no-compiler-targets), $(MAKECMDGOALS)),)
+ need-compiler :=
+ endif
+endif
+
ifneq ($(filter $(no-sync-config-targets), $(MAKECMDGOALS)),)
ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
may-sync-config :=
@@ -584,7 +595,9 @@ endif
# Include this also for config targets because some architectures need
# cc-cross-prefix to determine CROSS_COMPILE.
+ifdef need-compiler
include $(srctree)/scripts/Makefile.compiler
+endif
ifdef config-build
# ===
--
2.27.0
[PATCH 1/4] kbuild: add image_name to no-sync-config-targets
'make image_name' needs include/config/auto.conf to show the correct output because KBUILD_IMAGE depends on CONFIG options, but should not attempt to resync the configuration. Signed-off-by: Masahiro Yamada --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 633d2769b6ec..c84a9311df29 100644 --- a/Makefile +++ b/Makefile @@ -263,7 +263,8 @@ no-dot-config-targets := $(clean-targets) \ $(version_h) headers headers_% archheaders archscripts \ %asm-generic kernelversion %src-pkg dt_binding_check \ outputmakefile -no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease +no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease \ + image_name single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/ config-build := -- 2.27.0
Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability
On 2021-02-28, Masahiro Yamada wrote:
This commit reverts 0bf6276392e9 ("x32: Warn and disable rather than
error if binutils too old").
The help text in arch/x86/Kconfig says enabling the X32 ABI support
needs binutils 2.22 or later. This is met because the minimal binutils
version is 2.23 according to Documentation/process/changes.rst.
I would not say I am not familiar with toolchain configuration, but
I checked the configure.tgt code in binutils. The elf32_x86_64
emulation mode seems to be included when it is configured for the
x86_64-*-linux-* target.
I also tried lld and llvm-objcopy, and succeeded in building x32 VDSO.
I removed the compile-time check in arch/x86/Makefile, in the hope of
elf32_x86_64 being always supported.
With this, CONFIG_X86_X32 and CONFIG_X86_X32_ABI will be equivalent.
Rename the former to the latter.
Hi Masahiro, the cleanup looks nice!
As of LLVM toolchain support, I don't know any user using LLVM binary
utilities or LLD.
The support on binary utitlies should be minimum anyway (EM_X86_64,
ELFCLASS32, ELFDATA2LSB are mostly all the tool needs to know for many
utilities), so
many of they should just work.
For llvm-objcopy, I know two issues related to `$(OBJCOPY) -O elf32-x86-64`
(actually `objcopy -I elf64-x86-64 -O elf32-x86-64`). Such an operation tries
to convert an ELFCLASS64 object file to an ELFCLASS32 object file. It is not
very clear
what GNU objcopy does. llvm-objcopy is dumb and does not do fancy CLASS
conversion.
* {gcc,clang} -gz{,=zlib} produced object files. The Elf{32,64}_Chdr headers
are different.
Seems that GNU objcopy can convert the headers
(https://github.com/ClangBuiltLinux/linux/issues/514).
llvm-objcopy cannot do it.
* Seems that GNU objcopy can convert .note.gnu.property
(https://github.com/ClangBuiltLinux/linux/issues/1141#issuecomment-678798228)
llvm-objcopy cannot do it.
On the linker side, I know TLS relaxations and IBT need special care and I
believe LLD does not handle them correctly. Thankfully the kernel does not use
thread-local storage so this is not an issue. So perhaps for most configurations
it is already working. Since you've tested it, that is good news to me:)
RE: [PATCH 2/2] drivers: misc: add ripple counter driver
> -Original Message-
> From: Rasmus Villemoes
> Sent: Friday, February 26, 2021 9:14 AM
> To: Greg Kroah-Hartman ; Rob Herring
>
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Arnd Bergmann
> ; linux-...@vger.kernel.org; Rasmus Villemoes
>
> Subject: [PATCH 2/2] drivers: misc: add ripple counter driver
>
> The only purpose of this driver is to serve as a consumer of the input
> clock, to prevent it from being disabled by clk_disable_unused().
>
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/misc/Kconfig | 7 +++
> drivers/misc/Makefile | 1 +
> drivers/misc/ripple-ctr.c | 31 +++
> 3 files changed, 39 insertions(+)
> create mode 100644 drivers/misc/ripple-ctr.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index f532c59bb59b..44b0b6ce42df 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -445,6 +445,13 @@ config HISI_HIKEY_USB
> switching between the dual-role USB-C port and the USB-A host ports
> using only one USB controller.
>
> +config RIPPLE_CTR
> + tristate "Trivial ripple counter driver"
> + help
> + This provides a stub driver for a ripple counter, whose
> + only purpose is to request and enable the clock source
> + driving the counter.
> +
> source "drivers/misc/c2port/Kconfig"
> source "drivers/misc/eeprom/Kconfig"
> source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 99b6f15a3c70..d560163068a9 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -56,3 +56,4 @@ obj-$(CONFIG_HABANA_AI) += habanalabs/
> obj-$(CONFIG_UACCE) += uacce/
> obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
> obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o
> +obj-$(CONFIG_RIPPLE_CTR) += ripple-ctr.o
> diff --git a/drivers/misc/ripple-ctr.c b/drivers/misc/ripple-ctr.c
> new file mode 100644
> index ..f086eaf335df
> --- /dev/null
> +++ b/drivers/misc/ripple-ctr.c
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int ripple_ctr_probe(struct platform_device *pdev)
> +{
> + struct clk *clk;
> +
> + clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> + return clk_prepare_enable(clk);
> +}
> +
> +static const struct of_device_id ripple_ctr_ids[] = {
> + { .compatible = "linux,ripple-counter", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ripple_ctr_ids);
> +
> +static struct platform_driver ripple_ctr_driver = {
> + .driver = {
> + .name = "ripple-counter",
> + .of_match_table = ripple_ctr_ids,
> + },
> + .probe = ripple_ctr_probe,
> +};
> +module_platform_driver(ripple_ctr_driver);
Missing MODULE_LICENSE() tag?
See
https://www.kernel.org/doc/html/latest/process/license-rules.html#license-identifiers
> --
> 2.29.2
[PATCH] video: fbdev: sis: catch out of bounds in SiS_DoCalcDelay
idx1 is read from hardware and the range is [0, 30],
the size of ThLowA and ThLowB is 24, so there could possibly an out of
bounds access. This patch catches the OOB access and print a warning.
[4.771691]
==
[4.771693] BUG: KASAN: global-out-of-bounds in SiS_DoCalcDelay+0xa9/0x160
[sisfb]
[4.771718] Read of size 1 at addr c0048b1f by task modprobe/96
[4.771722] CPU: 0 PID: 96 Comm: modprobe Not tainted 5.11.0-rc7 #92
[4.771727] Call Trace:
[4.771729] dump_stack+0x7d/0xa3
[4.771733] print_address_description.constprop.0+0x1a/0x140
[4.771738] ? SiS_DoCalcDelay+0xa9/0x160 [sisfb]
[4.771760] ? SiS_DoCalcDelay+0xa9/0x160 [sisfb]
[4.771782] kasan_report.cold+0x7f/0x10e
[4.771786] ? SiS_DoCalcDelay+0xa9/0x160 [sisfb]
[4.771808] SiS_DoCalcDelay+0xa9/0x160 [sisfb]
[4.771830] ? SiS_GetFIFOThresholdIndex300+0xb0/0xb0 [sisfb]
[4.771853] ? sisfb_probe.cold+0x3a0f/0x4f7d [sisfb]
[4.771876] ? SiS_GetRefCRTVCLK+0x6c/0x80 [sisfb]
[4.771900] ? SiS_GetVCLK2Ptr+0x28b/0x800 [sisfb]
[4.771923] SiSSetMode+0x26de/0x4770 [sisfb]
[4.771946] ? SiS_LoadDAC+0x3e0/0x3e0 [sisfb]
[4.771968] ? ___slab_alloc+0x412/0x5d0
[4.771971] ? set_inverse_trans_unicode.isra.0+0x147/0x170
[4.771975] ? sisfb_syncaccel+0x12f/0x140 [sisfb]
[4.771998] sisfb_set_mode.isra.0+0x264/0x12b0 [sisfb]
[4.772020] ? kasan_module_alloc+0x5f/0xc0
[4.772023] sisfb_set_par+0x3b3/0x930 [sisfb]
[4.772046] fbcon_init+0x447/0x980
[4.772049] ? sisfb_probe+0x1490/0x1490 [sisfb]
[4.772071] visual_init+0x182/0x240
[4.772074] do_bind_con_driver+0x2db/0x460
[4.772078] do_take_over_console+0x205/0x280
[4.772082] do_fbcon_takeover+0x80/0x100
[4.772085] register_framebuffer+0x301/0x4c0
[4.772088] ? do_remove_conflicting_framebuffers+0xf0/0xf0
[4.772092] ? fb_copy_cmap+0x10b/0x160
[4.772096] sisfb_probe.cold+0x2fca/0x4f7d [sisfb]
[4.772120] ? rpm_resume+0x1cd/0xac0
[4.772124] ? sisfb_check_var+0x990/0x990 [sisfb]
[4.772146] ? pm_runtime_get_if_active+0x190/0x190
[4.772150] ? _raw_spin_lock_irqsave+0x7b/0xd0
[4.772154] ? _raw_spin_lock_irqsave+0x7b/0xd0
[4.772157] ? __mutex_lock_slowpath+0x10/0x10
[4.772161] ? sisfb_check_var+0x990/0x990 [sisfb]
[4.772183] local_pci_probe+0x6f/0xb0
[4.772349] The buggy address belongs to the variable:
[4.772350] ThLowA.47581+0x1f/0x9500 [sisfb]
[4.772373]
[4.772373] Memory state around the buggy address:
[4.772375] c0048a00: 00 00 00 00 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9
f9
[4.772377] c0048a80: 00 00 05 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9
f9
[4.772379] >c0048b00: 00 00 00 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9
f9
[4.772380] ^
[4.772382] c0048b80: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 07 f9
f9
[4.772384] c0048c00: f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9 00 f9 f9
f9
[4.772385]
==
Signed-off-by: Tong Zhang
---
drivers/video/fbdev/sis/init.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
index b568c646a76c..fb9815e7af4b 100644
--- a/drivers/video/fbdev/sis/init.c
+++ b/drivers/video/fbdev/sis/init.c
@@ -2249,6 +2249,10 @@ SiS_GetFIFOThresholdA300(unsigned short idx1, unsigned
short idx2)
34, 3,37, 5,47, 7, 67,11
};
+ if (idx1>22) {
+ printk(KERN_WARNING "idx1 out of bounds: %d\n", idx1);
+ idx1 = 22;
+ }
return (unsigned short)((ThLowA[idx1 + 1] * idx2) + ThLowA[idx1]);
}
@@ -2261,6 +2265,10 @@ SiS_GetFIFOThresholdB300(unsigned short idx1, unsigned
short idx2)
42, 4,45, 6,55, 8, 75,12
};
+ if (idx1>22) {
+ printk(KERN_WARNING "idx1 out of bounds: %d\n", idx1);
+ idx1 = 22;
+ }
return (unsigned short)((ThLowB[idx1 + 1] * idx2) + ThLowB[idx1]);
}
--
2.25.1
Re: [PATCH v4] f2fs: compress: add compress_inode to cache compressed blockst
On 02/04, Chao Yu wrote:
> Jaegeuk,
>
> On 2021/2/2 16:00, Chao Yu wrote:
> > - for (i = 0; i < dic->nr_cpages; i++) {
> > + for (i = 0; i < cc->nr_cpages; i++) {
> > struct page *page = dic->cpages[i];
>
> por_fsstress still hang in this line?
I'm stuck on testing the patches, since the latest kernel is panicking somehow.
Let me update later, once I can test a bit. :(
>
> Thanks,
>
> > block_t blkaddr;
> > struct bio_post_read_ctx *ctx;
> > @@ -2201,6 +2207,14 @@ int f2fs_read_multi_pages(struct compress_ctx *cc,
> > struct bio **bio_ret,
> > blkaddr = data_blkaddr(dn.inode, dn.node_page,
> > dn.ofs_in_node + i + 1);
> > + f2fs_wait_on_block_writeback(inode, blkaddr);
> > +
> > + if (f2fs_load_compressed_page(sbi, page, blkaddr)) {
> > + if (atomic_dec_and_test(>remaining_pages))
> > + f2fs_decompress_cluster(dic);
> > + continue;
> > + }
> > +
Re: [PATCH RFC] f2fs: fix to avoid selecting full segment w/ {AT,}SSR allocator
On 02/23, Chao Yu wrote:
> Jaegeuk,
>
> Could you please help to review this patch? since I doubt that this
> issue can happen in real world... :(
Let me take a look as soon as I have some time. Sorry for the delay.
>
> Thanks,
>
> On 2021/2/22 21:43, Chao Yu wrote:
> > Ping,
> >
> > On 2021/2/20 17:40, Chao Yu wrote:
> > > In cp disabling mode, there could be a condition
> > > - target segment has 128 ckpt valid blocks
> > > - GC migrates 128 valid blocks to other segment (segment is still in
> > > dirty list)
> > > - GC migrates 384 blocks to target segment (segment has 128 cp_vblocks
> > > and 384 vblocks)
> > > - If GC selects target segment via {AT,}SSR allocator, however there is
> > > no free space in targe segment.
> > >
> > > Fixes: 4354994f097d ("f2fs: checkpoint disabling")
> > > Fixes: 093749e296e2 ("f2fs: support age threshold based garbage
> > > collection")
> > > Signed-off-by: Chao Yu
> > > ---
> > >fs/f2fs/f2fs.h| 1 +
> > >fs/f2fs/gc.c | 17 +
> > >fs/f2fs/segment.c | 20
> > >3 files changed, 34 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > index ed7807103c8e..9c753eff0814 100644
> > > --- a/fs/f2fs/f2fs.h
> > > +++ b/fs/f2fs/f2fs.h
> > > @@ -3376,6 +3376,7 @@ block_t f2fs_get_unusable_blocks(struct
> > > f2fs_sb_info *sbi);
> > >int f2fs_disable_cp_again(struct f2fs_sb_info *sbi, block_t unusable);
> > >void f2fs_release_discard_addrs(struct f2fs_sb_info *sbi);
> > >int f2fs_npages_for_summary_flush(struct f2fs_sb_info *sbi, bool
> > > for_ra);
> > > +bool segment_has_free_slot(struct f2fs_sb_info *sbi, int segno);
> > >void f2fs_init_inmem_curseg(struct f2fs_sb_info *sbi);
> > >void f2fs_save_inmem_curseg(struct f2fs_sb_info *sbi);
> > >void f2fs_restore_inmem_curseg(struct f2fs_sb_info *sbi);
> > > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> > > index 86ba8ed0b8a7..a1d8062cdace 100644
> > > --- a/fs/f2fs/gc.c
> > > +++ b/fs/f2fs/gc.c
> > > @@ -392,10 +392,6 @@ static void add_victim_entry(struct f2fs_sb_info
> > > *sbi,
> > > if (p->gc_mode == GC_AT &&
> > > get_valid_blocks(sbi, segno, true) == 0)
> > > return;
> > > -
> > > - if (p->alloc_mode == AT_SSR &&
> > > - get_seg_entry(sbi, segno)->ckpt_valid_blocks == 0)
> > > - return;
> > > }
> > > for (i = 0; i < sbi->segs_per_sec; i++)
> > > @@ -736,6 +732,19 @@ static int get_victim_by_default(struct f2fs_sb_info
> > > *sbi,
> > > if (gc_type == BG_GC && test_bit(secno,
> > > dirty_i->victim_secmap))
> > > goto next;
> > > + if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) {
> > > + /*
> > > + * to avoid selecting candidate which has below valid
> > > + * block distribution:
> > > + * partial blocks are valid and all left ones are valid
> > > + * in previous checkpoint.
> > > + */
> > > + if (p.alloc_mode == SSR || p.alloc_mode == AT_SSR) {
> > > + if (!segment_has_free_slot(sbi, segno))
> > > + goto next;
> > > + }
> > > + }
> > > +
> > > if (is_atgc) {
> > > add_victim_entry(sbi, , segno);
> > > goto next;
> > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > > index 2d5a82c4ca15..deaf57e13125 100644
> > > --- a/fs/f2fs/segment.c
> > > +++ b/fs/f2fs/segment.c
> > > @@ -2650,6 +2650,26 @@ static void __refresh_next_blkoff(struct
> > > f2fs_sb_info *sbi,
> > > seg->next_blkoff++;
> > >}
> > > +bool segment_has_free_slot(struct f2fs_sb_info *sbi, int segno)
> > > +{
> > > + struct sit_info *sit = SIT_I(sbi);
> > > + struct seg_entry *se = get_seg_entry(sbi, segno);
> > > + int entries = SIT_VBLOCK_MAP_SIZE / sizeof(unsigned long);
> > > + unsigned long *target_map = SIT_I(sbi)->tmp_map;
> > > + unsigned long *ckpt_map = (unsigned long *)se->ckpt_valid_map;
> > > + unsigned long *cur_map = (unsigned long *)se->cur_valid_map;
> > > + int i, pos;
> > > +
> > > + down_write(>sentry_lock);
> > > + for (i = 0; i < entries; i++)
> > > + target_map[i] = ckpt_map[i] | cur_map[i];
> > > +
> > > + pos = __find_rev_next_zero_bit(target_map, sbi->blocks_per_seg, 0);
> > > + up_write(>sentry_lock);
> > > +
> > > + return pos < sbi->blocks_per_seg;
> > > +}
> > > +
> > >/*
> > > * This function always allocates a used segment(from dirty seglist)
> > > by SSR
> > > * manner, so it should recover the existing segment information of
> > > valid blocks
> > >
> > .
> >
Re: hppa64-linux-ld: kernel/rcu/refscale.o(.init.text+0x228): cannot reach schedule_timeout_uninterruptible
On Sun, Feb 28, 2021 at 12:08:08PM +0800, kernel test robot wrote: > Hi Paul, > > First bad commit (maybe != root cause): > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 > commit: 1fbeb3a8c4de29433a8d230ee600b13d369b6c0f refperf: Rename refperf.c to > refscale.c and change internal names > date: 8 months ago > config: parisc-randconfig-s031-20210228 (attached as .config) > compiler: hppa64-linux-gcc (GCC) 9.3.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # apt-get install sparse > # sparse version: v0.6.3-241-geaceeafa-dirty > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1fbeb3a8c4de29433a8d230ee600b13d369b6c0f > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 1fbeb3a8c4de29433a8d230ee600b13d369b6c0f > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 > CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): I must confess that I have no idea what I can do about these errors. Did the kernel maybe grow larger than can be handled by the PA-RISC toolchain? Thanx, Paul >hppa64-linux-ld: init/main.o(.init.text+0xdd8): cannot reach rest_init >init/main.o: in function `arch_call_rest_init': >(.init.text+0xdd8): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `rest_init' defined in .ref.text section in init/main.o >hppa64-linux-ld: init/main.o(.init.text+0x13d8): cannot reach > build_all_zonelists >init/main.o: in function `start_kernel': >(.init.text+0x13d8): relocation truncated to fit: R_PARISC_PCREL22F > against symbol `build_all_zonelists' defined in .ref.text section in > mm/page_alloc.o >hppa64-linux-ld: init/main.o(.init.text+0x176c): cannot reach profile_init >(.init.text+0x176c): relocation truncated to fit: R_PARISC_PCREL22F > against symbol `profile_init' defined in .ref.text section in kernel/profile.o >hppa64-linux-ld: init/main.o(.init.text+0x1ac0): cannot reach > wait_for_completion >init/main.o: in function `kernel_init_freeable': >(.init.text+0x1ac0): relocation truncated to fit: R_PARISC_PCREL22F > against symbol `wait_for_completion' defined in .sched.text section in > kernel/sched/completion.o >hppa64-linux-ld: init/main.o(.ref.text+0x1c): cannot reach > rcu_scheduler_starting >init/main.o: in function `rest_init': >(.ref.text+0x1c): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `rcu_scheduler_starting' defined in .init.text section in > kernel/rcu/srcutiny.o >hppa64-linux-ld: init/main.o(.ref.text+0x17c): cannot reach unknown >init/main.o: in function `kernel_init': >(.ref.text+0x17c): relocation truncated to fit: R_PARISC_PCREL22F against > `kernel_init_freeable' >hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0x78): cannot reach > unknown >arch/parisc/mm/init.o: in function `free_initmem': >(.ref.text+0x78): relocation truncated to fit: R_PARISC_PCREL22F against > `map_pages' >hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xa0): cannot reach > unknown >(.ref.text+0xa0): relocation truncated to fit: R_PARISC_PCREL22F against > `map_pages' >hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xc4): cannot reach > unknown >(.ref.text+0xc4): relocation truncated to fit: R_PARISC_PCREL22F against > `map_pages' >hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x768): cannot reach > _raw_spin_lock >kernel/printk/printk.o: in function `setup_log_buf': >(.init.text+0x768): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `_raw_spin_lock' defined in .spinlock.text section in > kernel/locking/spinlock.o >hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x7c4): cannot reach > _raw_spin_unlock >(.init.text+0x7c4): additional relocation overflows omitted from the output >hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x228): cannot reach > mutex_lock >hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x440): cannot reach > mutex_unlock >hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x7a0): cannot reach > mutex_lock >hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x878): cannot reach > mutex_unlock >hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0xad4): cannot reach > mutex_lock >hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0xafc): cannot reach > mutex_unlock >hppa64-linux-ld:
Re: [f2fs-dev] [PATCH][next] f2fs: Replace one-element array with flexible-array member
On 02/25, Chao Yu wrote:
> Hello, Gustavo,
>
> On 2021/2/25 3:03, Gustavo A. R. Silva wrote:
> > There is a regular need in the kernel to provide a way to declare having
> > a dynamically sized set of trailing elements in a structure. Kernel code
> > should always use “flexible array members”[1] for these cases. The older
> > style of one-element or zero-length arrays should no longer be used[2].
>
> I proposal to do the similar cleanup, and I've no objection on doing this.
>
> https://lore.kernel.org/patchwork/patch/869440/
>
> Let's ask for Jaegeuk' opinion.
Merged, thanks.
This looks better reason than code readability. :)
>
> >
> > Refactor the code according to the use of a flexible-array member in
> > struct f2fs_checkpoint, instead of a one-element arrays.
> >
> > Notice that a temporary pointer to void '*tmp_ptr' was used in order to
> > fix the following errors when using a flexible array instead of a one
> > element array in struct f2fs_checkpoint:
> >
> >CC [M] fs/f2fs/dir.o
> > In file included from fs/f2fs/dir.c:13:
> > fs/f2fs/f2fs.h: In function ‘__bitmap_ptr’:
> > fs/f2fs/f2fs.h:2227:40: error: invalid use of flexible array member
> > 2227 | return >sit_nat_version_bitmap + offset + sizeof(__le32);
> >|^
> > fs/f2fs/f2fs.h:2227:49: error: invalid use of flexible array member
> > 2227 | return >sit_nat_version_bitmap + offset + sizeof(__le32);
> >| ^
> > fs/f2fs/f2fs.h:2238:40: error: invalid use of flexible array member
> > 2238 | return >sit_nat_version_bitmap + offset;
> >|^
> > make[2]: *** [scripts/Makefile.build:287: fs/f2fs/dir.o] Error 1
> > make[1]: *** [scripts/Makefile.build:530: fs/f2fs] Error 2
> > make: *** [Makefile:1819: fs] Error 2
> >
> > [1] https://en.wikipedia.org/wiki/Flexible_array_member
> > [2]
> > https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays
> >
> > Link: https://github.com/KSPP/linux/issues/79
> > Build-tested-by: kernel test robot
> > Link:
> > https://lore.kernel.org/lkml/603647e4.deefbl4eqljuwaue%25...@intel.com/
> > Signed-off-by: Gustavo A. R. Silva
> > ---
> > fs/f2fs/f2fs.h | 5 +++--
> > include/linux/f2fs_fs.h | 2 +-
> > 2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index e2d302ae3a46..3f5cb097c30f 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -2215,6 +2215,7 @@ static inline block_t __cp_payload(struct
> > f2fs_sb_info *sbi)
> > static inline void *__bitmap_ptr(struct f2fs_sb_info *sbi, int flag)
> > {
> > struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
> > + void *tmp_ptr = >sit_nat_version_bitmap;
> > int offset;
> > if (is_set_ckpt_flags(sbi, CP_LARGE_NAT_BITMAP_FLAG)) {
> > @@ -2224,7 +2225,7 @@ static inline void *__bitmap_ptr(struct f2fs_sb_info
> > *sbi, int flag)
> > * if large_nat_bitmap feature is enabled, leave checksum
> > * protection for all nat/sit bitmaps.
> > */
> > - return >sit_nat_version_bitmap + offset + sizeof(__le32);
> > + return tmp_ptr + offset + sizeof(__le32);
> > }
> > if (__cp_payload(sbi) > 0) {
> > @@ -2235,7 +2236,7 @@ static inline void *__bitmap_ptr(struct f2fs_sb_info
> > *sbi, int flag)
> > } else {
> > offset = (flag == NAT_BITMAP) ?
> > le32_to_cpu(ckpt->sit_ver_bitmap_bytesize) : 0;
> > - return >sit_nat_version_bitmap + offset;
> > + return tmp_ptr + offset;
> > }
> > }
> > diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
> > index c6cc0a566ef5..5487a80617a3 100644
> > --- a/include/linux/f2fs_fs.h
> > +++ b/include/linux/f2fs_fs.h
> > @@ -168,7 +168,7 @@ struct f2fs_checkpoint {
> > unsigned char alloc_type[MAX_ACTIVE_LOGS];
> > /* SIT and NAT version bitmap */
> > - unsigned char sit_nat_version_bitmap[1];
> > + unsigned char sit_nat_version_bitmap[];
> > } __packed;
> > #define CP_CHKSUM_OFFSET 4092/* default chksum offset in checkpoint
> > */
> >
[PATCH] drm/fb-helper: only unmap if buffer not null
drm_fbdev_cleanup() can be called when fb_helper->buffer is null, hence fb_helper->buffer should be checked before calling drm_client_buffer_vunmap(). This buffer is also checked in drm_client_framebuffer_delete(), so we should also do the same thing for drm_client_buffer_vunmap(). [ 199.128742] RIP: 0010:drm_client_buffer_vunmap+0xd/0x20 [ 199.129031] Code: 43 18 48 8b 53 20 49 89 45 00 49 89 55 08 5b 44 89 e0 41 5c 41 5d 41 5e 5d c3 0f 1f 00 53 48 89 fb 48 8d 7f 10 e8 73 7d a1 ff <48> 8b 7b 10 48 8d 73 18 5b e9 75 53 fc ff 0 f 1f 44 00 00 48 b8 00 [ 199.130041] RSP: 0018:888103f3fc88 EFLAGS: 00010282 [ 199.130329] RAX: 0001 RBX: RCX: 8214d46d [ 199.130733] RDX: 1079c6b9 RSI: 0246 RDI: 83ce35c8 [ 199.131119] RBP: 888103d25458 R08: 0001 R09: fbfff0791761 [ 199.131505] R10: 83c8bb07 R11: fbfff0791760 R12: [ 199.131891] R13: 888103d25468 R14: 888103d25418 R15: 888103f18120 [ 199.132277] FS: 7f36fdcbb6a0() GS:88815b40() knlGS: [ 199.132721] CS: 0010 DS: ES: CR0: 80050033 [ 199.133033] CR2: 0010 CR3: 000103d26000 CR4: 06f0 [ 199.133420] DR0: DR1: DR2: [ 199.133807] DR3: DR6: fffe0ff0 DR7: 0400 [ 199.134195] Call Trace: [ 199.134333] drm_fbdev_cleanup+0x179/0x1a0 [ 199.134562] drm_fbdev_client_unregister+0x2b/0x40 [ 199.134828] drm_client_dev_unregister+0xa8/0x180 [ 199.135088] drm_dev_unregister+0x61/0x110 [ 199.135315] mgag200_pci_remove+0x38/0x52 [mgag200] [ 199.135586] pci_device_remove+0x62/0xe0 [ 199.135806] device_release_driver_internal+0x148/0x270 [ 199.136094] driver_detach+0x76/0xe0 [ 199.136294] bus_remove_driver+0x7e/0x100 [ 199.136521] pci_unregister_driver+0x28/0xf0 [ 199.136759] __x64_sys_delete_module+0x268/0x300 [ 199.137016] ? __ia32_sys_delete_module+0x300/0x300 [ 199.137285] ? call_rcu+0x3e4/0x580 [ 199.137481] ? fpregs_assert_state_consistent+0x4d/0x60 [ 199.137767] ? exit_to_user_mode_prepare+0x2f/0x130 [ 199.138037] do_syscall_64+0x33/0x40 [ 199.138237] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 199.138517] RIP: 0033:0x7f36fdc3dcf7 Signed-off-by: Tong Zhang --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index b9a616737c0e..f6baa2046124 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -2048,7 +2048,7 @@ static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper) if (shadow) vfree(shadow); - else + else if (fb_helper->buffer) drm_client_buffer_vunmap(fb_helper->buffer); drm_client_framebuffer_delete(fb_helper->buffer); -- 2.25.1
Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end
On 12/17/2020 12:12 PM, Roman Gushchin wrote: > With kaslr the kernel image is placed at a random place, so starting > the bottom-up allocation with the kernel_end can result in an > allocation failure and a warning like this one: > > [0.002920] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node > [0.002921] [ cut here ] > [0.002922] memblock: bottom-up allocation failed, memory hotremove may be > affected > [0.002937] WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 > memblock_find_in_range_node+0x178/0x25a > [0.002937] Modules linked in: > [0.002939] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #1169 > [0.002940] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.14.0-1.fc33 04/01/2014 > [0.002942] RIP: 0010:memblock_find_in_range_node+0x178/0x25a > [0.002944] Code: e9 6d ff ff ff 48 85 c0 0f 85 da 00 00 00 80 3d 9b 35 df > 00 00 75 15 48 c7 c7 c0 75 59 88 c6 05 8b 35 df 00 01 e8 25 8a fa ff <0f> 0b > 48 c7 44 24 20 ff ff ff ff 44 89 e6 44 89 ea 48 c7 c1 70 5c > [0.002945] RSP: :88803d18 EFLAGS: 00010086 ORIG_RAX: > > [0.002947] RAX: RBX: 00024000 RCX: > dfff > [0.002948] RDX: dfff RSI: ffea RDI: > 0046 > [0.002948] RBP: 0001 R08: 88922788 R09: > 9ffb > [0.002949] R10: e000 R11: 3fff R12: > > [0.002950] R13: R14: 8000 R15: > 0001fb42c000 > [0.002952] FS: () GS:88f71000() > knlGS: > [0.002953] CS: 0010 DS: ES: CR0: 80050033 > [0.002954] CR2: a080fb401000 CR3: 0001fa80a000 CR4: > 000406b0 > [0.002956] Call Trace: > [0.002961] ? memblock_alloc_range_nid+0x8d/0x11e > [0.002963] ? cma_declare_contiguous_nid+0x2c4/0x38c > [0.002964] ? hugetlb_cma_reserve+0xdc/0x128 > [0.002968] ? flush_tlb_one_kernel+0xc/0x20 > [0.002969] ? native_set_fixmap+0x82/0xd0 > [0.002971] ? flat_get_apic_id+0x5/0x10 > [0.002973] ? register_lapic_address+0x8e/0x97 > [0.002975] ? setup_arch+0x8a5/0xc3f > [0.002978] ? start_kernel+0x66/0x547 > [0.002980] ? load_ucode_bsp+0x4c/0xcd > [0.002982] ? secondary_startup_64_no_verify+0xb0/0xbb > [0.002986] random: get_random_bytes called from __warn+0xab/0x110 with > crng_init=0 > [0.002988] ---[ end trace f151227d0b39be70 ]--- > > At the same time, the kernel image is protected with memblock_reserve(), > so we can just start searching at PAGE_SIZE. In this case the > bottom-up allocation has the same chances to success as a top-down > allocation, so there is no reason to fallback in the case of a > failure. All together it simplifies the logic. > > Signed-off-by: Roman Gushchin Hi Roman, Thomas and other linux-mips folks, Kamal and myself have been unable to boot v5.11 on MIPS since this commit, reverting it makes our MIPS platforms boot successfully. We do not see a warning like this one in the commit message, instead what happens appear to be a corrupted Device Tree which prevents the parsing of the "rdb" node and leading to the interrupt controllers not being registered, and the system eventually not booting. The Device Tree is built-into the kernel image and resides at arch/mips/boot/dts/brcm/bcm97435svmb.dts. Do you have any idea what could be wrong with MIPS specifically here? Thanks! -- Florian
Re: [PATCH 5/5] HID: apple-touchbar - Add driver for the Touch Bar on MacBook Pro's.
Hi "Ronald, Thank you for the patch! Yet something to improve: [auto build test ERROR on hid/for-next] [also build test ERROR on iio/togreg jikos-trivial/for-next v5.11 next-20210226] [cannot apply to jikos-hid/for-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Ronald-Tschal-r/Touch-Bar-and-ALS-support-for-MacBook-Pro-s/20210228-093451 base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next config: x86_64-randconfig-r015-20210228 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project e0b1df924ae06d6d88582334087d2eacc6702e8f) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://github.com/0day-ci/linux/commit/cfbb470c2977fd10aef2791b57bdfa2d95f627e0 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Ronald-Tschal-r/Touch-Bar-and-ALS-support-for-MacBook-Pro-s/20210228-093451 git checkout cfbb470c2977fd10aef2791b57bdfa2d95f627e0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> ld.lld: error: undefined symbol: usb_get_intf >>> referenced by apple-touchbar.c:1088 (drivers/hid/apple-touchbar.c:1088) >>> hid/apple-touchbar.o:(appletb_probe) in archive drivers/built-in.a -- >> ld.lld: error: undefined symbol: usb_put_intf >>> referenced by apple-touchbar.c:1101 (drivers/hid/apple-touchbar.c:1101) >>> hid/apple-touchbar.o:(appletb_probe) in archive drivers/built-in.a >>> referenced by apple-touchbar.c:1101 (drivers/hid/apple-touchbar.c:1101) >>> hid/apple-touchbar.o:(appletb_remove) in archive drivers/built-in.a -- >> ld.lld: error: undefined symbol: usb_control_msg >>> referenced by apple-touchbar.c:212 (drivers/hid/apple-touchbar.c:212) >>> hid/apple-touchbar.o:(appletb_send_usb_ctrl) in archive drivers/built-in.a >>> referenced by apple-touchbar.c:212 (drivers/hid/apple-touchbar.c:212) >>> hid/apple-touchbar.o:(appletb_send_usb_ctrl) in archive drivers/built-in.a >>> referenced by apple-touchbar.c:212 (drivers/hid/apple-touchbar.c:212) >>> hid/apple-touchbar.o:(appletb_send_usb_ctrl) in archive drivers/built-in.a >>> referenced 2 more times --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
hppa64-linux-ld: kernel/rcu/refscale.o(.init.text+0x228): cannot reach schedule_timeout_uninterruptible
Hi Paul, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 commit: 1fbeb3a8c4de29433a8d230ee600b13d369b6c0f refperf: Rename refperf.c to refscale.c and change internal names date: 8 months ago config: parisc-randconfig-s031-20210228 (attached as .config) compiler: hppa64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-241-geaceeafa-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1fbeb3a8c4de29433a8d230ee600b13d369b6c0f git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1fbeb3a8c4de29433a8d230ee600b13d369b6c0f # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): hppa64-linux-ld: init/main.o(.init.text+0xdd8): cannot reach rest_init init/main.o: in function `arch_call_rest_init': (.init.text+0xdd8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `rest_init' defined in .ref.text section in init/main.o hppa64-linux-ld: init/main.o(.init.text+0x13d8): cannot reach build_all_zonelists init/main.o: in function `start_kernel': (.init.text+0x13d8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `build_all_zonelists' defined in .ref.text section in mm/page_alloc.o hppa64-linux-ld: init/main.o(.init.text+0x176c): cannot reach profile_init (.init.text+0x176c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `profile_init' defined in .ref.text section in kernel/profile.o hppa64-linux-ld: init/main.o(.init.text+0x1ac0): cannot reach wait_for_completion init/main.o: in function `kernel_init_freeable': (.init.text+0x1ac0): relocation truncated to fit: R_PARISC_PCREL22F against symbol `wait_for_completion' defined in .sched.text section in kernel/sched/completion.o hppa64-linux-ld: init/main.o(.ref.text+0x1c): cannot reach rcu_scheduler_starting init/main.o: in function `rest_init': (.ref.text+0x1c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `rcu_scheduler_starting' defined in .init.text section in kernel/rcu/srcutiny.o hppa64-linux-ld: init/main.o(.ref.text+0x17c): cannot reach unknown init/main.o: in function `kernel_init': (.ref.text+0x17c): relocation truncated to fit: R_PARISC_PCREL22F against `kernel_init_freeable' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0x78): cannot reach unknown arch/parisc/mm/init.o: in function `free_initmem': (.ref.text+0x78): relocation truncated to fit: R_PARISC_PCREL22F against `map_pages' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xa0): cannot reach unknown (.ref.text+0xa0): relocation truncated to fit: R_PARISC_PCREL22F against `map_pages' hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xc4): cannot reach unknown (.ref.text+0xc4): relocation truncated to fit: R_PARISC_PCREL22F against `map_pages' hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x768): cannot reach _raw_spin_lock kernel/printk/printk.o: in function `setup_log_buf': (.init.text+0x768): relocation truncated to fit: R_PARISC_PCREL22F against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/locking/spinlock.o hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x7c4): cannot reach _raw_spin_unlock (.init.text+0x7c4): additional relocation overflows omitted from the output hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x228): cannot reach mutex_lock hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x440): cannot reach mutex_unlock hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x7a0): cannot reach mutex_lock hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0x878): cannot reach mutex_unlock hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0xad4): cannot reach mutex_lock hppa64-linux-ld: kernel/cgroup/cgroup.o(.init.text+0xafc): cannot reach mutex_unlock hppa64-linux-ld: kernel/resource.o(.init.text+0x32c): cannot reach _raw_write_lock hppa64-linux-ld: kernel/resource.o(.init.text+0x4f8): cannot reach _raw_write_unlock hppa64-linux-ld: kernel/time/clocksource.o(.init.text+0x90): cannot reach mutex_lock hppa64-linux-ld: kernel/time/clocksource.o(.init.text+0xc4): cannot reach mutex_unlock hppa64-linux-ld: kernel/time/clocksource.o(.init.text+0x1b8): cannot reach mutex_lock hppa64-linux-ld: kernel/time/clocksource.o(.init.text+0x208):
[PATCH] atm: lanai: dont run lanai_dev_close if not open
lanai_dev_open() can fail. When it fail, lanai->base is unmapped and the pci device is disabled. The caller, lanai_init_one(), then tries to run atm_dev_deregister(). This will subsequently call lanai_dev_close() and use the already released MMIO area. To fix this issue, set the lanai->base to NULL if open fail, and test the flag in lanai_dev_close(). [8.324153] lanai: lanai_start() failed, err=19 [8.324819] lanai(itf 0): shutting down interface [8.325211] BUG: unable to handle page fault for address: c9180024 [8.325781] #PF: supervisor write access in kernel mode [8.326215] #PF: error_code(0x0002) - not-present page [8.326641] PGD 10067 P4D 10067 PUD 100139067 PMD 10013a067 PTE 0 [8.327206] Oops: 0002 [#1] SMP KASAN NOPTI [8.327557] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc7-00090-gdcc0b49040c7 #12 [8.328229] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4 [8.329145] RIP: 0010:lanai_dev_close+0x4f/0xe5 [lanai] [8.329587] Code: 00 48 c7 c7 00 d3 01 c0 e8 49 4e 0a c2 48 8d bd 08 02 00 00 e8 6e 52 14 c1 48 80 [8.330917] RSP: 0018:8881029ef680 EFLAGS: 00010246 [8.331196] RAX: 0003fffe RBX: 888102fb4800 RCX: c001a98a [8.331572] RDX: c918 RSI: 0246 RDI: 888102fb4000 [8.331948] RBP: 888102fb4000 R08: 8115da8a R09: ed102053deaa [8.332326] R10: 0003 R11: ed102053dea9 R12: 888102fb48a4 [8.332701] R13: c00123c0 R14: 888102fb4b90 R15: 888102fb4b88 [8.333077] FS: 7f08eb9056a0() GS:88815b40() knlGS: [8.333502] CS: 0010 DS: ES: CR0: 80050033 [8.333806] CR2: c9180024 CR3: 000102a28000 CR4: 06f0 [8.334182] DR0: DR1: DR2: [8.334557] DR3: DR6: fffe0ff0 DR7: 0400 [8.334932] Call Trace: [8.335066] atm_dev_deregister+0x161/0x1a0 [atm] [8.335324] lanai_init_one.cold+0x20c/0x96d [lanai] [8.335594] ? lanai_send+0x2a0/0x2a0 [lanai] [8.335831] local_pci_probe+0x6f/0xb0 [8.336039] pci_device_probe+0x171/0x240 [8.336255] ? pci_device_remove+0xe0/0xe0 [8.336475] ? kernfs_create_link+0xb6/0x110 [8.336704] ? sysfs_do_create_link_sd.isra.0+0x76/0xe0 [8.336983] really_probe+0x161/0x420 [8.337181] driver_probe_device+0x6d/0xd0 [8.337401] device_driver_attach+0x82/0x90 [8.337626] ? device_driver_attach+0x90/0x90 [8.337859] __driver_attach+0x60/0x100 [8.338065] ? device_driver_attach+0x90/0x90 [8.338298] bus_for_each_dev+0xe1/0x140 [8.338511] ? subsys_dev_iter_exit+0x10/0x10 [8.338745] ? klist_node_init+0x61/0x80 [8.338956] bus_add_driver+0x254/0x2a0 [8.339164] driver_register+0xd3/0x150 [8.339370] ? 0xc0028000 [8.339550] do_one_initcall+0x84/0x250 [8.339755] ? trace_event_raw_event_initcall_finish+0x150/0x150 [8.340076] ? free_vmap_area_noflush+0x1a5/0x5c0 [8.340329] ? unpoison_range+0xf/0x30 [8.340532] ? kasan_kmalloc.constprop.0+0x84/0xa0 [8.340806] ? unpoison_range+0xf/0x30 [8.341014] ? unpoison_range+0xf/0x30 [8.341217] do_init_module+0xf8/0x350 [8.341419] load_module+0x3fe6/0x4340 [8.341621] ? vm_unmap_ram+0x1d0/0x1d0 [8.341826] ? kasan_kmalloc.constprop.0+0x84/0xa0 [8.342101] ? module_frob_arch_sections+0x20/0x20 [8.342358] ? __do_sys_finit_module+0x108/0x170 [8.342604] __do_sys_finit_module+0x108/0x170 [8.342841] ? __ia32_sys_init_module+0x40/0x40 [8.343083] ? file_open_root+0x200/0x200 [8.343298] ? do_sys_open+0x85/0xe0 [8.343491] ? filp_open+0x50/0x50 [8.343675] ? exit_to_user_mode_prepare+0xfc/0x130 [8.343935] do_syscall_64+0x33/0x40 [8.344132] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [8.344401] RIP: 0033:0x7f08eb887cf7 [8.344594] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 41 [8.345565] RSP: 002b:7ffcd5c98ad8 EFLAGS: 0246 ORIG_RAX: 0139 [8.345962] RAX: ffda RBX: 008fea70 RCX: 7f08eb887cf7 [8.346336] RDX: RSI: 008fd9e0 RDI: 0003 [8.346711] RBP: 0003 R08: R09: 0001 [8.347085] R10: 7f08eb8eb300 R11: 0246 R12: 008fd9e0 [8.347460] R13: R14: 008fddd0 R15: 0001 [8.347836] Modules linked in: lanai(+) atm [8.348065] CR2: c9180024 [8.348244] ---[ end trace 7fdc1c668f2003e5 ]--- [8.348490] RIP: 0010:lanai_dev_close+0x4f/0xe5 [lanai] [8.348772] Code: 00 48 c7 c7 00 d3 01 c0 e8 49 4e 0a c2 48 8d bd 08 02 00 00 e8 6e 52 14 c1 48 80 [8.349745] RSP: 0018:8881029ef680 EFLAGS: 00010246 [8.350022] RAX:
Re: [PATCH 5/5] HID: apple-touchbar - Add driver for the Touch Bar on MacBook Pro's.
Hi "Ronald, Thank you for the patch! Yet something to improve: [auto build test ERROR on hid/for-next] [also build test ERROR on iio/togreg jikos-trivial/for-next v5.11 next-20210226] [cannot apply to jikos-hid/for-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Ronald-Tschal-r/Touch-Bar-and-ALS-support-for-MacBook-Pro-s/20210228-093451 base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next config: microblaze-randconfig-r011-20210228 (attached as .config) compiler: microblaze-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/cfbb470c2977fd10aef2791b57bdfa2d95f627e0 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Ronald-Tschal-r/Touch-Bar-and-ALS-support-for-MacBook-Pro-s/20210228-093451 git checkout cfbb470c2977fd10aef2791b57bdfa2d95f627e0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=microblaze If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): microblaze-linux-ld: drivers/hid/apple-touchbar.o: in function `appletb_clear_iface_info': >> drivers/hid/.tmp_gl_apple-touchbar.o:(.text+0x16dc): undefined reference to >> `usb_put_intf' microblaze-linux-ld: drivers/hid/apple-touchbar.o: in function `appletb_send_usb_ctrl.isra.0': >> drivers/hid/.tmp_gl_apple-touchbar.o:(.text+0x1bac): undefined reference to >> `usb_control_msg' microblaze-linux-ld: drivers/hid/apple-touchbar.o: in function `appletb_probe': >> drivers/hid/.tmp_gl_apple-touchbar.o:(.text+0x2670): undefined reference to >> `usb_get_intf' microblaze-linux-ld: drivers/hid/apple-touchbar.o: in function `appletb_set_tb_worker': >> drivers/hid/.tmp_gl_apple-touchbar.o:(.text+0x3258): undefined reference to >> `__divdi3' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[GIT PULL] csky changes for v5.12-rc1
Hi Linus, The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) are available in the Git repository at: https://github.com/c-sky/csky-linux.git tags/csky-for-linus-5.12-rc1 for you to fetch changes up to 6607aa6f6b68fc9b5955755f1b1be125cf2a9d03: csky: Fixup compile error (2021-02-27 22:04:14 +0800) arch/csky patches for 5.12-rc1 Features: - Add new memory layout 2.5G(user):1.5G(kernel) - Add kmemleak support - Reconstruct VDSO framework Add VDSO with GENERIC_GETTIMEOFDAY, GENERIC_TIME_VSYSCALL, HAVE_GENERIC_VDSO - Add faulthandler_disabled() check - Support(Fixup) swapon - Add(Fixup) _PAGE_ACCESSED for default pgprot - abort uaccess retries upon fatal signal (From arm) Fixup & Optimization: - Fixup perf probe failed - Fixup show_regs doesn't contain regs->usp - Remove custom asm/atomic.h implementation - Fixup barrier design - Fixup futex SMP implementation - Fixup asm/cmpxchg.h with correct ordering barrier - Cleanup asm/spinlock.h - Fixup PTE global for 2.5:1.5 virtual memory - Remove prologue of page fault handler in entry.S - Fix TLB maintenance synchronization problem - Add show_tlb for CPU_CK860 debug - Fixup FAULT_FLAG_XXX param for handle_mm_fault - Fixup update_mmu_cache called with user io mapping - Fixup do_page_fault parent irq status - Fix a size determination in gpr_get() - pgtable.h: Coding convention - kprobe: Fixup code in simulate without 'long' - Fixup pfn_valid error with wrong max_mapnr - use free_initmem_default() in free_initmem() - Fixup compile error David Hildenbrand (1): csky: use free_initmem_default() in free_initmem() Guo Ren (27): csky: Add memory layout 2.5G(user):1.5G(kernel) csky: Fixup perf probe failed csky: Fixup show_regs doesn't contain regs->usp csky: Remove custom asm/atomic.h implementation csky: Fixup barrier design csky: Fixup futex SMP implementation csky: Fixup asm/cmpxchg.h with correct ordering barrier csky: Cleanup asm/spinlock.h csky: Fixup PTE global for 2.5:1.5 virtual memory csky: Remove prologue of page fault handler in entry.S csky: Add kmemleak support csky: Fix TLB maintenance synchronization problem csky: Add show_tlb for CPU_CK860 debug csky: Fixup FAULT_FLAG_XXX param for handle_mm_fault csky: Fixup update_mmu_cache called with user io mapping csky: Add faulthandler_disabled() check csky: Fixup do_page_fault parent irq status csky: Sync riscv mm/fault.c for easy maintenance csky: mm: abort uaccess retries upon fatal signal csky: Reconstruct VDSO framework csky: Fixup _PAGE_ACCESSED for default pgprot csky: pgtable.h: Coding convention csky: Fixup swapon csky: kprobe: Fixup code in simulate without 'long' csky: Add VDSO with GENERIC_GETTIMEOFDAY, GENERIC_TIME_VSYSCALL, HAVE_GENERIC_VDSO csky: Fixup pfn_valid error with wrong max_mapnr csky: Fixup compile error Tian Tao (1): csky: remove unused including Zhenzhong Duan (1): csky: Fix a size determination in gpr_get() arch/csky/Kconfig | 24 +- arch/csky/abiv1/inc/abi/cacheflush.h | 1 - arch/csky/abiv1/inc/abi/ckmmu.h | 10 +- arch/csky/abiv1/inc/abi/entry.h | 1 - arch/csky/abiv1/inc/abi/page.h| 1 - arch/csky/abiv1/inc/abi/pgtable-bits.h| 40 +-- arch/csky/abiv1/inc/abi/reg_ops.h | 1 - arch/csky/abiv1/inc/abi/regdef.h | 6 +- arch/csky/abiv1/inc/abi/string.h | 1 - arch/csky/abiv1/inc/abi/switch_context.h | 1 - arch/csky/abiv1/inc/abi/vdso.h| 18 +- arch/csky/abiv2/cacheflush.c | 3 + arch/csky/abiv2/inc/abi/ckmmu.h | 44 +++- arch/csky/abiv2/inc/abi/entry.h | 20 +- arch/csky/abiv2/inc/abi/fpu.h | 1 - arch/csky/abiv2/inc/abi/page.h| 1 - arch/csky/abiv2/inc/abi/pgtable-bits.h| 37 ++- arch/csky/abiv2/inc/abi/reg_ops.h | 1 - arch/csky/abiv2/inc/abi/regdef.h | 6 +- arch/csky/abiv2/inc/abi/switch_context.h | 1 - arch/csky/abiv2/inc/abi/vdso.h| 20 +- arch/csky/abiv2/sysdep.h | 1 - arch/csky/include/asm/addrspace.h | 1 - arch/csky/include/asm/atomic.h| 212 arch/csky/include/asm/barrier.h | 83 +-- arch/csky/include/asm/bitops.h| 1 - arch/csky/include/asm/bug.h | 3 +- arch/csky/include/asm/cacheflush.h| 1 - arch/csky/include/asm/checksum.h | 1 - arch/csky/include/asm/clocksource.h | 8 + arch/csky/include/asm/cmpxchg.h | 27 ++- arch/csky/include/asm/elf.h | 1 -
Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability
On Sun, Feb 28, 2021 at 3:41 AM Masahiro Yamada wrote:
>
> This commit reverts 0bf6276392e9 ("x32: Warn and disable rather than
> error if binutils too old").
>
> The help text in arch/x86/Kconfig says enabling the X32 ABI support
> needs binutils 2.22 or later. This is met because the minimal binutils
> version is 2.23 according to Documentation/process/changes.rst.
>
> I would not say I am not familiar with toolchain configuration, but
I mean:
I would not say I am familiar ...
That is why I added RFC.
I appreciate comments from people who are familiar
with toolchains (binutils, llvm).
If this change is not safe,
we can move this check to Kconfig at least.
> I checked the configure.tgt code in binutils. The elf32_x86_64
> emulation mode seems to be included when it is configured for the
> x86_64-*-linux-* target.
>
> I also tried lld and llvm-objcopy, and succeeded in building x32 VDSO.
>
> I removed the compile-time check in arch/x86/Makefile, in the hope of
> elf32_x86_64 being always supported.
>
> With this, CONFIG_X86_X32 and CONFIG_X86_X32_ABI will be equivalent.
> Rename the former to the latter.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/x86/Kconfig | 8 ++--
> arch/x86/Makefile | 16
> arch/x86/include/asm/syscall_wrapper.h | 6 +++---
> arch/x86/include/asm/vdso.h| 2 +-
> arch/x86/kernel/process_64.c | 2 +-
> fs/fuse/file.c | 2 +-
> fs/xfs/xfs_ioctl32.c | 2 +-
> sound/core/control_compat.c| 16
> sound/core/pcm_compat.c| 20 ++--
> 9 files changed, 27 insertions(+), 47 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 2792879d398e..7272cba2744c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2865,7 +2865,7 @@ config IA32_AOUT
> help
> Support old a.out binaries in the 32bit emulation.
>
> -config X86_X32
> +config X86_X32_ABI
> bool "x32 ABI for 64-bit mode"
> depends on X86_64
> help
> @@ -2874,10 +2874,6 @@ config X86_X32
> full 64-bit register file and wide data path while leaving
> pointers at 32 bits for smaller memory footprint.
>
> - You will need a recent binutils (2.22 or later) with
> - elf32_x86_64 support enabled to compile a kernel with this
> - option set.
> -
> config COMPAT_32
> def_bool y
> depends on IA32_EMULATION || X86_32
> @@ -2886,7 +2882,7 @@ config COMPAT_32
>
> config COMPAT
> def_bool y
> - depends on IA32_EMULATION || X86_X32
> + depends on IA32_EMULATION || X86_X32_ABI
>
> if COMPAT
> config COMPAT_FOR_U64_ALIGNMENT
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 2d6d5a28c3bf..e163549f5be7 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -125,22 +125,6 @@ else
> KBUILD_CFLAGS += -mcmodel=kernel
> endif
>
> -ifdef CONFIG_X86_X32
> - x32_ld_ok := $(call try-run,\
> - /bin/echo -e '1: .quad 1b' | \
> - $(CC) $(KBUILD_AFLAGS) -c -x assembler -o "$$TMP" -
> && \
> - $(OBJCOPY) -O elf32-x86-64 "$$TMP" "$$TMPO" && \
> - $(LD) -m elf32_x86_64 "$$TMPO" -o "$$TMP",y,n)
> -ifeq ($(x32_ld_ok),y)
> -CONFIG_X86_X32_ABI := y
> -KBUILD_AFLAGS += -DCONFIG_X86_X32_ABI
> -KBUILD_CFLAGS += -DCONFIG_X86_X32_ABI
> -else
> -$(warning CONFIG_X86_X32 enabled but no binutils support)
> -endif
> -endif
> -export CONFIG_X86_X32_ABI
> -
> #
> # If the function graph tracer is used with mcount instead of fentry,
> # '-maccumulate-outgoing-args' is needed to prevent a GCC bug
> diff --git a/arch/x86/include/asm/syscall_wrapper.h
> b/arch/x86/include/asm/syscall_wrapper.h
> index a84333adeef2..69bf87c41a0b 100644
> --- a/arch/x86/include/asm/syscall_wrapper.h
> +++ b/arch/x86/include/asm/syscall_wrapper.h
> @@ -158,7 +158,7 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs
> *regs);
> #endif /* CONFIG_IA32_EMULATION */
>
>
> -#ifdef CONFIG_X86_X32
> +#ifdef CONFIG_X86_X32_ABI
> /*
> * For the x32 ABI, we need to create a stub for compat_sys_*() which is
> aware
> * of the x86-64-style parameter ordering of x32 syscalls. The syscalls
> common
> @@ -176,12 +176,12 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs
> *regs);
>
> #define __X32_COMPAT_SYS_NI(name) \
> __SYS_NI(x32, compat_sys_##name)
> -#else /* CONFIG_X86_X32 */
> +#else /* CONFIG_X86_X32_ABI */
> #define __X32_COMPAT_SYS_STUB0(name)
> #define __X32_COMPAT_SYS_STUBx(x, name, ...)
> #define __X32_COMPAT_COND_SYSCALL(name)
> #define __X32_COMPAT_SYS_NI(name)
> -#endif /* CONFIG_X86_X32 */
> +#endif /* CONFIG_X86_X32_ABI */
>
>
> #ifdef CONFIG_COMPAT
> diff --git
Re:reply
Hello,
My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state and
Petroleum" also "Minister of State for International Cooperation" in UAE.
I write to you on behalf of my other "three (3) colleagues" who has approved me
to solicit for your "partnership in claiming of {us$47=Million}" from a
Financial Home in Cambodia on their behalf and for our "Mutual Benefits". The
Fund {us$47=Million} is our share from the (over-invoiced) Oil/Gas deal with
Cambodian/Vietnam Government within 2013/2014, however, we don't want our
government to know about the fund.
If this proposal interests you, let me know, by sending me an email and I will
send to you detailed information on how this business would be successfully
transacted. Be informed that nobody knows about the secret of this fund except
us, and we know how to carry out the entire transaction. So I am compelled to
ask, that you will stand on our behalf and receive this fund into any account
that is solely controlled by you. We will compensate you with 15% of the total
amount involved as gratification for being our partner in this transaction.
Reply to: marlowguttri...@gmail.com
Regards,
Ms. Reem
Re: [PATCH v8 20/22] counter: Implement events_queue_size sysfs attribute
On Sat, Feb 27, 2021 at 03:18:47PM +, Jonathan Cameron wrote:
> On Fri, 26 Feb 2021 09:03:48 +0900
> William Breathitt Gray wrote:
>
> > On Sun, Feb 21, 2021 at 03:51:40PM +, Jonathan Cameron wrote:
> > > On Thu, 18 Feb 2021 19:32:16 +0900
> > > William Breathitt Gray wrote:
> > >
> > > > On Sun, Feb 14, 2021 at 06:11:46PM +, Jonathan Cameron wrote:
> > > > > On Fri, 12 Feb 2021 21:13:44 +0900
> > > > > William Breathitt Gray wrote:
> > > > >
> > > > > > The events_queue_size sysfs attribute provides a way for users to
> > > > > > dynamically configure the Counter events queue size for the Counter
> > > > > > character device interface. The size is in number of struct
> > > > > > counter_event data structures. The number of elements will be
> > > > > > rounded-up
> > > > > > to a power of 2 due to a requirement of the kfifo_alloc function
> > > > > > called
> > > > > > during reallocation of the queue.
> > > > > >
> > > > > > Cc: Oleksij Rempel
> > > > > > Signed-off-by: William Breathitt Gray
> > > > > > ---
> > > > > > Documentation/ABI/testing/sysfs-bus-counter | 8 +++
> > > > > > drivers/counter/counter-chrdev.c| 23
> > > > > > +++
> > > > > > drivers/counter/counter-chrdev.h| 2 ++
> > > > > > drivers/counter/counter-sysfs.c | 25
> > > > > > +
> > > > > > 4 files changed, 58 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-counter
> > > > > > b/Documentation/ABI/testing/sysfs-bus-counter
> > > > > > index 847e96f19d19..f6cb2a8b08a7 100644
> > > > > > --- a/Documentation/ABI/testing/sysfs-bus-counter
> > > > > > +++ b/Documentation/ABI/testing/sysfs-bus-counter
> > > > > > @@ -212,6 +212,14 @@ Description:
> > > > > > both edges:
> > > > > > Any state transition.
> > > > > >
> > > > > > +What:
> > > > > > /sys/bus/counter/devices/counterX/events_queue_size
> > > > > > +KernelVersion: 5.13
> > > > > > +Contact: linux-...@vger.kernel.org
> > > > > > +Description:
> > > > > > + Size of the Counter events queue in number of struct
> > > > > > + counter_event data structures. The number of elements
> > > > > > will be
> > > > > > + rounded-up to a power of 2.
> > > > > > +
> > > > > > What: /sys/bus/counter/devices/counterX/name
> > > > > > KernelVersion: 5.2
> > > > > > Contact: linux-...@vger.kernel.org
> > > > > > diff --git a/drivers/counter/counter-chrdev.c
> > > > > > b/drivers/counter/counter-chrdev.c
> > > > > > index 16f02df7f73d..53eea894e13f 100644
> > > > > > --- a/drivers/counter/counter-chrdev.c
> > > > > > +++ b/drivers/counter/counter-chrdev.c
> > > > > > @@ -375,6 +375,29 @@ void counter_chrdev_remove(struct
> > > > > > counter_device *const counter)
> > > > > > cdev_del(>chrdev);
> > > > > > }
> > > > > >
> > > > > > +int counter_chrdev_realloc_queue(struct counter_device *const
> > > > > > counter,
> > > > > > +size_t queue_size)
> > > > > > +{
> > > > > > + int err;
> > > > > > + DECLARE_KFIFO_PTR(events, struct counter_event);
> > > > > > + unsigned long flags;
> > > > > > +
> > > > > > + /* Allocate new events queue */
> > > > > > + err = kfifo_alloc(, queue_size, GFP_ATOMIC);
> > > > >
> > > > > Is there any potential for losing events?
> > > >
> > > > We take the events_list_lock down below so we're safe against missing an
> > > > event, but past events currently unread in the queue will be lost.
> > > >
> > > > Shortening the size of the queue is inherently a destructive process if
> > > > we have more events in the current queue than can fit in the new queue.
> > > > Because we a liable to lose some events in such a case, I think it's
> > > > best to keep the behavior of this reallocation consistent and have it
> > > > provide a fresh empty queue every time, as opposed to sometimes dropping
> > > > events and sometimes not.
> > > >
> > > > I also suspect an actual user would be setting the size of their queue
> > > > to the required amount before they begin watching events, rather than
> > > > adjusting it sporadically during a live operation.
> > > >
> > >
> > > Absolutely agree. As such I wonder if you are better off enforcing this
> > > behaviour? If the cdev is open for reading, don't allow the fifo to be
> > > resized.
> > >
> > > Jonathan
> >
> > I can't really think of a good reason not to, so let's enforce it: if
> > the cdev is open, then we'll return an EINVAL if the user attempts to
> > resize the queue.
> >
> > What is a good way to check for this condition? Should I just call
> > kref_read() and see if it's greater than 1? For example, in
> > counter_chrdev_realloc_queue():
> >
> > if (kref_read(>dev.kobj.kref) > 1)
> > return -EINVAL;
> In theory at least you might want the kobj.kref to be incremented
> for other reasons
mm/compaction.c:463:20: warning: unused function 'isolation_suitable'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4
commit: 9df41314390b81a541ca6e84c8340bad0959e4b5 mm/compaction: do page
isolation first in compaction
date: 2 months ago
config: mips-randconfig-r004-20210228 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
83bc7815c4235786111aa2abf7193292e4a602f5)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9df41314390b81a541ca6e84c8340bad0959e4b5
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 9df41314390b81a541ca6e84c8340bad0959e4b5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
mm/compaction.c:56:27: warning: unused variable
'HPAGE_FRAG_CHECK_INTERVAL_MSEC'
static const unsigned int HPAGE_FRAG_CHECK_INTERVAL_MSEC = 500;
^
>> mm/compaction.c:463:20: warning: unused function 'isolation_suitable'
static inline bool isolation_suitable(struct compact_control
^
>> mm/compaction.c:469:20: warning: unused function 'pageblock_skip_persistent'
static inline bool pageblock_skip_persistent(struct page
^
>> mm/compaction.c:474:20: warning: unused function 'update_pageblock_skip'
static inline void update_pageblock_skip(struct compact_control
^
fatal error: error in backend: Nested variants found in inline asm string: '
.set push
.set noat
.set push
.set arch=r4000
.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/cmpxchg.h",
.line = 163, $); 0x00 ) != -1)) : $))) ) && ( 0 ); .set push; .set mips64r2;
.rept 1; sync 0x00; .endr; .set pop; .else; ; .endif
1: ll $0, $2 # __cmpxchg_asm
bne $0, ${3:z}, 2f
.set pop
move $$1, ${4:z}
.set arch=r4000
sc $$1, $1
beqz $$1, 1b
.set pop
2: .if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct
ftrace_branch_data __attribute__((__aligned__(4)))
__attribute__((__section__("_ftrace_branch"))) __if_trace = $( .func =
__func__, .file = "arch/mips/include/asm/cmpxchg.h", .line = 163, $); 0x00 ) !=
-1)) : $))) ) && ( 0 ); .set push; .set mips64r2; .rept 1; sync 0x00; .endr;
.set pop; .else; ; .endif
'
clang-13: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 13.0.0 (git://gitmirror/llvm_project
e0b1df924ae06d6d88582334087d2eacc6702e8f)
Target: mipsel-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cross/clang-e0b1df924a/bin
clang-13: note: diagnostic msg:
Makefile arch block certs crypto drivers fs include init ipc kernel lib mm
net scripts security sound source usr virt
vim +/isolation_suitable +463 mm/compaction.c
e380bebe477154 Mel Gorman 2019-03-05 440
bb13ffeb9f6bfe Mel Gorman 2012-10-08 441 /*
bb13ffeb9f6bfe Mel Gorman 2012-10-08 442 * If no pages were isolated
then mark this pageblock to be skipped in the
62997027ca5b3d Mel Gorman 2012-10-08 443 * future. The information is
later cleared by __reset_isolation_suitable().
bb13ffeb9f6bfe Mel Gorman 2012-10-08 444 */
c89511ab2f8fe2 Mel Gorman 2012-10-08 445 static void
update_pageblock_skip(struct compact_control *cc,
d097a6f6352254 Mel Gorman 2019-03-05 446 struct
page *page, unsigned long pfn)
bb13ffeb9f6bfe Mel Gorman 2012-10-08 447 {
c89511ab2f8fe2 Mel Gorman 2012-10-08 448 struct zone *zone =
cc->zone;
6815bf3f233e0b Joonsoo Kim 2013-12-18 449
2583d6713267a4 Vlastimil Babka 2017-11-17 450 if
(cc->no_set_skip_hint)
6815bf3f233e0b Joonsoo Kim 2013-12-18 451 return;
6815bf3f233e0b Joonsoo Kim 2013-12-18 452
bb13ffeb9f6bfe Mel Gorman 2012-10-08 453 if (!page)
bb13ffeb9f6bfe Mel Gorman 2012-10-08 454 return;
bb13ffeb9f6bfe Mel Gorman 2012-10-08 455
bb13ffeb9f6bfe Mel Gorman 2012-10-08 456
set_pageblock_skip(page);
c89511ab2f8fe2 Mel Gorman 2012-10-08 457
35979ef3393110 David Rientjes 2014-06-04 458 /* Update where async
and sync compaction should restart */
35979ef3393110 David Rientjes 2014-06-04 459 if (pfn <
zone->compact_cached_free_pfn)
Re: [PATCH V2] fs: dlm: Spellings fixed throughout the file lock.c
On 2/27/21 5:02 PM, Bhaskar Chowdhury wrote: > > Few spelling fixes throughout the file. > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > Changes from V1: > Fixed the subject line typo. > Measured unwanted blank lines insertion. > > fs/dlm/lock.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c > index 002123efc6b0..b1c36ed5 100644 > --- a/fs/dlm/lock.c > +++ b/fs/dlm/lock.c > @@ -91,7 +91,7 @@ static void del_timeout(struct dlm_lkb *lkb); > static void toss_rsb(struct kref *kref); > > /* > - * Lock compatibilty matrix - thanks Steve > + * Lock compatibility matrix - thanks Steve > * UN = Unlocked state. Not really a state, used as a flag > * PD = Padding. Used to make the matrix a nice power of two in size > * Other states are the same as the VMS DLM. > @@ -2357,14 +2357,14 @@ static int _can_be_granted(struct dlm_rsb *r, struct > dlm_lkb *lkb, int now, >* 6-5: But the default algorithm for deciding whether to grant or >* queue conversion requests does not by itself guarantee that such >* requests are serviced on a "first come first serve" basis. This, in > - * turn, can lead to a phenomenon known as "indefinate postponement". > + * turn, can lead to a phenomenon known as "indefinite postponement". >* >* 6-7: This issue is dealt with by using the optional QUECVT flag with >* the system service employed to request a lock conversion. This flag >* forces certain conversion requests to be queued, even if they are >* compatible with the granted modes of other locks on the same >* resource. Thus, the use of this flag results in conversion requests > - * being ordered on a "first come first servce" basis. > + * being ordered on a "first come first serve" basis. >* >* DCT: This condition is all about new conversions being able to occur >* "in place" while the lock remains on the granted queue (assuming > -- -- ~Randy
rmem.c:undefined reference to `memremap'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 commit: 5a3fa75a4d9cb6bcfc9081ef224a4cdcd4b3eafe nvmem: Add driver to expose reserved memory as nvmem date: 3 weeks ago config: s390-randconfig-r013-20210228 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 83bc7815c4235786111aa2abf7193292e4a602f5) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a3fa75a4d9cb6bcfc9081ef224a4cdcd4b3eafe git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 5a3fa75a4d9cb6bcfc9081ef224a4cdcd4b3eafe # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): s390x-linux-gnu-ld: kernel/dma/coherent.o: in function `dma_declare_coherent_memory': coherent.c:(.text+0x7c): undefined reference to `memunmap' s390x-linux-gnu-ld: kernel/dma/coherent.o: in function `dma_init_coherent_memory': coherent.c:(.text+0xf4): undefined reference to `memremap' s390x-linux-gnu-ld: coherent.c:(.text+0x1e0): undefined reference to `memunmap' s390x-linux-gnu-ld: drivers/dma/dw/platform.o: in function `dw_probe': platform.c:(.text+0x92): undefined reference to `devm_platform_ioremap_resource' s390x-linux-gnu-ld: drivers/dma/fsl-edma.o: in function `fsl_edma_probe': fsl-edma.c:(.text+0xd4): undefined reference to `devm_ioremap_resource' s390x-linux-gnu-ld: fsl-edma.c:(.text+0x20a): undefined reference to `devm_ioremap_resource' s390x-linux-gnu-ld: drivers/dma/idma64.o: in function `idma64_platform_probe': idma64.c:(.text+0x76): undefined reference to `devm_ioremap_resource' s390x-linux-gnu-ld: drivers/dma/sf-pdma/sf-pdma.o: in function `sf_pdma_probe': sf-pdma.c:(.text+0x5a): undefined reference to `devm_ioremap_resource' s390x-linux-gnu-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_probe': hidma_mgmt.c:(.text+0x2f8): undefined reference to `devm_ioremap_resource' s390x-linux-gnu-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_of_populate_channels': hidma_mgmt.c:(.init.text+0x152): undefined reference to `of_address_to_resource' s390x-linux-gnu-ld: hidma_mgmt.c:(.init.text+0x16a): undefined reference to `of_address_to_resource' s390x-linux-gnu-ld: drivers/dma/xilinx/xilinx_dpdma.o: in function `xilinx_dpdma_probe': xilinx_dpdma.c:(.text+0xbc): undefined reference to `devm_platform_ioremap_resource' s390x-linux-gnu-ld: drivers/net/can/grcan.o: in function `grcan_probe': grcan.c:(.text+0x84): undefined reference to `devm_platform_ioremap_resource' s390x-linux-gnu-ld: drivers/media/rc/ir-hix5hd2.o: in function `hix5hd2_ir_probe': ir-hix5hd2.c:(.text+0xd8): undefined reference to `devm_ioremap_resource' s390x-linux-gnu-ld: drivers/iio/adc/adi-axi-adc.o: in function `adi_axi_adc_probe': adi-axi-adc.c:(.text+0x3aa): undefined reference to `devm_platform_ioremap_resource' s390x-linux-gnu-ld: drivers/nvmem/rmem.o: in function `rmem_read': >> rmem.c:(.text+0x142): undefined reference to `memremap' >> s390x-linux-gnu-ld: rmem.c:(.text+0x19a): undefined reference to `memunmap' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] [v2] Input: Add "Share" button to Microsoft Xbox One controller.
On 2/24/21 11:32 PM, Chris Ye wrote:
> Add "Share" button input capability and input event mapping for
> Microsoft Xbox One controller.
> Fixed Microsoft Xbox One controller share button not working under USB
> connection.
>
> Signed-off-by: Chris Ye
> ---
> drivers/input/joystick/xpad.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index 9f0d07dcbf06..0c3374091aff 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -79,6 +79,7 @@
> #define MAP_DPAD_TO_BUTTONS (1 << 0)
> #define MAP_TRIGGERS_TO_BUTTONS (1 << 1)
> #define MAP_STICKS_TO_NULL (1 << 2)
> +#define MAP_SHARE_BUTTON (1 << 3)
> #define DANCEPAD_MAP_CONFIG (MAP_DPAD_TO_BUTTONS | \
> MAP_TRIGGERS_TO_BUTTONS | MAP_STICKS_TO_NULL)
>
> @@ -130,6 +131,7 @@ static const struct xpad_device {
> { 0x045e, 0x02e3, "Microsoft X-Box One Elite pad", 0, XTYPE_XBOXONE },
> { 0x045e, 0x02ea, "Microsoft X-Box One S pad", 0, XTYPE_XBOXONE },
> { 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS,
> XTYPE_XBOX360W },
> + { 0x045e, 0x0b12, "Microsoft X-Box One X pad", MAP_SHARE_BUTTON,
> XTYPE_XBOXONE },
Let's use 'Xbox' for new entries instead of 'X-Box'. There was an effort to
standardize on 'Xbox' (which is what Microsoft uses), but changing device
names can impact userspace which may use these names in mapping heuristics
(SDL does this). We can at least not make the problem worse though.
> { 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
> { 0x046d, 0xc21e, "Logitech Gamepad F510", 0, XTYPE_XBOX360 },
> { 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
> @@ -862,6 +864,8 @@ static void xpadone_process_packet(struct usb_xpad *xpad,
> u16 cmd, unsigned char
> /* menu/view buttons */
> input_report_key(dev, BTN_START, data[4] & 0x04);
> input_report_key(dev, BTN_SELECT, data[4] & 0x08);
> + if (xpad->mapping & MAP_SHARE_BUTTON)
> + input_report_key(dev, KEY_RECORD, data[22] & 0x01);
>
I was worried adding a button to an existing supported gamepad like this
might cause a breaking change to SDL's gamepad mapping for this gamepad,
since SDL assigns each present button an index rather than using the keycodes
directly (adding a new one could change the old indices). Fortunately, SDL
always processes buttons in the BTN_GAMEPAD range first, so this new button
ends up at the end of the list anyway.
> /* buttons A,B,X,Y */
> input_report_key(dev, BTN_A,data[4] & 0x10);
> @@ -1669,9 +1673,12 @@ static int xpad_init_input(struct usb_xpad *xpad)
>
> /* set up model-specific ones */
> if (xpad->xtype == XTYPE_XBOX360 || xpad->xtype == XTYPE_XBOX360W ||
> - xpad->xtype == XTYPE_XBOXONE) {
> + xpad->xtype == XTYPE_XBOXONE) {
> for (i = 0; xpad360_btn[i] >= 0; i++)
> input_set_capability(input_dev, EV_KEY, xpad360_btn[i]);
> + if (xpad->mapping & MAP_SHARE_BUTTON) {
> + input_set_capability(input_dev, EV_KEY, KEY_RECORD);
> + }
Style nit: Drop the uneeded {} here
> } else {
> for (i = 0; xpad_btn[i] >= 0; i++)
> input_set_capability(input_dev, EV_KEY, xpad_btn[i]);
>
LGTM, other than the minor changes suggested above.
Regards,
Cameron
Re: [PATCH v1] xen: ACPI: Get rid of ACPICA message printing
On 2/24/21 1:47 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The ACPI_DEBUG_PRINT() macro is used in a few places in > xen-acpi-cpuhotplug.c and xen-acpi-memhotplug.c for printing debug > messages, but that is questionable, because that macro belongs to > ACPICA and it should not be used elsewhere. In addition, > ACPI_DEBUG_PRINT() requires special enabling to allow it to actually > print the message and the _COMPONENT symbol generally needed for > that is not defined in any of the files in question. > > For this reason, replace all of the ACPI_DEBUG_PRINT() instances in > the Xen code with acpi_handle_debug() (with the additional benefit > that the source object can be identified more easily after this > change) and drop the ACPI_MODULE_NAME() definitions that are only > used by the ACPICA message printing macros from that code. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/xen/xen-acpi-cpuhotplug.c | 12 +--- > drivers/xen/xen-acpi-memhotplug.c | 16 +++- As I was building with this patch I (re-)discovered that since 2013 it depends on BROKEN (commit 76fc253723add). Despite commit message there saying that it's a temporary patch it seems to me by now that it's more than that. And clearly noone tried to build these files since at least 2015 because memhotplug file doesn't compile due to commit cfafae940381207. While this is easily fixable the question is whether we want to keep these files. Obviously noone cares about this functionality. -boris
Re: [PATCH] Input: Add "Share" button to Microsoft Xbox One controller.
On 2/25/21 12:26 AM, Dmitry Torokhov wrote:
> On Wed, Feb 24, 2021 at 08:44:37PM -0800, Chris Ye wrote:
>> Hi Dmitry,
>> The latest Xbox One X series has this button, I can add a new
>> XTYPE_XBOXONE_X and only apply the change to the new type.
>
> Sounds good to me. Cameron, what do you think?
>
I'm not sure if some wires got crossed, but I see v2 uses MAP_SHARE_BUTTON
rather than a new XTYPE. I'm fine with either.
>> The controller supports bluetooth and the HID usage for this button is
>> consumer 0xB2:
>> 0x05, 0x0C,// Usage Page (Consumer)
>> 0x0A, 0xB2, 0x00, // Usage (Record)
>
> I see, thank you.
>
Regards,
Cameron
>>
>> Thanks!
>> Chris
>>
>> On Wed, Feb 24, 2021 at 8:33 PM Dmitry Torokhov
>> wrote:
>>>
>>> Hi Chris,
>>>
>>> On Thu, Feb 25, 2021 at 04:00:32AM +, Chris Ye wrote:
Add "Share" button input capability and input event mapping for
Microsoft Xbox One controller.
Fixed Microsoft Xbox One controller share button not working under USB
connection.
Signed-off-by: Chris Ye
---
drivers/input/joystick/xpad.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 9f0d07dcbf06..08c3e93ccb2f 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -368,6 +368,14 @@ static const signed short xpad360_btn[] = { /*
buttons for x360 controller */
-1
};
+static const signed short xpad_xboxone_btn[] = {
+ /* buttons for xbox one controller */
+ BTN_TL, BTN_TR, /* Button LB/RB */
+ BTN_MODE, /* The big X button */
+ KEY_RECORD, /* The share button */
>>>
>>> If I understand this correctly, not all Xbox One controllers have this
>>> new key. Is it possible to determine if it is present and only set
>>> capability for controllers that actually have it?
>>>
>>> Also, I am unsure if KEY_RECORD is the best keycode for this. It might,
>>> but does your controller supports bluetooth? What HID usage code does it
>>> send for this key?
>>>
>>> Thanks.
>>>
>>> --
>>> Dmitry
>
[PATCH] cpufreq: qcom-hw: fix dereferencing freed memory 'data'
Commit 67fc209b527d ("cpufreq: qcom-hw: drop devm_xxx() calls from
init/exit hooks") introduces an issue of dereferencing freed memory
'data'. Fix it.
Fixes: 67fc209b527d ("cpufreq: qcom-hw: drop devm_xxx() calls from init/exit
hooks")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Shawn Guo
---
Viresh,
The issue was introduced by v2 of "cpufreq: qcom-hw: drop devm_xxx()
calls from init/exit hooks", which misses the conversion of 'data->base'
in error path. Sorry!
Shawn
drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index d3c23447b892..bee5d67a8227 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -374,7 +374,7 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
error:
kfree(data);
unmap_base:
- iounmap(data->base);
+ iounmap(base);
release_region:
release_mem_region(res->start, resource_size(res));
return ret;
--
2.17.1
[PATCH 1/5] HID: Recognize sensors with application collections too.
According to HUTRR39 logical sensor devices may be nested inside
physical collections or may be specified in multiple top-level
application collections (see page 59, strategies 1 and 2). However,
the current code was only recognizing those with physical collections.
This issue turned up in recent MacBook Pro's which define the ALS in
a top-level application collection.
Signed-off-by: Ronald Tschalär
---
drivers/hid/hid-core.c | 3 ++-
drivers/hid/hid-sensor-hub.c | 6 --
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 56172fe6995cd..a96b252f97366 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -799,7 +799,8 @@ static void hid_scan_collection(struct hid_parser *parser,
unsigned type)
int i;
if (((parser->global.usage_page << 16) == HID_UP_SENSOR) &&
- type == HID_COLLECTION_PHYSICAL)
+ (type == HID_COLLECTION_PHYSICAL ||
+type == HID_COLLECTION_APPLICATION))
hid->group = HID_GROUP_SENSOR_HUB;
if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 3dd7d32467378..9aea558407794 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -393,7 +393,8 @@ int sensor_hub_input_get_attribute_info(struct
hid_sensor_hub_device *hsdev,
for (i = 0; i < report->maxfield; ++i) {
field = report->field[i];
if (field->maxusage) {
- if (field->physical == usage_id &&
+ if ((field->physical == usage_id ||
+field->application == usage_id) &&
(field->logical == attr_usage_id ||
field->usage[0].hid ==
attr_usage_id) &&
@@ -502,7 +503,8 @@ static int sensor_hub_raw_event(struct hid_device *hdev,
collection->usage);
callback = sensor_hub_get_callback(hdev,
- report->field[i]->physical,
+ report->field[i]->physical ?:
+ report->field[i]->application,
report->field[i]->usage[0].collection_index,
, );
if (!callback) {
--
2.26.2
[PATCH 4/5] HID: apple-ibridge: Add Apple iBridge HID driver for T1 chip.
The iBridge device provides access to several devices, including: - the Touch Bar - the iSight webcam - the light sensor - the fingerprint sensor This driver provides the core support for managing the iBridge device and the access to the underlying devices. In particular, the functionality for the touch bar and light sensor is exposed via USB HID interfaces, and on devices with the T1 chip one of the HID devices is used for both functions. So this driver creates virtual HID devices, one per top-level report collection on each HID device (for a total of 3 virtual HID devices). The sub-drivers then bind to these virtual HID devices. This way the Touch Bar and ALS drivers can be kept in their own modules, while at the same time making them look very much like as if they were connected to the real HID devices. And those drivers then work (mostly) without further changes on MacBooks with the T2 chip that don't need this driver. Signed-off-by: Ronald Tschalär --- drivers/hid/Kconfig | 16 + drivers/hid/Makefile| 1 + drivers/hid/apple-ibridge.c | 682 drivers/hid/apple-ibridge.h | 15 + drivers/hid/hid-ids.h | 1 + drivers/hid/hid-quirks.c| 3 + 6 files changed, 718 insertions(+) create mode 100644 drivers/hid/apple-ibridge.c create mode 100644 drivers/hid/apple-ibridge.h diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 09fa75a2b289e..579c45c3e36e5 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -136,6 +136,22 @@ config HID_APPLE Say Y here if you want support for keyboards of Apple iBooks, PowerBooks, MacBooks, MacBook Pros and Apple Aluminum. +config HID_APPLE_IBRIDGE + tristate "Apple iBridge" + depends on ACPI + depends on USB_HID + depends on X86 || COMPILE_TEST + imply HID_SENSOR_HUB + imply HID_SENSOR_ALS + help + This module provides the core support for the Apple T1 chip found + on 2016 and 2017 MacBookPro's, also known as the iBridge. The drivers + for the Touch Bar (apple-touchbar) and light sensor (hid-sensor-hub + and hid-sensor-als) need to be enabled separately. + + To compile this driver as a module, choose M here: the + module will be called apple-ibridge. + config HID_APPLEIR tristate "Apple infrared receiver" depends on (USB_HID) diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 014d21fe7dac6..d29a3934bfaa9 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_HID_ACCUTOUCH) += hid-accutouch.o obj-$(CONFIG_HID_ALPS) += hid-alps.o obj-$(CONFIG_HID_ACRUX)+= hid-axff.o obj-$(CONFIG_HID_APPLE)+= hid-apple.o +obj-$(CONFIG_HID_APPLE_IBRIDGE)+= apple-ibridge.o obj-$(CONFIG_HID_APPLEIR) += hid-appleir.o obj-$(CONFIG_HID_CREATIVE_SB0540) += hid-creative-sb0540.o obj-$(CONFIG_HID_ASUS) += hid-asus.o diff --git a/drivers/hid/apple-ibridge.c b/drivers/hid/apple-ibridge.c new file mode 100644 index 0..5f2b71c199746 --- /dev/null +++ b/drivers/hid/apple-ibridge.c @@ -0,0 +1,682 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Apple iBridge Driver + * + * Copyright (c) 2018 Ronald Tschalär + */ + +/** + * DOC: Overview + * + * 2016 and 2017 MacBookPro models with a Touch Bar (MacBookPro13,[23] and + * MacBookPro14,[23]) have an Apple iBridge chip (also known as T1 chip) which + * exposes the touch bar, built-in webcam (iSight), ambient light sensor, and + * Secure Enclave Processor (SEP) for TouchID. It shows up in the system as a + * USB device with 3 configurations: 'Default iBridge Interfaces', 'Default + * iBridge Interfaces(OS X)', and 'Default iBridge Interfaces(Recovery)'. + * + * In the first (default after boot) configuration, 4 usb interfaces are + * exposed: 2 related to the webcam, and 2 USB HID interfaces representing + * the touch bar and the ambient light sensor. The webcam interfaces are + * already handled by the uvcvideo driver. However, there is a problem with + * the other two interfaces: one of them contains functionality (HID reports) + * used by both the touch bar and the ALS, which is an issue because the kernel + * allows only one driver to be attached to a given device. This driver exists + * to solve this issue. + * + * This driver is implemented as a HID driver that attaches to both HID + * interfaces and in turn creates several virtual child HID devices, one for + * each top-level collection found in each interfaces report descriptor. The + * touch bar and ALS drivers then attach to these virtual HID devices, and this + * driver forwards the operations between the real and virtual devices. + * + * One important aspect of this approach is that resulting (virtual) HID + * devices look much like the HID devices found on the later MacBookPro models + * which have a T2 chip, where there are separate USB interfaces for the
[PATCH 5/5] HID: apple-touchbar - Add driver for the Touch Bar on MacBook Pro's.
This driver enables basic touch bar functionality: enabling it, switching between modes on FN key press, and dimming and turning the display off/on when idle/active. Signed-off-by: Ronald Tschalär --- drivers/hid/Kconfig | 10 + drivers/hid/Makefile |1 + drivers/hid/apple-touchbar.c | 1523 ++ 3 files changed, 1534 insertions(+) create mode 100644 drivers/hid/apple-touchbar.c diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 579c45c3e36e5..1609a60d65cc3 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -141,6 +141,7 @@ config HID_APPLE_IBRIDGE depends on ACPI depends on USB_HID depends on X86 || COMPILE_TEST + imply HID_APPLE_TOUCHBAR imply HID_SENSOR_HUB imply HID_SENSOR_ALS help @@ -152,6 +153,15 @@ config HID_APPLE_IBRIDGE To compile this driver as a module, choose M here: the module will be called apple-ibridge. +config HID_APPLE_TOUCHBAR + tristate "Apple Touch Bar" + help + Say Y here if you want support for the Touch Bar on recent + MacBook Pros. + + To compile this driver as a module, choose M here: the + module will be called apple-touchbar. + config HID_APPLEIR tristate "Apple infrared receiver" depends on (USB_HID) diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index d29a3934bfaa9..b82a8256785da 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_HID_ALPS)+= hid-alps.o obj-$(CONFIG_HID_ACRUX)+= hid-axff.o obj-$(CONFIG_HID_APPLE)+= hid-apple.o obj-$(CONFIG_HID_APPLE_IBRIDGE)+= apple-ibridge.o +obj-$(CONFIG_HID_APPLE_TOUCHBAR) += apple-touchbar.o obj-$(CONFIG_HID_APPLEIR) += hid-appleir.o obj-$(CONFIG_HID_CREATIVE_SB0540) += hid-creative-sb0540.o obj-$(CONFIG_HID_ASUS) += hid-asus.o diff --git a/drivers/hid/apple-touchbar.c b/drivers/hid/apple-touchbar.c new file mode 100644 index 0..87cb9ebafb615 --- /dev/null +++ b/drivers/hid/apple-touchbar.c @@ -0,0 +1,1523 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Apple Touch Bar Driver + * + * Copyright (c) 2017-2018 Ronald Tschalär + */ + +/* + * Recent MacBookPro models (MacBookPro 13,[23] and later) have a touch bar, + * which is exposed via several USB interfaces. MacOS supports a fancy mode + * where arbitrary buttons can be defined; this driver currently only + * supports the simple mode that consists of 3 predefined layouts + * (escape-only, esc + special keys, and esc + function keys). + * + * The first USB HID interface supports two reports, an input report that + * is used to report the key presses, and an output report which can be + * used to set the touch bar "mode": touch bar off (in which case no touches + * are reported at all), escape key only, escape + 12 function keys, and + * escape + several special keys (including brightness, audio volume, + * etc). The second interface supports several, complex reports, most of + * which are unknown at this time, but one of which has been determined to + * allow for controlling of the touch bar's brightness: off (though touches + * are still reported), dimmed, and full brightness. This driver makes + * use of these two reports. + */ + +#define dev_fmt(fmt) "tb: " fmt + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "hid-ids.h" +#include "apple-ibridge.h" + +#define HID_UP_APPLE 0xff12 +#define HID_USAGE_MODE (HID_UP_CUSTOM | 0x0004) +#define HID_USAGE_APPLE_APP(HID_UP_APPLE | 0x0001) +#define HID_USAGE_DISP (HID_UP_APPLE | 0x0021) +#define HID_USAGE_DISP_AUX1(HID_UP_APPLE | 0x0020) + +#define APPLETB_MAX_TB_KEYS13 /* ESC, F1-F12 */ + +#define APPLETB_CMD_MODE_ESC 0 +#define APPLETB_CMD_MODE_FN1 +#define APPLETB_CMD_MODE_SPCL 2 +#define APPLETB_CMD_MODE_OFF 3 +#define APPLETB_CMD_MODE_UPD 254 +#define APPLETB_CMD_MODE_NONE 255 + +#define APPLETB_CMD_DISP_ON1 +#define APPLETB_CMD_DISP_DIM 2 +#define APPLETB_CMD_DISP_OFF 4 +#define APPLETB_CMD_DISP_UPD 254 +#define APPLETB_CMD_DISP_NONE 255 + +#define APPLETB_FN_MODE_FKEYS 0 +#define APPLETB_FN_MODE_NORM 1 +#define APPLETB_FN_MODE_INV2 +#define APPLETB_FN_MODE_SPCL 3 +#define APPLETB_FN_MODE_ESC4 +#define APPLETB_FN_MODE_MAXAPPLETB_FN_MODE_ESC + +#define APPLETB_DEVID_KEYBOARD 1 +#define APPLETB_DEVID_TOUCHPAD 2 + +#define APPLETB_MAX_DIM_TIME 30 + +#define APPLETB_FEATURE_IS_T1 BIT(0) + +static int appletb_tb_def_idle_timeout = 5 * 60; +module_param_named(idle_timeout, appletb_tb_def_idle_timeout, int, 0444); +MODULE_PARM_DESC(idle_timeout, "Default touch bar idle timeout:\n" + "[>0] - turn touch bar display off after no keyboard, trackpad, or touch bar input has
[PATCH 3/5] HID: core: Export some report item parsing functions.
These are useful to drivers that need to scan or parse reports
themselves.
Signed-off-by: Ronald Tschalär
---
drivers/hid/hid-core.c | 54 +-
include/linux/hid.h| 4
2 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index a96b252f97366..b4c3d71a0ddda 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -340,7 +340,7 @@ static int hid_add_field(struct hid_parser *parser,
unsigned report_type, unsign
* Read data value from item.
*/
-static u32 item_udata(struct hid_item *item)
+u32 hid_item_udata(struct hid_item *item)
{
switch (item->size) {
case 1: return item->data.u8;
@@ -349,8 +349,9 @@ static u32 item_udata(struct hid_item *item)
}
return 0;
}
+EXPORT_SYMBOL_GPL(hid_item_udata);
-static s32 item_sdata(struct hid_item *item)
+s32 hid_item_sdata(struct hid_item *item)
{
switch (item->size) {
case 1: return item->data.s8;
@@ -359,6 +360,7 @@ static s32 item_sdata(struct hid_item *item)
}
return 0;
}
+EXPORT_SYMBOL_GPL(hid_item_sdata);
/*
* Process a global item.
@@ -391,29 +393,29 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG_USAGE_PAGE:
- parser->global.usage_page = item_udata(item);
+ parser->global.usage_page = hid_item_udata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_LOGICAL_MINIMUM:
- parser->global.logical_minimum = item_sdata(item);
+ parser->global.logical_minimum = hid_item_sdata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_LOGICAL_MAXIMUM:
if (parser->global.logical_minimum < 0)
- parser->global.logical_maximum = item_sdata(item);
+ parser->global.logical_maximum = hid_item_sdata(item);
else
- parser->global.logical_maximum = item_udata(item);
+ parser->global.logical_maximum = hid_item_udata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_PHYSICAL_MINIMUM:
- parser->global.physical_minimum = item_sdata(item);
+ parser->global.physical_minimum = hid_item_sdata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_PHYSICAL_MAXIMUM:
if (parser->global.physical_minimum < 0)
- parser->global.physical_maximum = item_sdata(item);
+ parser->global.physical_maximum = hid_item_sdata(item);
else
- parser->global.physical_maximum = item_udata(item);
+ parser->global.physical_maximum = hid_item_udata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_UNIT_EXPONENT:
@@ -421,7 +423,7 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
* nibble due to the common misunderstanding of HID
* specification 1.11, 6.2.2.7 Global Items. Attempt to handle
* both this and the standard encoding. */
- raw_value = item_sdata(item);
+ raw_value = hid_item_sdata(item);
if (!(raw_value & 0xfff0))
parser->global.unit_exponent = hid_snto32(raw_value, 4);
else
@@ -429,11 +431,11 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG_UNIT:
- parser->global.unit = item_udata(item);
+ parser->global.unit = hid_item_udata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
- parser->global.report_size = item_udata(item);
+ parser->global.report_size = hid_item_udata(item);
if (parser->global.report_size > 256) {
hid_err(parser->device, "invalid report_size %d\n",
parser->global.report_size);
@@ -442,7 +444,7 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG_REPORT_COUNT:
- parser->global.report_count = item_udata(item);
+ parser->global.report_count = hid_item_udata(item);
if (parser->global.report_count > HID_MAX_USAGES) {
hid_err(parser->device, "invalid report_count %d\n",
parser->global.report_count);
@@ -451,7 +453,7 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG_REPORT_ID:
- parser->global.report_id = item_udata(item);
+ parser->global.report_id = hid_item_udata(item);
[PATCH 2/5] iio: hid-sensor-als: Support change sensitivity in illuminance too.
Recent MacBook Pro's specify the usage of the change sensitivity field as illuminance (with a change sensitivity modifier) rather than as light. Signed-off-by: Ronald Tschalär --- drivers/iio/light/hid-sensor-als.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c index a21c827e4953d..849ee37dcd866 100644 --- a/drivers/iio/light/hid-sensor-als.c +++ b/drivers/iio/light/hid-sensor-als.c @@ -252,6 +252,14 @@ static int als_parse_report(struct platform_device *pdev, HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS | HID_USAGE_SENSOR_DATA_LIGHT, >common_attributes.sensitivity); + + if (st->common_attributes.sensitivity.index < 0) + sensor_hub_input_get_attribute_info(hsdev, + HID_FEATURE_REPORT, usage_id, + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS | + HID_USAGE_SENSOR_LIGHT_ILLUM, + >common_attributes.sensitivity); + dev_dbg(>dev, "Sensitivity index:report %d:%d\n", st->common_attributes.sensitivity.index, st->common_attributes.sensitivity.report_id); -- 2.26.2
[PATCH 0/5] Touch Bar and ALS support for MacBook Pro's
This patch set provides Touch Bar and ALS support on MacBook Pro's 13,*, 14,*, and 15,*. Some time a go an earlier version of these were posted to the list; all code comments from there have been incorporated. In addition the approach has been cleaned up, especially given that we now know how the 15,* models are implemented, so that the ibridge driver is only needed for the pre-15,* models and the ALS and Touch Bar drivers work unchanged for all models. Ronald Tschalär (5): HID: Recognize sensors with application collections too. iio: hid-sensor-als: Support change sensitivity in illuminance too. HID: core: Export some report item parsing functions. HID: apple-ibridge: Add Apple iBridge HID driver for T1 chip. HID: apple-touchbar - Add driver for the Touch Bar on MacBook Pro's. drivers/hid/Kconfig| 26 + drivers/hid/Makefile |2 + drivers/hid/apple-ibridge.c| 682 + drivers/hid/apple-ibridge.h| 15 + drivers/hid/apple-touchbar.c | 1523 drivers/hid/hid-core.c | 57 +- drivers/hid/hid-ids.h |1 + drivers/hid/hid-quirks.c |3 + drivers/hid/hid-sensor-hub.c |6 +- drivers/iio/light/hid-sensor-als.c |8 + include/linux/hid.h|4 + 11 files changed, 2302 insertions(+), 25 deletions(-) create mode 100644 drivers/hid/apple-ibridge.c create mode 100644 drivers/hid/apple-ibridge.h create mode 100644 drivers/hid/apple-touchbar.c -- 2.26.2
Re: [PATCH] kbuild: Fix for empty SUBLEVEL or PATCHLEVEL again
On Sat, Feb 27, 2021 at 11:20:23PM +0900, Masahiro Yamada wrote:
Commit 9b82f13e7ef3 ("kbuild: clamp SUBLEVEL to 255") breaks the build
if SUBLEVEL or PATCHLEVEL is empty.
Commit 78d3bb4483ba ("kbuild: Fix for empty SUBLEVEL
or PATCHLEVEL") fixed the issue by prepending a zero.
This time, we cannot take the same approach because we have C code:
#define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL)
#define LINUX_VERSION_SUBLEVEL $(SUBLEVEL)
Replace empty SUBLEVEL or PATCHLEVEL with a zero.
Fixes: 9b82f13e7ef3 ("kbuild: clamp SUBLEVEL to 255")
Reported-by: Christian Zigotzky
Signed-off-by: Masahiro Yamada
Reviewed-and-tested-by: Sasha Levin
Thank you!
--
Thanks,
Sasha
Re: drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: we previously assumed 'data' could be null (see line 327)
On Sat, Feb 27, 2021 at 12:26:20PM +0300, Dan Carpenter wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 8b83369ddcb3fb9cab5c1088987ce477565bb630 > commit: 67fc209b527d023db4d087c68e44e9790aa089ef cpufreq: qcom-hw: drop > devm_xxx() calls from init/exit hooks > config: arm64-randconfig-m031-20210226 (attached as .config) > compiler: aarch64-linux-gcc (GCC) 9.3.0 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > Reported-by: Dan Carpenter > > smatch warnings: > drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: we > previously assumed 'data' could be null (see line 327) > drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: > dereferencing freed memory 'data' Thanks for the report! I will send a fix for it right away. Shawn
Re: INFO: task hung in switchdev_deferred_process_work (2)
syzbot has found a reproducer for the following issue on: HEAD commit:5695e516 Merge tag 'io_uring-worker.v3-2021-02-25' of git:.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=135da5cad0 kernel config: https://syzkaller.appspot.com/x/.config?x=8c76dad0946df1f3 dashboard link: https://syzkaller.appspot.com/bug?extid=8ecc009e206a956ab317 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15aaeff2d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16fbcb6cd0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+8ecc009e206a956ab...@syzkaller.appspotmail.com INFO: task kworker/1:0:8387 blocked for more than 143 seconds. Not tainted 5.11.0-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:0 state:D stack:25896 pid: 8387 ppid: 2 flags:0x4000 Workqueue: events switchdev_deferred_process_work Call Trace: context_switch kernel/sched/core.c:4324 [inline] __schedule+0x90c/0x21a0 kernel/sched/core.c:5075 schedule+0xcf/0x270 kernel/sched/core.c:5154 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:5213 __mutex_lock_common kernel/locking/mutex.c:1023 [inline] __mutex_lock+0x81f/0x1120 kernel/locking/mutex.c:1093 switchdev_deferred_process_work+0xa/0x20 net/switchdev/switchdev.c:74 process_one_work+0x98d/0x1600 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 INFO: task kworker/1:6:9697 blocked for more than 143 seconds. Not tainted 5.11.0-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:6 state:D stack:25688 pid: 9697 ppid: 2 flags:0x4000 Workqueue: events rfkill_global_led_trigger_worker Call Trace: context_switch kernel/sched/core.c:4324 [inline] __schedule+0x90c/0x21a0 kernel/sched/core.c:5075 schedule+0xcf/0x270 kernel/sched/core.c:5154 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:5213 __mutex_lock_common kernel/locking/mutex.c:1023 [inline] __mutex_lock+0x81f/0x1120 kernel/locking/mutex.c:1093 rfkill_global_led_trigger_worker+0x17/0x110 net/rfkill/core.c:180 process_one_work+0x98d/0x1600 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 INFO: task syz-executor417:12942 blocked for more than 143 seconds. Not tainted 5.11.0-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor417 state:D stack:23856 pid:12942 ppid: 12792 flags:0x Call Trace: context_switch kernel/sched/core.c:4324 [inline] __schedule+0x90c/0x21a0 kernel/sched/core.c:5075 schedule+0xcf/0x270 kernel/sched/core.c:5154 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:5213 __mutex_lock_common kernel/locking/mutex.c:1023 [inline] __mutex_lock+0x81f/0x1120 kernel/locking/mutex.c:1093 rtnl_lock net/core/rtnetlink.c:72 [inline] rtnetlink_rcv_msg+0x3f9/0xad0 net/core/rtnetlink.c:5550 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 __sys_sendto+0x21c/0x320 net/socket.c:1977 __do_sys_sendto net/socket.c:1989 [inline] __se_sys_sendto net/socket.c:1985 [inline] __x64_sys_sendto+0xdd/0x1b0 net/socket.c:1985 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x40c6dc RSP: 002b:005ffdf0 EFLAGS: 0293 ORIG_RAX: 002c RAX: ffda RBX: 00601080 RCX: 0040c6dc RDX: 0020 RSI: 006010d0 RDI: 0004 RBP: R08: 005ffe44 R09: 000c R10: R11: 0293 R12: 005fff10 R13: 006010d0 R14: 0004 R15: INFO: task kworker/0:28:21057 blocked for more than 144 seconds. Not tainted 5.11.0-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/0:28state:D stack:27096 pid:21057 ppid: 2 flags:0x4000 Workqueue: ipv6_addrconf addrconf_dad_work Call Trace: context_switch kernel/sched/core.c:4324 [inline] __schedule+0x90c/0x21a0 kernel/sched/core.c:5075 schedule+0xcf/0x270 kernel/sched/core.c:5154 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:5213 __mutex_lock_common kernel/locking/mutex.c:1023 [inline] __mutex_lock+0x81f/0x1120 kernel/locking/mutex.c:1093 addrconf_dad_work+0xa3/0x12b0 net/ipv6/addrconf.c:4031 process_one_work+0x98d/0x1600 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120
[PATCH] staging: rtl8192u avoid flex array of flex array
Undo the flex array in struct ieee80211_info_element. It is used as the flex
array type in other structs (creating a flex array of flex arrays) making
sparse unhappy. This change maintains the intent of the code and satisfies
sparse.
Signed-off-by: Darryl T. Agostinelli
---
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 39f4ddd86796..43bb7aeb35e3 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -951,7 +951,7 @@ struct rtl_80211_hdr_4addrqos {
struct ieee80211_info_element {
u8 id;
u8 len;
- u8 data[];
+ u8 data[0];
} __packed;
struct ieee80211_authentication {
--
2.29.2
[PATCH V2] fs: dlm: Spellings fixed throughout the file lock.c
Few spelling fixes throughout the file. Signed-off-by: Bhaskar Chowdhury --- Changes from V1: Fixed the subject line typo. Measured unwanted blank lines insertion. fs/dlm/lock.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 002123efc6b0..b1c36ed5 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -91,7 +91,7 @@ static void del_timeout(struct dlm_lkb *lkb); static void toss_rsb(struct kref *kref); /* - * Lock compatibilty matrix - thanks Steve + * Lock compatibility matrix - thanks Steve * UN = Unlocked state. Not really a state, used as a flag * PD = Padding. Used to make the matrix a nice power of two in size * Other states are the same as the VMS DLM. @@ -2357,14 +2357,14 @@ static int _can_be_granted(struct dlm_rsb *r, struct dlm_lkb *lkb, int now, * 6-5: But the default algorithm for deciding whether to grant or * queue conversion requests does not by itself guarantee that such * requests are serviced on a "first come first serve" basis. This, in -* turn, can lead to a phenomenon known as "indefinate postponement". +* turn, can lead to a phenomenon known as "indefinite postponement". * * 6-7: This issue is dealt with by using the optional QUECVT flag with * the system service employed to request a lock conversion. This flag * forces certain conversion requests to be queued, even if they are * compatible with the granted modes of other locks on the same * resource. Thus, the use of this flag results in conversion requests -* being ordered on a "first come first servce" basis. +* being ordered on a "first come first serve" basis. * * DCT: This condition is all about new conversions being able to occur * "in place" while the lock remains on the granted queue (assuming -- 2.26.2
linux-next: Fixes tag needs some work in the netfilter tree
Hi all,
In commit
8e24edddad15 ("netfilter: x_tables: gpf inside xt_find_revision()")
Fixes tag
Fixes: 656caff20e1 ("netfilter 04/09: x_tables: fix match/target revision
lookup")
has these problem(s):
- SHA1 should be at least 12 digits long
I don't think it is worth rebasing to fix this, but it can be fixed for
future commits by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
pgpz_fModZMKL.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
Hi,
2021年2月12日(金) 21:10 Sai Krishna Potthuri
:
>
> Adding pinctrl driver for Xilinx ZynqMP platform.
> This driver queries pin information from firmware and registers
> pin control accordingly.
>
> Signed-off-by: Sai Krishna Potthuri
> ---
> drivers/pinctrl/Kconfig | 13 +
> drivers/pinctrl/Makefile |1 +
> drivers/pinctrl/pinctrl-zynqmp.c | 1031 ++
> 3 files changed, 1045 insertions(+)
> create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
>
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 815095326e2d..25d3c7208975 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
> help
> This selects the pinctrl driver for Xilinx Zynq.
>
> +config PINCTRL_ZYNQMP
> + bool "Pinctrl driver for Xilinx ZynqMP"
> + depends on ARCH_ZYNQMP
> + select PINMUX
> + select GENERIC_PINCONF
> + help
> + This selects the pinctrl driver for Xilinx ZynqMP platform.
> + This driver will query the pin information from the firmware
> + and allow configuring the pins.
> + Configuration can include the mux function to select on those
> + pin(s)/group(s), and various pin configuration parameters
> + such as pull-up, slew rate, etc.
> +
> config PINCTRL_INGENIC
> bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
> default MACH_INGENIC
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index f53933b2ff02..7e058739f0d5 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X) += pinctrl-tb10x.o
> obj-$(CONFIG_PINCTRL_ST) += pinctrl-st.o
> obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
> obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
> +obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
> obj-$(CONFIG_PINCTRL_INGENIC) += pinctrl-ingenic.o
> obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
> obj-$(CONFIG_PINCTRL_OCELOT) += pinctrl-ocelot.o
> diff --git a/drivers/pinctrl/pinctrl-zynqmp.c
> b/drivers/pinctrl/pinctrl-zynqmp.c
> new file mode 100644
> index ..ec0a5d0e22d5
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-zynqmp.c
> @@ -0,0 +1,1031 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ZynqMP pin controller
> + *
> + * Copyright (C) 2020 Xilinx, Inc.
> + *
> + * Sai Krishna Potthuri
> + * Rajan Vaja
> + */
> +/**
> + * zynqmp_pinctrl_get_function_name() - get function name
> + * @fid: Function ID.
> + * @name: Function name
> + *
> + * Call firmware API to get name of given function.
> + *
> + * Return: 0 on success else error code.
> + */
> +static int zynqmp_pinctrl_get_function_name(u32 fid, char *name)
> +{
> + struct zynqmp_pm_query_data qdata = {0};
> + u32 ret_payload[PAYLOAD_ARG_CNT];
> +
> + qdata.qid = PM_QID_PINCTRL_GET_FUNCTION_NAME;
> + qdata.arg1 = fid;
> +
> + zynqmp_pm_query_data(qdata, ret_payload);
Please check the return value here as well as other functions.
I know that when we used zynqmp_pm_query_data with
PM_QID_PINCTRL_GET_FUNCTION_NAME,
it returns -22 error code.
How about adding processing with zynqmp_pm_query_data like
PM_QID_CLOCK_GET_NAME or
writing a comment here?
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
Re: possible deadlock in io_poll_double_wake (2)
syzbot has found a reproducer for the following issue on:
HEAD commit:5695e516 Merge tag 'io_uring-worker.v3-2021-02-25' of git:..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=114e3866d0
kernel config: https://syzkaller.appspot.com/x/.config?x=8c76dad0946df1f3
dashboard link: https://syzkaller.appspot.com/bug?extid=28abd693db9e92c160d8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=122ed9b6d0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14d5a292d0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+28abd693db9e92c16...@syzkaller.appspotmail.com
WARNING: possible recursive locking detected
5.11.0-syzkaller #0 Not tainted
swapper/1/0 is trying to acquire lock:
88801b2b1130 (>sleep){..-.}-{2:2}, at: spin_lock
include/linux/spinlock.h:354 [inline]
88801b2b1130 (>sleep){..-.}-{2:2}, at:
io_poll_double_wake+0x25f/0x6a0 fs/io_uring.c:4960
but task is already holding lock:
88801b2b3130 (>sleep){..-.}-{2:2}, at:
__wake_up_common_lock+0xb4/0x130 kernel/sched/wait.c:137
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>sleep);
lock(>sleep);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by swapper/1/0:
#0: 888147474908 (>lock){..-.}-{2:2}, at:
_snd_pcm_stream_lock_irqsave+0x9f/0xd0 sound/core/pcm_native.c:170
#1: 88801b2b3130 (>sleep){..-.}-{2:2}, at:
__wake_up_common_lock+0xb4/0x130 kernel/sched/wait.c:137
stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.11.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0xfa/0x151 lib/dump_stack.c:120
print_deadlock_bug kernel/locking/lockdep.c:2829 [inline]
check_deadlock kernel/locking/lockdep.c:2872 [inline]
validate_chain kernel/locking/lockdep.c:3661 [inline]
__lock_acquire.cold+0x14c/0x3b4 kernel/locking/lockdep.c:4900
lock_acquire kernel/locking/lockdep.c:5510 [inline]
lock_acquire+0x1ab/0x730 kernel/locking/lockdep.c:5475
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:354 [inline]
io_poll_double_wake+0x25f/0x6a0 fs/io_uring.c:4960
__wake_up_common+0x147/0x650 kernel/sched/wait.c:108
__wake_up_common_lock+0xd0/0x130 kernel/sched/wait.c:138
snd_pcm_update_state+0x46a/0x540 sound/core/pcm_lib.c:203
snd_pcm_update_hw_ptr0+0xa75/0x1a50 sound/core/pcm_lib.c:464
snd_pcm_period_elapsed+0x160/0x250 sound/core/pcm_lib.c:1805
dummy_hrtimer_callback+0x94/0x1b0 sound/drivers/dummy.c:378
__run_hrtimer kernel/time/hrtimer.c:1519 [inline]
__hrtimer_run_queues+0x609/0xe40 kernel/time/hrtimer.c:1583
hrtimer_run_softirq+0x17b/0x360 kernel/time/hrtimer.c:1600
__do_softirq+0x29b/0x9f6 kernel/softirq.c:345
invoke_softirq kernel/softirq.c:221 [inline]
__irq_exit_rcu kernel/softirq.c:422 [inline]
irq_exit_rcu+0x134/0x200 kernel/softirq.c:434
sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1100
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632
RIP: 0010:native_save_fl arch/x86/include/asm/irqflags.h:29 [inline]
RIP: 0010:arch_local_save_flags arch/x86/include/asm/irqflags.h:70 [inline]
RIP: 0010:arch_irqs_disabled arch/x86/include/asm/irqflags.h:137 [inline]
RIP: 0010:acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]
RIP: 0010:acpi_idle_do_entry+0x1c9/0x250 drivers/acpi/processor_idle.c:516
Code: dd 38 6e f8 84 db 75 ac e8 54 32 6e f8 e8 0f 1c 74 f8 e9 0c 00 00 00 e8
45 32 6e f8 0f 00 2d 4e 4a c5 00 e8 39 32 6e f8 fb f4 <9c> 5b 81 e3 00 02 00 00
fa 31 ff 48 89 de e8 14 3a 6e f8 48 85 db
RSP: 0018:c9d47d18 EFLAGS: 0293
RAX: RBX: RCX:
RDX: 8880115c3780 RSI: 89052537 RDI:
RBP: 888141127064 R08: 0001 R09: 0001
R10: 81794168 R11: R12: 0001
R13: 888141127000 R14: 888141127064 R15: 888143331804
acpi_idle_enter+0x361/0x500 drivers/acpi/processor_idle.c:647
cpuidle_enter_state+0x1b1/0xc80 drivers/cpuidle/cpuidle.c:237
cpuidle_enter+0x4a/0xa0 drivers/cpuidle/cpuidle.c:351
call_cpuidle kernel/sched/idle.c:158 [inline]
cpuidle_idle_call kernel/sched/idle.c:239 [inline]
do_idle+0x3e1/0x590 kernel/sched/idle.c:300
cpu_startup_entry+0x14/0x20 kernel/sched/idle.c:397
start_secondary+0x274/0x350 arch/x86/kernel/smpboot.c:272
secondary_startup_64_no_verify+0xb0/0xbb
Re: [PATCH RESEND] ide/falconide: Fix module unload
On Sun, 3 Jan 2021, Jens Axboe wrote: > > > > This patch was sent in September and subsequently resent in November. > > I've since learned that the maintainer has been ill. What's the best > > way forward for fixes like this? > > I can queue it up. > That would be great.
Re: [PATCH v3 1/3] firmware: xilinx: Add pinctrl support
Hi,
2021年2月12日(金) 21:10 Sai Krishna Potthuri
:
>
> Adding pinctrl support to query platform specific information (pins)
> from firmware.
>
> Signed-off-by: Sai Krishna Potthuri
> Acked-by: Michal Simek
> ---
> drivers/firmware/xilinx/zynqmp.c | 114 +++
> include/linux/firmware/xlnx-zynqmp.h | 90 +
> 2 files changed, 204 insertions(+)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c
> b/drivers/firmware/xilinx/zynqmp.c
> index efb8a66efc68..299c3d5a9ebd 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
>
> @@ -125,6 +131,12 @@ enum pm_query_id {
> PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
> PM_QID_CLOCK_GET_PARENTS,
> PM_QID_CLOCK_GET_ATTRIBUTES,
> + PM_QID_PINCTRL_GET_NUM_PINS = 6,
> + PM_QID_PINCTRL_GET_NUM_FUNCTIONS = 7,
> + PM_QID_PINCTRL_GET_NUM_FUNCTION_GROUPS = 8,
> + PM_QID_PINCTRL_GET_FUNCTION_NAME = 9,
> + PM_QID_PINCTRL_GET_FUNCTION_GROUPS = 10,
> + PM_QID_PINCTRL_GET_PIN_GROUPS = 11,
These do not have to have values, Because PM_QID_INVALID is 0.
> PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
And you can drop value from this.
> PM_QID_CLOCK_GET_MAX_DIVISOR,
> };
> @@ -288,6 +300,44 @@ enum dll_reset_type {
> PM_DLL_RESET_PULSE,
> };
>
> +enum pm_pinctrl_config_param {
> + PM_PINCTRL_CONFIG_SLEW_RATE = 0,
> + PM_PINCTRL_CONFIG_BIAS_STATUS = 1,
> + PM_PINCTRL_CONFIG_PULL_CTRL = 2,
> + PM_PINCTRL_CONFIG_SCHMITT_CMOS = 3,
> + PM_PINCTRL_CONFIG_DRIVE_STRENGTH = 4,
> + PM_PINCTRL_CONFIG_VOLTAGE_STATUS = 5,
> + PM_PINCTRL_CONFIG_TRI_STATE = 6,
> + PM_PINCTRL_CONFIG_MAX = 7,
> +};
Same as above.
> +
> +enum pm_pinctrl_slew_rate {
> + PM_PINCTRL_SLEW_RATE_FAST = 0,
> + PM_PINCTRL_SLEW_RATE_SLOW = 1,
> +};
Same as above. Others are also specified.
> +
> +enum pm_pinctrl_bias_status {
> + PM_PINCTRL_BIAS_DISABLE = 0,
> + PM_PINCTRL_BIAS_ENABLE = 1,
> +};
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
Re: [PATCH] fs: dlm: Spellings fixed throughout the fle lock.c
On 2/27/21 3:33 PM, Bhaskar Chowdhury wrote: > > Few spelling fixes throughout the file. > in Subject: s/fle/file/ > Signed-off-by: Bhaskar Chowdhury > --- > fs/dlm/lock.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c > index 002123efc6b0..efcd84faca14 100644 > --- a/fs/dlm/lock.c > +++ b/fs/dlm/lock.c > @@ -91,7 +91,7 @@ static void del_timeout(struct dlm_lkb *lkb); > static void toss_rsb(struct kref *kref); > > /* > - * Lock compatibilty matrix - thanks Steve > + * Lock compatibility matrix - thanks Steve > * UN = Unlocked state. Not really a state, used as a flag > * PD = Padding. Used to make the matrix a nice power of two in size > * Other states are the same as the VMS DLM. > @@ -594,7 +594,7 @@ static int find_rsb_dir(struct dlm_ls *ls, char *name, > int len, > error = dlm_search_rsb_tree(>ls_rsbtbl[b].keep, name, len, ); > if (error) > goto do_toss; > - > + stray change? > /* >* rsb is active, so we can't check master_nodeid without lock_rsb. >*/ > @@ -2357,14 +2357,14 @@ static int _can_be_granted(struct dlm_rsb *r, struct > dlm_lkb *lkb, int now, >* 6-5: But the default algorithm for deciding whether to grant or >* queue conversion requests does not by itself guarantee that such >* requests are serviced on a "first come first serve" basis. This, in > - * turn, can lead to a phenomenon known as "indefinate postponement". > + * turn, can lead to a phenomenon known as "indefinite postponement". >* >* 6-7: This issue is dealt with by using the optional QUECVT flag with >* the system service employed to request a lock conversion. This flag >* forces certain conversion requests to be queued, even if they are >* compatible with the granted modes of other locks on the same >* resource. Thus, the use of this flag results in conversion requests > - * being ordered on a "first come first servce" basis. > + * being ordered on a "first come first serve" basis. >* >* DCT: This condition is all about new conversions being able to occur >* "in place" while the lock remains on the granted queue (assuming > @@ -5745,7 +5745,7 @@ int dlm_recover_process_copy(struct dlm_ls *ls, struct > dlm_rcom *rc) > > log_debug(ls, "dlm_recover_process_copy %x remote %d %x %d", > lkid, rc->rc_header.h_nodeid, remid, result); > - > + stray change? > dlm_send_rcom_lock(r, lkb); > goto out; > case -EEXIST: > -- -- ~Randy
Re: [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers from trace events
[ Resending with an address that should work for Felipe ] On Sat, 27 Feb 2021 14:18:02 -0500 Steven Rostedt wrote: > On Fri, 26 Feb 2021 14:21:00 -0800 > Linus Torvalds wrote: > > > On Fri, Feb 26, 2021 at 11:07 AM Steven Rostedt > > wrote: > > > > > > The first patch scans the print fmts of the trace events looking for > > > dereferencing pointers from %p*, and making sure that they refer back > > > to the trace event itself. > > > > > > The second patch handles strings "%s" [..] > > > > Doing this at runtime really feels like the wrong thing to do. > > > > It won't even protect us from what happened - people like me and > > Andrew won't even run those tracepoints in the first place, so we > > won't notice. > > > > It really would be much better in every respect to have this done by > > checkpatch, I think. > > And after fixing the parsing to not trigger false positives, an > allyesconfig boot found this: > > event cdns3_gadget_giveback has unsafe dereference of argument 11 > print_fmt: "%s: req: %p, req buff %p, length: %u/%u %s%s%s, status: %d, trb: > [start:%d, end:%d: virt addr %pa], flags:%x SID: %u", __get_str(name), > REC->req, REC->buf, > REC->actual, REC->length, REC->zero ? "Z" : "z", REC->short_not_ok ? "S" : > "s", REC->no_interrupt ? "I" : "i", REC->status, REC->start_trb, > REC->end_trb, REC->start_trb_addr, REC->flags, RE > C->stream_id > > (as the above is from a trace event class, it triggered for every event > in that class). > > As it looks like it uses %pa which IIUC from the printk code, it > dereferences the pointer to find it's virtual address. The event has > this as the field: > > __field(struct cdns3_trb *, start_trb_addr) > > Assigns it with: > > __entry->start_trb_addr = req->trb; > > And prints that with %pa, which will dereference pointer at the time of > reading, where the address in question may no longer be around. That > looks to me as a potential bug. > > [ Cc'd the people responsible for that code. ] > > -- Steve
kernel/sched/core.c:6854:20: warning: unused function 'balance_hotplug_wait'
Hi Thomas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4
commit: 1cf12e08bc4d50a76b80c42a3109c53d8794a0c9 sched/hotplug: Consolidate
task migration on CPU unplug
date: 4 months ago
config: mips-randconfig-r004-20210228 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
83bc7815c4235786111aa2abf7193292e4a602f5)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1cf12e08bc4d50a76b80c42a3109c53d8794a0c9
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 1cf12e08bc4d50a76b80c42a3109c53d8794a0c9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
kernel/sched/core.c:2376:6: warning: no previous prototype for function
'sched_set_stop_task'
void sched_set_stop_task(int cpu, struct task_struct
^
kernel/sched/core.c:2376:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
void sched_set_stop_task(int cpu, struct task_struct
^
static
kernel/sched/core.c:4196:20: warning: unused function 'sched_tick_stop'
static inline void sched_tick_stop(int cpu) { }
^
>> kernel/sched/core.c:6854:20: warning: unused function 'balance_hotplug_wait'
static inline void balance_hotplug_wait(void)
^
fatal error: error in backend: Nested variants found in inline asm string:
'.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/barrier.h",
.line = 27, $); 0x00 ) != -1)) : $))) ) && ( (1 << 0) ); .set push; .set
mips64r2; .rept 1; sync 0x00; .endr; .set pop; .else; ; .endif'
clang-13: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 13.0.0 (git://gitmirror/llvm_project
83bc7815c4235786111aa2abf7193292e4a602f5)
Target: mipsel-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cross/clang-83bc7815c4/bin
clang-13: note: diagnostic msg:
Makefile arch drivers fs include kernel mm scripts security source usr
vim +/balance_hotplug_wait +6854 kernel/sched/core.c
2558aacff85866 Peter Zijlstra 2020-09-11 6853
f2469a1fb43f85 Thomas Gleixner 2020-09-14 @6854 static inline void
balance_hotplug_wait(void)
f2469a1fb43f85 Thomas Gleixner 2020-09-14 6855 {
f2469a1fb43f85 Thomas Gleixner 2020-09-14 6856 }
f2469a1fb43f85 Thomas Gleixner 2020-09-14 6857
:: The code at line 6854 was first introduced by commit
:: f2469a1fb43f85d243ce72638367fb6e15c33491 sched/core: Wait for tasks
being pushed away on hotplug
:: TO: Thomas Gleixner
:: CC: Peter Zijlstra
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
arch/x86/kvm/mmu/tdp_mmu.c:533:9: sparse: sparse: cast removes address space '__rcu' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 commit: 08f07c800e9d35b59d0c8346333f189160bd67d4 KVM: x86/mmu: Flush TLBs after zap in TDP MMU PF handler date: 3 weeks ago config: x86_64-randconfig-s022-20210228 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-241-geaceeafa-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=08f07c800e9d35b59d0c8346333f189160bd67d4 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 08f07c800e9d35b59d0c8346333f189160bd67d4 # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" arch/x86/kvm/mmu/tdp_mmu.c:459:49: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected unsigned long long [usertype] *pt @@ got unsigned long long [noderef] [usertype] __rcu * @@ arch/x86/kvm/mmu/tdp_mmu.c:459:49: sparse: expected unsigned long long [usertype] *pt arch/x86/kvm/mmu/tdp_mmu.c:459:49: sparse: got unsigned long long [noderef] [usertype] __rcu * arch/x86/kvm/mmu/tdp_mmu.c:291:9: sparse: sparse: context imbalance in 'tdp_mmu_link_page' - different lock contexts for basic block arch/x86/kvm/mmu/tdp_mmu.c:316:9: sparse: sparse: context imbalance in 'tdp_mmu_unlink_page' - different lock contexts for basic block arch/x86/kvm/mmu/tdp_mmu.c:654:51: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected unsigned long long [usertype] *root_pt @@ got unsigned long long [noderef] [usertype] __rcu * @@ arch/x86/kvm/mmu/tdp_mmu.c:654:51: sparse: expected unsigned long long [usertype] *root_pt arch/x86/kvm/mmu/tdp_mmu.c:654:51: sparse: got unsigned long long [noderef] [usertype] __rcu * arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected unsigned long long [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned long long [usertype] *root_pt @@ got unsigned long long [noderef] [usertype] __rcu * @@ arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: expected unsigned long long [usertype] *root_pt arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: got unsigned long long [noderef] [usertype] __rcu * >> arch/x86/kvm/mmu/tdp_mmu.c:533:9: sparse: sparse: cast removes address space >> '__rcu' of expression arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned long long [usertype] *root_pt @@ got unsigned long long [noderef] [usertype] __rcu * @@ arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: expected unsigned long long [usertype] *root_pt arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: got unsigned long long [noderef] [usertype] __rcu * arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned long long [usertype] *root_pt @@ got unsigned long long [noderef] [usertype] __rcu * @@ arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: expected unsigned long long [usertype] *root_pt arch/x86/kvm/mmu/tdp_mmu.c:487:40: sparse: got unsigned long long [noderef] [usertype] __rcu * arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected unsigned long long [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected unsigned long long [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:560:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt
Re: Question about the "EXPERIMENTAL" tag for dax in XFS
On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote: > > On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote: > > On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote: > > > On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote: > > > > On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner > > > > wrote: > > > > > > My immediate concern is the issue Jason recently highlighted [1] > > > > > > with > > > > > > respect to invalidating all dax mappings when / if the device is > > > > > > ripped out from underneath the fs. I don't think that will collide > > > > > > with Ruan's implementation, but it does need new communication from > > > > > > driver to fs about removal events. > > > > > > > > > > > > [1]: > > > > > > http://lore.kernel.org/r/capcyv4i+pzhyziepf2pah0dt5jdfkmkdx-3usqy1fahf6lp...@mail.gmail.com > > > > > > > > > > Oh, yay. > > > > > > > > > > The XFS shutdown code is centred around preventing new IO from being > > > > > issued - we don't actually do anything about DAX mappings because, > > > > > well, I don't think anyone on the filesystem side thought they had > > > > > to do anything special if pmem went away from under it. > > > > > > > > > > My understanding -was- that the pmem removal invalidates > > > > > all the ptes currently mapped into CPU page tables that point at > > > > > the dax device across the system. THe vmas that manage these > > > > > mappings are not really something the filesystem really manages, > > > > > but a function of the mm subsystem. What the filesystem cares about > > > > > is that it gets page faults triggered when a change of state occurs > > > > > so that it can remap the page to it's backing store correctly. > > > > > > > > > > IOWs, all the mm subsystem needs to when pmem goes away is clear the > > > > > CPU ptes, because then when then when userspace tries to access the > > > > > mapped DAX pages we get a new page fault. In processing the fault, the > > > > > filesystem will try to get direct access to the pmem from the block > > > > > device. This will get an ENODEV error from the block device because > > > > > because the backing store (pmem) has been unplugged and is no longer > > > > > there... > > > > > > > > > > AFAICT, as long as pmem removal invalidates all the active ptes that > > > > > point at the pmem being removed, the filesystem doesn't need to > > > > > care about device removal at all, DAX or no DAX... > > > > > > > > How would the pmem removal do that without walking all the active > > > > inodes in the fs at the time of shutdown and call > > > > unmap_mapping_range(inode->i_mapping, 0, 0, 1)? > > > > > > Which then immediately ends up back at the vmas that manage the ptes > > > to unmap them. > > > > > > Isn't finding the vma(s) that map a specific memory range exactly > > > what the rmap code in the mm subsystem is supposed to address? > > > > rmap can lookup only vmas from a virt address relative to a given > > mm_struct. The driver has neither the list of mm_struct objects nor > > virt addresses to do a lookup. All it knows is that someone might have > > mapped pages through the fsdax interface. > > So there's no physical addr to vma translation in the mm subsystem > at all? > > That doesn't make sense. We do exactly this for hwpoison for DAX > mappings. While we don't look at ptes, we get a pfn, True hwpoison does get a known failing pfn and then uses page->mapping to get the 'struct address_space' to do the unmap. I discounted that approach from the outset because it would mean walking every pfn in a multi-terabyte device just in case one is mapped at device shutdown. > it points to, check if it points to the PMEM that is being removed, > grab the page it points to, map that to the relevant struct page, > run collect_procs() on that page, then kill the user processes that > map that page. > > So why can't we walk the ptescheck the physical pages that they > map to and if they map to a pmem page we go poison that > page and that kills any user process that maps it. > > i.e. I can't see how unexpected pmem device unplug is any different > to an MCE delivering a hwpoison event to a DAX mapped page. I guess the tradeoff is walking a long list of inodes vs walking a large array of pages. There's likely always more pages than inodes, but perhaps it's more efficient to walk the 'struct page' array than sb->s_inodes? > Both > indicate a physical address range now contains invalid data and the > filesystem has to take the same action... > > IOWs, we could just call ->corrupted_range(0, EOD) here to tell the > filesystem the entire device went away. Then the filesystem deal > with this however it needs to. However, it would be more efficient > from an invalidation POV to just call it on the pages that have > currently active ptes because once the block device is dead > new page faults on DAX mappings will get a SIGBUS naturally. There is no efficient way to lookup "currently active ptes" relative to a physical pfn range. SIGBUS
Re: linux-next: Signed-off-by missing for commits in Linus' tree
On Wed, Feb 24, 2021 at 10:30 PM Kees Cook wrote: > I wonder if we need this in Documentation/maintainer/configure-git.rst That is generally a good idea. > and to put check_commits and check_fixes into tools/ somewhere? People keep saying we should put git hooks somewhere where they can be reused easily. What about just creating scripts/git-hooks? Yours, Linus Walleij
general protection fault in crypto_destroy_tfm
Hello, syzbot found the following issue on: HEAD commit:29c395c7 Merge tag 'x86-entry-2021-02-24' of git://git.ker.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15246466d0 kernel config: https://syzkaller.appspot.com/x/.config?x=c581c545cb4ffac7 dashboard link: https://syzkaller.appspot.com/bug?extid=12cf5fbfdeba210a89dd compiler: Debian clang version 11.0.1-2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+12cf5fbfdeba210a8...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc02: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0010-0x0017] CPU: 0 PID: 12596 Comm: syz-executor.2 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:crypto_destroy_tfm+0x3b/0x260 crypto/api.c:568 Code: 48 89 fb e8 c7 d7 db fd 48 85 db 0f 84 0c 02 00 00 48 89 1c 24 49 bc 00 00 00 00 00 fc ff df 4c 8d 7d 10 4c 89 fb 48 c1 eb 03 <42> 80 3c 23 00 74 08 4c 89 ff e8 76 ff 1f fe 48 8b 45 10 48 89 44 RSP: 0018:c90001aff798 EFLAGS: 00010203 RAX: 839ca5e9 RBX: 0002 RCX: 0004 RDX: c9000dd37000 RSI: aeb0 RDI: aeb1 RBP: 0006 R08: 839ca4e5 R09: fbfff1f28ab5 R10: fbfff1f28ab5 R11: R12: dc00 R13: 888012f78000 R14: 888012f78080 R15: 0016 FS: 7fe6e40b8700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 014a53ad CR3: 29fb CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: crypto_free_aead include/crypto/aead.h:191 [inline] llsec_key_alloc net/mac802154/llsec.c:156 [inline] mac802154_llsec_key_add+0x930/0xe50 net/mac802154/llsec.c:249 ieee802154_add_llsec_key+0x61/0x80 net/mac802154/cfg.c:338 rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] nl802154_add_llsec_key+0x4ca/0x7b0 net/ieee802154/nl802154.c:1584 genl_family_rcv_msg_doit net/netlink/genetlink.c:739 [inline] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0xe4e/0x1280 net/netlink/genetlink.c:800 netlink_rcv_skb+0x190/0x3a0 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x786/0x940 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x9ae/0xd50 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg net/socket.c:674 [inline] sys_sendmsg+0x519/0x800 net/socket.c:2350 ___sys_sendmsg net/socket.c:2404 [inline] __sys_sendmsg+0x2bf/0x370 net/socket.c:2437 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x465ef9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7fe6e40b8188 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0056c008 RCX: 00465ef9 RDX: RSI: 20c0 RDI: 0004 RBP: 004bcd1c R08: R09: R10: R11: 0246 R12: 0056c008 R13: 7fffc1f33d2f R14: 7fe6e40b8300 R15: 00022000 Modules linked in: ---[ end trace c6264ccb84eba4a4 ]--- RIP: 0010:crypto_destroy_tfm+0x3b/0x260 crypto/api.c:568 Code: 48 89 fb e8 c7 d7 db fd 48 85 db 0f 84 0c 02 00 00 48 89 1c 24 49 bc 00 00 00 00 00 fc ff df 4c 8d 7d 10 4c 89 fb 48 c1 eb 03 <42> 80 3c 23 00 74 08 4c 89 ff e8 76 ff 1f fe 48 8b 45 10 48 89 44 RSP: 0018:c90001aff798 EFLAGS: 00010203 RAX: 839ca5e9 RBX: 0002 RCX: 0004 RDX: c9000dd37000 RSI: aeb0 RDI: aeb1 RBP: 0006 R08: 839ca4e5 R09: fbfff1f28ab5 R10: fbfff1f28ab5 R11: R12: dc00 R13: 888012f78000 R14: 888012f78080 R15: 0016 FS: 7fe6e40b8700() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b2d228000 CR3: 29fb CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report 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 issue. See: https://goo.gl/tpsmEJ#status for how to communicate
[PATCH] fs: dlm: Spellings fixed throughout the fle lock.c
Few spelling fixes throughout the file. Signed-off-by: Bhaskar Chowdhury --- fs/dlm/lock.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 002123efc6b0..efcd84faca14 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -91,7 +91,7 @@ static void del_timeout(struct dlm_lkb *lkb); static void toss_rsb(struct kref *kref); /* - * Lock compatibilty matrix - thanks Steve + * Lock compatibility matrix - thanks Steve * UN = Unlocked state. Not really a state, used as a flag * PD = Padding. Used to make the matrix a nice power of two in size * Other states are the same as the VMS DLM. @@ -594,7 +594,7 @@ static int find_rsb_dir(struct dlm_ls *ls, char *name, int len, error = dlm_search_rsb_tree(>ls_rsbtbl[b].keep, name, len, ); if (error) goto do_toss; - + /* * rsb is active, so we can't check master_nodeid without lock_rsb. */ @@ -2357,14 +2357,14 @@ static int _can_be_granted(struct dlm_rsb *r, struct dlm_lkb *lkb, int now, * 6-5: But the default algorithm for deciding whether to grant or * queue conversion requests does not by itself guarantee that such * requests are serviced on a "first come first serve" basis. This, in -* turn, can lead to a phenomenon known as "indefinate postponement". +* turn, can lead to a phenomenon known as "indefinite postponement". * * 6-7: This issue is dealt with by using the optional QUECVT flag with * the system service employed to request a lock conversion. This flag * forces certain conversion requests to be queued, even if they are * compatible with the granted modes of other locks on the same * resource. Thus, the use of this flag results in conversion requests -* being ordered on a "first come first servce" basis. +* being ordered on a "first come first serve" basis. * * DCT: This condition is all about new conversions being able to occur * "in place" while the lock remains on the granted queue (assuming @@ -5745,7 +5745,7 @@ int dlm_recover_process_copy(struct dlm_ls *ls, struct dlm_rcom *rc) log_debug(ls, "dlm_recover_process_copy %x remote %d %x %d", lkid, rc->rc_header.h_nodeid, remid, result); - + dlm_send_rcom_lock(r, lkb); goto out; case -EEXIST: -- 2.26.2
mtk_mdp_comp.c:undefined reference to `mtk_smi_larb_get'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 commit: 50fc8d9232cdc64b9e9d1b9488452f153de52b69 memory: mtk-smi: Allow building as module date: 5 weeks ago config: openrisc-randconfig-r004-20210228 (attached as .config) compiler: or1k-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50fc8d9232cdc64b9e9d1b9488452f153de52b69 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 50fc8d9232cdc64b9e9d1b9488452f153de52b69 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=openrisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): or1k-linux-ld: drivers/media/platform/mtk-mdp/mtk_mdp_comp.o: in function `mtk_mdp_comp_clock_on': >> mtk_mdp_comp.c:(.text+0x38): undefined reference to `mtk_smi_larb_get' mtk_mdp_comp.c:(.text+0x38): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `mtk_smi_larb_get' or1k-linux-ld: drivers/media/platform/mtk-mdp/mtk_mdp_comp.o: in function `mtk_mdp_comp_clock_off': >> mtk_mdp_comp.c:(.text+0x1e4): undefined reference to `mtk_smi_larb_put' mtk_mdp_comp.c:(.text+0x1e4): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `mtk_smi_larb_put' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] copy_file_range.2: Kernel v5.12 updates
On Fri, Feb 26, 2021 at 11:43 PM Amir Goldstein wrote:
>
> On Sat, Feb 27, 2021 at 12:19 AM Alejandro Colomar (man-pages)
> wrote:
> >
> > Hello Amir, Luis,
> >
> > On 2/24/21 5:10 PM, Amir Goldstein wrote:
> > > On Wed, Feb 24, 2021 at 4:22 PM Luis Henriques wrote:
> > >>
> > >> Update man-page with recent changes to this syscall.
> > >>
> > >> Signed-off-by: Luis Henriques
> > >> ---
> > >> Hi!
> > >>
> > >> Here's a suggestion for fixing the manpage for copy_file_range(). Note
> > >> that
> > >> I've assumed the fix will hit 5.12.
> > >>
> > >> man2/copy_file_range.2 | 10 +-
> > >> 1 file changed, 9 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/man2/copy_file_range.2 b/man2/copy_file_range.2
> > >> index 611a39b8026b..b0fd85e2631e 100644
> > >> --- a/man2/copy_file_range.2
> > >> +++ b/man2/copy_file_range.2
> > >> @@ -169,6 +169,9 @@ Out of memory.
> > >> .B ENOSPC
> > >> There is not enough space on the target filesystem to complete the
> > >> copy.
> > >> .TP
> > >> +.B EOPNOTSUPP
> >
> > I'll add the kernel version here:
> >
> > .BR EOPNOTSUPP " (since Linux 5.12)"
>
> Error could be returned prior to 5.3 and would be probably returned
> by future stable kernels 5.3..5.12 too
>
> >
> > >> +The filesystem does not support this operation >> +.TP
> > >> .B EOVERFLOW
> > >> The requested source or destination range is too large to represent in
> > >> the
> > >> specified data types.
> > >> @@ -187,7 +190,7 @@ refers to an active swap file.
> > >> .B EXDEV
> > >> The files referred to by
> > >> .IR fd_in " and " fd_out
> > >> -are not on the same mounted filesystem (pre Linux 5.3).
> > >> +are not on the same mounted filesystem (pre Linux 5.3 and post Linux
> > >> 5.12).
> >
> > I'm not sure that 'mounted' adds any value here. Would you remove the
> > word here?
>
> See rename(2). 'mounted' in this context is explained there.
> HOWEVER, it does not fit here.
> copy_file_range() IS allowed between two mounts of the same filesystem
> instance.
>
> To make things more complicated, it appears that cross mount clone is not
> allowed via FICLONE/FICLONERANGE ioctl, so ioctl_ficlonerange(2) man page
> also uses the 'mounted filesystem' terminology for EXDEV
>
> As things stand now, because of the fallback to clone logic,
> copy_file_range() provides a way for users to clone across different mounts
> of the same filesystem instance, which they cannot do with the FICLONE ioctl.
>
> Fun :)
>
> BTW, I don't know if preventing cross mount clone was done intentionally,
> but as I wrote in a comment in the code once:
>
> /*
> * FICLONE/FICLONERANGE ioctls enforce that src and dest files are on
> * the same mount. Practically, they only need to be on the same file
> * system.
> */
>
> >
> > It reads as if two separate devices with the same filesystem type would
> > still give this error.
> >
> > Per the LWN.net article Amir shared, this is permitted ("When called
> > from user space, copy_file_range() will only try to copy a file across
> > filesystems if the two are of the same type").
> >
> > This behavior was slightly different before 5.3 AFAICR (was it?) ("until
> > then, copy_file_range() refused to copy between files that were not
> > located on the same filesystem."). If that's the case, I'd specify the
> > difference, or more probably split the error into two, one before 5.3,
> > and one since 5.12.
> >
>
> True.
>
> > >
> > > I think you need to drop the (Linux range) altogether.
> >
> > I'll keep the range. Users of 5.3..5.11 might be surprised if the
> > filesystems are different and they don't get an error, I think.
> >
> > I reworded it to follow other pages conventions:
> >
> > .BR EXDEV " (before Linux 5.3; or since Linux 5.12)"
> >
> > which renders as:
> >
> > EXDEV (before Linux 5.3; or since Linux 5.12)
> >The files referred to by fd_in and fd_out are not on
> >the same mounted filesystem.
> >
>
> drop 'mounted'
>
> >
> > > What's missing here is the NFS cross server copy use case.
> > > Maybe:
At least for the SMB3 kernel server (ksmbd "cifsd") looks like they use splice.
And for the user space CIFS/SMB3 server (like Samba) they have a configurable
plug in library interface ("Samba VFS modules") that would allow you
to implement
cross filesystem copy optimally for your version of Linux and plug
this into Samba
with little work on your part.
> >
> > Again, this wasn't true before 5.3, right?
> >
>
> Right.
> Actually, v5.3 provides the vfs capabilities for filesystems to support
> cross fs copy. I am not sure if NFS already implements cross fs copy in
> v5.3 and not sure about cifs. Need to get input from nfs/cis developers
> or dig in the release notes for server-side copy.
The SMB3 protocol has multiple ways to do "server side copy" (copy
offload to the server), some of which would apply to your example.
The case of "reflink" in many cases would be most
drivers/gpu/drm/kmb/kmb_dsi.c:812:2: warning: unused function 'set_test_mode_src_osc_freq_target_low_bits'
Hi Geert,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4
commit: ade896460e4a62f5e4a892a98d254937f6f5b64c drm: DRM_KMB_DISPLAY should
depend on ARCH_KEEMBAY
date: 4 months ago
config: mips-randconfig-r004-20210228 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
83bc7815c4235786111aa2abf7193292e4a602f5)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ade896460e4a62f5e4a892a98d254937f6f5b64c
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout ade896460e4a62f5e4a892a98d254937f6f5b64c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/kmb/kmb_dsi.c:812:2: warning: unused function
>> 'set_test_mode_src_osc_freq_target_low_bits'
set_test_mode_src_osc_freq_target_low_bits(struct kmb_dsi
^
>> drivers/gpu/drm/kmb/kmb_dsi.c:824:2: warning: unused function
>> 'set_test_mode_src_osc_freq_target_hi_bits'
set_test_mode_src_osc_freq_target_hi_bits(struct kmb_dsi
^
fatal error: error in backend: Nested variants found in inline asm string:
'.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/barrier.h",
.line = 16, $); 0x00 ) != -1)) : $))) ) && ( (1 << 0) ); .set push; .set
mips64r2; .rept 1; sync 0x00; .endr; .set pop; .else; ; .endif'
clang-13: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 13.0.0 (git://gitmirror/llvm_project
83bc7815c4235786111aa2abf7193292e4a602f5)
Target: mipsel-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cross/clang-83bc7815c4/bin
clang-13: note: diagnostic msg:
Makefile arch drivers fs include kernel mm scripts security source usr
vim +/set_test_mode_src_osc_freq_target_low_bits +812
drivers/gpu/drm/kmb/kmb_dsi.c
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 810
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 811 static inline void
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 @812
set_test_mode_src_osc_freq_target_low_bits(struct kmb_dsi *kmb_dsi,
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 813
u32 dphy_no,
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 814
u32 freq)
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 815 {
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 816 /* Typical rise/fall
time=166, refer Table 1207 databook,
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 817*
sr_osc_freq_target[7:0]
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 818*/
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 819 test_mode_send(kmb_dsi,
dphy_no, TEST_CODE_SLEW_RATE_DDL_CYCLES,
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 820 (freq &
0x7f));
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 821 }
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 822
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 823 static inline void
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 @824
set_test_mode_src_osc_freq_target_hi_bits(struct kmb_dsi *kmb_dsi,
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 825
u32 dphy_no,
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 826
u32 freq)
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 827 {
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 828 u32 data;
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 829
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 830 /* Flag this as high
nibble */
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 831 data = ((freq >> 6) &
0x1f) | (1 << 7);
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 832
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 833 /* Typical rise/fall
time=166, refer Table 1207 databook,
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 834*
sr_osc_freq_target[11:7]
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 835*/
98521f4d4b4cb2 Anitha Chrisanthus 2020-11-04 836 test_mode_send(kmb_dsi,
dphy_no, TEST_CODE_SLEW_RATE_DDL_CYCLES, data);
98521f4d4b4cb2
[PATCH v2] MIPS: select CPU_MIPS64 for remaining MIPS64 CPUs
CPU_MIPS64 is supposed to be selected for CPUs that implement a revision of the MIPS64 ISA. While it contains the generic ones, it forgot about Octeon and Loongson in its list, which are indeed MIPS64 processors. This commit adds these missing CPUs to the auto-selection list. Cc: Maciej W. Rozycki Cc: Thomas Bogendoerfer Cc: Ralf Baechle Cc: George Cherian Cc: Huacai Chen Cc: Jiaxun Yang Signed-off-by: Jason A. Donenfeld --- arch/mips/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d89efba3d8a4..3e0e8f1d2e82 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2118,7 +2118,7 @@ config CPU_MIPS32 config CPU_MIPS64 bool default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || \ -CPU_MIPS64_R6 +CPU_MIPS64_R6 || CPU_LOONGSON64 || CPU_CAVIUM_OCTEON # # These indicate the revision of the architecture -- 2.30.1
Re: [PATCH] tools: include: nolibc: Fix a typo occured to occurred in the file nolibc.h
On 2/27/21 2:44 PM, Bhaskar Chowdhury wrote:
>
> s/occured/occurred/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> Stolen result from Colin's finding and share from the other places. :)
>
> tools/include/nolibc/nolibc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc/nolibc.h
> index e61d36cd4e50..fc998c359607 100644
> --- a/tools/include/nolibc/nolibc.h
> +++ b/tools/include/nolibc/nolibc.h
> @@ -1054,7 +1054,7 @@ struct sys_stat_struct {
> * scall32-o32.S in the kernel sources.
> * - the system call is performed by calling "syscall"
> * - syscall return comes in v0, and register a3 needs to be checked to
> know
> - * if an error occured, in which case errno is in v0.
> + * if an error occurred, in which case errno is in v0.
> * - the arguments are cast to long and assigned into the target registers
> * which are then simply passed as registers to the asm code, so that we
> * don't have to experience issues with register constraints.
> --
--
~Randy
Re: [PATCH] MIPS: select CPU_MIPS64 for remaining MIPS64 CPUs
On Sat, Feb 27, 2021 at 2:41 PM Maciej W. Rozycki wrote: > > On Sat, 27 Feb 2021, Jason A. Donenfeld wrote: > > > The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to > > distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they > > That is not true. The purpose of these options is to identify MIPS64 and > MIPS32 ISA processors respectively (and the generic features these ISAs > imply). There are 64-bit and 32-bit MIPS processors which do not qualify, > specifically all MIPS I, MIPS II, MIPS III, and MIPS IV implementations. > > > weren't selected by the specialty CPUs, Octeon and Loongson, which meant > > it was possible to hit a weird state of: > > > > MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n > > This is a correct combination for MIPS III and MIPS IV processors. > > > This commit rectifies the issue by having CPU_MIPS64 be selected when > > the missing Octeon or Loongson models are selected. > > From the description and/or other options selected by CPU_LOONGSON64 and > CPU_CAVIUM_OCTEON I infer the change itself is correct, so you only need > to rewrite the change description. Indeed you're right. v2 on its way. Jason
[PATCH] tools: include: nolibc: Fix a typo occured to occurred in the file nolibc.h
s/occured/occurred/
Signed-off-by: Bhaskar Chowdhury
---
Stolen result from Colin's finding and share from the other places. :)
tools/include/nolibc/nolibc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc/nolibc.h
index e61d36cd4e50..fc998c359607 100644
--- a/tools/include/nolibc/nolibc.h
+++ b/tools/include/nolibc/nolibc.h
@@ -1054,7 +1054,7 @@ struct sys_stat_struct {
* scall32-o32.S in the kernel sources.
* - the system call is performed by calling "syscall"
* - syscall return comes in v0, and register a3 needs to be checked to know
- * if an error occured, in which case errno is in v0.
+ * if an error occurred, in which case errno is in v0.
* - the arguments are cast to long and assigned into the target registers
* which are then simply passed as registers to the asm code, so that we
* don't have to experience issues with register constraints.
--
2.26.2
Re: Question about the "EXPERIMENTAL" tag for dax in XFS
On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote: > On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote: > > On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote: > > > On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote: > > > > > My immediate concern is the issue Jason recently highlighted [1] with > > > > > respect to invalidating all dax mappings when / if the device is > > > > > ripped out from underneath the fs. I don't think that will collide > > > > > with Ruan's implementation, but it does need new communication from > > > > > driver to fs about removal events. > > > > > > > > > > [1]: > > > > > http://lore.kernel.org/r/capcyv4i+pzhyziepf2pah0dt5jdfkmkdx-3usqy1fahf6lp...@mail.gmail.com > > > > > > > > Oh, yay. > > > > > > > > The XFS shutdown code is centred around preventing new IO from being > > > > issued - we don't actually do anything about DAX mappings because, > > > > well, I don't think anyone on the filesystem side thought they had > > > > to do anything special if pmem went away from under it. > > > > > > > > My understanding -was- that the pmem removal invalidates > > > > all the ptes currently mapped into CPU page tables that point at > > > > the dax device across the system. THe vmas that manage these > > > > mappings are not really something the filesystem really manages, > > > > but a function of the mm subsystem. What the filesystem cares about > > > > is that it gets page faults triggered when a change of state occurs > > > > so that it can remap the page to it's backing store correctly. > > > > > > > > IOWs, all the mm subsystem needs to when pmem goes away is clear the > > > > CPU ptes, because then when then when userspace tries to access the > > > > mapped DAX pages we get a new page fault. In processing the fault, the > > > > filesystem will try to get direct access to the pmem from the block > > > > device. This will get an ENODEV error from the block device because > > > > because the backing store (pmem) has been unplugged and is no longer > > > > there... > > > > > > > > AFAICT, as long as pmem removal invalidates all the active ptes that > > > > point at the pmem being removed, the filesystem doesn't need to > > > > care about device removal at all, DAX or no DAX... > > > > > > How would the pmem removal do that without walking all the active > > > inodes in the fs at the time of shutdown and call > > > unmap_mapping_range(inode->i_mapping, 0, 0, 1)? > > > > Which then immediately ends up back at the vmas that manage the ptes > > to unmap them. > > > > Isn't finding the vma(s) that map a specific memory range exactly > > what the rmap code in the mm subsystem is supposed to address? > > rmap can lookup only vmas from a virt address relative to a given > mm_struct. The driver has neither the list of mm_struct objects nor > virt addresses to do a lookup. All it knows is that someone might have > mapped pages through the fsdax interface. So there's no physical addr to vma translation in the mm subsystem at all? That doesn't make sense. We do exactly this for hwpoison for DAX mappings. While we don't look at ptes, we get a pfn, grab the page it points to, check if it points to the PMEM that is being removed, grab the page it points to, map that to the relevant struct page, run collect_procs() on that page, then kill the user processes that map that page. So why can't we walk the ptes, check the physical pages that they map to and if they map to a pmem page we go poison that page and that kills any user process that maps it. i.e. I can't see how unexpected pmem device unplug is any different to an MCE delivering a hwpoison event to a DAX mapped page. Both indicate a physical address range now contains invalid data and the filesystem has to take the same action... IOWs, we could just call ->corrupted_range(0, EOD) here to tell the filesystem the entire device went away. Then the filesystem deal with this however it needs to. However, it would be more efficient from an invalidation POV to just call it on the pages that have currently active ptes because once the block device is dead new page faults on DAX mappings will get a SIGBUS naturally. > To me this looks like a notifier that fires from memunmap_pages() > after dev_pagemap_kill() to notify any block_device associated with > that dev_pagemap() to say that any dax mappings arranged through this > block_device are now invalid. The reason to do this after > dev_pagemap_kill() is so that any new mapping attempts that are racing > the removal will be blocked. I don't see why this needs a unique notifier. At the filesystem level, we want a single interface that tells us "something bad happened to the block device", not a proliferation of similar but subtly different "bad thing X happened to block device" interfaces that are unique to specific physical device drivers... > The receiver of that notification needs to go from a block_device to a > superblock that has mapped inodes and walk ->sb_inodes
Hello okay
Hello,
My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state
and Petroleum" also "Minister of State for International Cooperation"
in UAE. I write to you on behalf of my other "three (3) colleagues"
who has approved me to solicit for your "partnership in claiming of
{us$47=Million}" from a Financial Home in Cambodia on their behalf and
for our "Mutual Benefits".
The Fund {us$47=Million} is our share from the (over-invoiced) Oil/Gas
deal with Cambodian/Vietnam Government within 2013/2014, however, we
don't want our government to know about the fund. If this proposal
interests you, let me know, by sending me an email and I will send to
you detailed information on how this business would be successfully
transacted. Be informed that nobody knows about the secret of this
fund except us, and we know how to carry out the entire transaction.
So I am compelled to ask, that you will stand on our behalf and
receive this fund into any account that is solely controlled by you.
We will compensate you with 15% of the total amount involved as
gratification for being our partner in this transaction. Reply to:
ms.r...@yandex.com
Regards,
Ms. Reem.
[PATCH 4/4] staging:rtl8712: replace cap_* definitions with native kernel WLAN_CAPABILITY_*
cap_* definitions duplicate WLAN_CAPABILITY_*. Remove cap_* definitions, improve code consistency. Signed-off-by: Ivan Safonov --- drivers/staging/rtl8712/ieee80211.c | 6 +++--- drivers/staging/rtl8712/wifi.h | 7 --- 2 files changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/staging/rtl8712/ieee80211.c b/drivers/staging/rtl8712/ieee80211.c index b4a099169c7c..13fc3c1ec0db 100644 --- a/drivers/staging/rtl8712/ieee80211.c +++ b/drivers/staging/rtl8712/ieee80211.c @@ -173,11 +173,11 @@ int r8712_generate_ie(struct registry_priv *registrypriv) ie += 2; /*capability info*/ *(u16 *)ie = 0; - *(__le16 *)ie |= cpu_to_le16(cap_IBSS); + *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_IBSS); if (registrypriv->preamble == PREAMBLE_SHORT) - *(__le16 *)ie |= cpu_to_le16(cap_ShortPremble); + *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_SHORT_PREAMBLE); if (dev_network->Privacy) - *(__le16 *)ie |= cpu_to_le16(cap_Privacy); + *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_PRIVACY); sz += 2; ie += 2; /*SSID*/ diff --git a/drivers/staging/rtl8712/wifi.h b/drivers/staging/rtl8712/wifi.h index b7889ac3dce9..f941efb1f4e2 100644 --- a/drivers/staging/rtl8712/wifi.h +++ b/drivers/staging/rtl8712/wifi.h @@ -278,13 +278,6 @@ static inline unsigned char *get_hdr_bssid(unsigned char *pframe) #define AUTH_ODD_TO0 #define AUTH_EVEN_TO 1 -#define cap_ESS BIT(0) -#define cap_IBSS BIT(1) -#define cap_CFPollable BIT(2) -#define cap_CFRequest BIT(3) -#define cap_Privacy BIT(4) -#define cap_ShortPremble BIT(5) - /*- * Below is the definition for 802.11i / 802.1x *-- -- 2.26.2
[PATCH 1/4] staging:rtl8712: replace get_(d|s)a with ieee80211_get_(D|S)A
get_da()/get_sa() duplicate native ieee80211_get_(D|S)A functions.
Remove get_(d|s)a, use ieee80211_get_(D|S)A instead.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8712/rtl871x_recv.c | 4 +--
drivers/staging/rtl8712/wifi.h | 45 --
2 files changed, 2 insertions(+), 47 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_recv.c
b/drivers/staging/rtl8712/rtl871x_recv.c
index eb4e46a7f743..efd783e7ccbc 100644
--- a/drivers/staging/rtl8712/rtl871x_recv.c
+++ b/drivers/staging/rtl8712/rtl871x_recv.c
@@ -466,8 +466,8 @@ static sint validate_recv_data_frame(struct _adapter
*adapter,
struct security_priv *psecuritypriv = >securitypriv;
bretry = GetRetry(ptr);
- pda = get_da(ptr);
- psa = get_sa(ptr);
+ pda = ieee80211_get_DA((struct ieee80211_hdr *)ptr);
+ psa = ieee80211_get_SA((struct ieee80211_hdr *)ptr);
pbssid = get_hdr_bssid(ptr);
if (!pbssid)
return _FAIL;
diff --git a/drivers/staging/rtl8712/wifi.h b/drivers/staging/rtl8712/wifi.h
index 1b32b3510093..5de0e67b1876 100644
--- a/drivers/staging/rtl8712/wifi.h
+++ b/drivers/staging/rtl8712/wifi.h
@@ -264,51 +264,6 @@ static inline unsigned char get_tofr_ds(unsigned char
*pframe)
#define GetAddr4Ptr(pbuf) ((unsigned char *)((addr_t)(pbuf) + 24))
-static inline unsigned char *get_da(unsigned char *pframe)
-{
- unsigned char *da;
- unsigned intto_fr_ds = (GetToDs(pframe) << 1) | GetFrDs(pframe);
-
- switch (to_fr_ds) {
- case 0x00: /* ToDs=0, FromDs=0 */
- da = GetAddr1Ptr(pframe);
- break;
- case 0x01: /* ToDs=0, FromDs=1 */
- da = GetAddr1Ptr(pframe);
- break;
- case 0x02: /* ToDs=1, FromDs=0 */
- da = GetAddr3Ptr(pframe);
- break;
- default:/* ToDs=1, FromDs=1 */
- da = GetAddr3Ptr(pframe);
- break;
- }
- return da;
-}
-
-static inline unsigned char *get_sa(unsigned char *pframe)
-{
- unsigned char *sa;
- unsigned intto_fr_ds = (GetToDs(pframe) << 1) | GetFrDs(pframe);
-
- switch (to_fr_ds) {
- case 0x00: /* ToDs=0, FromDs=0 */
- sa = GetAddr2Ptr(pframe);
- break;
- case 0x01: /* ToDs=0, FromDs=1 */
- sa = GetAddr3Ptr(pframe);
- break;
- case 0x02: /* ToDs=1, FromDs=0 */
- sa = GetAddr2Ptr(pframe);
- break;
- default:/* ToDs=1, FromDs=1 */
- sa = GetAddr4Ptr(pframe);
- break;
- }
-
- return sa;
-}
-
static inline unsigned char *get_hdr_bssid(unsigned char *pframe)
{
unsigned char *sa;
--
2.26.2
[PATCH 2/4] staging:rtl8712: remove unused definitions from wifi.h
These definitions are not used and will not be useful in the future.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8712/wifi.h | 74 --
1 file changed, 74 deletions(-)
diff --git a/drivers/staging/rtl8712/wifi.h b/drivers/staging/rtl8712/wifi.h
index 5de0e67b1876..11fba6f9e721 100644
--- a/drivers/staging/rtl8712/wifi.h
+++ b/drivers/staging/rtl8712/wifi.h
@@ -16,22 +16,8 @@
#include
-#define WLAN_IEEE_OUI_LEN 3
-#define WLAN_CRC_LEN 4
-#define WLAN_BSSID_LEN 6
-#define WLAN_BSS_TS_LEN8
#define WLAN_HDR_A3_LEN24
-#define WLAN_HDR_A4_LEN30
#define WLAN_HDR_A3_QOS_LEN26
-#define WLAN_HDR_A4_QOS_LEN32
-#define WLAN_SSID_MAXLEN 32
-#define WLAN_DATA_MAXLEN 2312
-
-#define WLAN_A3_PN_OFFSET 24
-#define WLAN_A4_PN_OFFSET 30
-
-#define WLAN_MIN_ETHFRM_LEN60
-#define WLAN_MAX_ETHFRM_LEN1514
#define P80211CAPTURE_VERSION 0x80211001
@@ -74,33 +60,6 @@ enum WIFI_FRAME_SUBTYPE {
WIFI_CF_ACKPOLL = (BIT(6) | BIT(5) | BIT(4) | WIFI_DATA_TYPE),
};
-enum WIFI_REASON_CODE {
- _RSON_RESERVED_ = 0,
- _RSON_UNSPECIFIED_ = 1,
- _RSON_AUTH_NO_LONGER_VALID_ = 2,
- _RSON_DEAUTH_STA_LEAVING_ = 3,
- _RSON_INACTIVITY_ = 4,
- _RSON_UNABLE_HANDLE_= 5,
- _RSON_CLS2_ = 6,
- _RSON_CLS3_ = 7,
- _RSON_DISAOC_STA_LEAVING_ = 8,
- _RSON_ASOC_NOT_AUTH_= 9,
- /* WPA reason */
- _RSON_INVALID_IE_ = 13,
- _RSON_MIC_FAILURE_ = 14,
- _RSON_4WAY_HNDSHK_TIMEOUT_ = 15,
- _RSON_GROUP_KEY_UPDATE_TIMEOUT_ = 16,
- _RSON_DIFF_IE_ = 17,
- _RSON_MLTCST_CIPHER_NOT_VALID_ = 18,
- _RSON_UNICST_CIPHER_NOT_VALID_ = 19,
- _RSON_AKMP_NOT_VALID_ = 20,
- _RSON_UNSUPPORT_RSNE_VER_ = 21,
- _RSON_INVALID_RSNE_CAP_ = 22,
- _RSON_IEEE_802DOT1X_AUTH_FAIL_ = 23,
- /* below are Realtek definitions */
- _RSON_PMK_NOT_AVAILABLE_= 24,
-};
-
enum WIFI_REG_DOMAIN {
DOMAIN_FCC = 1,
DOMAIN_IC = 2,
@@ -234,11 +193,6 @@ static inline unsigned char get_tofr_ds(unsigned char
*pframe)
0x000f) | (0xfff0 & (num << 4))); \
})
-#define SetDuration(pbuf, dur) ({ \
- *(__le16 *)((addr_t)(pbuf) + 2) |= \
- cpu_to_le16(0x & (dur)); \
-})
-
#define SetPriority(pbuf, tid) ({ \
*(__le16 *)(pbuf) |= cpu_to_le16(tid & 0xf); \
})
@@ -253,9 +207,6 @@ static inline unsigned char get_tofr_ds(unsigned char
*pframe)
#define GetAMsdu(pbuf) (((le16_to_cpu(*(__le16 *)pbuf)) >> 7) & 0x1)
-#define GetAid(pbuf) (cpu_to_le16(*(__le16 *)((addr_t)(pbuf) + 2)) \
- & 0x3fff)
-
#define GetAddr1Ptr(pbuf) ((unsigned char *)((addr_t)(pbuf) + 4))
#define GetAddr2Ptr(pbuf) ((unsigned char *)((addr_t)(pbuf) + 10))
@@ -290,19 +241,6 @@ static inline unsigned char *get_hdr_bssid(unsigned char
*pframe)
* Below is for the security related definition
*-
*/
-#define _RESERVED_FRAME_TYPE_ 0
-#define _SKB_FRAME_TYPE_ 2
-#define _PRE_ALLOCMEM_ 1
-#define _PRE_ALLOCHDR_ 3
-#define _PRE_ALLOCLLCHDR_ 4
-#define _PRE_ALLOCICVHDR_ 5
-#define _PRE_ALLOCMICHDR_ 6
-
-#define _SIFSTIME_ ((priv->pmib->BssType.net_work_type & \
- WIRELESS_11A) ? 16 : 10)
-#define _ACKCTSLNG_14 /*14 bytes long, including crclng */
-#define _CRCLNG_ 4
-
#define _ASOCREQ_IE_OFFSET_4 /* excluding wlan_hdr */
#define_ASOCRSP_IE_OFFSET_ 6
#define _REASOCREQ_IE_OFFSET_ 10
@@ -348,10 +286,6 @@ static inline unsigned char *get_hdr_bssid(unsigned char
*pframe)
#define AUTH_ODD_TO0
#define AUTH_EVEN_TO 1
-#define WLAN_ETHCONV_ENCAP 1
-#define WLAN_ETHCONV_RFC1042 2
-#define WLAN_ETHCONV_8021h 3
-
#define cap_ESS BIT(0)
#define cap_IBSS BIT(1)
#define cap_CFPollable BIT(2)
@@ -371,20 +305,12 @@ static inline unsigned char *get_hdr_bssid(unsigned char
*pframe)
*--
*/
#define _WMM_IE_Length_7 /* for WMM STA */
-#define _WMM_Para_Element_Length_ 24
/*-
* Below is the definition for 802.11n
*--
*/
-#define SetOrderBit(pbuf) ({ \
- *(__le16 *)(pbuf) |= cpu_to_le16(_ORDER_); \
-})
-
-#define GetOrderBit(pbuf) (((*(__le16
[PATCH 3/4] staging:rtl8712: use IEEE80211_FCTL_* kernel definitions
_TO_DS_, _FROM_DS_, _MORE_FRAG_, _RETRY_, _PWRMGT_, _MORE_DATA_,
_PRIVACY_, _ORDER_ definitions are duplicate IEEE80211_FCTL_*
kernel definitions.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8712/wifi.h | 52 ++
1 file changed, 22 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/rtl8712/wifi.h b/drivers/staging/rtl8712/wifi.h
index 11fba6f9e721..b7889ac3dce9 100644
--- a/drivers/staging/rtl8712/wifi.h
+++ b/drivers/staging/rtl8712/wifi.h
@@ -15,6 +15,7 @@
#define _WIFI_H_
#include
+#include
#define WLAN_HDR_A3_LEN24
#define WLAN_HDR_A3_QOS_LEN26
@@ -74,33 +75,24 @@ enum WIFI_REG_DOMAIN {
DOMAIN_MAX
};
-#define _TO_DS_BIT(8)
-#define _FROM_DS_ BIT(9)
-#define _MORE_FRAG_BIT(10)
-#define _RETRY_BIT(11)
-#define _PWRMGT_ BIT(12)
-#define _MORE_DATA_BIT(13)
-#define _PRIVACY_ BIT(14)
-#define _ORDER_BIT(15)
-
#define SetToDs(pbuf) ({ \
- *(__le16 *)(pbuf) |= cpu_to_le16(_TO_DS_); \
+ *(__le16 *)(pbuf) |= cpu_to_le16(IEEE80211_FCTL_TODS); \
})
-#define GetToDs(pbuf) (((*(__le16 *)(pbuf)) & cpu_to_le16(_TO_DS_)) != 0)
+#define GetToDs(pbuf) (((*(__le16 *)(pbuf)) &
cpu_to_le16(IEEE80211_FCTL_TODS)) != 0)
#define ClearToDs(pbuf)({ \
- *(__le16 *)(pbuf) &= (~cpu_to_le16(_TO_DS_)); \
+ *(__le16 *)(pbuf) &= (~cpu_to_le16(IEEE80211_FCTL_TODS)); \
})
#define SetFrDs(pbuf) ({ \
- *(__le16 *)(pbuf) |= cpu_to_le16(_FROM_DS_); \
+ *(__le16 *)(pbuf) |= cpu_to_le16(IEEE80211_FCTL_FROMDS); \
})
-#define GetFrDs(pbuf) (((*(__le16 *)(pbuf)) & cpu_to_le16(_FROM_DS_)) != 0)
+#define GetFrDs(pbuf) (((*(__le16 *)(pbuf)) &
cpu_to_le16(IEEE80211_FCTL_FROMDS)) != 0)
#define ClearFrDs(pbuf)({ \
- *(__le16 *)(pbuf) &= (~cpu_to_le16(_FROM_DS_)); \
+ *(__le16 *)(pbuf) &= (~cpu_to_le16(IEEE80211_FCTL_FROMDS)); \
})
static inline unsigned char get_tofr_ds(unsigned char *pframe)
@@ -109,56 +101,56 @@ static inline unsigned char get_tofr_ds(unsigned char
*pframe)
}
#define SetMFrag(pbuf) ({ \
- *(__le16 *)(pbuf) |= cpu_to_le16(_MORE_FRAG_); \
+ *(__le16 *)(pbuf) |= cpu_to_le16(IEEE80211_FCTL_MOREFRAGS); \
})
-#define GetMFrag(pbuf) (((*(__le16 *)(pbuf)) & cpu_to_le16(_MORE_FRAG_)) != 0)
+#define GetMFrag(pbuf) (((*(__le16 *)(pbuf)) &
cpu_to_le16(IEEE80211_FCTL_MOREFRAGS)) != 0)
#define ClearMFrag(pbuf) ({ \
- *(__le16 *)(pbuf) &= (~cpu_to_le16(_MORE_FRAG_)); \
+ *(__le16 *)(pbuf) &= (~cpu_to_le16(IEEE80211_FCTL_MOREFRAGS)); \
})
#define SetRetry(pbuf) ({ \
- *(__le16 *)(pbuf) |= cpu_to_le16(_RETRY_); \
+ *(__le16 *)(pbuf) |= cpu_to_le16(IEEE80211_FCTL_RETRY); \
})
-#define GetRetry(pbuf) (((*(__le16 *)(pbuf)) & cpu_to_le16(_RETRY_)) != 0)
+#define GetRetry(pbuf) (((*(__le16 *)(pbuf)) &
cpu_to_le16(IEEE80211_FCTL_RETRY)) != 0)
#define ClearRetry(pbuf) ({ \
- *(__le16 *)(pbuf) &= (~cpu_to_le16(_RETRY_)); \
+ *(__le16 *)(pbuf) &= (~cpu_to_le16(IEEE80211_FCTL_RETRY)); \
})
#define SetPwrMgt(pbuf) ({ \
- *(__le16 *)(pbuf) |= cpu_to_le16(_PWRMGT_); \
+ *(__le16 *)(pbuf) |= cpu_to_le16(IEEE80211_FCTL_PM); \
})
#define GetPwrMgt(pbuf)(((*(__le16 *)(pbuf)) & \
- cpu_to_le16(_PWRMGT_)) != 0)
+ cpu_to_le16(IEEE80211_FCTL_PM)) != 0)
#define ClearPwrMgt(pbuf) ({ \
- *(__le16 *)(pbuf) &= (~cpu_to_le16(_PWRMGT_)); \
+ *(__le16 *)(pbuf) &= (~cpu_to_le16(IEEE80211_FCTL_PM)); \
})
#define SetMData(pbuf) ({ \
- *(__le16 *)(pbuf) |= cpu_to_le16(_MORE_DATA_); \
+ *(__le16 *)(pbuf) |= cpu_to_le16(IEEE80211_FCTL_MOREDATA); \
})
#define GetMData(pbuf) (((*(__le16 *)(pbuf)) & \
- cpu_to_le16(_MORE_DATA_)) != 0)
+ cpu_to_le16(IEEE80211_FCTL_MOREDATA)) != 0)
#define ClearMData(pbuf) ({ \
- *(__le16 *)(pbuf) &= (~cpu_to_le16(_MORE_DATA_)); \
+ *(__le16 *)(pbuf) &= (~cpu_to_le16(IEEE80211_FCTL_MOREDATA)); \
})
#define SetPrivacy(pbuf) ({ \
- *(__le16 *)(pbuf) |= cpu_to_le16(_PRIVACY_); \
+ *(__le16 *)(pbuf) |= cpu_to_le16(IEEE80211_FCTL_PROTECTED); \
})
#define GetPrivacy(pbuf) (((*(__le16 *)(pbuf)) & \
- cpu_to_le16(_PRIVACY_)) != 0)
+ cpu_to_le16(IEEE80211_FCTL_PROTECTED)) != 0)
#define GetOrder(pbuf) (((*(__le16 *)(pbuf)) & \
- cpu_to_le16(_ORDER_)) != 0)
+ cpu_to_le16(IEEE80211_FCTL_ORDER)) != 0)
#define GetFrameType(pbuf) (le16_to_cpu(*(__le16 *)(pbuf)) & \
(BIT(3) | BIT(2)))
--
2.26.2
[PATCH 0/4] staging:rtl8712: avoid unnecessary definitions in wifi.h
wifi.h contains unnecessary definitions. Some of them are not used at all, some can be replaced with native definitions. Ivan Safonov (4): staging:rtl8712: replace get_(d|s)a with ieee80211_get_(D|S)A staging:rtl8712: remove unused definitions from wifi.h staging:rtl8712: use IEEE80211_FCTL_* kernel definitions staging:rtl8712: replace cap_* definitions with native kernel WLAN_CAPABILITY_* drivers/staging/rtl8712/ieee80211.c| 6 +- drivers/staging/rtl8712/rtl871x_recv.c | 4 +- drivers/staging/rtl8712/wifi.h | 178 +++-- 3 files changed, 27 insertions(+), 161 deletions(-) -- 2.26.2
[PATCH] staging: rtl8723bs: Fixed indentation and coding style
This clean up indentaion issue as well as coding style issue.
Signed-off-by: chakravarthikulkarni
---
drivers/staging/rtl8723bs/include/rtw_cmd.h | 30 ++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/rtw_cmd.h
b/drivers/staging/rtl8723bs/include/rtw_cmd.h
index 56c77bc7ca81..3545a98ef94e 100644
--- a/drivers/staging/rtl8723bs/include/rtw_cmd.h
+++ b/drivers/staging/rtl8723bs/include/rtw_cmd.h
@@ -678,13 +678,13 @@ struct setratable_parm {
};
struct getratable_parm {
-uint rsvd;
+ uint rsvd;
};
struct getratable_rsp {
-u8 ss_ForceUp[NumRates];
-u8 ss_ULevel[NumRates];
-u8 ss_DLevel[NumRates];
-u8 count_judge[NumRates];
+ u8 ss_ForceUp[NumRates];
+ u8 ss_ULevel[NumRates];
+ u8 ss_DLevel[NumRates];
+ u8 count_judge[NumRates];
};
@@ -786,7 +786,7 @@ struct TDLSoption_param {
/*H2C Handler index: 64 */
struct RunInThread_param {
- void (*func)(void*);
+ void (*func)(void *);
void *context;
};
@@ -795,14 +795,14 @@ struct RunInThread_param {
/*
-
-Result:
-0x00: success
-0x01: sucess, and check Response.
-0x02: cmd ignored due to duplicated sequcne number
-0x03: cmd dropped due to invalid cmd code
-0x04: reserved.
-
+*
+*Result:
+*0x00: success
+*0x01: sucess, and check Response.
+*0x02: cmd ignored due to duplicated sequcne number
+*0x03: cmd dropped due to invalid cmd code
+*0x04: reserved.
+*
*/
#define H2C_RSP_OFFSET 512
@@ -824,7 +824,7 @@ struct sta_info;
extern u8 rtw_setstakey_cmd(struct adapter *padapter, struct sta_info *sta,
u8 unicast_key, bool enqueue);
extern u8 rtw_clearstakey_cmd(struct adapter *padapter, struct sta_info *sta,
u8 enqueue);
-extern u8 rtw_joinbss_cmd(struct adapter *padapter, struct wlan_network*
pnetwork);
+extern u8 rtw_joinbss_cmd(struct adapter *padapter, struct wlan_network
*pnetwork);
u8 rtw_disassoc_cmd(struct adapter *padapter, u32 deauth_timeout_ms, bool
enqueue);
extern u8 rtw_setopmode_cmd(struct adapter *padapter, enum
NDIS_802_11_NETWORK_INFRASTRUCTURE networktype, bool enqueue);
extern u8 rtw_setdatarate_cmd(struct adapter *padapter, u8 *rateset);
--
2.17.1
[PATCH] usb: dwc2: Add STM32 related debugfs entries
These are entries related to STM32MP1 PHY control. Signed-off-by: Martin Devera --- drivers/usb/dwc2/debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc2/debugfs.c b/drivers/usb/dwc2/debugfs.c index aaafd463d72a..f13eed4231e1 100644 --- a/drivers/usb/dwc2/debugfs.c +++ b/drivers/usb/dwc2/debugfs.c @@ -691,6 +691,8 @@ static int params_show(struct seq_file *seq, void *v) print_param(seq, p, ulpi_fs_ls); print_param(seq, p, host_support_fs_ls_low_power); print_param(seq, p, host_ls_low_power_phy_clk); + print_param(seq, p, activate_stm_fs_transceiver); + print_param(seq, p, activate_stm_id_vb_detection); print_param(seq, p, ts_dline); print_param(seq, p, reload_ctl); print_param_hex(seq, p, ahbcfg); -- 2.11.0
arch/x86/kvm/mmu/tdp_mmu.c:388:49: sparse: sparse: incorrect type in argument 2 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 commit: 7cca2d0b7e7d9f3cd740d41afdc00051c9b508a0 KVM: x86/mmu: Protect TDP MMU page table memory with RCU date: 3 weeks ago config: x86_64-randconfig-s022-20210228 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-241-geaceeafa-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7cca2d0b7e7d9f3cd740d41afdc00051c9b508a0 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 7cca2d0b7e7d9f3cd740d41afdc00051c9b508a0 # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" >> arch/x86/kvm/mmu/tdp_mmu.c:388:49: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected unsigned long long >> [usertype] *pt @@ got unsigned long long [noderef] [usertype] __rcu * @@ arch/x86/kvm/mmu/tdp_mmu.c:388:49: sparse: expected unsigned long long [usertype] *pt arch/x86/kvm/mmu/tdp_mmu.c:388:49: sparse: got unsigned long long [noderef] [usertype] __rcu * >> arch/x86/kvm/mmu/tdp_mmu.c:506:51: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected unsigned long long >> [usertype] *root_pt @@ got unsigned long long [noderef] [usertype] __rcu >> * @@ arch/x86/kvm/mmu/tdp_mmu.c:506:51: sparse: expected unsigned long long [usertype] *root_pt arch/x86/kvm/mmu/tdp_mmu.c:506:51: sparse: got unsigned long long [noderef] [usertype] __rcu * >> arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected unsigned long long >> [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu >> *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt >> arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected unsigned long long >> [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu >> *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt >> arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected unsigned long long >> [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu >> *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt >> arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected unsigned long long >> [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu >> *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt >> arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected unsigned long long >> [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu >> *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt >> arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected unsigned long long >> [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu >> *[usertype] root_pt @@ arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: expected unsigned long long [usertype] *sptep arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: got unsigned long long [noderef] [usertype] __rcu *[usertype] root_pt >> arch/x86/kvm/mmu/tdp_mmu.c:421:49: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected unsigned long long >> [usertype] *sptep @@ got unsigned long long [noderef] [usertype] __rcu
Re: [PATCH] uapi: nfnetlink_cthelper.h: fix userspace compilation error
On Mon, Feb 22, 2021 at 08:00:00AM +, Dmitry V. Levin wrote: > Apparently, and > could not be included into the same > compilation unit because of a cut-and-paste typo in the former header. Applied, thanks.
[PATCH] atm: eni: dont release is never initialized
label err_eni_release is reachable when eni_start() fail. In eni_start() it calls dev->phy->start() in the last step, if start() fail we don't need to call phy->stop(), if start() is never called, we neither need to call phy->stop(), otherwise null-ptr-deref will happen. In order to fix this issue, don't call phy->stop() in label err_eni_release [4.875714] == [4.876091] BUG: KASAN: null-ptr-deref in suni_stop+0x47/0x100 [suni] [4.876433] Read of size 8 at addr 0030 by task modprobe/95 [4.876778] [4.876862] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc7-00090-gdcc0b49040c7 #2 [4.877290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd94 [4.877876] Call Trace: [4.878009] dump_stack+0x7d/0xa3 [4.878191] kasan_report.cold+0x10c/0x10e [4.878410] ? __slab_free+0x2f0/0x340 [4.878612] ? suni_stop+0x47/0x100 [suni] [4.878832] suni_stop+0x47/0x100 [suni] [4.879043] eni_do_release+0x3b/0x70 [eni] [4.879269] eni_init_one.cold+0x1152/0x1747 [eni] [4.879528] ? _raw_spin_lock_irqsave+0x7b/0xd0 [4.879768] ? eni_ioctl+0x270/0x270 [eni] [4.879990] ? __mutex_lock_slowpath+0x10/0x10 [4.880226] ? eni_ioctl+0x270/0x270 [eni] [4.880448] local_pci_probe+0x6f/0xb0 [4.880650] pci_device_probe+0x171/0x240 [4.880864] ? pci_device_remove+0xe0/0xe0 [4.881086] ? kernfs_create_link+0xb6/0x110 [4.881315] ? sysfs_do_create_link_sd.isra.0+0x76/0xe0 [4.881594] really_probe+0x161/0x420 [4.881791] driver_probe_device+0x6d/0xd0 [4.882010] device_driver_attach+0x82/0x90 [4.882233] ? device_driver_attach+0x90/0x90 [4.882465] __driver_attach+0x60/0x100 [4.882671] ? device_driver_attach+0x90/0x90 [4.882903] bus_for_each_dev+0xe1/0x140 [4.883114] ? subsys_dev_iter_exit+0x10/0x10 [4.883346] ? klist_node_init+0x61/0x80 [4.883557] bus_add_driver+0x254/0x2a0 [4.883764] driver_register+0xd3/0x150 [4.883971] ? 0xc0038000 [4.884149] do_one_initcall+0x84/0x250 [4.884355] ? trace_event_raw_event_initcall_finish+0x150/0x150 [4.884674] ? unpoison_range+0xf/0x30 [4.884875] ? kasan_kmalloc.constprop.0+0x84/0xa0 [4.885150] ? unpoison_range+0xf/0x30 [4.885352] ? unpoison_range+0xf/0x30 [4.885557] do_init_module+0xf8/0x350 [4.885760] load_module+0x3fe6/0x4340 [4.885960] ? vm_unmap_ram+0x1d0/0x1d0 [4.886166] ? kasan_kmalloc.constprop.0+0x84/0xa0 [4.886441] ? module_frob_arch_sections+0x20/0x20 [4.886697] ? __do_sys_finit_module+0x108/0x170 [4.886941] __do_sys_finit_module+0x108/0x170 [4.887178] ? __ia32_sys_init_module+0x40/0x40 [4.887419] ? file_open_root+0x200/0x200 [4.887634] ? do_sys_open+0x85/0xe0 [4.887826] ? filp_open+0x50/0x50 [4.888009] ? fpregs_assert_state_consistent+0x4d/0x60 [4.888287] ? exit_to_user_mode_prepare+0x2f/0x130 [4.888547] do_syscall_64+0x33/0x40 [4.888739] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [4.889010] RIP: 0033:0x7ff62fcf1cf7 [4.889202] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f71 [4.890172] RSP: 002b:7ffe6644ade8 EFLAGS: 0246 ORIG_RAX: 0139 [4.890570] RAX: ffda RBX: 00f2ca70 RCX: 7ff62fcf1cf7 [4.890944] RDX: RSI: 00f2b9e0 RDI: 0003 [4.891318] RBP: 0003 R08: R09: 0001 [4.891691] R10: 7ff62fd55300 R11: 0246 R12: 00f2b9e0 [4.892064] R13: R14: 00f2bdd0 R15: 0001 [4.892439] == Signed-off-by: Tong Zhang --- drivers/atm/eni.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c index 316a9947541f..b574cce98dc3 100644 --- a/drivers/atm/eni.c +++ b/drivers/atm/eni.c @@ -2260,7 +2260,8 @@ static int eni_init_one(struct pci_dev *pci_dev, return rc; err_eni_release: - eni_do_release(dev); + dev->phy = NULL; + iounmap(ENI_DEV(dev)->ioaddr); err_unregister: atm_dev_deregister(dev); err_free_consistent: -- 2.25.1
