Re: [f2fs-dev] [PATCH] f2fs: expose # of overprivision segments

2021-03-03 Thread Chao Yu

On 2021/3/3 2:44, Jaegeuk Kim wrote:

On 03/02, Jaegeuk Kim wrote:

On 03/02, Chao Yu wrote:

On 2021/3/2 13:42, Jaegeuk Kim wrote:

This is useful when checking conditions during checkpoint=disable in Android.


This sysfs entry is readonly, how about putting this at
/sys/fs/f2fs//stat/?


Urg.. "stat" is a bit confused. I'll take a look a better ones.


Oh, I mean put it into "stat" directory, not "stat" entry, something like this:

/sys/fs/f2fs//stat/ovp_segments



Taking a look at other entries using in Android, I feel that this one can't be
in stat or whatever other location, since I worry about the consistency with
similar dirty/free segments. It seems it's not easy to clean up the existing
ones anymore.


Well, actually, the entry number are still increasing continuously, the result 
is
that it becomes more and more slower and harder for me to find target entry name
from that directory.

IMO, once new readonly entry was added to "" directory, there is no chance
to reloacate it due to interface compatibility. So I think this is the only
chance to put it to the appropriate place at this time.

Thanks,









Signed-off-by: Jaegeuk Kim 
---
   fs/f2fs/sysfs.c | 8 
   1 file changed, 8 insertions(+)

diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index e38a7f6921dd..254b6fa17406 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -91,6 +91,13 @@ static ssize_t free_segments_show(struct f2fs_attr *a,
(unsigned long long)(free_segments(sbi)));
   }
+static ssize_t ovp_segments_show(struct f2fs_attr *a,
+   struct f2fs_sb_info *sbi, char *buf)
+{
+   return sprintf(buf, "%llu\n",
+   (unsigned long long)(overprovision_segments(sbi)));
+}
+
   static ssize_t lifetime_write_kbytes_show(struct f2fs_attr *a,
struct f2fs_sb_info *sbi, char *buf)
   {
@@ -629,6 +636,7 @@ F2FS_RW_ATTR(F2FS_SBI, f2fs_sb_info, node_io_flag, 
node_io_flag);
   F2FS_RW_ATTR(CPRC_INFO, ckpt_req_control, ckpt_thread_ioprio, 
ckpt_thread_ioprio);
   F2FS_GENERAL_RO_ATTR(dirty_segments);
   F2FS_GENERAL_RO_ATTR(free_segments);
+F2FS_GENERAL_RO_ATTR(ovp_segments);


Missed to add document entry in Documentation/ABI/testing/sysfs-fs-f2fs?


Yeah, thanks.



Thanks,


   F2FS_GENERAL_RO_ATTR(lifetime_write_kbytes);
   F2FS_GENERAL_RO_ATTR(features);
   F2FS_GENERAL_RO_ATTR(current_reserved_blocks);




___
Linux-f2fs-devel mailing list
linux-f2fs-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

.



[PATCH] scripts/spelling.txt: Add "diabled" typo

2021-03-03 Thread zuoqilin1
From: zuoqilin 

Increase "diabled" spelling error check.

Signed-off-by: zuoqilin 
---
 scripts/spelling.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/spelling.txt b/scripts/spelling.txt
index 2e3ba91..e5f3b7e 100644
--- a/scripts/spelling.txt
+++ b/scripts/spelling.txt
@@ -470,6 +470,7 @@ devided||divided
 deviece||device
 devision||division
 diable||disable
+diabled||disabled
 dicline||decline
 dictionnary||dictionary
 didnt||didn't
-- 
1.9.1




Re: drm/ttm: ttm_bo_release called without lock

2021-03-03 Thread Christian König
I also already send a patch to the list to mitigate the warnings into a 
WARN_ON_ONCE().


Christian.

Am 04.03.21 um 08:42 schrieb Thomas Zimmermann:

(cc'ing Gerd)

This might be related to the recent clean-up patches for the BO 
handling in qxl.


Am 03.03.21 um 16:07 schrieb Petr Mladek:

On Wed 2021-03-03 15:34:09, Petr Mladek wrote:

Hi,

the following warning is filling my kernel log buffer
with 5.12-rc1+ kernels:

[  941.070598] WARNING: CPU: 0 PID: 11 at 
drivers/gpu/drm/ttm/ttm_bo.c:139 ttm_bo_move_to_lru_tail+0x1ba/0x210

[  941.070601] Modules linked in:
[  941.070603] CPU: 0 PID: 11 Comm: kworker/0:1 Kdump: loaded 
Tainted: G    W 5.12.0-rc1-default+ #81
[  941.070605] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), 
BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014

[  941.070606] Workqueue: events qxl_gc_work
[  941.070609] RIP: 0010:ttm_bo_move_to_lru_tail+0x1ba/0x210
[  941.070610] Code: 93 e8 02 00 00 48 89 0a e9 00 ff ff ff 48 8b 87 
38 01 00 00 be ff ff ff ff 48 8d 78 70 e8 8e 7d 46 00 85 c0 0f 85 6f 
fe ff ff <0f> 0b 8b 93 fc 02 00 00 85 d2 0f 84 6d fe ff ff 48 89 df 
5b 5d 41

[  941.070612] RSP: 0018:bddf4008fd38 EFLAGS: 00010246
[  941.070614] RAX:  RBX: 95ae485bac00 RCX: 
0002
[  941.070615] RDX:  RSI: 95ae485badb0 RDI: 
95ae40305108
[  941.070616] RBP:  R08: 0001 R09: 
0001
[  941.070617] R10: bddf4008fc10 R11: a5401580 R12: 
95ae42a94e90
[  941.070618] R13: 95ae485bae70 R14: 95ae485bac00 R15: 
95ae455d1800
[  941.070620] FS:  () GS:95aebf60() 
knlGS:

[  941.070621] CS:  0010 DS:  ES:  CR0: 80050033
[  941.070622] CR2: 7f8ffb2f8000 CR3: 000102c5e005 CR4: 
00370ef0
[  941.070624] DR0:  DR1:  DR2: 

[  941.070626] DR3:  DR6: fffe0ff0 DR7: 
0400

[  941.070627] Call Trace:
[  941.070630]  ttm_bo_release+0x551/0x600
[  941.070635]  qxl_bo_unref+0x3a/0x50
[  941.070638]  qxl_release_free_list+0x62/0xc0
[  941.070643]  qxl_release_free+0x76/0xe0
[  941.070646]  qxl_garbage_collect+0xd9/0x190
[  941.080241]  process_one_work+0x2b0/0x630
[  941.080249]  ? process_one_work+0x630/0x630
[  941.080251]  worker_thread+0x39/0x3f0
[  941.080255]  ? process_one_work+0x630/0x630
[  941.080257]  kthread+0x13a/0x150
[  941.080260]  ? kthread_create_worker_on_cpu+0x70/0x70
[  941.080265]  ret_from_fork+0x1f/0x30
[  941.080277] irq event stamp: 757191
[  941.080278] hardirqs last  enabled at (757197): 
[] vprintk_emit+0x27f/0x2c0
[  941.080280] hardirqs last disabled at (757202): 
[] vprintk_emit+0x23c/0x2c0
[  941.080281] softirqs last  enabled at (755768): 
[] __do_softirq+0x30f/0x432
[  941.080284] softirqs last disabled at (755763): 
[] irq_exit_rcu+0xea/0xf0


I have just realized that it actually prints two warnings over and
over again. The 2nd one is:

[  186.078790] WARNING: CPU: 0 PID: 146 at 
drivers/gpu/drm/ttm/ttm_bo.c:512 ttm_bo_release+0x533/0x600

[  186.078794] Modules linked in:
[  186.078795] CPU: 0 PID: 146 Comm: kworker/0:2 Kdump: loaded 
Tainted: G    W 5.12.0-rc1-default+ #81
[  186.078797] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), 
BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014

[  186.078799] Workqueue: events qxl_gc_work
[  186.078801] RIP: 0010:ttm_bo_release+0x533/0x600
[  186.078803] Code: e9 c6 fb ff ff 4c 8b 7d d0 b9 4c 1d 00 00 31 d2 
be 01 00 00 00 49 8b bf d0 fe ff ff e8 86 f1 04 00 49 8b
47 e0 e9 2b ff ff ff <0f> 0b 48 8b 45 d0 31 d2 4c 89 f7 48 8d 70 08 
c7 80 94 00 00 00 00

[  186.078805] RSP: 0018:a22a402e3d60 EFLAGS: 00010202
[  186.078807] RAX: 0001 RBX: 9334cd8f5668 RCX: 
1180
[  186.078808] RDX: 93353f61a7c0 RSI: a6401580 RDI: 
9334c44f9588
[  186.078810] RBP: a22a402e3d90 R08: 0001 R09: 
0001
[  186.078811] R10: a22a402e3c10 R11: a6401580 R12: 
9334c48fa300
[  186.078812] R13: 9334c0f24e90 R14: 9334cd8f5400 R15: 
9334c4528000
[  186.078813] FS:  () GS:93353f60() 
knlGS:

[  186.078814] CS:  0010 DS:  ES:  CR0: 80050033
[  186.078816] CR2: 7f1908079860 CR3: 21824004 CR4: 
00370ef0
[  186.078818] DR0:  DR1:  DR2: 

[  186.078819] DR3:  DR6: fffe0ff0 DR7: 
0400

[  186.078821] Call Trace:
[  186.078826]  qxl_bo_unref+0x3a/0x50
[  186.078829]  qxl_release_free_list+0x62/0xc0
[  186.078834]  qxl_release_free+0x76/0xe0
[  186.078837]  qxl_garbage_collect+0xd9/0x190
[  186.078843]  process_one_work+0x2b0/0x630
[  186.078850]  ? process_one_work+0x630/0x630
[  186.078853]  worker_thread+0x39/0x3f0
[  186.078857]  ? process_one_work+0x630/0x630
[  186.07

Re: [PATCH 3/3] netfilter: x_tables: Use correct memory barriers.

2021-03-03 Thread Florian Westphal
Mark Tomlinson  wrote:
> When a new table value was assigned, it was followed by a write memory
> barrier. This ensured that all writes before this point would complete
> before any writes after this point. However, to determine whether the
> rules are unused, the sequence counter is read. To ensure that all
> writes have been done before these reads, a full memory barrier is
> needed, not just a write memory barrier. The same argument applies when
> incrementing the counter, before the rules are read.
> 
> Changing to using smp_mb() instead of smp_wmb() fixes the kernel panic
> reported in cc00bcaa5899,

Can you reproduce the crashes without this change?

> while still maintaining the same speed of replacing tables.

How much of an impact is the MB change on the packet path?

Please also CC authors of the patches you want reverted when reposting.


Re: [PATCH 2/3] Revert "netfilter: x_tables: Switch synchronization to RCU"

2021-03-03 Thread Florian Westphal
Mark Tomlinson  wrote:
> This reverts commit cc00bcaa589914096edef7fb87ca5cee4a166b5c.
> 
> This (and the preceding) patch basically re-implemented the RCU
> mechanisms of patch 784544739a25. That patch was replaced because of the
> performance problems that it created when replacing tables. Now, we have
> the same issue: the call to synchronize_rcu() makes replacing tables
> slower by as much as an order of magnitude.

Can you give roigh numbers?

> See https://lore.kernel.org/patchwork/patch/151796/ for why using RCU is
> not a good idea.

Please, no link.


Re: [PATCH v10 2/2] ufs: sysfs: Resume the proper scsi device

2021-03-03 Thread Adrian Hunter
On 3/03/21 12:52 am, Asutosh Das wrote:
> Resumes the actual scsi device the unit descriptor of which
> is being accessed instead of the hba alone.

Since "scsi: ufs: ufs-debugfs: Add user-defined exception_event_mask"
is now in linux-next, a similar change is needed for ufs-debugfs.c.
Probably best it is a separate patch though.


Re: [PATCH 1/3] Revert "netfilter: x_tables: Update remaining dereference to RCU"

2021-03-03 Thread Florian Westphal
Mark Tomlinson  wrote:
> This reverts commit 443d6e86f821a165fae3fc3fc13086d27ac140b1.
> 
> This (and the following) patch basically re-implemented the RCU
> mechanisms of patch 784544739a25. That patch was replaced because of the
> performance problems that it created when replacing tables. Now, we have
> the same issue: the call to synchronize_rcu() makes replacing tables
> slower by as much as an order of magnitude.
> 
> See https://lore.kernel.org/patchwork/patch/151796/ for why using RCU is
> not a good idea.

Please don't add links for the rationale.


[PATCH v2 2/2] mm/memcg: set memcg when split page

2021-03-03 Thread Zhou Guanghui
As described in the split_page function comment, for the non-compound
high order page, the sub-pages must be freed individually. If the
memcg of the fisrt page is valid, the tail pages cannot be uncharged
when be freed.

For example, when alloc_pages_exact is used to allocate 1MB continuous
physical memory, 2MB is charged(kmemcg is enabled and __GFP_ACCOUNT is
set). When make_alloc_exact free the unused 1MB and free_pages_exact
free the applied 1MB, actually, only 4KB(one page) is uncharged.

Therefore, the memcg of the tail page needs to be set when split page.

Signed-off-by: Zhou Guanghui 
---
 mm/page_alloc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3e4b29ee2b1e..3ed783e25c3c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3310,6 +3310,7 @@ void split_page(struct page *page, unsigned int order)
for (i = 1; i < (1 << order); i++)
set_page_refcounted(page + i);
split_page_owner(page, 1 << order);
+   split_page_memcg(page, 1 << order);
 }
 EXPORT_SYMBOL_GPL(split_page);
 
-- 
2.25.0



Re: drm/ttm: ttm_bo_release called without lock

2021-03-03 Thread Thomas Zimmermann

(cc'ing Gerd)

This might be related to the recent clean-up patches for the BO handling 
in qxl.


Am 03.03.21 um 16:07 schrieb Petr Mladek:

On Wed 2021-03-03 15:34:09, Petr Mladek wrote:

Hi,

the following warning is filling my kernel log buffer
with 5.12-rc1+ kernels:

[  941.070598] WARNING: CPU: 0 PID: 11 at drivers/gpu/drm/ttm/ttm_bo.c:139 
ttm_bo_move_to_lru_tail+0x1ba/0x210
[  941.070601] Modules linked in:
[  941.070603] CPU: 0 PID: 11 Comm: kworker/0:1 Kdump: loaded Tainted: G
W 5.12.0-rc1-default+ #81
[  941.070605] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
[  941.070606] Workqueue: events qxl_gc_work
[  941.070609] RIP: 0010:ttm_bo_move_to_lru_tail+0x1ba/0x210
[  941.070610] Code: 93 e8 02 00 00 48 89 0a e9 00 ff ff ff 48 8b 87 38 01 00 00 be 
ff ff ff ff 48 8d 78 70 e8 8e 7d 46 00 85 c0 0f 85 6f fe ff ff <0f> 0b 8b 93 fc 
02 00 00 85 d2 0f 84 6d fe ff ff 48 89 df 5b 5d 41
[  941.070612] RSP: 0018:bddf4008fd38 EFLAGS: 00010246
[  941.070614] RAX:  RBX: 95ae485bac00 RCX: 0002
[  941.070615] RDX:  RSI: 95ae485badb0 RDI: 95ae40305108
[  941.070616] RBP:  R08: 0001 R09: 0001
[  941.070617] R10: bddf4008fc10 R11: a5401580 R12: 95ae42a94e90
[  941.070618] R13: 95ae485bae70 R14: 95ae485bac00 R15: 95ae455d1800
[  941.070620] FS:  () GS:95aebf60() 
knlGS:
[  941.070621] CS:  0010 DS:  ES:  CR0: 80050033
[  941.070622] CR2: 7f8ffb2f8000 CR3: 000102c5e005 CR4: 00370ef0
[  941.070624] DR0:  DR1:  DR2: 
[  941.070626] DR3:  DR6: fffe0ff0 DR7: 0400
[  941.070627] Call Trace:
[  941.070630]  ttm_bo_release+0x551/0x600
[  941.070635]  qxl_bo_unref+0x3a/0x50
[  941.070638]  qxl_release_free_list+0x62/0xc0
[  941.070643]  qxl_release_free+0x76/0xe0
[  941.070646]  qxl_garbage_collect+0xd9/0x190
[  941.080241]  process_one_work+0x2b0/0x630
[  941.080249]  ? process_one_work+0x630/0x630
[  941.080251]  worker_thread+0x39/0x3f0
[  941.080255]  ? process_one_work+0x630/0x630
[  941.080257]  kthread+0x13a/0x150
[  941.080260]  ? kthread_create_worker_on_cpu+0x70/0x70
[  941.080265]  ret_from_fork+0x1f/0x30
[  941.080277] irq event stamp: 757191
[  941.080278] hardirqs last  enabled at (757197): [] 
vprintk_emit+0x27f/0x2c0
[  941.080280] hardirqs last disabled at (757202): [] 
vprintk_emit+0x23c/0x2c0
[  941.080281] softirqs last  enabled at (755768): [] 
__do_softirq+0x30f/0x432
[  941.080284] softirqs last disabled at (755763): [] 
irq_exit_rcu+0xea/0xf0


I have just realized that it actually prints two warnings over and
over again. The 2nd one is:

[  186.078790] WARNING: CPU: 0 PID: 146 at drivers/gpu/drm/ttm/ttm_bo.c:512 
ttm_bo_release+0x533/0x600
[  186.078794] Modules linked in:
[  186.078795] CPU: 0 PID: 146 Comm: kworker/0:2 Kdump: loaded Tainted: G   
 W 5.12.0-rc1-default+ #81
[  186.078797] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
[  186.078799] Workqueue: events qxl_gc_work
[  186.078801] RIP: 0010:ttm_bo_release+0x533/0x600
[  186.078803] Code: e9 c6 fb ff ff 4c 8b 7d d0 b9 4c 1d 00 00 31 d2 be 01 00 
00 00 49 8b bf d0 fe ff ff e8 86 f1 04 00 49 8b
47 e0 e9 2b ff ff ff <0f> 0b 48 8b 45 d0 31 d2 4c 89 f7 48 8d 70 08 c7 80 94 00 
00 00 00
[  186.078805] RSP: 0018:a22a402e3d60 EFLAGS: 00010202
[  186.078807] RAX: 0001 RBX: 9334cd8f5668 RCX: 1180
[  186.078808] RDX: 93353f61a7c0 RSI: a6401580 RDI: 9334c44f9588
[  186.078810] RBP: a22a402e3d90 R08: 0001 R09: 0001
[  186.078811] R10: a22a402e3c10 R11: a6401580 R12: 9334c48fa300
[  186.078812] R13: 9334c0f24e90 R14: 9334cd8f5400 R15: 9334c4528000
[  186.078813] FS:  () GS:93353f60() 
knlGS:
[  186.078814] CS:  0010 DS:  ES:  CR0: 80050033
[  186.078816] CR2: 7f1908079860 CR3: 21824004 CR4: 00370ef0
[  186.078818] DR0:  DR1:  DR2: 
[  186.078819] DR3:  DR6: fffe0ff0 DR7: 0400
[  186.078821] Call Trace:
[  186.078826]  qxl_bo_unref+0x3a/0x50
[  186.078829]  qxl_release_free_list+0x62/0xc0
[  186.078834]  qxl_release_free+0x76/0xe0
[  186.078837]  qxl_garbage_collect+0xd9/0x190
[  186.078843]  process_one_work+0x2b0/0x630
[  186.078850]  ? process_one_work+0x630/0x630
[  186.078853]  worker_thread+0x39/0x3f0
[  186.078857]  ? process_one_work+0x630/0x630
[  186.078859]  kthread+0x13a/0x150
[  186.078861]  ? kthread_create_worker_on_cpu+0x70/0x70
[  186.078866]  ret_from_fork+0x1f/0x30
[  186.078879] irq event stamp: 619687
[  186.091417] 

Re: [PATCH] clocksource: don't run watchdog forever

2021-03-03 Thread Feng Tang
Hi Thomas,

On Wed, Mar 03, 2021 at 04:50:31PM +0100, Thomas Gleixner wrote:
> On Tue, Mar 02 2021 at 20:06, Feng Tang wrote:
> > On Tue, Mar 02, 2021 at 10:16:37AM +0100, Peter Zijlstra wrote:
> >> On Tue, Mar 02, 2021 at 10:54:24AM +0800, Feng Tang wrote:
> >> > clocksource watchdog runs every 500ms, which creates some OS noise.
> >> > As the clocksource wreckage (especially for those that has per-cpu
> >> > reading hook) usually happens shortly after CPU is brought up or
> >> > after system resumes from sleep state, so add a time limit for
> >> > clocksource watchdog to only run for a period of time, and make
> >> > sure it run at least twice for each CPU.
> >> > 
> >> > Regarding performance data, there is no improvement data with the
> >> > micro-benchmarks we have like hackbench/netperf/fio/will-it-scale
> >> > etc. But it obviously reduces periodic timer interrupts, and may
> >> > help in following cases:
> >> > * When some CPUs are isolated to only run scientific or high
> >> >   performance computing tasks on a NOHZ_FULL kernel, where there
> >> >   is almost no interrupts, this could make it more quiet
> >> > * On a cluster which runs a lot of systems in parallel with
> >> >   barriers there are always enough systems which run the watchdog
> >> >   and make everyone else wait
> >> > 
> >> > Signed-off-by: Feng Tang 
> >> 
> >> Urgh.. so this hopes and prays that the TSC wrackage happens in the
> >> first 10 minutes after boot.
> 
> which is wishful thinking
> 
> > Yes, the 10 minutes part is only based on our past experience and we
> > can make it longer. But if there was real case that the wrackage happened
> > long after CPU is brought up like days, then this patch won't help
> > much.
> 
> It really depends on the BIOS wreckage. On one of my machine it takes up
> to a day depending on the workload.

Thanks for sharing the info.

> Anything pre TSC_ADJUST wants the watchdog on. With TSC ADJUST available
> we can probably avoid it.
> 
> There is a caveat though. If the machine never goes idle then TSC adjust
> is not able to detect a potential wreckage. OTOH, most of the broken
> BIOSes tweak TSC only by a few cycles and that is usually detectable
> during boot. So we might be clever about it and schedule a check every
> hour when during the first 10 minutes a modification of TSC adjust is
> seen on any CPU.

I don't have much experience with tsc_adjust, and try to understand it:
The 'modification of TSC' here has 2 cases: ? 
* First read of 'TSC_ADJUST' MSR of a just boot CPU returns non-zero value
* Following read of 'TSC_ADJUST' doesn't equal to the 'tsc_adjust' value
  saved in per-cpu data.

Also, does the patch ("x86/tsc: mark tsc reliable for qualified platforms")
need to wait till this caveat case is solved? 

Thanks,
Feng




> 
> Where is this TSC_DISABLE_WRITE bit again?
> 
> Thanks,
> 
> tglx
> 


[PATCH v2 1/2] mm/memcg: rename mem_cgroup_split_huge_fixup to split_page_memcg

2021-03-03 Thread Zhou Guanghui
Rename mem_cgroup_split_huge_fixup to split_page_memcg and explicitly
pass in page number argument.

In this way, the interface name is more common and can be used by
potential users. In addition, the complete info(memcg and flag) of
the memcg needs to be set to the tail pages.

Signed-off-by: Zhou Guanghui 
---
 include/linux/memcontrol.h |  6 ++
 mm/huge_memory.c   |  2 +-
 mm/memcontrol.c| 15 ++-
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index e6dc793d587d..0c04d39a7967 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -1061,9 +1061,7 @@ static inline void memcg_memory_event_mm(struct mm_struct 
*mm,
rcu_read_unlock();
 }
 
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-void mem_cgroup_split_huge_fixup(struct page *head);
-#endif
+void split_page_memcg(struct page *head, unsigned int nr);
 
 #else /* CONFIG_MEMCG */
 
@@ -1400,7 +1398,7 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t 
*pgdat, int order,
return 0;
 }
 
-static inline void mem_cgroup_split_huge_fixup(struct page *head)
+static inline void split_page_memcg(struct page *head, unsigned int nr)
 {
 }
 
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 395c75111d33..e7f29308ebc8 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2471,7 +2471,7 @@ static void __split_huge_page(struct page *page, struct 
list_head *list,
int i;
 
/* complete memcg works before add pages to LRU */
-   mem_cgroup_split_huge_fixup(head);
+   split_page_memcg(head, nr);
 
if (PageAnon(head) && PageSwapCache(head)) {
swp_entry_t entry = { .val = page_private(head) };
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 845eec01ef9d..e064ac0d850a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3287,24 +3287,21 @@ void obj_cgroup_uncharge(struct obj_cgroup *objcg, 
size_t size)
 
 #endif /* CONFIG_MEMCG_KMEM */
 
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 /*
- * Because page_memcg(head) is not set on compound tails, set it now.
+ * Because page_memcg(head) is not set on tails, set it now.
  */
-void mem_cgroup_split_huge_fixup(struct page *head)
+void split_page_memcg(struct page *head, unsigned int nr)
 {
struct mem_cgroup *memcg = page_memcg(head);
int i;
 
-   if (mem_cgroup_disabled())
+   if (mem_cgroup_disabled() || !memcg)
return;
 
-   for (i = 1; i < HPAGE_PMD_NR; i++) {
-   css_get(&memcg->css);
-   head[i].memcg_data = (unsigned long)memcg;
-   }
+   for (i = 1; i < nr; i++)
+   head[i].memcg_data = head->memcg_data;
+   css_get_many(&memcg->css, nr - 1);
 }
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
 #ifdef CONFIG_MEMCG_SWAP
 /**
-- 
2.25.0



[PATCH v2 0/2] set memcg when split page

2021-03-03 Thread Zhou Guanghui
v2:
1. rename mem_cgroup_split_huge_fixup
2. use split_page_memcg when split page

*** BLURB HERE ***

Zhou Guanghui (2):
  mm/memcg: rename mem_cgroup_split_huge_fixup to split_page_memcg
  mm/memcg: set memcg when split pages

 include/linux/memcontrol.h |  6 ++
 mm/huge_memory.c   |  2 +-
 mm/memcontrol.c| 15 ++-
 mm/page_alloc.c|  1 +
 4 files changed, 10 insertions(+), 14 deletions(-)

-- 
2.25.0



arch/riscv/mm/kasan_init.c:99:13: warning: no previous prototype for function 'kasan_shallow_populate'

2021-03-03 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f69d02e37a85645aa90d18cacfff36dba370f797
commit: e178d670f251b6947d6be99c0014e9a57ad4f0e0 riscv/kasan: add KASAN_VMALLOC 
support
date:   13 days ago
config: riscv-randconfig-r022-20210304 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
eec7f8f7b1226be422a76542cb403d02538f453a)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e178d670f251b6947d6be99c0014e9a57ad4f0e0
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e178d670f251b6947d6be99c0014e9a57ad4f0e0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv 

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

All warnings (new ones prefixed by >>):

>> arch/riscv/mm/kasan_init.c:99:13: warning: no previous prototype for 
>> function 'kasan_shallow_populate' [-Wmissing-prototypes]
   void __init kasan_shallow_populate(void *start, void *end)
   ^
   arch/riscv/mm/kasan_init.c:99:1: note: declare 'static' if the function is 
not intended to be used outside of this translation unit
   void __init kasan_shallow_populate(void *start, void *end)
   ^
   static 
   1 warning generated.


vim +/kasan_shallow_populate +99 arch/riscv/mm/kasan_init.c

98  
  > 99  void __init kasan_shallow_populate(void *start, void *end)
   100  {
   101  unsigned long vaddr = (unsigned long)start & PAGE_MASK;
   102  unsigned long vend = PAGE_ALIGN((unsigned long)end);
   103  unsigned long pfn;
   104  int index;
   105  void *p;
   106  pud_t *pud_dir, *pud_k;
   107  pgd_t *pgd_dir, *pgd_k;
   108  p4d_t *p4d_dir, *p4d_k;
   109  
   110  while (vaddr < vend) {
   111  index = pgd_index(vaddr);
   112  pfn = csr_read(CSR_SATP) & SATP_PPN;
   113  pgd_dir = (pgd_t *)pfn_to_virt(pfn) + index;
   114  pgd_k = init_mm.pgd + index;
   115  pgd_dir = pgd_offset_k(vaddr);
   116  set_pgd(pgd_dir, *pgd_k);
   117  
   118  p4d_dir = p4d_offset(pgd_dir, vaddr);
   119  p4d_k  = p4d_offset(pgd_k, vaddr);
   120  
   121  vaddr = (vaddr + PUD_SIZE) & PUD_MASK;
   122  pud_dir = pud_offset(p4d_dir, vaddr);
   123  pud_k = pud_offset(p4d_k, vaddr);
   124  
   125  if (pud_present(*pud_dir)) {
   126  p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
   127  pud_populate(&init_mm, pud_dir, p);
   128  }
   129  vaddr += PAGE_SIZE;
   130  }
   131  }
   132  

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


.config.gz
Description: application/gzip


Re: [PATCH 1/5] CMDLINE: add generic builtin command line

2021-03-03 Thread Christophe Leroy




Le 04/03/2021 à 05:47, Daniel Walker a écrit :

This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. On x86 and mips they have pretty much the same code and the
code prepends the builtin command line onto the boot loader provided
one. On powerpc there is only a builtin override and nothing else.

The code in this commit unifies the code into a generic
header file under the CONFIG_GENERIC_CMDLINE option. When this
option is enabled the architecture can call the cmdline_add_builtin()
to add the builtin command line.


WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in 
line 1
#32: FILE: include/linux/cmdline.h:1:
+#ifndef _LINUX_CMDLINE_H

CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#56: FILE: include/linux/cmdline.h:25:
+__cmdline_add_builtin(char *dest, const char *src, char *tmp, unsigned long 
length,
+   size_t (*strlcpy)(char *dest, const char *src, size_t size),

WARNING:STRLCPY: Prefer strscpy over strlcpy - see: 
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/

#61: FILE: include/linux/cmdline.h:30:
+   strlcpy(dest, " ", length);

WARNING:STRLCPY: Prefer strscpy over strlcpy - see: 
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/

#69: FILE: include/linux/cmdline.h:38:
+   strlcpy(tmp, CONFIG_CMDLINE_PREPEND " ", length);

WARNING:STRLCPY: Prefer strscpy over strlcpy - see: 
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/

#71: FILE: include/linux/cmdline.h:40:
+   strlcpy(dest, tmp, length);

WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#75: FILE: include/linux/cmdline.h:44:
+#define cmdline_add_builtin_custom(dest, src, length, label, strlcpy, strlcat) 
^I^I^I\$

CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dest' - possible side-effects?
#75: FILE: include/linux/cmdline.h:44:
+#define cmdline_add_builtin_custom(dest, src, length, label, strlcpy, strlcat) 
\
+{  
\
+   if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {   
 \
+   static label char cmdline_tmp_space[length];
\
+   __cmdline_add_builtin(dest, src, cmdline_tmp_space, length, 
strlcpy, strlcat);  \
+   } else if (sizeof(CONFIG_CMDLINE_APPEND) > 1) { 
 \
+   __cmdline_add_builtin(dest, src, NULL, length, strlcpy, 
strlcat);   \
+   }   
\
+}

CHECK:MACRO_ARG_REUSE: Macro argument reuse 'src' - possible side-effects?
#75: FILE: include/linux/cmdline.h:44:
+#define cmdline_add_builtin_custom(dest, src, length, label, strlcpy, strlcat) 
\
+{  
\
+   if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {   
 \
+   static label char cmdline_tmp_space[length];
\
+   __cmdline_add_builtin(dest, src, cmdline_tmp_space, length, 
strlcpy, strlcat);  \
+   } else if (sizeof(CONFIG_CMDLINE_APPEND) > 1) { 
 \
+   __cmdline_add_builtin(dest, src, NULL, length, strlcpy, 
strlcat);   \
+   }   
\
+}

CHECK:MACRO_ARG_REUSE: Macro argument reuse 'length' - possible side-effects?
#75: FILE: include/linux/cmdline.h:44:
+#define cmdline_add_builtin_custom(dest, src, length, label, strlcpy, strlcat) 
\
+{  
\
+   if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {   
 \
+   static label char cmdline_tmp_space[length];
\
+   __cmdline_add_builtin(dest, src, cmdline_tmp_space, length, 
strlcpy, strlcat);  \
+   } else if (sizeof(CONFIG_CMDLINE_APPEND) > 1) { 
 \
+   __cmdline_add_builtin(dest, src, NULL, length, strlcpy, 
strlcat);   \
+   }   
\
+}

CHECK:MACRO_ARG_REUSE: Macro argument reuse 'strlcpy' - possible side-effects?
#75: FILE: include/linux/cmdline.h:44:
+#define cmdline_add_builtin_custom(dest, src, length, label, strlcpy, strlcat) 
\
+{  
  

Re: [PATCH v3] powerpc/uprobes: Validation for prefixed instruction

2021-03-03 Thread Ravi Bangoria




@@ -41,6 +41,14 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
if (addr & 0x03)
return -EINVAL;
  
+	if (!IS_ENABLED(CONFIG_PPC64) || !cpu_has_feature(CPU_FTR_ARCH_31))

+   return 0;


Sorry, I missed this last time, but I think we can drop the above
checks. ppc_inst_prefixed() already factors in the dependency on
CONFIG_PPC64,


Yeah, makes sense. I initially added CONFIG_PPC64 check because
I was using ppc_inst_prefix(x, y) macro which is not available
for !CONFIG_PPC64.


and I don't think we need to confirm if we're running on a
ISA V3.1 for the below check.


Prefixed instructions would be supported only when ARCH_31 is set.
(Ignoring insane scenario where user probes on prefixed instruction
on p10 predecessors). So I guess I still need ARCH_31 check?

Ravi


Re: [PATCH 3/5] CMDLINE: powerpc: convert to generic builtin command line

2021-03-03 Thread Christophe Leroy




Le 04/03/2021 à 05:48, Daniel Walker a écrit :

This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.


CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: arch/powerpc/kernel/prom_init.c:788:
+   cmdline_add_builtin_custom(prom_cmd_line, NULL, 
sizeof(prom_cmd_line),
+   __prombss, &prom_strlcpy, 
&prom_strlcat);

total: 0 errors, 0 warnings, 1 checks, 117 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

the.patch has style problems, please review.

NOTE: Ignored message types: ARCH_INCLUDE_LINUX BIT_MACRO COMPARISON_TO_NULL DT_SPLIT_BINDING_PATCH 
EMAIL_SUBJECT FILE_PATH_CHANGES GLOBAL_INITIALISERS LINE_SPACING MULTIPLE_ASSIGNMENTS


NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.



Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Daniel Walker 
---
  arch/powerpc/Kconfig| 37 +
  arch/powerpc/kernel/prom.c  |  1 +
  arch/powerpc/kernel/prom_init.c | 31 +++
  3 files changed, 20 insertions(+), 49 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 107bb4319e0e..276b06d5c961 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -167,6 +167,7 @@ config PPC
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32
select GENERIC_CLOCKEVENTS_BROADCASTif SMP
+   select GENERIC_CMDLINE
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES  if PPC_BARRIER_NOSPEC
@@ -906,42 +907,6 @@ config PPC_DENORMALISATION
  Add support for handling denormalisation of single precision
  values.  Useful for bare metal only.  If unsure say Y here.
  
-config CMDLINE

-   string "Initial kernel command string"
-   default ""
-   help
- On some platforms, there is currently no way for the boot loader to
- pass arguments to the kernel. For these platforms, you can supply
- some command-line options at build time by entering them here.  In
- most cases you will need to specify the root device here.
-
-choice
-   prompt "Kernel command line type" if CMDLINE != ""
-   default CMDLINE_FROM_BOOTLOADER
-
-config CMDLINE_FROM_BOOTLOADER
-   bool "Use bootloader kernel arguments if available"
-   help
- Uses the command-line options passed by the boot loader. If
- the boot loader doesn't provide any, the default kernel command
- string provided in CMDLINE will be used.
-
-config CMDLINE_EXTEND
-   bool "Extend bootloader kernel arguments"
-   help
- The command-line arguments provided by the boot loader will be
- appended to the default kernel command string.
-
-config CMDLINE_FORCE
-   bool "Always use the default kernel command string"
-   help
- Always use the default kernel command string, even if the boot
- loader passes other arguments to the kernel.
- This is useful if you cannot or don't want to change the
- command-line options your boot loader passes to the kernel.
-
-endchoice
-
  config EXTRA_TARGETS
string "Additional default image types"
help
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index ae3c41730367..96d0a01be1b4 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index e9d4eb6144e1..d752be688b62 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -242,15 +243,6 @@ static int __init prom_strcmp(const char *cs, const char 
*ct)
return 0;
  }
  
-static char __init *prom_strcpy(char *dest, const char *src)

-{
-   char *tmp = dest;
-
-   while ((*dest++ = *src++) != '\0')
-   /* nothing */;
-   return tmp;
-}
-
  static int __init prom_strncmp(const char *cs, const char *ct, size_t count)
  {
unsigned char c1, c2;
@@ -276,6 +268,19 @@ static size_t __init prom_strlen(const char *s)
return sc - s;
  }
  
+static size_t __init prom_strlcpy(char *dest, const char *src, size_t size)

+{
+   size_t ret = prom_strlen(src);
+
+   if (size) {
+   size_t len = (ret >= size) ? size - 1 : ret;
+   memcpy(dest, src, len);
+   dest[len] = '\0';
+   }
+   return ret;
+}
+
+
  static int __init prom_memcmp(const void *cs, const void *ct, size_t count)
  

Re: [PATCH 3/5] CMDLINE: powerpc: convert to generic builtin command line

2021-03-03 Thread Christophe Leroy




Le 04/03/2021 à 05:48, Daniel Walker a écrit :

This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.


In file included from arch/powerpc/kernel/prom_init.c:30:
arch/powerpc/kernel/prom_init.c: In function 'early_cmdline_parse':
arch/powerpc/kernel/prom_init.c:788:17: error: lvalue required as unary '&' 
operand
  788 |  __prombss, &prom_strlcpy, &prom_strlcat);
  | ^
