date:20200516

The pull request you sent on Sat, 16 May 2020 22:11:47 +1000:

> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
> tags/powerpc-5.7-4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/befc42e5dd4977b63dd3b0c0db05e21d56f13c2e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] csky updates for v5.7-rc6

The pull request you sent on Sat, 16 May 2020 17:33:36 +0800:

> https://github.com/c-sky/csky-linux.git tags/csky-for-linus-5.7-rc6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/26b089a7fc3301d8f53f99dd3607513d7700b505

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] KVM changes for Linux 5.7-rc6

The pull request you sent on Sat, 16 May 2020 08:24:13 -0400:

> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5d438e071f09845f0abd1464b52cddee880c2364

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

INFO: trying to register non-static key in io_cqring_ev_posted (3)

2020-05-16 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:ac935d22 Add linux-next specific files for 20200415
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12deaa5e10
kernel config:  https://syzkaller.appspot.com/x/.config?x=bc498783097e9019
dashboard link: https://syzkaller.appspot.com/bug?extid=8c91f5d054e998721c57
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11d54c0210
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17461e0610

The bug was bisected to:

commit b41e98524e424d104aa7851d54fd65820759875a
Author: Jens Axboe 
Date:   Mon Feb 17 16:52:41 2020 +

io_uring: add per-task callback handler

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1488dc3c10
final crash:https://syzkaller.appspot.com/x/report.txt?x=1688dc3c10
console output: https://syzkaller.appspot.com/x/log.txt?x=1288dc3c10

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8c91f5d054e998721...@syzkaller.appspotmail.com
Fixes: b41e98524e42 ("io_uring: add per-task callback handler")

RSP: 002b:7fffb1fb9aa8 EFLAGS: 0246 ORIG_RAX: 01a9
RAX: ffda RBX:  RCX: 00441319
RDX: 0001 RSI: 2140 RDI: 047b
RBP: 00010475 R08: 0001 R09: 004002c8
R10:  R11: 0246 R12: 00402260
R13: 004022f0 R14:  R15: 
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 7090 Comm: syz-executor222 Not tainted 
5.7.0-rc1-next-20200415-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x188/0x20d lib/dump_stack.c:118
 assign_lock_key kernel/locking/lockdep.c:913 [inline]
 register_lock_class+0x1664/0x1760 kernel/locking/lockdep.c:1225
 __lock_acquire+0x104/0x4c50 kernel/locking/lockdep.c:4234
 lock_acquire+0x1f2/0x8f0 kernel/locking/lockdep.c:4934
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
 __wake_up_common_lock+0xb4/0x130 kernel/sched/wait.c:122
 io_cqring_ev_posted+0xa5/0x1e0 fs/io_uring.c:1160
 io_poll_remove_all fs/io_uring.c:4357 [inline]
 io_ring_ctx_wait_and_kill+0x2bc/0x5a0 fs/io_uring.c:7305
 io_uring_create fs/io_uring.c:7843 [inline]
 io_uring_setup+0x115e/0x22b0 fs/io_uring.c:7870
 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x441319
Code: e8 5c ae 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fffb1fb9aa8 EFLAGS: 0246 ORIG_RAX: 01a9
RAX: ffda RBX:  RCX: 00441319
RDX: 0001 RSI: 2140 RDI: 047b
RBP: 00010475 R08: 0001 R09: 004002c8
R10:  R11: 0246 R12: 00402260
R13: 004022f0 R14:  R15: 
general protection fault, probably for non-canonical address 
0xdc00:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x-0x0007]
CPU: 1 PID: 7090 Comm: syz-executor222 Not tainted 
5.7.0-rc1-next-20200415-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:__read_once_size include/linux/compiler.h:232 [inline]
RIP: 0010:__wake_up_common+0xdc/0x600 kernel/sched/wait.c:86
Code: b9 04 00 00 4c 8b 43 40 49 83 e8 18 49 8d 78 18 48 39 fd 0f 84 d0 00 00 
00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 e3 04 
00 00 49 bd 00 00 00 00 00 fc ff df 4d 8b
RSP: 0018:c90001677c20 EFLAGS: 00010046
RAX: dc00 RBX: 8880a6081120 RCX: 11517002
RDX:  RSI: 0003 RDI: 
RBP: 8880a6081160 R08: ffe8 R09: c90001677cb8
R10: 0003 R11: f520002cef7e R12: 0001
R13:  R14: 0003 R15: 
FS:  0136f880() GS:8880ae70() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2140 CR3: 936b4000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __wake_up_common_lock+0xd0/0x130 kernel/sched/wait.c:123
 io_cqring_ev_posted+0xa5/0x1e0 fs/io_uring.c:1160
 io_poll_remove_all fs/io_uring.c:4357 [inline]
 io_ring_ctx_wait_and_kill+0x2bc/0x5a0

Re: [rcu] 2f08469563: BUG:kernel_reboot-without-warning_in_boot_stage

2020-05-16 Thread Paul E. McKenney

On Sun, May 17, 2020 at 09:17:32AM +0800, kernel test robot wrote:
> Greeting,
> 
> FYI, we noticed the following commit (built with clang-11):
> 
> commit: 2f08469563550d15cb08a60898d3549720600eee ("rcu: Mark rcu_state.ncpus 
> to detect concurrent writes")
> https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git 
> dev.2020.05.14c
> 
> in testcase: boot
> 
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> 
> 
> 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot 
> 
> 
> [0.054943] BRK [0x05204000, 0x05204fff] PGTABLE
> [0.061181] BRK [0x05205000, 0x05205fff] PGTABLE
> [0.062403] BRK [0x05206000, 0x05206fff] PGTABLE
> [0.065200] RAMDISK: [mem 0x7a247000-0x7fff]
> [0.067344] ACPI: Early table checksum verification disabled
> BUG: kernel reboot-without-warning in boot stage

I am having some difficulty believing that this commit is at fault given
that the .config does not list CONFIG_KCSAN=y, but CCing Marco Elver
for his thoughts.  Especially given that I have never built with clang-11.

But this does invoke ASSERT_EXCLUSIVE_WRITER() in early boot from
rcu_init().  Might clang-11 have objections to early use of this macro?

Thanx, Paul

> Elapsed time: 60
> 
> qemu-img create -f qcow2 disk-vm-snb-16-0 256G
> qemu-img create -f qcow2 disk-vm-snb-16-1 256G
> 
> 
> To reproduce:
> 
> # build kernel
>   cd linux
>   cp config-5.7.0-rc2-3-g2f08469563550 .config
>   make HOSTCC=clang-11 CC=clang-11 ARCH=x86_64 olddefconfig prepare 
> modules_prepare bzImage
> 
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k  job-script # job-script is attached in this 
> email
> 
> 
> 
> Thanks,
> Rong Chen
> 

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 5.7.0-rc2 Kernel Configuration
> #
> 
> #
> # Compiler: clang version 11.0.0 (git://gitmirror/llvm_project 
> 54b35c066417d4856e9d53313f7e98b354274584)
> #
> CONFIG_GCC_VERSION=0
> CONFIG_LD_VERSION=0
> CONFIG_CC_IS_CLANG=y
> CONFIG_CLANG_VERSION=11
> CONFIG_CC_CAN_LINK=y
> CONFIG_CC_HAS_ASM_GOTO=y
> CONFIG_CC_HAS_ASM_INLINE=y
> # CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED is not set
> CONFIG_CONSTRUCTORS=y
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_TABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> # CONFIG_COMPILE_TEST is not set
> # CONFIG_UAPI_HEADER_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_BUILD_SALT=""
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> # CONFIG_KERNEL_GZIP is not set
> CONFIG_KERNEL_BZIP2=y
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> # CONFIG_SYSVIPC is not set
> # CONFIG_POSIX_MQUEUE is not set
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_USELIB=y
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_MIGRATION=y
> CONFIG_HARDIRQS_SW_RESEND=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_SIM=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> CONFIG_IRQ_MSI_IOMMU=y
> CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
> CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> # CONFIG_GENERIC_IRQ_DEBUGFS is not set
> # end of IRQ subsystem
> 
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_INIT=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> # CONFIG_HIGH_RES_TIMERS is not set
> # end of Timers subsystem
> 
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> CONFIG_PREEMPT_COUNT=y
> 
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> CONFIG_IRQ_TIME_ACCOUNTING=y
> CONFIG_HAVE_SCHED_AVG_IRQ=y
> # CONFIG_SCHED_THERMAL_PRESSURE is not set
> CONFIG_BSD_PROCESS_ACCT=y
> CONFIG_BSD_PROCESS_ACCT_V3=y
> # CONFIG_TASKSTATS is not set
> CONFIG_PSI=y
> CONFIG_PSI_DEFAULT_DISABLED=y
> # end of CPU/Task time and stats

[PATCH] Documentation: admin-guide: update bug-hunting.rst

2020-05-16 Thread Randy Dunlap

From: Randy Dunlap 

Update Documentation/admin-guide/bug-hunting.rst:

- add a small section on "Modules linked in" and their possible flags;
- delete all references to ksymoops since it is no longer applicable;
- fix spello, grammar, and punctuation;
- note that get_maintainers.pl only provides recent patchers if it is
  run inside a git tree;
- add mention of scripts/decode_stacktrace.sh;

Signed-off-by: Randy Dunlap 
Cc: g...@wind.rmcc.com
---
 Documentation/admin-guide/bug-hunting.rst |   53 +++-
 1 file changed, 31 insertions(+), 22 deletions(-)

--- linux-next-20200515.orig/Documentation/admin-guide/bug-hunting.rst
+++ linux-next-20200515/Documentation/admin-guide/bug-hunting.rst
@@ -49,15 +49,19 @@ the issue, it may also contain the word
 
 Despite being an **Oops** or some other sort of stack trace, the offended
 line is usually required to identify and handle the bug. Along this chapter,
-we'll refer to "Oops" for all kinds of stack traces that need to be analized.
+we'll refer to "Oops" for all kinds of stack traces that need to be analyzed.
 
-.. note::
+If the kernel is compiled with ``CONFIG_DEBUG_INFO``, you can enhance the
+quality of the stack trace by using file:`scripts/decode_stacktrace.sh`.
+
+Modules linked in
+-
+
+Modules that are tainted or are being loaded or unloaded are marked with
+"(...)", where the taint flags are described in
+file:`Documentation/admin-guide/tainted-kernels.rst`, "being loaded" is
+annotated with "+", and "being unloaded" is annotated with "-".
 
-  ``ksymoops`` is useless on 2.6 or upper.  Please use the Oops in its original
-  format (from ``dmesg``, etc).  Ignore any references in this or other docs to
-  "decoding the Oops" or "running it through ksymoops".
-  If you post an Oops from 2.6+ that has been run through ``ksymoops``,
-  people will just tell you to repost it.
 
 Where is the Oops message is located?
 -
@@ -71,7 +75,7 @@ by running ``journalctl`` command.
 Sometimes ``klogd`` dies, in which case you can run ``dmesg > file`` to
 read the data from the kernel buffers and save it.  Or you can
 ``cat /proc/kmsg > file``, however you have to break in to stop the transfer,
-``kmsg`` is a "never ending file".
+since ``kmsg`` is a "never ending file".
 
 If the machine has crashed so badly that you cannot enter commands or
 the disk is not available then you have three options:
@@ -81,9 +85,9 @@ the disk is not available then you have
 planned for a crash. Alternatively, you can take a picture of
 the screen with a digital camera - not nice, but better than
 nothing.  If the messages scroll off the top of the console, you
-may find that booting with a higher resolution (eg, ``vga=791``)
+may find that booting with a higher resolution (e.g., ``vga=791``)
 will allow you to read more of the text. (Caveat: This needs ``vesafb``,
-so won't help for 'early' oopses)
+so won't help for 'early' oopses.)
 
 (2) Boot with a serial console (see
 :ref:`Documentation/admin-guide/serial-console.rst `),
@@ -104,7 +108,7 @@ Kernel source file. There are two method
 gdb
 ^^^
 
-The GNU debug (``gdb``) is the best way to figure out the exact file and line
+The GNU debugger (``gdb``) is the best way to figure out the exact file and 
line
 number of the OOPS from the ``vmlinux`` file.
 
 The usage of gdb works best on a kernel compiled with ``CONFIG_DEBUG_INFO``.
@@ -165,7 +169,7 @@ If you have a call trace, such as::
   [] :jbd:journal_stop+0x1be/0x1ee
   ...
 
-this shows the problem likely in the :jbd: module. You can load that module
+this shows the problem likely is in the :jbd: module. You can load that module
 in gdb and list the relevant code::
 
   $ gdb fs/jbd/jbd.ko
@@ -199,8 +203,9 @@ in the kernel hacking menu of the menu c
You need to be at the top level of the kernel tree for this to pick up
your C files.
 
-If you don't have access to the code you can also debug on some crash dumps
-e.g. crash dump output as shown by Dave Miller::
+If you don't have access to the source code you can still debug some crash
+dumps using the following method (example crash dump output as shown by
+Dave Miller)::
 
  EIP is at +0x14/0x4c0
   ...
@@ -230,6 +235,9 @@ e.g. crash dump output as shown by Dave
  mov0x8(%ebp), %ebx ! %ebx = skb->sk
  mov0x13c(%ebx), %eax   ! %eax = inet_sk(sk)->opt
 
+file:`scripts/decodecode` can be used to automate most of this, depending
+on what CPU architecture is being debugged.
+
 Reporting the bug
 -
 
@@ -241,7 +249,7 @@ used for the development of the affected
 the ``get_maintainer.pl`` script.
 
 For example, if you find a bug at the gspca's sonixj.c file, you can get
-their maintainers with::
+its maintainers with::
 
$ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
Hans Verkuil  (odd fixer:GSPCA USB WEBCAM

Re: [PATCH v11 33/56] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators

2020-05-16 Thread Wang, Jiada


Hello Dmitry

On 2020/05/14 13:53, Dmitry Osipenko wrote:

13.05.2020 08:07, Wang, Jiada пишет:

Hello Dmitry

On 2020/05/12 8:13, Dmitry Osipenko wrote:

11.05.2020 05:05, Wang, Jiada пишет:

Hello Dmitry

Thanks for your comment and test,

can you let me know which platform (board) you are using for test,
and DTS changes if you have added any.


That's this device-tree [1] without any extra changes.


I am using Samsung Chromebook Pro for testing,
but obviously some of the use cases it can't cover.

I also would like to test on same device you are using,
would you please let me know how to boot Acer Iconia Tab A500
with custom images. Are you booting Linux or Android on it?


I'm using Ubuntu 20.04 on it at the moment. In order to boot custom
images you'll need at least to install a custom recovery, which will
allow to flash boot.img on eMMC storage.

Ideally, you'll need to install an unlocked bootloader that will enable
Android's fastboot, and thus, allow to easily boot kernel zImage without
messing with flashing boot images.

Could you please tell what is the current state of yours device: does it
have a stock Android installed? is it rooted? is custom recovery installed?


Thanks for your information

By following instructions found in XDA forums,
now I am able to install an unlocked bootloader,
boot among primary kernel, recovery kernel or fastboot,
an Android custom stock rom also has been installed

Could you please let me know how to install local built ubuntu images

Thanks,
Jiada


My device was unlocked about 8+ years ago, so I'm not sure what's the
best way to do it nowadays. The XDA forums [1] could be a good starting
point, I may give you some advises once you'll tell what's the current
status of yours device.

[1] https://forum.xda-developers.com/iconia-a500

[rcu:lkmm] BUILD SUCCESS 7ab9d2b00209d140e02042e027f6e5f98f1dbec7

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  lkmm
branch HEAD: 7ab9d2b00209d140e02042e027f6e5f98f1dbec7  
Documentation/litmus-tests: Cite an RCU litmus test

elapsed time: 602m

configs tested: 104
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
m68k allyesconfig
mips allyesconfig
sparcallyesconfig
mipsmalta_kvm_guest_defconfig
archsdk_defconfig
arc   tb10x_defconfig
h8300alldefconfig
powerpc   allnoconfig
xtensaxip_kc705_defconfig
mips pnx8335_stb225_defconfig
xtensa  defconfig
ia64 allyesconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
x86_64   randconfig-a005-20200517
x86_64   randconfig-a003-20200517
x86_64   randconfig-a006-20200517
x86_64   randconfig-a004-20200517
x86_64   randconfig-a001-20200517
x86_64   randconfig-a002-20200517
i386 randconfig-a006-20200517
i386 randconfig-a005-20200517
i386 randconfig-a003-20200517
i386 randconfig-a001-20200517
i386 randconfig-a004-20200517
i386 randconfig-a002-20200517
i386 randconfig-a012-20200517
i386 randconfig-a016-20200517
i386 randconfig-a014-20200517
i386 randconfig-a011-20200517
i386 randconfig-a013-20200517
i386 randconfig-a015-20200517
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
x86_64  defconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64   rhel
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64

Re: [PATCH v2 3/4] hung_task: Move hung_task sysctl interface to hung_task.c

2020-05-16 Thread Xiaoming Ni


On 2020/5/17 10:43, Kees Cook wrote:

On Sat, May 16, 2020 at 04:55:14PM +0800, Xiaoming Ni wrote:

+/*
+ * This is needed for proc_doulongvec_minmax of sysctl_hung_task_timeout_secs
+ * and hung_task_check_interval_secs
+ */
+static unsigned long hung_task_timeout_max = (LONG_MAX / HZ);


Please make this const. With that done, yes, looks great!

Reviewed-by: Kees Cook 



Thank you for your guidance, I will fix it in v3

In addition, I am a bit confused about the patch submission, and hope to 
get everyone's answer.
  I made this patch based on the master branch. But as in conflict at 
https://lkml.org/lkml/2020/5/10/413, my patch will inevitably conflict. 
Should I modify to make patch based on "linux-next" branch to avoid 
conflict, or other branches?


Thanks
Xiaoming Ni

arch/x86/kernel/apm_32.c:428:43: sparse: sparse: cast truncates bits from constant value (40000400 becomes 400)

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   3d1c1e5931ce45b3a3f309385bbc00c78e9951c6
commit: 1651e700664b4597ddf4f8adfe435252a0d11277 x86: Fix bitops.h warning with 
a moved cast
date:   9 weeks ago
config: i386-randconfig-s002-20200517 (attached as .config)
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-193-gb8fad4bc-dirty
git checkout 1651e700664b4597ddf4f8adfe435252a0d11277
# save the attached .config to linux build tree
make C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 


sparse warnings: (new ones prefixed by >>)

>> arch/x86/kernel/apm_32.c:428:43: sparse: sparse: cast truncates bits from 
>> constant value (4400 becomes 400)

vim +428 arch/x86/kernel/apm_32.c

c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09  421  
c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09  422  /*
c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09  423   * Set 
up a segment that references the real mode segment 0x40
c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09  424   * that 
extends up to the end of page zero (that we have reserved).
c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09  425   * This 
is for buggy BIOS's that refer to (real mode) segment 0x40
c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09  426   * even 
though they are called in protected mode.
c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09  427   */
c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09 @428  static 
struct desc_struct bad_bios_desc = GDT_ENTRY_INIT(0x4092,
c7425314c755d5 arch/x86/kernel/apm_32.c Akinobu Mita   2009-08-09  429  
(unsigned long)__va(0x400UL), PAGE_SIZE - 0x400 - 1);
^1da177e4c3f41 arch/i386/kernel/apm.c   Linus Torvalds 2005-04-16  430  

:: The code at line 428 was first introduced by commit
:: c7425314c755d5f94da7c978205c85a7c6201212 x86: Introduce 
GDT_ENTRY_INIT(), initialize bad_bios_desc statically

:: TO: Akinobu Mita 
:: CC: Ingo Molnar 

---
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 4/4] watchdog: move watchdog sysctl interface to watchdog.c

On Sat, May 16, 2020 at 04:55:15PM +0800, Xiaoming Ni wrote:
> Move watchdog syscl interface to watchdog.c.
> Use register_sysctl() to register the sysctl interface to avoid
> merge conflicts when different features modify sysctl.c at the same time.
> 
> Signed-off-by: Xiaoming Ni 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH v2 1/4] sysctl: Add register_sysctl_init() interface

On Sat, May 16, 2020 at 04:55:12PM +0800, Xiaoming Ni wrote:
> In order to eliminate the duplicate code for registering the sysctl
> interface during the initialization of each feature, add the
> register_sysctl_init() interface
> 
> Signed-off-by: Xiaoming Ni 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH v2 3/4] hung_task: Move hung_task sysctl interface to hung_task.c

On Sat, May 16, 2020 at 04:55:14PM +0800, Xiaoming Ni wrote:
> +/*
> + * This is needed for proc_doulongvec_minmax of sysctl_hung_task_timeout_secs
> + * and hung_task_check_interval_secs
> + */
> +static unsigned long hung_task_timeout_max = (LONG_MAX / HZ);

Please make this const. With that done, yes, looks great!

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH v2 2/4] sysctl: Move some boundary constants form sysctl.c to sysctl_vals

On Sat, May 16, 2020 at 04:55:13PM +0800, Xiaoming Ni wrote:
> Some boundary (.extra1 .extra2) constants (E.g: neg_one two) in
> sysctl.c are used in multiple features. Move these variables to
> sysctl_vals to avoid adding duplicate variables when cleaning up
> sysctls table.
> 
> Signed-off-by: Xiaoming Ni 

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH 2/4] proc/sysctl: add shared variables -1

On Sat, May 16, 2020 at 11:05:53AM +0800, Xiaoming Ni wrote:
> On 2020/5/16 10:47, Kees Cook wrote:
> > On Sat, May 16, 2020 at 10:32:19AM +0800, Xiaoming Ni wrote:
> > > On 2020/5/16 0:05, Kees Cook wrote:
> > > > On Fri, May 15, 2020 at 05:06:28PM +0800, Xiaoming Ni wrote:
> > > > > On 2020/5/15 16:06, Kees Cook wrote:
> > > > > > On Fri, May 15, 2020 at 12:33:42PM +0800, Xiaoming Ni wrote:
> > > > > > > Add the shared variable SYSCTL_NEG_ONE to replace the variable 
> > > > > > > neg_one
> > > > > > > used in both sysctl_writes_strict and hung_task_warnings.
> > > > > > > 
> > > > > > > Signed-off-by: Xiaoming Ni 
> > > > > > > ---
> > > > > > > fs/proc/proc_sysctl.c | 2 +-
> > > > > > > include/linux/sysctl.h| 1 +
> > > > > > > kernel/hung_task_sysctl.c | 3 +--
> > > > > > > kernel/sysctl.c   | 3 +--
> > > > > > 
> > > > > > How about doing this refactoring in advance of the extraction patch?
> > > > > Before  advance of the extraction patch, neg_one is only used in one 
> > > > > file,
> > > > > does it seem to have no value for refactoring?
> > > > 
> > > > I guess it doesn't matter much, but I think it's easier to review in the
> > > > sense that neg_one is first extracted and then later everything else is
> > > > moved.
> > > > 
> > > Later, when more features sysctl interface is moved to the code file, 
> > > there
> > > will be more variables that need to be extracted.
> > > So should I only extract the neg_one variable here, or should I extract 
> > > all
> > > the variables used by multiple features?
> > 
> > Hmm -- if you're going to do a consolidation pass, then nevermind, I
> > don't think order will matter then.
> > 
> > Thank you for the cleanup! Sorry we're giving you back-and-forth advice!
> > 
> > -Kees
> > 
> 
> Sorry, I don't fully understand.
> Does this mean that there is no need to adjust the patch order or the order
> of variables in sysctl_vals?
> Should I extract only SYSCTL_NEG_ONE or should I extract all variables?

I think either order is fine -- I though you were only doing 1 variable.
If you're don't a bunch, then I don't think order is important.

-- 
Kees Cook

