[PATCHv3 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

[Dmitry Safonov]

As the task isn't executing at the moment of {GET,SET}REGS,
return regset that corresponds to code selector, rather than
value of TIF_IA32 flag.
I.e. if we ptrace i386 elf binary that has just changed it's
code selector to __USER_CS, than GET_REGS will return
full x86_64 register set.

Note, that this will work only if application has changed it's CS.
If the application does 32-bit syscall with __USER_CS, ptrace
will still return 64-bit register set. Which might be still confusing
for tools that expect TS_COMPACT to be exposed [1, 2].

So this this change should make PTRACE_GETREGSET more reliable and
this will be another step to drop TIF_{IA32,X32} flags.

[1]: https://sourceforge.net/p/strace/mailman/message/30471411/
[2]: https://lkml.org/lkml/2012/1/18/320

Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Cc: Pedro Alves 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc: Cyrill Gorcunov 
Cc: Pavel Emelyanov 
Signed-off-by: Dmitry Safonov 
---
 arch/x86/kernel/ptrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index f79576a541ff..ad0bab8fc594 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1358,7 +1358,7 @@ void update_regset_xstate_info(unsigned int size, u64 
xstate_mask)
 const struct user_regset_view *task_user_regset_view(struct task_struct *task)
 {
 #ifdef CONFIG_IA32_EMULATION
-   if (test_tsk_thread_flag(task, TIF_IA32))
+   if (!user_64bit_mode(task_pt_regs(task)))
 #endif
 #if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION
return &user_x86_32_view;
-- 
2.9.0

Re: [PATCH 3/5] rxrpc: fix last_call processing

[David Howells]

Arnd Bergmann  wrote:

> A change to the retransmission handling in rxrpc caused a use-before-init
> bug in rxrpc_data_ready(), as indicated by "gcc -Wmaybe-uninitialized":
> 
> net/rxrpc/input.c: In function 'rxrpc_data_ready':
> net/rxrpc/input.c:735:34: error: 'call' may be used uninitialized in this 
> function [-Werror=maybe-uninitialized]
> 
> This moves the initialization of the local variable before the first
> user, which presumably is what was intended here.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 18bfeba50dfd ("rxrpc: Perform terminal call ACK/ABORT retransmission 
> from conn processor")
> ---
> Cc: David Howells 
> Cc: "David S. Miller" 
> Cc: net...@vger.kernel.org
> 
>  net/rxrpc/input.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
> index 66cdeb56f44f..3c22e43a58fd 100644
> --- a/net/rxrpc/input.c
> +++ b/net/rxrpc/input.c
> @@ -728,6 +728,10 @@ void rxrpc_data_ready(struct sock *sk)
>   if (sp->hdr.callNumber < chan->last_call)
>   goto discard_unlock;
>  
> + call = rcu_dereference(chan->call);
> + if (!call || atomic_read(&call->usage) == 0)
> + goto cant_route_call;
> +
>   if (sp->hdr.callNumber == chan->last_call) {
>   /* For the previous service call, if completed
>* successfully, we discard all further packets.
> @@ -744,10 +748,6 @@ void rxrpc_data_ready(struct sock *sk)
>   goto out_unlock;
>   }
>  
> - call = rcu_dereference(chan->call);
> - if (!call || atomic_read(&call->usage) == 0)
> - goto cant_route_call;
> -
>   rxrpc_post_packet_to_call(call, skb);
>   goto out_unlock;
>   }

You can't rearrange these like this.  I have a different fix.

David

Re: [PATCH 1/5] IA64-IRQ: Use kmalloc_array() in sn_irq_lh_init()

[SF Markus Elfring]

>>> @@ -474,12 +474,12 @@ void __init sn_irq_lh_init(void)
>>>   {
>>>int i;
>>>
>>> - sn_irq_lh = kmalloc(sizeof(struct list_head *) * NR_IRQS, GFP_KERNEL);
>>> + sn_irq_lh = kmalloc_array(NR_IRQS, sizeof(*sn_irq_lh), GFP_KERNEL);
>>>if (!sn_irq_lh)
>>>panic("SN PCI INIT: Failed to allocate memory for PCI 
>>> init\n");
>>>
>>>for (i = 0; i < NR_IRQS; i++) {
>>> - sn_irq_lh[i] = kmalloc(sizeof(struct list_head), GFP_KERNEL);
>>> + sn_irq_lh[i] = kmalloc(*sn_irq_lh[i], GFP_KERNEL);
>>
>> Did a sizeof get lost here?
> 
> Yes, thanks Julia.

Unfortunately, another copy mistake happened during a bit of
source code editing.


> This is why adding the generating spatch code is always good.

I find that this broken update suggestion can point a few details out
for further considerations.

I dared to combine some software aspects once more in this use case.
Such a combination (join point) shows interesting challenges,
doesn't it?


> And Markus, please always compile test your code using the
> appropriate cross-compilers available here:
> https://www.kernel.org/pub/tools/crosstool/

Thanks for your link.


> And btw: using sizeof(*pp[i]) or sizeof(**pp) is not always
> clearer or better than using sizeof(type)

Do you express a target conflict between your expectations
and the evolving Linux coding style documentation here?

Would any software developers insist to see the corresponding
data type directly instead of "evaluating" a pointer expression?


> If you _really wanted to clear up this code and make it more
> robust/better, it'd probably be nicer to convert the
> struct list_head **sn_irq_lh to a single struct list_head *
…
> That would be less data space overall given the alignment
> waste of the individual allocs.

Does this suggestion mean that I should drop my proposal
around the software components "IRQ" and "TLB" for the system
architecture "IA64" in such a questionable patch series?

Regards,
Markus

[PATCH] bdev: fix NULL pointer dereference in sync()/close() race

[Vegard Nossum]

I got this with syzkaller:

general protection fault:  [#1] PREEMPT SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
CPU: 0 PID: 11941 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
task: 880110762cc0 task.stack: 88010229
RIP: 0010:[]  [] 
blk_get_backing_dev_info+0x4a/0x70
RSP: 0018:880102297cd0  EFLAGS: 00010202
RAX: dc00 RBX:  RCX: c9bb4000
RDX: 0097 RSI:  RDI: 04b8
RBP: 880102297cd8 R08:  R09: 0001
R10:  R11: 0001 R12: 88011a010a90
R13: 88011a594568 R14: 88011a010890 R15: 7fff
FS:  7f2445174700() GS:88011aa0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 200047c8 CR3: 000107eb5000 CR4: 06f0
DR0: 001e DR1: 001e DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Stack:
 110020452f9e 880102297db8 81508daa 
 41b58ab3 844e89e1 81508b30 ed0020452001
 7fff   7fff
Call Trace:
 [] __filemap_fdatawrite_range+0x27a/0x2e0
 [] ? filemap_check_errors+0xe0/0xe0
 [] ? preempt_schedule+0x27/0x30
 [] ? ___preempt_schedule+0x16/0x18
 [] filemap_fdatawrite+0x26/0x30
 [] fdatawrite_one_bdev+0x50/0x70
 [] iterate_bdevs+0x194/0x210
 [] ? fdatawait_one_bdev+0x70/0x70
 [] ? sync_filesystem+0x240/0x240
 [] sys_sync+0xce/0x160
 [] ? sync_filesystem+0x240/0x240
 [] ? exit_to_usermode_loop+0x190/0x190
 [] ? __context_tracking_exit.part.4+0x3a/0x1e0
 [] do_syscall_64+0x1c4/0x4e0
 [] entry_SYSCALL64_slow_path+0x25/0x25
Code: 89 fa 48 c1 ea 03 80 3c 02 00 75 35 48 8b 9b e0 00 00 00 48 b8 00 00 
00 00 00 fc ff df 48 8d bb b8 04 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 17 
48 8b 83 b8 04 00 00 5b 5d 48 05 10 02 00 00
RIP  [] blk_get_backing_dev_info+0x4a/0x70
 RSP 

The problem is that sync() calls down to blk_get_backing_dev_info()
without necessarily having the block device opened (if it races with
another process doing close()):

/**
 * blk_get_backing_dev_info - get the address of a queue's backing_dev_info
 * @bdev:   device
 *
 * Locates the passed device's request queue and returns the address of its
 * backing_dev_info.  This function can only be called if @bdev is opened   
   <
 * and the return value is never NULL.
 */
struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev)
{
struct request_queue *q = bdev_get_queue(bdev);

return &q->backing_dev_info;
}

bdev_get_queue() crashes on dereferencing bdev->bd_disk->queue because
->bd_disk was set to NULL when close() reached __blkdev_put().

Taking bdev->bd_mutex and checking bdev->bd_disk actually seems to be a
reliable test of whether it's safe to call filemap_fdatawrite() for the
block device inode and completely fixes the crash for me.

What I don't like about this patch is that it simply skips block devices
which we don't have any open file descriptors for. That seems wrong to
me because sync() should do writeback on (and wait for) _all_ devices,
not just the ones that we happen to have an open file descriptor for.
Imagine if we opened a device, wrote a lot of data to it, closed it,
called sync(), and sync() returns. Now we should be guaranteed the data
was written, but I'm not sure we are in this case. But maybe I've
misunderstood how the writeback mechanism works.

Another ugly thing is that we're now holding a new mutex over a
potentially big chunk of code (everything that happens inside
filemap_fdatawrite()). The only thing I can say is that it seems to
work here.

I have a reproducer that reliably triggers the problem in ~2 seconds so
I can easily test other proposed fixes if there are any. I would also be
happy to submit a new patch with some guidance on the Right Way to fix
this.

Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum 
---
 fs/sync.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/sync.c b/fs/sync.c
index 2a54c1f..9189eeb 100644
--- a/fs/sync.c
+++ b/fs/sync.c
@@ -81,7 +81,10 @@ static void sync_fs_one_sb(struct super_block *sb, void *arg)
 
 static void fdatawrite_one_bdev(struct block_device *bdev, void *arg)
 {
-   filemap_fdatawrite(bdev->bd_inode->i_mapping);
+   mutex_lock(&bdev->bd_mutex);
+   if (bdev->bd_disk)
+   filemap_fdatawrite(bdev->bd_inode->i_mapping);
+   mutex_unlock(&bdev->bd_mutex);
 }
 
 static void fdatawait_one_bdev(struct block_device *bdev, void *arg)
-- 
2.10

Re: [PATCH][RFC v4] timekeeping: ignore the bogus sleep time if pm_trace is enabled

[Xunlei Pang]

On 2016/08/18 at 18:43, Chen Yu wrote:
> Previously we encountered some memory overflow issues due to
> the bogus sleep time brought by inconsistent rtc, which is
> triggered when pm_trace is enabled, please refer to:
> https://patchwork.kernel.org/patch/9286365/
> It's improper in the first place to call __timekeeping_inject_sleeptime()
> in case that pm_trace is enabled simply because that "hash" time value
> will wreckage the timekeeping subsystem.
>
> So this patch ignores the sleep time if pm_trace is enabled in
> the following situation:
> 1. rtc is used as persist clock to compensate for sleep time,
>(because system does not have a nonstop clocksource) or
> 2. rtc is used to calculate the sleep time in rtc_resume.
>
> Cc: Rafael J. Wysocki 
> Cc: John Stultz 
> Cc: Thomas Gleixner 
> Cc: Xunlei Pang 
> Cc: Zhang Rui 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Suggested-by: Rafael J. Wysocki 
> Reported-by: Janek Kozicki 
> Signed-off-by: Chen Yu 
> ---
>  arch/x86/kernel/rtc.c |  7 +++
>  kernel/time/timekeeping.c | 14 +-
>  2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
> index 79c6311c..6039138 100644
> --- a/arch/x86/kernel/rtc.c
> +++ b/arch/x86/kernel/rtc.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -146,6 +147,12 @@ void read_persistent_clock(struct timespec *ts)
>   x86_platform.get_wallclock(ts);
>  }
>  
> +bool persistent_clock_is_usable(void)
> +{
> + /* Unusable if pm_trace is enabled. */
> + return !((x86_platform.get_wallclock == mach_get_cmos_time) &&
> +  pm_trace_is_enabled());
> +}
>  
>  static struct resource rtc_resources[] = {
>   [0] = {
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 3b65746..3122bd2b 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "tick-internal.h"
>  #include "ntp_internal.h"
> @@ -1450,6 +1451,11 @@ void __weak read_boot_clock64(struct timespec64 *ts)
>   ts->tv_nsec = 0;
>  }
>  
> +bool __weak persistent_clock_is_usable(void)
> +{
> + return true;
> +}
> +

I suddenly think of a way to avoid adding this ugly __weak auxiliary function.

Add a special treatment for read_persistent_clock() in arch/x86/kernel/rtc.c as 
follows,
void read_persistent_clock(struct timespec *ts)
{
x86_platform.get_wallclock(ts);

/* Make rtc-based persistent clock unusable if pm_trace is enabled. */
if (pm_trace_is_enabled() &&
x86_platform.get_wallclock == mach_get_cmos_time) {
ts->tv_sec = 0;
ts->tv_nsec = 0;
}
}

In this way, we can avoid the touch of timekeeping core, after all ptrace is 
currently x86-specific.

What do you think?

Regards,
Xunlei

>  /* Flag for if timekeeping_resume() has injected sleeptime */
>  static bool sleeptime_injected;
>  
> @@ -1551,7 +1557,7 @@ static void __timekeeping_inject_sleeptime(struct 
> timekeeper *tk,
>   */
>  bool timekeeping_rtc_skipresume(void)
>  {
> - return sleeptime_injected;
> + return sleeptime_injected || pm_trace_is_enabled();
>  }
>  
>  /**
> @@ -1662,6 +1668,12 @@ void timekeeping_resume(void)
>   } else if (timespec64_compare(&ts_new, &timekeeping_suspend_time) > 0) {
>   ts_delta = timespec64_sub(ts_new, timekeeping_suspend_time);
>   sleeptime_injected = true;
> + /*
> +  * If rtc is used as persist clock thus it
> +  * would be bogus when pm_trace is enabled.
> +  */
> + if (!persistent_clock_is_usable())
> + sleeptime_injected = false;
>   }
>  
>   if (sleeptime_injected)

Re: [PATCH 0/4] Better memcpy_mcsafe()

[Ingo Molnar]

* Tony Luck  wrote:

> The original version of this used a check of the x86_model_id string
> for the magic "Intel(R) Xeon(R) CPU E7-" to determine whether we are
> running on a cpu that supports machine check recovery.
> 
> Boris tried to talk me out of that, but at the time I didn't think
> there was a viable alternate option, and somehow he fell for that line.
> 
> It turns out there is a better way, that isn't as painful as I thought
> it might be.  It does help guarantee future employment, as I'll
> have to add a new quirk for each CPU generation. But the check for "E7"
> would have eventually failed and required a patch too.
> 
> The downside of a quirk is that it runs after the X86_FEATURE patching
> code. So instead of "static_cpu_has()" we use 
> "static_branch_unlikely(&mcsafe_key)"

So why not move it to the early PCI quirk code in arch/x86/ and get rid of this 
quirk within a quirk?

Thanks,

Ingo

Re: ia64/mm/tlb: Delete unnecessary braces

[SF Markus Elfring]

>arch/ia64/mm/tlb.c: In function 'ia64_global_tlb_purge':
>>> arch/ia64/mm/tlb.c:247:5: warning: suggest explicit braces to avoid 
>>> ambiguous 'else' [-Wparentheses]
>  if (mm != active_mm)
> ^

Does this message from the compiler mean that there are a few
corresponding details to clarify for the Linux coding style documentation?

Regards,
Markus

Re: [RFC v2 09/10] landlock: Handle cgroups

[Andy Lutomirski]

On Aug 27, 2016 1:05 AM, "Alexei Starovoitov"
 wrote:
>
> On Fri, Aug 26, 2016 at 05:10:40PM +0200, Mickaël Salaün wrote:
> >
>
> trimming cc list again. When it's too big vger will consider it as spam.
>
> > On 26/08/2016 04:14, Alexei Starovoitov wrote:
> > > On Thu, Aug 25, 2016 at 12:32:44PM +0200, Mickaël Salaün wrote:
> > >> Add an eBPF function bpf_landlock_cmp_cgroup_beneath(opt, map, map_op)
> > >> to compare the current process cgroup with a cgroup handle, The handle
> > >> can match the current cgroup if it is the same or a child. This allows
> > >> to make conditional rules according to the current cgroup.
> > >>
> > >> A cgroup handle is a map entry created from a file descriptor referring
> > >> a cgroup directory (e.g. by opening /sys/fs/cgroup/X). In this case, the
> > >> map entry is of type BPF_MAP_HANDLE_TYPE_LANDLOCK_CGROUP_FD and the
> > >> inferred array map is of type BPF_MAP_ARRAY_TYPE_LANDLOCK_CGROUP.
> > >>
> > >> An unprivileged process can create and manipulate cgroups thanks to
> > >> cgroup delegation.
> > >>
> > >> Signed-off-by: Mickaël Salaün 
> > > ...
> > >> +static inline u64 bpf_landlock_cmp_cgroup_beneath(u64 r1_option, u64 
> > >> r2_map,
> > >> +  u64 r3_map_op, u64 r4, u64 r5)
> > >> +{
> > >> +  u8 option = (u8) r1_option;
> > >> +  struct bpf_map *map = (struct bpf_map *) (unsigned long) r2_map;
> > >> +  enum bpf_map_array_op map_op = r3_map_op;
> > >> +  struct bpf_array *array = container_of(map, struct bpf_array, map);
> > >> +  struct cgroup *cg1, *cg2;
> > >> +  struct map_landlock_handle *handle;
> > >> +  int i;
> > >> +
> > >> +  /* ARG_CONST_PTR_TO_LANDLOCK_HANDLE_CGROUP is an arraymap */
> > >> +  if (unlikely(!map)) {
> > >> +  WARN_ON(1);
> > >> +  return -EFAULT;
> > >> +  }
> > >> +  if (unlikely((option | _LANDLOCK_FLAG_OPT_MASK) != 
> > >> _LANDLOCK_FLAG_OPT_MASK))
> > >> +  return -EINVAL;
> > >> +
> > >> +  /* for now, only handle OP_OR */
> > >> +  switch (map_op) {
> > >> +  case BPF_MAP_ARRAY_OP_OR:
> > >> +  break;
> > >> +  case BPF_MAP_ARRAY_OP_UNSPEC:
> > >> +  case BPF_MAP_ARRAY_OP_AND:
> > >> +  case BPF_MAP_ARRAY_OP_XOR:
> > >> +  default:
> > >> +  return -EINVAL;
> > >> +  }
> > >> +
> > >> +  synchronize_rcu();
> > >> +
> > >> +  for (i = 0; i < array->n_entries; i++) {
> > >> +  handle = (struct map_landlock_handle *)
> > >> +  (array->value + array->elem_size * i);
> > >> +
> > >> +  /* protected by the proto types, should not happen */
> > >> +  if (unlikely(handle->type != 
> > >> BPF_MAP_HANDLE_TYPE_LANDLOCK_CGROUP_FD)) {
> > >> +  WARN_ON(1);
> > >> +  return -EFAULT;
> > >> +  }
> > >> +  if (unlikely(!handle->css)) {
> > >> +  WARN_ON(1);
> > >> +  return -EFAULT;
> > >> +  }
> > >> +
> > >> +  if (option & LANDLOCK_FLAG_OPT_REVERSE) {
> > >> +  cg1 = handle->css->cgroup;
> > >> +  cg2 = task_css_set(current)->dfl_cgrp;
> > >> +  } else {
> > >> +  cg1 = task_css_set(current)->dfl_cgrp;
> > >> +  cg2 = handle->css->cgroup;
> > >> +  }
> > >> +
> > >> +  if (cgroup_is_descendant(cg1, cg2))
> > >> +  return 0;
> > >> +  }
> > >> +  return 1;
> > >> +}
> > >
> > > - please take a loook at exisiting bpf_current_task_under_cgroup and
> > > reuse BPF_MAP_TYPE_CGROUP_ARRAY as a minimum. Doing new cgroup array
> > > is nothing but duplication of the code.
> >
> > Oh, I didn't know about this patchset and the new helper. Indeed, it
> > looks a lot like mine except there is no static verification of the map
> > type as I did with the arraymap of handles, and no batch mode either. I
> > think the return value of bpf_current_task_under_cgroup is error-prone
> > if an eBPF program do an "if(ret)" test on the value (because of the
> > negative ERRNO return value). Inverting the 0 and 1 return values should
> > fix this (0 == succeed, 1 == failed, <0 == error).
>
> nothing to fix. It's good as-is. Use if (ret > 0) instead.
>
> >
> > To sum up, there is four related patchsets:
> > * "Landlock LSM: Unprivileged sandboxing" (this series)
> > * "Add Checmate, BPF-driven minor LSM" (Sargun Dhillon)
> > * "Networking cgroup controller" (Anoop Naravaram)
> > * "Add eBPF hooks for cgroups" (Daniel Mack)
> >
> > The three other series (Sargun's, Anoop's and Daniel's) are mainly
> > focused on network access-control via cgroup for *containers*. As far as
> > I can tell, only a *root* user (CAP_SYS_ADMIN) can use them. Landlock's
> > goal is to empower all processes (privileged or not) to create their own
> > sandbox. This also means, like explained in "[RFC v2 00/10] Landlock
> > LSM: Unprivileged sandboxing", there is more constraints. For example,
> > it is not acceptable to let a process probe the kernel memory as it
> > wish. More details are in the Landl

[PATCH v1] i2c: designware: save the preset value of DW_IC_SDA_HOLD

[Zhuo-hao Lee]

There are several ways to set the SDA hold time for i2c controller,
including: Device Tree, built-in device properties and ACPI. However,
if the SDA hold time is not specified by above method, we should
read the value, where it is preset by firmware, and save it to
sda_hold_time. This is needed because when i2c controller enters
runtime suspend, the DW_IC_SDA_HOLD value will be reset to chipset
default value. And during runtime resume, i2c_dw_init will be called
to reconfigure i2c controller. If sda_hold_time is zero, the chipset
default hold time will be used, that will be too short for some
platforms. Therefore, to have a better tolerance, the DW_IC_SDA_HOLD
value should be kept by sda_hold_time.

Signed-off-by: Zhuo-hao Lee 
---
 drivers/i2c/busses/i2c-designware-core.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-core.c 
b/drivers/i2c/busses/i2c-designware-core.c
index c6922b8..fcd973d 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -367,13 +367,17 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
dev_dbg(dev->dev, "Fast-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
 
/* Configure SDA Hold Time if required */
-   if (dev->sda_hold_time) {
-   reg = dw_readl(dev, DW_IC_COMP_VERSION);
-   if (reg >= DW_IC_SDA_HOLD_MIN_VERS)
+   reg = dw_readl(dev, DW_IC_COMP_VERSION);
+   if (reg >= DW_IC_SDA_HOLD_MIN_VERS) {
+   if (dev->sda_hold_time) {
dw_writel(dev, dev->sda_hold_time, DW_IC_SDA_HOLD);
-   else
-   dev_warn(dev->dev,
-   "Hardware too old to adjust SDA hold time.");
+   } else {
+   /* Keep previous hold time setting if no one set it */
+   dev->sda_hold_time = dw_readl(dev, DW_IC_SDA_HOLD);
+   }
+   } else {
+   dev_warn(dev->dev,
+   "Hardware too old to adjust SDA hold time.\n");
}
 
/* Configure Tx/Rx FIFO threshold levels */
-- 
1.9.1

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing

[Andy Lutomirski]

On Thu, Aug 25, 2016 at 3:32 AM, Mickaël Salaün  wrote:
> Hi,
>
> This series is a proof of concept to fill some missing part of seccomp as the
> ability to check syscall argument pointers or creating more dynamic security
> policies. The goal of this new stackable Linux Security Module (LSM) called
> Landlock is to allow any process, including unprivileged ones, to create
> powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the
> OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of
> bugs or unexpected/malicious behaviors in userland applications.
>
> The first RFC [1] was focused on extending seccomp while staying at the 
> syscall
> level. This brought a working PoC but with some (mitigated) ToCToU race
> conditions due to the seccomp ptrace hole (now fixed) and the non-atomic
> syscall argument evaluation (hence the LSM hooks).
>
>
> # Landlock LSM
>
> This second RFC is a fresh revamp of the code while keeping some working 
> ideas.
> This series is mainly focused on LSM hooks, while keeping the possibility to
> tied them to syscalls. This new code removes all race conditions by design. It
> now use eBPF instead of a subset of cBPF (as used by seccomp-bpf). This allow
> to remove the previous stacked cBPF hack to do complex access checks thanks to
> dedicated eBPF functions. An eBPF program is still very limited (i.e. can only
> call a whitelist of functions) and can not do a denial of service (i.e. no
> loop). The other major improvement is the replacement of the previous custom
> checker groups of syscall arguments with a new dedicated eBPF map to collect
> and compare Landlock handles with system resources (e.g. files or network
> connections).
>
> The approach taken is to add the minimum amount of code while still allowing
> the userland to create quite complex access rules. A dedicated security policy
> language such as used by SELinux, AppArmor and other major LSMs is a lot of
> code and dedicated to a trusted process (i.e. root/administrator).
>

I think there might be a problem with the current design.  If I add a
seccomp filter that uses RET_LANDLOCK and some landlock filters, what
happens if a second seccomp filter *also* uses RET_LANDLOCK?  I think
they'll interfere with each other.  It might end up being necessary to
require only one landlock seccomp layer at a time or to find a way to
stick all the filters in a layer together with the LSM callbacks or
maybe to just drop RET_LANDLOCK and let the callbacks look at the
syscall args.

BTW, what happens if an LSM hook is called outside a syscall context,
e.g. from a page fault?

>
>
> # Sandbox example with conditional access control depending on cgroup
>
>   $ mkdir /sys/fs/cgroup/sandboxed
>   $ ls /home
>   user1
>   $ LANDLOCK_CGROUPS='/sys/fs/cgroup/sandboxed' \
>   LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \
>   ./sandbox /bin/sh -i
>   $ ls /home
>   user1
>   $ echo $$ > /sys/fs/cgroup/sandboxed/cgroup.procs
>   $ ls /home
>   ls: cannot open directory '/home': Permission denied
>

Something occurs to me that isn't strictly relevant to landlock but
may be relevant to unprivileged cgroups: can you cause trouble by
setting up a nastily-configured cgroup and running a setuid program in
it?

Re: [PATCH RFC v3] x86,mm,sched: make lazy TLB mode even lazier

[Ingo Molnar]

* Rik van Riel  wrote:

> On Thu, 25 Aug 2016 12:42:15 -0700
> "H. Peter Anvin"  wrote:
> 
> > Why grabbing a lock instead of cmpxchg?
> 
> ... and some more cleanups later, this might actually be
> good to merge, assuming it works for Benjamin :)
> 
> ---8<---

LGTM in principle (it's a pretty clever trick!), just some minor stylistic nits:

> 
> Subject: x86,mm,sched: make lazy TLB mode even lazier
> 
> Lazy TLB mode can result in an idle CPU being woken up for a TLB
> flush, when all it really needed to do was flush %cr3 before the
> next context switch.

s/%cr3/CR3

> This is mostly fine on bare metal, though sub-optimal from a power
> saving point of view, and deeper C states could make TLB flushes
> take a little longer than desired.

s/C state/C-state/

> On virtual machines, the pain can be much worse, especially if a
> currently non-running VCPU is woken up for a TLB invalidation
> IPI, on a CPU that is busy running another task. It could take
> a while before that IPI is handled, leading to performance issues.

So I was going to suggest:

 s/VCPU/vCPU

But then, out of curiosity, I ran:

   triton:~/tip> for N in $(git log v3.0.. | grep -i vcpu | sed 
's/[^a-zA-Z\d\s]/ /g'); do echo $N; done | grep -iw vcpu  | sort | uniq -c | 
sort -n
  3 Vcpu
125 vCPU
527 VCPU
   1611 vcpu

So never mind, I guess we missed that boat by a few years already ;-)

> 
> This patch deals with the issue by introducing a third tlb state,
> TLBSTATE_FLUSH, which causes %cr3 to be flushed at the next
> context switch.

s/tlb state/TLB state

> 
> A CPU that transitions from TLBSTATE_LAZY to TLBSTATE_OK during
> the attempted transition to TLBSTATE_FLUSH will get a TLB flush
> IPI, just like a CPU that was in TLBSTATE_OK to begin with.
> 
> Nothing is done for a CPU that is already in TLBSTATE_FLUSH mode.
> 
> This patch is totally untested, because I am at a conference right
> now, and Benjamin has the test case :)
> 
> Benjamin, does this help your issue?
>
> Signed-off-by: Rik van Riel 
> Reported-by: Benjamin Serebrin 
> ---
>  arch/x86/include/asm/tlbflush.h |  1 +
>  arch/x86/mm/tlb.c   | 47 
> ++---
>  2 files changed, 45 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
> index 4e5be94e079a..5ae8e4b174f8 100644
> --- a/arch/x86/include/asm/tlbflush.h
> +++ b/arch/x86/include/asm/tlbflush.h
> @@ -310,6 +310,7 @@ void native_flush_tlb_others(const struct cpumask 
> *cpumask,
>  
>  #define TLBSTATE_OK  1
>  #define TLBSTATE_LAZY2
> +#define TLBSTATE_FLUSH   3
>  
>  static inline void reset_lazy_tlbstate(void)
>  {
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 5643fd0b1a7d..4352db65a129 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -140,10 +140,12 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
> mm_struct *next,
>   }
>  #ifdef CONFIG_SMP
> else {
> + int oldstate = this_cpu_read(cpu_tlbstate.state);
>   this_cpu_write(cpu_tlbstate.state, TLBSTATE_OK);

Please separate local variable definition blocks from statements by an extra 
newline.

>   BUG_ON(this_cpu_read(cpu_tlbstate.active_mm) != next);
>  
> - if (!cpumask_test_cpu(cpu, mm_cpumask(next))) {
> + if (oldstate == TLBSTATE_FLUSH ||
> + !cpumask_test_cpu(cpu, mm_cpumask(next))) {
>   /*
>* On established mms, the mm_cpumask is only changed
>* from irq context, from ptep_clear_flush() while in
> @@ -242,11 +244,42 @@ static void flush_tlb_func(void *info)
>  
>  }
>  
> +/*
> + * Determine whether a CPU's TLB needs to be flushed now, or whether the
> + * flush can be delayed until the next context switch, by changing the
> + * tlbstate from TLBSTATE_LAZY to TLBSTATE_FLUSH.
> + */
> +static bool lazy_tlb_can_skip_flush(int cpu) {
> + int *tlbstate = &per_cpu(cpu_tlbstate.state, cpu);
> + int old;

Yeah, so this is not how the standard function definition looks like.

> + /* A task on the CPU is actively using the mm. Flush the TLB. */
> + if (*tlbstate == TLBSTATE_OK)
> + return false;
> +
> + /* The TLB will be flushed on the next context switch. */
> + if (*tlbstate == TLBSTATE_FLUSH)
> + return true;
> +
> + /*
> +  * The CPU is in TLBSTATE_LAZY, which could context switch back
> +  * to TLBSTATE_OK, re-using the TLB state without a TLB flush.
> +  * In that case, a TLB flush IPI needs to be sent.
> +  *
> +  * Otherwise, the TLB state is now TLBSTATE_FLUSH, and the
> +  * TLB flush IPI can be skipped.
> +  */
> + old = cmpxchg(tlbstate, TLBSTATE_LAZY, TLBSTATE_FLUSH);
> +
> + return old != TLBSTATE_OK;
> +}
> +
>  void native_flush_tlb_others(const struct cpumask *cpumask,
>struct mm_struct *mm, 

Re: [PATCH v7 03/14] arm64/numa: add nid check for memory block

[Leizhen (ThunderTown)]

On 2016/8/26 20:39, Will Deacon wrote:
> On Wed, Aug 24, 2016 at 03:44:42PM +0800, Zhen Lei wrote:
>> Use the same tactic to cpu and numa-distance nodes.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  drivers/of/of_numa.c | 5 +
>>  1 file changed, 5 insertions(+)
> 
> The subject has arm64/numa, but this is clearly core OF code and
I originally added below check in arch/arm64/mm/numa.c, until Hanjun Guo
told me that it should move into drivers/of/of_numa.c

I forgot updating this.

> requires an ack from Rob.
> 
> The commit message also doesn't make much sense to me.
> 
>> diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
>> index 7b3fbdc..afaeb9c 100644
>> --- a/drivers/of/of_numa.c
>> +++ b/drivers/of/of_numa.c
>> @@ -75,6 +75,11 @@ static int __init of_numa_parse_memory_nodes(void)
>>   */
>>  continue;
>>
>> +if (nid >= MAX_NUMNODES) {
>> +pr_warn("NUMA: Node id %u exceeds maximum value\n", 
>> nid);
>> +return -EINVAL;
>> +}
> 
> Do you really want to return from the function here? Shouldn't we at least
> of_node_put(np), i.e. by using a break; ?
Thanks for pointing out this mistake. I will change to "r = -EINVAL" in the 
next version.

> 
> Will
> 
> .
> 

Re: [PATCH 2/2] f2fs: fix to update node page under cp_rwsem

[Chao Yu]

On 2016/8/27 1:04, Jaegeuk Kim wrote:
> On Sat, Aug 27, 2016 at 12:14:32AM +0800, Chao Yu wrote:
>> From: Chao Yu 
>>
>> Update node page under cp_rwsem in order to keep data consistency
>> during writting checkpoint.
>>
>> Signed-off-by: Chao Yu 
>> ---
>>  fs/f2fs/inode.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
>> index 9ac5efc..1057c73 100644
>> --- a/fs/f2fs/inode.c
>> +++ b/fs/f2fs/inode.c
>> @@ -377,8 +377,11 @@ retry:
>>  goto retry;
>>  }
>>  
>> -if (err)
>> +if (err) {
>> +f2fs_lock_op(sbi);
>>  update_inode_page(inode);
>> +f2fs_unlock_op(sbi);
>> +}
> 
> Any corner case?

No, just follow the old rule.

> Now, it allows updating node page when checkpoint is doing.

Oh, so for current rule, during checkpoint it:
1. allows updating meta info of inode which is not related to metadata of
filesystem (e.g. i_size, i_block, i_nlink..)
2. does not allow updating meta info of inode which is related to metadata of
filesystem (i_addr, i_nid..)

Is my understanding right?

Thanks,

> 
> Thanks,
> 
>>  sb_end_intwrite(inode->i_sb);
>>  no_delete:
>>  stat_dec_inline_xattr(inode);
>> -- 
>> 2.7.2
> 
> .
> 

Re: [PATCH] docs: make kernel-doc handle varargs properly

[Jani Nikula]

On Fri, 26 Aug 2016, Jonathan Corbet  wrote:
> As far as I can tell, the handling of "..." arguments has never worked
> right, so any documentation provided was ignored in favor of "variable
> arguments."  This makes kernel-doc handle "@...:" as documented.  It does
> *not* fix spots in kerneldoc comments that don't follow that convention,
> but they are no more broken than before.
>
> Signed-off-by: Jonathan Corbet 
> ---
>  scripts/kernel-doc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index c681e8f0ecc2..e6c52ab938fd 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -414,7 +414,7 @@ my $doc_com_body = '\s*\* ?';
>  my $doc_decl = $doc_com . '(\w+)';
>  # @params and a strictly limited set of supported section names
>  my $doc_sect = $doc_com . 
> -'\s*(\@\w+|description|context|returns?|notes?|examples?)\s*:(.*)';
> +'\s*(\@[.\w]+|description|context|returns?|notes?|examples?)\s*:(.*)';

So this will now accept "@foo.bar.baz:" too, right? Should it be
something like this instead?

'\s*(\@\w+|\@\.\.\.|description|context|returns?|notes?|examples?)\s*:(.*)';

BR,
Jani.


>  my $doc_content = $doc_com_body . '(.*)';
>  my $doc_block = $doc_com . 'DOC:\s*(.*)?';
>  my $doc_inline_start = '^\s*/\*\*\s*$';
> @@ -2340,6 +2340,7 @@ sub push_parameter($$$) {
>  
>   if ($type eq "" && $param =~ /\.\.\.$/)
>   {
> + $param = "...";
>   if (!defined $parameterdescs{$param} || $parameterdescs{$param} eq 
> "") {
>   $parameterdescs{$param} = "variable arguments";
>   }

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] fix:iio:common:st_sensors:st_sensors_trigger:mark symbols static where possible

[Linus Walleij]

On Sat, Aug 27, 2016 at 8:26 AM, Baoyou Xie  wrote:

> We get 2 warnings when biuld kernel with W=1:
> drivers/iio/common/st_sensors/st_sensors_trigger.c:69:13: warning: no 
> previous prototype
> for 'st_sensors_irq_handler' [-Wmissing-prototypes]
> drivers/iio/common/st_sensors/st_sensors_trigger.c:85:13: warning: no 
> previous prototype
> for 'st_sensors_irq_thread' [-Wmissing-prototypes]
>
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie 

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

Re: [PATCH 1/5] IA64-IRQ: Use kmalloc_array() in sn_irq_lh_init()

[walter harms]

Am 26.08.2016 20:02, schrieb SF Markus Elfring:
> From: Markus Elfring 
> Date: Fri, 26 Aug 2016 18:32:53 +0200
> 
> * A multiplication for the size determination of a memory allocation
>   indicated that an array data structure should be processed.
>   Thus use the corresponding function "kmalloc_array".
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Replace the specification of data structures by pointer dereferences
>   to make the corresponding size determination a bit safer according to
>   the Linux coding style convention.
> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/ia64/sn/kernel/irq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/ia64/sn/kernel/irq.c b/arch/ia64/sn/kernel/irq.c
> index 85d0951..c7f9eea 100644
> --- a/arch/ia64/sn/kernel/irq.c
> +++ b/arch/ia64/sn/kernel/irq.c
> @@ -474,12 +474,12 @@ void __init sn_irq_lh_init(void)
>  {
>   int i;
>  
> - sn_irq_lh = kmalloc(sizeof(struct list_head *) * NR_IRQS, GFP_KERNEL);
> + sn_irq_lh = kmalloc_array(NR_IRQS, sizeof(*sn_irq_lh), GFP_KERNEL);
>   if (!sn_irq_lh)
>   panic("SN PCI INIT: Failed to allocate memory for PCI init\n");
>  
>   for (i = 0; i < NR_IRQS; i++) {
> - sn_irq_lh[i] = kmalloc(sizeof(struct list_head), GFP_KERNEL);
> + sn_irq_lh[i] = kmalloc(*sn_irq_lh[i], GFP_KERNEL);

perhaps a sizeof(*sn_irq_lh[i]) is here intended ?

re,
 wh

>   if (!sn_irq_lh[i])
>   panic("SN PCI INIT: Failed IRQ memory allocation\n");
>  

[PATCH v2 0/8] mfd: axp20x: Add support for AXP806 PMIC

[Chen-Yu Tsai]

Hi everyone,

This is v2 of the AXP806 PMIC support series. The patch "regulator: core:
Try full range when adjusting regulators to constraints" has been dropped.
Other changes are inline in the patches.

This series adds support for X-Powers' AXP806 PMIC. This is the secondary
PMIC accompanying Allwinner's A80 SoC. For now, only the regulators are
supported. While the AXP806 supports standalone operation, no hardware
exists, so this will not be supported.

Patch 1 adds AXP806 to the axp20x bindings.

Patch 2 adds AXP806 support to the axp20x mfd driver.

Patch 3 adds AXP806 support to the axp20x regulator driver.

Patch 4 adds the unused SW switch output of the AXP809 PMIC on the A80
Optimus board. This was accidentally left out of the AXP809 series.

Patch 5 adds the unused SW switch output of the AXP809 PMIC on the
Cubieboard 4. This was accidentally left out of the AXP809 series.

Patch 6 enables AXP809 support on the A80 Optimus board.

Patch 7 enables AXP809 support on the Cubieboard 4.

Patch 8 disables EHCI1 on the A80 Optimus board.


Regards
ChenYu

Chen-Yu Tsai (8):
  mfd: axp20x: Add bindings for AXP806 PMIC
  mfd: axp20x: Add support for AXP806 PMIC
  regulator: axp20x: support AXP806 variant
  ARM: dts: sun9i: a80-optimus: Declare AXP809 SW regulator as unused
  ARM: dts: sun9i: cubieboard4: Declare AXP809 SW regulator as unused
  ARM: dts: sun9i: a80-optimus: Add AXP806 PMIC device node and
regulators
  ARM: dts: sun9i: cubieboard4: Add AXP806 PMIC device node and
regulators
  ARM: dts: sun9i: a80-optimus: Disable EHCI1

 Documentation/devicetree/bindings/mfd/axp20x.txt |  28 +-
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts  | 116 +
 arch/arm/boot/dts/sun9i-a80-optimus.dts  | 123 ++-
 drivers/mfd/axp20x-rsb.c |   1 +
 drivers/mfd/axp20x.c |  72 +
 drivers/regulator/axp20x-regulator.c | 118 --
 include/linux/mfd/axp20x.h   |  60 +++
 7 files changed, 507 insertions(+), 11 deletions(-)

-- 
2.9.3

[PATCH v2 4/8] ARM: dts: sun9i: a80-optimus: Declare AXP809 SW regulator as unused

[Chen-Yu Tsai]

The AXP809's SW (switch) regulator is unused on the A80 Optimus.
Add an empty node for it so that the OS can generate constraints.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1: none
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts 
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index fd874ded890e..caf0091e71ba 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -325,6 +325,10 @@
reg_rtc_ldo: rtc_ldo {
regulator-name = "vcc-rtc-vdd1v8-io";
};
+
+   sw {
+   /* unused */
+   };
};
};
 
-- 
2.9.3

[PATCH v2 8/8] ARM: dts: sun9i: a80-optimus: Disable EHCI1

[Chen-Yu Tsai]

EHCI1 provides an HSIC interface. This interface is exposed on the
board through two pins among the GPIO header.

With the PHY now powered up and responding, enabling the interface when
nothing is connected results in a lot of error messages:

usb 2-1: device descriptor read/64, error -71
usb 2-1: device descriptor read/64, error -71
usb 2-1: new high-speed USB device number 3 using ehci-platform
usb 2-1: device descriptor read/64, error -71
usb 2-1: device descriptor read/64, error -71
usb 2-1: new high-speed USB device number 4 using ehci-platform
usb 2-1: device not accepting address 4, error -71
usb 2-1: new high-speed USB device number 5 using ehci-platform
usb 2-1: device not accepting address 5, error -71
usb usb2-port1: unable to enumerate USB device

Disable it by default, but leave the entries in the board DTS.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1: none
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts 
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index d805cb50b5c8..ceb6ef15d669 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -112,7 +112,8 @@
 };
 
 &ehci1 {
-   status = "okay";
+   /* Enable if HSIC peripheral is connected */
+   status = "disabled";
 };
 
 &ehci2 {
@@ -484,7 +485,8 @@
 
 &usbphy2 {
phy-supply = <®_bldo4>;
-   status = "okay";
+   /* Enable if HSIC peripheral is connected */
+   status = "disabled";
 };
 
 &usbphy3 {
-- 
2.9.3

[PATCH v2 1/8] mfd: axp20x: Add bindings for AXP806 PMIC

[Chen-Yu Tsai]

This patch adds the basic and regulator bindings for the X-Powers AXP806
PMIC.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1: none
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 585a95546288..8f3ad9ab4637 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -10,7 +10,8 @@ axp809 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223", "x-powers,axp809"
+ "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
+ "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -47,7 +48,6 @@ Optional properties for DCDC regulators:
  probably makes sense for HiFi audio related
  applications that aren't battery constrained.
 
-
 AXP202/AXP209 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
@@ -86,6 +86,30 @@ LDO_IO1  : LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
 
+AXP806 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDCA  : DC-DC buck: vina-supply   : poly-phase capable
+DCDCB  : DC-DC buck: vinb-supply   : poly-phase capable
+DCDCC  : DC-DC buck: vinc-supply   : poly-phase capable
+DCDCD  : DC-DC buck: vind-supply   : poly-phase capable
+DCDCE  : DC-DC buck: vine-supply   : poly-phase capable
+ALDO1  : LDO   : aldoin-supply : shared supply
+ALDO2  : LDO   : aldoin-supply : shared supply
+ALDO3  : LDO   : aldoin-supply : shared supply
+BLDO1  : LDO   : bldoin-supply : shared supply
+BLDO2  : LDO   : bldoin-supply : shared supply
+BLDO3  : LDO   : bldoin-supply : shared supply
+BLDO4  : LDO   : bldoin-supply : shared supply
+CLDO1  : LDO   : cldoin-supply : shared supply
+CLDO2  : LDO   : cldoin-supply : shared supply
+CLDO3  : LDO   : cldoin-supply : shared supply
+SW : On/Off Switch : swin-supply
+
+Additionally, the AXP806 DC-DC regulators support poly-phase arrangements
+for higher output current. The possible groupings are: A+B, A+B+C, D+E.
+
 AXP809 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
-- 
2.9.3

[PATCH v2 3/8] regulator: axp20x: support AXP806 variant

[Chen-Yu Tsai]

The X-Powers AXP806 PMIC has a new set of buck and LDO regulators, and
also a switch. The buck regulators support teaming into multi-phase
groups, with A+B, A+B+C, D+E groupings.

Some registers controlling DCDC converter work settings are at different
offsets. Deal with them as well.

Add support for this new variant.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:

  - Use switch-case block in axp20x_is_polyphase_slave

---
 drivers/regulator/axp20x-regulator.c | 118 ---
 1 file changed, 111 insertions(+), 7 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 6d9ac76a772f..54382ef902c6 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,16 +244,64 @@ static const struct regulator_desc 
axp22x_drivevbus_regulator = {
.ops= &axp20x_ops_sw,
 };
 
-static const struct regulator_linear_range axp809_dcdc4_ranges[] = {
-   REGULATOR_LINEAR_RANGE(60, 0x0, 0x2f, 2),
-   REGULATOR_LINEAR_RANGE(180, 0x30, 0x38, 10),
+static const struct regulator_linear_range axp806_dcdca_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0x0, 0x32, 1),
+   REGULATOR_LINEAR_RANGE(112, 0x33, 0x47, 2),
 };
 
-static const struct regulator_linear_range axp809_dldo1_ranges[] = {
+static const struct regulator_linear_range axp806_dcdcd_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0x0, 0x2d, 2),
+   REGULATOR_LINEAR_RANGE(160, 0x2e, 0x3f, 10),
+};
+
+static const struct regulator_linear_range axp806_cldo2_ranges[] = {
REGULATOR_LINEAR_RANGE(70, 0x0, 0x1a, 10),
REGULATOR_LINEAR_RANGE(340, 0x1b, 0x1f, 20),
 };
 
+static const struct regulator_desc axp806_regulators[] = {
+   AXP_DESC_RANGES(AXP806, DCDCA, "dcdca", "vina", axp806_dcdca_ranges,
+   72, AXP806_DCDCA_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
+   BIT(0)),
+   AXP_DESC(AXP806, DCDCB, "dcdcb", "vinb", 1000, 2550, 50,
+AXP806_DCDCB_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(1)),
+   AXP_DESC_RANGES(AXP806, DCDCC, "dcdcc", "vinc", axp806_dcdca_ranges,
+   72, AXP806_DCDCC_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
+   BIT(2)),
+   AXP_DESC_RANGES(AXP806, DCDCD, "dcdcd", "vind", axp806_dcdcd_ranges,
+   64, AXP806_DCDCD_V_CTRL, 0x3f, AXP806_PWR_OUT_CTRL1,
+   BIT(3)),
+   AXP_DESC(AXP806, DCDCE, "dcdce", "vine", 1100, 3400, 100,
+AXP806_DCDCB_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(4)),
+   AXP_DESC(AXP806, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+AXP806_ALDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(5)),
+   AXP_DESC(AXP806, ALDO2, "aldo2", "aldoin", 700, 3400, 100,
+AXP806_ALDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(6)),
+   AXP_DESC(AXP806, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+AXP806_ALDO3_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(7)),
+   AXP_DESC(AXP806, BLDO1, "bldo1", "bldoin", 700, 1900, 100,
+AXP806_BLDO1_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(0)),
+   AXP_DESC(AXP806, BLDO2, "bldo2", "bldoin", 700, 1900, 100,
+AXP806_BLDO2_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(1)),
+   AXP_DESC(AXP806, BLDO3, "bldo3", "bldoin", 700, 1900, 100,
+AXP806_BLDO3_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(2)),
+   AXP_DESC(AXP806, BLDO4, "bldo4", "bldoin", 700, 1900, 100,
+AXP806_BLDO4_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(3)),
+   AXP_DESC(AXP806, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
+AXP806_CLDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(4)),
+   AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp806_cldo2_ranges,
+   32, AXP806_CLDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2,
+   BIT(5)),
+   AXP_DESC(AXP806, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
+AXP806_CLDO3_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(6)),
+   AXP_DESC_SW(AXP806, SW, "sw", "swin", AXP806_PWR_OUT_CTRL2, BIT(7)),
+};
+
+static const struct regulator_linear_range axp809_dcdc4_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0x0, 0x2f, 2),
+   REGULATOR_LINEAR_RANGE(180, 0x30, 0x38, 10),
+};
+
 static const struct regulator_desc axp809_regulators[] = {
AXP_DESC(AXP809, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
 AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(1)),
@@ -278,7 +326,7 @@ static const struct regulator_desc axp809_regulators[] = {
 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
-   AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp809_dldo1_ranges,
+   AXP_DESC

[PATCH v2 5/8] ARM: dts: sun9i: cubieboard4: Declare AXP809 SW regulator as unused

[Chen-Yu Tsai]

The AXP809's SW (switch) regulator is unused on the Cubieboard 4.
Add an empty node for it so that the OS can generate constraints.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1: none
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts 
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 04b014603659..910b29f0f0b5 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -253,6 +253,10 @@
reg_rtc_ldo: rtc_ldo {
regulator-name = "vcc-rtc-vdd1v8-io";
};
+
+   sw {
+   /* unused */
+   };
};
};
 
-- 
2.9.3

[PATCH v2 7/8] ARM: dts: sun9i: cubieboard4: Add AXP806 PMIC device node and regulators

[Chen-Yu Tsai]

The AXP806 PMIC is the secondary PMIC. It provides various supply
voltages for the SoC and other peripherals. The PMIC's interrupt
line is connected to NMI pin of the SoC.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:

  - Fixed up bldo* voltage constraints to match regulator voltage step.

---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 112 
 1 file changed, 112 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts 
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 910b29f0f0b5..439847acd41e 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -260,6 +260,118 @@
};
};
 
+   axp806: pmic@745 {
+   compatible = "x-powers,axp806";
+   reg = <0x745>;
+   interrupt-parent = <&nmi_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   bldoin-supply = <®_dcdce>;
+
+   regulators {
+   reg_s_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+   };
+
+   aldo2 {
+   /*
+* unused, but use a different name to
+* avoid name clash with axp809's aldo's
+*/
+   regulator-name = "s_aldo2";
+   };
+
+   aldo3 {
+   /*
+* unused, but use a different name to
+* avoid name clash with axp809's aldo's
+*/
+   regulator-name = "s_aldo3";
+   };
+
+   reg_bldo1: bldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <170>;
+   regulator-max-microvolt = <190>;
+   regulator-name = "vcc18-efuse-adc-display-csi";
+   };
+
+   reg_bldo2: bldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <170>;
+   regulator-max-microvolt = <190>;
+   regulator-name =
+   "vdd18-drampll-vcc18-pll-cpvdd";
+   };
+
+   bldo3 {
+   /* unused */
+   };
+
+   reg_bldo4: bldo4 {
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <130>;
+   regulator-name = "vcc12-hsic";
+   };
+
+   reg_cldo1: cldo1 {
+   /*
+* This was 3V in the original design, but
+* 3.3V is the recommended supply voltage
+* for the Ethernet PHY.
+*/
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-gmac-phy";
+   };
+
+   reg_cldo2: cldo2 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "afvcc-cam";
+   };
+
+   reg_cldo3: cldo3 {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io-wifi-codec-io2";
+   };
+
+   reg_dcdca: dcdca {
+   regulator-always-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-cpub";
+   };
+
+   reg_dcdcd: dcdcd {
+   regulator-always-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-vpu";
+   };
+
+   reg_dcdce: dcdce {
+  

[PATCH v2 6/8] ARM: dts: sun9i: a80-optimus: Add AXP806 PMIC device node and regulators

[Chen-Yu Tsai]

The AXP806 PMIC is the secondary PMIC. It provides various supply
voltages for the SoC and other peripherals. The PMIC's interrupt
line is connected to NMI pin of the SoC.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:

  - Fixed up bldo* voltage constraints to match regulator voltage step.

---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 113 
 1 file changed, 113 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts 
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index caf0091e71ba..d805cb50b5c8 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -332,6 +332,118 @@
};
};
 