./include/linux/cmdline.h:66:3: note: in definition of macro 
'cmdline_add_builtin_custom'
   66 |   strlcpy(dest, src, length);   \
  |   ^~~
At top level:
arch/powerpc/kernel/prom_init.c:312:22: error: 'prom_strlcat' defined but not used 
[-Werror=unused-function]

  312 | static size_t __init prom_strlcat(char *dest, const char *src, size_t 
count)
  |  ^~~~
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:279: arch/powerpc/kernel/prom_init.o] 
Error 1
make[1]: *** [scripts/Makefile.build:496: arch/powerpc/kernel] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1805: arch/powerpc] Error 2
make: *** Waiting for unfinished jobs



Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Daniel Walker 
---
  arch/powerpc/Kconfig| 37 +
  arch/powerpc/kernel/prom.c  |  1 +
  arch/powerpc/kernel/prom_init.c | 31 +++
  3 files changed, 20 insertions(+), 49 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 107bb4319e0e..276b06d5c961 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -167,6 +167,7 @@ config PPC
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32
select GENERIC_CLOCKEVENTS_BROADCASTif SMP
+   select GENERIC_CMDLINE
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES  if PPC_BARRIER_NOSPEC
@@ -906,42 +907,6 @@ config PPC_DENORMALISATION
  Add support for handling denormalisation of single precision
  values.  Useful for bare metal only.  If unsure say Y here.
  
-config CMDLINE

-   string "Initial kernel command string"
-   default ""
-   help
- On some platforms, there is currently no way for the boot loader to
- pass arguments to the kernel. For these platforms, you can supply
- some command-line options at build time by entering them here.  In
- most cases you will need to specify the root device here.
-
-choice
-   prompt "Kernel command line type" if CMDLINE != ""
-   default CMDLINE_FROM_BOOTLOADER
-
-config CMDLINE_FROM_BOOTLOADER
-   bool "Use bootloader kernel arguments if available"
-   help
- Uses the command-line options passed by the boot loader. If
- the boot loader doesn't provide any, the default kernel command
- string provided in CMDLINE will be used.
-
-config CMDLINE_EXTEND
-   bool "Extend bootloader kernel arguments"
-   help
- The command-line arguments provided by the boot loader will be
- appended to the default kernel command string.
-
-config CMDLINE_FORCE
-   bool "Always use the default kernel command string"
-   help
- Always use the default kernel command string, even if the boot
- loader passes other arguments to the kernel.
- This is useful if you cannot or don't want to change the
- command-line options your boot loader passes to the kernel.
-
-endchoice
-
  config EXTRA_TARGETS
string "Additional default image types"
help
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index ae3c41730367..96d0a01be1b4 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index e9d4eb6144e1..d752be688b62 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -242,15 +243,6 @@ static int __init prom_strcmp(const char *cs, const char 
*ct)
return 0;
  }
  
-static char __init *prom_strcpy(char *dest, const char *src)

-{
-   char *tmp = dest;
-
-   while ((*dest++ = *src++) != '\0')
-   /* nothing */;
-   return tmp;
-}
-
  static int __init prom_strncmp(const char *cs, const char *ct, size_t count)
  {
unsigned char c1, c2;
@@ -276,6 +268,19 @@ static size_t __init prom_strlen(const char *s)
return sc - s;
  }
  
+static size_t __init prom_strlcpy(char *dest, const char *src, size_t size)