Re: [PATCH v2 3/4] mm/slub: Fix another circular locking dependency in slab_attr_store()




> On Apr 27, 2020, at 7:56 PM, Waiman Long  wrote:
> 
> It turns out that switching from slab_mutex to memcg_cache_ids_sem in
> slab_attr_store() does not completely eliminate circular locking dependency
> as shown by the following lockdep splat when the system is shut down:
> 
> [ 2095.079697] Chain exists of:
> [ 2095.079697]   kn->count#278 --> memcg_cache_ids_sem --> slab_mutex
> [ 2095.079697]
> [ 2095.090278]  Possible unsafe locking scenario:
> [ 2095.090278]
> [ 2095.096227]CPU0CPU1
> [ 2095.100779]
> [ 2095.105331]   lock(slab_mutex);
> [ 2095.108486]lock(memcg_cache_ids_sem);
> [ 2095.114961]lock(slab_mutex);
> [ 2095.120649]   lock(kn->count#278);
> [ 2095.124068]
> [ 2095.124068]  *** DEADLOCK ***

Can you show the full splat?

> 
> To eliminate this possibility, we have to use trylock to acquire
> memcg_cache_ids_sem. Unlikely slab_mutex which can be acquired in
> many places, the memcg_cache_ids_sem write lock is only acquired
> in memcg_alloc_cache_id() to double the size of memcg_nr_cache_ids.
> So the chance of successive calls to memcg_alloc_cache_id() within
> a short time is pretty low. As a result, we can retry the read lock
> acquisition a few times if the first attempt fails.
> 
> Signed-off-by: Waiman Long 

The code looks a bit hacky and probably not that robust. Since it is the 
shutdown path which is not all that important without lockdep, maybe you could 
drop this single patch for now until there is a better solution?

> ---
> include/linux/memcontrol.h |  1 +
> mm/memcontrol.c|  5 +
> mm/slub.c  | 25 +++--
> 3 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index d275c72c4f8e..9285f14965b1 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1379,6 +1379,7 @@ extern struct workqueue_struct *memcg_kmem_cache_wq;
> extern int memcg_nr_cache_ids;
> void memcg_get_cache_ids(void);
> void memcg_put_cache_ids(void);
> +int  memcg_tryget_cache_ids(void);
> 
> /*
>  * Helper macro to loop through all memcg-specific caches. Callers must still
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 5beea03dd58a..9fa8535ff72a 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -279,6 +279,11 @@ void memcg_get_cache_ids(void)
>down_read(_cache_ids_sem);
> }
> 
> +int memcg_tryget_cache_ids(void)
> +{
> +return down_read_trylock(_cache_ids_sem);
> +}
> +
> void memcg_put_cache_ids(void)
> {
>up_read(_cache_ids_sem);
> diff --git a/mm/slub.c b/mm/slub.c
> index 44cb5215c17f..cf2114ca27f7 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -34,6 +34,7 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include 
> 
> @@ -5572,6 +5573,7 @@ static ssize_t slab_attr_store(struct kobject *kobj,
>!list_empty(>memcg_params.children)) {
>struct kmem_cache *c, **pcaches;
>int idx, max, cnt = 0;
> +int retries = 3;
>size_t size, old = s->max_attr_size;
>struct memcg_cache_array *arr;
> 
> @@ -5585,9 +5587,28 @@ static ssize_t slab_attr_store(struct kobject *kobj,
>old = cmpxchg(>max_attr_size, size, len);
>} while (old != size);
> 
> -memcg_get_cache_ids();
> -max = memcg_nr_cache_ids;
> +/*
> + * To avoid the following circular lock chain
> + *
> + *   kn->count#278 --> memcg_cache_ids_sem --> slab_mutex
> + *
> + * We need to use trylock to acquire memcg_cache_ids_sem.
> + *
> + * Since the write lock is acquired only in
> + * memcg_alloc_cache_id() to double the size of
> + * memcg_nr_cache_ids. The chance of successive
> + * memcg_alloc_cache_id() calls within a short time is
> + * very low except at the beginning where the number of
> + * memory cgroups is low. So we retry a few times to get
> + * the memcg_cache_ids_sem read lock.
> + */
> +while (!memcg_tryget_cache_ids()) {
> +if (retries-- <= 0)
> +return -EBUSY;
> +msleep(100);
> +}
> 
> +max = memcg_nr_cache_ids;
>pcaches = kmalloc_array(max, sizeof(void *), GFP_KERNEL);
>if (!pcaches) {
>memcg_put_cache_ids();

[PATCH v6 3/7] partitions: Introduce NVIDIA Tegra Partition Table

All NVIDIA Tegra devices use a special partition table format for the
internal storage partitioning.  Most of Tegra devices have GPT partition
in addition to TegraPT, but some older Android consumer-grade devices do
not or GPT is placed in a wrong sector, and thus, the TegraPT is needed
in order to support these devices properly by the upstream kernel. This
patch adds support for NVIDIA Tegra Partition Table format that is used
at least by all NVIDIA Tegra20 and Tegra30 devices.

Tested-by: Nils Östlund 
Signed-off-by: Dmitry Osipenko 
---
 arch/arm/mach-tegra/tegra.c   |  54 
 block/partitions/Kconfig  |   8 +
 block/partitions/Makefile |   1 +
 block/partitions/check.h  |   1 +
 block/partitions/core.c   |   3 +
 block/partitions/tegra.c  | 567 ++
 include/soc/tegra/bootdata.h  |  46 +++
 include/soc/tegra/common.h|   9 +
 include/soc/tegra/partition.h |  84 +
 9 files changed, 773 insertions(+)
 create mode 100644 block/partitions/tegra.c
 create mode 100644 include/soc/tegra/bootdata.h
 create mode 100644 include/soc/tegra/partition.h

diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index c011359bcdb4..da6bcd85398b 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -28,7 +28,9 @@
 
 #include 
 
+#include 
 #include 
+#include 
 #include 
 
 #include 
@@ -62,9 +64,61 @@ u32 tegra_uart_config[3] = {
0,
 };
 
+static void __init tegra_boot_config_table_init(void)
+{
+   struct tegra30_boot_config_table __iomem *t30_bct;
+   struct tegra20_boot_config_table __iomem *t20_bct;
+   struct tegra20_boot_info_table   __iomem *t20_bit;
+   u32 iram_end   = TEGRA_IRAM_BASE + TEGRA_IRAM_SIZE;
+   u32 iram_start = TEGRA_IRAM_BASE;
+   u32 pt_addr, pt_size, bct_size;
+
+   t20_bit = IO_ADDRESS(TEGRA_IRAM_BASE);
+
+   if (of_machine_is_compatible("nvidia,tegra20")) {
+   bct_size = sizeof(*t20_bct);
+
+   if (t20_bit->bct_size != bct_size ||
+   t20_bit->bct_ptr < iram_start ||
+   t20_bit->bct_ptr > iram_end - bct_size)
+   return;
+
+   t20_bct = IO_ADDRESS(t20_bit->bct_ptr);
+
+   if (t20_bct->boot_data_version != TEGRA_BOOTDATA_VERSION_T20)
+   return;
+
+   pt_addr = t20_bct->partition_table_logical_sector_address;
+   pt_size = t20_bct->partition_table_num_logical_sectors;
+
+   } else if (of_machine_is_compatible("nvidia,tegra30")) {
+   bct_size = sizeof(*t30_bct);
+
+   if (t20_bit->bct_size != bct_size ||
+   t20_bit->bct_ptr < iram_start ||
+   t20_bit->bct_ptr > iram_end - bct_size)
+   return;
+
+   t30_bct = IO_ADDRESS(t20_bit->bct_ptr);
+
+   if (t30_bct->boot_data_version != TEGRA_BOOTDATA_VERSION_T30)
+   return;
+
+   pt_addr = t30_bct->partition_table_logical_sector_address;
+   pt_size = t30_bct->partition_table_num_logical_sectors;
+   } else {
+   return;
+   }
+
+   pr_info("%s: BCT found in IRAM\n", __func__);
+
+   tegra_partition_table_setup(pt_addr, pt_size);
+}
+
 static void __init tegra_init_early(void)
 {
of_register_trusted_foundations();
+   tegra_boot_config_table_init();
tegra_cpu_reset_handler_init();
call_firmware_op(l2x0_init);
 }
diff --git a/block/partitions/Kconfig b/block/partitions/Kconfig
index 702689a628f0..97cd4a030f98 100644
--- a/block/partitions/Kconfig
+++ b/block/partitions/Kconfig
@@ -268,3 +268,11 @@ config CMDLINE_PARTITION
help
  Say Y here if you want to read the partition table from bootargs.
  The format for the command line is just like mtdparts.
+
+config TEGRA_PARTITION
+   bool "NVIDIA Tegra Partition support" if PARTITION_ADVANCED
+   default y if ARCH_TEGRA
+   depends on MMC_BLOCK && (ARCH_TEGRA || COMPILE_TEST)
+   help
+ Say Y here if you would like to be able to read the hard disk
+ partition table format used by NVIDIA Tegra machines.
diff --git a/block/partitions/Makefile b/block/partitions/Makefile
index a7f05cdb02a8..83cb70c6d08d 100644
--- a/block/partitions/Makefile
+++ b/block/partitions/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_IBM_PARTITION) += ibm.o
 obj-$(CONFIG_EFI_PARTITION) += efi.o
 obj-$(CONFIG_KARMA_PARTITION) += karma.o
 obj-$(CONFIG_SYSV68_PARTITION) += sysv68.o
+obj-$(CONFIG_TEGRA_PARTITION) += tegra.o
diff --git a/block/partitions/check.h b/block/partitions/check.h
index c577e9ee67f0..ffa01cc4b0b0 100644
--- a/block/partitions/check.h
+++ b/block/partitions/check.h
@@ -67,4 +67,5 @@ int osf_partition(struct parsed_partitions *state);
 int sgi_partition(struct parsed_partitions *state);
 int sun_partition(struct parsed_partitions *state);
 int sysv68_partition(struct parsed_partitions

[PATCH v6 5/7] partitions/efi: Improve coding style

The 'efi.c' source code has a lot of coding style problems like:

  - trailing whitespaces
  - whitespaces instead of tabs
  - missing whitespaces where they actually needed
  - double blank-lines
  - improperly aligned code
  - improperly styled multi-line comments
  - unnecessarily assigned variables
  - NULL-checks that can't ever trigger

and etc.

This patch fixes few dozen of coding style problems without introducing
any functional changes, making code easier to read, and thus, easier to
maintain.

Signed-off-by: Dmitry Osipenko 
---
 block/partitions/efi.c | 354 -
 1 file changed, 175 insertions(+), 179 deletions(-)

diff --git a/block/partitions/efi.c b/block/partitions/efi.c
index 34c25f708733..f0229e7a6894 100644
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -23,7 +23,7 @@
  * - Ported to 2.5.7-pre1 and 2.5.7-dj2
  * - Applied patch to avoid fault in alternate header handling
  * - cleaned up find_valid_gpt
- * - On-disk structure and copy in memory is *always* LE now - 
+ * - On-disk structure and copy in memory is *always* LE now -
  *   swab fields as needed
  * - remove print_gpt_header()
  * - only use first max_p partition entries, to keep the kernel minor number
@@ -40,7 +40,7 @@
  * - moved le_efi_guid_to_cpus() back into this file.  GPT is the only
  *   thing that keeps EFI GUIDs on disk.
  * - Changed gpt structure names and members to be simpler and more Linux-like.
- * 
+ *
  * Wed Oct 17 2001 Matt Domsch 
  * - Removed CONFIG_DEVFS_VOLUMES_UUID code entirely per Martin Wilck
  *
@@ -65,7 +65,7 @@
  *
  * Wed Jun  6 2001 Martin Wilck 
  * - added devfs volume UUID support (/dev/volumes/uuids) for
- *   mounting file systems by the partition GUID. 
+ *   mounting file systems by the partition GUID.
  *
  * Tue Dec  5 2000 Matt Domsch 
  * - Moved crc32() to linux/lib, added efi_crc32().
@@ -82,15 +82,18 @@
  * - Code works, detects all the partitions.
  *
  /
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+
 #include "check.h"
 #include "efi.h"
 
-/* This allows a kernel command line option 'gpt' to override
+/*
+ * This allows a kernel command line option 'gpt' to override
  * the test for invalid PMBR.  Not __initdata because reloading
  * the partition tables happens after init too.
  */
@@ -103,14 +106,13 @@ force_gpt_fn(char *str)
 }
 __setup("gpt", force_gpt_fn);
 
-
 /**
  * efi_crc32() - EFI version of crc32 function
  * @buf: buffer to calculate crc32 of
  * @len: length of buf
  *
  * Description: Returns EFI-style CRC32 value for @buf
- * 
+ *
  * This function uses the little endian Ethernet polynomial
  * but seeds the function with ~0, and xor's with ~0 at the end.
  * Note, the EFI Specification, v1.02, has a reference to
@@ -125,7 +127,7 @@ efi_crc32(const void *buf, unsigned long len)
 /**
  * last_lba(): return number of last logical block of device
  * @bdev: block device
- * 
+ *
  * Description: Returns last LBA value on success, 0 on error.
  * This is stored (by sd and ide-geometry) in
  *  the part[0] entry for this disk, and is the number of
@@ -173,8 +175,8 @@ static inline int pmbr_part_valid(gpt_mbr_record *part)
  */
 static int is_pmbr_valid(legacy_mbr *mbr, sector_t total_sectors)
 {
-   uint32_t sz = 0;
-   int i, part = 0, ret = 0; /* invalid by default */
+   unsigned int i, sz = 0, part = 0;
+   int ret = 0; /* invalid by default */
 
if (!mbr || le16_to_cpu(mbr->signature) != MSDOS_MBR_SIGNATURE)
goto done;
@@ -195,11 +197,13 @@ static int is_pmbr_valid(legacy_mbr *mbr, sector_t 
total_sectors)
if (ret != GPT_MBR_PROTECTIVE)
goto done;
 check_hybrid:
-   for (i = 0; i < 4; i++)
-   if ((mbr->partition_record[i].os_type !=
-   EFI_PMBR_OSTYPE_EFI_GPT) &&
-   (mbr->partition_record[i].os_type != 0x00))
+   for (i = 0; i < 4; i++) {
+   if (mbr->partition_record[i].os_type != EFI_PMBR_OSTYPE_EFI_GPT 
&&
+   mbr->partition_record[i].os_type != 0x00) {
ret = GPT_MBR_HYBRID;
+   break;
+   }
+   }
 
/*
 * Protective MBRs take up the lesser of the whole disk
@@ -215,10 +219,9 @@ static int is_pmbr_valid(legacy_mbr *mbr, sector_t 
total_sectors)
 */
if (ret == GPT_MBR_PROTECTIVE) {
sz = le32_to_cpu(mbr->partition_record[part].size_in_lba);
-   if (sz != (uint32_t) total_sectors - 1 && sz != 0x)
-   pr_debug("GPT: mbr size in lba (%u) different than 
whole disk (%u).\n",
-sz, min_t(uint32_t,
-  total_sectors - 1, 0x));
+   if (sz != (u32)total_sectors - 1 && sz != 0x)
+   pr_debug("GPT: mbr size in lba (%u)

[PATCH v6 1/7] mmc: core: Add raw_boot_mult field to mmc_ext_csd

In order to support parsing of NVIDIA Tegra Partition Table format, we
need to know the BOOT_SIZE_MULT value of the Extended CSD register because
NVIDIA's bootloader linearizes the boot0/boot1/main partitions into a
single virtual space, and thus, all partition addresses are shifted by
the size of boot0 + boot1 partitions.

Signed-off-by: Dmitry Osipenko 
---
 drivers/mmc/core/mmc.c   | 2 ++
 include/linux/mmc/card.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 4203303f946a..112edfb1eb1d 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -417,6 +417,8 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
ext_csd[EXT_CSD_ERASE_TIMEOUT_MULT];
card->ext_csd.raw_hc_erase_grp_size =
ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE];
+   card->ext_csd.raw_boot_mult =
+   ext_csd[EXT_CSD_BOOT_MULT];
if (card->ext_csd.rev >= 3) {
u8 sa_shift = ext_csd[EXT_CSD_S_A_TIMEOUT];
card->ext_csd.part_config = ext_csd[EXT_CSD_PART_CONFIG];
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 7d46411ffaa2..cd6b58b66010 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -109,6 +109,7 @@ struct mmc_ext_csd {
u8  raw_hc_erase_gap_size;  /* 221 */
u8  raw_erase_timeout_mult; /* 223 */
u8  raw_hc_erase_grp_size;  /* 224 */
+   u8  raw_boot_mult;  /* 226 */
u8  raw_sec_trim_mult;  /* 229 */
u8  raw_sec_erase_mult; /* 230 */
u8  raw_sec_feature_support;/* 231 */
-- 
2.26.0

[PATCH v6 6/7] partitions/tegra: Support enforced GPT scanning

Downstream NVIDIA bootloader provides gpt_sector= kernel command
line option to the kernel. This option should instruct the GPT partition
parser to look at the specified sector for a valid GPT header if the GPT
is not found at the beginning or the end of a block device. Support of
this feature is needed by Tegra-based devices that have TegraPT and GPT
placed in inaccessible by kernel locations.  The GPT entry duplicates
TegraPT partitions.

Secondly, some Tegra-based devices have bootloader that enforces the GPT
scanning of the backup/alternative GPT entry by providing "gpt" cmdline
option to the kernel, but doesn't provide the "gpt_sector" option.
In this case GPT entry resides at a special offset from the end of eMMC
storage.  It is a common situation for older bootloader versions.

The offset is calculated as a total number of eMMC sectors minus number of
eMMC boot sectors minus 1.  This equation is explicitly defined and used
by the downstream Tegra kernels for locating GPT entry.

Signed-off-by: Dmitry Osipenko 
---
 block/partitions/check.h |  1 +
 block/partitions/core.c  |  1 +
 block/partitions/efi.c   |  9 +++
 block/partitions/tegra.c | 57 
 4 files changed, 68 insertions(+)

diff --git a/block/partitions/check.h b/block/partitions/check.h
index 55acf6340e5b..1ce445d1c7f0 100644
--- a/block/partitions/check.h
+++ b/block/partitions/check.h
@@ -68,5 +68,6 @@ int osf_partition(struct parsed_partitions *state);
 int sgi_partition(struct parsed_partitions *state);
 int sun_partition(struct parsed_partitions *state);
 int sysv68_partition(struct parsed_partitions *state);
+int tegra_partition_forced_gpt(struct parsed_partitions *state);
 int tegra_partition(struct parsed_partitions *state);
 int ultrix_partition(struct parsed_partitions *state);
diff --git a/block/partitions/core.c b/block/partitions/core.c
index 0b4720372f07..1931647d9742 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -83,6 +83,7 @@ static int (*check_part[])(struct parsed_partitions *) = {
sysv68_partition,
 #endif
 #ifdef CONFIG_TEGRA_PARTITION
+   tegra_partition_forced_gpt,
tegra_partition,
 #endif
NULL
diff --git a/block/partitions/efi.c b/block/partitions/efi.c
index f0229e7a6894..f8036fd55501 100644
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -101,6 +101,15 @@ static int force_gpt;
 static int __init
 force_gpt_fn(char *str)
 {
+   /*
+* This check allows to properly parse cmdline variants like
+* "gpt gpt_sector=" and "gpt_sector= gpt" since
+* "gpt" overlaps with the "gpt_sector=", see tegra_gpt_sector_fn().
+* The argument should be absent for a boolean cmdline option.
+*/
+   if (strlen(str))
+   return 0;
+
force_gpt = 1;
return 1;
 }
diff --git a/block/partitions/tegra.c b/block/partitions/tegra.c
index d3a00ade145a..831dedb9a11c 100644
--- a/block/partitions/tegra.c
+++ b/block/partitions/tegra.c
@@ -565,3 +565,60 @@ int tegra_partition(struct parsed_partitions *state)
 
return ret;
 }
+
+/*
+ * This allows a kernel command line option 'gpt_sector=' to
+ * enable GPT header lookup at a non-standard location. This option
+ * is provided to kernel by NVIDIA's proprietary bootloader.
+ */
+static sector_t tegra_gpt_sector;
+static int __init tegra_gpt_sector_fn(char *str)
+{
+   WARN_ON(kstrtoull(str, 10, _gpt_sector) < 0);
+   return 1;
+}
+__setup("gpt_sector=", tegra_gpt_sector_fn);
+
+int tegra_partition_forced_gpt(struct parsed_partitions *state)
+{
+   int ret = 0;
+
+#ifdef CONFIG_EFI_PARTITION
+   struct tegra_partition_table_parser ptp = {};
+
+   if (!soc_is_tegra() || !tegra_boot_sdmmc)
+   return 0;
+
+   ptp.state = state;
+
+   ptp.boot_offset = tegra_partition_table_emmc_boot_offset();
+   if (ptp.boot_offset < 0)
+   return 0;
+
+   /*
+* Some Tegra devices do not use gpt_sector= kernel command
+* line option. In this case these devices usually have a GPT entry
+* at the end of the block device and the GPT entry address is
+* calculated this way for eMMC:
+*
+* gpt_sector = ext_csd.sectors_num - ext_csd.boot_sectors_num - 1
+*
+* This algorithm is defined and used by NVIDIA in the downstream
+* kernel of those devices.
+*
+* Please note that bootloader supplies the "gpt" cmdline option
+* which enforces the GPT scanning, meaning that the scanning will
+* be a NO-OP on devices that do not use GPT.
+*/
+   if (tegra_gpt_sector) {
+   state->force_gpt_sector = tegra_gpt_sector;
+   } else {
+   state->force_gpt_sector  = get_capacity(state->bdev->bd_disk);
+   state->force_gpt_sector -= ptp.boot_offset + 1;
+   }
+
+   ret = efi_partition(state);
+   state->force_gpt_sector = 0;
+#endif
+

[PATCH v6 0/7] Introduce NVIDIA Tegra Partition Table

Hello,

This series adds support for the NVIDIA Tegra Partition Table format,
which is needed in order to support consumer-grade Tegra-based devices
by the upstream kernel. These devices have Secure Boot enabled and it
can't be disabled, and thus, it's not possible to easily modify bootloader
and eMMC storage partitioning.

Big thanks to everyone who helped with figuring out the TegraPT format
and with testing!

Changelog:

v6: - Now using a proper multi-line comments style in efi.c, thanks to
Randy Dunlap for the suggestion.

- Added new patch that improves coding style of partitions/efi.c

- Now both "gpt gpt_sector=" and "gpt_sector= gpt"
cmdline variants are parsed properly. I found that the second variant
wasn't working in v5.

- Fixed accidentally swapped GFP_KERNEL flag and allocation size passed
to kmalloc() in the patch "Expose Boot Configuration Table via sysfs".
Thanks to KASAN for reporting the problem.

v5: - Corrected Kconfig dependency, like it was suggested by Randy Dunlap
in the review comment to v4.

- Corrected a typo in the commit message, which was spotted by
Steve McIntyre in v4.

- The new force_gpt_sector variable has been moved out to the common
parser state because I realized that multiple drives could be scanned
simultaneously, and thus, a global shared variable isn't a suitable
variant.

- The Tegra's enforced GPT-scan now supports older bootloader versions,
which do not provide the gpt_sector= command line option. The gpt_sector
should be calculated using NVIDIA's algorithm in this case.

v4: - Scanning of the eMMC boot partitions has been dropped because it
requires a bit too messy hacks in the kernel. We can live without
this feature, at least for now it's not really needed.

- Instead of the dropped boot partitions scanning, the "gpt_sector="
command line option has been brought back [1]. But now it's done
in a different way, not bothering platforms other than Tegra and
not touching block devices other than eMMC, which was requested during
of the [1] review. The "gpt_sector=" usage is needed when partition
table is inaccessible by kernel, which is the case for the Ouya game
console device for example. Please note that "gpt_sector=" is not
available on all devices, such devices will fall back to the TegraPT,
Samsung Galaxy Tab 10.1 is an example of a such device.

[1]
https://patchwork.ozlabs.org/project/linux-tegra/patch/20200219162339.16192-1-dig...@gmail.com/

- We got a bit more broad testing and discovered that Samsung Galaxy
Tab 10.1 uses 2K logical sectors instead of 4K. So the 2K sectors
are supported now by the TegraPT parser. Thanks to Nils Östlund for
the testing!

- TegraPT parser now utilizes "tegraboot=" cmdline option which is
passed to kernel by the NVIDIA's bootloader. It's used for verifying
that SDMMC device is *the* boot source.

- Added patch that exposes Boot Configuration Table to userspace via
sysfs. Thanks to Michał Mirosław for the suggestion!

- Misc changes:
- The EB2 (second bootloader) partition is added to the list of
known partitions. Used by the Galaxy Tab 10.

- The blkdev logical sector size is checked now, for consistency.
It always should be 512 bytes on the supported/tested devices.

- Verbose error messages are replaced with pr_debug().

v3: - Fixed "BUG: KASAN: slab-out-of-bounds in tegra_partition". Thanks to
Peter Geis for noticing the problem.

- The MMC boot partitions scanning is now opt-in. See this patch:

mmc: block: Support partition-table scanning on boot partitions

- The found MMC boot partitions won't be assigned to the MMC boot
block device ever due to the new GENHD_FL_PART_SCAN_ONCE flag.

This makes us to ensure that the old behavior of the MMC core is
preserved for a non-Tegra MMC-block users.

New patches in v3:

block: Introduce GENHD_FL_PART_SCAN_ONCE
mmc: sdhci-tegra: Enable boot partitions scanning on Tegra20 and Tegra30

v2: - Addressed v1 review comments from Stephen Warren by using BIT for
locating BCT position in IRAM.

- Added more validations to the TegraPT parser: partition type is
verified, eMMC instance ID is verified.

- TegraPT parser now doesn't touch any devices other than eMMC.

- EKS (encrypted keys) partition is blacklisted now.

- Implemented eMMC boot partitions scanning. These new patches are
added in a result:

mmc: block: Add mmc_bdev_to_part_type() helper
mmc: block: Add mmc_bdev_to_area_type() helper
mmc: block: Add MMC_QUIRK_RESCAN_MAIN_BLKDEV
mmc: block: Enable partition-table scanning for boot partitions
partitions/tegra: Implement eMMC boot partitions scanning

Dmitry Osipenko (7):

[PATCH v6 7/7] soc/tegra: Expose Boot Configuration Table via sysfs

It's quite useful to have unencrypted BCT exposed to userspace for
debugging purposes, so let's expose it via sysfs.  The BCT data will be
present in '/sys/tegra/boot_config_table' binary file if BCT is available.

Suggested-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
---
 arch/arm/mach-tegra/tegra.c  |  4 +++
 drivers/soc/tegra/Makefile   |  1 +
 drivers/soc/tegra/bootdata.c | 51 
 drivers/soc/tegra/common.c   | 17 
 include/soc/tegra/bootdata.h |  2 ++
 include/soc/tegra/common.h   |  3 +++
 6 files changed, 78 insertions(+)
 create mode 100644 drivers/soc/tegra/bootdata.c

diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index da6bcd85398b..5f40463f1b97 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -72,6 +72,7 @@ static void __init tegra_boot_config_table_init(void)
u32 iram_end   = TEGRA_IRAM_BASE + TEGRA_IRAM_SIZE;
u32 iram_start = TEGRA_IRAM_BASE;
u32 pt_addr, pt_size, bct_size;
+   void __iomem *bct_ptr;
 
t20_bit = IO_ADDRESS(TEGRA_IRAM_BASE);
 
@@ -90,6 +91,7 @@ static void __init tegra_boot_config_table_init(void)
 
pt_addr = t20_bct->partition_table_logical_sector_address;
pt_size = t20_bct->partition_table_num_logical_sectors;
+   bct_ptr = t20_bct;
 
} else if (of_machine_is_compatible("nvidia,tegra30")) {
bct_size = sizeof(*t30_bct);
@@ -106,12 +108,14 @@ static void __init tegra_boot_config_table_init(void)
 
pt_addr = t30_bct->partition_table_logical_sector_address;
pt_size = t30_bct->partition_table_num_logical_sectors;
+   bct_ptr = t30_bct;
} else {
return;
}
 
pr_info("%s: BCT found in IRAM\n", __func__);
 
+   tegra_bootdata_bct_setup(bct_ptr, bct_size);
tegra_partition_table_setup(pt_addr, pt_size);
 }
 
diff --git a/drivers/soc/tegra/Makefile b/drivers/soc/tegra/Makefile
index 9c809c1814bd..8be2bfb4d95d 100644
--- a/drivers/soc/tegra/Makefile
+++ b/drivers/soc/tegra/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y += fuse/
 
+obj-y += bootdata.o
 obj-y += common.o
 obj-$(CONFIG_SOC_TEGRA_FLOWCTRL) += flowctrl.o
 obj-$(CONFIG_SOC_TEGRA_PMC) += pmc.o
diff --git a/drivers/soc/tegra/bootdata.c b/drivers/soc/tegra/bootdata.c
new file mode 100644
index ..3d028e0d343d
--- /dev/null
+++ b/drivers/soc/tegra/bootdata.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+ * spare_bct[] will be released once kernel is booted, hence not wasting
+ * kernel space if BCT is missing. The tegra_bct can't be allocated during
+ * of BCT setting up because it's too early for the slab allocator.
+ */
+static u8 spare_bct[SZ_8K] __initdata;
+static u8 *tegra_bct;
+
+static ssize_t boot_config_table_read(struct file *filp,
+ struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+   memcpy(buf, tegra_bct + off, count);
+   return count;
+}
+static BIN_ATTR_RO(boot_config_table, 0);
+
+static int __init tegra_bootdata_bct_sysfs_init(void)
+{
+   if (!bin_attr_boot_config_table.size)
+   return 0;
+
+   tegra_bct = kmalloc(bin_attr_boot_config_table.size, GFP_KERNEL);
+   if (!tegra_bct)
+   return -ENOMEM;
+
+   memcpy(tegra_bct, spare_bct, bin_attr_boot_config_table.size);
+
+   return sysfs_create_bin_file(tegra_soc_kobj,
+_attr_boot_config_table);
+}
+late_initcall(tegra_bootdata_bct_sysfs_init)
+
+void __init tegra_bootdata_bct_setup(void __iomem *bct_ptr, size_t bct_size)
+{
+   memcpy_fromio(spare_bct, bct_ptr, bct_size);
+   bin_attr_boot_config_table.size = bct_size;
+}
diff --git a/drivers/soc/tegra/common.c b/drivers/soc/tegra/common.c
index 3dc54f59cafe..2b4b49eacb2e 100644
--- a/drivers/soc/tegra/common.c
+++ b/drivers/soc/tegra/common.c
@@ -3,10 +3,15 @@
  * Copyright (C) 2014 NVIDIA CORPORATION.  All rights reserved.
  */
 
+#include 
+#include 
 #include 
+#include 
 
 #include 
 
+struct kobject *tegra_soc_kobj;
+
 static const struct of_device_id tegra_machine_match[] = {
{ .compatible = "nvidia,tegra20", },
{ .compatible = "nvidia,tegra30", },
@@ -31,3 +36,15 @@ bool soc_is_tegra(void)
 
return match != NULL;
 }
+
+static int __init tegra_soc_sysfs_init(void)
+{
+   if (!soc_is_tegra())
+   return 0;
+
+   tegra_soc_kobj = kobject_create_and_add("tegra", NULL);
+   WARN_ON(!tegra_soc_kobj);
+
+   return 0;
+}
+arch_initcall(tegra_soc_sysfs_init)
diff --git a/include/soc/tegra/bootdata.h b/include/soc/tegra/bootdata.h
index 7be207cb2519..d5c7a251517d 100644
---

[PATCH v6 2/7] mmc: block: Add mmc_bdev_to_card() helper

NVIDIA Tegra Partition Table takes into account MMC card's BOOT_SIZE_MULT
parameter, and thus, the partition parser needs to retrieve that EXT_CSD
value from the block device.  There are also some other parts of struct
mmc_card that are needed for the partition parser in order to calculate
the eMMC offset and verify different things.  This patch introduces new
helper which takes block device for the input argument and returns the
corresponding MMC card.

Signed-off-by: Dmitry Osipenko 
---
 drivers/mmc/core/block.c   | 15 +++
 include/linux/mmc/blkdev.h | 13 +
 2 files changed, 28 insertions(+)
 create mode 100644 include/linux/mmc/blkdev.h

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index c5367e2c8487..99298e888381 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -40,6 +40,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -305,6 +306,20 @@ static ssize_t force_ro_store(struct device *dev, struct 
device_attribute *attr,
return ret;
 }
 
+struct mmc_card *mmc_bdev_to_card(struct block_device *bdev)
+{
+   struct mmc_blk_data *md;
+
+   if (bdev->bd_disk->major != MMC_BLOCK_MAJOR)
+   return NULL;
+
+   md = mmc_blk_get(bdev->bd_disk);
+   if (!md)
+   return NULL;
+
+   return md->queue.card;
+}
+
 static int mmc_blk_open(struct block_device *bdev, fmode_t mode)
 {
struct mmc_blk_data *md = mmc_blk_get(bdev->bd_disk);
diff --git a/include/linux/mmc/blkdev.h b/include/linux/mmc/blkdev.h
new file mode 100644
index ..67608c58de70
--- /dev/null
+++ b/include/linux/mmc/blkdev.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *  linux/include/linux/mmc/blkdev.h
+ */
+#ifndef LINUX_MMC_BLOCK_DEVICE_H
+#define LINUX_MMC_BLOCK_DEVICE_H
+
+struct block_device;
+struct mmc_card;
+
+struct mmc_card *mmc_bdev_to_card(struct block_device *bdev);
+
+#endif /* LINUX_MMC_BLOCK_DEVICE_H */
-- 
2.26.0

[PATCH v6 4/7] partitions/efi: Support GPT entry lookup at a non-standard location

Most of consumer-grade NVIDIA Tegra devices use a proprietary bootloader
that can't be easily replaced because it's locked down using Secure Boot
cryptography signing and the crypto keys aren't given to a device owner.
These devices usually have eMMC storage that is partitioned using a custom
NVIDIA Tegra partition table format.  Of course bootloader and other
"special things" are stored on the eMMC storage, and thus, the partition
format can't be changed.

The Tegra partition format has been reverse-engineered, but NVIDIA uses
a virtually merged "boot" and "main" eMMC HW partitions in theirs
bootloader. This is not supported by Linux kernel and can't be easily
implemented. Hence partition table entry isn't accessible by kernel if
it's located at the "boot" eMMC partition. Luckily this is a rare case in
practice and even if it's the case, likely that the proprietary bootloader
will supply kernel with a non-standard gpt_sector= cmdline option.  This
gpt_sector= argument points at a GPT entry which resides at a non-standard
location on the eMMC storage.

This patch allows to support the non-standard cmdline option for NVIDIA
Tegra devices without bothering any other platforms.  The force_gpt_sector
parser-state struct member should be set before invoking efi_partition()
and it should be unset after the invocation completion.  This new parser
member instructs GPT parser to look up GPT entry at the given sector if
state->force_gpt_sector != 0.

This patch is based on the original work done by Colin Cross for the
downstream Android kernel.

Signed-off-by: Dmitry Osipenko 
---
 block/partitions/check.h | 1 +
 block/partitions/efi.c   | 9 +
 2 files changed, 10 insertions(+)

diff --git a/block/partitions/check.h b/block/partitions/check.h
index ffa01cc4b0b0..55acf6340e5b 100644
--- a/block/partitions/check.h
+++ b/block/partitions/check.h
@@ -22,6 +22,7 @@ struct parsed_partitions {
int limit;
bool access_beyond_eod;
char *pp_buf;
+   sector_t force_gpt_sector;
 };
 
 typedef struct {
diff --git a/block/partitions/efi.c b/block/partitions/efi.c
index b64bfdd4326c..34c25f708733 100644
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -621,6 +621,15 @@ static int find_valid_gpt(struct parsed_partitions *state, 
gpt_header **gpt,
 if (!good_agpt && force_gpt)
 good_agpt = is_gpt_valid(state, lastlba, , );
 
+   /*
+* The force_gpt_sector is used by NVIDIA Tegra partition parser in
+* order to convey a non-standard location of the GPT entry for lookup.
+* By default force_gpt_sector is set to 0 and has no effect.
+*/
+   if (!good_agpt && force_gpt && state->force_gpt_sector)
+   good_agpt = is_gpt_valid(state, state->force_gpt_sector,
+, );
+
 /* The obviously unsuccessful case */
 if (!good_pgpt && !good_agpt)
 goto fail;
-- 
2.26.0

[PATCH] oradax: convert get_user_pages() --> pin_user_pages()

This code was using get_user_pages_fast(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages_fast() + put_page() calls to
pin_user_pages_fast() + unpin_user_pages() calls.

There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.

[1] Documentation/core-api/pin_user_pages.rst

[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/

Cc: David S. Miller 
Cc: sparcli...@vger.kernel.org
Signed-off-by: John Hubbard 
---
 drivers/sbus/char/oradax.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/sbus/char/oradax.c b/drivers/sbus/char/oradax.c
index 8af216287a84..21b7cb6e7e70 100644
--- a/drivers/sbus/char/oradax.c
+++ b/drivers/sbus/char/oradax.c
@@ -410,9 +410,7 @@ static void dax_unlock_pages(struct dax_ctx *ctx, int 
ccb_index, int nelem)
 
if (p) {
dax_dbg("freeing page %p", p);
-   if (j == OUT)
-   set_page_dirty(p);
-   put_page(p);
+   unpin_user_pages_dirty_lock(, 1, j == OUT);
ctx->pages[i][j] = NULL;
}
}
@@ -425,13 +423,13 @@ static int dax_lock_page(void *va, struct page **p)
 
dax_dbg("uva %p", va);
 
-   ret = get_user_pages_fast((unsigned long)va, 1, FOLL_WRITE, p);
+   ret = pin_user_pages_fast((unsigned long)va, 1, FOLL_WRITE, p);
if (ret == 1) {
dax_dbg("locked page %p, for VA %p", *p, va);
return 0;
}
 
-   dax_dbg("get_user_pages failed, va=%p, ret=%d", va, ret);
+   dax_dbg("pin_user_pages failed, va=%p, ret=%d", va, ret);
return -1;
 }
 

base-commit: 3d1c1e5931ce45b3a3f309385bbc00c78e9951c6
-- 
2.26.2

Re: [PATCH v5 4/6] partitions/efi: Support GPT entry lookup at a non-standard location

2020-05-16 Thread Randy Dunlap

On 5/16/20 5:11 PM, Dmitry Osipenko wrote:
> 16.05.2020 19:58, Randy Dunlap пишет:
>> On 5/16/20 9:50 AM, Dmitry Osipenko wrote:
>>> 16.05.2020 18:51, Randy Dunlap пишет:
 On 5/16/20 8:36 AM, Dmitry Osipenko wrote:
> diff --git a/block/partitions/efi.c b/block/partitions/efi.c
> index b64bfdd4326c..3af4660bc11f 100644
> --- a/block/partitions/efi.c
> +++ b/block/partitions/efi.c
> @@ -621,6 +621,14 @@ static int find_valid_gpt(struct parsed_partitions 
> *state, gpt_header **gpt,
>  if (!good_agpt && force_gpt)
>  good_agpt = is_gpt_valid(state, lastlba, , );
>  
> + /* The force_gpt_sector is used by NVIDIA Tegra partition parser in
> +  * order to convey a non-standard location of the GPT entry for lookup.
> +  * By default force_gpt_sector is set to 0 and has no effect.
> +  */

 Please fix the multi-line comment format as described in
 Documentation/process/coding-style.rst.

> + if (!good_agpt && force_gpt && state->force_gpt_sector)
> + good_agpt = is_gpt_valid(state, state->force_gpt_sector,
> +  , );
> +
>  /* The obviously unsuccessful case */
>  if (!good_pgpt && !good_agpt)
>  goto fail;

 thanks.

>>>
>>> Hello Randy,
>>>
>>> I know that it's not a proper kernel-style formatting, but that's the
>>> style used by the whole efi.c source code and I wanted to maintain the
>>> same style, for consistency. Of course I can change to a proper style if
>>> it's more desirable than the consistency. Thank you for the comment!
>>>
>>
>> too bad. Sorry to hear that.
>> It should have been "fixed" much earlier.
>> It's probably too late now.
> 
> Actually, I now see that there is a mix of different comment styles in
> the efi.c code. So it should be fine to use the proper style, I'll
> change it in v6.
> 
> I don't think it's too late, it's never late to make a correction :)
> There are some other coding style problems in the efi.c that won't hurt
> to fix, I may take a look at fixing them later on.
> 

OK, great. Thanks.

-- 
~Randy

Re: [PATCH v2 4/4] mm/slub: Fix sysfs shrink circular locking dependency




> On Apr 27, 2020, at 7:56 PM, Waiman Long  wrote:
> 
> A lockdep splat is observed by echoing "1" to the shrink sysfs file
> and then shutting down the system:
> 
> [  167.473392] Chain exists of:
> [  167.473392]   kn->count#279 --> mem_hotplug_lock.rw_sem --> slab_mutex
> [  167.473392]
> [  167.484323]  Possible unsafe locking scenario:
> [  167.484323]
> [  167.490273]CPU0CPU1
> [  167.494825]
> [  167.499376]   lock(slab_mutex);
> [  167.502530]lock(mem_hotplug_lock.rw_sem);
> [  167.509356]lock(slab_mutex);
> [  167.515044]   lock(kn->count#279);
> [  167.518462]
> [  167.518462]  *** DEADLOCK ***
> 
> It is because of the get_online_cpus() and get_online_mems() calls in
> kmem_cache_shrink() invoked via the shrink sysfs file. To fix that, we
> have to use trylock to get the memory and cpu hotplug read locks. Since
> hotplug events are rare, it should be fine to refuse a kmem caches
> shrink operation when some hotplug events are in progress.
> 
> Signed-off-by: Waiman Long 

Feel free to use,

Reviewed-by: Qian Cai

Re: [PATCH v2 0/4] mm/slub: Fix sysfs circular locking dependency




> On Apr 27, 2020, at 7:56 PM, Waiman Long  wrote:
> 
> v2:
> - Use regular cmpxchg() instead of x86-only try_cmpxchg() in patch 2.
> - Add patches 3 and 4 to fix circular locking dependency showing up
>   at shutdown time.
> 
> With lockdep enabled, issuing the following command to the slub sysfs
> files will cause splat about circular locking dependency to show up
> either immediately afterwards or at shutdown time.
> 
> # echo 1 > validate
> # echo 1 > shrink
> 
> This patchset fixes these lockdep splats by replacing slab_mutex with
> memcg_cache_ids_sem as well as changing some of the lock operations
> with trylock.

For the whole series, feel free to use,

Tested-by: Qian Cai

Re: [PATCH] x86/mm: Don't try to change poison pages to uncacheable in a guest

2020-05-16 Thread Luck, Tony

But the guest isn’t likely to do the right thing with a page fault. The guest 
just accessed a page that it knows is poisoned (VMM just told it once that it 
was poisoned). There is no reason that the VMM should let the guest actually 
touch the poison a second time. But if the guest does, then the guest should 
get the expected response.  I.e. another machine check.

Sent from my iPhone

> On May 16, 2020, at 08:03, Borislav Petkov  wrote:
> 
> On Sat, May 16, 2020 at 02:47:42PM +, Luck, Tony wrote:
>> There is only one actual machine check. But the VMM simulates a second
>> machine check to the guest when the guest tries to access the poisoned
>> page.
> 
> If the VMM unmaps the bad page, why doesn't the guest get a #PF instead
> injected by the VMM instead of latter injecting a second #MCE?
> 
> If the guest tries to access an unmapped page, it should get a #PF, I'd
> expect.
> 
> -- 
> Regards/Gruss,
>Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

[rcu:dev.2020.05.16a] BUILD SUCCESS 0f214eff73a9c86bf1e5a0c566c190716782b6a9

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
dev.2020.05.16a
branch HEAD: 0f214eff73a9c86bf1e5a0c566c190716782b6a9  tick/nohz: Narrow down 
noise while setting current task's tick dependency

i386-tinyconfig vmlinux size:


 TOTAL  TEXT  arch/x86/events/zhaoxin/built-in.*


  -225  -224-136  f21d375f5014 Merge branch 
'kcsan-dev.2020.04.13c' into HEAD   
 0 0  0d3abc57e048 Merge branch 
'lkmm-dev.2020.05.14b' into HEAD
   +38   +38  4e07267a1891 fork: Annotate a 
data race in vm_area_dup()  
 0 0  82ee1245c8ce x86/mm/pat: Mark 
an intentional data race
 0 0  3e745f06e547 rculist: Add 
ASSERT_EXCLUSIVE_ACCESS() to __list_splice_init 
 0 0  3064b68481a8 locktorture: Use 
true and false to assign to bool variables  
 0 0  a77eaf80c023 srcu: Fix a typo 
in comment "amoritized"->"amortized"
 0 0  7876218db8cb rcu: Simplify 
the calculation of rcu_state.ncpus 
 0 0  11b741bd89c5 docs: RCU: 
Convert checklist.txt to ReST 
 0 0  dd051b8b94b5 docs: RCU: 
Convert lockdep-splat.txt to ReST 
 0 0  0ac5a288bd8e docs: RCU: 
Convert lockdep.txt to ReST   
 0 0  92943993fb41 docs: RCU: 
Convert rculist_nulls.txt to ReST 
 0 0  e8dd4b58c6fc docs: RCU: 
Convert torture.txt to ReST   
 0 0  73ee3d5eec05 docs: RCU: 
Convert rcuref.txt to ReST
 0 0  425c2ecca450 docs: RCU: 
Convert stallwarn.txt to ReST 
 0 0  b8b9ee19d328 docs: RCU: Don't 
duplicate chapter names in rculist_nulls.rs 
 0 0  7c76eb5e4209 rcutorture: Add 
races with task-exit processing  
 0 0  be8258baccc0 torture: Set 
configfile variable to current scenario 
 0 0  46de31180c5b rcutorture: 
Handle non-statistic bang-string error messages  
 0 0  f5d2e43344f1 rcutorture: NULL 
rcu_torture_current earlier in cleanup code 
 0 0  046b23f81154 kcsan: Add test 
suite
 0 0  f742885f1fbf torture:  Remove 
qemu dependency on EFI firmware 
 0 0  a34638af2455 doc: Timer 
problems can cause RCU CPU stall warnings 
 0 0  8609e646d509 rcu: Add 
callbacks-invoked counters  
 0 0  e1ea77a91005 rcu: Add comment 
documenting rcu_callback_map's purpose  
 0 0  037b0281beb8 Revert 
b8c17e6664c4 ("rcu: Maintain special bits at bottom o 
 0 0  adfc62c9416b rcu/tree: Add 
better tracing for dyntick-idle
+1 0  791756fd750d rcu/tree: Clean 
up dynticks counter usage
 0 0  4993b760a88f rcu/tree: Remove 
dynticks_nmi_nesting counter
 0 0  e1b441a18227 trace: events: 
rcu: Change description of rcu_dyntick trace  
 0 0  9623376f6294 torture: Add 
script to smoke-test commits in a branch
 0 0  b6d56227b204 torture: Remove 
whitespace from identify_qemu_vcpus output   
 0 0  b518c273d0d9 torture: Add 
--allcpus argument to the kvm.sh script 
 0 0  afd3653541c7 rcu: 
Grace-period-kthread related sleeps to idle priority
 0 0  a969886c710d rcu:

Re: [PATCH v2 4/4] mm/slub: Fix sysfs shrink circular locking dependency




> On Apr 28, 2020, at 10:07 AM, Waiman Long  wrote:
> 
> Trylock is handled differently from lockdep's perspective as trylock can 
> failed. When trylock succeeds, the critical section is executed. As long as 
> it doesn't try to acquire another lock in the circular chain, the execution 
> will finish at some point and release the lock. On the other hand, if another 
> task has already held all those locks, the trylock will fail and held locks 
> should be released. Again, no deadlock will happen.

Ok, I can see that in validate_chain() especially mentioned,

“Trylock needs to maintain the stack of held locks, but it does not add new 
dependencies, because trylock can be done in any order.”

So, I agree this trylock trick could really work. Especially, I don’t know any 
other better way to fix this.

Gute Nachrichten. Bitte lesen Sie

2020-05-16 Thread David Yax.

-- 
€ 40.000,00 Euro wurden Ihnen von David Yax gespendet. Bin der
Gewinner der $ 80 Millionen Jackpot Powerball Ziehung. Die € 40.000,00
Euro werden Ihnen aufgrund von COVID-19 gespendet, um sicherzustellen,
dass Sie und alle in Ihnen die beste Pflege erhalten. Mailen Sie mir
für weitere Informationen.

Mr. David Yax.
E-Mail: lbill9...@gmail.com

[PATCH] rds: convert get_user_pages() --> pin_user_pages()

This code was using get_user_pages_fast(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages_fast() + put_page() calls to
pin_user_pages_fast() + unpin_user_pages() calls.

There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.

[1] Documentation/core-api/pin_user_pages.rst

[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/

Cc: David S. Miller 
Cc: Jakub Kicinski 
Cc: net...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: rds-de...@oss.oracle.com
Signed-off-by: John Hubbard 
---
 net/rds/info.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/net/rds/info.c b/net/rds/info.c
index 03f6fd56d237..e1d63563e81c 100644
--- a/net/rds/info.c
+++ b/net/rds/info.c
@@ -162,7 +162,6 @@ int rds_info_getsockopt(struct socket *sock, int optname, 
char __user *optval,
struct rds_info_lengths lens;
unsigned long nr_pages = 0;
unsigned long start;
-   unsigned long i;
rds_info_func func;
struct page **pages = NULL;
int ret;
@@ -193,7 +192,7 @@ int rds_info_getsockopt(struct socket *sock, int optname, 
char __user *optval,
ret = -ENOMEM;
goto out;
}
-   ret = get_user_pages_fast(start, nr_pages, FOLL_WRITE, pages);
+   ret = pin_user_pages_fast(start, nr_pages, FOLL_WRITE, pages);
if (ret != nr_pages) {
if (ret > 0)
nr_pages = ret;
@@ -235,8 +234,7 @@ int rds_info_getsockopt(struct socket *sock, int optname, 
char __user *optval,
ret = -EFAULT;
 
 out:
-   for (i = 0; pages && i < nr_pages; i++)
-   put_page(pages[i]);
+   unpin_user_pages(pages, nr_pages);
kfree(pages);
 
return ret;

base-commit: 3d1c1e5931ce45b3a3f309385bbc00c78e9951c6
-- 
2.26.2

[PATCH] fpga: dfl: afu: convert get_user_pages() --> pin_user_pages()

This code was using get_user_pages_fast(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages_fast() + put_page() calls to
pin_user_pages_fast() + unpin_user_pages() calls.

There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.

[1] Documentation/core-api/pin_user_pages.rst

[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/

Cc: Wu Hao 
Cc: Moritz Fischer 
Cc: linux-f...@vger.kernel.org
Signed-off-by: John Hubbard 
---
 drivers/fpga/dfl-afu-dma-region.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/fpga/dfl-afu-dma-region.c 
b/drivers/fpga/dfl-afu-dma-region.c
index 62f924489db5..84f696d5ba82 100644
--- a/drivers/fpga/dfl-afu-dma-region.c
+++ b/drivers/fpga/dfl-afu-dma-region.c
@@ -16,15 +16,6 @@
 
 #include "dfl-afu.h"
 
-static void put_all_pages(struct page **pages, int npages)
-{
-   int i;
-
-   for (i = 0; i < npages; i++)
-   if (pages[i])
-   put_page(pages[i]);
-}
-
 void afu_dma_region_init(struct dfl_feature_platform_data *pdata)
 {
struct dfl_afu *afu = dfl_fpga_pdata_get_private(pdata);
@@ -57,7 +48,7 @@ static int afu_dma_pin_pages(struct dfl_feature_platform_data 
*pdata,
goto unlock_vm;
}
 
-   pinned = get_user_pages_fast(region->user_addr, npages, FOLL_WRITE,
+   pinned = pin_user_pages_fast(region->user_addr, npages, FOLL_WRITE,
 region->pages);
if (pinned < 0) {
ret = pinned;
@@ -72,7 +63,7 @@ static int afu_dma_pin_pages(struct dfl_feature_platform_data 
*pdata,
return 0;
 
 put_pages:
-   put_all_pages(region->pages, pinned);
+   unpin_user_pages(region->pages, pinned);
 free_pages:
kfree(region->pages);
 unlock_vm:
@@ -94,7 +85,7 @@ static void afu_dma_unpin_pages(struct 
dfl_feature_platform_data *pdata,
long npages = region->length >> PAGE_SHIFT;
struct device *dev = >dev->dev;
 
-   put_all_pages(region->pages, npages);
+   unpin_user_pages(region->pages, npages);
kfree(region->pages);
account_locked_vm(current->mm, npages, false);
 

base-commit: 3d1c1e5931ce45b3a3f309385bbc00c78e9951c6
-- 
2.26.2

[rcu] 2f08469563: BUG:kernel_reboot-without-warning_in_boot_stage

2020-05-16 Thread kernel test robot

Greeting,

FYI, we noticed the following commit (built with clang-11):

commit: 2f08469563550d15cb08a60898d3549720600eee ("rcu: Mark rcu_state.ncpus to 
detect concurrent writes")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git 
dev.2020.05.14c

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):




If you fix the issue, kindly add following tag
Reported-by: kernel test robot 


[0.054943] BRK [0x05204000, 0x05204fff] PGTABLE
[0.061181] BRK [0x05205000, 0x05205fff] PGTABLE
[0.062403] BRK [0x05206000, 0x05206fff] PGTABLE
[0.065200] RAMDISK: [mem 0x7a247000-0x7fff]
[0.067344] ACPI: Early table checksum verification disabled
BUG: kernel reboot-without-warning in boot stage

Elapsed time: 60

qemu-img create -f qcow2 disk-vm-snb-16-0 256G
qemu-img create -f qcow2 disk-vm-snb-16-1 256G


To reproduce:

# build kernel
cd linux
cp config-5.7.0-rc2-3-g2f08469563550 .config
make HOSTCC=clang-11 CC=clang-11 ARCH=x86_64 olddefconfig prepare 
modules_prepare bzImage

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script # job-script is attached in this 
email



Thanks,
Rong Chen

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.7.0-rc2 Kernel Configuration
#

#
# Compiler: clang version 11.0.0 (git://gitmirror/llvm_project 
54b35c066417d4856e9d53313f7e98b354274584)
#
CONFIG_GCC_VERSION=0
CONFIG_LD_VERSION=0
CONFIG_CC_IS_CLANG=y
CONFIG_CLANG_VERSION=11
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
# CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED is not set
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_UAPI_HEADER_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_IRQ_MSI_IOMMU=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem

CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set
# end of Timers subsystem

CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_SCHED_AVG_IRQ=y
# CONFIG_SCHED_THERMAL_PRESSURE is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
CONFIG_PSI=y
CONFIG_PSI_DEFAULT_DISABLED=y
# end of CPU/Task time and stats accounting

# CONFIG_CPU_ISOLATION is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_RCU_NOCB_CPU is not set
# end of RCU Subsystem

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_IKHEADERS=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y

#
# Scheduler features
#
# end of Scheduler features

CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CC_HAS_INT128=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CGROUP_SCHED is not set
#

Re: "BUG: MAX_LOCKDEP_ENTRIES too low" with 6979 ">s_umount_key"

2020-05-16 Thread Waiman Long


On 5/15/20 1:21 AM, Qian Cai wrote:

Lockdep is screwed here in next-20200514 due to "BUG: MAX_LOCKDEP_ENTRIES too 
low". One of the traces below pointed to this linux-next commit,

8c8e824d4ef0 watch_queue: Introduce a non-repeating system-unique superblock ID

which was accidentally just showed up in next-20200514 along with,

46896d79c514 watch_queue: Add superblock notifications

I did have here,

CONFIG_SB_NOTIFICATIONS=y
CONFIG_MOUNT_NOTIFICATIONS=y
CONFIG_FSINFO=y

While MAX_LOCKDEP_ENTRIES is 32768, I noticed there is one type of lock had a 
lot along,

# grep  'type->s_umount_key’ /proc/lockdep_chains | wc -l
6979


The lock_list table entries are for tracking a lock's forward and 
backward dependencies. The lockdep_chains isn't the right lockdep file 
to look at. Instead, check the lockdep files for entries with the 
maximum BD (backward dependency) + FD (forward dependency). That will 
give you a better view of which locks are consuming most of the 
lock_list entries. Also take a look at lockdep_stats for an overall view 
of how much various table entries are being consumed.


Cheers,
Longman

[rcu:lkmm-dev] BUILD SUCCESS ae801b4aaca0db21c44819ab833dc591b1d3219e

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  lkmm-dev
branch HEAD: ae801b4aaca0db21c44819ab833dc591b1d3219e  tools/memory-model: Use 
"-unroll 0" to keep --hw runs finite

elapsed time: 482m

configs tested: 102
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
m68k allyesconfig
mips allyesconfig
sparcallyesconfig
mipsmalta_kvm_guest_defconfig
archsdk_defconfig
arc   tb10x_defconfig
h8300alldefconfig
powerpc   allnoconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
x86_64   randconfig-a005-20200517
x86_64   randconfig-a003-20200517
x86_64   randconfig-a006-20200517
x86_64   randconfig-a004-20200517
x86_64   randconfig-a001-20200517
x86_64   randconfig-a002-20200517
i386 randconfig-a006-20200517
i386 randconfig-a005-20200517
i386 randconfig-a003-20200517
i386 randconfig-a001-20200517
i386 randconfig-a004-20200517
i386 randconfig-a002-20200517
i386 randconfig-a012-20200517
i386 randconfig-a016-20200517
i386 randconfig-a014-20200517
i386 randconfig-a011-20200517
i386 randconfig-a013-20200517
i386 randconfig-a015-20200517
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
x86_64  defconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64   rhel
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64lkp
x86_64

Re: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects

2020-05-16 Thread Matthew Wilcox

On Sun, May 17, 2020 at 10:27:39AM +1000, Balbir Singh wrote:
> On 14/5/20 10:00 pm, Matthew Wilcox wrote:
> > On Thu, May 14, 2020 at 09:00:40PM +1000, Balbir Singh wrote:
> >> I wonder if the right thing to do is also to disable pre-emption, just so 
> >> that the thread does not linger on with sensitive data.
> >>
> >> void kvfree_sensitive(const void *addr, size_t len)
> >> {
> >>preempt_disable();
> >>if (likely(!ZERO_OR_NULL_PTR(addr))) {
> >>memzero_explicit((void *)addr, len);
> >>kvfree(addr);
> >>}
> >>preempt_enable();
> >> }
> >> EXPORT_SYMBOL(kvfree_sensitive);
> > 
> > If it's _that_ sensitive then the caller should have disabled preemption.
> > Because preemption could otherwise have occurred immediately before
> > kvfree_sensitive() was called.
> > 
> 
> May be, but the callers of the API have to be explictly aware of the contract.
> I don't disagree with you on what you've said, but I was referring to the
> intent of freeing sensitive data vs the turn around time for doing so.

It's the caller's information.  They should be aware of their own
requirements.  If they do something like:

p = kmalloc();
preempt_disable();
construct(p);
use(p);
preempt_enable();
kvfree_sensitive(p);

there's really nothing we can do to help them inside kvfree_sensitive().
Actually, can you come up with a scenario where disabling preemption
inside kvfree_sensitive() will help with anything?

Re: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects

2020-05-16 Thread Balbir Singh




On 14/5/20 10:00 pm, Matthew Wilcox wrote:
> On Thu, May 14, 2020 at 09:00:40PM +1000, Balbir Singh wrote:
>> I wonder if the right thing to do is also to disable pre-emption, just so 
>> that the thread does not linger on with sensitive data.
>>
>> void kvfree_sensitive(const void *addr, size_t len)
>> {
>>  preempt_disable();
>>  if (likely(!ZERO_OR_NULL_PTR(addr))) {
>>  memzero_explicit((void *)addr, len);
>>  kvfree(addr);
>>  }
>>  preempt_enable();
>> }
>> EXPORT_SYMBOL(kvfree_sensitive);
> 
> If it's _that_ sensitive then the caller should have disabled preemption.
> Because preemption could otherwise have occurred immediately before
> kvfree_sensitive() was called.
> 

May be, but the callers of the API have to be explictly aware of the contract.
I don't disagree with you on what you've said, but I was referring to the
intent of freeing sensitive data vs the turn around time for doing so.

Balbir Singh.

[PATCH 1/1] selftests/vm/.gitignore: add khugepaged, mremap_dontunmap

Add mremap_dontunmap and khugepaged to .gitignore.

Fixes: 6582dba23f8b ("khugepaged: add self test")
Fixes: 0c28759ee3c9 ("selftests: add MREMAP_DONTUNMAP selftest")
Cc: Kirill A. Shutemov 
Cc: Brian Geffon 
Signed-off-by: John Hubbard 
---
 tools/testing/selftests/vm/.gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/testing/selftests/vm/.gitignore 
b/tools/testing/selftests/vm/.gitignore
index 4ff9708277fb..ddf5426416fa 100644
--- a/tools/testing/selftests/vm/.gitignore
+++ b/tools/testing/selftests/vm/.gitignore
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+mremap_dontunmap
 hugepage-mmap
 hugepage-shm
 map_hugetlb
@@ -18,3 +19,4 @@ va_128TBswitch
 map_fixed_noreplace
 write_to_hugetlbfs
 hmm-tests
+khugepaged
-- 
2.26.2

[PATCH 0/1] selftests/vm: .gitignore fixes for mmotm

These apply to today's mmotm. Some merge notes:

* The missing item ("mremap_dontunmap") at the *top* of .gitignore
  for this patch will also being applied to linux.git in a separate
  patch [1].

  The other missing item ("khugepaged") is added to *bottom* of
  .gitignore. This approach allows merging to work without manual
  intervention in this case.

[1] https://lore.kernel.org/r/20200517001245.361762-3-jhubb...@nvidia.com

John Hubbard (1):
  selftests/vm/.gitignore: add khugepaged, mremap_dontunmap

 tools/testing/selftests/vm/.gitignore | 2 ++
 1 file changed, 2 insertions(+)


base-commit: 2bbf0589bfeb27800c730b76eacf34528eee5418
-- 
2.26.2

[PATCH 1/2] selftests/vm/write_to_hugetlbfs.c: fix unused variable warning

Remove unused variable "i", which was triggering a compiler warning.

Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests")
Cc: Mina Almasry 
Signed-off-by: John Hubbard 
---
 tools/testing/selftests/vm/write_to_hugetlbfs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tools/testing/selftests/vm/write_to_hugetlbfs.c 
b/tools/testing/selftests/vm/write_to_hugetlbfs.c
index 110bc4e4015d..6a2caba19ee1 100644
--- a/tools/testing/selftests/vm/write_to_hugetlbfs.c
+++ b/tools/testing/selftests/vm/write_to_hugetlbfs.c
@@ -74,8 +74,6 @@ int main(int argc, char **argv)
int write = 0;
int reserve = 1;
 
-   unsigned long i;
-
if (signal(SIGINT, sig_handler) == SIG_ERR)
err(1, "\ncan't catch SIGINT\n");
 
-- 
2.26.2

[PATCH 2/2] selftests/vm/.gitignore: add mremap_dontunmap

Add mremap_dontunmap to .gitignore.

Fixes: 0c28759ee3c9 ("selftests: add MREMAP_DONTUNMAP selftest")
Cc: Brian Geffon 
Signed-off-by: John Hubbard 
---
 tools/testing/selftests/vm/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/vm/.gitignore 
b/tools/testing/selftests/vm/.gitignore
index 0edb6d900e8d..1f332f1f7077 100644
--- a/tools/testing/selftests/vm/.gitignore
+++ b/tools/testing/selftests/vm/.gitignore
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+mremap_dontunmap
 hugepage-mmap
 hugepage-shm
 map_hugetlb
-- 
2.26.2

[PATCH 0/2] selftests/vm: minor fixes for 5.7-rc5

Here's a couple of tiny fixes, just so we can cleanly build
selftests/vm. These apply to today's linux.git. Some merge notes:

* The .gitignore fix is appropriate for linux.git, but it is a subset of
  what's required for linux-next and mmotm. In order to fix things now
  in linux.git, and keep it fixed in mmotm and linux-next, but without
  manual intervention required in git merges, I'm adding the missing
  item ("mremap_dontunmap") to the *top* of .gitignore for this patch.
  And then I'll send a separate patch to be applied to mmotm and
  linux-next, that will also add a different item ("khugepaged") to the
  *bottom* of .gitignore.

* The write_to_hugetlbfs.c fix is already applied to linux-next, but
  doesn't seem to be getting picked up for linux.git. Maybe it's in
  the merge pipeline, but if not, let's fix it here, before the -rc
  cycle is over.

John Hubbard (2):
  selftests/vm/write_to_hugetlbfs.c: fix unused variable warning
  selftests/vm/.gitignore: add mremap_dontunmap

 tools/testing/selftests/vm/.gitignore   | 1 +
 tools/testing/selftests/vm/write_to_hugetlbfs.c | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)


base-commit: 3d1c1e5931ce45b3a3f309385bbc00c78e9951c6
-- 
2.26.2

Re: [PATCH v5 4/6] partitions/efi: Support GPT entry lookup at a non-standard location

16.05.2020 19:58, Randy Dunlap пишет:
> On 5/16/20 9:50 AM, Dmitry Osipenko wrote:
>> 16.05.2020 18:51, Randy Dunlap пишет:
>>> On 5/16/20 8:36 AM, Dmitry Osipenko wrote:
 diff --git a/block/partitions/efi.c b/block/partitions/efi.c
 index b64bfdd4326c..3af4660bc11f 100644
 --- a/block/partitions/efi.c
 +++ b/block/partitions/efi.c
 @@ -621,6 +621,14 @@ static int find_valid_gpt(struct parsed_partitions 
 *state, gpt_header **gpt,
  if (!good_agpt && force_gpt)
  good_agpt = is_gpt_valid(state, lastlba, , );
  
 +  /* The force_gpt_sector is used by NVIDIA Tegra partition parser in
 +   * order to convey a non-standard location of the GPT entry for lookup.
 +   * By default force_gpt_sector is set to 0 and has no effect.
 +   */
>>>
>>> Please fix the multi-line comment format as described in
>>> Documentation/process/coding-style.rst.
>>>
 +  if (!good_agpt && force_gpt && state->force_gpt_sector)
 +  good_agpt = is_gpt_valid(state, state->force_gpt_sector,
 +   , );
 +
  /* The obviously unsuccessful case */
  if (!good_pgpt && !good_agpt)
  goto fail;
>>>
>>> thanks.
>>>
>>
>> Hello Randy,
>>
>> I know that it's not a proper kernel-style formatting, but that's the
>> style used by the whole efi.c source code and I wanted to maintain the
>> same style, for consistency. Of course I can change to a proper style if
>> it's more desirable than the consistency. Thank you for the comment!
>>
> 
> too bad. Sorry to hear that.
> It should have been "fixed" much earlier.
> It's probably too late now.

Actually, I now see that there is a mix of different comment styles in
the efi.c code. So it should be fine to use the proper style, I'll
change it in v6.

I don't think it's too late, it's never late to make a correction :)
There are some other coding style problems in the efi.c that won't hurt
to fix, I may take a look at fixing them later on.

Re: [PATCH v4 1/2] mfd: syscon: Support physical regmap bus

2020-05-16 Thread Orson Zhai

On Sat, May 16, 2020 at 6:13 PM Baolin Wang  wrote:
>
> Some platforms such as Spreadtrum platform, define a special method to
> update bits of the registers instead of reading and writing, which means
> we should use a physical regmap bus to define the reg_update_bits()
> operation instead of the MMIO regmap bus.
>
> Thus add a a __weak function  for the syscon driver to allow to register

Typo -- duplicated "a".

It seems to be a better idea than before.

-Orson

> a physical regmap bus to support this new requirement.
>
> Signed-off-by: Baolin Wang 
> ---
>  drivers/mfd/syscon.c   |  9 -
>  include/linux/mfd/syscon.h | 11 +++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 3a97816d0cba..dc92f3177ceb 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -40,6 +40,13 @@ static const struct regmap_config syscon_regmap_config = {
> .reg_stride = 4,
>  };
>
> +struct regmap * __weak syscon_regmap_init(struct device_node *np,
> + void __iomem *base,
> + struct regmap_config *syscon_config)
> +{
> +   return regmap_init_mmio(NULL, base, syscon_config);
> +}
> +
>  static struct syscon *of_syscon_register(struct device_node *np, bool 
> check_clk)
>  {
> struct clk *clk;
> @@ -106,7 +113,7 @@ static struct syscon *of_syscon_register(struct 
> device_node *np, bool check_clk)
> syscon_config.val_bits = reg_io_width * 8;
> syscon_config.max_register = resource_size() - reg_io_width;
>
> -   regmap = regmap_init_mmio(NULL, base, _config);
> +   regmap = syscon_regmap_init(np, base, _config);
> if (IS_ERR(regmap)) {
> pr_err("regmap init failed\n");
> ret = PTR_ERR(regmap);
> diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
> index 7f20e9b502a5..85088e44fe7c 100644
> --- a/include/linux/mfd/syscon.h
> +++ b/include/linux/mfd/syscon.h
> @@ -13,6 +13,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  struct device_node;
>
> @@ -28,6 +29,9 @@ extern struct regmap *syscon_regmap_lookup_by_phandle_args(
> const char *property,
> int arg_count,
> unsigned int *out_args);
> +extern struct regmap *syscon_regmap_init(struct device_node *np,
> +void __iomem *base,
> +struct regmap_config *syscon_config);
>  #else
>  static inline struct regmap *device_node_to_regmap(struct device_node *np)
>  {
> @@ -59,6 +63,13 @@ static inline struct regmap 
> *syscon_regmap_lookup_by_phandle_args(
>  {
> return ERR_PTR(-ENOTSUPP);
>  }
> +
> +static inline struct regmap *syscon_regmap_init(struct device_node *np,
> +   void __iomem *base,
> +   struct regmap_config 
> *syscon_config)
> +{
> +   return ERR_PTR(-ENOTSUPP);
> +}
>  #endif
>
>  #endif /* __LINUX_MFD_SYSCON_H__ */
> --
> 2.17.1
>

Re: [PATCH v5 04/18] sparc32: mm: Reduce allocation size for PMD and PTE tables

2020-05-16 Thread Guenter Roeck

On Sat, May 16, 2020 at 05:00:50PM -0700, Guenter Roeck wrote:
> On Mon, May 11, 2020 at 09:41:36PM +0100, Will Deacon wrote:
> > Now that the page table allocator can free page table allocations
> > smaller than PAGE_SIZE, reduce the size of the PMD and PTE allocations
> > to avoid needlessly wasting memory.
> > 
> > Cc: "David S. Miller" 
> > Cc: Peter Zijlstra 
> > Signed-off-by: Will Deacon 
> 
> Something in the sparc32 patches in linux-next causes all my sparc32 
> emulations
> to crash. bisect points to this patch, but reverting it doesn't help, and 
> neither
> does reverting the rest of the series.
> 
Actually, turns out I see the same pattern (lots of scheduling while atomic
followed by 'killing interrupt handler' in cryptomgr_test) with several
powerpc boot tests.  I am currently bisecting those crashes. I'll report
the results here as well as soon as I have it.

Guenter

> Guenter
> 
> ---
> Bisect log:
> 
> # bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific 
> files for 20200515
> # good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
> git bisect start 'HEAD' 'v5.7-rc5'
> # bad: [3674d7aa7a8e61d993886c2fb7c896c5ef85e988] Merge remote-tracking 
> branch 'crypto/master'
> git bisect bad 3674d7aa7a8e61d993886c2fb7c896c5ef85e988
> # bad: [1ab4d6ff0a3ee4b29441d8b0076bc8d4734bd16e] Merge remote-tracking 
> branch 'hwmon-staging/hwmon-next'
> git bisect bad 1ab4d6ff0a3ee4b29441d8b0076bc8d4734bd16e
> # good: [dccfae3ab84387c94f2efc574d41efae0055] Merge remote-tracking 
> branch 'tegra/for-next'
> git bisect good dccfae3ab84387c94f2efc574d41efae0055
> # bad: [20f9d1287c9f0047b81497197c9f4893485bbe15] Merge remote-tracking 
> branch 'djw-vfs/vfs-for-next'
> git bisect bad 20f9d1287c9f0047b81497197c9f4893485bbe15
> # bad: [6537897637b5b91f921cb0ac6c465a593f4a665e] Merge remote-tracking 
> branch 'sparc-next/master'
> git bisect bad 6537897637b5b91f921cb0ac6c465a593f4a665e
> # good: [bca1583e0693e0ba76450b684c5910f7083eeef4] Merge remote-tracking 
> branch 'mips/mips-next'
> git bisect good bca1583e0693e0ba76450b684c5910f7083eeef4
> # good: [1f12096aca212af8fad3ef58d5673cde691a1452] Merge the lockless page 
> table walk rework into next
> git bisect good 1f12096aca212af8fad3ef58d5673cde691a1452
> # good: [23a457b8d57dc8d0cc1dbd1882993dd2fcc4b0c0] s390: nvme reipl
> git bisect good 23a457b8d57dc8d0cc1dbd1882993dd2fcc4b0c0
> # good: [f57f5010c0c3fe2d924a957ddf1d17fbebb54d47] Merge remote-tracking 
> branch 'risc-v/for-next'
> git bisect good f57f5010c0c3fe2d924a957ddf1d17fbebb54d47
> # good: [1d5fd6c33b04e5d5b665446c3b56f2148f0f1272] sh: add missing 
> DECLARE_EXPORT() for __ashiftrt_r4_xx
> git bisect good 1d5fd6c33b04e5d5b665446c3b56f2148f0f1272
> # bad: [8c8f3156dd40f8bdc58f2ac461374bc804c28e3b] sparc32: mm: Reduce 
> allocation size for PMD and PTE tables
> git bisect bad 8c8f3156dd40f8bdc58f2ac461374bc804c28e3b
> # good: [8e958839e4b9fb6ea4385ff2c52d1333a3a618de] sparc32: mm: Restructure 
> sparc32 MMU page-table layout
> git bisect good 8e958839e4b9fb6ea4385ff2c52d1333a3a618de
> # good: [3f407976ac2953116cb8880a7a18b63bcc81829d] sparc32: mm: Change 
> pgtable_t type to pte_t * instead of struct page *
> git bisect good 3f407976ac2953116cb8880a7a18b63bcc81829d
> # first bad commit: [8c8f3156dd40f8bdc58f2ac461374bc804c28e3b] sparc32: mm: 
> Reduce allocation size for PMD and PTE tables
> 
> ---
> Log messages:
> 
> Lots of:
> 
> BUG: scheduling while atomic: kthreadd/2/0x
> Modules linked in:
> CPU: 0 PID: 2 Comm: kthreadd Tainted: GW 
> 5.7.0-rc5-next-20200515 #1
> [f04f2c94 :
> here+0x16c/0x250 ]
> [f04f2df0 :
> schedule+0x78/0x11c ]
> [f003f100 :
> kthreadd+0x188/0x1a4 ]
> [f0008448 :
> ret_from_kernel_thread+0xc/0x38 ]
> [ :
> 0x0 ]
> 
> followed by:
> 
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> CPU: 0 PID: 19 Comm: cryptomgr_test Tainted: GW 
> 5.7.0-rc5-next-20200515 #1
> [f0024400 :
> do_exit+0x7c8/0xa88 ]
> [f0075540 :
> __module_put_and_exit+0xc/0x18 ]
> [f0221428 :
> cryptomgr_test+0x28/0x48 ]
> [f003edc0 :
> kthread+0xf4/0x12c ]
> [f0008448 :
> ret_from_kernel_thread+0xc/0x38 ]
> [ :
> 0x0 ]

Re: [PATCH v5 04/18] sparc32: mm: Reduce allocation size for PMD and PTE tables

2020-05-16 Thread Guenter Roeck

On Mon, May 11, 2020 at 09:41:36PM +0100, Will Deacon wrote:
> Now that the page table allocator can free page table allocations
> smaller than PAGE_SIZE, reduce the size of the PMD and PTE allocations
> to avoid needlessly wasting memory.
> 
> Cc: "David S. Miller" 
> Cc: Peter Zijlstra 
> Signed-off-by: Will Deacon 

Something in the sparc32 patches in linux-next causes all my sparc32 emulations
to crash. bisect points to this patch, but reverting it doesn't help, and 
neither
does reverting the rest of the series.

Guenter

---
Bisect log:

# bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific files 
for 20200515
# good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
git bisect start 'HEAD' 'v5.7-rc5'
# bad: [3674d7aa7a8e61d993886c2fb7c896c5ef85e988] Merge remote-tracking branch 
'crypto/master'
git bisect bad 3674d7aa7a8e61d993886c2fb7c896c5ef85e988
# bad: [1ab4d6ff0a3ee4b29441d8b0076bc8d4734bd16e] Merge remote-tracking branch 
'hwmon-staging/hwmon-next'
git bisect bad 1ab4d6ff0a3ee4b29441d8b0076bc8d4734bd16e
# good: [dccfae3ab84387c94f2efc574d41efae0055] Merge remote-tracking branch 
'tegra/for-next'
git bisect good dccfae3ab84387c94f2efc574d41efae0055
# bad: [20f9d1287c9f0047b81497197c9f4893485bbe15] Merge remote-tracking branch 
'djw-vfs/vfs-for-next'
git bisect bad 20f9d1287c9f0047b81497197c9f4893485bbe15
# bad: [6537897637b5b91f921cb0ac6c465a593f4a665e] Merge remote-tracking branch 
'sparc-next/master'
git bisect bad 6537897637b5b91f921cb0ac6c465a593f4a665e
# good: [bca1583e0693e0ba76450b684c5910f7083eeef4] Merge remote-tracking branch 
'mips/mips-next'
git bisect good bca1583e0693e0ba76450b684c5910f7083eeef4
# good: [1f12096aca212af8fad3ef58d5673cde691a1452] Merge the lockless page 
table walk rework into next
git bisect good 1f12096aca212af8fad3ef58d5673cde691a1452
# good: [23a457b8d57dc8d0cc1dbd1882993dd2fcc4b0c0] s390: nvme reipl
git bisect good 23a457b8d57dc8d0cc1dbd1882993dd2fcc4b0c0
# good: [f57f5010c0c3fe2d924a957ddf1d17fbebb54d47] Merge remote-tracking branch 
'risc-v/for-next'
git bisect good f57f5010c0c3fe2d924a957ddf1d17fbebb54d47
# good: [1d5fd6c33b04e5d5b665446c3b56f2148f0f1272] sh: add missing 
DECLARE_EXPORT() for __ashiftrt_r4_xx
git bisect good 1d5fd6c33b04e5d5b665446c3b56f2148f0f1272
# bad: [8c8f3156dd40f8bdc58f2ac461374bc804c28e3b] sparc32: mm: Reduce 
allocation size for PMD and PTE tables
git bisect bad 8c8f3156dd40f8bdc58f2ac461374bc804c28e3b
# good: [8e958839e4b9fb6ea4385ff2c52d1333a3a618de] sparc32: mm: Restructure 
sparc32 MMU page-table layout
git bisect good 8e958839e4b9fb6ea4385ff2c52d1333a3a618de
# good: [3f407976ac2953116cb8880a7a18b63bcc81829d] sparc32: mm: Change 
pgtable_t type to pte_t * instead of struct page *
git bisect good 3f407976ac2953116cb8880a7a18b63bcc81829d
# first bad commit: [8c8f3156dd40f8bdc58f2ac461374bc804c28e3b] sparc32: mm: 
Reduce allocation size for PMD and PTE tables

---
Log messages:

Lots of:

BUG: scheduling while atomic: kthreadd/2/0x
Modules linked in:
CPU: 0 PID: 2 Comm: kthreadd Tainted: GW 
5.7.0-rc5-next-20200515 #1
[f04f2c94 :
here+0x16c/0x250 ]
[f04f2df0 :
schedule+0x78/0x11c ]
[f003f100 :
kthreadd+0x188/0x1a4 ]
[f0008448 :
ret_from_kernel_thread+0xc/0x38 ]
[ :
0x0 ]

followed by:

Kernel panic - not syncing: Aiee, killing interrupt handler!
CPU: 0 PID: 19 Comm: cryptomgr_test Tainted: GW 
5.7.0-rc5-next-20200515 #1
[f0024400 :
do_exit+0x7c8/0xa88 ]
[f0075540 :
__module_put_and_exit+0xc/0x18 ]
[f0221428 :
cryptomgr_test+0x28/0x48 ]
[f003edc0 :
kthread+0xf4/0x12c ]
[f0008448 :
ret_from_kernel_thread+0xc/0x38 ]
[ :
0x0 ]

Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec_page

2020-05-16 Thread Shakeel Butt

On Sat, May 16, 2020 at 4:39 PM David Miller  wrote:
>
> From: Shakeel Butt 
> Date: Sat, 16 May 2020 15:35:46 -0700
>
> > So, my argument is if non-zero order vzalloc has failed (allocations
> > internal to vzalloc, including virtual mapping allocation and page
> > table allocations, are order 0 and use GFP_KERNEL i.e. triggering
> > reclaim and oom-killer) then the next non-zero order page allocation
> > has very low chance of succeeding.
>
> Also not true.
>
> Page table allocation strategies and limits vary by architecture, they
> may even need virtual mappings themselves.  So they can fail in situations
> where a non-zero GFP_KERNEL page allocator allocation would succeed.

Thanks for the explanation. Do you think calling vzalloc only for
non-zero order here has any value?

Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec_page

2020-05-16 Thread Shakeel Butt

On Sat, May 16, 2020 at 3:45 PM Eric Dumazet  wrote:
>
> On Sat, May 16, 2020 at 3:35 PM Shakeel Butt  wrote:
> >
> > On Sat, May 16, 2020 at 1:40 PM David Miller  wrote:
> > >
> > > From: Shakeel Butt 
> > > Date: Fri, 15 May 2020 19:17:36 -0700
> > >
> > > > and thus there is no need to have any fallback after vzalloc.
> > >
> > > This statement is false.
> > >
> > > The virtual mapping allocation or the page table allocations can fail.
> > >
> > > A fallback is therefore indeed necessary.
> >
> > I am assuming that you at least agree that vzalloc should only be
> > called for non-zero order allocations. So, my argument is if non-zero
> > order vzalloc has failed (allocations internal to vzalloc, including
> > virtual mapping allocation and page table allocations, are order 0 and
> > use GFP_KERNEL i.e. triggering reclaim and oom-killer) then the next
> > non-zero order page allocation has very low chance of succeeding.
>
>
> 32bit kernels might have exhausted their vmalloc space, yet they can
> still allocate order-0 pages.

Oh ok it makes sense.

Re: [PATCH net-next 0/2] net: ipa: sc7180 suspend/resume

From: Alex Elder 
Date: Fri, 15 May 2020 15:07:29 -0500

> This series permits suspend/resume to work for the IPA driver
> on the Qualcomm SC7180 SoC.  The IPA version on this SoC requires
> interrupts to be enabled when the suspend and resume callbacks are
> made, and the first patch moves away from using the noirq variants.
> The second patch fixes a problem with resume that occurs because
> pending interrupts were being cleared before starting a channel.

Series applied, thanks Alex.

Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec_page

From: Shakeel Butt 
Date: Sat, 16 May 2020 15:35:46 -0700

> So, my argument is if non-zero order vzalloc has failed (allocations
> internal to vzalloc, including virtual mapping allocation and page
> table allocations, are order 0 and use GFP_KERNEL i.e. triggering
> reclaim and oom-killer) then the next non-zero order page allocation
> has very low chance of succeeding.

Also not true.

Page table allocation strategies and limits vary by architecture, they
may even need virtual mappings themselves.  So they can fail in situations
where a non-zero GFP_KERNEL page allocator allocation would succeed.

Re: [PATCH target] target: Add initiatorname to NON_EXISTENT_LUN error

2020-05-16 Thread Lance Digby

Mike,  Thanks for the review!
  The pr_err  Detected NON_EXISTENT_LUN is the error messages issued
for the TCM_NON_EXISTENT_LUN retcode so I believe they are the same.
  Simply scanning for the wrong lun on an initiator will generate this
error on the target but not generate an error on the initiator. And I
have seen installs, with a lot of initiators, automate the scanning of
such luns incorrectly deemed missing.
  While this looks like a simple problem it can take days to get
access or the tcp traces to sort it out.

   Within the same routine there is another pr_err for
TCM_WRITE_PROTECTED that I did not add the initiatorname to as I
thought this would leave a heavy footprint on the initiator. If you
believe this should be changed for consistency please let me know and
I will add this and change to nacl->initiatorname.

On Sat, May 16, 2020 at 9:50 AM Mike Christie  wrote:
>
> On 5/13/20 11:01 PM, Lance Digby wrote:
> > The NON_EXISTENT_LUN error can be written without an error condition
> >  on the initiator responsible. Adding the initiatorname to this message
> >  will reduce the effort required to fix this when many initiators are
> > supported by a target.
> >
> > Signed-off-by: Lance Digby 
> > ---
> >  drivers/target/target_core_device.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/target/target_core_device.c 
> > b/drivers/target/target_core_device.c
> > index 4cee113..604dea0 100644
> > --- a/drivers/target/target_core_device.c
> > +++ b/drivers/target/target_core_device.c
> > @@ -100,9 +100,10 @@
> >*/
> >   if (unpacked_lun != 0) {
> >   pr_err("TARGET_CORE[%s]: Detected NON_EXISTENT_LUN"
> > - " Access for 0x%08llx\n",
> > + " Access for 0x%08llx from %s\n",
> >   se_cmd->se_tfo->fabric_name,
> > - unpacked_lun);
> > + unpacked_lun,
> > + se_sess->se_node_acl->initiatorname);
>
> You can do nacl->initiatorname.
>
> Do you also want add the name to the tmr case? It's probably not common,
> but the error message would be consistent.
>
> >   return TCM_NON_EXISTENT_LUN;
> >   }
> >
>

please i really need your urgent assistance.

2020-05-16 Thread Hannah Wilson

Hello My Dear.

Please do not feel disturbed for contacting  you in this regards, It
was based on the critical health condition I find mine self.  My names
 are Mrs. Hannah Wilson David, a widow and I’m suffering from brain
tumor disease and this illness has gotten to a very bad stage, I
 married my husband for Ten years without any family members and no
child.  My husband died after a brief illness that lasted for few
days.

Since the death of my husband, I decided not to remarry again, When my
late husband was alive he deposited the sum of  ($  11,450,000.00,
Nine Million Four Hundred and Fifty Thousand Dollars) with the Bank.
Presently this money is still in bank. And My  Doctor told me that I
don't have much time to live because my illness has gotten to a very
bad stage, Having known my condition I  decided to entrust over the
deposited fund under your custody to take care of the less-privileged
ones therein your country or position,
which i believe that you will utilize this money the way I am going to
instruct herein.

However all I need and required from you is your sincerity and ability
to carry out the transaction successfully and fulfill my final wish in
implementing the charitable project as it requires absolute trust and
devotion without any failure and I will be glad to see that the bank
finally release and transfer the fund into your bank account in your
country even before I die here in the hospital, because my present
health condition is very critical at the moment everything needs to be
process rapidly as soon as possible.

It will be my pleasure to compensate you as my Investment
Manager/Partner with 35 % percent of the total fund for your effort in
 handling the transaction, 5 % percent for any expenses or processing
charges fee that will involve during this process while 60% of the
fund will be Invested into the charity project there in your country
for the mutual benefit of the orphans and the less privileges ones.

Meanwhile I am waiting for your prompt respond, if only you are
interested for further details of the transaction and execution of
this  humanitarian project for the glory and honor of God the merciful
compassionate.

May bless you and your family.
Regards,
Mrs. Hannah Wilson David.
written from Hospital.

[tip:x86/fpu] BUILD SUCCESS 55e00fb66fd5048f4a3ee357018fd26fc527abca

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/fpu
branch HEAD: 55e00fb66fd5048f4a3ee357018fd26fc527abca  x86/fpu/xstate: Restore 
supervisor states for signal return

elapsed time: 481m

configs tested: 95
configs skipped: 91

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
m68k allyesconfig
sparcallyesconfig
mips allyesconfig
mipsmalta_kvm_guest_defconfig
archsdk_defconfig
arc   tb10x_defconfig
h8300alldefconfig
powerpc   allnoconfig
xtensaxip_kc705_defconfig
mips pnx8335_stb225_defconfig
xtensa  defconfig
ia64 allyesconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
mips  allnoconfig
mips allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
x86_64   randconfig-a005-20200517
x86_64   randconfig-a003-20200517
x86_64   randconfig-a006-20200517
x86_64   randconfig-a004-20200517
x86_64   randconfig-a001-20200517
x86_64   randconfig-a002-20200517
i386 randconfig-a006-20200517
i386 randconfig-a005-20200517
i386 randconfig-a003-20200517
i386 randconfig-a001-20200517
i386 randconfig-a004-20200517
i386 randconfig-a002-20200517
i386 randconfig-a012-20200517
i386 randconfig-a016-20200517
i386 randconfig-a014-20200517
i386 randconfig-a011-20200517
i386 randconfig-a013-20200517
i386 randconfig-a015-20200517
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
x86_64  defconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64   rhel
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH v2] x86/boot: Correct relocation destination on old linkers

2020-05-16 Thread Arvind Sankar

On Fri, Mar 13, 2020 at 02:33:50PM -0400, Arvind Sankar wrote:
> On Fri, Feb 07, 2020 at 04:49:26PM -0500, Arvind Sankar wrote:
> > For the 32-bit kernel, as described in commit 6d92bc9d483a ("x86/build:
> > Build compressed x86 kernels as PIE"), pre-2.26 binutils generates
> > R_386_32 relocations in PIE mode.  Since the startup code does not
> > perform relocation, any reloc entry with R_386_32 will remain as 0 in
> > the executing code.
> > 
> > Commit 974f221c84b0 ("x86/boot: Move compressed kernel to the end of the
> > decompression buffer") added a new symbol _end but did not mark it
> > hidden, which doesn't give the correct offset on older linkers. This
> > causes the compressed kernel to be copied beyond the end of the
> > decompression buffer, rather than flush against it. This region of
> > memory may be reserved or already allocated for other purposes by the
> > bootloader.
> > 
> > Mark _end as hidden to fix. This changes the relocation from R_386_32 to
> > R_386_RELATIVE even on the pre-2.26 binutils.
> > 
> > For 64-bit, this is not strictly necessary, as the 64-bit kernel is only
> > built as PIE if the linker supports -z noreloc-overflow, which implies
> > binutils-2.27+, but for consistency, mark _end as hidden here too.
> > 
> 
> Gentle reminder.
> 
> https://lore.kernel.org/lkml/20200207214926.3564079-1-nived...@alum.mit.edu/

Ping.

Re: [PATCH AUTOSEL 5.4 26/35] SUNRPC: defer slow parts of rpc_free_client() to a workqueue.

2020-05-16 Thread Sasha Levin


On Fri, May 08, 2020 at 07:18:53AM +1000, NeilBrown wrote:

On Thu, May 07 2020, Sasha Levin wrote:


From: NeilBrown 

[ Upstream commit 7c4310ff56422ea43418305d22bbc5fe19150ec4 ]


This one is buggy - it introduces a use-after-free.  Best delay it for
now.


I've dropped it, thanks!

--
Thanks,
Sasha

Re: [PATCH AUTOSEL 5.6 33/50] drm/amdgpu: bump version for invalidate L2 before SDMA IBs

2020-05-16 Thread Sasha Levin


On Thu, May 07, 2020 at 06:11:17PM +0200, Michel Dänzer wrote:

On 2020-05-07 4:27 p.m., Sasha Levin wrote:

From: Marek Olšák 

[ Upstream commit 9017a4897a20658f010bebea825262963c10afa6 ]

This fixes GPU hangs due to cache coherency issues.
Bump the driver version. Split out from the original patch.

Signed-off-by: Marek Olšák 
Reviewed-by: Christian König 
Tested-by: Pierre-Eric Pelloux-Prayer 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 42f4febe24c6d..8d45a2b662aeb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -85,9 +85,10 @@
  * - 3.34.0 - Non-DC can flip correctly between buffers with different pitches
  * - 3.35.0 - Add drm_amdgpu_info_device::tcc_disabled_mask
  * - 3.36.0 - Allow reading more status registers on si/cik
+ * - 3.37.0 - L2 is invalidated before SDMA IBs, needed for correctness
  */
 #define KMS_DRIVER_MAJOR   3
-#define KMS_DRIVER_MINOR   36
+#define KMS_DRIVER_MINOR   37
 #define KMS_DRIVER_PATCHLEVEL  0

 int amdgpu_vram_limit = 0;



This requires the parent commit fdf83646c0542ecfb9adc4db8f741a1f43dca058
"drm/amdgpu: invalidate L2 before SDMA IBs (v2)". KMS_DRIVER_MINOR is
bumped to signal to userspace the fix in that commit is present.


I've grabbed the commit you've pointed out as well as ce73516d42c9
("drm/amdgpu: simplify padding calculations (v2)") to make the backport
apply cleanly, thank you!

--
Thanks,
Sasha

Re: [PATCH] net: mscc: ocelot: replace readx_poll_timeout with readx_poll_timeout_atomic

2020-05-16 Thread Vladimir Oltean

On Sat, 16 May 2020 at 23:54, David Miller  wrote:
>
> From: Xulin Sun 
> Date: Fri, 15 May 2020 11:18:13 +0800
>
> > BUG: sleeping function called from invalid context at 
> > drivers/net/ethernet/mscc/ocelot.c:59
> > in_atomic(): 1, irqs_disabled(): 0, pid: 3778, name: ifconfig
> > INFO: lockdep is turned off.
> > Preemption disabled at:
> > [] dev_set_rx_mode+0x24/0x40
> > Hardware name: LS1028A RDB Board (DT)
> > Call trace:
> > dump_backtrace+0x0/0x140
> > show_stack+0x24/0x30
> > dump_stack+0xc4/0x10c
> > ___might_sleep+0x194/0x230
> > __might_sleep+0x58/0x90
> > ocelot_mact_forget+0x74/0xf8
> > ocelot_mc_unsync+0x2c/0x38
> > __hw_addr_sync_dev+0x6c/0x130
> > ocelot_set_rx_mode+0x8c/0xa0
>
> Vladimir states that this call chain is not possible in mainline.
>
> I'm not applying this.

(but the essence of the problem is legitimate though)

There are 2 specific things I don't like:
- The problem is claimed to reproduce on "LS1028A RDB Board (DT)"
which does not call ocelot_set_rx_mode. So it claims to fix a problem
for which only Xulin has the ability to decide whether it is the right
solution or not.
- On ocelot, it _looks_ like it is indeed a problem which was
introduced in 639c1b2625af ("net: mscc: ocelot: Register poll timeout
should be wall time not attempts"). But there was no attempt to bring
it up with the author of that patch, who very clearly expressed that
he is working on hardware where the polling timeout is in the order of
milliseconds, and the timeout for the driver is currently set at 100
ms. I'm not very sure that it is desirable to spin in atomic context
for 100 ms.

Thanks,
-Vladimir

Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec_page

2020-05-16 Thread Eric Dumazet

On Sat, May 16, 2020 at 3:35 PM Shakeel Butt  wrote:
>
> On Sat, May 16, 2020 at 1:40 PM David Miller  wrote:
> >
> > From: Shakeel Butt 
> > Date: Fri, 15 May 2020 19:17:36 -0700
> >
> > > and thus there is no need to have any fallback after vzalloc.
> >
> > This statement is false.
> >
> > The virtual mapping allocation or the page table allocations can fail.
> >
> > A fallback is therefore indeed necessary.
>
> I am assuming that you at least agree that vzalloc should only be
> called for non-zero order allocations. So, my argument is if non-zero
> order vzalloc has failed (allocations internal to vzalloc, including
> virtual mapping allocation and page table allocations, are order 0 and
> use GFP_KERNEL i.e. triggering reclaim and oom-killer) then the next
> non-zero order page allocation has very low chance of succeeding.


32bit kernels might have exhausted their vmalloc space, yet they can
still allocate order-0 pages.

Re: [PATCH v9 4/4] media: i2c: Add RDACM20 driver

2020-05-16 Thread Sakari Ailus

Hi Kieran,

On Tue, May 12, 2020 at 04:51:05PM +0100, Kieran Bingham wrote:
> From: Jacopo Mondi 
> 
> The RDACM20 is a GMSL camera supporting 1280x800 resolution images
> developed by IMI based on an Omnivision 10635 sensor and a Maxim MAX9271
> GMSL serializer.
> 
> The GMSL link carries power, control (I2C) and video data over a
> single coax cable.
> 
> Signed-off-by: Jacopo Mondi 
> Signed-off-by: Laurent Pinchart 
> Signed-off-by: Niklas Söderlund 
> Signed-off-by: Kieran Bingham 
> Reviewed-by: Rob Herring 
> 
> ---
> v2:
>  - Fix MAINTAINERS entry
> 
> v3:
>  - Use new V4L2_MBUS_CSI2_DPHY bus type
>  - Remove 'always zero' error print
>  - Fix module description
> 
> v5:
>  - use sleep rather than busy loops for 10 ms delays
>  - Return ov10635_set_regs directly
>  - Use devm_kzalloc instead of kzalloc in probe()
>  - Or in the flags: dev->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE
>  - Ensure v4l2_ctrl_handler_free() is called
>  - rdacm20_probe converted to use .probe_new and drop i2c device id
>tables
>  - Remove rdacm20_g_mbus_config
> 
> v7:
>  - Use new i2c_new_dummy_device API
> 
> v8:
>  - Almost a new version, main changes are:
>- Split max9271 out
>- Rework bindings to yaml format and include forthcoming RDACM21
>- Remove unecessary header file
>- Add pixel rate calculation
>- Drop unused fields and dead code
>- Rebase on media-master v5.7-rc1
>- A detailed list of changes provided as fixup patches is avilable at
>  git://jmondi.org/linux 
> #gmsl/jmondi/media-master/max9286-v8+old-rdacm20+split
> 
>  which includes the following list of patches:
>squash!: rdacm20: Report pixel rate
>squash!: rdacm20: Force sensor ID re-read
>squash!: rdamc20: Check register programming result
>squash!: rdacm20: Update to use the new max9271 APIs
>squash!: rdacm20: Start with serial link disabled
>squash!: rdacm20: Hard reset the sensor
>squash!: rdacm20: Cache i2c addresses
>squash!: rdacm20: Adjust to use new max9271 API
>squash!: rdacm20: Drop unused format definition
>squash!: rdacm20: Refresh file header
>squash!: max9271: Add two functions to control addresses
>squash!: max9271: Do not rewrite i2c address
>squash!: max9271: Improve gpio handling
>squash!: max9271: Rework core functions
>squash!: max9271 refresh
>squash!: rdacm20: Update maintainers file
>squash!: rdacm20: Remove unsued/duplicated defines
>squash!: rdacm20: Remove header file
>squash!: rdacm20: Move content of  header into C file
>squash!: rdacm20: Reorganize register table
>squash!: rdacm20: Fix subdevice flag creation
>squash!: rdacm20: Drop i2c id table
>squash!: rdacm20: Release control handler
>squash!: rdacm20: Better handle i2c dummy error
>squash!: rdacm20: Use devm_kzalloc
>squash!: rdacm20: Use probe_new()
>squash!: rdacm20: Drop deprecated g_mbus_config
>media: i2c: rdacm20: Break max9271 out from rdacm20
>squash!: rdacm20: Rebase on latest media/maste
>media: i2c: Add RDACM20 driver
>dt-bindings: media: i2c: Add bindings for IMI RDACM2x
> 
> v9:
> - Drop OV10635_FORMAT and use MEDIA_BUS_FMT_UYVY8_2X8 as suggested by
>   Hans
> 
>  MAINTAINERS |  12 +
>  drivers/media/i2c/Kconfig   |  13 +
>  drivers/media/i2c/Makefile  |   2 +
>  drivers/media/i2c/max9271.c | 341 ++
>  drivers/media/i2c/max9271.h | 224 
>  drivers/media/i2c/rdacm20.c | 667 
>  6 files changed, 1259 insertions(+)
>  create mode 100644 drivers/media/i2c/max9271.c
>  create mode 100644 drivers/media/i2c/max9271.h
>  create mode 100644 drivers/media/i2c/rdacm20.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 99e3bf7760fd..713b56652181 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14206,6 +14206,18 @@ S:   Supported
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> dev
>  F:   tools/testing/selftests/rcutorture
>  
> +RDACM20 Camera Sensor
> +M:   Jacopo Mondi 
> +M:   Kieran Bingham 
> +M:   Laurent Pinchart 
> +M:   Niklas Söderlund 
> +L:   linux-me...@vger.kernel.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
> +F:   drivers/media/i2c/rdacm20.c
> +F:   drivers/media/i2c/max9271.c
> +F:   drivers/media/i2c/max9271.h
> +
>  RDC R-321X SoC
>  M:   Florian Fainelli 
>  S:   Maintained
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 2e390f41f6da..6e3300760c7f 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -1157,6 +1157,19 @@ config VIDEO_NOON010PC30
>  
>  source "drivers/media/i2c/m5mols/Kconfig"
>  
> +config VIDEO_RDACM20
> + tristate "IMI RDACM20 camera support"
> + depends on I2C
> + select V4L2_FWNODE
> + select

Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec_page

2020-05-16 Thread Shakeel Butt

On Sat, May 16, 2020 at 1:40 PM David Miller  wrote:
>
> From: Shakeel Butt 
> Date: Fri, 15 May 2020 19:17:36 -0700
>
> > and thus there is no need to have any fallback after vzalloc.
>
> This statement is false.
>
> The virtual mapping allocation or the page table allocations can fail.
>
> A fallback is therefore indeed necessary.

I am assuming that you at least agree that vzalloc should only be
called for non-zero order allocations. So, my argument is if non-zero
order vzalloc has failed (allocations internal to vzalloc, including
virtual mapping allocation and page table allocations, are order 0 and
use GFP_KERNEL i.e. triggering reclaim and oom-killer) then the next
non-zero order page allocation has very low chance of succeeding.

[PATCH] power: supply: max8998_charger: Correct ONLINE and add STATUS props

2020-05-16 Thread Jonathan Bakker

The ONLINE prop should be when the charger is present (ie able to
charge), however, it was for when it was actually charging or not.
Instead, add the STATUS prop to show whether charging is actually
going on or not.

The magic numbers have been ported from a downstream kernel for the
SGH-T959V.

Signed-off-by: Jonathan Bakker 
---
 drivers/power/supply/max8998_charger.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/power/supply/max8998_charger.c 
b/drivers/power/supply/max8998_charger.c
index 9a926c7c0f22..c26023b19f26 100644
--- a/drivers/power/supply/max8998_charger.c
+++ b/drivers/power/supply/max8998_charger.c
@@ -23,6 +23,7 @@ struct max8998_battery_data {
 static enum power_supply_property max8998_battery_props[] = {
POWER_SUPPLY_PROP_PRESENT, /* the presence of battery */
POWER_SUPPLY_PROP_ONLINE, /* charger is active or not */
+   POWER_SUPPLY_PROP_STATUS, /* charger is charging/discharging/full */
 };
 
 /* Note that the charger control is done by a current regulator "CHARGER" */
@@ -49,10 +50,28 @@ static int max8998_battery_get_property(struct power_supply 
*psy,
ret = max8998_read_reg(i2c, MAX8998_REG_STATUS2, );
if (ret)
return ret;
-   if (reg & (1 << 3))
-   val->intval = 0;
-   else
+
+   if (reg & (1 << 5))
val->intval = 1;
+   else
+   val->intval = 0;
+
+   break;
+   case POWER_SUPPLY_PROP_STATUS:
+   ret = max8998_read_reg(i2c, MAX8998_REG_STATUS2, );
+   if (ret)
+   return ret;
+
+   if (!(reg & (1 << 5))) {
+   val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+   } else {
+   if (reg & (1 << 6))
+   val->intval = POWER_SUPPLY_STATUS_FULL;
+   else if (reg & (1 << 3))
+   val->intval = POWER_SUPPLY_STATUS_CHARGING;
+   else
+   val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
+   }
break;
default:
return -EINVAL;
-- 
2.20.1

Re: [PATCH V3 07/15] arch/kunmap_atomic: Consolidate duplicate code

2020-05-16 Thread Guenter Roeck

On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny 
> 
> Every single architecture (including !CONFIG_HIGHMEM) calls...
> 
>   pagefault_enable();
>   preempt_enable();
> 
> ... before returning from __kunmap_atomic().  Lift this code into the
> kunmap_atomic() macro.
> 
> While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> be consistent.
> 
> Reviewed-by: Christoph Hellwig 
> Signed-off-by: Ira Weiny 

This patch results in:

Starting init: /bin/sh exists but couldn't execute it (error -14)

when trying to boot microblazeel:petalogix-ml605 in qemu.

Bisect log attached.

Guenter

---
# bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific files 
for 20200515
# good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
git bisect start 'HEAD' 'v5.7-rc5'
# good: [3674d7aa7a8e61d993886c2fb7c896c5ef85e988] Merge remote-tracking branch 
'crypto/master'
git bisect good 3674d7aa7a8e61d993886c2fb7c896c5ef85e988
# good: [87f6f21783522e6d62127cf33ae5e95f50874beb] Merge remote-tracking branch 
'spi/for-next'
git bisect good 87f6f21783522e6d62127cf33ae5e95f50874beb
# good: [5c428e8277d5d97c85126387d4e00aa5adde4400] Merge remote-tracking branch 
'staging/staging-next'
git bisect good 5c428e8277d5d97c85126387d4e00aa5adde4400
# good: [f68de67ed934e7bdef4799fdc86f33f14982] Merge remote-tracking branch 
'hyperv/hyperv-next'
git bisect good f68de67ed934e7bdef4799fdc86f33f14982
# bad: [54acd2dc52b069da59639eea0d0c92726f32fb01] mm/memblock: fix a typo in 
comment "implict"->"implicit"
git bisect bad 54acd2dc52b069da59639eea0d0c92726f32fb01
# good: [784a17aa58a529b84f7cc50f351ed4acf3bd11f3] mm: remove the pgprot 
argument to __vmalloc
git bisect good 784a17aa58a529b84f7cc50f351ed4acf3bd11f3
# good: [6cd8137ff37e9a37aee2d2a8889c8beb8eab192f] khugepaged: replace the 
usage of system(3) in the test
git bisect good 6cd8137ff37e9a37aee2d2a8889c8beb8eab192f
# bad: [6987da379826ed01b8a1cf046b67cc8cc10117cc] sparc: remove unnecessary 
includes
git bisect bad 6987da379826ed01b8a1cf046b67cc8cc10117cc
# good: [bc17b545388f64c09e83e367898e28f60277c584] mm/hugetlb: define a generic 
fallback for is_hugepage_only_range()
git bisect good bc17b545388f64c09e83e367898e28f60277c584
# bad: [9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011] 
arch-kmap_atomic-consolidate-duplicate-code-checkpatch-fixes
git bisect bad 9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011
# good: [0941a38ff0790c1004270f952067a5918a4ba32d] arch/kmap: remove redundant 
arch specific kmaps
git bisect good 0941a38ff0790c1004270f952067a5918a4ba32d
# good: [56e635a64c2cbfa815c851af10e0f811e809977b] 
arch-kunmap-remove-duplicate-kunmap-implementations-fix
git bisect good 56e635a64c2cbfa815c851af10e0f811e809977b
# bad: [60f96b2233c790d4f1c49317643051f1670bcb29] arch/kmap_atomic: consolidate 
duplicate code
git bisect bad 60f96b2233c790d4f1c49317643051f1670bcb29
# good: [7b3708dc3bf72a647243064fe7ddf9a76248ddfd] 
{x86,powerpc,microblaze}/kmap: move preempt disable
git bisect good 7b3708dc3bf72a647243064fe7ddf9a76248ddfd
# first bad commit: [60f96b2233c790d4f1c49317643051f1670bcb29] 
arch/kmap_atomic: consolidate duplicate code

Re: [PATCH net 1/1] net: ipa: don't be a hog in gsi_channel_poll()

From: Alex Elder 
Date: Fri, 15 May 2020 14:52:03 -0500

> The iteration count value used in gsi_channel_poll() is intended to
> limit poll iterations to the budget supplied as an argument.  But
> it's never updated.
> 
> Fix this bug by incrementing the count each time through the loop.
> 
> Reported-by: Sharath Chandra Vurukala 
> Signed-off-by: Alex Elder 

Applied, thanks.

Re: [RFC PATCH v3 00/12] Integrity Policy Enforcement LSM (IPE)

2020-05-16 Thread Jaskaran Singh Khurana



Hello Mickael,

On Thu, 14 May 2020, Mickaël Salaün wrote:



On 12/05/2020 22:46, Deven Bowers wrote:



On 5/11/2020 11:03 AM, Deven Bowers wrote:



On 5/10/2020 2:28 AM, Mickaël Salaün wrote:

[...snip]



Additionally, rules are evaluated top-to-bottom. As a result, any
revocation rules, or denies should be placed early in the file to
ensure
that these rules are evaluated before a rule with "action=ALLOW" is
hit.

IPE policy is designed to be forward compatible and backwards
compatible,
thus any failure to parse a rule will result in the line being ignored,
and a warning being emitted. If backwards compatibility is not
required,
the kernel commandline parameter and sysctl, ipe.strict_parse can be
enabled, which will cause these warnings to be fatal.


Ignoring unknown command may lead to inconsistent beaviors. To achieve
forward compatibility, I think it would be better to never ignore
unknown rule but to give a way to userspace to known what is the current
kernel ABI. This could be done with a securityfs file listing the
current policy grammar.



That's a fair point. From a manual perspective, I think this is fine.
A human-user can interpret a grammar successfully on their own when new
syntax is introduced.

 From a producing API perspective, I'd have to think about it a bit
more. Ideally, the grammar would be structured in such a way that the
userland
interpreter of this grammar would not have to be updated once new syntax
is introduced, avoiding the need to update the userland binary. To do so
generically ("op=%s") is easy, but doesn't necessarily convey sufficient
information (what happens when a new "op" token is introduced?). I think
this may come down to regular expression representations of valid values
for these tokens, which worries me as regular expressions are incredibly
error-prone[1].

I'll see what I can come up with regarding this.


I have not found a way that I like to expose some kind of grammar
through securityfs that can be understood by usermode to parse the
policy. Here's what I propose as a compromise:

1. I remove the unknown command behavior. This address your
first point about inconsistent behaviors, and effectively removes the
strict_parse sysctl (as it is always enabled).

2. I introduce a versioning system for the properties
themselves. The valid set of properties and their versions
can be found in securityfs, under say, ipe/config in a key=value
format where `key` indicates the understood token, and `value`
indicates their current version. For example:

$ cat $SECURITYFS/ipe/config
op=1
action=1
policy_name=1
policy_version=1
dmverity_signature=1
dmverity_roothash=1
boot_verified=1


The name ipe/config sounds like a file to configure IPE. Maybe something
like ipe/config_abi or ipe/config_grammar?



if new syntax is introduced, the version number is increased.

3. The format of those versions are documented as part of
the admin-guide around IPE. If user-mode at that point wants to rip
the documentation formats and correlate with the versioning, then
it fulfills the same functionality as above, with out the complexity
around exposing a parsing grammar and interpreting it on-the-fly.
Many of these are unlikely to move past version 1, however.

Thoughts?



That seems reasonable.



There is a use case for not having strict parsing in the cloud world where 
there are multiple versions of OS deployed across a large number of 
systems say 100,000 nodes. An OS update can take weeks to complete 
across all the nodes, and we end up having a heterogeneous mix of OS 
versions.


Without non-strict parsing, to fix an issue in a policy we will need to 
update the various versions of the policy (one each for all OS versions
which have different IPE policy schema). We will lose the agility we 
need to fix and deploy something urgently in the policy, the nodes might 
be failing some critical workloads meanwhile. All the various versions of 
the policy will need to be changed and production signed then deployed 
etc. Further some versions might introduce newer issues and we will need 
to see what all versions of the policy have that bug.


I propose keeping the non-strict option as well to cater to this use case. 
Let me know your thoughts on this.


Regards,
JK

[PATCH 11/12] gpu/drm: Ingenic: Add support for the IPU

Add support for the Image Processing Unit (IPU) found in all Ingenic
SoCs.

The IPU can upscale and downscale a source frame of arbitrary size
ranging from 4x4 to 4096x4096 on newer SoCs, with bicubic filtering
on newer SoCs, bilinear filtering on older SoCs. Nearest-neighbour can
also be obtained with proper coefficients.

Starting from the JZ4725B, the IPU supports a mode where its output is
sent directly to the CRTC, without having to be written to RAM first.
This makes it possible to use the IPU as a DRM plane on the compatible
SoCs, and have it convert and scale anything the userspace asks for to
what's available for the display.

Regarding pixel formats, older SoCs support packed YUV 4:2:2 and various
planar YUV formats. Newer SoCs also support RGB.

The CRTC can toggle between the primary plane and the IPU, but cannot
display both at the same time. The IPU plane is then a primary plane
itself.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/Kconfig   |  11 +
 drivers/gpu/drm/ingenic/Makefile  |   1 +
 drivers/gpu/drm/ingenic/ingenic-drm.c |  67 +-
 drivers/gpu/drm/ingenic/ingenic-drm.h |   9 +
 drivers/gpu/drm/ingenic/ingenic-ipu.c | 861 ++
 drivers/gpu/drm/ingenic/ingenic-ipu.h | 110 
 6 files changed, 1048 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/ingenic/ingenic-ipu.c
 create mode 100644 drivers/gpu/drm/ingenic/ingenic-ipu.h

diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index d82c3d37ec9c..80e10527d404 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -14,3 +14,14 @@ config DRM_INGENIC
  Choose this option for DRM support for the Ingenic SoCs.
 
  If M is selected the module will be called ingenic-drm.
+
+if DRM_INGENIC
+
+config DRM_INGENIC_IPU
+   tristate "IPU support for Ingenic SoCs"
+   help
+ Choose this option to enable support for the IPU found in Ingenic 
SoCs.
+
+ If M is selected the module will be called ingenic-ipu.
+
+endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index 11cac42ce0bb..df156194fbe5 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
+obj-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index b53db3ee001f..ad1cec4f2a4d 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -50,7 +50,7 @@ struct jz_soc_info {
 
 struct ingenic_drm {
struct drm_device drm;
-   struct drm_plane f0, f1;
+   struct drm_plane f0, f1, *ipu_plane;
struct drm_crtc crtc;
struct drm_encoder encoder;
 
@@ -186,13 +186,16 @@ static void ingenic_drm_crtc_update_timings(struct 
ingenic_drm *priv,
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
   JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16,
   JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16);
+
+   regmap_write(priv->map, JZ_REG_LCD_IPUR, JZ_LCD_IPUR_IPUREN |
+(ht * vpe / 3) << JZ_LCD_IPUR_IPUR_LSB);
 }
 
 static int ingenic_drm_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_crtc_state *state)
 {
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
-   struct drm_plane_state *f1_state, *f0_state;
+   struct drm_plane_state *f1_state, *f0_state, *ipu_state;
long rate;
 
if (!drm_atomic_crtc_needs_modeset(state))
@@ -213,14 +216,41 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc 
*crtc,
f0_state = drm_atomic_get_plane_state(state->state,
  >f0);
 
+   if (priv->ipu_plane)
+   ipu_state = drm_atomic_get_plane_state(state->state,
+  priv->ipu_plane);
+
+   /* IPU and F1 planes cannot be enabled at the same time. */
+   if (priv->ipu_plane && f1_state->fb && ipu_state->fb) {
+   dev_dbg(priv->dev, "Cannot enable both F1 and IPU\n");
+   return -EINVAL;
+   }
+
/* If all the planes are disabled, we won't get a VBLANK IRQ */
-   if (!f1_state->fb && !f0_state->fb)
+   if (!f1_state->fb && !f0_state->fb &&
+   !(priv->ipu_plane && ipu_state->fb))
state->no_vblank = true;
}
 
return 0;
 }
 
+static void ingenic_drm_crtc_atomic_begin(struct drm_crtc *crtc,
+ struct drm_crtc_state *oldstate)
+{
+   struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
+   u32 ctrl = 0;
+
+   if (priv->soc_info->has_osd &&
+   drm_atomic_crtc_needs_modeset(crtc->state)) {
+

[PATCH 12/12] gpu/drm: Ingenic: Support multiple panels/bridges

Support multiple panels or bridges connected to the same DPI output of
the SoC. This setup can be found for instance on the GCW Zero, where the
same DPI output interfaces the internal 320x240 TFT panel, and the ITE
IT6610 HDMI chip.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 74 ---
 1 file changed, 43 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index ad1cec4f2a4d..091e3d3c9027 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -52,7 +52,6 @@ struct ingenic_drm {
struct drm_device drm;
struct drm_plane f0, f1, *ipu_plane;
struct drm_crtc crtc;
-   struct drm_encoder encoder;
 
struct device *dev;
struct regmap *map;
@@ -106,12 +105,6 @@ static inline struct ingenic_drm *drm_crtc_get_priv(struct 
drm_crtc *crtc)
return container_of(crtc, struct ingenic_drm, crtc);
 }
 
-static inline struct ingenic_drm *
-drm_encoder_get_priv(struct drm_encoder *encoder)
-{
-   return container_of(encoder, struct ingenic_drm, encoder);
-}
-
 static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_crtc_state *state)
 {
@@ -456,7 +449,7 @@ static void ingenic_drm_encoder_atomic_mode_set(struct 
drm_encoder *encoder,
struct drm_crtc_state 
*crtc_state,
struct drm_connector_state 
*conn_state)
 {
-   struct ingenic_drm *priv = drm_encoder_get_priv(encoder);
+   struct ingenic_drm *priv = drm_device_get_priv(encoder->dev);
struct drm_display_mode *mode = _state->adjusted_mode;
struct drm_connector *conn = conn_state->connector;
struct drm_display_info *info = >display_info;
@@ -670,9 +663,11 @@ static int ingenic_drm_bind(struct device *dev)
struct clk *parent_clk;
struct drm_bridge *bridge;
struct drm_panel *panel;
+   struct drm_encoder *encoder;
struct drm_device *drm;
void __iomem *base;
long parent_rate;
+   unsigned int i, clone_mask = 0;
int ret, irq;
 
soc_info = of_device_get_match_data(dev);
@@ -744,17 +739,6 @@ static int ingenic_drm_bind(struct device *dev)
return PTR_ERR(priv->pix_clk);
}
 
-   ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, , );
-   if (ret) {
-   if (ret != -EPROBE_DEFER)
-   dev_err(dev, "Failed to get panel handle");
-   return ret;
-   }
-
-   if (panel)
-   bridge = devm_drm_panel_bridge_add_typed(dev, panel,
-
DRM_MODE_CONNECTOR_DPI);
-
priv->dma_hwdesc[0] = dma_alloc_coherent(dev,
 sizeof(*priv->dma_hwdesc[0]),
 >dma_hwdesc_phys[0],
@@ -821,22 +805,50 @@ static int ingenic_drm_bind(struct device *dev)
}
}
 
-   priv->encoder.possible_crtcs = 1;
+   for (i = 0; ; i++) {
+   ret = drm_of_find_panel_or_bridge(dev->of_node, 0, i,
+ , );
+   if (ret) {
+   if (ret == -ENODEV)
+   break; /* we're done */
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev, "Failed to get bridge handle\n");
+   return ret;
+   }
 
-   drm_encoder_helper_add(>encoder,
-  _drm_encoder_helper_funcs);
+   if (panel)
+   bridge = devm_drm_panel_bridge_add_typed(dev, panel,
+
DRM_MODE_CONNECTOR_DPI);
 
-   ret = drm_simple_encoder_init(drm, >encoder,
- DRM_MODE_ENCODER_DPI);
-   if (ret) {
-   dev_err(dev, "Failed to init encoder: %i", ret);
-   return ret;
+   encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);
+   if (!encoder)
+   return -ENOMEM;
+
+   encoder->possible_crtcs = 1;
+
+   drm_encoder_helper_add(encoder,
+  _drm_encoder_helper_funcs);
+
+   ret = drm_simple_encoder_init(drm, encoder,
+ DRM_MODE_ENCODER_DPI);
+   if (ret) {
+   dev_err(dev, "Failed to init encoder: %d\n", ret);
+   return ret;
+   }
+
+   ret = drm_bridge_attach(encoder, bridge, NULL, 0);
+   if (ret) {
+   dev_err(dev, "Unable to attach bridge");
+   return ret;
+   }

[PATCH 10/12] gpu/drm: Ingenic: Register driver as component master

Register the ingenic-drm driver as a component master.

This will later allow to plug optional components to the driver, for
instance to add support for the IPU, or the SLCD module.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 61 +--
 1 file changed, 57 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index f139af5b7a40..b53db3ee001f 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -6,6 +6,7 @@
 
 #include "ingenic-drm.h"
 
+#include 
 #include 
 #include 
 #include 
@@ -613,10 +614,17 @@ static void ingenic_drm_free_dma_hwdesc(void *d)
  priv->dma_hwdesc[1], priv->dma_hwdesc_phys[1]);
 }
 
-static int ingenic_drm_probe(struct platform_device *pdev)
+static void ingenic_drm_unbind_all(void *d)
 {
+   struct ingenic_drm *priv = d;
+
+   component_unbind_all(priv->dev, >drm);
+}
+
+static int ingenic_drm_bind(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
const struct jz_soc_info *soc_info;
-   struct device *dev = >dev;
struct ingenic_drm *priv;
struct clk *parent_clk;
struct drm_bridge *bridge;
@@ -653,6 +661,17 @@ static int ingenic_drm_probe(struct platform_device *pdev)
drm->mode_config.max_height = 4095;
drm->mode_config.funcs = _drm_mode_config_funcs;
 
+   ret = component_bind_all(dev, drm);
+   if (ret) {
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev, "Failed to bind components: %i", ret);
+   return ret;
+   }
+
+   ret = devm_add_action_or_reset(dev, ingenic_drm_unbind_all, priv);
+   if (ret)
+   return ret;
+
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base)) {
dev_err(dev, "Failed to get memory resource");
@@ -843,9 +862,14 @@ static int ingenic_drm_probe(struct platform_device *pdev)
return ret;
 }
 
-static int ingenic_drm_remove(struct platform_device *pdev)
+static int compare_of(struct device *dev, void *data)
+{
+   return dev->of_node == data;
+}
+
+static void ingenic_drm_unbind(struct device *dev)
 {
-   struct ingenic_drm *priv = platform_get_drvdata(pdev);
+   struct ingenic_drm *priv = dev_get_drvdata(dev);
 
if (priv->lcd_clk)
clk_disable_unprepare(priv->lcd_clk);
@@ -853,6 +877,35 @@ static int ingenic_drm_remove(struct platform_device *pdev)
 
drm_dev_unregister(>drm);
drm_atomic_helper_shutdown(>drm);
+}
+
+static const struct component_master_ops ingenic_master_ops = {
+   .bind = ingenic_drm_bind,
+   .unbind = ingenic_drm_unbind,
+};
+
+static int ingenic_drm_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct component_match *match = NULL;
+   struct device_node *np;
+   unsigned int i;
+
+   /* Probe components at port address 8 and upwards */
+   for (i = 8; ; i++) {
+   np = of_graph_get_remote_node(dev->of_node, i, 0);
+   if (!np)
+   break;
+
+   drm_of_component_match_add(dev, , compare_of, np);
+   }
+
+   return component_master_add_with_match(dev, _master_ops, match);
+}
+
+static int ingenic_drm_remove(struct platform_device *pdev)
+{
+   component_master_del(>dev, _master_ops);
 
return 0;
 }
-- 
2.26.2

[PATCH 09/12] gpu/drm: Ingenic: Add support for OSD mode

All Ingenic SoCs starting from the JZ4725B support OSD mode.

In this mode, two separate planes can be used. They can have different
positions and sizes, and one can be overlayed on top of the other.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 275 +-
 drivers/gpu/drm/ingenic/ingenic-drm.h |  35 
 2 files changed, 258 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 92c63d1303f9..f139af5b7a40 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -43,12 +43,13 @@ struct ingenic_dma_hwdesc {
 
 struct jz_soc_info {
bool needs_dev_clk;
+   bool has_osd;
unsigned int max_width, max_height;
 };
 
 struct ingenic_drm {
struct drm_device drm;
-   struct drm_plane primary;
+   struct drm_plane f0, f1;
struct drm_crtc crtc;
struct drm_encoder encoder;
 
@@ -57,8 +58,8 @@ struct ingenic_drm {
struct clk *lcd_clk, *pix_clk;
const struct jz_soc_info *soc_info;
 
-   struct ingenic_dma_hwdesc *dma_hwdesc;
-   dma_addr_t dma_hwdesc_phys;
+   struct ingenic_dma_hwdesc *dma_hwdesc[2];
+   dma_addr_t dma_hwdesc_phys[2];
 
bool panel_is_sharp;
 };
@@ -90,7 +91,7 @@ static const struct regmap_config ingenic_drm_regmap_config = 
{
.val_bits = 32,
.reg_stride = 4,
 
-   .max_register = JZ_REG_LCD_CMD1,
+   .max_register = JZ_REG_LCD_SIZE1,
.writeable_reg = ingenic_drm_writeable_reg,
 };
 
@@ -110,11 +111,6 @@ drm_encoder_get_priv(struct drm_encoder *encoder)
return container_of(encoder, struct ingenic_drm, encoder);
 }
 
-static inline struct ingenic_drm *drm_plane_get_priv(struct drm_plane *plane)
-{
-   return container_of(plane, struct ingenic_drm, primary);
-}
-
 static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_crtc_state *state)
 {
@@ -185,34 +181,17 @@ static void ingenic_drm_crtc_update_timings(struct 
ingenic_drm *priv,
regmap_write(priv->map, JZ_REG_LCD_SPL, hpe << 16 | (hpe + 1));
regmap_write(priv->map, JZ_REG_LCD_REV, mode->htotal << 16);
}
-}
-
-static void ingenic_drm_crtc_update_ctrl(struct ingenic_drm *priv,
-const struct drm_format_info *finfo)
-{
-   unsigned int ctrl = JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16;
-
-   switch (finfo->format) {
-   case DRM_FORMAT_XRGB1555:
-   ctrl |= JZ_LCD_CTRL_RGB555;
-   /* fall-through */
-   case DRM_FORMAT_RGB565:
-   ctrl |= JZ_LCD_CTRL_BPP_15_16;
-   break;
-   case DRM_FORMAT_XRGB:
-   ctrl |= JZ_LCD_CTRL_BPP_18_24;
-   break;
-   }
 
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
-  JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16 |
-  JZ_LCD_CTRL_BPP_MASK, ctrl);
+  JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16,
+  JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16);
 }
 
 static int ingenic_drm_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_crtc_state *state)
 {
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
+   struct drm_plane_state *f1_state, *f0_state;
long rate;
 
if (!drm_atomic_crtc_needs_modeset(state))
@@ -227,6 +206,17 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc 
*crtc,
if (rate < 0)
return rate;
 
+   if (priv->soc_info->has_osd) {
+   f1_state = drm_atomic_get_plane_state(state->state,
+ >f1);
+   f0_state = drm_atomic_get_plane_state(state->state,
+ >f0);
+
+   /* If all the planes are disabled, we won't get a VBLANK IRQ */
+   if (!f1_state->fb && !f0_state->fb)
+   state->no_vblank = true;
+   }
+
return 0;
 }
 
@@ -236,14 +226,9 @@ static void ingenic_drm_crtc_atomic_flush(struct drm_crtc 
*crtc,
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
struct drm_crtc_state *state = crtc->state;
struct drm_pending_vblank_event *event = state->event;
-   struct drm_framebuffer *drm_fb = crtc->primary->state->fb;
-   const struct drm_format_info *finfo;
 
if (drm_atomic_crtc_needs_modeset(state)) {
-   finfo = drm_format_info(drm_fb->format->format);
-
ingenic_drm_crtc_update_timings(priv, >mode);
-   ingenic_drm_crtc_update_ctrl(priv, finfo);
 
clk_set_rate(priv->pix_clk, state->adjusted_mode.clock * 1000);
}
@@ -260,12 +245,149 @@ static void ingenic_drm_crtc_atomic_flush(struct 
drm_crtc *crtc,
}
 }

[PATCH 07/12] gpu/drm: ingenic: Set DMA descriptor chain address in probe

The address of the DMA descriptor never changes. It can therefore be set
in the probe function.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 3207105755c9..e43318938e9e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -358,8 +358,6 @@ static void ingenic_drm_crtc_atomic_flush(struct drm_crtc 
*crtc,
ingenic_drm_crtc_update_ctrl(priv, finfo);
 
clk_set_rate(priv->pix_clk, state->adjusted_mode.clock * 1000);
-
-   regmap_write(priv->map, JZ_REG_LCD_DA0, priv->dma_hwdesc->next);
}
 
if (event) {
@@ -768,6 +766,9 @@ static int ingenic_drm_probe(struct platform_device *pdev)
}
}
 
+   /* Set address of our DMA descriptor chain */
+   regmap_write(priv->map, JZ_REG_LCD_DA0, priv->dma_hwdesc_phys);
+
ret = drm_dev_register(drm, 0);
if (ret) {
dev_err(dev, "Failed to register DRM driver");
-- 
2.26.2

[PATCH 08/12] gpu/drm: Ingenic: Move register definitions to ingenic-drm.h

Move the register definitions to ingenic-drm.h, to keep ingenic-drm.c
tidy.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 116 +--
 drivers/gpu/drm/ingenic/ingenic-drm.h | 127 ++
 2 files changed, 129 insertions(+), 114 deletions(-)
 create mode 100644 drivers/gpu/drm/ingenic/ingenic-drm.h

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index e43318938e9e..92c63d1303f9 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -4,6 +4,8 @@
 //
 // Copyright (C) 2019, Paul Cercueil 
 
+#include "ingenic-drm.h"
+
 #include 
 #include 
 #include 
@@ -32,120 +34,6 @@
 #include 
 #include 
 
-#define JZ_REG_LCD_CFG 0x00
-#define JZ_REG_LCD_VSYNC   0x04
-#define JZ_REG_LCD_HSYNC   0x08
-#define JZ_REG_LCD_VAT 0x0C
-#define JZ_REG_LCD_DAH 0x10
-#define JZ_REG_LCD_DAV 0x14
-#define JZ_REG_LCD_PS  0x18
-#define JZ_REG_LCD_CLS 0x1C
-#define JZ_REG_LCD_SPL 0x20
-#define JZ_REG_LCD_REV 0x24
-#define JZ_REG_LCD_CTRL0x30
-#define JZ_REG_LCD_STATE   0x34
-#define JZ_REG_LCD_IID 0x38
-#define JZ_REG_LCD_DA0 0x40
-#define JZ_REG_LCD_SA0 0x44
-#define JZ_REG_LCD_FID00x48
-#define JZ_REG_LCD_CMD00x4C
-#define JZ_REG_LCD_DA1 0x50
-#define JZ_REG_LCD_SA1 0x54
-#define JZ_REG_LCD_FID10x58
-#define JZ_REG_LCD_CMD10x5C
-
-#define JZ_LCD_CFG_SLCDBIT(31)
-#define JZ_LCD_CFG_PS_DISABLE  BIT(23)
-#define JZ_LCD_CFG_CLS_DISABLE BIT(22)
-#define JZ_LCD_CFG_SPL_DISABLE BIT(21)
-#define JZ_LCD_CFG_REV_DISABLE BIT(20)
-#define JZ_LCD_CFG_HSYNCM  BIT(19)
-#define JZ_LCD_CFG_PCLKM   BIT(18)
-#define JZ_LCD_CFG_INV BIT(17)
-#define JZ_LCD_CFG_SYNC_DIRBIT(16)
-#define JZ_LCD_CFG_PS_POLARITY BIT(15)
-#define JZ_LCD_CFG_CLS_POLARITYBIT(14)
-#define JZ_LCD_CFG_SPL_POLARITYBIT(13)
-#define JZ_LCD_CFG_REV_POLARITYBIT(12)
-#define JZ_LCD_CFG_HSYNC_ACTIVE_LOWBIT(11)
-#define JZ_LCD_CFG_PCLK_FALLING_EDGE   BIT(10)
-#define JZ_LCD_CFG_DE_ACTIVE_LOW   BIT(9)
-#define JZ_LCD_CFG_VSYNC_ACTIVE_LOWBIT(8)
-#define JZ_LCD_CFG_18_BIT  BIT(7)
-#define JZ_LCD_CFG_PDW (BIT(5) | BIT(4))
-
-#define JZ_LCD_CFG_MODE_GENERIC_16BIT  0
-#define JZ_LCD_CFG_MODE_GENERIC_18BIT  BIT(7)
-#define JZ_LCD_CFG_MODE_GENERIC_24BIT  BIT(6)
-
-#define JZ_LCD_CFG_MODE_SPECIAL_TFT_1  1
-#define JZ_LCD_CFG_MODE_SPECIAL_TFT_2  2
-#define JZ_LCD_CFG_MODE_SPECIAL_TFT_3  3
-
-#define JZ_LCD_CFG_MODE_TV_OUT_P   4
-#define JZ_LCD_CFG_MODE_TV_OUT_I   6
-
-#define JZ_LCD_CFG_MODE_SINGLE_COLOR_STN   8
-#define JZ_LCD_CFG_MODE_SINGLE_MONOCHROME_STN  9
-#define JZ_LCD_CFG_MODE_DUAL_COLOR_STN 10
-#define JZ_LCD_CFG_MODE_DUAL_MONOCHROME_STN11
-
-#define JZ_LCD_CFG_MODE_8BIT_SERIAL12
-#define JZ_LCD_CFG_MODE_LCM13
-
-#define JZ_LCD_VSYNC_VPS_OFFSET16
-#define JZ_LCD_VSYNC_VPE_OFFSET0
-
-#define JZ_LCD_HSYNC_HPS_OFFSET16
-#define JZ_LCD_HSYNC_HPE_OFFSET0
-
-#define JZ_LCD_VAT_HT_OFFSET   16
-#define JZ_LCD_VAT_VT_OFFSET   0
-
-#define JZ_LCD_DAH_HDS_OFFSET  16
-#define JZ_LCD_DAH_HDE_OFFSET  0
-
-#define JZ_LCD_DAV_VDS_OFFSET  16
-#define JZ_LCD_DAV_VDE_OFFSET  0
-
-#define JZ_LCD_CTRL_BURST_4(0x0 << 28)
-#define JZ_LCD_CTRL_BURST_8(0x1 << 28)
-#define JZ_LCD_CTRL_BURST_16   (0x2 << 28)
-#define JZ_LCD_CTRL_RGB555 BIT(27)
-#define JZ_LCD_CTRL_OFUP   BIT(26)
-#define JZ_LCD_CTRL_FRC_GRAYSCALE_16   (0x0 << 24)
-#define JZ_LCD_CTRL_FRC_GRAYSCALE_4(0x1 << 24)
-#define JZ_LCD_CTRL_FRC_GRAYSCALE_2(0x2 << 24)
-#define JZ_LCD_CTRL_PDD_MASK   (0xff << 16)
-#define JZ_LCD_CTRL_EOF_IRQBIT(13)
-#define JZ_LCD_CTRL_SOF_IRQBIT(12)
-#define JZ_LCD_CTRL_OFU_IRQBIT(11)
-#define

[PATCH 06/12] gpu/drm: Ingenic: Fix incorrect assumption about plane->index

plane->index is NOT the index of the color plane in a YUV frame.
Actually, a YUV frame is represented by a single drm_plane, even though
it contains three Y, U, V planes.

Cc: sta...@vger.kernel.org # v5.3
Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 97244462599b..3207105755c9 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -386,7 +386,7 @@ static void ingenic_drm_plane_atomic_update(struct 
drm_plane *plane,
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
width = state->src_w >> 16;
height = state->src_h >> 16;
-   cpp = state->fb->format->cpp[plane->index];
+   cpp = state->fb->format->cpp[0];
 
priv->dma_hwdesc->addr = addr;
priv->dma_hwdesc->cmd = width * height * cpp / 4;
-- 
2.26.2

[PATCH 04/12] gpu/drm: ingenic: Fix bogus crtc_atomic_check callback

The code was comparing the SoC's maximum height with the mode's width,
and vice-versa. D'oh.

Cc: sta...@vger.kernel.org # v5.6
Fixes: a7c909b7c037 ("gpu/drm: ingenic: Check for display size in CRTC atomic 
check")
Signed-off-by: Paul Cercueil 
---

Notes:
This patch was previously sent standalone.
I marked it as superseded in patchwork.
Nothing has been changed here.

 drivers/gpu/drm/ingenic/ingenic-drm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 632d72177123..0c472382a08b 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -330,8 +330,8 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc 
*crtc,
if (!drm_atomic_crtc_needs_modeset(state))
return 0;
 
-   if (state->mode.hdisplay > priv->soc_info->max_height ||
-   state->mode.vdisplay > priv->soc_info->max_width)
+   if (state->mode.hdisplay > priv->soc_info->max_width ||
+   state->mode.vdisplay > priv->soc_info->max_height)
return -EINVAL;
 
rate = clk_round_rate(priv->pix_clk,
-- 
2.26.2

[PATCH 05/12] gpu/drm: Ingenic: Fix opaque pointer casted to wrong type

The opaque pointer passed to the IRQ handler is a pointer to the
drm_device, not a pointer to our ingenic_drm structure.

It still worked, because our ingenic_drm structure contains the
drm_device as its first field, so the pointer received had the same
value, but this was not semantically correct.

Cc: sta...@vger.kernel.org # v5.3
Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 0c472382a08b..97244462599b 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -476,7 +476,7 @@ static int ingenic_drm_encoder_atomic_check(struct 
drm_encoder *encoder,
 
 static irqreturn_t ingenic_drm_irq_handler(int irq, void *arg)
 {
-   struct ingenic_drm *priv = arg;
+   struct ingenic_drm *priv = drm_device_get_priv(arg);
unsigned int state;
 
regmap_read(priv->map, JZ_REG_LCD_STATE, );
-- 
2.26.2

[PATCH 03/12] component: Support binding with no matches

Support binding the master even though no components have been
registered.

This permits to support cases where components are optional.

Signed-off-by: Paul Cercueil 
---
 drivers/base/component.c | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index e97704104784..a9de7ee1677f 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -100,7 +100,7 @@ static int component_devices_show(struct seq_file *s, void 
*data)
 
seq_printf(s, "%-40s %20s\n", "device name", "status");
seq_puts(s, 
"-\n");
-   for (i = 0; i < match->num; i++) {
+   for (i = 0; !!match && i < match->num; i++) {
struct component *component = match->compare[i].component;
 
seq_printf(s, "%-40s %20s\n",
@@ -184,6 +184,11 @@ static int find_components(struct master *master)
size_t i;
int ret = 0;
 
+   if (!match) {
+   dev_dbg(master->dev, "No components\n");
+   return 0;
+   }
+
/*
 * Scan the array of match functions and attach
 * any components which are found to this master.
@@ -218,10 +223,12 @@ static void remove_component(struct master *master, 
struct component *c)
 {
size_t i;
 
-   /* Detach the component from this master. */
-   for (i = 0; i < master->match->num; i++)
-   if (master->match->compare[i].component == c)
-   master->match->compare[i].component = NULL;
+   if (master->match) {
+   /* Detach the component from this master. */
+   for (i = 0; i < master->match->num; i++)
+   if (master->match->compare[i].component == c)
+   master->match->compare[i].component = NULL;
+   }
 }
 
 /*
@@ -470,10 +477,12 @@ int component_master_add_with_match(struct device *dev,
struct master *master;
int ret;
 
-   /* Reallocate the match array for its true size */
-   ret = component_match_realloc(dev, match, match->num);
-   if (ret)
-   return ret;
+   if (match) {
+   /* Reallocate the match array for its true size */
+   ret = component_match_realloc(dev, match, match->num);
+   if (ret)
+   return ret;
+   }
 
master = kzalloc(sizeof(*master), GFP_KERNEL);
if (!master)
@@ -557,6 +566,10 @@ void component_unbind_all(struct device *master_dev, void 
*data)
if (!master)
return;
 
+   /* No match, nothing to unbind */
+   if (!master->match)
+   return;
+
/* Unbind components in reverse order */
for (i = master->match->num; i--; )
if (!master->match->compare[i].duplicate) {
@@ -640,6 +653,10 @@ int component_bind_all(struct device *master_dev, void 
*data)
if (!master)
return -EINVAL;
 
+   /* No match, nothing to bind */
+   if (!master->match)
+   return 0;
+
/* Bind components in match order */
for (i = 0; i < master->match->num; i++)
if (!master->match->compare[i].duplicate) {
-- 
2.26.2

Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver

2020-05-16 Thread Sakari Ailus

Hi Kieran,

Thanks for the update.

On Tue, May 12, 2020 at 04:51:03PM +0100, Kieran Bingham wrote:

...

> +static int max9286_enum_mbus_code(struct v4l2_subdev *sd,
> +   struct v4l2_subdev_pad_config *cfg,
> +   struct v4l2_subdev_mbus_code_enum *code)
> +{
> + if (code->pad || code->index > 0)
> + return -EINVAL;
> +
> + code->code = MEDIA_BUS_FMT_UYVY8_2X8;

Why UYVY8_2X8 and not UYVY8_1X16? In general, the single sample / pixel
variant of the format is generally used on the serial busses. This choice
was made when serial busses were introduced.

> +
> + return 0;
> +}
> +
> +static struct v4l2_mbus_framefmt *
> +max9286_get_pad_format(struct max9286_priv *priv,
> +struct v4l2_subdev_pad_config *cfg,
> +unsigned int pad, u32 which)
> +{
> + switch (which) {
> + case V4L2_SUBDEV_FORMAT_TRY:
> + return v4l2_subdev_get_try_format(>sd, cfg, pad);
> + case V4L2_SUBDEV_FORMAT_ACTIVE:
> + return >fmt[pad];
> + default:
> + return NULL;
> + }
> +}
> +
> +static int max9286_set_fmt(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg,
> +struct v4l2_subdev_format *format)
> +{
> + struct max9286_priv *priv = sd_to_max9286(sd);
> + struct v4l2_mbus_framefmt *cfg_fmt;
> +
> + if (format->pad >= MAX9286_SRC_PAD)
> + return -EINVAL;

You can remove these checks; it's been already done by the caller.

...

> +static int max9286_parse_dt(struct max9286_priv *priv)
> +{
> + struct device *dev = >client->dev;
> + struct device_node *i2c_mux;
> + struct device_node *node = NULL;
> + unsigned int i2c_mux_mask = 0;
> +
> + of_node_get(dev->of_node);
> + i2c_mux = of_find_node_by_name(dev->of_node, "i2c-mux");
> + if (!i2c_mux) {
> + dev_err(dev, "Failed to find i2c-mux node\n");
> + of_node_put(dev->of_node);
> + return -EINVAL;
> + }
> +
> + /* Identify which i2c-mux channels are enabled */
> + for_each_child_of_node(i2c_mux, node) {
> + u32 id = 0;
> +
> + of_property_read_u32(node, "reg", );
> + if (id >= MAX9286_NUM_GMSL)
> + continue;
> +
> + if (!of_device_is_available(node)) {
> + dev_dbg(dev, "Skipping disabled I2C bus port %u\n", id);
> + continue;
> + }
> +
> + i2c_mux_mask |= BIT(id);
> + }
> + of_node_put(node);
> + of_node_put(i2c_mux);
> +
> + /* Parse the endpoints */
> + for_each_endpoint_of_node(dev->of_node, node) {
> + struct max9286_source *source;
> + struct of_endpoint ep;
> +
> + of_graph_parse_endpoint(node, );
> + dev_dbg(dev, "Endpoint %pOF on port %d",
> + ep.local_node, ep.port);
> +
> + if (ep.port > MAX9286_NUM_GMSL) {
> + dev_err(dev, "Invalid endpoint %s on port %d",
> + of_node_full_name(ep.local_node), ep.port);
> + continue;
> + }
> +
> + /* For the source endpoint just parse the bus configuration. */
> + if (ep.port == MAX9286_SRC_PAD) {
> + struct v4l2_fwnode_endpoint vep = {
> + .bus_type = V4L2_MBUS_CSI2_DPHY
> + };
> + int ret;
> +
> + ret = v4l2_fwnode_endpoint_parse(
> + of_fwnode_handle(node), );
> + if (ret) {
> + of_node_put(node);
> + of_node_put(dev->of_node);
> + return ret;
> + }
> +
> + if (vep.bus_type != V4L2_MBUS_CSI2_DPHY) {

This won't happen, the bus type will stay if you set it to a non-zero
value.

> + dev_err(dev,
> + "Media bus %u type not supported\n",
> + vep.bus_type);
> + v4l2_fwnode_endpoint_free();
> + of_node_put(node);
> + of_node_put(dev->of_node);
> + return -EINVAL;
> + }
> +
> + priv->csi2_data_lanes =
> + vep.bus.mipi_csi2.num_data_lanes;
> + v4l2_fwnode_endpoint_free();

No need to call this unless you use v4l2_fwnode_endpoint_alloc_parse().

And as you don't, you also won't know which frequencies are known to be
safe to use. That said, perhaps where this device is used having a random
frequency on that bus could not be an issue. Perhaps.

> +
> + continue;
> + }
> +
> +

[PATCH 01/12] dt-bindings: display: Convert ingenic,lcd.txt to YAML

Convert the ingenic,lcd.txt to a new ingenic,lcd.yaml file.

In the process, the new ingenic,jz4780-lcd compatible string has been
added.

Signed-off-by: Paul Cercueil 
---

Notes:
This patch comes from a different patchset so it's effectively a V2.

Changes were:
- lcd_pclk and lcd clocks are in the correct order now,
- Add 'port' and 'ports' properties, and document the valid ports.

 .../bindings/display/ingenic,lcd.txt  |  45 ---
 .../bindings/display/ingenic,lcd.yaml | 126 ++
 2 files changed, 126 insertions(+), 45 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.txt
 create mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.yaml

diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.txt 
b/Documentation/devicetree/bindings/display/ingenic,lcd.txt
deleted file mode 100644
index 01e3261defb6..
--- a/Documentation/devicetree/bindings/display/ingenic,lcd.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Ingenic JZ47xx LCD driver
-
-Required properties:
-- compatible: one of:
-  * ingenic,jz4740-lcd
-  * ingenic,jz4725b-lcd
-  * ingenic,jz4770-lcd
-- reg: LCD registers location and length
-- clocks: LCD pixclock and device clock specifiers.
-  The device clock is only required on the JZ4740.
-- clock-names: "lcd_pclk" and "lcd"
-- interrupts: Specifies the interrupt line the LCD controller is connected to.
-
-Example:
-
-panel {
-   compatible = "sharp,ls020b1dd01d";
-
-   backlight = <>;
-   power-supply = <>;
-
-   port {
-   panel_input: endpoint {
-   remote-endpoint = <_output>;
-   };
-   };
-};
-
-
-lcd: lcd-controller@1305 {
-   compatible = "ingenic,jz4725b-lcd";
-   reg = <0x1305 0x1000>;
-
-   interrupt-parent = <>;
-   interrupts = <31>;
-
-   clocks = < JZ4725B_CLK_LCD>;
-   clock-names = "lcd";
-
-   port {
-   panel_output: endpoint {
-   remote-endpoint = <_input>;
-   };
-   };
-};
diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml 
b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
new file mode 100644
index ..d56db1802fad
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic,lcd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ingenic SoCs LCD controller devicetree bindings
+
+maintainers:
+  - Paul Cercueil 
+
+properties:
+  $nodename:
+pattern: "^lcd-controller@[0-9a-f]+$"
+
+  compatible:
+enum:
+  - ingenic,jz4740-lcd
+  - ingenic,jz4725b-lcd
+  - ingenic,jz4770-lcd
+  - ingenic,jz4780-lcd
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Pixel clock
+  - description: Module clock
+minItems: 1
+
+  clock-names:
+items:
+  - const: lcd_pclk
+  - const: lcd
+minItems: 1
+
+  port:
+description: OF graph bindings (specified in bindings/graph.txt).
+
+  ports:
+description: OF graph bindings (specified in bindings/graph.txt).
+type: object
+properties:
+  port@0:
+type: object
+description: DPI output, to interface with TFT panels.
+
+  port@8:
+type: object
+description: Link to the Image Processing Unit (IPU).
+  (See ingenic,ipu.yaml).
+
+required:
+  - port@0
+
+required:
+- compatible
+- reg
+- interrupts
+- clocks
+- clock-names
+
+if:
+  properties:
+compatible:
+  contains:
+enum:
+  - ingenic,jz4740-lcd
+  - ingenic,jz4780-lcd
+then:
+  properties:
+clocks:
+  minItems: 2
+clock-names:
+  minItems: 2
+else:
+  properties:
+clocks:
+  maxItems: 1
+clock-names:
+  maxItems: 1
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+lcd-controller@1305 {
+  compatible = "ingenic,jz4740-lcd";
+  reg = <0x1305 0x1000>;
+
+  interrupt-parent = <>;
+  interrupts = <30>;
+
+  clocks = < JZ4740_CLK_LCD_PCLK>, < JZ4740_CLK_LCD>;
+  clock-names = "lcd_pclk", "lcd";
+
+  port {
+endpoint {
+  remote-endpoint = <_input>;
+};
+  };
+};
+
+  - |
+#include 
+lcd-controller@1305 {
+  compatible = "ingenic,jz4725b-lcd";
+  reg = <0x1305 0x1000>;
+
+  interrupt-parent = <>;
+  interrupts = <31>;
+
+  clocks = < JZ4725B_CLK_LCD>;
+  clock-names = "lcd_pclk";
+
+  port {
+endpoint {
+  remote-endpoint = <_input>;
+};
+  };
+};
-- 
2.26.2

[PATCH 02/12] dt-bindings: display: Add ingenic,ipu.yaml

Add documentation of the Device Tree bindings for the Image Processing
Unit (IPU) found in most Ingenic SoCs.

Signed-off-by: Paul Cercueil 
---
 .../bindings/display/ingenic,ipu.yaml | 65 +++
 1 file changed, 65 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ingenic,ipu.yaml

diff --git a/Documentation/devicetree/bindings/display/ingenic,ipu.yaml 
b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml
new file mode 100644
index ..22fe02ca866d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic,ipu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ingenic SoCs Image Processing Unit (IPU) devicetree bindings
+
+maintainers:
+  - Paul Cercueil 
+
+properties:
+  compatible:
+oneOf:
+  - enum:
+- ingenic,jz4725b-ipu
+- ingenic,jz4760-ipu
+  - items:
+- ingenic,jz4770-ipu
+- ingenic,jz4760-ipu
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: ipu
+
+patternProperties:
+  "^ports?$":
+description: OF graph bindings (specified in bindings/graph.txt).
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+ipu@1308 {
+  compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu";
+  reg = <0x1308 0x800>;
+
+  interrupt-parent = <>;
+  interrupts = <29>;
+
+  clocks = < JZ4770_CLK_IPU>;
+  clock-names = "ipu";
+
+  port {
+ipu_ep: endpoint {
+  remote-endpoint = <_ep>;
+};
+  };
+};
-- 
2.26.2

[PATCH] dmaengine: tegra210-adma: Fix an error handling path in 'tegra_adma_probe()'

2020-05-16 Thread Christophe JAILLET

Commit b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe")
has moved some code in the probe function and reordered the error handling
path accordingly.
However, a goto has been missed.

Fix it and goto the right label if 'dma_async_device_register()' fails, so
that all resources are released.

Fixes: b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe")
Signed-off-by: Christophe JAILLET 
---
 drivers/dma/tegra210-adma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index c4ce5dfb149b..db58d7e4f9fe 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -900,7 +900,7 @@ static int tegra_adma_probe(struct platform_device *pdev)
ret = dma_async_device_register(>dma_dev);
if (ret < 0) {
dev_err(>dev, "ADMA registration failed: %d\n", ret);
-   goto irq_dispose;
+   goto rpm_put;
}
 
ret = of_dma_controller_register(pdev->dev.of_node,
-- 
2.25.1

Re: [RFC PATCH 3/8] qaic: Create char dev

2020-05-16 Thread Jeffrey Hugo


On 5/16/2020 1:01 AM, Greg KH wrote:

On Fri, May 15, 2020 at 03:08:59PM -0600, Jeffrey Hugo wrote:

2. There are a limited number of dynamic minor numbers for misc devs (64),
so if you are expecting more devices than that, a misc dev is not
appropiate.  Also, these minors are shared with other misc dev users, so
depending on the system configuration, you might have significantly less
than 64 minors available for use.


I'm pretty sure we can have more than 64 misc devices, that limitation
should have been removed a while ago.  Try it and see :)


In total, there can be more tha 64 misc devices.  However my previous 
comment was specific to dynamic minors (ie devices which do not have an 
assigned minor).  The limit on dynamic minors still apears to be 64. 
Looking at the code -


DYNAMIC_MINORS is still 64
https://elixir.bootlin.com/linux/v5.7-rc5/source/drivers/char/misc.c#L63

I see the same in -next

DYNAMIC_MINORS is used to size a bitmap - one bit for each dynamic minor 
misc device that exists at one particular point in time.  After all 64 
bits are consumed by misc_register() by clients requesting a dynamic 
minor, no more dynamic minor misc devices can be registered until some 
are unregistered.


What am I missing?

--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: KASAN: use-after-free Write in hci_sock_release

2020-05-16 Thread syzbot

syzbot suspects this bug was fixed by commit:

commit f1e67e355c2aafeddf1eac31335709236996d2fe
Author: Thomas Gleixner 
Date:   Mon Nov 18 13:28:24 2019 +

fs/buffer: Make BH_Uptodate_Lock bit_spin_lock a regular spinlock_t

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1761ce0610
start commit:   645ff1e8 Merge branch 'for-linus' of git://git.kernel.org/..
git tree:   upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=7308e68273924137
dashboard link: https://syzkaller.appspot.com/bug?extid=b364ed862aa07c74bc62
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=152532bb40
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13f73320c0

If the result looks correct, please mark the bug fixed by replying with:

#syz fix: fs/buffer: Make BH_Uptodate_Lock bit_spin_lock a regular spinlock_t

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [PATCH 1/1] Documentation: security: core.rst: add missing argument

2020-05-16 Thread Jarkko Sakkinen

On Fri, 2020-05-15 at 20:39 -0400, Ben Boeckel wrote:
> From: Ben Boeckel 
> 
> This argument was just never documented in the first place.
> 
> Signed-off-by: Ben Boeckel 

Reviewed-by: Jarkko Sakkinen 

/Jarkko

undefined reference to `start_isolate_page_range'

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   3d1c1e5931ce45b3a3f309385bbc00c78e9951c6
commit: 2602276d3d3811b1a48c48113042cd75fcbfc27d microblaze: Wire CMA allocator
date:   3 months ago
config: microblaze-randconfig-r036-20200517 (attached as .config)
compiler: microblaze-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
git checkout 2602276d3d3811b1a48c48113042cd75fcbfc27d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross 
ARCH=microblaze 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

microblaze-linux-ld: mm/page_alloc.o: in function `alloc_contig_range':
>> (.text+0x9b58): undefined reference to `start_isolate_page_range'
>> microblaze-linux-ld: (.text+0x9c98): undefined reference to 
>> `test_pages_isolated'
>> microblaze-linux-ld: (.text+0x9cdc): undefined reference to 
>> `undo_isolate_page_range'

---
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 19/19] dt-bindings: spi: Convert DW SPI binding to DT schema

2020-05-16 Thread Serge Semin

Rob,
Could you take a look at this patch? We are getting closer to merging the series
into the spi/for-next branch and then to the kernel 5.8. It would be great to
have the bindings converted by the next merge window.

-Sergey

On Fri, May 15, 2020 at 01:47:58PM +0300, Serge Semin wrote:
> Modern device tree bindings are supposed to be created as YAML-files
> in accordance with dt-schema. This commit replaces two DW SPI legacy
> bare text bindings with YAML file. As before the bindings file states
> that the corresponding dts node is supposed to be compatible either
> with generic DW APB SSI controller or with Microsemi/Amazon/Renesas/Intel
> vendors-specific controllers, to have registers, interrupts and clocks
> properties. Though in case of Microsemi version of the controller
> there must be two registers resources specified. Properties like
> clock-names, reg-io-width, cs-gpio, num-cs, DMA and slave device
> sub-nodes are optional.

[nip]

Re: [PATCH 4/4] ipv6: symbol_get to access a sit symbol

From: Christoph Hellwig 
Date: Fri, 15 May 2020 08:33:24 +0200

> My initial plan was to add a ->tunnel_ctl method to the net_device_ops,
> and lift the copy_{to,from}_user for SIOCADDTUNNEL, SIOCCHGTUNNEL,
> SIOCDELTUNNEL and maybe SIOCGETTUNNEL to net/socket.c.  But that turned
> out to have two problems:
> 
>  - first these ioctls names use SIOCDEVPRIVATE range, that can also
>be implemented by other drivers
>  - the ip_tunnel_parm struture is only used by the ipv4 tunneling
>drivers (including sit), the "real" ipv6 tunnels use a
>ip6_tnl_parm or ip6_tnl_parm structure instead

Yes, this is the core of the problem, the user provided data's type
is unknown until we are very deep in the call chains.

I wonder if there is some clever way to propagate this size value
"up"?

Re: [PATCH] net: mscc: ocelot: replace readx_poll_timeout with readx_poll_timeout_atomic

From: Xulin Sun 
Date: Fri, 15 May 2020 11:18:13 +0800

> BUG: sleeping function called from invalid context at 
> drivers/net/ethernet/mscc/ocelot.c:59
> in_atomic(): 1, irqs_disabled(): 0, pid: 3778, name: ifconfig
> INFO: lockdep is turned off.
> Preemption disabled at:
> [] dev_set_rx_mode+0x24/0x40
> Hardware name: LS1028A RDB Board (DT)
> Call trace:
> dump_backtrace+0x0/0x140
> show_stack+0x24/0x30
> dump_stack+0xc4/0x10c
> ___might_sleep+0x194/0x230
> __might_sleep+0x58/0x90
> ocelot_mact_forget+0x74/0xf8
> ocelot_mc_unsync+0x2c/0x38
> __hw_addr_sync_dev+0x6c/0x130
> ocelot_set_rx_mode+0x8c/0xa0

Vladimir states that this call chain is not possible in mainline.

I'm not applying this.

Re: [PATCH net v2] ipv6: Fix suspicious RCU usage warning in ip6mr

From: madhuparnabhowmi...@gmail.com
Date: Sat, 16 May 2020 13:15:15 +0530

> From: Madhuparna Bhowmik 
> 
> This patch fixes the following warning:
> 
> =
> WARNING: suspicious RCU usage
> 5.7.0-rc4-next-20200507-syzkaller #0 Not tainted
> -
> net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!!
> 
> ipmr_new_table() returns an existing table, but there is no table at
> init. Therefore the condition: either holding rtnl or the list is empty
> is used.
> 
> Fixes: d1db275dd3f6e ("ipv6: ip6mr: support multiple tables")
> Reported-by: kernel test robot 
> Suggested-by: Jakub Kicinski 
> Signed-off-by: Madhuparna Bhowmik 

Applied and queued up for -stable, thanks.

Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec_page

From: Shakeel Butt 
Date: Fri, 15 May 2020 19:17:36 -0700

> and thus there is no need to have any fallback after vzalloc.

This statement is false.

The virtual mapping allocation or the page table allocations can fail.

A fallback is therefore indeed necessary.

Re: [PATCH net-next v1] hinic: add set_channels ethtool_ops support

From: Luo bin 
Date: Fri, 15 May 2020 19:42:12 +

> add support to change TX/RX queue number with ethtool -L
> 
> Signed-off-by: Luo bin 

I don't think you are properly following the semantics of this
ethtool command with your changes.

In fact, you are breaking the hinic_get_channels() function which
is properly advertising the ->max_* values currently.  Now it will
return zero.

Whatever is advertised in ->max_* should be the driver's maximum
capabilities.

This means that the user can request anything in the range from '1'
to these max values.

Whatever the user asks for in ->combined_count and elsewhere, you
_MUST_ provide or return an error.

That is not what hinic_set_channels() is doing.  It is using
combined_count as a "limit" rather than the value to use.

Re: [GIT PULL] io_uring fixes for 5.7-rc6

The pull request you sent on Fri, 15 May 2020 22:48:47 -0600:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.7-2020-05-15

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/18e70f3a7651b420bf5d8ce0a3fd3d1cd9e5b689

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] Pin control fixes for the v5.7 series

The pull request you sent on Sat, 16 May 2020 11:16:21 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git 
> tags/pinctrl-v5.7-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cf0ca701a01cf631333855831fe48b717ed1f20b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH] arm64: Call debug_traps_init() from trap_init() to help early kgdb

2020-05-16 Thread Daniel Thompson

On Fri, May 15, 2020 at 05:23:17PM +0100, Will Deacon wrote:
> On Wed, May 13, 2020 at 04:06:37PM -0700, Douglas Anderson wrote:
> > A new kgdb feature will soon land (kgdb_earlycon) that lets us run
> > kgdb much earlier.  In order for everything to work properly it's
> > important that the break hook is setup by the time we process
> > "kgdbwait".
> > 
> > Right now the break hook is setup in debug_traps_init() and that's
> > called from arch_initcall().  That's a bit too late since
> > kgdb_earlycon really needs things to be setup by the time the system
> > calls dbg_late_init().
> > 
> > We could fix this by adding call_break_hook() into early_brk64() and
> > that works fine.  However, it's a little ugly.  Instead, let's just
> > add a call to debug_traps_init() straight from trap_init().  There's
> > already a documented dependency between trap_init() and
> > debug_traps_init() and this makes the dependency more obvious rather
> > than just relying on a comment.
> > 
> > NOTE: this solution isn't early enough to let us select the
> > "ARCH_HAS_EARLY_DEBUG" KConfig option that is introduced by the
> > kgdb_earlycon patch series.  That would only be set if we could do
> > breakpoints when early params are parsed.  This patch only enables
> > "late early" breakpoints, AKA breakpoints when dbg_late_init() is
> > called.  It's expected that this should be fine for most people.
> > 
> > It should also be noted that if you crash you can still end up in kgdb
> > earlier than debug_traps_init().  Since you don't need breakpoints to
> > debug a crash that's fine.
> > 
> > Suggested-by: Will Deacon 
> > Signed-off-by: Douglas Anderson 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > ---
> > This replaces the patch ("arm64: Add call_break_hook() to
> > early_brk64() for early kgdb") in my recent kgdb series [1].  If I end
> > up re-posting that series again I'll include this patch as a
> > replacement, but I'm sending it separately to avoid spamming a pile of
> > people another time with a 12-patch series.
> > 
> > Note that, because it doesn't select the "ARCH_HAS_EARLY_DEBUG"
> > KConfig option it could be landed standalone.  However, it's still
> > probably better to land together with that patch series.
> > 
> > If the kgdb_earlycon patch series lands without this patch then
> > kgdbwait + kgdb_earlycon won't work well on arm64, but there would be
> > no other bad side effects.
> > 
> > If this patch lands without the kgdb_earlycon patch series then there
> > will be no known problems.
> > 
> > [1] 
> > https://lore.kernel.org/r/20200507130644.v4.5.I22067ad43e77ddfd4b64c2d49030628480f9e8d9@changeid
> > 
> >  arch/arm64/include/asm/debug-monitors.h | 2 ++
> >  arch/arm64/kernel/debug-monitors.c  | 4 +---
> >  arch/arm64/kernel/traps.c   | 2 +-
> >  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> [...]
> 
> Acked-by: Will Deacon 
> 
> I would prefer to take this via arm64, if possible, since we have quite lot
> going in for 5.8, although I don't think this conflicts at the moment.
> 
> Daniel -- what do you want to do?

I'm very happy for you to take it!

On my side I hope to get the rest of the patchset into linux-next early
next week.


Daniel.

Re: [PATCH] drivers: block: use set_current_state macro

2020-05-16 Thread Jens Axboe

On 5/7/20 1:12 AM, Xu Wang wrote:
> Use set_current_state macro instead of current->state = TASK_RUNNING.

Applied, thanks.

-- 
Jens Axboe

Re: [PATCH net-next] hinic: add support to set and get pause param