ERROR: modpost: ".__sanitizer_cov_trace_cmp4" undefined!

[kernel test robot]

Hi Madhavan,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   996e435fd401de35df62ac943ab9402cfe85c430
commit: 3c9450c053f88e525b2db1e6990cdf34d14e7696 powerpc/perf: Fix missing 
is_sier_aviable() during build
date:   6 months ago
config: powerpc-randconfig-r004-20210108 (attached as .config)
compiler: powerpc64-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=3c9450c053f88e525b2db1e6990cdf34d14e7696
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 3c9450c053f88e525b2db1e6990cdf34d14e7696
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

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: ".hid_unregister_driver" [drivers/hid/hid-ortek.ko] undefined!
ERROR: modpost: ".__hid_register_driver" [drivers/hid/hid-ortek.ko] undefined!
ERROR: modpost: "._dev_info" [drivers/hid/hid-ortek.ko] undefined!
ERROR: modpost: ".__sanitizer_cov_trace_const_cmp1" [drivers/hid/hid-ortek.ko] 
undefined!
ERROR: modpost: ".__sanitizer_cov_trace_const_cmp4" [drivers/hid/hid-ortek.ko] 
undefined!
ERROR: modpost: ".__sanitizer_cov_trace_pc" [drivers/hid/hid-ortek.ko] 
undefined!
ERROR: modpost: ".__gcov_exit" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".__gcov_init" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".hid_unregister_driver" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".__hid_register_driver" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".sysfs_create_group" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".hid_hw_start" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".hid_open_report" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".init_timer_key" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".__sanitizer_cov_trace_cmp8" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".__hid_request" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".find_next_bit" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".mod_timer" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".__sanitizer_cov_trace_const_cmp2" 
[drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".jiffies_to_usecs" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".input_mt_get_slot_by_key" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".__sanitizer_cov_trace_cmp1" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".strlen" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".input_mt_init_slots" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".devm_kfree" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".__stack_chk_fail" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".kstrtoull" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".hid_hw_stop" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".sysfs_remove_group" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".del_timer" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".input_set_capability" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".__dynamic_dev_dbg" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".input_alloc_absinfo" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".hidinput_calc_abs_res" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".input_set_abs_params" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".__list_add_valid" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".devm_kmalloc" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".sprintf" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: "._dev_err" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".__sanitizer_cov_trace_const_cmp1" 
[drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".__sanitizer_cov_trace_switch" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: "._dev_warn" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".kfree" [drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".hid_report_raw_event" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".hid_alloc_report_buf" [drivers/hid/hid-multitouch.ko] 
undefined!
ERROR: modpost: ".__sanitizer_cov_trace_const_cmp8" 
[drivers/hid/hid-multitouch.ko] undefined!
ERROR: modpost: ".input_mt_sync_frame" [drivers/hid/hid-multitouch.ko] 
undefine

[PATCH V2] x86/sev-es: Fix SEV-ES #VC handler for string port IO

[Hyunwook (Wooky) Baek]

Don't assume dest/source buffers are userspace addresses when manually
copying data for string I/O or MOVS MMIO, as {get,put}_user() will fail
if handed a kernel address and ultimately lead to a kernel panic.

Signed-off-by: Hyunwook (Wooky) Baek 
Acked-by: David Rientjes 
---

This patch is tested by invoking INSB/OUTSB instructions in kernel space in a
SEV-ES-enabled VM. Without the patch, the kernel crashed with the following
message:
  "SEV-ES: Unsupported exception in #VC instruction emulation - can't continue"
With the patch, the instructions successfully read/wrote the string from/to
the I/O port.

 arch/x86/kernel/sev-es.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c
index 0bd1a0fc587e..ab31c34ba508 100644
--- a/arch/x86/kernel/sev-es.c
+++ b/arch/x86/kernel/sev-es.c
@@ -286,6 +286,12 @@ static enum es_result vc_write_mem(struct es_em_ctxt *ctxt,
u16 d2;
u8  d1;

+   /* If instruction ran in kernel mode and the I/O buffer is in kernel 
space */
+   if (!user_mode(ctxt->regs) && !access_ok(target, size)) {
+   memcpy(dst, buf, size);
+   return ES_OK;
+   }
+
switch (size) {
case 1:
memcpy(&d1, buf, 1);
@@ -335,6 +341,12 @@ static enum es_result vc_read_mem(struct es_em_ctxt *ctxt,
u16 d2;
u8  d1;

+   /* If instruction ran in kernel mode and the I/O buffer is in kernel 
space */
+   if (!user_mode(ctxt->regs) && !access_ok(s, size)) {
+   memcpy(buf, src, size);
+   return ES_OK;
+   }
+
switch (size) {
case 1:
if (get_user(d1, s))
--
2.30.0.284.gd98b1dd5eaa7-goog

Re: [PATCH v3 0/6] add timestamp channel for hid-sensors

[Ye, Xiang]

On Sat, Jan 09, 2021 at 07:28:05PM +, Jonathan Cameron wrote:
> On Tue, 5 Jan 2021 17:26:33 +0800
> "Ye, Xiang"  wrote:
> 
> > On Tue, Jan 05, 2021 at 12:53:44AM -0800, Srinivas Pandruvada wrote:
> > > On Tue, 2021-01-05 at 15:21 +0800, Ye Xiang wrote:  
> > > > This patch series add a timestamp channel for hid sensors,
> > > > including gravity sensor, gyro sensor, magnetometer sensor,
> > > > ambient light sensor, inclinometer sensor, and rotation sensor.
> > > > 
> > > > With this patch series, user can get the time when sensor yield
> > > > a sample.
> > > >   
> > > I think this series is v1 for upstream not v3.  
> > Sorry, it's v1 for upstream. will resent it as v1. v3 is our internal 
> > review version.
> > 
> Future notice, if you make a mistake of this particular type - don't resend 
> and
> carry on with future version numbers.  Otherwise it gets really confusing
> if we get to a public v3 version!   Monotonic version numbers only :)
> 
> Not a bit problem though but if that does happen check I don't grab the wrong
> version.

Got it. you grabed the right version v1 for test. thanks.

Thanks
Ye Xiang

> 
> > > 
> > >   
> > > > ---
> > > > v3:
> > > >   - hid-sensor-magn-3d: fix iio_val buffer len issue.
> > > >   - hid-sensor-accel-3d: refine commit message
> > > > 
> > > > v2:
> > > >   - remove unrelated changes.
> > > > 
> > > > Ye Xiang (6):
> > > >   iio: hid-sensor-accel-3d: Add timestamp channel for gravity sensor
> > > >   iio: hid-sensor-gyro-3d: Add timestamp channel
> > > >   iio: hid-sensor-als: Add timestamp channel
> > > >   iio: hid-sensor-magn-3d: Add timestamp channel
> > > >   iio: hid-sensor-incl-3d: Add timestamp channel
> > > >   iio: hid-sensor-rotation: Add timestamp channel
> > > > 
> > > >  drivers/iio/accel/hid-sensor-accel-3d.c   |  6 ++-
> > > >  drivers/iio/gyro/hid-sensor-gyro-3d.c | 40 +---
> > > >  drivers/iio/light/hid-sensor-als.c    | 39 ---
> > > >  drivers/iio/magnetometer/hid-sensor-magn-3d.c | 48 -
> > > > --
> > > >  drivers/iio/orientation/hid-sensor-incl-3d.c  | 43 ++---
> > > >  drivers/iio/orientation/hid-sensor-rotation.c | 46 ++---
> > > > -
> > > >  6 files changed, 134 insertions(+), 88 deletions(-)
> > > >   
> > > 
> > >   
> 

possible deadlock in lock_sock_nested

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:f6e7a024 Merge tag 'arc-5.11-rc3' of git://git.kernel.org/..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=135c95fb50
kernel config:  https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
dashboard link: https://syzkaller.appspot.com/bug?extid=d8d5fa7f3a0c96bcdc78
compiler:   gcc (GCC) 10.1.0-syz 20200507

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

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


WARNING: possible irq lock inversion dependency detected
5.11.0-rc2-syzkaller #0 Not tainted

kworker/1:0/19 just changed the state of lock:
88805f80b0a0 (wq_mayday_lock){+.-.}-{2:2}, at: spin_lock_bh 
include/linux/spinlock.h:359 [inline]
88805f80b0a0 (wq_mayday_lock){+.-.}-{2:2}, at: lock_sock_nested+0x3b/0x110 
net/core/sock.c:3049
but this lock was taken by another, HARDIRQ-safe lock in the past:
 (&pool->lock){-.-.}-{2:2}


and interrupts could create inverse lock ordering between them.


other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

   CPU0CPU1
   
  lock(wq_mayday_lock);
   local_irq_disable();
   lock(&pool->lock);
   lock(wq_mayday_lock);
  
lock(&pool->lock);

 *** DEADLOCK ***

4 locks held by kworker/1:0/19:
 #0: 888010062d38 ((wq_completion)events){+.+.}-{0:0}, at: 
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: 888010062d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic64_set 
include/asm-generic/atomic-instrumented.h:856 [inline]
 #0: 888010062d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic_long_set 
include/asm-generic/atomic-long.h:41 [inline]
 #0: 888010062d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_data 
kernel/workqueue.c:616 [inline]
 #0: 888010062d38 ((wq_completion)events){+.+.}-{0:0}, at: 
set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
 #0: 888010062d38 ((wq_completion)events){+.+.}-{0:0}, at: 
process_one_work+0x871/0x15f0 kernel/workqueue.c:2246
 #1: c9d97da8 
((work_completion)(&(&chan->chan_timer)->work)){+.+.}-{0:0}, at: 
process_one_work+0x8a5/0x15f0 kernel/workqueue.c:2250
 #2: 88802fc01ad8 (&conn->chan_lock){+.+.}-{3:3}, at: 
l2cap_chan_timeout+0x69/0x2f0 net/bluetooth/l2cap_core.c:422
 #3: 8880623c6520 (&chan->lock/1){+.+.}-{3:3}, at: l2cap_chan_lock 
include/net/bluetooth/l2cap.h:852 [inline]
 #3: 8880623c6520 (&chan->lock/1){+.+.}-{3:3}, at: 
l2cap_chan_timeout+0xb5/0x2f0 net/bluetooth/l2cap_core.c:426

the shortest dependencies between 2nd lock and 1st lock:
 -> (&pool->lock){-.-.}-{2:2} {
IN-HARDIRQ-W at:
  lock_acquire kernel/locking/lockdep.c:5437 [inline]
  lock_acquire+0x29d/0x740 kernel/locking/lockdep.c:5402
  __raw_spin_lock include/linux/spinlock_api_smp.h:142 
[inline]
  _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
  __queue_work+0x375/0xf00 kernel/workqueue.c:1455
  queue_work_on+0xc7/0xd0 kernel/workqueue.c:1524
  tick_nohz_activate kernel/time/tick-sched.c:1285 [inline]
  tick_nohz_activate kernel/time/tick-sched.c:1278 [inline]
  tick_setup_sched_timer+0x1e8/0x320 
kernel/time/tick-sched.c:1419
  hrtimer_switch_to_hres kernel/time/hrtimer.c:738 [inline]
  hrtimer_run_queues+0x339/0x400 kernel/time/hrtimer.c:1745
  run_local_timers kernel/time/timer.c:1756 [inline]
  update_process_times+0xc0/0x200 kernel/time/timer.c:1781
  tick_periodic+0x79/0x230 kernel/time/tick-common.c:100
  tick_handle_periodic+0x41/0x120 
kernel/time/tick-common.c:112
  local_apic_timer_interrupt 
arch/x86/kernel/apic/apic.c:1085 [inline]
  __sysvec_apic_timer_interrupt+0x146/0x540 
arch/x86/kernel/apic/apic.c:1102
  asm_call_irq_on_stack+0xf/0x20
  __run_sysvec_on_irqstack 
arch/x86/include/asm/irq_stack.h:37 [inline]
  run_sysvec_on_irqstack_cond 
arch/x86/include/asm/irq_stack.h:89 [inline]
  sysvec_apic_timer_interrupt+0xbd/0x100 
arch/x86/kernel/apic/apic.c:1096
  asm_sysvec_apic_timer_interrupt+0x12/0x20 
arch/x86/include/asm/idtentry.h:628
  native_restore_fl arch/x86/include/asm/irqflags.h:41 
[inline]
  arch_local_irq_restore arch/x86/include/asm/irqflags.h:84 
[inline]
 

هل يمكنك مساعدتي

[Mrs. Cristina Campbell]

عزيزي الحبيب ،

يرجى قراءة هذا ببطء وبعناية ، فقد يكون أحد أهم رسائل البريد الإلكتروني
التي تتلقاها على الإطلاق ، أنا السيدة كريستينا كامبل ، كنت متزوجة من
الراحل إدوارد كامبل ، وكان يعمل في شركة شل لتطوير البترول بلندن وكان
أيضًا مقاول متمرس في منطقة شرق آسيا ، توفي يوم الاثنين 31 يوليو 2003
في باريس. تزوجنا لمدة سبع سنوات بدون طفل.

بينما تقرأ هذا ، لا أريدك أن تشعر بالأسف من أجلي ، لأنني أعتقد أن
الجميع سيموتون يومًا ما. لقد تم تشخيصي بسرطان المريء وأخبرني طبيبي
أنني لن أستمر طويلاً بسبب مشاكلي الصحية المعقدة.

أريد أن يرحمني الله ويقبل روحي ، لذلك قررت أن أعطي الصدقات للمنظمات
الخيرية / المساجد / المعابد البوذية / الكنائس / الأطفال بلا أم / أقل
امتيازًا ، أرامل لأنني أريد أن يكون هذا من آخر الأعمال الصالحة أفعل
على الأرض قبل أن أموت. لقد قمت حتى الآن بتوزيع الأموال على بعض
المنظمات الخيرية في فلسطين وكمبوديا وسويسرا والعراق. الآن وقد تدهورت
صحتي بشكل سيء للغاية ، لا يمكنني القيام بذلك بنفسي بعد الآن.

طلبت ذات مرة من أفراد عائلتي إغلاق أحد حساباتي وتوزيع الأموال التي
أملكها هناك على منظمة خيرية في الأردن والكويت وقطر والإمارات العربية
المتحدة والهند ، لكنهم رفضوا واحتفظوا بالمال لأنفسهم. لا تثق بهم بعد
الآن ، حيث يبدو أنهم لا ينازعون ما تركته لهم. آخر أموالي التي لا
يعرفها أحد هو الإيداع النقدي الضخم البالغ ستة ملايين دولار أمريكي
6،000،000.00 لديّ لدى بنك في تايلاند حيث أودعت الصندوق. أرغب في
استخدام هذا الصندوق للبرامج الخيرية ودعم الإنسانية في بلدك فقط إذا كنت
مخلصًا.

لقد اتخذت هذا القرار لأنه ليس لدي أي طفل يرث هذا المال ، ولا أخاف من
الموت ، ومن ثم أعرف إلى أين سأذهب ، وأعلم أنني سأكون في حضن الرب.
بمجرد أن أتلقى ردك ، سأعطيك الاتصال بالبنك وأصدر لك خطاب تفويض من شأنه
تمكينك بصفتك المستفيد الأصلي من هذا الصندوق لبدء هذا البرنامج الخيري
على الفور في بلدك.

أريدك أن تصلي دائمًا من أجلي ، أي تأخير في ردك سيمنحني مساحة في البحث
عن شخص آخر لنفس الغرض. إذا لم تكن مهتمًا ، فيرجى العفو عن تواصلك معنا.
يمكنك التواصل معي أو الرد على بريدي الإلكتروني الخاص:
(cristinacampe...@outlook.com).

شكر،
تفضلوا بقبول فائق الاحترام،
السيدة كريستينا كامبل
البريد الإلكتروني؛ cristinacampe...@outlook.com

Re: Re: Re: [PATCH] evm: Fix memleak in init_desc

[dinghao . liu]

> On Sun, Jan 10, 2021 at 01:27:09PM +0800, dinghao@zju.edu.cn wrote:
> > > On Sat, Jan 09, 2021 at 07:33:05PM +0800, Dinghao Liu wrote:
> > > > When kmalloc() fails, tmp_tfm allocated by
> > > > crypto_alloc_shash() has not been freed, which
> > > > leads to memleak.
> > > > 
> > > > Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
> > > > Signed-off-by: Dinghao Liu 
> > > > ---
> > > >  security/integrity/evm/evm_crypto.c | 9 +++--
> > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/security/integrity/evm/evm_crypto.c 
> > > > b/security/integrity/evm/evm_crypto.c
> > > > index 168c3b78ac47..39fb31a638ac 100644
> > > > --- a/security/integrity/evm/evm_crypto.c
> > > > +++ b/security/integrity/evm/evm_crypto.c
> > > > @@ -73,7 +73,7 @@ static struct shash_desc *init_desc(char type, 
> > > > uint8_t hash_algo)
> > > >  {
> > > > long rc;
> > > > const char *algo;
> > > > -   struct crypto_shash **tfm, *tmp_tfm;
> > > > +   struct crypto_shash **tfm, *tmp_tfm = NULL;
> > > > struct shash_desc *desc;
> > > >  
> > > > if (type == EVM_XATTR_HMAC) {
> > > > @@ -118,13 +118,18 @@ static struct shash_desc *init_desc(char type, 
> > > > uint8_t hash_algo)
> > > >  alloc:
> > > > desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
> > > > GFP_KERNEL);
> > > > -   if (!desc)
> > > > +   if (!desc) {
> > > > +   if (tmp_tfm)
> > > > +   crypto_free_shash(tmp_tfm);
> > > > return ERR_PTR(-ENOMEM);
> > > > +   }
> > > >  
> > > > desc->tfm = *tfm;
> > > >  
> > > > rc = crypto_shash_init(desc);
> > > > if (rc) {
> > > > +   if (tmp_tfm)
> > > > +   crypto_free_shash(tmp_tfm);
> > > > kfree(desc);
> > > > return ERR_PTR(rc);
> > > > }
> > > 
> > > There's no need to check for NULL before calling crypto_free_shash().
> > > 
> > 
> > I find there is a crypto_shash_tfm() in the definition of 
> > crypto_free_shash(). Will this lead to null pointer dereference
> > when we use it to free a NULL pointer?
> > 
> 
> No.  It does &tfm->base, not tfm->base.
> 

Thank you for your advice! I will resend a new patch soon.

Regards,
Dinghao

Re: Re: [PATCH] evm: Fix memleak in init_desc

[Eric Biggers]

On Sun, Jan 10, 2021 at 01:27:09PM +0800, dinghao@zju.edu.cn wrote:
> > On Sat, Jan 09, 2021 at 07:33:05PM +0800, Dinghao Liu wrote:
> > > When kmalloc() fails, tmp_tfm allocated by
> > > crypto_alloc_shash() has not been freed, which
> > > leads to memleak.
> > > 
> > > Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
> > > Signed-off-by: Dinghao Liu 
> > > ---
> > >  security/integrity/evm/evm_crypto.c | 9 +++--
> > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/security/integrity/evm/evm_crypto.c 
> > > b/security/integrity/evm/evm_crypto.c
> > > index 168c3b78ac47..39fb31a638ac 100644
> > > --- a/security/integrity/evm/evm_crypto.c
> > > +++ b/security/integrity/evm/evm_crypto.c
> > > @@ -73,7 +73,7 @@ static struct shash_desc *init_desc(char type, uint8_t 
> > > hash_algo)
> > >  {
> > >   long rc;
> > >   const char *algo;
> > > - struct crypto_shash **tfm, *tmp_tfm;
> > > + struct crypto_shash **tfm, *tmp_tfm = NULL;
> > >   struct shash_desc *desc;
> > >  
> > >   if (type == EVM_XATTR_HMAC) {
> > > @@ -118,13 +118,18 @@ static struct shash_desc *init_desc(char type, 
> > > uint8_t hash_algo)
> > >  alloc:
> > >   desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
> > >   GFP_KERNEL);
> > > - if (!desc)
> > > + if (!desc) {
> > > + if (tmp_tfm)
> > > + crypto_free_shash(tmp_tfm);
> > >   return ERR_PTR(-ENOMEM);
> > > + }
> > >  
> > >   desc->tfm = *tfm;
> > >  
> > >   rc = crypto_shash_init(desc);
> > >   if (rc) {
> > > + if (tmp_tfm)
> > > + crypto_free_shash(tmp_tfm);
> > >   kfree(desc);
> > >   return ERR_PTR(rc);
> > >   }
> > 
> > There's no need to check for NULL before calling crypto_free_shash().
> > 
> 
> I find there is a crypto_shash_tfm() in the definition of 
> crypto_free_shash(). Will this lead to null pointer dereference
> when we use it to free a NULL pointer?
> 

No.  It does &tfm->base, not tfm->base.

- Eric

Re: [PATCH] mlx5: vdpa: fix possible uninitialized var

[Eli Cohen]

On Fri, Jan 08, 2021 at 04:24:43PM +0800, Jason Wang wrote:
> Upstream: posted
> 
> When compiling with -Werror=maybe-uninitialized, gcc may complains the
> possible uninitialized umem. Fix that.
> 
> Signed-off-by: Jason Wang 
> ---
>  drivers/vdpa/mlx5/net/mlx5_vnet.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index f1d54814db97..a6ad83d8d8e2 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -706,6 +706,9 @@ static void umem_destroy(struct mlx5_vdpa_net *ndev, 
> struct mlx5_vdpa_virtqueue
>   case 3:
>   umem = &mvq->umem3;
>   break;
> + default:
> + WARN(1, "unsupported umem num %d\n", num);
> + return;
>   }
>  
>   MLX5_SET(destroy_umem_in, in, opcode, MLX5_CMD_OP_DESTROY_UMEM);

Since the "default" case will never be executed, maybe it's better to
just change "case 3:" to "default:" and avoid the WARN().

> -- 
> 2.25.1
> 

Re: [PATCH 3/4] Input: omap4-keypad - use PM runtime to check keys for errata

[Dmitry Torokhov]

Hi Tony,

On Wed, Jan 06, 2021 at 02:58:21PM +0200, Tony Lindgren wrote:
> @@ -301,6 +348,7 @@ static int omap4_keypad_probe(struct platform_device 
> *pdev)
>   }
>  
>   keypad_data->irq = irq;
> + mutex_init(&keypad_data->lock);
>  
>   error = omap4_keypad_parse_dt(&pdev->dev, keypad_data);
>   if (error)
> @@ -320,6 +368,8 @@ static int omap4_keypad_probe(struct platform_device 
> *pdev)
>   goto err_release_mem;
>   }
>  
> + pm_runtime_use_autosuspend(&pdev->dev);
> + pm_runtime_set_autosuspend_delay(&pdev->dev, OMAP4_KEYPAD_AUTOIDLE_MS);

This, and corresponding changes in open() and close() seem like a
separate improvement. Do you mind splitting them into a separate patch,
and have the missing key release fix go on top of it?

Thanks.

-- 
Dmitry

drivers/net/ethernet/cadence/macb_main.c:4661:14: warning: Either the condition 'macb_config' is redundant or there is possible null pointer dereference: macb_config.

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   996e435fd401de35df62ac943ab9402cfe85c430
commit: edac63861db72a462ccdfad0b5dfa66985d58bd5 net: macb: add userio bits as 
platform configuration
compiler: nios2-linux-gcc (GCC) 9.3.0

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


cppcheck possible warnings: (new ones prefixed by >>, may not real problems)

   drivers/net/ethernet/cadence/macb_main.c:2908:5: warning: %d in format 
string (no. 1) requires 'int' but the argument type is 'unsigned int'. 
[invalidPrintfArgType_sint]
   snprintf(stat_string, ETH_GSTRING_LEN, "q%d_%s",
   ^
>> drivers/net/ethernet/cadence/macb_main.c:4661:14: warning: Either the 
>> condition 'macb_config' is redundant or there is possible null pointer 
>> dereference: macb_config. [nullPointerRedundantCheck]
bp->usrio = macb_config->usrio;
^
   drivers/net/ethernet/cadence/macb_main.c:4646:6: note: Assuming that 
condition 'macb_config' is not redundant
if (macb_config)
^
   drivers/net/ethernet/cadence/macb_main.c:4661:14: note: Null pointer 
dereference
bp->usrio = macb_config->usrio;
^

vim +/macb_config +4661 drivers/net/ethernet/cadence/macb_main.c

83a77e9ec4150ee drivers/net/ethernet/cadence/macb.c  Bartosz Folta  
   2016-12-14  4573  
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4574  static int macb_probe(struct platform_device *pdev)
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4575  {
83a77e9ec4150ee drivers/net/ethernet/cadence/macb.c  Bartosz Folta  
   2016-12-14  4576 const struct macb_config *macb_config = 
&default_gem_config;
c69618b3e4f220f drivers/net/ethernet/cadence/macb.c  Nicolas Ferre  
   2015-03-31  4577 int (*clk_init)(struct platform_device *, 
struct clk **,
f5473d1d44e4b42 drivers/net/ethernet/cadence/macb_main.c Harini Katakam 
   2019-03-01  4578 struct clk **, struct clk **,  
struct clk **,
f5473d1d44e4b42 drivers/net/ethernet/cadence/macb_main.c Harini Katakam 
   2019-03-01  4579 struct clk **) = 
macb_config->clk_init;
83a77e9ec4150ee drivers/net/ethernet/cadence/macb.c  Bartosz Folta  
   2016-12-14  4580 int (*init)(struct platform_device *) = 
macb_config->init;
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4581 struct device_node *np = pdev->dev.of_node;
aead88bd0e99054 drivers/net/ethernet/cadence/macb.c  
shubhrajyoti.da...@xilinx.com 2016-08-16  4582 struct clk *pclk, *hclk 
= NULL, *tx_clk = NULL, *rx_clk = NULL;
f5473d1d44e4b42 drivers/net/ethernet/cadence/macb_main.c Harini Katakam 
   2019-03-01  4583 struct clk *tsu_clk = NULL;
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4584 unsigned int queue_mask, num_queues;
f2ce8a9e48385f4 drivers/net/ethernet/cadence/macb.c  Andy Shevchenko
   2015-07-24  4585 bool native_io;
0c65b2b90d13c1d drivers/net/ethernet/cadence/macb_main.c Andrew Lunn
   2019-11-04  4586 phy_interface_t interface;
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4587 struct net_device *dev;
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4588 struct resource *regs;
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4589 void __iomem *mem;
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4590 const char *mac;
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4591 struct macb *bp;
404cd086f29e867 drivers/net/ethernet/cadence/macb_main.c Harini Katakam 
   2018-07-06  4592 int err, val;
421d9df0628be16 drivers/net/ethernet/cadence/macb.c  Cyrille Pitchen
   2015-03-07  4593  
f2ce8a9e48385f4 drivers/net/ethernet/cadence/macb.c  Andy Shevchenko
   2015-07-24  4594 regs = platform_get_resource(pdev, 
IORESOURCE_MEM, 0);
f2ce8a9e48385f4 drivers/net/ethernet/cadence/macb.c  Andy Shevchenko
   2015-07-24  4595 mem = devm_ioremap_resource(&pdev->dev, regs);
f2ce8a9e48385f4 drivers/net/ethernet/cadence/macb.c  Andy Shevchenko
   2015-07-24  4596 if (IS_ERR(mem))
f2ce8a9e48385f4 drivers/net/ethernet/cadence/macb.c  Andy Shevchenko
   2015-07-24  4597 return PTR_ERR(mem);
f2ce8a9e48385f4 drivers/net/ethernet/cadence/macb.c  Andy Shevc

Re: [PATCH 4/4] Input: omap4-keypad - simplify probe with devm

[Dmitry Torokhov]

Hi Tony,

On Wed, Jan 06, 2021 at 02:58:22PM +0200, Tony Lindgren wrote:
>  static int omap4_keypad_remove(struct platform_device *pdev)
>  {
>   struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
> - struct resource *res;
>  
>   dev_pm_clear_wake_irq(&pdev->dev);
> -
> - free_irq(keypad_data->irq, keypad_data);
> -
>   pm_runtime_dont_use_autosuspend(&pdev->dev);
>   pm_runtime_disable(&pdev->dev);

I do not quite like that we need to keep this in remove(). I had the
patch below for quite some time, could you please try it?

Thanks!

-- 
Dmitry


Input: omap4-keypad - switch to use managed resources

From: Dmitry Torokhov 

Now that input core supports devres-managed input devices we can clean
up this driver a bit.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/keyboard/omap4-keypad.c |  139 +
 1 file changed, 55 insertions(+), 84 deletions(-)

diff --git a/drivers/input/keyboard/omap4-keypad.c 
b/drivers/input/keyboard/omap4-keypad.c
index b17ac2a295b9..d36774a55a10 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -252,8 +252,14 @@ static int omap4_keypad_check_revision(struct device *dev,
return 0;
 }
 
+static void omap4_disable_pm(void *d)
+{
+   pm_runtime_disable(d);
+}
+
 static int omap4_keypad_probe(struct platform_device *pdev)
 {
+   struct device *dev = &pdev->dev;
struct omap4_keypad *keypad_data;
struct input_dev *input_dev;
struct resource *res;
@@ -271,33 +277,30 @@ static int omap4_keypad_probe(struct platform_device 
*pdev)
if (irq < 0)
return irq;
 
-   keypad_data = kzalloc(sizeof(struct omap4_keypad), GFP_KERNEL);
+   keypad_data = devm_kzalloc(dev, sizeof(struct omap4_keypad),
+  GFP_KERNEL);
if (!keypad_data) {
-   dev_err(&pdev->dev, "keypad_data memory allocation failed\n");
+   dev_err(dev, "keypad_data memory allocation failed\n");
return -ENOMEM;
}
 
keypad_data->irq = irq;
 
-   error = omap4_keypad_parse_dt(&pdev->dev, keypad_data);
+   error = omap4_keypad_parse_dt(dev, keypad_data);
if (error)
-   goto err_free_keypad;
+   return error;
 
-   res = request_mem_region(res->start, resource_size(res), pdev->name);
-   if (!res) {
-   dev_err(&pdev->dev, "can't request mem region\n");
-   error = -EBUSY;
-   goto err_free_keypad;
-   }
+   keypad_data->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(keypad_data->base))
+   return PTR_ERR(keypad_data->base);
 
-   keypad_data->base = ioremap(res->start, resource_size(res));
-   if (!keypad_data->base) {
-   dev_err(&pdev->dev, "can't ioremap mem resource\n");
-   error = -ENOMEM;
-   goto err_release_mem;
-   }
+   pm_runtime_enable(dev);
 
-   pm_runtime_enable(&pdev->dev);
+   error = devm_add_action_or_reset(dev, omap4_disable_pm, dev);
+   if (error) {
+   dev_err(dev, "unable to register cleanup action\n");
+   return error;
+   }
 
/*
 * Enable clocks for the keypad module so that we can read
@@ -307,27 +310,26 @@ static int omap4_keypad_probe(struct platform_device 
*pdev)
if (error) {
dev_err(&pdev->dev, "pm_runtime_get_sync() failed\n");
pm_runtime_put_noidle(&pdev->dev);
-   } else {
-   error = omap4_keypad_check_revision(&pdev->dev,
-   keypad_data);
-   if (!error) {
-   /* Ensure device does not raise interrupts */
-   omap4_keypad_stop(keypad_data);
-   }
-   pm_runtime_put_sync(&pdev->dev);
+   return error;
+   }
+
+   error = omap4_keypad_check_revision(&pdev->dev,
+   keypad_data);
+   if (!error) {
+   /* Ensure device does not raise interrupts */
+   omap4_keypad_stop(keypad_data);
}
+
+   pm_runtime_put_sync(&pdev->dev);
if (error)
-   goto err_pm_disable;
+   return error;
 
/* input device allocation */
-   keypad_data->input = input_dev = input_allocate_device();
-   if (!input_dev) {
-   error = -ENOMEM;
-   goto err_pm_disable;
-   }
+   keypad_data->input = input_dev = devm_input_allocate_device(dev);
+   if (!input_dev)
+   return -ENOMEM;
 
input_dev->name = pdev->name;
-   input_dev->dev.parent = &pdev->dev;
input_dev->id.bustype = BUS_HOST;
input_dev->id.vendor = 0x0001;
input_dev->id.product = 0x0001;
@@ -344,84 +346,53 @@ static int omap4_keypad_probe(struct platform_device 
*pdev)
 
   

Re: Old platforms: bring out your dead

[Willy Tarreau]

On Sat, Jan 09, 2021 at 10:52:53PM +0100, Arnd Bergmann wrote:
(... i486 ...)
> As with the other older platforms, the main question to ask is:
> Are there users that are better off running a future LTS kernel on this
> hardware than the v5.10.y version or something older?

I think this is the most important part of the question. Because the
possible use case I've described actually doesn't correspond to a
"prod" machine but to a machine that's powered on every 5 years for
some old data recovery. In such a case users just start with an old
system (possibly the one that's still on them if present), and this
doesn't warrant an up-to-date OS.

Moreover, just as I experienced when maintaining 2.4, there's a point
where support for old stuff starts to break again by lack of testing.
And just because of this, users shouldn't always expect to see their
old machines boot fine on a recent kernel. Sometimes there may even be
difficulties setting up a compatible toolchain.

So actually the question shouldn't be "does anyone want such old
machines to still be supported" but "does anyone *need* them to be
supported". And I suspect that for most of them the response is "no",
it's just a convenience.

Just my two cents,
Willy

Re: [PATCH 2/2] dt-bindings: ts: goodix: Add binding for GT9286 IC

[Dmitry Torokhov]

On Sat, Jan 09, 2021 at 02:55:12PM +0100, AngeloGioacchino Del Regno wrote:
> Support for this chip was added to the goodix driver: add the
> DT binding for it.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 

Applied, thank you.

-- 
Dmitry

Re: [PATCH 1/2] input: goodix: Add support for Goodix GT9286 chip

[Dmitry Torokhov]

On Sat, Jan 09, 2021 at 02:55:11PM +0100, AngeloGioacchino Del Regno wrote:
> The Goodix GT9286 is a capacitive touch sensor IC based on GT1x.
> 
> This chip can be found on a number of smartphones, including the
> F(x)tec Pro 1 and the Elephone U.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 

Applied, thank you.

-- 
Dmitry

Re: [PATCH 0/2] Add support for Goodix GT9286 chip

[Dmitry Torokhov]

On Sat, Jan 09, 2021 at 03:37:40PM +0100, Bastien Nocera wrote:
> On Sat, 2021-01-09 at 14:55 +0100, AngeloGioacchino Del Regno wrote:
> > Add support for the GT9286 chip, tested on F(x)Tec Pro1 (MSM8998).
> 
> Can you please add this test information to the commit message for the
> goodix.c patch?
> 
> Feel free to add my:
> Reviewed-by: Bastien Nocera 
> to both patches when you send a v2.

I added this to the patch by hand, there is no need to submit v2.

Thanks.

-- 
Dmitry

Re: Expense of read_iter

[Matthew Wilcox]

On Thu, Jan 07, 2021 at 01:59:01PM -0500, Mikulas Patocka wrote:
> On Thu, 7 Jan 2021, Matthew Wilcox wrote:
> > On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote:
> > > I'd like to ask about this piece of code in __kernel_read:
> > >   if (unlikely(!file->f_op->read_iter || file->f_op->read))
> > >   return warn_unsupported...
> > > and __kernel_write:
> > >   if (unlikely(!file->f_op->write_iter || file->f_op->write))
> > >   return warn_unsupported...
> > > 
> > > - It exits with an error if both read_iter and read or write_iter and 
> > > write are present.
> > > 
> > > I found out that on NVFS, reading a file with the read method has 10% 
> > > better performance than the read_iter method. The benchmark just reads 
> > > the 
> > > same 4k page over and over again - and the cost of creating and parsing 
> > > the kiocb and iov_iter structures is just that high.
> > 
> > Which part of it is so expensive?
> 
> The read_iter path is much bigger:
> vfs_read  - 0x160 bytes
> new_sync_read - 0x160 bytes
> nvfs_rw_iter  - 0x100 bytes
> nvfs_rw_iter_locked   - 0x4a0 bytes
> iov_iter_advance  - 0x300 bytes

Number of bytes in a function isn't really correlated with how expensive
a particular function is.  That said, looking at new_sync_read() shows
one part that's particularly bad, init_sync_kiocb():

static inline int iocb_flags(struct file *file)
{
int res = 0;
if (file->f_flags & O_APPEND)
res |= IOCB_APPEND;
 7ec:   8b 57 40mov0x40(%rdi),%edx
 7ef:   48 89 75 80 mov%rsi,-0x80(%rbp)
if (file->f_flags & O_DIRECT)
 7f3:   89 d0   mov%edx,%eax
 7f5:   c1 e8 06shr$0x6,%eax
 7f8:   83 e0 10and$0x10,%eax
res |= IOCB_DIRECT;
if ((file->f_flags & O_DSYNC) || IS_SYNC(file->f_mapping->host))
 7fb:   89 c1   mov%eax,%ecx
 7fd:   81 c9 00 00 02 00   or $0x2,%ecx
 803:   f6 c6 40test   $0x40,%dh
 806:   0f 45 c1cmovne %ecx,%eax
res |= IOCB_DSYNC;
 809:   f6 c6 10test   $0x10,%dh
 80c:   75 18   jne826 
 80e:   48 8b 8f d8 00 00 00mov0xd8(%rdi),%rcx
 815:   48 8b 09mov(%rcx),%rcx
 818:   48 8b 71 28 mov0x28(%rcx),%rsi
 81c:   f6 46 50 10 testb  $0x10,0x50(%rsi)
 820:   0f 84 e2 00 00 00   je 908 
if (file->f_flags & __O_SYNC)
 826:   83 c8 02or $0x2,%eax
res |= IOCB_SYNC;
return res;
 829:   89 c1   mov%eax,%ecx
 82b:   83 c9 04or $0x4,%ecx
 82e:   81 e2 00 00 10 00   and$0x10,%edx

We could optimise this by, eg, checking for (__O_SYNC | O_DIRECT |
O_APPEND) and returning 0 if none of them are set, since they're all
pretty rare.  It might be better to maintain an f_iocb_flags in the
struct file and just copy that unconditionally.  We'd need to remember
to update it in fcntl(F_SETFL), but I think that's the only place.


> If we go with the "read" method, there's just:
> vfs_read  - 0x160 bytes
> nvfs_read - 0x200 bytes
> 
> > Is it worth, eg adding an iov_iter
> > type that points to a single buffer instead of a single-member iov?

>  6.57%  pread[nvfs][k] nvfs_rw_iter_locked
>  2.31%  pread[kernel.vmlinux]  [k] new_sync_read
>  1.89%  pread[kernel.vmlinux]  [k] iov_iter_advance
>  1.24%  pread[nvfs][k] nvfs_rw_iter
>  0.29%  pread[kernel.vmlinux]  [k] iov_iter_init

>  2.71%  pread[nvfs][k] nvfs_read

> Note that if we sum the percentage of nvfs_iter_locked, new_sync_read, 
> iov_iter_advance, nvfs_rw_iter, we get 12.01%. On the other hand, in the 
> second trace, nvfs_read consumes just 2.71% - and it replaces 
> functionality of all these functions.
> 
> That is the reason for that 10% degradation with read_iter.

You seem to be focusing on your argument for "let's just permit
filesystems to implement both ->read and ->read_iter".  My suggestion
is that we need to optimise the ->read_iter path, but to do that we need
to know what's expensive.

nvfs_rw_iter_locked() looks very complicated.  I suspect it can
be simplified.  Of course new_sync_read() needs to be improved too,
as do the other functions here, but fully a third of the difference
between read() and read_iter() is the difference between nvfs_read()
and nvfs_rw_iter_locked().

[PATCH v4 1/2] misc: pvpanic: introduce device capability

[zhenwei pi]

According to pvpanic spec:
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt

The guest should determine pvpanic capability by RDPT, so initialize
capability during device probing. There is no need to register panic
notifier callback function if no events supported.

Before sending event to host side, check capability firstly.

Suggested by Greg KH, use sysfs to expose capability to user space,
also add new sysfs attribute in document.

Signed-off-by: zhenwei pi 
---
 .../ABI/testing/sysfs-bus-pci-devices-pvpanic |  7 
 drivers/misc/pvpanic.c| 33 ---
 2 files changed, 35 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic 
b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
new file mode 100644
index ..57d014a2c339
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
@@ -0,0 +1,7 @@
+What:  /sys/devices/pci:00/*/QEMU0001:00/capability
+Date:  Jan 2021
+Contact:   zhenwei pi 
+Description:
+   Read-only attribute. Capabilities of pvpanic device
+   which are supported by QEMU.
+   Format: %s.
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index 951b37da5e3c..c2f6a9e866b3 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -19,6 +19,22 @@
 #include 
 
 static void __iomem *base;
+static unsigned int capability = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
+
+static ssize_t capability_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "%s%s",
+   capability & PVPANIC_PANICKED ? "PANICKED[BIT 0]\n" : "",
+   capability & PVPANIC_CRASH_LOADED ? "CRASH_LOADED[BIT 1]\n" : 
"");
+}
+static DEVICE_ATTR_RO(capability);
+
+static struct attribute *pvpanic_dev_attrs[] = {
+   &dev_attr_capability.attr,
+   NULL
+};
+ATTRIBUTE_GROUPS(pvpanic_dev);
 
 MODULE_AUTHOR("Hu Tao ");
 MODULE_DESCRIPTION("pvpanic device driver");
@@ -27,7 +43,8 @@ MODULE_LICENSE("GPL");
 static void
 pvpanic_send_event(unsigned int event)
 {
-   iowrite8(event, base);
+   if (event & capability)
+   iowrite8(event, base);
 }
 
 static int
@@ -62,8 +79,12 @@ static int pvpanic_mmio_probe(struct platform_device *pdev)
if (IS_ERR(base))
return PTR_ERR(base);
 
-   atomic_notifier_chain_register(&panic_notifier_list,
-  &pvpanic_panic_nb);
+   /* initlize capability by RDPT */
+   capability &= ioread8(base);
+
+   if (capability)
+   atomic_notifier_chain_register(&panic_notifier_list,
+  &pvpanic_panic_nb);
 
return 0;
 }
@@ -71,8 +92,9 @@ static int pvpanic_mmio_probe(struct platform_device *pdev)
 static int pvpanic_mmio_remove(struct platform_device *pdev)
 {
 
-   atomic_notifier_chain_unregister(&panic_notifier_list,
-&pvpanic_panic_nb);
+   if (capability)
+   atomic_notifier_chain_unregister(&panic_notifier_list,
+&pvpanic_panic_nb);
 
return 0;
 }
@@ -93,6 +115,7 @@ static struct platform_driver pvpanic_mmio_driver = {
.name = "pvpanic-mmio",
.of_match_table = pvpanic_mmio_match,
.acpi_match_table = pvpanic_device_ids,
+   .dev_groups = pvpanic_dev_groups,
},
.probe = pvpanic_mmio_probe,
.remove = pvpanic_mmio_remove,
-- 
2.25.1

[PATCH v4 2/2] misc: pvpanic: introduce events device attribue

[zhenwei pi]

Suggested by Paolo & Greg, add 'events' device attribute that can be
used to limit which capabilities the driver uses.

Finally, the pvpanic guest driver works by the limitation of both
device capability and user setting.

Signed-off-by: zhenwei pi 
---
 .../ABI/testing/sysfs-bus-pci-devices-pvpanic |  7 +
 drivers/misc/pvpanic.c| 26 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic 
b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
index 57d014a2c339..4750cfa0af2b 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
@@ -5,3 +5,10 @@ Description:
Read-only attribute. Capabilities of pvpanic device
which are supported by QEMU.
Format: %s.
+
+What:  /sys/devices/pci:00/*/QEMU0001:00/events
+Date:  Jan 2021
+Contact:   zhenwei pi 
+Description:
+   RW attribute. Set/get which features in-use.
+   Format: %x.
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index c2f6a9e866b3..07a008e15bd2 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -19,8 +19,31 @@
 #include 
 
 static void __iomem *base;
+static unsigned int events = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
 static unsigned int capability = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
 
+static ssize_t events_show(struct device *dev,  struct device_attribute *attr, 
char *buf)
+{
+   return sprintf(buf, "%x\n", events);
+}
+
+static ssize_t events_store(struct device *dev,  struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   unsigned int tmp;
+   int err;
+
+   err = kstrtouint(buf, 16, &tmp);
+   if (err)
+   return err;
+
+   events = tmp;
+
+   return count;
+
+}
+static DEVICE_ATTR_RW(events);
+
 static ssize_t capability_show(struct device *dev,
   struct device_attribute *attr, char *buf)
 {
@@ -32,6 +55,7 @@ static DEVICE_ATTR_RO(capability);
 
 static struct attribute *pvpanic_dev_attrs[] = {
&dev_attr_capability.attr,
+   &dev_attr_events.attr,
NULL
 };
 ATTRIBUTE_GROUPS(pvpanic_dev);
@@ -43,7 +67,7 @@ MODULE_LICENSE("GPL");
 static void
 pvpanic_send_event(unsigned int event)
 {
-   if (event & capability)
+   if (event & capability & events)
iowrite8(event, base);
 }
 
-- 
2.25.1

[PATCH v4 0/2] misc: pvpanic: introduce capability & event attribute

[zhenwei pi]

v3 -> v4:
Use event sysfs attribute instead of module parameter.
Use driver dev_groups instead of creating files by sysfs_* API.

v2 -> v3:
Seperate the function to 2 parts:
1, use sysfs to expose device capability.
2, add a module parameter to set limitation by user.

v1 -> v2:
Remove device info log, use module parameter to expose capability.

v1:
The guest sides determines pvpanic capability by RDPT, before kicking
host side, check the event is supported or not.

zhenwei pi (2):
  misc: pvpanic: introduce device capability
  misc: pvpanic: introduce module parameter 'events'

 .../ABI/testing/sysfs-bus-pci-devices-pvpanic | 14 +
 drivers/misc/pvpanic.c| 58 +--
 2 files changed, 67 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic

-- 
2.25.1

[PATCH] arm64: Kconfig: Increase NR_CPUS default to 512

[vanshikonda]

From: Vanshidhar Konda 

Increase the default value of NR_CPUS to 512 from 256. This will
enable the defconfig kernel to support platforms that have upto
512 cores.

Signed-off-by: Vanshidhar Konda 
---
 arch/arm64/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 05e17351e4f3..23fbbf413f58 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -983,7 +983,7 @@ config SCHED_SMT
 config NR_CPUS
int "Maximum number of CPUs (2-4096)"
range 2 4096
-   default "256"
+   default "512"
 
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
-- 
2.29.2

drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:1855:42: warning: Uninitialized variable: fw_ver

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2ff90100ace886895e4fbb2850b8d5e49d931ed6
commit: 57430471e2fa60a412e220fa3014567e792aaa6f drm/amdgpu: Add support for 
USBC PD FW download
date:   10 months ago
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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


"cppcheck warnings: (new ones prefixed by >>)"
>> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:1855:42: warning: Uninitialized 
>> variable: fw_ver [uninitvar]
return snprintf(buf, PAGE_SIZE, "%xn", fw_ver);
^

vim +1855 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

  1836  
  1837  static ssize_t psp_usbc_pd_fw_sysfs_read(struct device *dev,
  1838   struct device_attribute *attr,
  1839   char *buf)
  1840  {
  1841  struct drm_device *ddev = dev_get_drvdata(dev);
  1842  struct amdgpu_device *adev = ddev->dev_private;
  1843  uint32_t fw_ver;
  1844  int ret;
  1845  
  1846  mutex_lock(&adev->psp.mutex);
  1847  ret = psp_read_usbc_pd_fw(&adev->psp, &fw_ver);
  1848  mutex_unlock(&adev->psp.mutex);
  1849  
  1850  if (ret) {
  1851  DRM_ERROR("Failed to read USBC PD FW, err = %d", ret);
  1852  return ret;
  1853  }
  1854  
> 1855  return snprintf(buf, PAGE_SIZE, "%x\n", fw_ver);
  1856  }
  1857  

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

Re: Re: [PATCH] evm: Fix memleak in init_desc

[dinghao . liu]

> On Sat, Jan 09, 2021 at 07:33:05PM +0800, Dinghao Liu wrote:
> > When kmalloc() fails, tmp_tfm allocated by
> > crypto_alloc_shash() has not been freed, which
> > leads to memleak.
> > 
> > Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
> > Signed-off-by: Dinghao Liu 
> > ---
> >  security/integrity/evm/evm_crypto.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/security/integrity/evm/evm_crypto.c 
> > b/security/integrity/evm/evm_crypto.c
> > index 168c3b78ac47..39fb31a638ac 100644
> > --- a/security/integrity/evm/evm_crypto.c
> > +++ b/security/integrity/evm/evm_crypto.c
> > @@ -73,7 +73,7 @@ static struct shash_desc *init_desc(char type, uint8_t 
> > hash_algo)
> >  {
> > long rc;
> > const char *algo;
> > -   struct crypto_shash **tfm, *tmp_tfm;
> > +   struct crypto_shash **tfm, *tmp_tfm = NULL;
> > struct shash_desc *desc;
> >  
> > if (type == EVM_XATTR_HMAC) {
> > @@ -118,13 +118,18 @@ static struct shash_desc *init_desc(char type, 
> > uint8_t hash_algo)
> >  alloc:
> > desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
> > GFP_KERNEL);
> > -   if (!desc)
> > +   if (!desc) {
> > +   if (tmp_tfm)
> > +   crypto_free_shash(tmp_tfm);
> > return ERR_PTR(-ENOMEM);
> > +   }
> >  
> > desc->tfm = *tfm;
> >  
> > rc = crypto_shash_init(desc);
> > if (rc) {
> > +   if (tmp_tfm)
> > +   crypto_free_shash(tmp_tfm);
> > kfree(desc);
> > return ERR_PTR(rc);
> > }
> 
> There's no need to check for NULL before calling crypto_free_shash().
> 

I find there is a crypto_shash_tfm() in the definition of 
crypto_free_shash(). Will this lead to null pointer dereference
when we use it to free a NULL pointer?

Regards,
Dinghao

Re: linux-next: Signed-off-by missing for commit in the rcu tree

[Paul E. McKenney]

On Sun, Jan 10, 2021 at 01:24:32PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Commit
> 
>   cffdc9c7c24c ("EXP sched: Print list of runnable tasks in the current rq")
> 
> is missing a Signed-off-by from its author.
> 
> Paul, remember the rules for -next:
> 
> You will need to ensure that the patches/commits in your tree/series have
> been:
>  * submitted under GPL v2 (or later) and include the Contributor's
> Signed-off-by,
>  * posted to the relevant mailing list,
>  * reviewed by you (or another maintainer of your subsystem tree),
>  * successfully unit tested, and 
>  * destined for the current or next Linux merge window.
> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.

Please accept my apologies for my messing this up.

Valentin, may I apply your Signed-off-by?  Otherwise, I am liable to
again get it into -next where it is not yet ready to go.  But without it,
rcutorture gets noise from 12e08bc4d ("sched/hotplug: Consolidate task
migration on CPU unplug") that is otherwise difficult to diagnose.  :-/

Thanx, Paul

Re: [PATCH v2 0/5] Enable root to update the blacklist keyring

[Jarkko Sakkinen]

On Tue, Jan 05, 2021 at 11:12:57AM +0100, Mickaël Salaün wrote:
> Jarkko, David, what is the status of this patch series? Do you need help
> to test it?

Hi, a leave/vacation and the holiday period badly mixed my schedules.

I'm testing this upcoming week.

/Jarkko

RE: [PATCH v8 04/20] dlb: add device ioctl layer and first three ioctls

[Chen, Mike Ximing]

> -Original Message-
> From: Greg KH 
> Sent: Saturday, January 9, 2021 3:34 AM
> To: Chen, Mike Ximing 
> Cc: linux-kernel@vger.kernel.org; a...@arndb.de; Williams, Dan J
> ; pierre-louis.boss...@linux.intel.com
> Subject: Re: [PATCH v8 04/20] dlb: add device ioctl layer and first three 
> ioctls
> 
> On Sat, Jan 09, 2021 at 07:49:24AM +, Chen, Mike Ximing wrote:
> > > > +static int dlb_ioctl_arg_size[NUM_DLB_CMD] = {
> > > > +   sizeof(struct dlb_get_device_version_args),
> > > > +   sizeof(struct dlb_create_sched_domain_args),
> > > > +   sizeof(struct dlb_get_num_resources_args)
> > >
> > > That list.
> > >
> > > Ugh, no.  that's no way to write maintainable code that you will be able
> > > to understand in 2 years.
> > >
> >
> > dlb_ioctl() was implemented with switch-case and real function calls 
> > previously.
> > We changed to the table/list implementation during a code restructure. I 
> > will move
> > back to the old implementation.
> 
> Who said to change this?  And why did they say that?  Please go back to
> those developers and point them at this thread so that doesn't happen
> again...
> 

It was my fault:(. Will  make sure it doesn't happen again.

> 
> > > > +#define DLB_DEVICE_VERSION(x) (((x) >> 8) & 0xFF)
> > > > +#define DLB_DEVICE_REVISION(x) ((x) & 0xFF)
> > > > +
> > > > +enum dlb_revisions {
> > > > +   DLB_REV_A0 = 0,
> > >
> > > What is a "revision" and why do you care about it?
> >
> > This is for different revisions of hardware. Each revision of hardware may 
> > have a
> slight different configuration/feature.
> 
> So what does this mean?  What are you going to do based on it?
> 
For now, it is primarily informational to user. Different HW revision may have 
different features enabled. For example,  certain features may not be available 
in the earlier revision A0 and A1, but are enabled in  the later revisions (B0, 
C0, etc). User applications that depends on these features may fail on A0/A1 
devices. They can check the device revision/version to confirm that the failure 
is expected. Users can also implement workarounds to avoid failures. 

Thanks
Mike

[PATCH V3] mtd: rawnand: qcom: update last code word register

[Md Sadre Alam]

>From QPIC version 2.0 onwards new register got added to
read last codeword. This change will update the same.

For first three code word READ_LOCATION_n register will be
use.For last code word READ_LOCATION_LAST_CW_n register will be
use.

Signed-off-by: Md Sadre Alam 
---
[V3]
 * Added else condition for last code word in update_rw_regs().
 drivers/mtd/nand/raw/qcom_nandc.c | 84 ---
 1 file changed, 70 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
b/drivers/mtd/nand/raw/qcom_nandc.c
index 667e4bf..50ff6e3 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -48,6 +48,10 @@
 #defineNAND_READ_LOCATION_10xf24
 #defineNAND_READ_LOCATION_20xf28
 #defineNAND_READ_LOCATION_30xf2c
+#defineNAND_READ_LOCATION_LAST_CW_00xf40
+#defineNAND_READ_LOCATION_LAST_CW_10xf44
+#defineNAND_READ_LOCATION_LAST_CW_20xf48
+#defineNAND_READ_LOCATION_LAST_CW_30xf4c
 
 /* dummy register offsets, used by write_reg_dma */
 #defineNAND_DEV_CMD1_RESTORE   0xdead
@@ -187,6 +191,12 @@ nandc_set_reg(nandc, NAND_READ_LOCATION_##reg, 
\
  ((size) << READ_LOCATION_SIZE) |  \
  ((is_last) << READ_LOCATION_LAST))
 
+#define nandc_set_read_loc_last(nandc, reg, offset, size, is_last) \
+nandc_set_reg(nandc, NAND_READ_LOCATION_LAST_CW_##reg, \
+ ((offset) << READ_LOCATION_OFFSET) |  \
+ ((size) << READ_LOCATION_SIZE) |  \
+ ((is_last) << READ_LOCATION_LAST))
+
 /*
  * Returns the actual register address for all NAND_DEV_ registers
  * (i.e. NAND_DEV_CMD0, NAND_DEV_CMD1, NAND_DEV_CMD2 and NAND_DEV_CMD_VLD)
@@ -316,6 +326,10 @@ struct nandc_regs {
__le32 read_location1;
__le32 read_location2;
__le32 read_location3;
+   __le32 read_location_last0;
+   __le32 read_location_last1;
+   __le32 read_location_last2;
+   __le32 read_location_last3;
 
__le32 erased_cw_detect_cfg_clr;
__le32 erased_cw_detect_cfg_set;
@@ -644,6 +658,14 @@ static __le32 *offset_to_nandc_reg(struct nandc_regs 
*regs, int offset)
return ®s->read_location2;
case NAND_READ_LOCATION_3:
return ®s->read_location3;
+   case NAND_READ_LOCATION_LAST_CW_0:
+   return ®s->read_location_last0;
+   case NAND_READ_LOCATION_LAST_CW_1:
+   return ®s->read_location_last1;
+   case NAND_READ_LOCATION_LAST_CW_2:
+   return ®s->read_location_last2;
+   case NAND_READ_LOCATION_LAST_CW_3:
+   return ®s->read_location_last3;
default:
return NULL;
}
@@ -719,9 +741,14 @@ static void update_rw_regs(struct qcom_nand_host *host, 
int num_cw, bool read)
nandc_set_reg(nandc, NAND_READ_STATUS, host->clrreadstatus);
nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
 
-   if (read)
-   nandc_set_read_loc(nandc, 0, 0, host->use_ecc ?
-  host->cw_data : host->cw_size, 1);
+   if (read) {
+   if (nandc->props->qpic_v2)
+   nandc_set_read_loc_last(nandc, 0, 0, host->use_ecc ?
+   host->cw_data : host->cw_size, 1);
+   else
+   nandc_set_read_loc(nandc, 0, 0, host->use_ecc ?
+   host->cw_data : host->cw_size, 1);
+   }
 }
 
 /*
@@ -1096,9 +1123,13 @@ static void config_nand_page_read(struct 
qcom_nand_controller *nandc)
 static void
 config_nand_cw_read(struct qcom_nand_controller *nandc, bool use_ecc)
 {
-   if (nandc->props->is_bam)
+   if (nandc->props->is_bam) {
+   if (nandc->props->qpic_v2)
+   write_reg_dma(nandc, NAND_READ_LOCATION_LAST_CW_0,
+ 1, NAND_BAM_NEXT_SGL);
write_reg_dma(nandc, NAND_READ_LOCATION_0, 4,
  NAND_BAM_NEXT_SGL);
+   }
 
write_reg_dma(nandc, NAND_FLASH_CMD, 1, NAND_BAM_NEXT_SGL);
write_reg_dma(nandc, NAND_EXEC_CMD, 1, NAND_BAM_NEXT_SGL);
@@ -1633,16 +1664,28 @@ qcom_nandc_read_cw_raw(struct mtd_info *mtd, struct 
nand_chip *chip,
}
 
if (nandc->props->is_bam) {
-   nandc_set_read_loc(nandc, 0, read_loc, data_size1, 0);
+   if (nandc->props->qpic_v2 && cw == (ecc->steps - 1))
+   nandc_set_read_loc_last(nandc, 0, read_loc, data_size1, 
0);
+   else
+   nandc_set_read_loc(nandc, 0, read_loc, data_size1, 0);
read_loc += data_size1;
 
-   nandc_set_read_loc(nandc, 1, read_loc, oob_size1, 0);
+   if (nandc->props->qpic_v2 && cw == (ecc->steps - 1))
+   nan

[PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
As the official wiki page puts it, "E for Ethernets".

It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
a power-only USB type-C port, a 3.5mm headphone jack for audio output,
two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
and PoE header.

The board comes in multiple configurations, differing in the amount of
onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
can all share the same device tree.

The USB 2.0 OTG controller is available on the 40-pin header. This is
not enabled in the device tree, since it is possible to use it in a
host-only configuration, or in OTG mode with an extra pin from the
header as the ID pin.

The device tree is based on the one of the Rock64, with various parts
modified to match the ROCK Pi E, and some parts updated to newer styles,
such as the gmac2io node's mdio sub-node.

Add a new device tree file for the new board.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm64/boot/dts/rockchip/Makefile |   1 +
 .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
 2 files changed, 370 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 622d320ddd13..62d3abc17a24 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
new file mode 100644
index ..7818d2e8180c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -0,0 +1,369 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * (C) Copyright 2020 Chen-Yu Tsai 
+ *
+ * Based on ./rk3328-rock64.dts, which is
+ *
+ * Copyright (c) 2017 PINE64
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include "rk3328.dtsi"
+
+/ {
+   model = "Radxa ROCK Pi E";
+   compatible = "radxa,rockpi-e", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-0 = <&led_pin>;
+   pinctrl-names = "default";
+
+   led-0 {
+   /* schematic say green but the actual thing is blue */
+   color = ;
+   gpios = <&gpio3 RK_PA5 GPIO_ACTIVE_LOW>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc0m1_pin>;
+   regulator-boot-on;
+   regulator-name = "vcc_sd";
+   vin-supply = <&vcc_io>;
+   };
+
+   vcc_host_5v: vcc-host-5v-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio3 RK_PA7 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb30_host_drv>;
+   enable-active-high;
+   regulator-name = "vcc_host_5v";
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <&vcc_sys>;
+   };
+
+   vcc_sys: vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc_wifi: vcc-wifi-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_en>;
+   regulator-name = "vcc_wifi";
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <&vcc_io>;
+   };
+};
+
+&analog_sound {
+   status = "okay";
+};
+
+&code

[PATCH 1/3] arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The gmac2phy is integrated with the PHY within the SoC. Any properties
related to this integration can be included in the .dtsi file, instead
of having board dts files specify them separately.

Add the clock_in_out property to specify the direction of the PHY clock.
This is the minimum required to have gmac2phy working on Linux. Other
examples include assigned-clocks, assigned-clock-rates, and
assigned-clock-parents properties, but the hardware default plus the
implementation requesting the appropriate clock rate also works.

Fixes: 9c4cc910fe28 ("ARM64: dts: rockchip: Add gmac2phy node support for 
rk3328")
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index db0d5c8e5f96..93c734d8a46c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -928,6 +928,7 @@ gmac2phy: ethernet@ff55 {
phy-mode = "rmii";
phy-handle = <&phy>;
snps,txpbl = <0x4>;
+   clock_in_out = "output";
status = "disabled";
 
mdio {
-- 
2.29.2

Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse

[Linus Torvalds]

On Sat, Jan 9, 2021 at 6:51 PM Andrea Arcangeli  wrote:
>
> I just don't see the simplification coming from
> 09854ba94c6aad7886996bfbee2530b3d8a7f4f4. Instead of checking
> page_mapcount above as an optimization, to me it looks much simpler to
> check it in a single place, in do_wp_page, that in addition of
> optimizing away the superfluous copy, would optimize away the above
> complexity as well.

Here's the difference:

 (a) in COW, "page_mapcount()" is pure and utter garbage, and has zero meaning.

Why? Because MAPCOUNT DOES NOT MATTER FOR COW.

COW is about "I'm about to write to this page, and that means I need
an _exclusive_ page so that I don't write to a page that somebody else
is using".

Can you admit that fundamental fact?

Notice how "page_mapcount()" has absolutely NOTHING to do with
"exclusive page". There are lots of other ways the page can be used
aside from mapcount. The page cache may have a reference to the page.
Somebody that did a GUP may have a reference to the page.

So what actually matters at COW time? The only thing that matters is
"am I the exclusive owner". And guess what? We have a count of page
references. It's "page_count()". That's *EXACTLY* the thing that says
"are there maybe other references to this page".

In other words, COW needs to use page_count(). It really is that easy.
End of story.

So, given that, why do I then do

> + if (page_mapcount(page) != 1)
> + return false;

in my patch, when I just told you that "page_mapcount()" is irrelevant for COW?

Guess what? The above isn't about COW. The above isn't about whether
we need to do a copy in order to be able to write to the page without
anybody else being affected by it.

No, at fork time, and at this clear_refs time, the question is
entirely different. The question is not "Do I have exclusive access to
the page", but it is "Did I _already_ made sure that I have exclusive
access to the page because I pinned it"?

See how different the question is?

Because *if* you have done a pinned COW for soem direct-IO read, and
*if* that page is dirty, then you know it's mapped only in your
address space. You're basically doing the _reverse_ of the COW test,
and asking yourself "is this my own private pinned page"?

And then it's actually perfectly sane to do a check that says
"obviously, if somebody else has this page mapped, then that's not the
case".

See?

For COW, "page_mapcount()" is pure and utter garbage, and entirely
meaningless. How many places it's mapped in doesn't matter. You may
have to COW even if it's only mapped in your address space (page
cache, GUP, whatever).

But for "did I already make this exclusive", then it's actually
meaningful to say "is it mapped somewhere else". We know it has other
users - that "page_may_be_pinned()" in fact *guarantees* that it has
other users. But we're double-checking that the other users aren't
other mappings.

That said, I did just realize that that "page_mapcount()" check is
actually pointless.

Because we do have a simpler one. Instead of checking whether all
those references that made us go "page_might_be_pinned()" aren't other
mappings, the simple check for "pte_writable()" would already have
told us that we had already done the COW.

So you are actually right that the page_mapcount() test in my patch is
not the best way to check for this. By the time we see
"page_may_be_pinned()", we might as well just say "Oh, it's a private
mapping and the pte is already writable, so we know we were the
exclusive mapper, because COW and fork() already guarantee that".

> And I won't comment if it's actually safe to skip random pages or
> not. All I know is for mprotect and uffd-wp, definitely the above
> approach wouldn't work.

Why do you say that?

You say ":definitely know", but I think you're full of it.

The fact is, if you have a pinned page, why wouldn't we say "you can't
turn it read-only"?

It's pinned in the VM address space - and it's pinned writable. Simple
and clear semantics. You can *remove* it, but you can't change the
pinning.

  Linus

[PATCH 0/3] arm64: rockchip: rk3328: Add Radxa ROCK Pi E

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This series adds support for the Radxa ROCK Pi E. This is a router
oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page
puts it, "E for Ethernets".

It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
a power-only USB type-C port, a 3.5mm headphone jack for audio output,
two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
and PoE header.

The board comes in multiple configurations, differing in the amount of
onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
can all share the same device tree. Currently, the 802.11ac chip
lacks an in-kernel driver.

The USB 2.0 OTG controller is available on the 40-pin header. This is
not enabled in the device tree, since it is possible to use it in a
host-only configuration, or in OTG mode with an extra pin from the
header as the ID pin.

The device tree is based on the one of the Rock64, with various parts
modified to match the ROCK Pi E, and some parts updated to newer styles,
such as the gmac2io node's mdio sub-node.

Patch 1 adds the clock_in_out property to the gmac2phy node. This would
always have the same setting for gmac2phy, which uses an integrated PHY
in RMII mode. Having this set by default makes enabling gmac2phy at the
board level simpler.

Patch 2 adds a compatible string for this board to the list of Rockchip
based devices.

Patch 3 adds a device tree file for this board. This is based on the
one for the Rock64, with many modifications to adapt it to the new
board, as well as style updates.

Please have a look.


Regards
ChenYu

Chen-Yu Tsai (3):
  arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy
node
  dt-bindings: arm: rockchip: Add Radxa ROCK Pi E
  arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E

 .../devicetree/bindings/arm/rockchip.yaml |   5 +
 arch/arm64/boot/dts/rockchip/Makefile |   1 +
 .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
 arch/arm64/boot/dts/rockchip/rk3328.dtsi  |   1 +
 4 files changed, 376 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts

-- 
2.29.2

[PATCH 2/3] dt-bindings: arm: rockchip: Add Radxa ROCK Pi E

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
As the official wiki page puts it, "E for Ethernets".

It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
a power-only USB type-C port, a 3.5mm headphone jack for audio output,
two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
and PoE header.

The board comes in multiple configurations, differing in the amount of
onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
can all share the same device tree.

The USB 2.0 OTG controller is available on the 40-pin header. This is
not enabled in the device tree, since it is possible to use it in a
host-only configuration, or in OTG mode with an extra pin from the
header as the ID pin.

The device tree is based on the one of the Rock64, with various parts
modified to match the ROCK Pi E, and some parts updated to newer styles,
such as the gmac2io node's mdio sub-node.

Add a compatible string for the new board.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 773fd4c531ed..c3036f95c7bc 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -468,6 +468,11 @@ properties:
   - const: radxa,rockpi4
   - const: rockchip,rk3399
 
+  - description: Radxa ROCK Pi E
+items:
+  - const: radxa,rockpi-e
+  - const: rockchip,rk3328
+
   - description: Radxa ROCK Pi N8
 items:
   - const: radxa,rockpi-n8
-- 
2.29.2

Re: [PATCH] mtd: rawnand: qcom: update last code word register

[mdalam]

On 2021-01-05 21:15, Manivannan Sadhasivam wrote:

On Tue, Jan 05, 2021 at 12:24:45AM +0530, mda...@codeaurora.org wrote:

On 2020-12-31 16:23, Manivannan Sadhasivam wrote:
> On Thu, Dec 17, 2020 at 07:32:56PM +0530, Md Sadre Alam wrote:
> > From QPIC version 2.0 onwards new register got added to
> > read last codeword. This change will update the same.
> >
> > For first three code word READ_LOCATION_n register will be
> > use.For last code wrod READ_LOCATION_LAST_CW_n register will be
> > use.
> >
> > Signed-off-by: Md Sadre Alam 
> > ---
> >  drivers/mtd/nand/raw/qcom_nandc.c | 79
> > +--
> >  1 file changed, 67 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
> > b/drivers/mtd/nand/raw/qcom_nandc.c
> > index 667e4bf..eaef51d 100644
> > --- a/drivers/mtd/nand/raw/qcom_nandc.c
> > +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> > @@ -48,6 +48,10 @@
> >  #define  NAND_READ_LOCATION_10xf24
> >  #define  NAND_READ_LOCATION_20xf28
> >  #define  NAND_READ_LOCATION_30xf2c
> > +#define NAND_READ_LOCATION_LAST_CW_00xf40
> > +#define NAND_READ_LOCATION_LAST_CW_10xf44
> > +#define NAND_READ_LOCATION_LAST_CW_20xf48
> > +#define NAND_READ_LOCATION_LAST_CW_30xf4c
>
> Please keep the alignment as before.
>
 Fixed alignment in V2 patch
> >
> >  /* dummy register offsets, used by write_reg_dma */
> >  #define  NAND_DEV_CMD1_RESTORE   0xdead
> > @@ -187,6 +191,12 @@ nandc_set_reg(nandc,
> > NAND_READ_LOCATION_##reg, \
> > ((size) << READ_LOCATION_SIZE) |\
> > ((is_last) << READ_LOCATION_LAST))
> >
> > +#define nandc_set_read_loc_last(nandc, reg, offset, size, is_last)   \
> > +nandc_set_reg(nandc, NAND_READ_LOCATION_LAST_CW_##reg, 
  \
> > +   ((offset) << READ_LOCATION_OFFSET) |\
> > +   ((size) << READ_LOCATION_SIZE) |\
> > +   ((is_last) << READ_LOCATION_LAST))
> > +
> >  /*
> >   * Returns the actual register address for all NAND_DEV_ registers
> >   * (i.e. NAND_DEV_CMD0, NAND_DEV_CMD1, NAND_DEV_CMD2 and
> > NAND_DEV_CMD_VLD)
> > @@ -316,6 +326,10 @@ struct nandc_regs {
> >   __le32 read_location1;
> >   __le32 read_location2;
> >   __le32 read_location3;
> > + __le32 read_location_last0;
> > + __le32 read_location_last1;
> > + __le32 read_location_last2;
> > + __le32 read_location_last3;
> >
> >   __le32 erased_cw_detect_cfg_clr;
> >   __le32 erased_cw_detect_cfg_set;
> > @@ -644,6 +658,14 @@ static __le32 *offset_to_nandc_reg(struct
> > nandc_regs *regs, int offset)
> >   return ®s->read_location2;
> >   case NAND_READ_LOCATION_3:
> >   return ®s->read_location3;
> > + case NAND_READ_LOCATION_LAST_CW_0:
> > + return ®s->read_location_last0;
> > + case NAND_READ_LOCATION_LAST_CW_1:
> > + return ®s->read_location_last1;
> > + case NAND_READ_LOCATION_LAST_CW_2:
> > + return ®s->read_location_last2;
> > + case NAND_READ_LOCATION_LAST_CW_3:
> > + return ®s->read_location_last3;
> >   default:
> >   return NULL;
> >   }
> > @@ -719,9 +741,13 @@ static void update_rw_regs(struct
> > qcom_nand_host *host, int num_cw, bool read)
> >   nandc_set_reg(nandc, NAND_READ_STATUS, host->clrreadstatus);
> >   nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
> >
> > - if (read)
> > + if (read) {
> > + if (nandc->props->qpic_v2)
> > + nandc_set_read_loc_last(nandc, 0, 0, host->use_ecc ?
> > + host->cw_data : host->cw_size, 1);
>
> Forgot to add else? Otherwise both NAND_READ_LOCATION_n and
> NAND_READ_LOCATION_LAST_CW_n
> will be used.

  Here else is not needed , because to read last code word we need to
configure
  NAND_READ_LOCATION_LAST_CW_n register. Any way here we are doing 
only

register configuration.
  for all the code words. Earlier version of QPIC we were using
nandc_set_read_loc()
  for all the code words, but in qpic V2 onwards for last code word we 
have

to use
  NAND_READ_LOCATION_LAST_CW_n register. So configuring here the same.



nandc_set_read_loc() has the last argument "is_last". This is used to 
convey
whether we need to set READ_LOCATION_LAST bit or not. This is fine for 
QPIC
IP < 2, but for >=2 we need to use nandc_set_read_loc_last() only. My 
point
is why do you need to still use nandc_set_read_loc() here for QPIC v2? 
That's

why I asked you about using else().


  Got it. I fixed this in V3 patch.


>
> >   nandc_set_read_loc(nandc, 0, 0, host->use_ecc ?
> >  host->cw_data : host->cw_size, 1);
> > + }
> >  }
> >
> >  /*
> > @@ -1096,9 +1122,13 @@ static void config_nand_page_read(struct
> > qcom_nand_controller *nandc)
> >  static void
> >  config_nand_cw

WARNING in qrtr_tun_write_iter

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:6207214a Merge tag 'afs-fixes-04012021' of git://git.kerne..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12b600cf50
kernel config:  https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
dashboard link: https://syzkaller.appspot.com/bug?extid=c2a7e5c5211605a90865
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=169c0d0b50
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=152fe7a8d0

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

[ cut here ]
WARNING: CPU: 1 PID: 8469 at mm/page_alloc.c:4976 
__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5011
Modules linked in:
CPU: 0 PID: 8469 Comm: syz-executor105 Not tainted 5.11.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4976
Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00 
48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89 
74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8
RSP: 0018:c900013efb70 EFLAGS: 00010246
RAX:  RBX: 19200027df72 RCX: 
RDX:  RSI: dc00 RDI: 00040dc0
RBP: 00040dc0 R08:  R09: 
R10: 81b1f7f1 R11:  R12: 0012
R13: 0012 R14:  R15: 2020
FS:  02127880() GS:8880b9f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2000 CR3: 27766000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267
 alloc_pages include/linux/gfp.h:547 [inline]
 kmalloc_order+0x2e/0xb0 mm/slab_common.c:837
 kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853
 kmalloc include/linux/slab.h:557 [inline]
 kzalloc include/linux/slab.h:682 [inline]
 qrtr_tun_write_iter+0x8a/0x180 net/qrtr/tun.c:83
 call_write_iter include/linux/fs.h:1901 [inline]
 new_sync_write+0x426/0x650 fs/read_write.c:518
 vfs_write+0x791/0xa30 fs/read_write.c:605
 ksys_write+0x12d/0x250 fs/read_write.c:658
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440279
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffc5f1b8358 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 004002c8 RCX: 00440279
RDX: 2020 RSI: 2000 RDI: 0003
RBP: 006ca018 R08:  R09: 004002c8
R10:  R11: 0246 R12: 00401a80
R13: 00401b10 R14:  R15: 


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

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

Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse

[Andrea Arcangeli]

On Sat, Jan 09, 2021 at 05:37:09PM -0800, Linus Torvalds wrote:
> On Sat, Jan 9, 2021 at 5:19 PM Linus Torvalds
>  wrote:
> >
> > And no, I didn't make the UFFDIO_WRITEPROTECT code take the mmap_sem
> > for writing. For whoever wants to look at that, it's
> > mwriteprotect_range() in mm/userfaultfd.c and the fix is literally to
> > turn the read-lock (and unlock) into a write-lock (and unlock).
> 
> Oh, and if it wasn't obvious, we'll have to debate what to do with
> trying to mprotect() a pinned page. Do we just ignore the pinned page
> (the way my clear_refs patch did)? Or do we turn it into -EBUSY? Or
> what?

Agreed, I assume mprotect would have the same effect.

mprotect in parallel of a read or recvmgs may be undefined, so I
didn't bring it up, but it was pretty clear.

The moment the write bit is cleared (no matter why and from who) and
the PG lock relased, if there's any GUP pin, GUP currently loses
synchrony.

In any case I intended to help exercising the new page_count logic
with the testcase, possibly to make it behave better somehow, no
matter how.

I admit I'm also wondering myself the exact semantics of O_DIRECT on
clear_refs or uffd-wp tracking, but the point is that losing reads and
getting unexpected data in the page, still doesn't look a good
behavior and it had to be at least checked.

To me ultimately the useful use case that is become impossible with
page_count isn't even clear_refs nor uffd-wp.

The useful case that I can see zero fundamental flaws in it, is a RDMA
or some other device computing in pure readonly DMA on the data while
a program runs normally and produces it. It could be even a
framebuffer that doesn't care about coherency. You may want to
occasionally wrprotect the memory under readonly long term GUP pin for
consistency even against bugs of the program itself. Why should
wrprotecting make the device lose synchrony? And kind of performance
we gain to the normal useful cases by breaking the special case? Is
there a benchmark showing it?

> So it's not *just* the locking that needs to be fixed. But just take a
> look at that suggested clear_refs patch of mine - it sure isn't
> complicated.

If we can skip the wrprotection it's fairly easy, I fully agree, even
then it still looks more difficult than using page_mapcount in
do_wp_page in my view, so I also don't see the simplification. And
overall the amount of kernel code had a net increase as result.

Thanks,
Andrea

Re: [External] Re: [PATCH v3 2/2] misc: pvpanic: introduce module parameter 'events'

[zhenwei pi]

On 1/9/21 7:31 PM, Greg KH wrote:

On Fri, Jan 08, 2021 at 04:26:17PM +0100, Paolo Bonzini wrote:

On 08/01/21 16:15, Greg KH wrote:

On Fri, Jan 08, 2021 at 04:04:24PM +0100, Paolo Bonzini wrote:

On 08/01/21 15:07, Greg KH wrote:

static void __iomem *base;
+static unsigned int events = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
+module_param(events, uint, 0644);
+MODULE_PARM_DESC(events, "set event limitation of pvpanic device");

I do not understand you wanting a module parameter as well as a sysfs
file.  Why is this needed?  Why are you spreading this information out
across different apis and locations?


It can be useful to disable some functionality, for example in case you want
to fake running on an older virtualization host.  This can be done for
debugging reasons, or to keep uniform handling across a fleet that is
running different versions of QEMU.


And where is this all going to be documented?


I don't disagree.


And what's wrong with just making the sysfs attribute writable?


Isn't it harder to configure it at boot?  Also the sysfs attribute added by
patch 1 is documenting what is supported by the device, while the module
parameter can be set to any value (you can think of the module parameter as
of a "what to log" option, except the logging happens on another machine).


But the module parameter is global, and not device specific.

And yes, it would be harder to configure this at boot, is this something
that is required?  If so, please document that somewhere.


Therefore, if you make the sysfs attribute writable, you would actually need
_two_ attributes, one for the in-use capabilities and one for the device
capabilities.  And sysfs files are runtime values, which is different
concept than 0444 module parameters (which are more like just
configuration).


That's not the module parameter mode setting in this patch :(


So you would have to decide whether it's valid to write 2
to the in-use capabilities file when the device capabilities are "1", and I
don't really have a good answer for that.

Also considering that there will not be more than one copy of this device
(it doesn't make sense as they would all do exactly the same thing), in this
case a module parameter really seems to be the simplest way to configure it.


So you never can have more than one of these in the system at one time?
Because if this ever becomes not true, the module parameter is a mess...

thanks,

greg k-h



What about adding _two_ device attribute:
capability (0444): detect from device which the hypervisor really supports.

events (0644): root user could enable/disable feature(s) from guest side.

--
zhenwei pi

Re: [PATCH 1/1] mm: restore full accuracy in COW page reuse

[Andrea Arcangeli]

Hello,

On Sat, Jan 09, 2021 at 07:44:35PM -0500, Andrea Arcangeli wrote:
> allowing a child to corrupt memory in the parent. That's a problem
> that could happen not-maliciously too. So the scenario described

I updated the above partly quoted sentence since in the previous
version it didn't have full accuracy:

https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git/commit/?id=fc5a76b1c14e5e6cdc64ece306fc03773662d98a

"However since a single transient GUP pin on a tail page, would elevate
the page_count for all other tail pages (unlike the mapcount which is
subpage granular), the COW page reuse inaccuracy would then cross
different vmas and the effect would happen at a distance in vma of
different processes. A single GUP pin taken on a subpage mapped in a
different process could trigger 511 false positive COWs copies in the
local process, after a fork()."

This a best effort to try to document all side effects, but it'd be
great to hear from Kirill too on the above detail to have
confirmation.

Thanks and have a great weekend everyone,
Andrea

Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse

[Andrea Arcangeli]

Hello Linus,

On Sat, Jan 09, 2021 at 05:19:51PM -0800, Linus Torvalds wrote:
> +#define is_cow_mapping(flags) (((flags) & (VM_SHARED | VM_MAYWRITE)) == 
> VM_MAYWRITE)
> +
> +static inline bool pte_is_pinned(struct vm_area_struct *vma, unsigned long 
> addr, pte_t pte)
> +{
> + struct page *page;
> +
> + if (!is_cow_mapping(vma->vm_flags))
> + return false;
> + if (likely(!atomic_read(&vma->vm_mm->has_pinned)))
> + return false;
> + page = vm_normal_page(vma, addr, pte);
> + if (!page)
> + return false;
> + if (page_mapcount(page) != 1)
> + return false;
> + return page_maybe_dma_pinned(page);
> +}

I just don't see the simplification coming from
09854ba94c6aad7886996bfbee2530b3d8a7f4f4. Instead of checking
page_mapcount above as an optimization, to me it looks much simpler to
check it in a single place, in do_wp_page, that in addition of
optimizing away the superfluous copy, would optimize away the above
complexity as well.

And I won't comment if it's actually safe to skip random pages or
not. All I know is for mprotect and uffd-wp, definitely the above
approach wouldn't work.

In addition I dislike has_pinned and FOLL_PIN.

has_pinned450 include/linux/mm_types.h   * for instance during 
page table copying for fork().
has_pinned   1021 kernel/fork.c atomic64_set(&mm->pinned_vm, 0);
has_pinned   1239 mm/gup.c  atomic_set(&mm->has_pinned, 1);
has_pinned   2579 mm/gup.c  
atomic_set(¤t->mm->has_pinned, 1);
has_pinned   1099 mm/huge_memory.c   
atomic_read(&src_mm->has_pinned) &&
has_pinned   1213 mm/huge_memory.c   
atomic_read(&src_mm->has_pinned) &&
has_pinned819 mm/memory.c   if 
(likely(!atomic_read(&src_mm->has_pinned)))

Are we spending 32bit in mm_struct atomic_t just to call atomic_set(1)
on it? Why isn't it a MMF_HAS_PINNED that already can be set
atomically under mmap_read_lock too? There's bit left free there, we
didn't run out yet to justify wasting another 31 bits. I hope I'm
overlooking something.

The existence of FOLL_LONGTERM is good and makes a difference at times
for writeback if it's on a MAP_SHARED, or it makes difference during
GUP to do a page_migrate before taking the pin, but for the whole rest
of the VM it's irrelevant if it's long or short term, so I'm also
concerned from what Jason mentioned about long term pins being treated
differently within the VM. That to me looks fundamentally as flawed as
introducing inaccuracies in do_wp_page, that even ignoring the
performance implications caused by the inaccuracy, simply prevent to
do some useful things.

I obviously agree all common workloads with no GUP pins and no
clear_refs and no uffd, are way more important to be optimal, but I
haven't seen a single benchmark showing the benefit of not taking the
PG_lock before a page copy or any other runtime benefit coming from
page_count in do_wp_page.

To the contrary now I see additional branches in fork and in various
other paths.

The only thing again where I see page_count provides a tangible
benefit, is the vmsplice attack from child to parent, but that has not
been fully fixed and if page_count is added to fix it in all COW
faults, it'll introduce extra inefficiency to the the very common
important workloads, not only to the special GUP/clear_refs/uffd-wp
workloads as your patch above shows.

Thanks,
Andrea

linux-next: Signed-off-by missing for commit in the rcu tree

[Stephen Rothwell]

Hi all,

Commit

  cffdc9c7c24c ("EXP sched: Print list of runnable tasks in the current rq")

is missing a Signed-off-by from its author.

Paul, remember the rules for -next:

You will need to ensure that the patches/commits in your tree/series have
been:
 * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
 * posted to the relevant mailing list,
 * reviewed by you (or another maintainer of your subsystem tree),
 * successfully unit tested, and 
 * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell


pgpXz95bI8xAy.pgp
Description: OpenPGP digital signature

linux-next: Fixes tag needs some work in the nfs tree

[Stephen Rothwell]

Hi all,

In commit

  2cc8aca9d547 ("NFS: Adjust fs_context error logging")

Fixes tag

  Fixes: Fixes: ce8866f0913f ("NFS: Attach supplementary error information to 
fs_context.")

has these problem(s):

  - No SHA1 recognised

See duplicate "Fixes: " :-(

-- 
Cheers,
Stephen Rothwell


pgpu4yzV19dBc.pgp
Description: OpenPGP digital signature

Re: [PATCH v4] driver core: Fix device link device name collision

[Michael Walle]

Am 2021-01-09 23:45, schrieb Saravana Kannan:

The device link device's name was of the form:
--

This can cause name collision as reported here [1] as device names are
not globally unique. Since device names have to be unique within the
bus/class, add the bus/class name as a prefix to the device names used 
to

construct the device link device name.

So the devuce link device's name will be of the form:
:--:

[1] - 
https://lore.kernel.org/lkml/20201229033440.32142-1-mich...@walle.cc/


Cc: sta...@vger.kernel.org
Fixes: 287905e68dd2 ("driver core: Expose device link details in 
sysfs")

Reported-by: Michael Walle 
Signed-off-by: Saravana Kannan 


Tested-by: Michael Walle 

Thanks!

-michael

Re: [PATCH 2/3] soc: mediatek: pm-domains: Add domain regulator supply

[Nicolas Boichat]

On Thu, Jan 7, 2021 at 6:49 PM Hsin-Yi Wang  wrote:
>
> Some power domains (eg. mfg) needs to turn on power supply before power
> on.
>
> Signed-off-by: Hsin-Yi Wang 

Reviewed-by: Nicolas Boichat 

> ---
>  drivers/soc/mediatek/mt8183-pm-domains.h |  1 +
>  drivers/soc/mediatek/mtk-pm-domains.c| 36 +++-
>  drivers/soc/mediatek/mtk-pm-domains.h|  1 +
>  3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mt8183-pm-domains.h 
> b/drivers/soc/mediatek/mt8183-pm-domains.h
> index 8d996c5d2682d..aa5230e6c12f8 100644
> --- a/drivers/soc/mediatek/mt8183-pm-domains.h
> +++ b/drivers/soc/mediatek/mt8183-pm-domains.h
> @@ -38,6 +38,7 @@ static const struct scpsys_domain_data 
> scpsys_domain_data_mt8183[] = {
> .ctl_offs = 0x0338,
> .sram_pdn_bits = GENMASK(8, 8),
> .sram_pdn_ack_bits = GENMASK(12, 12),
> +   .caps = MTK_SCPD_DOMAIN_SUPPLY,
> },
> [MT8183_POWER_DOMAIN_MFG_CORE0] = {
> .sta_mask = BIT(7),
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
> b/drivers/soc/mediatek/mtk-pm-domains.c
> index fb70cb3b07b36..ae255aa7b1a97 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.c
> +++ b/drivers/soc/mediatek/mtk-pm-domains.c
[snip]
> @@ -275,6 +295,7 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
> *scpsys, struct device_no
>  {
> const struct scpsys_domain_data *domain_data;
> struct scpsys_domain *pd;
> +   struct device_node *np = scpsys->dev->of_node;
> struct property *prop;
> const char *clk_name;
> int i, ret, num_clks;
> @@ -307,6 +328,19 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
> *scpsys, struct device_no
> pd->data = domain_data;
> pd->scpsys = scpsys;
>
> +   if (MTK_SCPD_CAPS(pd, MTK_SCPD_DOMAIN_SUPPLY)) {
> +   /* Find regulator in current power domain node */
> +   scpsys->dev->of_node = node;
> +   pd->supply = devm_regulator_get(scpsys->dev, "domain");
> +   scpsys->dev->of_node = np;

This pattern is a bit strange to me. But Hsin-Yi pointed out that
there are precedents:
https://elixir.bootlin.com/linux/v5.11-rc2/source/drivers/iio/adc/rcar-gyroadc.c#L397
.

> +   if (IS_ERR(pd->supply)) {
> +   dev_err_probe(scpsys->dev, PTR_ERR(pd->supply),
> + "%pOF: failed to get power supply.\n",
> + node);
> +   return ERR_CAST(pd->supply);
> +   }
> +   }
> +
> pd->infracfg = syscon_regmap_lookup_by_phandle_optional(node, 
> "mediatek,infracfg");
> if (IS_ERR(pd->infracfg))
> return ERR_CAST(pd->infracfg);
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
> b/drivers/soc/mediatek/mtk-pm-domains.h
> index a2f4d8f97e058..b2770b5266dba 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.h
> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
> @@ -7,6 +7,7 @@
>  #define MTK_SCPD_FWAIT_SRAMBIT(1)
>  #define MTK_SCPD_SRAM_ISO  BIT(2)
>  #define MTK_SCPD_KEEP_DEFAULT_OFF  BIT(3)
> +#define MTK_SCPD_DOMAIN_SUPPLY BIT(4)
>  #define MTK_SCPD_CAPS(_scpd, _x)   ((_scpd)->data->caps & (_x))
>
>  #define SPM_VDE_PWR_CON0x0210
> --
> 2.29.2.729.g45daf8777d-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH] fpga: dfl: fme: Constify static attribute_group structs

[Tom Rix]

On 1/9/21 2:52 PM, Rikard Falkeborn wrote:
> On Sat, Jan 09, 2021 at 01:55:13PM -0800, Tom Rix wrote:
>> On 1/8/21 3:54 PM, Rikard Falkeborn wrote:
>>> The only usage of these is to put their addresses in arrays of pointers
>>> to const attribute_groups. Make them const to allow the compiler to put
>>> them in read-only memory.
>>>
>>> Signed-off-by: Rikard Falkeborn 
>>> ---
>>>  drivers/fpga/dfl-fme-perf.c | 6 +++---
>> This looks ok.
>>
>> There are other 'static struct's in drivers/fpga.
>>
>> Why is the change limited to this file ?
>>
>> Tom
>>
> I have a WIP coccinelle script to constify static struct attribute_group
> and this is the only file in drivers/fpga which has non-const struct
> attribute_group, that's why it's limited to this file. I could have
> mentioned that in the commit message.

No worries, thanks for the change!

Reviewed-by: Tom Rix 

> Rikard
>
>
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
>>> index 531266287eee..4299145ef347 100644
>>> --- a/drivers/fpga/dfl-fme-perf.c
>>> +++ b/drivers/fpga/dfl-fme-perf.c
>>> @@ -192,7 +192,7 @@ static struct attribute *fme_perf_cpumask_attrs[] = {
>>> NULL,
>>>  };
>>>  
>>> -static struct attribute_group fme_perf_cpumask_group = {
>>> +static const struct attribute_group fme_perf_cpumask_group = {
>>> .attrs = fme_perf_cpumask_attrs,
>>>  };
>>>  
>>> @@ -225,7 +225,7 @@ static struct attribute *fme_perf_format_attrs[] = {
>>> NULL,
>>>  };
>>>  
>>> -static struct attribute_group fme_perf_format_group = {
>>> +static const struct attribute_group fme_perf_format_group = {
>>> .name = "format",
>>> .attrs = fme_perf_format_attrs,
>>>  };
>>> @@ -239,7 +239,7 @@ static struct attribute *fme_perf_events_attrs_empty[] 
>>> = {
>>> NULL,
>>>  };
>>>  
>>> -static struct attribute_group fme_perf_events_group = {
>>> +static const struct attribute_group fme_perf_events_group = {
>>> .name = "events",
>>> .attrs = fme_perf_events_attrs_empty,
>>>  };

Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse

[Linus Torvalds]

On Sat, Jan 9, 2021 at 5:19 PM Linus Torvalds
 wrote:
>
> And no, I didn't make the UFFDIO_WRITEPROTECT code take the mmap_sem
> for writing. For whoever wants to look at that, it's
> mwriteprotect_range() in mm/userfaultfd.c and the fix is literally to
> turn the read-lock (and unlock) into a write-lock (and unlock).

Oh, and if it wasn't obvious, we'll have to debate what to do with
trying to mprotect() a pinned page. Do we just ignore the pinned page
(the way my clear_refs patch did)? Or do we turn it into -EBUSY? Or
what?

So it's not *just* the locking that needs to be fixed. But just take a
look at that suggested clear_refs patch of mine - it sure isn't
complicated.

  Linus

Re: depmod fixes for linux-stable releases

[Linus Torvalds]

Ack, I think 436e980e2ed5 ("kbuild: don't hardcode depmod path") is
stable material even if it doesn't fix a bug.

Not only does the fix for that commit not make sense without the
commit in the first place, but any environment that sets depmod
somewhere else might well be an environment that still wants stable
kernels.

It may not be the traditional case, but there's little reason for the
kernel build to force that /sbin/depmod location.

   Linus

Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse

[Linus Torvalds]

On Sat, Jan 9, 2021 at 4:55 PM Linus Torvalds
 wrote:
>
> What part of "clear_refs is the _least_ important of the three cases"
> are you not willing to understand?

In fact, I couldn't even turn on that code with my normal config,
because it depends on CONFIG_CHECKPOINT_RESTORE that I didn't even
have enabled.

IOW, that code is some special-case stuff, and instead of messing up
the rest of the VM, it should be made to conform to all the normal VM
rules and requirements.

Here's two patches to basically start doing that.

The first one is the same one I already sent out earlier, fixing the
locking. And yes, it can be improved upon, but before improving on it,
let's _fix_ the code.

The second is a trivial "oh, look, I can see that the page is pinned,
soft-dirty cannot work so don't do it then". Again, it can be improved
upon, most particularly by doing the same (simple) tests for the
hugepage case too, which I didn't do.

Note: I have not a single actual user of this code that I can test
with, so this is all ENTIRELY untested.

IOW, I am in no way claiming that these patches are perfect and
correct, and the only way to do things.

But what I _am_ claiming is that this clear_refs code (and the UFFD
code) is of secondary importance, and instead of messing up the core
VM, we should fix these special cases to not do bad things.

It really is that simple.

And no, I didn't make the UFFDIO_WRITEPROTECT code take the mmap_sem
for writing. For whoever wants to look at that, it's
mwriteprotect_range() in mm/userfaultfd.c and the fix is literally to
turn the read-lock (and unlock) into a write-lock (and unlock).

   Linus
From dacb5de62b654f1f5df1147e263b5b4e5fe2af44 Mon Sep 17 00:00:00 2001
From: Linus Torvalds 
Date: Fri, 8 Jan 2021 13:13:41 -0800
Subject: [PATCH 1/2] mm: fix clear_refs_write locking

Turning page table entries read-only requires the mmap_sem held for
writing.

So stop doing the odd games with turning things from read locks to write
locks and back.  Just get the write lock.

Signed-off-by: Linus Torvalds 
---
 fs/proc/task_mmu.c | 32 +---
 1 file changed, 9 insertions(+), 23 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ee5a235b3056..ab7d700b2caa 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1215,41 +1215,26 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf,
 			.type = type,
 		};
 
+		if (mmap_write_lock_killable(mm)) {
+			count = -EINTR;
+			goto out_mm;
+		}
 		if (type == CLEAR_REFS_MM_HIWATER_RSS) {
-			if (mmap_write_lock_killable(mm)) {
-count = -EINTR;
-goto out_mm;
-			}
-
 			/*
 			 * Writing 5 to /proc/pid/clear_refs resets the peak
 			 * resident set size to this mm's current rss value.
 			 */
 			reset_mm_hiwater_rss(mm);
-			mmap_write_unlock(mm);
-			goto out_mm;
+			goto out_unlock;
 		}
 
-		if (mmap_read_lock_killable(mm)) {
-			count = -EINTR;
-			goto out_mm;
-		}
 		tlb_gather_mmu(&tlb, mm, 0, -1);
 		if (type == CLEAR_REFS_SOFT_DIRTY) {
 			for (vma = mm->mmap; vma; vma = vma->vm_next) {
 if (!(vma->vm_flags & VM_SOFTDIRTY))
 	continue;
-mmap_read_unlock(mm);
-if (mmap_write_lock_killable(mm)) {
-	count = -EINTR;
-	goto out_mm;
-}
-for (vma = mm->mmap; vma; vma = vma->vm_next) {
-	vma->vm_flags &= ~VM_SOFTDIRTY;
-	vma_set_page_prot(vma);
-}
-mmap_write_downgrade(mm);
-break;
+vma->vm_flags &= ~VM_SOFTDIRTY;
+vma_set_page_prot(vma);
 			}
 
 			mmu_notifier_range_init(&range, MMU_NOTIFY_SOFT_DIRTY,
@@ -1261,7 +1246,8 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf,
 		if (type == CLEAR_REFS_SOFT_DIRTY)
 			mmu_notifier_invalidate_range_end(&range);
 		tlb_finish_mmu(&tlb, 0, -1);
-		mmap_read_unlock(mm);
+out_unlock:
+		mmap_write_unlock(mm);
 out_mm:
 		mmput(mm);
 	}
-- 
2.29.2.157.g1d47791a39

From b40950b647509f7222e1f7174d61045d15f56f1c Mon Sep 17 00:00:00 2001
From: Linus Torvalds 
Date: Sat, 9 Jan 2021 17:09:10 -0800
Subject: [PATCH 2/2] mm: don't play games with pinned pages in clear_page_refs

Turnign a pinned page read-only breaks the pinning after COW. Don't do it.

The whole "track page soft dirty" state doesn't work with pinned pages
anyway, since the page might be dirtied by the pinning entity without
ever being noticed in the page tables.

Signed-off-by: Linus Torvalds 
---
 fs/proc/task_mmu.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ab7d700b2caa..0377081021b7 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1035,6 +1035,25 @@ struct clear_refs_private {
 };
 
 #ifdef CONFIG_MEM_SOFT_DIRTY
+
+#define is_cow_mapping(flags) (((flags) & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE)
+
+static inline bool pte_is_pinned(struct vm_area_struct *vma, unsigned long addr, pte_t pte)
+{
+	struct page *page;
+
+	if (!is_cow_mapping(vma->vm_flags))
+		return false;
+	if (likely(!atomi

depmod fixes for linux-stable releases

[Sedat Dilek]

Hi,

I was CCed on the "depmod: handle the case of /sbin/depmod without
/sbin in PATH" changes to linux-stable releases.

Do you mind also pushing...?

commit 436e980e2ed526832de822cbf13c317a458b78e1
kbuild: don't hardcode depmod path

That was the origin for the depmod follow-up.

Thanks.

Regards,
- Sedat -

[1] https://git.kernel.org/linus/436e980e2ed526832de822cbf13c317a458b78e1

Re: [BUG mips llvm] MIPS: malformed R_MIPS_{HI16,LO16} with LLVM

[Alexander Lobakin]

From: Alexander Lobakin 
Date: Sat, 09 Jan 2021 23:29:26 +

> From: Alexander Lobakin 
> Date: Sat, 09 Jan 2021 19:15:31 +
>
>> From: Nick Desaulniers 
>> Date: Sat, 9 Jan 2021 09:50:44 -0800
>>
>>> On Sat, Jan 9, 2021 at 9:11 AM Alexander Lobakin  wrote:

 Machine: MIPS32 R2 Big Endian (interAptiv (multi))

 While testing MIPS with LLVM, I found a weird and very rare bug with
 MIPS relocs that LLVM emits into kernel modules. It happens on both
 11.0.0 and latest git snapshot and applies, as I can see, only to
 references to static symbols.

 When the kernel loads the module, it allocates a space for every
 section and then manually apply the relocations relative to the
 new address.

 Let's say we have a function phy_probe() in drivers/net/phy/libphy.ko.
 It's static and referenced only in phy_register_driver(), where it's
 used to fill callback pointer in a structure.

 The real function address after module loading is 0xc06c1444, that
 is observed in its ELF st_value field.
 There are two relocs related to this usage in phy_register_driver():

 R_MIPS_HI16 refers to 0x3c01
 R_MIPS_LO16 refers to 0x24339444

 The address of .text is 0xc06b8000. So the destination is calculated
 as follows:

 0x from hi16;
 0x9444 from lo16 (sign extend as it's always treated as signed);
 0xc06b8000 from base.

 = 0xc06b1444. The value is lower than the real phy_probe() address
 (0xc06c1444) by 0x1 and is lower than the base address of
 module's .text, so it's 100% incorrect.

 This results in:

 [2.204022] CPU 3 Unable to handle kernel paging request at virtual
 address c06b1444, epc == c06b1444, ra == 803f1090

 The correct instructions should be:

 R_MIPS_HI16 0x3c010001
 R_MIPS_LO16 0x24339444

 so there'll be 0x0001 from hi16.

 I tried to catch those bugs in arch/mips/kernel/module.c (by checking
 if the destination is lower than the base address, which should never
 happen), and seems like I have only 3 such places in libphy.ko (and
 one in nf_tables.ko).
 I don't think it should be handled somehow in mentioned source code
 as it would look rather ugly and may break kernels build with GNU
 stack, which seems to not produce such bad codes.

 If I should report this to any other resources, please let me know.
 I chose clang-built-linux and LKML as it may not happen with userland
 (didn't tried to catch).
>>>
>>> Thanks for the report.  Sounds like we may indeed be producing an
>>> incorrect relocation.  This is only seen for big endian triples?
>>
>> Unfortunately I don't have a LE board to play with, so can confirm
>> only Big Endian.
>>
>> (BTW, if someone can say if it's possible for MIPS (and how if it is)
>> to launch a LE kernel from BE-booted preloader and U-Boot, that would
>> be super cool)
>>
>>> Getting a way for us to deterministically reproduce would be a good
>>> first step.  Which config or configs beyond defconfig, and which
>>> relocations specifically are you observing this with?
>>
>> I use `make 32r2_defconfig` which combines several configs from
>> arch/mips/configs:
>>  - generic_defconfig;
>>  - generic/32r2.config;
>>  - generic/eb.config.
>>
>> Aside from that, I enable a bunch of my WIP drivers and the
>> Netfilter. On my setup, this bug is always present in libphy.ko,
>> so CONFIG_PHYLIB=m (with all deps) should be enough.
>>
>> The three failed relocs belongs to this part of code: [0]
>>
>> llvm-readelf on them:
>>
>> Relocation section '.rel.text' at offset 0xbf60 contains 2281 entries:
>> [...]
>> 5740  00029305 R_MIPS_HI16   .text
>> 5744  00029306 R_MIPS_LO16   .text
>> 5720  00029305 R_MIPS_HI16   .text
>> 5748  00029306 R_MIPS_LO16   .text
>> 573c  00029305 R_MIPS_HI16   .text
>> 574c  00029306 R_MIPS_LO16   .text
>>
>> The first pair is the one from my first mail:
>> 0x3c01 <-- should be 0x3c010001 to work properly
>> 0x24339444
>>
>> I'm planning to hunt for more now, will let you know.
>
> Unfortunately, R_MIPS_32 also suffers from that. And unlikely
> R_MIPS_{HI,LO}16, they can't be handled runtime as the values
> are pure random.
> I expanded arch/mips/kernel/module.c a bit, so it tries to find
> the actual symbol in .symtab after each applied relocation and
> print the detailed info. Here's an example from nf_defrag_ipv6
> loading:
>
> [  429.789793] nf_defrag_ipv6: final section addresses:
> [  429.795409] =090xc07214fc __ksymtab_gpl
> [  429.799574] =090xc072 .text
> [  429.802902] =090xc07216b0 .data
> [  429.806249] =090xc0721790 .bss
> [  429.809474] =090xc0721508 __ksymtab_strings
> [  429.813977] =090xc0728000 .init.text
> [  429.817781] =090xc07214c0 .exit.text

Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse

[Linus Torvalds]

On Sat, Jan 9, 2021 at 4:44 PM Andrea Arcangeli  wrote:
>
> Once we agree that COW page reuse requires full accuracy, [...]

You have completely and utterly ignored every single argument against that.

Instead, you just continue to push your agenda.

The thing is, GUP works fine.

COW works fine.

The thing that is broken is clear_refs.

Yet you try to now "fix" the two fine cases, because you don't want to
fix clear_refs.

What part of "clear_refs is the _least_ important of the three cases"
are you not willing to understand?

 Linus

[PATCH 0/1] mm: restore full accuracy in COW page reuse

[Andrea Arcangeli]

Hello Andrew and everyone,

Once we agree that COW page reuse requires full accuracy, the next
step is to re-apply 17839856fd588f4ab6b789f482ed3ffd7c403e1f and to
return going in that direction.

Who is going to orthogonally secure vmsplice, Andy, Jason, Jens?  Once
vmsplice is secured from taking unconstrained unprivileged long term
GUP pins, the attack from child to parent can still happen in theory,
but statistically speaking once that huge window is closed, it won't
be a practical concern, so it'll give us time to perfect the full
solution by closing all windows the VM core. vmsplice has to be
orthogonally fixed anyway, even if all windows were closed in VM core
first.

Unfortunately it's still not clear exactly what failed with
17839856fd588f4ab6b789f482ed3ffd7c403e1f but the whole point is that
we need to discuss that together.

Thanks,
Andrea

// SPDX-License-Identifier: GPL-3.0-or-later
/*
 *  reproducer for v5.11 O_DIRECT mm corruption with page_count
 *  instead of mapcount in do_wp_page.
 *
 *  Copyright (C) 2021  Red Hat, Inc.
 *
 *  gcc -O2 -o page_count_do_wp_page page_count_do_wp_page.c -lpthread
 *  page_count_do_wp_page ./whateverfile
 *
 *  NOTE: CONFIG_SOFT_DIRTY=y is required in the kernel config.
 */

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define PAGE_SIZE (1UL<<12)
#define HARDBLKSIZE 512

static void* writer(void *_mem)
{
char *mem = (char *)_mem;
for(;;) {
usleep(random() % 1000);
mem[PAGE_SIZE-1] = 0;
}
}

static void* background_soft_dirty(void *data)
{
long fd = (long) data;
for (;;)
if (write(fd, "4", 1) != 1)
perror("write soft dirty"), exit(1);
}

int main(int argc, char *argv[])
{
if (argc < 2)
printf("%s ", argv[0]), exit(1);

char path[PAGE_SIZE];
strcpy(path, "/proc/");
sprintf(path + strlen(path), "%d", getpid());
strcat(path, "/clear_refs");
long soft_dirty_fd = open(path, O_WRONLY);
if (soft_dirty_fd < 0)
perror("open clear_refs"), exit(1);

char *mem;
if (posix_memalign((void **)&mem, PAGE_SIZE, PAGE_SIZE*3))
perror("posix_memalign"), exit(1);
/* THP is not using page_count so it would not corrupt memory */
if (madvise(mem, PAGE_SIZE, MADV_NOHUGEPAGE))
perror("madvise"), exit(1);
bzero(mem, PAGE_SIZE * 3);
memset(mem + PAGE_SIZE * 2, 0xff, HARDBLKSIZE);

/*
 * This is not specific to O_DIRECT. Even if O_DIRECT was
 * forced to use PAGE_SIZE minimum granularity for reads, a
 * recvmsg would create the same issue since it also use
 * iov_iter_get_pages internally to create transient GUP pins
 * on anon memory.
 */
int fd = open(argv[1], O_DIRECT|O_CREAT|O_RDWR|O_TRUNC, 0600);
if (fd < 0)
perror("open"), exit(1);
if (write(fd, mem, PAGE_SIZE) != PAGE_SIZE)
perror("write"), exit(1);

pthread_t soft_dirty;
if (pthread_create(&soft_dirty, NULL,
   background_soft_dirty, (void *)soft_dirty_fd))
perror("soft_dirty"), exit(1);

pthread_t thread;
if (pthread_create(&thread, NULL, writer, mem))
perror("pthread_create"), exit(1);

bool skip_memset = true;
while (1) {
if (pread(fd, mem, HARDBLKSIZE, 0) != HARDBLKSIZE)
perror("read"), exit(1);
if (memcmp(mem, mem+PAGE_SIZE, HARDBLKSIZE)) {
if (memcmp(mem, mem+PAGE_SIZE*2, PAGE_SIZE)) {
if (skip_memset)
printf("unexpected memory "
   "corruption detected\n");
else
printf("memory corruption detected, "
   "dumping page\n");
int end = PAGE_SIZE;
if (!memcmp(mem+HARDBLKSIZE, mem+PAGE_SIZE,
PAGE_SIZE-HARDBLKSIZE))
end = HARDBLKSIZE;
for (int i = 0; i < end; i++)
printf("%x", mem[i]);
printf("\n");
} else
printf("memory corruption detected\n");
}
skip_memset = !skip_memset;
if (!skip_memset)
memset(mem, 0xff, HARDBLKSIZE);
}

return 0;
}

Andrea Arcangeli (1):
  mm: restore full accuracy in COW page reuse

 include/linux/ksm.h |  7 ++
 mm/ksm.c| 25 +++
 mm/memory.c

[PATCH 1/1] mm: restore full accuracy in COW page reuse

[Andrea Arcangeli]

This reverts commit 09854ba94c6aad7886996bfbee2530b3d8a7f4f4.
This reverts commit be068f29034fb00530a053d18b8cf140c32b12b3.
This reverts commit 1a0cf26323c80e2f1c58fc04f15686de61bfab0c.

This example below uses O_DIRECT, on a process under
clear_refs. There's no FOLL_LONGTERM involvement. All GUP pins are
transient. fork is never called and even when clear_refs is cleared by
an external program, fork() would not be involved.

thread0 thread1 other process
(or thread 3)
=   =   ===
read syscall
O_DIRECT
read DMA to vaddr+0
len = 512 bytes
GUP(FOLL_WRITE)
DMA writing to RAM started
clear_refs
pte_wrprotect
write vaddrA+512
page_count == 2
wp_copy_page
read syscall returns
read lost

Notwithstanding the fact that failing O_DIRECT at sub-PAGE_SIZE
granularity is an ABI break by itself, this is of course not just
about O_DIRECT. recvmsg kernel TLS and plenty of other GUP FOLL_WRITE
iov_iter_get_pages users would write to the memory with sub-PAGE_SIZE
granularity, depending on the msghdr iov tiny buffers. Those recvmsg
are already silently lost too as well as the above O_DIRECT already
get lost.

The fact COW must not happen too much is documented in commit
6d0a07edd17cfc12fdc1f36de8072fa17cc3666f:

==
This will provide fully accuracy to the mapcount calculation in the
write protect faults, so page pinning will not get broken by false
positive copy-on-writes.
==

And in the current comment above the THP mapcount:

==
 * [..] we only use
 * page_trans_huge_mapcount() in the copy-on-write faults where we
 * need full accuracy to avoid breaking page pinning, [..]
==

Quote from the Link tagged:

==
In other words, the page_count check in do_wp_page, extends the old
fork vs gup vs threads race, so that it also happens within a single
thread without fork() involvement.
===

In addition FOLL_LONGTERM breaks for readonly DMA, despite
FOLL_LONGTERM pages are now treated specially and copied in fork().

FOLL_LONGTERM is in no way special with regard to the VM core and it
can't be. From the VM standpoint all GUP in are equal and breaking
one, means breaking them all the same.

It is not possible to resolve this by looking only at FOLL_LONGTERM,
that only hides the problem, but it doesn't fully resolve it as shown
above.

In addition this avoids storms of extra false positive COWs if the THP
are shared by different processes, which causes extra overhead, but
the several performance considerations are only a secondary concern.

After this commit, the copy in fork() for FOLL_LONGTERM also must be
extended to all GUP pins including transient pins or we shouldn't even
copy FOLL_LONGTERM pinned pages. Treating FOLL_LONGTERM any different
from transient GUP pin is sign that something is fundamentally flawed.

FOLL_LONGTERM can be treated different in writeback and during GUP
runtime itself, but not in the VM-core when deciding when to COW or
not to COW an anonymous page.

This revert causes no theoretical security regression because THP is
not yet using page_count in do_huge_pmd_wp_page.

The alternative of this patch would be to replace the mapcount with
the page_count in do_huge_pmd_wp_page too in order to really close the
vmsplice attack from child to parent that way.

However since a single transient GUP pin on a tail page, would elevate
the page_count for all other tail pages (unlike the mapcount which is
subpage granular), the above "fork-less" race would span over a
HPAGE_PMD_SIZE range, it would even cross different vmas and the
effect would happen at a distance in vma of different processes
allowing a child to corrupt memory in the parent. That's a problem
that could happen not-maliciously too. So the scenario described
above, if extended to THP new refcounting, would be more concerning
than the vmsplice issue, that can be tackled first in vmsplice itself,
and only at a second stage in the COW code.

Link: https://lkml.kernel.org/r/20210107200402.31095-1-aarca...@redhat.com
Cc: sta...@kernel.org
Fixes: 09854ba94c6a ("mm: do_wp_page() simplification")
Signed-off-by: Andrea Arcangeli 
---
 include/linux/ksm.h |  7 ++
 mm/ksm.c| 25 +++
 mm/memory.c | 59 -
 3 files changed, 74 insertions(+), 17 deletions(-)

diff --git a/include/linux/ksm.h b/include/linux/ksm.h
index 161e8164abcf..e48b1e453ff5 100644
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -53,6 +53,8 @@ struct page *ksm_might_need_to_copy(struct page *page,
 
 void rmap_walk_ksm(struct page *page, struct rmap_walk_control *rwc);
 void ksm_migrate_page(struct page *newpage, struct page *oldpage);
+bool reuse_ksm_page(struc

Re: [PATCH v2 09/15] soc: qcom: Add support for Core Power Reduction v3, v4 and Hardened

[kernel test robot]

Hi AngeloGioacchino,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pm/linux-next]
[also build test WARNING on robh/for-next linux/master linus/master v5.11-rc2 
next-20210108]
[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/AngeloGioacchino-Del-Regno/Enable-CPRh-3-4-CPU-Scaling-on-various-QCOM-SoCs/20210110-021002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/f7b151e3b7c4b04b508e6ff13738de070041
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
AngeloGioacchino-Del-Regno/Enable-CPRh-3-4-CPU-Scaling-on-various-QCOM-SoCs/20210110-021002
git checkout f7b151e3b7c4b04b508e6ff13738de070041
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

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

All warnings (new ones prefixed by >>):

   drivers/soc/qcom/cpr3.c: In function 'cpr3_corner_init':
>> drivers/soc/qcom/cpr3.c:1673:17: warning: variable 'min_quot_val' set but 
>> not used [-Wunused-but-set-variable]
1673 |   int ring_osc, min_quot_val;
 | ^~~~
>> drivers/soc/qcom/cpr3.c:1316:7: warning: variable 'apply_scaling' set but 
>> not used [-Wunused-but-set-variable]
1316 |  bool apply_scaling;
 |   ^


vim +/min_quot_val +1673 drivers/soc/qcom/cpr3.c

  1284  
  1285  /**
  1286   * cpr3_corner_init - Calculate and set-up corners for the CPR HW
  1287   * @thread: Structure holding CPR thread-specific parameters
  1288   *
  1289   * This function calculates all the corner parameters by comparing
  1290   * and interpolating the values read from the various set-points
  1291   * read from the fuses (also called "fuse corners") to generate and
  1292   * program to the CPR a lookup table that describes each voltage
  1293   * step, mapped to a performance level (or corner number).
  1294   *
  1295   * It also programs other essential parameters on the CPR and - if
  1296   * we are dealing with CPR-Hardened, it will also enable the internal
  1297   * interface between the Operating State Manager (OSM) and the CPRh
  1298   * in order to achieve CPU DVFS.
  1299   *
  1300   * Returns: Zero for success, negative number on error
  1301   */
  1302  static int cpr3_corner_init(struct cpr_thread *thread)
  1303  {
  1304  struct cpr_drv *drv = thread->drv;
  1305  const struct cpr_desc *desc = drv->desc;
  1306  const struct cpr_thread_desc *tdesc = thread->desc;
  1307  const struct cpr_fuse *fuses = thread->cpr_fuses;
  1308  int i, ret, total_corners, extra_corners, level, scaling = 0;
  1309  unsigned int fnum, fc;
  1310  const char *quot_offset;
  1311  const struct fuse_corner_data *fdata;
  1312  struct fuse_corner *fuse, *prev_fuse;
  1313  struct corner *corner, *prev_corner, *end;
  1314  struct corner_data *cdata;
  1315  struct dev_pm_opp *opp;
  1316  bool apply_scaling;
  1317  unsigned long freq;
  1318  u32 ring_osc_mask = CPR3_RO_MASK, min_quotient = U32_MAX;
  1319  
  1320  corner = thread->corners;
  1321  prev_corner = &thread->corners[0];
  1322  end = &corner[thread->num_corners - 1];
  1323  
  1324  cdata = devm_kcalloc(drv->dev,
  1325   thread->num_corners + drv->extra_corners,
  1326   sizeof(struct corner_data),
  1327   GFP_KERNEL);
  1328  if (!cdata)
  1329  return -ENOMEM;
  1330  
  1331  for (level = 1; level <= thread->num_corners; level++) {
  1332  opp = dev_pm_opp_find_level_exact(&thread->pd.dev, 
level);
  1333  if (IS_ERR(opp))
  1334  return -EINVAL;
  1335  
  1336  /*
  1337   * If there is only one specified qcom,opp-fuse-level, 
then
  1338   * it is assumed that this only one is global and valid 
for
  1339   * all IDs, so try to get the specific one but, on 
failure,
  1340   * go for the global one.
  1341   */
  1342  fc = cpr_get_fuse_corner(opp, thread->id);
  1343  if (fc == 0

Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander

[Linus Walleij]

On Sun, Jan 10, 2021 at 12:11 AM AngeloGioacchino Del Regno
 wrote:
> Il 09/01/21 23:11, Linus Walleij ha scritto:

> > The major review comment is that it'd be nice if you look into
> > using regmaps register cache instead of rolling your own,
> > and also possibly using regmaps locking rather than your own
> > as a result of that.
> >
> Actually, I really tried to use regmap's FLAT register cache and after
> many, many tries... I had to give up. I just couldn't get it working. :(

This needs to be root-caused. The register cache in regmap is for
using not for decoration.

What is the problems you are seeing?

If it is fundamentally so that regmap has limitations that is one thing,
but I want to rule out that we're just not using it wrong or that there
is a bug in it that we should fix.

Looping in Mark Brown the regmap maintainer.

Yours,
Linus Walleij

WARNING in squashfs_read_table

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:83dadd4c Add linux-next specific files for 20210105
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14c0532b50
kernel config:  https://syzkaller.appspot.com/x/.config?x=ca68c01770b963e1
dashboard link: https://syzkaller.appspot.com/bug?extid=2ccea6339d368360800d
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=115f4dfb50
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1542c43f50

Bisection is inconclusive: the issue happens on the oldest tested release.

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17f77b6750
final oops: https://syzkaller.appspot.com/x/report.txt?x=140f7b6750
console output: https://syzkaller.appspot.com/x/log.txt?x=100f7b6750

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

loop0: detected capacity change from 8 to 0
[ cut here ]
WARNING: CPU: 0 PID: 8456 at mm/page_alloc.c:4977 
__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5012
Modules linked in:
CPU: 0 PID: 8456 Comm: syz-executor943 Not tainted 
5.11.0-rc2-next-20210105-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4977
Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00 
48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89 
74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8
RSP: 0018:c9000112fa98 EFLAGS: 00010246
RAX:  RBX: 192000225f57 RCX: 
RDX:  RSI: dc00 RDI: 00040cc0
RBP: 00040cc0 R08:  R09: 
R10: 81b25651 R11:  R12: 0034
R13: 0034 R14:  R15: e24d8401
FS:  019a2880() GS:8880b9f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 559ed1ff3180 CR3: 1b421000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267
 alloc_pages include/linux/gfp.h:547 [inline]
 kmalloc_order+0x2e/0xb0 mm/slab_common.c:916
 kmalloc_order_trace+0x14/0x120 mm/slab_common.c:932
 kmalloc include/linux/slab.h:559 [inline]
 squashfs_read_table+0x43/0x1e0 fs/squashfs/cache.c:413
 squashfs_read_xattr_id_table+0x191/0x220 fs/squashfs/xattr_id.c:81
 squashfs_fill_super+0xcfb/0x23b0 fs/squashfs/super.c:225
 get_tree_bdev+0x421/0x740 fs/super.c:1291
 vfs_get_tree+0x89/0x2f0 fs/super.c:1496
 do_new_mount fs/namespace.c:2899 [inline]
 path_mount+0x12ae/0x1e70 fs/namespace.c:3230
 do_mount fs/namespace.c:3243 [inline]
 __do_sys_mount fs/namespace.c:3451 [inline]
 __se_sys_mount fs/namespace.c:3428 [inline]
 __x64_sys_mount+0x27f/0x300 fs/namespace.c:3428
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d1a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 
84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 
da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:7ffe89cbd7b8 EFLAGS: 0293 ORIG_RAX: 00a5
RAX: ffda RBX: 7ffe89cbd810 RCX: 00446d1a
RDX: 2000 RSI: 2100 RDI: 7ffe89cbd7d0
RBP: 7ffe89cbd7d0 R08: 7ffe89cbd810 R09: 7ffe0015
R10:  R11: 0293 R12: 0001
R13: 0004 R14: 0003 R15: 0003


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

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

Re: [PATCH v2 2/3] net: sfp: assume that LOS is not implemented if both LOS normal and inverted is set

[Pali Rohár]

On Saturday 09 January 2021 23:19:54 Russell King - ARM Linux admin wrote:
> On Sat, Jan 09, 2021 at 08:14:47PM +0100, Pali Rohár wrote:
> > On Saturday 09 January 2021 15:46:01 Russell King - ARM Linux admin wrote:
> > > On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> > > > On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
> > > > > From: Russell King 
> > > > > 
> > > > > Some GPON SFP modules (e.g. Ubiquiti U-Fiber Instant) have set both
> > > > > SFP_OPTIONS_LOS_INVERTED and SFP_OPTIONS_LOS_NORMAL bits in their 
> > > > > EEPROM.
> > > > > 
> > > > > Such combination of bits is meaningless so assume that LOS signal is 
> > > > > not
> > > > > implemented.
> > > > > 
> > > > > This patch fixes link carrier for GPON SFP module Ubiquiti U-Fiber 
> > > > > Instant.
> > > > > 
> > > > > Signed-off-by: Russell King 
> > > > > Signed-off-by: Pali Rohár 
> > > > 
> > > > Reviewed-by: Andrew Lunn 
> > > 
> > > I'd like to send this patch irrespective of discussion on the other
> > > patches - I already have it committed in my repository with a different
> > > description, but the patch content is the same.
> > > 
> > > Are you happy if I transfer Andrew's r-b tag, and convert yours to an
> > > acked-by before I send it?
> > > 
> > > I'd also like to add a patch that allows 2.5G if no other modes are
> > > found, but the bitrate specified by the module allows 2.5G speed - much
> > > like we do for 1G speeds.
> > 
> > Russell, should I send a new version of patch series without this patch?
> 
> I think there's some work to be done for patch 1, so I was thinking of
> sending this with another SFP patch. It's really a bug fix since the
> existing code doesn't behave very well if both bits are set - it will
> toggle state on every RX_LOS event received irrespective of the RX_LOS
> state.

Ok! So I will fix what is needed for patch 1, send it with patch 3 as
next version and let patch 2 to you.

Re: [PATCH v9 00/16] Add support for Clang LTO

[Sedat Dilek]

On Sat, Jan 9, 2021 at 6:06 PM Josh Poimboeuf  wrote:
>
> On Sat, Jan 09, 2021 at 11:03:57AM -0600, Josh Poimboeuf wrote:
> > On Sat, Jan 09, 2021 at 05:45:47PM +0100, Sedat Dilek wrote:
> > > I tried merging with clang-cfi Git which is based on Linux v5.11-rc2+
> > > with a lot of merge conflicts.
> > >
> > > Did you try on top of cfi-10 Git tag which is based on Linux v5.10?
> > >
> > > Whatever you successfully did... Can you give me a step-by-step 
> > > instruction?
> >
> > Oops, my bad.  My last three commits (which I just added) do conflict.
> > Sorry for the confusion.
> >
> > Just drop my last three commits:
> >
> > git fetch 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git 
> > objtool-vmlinux
> > git checkout -B tmp FETCH_HEAD
> > git reset --hard HEAD~~~
> > git fetch https://github.com/samitolvanen/linux clang-lto
> > git rebase --onto FETCH_HEAD 79881bfc57be
>
> Last one should be:
>
> git rebase --onto FETCH_HEAD 2c85ebc57b3e
>

Hi Josh,

as said I tried your latest changes on top of Linux v5.10.6 + cfi-5.10.
This reduces the objtool-warnings in vmlinux.o from 15 down to 2.

Without your latest changes:

$ grep 'vmlinux.o: warning: objtool:'
build-log_5.10.4-3-amd64-clang11-cfi.txt | wc -l
15

$ grep 'vmlinux.o: warning: objtool:'
build-log_5.10.4-3-amd64-clang11-cfi.txt
vmlinux.o: warning: objtool: wakeup_long64()+0x61: indirect jump found
in RETPOLINE build
vmlinux.o: warning: objtool: .text+0x408a: indirect jump found in
RETPOLINE build
vmlinux.o: warning: objtool: .text+0x40c5: indirect jump found in
RETPOLINE build
vmlinux.o: warning: objtool: .head.text+0x298: indirect jump found in
RETPOLINE build
vmlinux.o: warning: objtool: __switch_to_asm()+0x0: undefined stack state
vmlinux.o: warning: objtool: .entry.text+0xf91: sibling call from
callable instruction with modified stack frame
vmlinux.o: warning: objtool: .entry.text+0x16c4: unsupported
instruction in callable function
vmlinux.o: warning: objtool: .entry.text+0x15a4: redundant CLD
vmlinux.o: warning: objtool: do_suspend_lowlevel()+0x116: sibling call
from callable instruction with modified stack frame
vmlinux.o: warning: objtool: kretprobe_trampoline()+0x49: return with
modified stack frame
vmlinux.o: warning: objtool: machine_real_restart()+0x85: unsupported
instruction in callable function
vmlinux.o: warning: objtool: __x86_retpoline_rdi()+0x0: stack state
mismatch: cfa1=7+8 cfa2=-1+0
vmlinux.o: warning: objtool: .entry.text+0x48: stack state mismatch:
cfa1=7-8 cfa2=-1+0
vmlinux.o: warning: objtool: .entry.text+0x156d: stack state mismatch:
cfa1=7-8 cfa2=-1+0
vmlinux.o: warning: objtool: .entry.text+0x15fc: stack state mismatch:
cfa1=7-8 cfa2=-1+0

With your latest changes in :

$ grep 'vmlinux.o: warning: objtool:'
build-log_5.10.6-1-amd64-clang11-cfi.txt | wc -l
2

$ grep 'vmlinux.o: warning: objtool:' build-log_5.10.6-1-amd64-clang11-cfi.txt
vmlinux.o: warning: objtool: kretprobe_trampoline()+0x49: return with
modified stack frame
vmlinux.o: warning: objtool: machine_real_restart()+0x85: unsupported
instruction in callable function

Awesome.

If you need further information, please let me know.

Regards,
- Sedat -

Re: [BUG mips llvm] MIPS: malformed R_MIPS_{HI16,LO16} with LLVM

[Alexander Lobakin]

From: Alexander Lobakin 
Date: Sat, 09 Jan 2021 19:15:31 +

> From: Nick Desaulniers 
> Date: Sat, 9 Jan 2021 09:50:44 -0800
>
>> On Sat, Jan 9, 2021 at 9:11 AM Alexander Lobakin  wrote:
>>>
>>> Machine: MIPS32 R2 Big Endian (interAptiv (multi))
>>>
>>> While testing MIPS with LLVM, I found a weird and very rare bug with
>>> MIPS relocs that LLVM emits into kernel modules. It happens on both
>>> 11.0.0 and latest git snapshot and applies, as I can see, only to
>>> references to static symbols.
>>>
>>> When the kernel loads the module, it allocates a space for every
>>> section and then manually apply the relocations relative to the
>>> new address.
>>>
>>> Let's say we have a function phy_probe() in drivers/net/phy/libphy.ko.
>>> It's static and referenced only in phy_register_driver(), where it's
>>> used to fill callback pointer in a structure.
>>>
>>> The real function address after module loading is 0xc06c1444, that
>>> is observed in its ELF st_value field.
>>> There are two relocs related to this usage in phy_register_driver():
>>>
>>> R_MIPS_HI16 refers to 0x3c01
>>> R_MIPS_LO16 refers to 0x24339444
>>>
>>> The address of .text is 0xc06b8000. So the destination is calculated
>>> as follows:
>>>
>>> 0x from hi16;
>>> 0x9444 from lo16 (sign extend as it's always treated as signed);
>>> 0xc06b8000 from base.
>>>
>>> = 0xc06b1444. The value is lower than the real phy_probe() address
>>> (0xc06c1444) by 0x1 and is lower than the base address of
>>> module's .text, so it's 100% incorrect.
>>>
>>> This results in:
>>>
>>> [2.204022] CPU 3 Unable to handle kernel paging request at virtual
>>> address c06b1444, epc =3D=3D c06b1444, ra =3D=3D 803f1090
>>>
>>> The correct instructions should be:
>>>
>>> R_MIPS_HI16 0x3c010001
>>> R_MIPS_LO16 0x24339444
>>>
>>> so there'll be 0x0001 from hi16.
>>>
>>> I tried to catch those bugs in arch/mips/kernel/module.c (by checking
>>> if the destination is lower than the base address, which should never
>>> happen), and seems like I have only 3 such places in libphy.ko (and
>>> one in nf_tables.ko).
>>> I don't think it should be handled somehow in mentioned source code
>>> as it would look rather ugly and may break kernels build with GNU
>>> stack, which seems to not produce such bad codes.
>>>
>>> If I should report this to any other resources, please let me know.
>>> I chose clang-built-linux and LKML as it may not happen with userland
>>> (didn't tried to catch).
>>
>> Thanks for the report.  Sounds like we may indeed be producing an
>> incorrect relocation.  This is only seen for big endian triples?
>
> Unfortunately I don't have a LE board to play with, so can confirm
> only Big Endian.
>
> (BTW, if someone can say if it's possible for MIPS (and how if it is)
> to launch a LE kernel from BE-booted preloader and U-Boot, that would
> be super cool)
>
>> Getting a way for us to deterministically reproduce would be a good
>> first step.  Which config or configs beyond defconfig, and which
>> relocations specifically are you observing this with?
>
> I use `make 32r2_defconfig` which combines several configs from
> arch/mips/configs:
>  - generic_defconfig;
>  - generic/32r2.config;
>  - generic/eb.config.
>
> Aside from that, I enable a bunch of my WIP drivers and the
> Netfilter. On my setup, this bug is always present in libphy.ko,
> so CONFIG_PHYLIB=m (with all deps) should be enough.
>
> The three failed relocs belongs to this part of code: [0]
>
> llvm-readelf on them:
>
> Relocation section '.rel.text' at offset 0xbf60 contains 2281 entries:
> [...]
> 5740  00029305 R_MIPS_HI16   .text
> 5744  00029306 R_MIPS_LO16   .text
> 5720  00029305 R_MIPS_HI16   .text
> 5748  00029306 R_MIPS_LO16   .text
> 573c  00029305 R_MIPS_HI16   .text
> 574c  00029306 R_MIPS_LO16   .text
>
> The first pair is the one from my first mail:
> 0x3c01 <-- should be 0x3c010001 to work properly
> 0x24339444
>
> I'm planning to hunt for more now, will let you know.

Unfortunately, R_MIPS_32 also suffers from that. And unlikely
R_MIPS_{HI,LO}16, they can't be handled runtime as the values
are pure random.
I expanded arch/mips/kernel/module.c a bit, so it tries to find
the actual symbol in .symtab after each applied relocation and
print the detailed info. Here's an example from nf_defrag_ipv6
loading:

[  429.789793] nf_defrag_ipv6: final section addresses:
[  429.795409]  0xc07214fc __ksymtab_gpl
[  429.799574]  0xc072 .text
[  429.802902]  0xc07216b0 .data
[  429.806249]  0xc0721790 .bss
[  429.809474]  0xc0721508 __ksymtab_strings
[  429.813977]  0xc0728000 .init.text
[  429.817781]  0xc07214c0 .exit.text
[  429.821606]  0xc0721520 .rodata
[  429.825120]  0xc0721578 .rodata.str1.1
[  429.829322]  0xc0721638 .note.Linux
[  429.833226]  0xc0721800 .gnu.linkonce.this_module
[  429.838503]  0xc0721650 .MIPS.abiflags

Re: [PATCH v2 2/3] net: sfp: assume that LOS is not implemented if both LOS normal and inverted is set

[Russell King - ARM Linux admin]

On Sat, Jan 09, 2021 at 08:14:47PM +0100, Pali Rohár wrote:
> On Saturday 09 January 2021 15:46:01 Russell King - ARM Linux admin wrote:
> > On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> > > On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
> > > > From: Russell King 
> > > > 
> > > > Some GPON SFP modules (e.g. Ubiquiti U-Fiber Instant) have set both
> > > > SFP_OPTIONS_LOS_INVERTED and SFP_OPTIONS_LOS_NORMAL bits in their 
> > > > EEPROM.
> > > > 
> > > > Such combination of bits is meaningless so assume that LOS signal is not
> > > > implemented.
> > > > 
> > > > This patch fixes link carrier for GPON SFP module Ubiquiti U-Fiber 
> > > > Instant.
> > > > 
> > > > Signed-off-by: Russell King 
> > > > Signed-off-by: Pali Rohár 
> > > 
> > > Reviewed-by: Andrew Lunn 
> > 
> > I'd like to send this patch irrespective of discussion on the other
> > patches - I already have it committed in my repository with a different
> > description, but the patch content is the same.
> > 
> > Are you happy if I transfer Andrew's r-b tag, and convert yours to an
> > acked-by before I send it?
> > 
> > I'd also like to add a patch that allows 2.5G if no other modes are
> > found, but the bitrate specified by the module allows 2.5G speed - much
> > like we do for 1G speeds.
> 
> Russell, should I send a new version of patch series without this patch?

I think there's some work to be done for patch 1, so I was thinking of
sending this with another SFP patch. It's really a bug fix since the
existing code doesn't behave very well if both bits are set - it will
toggle state on every RX_LOS event received irrespective of the RX_LOS
state.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 1/2] dt-bindings: mediatek: mmsys: add mt1867 binding

[Chun-Kuang Hu]

Hi, Matthias:

Rob Herring  於 2020年10月31日 週六 上午3:17寫道：
>
> On Tue, 27 Oct 2020 17:06:29 +0100, Fabien Parent wrote:
> > Add binding documentation for MT8167 SoC.

Even though the title need to change to 'mt8167', this patch looks
good to me. How do you think about this patch? One drm patch [1]
depend on this patch, if you like this patch, could you applied this
patch first?

[1] 
https://patchwork.kernel.org/project/linux-mediatek/patch/20201023133130.194140-6-fpar...@baylibre.com/

Regards,
Chun-Kuang.

> >
> > Signed-off-by: Fabien Parent 
> > ---
> >  .../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt  | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Acked-by: Rob Herring 
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander

[AngeloGioacchino Del Regno]

Il 09/01/21 23:12, Linus Walleij ha scritto:

On Sat, Jan 9, 2021 at 6:24 PM kernel test robot  wrote:


  > 880  gpioirq->parent_domain = NULL;


The autobuilder is complaining because your irq chip is not
hierarchical and this is only used for hierarchical irqchips.
I think you can just delete this line.


That's a development leftover. Big oops! Removed in V2 :)


Yours,
Linus Walleij

Re: [PATCH 2/2] dt-bindings: pinctrl: Add bindings for Awinic AW9523/AW9523B

[AngeloGioacchino Del Regno]

Il 09/01/21 23:14, Linus Walleij ha scritto:

Hi Angelo,

thanks for your patch!

On Sat, Jan 9, 2021 at 3:02 PM AngeloGioacchino Del Regno
 wrote:


+#PIN CONFIGURATION NODES
+patternProperties:
+  '^.*$':
+if:
+  type: object
+then:
+  properties:
+pins:
+  description:
+List of gpio pins affected by the properties specified in
+this subnode.
+  items:
+pattern: "^gpio([0-9]|1[0-5])$"
+  minItems: 1
+  maxItems: 16
+
+function:
+  description:
+Specify the alternative function to be configured for the
+specified pins.
+
+  enum: [ gpio, pwm ]
+
+bias-disable: true
+bias-pull-down: true
+bias-pull-up: true
+drive-open-drain: true
+drive-push-pull: true
+input-enable: true
+output-high: true
+output-low: true
+
+  required:
+- pins
+- function


Is it possible to just $ref /pinctrl/pincfg-node.yaml# for some of this?


Sure, I will try to reference that for V2!


Yours,
Linus Walleij

[PATCH v2 6/6] iio:pressure:ms5637: add ms5803 support

[Alexandre Belloni]

The ms5803 is very similar to the ms5805 but has less resolution options
and has the 128bit PROM layout.

Signed-off-by: Alexandre Belloni 
---
 Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
 drivers/iio/pressure/ms5637.c  | 8 
 2 files changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml 
b/Documentation/devicetree/bindings/trivial-devices.yaml
index e9b64be4b91e..a327130d1faa 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -153,6 +153,8 @@ properties:
 # Measurement Specialities I2C pressure and temperature sensor
   - meas,ms5637
 # Measurement Specialities I2C pressure and temperature sensor
+  - meas,ms5803
+# Measurement Specialities I2C pressure and temperature sensor
   - meas,ms5805
 # Measurement Specialities I2C pressure and temperature sensor
   - meas,ms5837
diff --git a/drivers/iio/pressure/ms5637.c b/drivers/iio/pressure/ms5637.c
index 0a6034342714..81f683321b23 100644
--- a/drivers/iio/pressure/ms5637.c
+++ b/drivers/iio/pressure/ms5637.c
@@ -200,8 +200,15 @@ static const struct ms_tp_hw_data ms5637_hw_data  = {
.max_res_index = 5
 };
 
+static const struct ms_tp_hw_data ms5803_hw_data  = {
+   .prom_len = 8,
+   .max_res_index = 4
+};
+
 static const struct ms_tp_data ms5637_data = { .name = "ms5637", .hw = 
&ms5637_hw_data };
 
+static const struct ms_tp_data ms5803_data = { .name = "ms5803", .hw = 
&ms5803_hw_data };
+
 static const struct ms_tp_data ms5805_data = { .name = "ms5805", .hw = 
&ms5637_hw_data };
 
 static const struct ms_tp_data ms5837_data = { .name = "ms5837", .hw = 
&ms5637_hw_data };
@@ -222,6 +229,7 @@ MODULE_DEVICE_TABLE(i2c, ms5637_id);
 
 static const struct of_device_id ms5637_of_match[] = {
{ .compatible = "meas,ms5637", .data = &ms5637_data },
+   { .compatible = "meas,ms5803", .data = &ms5803_data },
{ .compatible = "meas,ms5805", .data = &ms5805_data },
{ .compatible = "meas,ms5837", .data = &ms5837_data },
{ .compatible = "meas,ms8607-temppressure", .data = &ms8607_data },
-- 
2.29.2

[PATCH v2 5/6] iio:common:ms_sensors:ms_sensors_i2c: add support for alternative PROM layout

[Alexandre Belloni]

Currently, only the 112bit PROM with 7 words is supported. However the ms58xx
family also have devices with a 128bit PROM on 8 words. See AN520:
C-CODE EXAMPLE FOR MS56XX, MS57XX (EXCEPT ANALOG SENSOR), AND MS58XX SERIES
PRESSURE SENSORS and the various device datasheets.

The difference is that the CRC is the 4 LSBs of word7 instead of being the
4 MSBs of word0.

Signed-off-by: Alexandre Belloni 
---
Changes in v2:
 - Fix return value documentation for ms_sensors_tp_crc_valid_112 and
   ms_sensors_tp_crc_valid_128

 .../iio/common/ms_sensors/ms_sensors_i2c.c| 70 ---
 1 file changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c 
b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c
index 872f90459e2e..16ea697e945c 100644
--- a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c
+++ b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c
@@ -488,21 +488,18 @@ int ms_sensors_ht_read_humidity(struct ms_ht_dev 
*dev_data,
 EXPORT_SYMBOL(ms_sensors_ht_read_humidity);
 
 /**
- * ms_sensors_tp_crc_valid() - CRC check function for
+ * ms_sensors_tp_crc4() - Calculate PROM CRC for
  * Temperature and pressure devices.
  * This function is only used when reading PROM coefficients
  *
  * @prom:  pointer to PROM coefficients array
  *
- * Return: True if CRC is ok.
+ * Return: CRC.
  */
-static bool ms_sensors_tp_crc_valid(u16 *prom)
+static u8 ms_sensors_tp_crc4(u16 *prom)
 {
unsigned int cnt, n_bit;
-   u16 n_rem = 0x, crc_read = prom[0], crc = (*prom & 0xF000) >> 12;
-
-   prom[MS_SENSORS_TP_PROM_WORDS_NB - 1] = 0;
-   prom[0] &= 0x0FFF;  /* Clear the CRC computation part */
+   u16 n_rem = 0x;
 
for (cnt = 0; cnt < MS_SENSORS_TP_PROM_WORDS_NB * 2; cnt++) {
if (cnt % 2 == 1)
@@ -517,10 +514,55 @@ static bool ms_sensors_tp_crc_valid(u16 *prom)
n_rem <<= 1;
}
}
-   n_rem >>= 12;
-   prom[0] = crc_read;
 
-   return n_rem == crc;
+   return n_rem >> 12;
+}
+
+/**
+ * ms_sensors_tp_crc_valid_112() - CRC check function for
+ * Temperature and pressure devices for 112bit PROM.
+ * This function is only used when reading PROM coefficients
+ *
+ * @prom:  pointer to PROM coefficients array
+ *
+ * Return: True if CRC is ok.
+ */
+static bool ms_sensors_tp_crc_valid_112(u16 *prom)
+{
+   u16 w0 = prom[0], crc_read = (w0 & 0xF000) >> 12;
+   u8 crc;
+
+   prom[0] &= 0x0FFF;  /* Clear the CRC computation part */
+   prom[MS_SENSORS_TP_PROM_WORDS_NB - 1] = 0;
+
+   crc = ms_sensors_tp_crc4(prom);
+
+   prom[0] = w0;
+
+   return crc == crc_read;
+}
+
+/**
+ * ms_sensors_tp_crc_valid_128() - CRC check function for
+ * Temperature and pressure devices for 128bit PROM.
+ * This function is only used when reading PROM coefficients
+ *
+ * @prom:  pointer to PROM coefficients array
+ *
+ * Return: True if CRC is ok.
+ */
+static bool ms_sensors_tp_crc_valid_128(u16 *prom)
+{
+   u16 w7 = prom[7], crc_read = w7 & 0x000F;
+   u8 crc;
+
+   prom[7] &= 0xFF00;  /* Clear the CRC and LSB part */
+
+   crc = ms_sensors_tp_crc4(prom);
+
+   prom[7] = w7;
+
+   return crc == crc_read;
 }
 
 /**
@@ -535,6 +577,7 @@ static bool ms_sensors_tp_crc_valid(u16 *prom)
 int ms_sensors_tp_read_prom(struct ms_tp_dev *dev_data)
 {
int i, ret;
+   bool valid;
 
for (i = 0; i < dev_data->hw->prom_len; i++) {
ret = ms_sensors_read_prom_word(
@@ -546,7 +589,12 @@ int ms_sensors_tp_read_prom(struct ms_tp_dev *dev_data)
return ret;
}
 
-   if (!ms_sensors_tp_crc_valid(dev_data->prom)) {
+   if (dev_data->hw->prom_len == 8)
+   valid = ms_sensors_tp_crc_valid_128(dev_data->prom);
+   else
+   valid = ms_sensors_tp_crc_valid_112(dev_data->prom);
+
+   if (!valid) {
dev_err(&dev_data->client->dev,
"Calibration coefficients crc check error\n");
return -ENODEV;
-- 
2.29.2

[PATCH v2 4/6] iio:common:ms_sensors:ms_sensors_i2c: rework CRC calculation helper

[Alexandre Belloni]

The CRC calculation always happens on 8 words which is why there is an
extra element in the prom array of struct ms_tp_dev. However, on ms5637 and
similar, only 7 words are readable.

Then, set MS_SENSORS_TP_PROM_WORDS_NB to 8 and stop passing a len parameter
to ms_sensors_tp_crc_valid as this simply hide the fact that it is
hardcoded.

Finally, use the newly introduced hw->prom_len to know how many words can be
read.

Signed-off-by: Alexandre Belloni 
---
 drivers/iio/common/ms_sensors/ms_sensors_i2c.c | 12 +---
 drivers/iio/common/ms_sensors/ms_sensors_i2c.h |  4 ++--
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c 
b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c
index b9e2038d05ef..872f90459e2e 100644
--- a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c
+++ b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c
@@ -493,19 +493,18 @@ EXPORT_SYMBOL(ms_sensors_ht_read_humidity);
  * This function is only used when reading PROM coefficients
  *
  * @prom:  pointer to PROM coefficients array
- * @len:   length of PROM coefficients array
  *
  * Return: True if CRC is ok.
  */
-static bool ms_sensors_tp_crc_valid(u16 *prom, u8 len)
+static bool ms_sensors_tp_crc_valid(u16 *prom)
 {
unsigned int cnt, n_bit;
u16 n_rem = 0x, crc_read = prom[0], crc = (*prom & 0xF000) >> 12;
 
-   prom[len - 1] = 0;
+   prom[MS_SENSORS_TP_PROM_WORDS_NB - 1] = 0;
prom[0] &= 0x0FFF;  /* Clear the CRC computation part */
 
-   for (cnt = 0; cnt < len * 2; cnt++) {
+   for (cnt = 0; cnt < MS_SENSORS_TP_PROM_WORDS_NB * 2; cnt++) {
if (cnt % 2 == 1)
n_rem ^= prom[cnt >> 1] & 0x00FF;
else
@@ -537,7 +536,7 @@ int ms_sensors_tp_read_prom(struct ms_tp_dev *dev_data)
 {
int i, ret;
 
-   for (i = 0; i < MS_SENSORS_TP_PROM_WORDS_NB; i++) {
+   for (i = 0; i < dev_data->hw->prom_len; i++) {
ret = ms_sensors_read_prom_word(
dev_data->client,
MS_SENSORS_TP_PROM_READ + (i << 1),
@@ -547,8 +546,7 @@ int ms_sensors_tp_read_prom(struct ms_tp_dev *dev_data)
return ret;
}
 
-   if (!ms_sensors_tp_crc_valid(dev_data->prom,
-MS_SENSORS_TP_PROM_WORDS_NB + 1)) {
+   if (!ms_sensors_tp_crc_valid(dev_data->prom)) {
dev_err(&dev_data->client->dev,
"Calibration coefficients crc check error\n");
return -ENODEV;
diff --git a/drivers/iio/common/ms_sensors/ms_sensors_i2c.h 
b/drivers/iio/common/ms_sensors/ms_sensors_i2c.h
index f4a88148c113..f15b973f27c6 100644
--- a/drivers/iio/common/ms_sensors/ms_sensors_i2c.h
+++ b/drivers/iio/common/ms_sensors/ms_sensors_i2c.h
@@ -11,7 +11,7 @@
 #include 
 #include 
 
-#define MS_SENSORS_TP_PROM_WORDS_NB7
+#define MS_SENSORS_TP_PROM_WORDS_NB8
 
 /**
  * struct ms_ht_dev - Humidity/Temperature sensor device structure
@@ -47,7 +47,7 @@ struct ms_tp_dev {
struct i2c_client *client;
struct mutex lock;
const struct ms_tp_hw_data *hw;
-   u16 prom[MS_SENSORS_TP_PROM_WORDS_NB + 1];
+   u16 prom[MS_SENSORS_TP_PROM_WORDS_NB];
u8 res_index;
 };
 
-- 
2.29.2

[PATCH v2 3/6] iio:pressure:ms5637: limit available sample frequencies

[Alexandre Belloni]

Avoid exposing all the sampling frequencies for chip that only support a
subset.

Signed-off-by: Alexandre Belloni 
---
Changes in v2:
 -use sysfs_emit_at

 drivers/iio/pressure/ms5637.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/pressure/ms5637.c b/drivers/iio/pressure/ms5637.c
index fdd557ac71a3..0a6034342714 100644
--- a/drivers/iio/pressure/ms5637.c
+++ b/drivers/iio/pressure/ms5637.c
@@ -36,8 +36,19 @@ struct ms_tp_data {
 };
 
 static const int ms5637_samp_freq[6] = { 960, 480, 240, 120, 60, 30 };
-/* String copy of the above const for readability purpose */
-static const char ms5637_show_samp_freq[] = "960 480 240 120 60 30";
+
+static ssize_t ms5637_show_samp_freq(struct device *dev, struct 
device_attribute *attr, char *buf)
+{
+   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+   struct ms_tp_dev *dev_data = iio_priv(indio_dev);
+   int i, len = 0;
+
+   for (i = 0; i <= dev_data->hw->max_res_index; i++)
+   len += sysfs_emit_at(buf, len, "%u ", ms5637_samp_freq[i]);
+   sysfs_emit_at(buf, len - 1, "\n");
+
+   return len;
+}
 
 static int ms5637_read_raw(struct iio_dev *indio_dev,
   struct iio_chan_spec const *channel, int *val,
@@ -114,10 +125,10 @@ static const struct iio_chan_spec ms5637_channels[] = {
}
 };
 
-static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(ms5637_show_samp_freq);
+static IIO_DEV_ATTR_SAMP_FREQ_AVAIL(ms5637_show_samp_freq);
 
 static struct attribute *ms5637_attributes[] = {
-   &iio_const_attr_sampling_frequency_available.dev_attr.attr,
+   &iio_dev_attr_sampling_frequency_available.dev_attr.attr,
NULL,
 };
 
-- 
2.29.2

[PATCH v2 0/6] iio:pressure:ms5637: add ms5803 support

[Alexandre Belloni]

Hello,

This series adds support for the Measurement Specialities ms5803. It is
very similar to the ms5805 but has a different PROM layout (which I
suspect predates the ms5805 PROM layout). Also it supports less
frequency sampling options.

After a bit of preparatory work in the ms5637 driver and its common
library, mainly to handle the PROM layout and sample frequencies, adding
support is trivial.

Changes in v2:
 - Dropped "iio:pressure:ms5637: switch to probe_new" to keep the i2c_device_id
   table.
 - Reorder trivial-devices.yaml

Alexandre Belloni (6):
  dt-bindings: trivial-devices: reorder memsic devices
  iio:pressure:ms5637: introduce hardware differentiation
  iio:pressure:ms5637: limit available sample frequencies
  iio:common:ms_sensors:ms_sensors_i2c: rework CRC calculation helper
  iio:common:ms_sensors:ms_sensors_i2c: add support for alternative PROM
layout
  iio:pressure:ms5637: add ms5803 support

 .../devicetree/bindings/trivial-devices.yaml  | 10 ++-
 .../iio/common/ms_sensors/ms_sensors_i2c.c| 76 ++
 .../iio/common/ms_sensors/ms_sensors_i2c.h| 15 +++-
 drivers/iio/pressure/ms5637.c | 77 +++
 4 files changed, 143 insertions(+), 35 deletions(-)

-- 
2.29.2

[PATCH v2 2/6] iio:pressure:ms5637: introduce hardware differentiation

[Alexandre Belloni]

Some sensors in the ms58xx family have a different PROM length and a
different number of available resolution. introduce struct ms_tp_hw_data to
handle those differences.

Signed-off-by: Alexandre Belloni 
---
Changes in v2:
 - handle the i2c_device_table

 .../iio/common/ms_sensors/ms_sensors_i2c.h| 11 
 drivers/iio/pressure/ms5637.c | 50 +++
 2 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/drivers/iio/common/ms_sensors/ms_sensors_i2c.h 
b/drivers/iio/common/ms_sensors/ms_sensors_i2c.h
index bad09c80e47a..f4a88148c113 100644
--- a/drivers/iio/common/ms_sensors/ms_sensors_i2c.h
+++ b/drivers/iio/common/ms_sensors/ms_sensors_i2c.h
@@ -25,6 +25,16 @@ struct ms_ht_dev {
u8 res_index;
 };
 
+/**
+ * struct ms_hw_data - Temperature/Pressure sensor hardware data
+ * @prom_len:  number of words in the PROM
+ * @max_res_index: maximum sensor resolution index
+ */
+struct ms_tp_hw_data {
+   u8 prom_len;
+   u8 max_res_index;
+};
+
 /**
  * struct ms_tp_dev - Temperature/Pressure sensor device structure
  * @client:i2c client
@@ -36,6 +46,7 @@ struct ms_ht_dev {
 struct ms_tp_dev {
struct i2c_client *client;
struct mutex lock;
+   const struct ms_tp_hw_data *hw;
u16 prom[MS_SENSORS_TP_PROM_WORDS_NB + 1];
u8 res_index;
 };
diff --git a/drivers/iio/pressure/ms5637.c b/drivers/iio/pressure/ms5637.c
index 5b59a4137d32..fdd557ac71a3 100644
--- a/drivers/iio/pressure/ms5637.c
+++ b/drivers/iio/pressure/ms5637.c
@@ -30,6 +30,11 @@
 
 #include "../common/ms_sensors/ms_sensors_i2c.h"
 
+struct ms_tp_data {
+   const char *name;
+   const struct ms_tp_hw_data *hw;
+};
+
 static const int ms5637_samp_freq[6] = { 960, 480, 240, 120, 60, 30 };
 /* String copy of the above const for readability purpose */
 static const char ms5637_show_samp_freq[] = "960 480 240 120 60 30";
@@ -129,6 +134,7 @@ static const struct iio_info ms5637_info = {
 static int ms5637_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
+   const struct ms_tp_data *data;
struct ms_tp_dev *dev_data;
struct iio_dev *indio_dev;
int ret;
@@ -142,17 +148,25 @@ static int ms5637_probe(struct i2c_client *client,
return -EOPNOTSUPP;
}
 
+   if (id)
+   data = (const struct ms_tp_data *)id->driver_data;
+   else
+   data = device_get_match_data(&client->dev);
+   if (!data)
+   return -EINVAL;
+
indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*dev_data));
if (!indio_dev)
return -ENOMEM;
 
dev_data = iio_priv(indio_dev);
dev_data->client = client;
-   dev_data->res_index = 5;
+   dev_data->res_index = data->hw->max_res_index;
+   dev_data->hw = data->hw;
mutex_init(&dev_data->lock);
 
indio_dev->info = &ms5637_info;
-   indio_dev->name = id->name;
+   indio_dev->name = data->name;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->channels = ms5637_channels;
indio_dev->num_channels = ARRAY_SIZE(ms5637_channels);
@@ -170,20 +184,36 @@ static int ms5637_probe(struct i2c_client *client,
return devm_iio_device_register(&client->dev, indio_dev);
 }
 
+static const struct ms_tp_hw_data ms5637_hw_data  = {
+   .prom_len = 7,
+   .max_res_index = 5
+};
+
+static const struct ms_tp_data ms5637_data = { .name = "ms5637", .hw = 
&ms5637_hw_data };
+
+static const struct ms_tp_data ms5805_data = { .name = "ms5805", .hw = 
&ms5637_hw_data };
+
+static const struct ms_tp_data ms5837_data = { .name = "ms5837", .hw = 
&ms5637_hw_data };
+
+static const struct ms_tp_data ms8607_data = {
+   .name = "ms8607-temppressure",
+   .hw = &ms5637_hw_data,
+};
+
 static const struct i2c_device_id ms5637_id[] = {
-   {"ms5637", 0},
-   {"ms5805", 0},
-   {"ms5837", 0},
-   {"ms8607-temppressure", 0},
+   {"ms5637", (kernel_ulong_t)&ms5637_data },
+   {"ms5805", (kernel_ulong_t)&ms5805_data },
+   {"ms5837", (kernel_ulong_t)&ms5837_data },
+   {"ms8607-temppressure", (kernel_ulong_t)&ms8607_data },
{}
 };
 MODULE_DEVICE_TABLE(i2c, ms5637_id);
 
 static const struct of_device_id ms5637_of_match[] = {
-   { .compatible = "meas,ms5637", },
-   { .compatible = "meas,ms5805", },
-   { .compatible = "meas,ms5837", },
-   { .compatible = "meas,ms8607-temppressure", },
+   { .compatible = "meas,ms5637", .data = &ms5637_data },
+   { .compatible = "meas,ms5805", .data = &ms5805_data },
+   { .compatible = "meas,ms5837", .data = &ms5837_data },
+   { .compatible = "meas,ms8607-temppressure", .data = &ms8607_data },
{ },
 };
 MODULE_DEVICE_TABLE(of, ms5637_of_match);
-- 
2.29.2

[PATCH v2 1/6] dt-bindings: trivial-devices: reorder memsic devices

[Alexandre Belloni]

Reorder memsic compatible strings alphabetically

Signed-off-by: Alexandre Belloni 
---
 Documentation/devicetree/bindings/trivial-devices.yaml | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml 
b/Documentation/devicetree/bindings/trivial-devices.yaml
index bdc2dc318178..e9b64be4b91e 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -148,10 +148,6 @@ properties:
   - maxim,max31730
 # mCube 3-axis 8-bit digital accelerometer
   - mcube,mc3230
-# MEMSIC magnetometer
-  - memsic,mmc35240
-# MEMSIC 2-axis 8-bit digital accelerometer
-  - memsic,mxc6225
 # Measurement Specialities I2C temperature and humidity sensor
   - meas,htu21
 # Measurement Specialities I2C pressure and temperature sensor
@@ -166,6 +162,10 @@ properties:
   - meas,ms8607-temppressure
 # Measurement Specialties temperature sensor
   - meas,tsys01
+# MEMSIC magnetometer
+  - memsic,mmc35240
+# MEMSIC 2-axis 8-bit digital accelerometer
+  - memsic,mxc6225
 # Microchip differential I2C ADC, 1 Channel, 18 bit
   - microchip,mcp3421
 # Microchip differential I2C ADC, 2 Channel, 18 bit
-- 
2.29.2

Re: Old platforms: bring out your dead

[Andrew Lunn]

> Then there are ARM platforms that are old but have still seen some work
> in the past years. If I hear nothing, these will all stay, but if maintainers
> may want to drop them anyway, I can help with that:

Hi Arnd

I notice orion5x is not on this list. Is that because of Debian still
building for it?

I just blew the dust out of my orion5x RDK and booted 5.11-rc2 on it.
orion5x_defconfig needs a few updates, but otherwise it seems to work
O.K.

But i have no idea if there are any real users out there running
modern kernels.

   Andrew

Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander

[AngeloGioacchino Del Regno]

Il 09/01/21 23:11, Linus Walleij ha scritto:

On Sat, Jan 9, 2021 at 3:02 PM AngeloGioacchino Del Regno
 wrote:


The Awinic AW9523(B) is a multi-function I2C gpio expander in a
TQFN-24L package, featuring PWM (max 37mA per pin, or total max
power 3.2Watts) for LED driving capability.

It has two ports with 8 pins per port (for a total of 16 pins),
configurable as either PWM with 1/256 stepping or GPIO input/output,
1.8V logic input; each GPIO can be configured as input or output
independently from each other.

This IC also has an internal interrupt controller, which is capable
of generating an interrupt for each GPIO, depending on the
configuration, and will raise an interrupt on the INTN pin to
advertise this to an external interrupt controller.

Signed-off-by: AngeloGioacchino Del Regno 



Okay!

Overall this driver is in good shape.

The major review comment is that it'd be nice if you look into
using regmaps register cache instead of rolling your own,
and also possibly using regmaps locking rather than your own
as a result of that.

Actually, I really tried to use regmap's FLAT register cache and after 
many, many tries... I had to give up. I just couldn't get it working. :(



+config PINCTRL_AW9523
+   bool "Awinic AW9523/AW9523B I2C GPIO expander pinctrl driver"
+   depends on OF && I2C
+   select PINMUX
+   select PINCONF
+   select GENERIC_PINCONF
+   select GPIOLIB
+   select GPIOLIB_IRQCHIP
+   select REGMAP
+   help
+ The Awinic AW9523/AW9523B is a multi-function I2C GPIO
+ expander with PWM functionality. This driver bundles a
+ pinctrl driver to select the function muxing and a GPIO
+ driver to handle GPIO, when the GPIO function is selected.
+
+ Say yes to enable pinctrl and GPIO support for the AW9523(B).


This:

+   DECLARE_BITMAP(old_masked[AW9523_NUM_PORTS], AW9523_PINS_PER_PORT);
+   DECLARE_BITMAP(masked[AW9523_NUM_PORTS], AW9523_PINS_PER_PORT)
(...)
+   DECLARE_BITMAP(direction_in[AW9523_NUM_PORTS], AW9523_PINS_PER_PORT);

And this looks like a reimplementation of the existing register cache
in regmap. So use regmaps regcache instead. (More notes on that
below.)

This looks good. Right dependencies and helpers.


+   int hw_pin = pin % AW9523_PINS_PER_PORT;


This makes me a bit wary.

Is that really the "hardware pin" as it looks? It looks more like
the bit number 0..7 in the register for that port. I would just name these
"regbit" or just "n" like you do in the irq code.

Yes this is the bit number 0..7, you've understood that right. I guess 
renaming it to "regbit" is a good choice, makes it more understandable!



+/*
+ * __aw9523_gpio_get_direction - Get pin direction
+ * @regmap: Regmap structure
+ * @pin: gpiolib pin number
+ * @hwp: pin index in port register
+ *
+ * Return: Pin direction for success or negative number for error
+ */
+static int __aw9523_gpio_get_direction(struct regmap *regmap, u8 pin, u8 hwp)


Nitpick: I kind of dislike __underscore functions because they have
ambiguous semantics. Sometimes it is a compiler thing. Sometimes
it is an inner function from something wrapped, i.e. it depends on
context what these underscores
mean. What about finding a better name that says what the function
is doing?

My initial idea was aw9523_get_pin_direction... then I changed it to 
include the word "gpio" in an attempt to make it less confusing. Let's 
go for the initial one then!



+static int __aw9523_get_port_state(struct regmap *regmap, u8 pin,
+  u8 hw_pin, unsigned int *state)


Same.

...And here I had another function without __prefix, which was then 
merged into another one as having it separated made no sense, then I 
forgot to remove the underscores. Oops! Removed!



+static int aw9523_gpio_irq_type(struct irq_data *d, unsigned int type)
+{
+   switch (type) {
+   case IRQ_TYPE_NONE:
+   case IRQ_TYPE_LEVEL_MASK:
+   case IRQ_TYPE_LEVEL_HIGH:
+   case IRQ_TYPE_LEVEL_LOW:
+   case IRQ_TYPE_EDGE_BOTH:
+   case IRQ_TYPE_EDGE_RISING:
+   case IRQ_TYPE_EDGE_FALLING:
+   return 0;


Does this hardware really support all these edge types without any
software configuration whatsoever. That looks weird.

And it would indeed be weird: I've rechecked the datasheet again and 
only LEVEL interrupts are supported. As stated there: "When AW9523B 
detect port change, any input state from high-level to low-level or from


low-level to high-level will generate interrupt after 8us internal 
deglitch."

I wonder what happened with my brain, there...


+static irqreturn_t aw9523_irq_thread_func(int irq, void *dev_id)
+{
+   struct aw9523 *awi = (struct aw9523 *)dev_id;
+   unsigned long n, val = 0;
+   unsigned long changed_gpio;
+   unsigned int tmp, port_pin, i, ret;
+
+   for (i = 0; i < AW9523_NUM_PORTS; i++) {
+   port_pin = i * AW9523_PINS_PER_PORT;
+   ret = regm

Re: [PATCH v5 4/4] scatterlist: add sgl_memset()

[Douglas Gilbert]

On 2021-01-07 12:46 p.m., Jason Gunthorpe wrote:

On Mon, Dec 28, 2020 at 06:49:55PM -0500, Douglas Gilbert wrote:

The existing sg_zero_buffer() function is a bit restrictive. For
example protection information (PI) blocks are usually initialized
to 0xff bytes. As its name suggests sgl_memset() is modelled on
memset(). One difference is the type of the val argument which is
u8 rather than int. Plus it returns the number of bytes (over)written.

Change implementation of sg_zero_buffer() to call this new function.

Reviewed-by: Bodo Stroesser 
Signed-off-by: Douglas Gilbert 
  include/linux/scatterlist.h |  3 ++
  lib/scatterlist.c   | 65 +
  2 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 71be65f9ebb5..70d3f1f73df1 100644
+++ b/include/linux/scatterlist.h
@@ -333,6 +333,9 @@ bool sgl_compare_sgl_idx(struct scatterlist *x_sgl, 
unsigned int x_nents, off_t
 struct scatterlist *y_sgl, unsigned int y_nents, off_t 
y_skip,
 size_t n_bytes, size_t *miscompare_idx);
  
+size_t sgl_memset(struct scatterlist *sgl, unsigned int nents, off_t skip,

+ u8 val, size_t n_bytes);
+
  /*
   * Maximum number of entries that will be allocated in one piece, if
   * a list larger than this is required then chaining will be utilized.
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 9332365e7eb6..f06614a880c8 100644
+++ b/lib/scatterlist.c
@@ -1038,26 +1038,7 @@ EXPORT_SYMBOL(sg_pcopy_to_buffer);
  size_t sg_zero_buffer(struct scatterlist *sgl, unsigned int nents,
   size_t buflen, off_t skip)
  {
-   unsigned int offset = 0;
-   struct sg_mapping_iter miter;
-   unsigned int sg_flags = SG_MITER_ATOMIC | SG_MITER_TO_SG;
-
-   sg_miter_start(&miter, sgl, nents, sg_flags);
-
-   if (!sg_miter_skip(&miter, skip))
-   return false;
-
-   while (offset < buflen && sg_miter_next(&miter)) {
-   unsigned int len;
-
-   len = min(miter.length, buflen - offset);
-   memset(miter.addr, 0, len);
-
-   offset += len;
-   }
-
-   sg_miter_stop(&miter);
-   return offset;
+   return sgl_memset(sgl, nents, skip, 0, buflen);
  }
  EXPORT_SYMBOL(sg_zero_buffer);


May as well make this one liner a static inline in the header. Just
rename this function to sgl_memset so the diff is clearer


Yes, fine. I can roll a new version.

Doug Gilbert

Re: [PATCH] soc: mediatek: cmdq: Remove cmdq_pkt_flush()

[Chun-Kuang Hu]

Hi, Matthias:

Chun-Kuang Hu  於 2020年12月3日 週四 上午7:59寫道：
>
> rx_callback is a standard mailbox callback mechanism and could
> cover the function of proprietary cmdq_task_cb, so it is better
> to use the standard one instead of the proprietary one. But
> register rx_callback should before mbox_request_channel(),
> so remove cmdq_pkt_flush() and let client driver implement
> its own synchronous flush.

How do you think about this patch? This patch is derived from [1]
according to Jassi's suggestion [2].

[1] 
https://patchwork.kernel.org/project/linux-mediatek/patch/20200927230422.11610-3-chunkuang...@kernel.org/
[2] 
https://patchwork.kernel.org/project/linux-mediatek/cover/20200927230422.11610-1-chunkuang...@kernel.org/

Regards,
Chun-Kuang.

>
> Signed-off-by: Chun-Kuang Hu 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c | 32 --
>  include/linux/soc/mediatek/mtk-cmdq.h  | 12 --
>  2 files changed, 44 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 505651b0d715..fd3bc39538a1 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -502,36 +502,4 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, 
> cmdq_async_flush_cb cb,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_flush_async);
>
> -struct cmdq_flush_completion {
> -   struct completion cmplt;
> -   bool err;
> -};
> -
> -static void cmdq_pkt_flush_cb(struct cmdq_cb_data data)
> -{
> -   struct cmdq_flush_completion *cmplt;
> -
> -   cmplt = (struct cmdq_flush_completion *)data.data;
> -   if (data.sta != CMDQ_CB_NORMAL)
> -   cmplt->err = true;
> -   else
> -   cmplt->err = false;
> -   complete(&cmplt->cmplt);
> -}
> -
> -int cmdq_pkt_flush(struct cmdq_pkt *pkt)
> -{
> -   struct cmdq_flush_completion cmplt;
> -   int err;
> -
> -   init_completion(&cmplt.cmplt);
> -   err = cmdq_pkt_flush_async(pkt, cmdq_pkt_flush_cb, &cmplt);
> -   if (err < 0)
> -   return err;
> -   wait_for_completion(&cmplt.cmplt);
> -
> -   return cmplt.err ? -EFAULT : 0;
> -}
> -EXPORT_SYMBOL(cmdq_pkt_flush);
> -
>  MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 960704d75994..2c6aa84c0e80 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -288,16 +288,4 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
>  int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
>  void *data);
>
> -/**
> - * cmdq_pkt_flush() - trigger CMDQ to execute the CMDQ packet
> - * @pkt:   the CMDQ packet
> - *
> - * Return: 0 for success; else the error code is returned
> - *
> - * Trigger CMDQ to execute the CMDQ packet. Note that this is a
> - * synchronous flush function. When the function returned, the recorded
> - * commands have been done.
> - */
> -int cmdq_pkt_flush(struct cmdq_pkt *pkt);
> -
>  #endif /* __MTK_CMDQ_H__ */
> --
> 2.17.1
>

Re: [PATCH v5 1/4] sgl_alloc_order: remove 4 GiB limit, sgl_free() warning

[Douglas Gilbert]

On 2021-01-07 12:44 p.m., Jason Gunthorpe wrote:

On Mon, Dec 28, 2020 at 06:49:52PM -0500, Douglas Gilbert wrote:

diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index a59778946404..4986545beef9 100644
+++ b/lib/scatterlist.c
@@ -554,13 +554,15 @@ EXPORT_SYMBOL(sg_alloc_table_from_pages);
  #ifdef CONFIG_SGL_ALLOC
  
  /**

- * sgl_alloc_order - allocate a scatterlist and its pages
+ * sgl_alloc_order - allocate a scatterlist with equally sized elements
   * @length: Length in bytes of the scatterlist. Must be at least one
- * @order: Second argument for alloc_pages()
+ * @order: Second argument for alloc_pages(). Each sgl element size will
+ *be (PAGE_SIZE*2^order) bytes
   * @chainable: Whether or not to allocate an extra element in the scatterlist
- * for scatterlist chaining purposes
+ *for scatterlist chaining purposes
   * @gfp: Memory allocation flags
- * @nent_p: [out] Number of entries in the scatterlist that have pages
+ * @nent_p: [out] Number of entries in the scatterlist that have pages.
+ *   Ignored if NULL is given.
   *
   * Returns: A pointer to an initialized scatterlist or %NULL upon failure.
   */
@@ -574,8 +576,8 @@ struct scatterlist *sgl_alloc_order(unsigned long long 
length,
u32 elem_len;
  
  	nent = round_up(length, PAGE_SIZE << order) >> (PAGE_SHIFT + order);

-   /* Check for integer overflow */
-   if (length > (nent << (PAGE_SHIFT + order)))
+   /* Integer overflow if:  length > nent*2^(PAGE_SHIFT+order) */
+   if (ilog2(length) > ilog2(nent) + PAGE_SHIFT + order)
return NULL;
nalloc = nent;
if (chainable) {


This is a little bit too tortured now, how about this:

if (length >> (PAGE_SHIFT + order) >= UINT_MAX)
return NULL;
nent = length >> (PAGE_SHIFT + order);
if (length & ((1ULL << (PAGE_SHIFT + order)) - 1))
nent++;

if (chainable) {
if (check_add_overflow(nent, 1, &nalloc))
return NULL;
}
else
nalloc = nent;



And your proposal is less <> ?

I'm looking at performance, not elegance and I'm betting that two
ilog2() calls [which boil down to ffs()] are faster than two
right-shift-by-n_s and one left-shift-by-n . Perhaps an extra comment
could help my code by noting that mathematically:
  /* if n > m for positive n and m then: log(n) > log(m) */

My original preference was to drop the check all together but Bart
Van Assche (who wrote that function) wanted me to keep it. Any
function that takes 'order' (i.e. an exponent) can blow up given
a silly value.


The chainable check_add_overflow() call is new and an improvement.

Doug Gilbert

Re: [PATCH] fpga: dfl: fme: Constify static attribute_group structs

[Rikard Falkeborn]

On Sat, Jan 09, 2021 at 01:55:13PM -0800, Tom Rix wrote:
> 
> On 1/8/21 3:54 PM, Rikard Falkeborn wrote:
> > The only usage of these is to put their addresses in arrays of pointers
> > to const attribute_groups. Make them const to allow the compiler to put
> > them in read-only memory.
> >
> > Signed-off-by: Rikard Falkeborn 
> > ---
> >  drivers/fpga/dfl-fme-perf.c | 6 +++---
> 
> This looks ok.
> 
> There are other 'static struct's in drivers/fpga.
> 
> Why is the change limited to this file ?
> 
> Tom
> 

I have a WIP coccinelle script to constify static struct attribute_group
and this is the only file in drivers/fpga which has non-const struct
attribute_group, that's why it's limited to this file. I could have
mentioned that in the commit message.

Rikard


> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
> > index 531266287eee..4299145ef347 100644
> > --- a/drivers/fpga/dfl-fme-perf.c
> > +++ b/drivers/fpga/dfl-fme-perf.c
> > @@ -192,7 +192,7 @@ static struct attribute *fme_perf_cpumask_attrs[] = {
> > NULL,
> >  };
> >  
> > -static struct attribute_group fme_perf_cpumask_group = {
> > +static const struct attribute_group fme_perf_cpumask_group = {
> > .attrs = fme_perf_cpumask_attrs,
> >  };
> >  
> > @@ -225,7 +225,7 @@ static struct attribute *fme_perf_format_attrs[] = {
> > NULL,
> >  };
> >  
> > -static struct attribute_group fme_perf_format_group = {
> > +static const struct attribute_group fme_perf_format_group = {
> > .name = "format",
> > .attrs = fme_perf_format_attrs,
> >  };
> > @@ -239,7 +239,7 @@ static struct attribute *fme_perf_events_attrs_empty[] 
> > = {
> > NULL,
> >  };
> >  
> > -static struct attribute_group fme_perf_events_group = {
> > +static const struct attribute_group fme_perf_events_group = {
> > .name = "events",
> > .attrs = fme_perf_events_attrs_empty,
> >  };
> 

[PATCH v4] driver core: Fix device link device name collision

[Saravana Kannan]

The device link device's name was of the form:
--

This can cause name collision as reported here [1] as device names are
not globally unique. Since device names have to be unique within the
bus/class, add the bus/class name as a prefix to the device names used to
construct the device link device name.

So the devuce link device's name will be of the form:
:--:

[1] - https://lore.kernel.org/lkml/20201229033440.32142-1-mich...@walle.cc/

Cc: sta...@vger.kernel.org
Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
Reported-by: Michael Walle 
Signed-off-by: Saravana Kannan 
---
 Documentation/ABI/testing/sysfs-class-devlink |  4 +--
 .../ABI/testing/sysfs-devices-consumer|  5 ++--
 .../ABI/testing/sysfs-devices-supplier|  5 ++--
 drivers/base/core.c   | 27 ++-
 include/linux/device.h| 12 +
 5 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-devlink 
b/Documentation/ABI/testing/sysfs-class-devlink
index b662f747c83e..8a21ce515f61 100644
--- a/Documentation/ABI/testing/sysfs-class-devlink
+++ b/Documentation/ABI/testing/sysfs-class-devlink
@@ -5,8 +5,8 @@ Description:
Provide a place in sysfs for the device link objects in the
kernel at any given time.  The name of a device link directory,
denoted as ... above, is of the form --
-   where  is the supplier device name and  is
-   the consumer device name.
+   where  is the supplier bus:device name and 
+   is the consumer bus:device name.
 
 What:  /sys/class/devlink/.../auto_remove_on
 Date:  May 2020
diff --git a/Documentation/ABI/testing/sysfs-devices-consumer 
b/Documentation/ABI/testing/sysfs-devices-consumer
index 1f06d74d1c3c..0809fda092e6 100644
--- a/Documentation/ABI/testing/sysfs-devices-consumer
+++ b/Documentation/ABI/testing/sysfs-devices-consumer
@@ -4,5 +4,6 @@ Contact:Saravana Kannan 
 Description:
The /sys/devices/.../consumer: are symlinks to device
links where this device is the supplier.  denotes the
-   name of the consumer in that device link. There can be zero or
-   more of these symlinks for a given device.
+   name of the consumer in that device link and is of the form
+   bus:device name. There can be zero or more of these symlinks
+   for a given device.
diff --git a/Documentation/ABI/testing/sysfs-devices-supplier 
b/Documentation/ABI/testing/sysfs-devices-supplier
index a919e0db5e90..207f5972e98d 100644
--- a/Documentation/ABI/testing/sysfs-devices-supplier
+++ b/Documentation/ABI/testing/sysfs-devices-supplier
@@ -4,5 +4,6 @@ Contact:Saravana Kannan 
 Description:
The /sys/devices/.../supplier: are symlinks to device
links where this device is the consumer.  denotes the
-   name of the supplier in that device link. There can be zero or
-   more of these symlinks for a given device.
+   name of the supplier in that device link and is of the form
+   bus:device name. There can be zero or more of these symlinks
+   for a given device.
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 25e08e5f40bd..47a6faf1605a 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -456,7 +456,9 @@ static int devlink_add_symlinks(struct device *dev,
struct device *con = link->consumer;
char *buf;
 
-   len = max(strlen(dev_name(sup)), strlen(dev_name(con)));
+   len = max(strlen(dev_bus_name(sup)) + strlen(dev_name(sup)),
+ strlen(dev_bus_name(con)) + strlen(dev_name(con)));
+   len += strlen(":");
len += strlen("supplier:") + 1;
buf = kzalloc(len, GFP_KERNEL);
if (!buf)
@@ -470,12 +472,12 @@ static int devlink_add_symlinks(struct device *dev,
if (ret)
goto err_con;
 
-   snprintf(buf, len, "consumer:%s", dev_name(con));
+   snprintf(buf, len, "consumer:%s:%s", dev_bus_name(con), dev_name(con));
ret = sysfs_create_link(&sup->kobj, &link->link_dev.kobj, buf);
if (ret)
goto err_con_dev;
 
-   snprintf(buf, len, "supplier:%s", dev_name(sup));
+   snprintf(buf, len, "supplier:%s:%s", dev_bus_name(sup), dev_name(sup));
ret = sysfs_create_link(&con->kobj, &link->link_dev.kobj, buf);
if (ret)
goto err_sup_dev;
@@ -483,7 +485,7 @@ static int devlink_add_symlinks(struct device *dev,
goto out;
 
 err_sup_dev:
-   snprintf(buf, len, "consumer:%s", dev_name(con));
+   snprintf(buf, len, "consumer:%s:%s", dev_bus_name(con), dev_name(con));
sysfs_remove_link(&sup->kobj, buf);
 err_con_dev:
sysfs_remove_link(&link->link_dev.kobj, "consumer");
@@ -506,7 +508,9 @@ static void devlink

[PATCH 2/2] udf: fix File Tail reclaim following hole append

[Steve Magnani]

From: Steven J. Magnani 

Adjust bookkeeping during creation of an end-of-file hole to ensure that
any File Tail (preallocated extent) is reclaimed when the file is
released.

This also ensures that the file's Extended File Entry is populated with
the proper count of recorded blocks.

Fixes: fa33cdbf3ece ("udf: Fix incorrect final NOT_ALLOCATED (hole) extent 
length")
Signed-off-by: Steven J. Magnani 
---
--- a/fs/udf/inode.c2020-12-28 20:51:29.0 -0600
+++ b/fs/udf/inode.c2021-01-03 07:04:05.759911829 -0600
@@ -535,6 +535,7 @@ static int udf_do_extend_file(struct ino
add = new_block_bytes;
new_block_bytes -= add;
last_ext->extLength += add;
+   iinfo->i_lenExtents += add;
}
 
if (fake) {
@@ -571,6 +572,7 @@ static int udf_do_extend_file(struct ino
   last_ext->extLength, 1);
if (err)
return err;
+   iinfo->i_lenExtents += add;
count++;
}
if (new_block_bytes) {
@@ -580,6 +582,7 @@ static int udf_do_extend_file(struct ino
   last_ext->extLength, 1);
if (err)
return err;
+   iinfo->i_lenExtents += new_block_bytes;
count++;
}
 
@@ -682,7 +685,6 @@ static int udf_extend_file(struct inode
if (err < 0)
goto out;
err = 0;
-   iinfo->i_lenExtents = newsize;
 out:
brelse(epos.bh);
return err;

[PATCH 0/2] udf: fix hole append when File Tail exists

[Steve Magnani]

From: Steven J. Magnani 

Fixes: fa33cdbf3ece ("udf: Fix incorrect final NOT_ALLOCATED (hole) extent 
length")

The fix for incorrect final NOT_ALLOCATED (hole) extent length did not
consider the possibility that an ALLOCATED_NOT_RECORDED extent
("File Tail") may follow the extents describing the file body.

A ftruncate() that adds a hole to the end of such a file now causes the
File Tail to grow into the block that follows it...even if that block
is already in use. The block is not marked as allocated (in the space
bitmap) as part of this process and so can later end up being double-
allocated for some other use (i.e., an ICB or file/directory data).

Other side-effects in this scenario include a failure to reclaim allocated
File Tail blocks when the file is released, and associated misreporting of
the number of recorded blocks in the file's Extended File Entry.

The kernel does not give any indication of any of these issues.
However, an attempt to read the file in Windows 10 fails with
"The file or directory is corrupted and unreadable."

The script below creates a toy UDF filesystem to illustrate the problem.
The filesystem can be dd'd to a flash disk partition of the same size
to observe how Windows handles the corruption.
---
#!/bin/bash

# Tool to illustrate / test fix for bugs in UDF driver
# related to creation of an end-of-file hole.
# Developed using mkudffs from udftools 2.2.

# Terminology:
#  LSN == Logical Sector Number (media / volume relative)
#  LBN == Logical Block Number  (UDF partition relative)


TEST_UDFFS=/tmp/test.udf

# Changing these may alter filesystem layout and/or invalidate the test
UDFFS_SIZE=1M# --size argument to 'truncate' command
UDF_BLOCKSIZE=512
PD_LSN=98# Expected UDF Partition Descriptor location
EFE_LSN=261  # Location of Extended File Entry under test
SBD_LSN=257  # Location of Space Bitmap Descriptor

require()
{
local APP_REALPATH=`which $1`
local PACKAGE_NAME=${2:-$1}
if [ -z "$APP_REALPATH" ] ; then
echo This test requires $1. Please install the $PACKAGE_NAME package.
exit 1
fi 
}

# "Quiet" dd command
ddq()
{
dd $* 2> /dev/null
}

# Extract an 8-bit unsigned value at a specified byte offset ($2)
# of a specified LSN ($1). Hex format can be output by passing x for $3.
# 
extract8()
{
local format=${3:-u}   # Default to unsigned int
local value=`ddq if=$TEST_UDFFS bs=$UDF_BLOCKSIZE skip=$1 count=1 | ddq 
bs=1 skip=$2 count=1 | od -A none -t ${format}1`
[ -z "$value" ] && value=0   # Fail in a sane manner

echo -n $value
}

# Extract a 16-bit little-endian unsigned value at a specified byte offset ($2)
# of a specified LSN ($1). Hex format can be output by passing x for $3.
# 
extract16()
{
local format=${3:-u}   # Default to unsigned int
local value=`ddq if=$TEST_UDFFS bs=$UDF_BLOCKSIZE skip=$1 count=1 | ddq 
bs=1 skip=$2 count=2 | od -A none -t ${format}2 --endian=little`
[ -z "$value" ] && value=0   # Fail in a sane manner

echo -n $value
}

# Extract a 32-bit little-endian unsigned value at a specified byte offset ($2)
# of a specified LSN ($1). Hex format can be output by passing x for $3.
# 
extract32()
{
local format=${3:-u}   # Default to unsigned int
local value=`ddq if=$TEST_UDFFS bs=$UDF_BLOCKSIZE skip=$1 count=1 | ddq 
bs=1 skip=$2 count=4 | od -A none -t ${format}4 --endian=little`
[ -z "$value" ] && value=0   # Fail in a sane manner

echo -n $value
}


# Extract a 64-bit little-endian unsigned value at a specified byte offset ($2)
# of a specified LSN ($1). Hex format can be output by passing x for $3.
# 
extract64()
{
local format=${3:-u}   # Default to unsigned int
local value=`ddq if=$TEST_UDFFS bs=$UDF_BLOCKSIZE skip=$1 count=1 | ddq 
bs=1 skip=$2 count=8 | od -A none -t ${format}8 --endian=little`
[ -z "$value" ] && value=0   # Fail in a sane manner

echo -n $value
}

read_extent_start_lbn()
{
local extent_lbn_offset=$((220 + $2 * 16))
extract32 $1 $extent_lbn_offset
}

# $1 == LSN of EFE
# $2 == Extent index of interest
read_extent_type()
{
local extent_type_offset=$((219 + $2 * 16))
local type_byte=`extract8 $1 $extent_type_offset`
expr $type_byte / 64
}

# $1 == LSN of EFE
# $2 == Extent index of interest
read_extent_len()
{
local extent_len_offset=$((216 + $2 * 16))
local extent_typelen=`extract32 $1 $extent_len_offset`
local extent_type=`read_extent_type $1 $2`
echo $(($extent_typelen & 0x3FFF))
}


# $1 == LSN of EFE
# $2 == Extent index of interest
# $3 == Expected length field (including type) of extent - 8 lowercase hex 
digits
verify_extent_typelen()
{
local extent_len_offset=$((216 + $2 * 16))
local found_extent_len=`extract32 $1 $extent_len_offset x`
if [ $found_extent_len != $3 ] ; then
echo FAILURE: expected extent[$2] type/length $3, but EFE has 
$found_extent_len
exitcode=1
fi 
}

# $1 = LSN
# $2 = Expected tag ID value (dec

[PATCH 1/2] udf: fix hole append when File Tail exists

[Steve Magnani]

From: Steven J. Magnani 

When an ALLOCATED_NOT_RECORDED extent ("File Tail") follows the
extents describing a file body, don't (improperly) try to make use of it
as part of appending a hole to the file.

Fixes: fa33cdbf3ece ("udf: Fix incorrect final NOT_ALLOCATED (hole) extent 
length")
Signed-off-by: Steven J. Magnani 
---
--- a/fs/udf/inode.c2020-12-28 20:51:29.0 -0600
+++ b/fs/udf/inode.c2021-01-02 17:00:39.794157840 -0600
@@ -520,8 +520,7 @@ static int udf_do_extend_file(struct ino
prealloc_loc = last_ext->extLocation;
prealloc_len = last_ext->extLength;
/* Mark the extent as a hole */
-   last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED |
-   (last_ext->extLength & UDF_EXTENT_LENGTH_MASK);
+   last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED;
last_ext->extLocation.logicalBlockNum = 0;
last_ext->extLocation.partitionReferenceNum = 0;
}
@@ -626,7 +625,6 @@ static void udf_do_extend_final_block(st
 
 static int udf_extend_file(struct inode *inode, loff_t newsize)
 {
-
struct extent_position epos;
struct kernel_lb_addr eloc;
uint32_t elen;
@@ -639,6 +637,7 @@ static int udf_extend_file(struct inode
struct kernel_long_ad extent;
int err = 0;
int within_final_block;
+   loff_t hole_size = 0;
 
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_SHORT)
adsize = sizeof(struct short_ad);
@@ -648,7 +647,8 @@ static int udf_extend_file(struct inode
BUG();
 
etype = inode_bmap(inode, first_block, &epos, &eloc, &elen, &offset);
-   within_final_block = (etype != -1);
+   within_final_block = (etype == (EXT_RECORDED_ALLOCATED >> 30)) ||
+(etype == (EXT_NOT_RECORDED_NOT_ALLOCATED >> 30));
 
if ((!epos.bh && epos.offset == udf_file_entry_alloc_offset(inode)) ||
(epos.bh && epos.offset == sizeof(struct allocExtDesc))) {
@@ -658,9 +658,15 @@ static int udf_extend_file(struct inode
extent.extLocation.partitionReferenceNum = 0;
extent.extLength = EXT_NOT_RECORDED_NOT_ALLOCATED;
} else {
+   int8_t bmap_etype = etype;
epos.offset -= adsize;
etype = udf_next_aext(inode, &epos, &extent.extLocation,
  &extent.extLength, 0);
+   if ((bmap_etype == -1) &&
+   (etype == (EXT_NOT_RECORDED_ALLOCATED >> 30))) {
+   /* offset is relative to prealloc extent end */
+   hole_size = extent.extLength;
+   }
extent.extLength |= etype << 30;
}
 
@@ -674,9 +680,9 @@ static int udf_extend_file(struct inode
udf_do_extend_final_block(inode, &epos, &extent,
  partial_final_block);
} else {
-   loff_t add = ((loff_t)offset << sb->s_blocksize_bits) |
+   hole_size += ((loff_t)offset << sb->s_blocksize_bits) |
 partial_final_block;
-   err = udf_do_extend_file(inode, &epos, &extent, add);
+   err = udf_do_extend_file(inode, &epos, &extent, hole_size);
}
 
if (err < 0)
@@ -700,7 +706,7 @@ static sector_t inode_getblk(struct inod
loff_t lbcount = 0, b_off = 0;
udf_pblk_t newblocknum, newblock;
sector_t offset = 0;
-   int8_t etype;
+   int8_t etype = -1;
struct udf_inode_info *iinfo = UDF_I(inode);
udf_pblk_t goal = 0, pgoal = iinfo->i_location.logicalBlockNum;
int lastblock = 0;
@@ -729,14 +735,22 @@ static sector_t inode_getblk(struct inod
cur_epos.bh = next_epos.bh;
}
 
-   lbcount += elen;
-
prev_epos.block = cur_epos.block;
cur_epos.block = next_epos.block;
 
prev_epos.offset = cur_epos.offset;
cur_epos.offset = next_epos.offset;
 
+   /* Corner case: preallocated extent that stops short of
+* desired block
+*/
+   if ((etype == (EXT_NOT_RECORDED_ALLOCATED >> 30)) &&
+   ((lbcount + elen) <= b_off)) {
+   etype = -1;
+   break;
+   }
+
+   lbcount += elen;
etype = udf_next_aext(inode, &next_epos, &eloc, &elen, 1);
if (etype == -1)
break;

Re: upstream build error (11)

[Andrew Morton]

On Sat, 9 Jan 2021 21:41:23 +0100 Dmitry Vyukov  wrote:

> On Wed, Oct 28, 2020 at 9:31 AM syzbot
>  wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:4d09c1d9 Merge tag 'devicetree-fixes-for-5.10-1' of git://..
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1615899c50
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=a5c844e56cc50cdb
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5b0d0de84d6c65b8dd2b
> > compiler:   gcc (GCC) 10.1.0-syz 20200507
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+5b0d0de84d6c65b8d...@syzkaller.appspotmail.com
> >
> > mm/process_vm_access.c:277:5: error: implicit declaration of function 
> > 'in_compat_syscall'; did you mean 'in_ia32_syscall'? 
> > [-Werror=implicit-function-declaration]
> 
> Other build failures are piling behind this.
> 
> #syz fix: mm/process_vm_access: Add missing #include 

For some reason I cant reproduce this with that .config, but presumably
this is the fix?


From: Andrew Morton 
Subject: mm/process_vm_access.c: include compat.h

mm/process_vm_access.c:277:5: error: implicit declaration of function 
'in_compat_syscall'; did you mean 'in_ia32_syscall'? 
[-Werror=implicit-function-declaration]

Fixes: 38dc5079da7081e "Fix compat regression in process_vm_rw()"
Reported-by: syzbot+5b0d0de84d6c65b8d...@syzkaller.appspotmail.com
Cc: Kyle Huey 
Cc: Jens Axboe 
Cc: Al Viro 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
---

 mm/process_vm_access.c |1 +
 1 file changed, 1 insertion(+)

--- a/mm/process_vm_access.c~a
+++ a/mm/process_vm_access.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
_

[RFC] removing explicit #define DEBUG

[Tom Rix]

In cleaning up the printf %hh's I have found a number of files

that explicitly do a

#define DEBUG

with no comments or surrounding #ifdef CONFIG_MY_DEBUG_FEATURE/#endif

If I saw this in a review, I would assume this was leftover devel code and nak 
the review.

Finding and removing are pretty trival, i believe there are only around 10.

I am bringing this up because if the existing code depends on the DEBUG,

ex/ getting lucking with timing, then the change would introduce problems.


Tom

Re: [PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

[Samuel Holland]

On 12/31/20 8:29 AM, Paul Kocialkowski wrote:
> The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
> found on Allwinner SoCs such as the A31 and V3/V3s.
> 
> It is a standalone block, connected to the CSI controller on one side
> and to the MIPI D-PHY block on the other. It has a dedicated address
> space, interrupt line and clock.
> 
> It is represented as a V4L2 subdev to the CSI controller and takes a
> MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
> media controller API.
> 
> Only 8-bit and 10-bit Bayer formats are currently supported.
> While up to 4 internal channels to the CSI controller exist, only one
> is currently supported by this implementation.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/media/platform/sunxi/Kconfig  |   1 +
>  drivers/media/platform/sunxi/Makefile |   1 +
>  .../platform/sunxi/sun6i-mipi-csi2/Kconfig|  12 +
>  .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
>  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 590 ++
>  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 117 
>  6 files changed, 725 insertions(+)
>  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
>  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
>  create mode 100644 
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
>  create mode 100644 
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
> 
> diff --git a/drivers/media/platform/sunxi/Kconfig 
> b/drivers/media/platform/sunxi/Kconfig
> index 7151cc249afa..9684e07454ad 100644
> --- a/drivers/media/platform/sunxi/Kconfig
> +++ b/drivers/media/platform/sunxi/Kconfig
> @@ -2,3 +2,4 @@
>  
>  source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
>  source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> +source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
> diff --git a/drivers/media/platform/sunxi/Makefile 
> b/drivers/media/platform/sunxi/Makefile
> index fc537c9f5ca9..887a7cae8fca 100644
> --- a/drivers/media/platform/sunxi/Makefile
> +++ b/drivers/media/platform/sunxi/Makefile
> @@ -2,5 +2,6 @@
>  
>  obj-y+= sun4i-csi/
>  obj-y+= sun6i-csi/
> +obj-y+= sun6i-mipi-csi2/
>  obj-y+= sun8i-di/
>  obj-y+= sun8i-rotate/
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig 
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> new file mode 100644
> index ..47f1bb0779a8
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> @@ -0,0 +1,12 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config VIDEO_SUN6I_MIPI_CSI2
> + tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + depends on PM && COMMON_CLK && VIDEO_V4L2
> + select REGMAP_MMIO
> + select PHY_SUN6I_MIPI_DPHY
> + select MEDIA_CONTROLLER
> + select VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> + help
> +Support for the Allwinner A31 MIPI CSI-2 Controller.
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile 
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> new file mode 100644
> index ..14e4e03818b5
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
> +
> +obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c 
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> new file mode 100644
> index ..87307beda4cf
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> @@ -0,0 +1,590 @@
[...]
> +/* Base Driver */
> +
> +static int sun6i_mipi_csi2_suspend(struct device *dev)
> +{
> + struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(cdev->clk_mod);
> + clk_disable_unprepare(cdev->clk_bus);
> + reset_control_assert(cdev->reset);
> +
> + return 0;
> +}
> +
> +static int sun6i_mipi_csi2_resume(struct device *dev)
> +{
> + struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = reset_control_deassert(cdev->reset);
> + if (ret) {
> + dev_err(cdev->dev, "failed to deassert reset\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(cdev->clk_bus);
> + if (ret) {
> + dev_err(cdev->dev, "failed to enable bus clock\n");
> + goto error_reset;
> + }
> +
> + ret = clk_prepare_enable(cdev->clk_mod);
> + if (ret) {
> + dev_err(cdev->dev, "failed to enable module clock\n");
> + goto error_clk_bus;
> + }
> +
> + return 0;
> +
> +error_clk_bus:
> + clk_disable_unprepare(cdev->clk_bus);
> +
> +error_reset:
> + reset_cont

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang  wrote:
>
> Hi Arnd,
>
> On 9 Jan 2021, at 9:55 am, Arnd Bergmann  wrote:
>
> * nspire -- added in 2013, no notable changes after 2015
>
>
> I believe this is still in active use. I’ve CC’d Fabian into this thread who’s
> probably in a better position to respond to this.

Ok, moving it to the "keep around for now list" as well, to be on the
safe side. Would either of you already have a guess for how long it makes
sense to update kernels on it?

I see that this is one of the more limited platforms with just 32MB
of RAM (64MB in case of CX), and kernels only get more bloated over
time, so I expect at some point you will be stuck with running old
software.

Wikipedia tells me that new models came out recently. Are you
planning to add support for those as well?

  Arnd

Re: [PATCH] iov_iter: optimise iter type checking

[Pavel Begunkov]

On 09/01/2021 21:49, David Laight wrote:
> From: Al Viro
>> Sent: 09 January 2021 17:04
>>
>> On Sat, Jan 09, 2021 at 04:09:08PM +, Pavel Begunkov wrote:
>>> On 06/12/2020 16:01, Pavel Begunkov wrote:
 On 21/11/2020 14:37, Pavel Begunkov wrote:
> The problem here is that iov_iter_is_*() helpers check types for
> equality, but all iterate_* helpers do bitwise ands. This confuses
> compilers, so even if some cases were handled separately with
> iov_iter_is_*(), corresponding ifs in iterate*() right after are not
> eliminated.
>
> E.g. iov_iter_npages() first handles discards, but iterate_all_kinds()
> still checks for discard iter type and generates unreachable code down
> the line.

 Ping. This one should be pretty simple
>>>
>>> Ping please. Any doubts about this patch?
>>
>> Sorry, had been buried in other crap.  I'm really not fond of the
>> bitmap use; if anything, I would rather turn iterate_and_advance() et.al.
>> into switches...
> 
> That loses any optimisations in the order of the comparisons.
> The bitmap also allows different groups to be optimised for in different code 
> paths.

You still can have a fast path and even retoss ITER_* for convenience.
Other use cases are not important at the current state.

> 
>> How about moving the READ/WRITE part into MSB?  Checking is just as fast
>> (if not faster - check for sign vs. checking bit 0).  And turn the
>> types into straight (dense) enum.
> 
> Does any code actually look at the fields as a pair?
> Would it even be better to use separate bytes?
> Even growing the on-stack structure by a word won't really matter.

u8 type, rw;

That won't bloat the struct. I like the idea. If used together compilers
can treat it as u16.

btw there is a 4B hole just after for x64.

-- 
Pavel Begunkov

Re: [PATCH 2/2] dt-bindings: pinctrl: Add bindings for Awinic AW9523/AW9523B

[Linus Walleij]

Hi Angelo,

thanks for your patch!

On Sat, Jan 9, 2021 at 3:02 PM AngeloGioacchino Del Regno
 wrote:

> +#PIN CONFIGURATION NODES
> +patternProperties:
> +  '^.*$':
> +if:
> +  type: object
> +then:
> +  properties:
> +pins:
> +  description:
> +List of gpio pins affected by the properties specified in
> +this subnode.
> +  items:
> +pattern: "^gpio([0-9]|1[0-5])$"
> +  minItems: 1
> +  maxItems: 16
> +
> +function:
> +  description:
> +Specify the alternative function to be configured for the
> +specified pins.
> +
> +  enum: [ gpio, pwm ]
> +
> +bias-disable: true
> +bias-pull-down: true
> +bias-pull-up: true
> +drive-open-drain: true
> +drive-push-pull: true
> +input-enable: true
> +output-high: true
> +output-low: true
> +
> +  required:
> +- pins
> +- function

Is it possible to just $ref /pinctrl/pincfg-node.yaml# for some of this?

Yours,
Linus Walleij

Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander

[Linus Walleij]

On Sat, Jan 9, 2021 at 6:24 PM kernel test robot  wrote:

>  > 880  gpioirq->parent_domain = NULL;

The autobuilder is complaining because your irq chip is not
hierarchical and this is only used for hierarchical irqchips.
I think you can just delete this line.

Yours,
Linus Walleij

Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander

[Linus Walleij]

On Sat, Jan 9, 2021 at 3:02 PM AngeloGioacchino Del Regno
 wrote:

> The Awinic AW9523(B) is a multi-function I2C gpio expander in a
> TQFN-24L package, featuring PWM (max 37mA per pin, or total max
> power 3.2Watts) for LED driving capability.
>
> It has two ports with 8 pins per port (for a total of 16 pins),
> configurable as either PWM with 1/256 stepping or GPIO input/output,
> 1.8V logic input; each GPIO can be configured as input or output
> independently from each other.
>
> This IC also has an internal interrupt controller, which is capable
> of generating an interrupt for each GPIO, depending on the
> configuration, and will raise an interrupt on the INTN pin to
> advertise this to an external interrupt controller.
>
> Signed-off-by: AngeloGioacchino Del Regno 
> 

Okay!

Overall this driver is in good shape.

The major review comment is that it'd be nice if you look into
using regmaps register cache instead of rolling your own,
and also possibly using regmaps locking rather than your own
as a result of that.

> +config PINCTRL_AW9523
> +   bool "Awinic AW9523/AW9523B I2C GPIO expander pinctrl driver"
> +   depends on OF && I2C
> +   select PINMUX
> +   select PINCONF
> +   select GENERIC_PINCONF
> +   select GPIOLIB
> +   select GPIOLIB_IRQCHIP
> +   select REGMAP
> +   help
> + The Awinic AW9523/AW9523B is a multi-function I2C GPIO
> + expander with PWM functionality. This driver bundles a
> + pinctrl driver to select the function muxing and a GPIO
> + driver to handle GPIO, when the GPIO function is selected.
> +
> + Say yes to enable pinctrl and GPIO support for the AW9523(B).

This:

+   DECLARE_BITMAP(old_masked[AW9523_NUM_PORTS], AW9523_PINS_PER_PORT);
+   DECLARE_BITMAP(masked[AW9523_NUM_PORTS], AW9523_PINS_PER_PORT)
(...)
+   DECLARE_BITMAP(direction_in[AW9523_NUM_PORTS], AW9523_PINS_PER_PORT);

And this looks like a reimplementation of the existing register cache
in regmap. So use regmaps regcache instead. (More notes on that
below.)

This looks good. Right dependencies and helpers.

> +   int hw_pin = pin % AW9523_PINS_PER_PORT;

This makes me a bit wary.

Is that really the "hardware pin" as it looks? It looks more like
the bit number 0..7 in the register for that port. I would just name these
"regbit" or just "n" like you do in the irq code.

> +/*
> + * __aw9523_gpio_get_direction - Get pin direction
> + * @regmap: Regmap structure
> + * @pin: gpiolib pin number
> + * @hwp: pin index in port register
> + *
> + * Return: Pin direction for success or negative number for error
> + */
> +static int __aw9523_gpio_get_direction(struct regmap *regmap, u8 pin, u8 hwp)

Nitpick: I kind of dislike __underscore functions because they have
ambiguous semantics. Sometimes it is a compiler thing. Sometimes
it is an inner function from something wrapped, i.e. it depends on
context what these underscores
mean. What about finding a better name that says what the function
is doing?

> +static int __aw9523_get_port_state(struct regmap *regmap, u8 pin,
> +  u8 hw_pin, unsigned int *state)

Same.

> +static int aw9523_gpio_irq_type(struct irq_data *d, unsigned int type)
> +{
> +   switch (type) {
> +   case IRQ_TYPE_NONE:
> +   case IRQ_TYPE_LEVEL_MASK:
> +   case IRQ_TYPE_LEVEL_HIGH:
> +   case IRQ_TYPE_LEVEL_LOW:
> +   case IRQ_TYPE_EDGE_BOTH:
> +   case IRQ_TYPE_EDGE_RISING:
> +   case IRQ_TYPE_EDGE_FALLING:
> +   return 0;

Does this hardware really support all these edge types without any
software configuration whatsoever. That looks weird.

> +static irqreturn_t aw9523_irq_thread_func(int irq, void *dev_id)
> +{
> +   struct aw9523 *awi = (struct aw9523 *)dev_id;
> +   unsigned long n, val = 0;
> +   unsigned long changed_gpio;
> +   unsigned int tmp, port_pin, i, ret;
> +
> +   for (i = 0; i < AW9523_NUM_PORTS; i++) {
> +   port_pin = i * AW9523_PINS_PER_PORT;
> +   ret = regmap_read(awi->regmap,
> + AW9523_REG_IN_STATE(port_pin),
> + &tmp);
> +   if (ret)
> +   return ret;
> +
> +   val |= (u8)tmp << (i * 8);
> +   }

Can you convince me that these are not just consecutive registers
that could be read in one go with regmap_bulk_read()?
(I could not unwind the macros in my head, and you have the
datasheet I suppose.)

> +/*
> + * aw9523_irq_bus_sync_unlock - Synchronize state and unlock
> + * @d: irq data
> + *
> + * Writes the interrupt mask bits (found in the bit map) to the
> + * hardware, then unlocks the bus.
> + */
> +static void aw9523_irq_bus_sync_unlock(struct irq_data *d)
> +{
> +   struct aw9523 *awi = gpiochip_get_data(irq_data_get_irq_chip_data(d));
> +   int i;
> +
> +   for (i = 0; i < AW9523_NUM_PORTS; i++) {
> +   if (bitmap_equal(awi->irq

Re: [PATCH -next] fpga: Use DEFINE_SPINLOCK() for spinlock

[Tom Rix]

On 12/28/20 5:51 AM, Zheng Yongjun wrote:
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
>
> Signed-off-by: Zheng Yongjun 

This looks fine.

Reviewed-by: Tom Rix 

> ---
>  drivers/fpga/fpga-bridge.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
> index 2deccacc3aa7..e9266b2a357f 100644
> --- a/drivers/fpga/fpga-bridge.c
> +++ b/drivers/fpga/fpga-bridge.c
> @@ -17,7 +17,7 @@ static DEFINE_IDA(fpga_bridge_ida);
>  static struct class *fpga_bridge_class;
>  
>  /* Lock for adding/removing bridges to linked lists*/
> -static spinlock_t bridge_list_lock;
> +static DEFINE_SPINLOCK(bridge_list_lock);
>  
>  /**
>   * fpga_bridge_enable - Enable transactions on the bridge
> @@ -479,8 +479,6 @@ static void fpga_bridge_dev_release(struct device *dev)
>  
>  static int __init fpga_bridge_dev_init(void)
>  {
> - spin_lock_init(&bridge_list_lock);
> -
>   fpga_bridge_class = class_create(THIS_MODULE, "fpga_bridge");
>   if (IS_ERR(fpga_bridge_class))
>   return PTR_ERR(fpga_bridge_class);

Re: [PATCH v7 net-next 2/2] net: dsa: qca: ar9331: export stats64

[Jakub Kicinski]

On Thu, 7 Jan 2021 15:36:45 +0100 Andrew Lunn wrote:
> > +static void ar9331_get_stats64(struct dsa_switch *ds, int port,
> > +  struct rtnl_link_stats64 *s)
> > +{
> > +   struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> > +   struct ar9331_sw_port *p = &priv->port[port];
> > +
> > +   spin_lock(&p->stats_lock);
> > +   memcpy(s, &p->stats, sizeof(*s));
> > +   spin_unlock(&p->stats_lock);
> > +}  
> 
> This should probably wait until Vladimir's changes for stat64 are
> merged, so this call can sleep. You can then return up to date
> statistics.

Plus rx_nohandler is still updated from HW stats here :|

+   stats->rx_nohandler += raw.filtered;

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 12:32 AM Steven Rostedt  wrote:
>
> On Fri, 8 Jan 2021 23:55:06 +0100
> Arnd Bergmann  wrote:
>
> > * h8300: Steven Rostedt has repeatedly asked about it to be removed
> >or fixed in 2020 with no reply. This was killed before in 2013, added 
> > back
> >in 2015 but has been mostly stale again since 2016
>
> "I'm not dead yet!", "You're not fooling anyone!"
>
> The patch that I sent that fixes a critical bug in the architecture
> (irq disabling does no compiler barriers!), has been ignored since
> September 18th.
>
>   https://lore.kernel.org/lkml/20200918152507.71186...@gandalf.local.home/
>
> I'm thinking to kill it and see if that causes any complaints.

I'm happy to queue the patches in my asm-generic tree if you send them
my way. Then they can spend some more time in linux-next and give
possible users one last chance to speak up.

   Arnd

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 1:18 AM Linus Walleij  wrote:
>
> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann  wrote:
>
> > * u300 -- added in 2009, no notable changes since 2013
>
> We can delete this, I don't see any use for it moving forward.
> I'll send patches to drop it.

Ok, thanks for confirming.

> > * ep93xx -- added in 2006, LinusW still working on it, any users left?
>
> I was contacted by a user of this platform, using it with mainline and
> fixing bugs in the GPIO driver for this kernel cycle. So it has users.
>
> > * gemini -- added in 2009, LinusW still working on it
>
> This has active support and users through OpenWrt on the
> D-Link DNS-313 and DIR-685.
>
> > * ixp4xx -- prehistoric, but LinusW and I are still working on it
>
> One more developer has contacted me showing strong interest
> in the platform.
>
> > * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
>
> I use this for various subsystem testing actually (for the hardware that
> is on the board, not necessarily Nomadik per se). So it is in pretty
> active use.
>
> > * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
>
> There were some users from OpenEmbedded some years back
> and active patches from Andrea Adami beside RMK and me. Paging
> Andrea to see if he still has interest in the platform. (I don't.)

And thanks for confirming that we still want to keep all of these.

One thing I'd really like to see for the ep93xx is to have it
use the COMMON_CLK interfaces. I have patches for OMAP1
that I need to finalize, and then this one will be the last ARM
platform without it. I also still hope we can eventually get ep93xx
into multiplatform build.

  Arnd

Re: [PATCH] fpga: dfl: fme: Constify static attribute_group structs

[Tom Rix]

On 1/8/21 3:54 PM, Rikard Falkeborn wrote:
> The only usage of these is to put their addresses in arrays of pointers
> to const attribute_groups. Make them const to allow the compiler to put
> them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn 
> ---
>  drivers/fpga/dfl-fme-perf.c | 6 +++---

This looks ok.

There are other 'static struct's in drivers/fpga.

Why is the change limited to this file ?

Tom

>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
> index 531266287eee..4299145ef347 100644
> --- a/drivers/fpga/dfl-fme-perf.c
> +++ b/drivers/fpga/dfl-fme-perf.c
> @@ -192,7 +192,7 @@ static struct attribute *fme_perf_cpumask_attrs[] = {
>   NULL,
>  };
>  
> -static struct attribute_group fme_perf_cpumask_group = {
> +static const struct attribute_group fme_perf_cpumask_group = {
>   .attrs = fme_perf_cpumask_attrs,
>  };
>  
> @@ -225,7 +225,7 @@ static struct attribute *fme_perf_format_attrs[] = {
>   NULL,
>  };
>  
> -static struct attribute_group fme_perf_format_group = {
> +static const struct attribute_group fme_perf_format_group = {
>   .name = "format",
>   .attrs = fme_perf_format_attrs,
>  };
> @@ -239,7 +239,7 @@ static struct attribute *fme_perf_events_attrs_empty[] = {
>   NULL,
>  };
>  
> -static struct attribute_group fme_perf_events_group = {
> +static const struct attribute_group fme_perf_events_group = {
>   .name = "events",
>   .attrs = fme_perf_events_attrs_empty,
>  };

Re: [PATCH net-next] net/bridge: fix misspellings using codespell tool

[Jakub Kicinski]

On Thu, 7 Jan 2021 20:03:49 -0800 Randy Dunlap wrote:
> On 1/7/21 6:53 PM, menglong8.d...@gmail.com wrote:
> > From: Menglong Dong 
> > 
> > Some typos are found out by codespell tool:
> > 
> > $ codespell ./net/bridge/
> > ./net/bridge/br_stp.c:604: permanant  ==> permanent
> > ./net/bridge/br_stp.c:605: persistance  ==> persistence
> > ./net/bridge/br.c:125: underlaying  ==> underlying
> > ./net/bridge/br_input.c:43: modue  ==> mode
> > ./net/bridge/br_mrp.c:828: Determin  ==> Determine
> > ./net/bridge/br_mrp.c:848: Determin  ==> Determine
> > ./net/bridge/br_mrp.c:897: Determin  ==> Determine
> > 
> > Fix typos found by codespell.
> > 
> > Signed-off-by: Menglong Dong   
> 
> LGTM. Thanks.
> 
> Acked-by: Randy Dunlap 

Applied, thanks!

Re: [PATCH net-next 0/4] net: ipa: support COMPILE_TEST

[Jakub Kicinski]

On Thu,  7 Jan 2021 17:34:00 -0600 Alex Elder wrote:
> This series adds the IPA driver as a possible target when
> the COMPILE_TEST configuration is enabled.  Two small changes to
> dependent subsystems needed to be made for this to work.
> 
> Version 2 of this series adds one more patch, which adds the
> declation of struct page to "gsi_trans.h".  The Intel kernel test
> robot reported that this was a problem for the alpha build.
> 
> David/Jakub, please take all four of these patches through the
> net-next tree if you find them acceptable.

Applied, thanks a lot for doing this!

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau  wrote:
>
> On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> > * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
> >   indications that 486 have no users either on recent kernels.
> >   There is still the Vortex86 family of SoCs, and the oldest of those were
> >   486SX-class, but all the modern ones are 586-class.
>
> These also are the last generation of fanless x86 boards with 100% compatible
> controllers, that some people have probably kept around because these don't
> age much and have plenty of connectivity. I've used an old one a few times
> to plug in an old floppy drive, ISA SCSI controllers to access an old tape
> drive and a few such things. That doesn't mean that it's a good justification
> not to remove them, what I rather mean is that *if* there is no benefit
> in dropping them maybe we can keep them. On the other hand, good luck for
> running a modern OS on these, when 16MB-32MB RAM was about the maximum that
> was commonly found by then (though if people kept them around that's probably
> because they were well equipped, like that 64MB 386DX I'm having :-)).

I think there were 486s with up to 256MB, which would still qualify as barely
usable for a minimal desktop, or as comfortable for a deeply embedded
system. The main limit was apparently the cacheable RAM, which is limited
by the amount of L2 cache -- you needed a rare 1MB of external L2-cache to
have 256MB of cached RAM, while more common 256KB of cache would
be good for 64MB. Vortex86SX has no FPU or L2 cache at all, but supports
256MB of DDR2.

I checked some distros and found that aside from Debian inadvertently
dropping i486 a long time ago, Slackware 14.2 (from 2016) also requires
an i586 or higher now. Slackware 14.1 (from 2013) is still supported
on i486 but ships with a Linux-3.10 kernel.  archlinux32 is the only
binary distro I could find that still officially supports i486, which in their
case means anything below an i686 (cmov+mmx+sse). If it gets
dropped, it might require some users to stay on LTS kernels
after the distro moves to i586-only kernel, but as there are no
long-term supported releases, there is also no need to coordinate
the timing.

As with the other older platforms, the main question to ask is:
Are there users that are better off running a future LTS kernel on this
hardware than the v5.10.y version or something older?

 Arnd

RE: [PATCH] iov_iter: optimise iter type checking

[David Laight]

From: Al Viro
> Sent: 09 January 2021 17:04
> 
> On Sat, Jan 09, 2021 at 04:09:08PM +, Pavel Begunkov wrote:
> > On 06/12/2020 16:01, Pavel Begunkov wrote:
> > > On 21/11/2020 14:37, Pavel Begunkov wrote:
> > >> The problem here is that iov_iter_is_*() helpers check types for
> > >> equality, but all iterate_* helpers do bitwise ands. This confuses
> > >> compilers, so even if some cases were handled separately with
> > >> iov_iter_is_*(), corresponding ifs in iterate*() right after are not
> > >> eliminated.
> > >>
> > >> E.g. iov_iter_npages() first handles discards, but iterate_all_kinds()
> > >> still checks for discard iter type and generates unreachable code down
> > >> the line.
> > >
> > > Ping. This one should be pretty simple
> >
> > Ping please. Any doubts about this patch?
> 
> Sorry, had been buried in other crap.  I'm really not fond of the
> bitmap use; if anything, I would rather turn iterate_and_advance() et.al.
> into switches...

That loses any optimisations in the order of the comparisons.
The bitmap also allows different groups to be optimised for in different code 
paths.

> How about moving the READ/WRITE part into MSB?  Checking is just as fast
> (if not faster - check for sign vs. checking bit 0).  And turn the
> types into straight (dense) enum.

Does any code actually look at the fields as a pair?
Would it even be better to use separate bytes?
Even growing the on-stack structure by a word won't really matter.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH v8 04/20] dlb: add device ioctl layer and first three ioctls

[Dan Williams]

On Sat, Jan 9, 2021 at 12:34 AM Greg KH  wrote:
>
> On Sat, Jan 09, 2021 at 07:49:24AM +, Chen, Mike Ximing wrote:
> > > > +static int dlb_ioctl_arg_size[NUM_DLB_CMD] = {
> > > > + sizeof(struct dlb_get_device_version_args),
> > > > + sizeof(struct dlb_create_sched_domain_args),
> > > > + sizeof(struct dlb_get_num_resources_args)
> > >
> > > That list.
> > >
> > > Ugh, no.  that's no way to write maintainable code that you will be able
> > > to understand in 2 years.
> > >
> >
> > dlb_ioctl() was implemented with switch-case and real function calls 
> > previously.
> > We changed to the table/list implementation during a code restructure. I 
> > will move
> > back to the old implementation.
>
> Who said to change this?  And why did they say that?  Please go back to
> those developers and point them at this thread so that doesn't happen
> again...
>
> > > > +{
> > > > + struct dlb *dlb;
> > > > + dlb_ioctl_fn_t fn;
> > > > + u32 cmd_nr;
> > > > + void *karg;
> > > > + int size;
> > > > + int ret;
> > > > +
> > > > + dlb = f->private_data;
> > > > +
> > > > + if (!dlb) {
> > > > + pr_err("dlb: [%s()] Invalid DLB data\n", __func__);
> > > > + return -EFAULT;
> > >
> > > This error value is only allowed if you really do have a memory fault.
> > >
> > > Hint, you do not here.
> > >
> > > How can that value ever be NULL?
> > >
> >
> > It is targeted at some very rare cases, in which an ioctl command are 
> > called immediately after a device unbind (by a different 
> > process/application).
>
> And how can that happen?  If it really can happen, where is the lock
> that you are holding to keep that pointer from becoming "stale" right
> after you assign it?
>
> So either this never can happen, or your logic here for this type of
> thing is totally wrong.  Please work to determine which it is.

I would have preferred a chance to offer a reviewed-by on this set
before it went out (per the required process) to validate that the
feedback on the lifetime handling was properly addressed, it wasn't,
but lets deal with this on the list now.

The race to handle is the one identified by cdev_del():

 * NOTE: This guarantees that cdev device will no longer be able to be
 * opened, however any cdevs already open will remain and their fops will
 * still be callable even after cdev_del returns.

This means that the dlb->private_data is pointing to a live device, a
dying device, or NULL. Without revalidating to the dlb pointer under a
lock, or some other coordinated reference cout, it can transition
states underneath the running ioctl.

Greg, I'm thinking of taking a shot at a document, "botching up device
lifetimes",  in the same spirit as
Documentation/process/botching-up-ioctls.rst to lay out the different
schemes for revalidating driver private data in ioctls.

It strikes me that a helper like this might address many of the common patterns:

+/**
+ * get_live_device() - increment reference count for device iff !dead
+ * @dev: device.
+ *
+ * Forward the call to get_device() if the device is still alive. If
+ * this is called with the device_lock() held then the device is
+ * guaranteed to not die until the device_lock() is dropped.
+ */
+struct device *get_live_device(struct device *dev)
+{
+   return dev && !dev->p->dead ? get_device(dev) : NULL;
+}
+EXPORT_SYMBOL_GPL(get_live_device);

Alternatively, if device_lock() is too awkward for a driver it could
use its own lock and kill_device().

...am I off base thinking that cdev_del vs fops liveness is a
widespread problem worth documenting new design patterns?

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 6:43 PM Russell King - ARM Linux admin
 wrote:
>
> On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> > * dove -- added in 2009, obsoleted by mach-mvebu in 2015
>
> May be obsoleted, but I still use this for my dove cubox with
> additional patches.

What is the status of these patches? I also still have a set of patches
to integrate it with the other ARMv7 machines into multiplatform,
and a series to change some of the PCI handling in all plat-orion
platforms, that I was hoping to either upstream or drop once the
platform itself gets removed.

Did you give up on moving the Cubox to DT, or is this something you
still want to get back?

> > * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW
> >   have one
>
> Yes, and still running:
> Linux flint 5.6.12+ #94 Sat Oct 17 23:44:28 BST 2020 armv4l armv4l armv4l 
> GNU/Linux
>
> > * iop32x -- added in 2006, no notable changes other than my cleanup, but
> >   I think there are still users
>
> I have two TheCUS N2100s here, one still powered up and running and
> one is currently available if anyone wants the machine. Both may
> become available if anyone wants them later in 2021. I notice
> Heiner Kallweit has been patching some of this code recently.
>
> > * rpc -- prehistoric, but I think Russell still uses his machine
>
> Yes, and I have sent some patches in the 5.x timeframe, and I do
> have some further ones I could send, mostly around SCSI stuff.
> It is my only machine that gives me access to some old tape backups
> and syquest cartridges (not that any of that contains "modern" data.)
>
> > * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
>
> I also have some further patches that have been hanging around for
> some time to modernise sa1100 a bit.

Ok, that roughly all matches what I was guessing. As I wrote, I
saw most of them have been getting updates and assumed we want
to keep them, but I was not sure if any of them have come to the point
where it's no longer worth updating kernels past v5.10.y for any
reason.

 Arnd

Re: [PATCH] target/file: don't zero iter before iov_iter_bvec

[Pavel Begunkov]

On 09/01/2021 20:52, Chaitanya Kulkarni wrote:
> On 1/9/21 12:40, Pavel Begunkov wrote:
>> I expect you won't find any, but such little things can pile up
>> into a not-easy-to-spot overhead over time.
> 
> That is what I suspected with the resulting assembly. The commit log
> needs to document that there is no direct impact on the performance

It's obvious that 3-4 extra mov $0 off(%reg) won't change performance
but still hasn't been formally confirmed ...

> which can be seen with this patch, but this is nice to have

... so if you don't mind, I won't be resending just for that.

-- 
Pavel Begunkov

Re: [PATCH] arm/kasan:fix the arry size of kasan_early_shadow_pte

[Linus Walleij]

On Sat, Jan 9, 2021 at 5:51 AM Hailong liu  wrote:

> From: Hailong Liu 
>
> The size of kasan_early_shadow_pte[] now is PTRS_PER_PTE which defined to
> 512 for arm architecture. This means that it only covers the prev Linux pte
> entries, but not the HWTABLE pte entries for arm.
>
> The reason it works well current is that the symbol kasan_early_shadow_page
> immediately following kasan_early_shadow_pte in memory is page aligned,
> which makes kasan_early_shadow_pte look like a 4KB size array. But we can't
> ensure the order always right with different compiler/linker, nor more bss
> symbols be introduced.
>
> We had a test with QEMU + vexpress：put a 512KB-size symbol with attribute
> __section(".bss..page_aligned") after kasan_early_shadow_pte, and poison it
> after kasan_early_init(). Then enabled CONFIG_KASAN, it failed to boot up.
>
> Signed-off-by: Hailong Liu 
> Signed-off-by: Ziliang Guo 

OK I see the problem, I think.

> +#ifndef PTE_HWTABLE_PTRS
> +#define PTE_HWTABLE_PTRS 0
> +#endif

Can this even happen? We have either pgtable-2level.h or
pgtable-3level.h, both of which define PTE_HWTABLE_PTRS.

>  extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
> -extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
> +extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE + PTE_HWTABLE_PTRS];

Yeah this looks exactly like bm_pte so it makes sense.

If you drop the first ifndef,
Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

Re: [PATCH v2 1/2] usb: ohci: Default to per-port over-current protection

[Alan Stern]

On Sun, Dec 27, 2020 at 12:22:34PM +0100, Paul Kocialkowski wrote:
> Hi,

Sorry it has taken so long to respond to this.  The holidays intervened, 
but that's no excuse.

> On Fri 11 Sep 20, 09:25, Hamish Martin wrote:
> > Some integrated OHCI controller hubs do not expose all ports of the hub
> > to pins on the SoC. In some cases the unconnected ports generate
> > spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC
> > contains a nominally 3 port hub but only the first port is wired.
> > 
> > Default behaviour for ohci-platform driver is to use global over-current
> > protection mode (AKA "ganged"). This leads to the spurious over-current
> > events affecting all ports in the hub.
> > 
> > We now alter the default to use per-port over-current protection.
> 
> This specific patch lead to breaking OHCI on my mom's laptop (whom was about
> to buy a new one thinking the hardware had failed). I get no OHCI interrupt at
> all and no USB 1 device is ever detected.
> 
> I haven't really found a reasonable explanation about why that is, but here
> are some notes I was able to collect:
> - The issue showed up on 5.8,18 and 5.9.15, which don't include the patch
>   from this series that sets distrust_firmware = false; This results in the 
> NPS
>   bit being set via OHCI_QUIRK_HUB_POWER.
> - Adding val &= ~RH_A_PSM; (as was done before this change) solves the issue
>   which is weird because the bit is supposed to be inactive when NPS is set;
> - Setting ohci_hcd.distrust_firmware=0 in the cmdline results in not setting
>   the NPS bit and also solves the issue;
> - The initial value of the register at function entry is 0x1001104 (PSM bit
>   is set, NPS is unset);
> - The OHCI controller is the following:
> 00:03.0 USB controller: Silicon Integrated Systems [SiS] USB 1.1 Controller 
> (rev 0f) (prog-if 10 [OHCI])
>   Subsystem: ASUSTeK Computer Inc. Device 1aa7

Great reporting -- thanks.

> Does that make any sense to you?
> 
> I really wonder what a proper fix could be and here are some suggestions:
> - Adding a specific quirk to clear the PSM bit for this hardware which seems 
> to
>   consider the bit regardless of NPS;

We don't need a quirk for this.  There shouldn't be anything wrong with 
_always_ clearing PSM whenever NPS is set, since the controller is 
supposed to ignore PSM under that condition.

Would you like to submit a patch for this?

> - Adding the patch that sets distrust_firmware = false to stable branches;

That's certainly reasonable.  Nobody has reported any problems caused by 
that patch, so adding it to the stable branches should be safe enough.

> What do you think?

We could even do both.  That would help if, for example, somebody 
decided to set ohci_hcd.distrust_firmware=true explicitly.

Greg, in the meantime can we have commit c4005a8f65ed ("usb: ohci: Make 
distrust_firmware param default to false") added to all the stable 
kernels which have back-ported versions of commit b77d2a0a223b?

Alan Stern

Re: [PATCH] iov_iter: optimise iter type checking

[Pavel Begunkov]

On 09/01/2021 17:03, Al Viro wrote:
> On Sat, Jan 09, 2021 at 04:09:08PM +, Pavel Begunkov wrote:
>> On 06/12/2020 16:01, Pavel Begunkov wrote:
>>> On 21/11/2020 14:37, Pavel Begunkov wrote:
 The problem here is that iov_iter_is_*() helpers check types for
 equality, but all iterate_* helpers do bitwise ands. This confuses
 compilers, so even if some cases were handled separately with
 iov_iter_is_*(), corresponding ifs in iterate*() right after are not
 eliminated.

 E.g. iov_iter_npages() first handles discards, but iterate_all_kinds()
 still checks for discard iter type and generates unreachable code down
 the line.
>>>
>>> Ping. This one should be pretty simple
>>
>> Ping please. Any doubts about this patch?
> 
> Sorry, had been buried in other crap.  I'm really not fond of the
> bitmap use; if anything, I would rather turn iterate_and_advance() et.al.
> into switches...
> 
> How about moving the READ/WRITE part into MSB?  Checking is just as fast
> (if not faster - check for sign vs. checking bit 0).  And turn the
> types into straight (dense) enum.

Didn't realise that approach before, sounds good. Most of it will be
replaced with sign jcc, and the rest will be (t >> 31) or movcc, so it
should not be of concern.

type_mask = 255;
iov_iter_type(i) { return i->type & ~type_mask; }

I hope this stuff won't add much, because the original patch completely
optimises this "&" out. I guess it'll turn into extra

xor m m
notb8 m
and m & type

> 
> Almost all iov_iter_rw() callers have the form (iov_iter_rw(iter) == READ) or
> (iov_iter_rw(iter) == WRITE).  Out of 50-odd callers there are 5 nominal
> exceptions:
> fs/cifs/smbdirect.c:1936:iov_iter_rw(&msg->msg_iter));
> fs/exfat/inode.c:442:   int rw = iov_iter_rw(iter);
> fs/f2fs/data.c:3639:int rw = iov_iter_rw(iter);
> fs/f2fs/f2fs.h:4082:int rw = iov_iter_rw(iter);
> fs/f2fs/f2fs.h:4092:int rw = iov_iter_rw(iter);
> 
> The first one is debugging printk
> if (iov_iter_rw(&msg->msg_iter) == WRITE) {
> /* It's a bug in upper layer to get there */
> cifs_dbg(VFS, "Invalid msg iter dir %u\n",
>  iov_iter_rw(&msg->msg_iter));
> rc = -EINVAL;
> goto out;
> }
> and if you look at the condition, the quality of message is
> underwhelming - "Data source msg iter passed by caller" would
> be more informative.
> 
> Other 4...  exfat one is
> if (rw == WRITE) {
> ...
>   }
> ...
> if (ret < 0 && (rw & WRITE))
> exfat_write_failed(mapping, size);
> IOW, doing
>   bool is_write = iov_iter_rw(iter) == WRITE;
> would be cleaner.  f2fs.h ones are
>   int rw = iov_iter_rw(iter);
>   
>   if ( && rw == WRITE ...
> so they are of the same sort (assuming we want that local
> variable in the first place).
> 
> f2fs/data.c is the least trivial - it includes things like
> if (!down_read_trylock(&fi->i_gc_rwsem[rw])) {
> and considering the amount of other stuff done there,
> I would suggest something like
>   int rw = is_data_source(iter) ? WRITE : READ;
> 
> I'll dig myself from under ->d_revalidate() code review, look
> through the iov_iter-related series and post review, hopefully
> by tonight.

Great, thanks Al. Without it being optimised right my other patches keep
worsening iov_iter, and I obviously want to avoid that.

-- 
Pavel Begunkov