+{
+   size_t ret = prom_strlen(src);
+
+   if (size) {
+   size_t len = (ret >= size) ? size - 1 : ret;
+ 

Linux 4.4.259

2021-03-03 Thread Greg Kroah-Hartman
I'm announcing the release of the 4.4.259 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/arm/boot/compressed/head.S |4 
 arch/arm/boot/dts/exynos5250-spring.dts |2 
 arch/arm/boot/dts/exynos5420-arndale-octa.dts   |2 
 arch/mips/kernel/vmlinux.lds.S  |1 
 arch/mips/lantiq/irq.c  |2 
 arch/mips/mm/c-r4k.c|2 
 arch/powerpc/Kconfig|2 
 arch/powerpc/platforms/pseries/dlpar.c  |7 -
 arch/sparc/Kconfig  |2 
 arch/sparc/lib/memset.S |1 
 arch/x86/kernel/reboot.c|   29 ++
 arch/xtensa/platforms/iss/simdisk.c |1 
 block/blk-settings.c|   12 ++
 drivers/amba/bus.c  |   20 ++--
 drivers/block/brd.c |1 
 drivers/block/floppy.c  |   27 +++--
 drivers/block/rbd.c |9 -
 drivers/block/zram/zram_drv.h   |1 
 drivers/clk/meson/clk-pll.c |2 
 drivers/clocksource/mxs_timer.c |5 -
 drivers/dma/fsldma.c|6 +
 drivers/gpio/gpio-pcf857x.c |2 
 drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c  |   22 ++--
 drivers/gpu/drm/gma500/psb_drv.c|2 
 drivers/hid/hid-core.c  |9 +
 drivers/i2c/busses/i2c-brcmstb.c|2 
 drivers/ide/ide-cd.c|8 -
 drivers/ide/ide-cd.h|6 -
 drivers/infiniband/core/user_mad.c  |7 +
 drivers/input/joydev.c  |7 +
 drivers/input/joystick/xpad.c   |1 
 drivers/input/serio/i8042-x86ia64io.h   |4 
 drivers/input/touchscreen/elo.c |4 
 drivers/md/dm-era-target.c  |   93 
 drivers/media/pci/cx25821/cx25821-core.c|4 
 drivers/media/pci/saa7134/saa7134-empress.c |5 -
 drivers/media/usb/dvb-usb-v2/lmedm04.c  |2 
 drivers/media/usb/tm6000/tm6000-dvb.c   |4 
 drivers/media/usb/uvc/uvc_v4l2.c|   18 +--
 drivers/mfd/wm831x-auxadc.c |3 
 drivers/misc/eeprom/eeprom_93xx46.c |1 
 drivers/misc/vmw_vmci/vmci_queue_pair.c |5 -
 drivers/mmc/host/usdhi6rol0.c   |4 
 drivers/net/ethernet/broadcom/bnxt/bnxt.c   |3 
 drivers/net/ethernet/intel/igb/igb_main.c   |2 
 drivers/net/wireless/b43/phy_n.c|2 
 drivers/net/xen-netback/interface.c |9 +
 drivers/nvdimm/dimm_devs.c  |   18 +++
 drivers/nvdimm/nd.h |1 
 drivers/pci/syscall.c   |   10 +-
 drivers/regulator/axp20x-regulator.c|7 -
 drivers/scsi/bnx2fc/Kconfig |1 
 drivers/scsi/gdth.h |3 
 drivers/spi/spi-s3c24xx-fiq.S   |9 -
 drivers/staging/rtl8188eu/os_dep/usb_intf.c |1 
 drivers/usb/core/quirks.c   |3 
 drivers/usb/dwc2/hcd_intr.c |   14 ++-
 drivers/usb/dwc3/gadget.c   |   19 +++-
 drivers/usb/renesas_usbhs/fifo.c|2 
 drivers/usb/serial/mos7720.c|4 
 drivers/usb/serial/mos7840.c|4 
 drivers/usb/serial/option.c |3 
 drivers/video/fbdev/Kconfig |2 
 fs/btrfs/free-space-cache.c |6 +
 fs/btrfs/relocation.c   |4 
 fs/f2fs/file.c  |3 
 fs/gfs2/lock_dlm.c  |8 -
 fs/isofs/dir.c  |1 
 fs/isofs/namei.c|1 
 fs/jffs2/summary.c  |3 
 fs/jfs/jfs_dmap.c   |2 
 fs/ntfs/inode.c |6 +
 include/linux/blkdev.h  |  

Linux 4.9.259

2021-03-03 Thread Greg Kroah-Hartman
I'm announcing the release of the 4.9.259 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/arm/boot/compressed/head.S   |4 
 arch/arm/boot/dts/exynos5250-spring.dts   |2 
 arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 
 arch/arm/boot/dts/omap443x.dtsi   |2 
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts   |2 
 arch/arm64/boot/dts/nvidia/tegra210.dtsi  |1 
 arch/arm64/boot/dts/qcom/msm8916.dtsi |4 
 arch/arm64/kernel/head.S  |1 
 arch/mips/kernel/vmlinux.lds.S|1 
 arch/mips/lantiq/irq.c|2 
 arch/mips/mm/c-r4k.c  |2 
 arch/powerpc/Kconfig  |2 
 arch/powerpc/platforms/pseries/dlpar.c|7 -
 arch/sparc/Kconfig|2 
 arch/sparc/lib/memset.S   |1 
 arch/x86/kernel/reboot.c  |   29 +
 block/blk-settings.c  |   12 ++
 crypto/ecdh_helper.c  |3 
 drivers/acpi/acpi_configfs.c  |7 +
 drivers/amba/bus.c|   20 ++-
 drivers/ata/ahci_brcm.c   |   14 ++
 drivers/block/floppy.c|   27 ++---
 drivers/char/random.c |2 
 drivers/clk/meson/clk-pll.c   |2 
 drivers/clocksource/mxs_timer.c   |5 
 drivers/dma/fsldma.c  |6 +
 drivers/gpio/gpio-pcf857x.c   |2 
 drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c|   22 ++--
 drivers/gpu/drm/gma500/psb_drv.c  |2 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c|2 
 drivers/hid/hid-core.c|9 +
 drivers/i2c/busses/i2c-brcmstb.c  |2 
 drivers/infiniband/core/user_mad.c|7 +
 drivers/infiniband/sw/rxe/rxe_recv.c  |   11 +-
 drivers/input/joydev.c|7 -
 drivers/input/joystick/xpad.c |1 
 drivers/input/serio/i8042-x86ia64io.h |4 
 drivers/input/touchscreen/elo.c   |4 
 drivers/input/touchscreen/raydium_i2c_ts.c|3 
 drivers/md/dm-era-target.c|   93 +++---
 drivers/media/pci/cx25821/cx25821-core.c  |4 
 drivers/media/pci/saa7134/saa7134-empress.c   |5 
 drivers/media/platform/pxa_camera.c   |3 
 drivers/media/platform/vsp1/vsp1_drv.c|4 
 drivers/media/tuners/qm1d1c0042.c |4 
 drivers/media/usb/dvb-usb-v2/lmedm04.c|2 
 drivers/media/usb/tm6000/tm6000-dvb.c |4 
 drivers/media/usb/uvc/uvc_v4l2.c  |   18 +--
 drivers/mfd/wm831x-auxadc.c   |3 
 drivers/misc/eeprom/eeprom_93xx46.c   |1 
 drivers/misc/vmw_vmci/vmci_queue_pair.c   |5 
 drivers/mmc/host/sdhci-esdhc-imx.c|3 
 drivers/mmc/host/usdhi6rol0.c |4 
 drivers/mtd/spi-nor/cadence-quadspi.c |2 
 drivers/mtd/spi-nor/hisi-sfc.c|4 
 drivers/net/ethernet/broadcom/bnxt/bnxt.c |3 
 drivers/net/ethernet/intel/i40e/i40e_txrx.c   |9 +
 drivers/net/ethernet/intel/igb/igb_main.c |2 
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c |1 
 drivers/net/ethernet/sun/sunvnet_common.c |   24 
 drivers/net/gtp.c |5 
 drivers/net/usb/qmi_wwan.c|1 
 drivers/net/wireless/broadcom/b43/phy_n.c |2 
 drivers/net/xen-netback/interface.c   |8 -
 drivers/nvdimm/dimm_devs.c|   18 ++-
 drivers/of/fdt.c  |   12 +-
 drivers/pci/syscall.c |   10 -
 drivers/power/reset/at91-sama5d2_shdwc.c  |2 
 drivers/pwm/pwm-rockchip.c|1 
 drivers/regulator/axp20x-regulator.c  |7 -
 drivers/scsi/bnx2fc/Kconfig  

Re: Linux 4.14.223

2021-03-03 Thread Greg Kroah-Hartman
diff --git a/Makefile b/Makefile
index 101b789e7c2b..b8ab01786d09 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 222
+SUBLEVEL = 223
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 8ca539bdac35..becd5d4bc3a6 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -1088,9 +1088,9 @@ __armv4_mmu_cache_off:
 __armv7_mmu_cache_off:
mrc p15, 0, r0, c1, c0
 #ifdef CONFIG_MMU
-   bic r0, r0, #0x000d
+   bic r0, r0, #0x0005
 #else
-   bic r0, r0, #0x000c
+   bic r0, r0, #0x0004
 #endif
mcr p15, 0, r0, c1, c0  @ turn MMU and cache off
mov r12, lr
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index bbdfcbc6e7d2..4334311d3b47 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -191,7 +191,7 @@
s2mps14_pmic@66 {
compatible = "samsung,s2mps14-pmic";
interrupt-parent = <&gpx0>;
-   interrupts = <7 IRQ_TYPE_NONE>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
reg = <0x66>;
wakeup-source;
 
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 0b45467d77a8..c0c3b185b731 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -274,7 +274,7 @@
s2mps14_pmic@66 {
compatible = "samsung,s2mps14-pmic";
interrupt-parent = <&gpx0>;
-   interrupts = <7 IRQ_TYPE_NONE>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
reg = <0x66>;
wakeup-source;
 
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index d53bfcbeb39c..1f2d4e51824b 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -111,7 +111,7 @@
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
interrupt-parent = <&gpx3>;
-   interrupts = <2 IRQ_TYPE_NONE>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&s5m8767_irq &s5m8767_dvs &s5m8767_ds>;
wakeup-source;
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 38538211a967..ab76c575b67a 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -87,7 +87,7 @@
reg = <0x66>;
 
interrupt-parent = <&gpx3>;
-   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&s2mps11_irq>;
 
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 03c8ad91ddac..5b4aa8f38e8e 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -35,10 +35,12 @@
};
 
ocp {
+   /* 4430 has only gpio_86 tshut and no talert interrupt */
bandgap: bandgap@4a002260 {
reg = <0x4a002260 0x4
   0x4a00232C 0x4>;
compatible = "ti,omap4430-bandgap";
+   gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
 
#thermal-sensor-cells = <0>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 297597442c44..7de6a187ba8f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -343,7 +343,7 @@
s2mps13-pmic@66 {
compatible = "samsung,s2mps13-pmic";
interrupt-parent = <&gpa0>;
-   interrupts = <7 IRQ_TYPE_NONE>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
reg = <0x66>;
samsung,s2mps11-wrstbi-ground;
 
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index c8824b918693..a85ad9f55cda 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -88,7 +88,7 @@
s2mps15_pmic@66 {
compatible = "samsung,s2mps15-pmic";
reg = <0x66>;
-   interrupts = <2 IRQ_TYPE_NONE>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpa0>;
pinctrl-names = "default";
pinctrl-0 = <&pmic_irq>;
diff --git a/arch/arm64/boot/dts/nvidi

[PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue

2021-03-03 Thread Tony Lindgren
There is a timer wrap issue on dra7 for the ARM architected timer.
In a typical clock configuration the timer fails to wrap after 388 days.

To work around the issue, we need to use timer-ti-dm timers instead.

Let's prepare for adding support for percpu timers by adding a common
dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init().
This patch makes no intentional functional changes.

Signed-off-by: Tony Lindgren 
---
 drivers/clocksource/timer-ti-dm-systimer.c | 72 +++---
 1 file changed, 49 insertions(+), 23 deletions(-)

diff --git a/drivers/clocksource/timer-ti-dm-systimer.c 
b/drivers/clocksource/timer-ti-dm-systimer.c
--- a/drivers/clocksource/timer-ti-dm-systimer.c
+++ b/drivers/clocksource/timer-ti-dm-systimer.c
@@ -528,17 +528,18 @@ static void omap_clockevent_unidle(struct 
clock_event_device *evt)
writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->wakeup);
 }
 
-static int __init dmtimer_clockevent_init(struct device_node *np)
+static int __init dmtimer_clkevt_init_common(struct dmtimer_clockevent *clkevt,
+struct device_node *np,
+unsigned int features,
+const struct cpumask *cpumask,
+const char *name,
+int rating)
 {
-   struct dmtimer_clockevent *clkevt;
struct clock_event_device *dev;
struct dmtimer_systimer *t;
+   unsigned long irqflags;
int error;
 
-   clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL);
-   if (!clkevt)
-   return -ENOMEM;
-
t = &clkevt->t;
dev = &clkevt->dev;
 
@@ -546,25 +547,23 @@ static int __init dmtimer_clockevent_init(struct 
device_node *np)
 * We mostly use cpuidle_coupled with ARM local timers for runtime,
 * so there's probably no use for CLOCK_EVT_FEAT_DYNIRQ here.
 */
-   dev->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
-   dev->rating = 300;
+   dev->features = features;
+   dev->rating = rating;
dev->set_next_event = dmtimer_set_next_event;
dev->set_state_shutdown = dmtimer_clockevent_shutdown;
dev->set_state_periodic = dmtimer_set_periodic;
dev->set_state_oneshot = dmtimer_clockevent_shutdown;
dev->set_state_oneshot_stopped = dmtimer_clockevent_shutdown;
dev->tick_resume = dmtimer_clockevent_shutdown;
-   dev->cpumask = cpu_possible_mask;
+   dev->cpumask = cpumask;
 
dev->irq = irq_of_parse_and_map(np, 0);
-   if (!dev->irq) {
-   error = -ENXIO;
-   goto err_out_free;
-   }
+   if (!dev->irq)
+   return -ENXIO;
 
error = dmtimer_systimer_setup(np, &clkevt->t);
if (error)
-   goto err_out_free;
+   return error;
 
clkevt->period = 0x - DIV_ROUND_CLOSEST(t->rate, HZ);
 
@@ -575,33 +574,60 @@ static int __init dmtimer_clockevent_init(struct 
device_node *np)
 */
writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl);
 
+   if (dev->cpumask == cpu_possible_mask)
+   irqflags = IRQF_TIMER;
+   else
+   irqflags = IRQF_TIMER | IRQF_NOBALANCING;
+
error = request_irq(dev->irq, dmtimer_clockevent_interrupt,
-   IRQF_TIMER, "clockevent", clkevt);
+   irqflags, name, clkevt);
if (error)
goto err_out_unmap;
 
writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->irq_ena);
writel_relaxed(OMAP_TIMER_INT_OVERFLOW, t->base + t->wakeup);
 
-   pr_info("TI gptimer clockevent: %s%lu Hz at %pOF\n",
-   of_find_property(np, "ti,timer-alwon", NULL) ?
+   pr_info("TI gptimer %s: %s%lu Hz at %pOF\n",
+   name, of_find_property(np, "ti,timer-alwon", NULL) ?
"always-on " : "", t->rate, np->parent);
 
-   clockevents_config_and_register(dev, t->rate,
+   return 0;
+
+err_out_unmap:
+   iounmap(t->base);
+
+   return error;
+}
+
+static int __init dmtimer_clockevent_init(struct device_node *np)
+{
+   struct dmtimer_clockevent *clkevt;
+   int error;
+
+   clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL);
+   if (!clkevt)
+   return -ENOMEM;
+
+   error = dmtimer_clkevt_init_common(clkevt, np,
+  CLOCK_EVT_FEAT_PERIODIC |
+  CLOCK_EVT_FEAT_ONESHOT,
+  cpu_possible_mask, "clockevent",
+  300);
+   if (error)
+   goto err_out_free;
+
+   clockevents_config_and_register(&clkevt->dev, clkevt->t.rate,
3, /* Timer internal resynch latency */
0xfff

[rcu:dev.2021.03.03a] BUILD SUCCESS 2a75054f76b2f5c6e1bdc89ec4cc8538129897b0

2021-03-03 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2021.03.03a
branch HEAD: 2a75054f76b2f5c6e1bdc89ec4cc8538129897b0  kcsan, debugfs: Move 
debugfs file creation out of early init

elapsed time: 725m

configs tested: 94
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
m68k alldefconfig
mips   capcella_defconfig
powerpc wii_defconfig
powerpc  pmac32_defconfig
m68k  multi_defconfig
sh sh03_defconfig
arcvdk_hs38_smp_defconfig
microblaze  defconfig
shsh7757lcr_defconfig
arm bcm2835_defconfig
parisc   alldefconfig
armlart_defconfig
arm  lpd270_defconfig
arm davinci_all_defconfig
sh  defconfig
archsdk_defconfig
powerpc  ppc64e_defconfig
arm   multi_v4t_defconfig
arm   sunxi_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a005-20210303
i386 randconfig-a003-20210303
i386 randconfig-a002-20210303
i386 randconfig-a004-20210303
i386 randconfig-a006-20210303
i386 randconfig-a001-20210303
x86_64   randconfig-a013-20210303
x86_64   randconfig-a016-20210303
x86_64   randconfig-a015-20210303
x86_64   randconfig-a014-20210303
x86_64   randconfig-a012-20210303
x86_64   randconfig-a011-20210303
i386 randconfig-a016-20210303
i386 randconfig-a012-20210303
i386 randconfig-a014-20210303
i386 randconfig-a013-20210303
i386 randconfig-a011-20210303
i386 randconfig-a015-20210303
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   allyesconfig
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-a006-20210303
x86_64   randconfig-a001-20210303
x86_64   randconfig-a004-20210303
x86_64   randconfig-a002-20210303
x86_64   randconfig-a005-20210303
x86_64   randconfig-a003-20210303

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


Linux 4.14.223

2021-03-03 Thread Greg Kroah-Hartman
I'm announcing the release of the 4.14.223 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/arm/boot/compressed/head.S   |4 
 arch/arm/boot/dts/exynos3250-monk.dts |2 
 arch/arm/boot/dts/exynos3250-rinato.dts   |2 
 arch/arm/boot/dts/exynos5250-spring.dts   |2 
 arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 
 arch/arm/boot/dts/omap443x.dtsi   |2 
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi |2 
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts   |2 
 arch/arm64/boot/dts/nvidia/tegra210.dtsi  |1 
 arch/arm64/boot/dts/qcom/msm8916.dtsi |4 
 arch/arm64/kernel/head.S  |1 
 arch/arm64/kernel/probes/uprobes.c|2 
 arch/mips/kernel/vmlinux.lds.S|1 
 arch/mips/lantiq/irq.c|2 
 arch/mips/mm/c-r4k.c  |2 
 arch/powerpc/Kconfig  |2 
 arch/powerpc/kernel/head_8xx.S|2 
 arch/powerpc/platforms/pseries/dlpar.c|7 -
 arch/sparc/Kconfig|2 
 arch/sparc/lib/memset.S   |1 
 arch/x86/kernel/reboot.c  |   29 +---
 block/blk-settings.c  |   12 +
 certs/blacklist.c |2 
 crypto/ecdh_helper.c  |3 
 drivers/acpi/acpi_configfs.c  |7 -
 drivers/acpi/property.c   |   44 --
 drivers/amba/bus.c|   20 +-
 drivers/ata/ahci_brcm.c   |   14 +-
 drivers/auxdisplay/ht16k33.c  |3 
 drivers/block/floppy.c|   27 ++-
 drivers/bluetooth/btqcomsmd.c |   27 ++-
 drivers/char/hw_random/timeriomem-rng.c   |2 
 drivers/char/random.c |2 
 drivers/char/tpm/tpm_tis_core.c   |3 
 drivers/clk/meson/clk-pll.c   |2 
 drivers/clocksource/mxs_timer.c   |5 
 drivers/cpufreq/brcmstb-avs-cpufreq.c |3 
 drivers/crypto/bcm/cipher.c   |2 
 drivers/crypto/bcm/cipher.h   |4 
 drivers/crypto/bcm/util.c |2 
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c |  125 ++
 drivers/dma/fsldma.c  |6 
 drivers/dma/hsu/pci.c |   21 +--
 drivers/gpio/gpio-pcf857x.c   |2 
 drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c|   22 +--
 drivers/gpu/drm/gma500/psb_drv.c  |2 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c|2 
 drivers/hid/hid-core.c|9 -
 drivers/hid/wacom_wac.c   |7 -
 drivers/hv/channel_mgmt.c |3 
 drivers/i2c/busses/i2c-brcmstb.c  |2 
 drivers/infiniband/core/user_mad.c|7 -
 drivers/infiniband/sw/rxe/rxe_recv.c  |   11 +
 drivers/input/joydev.c|7 -
 drivers/input/joystick/xpad.c |1 
 drivers/input/serio/i8042-x86ia64io.h |4 
 drivers/input/touchscreen/elo.c   |4 
 drivers/input/touchscreen/raydium_i2c_ts.c|3 
 drivers/md/dm-era-target.c|   93 -
 drivers/media/i2c/ov5670.c|3 
 drivers/media/pci/cx25821/cx25821-core.c  |4 
 drivers/media/pci/saa7134/saa7134-empress.c   |5 
 drivers/media/platform/pxa_camera.c   |3 
 drivers/media/platform/vsp1/vsp1_drv.c|4 
 drivers/media/tuners/qm1d1c0042.c |4 
 drivers/media/usb/dvb-usb-v2/lmedm04.c|2 
 drivers/media/usb/tm6000/tm6000-dvb.c |4 
 drivers/media/usb/uvc/uvc_v4l2.c  |   18 +-
 drivers/mfd/bd9571mwv.c   |6 
 drivers/mfd/wm831x-auxadc.c   |3 
 drivers/misc/eeprom/eeprom_93xx46.c  

[PATCH 2/2] clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940

2021-03-03 Thread Tony Lindgren
There is a timer wrap issue on dra7 for the ARM architected timer.
In a typical clock configuration the timer fails to wrap after 388 days.

To work around the issue, we need to use timer-ti-dm percpu timers instead.

Let's configure dmtimer3 and 4 as percpu timers by default, and warn about
the issue if the dtb is not configured properly.

Let's do this as a single patch so it can be backported to v5.8 and later
kernels easily. Note that this patch depends on earlier timer-ti-dm
systimer posted mode fixes, and a preparatory clockevent patch
"clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue".

For more information, please see the errata for "AM572x Sitara Processors
Silicon Revisions 1.1, 2.0":

https://www.ti.com/lit/er/sprz429m/sprz429m.pdf

The concept is based on earlier reference patches done by Tero Kristo and
Keerthy.

Cc: Keerthy 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dra7-l4.dtsi |  4 +-
 arch/arm/boot/dts/dra7.dtsi| 20 ++
 drivers/clocksource/timer-ti-dm-systimer.c | 76 ++
 include/linux/cpuhotplug.h |  1 +
 4 files changed, 99 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -1168,7 +1168,7 @@ timer2: timer@0 {
};
};
 
-   target-module@34000 {   /* 0x48034000, ap 7 
46.0 */
+   timer3_target: target-module@34000 {/* 0x48034000, ap 7 
46.0 */
compatible = "ti,sysc-omap4-timer", "ti,sysc";
reg = <0x34000 0x4>,
  <0x34010 0x4>;
@@ -1195,7 +1195,7 @@ timer3: timer@0 {
};
};
 
-   target-module@36000 {   /* 0x48036000, ap 9 
4e.0 */
+   timer4_target: target-module@36000 {/* 0x48036000, ap 9 
4e.0 */
compatible = "ti,sysc-omap4-timer", "ti,sysc";
reg = <0x36000 0x4>,
  <0x36010 0x4>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -46,6 +46,7 @@ aliases {
 
timer {
compatible = "arm,armv7-timer";
+   status = "disabled";/* See ARM architected timer wrap 
erratum i940 */
interrupts = ,
 ,
 ,
@@ -1241,3 +1242,22 @@ timer@0 {
assigned-clock-parents = <&sys_32k_ck>;
};
 };
+
+/* Local timers, see ARM architected timer wrap erratum i940 */
+&timer3_target {
+   ti,no-reset-on-init;
+   ti,no-idle;
+   timer@0 {
+   assigned-clocks = <&l4per_clkctrl DRA7_L4PER_TIMER3_CLKCTRL 24>;
+   assigned-clock-parents = <&timer_sys_clk_div>;
+   };
+};
+
+&timer4_target {
+   ti,no-reset-on-init;
+   ti,no-idle;
+   timer@0 {
+   assigned-clocks = <&l4per_clkctrl DRA7_L4PER_TIMER4_CLKCTRL 24>;
+   assigned-clock-parents = <&timer_sys_clk_div>;
+   };
+};
diff --git a/drivers/clocksource/timer-ti-dm-systimer.c 
b/drivers/clocksource/timer-ti-dm-systimer.c
--- a/drivers/clocksource/timer-ti-dm-systimer.c
+++ b/drivers/clocksource/timer-ti-dm-systimer.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -634,6 +635,78 @@ static int __init dmtimer_clockevent_init(struct 
device_node *np)
return error;
 }
 
+/* Dmtimer as percpu timer. See dra7 ARM architected timer wrap erratum i940 */
+static DEFINE_PER_CPU(struct dmtimer_clockevent, dmtimer_percpu_timer);
+
+static int __init dmtimer_percpu_timer_init(struct device_node *np, int cpu)
+{
+   struct dmtimer_clockevent *clkevt;
+   int error;
+
+   if (!cpu_possible(cpu))
+   return -EINVAL;
+
+   if (!of_property_read_bool(np->parent, "ti,no-reset-on-init") ||
+   !of_property_read_bool(np->parent, "ti,no-idle"))
+   pr_warn("Incomplete dtb for percpu dmtimer %pOF\n", np->parent);
+
+   clkevt = per_cpu_ptr(&dmtimer_percpu_timer, cpu);
+
+   error = dmtimer_clkevt_init_common(clkevt, np, CLOCK_EVT_FEAT_ONESHOT,
+  cpumask_of(cpu), "percpu-dmtimer",
+  500);
+   if (error)
+   return error;
+
+   return 0;
+}
+
+/* See TRM for timer internal resynch latency */
+static int omap_dmtimer_starting_cpu(unsigned int cpu)
+{
+   struct dmtimer_clockevent *clkevt = per_cpu_ptr(&dmtimer_percpu_timer, 
cpu);
+   struct clock_event_device *dev = &clkevt->dev;
+   struct dmtimer_systimer *t = &clkevt->t;
+
+   clockevents_config_and_register(dev, t->rate, 3, ULONG_MAX);
+   irq_force_af

Re: Linux 4.9.259

2021-03-03 Thread Greg Kroah-Hartman
diff --git a/Makefile b/Makefile
index e5955f122ffd..cdc71bda92c4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 258
+SUBLEVEL = 259
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index a67ed746b0e3..5fa0beba46ee 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -1080,9 +1080,9 @@ __armv4_mmu_cache_off:
 __armv7_mmu_cache_off:
mrc p15, 0, r0, c1, c0
 #ifdef CONFIG_MMU
-   bic r0, r0, #0x000d
+   bic r0, r0, #0x0005
 #else
-   bic r0, r0, #0x000c
+   bic r0, r0, #0x0004
 #endif
mcr p15, 0, r0, c1, c0  @ turn MMU and cache off
mov r12, lr
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index 4d7bdb735ed3..e4433ecd9fe4 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -112,7 +112,7 @@
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
interrupt-parent = <&gpx3>;
-   interrupts = <2 IRQ_TYPE_NONE>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&s5m8767_irq &s5m8767_dvs &s5m8767_ds>;
wakeup-source;
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index e664c33c3c64..4a71bbe1ce54 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -88,7 +88,7 @@
reg = <0x66>;
 
interrupt-parent = <&gpx3>;
-   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&s2mps11_irq>;
 
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index fc6a8610c24c..adcf9d141db6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -35,10 +35,12 @@
};
 
ocp {
+   /* 4430 has only gpio_86 tshut and no talert interrupt */
bandgap: bandgap@4a002260 {
reg = <0x4a002260 0x4
   0x4a00232C 0x4>;
compatible = "ti,omap4430-bandgap";
+   gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
 
#thermal-sensor-cells = <0>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 2f7d144d556d..e43e804c42c3 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -64,7 +64,7 @@
s2mps15_pmic@66 {
compatible = "samsung,s2mps15-pmic";
reg = <0x66>;
-   interrupts = <2 IRQ_TYPE_NONE>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpa0>;
pinctrl-names = "default";
pinctrl-0 = <&pmic_irq>;
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 87ef72bffd86..7501bfc2b0f1 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -727,6 +727,7 @@
 <&tegra_car 128>, /* hda2hdmi */
 <&tegra_car 111>; /* hda2codec_2x */
reset-names = "hda", "hda2hdmi", "hda2codec_2x";
+   power-domains = <&pd_sor>;
status = "disabled";
};
 
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index fb5001a6879c..c2557cf43b3d 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -62,7 +62,7 @@
no-map;
};
 
-   reserved@8668000 {
+   reserved@8668 {
reg = <0x0 0x8668 0x0 0x8>;
no-map;
};
@@ -72,7 +72,7 @@
no-map;
};
 
-   rfsa@867e0 {
+   rfsa@867e {
reg = <0x0 0x867e 0x0 0x2>;
no-map;
};
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index aba534959377..387542383662 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -846,6 +846,7 @@ __primary_switch:
 
tlbivmalle1 // Remove any stale TLB entries
dsb nsh
+   isb
 
msr sctlr_el1, x19  // re-enable the MMU
isb
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index 612b2b30

[PATCH 0/2] Fixes for for dra7 timer wrap errata i940

2021-03-03 Thread Tony Lindgren
Hi all,

Here are fixes for dra7 ARM architected timer wrap errata i940 where it
fails to wrap after 388 days. The workaround is to use two dmtimers as
the local timers instead.

Note that these patches depend on timer posted mode fixes series
"[PATCH 0/3] Fixes for timer-ti-dm systimer posted mode" for the write
status register check fix. Also the spurious timer interrupt fix is
good to have from that series.

Regards,

Tony


Tony Lindgren (2):
  clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap
issue
  clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940

 arch/arm/boot/dts/dra7-l4.dtsi |   4 +-
 arch/arm/boot/dts/dra7.dtsi|  20 +++
 drivers/clocksource/timer-ti-dm-systimer.c | 148 +
 include/linux/cpuhotplug.h |   1 +
 4 files changed, 148 insertions(+), 25 deletions(-)

-- 
2.30.1


Re: Linux 4.4.259

2021-03-03 Thread Greg Kroah-Hartman
diff --git a/Makefile b/Makefile
index abf7b5aa99bb..a8c906a79f34 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 258
+SUBLEVEL = 259
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 856913705169..082d036e9564 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -1074,9 +1074,9 @@ __armv4_mmu_cache_off:
 __armv7_mmu_cache_off:
mrc p15, 0, r0, c1, c0
 #ifdef CONFIG_MMU
-   bic r0, r0, #0x000d
+   bic r0, r0, #0x0005
 #else
-   bic r0, r0, #0x000c
+   bic r0, r0, #0x0004
 #endif
mcr p15, 0, r0, c1, c0  @ turn MMU and cache off
mov r12, lr
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d038a9..4b3bd43f7721 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -112,7 +112,7 @@
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
interrupt-parent = <&gpx3>;
-   interrupts = <2 IRQ_TYPE_NONE>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&s5m8767_irq &s5m8767_dvs &s5m8767_ds>;
wakeup-source;
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index b54c0b8a5b34..5cf9bcc91c4a 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -75,7 +75,7 @@
s2mps11,buck4-ramp-enable = <1>;
 
interrupt-parent = <&gpx3>;
-   interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&s2mps11_irq>;
 
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index 2026203c41e2..ce0654b07c90 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -90,6 +90,7 @@ SECTIONS
 
INIT_TASK_DATA(THREAD_SIZE)
NOSAVE_DATA
+   PAGE_ALIGNED_DATA(PAGE_SIZE)
CACHELINE_ALIGNED_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
READ_MOSTLY_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
DATA_DATA
diff --git a/arch/mips/lantiq/irq.c b/arch/mips/lantiq/irq.c
index a7057a06c096..5526b89a21a0 100644
--- a/arch/mips/lantiq/irq.c
+++ b/arch/mips/lantiq/irq.c
@@ -245,7 +245,7 @@ static void ltq_hw_irqdispatch(int module)
do_IRQ((int)irq + MIPS_CPU_IRQ_CASCADE + (INT_NUM_IM_OFFSET * module));
 
/* if this is a EBU irq, we need to ack it or get a deadlock */
-   if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT)
+   if (irq == LTQ_ICU_EBU_IRQ && !module && LTQ_EBU_PCC_ISTAT != 0)
ltq_ebu_w32(ltq_ebu_r32(LTQ_EBU_PCC_ISTAT) | 0x10,
LTQ_EBU_PCC_ISTAT);
 }
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 6c0147bd8e80..90f8d6d51f31 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1401,7 +1401,7 @@ static int probe_scache(void)
return 1;
 }
 
-static void __init loongson2_sc_init(void)
+static void loongson2_sc_init(void)
 {
struct cpuinfo_mips *c = ¤t_cpu_data;
 
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4ece20178145..735f99906a32 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -577,7 +577,7 @@ config PPC_64K_PAGES
 
 config PPC_256K_PAGES
bool "256k page size"
-   depends on 44x && !STDBINUTILS
+   depends on 44x && !STDBINUTILS && !PPC_47x
help
  Make the page size 256k.
 
diff --git a/arch/powerpc/platforms/pseries/dlpar.c 
b/arch/powerpc/platforms/pseries/dlpar.c
index 551ba5b35df9..91a667d8b1e9 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -131,7 +131,6 @@ void dlpar_free_cc_nodes(struct device_node *dn)
 #define NEXT_PROPERTY   3
 #define PREV_PARENT 4
 #define MORE_MEMORY 5
-#define CALL_AGAIN -2
 #define ERR_CFG_USE -9003
 
 struct device_node *dlpar_configure_connector(__be32 drc_index,
@@ -173,6 +172,9 @@ struct device_node *dlpar_configure_connector(__be32 
drc_index,
 
spin_unlock(&rtas_data_buf_lock);
 
+   if (rtas_busy_delay(rc))
+   continue;
+
switch (rc) {
case COMPLETE:
break;
@@ -225,9 +227,6 @@ struct device_node *dlpar_configure_connector(__be32 
drc_index,
parent_path = last_dn->parent->full_name;
break;
 
-   case CALL_AGAIN:
-   break;
-
case MORE_MEMORY:

Re: [PATCH] char: lp: remove redundant space

2021-03-03 Thread Greg KH
On Thu, Mar 04, 2021 at 03:21:47PM +0800, maqiang wrote:
> These two lines of code don't meet the kernel coding style,
> so remove the redundant space.
> 
> Signed-off-by: Qiang Ma 
> Signed-off-by: maqiang 

Why do you have 2 signed-off-by lines with the same email address, but
different names?

If you want to start out in kernel development for coding style fixes, I
recommend doing so in drivers/staging/ as patches there for things like
this are more welcome than other parts of the kernel.

thanks,

greg k-h


Re: [PATCH v3] powerpc/uprobes: Validation for prefixed instruction

2021-03-03 Thread Christophe Leroy




Le 04/03/2021 à 06:05, Ravi Bangoria a écrit :

As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on such prefixed instruction.

There are two ways probed instruction is changed in mapped pages.
First, when Uprobe is activated, it searches for all the relevant
pages and replace instruction in them. In this case, if that probe
is on the 64-byte unaligned prefixed instruction, error out
directly. Second, when Uprobe is already active and user maps a
relevant page via mmap(), instruction is replaced via mmap() code
path. But because Uprobe is invalid, entire mmap() operation can
not be stopped. In this case just print an error and continue.

Signed-off-by: Ravi Bangoria 
---
v2: 
https://lore.kernel.org/r/20210204104703.273429-1-ravi.bango...@linux.ibm.com
v2->v3:
   - Drop restriction for Uprobe on suffix of prefixed instruction.
 It needs lot of code change including generic code but what
 we get in return is not worth it.

  arch/powerpc/kernel/uprobes.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index e8a63713e655..c400971ebe70 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -41,6 +41,14 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
if (addr & 0x03)
return -EINVAL;
  
+	if (!IS_ENABLED(CONFIG_PPC64) || !cpu_has_feature(CPU_FTR_ARCH_31))


cpu_has_feature(CPU_FTR_ARCH_31) should return 'false' when CONFIG_PPC64 is not enabled, no need to 
double check.



+   return 0;
+
+   if (ppc_inst_prefixed(auprobe->insn) && (addr & 0x3F) == 0x3C) {


Maybe 3C instead of 4F ? : (addr & 0x3C) == 0x3C

What about

(addr & (SZ_64 - 4)) == SZ_64 - 4 to make it more explicit ?

Or ALIGN(addr, SZ_64) != ALIGN(addr + 8, SZ_64)


+   pr_info_ratelimited("Cannot register a uprobe on 64 byte unaligned 
prefixed instruction\n");
+   return -EINVAL;
+   }
+
return 0;
  }
  



Christophe


[PATCH v5 2/2] hwrng: bcm2835: add reset support

2021-03-03 Thread Álvaro Fernández Rojas
BCM6368 devices need to reset the in order to generate true random numbers.
This is what BCM6368 produces without a reset:
root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000
rngtest 6.10
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 2032
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 1000
rngtest: FIPS 140-2(2001-10-10) Monobit: 2
rngtest: FIPS 140-2(2001-10-10) Poker: 1000
rngtest: FIPS 140-2(2001-10-10) Runs: 1000
rngtest: FIPS 140-2(2001-10-10) Long run: 30
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=37.253; avg=320.827; max=635.783)Mibits/s
rngtest: FIPS tests speed: (min=12.141; avg=15.034; max=16.428)Mibits/s
rngtest: Program run time: 1336176 microseconds
cat: write error: Broken pipe

Signed-off-by: Álvaro Fernández Rojas 
---
 v5: remove reset_control_rearm().
 v4: add reset_control_rearm().
 v3: no changes.
 v2: no changes.

 drivers/char/hw_random/bcm2835-rng.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/char/hw_random/bcm2835-rng.c 
b/drivers/char/hw_random/bcm2835-rng.c
index be5be395b341..e7dd457e9b22 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define RNG_CTRL   0x0
 #define RNG_STATUS 0x4
@@ -32,6 +33,7 @@ struct bcm2835_rng_priv {
void __iomem *base;
bool mask_interrupts;
struct clk *clk;
+   struct reset_control *reset;
 };
 
 static inline struct bcm2835_rng_priv *to_rng_priv(struct hwrng *rng)
@@ -92,6 +94,10 @@ static int bcm2835_rng_init(struct hwrng *rng)
if (ret)
return ret;
 
+   ret = reset_control_reset(priv->reset);
+   if (ret)
+   return ret;
+
if (priv->mask_interrupts) {
/* mask the interrupt */
val = rng_readl(priv, RNG_INT_MASK);
@@ -156,6 +162,10 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
if (IS_ERR(priv->clk))
return PTR_ERR(priv->clk);
 
+   priv->reset = devm_reset_control_get_optional_exclusive(dev, NULL);
+   if (IS_ERR(priv->reset))
+   return PTR_ERR(priv->reset);
+
priv->rng.name = pdev->name;
priv->rng.init = bcm2835_rng_init;
priv->rng.read = bcm2835_rng_read;
-- 
2.20.1



[PATCH v5 0/2] hwrng: bcm2835: add reset support

2021-03-03 Thread Álvaro Fernández Rojas
v5: remove reset_control_rearm() and apply on latest herbert/cryptodev-2.6.git.
v4: fix documentation, add reset_control_rearm().
v3: make resets required if brcm,bcm6368-rng.
v2: document reset support.

Álvaro Fernández Rojas (2):
  dt-bindings: rng: bcm2835: document reset support
  hwrng: bcm2835: add reset support

 .../devicetree/bindings/rng/brcm,bcm2835.yaml   | 17 +
 drivers/char/hw_random/bcm2835-rng.c| 10 ++
 2 files changed, 27 insertions(+)

-- 
2.20.1



[PATCH v5 1/2] dt-bindings: rng: bcm2835: document reset support

2021-03-03 Thread Álvaro Fernández Rojas
Some devices may need to perform a reset before using the RNG, such as the
BCM6368.

Signed-off-by: Álvaro Fernández Rojas 
---
 v5: no changes.
 v4: pass dt_binding_check.
 v3: make resets required if brcm,bcm6368-rng.
 v2: document reset support.

 .../devicetree/bindings/rng/brcm,bcm2835.yaml   | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml 
b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml
index c147900f9041..11c23e1f6988 100644
--- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml
@@ -37,6 +37,21 @@ required:
 
 additionalProperties: false
 
+if:
+  properties:
+compatible:
+  enum:
+- brcm,bcm6368-rng
+then:
+  properties:
+resets:
+  maxItems: 1
+  required:
+- resets
+else:
+  properties:
+resets: false
+
 examples:
   - |
 rng@7e104000 {
@@ -58,4 +73,6 @@ examples:
 
 clocks = <&periph_clk 18>;
 clock-names = "ipsec";
+
+resets = <&periph_rst 4>;
 };
-- 
2.20.1



[PATCH] scripts/spelling.txt: add "overlfow"

2021-03-03 Thread Drew Fustini
Add typo "overlfow" for "overflow". This typo was found and fixed in
net/sctp/tsnmap.c.

Link: 
https://lore.kernel.org/netdev/20210304055548.56829-1-d...@beagleboard.org/
Suggested-by: Kees Cook 
Signed-off-by: Drew Fustini 
---
 scripts/spelling.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/spelling.txt b/scripts/spelling.txt
index 2e3ba91a5072..f57e3e9538b0 100644
--- a/scripts/spelling.txt
+++ b/scripts/spelling.txt
@@ -1013,6 +1013,7 @@ oustanding||outstanding
 overaall||overall
 overhread||overhead
 overlaping||overlapping
+overlfow||overflow
 overide||override
 overrided||overridden
 overriden||overridden
-- 
2.27.0



[PATCH mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM

2021-03-03 Thread Rafał Miłecki
From: Rafał Miłecki 

1. Use meaningful variable names (e.g. "flash_start", "res_size" instead
   of e.g. "iobase", "end")
2. Always operate on "offset" instead of mix of start, end, size, etc.
3. Add helper checking for NVRAM to avoid duplicating code
4. Use "found" variable instead of goto
5. Use simpler checking of offsets and sizes (2 nested loops with
   trivial check instead of extra function)

This change has been tested on BCM4706. Updated code checks the same
offsets as before. Driver still finds & copies NVRAM content.

Signed-off-by: Rafał Miłecki 
---
 drivers/firmware/broadcom/bcm47xx_nvram.c | 111 --
 1 file changed, 63 insertions(+), 48 deletions(-)

diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c 
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 835ece9c00f1..7cfe857b3e98 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -34,26 +34,47 @@ static char nvram_buf[NVRAM_SPACE];
 static size_t nvram_len;
 static const u32 nvram_sizes[] = {0x6000, 0x8000, 0xF000, 0x1};
 
-static u32 find_nvram_size(void __iomem *end)
+/**
+ * bcm47xx_nvram_validate - check for a valid NVRAM at specified memory
+ */
+static bool bcm47xx_nvram_is_valid(void __iomem *nvram)
 {
-   struct nvram_header __iomem *header;
-   int i;
+   return ((struct nvram_header *)nvram)->magic == NVRAM_MAGIC;
+}
 
-   for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
-   header = (struct nvram_header *)(end - nvram_sizes[i]);
-   if (header->magic == NVRAM_MAGIC)
-   return nvram_sizes[i];
+/**
+ * bcm47xx_nvram_copy - copy NVRAM to internal buffer
+ */
+static void bcm47xx_nvram_copy(void __iomem *nvram_start, size_t res_size)
+{
+   struct nvram_header __iomem *header = nvram_start;
+   size_t copy_size;
+
+   copy_size = header->len;
+   if (copy_size > res_size) {
+   pr_err("The nvram size according to the header seems to be 
bigger than the partition on flash\n");
+   copy_size = res_size;
+   }
+   if (copy_size >= NVRAM_SPACE) {
+   pr_err("nvram on flash (%zu bytes) is bigger than the reserved 
space in memory, will just copy the first %i bytes\n",
+  copy_size, NVRAM_SPACE - 1);
+   copy_size = NVRAM_SPACE - 1;
}
 
-   return 0;
+   __ioread32_copy(nvram_buf, nvram_start, DIV_ROUND_UP(copy_size, 4));
+   nvram_buf[NVRAM_SPACE - 1] = '\0';
+   nvram_len = copy_size;
 }
 
-/* Probe for NVRAM header */
-static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
+/**
+ * bcm47xx_nvram_find_and_copy - find NVRAM on flash mapping & copy it
+ */
+static int bcm47xx_nvram_find_and_copy(void __iomem *flash_start, size_t 
res_size)
 {
-   struct nvram_header __iomem *header;
-   u32 off;
-   u32 size;
+   size_t flash_size;
+   size_t offset;
+   bool found;
+   int i;
 
if (nvram_len) {
pr_warn("nvram already initialized\n");
@@ -61,49 +82,43 @@ static int nvram_find_and_copy(void __iomem *iobase, u32 
lim)
}
 
/* TODO: when nvram is on nand flash check for bad blocks first. */
-   off = FLASH_MIN;
-   while (off <= lim) {
-   /* Windowed flash access */
-   size = find_nvram_size(iobase + off);
-   if (size) {
-   header = (struct nvram_header *)(iobase + off - size);
-   goto found;
+
+   found = false;
+
+   /* Try every possible flash size and check for NVRAM at its end */
+   for (flash_size = FLASH_MIN; flash_size <= res_size; flash_size <<= 1) {
+   for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
+   offset = flash_size - nvram_sizes[i];
+   if (bcm47xx_nvram_is_valid(flash_start + offset)) {
+   found = true;
+   break;
+   }
}
-   off <<= 1;
+
+   if (found)
+   break;
}
 
/* Try embedded NVRAM at 4 KB and 1 KB as last resorts */
-   header = (struct nvram_header *)(iobase + 4096);
-   if (header->magic == NVRAM_MAGIC) {
-   size = NVRAM_SPACE;
-   goto found;
-   }
 
-   header = (struct nvram_header *)(iobase + 1024);
-   if (header->magic == NVRAM_MAGIC) {
-   size = NVRAM_SPACE;
-   goto found;
+   if (!found) {
+   offset = 4096;
+   if (bcm47xx_nvram_is_valid(flash_start + offset))
+   found = true;
}
 
-   pr_err("no nvram found\n");
-   return -ENXIO;
-
-found:
-   __ioread32_copy(nvram_buf, header, sizeof(*header) / 4);
-   nvram_len = ((struct nvram_header *)(nvram_buf))->len;
-   if (nvram_len > size) {
-   pr_err("The nvram size according 

[PATCH] char: lp: remove redundant space

2021-03-03 Thread maqiang
These two lines of code don't meet the kernel coding style,
so remove the redundant space.

Signed-off-by: Qiang Ma 
Signed-off-by: maqiang 
---
 drivers/char/lp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/lp.c b/drivers/char/lp.c
index 862c2fd933c7..0e22e3b0a04e 100644
--- a/drivers/char/lp.c
+++ b/drivers/char/lp.c
@@ -546,7 +546,7 @@ static int lp_open(struct inode *inode, struct file *file)
}
/* Determine if the peripheral supports ECP mode */
lp_claim_parport_or_block(&lp_table[minor]);
-   if ( (lp_table[minor].dev->port->modes & PARPORT_MODE_ECP) &&
+   if ((lp_table[minor].dev->port->modes & PARPORT_MODE_ECP) &&
 !parport_negotiate(lp_table[minor].dev->port,
 IEEE1284_MODE_ECP)) {
printk(KERN_INFO "lp%d: ECP mode\n", minor);
@@ -590,7 +590,7 @@ static int lp_do_ioctl(unsigned int minor, unsigned int cmd,
return -ENODEV;
if ((LP_F(minor) & LP_EXIST) == 0)
return -ENODEV;
-   switch ( cmd ) {
+   switch (cmd) {
case LPTIME:
if (arg > UINT_MAX / HZ)
return -EINVAL;
-- 
2.20.1





Re: [PATCH 3/5] CMDLINE: powerpc: convert to generic builtin command line

2021-03-03 Thread Christophe Leroy




Le 04/03/2021 à 05:48, Daniel Walker a écrit :

This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.


Should be split in two patches. The change of strcpy to strlcpy should go in a 
first patch.



Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Daniel Walker 
---
  arch/powerpc/Kconfig| 37 +
  arch/powerpc/kernel/prom.c  |  1 +
  arch/powerpc/kernel/prom_init.c | 31 +++
  3 files changed, 20 insertions(+), 49 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 107bb4319e0e..276b06d5c961 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -167,6 +167,7 @@ config PPC
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32
select GENERIC_CLOCKEVENTS_BROADCASTif SMP
+   select GENERIC_CMDLINE
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES  if PPC_BARRIER_NOSPEC
@@ -906,42 +907,6 @@ config PPC_DENORMALISATION
  Add support for handling denormalisation of single precision
  values.  Useful for bare metal only.  If unsure say Y here.
  
-config CMDLINE

-   string "Initial kernel command string"
-   default ""
-   help
- On some platforms, there is currently no way for the boot loader to
- pass arguments to the kernel. For these platforms, you can supply
- some command-line options at build time by entering them here.  In
- most cases you will need to specify the root device here.
-
-choice
-   prompt "Kernel command line type" if CMDLINE != ""
-   default CMDLINE_FROM_BOOTLOADER
-
-config CMDLINE_FROM_BOOTLOADER
-   bool "Use bootloader kernel arguments if available"
-   help
- Uses the command-line options passed by the boot loader. If
- the boot loader doesn't provide any, the default kernel command
- string provided in CMDLINE will be used.
-
-config CMDLINE_EXTEND
-   bool "Extend bootloader kernel arguments"
-   help
- The command-line arguments provided by the boot loader will be
- appended to the default kernel command string.
-
-config CMDLINE_FORCE
-   bool "Always use the default kernel command string"
-   help
- Always use the default kernel command string, even if the boot
- loader passes other arguments to the kernel.
- This is useful if you cannot or don't want to change the
- command-line options your boot loader passes to the kernel.
-
-endchoice
-
  config EXTRA_TARGETS
string "Additional default image types"
help
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index ae3c41730367..96d0a01be1b4 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index e9d4eb6144e1..d752be688b62 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -242,15 +243,6 @@ static int __init prom_strcmp(const char *cs, const char 
*ct)
return 0;
  }
  
-static char __init *prom_strcpy(char *dest, const char *src)

-{
-   char *tmp = dest;
-
-   while ((*dest++ = *src++) != '\0')
-   /* nothing */;
-   return tmp;
-}
-
  static int __init prom_strncmp(const char *cs, const char *ct, size_t count)
  {
unsigned char c1, c2;
@@ -276,6 +268,19 @@ static size_t __init prom_strlen(const char *s)
return sc - s;
  }
  
+static size_t __init prom_strlcpy(char *dest, const char *src, size_t size)

+{
+   size_t ret = prom_strlen(src);
+
+   if (size) {
+   size_t len = (ret >= size) ? size - 1 : ret;
+   memcpy(dest, src, len);
+   dest[len] = '\0';
+   }
+   return ret;
+}
+
+
  static int __init prom_memcmp(const void *cs, const void *ct, size_t count)
  {
const unsigned char *su1, *su2;
@@ -778,9 +783,9 @@ static void __init early_cmdline_parse(void)
if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && (long)prom.chosen > 0)


You have removed CONFIG_CMDLINE_FORCE and the generic cmdline doesn't provide 
it.


l = prom_getprop(prom.chosen, "bootargs", p, 
COMMAND_LINE_SIZE-1);
  
-	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) || l <= 0 || p[0] == '\0')

-   prom_strlcat(prom_cmd_line, " " CONFIG_CMDLINE,
-sizeof(prom_cmd_line));
+   if (l <= 0 || p[0] == '\0') /* dbl check */


So it means cmdline_add_builtin_custom() is only called when bootloader does 
not provide bootargs ?


+   cmdline_add_builtin_custom(prom_cmd_line, NULL,

Re: [RFC PATCH 3/4] KVM: arm64: Install the block entry before unmapping the page mappings

2021-03-03 Thread wangyanan (Y)



On 2021/3/4 15:07, wangyanan (Y) wrote:

Hi Alex,

On 2021/3/4 1:27, Alexandru Elisei wrote:

Hi Yanan,

On 3/3/21 11:04 AM, wangyanan (Y) wrote:

Hi Alex,

On 2021/3/3 1:13, Alexandru Elisei wrote:

Hello,

On 2/8/21 11:22 AM, Yanan Wang wrote:
When KVM needs to coalesce the normal page mappings into a block 
mapping,
we currently invalidate the old table entry first followed by 
invalidation
of TLB, then unmap the page mappings, and install the block entry 
at last.


It will cost a long time to unmap the numerous page mappings, 
which means
there will be a long period when the table entry can be found 
invalid.
If other vCPUs access any guest page within the block range and 
find the
table entry invalid, they will all exit from guest with a 
translation fault
which is not necessary. And KVM will make efforts to handle these 
faults,

especially when performing CMOs by block range.

So let's quickly install the block entry at first to ensure 
uninterrupted
memory access of the other vCPUs, and then unmap the page mappings 
after
installation. This will reduce most of the time when the table 
entry is

invalid, and avoid most of the unnecessary translation faults.
I'm not convinced I've fully understood what is going on yet, but 
it seems to me

that the idea is sound. Some questions and comments below.
What I am trying to do in this patch is to adjust the order of 
rebuilding block

mappings from page mappings.
Take the rebuilding of 1G block mappings as an example.
Before this patch, the order is like:
1) invalidate the table entry of the 1st level(PUD)
2) flush TLB by VMID
3) unmap the old PMD/PTE tables
4) install the new block entry to the 1st level(PUD)

So entry in the 1st level can be found invalid by other vcpus in 1), 
2), and 3),

and it's a long time in 3) to unmap
the numerous old PMD/PTE tables, which means the total time of the 
entry being

invalid is long enough to
affect the performance.

After this patch, the order is like:
1) invalidate the table ebtry of the 1st level(PUD)
2) flush TLB by VMID
3) install the new block entry to the 1st level(PUD)
4) unmap the old PMD/PTE tables

The change ensures that period of entry in the 1st level(PUD) being 
invalid is

only in 1) and 2),
so if other vcpus access memory within 1G, there will be less chance 
to find the

entry invalid
and as a result trigger an unnecessary translation fault.
Thank you for the explanation, that was my understand of it also, and 
I believe
your idea is correct. I was more concerned that I got some of the 
details wrong,

and you have kindly corrected me below.


Signed-off-by: Yanan Wang 
---
   arch/arm64/kvm/hyp/pgtable.c | 26 --
   1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kvm/hyp/pgtable.c 
b/arch/arm64/kvm/hyp/pgtable.c

index 78a560446f80..308c36b9cd21 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -434,6 +434,7 @@ struct stage2_map_data {
   kvm_pte_t    attr;
     kvm_pte_t    *anchor;
+    kvm_pte_t    *follow;
     struct kvm_s2_mmu    *mmu;
   struct kvm_mmu_memory_cache    *memcache;
@@ -553,15 +554,14 @@ static int stage2_map_walk_table_pre(u64 
addr, u64 end,

u32 level,
   if (!kvm_block_mapping_supported(addr, end, data->phys, 
level))

   return 0;
   -    kvm_set_invalid_pte(ptep);
-
   /*
- * Invalidate the whole stage-2, as we may have numerous leaf
- * entries below us which would otherwise need invalidating
- * individually.
+ * If we need to coalesce existing table entries into a block 
here,
+ * then install the block entry first and the sub-level page 
mappings

+ * will be unmapped later.
    */
-    kvm_call_hyp(__kvm_tlb_flush_vmid, data->mmu);
   data->anchor = ptep;
+    data->follow = kvm_pte_follow(*ptep);
+    stage2_coalesce_tables_into_block(addr, level, ptep, data);
Here's how stage2_coalesce_tables_into_block() is implemented from 
the previous
patch (it might be worth merging it with this patch, I found it 
impossible to
judge if the function is correct without seeing how it is used and 
what is

replacing):

Ok, will do this if v2 is going to be post.

static void stage2_coalesce_tables_into_block(u64 addr, u32 level,
                    kvm_pte_t *ptep,
                    struct stage2_map_data *data)
{
  u64 granule = kvm_granule_size(level), phys = data->phys;
  kvm_pte_t new = kvm_init_valid_leaf_pte(phys, data->attr, 
level);


  kvm_set_invalid_pte(ptep);

  /*
   * Invalidate the whole stage-2, as we may have numerous leaf 
entries
   * below us which would otherwise need invalidating 
individually.

   */
  kvm_call_hyp(__kvm_tlb_flush_vmid, data->mmu);
  smp_store_release(ptep, new);
  data->phys += granule;
}

This works because __kvm_pgtable_visit() saves the *ptep value 
before calling the
pre callback, and it visits the next lev

[PATCH 2/3] clocksource/drivers/timer-ti-dm: Remove extra of_node_put()

2021-03-03 Thread Tony Lindgren
We have of_translate_address() already do of_node_put() as needed.
I probably looked at __of_translate_address() earlier by accident
that of_translate_address() uses.

Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and 
clocksource support")
Signed-off-by: Tony Lindgren 
---
 drivers/clocksource/timer-ti-dm-systimer.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/clocksource/timer-ti-dm-systimer.c 
b/drivers/clocksource/timer-ti-dm-systimer.c
--- a/drivers/clocksource/timer-ti-dm-systimer.c
+++ b/drivers/clocksource/timer-ti-dm-systimer.c
@@ -265,7 +265,6 @@ static void __init dmtimer_systimer_assign_alwon(void)
pa == 0x48318000)
continue;
 
-   of_node_put(np);
break;
}
}
@@ -300,7 +299,6 @@ static u32 __init 
dmtimer_systimer_find_first_available(void)
continue;
}
 
-   of_node_put(np);
break;
}
}
-- 
2.30.1


[PATCH 0/3] Fixes for timer-ti-dm systimer posted mode

2021-03-03 Thread Tony Lindgren
Hi all,

Here are few timer-ti-dm fixes. The first fix corrects the status bit
check order for posted mode. The other two are minor fixes noticed while
reviewing and testing the code.

Regards,

Tony


Tony Lindgren (3):
  clocksource/drivers/timer-ti-dm: Fix posted mode status check order
  clocksource/drivers/timer-ti-dm: Remove extra of_node_put()
  clocksource/drivers/timer-ti-dm: Add missing set_state_oneshot_stopped

 drivers/clocksource/timer-ti-dm-systimer.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

-- 
2.30.1


[PATCH 3/3] clocksource/drivers/timer-ti-dm: Add missing set_state_oneshot_stopped

2021-03-03 Thread Tony Lindgren
To avoid spurious timer interrupts when KTIME_MAX is used, we need to
configure set_state_oneshot_stopped(). Although implementing this is
optional, it still affects things like power management for the extra
timer interrupt.

For more information, please see commit 8fff52fd5093 ("clockevents:
Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state") and commit cf8c5009ee37
("clockevents/drivers/arm_arch_timer: Implement
->set_state_oneshot_stopped()").

Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and 
clocksource support")
Signed-off-by: Tony Lindgren 
---
 drivers/clocksource/timer-ti-dm-systimer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/timer-ti-dm-systimer.c 
b/drivers/clocksource/timer-ti-dm-systimer.c
--- a/drivers/clocksource/timer-ti-dm-systimer.c
+++ b/drivers/clocksource/timer-ti-dm-systimer.c
@@ -552,6 +552,7 @@ static int __init dmtimer_clockevent_init(struct 
device_node *np)
dev->set_state_shutdown = dmtimer_clockevent_shutdown;
dev->set_state_periodic = dmtimer_set_periodic;
dev->set_state_oneshot = dmtimer_clockevent_shutdown;
+   dev->set_state_oneshot_stopped = dmtimer_clockevent_shutdown;
dev->tick_resume = dmtimer_clockevent_shutdown;
dev->cpumask = cpu_possible_mask;
 
-- 
2.30.1


[PATCH 1/3] clocksource/drivers/timer-ti-dm: Fix posted mode status check order

2021-03-03 Thread Tony Lindgren
When the timer is configured in posted mode, we need to check the write-
posted status register (TWPS) before writing to the register.

We now check TWPS after the write starting with commit 52762fbd1c47
("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource
support").

For example, in the TRM for am571x the following is documented in chapter
"22.2.4.13.1.1 Write Posting Synchronization Mode":

"For each register, a status bit is provided in the timer write-posted
 status (TWPS) register. In this mode, it is mandatory that software check
 this status bit before any write access. If a write is attempted to a
 register with a previous access pending, the previous access is discarded
 without notice."

The regression happened when I updated the code to use standard read/write
accessors for the driver instead of using __omap_dm_timer_load_start().
We have__omap_dm_timer_load_start() check the TWPS status correctly using
__omap_dm_timer_write().

Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and 
clocksource support")
Signed-off-by: Tony Lindgren 
---
 drivers/clocksource/timer-ti-dm-systimer.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/timer-ti-dm-systimer.c 
b/drivers/clocksource/timer-ti-dm-systimer.c
--- a/drivers/clocksource/timer-ti-dm-systimer.c
+++ b/drivers/clocksource/timer-ti-dm-systimer.c
@@ -449,13 +449,13 @@ static int dmtimer_set_next_event(unsigned long cycles,
struct dmtimer_systimer *t = &clkevt->t;
void __iomem *pend = t->base + t->pend;
 
-   writel_relaxed(0x - cycles, t->base + t->counter);
while (readl_relaxed(pend) & WP_TCRR)
cpu_relax();
+   writel_relaxed(0x - cycles, t->base + t->counter);
 
-   writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl);
while (readl_relaxed(pend) & WP_TCLR)
cpu_relax();
+   writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl);
 
return 0;
 }
@@ -490,18 +490,18 @@ static int dmtimer_set_periodic(struct clock_event_device 
*evt)
dmtimer_clockevent_shutdown(evt);
 
/* Looks like we need to first set the load value separately */
-   writel_relaxed(clkevt->period, t->base + t->load);
while (readl_relaxed(pend) & WP_TLDR)
cpu_relax();
+   writel_relaxed(clkevt->period, t->base + t->load);
 
-   writel_relaxed(clkevt->period, t->base + t->counter);
while (readl_relaxed(pend) & WP_TCRR)
cpu_relax();
+   writel_relaxed(clkevt->period, t->base + t->counter);
 
-   writel_relaxed(OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
-  t->base + t->ctrl);
while (readl_relaxed(pend) & WP_TCLR)
cpu_relax();
+   writel_relaxed(OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
+  t->base + t->ctrl);
 
return 0;
 }
-- 
2.30.1


RE: [PATCH v2 0/2] Add DFX AXI Shutdown manager IP support for Xilinx

2021-03-03 Thread Nava kishore Manne
Ping!

> -Original Message-
> From: Nava kishore Manne 
> Sent: Thursday, February 11, 2021 10:42 AM
> To: m...@kernel.org; t...@redhat.com; robh...@kernel.org; Michal Simek
> ; linux-f...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; chinnikishore...@gmail.com
> Cc: git ; Nava kishore Manne 
> Subject: [PATCH v2 0/2] Add DFX AXI Shutdown manager IP support for Xilinx
> 
> Nava kishore Manne (2):
>   dt-bindings: fpga: Add compatible value for Xilinx DFX AXI shutdown
> manager
>   fpga: Add support for Xilinx DFX AXI Shutdown manager
> 
>  .../bindings/fpga/xilinx-pr-decoupler.txt | 24 +++-
>  drivers/fpga/Kconfig  |  9 -
>  drivers/fpga/xilinx-pr-decoupler.c| 37 ---
>  3 files changed, 63 insertions(+), 7 deletions(-)
> 
> --
> 2.18.0



Re:reply

2021-03-03 Thread Ms. Reem
Hello,

My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state
and Petroleum" also "Minister of State for International Cooperation"
in UAE. I write to you on behalf of my other "three (3) colleagues"
who has approved me to solicit for your "partnership in claiming of
{us$47=Million}" from a Financial Home in Cambodia on their behalf and
for our "Mutual Benefits".

The Fund {us$47=Million} is our share from the (over-invoiced) Oil/Gas
deal with Cambodian/Vietnam Government within 2013/2014, however, we
don't want our government to know about the fund. If this proposal
interests you, let me know, by sending me an email and I will send to
you detailed information on how this business would be successfully
transacted. Be informed that nobody knows about the secret of this
fund except us, and we know how to carry out the entire transaction.
So I am compelled to ask, that you will stand on our behalf and
receive this fund into any account that is solely controlled by you.

We will compensate you with 15% of the total amount involved as
gratification for being our partner in this transaction. Reply to:
ms.r...@yandex.com

Regards,
Ms. Reem.


Re: [PATCH] MIPS: Fix inline asm input/output type mismatch in checksum.h used with Clang

2021-03-03 Thread Tiezhu Yang

On 02/13/2021 04:36 AM, Maciej W. Rozycki wrote:

On Wed, 27 Jan 2021, Thomas Bogendoerfer wrote:


Fix the following build error when make M=samples/bpf used with Clang:

   CLANG-bpf  samples/bpf/sockex2_kern.o
In file included from samples/bpf/sockex2_kern.c:7:
In file included from ./include/uapi/linux/if_tunnel.h:7:
In file included from ./include/linux/ip.h:16:
In file included from ./include/linux/skbuff.h:28:
In file included from ./include/net/checksum.h:22:
./arch/mips/include/asm/checksum.h:161:9: error: unsupported inline asm: input 
with type 'unsigned long' matching output with type '__wsum' (aka 'unsigned 
int')
 : "0" ((__force unsigned long)daddr),
^~~~
1 error generated.

This is a known issue on MIPS [1], the changed code can be compiled
successfully by both GCC and Clang.

[1] 
https://lore.kernel.org/linux-mips/CAG_fn=W0JHf8QyUX==+rqmp8poulhrsqca9htffws31ga8k...@mail.gmail.com/

Signed-off-by: Tiezhu Yang 
---
  arch/mips/include/asm/checksum.h | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

applied to mips-next.

  This is in a performance-critical path (otherwise it wouldn't have been
in the form of inline assembly).  Has it been verified that it does not
regress code quality with GCC?

  The semantics is clear here: output is in the same register as in input,
but the register holds a different local variable in each case.  There's
nothing odd about that and the variables can obviously be of a different
type each; that's no different to register usage with code produced by the
compiler directly itself from a high-level language.

  I seem to remember discussing the issue before, but I can't remember what
the outcome has been WRT filing this as a Clang bug, and archives are not
easily available at the moment (I know a mirror exists, but any old links
are not relevant there).  Would someone be able to fill me in?

  I think ultimately with any critical piece where a Clang workaround does
regress code produced with GCC we do want to go with `#ifdef __clang__' so
that good use with GCC is not penalised on one hand and we know the places
to revert changes at should Clang ever get fixed.

  Otherwise I'll start suspecting that Clang supporters try some kind of an
unfair game to gain advantage over GCC, by modifying projects such that
the competing compiler produces worse code than it could if Clang was not
actively supported.

   Maciej


Hi Maciej,

Thank you very much for your detailed explanation, sorry for the
late response and the poorly considered implementation about the
performance influence with GCC.

I think you are right, so are you OK with the following changes?
If yes, I will send a new patch later.

With the new patch, we can build successfully by both GCC and Clang,
at the same time, we can avoid the potential performance influence
with GCC.

diff --git a/arch/mips/include/asm/checksum.h 
b/arch/mips/include/asm/checksum.h

index 1e6c135..0079a8e 100644
--- a/arch/mips/include/asm/checksum.h
+++ b/arch/mips/include/asm/checksum.h
@@ -130,7 +130,9 @@ static inline __wsum csum_tcpudp_nofold(__be32 
saddr, __be32 daddr,

__u32 len, __u8 proto,
__wsum sum)
 {
+#ifdef CONFIG_CC_IS_CLANG
unsigned long tmp = (__force unsigned long)sum;
+#endif

__asm__(
"   .setpush# csum_tcpudp_nofold\n"
@@ -159,7 +161,11 @@ static inline __wsum csum_tcpudp_nofold(__be32 
saddr, __be32 daddr,

"   addu%0, $1  \n"
 #endif
"   .setpop"
+#ifdef CONFIG_CC_IS_CLANG
: "=r" (tmp)
+#else
+   : "=r" (sum)
+#endif
: "0" ((__force unsigned long)daddr),
  "r" ((__force unsigned long)saddr),
 #ifdef __MIPSEL__
@@ -169,7 +175,11 @@ static inline __wsum csum_tcpudp_nofold(__be32 
saddr, __be32 daddr,

 #endif
  "r" ((__force unsigned long)sum));

+#ifdef CONFIG_CC_IS_CLANG
return (__force __wsum)tmp;
+#else
+   return sum;
+#endif
 }
 #define csum_tcpudp_nofold csum_tcpudp_nofold

Thanks,
Tiezhu



[PATCH v2] gpio: regmap: set gpio_chip of_node

2021-03-03 Thread Álvaro Fernández Rojas
This is needed for properly registering gpio regmap as a child of a regmap
pin controller.

Signed-off-by: Álvaro Fernández Rojas 
Reviewed-by: Michael Walle 
---
 v2: split this patch from the bcm63xx-pinctrl series

 drivers/gpio/gpio-regmap.c  | 1 +
 include/linux/gpio/regmap.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
index fed1e269c42a..8898ab3e1d59 100644
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -249,6 +249,7 @@ struct gpio_regmap *gpio_regmap_register(const struct 
gpio_regmap_config *config
 
chip = &gpio->gpio_chip;
chip->parent = config->parent;
+   chip->of_node = config->of_node ?: dev_of_node(config->parent);
chip->base = -1;
chip->ngpio = config->ngpio;
chip->names = config->names;
diff --git a/include/linux/gpio/regmap.h b/include/linux/gpio/regmap.h
index ad76f3d0a6ba..566d76d0dbae 100644
--- a/include/linux/gpio/regmap.h
+++ b/include/linux/gpio/regmap.h
@@ -4,6 +4,7 @@
 #define _LINUX_GPIO_REGMAP_H
 
 struct device;
+struct device_node;
 struct gpio_regmap;
 struct irq_domain;
 struct regmap;
@@ -15,6 +16,7 @@ struct regmap;
  * struct gpio_regmap_config - Description of a generic regmap gpio_chip.
  * @parent:The parent device
  * @regmap:The regmap used to access the registers
+ * @of_node:   (Optional) The device node
  * given, the name of the device is used
  * @label: (Optional) Descriptive name for GPIO controller.
  * If not given, the name of the device is used.
@@ -57,6 +59,7 @@ struct regmap;
 struct gpio_regmap_config {
struct device *parent;
struct regmap *regmap;
+   struct device_node *of_node;
 
const char *label;
int ngpio;
-- 
2.20.1



RE: [PATCH v2 0/2] Add DFX AXI Shutdown manager IP support for Xilinx

2021-03-03 Thread Nava kishore Manne
Ping!

> -Original Message-
> From: Nava kishore Manne 
> Sent: Thursday, February 11, 2021 10:42 AM
> To: m...@kernel.org; t...@redhat.com; robh...@kernel.org; Michal Simek
> ; linux-f...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; chinnikishore...@gmail.com
> Cc: git ; Nava kishore Manne 
> Subject: [PATCH v2 0/2] Add DFX AXI Shutdown manager IP support for Xilinx
> 
> Nava kishore Manne (2):
>   dt-bindings: fpga: Add compatible value for Xilinx DFX AXI shutdown
> manager
>   fpga: Add support for Xilinx DFX AXI Shutdown manager
> 
>  .../bindings/fpga/xilinx-pr-decoupler.txt | 24 +++-
>  drivers/fpga/Kconfig  |  9 -
>  drivers/fpga/xilinx-pr-decoupler.c| 37 ---
>  3 files changed, 63 insertions(+), 7 deletions(-)
> 
> --
> 2.18.0



Re: [PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu

2021-03-03 Thread Chunyan Zhang
Hi Robin,

On Tue, 16 Feb 2021 at 23:10, Robin Murphy  wrote:
>
> >>>
> >>> On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
>  From: Chunyan Zhang 
> 
>  This iommu module can be used by Unisoc's multimedia devices, such as
>  display, Image codec(jpeg) and a few signal processors, including
>  VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), 
>  etc.
> 
>  Signed-off-by: Chunyan Zhang 
>  ---
>    .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
>    1 file changed, 72 insertions(+)
>    create mode 100644 
>  Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> 
>  diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml 
>  b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
>  new file mode 100644
>  index ..4fc99e81fa66
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
>  @@ -0,0 +1,72 @@
>  +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>  +# Copyright 2020 Unisoc Inc.
>  +%YAML 1.2
>  +---
>  +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
>  +$schema: http://devicetree.org/meta-schemas/core.yaml#
>  +
>  +title: Unisoc IOMMU and Multi-media MMU
>  +
>  +maintainers:
>  +  - Chunyan Zhang 
>  +
>  +properties:
>  +  compatible:
>  +enum:
>  +  - sprd,iommu-v1
>  +
>  +  "#iommu-cells":
>  +const: 0
>  +description:
>  +  Unisoc IOMMUs are all single-master IOMMU devices, therefore no
>  +  additional information needs to associate with its master device.
>  +  Please refer to the generic bindings document for more details,
>  +  Documentation/devicetree/bindings/iommu/iommu.txt
>  +
>  +  reg:
>  +maxItems: 1
>  +description:
>  +  Not required if 'sprd,iommu-regs' is defined.
>  +
>  +  clocks:
>  +description:
>  +  Reference to a gate clock phandle, since access to some of IOMMUs 
>  are
>  +  controlled by gate clock, but this is not required.
>  +
>  +  sprd,iommu-regs:
>  +$ref: /schemas/types.yaml#/definitions/phandle-array
>  +description:
>  +  Reference to a syscon phandle plus 1 cell, the syscon defines the
>  +  register range used by the iommu and the media device, the cell
>  +  defines the offset for iommu registers. Since iommu module shares
>  +  the same register range with the media device which uses it.
>  +
>  +required:
>  +  - compatible
>  +  - "#iommu-cells"
>
> OK, so apparently the hardware is not quite as trivial as my initial
> impression, and you should have interrupts as well.

I've checked with my colleagues for this issue. And like I explained
before, one sprd IOMMU serves one master device only, so interrupts
are handled by master devices rather than IOMMUs.

Chunyan


[PATCH v3 2/3] dt-bindings: fpga: Add binding doc for versal fpga manager

2021-03-03 Thread Nava kishore Manne
From: Appana Durga Kedareswara rao 

This patch adds binding doc for versal fpga manager driver.

Signed-off-by: Nava kishore Manne 
Signed-off-by: Appana Durga Kedareswara rao 
---
Changes for v2:
-Fixed file format and syntax issues.
Changes for v3:
-Removed unwated extra spaces.

 .../bindings/fpga/xlnx,versal-fpga.yaml   | 33 +++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml

diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml 
b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
new file mode 100644
index ..fec6144766fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/xlnx,versal-fpga.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal FPGA driver.
+
+maintainers:
+  - Nava kishore Manne 
+
+description: |
+  Device Tree Versal FPGA bindings for the Versal SoC, controlled
+  using firmware interface.
+
+properties:
+  compatible:
+items:
+  - enum:
+  - xlnx,versal-fpga
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+versal_fpga: fpga {
+ compatible = "xlnx,versal-fpga";
+};
+
+...
-- 
2.18.0



[PATCH v3 3/3] fpga: versal-fpga: Add versal fpga manager driver

2021-03-03 Thread Nava kishore Manne
Add support for Xilinx Versal FPGA manager.

PDI source type can be DDR, OCM, QSPI flash etc..
But driver allocates memory always from DDR, Since driver supports only
DDR source type.

Signed-off-by: Appana Durga Kedareswara rao 
Signed-off-by: Nava kishore Manne 
---
Changes for v2:
-Updated the Fpga Mgr registrations call's
 to 5.11
-Fixed some minor coding issues as suggested by
 Moritz.
Changes for v3:
-Rewritten the Versal fpga Kconfig contents.

 drivers/fpga/Kconfig   |   9 +++
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/versal-fpga.c | 117 +
 3 files changed, 127 insertions(+)
 create mode 100644 drivers/fpga/versal-fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index bf85b9a65ec2..c1603c7e1518 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -223,4 +223,13 @@ config FPGA_MGR_ZYNQMP_FPGA
  to configure the programmable logic(PL) through PS
  on ZynqMP SoC.
 
+config FPGA_MGR_VERSAL_FPGA
+   tristate "Xilinx Versal FPGA"
+   depends on ARCH_ZYNQMP || COMPILE_TEST
+   help
+ Select this option to enable FPGA manager driver support for
+ Xilinx Versal SoC. This driver uses the firmware interface to
+ configure the programmable logic(PL).
+
+ To compile this as a module, choose M here.
 endif # FPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index d8e21dfc6778..40c9adb6a644 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
 obj-$(CONFIG_FPGA_MGR_XILINX_SPI)  += xilinx-spi.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQMP_FPGA) += zynqmp-fpga.o
+obj-$(CONFIG_FPGA_MGR_VERSAL_FPGA)  += versal-fpga.o
 obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
 obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT)+= altera-pr-ip-core-plat.o
 
diff --git a/drivers/fpga/versal-fpga.c b/drivers/fpga/versal-fpga.c
new file mode 100644
index ..5744e44f981d
--- /dev/null
+++ b/drivers/fpga/versal-fpga.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019-2021 Xilinx, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct versal_fpga_priv - Private data structure
+ * @dev:   Device data structure
+ */
+struct versal_fpga_priv {
+   struct device *dev;
+};
+
+static int versal_fpga_ops_write_init(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
+ const char *buf, size_t size)
+{
+   return 0;
+}
+
+static int versal_fpga_ops_write(struct fpga_manager *mgr,
+const char *buf, size_t size)
+{
+   struct versal_fpga_priv *priv;
+   dma_addr_t dma_addr = 0;
+   char *kbuf;
+   int ret;
+
+   priv = mgr->priv;
+
+   kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr, GFP_KERNEL);
+   if (!kbuf)
+   return -ENOMEM;
+
+   memcpy(kbuf, buf, size);
+
+   wmb(); /* ensure all writes are done before initiate FW call */
+
+   ret = zynqmp_pm_load_pdi(PDI_SRC_DDR, dma_addr);
+
+   dma_free_coherent(priv->dev, size, kbuf, dma_addr);
+
+   return ret;
+}
+
+static int versal_fpga_ops_write_complete(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+   return 0;
+}
+
+static enum fpga_mgr_states versal_fpga_ops_state(struct fpga_manager *mgr)
+{
+   return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static const struct fpga_manager_ops versal_fpga_ops = {
+   .state = versal_fpga_ops_state,
+   .write_init = versal_fpga_ops_write_init,
+   .write = versal_fpga_ops_write,
+   .write_complete = versal_fpga_ops_write_complete,
+};
+
+static int versal_fpga_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct versal_fpga_priv *priv;
+   struct fpga_manager *mgr;
+   int ret;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   priv->dev = dev;
+   ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+   if (ret < 0) {
+   dev_err(dev, "no usable DMA configuration\n");
+   return ret;
+   }
+
+   mgr = devm_fpga_mgr_create(dev, "Xilinx Versal FPGA Manager",
+  &versal_fpga_ops, priv);
+   if (!mgr)
+   return -ENOMEM;
+
+   return devm_fpga_mgr_register(dev, mgr);
+}
+
+static const struct of_device_id versal_fpga_of_match[] = {
+   { .compatible = "xlnx,versal-fpga", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, versal_fpga_of_match);
+
+static struct platform_driver versal_fpga_driver = {
+   .probe = versal_f

Re: [PATCH 2/5] CMDLINE: drivers: of: ifdef out cmdline section

2021-03-03 Thread Christophe Leroy




Le 04/03/2021 à 05:47, Daniel Walker a écrit :

It looks like there's some seepage of cmdline stuff into
the generic device tree code. This conflicts with the
generic cmdline implementation so I remove it in the case
when that's enabled.

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko 
Signed-off-by: Daniel Walker 
---
  drivers/of/fdt.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index feb0f2d67fc5..cfe4f8d3c9f5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -25,6 +25,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include   /* for COMMAND_LINE_SIZE */

  #include 
@@ -1048,8 +1049,18 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
  
  	early_init_dt_check_for_initrd(node);
  
+#ifdef CONFIG_GENERIC_CMDLINE

/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
+
+   /*
+* The builtin command line will be added here, or it can override
+* with the DT bootargs.
+*/
+   cmdline_add_builtin(data,
+   ((p != NULL && l > 0) ? p : NULL), /* This is 
sanity checking */


Can we do more simple ? If p is NULL, p is already NULL, so (l > 0 ? p : NULL) 
should be enough.


+   COMMAND_LINE_SIZE);
+#else


What does p contains now that "p = of_get_flat_dt_prop(node, "bootargs", &l);" is only called when 
CONFIG_GENERIC_CMDLINE is defined ?



if (p != NULL && l > 0)
strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
  
@@ -1070,6 +1081,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,

strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
  #endif
  #endif /* CONFIG_CMDLINE */
+#endif /* CONFIG_GENERIC_CMDLINE */
  
  	pr_debug("Command line is: %s\n", (char *)data);
  



[PATCH v3 1/3] drivers: firmware: Add PDI load API support

2021-03-03 Thread Nava kishore Manne
This patch adds load PDI API support to enable full/partial PDI loading
from linux. Programmable Device Image (PDI) is combination of headers,
images and bitstream files to be loaded.

Signed-off-by: Nava kishore Manne 
---
Changes for v2:
-Updated API Doc and commit msg.
 No functional changes.
Changes for v3:
-Added PDI_SRC_DDR macro in the firmware.h file.

 drivers/firmware/xilinx/zynqmp.c | 17 +
 include/linux/firmware/xlnx-zynqmp.h | 10 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 7eb9958662dd..9ee02655db89 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -897,6 +897,23 @@ int zynqmp_pm_set_requirement(const u32 node, const u32 
capabilities,
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_set_requirement);
 
+/**
+ * zynqmp_pm_load_pdi - Load and process PDI
+ * @src:   Source device where PDI is located
+ * @address:   PDI src address
+ *
+ * This function provides support to load PDI from linux
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_load_pdi(const u32 src, const u64 address)
+{
+   return zynqmp_pm_invoke_fn(PM_LOAD_PDI, src,
+  lower_32_bits(address),
+  upper_32_bits(address), 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_load_pdi);
+
 /**
  * zynqmp_pm_aes - Access AES hardware to encrypt/decrypt the data using
  * AES-GCM core.
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 2a0da841c942..3eba9d5c7640 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -52,6 +52,10 @@
 #defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
 #defineZYNQMP_PM_CAPABILITY_UNUSABLE   0x8U
 
+/* Loader commands */
+#define PM_LOAD_PDI0x701
+#define PDI_SRC_DDR0xF
+
 /*
  * Firmware FPGA Manager flags
  * XILINX_ZYNQMP_PM_FPGA_FULL: FPGA full reconfiguration
@@ -354,6 +358,7 @@ int zynqmp_pm_write_pggs(u32 index, u32 value);
 int zynqmp_pm_read_pggs(u32 index, u32 *value);
 int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
 int zynqmp_pm_set_boot_health_status(u32 value);
+int zynqmp_pm_load_pdi(const u32 src, const u64 address);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -538,6 +543,11 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_load_pdi(const u32 src, const u64 address)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.18.0



[PATCH v1] usb: typec: tcpci: Check ROLE_CONTROL while interpreting CC_STATUS

2021-03-03 Thread Badhri Jagan Sridharan
While interpreting CC_STATUS, ROLE_CONTROL has to be read to make
sure that CC1/CC2 is not forced presenting Rp/Rd.

>From the TCPCI spec:

4.4.5.2 ROLE_CONTROL (Normative):
The TCPM shall write B6 (DRP) = 0b and B3..0 (CC1/CC2) if it wishes
to control the Rp/Rd directly instead of having the TCPC perform
DRP toggling autonomously. When controlling Rp/Rd directly, the
TCPM writes to B3..0 (CC1/CC2) each time it wishes to change the
CC1/CC2 values. This control is used for TCPM-TCPC implementing
Source or Sink only as well as when a connection has been detected
via DRP toggling but the TCPM wishes to attempt Try.Src or Try.Snk.

Table 4-22. CC_STATUS Register Definition:
If (ROLE_CONTROL.CC1 = Rd) or ConnectResult=1)
00b: SNK.Open (Below maximum vRa)
01b: SNK.Default (Above minimum vRd-Connect)
10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp-1.5A
11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp-3.0A

If (ROLE_CONTROL.CC2=Rd) or (ConnectResult=1)
00b: SNK.Open (Below maximum vRa)
01b: SNK.Default (Above minimum vRd-Connect)
10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp 1.5A
11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp 3.0A

Fixes: 74e656d6b0551 ("staging: typec: Type-C Port Controller
Interface driver (tcpci)")
Signed-off-by: Badhri Jagan Sridharan 
---
 drivers/usb/typec/tcpm/tcpci.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index a27deb0b5f03..027afd7dfdce 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -24,6 +24,15 @@
 #defineAUTO_DISCHARGE_PD_HEADROOM_MV   850
 #defineAUTO_DISCHARGE_PPS_HEADROOM_MV  1250
 
+#define tcpc_presenting_cc1_rd(reg) \
+   (!(TCPC_ROLE_CTRL_DRP & (reg)) && \
+(((reg) & (TCPC_ROLE_CTRL_CC1_MASK << TCPC_ROLE_CTRL_CC1_SHIFT)) == \
+ (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT)))
+#define tcpc_presenting_cc2_rd(reg) \
+   (!(TCPC_ROLE_CTRL_DRP & (reg)) && \
+(((reg) & (TCPC_ROLE_CTRL_CC2_MASK << TCPC_ROLE_CTRL_CC2_SHIFT)) == \
+ (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT)))
+
 struct tcpci {
struct device *dev;
 
@@ -178,19 +187,25 @@ static int tcpci_get_cc(struct tcpc_dev *tcpc,
enum typec_cc_status *cc1, enum typec_cc_status *cc2)
 {
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-   unsigned int reg;
+   unsigned int reg, role_control;
int ret;
 
+   ret = regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, &role_control);
+   if (ret < 0)
+   return ret;
+
ret = regmap_read(tcpci->regmap, TCPC_CC_STATUS, ®);
if (ret < 0)
return ret;
 
*cc1 = tcpci_to_typec_cc((reg >> TCPC_CC_STATUS_CC1_SHIFT) &
 TCPC_CC_STATUS_CC1_MASK,
-reg & TCPC_CC_STATUS_TERM);
+reg & TCPC_CC_STATUS_TERM ||
+tcpc_presenting_cc1_rd(role_control));
*cc2 = tcpci_to_typec_cc((reg >> TCPC_CC_STATUS_CC2_SHIFT) &
 TCPC_CC_STATUS_CC2_MASK,
-reg & TCPC_CC_STATUS_TERM);
+reg & TCPC_CC_STATUS_TERM ||
+tcpc_presenting_cc2_rd(role_control));
 
return 0;
 }
-- 
2.30.1.766.gb4fecdf3b7-goog



[PATCH v3 0/3] Add Bitstream configuration support for Versal

2021-03-03 Thread Nava kishore Manne
This series adds FPGA Manager support for the Xilinx
Versal chip.

Appana Durga Kedareswara rao (1):
  dt-bindings: fpga: Add binding doc for versal fpga manager

Nava kishore Manne (2):
  drivers: firmware: Add PDI load API support
  fpga: versal-fpga: Add versal fpga manager driver

 .../bindings/fpga/xlnx,versal-fpga.yaml   |  33 +
 drivers/firmware/xilinx/zynqmp.c  |  17 +++
 drivers/fpga/Kconfig  |   9 ++
 drivers/fpga/Makefile |   1 +
 drivers/fpga/versal-fpga.c| 117 ++
 include/linux/firmware/xlnx-zynqmp.h  |  10 ++
 6 files changed, 187 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
 create mode 100644 drivers/fpga/versal-fpga.c

-- 
2.18.0



Re: [RFC PATCH 3/4] KVM: arm64: Install the block entry before unmapping the page mappings

2021-03-03 Thread wangyanan (Y)

Hi Alex,

On 2021/3/4 1:27, Alexandru Elisei wrote:

Hi Yanan,

On 3/3/21 11:04 AM, wangyanan (Y) wrote:

Hi Alex,

On 2021/3/3 1:13, Alexandru Elisei wrote:

Hello,

On 2/8/21 11:22 AM, Yanan Wang wrote:

When KVM needs to coalesce the normal page mappings into a block mapping,
we currently invalidate the old table entry first followed by invalidation
of TLB, then unmap the page mappings, and install the block entry at last.

It will cost a long time to unmap the numerous page mappings, which means
there will be a long period when the table entry can be found invalid.
If other vCPUs access any guest page within the block range and find the
table entry invalid, they will all exit from guest with a translation fault
which is not necessary. And KVM will make efforts to handle these faults,
especially when performing CMOs by block range.

So let's quickly install the block entry at first to ensure uninterrupted
memory access of the other vCPUs, and then unmap the page mappings after
installation. This will reduce most of the time when the table entry is
invalid, and avoid most of the unnecessary translation faults.

I'm not convinced I've fully understood what is going on yet, but it seems to me
that the idea is sound. Some questions and comments below.

What I am trying to do in this patch is to adjust the order of rebuilding block
mappings from page mappings.
Take the rebuilding of 1G block mappings as an example.
Before this patch, the order is like:
1) invalidate the table entry of the 1st level(PUD)
2) flush TLB by VMID
3) unmap the old PMD/PTE tables
4) install the new block entry to the 1st level(PUD)

So entry in the 1st level can be found invalid by other vcpus in 1), 2), and 3),
and it's a long time in 3) to unmap
the numerous old PMD/PTE tables, which means the total time of the entry being
invalid is long enough to
affect the performance.

After this patch, the order is like:
1) invalidate the table ebtry of the 1st level(PUD)
2) flush TLB by VMID
3) install the new block entry to the 1st level(PUD)
4) unmap the old PMD/PTE tables

The change ensures that period of entry in the 1st level(PUD) being invalid is
only in 1) and 2),
so if other vcpus access memory within 1G, there will be less chance to find the
entry invalid
and as a result trigger an unnecessary translation fault.

Thank you for the explanation, that was my understand of it also, and I believe
your idea is correct. I was more concerned that I got some of the details wrong,
and you have kindly corrected me below.


Signed-off-by: Yanan Wang 
---
   arch/arm64/kvm/hyp/pgtable.c | 26 --
   1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 78a560446f80..308c36b9cd21 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -434,6 +434,7 @@ struct stage2_map_data {
   kvm_pte_t    attr;
     kvm_pte_t    *anchor;
+    kvm_pte_t    *follow;
     struct kvm_s2_mmu    *mmu;
   struct kvm_mmu_memory_cache    *memcache;
@@ -553,15 +554,14 @@ static int stage2_map_walk_table_pre(u64 addr, u64 end,
u32 level,
   if (!kvm_block_mapping_supported(addr, end, data->phys, level))
   return 0;
   -    kvm_set_invalid_pte(ptep);
-
   /*
- * Invalidate the whole stage-2, as we may have numerous leaf
- * entries below us which would otherwise need invalidating
- * individually.
+ * If we need to coalesce existing table entries into a block here,
+ * then install the block entry first and the sub-level page mappings
+ * will be unmapped later.
    */
-    kvm_call_hyp(__kvm_tlb_flush_vmid, data->mmu);
   data->anchor = ptep;
+    data->follow = kvm_pte_follow(*ptep);
+    stage2_coalesce_tables_into_block(addr, level, ptep, data);

Here's how stage2_coalesce_tables_into_block() is implemented from the previous
patch (it might be worth merging it with this patch, I found it impossible to
judge if the function is correct without seeing how it is used and what is
replacing):

Ok, will do this if v2 is going to be post.

static void stage2_coalesce_tables_into_block(u64 addr, u32 level,
                    kvm_pte_t *ptep,
                    struct stage2_map_data *data)
{
  u64 granule = kvm_granule_size(level), phys = data->phys;
  kvm_pte_t new = kvm_init_valid_leaf_pte(phys, data->attr, level);

  kvm_set_invalid_pte(ptep);

  /*
   * Invalidate the whole stage-2, as we may have numerous leaf entries
   * below us which would otherwise need invalidating individually.
   */
  kvm_call_hyp(__kvm_tlb_flush_vmid, data->mmu);
  smp_store_release(ptep, new);
  data->phys += granule;
}

This works because __kvm_pgtable_visit() saves the *ptep value before calling 
the
pre callback, and it visits the next level table based on the initial pte value,
not the new value written by stage2_coalesce

[PATCH] gpio: regmap: disable IRQ domain without GPIOLIB_IRQCHIP

2021-03-03 Thread Álvaro Fernández Rojas
The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in
a compilation error when trying to build gpio-regmap without having selected
CONFIG_GPIOLIB_IRQCHIP.

Fixes: ebe363197e52 ("gpio: add a reusable generic gpio_chip using regmap")
Signed-off-by: Álvaro Fernández Rojas 
---
 drivers/gpio/gpio-regmap.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
index 5412cb3b0b2a..fed1e269c42a 100644
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -279,16 +279,20 @@ struct gpio_regmap *gpio_regmap_register(const struct 
gpio_regmap_config *config
if (ret < 0)
goto err_free_gpio;
 
+#ifdef CONFIG_GPIOLIB_IRQCHIP
if (config->irq_domain) {
ret = gpiochip_irqchip_add_domain(chip, config->irq_domain);
if (ret)
goto err_remove_gpiochip;
}
+#endif /* CONFIG_GPIOLIB_IRQCHIP */
 
return gpio;
 
+#ifdef CONFIG_GPIOLIB_IRQCHIP
 err_remove_gpiochip:
gpiochip_remove(chip);
+#endif /* CONFIG_GPIOLIB_IRQCHIP */
 err_free_gpio:
kfree(gpio);
return ERR_PTR(ret);
-- 
2.20.1



Re: [V2][PATCH] vt: keyboard, fix uninitialized variables warning

2021-03-03 Thread Greg KH
On Thu, Mar 04, 2021 at 11:10:48AM +0800, Li Wang wrote:
> drivers/tty/vt/keyboard.c: In function 'vt_do_kdgkb_ioctl':
> drivers/tty/vt/keyboard.c: warning: 'ret' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   return ret;
>  ^~~
> drivers/tty/vt/keyboard.c: warning: 'kbs' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   kfree(kbs);
>   ^~

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot


Re: [V2][PATCH] vt: keyboard, fix uninitialized variables warning

2021-03-03 Thread Jiri Slaby

On 04. 03. 21, 4:10, Li Wang wrote:

drivers/tty/vt/keyboard.c: In function 'vt_do_kdgkb_ioctl':
drivers/tty/vt/keyboard.c: warning: 'ret' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
   return ret;
  ^~~
drivers/tty/vt/keyboard.c: warning: 'kbs' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
   kfree(kbs);
   ^~

Signed-off-by: Li Wang 
---
  drivers/tty/vt/keyboard.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index 7763862..62f1ecb 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -2090,6 +2090,8 @@ int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __user 
*user_kdgkb, int perm)
  
  		ret = 0;

break;
+   default:
+   return -EINVAL;


I am not biased whether to add it or not, but I would return 
-ENOIOCTLCMD if we do.



}
  
  	kfree(kbs);





--
js
suse labs


RE: [RFC PATCH 2/5] char: rpmb: provide a user space interface

2021-03-03 Thread Winkler, Tomas

> 
> The user space API is achieved via a number of synchronous IOCTLs.
> 
>   * RPMB_IOC_VER_CMD - simple versioning API
>   * RPMB_IOC_CAP_CMD - query of underlying capabilities
>   * RPMB_IOC_PKEY_CMD - one time programming of access key
>   * RPMB_IOC_COUNTER_CMD - query the write counter
>   * RPMB_IOC_WBLOCKS_CMD - write blocks to device
>   * RPMB_IOC_RBLOCKS_CMD - read blocks from device
> 
> The keys used for programming and writing blocks to the device are
> key_serial_t handles as provided by the keyctl() interface.
> 
> [AJB: here there are two key differences between this and the original
> proposal. The first is the dropping of the sequence of preformated frames in
> favour of explicit actions. The second is the introduction of key_serial_t and
> the keyring API for referencing the key to use]

Putting it gently I'm not sure this is good idea, from the security point of 
view.
The key has to be possession of the one that signs the frames as they are, it 
doesn't mean it is linux kernel keyring, it can be other party on different 
system.
With this approach you will make the other usecases not applicable. It is less 
then trivial to move key securely from one system to another.
We all wished it can be abstracted more but the frames has to come already 
signed, and the key material is inside the frame. 
Thanks
Tomas


> 
> Signed-off-by: Alex Bennée 
> Cc: Ulf Hansson 
> Cc: Linus  Walleij 
> Cc: Arnd Bergmann 
> Cc: Ilias Apalodimas 
> Cc: Tomas Winkler 
> Cc: Alexander Usyskin 
> Cc: Avri Altman 
> ---
>  .../userspace-api/ioctl/ioctl-number.rst  |   1 +
>  MAINTAINERS   |   1 +
>  drivers/char/rpmb/Kconfig |   7 +
>  drivers/char/rpmb/Makefile|   1 +
>  drivers/char/rpmb/cdev.c  | 246 ++
>  drivers/char/rpmb/core.c  |  10 +-
>  drivers/char/rpmb/rpmb-cdev.h |  17 ++
>  include/linux/rpmb.h  |  10 +
>  include/uapi/linux/rpmb.h |  68 +
>  9 files changed, 357 insertions(+), 4 deletions(-)  create mode 100644
> drivers/char/rpmb/cdev.c  create mode 100644 drivers/char/rpmb/rpmb-
> cdev.h  create mode 100644 include/uapi/linux/rpmb.h
> 
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index a4c75a28c839..0ff2d4d81bb0 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -344,6 +344,7 @@ Code  Seq#Include File
> Comments
>  0xB5  00-0F  uapi/linux/rpmsg.h  
>  remotep...@vger.kernel.org>
>  0xB6  alllinux/fpga-dfl.h
>  0xB7  alluapi/linux/remoteproc_cdev.h
>  remotep...@vger.kernel.org>
> +0xB8  80-8F  uapi/linux/rpmb.h   
>  m...@vger.kernel.org>
>  0xC0  00-0F  linux/usb/iowarrior.h
>  0xCA  00-0F  uapi/misc/cxl.h
>  0xCA  10-2F  uapi/misc/ocxl.h
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 076f3983526c..c60b41b6e6bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15374,6 +15374,7 @@ M:?
>  L:   linux-kernel@vger.kernel.org
>  S:   Supported
>  F:   drivers/char/rpmb/*
> +F:   include/uapi/linux/rpmb.h
>  F:   include/linux/rpmb.h
> 
>  RTL2830 MEDIA DRIVER
> diff --git a/drivers/char/rpmb/Kconfig b/drivers/char/rpmb/Kconfig index
> 431c2823cf70..9068664a399a 100644
> --- a/drivers/char/rpmb/Kconfig
> +++ b/drivers/char/rpmb/Kconfig
> @@ -9,3 +9,10 @@ config RPMB
> access RPMB partition.
> 
> If unsure, select N.
> +
> +config RPMB_INTF_DEV
> + bool "RPMB character device interface /dev/rpmbN"
> + depends on RPMB && KEYS
> + help
> +   Say yes here if you want to access RPMB from user space
> +   via character device interface /dev/rpmb%d
> diff --git a/drivers/char/rpmb/Makefile b/drivers/char/rpmb/Makefile index
> 24d4752a9a53..f54b3f30514b 100644
> --- a/drivers/char/rpmb/Makefile
> +++ b/drivers/char/rpmb/Makefile
> @@ -3,5 +3,6 @@
> 
>  obj-$(CONFIG_RPMB) += rpmb.o
>  rpmb-objs += core.o
> +rpmb-$(CONFIG_RPMB_INTF_DEV) += cdev.o
> 
>  ccflags-y += -D__CHECK_ENDIAN__
> diff --git a/drivers/char/rpmb/cdev.c b/drivers/char/rpmb/cdev.c new file
> mode 100644 index ..55f66720fd03
> --- /dev/null
> +++ b/drivers/char/rpmb/cdev.c
> @@ -0,0 +1,246 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(c) 2015 - 2019 Intel Corporation.
> + */
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "rpmb-cdev.h"
> +
> +static dev_t rpmb_devt;
> +#define RPMB_MAX_DEVS  MINORMASK
> +
> +#define RPMB_DEV_OPEN0  /** single open bit (position) */
> +
> +/**
> + * rpmb_open - the open function
> + *
> + * @inode: pointer to inode structure
> +

Re: [PATCH 1/5] CMDLINE: add generic builtin command line

2021-03-03 Thread Christophe Leroy




Le 04/03/2021 à 05:47, Daniel Walker a écrit :

This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. On x86 and mips they have pretty much the same code and the
code prepends the builtin command line onto the boot loader provided
one. On powerpc there is only a builtin override and nothing else.


This is not exact. powerpc has:
CONFIG_FROM_BOOTLOADER
CONFIG_EXTEND
CONFIG_FORCE



The code in this commit unifies the code into a generic
header file under the CONFIG_GENERIC_CMDLINE option. When this
option is enabled the architecture can call the cmdline_add_builtin()
to add the builtin command line.

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Daniel Walker 
---
  include/linux/cmdline.h | 75 +
  init/Kconfig| 68 +
  2 files changed, 143 insertions(+)
  create mode 100644 include/linux/cmdline.h

diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
new file mode 100644
index ..f44011d1a9ee
--- /dev/null
+++ b/include/linux/cmdline.h
@@ -0,0 +1,75 @@


Missing the SPDX Licence Identifier


+#ifndef _LINUX_CMDLINE_H
+#define _LINUX_CMDLINE_H
+
+/*
+ *
+ * Copyright (C) 2006,2021. Cisco Systems, Inc.
+ *
+ * Generic Append/Prepend cmdline support.
+ */
+
+#if defined(CONFIG_GENERIC_CMDLINE) && defined(CONFIG_CMDLINE_BOOL)


I think it would be better if we can avoid the CONFIG_CMDLINE_BOOL.
By making the CMDLINEs default to "" at all time, I think we can about that 
BOOL.


+
+#ifndef CONFIG_CMDLINE_OVERRIDE
+/*
+ * This function will append or prepend a builtin command line to the command


As far as I understand, it doesn't "append _or_ prepend" but it does "append _and_ 
prepend"


+ * line provided by the bootloader. Kconfig options can be used to alter
+ * the behavior of this builtin command line.
+ * @dest: The destination of the final appended/prepended string
+ * @src: The starting string or NULL if there isn't one.
+ * @tmp: temporary space used for prepending
+ * @length: the maximum length of the strings above.


Missing some parameters here, but I think we should avoid those 'strlcpy' and 'strlcat', see later 
comment.



+ */
+static inline void
+__cmdline_add_builtin(char *dest, const char *src, char *tmp, unsigned long 
length,
+   size_t (*strlcpy)(char *dest, const char *src, size_t size),
+   size_t (*strlcat)(char *dest, const char *src, size_t count)


Don't use names that overide names of existing functions.

'count' is __kernel_size_t not size_t


+   )
+{
+   if (src != dest && src != NULL) {
+   strlcpy(dest, " ", length);


Why do you need a space up front in that case ? Why not just copy the source to 
the destination ?


+   strlcat(dest, src, length);
+   }
+
+   if (sizeof(CONFIG_CMDLINE_APPEND) > 1)
+   strlcat(dest, " " CONFIG_CMDLINE_APPEND, length);
+
+   if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {
+   strlcpy(tmp, CONFIG_CMDLINE_PREPEND " ", length);
+   strlcat(tmp, dest, length);
+   strlcpy(dest, tmp, length);


Could we use memmove(), or implement strmove() and avoid the temporary buffer 
at all ?


+   }
+}
+
+#define cmdline_add_builtin_custom(dest, src, length, label, strlcpy, strlcat) 
\


It is misleading to call parameters 'strlcpy' or 'strlcat', it hides that they 
are overriden.


+{  
\
+   if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {   
 \
+   static label char cmdline_tmp_space[length];
\


Let the architecture define the temporary space when using the custom variant instead of just asking 
the architecture to provide the name of the section to use. powerpc already have prom_scratch for that.



+   __cmdline_add_builtin(dest, src, cmdline_tmp_space, length, 
strlcpy, strlcat);  \
+   } else if (sizeof(CONFIG_CMDLINE_APPEND) > 1) { 
 \
+   __cmdline_add_builtin(dest, src, NULL, length, strlcpy, 
strlcat);   \
+   }   
\


Ah, so if I understand correctly, the user can set both CONFIG_CMDLINE_PREPEND and 
CONFIG_CMDLINE_APPEND but one of them is silently ignored.


Then I think we should just offer the user to set one, name it CONFIG_CMDLINE then ask him to choose 
between FORCE, APPEND or PREPEND.



+}
+#define cmdline_add_builtin(dest, src, length)\
+   cmdline_add_builtin_custom(dest, src, length, __initdata, &strlcpy, 
&strlcat)
+#else
+#define cmdline_add_builtin(dest, src, length)

Re: [PATCH v2 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards

2021-03-03 Thread Vignesh Raghavendra
Hi,

On 2/12/21 1:02 AM, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> Add support for two Siemens SIMATIC IOT2050 variants, Basic and
> Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
> differ in their number of cores and availability of security features.
> Furthermore the Advanced version comes with more RAM, an eMMC and a few
> internal differences.
> 
> Based on original version by Le Jin.
> 
> Link: 
> https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
> Link: https://github.com/siemens/meta-iot2050
> Signed-off-by: Jan Kiszka 

Reviewed-by: Vignesh Raghavendra 

Few minor comments below:

[...]

> +
> +&mcu_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_i2c0_pins_default>;
> + clock-frequency = <40>;
> +
> + psu: tps62363@60 {

Please use generic node names:

psu: regulator@60 { ... };

> + compatible = "ti,tps62363";
> + reg =  <0x60>;
> + regulator-name = "tps62363-vout";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <150>;
> + regulator-boot-on;
> + ti,vsel0-state-high;
> + ti,vsel1-state-high;
> + ti,enable-vout-discharge;
> + };
> +
> + /* D4200 */
> + pcal9535_1: gpio@20 {
> + compatible = "nxp,pcal9535";
> + reg = <0x20>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + gpio-line-names =
> + "A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull",
> + "A5-pull", "", "",
> + "IO14-enable", "IO15-enable", "IO16-enable",
> + "IO17-enable", "IO18-enable", "IO19-enable";
> + };
> +
> + /* D4201 */
> + pcal9535_2: gpio@21 {
> + compatible = "nxp,pcal9535";
> + reg = <0x21>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + gpio-line-names =
> + "IO0-direction", "IO1-direction", "IO2-direction",
> + "IO3-direction", "IO4-direction", "IO5-direction",
> + "IO6-direction", "IO7-direction",
> + "IO8-direction", "IO9-direction", "IO10-direction",
> + "IO11-direction", "IO12-direction", "IO13-direction",
> + "IO19-direction";
> + };
> +
> + /* D4202 */
> + pcal9535_3: gpio@25 {
> + compatible = "nxp,pcal9535";
> + reg = <0x25>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + gpio-line-names =
> + "IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull",
> + "IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull",
> + "IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull",
> + "IO12-pull", "IO13-pull";
> + };
> +};

[...]

> +&dwc3_0 {
> + status = "okay";
> +};
> +
> +&usb0_phy {
> + status = "okay";
> +};
> +

These nodes are enabled by default right? Above is redundant.

> +&usb0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb0_pins_default>;
> + dr_mode = "host";
> +};
> +
> +&dwc3_1 {
> + status = "okay";
> +};
> +
> +&usb1_phy {
> + status = "okay";
> +};
> +

Same here...

> +&usb1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb1_pins_default>;
> + dr_mode = "host";
> +};
> +

[...]

> +&mcu_spi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_spi0_pins_default>;
> +
> + #address-cells = <1>;
> + #size-cells= <0>;
> + ti,pindir-d0-out-d1-in = <1>;
> +
> + spidev@0 {
> + compatible = "rohm,dh2228fv";
> + spi-max-frequency = <2000>;
> + reg = <0>;
> + };

Is the device really dh2228fv?

> +};
> +
> +&tscadc0 {
> + status = "disabled";
> +};
> +
> +&tscadc1 {
> + adc {
> + ti,adc-channels = <0 1 2 3 4 5>;
> + };
> +};
> +
> +&ospi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_fss0_ospi0_pins_default>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0x0>;
> + spi-tx-bus-width = <1>;
> + spi-rx-bus-width = <1>;
> + spi-max-frequency = <5000>;
> + cdns,tshsl-ns = <60>;
> + cdns,tsd2d-ns = <60>;
> + cdns,tchsh-ns = <60>;
> + cdns,tslch-ns = <60>;
> + cdns,read-delay = <2>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> +};
> +
> +&dss {
> + status = "okay";
> +

Node is enabled by default. Please drop above line for consistency.

> + pinctrl-names = "default";
> + pinctrl-0 = <&dss_vout1_pins_default>;
> +
> + assigned-clocks = <&k3_clks 67 2>;
> + assigned-clock-parents = <&k3_clks 67 5>;
> +};
> +
> +&dss_ports {
> + #address-cells = <1

Re: [RFC PATCH] autofs: find_autofs_mount overmounted parent support

2021-03-03 Thread Ian Kent
On Wed, 2021-03-03 at 18:28 +0300, Alexander Mikhalitsyn wrote:
> It was discovered that find_autofs_mount() function
> in autofs not support cases when autofs mount
> parent is overmounted. In this case this function will
> always return -ENOENT.

Ok, I get this shouldn't happen.

> 
> Real-life reproducer is fairly simple.
> Consider the following mounts on root mntns:
> --
> 35 24 0:36 / /proc/sys/fs/binfmt_misc ... shared:16 - autofs systemd-
> 1 ...
> 654 35 0:57 / /proc/sys/fs/binfmt_misc ... shared:322 - binfmt_misc
> ...
> --
> and some process which calls ioctl(AUTOFS_DEV_IOCTL_OPENMOUNT)
> $ unshare -m -p --fork --mount-proc ./process-bin
> 
> Due to "mount-proc" /proc will be overmounted and
> ioctl() will fail with -ENOENT

I think I need a better explanation ...

What's being said here?

For a start your talking about direct mounts, I'm pretty sure this
use case can't occur with indirect mounts in the sense that the
indirect mount base should/must never be over mounted and IIRC that
base can't be /proc (but maybe that's just mounts inside proc ...),
can't remember now but from a common sense POV an indirect mount
won't/can't be on /proc.

And why is this ioctl be called?

If the mount is over mounted should that prevent expiration of the
over mounted /proc anyway, so maybe the return is correct ... or
not ...

I get that the mount namespaces should be independent and intuitively
this is a bug but what is the actual use and expected result.

But anyway, aren't you saying that the VFS path walk isn't handling
mount namespaces properly or are you saying that a process outside
this new mount namespace becomes broken because of it?

Either way the solution looks more complicated than I'd expect so
some explanation along these lines would be good.

Ian
> 
> Cc: Matthew Wilcox 
> Cc: Al Viro 
> Cc: Pavel Tikhomirov 
> Cc: Kirill Tkhai 
> Cc: aut...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Alexander Mikhalitsyn <
> alexander.mikhalit...@virtuozzo.com>
> ---
>  fs/autofs/dev-ioctl.c | 127 +---
> --
>  fs/namespace.c|  44 +++
>  include/linux/mount.h |   5 ++
>  3 files changed, 162 insertions(+), 14 deletions(-)
> 
> diff --git a/fs/autofs/dev-ioctl.c b/fs/autofs/dev-ioctl.c
> index 5bf781ea6d67..55edd3eba8ce 100644
> --- a/fs/autofs/dev-ioctl.c
> +++ b/fs/autofs/dev-ioctl.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "autofs_i.h"
>  
> @@ -179,32 +180,130 @@ static int autofs_dev_ioctl_protosubver(struct
> file *fp,
>   return 0;
>  }
>  
> +struct filter_autofs_data {
> + char *pathbuf;
> + const char *fpathname;
> + int (*test)(const struct path *path, void *data);
> + void *data;
> +};
> +
> +static int filter_autofs(const struct path *path, void *p)
> +{
> + struct filter_autofs_data *data = p;
> + char *name;
> + int err;
> +
> + if (path->mnt->mnt_sb->s_magic != AUTOFS_SUPER_MAGIC)
> + return 0;
> +
> + name = d_path(path, data->pathbuf, PATH_MAX);
> + if (IS_ERR(name)) {
> + err = PTR_ERR(name);
> + pr_err("d_path failed, errno %d\n", err);
> + return 0;
> + }
> +
> + if (strncmp(data->fpathname, name, PATH_MAX))
> + return 0;
> +
> + if (!data->test(path, data->data))
> + return 0;
> +
> + return 1;
> +}
> +
>  /* Find the topmost mount satisfying test() */
>  static int find_autofs_mount(const char *pathname,
>struct path *res,
>int test(const struct path *path, void
> *data),
>void *data)
>  {
> - struct path path;
> + struct filter_autofs_data mdata = {
> + .pathbuf = NULL,
> + .test = test,
> + .data = data,
> + };
> + struct mnt_namespace *mnt_ns = current->nsproxy->mnt_ns;
> + struct path path = {};
> + char *fpathbuf = NULL;
>   int err;
>  
> + /*
> +  * In most cases user will provide full path to autofs mount
> point
> +  * as it is in /proc/X/mountinfo. But if not, then we need to
> +  * open provided relative path and calculate full path.
> +  * It will not work in case when parent mount of autofs mount
> +  * is overmounted:
> +  * cd /root
> +  * ./autofs_mount /root/autofs_yard/mnt
> +  * mount -t tmpfs tmpfs /root/autofs_yard/mnt
> +  * mount -t tmpfs tmpfs /root/autofs_yard
> +  * ./call_ioctl /root/autofs_yard/mnt <- all fine here because
> we
> +  *   have full path and
> don't
> +  *   need to call
> kern_path()
> +  *   and d_path()
> +  * ./call_ioctl autofs_yard/mnt <- will fail because
> kern_path()
> +  * can't lookup
> /root/autofs_yard/mnt
> +  *  

ERROR: modpost: "devm_platform_ioremap_resource" undefined!

2021-03-03 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f69d02e37a85645aa90d18cacfff36dba370f797
commit: 7cbb0c63de3fc218fd06ecfedb42a4d12f76 dmaengine: xilinx: dpdma: Add 
the Xilinx DisplayPort DMA engine driver
date:   8 months ago
config: s390-randconfig-r002-20210304 (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7cbb0c63de3fc218fd06ecfedb42a4d12f76
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 7cbb0c63de3fc218fd06ecfedb42a4d12f76
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

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

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

ERROR: modpost: "devm_ioremap" [drivers/input/keyboard/samsung-keypad.ko] 
undefined!
ERROR: modpost: "devm_ioremap_resource" [drivers/dma/sf-pdma/sf-pdma.ko] 
undefined!
ERROR: modpost: "devm_ioremap_resource" [drivers/dma/idma64.ko] undefined!
ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/dw/dw_dmac.ko] 
undefined!
ERROR: modpost: "devm_ioremap" [drivers/dma/altera-msgdma.ko] undefined!
>> ERROR: modpost: "devm_platform_ioremap_resource" 
>> [drivers/dma/xilinx/xilinx_dpdma.ko] undefined!
ERROR: modpost: "devm_ioremap_resource" [drivers/dma/qcom/hdma.ko] undefined!

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


.config.gz
Description: application/gzip


Re: [PATCH 2/4] userfaultfd.2: Add write-protect mode

2021-03-03 Thread Mike Rapoport
On Wed, Mar 03, 2021 at 08:59:45PM -0500, Peter Xu wrote:
> Write-protect mode is supported starting from Linux 5.7.
> 
> Signed-off-by: Peter Xu 
> ---
>  man2/userfaultfd.2 | 88 --
>  1 file changed, 86 insertions(+), 2 deletions(-)
> 
> diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
> index 2d14effc6..8e1602d62 100644
> --- a/man2/userfaultfd.2
> +++ b/man2/userfaultfd.2
> @@ -78,6 +78,28 @@ all memory ranges that were registered with the object are 
> unregistered
>  and unread events are flushed.
>  .\"
>  .PP
> +Currently, userfaultfd supports two modes of registration:
> +.TP
> +.BR UFFDIO_REGISTER_MODE_MISSING
> +When registered with
> +.BR UFFDIO_REGISTER_MODE_MISSING
> +mode, the userspace will receive a page fault message when a missing page is
> +accessed.  The faulted thread will be stopped from execution until the page
> +fault is resolved from the userspace by either an
> +.BR UFFDIO_COPY
> +or an
> +.BR UFFDIO_ZEROPAGE
> +ioctl.
> +.TP
> +.BR UFFDIO_REGISTER_MODE_WP
> +When registered with
> +.BR UFFDIO_REGISTER_MODE_WP
> +mode, the userspace will receive a page fault message when a write-protected
> +page is written.  The faulted thread will be stopped from execution until the
> +userspace un-write-protect the page using an
> +.BR UFFDIO_WRITEPROTECT
> +ioctl.
> +.PP

I'd add a sentence about combining the modes together. Something like

"Both modes can be enabled together for the same memory range"

>  Since Linux 4.14, userfaultfd page fault message can selectively embed fault
>  thread ID information into the fault message.  One needs to enable this 
> feature
>  explicitly using the
> @@ -143,6 +165,16 @@ single threaded non-cooperative userfaultfd manager 
> implementations.
>  .\" and limitations remaining in 4.11
>  .\" Maybe it's worth adding a dedicated sub-section...
>  .\"
> +.PP
> +Starting from Linux 5.7, userfaultfd is able to do synchronous page dirty
> +tracking using the new write-protection register mode.  One should check
> +against the feature bit
> +.B UFFD_FEATURE_PAGEFAULT_FLAG_WP
> +before using this feature.  Similar to the original userfaultfd missing mode,
> +the write-protect mode will generate an userfaultfd message when the 
> protected
> +page is written.  The user needs to resolve the page fault by unprotecting 
> the
> +faulted page and kick the faulted thread to continue.  For more information,
> +please read the "Userfaultfd write-protect mode" section below.
>  .SS Userfaultfd operation
>  After the userfaultfd object is created with
>  .BR userfaultfd (),
> @@ -218,6 +250,54 @@ userfaultfd can be used only with anonymous private 
> memory mappings.
>  Since Linux 4.11,
>  userfaultfd can be also used with hugetlbfs and shared memory mappings.
>  .\"
> +.SS Userfaultfd write-protect mode
> +Since Linux 5.7, userfaultfd started to support write-protect mode.  The user

Maybe s/started to support/supports/

> +needs to first check availability of this feature using
> +.BR UFFDIO_API
> +ioctl against the feature bit
> +.BR UFFD_FEATURE_PAGEFAULT_FLAG_WP .
> +.PP
> +To register with userfaultfd write-protect mode, the user needs to send the
> +.BR UFFDIO_REGISTER
> +ioctl with mode
> +.BR UFFDIO_REGISTER_MODE_WP
> +set.  Note that it's legal to monitor the same memory range with multiple
> +modes.  For example, the user can do
> +.BR UFFDIO_REGISTER
> +with the mode set to
> +.BR UFFDIO_REGISTER_MODE_MISSING\ |\ UFFDIO_REGISTER_MODE_WP.
> +When there is only
> +.BR UFFDIO_REGISTER_MODE_WP
> +registered, the userspace will
> +.I not
> +receive any message when a missing page is written.  Instead, the userspace
> +will only receive a write-protect page fault message when an existing but
> +write-protected page got written.
> +.PP
> +After the
> +.BR UFFDIO_REGISTER
> +ioctl completed with
> +.BR UFFDIO_REGISTER_MODE_WP
> +mode set, one can write-protect any existing memory within the range using 
> the
> +ioctl
> +.BR UFFDIO_WRITEPROTECT
> +where
> +.I uffdio_writeprotect.mode
> +should be set to
> +.BR UFFDIO_WRITEPROTECT_MODE_WP .
> +.PP
> +When a write-protect event happens, the userspace will receive a page fault
> +message whose
> +.I uffd_msg.pagefault.flags
> +will be with
> +.BR UFFD_PAGEFAULT_FLAG_WP
> +flag set.  Note: since only writes can trigger such kind of fault,
> +write-protect messages will always be with
> +.BR UFFD_PAGEFAULT_FLAG_WRITE
> +bit set too along with
> +.BR UFFD_PAGEFAULT_FLAG_WP .
> +.PP
> +Currently, write-protect mode only supports private anonymous memory.
>  .SS Reading from the userfaultfd structure
>  Each
>  .BR read (2)
> @@ -363,8 +443,12 @@ flag (see
>  .BR ioctl_userfaultfd (2))
>  and this flag is set, this a write fault;
>  otherwise it is a read fault.
> -.\"
> -.\" UFFD_PAGEFAULT_FLAG_WP is not yet supported.
> +.TP
> +.B UFFD_PAGEFAULT_FLAG_WP
> +If the address is in a range that was registered with the
> +.B UFFDIO_REGISTER_MODE_WP
> +flag, when this bit is set i

Re: [PATCH] perf report: Fix -F for branch & mem modes

2021-03-03 Thread Athira Rajeev



> On 04-Mar-2021, at 11:59 AM, Ravi Bangoria  
> wrote:
> 
> perf report fails to add valid additional fields with -F when
> used with branch or mem modes. Fix it.
> 
> Before patch:
> 
>  $ ./perf record -b
>  $ ./perf report -b -F +srcline_from --stdio
>  Error:
>  Invalid --fields key: `srcline_from'
> 
> After patch:
> 
>  $ ./perf report -b -F +srcline_from --stdio
>  # Samples: 8K of event 'cycles'
>  # Event count (approx.): 8784
>  ...
> 
> Reported-by: Athira Rajeev 
> Fixes: aa6b3c99236b ("perf report: Make -F more strict like -s")
> Signed-off-by: Ravi Bangoria 

Thanks for the fix Ravi.

Reviewed-and-tested-by: Athira Rajeev 

> ---
> tools/perf/util/sort.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index 0d5ad42812b9..552b590485bf 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -3140,7 +3140,7 @@ int output_field_add(struct perf_hpp_list *list, char 
> *tok)
>   if (strncasecmp(tok, sd->name, strlen(tok)))
>   continue;
> 
> - if (sort__mode != SORT_MODE__MEMORY)
> + if (sort__mode != SORT_MODE__BRANCH)
>   return -EINVAL;
> 
>   return __sort_dimension__add_output(list, sd);
> @@ -3152,7 +3152,7 @@ int output_field_add(struct perf_hpp_list *list, char 
> *tok)
>   if (strncasecmp(tok, sd->name, strlen(tok)))
>   continue;
> 
> - if (sort__mode != SORT_MODE__BRANCH)
> + if (sort__mode != SORT_MODE__MEMORY)
>   return -EINVAL;
> 
>   return __sort_dimension__add_output(list, sd);
> -- 
> 2.29.2
> 



Re: [PATCH v2] MIPS: Make MIPS32_O32 depends on !CC_IS_CLANG

2021-03-03 Thread Nathan Chancellor
On Thu, Mar 04, 2021 at 02:19:38PM +0800, Tiezhu Yang wrote:
> When build kernel with Clang [1]:

Sorry I did not catch this in the first revision but I think this would
sound better as:

When building with Clang [1]:

I think the kernel part is obvious :) couple more comments about the
commit message inline.

> 
> $ make CC=clang loongson3_defconfig
> $ make CC=clang
> 
> there exists the following error:
> 
>   Checking missing-syscalls for O32
>   CALLscripts/checksyscalls.sh
> error: ABI 'o32' is not supported on CPU 'mips64r2'
> make[1]: *** [Kbuild:48: missing-syscalls] Error 1
> make: *** [arch/mips/Makefile:419: archprepare] Error 2
> 
> This is a known bug [2] with Clang, as Simon Atanasyan said,
> "There is no plan on support O32 for MIPS64 due to lack of
> resources".
> 
> It is not a good idea to remove CONFIG_MIPS32_O32=y directly
> in defconfig due to GCC works well, as Nathan said, the config

in defconfig because GCC works, as...

> should not even be selectable when build kernel with Clang, so

 building with Clang

> just make MIPS32_O32 depends on !CC_IS_CLANG.
> 
> [1] https://www.kernel.org/doc/html/latest/kbuild/llvm.html
> [2] https://bugs.llvm.org/show_bug.cgi?id=38063
> 
> Signed-off-by: Tiezhu Yang 

I don't know if Nick will have any comments but for me:

Acked-by: Nathan Chancellor 

I have added this patch and the LLVM bug to our issue tracker:

https://github.com/ClangBuiltLinux/linux/issues/884

> ---
>  arch/mips/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 3a38d27..f6ba59f 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -3318,6 +3318,8 @@ config SYSVIPC_COMPAT
>  config MIPS32_O32
>   bool "Kernel support for o32 binaries"
>   depends on 64BIT
> + # https://bugs.llvm.org/show_bug.cgi?id=38063
> + depends on !CC_IS_CLANG
>   select ARCH_WANT_OLD_COMPAT_IPC
>   select COMPAT
>   select MIPS32_COMPAT
> -- 
> 2.1.0
> 


Re: [PATCH] mm,hwpoison: return -EBUSY when page already poisoned

2021-03-03 Thread Aili Yao
On Thu, 4 Mar 2021 12:19:41 +0800
Aili Yao  wrote:

> On Thu, 4 Mar 2021 10:16:53 +0800
> Aili Yao  wrote:
> 
> > On Wed, 3 Mar 2021 15:41:35 +
> > "Luck, Tony"  wrote:
> >   
> > > > For error address with sigbus, i think this is not an issue resulted by 
> > > > the patch i post, before my patch, the issue is already there.
> > > > I don't find a realizable way to get the correct address for same 
> > > > reason --- we don't know whether the page mapping is there or not when
> > > > we got to kill_me_maybe(), in some case, we may get it, but there are a 
> > > > lot of parallel issue need to consider, and if failed we have to 
> > > > fallback
> > > > to the error brach again, remaining current code may be an easy option; 
> > > >  
> > > 
> > > My RFC patch from yesterday removes the uncertainty about whether the 
> > > page is there or not. After it walks the page
> > > tables we know that the poison page isn't mapped (note that patch is RFC 
> > > for a reason ... I'm 90% sure that it should
> > > do a bit more that just clear the PRESENT bit).
> > > 
> > > So perhaps memory_failure() has queued a SIGBUS for this task, if so, we 
> > > take it when we return from kill_me_maybe()  
> 
> And when this happen, the process will receive an SIGBUS with AO level, is it 
> proper as not an AR?
> 
> > > If not, we will return to user mode and re-execute the failing 
> > > instruction ... but because the page is unmapped we will take a #PF
> > 
> > Got this, I have some error thoughts here.
> > 
> >   
> > > The x86 page fault handler will see that the page for this physical 
> > > address is marked HWPOISON, and it will send the SIGBUS
> > > (just like it does if the page had been removed by an earlier UCNA/SRAO 
> > > error).
> > 
> > if your methods works, should it be like this?
> > 
> > 1582 pteval = 
> > swp_entry_to_pte(make_hwpoison_entry(subpage));
> > 1583 if (PageHuge(page)) {
> > 1584 hugetlb_count_sub(compound_nr(page), 
> > mm);
> > 1585 set_huge_swap_pte_at(mm, address,
> > 1586  pvmw.pte, pteval,
> > 1587  
> > vma_mmu_pagesize(vma));
> > 1588 } else {
> > 1589 dec_mm_counter(mm, mm_counter(page));
> > 1590 set_pte_at(mm, address, pvmw.pte, 
> > pteval);
> > 1591 }
> > 
> > the page fault check if it's a poison page using is_hwpoison_entry(),
> >   
> 
> And if it works, does we need some locking mechanism before we call 
> walk_page_range();
> if we lock, does we need to process the blocking interrupted error as other 
> places will do?
> 

And another thing:
Do we need a call to flush_tlb_page(vma, address) to make the pte changes into 
effect?

-- 
Thanks!
Aili Yao


Re: [PATCH v2] crypto/nx: add missing call to of_node_put()

2021-03-03 Thread Herbert Xu
On Fri, Feb 26, 2021 at 09:23:06AM +0800, Yang Li wrote:
> In one of the error paths of the for_each_child_of_node() loop,
> add missing call to of_node_put().
> 
> Fix the following coccicheck warning:
> ./drivers/crypto/nx/nx-common-powernv.c:927:1-23: WARNING: Function
> "for_each_child_of_node" should have of_node_put() before return around
> line 936.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 
> ---
> 
> Changes in v2:
> -add braces for if
> 
>  drivers/crypto/nx/nx-common-powernv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: testmgr - delete some redundant code

2021-03-03 Thread Herbert Xu
On Tue, Feb 23, 2021 at 11:42:04AM +0800, Kai Ye wrote:
> Delete sg_data function, because sg_data function definition same as
> sg_virt(), so need to delete it and use sg_virt() replace to sg_data().
> 
> Signed-off-by: Kai Ye 
> ---
>  crypto/testmgr.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[PATCH v1] mm, hwpoison: do not lock page again when me_huge_page() successfully recovers

2021-03-03 Thread Naoya Horiguchi
From: Naoya Horiguchi 

Currently me_huge_page() temporary unlocks page to perform some actions
then locks it again later. My testcase (which calls hard-offline on some
tail page in a hugetlb, then accesses the address of the hugetlb range)
showed that page allocation code detects the page lock on buddy page and
printed out "BUG: Bad page state" message.  PG_hwpoison does not prevent
it because PG_hwpoison flag is set on any subpage of the hugetlb page
but the 2nd page lock is on the head page.

This patch suggests to drop the 2nd page lock to fix the issue.

Fixes: commit 78bb920344b8 ("mm: hwpoison: dissolve in-use hugepage in 
unrecoverable memory error")
Cc: sta...@vger.kernel.org
Signed-off-by: Naoya Horiguchi 
---
 mm/memory-failure.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git v5.11/mm/memory-failure.c v5.11_patched/mm/memory-failure.c
index e9481632fcd1..d8aba15295c5 100644
--- v5.11/mm/memory-failure.c
+++ v5.11_patched/mm/memory-failure.c
@@ -830,7 +830,6 @@ static int me_huge_page(struct page *p, unsigned long pfn)
page_ref_inc(p);
res = MF_RECOVERED;
}
-   lock_page(hpage);
}
 
return res;
@@ -1286,7 +1285,8 @@ static int memory_failure_hugetlb(unsigned long pfn, int 
flags)
 
res = identify_page_state(pfn, p, page_flags);
 out:
-   unlock_page(head);
+   if (PageLocked(head))
+   unlock_page(head);
return res;
 }
 