+   axp806: pmic@745 {
+   compatible = "x-powers,axp806";
+   reg = <0x745>;
+   interrupt-parent = <&nmi_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   bldoin-supply = <®_dcdce>;
+
+   regulators {
+   reg_s_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+   };
+
+   aldo2 {
+   /*
+* unused, but use a different name to
+* avoid name clash with axp809's aldo's
+*/
+   regulator-name = "s_aldo2";
+   };
+
+   aldo3 {
+   /*
+* unused, but use a different name to
+* avoid name clash with axp809's aldo's
+*/
+   regulator-name = "s_aldo3";
+   };
+
+   reg_bldo1: bldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <170>;
+   regulator-max-microvolt = <190>;
+   regulator-name = "vcc18-efuse-adc-display-csi";
+   };
+
+   reg_bldo2: bldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <170>;
+   regulator-max-microvolt = <190>;
+   regulator-name =
+   "vdd18-drampll-vcc18-pll-cpvdd";
+   };
+
+   bldo3 {
+   /* unused */
+   };
+
+   reg_bldo4: bldo4 {
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <130>;
+   regulator-name = "vcc12-hsic";
+   };
+
+   reg_cldo1: cldo1 {
+   /*
+* This was 3V in the original design, but
+* 3.3V is the recommended supply voltage
+* for the Ethernet PHY.
+*/
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-gmac-phy";
+   };
+
+   reg_cldo2: cldo2 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "afvcc-cam";
+   };
+
+   reg_cldo3: cldo3 {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io-wifi-codec-io2";
+   };
+
+   reg_dcdca: dcdca {
+   regulator-always-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-cpub";
+   };
+
+   reg_dcdcd: dcdcd {
+   regulator-always-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-vpu";
+   };
+
+   reg_dcdce: dcdce {
+   regulator-a

[PATCH v2 2/8] mfd: axp20x: Add support for AXP806 PMIC

[Chen-Yu Tsai]

The X-Powers AXP806 is a new PMIC that is paired with Allwinner's A80
SoC, along with a master AXP809 PMIC.

This PMIC has a new register layout, and supports some functions not
seen in other X-Powers PMICs, such as master-slave mode, or having
multiple AXP806 PMICs on the same bus with address space extension,
or supporting both I2C and RSB mode. I2C has not been tested.

This patch adds support for the interrupts of the PMIC. A regulator
sub-device is enabled, but actual regulator support will come in a
later patch.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1: none
---
 drivers/mfd/axp20x-rsb.c   |  1 +
 drivers/mfd/axp20x.c   | 72 ++
 include/linux/mfd/axp20x.h | 60 ++
 3 files changed, 133 insertions(+)

diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index a407527bcd09..a732cb50bcff 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
 
 static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+   { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
{ },
 };
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index fd80b0981f0f..96102753847f 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -38,6 +38,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+   "AXP806",
"AXP809",
 };
 
