Re: linux 4.19.19: md0_raid:1317 blocked for more than 120 seconds.

[Guoqing Jiang]

On 2/14/19 11:27 PM, Wolfgang Walter wrote:

Am Donnerstag, 14. Februar 2019, 10:09:56 schrieb Guoqing Jiang:

On 2/12/19 7:20 PM, Wolfgang Walter wrote:

Am Dienstag, 12. Februar 2019, 16:20:11 schrieb Guoqing Jiang:

On 2/11/19 11:12 PM, Wolfgang Walter wrote:

With 4.19.19 we see sometimes the following issue (practically only with
blk_mq, though):

Feb  4 20:04:46 tettnang kernel: [252300.060165] INFO: task
md0_raid1:317
blocked for more than 120 seconds. Feb  4 20:04:46 tettnang kernel:
[252300.060188]   Not tainted 4.19.19-debian64.all+1.1 #1 Feb  4
20:04:46 tettnang kernel: [252300.060197] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message. Feb  4
20:04:46 tettnang kernel: [252300.060207] md0_raid1   D0   317

2 0x8000 Feb  4 20:04:46 tettnang kernel: [252300.060211] Call

Trace:
Feb  4 20:04:46 tettnang kernel: [252300.060222]  ?
__schedule+0x2a2/0x8c0
Feb  4 20:04:46 tettnang kernel: [252300.060226]  ?
_raw_spin_unlock_irqrestore+0x20/0x40 Feb  4 20:04:46 tettnang kernel:
[252300.060229]  schedule+0x32/0x90 Feb  4 20:04:46 tettnang kernel:
[252300.060241]  md_super_wait+0x69/0xa0 [md_mod] Feb  4 20:04:46
tettnang kernel: [252300.060247]  ? finish_wait+0x80/0x80 Feb  4
20:04:46
tettnang kernel: [252300.060255]  md_bitmap_wait_writes+0x8e/0xa0
[md_mod] Feb  4 20:04:46 tettnang kernel: [252300.060263]  ?
md_bitmap_get_counter+0x42/0xd0 [md_mod] Feb  4 20:04:46 tettnang
kernel:
[252300.060271]  md_bitmap_daemon_work+0x1e8/0x380 [md_mod] Feb  4
20:04:46 tettnang kernel: [252300.060278]  ? md_rdev_init+0xb0/0xb0
[md_mod] Feb  4 20:04:46 tettnang kernel: [252300.060285]
md_check_recovery+0x26/0x540 [md_mod] Feb  4 20:04:46 tettnang kernel:
[252300.060290]  raid1d+0x5c/0xf00 [raid1] Feb  4 20:04:46 tettnang
kernel: [252300.060294]  ? preempt_count_add+0x79/0xb0 Feb  4 20:04:46
tettnang kernel: [252300.060298]  ? lock_timer_base+0x67/0x80 Feb  4
20:04:46 tettnang kernel: [252300.060302]  ?
_raw_spin_unlock_irqrestore+0x20/0x40 Feb  4 20:04:46 tettnang kernel:
[252300.060304]  ? try_to_del_timer_sync+0x4d/0x80 Feb  4 20:04:46
tettnang kernel: [252300.060306]  ? del_timer_sync+0x35/0x40 Feb  4
20:04:46 tettnang kernel: [252300.060309]  ?
schedule_timeout+0x17a/0x3b0
Feb  4 20:04:46 tettnang kernel: [252300.060312]  ?
preempt_count_add+0x79/0xb0 Feb  4 20:04:46 tettnang kernel:
[252300.060315]  ? _raw_spin_lock_irqsave+0x25/0x50 Feb  4 20:04:46
tettnang kernel: [252300.060321]  ? md_rdev_init+0xb0/0xb0 [md_mod] Feb
4 20:04:46 tettnang kernel: [252300.060327]  ? md_thread+0xf9/0x160
[md_mod] Feb  4 20:04:46 tettnang kernel: [252300.060330]  ?
r1bio_pool_alloc+0x20/0x20 [raid1] Feb  4 20:04:46 tettnang kernel:
[252300.060336]  md_thread+0xf9/0x160 [md_mod] Feb  4 20:04:46 tettnang
kernel: [252300.060340]  ? finish_wait+0x80/0x80 Feb  4 20:04:46
tettnang
kernel: [252300.060344]  kthread+0x112/0x130 Feb  4 20:04:46 tettnang
kernel: [252300.060346]  ? kthread_create_worker_on_cpu+0x70/0x70 Feb  4
20:04:46 tettnang kernel: [252300.060350]  ret_from_fork+0x35/0x40

I saw that there was a similar problem with raid10 and an upstream patch

e820d55cb99dd93ac2dc949cf486bb187e5cd70d
md: fix raid10 hang issue caused by barrier
by  Guoqing Jiang

I wonder if there is a similar fix needed for raid1?

Seems not, the calltrace tells the previous write superblock IO was not
finish as expected,
there is a report for raid5 which has similar problem with md_super_wait
in the link [1]. Maybe
you can disable blk-mq to narrow down the issue as well.

I already did for 4 weeks. I didn't saw this with blk-mq disabled (for
scsi
and md), though this may be by luck.

Then I guess it maybe related to blk-mq, which scheduler are you used
with blk-mq?
And maybe you can switch it to see if it is caused by specified
scheduler or not.

mq-deadline for SCSI and none for md and dm.


Can you try with the patch [1]? In case the block was caused by flush.

[1]: https://patchwork.kernel.org/patch/10787903/


Thanks,
Guoqing

Re: [PATCH v2] staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()

[Dan Carpenter]

On Fri, Feb 15, 2019 at 03:02:25PM +0800, Chao Yu wrote:
> On 2019/2/1 20:16, Gao Xiang wrote:
> > +   /*
> > +* on-disk error, let's only BUG_ON in the debugging mode.
> > +* otherwise, it will return 1 to just skip the invalid name
> > +* and go on (in consideration of the lookup performance).
> > +*/
> > +   DBG_BUGON(qd->name > qd->end);
> 
> qd->name == qd->end is not allowed as well?
> 
> So will it be better to return directly here?
> 
>   if (unlikely(qd->name >= qd->end)) {
>   DBG_BUGON(1);
>   return 1;
>   }

Please don't add likely/unlikely() annotations unless you have
benchmarked it and it makes a difference.

regards,
dan carpenter

Re: [PATCH 06/11] lockdep: consolidate the LOCKDEP_SUPPORT symbol

[Greentime Hu]

Hi Yamada,

Masahiro Yamada  於 2019年2月15日 週五 下午3:17寫道：
>
> +CC Greentime Hu
> +CC Vincent Chen
>
>
> On Thu, Feb 14, 2019 at 2:40 AM Christoph Hellwig  wrote:
> >
> > Add one definition to lib/Kconfig.debug and let the architectures
> > select if it supported.
> >
> > Signed-off-by: Christoph Hellwig 
>
>
> This changes the behavior of nds32.
>
> So please leave a note in the commit description.
> (Ideally, we want Ack of a NDS32 maintainer)
>
> Also, please do compile test for NDS32.
>
>
> -
> This commit changes CONFIG_LOCKDEP_SUPPORT to y for nds32.
>
> NDS32 selects LOCKEP_SUPPORT, but there was previously
> no config entry of LOCKDEP_SUPPORT in nds32.
>
> It is now available in lib/Kconfig.debug,
> so this commit enables LOCKDEP_SUPPORT for nds32.
> -

Thank you to let us know this change.
I think it's ok to enable LOCKDEP_SUPPORT for nds32.
I just verified it in 5.0.0-rc1.

Re: [PATCH 05/11] tracing: consolidate the TRACE_IRQFLAGS_SUPPORT symbol

[Masahiro Yamada]

+CC: Ley Foon Tan 
+CC: nios2-...@lists.rocketboards.org


On Thu, Feb 14, 2019 at 2:40 AM Christoph Hellwig  wrote:

> diff --git a/arch/nios2/Kconfig b/arch/nios2/Kconfig
> index 715e6c09b4a5..3b50689007f5 100644
> --- a/arch/nios2/Kconfig
> +++ b/arch/nios2/Kconfig
> @@ -20,6 +20,7 @@ config NIOS2
> select OF_EARLY_FLATTREE
> select SOC_BUS
> select SPARSE_IRQ
> +   select TRACE_IRQFLAGS_SUPPORT


This is a behavior change of nios2.

TRACE_IRQFLAGS_SUPPORT was previously 'n',
and this commit is changing it to 'y'.




Strangely, nios2 defines TRACE_IRQFLAGS_SUPPORT twice
with different default values.

In Kconfig, the first one becomes effective.

In this case, 'def_bool n' in arch/nios2/Kconfig is used.
'def_bool y' in arch/nios2/Kconfig.debug is dead code.


I think this select should be dropped
to keep the current behavior,
but I hope the NIOS2 maintainer will give us
some comments just in case.




> select USB_ARCH_HAS_HCD if USB_SUPPORT
> select CPU_NO_EFFICIENT_FFS
> select ARCH_DISCARD_MEMBLOCK
> @@ -39,9 +40,6 @@ config NO_IOPORT_MAP
>  config FPU
> def_bool n
>
> -config TRACE_IRQFLAGS_SUPPORT
> -   def_bool n
> -
>  menu "Kernel features"
>
>  source "kernel/Kconfig.hz"
> diff --git a/arch/nios2/Kconfig.debug b/arch/nios2/Kconfig.debug
> index f1da8a7b17ff..a8bc06e96ef5 100644
> --- a/arch/nios2/Kconfig.debug
> +++ b/arch/nios2/Kconfig.debug
> @@ -1,8 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
>
> -config TRACE_IRQFLAGS_SUPPORT
> -   def_bool y
> -
>  config EARLY_PRINTK
> bool "Activate early kernel debugging"
> default y

--
Best Regards
Masahiro Yamada

Re: [PATCH -mm -V7] mm, swap: fix race between swapoff and some swap operations

[Huang, Ying]

Andrea Arcangeli  writes:

> On Thu, Feb 14, 2019 at 04:07:37PM +0800, Huang, Ying wrote:
>> Before, we choose to use stop_machine() to reduce the overhead of hot
>> path (page fault handler) as much as possible.  But now, I found
>> rcu_read_lock_sched() is just a wrapper of preempt_disable().  So maybe
>> we can switch to RCU version now.
>
> rcu_read_lock looks more efficient than rcu_read_lock_sched. So for
> this purpose in the fast path rcu_read_lock()/unlock() should be the
> preferred methods, no need to force preempt_disable() (except for
> debug purposes if sleep debug is enabled). Server builds are done with
> voluntary preempt (no preempt shouldn't even exist as config option)
> and there rcu_read_lock might be just a noop.

If

CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT=n
CONFIG_PREEMPT_COUNT=n

which is common for servers,

rcu_read_lock() will be a noop, rcu_read_lock_sched() and
preempt_disable() will be barrier().  So rcu_read_lock() is a little
better.

> Against a fast path rcu_read_lock/unlock before the consolidation
> synchronize_rcu would have been enough, now after the consolidation
> even more certain that it's enough because it's equivalent to _mult.

Yes.  Will change to rcu_read_lock/unlock based method.

Best Regards,
Huang, Ying

[PATCH v5] coccinelle: semantic code search for missing put_device()

[Wen Yang]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
The implementation of this semantic code search is:
In a function, for a local variable returned by calling
of_find_device_by_node(),
a, if it is released by a function such as
   put_device()/of_dev_put()/platform_device_put() after the last use,
   it is considered that there is no reference leak;
b, if it is passed back to the caller via
   dev_get_drvdata()/platform_get_drvdata()/get_device(), etc., the
   reference will be released in other functions, and the current function
   also considers that there is no reference leak;
c, for the rest of the situation, the current function should release the
   reference by calling put_device, this code search will report the
   corresponding error message.

By using this semantic code search, we have found some object reference leaks,
such as:
commit 11907e9d3533 ("ASoC: fsl-asoc-card: fix object reference leaks in
fsl_asoc_card_probe")
commit a12085d13997 ("mtd: rawnand: atmel: fix possible object reference leak")
commit 11493f26856a ("mtd: rawnand: jz4780: fix possible object reference leak")

There are still dozens of reference leaks in the current kernel code.

Further, for the case of b, the object returned to other functions may also
have a reference leak, we will continue to develop other cocci scripts to
further check the reference leak.

Signed-off-by: Wen Yang 
Reviewed-by: Julia Lawall 
Reviewed-by: Markus Elfring 
Cc: Julia Lawall 
Cc: Gilles Muller 
Cc: Nicolas Palix 
Cc: Michal Marek 
Cc: Markus Elfring 
Cc: Masahiro Yamada 
Cc: Wen Yang 
Cc: cheng.shen...@zte.com.cn
Cc: co...@systeme.lip6.fr
Cc: linux-kernel@vger.kernel.org
---
v5->v4:
- exchange the word “patch” by “code search”
- add a SPDX identifierfix
- a split string literal can be unwanted.
- Change the content of the reported information. 
v4->v3:
- add Masahiro Yamada
- omit a blank line
- split the long message parameter
- reduce the number of metavariables
- Describe the implementation of the semantic patch, 
  explain the scenarios it can detect, 
  and further software development considerations.  
v3->v2:
- reduction of a bit of redundant C code within SmPL search specifications.
- consider the message construction without using the extra Python variable 
“msg”
v2->v1:
- put exists after search, and then drop the when exists below.
- should not use the same e as in the when's below.
- Make a new type metavariable and use it to put a cast on the result of 
  platform_get_drvdata.

 scripts/coccinelle/free/put_device.cocci | 56 
 1 file changed, 56 insertions(+)
 create mode 100644 scripts/coccinelle/free/put_device.cocci

diff --git a/scripts/coccinelle/free/put_device.cocci 
b/scripts/coccinelle/free/put_device.cocci
new file mode 100644
index 000..7395697
--- /dev/null
+++ b/scripts/coccinelle/free/put_device.cocci
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+/// Find missing put_device for every of_find_device_by_node.
+///
+// Confidence: Moderate
+// Copyright: (C) 2018-2019 Wen Yang, ZTE.
+// Comments:
+// Options: --no-includes --include-headers
+
+virtual report
+virtual org
+
+@search exists@
+local idexpression id;
+expression x,e,e1;
+position p1,p2;
+type T,T1,T2,T3;
+@@
+
+id = of_find_device_by_node@p1(x)
+... when != e = id
+if (id == NULL || ...) { ... return ...; }
+... when != put_device(>dev)
+when != platform_device_put(id)
+when != of_dev_put(id)
+when != if (id) { ... put_device(>dev) ... }
+when != e1 = (T)id
+when != e1 = >dev
+when != e1 = get_device(>dev)
+when != e1 = (T1)platform_get_drvdata(id)
+(
+  return
+(id
+|(T2)dev_get_drvdata(>dev)
+|(T3)platform_get_drvdata(id)
+);
+| return@p2 ...;
+)
+
+@script:python depends on report@
+p1 << search.p1;
+p2 << search.p2;
+@@
+
+coccilib.report.print_report(p2[0], "ERROR: missing put_device; "
+ + "call of_find_device_by_node on line "
+ + p1[0].line
+ + ", but without a corresponding object release "
+ + "within this function.")
+
+@script:python depends on org@
+p1 << search.p1;
+p2 << search.p2;
+@@
+
+cocci.print_main("of_find_device_by_node", p1)
+cocci.print_secs("needed put_device", p2)
-- 
2.9.5

Re: [PATCH] staging/android: use multiple futex wait queues

[Hugo Lefeuvre]

> > +   list_for_each_entry(it, >futex_wait_queue_list, list) {
> > +   if (wait_queue->offset == arg->offset) {
> ^^
> You meant "it->offset".

Right, this is not good. Fixed in v2.

Thanks for the feedback!

regards,
 Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C

[PATCH net] vhost: correctly check the return value of translate_desc() in log_used()

[Jason Wang]

When fail, translate_desc() returns negative value, otherwise the
number of iovs. So we should fail when the return value is negative
instead of a blindly check against zero.

Reported-by: Stephen Hemminger 
Fixes: cc5e71075947 ("vhost: log dirty page correctly")
Signed-off-by: Jason Wang 
---
 drivers/vhost/vhost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 24a129fcdd61..a2e5dc7716e2 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64 
used_offset, u64 len)
 
ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
 len, iov, 64, VHOST_ACCESS_WO);
-   if (ret)
+   if (ret < 0)
return ret;
 
for (i = 0; i < ret; i++) {
-- 
2.17.1

Re: [PATCH RFC v2] fcoe: make use of fip_mode enum complete

[Sedat Dilek]

On Fri, Feb 15, 2019 at 8:35 AM Hannes Reinecke  wrote:
>
> On 2/12/19 11:42 PM, Nathan Chancellor wrote:
> > On Tue, Feb 12, 2019 at 08:50:04AM +0100, Sedat Dilek wrote:
> >> On Mon, Feb 11, 2019 at 6:53 PM Nathan Chancellor
> >>  wrote:
> >>>
> >>> On Mon, Feb 11, 2019 at 06:07:51PM +0100, Sedat Dilek wrote:
>  From: Sedat Dilek 
> 
>  commit 1917d42d14b7 ("fcoe: use enum for fip_mode") introduces a separate
>  enum for the fip_mode that shall be used during initialisation handling
>  until it is passed to fcoe_ctrl_link_up to set the initial fip_state.
>  That change was incomplete and gcc quietly converted in various places
>  between the fip_mode and the fip_state enum values with implicit enum
>  conversions, which fortunately cannot cause any issues in the actual
>  code's execution.
> 
>  clang however warns about these implicit enum conversions in the scsi
>  drivers. This commit consolidates the use of the two enums, guided by
>  clang's enum-conversion warnings.
> 
>  This commit now completes the use of the fip_mode:
>  It expects and uses fip_mode in {bnx2fc,fcoe}_interface_create and
>  fcoe_ctlr_init, and it explicitly converts from fip_mode to fip_state
>  only at the single point in fcoe_ctlr_link_up.
> 
>  To eliminate that adding or removing values from fip_mode or fip_state 
>  enum
>  break the right mapping of values, all fip_mode values are assigned to
>  their fip_state counterparts.
> 
>  Link: https://github.com/ClangBuiltLinux/linux/issues/151
>  Fixes: 1917d42d14b7 ("fcoe: use enum for fip_mode")
>  Reported-by: Dmitry Golovin "Twisted Pair in my Hair" 
>  CC: Lukas Bulwahn 
>  CC: Nick Desaulniers 
>  CC: Nathan Chancellor 
>  CC: Hannes Reinecke 
>  Suggested-by: Johannes Thumshirn 
>  ---
> 
>  [ v2:
>  - Based on the original patch by Lukas Bulwahn
>  - Suggestion by Johannes T. [1] required some changes:
>    + s/case FIP_ST_VMMP_START/case FIP_ST_V*N*MP_START
>    + s/return FIP_ST_AUTO/return FIP_MODE_AUTO
>  - Add Link to ClangBuiltLinux issue #151
>  - S-o-b line later when there is an OK from the FCoE maintainers
> 
>  NOTE: Compile-tested against Linux-v5.0-rc6 with LLVM/Clang from Git with
> experimental asm-goto support via executing:
> $ make V=1 CC=clang-9 HOSTCC=clang-9 drivers/scsi/fcoe/
> 
>  [1] https://marc.info/?l=linux-scsi=154745527612152=2
> 
> -dileks ]
> 
>    drivers/scsi/bnx2fc/bnx2fc_fcoe.c  |  2 +-
>    drivers/scsi/fcoe/fcoe.c   |  2 +-
>    drivers/scsi/fcoe/fcoe_ctlr.c  |  4 ++--
>    drivers/scsi/fcoe/fcoe_transport.c |  2 +-
>    drivers/scsi/qedf/qedf_main.c  |  2 +-
>    include/scsi/libfcoe.h | 22 --
>    6 files changed, 26 insertions(+), 8 deletions(-)
> 
>  diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
>  b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
>  index 2e4e7159ebf9..a75e74ad1698 100644
>  --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
>  +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
>  @@ -1438,7 +1438,7 @@ static struct bnx2fc_hba *bnx2fc_hba_create(struct 
>  cnic_dev *cnic)
>    static struct bnx2fc_interface *
>    bnx2fc_interface_create(struct bnx2fc_hba *hba,
> struct net_device *netdev,
>  - enum fip_state fip_mode)
>  + enum fip_mode fip_mode)
>    {
> struct fcoe_ctlr_device *ctlr_dev;
> struct bnx2fc_interface *interface;
>  diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
>  index cd19be3f3405..8ba8862d3292 100644
>  --- a/drivers/scsi/fcoe/fcoe.c
>  +++ b/drivers/scsi/fcoe/fcoe.c
>  @@ -389,7 +389,7 @@ static int fcoe_interface_setup(struct 
>  fcoe_interface *fcoe,
> * Returns: pointer to a struct fcoe_interface or NULL on error
> */
>    static struct fcoe_interface *fcoe_interface_create(struct net_device 
>  *netdev,
>  - enum fip_state 
>  fip_mode)
>  + enum fip_mode fip_mode)
>    {
> struct fcoe_ctlr_device *ctlr_dev;
> struct fcoe_ctlr *ctlr;
>  diff --git a/drivers/scsi/fcoe/fcoe_ctlr.c 
>  b/drivers/scsi/fcoe/fcoe_ctlr.c
>  index 54da3166da8d..a52d3ad94876 100644
>  --- a/drivers/scsi/fcoe/fcoe_ctlr.c
>  +++ b/drivers/scsi/fcoe/fcoe_ctlr.c
>  @@ -147,7 +147,7 @@ static void fcoe_ctlr_map_dest(struct fcoe_ctlr *fip)
> * fcoe_ctlr_init() - Initialize the FCoE Controller instance
> * @fip: The FCoE controller to initialize
> */
>  -void fcoe_ctlr_init(struct fcoe_ctlr *fip, enum fip_state mode)
>  +void fcoe_ctlr_init(struct 

Re: [v4] coccinelle: semantic patch for missing put_device()

[Markus Elfring]

>> So I plan to modify the following to capture both cases:
>> -local idexpression id;
>> +expression id;
>
> I'm not sure that this is a good idea.

Why have you got doubts here?


> There is likely no need for a put in the latter case.

I have got understanding difficulties for such information.
What did you try to express with this sentence finally?

Regards,
Markus

[PATCH v2] pstore: Add boot loader log messages support

[Yue Hu]

From: Yue Hu 

Sometimes we hope to check boot loader log messages (e.g. Android
Verified Boot status) when kernel is coming up. Generally it does
depend on serial device, but it will be removed for the hardware
shipping to market by most of manufacturers. In that case better
solder and proper serial cable for different interface (e.g. Type-C
or microUSB) are needed. That is inconvenient and even wasting much
time on it.

Therefore, let's add a logging support: PSTORE_TYPE_XBL.

Signed-off-by: Yue Hu 
---
v2: mention info of interacting with boot loader

 fs/pstore/Kconfig  | 10 +++
 fs/pstore/platform.c   | 16 ++
 fs/pstore/ram.c| 81 --
 include/linux/pstore.h | 21 +
 4 files changed, 121 insertions(+), 7 deletions(-)

diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 0d19d19..ef4a2dc 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -137,6 +137,16 @@ config PSTORE_FTRACE
 
  If unsure, say N.
 
+config PSTORE_XBL
+   bool "Log bootloader messages"
+   depends on PSTORE
+   help
+ When the option is enabled, pstore will log boot loader
+ messages to /sys/fs/pstore/xbl-ramoops-[ID] after reboot.
+ Boot loader needs to support log buffer reserved.
+
+ If unsure, say N.
+
 config PSTORE_RAM
tristate "Log panic/oops to a RAM buffer"
depends on PSTORE
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 2d1066e..2e6c3f8f 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -65,6 +65,7 @@
"mce",
"console",
"ftrace",
+   "xbl",
"rtas",
"powerpc-ofw",
"powerpc-common",
@@ -530,6 +531,19 @@ static void pstore_register_console(void) {}
 static void pstore_unregister_console(void) {}
 #endif
 
+#ifdef CONFIG_PSTORE_XBL
+static void pstore_register_xbl(void)
+{
+   struct pstore_record record;
+
+   pstore_record_init(, psinfo);
+   record.type = PSTORE_TYPE_XBL;
+   psinfo->write();
+}
+#else
+static void pstore_register_xbl(void) {}
+#endif
+
 static int pstore_write_user_compat(struct pstore_record *record,
const char __user *buf)
 {
@@ -616,6 +630,8 @@ int pstore_register(struct pstore_info *psi)
pstore_register_ftrace();
if (psi->flags & PSTORE_FLAGS_PMSG)
pstore_register_pmsg();
+   if (psi->flags & PSTORE_FLAGS_XBL)
+   pstore_register_xbl();
 
/* Start watching for new records, if desired. */
if (pstore_update_ms >= 0) {
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 1adb5e3..b114b1d 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -56,6 +56,27 @@
 module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
 MODULE_PARM_DESC(pmsg_size, "size of user space message log");
 
+/*
+ * interact with boot loader
+ * =
+ *
+ * xbl memory layout:
+ * ++
+ * |dst |
+ * || ++
+ * |src > |   header   |
+ * ++ |log messages|
+ *++
+ *
+ * As above, src memory is used to store header and log messages generated
+ * by boot loader, pstore will copy the log messages to dst memory which
+ * has same size as src. The header in src is to record log messages size
+ * written and make xbl cookie.
+ */
+static ulong ramoops_xbl_size = MIN_MEM_SIZE;
+module_param_named(xbl_size, ramoops_xbl_size, ulong, 0400);
+MODULE_PARM_DESC(xbl_size, "size of boot loader log");
+
 static unsigned long long mem_address;
 module_param_hw(mem_address, ullong, other, 0400);
 MODULE_PARM_DESC(mem_address,
@@ -88,6 +109,7 @@ struct ramoops_context {
struct persistent_ram_zone *cprz;   /* Console zone */
struct persistent_ram_zone **fprzs; /* Ftrace zones */
struct persistent_ram_zone *mprz;   /* PMSG zone */
+   struct persistent_ram_zone *bprz;   /* XBL zone */
phys_addr_t phys_addr;
unsigned long size;
unsigned int memtype;
@@ -95,6 +117,7 @@ struct ramoops_context {
size_t console_size;
size_t ftrace_size;
size_t pmsg_size;
+   size_t xbl_size;
int dump_oops;
u32 flags;
struct persistent_ram_ecc_info ecc_info;
@@ -106,6 +129,7 @@ struct ramoops_context {
unsigned int max_ftrace_cnt;
unsigned int ftrace_read_cnt;
unsigned int pmsg_read_cnt;
+   unsigned int xbl_read_cnt;
struct pstore_info pstore;
 };
 
@@ -119,6 +143,7 @@ static int ramoops_pstore_open(struct pstore_info *psi)
cxt->console_read_cnt = 0;
cxt->ftrace_read_cnt = 0;
cxt->pmsg_read_cnt = 0;
+   cxt->xbl_read_cnt = 0;
return 0;
 }
 
@@ -272,6 +297,10 @@ static ssize_t ramoops_pstore_read(struct pstore_record 
*record)
if (!prz_ok(prz) && !cxt->pmsg_read_cnt++)
prz = ramoops_get_next_prz(>mprz, 0 /* single */, record);
 
+ 

Re: [PATCH] binder: fix handling of misaligned binder object

[Greg KH]

On Thu, Feb 14, 2019 at 03:22:57PM -0800, Todd Kjos wrote:
> Fixes crash found by syzbot:
> kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
> 
> Reported-by: syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com

As the bot asked, this should be:
Reported-and-tested-by: 
syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com

I'll go fix that up...

thanks,

greg k-h

Re: [PATCH][V2][next] regulator: axp20x: check rdev is null before dereferencing it

[Dan Carpenter]

On Tue, Feb 05, 2019 at 11:37:40AM +0800, Chen-Yu Tsai wrote:
> On Sat, Dec 22, 2018 at 7:32 PM Colin King  wrote:
> >
> > From: Colin Ian King 
> >
> > Currently rdev is dereferenced when assigning desc before rdev is null
> > checked, hence there is a potential null pointer dereference on rdev.
> > Fix this by null checking rdev first.
> >
> > Detected by CoverityScan, CID#1476031 ("Dereference before null check")
> >
> > Fixes: 77e3e3b165db ("regulator: axp20x: add software based soft_start for 
> > AXP209 LDO3")
> > Signed-off-by: Colin Ian King 
> 
> This patch somehow fell through the cracks. Sorry about that.
> 
> Both are really false positives.

I don't like when people use the word "false positive" like this.  The
code doesn't checks for NULL after a dereference so that's a nonsense
to do.  The correct thing is to remove the NULL check.

regards,
dan carpenter

Re: [PATCH] HID: wacom: Mark expected switch fall-through

[Jiri Kosina]

On Thu, 14 Feb 2019, Ping Cheng wrote:

> Yes, it was intended. You can have my Acked-by: Ping Cheng <
> ping.ch...@wacom.com>

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 11/11] s390: don't redefined the HAS_IOMEM symbol

[Masahiro Yamada]

On Thu, Feb 14, 2019 at 2:40 AM Christoph Hellwig  wrote:
>
> Rely on the common defintion instead.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/s390/Kconfig | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 9a25e19364f5..0f62e33ffcb2 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -159,6 +159,7 @@ config S390
> select MODULES_USE_ELF_RELA
> select NEED_DMA_MAP_STATE   if PCI
> select NEED_SG_DMA_LENGTH   if PCI
> +   select NO_IOMEM if !PCI


This does not work because NO_IOMEM is defined
in arch/um/Kconfig.


If you want to do this,
you must move NO_IOMEM  to lib/Kconfig.



> select OLD_SIGACTION
> select OLD_SIGSUSPEND3
> select PCI_DOMAINS  if PCI
> @@ -708,9 +709,6 @@ config PCI_NR_FUNCTIONS
>
>  endif  # PCI
>
> -config HAS_IOMEM
> -   def_bool PCI
> -
>  config CHSC_SCH
> def_tristate m
> prompt "Support for CHSC subchannels"
> --
> 2.20.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Best Regards
Masahiro Yamada

[PATCH v2] staging/android: use multiple futex wait queues

[Hugo Lefeuvre]

Use multiple per-offset wait queues instead of one big wait queue per
region.

Signed-off-by: Hugo Lefeuvre 
---
Changes in v2:
  - dereference the it pointer instead of wait_queue (which is not set
yet) in handle_vsoc_cond_wait()
---
 drivers/staging/android/TODO   |  4 ---
 drivers/staging/android/vsoc.c | 56 ++
 2 files changed, 44 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index fbf015cc6d62..cd2af06341dc 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -12,10 +12,6 @@ ion/
  - Better test framework (integration with VGEM was suggested)
 
 vsoc.c, uapi/vsoc_shm.h
- - The current driver uses the same wait queue for all of the futexes in a
-   region. This will cause false wakeups in regions with a large number of
-   waiting threads. We should eventually use multiple queues and select the
-   queue based on the region.
  - Add debugfs support for examining the permissions of regions.
  - Remove VSOC_WAIT_FOR_INCOMING_INTERRUPT ioctl. This functionality has been
superseded by the futex and is there for legacy reasons.
diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index f2bb18158e5b..97303d9173aa 100644
--- a/drivers/staging/android/vsoc.c
+++ b/drivers/staging/android/vsoc.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "uapi/vsoc_shm.h"
 
 #define VSOC_DEV_NAME "vsoc"
@@ -62,11 +63,18 @@ static const int MAX_REGISTER_BAR_LEN = 0x100;
  */
 static const int SHARED_MEMORY_BAR = 2;
 
+struct vsoc_futex_wait_queue_t {
+   struct list_head list;
+   u32 offset;
+   wait_queue_head_t queue;
+};
+
 struct vsoc_region_data {
char name[VSOC_DEVICE_NAME_SZ + 1];
wait_queue_head_t interrupt_wait_queue;
-   /* TODO(b/73664181): Use multiple futex wait queues */
-   wait_queue_head_t futex_wait_queue;
+   /* Per-offset futex wait queue. */
+   struct list_head futex_wait_queue_list;
+   spinlock_t futex_wait_queue_lock;
/* Flag indicating that an interrupt has been signalled by the host. */
atomic_t *incoming_signalled;
/* Flag indicating the guest has signalled the host. */
@@ -402,6 +410,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct 
vsoc_cond_wait *arg)
struct vsoc_region_data *data = vsoc_dev.regions_data + region_number;
int ret = 0;
struct vsoc_device_region *region_p = vsoc_region_from_filep(filp);
+   struct vsoc_futex_wait_queue_t *it, *wait_queue = NULL;
atomic_t *address = NULL;
ktime_t wake_time;
 
@@ -415,10 +424,27 @@ static int handle_vsoc_cond_wait(struct file *filp, 
struct vsoc_cond_wait *arg)
address = shm_off_to_virtual_addr(region_p->region_begin_offset +
  arg->offset);
 
+   /* Find wait queue corresponding to offset or create it */
+   spin_lock(>futex_wait_queue_lock);
+   list_for_each_entry(it, >futex_wait_queue_list, list) {
+   if (it->offset == arg->offset) {
+   wait_queue = it;
+   break;
+   }
+   }
+
+   if (!wait_queue) {
+   wait_queue = kmalloc(sizeof(*wait_queue), GFP_KERNEL);
+   wait_queue->offset = arg->offset;
+   init_waitqueue_head(_queue->queue);
+   list_add(_queue->list, >futex_wait_queue_list);
+   }
+   spin_unlock(>futex_wait_queue_lock);
+
/* Ensure that the type of wait is valid */
switch (arg->wait_type) {
case VSOC_WAIT_IF_EQUAL:
-   ret = wait_event_freezable(data->futex_wait_queue,
+   ret = wait_event_freezable(wait_queue->queue,
   arg->wakes++ &&
   atomic_read(address) != arg->value);
break;
@@ -426,7 +452,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct 
vsoc_cond_wait *arg)
if (arg->wake_time_nsec >= NSEC_PER_SEC)
return -EINVAL;
wake_time = ktime_set(arg->wake_time_sec, arg->wake_time_nsec);
-   ret = wait_event_freezable_hrtimeout(data->futex_wait_queue,
+   ret = wait_event_freezable_hrtimeout(wait_queue->queue,
 arg->wakes++ &&
 atomic_read(address) != 
arg->value,
 wake_time);
@@ -463,6 +489,7 @@ static int do_vsoc_cond_wake(struct file *filp, uint32_t 
offset)
struct vsoc_device_region *region_p = vsoc_region_from_filep(filp);
u32 region_number = iminor(file_inode(filp));
struct vsoc_region_data *data = vsoc_dev.regions_data + region_number;
+   struct vsoc_futex_wait_queue_t *wait_queue;
/* Ensure that the offset is 

Re: [PATCH 5/9] perf, bpf: save bpf_prog_info in a rbtree in perf_env

[Jiri Olsa]

On Thu, Feb 14, 2019 at 05:03:03PM +, Song Liu wrote:
> 
> 
> > On Feb 14, 2019, at 4:33 AM, Jiri Olsa  wrote:
> > 
> > On Fri, Feb 08, 2019 at 05:17:01PM -0800, Song Liu wrote:
> >> bpf_prog_info contains information necessary to annotate bpf programs.
> >> This patch saves bpf_prog_info for bpf programs loaded in the system.
> >> 
> >> perf-record saves bpf_prog_info information as headers to perf.data.
> >> A new header type HEADER_BPF_PROG_INFO is introduced for this data.
> > 
> > please move those 2 changes into separate patches then
> 
> Do you mean one patch to save data in rbtree, then a separate patch 
> to save data in perf.data file?

yes

jirka

[PATCH v2.5 1/4] mm: Move recent_rotated pages calculation to shrink_inactive_list()

[Kirill Tkhai]

mm: Move recent_rotated pages calculation to shrink_inactive_list()

From: Kirill Tkhai 

The patch moves the calculation from putback_inactive_pages()
to shrink_inactive_list(). This makes putback_inactive_pages()
looking more similar to move_active_pages_to_lru().

To do that, we account activated pages in reclaim_stat::nr_activate.
Since a page may change its LRU type from anon to file cache
inside shrink_page_list() (see ClearPageSwapBacked()), we have to
account pages for the both types. So, nr_activate becomes an array.

Previously we used nr_activate to account PGACTIVATE events, but now
we account them into pgactivate variable (since they are about
number of pages in general, not about sum of hpage_nr_pages).

Signed-off-by: Kirill Tkhai 

v2.5: Update comment.
v2:   Update trace events.
---
 .../trace/postprocess/trace-vmscan-postprocess.pl  |7 ---
 include/linux/vmstat.h |2 +-
 include/trace/events/vmscan.h  |   13 -
 mm/vmscan.c|   15 +++
 4 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl 
b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
index 66bfd8396877..995da15b16ca 100644
--- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
+++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
@@ -113,7 +113,7 @@ my $regex_kswapd_wake_default = 'nid=([0-9]*) 
order=([0-9]*)';
 my $regex_kswapd_sleep_default = 'nid=([0-9]*)';
 my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*) 
gfp_flags=([A-Z_|]*)';
 my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) classzone_idx=([0-9]*) 
order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*) 
nr_taken=([0-9]*) lru=([a-z_]*)';
-my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*) 
nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*) 
nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate=([0-9]*) 
nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)';
+my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*) 
nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*) 
nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate_anon=([0-9]*) 
nr_activate_file=([0-9]*) nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*) 
priority=([0-9]*) flags=([A-Z_|]*)';
 my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) 
nr_rotated=([0-9]*) priority=([0-9]*)';
 my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)';
 
@@ -212,7 +212,8 @@ $regex_lru_shrink_inactive = generate_traceevent_regex(
"vmscan/mm_vmscan_lru_shrink_inactive",
$regex_lru_shrink_inactive_default,
"nid", "nr_scanned", "nr_reclaimed", "nr_dirty", 
"nr_writeback",
-   "nr_congested", "nr_immediate", "nr_activate", 
"nr_ref_keep",
+   "nr_congested", "nr_immediate", "nr_activate_anon",
+   "nr_activate_file", "nr_ref_keep",
"nr_unmap_fail", "priority", "flags");
 $regex_lru_shrink_active = generate_traceevent_regex(
"vmscan/mm_vmscan_lru_shrink_active",
@@ -407,7 +408,7 @@ sub process_events {
}
 
my $nr_reclaimed = $3;
-   my $flags = $12;
+   my $flags = $13;
my $file = 0;
if ($flags =~ /RECLAIM_WB_FILE/) {
$file = 1;
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 2db8d60981fe..bdeda4b079fe 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -26,7 +26,7 @@ struct reclaim_stat {
unsigned nr_congested;
unsigned nr_writeback;
unsigned nr_immediate;
-   unsigned nr_activate;
+   unsigned nr_activate[2];
unsigned nr_ref_keep;
unsigned nr_unmap_fail;
 };
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index a1cb91342231..4f0e45e90cfc 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -358,7 +358,8 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive,
__field(unsigned long, nr_writeback)
__field(unsigned long, nr_congested)
__field(unsigned long, nr_immediate)
-   __field(unsigned long, nr_activate)
+   __field(unsigned int, nr_activate0)
+   __field(unsigned int, nr_activate1)
__field(unsigned long, nr_ref_keep)
__field(unsigned long, nr_unmap_fail)
__field(int, priority)
@@ -373,20 +374,22 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive,
__entry->nr_writeback = stat->nr_writeback;

Re: [PATCH v4 01/37] input: davinci_keyscan: remove unnecessary includes

[Dmitry Torokhov]

On Thu, Feb 14, 2019 at 03:51:55PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> The mach/ and asm/ includes are not needed in davinci_keyscan, but they
> will cause build problems once we make mach/irqs.h a private header for
> mach-davinci.
> 
> Remove all unused header includes.
> 
> Signed-off-by: Bartosz Golaszewski 

Acked-by: Dmitry Torokhov 

> ---
>  drivers/input/keyboard/davinci_keyscan.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/input/keyboard/davinci_keyscan.c 
> b/drivers/input/keyboard/davinci_keyscan.c
> index b20a5d044caa..b4db72f833ca 100644
> --- a/drivers/input/keyboard/davinci_keyscan.c
> +++ b/drivers/input/keyboard/davinci_keyscan.c
> @@ -32,10 +32,6 @@
>  #include 
>  #include 
>  
> -#include 
> -
> -#include 
> -#include 
>  #include 
>  
>  /* Key scan registers */
> -- 
> 2.20.1
> 

-- 
Dmitry

Re: [PATCH v2 2/2] staging: erofs: complete POSIX ACL support

[Dan Carpenter]

On Fri, Feb 15, 2019 at 10:10:34AM +0800, Chao Yu wrote:
> Hi Dan,
> 
> Any suggestion?
> 

I won't NAK whatever you decide.  But my opinion is that you should
just use normal kernel memory allocators even though it means you have
to use two different fault injection frameworks.

Over time it would be good to improve and expand the standard kernel
error injection frameworks to cover more types.

regards,
dan carpenter

Re: [PATCH RFC v2] fcoe: make use of fip_mode enum complete

[Hannes Reinecke]

On 2/12/19 11:42 PM, Nathan Chancellor wrote:

On Tue, Feb 12, 2019 at 08:50:04AM +0100, Sedat Dilek wrote:

On Mon, Feb 11, 2019 at 6:53 PM Nathan Chancellor
 wrote:


On Mon, Feb 11, 2019 at 06:07:51PM +0100, Sedat Dilek wrote:

From: Sedat Dilek 

commit 1917d42d14b7 ("fcoe: use enum for fip_mode") introduces a separate
enum for the fip_mode that shall be used during initialisation handling
until it is passed to fcoe_ctrl_link_up to set the initial fip_state.
That change was incomplete and gcc quietly converted in various places
between the fip_mode and the fip_state enum values with implicit enum
conversions, which fortunately cannot cause any issues in the actual
code's execution.

clang however warns about these implicit enum conversions in the scsi
drivers. This commit consolidates the use of the two enums, guided by
clang's enum-conversion warnings.

This commit now completes the use of the fip_mode:
It expects and uses fip_mode in {bnx2fc,fcoe}_interface_create and
fcoe_ctlr_init, and it explicitly converts from fip_mode to fip_state
only at the single point in fcoe_ctlr_link_up.

To eliminate that adding or removing values from fip_mode or fip_state enum
break the right mapping of values, all fip_mode values are assigned to
their fip_state counterparts.

Link: https://github.com/ClangBuiltLinux/linux/issues/151
Fixes: 1917d42d14b7 ("fcoe: use enum for fip_mode")
Reported-by: Dmitry Golovin "Twisted Pair in my Hair" 
CC: Lukas Bulwahn 
CC: Nick Desaulniers 
CC: Nathan Chancellor 
CC: Hannes Reinecke 
Suggested-by: Johannes Thumshirn 
---

[ v2:
- Based on the original patch by Lukas Bulwahn
- Suggestion by Johannes T. [1] required some changes:
  + s/case FIP_ST_VMMP_START/case FIP_ST_V*N*MP_START
  + s/return FIP_ST_AUTO/return FIP_MODE_AUTO
- Add Link to ClangBuiltLinux issue #151
- S-o-b line later when there is an OK from the FCoE maintainers

NOTE: Compile-tested against Linux-v5.0-rc6 with LLVM/Clang from Git with
   experimental asm-goto support via executing:
   $ make V=1 CC=clang-9 HOSTCC=clang-9 drivers/scsi/fcoe/

[1] https://marc.info/?l=linux-scsi=154745527612152=2

   -dileks ]

  drivers/scsi/bnx2fc/bnx2fc_fcoe.c  |  2 +-
  drivers/scsi/fcoe/fcoe.c   |  2 +-
  drivers/scsi/fcoe/fcoe_ctlr.c  |  4 ++--
  drivers/scsi/fcoe/fcoe_transport.c |  2 +-
  drivers/scsi/qedf/qedf_main.c  |  2 +-
  include/scsi/libfcoe.h | 22 --
  6 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 2e4e7159ebf9..a75e74ad1698 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -1438,7 +1438,7 @@ static struct bnx2fc_hba *bnx2fc_hba_create(struct 
cnic_dev *cnic)
  static struct bnx2fc_interface *
  bnx2fc_interface_create(struct bnx2fc_hba *hba,
   struct net_device *netdev,
- enum fip_state fip_mode)
+ enum fip_mode fip_mode)
  {
   struct fcoe_ctlr_device *ctlr_dev;
   struct bnx2fc_interface *interface;
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index cd19be3f3405..8ba8862d3292 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -389,7 +389,7 @@ static int fcoe_interface_setup(struct fcoe_interface *fcoe,
   * Returns: pointer to a struct fcoe_interface or NULL on error
   */
  static struct fcoe_interface *fcoe_interface_create(struct net_device *netdev,
- enum fip_state fip_mode)
+ enum fip_mode fip_mode)
  {
   struct fcoe_ctlr_device *ctlr_dev;
   struct fcoe_ctlr *ctlr;
diff --git a/drivers/scsi/fcoe/fcoe_ctlr.c b/drivers/scsi/fcoe/fcoe_ctlr.c
index 54da3166da8d..a52d3ad94876 100644
--- a/drivers/scsi/fcoe/fcoe_ctlr.c
+++ b/drivers/scsi/fcoe/fcoe_ctlr.c
@@ -147,7 +147,7 @@ static void fcoe_ctlr_map_dest(struct fcoe_ctlr *fip)
   * fcoe_ctlr_init() - Initialize the FCoE Controller instance
   * @fip: The FCoE controller to initialize
   */
-void fcoe_ctlr_init(struct fcoe_ctlr *fip, enum fip_state mode)
+void fcoe_ctlr_init(struct fcoe_ctlr *fip, enum fip_mode mode)
  {
   fcoe_ctlr_set_state(fip, FIP_ST_LINK_WAIT);
   fip->mode = mode;
@@ -454,7 +454,7 @@ void fcoe_ctlr_link_up(struct fcoe_ctlr *fip)
   mutex_unlock(>ctlr_mutex);
   fc_linkup(fip->lp);
   } else if (fip->state == FIP_ST_LINK_WAIT) {
- fcoe_ctlr_set_state(fip, fip->mode);
+ fcoe_ctlr_set_state(fip, (enum fip_state) fip->mode);
   switch (fip->mode) {
   default:
   LIBFCOE_FIP_DBG(fip, "invalid mode %d\n", fip->mode);


Watch out for this one.
fip_mode != fip_state.

This arguably is an error even now; it might _just_ work if we have 
fip->mode == FIP_MODE_FABRIC, but we probably will be getting 
interesting results when 

Re: [PATCH] Fix resume for ELAN2097 touchscreen.

[Jiri Kosina]

On Thu, 14 Feb 2019, james broadus wrote:

> > This should be fixed in hid.git#for-5.1/i2c-hid already by commit
> > 1475af255e18f. Could you please confirm that?
> >
> 
> Hi Jiri. That change mutes the log messages, but I'm still counting 
> around 35000 interrupts per second after resume and touch does not work. 
> With the reset, the device works properly.

Ah, I see. Should your patch then actually replace 1475af255e18f?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [RFC 2/2] soc: samsung: pmu: Add the PMU data of exynos4412 to support low-power state

[Krzysztof Kozlowski]

On Thu, 14 Feb 2019 at 19:37, Anand Moon  wrote:
>
> Hi Krzysztof,
>
> Thanks for your review comments.
>
> On Thu, 14 Feb 2019 at 18:29, Krzysztof Kozlowski  wrote:
> >
> > On Wed, 13 Feb 2019 at 22:41, Anand Moon  wrote:
> > >
> > > This patch adds configration for PMU (Power Management Unit) state
> > > tuning for exynos4412 SoC in order to enter low-power mode during
> > > suspend power modes and help resume from suspend state.
> >
> > The U3 and Trats2 already enter STOP/S2R so please describe what
> > exactly you change.
> >
> > > Fixes: bfce552d0b1 ("drivers: soc: Add support for Exynos PMU driver")
> >
> > How it fixes it? What was broken in that commit?
>
> * I was not aware on their is common framework for suspend and resume
> other than setting this here.I only look in to some the other exynos
> pmu architecture
> and referring 3.10.x kernel to model my changes.*

Suspend in general should be working already so adding this code just
because is not a valid reason. Please specify what is not working
first.

> >
> > > Cc: Marek Szyprowski 
> > > Cc: Krzysztof Kozlowski 
> > > Cc: Chanwoo Choi 
> > > Signed-off-by: Anand Moon 
> > > ---
> > >
> > > Changes from previous patch.
> > > New patch to this series to support suspend and resume state
> > >
> > > Changes have been tested on microSD card but fails to resume on cMMC.
> > > It need to be investigated and more debuging
> > > ---
> > >  drivers/soc/samsung/exynos4-pmu.c   | 83 +
> > >  include/linux/soc/samsung/exynos-regs-pmu.h | 21 ++
> > >  2 files changed, 104 insertions(+)
> > >
> > > diff --git a/drivers/soc/samsung/exynos4-pmu.c 
> > > b/drivers/soc/samsung/exynos4-pmu.c
> > > index a7cdbf1aac0c..d261a0d2371e 100644
> > > --- a/drivers/soc/samsung/exynos4-pmu.c
> > > +++ b/drivers/soc/samsung/exynos4-pmu.c
> > > @@ -200,10 +200,93 @@ static const struct exynos_pmu_conf 
> > > exynos4412_pmu_config[] = {
> > > { PMU_TABLE_END,},
> > >  };
> > >
> > > +static unsigned int const exynos4412_list_feed[] = {
> > > +   EXYNOS4_ARM_CORE0_OPTION,
> > > +   EXYNOS4_ARM_CORE1_OPTION,
> > > +   EXYNOS4_ARM_CORE2_OPTION,
> > > +   EXYNOS4_ARM_CORE3_OPTION,
> > > +   EXYNOS4_ARM_COMMON_OPTION,
> > > +   EXYNOS4_CAM_OPTION,
> > > +   EXYNOS4_TV_OPTION,
> > > +   EXYNOS4_MFC_OPTION,
> > > +   EXYNOS4_G3D_OPTION,
> > > +   EXYNOS4_LCD0_OPTION,
> > > +   EXYNOS4_ISP_OPTION,
> > > +   EXYNOS4_MAUDIO_OPTION,
> > > +   EXYNOS4_GPS_OPTION,
> > > +   EXYNOS4_GPS_ALIVE_OPTION,
> > > +};
> > > +
> > > +static void exynos4412_pmu_central_seq(bool enable)
> >
> > You name the argument as "enable"  but during initialization and
> > system running you pass here false. It confuses me. What do you enable
> > here?
> >
>
> Yep your are correct need to drop this function as already done in
> common frame work.
>
> > > +{
> > > +   unsigned int value;
> > > +
> > > +   value = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
> > > +   if (enable)
> > > +   value &= ~S5P_CENTRAL_LOWPWR_CFG;
> > > +   else
> > > +   value |= S5P_CENTRAL_LOWPWR_CFG;
> > > +   pmu_raw_writel(value, S5P_CENTRAL_SEQ_CONFIGURATION);
> >
> > You duplicate exynos_pm_central_suspend() without removing the original 
> > code.
> >
> > > +
> > > +   value = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION_COREBLK);
> > > +   if (enable)
> > > +   value &= ~S5P_CENTRAL_LOWPWR_CFG;
> > > +   else
> > > +   value |= S5P_CENTRAL_LOWPWR_CFG;
> >
> > As manual says - set this register only if you disable C2C. Our entire
> > low power configuration for STOP mode is for C2C enabled case so you
> > add inconsistent configuration.
>
> Ok Sorry I overlook this code change.
>
> Enable system power down. Set only CENTRAL_SEQ_CONFIGURATION register
> if you disable C2C.
> Set both CENTRAL_SEQ_CONFIGURATION and
> CENTRAL_SEQ_CONFIGURATION_COREBLK registers if you enable C2C.
>
> > > +   pmu_raw_writel(value, S5P_CENTRAL_SEQ_CONFIGURATION_COREBLK);
> > > +}
> > > +
> > > +static void exynos4412_pmu_init(void)
> > > +{
> > > +   unsigned int value;
> > > +   int i;
> > > +
> > > +   /* Enable USE_STANDBY_WFI for all CORE */
> > > +   pmu_raw_writel(S5P_USE_STANDBY_WFI_ALL, S5P_CENTRAL_SEQ_OPTION);
> >
> > This does not look related to improving suspend... it looks unrelated.
> >
>
> Ok  yes your are correct all ready done in comment frame work.
>
> "Execute WFI/WFE for all CPU cores. As soon as all the CPU cores in
> Exynos 4412 SCP enter STANDBY mode"
> > > +
> > > +   /* Decides whether to use retention capability */
> > > +   value  = pmu_raw_readl(S5P_ARM_L2_0_OPTION);
> > > +   value &= ~EXYNOS_L2_USE_RETENTION;
> > > +   pmu_raw_writel(value, S5P_ARM_L2_0_OPTION);
> > > +
> > > +   value = pmu_raw_readl(S5P_ARM_L2_1_OPTION);
> > > +   value &= ~EXYNOS_L2_USE_RETENTION;
> > > +   pmu_raw_writel(value, 

[PATCH V2] sysfs.txt: add note on available attribute macros

[Nicholas Mc Guire]

The common cases of attributes wrappers should probably be using the
__ATTR_XXX macros to make code more concise and readable but the current
sysfs.txt does not point developers to those convenience macros. Further
there is no note in sysfs.txt currently explaining why trying to set a
sysfs file to mode 0666 will fail respectively revert to 0664.

Signed-off-by: Nicholas Mc Guire 
---

V2: the descriptions were not too helpful as noted by 
Greg Kroah-Hartman 
so lets see if V2 is any better...

 Documentation/filesystems/sysfs.txt | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Documentation/filesystems/sysfs.txt 
b/Documentation/filesystems/sysfs.txt
index 41411b0..b003123 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -116,6 +116,27 @@ static struct device_attribute dev_attr_foo = {
.store = store_foo,
 };
 
+Note as stated in include/linux/kernel.h "OTHER_WRITABLE?  Generally
+considered a bad idea." so trying to set a sysfs file writable for
+everyone will fail reverting to RO mode for "Others".
+
+For the common cases sysfs.h provides convenience macros to make
+defining attributes easier as well as making code more concise and
+readable. The above case could be shortened to:
+
+static struct device_attribute dev_attr_foo = __ATTR_RW(foo);
+
+the list of helpers available to define your wrapper function is:
+__ATTR_RO(name): assumes default name_show and mode 0444
+__ATTR_WO(name): assumes a name_store only and is restricted to mode
+ 0200 that is root write access only.
+__ATTR_RO_MODE(name, mode): fore more restrictive RO access currently
+ only use case is the EFI System Resource Table
+ (see drivers/firmware/efi/esrt.c)
+__ATTR_RW(name): assumes default name_show, name_store and setting
+ mode to 0644.
+__ATTR_NULL: which sets the name to NULL and is used as end of list
+ indicator (see: kernel/workqueue.c)
 
 Subsystem-Specific Callbacks
 
-- 
2.1.4

Re: [RFC 1/2] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3

[Krzysztof Kozlowski]

On Thu, 14 Feb 2019 at 19:35, Anand Moon  wrote:
>
> hi Krzysztof,
>
> Thanks fro your review comments.
>
> On Thu, 14 Feb 2019 at 18:11, Krzysztof Kozlowski  wrote:
> >
> > Hi Anand,
> >
> > Thanks for the patch. See comments below.
> >
> > On Wed, 13 Feb 2019 at 22:41, Anand Moon  wrote:
> > >
> > > Add suspend-to-mem node to regulator core to be enabled or disabled
> > > during system suspend and also support changing the regulator operating
> > > mode during runtime and when the system enter sleep mode.
> > >
> > > Cc: Marek Szyprowski 
> > > Cc: Krzysztof Kozlowski 
> > > Cc: Chanwoo Choi 
> > > Signed-off-by: Anand Moon 
> > > ---
> > >
> > > Changes from previos patch
> > > [0] https://patchwork.kernel.org/patch/10712549/
> > >
> > > Set all the WAKEUP source regulator in suspend-on state.
> > > LD04, LD012, LD015, LD020, LD022
> > > Set all the non used regulator in suspend-odd state
> > > LD02, LD03, LD05, LD06, LD07, LD011, LD013, LDO14, LD016
> > >
> > > BUCK5, BUCK6, BUCK7 and not confirable as per driver max77686-regulator
> > >
> > > Tested on microSD card and it resumes correcly after suspend.
> > > eMMC is not able to resume after entering into suspend state,
> > > which need to be investigated and how to debug more.
> > > ---
> > >  .../boot/dts/exynos4412-odroid-common.dtsi| 63 +++
> > >  arch/arm/boot/dts/exynos4412-odroidu3.dts |  3 +
> > >  2 files changed, 66 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > index 08d3a0a7b4eb..e984461c37d9 100644
> > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > @@ -288,6 +288,9 @@
> > > regulator-min-microvolt = <180>;
> > > regulator-max-microvolt = <180>;
> > > regulator-always-on;
> > > +   regulator-state-mem {
> > > +   regulator-off-in-suspend;
> > > +   };
> >
> > I see my comment from previous patch was not addressed.
>
> I left this unchanged since this regulator is not active linked and used.
> Ok I will change this to regulator-on-in-suspend,

Why?

Previous patch was setting this to "on". I said that this is noop and
if you want to add it, I need explanation why this regulator has to
stay on during suspend.

So you changed to "off"... which is still noop... and you did not
provide explanation. Now you replied that you will change to "on"...
so this will be circle. Still without explanation.

>
> From documentation device tree binding regulator.txt
> "- regulator-always-on: boolean, regulator should never be disabled"
>
> But some regulator switches to a low power mode under light current loads
> and the device automatically switches back to a fast response mode as the
> output load increases.
>
> >
> > > };
> > >
> > > ldo3_reg: LDO3 {
> > > @@ -295,6 +298,9 @@
> > > regulator-min-microvolt = <180>;
> > > regulator-max-microvolt = <180>;
> > > regulator-always-on;
> > > +   regulator-state-mem {
> > > +   regulator-off-in-suspend;
> > > +   };
> >
> > The same...
>
> Ok I will change this to regulator-on-in-suspend,

The same - why changing this to on or off? I need explanation why this
should be in first place.

> >
> > > };
> > >
> > > ldo4_reg: LDO4 {
> > > @@ -302,6 +308,9 @@
> > > regulator-min-microvolt = <280>;
> > > regulator-max-microvolt = <280>;
> > > regulator-boot-on;
> > > +   regulator-state-mem {
> > > +   regulator-on-in-suspend;
> > > +   };
> > > };
> > >
> > > ldo5_reg: LDO5 {
> > > @@ -310,6 +319,9 @@
> > > regulator-max-microvolt = <180>;
> > > regulator-always-on;
> > > regulator-boot-on;
> > > +   regulator-state-mem {
> > > +   regulator-off-in-suspend;
> > > +   };
> > > };
> > >
> > > ldo6_reg: LDO6 {
> > > @@ -317,6 +329,9 @@
> > > regulator-min-microvolt = <100>;
> > > regulator-max-microvolt = <100>;
> > > regulator-always-on;
> > > +   

Re: [PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32

[Jiri Kosina]

On Fri, 15 Feb 2019, chenzefeng (A) wrote:

> On x86-64, for 32-bit PC-relacive branches, we can generate PLT32 
> relocation, instead of PC32 relocation. and R_X86_64_PLT32 can be 
> treated the same as R_X86_64_PC32 since linux kernel doesn't use PLT.
> 
> In linux 4.4 commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as 
> R_X86_64_PC32") been fixed for the module loading, but not fixed for 
> livepatch relocation, which will fail to load livepatch with the error 
> message as follow: relocation failed for symbol  at  address>
> 
> Signed-off-by: chenzefeng 

What kernel version is this patch based on? We've got rid of x86-specific 
module loading stub and offloaded all the relocation handling to generic 
kmod loader long time ago.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs

[Yauhen Kharuzhy]

On Fri, Feb 15, 2019 at 12:03:07AM +0100, Pavel Machek wrote:
> Hi!
> 
> > >>>I suggest that we deal with this special case by adding 3 custom
> > >>>sysfs attributes:
> > >>>
> > >>>1) "mode" which when read, prints, e.g. :
> > >>>manual [on-when-charging]
> > >>
> > >>While this allows _user on console_ to control everything using echo,
> > >>it is not suitable for applications trying to control LEDs.
> > >>
> > >>As there's nothing special about the case here, I believe we should
> > >>have generic solution here.
> > >>
> > >>My preffered solution would be "hardware" trigger that leaves the LED
> > >>in hardware control.
> > >
> > >As you explained in the parts which I snipped, there are many
> > >devices which have a similar choice for a LED being under hw or
> > >user control. I can see how this looks like a trigger and how we
> > >could use the trigger API for this.
> > >
> > >I believe though, that if we implement a "virtual" (for lack of
> > >a better word) trigger for this, that this should be done in the
> > >LED core. I can envision this working like this:
> > >
> > >1) Add a:
> > >
> > >hw_control_set(struct led_classdev *led_cdev, bool enable_hw_control);
> > 
> > Please note that we have support for hw patterns in the pattern trigger.
> > (see how drivers/leds/leds-sc27xx-bltc.c makes use of it for its
> > breathing pattern).
> > We have also support for hw blinking in timer trigger via blink_set op.
> > 
> > In addition to that there is brightness_hw_changed sysfs attribute
> > with led_classdev_notify_brightness_hw_changed() LED API.
> > 
> > Couldn't they be used in concert to support the specific features
> > of the device in question?
> 
> I believe main issue here is this:
> 
> Hardware can automatically control the LED according to the charging
> status, or it can be used as normal software-controlled LED.
> 
> I believe we should use trigger to select if hardware controls it or
> not (and then add driver-specific files to describe the
> details). Other proposal is in the mail thread, too.

But there are two kinds of 'hardware control' here in discussion:
1:
a) PMIC switching LED off/on/breathing/blinking reflected the charging
state (charger is controlled by PMIC entirely without of
software intervention) – 'hw controlled' mode
b) Software controls when LED is on/off/breathing/blinking but
patterns are generated by PMIC – 'sw controlled' mode.

2:
a) parameters of lighting (continuous/blinking/breathing) are
set in the PMIC and the PMIC generates patterns
b) blinking/breathing patterns are generated by the software
entirely.

It seems that we sometimes confuse this two kinds of hw control definitions
in the discussion.


The simple use case question: with this hardware and existing LED class
API, what user/app should to do to make LED breathing with hw-generated
pattern?

As I see, user should activate 'pattern' trigger and write to its hw_pattern 
attribute...
hm... big pattern which describes every step of breathing? Some
simplified pattern which should be interpreted as 'enable the breathing
an set its frequency' by driver? Which level of simplification will be
suitable? Which criteria of pattern rejection should be?

-- 
Yauhen Kharuzhy

Re: [PATCH] ASoC: samsung: odroid: Ensure proper sample rate on pri/sec PCM

[Krzysztof Kozlowski]

On Thu, 14 Feb 2019 at 17:00, Sylwester Nawrocki  wrote:
>
> Currently when playing sound with different sample rates actual
> sample rate will be determined by audio stream which starts first
> on either primary or secondary PCM. The audio root clock will be
> configured appropriately only for the first stream. As the hardware
> is limited to same sample rate on both interfaces we need to disallow
> streams with different sample rates. It is done by this patch by
> returning error in FE hw_params if there is already active stream
> running with different sample rate.
>
> Signed-off-by: Sylwester Nawrocki 
> ---
>  sound/soc/samsung/odroid.c | 56 ++
>  1 file changed, 56 insertions(+)

Is this the fix for
"aplay: set_params:1403: Unable to install hw params:"
which appeared in today's next (so after your last round of patches get merged)?
https://krzk.eu/#/builders/1/builds/3093/steps/24/logs/stdio

Also, since yesterday (so with previous rounds of patches) the audss
rebind freezes entire kernel:
https://krzk.eu/#/builders/1/builds/3093/steps/25/logs/stdio
https://krzk.eu/#/builders/1/builds/3093/steps/25/logs/serial0

It is not important test but it was always passing in my suite.

Best regards,
Krzysztof

Re: [PATCH v7 1/6] dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183

[Matthias Brugger]

On 2/15/19 7:02 AM, Erin Lo wrote:
> This adds dt-binding documentation of SYSIRQ for Mediatek MT8183 SoC
> Platform.
> 
> Signed-off-by: Erin Lo 
> Acked-by: Rob Herring 
> ---

Reviewed-by: Matthias Brugger 

Marc you want me to take it through my tree?

>  .../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 1 
> +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt 
> b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
> index 33a98eb..91aa9ab 100644
> --- 
> a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
> +++ 
> b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
> @@ -5,6 +5,7 @@ interrupt.
>  
>  Required properties:
>  - compatible: should be
> + "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183
>   "mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173
>   "mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135
>   "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127
> 

Re: [PATCH] Fix resume for ELAN2097 touchscreen.

[james broadus]

On Wed, Feb 13, 2019 at 3:37 PM Jiri Kosina  wrote:
>
> On Sun, 10 Feb 2019, Jim Broadus wrote:
>
> > Commit 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system resume")
> > fixes the resume behavior of several devices. However, this breaks the
> > resume on the ELAN2097, used on Dell Inspiron laptops, with the same flood
> > of messages:
> >
> > [27009.817110] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete 
> > report (67/65535)
> > [27009.818867] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete 
> > report (67/65535)
> > [27009.820623] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete 
> > report (67/65535)
> >
> > This change adds a new I2C_HID_QUIRK_RESET_AFTER_RESUME and replaces the
> > original reset behavior for this device.
> >
> > Signed-off-by: Jim Broadus 
>
> This should be fixed in hid.git#for-5.1/i2c-hid already by commit
> 1475af255e18f. Could you please confirm that?
>

Hi Jiri. That change mutes the log messages, but I'm still counting around
35000 interrupts per second after resume and touch does not work. With the
reset, the device works properly.

Jim

> > ---
> >  drivers/hid/hid-ids.h  |  1 +
> >  drivers/hid/i2c-hid/i2c-hid-core.c | 20 ++--
> >  2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 24f846d67478..38cc7033712a 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -387,6 +387,7 @@
> >  #define USB_DEVICE_ID_TOSHIBA_CLICK_L9W  0x0401
> >  #define USB_DEVICE_ID_HP_X2  0x074d
> >  #define USB_DEVICE_ID_HP_X2_10_COVER 0x0755
> > +#define USB_DEVICE_ID_ELAN2097   0x2504
> >
> >  #define USB_VENDOR_ID_ELECOM 0x056e
> >  #define USB_DEVICE_ID_ELECOM_BM084   0x0061
> > diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c 
> > b/drivers/hid/i2c-hid/i2c-hid-core.c
> > index c5edfa966343..fdbad29b4406 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> > @@ -50,6 +50,7 @@
> >  #define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
> >  #define I2C_HID_QUIRK_NO_RUNTIME_PM  BIT(2)
> >  #define I2C_HID_QUIRK_DELAY_AFTER_SLEEP  BIT(3)
> > +#define I2C_HID_QUIRK_RESET_AFTER_RESUME BIT(4)
> >
> >  /* flags */
> >  #define I2C_HID_STARTED  0
> > @@ -181,6 +182,8 @@ static const struct i2c_hid_quirks {
> >   I2C_HID_QUIRK_NO_RUNTIME_PM },
> >   { I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
> >   I2C_HID_QUIRK_NO_RUNTIME_PM },
> > + { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN2097,
> > +  I2C_HID_QUIRK_RESET_AFTER_RESUME },
> >   { 0, 0 }
> >  };
> >
> > @@ -1279,12 +1282,17 @@ static int i2c_hid_resume(struct device *dev)
> >
> >   enable_irq(client->irq);
> >
> > - /* Instead of resetting device, simply powers the device on. This
> > -  * solves "incomplete reports" on Raydium devices 2386:3118 and
> > -  * 2386:4B33 and fixes various SIS touchscreens no longer sending
> > -  * data after a suspend/resume.
> > -  */
> > - ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> > + if (ihid->quirks & I2C_HID_QUIRK_RESET_AFTER_RESUME) {
> > + ret = i2c_hid_hwreset(client);
> > + } else {
> > + /* Instead of resetting device, simply powers the device on.
> > +  * This solves "incomplete reports" on Raydium devices 
> > 2386:3118
> > +  * and 2386:4B33 and fixes various SIS touchscreens no longer
> > +  * sending data after a suspend/resume.
> > +  */
> > + ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> > + }
> > +
> >   if (ret)
> >   return ret;
> >
> > --
> > 2.20.1
> >
>
> --
> Jiri Kosina
> SUSE Labs
>

Re: [PATCH 06/11] lockdep: consolidate the LOCKDEP_SUPPORT symbol

[Masahiro Yamada]

+CC Greentime Hu
+CC Vincent Chen


On Thu, Feb 14, 2019 at 2:40 AM Christoph Hellwig  wrote:
>
> Add one definition to lib/Kconfig.debug and let the architectures
> select if it supported.
>
> Signed-off-by: Christoph Hellwig 


This changes the behavior of nds32.

So please leave a note in the commit description.
(Ideally, we want Ack of a NDS32 maintainer)

Also, please do compile test for NDS32.


-
This commit changes CONFIG_LOCKDEP_SUPPORT to y for nds32.

NDS32 selects LOCKEP_SUPPORT, but there was previously
no config entry of LOCKDEP_SUPPORT in nds32.

It is now available in lib/Kconfig.debug,
so this commit enables LOCKDEP_SUPPORT for nds32.
-






--
Best Regards
Masahiro Yamada

Re: Userspace regression in LTS and stable kernels

[Greg Kroah-Hartman]

On Fri, Feb 15, 2019 at 08:00:22AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 14, 2019 at 12:20:27PM -0800, Andrew Morton wrote:
> > On Thu, 14 Feb 2019 09:56:46 -0800 Linus Torvalds 
> >  wrote:
> > 
> > > On Wed, Feb 13, 2019 at 3:37 PM Richard Weinberger
> > >  wrote:
> > > >
> > > > Your shebang line exceeds BINPRM_BUF_SIZE.
> > > > Before the said commit the kernel silently truncated the shebang line
> > > > (and corrupted it),
> > > > now it tells the user that the line is too long.
> > > 
> > > It doesn't matter if it "corrupted" things by truncating it. All that
> > > matters is "it used to work, now it doesn't"
> > > 
> > > Yes, maybe it never *should* have worked. And yes, it's sad that
> > > people apparently had cases that depended on this odd behavior, but
> > > there we are.
> > > 
> > > I see that Kees has a patch to fix it up.
> > > 
> > 
> > Greg, I think we have a problem here.
> > 
> > 8099b047ecc431518 ("exec: load_script: don't blindly truncate shebang
> > string") wasn't marked for backporting.  And, presumably as a
> > consequence, Kees's fix "exec: load_script: allow interpreter argument
> > truncation" was not marked for backporting.
> > 
> > 8099b047ecc431518 hasn't even appeared in a Linus released kernel, yet
> > it is now present in 4.9.x, 4.14.x, 4.19.x and 4.20.x.
> 
> It came in 5.0-rc1, so it fits the "in a Linus released kernel"
> requirement.  If we are to wait until it shows up in a -final, that
> would be months too late for almost all of these types of patches that
> are picked up.
> 
> > I don't know if Oleg considered backporting that patch.  I certainly
> > did (I always do), and I decided against doing so.  Yet there it is.
> 
> This came in through Sasha's tools, which give people a week or so to
> say "hey, this isn't a stable patch!" and it seems everyone ignored that
> :(
> 
> Where is Kees's fix?  I'll be glad to queue it up, or just revert the
> above commit, which ever people think is easiest.

Ah, I see the fix now, _after_ I just pushed out a bunch of stable
releases.  I'll go queue it up and push it out with just that fix in it
now...

thanks,

greg k-h

Re: [PATCH v2 0/2] drm/omap: panel-tpo-td028ttec1: add backlight support

[Andreas Kemnade]

Hi,

On Fri, 8 Feb 2019 11:13:33 +0200
Tomi Valkeinen  wrote:

> On 05/02/2019 08:38, Andreas Kemnade wrote:
> > This panel has a backlight, so add a property describing that and
> > add the code to use that.
> > This makes things like xset dpms force off
> > also turn off the backlight, so we do not need to rely on additional
> > userspace programs to do that.
> > 
> > Andreas Kemnade (2):
> >   drm/omap: panel-tpo-td028ttec1: add backlight support
> >   dt-bindings: panel: td028ttec1: add backlight property
> > 
> >  .../devicetree/bindings/display/panel/tpo,td028ttec1.txt   |  2 ++
> >  drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c| 10 
> > ++
> >  2 files changed, 12 insertions(+)
> >   
> 
> Thanks, I'll pick these up.
> 

hmm, that sounds like: patch accepted, will appear in linux-next soon.
I have not seen it there, or is it just in some branch not merged into
linux-next. Any new obstacles?

Regards,
Andreas


pgpAZ9lP4r7MH.pgp
Description: OpenPGP digital signature

Re: [v4] coccinelle: semantic patch for missing put_device()

[Markus Elfring]

 In a function, for variables returned by calling of_find_device_by_node(),
>>> Do variables really get returned?
>>> The provided pointer should usually be stored somewhere.
>>
>> Thank you very much, we will consider this situation and  submit a next 
>> version to fix it.
>
> I don't know what Markus is talking about here,

I find that my feedback contained details for two items.

1. I suggested another adjustment for a wording in the evolving
   commit description.

2. Should any more case distinctions be taken into account for the data
   storage of function return values so that the shown source code search
   approach can become safer?


> so I'm not sure that a change is needed.

I am curious if there is a need for further clarifications then.


 + "ERROR: missing put_device;"
>>> Will change confidence considerations result in another fine-tuning for 
>>> this message?
>>
>> Thank you, we will change "ERROR" to "WARNING".
>
> I think ERROR is fine.

I have got a different software development view for the possible
severity information.


> If it is a real positive than it is a real problem.

I can agree to this information.

You specified also a precondition.
How should be achieved that the source code analysis will not point
false positives out?


> Warning is for things that look ugly,

I am also curious on how views will evolve around such ugliness.


> but don't have any impact on the execution.

I find such a restriction questionable.


Would you like to share any more ideas for safe data flow analysis
(eventually also together with your software)?

Regards,
Markus

Re: [PATCH 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks

[Chanwoo Choi]

Hi Yauhen,

You are missing me on cc list. I didn't know this patchset.
On next, please use the get_maintainer script in order to
send the correct list.

On 19. 2. 11. 오전 5:36, Yauhen Kharuzhy wrote:
> At implementation of charging support for Lenovo Yoga Book (Intel Cherry Trail
> based with Whiskey Cove PMIC), two pitfalls were found:
> 
> - for detection of charger type by PMIC, bit 6 in the CHGRCTRL1 register
>   should be set in 0 (and set to 1 for Host mode). Pick up its definition
>   and logic from from Intel code drop[1];
> 
> - "#CHARGE ENABLE" signal of external charger (bq25892) in Yoga Book is
>   connected to one of PMIC outputs controlled by CHGDISCTRL register.
>   Enable charging at driver initialization. Pick up this from Lenovo's code
>   drop[2,3].
> 
> Please keep in mind that I have no docs for Whiskey Cove PMIC, so this patches
> are based on some kind of reverse engineering and suppositions, correct me if
> this semantic is wrong for common case.
> 
> [1]. 
> https://github.com/01org/ProductionKernelQuilts/uefi/cht-m1stable/patches/0001-power_supply-intel-pmic-ccsm-driver.patch
> [2]. 
> https://github.com/jekhor/yogabook-linux-android-kernel/blob/b7aa015ab794b516da7b6cb76e5e2d427e3b8b0c/drivers/power/bq2589x_charger.c#L2257
> [3]. 
> https://github.com/01org/ProductionKernelQuilts/uefi/cht-m1stable/patches/EM-Charger-Disable-battery-charging-in-S3-and-enable.patch
> 
> Yauhen Kharuzhy (2):
>   extcon-intel-cht-wc: Make charger detection co-existed with OTG host mode
>   extcon intel-cht-wc: Enable external charger
> 
>  drivers/extcon/extcon-intel-cht-wc.c | 71 +++-
>  1 file changed, 70 insertions(+), 1 deletion(-)
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] staging/android: use multiple futex wait queues

[Dan Carpenter]

On Thu, Feb 14, 2019 at 06:34:59PM +0100, Hugo Lefeuvre wrote:
> @@ -402,6 +410,7 @@ static int handle_vsoc_cond_wait(struct file *filp, 
> struct vsoc_cond_wait *arg)
>   struct vsoc_region_data *data = vsoc_dev.regions_data + region_number;
>   int ret = 0;
>   struct vsoc_device_region *region_p = vsoc_region_from_filep(filp);
> + struct vsoc_futex_wait_queue_t *it, *wait_queue = NULL;
 ^
>   atomic_t *address = NULL;
>   ktime_t wake_time;
>  
> @@ -415,10 +424,27 @@ static int handle_vsoc_cond_wait(struct file *filp, 
> struct vsoc_cond_wait *arg)
>   address = shm_off_to_virtual_addr(region_p->region_begin_offset +
> arg->offset);
>  
> + /* Find wait queue corresponding to offset or create it */
> + spin_lock(>futex_wait_queue_lock);
> + list_for_each_entry(it, >futex_wait_queue_list, list) {
> + if (wait_queue->offset == arg->offset) {
^^
You meant "it->offset".


> + wait_queue = it;
> + break;
> + }
> + }
> +
> + if (!wait_queue) {
> + wait_queue = kmalloc(sizeof(*wait_queue), GFP_KERNEL);
> + wait_queue->offset = arg->offset;
> + init_waitqueue_head(_queue->queue);
> + list_add(_queue->list, >futex_wait_queue_list);
> + }
> + spin_unlock(>futex_wait_queue_lock);

regards,
dan carpenter

[PATCH] ASoC: AMD: Configure master codec on all playback/capture cases

[Agrawal, Akshu]

In the system design da7219 is the master codec and clocks are
generated by it.
Bclk is to be generated at the required rate for other codecs used when
da7219 is acting only as clock master. For this call hw_params of da7219
during playback/capture on non da7219 codecs.

Being able to set bclk at lower rate also fixes noise issue observed on
some dmics.

Signed-off-by: Akshu Agrawal 
---
 sound/soc/amd/acp-da7219-max98357a.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index a5daad973ce5..ad327415290a 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -45,6 +45,7 @@
 #define CZ_PLAT_CLK 4800
 #define DUAL_CHANNEL   2
 
+static struct snd_soc_dai *codec_dai;
 static struct snd_soc_jack cz_jack;
 static struct clk *da7219_dai_clk;
 extern int bt_uart_enable;
@@ -53,8 +54,10 @@ static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
 {
int ret;
struct snd_soc_card *card = rtd->card;
-   struct snd_soc_dai *codec_dai = rtd->codec_dai;
-   struct snd_soc_component *component = codec_dai->component;
+   struct snd_soc_component *component;
+
+   codec_dai = rtd->codec_dai;
+   component = codec_dai->component;
 
dev_info(rtd->dev, "codec dai name = %s\n", codec_dai->name);
 
@@ -255,6 +258,16 @@ static void cz_dmic_shutdown(struct snd_pcm_substream 
*substream)
da7219_clk_disable();
 }
 
+static static int cz_da7219_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   /* da7219 Codec is clock master so setup as per the needs */
+   if (codec_dai->driver->ops->hw_params)
+   return codec_dai->driver->ops->hw_params(substream, params,
+codec_dai);
+   return 0;
+}
+
 static const struct snd_soc_ops cz_da7219_play_ops = {
.startup = cz_da7219_play_startup,
.shutdown = cz_da7219_shutdown,
@@ -268,16 +281,19 @@ static const struct snd_soc_ops cz_da7219_cap_ops = {
 static const struct snd_soc_ops cz_max_play_ops = {
.startup = cz_max_startup,
.shutdown = cz_max_shutdown,
+   .hw_params = cz_da7219_hw_params,
 };
 
 static const struct snd_soc_ops cz_dmic0_cap_ops = {
.startup = cz_dmic0_startup,
.shutdown = cz_dmic_shutdown,
+   .hw_params = cz_da7219_hw_params,
 };
 
 static const struct snd_soc_ops cz_dmic1_cap_ops = {
.startup = cz_dmic1_startup,
.shutdown = cz_dmic_shutdown,
+   .hw_params = cz_da7219_hw_params,
 };
 
 static struct snd_soc_dai_link cz_dai_7219_98357[] = {
-- 
2.17.1

Re: [PATCH v2] staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()

[Chao Yu]

On 2019/2/1 20:16, Gao Xiang wrote:
> As Al pointed out, "
> ... and while we are at it, what happens to
>   unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
>   unsigned int matched = min(startprfx, endprfx);
> 
>   struct qstr dname = QSTR_INIT(data + nameoff,
>   unlikely(mid >= ndirents - 1) ?
>   maxsize - nameoff :
>   le16_to_cpu(de[mid + 1].nameoff) - nameoff);
> 
>   /* string comparison without already matched prefix */
>   int ret = dirnamecmp(name, , );
> if le16_to_cpu(de[...].nameoff) is not monotonically increasing?  I.e.
> what's to prevent e.g. (unsigned)-1 ending up in dname.len?
> 
> Corrupted fs image shouldn't oops the kernel.. "
> 
> Revisit the related lookup flow to address the issue.
> 
> Fixes: d72d1ce60174 ("staging: erofs: add namei functions")
> Cc:  # 4.19+
> Suggested-by: Al Viro 
> Signed-off-by: Gao Xiang 
> ---
> [ It should be better get reviewed first and for linux-next... ]
> 
> change log v2:
>  - fix the missing "kunmap_atomic" pointed out by Dan;
>  - minor cleanup;
> 
>  drivers/staging/erofs/namei.c | 187 
> ++
>  1 file changed, 99 insertions(+), 88 deletions(-)
> 
> diff --git a/drivers/staging/erofs/namei.c b/drivers/staging/erofs/namei.c
> index 5596c52e246d..321c881d720f 100644
> --- a/drivers/staging/erofs/namei.c
> +++ b/drivers/staging/erofs/namei.c
> @@ -15,74 +15,77 @@
>  
>  #include 
>  
> -/* based on the value of qn->len is accurate */
> -static inline int dirnamecmp(struct qstr *qn,
> - struct qstr *qd, unsigned int *matched)
> +struct erofs_qstr {
> + const unsigned char *name;
> + const unsigned char *end;
> +};
> +
> +/* based on the end of qn is accurate and it must have the trailing '\0' */
> +static inline int dirnamecmp(const struct erofs_qstr *qn,
> +  const struct erofs_qstr *qd,
> +  unsigned int *matched)
>  {
> - unsigned int i = *matched, len = min(qn->len, qd->len);
> -loop:
> - if (unlikely(i >= len)) {
> - *matched = i;
> - if (qn->len < qd->len) {
> - /*
> -  * actually (qn->len == qd->len)
> -  * when qd->name[i] == '\0'
> -  */
> - return qd->name[i] == '\0' ? 0 : -1;
> + unsigned int i = *matched;
> +
> + /*
> +  * on-disk error, let's only BUG_ON in the debugging mode.
> +  * otherwise, it will return 1 to just skip the invalid name
> +  * and go on (in consideration of the lookup performance).
> +  */
> + DBG_BUGON(qd->name > qd->end);

qd->name == qd->end is not allowed as well?

So will it be better to return directly here?

if (unlikely(qd->name >= qd->end)) {
DBG_BUGON(1);
return 1;
}

> +
> + /* qd could not have trailing '\0' */
> + /* However it is absolutely safe if < qd->end */
> + while (qd->name + i < qd->end && qd->name[i] != '\0') {
> + if (qn->name[i] != qd->name[i]) {
> + *matched = i;
> + return qn->name[i] > qd->name[i] ? 1 : -1;
>   }
> - return (qn->len > qd->len);
> + ++i;
>   }
> -
> - if (qn->name[i] != qd->name[i]) {
> - *matched = i;
> - return qn->name[i] > qd->name[i] ? 1 : -1;
> - }
> -
> - ++i;
> - goto loop;
> + *matched = i;
> + /* See comments in __d_alloc on the terminating NUL character */
> + return qn->name[i] == '\0' ? 0 : 1;
>  }
>  
> -static struct erofs_dirent *find_target_dirent(
> - struct qstr *name,
> - u8 *data, int maxsize)
> +#define nameoff_from_disk(off, sz)   (le16_to_cpu(off) & ((sz) - 1))
> +
> +static struct erofs_dirent *find_target_dirent(struct erofs_qstr *name,
> +u8 *data,
> +unsigned int dirblksize,
> +const int ndirents)
>  {
> - unsigned int ndirents, head, back;
> + int head, back;
>   unsigned int startprfx, endprfx;
>   struct erofs_dirent *const de = (struct erofs_dirent *)data;
>  
> - /* make sure that maxsize is valid */
> - BUG_ON(maxsize < sizeof(struct erofs_dirent));
> -
> - ndirents = le16_to_cpu(de->nameoff) / sizeof(*de);
> -
> - /* corrupted dir (may be unnecessary...) */
> - BUG_ON(!ndirents);
> -
> - head = 0;
> + /* since the 1st dirent has been evaluated previously */
> + head = 1;
>   back = ndirents - 1;
>   startprfx = endprfx = 0;
>  
>   while (head <= back) {
> - unsigned int mid = head + (back - head) / 2;
> - unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
> + const int mid = head + (back - head) / 2;
> + const int nameoff = nameoff_from_disk(de[mid].nameoff,
> +  

Re: [PATCH 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks

[Yauhen Kharuzhy]

On Thu, Feb 14, 2019 at 04:05:26PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 14-02-19 15:15, Yauhen Kharuzhy wrote:
> > 
> > 
> > чц, 14 лют 2019, 15.47: карыстальнік Andy Shevchenko 
> >  > > напісаў:
> > 
> > On Thu, Feb 14, 2019 at 12:00:44AM +0100, Hans de Goede wrote:
> >  > On 10-02-19 21:36, Yauhen Kharuzhy wrote:
> > 
> >  > A kind request to the platform-x86 driver maintainers (hi Andy): 
> > Please
> >  > do not apply these patches until I've been able to test they don't 
> > cause
> >  > issues elsewhere.
> > 
> > Yes, that's my plan from the day one.
> > 
> > I also asked Yauhen to keep you in Cc list for all patches regarding the
> > platform he is enabling. On his GH page you may find, btw, a pile of 
> > patches.
> > I hope we will not get a patch bomb at once.
> > 
> > 
> > 
> > Yes, I plan to propose remained patches only after discussing and accepting 
> > already sent series and some reworking.
> > 
> > 
> > The charger-related part will be very discussable.
> 
> Yes I just took a look at the patches from your kernel-tree at github,
> it seems this is another quite "interesting" Cherry Trail device.
> 
> Oh if only the engineers who designed these had just use ACPI as intended
> instead of doing a bunch of spaghetti code and duck-taping it all together
> with proprietary / vendor-specific ACPI opregions. Ah well.
> 
> Note I see that your DSDT does not have any *valid* ACPI battery device
> (PNP0C0A dev), so we need to directly talk to the fuel-gauge. I also see
> that you already have some WIP code for this, good.
> 
> Taking a quick peek I also noticed the changes you did for the
> drivers/i2c/busses/i2c-cht-wc.c code instantiating the charger device.
> 
> I think it would be better to instead of using DMI matching, to
> actually probe which device is there, you can create a dummy
> client on the adapter after the i2c_add_adapter call using:
> i2c_new_dummy() and then you can do an smbus byte read from
> register 0x14, on the bq24292i which the other devices with a wcove
> pmic have you will get 0xff then since the addresses on the
> bq24292i only go up to 0x0a and on the bq2589x your device has
> you should then actually be able to check the device id you expect.
> 
> If you do this, please also read and check the 0x0a device-id register
> of the bq24292i if the 0x14 check fails, I can test this. For the
> bq24292i the expectation is for bits 3-5 to encode the value 3 (011).

Sounds reasonable. I don't like approach when we store information about
I2C devices inside of I2C bus driver but this kind of autodetection
seems to be lesser evil than a DMI matching.

> 
> If you go this route, I would also advice to change the:
> 
> if (acpi_dev_present("INT33FE", NULL, -1)) {
>   
> }
> 
> To:
> 
> if (!acpi_dev_present("INT33FE", NULL, -1))
>   goto done;
> 
> So that you don't get a too deep indentation level, making
> the end result look something like this:
> 
> 
> if (!acpi_dev_present("INT33FE", NULL, -1))
>   goto done;
> 
> test_client = i2c_new_dummy(>adapter, 0x14);
> // test for bq25892 or bq24292i
> i2c_unregister_device(test_client);
> // register correct device, this must be done after
> // unregister-ing the dummy to avoid an EBUSY error on the address
> 
> done:
> platform_set_drvdata(pdev, adap);
> return 0;
> 
> ###
> 
> I would do something similar with the fuel-gauge in
> drivers/platform/x86/intel_cht_int33fe.c, one option would
> be to simply count the number of resources in the ACPI
> resource table for the INT33FE device, versions with
> the Type-C port have 7 resources, where as your INT33FE
> device has only 3.
> 
> I'm even thinking that it might be best to rename
> intel_cht_int33fe.c to intel_cht_int33fe_typec.c and add
> a check for the resource table having 7 entries there, then
> you can make a intel_cht_int33fe_micro_usb.c copy and strip
> that mostly empty. Both would bind to the same "INT33FE"
> id and they would both silently bail with -ENODEV if the
> resource-count (or the PTYP value) don't match.
> 
> The reason I'm thinking of having 2 drivers is because
> the current intel_cht_int33fe.c is quite special / ugly and
> already has enough ifs.
> 
> If you do a stand-alone intel_cht_int33fe_micro_usb.c that can
> hopefully be much simpler.
> 
> Andy what is your take on having separate intel_cht_int33fe_typec.c
> and intel_cht_int33fe_micro_usb.c drivers, both binding to
> the "INT33FE" ACPI-ID (with its totally !@#%$#-ed up "API") ?
> 
> Having 2 drivers bind to the same id and exit silently with -ENODEV
> is somewhat normal for USB ids where we also sometimes have these
> kinda ID clashes with different devices hiding behind the same id.

Hmm... And we need to handle case when all three INT33FE devices are
enabled in the DSDT...

Instead of separating of driver to two (and more when we will find new
CHT device...) I think about some kind of configuration 

Re: Userspace regression in LTS and stable kernels

[Greg Kroah-Hartman]

On Thu, Feb 14, 2019 at 12:20:27PM -0800, Andrew Morton wrote:
> On Thu, 14 Feb 2019 09:56:46 -0800 Linus Torvalds 
>  wrote:
> 
> > On Wed, Feb 13, 2019 at 3:37 PM Richard Weinberger
> >  wrote:
> > >
> > > Your shebang line exceeds BINPRM_BUF_SIZE.
> > > Before the said commit the kernel silently truncated the shebang line
> > > (and corrupted it),
> > > now it tells the user that the line is too long.
> > 
> > It doesn't matter if it "corrupted" things by truncating it. All that
> > matters is "it used to work, now it doesn't"
> > 
> > Yes, maybe it never *should* have worked. And yes, it's sad that
> > people apparently had cases that depended on this odd behavior, but
> > there we are.
> > 
> > I see that Kees has a patch to fix it up.
> > 
> 
> Greg, I think we have a problem here.
> 
> 8099b047ecc431518 ("exec: load_script: don't blindly truncate shebang
> string") wasn't marked for backporting.  And, presumably as a
> consequence, Kees's fix "exec: load_script: allow interpreter argument
> truncation" was not marked for backporting.
> 
> 8099b047ecc431518 hasn't even appeared in a Linus released kernel, yet
> it is now present in 4.9.x, 4.14.x, 4.19.x and 4.20.x.

It came in 5.0-rc1, so it fits the "in a Linus released kernel"
requirement.  If we are to wait until it shows up in a -final, that
would be months too late for almost all of these types of patches that
are picked up.

> I don't know if Oleg considered backporting that patch.  I certainly
> did (I always do), and I decided against doing so.  Yet there it is.

This came in through Sasha's tools, which give people a week or so to
say "hey, this isn't a stable patch!" and it seems everyone ignored that
:(

Where is Kees's fix?  I'll be glad to queue it up, or just revert the
above commit, which ever people think is easiest.

thanks,

greg k-h

Re: [PATCH 4.20 00/50] 4.20.9-stable review

[Greg Kroah-Hartman]

On Thu, Feb 14, 2019 at 10:52:42AM -0600, Dan Rue wrote:
> On Wed, Feb 13, 2019 at 07:38:05PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.9 release.
> > There are 50 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Feb 15 18:36:30 UTC 2019.
> > Anything received after that time might be too late.
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Great, thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.20 00/50] 4.20.9-stable review

[Greg Kroah-Hartman]

On Thu, Feb 14, 2019 at 01:02:26PM -0800, Guenter Roeck wrote:
> On Wed, Feb 13, 2019 at 07:38:05PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.9 release.
> > There are 50 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Feb 15 18:36:30 UTC 2019.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 159 pass: 159 fail: 0
> Qemu test results:
>   total: 343 pass: 330 fail: 13
> Failed tests: 
>   sh:rts7751r2dplus_defconfig:initrd 
>   sh:rts7751r2dplus_defconfig:ata:rootfs 
>   sh:rts7751r2dplus_defconfig:mmc:rootfs 
>   sh:rts7751r2dplus_defconfig:usb:rootfs 
>   sh:rts7751r2dplus_defconfig:usb-hub:rootfs 
>   sh:rts7751r2dplus_defconfig:usb-ohci:rootfs 
>   sh:rts7751r2dplus_defconfig:usb-ehci:rootfs 
>   sh:rts7751r2dplus_defconfig:usb-xhci:rootfs 
>   sh:rts7751r2dplus_defconfig:usb-uas-ehci:rootfs 
>   sh:rts7751r2dplus_defconfig:usb-uas-xhci:rootfs 
>   sh:rts7751r2dplus_defconfig:scsi[53C810]:rootfs 
>   sh:rts7751r2dplus_defconfig:scsi[53C895A]:rootfs
>   sh:rts7751r2dplus_defconfig:scsi[FUSION]:rootfs
> 
> This failure gave me a bit of trouble. It is similar to the failure observed
> earlier with v4.4.y, but changing the C compiler version did not help (I
> tried 8.2.0 and 5.5.0), and changing the qemu version did not help either.
> Bisect points to commit 31e8a058e1f ("Revert "ext4: use ext4_write_inode()
> when fsyncing w/o a journal") as the culprit. No idea why that would be
> the case, but I repeated the bisect twice with the same results, and
> reverting that revert indeed fixes the problem. This is weird since
> one of the failing tests doesn't even mount a file system but boots
> from initrd. Go figure. Bisect results are below.
> 
> Guenter
> 
> ---
> # bad: [f4a86d6d2a0bdead7cf98d552481367e6356ef28] Linux 4.20.9-rc1
> # good: [0788acb1a3ed1589da1768ba64b1e5c76e8cb661] Linux 4.20.8
> git bisect start 'HEAD' 'v4.20.8'
> # good: [df6033ca3341635d8f529d6cdb6d37257df6f783] MIPS: OCTEON: don't set 
> octeon_dma_bar_type if PCI is disabled
> git bisect good df6033ca3341635d8f529d6cdb6d37257df6f783
> # good: [da33f30a55d08758a63de90038344f956252ea8f] drm/rockchip: rgb: update 
> SPDX license identifier
> git bisect good da33f30a55d08758a63de90038344f956252ea8f
> # good: [3ef454cd518997a8447080fb01743aaa4d4de8ae] xfrm: Make set-mark 
> default behavior backward compatible
> git bisect good 3ef454cd518997a8447080fb01743aaa4d4de8ae
> # bad: [b442f17368f050887aae5d525b4dd0e146440f94] libceph: avoid 
> KEEPALIVE_PENDING races in ceph_con_keepalive()
> git bisect bad b442f17368f050887aae5d525b4dd0e146440f94
> # bad: [31e8a058e1f9aa32254f64a9643853062141895a] Revert "ext4: use 
> ext4_write_inode() when fsyncing w/o a journal"
> git bisect bad 31e8a058e1f9aa32254f64a9643853062141895a
> # good: [0bc4dd12c3196b01d2123f95bb1c949e5eebe483] drm/i915: Try to sanitize 
> bogus DPLL state left over by broken SNB BIOSen
> git bisect good 0bc4dd12c3196b01d2123f95bb1c949e5eebe483
> # first bad commit: [31e8a058e1f9aa32254f64a9643853062141895a] Revert "ext4: 
> use ext4_write_inode() when fsyncing w/o a journal"

That's really odd, given that this is only showing up in sh and not in
any of the other releases.  I'll blame gcc for this one :(

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH v4] coccinelle: semantic patch for missing put_device()

[Julia Lawall]

On Fri, 15 Feb 2019, wen.yan...@zte.com.cn wrote:

> Hi Julia, thank you very much.
>
> > > >> In a function, for variables returned by calling 
> > > >> of_find_device_by_node(),
> > > > Do variables really get returned?
> > > > The provided pointer should usually be stored somewhere.
> > >
> > > Thank you very much, we will consider this situation and submit a next 
> > > version to fix it.
> >
> > I don't know what Markus is talking about here, so I'm not sure that a
> > change is needed.
>
> I think Markus means that we need to deal with two situations:
> 1,  The return value of of_find_device_by_node () is assigned to a variable, 
> such as:
> pdev = of_find_device_by_node(np);
> 2,  The return value of of_find_device_by_node() is assigned to a variable in 
> a structure, such as:
> dev->pdev = of_find_device_by_node(args.np);
>
> So I plan to modify the following to capture both cases:
> -local idexpression id;
> +expression id;

I'm not sure that this is a good idea.  There is likely no need for a put
in the latter case.

julia

> ...
> id = of_find_device_by_node@p1(x)
>
> > > >> + "ERROR: missing put_device;"
> > > >Will change confidence considerations result in another fine-tuning for 
> > > >this message?
> > >
> > > Thank you, we will change "ERROR" to "WARNING".
> >
> > I think ERROR is fine. If it is a real positive than it is a real
> > problem. Warning is for things that look ugly, but don't have any impact
> > on the execution.
>
> OK, I will keep it.
> Thanks.
>
> Regards,
> Wen

Re: [PATCH 4.20 00/50] 4.20.9-stable review

[Greg Kroah-Hartman]

On Thu, Feb 14, 2019 at 03:24:07PM -0700, shuah wrote:
> On 2/13/19 11:38 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.9 release.
> > There are 50 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Feb 15 18:36:30 UTC 2019.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.9-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.20.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 01/11] dt-bindings: Add vendor prefix for Silicon Linux.

[Lukasz Majewski]

Hi Fabrizio,

The best approach is to run:

git format patch -1 

And then 

scripts/get_maintainer.pl 0001-xxx

You shall see the the list of people to send the patch.

> Dear All,
> 
> Who is the best person for taking this patch?
> 
> Thanks,
> Fab
> 
> > From: Fabrizio Castro 
> > Sent: 16 January 2019 18:38
> > Subject: [PATCH 01/11] dt-bindings: Add vendor prefix for Silicon
> > Linux.
> >
> > From: Biju Das 
> >
> > Add Silicon Linux to the list of devicetree vendor prefixes.
> >
> > Website: http://www.si-linux.co.jp
> >
> > Signed-off-by: Biju Das 
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Chris Paterson 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt index
> > 4b1a2a8..02a7037 100644 ---
> > a/Documentation/devicetree/bindings/vendor-prefixes.txt +++
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -344,6
> > +344,7 @@ sgxSGX Sensortech sharpSharp Corporation
> >  shimafujiShimafuji Electric, Inc.
> >  si-enSi-En Technology Ltd.
> > +si-linuxSilicon Linux Corporation
> >  sifiveSiFive, Inc.
> >  sigmaSigma Designs, Inc.
> >  siiSeiko Instruments, Inc.
> > --
> > 2.7.4  
> 
> 
> 
> Renesas Electronics Europe GmbH,Geschaeftsfuehrer/President : Michael
> Hannawald, Sitz der Gesellschaft/Registered office: Duesseldorf,
> Arcadiastrasse 10, 40472 Duesseldorf,
> Germany,Handelsregister/Commercial Register: Duesseldorf, HRB 3708
> USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE
> reg. no.: DE 14978647




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpPp1cxZrQBp.pgp
Description: OpenPGP digital signature

RE: [PATCH] usb: gadget: udc: renesas_usb3: add support for r8a774c0

[Felipe Balbi]

Hi,

(no top-posting, please)

Fabrizio Castro  writes:

> Hello Felipe,
>
> Who is the best person for taking patches for renesas_usb3.c?

they're already in my 'next' branch. I'll send pull request to Greg shortly

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] extcon intel-cht-wc: Enable external charger

[Yauhen Kharuzhy]

On Thu, Feb 14, 2019 at 05:31:48PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 10-02-19 21:36, Yauhen Kharuzhy wrote:
> > In some configuration external charge "#charge enable" signal is
> > connected to PMIC. Enable it at device probing to allow charging.
> > 
> > Tested at Lenovo Yoga Book (YB1-X91L).
> > 
> > Signed-off-by: Yauhen Kharuzhy 
> > ---
> >   drivers/extcon/extcon-intel-cht-wc.c | 33 
> >   1 file changed, 33 insertions(+)
> > 
> > diff --git a/drivers/extcon/extcon-intel-cht-wc.c 
> > b/drivers/extcon/extcon-intel-cht-wc.c
> > index 4f6ba249bc30..00cb3084955e 100644
> > --- a/drivers/extcon/extcon-intel-cht-wc.c
> > +++ b/drivers/extcon/extcon-intel-cht-wc.c
> > @@ -57,6 +57,11 @@
> >   #define CHT_WC_USBSRC_TYPE_OTHER  8
> >   #define CHT_WC_USBSRC_TYPE_DCP_EXTPHY 9
> > +#define CHT_WC_CHGDISCTRL  0x5e2f
> > +#define CHT_WC_CHGDISCTRL_CCSM_DIS 0x11
> > +#define CHT_WC_CHGDISCTRL_CCSM_EN  0x00
> 
> Hmm, the enable mask here does not match the enable mask from:
> 
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/EM-Charger-Disable-battery-charging-in-S3-and-enable.patch
> 
> Which has:
> 
> #define CHGDISFN_EN_CCSM_VAL   0x50
> #define CHGDISFN_DIS_CCSM_VAL  0x11
> #define CHGDISFN_CCSM_MASK 0x51
> 
> Where as on my hardware, the PMIC comes up with 0x50
> in the 0x5e2f register, exactly matching the values
> from that patch.
> 
> Why did you change this value ?

Good question... I found this values in Lenovo's sources and use them
'as is':
https://github.com/jekhor/yogabook-linux-android-kernel/blob/b7aa015ab794b516da7b6cb76e5e2d427e3b8b0c/drivers/power/intel_pmic_ccsm.h#L255

I don't remember if charger worked with Intel's value, I need to
re-check this.

(...why does Intel close documentation for this piece of HW?...)

> 
> It would be interesting to get a dump of the
> charger's i2c registers using i2cdump before
> and after writing this new value to register
> 0x5e2f. Note you can simply leave the patch adding
> the write out of the kernel, and then do:
> 
> i2cdump 
> i2cget -y -f 6 0x5e 0x2f
> # check 0x00 is the correct val
> i2cset -y -f 6 0x5e 0x2f 0x00
> i2cdump 
> 
> To see if any reg values of the charger-ic have changed.
> 
> Note bus 6 is the right bus for the PMIC on my systems,
> but it might be different, to find the right bus do:
> 
> ls -l /sys/bus/devices/i2c-INT34D3:00
> 
> And look at what the i2c bus-number is in that symlink.
> 
> 
> Also can you please provide i2cdump output for the
> 0x5e and 0x6e devices of the PMIC, preferably from a
> clean boot, without your patches, so that we can
> see what the value of the 0x5e2f register is before
> your code modifies it.
> 
> i2cdump -y -f 6 0x5e
> i2cdump -y -f 6 0x6e

OK, I will send this dumps soon. I used i2get/i2cset for checking this
values and PMIC behaviour already but don't remember exactly results.


-- 
Yauhen Kharuzhy

Re: [PATCH v3] exec: load_script: Do not exec truncated interpreter path

[Kees Cook]

On Thu, Feb 14, 2019 at 10:14 PM Kees Cook  wrote:
> But, as it turns out, the above is actually wrong too (yay for my test
> cases): the NUL termination before the loop (line 45) may blow away
> the newline at byte 127. So we need to actually manually scan for the
> newline while doing the out-of-bounds checking. (This was part of
> Oleg's original "don't blindly truncate" rationale in the reverted
> patch.)

Actually, though, this passes my regression tests:

diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index 7cde3f46ad26..6d7787e35d76 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -42,9 +42,18 @@ static int load_script(struct linux_binprm *bprm)
fput(bprm->file);
bprm->file = NULL;

-   bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
-   if ((cp = strchr(bprm->buf, '\n')) == NULL)
-   cp = bprm->buf+BINPRM_BUF_SIZE-1;
+   if ((cp = strnchr(bprm->buf, BINPRM_BUF_SIZE, '\n')) == NULL) {
+   bool truncated = true;
+
+   for (cp = bprm->buf+2; cp < bprm->buf+BINPRM_BUF_SIZE-1 &&
+  ((*cp == ' ') || (*cp == '\t')); cp++);
+   for (; cp < bprm->buf+BINPRM_BUF_SIZE-1; cp++) {
+   if ((*cp == ' ') || (*cp == '\t'))
+   truncated = false;
+   }
+   if (truncated)
+   return -ENOEXEC; /* Interpreter truncated */
+   }
*cp = '\0';
while (cp > bprm->buf) {
cp--;

I still want to add all the comments, though. :)

(The above still seems uglier to me than just collecting the
information as we need it, but I'll do whatever.)

What do you think?

-- 
Kees Cook

Re: [PATCH v4] coccinelle: semantic patch for missing put_device()

[Julia Lawall]

On Fri, 15 Feb 2019, wen.yan...@zte.com.cn wrote:

> > How do you think about to exchange the word “patch” by “code search”
> > at affected places (and in the subject) then?
>
> Thanks, we‘ll fix it.
>
> >> In a function, for variables returned by calling of_find_device_by_node(),
> > Do variables really get returned?
> > The provided pointer should usually be stored somewhere.
>
> Thank you very much, we will consider this situation and  submit a next 
> version to fix it.

I don't know what Markus is talking about here, so I'm not sure that a
change is needed.

>
> > * Would you like to pick any software development challenges up around
> > inter-procedural data flow (or even escape) analysis for the shown use case?
>
> We are very interested in doing this work, but currently coccinelle may
> not support data flow analysis, and we hope to contribute a little.
>
> > Would you like to add a SPDX identifier?
>
> OK, we will add a SPDX identifierfix soon.
>
> >> + "ERROR: missing put_device;"
> >Will change confidence considerations result in another fine-tuning for this 
> >message?
>
> Thank you, we will change "ERROR" to "WARNING".

I think ERROR is fine.  If it is a real positive than it is a real
problem.  Warning is for things that look ugly, but don't have any impact
on the execution.

julia

> >> + + " call of_find_device_by_node on line "
> >I find that such a split string literal can be unwanted.
>
> Thank you, we will fix it soon.
>
> >> + + " and return without releasing.")
> >Possible rewording?
> >+ + " but without a corresponding object release within this function.")
>
> Thanks, we will modify it according to your suggestion.
>
> Regards,
> Wen

Re: [PATCH v2 08/15] PCI: endpoint: Fix pci_epf_alloc_space to set correct MEM TYPE flags

[Kishon Vijay Abraham I]

Hi Lorenzo,

On 14/02/19 9:59 PM, Lorenzo Pieralisi wrote:
> On Wed, Feb 13, 2019 at 07:17:14PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Lorenzo,
>>
>> On 11/02/19 11:07 PM, Lorenzo Pieralisi wrote:
>>> On Mon, Jan 14, 2019 at 04:45:06PM +0530, Kishon Vijay Abraham I wrote:
 pci_epf_alloc_space() sets the MEM TYPE flags to indicate a 32-bit
 Base Address Register irrespective of the size. Fix it here to indicate
 64-bit BAR if the size is > 2GB.

 Signed-off-by: Kishon Vijay Abraham I 
 ---
  drivers/pci/endpoint/pci-epf-core.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> This looks like a fix and should me marked as such. Does it work
>>> as as standalone patch if it gets backported ?
>>
>> Yeah, it should work. But the current users doesn't allocate > 2GB and some
>> EPC drivers configure their registers based on size. So nothing is broken
>> without this patch as such.
> 
> I suspect you mean 4GB (here and the commit log), right ? I am checking
> the commit logs, aiming at merging the patches.

A 32bit BAR register can support a 'size' of only up to 2GB. Though it can hold
a memory address of up to 4GB.

This is also mentioned in the PCI Local Bus Specification.
"A 32-bit register can be implemented to support a single memory size that is a
power of 2 from 16 bytes to 2 GB"

Thanks
Kishon

Re: [PATCH 0/4] crypto: caam - add ecb mode support

[Herbert Xu]

On Thu, Feb 14, 2019 at 09:54:47PM -0800, Eric Biggers wrote:
>
> Sure, but the bar shouldn't be so low that new implementations of insecure
> algorithms the world is moving away from are accepted without a real use case.
> We should be moving towards removing these algorithms instead.  The original 
> DES
> is especially bad as it only has a 56-bit key.  I'd like to better understand
> if/why people claim to not only still need these algorithms in 2019, but also
> need brand new implementations of them.

If we're going to remove DES then we should remove all implementations
of it and not single out a single driver.

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

Re: [PATCH v3] exec: load_script: Do not exec truncated interpreter path

[Kees Cook]

On Thu, Feb 14, 2019 at 8:49 PM Linus Torvalds
 wrote:
>
>
>
> On Thu, Feb 14, 2019, 19:18 Kees Cook >
>>
>>  fs/binfmt_script.c | 97 +++---
>>  1 file changed, 82 insertions(+), 15 deletions(-)
>
> No, why?

In my defense, 56 of those 82 lines are comments. ;)

>> -   if ((cp = strchr(bprm->buf, '\n')) == NULL)
>> -   cp = bprm->buf+BINPRM_BUF_SIZE-1;
>
>
> This statement when we've not seen a newline should simply get a "is there at 
> least a whitespace in there somewhere" test. Nothing more than that, afaik.

Unfortunately I don't think this is true for two reasons. First, the
leading spaces don't indicate that we won't later truncate the
interpreter path.

i.e. this is valid:
"#!/usr/bin/perl"
but this could get truncated, even though we see whitespace:
"#!/some/insane/nfs/or/hexified/path/longer/than/127/bytes"

The only way we know the interpreter wasn't truncated in the
no-newline case is if we see whitespace after first skipping any
leading whitespace, and it seemed really ugly to add a special scan
there. This is what I had for that, minus comments:

diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index 7cde3f46ad26..6d7ef98bc949 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -43,8 +43,18 @@ static int load_script(struct linux_binprm *bprm)
bprm->file = NULL;

bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
-   if ((cp = strchr(bprm->buf, '\n')) == NULL)
-   cp = bprm->buf+BINPRM_BUF_SIZE-1;
+   if ((cp = strchr(bprm->buf, '\n')) == NULL) {
+   bool whitespace = false;
+
+   for (cp = bprm->buf+2; cp < bprm->buf+BINPRM_BUF_SIZE-1 &&
+  ((*cp == ' ') || (*cp == '\t')); cp++);
+   for (; cp < bprm->buf+BINPRM_BUF_SIZE-1; cp++) {
+   if ((*cp == ' ') || (*cp == '\t'))
+   whitespace = true;
+   }
+   if (!whitespace)
+   return -ENOEXEC; /* Interpreter truncated */
+   }
*cp = '\0';
while (cp > bprm->buf) {
cp--;

But, as it turns out, the above is actually wrong too (yay for my test
cases): the NUL termination before the loop (line 45) may blow away
the newline at byte 127. So we need to actually manually scan for the
newline while doing the out-of-bounds checking. (This was part of
Oleg's original "don't blindly truncate" rationale in the reverted
patch.)

I had also tried building some state machine to walk the bytes and do
everything in a single pass, but it was horrible. In another attempt I
tried converting as much to using "standard" C string routines
(isspace(), strchr(), strsep(), etc), but that was even more terrible.

So I opted to keep most of the existing logic but add the places where
tests were needed (along with comments describing wtf is happening
along the way). Anyway, I'm open to suggestions, obviously. :)

-- 
Kees Cook

[PATCH v7 4/6] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile

[Erin Lo]

From: Ben Ho 

Add basic chip support for Mediatek 8183, include
uart node with correct uart clocks, pwrap device

Add clock controller nodes, include topckgen, infracfg,
apmixedsys and subsystem.

Signed-off-by: Ben Ho 
Signed-off-by: Erin Lo 
Signed-off-by: Seiya Wang 
Signed-off-by: Weiyi Lu 
Signed-off-by: Zhiyong Tao 
Signed-off-by: Hsin-Hsiung Wang 
Signed-off-by: Eddie Huang 
---
 arch/arm64/boot/dts/mediatek/Makefile   |   1 +
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts |  31 +++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi| 336 
 3 files changed, 368 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index e8f952f..458bbc4 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -7,3 +7,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
new file mode 100644
index 000..9b52559
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho 
+ *Erin Lo 
+ */
+
+/dts-v1/;
+#include "mt8183.dtsi"
+
+/ {
+   model = "MediaTek MT8183 evaluation board";
+   compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
+
+   aliases {
+   serial0 = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x8000>;
+   };
+
+   chosen {
+   stdout-path = "serial0:921600n8";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
new file mode 100644
index 000..1bd1399
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -0,0 +1,336 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho 
+ *Erin Lo 
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt8183";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x000>;
+   enable-method = "psci";
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x001>;
+   enable-method = "psci";
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x002>;
+   enable-method = "psci";
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x003>;
+   enable-method = "psci";
+   };
+
+   cpu4: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a73";
+   reg = <0x100>;
+   enable-method = 

[PATCH v7 3/6] dt-bindings: pinctrl: mt8183: add binding document

[Erin Lo]

From: Zhiyong Tao 

The commit adds mt8183 compatible node in binding document.

Signed-off-by: Zhiyong Tao 
Signed-off-by: Erin Lo 
---
 .../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 115 +
 1 file changed, 115 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
new file mode 100644
index 000..364e673
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
@@ -0,0 +1,115 @@
+* Mediatek MT8183 Pin Controller
+
+The Mediatek's Pin controller is used to control SoC pins.
+
+Required properties:
+- compatible: value should be one of the following.
+   "mediatek,mt8183-pinctrl", compatible with mt8183 pinctrl.
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
+  binding is used, the amount of cells must be specified as 2. See the below
+  mentioned gpio binding representation for description of particular cells.
+- gpio-ranges : gpio valid number range.
+- reg: physicall address base for gpio base registers. There are nine
+  physicall address base in mt8183. They are 0x10005000, 0x11F2,
+  0x11E8, 0x11E7, 0x11E9, 0x11D3, 0x11D2, 0x11C5,
+  0x11F3.
+
+   Eg: < 6 0>
+   <[phandle of the gpio controller node]
+   [line number within the gpio controller]
+   [flags]>
+
+   Values for gpio specifier:
+   - Line number: is a value between 0 to 202.
+   - Flags:  bit field of flags, as defined in .
+Only the following flags are supported:
+0 - GPIO_ACTIVE_HIGH
+1 - GPIO_ACTIVE_LOW
+
+Optional properties:
+- reg-names: gpio base register names. There are nine gpio base register
+  names in mt8183. They are "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4",
+  "iocfg5", "iocfg6", "iocfg7", "iocfg8".
+- interrupt-controller: Marks the device node as an interrupt controller
+- #interrupt-cells: Should be two.
+- interrupts : The interrupt outputs from the controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+Subnode format
+A pinctrl node should contain at least one subnodes representing the
+pinctrl groups available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, pullups, drive strength, input enable/disable and input schmitt.
+
+node {
+   pinmux = ;
+   GENERIC_PINCONFIG;
+};
+
+Required properties:
+- pinmux: integer array, represents gpio pin number and mux setting.
+Supported pin number and mux varies for different SoCs, and are defined
+as macros in boot/dts/-pinfunc.h directly.
+
+Optional properties:
+- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable,
+bias-pull-down, bias-pull-up, input-enable, input-disable, output-low, 
output-high,
+input-schmitt-enable, input-schmitt-disable and drive-strength are valid.
+
+Some special pins have extra pull up strength, there are R0 and R1 pull-up
+resistors available, but for user, it's only need to set R1R0 as 00, 01, 
10 or 11.
+So when config mediatek,pull-up-adv or mediatek,pull-down-adv,
+it support arguments for those special pins.
+
+When config drive-strength, it can support some arguments, such as
+MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h.
+
+Examples:
+
+#include "mt8183-pinfunc.h"
+
+...
+{
+   pio: pinctrl@10005000 {
+   compatible = "mediatek,mt8183-pinctrl";
+   reg = <0 0x10005000 0 0x1000>,
+ <0 0x11F2 0 0x1000>,
+ <0 0x11E8 0 0x1000>,
+ <0 0x11E7 0 0x1000>,
+ <0 0x11E9 0 0x1000>,
+ <0 0x11D3 0 0x1000>,
+ <0 0x11D2 0 0x1000>,
+ <0 0x11C5 0 0x1000>,
+ <0 0x11F3 0 0x1000>;
+   reg-names = "iocfg0", "iocfg1", "iocfg2",
+   "iocfg3", "iocfg4", "iocfg5",
+   "iocfg6", "iocfg7", "iocfg8";
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 192>;
+   interrupt-controller;
+   interrupts = ;
+   interrupt-parent = <>;
+   #interrupt-cells = <2>;
+
+   i2c0_pins_a: i2c0 {
+   pins1 {
+   pinmux = ,
+;
+   mediatek,pull-up-adv = <11>;
+   };
+   };
+
+   i2c1_pins_a: i2c1 {
+   pins {
+  

[PATCH v7 5/6] arm64: dts: mt8183: add pintcrl file

[Erin Lo]

This patch adds pinctrl file for mt8183.

Signed-off-by: Zhiyong Tao 
Signed-off-by: Erin Lo 
---
 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h | 1120 +
 1 file changed, 1120 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h 
b/arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
new file mode 100644
index 000..768e41e
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
@@ -0,0 +1,1120 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Zhiyong Tao 
+ *
+ */
+
+#ifndef __MT8183_PINFUNC_H
+#define __MT8183_PINFUNC_H
+
+#include 
+
+#define PINMUX_GPIO0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define PINMUX_GPIO0__FUNC_MRG_SYNC (MTK_PIN_NO(0) | 1)
+#define PINMUX_GPIO0__FUNC_PCM0_SYNC (MTK_PIN_NO(0) | 2)
+#define PINMUX_GPIO0__FUNC_TP_GPIO0_AO (MTK_PIN_NO(0) | 3)
+#define PINMUX_GPIO0__FUNC_SRCLKENAI0 (MTK_PIN_NO(0) | 4)
+#define PINMUX_GPIO0__FUNC_SCP_SPI2_CS (MTK_PIN_NO(0) | 5)
+#define PINMUX_GPIO0__FUNC_I2S3_MCK (MTK_PIN_NO(0) | 6)
+#define PINMUX_GPIO0__FUNC_SPI2_CSB (MTK_PIN_NO(0) | 7)
+
+#define PINMUX_GPIO1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define PINMUX_GPIO1__FUNC_MRG_CLK (MTK_PIN_NO(1) | 1)
+#define PINMUX_GPIO1__FUNC_PCM0_CLK (MTK_PIN_NO(1) | 2)
+#define PINMUX_GPIO1__FUNC_TP_GPIO1_AO (MTK_PIN_NO(1) | 3)
+#define PINMUX_GPIO1__FUNC_CLKM3 (MTK_PIN_NO(1) | 4)
+#define PINMUX_GPIO1__FUNC_SCP_SPI2_MO (MTK_PIN_NO(1) | 5)
+#define PINMUX_GPIO1__FUNC_I2S3_BCK (MTK_PIN_NO(1) | 6)
+#define PINMUX_GPIO1__FUNC_SPI2_MO (MTK_PIN_NO(1) | 7)
+
+#define PINMUX_GPIO2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define PINMUX_GPIO2__FUNC_MRG_DO (MTK_PIN_NO(2) | 1)
+#define PINMUX_GPIO2__FUNC_PCM0_DO (MTK_PIN_NO(2) | 2)
+#define PINMUX_GPIO2__FUNC_TP_GPIO2_AO (MTK_PIN_NO(2) | 3)
+#define PINMUX_GPIO2__FUNC_SCL6 (MTK_PIN_NO(2) | 4)
+#define PINMUX_GPIO2__FUNC_SCP_SPI2_CK (MTK_PIN_NO(2) | 5)
+#define PINMUX_GPIO2__FUNC_I2S3_LRCK (MTK_PIN_NO(2) | 6)
+#define PINMUX_GPIO2__FUNC_SPI2_CLK (MTK_PIN_NO(2) | 7)
+
+#define PINMUX_GPIO3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define PINMUX_GPIO3__FUNC_MRG_DI (MTK_PIN_NO(3) | 1)
+#define PINMUX_GPIO3__FUNC_PCM0_DI (MTK_PIN_NO(3) | 2)
+#define PINMUX_GPIO3__FUNC_TP_GPIO3_AO (MTK_PIN_NO(3) | 3)
+#define PINMUX_GPIO3__FUNC_SDA6 (MTK_PIN_NO(3) | 4)
+#define PINMUX_GPIO3__FUNC_TDM_MCK (MTK_PIN_NO(3) | 5)
+#define PINMUX_GPIO3__FUNC_I2S3_DO (MTK_PIN_NO(3) | 6)
+#define PINMUX_GPIO3__FUNC_SCP_VREQ_VAO (MTK_PIN_NO(3) | 7)
+
+#define PINMUX_GPIO4__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define PINMUX_GPIO4__FUNC_PWM_B (MTK_PIN_NO(4) | 1)
+#define PINMUX_GPIO4__FUNC_I2S0_MCK (MTK_PIN_NO(4) | 2)
+#define PINMUX_GPIO4__FUNC_SSPM_UTXD_AO (MTK_PIN_NO(4) | 3)
+#define PINMUX_GPIO4__FUNC_MD_URXD1 (MTK_PIN_NO(4) | 4)
+#define PINMUX_GPIO4__FUNC_TDM_BCK (MTK_PIN_NO(4) | 5)
+#define PINMUX_GPIO4__FUNC_TP_GPIO4_AO (MTK_PIN_NO(4) | 6)
+#define PINMUX_GPIO4__FUNC_DAP_MD32_SWD (MTK_PIN_NO(4) | 7)
+
+#define PINMUX_GPIO5__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define PINMUX_GPIO5__FUNC_PWM_C (MTK_PIN_NO(5) | 1)
+#define PINMUX_GPIO5__FUNC_I2S0_BCK (MTK_PIN_NO(5) | 2)
+#define PINMUX_GPIO5__FUNC_SSPM_URXD_AO (MTK_PIN_NO(5) | 3)
+#define PINMUX_GPIO5__FUNC_MD_UTXD1 (MTK_PIN_NO(5) | 4)
+#define PINMUX_GPIO5__FUNC_TDM_LRCK (MTK_PIN_NO(5) | 5)
+#define PINMUX_GPIO5__FUNC_TP_GPIO5_AO (MTK_PIN_NO(5) | 6)
+#define PINMUX_GPIO5__FUNC_DAP_MD32_SWCK (MTK_PIN_NO(5) | 7)
+
+#define PINMUX_GPIO6__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define PINMUX_GPIO6__FUNC_PWM_A (MTK_PIN_NO(6) | 1)
+#define PINMUX_GPIO6__FUNC_I2S0_LRCK (MTK_PIN_NO(6) | 2)
+#define PINMUX_GPIO6__FUNC_IDDIG (MTK_PIN_NO(6) | 3)
+#define PINMUX_GPIO6__FUNC_MD_URXD0 (MTK_PIN_NO(6) | 4)
+#define PINMUX_GPIO6__FUNC_TDM_DATA0 (MTK_PIN_NO(6) | 5)
+#define PINMUX_GPIO6__FUNC_TP_GPIO6_AO (MTK_PIN_NO(6) | 6)
+#define PINMUX_GPIO6__FUNC_CMFLASH (MTK_PIN_NO(6) | 7)
+
+#define PINMUX_GPIO7__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define PINMUX_GPIO7__FUNC_SPI1_B_MI (MTK_PIN_NO(7) | 1)
+#define PINMUX_GPIO7__FUNC_I2S0_DI (MTK_PIN_NO(7) | 2)
+#define PINMUX_GPIO7__FUNC_USB_DRVVBUS (MTK_PIN_NO(7) | 3)
+#define PINMUX_GPIO7__FUNC_MD_UTXD0 (MTK_PIN_NO(7) | 4)
+#define PINMUX_GPIO7__FUNC_TDM_DATA1 (MTK_PIN_NO(7) | 5)
+#define PINMUX_GPIO7__FUNC_TP_GPIO7_AO (MTK_PIN_NO(7) | 6)
+#define PINMUX_GPIO7__FUNC_DVFSRC_EXT_REQ (MTK_PIN_NO(7) | 7)
+
+#define PINMUX_GPIO8__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define PINMUX_GPIO8__FUNC_SPI1_B_CSB (MTK_PIN_NO(8) | 1)
+#define PINMUX_GPIO8__FUNC_ANT_SEL3 (MTK_PIN_NO(8) | 2)
+#define PINMUX_GPIO8__FUNC_SCL7 (MTK_PIN_NO(8) | 3)
+#define PINMUX_GPIO8__FUNC_CONN_MCU_TRST_B (MTK_PIN_NO(8) | 4)
+#define PINMUX_GPIO8__FUNC_TDM_DATA2 (MTK_PIN_NO(8) | 5)
+#define PINMUX_GPIO8__FUNC_MD_INT0 (MTK_PIN_NO(8) | 6)
+#define PINMUX_GPIO8__FUNC_JTRSTN_SEL1 (MTK_PIN_NO(8) | 7)
+
+#define PINMUX_GPIO9__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define PINMUX_GPIO9__FUNC_SPI1_B_MO (MTK_PIN_NO(9) | 1)
+#define PINMUX_GPIO9__FUNC_ANT_SEL4 

[PATCH v7 6/6] arm64: dts: mt8183: add spi node

[Erin Lo]

Add spi DTS node to the mt8183 and mt8183-evb.

Signed-off-by: Mengqi Zhang 
Signed-off-by: Erin Lo 
---
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 105 
 arch/arm64/boot/dts/mediatek/mt8183.dtsi|  79 +
 2 files changed, 184 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 9b52559..b12c6ea 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -26,6 +26,111 @@
};
 };
 
+ {
+   spi_pins_0: spi0{
+   pins_spi{
+   pinmux = ,
+,
+,
+;
+   bias-disable;
+   };
+   };
+
+   spi_pins_1: spi1{
+   pins_spi{
+   pinmux = ,
+,
+,
+;
+   bias-disable;
+   };
+   };
+
+   spi_pins_2: spi2{
+   pins_spi{
+   pinmux = ,
+,
+,
+;
+   bias-disable;
+   };
+   };
+
+   spi_pins_3: spi3{
+   pins_spi{
+   pinmux = ,
+,
+,
+;
+   bias-disable;
+   };
+   };
+
+   spi_pins_4: spi4{
+   pins_spi{
+   pinmux = ,
+,
+,
+;
+   bias-disable;
+   };
+   };
+
+   spi_pins_5: spi5{
+   pins_spi{
+   pinmux = ,
+,
+,
+;
+   bias-disable;
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_0>;
+   mediatek,pad-select = <0>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_1>;
+   mediatek,pad-select = <0>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_2>;
+   mediatek,pad-select = <0>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_3>;
+   mediatek,pad-select = <0>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_4>;
+   mediatek,pad-select = <0>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_5>;
+   mediatek,pad-select = <0>;
+   status = "okay";
+
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 1bd1399..165b859 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include "mt8183-pinfunc.h"
 
 / {
compatible = "mediatek,mt8183";
@@ -267,6 +268,84 @@
status = "disabled";
};
 
+   spi0: spi@1100a000 {
+   compatible = "mediatek,mt8183-spi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0 0x1100a000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_TOP_SYSPLL_D5_D2>,
+< CLK_TOP_MUX_SPI>,
+< CLK_INFRA_SPI0>;
+   clock-names = "parent-clk", "sel-clk", "spi-clk";
+   status = "disabled";
+   };
+
+   spi1: spi@1101 {
+   compatible = "mediatek,mt8183-spi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0 0x1101 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_TOP_SYSPLL_D5_D2>,
+< CLK_TOP_MUX_SPI>,
+< CLK_INFRA_SPI1>;
+   clock-names = "parent-clk", "sel-clk", "spi-clk";
+   status = "disabled";
+   };
+
+   spi2: spi@11012000 {
+   compatible = "mediatek,mt8183-spi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0 0x11012000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_TOP_SYSPLL_D5_D2>,
+< CLK_TOP_MUX_SPI>,
+  

[PATCH v7 2/6] dt-bindings: serial: Add compatible for Mediatek MT8183

[Erin Lo]

This adds dt-binding documentation of uart for Mediatek MT8183 SoC
Platform.

Signed-off-by: Erin Lo 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt 
b/Documentation/devicetree/bindings/serial/mtk-uart.txt
index 742cb47..bcfb131 100644
--- a/Documentation/devicetree/bindings/serial/mtk-uart.txt
+++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
@@ -16,6 +16,7 @@ Required properties:
   * "mediatek,mt8127-uart" for MT8127 compatible UARTS
   * "mediatek,mt8135-uart" for MT8135 compatible UARTS
   * "mediatek,mt8173-uart" for MT8173 compatible UARTS
+  * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS
   * "mediatek,mt6577-uart" for MT6577 and all of the above
 
 - reg: The base address of the UART register bank.
-- 
1.9.1

[PATCH v7 1/6] dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183

[Erin Lo]

This adds dt-binding documentation of SYSIRQ for Mediatek MT8183 SoC
Platform.

Signed-off-by: Erin Lo 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt 
b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
index 33a98eb..91aa9ab 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
@@ -5,6 +5,7 @@ interrupt.
 
 Required properties:
 - compatible: should be
+   "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183
"mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173
"mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135
"mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127
-- 
1.9.1

[PATCH v7 0/6] Add basic and clock support for Mediatek MT8183 SoC

[Erin Lo]

MT8183 is a SoC based on 64bit ARMv8 architecture.
It contains 4 CA53 and 4 CA73 cores.
MT8183 share many HW IP with MT65xx series.
This patchset was tested on MT8183 evaluation board and use correct clock to 
shell.

This series contains document bindings, device tree including interrupt, uart, 
clock,
pinctrl, spi, and pwrap.

Based on v5.0-rc1 and
http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016243.html

Change in v7:
1. Place all the MMIO peripherals under one or more simple-bus nodes
2. Make the pinfunc.h and spi node into seperate patch
3. Modify SPIs pamerater from 4 back to 3 
   and remove patch "support 4 interrupt parameters for sysirq"
4. Rename intpol-controller to interrupt-controller
5. Rename pinctrl@1000b000 to pinctrl@10005000

Change in v6:
1. Remove power and iommu nodes
2. Fix dtb build warning
3. Fix pinctrl binding doc
4. Fix '_' in node names

Change in v5:
1. Collect all device tree nodes to the last patch
2. Add PMU
3. Add Signed-off-by
4. Remove clock driver code and binding doc
5. Add pinctrl, iommu, spi, and pwrap nodes

Change in v4:
1. Correct syntax error in dtsi
2. Add MT8183 clock support

Change in v3:
1. Fill out GICC, GICH, GICV regions
2. Update Copyright to 2018

Change in v2:
1. Split dt-bindings into different patches 2. Correct bindings for supported 
SoCs (mtk-uart.txt)

Ben Ho (1):
  arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and
Makefile

Erin Lo (4):
  dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183
  dt-bindings: serial: Add compatible for Mediatek MT8183
  arm64: dts: mt8183: add pintcrl file
  arm64: dts: mt8183: add spi node

Zhiyong Tao (1):
  dt-bindings: pinctrl: mt8183: add binding document

 .../interrupt-controller/mediatek,sysirq.txt   |1 +
 .../devicetree/bindings/pinctrl/pinctrl-mt8183.txt |  115 ++
 .../devicetree/bindings/serial/mtk-uart.txt|1 +
 arch/arm64/boot/dts/mediatek/Makefile  |1 +
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts|  136 +++
 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h  | 1120 
 arch/arm64/boot/dts/mediatek/mt8183.dtsi   |  415 
 7 files changed, 1789 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi

--
1.9.1

linux-next: Tree for Feb 15

[Stephen Rothwell]

Hi all,

Changes since 20190214:

The tip tree gained a conflict against the net-next tree.

The akpm tree lost a patch that turned up elsewhere,

Non-merge commits (relative to Linus' tree): 7981
 8238 files changed, 332149 insertions(+), 195576 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 296 trees (counting Linus' and 69 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (23e93c9b2cde Revert "gfs2: read journal in large chunks 
to locate the head")
Merging fixes/master (0dd62c042779 x86/syscalls: Mark expected switch 
fall-throughs)
Merging kbuild-current/fixes (207a369e3c08 sh: fix build error for invisible 
CONFIG_BUILTIN_DTB_SOURCE)
Merging arc-current/for-curr (7e9246a982a6 ARCv2: support manual regfile save 
on interrupts)
Merging arm-current/fixes (fc67e6f120a3 ARM: 8835/1: dma-mapping: Clear DMA ops 
on teardown)
Merging arm64-fixes/for-next/fixes (ea5736805190 arm64: kexec_file: handle 
empty command-line)
Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes)
Merging powerpc-fixes/fixes (5a3840a470c4 powerpc/papr_scm: Use the correct 
bind address)
Merging sparc/master (b71acb0e3721 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (f9bcc9f3ee4f net: ethernet: freescale: set FEC ethtool regs 
version)
Merging bpf/master (1e405c1a3f66 xsk: do not remove umem from netdevice on 
fall-back to copy-mode)
Merging ipsec/master (fc2d5cfdcfe2 af_key: unconditionally clone on broadcast)
Merging netfilter/master (8d6ea932856c net: dsa: bcm_sf2: potential array 
overflow in bcm_sf2_sw_suspend())
Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must 
not have side effects)
Merging wireless-drivers/master (d04ca383860b mt76x0u: fix suspend/resume)
Merging mac80211/master (6157ca0d6bfe mac80211: Fix Tx aggregation session tear 
down with ITXQs)
Merging rdma-fixes/for-rc (48396e80fb65 RDMA/srp: Rework SCSI device reset 
handling)
Merging sound-current/for-linus (c8c6ee611926 ALSA: hda/realtek: Disable PC 
beep in passthrough on alc285)
Merging sound-asoc-fixes/for-linus (585c8c9bcc7c Merge branch 'asoc-5.0' into 
asoc-linus)
Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4)
Merging regulator-fixes/for-linus (4b70f636189b Merge branch 'regulator-5.0' 
into regulator-linus)
Merging spi-fixes/for-linus (e7f77d1a86f2 Merge branch 'spi-5.0' into spi-linus)
Merging pci-current/for-linus (f57a98e1b713 PCI: Work around Synopsys duplicate 
Device ID (HAPS USB3, NXP i.MX))
Merging driver-core.current/driver-core-linus (d13937116f1e Linux 5.0-rc6)
Merging tty.current/tty-linus (d13937116f1e Linux 5.0-rc6)
Merging usb.current/usb-linus (d13937116f1e Linux 5.0-rc6)
Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x: fix race 
condition in _probe)
Merging usb-serial-fixes/usb-linus (dd9d3d86b08d USB: serial: cp210x: add ID 
for Ingenico 3070)
Merging usb-chipidea-fixes/ci-for-usb-stable (d6d768a0ec3c usb: chipidea: fix 
static checker warning for NULL pointer)
Merging phy/fixes (827cb0323928 phy: ath79-usb: Fix the main reset name to 
match the DT binding)
Merging staging.current/staging-linus (d1393

[PATCH v2 1/2] mmc: core: do not retry CMD6 in __mmc_switch()

[Chaotian Jing]

the response type of CMD6 is R1B, when the first CMD6 gets response
CRC error, do retry may get timeout error due to card may still in
busy state, which cause this retry make no sense.

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/core/mmc_ops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 9054329..c5208fb 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -562,7 +562,7 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, 
u8 value,
if (index == EXT_CSD_SANITIZE_START)
cmd.sanitize_busy = true;
 
-   err = mmc_wait_for_cmd(host, , MMC_CMD_RETRIES);
+   err = mmc_wait_for_cmd(host, , 0);
if (err)
goto out;
 
-- 
1.8.1.1.dirty

[PATCH v2 2/2] mmc: mmc: Fix HS setting in mmc_hs400_to_hs200()

[Chaotian Jing]

mmc_hs400_to_hs200() begins with the card and host in HS400 mode.
before send CMD6 to switch card's timing to HS mode, it reduce clock
frequency to 50Mhz firstly, the original intention of reduce clock
is to make "more stable" when doing HS switch. however,reduce clock
frequency to 50Mhz but without host timming change may cause CMD6
response CRC error. because host is still running at hs400 mode,
and it's hard to find a suitable setting for all eMMC cards when
clock frequency reduced to 50Mhz but card & host still in hs400 mode.

so that We consider that CMD6 response CRC error is not a fatal error,
if host gets CMD6 response CRC error, it means that card has already
received this command.

Signed-off-by: Chaotian Jing 
Fixes: ef3d232245ab ("mmc: mmc: Relax checking for switch errors after HS200 
switch")
---
 drivers/mmc/core/mmc.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 09c688f..03d1c17 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1248,8 +1248,25 @@ int mmc_hs400_to_hs200(struct mmc_card *card)
err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
   val, card->ext_csd.generic_cmd6_time, 0,
   true, false, true);
-   if (err)
-   goto out_err;
+   /*
+* as we are on the way to do re-tune, so if the CMD6 got response CRC
+* error, do not treat it as error.
+*/
+   if (err) {
+   if (err == -EILSEQ) {
+   /*
+* card will busy after sending out response and host
+* driver may not wait busy de-assert when get
+* response CRC error. so just wait enough time to
+* ensure card leave busy state.
+*/
+   mmc_delay(card->ext_csd.generic_cmd6_time);
+   pr_debug("%s: %s switch to HS got CRC error\n",
+mmc_hostname(host), __func__);
+   } else {
+   goto out_err;
+   }
+   }
 
mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
 
-- 
1.8.1.1.dirty

[PATCH v2] Fix HS setting in mmc_hs400_to_hs200()

[Chaotian Jing]

Change vs v1:
  do not retry CMD6 in __mmc_switch()
  do not move the reduce clock operation after switch HS

Chaotian Jing (2):
  mmc: core: do not retry CMD6 in __mmc_switch()
  mmc: mmc: Fix HS setting in mmc_hs400_to_hs200()

 drivers/mmc/core/mmc.c | 21 +++--
 drivers/mmc/core/mmc_ops.c |  2 +-
 2 files changed, 20 insertions(+), 3 deletions(-)

-- 
1.8.1.1.dirty

Re: [PATCH v4] panic: Avoid the extra noise dmesg

[Feng Tang]

Hi all,

On Tue, Dec 11, 2018 at 09:32:30AM +0100, Petr Mladek wrote:
> On Mon 2018-12-10 10:49:22, Kees Cook wrote:
> > On Mon, Dec 10, 2018 at 10:17 AM Steven Rostedt  wrote:
> > >
> > > On Fri,  7 Dec 2018 17:51:19 +0800
> > > Feng Tang  wrote:
> > >
> > > > When kernel panic happens, it will first print the panic call stack,
> > > > then the ending msg like:
> > > >
> > > > [   35.743249] ---[ end Kernel panic - not syncing: Fatal exception
> > > > [   35.749975] [ cut here ]
> > > >
> > > > The above message are very useful for debugging.
> > > >
> > > > But if system is configured to not reboot on panic, say the 
> > > > "panic_timeout"
> > > > parameter equals 0, it will likely print out many noisy message like
> > > > WARN() call stack for each and every CPU except the panic one, messages
> > > > like below:
> > >
> > >
> > > > Keeping the interrupt disabled will avoid the noisy message.
> > > >
> > > > When code runs to this point, it means user has chosed to not reboot, or
> > > > do any special handling by using the panic notifier method, the only 
> > > > reason
> > > > to enable the interrupt may be sysrq migic key and panic_blink function
> > > > (though may not work even with irq enabled).
> > > >
> > > > So make the irq disabled by default and add a cmdline parameter
> > > > "panic_keep_irq_on" to turn it on when needed.
> > > >
> > > > Signed-off-by: Feng Tang 
> > > >
> > >
> > > Acked-by: Steven Rostedt (VMware) 
> > 
> > I'm fine with the new boot param, but I think we need to leave it how
> > it was by default: systems that want to see the blinking aren't going
> > to have a screen to read about what boot param they need to add.
> > Currently, we'll blink and spew extra warnings. With this patch we'll
> > not blink and not spew: a headless machine will have no indication
> > that a panic happened.
> 
> Just to be sure, in case, you did not follow the other long
> discussion.
> 
> I had an alternative approach to switch printk() into nop at
> this panic() stage. It can be restored when sysrq is triggered.
> This approach allows to keep blinking and sysrq working. People
> debugging the blinking would need to block this change but it
> should be rare.
> 
> I do not resist on my solution. It looks a bit hacky. But it
> is simple and rather straightforward.
 
Sorry for the late response.

So currently, there are 2 proposals:
1. this v4 patch of "panic_keep_irq_on" flag (default off to be same
   as the current kernel behavior)
2. Petr's suggestion of adding a flag to suppress printk after enterring
   late panic phase (blinking time), while keeping the sysrq printk
   working.

Following is the draft patch based on Petr's suggestion:

Please review, thanks. I'm fine with both solutions.

- Feng

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 1f03078..8921fed 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -528,6 +528,11 @@ void __handle_sysrq(int key, bool check_mask)
struct sysrq_key_op *op_p;
int orig_log_level;
int i;
+   int old_val;
+
+   /* save the old panic printk flag */
+   old_val = panic_suppress_printk;
+   panic_suppress_printk = 1;
 
rcu_sysrq_start();
rcu_read_lock();
@@ -574,6 +579,8 @@ void __handle_sysrq(int key, bool check_mask)
}
rcu_read_unlock();
rcu_sysrq_end();
+
+   panic_suppress_printk = old_val;
 }
 
 void handle_sysrq(int key)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8f0e68e..4120f3a 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -534,6 +534,7 @@ extern int panic_on_io_nmi;
 extern int panic_on_warn;
 extern int sysctl_panic_on_rcu_stall;
 extern int sysctl_panic_on_stackoverflow;
+extern int panic_suppress_printk;
 
 extern bool crash_kexec_post_notifiers;
 
diff --git a/kernel/panic.c b/kernel/panic.c
index f121e6b..0cd3a1b 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -46,6 +46,8 @@ int panic_on_warn __read_mostly;
 int panic_timeout = CONFIG_PANIC_TIMEOUT;
 EXPORT_SYMBOL_GPL(panic_timeout);
 
+int panic_suppress_printk;
+
 #define PANIC_PRINT_TASK_INFO  0x0001
 #define PANIC_PRINT_MEM_INFO   0x0002
 #define PANIC_PRINT_TIMER_INFO 0x0004
@@ -326,6 +328,7 @@ void panic(const char *fmt, ...)
}
 #endif
pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
+   panic_suppress_printk = 1;
local_irq_enable();
for (i = 0; ; i += PANIC_TIMER_STEP) {
touch_softlockup_watchdog();
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index d3d1703..c27bbf5 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1987,6 +1987,9 @@ asmlinkage __visible int printk(const char *fmt, ...)
va_list args;
int r;
 
+   if (unlikely(panic_suppress_printk))
+   return 0;
+
va_start(args, fmt);
r = vprintk_func(fmt, args);

Re: [PATCH 0/4] crypto: caam - add ecb mode support

[Eric Biggers]

On Fri, Feb 15, 2019 at 01:24:42PM +0800, Herbert Xu wrote:
> On Wed, Feb 13, 2019 at 10:51:36AM -0800, Eric Biggers wrote:
> >
> > You are claiming you need DES-ECB, 3DES-ECB, *and* ARC4 for that?
> > 
> > Which one is it actually, if any?
> 
> Since these are existing algorithms in the crypto API and we're
> simply adding them to the driver I think the bar of acceptance
> is lower than if it were a completely new addition to the kernel.
> 
> Thanks,
> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Sure, but the bar shouldn't be so low that new implementations of insecure
algorithms the world is moving away from are accepted without a real use case.
We should be moving towards removing these algorithms instead.  The original DES
is especially bad as it only has a 56-bit key.  I'd like to better understand
if/why people claim to not only still need these algorithms in 2019, but also
need brand new implementations of them.

- Eric

Re: [PATCH] usb: dwc2: hcd: call dwc2_is_controller_alive under spinlock

[Jaehoon Chung]

Hi Minas,

On 2/14/19 8:43 PM, Minas Harutyunyan wrote:
> Hi Jaehoon Chung,
> 
> On 2/14/2019 2:04 PM, Jaehoon Chung wrote:
>> This patch is referred to Robert's patch
>> commit cf54772b913b ("usb: dwc2: call dwc2_is_controller_alive() under 
>> spinlock")
>>
>> During running sdb with otg mode, the usb is hung sometime.
>>
>> The one of SDB hang issues should be fixed with this patch.
>> After hang, it doesn't never trigger the usb interrupt.
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>>   drivers/usb/dwc2/hcd_intr.c | 7 ---
>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
>> index 88b5dcf..8d3b155 100644
>> --- a/drivers/usb/dwc2/hcd_intr.c
>> +++ b/drivers/usb/dwc2/hcd_intr.c
>> @@ -,13 +,13 @@ irqreturn_t dwc2_handle_hcd_intr(struct dwc2_hsotg 
>> *hsotg)
>>  u32 gintsts, dbg_gintsts;
>>  irqreturn_t retval = IRQ_NONE;
>>   
>> +spin_lock(>lock);
>> +
>>  if (!dwc2_is_controller_alive(hsotg)) {
>>  dev_warn(hsotg->dev, "Controller is dead\n");
>> -return retval;
>> +goto out;
>>  }
>>   
>> -spin_lock(>lock);
>> -
>>  /* Check if HOST Mode */
>>  if (dwc2_is_host_mode(hsotg)) {
>>  gintsts = dwc2_read_core_intr(hsotg);
>> @@ -2276,6 +2276,7 @@ irqreturn_t dwc2_handle_hcd_intr(struct dwc2_hsotg 
>> *hsotg)
>>  }
>>  }
>>   
>> +out:
>>  spin_unlock(>lock);
>>   
>>  return retval;
>>
> 
> 1. Checking core alive or not was introduced in our internal reference 
> driver for our setups, because sometime AHB-PCI bridge can hung, not 
> core itself. If it happen then only way to overcome it - reboot core 
> setup and PC.
> 2. Actually this issue was fixed on our setups and currently no need to 
> check access via bridge to core.
> 3. Any case if it still happen on some platforms then first need to 
> check and fix HW

I didn't check with latest kernel. we're using v4.4.172.
This issue is occurred on only ARTIK boards.
- During running test about 10~15 hours, suddenly hang.
- It's impossible to fix HW side.

After applied this patch, passed the test case as 100%. (Before applied, it 
didn't pass the test.)

> 
> On asserted any interrupt for dwc2, handlers call sequence is follow: 
> common->gadget->host handlers. If core alive checked in common handler 
> then checking same stuff in host handler again not needed at all.

Right, it's the duplicated checking according to sequence.

> 
> So, core alive checking in host handler create issue for your test, I 
> suggest to not fix alive checking in host interrupt handler as you 
> suggested and done in common handler, but just remove it.

Will remove it.

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Minas
> 
> 
> 
> 
> 

Re: [PATCH v2 05/11] mfd: pm8xxx: disassociate old virq if hwirq mapping already exists

[Stephen Boyd]

Quoting Brian Masney (2019-02-07 18:16:25)
> Check to see if the hwirq is already associated with another virq on
> this IRQ domain. If so, then disassociate it before associating the
> hwirq with the new virq.
> 
> This is a temporary hack that is needed in order to not break git
> bisect for existing boards. The next patch in this series converts
> ssbi-gpio to be a hierarchical IRQ chip, then there are several patches
> to update all of the device tree files, and finally this patch will be
> reverted within the same patch series.
> 
> IRQs for ssbi-gpio are all initially setup without an IRQ hierarchy
> this driver is probed due to the interrupts property in device tree.
> Once ssbi-gpio is converted to be a hierarchical IRQ chip in the next
> patch, existing users of gpio[d]_to_irq() will call pmic_gpio_to_irq(),
> and that will use the new IRQ chip code in ssbi-gpio that sets up the
> IRQ in an IRQ hierarchy. The hwirq is now associated with two Linux
> virqs and interrupts will not work as expected. This patch corrects
> that issue.
> 
> This change was tested on an APQ8060 DragonBoard.
> 
> Signed-off-by: Brian Masney 
> Tested-by: Linus Walleij 
> ---
> Changes since v1:
> - None
> 
>  drivers/mfd/qcom-pm8xxx.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 8eb2528793f9..2f99a98ccee5 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> @@ -380,6 +380,12 @@ static void pm8xxx_irq_domain_map(struct pm_irq_chip 
> *chip,
>   struct irq_domain *domain, unsigned int irq,
>   irq_hw_number_t hwirq, unsigned int type)
>  {
> +   unsigned int old_virq;
> +
> +   old_virq = irq_find_mapping(domain, hwirq);
> +   if (old_virq)
> +   irq_domain_disassociate(domain, old_virq);

Is it possible to pass 'true' for the 'realloc' argument to
__irq_domain_alloc_irqs() and then this disassociate change isn't
needed?

> +
> irq_domain_set_info(domain, irq, hwirq, chip->pm_irq_data->irq_chip,
> chip, handle_level_irq, NULL, NULL);
> irq_set_noprobe(irq);

[PATCH v2 0/2] Add Reset controller support for HI3670 SoC

[Manivannan Sadhasivam]

Hello,

This patchset adds Reset controller support for HiSilicon HI3670 SoC.
HI3670 SoC is architecturally same as HI3660 SoC, hence the same driver
is reused.

This patchset has been tested on HiKey970 board.

Thanks,
Mani

Changes in v2:

* Used the DT compatible fallback approach instead of adding a new one
  for HI3670

Manivannan Sadhasivam (2):
  dt-bindings: reset: Add HI3670 reset controller binding
  arm64: dts: hisilicon: hi3670: Add reset controller support

 .../devicetree/bindings/reset/hisilicon,hi3660-reset.txt   | 7 ---
 arch/arm64/boot/dts/hisilicon/hi3670.dtsi  | 6 ++
 2 files changed, 10 insertions(+), 3 deletions(-)

-- 
2.17.1

[PATCH v2 1/2] dt-bindings: reset: Add HI3670 reset controller binding

[Manivannan Sadhasivam]

HI3670 SoC is architecturally same as the HI3660 SoC. Hence, the same
driver is reused for HI3670 SoC and the binding is documented here which
uses the fallback approach.

Signed-off-by: Manivannan Sadhasivam 
---
 .../devicetree/bindings/reset/hisilicon,hi3660-reset.txt   | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt 
b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
index 2bf3344b2a02..2df4bddeb688 100644
--- a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
@@ -5,11 +5,12 @@ Please also refer to reset.txt in this directory for common 
reset
 controller binding usage.
 
 The reset controller registers are part of the system-ctl block on
-hi3660 SoC.
+hi3660 and hi3670 SoCs.
 
 Required properties:
-- compatible: should be
-"hisilicon,hi3660-reset"
+- compatible: should be one of the following:
+"hisilicon,hi3660-reset" for HI3660
+"hisilicon,hi3670-reset", "hisilicon,hi3660-reset" for HI3670
 - hisi,rst-syscon: phandle of the reset's syscon.
 - #reset-cells : Specifies the number of cells needed to encode a
   reset source.  The type shall be a  and the value shall be 2.
-- 
2.17.1

[PATCH v2 2/2] arm64: dts: hisilicon: hi3670: Add reset controller support

[Manivannan Sadhasivam]

Add reset controller support for HiSilicon HI3670 SoC.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
index a5bd6d80b226..2af88c429c97 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
@@ -151,6 +151,12 @@
#clock-cells = <1>;
};
 
+   crg_rst: crg_rst_controller {
+   compatible = "hisilicon,hi3670-reset", 
"hisilicon,hi3660-reset";
+   #reset-cells = <2>;
+   hisi,rst-syscon = <_ctrl>;
+   };
+
pctrl: pctrl@e8a09000 {
compatible = "hisilicon,hi3670-pctrl", "syscon";
reg = <0x0 0xe8a09000 0x0 0x1000>;
-- 
2.17.1

Re: [PATCH] efi/libstub: refactor cmd_stubcopy

[Masahiro Yamada]

On Tue, Feb 12, 2019 at 4:26 PM Ard Biesheuvel
 wrote:
>
> On Tue, 12 Feb 2019 at 04:45, Masahiro Yamada
>  wrote:
> >
> > It took me a while to understand what is going on in the nested
> > if-blocks.
> >
> > Simplify it by removing unneeded code.
> >
> >   - if_changed automatically adds 'set -e', so any failure in the
> > series of commands makes it immediately fail as a whole.
> > So, the outer if block is entirely redundant.
> >
> >   - Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
> > target"), GNU Make automatically deletes the target on any failure
> > in its recipe. The explicit 'rm -f $@' is redundant.
> >
> >   - surrounding commands with ( ) will spawn a subshell to execute them
> > in it, but it is rarely useful to do so.
> >
> > Signed-off-by: Masahiro Yamada 
>
> Assuming that it still works as expected:
>
> Acked-by: Ard Biesheuvel 
>
> You can test this by adding a statically initialized global function
> pointer to any of the libstub source files that get built for ARM.
>
> Thanks!


I tried that, and it failed as expected.


$ git diff
diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
b/drivers/firmware/efi/libstub/arm32-stub.c
index becbda4..5ad7bbd 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -28,6 +28,8 @@ efi_status_t
check_platform_features(efi_system_table_t *sys_table_arg)
return EFI_SUCCESS;
 }

+void * foo = (void *)check_platform_features;
+
 static efi_guid_t screen_info_guid = LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID;

 struct screen_info *alloc_screen_info(efi_system_table_t *sys_table_arg)
$ make ARCH=arm  CROSS_COMPILE=arm-linux-gnueabihf- defconfig
drivers/firmware/efi/libstub/
*** Default configuration is based on 'multi_v7_defconfig'
#
# configuration written to .config
#
scripts/kconfig/conf  --syncconfig Kconfig
  CALLscripts/checksyscalls.sh
  CC  drivers/firmware/efi/libstub/arm32-stub.o
  STUBCPY drivers/firmware/efi/libstub/arm32-stub.stub.o
 R_ARM_ABS32   check_platform_features
drivers/firmware/efi/libstub/arm32-stub.stub.o: absolute symbol
references not allowed in the EFI stub
drivers/firmware/efi/libstub/Makefile:80: recipe for target
'drivers/firmware/efi/libstub/arm32-stub.stub.o' failed
make[3]: *** [drivers/firmware/efi/libstub/arm32-stub.stub.o] Error 1
make[3]: *** Deleting file 'drivers/firmware/efi/libstub/arm32-stub.stub.o'
Makefile:1705: recipe for target 'drivers/firmware/efi/libstub/' failed
make[2]: *** [drivers/firmware/efi/libstub/] Error 2
/home/masahiro/workspace/bsp/linux/Makefile:300: recipe for target
'__build_one_by_one' failed
make[1]: *** [__build_one_by_one] Error 2
Makefile:160: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2





-- 
Best Regards
Masahiro Yamada

Re: general protection fault in prepare_to_wait

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:23e93c9b2cde Revert "gfs2: read journal in large chunks to..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14e94014c0
kernel config:  https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
dashboard link: https://syzkaller.appspot.com/bug?extid=55f9d3e51d49e20b2ce5
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=109c886cc0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11ed20d0c0

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

IPv6: ADDRCONF(NETDEV_CHANGE): veth0_to_hsr: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_0: link becomes ready
kasan: CONFIG_KASAN_INLINE enabled
8021q: adding VLAN 0 to HW filter on device batadv0
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: 7785 Comm: syz-executor295 Not tainted 5.0.0-rc6+ #72
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:__lock_acquire+0x8df/0x4700 kernel/locking/lockdep.c:3215
Code: 28 00 00 00 0f 85 35 27 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f  
5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f  
85 dc 27 00 00 49 81 3c 24 20 25 9a 89 0f 84 03 f8

RSP: 0018:888094c6f970 EFLAGS: 00010006
kobject: 'vlan0' (d30c60ff): kobject_add_internal: parent: 'mesh',  
set: ''

RAX: dc00 RBX:  RCX: 
RDX: 0003 RSI:  RDI: 0018
RBP: 888094c6fb40 R08: 0001 R09: 0001
R10:  R11: 0001 R12: 0018
R13: 0001 R14:  R15: 88808c0f00c0
FS:  7f9abeeec700() GS:8880ae80() knlGS:
8021q: adding VLAN 0 to HW filter on device batadv0
CS:  0010 DS:  ES:  CR0: 80050033
kobject: 'vlan0' (a54e32cc): kobject_add_internal: parent: 'mesh',  
set: ''

CR2: 004d0910 CR3: 906d2000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
8021q: adding VLAN 0 to HW filter on device batadv0
Call Trace:
kobject: 'vlan0' (16be0e34): kobject_add_internal: parent: 'mesh',  
set: ''

 lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152
 prepare_to_wait+0x7c/0x300 kernel/sched/wait.c:230
 nr_accept+0x239/0x790 net/netrom/af_netrom.c:796
 __sys_accept4+0x350/0x6a0 net/socket.c:1588
 __do_sys_accept net/socket.c:1629 [inline]
 __se_sys_accept net/socket.c:1626 [inline]
 __x64_sys_accept+0x75/0xb0 net/socket.c:1626
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x449489
Code: e8 7c e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 1b 05 fc ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7f9abeeebcc8 EFLAGS: 0246 ORIG_RAX: 002b
RAX: ffda RBX: 006dfc68 RCX: 00449489
RDX:  RSI:  RDI: 0004
RBP: 006dfc60 R08: 7f9abeeec700 R09: 
R10: 7f9abeeec700 R11: 0246 R12: 006dfc6c
R13: 7ffe8979730f R14: 7f9abeeec9c0 R15: 0002
Modules linked in:
---[ end trace 91ccd60fc619e2e6 ]---
RIP: 0010:__lock_acquire+0x8df/0x4700 kernel/locking/lockdep.c:3215
Code: 28 00 00 00 0f 85 35 27 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f  
5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f  
85 dc 27 00 00 49 81 3c 24 20 25 9a 89 0f 84 03 f8

RSP: 0018:888094c6f970 EFLAGS: 00010006
RAX: dc00 RBX:  RCX: 
RDX: 0003 RSI:  RDI: 0018
RBP: 888094c6fb40 R08: 0001 R09: 0001
R10:  R11: 0001 R12: 0018
R13: 0001 R14:  R15: 88808c0f00c0
FS:  7f9abeeec700() GS:8880ae80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004d0910 CR3: 906d2000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400

Re: [PATCH] random: Make /dev/random wait for crng_ready

[Bernd Edlinger]

On 2/15/19 2:47 AM, Bernd Edlinger wrote:
>   while (1) {
> - n = extract_entropy_user(_pool, buf, nbytes);
> + n = crng_ready()
> + ?  extract_entropy_user(_pool, buf, nbytes)
> + : 0;

Aehm, the whitespace after ? does not align with :, didn't see that before.

I wonder if it would be better style to use
 if (crng_ready())
  n = extract...;
 else
  n = 0;


Bernd.

Re: kernel BUG at drivers/android/binder_alloc.c:LINE! (2)

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:b3418f8bddf4 Add linux-next specific files for 20190214
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12ccad60c0
kernel config:  https://syzkaller.appspot.com/x/.config?x=8a3a37525a677c71
dashboard link: https://syzkaller.appspot.com/bug?extid=55de1eb4975dec156d8f
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=16f6304740
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12a2ed58c0

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

[ cut here ]
kernel BUG at drivers/android/binder_alloc.c:1141!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: 7540 Comm: syz-executor013 Not tainted 5.0.0-rc6-next-20190214  
#35
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:binder_alloc_do_buffer_copy+0xd6/0x510  
drivers/android/binder_alloc.c:1141
Code: 02 00 0f 85 20 04 00 00 4d 8b 64 24 58 49 29 dc e8 9f e1 26 fc 4c 89  
e6 4c 89 ef e8 b4 e2 26 fc 4d 39 e5 76 07 e8 8a e1 26 fc <0f> 0b e8 83 e1  
26 fc 4c 8b 75 d0 4d 29 ec 4c 89 e6 4c 89 f7 e8 91

RSP: 0018:88804a6cf558 EFLAGS: 00010293
RAX: 888033dc61c0 RBX: 20001000 RCX: 8549806c
RDX:  RSI: 85498076 RDI: 0006
RBP: 88804a6cf5d8 R08: 888033dc61c0 R09: 0028
R10: ed10094d9f01 R11: 88804a6cf80f R12: 0008
R13: 0028 R14: 888069c1c210 R15: 
FS:  017d9940() GS:8880ae80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 7b49a000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 binder_alloc_copy_from_buffer+0x37/0x42 drivers/android/binder_alloc.c:1187
 binder_get_object+0xa2/0x1e0 drivers/android/binder.c:2062
 binder_transaction+0x2b4a/0x6690 drivers/android/binder.c:3231
 binder_thread_write+0x64a/0x2820 drivers/android/binder.c:3792
 binder_ioctl_write_read drivers/android/binder.c:4825 [inline]
 binder_ioctl+0x1033/0x183b drivers/android/binder.c:5002
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:509 [inline]
 do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696
 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
 __do_sys_ioctl fs/ioctl.c:720 [inline]
 __se_sys_ioctl fs/ioctl.c:718 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x444579
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 d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7fff3621c708 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7fff3621c710 RCX: 00444579
RDX: 2440 RSI: c0306201 RDI: 0003
RBP:  R08:  R09: 00401000
R10:  R11: 0246 R12: 00402280
R13: 00402310 R14:  R15: 
Modules linked in:
---[ end trace e53003f51f970669 ]---
RIP: 0010:binder_alloc_do_buffer_copy+0xd6/0x510  
drivers/android/binder_alloc.c:1141
Code: 02 00 0f 85 20 04 00 00 4d 8b 64 24 58 49 29 dc e8 9f e1 26 fc 4c 89  
e6 4c 89 ef e8 b4 e2 26 fc 4d 39 e5 76 07 e8 8a e1 26 fc <0f> 0b e8 83 e1  
26 fc 4c 8b 75 d0 4d 29 ec 4c 89 e6 4c 89 f7 e8 91

RSP: 0018:88804a6cf558 EFLAGS: 00010293
RAX: 888033dc61c0 RBX: 20001000 RCX: 8549806c
RDX:  RSI: 85498076 RDI: 0006
RBP: 88804a6cf5d8 R08: 888033dc61c0 R09: 0028
R10: ed10094d9f01 R11: 88804a6cf80f R12: 0008
R13: 0028 R14: 888069c1c210 R15: 
FS:  017d9940() GS:8880ae80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 7b49a000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400

Re: [PATCH 0/4] crypto: caam - add ecb mode support

[Herbert Xu]

On Wed, Feb 13, 2019 at 10:51:36AM -0800, Eric Biggers wrote:
>
> You are claiming you need DES-ECB, 3DES-ECB, *and* ARC4 for that?
> 
> Which one is it actually, if any?

Since these are existing algorithms in the crypto API and we're
simply adding them to the driver I think the bar of acceptance
is lower than if it were a completely new addition to the kernel.

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

Re: [PATCH 0/4] crypto: caam - add ecb mode support

[Herbert Xu]

On Fri, Feb 08, 2019 at 03:50:06PM +0200, Iuliana Prodan wrote:
> This patch set adds ecb mode support for aes, des, 3des and arc4 ciphers.
> skcipher implementation is reused, making sure to handle the no IV case.
> 
> While here:
> -fix a DMA API issue where initial src/dst_nents are used instead of nents
> returned by dma_map_sg()
> -export arc4 defines in a common header
> -update cbc des and 3des to check for weak keys 
> 
> Iuliana Prodan (4):
>   crypto: caam - use mapped_{src,dst}_nents for job descriptor
>   crypto: export arc4 defines
>   crypto: caam - add ecb(*) support
>   crypto: caam - weak key checking for cbc des, 3des
> 
>  crypto/arc4.c  |   5 +-
>  drivers/crypto/bcm/cipher.h|   4 +-
>  drivers/crypto/caam/Kconfig|   1 +
>  drivers/crypto/caam/caamalg.c  | 215 
> -
>  drivers/crypto/caam/caamalg_desc.c |  18 ++--
>  drivers/crypto/caam/compat.h   |   1 +
>  include/crypto/arc4.h  |  13 +++
>  7 files changed, 195 insertions(+), 62 deletions(-)
>  create mode 100644 include/crypto/arc4.h

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

Re: KASAN: use-after-free Read in lock_sock_nested

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:b3418f8bddf4 Add linux-next specific files for 20190214
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14f6304740
kernel config:  https://syzkaller.appspot.com/x/.config?x=8a3a37525a677c71
dashboard link: https://syzkaller.appspot.com/bug?extid=500c69d1e21d970e461b
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=14b08da740

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

==
BUG: KASAN: use-after-free in __lock_acquire+0x3150/0x4710  
kernel/locking/lockdep.c:3200

Read of size 8 at addr 8880195faa60 by task syz-executor.4/7495

CPU: 1 PID: 7495 Comm: syz-executor.4 Not tainted 5.0.0-rc6-next-20190214  
#35
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
 __lock_acquire+0x3150/0x4710 kernel/locking/lockdep.c:3200
 lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3833
 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
 _raw_spin_lock_bh+0x33/0x50 kernel/locking/spinlock.c:168
 spin_lock_bh include/linux/spinlock.h:334 [inline]
 lock_sock_nested+0x41/0x120 net/core/sock.c:2878
 lock_sock include/net/sock.h:1507 [inline]
 nr_accept+0x200/0x790 net/netrom/af_netrom.c:808
 __sys_accept4+0x350/0x6a0 net/socket.c:1610
 __do_sys_accept net/socket.c:1651 [inline]
 __se_sys_accept net/socket.c:1648 [inline]
 __x64_sys_accept+0x75/0xb0 net/socket.c:1648
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e29
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7f16cb51ec78 EFLAGS: 0246 ORIG_RAX: 002b
RAX: ffda RBX: 0003 RCX: 00457e29
RDX:  RSI:  RDI: 0004
RBP: 0073bfa0 R08:  R09: 
R10:  R11: 0246 R12: 7f16cb51f6d4
R13: 004bdbf0 R14: 004cde80 R15: 

Allocated by task 7492:
 save_stack+0x45/0xd0 mm/kasan/common.c:75
 set_track mm/kasan/common.c:87 [inline]
 __kasan_kmalloc mm/kasan/common.c:497 [inline]
 __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:511
 __do_kmalloc mm/slab.c:3721 [inline]
 __kmalloc+0x15c/0x740 mm/slab.c:3730
 kmalloc include/linux/slab.h:553 [inline]
 sk_prot_alloc+0x19c/0x2e0 net/core/sock.c:1573
 sk_alloc+0x39/0xf70 net/core/sock.c:1627
 nr_create+0xb9/0x5e0 net/netrom/af_netrom.c:436
 __sock_create+0x3e6/0x750 net/socket.c:1297
 sock_create net/socket.c:1337 [inline]
 __sys_socket+0x103/0x220 net/socket.c:1367
 __do_sys_socket net/socket.c:1376 [inline]
 __se_sys_socket net/socket.c:1374 [inline]
 __x64_sys_socket+0x73/0xb0 net/socket.c:1374
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 7491:
 save_stack+0x45/0xd0 mm/kasan/common.c:75
 set_track mm/kasan/common.c:87 [inline]
 __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459
 kasan_slab_free+0xe/0x10 mm/kasan/common.c:467
 __cache_free mm/slab.c:3491 [inline]
 kfree+0xcf/0x230 mm/slab.c:3816
 sk_prot_free net/core/sock.c:1610 [inline]
 __sk_destruct+0x4f1/0x6d0 net/core/sock.c:1692
 sk_destruct+0x7b/0x90 net/core/sock.c:1700
 __sk_free+0xce/0x300 net/core/sock.c:1711
 sk_free+0x42/0x50 net/core/sock.c:1722
 sock_put include/net/sock.h:1708 [inline]
 nr_release+0x337/0x3c0 net/netrom/af_netrom.c:557
 __sock_release+0xd3/0x250 net/socket.c:579
 sock_close+0x1b/0x30 net/socket.c:1161
 __fput+0x2e5/0x8d0 fs/file_table.c:278
 fput+0x16/0x20 fs/file_table.c:309
 task_work_run+0x14a/0x1c0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166
 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
 do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at 8880195fa9c0
 which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 160 bytes inside of
 2048-byte region [8880195fa9c0, 8880195fb1c0)
The buggy address belongs to the page:
page:ea

Re: [PATCH v7 1/2] signal: add pidfd_send_signal() syscall

[Tycho Andersen]

On Wed, Jan 02, 2019 at 05:16:53PM +0100, Christian Brauner wrote:
> The kill() syscall operates on process identifiers (pid). After a process
> ...

Fashionably late to the party, but feel free to consider these two:

Reviewed-by: Tycho Andersen 

Re: [PATCH v5 5/5] arm64/kvm: control accessibility of ptrauth key registers

[Amit Daniel Kachhap]

Hi,

On 2/13/19 11:24 PM, Dave P Martin wrote:

On Wed, Feb 13, 2019 at 05:35:46PM +, Kristina Martsenko wrote:

On 28/01/2019 06:58, Amit Daniel Kachhap wrote:

According to userspace settings, ptrauth key registers are conditionally
present in guest system register list based on user specified flag
KVM_ARM_VCPU_PTRAUTH.

Signed-off-by: Amit Daniel Kachhap 
Cc: Mark Rutland 
Cc: Christoffer Dall 
Cc: Marc Zyngier 
Cc: Kristina Martsenko 
Cc: kvm...@lists.cs.columbia.edu
Cc: Ramana Radhakrishnan 
Cc: Will Deacon 
---
  Documentation/arm64/pointer-authentication.txt |  3 ++
  arch/arm64/kvm/sys_regs.c  | 42 +++---
  2 files changed, 34 insertions(+), 11 deletions(-)



[...]


diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c


[...]


@@ -2487,18 +2493,22 @@ static int walk_one_sys_reg(const struct sys_reg_desc 
*rd,
  }
  
  /* Assumed ordered tables, see kvm_sys_reg_table_init. */

-static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind)
+static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind,
+   const struct sys_reg_desc *desc, unsigned int len)
  {
const struct sys_reg_desc *i1, *i2, *end1, *end2;
unsigned int total = 0;
size_t num;
int err;
  
+	if (desc == ptrauth_reg_descs && !kvm_arm_vcpu_ptrauth_allowed(vcpu))

+   return total;
+
/* We check for duplicates here, to allow arch-specific overrides. */
i1 = get_target_table(vcpu->arch.target, true, );
end1 = i1 + num;
-   i2 = sys_reg_descs;
-   end2 = sys_reg_descs + ARRAY_SIZE(sys_reg_descs);
+   i2 = desc;
+   end2 = desc + len;
  
  	BUG_ON(i1 == end1 || i2 == end2);
  
@@ -2526,7 +2536,10 @@ unsigned long kvm_arm_num_sys_reg_descs(struct kvm_vcpu *vcpu)

  {
return ARRAY_SIZE(invariant_sys_regs)
+ num_demux_regs()
-   + walk_sys_regs(vcpu, (u64 __user *)NULL);
+   + walk_sys_regs(vcpu, (u64 __user *)NULL, sys_reg_descs,
+   ARRAY_SIZE(sys_reg_descs))
+   + walk_sys_regs(vcpu, (u64 __user *)NULL, ptrauth_reg_descs,
+   ARRAY_SIZE(ptrauth_reg_descs));
  }
  
  int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)

@@ -2541,7 +2554,12 @@ int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, 
u64 __user *uindices)
uindices++;
}
  
-	err = walk_sys_regs(vcpu, uindices);

+   err = walk_sys_regs(vcpu, uindices, sys_reg_descs, 
ARRAY_SIZE(sys_reg_descs));
+   if (err < 0)
+   return err;
+   uindices += err;
+
+   err = walk_sys_regs(vcpu, uindices, ptrauth_reg_descs, 
ARRAY_SIZE(ptrauth_reg_descs));
if (err < 0)
return err;
uindices += err;
@@ -2575,6 +2593,7 @@ void kvm_sys_reg_table_init(void)
BUG_ON(check_sysreg_table(cp15_regs, ARRAY_SIZE(cp15_regs)));
BUG_ON(check_sysreg_table(cp15_64_regs, ARRAY_SIZE(cp15_64_regs)));
BUG_ON(check_sysreg_table(invariant_sys_regs, 
ARRAY_SIZE(invariant_sys_regs)));
+   BUG_ON(check_sysreg_table(ptrauth_reg_descs, 
ARRAY_SIZE(ptrauth_reg_descs)));
  
  	/* We abuse the reset function to overwrite the table itself. */

for (i = 0; i < ARRAY_SIZE(invariant_sys_regs); i++)
@@ -2616,6 +2635,7 @@ void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
  
  	/* Generic chip reset first (so target could override). */

reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
+   reset_sys_reg_descs(vcpu, ptrauth_reg_descs, 
ARRAY_SIZE(ptrauth_reg_descs));
  
  	table = get_target_table(vcpu->arch.target, true, );

reset_sys_reg_descs(vcpu, table, num);


This isn't very scalable, since we'd need to duplicate all the above
code every time we add new system registers that are conditionally
accessible.


Agreed, putting feature-specific checks in walk_sys_regs() is probably
best avoided.  Over time we would likely accumulate a fair number of
these checks.


It seems that the SVE patches [1] solved this problem by adding a
check_present() callback into struct sys_reg_desc. It probably makes
sense to rebase onto that patch and just implement the callback for the
ptrauth key registers as well.

[1] 
https://lore.kernel.org/linux-arm-kernel/1547757219-19439-13-git-send-email-dave.mar...@arm.com/


Note, I'm currently refactoring this so that enumeration through
KVM_GET_REG_LIST can be disabled independently of access to the
register.  This may not be the best approach, but for SVE I have a
feature-specific ID register to handle too (ID_AA64ZFR0_EL1), which
needs to be hidden from the enumeration but still accessible with
read-as-zero behaviour.

This changes the API a bit: I move to a .restrictions() callback which
returns flags to say what is disabled, and this callback is used in the
common code so that you don't have repeat your "feature present" check
in every 

[PATCH v2] arm64: dts: rockchip: Add on-board WiFi/BT support for Rock960 boards

[Manivannan Sadhasivam]

Add on-board WiFi/BT support for Rock960 boards such as Rock960 based
on AP6356S and Ficus based on AP6354 wireless modules.

Firmwares for the respective boards are available here:

http://people.linaro.org/~manivannan.sadhasivam/rock960_wifi/
http://people.linaro.org/~manivannan.sadhasivam/ficus_wifi/

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v2:

* Added address and size cells property to sdio0 node

 .../boot/dts/rockchip/rk3399-rock960.dtsi | 98 ++-
 1 file changed, 97 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
index 56abbb08c133..d33cd441dee9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
@@ -9,6 +9,15 @@
 #include "rk3399-opp.dtsi"
 
 / {
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   clocks = < 1>;
+   clock-names = "ext_clock";
+   pinctrl-names = "default";
+   pinctrl-0 = <_enable_h>;
+   reset-gpios = < RK_PB2 GPIO_ACTIVE_LOW>;
+   };
+
vcc1v8_s0: vcc1v8-s0 {
compatible = "regulator-fixed";
regulator-name = "vcc1v8_s0";
@@ -362,6 +371,20 @@
 };
 
  {
+   bt {
+   bt_enable_h: bt-enable-h {
+   rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO _pull_none>;
+   };
+
+   bt_host_wake_l: bt-host-wake-l {
+   rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO _pull_none>;
+   };
+
+   bt_wake_l: bt-wake-l {
+   rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO _pull_none>;
+   };
+   };
+
sdmmc {
sdmmc_bus1: sdmmc-bus1 {
rockchip,pins =
@@ -387,6 +410,26 @@
};
};
 
+   sdio0 {
+   sdio0_bus4: sdio0-bus4 {
+   rockchip,pins =
+   <2 20 RK_FUNC_1 _pull_up_20ma>,
+   <2 21 RK_FUNC_1 _pull_up_20ma>,
+   <2 22 RK_FUNC_1 _pull_up_20ma>,
+   <2 23 RK_FUNC_1 _pull_up_20ma>;
+   };
+
+   sdio0_cmd: sdio0-cmd {
+   rockchip,pins =
+   <2 24 RK_FUNC_1 _pull_up_20ma>;
+   };
+
+   sdio0_clk: sdio0-clk {
+   rockchip,pins =
+   <2 25 RK_FUNC_1 _pull_none_20ma>;
+   };
+   };
+
pmic {
pmic_int_l: pmic-int-l {
rockchip,pins =
@@ -403,6 +446,19 @@
<1 14 RK_FUNC_GPIO _pull_down>;
};
};
+
+   sdio-pwrseq {
+   wifi_enable_h: wifi-enable-h {
+   rockchip,pins =
+   <0 RK_PB2 RK_FUNC_GPIO _pull_none>;
+   };
+   };
+
+   wifi {
+   wifi_host_wake_l: wifi-host-wake-l {
+   rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO _pull_none>;
+   };
+   };
 };
 
  {
@@ -413,6 +469,35 @@
status = "okay";
 };
 
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clock-frequency = <5000>;
+   bus-width = <4>;
+   cap-sdio-irq;
+   cap-sd-highspeed;
+   no-emmc;
+   keep-power-in-suspend;
+   mmc-pwrseq = <_pwrseq>;
+   non-removable;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus4 _cmd _clk>;
+   sd-uhs-sdr104;
+
+   status = "okay";
+
+   brcmf: wifi@1 {
+   compatible = "brcm,bcm4329-fmac";
+   reg = <1>;
+   interrupt-parent = <>;
+   interrupts = ;
+   interrupt-names = "host-wake";
+   pinctrl-names = "default";
+   pinctrl-0 = <_host_wake_l>;
+   };
+};
+
  {
bus-width = <8>;
mmc-hs400-1_8v;
@@ -439,8 +524,19 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_xfer _cts>;
+   pinctrl-0 = <_xfer _cts _rts>;
status = "okay";
+
+   bluetooth {
+   compatible = "brcm,bcm43438-bt";
+   clocks = < 1>;
+   clock-names = "ext_clock";
+   device-wakeup-gpios = < RK_PD3 GPIO_ACTIVE_HIGH>;
+   host-wakeup-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
+   shutdown-gpios = < RK_PB1 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_host_wake_l _wake_l _enable_h>;
+   };
 };
 
  {
-- 
2.17.1

[PATCH v2 1/2] dt-bindings: gpio: sprd: Use SoC compatible string instead of wildcard string

[Baolin Wang]

Use SoC compatible string instead of wildcard string.

Signed-off-by: Baolin Wang 
---
Changes from v1:
 - Add 'sprd' to indicate the module in subject line.
---
 .../devicetree/bindings/gpio/gpio-eic-sprd.txt |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt 
b/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt
index 93d98d0..54040a2 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt
@@ -33,7 +33,7 @@ Required properties:
   "sprd,sc9860-eic-latch",
   "sprd,sc9860-eic-async",
   "sprd,sc9860-eic-sync",
-  "sprd,sc27xx-eic".
+  "sprd,sc2731-eic".
 - reg: Define the base and range of the I/O address space containing
   the GPIO controller registers.
 - gpio-controller: Marks the device node as a GPIO controller.
@@ -86,7 +86,7 @@ Example:
};
 
pmic_eic: gpio@300 {
-   compatible = "sprd,sc27xx-eic";
+   compatible = "sprd,sc2731-eic";
reg = <0x300>;
interrupt-parent = <_pmic>;
interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
-- 
1.7.9.5

[PATCH v2 2/2] gpio: sprd: Change to use SoC compatible string

[Baolin Wang]

Change to use SoC compatible string instead of wildcard string.

Signed-off-by: Baolin Wang 
---
Changes from v1:
 - None.
---
 drivers/gpio/gpio-pmic-eic-sprd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-pmic-eic-sprd.c 
b/drivers/gpio/gpio-pmic-eic-sprd.c
index ac573da..24228cf 100644
--- a/drivers/gpio/gpio-pmic-eic-sprd.c
+++ b/drivers/gpio/gpio-pmic-eic-sprd.c
@@ -364,7 +364,7 @@ static int sprd_pmic_eic_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id sprd_pmic_eic_of_match[] = {
-   { .compatible = "sprd,sc27xx-eic", },
+   { .compatible = "sprd,sc2731-eic", },
{ /* end of list */ }
 };
 MODULE_DEVICE_TABLE(of, sprd_pmic_eic_of_match);
-- 
1.7.9.5

Re: [PATCH v2] kcm: remove any offset before parsing messages

[Dominique Martinet]

Tom Herbert wrote on Thu, Feb 14, 2019:
> On Thu, Feb 14, 2019 at 7:31 PM Dominique Martinet
>  wrote:
> > Yes, the parser fails with -ENOMEM ; that is not handled gracefully at
> > all: from a user point of view, the connection just hangs (recvmsg never
> > returns), without so much as a message in dmesg either.
>
> That's by design. Here is the description in kcm.txt:
> 
> "When a TCP socket is attached to a KCM multiplexor data ready
> (POLLIN) and write space available (POLLOUT) events are handled by the
> multiplexor. If there is a state change (disconnection) or other error
> on a TCP socket, an error is posted on the TCP socket so that a
> POLLERR event happens and KCM discontinues using the socket. When the
> application gets the error notification for a TCP socket, it should
> unattach the socket from KCM and then handle the error condition (the
> typical response is to close the socket and create a new connection if
> necessary)."

Sigh, that's what I get for relying on pieces of code found on the
internet.

It does make "trivial" kcm sockets difficult to use though, the old
ganesha code I adapted to kcm was the horrible (naive?) kind spawning
one thread per connection and just waiting on read(), so making it just
create a kcm socket from the tcp one and wait on recvmsg() until an
error pops up does not seem an option.

That being said I'm a bit confused, I thought part of the point of kcm
was the multiplexing so a simple server could just keep attaching tcp
sockets to a single kcm socket and only have a single trivial loop
reading from the kcm socket ; but I guess there's no harm in also
looking for POLLERR on the tcp sockets... It would still need to close
them once clients disconnect I guess, this really only affects my naive
server.

> > strparser might be able to retry somehow.
> 
> We could retry on -ENOMEM since it is potentially a transient error,

Yes, I think we should aim to retry on -ENOMEM; I agree all errors are
not meant to be retried on but there already are different cases based
on what the parse cb returned; but that can be a different patch.

> but generally for errors (like connection is simply broken) it seems
> like it's working as intended. I suppose we could add a socket option
> to fail the KCM socket when all attached lower sockets have failed,
> but I not sure that would be a significant benefit for additional
> complexity.

Right, I agree it's probably not worth doing, now I'm aware of this I
can probably motivate myself to change this old code to use epoll
properly.

I think it could make sense to have this option for simpler programs,
but as things stand I guess we can require kcm users to do this much,
thanks for the explanation, and sorry for having failed to notice it.



With all that said I guess my patch should work correctly then, I'll try
to find some time to check the error does come back up the tcp socket in
my reproducer but I have no reason to believe it doesn't.

I'd like to see some retry on ENOMEM before this is merged though, so
while I'm there I'll resend this with a second patch doing that
retry,.. I think just not setting strp->interrupted and not reporting
the error up might be enough? Will have to try either way.



Thanks for the feedback,
-- 
Dominique

Re: [PATCH v5 4/5] arm64/kvm: add a userspace option to enable pointer authentication

[Amit Daniel Kachhap]

Hi,

On 2/13/19 11:05 PM, Kristina Martsenko wrote:

On 28/01/2019 06:58, Amit Daniel Kachhap wrote:

This feature will allow the KVM guest to allow the handling of
pointer authentication instructions or to treat them as undefined
if not set. It uses the existing vcpu API KVM_ARM_VCPU_INIT to
supply this parameter instead of creating a new API.

A new register is not created to pass this parameter via
SET/GET_ONE_REG interface as just a flag (KVM_ARM_VCPU_PTRAUTH)
supplied is enough to enable this feature.


[...]


diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index b200c14..b6950df 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -346,6 +346,10 @@ static inline int kvm_arm_have_ssbd(void)
  static inline void kvm_vcpu_load_sysregs(struct kvm_vcpu *vcpu) {}
  static inline void kvm_vcpu_put_sysregs(struct kvm_vcpu *vcpu) {}
  static inline void kvm_arm_vcpu_ptrauth_reset(struct kvm_vcpu *vcpu) {}
+static inline bool kvm_arm_vcpu_ptrauth_allowed(struct kvm_vcpu *vcpu)
+{
+   return false;
+}


It seems like this is only ever called from arm64 code, so do we need an
arch/arm/ definition?

Yes not required. Nice catch.



+/**
+ * kvm_arm_vcpu_ptrauth_allowed - checks if ptrauth feature is present in vcpu
+ *
+ * @vcpu: The VCPU pointer
+ *
+ * This function will be used to enable/disable ptrauth in guest as configured
+ * by the KVM userspace API.
+ */
+bool kvm_arm_vcpu_ptrauth_allowed(struct kvm_vcpu *vcpu)
+{
+   return test_bit(KVM_ARM_VCPU_PTRAUTH, vcpu->arch.features);
+}


I'm not sure, but should there also be something like

if (test_bit(KVM_ARM_VCPU_PTRAUTH, vcpu->arch.features) &&
 !kvm_supports_ptrauth())
return -EINVAL;

in kvm_reset_vcpu?
Yes makes sense. I missed it and with Dave martin patch this may be done 
cleanly.


Thanks,
Amit D



Thanks,
Kristina

Re: [PATCH v11 2/3] x86,/proc/pid/status: Add AVX-512 usage elapsed time

[Li, Aubrey]

On 2019/2/14 19:29, Thomas Gleixner wrote:
> On Wed, 13 Feb 2019, Aubrey Li wrote:
> 
>> AVX-512 components use could cause core turbo frequency drop. So
>> it's useful to expose AVX-512 usage elapsed time as a heuristic hint
>> for the user space job scheduler to cluster the AVX-512 using tasks
>> together.
>>
>> Example:
>> $ cat /proc/pid/status | grep AVX512_elapsed_ms
>> AVX512_elapsed_ms:  1020
>>
>> The number '1020' denotes 1020 millisecond elapsed since last time
>> context switch the off-CPU task using AVX-512 components, thus the
> 
> I know what you are trying to say, but this sentence does not parse. So
> what you want to say is:
> 
>   This means that 1020 milliseconds have elapsed since the AVX512 usage of
>   the task was detected when the task was scheduled out.

Thanks, will refine this.

> 
> Aside of that 1020ms is hardly evidence for real AVX512 usage, so you want
> to come up with a better example than that.

Oh, I wrote a simple benchmark to loop {AVX ops a while and non-AVX ops a 
while},
So this is expected. Yeah, I should use real AVX512 usage. Below is tensorflow
output to train a neural network model to classify images (HZ = 250 on my side).
Will change to use this example.

$ while [ 1 ]; do cat /proc/83226/status | grep AVX; sleep 1; done
AVX512_elapsed_ms:  4
AVX512_elapsed_ms:  16
AVX512_elapsed_ms:  12
AVX512_elapsed_ms:  12
AVX512_elapsed_ms:  16
AVX512_elapsed_ms:  8
AVX512_elapsed_ms:  8
AVX512_elapsed_ms:  4
AVX512_elapsed_ms:  4
AVX512_elapsed_ms:  12
AVX512_elapsed_ms:  0
AVX512_elapsed_ms:  16
AVX512_elapsed_ms:  4
AVX512_elapsed_ms:  0
AVX512_elapsed_ms:  8
AVX512_elapsed_ms:  8
AVX512_elapsed_ms:  4

> 
> But that makes me think about the usefulness of this hint in general.
> 
> A AVX512 using task which runs alone on a CPU, is going to have either no
> AVX512 usage recorded at all or the time elapsed since the last recording
> is absurdly long.

I did an experiment of this, please correct me if I was wrong.

I isolate CPU103, and run a AVX512 micro benchmark(spin AVX512 ops) on it.

$ cat /proc/cmdline 
root=UUID=e6503b72-57d7-433a-ab09-a4b9a39e9128 ro isolcpus=103

I still saw context switch
aubrey@aubrey-skl:~$ sudo trace-cmd report --cpu 103
cpus=104
avx_demo-6985  [103]  5055.442432: sched_switch: avx_demo:6985 
[120] R ==> migration/103:527 [0]
   migration/103-527   [103]  5055.442434: sched_switch: 
migration/103:527 [0] S ==> avx_demo:6985 [120]
avx_demo-6985  [103]  5059.442430: sched_switch: avx_demo:6985 
[120] R ==> migration/103:527 [0]
   migration/103-527   [103]  5059.442432: sched_switch: 
migration/103:527 [0] S ==> avx_demo:6985 [120]
avx_demo-6985  [103]  5063.442430: sched_switch: avx_demo:6985 
[120] R ==> migration/103:527 [0]
   migration/103-527   [103]  5063.442431: sched_switch: 
migration/103:527 [0] S ==> avx_demo:6985 [120]
avx_demo-6985  [103]  5067.442430: sched_switch: avx_demo:6985 
[120] R ==> migration/103:527 [0]
   migration/103-527   [103]  5067.442431: sched_switch: 
migration/103:527 [0] S ==> avx_demo:6985 [120]

It looks like some kernel threads still participant context switch on the 
isolated
CPU, like above one, each CPU has one migration daemon to do migration jobs.

Under this scenario, the elapsed time becomes longer than normal indeed, see 
below:

$ while [ 1 ]; do cat /proc/6985/status | grep AVX; sleep 1; done
AVX512_elapsed_ms:  3432
AVX512_elapsed_ms:  440
AVX512_elapsed_ms:  1444
AVX512_elapsed_ms:  2448
AVX512_elapsed_ms:  3456
AVX512_elapsed_ms:  460
AVX512_elapsed_ms:  1464
AVX512_elapsed_ms:  2468

But AFAIK, google's Heracles do a 15s polling, so this worst case is still 
acceptable.?

>IOW, this needs crystal ball magic to decode because
> there is no correlation between that elapsed time and the time when the
> last context switch happened simply because that time is not available in
> /proc/$PID/status. Sure you can oracle it out from /proc/$PID/stat with
> even more crystal ball magic, but there is no explanation at all.
> 
> There may be use case scenarios where this crystal ball prediction is
> actually useful, but the inaccuracy of that information and the possible
> pitfalls for any user space application which uses it need to be documented
> in detail. Without that, this is going to cause more trouble and confusion
> than benefit.
> 
Not sure if the above experiment addressed your concern, please correct me if
I totally misunderstood.

Thanks,
-Aubrey

Re: [PATCH v3 0/3] Stingray USB PHY driver support

[Srinath Mannam]

Hi Kishon,

Could you please help to review and provide your comments to this
patch series when you have time?

Regards,
Srinath.

On Wed, Feb 6, 2019 at 11:03 PM Srinath Mannam
 wrote:
>
> These patches add Stingray USB PHY driver and its corresponding
> DT nodes with documentation.
>
> This patch set is based on Linux-5.0-rc2.
>
> Changes from v2:
>   - Addressed Kishon review comments
>   - Updated patchset to Linux-5.0-rc2
>
> Changes from v1:
>   - Addressed Kishon review comments
>   - phy init call return value handle
>
> Srinath Mannam (3):
>   dt-bindings: phy: Add Stingray USB PHY binding document
>   phy: sr-usb: Add Stingray USB PHY driver
>   arm64: dts: Add USB DT nodes for Stingray SoC
>
>  .../bindings/phy/brcm,stingray-usb-phy.txt |  62 
>  .../boot/dts/broadcom/stingray/stingray-usb.dtsi   |  95 ++
>  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |   1 +
>  drivers/phy/broadcom/Kconfig   |  11 +
>  drivers/phy/broadcom/Makefile  |   1 +
>  drivers/phy/broadcom/phy-bcm-sr-usb.c  | 371 
> +
>  6 files changed, 541 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
>  create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
>
> --
> 2.7.4
>

Re: [f2fs-dev] [PATCH] f2fs: do not use mutex lock in atomic context

[Ritesh Harjani]

On 2/14/2019 9:40 PM, Chao Yu wrote:

On 2019-2-14 15:46, Sahitya Tummala wrote:

On Wed, Feb 13, 2019 at 11:25:31AM +0800, Chao Yu wrote:

On 2019/2/4 16:06, Sahitya Tummala wrote:

Fix below warning coming because of using mutex lock in atomic context.

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:98
in_atomic(): 1, irqs_disabled(): 0, pid: 585, name: sh
Preemption disabled at: __radix_tree_preload+0x28/0x130
Call trace:
  dump_backtrace+0x0/0x2b4
  show_stack+0x20/0x28
  dump_stack+0xa8/0xe0
  ___might_sleep+0x144/0x194
  __might_sleep+0x58/0x8c
  mutex_lock+0x2c/0x48
  f2fs_trace_pid+0x88/0x14c
  f2fs_set_node_page_dirty+0xd0/0x184

Do not use f2fs_radix_tree_insert() to avoid doing cond_resched() with
spin_lock() acquired.

Signed-off-by: Sahitya Tummala 
---
  fs/f2fs/trace.c | 20 +---
  1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/fs/f2fs/trace.c b/fs/f2fs/trace.c
index ce2a5eb..d0ab533 100644
--- a/fs/f2fs/trace.c
+++ b/fs/f2fs/trace.c
@@ -14,7 +14,7 @@
  #include "trace.h"
  
  static RADIX_TREE(pids, GFP_ATOMIC);

-static struct mutex pids_lock;
+static spinlock_t pids_lock;
  static struct last_io_info last_io;
  
  static inline void __print_last_io(void)

@@ -58,23 +58,29 @@ void f2fs_trace_pid(struct page *page)
  
  	set_page_private(page, (unsigned long)pid);
  
+retry:

if (radix_tree_preload(GFP_NOFS))
return;
  
-	mutex_lock(_lock);

+   spin_lock(_lock);
p = radix_tree_lookup(, pid);
if (p == current)
goto out;
if (p)
radix_tree_delete(, pid);
  
-	f2fs_radix_tree_insert(, pid, current);


Do you know why do we have a retry logic here? When anyways we have 
called for radix_tree_delete with pid key?

Which should ensure the slot is empty, no?
Then why in the original code (f2fs_radix_tree_insert), we were 
retrying. For what condition a retry was needed?


Regards
Ritesh



+   if (radix_tree_insert(, pid, current)) {
+   spin_unlock(_lock);
+   radix_tree_preload_end();
+   cond_resched();
+   goto retry;
+   }
  
  	trace_printk("%3x:%3x %4x %-16s\n",

MAJOR(inode->i_sb->s_dev), MINOR(inode->i_sb->s_dev),
pid, current->comm);

Hi Sahitya,

Can trace_printk sleep? For safety, how about moving it out of spinlock?


Hi Chao,

Yes, trace_printk() is safe to use in atomic context (unlike printk).

Hi Sahitya,

Thanks for your confirmation. :)

Reviewed-by: Chao Yu 

Thanks,


Thanks,
Sahitya.


Thanks,


  out:
-   mutex_unlock(_lock);
+   spin_unlock(_lock);
radix_tree_preload_end();
  }
  
@@ -119,7 +125,7 @@ void f2fs_trace_ios(struct f2fs_io_info *fio, int flush)
  
  void f2fs_build_trace_ios(void)

  {
-   mutex_init(_lock);
+   spin_lock_init(_lock);
  }
  
  #define PIDVEC_SIZE	128

@@ -147,7 +153,7 @@ void f2fs_destroy_trace_ios(void)
pid_t next_pid = 0;
unsigned int found;
  
-	mutex_lock(_lock);

+   spin_lock(_lock);
while ((found = gang_lookup_pids(pid, next_pid, PIDVEC_SIZE))) {
unsigned idx;
  
@@ -155,5 +161,5 @@ void f2fs_destroy_trace_ios(void)

for (idx = 0; idx < found; idx++)
radix_tree_delete(, pid[idx]);
}
-   mutex_unlock(_lock);
+   spin_unlock(_lock);
  }



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

Re: [PATCH v6 0/3] Stingray thermal driver support

[Srinath Mannam]

Hi Eduardo,

Could you please provide your review comments?

Regards,
Srinath.

On Wed, Feb 6, 2019 at 5:28 AM Eduardo Valentin  wrote:
>
> Hello,
>
> On Mon, Feb 04, 2019 at 04:16:19PM -0800, Ray Jui wrote:
> > Hi Zhang/Eduardo,
> >
> > Can this patch series be merged? It looks like Srinath has addressed all
> > review comments?
>
> I will take a look. Side note, thermal patches are reviewed on
> linux...@vger.kernel.org. Copying that list it does help because that
> is how the patches get assigned in patchwork.kernel.org.
>
> >
> > The following tag should be added to the binding document patch:
> >
> > Reviewed-by: Rob Herring 
> >
> > Thanks,
> >
> > Ray
> >
> > On 1/3/2019 12:55 AM, Srinath Mannam wrote:
> > > These patches adds the stingray thermal driver and its
> > > corresponding DT nodes with documentation.
> > >
> > > Changes from v5
> > >   - Addressed Eduardo Valentin comments.
> > >
> > > Changes from v4
> > >   - Addressed Rob Herring comments on DT parameters and
> > > thermal driver architecture.
> > >   - Removed brcm,max-crit-temp DT parameter
> > >   - Changed driver to thermal sensor registration model.
> > >   - Added trip DT properties.
> > >
> > > Changes from v3
> > >   - Addressed Daniel lezcano comments.
> > >   - Elaborated commit description of thermal driver patch.
> > >   - Added brcm,max-crit-temp DT parameter.
> > >
> > > Changes from v2:
> > >   - All stingray TMON DT nodes are combine together into single.
> > > Temperature registers are combined into one mem resource.
> > > brcm,tmon-mask parameter has available TMONs mask value.
> > >   - All available TMONs are initialized together in single
> > > instance of driver probe call.
> > >
> > > Changes from v1:
> > >   - Fixed auto build sparce warning.
> > >
> > > Pramod Kumar (3):
> > >   dt-bindings: thermal: Add binding document for SR thermal
> > >   thermal: broadcom: Add Stingray thermal driver
> > >   arm64: dts: stingray: Add Stingray Thermal DT support.
> > >
> > >  .../bindings/thermal/brcm,sr-thermal.txt   | 105 
> > > ++
> > >  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |  89 +++
> > >  drivers/thermal/Kconfig|   3 +-
> > >  drivers/thermal/broadcom/Kconfig   |   9 ++
> > >  drivers/thermal/broadcom/Makefile  |   1 +
> > >  drivers/thermal/broadcom/sr-thermal.c  | 122 
> > > +
> > >  6 files changed, 328 insertions(+), 1 deletion(-)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
> > >  create mode 100644 drivers/thermal/broadcom/sr-thermal.c
> > >

Re: [PATCH] pstore: Add boot loader log messages support

[Kees Cook]

On Thu, Feb 14, 2019 at 8:01 PM Yue Hu  wrote:
> Yes, boot loader will did the _write_. When booting from power on, the first 
> phase
> is boot loader, it will log to specific reserver memory. Then kernel/pstore is
> coming up, pstore will copy the log generated by boot loader to xbl zone. The 
> xbl
> memory zone layout like below:
>
> +-+-
> |dest |
> |-|  xbl zone
> |src  |
> +-+-
>
> Anyway, i think it is a useful debug feature.

Ah-ha, interesting. Okay, please mention this (and how the boot loader
knows to write in the area) in v2.

Thanks!

-- 
Kees Cook

[PATCH] h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux-

[Masahiro Yamada]

It believe it is a bad idea to hardcode a specific compiler prefix
that may or may not be installed on a user's system. It is annoying
when testing features that should not require compilers at all.

For example, mrproper, headers_install, etc. should work without
any compiler.

They look like follows on my machine.

$ make ARCH=h8300 mrproper
./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
make: h8300-unknown-linux-gcc: Command not found
make: h8300-unknown-linux-gcc: Command not found
  [ a bunch of the same error messages continue ]

$ make ARCH=h8300 headers_install
./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
make: h8300-unknown-linux-gcc: Command not found
  HOSTCC  scripts/basic/fixdep
make: h8300-unknown-linux-gcc: Command not found
  WRAParch/h8300/include/generated/uapi/asm/kvm_para.h
  [ snip ]

The solution is to delete this line, or to use cc-cross-prefix like
some architectures do. I chose the latter as a moderate fixup.

I added an alternative 'h8300-linux-' because it is available at:

https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/

Signed-off-by: Masahiro Yamada 
---

 arch/h8300/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile
index f801f37..ba0f26c 100644
--- a/arch/h8300/Makefile
+++ b/arch/h8300/Makefile
@@ -27,7 +27,7 @@ KBUILD_LDFLAGS += $(ldflags-y)
 CHECKFLAGS += -msize-long
 
 ifeq ($(CROSS_COMPILE),)
-CROSS_COMPILE := h8300-unknown-linux-
+CROSS_COMPILE := $(call cc-cross-prefix, h8300-unknown-linux- h8300-linux-)
 endif
 
 core-y += arch/$(ARCH)/kernel/ arch/$(ARCH)/mm/
-- 
2.7.4

Re: [PATCH v2] kcm: remove any offset before parsing messages

[Tom Herbert]

On Thu, Feb 14, 2019 at 7:31 PM Dominique Martinet
 wrote:
>
> Tom Herbert wrote on Thu, Feb 14, 2019:
> > > This second patch[2] (the current thread) now does an extra clone if
> > > there is an offset, but the problem really isn't in the clone but the
> > > pull itself that can fail and return NULL when there is memory pressure.
> > > For some reason I hadn't been able to reproduce that behaviour with
> > > strparser doing the pull, but I assume it would also be possible to hit
> > > in extreme situations, I'm not sure...
> >
> > This option looks the best to me, at least as a way to fix the issue
> > without requiring a change to the API. If the pull fails, doesn't that
> > just mean that the parser fails? Is there some behavior with this
> > patch that is not being handled gracefully?
>
> Yes, the parser fails with -ENOMEM ; that is not handled gracefully at
> all: from a user point of view, the connection just hangs (recvmsg never
> returns), without so much as a message in dmesg either.
>
Dominique,

That's by design. Here is the description in kcm.txt:

"When a TCP socket is attached to a KCM multiplexor data ready
(POLLIN) and write space available (POLLOUT) events are handled by the
multiplexor. If there is a state change (disconnection) or other error
on a TCP socket, an error is posted on the TCP socket so that a
POLLERR event happens and KCM discontinues using the socket. When the
application gets the error notification for a TCP socket, it should
unattach the socket from KCM and then handle the error condition (the
typical response is to close the socket and create a new connection if
necessary)."

> It took me a while to figure out what failed exactly as I did indeed
> expect strparser/kcm to handle that better, but ultimately as things
> stand if the parser fails it calls strp_parser_err() with the error
> which ends up in strp_abort_strp that should call
> sk->sk_error_report(sk) but in kcm case sk is the csk and I guess
> failing csk does not make a pending recv on the kcm sock to fail...
>
> I'm not sure whether propagating the error to the upper socket is the
> right thing to do, kcm is meant to be able to work with multiple
> underlying sockets so I feel we must be cautious about that, but

Right, that's the motivation for the design.

> strparser might be able to retry somehow.

We could retry on -ENOMEM since it is potentially a transient error,
but generally for errors (like connection is simply broken) it seems
like it's working as intended. I suppose we could add a socket option
to fail the KCM socket when all attached lower sockets have failed,
but I not sure that would be a significant benefit for additional
complexity.

> This is what I said below:
> > > [,,,]
> > >  - the current patch, that I could only get to fail with KASAN, but does
> > > complexify kcm a bit; this also does not fix bpf sockmap at all.
> > > Would still require to fix the hang, so make strparser retry a few times
> > > if strp->cb.parse_msg failed maybe? Or at least get the error back to
> > > userspace somehow.

The error should be getting to userspace via the TCP socket.

Tom

>
> Thanks,
> --
> Dominique

Re: [PATCH v5 3/5] arm64/kvm: context-switch ptrauth register

[Amit Daniel Kachhap]

Hi,

On 2/13/19 11:05 PM, Kristina Martsenko wrote:

On 31/01/2019 16:25, James Morse wrote:

Hi Amit,

On 28/01/2019 06:58, Amit Daniel Kachhap wrote:

When pointer authentication is supported, a guest may wish to use it.
This patch adds the necessary KVM infrastructure for this to work, with
a semi-lazy context switch of the pointer auth state.


[...]


+void __no_ptrauth __hyp_text __ptrauth_switch_to_guest(struct kvm_vcpu *vcpu,
+ struct kvm_cpu_context *host_ctxt,
+ struct kvm_cpu_context *guest_ctxt)
+{
+   if (!__ptrauth_is_enabled(vcpu))
+   return;
+



+   ptrauth_keys_store((struct ptrauth_keys *) 
_ctxt->sys_regs[APIAKEYLO_EL1]);


We can't cast part of an array to a structure like this. What happens if the
compiler inserts padding in struct-ptrauth_keys, or the struct randomization
thing gets hold of it: https://lwn.net/Articles/722293/

If we want to use the helpers that take a struct-ptrauth_keys, we need to keep
the keys in a struct-ptrauth_keys. To do this we'd need to provide accessors so
that GET_ONE_REG() of APIAKEYLO_EL1 comes from the struct-ptrauth_keys, instead
of the sys_reg array.


If I've understood correctly, the idea is to have a struct ptrauth_keys
in struct kvm_vcpu_arch, instead of having the keys in the
kvm_cpu_context->sys_regs array. This is to avoid having similar code in
__ptrauth_key_install/ptrauth_keys_switch and
__ptrauth_restore_key/__ptrauth_restore_state, and so that future
patches (that add pointer auth in the kernel) would only need to update
one place instead of two.

Yes your observation is correct.


But it also means we'll have to special case pointer auth in
kvm_arm_sys_reg_set_reg/kvm_arm_sys_reg_get_reg and kvm_vcpu_arch. Is it
worth it? I'd prefer to keep the slight code duplication but avoid the
special casing.
In my local implementation I implemented above by separating ptrauth 
registers from sys registers but if I use the new way suggested by Dave
[1] then those things are not possible as reg ID is used for matching 
entries.


So I will stick to the single sys_reg list for next iteration using [1].

[1]: 
https://lore.kernel.org/linux-arm-kernel/1547757219-19439-11-git-send-email-dave.mar...@arm.com/





Wouldn't the host keys be available somewhere else? (they must get transfer to
secondary CPUs somehow). Can we skip the save step when switching from the host?



+   ptrauth_keys_switch((struct ptrauth_keys *) 
_ctxt->sys_regs[APIAKEYLO_EL1]);
+}




[...]




diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 03b36f1..301d332 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -483,6 +483,8 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
sysreg_restore_guest_state_vhe(guest_ctxt);
__debug_switch_to_guest(vcpu);
  
+	__ptrauth_switch_to_guest(vcpu, host_ctxt, guest_ctxt);

+
__set_guest_arch_workaround_state(vcpu);
  
  	do {

@@ -494,6 +496,8 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
  
  	__set_host_arch_workaround_state(vcpu);
  
+	__ptrauth_switch_to_host(vcpu, host_ctxt, guest_ctxt);

+
sysreg_save_guest_state_vhe(guest_ctxt);
  
  	__deactivate_traps(vcpu);


...This makes me nervous...

__guest_enter() is a function that (might) change the keys, then we change them
again here. We can't have any signed return address between these two points. I
don't trust the compiler not to generate any.

~

I had a chat with some friendly compiler folk... because there are two identical
sequences in kvm_vcpu_run_vhe() and __kvm_vcpu_run_nvhe(), the compiler could
move the common code to a function it then calls. Apparently this is called
'function outlining'.

If the compiler does this, and the guest changes the keys, I think we would fail
the return address check.

Painting the whole thing with no_prauth would solve this, but this code then
becomes a target.
Because the compiler can't anticipate the keys changing, we ought to treat them
the same way we do the callee saved registers, stack-pointer etc, and
save/restore them in the __guest_enter() assembly code.

(we can still keep the save/restore in C, but call it from assembly so we know
nothing new is going on the stack).


I agree that this should be called from assembly if we were building the
kernel with pointer auth. But as we are not doing that yet in this
series, can't we keep the calls in kvm_vcpu_run_vhe for now?
Well if we keep them in kvm_vcpu_run_vhe then there is not much issue 
also in calling those C functions from assembly guest_enter/guest_exit. 
It works fine in my local implementation. This will also save code 
churning again when kernel ptrauth support is added. The only extra 
change required to be done is to assign attribute _noptrauth to those 
functions. I will add these comments properly in function description.


In general I would prefer if the keys were switched in

Re: [PATCH AUTOSEL 4.20 42/77] dm: fix clone_bio() to trigger blk_recount_segments()

[Mike Snitzer]

On Thu, Feb 14 2019 at  9:08pm -0500,
Sasha Levin  wrote:

> From: Mike Snitzer 
> 
> [ Upstream commit 57c36519e4b949f89381053f7283f5d605595b42 ]
> 
> DM's clone_bio() now benefits from using bio_trim() by fixing the fact
> that clone_bio() wasn't clearing BIO_SEG_VALID like bio_trim() does;
> which triggers blk_recount_segments() via bio_phys_segments().
> 
> Reviewed-by: Ming Lei 
> Signed-off-by: Mike Snitzer 
> Signed-off-by: Sasha Levin 

Please no, I later effectively reverted this change with commit
fa8db4948f522 ("dm: don't use bio_trim() afterall")

(As and aside, I really shouldn't have to defend against stable@ bots
picking up a commit, like 57c36519e4b949f, that wasn't marked for
stable@.)

Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel

[Joel Fernandes]

On Thu, Feb 14, 2019 at 07:19:29PM -0800, Alexei Starovoitov wrote:
> On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote:
> > Introduce in-kernel headers and other artifacts which are made available
> > as an archive through proc (/proc/kheaders.txz file). This archive makes
> > it possible to build kernel modules, run eBPF programs, and other
> > tracing programs that need to extend the kernel for tracing purposes
> > without any dependency on the file system having headers and build
> > artifacts.
> > 
> > On Android and embedded systems, it is common to switch kernels but not
> > have kernel headers available on the file system. Raw kernel headers
> > also cannot be copied into the filesystem like they can be on other
> > distros, due to licensing and other issues. There's no linux-headers
> > package on Android. Further once a different kernel is booted, any
> > headers stored on the file system will no longer be useful. By storing
> > the headers as a compressed archive within the kernel, we can avoid these
> > issues that have been a hindrance for a long time.
> 
> The set looks good to me and since the main use case is building bpf progs
> I can route it via bpf-next tree if there are no objections.
> Masahiro, could you please ack it?
> 

Yes, eBPF is one of the usecases. After this, I am also planning to send
patches to BCC so that it can use this feature when compiling C to eBPF.

Thanks!

 - Joel

Re: [PATCH V2] blk-mq: insert rq with DONTPREP to hctx dispatch list when requeue

[jianchao.wang]

On 2/15/19 11:14 AM, Ming Lei wrote:
> On Fri, Feb 15, 2019 at 10:34:39AM +0800, jianchao.wang wrote:
>> Hi Ming
>>
>> Thanks for your kindly response.
>>
>> On 2/15/19 10:00 AM, Ming Lei wrote:
>>> On Tue, Feb 12, 2019 at 09:56:25AM +0800, Jianchao Wang wrote:
 When requeue, if RQF_DONTPREP, rq has contained some driver
 specific data, so insert it to hctx dispatch list to avoid any
 merge. Take scsi as example, here is the trace event log (no
 io scheduler, because RQF_STARTED would prevent merging),

kworker/0:1H-339   [000] ...1  2037.209289: block_rq_insert: 8,0 R 4096 
 () 32768 + 8 [kworker/0:1H]
 scsi_inert_test-1987  [000]   2037.220465: block_bio_queue: 8,0 R 
 32776 + 8 [scsi_inert_test]
 scsi_inert_test-1987  [000] ...2  2037.220466: block_bio_backmerge: 8,0 R 
 32776 + 8 [scsi_inert_test]
kworker/0:1H-339   [000]   2047.220913: block_rq_issue: 8,0 R 8192 
 () 32768 + 16 [kworker/0:1H]
 scsi_inert_test-1996  [000] ..s1  2047.221007: block_rq_complete: 8,0 R () 
 32768 + 8 [0]
 scsi_inert_test-1996  [000] .Ns1  2047.221045: block_rq_requeue: 8,0 R () 
 32776 + 8 [0]
kworker/0:1H-339   [000] ...1  2047.221054: block_rq_insert: 8,0 R 4096 
 () 32776 + 8 [kworker/0:1H]
kworker/0:1H-339   [000] ...1  2047.221056: block_rq_issue: 8,0 R 4096 
 () 32776 + 8 [kworker/0:1H]
 scsi_inert_test-1986  [000] ..s1  2047.221119: block_rq_complete: 8,0 R () 
 32776 + 8 [0]

 (32768 + 8) was requeued by scsi_queue_insert and had RQF_DONTPREP.
>>>
>>> scsi_mq_requeue_cmd() does uninit the request before requeuing, but
>>> __scsi_queue_insert doesn't do that.
>>
>> Yes.
>> scsi layer use both of them.
>>
>>>
>>>
 Then it was merged with (32776 + 8) and issued. Due to RQF_DONTPREP,
 the sdb only contained the part of (32768 + 8), then only that part
 was completed. The lucky thing was that scsi_io_completion detected
 it and requeued the remaining part. So we didn't get corrupted data.
 However, the requeue of (32776 + 8) is not expected.

 Suggested-by: Jens Axboe 
 Signed-off-by: Jianchao Wang 
 ---
 V2:
  - refactor the code based on Jens' suggestion

  block/blk-mq.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

 diff --git a/block/blk-mq.c b/block/blk-mq.c
 index 8f5b533..9437a5e 100644
 --- a/block/blk-mq.c
 +++ b/block/blk-mq.c
 @@ -737,12 +737,20 @@ static void blk_mq_requeue_work(struct work_struct 
 *work)
spin_unlock_irq(>requeue_lock);
  
list_for_each_entry_safe(rq, next, _list, queuelist) {
 -  if (!(rq->rq_flags & RQF_SOFTBARRIER))
 +  if (!(rq->rq_flags & (RQF_SOFTBARRIER | RQF_DONTPREP)))
continue;
  
rq->rq_flags &= ~RQF_SOFTBARRIER;
list_del_init(>queuelist);
 -  blk_mq_sched_insert_request(rq, true, false, false);
 +  /*
 +   * If RQF_DONTPREP, rq has contained some driver specific
 +   * data, so insert it to hctx dispatch list to avoid any
 +   * merge.
 +   */
 +  if (rq->rq_flags & RQF_DONTPREP)
 +  blk_mq_request_bypass_insert(rq, false);
 +  else
 +  blk_mq_sched_insert_request(rq, true, false, false);
}
>>>
>>> Suppose it is one WRITE request to zone device, this way might break
>>> the order.
>>
>> I'm not sure about this.
>> Since the request is dispatched, it should hold and zone write lock.
>> And also mq-deadline doesn't have a .requeue_request, zone write lock
>> wouldn't be released during requeue.
> 
> You are right, looks I misunderstood the zone write lock, sorry for
> the noise.
> 
>>
>> IMO, this requeue action is similar with what blk_mq_dispatch_rq_list does.
>> The latter one also issues the request to underlying driver and requeue rqs
>> on dispatch_list if get BLK_STS_SOURCE or BLK_STS_DEV_SOURCE.
>>
>> And in addition, RQF_STARTED is set by io scheduler .dispatch_request and
>> it could be stop merging as RQF_NOMERGE_FLAGS contains it. 
> 
> Yes, that is correct.
> 
> Then another question is:
> 
> Why don't always requeue request in this way so that it can be simplified
> into one code path?
> 
> 1) in block legacy code, blk_requeue_request() doesn't insert the
> request into scheduler queue, and simply put the request into
> q->queue_head.
> 
> 2) blk_mq_requeue_request() is basically run from completion context for
> handling very unusual cases(partial completion, error, timeout, ...),
> and there shouldn't have benefit to schedule/merge requeued request.

Actually, I'm also confused about questions above when I looked into the code 
before :)

> 
> 3) RQF_DONTPREP is like a driver private flag, and read/write by driver
> only before this patch.

Yes, indeed.
And it tells us there is driver 

Re: [PATCH v2] kcm: remove any offset before parsing messages

[Dominique Martinet]

Tom Herbert wrote on Thu, Feb 14, 2019:
> > This second patch[2] (the current thread) now does an extra clone if
> > there is an offset, but the problem really isn't in the clone but the
> > pull itself that can fail and return NULL when there is memory pressure.
> > For some reason I hadn't been able to reproduce that behaviour with
> > strparser doing the pull, but I assume it would also be possible to hit
> > in extreme situations, I'm not sure...
>
> This option looks the best to me, at least as a way to fix the issue
> without requiring a change to the API. If the pull fails, doesn't that
> just mean that the parser fails? Is there some behavior with this
> patch that is not being handled gracefully?

Yes, the parser fails with -ENOMEM ; that is not handled gracefully at
all: from a user point of view, the connection just hangs (recvmsg never
returns), without so much as a message in dmesg either.

It took me a while to figure out what failed exactly as I did indeed
expect strparser/kcm to handle that better, but ultimately as things
stand if the parser fails it calls strp_parser_err() with the error
which ends up in strp_abort_strp that should call
sk->sk_error_report(sk) but in kcm case sk is the csk and I guess
failing csk does not make a pending recv on the kcm sock to fail...

I'm not sure whether propagating the error to the upper socket is the
right thing to do, kcm is meant to be able to work with multiple
underlying sockets so I feel we must be cautious about that, but
strparser might be able to retry somehow.
This is what I said below:
> > [,,,]
> >  - the current patch, that I could only get to fail with KASAN, but does
> > complexify kcm a bit; this also does not fix bpf sockmap at all.
> > Would still require to fix the hang, so make strparser retry a few times
> > if strp->cb.parse_msg failed maybe? Or at least get the error back to
> > userspace somehow.

Thanks,
-- 
Dominique

Re: mmotm 2019-02-14-15-22 uploaded (drivers/misc/fastrpc.c)

[Randy Dunlap]

On 2/14/19 3:23 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2019-02-14-15-22 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (5.x
> or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series

on x86_64:

when CONFIG_DMA_SHARED_BUFFER is not set:

ld: drivers/misc/fastrpc.o: in function `fastrpc_free_map':
fastrpc.c:(.text+0xbe): undefined reference to `dma_buf_unmap_attachment'
ld: fastrpc.c:(.text+0xcb): undefined reference to `dma_buf_detach'
ld: fastrpc.c:(.text+0xd4): undefined reference to `dma_buf_put'
ld: drivers/misc/fastrpc.o: in function `fastrpc_map_create':
fastrpc.c:(.text+0xb2b): undefined reference to `dma_buf_get'
ld: fastrpc.c:(.text+0xb47): undefined reference to `dma_buf_attach'
ld: fastrpc.c:(.text+0xb61): undefined reference to `dma_buf_map_attachment'
ld: fastrpc.c:(.text+0xc36): undefined reference to `dma_buf_put'
ld: fastrpc.c:(.text+0xc48): undefined reference to `dma_buf_detach'
ld: drivers/misc/fastrpc.o: in function `fastrpc_device_ioctl':
fastrpc.c:(.text+0x1756): undefined reference to `dma_buf_get'
ld: fastrpc.c:(.text+0x1776): undefined reference to `dma_buf_put'
ld: fastrpc.c:(.text+0x1780): undefined reference to `dma_buf_put'
ld: fastrpc.c:(.text+0x1abf): undefined reference to `dma_buf_export'
ld: fastrpc.c:(.text+0x1ae7): undefined reference to `dma_buf_fd'
ld: fastrpc.c:(.text+0x1cb5): undefined reference to `dma_buf_put'
ld: fastrpc.c:(.text+0x1cca): undefined reference to `dma_buf_put'



-- 
~Randy

[PATCH -next] drm: Remove set but not used variable 'gem'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/vc4/vc4_txp.c: In function 'vc4_txp_connector_atomic_check':
drivers/gpu/drm/vc4/vc4_txp.c:252:29: warning:
 variable 'gem' set but not used [-Wunused-but-set-variable]
  struct drm_gem_cma_object *gem;
 ^

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/vc4/vc4_txp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index aa279b5b0de7..afb1c4ec4f18 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -249,7 +249,6 @@ static int vc4_txp_connector_atomic_check(struct 
drm_connector *conn,
struct drm_connector_state *conn_state)
 {
struct drm_crtc_state *crtc_state;
-   struct drm_gem_cma_object *gem;
struct drm_framebuffer *fb;
int i;
 
@@ -275,8 +274,6 @@ static int vc4_txp_connector_atomic_check(struct 
drm_connector *conn,
if (i == ARRAY_SIZE(drm_fmts))
return -EINVAL;
 
-   gem = drm_fb_cma_get_gem_obj(fb, 0);
-
/* Pitch must be aligned on 16 bytes. */
if (fb->pitches[0] & GENMASK(3, 0))
return -EINVAL;

Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel

[Alexei Starovoitov]

On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote:
> Introduce in-kernel headers and other artifacts which are made available
> as an archive through proc (/proc/kheaders.txz file). This archive makes
> it possible to build kernel modules, run eBPF programs, and other
> tracing programs that need to extend the kernel for tracing purposes
> without any dependency on the file system having headers and build
> artifacts.
> 
> On Android and embedded systems, it is common to switch kernels but not
> have kernel headers available on the file system. Raw kernel headers
> also cannot be copied into the filesystem like they can be on other
> distros, due to licensing and other issues. There's no linux-headers
> package on Android. Further once a different kernel is booted, any
> headers stored on the file system will no longer be useful. By storing
> the headers as a compressed archive within the kernel, we can avoid these
> issues that have been a hindrance for a long time.

The set looks good to me and since the main use case is building bpf progs
I can route it via bpf-next tree if there are no objections.
Masahiro, could you please ack it?

[PATCH v3] exec: load_script: Do not exec truncated interpreter path

[Kees Cook]

Commit 8099b047ecc4 ("exec: load_script: don't blindly truncate
shebang string") was trying to protect against a confused exec of a
truncated interpreter path. However, it was overeager and also refused
to truncate arguments as well, which broke userspace, and it was
reverted. This attempts the protection again, but allows arguments to
remain truncated. Lots more comments are added, since the parsing here
is rather fiddly while dealing with whitespace.

Signed-off-by: Kees Cook 
---
 fs/binfmt_script.c | 97 +++---
 1 file changed, 82 insertions(+), 15 deletions(-)

diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index 7cde3f46ad26..8fca59f9ee03 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -20,7 +20,9 @@ static int load_script(struct linux_binprm *bprm)
char *cp;
struct file *file;
int retval;
+   bool truncated = false, end_of_interp = false;
 
+   /* Not ours to exec if we don't start with "#!". */
if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))
return -ENOEXEC;
 
@@ -33,37 +35,102 @@ static int load_script(struct linux_binprm *bprm)
if (bprm->interp_flags & BINPRM_FLAGS_PATH_INACCESSIBLE)
return -ENOENT;
 
-   /*
-* This section does the #! interpretation.
-* Sorta complicated, but hopefully it will work.  -TYT
-*/
-
+   /* Release since we are not mapping a binary into memory. */
allow_write_access(bprm->file);
fput(bprm->file);
bprm->file = NULL;
 
-   bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
-   if ((cp = strchr(bprm->buf, '\n')) == NULL)
-   cp = bprm->buf+BINPRM_BUF_SIZE-1;
+   /*
+* This section handles parsing the #! line into separate
+* interpreter path and argument strings. We must be careful
+* because bprm->buf is not yet guaranteed to be NUL-terminated.
+*
+* Truncating interpreter arguments is okay: the interpreter
+* can re-read the script to parse them on its own. Truncating
+* the interpreter path itself, though, is bad. We can note
+* truncation here, but we cannot yet check for non-EOL whitespace
+* because any leading whitespace would not indicate the end of
+* the interpreter path string.
+*/
+   for (cp = bprm->buf + 2;; cp++) {
+   if (!*cp || (*cp == '\n')) {
+   /*
+* If we see NUL (end of file) or newline it means
+* we hit the end of the #! line without truncation.
+*/
+   end_of_interp = true;
+   break;
+   }
+   if (cp == bprm->buf + BINPRM_BUF_SIZE - 1) {
+   /*
+* Otherwise if we reach the end of the buffer,
+* we've been truncated, but we don't know if
+* it was in arguments or the interpreter path.
+*/
+   truncated = true;
+   break;
+   }
+   }
*cp = '\0';
+   /* At this point, the bprm->buf array is a NUL-terminated string. */
+
+   /*
+* Truncate trailing whitespace so it cannot be included in either
+* interpreter or argument strings.
+*/
while (cp > bprm->buf) {
cp--;
-   if ((*cp == ' ') || (*cp == '\t'))
+   if ((*cp == ' ') || (*cp == '\t')) {
+   /*
+* If we see whitespace at the end of the buffer,
+* we know we've at least found a full interpreter
+* path (even if it's zero length, which is checked
+* later).
+*/
+   end_of_interp = true;
*cp = '\0';
-   else
+   } else
break;
}
+   /* Skip leading whitespace ahead of the interpreter path. */
for (cp = bprm->buf+2; (*cp == ' ') || (*cp == '\t'); cp++);
-   if (*cp == '\0')
-   return -ENOEXEC; /* No interpreter name found */
-   i_name = cp;
-   i_arg = NULL;
+   /*
+* We've successfully found the start of the interpreter path.
+* Fail if the interpreter path is already empty.
+*/
+   if (*cp)
+   i_name = cp;
+   else
+   return -ENOEXEC;
+   /*
+* Find the end of the interpreter path. We will either hit NUL
+* termination or find whitespace which signals the start of
+* arguments.
+*/
for ( ; *cp && (*cp != ' ') && (*cp != '\t'); cp++)
/* nothing */ ;
-   while ((*cp == ' ') || (*cp == '\t'))
+   /*
+* In the case of whitespace, terminate the end of the interpreter
+*