-- 
2.25.1



Re: [RFT PATCH] crypto: s5p-sss - initialize APB clock after the AXI bus clock for SlimSSS

2021-03-03 Thread Herbert Xu
On Fri, Feb 12, 2021 at 05:35:26PM +0100, Krzysztof Kozlowski wrote:
> The driver for Slim Security Subsystem (SlimSSS) on Exynos5433 takes two
> clocks - aclk (AXI/AHB clock) and pclk (APB/Advanced Peripheral Bus
> clock).  The "aclk", as main high speed bus clock, is enabled first.  Then
> the "pclk" is enabled.
> 
> However the driver assigned reversed names for lookup of these clocks
> from devicetree, so effectively the "pclk" was enabled first.
> 
> Although it might not matter in reality, the correct order is to enable
> first main/high speed bus clock - "aclk".  Also this was the intention
> of the actual code.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Not tested, please kindly test on Exynos5433 hardware.
> ---
>  drivers/crypto/s5p-sss.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 3/8] spi: dw: Add support for Pensando Elba SoC SPI

2021-03-03 Thread Serge Semin
Hello Brad.
Thanks for the patch. See my comments below.

On Wed, Mar 03, 2021 at 07:41:36PM -0800, Brad Larson wrote:
> The Pensando Elba SoC uses a GPIO based chip select
> for two DW SPI busses with each bus having two
> chip selects.