@@ -129,6 +130,27 @@ static const struct regmap_access_table 
axp288_volatile_table = {
.n_yes_ranges   = ARRAY_SIZE(axp288_volatile_ranges),
 };
 
+static const struct regmap_range axp806_writeable_ranges[] = {
+   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_DATACACHE(3)),
+   regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL),
+   regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN),
+   regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
+};
+
+static const struct regmap_range axp806_volatile_ranges[] = {
+   regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
+};
+
+static const struct regmap_access_table axp806_writeable_table = {
+   .yes_ranges = axp806_writeable_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(axp806_writeable_ranges),
+};
+
+static const struct regmap_access_table axp806_volatile_table = {
+   .yes_ranges = axp806_volatile_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(axp806_volatile_ranges),
+};
+
 static struct resource axp152_pek_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
@@ -278,6 +300,15 @@ static const struct regmap_config axp288_regmap_config = {
.cache_type = REGCACHE_RBTREE,
 };
 
+static const struct regmap_config axp806_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .wr_table   = &axp806_writeable_table,
+   .volatile_table = &axp806_volatile_table,
+   .max_register   = AXP806_VREF_TEMP_WARN_L,
+   .cache_type = REGCACHE_RBTREE,
+};
+
 #define INIT_REGMAP_IRQ(_variant, _irq, _off, _mask)   \
[_variant##_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
 
@@ -409,6 +440,21 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,5, 1),
 };
 
+static const struct regmap_irq axp806_regmap_irqs[] = {
+   INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1,  0, 0),
+   INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2,  0, 1),
+   INIT_REGMAP_IRQ(AXP806, DCDCA_V_LOW,0, 3),
+   INIT_REGMAP_IRQ(AXP806, DCDCB_V_LOW,0, 4),
+   INIT_REGMAP_IRQ(AXP806, DCDCC_V_LOW,0, 5),
+   INIT_REGMAP_IRQ(AXP806, DCDCD_V_LOW,0, 6),
+   INIT_REGMAP_IRQ(AXP806, DCDCE_V_LOW,0, 7),
+   INIT_REGMAP_IRQ(AXP806, PWROK_LONG, 1, 0),
+   INIT_REGMAP_IRQ(AXP806, PWROK_SHORT,1, 1),
+   INIT_REGMAP_IRQ(AXP806, WAKEUP, 1, 4),
+   INIT_REGMAP_IRQ(AXP806, PWROK_FALL, 1, 5),
+   INIT_REGMAP_IRQ(AXP806, PWROK_RISE, 1, 6),
+};
+
 static const struct regmap_irq axp809_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP809, ACIN_OVER_V,0, 7),
INIT_REGMAP_IRQ(AXP809, ACIN_PLUGIN,0, 6),
@@ -494,6 +540,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip 
= {
 
 };
 
+static const struct regmap_irq_chip axp806_regmap_irq_chip = {
+   .name   = "axp806",
+   .status_base= AXP20X_IRQ1_STATE,
+   .ack_base   = AXP20X_IRQ1_STATE,
+   .mask_base  = AXP20X_IRQ1_EN,
+   .mask_invert= true,
+   .ini

Re: [PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed

[Leizhen (ThunderTown)]

On 2016/8/26 20:47, Will Deacon wrote:
> On Wed, Aug 24, 2016 at 03:44:44PM +0800, Zhen Lei wrote:
>> numa_init(of_numa_init) may returned error because of numa configuration
>> error. So "No NUMA configuration found" is inaccurate. In fact, specific
>> configuration error information should be immediately printed by the
>> testing branch.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/mm/numa.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 5bb15ea..d97c6e2 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -335,8 +335,10 @@ static int __init numa_init(int (*init_func)(void))
>>  if (ret < 0)
>>  return ret;
>>
>> -if (nodes_empty(numa_nodes_parsed))
>> +if (nodes_empty(numa_nodes_parsed)) {
>> +pr_info("No NUMA configuration found\n");
>>  return -EINVAL;
> 
> Hmm, but dummy_numa_init calls node_set(nid, numa_nodes_parsed) for a
> completely artificial setup, created by adding all memblocks to node 0,
> so this new message will be suppressed even though things really did go
> wrong.
It will be printed by the former: numa_init(of_numa_init)

> 
> In that case, don't we want to print *something* (like we do today in
> dummy_numa_init) but maybe not "No NUMA configuration found"? What
> exactly do you find inaccurate about the current message?
For example:
[0.00] NUMA: No distance-matrix property in distance-map
[0.00] No NUMA configuration found

So if of_numa_init or arm64_acpi_numa_init returned error, because of
some numa configuration error had been found, it's no good to print "No NUMA 
...".

> 
> Will
> 
> .
> 

[PATCH] checkkconfigsymbols.py: avoid shell injection

[Valentin Rothberg]

Use subprocess and set shell to False to avoid potential shell
injections.

Reported-by: Bernd Dietzel 
Signed-off-by: Valentin Rothberg 
---
Note that I don't see how it could be exploited currently.  There is no
user input used in the execute() function.  I see the patch more as a
preventive fix than something urgent.

 scripts/checkkconfigsymbols.py | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/scripts/checkkconfigsymbols.py b/scripts/checkkconfigsymbols.py
index b140fc9018b1..0cae73b5c925 100755
--- a/scripts/checkkconfigsymbols.py
+++ b/scripts/checkkconfigsymbols.py
@@ -2,7 +2,7 @@
 
 """Find Kconfig symbols that are referenced but not defined."""
 
-# (c) 2014-2015 Valentin Rothberg 
+# (c) 2014-2016 Valentin Rothberg 
 # (c) 2014 Stefan Hengelein 
 #
 # Licensed under the terms of the GNU GPL License version 2
@@ -12,6 +12,7 @@ import difflib
 import os
 import re
 import signal
+import subprocess
 import sys
 from multiprocessing import Pool, cpu_count
 from optparse import OptionParser
@@ -222,10 +223,11 @@ def red(string):
 
 def execute(cmd):
 """Execute %cmd and return stdout.  Exit in case of error."""
-pop = Popen(cmd, stdout=PIPE, stderr=STDOUT, shell=True)
-(stdout, _) = pop.communicate()  # wait until finished
-if pop.returncode != 0:
-sys.exit(stdout)
+try:
+cmdlist = cmd.split(" ")
+stdout = subprocess.check_output(cmdlist, stderr=STDOUT, shell=False)
+except subprocess.CalledProcessError as fail:
+exit("Failed to execute %s\n%s" % (cmd, fail))
 return stdout
 
 
-- 
2.9.3

Re: [PATCH] bdev: fix NULL pointer dereference in sync()/close() race

[Rabin Vincent]

On Sat, Aug 27, 2016 at 09:07:28AM +0200, Vegard Nossum wrote:
> I got this with syzkaller:
> 
> general protection fault:  [#1] PREEMPT SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> CPU: 0 PID: 11941 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
> task: 880110762cc0 task.stack: 88010229
> RIP: 0010:[]  [] 
> blk_get_backing_dev_info+0x4a/0x70
> RSP: 0018:880102297cd0  EFLAGS: 00010202
> RAX: dc00 RBX:  RCX: c9bb4000
> RDX: 0097 RSI:  RDI: 04b8
> RBP: 880102297cd8 R08:  R09: 0001
> R10:  R11: 0001 R12: 88011a010a90
> R13: 88011a594568 R14: 88011a010890 R15: 7fff
> FS:  7f2445174700() GS:88011aa0() 
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 200047c8 CR3: 000107eb5000 CR4: 06f0
> DR0: 001e DR1: 001e DR2: 
> DR3:  DR6: 0ff0 DR7: 0600
> Stack:
>  110020452f9e 880102297db8 81508daa 
>  41b58ab3 844e89e1 81508b30 ed0020452001
>  7fff   7fff
> Call Trace:
>  [] __filemap_fdatawrite_range+0x27a/0x2e0
>  [] ? filemap_check_errors+0xe0/0xe0
>  [] ? preempt_schedule+0x27/0x30
>  [] ? ___preempt_schedule+0x16/0x18
>  [] filemap_fdatawrite+0x26/0x30
>  [] fdatawrite_one_bdev+0x50/0x70
>  [] iterate_bdevs+0x194/0x210
>  [] ? fdatawait_one_bdev+0x70/0x70
>  [] ? sync_filesystem+0x240/0x240
>  [] sys_sync+0xce/0x160
>  [] ? sync_filesystem+0x240/0x240
>  [] ? exit_to_usermode_loop+0x190/0x190
>  [] ? __context_tracking_exit.part.4+0x3a/0x1e0
>  [] do_syscall_64+0x1c4/0x4e0
>  [] entry_SYSCALL64_slow_path+0x25/0x25
> Code: 89 fa 48 c1 ea 03 80 3c 02 00 75 35 48 8b 9b e0 00 00 00 48 b8 00 
> 00 00 00 00 fc ff df 48 8d bb b8 04 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 
> 75 17 48 8b 83 b8 04 00 00 5b 5d 48 05 10 02 00 00
> RIP  [] blk_get_backing_dev_info+0x4a/0x70
>  RSP 
> 
> The problem is that sync() calls down to blk_get_backing_dev_info()
> without necessarily having the block device opened (if it races with
> another process doing close()):
> 
> /**
>  * blk_get_backing_dev_info - get the address of a queue's 
> backing_dev_info
>  * @bdev:   device
>  *
>  * Locates the passed device's request queue and returns the address of 
> its
>  * backing_dev_info.  This function can only be called if @bdev is opened 
>  <
>  * and the return value is never NULL.
>  */
> struct backing_dev_info *blk_get_backing_dev_info(struct block_device 
> *bdev)
> {
> struct request_queue *q = bdev_get_queue(bdev);
> 
> return &q->backing_dev_info;
> }
> 
> bdev_get_queue() crashes on dereferencing bdev->bd_disk->queue because
> ->bd_disk was set to NULL when close() reached __blkdev_put().
> 
> Taking bdev->bd_mutex and checking bdev->bd_disk actually seems to be a
> reliable test of whether it's safe to call filemap_fdatawrite() for the
> block device inode and completely fixes the crash for me.
> 
> What I don't like about this patch is that it simply skips block devices
> which we don't have any open file descriptors for. That seems wrong to
> me because sync() should do writeback on (and wait for) _all_ devices,
> not just the ones that we happen to have an open file descriptor for.
> Imagine if we opened a device, wrote a lot of data to it, closed it,
> called sync(), and sync() returns. Now we should be guaranteed the data
> was written, but I'm not sure we are in this case. But maybe I've
> misunderstood how the writeback mechanism works.
> 
> Another ugly thing is that we're now holding a new mutex over a
> potentially big chunk of code (everything that happens inside
> filemap_fdatawrite()). The only thing I can say is that it seems to
> work here.
> 
> I have a reproducer that reliably triggers the problem in ~2 seconds so
> I can easily test other proposed fixes if there are any. I would also be
> happy to submit a new patch with some guidance on the Right Way to fix
> this.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Vegard Nossum 

Don't know what's the right fix, but I posted a slightly different one
for the same crash some months ago:
https://patchwork.kernel.org/patch/8556941/

Re: [PATCH v7 08/14] arm64: numa: Use pr_fmt()

[Leizhen (ThunderTown)]

On 2016/8/26 20:54, Will Deacon wrote:
> On Wed, Aug 24, 2016 at 03:44:47PM +0800, Zhen Lei wrote:
>> From: Kefeng Wang 
>>
>> Use pr_fmt to prefix kernel output, and remove duplicated msg
>> of NUMA turned off.
>>
>> Signed-off-by: Kefeng Wang 
>> ---
>>  arch/arm64/mm/numa.c | 40 
>>  1 file changed, 20 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index d97c6e2..7b73808 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -17,6 +17,8 @@
>>   * along with this program.  If not, see .
>>   */
>>
>> +#define pr_fmt(fmt) "numa: " fmt
> 
> Shouldn't this be uppercase for consistency with the existing code and
> the code in places like drivers/of/of_numa.c?
OK, I will change it to "NUMA: ".

> 
>>  #include 
>>  #include 
>>  #include 
>> @@ -38,10 +40,9 @@ static __init int numa_parse_early_param(char *opt)
>>  {
>>  if (!opt)
>>  return -EINVAL;
>> -if (!strncmp(opt, "off", 3)) {
>> -pr_info("%s\n", "NUMA turned off");
>> +if (!strncmp(opt, "off", 3))
>>  numa_off = true;
>> -}
>> +
>>  return 0;
>>  }
>>  early_param("numa", numa_parse_early_param);
>> @@ -110,7 +111,7 @@ static void __init setup_node_to_cpumask_map(void)
>>  set_cpu_numa_node(cpu, NUMA_NO_NODE);
>>
>>  /* cpumask_of_node() will now work */
>> -pr_debug("NUMA: Node to cpumask map for %d nodes\n", nr_node_ids);
>> +pr_debug("Node to cpumask map for %d nodes\n", nr_node_ids);
>>  }
>>
>>  /*
>> @@ -145,13 +146,13 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>>
>>  ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
>>  if (ret < 0) {
>> -pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node 
>> %d\n",
>> +pr_err("memblock [0x%llx - 0x%llx] failed to add on node %d\n",
>>  start, (end - 1), nid);
>>  return ret;
>>  }
>>
>>  node_set(nid, numa_nodes_parsed);
>> -pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
>> +pr_info("Adding memblock [0x%llx - 0x%llx] on node %d\n",
>>  start, (end - 1), nid);
>>  return ret;
>>  }
>> @@ -166,19 +167,18 @@ static void __init setup_node_data(int nid, u64 
>> start_pfn, u64 end_pfn)
>>  void *nd;
>>  int tnid;
>>
>> -pr_info("NUMA: Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
>> -nid, start_pfn << PAGE_SHIFT,
>> -(end_pfn << PAGE_SHIFT) - 1);
>> +pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
>> +nid, start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
>>
>>  nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
>>  nd = __va(nd_pa);
>>
>>  /* report and initialize */
>> -pr_info("NUMA: NODE_DATA [mem %#010Lx-%#010Lx]\n",
>> +pr_info("  NODE_DATA [mem %#010Lx-%#010Lx]\n",
> 
> Why are you adding leading whitespace?
Kefeng Wang said that just in order to make the final print info looks more 
clear.

I will remove the leading whitespace in v8.

> 
>>  nd_pa, nd_pa + nd_size - 1);
>>  tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
>>  if (tnid != nid)
>> -pr_info("NUMA: NODE_DATA(%d) on node %d\n", nid, tnid);
>> +pr_info("NODE_DATA(%d) on node %d\n", nid, tnid);
> 
> 
> Same here.
> 
>>  node_data[nid] = nd;
>>  memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
>> @@ -235,8 +235,7 @@ static int __init numa_alloc_distance(void)
>>  numa_distance[i * numa_distance_cnt + j] = i == j ?
>>  LOCAL_DISTANCE : REMOTE_DISTANCE;
>>
>> -pr_debug("NUMA: Initialized distance table, cnt=%d\n",
>> -numa_distance_cnt);
>> +pr_debug("Initialized distance table, cnt=%d\n", numa_distance_cnt);
>>
>>  return 0;
>>  }
>> @@ -257,20 +256,20 @@ static int __init numa_alloc_distance(void)
>>  void __init numa_set_distance(int from, int to, int distance)
>>  {
>>  if (!numa_distance) {
>> -pr_warn_once("NUMA: Warning: distance table not allocated 
>> yet\n");
>> +pr_warn_once("Warning: distance table not allocated yet\n");
>>  return;
>>  }
>>
>>  if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
>>  from < 0 || to < 0) {
>> -pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d 
>> to=%d distance=%d\n",
>> +pr_warn_once("Warning: node ids are out of bound, from=%d to=%d 
>> distance=%d\n",
>>  from, to, distance);
>>  return;
>>  }
>>
>>  if ((u8)distance != distance ||
>>  (from == to && distance != LOCAL_DISTANCE)) {
>> -pr_warn_once("NUMA: Warning: invalid distance parameter, 
>> from=%d to=%d distance=%d\n",
>> +pr_warn_once("Wa

Re: [PATCH 3.10 099/180] fix d_walk()/non-delayed __d_free() race

[Willy Tarreau]

Greg, Jiri,

I checked Jari's explanation below and found that v3.14.77 and v3.12.62
are missing the same fix as 3.10. In fact Al's original commit 3d56c25
("fix d_walk()/non-delayed __d_free() race") used to mention to check 
this __d_materialise_dentry() function in the Cc: stable line, but this
got lost during the backports.

Normally all of our 3 kernels need to apply the following patch that
Ben correctly put in 3.16 and 3.2. I'm fixing the backport in 3.10.103
right now.

Cheers,
Willy

diff --git a/fs/dcache.c b/fs/dcache.c
index 2a808fb..2d0b9d2 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2401,6 +2401,7 @@ static void __d_materialise_dentry(struct dentry *dentry, 
struct dentry *anon)
switch_names(dentry, anon);
swap(dentry->d_name.hash, anon->d_name.hash);
 
+   dentry->d_flags |= DCACHE_RCUACCESS;
dentry->d_parent = dentry;
list_del_init(&dentry->d_child);
anon->d_parent = dparent;


On Mon, Aug 22, 2016 at 04:56:57PM +0300, Jari Ruusu wrote:
> This patch for 3.10 branch appears to be missing one important
> 
> +   dentry->d_flags |= DCACHE_RCUACCESS;
> 
> in fs/dcache.c __d_materialise_dentry() function. When Ben Hutchings
> backported Al Viro's original fix to stable branches that he maintains,
> he added that one additional line to both 3.2 and 3.16 branches. Please
> consider including that additional one line fix for 3.10 stable branch
> also.
> 
> 
> Ben Hutchings said this on his 3.2.82-rc1 patch:
> [bwh: Backported to 3.2:
>  - Adjust context
>  - Also set the flag in __d_materialise_dentry())]
> 
> http://marc.info/?l=linux-kernel&m=147117565612275&w=2
> 
> 
> Ben Hutchings said this on his 3.16.37-rc1 patch:
> [bwh: Backported to 3.16:
>  - Adjust context
>  - Also set the flag in __d_materialise_dentry())]
> 
> http://marc.info/?l=linux-kernel&m=147117433412006&w=2
> 
> 
> Also mentioned by Sasha Levin on 3.18 and 4.1 commits:
> Cc: sta...@vger.kernel.org # v3.2+ (and watch out for 
> __d_materialise_dentry())
> 
> http://marc.info/?l=linux-stable-commits&m=146648034410827&w=2
> http://marc.info/?l=linux-stable-commits&m=146647471009771&w=2
> 
> -- 
> Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 F189

Re: [PATCH] bdev: fix NULL pointer dereference in sync()/close() race

[Vegard Nossum]

On 08/27/2016 11:03 AM, Rabin Vincent wrote:

On Sat, Aug 27, 2016 at 09:07:28AM +0200, Vegard Nossum wrote:

I got this with syzkaller:

general protection fault:  [#1] PREEMPT SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
CPU: 0 PID: 11941 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
task: 880110762cc0 task.stack: 88010229
RIP: 0010:[]  [] 
blk_get_backing_dev_info+0x4a/0x70
RSP: 0018:880102297cd0  EFLAGS: 00010202
RAX: dc00 RBX:  RCX: c9bb4000
RDX: 0097 RSI:  RDI: 04b8
RBP: 880102297cd8 R08:  R09: 0001
R10:  R11: 0001 R12: 88011a010a90
R13: 88011a594568 R14: 88011a010890 R15: 7fff
FS:  7f2445174700() GS:88011aa0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 200047c8 CR3: 000107eb5000 CR4: 06f0
DR0: 001e DR1: 001e DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Stack:
 110020452f9e 880102297db8 81508daa 
 41b58ab3 844e89e1 81508b30 ed0020452001
 7fff   7fff
Call Trace:
 [] __filemap_fdatawrite_range+0x27a/0x2e0
 [] ? filemap_check_errors+0xe0/0xe0
 [] ? preempt_schedule+0x27/0x30
 [] ? ___preempt_schedule+0x16/0x18
 [] filemap_fdatawrite+0x26/0x30
 [] fdatawrite_one_bdev+0x50/0x70
 [] iterate_bdevs+0x194/0x210
 [] ? fdatawait_one_bdev+0x70/0x70
 [] ? sync_filesystem+0x240/0x240
 [] sys_sync+0xce/0x160
 [] ? sync_filesystem+0x240/0x240
 [] ? exit_to_usermode_loop+0x190/0x190
 [] ? __context_tracking_exit.part.4+0x3a/0x1e0
 [] do_syscall_64+0x1c4/0x4e0
 [] entry_SYSCALL64_slow_path+0x25/0x25
Code: 89 fa 48 c1 ea 03 80 3c 02 00 75 35 48 8b 9b e0 00 00 00 48 b8 00 00 00 00 
00 fc ff df 48 8d bb b8 04 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 17 48 8b 
83 b8 04 00 00 5b 5d 48 05 10 02 00 00
RIP  [] blk_get_backing_dev_info+0x4a/0x70
 RSP 

The problem is that sync() calls down to blk_get_backing_dev_info()
without necessarily having the block device opened (if it races with
another process doing close()):

/**
 * blk_get_backing_dev_info - get the address of a queue's backing_dev_info
 * @bdev:   device
 *
 * Locates the passed device's request queue and returns the address of its
 * backing_dev_info.  This function can only be called if @bdev is opened  
<
 * and the return value is never NULL.
 */
struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev)
{
struct request_queue *q = bdev_get_queue(bdev);

return &q->backing_dev_info;
}

bdev_get_queue() crashes on dereferencing bdev->bd_disk->queue because
->bd_disk was set to NULL when close() reached __blkdev_put().

Taking bdev->bd_mutex and checking bdev->bd_disk actually seems to be a
reliable test of whether it's safe to call filemap_fdatawrite() for the
block device inode and completely fixes the crash for me.

What I don't like about this patch is that it simply skips block devices
which we don't have any open file descriptors for. That seems wrong to
me because sync() should do writeback on (and wait for) _all_ devices,
not just the ones that we happen to have an open file descriptor for.
Imagine if we opened a device, wrote a lot of data to it, closed it,
called sync(), and sync() returns. Now we should be guaranteed the data
was written, but I'm not sure we are in this case. But maybe I've
misunderstood how the writeback mechanism works.

Another ugly thing is that we're now holding a new mutex over a
potentially big chunk of code (everything that happens inside
filemap_fdatawrite()). The only thing I can say is that it seems to
work here.

I have a reproducer that reliably triggers the problem in ~2 seconds so
I can easily test other proposed fixes if there are any. I would also be
happy to submit a new patch with some guidance on the Right Way to fix
this.

Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum 


Don't know what's the right fix, but I posted a slightly different one
for the same crash some months ago:
https://patchwork.kernel.org/patch/8556941/



Ah, I'm sorry, I didn't see that.

Your patch is 100% identical to my first attempt at a fix and I can
confirm that it also fixes the problem for me.

If people who are more savvy in block/fs code could ack the locking bits
I think we should apply the patch ASAP because it's an easy local DOS if
you have (open/read) access to any block device.


Vegard

Re: [RFC PATCH v3 0/2] arm64/hugetlb: enable gigantic page

[Yisheng Xie]

Hi Andrew,
Can this patchset be merged? Or have any other comments?

Thanks
Xie Yisheng

On 2016/8/26 18:26, Will Deacon wrote:
> On Mon, Aug 22, 2016 at 09:20:02PM +0800, Xie Yisheng wrote:
>>
>> Xie Yisheng (2):
>>   mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
>>   arm64 Kconfig: Select gigantic page
>>
> 
> I assume you plan to merge this via -mm/akpm, given that Catalin has
> acked the arm64 part?
> 
Yes, however, it seems still not merged right now.

> Will
> 
> .
> 

MFC: different h264 profile and level output the same size encoded result

[Randy Li]

Hi:

  I have been reported that the setting the profile, level and bitrate 
through the v4l2 extra controls would not make the encoded result 
different. I tried it recently, it is true. Although the h264 parser 
would tell me the result have been applied as different h264 profile and 
level, but size is the same.


You may try this in Gstreamer.

gst-launch-1.0 -v \
videotestsrc num-buffers=500 ! video/x-raw, width=1920,height=1080 ! \
videoconvert ! \
v4l2video4h264enc 
extra-controls="controls,h264_profile=1,video_bitrate=100;" ! \

h264parse ! matroskamux ! filesink location=/tmp/1.mkv

Is there any way to reduce the size of MFC encoded data?

Re: kernel BUG at net/unix/garbage.c:149!"

[Miklos Szeredi]

On Wed, Aug 24, 2016 at 11:40 PM, Hannes Frederic Sowa
 wrote:
> On 24.08.2016 16:24, Nikolay Borisov wrote:
>> Hello,
>>
>> I hit the following BUG:
>>
>> [1851513.239831] [ cut here ]
>> [1851513.240079] kernel BUG at net/unix/garbage.c:149!
>> [1851513.240313] invalid opcode:  [#1] SMP
>> [1851513.248320] CPU: 37 PID: 11683 Comm: nginx Tainted: G   O
>> 4.4.14-clouder3 #26
>> [1851513.248719] Hardware name: Supermicro X10DRi/X10DRi, BIOS 1.1 04/14/2015
>> [1851513.248966] task: 883b0f6f ti: 880189cf task.ti: 
>> 880189cf
>> [1851513.249361] RIP: 0010:[]  [] 
>> unix_notinflight+0x8d/0x90
>> [1851513.249846] RSP: 0018:880189cf3cf8  EFLAGS: 00010246
>> [1851513.250082] RAX: 883b05491968 RBX: 883b05491680 RCX: 
>> 8807f9967330
>> [1851513.250476] RDX: 0001 RSI: 882e6d8bae00 RDI: 
>> 82073f10
>> [1851513.250886] RBP: 880189cf3d08 R08: 880cbc70e200 R09: 
>> 00018021
>> [1851513.251280] R10: 883fff3b9dc0 R11: ea0032f1c380 R12: 
>> 883fbaf5
>> [1851513.251674] R13: 815f6354 R14: 881a7c77b140 R15: 
>> 881a7c7792c0
>> [1851513.252083] FS:  7f4f19573720() GS:883fff3a() 
>> knlGS:
>> [1851513.252481] CS:  0010 DS:  ES:  CR0: 80050033
>> [1851513.252717] CR2: 013062d8 CR3: 001712f32000 CR4: 
>> 001406e0
>> [1851513.253116] Stack:
>> [1851513.253345]   880189cf3d40 880189cf3d28 
>> 815f4383
>> [1851513.254022]  8839ee11a800 8839ee11a800 880189cf3d60 
>> 815f53b8
>> [1851513.254685]   883406788de0  
>> 
>> [1851513.255360] Call Trace:
>> [1851513.255594]  [] unix_detach_fds.isra.19+0x43/0x50
>> [1851513.255851]  [] unix_destruct_scm+0x48/0x80
>> [1851513.256090]  [] skb_release_head_state+0x4f/0xb0
>> [1851513.256328]  [] skb_release_all+0x12/0x30
>> [1851513.256564]  [] kfree_skb+0x32/0xa0
>> [1851513.256810]  [] unix_release_sock+0x1e4/0x2c0
>> [1851513.257046]  [] unix_release+0x20/0x30
>> [1851513.257284]  [] sock_release+0x1f/0x80
>> [1851513.257521]  [] sock_close+0x12/0x20
>> [1851513.257769]  [] __fput+0xea/0x1f0
>> [1851513.258005]  [] fput+0xe/0x10
>> [1851513.258244]  [] task_work_run+0x7f/0xb0
>> [1851513.258488]  [] exit_to_usermode_loop+0xc0/0xd0
>> [1851513.258728]  [] syscall_return_slowpath+0x80/0xf0
>> [1851513.258983]  [] int_ret_from_sys_call+0x25/0x9f
>> [1851513.259222] Code: 7e 5b 41 5c 5d c3 48 8b 8b e8 02 00 00 48 8b 93 f0 02 
>> 00 00 48 89 51 08 48 89 0a 48 89 83 e8 02 00 00 48 89 83 f0 02 00 00 eb b8 
>> <0f> 0b 90 0f 1f 44 00 00 55 48 c7 c7 10 3f 07 82 48 89 e5 41 54
>> [1851513.268473] RIP  [] unix_notinflight+0x8d/0x90
>> [1851513.268793]  RSP 
>>
>> That's essentially BUG_ON(list_empty(&u->link));
>>
>> I see that all the code involving the ->link member hasn't really been
>> touched since it was introduced in 2007. So this must be a latent bug.
>> This is the first time I've observed it. The state
>> of the struct unix_sock can be found here http://sprunge.us/WCMW . Evidently,
>> there are no inflight sockets.

Weird.  If it was the BUG_ON(!list_empty(&u->link)) I'd understand,
because the code in scan children looks fishy: what prevents "embryos"
from fledging to full socket status and going in-flight?

But this one, I cannot imagine any scenario.

Can we have access to the crashdump?

Thanks,
Miklos

Re: [PATCH v7 09/14] arm64/numa: support HAVE_SETUP_PER_CPU_AREA

[Leizhen (ThunderTown)]

On 2016/8/26 21:28, Will Deacon wrote:
> On Wed, Aug 24, 2016 at 03:44:48PM +0800, Zhen Lei wrote:
>> To make each percpu area allocated from its local numa node. Without this
>> patch, all percpu areas will be allocated from the node which cpu0 belongs
>> to.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/Kconfig   |  8 
>>  arch/arm64/mm/numa.c | 55 
>> 
>>  2 files changed, 63 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index bc3f00f..2815af6 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -603,6 +603,14 @@ config USE_PERCPU_NUMA_NODE_ID
>>  def_bool y
>>  depends on NUMA
>>
>> +config HAVE_SETUP_PER_CPU_AREA
>> +def_bool y
>> +depends on NUMA
>> +
>> +config NEED_PER_CPU_EMBED_FIRST_CHUNK
>> +def_bool y
>> +depends on NUMA
> 
> Why do we need this? Is it purely about using block mappings for the
> pcpu area?
Without NEED_PER_CPU_EMBED_FIRST_CHUNK, Link error will be reported.

#if defined(CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK) || \
!defined(CONFIG_HAVE_SETUP_PER_CPU_AREA)
#define BUILD_EMBED_FIRST_CHUNK
#endif

#if defined(BUILD_EMBED_FIRST_CHUNK)
//pcpu_embed_first_chunk definition
#endif

setup_per_cpu_areas -->pcpu_embed_first_chunk


> 
>>  source kernel/Kconfig.preempt
>>  source kernel/Kconfig.hz
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 7b73808..5e44ad1 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -26,6 +26,7 @@
>>  #include 
>>
>>  #include 
>> +#include 
>>
>>  struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
>>  EXPORT_SYMBOL(node_data);
>> @@ -131,6 +132,60 @@ void __init early_map_cpu_to_node(unsigned int cpu, int 
>> nid)
>>  cpu_to_node_map[cpu] = nid;
>>  }
>>
>> +#ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
>> +unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
>> +EXPORT_SYMBOL(__per_cpu_offset);
>> +
>> +static int __init early_cpu_to_node(int cpu)
>> +{
>> +return cpu_to_node_map[cpu];
>> +}
>> +
>> +static int __init pcpu_cpu_distance(unsigned int from, unsigned int to)
>> +{
>> +if (early_cpu_to_node(from) == early_cpu_to_node(to))
>> +return LOCAL_DISTANCE;
>> +else
>> +return REMOTE_DISTANCE;
>> +}
> 
> Is it too early to use __node_distance here?
Good, we can directly use node_distance, thanks.

> 
>> +static void * __init pcpu_fc_alloc(unsigned int cpu, size_t size,
>> +   size_t align)
>> +{
>> +int nid = early_cpu_to_node(cpu);
>> +
>> +return  memblock_virt_alloc_try_nid(size, align,
>> +__pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, nid);
>> +}
>> +
>> +static void __init pcpu_fc_free(void *ptr, size_t size)
>> +{
>> +memblock_free_early(__pa(ptr), size);
>> +}
>> +
>> +void __init setup_per_cpu_areas(void)
>> +{
>> +unsigned long delta;
>> +unsigned int cpu;
>> +int rc;
>> +
>> +/*
>> + * Always reserve area for module percpu variables.  That's
>> + * what the legacy allocator did.
>> + */
>> +rc = pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
>> +PERCPU_DYNAMIC_RESERVE, PAGE_SIZE,
>> +pcpu_cpu_distance,
>> +pcpu_fc_alloc, pcpu_fc_free);
>> +if (rc < 0)
>> +panic("Failed to initialize percpu areas.");
>> +
>> +delta = (unsigned long)pcpu_base_addr - (unsigned long)__per_cpu_start;
>> +for_each_possible_cpu(cpu)
>> +__per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
>> +}
>> +#endif
> 
> It's a pity that this is practically identical to PowerPC. Ideally, there
> would be definitions of this initialisation gunk in the core code that
> could be reused across architectures.
But these are different from other ARCHs, except PPC.

I originally want to put it into driver/of/of_numa.c, but now the ACPI NUMA is
coming up, so I don't known where.

> 
> Will
> 
> .
> 

Re: [zer0...@yahoo.com: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master]

[Kirill Marinushkin]

> David, here's a bug report with reproducer that was sent to the
> oss-security mailing list for some unknown reason earlier today.
> 
> Any ideas?

The problem is in the wrong RNG dependency.
I submitted a patch to fix the behaviour, you can find it by subject:
[PATCH] KEYS: fix big_key dependency

Re: [PATCH v7 10/14] arm64/numa: define numa_distance as array to simplify code

[Leizhen (ThunderTown)]

On 2016/8/26 23:29, Will Deacon wrote:
> On Wed, Aug 24, 2016 at 03:44:49PM +0800, Zhen Lei wrote:
>> 1. MAX_NUMNODES is base on CONFIG_NODES_SHIFT, the default value of the
>>latter is very small now.
>> 2. Suppose the default value of MAX_NUMNODES is enlarged to 64, so the
>>size of numa_distance is 4K, it's still acceptable if run the Image
>>on other processors.
>> 3. It will make function __node_distance quicker than before.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/include/asm/numa.h |  1 -
>>  arch/arm64/mm/numa.c  | 74 
>> +++
>>  2 files changed, 5 insertions(+), 70 deletions(-)
> 
> I fail to see the advantages of this patch. Do you have some compelling
> performance figures or something?

We can only put numa_distance_cnt on one node, so for the cpus of other nodes 
to access it should
spend more time. I have not tested how many can be improved yet.

I will try to get some data next week.

> 
> Will
> 
> .
> 

Re: [PATCH] IB/mlx5: Fix a parameter of find_first_bit

[Majd Dibbiny]

Acked-by: Majd Dibbiny 

> On Aug 26, 2016, at 8:25 AM, Christophe JAILLET 
>  wrote:
> 
> The 2nd parameter of 'find_first_bit' is the number of bits to search.
> In this case, we are passing 'sizeof(tmp)' which is likely to be 4 or 8
> because 'tmp' is an 'unsigned long'.
> 
> It is likely that the number of bits of 'tmp' was expected here. So use
> BITS_PER_LONG instead.
> 
> It has been spotted by the following coccinelle script:
> @@
> expression ret, x;
> 
> @@
> *  ret = \(find_first_bit \| find_first_zero_bit\) (x, sizeof(...));
> 
> Signed-off-by: Christophe JAILLET 
> ---
> __ffs could be used to reduce code verbosity
> ---
> drivers/infiniband/hw/mlx5/mem.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/mlx5/mem.c 
> b/drivers/infiniband/hw/mlx5/mem.c
> index 40df2cca0609..996b54e366b0 100644
> --- a/drivers/infiniband/hw/mlx5/mem.c
> +++ b/drivers/infiniband/hw/mlx5/mem.c
> @@ -71,7 +71,7 @@ void mlx5_ib_cont_pages(struct ib_umem *umem, u64 addr, int 
> *count, int *shift,
> 
>addr = addr >> page_shift;
>tmp = (unsigned long)addr;
> -m = find_first_bit(&tmp, sizeof(tmp));
> +m = find_first_bit(&tmp, BITS_PER_LONG);
>skip = 1 << m;
>mask = skip - 1;
>i = 0;
> @@ -81,7 +81,7 @@ void mlx5_ib_cont_pages(struct ib_umem *umem, u64 addr, int 
> *count, int *shift,
>for (k = 0; k < len; k++) {
>if (!(i & mask)) {
>tmp = (unsigned long)pfn;
> -m = min_t(unsigned long, m, find_first_bit(&tmp, 
> sizeof(tmp)));
> +m = min_t(unsigned long, m, find_first_bit(&tmp, 
> BITS_PER_LONG));
>skip = 1 << m;
>mask = skip - 1;
>base = pfn;
> @@ -89,7 +89,7 @@ void mlx5_ib_cont_pages(struct ib_umem *umem, u64 addr, int 
> *count, int *shift,
>} else {
>if (base + p != pfn) {
>tmp = (unsigned long)p;
> -m = find_first_bit(&tmp, sizeof(tmp));
> +m = find_first_bit(&tmp, BITS_PER_LONG);
>skip = 1 << m;
>mask = skip - 1;
>base = pfn;
> -- 
> 2.7.4
> 
> 
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le 
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 14/14] Documentation: remove the constraint on the distances of node pairs

[Leizhen (ThunderTown)]

On 2016/8/26 23:35, Will Deacon wrote:
> On Wed, Aug 24, 2016 at 03:44:53PM +0800, Zhen Lei wrote:
>> Update documentation. This limit is unneccessary.
>>
>> Signed-off-by: Zhen Lei 
>> Acked-by: Rob Herring 
>> ---
>>  Documentation/devicetree/bindings/numa.txt | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/numa.txt 
>> b/Documentation/devicetree/bindings/numa.txt
>> index 21b3505..c0ea4a7 100644
>> --- a/Documentation/devicetree/bindings/numa.txt
>> +++ b/Documentation/devicetree/bindings/numa.txt
>> @@ -48,7 +48,6 @@ distance (memory latency) between all numa nodes.
>>
>>Note:
>>  1. Each entry represents distance from first node to second node.
>> -The distances are equal in either direction.
> 
> Hmm, so what happens now if firmware provides a description where both
> distances (in either direction) are supplied, but are different?
I have not known any hardware that the distances of two direction are different 
yet, but:
1. software have no need to limit the distances of two direction must be equal.
2. suppose below software scenario:
   1) cpu0 and cpu1 belong to the same hardware node.
   2) cpu0 is a master control CPU, many tasks and interrupts deliver to cpu0 
first. So cpu0 often busy than cpu1.
   3) we split cpu0 and cpu1 into two logical nodes, cpu0 belongs to node0, 
cpu1 belong to node1. Now, we make
  the distance from cpu0 to cpu1 larger than the distance from cpu1 to cpu0.

> 
> Will
> 
> .
> 

Re: [PATCH v7 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

[Leizhen (ThunderTown)]

On 2016/8/26 23:43, Will Deacon wrote:
> On Wed, Aug 24, 2016 at 03:44:50PM +0800, Zhen Lei wrote:
>> Some numa nodes may have no memory. For example:
>> 1. cpu0 on node0
>> 2. cpu1 on node1
>> 3. device0 access the momory from node0 and node1 take the same time.
>>
>> So, we can not simply classify device0 to node0 or node1, but we can
>> define a node2 which distances to node0 and node1 are the same.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/Kconfig  |  4 
>>  arch/arm64/kernel/smp.c |  1 +
>>  arch/arm64/mm/numa.c| 43 +--
>>  3 files changed, 46 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 2815af6..3a2b6ed 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -611,6 +611,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>>  def_bool y
>>  depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> +def_bool y
>> +depends on NUMA
>> +
>>  source kernel/Kconfig.preempt
>>  source kernel/Kconfig.hz
>>
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index d93d433..4879085 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -619,6 +619,7 @@ static void __init of_parse_and_init_cpus(void)
>>  }
>>
>>  bootcpu_valid = true;
>> +early_map_cpu_to_node(0, of_node_to_nid(dn));
> 
> This seems unrelated?
I will get off my work soon. Maybe I need put it into patch 12.

> 
>>  /*
>>   * cpu_logical_map has already been
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 6853db7..114180f 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -129,6 +129,14 @@ void __init early_map_cpu_to_node(unsigned int cpu, int 
>> nid)
>>  nid = 0;
>>
>>  cpu_to_node_map[cpu] = nid;
>> +
>> +/*
>> + * We should set the numa node of cpu0 as soon as possible, because it
>> + * has already been set up online before. cpu_to_node(0) will soon be
>> + * called.
>> + */
>> +if (!cpu)
>> +set_cpu_numa_node(cpu, nid);
> 
> Likewise.
> 
>>  }
>>
>>  #ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
>> @@ -211,6 +219,35 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>>  return ret;
>>  }
>>
>> +static u64 __init alloc_node_data_from_nearest_node(int nid, const size_t 
>> size)
>> +{
>> +int i, best_nid, distance;
>> +u64 pa;
>> +DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
>> +
>> +bitmap_zero(nodes_map, MAX_NUMNODES);
>> +bitmap_set(nodes_map, nid, 1);
>> +
>> +find_nearest_node:
>> +best_nid = NUMA_NO_NODE;
>> +distance = INT_MAX;
>> +
>> +for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
>> +if (numa_distance[nid][i] < distance) {
>> +best_nid = i;
>> +distance = numa_distance[nid][i];
>> +}
>> +
>> +pa = memblock_alloc_nid(size, SMP_CACHE_BYTES, best_nid);
>> +if (!pa) {
>> +BUG_ON(best_nid == NUMA_NO_NODE);
>> +bitmap_set(nodes_map, best_nid, 1);
>> +goto find_nearest_node;
>> +}
>> +
>> +return pa;
>> +}
>> +
>>  /**
>>   * Initialize NODE_DATA for a node on the local memory
>>   */
>> @@ -224,7 +261,9 @@ static void __init setup_node_data(int nid, u64 
>> start_pfn, u64 end_pfn)
>>  pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
>>  nid, start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
>>
>> -nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
>> +nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
>> +if (!nd_pa)
>> +nd_pa = alloc_node_data_from_nearest_node(nid, nd_size);
> 
> Why not add memblock_alloc_near_nid to the core code, and make it do
> what you need there?
I'm thinking about it next week. But some ARCHs like X86/IA64 have their own 
implementation.

> 
> Will
> 
> .
> 

Re: [PATCH 1/6] pinctrl: mediatek: make mtk-common explicitly non-modular

[Linus Walleij]

On Tue, Aug 23, 2016 at 11:19 PM, Paul Gortmaker
 wrote:

> The Makefile currently controlling compilation of this code is:
>
>   drivers/pinctrl/mediatek/pinctrl-mtk-common.o
> ---> drivers/pinctrl/mediatek/Makefile:obj-y += pinctrl-mtk-common.o
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the couple traces of modular infrastructure use, so that
> when reading the driver there is no doubt it is builtin-only.
>
> We delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
>
> We don't replace module.h with init.h since the file doesn't need that.
>
> Cc: Linus Walleij 
> Cc: Hongzhou Yang 
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 2/6] pinctrl: nomadik: make abx500 explicitly non-modular

[Linus Walleij]

On Tue, Aug 23, 2016 at 11:19 PM, Paul Gortmaker
 wrote:

> The Kconfig currently controlling compilation of this code is:
>
>  config PINCTRL_ABX500
>bool "ST-Ericsson ABx500 family Mixed Signal Circuit gpio functions"
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the couple traces of modular infrastructure use, so that
> when reading the driver there is no doubt it is builtin-only.
>
> Note that MODULE_ALIAS is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
>
> Cc: Linus Walleij 
> Cc: Alessandro Rubini 
> Cc: Patrice Chotard 
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 3/6] pinctrl: nomadik: make core support explicitly non-modular

