Re: [PATCH] zsmalloc: do not use bit_spin_lock

[Mike Galbraith]

On Sun, 2020-12-20 at 02:23 +0100, Mike Galbraith wrote:
> On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote:
> > zsmalloc takes bit spinlock in its _map() callback and releases it
> > only in unmap() which is unsafe and leads to zswap complaining
> > about scheduling in atomic context.
> >
> > To fix that and to improve RT properties of zsmalloc, remove that
> > bit spinlock completely and use a bit flag instead.
>
> It also does get_cpu_var() in map(), put_cpu_var() in unmap().

That aside, the bit spinlock removal seems to hold up to beating in RT.
I stripped out the RT changes to replace the bit spinlocks, applied the
still needed atm might_sleep() fix, and ltp zram and zswap test are
running in a loop with no signs that it's a bad idea, so I hope that
makes it in (minus the preempt disabled spin which I whacked), as it
makes zsmalloc markedly more RT friendly.

RT changes go from:
 1 file changed, 79 insertions(+), 6 deletions(-)
to:
 1 file changed, 8 insertions(+), 3 deletions(-)

-Mike

[PATCH] signal: Don't init struct kernel_siginfo fields to zero again

[Leesoo Ahn]

clear_siginfo() is responsible for clearing struct kernel_siginfo object.
It's obvious that manually initializing those fields is needless as
a commit[1] explains why the function introduced and its guarantee that
all bits in the struct are cleared after it.

[1]: commit 8c5dbf2ae00b ("signal: Introduce clear_siginfo")

Signed-off-by: Leesoo Ahn 
---
 kernel/signal.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 5736c55aaa1a..8f49fa3ade33 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -603,10 +603,7 @@ static void collect_signal(int sig, struct sigpending 
*list, kernel_siginfo_t *i
 */
clear_siginfo(info);
info->si_signo = sig;
-   info->si_errno = 0;
info->si_code = SI_USER;
-   info->si_pid = 0;
-   info->si_uid = 0;
}
 }
 