I see a contradiction here. Normally GPIO-based chip-select is a
property of a platform, but not a SoC/CPU/MCU/etc. Most of the time
SoC SPI interfaces still get to have native CS pins, while at some
platform configurations (like in case of DW APB SPI, which doesn't
provide a way to directly toggle its native CSs) it's easier or even
safer to use GPIOs as CS signals. Of course theoretically a SoC could
be synthesized so it doesn't have native CS output pins, but only some
virtual internal CS flags, but I've never seen such. Anyway according
to the custom CS method below it's not your case because you still
provide support for SPI-devices handled by native CS (else branch in
the if (spi->cs_gpiod) {} else {} statement).

> 
> Signed-off-by: Brad Larson 
> ---
>  drivers/spi/spi-dw-mmio.c | 35 ++-
>  1 file changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index 17c06039a74d..417bd2125c07 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -56,7 +56,7 @@ struct dw_spi_mscc {
>  /*
>   * The Designware SPI controller (referred to as master in the documentation)
>   * automatically deasserts chip select when the tx fifo is empty. The chip
> - * selects then needs to be either driven as GPIOs or, for the first 4 using 
> the
> + * selects then needs to be either driven as GPIOs or, for the first 4 using
>   * the SPI boot controller registers. the final chip select is an OR gate
>   * between the Designware SPI controller and the SPI boot controller.
>   */
> @@ -237,6 +237,38 @@ static int dw_spi_canaan_k210_init(struct 
> platform_device *pdev,
>   return 0;
>  }
>
  
> +static void dw_spi_elba_set_cs(struct spi_device *spi, bool enable)
> +{
> + struct dw_spi *dws = spi_master_get_devdata(spi->master);
> +
> + if (!enable) {
> + if (spi->cs_gpiod) {
> + /*
> +  * Using a GPIO-based chip-select, the DW SPI
> +  * controller still needs its own CS bit selected
> +  * to start the serial engine.  On Elba the specific
> +  * CS doesn't matter, so use CS0.
> +  */
> + dw_writel(dws, DW_SPI_SER, BIT(0));
> + } else {
> + /*
> +  * Using the intrinsic DW chip-select; set the
> +  * appropriate CS.
> +  */
> + dw_writel(dws, DW_SPI_SER, BIT(spi->chip_select));
> + }
> - } else
  + } else {
> + dw_writel(dws, DW_SPI_SER, 0);
  + } /* See [1] */
> +}