[Linus Walleij]

On Tue, Aug 23, 2016 at 11:19 PM, Paul Gortmaker
 wrote:

> The Kconfig currently controlling compilation of this code is:
>
> drivers/pinctrl/nomadik/Kconfig:config PINCTRL_NOMADIK
> drivers/pinctrl/nomadik/Kconfig:bool "Nomadik pin controller driver"
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the couple traces of modular infrastructure use, so that
> when reading the driver there is no doubt it is builtin-only.
>
> We delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
>
> Cc: Linus Walleij 
> Cc: Alessandro Rubini 
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 4/6] pinctrl: rockchip: make it explicitly non-modular

[Linus Walleij]

On Tue, Aug 23, 2016 at 11:19 PM, Paul Gortmaker
 wrote:

> The Kconfig currently controlling compilation of this code is:
>
> drivers/pinctrl/Kconfig:config PINCTRL_ROCKCHIP
> drivers/pinctrl/Kconfig:bool
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the couple traces of modular infrastructure use, so that
> when reading the driver there is no doubt it is builtin-only.
>
> Note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
>
> Cc: Linus Walleij 
> Cc: Heiko Stuebner 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Paul Gortmaker 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 5/6] pinctrl: sirf: make atlas7 explicitly non-modular

[Linus Walleij]

On Tue, Aug 23, 2016 at 11:19 PM, Paul Gortmaker
 wrote:

> The Makefile currently controlling compilation of this code is:
>
>   drivers/pinctrl/sirf/pinctrl-atlas7.o
> ---> drivers/pinctrl/sirf/Makefile:obj-y += pinctrl-atlas7.o
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the couple traces of modular infrastructure use, so that
> when reading the driver there is no doubt it is builtin-only.
>
> We delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
>
> Cc: Linus Walleij 
> Cc: Barry Song 
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 6/6] pinctrl: sirf: make core support explicitly non-modular

[Linus Walleij]

On Tue, Aug 23, 2016 at 11:19 PM, Paul Gortmaker
 wrote:

> The Makefile currently controlling compilation of this code is:
>
>   drivers/pinctrl/sirf/pinctrl-sirf.o
>   --> drivers/pinctrl/sirf/Makefile:obj-y += pinctrl-sirf.o
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the couple traces of modular infrastructure use, so that
> when reading the driver there is no doubt it is builtin-only.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
>
> Cc: Linus Walleij 
> Cc: Rongjun Ying 
> Cc: Yuping Luo 
> Cc: Barry Song 
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 3.10 099/180] fix d_walk()/non-delayed __d_free() race

[Ben Hutchings]

On Sat, 2016-08-27 at 11:31 +0200, Willy Tarreau wrote:
> Greg, Jiri,
> 
> I checked Jari's explanation below and found that v3.14.77 and v3.12.62
> are missing the same fix as 3.10. In fact Al's original commit 3d56c25
> ("fix d_walk()/non-delayed __d_free() race") used to mention to check 
> this __d_materialise_dentry() function in the Cc: stable line, but this
> got lost during the backports.
> 
> Normally all of our 3 kernels need to apply the following patch that
> Ben correctly put in 3.16 and 3.2. I'm fixing the backport in 3.10.103
> right now.

I never did get positive confirmation that this is the right change in
__d_materialise_dentry().  Al, could you please comment?

Ben.

> > Cheers,
> Willy
> 
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 2a808fb..2d0b9d2 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -2401,6 +2401,7 @@ static void __d_materialise_dentry(struct dentry 
> *dentry, struct dentry *anon)
> >     switch_names(dentry, anon);
> >     swap(dentry->d_name.hash, anon->d_name.hash);
>  
> > +   dentry->d_flags |= DCACHE_RCUACCESS;
> >     dentry->d_parent = dentry;
> >     list_del_init(&dentry->d_child);
> >     anon->d_parent = dparent;
> 
> 
> On Mon, Aug 22, 2016 at 04:56:57PM +0300, Jari Ruusu wrote:
> > 
> > This patch for 3.10 branch appears to be missing one important
> > 
> > +   dentry->d_flags |= DCACHE_RCUACCESS;
> > 
> > in fs/dcache.c __d_materialise_dentry() function. When Ben Hutchings
> > backported Al Viro's original fix to stable branches that he maintains,
> > he added that one additional line to both 3.2 and 3.16 branches. Please
> > consider including that additional one line fix for 3.10 stable branch
> > also.
> > 
> > 
> > Ben Hutchings said this on his 3.2.82-rc1 patch:
> > [bwh: Backported to 3.2:
> >  - Adjust context
> >  - Also set the flag in __d_materialise_dentry())]
> > 
> > http://marc.info/?l=linux-kernel&m=147117565612275&w=2
> > 
> > 
> > Ben Hutchings said this on his 3.16.37-rc1 patch:
> > [bwh: Backported to 3.16:
> >  - Adjust context
> >  - Also set the flag in __d_materialise_dentry())]
> > 
> > http://marc.info/?l=linux-kernel&m=147117433412006&w=2
> > 
> > 
> > Also mentioned by Sasha Levin on 3.18 and 4.1 commits:
> > > > Cc: sta...@vger.kernel.org # v3.2+ (and watch out for 
> > > > __d_materialise_dentry())
> > 
> > http://marc.info/?l=linux-stable-commits&m=146648034410827&w=2
> > http://marc.info/?l=linux-stable-commits&m=146647471009771&w=2
> > 
> > -- 
> > Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 
> > F189
-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought.
... I realized that a large part of my life from then on was going to
be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 1/2] smc91x: always use 8-bit access if necessary

[kbuild test robot]

Hi Arnd,

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.8-rc3 next-20160825]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/smc91x-always-use-8-bit-access-if-necessary/20160825-225929
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All warnings (new ones prefixed by >>):

   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:1015:28: note: in expansion of macro 
'SMC_out16'
#define SMC_SET_TCR(lp, x) SMC_out16(x, ioaddr, TCR_REG(lp))
   ^
   drivers/net/ethernet/smsc/smc91x.c:1028:3: note: in expansion of macro 
'SMC_SET_TCR'
  SMC_SET_TCR(lp, lp->tcr_cur_mode);
  ^
   drivers/net/ethernet/smsc/smc91x.c: In function 'smc_phy_configure':
   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:944:4: note: in expansion of macro 
'SMC_out16'
   SMC_out16(x, ioaddr, BANK_SELECT);  \
   ^
   drivers/net/ethernet/smsc/smc91x.c:1077:2: note: in expansion of macro 
'SMC_SELECT_BANK'
 SMC_SELECT_BANK(lp, 0);
 ^
   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:1010:4: note: in expansion of macro 
'SMC_out16'
   SMC_out16(x, ioaddr, RPC_REG(lp));  \
   ^
   drivers/net/ethernet/smsc/smc91x.c:1078:2: note: in expansion of macro 
'SMC_SET_RPC'
 SMC_SET_RPC(lp, lp->rpc_cur_mode);
 ^
   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:944:4: note: in expansion of macro 
'SMC_out16'
   SMC_out16(x, ioaddr, BANK_SELECT);  \
   ^
   drivers/net/ethernet/smsc/smc91x.c:1135:2: note: in expansion of macro 
'SMC_SELECT_BANK'
 SMC_SELECT_BANK(lp, 2);
 ^
   drivers/net/ethernet/smsc/smc91x.c: In function 'smc_10bt_check_media':
   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:944:4: note: in expansion of macro 
'SMC_out16'
   SMC_out16(x, ioaddr, BANK_SELECT);  \
   ^
   drivers/net/ethernet/smsc/smc91x.c:1176:2: note: in expansion of macro 
'SMC_SELECT_BANK'
 SMC_SELECT_BANK(lp, 0);
 ^
   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:944:4: note: in expansion of macro 
'SMC_out16'
   SMC_out16(x, ioaddr, BANK_SELECT);  \
   ^
   drivers/net/ethernet/smsc/smc91x.c:1178:2: note: in expansion of macro 
'SMC_SELECT_BANK'
 SMC_SELECT_BANK(lp, 2);
 ^
   drivers/net/ethernet/smsc/smc91x.c: In function 'smc_eph_interrupt':
   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:944:4: note: in expansion of macro 
'SMC_out16'
   SMC_out16(x, ioaddr, BANK_SELECT);  \
   ^
   drivers/net/ethernet/smsc/smc91x.c:1200:2: note: in expansion of macro 
'SMC_SELECT_BANK'
 SMC_SELECT_BANK(lp, 1);
 ^
   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:959:28: note: in expansion of macro 
'SMC_out16'
#define SMC_SET_CTL(lp, x) SMC_out16(x, ioaddr, CTL_REG(lp))
   ^
   drivers/net/ethernet/smsc/smc91x.c:1202:2: note: in expansion of macro 
'SMC_SET_CTL'
 SMC_SET_CTL(lp, ctl & ~CTL_LE_ENABLE);
 ^
   drivers/net/ethernet/smsc/smc91x.h:424:16: warning: unused variable 
'__val16' [-Wunused-variable]
  unsigned int __val16 = (x); \
   ^
   drivers/net/ethernet/smsc/smc91x.h:959:28: note: in expansion 

Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords

[One Thousand Gnomes]

On Fri, 26 Aug 2016 17:26:18 -0400
James Bottomley  wrote:

> On Fri, 2016-08-26 at 22:12 +0100, One Thousand Gnomes wrote:
> > > A non-security use case would be to run the binary (without 
> > > modification) with a different ELF interpreter (assuming this 
> > > allows to override binfmt_elf, but self-sandboxing would need that 
> > > as well).  This would make it easier to use older or newer libcs 
> > > for select binaries on the system.  Right now, one has to write 
> > > wrappers for that, and the explicit dynamic linker invocation is 
> > > not completely transparent to the application.  
> > 
> > If it gets in I'll be using it to label CP/M COM files so that they 
> > can be auto-run nicely when crossbuilding stuff in part with the 
> > original tools but a modern build environment 8)
> > 
> > Sandboxing is an obvious use but there are more bizarre ones such as
> > marking a file system image to get auto-run under a virtual machine 
> > or make containers fire up as if they were commands.  
> 
> So I asked previously but didn't get an answer.  If this is useful for
> sandboxing and being in the sandbox depends on the xattr value,
> shouldn't it be in one of the privileged xattr namespaces, not the
> user. one?

IMHO no 

- because it's not giving additional rights, it is taking rights away
  voluntarily
- because as a user I can simply cp the file to get an unsandboxed version

If it was a setuid like bit then yes it would matter.

Alan

Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

[Matthijs van Duin]

To clarify, this patch effectively reverts

commit 2ab9f5879162499e1c4e48613287e3f59e593c4f
gpu: drm: omapdrm: dss-of: add missing of_node_put after calling
of_parse_phandle

except it leaves behind unnecessary verbiage that this commit
introduced. And to be clear, that commit *should* indeed be reverted,
although preferably in its entirety obviously.

of_get_next_parent already drops a ref on its argument, so of_node_put
was never "missing" here.

Matthijs

Re: [RFC PATCH 0/3] UART slave device bus

[Michal Suchanek]

On 22 August 2016 at 23:23, H. Nikolaus Schaller  wrote:
> Hi Sebastian,
>
>> Am 22.08.2016 um 22:39 schrieb Sebastian Reichel :
>>
>> Hi,
>>
>> On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote:
 Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes 
 :
> What it is not about are UART/RS232 converters connected through USB or 
> virtual
> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or 
> BT devices
> connected through USB (even if they also run HCI protocol).

 It actually has to be about both because you will find the exact same
 device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is
 it just about embedded boards.
>>>
>>> Not necessarily.
>>>
>>> We often have two interface options for exactly the sam sensor chips. They 
>>> can be connected
>>> either through SPI or I2C. Which means that there is a core driver for the 
>>> chip and two different
>>> transport glue components (see e.g. iio/accel/bmc150).
>>>
>>> This does not require I2C to be able to handle SPI or vice versa or provide 
>>> a common API.
>>
>> I don't understand this comparison. I2C and SPI are different
>> protocols,
>
> Yes, they are different on protocol level, but on both you transfer blocks of 
> data from/to a slave device
> which usually can be addressed. And for some chips they are just two slightly 
> alternative serial interfaces.
>
>> while native UART and USB-connected UART are both UART.
>
> I see what you mean, but kernel divides between directly connected UART and 
> USB-connected UART.
>
> drivers/usb/serial/ vs. drivers/tty/serial/
>
> to implement two different groups of UARTs. Although on user space level they 
> are harmonized again.
> This is why I compare with i2c and spi. But each such comparison is not 
> perfect.
>
> Anyways, to me it looks as if everybody wants to make the solution work for 
> usb-uarts as well
> (although I still would like to see a real world use-case).