@@ -1120,7 +1117,6 @@ static int __send_signal(int sig, struct kernel_siginfo 
*info, struct task_struc
case (unsigned long) SEND_SIG_NOINFO:
clear_siginfo(>info);
q->info.si_signo = sig;
-   q->info.si_errno = 0;
q->info.si_code = SI_USER;
q->info.si_pid = task_tgid_nr_ns(current,
task_active_pid_ns(t));
@@ -1133,10 +1129,7 @@ static int __send_signal(int sig, struct kernel_siginfo 
*info, struct task_struc
case (unsigned long) SEND_SIG_PRIV:
clear_siginfo(>info);
q->info.si_signo = sig;
-   q->info.si_errno = 0;
q->info.si_code = SI_KERNEL;
-   q->info.si_pid = 0;
-   q->info.si_uid = 0;
break;
default:
copy_siginfo(>info, info);
@@ -1623,10 +1616,7 @@ void force_sig(int sig)
 
clear_siginfo();
info.si_signo = sig;
-   info.si_errno = 0;
info.si_code = SI_KERNEL;
-   info.si_pid = 0;
-   info.si_uid = 0;
force_sig_info();
 }
 EXPORT_SYMBOL(force_sig);
@@ -1659,7 +1649,6 @@ int force_sig_fault_to_task(int sig, int code, void 
__user *addr
 
clear_siginfo();
info.si_signo = sig;
-   info.si_errno = 0;
info.si_code  = code;
info.si_addr  = addr;
 #ifdef __ARCH_SI_TRAPNO
@@ -1691,7 +1680,6 @@ int send_sig_fault(int sig, int code, void __user *addr
 
clear_siginfo();
info.si_signo = sig;
-   info.si_errno = 0;
info.si_code  = code;
info.si_addr  = addr;
 #ifdef __ARCH_SI_TRAPNO
@@ -1712,7 +1700,6 @@ int force_sig_mceerr(int code, void __user *addr, short 
lsb)
WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
clear_siginfo();
info.si_signo = SIGBUS;
-   info.si_errno = 0;
info.si_code = code;
info.si_addr = addr;
info.si_addr_lsb = lsb;
@@ -1726,7 +1713,6 @@ int send_sig_mceerr(int code, void __user *addr, short 
lsb, struct task_struct *
WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
clear_siginfo();
info.si_signo = SIGBUS;
-   info.si_errno = 0;
info.si_code = code;
info.si_addr = addr;
info.si_addr_lsb = lsb;
@@ -1740,7 +1726,6 @@ int force_sig_bnderr(void __user *addr, void __user 
*lower, void __user *upper)
 
clear_siginfo();
info.si_signo = SIGSEGV;
-   info.si_errno = 0;
info.si_code  = SEGV_BNDERR;
info.si_addr  = addr;
info.si_lower = lower;
@@ -1755,7 +1740,6 @@ int force_sig_pkuerr(void __user *addr, u32 pkey)
 
clear_siginfo();
info.si_signo = SIGSEGV;
-   info.si_errno = 0;
info.si_code  = SEGV_PKUERR;
info.si_addr  = addr;
info.si_pkey  = pkey;
@@ -1934,7 +1918,6 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
 
clear_siginfo();
info.si_signo = sig;
-   info.si_errno = 0;
/*
 * We are under tasklist_lock here so our parent is tied to
 * us and cannot change.
@@ -2033,7 +2016,6 @@ static void do_notify_parent_cldstop(struct task_struct 
*tsk,
 
clear_siginfo();
info.si_signo = SIGCHLD;
-   info.si_errno = 0;
/*
 * see comment in do_notify_parent() about the following 4 lines
 */
@@ -2506,7 +2488,6 @@ static int ptrace_signal(int signr, kernel_siginfo_t 
*info)
if (signr != info->si_signo) {
clear_siginfo(info);
info->si_signo = signr;
-   info->si_errno = 0;
info->si_code = SI_USER;
rcu_read_lock();
info->si_pid = task_pid_vnr(current->parent);
@@ -3660,7 +3641,6 @@ static inline void prepare_kill_siginfo(int sig, struct 
kernel_siginfo *info)
 {
clear_siginfo(info);

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Romain Dolbeau]

Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg  a écrit :
> Another said that it would be a shame to sunset sun4m and sun4d because
> there are so many machines around, and netbsd is also active on the
> sparc32 area.

Yes, those were plentiful back in the day and there's still quite a few around.

> The second mail also re-reminded me of an interesting project
> implementing SPARC V8 and the sun4m platform in VHDL.

There's also new hardware being developed for SBus systems :-)

(disclaimer: work-in-progress and shameless self-promotion here!).

If there's still a distribution willing to build for Sparc v8, then I
believe the kernel
should try to keep support of the relevant machine architectures if at all
possible...

Cordially,

-- 
Romain Dolbeau

HELP! I can't get my Cisco CP-7960G IP hardphone to register on my Asterisk VoIP IP PBX SIP Server with FreePBX GUI

[Turritopsis Dohrnii Teo En Ming]

Subject: HELP! I can't get my Cisco CP-7960G IP hardphone to register on 
my Asterisk VoIP IP PBX SIP Server with FreePBX GUI


Good day from Singapore,

My Asterisk version: 16.13.0
My FreePBX version: 15.0.16.81

On 7 December 2020, I was able to get Bria softphone to work with my 
Asterisk PBX server successfully.


On 19 December 2020, I bought a refurbished Cisco CP-7960G IP hardphone 
for SGD$30 in Singapore. I have tried all of the following steps, but I 
simply can't get my Cisco CP-7960G IP phone to register on my Asterisk 
PBX server.


TFTP works though. My DHCP server in my pfSense firewall applaince is 
able to assign my Cisco 7960 IP phone with an IP address with DHCP 
option 66 (TFTP server). My Cisco 7960 IP phone is able to connect to my 
TFTP server on my Asterisk PBX appliance and download firmware and 
configuration files successfully. However, it simply cannot register on 
my Asterisk PBX server.


You can watch my Youtube video at

https://www.youtube.com/watch?v=ip_F08jmmio

Appreciate your kind assistance.

Thank you very much.

STEPS I HAVE TRIED
===

Reference Guide: Configure Asterisk with Cisco IP Phones
Link: http://docshare02.docshare.tips/files/6706/67061980.pdf

SECTION: INSTALLING TFTP SERVER ON ASTERISK PBX APPLIANCE
=

Putty/ssh into Teo En Ming's Asterisk VoIP IP PBX SIP Server at 
192.168.1.9.


# yum install tftp-server

Package tftp-server-5.2-23.8.sng7.x86_64 already installed and latest 
version


# chkconfig xinetd on

# chkconfig tftp on

# systemctl start tftp.service

# ps -ef | grep tftp
root  3424 1  0 11:17 ?00:00:00 /usr/sbin/in.tftpd -s 
/tftpboot


SECTION: DOWNLOADING CISCO 7960 IP PHONE SIP FIRMWARE
==

# cd /tftpboot

# wget 
http://www.firewall.cx/downloads/cisco-tools-a-applications/cisco-ip-phone-a-ata-firmware-downloads/107-7940-a-7960-ip-phone-sccp-a-sip/file.html


# mv file.html file.zip

# unzip file.zip

# cd 7940_7960/

# cd SIP/

# tar -xf P0S3-8-12-00.tar

# rm P0S3-8-12-00.tar

# mv * /tftpboot/

# cd /tftpboot/

[root@freepbx tftpboot]# ls
7940_7960  file.zip  OS79XX.TXT  P003-8-12-00.bin  P003-8-12-00.sbn  
P0S3-8-12-00.loads  P0S3-8-12-00.sb2


SECTION: CREATING CISCO 7960 IP PHONE CONFIGURATION FILES
==

# nano OS79XX.TXT (Create configuration file)
=

P003-8-12-00

# nano XMLDefault.cnf.xml (Create configuration file)
=



 
 
 
 
 2000
 
 2427
 2428
 
 
 
 
 
 
 
P0S3-8-12-00
P0S3-8-12-00
SIP45.8-4-2S
SIP45.8-4-2S
SIP70.8-0-3S









# nano SIPDefault.cnf (Create configuration file)
=

image_version: "P0S3-8-12-00"
proxy1_address: "192.168.1.9"
# proxy2_address: "xxx.xxx.xxx.xxx"
# proxy3_address: "xxx.xxx.xxx.xxx"
# proxy4_address: "xxx.xxx.xxx.xxx"

# Proxy Server Port
proxy1_port:"5060"
# proxy2_port:"5060"
# proxy3_port:"5060"
# proxy4_port:"5060"
proxy_emergency: ""
proxy_emergency_port: "5060"
proxy_backup: ""
proxy_backup_port: "5060"
outbound_proxy: ""
outbound_proxy_port: "5060"

nat_enable: "0"
nat_address: ""
voip_control_port: "5060"
start_media_port: "16348"
end_media_port: "20134"
nat_received_processing: "1"
dyn_dns_addr_1: ""
dyn_dns_addr_2: ""
dyn_tftp_addr: "192.168.1.9"
tftp_cfg_dir: "./"
proxy_register: "1"
timer_register_expires: "120"
preferred_codec: "none"
tos_media: "5"
enable_vad: "0"
dial_template: "dialplan"
network_media_type: "auto"
autocomplete: "1"
telnet_level: "2"
cnf_join_enable: "1"
semi_attended_transfer: "0"
call_waiting: "1"
anonymous_call_block: "0"
callerid_blocking: "0"
dnd_control: "0"
dtmf_inband: "1"
dtmf_outofband: "avt"
dtmf_db_level: "3"
dtmf_avt_payload: "101"
timer_t1: "500"
timer_t2: "4000"
sip_retx: "10"
sip_invite_retx: "6"
timer_invite_expires: "180"

sntp_mode: "directedbroadcast"
sntp_server: "time-a-g.nist.gov"
time_zone: "8"
time_format_24hr: "0"
dst_offset: "0"
dst_start_month: "April"
dst_start_day: ""
dst_start_day_of_week: "Sun"
dst_start_week_of_month: "1"
dst_start_time: "2"
dst_stop_month: "Nov"
dst_stop_day: "1"

dst_stop_day_of_week: "Sunday"
dst_stop_week_of_month: ""
dst_stop_time: "2"
dst_auto_adjust: "1"

messages_uri: "*99"
services_url: "http://example.domain.ext/services/menu.xml;
directory_url: "http://example.domain.ext/services/directory.php;
logo_url: "http://example.domain.ext/imagename.bmp;
http_proxy_addr: ""
http_proxy_port: ""
remote_party_id: 0

# nano dialplan.xml (Create configuration file)
===


  


# nano RINGLIST.DAT (Create configuration file)
===

FlintPhone FlintPhone.raw
HarpSynth HarpSynth.raw
Jamaica Jamaica.raw
Klaxons Klaxons.raw
KotoEffect KotoEffect.raw
MusicBox MusicBox.raw
Ohno Ohno.raw
Piano 1 Piano1.raw
Piano 

Re: [PATCH] zsmalloc: do not use bit_spin_lock

[Vitaly Wool]

On Sun, Dec 20, 2020 at 2:18 AM Matthew Wilcox  wrote:
>
> On Sun, Dec 20, 2020 at 02:22:28AM +0200, Vitaly Wool wrote:
> > zsmalloc takes bit spinlock in its _map() callback and releases it
> > only in unmap() which is unsafe and leads to zswap complaining
> > about scheduling in atomic context.
> >
> > To fix that and to improve RT properties of zsmalloc, remove that
> > bit spinlock completely and use a bit flag instead.
>
> Isn't this just "I open coded bit spinlock to make the lockdep
> warnings go away"?

Not really because bit spinlock leaves preemption disabled.

[PATCH] ide: pci: Fix memleak in ide_pci_init_two

[Dinghao Liu]

When do_ide_setup_pci_device() fails, host allocated
by ide_host_alloc() may not have been freed, which
leads to memleak.

Signed-off-by: Dinghao Liu 
---
 drivers/ide/setup-pci.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/ide/setup-pci.c b/drivers/ide/setup-pci.c
index fdc8e813170c..c7da5368fcd4 100644
--- a/drivers/ide/setup-pci.c
+++ b/drivers/ide/setup-pci.c
@@ -586,7 +586,7 @@ int ide_pci_init_two(struct pci_dev *dev1, struct pci_dev 
*dev2,
 * do_ide_setup_pci_device() on the first device!
 */
if (ret < 0)
-   goto out_free_bars;
+   goto out_free_host;
 
/* fixup IRQ */
if (ide_pci_is_in_compatibility_mode(pdev[i])) {
@@ -597,11 +597,11 @@ int ide_pci_init_two(struct pci_dev *dev1, struct pci_dev 
*dev2,
}
 
ret = ide_host_register(host, d, hws);
-   if (ret)
-   ide_host_free(host);
-   else
+   if (!ret)
goto out;
 
+out_free_host:
+   ide_host_free(host);
 out_free_bars:
i = n_ports / 2;
while (i--)
-- 
2.17.1

Re: [PATCH v3 5/6] i2c: iproc: handle master read request

[Rayagonda Kokatanur]

On Fri, Dec 18, 2020 at 12:41 AM Ray Jui  wrote:
>
>
>
> On 12/16/2020 8:08 PM, Rayagonda Kokatanur wrote:
> > On Wed, Dec 2, 2020 at 11:14 PM Ray Jui  wrote:
> >>
> >>
> >>
> >> On 12/2/2020 6:35 AM, Wolfram Sang wrote:
> >>>
>  All review comments are scattered now, please let me know what has to be
>  done further,
>  Are we going to change the tasklet to irq thread ?
>  Are we going to remove batching 64 packets if transaction > 64B and use 
>  rx
>  fifo threshold ?
> 
>  I don't see any issue with current code but if it has to change we need a
>  valid reason for the same.
>  If nothing to be done, please acknowledge the patch.
> >>>
> >>> Valid request. Has there been any news?
> >>>
> >>
> >> Sorry for the delay. I just replied.
> >
> > This patch is tested and validated with all corner cases and its working.
> > Can we merge this and take up any improvement as part of separate patch?
> >
>
> I think that makes sense, and I'm okay with these patches going in as
> they are now.
>
> Acked-by: Ray Jui 

Thank you.

>
> But please help to collect precise FIFO access timing (later when you
> have time), that would allow us to know if the current defer-to-tasklet
> (instead of thread) based approach makes sense or not.
>
> Thanks,
>
> Ray
>
> > Thanks,
> > Rayagonda
> >
> >>
> >>
> >> Thanks,
> >>
> >> Ray

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH] fs: io_uring.c: Add skip option for __io_sqe_files_update

[noah]

From: noah 

This patch makes it so that specify a file descriptor value of -2 will
skip updating the corresponding fixed file index.

This will allow for users to reduce the number of syscalls necessary
to update a sparse file range when using the fixed file option.

Signed-off-by: noah 
---
 fs/io_uring.c | 72 ++-
 1 file changed, 37 insertions(+), 35 deletions(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 6f9392c35eef..43ab2b7a87d4 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -7876,42 +7876,44 @@ static int __io_sqe_files_update(struct io_ring_ctx 
*ctx,
err = -EFAULT;
break;
}
-   i = array_index_nospec(up->offset, ctx->nr_user_files);
-   table = >file_data->table[i >> IORING_FILE_TABLE_SHIFT];
-   index = i & IORING_FILE_TABLE_MASK;
-   if (table->files[index]) {
-   file = table->files[index];
-   err = io_queue_file_removal(data, file);
-   if (err)
-   break;
-   table->files[index] = NULL;
-   needs_switch = true;
-   }
-   if (fd != -1) {
-   file = fget(fd);
-   if (!file) {
-   err = -EBADF;
-   break;
-   }
-   /*
-* Don't allow io_uring instances to be registered. If
-* UNIX isn't enabled, then this causes a reference
-* cycle and this instance can never get freed. If UNIX
-* is enabled we'll handle it just fine, but there's
-* still no point in allowing a ring fd as it doesn't
-* support regular read/write anyway.
-*/
-   if (file->f_op == _uring_fops) {
-   fput(file);
-   err = -EBADF;
-   break;
-   }
-   table->files[index] = file;
-   err = io_sqe_file_register(ctx, file, i);
-   if (err) {
+   if (fd != -2) {
+   i = array_index_nospec(up->offset, ctx->nr_user_files);
+   table = >file_data->table[i >> 
IORING_FILE_TABLE_SHIFT];
+   index = i & IORING_FILE_TABLE_MASK;
+   if (table->files[index]) {
+   file = table->files[index];
+   err = io_queue_file_removal(data, file);
+   if (err)
+   break;
table->files[index] = NULL;
-   fput(file);
-   break;
+   needs_switch = true;
+   }
+   if (fd != -1) {
+   file = fget(fd);
+   if (!file) {
+   err = -EBADF;
+   break;
+   }
+   /*
+* Don't allow io_uring instances to be 
registered. If
+* UNIX isn't enabled, then this causes a 
reference
+* cycle and this instance can never get freed. 
If UNIX
+* is enabled we'll handle it just fine, but 
there's
+* still no point in allowing a ring fd as it 
doesn't
+* support regular read/write anyway.
+*/
+   if (file->f_op == _uring_fops) {
+   fput(file);
+   err = -EBADF;
+   break;
+   }
+   table->files[index] = file;
+   err = io_sqe_file_register(ctx, file, i);
+   if (err) {
+   table->files[index] = NULL;
+   fput(file);
+   break;
+   }
}
}
nr_args--;
-- 
2.29.2

Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end

[Mike Rapoport]

On Thu, Dec 17, 2020 at 12:12:14PM -0800, Roman Gushchin wrote:
> With kaslr the kernel image is placed at a random place, so starting
> the bottom-up allocation with the kernel_end can result in an
> allocation failure and a warning like this one:
> 
> [0.002920] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
> [0.002921] [ cut here ]
> [0.002922] memblock: bottom-up allocation failed, memory hotremove may be 
> affected
> [0.002937] WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 
> memblock_find_in_range_node+0x178/0x25a
> [0.002937] Modules linked in:
> [0.002939] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #1169
> [0.002940] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.14.0-1.fc33 04/01/2014
> [0.002942] RIP: 0010:memblock_find_in_range_node+0x178/0x25a
> [0.002944] Code: e9 6d ff ff ff 48 85 c0 0f 85 da 00 00 00 80 3d 9b 35 df 
> 00 00 75 15 48 c7 c7 c0 75 59 88 c6 05 8b 35 df 00 01 e8 25 8a fa ff <0f> 0b 
> 48 c7 44 24 20 ff ff ff ff 44 89 e6 44 89 ea 48 c7 c1 70 5c
> [0.002945] RSP: :88803d18 EFLAGS: 00010086 ORIG_RAX: 
> 
> [0.002947] RAX:  RBX: 00024000 RCX: 
> dfff
> [0.002948] RDX: dfff RSI: ffea RDI: 
> 0046
> [0.002948] RBP: 0001 R08: 88922788 R09: 
> 9ffb
> [0.002949] R10: e000 R11: 3fff R12: 
> 
> [0.002950] R13:  R14: 8000 R15: 
> 0001fb42c000
> [0.002952] FS:  () GS:88f71000() 
> knlGS:
> [0.002953] CS:  0010 DS:  ES:  CR0: 80050033
> [0.002954] CR2: a080fb401000 CR3: 0001fa80a000 CR4: 
> 000406b0
> [0.002956] Call Trace:
> [0.002961]  ? memblock_alloc_range_nid+0x8d/0x11e
> [0.002963]  ? cma_declare_contiguous_nid+0x2c4/0x38c
> [0.002964]  ? hugetlb_cma_reserve+0xdc/0x128
> [0.002968]  ? flush_tlb_one_kernel+0xc/0x20
> [0.002969]  ? native_set_fixmap+0x82/0xd0
> [0.002971]  ? flat_get_apic_id+0x5/0x10
> [0.002973]  ? register_lapic_address+0x8e/0x97
> [0.002975]  ? setup_arch+0x8a5/0xc3f
> [0.002978]  ? start_kernel+0x66/0x547
> [0.002980]  ? load_ucode_bsp+0x4c/0xcd
> [0.002982]  ? secondary_startup_64_no_verify+0xb0/0xbb
> [0.002986] random: get_random_bytes called from __warn+0xab/0x110 with 
> crng_init=0
> [0.002988] ---[ end trace f151227d0b39be70 ]---
> 
> At the same time, the kernel image is protected with memblock_reserve(),
> so we can just start searching at PAGE_SIZE. In this case the
> bottom-up allocation has the same chances to success as a top-down
> allocation, so there is no reason to fallback in the case of a
> failure. All together it simplifies the logic.
> 
> Signed-off-by: Roman Gushchin 

Reviewed-by: Mike Rapoport 

> ---
>  mm/memblock.c | 49 ++---
>  1 file changed, 6 insertions(+), 43 deletions(-)
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index b68ee86788af..10bd7d1ef0f4 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -275,14 +275,6 @@ __memblock_find_range_top_down(phys_addr_t start, 
> phys_addr_t end,
>   *
>   * Find @size free area aligned to @align in the specified range and node.
>   *
> - * When allocation direction is bottom-up, the @start should be greater
> - * than the end of the kernel image. Otherwise, it will be trimmed. The
> - * reason is that we want the bottom-up allocation just near the kernel
> - * image so it is highly likely that the allocated memory and the kernel
> - * will reside in the same node.
> - *
> - * If bottom-up allocation failed, will try to allocate memory top-down.
> - *
>   * Return:
>   * Found address on success, 0 on failure.
>   */
> @@ -291,8 +283,6 @@ static phys_addr_t __init_memblock 
> memblock_find_in_range_node(phys_addr_t size,
>   phys_addr_t end, int nid,
>   enum memblock_flags flags)
>  {
> - phys_addr_t kernel_end, ret;
> -
>   /* pump up @end */
>   if (end == MEMBLOCK_ALLOC_ACCESSIBLE ||
>   end == MEMBLOCK_ALLOC_KASAN)
> @@ -301,40 +291,13 @@ static phys_addr_t __init_memblock 
> memblock_find_in_range_node(phys_addr_t size,
>   /* avoid allocating the first page */
>   start = max_t(phys_addr_t, start, PAGE_SIZE);
>   end = max(start, end);
> - kernel_end = __pa_symbol(_end);
> -
> - /*
> -  * try bottom-up allocation only when bottom-up mode
> -  * is set and @end is above the kernel image.
> -  */
> - if (memblock_bottom_up() && end > kernel_end) {
> - phys_addr_t bottom_up_start;
> -
> - /* make sure we will allocate above the kernel */
> - bottom_up_start = max(start, kernel_end);
>  
> - /* ok, try 

Re: [PATCH v2 1/2] mm: cma: allocate cma areas bottom-up

[Mike Rapoport]

On Thu, Dec 17, 2020 at 12:12:13PM -0800, Roman Gushchin wrote:
> Currently cma areas without a fixed base are allocated close to the
> end of the node. This placement is sub-optimal because of compaction:
> it brings pages into the cma area. In particular, it can bring in hot
> executable pages, even if there is a plenty of free memory on the
> machine. This results in cma allocation failures.
> 
> Instead let's place cma areas close to the beginning of a node.
> In this case the compaction will help to free cma areas, resulting
> in better cma allocation success rates.
> 
> If there is enough memory let's try to allocate bottom-up starting
> with 4GB to exclude any possible interference with DMA32. On smaller
> machines or in a case of a failure, stick with the old behavior.
> 
> 16GB vm, 2GB cma area:
> With this patch:
> [0.00] Command line: root=/dev/vda3 rootflags=subvol=/root 
> systemd.unified_cgroup_hierarchy=1 enforcing=0 console=ttyS0,115200 
> hugetlb_cma=2G
> [0.002928] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
> [0.002930] cma: Reserved 2048 MiB at 0x0001
> [0.002931] hugetlb_cma: reserved 2048 MiB on node 0
> 
> Without this patch:
> [0.00] Command line: root=/dev/vda3 rootflags=subvol=/root 
> systemd.unified_cgroup_hierarchy=1 enforcing=0 console=ttyS0,115200 
> hugetlb_cma=2G
> [0.002930] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
> [0.002933] cma: Reserved 2048 MiB at 0x0003c000
> [0.002934] hugetlb_cma: reserved 2048 MiB on node 0
> 
> v2:
>   - switched to memblock_set_bottom_up(true), by Mike
>   - start with 4GB, by Mike
> 
> Signed-off-by: Roman Gushchin 

With one nit below 

Reviewed-by: Mike Rapoport 

> ---
>  mm/cma.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/mm/cma.c b/mm/cma.c
> index 7f415d7cda9f..21fd40c092f0 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -337,6 +337,22 @@ int __init cma_declare_contiguous_nid(phys_addr_t base,
>   limit = highmem_start;
>   }
>  
> + /*
> +  * If there is enough memory, try a bottom-up allocation first.
> +  * It will place the new cma area close to the start of the node
> +  * and guarantee that the compaction is moving pages out of the
> +  * cma area and not into it.
> +  * Avoid using first 4GB to not interfere with constrained zones
> +  * like DMA/DMA32.
> +  */
> + if (!memblock_bottom_up() &&
> + memblock_end >= SZ_4G + size) {

This seems short enough to fit a single line

> + memblock_set_bottom_up(true);
> + addr = memblock_alloc_range_nid(size, alignment, SZ_4G,
> + limit, nid, true);
> + memblock_set_bottom_up(false);
> + }
> +
>   if (!addr) {
>   addr = memblock_alloc_range_nid(size, alignment, base,
>   limit, nid, true);
> -- 
> 2.26.2
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 3/6] clk: mstar: MStar/SigmaStar MPLL driver

[Daniel Palmer]

Hi Stephen,

On Sun, 20 Dec 2020 at 13:36, Stephen Boyd  wrote:
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index da8fcf147eb1..b758aae17ab8 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -124,3 +124,4 @@ endif
> >  obj-$(CONFIG_ARCH_ZX)  += zte/
> >  obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
> >  obj-$(CONFIG_COMMON_CLK_ZYNQMP) += zynqmp/
> > +obj-$(CONFIG_ARCH_MSTARV7) += mstar/
>
> This is in the wrong place. It looks to be sorted based on the path
> name, so mstar/ comes much earlier in this file.

Noted. I'll fix this.

> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> Please remove unused includes
>
> > +#include 
> > +#include 
>
> Isn't it builtin? This include should be removed.

Yes. Sorry it was originally a module and there are some leftovers I
didn't clean up when I changed it to builtin.

> > +#define to_mpll(_hw) container_of(_hw, struct msc313_mpll, clk_hw)
> > +#define to_divider_hw(_mpll, _which) _mpll->clk_data->hws[_which + 1]
>
> I'd rather not have this macro. It's confusing given that to_foo()
> macros are usually a container_of() invocation. Given that it's only
> used in the registration/unregistration loops please inline it and use a
> local variable.
>

Ok I'll rework that.

> > +
> > +static int msc313_mpll_remove(struct platform_device *pdev)
> > +{
> > +   struct msc313_mpll *mpll = platform_get_drvdata(pdev);
> > +   int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(output_dividers); i++)
> > +   clk_hw_unregister_fixed_factor(to_divider_hw(mpll, i));
>
> Maybe add a devm_ for this if it doesn't exist.

I did think about adding this. Would I need to do that in a separate
series or would it be ok to roll it into this one?

Thanks,

Daniel

Re: [PATCH 2/6] dt-bindings: clk: mstar msc313 mpll binding description

[Daniel Palmer]

Hi Stephen,

On Sun, 20 Dec 2020 at 12:39, Stephen Boyd  wrote:
> > +  clock-output-names:
> > +minItems: 8
> > +maxItems: 8
> > +description: |
> > +  This should provide a name for the internal PLL clock and then
> > +  a name for each of the divided outputs.
>
> Is this necessary?

I found without the names specified in the dt probing of muxes that
depend on the outputs but appear earlier didn't work.
Also this same PLL layout seems to be used in some other places so
eventually I was thinking this driver would get used for those PLLs
with different output names.

Thanks,

Daniel

[PATCH] atomic: remove further references to atomic_ops

[Lukas Bulwahn]

Commit f0400a77ebdc ("atomic: Delete obsolete documentation") removed
./Documentation/core-api/atomic_ops.rst, but missed to remove further
references to that file.

Hence, make htmldocs warns:

  Documentation/core-api/index.rst:53: WARNING:
  toctree contains reference to nonexisting document 'core-api/atomic_ops'

Also, ./scripts/get_maintainer.pl --self-test=patterns warns:

  warning: no file matchesF:Documentation/core-api/atomic_ops.rst

Remove further references to ./Documentation/core-api/atomic_ops.rst.

Fixes: f0400a77ebdc ("atomic: Delete obsolete documentation")
Signed-off-by: Lukas Bulwahn 
---

Peter, please pick this quick minor fix on top of your commit above.

 Documentation/core-api/index.rst | 1 -
 MAINTAINERS  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index 69171b1799f2..f1c9d20bd42d 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -53,7 +53,6 @@ How Linux keeps everything from happening at the same time.  
See
 .. toctree::
:maxdepth: 1
 
-   atomic_ops
refcount-vs-atomic
irq/index
local_ops
diff --git a/MAINTAINERS b/MAINTAINERS
index f5eafee83bc6..4ea4ef9ec5d4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10280,7 +10280,6 @@ S:  Supported
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev
 F: Documentation/atomic_bitops.txt
 F: Documentation/atomic_t.txt
-F: Documentation/core-api/atomic_ops.rst
 F: Documentation/core-api/refcount-vs-atomic.rst
 F: Documentation/litmus-tests/
 F: Documentation/memory-barriers.txt
-- 
2.17.1

Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect

[Yu Zhao]

On Sat, Dec 19, 2020 at 01:34:29PM -0800, Nadav Amit wrote:
> [ cc’ing some more people who have experience with similar problems ]
> 
> > On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli  wrote:
> > 
> > Hello,
> > 
> > On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
> >> Analyzing this problem indicates that there is a real bug since
> >> mmap_lock is only taken for read in mwriteprotect_range(). This might
> > 
> > Never having to take the mmap_sem for writing, and in turn never
> > blocking, in order to modify the pagetables is quite an important
> > feature in uffd that justifies uffd instead of mprotect. It's not the
> > most important reason to use uffd, but it'd be nice if that guarantee
> > would remain also for the UFFDIO_WRITEPROTECT API, not only for the
> > other pgtable manipulations.
> > 
> >> Consider the following scenario with 3 CPUs (cpu2 is not shown):
> >> 
> >> cpu0   cpu1
> >>    
> >> userfaultfd_writeprotect()
> >> [ write-protecting ]
> >> mwriteprotect_range()
> >> mmap_read_lock()
> >> change_protection()
> >>  change_protection_range()
> >>   ...
> >>   change_pte_range()
> >>   [ defer TLB flushes]
> >>userfaultfd_writeprotect()
> >> mmap_read_lock()
> >> change_protection()
> >> [ write-unprotect ]
> >> ...
> >>  [ unprotect PTE logically ]
> >>...
> >>[ page-fault]
> >>...
> >>wp_page_copy()
> >>[ set new writable page in PTE]

I don't see any problem in this example -- wp_page_copy() calls
ptep_clear_flush_notify(), which should take care of the stale entry
left by cpu0.

That being said, I suspect the memory corruption you observed is
related this example, with cpu1 running something else that flushes
conditionally depending on pte_write().

Do you know which type of pages were corrupted? file, anon, etc.

> > Can't we check mm_tlb_flush_pending(vma->vm_mm) if MM_CP_UFFD_WP_ALL
> > is set and do an explicit (potentially spurious) tlb flush before
> > write-unprotect?
> 
> There is a concrete scenario that I actually encountered and then there is a
> general problem.
> 
> In general, the kernel code assumes that PTEs that are read from the
> page-tables are coherent across all the TLBs, excluding permission promotion
> (i.e., the PTE may have higher permissions in the page-tables than those
> that are cached in the TLBs).
> 
> We therefore need to both: (a) protect change_protection_range() from the
> changes of others who might defer TLB flushes without taking mmap_sem for
> write (e.g., try_to_unmap_one()); and (b) to protect others (e.g.,
> page-fault handlers) from concurrent changes of change_protection().
> 
> We have already encountered several similar bugs, and debugging such issues
> s time consuming and these bugs impact is substantial (memory corruption,
> security). So I think we should only stick to general solutions.
> 
> So perhaps your the approach of your proposed solution is feasible, but it
> would have to be applied all over the place: we will need to add a check for
> mm_tlb_flush_pending() and conditionally flush the TLB in every case in
> which PTEs are read and there might be an assumption that the
> access-permission reflect what the TLBs hold. This includes page-fault
> handlers, but also NUMA migration code in change_protection(), softdirty
> cleanup in clear_refs_write() and maybe others.
> 
> [ I have in mind another solution, such as keeping in each page-table a 
> “table-generation” which is the mm-generation at the time of the change,
> and only flush if “table-generation”==“mm-generation”, but it requires
> some thought on how to avoid adding new memory barriers. ]
> 
> IOW: I think the change that you suggest is insufficient, and a proper
> solution is too intrusive for “stable".
> 
> As for performance, I can add another patch later to remove the TLB flush
> that is unnecessarily performed during change_protection_range() that does
> permission promotion. I know that your concern is about the “protect” case
> but I cannot think of a good immediate solution that avoids taking mmap_lock
> for write.
> 
> Thoughts?
> 

[PATCH v6 2/3] scsi: ufs: Clean up ufshcd_exit_clk_scaling/gating()

[Can Guo]

ufshcd_hba_exit() is always called after ufshcd_exit_clk_scaling() and
ufshcd_exit_clk_gating(), so move ufshcd_exit_clk_scaling/gating() to
ufshcd_hba_exit().

Reviewed-by: Stanley Chu 
Reviewed-by: Bean Huo 
Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 32 +++-
 drivers/scsi/ufs/ufshcd.h |  4 
 2 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 79752a7..2dee21e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1857,11 +1857,14 @@ static void ufshcd_init_clk_scaling(struct ufs_hba *hba)
snprintf(wq_name, sizeof(wq_name), "ufs_clkscaling_%d",
 hba->host->host_no);
hba->clk_scaling.workq = create_singlethread_workqueue(wq_name);
+
+   hba->clk_scaling.is_initialized = true;
 }
 
 static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
 {
-   if (!ufshcd_is_clkscaling_supported(hba))
+   if (!ufshcd_is_clkscaling_supported(hba) ||
+   !hba->clk_scaling.is_initialized)
return;
 
if (hba->devfreq)
@@ -1905,12 +1908,16 @@ static void ufshcd_init_clk_gating(struct ufs_hba *hba)
hba->clk_gating.enable_attr.attr.mode = 0644;
if (device_create_file(hba->dev, >clk_gating.enable_attr))
dev_err(hba->dev, "Failed to create sysfs for 
clkgate_enable\n");
+
+   hba->clk_gating.is_initialized = true;
 }
 
 static void ufshcd_exit_clk_gating(struct ufs_hba *hba)
 {
-   if (!ufshcd_is_clkgating_allowed(hba))
+   if (!ufshcd_is_clkgating_allowed(hba) ||
+   !hba->clk_gating.is_initialized)
return;
+
device_remove_file(hba->dev, >clk_gating.delay_attr);
device_remove_file(hba->dev, >clk_gating.enable_attr);
cancel_work_sync(>clk_gating.ungate_work);
@@ -7775,7 +7782,6 @@ static void ufshcd_async_scan(void *data, async_cookie_t 
cookie)
 */
if (ret) {
pm_runtime_put_sync(hba->dev);
-   ufshcd_exit_clk_scaling(hba);
ufshcd_hba_exit(hba);
}
 }
@@ -8212,12 +8218,12 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
 static void ufshcd_hba_exit(struct ufs_hba *hba)
 {
if (hba->is_powered) {
+   ufshcd_exit_clk_scaling(hba);
+   ufshcd_exit_clk_gating(hba);
+   if (hba->eh_wq)
+   destroy_workqueue(hba->eh_wq);
ufshcd_variant_hba_exit(hba);
ufshcd_setup_vreg(hba, false);
-   ufshcd_suspend_clkscaling(hba);
-   if (ufshcd_is_clkscaling_supported(hba))
-   if (hba->devfreq)
-   ufshcd_suspend_clkscaling(hba);
ufshcd_setup_clocks(hba, false);
ufshcd_setup_hba_vreg(hba, false);
hba->is_powered = false;
@@ -8964,13 +8970,9 @@ void ufshcd_remove(struct ufs_hba *hba)
blk_mq_free_tag_set(>tmf_tag_set);
blk_cleanup_queue(hba->cmd_queue);
scsi_remove_host(hba->host);
-   destroy_workqueue(hba->eh_wq);
/* disable interrupts */
ufshcd_disable_intr(hba, hba->intr_mask);
ufshcd_hba_stop(hba);
-
-   ufshcd_exit_clk_scaling(hba);
-   ufshcd_exit_clk_gating(hba);
ufshcd_hba_exit(hba);
 }
 EXPORT_SYMBOL_GPL(ufshcd_remove);
@@ -9169,7 +9171,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
err = devm_request_irq(dev, irq, ufshcd_intr, IRQF_SHARED, UFSHCD, hba);
if (err) {
dev_err(hba->dev, "request irq failed\n");
-   goto exit_gating;
+   goto out_disable;
} else {
hba->is_irq_enabled = true;
}
@@ -9177,7 +9179,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
err = scsi_add_host(host, hba->dev);
if (err) {
dev_err(hba->dev, "scsi_add_host failed\n");
-   goto exit_gating;
+   goto out_disable;
}
 
hba->cmd_queue = blk_mq_init_queue(>host->tag_set);
@@ -9260,10 +9262,6 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
blk_cleanup_queue(hba->cmd_queue);
 out_remove_scsi_host:
scsi_remove_host(hba->host);
-exit_gating:
-   ufshcd_exit_clk_scaling(hba);
-   ufshcd_exit_clk_gating(hba);
-   destroy_workqueue(hba->eh_wq);
 out_disable:
hba->is_irq_enabled = false;
ufshcd_hba_exit(hba);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5737679..cb9075d 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -347,6 +347,7 @@ enum clk_gating_state {
  * @delay_attr: sysfs attribute to control delay_attr
  * @enable_attr: sysfs attribute to enable/disable clock gating
  * @is_enabled: Indicates the current status of clock gating
+ * @is_initialized: Indicates 

[PATCH v6 1/3] scsi: ufs: Protect some contexts from unexpected clock scaling

[Can Guo]

In contexts like suspend, shutdown and error handling, we need to suspend
devfreq to make sure these contexts won't be disturbed by clock scaling.
However, suspending devfreq is not enough since users can still trigger a
clock scaling by manipulating the sysfs node clkscale_enable and devfreq
sysfs nodes like min/max_freq and governor. Add one more flag in struct
clk_scaling such that these contexts can prevent clock scaling from being
invoked through above sysfs nodes.

Reviewed-by: Stanley Chu 
Reviewed-by: Bean Huo 
Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 81 +++
 drivers/scsi/ufs/ufshcd.h |  6 +++-
 2 files changed, 58 insertions(+), 29 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0c148fc..79752a7 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1147,12 +1147,22 @@ static int ufshcd_clock_scaling_prepare(struct ufs_hba 
*hba)
 */
ufshcd_scsi_block_requests(hba);
down_write(>clk_scaling_lock);
-   if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US)) {
+
+   if (!hba->clk_scaling.is_allowed)
+   ret = -EAGAIN;
+   else if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US))
ret = -EBUSY;
+
+   if (ret) {
up_write(>clk_scaling_lock);
ufshcd_scsi_unblock_requests(hba);
+   goto out;
}
 
+   /* let's not get into low power until clock scaling is completed */
+   ufshcd_hold(hba, false);
+
+out:
return ret;
 }
 
@@ -1160,6 +1170,7 @@ static void ufshcd_clock_scaling_unprepare(struct ufs_hba 
*hba)
 {
up_write(>clk_scaling_lock);
ufshcd_scsi_unblock_requests(hba);
+   ufshcd_release(hba);
 }
 
 /**
@@ -1175,12 +1186,9 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba, 
bool scale_up)
 {
int ret = 0;
 
-   /* let's not get into low power until clock scaling is completed */
-   ufshcd_hold(hba, false);
-
ret = ufshcd_clock_scaling_prepare(hba);
if (ret)
-   goto out;
+   return ret;
 
/* scale down the gear before scaling down clocks */
if (!scale_up) {
@@ -1212,8 +1220,6 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba, bool 
scale_up)
 
 out_unprepare:
ufshcd_clock_scaling_unprepare(hba);
-out:
-   ufshcd_release(hba);
return ret;
 }
 
@@ -1487,7 +1493,7 @@ static ssize_t ufshcd_clkscale_enable_show(struct device 
*dev,
 {
struct ufs_hba *hba = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%d\n", hba->clk_scaling.is_allowed);
+   return snprintf(buf, PAGE_SIZE, "%d\n", hba->clk_scaling.is_enabled);
 }
 
 static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
@@ -1496,12 +1502,20 @@ static ssize_t ufshcd_clkscale_enable_store(struct 
device *dev,
struct ufs_hba *hba = dev_get_drvdata(dev);
u32 value;
int err;
+   unsigned long flags;
+   bool update = true;
 
if (kstrtou32(buf, 0, ))
return -EINVAL;
 
value = !!value;
-   if (value == hba->clk_scaling.is_allowed)
+   spin_lock_irqsave(hba->host->host_lock, flags);
+   if (value == hba->clk_scaling.is_enabled)
+   update = false;
+   else
+   hba->clk_scaling.is_enabled = value;
+   spin_unlock_irqrestore(hba->host->host_lock, flags);
+   if (!update)
goto out;
 
pm_runtime_get_sync(hba->dev);
@@ -1510,8 +1524,6 @@ static ssize_t ufshcd_clkscale_enable_store(struct device 
*dev,
cancel_work_sync(>clk_scaling.suspend_work);
cancel_work_sync(>clk_scaling.resume_work);
 
-   hba->clk_scaling.is_allowed = value;
-
if (value) {
ufshcd_resume_clkscaling(hba);
} else {
@@ -1845,8 +1857,6 @@ static void ufshcd_init_clk_scaling(struct ufs_hba *hba)
snprintf(wq_name, sizeof(wq_name), "ufs_clkscaling_%d",
 hba->host->host_no);
hba->clk_scaling.workq = create_singlethread_workqueue(wq_name);
-
-   ufshcd_clkscaling_init_sysfs(hba);
 }
 
 static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
@@ -1854,6 +1864,8 @@ static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
if (!ufshcd_is_clkscaling_supported(hba))
return;
 
+   if (hba->devfreq)
+   device_remove_file(hba->dev, >clk_scaling.enable_attr);
destroy_workqueue(hba->clk_scaling.workq);
ufshcd_devfreq_remove(hba);
 }
@@ -1918,7 +1930,7 @@ static void ufshcd_clk_scaling_start_busy(struct ufs_hba 
*hba)
if (!hba->clk_scaling.active_reqs++)
queue_resume_work = true;
 
-   if (!hba->clk_scaling.is_allowed || hba->pm_op_in_progress)
+   if (!hba->clk_scaling.is_enabled || hba->pm_op_in_progress)
return;
 
if (queue_resume_work)
@@ -4987,7 +4999,8 @@ static 

[PATCH v6 3/3] scsi: ufs: Revert "Make sure clk scaling happens only when HBA is runtime ACTIVE"

[Can Guo]

Commit 73cc291c27024 ("Make sure clk scaling happens only when HBA is
runtime ACTIVE") is no longer needed since commit f7a42540928a8 ("scsi:
ufs: Protect some contexts from unexpected clock scaling") is a more
mature fix to protect UFS LLD stability from clock scaling invoked through
sysfs nodes by users.

Reviewed-by: Stanley Chu 
Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 2dee21e..7229a1b 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1300,15 +1300,8 @@ static int ufshcd_devfreq_target(struct device *dev,
}
spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
 
-   pm_runtime_get_noresume(hba->dev);
-   if (!pm_runtime_active(hba->dev)) {
-   pm_runtime_put_noidle(hba->dev);
-   ret = -EAGAIN;
-   goto out;
-   }
start = ktime_get();
ret = ufshcd_devfreq_scale(hba, scale_up);
-   pm_runtime_put(hba->dev);
 
trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
(scale_up ? "up" : "down"),
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

general protection fault in j1939_netdev_notify (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:d635a69d Merge tag 'net-next-5.11' of git://git.kernel.org..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1315f12350
kernel config:  https://syzkaller.appspot.com/x/.config?x=c3556e4856b17a95
dashboard link: https://syzkaller.appspot.com/bug?extid=5138c4dd15a0401bec7b
compiler:   clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1295512350
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10f2f30f50

The issue was bisected to:

commit 497a5757ce4e8f37219a3989ac6a561eb9a8e6c7
Author: Heiner Kallweit 
Date:   Sat Nov 7 20:50:56 2020 +

tun: switch to net core provided statistics counters

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=143b845b50
final oops: https://syzkaller.appspot.com/x/report.txt?x=163b845b50
console output: https://syzkaller.appspot.com/x/log.txt?x=123b845b50

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5138c4dd15a0401be...@syzkaller.appspotmail.com
Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters")

general protection fault, probably for non-canonical address 
0xe80fe8c072f1:  [#1] PREEMPT SMP KASAN
KASAN: probably user-memory-access in range 
[0x607f46039788-0x607f4603978f]
CPU: 1 PID: 8472 Comm: syz-executor635 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:j1939_ndev_to_priv net/can/j1939/main.c:219 [inline]
RIP: 0010:j1939_priv_get_by_ndev_locked net/can/j1939/main.c:231 [inline]
RIP: 0010:j1939_priv_get_by_ndev net/can/j1939/main.c:243 [inline]
RIP: 0010:j1939_netdev_notify+0x115/0x320 net/can/j1939/main.c:353
Code: 00 74 08 48 89 df e8 ba 1e 48 f9 48 8b 1b 48 85 db 0f 84 f0 00 00 00 4c 
89 64 24 08 48 81 c3 28 60 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 
89 df e8 8c 1e 48 f9 4c 8b 23 4d 85 e4 0f
RSP: 0018:c9e9fd68 EFLAGS: 00010202
RAX: 0c0fe8c072f1 RBX: 607f46039788 RCX: 88801456d040
RDX: 88801456d040 RSI: 0118 RDI: 0118
RBP: 0118 R08: 8870585d R09: f520001d3fa5
R10: f520001d3fa5 R11:  R12: 0010
R13: 11100293e848 R14: dc00 R15: 8880149f4244
FS:  01d13880() GS:8880b9d0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2080 CR3: 1402f000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 notifier_call_chain kernel/notifier.c:83 [inline]
 raw_notifier_call_chain+0xe7/0x170 kernel/notifier.c:410
 call_netdevice_notifiers_info net/core/dev.c:2022 [inline]
 call_netdevice_notifiers_extack net/core/dev.c:2034 [inline]
 call_netdevice_notifiers+0xeb/0x150 net/core/dev.c:2048
 __tun_chr_ioctl+0x2337/0x4860 drivers/net/tun.c:3093
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440359
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fffd37b9c98 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 004002c8 RCX: 00440359
RDX: 0118 RSI: 400454cd RDI: 0003
RBP: 006ca018 R08: 004002c8 R09: 004002c8
R10:  R11: 0246 R12: 00401b60
R13: 00401bf0 R14:  R15: 
Modules linked in:
---[ end trace 7688a2c3c10da2e1 ]---
RIP: 0010:j1939_ndev_to_priv net/can/j1939/main.c:219 [inline]
RIP: 0010:j1939_priv_get_by_ndev_locked net/can/j1939/main.c:231 [inline]
RIP: 0010:j1939_priv_get_by_ndev net/can/j1939/main.c:243 [inline]
RIP: 0010:j1939_netdev_notify+0x115/0x320 net/can/j1939/main.c:353
Code: 00 74 08 48 89 df e8 ba 1e 48 f9 48 8b 1b 48 85 db 0f 84 f0 00 00 00 4c 
89 64 24 08 48 81 c3 28 60 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 
89 df e8 8c 1e 48 f9 4c 8b 23 4d 85 e4 0f
RSP: 0018:c9e9fd68 EFLAGS: 00010202
RAX: 0c0fe8c072f1 RBX: 607f46039788 RCX: 88801456d040
RDX: 88801456d040 RSI: 0118 RDI: 0118
RBP: 0118 R08: 8870585d R09: f520001d3fa5
R10: f520001d3fa5 R11:  R12: 0010
R13: 11100293e848 R14: dc00 R15: 8880149f4244
FS:  01d13880() GS:8880b9d0() knlGS:
CS:  0010 DS: 

Re: [PATCH v3] drivers: clk: make gpio-gated clock support optional

[Stephen Boyd]

Quoting Stephen Boyd (2020-12-19 16:04:21)
> Quoting Enrico Weigelt, metux IT consult (2020-12-02 04:34:46)
> > The gpio-gate-clock / gpio-mux-clock driver isn't used much,
> > just by a few ARM SoCs, so there's no need to always include
> > it unconditionally.
> > 
> > Thus make it optional, but keep it enabled by default.
> > 
> > changes v3: default to y when gpiolib enabled
> > fix depends on gpiolib to uppercase
> > 
> > changes v2: added missing dependency on gpiolib
> > 
> > Signed-off-by: Enrico Weigelt, metux IT consult 
> > ---
> 
> Applied to clk-next

And now reverted

In file included from include/linux/device.h:32:0,
 from drivers/clk/clk-gpio.c:17:
include/linux/device/driver.h:290:1: warning: data definition has no type or 
storage class
 device_initcall(__driver##_init);
 ^
include/linux/platform_device.h:258:2: note: in expansion of macro 
'builtin_driver'
  builtin_driver(__platform_driver, platform_driver_register)
  ^~
drivers/clk/clk-gpio.c:249:1: note: in expansion of macro 
'builtin_platform_driver'
 builtin_platform_driver(gpio_clk_driver);
 ^~~
include/linux/device/driver.h:290:1: error: type defaults to 'int' in 
declaration of 'device_initcall' [-Werror=implicit-int]
 device_initcall(__driver##_init);
 ^
include/linux/platform_device.h:258:2: note: in expansion of macro 
'builtin_driver'
  builtin_driver(__platform_driver, platform_driver_register)
  ^~
drivers/clk/clk-gpio.c:249:1: note: in expansion of macro 
'builtin_platform_driver'
 builtin_platform_driver(gpio_clk_driver);
 ^~~
drivers/clk/clk-gpio.c:249:1: warning: parameter names (without types) in 
function declaration
In file included from include/linux/device.h:32:0,
 from drivers/clk/clk-gpio.c:17:
drivers/clk/clk-gpio.c:249:25: warning: 'gpio_clk_driver_init' defined but not 
used [-Wunused-function]
 builtin_platform_driver(gpio_clk_driver);
 ^
include/linux/device/driver.h:286:19: note: in definition of macro 
'builtin_driver'
 static int __init __driver##_init(void) \
   ^~~~
drivers/clk/clk-gpio.c:249:1: note: in expansion of macro 
'builtin_platform_driver'
 builtin_platform_driver(gpio_clk_driver);
 ^~~

It looks like it needs to be a bool Kconfig to match how it used to be.
A module would be interesting, but would require more changes
presumably, like getting rid of builtin_platform_driver() and replacing
it with module_platform_driver().

Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect

[Andy Lutomirski]

On Sat, Dec 19, 2020 at 6:49 PM Andrea Arcangeli  wrote:
>
> On Sat, Dec 19, 2020 at 06:01:39PM -0800, Andy Lutomirski wrote:
> > I missed the beginning of this thread, but it looks to me like
> > userfaultfd changes PTEs with not locking except mmap_read_lock().  It
>
> There's no mmap_read_lock, I assume you mean mmap_lock for reading.

Yes.

>
> The ptes are changed always with the PT lock, in fact there's no
> problem with the PTE updates. The only difference with mprotect
> runtime is that the mmap_lock is taken for reading. And the effect
> contested for this change doesn't affect the PTE, but supposedly the
> tlb flushing deferral.

Can you point me at where the lock ends up being taken in this path?
I apparently missed it somewhere.

> Anyway to wait the wrprotect to do the deferred flush, before the
> unprotect can even start, one more mutex in the mm to take in all
> callers of change_protection_range with the mmap_lock for reading may
> be enough.

I'll read the code again tomorrow.

[PATCH v2] inotify, memcg: account inotify instances to kmemcg

[Shakeel Butt]

Currently the fs sysctl inotify/max_user_instances is used to limit the
number of inotify instances on the system. For systems running multiple
workloads, the per-user namespace sysctl max_inotify_instances can be
used to further partition inotify instances. However there is no easy
way to set a sensible system level max limit on inotify instances and
further partition it between the workloads. It is much easier to charge
the underlying resource (i.e. memory) behind the inotify instances to
the memcg of the workload and let their memory limits limit the number
of inotify instances they can create.

With inotify instances charged to memcg, the admin can simply set
max_user_instances to INT_MAX and let the memcg limits of the jobs limit
their inotify instances.

Signed-off-by: Shakeel Butt 
---
Changes since v1:
- introduce fsnotify_alloc_user_group() and convert fanotify in addition
  to inotify to use that function. [suggested by Amir]

 fs/notify/fanotify/fanotify_user.c |  2 +-
 fs/notify/group.c  | 25 -
 fs/notify/inotify/inotify_user.c   |  4 ++--
 include/linux/fsnotify_backend.h   |  1 +
 4 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c 
b/fs/notify/fanotify/fanotify_user.c
index 3e01d8f2ab90..7e7afc2b62e1 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -976,7 +976,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, 
unsigned int, event_f_flags)
f_flags |= O_NONBLOCK;
 
/* fsnotify_alloc_group takes a ref.  Dropped in fanotify_release */
-   group = fsnotify_alloc_group(_fsnotify_ops);
+   group = fsnotify_alloc_user_group(_fsnotify_ops);
if (IS_ERR(group)) {
free_uid(user);
return PTR_ERR(group);
diff --git a/fs/notify/group.c b/fs/notify/group.c
index a4a4b1c64d32..ffd723ffe46d 100644
--- a/fs/notify/group.c
+++ b/fs/notify/group.c
@@ -111,14 +111,12 @@ void fsnotify_put_group(struct fsnotify_group *group)
 }
 EXPORT_SYMBOL_GPL(fsnotify_put_group);
 
-/*
- * Create a new fsnotify_group and hold a reference for the group returned.
- */
-struct fsnotify_group *fsnotify_alloc_group(const struct fsnotify_ops *ops)
+static struct fsnotify_group *__fsnotify_alloc_group(
+   const struct fsnotify_ops *ops, gfp_t gfp)
 {
struct fsnotify_group *group;
 
-   group = kzalloc(sizeof(struct fsnotify_group), GFP_KERNEL);
+   group = kzalloc(sizeof(struct fsnotify_group), gfp);
if (!group)
return ERR_PTR(-ENOMEM);
 
@@ -139,8 +137,25 @@ struct fsnotify_group *fsnotify_alloc_group(const struct 
fsnotify_ops *ops)
 
return group;
 }
+
+/*
+ * Create a new fsnotify_group and hold a reference for the group returned.
+ */
+struct fsnotify_group *fsnotify_alloc_group(const struct fsnotify_ops *ops)
+{
+   return __fsnotify_alloc_group(ops, GFP_KERNEL);
+}
 EXPORT_SYMBOL_GPL(fsnotify_alloc_group);
 
+/*
+ * Create a new fsnotify_group and hold a reference for the group returned.
+ */
+struct fsnotify_group *fsnotify_alloc_user_group(const struct fsnotify_ops 
*ops)
+{
+   return __fsnotify_alloc_group(ops, GFP_KERNEL_ACCOUNT);
+}
+EXPORT_SYMBOL_GPL(fsnotify_alloc_user_group);
+
 int fsnotify_fasync(int fd, struct file *file, int on)
 {
struct fsnotify_group *group = file->private_data;
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index 59c177011a0f..266d17e8ecb9 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -632,11 +632,11 @@ static struct fsnotify_group *inotify_new_group(unsigned 
int max_events)
struct fsnotify_group *group;
struct inotify_event_info *oevent;
 
-   group = fsnotify_alloc_group(_fsnotify_ops);
+   group = fsnotify_alloc_user_group(_fsnotify_ops);
if (IS_ERR(group))
return group;
 
-   oevent = kmalloc(sizeof(struct inotify_event_info), GFP_KERNEL);
+   oevent = kmalloc(sizeof(struct inotify_event_info), GFP_KERNEL_ACCOUNT);
if (unlikely(!oevent)) {
fsnotify_destroy_group(group);
return ERR_PTR(-ENOMEM);
diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
index a2e42d3cd87c..e5409b83e731 100644
--- a/include/linux/fsnotify_backend.h
+++ b/include/linux/fsnotify_backend.h
@@ -470,6 +470,7 @@ static inline void fsnotify_update_flags(struct dentry 
*dentry)
 
 /* create a new group */
 extern struct fsnotify_group *fsnotify_alloc_group(const struct fsnotify_ops 
*ops);
+extern struct fsnotify_group *fsnotify_alloc_user_group(const struct 
fsnotify_ops *ops);
 /* get reference to a group */
 extern void fsnotify_get_group(struct fsnotify_group *group);
 /* drop reference on a group from fsnotify_alloc_group */
-- 
2.29.2.684.gfbc64c5ab5-goog

Re: [RFC PATCH] ptrace: make ptrace() fail if the tracee changed its pid unexpectedly

[Simon Marchi]

On 2020-12-19 2:33 p.m., Oleg Nesterov wrote:
> OOPS! Sorry Simon, yes I forgot to add reported-by. Andrew, or Eric, if
> you take this patch, could you also add
> 
>   Reported-by: Simon Marchi 

I tried the original reproducer on a patched kernel, and it looks good.
GDB's behavior is still not super clean when this situation happens: a
PTRACE_GETREGS on the (disappeared) leader now fails with ESRCH (that's
what we want), and that interrupts the "continue" command and
unexpectedly brings back the prompt while leaving the other thread
running.  But that is all logic that will have to be fixed inside GDB.

So, feel free to add

  Acked-by: Simon Marchi 

too.

Thanks!

Simon

Máte dar vo výške 5 800 000,00 €.

[Mrs. Mavis]

Máte dar vo výške 5 800 000,00 €. od Mavisa Wanczyka odpovedzte týmto kódom 
[MW530342019], aby ste dostali dar

Re: [PATCH 3/6] clk: mstar: MStar/SigmaStar MPLL driver

[Stephen Boyd]

Quoting Daniel Palmer (2020-11-14 05:50:41)
>  F: include/dt-bindings/gpio/msc313-gpio.h
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index c715d4681a0b..a002f2605fa3 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -370,6 +370,7 @@ source "drivers/clk/ingenic/Kconfig"
>  source "drivers/clk/keystone/Kconfig"
>  source "drivers/clk/mediatek/Kconfig"
>  source "drivers/clk/meson/Kconfig"
> +source "drivers/clk/mstar/Kconfig"
>  source "drivers/clk/mvebu/Kconfig"
>  source "drivers/clk/qcom/Kconfig"
>  source "drivers/clk/renesas/Kconfig"

This looks good.

> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index da8fcf147eb1..b758aae17ab8 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -124,3 +124,4 @@ endif
>  obj-$(CONFIG_ARCH_ZX)  += zte/
>  obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
>  obj-$(CONFIG_COMMON_CLK_ZYNQMP) += zynqmp/
> +obj-$(CONFIG_ARCH_MSTARV7) += mstar/

This is in the wrong place. It looks to be sorted based on the path
name, so mstar/ comes much earlier in this file.

> diff --git a/drivers/clk/mstar/Kconfig b/drivers/clk/mstar/Kconfig
> new file mode 100644
> index ..23765edde3af
> --- /dev/null
> +++ b/drivers/clk/mstar/Kconfig
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config MSTAR_MSC313_MPLL
> +   bool
> +   select REGMAP
> +   select REGMAP_MMIO
> diff --git a/drivers/clk/mstar/Makefile b/drivers/clk/mstar/Makefile
> new file mode 100644
> index ..f8dcd25ede1d
> --- /dev/null
> +++ b/drivers/clk/mstar/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Makefile for mstar specific clk
> +#
> +
> +obj-$(CONFIG_MSTAR_MSC313_MPLL) += clk-msc313-mpll.o
> diff --git a/drivers/clk/mstar/clk-msc313-mpll.c 
> b/drivers/clk/mstar/clk-msc313-mpll.c
> new file mode 100644
> index ..c1e2fe0fc412
> --- /dev/null
> +++ b/drivers/clk/mstar/clk-msc313-mpll.c
> @@ -0,0 +1,177 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MStar MSC313 MPLL driver
> + *
> + * Copyright (C) 2020 Daniel Palmer 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

Please remove unused includes

> +#include 
> +#include 

Isn't it builtin? This include should be removed.

> +#include 
> +
> +#define REG_CONFIG10x8
> +#define REG_CONFIG20xc
> +
> +static const struct regmap_config msc313_mpll_regmap_config = {
> +   .reg_bits = 16,
> +   .val_bits = 16,
> +   .reg_stride = 4,
> +};
> +
> +static const struct reg_field config1_loop_div_first = 
> REG_FIELD(REG_CONFIG1, 8, 9);
> +static const struct reg_field config1_input_div_first = 
> REG_FIELD(REG_CONFIG1, 4, 5);
> +static const struct reg_field config2_output_div_first = 
> REG_FIELD(REG_CONFIG2, 12, 13);
> +static const struct reg_field config2_loop_div_second = 
> REG_FIELD(REG_CONFIG2, 0, 7);
> +
> +static const unsigned int output_dividers[] = {
> +   2, 3, 4, 5, 6, 7, 10
> +};
> +
> +#define NUMOUTPUTS (ARRAY_SIZE(output_dividers) + 1)
> +
> +struct msc313_mpll {
> +   struct clk_hw clk_hw;
> +   struct regmap_field *input_div;
> +   struct regmap_field *loop_div_first;
> +   struct regmap_field *loop_div_second;
> +   struct regmap_field *output_div;
> +   struct clk_hw_onecell_data *clk_data;
> +};
> +
> +#define to_mpll(_hw) container_of(_hw, struct msc313_mpll, clk_hw)
> +#define to_divider_hw(_mpll, _which) _mpll->clk_data->hws[_which + 1]

I'd rather not have this macro. It's confusing given that to_foo()
macros are usually a container_of() invocation. Given that it's only
used in the registration/unregistration loops please inline it and use a
local variable.

> +
> +static unsigned long msc313_mpll_recalc_rate(struct clk_hw *hw,
> +   unsigned long parent_rate)
> +{
> +   struct msc313_mpll *mpll = to_mpll(hw);
> +   unsigned int input_div, output_div, loop_first, loop_second;
> +   unsigned long output_rate;
> +
> +   regmap_field_read(mpll->input_div, _div);
> +   regmap_field_read(mpll->output_div, _div);
> +   regmap_field_read(mpll->loop_div_first, _first);
> +   regmap_field_read(mpll->loop_div_second, _second);
> +
> +   output_rate = parent_rate / (1 << input_div);
> +   output_rate *= (1 << loop_first) * max(loop_second, 1U);
> +   output_rate /= max(output_div, 1U);
> +
> +   return output_rate;
> +}
> +
> +static const struct clk_ops msc313_mpll_ops = {
> +   .recalc_rate = msc313_mpll_recalc_rate,

Weird double indent here.

> +};
> +
> +static int msc313_mpll_probe(struct platform_device *pdev)
> +{
> +   void __iomem *base;
> +   struct msc313_mpll *mpll;
> +   struct clk_init_data clk_init;
> +   struct device *dev = >dev;
> +   struct regmap *regmap;
> +   const char *parents[1], *outputnames[NUMOUTPUTS];
> +   const int numparents = ARRAY_SIZE(parents);
> +   int ret, 

Re: [PATCH] inotify, memcg: account inotify instances to kmemcg

[Shakeel Butt]

On Sat, Dec 19, 2020 at 8:25 AM Amir Goldstein  wrote:
>
> On Sat, Dec 19, 2020 at 4:31 PM Shakeel Butt  wrote:
> >
> > On Sat, Dec 19, 2020 at 1:48 AM Amir Goldstein  wrote:
> > >
> > > On Sat, Dec 19, 2020 at 12:11 AM Shakeel Butt  wrote:
> > > >
> > > > Currently the fs sysctl inotify/max_user_instances is used to limit the
> > > > number of inotify instances on the system. For systems running multiple
> > > > workloads, the per-user namespace sysctl max_inotify_instances can be
> > > > used to further partition inotify instances. However there is no easy
> > > > way to set a sensible system level max limit on inotify instances and
> > > > further partition it between the workloads. It is much easier to charge
> > > > the underlying resource (i.e. memory) behind the inotify instances to
> > > > the memcg of the workload and let their memory limits limit the number
> > > > of inotify instances they can create.
> > >
> > > Not that I have a problem with this patch, but what problem does it try to
> > > solve?
> >
> > I am aiming for the simplicity to not set another limit which can
> > indirectly be limited by memcg limits. I just want to set the memcg
> > limit on our production environment which runs multiple workloads on a
> > system and not think about setting a sensible value to
> > max_user_instances in production. I would prefer to set
> > max_user_instances to max int and let the memcg limits of the
> > workloads limit their inotify usage.
> >
>
> understood.
> and I guess the multiple workloads cannot run each in their own userns?
> because then you wouldn't need to change max_user_instances limit.
>

No workloads can run in their own user namespace but please note that
max_user_instances is shared between all the user namespaces.

>
[snip]
> > > Any reason why you did not include fanotify in this patch?
> >
> > The motivation was inotify's max_user_instances but we can charge
> > fsnotify_group for fanotify as well. Though I would prefer that to be
> > a separate patch. Let me know what you prefer?
> >
>
> I would prefer to add the helper fsnotify_alloc_user_group()
> that will use the GFP_KERNEL_ACCOUNT allocation flags
> internally.
>
> fsnotify_alloc_group() is used by all backends that initialize a single
> group instance for internal use and  fsnotify_alloc_user_group() will be
> used by inotify/fanotify when users create instances.
> I see no reason to separate that to two patches.
>

SGTM.

Re: [PATCH] zsmalloc: do not use bit_spin_lock

[Mike Galbraith]

On Sun, 2020-12-20 at 02:23 +0100, Mike Galbraith wrote:
> On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote:
> > zsmalloc takes bit spinlock in its _map() callback and releases it
> > only in unmap() which is unsafe and leads to zswap complaining
> > about scheduling in atomic context.
> >
> > To fix that and to improve RT properties of zsmalloc, remove that
> > bit spinlock completely and use a bit flag instead.
>
> It also does get_cpu_var() in map(), put_cpu_var() in unmap().

Bah, I forgot to mention the config dependent rwlock, it's held across
map()/unmap() as well, so there are two more hurdles, not one.

-Mike

Re: [PATCH v2] mips: lib: uncached: fix non-standard usage of variable 'sp'

[Naresh Kamboju]

On Mon, 14 Dec 2020 at 21:05, Thomas Bogendoerfer
 wrote:
>
> On Fri, Dec 11, 2020 at 11:24:37AM +0100, Anders Roxell wrote:
> > When building mips tinyconfig with clang the following warning show up:
> >
> > arch/mips/lib/uncached.c:45:6: warning: variable 'sp' is uninitialized when 
> > used here [-Wuninitialized]
> > if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
> > ^~
> > arch/mips/lib/uncached.c:40:18: note: initialize the variable 'sp' to 
> > silence this warning
> > register long sp __asm__("$sp");
> > ^
> >  = 0
> > 1 warning generated.



> > [1] https://docs.w3cub.com/gcc~10/local-register-variables
> > Signed-off-by: Anders Roxell 
> > ---
> >  arch/mips/lib/uncached.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
>
> applied to mips-next.

We have noticed these build failures on stable tree also.
May I request you to initiate the process to get into the stable tree
and for the following branches.
 - linux-5.10.y
 - linux-5.9.y
 - linux-5.4.y
 - linux-4.19.y

- Naresh

Re: [PATCH 5.4 00/34] 5.4.85-rc1 review

[Naresh Kamboju]

On Sat, 19 Dec 2020 at 18:33, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.4.85 release.
> There are 34 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Mon, 21 Dec 2020 12:53:29 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.85-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.4.85-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: bcf35e05a52636bd982a253c1ed928d3b128a332
git describe: v5.4.84-35-gbcf35e05a526
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.83-72-gbcf35e05a526
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.84-35-gbcf35e05a526

No regressions (compared to build v5.4.83-37-gfbaf54ae613a)

No fixes (compared to build v5.4.83-37-gfbaf54ae613a)

Ran 45558 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu_arm
- qemu_arm64
- qemu-arm64-clang
- qemu_arm64-compat
- qemu-arm64-kasan
- qemu-arm-clang
- qemu_i386
- qemu_x86_64
- qemu-x86_64-clang
- qemu_x86_64-compat
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- riscv
- s390
- sh
- sparc
- x15
- x15
- x86
- x86-kasan

Test Suites
---
* build
* fwts
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 5.9 00/49] 5.9.16-rc1 review

[Naresh Kamboju]

On Sat, 19 Dec 2020 at 18:28, Greg Kroah-Hartman
 wrote:
>
> --
> Note, I would like to make this the past, or next-to-last 5.9.y kernel
> to be released.  If anyone knows of any reason they can not move to the
> 5.10.y kernel now, please let me know!
> --
>
> This is the start of the stable review cycle for the 5.9.16 release.
> There are 49 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Mon, 21 Dec 2020 12:53:29 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.16-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.9.16-rc1
git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git branch: linux-5.9.y
git commit: 345f3d037fc5bdbbc65a33c917192261fdd58393
git describe: v5.9.14-156-g345f3d037fc5
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.14-156-g345f3d037fc5
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.15-50-g345f3d037fc5

No regressions (compared to build v5.9.14-106-g609d95a95925)

No fixes (compared to build v5.9.14-106-g609d95a95925)

Ran 57227 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu_arm
- qemu_arm64
- qemu-arm64-clang
- qemu_arm64-compat
- qemu-arm64-kasan
- qemu-arm-clang
- qemu_i386
- qemu-i386-clang
- qemu_x86_64
- qemu-x86_64-clang
- qemu_x86_64-compat
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance


--
Linaro LKFT
https://lkft.linaro.org

[PATCH v2 0/4] panic: Add new API in_panic_state()

[Xiaoming Ni]

For some features (such as hang_task, ledtrig-activity, ledtrig-heartbeat)
different processing logics need to be performed based on whether the
current system is in panic state:
1: Register hook for panic_notifier_list.
2. Assign a value to the global variable in the hook function.
3. Determine whether the system is in panic state based on the
  global variable and perform different processing.
Duplicate code snippets exist, and the timing judgment is relatively lag.
Therefore, consider extracting the new API: bool in_panic_state(void).



v2: Rename api to in_panic_state as recommended by Pavel Machek, Tetsuo
 Handa, Randy Dunlap.

v1: https://lore.kernel.org/lkml/20201218114406.61906-1-nixiaom...@huawei.com/
  API name: is_being_panic


Xiaoming Ni (4):
  panic: Add new API in_panic_state()
  hung_task: Replace "did_panic" with in_panic_state()
  leds:trigger:ledtrig-activity Replace "panic_detected" with
in_panic_state()
  leds:trigger:ledtrig-heartbeat: Replace "panic_heartbeats" with
in_panic_state()

 drivers/leds/trigger/ledtrig-activity.c  | 19 +--
 drivers/leds/trigger/ledtrig-heartbeat.c | 19 +--
 include/linux/kernel.h   |  1 +
 kernel/hung_task.c   | 17 +
 kernel/panic.c   |  6 ++
 5 files changed, 10 insertions(+), 52 deletions(-)

-- 
2.27.0

[PATCH v2 4/4] leds:trigger:ledtrig-heartbeat: Replace "panic_heartbeats" with in_panic_state()

[Xiaoming Ni]

Replace the global variable "panic_heartbeats" with in_panic_state()

Signed-off-by: Xiaoming Ni 
---
 drivers/leds/trigger/ledtrig-heartbeat.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-heartbeat.c 
b/drivers/leds/trigger/ledtrig-heartbeat.c
index 36b6709afe9f..f24d64cf0a62 100644
--- a/drivers/leds/trigger/ledtrig-heartbeat.c
+++ b/drivers/leds/trigger/ledtrig-heartbeat.c
@@ -19,8 +19,6 @@
 #include 
 #include "../leds.h"
 
-static int panic_heartbeats;
-
 struct heartbeat_trig_data {
struct led_classdev *led_cdev;
unsigned int phase;
@@ -39,7 +37,7 @@ static void led_heartbeat_function(struct timer_list *t)
 
led_cdev = heartbeat_data->led_cdev;
 
-   if (unlikely(panic_heartbeats)) {
+   if (unlikely(in_panic_state())) {
led_set_brightness_nosleep(led_cdev, LED_OFF);
return;
}
@@ -169,28 +167,15 @@ static int heartbeat_reboot_notifier(struct 
notifier_block *nb,
return NOTIFY_DONE;
 }
 
-static int heartbeat_panic_notifier(struct notifier_block *nb,
-unsigned long code, void *unused)
-{
-   panic_heartbeats = 1;
-   return NOTIFY_DONE;
-}
-
 static struct notifier_block heartbeat_reboot_nb = {
.notifier_call = heartbeat_reboot_notifier,
 };
 
-static struct notifier_block heartbeat_panic_nb = {
-   .notifier_call = heartbeat_panic_notifier,
-};
-
 static int __init heartbeat_trig_init(void)
 {
int rc = led_trigger_register(_led_trigger);
 
if (!rc) {
-   atomic_notifier_chain_register(_notifier_list,
-  _panic_nb);
register_reboot_notifier(_reboot_nb);
}
return rc;
@@ -199,8 +184,6 @@ static int __init heartbeat_trig_init(void)
 static void __exit heartbeat_trig_exit(void)
 {
unregister_reboot_notifier(_reboot_nb);
-   atomic_notifier_chain_unregister(_notifier_list,
-_panic_nb);
led_trigger_unregister(_led_trigger);
 }
 
-- 
2.27.0

[PATCH v2 3/4] leds:trigger:ledtrig-activity Replace "panic_detected" with in_panic_state()

[Xiaoming Ni]

Replace the global variable "panic_detected" with in_panic_state()

Signed-off-by: Xiaoming Ni 
---
 drivers/leds/trigger/ledtrig-activity.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-activity.c 
b/drivers/leds/trigger/ledtrig-activity.c
index 14ba7faaed9e..9675c9348516 100644
--- a/drivers/leds/trigger/ledtrig-activity.c
+++ b/drivers/leds/trigger/ledtrig-activity.c
@@ -17,8 +17,6 @@
 #include 
 #include "../leds.h"
 
-static int panic_detected;
-
 struct activity_data {
struct timer_list timer;
struct led_classdev *led_cdev;
@@ -47,7 +45,7 @@ static void led_activity_function(struct timer_list *t)
if (test_and_clear_bit(LED_BLINK_BRIGHTNESS_CHANGE, 
_cdev->work_flags))
led_cdev->blink_brightness = led_cdev->new_blink_brightness;
 
-   if (unlikely(panic_detected)) {
+   if (unlikely(in_panic_state())) {
/* full brightness in case of panic */
led_set_brightness_nosleep(led_cdev, 
led_cdev->blink_brightness);
return;
@@ -226,28 +224,15 @@ static int activity_reboot_notifier(struct notifier_block 
*nb,
return NOTIFY_DONE;
 }
 
-static int activity_panic_notifier(struct notifier_block *nb,
-   unsigned long code, void *unused)
-{
-   panic_detected = 1;
-   return NOTIFY_DONE;
-}
-
 static struct notifier_block activity_reboot_nb = {
.notifier_call = activity_reboot_notifier,
 };
 
-static struct notifier_block activity_panic_nb = {
-   .notifier_call = activity_panic_notifier,
-};
-
 static int __init activity_init(void)
 {
int rc = led_trigger_register(_led_trigger);
 
if (!rc) {
-   atomic_notifier_chain_register(_notifier_list,
-  _panic_nb);
register_reboot_notifier(_reboot_nb);
}
return rc;
@@ -256,8 +241,6 @@ static int __init activity_init(void)
 static void __exit activity_exit(void)
 {
unregister_reboot_notifier(_reboot_nb);
-   atomic_notifier_chain_unregister(_notifier_list,
-_panic_nb);
led_trigger_unregister(_led_trigger);
 }
 
-- 
2.27.0

[PATCH v2 2/4] hung_task: Replace "did_panic" with in_panic_state()

[Xiaoming Ni]

Replace the global variable "did_panic" with in_panic_state()

Signed-off-by: Xiaoming Ni 
---
 kernel/hung_task.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index bb2e3e15c84c..2747cd6dd35e 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -50,7 +50,6 @@ unsigned long __read_mostly 
sysctl_hung_task_check_interval_secs;
 
 int __read_mostly sysctl_hung_task_warnings = 10;
 
-static int __read_mostly did_panic;
 static bool hung_task_show_lock;
 static bool hung_task_call_panic;
 static bool hung_task_show_all_bt;
@@ -72,18 +71,6 @@ unsigned int __read_mostly 
sysctl_hung_task_all_cpu_backtrace;
 unsigned int __read_mostly sysctl_hung_task_panic =
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE;
 
-static int
-hung_task_panic(struct notifier_block *this, unsigned long event, void *ptr)
-{
-   did_panic = 1;
-
-   return NOTIFY_DONE;
-}
-
-static struct notifier_block panic_block = {
-   .notifier_call = hung_task_panic,
-};
-
 static void check_hung_task(struct task_struct *t, unsigned long timeout)
 {
unsigned long switch_count = t->nvcsw + t->nivcsw;
@@ -223,7 +210,7 @@ static void check_hung_uninterruptible_tasks(unsigned long 
timeout)
 * If the system crashed already then all bets are off,
 * do not report extra hung tasks:
 */
-   if (test_taint(TAINT_DIE) || did_panic)
+   if (test_taint(TAINT_DIE) || unlikely(in_panic_state()))
return;
 
hung_task_show_lock = false;
@@ -347,8 +334,6 @@ static int watchdog(void *dummy)
 
 static int __init hung_task_init(void)
 {
-   atomic_notifier_chain_register(_notifier_list, _block);
-
/* Disable hung task detector on suspend */
pm_notifier(hungtask_pm_notify, 0);
 
-- 
2.27.0

[PATCH v2 1/4] panic: Add new API in_panic_state()

[Xiaoming Ni]

For some features (such as hang_task, ledtrig-activity, ledtrig-heartbeat)
different processing logics need to be performed based on whether the
current system is in panic state:
1: Register hook for panic_notifier_list.
2. Assign a value to the global variable in the hook function.
3. Determine whether the system is in panic state based on the
  global variable and perform different processing.
Duplicate code snippets exist, and the timing judgment is relatively lag.
Therefore, consider extracting the new API: bool in_panic_state(void).

Signed-off-by: Xiaoming Ni 
---
 include/linux/kernel.h | 1 +
 kernel/panic.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f7902d8c1048..c9a9078157b6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -167,6 +167,7 @@ void __might_fault(const char *file, int line);
 static inline void might_fault(void) { }
 #endif
 
+extern bool in_panic_state(void);
 extern struct atomic_notifier_head panic_notifier_list;
 extern long (*panic_blink)(int state);
 __printf(1, 2)
diff --git a/kernel/panic.c b/kernel/panic.c
index 332736a72a58..351627883a04 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -125,6 +125,12 @@ void __weak crash_smp_send_stop(void)
 
 atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
 
+bool in_panic_state(void)
+{
+   return (atomic_read(_cpu) != PANIC_CPU_INVALID);
+}
+EXPORT_SYMBOL(in_panic_state);
+
 /*
  * A variant of panic() called from NMI context. We return if we've already
  * panicked on this CPU. If another CPU already panicked, loop in
-- 
2.27.0

WARNING in ext4_evict_inode

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:3db1a3fa Merge tag 'staging-5.11-rc1' of git://git.kernel...
git tree:   net
console output: https://syzkaller.appspot.com/x/log.txt?x=15c2f30f50
kernel config:  https://syzkaller.appspot.com/x/.config?x=2764fc28a92339f9
dashboard link: https://syzkaller.appspot.com/bug?extid=f3e5bd9358af6c9a28c5
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f3e5bd9358af6c9a2...@syzkaller.appspotmail.com

[ cut here ]
WARNING: CPU: 1 PID: 8514 at fs/ext4/inode.c:229 ext4_evict_inode+0x112c/0x1800 
fs/ext4/inode.c:229
Modules linked in:
CPU: 1 PID: 8514 Comm: syz-executor.1 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:ext4_evict_inode+0x112c/0x1800 fs/ext4/inode.c:229
Code: 05 72 d6 d3 0a 01 e8 ea 75 ae 06 e9 08 f5 ff ff c7 44 24 2c 06 00 00 00 
c7 44 24 28 06 00 00 00 e9 9f f6 ff ff e8 54 29 6b ff <0f> 0b e9 34 f4 ff ff e8 
48 29 6b ff e8 73 07 57 ff 31 ff 41 89 c5
RSP: 0018:c9000166fcb8 EFLAGS: 00010293
RAX:  RBX: 1920002cdf9e RCX: 8205683e
RDX: 8880125fb580 RSI: 8205740c RDI: 0005
RBP: 888059bf0338 R08:  R09: 
R10:  R11:  R12: 0001
R13: 888015bb1070 R14: 895fec20 R15: 888059bf4b00
FS:  0258e940() GS:8880b9f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 001b30522000 CR3: 47a9c000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 evict+0x2ed/0x750 fs/inode.c:578
 iput_final fs/inode.c:1654 [inline]
 iput.part.0+0x3fe/0x820 fs/inode.c:1680
 iput+0x58/0x70 fs/inode.c:1670
 do_unlinkat+0x40b/0x660 fs/namei.c:3903
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45dea7
Code: 00 66 90 b8 58 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 ad b6 fb ff c3 66 
2e 0f 1f 84 00 00 00 00 00 66 90 b8 57 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 
8d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff0cd52098 EFLAGS: 0246 ORIG_RAX: 0057
RAX: ffda RBX:  RCX: 0045dea7
RDX: 7fff0cd520b0 RSI: 7fff0cd520b0 RDI: 7fff0cd52140
RBP: 0714 R08:  R09: 001b
R10: 0015 R11: 0246 R12: 7fff0cd531d0
R13: 0258fa60 R14:  R15: 000ab9e5


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [PATCH 2/6] dt-bindings: clk: mstar msc313 mpll binding description

[Stephen Boyd]

Quoting Daniel Palmer (2020-11-14 05:50:40)
> Add a binding description for the MStar/SigmaStar MPLL clock block.
> 
> Signed-off-by: Daniel Palmer 
> ---
>  .../bindings/clock/mstar,msc313-mpll.yaml | 58 +++
>  MAINTAINERS   |  1 +
>  2 files changed, 59 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/mstar,msc313-mpll.yaml
> 
> diff --git a/Documentation/devicetree/bindings/clock/mstar,msc313-mpll.yaml 
> b/Documentation/devicetree/bindings/clock/mstar,msc313-mpll.yaml
> new file mode 100644
> index ..9ddc1163b31b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mstar,msc313-mpll.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/mstar,msc313-mpll.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MStar/Sigmastar MSC313 MPLL
> +
> +maintainers:
> +  - Daniel Palmer 
> +
> +description: |
> +  The MStar/SigmaStar MSC313 and later ARMv7 chips have an MPLL block that
> +  takes the external xtal input and multiplies it to create a high
> +  frequency clock and divides that down into a number of clocks that
> +  peripherals use.
> +
> +properties:
> +  compatible:
> +const: mstar,msc313-mpll
> +
> +  "#clock-cells":
> +const: 1
> +
> +  clocks:
> +maxItems: 1
> +
> +  clock-output-names:
> +minItems: 8
> +maxItems: 8
> +description: |
> +  This should provide a name for the internal PLL clock and then
> +  a name for each of the divided outputs.

Is this necessary?

> +
> +  reg:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - "#clock-cells"
> +  - clocks
> +  - clock-output-names
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +mpll@206000 {
> +compatible = "mstar,msc313-mpll";
> +reg = <0x206000 0x200>;
> +#clock-cells = <1>;
> +clocks = <>;
> +clock-output-names = "mpll", "mpll_div_2",
> + "mpll_div_3", "mpll_div_4",
> + "mpll_div_5", "mpll_div_6",
> + "mpll_div_7", "mpll_div_10";

It looks like it can be derived in the driver.

[PATCH AUTOSEL 5.9 10/15] Input: cros_ec_keyb - send 'scancodes' in addition to key events

[Sasha Levin]

From: Dmitry Torokhov 

[ Upstream commit 80db2a087f425b63f0163bc95217abd01c637cb5 ]

To let userspace know what 'scancodes' should be used in EVIOCGKEYCODE
and EVIOCSKEYCODE ioctls, we should send EV_MSC/MSC_SCAN events in
addition to EV_KEY/KEY_* events. The driver already declared MSC_SCAN
capability, so it is only matter of actually sending the events.

Link: https://lore.kernel.org/r/x87aoasptptvz...@google.com
Acked-by: Rajat Jain 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/keyboard/cros_ec_keyb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
b/drivers/input/keyboard/cros_ec_keyb.c
index fc1793ca2f174..0a748aed02658 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -183,6 +183,7 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
"changed: [r%d c%d]: byte %02x\n",
row, col, new_state);
 
+   input_event(idev, EV_MSC, MSC_SCAN, pos);
input_report_key(idev, keycodes[pos],
 new_state);
}
-- 
2.27.0

[PATCH AUTOSEL 5.9 13/15] initramfs: fix clang build failure

[Sasha Levin]

From: Arnd Bergmann 

[ Upstream commit 55d5b7dd6451b58489ce384282ca5a4a289eb8d5 ]

There is only one function in init/initramfs.c that is in the .text
section, and it is marked __weak.  When building with clang-12 and the
integrated assembler, this leads to a bug with recordmcount:

  ./scripts/recordmcount  "init/initramfs.o"
  Cannot find symbol for section 2: .text.
  init/initramfs.o: failed

I'm not quite sure what exactly goes wrong, but I notice that this
function is only ever called from an __init function, and normally
inlined.  Marking it __init as well is clearly correct and it leads to
recordmcount no longer complaining.

Link: https://lkml.kernel.org/r/20201204165742.3815221-1-a...@kernel.org
Signed-off-by: Arnd Bergmann 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Barret Rhoden 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 init/initramfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 1f97c0328a7ae..55b74d7e52607 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -535,7 +535,7 @@ extern unsigned long __initramfs_size;
 #include 
 #include 
 
-void __weak free_initrd_mem(unsigned long start, unsigned long end)
+void __weak __init free_initrd_mem(unsigned long start, unsigned long end)
 {
 #ifdef CONFIG_ARCH_KEEP_MEMBLOCK
unsigned long aligned_start = ALIGN_DOWN(start, PAGE_SIZE);
-- 
2.27.0

[PATCH AUTOSEL 5.9 11/15] selftests/bpf: Fix array access with signed variable test

[Sasha Levin]

From: Jean-Philippe Brucker 

[ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]

The test fails because of a recent fix to the verifier, even though this
program is valid. In details what happens is:

7: (61) r1 = *(u32 *)(r0 +0)

Load a 32-bit value, with signed bounds [S32_MIN, S32_MAX]. The bounds
of the 64-bit value are [0, U32_MAX]...

8: (65) if r1 s> 0x goto pc+1

... therefore this is always true (the operand is sign-extended).

10: (b4) w2 = 11
11: (6d) if r2 s> r1 goto pc+1

When true, the 64-bit bounds become [0, 10]. The 32-bit bounds are still
[S32_MIN, 10].

13: (64) w1 <<= 2

Because this is a 32-bit operation, the verifier propagates the new
32-bit bounds to the 64-bit ones, and the knowledge gained from insn 11
is lost.

14: (0f) r0 += r1
15: (7a) *(u64 *)(r0 +0) = 4

Then the verifier considers r0 unbounded here, rejecting the test. To
make the test work, change insn 8 to check the sign of the 32-bit value.

Signed-off-by: Jean-Philippe Brucker 
Acked-by: John Fastabend 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/bpf/verifier/array_access.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/verifier/array_access.c 
b/tools/testing/selftests/bpf/verifier/array_access.c
index 1c4b1939f5a8d..bed53b561e044 100644
--- a/tools/testing/selftests/bpf/verifier/array_access.c
+++ b/tools/testing/selftests/bpf/verifier/array_access.c
@@ -68,7 +68,7 @@
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 9),
BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0),
-   BPF_JMP_IMM(BPF_JSGT, BPF_REG_1, 0x, 1),
+   BPF_JMP32_IMM(BPF_JSGT, BPF_REG_1, 0x, 1),
BPF_MOV32_IMM(BPF_REG_1, 0),
BPF_MOV32_IMM(BPF_REG_2, MAX_ENTRIES),
BPF_JMP_REG(BPF_JSGT, BPF_REG_2, BPF_REG_1, 1),
-- 
2.27.0

[PATCH AUTOSEL 4.14 1/4] cfg80211: initialize rekey_data

[Sasha Levin]

From: Sara Sharon 

[ Upstream commit f495acd8851d7b345e5f0e521b2645b1e1f928a0 ]

In case we have old supplicant, the akm field is uninitialized.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Link: 
https://lore.kernel.org/r/iwlwifi.20201129172929.930f0ab7ebee.Ic546e384efab3f4a89f318eafddc3eb7d556aecb@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 6bd4f6c8fc2ef..f630fa2e31647 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10969,7 +10969,7 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, 
struct genl_info *info)
struct net_device *dev = info->user_ptr[1];
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct nlattr *tb[NUM_NL80211_REKEY_DATA];
-   struct cfg80211_gtk_rekey_data rekey_data;
+   struct cfg80211_gtk_rekey_data rekey_data = {};
int err;
 
if (!info->attrs[NL80211_ATTR_REKEY_DATA])
-- 
2.27.0

[PATCH AUTOSEL 4.4 2/3] Input: cros_ec_keyb - send 'scancodes' in addition to key events

[Sasha Levin]

From: Dmitry Torokhov 

[ Upstream commit 80db2a087f425b63f0163bc95217abd01c637cb5 ]

To let userspace know what 'scancodes' should be used in EVIOCGKEYCODE
and EVIOCSKEYCODE ioctls, we should send EV_MSC/MSC_SCAN events in
addition to EV_KEY/KEY_* events. The driver already declared MSC_SCAN
capability, so it is only matter of actually sending the events.

Link: https://lore.kernel.org/r/x87aoasptptvz...@google.com
Acked-by: Rajat Jain 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/keyboard/cros_ec_keyb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
b/drivers/input/keyboard/cros_ec_keyb.c
index b01966dc7eb3d..44a5a5496cfd0 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -137,6 +137,7 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
"changed: [r%d c%d]: byte %02x\n",
row, col, new_state);
 
+   input_event(idev, EV_MSC, MSC_SCAN, pos);
input_report_key(idev, keycodes[pos],
 new_state);
}
-- 
2.27.0

[PATCH AUTOSEL 5.4 05/10] drm/amd/display: Prevent bandwidth overflow

[Sasha Levin]

From: Chris Park 

[ Upstream commit 80089dd8410f356d5104496d5ab71a66a4f4646b ]

[Why]
At very high pixel clock, bandwidth calculation exceeds 32 bit size
and overflow value. This causes the resulting selection of link rate
to be inaccurate.

[How]
Change order of operation and use fixed point to deal with integer
accuracy. Also address bug found when forcing link rate.

Signed-off-by: Chris Park 
Reviewed-by: Wenjing Liu 
Acked-by: Eryk Brol 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 47cefc05fd3f5..f933791f1fbbb 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2906,11 +2906,14 @@ uint32_t dc_bandwidth_in_kbps_from_timing(
 {
uint32_t bits_per_channel = 0;
uint32_t kbps;
+   struct fixed31_32 link_bw_kbps;
 
 #ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
if (timing->flags.DSC) {
-   kbps = (timing->pix_clk_100hz * timing->dsc_cfg.bits_per_pixel);
-   kbps = kbps / 160 + ((kbps % 160) ? 1 : 0);
+   link_bw_kbps = dc_fixpt_from_int(timing->pix_clk_100hz);
+   link_bw_kbps = dc_fixpt_div_int(link_bw_kbps, 160);
+   link_bw_kbps = dc_fixpt_mul_int(link_bw_kbps, 
timing->dsc_cfg.bits_per_pixel);
+   kbps = dc_fixpt_ceil(link_bw_kbps);
return kbps;
}
 #endif
-- 
2.27.0

[PATCH AUTOSEL 5.4 06/10] drm/amdkfd: Fix leak in dmabuf import

[Sasha Levin]

From: Felix Kuehling 

[ Upstream commit c897934da15f182ce99536007f8ef61c4748c07e ]

Release dmabuf reference before returning from kfd_ioctl_import_dmabuf.
amdgpu_amdkfd_gpuvm_import_dmabuf takes a reference to the underlying
GEM BO and doesn't keep the reference to the dmabuf wrapper.

Signed-off-by: Felix Kuehling 
Reviewed-by: Kent Russell 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 1d3cd5c50d5f2..4a0ef9268918c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1664,6 +1664,7 @@ static int kfd_ioctl_import_dmabuf(struct file *filep,
}
 
mutex_unlock(>mutex);
+   dma_buf_put(dmabuf);
 
args->handle = MAKE_HANDLE(args->gpu_id, idr_handle);
 
@@ -1673,6 +1674,7 @@ static int kfd_ioctl_import_dmabuf(struct file *filep,
amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem);
 err_unlock:
mutex_unlock(>mutex);
+   dma_buf_put(dmabuf);
return r;
 }
 
-- 
2.27.0

[PATCH AUTOSEL 5.4 04/10] lwt: Disable BH too in run_lwt_bpf()

[Sasha Levin]

From: Dongdong Wang 

[ Upstream commit d9054a1ff585ba01029584ab730efc794603d68f ]

The per-cpu bpf_redirect_info is shared among all skb_do_redirect()
and BPF redirect helpers. Callers on RX path are all in BH context,
disabling preemption is not sufficient to prevent BH interruption.

In production, we observed strange packet drops because of the race
condition between LWT xmit and TC ingress, and we verified this issue
is fixed after we disable BH.

Although this bug was technically introduced from the beginning, that
is commit 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure"),
at that time call_rcu() had to be call_rcu_bh() to match the RCU context.
So this patch may not work well before RCU flavor consolidation has been
completed around v5.0.

Update the comments above the code too, as call_rcu() is now BH friendly.

Signed-off-by: Dongdong Wang 
Signed-off-by: Alexei Starovoitov 
Reviewed-by: Cong Wang 
Link: 
https://lore.kernel.org/bpf/20201205075946.497763-1-xiyou.wangc...@gmail.com
Signed-off-by: Sasha Levin 
---
 net/core/lwt_bpf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c
index 99a6de52b21da..a5502c5aa44e7 100644
--- a/net/core/lwt_bpf.c
+++ b/net/core/lwt_bpf.c
@@ -39,12 +39,11 @@ static int run_lwt_bpf(struct sk_buff *skb, struct 
bpf_lwt_prog *lwt,
 {
int ret;
 
-   /* Preempt disable is needed to protect per-cpu redirect_info between
-* BPF prog and skb_do_redirect(). The call_rcu in bpf_prog_put() and
-* access to maps strictly require a rcu_read_lock() for protection,
-* mixing with BH RCU lock doesn't work.
+   /* Preempt disable and BH disable are needed to protect per-cpu
+* redirect_info between BPF prog and skb_do_redirect().
 */
preempt_disable();
+   local_bh_disable();
bpf_compute_data_pointers(skb);
ret = bpf_prog_run_save_cb(lwt->prog, skb);
 
@@ -78,6 +77,7 @@ static int run_lwt_bpf(struct sk_buff *skb, struct 
bpf_lwt_prog *lwt,
break;
}
 
+   local_bh_enable();
preempt_enable();
 
return ret;
-- 
2.27.0

[PATCH AUTOSEL 4.9 3/3] Input: goodix - add upside-down quirk for Teclast X98 Pro tablet

[Sasha Levin]

From: Simon Beginn 

[ Upstream commit cffdd6d90482316e18d686060a4397902ea04bd2 ]

The touchscreen on the Teclast x98 Pro is also mounted upside-down in
relation to the display orientation.

Signed-off-by: Simon Beginn 
Signed-off-by: Bastien Nocera 
Link: https://lore.kernel.org/r/20201117004253.27A5A27EFD@localhost
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/touchscreen/goodix.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 6a02e7301297d..ba0ab9963f3cd 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -98,6 +98,18 @@ static const struct dmi_system_id rotated_screen[] = {
DMI_MATCH(DMI_BIOS_DATE, "12/19/2014"),
},
},
+   {
+   .ident = "Teclast X98 Pro",
+   .matches = {
+   /*
+* Only match BIOS date, because the manufacturers
+* BIOS does not report the board name at all
+* (sometimes)...
+*/
+   DMI_MATCH(DMI_BOARD_VENDOR, "TECLAST"),
+   DMI_MATCH(DMI_BIOS_DATE, "10/28/2015"),
+   },
+   },
{
.ident = "WinBook TW100",
.matches = {
-- 
2.27.0

[PATCH AUTOSEL 4.19 2/6] cfg80211: initialize rekey_data

[Sasha Levin]

From: Sara Sharon 

[ Upstream commit f495acd8851d7b345e5f0e521b2645b1e1f928a0 ]

In case we have old supplicant, the akm field is uninitialized.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Link: 
https://lore.kernel.org/r/iwlwifi.20201129172929.930f0ab7ebee.Ic546e384efab3f4a89f318eafddc3eb7d556aecb@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fbc8875502c3e..5f0605275fa39 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11502,7 +11502,7 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, 
struct genl_info *info)
struct net_device *dev = info->user_ptr[1];
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct nlattr *tb[NUM_NL80211_REKEY_DATA];
-   struct cfg80211_gtk_rekey_data rekey_data;
+   struct cfg80211_gtk_rekey_data rekey_data = {};
int err;
 
if (!info->attrs[NL80211_ATTR_REKEY_DATA])
-- 
2.27.0

[PATCH AUTOSEL 5.4 10/10] Input: goodix - add upside-down quirk for Teclast X98 Pro tablet

[Sasha Levin]

From: Simon Beginn 

[ Upstream commit cffdd6d90482316e18d686060a4397902ea04bd2 ]

The touchscreen on the Teclast x98 Pro is also mounted upside-down in
relation to the display orientation.

Signed-off-by: Simon Beginn 
Signed-off-by: Bastien Nocera 
Link: https://lore.kernel.org/r/20201117004253.27A5A27EFD@localhost
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/touchscreen/goodix.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 37b35ab97beb2..bfb945fc33a17 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -137,6 +137,18 @@ static const struct dmi_system_id rotated_screen[] = {
DMI_MATCH(DMI_BIOS_DATE, "12/19/2014"),
},
},
+   {
+   .ident = "Teclast X98 Pro",
+   .matches = {
+   /*
+* Only match BIOS date, because the manufacturers
+* BIOS does not report the board name at all
+* (sometimes)...
+*/
+   DMI_MATCH(DMI_BOARD_VENDOR, "TECLAST"),
+   DMI_MATCH(DMI_BIOS_DATE, "10/28/2015"),
+   },
+   },
{
.ident = "WinBook TW100",
.matches = {
-- 
2.27.0

[PATCH AUTOSEL 5.4 08/10] selftests/bpf: Fix array access with signed variable test

[Sasha Levin]

From: Jean-Philippe Brucker 

[ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]

The test fails because of a recent fix to the verifier, even though this
program is valid. In details what happens is:

7: (61) r1 = *(u32 *)(r0 +0)

Load a 32-bit value, with signed bounds [S32_MIN, S32_MAX]. The bounds
of the 64-bit value are [0, U32_MAX]...

8: (65) if r1 s> 0x goto pc+1

... therefore this is always true (the operand is sign-extended).

10: (b4) w2 = 11
11: (6d) if r2 s> r1 goto pc+1

When true, the 64-bit bounds become [0, 10]. The 32-bit bounds are still
[S32_MIN, 10].

13: (64) w1 <<= 2

Because this is a 32-bit operation, the verifier propagates the new
32-bit bounds to the 64-bit ones, and the knowledge gained from insn 11
is lost.

14: (0f) r0 += r1
15: (7a) *(u64 *)(r0 +0) = 4

Then the verifier considers r0 unbounded here, rejecting the test. To
make the test work, change insn 8 to check the sign of the 32-bit value.

Signed-off-by: Jean-Philippe Brucker 
Acked-by: John Fastabend 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/bpf/verifier/array_access.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/verifier/array_access.c 
b/tools/testing/selftests/bpf/verifier/array_access.c
index f3c33e128709b..a80d806ead15f 100644
--- a/tools/testing/selftests/bpf/verifier/array_access.c
+++ b/tools/testing/selftests/bpf/verifier/array_access.c
@@ -68,7 +68,7 @@
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 9),
BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0),
-   BPF_JMP_IMM(BPF_JSGT, BPF_REG_1, 0x, 1),
+   BPF_JMP32_IMM(BPF_JSGT, BPF_REG_1, 0x, 1),
BPF_MOV32_IMM(BPF_REG_1, 0),
BPF_MOV32_IMM(BPF_REG_2, MAX_ENTRIES),
BPF_JMP_REG(BPF_JSGT, BPF_REG_2, BPF_REG_1, 1),
-- 
2.27.0

[PATCH AUTOSEL 4.14 4/4] Input: goodix - add upside-down quirk for Teclast X98 Pro tablet

[Sasha Levin]

From: Simon Beginn 

[ Upstream commit cffdd6d90482316e18d686060a4397902ea04bd2 ]

The touchscreen on the Teclast x98 Pro is also mounted upside-down in
relation to the display orientation.

Signed-off-by: Simon Beginn 
Signed-off-by: Bastien Nocera 
Link: https://lore.kernel.org/r/20201117004253.27A5A27EFD@localhost
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/touchscreen/goodix.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 777dd5b159d39..87f5722a67829 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -101,6 +101,18 @@ static const struct dmi_system_id rotated_screen[] = {
DMI_MATCH(DMI_BIOS_DATE, "12/19/2014"),
},
},
+   {
+   .ident = "Teclast X98 Pro",
+   .matches = {
+   /*
+* Only match BIOS date, because the manufacturers
+* BIOS does not report the board name at all
+* (sometimes)...
+*/
+   DMI_MATCH(DMI_BOARD_VENDOR, "TECLAST"),
+   DMI_MATCH(DMI_BIOS_DATE, "10/28/2015"),
+   },
+   },
{
.ident = "WinBook TW100",
.matches = {
-- 
2.27.0

[PATCH AUTOSEL 4.14 2/4] [SECURITY] fix namespaced fscaps when !CONFIG_SECURITY

[Sasha Levin]

From: Serge Hallyn 

[ Upstream commit ed9b25d1970a4787ac6a39c2091e63b127ecbfc1 ]

Namespaced file capabilities were introduced in 8db6c34f1dbc .
When userspace reads an xattr for a namespaced capability, a
virtualized representation of it is returned if the caller is
in a user namespace owned by the capability's owning rootid.
The function which performs this virtualization was not hooked
up if CONFIG_SECURITY=n.  Therefore in that case the original
xattr was shown instead of the virtualized one.

To test this using libcap-bin (*1),

$ v=$(mktemp)
$ unshare -Ur setcap cap_sys_admin-eip $v
$ unshare -Ur setcap -v cap_sys_admin-eip $v
/tmp/tmp.lSiIFRvt8Y: OK

"setcap -v" verifies the values instead of setting them, and
will check whether the rootid value is set.  Therefore, with
this bug un-fixed, and with CONFIG_SECURITY=n, setcap -v will
fail:

$ v=$(mktemp)
$ unshare -Ur setcap cap_sys_admin=eip $v
$ unshare -Ur setcap -v cap_sys_admin=eip $v
nsowner[got=1000, want=0],/tmp/tmp.HHDiOOl9fY differs in []

Fix this bug by calling cap_inode_getsecurity() in
security_inode_getsecurity() instead of returning
-EOPNOTSUPP, when CONFIG_SECURITY=n.

*1 - note, if libcap is too old for getcap to have the '-n'
option, then use verify-caps instead.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209689
Cc: Hervé Guillemet 
Acked-by: Casey Schaufler 
Signed-off-by: Serge Hallyn 
Signed-off-by: Andrew G. Morgan 
Signed-off-by: James Morris 
Signed-off-by: Sasha Levin 
---
 include/linux/security.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index ce6265960d6c4..dab093af4ee8d 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -780,7 +780,7 @@ static inline int security_inode_killpriv(struct dentry 
*dentry)
 
 static inline int security_inode_getsecurity(struct inode *inode, const char 
*name, void **buffer, bool alloc)
 {
-   return -EOPNOTSUPP;
+   return cap_inode_getsecurity(inode, name, buffer, alloc);
 }
 
 static inline int security_inode_setsecurity(struct inode *inode, const char 
*name, const void *value, size_t size, int flags)
-- 
2.27.0

[PATCH AUTOSEL 4.4 1/3] cfg80211: initialize rekey_data

[Sasha Levin]

From: Sara Sharon 

[ Upstream commit f495acd8851d7b345e5f0e521b2645b1e1f928a0 ]

In case we have old supplicant, the akm field is uninitialized.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Link: 
https://lore.kernel.org/r/iwlwifi.20201129172929.930f0ab7ebee.Ic546e384efab3f4a89f318eafddc3eb7d556aecb@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7748d674677c9..eb25998a0032e 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -9836,7 +9836,7 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, 
struct genl_info *info)
struct net_device *dev = info->user_ptr[1];
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct nlattr *tb[NUM_NL80211_REKEY_DATA];
-   struct cfg80211_gtk_rekey_data rekey_data;
+   struct cfg80211_gtk_rekey_data rekey_data = {};
int err;
 
if (!info->attrs[NL80211_ATTR_REKEY_DATA])
-- 
2.27.0

[PATCH AUTOSEL 5.4 02/10] cfg80211: initialize rekey_data

[Sasha Levin]

From: Sara Sharon 

[ Upstream commit f495acd8851d7b345e5f0e521b2645b1e1f928a0 ]

In case we have old supplicant, the akm field is uninitialized.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Link: 
https://lore.kernel.org/r/iwlwifi.20201129172929.930f0ab7ebee.Ic546e384efab3f4a89f318eafddc3eb7d556aecb@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index dbac5c0995a0f..5bb2316befb98 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -12033,7 +12033,7 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, 
struct genl_info *info)
struct net_device *dev = info->user_ptr[1];
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct nlattr *tb[NUM_NL80211_REKEY_DATA];
-   struct cfg80211_gtk_rekey_data rekey_data;
+   struct cfg80211_gtk_rekey_data rekey_data = {};
int err;
 
if (!info->attrs[NL80211_ATTR_REKEY_DATA])
-- 
2.27.0

[PATCH AUTOSEL 4.19 4/6] lwt: Disable BH too in run_lwt_bpf()

[Sasha Levin]

From: Dongdong Wang 

[ Upstream commit d9054a1ff585ba01029584ab730efc794603d68f ]

The per-cpu bpf_redirect_info is shared among all skb_do_redirect()
and BPF redirect helpers. Callers on RX path are all in BH context,
disabling preemption is not sufficient to prevent BH interruption.

In production, we observed strange packet drops because of the race
condition between LWT xmit and TC ingress, and we verified this issue
is fixed after we disable BH.

Although this bug was technically introduced from the beginning, that
is commit 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure"),
at that time call_rcu() had to be call_rcu_bh() to match the RCU context.
So this patch may not work well before RCU flavor consolidation has been
completed around v5.0.

Update the comments above the code too, as call_rcu() is now BH friendly.

Signed-off-by: Dongdong Wang 
Signed-off-by: Alexei Starovoitov 
Reviewed-by: Cong Wang 
Link: 
https://lore.kernel.org/bpf/20201205075946.497763-1-xiyou.wangc...@gmail.com
Signed-off-by: Sasha Levin 
---
 net/core/lwt_bpf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c
index a648568c5e8fe..4a5f4fbffd836 100644
--- a/net/core/lwt_bpf.c
+++ b/net/core/lwt_bpf.c
@@ -44,12 +44,11 @@ static int run_lwt_bpf(struct sk_buff *skb, struct 
bpf_lwt_prog *lwt,
 {
int ret;
 
-   /* Preempt disable is needed to protect per-cpu redirect_info between
-* BPF prog and skb_do_redirect(). The call_rcu in bpf_prog_put() and
-* access to maps strictly require a rcu_read_lock() for protection,
-* mixing with BH RCU lock doesn't work.
+   /* Preempt disable and BH disable are needed to protect per-cpu
+* redirect_info between BPF prog and skb_do_redirect().
 */
preempt_disable();
+   local_bh_disable();
bpf_compute_data_pointers(skb);
ret = bpf_prog_run_save_cb(lwt->prog, skb);
 
@@ -82,6 +81,7 @@ static int run_lwt_bpf(struct sk_buff *skb, struct 
bpf_lwt_prog *lwt,
break;
}
 
+   local_bh_enable();
preempt_enable();
 
return ret;
-- 
2.27.0

[PATCH AUTOSEL 4.19 6/6] Input: goodix - add upside-down quirk for Teclast X98 Pro tablet

[Sasha Levin]

From: Simon Beginn 

[ Upstream commit cffdd6d90482316e18d686060a4397902ea04bd2 ]

The touchscreen on the Teclast x98 Pro is also mounted upside-down in
relation to the display orientation.

Signed-off-by: Simon Beginn 
Signed-off-by: Bastien Nocera 
Link: https://lore.kernel.org/r/20201117004253.27A5A27EFD@localhost
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/touchscreen/goodix.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index b20ba65992735..7e480e2364216 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -136,6 +136,18 @@ static const struct dmi_system_id rotated_screen[] = {
DMI_MATCH(DMI_BIOS_DATE, "12/19/2014"),
},
},
+   {
+   .ident = "Teclast X98 Pro",
+   .matches = {
+   /*
+* Only match BIOS date, because the manufacturers
+* BIOS does not report the board name at all
+* (sometimes)...
+*/
+   DMI_MATCH(DMI_BOARD_VENDOR, "TECLAST"),
+   DMI_MATCH(DMI_BIOS_DATE, "10/28/2015"),
+   },
+   },
{
.ident = "WinBook TW100",
.matches = {
-- 
2.27.0

[PATCH AUTOSEL 4.4 3/3] Input: goodix - add upside-down quirk for Teclast X98 Pro tablet

[Sasha Levin]

From: Simon Beginn 

[ Upstream commit cffdd6d90482316e18d686060a4397902ea04bd2 ]

The touchscreen on the Teclast x98 Pro is also mounted upside-down in
relation to the display orientation.

Signed-off-by: Simon Beginn 
Signed-off-by: Bastien Nocera 
Link: https://lore.kernel.org/r/20201117004253.27A5A27EFD@localhost
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/touchscreen/goodix.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 67cadda13ab17..d7cc8f6a292ea 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -77,6 +77,18 @@ static const struct dmi_system_id rotated_screen[] = {
DMI_MATCH(DMI_BIOS_DATE, "12/19/2014"),
},
},
+   {
+   .ident = "Teclast X98 Pro",
+   .matches = {
+   /*
+* Only match BIOS date, because the manufacturers
+* BIOS does not report the board name at all
+* (sometimes)...
+*/
+   DMI_MATCH(DMI_BOARD_VENDOR, "TECLAST"),
+   DMI_MATCH(DMI_BIOS_DATE, "10/28/2015"),
+   },
+   },
{
.ident = "WinBook TW100",
.matches = {
-- 
2.27.0

[PATCH AUTOSEL 4.9 1/3] cfg80211: initialize rekey_data

[Sasha Levin]

From: Sara Sharon 

[ Upstream commit f495acd8851d7b345e5f0e521b2645b1e1f928a0 ]

In case we have old supplicant, the akm field is uninitialized.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Link: 
https://lore.kernel.org/r/iwlwifi.20201129172929.930f0ab7ebee.Ic546e384efab3f4a89f318eafddc3eb7d556aecb@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 5bd89f536720d..ab8bca39afa3f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10428,7 +10428,7 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, 
struct genl_info *info)
struct net_device *dev = info->user_ptr[1];
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct nlattr *tb[NUM_NL80211_REKEY_DATA];
-   struct cfg80211_gtk_rekey_data rekey_data;
+   struct cfg80211_gtk_rekey_data rekey_data = {};
int err;
 
if (!info->attrs[NL80211_ATTR_REKEY_DATA])
-- 
2.27.0

[PATCH AUTOSEL 4.9 2/3] Input: cros_ec_keyb - send 'scancodes' in addition to key events

[Sasha Levin]

From: Dmitry Torokhov 

[ Upstream commit 80db2a087f425b63f0163bc95217abd01c637cb5 ]

To let userspace know what 'scancodes' should be used in EVIOCGKEYCODE
and EVIOCSKEYCODE ioctls, we should send EV_MSC/MSC_SCAN events in
addition to EV_KEY/KEY_* events. The driver already declared MSC_SCAN
capability, so it is only matter of actually sending the events.

Link: https://lore.kernel.org/r/x87aoasptptvz...@google.com
Acked-by: Rajat Jain 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/keyboard/cros_ec_keyb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
b/drivers/input/keyboard/cros_ec_keyb.c
index 25943e9bc8bff..328792e26a9f6 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -140,6 +140,7 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
"changed: [r%d c%d]: byte %02x\n",
row, col, new_state);
 
+   input_event(idev, EV_MSC, MSC_SCAN, pos);
input_report_key(idev, keycodes[pos],
 new_state);
}
-- 
2.27.0

[PATCH AUTOSEL 5.4 03/10] [SECURITY] fix namespaced fscaps when !CONFIG_SECURITY

[Sasha Levin]

From: Serge Hallyn 

[ Upstream commit ed9b25d1970a4787ac6a39c2091e63b127ecbfc1 ]

Namespaced file capabilities were introduced in 8db6c34f1dbc .
When userspace reads an xattr for a namespaced capability, a
virtualized representation of it is returned if the caller is
in a user namespace owned by the capability's owning rootid.
The function which performs this virtualization was not hooked
up if CONFIG_SECURITY=n.  Therefore in that case the original
xattr was shown instead of the virtualized one.

To test this using libcap-bin (*1),

$ v=$(mktemp)
$ unshare -Ur setcap cap_sys_admin-eip $v
$ unshare -Ur setcap -v cap_sys_admin-eip $v
/tmp/tmp.lSiIFRvt8Y: OK

"setcap -v" verifies the values instead of setting them, and
will check whether the rootid value is set.  Therefore, with
this bug un-fixed, and with CONFIG_SECURITY=n, setcap -v will
fail:

$ v=$(mktemp)
$ unshare -Ur setcap cap_sys_admin=eip $v
$ unshare -Ur setcap -v cap_sys_admin=eip $v
nsowner[got=1000, want=0],/tmp/tmp.HHDiOOl9fY differs in []

Fix this bug by calling cap_inode_getsecurity() in
security_inode_getsecurity() instead of returning
-EOPNOTSUPP, when CONFIG_SECURITY=n.

*1 - note, if libcap is too old for getcap to have the '-n'
option, then use verify-caps instead.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209689
Cc: Hervé Guillemet 
Acked-by: Casey Schaufler 
Signed-off-by: Serge Hallyn 
Signed-off-by: Andrew G. Morgan 
Signed-off-by: James Morris 
Signed-off-by: Sasha Levin 
---
 include/linux/security.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index fd022768e91df..df90399a8af98 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -852,7 +852,7 @@ static inline int security_inode_killpriv(struct dentry 
*dentry)
 
 static inline int security_inode_getsecurity(struct inode *inode, const char 
*name, void **buffer, bool alloc)
 {
-   return -EOPNOTSUPP;
+   return cap_inode_getsecurity(inode, name, buffer, alloc);
 }
 
 static inline int security_inode_setsecurity(struct inode *inode, const char 
*name, const void *value, size_t size, int flags)
-- 
2.27.0

[PATCH AUTOSEL 4.14 3/4] Input: cros_ec_keyb - send 'scancodes' in addition to key events

[Sasha Levin]

From: Dmitry Torokhov 

[ Upstream commit 80db2a087f425b63f0163bc95217abd01c637cb5 ]

To let userspace know what 'scancodes' should be used in EVIOCGKEYCODE
and EVIOCSKEYCODE ioctls, we should send EV_MSC/MSC_SCAN events in
addition to EV_KEY/KEY_* events. The driver already declared MSC_SCAN
capability, so it is only matter of actually sending the events.

Link: https://lore.kernel.org/r/x87aoasptptvz...@google.com
Acked-by: Rajat Jain 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/keyboard/cros_ec_keyb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
b/drivers/input/keyboard/cros_ec_keyb.c
index 0993b3f12df6a..149f4045f0f15 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -196,6 +196,7 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
"changed: [r%d c%d]: byte %02x\n",
row, col, new_state);
 
+   input_event(idev, EV_MSC, MSC_SCAN, pos);
input_report_key(idev, keycodes[pos],
 new_state);
}
-- 
2.27.0

[PATCH AUTOSEL 5.4 09/10] initramfs: fix clang build failure

[Sasha Levin]

From: Arnd Bergmann 

[ Upstream commit 55d5b7dd6451b58489ce384282ca5a4a289eb8d5 ]

There is only one function in init/initramfs.c that is in the .text
section, and it is marked __weak.  When building with clang-12 and the
integrated assembler, this leads to a bug with recordmcount:

  ./scripts/recordmcount  "init/initramfs.o"
  Cannot find symbol for section 2: .text.
  init/initramfs.o: failed

I'm not quite sure what exactly goes wrong, but I notice that this
function is only ever called from an __init function, and normally
inlined.  Marking it __init as well is clearly correct and it leads to
recordmcount no longer complaining.

Link: https://lkml.kernel.org/r/20201204165742.3815221-1-a...@kernel.org
Signed-off-by: Arnd Bergmann 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Barret Rhoden 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 init/initramfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 5feee4f616d55..00a32799a38b0 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -527,7 +527,7 @@ extern unsigned long __initramfs_size;
 #include 
 #include 
 
-void __weak free_initrd_mem(unsigned long start, unsigned long end)
+void __weak __init free_initrd_mem(unsigned long start, unsigned long end)
 {
free_reserved_area((void *)start, (void *)end, POISON_FREE_INITMEM,
"initrd");
-- 
2.27.0

[PATCH AUTOSEL 5.4 01/10] ARM: sunxi: Add machine match for the Allwinner V3 SoC

[Sasha Levin]

From: Paul Kocialkowski 

[ Upstream commit ad2091f893bd5dfe2824f0d6819600d120698e9f ]

The Allwinner V3 SoC shares the same base as the V3s but comes with
extra pins and features available. As a result, it has its dedicated
compatible string (already used in device trees), which is added here.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20201031182137.1879521-2-cont...@paulk.fr
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-sunxi/sunxi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 933b6930f024f..a0ca5e7a68de2 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
"allwinner,sun8i-r40",
+   "allwinner,sun8i-v3",
"allwinner,sun8i-v3s",
NULL,
 };
-- 
2.27.0

[PATCH AUTOSEL 5.9 15/15] Input: goodix - add upside-down quirk for Teclast X98 Pro tablet

[Sasha Levin]

From: Simon Beginn 

[ Upstream commit cffdd6d90482316e18d686060a4397902ea04bd2 ]

The touchscreen on the Teclast x98 Pro is also mounted upside-down in
relation to the display orientation.

Signed-off-by: Simon Beginn 
Signed-off-by: Bastien Nocera 
Link: https://lore.kernel.org/r/20201117004253.27A5A27EFD@localhost
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/touchscreen/goodix.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 02c75ea385e08..6612f9e2d7e83 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -192,6 +192,18 @@ static const struct dmi_system_id rotated_screen[] = {
DMI_MATCH(DMI_BIOS_DATE, "12/19/2014"),
},
},
+   {
+   .ident = "Teclast X98 Pro",
+   .matches = {
+   /*
+* Only match BIOS date, because the manufacturers
+* BIOS does not report the board name at all
+* (sometimes)...
+*/
+   DMI_MATCH(DMI_BOARD_VENDOR, "TECLAST"),
+   DMI_MATCH(DMI_BIOS_DATE, "10/28/2015"),
+   },
+   },
{
.ident = "WinBook TW100",
.matches = {
-- 
2.27.0

[PATCH AUTOSEL 5.4 07/10] Input: cros_ec_keyb - send 'scancodes' in addition to key events

[Sasha Levin]

From: Dmitry Torokhov 

[ Upstream commit 80db2a087f425b63f0163bc95217abd01c637cb5 ]

To let userspace know what 'scancodes' should be used in EVIOCGKEYCODE
and EVIOCSKEYCODE ioctls, we should send EV_MSC/MSC_SCAN events in
addition to EV_KEY/KEY_* events. The driver already declared MSC_SCAN
capability, so it is only matter of actually sending the events.

Link: https://lore.kernel.org/r/x87aoasptptvz...@google.com
Acked-by: Rajat Jain 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/keyboard/cros_ec_keyb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
b/drivers/input/keyboard/cros_ec_keyb.c
index 8d4d9786cc745..cae262b6ff398 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -183,6 +183,7 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
"changed: [r%d c%d]: byte %02x\n",
row, col, new_state);
 
+   input_event(idev, EV_MSC, MSC_SCAN, pos);
input_report_key(idev, keycodes[pos],
 new_state);
}
-- 
2.27.0

[PATCH AUTOSEL 5.9 08/15] drm/amd/display: Prevent bandwidth overflow

[Sasha Levin]

From: Chris Park 

[ Upstream commit 80089dd8410f356d5104496d5ab71a66a4f4646b ]

[Why]
At very high pixel clock, bandwidth calculation exceeds 32 bit size
and overflow value. This causes the resulting selection of link rate
to be inaccurate.

[How]
Change order of operation and use fixed point to deal with integer
accuracy. Also address bug found when forcing link rate.

Signed-off-by: Chris Park 
Reviewed-by: Wenjing Liu 
Acked-by: Eryk Brol 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index b0f8bfd48d102..462f8b18440b3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3394,10 +3394,13 @@ uint32_t dc_bandwidth_in_kbps_from_timing(
 {
uint32_t bits_per_channel = 0;
uint32_t kbps;
+   struct fixed31_32 link_bw_kbps;
 
if (timing->flags.DSC) {
-   kbps = (timing->pix_clk_100hz * timing->dsc_cfg.bits_per_pixel);
-   kbps = kbps / 160 + ((kbps % 160) ? 1 : 0);
+   link_bw_kbps = dc_fixpt_from_int(timing->pix_clk_100hz);
+   link_bw_kbps = dc_fixpt_div_int(link_bw_kbps, 160);
+   link_bw_kbps = dc_fixpt_mul_int(link_bw_kbps, 
timing->dsc_cfg.bits_per_pixel);
+   kbps = dc_fixpt_ceil(link_bw_kbps);
return kbps;
}
 
-- 
2.27.0

[PATCH AUTOSEL 5.9 09/15] drm/amdkfd: Fix leak in dmabuf import

[Sasha Levin]

From: Felix Kuehling 

[ Upstream commit c897934da15f182ce99536007f8ef61c4748c07e ]

Release dmabuf reference before returning from kfd_ioctl_import_dmabuf.
amdgpu_amdkfd_gpuvm_import_dmabuf takes a reference to the underlying
GEM BO and doesn't keep the reference to the dmabuf wrapper.

Signed-off-by: Felix Kuehling 
Reviewed-by: Kent Russell 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index e9b96ad3d9a52..fdad4d108dd36 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1729,6 +1729,7 @@ static int kfd_ioctl_import_dmabuf(struct file *filep,
}
 
mutex_unlock(>mutex);
+   dma_buf_put(dmabuf);
 
args->handle = MAKE_HANDLE(args->gpu_id, idr_handle);
 
@@ -1738,6 +1739,7 @@ static int kfd_ioctl_import_dmabuf(struct file *filep,
amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem, 
NULL);
 err_unlock:
mutex_unlock(>mutex);
+   dma_buf_put(dmabuf);
return r;
 }
 
-- 
2.27.0

[PATCH AUTOSEL 5.9 06/15] lwt: Disable BH too in run_lwt_bpf()

[Sasha Levin]

From: Dongdong Wang 

[ Upstream commit d9054a1ff585ba01029584ab730efc794603d68f ]

The per-cpu bpf_redirect_info is shared among all skb_do_redirect()
and BPF redirect helpers. Callers on RX path are all in BH context,
disabling preemption is not sufficient to prevent BH interruption.

In production, we observed strange packet drops because of the race
condition between LWT xmit and TC ingress, and we verified this issue
is fixed after we disable BH.

Although this bug was technically introduced from the beginning, that
is commit 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure"),
at that time call_rcu() had to be call_rcu_bh() to match the RCU context.
So this patch may not work well before RCU flavor consolidation has been
completed around v5.0.

Update the comments above the code too, as call_rcu() is now BH friendly.

Signed-off-by: Dongdong Wang 
Signed-off-by: Alexei Starovoitov 
Reviewed-by: Cong Wang 
Link: 
https://lore.kernel.org/bpf/20201205075946.497763-1-xiyou.wangc...@gmail.com
Signed-off-by: Sasha Levin 
---
 net/core/lwt_bpf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c
index 7d3438215f32c..4f3cb7c15ddfe 100644
--- a/net/core/lwt_bpf.c
+++ b/net/core/lwt_bpf.c
@@ -39,12 +39,11 @@ static int run_lwt_bpf(struct sk_buff *skb, struct 
bpf_lwt_prog *lwt,
 {
int ret;
 
-   /* Preempt disable is needed to protect per-cpu redirect_info between
-* BPF prog and skb_do_redirect(). The call_rcu in bpf_prog_put() and
-* access to maps strictly require a rcu_read_lock() for protection,
-* mixing with BH RCU lock doesn't work.
+   /* Preempt disable and BH disable are needed to protect per-cpu
+* redirect_info between BPF prog and skb_do_redirect().
 */
preempt_disable();
+   local_bh_disable();
bpf_compute_data_pointers(skb);
ret = bpf_prog_run_save_cb(lwt->prog, skb);
 
@@ -78,6 +77,7 @@ static int run_lwt_bpf(struct sk_buff *skb, struct 
bpf_lwt_prog *lwt,
break;
}
 
+   local_bh_enable();
preempt_enable();
 
return ret;
-- 
2.27.0

[PATCH AUTOSEL 4.19 3/6] [SECURITY] fix namespaced fscaps when !CONFIG_SECURITY

[Sasha Levin]

From: Serge Hallyn 

[ Upstream commit ed9b25d1970a4787ac6a39c2091e63b127ecbfc1 ]

Namespaced file capabilities were introduced in 8db6c34f1dbc .
When userspace reads an xattr for a namespaced capability, a
virtualized representation of it is returned if the caller is
in a user namespace owned by the capability's owning rootid.
The function which performs this virtualization was not hooked
up if CONFIG_SECURITY=n.  Therefore in that case the original
xattr was shown instead of the virtualized one.

To test this using libcap-bin (*1),

$ v=$(mktemp)
$ unshare -Ur setcap cap_sys_admin-eip $v
$ unshare -Ur setcap -v cap_sys_admin-eip $v
/tmp/tmp.lSiIFRvt8Y: OK

"setcap -v" verifies the values instead of setting them, and
will check whether the rootid value is set.  Therefore, with
this bug un-fixed, and with CONFIG_SECURITY=n, setcap -v will
fail:

$ v=$(mktemp)
$ unshare -Ur setcap cap_sys_admin=eip $v
$ unshare -Ur setcap -v cap_sys_admin=eip $v
nsowner[got=1000, want=0],/tmp/tmp.HHDiOOl9fY differs in []

Fix this bug by calling cap_inode_getsecurity() in
security_inode_getsecurity() instead of returning
-EOPNOTSUPP, when CONFIG_SECURITY=n.

*1 - note, if libcap is too old for getcap to have the '-n'
option, then use verify-caps instead.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209689
Cc: Hervé Guillemet 
Acked-by: Casey Schaufler 
Signed-off-by: Serge Hallyn 
Signed-off-by: Andrew G. Morgan 
Signed-off-by: James Morris 
Signed-off-by: Sasha Levin 
---
 include/linux/security.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index d2240605edc46..454cc963d1457 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -787,7 +787,7 @@ static inline int security_inode_killpriv(struct dentry 
*dentry)
 
 static inline int security_inode_getsecurity(struct inode *inode, const char 
*name, void **buffer, bool alloc)
 {
-   return -EOPNOTSUPP;
+   return cap_inode_getsecurity(inode, name, buffer, alloc);
 }
 
 static inline int security_inode_setsecurity(struct inode *inode, const char 
*name, const void *value, size_t size, int flags)
-- 
2.27.0

[PATCH AUTOSEL 5.9 07/15] net: stmmac: increase the timeout for dma reset

[Sasha Levin]

From: Fugang Duan 

[ Upstream commit 9d14edfdeabf37d8d8f045e63e5873712aadcd6b ]

Current timeout value is not enough for gmac5 dma reset
on imx8mp platform, increase the timeout range.

Signed-off-by: Fugang Duan 
Signed-off-by: Joakim Zhang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
index 6e30d7eb4983d..0b4ee2dbb691d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c
@@ -22,7 +22,7 @@ int dwmac4_dma_reset(void __iomem *ioaddr)
 
return readl_poll_timeout(ioaddr + DMA_BUS_MODE, value,
 !(value & DMA_BUS_MODE_SFT_RESET),
-1, 10);
+1, 100);
 }
 
 void dwmac4_set_rx_tail_ptr(void __iomem *ioaddr, u32 tail_ptr, u32 chan)
-- 
2.27.0

[PATCH AUTOSEL 4.19 1/6] ARM: sunxi: Add machine match for the Allwinner V3 SoC

[Sasha Levin]

From: Paul Kocialkowski 

[ Upstream commit ad2091f893bd5dfe2824f0d6819600d120698e9f ]

The Allwinner V3 SoC shares the same base as the V3s but comes with
extra pins and features available. As a result, it has its dedicated
compatible string (already used in device trees), which is added here.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20201031182137.1879521-2-cont...@paulk.fr
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-sunxi/sunxi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index de4b0e932f22e..aa08b8cb01524 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
"allwinner,sun8i-r40",
+   "allwinner,sun8i-v3",
"allwinner,sun8i-v3s",
NULL,
 };
-- 
2.27.0

[PATCH AUTOSEL 4.19 5/6] Input: cros_ec_keyb - send 'scancodes' in addition to key events

[Sasha Levin]

From: Dmitry Torokhov 

[ Upstream commit 80db2a087f425b63f0163bc95217abd01c637cb5 ]

To let userspace know what 'scancodes' should be used in EVIOCGKEYCODE
and EVIOCSKEYCODE ioctls, we should send EV_MSC/MSC_SCAN events in
addition to EV_KEY/KEY_* events. The driver already declared MSC_SCAN
capability, so it is only matter of actually sending the events.

Link: https://lore.kernel.org/r/x87aoasptptvz...@google.com
Acked-by: Rajat Jain 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/keyboard/cros_ec_keyb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
b/drivers/input/keyboard/cros_ec_keyb.c
index d560011815983..1edf0e8322ccc 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -183,6 +183,7 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
"changed: [r%d c%d]: byte %02x\n",
row, col, new_state);
 
+   input_event(idev, EV_MSC, MSC_SCAN, pos);
input_report_key(idev, keycodes[pos],
 new_state);
}
-- 
2.27.0

[PATCH AUTOSEL 5.9 12/15] selftests/bpf: Fix "dubious pointer arithmetic" test

[Sasha Levin]

From: Jean-Philippe Brucker 

[ Upstream commit 3615bdf6d9b19db12b1589861609b4f1c6a8d303 ]

The verifier trace changed following a bugfix. After checking the 64-bit
sign, only the upper bit mask is known, not bit 31. Update the test
accordingly.

Signed-off-by: Jean-Philippe Brucker 
Acked-by: John Fastabend 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/bpf/prog_tests/align.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/align.c 
b/tools/testing/selftests/bpf/prog_tests/align.c
index c548aded65859..2a15aa3d49c74 100644
--- a/tools/testing/selftests/bpf/prog_tests/align.c
+++ b/tools/testing/selftests/bpf/prog_tests/align.c
@@ -456,10 +456,10 @@ static struct bpf_align_test tests[] = {
 */
{7, 
"R5_w=inv(id=0,smin_value=-9223372036854775806,smax_value=9223372036854775806,umin_value=2,umax_value=18446744073709551614,var_off=(0x2;
 0xfffc)"},
/* Checked s>=0 */
-   {9, 
"R5=inv(id=0,umin_value=2,umax_value=9223372034707292158,var_off=(0x2; 
0x7fff7ffc)"},
+   {9, 
"R5=inv(id=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 
0x7ffc)"},
/* packet pointer + nonnegative (4n+2) */
-   {11, 
"R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372034707292158,var_off=(0x2;
 0x7fff7ffc)"},
-   {13, 
"R4_w=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372034707292158,var_off=(0x2;
 0x7fff7ffc)"},
+   {11, 
"R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2;
 0x7ffc)"},
+   {13, 
"R4_w=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2;
 0x7ffc)"},
/* NET_IP_ALIGN + (4n+2) == (4n), alignment is fine.
 * We checked the bounds, but it might have been able
 * to overflow if the packet pointer started in the
@@ -467,7 +467,7 @@ static struct bpf_align_test tests[] = {
 * So we did not get a 'range' on R6, and the access
 * attempt will fail.
 */
-   {15, 
"R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372034707292158,var_off=(0x2;
 0x7fff7ffc)"},
+   {15, 
"R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2;
 0x7ffc)"},
}
},
{
-- 
2.27.0

[PATCH AUTOSEL 5.9 05/15] [SECURITY] fix namespaced fscaps when !CONFIG_SECURITY

[Sasha Levin]

From: Serge Hallyn 

[ Upstream commit ed9b25d1970a4787ac6a39c2091e63b127ecbfc1 ]

Namespaced file capabilities were introduced in 8db6c34f1dbc .
When userspace reads an xattr for a namespaced capability, a
virtualized representation of it is returned if the caller is
in a user namespace owned by the capability's owning rootid.
The function which performs this virtualization was not hooked
up if CONFIG_SECURITY=n.  Therefore in that case the original
xattr was shown instead of the virtualized one.

To test this using libcap-bin (*1),

$ v=$(mktemp)
$ unshare -Ur setcap cap_sys_admin-eip $v
$ unshare -Ur setcap -v cap_sys_admin-eip $v
/tmp/tmp.lSiIFRvt8Y: OK

"setcap -v" verifies the values instead of setting them, and
will check whether the rootid value is set.  Therefore, with
this bug un-fixed, and with CONFIG_SECURITY=n, setcap -v will
fail:

$ v=$(mktemp)
$ unshare -Ur setcap cap_sys_admin=eip $v
$ unshare -Ur setcap -v cap_sys_admin=eip $v
nsowner[got=1000, want=0],/tmp/tmp.HHDiOOl9fY differs in []

Fix this bug by calling cap_inode_getsecurity() in
security_inode_getsecurity() instead of returning
-EOPNOTSUPP, when CONFIG_SECURITY=n.

*1 - note, if libcap is too old for getcap to have the '-n'
option, then use verify-caps instead.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209689
Cc: Hervé Guillemet 
Acked-by: Casey Schaufler 
Signed-off-by: Serge Hallyn 
Signed-off-by: Andrew G. Morgan 
Signed-off-by: James Morris 
Signed-off-by: Sasha Levin 
---
 include/linux/security.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index 0a0a03b36a3bb..2befc0a25eb37 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -864,7 +864,7 @@ static inline int security_inode_killpriv(struct dentry 
*dentry)
 
 static inline int security_inode_getsecurity(struct inode *inode, const char 
*name, void **buffer, bool alloc)
 {
-   return -EOPNOTSUPP;
+   return cap_inode_getsecurity(inode, name, buffer, alloc);
 }
 
 static inline int security_inode_setsecurity(struct inode *inode, const char 
*name, const void *value, size_t size, int flags)
-- 
2.27.0

[PATCH AUTOSEL 5.9 14/15] elfcore: fix building with clang

[Sasha Levin]

From: Arnd Bergmann 

[ Upstream commit 6e7b64b9dd6d96537d816ea07ec26b7dedd397b9 ]

kernel/elfcore.c only contains weak symbols, which triggers a bug with
clang in combination with recordmcount:

  Cannot find symbol for section 2: .text.
  kernel/elfcore.o: failed

Move the empty stubs into linux/elfcore.h as inline functions.  As only
two architectures use these, just use the architecture specific Kconfig
symbols to key off the declaration.

Link: https://lkml.kernel.org/r/20201204165742.3815221-2-a...@kernel.org
Signed-off-by: Arnd Bergmann 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Barret Rhoden 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 include/linux/elfcore.h | 22 ++
 kernel/Makefile |  1 -
 kernel/elfcore.c| 26 --
 3 files changed, 22 insertions(+), 27 deletions(-)
 delete mode 100644 kernel/elfcore.c

diff --git a/include/linux/elfcore.h b/include/linux/elfcore.h
index 46c3d691f6776..de51c1bef27da 100644
--- a/include/linux/elfcore.h
+++ b/include/linux/elfcore.h
@@ -104,6 +104,7 @@ static inline int elf_core_copy_task_fpregs(struct 
task_struct *t, struct pt_reg
 #endif
 }
 
+#if defined(CONFIG_UM) || defined(CONFIG_IA64)
 /*
  * These functions parameterize elf_core_dump in fs/binfmt_elf.c to write out
  * extra segments containing the gate DSO contents.  Dumping its
@@ -118,5 +119,26 @@ elf_core_write_extra_phdrs(struct coredump_params *cprm, 
loff_t offset);
 extern int
 elf_core_write_extra_data(struct coredump_params *cprm);
 extern size_t elf_core_extra_data_size(void);
+#else
+static inline Elf_Half elf_core_extra_phdrs(void)
+{
+   return 0;
+}
+
+static inline int elf_core_write_extra_phdrs(struct coredump_params *cprm, 
loff_t offset)
+{
+   return 1;
+}
+
+static inline int elf_core_write_extra_data(struct coredump_params *cprm)
+{
+   return 1;
+}
+
+static inline size_t elf_core_extra_data_size(void)
+{
+   return 0;
+}
+#endif
 
 #endif /* _LINUX_ELFCORE_H */
diff --git a/kernel/Makefile b/kernel/Makefile
index 9a20016d4900d..55e25e1739a31 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -100,7 +100,6 @@ obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
 obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o
 obj-$(CONFIG_TRACEPOINTS) += tracepoint.o
 obj-$(CONFIG_LATENCYTOP) += latencytop.o
-obj-$(CONFIG_ELFCORE) += elfcore.o
 obj-$(CONFIG_FUNCTION_TRACER) += trace/
 obj-$(CONFIG_TRACING) += trace/
 obj-$(CONFIG_TRACE_CLOCK) += trace/
diff --git a/kernel/elfcore.c b/kernel/elfcore.c
deleted file mode 100644
index 57fb4dcff4349..0
--- a/kernel/elfcore.c
+++ /dev/null
@@ -1,26 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include 
-#include 
-#include 
-#include 
-#include 
-
-Elf_Half __weak elf_core_extra_phdrs(void)
-{
-   return 0;
-}
-
-int __weak elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t 
offset)
-{
-   return 1;
-}
-
-int __weak elf_core_write_extra_data(struct coredump_params *cprm)
-{
-   return 1;
-}
-
-size_t __weak elf_core_extra_data_size(void)
-{
-   return 0;
-}
-- 
2.27.0

[PATCH AUTOSEL 5.9 04/15] ethernet: select CONFIG_CRC32 as needed

[Sasha Levin]

From: Arnd Bergmann 

[ Upstream commit 0b32e91fdfd87314af9943e69eb85a88adb4233c ]

A number of ethernet drivers require crc32 functionality to be
avaialable in the kernel, causing a link error otherwise:

arm-linux-gnueabi-ld: drivers/net/ethernet/agere/et131x.o: in function 
`et1310_setup_device_for_multicast':
et131x.c:(.text+0x5918): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/ethernet/cadence/macb_main.o: in function 
`macb_start_xmit':
macb_main.c:(.text+0x4b88): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/ethernet/faraday/ftgmac100.o: in function 
`ftgmac100_set_rx_mode':
ftgmac100.c:(.text+0x2b38): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/ethernet/freescale/fec_main.o: in function 
`set_multicast_list':
fec_main.c:(.text+0x6120): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/ethernet/freescale/fman/fman_dtsec.o: in 
function `dtsec_add_hash_mac_address':
fman_dtsec.c:(.text+0x830): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: 
drivers/net/ethernet/freescale/fman/fman_dtsec.o:fman_dtsec.c:(.text+0xb68): 
more undefined references to `crc32_le' follow
arm-linux-gnueabi-ld: drivers/net/ethernet/netronome/nfp/nfpcore/nfp_hwinfo.o: 
in function `nfp_hwinfo_read':
nfp_hwinfo.c:(.text+0x250): undefined reference to `crc32_be'
arm-linux-gnueabi-ld: nfp_hwinfo.c:(.text+0x288): undefined reference to 
`crc32_be'
arm-linux-gnueabi-ld: 
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.o: in function 
`nfp_resource_acquire':
nfp_resource.c:(.text+0x144): undefined reference to `crc32_be'
arm-linux-gnueabi-ld: nfp_resource.c:(.text+0x158): undefined reference to 
`crc32_be'
arm-linux-gnueabi-ld: drivers/net/ethernet/nxp/lpc_eth.o: in function 
`lpc_eth_set_multicast_list':
lpc_eth.c:(.text+0x1934): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/ethernet/rocker/rocker_ofdpa.o: in function 
`ofdpa_flow_tbl_do':
rocker_ofdpa.c:(.text+0x2e08): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/ethernet/rocker/rocker_ofdpa.o: in function 
`ofdpa_flow_tbl_del':
rocker_ofdpa.c:(.text+0x3074): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/ethernet/rocker/rocker_ofdpa.o: in function 
`ofdpa_port_fdb':
arm-linux-gnueabi-ld: 
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_ste.o: in function 
`mlx5dr_ste_calc_hash_index':
dr_ste.c:(.text+0x354): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/net/ethernet/microchip/lan743x_main.o: in 
function `lan743x_netdev_set_multicast':
lan743x_main.c:(.text+0x5dc4): undefined reference to `crc32_le'

Add the missing 'select CRC32' entries in Kconfig for each of them.

Signed-off-by: Arnd Bergmann 
Acked-by: Nicolas Ferre 
Acked-by: Madalin Bucur 
Acked-by: Mark Einon 
Acked-by: Simon Horman 
Link: https://lore.kernel.org/r/20201203232114.1485603-1-a...@kernel.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/agere/Kconfig  | 1 +
 drivers/net/ethernet/cadence/Kconfig| 1 +
 drivers/net/ethernet/faraday/Kconfig| 1 +
 drivers/net/ethernet/freescale/Kconfig  | 1 +
 drivers/net/ethernet/freescale/fman/Kconfig | 1 +
 drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
 drivers/net/ethernet/microchip/Kconfig  | 1 +
 drivers/net/ethernet/netronome/Kconfig  | 1 +
 drivers/net/ethernet/nxp/Kconfig| 1 +
 drivers/net/ethernet/rocker/Kconfig | 1 +
 10 files changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/agere/Kconfig 
b/drivers/net/ethernet/agere/Kconfig
index d92516ae59cc7..9cd750184947c 100644
--- a/drivers/net/ethernet/agere/Kconfig
+++ b/drivers/net/ethernet/agere/Kconfig
@@ -21,6 +21,7 @@ config ET131X
tristate "Agere ET-1310 Gigabit Ethernet support"
depends on PCI
select PHYLIB
+   select CRC32
help
  This driver supports Agere ET-1310 ethernet adapters.
 
diff --git a/drivers/net/ethernet/cadence/Kconfig 
b/drivers/net/ethernet/cadence/Kconfig
index 85858163bac5d..e432a68ac5201 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -23,6 +23,7 @@ config MACB
tristate "Cadence MACB/GEM support"
depends on HAS_DMA && COMMON_CLK
select PHYLINK
+   select CRC32
help
  The Cadence MACB ethernet interface is found on many Atmel AT32 and
  AT91 parts.  This driver also supports the Cadence GEM (Gigabit
diff --git a/drivers/net/ethernet/faraday/Kconfig 
b/drivers/net/ethernet/faraday/Kconfig
index c2677ec0564d0..3d1e9a302148a 100644
--- a/drivers/net/ethernet/faraday/Kconfig
+++ b/drivers/net/ethernet/faraday/Kconfig
@@ -33,6 +33,7 @@ config FTGMAC100
depends on !64BIT || BROKEN
select PHYLIB
select MDIO_ASPEED if MACH_ASPEED_G6
+   select CRC32
help
  This driver supports the 

[PATCH AUTOSEL 5.9 01/15] ARM: sunxi: Add machine match for the Allwinner V3 SoC

[Sasha Levin]

From: Paul Kocialkowski 

[ Upstream commit ad2091f893bd5dfe2824f0d6819600d120698e9f ]

The Allwinner V3 SoC shares the same base as the V3s but comes with
extra pins and features available. As a result, it has its dedicated
compatible string (already used in device trees), which is added here.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20201031182137.1879521-2-cont...@paulk.fr
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-sunxi/sunxi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 06da2747a90bc..19635721013d8 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
"allwinner,sun8i-r40",
+   "allwinner,sun8i-v3",
"allwinner,sun8i-v3s",
NULL,
 };
-- 
2.27.0

[PATCH AUTOSEL 5.9 02/15] pNFS/flexfiles: Fix array overflow when flexfiles mirroring is enabled

[Sasha Levin]

From: Trond Myklebust 

[ Upstream commit 63e2fffa59a9dd91e443b08832656399fd80b7f0 ]

If the flexfiles mirroring is enabled, then the read code expects to be
able to set pgio->pg_mirror_idx to point to the data server that is
being used for this particular read. However it does not change the
pg_mirror_count because we only need to send a single read.

Signed-off-by: Trond Myklebust 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/flexfilelayout/flexfilelayout.c | 27 ++-
 fs/nfs/pagelist.c  | 36 +++---
 include/linux/nfs_page.h   |  4 +++
 3 files changed, 52 insertions(+), 15 deletions(-)

diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c 
b/fs/nfs/flexfilelayout/flexfilelayout.c
index a163533446fa3..24bf5797f88ae 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -838,7 +838,7 @@ ff_layout_pg_init_read(struct nfs_pageio_descriptor *pgio,
struct nfs_pgio_mirror *pgm;
struct nfs4_ff_layout_mirror *mirror;
struct nfs4_pnfs_ds *ds;
-   u32 ds_idx, i;
+   u32 ds_idx;
 
 retry:
ff_layout_pg_check_layout(pgio, req);
@@ -864,11 +864,9 @@ ff_layout_pg_init_read(struct nfs_pageio_descriptor *pgio,
goto retry;
}
 
-   for (i = 0; i < pgio->pg_mirror_count; i++) {
-   mirror = FF_LAYOUT_COMP(pgio->pg_lseg, i);
-   pgm = >pg_mirrors[i];
-   pgm->pg_bsize = mirror->mirror_ds->ds_versions[0].rsize;
-   }
+   mirror = FF_LAYOUT_COMP(pgio->pg_lseg, ds_idx);
+   pgm = >pg_mirrors[0];
+   pgm->pg_bsize = mirror->mirror_ds->ds_versions[0].rsize;
 
pgio->pg_mirror_idx = ds_idx;
 
@@ -985,6 +983,21 @@ ff_layout_pg_get_mirror_count_write(struct 
nfs_pageio_descriptor *pgio,
return 1;
 }
 
+static u32
+ff_layout_pg_set_mirror_write(struct nfs_pageio_descriptor *desc, u32 idx)
+{
+   u32 old = desc->pg_mirror_idx;
+
+   desc->pg_mirror_idx = idx;
+   return old;
+}
+
+static struct nfs_pgio_mirror *
+ff_layout_pg_get_mirror_write(struct nfs_pageio_descriptor *desc, u32 idx)
+{
+   return >pg_mirrors[idx];
+}
+
 static const struct nfs_pageio_ops ff_layout_pg_read_ops = {
.pg_init = ff_layout_pg_init_read,
.pg_test = pnfs_generic_pg_test,
@@ -998,6 +1011,8 @@ static const struct nfs_pageio_ops ff_layout_pg_write_ops 
= {
.pg_doio = pnfs_generic_pg_writepages,
.pg_get_mirror_count = ff_layout_pg_get_mirror_count_write,
.pg_cleanup = pnfs_generic_pg_cleanup,
+   .pg_get_mirror = ff_layout_pg_get_mirror_write,
+   .pg_set_mirror = ff_layout_pg_set_mirror_write,
 };
 
 static void ff_layout_reset_write(struct nfs_pgio_header *hdr, bool retry_pnfs)
diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
index 6985cacf4700d..78c9c4bdef2b6 100644
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -31,13 +31,29 @@
 static struct kmem_cache *nfs_page_cachep;
 static const struct rpc_call_ops nfs_pgio_common_ops;
 
+static struct nfs_pgio_mirror *
+nfs_pgio_get_mirror(struct nfs_pageio_descriptor *desc, u32 idx)
+{
+   if (desc->pg_ops->pg_get_mirror)
+   return desc->pg_ops->pg_get_mirror(desc, idx);
+   return >pg_mirrors[0];
+}
+
 struct nfs_pgio_mirror *
 nfs_pgio_current_mirror(struct nfs_pageio_descriptor *desc)
 {
-   return >pg_mirrors[desc->pg_mirror_idx];
+   return nfs_pgio_get_mirror(desc, desc->pg_mirror_idx);
 }
 EXPORT_SYMBOL_GPL(nfs_pgio_current_mirror);
 
+static u32
+nfs_pgio_set_current_mirror(struct nfs_pageio_descriptor *desc, u32 idx)
+{
+   if (desc->pg_ops->pg_set_mirror)
+   return desc->pg_ops->pg_set_mirror(desc, idx);
+   return desc->pg_mirror_idx;
+}
+
 void nfs_pgheader_init(struct nfs_pageio_descriptor *desc,
   struct nfs_pgio_header *hdr,
   void (*release)(struct nfs_pgio_header *hdr))
@@ -1259,7 +1275,7 @@ static void nfs_pageio_error_cleanup(struct 
nfs_pageio_descriptor *desc)
return;
 
for (midx = 0; midx < desc->pg_mirror_count; midx++) {
-   mirror = >pg_mirrors[midx];
+   mirror = nfs_pgio_get_mirror(desc, midx);
desc->pg_completion_ops->error_cleanup(>pg_list,
desc->pg_error);
}
@@ -1293,12 +1309,12 @@ int nfs_pageio_add_request(struct nfs_pageio_descriptor 
*desc,
goto out_failed;
}
 
-   desc->pg_mirror_idx = midx;
+   nfs_pgio_set_current_mirror(desc, midx);
if (!nfs_pageio_add_request_mirror(desc, dupreq))
goto out_cleanup_subreq;
}
 
-   desc->pg_mirror_idx = 0;
+   nfs_pgio_set_current_mirror(desc, 0);
if (!nfs_pageio_add_request_mirror(desc, req))
goto out_failed;
 
@@ -1320,10 +1336,12 @@ int nfs_pageio_add_request(struct 

[PATCH AUTOSEL 5.9 03/15] cfg80211: initialize rekey_data

[Sasha Levin]

From: Sara Sharon 

[ Upstream commit f495acd8851d7b345e5f0e521b2645b1e1f928a0 ]

In case we have old supplicant, the akm field is uninitialized.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Link: 
https://lore.kernel.org/r/iwlwifi.20201129172929.930f0ab7ebee.Ic546e384efab3f4a89f318eafddc3eb7d556aecb@changeid
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8eb43c47e582a..c37b4ba7d817b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -12348,7 +12348,7 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, 
struct genl_info *info)
struct net_device *dev = info->user_ptr[1];
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct nlattr *tb[NUM_NL80211_REKEY_DATA];
-   struct cfg80211_gtk_rekey_data rekey_data;
+   struct cfg80211_gtk_rekey_data rekey_data = {};
int err;
 
if (!info->attrs[NL80211_ATTR_REKEY_DATA])
-- 
2.27.0

Re: [PATCH 5.10 00/16] 5.10.2-rc1 review

[Naresh Kamboju]

On Sat, 19 Dec 2020 at 18:26, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.10.2 release.
> There are 16 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Mon, 21 Dec 2020 12:53:29 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.2-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.10.2-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.10.y
git commit: c96cfd687a3f1d1d461dd4a73eb51410c4fd45d8
git describe: v5.10.1-17-gc96cfd687a3f
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.1-17-gc96cfd687a3f

No regressions (compared to build v5.10.1)

No fixes (compared to build v5.10.1)

Ran 51496 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* fwts
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 2/4] hung_task: Replace "did_panic" with is_be_panic()

[Xiaoming Ni]

On 2020/12/19 1:06, Randy Dunlap wrote:

On 12/18/20 6:36 AM, Tetsuo Handa wrote:

On 2020/12/18 21:59, Pavel Machek wrote:

On Fri 2020-12-18 19:44:04, Xiaoming Ni wrote:
Plus.. is_being_panic is not really english. "is_paniccing" would be
closer...?


Or in_panic() ?



Yes, or  in_panic_state()



Thank you,
I'll resend the patch later on according to your suggestion.

Thanks
Xiaoming Ni
.

Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect

[Andrea Arcangeli]

On Sat, Dec 19, 2020 at 06:01:39PM -0800, Andy Lutomirski wrote:
> I missed the beginning of this thread, but it looks to me like
> userfaultfd changes PTEs with not locking except mmap_read_lock().  It

There's no mmap_read_lock, I assume you mean mmap_lock for reading.

The ptes are changed always with the PT lock, in fact there's no
problem with the PTE updates. The only difference with mprotect
runtime is that the mmap_lock is taken for reading. And the effect
contested for this change doesn't affect the PTE, but supposedly the
tlb flushing deferral.

The change_protection_range is identical to what already happens with
zap_page_range. zap_page_range is called with mmap_lock for reading
in MADV_DONTNEED, and by munmap with mmap_lock for
writing. change_protection_range is called with mmap_lock for writing
by mprotect, and mmap_lock for reading by UFFDIO_WRITEPROTECT.

> also calls inc_tlb_flush_pending(), which is very explicitly
> documented as requiring the pagetable lock.  Those docs must be wrong,

The comment in inc_tlb_flush_pending() shows the pagetable lock is
taken after inc_tlb_flush_pending():

 *  atomic_inc(>tlb_flush_pending);
 *  spin_lock();

> because mprotect() uses the mmap_sem write lock, which is just fine,
> but ISTM some kind of mutual exclusion with proper acquire/release
> ordering is indeed needed.  So the userfaultfd code seems bogus.

If there's a bug, it'd be nice to fix without taking the mmap_lock for
writing.

The vma is guaranteed not modified, so I think it'd be pretty bad if
we had to give in the mmap_lock for writing just to wait for a tlb
flush that is issued deferred in the context of
userfaultfd_writeprotect.

> I think userfaultfd either needs to take a real lock (probably doesn't
> matter which) or the core rules about PTEs need to be rewritten.

It's not exactly clear how the do_wp_page could run on cpu1 before the
unprotect did an extra flush, I guess the trace needs one more
cpu/thread?

Anyway to wait the wrprotect to do the deferred flush, before the
unprotect can even start, one more mutex in the mm to take in all
callers of change_protection_range with the mmap_lock for reading may
be enough.

Thanks,
Andrea

[PATCH 2/5] drm/mediatek: Rename file mtk_drm_ddp to mtk_mutex

[Chun-Kuang Hu]

From: CK Hu 

After mmsys routing function is moved out of mtk_drm_ddp.c, mtk_drm_ddp.c
has only mtk mutex function, so rename it to match the function in it.

Signed-off-by: CK Hu 
Signed-off-by: Chun-Kuang Hu 
---
 drivers/gpu/drm/mediatek/Makefile   | 4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
 drivers/gpu/drm/mediatek/{mtk_drm_ddp.c => mtk_mutex.c} | 0
 drivers/gpu/drm/mediatek/{mtk_drm_ddp.h => mtk_mutex.h} | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)
 rename drivers/gpu/drm/mediatek/{mtk_drm_ddp.c => mtk_mutex.c} (100%)
 rename drivers/gpu/drm/mediatek/{mtk_drm_ddp.h => mtk_mutex.h} (92%)

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index a892edec5563..09979c4c340a 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -4,13 +4,13 @@ mediatek-drm-y := mtk_disp_color.o \
  mtk_disp_ovl.o \
  mtk_disp_rdma.o \
  mtk_drm_crtc.o \
- mtk_drm_ddp.o \
  mtk_drm_ddp_comp.o \
  mtk_drm_drv.o \
  mtk_drm_gem.o \
  mtk_drm_plane.o \
  mtk_dsi.o \
- mtk_dpi.o
+ mtk_dpi.o \
+ mtk_mutex.o
 
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index bdd37eadecd5..1e827de1427d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -19,10 +19,10 @@
 
 #include "mtk_drm_drv.h"
 #include "mtk_drm_crtc.h"
-#include "mtk_drm_ddp.h"
 #include "mtk_drm_ddp_comp.h"
 #include "mtk_drm_gem.h"
 #include "mtk_drm_plane.h"
+#include "mtk_mutex.h"
 
 /*
  * struct mtk_drm_crtc - MediaTek specific crtc structure.
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_mutex.c
similarity index 100%
rename from drivers/gpu/drm/mediatek/mtk_drm_ddp.c
rename to drivers/gpu/drm/mediatek/mtk_mutex.c
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h 
b/drivers/gpu/drm/mediatek/mtk_mutex.h
similarity index 92%
rename from drivers/gpu/drm/mediatek/mtk_drm_ddp.h
rename to drivers/gpu/drm/mediatek/mtk_mutex.h
index a1ee21d15334..3abcc20e88fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
+++ b/drivers/gpu/drm/mediatek/mtk_mutex.h
@@ -3,8 +3,8 @@
  * Copyright (c) 2015 MediaTek Inc.
  */
 
-#ifndef MTK_DRM_DDP_H
-#define MTK_DRM_DDP_H
+#ifndef MTK_MUTEX_H
+#define MTK_MUTEX_H
 
 struct regmap;
 struct device;
@@ -23,4 +23,4 @@ void mtk_disp_mutex_put(struct mtk_disp_mutex *mutex);
 void mtk_disp_mutex_acquire(struct mtk_disp_mutex *mutex);
 void mtk_disp_mutex_release(struct mtk_disp_mutex *mutex);
 
-#endif /* MTK_DRM_DDP_H */
+#endif /* MTK_MUTEX_H */
-- 
2.17.1

[PATCH 5/5] soc / drm: mediatek: Move mtk mutex driver to soc folder

[Chun-Kuang Hu]

From: CK Hu 

mtk mutex is used by DRM and MDP driver, and its function is SoC-specific,
so move it to soc folder.

Signed-off-by: CK Hu 
Signed-off-by: Chun-Kuang Hu 
---
 drivers/gpu/drm/mediatek/Makefile  | 3 +--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 2 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
 drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 -
 drivers/soc/mediatek/Makefile  | 1 +
 .../{gpu/drm/mediatek/mtk_mutex.c => soc/mediatek/mtk-mutex.c} | 2 ++
 .../mtk_mutex.h => include/linux/soc/mediatek/mtk-mutex.h  | 0
 7 files changed, 5 insertions(+), 5 deletions(-)
 rename drivers/{gpu/drm/mediatek/mtk_mutex.c => soc/mediatek/mtk-mutex.c} (99%)
 rename drivers/gpu/drm/mediatek/mtk_mutex.h => 
include/linux/soc/mediatek/mtk-mutex.h (100%)

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index 09979c4c340a..01d06332f767 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -9,8 +9,7 @@ mediatek-drm-y := mtk_disp_color.o \
  mtk_drm_gem.o \
  mtk_drm_plane.o \
  mtk_dsi.o \
- mtk_dpi.o \
- mtk_mutex.o
+ mtk_dpi.o
 
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 23d9abc4f46c..d7bd07916d74 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -22,7 +23,6 @@
 #include "mtk_drm_ddp_comp.h"
 #include "mtk_drm_gem.h"
 #include "mtk_drm_plane.h"
-#include "mtk_mutex.h"
 
 /*
  * struct mtk_drm_crtc - MediaTek specific crtc structure.
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 907a69eb6d51..d1232124b650 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -602,7 +602,6 @@ static struct platform_driver mtk_drm_platform_driver = {
 };
 
 static struct platform_driver * const mtk_drm_drivers[] = {
-   _mutex_driver,
_disp_color_driver,
_disp_ovl_driver,
_disp_rdma_driver,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index c7220f267a62..f7cd95903a4e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -46,7 +46,6 @@ struct mtk_drm_private {
struct drm_atomic_state *suspend_state;
 };
 
-extern struct platform_driver mtk_mutex_driver;
 extern struct platform_driver mtk_disp_color_driver;
 extern struct platform_driver mtk_disp_ovl_driver;
 extern struct platform_driver mtk_disp_rdma_driver;
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index b6908db534c2..90270f8114ed 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
 obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
+obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
diff --git a/drivers/gpu/drm/mediatek/mtk_mutex.c 
b/drivers/soc/mediatek/mtk-mutex.c
similarity index 99%
rename from drivers/gpu/drm/mediatek/mtk_mutex.c
rename to drivers/soc/mediatek/mtk-mutex.c
index e16b1772317c..f2597ebf52db 100644
--- a/drivers/gpu/drm/mediatek/mtk_mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -459,3 +459,5 @@ struct platform_driver mtk_mutex_driver = {
.of_match_table = mutex_driver_dt_match,
},
 };
+
+builtin_platform_driver(mtk_mutex_driver);
diff --git a/drivers/gpu/drm/mediatek/mtk_mutex.h 
b/include/linux/soc/mediatek/mtk-mutex.h
similarity index 100%
rename from drivers/gpu/drm/mediatek/mtk_mutex.h
rename to include/linux/soc/mediatek/mtk-mutex.h
-- 
2.17.1

[PATCH 3/5] drm/mediatek: Change disp/ddp term to mutex in mtk mutex driver

[Chun-Kuang Hu]

From: CK Hu 

mtk mutex is used by both drm and mdp driver, so change disp/ddp term to
mutex to show that it's a common driver for drm and mdp.

Signed-off-by: CK Hu 
Signed-off-by: Chun-Kuang Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  30 +--
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   2 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   2 +-
 drivers/gpu/drm/mediatek/mtk_mutex.c| 306 
 drivers/gpu/drm/mediatek/mtk_mutex.h|  26 +-
 5 files changed, 182 insertions(+), 184 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 1e827de1427d..5c4e8e2f4448 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -55,7 +55,7 @@ struct mtk_drm_crtc {
 #endif
 
struct device   *mmsys_dev;
-   struct mtk_disp_mutex   *mutex;
+   struct mtk_mutex*mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
 
@@ -107,7 +107,7 @@ static void mtk_drm_crtc_destroy(struct drm_crtc *crtc)
 {
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
 
-   mtk_disp_mutex_put(mtk_crtc->mutex);
+   mtk_mutex_put(mtk_crtc->mutex);
 
drm_crtc_cleanup(crtc);
 }
@@ -283,7 +283,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
return ret;
}
 
-   ret = mtk_disp_mutex_prepare(mtk_crtc->mutex);
+   ret = mtk_mutex_prepare(mtk_crtc->mutex);
if (ret < 0) {
DRM_ERROR("Failed to enable mutex clock: %d\n", ret);
goto err_pm_runtime_put;
@@ -299,11 +299,11 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
  mtk_crtc->ddp_comp[i]->id,
  mtk_crtc->ddp_comp[i + 1]->id);
-   mtk_disp_mutex_add_comp(mtk_crtc->mutex,
+   mtk_mutex_add_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
-   mtk_disp_mutex_add_comp(mtk_crtc->mutex, mtk_crtc->ddp_comp[i]->id);
-   mtk_disp_mutex_enable(mtk_crtc->mutex);
+   mtk_mutex_add_comp(mtk_crtc->mutex, mtk_crtc->ddp_comp[i]->id);
+   mtk_mutex_enable(mtk_crtc->mutex);
 
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
@@ -332,7 +332,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
return 0;
 
 err_mutex_unprepare:
-   mtk_disp_mutex_unprepare(mtk_crtc->mutex);
+   mtk_mutex_unprepare(mtk_crtc->mutex);
 err_pm_runtime_put:
pm_runtime_put(crtc->dev->dev);
return ret;
@@ -351,19 +351,19 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc 
*mtk_crtc)
}
 
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
-   mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
+   mtk_mutex_remove_comp(mtk_crtc->mutex,
   mtk_crtc->ddp_comp[i]->id);
-   mtk_disp_mutex_disable(mtk_crtc->mutex);
+   mtk_mutex_disable(mtk_crtc->mutex);
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
 mtk_crtc->ddp_comp[i]->id,
 mtk_crtc->ddp_comp[i + 1]->id);
-   mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
+   mtk_mutex_remove_comp(mtk_crtc->mutex,
   mtk_crtc->ddp_comp[i]->id);
}
-   mtk_disp_mutex_remove_comp(mtk_crtc->mutex, mtk_crtc->ddp_comp[i]->id);
+   mtk_mutex_remove_comp(mtk_crtc->mutex, mtk_crtc->ddp_comp[i]->id);
mtk_crtc_ddp_clk_disable(mtk_crtc);
-   mtk_disp_mutex_unprepare(mtk_crtc->mutex);
+   mtk_mutex_unprepare(mtk_crtc->mutex);
 
pm_runtime_put(drm->dev);
 
@@ -475,9 +475,9 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
*mtk_crtc)
mtk_crtc->pending_async_planes = true;
 
if (priv->data->shadow_register) {
-   mtk_disp_mutex_acquire(mtk_crtc->mutex);
+   mtk_mutex_acquire(mtk_crtc->mutex);
mtk_crtc_ddp_config(crtc, NULL);
-   mtk_disp_mutex_release(mtk_crtc->mutex);
+   mtk_mutex_release(mtk_crtc->mutex);
}
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
if (mtk_crtc->cmdq_client) {
@@ -772,7 +772,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (!mtk_crtc->ddp_comp)
return -ENOMEM;
 
-   mtk_crtc->mutex = mtk_disp_mutex_get(priv->mutex_dev, pipe);
+   mtk_crtc->mutex = mtk_mutex_get(priv->mutex_dev, pipe);
if (IS_ERR(mtk_crtc->mutex)) {
ret = PTR_ERR(mtk_crtc->mutex);
dev_err(dev, "Failed to get mutex: %d\n", 

[PATCH 1/5] drm/mediatek: Remove redundant file including

[Chun-Kuang Hu]

From: CK Hu 

Those file includings are useless, so remove them.

Signed-off-by: CK Hu 
Signed-off-by: Chun-Kuang Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 1 -
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 2 --
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 --
 3 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 1f99db6b1a42..ab7295c51b23 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 
-#include "mtk_drm_ddp.h"
 #include "mtk_drm_ddp_comp.h"
 
 #define MT2701_DISP_MUTEX0_MOD00x2c
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
index 6b691a57be4a..a1ee21d15334 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
@@ -6,8 +6,6 @@
 #ifndef MTK_DRM_DDP_H
 #define MTK_DRM_DDP_H
 
-#include "mtk_drm_ddp_comp.h"
-
 struct regmap;
 struct device;
 struct mtk_disp_mutex;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 2f717df28a77..089f956b22c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -26,7 +25,6 @@
 #include 
 
 #include "mtk_drm_crtc.h"
-#include "mtk_drm_ddp.h"
 #include "mtk_drm_ddp_comp.h"
 #include "mtk_drm_drv.h"
 #include "mtk_drm_gem.h"
-- 
2.17.1

[PATCH 4/5] drm/mediatek: Automatically search unclaimed mtk mutex in mtk_mutex_get()

[Chun-Kuang Hu]

From: CK Hu 

Moving mutex resource management from client driver to  mutex driver
could prevent client drivers negotiating for resource management.

Signed-off-by: CK Hu 
Signed-off-by: Chun-Kuang Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  2 +-
 drivers/gpu/drm/mediatek/mtk_mutex.c| 16 
 drivers/gpu/drm/mediatek/mtk_mutex.h|  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 5c4e8e2f4448..23d9abc4f46c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -772,7 +772,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (!mtk_crtc->ddp_comp)
return -ENOMEM;
 
-   mtk_crtc->mutex = mtk_mutex_get(priv->mutex_dev, pipe);
+   mtk_crtc->mutex = mtk_mutex_get(priv->mutex_dev);
if (IS_ERR(mtk_crtc->mutex)) {
ret = PTR_ERR(mtk_crtc->mutex);
dev_err(dev, "Failed to get mutex: %d\n", ret);
diff --git a/drivers/gpu/drm/mediatek/mtk_mutex.c 
b/drivers/gpu/drm/mediatek/mtk_mutex.c
index ece26359a292..e16b1772317c 100644
--- a/drivers/gpu/drm/mediatek/mtk_mutex.c
+++ b/drivers/gpu/drm/mediatek/mtk_mutex.c
@@ -226,18 +226,18 @@ static const struct mtk_mutex_data 
mt8173_mutex_driver_data = {
.mutex_sof_reg = MT2701_MUTEX0_SOF0,
 };
 
-struct mtk_mutex *mtk_mutex_get(struct device *dev, unsigned int id)
+struct mtk_mutex *mtk_mutex_get(struct device *dev)
 {
struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
+   int i;
 
-   if (id >= 10)
-   return ERR_PTR(-EINVAL);
-   if (mtx->mutex[id].claimed)
-   return ERR_PTR(-EBUSY);
-
-   mtx->mutex[id].claimed = true;
+   for (i = 0; i < 10; i++)
+   if (!mtx->mutex[i].claimed) {
+   mtx->mutex[i].claimed = true;
+   return >mutex[i];
+   }
 
-   return >mutex[id];
+   return ERR_PTR(-EBUSY);
 }
 
 void mtk_mutex_put(struct mtk_mutex *mutex)
diff --git a/drivers/gpu/drm/mediatek/mtk_mutex.h 
b/drivers/gpu/drm/mediatek/mtk_mutex.h
index b678e0988a37..6fe4ffbde290 100644
--- a/drivers/gpu/drm/mediatek/mtk_mutex.h
+++ b/drivers/gpu/drm/mediatek/mtk_mutex.h
@@ -10,7 +10,7 @@ struct regmap;
 struct device;
 struct mtk_mutex;
 
-struct mtk_mutex *mtk_mutex_get(struct device *dev, unsigned int id);
+struct mtk_mutex *mtk_mutex_get(struct device *dev);
 int mtk_mutex_prepare(struct mtk_mutex *mutex);
 void mtk_mutex_add_comp(struct mtk_mutex *mutex,
enum mtk_ddp_comp_id id);
-- 
2.17.1

[PATCH 0/5] Share mtk mutex driver for both DRM and MDP

[Chun-Kuang Hu]

mtk mutex is a driver used by DRM and MDP [1], so this series move
mtk mutex driver from DRM folder to soc folder, so it could be used
by DRM and MDP.

This series based on linux-next next-20201218 [2]

[1] https://patchwork.kernel.org/patch/11140751/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=next-20201218

CK Hu (5):
  drm/mediatek: Remove redundant file including
  drm/mediatek: Rename file mtk_drm_ddp to mtk_mutex
  drm/mediatek: Change disp/ddp term to mutex in mtk mutex driver
  drm/mediatek: Automatically search unclaimed mtk mutex in
mtk_mutex_get()
  soc / drm: mediatek: Move mtk mutex driver to soc folder

 drivers/gpu/drm/mediatek/Makefile |   1 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |  32 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h|  28 --
 drivers/gpu/drm/mediatek/mtk_drm_drv.c|   3 -
 drivers/gpu/drm/mediatek/mtk_drm_drv.h|   1 -
 drivers/soc/mediatek/Makefile |   1 +
 .../mediatek/mtk-mutex.c} | 317 +-
 include/linux/soc/mediatek/mtk-mutex.h|  26 ++
 8 files changed, 201 insertions(+), 208 deletions(-)
 delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h
 rename drivers/{gpu/drm/mediatek/mtk_drm_ddp.c => soc/mediatek/mtk-mutex.c} 
(54%)
 create mode 100644 include/linux/soc/mediatek/mtk-mutex.h

-- 
2.17.1

WARNING: suspicious RCU usage in wiphy_apply_custom_regulatory

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:d635a69d Merge tag 'net-next-5.11' of git://git.kernel.org..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14502c1350
kernel config:  https://syzkaller.appspot.com/x/.config?x=c3556e4856b17a95
dashboard link: https://syzkaller.appspot.com/bug?extid=27771d4abcd9b7a1f5d3
compiler:   clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1593f70350
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=176dc93750

The issue was bisected to:

commit beee246951571cc5452176f3dbfe9aa5a10ba2b9
Author: Ilan Peer 
Date:   Sun Nov 29 15:30:51 2020 +

cfg80211: Save the regulatory domain when setting custom regulatory

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=12fcc77f50
final oops: https://syzkaller.appspot.com/x/report.txt?x=11fcc77f50
console output: https://syzkaller.appspot.com/x/log.txt?x=16fcc77f50

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+27771d4abcd9b7a1f...@syzkaller.appspotmail.com
Fixes: beee24695157 ("cfg80211: Save the regulatory domain when setting custom 
regulatory")

=
WARNING: suspicious RCU usage
5.10.0-syzkaller #0 Not tainted
-
net/wireless/reg.c:144 suspicious rcu_dereference_check() usage!

other info that might help us debug this:


rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor434/8467:
 #0: 8cd0bd70 (cb_lock){}-{3:3}, at: genl_rcv+0x15/0x40 
net/netlink/genetlink.c:810
 #1: 8cd0bc28 (genl_mutex){+.+.}-{3:3}, at: genl_lock 
net/netlink/genetlink.c:33 [inline]
 #1: 8cd0bc28 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg+0xb1/0x1280 
net/netlink/genetlink.c:798

stack backtrace:
CPU: 1 PID: 8467 Comm: syz-executor434 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x137/0x1be lib/dump_stack.c:120
 get_wiphy_regdom net/wireless/reg.c:144 [inline]
 wiphy_apply_custom_regulatory+0x784/0x910 net/wireless/reg.c:2574
 mac80211_hwsim_new_radio+0x1eb3/0x3930 
drivers/net/wireless/mac80211_hwsim.c:3247
 hwsim_new_radio_nl+0xb07/0xf60 drivers/net/wireless/mac80211_hwsim.c:3822
 genl_family_rcv_msg_doit net/netlink/genetlink.c:739 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
 genl_rcv_msg+0xe4e/0x1280 net/netlink/genetlink.c:800
 netlink_rcv_skb+0x190/0x3a0 net/netlink/af_netlink.c:2494
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811
 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
 netlink_unicast+0x780/0x930 net/netlink/af_netlink.c:1330
 netlink_sendmsg+0x9a8/0xd40 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:652 [inline]
 sock_sendmsg net/socket.c:672 [inline]
 sys_sendmsg+0x519/0x800 net/socket.c:2336
 ___sys_sendmsg net/socket.c:2390 [inline]
 __sys_sendmsg+0x2bc/0x370 net/socket.c:2423
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440309
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffeafb01018 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 00440309
RDX:  RSI: 21c0 RDI: 0003
RBP: 006ca018 R08:  R09: 004002c8
R10: 00401ba0 R11: 0246 R12: 00401b10
R13: 00401ba0 R14:  R15: 


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect

[Andrea Arcangeli]

On Sat, Dec 19, 2020 at 02:06:02PM -0800, Nadav Amit wrote:
> > On Dec 19, 2020, at 1:34 PM, Nadav Amit  wrote:
> > 
> > [ cc’ing some more people who have experience with similar problems ]
> > 
> >> On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli  wrote:
> >> 
> >> Hello,
> >> 
> >> On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
> >>> Analyzing this problem indicates that there is a real bug since
> >>> mmap_lock is only taken for read in mwriteprotect_range(). This might
> >> 
> >> Never having to take the mmap_sem for writing, and in turn never
> >> blocking, in order to modify the pagetables is quite an important
> >> feature in uffd that justifies uffd instead of mprotect. It's not the
> >> most important reason to use uffd, but it'd be nice if that guarantee
> >> would remain also for the UFFDIO_WRITEPROTECT API, not only for the
> >> other pgtable manipulations.
> >> 
> >>> Consider the following scenario with 3 CPUs (cpu2 is not shown):
> >>> 
> >>> cpu0  cpu1
> >>>   
> >>> userfaultfd_writeprotect()
> >>> [ write-protecting ]
> >>> mwriteprotect_range()
> >>> mmap_read_lock()
> >>> change_protection()
> >>> change_protection_range()
> >>>  ...
> >>>  change_pte_range()
> >>>  [ defer TLB flushes]
> >>>   userfaultfd_writeprotect()
> >>>mmap_read_lock()
> >>>change_protection()
> >>>[ write-unprotect ]
> >>>...
> >>> [ unprotect PTE logically ]

Is the uffd selftest failing with upstream or after your kernel
modification that removes the tlb flush from unprotect?

} else if (uffd_wp_resolve) {
/*
 * Leave the write bit to be handled
 * by PF interrupt handler, then
 * things like COW could be properly
 * handled.
 */
ptent = pte_clear_uffd_wp(ptent);
}

Upstraem this will still do pages++, there's a tlb flush before
change_protection can return here, so I'm confused.


> >>>   ...
> >>>   [ page-fault]
> >>>   ...
> >>>   wp_page_copy()
> >>>   [ set new writable page in PTE]
> >> 
> >> Can't we check mm_tlb_flush_pending(vma->vm_mm) if MM_CP_UFFD_WP_ALL
> >> is set and do an explicit (potentially spurious) tlb flush before
> >> write-unprotect?
> > 
> > There is a concrete scenario that I actually encountered and then there is a
> > general problem.
> > 
> > In general, the kernel code assumes that PTEs that are read from the
> > page-tables are coherent across all the TLBs, excluding permission promotion
> > (i.e., the PTE may have higher permissions in the page-tables than those
> > that are cached in the TLBs).
> > 
> > We therefore need to both: (a) protect change_protection_range() from the
> > changes of others who might defer TLB flushes without taking mmap_sem for
> > write (e.g., try_to_unmap_one()); and (b) to protect others (e.g.,
> > page-fault handlers) from concurrent changes of change_protection().
> > 
> > We have already encountered several similar bugs, and debugging such issues
> > s time consuming and these bugs impact is substantial (memory corruption,
> > security). So I think we should only stick to general solutions.
> > 
> > So perhaps your the approach of your proposed solution is feasible, but it
> > would have to be applied all over the place: we will need to add a check for
> > mm_tlb_flush_pending() and conditionally flush the TLB in every case in
> > which PTEs are read and there might be an assumption that the
> > access-permission reflect what the TLBs hold. This includes page-fault
> > handlers, but also NUMA migration code in change_protection(), softdirty
> > cleanup in clear_refs_write() and maybe others.
> > 
> > [ I have in mind another solution, such as keeping in each page-table a 
> > “table-generation” which is the mm-generation at the time of the change,
> > and only flush if “table-generation”==“mm-generation”, but it requires
> > some thought on how to avoid adding new memory barriers. ]
> > 
> > IOW: I think the change that you suggest is insufficient, and a proper
> > solution is too intrusive for “stable".
> > 
> > As for performance, I can add another patch later to remove the TLB flush
> > that is unnecessarily performed during change_protection_range() that does
> > permission promotion. I know that your concern is about the “protect” case

You may want to check flush_tlb_fix_spurious_fault for other archs
before proceeding with your patch later, assuming it wasn't already applied.

> > but I cannot think of a good 

Re: [PATCH] mmc: sdhci-sprd: Fix some resource leaks in the remove function

[Orson Zhai]

On Fri, Dec 18, 2020 at 9:46 PM Christophe JAILLET
 wrote:
>
> Le 17/12/2020 à 23:55, Orson Zhai a écrit :
> > + cc: Billows
> >
> > Hi Christophe,
> > On Fri, Dec 18, 2020 at 4:50 AM Christophe JAILLET
> >  wrote:
> >>
> >> 'sdhci_remove_host()' and 'sdhci_pltfm_free()' should be used in place of
> >> 'mmc_remove_host()' and 'mmc_free_host()'.
> >>
> >> This avoids some resource leaks, is more in line with the error handling
> >> path of the probe function, and is more consistent with other drivers.
> >>
> >> Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host 
> >> controller")
> >> Signed-off-by: Christophe JAILLET 
> >> ---
> >> Other adjustment may be needed.
> >> I'm not sure at all of the 0 passed to 'sdhci_remove_host()'. Some drivers
> >> pass 0, some have some more complicated computation.
> >> ---
> >>   drivers/mmc/host/sdhci-sprd.c | 6 +++---
> >>   1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c
> >> index f85171edabeb..5dc36efff47f 100644
> >> --- a/drivers/mmc/host/sdhci-sprd.c
> >> +++ b/drivers/mmc/host/sdhci-sprd.c
> >> @@ -708,14 +708,14 @@ static int sdhci_sprd_remove(struct platform_device 
> >> *pdev)
> >>   {
> >>  struct sdhci_host *host = platform_get_drvdata(pdev);
> >>  struct sdhci_sprd_host *sprd_host = TO_SPRD_HOST(host);
> >> -   struct mmc_host *mmc = host->mmc;
> >>
> >> -   mmc_remove_host(mmc);
> >> +   sdhci_remove_host(host, 0);
> >> +
> >>  clk_disable_unprepare(sprd_host->clk_sdio);
> >>  clk_disable_unprepare(sprd_host->clk_enable);
> >>  clk_disable_unprepare(sprd_host->clk_2x_enable);
> >>
> >> -   mmc_free_host(mmc);
> >> +   sdhci_pltfm_free(pdev);
> >
> > I saw a lot of drivers also use mmc_free_host().
> > Do you have patches elsewhere to clean them?
> >
>
> As far as I can see, all drivers that use 'mmc_free_host' also use
> 'mmc_alloc_host'. (based on 5.10.1 and unless error)
>
> The only exception is 'sdhci-sprd.c'.
>
> So no, I don't plan any other clean-up.
>
>
>
> To spot it, I run one of my own cocci script which compare functions
> called in the remove function and in the error handling path of the probe.
>
> So I caught this one because 'mmc_free_host' is used in the porbe and
> 'sdhci_pltfm_free' in the remove function.

Thanks for the clarification.

Acked-by: Orson Zhai 

>
>
> CJ
>
> > Thanks,
> > -Orson
> >
> >>
> >>  return 0;
> >>   }
> >> --
> >> 2.27.0
> >>
> >
>

Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect

[Andy Lutomirski]

On Sat, Dec 19, 2020 at 1:34 PM Nadav Amit  wrote:
>
> [ cc’ing some more people who have experience with similar problems ]
>
> > On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli  wrote:
> >
> > Hello,
> >
> > On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
> >> Analyzing this problem indicates that there is a real bug since
> >> mmap_lock is only taken for read in mwriteprotect_range(). This might
> >
> > Never having to take the mmap_sem for writing, and in turn never
> > blocking, in order to modify the pagetables is quite an important
> > feature in uffd that justifies uffd instead of mprotect. It's not the
> > most important reason to use uffd, but it'd be nice if that guarantee
> > would remain also for the UFFDIO_WRITEPROTECT API, not only for the
> > other pgtable manipulations.
> >
> >> Consider the following scenario with 3 CPUs (cpu2 is not shown):
> >>
> >> cpu0 cpu1
> >>  
> >> userfaultfd_writeprotect()
> >> [ write-protecting ]
> >> mwriteprotect_range()
> >> mmap_read_lock()
> >> change_protection()
> >>  change_protection_range()
> >>   ...
> >>   change_pte_range()
> >>   [ defer TLB flushes]
> >>  userfaultfd_writeprotect()
> >>   mmap_read_lock()
> >>   change_protection()
> >>   [ write-unprotect ]
> >>   ...
> >>[ unprotect PTE logically ]
> >>  ...
> >>  [ page-fault]
> >>  ...
> >>  wp_page_copy()
> >>  [ set new writable page in PTE]
> >
> > Can't we check mm_tlb_flush_pending(vma->vm_mm) if MM_CP_UFFD_WP_ALL
> > is set and do an explicit (potentially spurious) tlb flush before
> > write-unprotect?
>
> There is a concrete scenario that I actually encountered and then there is a
> general problem.
>
> In general, the kernel code assumes that PTEs that are read from the
> page-tables are coherent across all the TLBs, excluding permission promotion
> (i.e., the PTE may have higher permissions in the page-tables than those
> that are cached in the TLBs).
>
> We therefore need to both: (a) protect change_protection_range() from the
> changes of others who might defer TLB flushes without taking mmap_sem for
> write (e.g., try_to_unmap_one()); and (b) to protect others (e.g.,
> page-fault handlers) from concurrent changes of change_protection().
>
> We have already encountered several similar bugs, and debugging such issues
> s time consuming and these bugs impact is substantial (memory corruption,
> security). So I think we should only stick to general solutions.
>
> So perhaps your the approach of your proposed solution is feasible, but it
> would have to be applied all over the place: we will need to add a check for
> mm_tlb_flush_pending() and conditionally flush the TLB in every case in
> which PTEs are read and there might be an assumption that the
> access-permission reflect what the TLBs hold. This includes page-fault
> handlers, but also NUMA migration code in change_protection(), softdirty
> cleanup in clear_refs_write() and maybe others.

I missed the beginning of this thread, but it looks to me like
userfaultfd changes PTEs with not locking except mmap_read_lock().  It
also calls inc_tlb_flush_pending(), which is very explicitly
documented as requiring the pagetable lock.  Those docs must be wrong,
because mprotect() uses the mmap_sem write lock, which is just fine,
but ISTM some kind of mutual exclusion with proper acquire/release
ordering is indeed needed.  So the userfaultfd code seems bogus.

I think userfaultfd either needs to take a real lock (probably doesn't
matter which) or the core rules about PTEs need to be rewritten.

Re: [PATCH] Input: da7280 - protect OF match table with CONFIG_OF

[Jeff LaBundy]

Hi Dmitry,

On Fri, Dec 18, 2020 at 04:49:48PM +, Roy Im wrote:
> On Friday, December 18, 2020 3:50 PM, Dmitry Torokhov wrote:
> 
> > The OF match table is only used when OF is enabled.
> > 
> > Fixes: cd3f609823a5 ("Input: new da7280 haptic driver")
> > Reported-by: kernel test robot 
> > Signed-off-by: Dmitry Torokhov 
> > ---
> >  drivers/input/misc/da7280.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c 
> > index 2f698a8c1d65..b08610d6e575 100644
> > --- a/drivers/input/misc/da7280.c
> > +++ b/drivers/input/misc/da7280.c
> > @@ -1300,11 +1300,13 @@ static int __maybe_unused da7280_resume(struct 
> > device *dev)
> > return retval;
> >  }
> > 
> > +#ifdef CONFIG_OF
> >  static const struct of_device_id da7280_of_match[] = {
> > { .compatible = "dlg,da7280", },
> > { }
> >  };
> >  MODULE_DEVICE_TABLE(of, da7280_of_match);
> > +#endif

Just for my own understanding, would it not work just as well
to include of_device.h? This includes mod_devicetable.h which
in turn defines the of_device_id struct (even if CONFIG_OF is
not set).

The reason for asking is because it seems many drivers do not
include these guards.

> > 
> >  static const struct i2c_device_id da7280_i2c_id[] = {
> > { "da7280", },
> > --
> > 2.29.2.729.g45daf8777d-goog
> > 
> > 
> > --
> > Dmitry
> 
> Thanks!
> 
> Acked-by: Roy Im 
> 

Kind regards,
Jeff LaBundy

Re: [PATCH] zsmalloc: do not use bit_spin_lock

[Mike Galbraith]

On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote:
> zsmalloc takes bit spinlock in its _map() callback and releases it
> only in unmap() which is unsafe and leads to zswap complaining
> about scheduling in atomic context.
>
> To fix that and to improve RT properties of zsmalloc, remove that
> bit spinlock completely and use a bit flag instead.


> -static void pin_tag(unsigned long handle) __acquires(bitlock)
> +static void pin_tag(unsigned long handle)
>  {
> - bit_spin_lock(HANDLE_PIN_BIT, (unsigned long *)handle);
> + preempt_disable();
> + while(test_and_set_bit(HANDLE_PIN_BIT, (unsigned long *)handle))
> + cpu_relax();
> + preempt_enable();
>  }

If try doesn't need to disable preemption, neither does pin.

-Mike

[PATCH] iio:light:apds9960 add detection for MSHW0184 ACPI device in apds9960 driver

[Max Leiter]

The device is used in the Microsoft Surface Book 3 and Surface Pro 7

Signed-off-by: Max Leiter 
---
 drivers/iio/light/apds9960.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c
index 9afb3fcc74e6..20719141c03a 100644
--- a/drivers/iio/light/apds9960.c
+++ b/drivers/iio/light/apds9960.c
@@ -8,6 +8,7 @@
  * TODO: gesture + proximity calib offsets
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1113,6 +1114,12 @@ static const struct i2c_device_id apds9960_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, apds9960_id);
 
+static const struct acpi_device_id apds9960_acpi_match[] = {
+   { "MSHW0184" },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, apds9960_acpi_match);
+
 static const struct of_device_id apds9960_of_match[] = {
{ .compatible = "avago,apds9960" },
{ }
@@ -1124,6 +1131,7 @@ static struct i2c_driver apds9960_driver = {
.name   = APDS9960_DRV_NAME,
.of_match_table = apds9960_of_match,
.pm = _pm_ops,
+   .acpi_match_table = apds9960_acpi_match,
},
.probe  = apds9960_probe,
.remove = apds9960_remove,
-- 
2.29.2

Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

[Ian Kent]

On Sun, 2020-12-20 at 07:52 +0800, Ian Kent wrote:
> On Sat, 2020-12-19 at 11:23 -0500, Tejun Heo wrote:
> > Hello,
> > 
> > On Sat, Dec 19, 2020 at 03:08:13PM +0800, Ian Kent wrote:
> > > And looking further I see there's a race that kernfs can't do
> > > anything
> > > about between kernfs_refresh_inode() and
> > > fs/inode.c:update_times().
> > 
> > Do kernfs files end up calling into that path tho? Doesn't look
> > like
> > it to
> > me but if so yeah we'd need to override the update_time for kernfs.

You are correct, update_time() will only be called during symlink
following and only to update atime.

So this isn't sufficient to update the inode attributes to reflect
changes make by things like kernfs_setattr() or when the directory
link count changes ...

Sigh!

[tip:master] BUILD SUCCESS 981316394e3558064e65bfabbae71acb9145e483

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  master
branch HEAD: 981316394e3558064e65bfabbae71acb9145e483  Merge branch 
'locking/urgent'

elapsed time: 725m

configs tested: 97
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
sh  urquell_defconfig
nds32 allnoconfig
powerpc tqm5200_defconfig
powerpc stx_gp3_defconfig
arc  axs101_defconfig
xtensa virt_defconfig
powerpc mpc832x_mds_defconfig
arm ezx_defconfig
powerpc mpc83xx_defconfig
sh  r7785rp_defconfig
armmagician_defconfig
h8300   defconfig
powerpccell_defconfig
sh   rts7751r2dplus_defconfig
powerpc akebono_defconfig
x86_64   allyesconfig
arc nsimosci_hs_smp_defconfig
arm lubbock_defconfig
xtensa  cadence_csp_defconfig
powerpc mpc836x_rdk_defconfig
shedosk7760_defconfig
ia64generic_defconfig
h8300alldefconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a003-20201219
x86_64   randconfig-a006-20201219
x86_64   randconfig-a002-20201219
x86_64   randconfig-a005-20201219
x86_64   randconfig-a001-20201219
x86_64   randconfig-a004-20201219
i386 randconfig-a004-20201219
i386 randconfig-a001-20201219
i386 randconfig-a002-20201219
i386 randconfig-a003-20201219
i386 randconfig-a005-20201219
i386 randconfig-a006-20201219
i386 randconfig-a014-20201219
i386 randconfig-a013-20201219
i386 randconfig-a011-20201219
i386 randconfig-a012-20201219
i386 randconfig-a016-20201219
i386 randconfig-a015-20201219
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a016-20201219
x86_64   randconfig-a013-20201219
x86_64   randconfig-a012-20201219
x86_64   randconfig-a015-20201219
x86_64   randconfig-a014-20201219
x86_64   randconfig-a011-20201219

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

Re: [PATCH] zsmalloc: do not use bit_spin_lock

[Mike Galbraith]

On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote:
> zsmalloc takes bit spinlock in its _map() callback and releases it
> only in unmap() which is unsafe and leads to zswap complaining
> about scheduling in atomic context.
>
> To fix that and to improve RT properties of zsmalloc, remove that
> bit spinlock completely and use a bit flag instead.

It also does get_cpu_var() in map(), put_cpu_var() in unmap().

-Mike

KASAN: use-after-free Read in io_ring_ctx_wait_and_kill

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:a409ed15 Merge tag 'gpio-v5.11-1' of git://git.kernel.org/..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1425527b50
kernel config:  https://syzkaller.appspot.com/x/.config?x=f7c39e7211134bc0
dashboard link: https://syzkaller.appspot.com/bug?extid=fef004c4db2d363bacd3
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fef004c4db2d363ba...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:938 
[inline]
BUG: KASAN: use-after-free in __mutex_lock+0x102f/0x1110 
kernel/locking/mutex.c:1103
Read of size 8 at addr 888073de33e0 by task syz-executor.1/13101

CPU: 1 PID: 13101 Comm: syz-executor.1 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 print_address_description.constprop.0.cold+0xae/0x4c8 mm/kasan/report.c:385
 __kasan_report mm/kasan/report.c:545 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
 __mutex_lock_common kernel/locking/mutex.c:938 [inline]
 __mutex_lock+0x102f/0x1110 kernel/locking/mutex.c:1103
 io_ring_ctx_wait_and_kill+0x21/0x450 fs/io_uring.c:8648
 io_uring_release+0x3e/0x50 fs/io_uring.c:8687
 __fput+0x283/0x920 fs/file_table.c:280
 task_work_run+0xdd/0x190 kernel/task_work.c:140
 exit_task_work include/linux/task_work.h:30 [inline]
 do_exit+0xb89/0x2a00 kernel/exit.c:823
 do_group_exit+0x125/0x310 kernel/exit.c:920
 get_signal+0x3e9/0x2160 kernel/signal.c:2770
 arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:811
 handle_signal_work kernel/entry/common.c:147 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
 exit_to_user_mode_prepare+0x124/0x200 kernel/entry/common.c:201
 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
 syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45e149
Code: Unable to access opcode bytes at RIP 0x45e11f.
RSP: 002b:7f2290236be8 EFLAGS: 0206 ORIG_RAX: 01a9
RAX: fff4 RBX: 2080 RCX: 0045e149
RDX: 200b RSI: 2080 RDI: 0001
RBP: 0119c080 R08: 2000 R09: 2000
R10: 2100 R11: 0206 R12: 200b
R13: 200a R14: 2000 R15: 2100

Allocated by task 13101:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
 kasan_set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:461
 kmalloc include/linux/slab.h:552 [inline]
 kzalloc include/linux/slab.h:682 [inline]
 io_ring_ctx_alloc fs/io_uring.c:1268 [inline]
 io_uring_create fs/io_uring.c:9480 [inline]
 io_uring_setup+0x1d5b/0x38b0 fs/io_uring.c:9613
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 37:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:352
 __kasan_slab_free+0x102/0x140 mm/kasan/common.c:422
 slab_free_hook mm/slub.c:1544 [inline]
 slab_free_freelist_hook+0x5d/0x150 mm/slub.c:1577
 slab_free mm/slub.c:3140 [inline]
 kfree+0xdb/0x3c0 mm/slub.c:4122
 process_one_work+0x98d/0x1630 kernel/workqueue.c:2275
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
 kthread+0x3b1/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296

Last potentially related work creation:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
 kasan_record_aux_stack+0xc0/0xf0 mm/kasan/generic.c:343
 insert_work+0x48/0x370 kernel/workqueue.c:1331
 __queue_work+0x5c1/0xfb0 kernel/workqueue.c:1497
 queue_work_on+0xc7/0xd0 kernel/workqueue.c:1524
 io_uring_create fs/io_uring.c:9586 [inline]
 io_uring_setup+0x1358/0x38b0 fs/io_uring.c:9613
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

The buggy address belongs to the object at 888073de3000
 which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 992 bytes inside of
 2048-byte region [888073de3000, 888073de3800)
The buggy address belongs to the page:
page:2686ff6f refcount:1 mapcount:0 mapping: index:0x0 
pfn:0x73de0
head:2686ff6f order:3 compound_mapcount:0 compound_pincount:0
flags: 0xfff0010200(slab|head)
raw: 00fff0010200 dead0100 dead0122 888010842000
raw:  00080008 0001 
page dumped because: kasan: bad access detected

Memory state 

Re: [PATCH] zsmalloc: do not use bit_spin_lock

[Matthew Wilcox]

On Sun, Dec 20, 2020 at 02:22:28AM +0200, Vitaly Wool wrote:
> zsmalloc takes bit spinlock in its _map() callback and releases it
> only in unmap() which is unsafe and leads to zswap complaining
> about scheduling in atomic context.
> 
> To fix that and to improve RT properties of zsmalloc, remove that
> bit spinlock completely and use a bit flag instead.

Isn't this just "I open coded bit spinlock to make the lockdep
warnings go away"?

Re: 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1

[Randy Dunlap]

On 12/18/20 2:20 AM, Toralf Förster wrote:
> On 12/18/20 7:54 AM, Randy Dunlap wrote:
>> Hi,
>>
>> [adding linux-mm]
>>
>> On 12/16/20 1:54 AM, Toralf Förster wrote:
>>> Hi,
>>>
>>> I got this recently at this hardened Gentoo Linux server:
>>>
>>> Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R)
>>> Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux
>>>
>>>
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206972]
>>> 
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206977] UBSAN: shift-out-of-bounds
>>> in ./include/linux/log2.h:57:13
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206980] shift exponent 64 is too
>>> large for 64-bit type 'long unsigned int'
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206982] CPU: 11 PID: 21051 Comm:
>>> cc1 Tainted: G    T 5.10.1 #1
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206984] Hardware name: ASUSTeK
>>> COMPUTER INC. Z10PA-U8 Series/Z10PA-U8 Series, BIOS 3703 08/02/2018
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206985] Call Trace:
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206993]  dump_stack+0x57/0x6a
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206996]  ubsan_epilogue+0x5/0x40
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.206999]
>>> __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207002]
>>> ondemand_readahead.cold+0x16/0x21
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207007]
>>> generic_file_buffered_read+0x452/0x890
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207011]  new_sync_read+0x156/0x200
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207014]  vfs_read+0xf8/0x190
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207016]  ksys_read+0x65/0xe0
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207018]  do_syscall_64+0x33/0x40
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207021]
>>> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207024] RIP: 0033:0x7f01b2df198e
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207026] Code: c0 e9 b6 fe ff ff 50
>>> 48 8d 3d 66 c3 09 00 e8 59 e2 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04
>>> 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f
>>> 84 00 00 00 00 00 48 83 ec 28
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207028] RSP: 002b:7fff2167e998
>>> EFLAGS: 0246 ORIG_RAX: 
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207030] RAX: ffda RBX:
>>>  RCX: 7f01b2df198e
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207032] RDX:  RSI:
>>> 054dcc50 RDI: 0004
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207033] RBP: 054dcc50 R08:
>>> 054dcc50 R09: 
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207034] R10:  R11:
>>> 0246 R12: 054dc3b0
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207035] R13: 8000 R14:
>>> 054c9800 R15: 
>>> Dec 15 23:31:51 mr-fox kernel: [ 1974.207037]
>>> 
>>>
>>>
>>> Known issue ?
>>
>> Not that I have heard about, but that's not conclusive.
>>
>> Looks to me like this is in mm/readahead.c:
>>
>> static unsigned long get_init_ra_size(unsigned long size, unsigned long max)
>> {
>> unsigned long newsize = roundup_pow_of_two(size);
>>
>>
>> What filesystem?  What workload?
> 
> / is a 32 GB ext4 filesystem.
> Data are at 3 BTRFS filesystems, 1x 500 GB and 2x 1.6TB.
> 
> 2 Tor relays run at 100% each and utilizes the 1 GBit/s by 50%-60% [1]
> 
> 7 build bots are running over the Gentoo software repostory [2]
> 1 AFL bot fuzzies the Tor sources.
> Those 8 jobs are contained by a cgroup of 9 CPUs and 120 GB RAM [3],
> each job is contained further by an own sub cgroup of 1.5 CPU and 20 GB
> RAM [4]
> 
> The host is monitored using sysstat, the load is about 11.8, CPU[all] at
> 80%, proc/s at 1800, cswchs/s at 2 and so on.
> 
> 
> [1] https://metrics.torproject.org/rs.html#search/zwiebeltoralf
> [2] https://zwiebeltoralf.de/tinderbox.html
> [3] https://github.com/toralf/tinderbox/blob/master/bin/cgroup.sh
> [4] https://github.com/toralf/tinderbox/blob/master/bin/bwrap.sh#L15
> 
> -- 

Hi Toralf,

Is this something that happens more than once?
I think we would like to find out what is causing it.
I see a couple of problems.

(a)
  UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
  shift exponent 64 is too large for 64-bit type 'long unsigned int'

:57: is like so:

50  /**
51   * __roundup_pow_of_two() - round up to nearest power of two
52   * @n: value to round up
53   */
54  static inline __attribute__((const))
55  unsigned long __roundup_pow_of_two(unsigned long n)
56  {
57  return 1UL << fls_long(n - 1);
58  }

It's OK/valid for fls_long() [fls64()] to return 64 for a bit
position -- it just means the high-order bit in a 64-bit value.
So this code should 

[PATCH] zsmalloc: do not use bit_spin_lock

[Vitaly Wool]

zsmalloc takes bit spinlock in its _map() callback and releases it
only in unmap() which is unsafe and leads to zswap complaining
about scheduling in atomic context.

To fix that and to improve RT properties of zsmalloc, remove that
bit spinlock completely and use a bit flag instead.

Signed-off-by: Vitaly Wool 
---
 mm/zsmalloc.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 7289f502ffac..ff26546a7fed 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -876,22 +876,25 @@ static unsigned long obj_to_head(struct page *page, void 
*obj)
 
 static inline int testpin_tag(unsigned long handle)
 {
-   return bit_spin_is_locked(HANDLE_PIN_BIT, (unsigned long *)handle);
+   return test_bit(HANDLE_PIN_BIT, (unsigned long *)handle);
 }
 
 static inline int trypin_tag(unsigned long handle)
 {
-   return bit_spin_trylock(HANDLE_PIN_BIT, (unsigned long *)handle);
+   return !test_and_set_bit(HANDLE_PIN_BIT, (unsigned long *)handle);
 }
 
-static void pin_tag(unsigned long handle) __acquires(bitlock)
+static void pin_tag(unsigned long handle)
 {
-   bit_spin_lock(HANDLE_PIN_BIT, (unsigned long *)handle);
+   preempt_disable();
+   while(test_and_set_bit(HANDLE_PIN_BIT, (unsigned long *)handle))
+   cpu_relax();
+   preempt_enable();
 }
 
 static void unpin_tag(unsigned long handle) __releases(bitlock)
 {
-   bit_spin_unlock(HANDLE_PIN_BIT, (unsigned long *)handle);
+   clear_bit(HANDLE_PIN_BIT, (unsigned long *)handle);
 }
 
 static void reset_page(struct page *page)
-- 
2.20.1