The custom CS-method above doesn't look much different from the
dw_spi_set_cs() method defined in the spi-dw-core.o driver, except
having at least two problems:
1) It assumes that "enable" argument means the CS-enabling flag, while
in fact it's the CS-level which depending on the SPI_CS_HIGH flag
set/cleared will be 1/0 respectively if CS is supposed to be enabled.
That aspect has already been fixed in the dw_spi_set_cs() method.
2) The method enables CS[0] if GPIO-CS is used for a particular SPI
device. That will cause problems for a GPIO/native CS intermixed case
of having for instance one SPI-device connected to native CS[0] and
another one - to a GPIO. So trying to communicate with the second SPI
device you'll end up having the native CS[0] activated too thus
having an SPI transfer sent to two SPI-device at the same time.
Of course that's not what you'd want.

Anyway I don't really see why you even need a custom CS method here. A
generic method dw_spi_set_cs() shall work for your SPI interface.
If I am wrong, please explain why. Did you try the generic CS method
on your platform?

[1] Placing Braces and Spaces. Chapter 3). 
Documentation/process/coding-style.rst

> +
> +static int dw_spi_elba_init(struct platform_device *pdev,
> + struct dw_spi_mmio *dwsmmio)
> +{
> + dwsmmio->dws.set_cs = dw_spi_elba_set_cs;
> +
> + return 0;
> +}
> +
>  static int dw_spi_mmio_probe(struct platform_device *pdev)
>  {
>   int (*init_func)(struct platform_device *pdev,
> @@ -351,6 +383,7 @@ static const struct of_device_id dw_spi_mmio_of_match[] = 
> {
>   { .compatible = "intel,keembay-ssi", .data = dw_spi_keembay_init},
>   { .compatible = "microchip,sparx5-spi", dw_spi_mscc_sparx5_init},
>   { .compatible = "canaan,k210-spi", dw_spi_canaan_k210_init},

> + { .compatible = "pensando,elba-spi", .data = dw_spi_elba_init },

If you agree with me and remove the custom CS-method defined above in
this patch, then all you'll need is just to add "pensando,elba-spi" here
with g

Re: [PATCH] crypto: sun8i-ss: fix result memory leak on error path

2021-03-03 Thread Herbert Xu
On Fri, Feb 12, 2021 at 09:46:10AM +0100, Corentin Labbe wrote:
> This patch fixes a memory leak on an error path.
> 
> Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms")
> Reported-by: kernel test robot 
> Reported-by: Dan Carpenter 
> Signed-off-by: Corentin Labbe 
> ---
>  drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH v7 00/11] Regression fixes/clean ups in the Qualcomm crypto engine driver

2021-03-03 Thread Herbert Xu
On Thu, Feb 11, 2021 at 03:01:17PM -0500, Thara Gopinath wrote:
> This patch series is a result of running kernel crypto fuzz tests (by
> enabling CONFIG_CRYPTO_MANAGER_EXTRA_TESTS) on the transformations
> currently supported via the Qualcomm crypto engine on sdm845.  The first
> nine patches are fixes for various regressions found during testing. The
> last two patches are minor clean ups of unused variable and parameters.
> 
> v6->v7:
>   - Fixed sparse warning in patch 4 as pointed out by Herbert Xu.
> This means the checking if any two keys are same for triple
> des algorithms has been reverted back to using conditional OR
> instead of using bitwise OR.
>   - Rebased to 5.11-rc7.
> 
> v5->v6:
>   - Return 0 for zero length messages instead of -EOPNOTSUPP in the
> cipher algorithms as pointed out by Eric Biggers.
>   - Remove the wrong TODO in patch 6 which implied that AES CBC can
> do partial block sizes when it is actually CTS mode that can as
> pointed out my Eric Biggers.
> 
> v4->v5:
>   - Fixed build warning/error in patch for wrong assignment of const
> pointer as reported by kernel test robot .
>   - Rebased to 5.11-rc6.
> v3->v4:
>   - Fixed the bug where only two bytes of byte_count were getting
> saved and restored instead of all eight bytes. Thanks Bjorn for
> catching this.
>   - Split patch 3 "Fix regressions found during fuzz testing" into
> 6 patches as requested by Bjorn.
>   - Dropped crypto from all subject headers.
>   - Rebased to 5.11-rc5
> v2->v3:
> - Made the comparison between keys to check if any two keys are
>   same for triple des algorithms constant-time as per
>   Nym Seddon's suggestion.
> - Rebased to 5.11-rc4.
> v1->v2:
> - Introduced custom struct qce_sha_saved_state to store and restore
>   partial sha transformation.
> - Rebased to 5.11-rc3.
> 
> Thara Gopinath (11):
>   crypto: qce: sha: Restore/save ahash state with custom struct in
> export/import
>   crypto: qce: sha: Hold back a block of data to be transferred as part
> of final
>   crypto: qce: skcipher: Return unsupported if key1 and key 2 are same
> for AES XTS algorithm
>   crypto: qce: skcipher: Return unsupported if any three keys are same
> for DES3 algorithms
>   crypto: qce: skcipher: Return error for zero length messages
>   crypto: qce: skcipher: Return error for non-blocksize data(ECB/CBC
> algorithms)
>   crypto: qce: skcipher: Set ivsize to 0 for ecb(aes)
> *** BLURB HERE ***
> 
> Thara Gopinath (11):
>   crypto: qce: sha: Restore/save ahash state with custom struct in
> export/import
>   crypto: qce: sha: Hold back a block of data to be transferred as part
> of final
>   crypto: qce: skcipher: Return unsupported if key1 and key 2 are same
> for AES XTS algorithm
>   crypto: qce: skcipher: Return unsupported if any three keys are same
> for DES3 algorithms
>   crypto: qce: skcipher: Return error for zero length messages
>   crypto: qce: skcipher: Return error for non-blocksize data(ECB/CBC
> algorithms)
>   crypto: qce: skcipher: Set ivsize to 0 for ecb(aes)
>   crypto: qce: skcipher: Improve the conditions for requesting AES
> fallback cipher
>   crypto: qce: common: Set data unit size to message length for AES XTS
> transformation
>   crypto: qce: Remover src_tbl from qce_cipher_reqctx
>   crypto: qce: Remove totallen and offset in qce_start
> 
>  drivers/crypto/qce/cipher.h   |   1 -
>  drivers/crypto/qce/common.c   |  25 +++---
>  drivers/crypto/qce/common.h   |   3 +-
>  drivers/crypto/qce/sha.c  | 143 +-
>  drivers/crypto/qce/skcipher.c |  69 +---
>  5 files changed, 126 insertions(+), 115 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: amlogic - Fix unnecessary check in meson_crypto_probe()

2021-03-03 Thread Herbert Xu
On Wed, Feb 10, 2021 at 11:16:37AM +0800, Tang Bin wrote:
> The function meson_crypto_probe() is only called with an openfirmware
> platform device. Therefore there is no need to check that the passed
> in device is NULL.
> 
> Signed-off-by: Tang Bin 
> ---
>  drivers/crypto/amlogic/amlogic-gxl-core.c | 3 ---
>  1 file changed, 3 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[PATCH] selftests_bpf: extend test_tc_tunnel test with vxlan

2021-03-03 Thread Xuesen Huang
From: Xuesen Huang 

Add BPF_F_ADJ_ROOM_ENCAP_L2_ETH flag to the existing tests which
encapsulates the ethernet as the inner l2 header.

Update a vxlan encapsulation test case.

Signed-off-by: Xuesen Huang 
Signed-off-by: Li Wang 
Signed-off-by: Willem de Bruijn 
---
 tools/testing/selftests/bpf/progs/test_tc_tunnel.c | 113 ++---
 tools/testing/selftests/bpf/test_tc_tunnel.sh  |  15 ++-
 2 files changed, 111 insertions(+), 17 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c 
b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
index 37bce7a..dbd18d0 100644
--- a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
+++ b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
@@ -24,14 +24,29 @@
 
 static const int cfg_udp_src = 2;
 
+#defineL2_PAD_SZ   (sizeof(struct vxlanhdr) + ETH_HLEN)
+
 #defineUDP_PORT
 #defineMPLS_OVER_UDP_PORT  6635
 #defineETH_OVER_UDP_PORT   
+#defineVXLAN_UDP_PORT  8472
+
+#defineEXTPROTO_VXLAN  0x1
+
+#defineVXLAN_N_VID (1u << 24)
+#defineVXLAN_VNI_MASK  bpf_htonl((VXLAN_N_VID - 1) << 8)
+#defineVXLAN_FLAGS 0x8
+#defineVXLAN_VNI   1
 
 /* MPLS label 1000 with S bit (last label) set and ttl of 255. */
 static const __u32 mpls_label = __bpf_constant_htonl(1000 << 12 |
 MPLS_LS_S_MASK | 0xff);
 
+struct vxlanhdr {
+   __be32 vx_flags;
+   __be32 vx_vni;
+} __attribute__((packed));
+
 struct gre_hdr {
__be16 flags;
__be16 protocol;
@@ -45,13 +60,13 @@ struct gre_hdr {
 struct v4hdr {
struct iphdr ip;
union l4hdr l4hdr;
-   __u8 pad[16];   /* enough space for L2 header */
+   __u8 pad[L2_PAD_SZ];/* space for L2 header / vxlan header 
... */
 } __attribute__((packed));
 
 struct v6hdr {
struct ipv6hdr ip;
union l4hdr l4hdr;
-   __u8 pad[16];   /* enough space for L2 header */
+   __u8 pad[L2_PAD_SZ];/* space for L2 header / vxlan header 
... */
 } __attribute__((packed));
 
 static __always_inline void set_ipv4_csum(struct iphdr *iph)
@@ -69,14 +84,15 @@ static __always_inline void set_ipv4_csum(struct iphdr *iph)
iph->check = ~((csum & 0x) + (csum >> 16));
 }
 
-static __always_inline int encap_ipv4(struct __sk_buff *skb, __u8 encap_proto,
- __u16 l2_proto)
+static __always_inline int __encap_ipv4(struct __sk_buff *skb, __u8 
encap_proto,
+   __u16 l2_proto, __u16 ext_proto)
 {
__u16 udp_dst = UDP_PORT;
struct iphdr iph_inner;
struct v4hdr h_outer;
struct tcphdr tcph;
int olen, l2_len;
+   __u8 *l2_hdr = NULL;
int tcp_off;
__u64 flags;
 
@@ -141,7 +157,11 @@ static __always_inline int encap_ipv4(struct __sk_buff 
*skb, __u8 encap_proto,
break;
case ETH_P_TEB:
l2_len = ETH_HLEN;
-   udp_dst = ETH_OVER_UDP_PORT;
+   if (ext_proto & EXTPROTO_VXLAN) {
+   udp_dst = VXLAN_UDP_PORT;
+   l2_len += sizeof(struct vxlanhdr);
+   } else
+   udp_dst = ETH_OVER_UDP_PORT;
break;
}
flags |= BPF_F_ADJ_ROOM_ENCAP_L2(l2_len);
@@ -171,14 +191,26 @@ static __always_inline int encap_ipv4(struct __sk_buff 
*skb, __u8 encap_proto,
}
 
/* add L2 encap (if specified) */
+   l2_hdr = (__u8 *)&h_outer + olen;
switch (l2_proto) {
case ETH_P_MPLS_UC:
-   *((__u32 *)((__u8 *)&h_outer + olen)) = mpls_label;
+   *(__u32 *)l2_hdr = mpls_label;
break;
case ETH_P_TEB:
-   if (bpf_skb_load_bytes(skb, 0, (__u8 *)&h_outer + olen,
-  ETH_HLEN))
+   flags |= BPF_F_ADJ_ROOM_ENCAP_L2_ETH;
+
+   if (ext_proto & EXTPROTO_VXLAN) {
+   struct vxlanhdr *vxlan_hdr = (struct vxlanhdr *)l2_hdr;
+
+   vxlan_hdr->vx_flags = VXLAN_FLAGS;
+   vxlan_hdr->vx_vni = bpf_htonl((VXLAN_VNI & 
VXLAN_VNI_MASK) << 8);
+
+   l2_hdr += sizeof(struct vxlanhdr);
+   }
+
+   if (bpf_skb_load_bytes(skb, 0, l2_hdr, ETH_HLEN))
return TC_ACT_SHOT;
+
break;
}
olen += l2_len;
@@ -214,14 +246,21 @@ static __always_inline int encap_ipv4(struct __sk_buff 
*skb, __u8 encap_proto,
return TC_ACT_OK;
 }
 
-static __always_inline int encap_ipv6(struct __sk_buff *skb, __u8 encap_proto,
+static __always_inline int encap_ipv4(struct __sk_buff *skb, __u8 encap_proto,
  __u16 l2_proto)
 {
+   return __encap_ipv4(skb, encap_proto, l2_proto, 0);
+}
+
+st

arch/arm64/kernel/hibernate.c:202:44: sparse: sparse: cast from restricted gfp_t

2021-03-03 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f69d02e37a85645aa90d18cacfff36dba370f797
commit: 50f53fb721817a6efa541cca24f1b7caa84801c1 arm64: trans_pgd: make 
trans_pgd_map_page generic
date:   5 weeks ago
config: arm64-randconfig-s032-20210304 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-245-gacc5c298-dirty
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50f53fb721817a6efa541cca24f1b7caa84801c1
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 50f53fb721817a6efa541cca24f1b7caa84801c1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64 

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


"sparse warnings: (new ones prefixed by >>)"
   arch/arm64/kernel/hibernate.c:181:39: sparse: sparse: cast to restricted 
gfp_t
>> arch/arm64/kernel/hibernate.c:202:44: sparse: sparse: cast from restricted 
>> gfp_t

vim +202 arch/arm64/kernel/hibernate.c

   178  
   179  static void *hibernate_page_alloc(void *arg)
   180  {
 > 181  return (void *)get_safe_page((gfp_t)(unsigned long)arg);
   182  }
   183  
   184  /*
   185   * Copies length bytes, starting at src_start into an new page,
   186   * perform cache maintenance, then maps it at the specified address low
   187   * address as executable.
   188   *
   189   * This is used by hibernate to copy the code it needs to execute when
   190   * overwriting the kernel text. This function generates a new set of 
page
   191   * tables, which it loads into ttbr0.
   192   *
   193   * Length is provided as we probably only want 4K of data, even on a 64K
   194   * page system.
   195   */
   196  static int create_safe_exec_page(void *src_start, size_t length,
   197   unsigned long dst_addr,
   198   phys_addr_t *phys_dst_addr)
   199  {
   200  struct trans_pgd_info trans_info = {
   201  .trans_alloc_page   = hibernate_page_alloc,
 > 202  .trans_alloc_arg= (void *)GFP_ATOMIC,
   203  };
   204  
   205  void *page = (void *)get_safe_page(GFP_ATOMIC);
   206  pgd_t *trans_pgd;
   207  int rc;
   208  
   209  if (!page)
   210  return -ENOMEM;
   211  
   212  memcpy(page, src_start, length);
   213  __flush_icache_range((unsigned long)page, (unsigned long)page + 
length);
   214  
   215  trans_pgd = (void *)get_safe_page(GFP_ATOMIC);
   216  if (!trans_pgd)
   217  return -ENOMEM;
   218  
   219  rc = trans_pgd_map_page(&trans_info, trans_pgd, page, dst_addr,
   220  PAGE_KERNEL_EXEC);
   221  if (rc)
   222  return rc;
   223  
   224  /*
   225   * Load our new page tables. A strict BBM approach requires 
that we
   226   * ensure that TLBs are free of any entries that may overlap 
with the
   227   * global mappings we are about to install.
   228   *
   229   * For a real hibernate/resume cycle TTBR0 currently points to 
a zero
   230   * page, but TLBs may contain stale ASID-tagged entries (e.g. 
for EFI
   231   * runtime services), while for a userspace-driven test_resume 
cycle it
   232   * points to userspace page tables (and we must point it at a 
zero page
   233   * ourselves). Elsewhere we only (un)install the idmap with 
preemption
   234   * disabled, so T0SZ should be as required regardless.
   235   */
   236  cpu_set_reserved_ttbr0();
   237  local_flush_tlb_all();
   238  write_sysreg(phys_to_ttbr(virt_to_phys(trans_pgd)), ttbr0_el1);
   239  isb();
   240  
   241  *phys_dst_addr = virt_to_phys(page);
   242  
   243  return 0;
   244  }
   245  

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


.config.gz
Description: application/gzip


[PATCH/v5] bpf: add bpf_skb_adjust_room flag BPF_F_ADJ_ROOM_ENCAP_L2_ETH

2021-03-03 Thread Xuesen Huang
From: Xuesen Huang 

bpf_skb_adjust_room sets the inner_protocol as skb->protocol for packets
encapsulation. But that is not appropriate when pushing Ethernet header.

Add an option to further specify encap L2 type and set the inner_protocol
as ETH_P_TEB.

Suggested-by: Willem de Bruijn 
Signed-off-by: Xuesen Huang 
Signed-off-by: Zhiyong Cheng 
Signed-off-by: Li Wang 
---
 include/uapi/linux/bpf.h   |  5 +
 net/core/filter.c  | 11 ++-
 tools/include/uapi/linux/bpf.h |  5 +
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 77d7c1b..d791596 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1751,6 +1751,10 @@ struct bpf_stack_build_id {
  *   Use with ENCAP_L3/L4 flags to further specify the tunnel
  *   type; *len* is the length of the inner MAC header.
  *
+ * * **BPF_F_ADJ_ROOM_ENCAP_L2_ETH**:
+ *   Use with BPF_F_ADJ_ROOM_ENCAP_L2 flag to further specify the
+ *   L2 type as Ethernet.
+ *
  * A call to this helper is susceptible to change the underlying
  * packet buffer. Therefore, at load time, all checks on pointers
  * previously done by the verifier are invalidated and must be
@@ -4088,6 +4092,7 @@ enum {
BPF_F_ADJ_ROOM_ENCAP_L4_GRE = (1ULL << 3),
BPF_F_ADJ_ROOM_ENCAP_L4_UDP = (1ULL << 4),
BPF_F_ADJ_ROOM_NO_CSUM_RESET= (1ULL << 5),
+   BPF_F_ADJ_ROOM_ENCAP_L2_ETH = (1ULL << 6),
 };
 
 enum {
diff --git a/net/core/filter.c b/net/core/filter.c
index 255aeee..8d1fb61 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3412,6 +3412,7 @@ static u32 bpf_skb_net_base_len(const struct sk_buff *skb)
 BPF_F_ADJ_ROOM_ENCAP_L3_MASK | \
 BPF_F_ADJ_ROOM_ENCAP_L4_GRE | \
 BPF_F_ADJ_ROOM_ENCAP_L4_UDP | \
+BPF_F_ADJ_ROOM_ENCAP_L2_ETH | \
 BPF_F_ADJ_ROOM_ENCAP_L2( \
  BPF_ADJ_ROOM_ENCAP_L2_MASK))
 
@@ -3448,6 +3449,10 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32 
off, u32 len_diff,
flags & BPF_F_ADJ_ROOM_ENCAP_L4_UDP)
return -EINVAL;
 
+   if (flags & BPF_F_ADJ_ROOM_ENCAP_L2_ETH &&
+   inner_mac_len < ETH_HLEN)
+   return -EINVAL;
+
if (skb->encapsulation)
return -EALREADY;
 
@@ -3466,7 +3471,11 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32 
off, u32 len_diff,
skb->inner_mac_header = inner_net - inner_mac_len;
skb->inner_network_header = inner_net;
skb->inner_transport_header = inner_trans;
-   skb_set_inner_protocol(skb, skb->protocol);
+
+   if (flags & BPF_F_ADJ_ROOM_ENCAP_L2_ETH)
+   skb_set_inner_protocol(skb, htons(ETH_P_TEB));
+   else
+   skb_set_inner_protocol(skb, skb->protocol);
 
skb->encapsulation = 1;
skb_set_network_header(skb, mac_len);
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 77d7c1b..d791596 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -1751,6 +1751,10 @@ struct bpf_stack_build_id {
  *   Use with ENCAP_L3/L4 flags to further specify the tunnel
  *   type; *len* is the length of the inner MAC header.
  *
+ * * **BPF_F_ADJ_ROOM_ENCAP_L2_ETH**:
+ *   Use with BPF_F_ADJ_ROOM_ENCAP_L2 flag to further specify the
+ *   L2 type as Ethernet.
+ *
  * A call to this helper is susceptible to change the underlying
  * packet buffer. Therefore, at load time, all checks on pointers
  * previously done by the verifier are invalidated and must be
@@ -4088,6 +4092,7 @@ enum {
BPF_F_ADJ_ROOM_ENCAP_L4_GRE = (1ULL << 3),
BPF_F_ADJ_ROOM_ENCAP_L4_UDP = (1ULL << 4),
BPF_F_ADJ_ROOM_NO_CSUM_RESET= (1ULL << 5),
+   BPF_F_ADJ_ROOM_ENCAP_L2_ETH = (1ULL << 6),
 };
 
 enum {
-- 
1.8.3.1



[PATCH v10 3/7] crypto: move curve_id of ECDH from the key to algorithm name

2021-03-03 Thread Meng Yu
1. crypto and crypto/atmel-ecc:
   Move curve id of ECDH from the key into the algorithm name instead
   in crypto and atmel-ecc, so ECDH algorithm name change form 'ecdh'
   to 'ecdh-nist-pxxx', and we cannot use 'curve_id' in 'struct ecdh';
2. crypto/testmgr and net/bluetooth:
   Modify 'testmgr.c', 'testmgr.h' and 'net/bluetooth' to adapt
   the modification.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
Reported-by: kernel test robot 
---
 crypto/ecdh.c   | 72 +++--
 crypto/ecdh_helper.c|  4 +--
 crypto/testmgr.c| 13 ++--
 crypto/testmgr.h| 34 ++---
 drivers/crypto/atmel-ecc.c  | 28 +-
 include/crypto/ecdh.h   |  2 --
 net/bluetooth/ecdh_helper.c |  2 --
 net/bluetooth/selftest.c|  2 +-
 net/bluetooth/smp.c |  6 ++--
 9 files changed, 89 insertions(+), 74 deletions(-)

diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index 96f80c8..04a427b 100644
--- a/crypto/ecdh.c
+++ b/crypto/ecdh.c
@@ -23,33 +23,16 @@ static inline struct ecdh_ctx *ecdh_get_ctx(struct 
crypto_kpp *tfm)
return kpp_tfm_ctx(tfm);
 }
 
-static unsigned int ecdh_supported_curve(unsigned int curve_id)
-{
-   switch (curve_id) {
-   case ECC_CURVE_NIST_P192: return ECC_CURVE_NIST_P192_DIGITS;
-   case ECC_CURVE_NIST_P256: return ECC_CURVE_NIST_P256_DIGITS;
-   default: return 0;
-   }
-}
-
 static int ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
   unsigned int len)
 {
struct ecdh_ctx *ctx = ecdh_get_ctx(tfm);
struct ecdh params;
-   unsigned int ndigits;
 
if (crypto_ecdh_decode_key(buf, len, ¶ms) < 0 ||
-   params.key_size > sizeof(ctx->private_key))
+   params.key_size > sizeof(u64) * ctx->ndigits)
return -EINVAL;
 
-   ndigits = ecdh_supported_curve(params.curve_id);
-   if (!ndigits)
-   return -EINVAL;
-
-   ctx->curve_id = params.curve_id;
-   ctx->ndigits = ndigits;
-
if (!params.key || !params.key_size)
return ecc_gen_privkey(ctx->curve_id, ctx->ndigits,
   ctx->private_key);
@@ -140,13 +123,24 @@ static unsigned int ecdh_max_size(struct crypto_kpp *tfm)
return ctx->ndigits << (ECC_DIGITS_TO_BYTES_SHIFT + 1);
 }
 
-static struct kpp_alg ecdh = {
+static int ecdh_nist_p192_init_tfm(struct crypto_kpp *tfm)
+{
+   struct ecdh_ctx *ctx = ecdh_get_ctx(tfm);
+
+   ctx->curve_id = ECC_CURVE_NIST_P192;
+   ctx->ndigits = ECC_CURVE_NIST_P192_DIGITS;
+
+   return 0;
+}
+
+static struct kpp_alg ecdh_nist_p192 = {
.set_secret = ecdh_set_secret,
.generate_public_key = ecdh_compute_value,
.compute_shared_secret = ecdh_compute_value,
.max_size = ecdh_max_size,
+   .init = ecdh_nist_p192_init_tfm,
.base = {
-   .cra_name = "ecdh",
+   .cra_name = "ecdh-nist-p192",
.cra_driver_name = "ecdh-generic",
.cra_priority = 100,
.cra_module = THIS_MODULE,
@@ -154,14 +148,48 @@ static struct kpp_alg ecdh = {
},
 };
 
+static int ecdh_nist_p256_init_tfm(struct crypto_kpp *tfm)
+{
+   struct ecdh_ctx *ctx = ecdh_get_ctx(tfm);
+
+   ctx->curve_id = ECC_CURVE_NIST_P256;
+   ctx->ndigits = ECC_CURVE_NIST_P256_DIGITS;
+
+   return 0;
+}
+
+static struct kpp_alg ecdh_nist_p256 = {
+   .set_secret = ecdh_set_secret,
+   .generate_public_key = ecdh_compute_value,
+   .compute_shared_secret = ecdh_compute_value,
+   .max_size = ecdh_max_size,
+   .init = ecdh_nist_p256_init_tfm,
+   .base = {
+   .cra_name = "ecdh-nist-p256",
+   .cra_driver_name = "ecdh-generic",
+   .cra_priority = 100,
+   .cra_module = THIS_MODULE,
+   .cra_ctxsize = sizeof(struct ecdh_ctx),
+   },
+};
+
+static bool ecdh_nist_p192_registered;
+
 static int ecdh_init(void)
 {
-   return crypto_register_kpp(&ecdh);
+   int ret;
+
+   ret = crypto_register_kpp(&ecdh_nist_p192);
+   ecdh_nist_p192_registered = ret == 0;
+
+   return crypto_register_kpp(&ecdh_nist_p256);
 }
 
 static void ecdh_exit(void)
 {
-   crypto_unregister_kpp(&ecdh);
+   if (ecdh_nist_p192_registered)
+   crypto_unregister_kpp(&ecdh_nist_p192);
+   crypto_unregister_kpp(&ecdh_nist_p256);
 }
 
 subsys_initcall(ecdh_init);
diff --git a/crypto/ecdh_helper.c b/crypto/ecdh_helper.c
index fca63b5..f18f902 100644
--- a/crypto/ecdh_helper.c
+++ b/crypto/ecdh_helper.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 
-#define ECDH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 2 * 
sizeof(short))
+#define ECDH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + sizeof(short))
 
 static inline u8 *ecdh_pack_data(void *dst, const void *src, size_t sz)
 {
@@ -46,7 +46,6 @@ int crypto_ecdh_encode_key(char *buf, unsigned

[PATCH v10 4/7] crypto: and expose ecc curves

2021-03-03 Thread Meng Yu
Move 'ecc_get_curve' to 'include/crypto/ecc_curve.h', so everyone
in kernel tree can easily get ecc curve params;

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 crypto/ecc.c   |  5 -
 crypto/ecc.h   | 37 ++--
 include/crypto/ecc_curve.h | 53 ++
 3 files changed, 59 insertions(+), 36 deletions(-)
 create mode 100644 include/crypto/ecc_curve.h

diff --git a/crypto/ecc.c b/crypto/ecc.c
index c80aa25..4b55ad0 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -24,6 +24,7 @@
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -42,7 +43,8 @@ typedef struct {
u64 m_high;
 } uint128_t;
 
-static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
+
+const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
 {
switch (curve_id) {
/* In FIPS mode only allow P256 and higher */
@@ -54,6 +56,7 @@ static inline const struct ecc_curve *ecc_get_curve(unsigned 
int curve_id)
return NULL;
}
 }
+EXPORT_SYMBOL(ecc_get_curve);
 
 static u64 *ecc_alloc_digits_space(unsigned int ndigits)
 {
diff --git a/crypto/ecc.h b/crypto/ecc.h
index d4e546b..38a81d4 100644
--- a/crypto/ecc.h
+++ b/crypto/ecc.h
@@ -26,6 +26,8 @@
 #ifndef _CRYPTO_ECC_H
 #define _CRYPTO_ECC_H
 
+#include 
+
 /* One digit is u64 qword. */
 #define ECC_CURVE_NIST_P192_DIGITS  3
 #define ECC_CURVE_NIST_P256_DIGITS  4
@@ -33,44 +35,9 @@
 
 #define ECC_DIGITS_TO_BYTES_SHIFT 3
 
-/**
- * struct ecc_point - elliptic curve point in affine coordinates
- *
- * @x: X coordinate in vli form.
- * @y: Y coordinate in vli form.
- * @ndigits:   Length of vlis in u64 qwords.
- */
-struct ecc_point {
-   u64 *x;
-   u64 *y;
-   u8 ndigits;
-};
-
 #define ECC_POINT_INIT(x, y, ndigits)  (struct ecc_point) { x, y, ndigits }
 
 /**
- * struct ecc_curve - definition of elliptic curve
- *
- * @name:  Short name of the curve.
- * @g: Generator point of the curve.
- * @p: Prime number, if Barrett's reduction is used for this curve
- * pre-calculated value 'mu' is appended to the @p after ndigits.
- * Use of Barrett's reduction is heuristically determined in
- * vli_mmod_fast().
- * @n: Order of the curve group.
- * @a: Curve parameter a.
- * @b: Curve parameter b.
- */
-struct ecc_curve {
-   char *name;
-   struct ecc_point g;
-   u64 *p;
-   u64 *n;
-   u64 *a;
-   u64 *b;
-};
-
-/**
  * ecc_is_key_valid() - Validate a given ECDH private key
  *
  * @curve_id:  id representing the curve to use
diff --git a/include/crypto/ecc_curve.h b/include/crypto/ecc_curve.h
new file mode 100644
index 000..19a35da
--- /dev/null
+++ b/include/crypto/ecc_curve.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2021 HiSilicon */
+
+#ifndef _CRYTO_ECC_CURVE_H
+#define _CRYTO_ECC_CURVE_H
+
+#include 
+
+/**
+ * struct ecc_point - elliptic curve point in affine coordinates
+ *
+ * @x: X coordinate in vli form.
+ * @y: Y coordinate in vli form.
+ * @ndigits:   Length of vlis in u64 qwords.
+ */
+struct ecc_point {
+   u64 *x;
+   u64 *y;
+   u8 ndigits;
+};
+
+/**
+ * struct ecc_curve - definition of elliptic curve
+ *
+ * @name:  Short name of the curve.
+ * @g: Generator point of the curve.
+ * @p: Prime number, if Barrett's reduction is used for this curve
+ * pre-calculated value 'mu' is appended to the @p after ndigits.
+ * Use of Barrett's reduction is heuristically determined in
+ * vli_mmod_fast().
+ * @n: Order of the curve group.
+ * @a: Curve parameter a.
+ * @b: Curve parameter b.
+ */
+struct ecc_curve {
+   char *name;
+   struct ecc_point g;
+   u64 *p;
+   u64 *n;
+   u64 *a;
+   u64 *b;
+};
+
+/**
+ * ecc_get_curve() - get elliptic curve;
+ * @curve_id:   Curves IDs:
+ *  defined in 'include/crypto/ecdh.h';
+ *
+ * Returns curve if get curve succssful, NULL otherwise
+ */
+const struct ecc_curve *ecc_get_curve(unsigned int curve_id);
+
+#endif
-- 
2.8.1



[PATCH v10 2/7] crypto: hisilicon/hpre - add algorithm type

2021-03-03 Thread Meng Yu
Algorithm type is brought in to get hardware HPRE queue
to support different algorithms.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 drivers/crypto/hisilicon/hpre/hpre.h| 10 +-
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 12 ++--
 drivers/crypto/hisilicon/hpre/hpre_main.c   | 11 +--
 3 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index cc50f23..02193e1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -10,6 +10,14 @@
 #define HPRE_PF_DEF_Q_NUM  64
 #define HPRE_PF_DEF_Q_BASE 0
 
+/*
+ * type used in qm sqc DW6.
+ * 0 - Algorithm which has been supported in V2, like RSA, DH and so on;
+ * 1 - ECC algorithm in V3.
+ */
+#define HPRE_V2_ALG_TYPE   0
+#define HPRE_V3_ECC_ALG_TYPE   1
+
 enum {
HPRE_CLUSTER0,
HPRE_CLUSTER1,
@@ -92,7 +100,7 @@ struct hpre_sqe {
__le32 rsvd1[_HPRE_SQE_ALIGN_EXT];
 };
 
-struct hisi_qp *hpre_create_qp(void);
+struct hisi_qp *hpre_create_qp(u8 type);
 int hpre_algs_register(struct hisi_qm *qm);
 void hpre_algs_unregister(struct hisi_qm *qm);
 
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index d89b2f5..712bea9 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -152,12 +152,12 @@ static void hpre_rm_req_from_ctx(struct hpre_asym_request 
*hpre_req)
}
 }
 
-static struct hisi_qp *hpre_get_qp_and_start(void)
+static struct hisi_qp *hpre_get_qp_and_start(u8 type)
 {
struct hisi_qp *qp;
int ret;
 
-   qp = hpre_create_qp();
+   qp = hpre_create_qp(type);
if (!qp) {
pr_err("Can not create hpre qp!\n");
return ERR_PTR(-ENODEV);
@@ -422,11 +422,11 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
req->cb(ctx, resp);
 }
 
-static int hpre_ctx_init(struct hpre_ctx *ctx)
+static int hpre_ctx_init(struct hpre_ctx *ctx, u8 type)
 {
struct hisi_qp *qp;
 
-   qp = hpre_get_qp_and_start();
+   qp = hpre_get_qp_and_start(type);
if (IS_ERR(qp))
return PTR_ERR(qp);
 
@@ -674,7 +674,7 @@ static int hpre_dh_init_tfm(struct crypto_kpp *tfm)
 {
struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
 
-   return hpre_ctx_init(ctx);
+   return hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
 }
 
 static void hpre_dh_exit_tfm(struct crypto_kpp *tfm)
@@ -1100,7 +1100,7 @@ static int hpre_rsa_init_tfm(struct crypto_akcipher *tfm)
return PTR_ERR(ctx->rsa.soft_tfm);
}
 
-   ret = hpre_ctx_init(ctx);
+   ret = hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
if (ret)
crypto_free_akcipher(ctx->rsa.soft_tfm);
 
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c 
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index e7a2c70..76f0a87 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -226,13 +226,20 @@ static u32 vfs_num;
 module_param_cb(vfs_num, &vfs_num_ops, &vfs_num, 0444);
 MODULE_PARM_DESC(vfs_num, "Number of VFs to enable(1-63), 0(default)");
 
-struct hisi_qp *hpre_create_qp(void)
+struct hisi_qp *hpre_create_qp(u8 type)
 {
int node = cpu_to_node(smp_processor_id());
struct hisi_qp *qp = NULL;
int ret;
 
-   ret = hisi_qm_alloc_qps_node(&hpre_devices, 1, 0, node, &qp);
+   if (type != HPRE_V2_ALG_TYPE && type != HPRE_V3_ECC_ALG_TYPE)
+   return NULL;
+
+   /*
+* type: 0 - RSA/DH. algorithm supported in V2,
+*   1 - ECC algorithm in V3.
+*/
+   ret = hisi_qm_alloc_qps_node(&hpre_devices, 1, type, node, &qp);
if (!ret)
return qp;
 
-- 
2.8.1



[PATCH v10 5/7] crypto: hisilicon/hpre - add 'ECDH' algorithm

2021-03-03 Thread Meng Yu
1. Enable 'ECDH' algorithm in Kunpeng 930;
2. HPRE ECDH Support: ecdh-nist-p192, ecdh-nist-p256.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 drivers/crypto/hisilicon/hpre/hpre.h|   2 +-
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 515 +++-
 drivers/crypto/hisilicon/hpre/hpre_main.c   |   1 +
 3 files changed, 513 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index 02193e1..50e6b2e 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -83,6 +83,7 @@ enum hpre_alg_type {
HPRE_ALG_KG_CRT = 0x3,
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
+   HPRE_ALG_ECC_MUL = 0xD,
 };
 
 struct hpre_sqe {
@@ -104,5 +105,4 @@ struct hisi_qp *hpre_create_qp(u8 type);
 int hpre_algs_register(struct hisi_qm *qm);
 void hpre_algs_unregister(struct hisi_qm *qm);
 
-
 #endif
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 712bea9..a6010b1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -2,6 +2,8 @@
 /* Copyright (c) 2019 HiSilicon Limited. */
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -36,6 +38,13 @@ struct hpre_ctx;
 #define HPRE_DFX_SEC_TO_US 100
 #define HPRE_DFX_US_TO_NS  1000
 
+/* size in bytes of the n prime */
+#define HPRE_ECC_NIST_P192_N_SIZE  24
+#define HPRE_ECC_NIST_P256_N_SIZE  32
+
+/* size in bytes */
+#define HPRE_ECC_HW256_KSZ_B   32
+
 typedef void (*hpre_cb)(struct hpre_ctx *ctx, void *sqe);
 
 struct hpre_rsa_ctx {
@@ -61,14 +70,25 @@ struct hpre_dh_ctx {
 * else if base if the counterpart public key we
 * compute the shared secret
 *  ZZ = yb^xa mod p; [RFC2631 sec 2.1.1]
+* low address: d--->n, please refer to Hisilicon HPRE UM
 */
-   char *xa_p; /* low address: d--->n, please refer to Hisilicon HPRE UM */
+   char *xa_p;
dma_addr_t dma_xa_p;
 
char *g; /* m */
dma_addr_t dma_g;
 };
 
+struct hpre_ecdh_ctx {
+   /* low address: p->a->k->b */
+   unsigned char *p;
+   dma_addr_t dma_p;
+
+   /* low address: x->y */
+   unsigned char *g;
+   dma_addr_t dma_g;
+};
+
 struct hpre_ctx {
struct hisi_qp *qp;
struct hpre_asym_request **req_list;
@@ -80,7 +100,10 @@ struct hpre_ctx {
union {
struct hpre_rsa_ctx rsa;
struct hpre_dh_ctx dh;
+   struct hpre_ecdh_ctx ecdh;
};
+   /* for ecc algorithms */
+   unsigned int curve_id;
 };
 
 struct hpre_asym_request {
@@ -91,6 +114,7 @@ struct hpre_asym_request {
union {
struct akcipher_request *rsa;
struct kpp_request *dh;
+   struct kpp_request *ecdh;
} areq;
int err;
int req_id;
@@ -1115,6 +1139,416 @@ static void hpre_rsa_exit_tfm(struct crypto_akcipher 
*tfm)
crypto_free_akcipher(ctx->rsa.soft_tfm);
 }
 
+static void hpre_key_to_big_end(u8 *data, int len)
+{
+   int i, j;
+   u8 tmp;
+
+   for (i = 0; i < len / 2; i++) {
+   j = len - i - 1;
+   tmp = data[j];
+   data[j] = data[i];
+   data[i] = tmp;
+   }
+}
+
+static void hpre_ecc_clear_ctx(struct hpre_ctx *ctx, bool is_clear_all,
+  bool is_ecdh)
+{
+   struct device *dev = HPRE_DEV(ctx);
+   unsigned int sz = ctx->key_sz;
+   unsigned int shift = sz << 1;
+
+   if (is_clear_all)
+   hisi_qm_stop_qp(ctx->qp);
+
+   if (is_ecdh && ctx->ecdh.p) {
+   /* ecdh: p->a->k->b */
+   memzero_explicit(ctx->ecdh.p + shift, sz);
+   dma_free_coherent(dev, sz << 3, ctx->ecdh.p, ctx->ecdh.dma_p);
+   ctx->ecdh.p = NULL;
+   }
+
+   hpre_ctx_clear(ctx, is_clear_all);
+}
+
+static unsigned int hpre_ecdh_supported_curve(unsigned short id)
+{
+   switch (id) {
+   case ECC_CURVE_NIST_P192:
+   case ECC_CURVE_NIST_P256:
+   return HPRE_ECC_HW256_KSZ_B;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
+static void fill_curve_param(void *addr, u64 *param, unsigned int cur_sz, u8 
ndigits)
+{
+   unsigned int sz = cur_sz - (ndigits - 1) * sizeof(u64);
+   u8 i = 0;
+
+   while (i < ndigits - 1) {
+   memcpy(addr + sizeof(u64) * i, ¶m[i], sizeof(u64));
+   i++;
+   }
+
+   memcpy(addr + sizeof(u64) * i, ¶m[ndigits - 1], sz);
+   hpre_key_to_big_end((u8 *)addr, cur_sz);
+}
+
+static int hpre_ecdh_fill_curve(struct hpre_ctx *ctx, struct ecdh *params,
+   unsigned int cur_sz)
+{
+   unsigned int shifta = ctx->key_sz << 1;
+   unsigned int shiftb = ctx->key_sz << 2;
+   void *p = ctx->ecdh.p + ctx->key_sz - c

[PATCH v10 7/7] crypto: hisilicon/hpre - add 'CURVE25519' algorithm

2021-03-03 Thread Meng Yu
Enable 'CURVE25519' algorithm in Kunpeng 930.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
Reported-by: kernel test robot 
---
 drivers/crypto/hisilicon/Kconfig|   1 +
 drivers/crypto/hisilicon/hpre/hpre.h|   2 +
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 366 +++-
 3 files changed, 361 insertions(+), 8 deletions(-)

diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
index 8431926..c45adb1 100644
--- a/drivers/crypto/hisilicon/Kconfig
+++ b/drivers/crypto/hisilicon/Kconfig
@@ -65,6 +65,7 @@ config CRYPTO_DEV_HISI_HPRE
depends on UACCE || UACCE=n
depends on ARM64 || (COMPILE_TEST && 64BIT)
depends on ACPI
+   select CRYPTO_LIB_CURVE25519_GENERIC
select CRYPTO_DEV_HISI_QM
select CRYPTO_DH
select CRYPTO_RSA
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index 50e6b2e..92892e3 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -84,6 +84,8 @@ enum hpre_alg_type {
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
HPRE_ALG_ECC_MUL = 0xD,
+   /* shared by x25519 and x448, but x448 is not supported now */
+   HPRE_ALG_CURVE25519_MUL = 0x10,
 };
 
 struct hpre_sqe {
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index a6010b1..53068d2 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (c) 2019 HiSilicon Limited. */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -89,6 +90,16 @@ struct hpre_ecdh_ctx {
dma_addr_t dma_g;
 };
 
+struct hpre_curve25519_ctx {
+   /* low address: p->a->k */
+   unsigned char *p;
+   dma_addr_t dma_p;
+
+   /* gx coordinate */
+   unsigned char *g;
+   dma_addr_t dma_g;
+};
+
 struct hpre_ctx {
struct hisi_qp *qp;
struct hpre_asym_request **req_list;
@@ -101,6 +112,7 @@ struct hpre_ctx {
struct hpre_rsa_ctx rsa;
struct hpre_dh_ctx dh;
struct hpre_ecdh_ctx ecdh;
+   struct hpre_curve25519_ctx curve25519;
};
/* for ecc algorithms */
unsigned int curve_id;
@@ -115,6 +127,7 @@ struct hpre_asym_request {
struct akcipher_request *rsa;
struct kpp_request *dh;
struct kpp_request *ecdh;
+   struct kpp_request *curve25519;
} areq;
int err;
int req_id;
@@ -437,7 +450,6 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
struct hpre_sqe *sqe = resp;
struct hpre_asym_request *req = ctx->req_list[le16_to_cpu(sqe->tag)];
 
-
if (unlikely(!req)) {
atomic64_inc(&dfx[HPRE_INVALID_REQ_CNT].value);
return;
@@ -1167,6 +1179,12 @@ static void hpre_ecc_clear_ctx(struct hpre_ctx *ctx, 
bool is_clear_all,
memzero_explicit(ctx->ecdh.p + shift, sz);
dma_free_coherent(dev, sz << 3, ctx->ecdh.p, ctx->ecdh.dma_p);
ctx->ecdh.p = NULL;
+   } else if (!is_ecdh && ctx->curve25519.p) {
+   /* curve25519: p->a->k */
+   memzero_explicit(ctx->curve25519.p + shift, sz);
+   dma_free_coherent(dev, sz << 2, ctx->curve25519.p,
+ ctx->curve25519.dma_p);
+   ctx->curve25519.p = NULL;
}
 
hpre_ctx_clear(ctx, is_clear_all);
@@ -1549,6 +1567,312 @@ static void hpre_ecdh_exit_tfm(struct crypto_kpp *tfm)
hpre_ecc_clear_ctx(ctx, true, true);
 }
 
+static void hpre_curve25519_fill_curve(struct hpre_ctx *ctx, const void *buf,
+  unsigned int len)
+{
+   u8 secret[CURVE25519_KEY_SIZE] = { 0 };
+   unsigned int sz = ctx->key_sz;
+   const struct ecc_curve *curve;
+   unsigned int shift = sz << 1;
+   void *p;
+
+   /*
+* The key from 'buf' is in little-endian, we should preprocess it as
+* the description in rfc7748: "k[0] &= 248, k[31] &= 127, k[31] |= 64",
+* then convert it to big endian. Only in this way, the result can be
+* the same as the software curve-25519 that exists in crypto.
+*/
+   memcpy(secret, buf, len);
+   curve25519_clamp_secret(secret);
+   hpre_key_to_big_end(secret, CURVE25519_KEY_SIZE);
+
+   p = ctx->curve25519.p + sz - len;
+
+   curve = ecc_get_curve25519();
+
+   /* fill curve parameters */
+   fill_curve_param(p, curve->p, len, curve->g.ndigits);
+   fill_curve_param(p + sz, curve->a, len, curve->g.ndigits);
+   memcpy(p + shift, secret, len);
+   fill_curve_param(p + shift + sz, curve->g.x, len, curve->g.ndigits);
+   memzero_explicit(secret, CURVE25519_KEY_SIZE);
+}
+
+static int hpre_curve25519_set_param(struct hpre_c

[PATCH v10 6/7] crypto: add curve25519 params and expose them

2021-03-03 Thread Meng Yu
1. Add curve 25519 parameters in 'crypto/ecc_curve_defs.h';
2. Add curve25519 interface 'ecc_get_curve25519_param' in
   'include/crypto/ecc_curve.h', to make its parameters be
   exposed to everyone in kernel tree.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 crypto/ecc.c   |  6 ++
 crypto/ecc_curve_defs.h| 17 +
 include/crypto/ecc_curve.h |  7 +++
 3 files changed, 30 insertions(+)

diff --git a/crypto/ecc.c b/crypto/ecc.c
index 4b55ad0..0798a18 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -43,6 +43,12 @@ typedef struct {
u64 m_high;
 } uint128_t;
 
+/* Returns curv25519 curve param */
+const struct ecc_curve *ecc_get_curve25519(void)
+{
+   return &ecc_25519;
+}
+EXPORT_SYMBOL(ecc_get_curve25519);
 
 const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
 {
diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h
index 69be6c7..d7769cc 100644
--- a/crypto/ecc_curve_defs.h
+++ b/crypto/ecc_curve_defs.h
@@ -54,4 +54,21 @@ static struct ecc_curve nist_p256 = {
.b = nist_p256_b
 };
 
+/* curve25519 */
+static u64 curve25519_g_x[] = { 0x0009, 0x,
+   0x, 0x };
+static u64 curve25519_p[] = { 0xffed, 0x,
+   0x, 0x7fff };
+static u64 curve25519_a[] = { 0x0001DB41, 0x,
+   0x, 0x };
+static const struct ecc_curve ecc_25519 = {
+   .name = "curve25519",
+   .g = {
+   .x = curve25519_g_x,
+   .ndigits = 4,
+   },
+   .p = curve25519_p,
+   .a = curve25519_a,
+};
+
 #endif
diff --git a/include/crypto/ecc_curve.h b/include/crypto/ecc_curve.h
index 19a35da..7096478 100644
--- a/include/crypto/ecc_curve.h
+++ b/include/crypto/ecc_curve.h
@@ -50,4 +50,11 @@ struct ecc_curve {
  */
 const struct ecc_curve *ecc_get_curve(unsigned int curve_id);
 
+/**
+ * ecc_get_curve25519() - get curve25519 curve;
+ *
+ * Returns curve25519
+ */
+const struct ecc_curve *ecc_get_curve25519(void);
+
 #endif
-- 
2.8.1



[PATCH v10 0/7] add ECDH and CURVE25519 algorithms support for Kunpeng 930

2021-03-03 Thread Meng Yu
1. Move  curve ID from the key into the algorithm name (like 'ecdh-nist-pxxx'
   so we get its tfm like 'crypto_alloc_kpp("ecdh-nist-p256", 0, 0)'),
   in 'crypto/ecc.c' (has been verified by testmgr) and 'crypto/atmel-ecc.c'
   (only compiled, not do test), and modify 'testmgr.c' and 
'net/bluetooth/smp.c'
   (only compiled, not do test) to adapt the modification;

2. Add new file 'include/crypto/ecc_curve.h', and move 'struct ecc_point' and
   'struct ecc_curve' definitions to it, also add new APIs 'ecc_get_curveXXX'
   into it, with these APIs, users in kernel tree can get ECDH and
   curve25519 parameters;

3. Add ECDH and CURVE25519 algorithms support for Kunpeng 930.

v9->v10:
- patch #3: delete 'atmel_ecdh_supported_curve' and 'n_sz' in atmel-ecc.c

v8->v9:
- patch #3: squash patches 3-5 in v8 into one in v9
- patch #4: delete ECDH curve parameters: P224, P384 and P521
- patch #5: delete ecdh-nist-p224, ecdh-nist-p384 and ecdh-nist-p521 support in 
HPRE

v7->v8:
- patch #3 and #5: move the curve ID from the key into the algorithm name 
instead

v6->v7:
- patch #4: add function interface to expose elliptic curve parameters
- patch #4: eliminate warning by 'kernel test robot'
- patch #5: add function interface to expose curve25519 parameters

v5->v6:
- patch #1: add a new patch (the first patch), which is the "depend on" patch 
before

v4->v5:
- patch #4: delete P-128 and P-320 curve, as the few using case in the kernel

v3 -> v4:
- patch #3: add new, and move ecc_curve params to "include/crypto"

v2 -> v3:
- patch #5: fix sparse warnings
- patch #5: add 'CRYPTO_LIB_CURVE25519_GENERIC' in 'Kconfig'

v1 -> v2:
- patch #5: delete `curve25519_null_point'


Meng Yu (7):
  crypto: hisilicon/hpre - add version adapt to new algorithms
  crypto: hisilicon/hpre - add algorithm type
  crypto: move curve_id of ECDH from the key to algorithm name
  crypto: and expose ecc curves
  crypto: hisilicon/hpre - add 'ECDH' algorithm
  crypto: add curve25519 params and expose them
  crypto: hisilicon/hpre - add 'CURVE25519' algorithm

 crypto/ecc.c|  11 +-
 crypto/ecc.h|  37 +-
 crypto/ecc_curve_defs.h |  17 +
 crypto/ecdh.c   |  72 ++-
 crypto/ecdh_helper.c|   4 +-
 crypto/testmgr.c|  13 +-
 crypto/testmgr.h|  34 +-
 drivers/crypto/atmel-ecc.c  |  28 +-
 drivers/crypto/hisilicon/Kconfig|   1 +
 drivers/crypto/hisilicon/hpre/hpre.h|  17 +-
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 881 +++-
 drivers/crypto/hisilicon/hpre/hpre_main.c   |  12 +-
 drivers/crypto/hisilicon/qm.c   |   4 +-
 drivers/crypto/hisilicon/qm.h   |   4 +-
 drivers/crypto/hisilicon/sec2/sec.h |   4 +-
 drivers/crypto/hisilicon/sec2/sec_crypto.c  |   4 +-
 drivers/crypto/hisilicon/sec2/sec_crypto.h  |   4 +-
 drivers/crypto/hisilicon/zip/zip.h  |   4 +-
 drivers/crypto/hisilicon/zip/zip_crypto.c   |   4 +-
 include/crypto/ecc_curve.h  |  60 ++
 include/crypto/ecdh.h   |   2 -
 net/bluetooth/ecdh_helper.c |   2 -
 net/bluetooth/selftest.c|   2 +-
 net/bluetooth/smp.c |   6 +-
 24 files changed, 1086 insertions(+), 141 deletions(-)
 create mode 100644 include/crypto/ecc_curve.h

-- 
2.8.1



[PATCH v10 1/7] crypto: hisilicon/hpre - add version adapt to new algorithms

2021-03-03 Thread Meng Yu
A new generation of accelerator Kunpeng930 has appeared, and the
corresponding driver needs to be updated to support some new
algorithms of Kunpeng930. To be compatible with Kunpeng920, we
add parameter 'struct hisi_qm *qm' to sec_algs_(un)register to
identify the chip's version.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
Reviewed-by: Longfang Liu 
---
 drivers/crypto/hisilicon/hpre/hpre.h| 5 +++--
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 4 ++--
 drivers/crypto/hisilicon/qm.c   | 4 ++--
 drivers/crypto/hisilicon/qm.h   | 4 ++--
 drivers/crypto/hisilicon/sec2/sec.h | 4 ++--
 drivers/crypto/hisilicon/sec2/sec_crypto.c  | 4 ++--
 drivers/crypto/hisilicon/sec2/sec_crypto.h  | 4 ++--
 drivers/crypto/hisilicon/zip/zip.h  | 4 ++--
 drivers/crypto/hisilicon/zip/zip_crypto.c   | 4 ++--
 9 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index 181c109..cc50f23 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -93,7 +93,8 @@ struct hpre_sqe {
 };
 
 struct hisi_qp *hpre_create_qp(void);
-int hpre_algs_register(void);
-void hpre_algs_unregister(void);
+int hpre_algs_register(struct hisi_qm *qm);
+void hpre_algs_unregister(struct hisi_qm *qm);
+
 
 #endif
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index a87f990..d89b2f5 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1154,7 +1154,7 @@ static struct kpp_alg dh = {
 };
 #endif
 
-int hpre_algs_register(void)
+int hpre_algs_register(struct hisi_qm *qm)
 {
int ret;
 
@@ -1171,7 +1171,7 @@ int hpre_algs_register(void)
return ret;
 }
 
-void hpre_algs_unregister(void)
+void hpre_algs_unregister(struct hisi_qm *qm)
 {
crypto_unregister_akcipher(&rsa);
 #ifdef CONFIG_CRYPTO_DH
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index 13cb421..bc23174 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -4084,7 +4084,7 @@ int hisi_qm_alg_register(struct hisi_qm *qm, struct 
hisi_qm_list *qm_list)
mutex_unlock(&qm_list->lock);
 
if (flag) {
-   ret = qm_list->register_to_crypto();
+   ret = qm_list->register_to_crypto(qm);
if (ret) {
mutex_lock(&qm_list->lock);
list_del(&qm->list);
@@ -4115,7 +4115,7 @@ void hisi_qm_alg_unregister(struct hisi_qm *qm, struct 
hisi_qm_list *qm_list)
mutex_unlock(&qm_list->lock);
 
if (list_empty(&qm_list->list))
-   qm_list->unregister_from_crypto();
+   qm_list->unregister_from_crypto(qm);
 }
 EXPORT_SYMBOL_GPL(hisi_qm_alg_unregister);
 
diff --git a/drivers/crypto/hisilicon/qm.h b/drivers/crypto/hisilicon/qm.h
index 54967c6..f91110f 100644
--- a/drivers/crypto/hisilicon/qm.h
+++ b/drivers/crypto/hisilicon/qm.h
@@ -199,8 +199,8 @@ struct hisi_qm_err_ini {
 struct hisi_qm_list {
struct mutex lock;
struct list_head list;
-   int (*register_to_crypto)(void);
-   void (*unregister_from_crypto)(void);
+   int (*register_to_crypto)(struct hisi_qm *qm);
+   void (*unregister_from_crypto)(struct hisi_qm *qm);
 };
 
 struct hisi_qm {
diff --git a/drivers/crypto/hisilicon/sec2/sec.h 
b/drivers/crypto/hisilicon/sec2/sec.h
index 0849191..17ddb20 100644
--- a/drivers/crypto/hisilicon/sec2/sec.h
+++ b/drivers/crypto/hisilicon/sec2/sec.h
@@ -183,6 +183,6 @@ struct sec_dev {
 
 void sec_destroy_qps(struct hisi_qp **qps, int qp_num);
 struct hisi_qp **sec_create_qps(void);
-int sec_register_to_crypto(void);
-void sec_unregister_from_crypto(void);
+int sec_register_to_crypto(struct hisi_qm *qm);
+void sec_unregister_from_crypto(struct hisi_qm *qm);
 #endif
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c 
b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 2eaa516..f835514 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -1634,7 +1634,7 @@ static struct aead_alg sec_aeads[] = {
 AES_BLOCK_SIZE, AES_BLOCK_SIZE, SHA512_DIGEST_SIZE),
 };
 
-int sec_register_to_crypto(void)
+int sec_register_to_crypto(struct hisi_qm *qm)
 {
int ret;
 
@@ -1651,7 +1651,7 @@ int sec_register_to_crypto(void)
return ret;
 }
 
-void sec_unregister_from_crypto(void)
+void sec_unregister_from_crypto(struct hisi_qm *qm)
 {
crypto_unregister_skciphers(sec_skciphers,
ARRAY_SIZE(sec_skciphers));
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.h 
b/drivers/crypto/hisilicon/sec2/sec_crypto.h
index b2786e1..0e933e7 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.h
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.h
@@ -211,6 +211,6 @@ struct sec_sqe {
struct sec_sqe_type2 type2;

[PATCH -next] mtd: parsers: ofpart: make symbol 'bcm4908_partitions_quirks' static

2021-03-03 Thread 'Wei Yongjun
From: Wei Yongjun 

The sparse tool complains as follows:

drivers/mtd/parsers/ofpart_core.c:25:32: warning:
 symbol 'bcm4908_partitions_quirks' was not declared. Should it be static?

This symbol is not used outside of ofpart_core.c, so this
commit marks it static.

Fixes: 457da931b608 ("mtd: parsers: ofpart: support BCM4908 fixed partitions")
Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
---
 drivers/mtd/parsers/ofpart_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/parsers/ofpart_core.c 
b/drivers/mtd/parsers/ofpart_core.c
index 258c06a42283..e9cb9ca28813 100644
--- a/drivers/mtd/parsers/ofpart_core.c
+++ b/drivers/mtd/parsers/ofpart_core.c
@@ -22,7 +22,7 @@ struct fixed_partitions_quirks {
int (*post_parse)(struct mtd_info *mtd, struct mtd_partition *parts, 
int nr_parts);
 };
 
-struct fixed_partitions_quirks bcm4908_partitions_quirks = {
+static struct fixed_partitions_quirks bcm4908_partitions_quirks = {
.post_parse = bcm4908_partitions_post_parse,
 };
 



Re: [PATCH 1/4] userfaultfd.2: Add UFFD_FEATURE_THREAD_ID docs

2021-03-03 Thread Mike Rapoport
On Wed, Mar 03, 2021 at 08:59:44PM -0500, Peter Xu wrote:
> UFFD_FEATURE_THREAD_ID is supported since Linux 4.14.
> 
> Signed-off-by: Peter Xu 
> ---
>  man2/userfaultfd.2 | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
> index e7dc9f813..2d14effc6 100644
> --- a/man2/userfaultfd.2
> +++ b/man2/userfaultfd.2
> @@ -77,6 +77,12 @@ When the last file descriptor referring to a userfaultfd 
> object is closed,
>  all memory ranges that were registered with the object are unregistered
>  and unread events are flushed.
>  .\"
> +.PP
> +Since Linux 4.14, userfaultfd page fault message can selectively embed fault

  Maybe faulting? ^

> +thread ID information into the fault message.  One needs to enable this 
> feature
> +explicitly using the
> +.BR UFFD_FEATURE_THREAD_ID
> +feature bit when initializing the userfaultfd context, otherwise disabled.

 "... otherwise thread ID reporting is disabled" ^

>  .SS Usage
>  The userfaultfd mechanism is designed to allow a thread in a multithreaded
>  program to perform user-space paging for the other threads in the process.
> @@ -229,6 +235,9 @@ struct uffd_msg {
>  struct {
>  __u64 flags;/* Flags describing fault */
>  __u64 address;  /* Faulting address */
> +union {
> +__u32 ptid; /* Thread ID of the fault */
> +} feat;
>  } pagefault;
> 
>  struct {/* Since Linux 4.11 */
> @@ -358,6 +367,9 @@ otherwise it is a read fault.
>  .\" UFFD_PAGEFAULT_FLAG_WP is not yet supported.
>  .RE
>  .TP
> +.I pagefault.feat.pid
> +The thread ID that triggered the page fault.
> +.TP
>  .I fork.ufd
>  The file descriptor associated with the userfault object
>  created for the child created by
> -- 
> 2.26.2
> 

-- 
Sincerely yours,
Mike.


Re: [PATCH] crypto: sha: remove unneeded semicolon

2021-03-03 Thread Herbert Xu
On Mon, Feb 08, 2021 at 05:10:38PM +0800, Yang Li wrote:
> Eliminate the following coccicheck warning:
> ./arch/powerpc/crypto/sha1-spe-glue.c:110:2-3: Unneeded semicolon
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 
> ---
>  arch/powerpc/crypto/sha1-spe-glue.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: XDP socket rings, and LKMM litmus tests

2021-03-03 Thread Boqun Feng
On Wed, Mar 03, 2021 at 10:13:22PM -0500, Alan Stern wrote:
> On Thu, Mar 04, 2021 at 09:26:31AM +0800, Boqun Feng wrote:
> > On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
> 
> > > Which brings us back to the case of the
> > > 
> > >   dep ; rfi
> > > 
> > > dependency relation, where the accesses in the middle are plain and 
> > > non-racy.  Should the LKMM be changed to allow this?
> > > 
> > 
> > For this particular question, do we need to consider code as the follow?
> > 
> > r1 = READ_ONCE(x);  // f
> > if (r == 1) {
> > local_v = &y; // g
> > do_something_a();
> > }
> > else {
> > local_v = &y;
> > do_something_b();
> > }
> > 
> > r2 = READ_ONCE(*local_v); // e
> > 
> > , do we have the guarantee that the first READ_ONCE() happens before the
> > second one? Can compiler optimize the code as:
> > 
> > r2 = READ_ONCE(y);
> > r1 = READ_ONCE(x);
> 
> Well, it can't do that because the compiler isn't allowed to reorder
> volatile accesses (which includes READ_ONCE).  But the compiler could
> do:
> 
>   r1 = READ_ONCE(x);
>   r2 = READ_ONCE(y);
> 
> > if (r == 1) {
> > do_something_a();
> > }
> > else {
> > do_something_b();
> > }
> > 
> > ? Although we have:
> > 
> > f ->dep g ->rfi ->addr e
> 
> This would be an example of a problem Paul has described on several
> occasions, where both arms of an "if" statement store the same value
> (in this case to local_v).  This problem arises even when local
> variables are not involved.  For example:
> 
>   if (READ_ONCE(x) == 0) {
>   WRITE_ONCE(y, 1);
>   do_a();
>   } else {
>   WRITE_ONCE(y, 1);
>   do_b();
>   }
> 
> The compiler can change this to:
> 
>   r = READ_ONCE(x);
>   WRITE_ONCE(y, 1);
>   if (r == 0)
>   do_a();
>   else
>   do_b();
> 
> thus allowing the marked accesses to be reordered by the CPU and
> breaking the apparent control dependency.
> 
> So the answer to your question is: No, we don't have this guarantee,
> but the reason is because of doing the same store in both arms, not
> because of the use of local variables.
> 

Right, I was thinking about something unrelated.. but how about the
following case:

local_v = &y;
r1 = READ_ONCE(*x); // f

if (r1 == 1) {
local_v = &y; // e
} else {
local_v = &z; // d
}

p = READ_ONCE(local_v); // g

r2 = READ_ONCE(*p);   // h

if r1 == 1, we definitely think we have:

f ->ctrl e ->rfi g ->addr h

, and if we treat ctrl;rfi as "to-r", then we have "f" happens before
"h". However compile can optimze the above as:

local_v = &y;

r1 = READ_ONCE(*x); // f

if (r1 != 1) {
local_v = &z; // d
}

p = READ_ONCE(local_v); // g

r2 = READ_ONCE(*p);   // h

, and when this gets executed, I don't think we have the guarantee we
have "f" happens before "h", because CPU can do optimistic read for "g"
and "h".

Part of this is because when we take plain access into consideration, we
won't guarantee a read-from or other relations exists if compiler
optimization happens.

Maybe I'm missing something subtle, but just try to think through the
effect of making dep; rfi as "to-r".

Regards,
Boqun

> Alan


[PATCH] perf report: Fix -F for branch & mem modes

2021-03-03 Thread Ravi Bangoria
perf report fails to add valid additional fields with -F when
used with branch or mem modes. Fix it.

Before patch:

  $ ./perf record -b
  $ ./perf report -b -F +srcline_from --stdio
  Error:
  Invalid --fields key: `srcline_from'

After patch:

  $ ./perf report -b -F +srcline_from --stdio
  # Samples: 8K of event 'cycles'
  # Event count (approx.): 8784
  ...

Reported-by: Athira Rajeev 
Fixes: aa6b3c99236b ("perf report: Make -F more strict like -s")
Signed-off-by: Ravi Bangoria 
---
 tools/perf/util/sort.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 0d5ad42812b9..552b590485bf 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -3140,7 +3140,7 @@ int output_field_add(struct perf_hpp_list *list, char 
*tok)
if (strncasecmp(tok, sd->name, strlen(tok)))
continue;
 
-   if (sort__mode != SORT_MODE__MEMORY)
+   if (sort__mode != SORT_MODE__BRANCH)
return -EINVAL;
 
return __sort_dimension__add_output(list, sd);
@@ -3152,7 +3152,7 @@ int output_field_add(struct perf_hpp_list *list, char 
*tok)
if (strncasecmp(tok, sd->name, strlen(tok)))
continue;
 
-   if (sort__mode != SORT_MODE__BRANCH)
+   if (sort__mode != SORT_MODE__MEMORY)
return -EINVAL;
 
return __sort_dimension__add_output(list, sd);
-- 
2.29.2



Re: [PATCH 5/7] printk: Make %pS and friends print module build ID

2021-03-03 Thread Stephen Boyd
Quoting Steven Rostedt (2021-03-03 17:19:32)
> On Wed, 03 Mar 2021 16:38:28 -0800
> Stephen Boyd  wrote:
> 
> > I'm starting to feel like nobody read the commit text, or I messed up
> > somehow and the commit text was confusing? :(
> > 
> 
> I read it, I'm just unfamiliar with it. I don't use pstore, and I'm not
> sure what "crashdump" is. Do you mean the kexec/kdump? in which case
> you can retrieve data within the kernel quite easily.

Right, I meant kexec/kdump. Given that it is easy to retrieve it in
kdump (presumably with some scripting?) I can remove this motivation
from the commit text.

> 
> I haven't used debuginfod (never heard of it before actually).

Got it. Hopefully the links I provided were good enough? I will provide
a link next time.

> 
> > │ This is especially helpful for crash debugging with pstore or crashdump   
> > 
> >   
> > │ kernels. If we have the build ID for the module in the stacktrace we can  
> > 
> >   
> > │ request the debug symbols for the module from a remote debuginfod server  
> > 
> >   
> > │ or parse stacktraces at a later time with decode_stacktrace.sh by 
> > 
> >   
> > │ downloading the correct symbols based on the build ID. This cuts down on  
> > 
> >   
> > │ the amount of time and effort needed to find the correct kernel modules   
> > 
> >   
> > │ for a stacktrace by encoding that information into it.  
> 
> Are you saying it's common to have modules from different builds?

No.

> 
> > 
> > In some distro (read: non-kernel dev) workflows the vmlinux isn't
> > shipped on the device and crash handling is done offline or much later.
> > Using the build ID[1] is a common way to identify the binary that's
> > running on the device. In conjunction with a debuginfod[2] server you
> > can download the symbols for a crash automatically if you have the build
> > ID information.
> > 
> > I can add a patch that updates decode_stacktrace.sh to show how it can
> > download the correct vmlinux/modules if it isn't provided on the
> > commandline.
> 
> Are you just trying to match modules with the builds that they were
> created with?

Not exactly. I don't have a mapping of modules to the kernel they're
built/used with. I could create a mapping, but then that's something
else to maintain vs. what I have right now which is just a big database
of debuginfo mapped to build IDs (i.e. a debuginfod server).

> 
> > 
> > If the debug symbols are on some public server then in theory we could
> > have some robot sitting on the mailing list that looks for stacktraces
> > and automatically replies with information about the line number/file
> > and even provides the code snippet for the code that's crashing from
> > that binary, because it's all stored in the full debuginfo builds.
> 
> Again, I have no idea how buildids are created or what they are used
> for. This is the first time I've even heard about them. I'm all for
> helping other people out to make their workflow easier, if it doesn't
> make a mess for everyone else.
> 
> 

Makes sense and sounds good. Thanks.


Re: [PATCH v26 4/4] scsi: ufs: Add HPB 2.0 support

2021-03-03 Thread Can Guo


-   if (!ufshpb_is_support_chunk(transfer_len))
-   return;
+   if (!ufshpb_is_support_chunk(hpb, transfer_len) &&
+	(ufshpb_is_legacy(hba) && (transfer_len != 
HPB_LEGACY_CHUNK_HIGH)))

+   return 0;



This is looks awkward, can we put the checks in 
ufshpb_is_support_chunk()?


Thanks,

Can Guo.


Re: [PATCH v6] i2c: virtio: add a virtio i2c frontend driver

2021-03-03 Thread kernel test robot
Hi Jie,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on vhost/linux-next linux/master linus/master v5.12-rc1 
next-20210303]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210304-100543
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
i2c/for-next
config: x86_64-randconfig-a014-20210304 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
eec7f8f7b1226be422a76542cb403d02538f453a)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/bb645653b6d7750a026229726f8d9d0371457ac6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210304-100543
git checkout bb645653b6d7750a026229726f8d9d0371457ac6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   In file included from :1:
>> ./usr/include/linux/virtio_i2c.h:35:2: error: unknown type name 'u8'
   u8 status;
   ^
   1 error generated.

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


.config.gz
Description: application/gzip


Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

2021-03-03 Thread Vipin Sharma
On Wed, Mar 03, 2021 at 06:55:13PM -0800, Jacob Pan wrote:
> Hi Vipin,
> 
> On Tue,  2 Mar 2021 00:17:05 -0800, Vipin Sharma  wrote:
> 
> > +Migration and Ownership
> > +~~~
> > +
> > +A miscellaneous scalar resource is charged to the cgroup in which it is
> > used +first, and stays charged to that cgroup until that resource is
> > freed. Migrating +a process to a different cgroup does not move the
> > charge to the destination +cgroup where the process has moved.
> > +
> I am trying to see if IOASIDs cgroup can also fit in this misc controller
> as yet another resource type.
> https://lore.kernel.org/linux-iommu/20210303131726.7a8cb169@jacob-builder/T/#u
> However, unlike sev IOASIDs need to be migrated if the process is moved to
> another cgroup. i.e. charge the destination and uncharge the source.
> 
> Do you think this behavior can be achieved by differentiating resource
> types? i.e. add attach callbacks for certain types. Having a single misc
> interface seems cleaner than creating another controller.

I think it makes sense to add support for migration for the resources
which need it. Resources like SEV, SEV-ES will not participate in
migration and won't stop can_attach() to succeed, other resources which
need migration will allow or stop based on their limits and capacity in
the destination.


[rcu:tglx-pc.2021.03.03a] BUILD SUCCESS 614745c470c1cc6c2becaec5d0b4435f83dc3c99

2021-03-03 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
tglx-pc.2021.03.03a
branch HEAD: 614745c470c1cc6c2becaec5d0b4435f83dc3c99  rcu/tree: Allocate a 
page when caller is preemptible

elapsed time: 725m

configs tested: 96
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
arm  colibri_pxa300_defconfig
mips  malta_defconfig
h8300   defconfig
ia64  gensparse_defconfig
powerpc  pmac32_defconfig
arc  axs103_defconfig
armclps711x_defconfig
m68k   m5249evb_defconfig
powerpc   holly_defconfig
armmini2440_defconfig
armvexpress_defconfig
mips cu1830-neo_defconfig
powerpc tqm5200_defconfig
mips  rm200_defconfig
arm64alldefconfig
armoxnas_v6_defconfig
mips  cavium_octeon_defconfig
mipsar7_defconfig
armrealview_defconfig
powerpc  ppc64e_defconfig
powerpc  ppc44x_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a005-20210303
i386 randconfig-a003-20210303
i386 randconfig-a002-20210303
i386 randconfig-a004-20210303
i386 randconfig-a006-20210303
i386 randconfig-a001-20210303
x86_64   randconfig-a013-20210303
x86_64   randconfig-a016-20210303
x86_64   randconfig-a015-20210303
x86_64   randconfig-a014-20210303
x86_64   randconfig-a012-20210303
x86_64   randconfig-a011-20210303
i386 randconfig-a016-20210304
i386 randconfig-a012-20210304
i386 randconfig-a013-20210304
i386 randconfig-a014-20210304
i386 randconfig-a011-20210304
i386 randconfig-a015-20210304
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   allyesconfig
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-a006-20210303
x86_64   randconfig-a001-20210303
x86_64   randconfig-a004-20210303
x86_64   randconfig-a002-20210303
x86_64   randconfig-a005-20210303
x86_64   randconfig-a003-20210303

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


[PATCH v3 2/2] crypto: hisilicon/sec - fixes some driver coding style

2021-03-03 Thread Longfang Liu
cleanup static check errors for SEC

Signed-off-by: Longfang Liu 
---
 drivers/crypto/hisilicon/sec2/sec_main.c | 131 ++-
 1 file changed, 76 insertions(+), 55 deletions(-)

diff --git a/drivers/crypto/hisilicon/sec2/sec_main.c 
b/drivers/crypto/hisilicon/sec2/sec_main.c
index dc68ba7..78a6043 100644
--- a/drivers/crypto/hisilicon/sec2/sec_main.c
+++ b/drivers/crypto/hisilicon/sec2/sec_main.c
@@ -35,15 +35,13 @@
 #define SEC_CTX_Q_NUM_MAX  32
 
 #define SEC_CTRL_CNT_CLR_CE0x301120
-#define SEC_CTRL_CNT_CLR_CE_BITBIT(0)
-#define SEC_ENGINE_PF_CFG_OFF  0x30
-#define SEC_ACC_COMMON_REG_OFF 0x1000
+#define SEC_CTRL_CNT_CLR_CE_BITBIT(0)
 #define SEC_CORE_INT_SOURCE0x301010
 #define SEC_CORE_INT_MASK  0x301000
 #define SEC_CORE_INT_STATUS0x301008
 #define SEC_CORE_SRAM_ECC_ERR_INFO 0x301C14
-#define SEC_ECC_NUM(err)   (((err) >> 16) & 0xFF)
-#define SEC_ECC_ADDR(err)  ((err) >> 0)
+#define SEC_ECC_NUM16
+#define SEC_ECC_MASH   0xFF
 #define SEC_CORE_INT_DISABLE   0x0
 #define SEC_CORE_INT_ENABLE0x1ff
 #define SEC_CORE_INT_CLEAR 0x1ff
@@ -55,23 +53,23 @@
 #define SEC_RAS_CE_ENB_MSK 0x88
 #define SEC_RAS_FE_ENB_MSK 0x0
 #define SEC_RAS_NFE_ENB_MSK0x177
-#define SEC_RAS_DISABLE0x0
-#define SEC_MEM_START_INIT_REG 0x0100
-#define SEC_MEM_INIT_DONE_REG  0x0104
+#define SEC_RAS_DISABLE0x0
+#define SEC_MEM_START_INIT_REG 0x301100
+#define SEC_MEM_INIT_DONE_REG  0x301104
 
-#define SEC_CONTROL_REG0x0200
+#define SEC_CONTROL_REG0x301200
 #define SEC_TRNG_EN_SHIFT  8
 #define SEC_CLK_GATE_ENABLEBIT(3)
 #define SEC_CLK_GATE_DISABLE   (~BIT(3))
 #define SEC_AXI_SHUTDOWN_ENABLEBIT(12)
 #define SEC_AXI_SHUTDOWN_DISABLE   0xEFFF
 
-#define SEC_INTERFACE_USER_CTRL0_REG   0x0220
-#define SEC_INTERFACE_USER_CTRL1_REG   0x0224
-#define SEC_SAA_EN_REG 0x0270
-#define SEC_BD_ERR_CHK_EN_REG0 0x0380
-#define SEC_BD_ERR_CHK_EN_REG1 0x0384
-#define SEC_BD_ERR_CHK_EN_REG3 0x038c
+#define SEC_INTERFACE_USER_CTRL0_REG   0x301220
+#define SEC_INTERFACE_USER_CTRL1_REG   0x301224
+#define SEC_SAA_EN_REG 0x301270
+#define SEC_BD_ERR_CHK_EN_REG0 0x301380
+#define SEC_BD_ERR_CHK_EN_REG1 0x301384
+#define SEC_BD_ERR_CHK_EN_REG3 0x30138c
 
 #define SEC_USER0_SMMU_NORMAL  (BIT(23) | BIT(15))
 #define SEC_USER1_SMMU_NORMAL  (BIT(31) | BIT(23) | BIT(15) | BIT(7))
@@ -95,9 +93,6 @@
 #define SEC_SQE_MASK_OFFSET64
 #define SEC_SQE_MASK_LEN   48
 
-#define SEC_ADDR(qm, offset) ((qm)->io_base + (offset) + \
-SEC_ENGINE_PF_CFG_OFF + SEC_ACC_COMMON_REG_OFF)
-
 struct sec_hw_error {
u32 int_msk;
const char *msg;
@@ -117,16 +112,43 @@ static struct hisi_qm_list sec_devices = {
 };
 
 static const struct sec_hw_error sec_hw_errors[] = {
-   {.int_msk = BIT(0), .msg = "sec_axi_rresp_err_rint"},
-   {.int_msk = BIT(1), .msg = "sec_axi_bresp_err_rint"},
-   {.int_msk = BIT(2), .msg = "sec_ecc_2bit_err_rint"},
-   {.int_msk = BIT(3), .msg = "sec_ecc_1bit_err_rint"},
-   {.int_msk = BIT(4), .msg = "sec_req_trng_timeout_rint"},
-   {.int_msk = BIT(5), .msg = "sec_fsm_hbeat_rint"},
-   {.int_msk = BIT(6), .msg = "sec_channel_req_rng_timeout_rint"},
-   {.int_msk = BIT(7), .msg = "sec_bd_err_rint"},
-   {.int_msk = BIT(8), .msg = "sec_chain_buff_err_rint"},
-   { /* sentinel */ }
+   {
+   .int_msk = BIT(0),
+   .msg = "sec_axi_rresp_err_rint"
+   },
+   {
+   .int_msk = BIT(1),
+   .msg = "sec_axi_bresp_err_rint"
+   },
+   {
+   .int_msk = BIT(2),
+   .msg = "sec_ecc_2bit_err_rint"
+   },
+   {
+   .int_msk = BIT(3),
+   .msg = "sec_ecc_1bit_err_rint"
+   },
+   {
+   .int_msk = BIT(4),
+   .msg = "sec_req_trng_timeout_rint"
+   },
+   {
+   .int_msk = BIT(5),
+   .msg = "sec_fsm_hbeat_rint"
+   },
+   {
+   .int_msk = BIT(6),
+   .msg = "sec_channel_req_rng_timeout_rint"
+   },
+   {
+   .int_msk = BIT(7),
+   .msg = "sec_bd_err_rint"
+   },
+   {
+   .int_msk = BIT(8),
+   .msg = "sec_chain_buff_err_rint"
+   },
+   {}
 };
 
 static const char * const sec_dbg_file_name[] = {
@@ -277,9 +299,7 @@ static u8 sec_get_endian(struct hisi_qm *qm)
"cannot access a register in VF!\n");
return SEC_L

[PATCH v3 1/2] crypto: hisilicon/sec - fixes some log printing style

2021-03-03 Thread Longfang Liu
1. Fix a problem of error log printing
2. Modify error log printing style

Signed-off-by: Longfang Liu 
---
 drivers/crypto/hisilicon/sec2/sec.h|  5 +-
 drivers/crypto/hisilicon/sec2/sec_crypto.c | 82 +++---
 drivers/crypto/hisilicon/sec2/sec_crypto.h |  2 -
 3 files changed, 42 insertions(+), 47 deletions(-)

diff --git a/drivers/crypto/hisilicon/sec2/sec.h 
b/drivers/crypto/hisilicon/sec2/sec.h
index 0849191..a8c10e3 100644
--- a/drivers/crypto/hisilicon/sec2/sec.h
+++ b/drivers/crypto/hisilicon/sec2/sec.h
@@ -4,8 +4,6 @@
 #ifndef __HISI_SEC_V2_H
 #define __HISI_SEC_V2_H
 
-#include 
-
 #include "../qm.h"
 #include "sec_crypto.h"
 
@@ -50,7 +48,7 @@ struct sec_req {
 
int err_type;
int req_id;
-   int flag;
+   u32 flag;
 
/* Status of the SEC request */
bool fake_busy;
@@ -139,6 +137,7 @@ struct sec_ctx {
bool pbuf_supported;
struct sec_cipher_ctx c_ctx;
struct sec_auth_ctx a_ctx;
+   struct device *dev;
 };
 
 enum sec_endian {
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c 
b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 2eaa516..d2c4a2c 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -43,7 +43,6 @@
 
 #define SEC_TOTAL_IV_SZ(SEC_IV_SIZE * QM_Q_DEPTH)
 #define SEC_SGL_SGE_NR 128
-#define SEC_CTX_DEV(ctx)   (&(ctx)->sec->qm.pdev->dev)
 #define SEC_CIPHER_AUTH0xfe
 #define SEC_AUTH_CIPHER0x1
 #define SEC_MAX_MAC_LEN64
@@ -96,7 +95,7 @@ static int sec_alloc_req_id(struct sec_req *req, struct 
sec_qp_ctx *qp_ctx)
  0, QM_Q_DEPTH, GFP_ATOMIC);
mutex_unlock(&qp_ctx->req_lock);
if (unlikely(req_id < 0)) {
-   dev_err(SEC_CTX_DEV(req->ctx), "alloc req id fail!\n");
+   dev_err(req->ctx->dev, "alloc req id fail!\n");
return req_id;
}
 
@@ -112,7 +111,7 @@ static void sec_free_req_id(struct sec_req *req)
int req_id = req->req_id;
 
if (unlikely(req_id < 0 || req_id >= QM_Q_DEPTH)) {
-   dev_err(SEC_CTX_DEV(req->ctx), "free request id invalid!\n");
+   dev_err(req->ctx->dev, "free request id invalid!\n");
return;
}
 
@@ -138,7 +137,7 @@ static int sec_aead_verify(struct sec_req *req)
aead_req->cryptlen + aead_req->assoclen -
authsize);
if (unlikely(sz != authsize || memcmp(mac_out, mac, sz))) {
-   dev_err(SEC_CTX_DEV(req->ctx), "aead verify failure!\n");
+   dev_err(req->ctx->dev, "aead verify failure!\n");
return -EBADMSG;
}
 
@@ -177,7 +176,7 @@ static void sec_req_cb(struct hisi_qp *qp, void *resp)
if (unlikely(req->err_type || done != SEC_SQE_DONE ||
(ctx->alg_type == SEC_SKCIPHER && flag != SEC_SQE_CFLAG) ||
(ctx->alg_type == SEC_AEAD && flag != SEC_SQE_AEAD_FLAG))) {
-   dev_err(SEC_CTX_DEV(ctx),
+   dev_err_ratelimited(ctx->dev,
"err_type[%d],done[%d],flag[%d]\n",
req->err_type, done, flag);
err = -EIO;
@@ -326,8 +325,8 @@ static int sec_alloc_pbuf_resource(struct device *dev, 
struct sec_alg_res *res)
 static int sec_alg_resource_alloc(struct sec_ctx *ctx,
  struct sec_qp_ctx *qp_ctx)
 {
-   struct device *dev = SEC_CTX_DEV(ctx);
struct sec_alg_res *res = qp_ctx->res;
+   struct device *dev = ctx->dev;
int ret;
 
ret = sec_alloc_civ_resource(dev, res);
@@ -360,7 +359,7 @@ static int sec_alg_resource_alloc(struct sec_ctx *ctx,
 static void sec_alg_resource_free(struct sec_ctx *ctx,
  struct sec_qp_ctx *qp_ctx)
 {
-   struct device *dev = SEC_CTX_DEV(ctx);
+   struct device *dev = ctx->dev;
 
sec_free_civ_resource(dev, qp_ctx->res);
 
@@ -373,7 +372,7 @@ static void sec_alg_resource_free(struct sec_ctx *ctx,
 static int sec_create_qp_ctx(struct hisi_qm *qm, struct sec_ctx *ctx,
 int qp_ctx_id, int alg_type)
 {
-   struct device *dev = SEC_CTX_DEV(ctx);
+   struct device *dev = ctx->dev;
struct sec_qp_ctx *qp_ctx;
struct hisi_qp *qp;
int ret = -ENOMEM;
@@ -428,7 +427,7 @@ static int sec_create_qp_ctx(struct hisi_qm *qm, struct 
sec_ctx *ctx,
 static void sec_release_qp_ctx(struct sec_ctx *ctx,
   struct sec_qp_ctx *qp_ctx)
 {
-   struct device *dev = SEC_CTX_DEV(ctx);
+   struct device *dev = ctx->dev;
 
hisi_qm_stop_qp(qp_ctx->qp);
sec_alg_resource_free(ctx, qp_ctx);
@@ -452,6 +451,7 @@ static int sec_ctx_base_init(struct sec_ctx *ctx)
 
sec = container_of(ctx->qps[0]->qm, struct sec_dev, qm);
ctx->sec = sec;
+   ctx->dev = &sec->

[PATCH v3 0/2] crypto:hisilicon/sec - fixes some coding style

2021-03-03 Thread Longfang Liu
1. Fix a problems.
2. Fix some coding style.

Changes v2 -> v3:
  - Delete shash test error patch.

Changes v1 -> v2:
  - Modify the way to fix shash test error.

Longfang Liu (2):
  crypto: hisilicon/sec - fixes some log printing style
  crypto: hisilicon/sec - fixes some driver coding style

 drivers/crypto/hisilicon/sec2/sec.h|   5 +-
 drivers/crypto/hisilicon/sec2/sec_crypto.c |  82 +-
 drivers/crypto/hisilicon/sec2/sec_crypto.h |   2 -
 drivers/crypto/hisilicon/sec2/sec_main.c   | 131 +
 4 files changed, 118 insertions(+), 102 deletions(-)

-- 
2.8.1



[PATCH v2] MIPS: Make MIPS32_O32 depends on !CC_IS_CLANG

2021-03-03 Thread Tiezhu Yang
When build kernel with Clang [1]:

$ make CC=clang loongson3_defconfig
$ make CC=clang

there exists the following error:

  Checking missing-syscalls for O32
  CALLscripts/checksyscalls.sh
error: ABI 'o32' is not supported on CPU 'mips64r2'
make[1]: *** [Kbuild:48: missing-syscalls] Error 1
make: *** [arch/mips/Makefile:419: archprepare] Error 2

This is a known bug [2] with Clang, as Simon Atanasyan said,
"There is no plan on support O32 for MIPS64 due to lack of
resources".

It is not a good idea to remove CONFIG_MIPS32_O32=y directly
in defconfig due to GCC works well, as Nathan said, the config
should not even be selectable when build kernel with Clang, so
just make MIPS32_O32 depends on !CC_IS_CLANG.

[1] https://www.kernel.org/doc/html/latest/kbuild/llvm.html
[2] https://bugs.llvm.org/show_bug.cgi?id=38063

Signed-off-by: Tiezhu Yang 
---
 arch/mips/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 3a38d27..f6ba59f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -3318,6 +3318,8 @@ config SYSVIPC_COMPAT
 config MIPS32_O32
bool "Kernel support for o32 binaries"
depends on 64BIT
+   # https://bugs.llvm.org/show_bug.cgi?id=38063
+   depends on !CC_IS_CLANG
select ARCH_WANT_OLD_COMPAT_IPC
select COMPAT
select MIPS32_COMPAT
-- 
2.1.0



[PATCH v4 5/8] mm: Device exclusive memory access

2021-03-03 Thread Alistair Popple
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.

In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIVE). When a SVM range needs to be marked for
exclusive access by a device all page table mappings for the particular
range are replaced with device exclusive swap entries. This causes any
CPU access to the page to result in a fault.

Faults are resovled by replacing the faulting entry with the original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.

Signed-off-by: Alistair Popple 

---

v4:
* Add function to check that mappings are still valid and exclusive.
* s/long/unsigned long/ in make_device_exclusive_entry().
---
 Documentation/vm/hmm.rst |  15 +++
 include/linux/rmap.h |   5 +
 include/linux/swap.h |   4 +-
 include/linux/swapops.h  |  44 +++-
 mm/hmm.c |   5 +
 mm/memory.c  | 107 +-
 mm/mprotect.c|   8 ++
 mm/page_vma_mapped.c |   9 +-
 mm/rmap.c| 230 +++
 9 files changed, 420 insertions(+), 7 deletions(-)

diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 09e28507f5b2..f526ac4d8798 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -405,6 +405,21 @@ between device driver specific code and shared common code:
 
The lock can now be released.
 
+Exclusive access memory
+===
+
+Not all devices support atomic access to system memory. To support atomic
+operations to a shared virtual memory page such a device needs access to that
+page which is exclusive of any userspace access from the CPU. The
+``make_device_exclusive_range()`` function can be used to make a memory range
+inaccessible from userspace.
+
+This replaces all mappings for pages in the given range with special swap
+entries. Any attempt to access the swap entry results in a fault which is
+resovled by replacing the entry with the original mapping. A driver gets
+notified that the mapping has been changed by MMU notifiers, after which point
+it will no longer have exclusive access to the page.
+
 Memory cgroup (memcg) and rss accounting
 
 
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 77fa17de51d7..93cbb88f7253 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -193,6 +193,11 @@ int page_referenced(struct page *, int is_locked,
 bool try_to_migrate(struct page *page, enum ttu_flags flags);
 bool try_to_unmap(struct page *, enum ttu_flags flags);
 
+int make_device_exclusive_range(struct mm_struct *mm, unsigned long start,
+   unsigned long end, struct page **pages);
+bool check_device_exclusive_range(struct mm_struct *mm, unsigned long start,
+ unsigned long end, struct page **pages);
+
 /* Avoid racy checks */
 #define PVMW_SYNC  (1 << 0)
 /* Look for migarion entries rather than present PTEs */
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 57a7690966a4..2d8b8e7fb4c2 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -63,9 +63,11 @@ static inline int current_is_kswapd(void)
  * to a special SWP_DEVICE_* entry.
  */
 #ifdef CONFIG_DEVICE_PRIVATE
-#define SWP_DEVICE_NUM 2
+#define SWP_DEVICE_NUM 4
 #define SWP_DEVICE_WRITE (MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM)
 #define SWP_DEVICE_READ (MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+1)
+#define SWP_DEVICE_EXCLUSIVE_WRITE 
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+2)
+#define SWP_DEVICE_EXCLUSIVE_READ 
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+3)
 #else
 #define SWP_DEVICE_NUM 0
 #endif
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 81008b0179cc..20b726e27f37 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -120,6 +120,27 @@ static inline bool 
is_writable_device_private_entry(swp_entry_t entry)
 {
return unlikely(swp_type(entry) == SWP_DEVICE_WRITE);
 }
+
+static inline swp_entry_t make_readable_device_exclusive_entry(pgoff_t offset)
+{
+   return swp_entry(SWP_DEVICE_EXCLUSIVE_READ, offset);
+}
+
+static inline swp_entry_t make_writable_device_exclusive_entry(pgoff_t offset)
+{
+   return swp_entry(SWP_DEVICE_EXCLUSIVE_WRITE, offset);
+}
+
+static inline bool is_device_exclusive_entry(swp_entry_t entry)
+{
+   return swp_type(entry) == SWP_DEVICE_EXCLUSIVE_READ ||
+   swp_type(entry) == SWP_DEVICE_EXCLUSIVE_WRITE;
+}
+
+static inline bool is_writable_device_exclusive_entry(swp_entry_t entry)
+{
+   return unlikely(swp_type(entry) == SWP_DEVICE_EXCLUSIVE_WRIT

  1   2   3   4   5   6   7   8   9   10   >