I use a NFC reader attached to a PL2303 UART. It's a proof of concept
solution but if I needed a finished
product all it takes is to put the two pieces of PCB into a box with
the USB connector sticking out.
Or glue the PCB on the inside of a plastic part of a PC case.

Thanks

Michal

Re: [PATCH v9 0/2] sun4i-codec: Add Line-In, FM-In, Mic 2, Capture Source, Differential Line-In

[Maxime Ripard]

Hi,

On Fri, Aug 26, 2016 at 09:22:28AM +0200, Danny Milosavljevic wrote:
> This patch adds support for some mixer controls:
> - Line-In
> - FM-In
> - Mic 2
> - Capture Source
> - Differential Line-In

Please send your patches using send-email.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

[Matthijs van Duin]

> [8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port@1/endpoint
> [8.843014] [] (omapdss_of_find_source_for_first_ep [omapdss])

I can confirm that reverting 2ab9f5879162 fixes this regression,
tested on omap5-uevm.

Matthijs

Re: [PATCH v2] ARM: dts: sun8i: Add dts file for inet-d978_rev2 tablets

[Maxime Ripard]

On Fri, Aug 26, 2016 at 06:23:56PM +0800, Icenowy Zheng wrote:
> The inet-d978_rev2 is a pcb used in generic A33 based tablets. It features
> volume buttons, micro-usb otg, headphone connector and a power button.
> 
> On the board a Realtek RTL8723BS SDIO Wi-Fi module are soldered, and there
> is also a accompanied board which has a Goodix GT9271 soldered.
> 
> As this board is desired to create tablets with a Home key dealed by
> GT9271, a LED is present at the front panel at the position of the
> Home key.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] pcmcia: ds: fix suspend/resume

[Dominik Brodowski]

Russell,

On Sun, Aug 21, 2016 at 12:05:30AM +0100, Russell King wrote:
> PCMCIA suspend/resume no longer works since the commit mentioned below,
> as the callbacks are no longer made.  Convert the driver to the new
> dev_pm_ops, which restores the suspend/resume functionality.  Tested on
> the arm arch Assabet platform with a pcnet_cs CF card.
> 
> Fixes: aa8e54b559479 ("PM / sleep: Go direct_complete if driver has no 
> callbacks")
> Signed-off-by: Russell King 

Looks goot to me. Can you push it upstream, please?

Best
Dominik

Re: [PATCH] clk: sunxi-ng: Fix wrong reset register offsets

[Maxime Ripard]

Hi,

Thanks a lot for your patch.

On Fri, Aug 26, 2016 at 01:24:13PM +0200, jo...@kippendief.biz wrote:
> From: Jorik Jonker 
> 
> The reset register offsets for UART*, I2C* and SCR were off by a few bytes.

You're missing your signed-off-by though. Could you resend it with it?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH -next] drm/sun4i: Remove redundant dev_err call in sun4i_tcon_init_regmap()

[Maxime Ripard]

On Fri, Aug 26, 2016 at 02:25:25PM +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Signed-off-by: Wei Yongjun 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH 3/4] ASoC: dapm: Fix kcontrol creation for output driver widget

[Chen-Yu Tsai]

Commit d88429a695a4 ("ASoC: dapm: Add output driver widget") added
the snd_soc_dapm_out_drv ID for the output driver widget, which is
the same as the PGA widget, with a later power sequence number.

Commit 19a2557b76d6 ("ASoC: dapm: Add kcontrol support for PGAs")
then added kcontrol support for PGA widgets, but failed to account
for output driver widgets. Attempts to use kcontrols with output
driver widgets result in silent failures, with the developer having
little idea about what went on.

Add snd_soc_dapm_out_drv to the switch/case block under snd_soc_dapm_pga
in dapm_create_or_share_kcontrol, since they are essentially the same.

Fixes: 19a2557b76d6 ("ASoC: dapm: Add kcontrol support for PGAs")
Signed-off-by: Chen-Yu Tsai 
---
 sound/soc/soc-dapm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 9be076bc14b5..ed6b707cc7ce 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -823,6 +823,7 @@ static int dapm_create_or_share_kcontrol(struct 
snd_soc_dapm_widget *w,
case snd_soc_dapm_switch:
case snd_soc_dapm_mixer:
case snd_soc_dapm_pga:
+   case snd_soc_dapm_out_drv:
wname_in_long_name = true;
kcname_in_long_name = true;
break;
-- 
2.9.3

[PATCH 1/4] ASoC: dapm: Fix possible uninitialized variable in snd_soc_dapm_get_volsw()

[Chen-Yu Tsai]

If soc_dapm_read() fails, val will be uninitialized, and bogus values
will be written later:

ret = soc_dapm_read(dapm, reg, &val);
val = (val >> shift) & mask;

However, the compiler does not give a warning. Return on error before
val is really used to avoid this.

This is similar to the commit 6912831623c5 ("ASoC: dapm: Fix
uninitialized variable in snd_soc_dapm_get_enum_double()")

Fixes: ce0fc93ae56e ("ASoC: Add DAPM support at the component level")
Signed-off-by: Chen-Yu Tsai 
---
 sound/soc/soc-dapm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 8698c26773b3..0b442fee0b62 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -3049,6 +3049,9 @@ int snd_soc_dapm_get_volsw(struct snd_kcontrol *kcontrol,
}
mutex_unlock(&card->dapm_mutex);
 
+   if (ret)
+   return ret;
+
if (invert)
ucontrol->value.integer.value[0] = max - val;
else
-- 
2.9.3

[PATCH 0/4] ASoC: dapm: Various fixes for dapm kcontrols

[Chen-Yu Tsai]

Hi everyone,

This series is a bunch of fixes for some problems I encountered while
experimenting with various dapm kcontrols for Allwinner A31 support
in sun4i-codec.

Patch 1 fixes a possible uninitialized variable usage in
snd_soc_dapm_get_volsw(). This doesn't show up as a compiler warning
but I'm fairly certain it might happen.

Patch 2 fixes setting the value for an enum kcontrol's second channel.

Patch 3 fixes kcontrol creation for output driver widgets. An output
driver widget is the same as a PGA widget, just with a different
priority.

Patch 4 adds an error message if anyone attempts to add hardware backed
kcontrols on PGA widgets. Originally kcontrols on PGAs weren't supported
at all. Support for them on virtual widgets were added later, but a guard
for real widgets was missing.


Regards
ChenYu


Chen-Yu Tsai (4):
  ASoC: dapm: Fix possible uninitialized variable in
snd_soc_dapm_get_volsw()
  ASoC: dapm: Fix value setting for _ENUM_DOUBLE MUX's second channel
  ASoC: dapm: Fix kcontrol creation for output driver widget
  ASoC: dapm: Give error when adding hardware backed controls for PGA
widgets

 sound/soc/soc-dapm.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

-- 
2.9.3

[PATCH 2/4] ASoC: dapm: Fix value setting for _ENUM_DOUBLE MUX's second channel

[Chen-Yu Tsai]

The value for the second channel in _ENUM_DOUBLE (double channel) MUXs
is not correctly updated, due to using the wrong bit shift.

Use the correct bit shift, so both channels toggle together.

Fixes: 3727b4968453 ("ASoC: dapm: Consolidate MUXs and value MUXs")
Signed-off-by: Chen-Yu Tsai 
---
 sound/soc/soc-dapm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 0b442fee0b62..9be076bc14b5 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -3203,7 +3203,7 @@ int snd_soc_dapm_put_enum_double(struct snd_kcontrol 
*kcontrol,
if (e->shift_l != e->shift_r) {
if (item[1] > e->items)
return -EINVAL;
-   val |= snd_soc_enum_item_to_val(e, item[1]) << e->shift_l;
+   val |= snd_soc_enum_item_to_val(e, item[1]) << e->shift_r;
mask |= e->mask << e->shift_r;
}
 
-- 
2.9.3

[PATCH 4/4] ASoC: dapm: Give error when adding hardware backed controls for PGA widgets

[Chen-Yu Tsai]

Commit 19a2557b76d6 ("ASoC: dapm: Add kcontrol support for PGAs") added
kcontrol support for PGA widgets, but did not add necessary changes to
snd_soc_dapm_put_volsw or soc_dapm_mixer_update_power to have hardware
register updates actually happen.

As this is a little used feature, this patch just adds an error message
when someone tries to use hardware backed controls with PGA or output
driver widgets.

Fixes: 19a2557b76d6 ("ASoC: dapm: Add kcontrol support for PGAs")
Signed-off-by: Chen-Yu Tsai 
---
 sound/soc/soc-dapm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index ed6b707cc7ce..f681a251d766 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -984,6 +984,14 @@ static int dapm_new_pga(struct snd_soc_dapm_widget *w)
int i, ret;
 
for (i = 0; i < w->num_kcontrols; i++) {
+   const struct soc_mixer_control *mc =
+   (struct soc_mixer_control 
*)w->kcontrol_news[i].private_value;
+
+   if (mc->reg != SND_SOC_NOPM)
+   dev_err(w->dapm->dev,
+   "ASoC: hardware backed PGA controls not 
supported: '%s'\n",
+   w->name);
+
ret = dapm_create_or_share_kcontrol(w, i);
if (ret < 0)
return ret;
-- 
2.9.3

Re: [PATCH] pcmcia: ds: fix suspend/resume

[Russell King - ARM Linux]

On Sat, Aug 27, 2016 at 02:05:22PM +0200, Dominik Brodowski wrote:
> Russell,
> 
> On Sun, Aug 21, 2016 at 12:05:30AM +0100, Russell King wrote:
> > PCMCIA suspend/resume no longer works since the commit mentioned below,
> > as the callbacks are no longer made.  Convert the driver to the new
> > dev_pm_ops, which restores the suspend/resume functionality.  Tested on
> > the arm arch Assabet platform with a pcnet_cs CF card.
> > 
> > Fixes: aa8e54b559479 ("PM / sleep: Go direct_complete if driver has no 
> > callbacks")
> > Signed-off-by: Russell King 
> 
> Looks goot to me. Can you push it upstream, please?

I can do - should I take that as an Acked-by?

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 6/6] rtl8188eu: remove unused debugging functions

[Luca Ceresoli]

These functions were only mentioned in the rtw_proc_init_one()
function in drivers/staging/rtl8188eu/os_dep/os_intfs.c, which was
under #if 0 and has now been removed completely.

Signed-off-by: Luca Ceresoli 
Cc: Greg Kroah-Hartman 
Cc: Kyle Kuffermann 
Cc: Chris Elliott 
Cc: Ivan Safonov 
Cc: linux-kernel@vger.kernel.org
---
 drivers/staging/rtl8188eu/core/rtw_debug.c| 731 --
 drivers/staging/rtl8188eu/include/rtw_debug.h | 121 -
 2 files changed, 852 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_debug.c 
b/drivers/staging/rtl8188eu/core/rtw_debug.c
index db5c952ac852..60d8c7b9f458 100644
--- a/drivers/staging/rtl8188eu/core/rtw_debug.c
+++ b/drivers/staging/rtl8188eu/core/rtw_debug.c
@@ -138,144 +138,6 @@ int proc_set_read_reg(struct file *file, const char 
__user *buffer,
return count;
 }
 
-int proc_get_fwstate(char *page, char **start,
- off_t offset, int count,
- int *eof, void *data)
-{
-   struct net_device *dev = data;
-   struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-   struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
-
-   int len = 0;
-
-   len += snprintf(page + len, count - len, "fwstate=0x%x\n", 
get_fwstate(pmlmepriv));
-
-   *eof = 1;
-   return len;
-}
-
-int proc_get_sec_info(char *page, char **start,
- off_t offset, int count,
- int *eof, void *data)
-{
-   struct net_device *dev = data;
-   struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-   struct security_priv *psecuritypriv = &padapter->securitypriv;
-
-   int len = 0;
-
-   len += snprintf(page + len, count - len, "auth_alg=0x%x, enc_alg=0x%x, 
auth_type=0x%x, enc_type=0x%x\n",
-   
psecuritypriv->dot11AuthAlgrthm, psecuritypriv->dot11PrivacyAlgrthm,
-   psecuritypriv->ndisauthtype, 
psecuritypriv->ndisencryptstatus);
-
-   *eof = 1;
-   return len;
-}
-
-int proc_get_mlmext_state(char *page, char **start,
- off_t offset, int count,
- int *eof, void *data)
-{
-   struct net_device *dev = data;
-   struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-   struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
-   struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
-
-   int len = 0;
-
-   len += snprintf(page + len, count - len, "pmlmeinfo->state=0x%x\n", 
pmlmeinfo->state);
-
-   *eof = 1;
-   return len;
-}
-
-int proc_get_qos_option(char *page, char **start,
- off_t offset, int count,
- int *eof, void *data)
-{
-   struct net_device *dev = data;
-   struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-   struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
-
-   int len = 0;
-
-   len += snprintf(page + len, count - len, "qos_option=%d\n", 
pmlmepriv->qospriv.qos_option);
-
-   *eof = 1;
-   return len;
-}
-
-int proc_get_ht_option(char *page, char **start,
- off_t offset, int count,
- int *eof, void *data)
-{
-   struct net_device *dev = data;
-   struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-   struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
-
-   int len = 0;
-
-   len += snprintf(page + len, count - len, "ht_option=%d\n", 
pmlmepriv->htpriv.ht_option);
-   *eof = 1;
-   return len;
-}
-
-int proc_get_rf_info(char *page, char **start,
- off_t offset, int count,
- int *eof, void *data)
-{
-   struct net_device *dev = data;
-   struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-   struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
-   int len = 0;
-
-   len += snprintf(page + len, count - len, "cur_ch=%d, cur_bw=%d, 
cur_ch_offset=%d\n",
-   pmlmeext->cur_channel, 
pmlmeext->cur_bwmode, pmlmeext->cur_ch_offset);
-   *eof = 1;
-   return len;
-}
-
-int proc_get_ap_info(char *page, char **start,
- off_t offset, int count,
- int *eof, void *data)
-{
-   struct sta_info *psta;
-   struct net_device *dev = data;
-   struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-   struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
-   struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
-   struct wlan_network *cur_network = &pmlmepriv->cur_network;
-   struct sta_priv *pstapriv = &padapter->stapriv;
-   int len = 0;
-
-   psta = rtw_get_stainfo(pstapriv, cur_network->network.MacAddress);
-   if (psta) {
-   int i;
-   struct recv_reorder_ctrl *preorder_c

[PATCH 2/6] rtl8188eu: remove declaration of unimplemented functions

[Luca Ceresoli]

Signed-off-by: Luca Ceresoli 
Cc: Greg Kroah-Hartman 
Cc: Kyle Kuffermann 
Cc: linux-kernel@vger.kernel.org
---
 drivers/staging/rtl8188eu/include/recv_osdep.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/recv_osdep.h 
b/drivers/staging/rtl8188eu/include/recv_osdep.h
index cad31587c30a..7550d58f6b5b 100644
--- a/drivers/staging/rtl8188eu/include/recv_osdep.h
+++ b/drivers/staging/rtl8188eu/include/recv_osdep.h
@@ -26,13 +26,9 @@ void _rtw_free_recv_priv(struct recv_priv *precvpriv);
 s32  rtw_recv_entry(struct recv_frame *precv_frame);
 int rtw_recv_indicatepkt(struct adapter *adapter,
 struct recv_frame *recv_frame);
-void rtw_recv_returnpacket(struct  net_device *cnxt, struct sk_buff *retpkt);
 
 void rtw_handle_tkip_mic_err(struct adapter *padapter, u8 bgroup);
 
-int rtw_init_recv_priv(struct recv_priv *precvpriv, struct adapter *padapter);
-void rtw_free_recv_priv(struct recv_priv *precvpriv);
-
 void rtw_os_recv_resource_alloc(struct recv_frame *recvfr);
 
 int rtw_os_recvbuf_resource_alloc(struct adapter *adapt, struct recv_buf *buf);
-- 
2.7.4

[PATCH 3/6] rtl8188eu: declare internal function as static

[Luca Ceresoli]

Signed-off-by: Luca Ceresoli 
Cc: Greg Kroah-Hartman 
Cc: Bhaktipriya Shridhar 
Cc: Andy Shevchenko 
Cc: Geliang Tang 
Cc: Jakub Sitnicki 
Cc: Ivan Safonov 
Cc: Kyle Kuffermann 
Cc: linux-kernel@vger.kernel.org
---
 drivers/staging/rtl8188eu/core/rtw_recv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c 
b/drivers/staging/rtl8188eu/core/rtw_recv.c
index 977bb2532c3e..1063617b0ce4 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -39,7 +39,7 @@ static u8 rtw_rfc1042_header[] = {
0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00
 };
 
-void rtw_signal_stat_timer_hdl(unsigned long data);
+static void rtw_signal_stat_timer_hdl(unsigned long data);
 
 void _rtw_init_sta_recv_priv(struct sta_recv_priv *psta_recvpriv)
 {
@@ -2088,7 +2088,7 @@ _recv_entry_drop:
return ret;
 }
 
-void rtw_signal_stat_timer_hdl(unsigned long data)
+static void rtw_signal_stat_timer_hdl(unsigned long data)
 {
struct adapter *adapter = (struct adapter *)data;
struct recv_priv *recvpriv = &adapter->recvpriv;
-- 
2.7.4

[PATCH 1/6] rtl8723au: remove declaration of unimplemented functions

[Luca Ceresoli]

Signed-off-by: Luca Ceresoli 
Cc: Larry Finger 
Cc: Jes Sorensen 
Cc: Greg Kroah-Hartman 
Cc: linux-wirel...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/staging/rtl8723au/include/recv_osdep.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rtl8723au/include/recv_osdep.h 
b/drivers/staging/rtl8723au/include/recv_osdep.h
index c2d3f1bd5948..c159dbc5c752 100644
--- a/drivers/staging/rtl8723au/include/recv_osdep.h
+++ b/drivers/staging/rtl8723au/include/recv_osdep.h
@@ -26,9 +26,6 @@ int rtw_recv_indicatepkt23a(struct rtw_adapter *adapter, 
struct recv_frame *prec
 
 void rtw_handle_tkip_mic_err23a(struct rtw_adapter *padapter, u8 bgroup);
 
-intrtw_init_recv_priv(struct recv_priv *precvpriv, struct rtw_adapter 
*padapter);
-void rtw_free_recv_priv (struct recv_priv *precvpriv);
-
 int rtw_os_recv_resource_init(struct recv_priv *precvpriv, struct rtw_adapter 
*padapter);
 
 void rtw_init_recv_timer23a(struct recv_reorder_ctrl *preorder_ctrl);
-- 
2.7.4

Re: [PATCH] ath10k: fix spelling mistake "montior" -> "monitor"

[Julian Calaby]

Hi All,

On Sat, Aug 27, 2016 at 4:08 AM, Colin King  wrote:
> From: Colin Ian King 
>
> Trivial fix to spelling mistake in ath10k_warn message.
>
> Signed-off-by: Colin Ian King 

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [f2fs-dev] [PATCH] f2fs: add noinline_dentry mount option

[Chao Yu]

Hi Jaegeuk,

On 2016/8/27 1:11, Jaegeuk Kim wrote:
> Hi Chao,
> 
> I integrated this patch into the original patch which makes inline_dentry by
> default. And, I couldn't find any bug case from my test-cases. :)

OK, it seems that this feature becomes stable now. :)

Thanks,

> 
> Thanks,
> 
> On Fri, Aug 26, 2016 at 09:01:22AM +0800, Chao Yu wrote:
>> This patch adds noinline_dentry mount option.
>>
>> Signed-off-by: Chao Yu 
>> ---
>>  Documentation/filesystems/f2fs.txt | 1 +
>>  fs/f2fs/super.c| 7 +++
>>  2 files changed, 8 insertions(+)
>>
>> diff --git a/Documentation/filesystems/f2fs.txt 
>> b/Documentation/filesystems/f2fs.txt
>> index ecd8080..753dd4f 100644
>> --- a/Documentation/filesystems/f2fs.txt
>> +++ b/Documentation/filesystems/f2fs.txt
>> @@ -131,6 +131,7 @@ inline_dentry  Enable the inline dir feature: 
>> data in new created
>> directory entries can be written into inode block. 
>> The
>> space of inode block which is used to store inline
>> dentries is limited to ~3.4k.
>> +noinline_dentryDiable the inline dentry feature.
>>  flush_mergeMerge concurrent cache_flush commands as much as possible
>> to eliminate redundant command issues. If the 
>> underlying
>> device handles the cache_flush command relatively slowly,
>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>> index 7974833..b776414 100644
>> --- a/fs/f2fs/super.c
>> +++ b/fs/f2fs/super.c
>> @@ -87,6 +87,7 @@ enum {
>>  Opt_inline_xattr,
>>  Opt_inline_data,
>>  Opt_inline_dentry,
>> +Opt_noinline_dentry,
>>  Opt_flush_merge,
>>  Opt_noflush_merge,
>>  Opt_nobarrier,
>> @@ -118,6 +119,7 @@ static match_table_t f2fs_tokens = {
>>  {Opt_inline_xattr, "inline_xattr"},
>>  {Opt_inline_data, "inline_data"},
>>  {Opt_inline_dentry, "inline_dentry"},
>> +{Opt_noinline_dentry, "noinline_dentry"},
>>  {Opt_flush_merge, "flush_merge"},
>>  {Opt_noflush_merge, "noflush_merge"},
>>  {Opt_nobarrier, "nobarrier"},
>> @@ -488,6 +490,9 @@ static int parse_options(struct super_block *sb, char 
>> *options)
>>  case Opt_inline_dentry:
>>  set_opt(sbi, INLINE_DENTRY);
>>  break;
>> +case Opt_noinline_dentry:
>> +clear_opt(sbi, INLINE_DENTRY);
>> +break;
>>  case Opt_flush_merge:
>>  set_opt(sbi, FLUSH_MERGE);
>>  break;
>> @@ -879,6 +884,8 @@ static int f2fs_show_options(struct seq_file *seq, 
>> struct dentry *root)
>>  seq_puts(seq, ",noinline_data");
>>  if (test_opt(sbi, INLINE_DENTRY))
>>  seq_puts(seq, ",inline_dentry");
>> +else
>> +seq_puts(seq, ",noinline_dentry");
>>  if (!f2fs_readonly(sbi->sb) && test_opt(sbi, FLUSH_MERGE))
>>  seq_puts(seq, ",flush_merge");
>>  if (test_opt(sbi, NOBARRIER))
>> -- 
>> 2.8.2.311.gee88674
> 
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 

[PATCH 4/6] rtl8188eu: remove rtw_proc_init_one and rtw_proc_remove_one

[Luca Ceresoli]

rtw_proc_init_one() and rtw_proc_remove_one() are two very long
functions that are supposed to create a bunch of proc entries to
access debugging features of the driver.

But both of them are under #if 0 since their first commit three years
ago (5adef66acf73705ae95ea0b1e6b5fc7f17d82d30), replaced by two empty
functions.

Remove these two functions completely along with every reference to
them. This allows to cleanly remove lots of other functions which are
referenced only by the code under #if 0, and as such is already unused
code.

Subsequent commits remove the unused code.

Should anybody want to implement (in a proper way) the mentioned
debugging features, they can still fetch these functions from the git
history.

Signed-off-by: Luca Ceresoli 
Cc: Greg Kroah-Hartman 
Cc: Kyle Kuffermann 
Cc: Binoy Jayan 
Cc: Arnd Bergmann 
Cc: "Rémy Oudompheng" 
Cc: Ivan Safonov 
Cc: Jakub Sitnicki 
Cc: Alexey Khoroshilov 
Cc: Bhaktipriya Shridhar 
Cc: Bhumika Goyal 
Cc: linux-kernel@vger.kernel.org
---
 drivers/staging/rtl8188eu/include/osdep_intf.h |   1 -
 drivers/staging/rtl8188eu/os_dep/os_intfs.c| 347 -
 drivers/staging/rtl8188eu/os_dep/usb_intf.c|   8 +-
 3 files changed, 3 insertions(+), 353 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/osdep_intf.h 
b/drivers/staging/rtl8188eu/include/osdep_intf.h
index 54fca79827e3..dbd7dc4f87dd 100644
--- a/drivers/staging/rtl8188eu/include/osdep_intf.h
+++ b/drivers/staging/rtl8188eu/include/osdep_intf.h
@@ -34,7 +34,6 @@ int rtw_ioctl(struct net_device *dev, struct ifreq *rq, int 
cmd);
 int rtw_init_netdev_name(struct net_device *pnetdev, const char *ifname);
 struct net_device *rtw_init_netdev(struct adapter *padapter);
 u16 rtw_recv_select_queue(struct sk_buff *skb);
-void rtw_proc_remove_one(struct net_device *dev);
 
 int pm_netdev_open(struct net_device *pnetdev, u8 bnormal);
 void rtw_ips_dev_unload(struct adapter *padapter);
diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c 
b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
index c494845814cd..33261b16fa63 100644
--- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
@@ -185,352 +185,6 @@ MODULE_PARM_DESC(monitor_enable, "Enable monitor 
inferface (default: false)");
 static int netdev_open(struct net_device *pnetdev);
 static int netdev_close(struct net_device *pnetdev);
 
-/* dummy routines */
-void rtw_proc_remove_one(struct net_device *dev)
-{
-}
-
-static void rtw_proc_init_one(struct net_device *dev)
-{
-}
-
-#if 0  /* TODO: Convert these to /sys */
-static void rtw_proc_init_one(struct net_device *dev)
-{
-   struct proc_dir_entry *dir_dev = NULL;
-   struct proc_dir_entry *entry = NULL;
-   struct adapter  *padapter = rtw_netdev_priv(dev);
-   u8 rf_type;
-
-   if (rtw_proc == NULL) {
-   memcpy(rtw_proc_name, DRV_NAME, sizeof(DRV_NAME));
-
-   rtw_proc = create_proc_entry(rtw_proc_name, S_IFDIR,
-init_net.proc_net);
-   if (rtw_proc == NULL) {
-   DBG_88E(KERN_ERR "Unable to create rtw_proc 
directory\n");
-   return;
-   }
-
-   entry = create_proc_read_entry("ver_info", S_IFREG | S_IRUGO,
-  rtw_proc, proc_get_drv_version,
-  dev);
-   if (!entry) {
-   pr_info("Unable to create_proc_read_entry!\n");
-   return;
-   }
-   }
-
-   if (padapter->dir_dev == NULL) {
-   padapter->dir_dev = create_proc_entry(dev->name,
- S_IFDIR | S_IRUGO | S_IXUGO,
- rtw_proc);
-   dir_dev = padapter->dir_dev;
-   if (dir_dev == NULL) {
-   if (rtw_proc_cnt == 0 && rtw_proc) {
-   remove_proc_entry(rtw_proc_name, 
init_net.proc_net);
-   rtw_proc = NULL;
-   }
-
-   pr_info("Unable to create dir_dev directory\n");
-   return;
-   }
-   } else {
-   return;
-   }
-
-   rtw_proc_cnt++;
-
-   entry = create_proc_read_entry("write_reg", S_IFREG | S_IRUGO,
-  dir_dev, proc_get_write_reg, dev);
-   if (!entry) {
-   pr_info("Unable to create_proc_read_entry!\n");
-   return;
-   }
-   entry->write_proc = proc_set_write_reg;
-
-   entry = create_proc_read_entry("read_reg", S_IFREG | S_IRUGO,
-  dir_dev, proc_get_read_reg, dev);
-   if (!entry) {
-   pr_info("Unable to create_proc_read_entry!\n");
-   return;
-   }
-   entry->write_proc = proc_set_read_reg;
-
-
-   entry = create_proc_read_entr

Re: Cannot use CONFIG_GCC_PLUGINS: your gcc version does not support plugins, you should upgrade it to at least gcc 4.5

[Kees Cook]

Hi,

This appears to be "as expected": 4.4 gcc doesn't have either of those
features, so it correctly failed.

-Kees

On Sat, Aug 27, 2016 at 1:52 AM, kbuild test robot
 wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   28687b935e93a9041a485b9ecdcab0e335f8eda5
> commit: ed58c0e9eefef517aa5a547b78658e2ab4422232 gcc-plugins: abort builds 
> cleanly when not supported
> date:   3 weeks ago
> config: x86_64-randconfig-s1-08271305 (attached as .config)
> compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
> reproduce:
> git checkout ed58c0e9eefef517aa5a547b78658e2ab4422232
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>scripts/Makefile.gcc-plugins:17: warning: cannot use CONFIG_KCOV: 
> -fsanitize-coverage=trace-pc is not supported by compiler
>>> Cannot use CONFIG_GCC_PLUGINS: your gcc version does not support plugins, 
>>> you should upgrade it to at least gcc 4.5
>make[1]: *** [gcc-plugins-check] Error 1
>make[1]: Target 'prepare' not remade because of errors.
>make: *** [sub-make] Error 2
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation



-- 
Kees Cook
Nexus Security

Re: Cannot use CONFIG_GCC_PLUGINS: your gcc version does not support plugins, you should upgrade it to at least gcc 4.5

[Fengguang Wu]

Hi Kees,

On Sat, Aug 27, 2016 at 09:28:38AM -0400, Kees Cook wrote:

Hi,

This appears to be "as expected": 4.4 gcc doesn't have either of those
features, so it correctly failed.


OK, I'll teach the robot to use newer compiler for CONFIG_GCC_PLUGINS.

Thanks,
Fengguang


On Sat, Aug 27, 2016 at 1:52 AM, kbuild test robot
 wrote:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   28687b935e93a9041a485b9ecdcab0e335f8eda5
commit: ed58c0e9eefef517aa5a547b78658e2ab4422232 gcc-plugins: abort builds 
cleanly when not supported
date:   3 weeks ago
config: x86_64-randconfig-s1-08271305 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout ed58c0e9eefef517aa5a547b78658e2ab4422232
# save the attached .config to linux build tree
make ARCH=x86_64

All errors (new ones prefixed by >>):

   scripts/Makefile.gcc-plugins:17: warning: cannot use CONFIG_KCOV: 
-fsanitize-coverage=trace-pc is not supported by compiler

Cannot use CONFIG_GCC_PLUGINS: your gcc version does not support plugins, you 
should upgrade it to at least gcc 4.5

   make[1]: *** [gcc-plugins-check] Error 1
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation




--
Kees Cook
Nexus Security

[PATCH 2/2] arm64: dts: rockchip: add eMMC's power domain support for rk3399

[Ziyuan Xu]

Control power domain for eMMC via genpd to reduce power consumption.

Signed-off-by: Elaine Zhang 
Signed-off-by: Ziyuan Xu 

---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 32aebc8..71733d4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -239,6 +239,7 @@
#clock-cells = <0>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
+   power-domains = <&power RK3399_PD_EMMC>;
status = "disabled";
};
 
@@ -611,6 +612,11 @@
status = "disabled";
};
 
+   qos_emmc: qos@ffa58000 {
+   compatible = "syscon";
+   reg = <0x0 0xffa58000 0x0 0x20>;
+   };
+
qos_hdcp: qos@ffa9 {
compatible = "syscon";
reg = <0x0 0xffa9 0x0 0x20>;
@@ -739,6 +745,11 @@
};
 
/* These power domains are grouped by VD_LOGIC */
+   pd_emmc@RK3399_PD_EMMC {
+   reg = ;
+   clocks = <&cru ACLK_EMMC>;
+   pm_qos = <&qos_emmc>;
+   };
pd_vio@RK3399_PD_VIO {
reg = ;
#address-cells = <1>;
-- 
2.9.2

[PATCH 0/2] Add power domain support for eMMC node on rk3399

[Ziyuan Xu]

This series add power domain for eMMC node which will be controlled by
genpd to make sure it's available in probing state, and will be off
once suspend/remove.


Ziyuan Xu (2):
  Documentation: mmc: sdhci-of-arasan: add description of power domain
  arm64: dts: rockchip: add eMMC's power domain support for rk3399

 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt |  6 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 11 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

-- 
2.9.2

Re: [PATCH] ASoC: rockchip: use SPI dependency for rt5514

[Xing Zheng]

Hi Arnd,

On 2016年08月26日 23:50, Arnd Bergmann wrote:

The rk3399 scans the spi_bus_type to find the rt5514 driver, but does not
actually have a Kconfig dependency on SPI, so we can end up with a link
failure:

sound/soc/codecs/snd-soc-rt5514-spi.o: In function `rt5514_spi_driver_init':
rt5514-spi.c:(.init.text+0x14): undefined reference to `__spi_register_driver'
sound/soc/codecs/snd-soc-rt5514-spi.o: In function `rt5514_spi_burst_read':
rt5514-spi.c:(.text.rt5514_spi_burst_read+0x18c): undefined reference to 
`spi_sync'
sound/soc/codecs/snd-soc-rt5514-spi.o: In function `rt5514_spi_burst_write':
rt5514-spi.c:(.text.rt5514_spi_burst_write+0x1b4): undefined reference to 
`spi_sync'
sound/soc/rockchip/snd-soc-rk3399-gru-sound.o: In function 
`rockchip_sound_probe':
rk3399_gru_sound.c:(.text.rockchip_sound_probe+0x128): undefined reference to 
`spi_bus_type'

This adds the missing dependency.

Signed-off-by: Arnd Bergmann
Fixes: c6eac8a36a84 ("ASoC: rockchip: Add machine driver for RK3399 GRU Boards")
---
  sound/soc/rockchip/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index d82d763d4854..c783f9a22595 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -44,7 +44,7 @@ config SND_SOC_ROCKCHIP_RT5645

  config SND_SOC_RK3399_GRU_SOUND
tristate "ASoC support multiple codecs for Rockchip RK3399 GRU boards"
-   depends on SND_SOC_ROCKCHIP&&  I2C&&  GPIOLIB&&  CLKDEV_LOOKUP
+   depends on SND_SOC_ROCKCHIP&&  I2C&&  GPIOLIB&&  CLKDEV_LOOKUP&&  SPI
select SND_SOC_ROCKCHIP_I2S
select SND_SOC_MAX98357A
select SND_SOC_RT5514

So sorry to miss it... Thanks to help us to fix it. :-)

Tested-by: Xing Zheng 

Thanks.

--
- Xing Zheng

Re: [RFC v2 08/10] landlock: Handle file system comparisons

[Mickaël Salaün]

On 26/08/2016 16:57, Andy Lutomirski wrote:
> On Thu, Aug 25, 2016 at 7:10 AM, Mickaël Salaün  wrote:
>>
>> On 25/08/2016 13:12, Andy Lutomirski wrote:
>>> On Thu, Aug 25, 2016 at 3:32 AM, Mickaël Salaün  wrote:
 Add eBPF functions to compare file system access with a Landlock file
 system handle:
 * bpf_landlock_cmp_fs_prop_with_struct_file(prop, map, map_op, file)
   This function allows to compare the dentry, inode, device or mount
   point of the currently accessed file, with a reference handle.
 * bpf_landlock_cmp_fs_beneath_with_struct_file(opt, map, map_op, file)
   This function allows an eBPF program to check if the current accessed
   file is the same or in the hierarchy of a reference handle.

 The goal of file system handle is to abstract kernel objects such as a
 struct file or a struct inode. Userland can create this kind of handle
 thanks to the BPF_MAP_UPDATE_ELEM command. The element is a struct
 landlock_handle containing the handle type (e.g.
 BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) and a file descriptor. This could
 also be any descriptions able to match a struct file or a struct inode
 (e.g. path or glob string).
>>>
>>> This needs Eric's opinion.
>>>
>>> Also, where do all the struct file *'s get stashed?  Are they
>>> preserved in the arraymap?  What prevents reference cycles or absurdly
>>> large numbers of struct files getting pinned?
>>
>> Yes, the struct file are kept in the arraymap and dropped when there is
>> no more reference on them. Currently, the limitations are the maximum
>> number of open file descriptors referring to an arraymap and the maximum
>> number of eBPF Landlock programs loaded in a process
>> (LANDLOCK_PROG_LIST_MAX_PAGES in kernel/seccomp.c).
>>
>> What kind of reference cycles have you in mind?
> 
> Shoving evil things into the arraymaps, e.g. unix sockets with
> SCM_RIGHTS messages pending, eBPF program references, the arraymap fd
> itself, another arraymap fd, etc.

The arraymap of Landlock handles is strongly typed and can check the
kind of FD it get when creating/updating an entry, which is done for the
cgroup type. It may be wise to add another check for FS types as well,
which should be a one-liner. I'll do it for the next round.


>>
>> It probably needs another limit for kernel object references as well.
>> What is the best option here? Add another static limitation or use an
>> existing one?
> 
> Dunno.  If RLIMIT_FILE could be made to work, that would be nice.

The RLIMIT_NOFILE is used for the eBPF map creation, but only the memory
limit is used to store the map entries (struct file pointers). I'll add
a new static limit for the number of FD-based arraymap entries because
it does not reflect the same semantic. The struct files are not usable
as FD, their only purpose is to be able to compare with another file.

 Mickaël



signature.asc
Description: OpenPGP digital signature

[PATCH 1/2] Documentation: mmc: sdhci-of-arasan: add description of power domain

[Ziyuan Xu]

Add power domain as a optional property for sdhci-of-arasan, which can
be truned off in the so-called unused condition, such as suspend and
remove. Aim to lower power requirements.

Signed-off-by: Ziyuan Xu 

---

 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 3404afa..3f5189c 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -1,12 +1,14 @@
 Device Tree Bindings for the Arasan SDHCI Controller
 
-  The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
+  The bindings follow the mmc[1], clock[2], interrupt[3], phy[4] and power
+  domain[5] bindings.
   Only deviations are documented here.
 
   [1] Documentation/devicetree/bindings/mmc/mmc.txt
   [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
   [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
   [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
+  [5] Documentation/devicetree/bindings/power/power_domain.txt
 
 Required Properties:
   - compatible: Compatibility string.  One of:
@@ -36,6 +38,8 @@ Optional Properties:
   - #clock-cells: If specified this should be the value <0>.  With this 
property
 in place we will export a clock representing the Card Clock.  This clock
 is expected to be consumed by our PHY.  You must also specify
+  - power-domains: A phandle of and PM domain as specifier defined by bindings
+of the power controller specified by phandle.
 
 Example:
sdhci@e010 {
-- 
2.9.2

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

[Matthijs van Duin]

Greetings, unfortunate souls trying to use the omap-i2c peripheral in
slave mode! :-)

I recently posted some stuff about exactly that topic on TI's E2E
forum, you may want to read this warning:
http://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1955843#1955843

and post contains suggestions on using slave mode and details on the
peripheral actually behaves:
http://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1959417#1959417

Matthijs

[PATCH 5/6] rtl8188eu: remove useless include

[Luca Ceresoli]

The proc filesystem is not used in this driver.

Signed-off-by: Luca Ceresoli 
Cc: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Cc: Binoy Jayan 
Cc: Anish Bhatt 
Cc: "Rémy Oudompheng" 
Cc: Alexey Khoroshilov 
Cc: Kyle Kuffermann 
Cc: linux-kernel@vger.kernel.org
---
 drivers/staging/rtl8188eu/include/osdep_service.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h 
b/drivers/staging/rtl8188eu/include/osdep_service.h
index 6f6a8f8c3b23..37eb3afeb93a 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -44,7 +44,6 @@
 #include 
 #include 
 #include 
-#include  /*  Necessary because we use the proc fs */
 #include/*  for struct tasklet_struct */
 #include 
 #include 
-- 
2.7.4

Re: [RFC v2 09/10] landlock: Handle cgroups (performance)

[Mickaël Salaün]

On 27/08/2016 01:05, Alexei Starovoitov wrote:
> On Fri, Aug 26, 2016 at 05:10:40PM +0200, Mickaël Salaün wrote:
>>
>>>
>>> - I don't think such 'for' loop can scale. The solution needs to work
>>> with thousands of containers and thousands of cgroups.
>>> In the patch 06/10 the proposal is to use 'current' as holder of
>>> the programs:
>>> +   for (prog = current->seccomp.landlock_prog;
>>> +   prog; prog = prog->prev) {
>>> +   if (prog->filter == landlock_ret->filter) {
>>> +   cur_ret = BPF_PROG_RUN(prog->prog, (void *)&ctx);
>>> +   break;
>>> +   }
>>> +   }
>>> imo that's the root of scalability issue.
>>> I think to be able to scale the bpf programs have to be attached to
>>> cgroups instead of tasks.
>>> That would be very different api. seccomp doesn't need to be touched.
>>> But that is the only way I see to be able to scale.
>>
>> Landlock is inspired from seccomp which also use a BPF program per
>> thread. For seccomp, each BPF programs are executed for each syscall.
>> For Landlock, some BPF programs are executed for some LSM hooks. I don't
>> see why it is a scale issue for Landlock comparing to seccomp. I also
>> don't see why storing the BPF program list pointer in the cgroup struct
>> instead of the task struct change a lot here. The BPF programs execution
>> will be the same anyway (for each LSM hook). Kees should probably have a
>> better opinion on this.
> 
> seccomp has its own issues and copying them doesn't make this lsm any better.
> Like seccomp bpf programs are all gigantic switch statement that looks
> for interesting syscall numbers. All syscalls of a task are paying
> non-trivial seccomp penalty due to such design. If bpf was attached per
> syscall it would have been much cheaper. Of course doing it this way
> for seccomp is not easy, but for lsm such facility is already there.
> Blank call of a single bpf prog for all lsm hooks is unnecessary
> overhead that can and should be avoided.

It's probably a misunderstanding. Contrary to seccomp which run all the
thread's BPF programs for any syscall, Landlock only run eBPF programs
for the triggered LSM hooks, if their type match. Indeed, thanks to the
multiple eBPF program types and contrary to seccomp, Landlock only run
an eBPF program when needed. Landlock will have almost no performance
overhead if the syscalls do not trigger the watched LSM hooks for the
current process.


> 
>>> May be another way of thinking about it is 'lsm cgroup controller'
>>> that Sargun is proposing.
>>> The lsm hooks will provide stable execution points and the programs
>>> will be called like:
>>> prog = task_css_set(current)->dfl_cgrp->bpf.prog_effective[lsm_hook_id];
>>> BPF_PROG_RUN(prog, ctx);
>>> The delegation functionality and 'prog_effective' logic that
>>> Daniel Mack is proposing will be fully reused here.
>>> External container management software will be able to apply bpf
>>> programs to control tasks under cgroup and such
>>> bpf_landlock_cmp_cgroup_beneath() helper won't be necessary.
>>> The user will be able to register different programs for different lsm 
>>> hooks.
>>> If I understand the patch 6/10 correctly, there is one (or a list) prog for
>>> all lsm hooks per task which is not flexible enough.
>>
>> For each LSM hook triggered by a thread, all of its Landlock eBPF
>> programs (dedicated for this kind of hook) will be evaluated (if
>> needed). This is the same behavior as seccomp (list of BPF programs
>> attached to a process hierarchy) except the BPF programs are not
>> evaluated for syscall but for LSM hooks. There is no way to make it more
>> fine-grained :)
> 
> There is a way to attach different bpf program per cgroup
> and per lsm hook. Such approach drastically reduces overhead
> of sandboxed application.

As said above, Landlock will not run an eBPF programs when not strictly
needed. Attaching to a cgroup will have the same performance impact as
attaching to a process hierarchy.



signature.asc
Description: OpenPGP digital signature

[PATCH RFC 1/4] lib/radix: add universal radix_tree_fill_range

[Konstantin Khlebnikov]

This patch adds function for filling and truncating ranges of slots:

radix_tree_node *radix_tree_fill_range(root, start, end, item, flags)

It fills slots in range "begin".."end" with "item" and returns pointer
to the last filled node. Filling with NULL truncates range.

This is intended for managing transparent huge pages in page cache where
all entries are aligned but this function can handle arbitrary unaligned
ranges. Might be useful for PAT or VMA-like extent trees.

By default filling range constructs shallow tree: entries are assigned
directly inner slots if possible. In worst case any range requires only
2 * RADIX_TREE_MAX_PATH nodes. If length is power of two and start index
is aligned then all slots are always in single node and requires at most
RADIX_TREE_MAX_PATH nodes.

Function accepts several flags:

RADIX_TREE_FILL_LEAVES  - build deep tree, insert entry into leaves.

RADIX_TREE_FILL_OVERWRITE - overwrite instead of failing with -EEXIST.

RADIX_TREE_FILL_ATOMIC - play well with concurrent RCU-protected lookup:
fill new nodes with RADIX_TREE_RETRY before inserting them into the tree.
At following iterations these slots are filled with @item or sub-nodes.

RADIX_TREE_FILL_CLEAR_TAGS - also clears all tags.

radix_tree_fill_range() returns pointer to the node which holds the last
slot in range, NULL if this is root slot, or ERR_PTR in case of error.

Thus, radix_tree_fill_range() can handle all operations required for THP:

* Insert
Fill range with pointer to head page.

radix_tree_fill_range(root, index, index + nr_pages - 1, head_page,
  RADIX_TREE_FILL_ATOMIC)

* Remove
Fill range with NULL or shadow entry, returned value will be used for
linking completely shadow nodes into slab shrinker.

radix_tree_fill_range(root, index, index + nr_pages - 1, NULL,
  RADIX_TREE_FILL_OVERWRITE)

* Merge
Fill range with overwrite to replace 0-order pages with THP.

radix_tree_fill_range(root, index, index + nr_pages - 1, head_page,
  RADIX_TREE_FILL_OVERWRITE | RADIX_TREE_FILL_ATOMIC)

* Split
Two passes: first fill leaves with head_page entry and then replace each
slot with pointer to individual tail page. This could be done in single
pass but makes radix_tree_fill_range much more complicated.

radix_tree_fill_range(root, index, index + nr_pages - 1, head_page,
  RADIX_TREE_FILL_LEAVES | RADIX_TREE_FILL_OVERWRITE |
  RADIX_TREE_FILL_ATOMIC);
radix_tree_for_each_slot(...)
radix_tree_replace_slot(slot, head + iter.index - head->index);


Page lookup and iterator will return pointer to head page for any index.


Code inside iterator loop could detect huge entry, handle all sub-pages
and jump to next index using new helper function radix_tree_iter_jump():

slot = radix_tree_iter_jump(&iter, page->index + hpage_nr_pages(page));

This helper has builtin protection against overflows: jump to index = 0
stops iterator. This uses existing logic in radix_tree_next_chunk():
if iter.next_index is zero then iter.index must be zero too.


Tags should be set only for last index of THP range: this way iterator
will find them regardless of starting index.

radix_tree_preload_range() pre-allocates nodes for filling range.

Signed-off-by: Konstantin Khlebnikov 
---
 include/linux/radix-tree.h |   46 
 lib/radix-tree.c   |  245 
 2 files changed, 291 insertions(+)

diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
index 4613bf35c311..af33e8d93ec3 100644
--- a/include/linux/radix-tree.h
+++ b/include/linux/radix-tree.h
@@ -319,6 +319,35 @@ static inline void radix_tree_preload_end(void)
preempt_enable();
 }
 
+#define RADIX_TREE_FILL_LEAVES 1 /* build full depth tree */
+#define RADIX_TREE_FILL_OVERWRITE  2 /* overwrite non-empty slots */
+#define RADIX_TREE_FILL_CLEAR_TAGS 4 /* clear all tags */
+#define RADIX_TREE_FILL_ATOMIC 8 /* play well with rcu lookup */
+
+struct radix_tree_node *
+radix_tree_fill_range(struct radix_tree_root *root, unsigned long start,
+ unsigned long end, void *item, unsigned int flags);
+
+int radix_tree_preload_range(gfp_t gfp_mask, unsigned long start,
+unsigned long end, unsigned int flags);
+
+/**
+ * radix_tree_truncate_range  - remove everything in range
+ * @root:  radix tree root
+ * @start: first index
+ * @end:   last index
+ *
+ * This function removes all items and tags within given range.
+ */
+static inline void
+radix_tree_truncate_range(struct radix_tree_root *root,
+ unsigned long start, unsigned long end)
+{
+   radix_tree_fill_range(root, start, end, NULL,
+ RADIX_TREE_FILL_OVERWRITE |
+ RADIX_TREE_FILL_CLEAR_TAGS);
+}
+
 /**
  * struct radix_tree_iter - radix tree iterator state
  *
@@ -435,6 +464,23 @@ void **radix_tree_

[PATCH RFC 3/4] testing/radix-tree: replace multi-order with range operations

[Konstantin Khlebnikov]

This patch updates test for multi-order operations according to changes
in radix-tree: huge entry now must remember its range.

Signed-off-by: Konstantin Khlebnikov 
---
 tools/testing/radix-tree/linux/bug.h  |2 -
 tools/testing/radix-tree/linux/err.h  |   31 
 tools/testing/radix-tree/linux/kernel.h   |3 +
 tools/testing/radix-tree/linux/rcupdate.h |6 ++
 tools/testing/radix-tree/multiorder.c |  113 -
 tools/testing/radix-tree/test.c   |   49 ++---
 tools/testing/radix-tree/test.h   |   15 ++--
 7 files changed, 151 insertions(+), 68 deletions(-)
 create mode 100644 tools/testing/radix-tree/linux/err.h

diff --git a/tools/testing/radix-tree/linux/bug.h 
b/tools/testing/radix-tree/linux/bug.h
index ccbe444977df..7a77fa971e91 100644
--- a/tools/testing/radix-tree/linux/bug.h
+++ b/tools/testing/radix-tree/linux/bug.h
@@ -1 +1 @@
-#define WARN_ON_ONCE(x)assert(x)
+#define WARN_ON_ONCE(x)assert(!(x))
diff --git a/tools/testing/radix-tree/linux/err.h 
b/tools/testing/radix-tree/linux/err.h
new file mode 100644
index ..6fd3e608d4d7
--- /dev/null
+++ b/tools/testing/radix-tree/linux/err.h
@@ -0,0 +1,31 @@
+#ifndef _LINUX_ERR_H
+#define _LINUX_ERR_H
+
+#define MAX_ERRNO   4095
+
+#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
+
+static inline void *ERR_PTR(long error)
+{
+   return (void *) error;
+}
+
+static inline long PTR_ERR(const void *ptr)
+{
+   return (long) ptr;
+}
+
+static inline bool IS_ERR(const void *ptr)
+{
+   return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+static inline int PTR_ERR_OR_ZERO(const void *ptr)
+{
+   if (IS_ERR(ptr))
+   return PTR_ERR(ptr);
+   else
+   return 0;
+}
+
+#endif /* _LINUX_ERR_H */
diff --git a/tools/testing/radix-tree/linux/kernel.h 
b/tools/testing/radix-tree/linux/kernel.h
index be98a47b4e1b..52714e86991b 100644
--- a/tools/testing/radix-tree/linux/kernel.h
+++ b/tools/testing/radix-tree/linux/kernel.h
@@ -32,6 +32,9 @@
 
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
 
+#define IS_ALIGNED(x, a)   (((x) & ((typeof(x))(a) - 1)) == 0)
+#define is_power_of_2(n)   ((n) != 0 && (((n) & ((n) - 1)) == 0))
+
 #define container_of(ptr, type, member) ({  \
const typeof( ((type *)0)->member ) *__mptr = (ptr);\
(type *)( (char *)__mptr - offsetof(type, member) );})
diff --git a/tools/testing/radix-tree/linux/rcupdate.h 
b/tools/testing/radix-tree/linux/rcupdate.h
index f7129ea2a899..8c4ae8173778 100644
--- a/tools/testing/radix-tree/linux/rcupdate.h
+++ b/tools/testing/radix-tree/linux/rcupdate.h
@@ -3,6 +3,12 @@
 
 #include 
 
+/* urcu.h includes errno.h which undefines ERANGE */
+#ifndef ERANGE
+#define ERANGE 34
+#endif
+
+#define RCU_INIT_POINTER(p, v) rcu_assign_pointer(p, v)
 #define rcu_dereference_raw(p) rcu_dereference(p)
 #define rcu_dereference_protected(p, cond) rcu_dereference(p)
 
diff --git a/tools/testing/radix-tree/multiorder.c 
b/tools/testing/radix-tree/multiorder.c
index 39d9b9568fe2..f73a3bfa83d8 100644
--- a/tools/testing/radix-tree/multiorder.c
+++ b/tools/testing/radix-tree/multiorder.c
@@ -29,7 +29,7 @@ static void __multiorder_tag_test(int index, int order)
unsigned long first = 0;
 
/* our canonical entry */
-   base = index & ~((1 << order) - 1);
+   base = index;
 
printf("Multiorder tag test with index %d, canonical entry %d\n",
index, base);
@@ -43,7 +43,7 @@ static void __multiorder_tag_test(int index, int order)
 * item_insert_order().
 */
for_each_index(i, base, order) {
-   err = __radix_tree_insert(&tree, i, order,
+   err = radix_tree_insert(&tree, i,
(void *)(0xA0 | RADIX_TREE_EXCEPTIONAL_ENTRY));
assert(err == -EEXIST);
}
@@ -55,18 +55,18 @@ static void __multiorder_tag_test(int index, int order)
 
assert(radix_tree_tag_set(&tree, index, 0));
 
-   for_each_index(i, base, order) {
-   assert(radix_tree_tag_get(&tree, i, 0));
+   assert(radix_tree_tag_get(&tree, index, 0));
+
+   for_each_index(i, base, order)
assert(!radix_tree_tag_get(&tree, i, 1));
-   }
 
assert(radix_tree_range_tag_if_tagged(&tree, &first, ~0UL, 10, 0, 1) == 
1);
assert(radix_tree_tag_clear(&tree, index, 0));
 
-   for_each_index(i, base, order) {
+   assert(radix_tree_tag_get(&tree, index, 1));
+
+   for_each_index(i, base, order)
assert(!radix_tree_tag_get(&tree, i, 0));
-   assert(radix_tree_tag_get(&tree, i, 1));
-   }
 
assert(radix_tree_tag_clear(&tree, index, 1));
 
@@ -122,7 +122,7 @@ static void multiorder_tag_tests(void)
 static void multiorder_check(unsigned long index, int order)
 {
unsigned long i;
- 

[PATCH RFC 2/4] lib/radix-tree: remove sibling entries

[Konstantin Khlebnikov]

Current implementation stores huge entry as "canonical" head entry with
tail of "sibling" entries which points backward to the head. Iterator
jumps back and forward when sees them. This complication is required for
THP in page-cache because struct page can tell it start index and size.

This patch removes support of sibling entries but keeps part that allows
store data pointers in non-leaf slots. Huge pages will be stored as range
of slots which points to the head page.

This allows to simplify fast-path in radix_tree_next_chunk(): huge entry
is reported as single-slot chunk for any index within range.

Signed-off-by: Konstantin Khlebnikov 
---
 include/linux/radix-tree.h |   75 -
 lib/radix-tree.c   |  158 +---
 2 files changed, 60 insertions(+), 173 deletions(-)

diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
index af33e8d93ec3..1721ddbf981d 100644
--- a/include/linux/radix-tree.h
+++ b/include/linux/radix-tree.h
@@ -37,8 +37,8 @@
  * 10 - exceptional entry
  * 11 - this bit combination is currently unused/reserved
  *
- * The internal entry may be a pointer to the next level in the tree, a
- * sibling entry, or an indicator that the entry in this slot has been moved
+ * The internal entry may be a pointer to the next level in the tree
+ * or an indicator that the entry in this slot has been moved
  * to another location in the tree and the lookup should be restarted.  While
  * NULL fits the 'data pointer' pattern, it means that there is no entry in
  * the tree for this index (no matter what level of the tree it is found at).
@@ -265,13 +265,7 @@ static inline void radix_tree_replace_slot(void **pslot, 
void *item)
 int __radix_tree_create(struct radix_tree_root *root, unsigned long index,
unsigned order, struct radix_tree_node **nodep,
void ***slotp);
-int __radix_tree_insert(struct radix_tree_root *, unsigned long index,
-   unsigned order, void *);
-static inline int radix_tree_insert(struct radix_tree_root *root,
-   unsigned long index, void *entry)
-{
-   return __radix_tree_insert(root, index, 0, entry);
-}
+int radix_tree_insert(struct radix_tree_root *, unsigned long index, void *);
 void *__radix_tree_lookup(struct radix_tree_root *root, unsigned long index,
  struct radix_tree_node **nodep, void ***slotp);
 void *radix_tree_lookup(struct radix_tree_root *, unsigned long);
@@ -354,7 +348,6 @@ radix_tree_truncate_range(struct radix_tree_root *root,
  * @index: index of current slot
  * @next_index:one beyond the last index for this chunk
  * @tags:  bit-mask for tag-iterating
- * @shift: shift for the node that holds our slots
  *
  * This radix tree iterator works in terms of "chunks" of slots.  A chunk is a
  * subinterval of slots contained within one radix tree leaf node.  It is
@@ -367,20 +360,8 @@ struct radix_tree_iter {
unsigned long   index;
unsigned long   next_index;
unsigned long   tags;
-#ifdef CONFIG_RADIX_TREE_MULTIORDER
-   unsigned intshift;
-#endif
 };
 
-static inline unsigned int iter_shift(struct radix_tree_iter *iter)
-{
-#ifdef CONFIG_RADIX_TREE_MULTIORDER
-   return iter->shift;
-#else
-   return 0;
-#endif
-}
-
 #define RADIX_TREE_ITER_TAG_MASK   0x00FF  /* tag index in lower byte */
 #define RADIX_TREE_ITER_TAGGED 0x0100  /* lookup tagged slots */
 #define RADIX_TREE_ITER_CONTIG 0x0200  /* stop at first hole */
@@ -441,12 +422,6 @@ void **radix_tree_iter_retry(struct radix_tree_iter *iter)
return NULL;
 }
 
-static inline unsigned long
-__radix_tree_iter_add(struct radix_tree_iter *iter, unsigned long slots)
-{
-   return iter->index + (slots << iter_shift(iter));
-}
-
 /**
  * radix_tree_iter_next - resume iterating when the chunk may be invalid
  * @iter:  iterator state
@@ -458,7 +433,7 @@ __radix_tree_iter_add(struct radix_tree_iter *iter, 
unsigned long slots)
 static inline __must_check
 void **radix_tree_iter_next(struct radix_tree_iter *iter)
 {
-   iter->next_index = __radix_tree_iter_add(iter, 1);
+   iter->next_index = iter->index + 1;
iter->tags = 0;
return NULL;
 }
@@ -489,7 +464,7 @@ void **radix_tree_iter_jump(struct radix_tree_iter *iter, 
unsigned long index)
 static __always_inline long
 radix_tree_chunk_size(struct radix_tree_iter *iter)
 {
-   return (iter->next_index - iter->index) >> iter_shift(iter);
+   return iter->next_index - iter->index;
 }
 
 static inline struct radix_tree_node *entry_to_node(void *ptr)
@@ -508,6 +483,9 @@ static inline struct radix_tree_node *entry_to_node(void 
*ptr)
  * This function updates @iter->index in the case of a successful lookup.
  * For tagged lookup it also eats @iter->tags.
  *
+ * Please keep this fast-path as small as possible. Complicated logic is hidden
+ * inside radix_tree

[PATCH RFC 4/4] testing/radix-tree: benchmark for iterator

[Konstantin Khlebnikov]

This adds simple benchmark for iterator similar to one I've used for
commit 78c1d78488a3 ("radix-tree: introduce bit-optimized iterator")

Building with make BENCHMARK=1 set radix tree order to 6 and adds -O2,
this allows to get performance comparable to in kernel performance.

Signed-off-by: Konstantin Khlebnikov 
---
 tools/testing/radix-tree/Makefile   |6 ++
 tools/testing/radix-tree/benchmark.c|  101 +++
 tools/testing/radix-tree/linux/kernel.h |4 +
 tools/testing/radix-tree/main.c |2 +
 tools/testing/radix-tree/test.h |1 
 5 files changed, 113 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/radix-tree/benchmark.c

diff --git a/tools/testing/radix-tree/Makefile 
b/tools/testing/radix-tree/Makefile
index 6079ec142685..1594335d1ed6 100644
--- a/tools/testing/radix-tree/Makefile
+++ b/tools/testing/radix-tree/Makefile
@@ -4,7 +4,11 @@ LDFLAGS += -lpthread -lurcu
 TARGETS = main
 OFILES = main.o radix-tree.o linux.o test.o tag_check.o find_next_bit.o \
 regression1.o regression2.o regression3.o multiorder.o \
-iteration_check.o
+iteration_check.o benchmark.o
+
+ifdef BENCHMARK
+   CFLAGS += -DBENCHMARK=1 -O2
+endif
 
 targets: $(TARGETS)
 
diff --git a/tools/testing/radix-tree/benchmark.c 
b/tools/testing/radix-tree/benchmark.c
new file mode 100644
index ..05d46071bf37
--- /dev/null
+++ b/tools/testing/radix-tree/benchmark.c
@@ -0,0 +1,101 @@
+/*
+ * benchmark.c:
+ * Author: Konstantin Khlebnikov 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "test.h"
+
+#define NSEC_PER_SEC   10L
+
+static long long benchmark_iter(struct radix_tree_root *root, bool tagged)
+{
+   volatile unsigned long sink = 0;
+   struct radix_tree_iter iter;
+   struct timespec start, finish;
+   long long nsec;
+   int l, loops = 1;
+   void **slot;
+
+#ifdef BENCHMARK
+again:
+#endif
+   clock_gettime(CLOCK_MONOTONIC, &start);
+   for (l = 0; l < loops; l++) {
+   if (tagged) {
+   radix_tree_for_each_tagged(slot, root, &iter, 0, 0)
+   sink ^= (unsigned long)slot;
+   } else {
+   radix_tree_for_each_slot(slot, root, &iter, 0)
+   sink ^= (unsigned long)slot;
+   }
+   }
+   clock_gettime(CLOCK_MONOTONIC, &finish);
+
+   nsec = (finish.tv_sec - start.tv_sec) * NSEC_PER_SEC +
+  (finish.tv_nsec - start.tv_nsec);
+
+#ifdef BENCHMARK
+   if (loops == 1 && nsec * 5 < NSEC_PER_SEC) {
+   loops = NSEC_PER_SEC / nsec / 4 + 1;
+   goto again;
+   }
+#endif
+
+   nsec /= loops;
+   return nsec;
+}
+
+static void benchmark_size(unsigned long size, unsigned long step, int order)
+{
+   RADIX_TREE(tree, GFP_KERNEL);
+   long long normal, tagged;
+   unsigned long index;
+
+   for (index = 0 ; index < size ; index += step) {
+   item_insert_order(&tree, index, order);
+   radix_tree_tag_set(&tree, item_order_end(index, order), 0);
+   }
+
+   tagged = benchmark_iter(&tree, true);
+   normal = benchmark_iter(&tree, false);
+
+   printf("Size %ld, step %6ld, order %d tagged %10lld ns, normal %10lld 
ns\n",
+   size, step, order, tagged, normal);
+
+   item_kill_tree(&tree);
+}
+
+void benchmark(void)
+{
+   unsigned long size[] = {1 << 10, 1 << 20,
+#ifdef BENCHMARK
+   1 << 27,
+#endif
+   0};
+   unsigned long step[] = {1, 2, 7, 15, 63, 64, 65,
+   128, 256, 512, 12345, 0};
+   int c, s;
+
+   printf("starting benchmarks\n");
+   printf("RADIX_TREE_MAP_SHIFT = %d\n", RADIX_TREE_MAP_SHIFT);
+
+   for (c = 0; size[c]; c++)
+   for (s = 0; step[s]; s++)
+   benchmark_size(size[c], step[s], 0);
+
+   for (c = 0; size[c]; c++)
+   for (s = 0; step[s]; s++)
+   benchmark_size(size[c], step[s] << 9, 9);
+}
diff --git a/tools/testing/radix-tree/linux/kernel.h 
b/tools/testing/radix-tree/linux/kernel.h
index 52714e86991b..ddabc495423f 100644
--- a/tools/testing/radix-tree/linux/kernel.h
+++ b/tools/testing/radix-tree/linux/kernel.h
@@ -10,7 +10,11 @@
 #include "../../include/linux/compiler.h"
 #include "../../../include/linux/kconfig.h"
 
+#ifdef BENCHMARK
+#define RADIX_TREE_MAP_SHIFT   6
+#else
 #define RADIX_TREE_MAP_SHIFT 

Re: [RFC v2 09/10] landlock: Handle cgroups (netfilter match)

[Mickaël Salaün]

On 27/08/2016 01:05, Alexei Starovoitov wrote:
> On Fri, Aug 26, 2016 at 05:10:40PM +0200, Mickaël Salaün wrote:
>> To sum up, there is four related patchsets:
>> * "Landlock LSM: Unprivileged sandboxing" (this series)
>> * "Add Checmate, BPF-driven minor LSM" (Sargun Dhillon)
>> * "Networking cgroup controller" (Anoop Naravaram)
>> * "Add eBPF hooks for cgroups" (Daniel Mack)

>>> Anoop Naravaram's use case is to control the ports the applications
>>> under cgroup can bind and listen on.
>>> Such use case can be solved by such 'lsm cgroup controller' by
>>> attaching bpf program to security_socket_bind lsm hook and
>>> filtering sockaddr.
>>> Furthermore Sargun's use case is to allow further sockaddr rewrites
>>> from the bpf program which can be done as natural extension
>>> of such mechanism.
>>>
>>> If I understood Daniel's Anoop's Sargun's and yours use cases
>>> correctly the common piece of kernel infrastructure that can solve
>>> them all can start from Daniel's current set of patches that
>>> establish a mechanism of attaching bpf program to a cgroup.
>>> Then adding lsm hooks to it and later allowing argument rewrite
>>> (since they're already in the kernel and no ToCToU problems exist)

>> For the network-related series, I think it make more sense to simply
>> create a netfilter rule matching a cgroup and then add more features to
>> netfilter (restrict port ranges and so on) thanks to eBPF programs.
>> Containers are (usually) in a dedicated network namespace, which open
>> the possibility to not only rely on cgroups (e.g. match UID,
>> netmask...). It would also be more flexible to be able to load a BPF
>> program in netfilter and update its maps on the fly to make dynamic
>> rules, like ipset does, but in a more generic way.

What do the netdev folks think about this design?



signature.asc
Description: OpenPGP digital signature

Re: [RFC v2 09/10] landlock: Handle cgroups (program types)

[Mickaël Salaün]

On 27/08/2016 01:05, Alexei Starovoitov wrote:
> On Fri, Aug 26, 2016 at 05:10:40PM +0200, Mickaël Salaün wrote:
>
>>> As far as safety and type checking that bpf programs has to do,
>>> I like the approach of patch 06/10:
>>> +LANDLOCK_HOOK2(file_open, FILE_OPEN,
>>> +   PTR_TO_STRUCT_FILE, struct file *, file,
>>> +   PTR_TO_STRUCT_CRED, const struct cred *, cred
>>> +)
>>> teaching verifier to recognize struct file, cred, sockaddr
>>> will let bpf program access them naturally without any overhead.
>>> Though:
>>> @@ -102,6 +102,9 @@ enum bpf_prog_type {
>>> BPF_PROG_TYPE_SCHED_CLS,
>>> BPF_PROG_TYPE_SCHED_ACT,
>>> BPF_PROG_TYPE_TRACEPOINT,
>>> +   BPF_PROG_TYPE_LANDLOCK_FILE_OPEN,
>>> +   BPF_PROG_TYPE_LANDLOCK_FILE_PERMISSION,
>>> +   BPF_PROG_TYPE_LANDLOCK_MMAP_FILE,
>>>  };
>>> is a bit of overkill.
>>> I think it would be cleaner to have single
>>> BPF_PROG_TYPE_LSM and at program load time pass
>>> lsm_hook_id as well, so that verifier can do safety checks
>>> based on type info provided in LANDLOCK_HOOKs
>>
>> I first started with a unique BPF_PROG_TYPE but, the thing is, the BPF
>> verifier check programs according to their types. If we need to check
>> specific context value types (e.g. PTR_TO_STRUCT_FILE), we need a
>> dedicated program types. I don't see any other way to do it with the
>> current verifier code. Moreover it's the purpose of program types, right?
> 
> Adding new bpf program type for every lsm hook is not acceptable.
> Either do one new program type + pass lsm_hook_id as suggested
> or please come up with an alternative approach.

OK, so we have to modify the verifier to not only rely on the program
type but on another value to check the context accesses. Do you have a
hint from where this value could come from? Do we need to add a new bpf
command to associate a program to a subtype?



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 6/8] hwrng: amd: Replace global variable with private struct

[Jason Cooper]

Hi Corentin,

On Fri, Aug 26, 2016 at 01:11:34PM +0200, LABBE Corentin wrote:
> Instead of having two global variable, it's better to use a
> private struct. This will permit to remove amd_pdev variable
> 
> Signed-off-by: LABBE Corentin 
> ---
>  drivers/char/hw_random/amd-rng.c | 57 
> ++--
>  1 file changed, 38 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/char/hw_random/amd-rng.c 
> b/drivers/char/hw_random/amd-rng.c
> index 383e197..4ef94e9 100644
> --- a/drivers/char/hw_random/amd-rng.c
> +++ b/drivers/char/hw_random/amd-rng.c
> @@ -47,15 +47,18 @@ static const struct pci_device_id pci_tbl[] = {
>  };
>  MODULE_DEVICE_TABLE(pci, pci_tbl);
>  
> -static struct pci_dev *amd_pdev;
> +struct amd768_priv {
> + struct pci_dev *pcidev;
> + u32 pmbase;
> +};
>  
>  static int amd_rng_data_present(struct hwrng *rng, int wait)
>  {
> - u32 pmbase = (u32)rng->priv;
> + struct amd768_priv *priv = (struct amd768_priv *)rng->priv;

Please remove unnecessary casts...

>   int data, i;
>  
>   for (i = 0; i < 20; i++) {
> - data = !!(inl(pmbase + 0xF4) & 1);
> + data = !!(inl(priv->pmbase + 0xF4) & 1);
>   if (data || !wait)
>   break;
>   udelay(10);
> @@ -65,35 +68,37 @@ static int amd_rng_data_present(struct hwrng *rng, int 
> wait)
>  
>  static int amd_rng_data_read(struct hwrng *rng, u32 *data)
>  {
> - u32 pmbase = (u32)rng->priv;
> + struct amd768_priv *priv = (struct amd768_priv *)rng->priv;

here,

>  
> - *data = inl(pmbase + 0xF0);
> + *data = inl(priv->pmbase + 0xF0);
>  
>   return 4;
>  }
>  
>  static int amd_rng_init(struct hwrng *rng)
>  {
> + struct amd768_priv *priv = (struct amd768_priv *)rng->priv;

here,

>   u8 rnen;
>  
> - pci_read_config_byte(amd_pdev, 0x40, &rnen);
> + pci_read_config_byte(priv->pcidev, 0x40, &rnen);
>   rnen |= BIT(7); /* RNG on */
> - pci_write_config_byte(amd_pdev, 0x40, rnen);
> + pci_write_config_byte(priv->pcidev, 0x40, rnen);
>  
> - pci_read_config_byte(amd_pdev, 0x41, &rnen);
> + pci_read_config_byte(priv->pcidev, 0x41, &rnen);
>   rnen |= BIT(7); /* PMIO enable */
> - pci_write_config_byte(amd_pdev, 0x41, rnen);
> + pci_write_config_byte(priv->pcidev, 0x41, rnen);
>  
>   return 0;
>  }
>  
>  static void amd_rng_cleanup(struct hwrng *rng)
>  {
> + struct amd768_priv *priv = (struct amd768_priv *)rng->priv;

here,

>   u8 rnen;
>  
> - pci_read_config_byte(amd_pdev, 0x40, &rnen);
> + pci_read_config_byte(priv->pcidev, 0x40, &rnen);
>   rnen &= ~BIT(7);/* RNG off */
> - pci_write_config_byte(amd_pdev, 0x40, rnen);
> + pci_write_config_byte(priv->pcidev, 0x40, rnen);
>  }
>  
>  static struct hwrng amd_rng = {
> @@ -110,6 +115,7 @@ static int __init mod_init(void)
>   struct pci_dev *pdev = NULL;
>   const struct pci_device_id *ent;
>   u32 pmbase;
> + struct amd768_priv *priv;
>  
>   for_each_pci_dev(pdev) {
>   ent = pci_match_id(pci_tbl, pdev);
> @@ -117,24 +123,30 @@ static int __init mod_init(void)
>   goto found;
>   }
>   /* Device not found. */
> - goto out;
> + return -ENODEV;
>  
>  found:
>   err = pci_read_config_dword(pdev, 0x58, &pmbase);
>   if (err)
> - goto out;
> - err = -EIO;
> + return err;
> +
>   pmbase &= 0xFF00;
>   if (pmbase == 0)
> - goto out;
> + return -EIO;
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
>   if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
>   dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
>   pmbase + 0xF0);
>   err = -EBUSY;
>   goto out;
>   }
> - amd_rng.priv = (unsigned long)pmbase;
> - amd_pdev = pdev;
> + amd_rng.priv = (unsigned long)priv;

here,

> + priv->pmbase = pmbase;
> + priv->pcidev = pdev;
>  
>   pr_info(DRV_NAME " detected\n");
>   err = hwrng_register(&amd_rng);
> @@ -143,17 +155,24 @@ found:
>   release_region(pmbase + 0xF0, 8);
>   goto out;
>   }
> + return 0;
> +
>  out:
> + kfree(priv);
>   return err;
>  }
>  
>  static void __exit mod_exit(void)
>  {
> - u32 pmbase = (unsigned long)amd_rng.priv;
> + struct amd768_priv *priv;
> +
> + priv = (struct amd768_priv *)amd_rng.priv;

and here.

thx,

Jason.

>  
>   hwrng_unregister(&amd_rng);
>  
> - release_region(pmbase + 0xF0, 8);
> + release_region(priv->pmbase + 0xF0, 8);
> +
> + kfree(priv);
>  }
>  
>  module_init(mod_init);
> -- 
> 2.7.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/maj

Re: [PATCH v3 0/8] hwrng: amd: rework of the amd hwrng driver

[Jason Cooper]

Hi Corentin,

On Fri, Aug 26, 2016 at 01:11:28PM +0200, LABBE Corentin wrote:
> Changes since v2:
>  - split the latest patch in 4
> Changes since v1:
>  - Keep the hwrng name as "amd"
> 
> LABBE Corentin (8):
>   hwrng: amd: Fix style problem with blank line
>   hwrng: amd: use the BIT macro
>   hwrng: amd: Be consitent with the driver name
>   hwrng: amd: Remove asm/io.h
>   hwrng: amd: release_region must be called after hwrng_unregister
>   hwrng: amd: Replace global variable with private struct
>   hwrng: amd: Access hardware via ioread32/iowrite32
>   hwrng: amd: Convert to new hwrng read() API
> 
>  drivers/char/hw_random/amd-rng.c | 150 
> +--
>  1 file changed, 96 insertions(+), 54 deletions(-)

Once you've fixed up the casting in #6, you can add my

Reviewed-by: Jason Cooper 

to the series.

thx,

Jason.

Re: [PATCH 1/2] Documentation: mmc: sdhci-of-arasan: add description of power domain

[Shawn Lin]

On 2016/8/27 21:41, Ziyuan Xu wrote:

Add power domain as a optional property for sdhci-of-arasan, which can
be truned off in the so-called unused condition, such as suspend and
remove. Aim to lower power requirements.

Signed-off-by: Ziyuan Xu 

---

 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 3404afa..3f5189c 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -1,12 +1,14 @@
 Device Tree Bindings for the Arasan SDHCI Controller

-  The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
+  The bindings follow the mmc[1], clock[2], interrupt[3], phy[4] and power
+  domain[5] bindings.
   Only deviations are documented here.

   [1] Documentation/devicetree/bindings/mmc/mmc.txt
   [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
   [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
   [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
+  [5] Documentation/devicetree/bindings/power/power_domain.txt

 Required Properties:
   - compatible: Compatibility string.  One of:
@@ -36,6 +38,8 @@ Optional Properties:
   - #clock-cells: If specified this should be the value <0>.  With this 
property
 in place we will export a clock representing the Card Clock.  This clock
 is expected to be consumed by our PHY.  You must also specify
+  - power-domains: A phandle of and PM domain as specifier defined by bindings


A phandle of what?


+of the power controller specified by phandle.

 Example:
sdhci@e010 {


It would be nice to add the example code.






--
Best Regards
Shawn Lin

Re: [PATCH] f2fs: fix to set superblock dirty correctly

[Chao Yu]

On 2016/8/27 9:01, Jaegeuk Kim wrote:
> On Fri, Aug 26, 2016 at 10:20:18PM +0800, Chao Yu wrote:
>> From: Chao Yu 
>>
>> tests/generic/251 of fstest suit complains us with below message:
>>
>> [ cut here ]
>> invalid opcode:  [#1] PREEMPT SMP
>> CPU: 2 PID: 7698 Comm: fstrim Tainted: G   O4.7.0+ #21
>> task: e9f4e000 task.stack: e7262000
>> EIP: 0060:[] EFLAGS: 00010202 CPU: 2
>> EIP is at write_checkpoint+0xfde/0x1020 [f2fs]
>> EAX: f33eb300 EBX: eecac310 ECX: 0001 EDX: 0001
>> ESI: eecac000 EDI: eecac5f0 EBP: e7263dec ESP: e7263d18
>>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>> CR0: 80050033 CR2: b76ab01c CR3: 2eb89de0 CR4: 000406f0
>> Stack:
>>  0001 a220fb7b e9f4e000 0002 419ff2d3 b3a05151 0002 e9f4e5d8
>>  e9f4e000 419ff2d3 b3a05151 eecac310 c10b8154 b3a05151 419ff2d3 c10b78bd
>>  e9f4e000 e9f4e000 e9f4e5d8 0001 e9f4e000 ec409000 eecac2cc eecac288
>> Call Trace:
>>  [] ? __lock_acquire+0x3c4/0x760
>>  [] ? mark_held_locks+0x5d/0x80
>>  [] f2fs_trim_fs+0x1c2/0x2e0 [f2fs]
>>  [] f2fs_ioctl+0x6b6/0x10b0 [f2fs]
>>  [] ? __this_cpu_preempt_check+0xf/0x20
>>  [] ? trace_hardirqs_off_caller+0x91/0x120
>>  [] ? __exchange_data_block+0xd30/0xd30 [f2fs]
>>  [] do_vfs_ioctl+0x81/0x7f0
>>  [] ? kmem_cache_free+0x245/0x2e0
>>  [] ? get_unused_fd_flags+0x40/0x40
>>  [] ? putname+0x4c/0x50
>>  [] ? do_sys_open+0x16e/0x1d0
>>  [] ? do_fast_syscall_32+0x30/0x1c0
>>  [] ? __this_cpu_preempt_check+0xf/0x20
>>  [] SyS_ioctl+0x58/0x80
>>  [] do_fast_syscall_32+0xa1/0x1c0
>>  [] sysenter_past_esp+0x45/0x74
>> EIP: [] write_checkpoint+0xfde/0x1020 [f2fs] SS:ESP 0068:e7263d18
>> ---[ end trace 4de95d7e6b3aa7c6 ]---
>>
>> The reason is: with below call stack, we will encounter BUG_ON during
>> doing fstrim.
>>
>> Thread A Thread B
>> - write_checkpoint
>>  - do_checkpoint
>>  - f2fs_write_inode
>>   - update_inode_page
>>- update_inode
>> - set_page_dirty
>>  - f2fs_set_node_page_dirty
>>   - inc_page_count
>>- percpu_counter_inc
>>- set_sbi_flag(SBI_IS_DIRTY)
>>   - clear_sbi_flag(SBI_IS_DIRTY)
>>
>> Thread C Thread D
>> - f2fs_write_node_page
>>  - set_node_addr
>>   - __set_nat_cache_dirty
>>- nm_i->dirty_nat_cnt++
>>  - do_vfs_ioctl
>>   - f2fs_ioctl
>>- f2fs_trim_fs
>> - write_checkpoint
>>  - f2fs_bug_on(nm_i->dirty_nat_cnt)
>>
>> Fix it by setting superblock dirty correctly in do_checkpoint and
>> f2fs_write_node_page.
>>
>> Signed-off-by: Chao Yu 
>> ---
>>  fs/f2fs/checkpoint.c | 4 
>>  fs/f2fs/node.c   | 1 +
>>  2 files changed, 5 insertions(+)
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index cd0443d..68c723c 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -1153,6 +1153,10 @@ static int do_checkpoint(struct f2fs_sb_info *sbi, 
>> struct cp_control *cpc)
>>  clear_prefree_segments(sbi, cpc);
>>  clear_sbi_flag(sbi, SBI_IS_DIRTY);
>>  
>> +/* redirty superblock if node page is updated by ->write_inode */
>> +if (get_pages(sbi, F2FS_DIRTY_NODES))
> 
> Need to check F2FS_DIRTY_IMETA and F2FS_DIRTY_DENTS as well?

Need to check F2FS_DIRTY_IMETA additionally? since F2FS_DIRTY_DENTS will not be
updated during checkpoint.

> And, if we have this, I don't think we need to worry about f2fs_lock_op() for
> update_inode_page() as well.

OK, I didn't find any data consistency issue related to this so far.

Thanks,

> 
> Thanks,
> 
>> +set_sbi_flag(sbi, SBI_IS_DIRTY);
>> +
>>  return 0;
>>  }
>>  
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 8a28800..365c6ff 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1597,6 +1597,7 @@ static int f2fs_write_node_page(struct page *page,
>>  fio.old_blkaddr = ni.blk_addr;
>>  write_node_page(nid, &fio);
>>  set_node_addr(sbi, &ni, fio.new_blkaddr, is_fsync_dnode(page));
>> +set_sbi_flag(sbi, SBI_IS_DIRTY);
>>  dec_page_count(sbi, F2FS_DIRTY_NODES);
>>  up_read(&sbi->node_write);
>>  
>> -- 
>> 2.7.2

Re: [f2fs-dev] [PATCH] f2fs: fix to set superblock dirty correctly

[Chao Yu]

Hi Yunlei,

On 2016/8/27 9:54, heyunlei wrote:
> Hi all,
> 
> On 2016/8/27 9:01, Jaegeuk Kim wrote:
>> On Fri, Aug 26, 2016 at 10:20:18PM +0800, Chao Yu wrote:
>>> From: Chao Yu 
>>>
>>> tests/generic/251 of fstest suit complains us with below message:
>>>
>>> [ cut here ]
>>> invalid opcode:  [#1] PREEMPT SMP
>>> CPU: 2 PID: 7698 Comm: fstrim Tainted: G   O4.7.0+ #21
>>> task: e9f4e000 task.stack: e7262000
>>> EIP: 0060:[] EFLAGS: 00010202 CPU: 2
>>> EIP is at write_checkpoint+0xfde/0x1020 [f2fs]
>>> EAX: f33eb300 EBX: eecac310 ECX: 0001 EDX: 0001
>>> ESI: eecac000 EDI: eecac5f0 EBP: e7263dec ESP: e7263d18
>>>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>>> CR0: 80050033 CR2: b76ab01c CR3: 2eb89de0 CR4: 000406f0
>>> Stack:
>>>  0001 a220fb7b e9f4e000 0002 419ff2d3 b3a05151 0002 e9f4e5d8
>>>  e9f4e000 419ff2d3 b3a05151 eecac310 c10b8154 b3a05151 419ff2d3 c10b78bd
>>>  e9f4e000 e9f4e000 e9f4e5d8 0001 e9f4e000 ec409000 eecac2cc eecac288
>>> Call Trace:
>>>  [] ? __lock_acquire+0x3c4/0x760
>>>  [] ? mark_held_locks+0x5d/0x80
>>>  [] f2fs_trim_fs+0x1c2/0x2e0 [f2fs]
>>>  [] f2fs_ioctl+0x6b6/0x10b0 [f2fs]
>>>  [] ? __this_cpu_preempt_check+0xf/0x20
>>>  [] ? trace_hardirqs_off_caller+0x91/0x120
>>>  [] ? __exchange_data_block+0xd30/0xd30 [f2fs]
>>>  [] do_vfs_ioctl+0x81/0x7f0
>>>  [] ? kmem_cache_free+0x245/0x2e0
>>>  [] ? get_unused_fd_flags+0x40/0x40
>>>  [] ? putname+0x4c/0x50
>>>  [] ? do_sys_open+0x16e/0x1d0
>>>  [] ? do_fast_syscall_32+0x30/0x1c0
>>>  [] ? __this_cpu_preempt_check+0xf/0x20
>>>  [] SyS_ioctl+0x58/0x80
>>>  [] do_fast_syscall_32+0xa1/0x1c0
>>>  [] sysenter_past_esp+0x45/0x74
>>> EIP: [] write_checkpoint+0xfde/0x1020 [f2fs] SS:ESP 0068:e7263d18
>>> ---[ end trace 4de95d7e6b3aa7c6 ]---
>>>
>>> The reason is: with below call stack, we will encounter BUG_ON during
>>> doing fstrim.
>>>
>>> Thread AThread B
>>> - write_checkpoint
>>>  - do_checkpoint
>>> - f2fs_write_inode
>>>  - update_inode_page
>>>   - update_inode
>>>- set_page_dirty
>>> - f2fs_set_node_page_dirty
>>>  - inc_page_count
>>>   - percpu_counter_inc
>>>   - set_sbi_flag(SBI_IS_DIRTY)
>>>   - clear_sbi_flag(SBI_IS_DIRTY)
>>>
>>> Thread CThread D
>>> - f2fs_write_node_page
>>>  - set_node_addr
>>>   - __set_nat_cache_dirty
>>>- nm_i->dirty_nat_cnt++
>>> - do_vfs_ioctl
>>>  - f2fs_ioctl
>>>   - f2fs_trim_fs
>>>- write_checkpoint
>>> - f2fs_bug_on(nm_i->dirty_nat_cnt)
>>>
>>> Fix it by setting superblock dirty correctly in do_checkpoint and
>>> f2fs_write_node_page.
>>>
>>> Signed-off-by: Chao Yu 
>>> ---
>>>  fs/f2fs/checkpoint.c | 4 
>>>  fs/f2fs/node.c   | 1 +
>>>  2 files changed, 5 insertions(+)
>>>
>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>> index cd0443d..68c723c 100644
>>> --- a/fs/f2fs/checkpoint.c
>>> +++ b/fs/f2fs/checkpoint.c
>>> @@ -1153,6 +1153,10 @@ static int do_checkpoint(struct f2fs_sb_info *sbi, 
>>> struct cp_control *cpc)
>>> clear_prefree_segments(sbi, cpc);
>>> clear_sbi_flag(sbi, SBI_IS_DIRTY);
>>>
>>> +   /* redirty superblock if node page is updated by ->write_inode */
>>> +   if (get_pages(sbi, F2FS_DIRTY_NODES))
>>
>> Need to check F2FS_DIRTY_IMETA and F2FS_DIRTY_DENTS as well?
>> And, if we have this, I don't think we need to worry about f2fs_lock_op() for
>> update_inode_page() as well.
>>
>> Thanks,
> Maybe we can add this:
> 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 7c8e219..d32539a 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -267,6 +267,9 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
> 
>  down_write(&io->io_rwsem);
> 
> +   if (!is_read)
> +   set_sbi_flag(sbi, SBI_IS_DIRTY);
> +
>  if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
>  (io->fio.op != fio->op || io->fio.op_flags != fio->op_flags)))
>  __submit_merged_bio(io);
> 
> This is deleted by this patch:
> 
> f2fs: use bio count instead of F2FS_WRITEBACK page count
> 
> which one is better?

I think we don't need to set fs as dirty state, if IPU is triggered, metadata of
filesystem is not updated, so we should not set the flag to avoid further
unneeded checkpoint.

Thanks,

> 
> Thanks.
> 
> 
> 
>>
>>> +   set_sbi_flag(sbi, SBI_IS_DIRTY);
>>> +
>>> return 0;
>>>  }
>>>
>>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>>> index 8a28800..365c6ff 100644
>>> --- a/fs/f2fs/node.c
>

Re: [PATCH 2/2] arm64: dts: rockchip: add eMMC's power domain support for rk3399

[Shawn Lin]

On 2016/8/27 21:41, Ziyuan Xu wrote:

Control power domain for eMMC via genpd to reduce power consumption.

Signed-off-by: Elaine Zhang 
Signed-off-by: Ziyuan Xu 



It looks nice to me. But this should be merged after applying that[0]
as your patch will break bind/unbind test for sdhci-of-arasan on rk3399
without it[0]. Moreover, Elaine should make sure that upstreamed
rockchip power domain stuff would not off pd for emmc, *otherwise*, I
should update my patch to make sure we update clkmul every time when
doing suspend 2 resume..



[0]: https://patchwork.kernel.org/patch/9300971/


---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 32aebc8..71733d4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -239,6 +239,7 @@
#clock-cells = <0>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
+   power-domains = <&power RK3399_PD_EMMC>;
status = "disabled";
};

@@ -611,6 +612,11 @@
status = "disabled";
};

+   qos_emmc: qos@ffa58000 {
+   compatible = "syscon";
+   reg = <0x0 0xffa58000 0x0 0x20>;
+   };
+
qos_hdcp: qos@ffa9 {
compatible = "syscon";
reg = <0x0 0xffa9 0x0 0x20>;
@@ -739,6 +745,11 @@
};

/* These power domains are grouped by VD_LOGIC */
+   pd_emmc@RK3399_PD_EMMC {
+   reg = ;
+   clocks = <&cru ACLK_EMMC>;
+   pm_qos = <&qos_emmc>;
+   };
pd_vio@RK3399_PD_VIO {
reg = ;
#address-cells = <1>;




--
Best Regards
Shawn Lin

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing

[Mickaël Salaün]

On 27/08/2016 09:40, Andy Lutomirski wrote:
> On Thu, Aug 25, 2016 at 3:32 AM, Mickaël Salaün  wrote:
>> Hi,
>>
>> This series is a proof of concept to fill some missing part of seccomp as the
>> ability to check syscall argument pointers or creating more dynamic security
>> policies. The goal of this new stackable Linux Security Module (LSM) called
>> Landlock is to allow any process, including unprivileged ones, to create
>> powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the
>> OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of
>> bugs or unexpected/malicious behaviors in userland applications.
>>
>> The first RFC [1] was focused on extending seccomp while staying at the 
>> syscall
>> level. This brought a working PoC but with some (mitigated) ToCToU race
>> conditions due to the seccomp ptrace hole (now fixed) and the non-atomic
>> syscall argument evaluation (hence the LSM hooks).
>>
>>
>> # Landlock LSM
>>
>> This second RFC is a fresh revamp of the code while keeping some working 
>> ideas.
>> This series is mainly focused on LSM hooks, while keeping the possibility to
>> tied them to syscalls. This new code removes all race conditions by design. 
>> It
>> now use eBPF instead of a subset of cBPF (as used by seccomp-bpf). This allow
>> to remove the previous stacked cBPF hack to do complex access checks thanks 
>> to
>> dedicated eBPF functions. An eBPF program is still very limited (i.e. can 
>> only
>> call a whitelist of functions) and can not do a denial of service (i.e. no
>> loop). The other major improvement is the replacement of the previous custom
>> checker groups of syscall arguments with a new dedicated eBPF map to collect
>> and compare Landlock handles with system resources (e.g. files or network
>> connections).
>>
>> The approach taken is to add the minimum amount of code while still allowing
>> the userland to create quite complex access rules. A dedicated security 
>> policy
>> language such as used by SELinux, AppArmor and other major LSMs is a lot of
>> code and dedicated to a trusted process (i.e. root/administrator).
>>
> 
> I think there might be a problem with the current design.  If I add a
> seccomp filter that uses RET_LANDLOCK and some landlock filters, what
> happens if a second seccomp filter *also* uses RET_LANDLOCK?  I think
> they'll interfere with each other.  It might end up being necessary to
> require only one landlock seccomp layer at a time or to find a way to
> stick all the filters in a layer together with the LSM callbacks or
> maybe to just drop RET_LANDLOCK and let the callbacks look at the
> syscall args.

This is correctly managed. For each RET_LANDLOCK, if there is one or
more associated Landlock programs (i.e. created by the same thread after
this seccomp filters), there is one Landlock program instance run for
each seccomp that trigger them. This way, each cookie linked to a
RET_LANDLOCK is evaluated one time by each relevant Landlock program.

Example when a thread that loaded multiple seccomp filters (SF) and
multiple Landlock programs (LP) associated with one LSM hook: SF0, SF1,
LP0(file_open), SF2, LP1(file_open), LP2(file_permission)

* If SF0 returns RET_LANDLOCK(cookie0), then LP0 and LP1 are run with
cookie0 if the current syscall trigger the file_open hook, and LP2 is
run with cookie0 if the syscall trigger the file_permission hook.

* In addition to the previous case, if SF1 returns
RET_LANDLOCK(cookie1), then LP0 and LP1 are run with cookie1 if the
current syscall trigger the file_open hook, and LP2 is run with cookie1
if the syscall trigger the file_permission hook.

* In addition to the previous cases, if SF2 returns
RET_LANDLOCK(cookie2), then (only) LP1 is run with cookie2 if the
current syscall trigger the file_open hook, and LP2 is run with cookie2
if the syscall trigger the file_permission hook.


> 
> BTW, what happens if an LSM hook is called outside a syscall context,
> e.g. from a page fault?

Good catch! For now, only a syscall can trigger an LSM hook because of
the RET_LANDLOCK constraint. It may be wise to trigger them without a
cookie and add a dedicated variable in the eBPF context.

> 
>>
>>
>> # Sandbox example with conditional access control depending on cgroup
>>
>>   $ mkdir /sys/fs/cgroup/sandboxed
>>   $ ls /home
>>   user1
>>   $ LANDLOCK_CGROUPS='/sys/fs/cgroup/sandboxed' \
>>   LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \
>>   ./sandbox /bin/sh -i
>>   $ ls /home
>>   user1
>>   $ echo $$ > /sys/fs/cgroup/sandboxed/cgroup.procs
>>   $ ls /home
>>   ls: cannot open directory '/home': Permission denied
>>
> 
> Something occurs to me that isn't strictly relevant to landlock but
> may be relevant to unprivileged cgroups: can you cause trouble by
> setting up a nastily-configured cgroup and running a setuid program in
> it?
> 

I hope not… But the use of cgroups should not be mandatory for Landlock.



signature.asc
Description: OpenPGP digital signat

Re: [PATCH] bridge: Fix format string for %ul

[Sergei Shtylyov]

Hello.

On 8/27/2016 6:10 AM, Oleg Drokin wrote:


%ul would print an unsigned value and a letter l,
likely it was %lu that was meant to print the long int,
but in reality the values printed there are just regular signed


   Signed? Then you need probably "%d" or "%i"...


ints, so just dropping the l altogether.

Signed-off-by: Oleg Drokin 

[...]

MBR, Sergei

Re: Random abnormal high CPU sys usage related to timer

[Mac Lin]

Hi Vegard,
Thanks for the prompt response.
The commit is introduced since 4.6, but the issue can be reproduced at
3.10 (earliest I have ever test). And testing on buildroot+4.7 with
the commit reverted, the issue still happen.

In fact, I did a test that ran a script that keep increase a counter
for 10 seconds on the same CPU. If I ran 2 of it, the number is half
of running 1. But if I ran it while the issue happened, the counter
reported is around the same value as the 1 process case. So I doubt
that it might be an issue of reported number.

Is there other way to ensure the CPU is "really" doing something?

x=0
trap 'echo x=$x;exit 1' SIGHUP SIGINT SIGTERM
while : ; do
x=$(($x+1));
#   echo $x;
done


On Sat, Aug 27, 2016 at 5:12 AM, Vegard Nossum  wrote:
> On 26 August 2016 at 19:10, Mac Lin  wrote:
>> We were having issue with our userspace application which
>> __sometimes__ result in high CPU sys usage at each execution. The high
>> sys CPU usage persist until the application is killed.
> [...]
>> Googling found one issue that seems related, but no further action.
>
> Was it this one? https://lkml.org/lkml/2016/8/23/360
>
> If so you may try to revert commit ff9a9b4c4334 ("sched, time: Switch
> VIRT_CPU_ACCOUNTING_GEN to jiffy granularity") to see if it helps.
>
>
> Vegard

Re: [RFC v4 13/22] clockevents: check a programmed delta's bounds in terms of cycles

[Nicolai Stange]

Nicolai Stange  writes:

> @@ -332,10 +337,10 @@ int clockevents_program_event(struct clock_event_device 
> *dev, ktime_t expires,
>   if (delta <= 0)
>   return force ? clockevents_program_min_delta(dev) : -ETIME;
>  
> - delta = min(delta, (int64_t) dev->max_delta_ns);
> - delta = max(delta, (int64_t) dev->min_delta_ns);
> -
>   clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
> + clc = min_t(unsigned long, clc, dev->max_delta_ticks);
> + clc = max_t(unsigned long, clc, dev->min_delta_ticks_adjusted);
> +
>   rc = dev->set_next_event((unsigned long) clc, dev);
>  
>   return (rc && force) ? clockevents_program_min_delta(dev) : rc;

This is broken :(

I failed to recognize that ->max_delta_ns serves not only one, but
three purposes actually:
1. It prevents the ced to get programmed with too large values. Still
   works with this patch.
2. It prevents the multiplication by dev->mult from overflowing 64 bits,
   i.e. it clamps the input delta to a range valid for the given
   ->mult. Ouch.
3. On 32 bit archs, it prevents the cast of clc to unsigned long from
   overflowing. Ouch here as well.


The 3.) can be restored by doing 
  clc = min_t(unsigned long long, clc, dev->max_delta_ticks);
rather than min_t(unsigned long, ...)
because dev->max_delta_ticks is of type unsigned long and thus,
<= ULONG_MAX.


Unfortunately, fixing up 2.) is not so straight forward: I'll certainly
have to resort to ->max_delta_ns again. But then, there will be the
issue with non-atomic updates from timekeeping -- at least if
->max_delta_ns continues to represent ->max_delta_ticks as it did
before.

In order to get rid of the requirement to update ->max_delta_ns whenever
the ->mult changes, would it be Ok to decouple ->max_delta_ns from
->max_delta_ticks by
a. setting
 dev->max_delta_ns = (1 << (64 - ilog2(dev->mult))) - 1
   once and for all at device registration (and from clockevents_update_freq()),
b. and introducing an *additional* comparison
 delta = min(delta, (int64_t) dev->max_delta_ns);
   right before the multiplication in clockevents_program_event()?

In this setting, ->max_delta_ns would be a function of the original
->mult only -- more precisely, of ilog2(dev->mult).

Altogether, we'd have

  delta = min(delta, (int64_t) dev->max_delta_ns);
  clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
  clc = min_t(unsigned long long, clc, dev->max_delta_ticks);
  clc = max_t(unsigned long long, clc, dev->min_delta_ticks_adjusted);
  
  rc = dev->set_next_event((unsigned long) clc, dev);

in clockevents_program_event() then.

So, purposes 1.) and 3.) would get served by the second min() while the
first one would make sure that the multiplication will never overflow.

The downside would be the additional comparison + conditional move in
the ced programming path. The ->max_delta_ns and ->max_delta_ticks can
both be moved to struct clock_event_device's first cacheline
simultaneously without affecting any of its remaining hot members though
(on 64 bit archs with a cacheline size of 64 bytes).


Now, to quote your objections to [22/22] ("timekeeping: inform
clockevents about freq adjustments"):

> What makes sure that the resulting shift/mult pair is still valid after this
> adjustment? The non adjusted mult/shift pair might be right at the border of
> potential overflows and the adjustment might just put it over the edge
> We need at least sanity checks here.

The updated ->mult_adjusted could get restricted to never grow beyond
  (1 << fls(dev->mult)) - 1
where dev->mult is the never changing, non-adjusted mult value. That is,
the mult adjustment would simply stop at the point where it could
possibly introduce overflows for some deltas smaller than the now fixed
->max_delta_ns.


I have to admit that checking both, ->max_delta_ticks and ->max_delta_ns
from clockevents_program_event() is a little bit messy. As is the
cut-off point for the mult adjustments...


Maybe I should just try to schedule the necessary updates from
timekeeping on each CPU instead? If this worked out, I could probably
recalculate appropriate values of ->*_delta_ns and store these
racelessly along with the adjusted mult while not touching
clockevents_program_event() at all. That is, I would schedule something
similar to clockevents_update_freq() on each CPU.


Thanks,

Nicolai Stange

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (cgroup delegation)

[Mickaël Salaün]

Cc Tejun and the cgroups ML.

On 27/08/2016 17:10, Mickaël Salaün wrote:
> On 27/08/2016 09:40, Andy Lutomirski wrote:
>> On Thu, Aug 25, 2016 at 3:32 AM, Mickaël Salaün  wrote:
>>>
>>> # Sandbox example with conditional access control depending on cgroup
>>>
>>>   $ mkdir /sys/fs/cgroup/sandboxed
>>>   $ ls /home
>>>   user1
>>>   $ LANDLOCK_CGROUPS='/sys/fs/cgroup/sandboxed' \
>>>   LANDLOCK_ALLOWED='/bin:/lib:/usr:/tmp:/proc/self/fd/0' \
>>>   ./sandbox /bin/sh -i
>>>   $ ls /home
>>>   user1
>>>   $ echo $$ > /sys/fs/cgroup/sandboxed/cgroup.procs
>>>   $ ls /home
>>>   ls: cannot open directory '/home': Permission denied
>>>
>>
>> Something occurs to me that isn't strictly relevant to landlock but
>> may be relevant to unprivileged cgroups: can you cause trouble by
>> setting up a nastily-configured cgroup and running a setuid program in
>> it?
>>
> 
> I hope not… But the use of cgroups should not be mandatory for Landlock.
> 

In a previous email:

On 26/08/2016 17:50, Tejun Heo wrote:
> I haven't looked in detail but in general I'm not too excited about
> layering security mechanism on top of cgroup.  Maybe it makes some
> sense when security domain coincides with resource domains but at any
> rate please keep me in the loop.




signature.asc
Description: OpenPGP digital signature

Re: [RFC v4 14/22] clockevents: clockevents_program_event(): turn clc into unsigned long

[Nicolai Stange]

Thomas Gleixner  writes:

> On Tue, 23 Aug 2016, Nicolai Stange wrote:
>
>> Right now, being of type unsigned long long, the clc local variable in
>> clockevents_program_event() is unnecessarily wide as it gets cast to
>> unsigned long anyway.
>
> Congrats! You just broke 32bit systems. When delta is sufficiently large then
> the mult overflows

The 32bit breakage has been introduced in [13/22] ("clockevents: check a
programmed delta's bounds in terms of cycles") already -- please see my
reply there.

[PATCH 1/3] checkkconfigsymbols: port to python3

[Valentin Rothberg]

Port the script to python3 and fix some pylint warnings.

Signed-off-by: Valentin Rothberg 
---
 scripts/checkkconfigsymbols.py | 280 +++--
 1 file changed, 156 insertions(+), 124 deletions(-)

diff --git a/scripts/checkkconfigsymbols.py b/scripts/checkkconfigsymbols.py
index 0cae73b5c925..9df545615b8d 100755
--- a/scripts/checkkconfigsymbols.py
+++ b/scripts/checkkconfigsymbols.py
@@ -1,13 +1,15 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python3
 
-"""Find Kconfig symbols that are referenced but not defined."""
+"""
+Find Kconfig symbols that are referenced but not defined.
+"""
 
 # (c) 2014-2016 Valentin Rothberg 
 # (c) 2014 Stefan Hengelein 
 #
 # Licensed under the terms of the GNU GPL License version 2
 
-
+import argparse
 import difflib
 import os
 import re
@@ -15,8 +17,6 @@ import signal
 import subprocess
 import sys
 from multiprocessing import Pool, cpu_count
-from optparse import OptionParser
-from subprocess import Popen, PIPE, STDOUT
 
 
 # regex expressions
@@ -42,63 +42,63 @@ REGEX_QUOTES = re.compile("(\"(.*?)\")")
 
 
 def parse_options():
-"""The user interface of this module."""
-usage = "%prog [options]\n\n"  
\
-"Run this tool to detect Kconfig symbols that are referenced but " 
\
-"not defined in\nKconfig.  The output of this tool has the "   
\
-"format \'Undefined symbol\\tFile list\'\n\n"  
\
-"If no option is specified, %prog will default to check your\n"
\
-"current tree.  Please note that specifying commits will " 
\
-"\'git reset --hard\'\nyour current tree!  You may save "  
\
-"uncommitted changes to avoid losing data."
-
-parser = OptionParser(usage=usage)
-
-parser.add_option('-c', '--commit', dest='commit', action='store',
-  default="",
-  help="Check if the specified commit (hash) introduces "
-   "undefined Kconfig symbols.")
-
-parser.add_option('-d', '--diff', dest='diff', action='store',
-  default="",
-  help="Diff undefined symbols between two commits.  The "
-   "input format bases on Git log's "
-   "\'commmit1..commit2\'.")
-
-parser.add_option('-f', '--find', dest='find', action='store_true',
-  default=False,
-  help="Find and show commits that may cause symbols to be 
"
-   "missing.  Required to run with --diff.")
-
-parser.add_option('-i', '--ignore', dest='ignore', action='store',
-  default="",
-  help="Ignore files matching this pattern.  Note that "
-   "the pattern needs to be a Python regex.  To "
-   "ignore defconfigs, specify -i '.*defconfig'.")
-
-parser.add_option('-s', '--sim', dest='sim', action='store', default="",
-  help="Print a list of maximum 10 string-similar 
symbols.")
-
-parser.add_option('', '--force', dest='force', action='store_true',
-  default=False,
-  help="Reset current Git tree even when it's dirty.")
-
-parser.add_option('', '--no-color', dest='color', action='store_false',
-  default=True,
-  help="Don't print colored output. Default when not "
-   "outputting to a terminal.")
-
-(opts, _) = parser.parse_args()
-
-if opts.commit and opts.diff:
+"""
+The user interface of this module.
+"""
+usage = "Run this tool to detect Kconfig symbols that are referenced but " 
\
+"not defined in Kconfig.  If no option is specified, " 
\
+"checkkconfigsymbols defaults to check your current tree.  "   
\
+"Please note that specifying commits will 'git reset --hard\' "
\
+"your current tree!  You may save uncommitted changes to avoid "   
\
+"losing data."
+
+parser = argparse.ArgumentParser(description=usage)
+
+parser.add_argument('-c', '--commit', dest='commit', action='store',
+default="",
+help="Check if the specified commit (hash) introduces "
+ "undefined Kconfig symbols.")
+
+parser.add_argument('-d', '--diff', dest='diff', action='store',
+default="",
+help="Diff undefined symbols between two commits.  The 
"
+ "input format bases on Git log's "
+ "\'commmit1..commit2\'.")
+
+parser.add_argument('-f', '--find', dest='find', action='store_true',
+default=False,
+help="Find and show commits that may cause symbols to 
be "
+ 

[PATCH 1/2] mm/nobootmem.c: make CONFIG_NO_BOOTMEM depend on CONFIG_HAVE_MEMBLOCK

[zijun_hu]

From: zijun_hu 

this patch fixes the following bugs:

 - no bootmem is implemented by memblock currently, but config option
   CONFIG_NO_BOOTMEM doesn't depend on CONFIG_HAVE_MEMBLOCK

 - the same ARCH_LOW_ADDRESS_LIMIT statements are duplicated between
   header and relevant source

 - don't ensure ARCH_LOW_ADDRESS_LIMIT perhaps defined by ARCH in
   asm/processor.h is preferred over default in linux/bootmem.h
   completely since the former header isn't included by the latter

Signed-off-by: zijun_hu 
---
 include/linux/bootmem.h | 13 +++--
 mm/Kconfig  |  6 --
 mm/nobootmem.c  |  6 +-
 3 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index f9be32691718..95968236abc7 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  *  simple boot-time physical memory area allocator.
@@ -119,6 +120,10 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
 #define BOOTMEM_LOW_LIMIT __pa(MAX_DMA_ADDRESS)
 #endif
 
+#ifndef ARCH_LOW_ADDRESS_LIMIT
+#define ARCH_LOW_ADDRESS_LIMIT  0xUL
+#endif
+
 #define alloc_bootmem(x) \
__alloc_bootmem(x, SMP_CACHE_BYTES, BOOTMEM_LOW_LIMIT)
 #define alloc_bootmem_align(x, align) \
@@ -148,7 +153,7 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
__alloc_bootmem_low_node(pgdat, x, PAGE_SIZE, 0)
 
 
-#if defined(CONFIG_HAVE_MEMBLOCK) && defined(CONFIG_NO_BOOTMEM)
+#if defined(CONFIG_NO_BOOTMEM)
 
 /* FIXME: use MEMBLOCK_ALLOC_* variants here */
 #define BOOTMEM_ALLOC_ACCESSIBLE   0
@@ -180,10 +185,6 @@ static inline void * __init memblock_virt_alloc_nopanic(
NUMA_NO_NODE);
 }
 
-#ifndef ARCH_LOW_ADDRESS_LIMIT
-#define ARCH_LOW_ADDRESS_LIMIT  0xUL
-#endif
-
 static inline void * __init memblock_virt_alloc_low(
phys_addr_t size, phys_addr_t align)
 {
@@ -333,7 +334,7 @@ static inline void __init memblock_free_late(
 {
free_bootmem_late(base, size);
 }
-#endif /* defined(CONFIG_HAVE_MEMBLOCK) && defined(CONFIG_NO_BOOTMEM) */
+#endif /* defined(CONFIG_NO_BOOTMEM) */
 
 #ifdef CONFIG_HAVE_ARCH_ALLOC_REMAP
 extern void *alloc_remap(int nid, unsigned long size);
diff --git a/mm/Kconfig b/mm/Kconfig
index be0ee11fa0d9..b7f19ff4b743 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -144,14 +144,16 @@ config ARCH_DISCARD_MEMBLOCK
bool
 
 config NO_BOOTMEM
-   bool
+   bool "No legacy boot memory"
+   depends on HAVE_MEMBLOCK
+   help
+NO_BOOTMEM is implemented by memblock
 
 config MEMORY_ISOLATION
bool
 
 config MOVABLE_NODE
bool "Enable to assign a node which has only movable memory"
-   depends on HAVE_MEMBLOCK
depends on NO_BOOTMEM
depends on X86_64
depends on NUMA
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index bd05a70f44b9..1802c9bbe11a 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -11,15 +11,14 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-#include 
 
 #include "internal.h"
 
@@ -395,9 +394,6 @@ void * __init __alloc_bootmem_node_high(pg_data_t *pgdat, 
unsigned long size,
return __alloc_bootmem_node(pgdat, size, align, goal);
 }
 
-#ifndef ARCH_LOW_ADDRESS_LIMIT
-#define ARCH_LOW_ADDRESS_LIMIT 0xUL
-#endif
 
 /**
  * __alloc_bootmem_low - allocate low boot memory
-- 
1.9.1