[PATCH 2/2] f2fs: fix to do f2fs_balance_fs in f2fs_map_blocks correctly

[Chao Yu]

If we preallocate blocks with f2fs_reserve_blocks in f2fs_map_blocks, we
should call f2fs_balance_fs for checking and reclaiming space, fix it.

Signed-off-by: Chao Yu 
---
 fs/f2fs/data.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index dee3a78..040a07a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -784,6 +784,7 @@ skip:
err = reserve_new_blocks(&dn, prealloc);
if (err)
goto sync_out;
+   allocated = dn.node_changed;
 
map->m_len += dn.ofs_in_node - ofs_in_node;
if (prealloc && dn.ofs_in_node != last_ofs_in_node + 1) {
-- 
2.8.2.311.gee88674

[PATCH 1/2] f2fs: fix to preallocate block only aligned to 4K

[Chao Yu]

In write_begin(), we skip checking dnode block for preallocating block
when whole block needs to be updated since we preallocated its block in
f2fs_preallocate_blocks, for partial updated block, we will still try
to lock its node and do preallocation in write_begin(), so in
f2fs_preallocate_blocks we should not preallocate its block.

But previously, the calculation of preallocating block number is
incorrect, fix it.

Signed-off-by: Chao Yu 
---
 fs/f2fs/data.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index ccb401e..dee3a78 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -626,7 +626,8 @@ ssize_t f2fs_preallocate_blocks(struct kiocb *iocb, struct 
iov_iter *from)
ssize_t ret = 0;
 
map.m_lblk = F2FS_BLK_ALIGN(iocb->ki_pos);
-   map.m_len = F2FS_BYTES_TO_BLK(iov_iter_count(from));
+   map.m_len = F2FS_BYTES_TO_BLK(iocb->ki_pos + iov_iter_count(from)) -
+   map.m_lblk;
map.m_next_pgofs = NULL;
 
if (f2fs_encrypted_inode(inode))
-- 
2.8.2.311.gee88674

Re: Memory (skb) leak in kernel 4.8-rc2

[Johan Hedberg]

Hi Marcel,

On Sat, Aug 20, 2016, Marcel Holtmann wrote:
> > I am seeing two skb leaks in the BT sub-system for kernel 4.8-rc2. I
> > only recently re-enabled kmemleak, but I do not think I saw these
> > leaks in 4.7.
> > 
> > The first leak is at btusb_recv_intr+0x12b/0x170 [btusb]. This
> > address refers to the call to bt_skb_alloc() in routine
> > btusb_recv_intr().
> 
> do you have a backtrace for this one? Also which hardware is this?
> 
> > The second leak is at hci_event_packet+0xb8/0x30b0 [bluetooth]. The
> > backtrace for this address is
> > 
> > 0x13d38 is in hci_event_packet (net/bluetooth/hci_event.c:5254).
> > 5249 * various handlers may modify the original one through
> > 5250 * skb_pull() calls, etc.
> > 5251 */
> > 5252if (req_complete_skb || event == HCI_EV_CMD_STATUS ||
> > 5253event == HCI_EV_CMD_COMPLETE)
> > 5254orig_skb = skb_clone(skb, GFP_KERNEL);
> > 5255
> > 5256skb_pull(skb, HCI_EVENT_HDR_SIZE);
> > 5257
> > 5258switch (event) {
> > 
> > I am unable to unload module bluetooth to verify that the second
> > leak is not a false positive; however, the one in btusb is a real
> > memory leak.
> 
> I can not see a leak. Maybe Johan has an idea.

Unfortunately I don't have any ideas either - there is no exit path from
hci_event_packet() after orig_skb has been allocated that would not
result in kfree_skb(orig_skb) being called first.

Johan

[PATCH 1/1] sched/clock: add __init attribute to sched_clock_init()

[seokhoon.yoon]

sched_clock_init() is only called from start_kernel().
So add __init attritute to it.

Signed-off-by: seokhoon.yoon 
---
 kernel/sched/clock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index e85a725..e5795e8 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -147,7 +147,7 @@ static inline struct sched_clock_data *cpu_sdc(int cpu)
return &per_cpu(sched_clock_data, cpu);
 }
 
-void sched_clock_init(void)
+void __init sched_clock_init(void)
 {
u64 ktime_now = ktime_to_ns(ktime_get());
int cpu;
@@ -366,7 +366,7 @@ EXPORT_SYMBOL_GPL(sched_clock_idle_wakeup_event);
 
 #else /* CONFIG_HAVE_UNSTABLE_SCHED_CLOCK */
 
-void sched_clock_init(void)
+void __init sched_clock_init(void)
 {
sched_clock_running = 1;
 }
-- 
1.9.1

[PATCH 0/2] tun: Fine-tuning for update_filter()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 09:16:16 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Use memdup_user()
  Rename a jump label

 drivers/net/tun.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

-- 
2.9.3

Re: [PATCH 0/2] fs, proc: optimize smaps output formatting

[Michal Hocko]

On Fri 19-08-16 10:43:15, Joe Perches wrote:
> On Fri, 2016-08-19 at 12:12 +0200, Michal Hocko wrote:
> > Hi,
> > this is rebased on top of next-20160818. Joe has pointed out that
> > meminfo is using a similar trick so I have extracted guts of what we
> > have already and made it more generic to be usable for smaps as well
> > (patch 1). The second patch then replaces seq_printf with seq_write
> > and show_val_kb which should have smaller overhead and my measuring (in
> > kvm) shows quite a nice improvements. I hope kvm is not playing tricks
> > on me but I didn't get to test on a real HW.
> 
> 
> Hi Michal.
> 
> A few comments:
> 
> For the first patch:
> 
> I think this isn't worth the expansion in object size (x86-64 defconfig)
> 
> $ size fs/proc/meminfo.o*
>    text      data bss dec hex filename
>    2698     8   0    2706 a92 fs/proc/meminfo.o.new
>    2142     8   0    2150 866 fs/proc/meminfo.o.old
> 
> Creating a new static in task_mmu would be smaller and faster code.

Hmm, nasty...
add/remove: 0/0 grow/shrink: 2/1 up/down: 1081/-24 (1057)
function old new   delta
meminfo_proc_show   11341745+611
show_smap5601030+470
show_val_kb  140 116 -24
Total: Before=91716, After=92773, chg +1.15%

it seems to be calls to seq_write which blown up the size. So I've tried
to put seq_write back to show_val_kb and did only sizeof() inside those
macros and that reduced the size but not fully back to the original code
size. So it seems the value shifts consumed some portion of that as well.
I've ended up with the following incremental diff which leads to
   textdata bss dec hex filename
 1007281443 400  102571   190ab fs/proc/built-in.o.next
 1016581443 400  103501   1944d fs/proc/built-in.o.patched
 1009511443 400  102794   1918a fs/proc/built-in.o.incremental

There is still some increase wrt. the baseline but I guess that can be
explained by single seq_printf -> many show_name_val_kb calls.

If that looks acceptable I will respin both patches. I would really
like to prefer to not duplicate show_val_kb into task_mmu as much as
possible, though.

---
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 6a369fc1949d..de9c561f83b4 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -307,17 +307,3 @@ extern void task_mem(struct seq_file *, struct mm_struct 
*);
 
 /* prints given value (in kB) padded properly to 8 spaces */
 extern void show_val_kb(struct seq_file *m, unsigned long num);
-
-#define show_name_pages_kb(seq, name, pages)   \
-({ \
-   BUILD_BUG_ON(!__builtin_constant_p(name));\
-   seq_write(seq, name, sizeof(name)); \
-   show_val_kb(seq, (pages) << (PAGE_SHIFT - 10));\
- })
-
-#define show_name_bytes_kb(seq, name, val) \
-({ \
-   BUILD_BUG_ON(!__builtin_constant_p(name));\
-   seq_write(seq, name, sizeof(name)); \
-   show_val_kb(seq, (val) >> 10);  \
-})
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 65e0bc6213e2..7f2937cd231c 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -39,6 +39,14 @@ void show_val_kb(struct seq_file *m, unsigned long num)
seq_write(m, " kB\n", 4);
 }
 
+static void show_name_pages_kb(struct seq_file *m, const char *name,
+   unsigned long pages)
+{
+   seq_write(m, name, 16);
+   show_val_kb(m, pages << (PAGE_SHIFT - 10));
+}
+
+
 static int meminfo_proc_show(struct seq_file *m, void *v)
 {
struct sysinfo i;
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index eebb91d44a58..a92898f20a1f 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -721,6 +721,19 @@ void __weak arch_show_smap(struct seq_file *m, struct 
vm_area_struct *vma)
 {
 }
 
+static void show_name_val_kb(struct seq_file *m, const char *name, size_t len,
+   unsigned long val)
+{
+   seq_write(m, name, len);
+   show_val_kb(m, val >> 10);
+}
+
+#define show_name_bytes_kb(seq, name, val) \
+({ \
+   BUILD_BUG_ON(!__builtin_constant_p(name));\
+   show_name_val_kb(seq, name, sizeof(name), val);\
+})
+
 static int show_smap(struct seq_file *m, void *v, int is_pid)
 {
struct vm_area_struct *vma = v;
-- 
Michal Hocko
SUSE Labs

[PATCH 1/2] tun: Use memdup_user() rather than duplicating its implementation

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 08:54:15 +0200

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/tun.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9c8b5bc..a1aeccb 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -731,14 +731,9 @@ static int update_filter(struct tap_filter *filter, void 
__user *arg)
}
 
alen = ETH_ALEN * uf.count;
-   addr = kmalloc(alen, GFP_KERNEL);
-   if (!addr)
-   return -ENOMEM;
-
-   if (copy_from_user(addr, arg + sizeof(uf), alen)) {
-   err = -EFAULT;
-   goto done;
-   }
+   addr = memdup_user(arg + sizeof(uf), alen);
+   if (IS_ERR(addr))
+   return PTR_ERR(addr);
 
/* The filter is updated without holding any locks. Which is
 * perfectly safe. We disable it first and in the worst
-- 
2.9.3

[PATCH 2/2] tun: Rename a jump label in update_filter()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 09:00:34 +0200

Adjust a jump target according to the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/net/tun.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a1aeccb..e249428 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -753,7 +753,7 @@ static int update_filter(struct tap_filter *filter, void 
__user *arg)
for (; n < uf.count; n++) {
if (!is_multicast_ether_addr(addr[n].u)) {
err = 0; /* no filter */
-   goto done;
+   goto free_addr;
}
addr_hash_set(filter->mask, addr[n].u);
}
@@ -769,8 +769,7 @@ static int update_filter(struct tap_filter *filter, void 
__user *arg)
 
/* Return the number of exact filters */
err = nexact;
-
-done:
+free_addr:
kfree(addr);
return err;
 }
-- 
2.9.3

Re: [PATCH 0/2] fs, proc: optimize smaps output formatting

[Joe Perches]

On Sat, 2016-08-20 at 09:29 +0200, Michal Hocko wrote:
> On Fri 19-08-16 10:43:15, Joe Perches wrote:
> > 
> > On Fri, 2016-08-19 at 12:12 +0200, Michal Hocko wrote:
> > > 
> > > Hi,
> > > this is rebased on top of next-20160818. Joe has pointed out that
> > > meminfo is using a similar trick so I have extracted guts of what we
> > > have already and made it more generic to be usable for smaps as well
> > > (patch 1). The second patch then replaces seq_printf with seq_write
> > > and show_val_kb which should have smaller overhead and my measuring (in
> > > kvm) shows quite a nice improvements. I hope kvm is not playing tricks
> > > on me but I didn't get to test on a real HW.
> > 
> > Hi Michal.
> > 
> > A few comments:
> > 
> > For the first patch:
> > 
> > I think this isn't worth the expansion in object size (x86-64 defconfig)
> > 
> > $ size fs/proc/meminfo.o*
> >    text    data bss dec hex filename
> >    2698   8   0    2706 a92 fs/proc/meminfo.o.new
> >    2142   8   0    2150 866 fs/proc/meminfo.o.old
> > 
> > Creating a new static in task_mmu would be smaller and faster code.
> Hmm, nasty...
> add/remove: 0/0 grow/shrink: 2/1 up/down: 1081/-24 (1057)
> function old new   delta
> meminfo_proc_show   11341745+611
> show_smap5601030+470
> show_val_kb  140 116 -24
> Total: Before=91716, After=92773, chg +1.15%
> 
> it seems to be calls to seq_write which blown up the size. So I've tried
> to put seq_write back to show_val_kb and did only sizeof() inside those
> macros and that reduced the size but not fully back to the original code
> size. So it seems the value shifts consumed some portion of that as well.
> I've ended up with the following incremental diff which leads to
>    textdata bss dec hex filename
>  1007281443 400  102571   190ab fs/proc/built-in.o.next
>  1016581443 400  103501   1944d fs/proc/built-in.o.patched
>  1009511443 400  102794   1918a fs/proc/built-in.o.incremental
> 
> There is still some increase wrt. the baseline but I guess that can be
> explained by single seq_printf -> many show_name_val_kb calls.
> 
> If that looks acceptable I will respin both patches. I would really
> like to prefer to not duplicate show_val_kb into task_mmu as much as
> possible, though.

I think the patch set I'll send you in a few minutes
will speed up /proc//smaps a whole lot more.

Please test it using your little test bench.

cheers, Joe

[PATCH 0/2] seq: Speed up /proc//smaps

[Joe Perches]

Doing a simple cat of these files can take a lot more cpu than
it should.  Optimize it a bit.

Joe Perches (2):
  seq_file: Add __seq_open_private_bufsize for seq file_operation sizes
  proc: task_mmu: Reduce output processing cpu time

 fs/proc/task_mmu.c   | 94 
 fs/seq_file.c| 31 
 include/linux/seq_file.h |  3 ++
 3 files changed, 82 insertions(+), 46 deletions(-)

-- 
2.8.0.rc4.16.g56331f8

[PATCH 1/2] seq_file: Add __seq_open_private_bufsize for seq file_operation sizes

[Joe Perches]

Specifying an initial output buffer size can reduce the
number of regenerations of the seq_ buffers when
the buffer overflows.

Add another version of __seq_open_private that takes an
initial buffer size.

Signed-off-by: Joe Perches 
---
 fs/seq_file.c| 31 +++
 include/linux/seq_file.h |  3 +++
 2 files changed, 34 insertions(+)

diff --git a/fs/seq_file.c b/fs/seq_file.c
index b8ac757e..d98fa77 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -652,6 +652,37 @@ int seq_open_private(struct file *filp, const struct 
seq_operations *ops,
 }
 EXPORT_SYMBOL(seq_open_private);
 
+void *__seq_open_private_bufsize(struct file *f,
+const struct seq_operations *ops,
+int psize, size_t bufsize)
+{
+   int rc;
+   void *private;
+   struct seq_file *seq;
+
+   private = kzalloc(psize, GFP_KERNEL);
+   if (private == NULL)
+   goto out;
+
+   rc = seq_open(f, ops);
+   if (rc < 0)
+   goto out_free;
+
+   seq = f->private_data;
+   seq->private = private;
+
+   kfree(seq->buf);
+   seq->buf = seq_buf_alloc(seq->size = round_up(bufsize, PAGE_SIZE));
+
+   return private;
+
+out_free:
+   kfree(private);
+out:
+   return NULL;
+}
+EXPORT_SYMBOL(__seq_open_private_bufsize);
+
 void seq_putc(struct seq_file *m, char c)
 {
if (m->count >= m->size)
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index e305b66..719f1b8 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -136,6 +136,9 @@ int single_open(struct file *, int (*)(struct seq_file *, 
void *), void *);
 int single_open_size(struct file *, int (*)(struct seq_file *, void *), void 
*, size_t);
 int single_release(struct inode *, struct file *);
 void *__seq_open_private(struct file *, const struct seq_operations *, int);
+void *__seq_open_private_bufsize(struct file *f,
+const struct seq_operations *ops,
+int psize, size_t bufsize);
 int seq_open_private(struct file *, const struct seq_operations *, int);
 int seq_release_private(struct inode *, struct file *);
 
-- 
2.8.0.rc4.16.g56331f8

[PATCH 2/2] proc: task_mmu: Reduce output processing cpu time

[Joe Perches]

Use the new __seq_open_private_buffer to estimate the final
output /proc//smaps filesize to reduce the number of
reallocations of overflowed buffers.

Use a simpler single-line function to emit various values in kB.

Signed-off-by: Joe Perches 
---
 fs/proc/task_mmu.c | 94 --
 1 file changed, 48 insertions(+), 46 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 187d84e..170509b 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -224,19 +224,21 @@ static void m_stop(struct seq_file *m, void *v)
 static int proc_maps_open(struct inode *inode, struct file *file,
const struct seq_operations *ops, int psize)
 {
-   struct proc_maps_private *priv = __seq_open_private(file, ops, psize);
+   struct proc_maps_private *priv;
+   struct mm_struct *mm;
+
+   mm = proc_mem_open(inode, PTRACE_MODE_READ);
+   if (IS_ERR(mm))
+   return PTR_ERR(mm);
 
+   priv = __seq_open_private_bufsize(file, ops, psize,
+ mm && mm->map_count ?
+ mm->map_count * 0x300 : PAGE_SIZE);
if (!priv)
return -ENOMEM;
 
priv->inode = inode;
-   priv->mm = proc_mem_open(inode, PTRACE_MODE_READ);
-   if (IS_ERR(priv->mm)) {
-   int err = PTR_ERR(priv->mm);
-
-   seq_release_private(inode, file);
-   return err;
-   }
+   priv->mm = mm;
 
return 0;
 }
@@ -721,6 +723,25 @@ void __weak arch_show_smap(struct seq_file *m, struct 
vm_area_struct *vma)
 {
 }
 
+static void show_val_kb(struct seq_file *m, const char *s, unsigned long num)
+{
+   char v[32];
+   static const char blanks[7] = {' ', ' ', ' ', ' ',' ', ' ', ' '};
+   int len;
+
+   len = num_to_str(v, sizeof(v), num >> 10);
+
+   seq_write(m, s, 16);
+
+   if (len > 0) {
+   if (len < 8)
+   seq_write(m, blanks, 8 - len);
+
+   seq_write(m, v, len);
+   }
+   seq_write(m, " kB\n", 4);
+}
+
 static int show_smap(struct seq_file *m, void *v, int is_pid)
 {
struct vm_area_struct *vma = v;
@@ -765,44 +786,25 @@ static int show_smap(struct seq_file *m, void *v, int 
is_pid)
 
show_map_vma(m, vma, is_pid);
 
-   seq_printf(m,
-  "Size:   %8lu kB\n"
-  "Rss:%8lu kB\n"
-  "Pss:%8lu kB\n"
-  "Shared_Clean:   %8lu kB\n"
-  "Shared_Dirty:   %8lu kB\n"
-  "Private_Clean:  %8lu kB\n"
-  "Private_Dirty:  %8lu kB\n"
-  "Referenced: %8lu kB\n"
-  "Anonymous:  %8lu kB\n"
-  "AnonHugePages:  %8lu kB\n"
-  "ShmemPmdMapped: %8lu kB\n"
-  "Shared_Hugetlb: %8lu kB\n"
-  "Private_Hugetlb: %7lu kB\n"
-  "Swap:   %8lu kB\n"
-  "SwapPss:%8lu kB\n"
-  "KernelPageSize: %8lu kB\n"
-  "MMUPageSize:%8lu kB\n"
-  "Locked: %8lu kB\n",
-  (vma->vm_end - vma->vm_start) >> 10,
-  mss.resident >> 10,
-  (unsigned long)(mss.pss >> (10 + PSS_SHIFT)),
-  mss.shared_clean  >> 10,
-  mss.shared_dirty  >> 10,
-  mss.private_clean >> 10,
-  mss.private_dirty >> 10,
-  mss.referenced >> 10,
-  mss.anonymous >> 10,
-  mss.anonymous_thp >> 10,
-  mss.shmem_thp >> 10,
-  mss.shared_hugetlb >> 10,
-  mss.private_hugetlb >> 10,
-  mss.swap >> 10,
-  (unsigned long)(mss.swap_pss >> (10 + PSS_SHIFT)),
-  vma_kernel_pagesize(vma) >> 10,
-  vma_mmu_pagesize(vma) >> 10,
-  (vma->vm_flags & VM_LOCKED) ?
-   (unsigned long)(mss.pss >> (10 + PSS_SHIFT)) : 0);
+   show_val_kb(m, "Size:   ", vma->vm_end - vma->vm_start);
+   show_val_kb(m, "Rss:", mss.resident);
+   show_val_kb(m, "Pss:", mss.pss >> PSS_SHIFT);
+   show_val_kb(m, "Shared_Clean:   ", mss.shared_clean);
+   show_val_kb(m, "Shared_Dirty:   ", mss.shared_dirty);
+   show_val_kb(m, "Private_Clean:  ", mss.private_clean);
+   show_val_kb(m, "Private_Dirty:  ", mss.private_dirty);
+   show_val_kb(m, "Referenced: ", mss.referenced);
+   show_val_kb(m, "Anonymous:  ", mss.anonymous);
+   show_val_kb(m, "AnonHugePages:  ", mss.anonymous_thp);
+   show_val_kb(m, "ShmemPmdMapped: ", mss.shmem_thp);
+   show_val_kb(m, "Shared_Hugetlb: ", mss.shared_hugetlb);
+   seq_printf(m, "Private_Hugetlb: %7lu kB\n",  mss.private_hugetlb >> 10);
+   show_val_k

[RFC/PATCHSET 0/3] virtio: Implement virtio pstore device (v3)

[Namhyung Kim]

Hello,

This is another iteration of the virtio-pstore work.  In this patchset
I addressed most of feedbacks from previous version and drooped the
support for PSTORE_TYPE_CONSOLE for simplicity.  It'll be added once the basic 
implementation

 * changes in v3)
  - use QIOChannel API  (Stefan, Daniel)
  - add bound check for malcious guests  (Daniel)
  - drop support PSTORE_TYPE_CONSOLE for now
  - update license to allow GPL v2 or later  (Michael)
  - limit number of pstore files on qemu

 * changes in v2)
  - update VIRTIO_ID_PSTORE to 22  (Cornelia, Stefan)
  - make buffer size configurable  (Cornelia)
  - support PSTORE_TYPE_CONSOLE  (Kees)
  - use separate virtqueues for read and write
  - support concurrent async write
  - manage pstore (file) id in device side
  - fix various mistakes in qemu device  (Stefan)

It started from the fact that dumping ftrace buffer at kernel
oops/panic takes too much time.  Although there's a way to reduce the
size of the original data, sometimes I want to have the information as
many as possible.  Maybe kexec/kdump can solve this problem but it
consumes some portion of guest memory so I'd like to avoid it.  And I
know the qemu + crashtool can dump and analyze the whole guest memory
including the ftrace buffer without wasting guest memory, but it adds
one more layer and has some limitation as an out-of-tree tool like not
being in sync with the kernel changes.

So I think it'd be great using the pstore interface to dump guest
kernel data on the host.  One can read the data on the host directly
or on the guest (at the next boot) using pstore filesystem as usual.
While this patchset only implements dumping kernel log buffer, it can
be extended to have ftrace buffer and probably some more..

The patch 0001 implements virtio pstore driver.  It has two virt queue
for (sync) read and (async) write, pstore buffer and io request and
response structure.  The virtio_pstore_req struct is to give
information about the current pstore operation.  The result will be
written to the virtio_pstore_res struct.  For read operation it also
uses virtio_pstore_fileinfo struct.

The patch 0002 and 0003 implement virtio-pstore legacy PCI device on
qemu-kvm and kvmtool respectively.  I referenced virtio-baloon and
virtio-rng implementations and I don't know whether kvmtool supports
modern virtio 1.0+ spec.  Other transports might be supported later.

For example, using virtio-pstore on qemu looks like below:

  $ qemu-system-x86_64 -enable-kvm -device virtio-pstore,directory=xxx

When guest kernel gets panic the log messages will be saved under the
xxx directory.

  $ ls xxx
  dmesg-1.enc.z  dmesg-2.enc.z

As you can see the pstore subsystem compresses the log data using zlib
(now supports lzo and lz4 too).  The data can be extracted with the
following command:

  $ cat xxx/dmesg-1.enc.z | \
  > python -c 'import sys, zlib; print(zlib.decompress(sys.stdin.read()))'
  Oops#1 Part1
  <5>[0.00] Linux version 4.6.0kvm+ (namhyung@danjae) (gcc version 
5.3.0 (GCC) ) #145 SMP Mon Jul 18 10:22:45 KST 2016
  <6>[0.00] Command line: root=/dev/vda console=ttyS0
  <6>[0.00] x86/fpu: Legacy x87 FPU detected.
  <6>[0.00] x86/fpu: Using 'eager' FPU context switches.
  <6>[0.00] e820: BIOS-provided physical RAM map:
  <6>[0.00] BIOS-e820: [mem 0x-0x0009fbff] 
usable
  <6>[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] 
reserved
  <6>[0.00] BIOS-e820: [mem 0x000f-0x000f] 
reserved
  <6>[0.00] BIOS-e820: [mem 0x0010-0x07fddfff] 
usable
  <6>[0.00] BIOS-e820: [mem 0x07fde000-0x07ff] 
reserved
  <6>[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] 
reserved
  <6>[0.00] BIOS-e820: [mem 0xfffc-0x] 
reserved
  <6>[0.00] NX (Execute Disable) protection: active
  <6>[0.00] SMBIOS 2.8 present.
  <7>[0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
  ...


Namhyung Kim (3):
  virtio: Basic implementation of virtio pstore driver
  qemu: Implement virtio-pstore device
  kvmtool: Implement virtio-pstore device

 drivers/virtio/Kconfig |  10 +
 drivers/virtio/Makefile|   1 +
 drivers/virtio/virtio_pstore.c | 417 +
 include/uapi/linux/Kbuild  |   1 +
 include/uapi/linux/virtio_ids.h|   1 +
 include/uapi/linux/virtio_pstore.h |  74 +++
 6 files changed, 504 insertions(+)
 create mode 100644 drivers/virtio/virtio_pstore.c
 create mode 100644 include/uapi/linux/virtio_pstore.h


Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: "Michael S. Tsirkin" 
Cc: Anthony Liguori 
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Minchan Kim 
Cc: Will Deacon 
Cc: k...@vger.kernel.org
Cc: qemu-

[PATCH 3/3] kvmtool: Implement virtio-pstore device

[Namhyung Kim]

From: Namhyung Kim 

Add virtio pstore device to allow kernel log messages saved on the
host.  With this patch, it will save the log files under directory given
by --pstore option.

  $ lkvm run --pstore=dir-xx

  (guest) # echo c > /proc/sysrq-trigger

  $ ls dir-xx
  dmesg-1.enc.z  dmesg-2.enc.z

The log files are usually compressed using zlib.  User can easily see
the messages on the host or on the guest (using pstore filesystem).

Cc: Will Deacon 
Signed-off-by: Namhyung Kim 
---
 Makefile |   1 +
 builtin-run.c|   2 +
 include/kvm/kvm-config.h |   1 +
 include/kvm/virtio-pci-dev.h |   2 +
 include/kvm/virtio-pstore.h  |  53 +
 include/linux/virtio_ids.h   |   1 +
 virtio/pstore.c  | 447 +++
 7 files changed, 507 insertions(+)
 create mode 100644 include/kvm/virtio-pstore.h
 create mode 100644 virtio/pstore.c

diff --git a/Makefile b/Makefile
index 1f0196f..d7462b9 100644
--- a/Makefile
+++ b/Makefile
@@ -67,6 +67,7 @@ OBJS  += virtio/net.o
 OBJS   += virtio/rng.o
 OBJS+= virtio/balloon.o
 OBJS   += virtio/pci.o
+OBJS   += virtio/pstore.o
 OBJS   += disk/blk.o
 OBJS   += disk/qcow.o
 OBJS   += disk/raw.o
diff --git a/builtin-run.c b/builtin-run.c
index 72b878d..08c12dd 100644
--- a/builtin-run.c
+++ b/builtin-run.c
@@ -128,6 +128,8 @@ void kvm_run_set_wrapper_sandbox(void)
" rootfs"), \
OPT_STRING('\0', "hugetlbfs", &(cfg)->hugetlbfs_path, "path",   \
"Hugetlbfs path"),  \
+   OPT_STRING('\0', "pstore", &(cfg)->pstore_path, "path", \
+   "pstore data path"),\
\
OPT_GROUP("Kernel options:"),   \
OPT_STRING('k', "kernel", &(cfg)->kernel_filename, "kernel",\
diff --git a/include/kvm/kvm-config.h b/include/kvm/kvm-config.h
index 386fa8c..42b7651 100644
--- a/include/kvm/kvm-config.h
+++ b/include/kvm/kvm-config.h
@@ -45,6 +45,7 @@ struct kvm_config {
const char *hugetlbfs_path;
const char *custom_rootfs_name;
const char *real_cmdline;
+   const char *pstore_path;
struct virtio_net_params *net_params;
bool single_step;
bool vnc;
diff --git a/include/kvm/virtio-pci-dev.h b/include/kvm/virtio-pci-dev.h
index 48ae018..4339d94 100644
--- a/include/kvm/virtio-pci-dev.h
+++ b/include/kvm/virtio-pci-dev.h
@@ -15,6 +15,7 @@
 #define PCI_DEVICE_ID_VIRTIO_BLN   0x1005
 #define PCI_DEVICE_ID_VIRTIO_SCSI  0x1008
 #define PCI_DEVICE_ID_VIRTIO_9P0x1009
+#define PCI_DEVICE_ID_VIRTIO_PSTORE0x100a
 #define PCI_DEVICE_ID_VESA 0x2000
 #define PCI_DEVICE_ID_PCI_SHMEM0x0001
 
@@ -34,5 +35,6 @@
 #define PCI_CLASS_RNG  0xff
 #define PCI_CLASS_BLN  0xff
 #define PCI_CLASS_9P   0xff
+#define PCI_CLASS_PSTORE   0xff
 
 #endif /* VIRTIO_PCI_DEV_H_ */
diff --git a/include/kvm/virtio-pstore.h b/include/kvm/virtio-pstore.h
new file mode 100644
index 000..9f52ffd
--- /dev/null
+++ b/include/kvm/virtio-pstore.h
@@ -0,0 +1,53 @@
+#ifndef KVM__PSTORE_VIRTIO_H
+#define KVM__PSTORE_VIRTIO_H
+
+#include 
+#include 
+
+#define VIRTIO_PSTORE_CMD_NULL   0
+#define VIRTIO_PSTORE_CMD_OPEN   1
+#define VIRTIO_PSTORE_CMD_READ   2
+#define VIRTIO_PSTORE_CMD_WRITE  3
+#define VIRTIO_PSTORE_CMD_ERASE  4
+#define VIRTIO_PSTORE_CMD_CLOSE  5
+
+#define VIRTIO_PSTORE_TYPE_UNKNOWN  0
+#define VIRTIO_PSTORE_TYPE_DMESG1
+
+#define VIRTIO_PSTORE_FL_COMPRESSED  1
+
+struct virtio_pstore_req {
+   __virtio16  cmd;
+   __virtio16  type;
+   __virtio32  flags;
+   __virtio64  id;
+   __virtio32  count;
+   __virtio32  reserved;
+};
+
+struct virtio_pstore_res {
+   __virtio16  cmd;
+   __virtio16  type;
+   __virtio32  ret;
+};
+
+struct virtio_pstore_fileinfo {
+   __virtio64  id;
+   __virtio32  count;
+   __virtio16  type;
+   __virtio16  unused;
+   __virtio32  flags;
+   __virtio32  len;
+   __virtio64  time_sec;
+   __virtio32  time_nsec;
+   __virtio32  reserved;
+};
+
+struct virtio_pstore_config {
+   __virtio32  bufsize;
+};
+
+int virtio_pstore__init(struct kvm *kvm);
+int virtio_pstore__exit(struct kvm *kvm);
+
+#endif /* KVM__PSTORE_VIRTIO_H */
diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h
index 5f60aa4..40eabf7 100644
--- a/include/linux/virtio_ids.h
+++ b/include/lin

[PATCH 2/3] qemu: Implement virtio-pstore device

[Namhyung Kim]

Add virtio pstore device to allow kernel log files saved on the host.
It will save the log files on the directory given by pstore device
option.

  $ qemu-system-x86_64 -device virtio-pstore,directory=dir-xx ...

  (guest) # echo c > /proc/sysrq-trigger

  $ ls dir-xx
  dmesg-1.enc.z  dmesg-2.enc.z

The log files are usually compressed using zlib.  Users can see the log
messages directly on the host or on the guest (using pstore filesystem).

The 'directory' property is required for virtio-pstore device to work.
It also adds 'bufsize' property to set size of pstore bufer.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: "Michael S. Tsirkin" 
Cc: Anthony Liguori 
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Minchan Kim 
Cc: Daniel P. Berrange 
Cc: k...@vger.kernel.org
Cc: qemu-de...@nongnu.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Namhyung Kim 
---
 hw/virtio/Makefile.objs|   2 +-
 hw/virtio/virtio-pci.c |  52 ++
 hw/virtio/virtio-pci.h |  14 +
 hw/virtio/virtio-pstore.c  | 699 +
 include/hw/pci/pci.h   |   1 +
 include/hw/virtio/virtio-pstore.h  |  36 ++
 include/standard-headers/linux/virtio_ids.h|   1 +
 include/standard-headers/linux/virtio_pstore.h |  76 +++
 qdev-monitor.c |   1 +
 9 files changed, 881 insertions(+), 1 deletion(-)
 create mode 100644 hw/virtio/virtio-pstore.c
 create mode 100644 include/hw/virtio/virtio-pstore.h
 create mode 100644 include/standard-headers/linux/virtio_pstore.h

diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
index 3e2b175..aae7082 100644
--- a/hw/virtio/Makefile.objs
+++ b/hw/virtio/Makefile.objs
@@ -4,4 +4,4 @@ common-obj-y += virtio-bus.o
 common-obj-y += virtio-mmio.o
 
 obj-y += virtio.o virtio-balloon.o 
-obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
+obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o virtio-pstore.o
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 755f921..c184823 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -2416,6 +2416,57 @@ static const TypeInfo virtio_host_pci_info = {
 };
 #endif
 
+/* virtio-pstore-pci */
+
+static void virtio_pstore_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
+{
+VirtIOPstorePCI *vps = VIRTIO_PSTORE_PCI(vpci_dev);
+DeviceState *vdev = DEVICE(&vps->vdev);
+Error *err = NULL;
+
+qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
+object_property_set_bool(OBJECT(vdev), true, "realized", &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+}
+
+static void virtio_pstore_pci_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
+PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
+
+k->realize = virtio_pstore_pci_realize;
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+
+pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_PSTORE;
+pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
+pcidev_k->class_id = PCI_CLASS_OTHERS;
+}
+
+static void virtio_pstore_pci_instance_init(Object *obj)
+{
+VirtIOPstorePCI *dev = VIRTIO_PSTORE_PCI(obj);
+
+virtio_instance_init_common(obj, &dev->vdev, sizeof(dev->vdev),
+TYPE_VIRTIO_PSTORE);
+object_property_add_alias(obj, "directory", OBJECT(&dev->vdev),
+  "directory", &error_abort);
+object_property_add_alias(obj, "bufsize", OBJECT(&dev->vdev),
+  "bufsize", &error_abort);
+}
+
+static const TypeInfo virtio_pstore_pci_info = {
+.name  = TYPE_VIRTIO_PSTORE_PCI,
+.parent= TYPE_VIRTIO_PCI,
+.instance_size = sizeof(VirtIOPstorePCI),
+.instance_init = virtio_pstore_pci_instance_init,
+.class_init= virtio_pstore_pci_class_init,
+};
+
 /* virtio-pci-bus */
 
 static void virtio_pci_bus_new(VirtioBusState *bus, size_t bus_size,
@@ -2485,6 +2536,7 @@ static void virtio_pci_register_types(void)
 #ifdef CONFIG_VHOST_SCSI
 type_register_static(&vhost_scsi_pci_info);
 #endif
+type_register_static(&virtio_pstore_pci_info);
 }
 
 type_init(virtio_pci_register_types)
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index 25fbf8a..354b2b7 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -31,6 +31,7 @@
 #ifdef CONFIG_VHOST_SCSI
 #include "hw/virtio/vhost-scsi.h"
 #endif
+#include "hw/virtio/virtio-pstore.h"
 
 typedef struct VirtIOPCIProxy VirtIOPCIProxy;
 typedef struct VirtIOBlkPCI VirtIOBlkPCI;
@@ -44,6 +45,7 @@ typedef struct VirtIOInputPCI VirtIOInputPCI;
 typedef struct VirtIOInputHIDPCI VirtIOInputHIDPCI;
 typedef struct VirtIOInputHostPCI VirtIOInputHostPCI;
 typedef struct Vir

[PATCH 1/3] virtio: Basic implementation of virtio pstore driver

[Namhyung Kim]

The virtio pstore driver provides interface to the pstore subsystem so
that the guest kernel's log/dump message can be saved on the host
machine.  Users can access the log file directly on the host, or on the
guest at the next boot using pstore filesystem.  It currently deals with
kernel log (printk) buffer only, but we can extend it to have other
information (like ftrace dump) later.

It supports legacy PCI device using single order-2 page buffer.  It uses
two virtqueues - one for (sync) read and another for (async) write.
Since it cannot wait for write finished, it supports up to 128
concurrent IO.  The buffer size is configurable now.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: "Michael S. Tsirkin" 
Cc: Anthony Liguori 
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Minchan Kim 
Cc: k...@vger.kernel.org
Cc: qemu-de...@nongnu.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Namhyung Kim 
---
 drivers/virtio/Kconfig |  10 +
 drivers/virtio/Makefile|   1 +
 drivers/virtio/virtio_pstore.c | 417 +
 include/uapi/linux/Kbuild  |   1 +
 include/uapi/linux/virtio_ids.h|   1 +
 include/uapi/linux/virtio_pstore.h |  74 +++
 6 files changed, 504 insertions(+)
 create mode 100644 drivers/virtio/virtio_pstore.c
 create mode 100644 include/uapi/linux/virtio_pstore.h

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 77590320d44c..8f0e6c796c12 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -58,6 +58,16 @@ config VIRTIO_INPUT
 
 If unsure, say M.
 
+config VIRTIO_PSTORE
+   tristate "Virtio pstore driver"
+   depends on VIRTIO
+   depends on PSTORE
+   ---help---
+This driver supports virtio pstore devices to save/restore
+panic and oops messages on the host.
+
+If unsure, say M.
+
  config VIRTIO_MMIO
tristate "Platform bus driver for memory mapped virtio devices"
depends on HAS_IOMEM && HAS_DMA
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 41e30e3dc842..bee68cb26d48 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -5,3 +5,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
 virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
 obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
 obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_PSTORE) += virtio_pstore.o
diff --git a/drivers/virtio/virtio_pstore.c b/drivers/virtio/virtio_pstore.c
new file mode 100644
index ..0a63c7db4278
--- /dev/null
+++ b/drivers/virtio/virtio_pstore.c
@@ -0,0 +1,417 @@
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VIRT_PSTORE_ORDER2
+#define VIRT_PSTORE_BUFSIZE  (4096 << VIRT_PSTORE_ORDER)
+#define VIRT_PSTORE_NR_REQ   128
+
+struct virtio_pstore {
+   struct virtio_device*vdev;
+   struct virtqueue*vq[2];
+   struct pstore_info   pstore;
+   struct virtio_pstore_req req[VIRT_PSTORE_NR_REQ];
+   struct virtio_pstore_res res[VIRT_PSTORE_NR_REQ];
+   unsigned int req_id;
+
+   /* Waiting for host to ack */
+   wait_queue_head_t   acked;
+   int failed;
+};
+
+#define TYPE_TABLE_ENTRY(_entry)   \
+   { PSTORE_TYPE_##_entry, VIRTIO_PSTORE_TYPE_##_entry }
+
+struct type_table {
+   int pstore;
+   u16 virtio;
+} type_table[] = {
+   TYPE_TABLE_ENTRY(DMESG),
+};
+
+#undef TYPE_TABLE_ENTRY
+
+
+static u16 to_virtio_type(struct virtio_pstore *vps, enum pstore_type_id type)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(type_table); i++) {
+   if (type == type_table[i].pstore)
+   return cpu_to_virtio16(vps->vdev, type_table[i].virtio);
+   }
+
+   return cpu_to_virtio16(vps->vdev, VIRTIO_PSTORE_TYPE_UNKNOWN);
+}
+
+static enum pstore_type_id from_virtio_type(struct virtio_pstore *vps, u16 
type)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(type_table); i++) {
+   if (virtio16_to_cpu(vps->vdev, type) == type_table[i].virtio)
+   return type_table[i].pstore;
+   }
+
+   return PSTORE_TYPE_UNKNOWN;
+}
+
+static void virtpstore_ack(struct virtqueue *vq)
+{
+   struct virtio_pstore *vps = vq->vdev->priv;
+
+   wake_up(&vps->acked);
+}
+
+static void virtpstore_check(struct virtqueue *vq)
+{
+   struct virtio_pstore *vps = vq->vdev->priv;
+   struct virtio_pstore_res *res;
+   unsigned int len;
+
+   res = virtqueue_get_buf(vq, &len);
+   if (res == NULL)
+   return;
+
+   if (virtio32_to_cpu(vq->vdev, res->ret) < 0)
+   vps->failed = 1;
+}
+
+static void virt_pstore_get_reqs(struct virtio_pstore *vps,
+   

Re: [PATCH] Fix /proc/stat freezes (was [PATCH v15] "task_isolation" mode)

[Chris Metcalf]

On 8/17/2016 3:37 PM, Christoph Lameter wrote:

On Tue, 16 Aug 2016, Chris Metcalf wrote:


- Dropped Christoph Lameter's patch to avoid scheduling the
   clocksource watchdog on nohz cores; the recommendation is to just
   boot with tsc=reliable for NOHZ in any case, if necessary.

We also said that there should be a WARN_ON if tsc=reliable is not
specified and processors are put into NOHZ mode. This is something not
obvious causing scheduling events on NOHZ processors.


Yes, I agree.  Frederic said he would queue a patch to do that, so I
didn't want to propose another patch that would conflict.


Frederic, do you have a sense of what is left to be done there?
I can certainly try to contribute to that effort as well.

Here is a potential fix to the problem that /proc/stat values freeze when
processors go into NOHZ busy mode. I'd like to hear what people think
about the approach here. In particular one issue may be that I am
accessing remote tick-sched structures without serialization. But for
top/ps this may be ok. I noticed that other values shown by top/os also
sometime are a bit fuzzy.


This seems pretty plausible to me, but I'm not an expert on what kind
of locking might be required for these data structures.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

[PATCH] wan-cosa: Use memdup_user() rather than duplicating its implementation

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 10:10:12 +0200

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/wan/cosa.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index b87fe0a..02f5809 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -875,16 +875,10 @@ static ssize_t cosa_write(struct file *file,
if (count > COSA_MTU)
count = COSA_MTU;

-   /* Allocate the buffer */
-   kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA);
-   if (kbuf == NULL) {
+   kbuf = memdup_user(buf, count);
+   if (IS_ERR(kbuf)) {
up(&chan->wsem);
-   return -ENOMEM;
-   }
-   if (copy_from_user(kbuf, buf, count)) {
-   up(&chan->wsem);
-   kfree(kbuf);
-   return -EFAULT;
+   return PTR_ERR(kbuf);
}
chan->tx_status=0;
cosa_start_tx(chan, kbuf, count);
-- 
2.9.3

Re: [PATCH] wan-cosa: Use memdup_user() rather than duplicating its implementation

[Christophe JAILLET]

Le 20/08/2016 à 10:25, SF Markus Elfring a écrit :

From: Markus Elfring 
Date: Sat, 20 Aug 2016 10:10:12 +0200

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
  drivers/net/wan/cosa.c | 12 +++-
  1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index b87fe0a..02f5809 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -875,16 +875,10 @@ static ssize_t cosa_write(struct file *file,
if (count > COSA_MTU)
count = COSA_MTU;

-   /* Allocate the buffer */
-   kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA);
In this case, 'memdup_user()' has a different meaning, as GFP_DMA will 
no more be used for this memory allocation.



-   if (kbuf == NULL) {
+   kbuf = memdup_user(buf, count);
+   if (IS_ERR(kbuf)) {
up(&chan->wsem);
-   return -ENOMEM;
-   }
-   if (copy_from_user(kbuf, buf, count)) {
-   up(&chan->wsem);
-   kfree(kbuf);
-   return -EFAULT;
+   return PTR_ERR(kbuf);
}
chan->tx_status=0;
cosa_start_tx(chan, kbuf, count);




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: [PATCH 1/2] mmc-block: Use memdup_user() rather than duplicating its implementation

[walter harms]

Am 19.08.2016 23:10, schrieb SF Markus Elfring:
> From: Markus Elfring 
> Date: Fri, 19 Aug 2016 22:46:38 +0200
> 
> * Reuse existing functionality from memdup_user() instead of keeping
>   duplicate source code.
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Delete the integer variable "err" then because the pointer
>   variable "idata" should be sufficient to handle return values alone
>   in this function.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/mmc/card/block.c | 26 +-
>  1 file changed, 9 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 48a5dd7..6ce9492 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -337,22 +337,21 @@ static struct mmc_blk_ioc_data 
> *mmc_blk_ioctl_copy_from_user(
>   struct mmc_ioc_cmd __user *user)
>  {
>   struct mmc_blk_ioc_data *idata;
> - int err;
>  
>   idata = kmalloc(sizeof(*idata), GFP_KERNEL);
>   if (!idata) {
> - err = -ENOMEM;
> + idata = ERR_PTR(-ENOMEM);
>   goto out;
>   }
>  
>   if (copy_from_user(&idata->ic, user, sizeof(idata->ic))) {
> - err = -EFAULT;
> + idata = ERR_PTR(-EFAULT);
>   goto idata_err;
>   }
>  
>   idata->buf_bytes = (u64) idata->ic.blksz * idata->ic.blocks;
>   if (idata->buf_bytes > MMC_IOC_MAX_BYTES) {
> - err = -EOVERFLOW;
> + idata = ERR_PTR(-EOVERFLOW);
>   goto idata_err;
>   }
>  
> @@ -361,26 +360,19 @@ static struct mmc_blk_ioc_data 
> *mmc_blk_ioctl_copy_from_user(
>   return idata;
>   }
>  
> - idata->buf = kmalloc(idata->buf_bytes, GFP_KERNEL);
> - if (!idata->buf) {
> - err = -ENOMEM;
> + idata->buf = memdup_user((void __user *)(unsigned long)
> +  idata->ic.data_ptr,
> +  idata->buf_bytes);
> + if (IS_ERR(idata->buf)) {
> + idata = (void *) idata->buf;
>   goto idata_err;
>   }
> -
> - if (copy_from_user(idata->buf, (void __user *)(unsigned long)
> - idata->ic.data_ptr, idata->buf_bytes)) {
> - err = -EFAULT;
> - goto copy_err;
> - }
> -
>   return idata;
>  
> -copy_err:
> - kfree(idata->buf);
>  idata_err:
>   kfree(idata);
>  out:
> - return ERR_PTR(err);
> + return idata;
>  }


This looks strange, returning a freed pointer is a bad idea. I suggest a
idata=NULL after kfree().

re,
 wh

>  
>  static int mmc_blk_ioctl_copy_to_user(struct mmc_ioc_cmd __user *ic_ptr,

Re: [PATCH v8 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods

[Chris Metcalf]

On 8/18/2016 10:12 AM, Petr Mladek wrote:

On Tue 2016-08-16 15:50:21, Chris Metcalf wrote:

Currently you can only request a backtrace of either all cpus, or
all cpus but yourself.  It can also be helpful to request a remote
backtrace of a single cpu, and since we want that, the logical
extension is to support a cpumask as the underlying primitive.

This change modifies the existing lib/nmi_backtrace.c code to take
a cpumask as its basic primitive, and modifies the linux/nmi.h code
to use the new "cpumask" method instead.

The mips code ignored the "include_self" boolean but with this change
it will now also dump a local backtrace if requested.

diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
index 7429ad09fbe3..fea1fa7726e3 100644
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -569,9 +569,16 @@ static void arch_dump_stack(void *info)
dump_stack();
  }
  
-void arch_trigger_all_cpu_backtrace(bool include_self)

+void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
  {
-   smp_call_function(arch_dump_stack, NULL, 1);
+   long this_cpu = get_cpu();
+
+   if (cpumask_test_cpu(this_cpu, mask) && !exclude_self)
+   dump_stack();

The bit is not cleared in the mask. Therefore arch_dump_stack
will get called for this CPU as well.


Actually, and kind of confusingly, smp_call_function_many() never calls
the current cpu, even if it is in the mask.  So this code is OK as-is.


Otherwise the patch patch looks good to me.


Great, thanks!  Should I add your Reviewed-by?

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: [PATCH] mlx5/core: Use memdup_user() rather than duplicating its implementation

[walter harms]

Am 20.08.2016 08:01, schrieb SF Markus Elfring:
> From: Markus Elfring 
> Date: Sat, 20 Aug 2016 07:50:09 +0200
> 
> * Reuse existing functionality from memdup_user() instead of keeping
>   duplicate source code.
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Return directly if this copy operation failed.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 17 +++--
>  1 file changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c 
> b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> index 6388bc0..bb89f04 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> @@ -1132,7 +1132,6 @@ static ssize_t data_write(struct file *filp, const char 
> __user *buf,
>   struct mlx5_core_dev *dev = filp->private_data;
>   struct mlx5_cmd_debug *dbg = &dev->cmd.dbg;
>   void *ptr;
> - int err;
>  
>   if (*pos != 0)
>   return -EINVAL;
> @@ -1140,25 +1139,15 @@ static ssize_t data_write(struct file *filp, const 
> char __user *buf,
>   kfree(dbg->in_msg);
>   dbg->in_msg = NULL;
>   dbg->inlen = 0;
> -
> - ptr = kzalloc(count, GFP_KERNEL);
> - if (!ptr)
> - return -ENOMEM;
> -
> - if (copy_from_user(ptr, buf, count)) {
> - err = -EFAULT;
> - goto out;
> - }
> + ptr = memdup_user(buf, count);
> + if (IS_ERR(ptr))
> + return PTR_ERR(ptr);
>   dbg->in_msg = ptr;
>   dbg->inlen = count;
>  
>   *pos = count;
>  

maybe i am missing something here but why do you need ptr ?

The use of count looks even more confusing it is stored in
 dbg->inlen, *pos and is returned.
is that realy needed ?

re,
 wh

>   return count;
> -
> -out:
> - kfree(ptr);
> - return err;
>  }
>  
>  static ssize_t data_read(struct file *filp, char __user *buf, size_t count,

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
>  wrote:
>> On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
>>> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
 On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
  wrote:
> On Thu, Aug 18, 2016 at 09:09:26PM +0800, zhongjiang wrote:
>> At present, boot cpu will bound to a node from device tree when node_off 
>> enable.
>> if the node is not initialization, it will lead to a following problem.
>>
>>  next_zones_zonelist+0x18/0x80
>>  __build_all_zonelists+0x1e0/0x288
>>  build_all_zonelists_init+0x10/0x1c
>>  build_all_zonelists+0x114/0x128
>>  start_kernel+0x1a0/0x414
> I think this "problem" is missing a lot of information. Is this supposed
> to be a kernel panic?
>
>> The patch fix it by fallback to node 0. therefore, the cpu will bound to 
>> the node
>> correctly.
>>
>> Signed-off-by: zhongjiang 
>> ---
>>  arch/arm64/mm/numa.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 4dcd7d6..1f8f5da 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -119,7 +119,7 @@ void numa_store_cpu_info(unsigned int cpu)
>>  void __init early_map_cpu_to_node(unsigned int cpu, int nid)
>>  {
>>   /* fallback to node 0 */
>> - if (nid < 0 || nid >= MAX_NUMNODES)
>> + if (nid < 0 || nid >= MAX_NUMNODES || numa_off)
 i  did not understood how this line change fixes the issue that you
 have mentioned (i too not understood fully the issue description)
 this array used while mapping node id when secondary cores comes up
 when numa_off is set the cpu_to_node_map[cpu] is not used and set to
 node0 always( refer function numa_store_cpu_info)..
 please provide more details to understand the issue you are facing.
 /*
  *  Set the cpu to node and mem mapping
  */
 void numa_store_cpu_info(unsigned int cpu)
 {
 map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
 }

 thanks
 Ganapat
>>> The issue comes up when we test the kdump. it will leads to kernel crash.
>>> when I debug the issue, I find boot cpu actually bound to the node1. while
>>> node1 is not real existence when numa_off enable.
>> boot cpu is default mapped to node0
>> are you running with any other patches?
> if you added any patch to change this code
>   /* init boot processor */
> cpu_to_node_map[0] = 0;
> map_cpu_to_node(0, 0);
>
> then adding code to take-care numa_off here might solve your issue.
 but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
 the relation node. and the node is from devicetree.

 you points to the code will be covered with another node. therefore, it is
 possible that cpu_to_node[cpu] will leads to the incorrect results. therefore,
 The crash will come up.
>>> __build_all_zonelists will call the cpu_to_node[cpu], but orresponding 
>>> relation
>>> will be obtained from the devicetree. therefore, the issue will come up.
>> when numa_off, all cpus are mapped to node0( refer
>> numa_store_cpu_info) and device tree mapping is ignored.
>>> The corresponding message is as follows when kdump start. it is obvious 
>>> that mem
>>> range points to the node1 in the devicetree.
>>>
>>> Early memory node ranges
>>> node   0: [mem 0x005fe000-0x005f]
>>> Initmem setup node 0 [mem 0x005fe000-0x005f]
>>>
>>> Unable to handle kernel paging request at virtual address 1690
>>> pgd = 81226000
>>> [1690] *pgd=
>>> Internal error: Oops: 9604 [#1] SMP
>>>  Modules linked in:
>>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
>>> Hardware name: Hisilicon Hi1612 Development Board (DT)
>>>  task: 8102b730 ti: 81018000 task.ti: 81018000
>>> PC is at next_zones_zonelist+0x18/0x80
>>>  LR is at __build_all_zonelists+0x1e0/0x288
>>> next_zones_zonelist+0x18/0x80
>>>  __build_all_zonelists+0x1e0/0x288
>>> build_all_zonelists_init+0x10/0x1c
>>>  build_all_zonelists+0x114/0x128
>>>  start_kernel+0x1a0/0x414
>>   nid = 0;
>>
>>   cpu_to_node_map[cpu] = nid;
> The patch looks fine (slight inconsistence from the map_cpu_to_node()
> callers but I guess we don't want to expose numa_off outside this file).
> I would however like to see an Ack from Ganapat (cc'ed).
>
> --
> Catalin
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 .

>>>
> .
>

Re: [PATCH 4.7 000/186] 4.7.2-stable review

[Greg Kroah-Hartman]

On Fri, Aug 19, 2016 at 12:45:29PM -0700, kernelci.org bot wrote:
> stable-rc boot: 146 boots: 0 failed, 139 passed with 7 offline 
> (v4.7.1-186-ge94b177018fe)
> 
> Full Boot Summary: 
> https://kernelci.org/boot/all/job/stable-rc/kernel/v4.7.1-186-ge94b177018fe/
> Full Build Summary: 
> https://kernelci.org/build/stable-rc/kernel/v4.7.1-186-ge94b177018fe/

Great, thanks for this, and the 2 other reports, much appreciated.

greg k-h

[PATCH] lib/Kconfig.debug: fix typo in select statement

[Valentin Rothberg]

Commit 484f29c7430b3 ("bug: Provide toggle for BUG on data corruption")
added a Kconfig select statement on CONFIG_DEBUG_LIST, but the CONFIG_
prefix is only used in Make and C(PP) syntax.  Remove the CONFIG_ prefix
to correctly select the Kconfig option DEBUG_LIST.

Signed-off-by: Valentin Rothberg 
---
I detected the issue with scripts/checkkconfigsymbols.py

 lib/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5dea4d0a5a07..c2bbaae13d04 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2009,7 +2009,7 @@ config TEST_STATIC_KEYS
 
 config BUG_ON_DATA_CORRUPTION
bool "Trigger a BUG when data corruption is detected"
-   select CONFIG_DEBUG_LIST
+   select DEBUG_LIST
help
  Select this option if the kernel should BUG when it encounters
  data corruption in kernel memory structures when they get checked
-- 
2.9.3

BUG: spinlock recursion in sched/fair.c | struct rq::lock

[Vegard Nossum]

Hi,

Got this:

BUG: spinlock recursion on CPU#0, trinity-c2/27519
 lock: 0x88011ab20180, .magic: dead4ead, .owner: trinity-c2/27519, 
.owner_cpu: 2

CPU: 0 PID: 27519 Comm: trinity-c2 Not tainted 4.8.0-rc2+ #143
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014

 88010587 88011289ef30 81f08d11 88011ab20180
 88010587 88011289ef68 8134289d 81312cde
  88011ab20180 0082 88011ab20190
Call Trace:
 [] dump_stack+0x65/0x84
 [] spin_dump+0x14d/0x270
 [] ? load_balance+0x62e/0x24c0
 [] do_raw_spin_lock+0x1ff/0x2b0
 [] _raw_spin_lock_irqsave+0x51/0x60
 [] ? load_balance+0x62e/0x24c0
 [] load_balance+0x62e/0x24c0
 [] ? find_busiest_group+0x2450/0x2450
 [] ? sched_clock+0x9/0x10
 [] ? sched_clock_cpu+0x152/0x1e0
 [] pick_next_task_fair+0x8e3/0x1290
 [] ? pick_next_task_fair+0x682/0x1290
 [] ? load_balance+0x24c0/0x24c0
 [] ? deactivate_task+0x11c/0x310
 [] __schedule+0x23d/0x19a0
 [] schedule+0x9a/0x1c0
 [] p9_client_rpc+0x336/0xde0
 [] ? p9_client_flush+0x1c0/0x1c0
 [] ? posix_lock_inode+0x661/0x1b80
 [] ? posix_lock_inode+0x6be/0x1b80
 [] ? locks_copy_lock+0x1a0/0x1a0
 [] ? wake_atomic_t_function+0x210/0x210
 [] ? __might_sleep+0x90/0x1a0
 [] ? locks_lock_inode_wait+0x207/0x310
 [] p9_client_lock_dotl+0x16f/0x4a0
 [] v9fs_file_do_lock+0x2b2/0x4f0
 [] ? v9fs_mmap_file_mmap+0x2d0/0x2d0
 [] ? perf_iterate_sb+0x7a/0x720
 [] v9fs_file_lock_dotl+0x1e9/0x850
 [] ? perf_event_mmap_output+0x800/0x800
 [] ? v9fs_file_flock_dotl+0x280/0x280
 [] ? __this_cpu_preempt_check+0x13/0x20
 [] ? __perf_event_task_sched_in+0x128/0x690
 [] vfs_lock_file+0x6c/0xf0
 [] locks_remove_posix.part.35+0x103/0x2e0
 [] ? finish_task_switch+0x180/0x660
 [] ? do_lock_file_wait+0x200/0x200
 [] ? fsnotify_find_inode_mark+0x1e/0x50
 [] ? fsnotify_find_inode_mark+0x38/0x50
 [] ? _raw_spin_unlock+0x2c/0x50
 [] ? fsnotify_find_inode_mark+0x38/0x50
 [] locks_remove_posix+0x86/0xd0
 [] filp_close+0xdc/0x130
 [] put_files_struct+0x124/0x230
 [] exit_files+0x79/0xa0
 [] do_exit+0x730/0x2b70
 [] ? ___perf_sw_event+0x284/0x330
 [] ? ___perf_sw_event+0xf4/0x330
 [] ? perf_log_itrace_start+0x3a0/0x3a0
 [] ? mm_update_next_owner+0x720/0x720
 [] ? get_signal+0x1a2/0x1120
 [] do_group_exit+0xf4/0x2f0
 [] get_signal+0x53d/0x1120
 [] ? __lock_acquire.isra.32+0xc2/0x1a30
 [] do_signal+0x83/0x1e20
 [] ? debug_smp_processor_id+0x17/0x20
 [] ? setup_sigcontext+0x7d0/0x7d0
 [] ? __do_page_fault+0x53b/0x8f0
 [] ? perf_iterate_sb+0x97/0x720
 [] ? trace_do_page_fault+0x18d/0x310
 [] ? do_async_page_fault+0x27/0xa0
 [] ? async_page_fault+0x28/0x30
 [] exit_to_usermode_loop+0xaf/0x140
 [] syscall_return_slowpath+0x144/0x170
 [] ret_from_fork+0x2f/0x40

$ addr2line -e vmlinux -i 81342e8f 81312cde 
81315453 83ad499d 83ad629a 83904486

kernel/locking/spinlock_debug.c:75
kernel/locking/spinlock_debug.c:84
kernel/locking/spinlock_debug.c:135
kernel/sched/fair.c:7502 // load_balance()
kernel/sched/fair.c:7770 // idle_balance()
kernel/sched/fair.c:5789 // pick_next_task_fair()
kernel/sched/core.c:3234 // pick_next_task()
kernel/sched/core.c:3365 // __schedule()
kernel/sched/core.c:3406 (discriminator 1) // schedule()
net/9p/client.c:752 (discriminator 13)

It's this bit in load_balance():

more_balance:
raw_spin_lock_irqsave(&busiest->lock, flags);

This is the bit in pick_next_task_fair() and it looks relevant to me
(although I have no scheduler chops):

idle:
/*
 * This is OK, because current is on_cpu, which avoids it being 
picked

 * for load-balance and preemption/IRQs are still disabled avoiding
 * further scheduler activity on it and we're being very careful to
 * re-start the picking loop.
 */
lockdep_unpin_lock(&rq->lock, cookie);
new_tasks = idle_balance(rq);
lockdep_repin_lock(&rq->lock, cookie);

I have:

$ grep SCHED .config
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_SCHED_HRTICK=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
CONFIG_NET_SCHED=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHED_INFO=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_SCHED_TRACER is not set


Vegard

Re: [PATCH 0/2] minor x86 PM source file cleanup

[Pavel Machek]

On Fri 2016-08-19 17:24:00, Al Stone wrote:
> Really minor patches: one to cleanup whitespace, the second just makes
> the code a wee bit more maintainable by correcting some variable names
> without changing functionality.

Acked-by: Pavel Machek 

(for both)

> Al Stone (2):
>   x86: ACPI: remove extraneous white space after semicolon
>   x86: ACPI: make variable names clearer in
> acpi_parse_madt_lapic_entries()
> 
>  arch/x86/kernel/acpi/boot.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 6/6] Add dockerfile

[Dmitry Monakhov]

Theodore Ts'o  writes:

> On Fri, Aug 19, 2016 at 12:27:43PM +0300, Dmitry Monakhov wrote:
>> Actually main idea is to have build environment for xfstests-bld development
>> plus automatic builds gives us CI. This is important because
>> xfstests-blk build is silently broken since May 30 due to 82c3a179
>> (fix proposed: 
>> https://github.com/dmonakhov/xfsprogs/commit/5dc7a0805d6b7a265863413a8e1b7acb191d5280)
>> But this was uncovered because most people do not build xfstests-bld
>> from scratch very often, we all too busy. Let's machine do that :)
>> In fact other good candidate for CI is https://travis-ci.com/
>
> Actually, I'm rebuilding all the time, but I'm not upgrading to the
> latest bleeding edge version of xfsprogs all the time.  In fact, I'm
> currently still using xfsprogs v4.5.0, since that's plenty for the
> testing I'm doing.  I have historically pinned the commit Id's for
> certain projects where newer versions were either (a) known to be
> flaky, or (b) known to be broken in some way -- that's why we
> currently have explicit commit ID's for fio and quota.  Perhaps I
> should add one for xfsprogs as well, so that we only upgrade to newer
> versions when it known to be needed and where it's helpful.
Yes. That is reasonable point.
My original idea was to check that any commit of xfstests-bld will
healthy with default config. And if github/docker build farm may do it
for us for free is it not bad.
>
>> Once we have Dockerfile which encapsulates all dependencies
>> one can create xfstets-blk from scratch simply typing
>> $ docker build -t my-xfstests-bld-image --file Dockerfile
>> Or use precreated environment
>> $ docker pull XXX/xfstests-bld
>
> If you use the precreated environment that will have a fixed commit
> ID.  So the advantage of doing continuous integration of the bleeding
> edge version of xfsprogs only works if you are using the "docker
> build" line, right.
>
>> Once image is created 
>> Log in to container and start hacking xfstest or e2fsprogs etc.
>> $ docker run -i -t XXX/xfstests-bld
>> $ emacs xfstest/tests/ext4/023 
>> $ kvm-xfstests --update-xfstest ext4/023
>> ...
>
> I'm not sure I see the advantage of doing this in a container, I
> guess.  I just do in my standard laptop environment today.
I can not because I laptop from famous thinkpad t430 series with
flaky SSD which starts to return EIO after intensive load.
https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T430s-Intel-SSD-520-180GB-issue/td-p/888083

Also. What about RH/SUSE/Fedora or even Gentoo people? They are exit :)
And if we give them just chance to try debian w/o complexities
maybe they will become debian adepts.
>
>> Other useful feature is ability to speed xfstests-bld by splitting
>> full test-set to groups and run kvm-xfstests instances in parallel.
>> For example:
>> docker run -v my-kernel:/my-kernel XXX/xfstests-bld  \
>>kvm-xfstests.sh --kernel /my-kernel/bzImage -c 1k > 1k.log &
>> docker run -v my-kernel:/my-kernel XXX/xfstests-bld  \
>>kvm-xfstests.sh --kernel /my-kernel/bzImage -c 4k > 4k.log &
>> docker run -v my-kernel:/my-kernel XXX/xfstests-bld  \
>>kvm-xfstests.sh --kernel /my-kernel/bzImage -c dax > dax.log &
>> .
>> w/o sand box they will conflict due to net ports (localhost:7500 etc)
>
> ... and because you will need separate scratch disks for each of the
> docker runs.
Space is not a problem for most people. Average disk size is more that 500Gb
>
> OK, I can see how that's certainly an advantage..  This is what I use
> gce-xfstests for, myself.  :-)
BTW: I would be good thing to have some sort of job preparation mode.
where test does not executed, but only listed. So one can get lists
of tests and then divide it to groups and run in parallel:
$ kvm-xfstests.sh -c 4k -g auto --list > all_tests.txt
# Next line divides all_tests.txt in 8 parts and run them parallel
$ parallel --joblog job.log -j 8 -m -a all_tests.txt "kvm-xfstests.sh -c 4k"
I'll send you a patch.
BTW: Sometimes many parallel jobs provoke BUGON on host kernel due to
some bug in KVM  :)
>
> The main thing I don't really like about the Dockerfile is that with
> the exception of the last use case, everyone would really need to have
> their own customized version of the Docker file, right?  And for
> someone who isn't Docker aware, I'm concerned that it might be very
> confusing to use, especially compared to all of the documentation I
> currently have for kvm-xfstests and gce-xfstests.
Absolutely no. Dockerfile is just script which used for container
creation(similar gen-image). As normal script it should be as generic
as possible. If I've embedded some ad-hoc references to my-config this
is just a common error than every scripts writers do :(
>
> Hmm, I'll have to think about this and play with it a bit more...
>
>   - Ted


signature.asc
Description: PGP signature

Re: [PATCH 1/2] tun: Use memdup_user() rather than duplicating its implementation

[Shmulik Ladkani]

Hi,

On Sat, 20 Aug 2016 09:34:56 +0200 SF Markus Elfring 
 wrote:
> From: Markus Elfring 
> Date: Sat, 20 Aug 2016 08:54:15 +0200
> 
> Reuse existing functionality from memdup_user() instead of keeping
> duplicate source code.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Reviewed-by: Shmulik Ladkani 

Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression

[Mel Gorman]

On Sat, Aug 20, 2016 at 09:48:39AM +1000, Dave Chinner wrote:
> On Fri, Aug 19, 2016 at 11:49:46AM +0100, Mel Gorman wrote:
> > On Thu, Aug 18, 2016 at 03:25:40PM -0700, Linus Torvalds wrote:
> > > It *could* be as simple/stupid as just saying "let's allocate the page
> > > cache for new pages from the current node" - and if the process that
> > > dirties pages just stays around on one single node, that might already
> > > be sufficient.
> > > 
> > > So just for testing purposes, you could try changing that
> > > 
> > > return alloc_pages(gfp, 0);
> > > 
> > > in __page_cache_alloc() into something like
> > > 
> > > return alloc_pages_node(cpu_to_node(raw_smp_processor_id())), 
> > > gfp, 0);
> > > 
> > > or something.
> > > 
> > 
> > The test would be interesting but I believe that keeping heavy writers
> > on one node will force them to stall early on dirty balancing even if
> > there is plenty of free memory on other nodes.
> 
> Well, it depends on the speed of the storage. The higher the speed
> of the storage, the less we care about stalling on dirty pages
> during reclaim. i.e. faster storage == shorter stalls. We really
> should stop thinking we need to optimise reclaim purely for the
> benefit of slow disks.  500MB/s write speed with latencies of a
> under a couple of milliseconds is common hardware these days. pcie
> based storage (e.g. m2, nvme) is rapidly becoming commonplace and
> they can easily do 1-2GB/s write speeds.
> 

I partially agree. I've been of the opinion for a long time that dirty_time
would be desirable and limit the amount of dirty data by microseconds
required to sync the data and pick a default like 5 seconds. It's
non-trivial as the write speed of all BDIs would have to be estimated
and on rotary storage the estimate would be unreliable.

A short-term practical idea would be to distribute pages for writing
only when the dirty limit is almost reached on a given node. For fast
storage, the distribution may never happen.

Neither idea would actually impact the current problem though unless it
was combined with discarding clean cache agressively if the underlying
storage is fast. Hence, it would still be nice if the contention problem
could be mitigated. Did that last patch help any?

-- 
Mel Gorman
SUSE Labs

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

[One Thousand Gnomes]

On Fri, 19 Aug 2016 19:42:37 +0200
"H. Nikolaus Schaller"  wrote:

> > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes 
> > :
> >   
> >> If possible, please do a callback for every character that arrives.
> >> And not only if the rx buffer becomes full, to give the slave driver
> >> a chance to trigger actions almost immediately after every character.
> >> This probably runs in interrupt context and can happen often.  
> > 
> > We don't realistically have the clock cycles to do that on a low end
> > embedded processor handling high speed I/O.  
> 
> well, if we have a low end embedded processor and high-speed I/O, then
> buffering the data before processing doesn't help either since processing
> still will eat up clock cycles.

Of course it helps. You are out of the IRQ handler within the 9 serial
clocks, so you can take another interrupt and grab the next byte. You
will also get benefits from processing the bytes further in blocks, and
if you get too far behind you'll make the flow control limit.

You've also usually got multiple cores these days - although not on the
very low end quite often.

> The question is if this is needed at all. If we have a bluetooth stack with 
> HCI the
> fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. 
> framing
> means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide
> if the byte should go to a buffer or not, check checksums, or discard and move
> the protocol engine to a different state. This is what I assume would be done 
> in
> a callback. No processing needing some ms per frame.

That depends on the processor - remember people run Linux on low end CPUs
including those embedded in an FPGA not just high end PC and ARM class
devices.

The more important question is - purely for the receive side of things -
is a callback which guarantees to be called "soon" after the bytes arrive
sufficient.

If it is then almost no work is needed on the receive side to allow pure
kernel code to manage recevied data directly because the current
buffering support throughout the receive side is completely capable of
providing those services without a tty structure, and to anything which
can have a tty attached.

Doesn't solve transmit or configuration but it's one step that needs no
additional real work and re-invention.

Alan

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

[One Thousand Gnomes]

> A single one is already difficult... And some scenarios need to shield the 
> UART
> from user space (currently there is always one /dev/tty per UART - unless the
> UART is completely disabled).

That bit is already covered and one or two devices support this because
they have things like 3 serial ports but one cannot be used if some other
feature is enabled.

You simply keep a private counter and return -EBUSY in the
port->activate() method if needed. That is sufficient to share a UART with
the tty layer when you have a contended resource, but not to borrow the
UART and re-use the stack which is what is needed in this case.

(You can even steal a UART this way by doing a hangup on it and then once
it drops out of use taking it over and ensuring the EBUSY behaviour)

> 
> Some ideas where it might be needed:
> * bluetooth HCI over UART
> * a weird GPS device whose power state can only reliably be detected by 
> monitoring data activity
> * other chips (microcontrollers) connected through UART - similar to I2C 
> slave devices
> * it potentially could help to better implement IrDA (although that is mostly 
> legacy)
> 
> 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. A current PC class device will usually have
bluetooth connected via a UART where both components are on board. The
same for GPS (or more accurately location services as it's usually more
than just a GPS nowdays). There may also be onboard WWAN modems and other
widgets wired this way.

In the PC case the power relationship and connectivity is usually
described via ACPI and that often means the kernel simply doesn't know
how to manage the power states besides telling the modem, GPS. etc to
turn itself on and off via normal ACPI power descriptions. Those may well
call OpRegion handlers so it's all abstracted nicely and generic, but
rather more invisible to the OS than DT describing pmic and/or gpio
setings for the device.

Todays low end Intel x86 PC has multiple DMA accelerated low power 16x50
compatible UARTS on die along with multiple channels of I2C and SPI.
Things like Android and PC tablet devices with sensors have pretty much
converged the old divide between a desktop/laptop/tablet PC and an
'embedded' board.

Alan

Hello Dear

[Catherine Wormer]

My name is Sgt Catherine from United States. I'm a woman seeking for true  
friendship and partner, please if you don't mind I will like you to respond to 
my
 mail so I can send you my photo and details about me,

 Sgt Catherine Wormer

Re: [RFC PATCH 1/5] Add generation of Module.symb in streamline_config

[Cristina-Gabriela Moraru]

2016-08-20 15:59 GMT+02:00 Cristina-Gabriela Moraru
:
>
>
> 2016-08-18 20:22 GMT+02:00 Luis R. Rodriguez :
>>
>> On Wed, Aug 17, 2016 at 09:26:59PM +0200, Cristina Moraru wrote:
>> > Add generation of ./scripts/Module.ksymb file containing
>> > associations of driver file names and corresponding CONFIG_*
>> > symbol:
>> >
>> > foo_KCONF=CONFIG_FOO
>> >
>> > This file will be further loaded by the Makefile as a
>> > configuration file: all foo_KCONF will be considered variables
>> > and all CONFIG_FOO will be their associate values.
>>
>> Will the file generated always work? What are the current
>> restrictions on kconfig variable names?
>>
>
> The file generated will always work. It's loaded with makefile's "include"
> directive which is quite straightforward.
>
> If you're referring to  CONFIG_* variables, I can't find any restriction
> regarding size or anything else.
> If you're referring to the newly created makefile variable foo_KCONF I only
> found this in the documentation:
> "A variable name may be any sequence of characters not containing ‘:’, ‘#’,
> ‘=’, or whitespace."
> "It is traditional to use upper case letters in variable names, but we
> recommend using lower case letters for variable names that serve internal
> purposes in the makefile, and reserving upper case for parameters that
> control implicit rules or for parameters that the user should override with
> command options"
>
> Since the module name is lowercase I put the suffix uppercase in order to be
> more visible.
>
>>
>> > The suffix
>> > is added to be able to differentiate the new variables from
>> > all existing variables in the Makefile system. Each kernel
>> > module will receive its CONFIG_FOO option as macro in the
>> > compilation command (-D parameter) and will expose it along
>> > with other module attributes (attributes of struct module).
>>
>> This is done later so this description does not belong here.
>> You want to describe what this patch does alone, if it has
>> potential for the future just mention basics, and that will will
>> be done later.
>>
>> > Note: this patch is built on the assumption that each driver
>> > has exactly one associate CONFIG_FOO symbol.
>>
>> This should note be a note, it should be an important aspect of
>> your changes -- you should try to describe when a direct mapping
>> is possible and when it is not.
>>
>> > CONFIG_* options
>> > that are required by CONFIG_FOO are not included. They can be
>> > found by SAT resolvers.
>>
>> You can leave this out.
>>
>> > This patch is part of a research project within
>> > Google Summer of Code of porting 'make localmodconfig'
>> > for backported drivers. The goal is to enable each
>> > module to expose in /sys its corresponding CONFIG_* option.
>> > The value of this attribute will be dynamically pegged by
>> > modpost without requiring extra work from the driver developers.
>> > Further, this information will be used by a hardware interogation
>> > tool to extract build information about the existing devices.
>>
>> You can leave this out.
>>
>> >
>> > Signed-off-by: Cristina Moraru 
>> > ---
>> >  scripts/kconfig/streamline_config.pl | 30
>> > +-
>> >  1 file changed, 29 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/scripts/kconfig/streamline_config.pl
>> > b/scripts/kconfig/streamline_config.pl
>> > index b8c7b29..686d02a 100755
>> > --- a/scripts/kconfig/streamline_config.pl
>> > +++ b/scripts/kconfig/streamline_config.pl
>> > @@ -128,9 +128,11 @@ my @config_file = read_config;
>> >  # Parse options
>> >  my $localmodconfig = 0;
>> >  my $localyesconfig = 0;
>> > +my $genmoduleksymb = 0;
>> >
>> >  GetOptions("localmodconfig" => \$localmodconfig,
>> > -"localyesconfig" => \$localyesconfig);
>> > +"localyesconfig" => \$localyesconfig,
>> > +"genmoduleksymb" => \$genmoduleksymb);
>> >
>> >  # Get the build source and top level Kconfig file (passed in)
>> >  my $ksource = ($ARGV[0] ? $ARGV[0] : '.');
>> > @@ -147,6 +149,7 @@ my %objects;
>> >  my $var;
>> >  my $iflevel = 0;
>> >  my @ifdeps;
>> > +my @drv_objs;
>> >
>> >  # prevent recursion
>> >  my %read_kconfigs;
>> > @@ -348,6 +351,31 @@ foreach my $makefile (@makefiles) {
>> >  close($infile);
>> >  }
>> >
>> > +foreach my $obj_key ( keys %objects )
>> > +{
>> > + my @config_options = @{$objects{$obj_key}};
>> > + # Last index of array is 0 is equivalent to array's size is 1
>> > + if ( $#config_options == 0) {
>> > + push(@drv_objs, $obj_key);
>> > + }
>> > +}
>> > +
>> > +sub gen_module_kconfigs {
>> > + my $module_ksymb = $ENV{'srctree'}."/scripts/Module.ksymb";
>> > +
>> > + open(my $ksymbfile, '>', $module_ksymb) || die "Can not open
>> > $module_ksymb for writing";
>> > +
>> > + foreach (@drv_objs) {
>> > + print $ksymbfile "$_" . "_KCONF=" . "@{$objects{$_}}\n";
>> > + }
>> > + close($ksymbfile);
>> > +}
>> > +
>> > +if ($genmoduleksymb) {
>> > + gen_module_kconf

Re: [RFC PATCH 2/5] Add CONFIG symbol to module as compilation parameter

[Cristina-Gabriela Moraru]

2016-08-18 20:10 GMT+02:00 Luis R. Rodriguez :
> On Wed, Aug 17, 2016 at 09:27:00PM +0200, Cristina Moraru wrote:
>> Add  CONFIG symbol to kernel modules as a define via -D
>
> Perhaps better worded as:
>
> When modules have a direct Kconfig CONFIG_ symbol associated with
> we want to be able to make it available to the build system when we
> are building the module.
>
> You can then describe you do this with -D.
>
>> compilation parameter. The CONFIG_FOO symbol for each
>> module is determined by the module name, using the
>> associations from Module.ksymb. This file is loaded
>> using the 'include' directive, thus run like a regular
>> makefile. The format of the content of the file is the
>> following:
>>
>> foo_KCONF=CONFIG_FOO
>>
>> creating a set of Makefile variables foo_KCONF with the
>> CONFIG_FOO as values.
>>
>> The Makefile then adds this value in the compilation
>> command with -DKBUILD_KCONF='"CONFIG_FOO"'.
>
> Very nice. What would it mean if it lacks this ?
> This should be explained on the commit log.
>

If we lack it then KBUILD_KCONF="" and in /sys the module has the
kconfig_symbol attribute but with the empty string as content:

prompt:/sys$ cat ./module/mptbase/kconfig_symbol

prompt:/sys$

I will add it into the commit log.

>> This patch is part of a research project within
>> Google Summer of Code of porting 'make localmodconfig'
>> for backported drivers. The goal is to enable each
>> module to expose in /sys its corresponding CONFIG_* option.
>> The value of this attribute will be dynamically pegged by
>> modpost without requiring extra work from the driver developers.
>> Further, this information will be used by a hardware interogation
>> tool to extract build information about the existing devices.
>
> You can leave this out as its part of the cover letter and
> not relevant to the patch. You can however mention you will
> use this later to make the define more useful in userspace.
>
>> Signed-off-by: Cristina Moraru 
>> ---
>>  scripts/Makefile.lib | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>> index e7df0f5..8ae9b7f 100644
>> --- a/scripts/Makefile.lib
>> +++ b/scripts/Makefile.lib
>> @@ -89,6 +89,10 @@ multi-objs-m   := $(addprefix $(obj)/,$(multi-objs-m))
>>  subdir-ym:= $(addprefix $(obj)/,$(subdir-ym))
>>  obj-dirs := $(addprefix $(obj)/,$(obj-dirs))
>>
>> +# Include Module.ksymb which contains the associations of modules' names
>> +# and corresponding CONFIG_* options
>> +include Module.ksymb
>
> Is this file always generated? If not prefixing the include call with - would
> be better. If we are going to make this optional, then an ifdef wrapper would
> suffice as we know it'd be expected only if the new feature was enabled.

Yes. This file is always generated. In case a 'git pull' happened
between two 'make' commands, the associations should be updated. Ok. I
will add a ifdef.

>
>> +
>>  # These flags are needed for modversions and compiling, so we define them 
>> here
>>  # already
>>  # $(modname_flags) #defines KBUILD_MODNAME as the name of the module it will
>> @@ -100,6 +104,9 @@ name-fix = $(squote)$(quote)$(subst $(comma),_,$(subst 
>> -,_,$1))$(quote)$(squote)
>>  basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget))
>>  modname_flags  = $(if $(filter 1,$(words $(modname))),\
>>   -DKBUILD_MODNAME=$(call name-fix,$(modname)))
>> +ksym-fix = $(squote)$(quote)$($(subst $(comma),_,$(subst 
>> -,_,$1))_KCONF)$(quote)$(squote)
>> +ksymb_flags = $(if $(filter 1,$(words $(modname))),\
>> + -DKBUILD_KSYMB=$(call ksym-fix, $(modname)))
>
> Are clashes possible with this formula? Can we end up with two results for 
> instance?
> If not what prevents current konfig logic and namespace from a clash ? If we 
> do
> not have anything to prevent a clash, what can we do to help make such clash 
> not
> possible ?

I think the fact that modname is unique prevents from having clashes.
KBUILD_KSYMB is found according to modname.
Currently there is no clash because I enforced the Module.ksymb to
have 1-to-1 mapping.
The only potential clash I can imagine right now it having the same
module name but architecture specific CONFIG_* symbol. If there is a
1-to-1 mapping in Module.ksymb there should be no clash in the
makefile.

>
>>  orig_c_flags   = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) 
>> $(KBUILD_SUBDIR_CCFLAGS) \
>>   $(ccflags-y) $(CFLAGS_$(basetarget).o)
>> @@ -162,7 +169,7 @@ endif
>>
>>  c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
>>$(__c_flags) $(modkern_cflags)   \
>> -  $(basename_flags) $(modname_flags)
>> +  $(basename_flags) $(modname_flags) $(ksymb_flags)
>>
>>  a_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
>>$(__a_flags) $(modkern_aflags)
>> --
>
> Other than that looks good!
>
>

Re: [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb module attribute

[Cristina-Gabriela Moraru]

2016-08-18 20:59 GMT+02:00 Luis R. Rodriguez :
>
> On Wed, Aug 17, 2016 at 09:27:02PM +0200, Cristina Moraru wrote:
> > Update modpost to add in *.mod.c files generated for each
> > module the setting of module attribute kernel_ksymb to
> > value given by KBUILD_KSYMB macro.
>
> Please review your patches and update subjects to match what other
> types of previous patches look like in terms of format, so
> for this patch check changes to scripts/mod/modpost.c and use
> similar type of patch prefix.
>

OK

>
> >
> > This patch is part of a research project within
> > Google Summer of Code of porting 'make localmodconfig'
> > for backported drivers. The goal is to enable each
> > module to expose in /sys its corresponding CONFIG_* option.
> > The value of this attribute will be dynamically pegged by
> > modpost without requiring extra work from the driver developers.
> > Further, this information will be used by a hardware interogation
> > tool to extract build information about the existing devices.
>
> You can leave this out.
>
> > Signed-off-by: Cristina Moraru 
> > ---
> >  scripts/mod/modpost.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> > index 48958d3..a105916 100644
> > --- a/scripts/mod/modpost.c
> > +++ b/scripts/mod/modpost.c
> > @@ -2245,6 +2245,12 @@ static void add_srcversion(struct buffer *b, struct 
> > module *mod)
> >   }
> >  }
> >
> > +static void add_kconfig_symbol(struct buffer *b, struct module *mod)
> > +{
> > + buf_printf(b, "\n");
> > + buf_printf(b, "MODULE_INFO(kconfig_symbol, KBUILD_KSYMB);\n");
>
> What if its not available? What happens?
>

If not available KBUILD_KSYMB is "" and so is set in kconfig_symbol.
More concrete:

prompt:/sys$ cat ./module/mptbase/kconfig_symbol

prompt:/sys$

>
> > +}
> > +
> >  static void write_if_changed(struct buffer *b, const char *fname)
> >  {
> >   char *tmp;
> > @@ -2478,6 +2484,7 @@ int main(int argc, char **argv)
> >   add_depends(&buf, mod, modules);
> >   add_moddevtable(&buf, mod);
> >   add_srcversion(&buf, mod);
> > + add_kconfig_symbol(&buf, mod);
> >
> >   sprintf(fname, "%s.mod.c", mod->name);
> >   write_if_changed(&buf, fname);
> > --
> > 2.7.4
> >
> >
>
> --
> Luis Rodriguez, SUSE LINUX GmbH
> Maxfeldstrasse 5; D-90409 Nuernberg

[PATCH] Staging: wlan-ng: improved code in p80211req.c file

[Claudiu Beznea]

This patch improves code from p80211req.c file by removing
duplicate code, by keeping count of returning code of
the called functions and also aesthetically.

Signed-off-by: Claudiu Beznea 
---
 drivers/staging/wlan-ng/p80211req.c | 163 +++-
 1 file changed, 84 insertions(+), 79 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211req.c 
b/drivers/staging/wlan-ng/p80211req.c
index 4b84b56..900635e 100644
--- a/drivers/staging/wlan-ng/p80211req.c
+++ b/drivers/staging/wlan-ng/p80211req.c
@@ -72,10 +72,12 @@
 #include "p80211metastruct.h"
 #include "p80211req.h"
 
-static void p80211req_handlemsg(wlandevice_t *wlandev, struct p80211msg *msg);
-static void p80211req_mibset_mibget(wlandevice_t *wlandev,
+static int p80211req_handlemsg(wlandevice_t *wlandev, struct p80211msg *msg);
+static int p80211req_mibset_mibget(wlandevice_t *wlandev,
   struct p80211msg_dot11req_mibget *mib_msg,
   int isget);
+static void p80211req_handle_action(struct wlandevice *wlandev, u32 *data,
+   int isget, u32 flag);
 
 /*
 * p80211req_dorequest
@@ -96,6 +98,7 @@ static void p80211req_mibset_mibget(wlandevice_t *wlandev,
 int p80211req_dorequest(wlandevice_t *wlandev, u8 *msgbuf)
 {
struct p80211msg *msg = (struct p80211msg *) msgbuf;
+   int rc = 0;
 
/* Check to make sure the MSD is running */
if (!((wlandev->msdstate == WLAN_MSD_HWPRESENT &&
@@ -107,7 +110,7 @@ int p80211req_dorequest(wlandevice_t *wlandev, u8 *msgbuf)
 
/* Check Permissions */
if (!capable(CAP_NET_ADMIN) &&
-   (msg->msgcode != DIDmsg_dot11req_mibget)) {
+   (msg->msgcode != DIDmsg_dot11req_mibget)) {
netdev_err(wlandev->netdev,
   "%s: only dot11req_mibget allowed for non-root.\n",
   wlandev->name);
@@ -115,20 +118,23 @@ int p80211req_dorequest(wlandevice_t *wlandev, u8 *msgbuf)
}
 
/* Check for busy status */
-   if (test_and_set_bit(1, &(wlandev->request_pending)))
+   if (test_and_set_bit(1, &wlandev->request_pending))
return -EBUSY;
 
/* Allow p80211 to look at msg and handle if desired. */
/* So far, all p80211 msgs are immediate, no waitq/timer necessary */
/* This may change. */
-   p80211req_handlemsg(wlandev, msg);
+   rc = p80211req_handlemsg(wlandev, msg);
+   if (rc != 0)
+   goto exit;
 
/* Pass it down to wlandev via wlandev->mlmerequest */
if (wlandev->mlmerequest != NULL)
-   wlandev->mlmerequest(wlandev, msg);
+   rc = wlandev->mlmerequest(wlandev, msg);
 
-   clear_bit(1, &(wlandev->request_pending));
-   return 0;   /* if result==0, msg->status still may contain an err */
+exit:
+   clear_bit(1, &wlandev->request_pending);
+   return rc;  /* if result==0, msg->status still may contain an err */
 }
 
 /*
@@ -149,64 +155,63 @@ int p80211req_dorequest(wlandevice_t *wlandev, u8 *msgbuf)
 * Call context:
 *  Process thread
 */
-static void p80211req_handlemsg(wlandevice_t *wlandev, struct p80211msg *msg)
+static int p80211req_handlemsg(wlandevice_t *wlandev, struct p80211msg *msg)
 {
-   switch (msg->msgcode) {
+   struct p80211msg_lnxreq_hostwep *req;
+   struct p80211msg_dot11req_mibget *mib_msg;
+   int isget;
+   int rc = 0;
 
-   case DIDmsg_lnxreq_hostwep:{
-   struct p80211msg_lnxreq_hostwep *req =
-   (struct p80211msg_lnxreq_hostwep *) msg;
-   wlandev->hostwep &=
-   ~(HOSTWEP_DECRYPT | HOSTWEP_ENCRYPT);
+   switch (msg->msgcode) {
+   case DIDmsg_lnxreq_hostwep:
+   req = (struct p80211msg_lnxreq_hostwep *)msg;
+   wlandev->hostwep &= ~(HOSTWEP_DECRYPT | HOSTWEP_ENCRYPT);
if (req->decrypt.data == P80211ENUM_truth_true)
wlandev->hostwep |= HOSTWEP_DECRYPT;
if (req->encrypt.data == P80211ENUM_truth_true)
wlandev->hostwep |= HOSTWEP_ENCRYPT;
 
-   break;
-   }
+   break;
+
case DIDmsg_dot11req_mibget:
-   case DIDmsg_dot11req_mibset:{
-   int isget = (msg->msgcode == DIDmsg_dot11req_mibget);
-   struct p80211msg_dot11req_mibget *mib_msg =
-   (struct p80211msg_dot11req_mibget *) msg;
-   p80211req_mibset_mibget(wlandev, mib_msg, isget);
-   break;
+   case DIDmsg_dot11req_mibset:
+   isget = (msg->msgcode == DIDmsg_dot11req_mibget);
+   mib_msg = (struct p80211msg_dot11req_mibget *)msg;
+   rc = p80211req_mibset_

[PATCH -next] irqchip/irq-jcore-aic: fix non static symbol warning

[Wei Yongjun]

Fixes the following sparse warning:

drivers/irqchip/irq-jcore-aic.c:47:12: warning:
 symbol 'aic_irq_of_init' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/irqchip/irq-jcore-aic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
index 5e5e3bb..84b01de 100644
--- a/drivers/irqchip/irq-jcore-aic.c
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -44,7 +44,8 @@ static void noop(struct irq_data *data)
 {
 }
 
-int __init aic_irq_of_init(struct device_node *node, struct device_node 
*parent)
+static int __init aic_irq_of_init(struct device_node *node,
+ struct device_node *parent)
 {
unsigned min_irq = JCORE_AIC2_MIN_HWIRQ;
unsigned dom_sz = JCORE_AIC_MAX_HWIRQ+1;

Re: [PATCH v2 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

[Krzysztof Kozlowski]

On Sat, Aug 20, 2016 at 03:08:01AM +0200, Rafael J. Wysocki wrote:
> On Friday, August 19, 2016 03:26:21 PM Krzysztof Kozlowski wrote:
> > On Fri, Aug 12, 2016 at 2:04 AM, Rafael J. Wysocki  
> > wrote:
> > > From: Rafael J. Wysocki 
> > >
> > > It is useful to know the reason why cpufreq_update_util() has just
> > > been called and that can be passed as flags to cpufreq_update_util()
> > > and to the ->func() callback in struct update_util_data.  However,
> > > doing that in addition to passing the util and max arguments they
> > > already take would be clumsy, so avoid it.
> > >
> > > Instead, use the observation that the schedutil governor is part
> > > of the scheduler proper, so it can access scheduler data directly.
> > > This allows the util and max arguments of cpufreq_update_util()
> > > and the ->func() callback in struct update_util_data to be replaced
> > > with a flags one, but schedutil has to be modified to follow.
> > >
> > > Thus make the schedutil governor obtain the CFS utilization
> > > information from the scheduler and use the "RT" and "DL" flags
> > > instead of the special utilization value of ULONG_MAX to track
> > > updates from the RT and DL sched classes.  Make it non-modular
> > > too to avoid having to export scheduler variables to modules at
> > > large.
> > >
> > > Next, update all of the other users of cpufreq_update_util()
> > > and the ->func() callback in struct update_util_data accordingly.
> > >
> > > Suggested-by: Peter Zijlstra 
> > > Signed-off-by: Rafael J. Wysocki 
> > > ---
> > >
> > > v1 -> v2: Do not check cpu_of(rq) against smp_processor_id() in
> > >   cfs_rq_util_change().
> > >
> > > ---
> > >  drivers/cpufreq/Kconfig|5 --
> > >  drivers/cpufreq/cpufreq_governor.c |2 -
> > >  drivers/cpufreq/intel_pstate.c |2 -
> > >  include/linux/sched.h  |   12 --
> > >  kernel/sched/cpufreq.c |2 -
> > >  kernel/sched/cpufreq_schedutil.c   |   67 
> > > -
> > >  kernel/sched/deadline.c|4 +-
> > >  kernel/sched/fair.c|   10 +
> > >  kernel/sched/rt.c  |4 +-
> > >  kernel/sched/sched.h   |   31 +
> > >  10 files changed, 66 insertions(+), 73 deletions(-)
> > 
> > (...)
> > 
> > > --- linux-pm.orig/drivers/cpufreq/Kconfig
> > > +++ linux-pm/drivers/cpufreq/Kconfig
> > > @@ -194,7 +194,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
> > >   If in doubt, say N.
> > >
> > >  config CPU_FREQ_GOV_SCHEDUTIL
> > > -   tristate "'schedutil' cpufreq policy governor"
> > > +   bool "'schedutil' cpufreq policy governor"
> > 
> > If you change such symbols please remember to update also all the
> > defconfigs. Without the update they start to show errors.
> 
> Are there defconfigs that use this particular one?

Yes, ARM/multi_v7 and exynos were using this as module. Javier sent a
patch for that and should be switched to builtin in upcoming next [1].

If you would like to base on top of that, let me know, so I would
prepare a tag.

Best regards,
Krzysztof

[1] 
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/commit/?h=for-v4.9/defconfig-cpufreq-schedutil-builtin&id=08023fb9cec03ee2992df51fa728c3f14a1ba0ea

Greetings Urgent

[Lehman]

>From  Mrs Esther G Mahmood
I need your urgent assistance in transferring MY LATE HUSBEND ($(6.5)million
into your  account for investment in your country if you are ready to assit
me, plesae get back to me i will give you full details on how the money will
be transfer to you for investment in your country,
(1.) your Name:on how
(2.) Country:
(3.)Phone Nb:
(4.)your passport:
(5.)your Occupation:
(6.)Your Age:
,I will send you my photo  as soon as I hear from you.Contact Me via E-mail :(
mrsdelo...@gmail.com )
Yours sincerely,
Best Regards,
Mrs Esther G Mahmood

Re: [Documentation] State of CPU controller in cgroup v2

[Tejun Heo]

Hello, Andy.

On Wed, Aug 17, 2016 at 01:18:24PM -0700, Andy Lutomirski wrote:
> >   2-1-1. Process Granularity
> >
> >   For memory, because an address space is shared between all threads
> >   of a process, the terminal consumer is a process, not a thread.
> >   Separating the threads of a single process into different memory
> >   control domains doesn't make semantical sense.  cgroup v2 ensures
> >   that all controller can agree on the same organization by requiring
> >   that threads of the same process belong to the same cgroup.
> 
> I haven't followed all of the history here, but it seems to me that
> this argument is less accurate than it appears.  Linux, for better or
> for worse, has somewhat orthogonal concepts of thread groups
> (processes), mms, and file tables.  An mm has VMAs in it, and VMAs can
> reference things (files, etc) that hold resources.  (Two mms can share
> resources by mapping the same thing or using fork().)  File tables
> hold files, and files can use resources.  Both of these are, at best,
> moderately good approximations of what actually holds resources.
> Meanwhile, threads (tasks) do syscalls, take page faults, *allocate*
> resources, etc.
> 
> So I think it's not really true to say that the "terminal consumer" of
> anything is a process, not a thread.

The terminal consumer is actually the mm context.  A task may be the
allocating entity but not always for itself.

This becomes clear whenever an entity is allocating memory on behalf
of someone else - get_user_pages(), khugepaged, swapoff and so on (and
likely userfaultfd too).  When a task is trying to add a page to a
VMA, the task might not have any relationship with the VMA other than
that it's operating on it for someone else.  The page has to be
charged to whoever is responsible for the VMA and the only ownership
which can be established is the containing mm_struct.

While a mm_struct technically may not map to a process, it is a very
close approxmiation which is hardly ever broken in practice.

> While it's certainly easier to think about assigning processes to
> cgroups, and I certainly agree that, in the common case, it's the
> right thing to do, I don't see why requiring it is a good idea.  Can
> we turn this around: what actually goes wrong if cgroup v2 were to
> allow assigning individual threads if a user specifically requests it?

Consider the scenario where you have somebody faulting on behalf of a
foreign VMA, but the thread who created and is actively using that VMA
is in a different cgroup than the process leader.  Who are we going to
charge?  All possible answers seem erratic.

Please note that I agree that thread granularity can be useful for
some resources; however, my points are 1. it should be scoped so that
the resource distribution tree as a whole can be shared across
different resources, and, 2. cgroup filesystem interface isn't a good
interface for the purpose.  I'll continue the second point below.

> >   there are other reasons to enforce process granularity.  One
> >   important one is isolating system-level management operations from
> >   in-process application operations.  The cgroup interface, being a
> >   virtual filesystem, is very unfit for multiple independent
> >   operations taking place at the same time as most operations have to
> >   be multi-step and there is no way to synchronize multiple accessors.
> >   See also [5] Documentation/cgroup-v2.txt, "R-2. Thread Granularity"
> 
> I don't buy this argument at all.  System-level code is likely to
> assign single process *trees*, which are a different beast entirely.
> I.e. you fork, move the child into a cgroup, and that child and its
> children stay in that cgroup.  I don't see how the thread/process
> distinction matters.

Good point on the multi-process issue, this is something which nagged
me a bit while working on rgroup, although I have to point out that
the issue here is one of not going far enough rather than the approach
being wrong.  There are limitations to scoping it to individual
processes but that doesn't negate the underlying problem or the
usefulness of in-process control.

For system-level and process-level operations to not step on each
other's toes, they need to agree on the granularity boundary -
system-level should be able to treat an application hierarchy as a
single unit.  A possible solution is allowing rgroup hirearchies to
span across process boundaries and implementing cgroup migration
operations which treat such hierarchies as a single unit.  I'm not yet
sure whether the boundary should be at program groups or rgroups.

> On the contrary: with cgroup namespaces, one could easily create a
> cgroup namespace, shove a process in it, and let that process delegate
> its threads to child cgroups however it likes.  (Well, children of the
> namespace root.)

cgroup namespace solves just one piece of the whole problem and not in
a very robust way.  It's okay for containers but not so for individual
applications.

Re: [RFC 00/17] clk: Add per-controller locks to fix deadlocks

[Krzysztof Kozlowski]

On Fri, Aug 19, 2016 at 03:31:08PM -0400, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 08/16/2016 09:34 AM, Krzysztof Kozlowski wrote:
> > Hi,
> > 
> > RFC, please, do not apply, maybe except patch #1 which is harmless.
> > 
> > 
> > Introduction
> > 
> > The patchset brings new entity: clock controller representing a hardware
> > block.  The clock controller comes with its own prepare lock which
> > is used then in many places.  The idea is to fix the deadlock mentioned
> > in commit 10ff4c5239a1 ("i2c: exynos5: Fix possible ABBA deadlock by keeping
> > I2C clock prepared") and commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA 
> > deadlock
> > by keeping clock prepared").
> > 
> > 
> 
> I'm not familiar enough with the common clock framework to do a proper review
> of this patch-set, but I've tested both on an Exynos5800 Peach Pi Chromebook
> and an Exynos5422 Odroid XU4 board and I didn't find any clock regressions.
> 
> Also, I confirmed that the possible deadlock in the Odroid XU4 that was fixed
> by reverted commit 10ff4c5239a1 doesn't happen anymore with your patches.
> 
> Tested-by: Javier Martinez Canillas 

Thanks for testing, I appreciate that!

Best regards,
Krzysztof

[PATCH] hw_random: omap3-rom-rng.c: Remove obsoleted functions

[PrasannaKumar Muralidharan]

Remove omap3_rom_rng_data_present method as it was returning 1 always.
Use .read callback instead of .data_read callback. This avoids use of
obsolete callbacks.

This patch is not tested with hardware as I don't have access to it.

Signed-off-by: PrasannaKumar Muralidharan 
---
 drivers/char/hw_random/omap3-rom-rng.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/char/hw_random/omap3-rom-rng.c 
b/drivers/char/hw_random/omap3-rom-rng.c
index 8da14f1..37a58d7 100644
--- a/drivers/char/hw_random/omap3-rom-rng.c
+++ b/drivers/char/hw_random/omap3-rom-rng.c
@@ -71,12 +71,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
return 0;
 }
 
-static int omap3_rom_rng_data_present(struct hwrng *rng, int wait)
-{
-   return 1;
-}
-
-static int omap3_rom_rng_data_read(struct hwrng *rng, u32 *data)
+static int omap3_rom_rng_read(struct hwrng *rng, void *data, size_t max, bool 
w)
 {
int r;
 
@@ -88,8 +83,7 @@ static int omap3_rom_rng_data_read(struct hwrng *rng, u32 
*data)
 
 static struct hwrng omap3_rom_rng_ops = {
.name   = "omap3-rom",
-   .data_present   = omap3_rom_rng_data_present,
-   .data_read  = omap3_rom_rng_data_read,
+   .read   = omap3_rom_rng_read,
 };
 
 static int omap3_rom_rng_probe(struct platform_device *pdev)
-- 
2.5.0

Re: Linux 3.14.77

[Greg KH]

diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt
index 2b40e04d3c49..f18b6ef7f805 100644
--- a/Documentation/module-signing.txt
+++ b/Documentation/module-signing.txt
@@ -238,3 +238,9 @@ Since the private key is used to sign modules, viruses and 
malware could use
 the private key to sign modules and compromise the operating system.  The
 private key must be either destroyed or moved to a secure location and not kept
 in the root node of the kernel source tree.
+
+If you use the same private key to sign modules for multiple kernel
+configurations, you must ensure that the module version information is
+sufficient to prevent loading a module into a different kernel.  Either
+set CONFIG_MODVERSIONS=y or ensure that each configuration has a different
+kernel release string by changing EXTRAVERSION or CONFIG_LOCALVERSION.
diff --git a/Makefile b/Makefile
index 306fd306906b..fc4df99727c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 76
+SUBLEVEL = 77
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/arm/include/asm/pgtable-3level.h 
b/arch/arm/include/asm/pgtable-3level.h
index ab7ee9205ca4..40d60a679fc8 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -243,8 +243,11 @@ PMD_BIT_FUNC(mkyoung,   |= PMD_SECT_AF);
 #define pfn_pmd(pfn,prot)  (__pmd(((phys_addr_t)(pfn) << PAGE_SHIFT) | 
pgprot_val(prot)))
 #define mk_pmd(page,prot)  pfn_pmd(page_to_pfn(page),prot)
 
-/* represent a notpresent pmd by zero, this is used by pmdp_invalidate */
-#define pmd_mknotpresent(pmd)  (__pmd(0))
+/* represent a notpresent pmd by faulting entry, this is used by 
pmdp_invalidate */
+static inline pmd_t pmd_mknotpresent(pmd_t pmd)
+{
+   return __pmd(pmd_val(pmd) & ~L_PMD_SECT_VALID);
+}
 
 static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
 {
diff --git a/arch/metag/include/asm/cmpxchg_lnkget.h 
b/arch/metag/include/asm/cmpxchg_lnkget.h
index 0154e2807ebb..2369ad394876 100644
--- a/arch/metag/include/asm/cmpxchg_lnkget.h
+++ b/arch/metag/include/asm/cmpxchg_lnkget.h
@@ -73,7 +73,7 @@ static inline unsigned long __cmpxchg_u32(volatile int *m, 
unsigned long old,
  " DCACHE  [%2], %0\n"
 #endif
  "2:\n"
- : "=&d" (temp), "=&da" (retval)
+ : "=&d" (temp), "=&d" (retval)
  : "da" (m), "bd" (old), "da" (new)
  : "cc"
  );
diff --git a/arch/mips/kvm/kvm_mips_emul.c b/arch/mips/kvm/kvm_mips_emul.c
index 33085819cd89..9f7643874fba 100644
--- a/arch/mips/kvm/kvm_mips_emul.c
+++ b/arch/mips/kvm/kvm_mips_emul.c
@@ -972,8 +972,13 @@ kvm_mips_emulate_cache(uint32_t inst, uint32_t *opc, 
uint32_t cause,
preempt_disable();
if (KVM_GUEST_KSEGX(va) == KVM_GUEST_KSEG0) {
 
-   if (kvm_mips_host_tlb_lookup(vcpu, va) < 0) {
-   kvm_mips_handle_kseg0_tlb_fault(va, vcpu);
+   if (kvm_mips_host_tlb_lookup(vcpu, va) < 0 &&
+   kvm_mips_handle_kseg0_tlb_fault(va, vcpu)) {
+   kvm_err("%s: handling mapped kseg0 tlb fault for %lx, 
vcpu: %p, ASID: %#lx\n",
+   __func__, va, vcpu, read_c0_entryhi());
+   er = EMULATE_FAIL;
+   preempt_enable();
+   goto done;
}
} else if ((KVM_GUEST_KSEGX(va) < KVM_GUEST_KSEG0) ||
   KVM_GUEST_KSEGX(va) == KVM_GUEST_KSEG23) {
@@ -1006,11 +1011,16 @@ kvm_mips_emulate_cache(uint32_t inst, uint32_t *opc, 
uint32_t cause,
run, vcpu);
preempt_enable();
goto dont_update_pc;
-   } else {
-   /* We fault an entry from the guest tlb to the 
shadow host TLB */
-   kvm_mips_handle_mapped_seg_tlb_fault(vcpu, tlb,
-NULL,
-NULL);
+   }
+   /* We fault an entry from the guest tlb to the shadow 
host TLB */
+   if (kvm_mips_handle_mapped_seg_tlb_fault(vcpu, tlb,
+NULL, NULL)) {
+   kvm_err("%s: handling mapped seg tlb fault for 
%lx, index: %u, vcpu: %p, ASID: %#lx\n",
+   __func__, va, index, vcpu,
+   read_c0_entryhi());
+   er = EMULATE_FAIL;
+   preempt_enable();
+   goto done;
}
}
} else {
@@ -1821,8 +1831,13 @@ kvm_mips_handle_tlbmiss(un

Linux 3.14.77

[Greg KH]

I'm announcing the release of the 3.14.77 kernel.

All users of the 3.14 kernel series must upgrade.

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

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

thanks,

greg k-h



 Documentation/module-signing.txt |6 ++
 Makefile |2 
 arch/arm/include/asm/pgtable-3level.h|7 ++-
 arch/metag/include/asm/cmpxchg_lnkget.h  |2 
 arch/mips/kvm/kvm_mips_emul.c|   33 ++
 arch/mips/kvm/kvm_tlb.c  |   61 ++-
 drivers/char/random.c|   12 +++--
 drivers/gpio/gpio-intel-mid.c|   19 
 drivers/gpio/gpio-pca953x.c  |2 
 drivers/gpu/drm/i915/intel_display.c |   20 ++--
 drivers/gpu/drm/radeon/atombios_encoders.c   |1 
 drivers/gpu/drm/radeon/radeon_atombios.c |4 -
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |5 ++
 drivers/gpu/drm/radeon/radeon_connectors.c   |   15 +++---
 drivers/infiniband/hw/mlx4/qp.c  |2 
 drivers/infiniband/hw/mlx5/qp.c  |   21 +
 drivers/infiniband/ulp/ipoib/ipoib_main.c|4 +
 drivers/md/dm-flakey.c   |   23 ++
 drivers/media/platform/s5p-mfc/s5p_mfc.c |   11 
 drivers/mtd/ubi/build.c  |5 +-
 drivers/mtd/ubi/vmt.c|   25 +++
 drivers/pci/quirks.c |   10 ++--
 drivers/platform/x86/hp-wmi.c|7 ++-
 drivers/target/iscsi/iscsi_target.c  |   22 +++--
 drivers/target/target_core_device.c  |8 ++-
 drivers/target/target_core_file.c|3 -
 drivers/target/target_core_iblock.c  |3 -
 drivers/target/target_core_transport.c   |3 -
 drivers/usb/core/devio.c |9 ++-
 drivers/usb/renesas_usbhs/mod_gadget.c   |9 +++
 drivers/usb/serial/option.c  |3 +
 drivers/virtio/virtio_balloon.c  |2 
 fs/cifs/cifsencrypt.c|   16 ---
 fs/cifs/dir.c|   24 +-
 fs/cifs/smb2ops.c|   30 -
 fs/nfs/write.c   |5 +-
 include/linux/mlx5/qp.h  |5 +-
 include/target/target_core_backend.h |2 
 kernel/module.c  |   13 +++--
 net/bluetooth/l2cap_sock.c   |2 
 net/ipv4/tcp_input.c |6 +-
 net/ipv4/udp.c   |6 +-
 net/ipv6/udp.c   |6 +-
 net/netlabel/netlabel_kapi.c |   12 -
 scripts/recordmcount.c   |9 +++
 45 files changed, 337 insertions(+), 158 deletions(-)

Alex Deucher (3):
  drm/radeon: add a delay after ATPX dGPU power off
  drm/radeon: fix firmware info version checks
  drm/radeon: support backlight control for UNIPHY3

Alex Hung (1):
  hp-wmi: Fix wifi cannot be hard-unblocked

Amadeusz Sławiński (1):
  Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU

Andy Shevchenko (1):
  gpio: intel-mid: Remove potentially harmful code

Artemy Kovalyov (1):
  IB/mlx5: Fix MODIFY_QP command input structure

Ben Hutchings (2):
  module: Invalidate signatures on force-loaded modules
  Documentation/module-signing.txt: Note need for version info if reusing a 
key

Benjamin Coddington (1):
  nfs: don't create zero-length requests

Chris Blake (1):
  PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset

Daniele Palmas (1):
  USB: serial: option: add support for Telit LE910 PID 0x1206

Eli Cohen (1):
  IB/mlx5: Fix post send fence logic

Erez Shitrit (1):
  IB/IPoIB: Don't update neigh validity for unresolved entries

Eric Dumazet (1):
  udp: properly support MSG_PEEK with truncated buffers

Greg Kroah-Hartman (2):
  tcp: make challenge acks faster
  Linux 3.14.77

Iosif Harutyunov (1):
  ubi: Fix race condition between ubi device creation and udev

James Hogan (5):
  MIPS: KVM: Fix mapped fault broken commpage handling
  MIPS: KVM: Add missing gfn range check
  MIPS: KVM: Fix gfn range check in kseg0 tlb faults
  MIPS: KVM: Propagate kseg0/mapped tlb fault errors
  metag: Fix __cmpxchg_u32 asm constraint for CMP

Javier Martinez Canillas (2):
  s5p-mfc: Set device name for reserved memory region devs
  s5p-mfc: Add release callback for memory region devs

Kangjie Lu (1):
  USB: usbfs: fix potential infoleak in devio

Konstantin Neumoin (1):
  balloon: check the number of available pages in leak balloon

Laura Ab

Linux 4.4.19

[Greg KH]

I'm announcing the release of the 4.4.19 kernel.

All users of the 4.4 kernel series must upgrade.

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

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

thanks,

greg k-h



 Documentation/module-signing.txt |6 
 Makefile |2 
 arch/arc/include/asm/pgtable.h   |2 
 arch/arm/boot/dts/sun4i-a10-a1000.dts|1 
 arch/arm/boot/dts/sun4i-a10-hackberry.dts|1 
 arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts   |1 
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts |1 
 arch/arm64/boot/dts/rockchip/rk3368.dtsi |2 
 arch/arm64/include/asm/ptrace.h  |2 
 arch/arm64/kernel/asm-offsets.c  |1 
 arch/arm64/kernel/debug-monitors.c   |1 
 arch/arm64/kernel/entry.S|   15 
 arch/arm64/kernel/smp.c  |3 
 arch/arm64/mm/mmu.c  |8 
 arch/arm64/mm/proc.S |2 
 arch/metag/include/asm/cmpxchg_lnkget.h  |2 
 arch/mips/kernel/csrc-r4k.c  |4 
 arch/mips/kvm/emulate.c  |   40 +
 arch/mips/kvm/tlb.c  |   68 ++-
 arch/mips/loongson64/loongson-3/hpet.c   |   14 
 arch/mips/mm/uasm-mips.c |2 
 arch/powerpc/kvm/book3s_hv_rmhandlers.S  |  462 ---
 arch/x86/kvm/mtrr.c  |1 
 arch/x86/kvm/vmx.c   |   20 
 arch/x86/pci/intel_mid_pci.c |   12 
 block/bio.c  |   15 
 block/genhd.c|2 
 drivers/acpi/ec.c|   41 +-
 drivers/bluetooth/hci_intel.c|6 
 drivers/char/random.c|   29 -
 drivers/cpufreq/intel_pstate.c   |2 
 drivers/edac/edac_mc_sysfs.c |   20 
 drivers/gpio/gpio-intel-mid.c|   19 
 drivers/gpio/gpio-pca953x.c  |2 
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |   25 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c |5 
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c   |7 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |   16 
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c   |1 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c|1 
 drivers/gpu/drm/drm_cache.c  |1 
 drivers/gpu/drm/drm_edid.c   |8 
 drivers/gpu/drm/i915/intel_display.c |   20 
 drivers/gpu/drm/i915/intel_opregion.c|2 
 drivers/gpu/drm/i915/intel_pm.c  |3 
 drivers/gpu/drm/nouveau/nouveau_drm.c|   11 
 drivers/gpu/drm/nouveau/nv04_fbcon.c |4 
 drivers/gpu/drm/nouveau/nv50_fbcon.c |2 
 drivers/gpu/drm/nouveau/nvc0_fbcon.c |2 
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv30.c|4 
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv34.c|4 
 drivers/gpu/drm/radeon/atombios_encoders.c   |1 
 drivers/gpu/drm/radeon/radeon_atombios.c |4 
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |5 
 drivers/gpu/drm/radeon/radeon_connectors.c   |   15 
 drivers/hid/uhid.c   |   33 +
 drivers/hv/vmbus_drv.c   |3 
 drivers/i2c/busses/i2c-efm32.c   |2 
 drivers/infiniband/core/iwpm_util.c  |1 
 drivers/infiniband/core/sa_query.c   |2 
 drivers/infiniband/hw/mlx4/mad.c |   24 -
 drivers/infiniband/hw/mlx4/qp.c  |6 
 drivers/infiniband/hw/mlx5/cq.c  |   12 
 drivers/infiniband/hw/mlx5/main.c|5 
 drivers/infiniband/hw/mlx5/qp.c  |   21 -
 drivers/infiniband/ulp/ipoib/ipoib_main.c|4 
 drivers/input/mouse/elan_i2c_core.c  |   79 +++
 drivers/input/touchscreen/sur40.c|5 
 drivers/iommu/amd_iommu.c|   40 +
 drivers/iommu/exynos-iommu.c |1 
 drivers/iommu/intel-iommu.c  |2 
 drivers/md/dm-flakey.c   |   23 -
 drivers/md/dm.c  |   14 
 drivers/media/dvb-core/dvb_ringbuffer.c  |   74 +++
 drivers/media/platform/s5p-mfc/s5p_mfc.c |   11 
 drivers/media/rc/ir-rc5-decoder.c|2 
 drivers/media/usb/usbtv/usbtv-audio.c|5 
 drivers/media/v4l2-core/videobuf2-core.c |   10 
 drivers/media/v4l

Linux 4.7.2

[Greg KH]

I'm announcing the release of the 4.7.2 kernel.

All users of the 4.7 kernel series must upgrade.

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

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

thanks,

greg k-h



 Documentation/module-signing.txt|6 
 Makefile|2 
 arch/arc/include/asm/pgtable.h  |2 
 arch/arc/mm/dma.c   |3 
 arch/arm/boot/dts/arm-realview-pbx-a9.dts   |9 
 arch/arm/boot/dts/sun4i-a10-a1000.dts   |1 
 arch/arm/boot/dts/sun4i-a10-hackberry.dts   |1 
 arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts  |1 
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts|1 
 arch/arm/boot/dts/tegra124-jetson-tk1.dts   |4 
 arch/arm/configs/aspeed_g4_defconfig|2 
 arch/arm/configs/aspeed_g5_defconfig|2 
 arch/arm/mm/dma-mapping.c   |   62 +
 arch/arm64/Kconfig  |2 
 arch/arm64/boot/dts/rockchip/rk3368.dtsi|2 
 arch/arm64/kernel/debug-monitors.c  |1 
 arch/arm64/kernel/hibernate.c   |   82 +-
 arch/arm64/kernel/smp.c |   10 
 arch/arm64/kernel/vmlinux.lds.S |4 
 arch/arm64/kvm/hyp/sysreg-sr.c  |8 
 arch/arm64/kvm/inject_fault.c   |   12 
 arch/arm64/mm/mmu.c |8 
 arch/arm64/mm/proc.S|2 
 arch/metag/include/asm/cmpxchg_lnkget.h |2 
 arch/mips/kernel/cevt-r4k.c |7 
 arch/mips/kernel/csrc-r4k.c |4 
 arch/mips/kvm/emulate.c |   40 -
 arch/mips/kvm/tlb.c |   66 +
 arch/mips/loongson64/loongson-3/hpet.c  |   14 
 arch/mips/mm/uasm-mips.c|2 
 arch/powerpc/kernel/tm.S|3 
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |  462 ++--
 arch/s390/include/asm/pgtable.h |2 
 arch/s390/include/asm/tlbflush.h|3 
 arch/s390/mm/gmap.c |4 
 arch/s390/mm/pgtable.c  |2 
 arch/um/os-Linux/signal.c   |5 
 arch/unicore32/include/asm/mmu_context.h|2 
 arch/x86/events/intel/uncore_snbep.c|   10 
 arch/x86/kvm/mtrr.c |1 
 arch/x86/kvm/vmx.c  |   20 
 arch/x86/kvm/x86.c  |   45 -
 arch/x86/pci/intel_mid_pci.c|   12 
 block/bio.c |   15 
 block/genhd.c   |2 
 drivers/acpi/ec.c   |   41 -
 drivers/bcma/host_pci.c |1 
 drivers/block/floppy.c  |   21 
 drivers/bluetooth/ath3k.c   |2 
 drivers/bluetooth/btusb.c   |1 
 drivers/char/random.c   |   33 
 drivers/char/tpm/tpm_crb.c  |2 
 drivers/clk/rockchip/clk-rk3399.c   |2 
 drivers/cpufreq/intel_pstate.c  |2 
 drivers/edac/edac_mc_sysfs.c|   20 
 drivers/gpio/gpio-intel-mid.c   |   21 
 drivers/gpio/gpio-pca953x.c |2 
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c|   25 
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c|5 
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c  |7 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   16 
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c  |1 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |1 
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c|4 
 drivers/gpu/drm/drm_cache.c |1 
 drivers/gpu/drm/drm_dp_helper.c |2 
 drivers/gpu

Re: Memory (skb) leak in kernel 4.8-rc2

[Larry Finger]

On 08/20/2016 01:01 AM, Marcel Holtmann wrote:

Hi Larry,

I can not see a leak. Maybe Johan has an idea.


Marcel and Johan,

The hardware in question is an Intel device with USB ID 8087:07dc, which is part 
of an Intel Wireless 7260.


The kmemleak backtraces for the two kinds of leaks are:

unreferenced object 0x8801e182e000 (size 1024):
  comm "hardirq", pid 0, jiffies 4312467853 (age 61.716s)
  hex dump (first 32 bytes):
00 84 82 e1 01 88 ff ff 0e 04 01 10 20 00 20 00   . .
05 06 02 00 00 05 00 00 40 00 40 00 00 00 00 00  @.@.
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] __kmalloc_node_track_caller+0x178/0x270
[] __kmalloc_reserve.isra.35+0x31/0x90
[] __alloc_skb+0x7e/0x280
[] btusb_recv_intr+0x12b/0x170 [btusb]
[] btusb_intr_complete+0xc5/0x130 [btusb]
[] __usb_hcd_giveback_urb+0x85/0x110 [usbcore]
[] usb_hcd_giveback_urb+0x3f/0x130 [usbcore]
[] handle_tx_event+0x4ca/0x13c0 [xhci_hcd]
[] xhci_irq+0x272/0xa30 [xhci_hcd]
[] xhci_msi_irq+0x11/0x20 [xhci_hcd]
[] __handle_irq_event_percpu+0x3f/0x1d0
[] handle_irq_event_percpu+0x23/0x60
[] handle_irq_event+0x3c/0x60
[] handle_edge_irq+0x9b/0x160
[] handle_irq+0x20/0x30

unreferenced object 0x88010ccbd200 (size 256):
  comm "kworker/u17:2", pid 684, jiffies 4312467853 (age 61.716s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
1e c6 5f 75 10 90 6c 14 00 00 00 00 00 00 00 00  .._u..l.
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] kmem_cache_alloc+0xc4/0x1f0
[] skb_clone+0x4c/0xa0
[] hci_event_packet+0xb8/0x30b0 [bluetooth]
[] hci_rx_work+0x18d/0x380 [bluetooth]
[] process_one_work+0x14b/0x430
[] worker_thread+0x12b/0x490
[] kthread+0xc9/0xe0
[] ret_from_fork+0x1f/0x40
[] 0x

I will attempt a bisection.

Larry

[PATCH 0/3] hostap: Fine-tuning for a few functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 18:35:43 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Use memdup_user()
  Delete an unnecessary jump label
  Delete unnecessary variable initialisations

 .../net/wireless/intersil/hostap/hostap_ioctl.c| 36 --
 1 file changed, 12 insertions(+), 24 deletions(-)

-- 
2.9.3

[PATCH 1/3] hostap: Use memdup_user() rather than duplicating its implementation

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 18:19:43 +0200

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 .../net/wireless/intersil/hostap/hostap_ioctl.c| 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c 
b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
index 3e5fa78..4e271f9 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
@@ -3041,14 +3041,9 @@ static int prism2_ioctl_priv_download(local_info_t 
*local, struct iw_point *p)
p->length > 1024 || !p->pointer)
return -EINVAL;
 
-   param = kmalloc(p->length, GFP_KERNEL);
-   if (param == NULL)
-   return -ENOMEM;
-
-   if (copy_from_user(param, p->pointer, p->length)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   param = memdup_user(p->pointer, p->length);
+   if (IS_ERR(param))
+   return PTR_ERR(param);
 
if (p->length < sizeof(struct prism2_download_param) +
param->num_areas * sizeof(struct prism2_download_area)) {
@@ -3803,14 +3798,9 @@ static int prism2_ioctl_priv_hostapd(local_info_t 
*local, struct iw_point *p)
p->length > PRISM2_HOSTAPD_MAX_BUF_SIZE || !p->pointer)
return -EINVAL;
 
-   param = kmalloc(p->length, GFP_KERNEL);
-   if (param == NULL)
-   return -ENOMEM;
-
-   if (copy_from_user(param, p->pointer, p->length)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   param = memdup_user(p->pointer, p->length);
+   if (IS_ERR(param))
+   return PTR_ERR(param);
 
switch (param->cmd) {
case PRISM2_SET_ENCRYPTION:
-- 
2.9.3

[PATCH 2/3] hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 18:21:29 +0200

Remove a jump label which is unneeded in this function at the end.

Signed-off-by: Markus Elfring 
---
 drivers/net/wireless/intersil/hostap/hostap_ioctl.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c 
b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
index 4e271f9..5942917 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
@@ -3835,14 +3835,12 @@ static int prism2_ioctl_priv_hostapd(local_info_t 
*local, struct iw_point *p)
}
 
if (ret == 1 || !ap_ioctl) {
-   if (copy_to_user(p->pointer, param, p->length)) {
+   if (copy_to_user(p->pointer, param, p->length))
ret = -EFAULT;
-   goto out;
-   } else if (ap_ioctl)
+   else if (ap_ioctl)
ret = 0;
}
 
- out:
kfree(param);
return ret;
 }
-- 
2.9.3

[PATCH 3/3] hostap: Delete unnecessary initialisations for the variable "ret"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 18:23:14 +0200

The local variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning of four functions.

Signed-off-by: Markus Elfring 
---
 drivers/net/wireless/intersil/hostap/hostap_ioctl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c 
b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
index 5942917..c37b0bb 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
@@ -2895,7 +2895,7 @@ static int prism2_ioctl_priv_monitor(struct net_device 
*dev, int *i)
 {
struct hostap_interface *iface;
local_info_t *local;
-   int ret = 0;
+   int ret;
u32 mode;
 
iface = netdev_priv(dev);
@@ -3035,7 +3035,7 @@ static int ap_mac_cmd_ioctl(local_info_t *local, int *cmd)
 static int prism2_ioctl_priv_download(local_info_t *local, struct iw_point *p)
 {
struct prism2_download_param *param;
-   int ret = 0;
+   int ret;
 
if (p->length < sizeof(struct prism2_download_param) ||
p->length > 1024 || !p->pointer)
@@ -3791,7 +3791,7 @@ static int prism2_ioctl_scan_req(local_info_t *local,
 static int prism2_ioctl_priv_hostapd(local_info_t *local, struct iw_point *p)
 {
struct prism2_hostapd_param *param;
-   int ret = 0;
+   int ret;
int ap_ioctl = 0;
 
if (p->length < sizeof(struct prism2_hostapd_param) ||
@@ -3954,7 +3954,7 @@ int hostap_ioctl(struct net_device *dev, struct ifreq 
*ifr, int cmd)
struct iwreq *wrq = (struct iwreq *) ifr;
struct hostap_interface *iface;
local_info_t *local;
-   int ret = 0;
+   int ret;
 
iface = netdev_priv(dev);
local = iface->local;
-- 
2.9.3

runaway latency detection

[T. Smith]

Trying to isolate PREEMPT_RT (full preemption) runaway latency conditions seen 
when using the cyclictest on the 4.1.8 SMP PREEMPT_RT kernel.  Seen average 
latency of 3uS, but runaway or outlier max latency seems indeterminate.  Noted 
72uS with one run of the cyclictest for example. Is this a known issue, the 
cause understood, and is there a patch for this?  

The goal is to isolate causes of indeterminism when using the PREEMPT_RT kernel 
configuration with full preemption and to characterize latency and jitter using 
ftrace, any recommendations?

Moving GPIO interrupts and IPIs to a core other than 0

[T. Smith]

On the 4.1.8-rt8+gdb51baf SMP PREMPT RT kernel, GPIO interrupts are assigned to 
core 0 as are the following IPI interrupts:

Arch_timer
Rescheduling Interrupt
Function call interrupt

Trying to assign GPIO interrupts to core 2 for example, or trying to reassign 
or move IPI interrupts running on core 0 to some other core does not seem 
possible since attempting to move these was unsuccessful. Successfully moved 
other ISRs and tasks to other cores with no problem.

1.  How does one control GPIO ISR affinity when GPIOs interrupts always appear 
to run on Core 0? How do we assign GPIO interrupts to any core other than 
Core#0. 

2.  It looks like the existing GPIO driver does not support assigning 
interrupts to any other core than CPU0, is this correct?

3.  If so, why are GPIO interrupts assigned only to Core#0?

4.  There are virtual GPIO interrupts and GPIO hardware interrupts, can either 
or both interrupts be assigned to a specific core other than Core#0?

5.  Is it possible to isolate a given CPU core from the following IPI 
interrupts, and if so, how do we isolate CPU0 from the following IPI 
interrupts.  If not, why are these always serviced on boot core 0? Arch_timer, 
Rescheduling Interrupt, Function call interrupt

Creating the GPIO interrupt:

root:~# echo 498 > /sys/class/gpio/export
root:~# echo falling > /sys/class/gpio/gpio498/edge
root:~# cat /proc/interrupts

   CPU0 CPU1   CPU2   CPU3
[] 
66:00  0  0 GIC 106
Level174.jr
67:00  0  0 mpc8xxx-gpio   18
Edge gpiolib
IPI0:  3226 4833   4237  4170   Recheduling interrupts
IPI1:17   21 1923   Function call interrupts

Setting GPIO affinity doesn’t work:

root:~# echo 1 > /proc/irq/67/smp_affinity_list-sh: echo: write error: 
Input/output error

Setting eMMC interrupt affinity works just fine:

root:~# echo 1 > /proc/irq/12/smp_affinity_list
root:~# cat /proc/interrupts

CPU0 CPU1   CPU2   CPU3
[] 
1:00  0  0 GIC 29
Edgearch_timer
2:   35475  3933628975   38803 GIC 30
Edgearch_timer
11 9   0  0   0GIC 75 Levelfsl-ifc
12:   3370 14 0   0GIC 94 Levelmmc0
[...]

thx, Tracy

[PATCH] s390/tape: Use memdup_user() rather than duplicating its implementation

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 19:25:34 +0200

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/s390/char/tape_3590.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/s390/char/tape_3590.c b/drivers/s390/char/tape_3590.c
index d3d1936..e352047 100644
--- a/drivers/s390/char/tape_3590.c
+++ b/drivers/s390/char/tape_3590.c
@@ -312,15 +312,10 @@ static int tape_3592_ioctl_kekl_set(struct tape_device 
*device,
return -ENOSYS;
if (!crypt_enabled(device))
return -EUNATCH;
-   ext_kekls = kmalloc(sizeof(*ext_kekls), GFP_KERNEL);
-   if (!ext_kekls)
-   return -ENOMEM;
-   if (copy_from_user(ext_kekls, (char __user *)arg, sizeof(*ext_kekls))) {
-   rc = -EFAULT;
-   goto out;
-   }
+   ext_kekls = memdup_user((char __user *)arg, sizeof(*ext_kekls));
+   if (IS_ERR(ext_kekls))
+   return PTR_ERR(ext_kekls);
rc = tape_3592_kekl_set(device, ext_kekls);
-out:
kfree(ext_kekls);
return rc;
 }
-- 
2.9.3

Re: runaway latency detection

[Nikolay Borisov]

On 20.08.2016 20:03, T. Smith wrote:
> The goal is to isolate causes of indeterminism when using the PREEMPT_RT 
> kernel configuration with full preemption and to characterize latency and 
> jitter using ftrace, any recommendations?

What hardware is it ? If it's x86 it's entirely possible you are seeing
SMI. Perhaps you should look into disabling those if you are on x86?

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Mikko Rapeli]

Cc'ing lkml too.

On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
> Story time:
> I was dreaming of a day were we can stop installing these headers,
> thus making deprecation a bit easier process.
> Yet after failing to convince Dave and Daniel on a number of occasions
> I've accepted that those headers _are_ here to stay. And yes they
> _are_ the UAPI, even though no applications are meant to use them but
> the libdrm 'version'.
> Thus any changes to the libdrm ones should be a mirror of the ones
> here and libdrm should _not_ differ.

Another day dream:

Wouldn't it be nice if the uapi headers from Linux kernel would pass
a simple quality check of compiling in userspace where they are meant to be
used? Stand alone. Without magic tricks and additional libraries and their
headers. Without glibc or any other libc implementation specific additions.
The uapi headers define many parts of the Linux kernel API and ABI, and thus
compiling them also without the 'official' GNU/Linux userspace libraries
like glibc or libdrm does have some uses. For example API and ABI
compatibility checks and API/ABI/system call fuzzers.

Many headers required stdint.h types but Linux kernel headers do not
define them in userspace, and then Linus has said that uapi headers
should use the linux/types.h with double underscores. Thus my patches
for fixing trivial compile errors turned into changing several stdint.h
definitions to linux/types.h.

Yes, there have been some regressions in this work but to err is human.
What is the actual problem and how can we (yes, including me) try to
solve it?

-Mikko

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Mikko Rapeli]

Cc'ing lkml.

On Fri, Aug 19, 2016 at 09:18:24PM -0500, Ken Phillis Jr wrote:
> On Fri, Aug 19, 2016 at 8:46 PM, Rob Clark  wrote:
> 
> > perhaps, but if the target audience for driver specific APIs is
> > libdrm/mesa, which already uses stdint types, then I fail to see the
> > point..
> >
> > It is a bit difference scenario for some of the core kms ioctls which
> > are not driver specific..  but most of the driver specific gpu related
> > ioctls tend to be rather complex and not intended for use by something
> > other than libdrm/mesa.
> >
> > BR,
> > -R
> >
> 
> I personally do not see the reason to break user space API in the first
> place.
> I know for a fact that the include file ( linux/types.h ) mentioned by the
> patch
> supports C99 integer data types since Linux Kernel Version 2.2.0. This makes
> the patch that got reverted completely meaningless since the only reason to
> make this change in the first place would be if the developer intends on
> backporting the driver to kernels older than version 2.2.0.

In userspace linux/types.h does not provide these integer data types to avoid
conflict with libc ones.

Thus several uapi headers fail to compile in userspace. Fix is to either
include libc side stdint.h in userspace but that was rejected by kernel
developers including Linus who are in favor of kernel specific double
underscore types.

-Mikko

[GIT PULL] parisc architecture fixes for 4.8-rc3

[Helge Deller]

Hi Linus,

Please pull two fixes for the parisc architecture for kernel 4.8-rc3 from 
  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
parisc-4.8-2

The first patch ensures that the high-res cr16 clocksource (which was added in
kernel 4.7) gets choosen as default clocksource for parisc.

The second patch moves the #define of EREFUSED down inside errno.h and thus
unbreaks building the gccgo compiler.

Thanks,
Helge


Helge Deller (2):
  parisc: Fix automatic selection of cr16 clocksource
  parisc: Fix order of EREFUSED define in errno.h

 arch/parisc/include/uapi/asm/errno.h |  4 ++--
 arch/parisc/kernel/processor.c   |  8 
 arch/parisc/kernel/time.c| 12 
 3 files changed, 2 insertions(+), 22 deletions(-)

Re: [PATCH v2 1/2] ARM: dts: Add MDM9615 dtsi

[Neil Armstrong]

On 08/18/2016 08:08 PM, Stephen Boyd wrote:
> On 08/18, Neil Armstrong wrote:
>> +
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/ {
>> +model = "Qualcomm MDM9615";
>> +compatible = "qcom,mdm9615";
>> +interrupt-parent = <&intc>;
>> +
>> +cpus {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +interrupts = ;
> 
> What's this interrupt for? 0x304 seems wrong as well, because 0x3
> would mean two CPUs and this is a SPI and not a PPI?
Bad copy paste

> 
>> +
>> +cpu0: cpu@0 {
>> +compatible = "arm,cortex-a5";
>> +device_type = "cpu";
>> +next-level-cache = <&L2>;
>> +};
>> +};
>> +
>> +cpu-pmu {
>> +compatible = "arm,cortex-a5-pmu";
>> +interrupts = ;
>> +};
>> +
>> +clocks {
>> +cxo_board {
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <1920>;
>> +clock-output-names = "cxo_board";
> 
> This is unnecessary as it's the same name as the node name.
> 
>> +};
>> +};
>> +
>> +soc: soc {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +compatible = "simple-bus";
>> +
>> +L2: l2-cache {
>> +compatible = "arm,pl310-cache";
>> +reg = <0x0204 0x1000>;
>> +arm,data-latency = <2 2 0>;
>> +cache-unified;
>> +cache-level = <2>;
>> +};
>> +
>> +intc: interrupt-controller@200 {
>> +compatible = "qcom,msm-qgic2";
>> +interrupt-controller;
>> +#interrupt-cells = <3>;
>> +reg = <0x0200 0x1000>,
>> +  <0x02002000 0x1000>;
>> +};
>> +
>> +timer@200a000 {
>> +compatible = "qcom,kpss-timer", "qcom,msm-timer";
>> +interrupts = ,
>> + ,
>> + ;
> 
> 0x101 for all those flags?

Bad copy paste

> 
>> +reg = <0x0200a000 0x100>;
>> +clock-frequency = <2700>,
>> +  <32768>;
>> +cpu-offset = <0x8>;
>> +};
>> +
>> +msmgpio: pinctrl@80 {
>> +compatible = "qcom,mdm9615-pinctrl", "syscon";
> 
> What's the syscon for?

Leftover for USB HSIC calibration registers

> 
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +interrupts = ;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +reg = <0x80 0x4000>;
>> +};
>> +
>> +gcc: clock-controller@90 {
>> +compatible = "qcom,gcc-mdm9615";
>> +#clock-cells = <1>;
>> +#reset-cells = <1>;
>> +reg = <0x90 0x4000>;
>> +};
>> +
>> +lcc: clock-controller@2800 {
>> +compatible = "qcom,lcc-mdm9615";
>> +reg = <0x2800 0x1000>;
>> +#clock-cells = <1>;
>> +#reset-cells = <1>;
>> +};
>> +
>> +l2cc: clock-controller@2011000 {
>> +compatible = "syscon";
>> +reg = <0x02011000 0x1000>;
>> +};
>> +
>> +rng@1a50 {
>> +compatible = "qcom,prng";
>> +reg = <0x1a50 0x200>;
>> +clocks = <&gcc PRNG_CLK>;
>> +clock-names = "core";
>> +assigned-clocks = <&gcc PRNG_CLK>;
>> +assigned-clock-rates = <3200>;
>> +};
>> +
>> +vsdcc_fixed: vsdcc-regulator {
>> +compatible = "regulator-fixed";
>> +regulator-name = "SDCC Power";
>> +regulator-min-microvolt = <270>;
>> +regulator-max-microvolt = <270>;
>> +regulator-always-on;
>> +};
> 
> This should go into the root under a "regulators" node.

Done.
> 
>> +
>> +gsbi2: gsbi@1610 {
>> +compatible = "qcom,gsbi-v1.0.0";
>> +cell-index = <2>;
>> +reg = <0x1610 0x100>;
>> +clocks = <&gcc GSBI2_H_CLK>;
>> +clock-names = "iface";
>> +status = "disabled";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> + 

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Mikko Rapeli]

Cc'ing lkml.

On Sat, Aug 20, 2016 at 12:05:54PM +0200, Marek Olšák wrote:
> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov  
> wrote:
> > On 19 August 2016 at 15:26, Christian König  wrote:
> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
> >>>
> >>> From: Marek Olšák 
> >>>
> >>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
> >>>
> >>> See the comment in the code. Basically, don't do cleanups in this header.
> >>>
> >>> Signed-off-by: Marek Olšák 
> >>
> >>
> >> I completely agree with you that this was a bad move, but I fear that we
> >> will run into opposition with that.
> >>
> > Please check the facts before introducing RATHER ANNOYING AND HARD TO
> > READ COMMENT IN ALL CAPS.
> >
> > Story time:
> > I was dreaming of a day were we can stop installing these headers,
> > thus making deprecation a bit easier process.
> > Yet after failing to convince Dave and Daniel on a number of occasions
> > I've accepted that those headers _are_ here to stay. And yes they
> > _are_ the UAPI, even though no applications are meant to use them but
> > the libdrm 'version'.
> > Thus any changes to the libdrm ones should be a mirror of the ones
> > here and libdrm should _not_ differ.
> >
> > But let's ignore all that and imagine that those headers are _not_
> > UAPI. That gives us even greater reason to _not_ use the uintx_t types
> > but the kernel __uX ones. The series that did these changes had a fair
> > few references why we want that.
> >
> > Yes, I can imagine that the situation isn't ideal, and/or not that
> > clear. Then again a check with git log should have straightened things
> > out.
> > If not _please_ help us improve this (documentation and/or others).
> >
> >
> > And last but not least, please share with up what inspired this -
> > (build/runtime) regression, attempted sync with libdrm, other ?
> 
> Syncing with libdrm became difficult. I'd like the diff between kernel
> and libdrm to be as small as possible.
> 
> We must take into account that the uapi headers can potentially be
> implemented by a different OS. That's why they are in libdrm and
> that's why nobody should make random changes to them in the kernel
> tree. Do not think like a kernel developer isolated in Linux and just
> consider the broader use case. If you do, you'll realize that it
> simply doesn't make sense to use the __uX types here.

When libdrm is combined with Linux kernel, then libdrm should be using
the uapi headers from the kernel. For various reasons there are embedded
kernel header copies in libdrm, glibc and basically everywhere but there
should not be need for that.

What exact problems did you now encounter with libdrm? Did something fail
to compile on Linux or other OS'es?

-Mikko

Re: [PATCH v2 1/4] dt-bindings: vendor-prefixes: Add Sierra Wireless

[Neil Armstrong]

On 08/19/2016 03:48 PM, Rob Herring wrote:
> On Thu, Aug 18, 2016 at 03:11:18PM +0200, Neil Armstrong wrote:
>> Add Sierra Wireless as swi vendor prefix.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 1992aa9..5a8881f 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -254,6 +254,7 @@ starry   Starry Electronic Technology (ShenZhen) Co., LTD
>>  startek Startek
>>  ste ST-Ericsson
>>  stericsson  ST-Ericsson
>> +swi Sierra Wireless
> 
> swir is the stock ticker. Can you use that?

I hoped to use swi since they use is a lot, bet swir is indeed more coherent.

> 
> This is going to have some conflicts with some sorting fixes, so I plan 
> to pick up this patch separately.

OK/\.

> 
> Rob
> 
Thanks,
Neil

Re: [PATCH v6 0/3] virtually mapped stacks

[Andy Lutomirski]

On Thu, Aug 11, 2016 at 2:35 AM, Andy Lutomirski  wrote:
> Andy Lutomirski (3):
>   fork: Add generic vmalloced stack support
>   dma-api: Teach the "DMA-from-stack" check about vmapped stacks
>   x86/mm/64: Enable vmapped stacks


Hi Ingo-

Is this a good format for this series?  Is there anything I need to do?

Re: [PATCH] lib/Kconfig.debug: fix typo in select statement

[Paul E. McKenney]

On Sat, Aug 20, 2016 at 12:16:10PM +0200, Valentin Rothberg wrote:
> Commit 484f29c7430b3 ("bug: Provide toggle for BUG on data corruption")
> added a Kconfig select statement on CONFIG_DEBUG_LIST, but the CONFIG_
> prefix is only used in Make and C(PP) syntax.  Remove the CONFIG_ prefix
> to correctly select the Kconfig option DEBUG_LIST.
> 
> Signed-off-by: Valentin Rothberg 

Well, color me blind!

Good catch, queued for review and testing.

Kees, Steve, Rik, any objections?

Thanx, Paul

> ---
> I detected the issue with scripts/checkkconfigsymbols.py
> 
>  lib/Kconfig.debug | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 5dea4d0a5a07..c2bbaae13d04 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2009,7 +2009,7 @@ config TEST_STATIC_KEYS
> 
>  config BUG_ON_DATA_CORRUPTION
>   bool "Trigger a BUG when data corruption is detected"
> - select CONFIG_DEBUG_LIST
> + select DEBUG_LIST
>   help
> Select this option if the kernel should BUG when it encounters
> data corruption in kernel memory structures when they get checked
> -- 
> 2.9.3
> 

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Marek Olšák]

On Sat, Aug 20, 2016 at 8:08 PM, Mikko Rapeli  wrote:
> Cc'ing lkml.
>
> On Sat, Aug 20, 2016 at 12:05:54PM +0200, Marek Olšák wrote:
>> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov  
>> wrote:
>> > On 19 August 2016 at 15:26, Christian König  
>> > wrote:
>> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>> >>>
>> >>> From: Marek Olšák 
>> >>>
>> >>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>> >>>
>> >>> See the comment in the code. Basically, don't do cleanups in this header.
>> >>>
>> >>> Signed-off-by: Marek Olšák 
>> >>
>> >>
>> >> I completely agree with you that this was a bad move, but I fear that we
>> >> will run into opposition with that.
>> >>
>> > Please check the facts before introducing RATHER ANNOYING AND HARD TO
>> > READ COMMENT IN ALL CAPS.
>> >
>> > Story time:
>> > I was dreaming of a day were we can stop installing these headers,
>> > thus making deprecation a bit easier process.
>> > Yet after failing to convince Dave and Daniel on a number of occasions
>> > I've accepted that those headers _are_ here to stay. And yes they
>> > _are_ the UAPI, even though no applications are meant to use them but
>> > the libdrm 'version'.
>> > Thus any changes to the libdrm ones should be a mirror of the ones
>> > here and libdrm should _not_ differ.
>> >
>> > But let's ignore all that and imagine that those headers are _not_
>> > UAPI. That gives us even greater reason to _not_ use the uintx_t types
>> > but the kernel __uX ones. The series that did these changes had a fair
>> > few references why we want that.
>> >
>> > Yes, I can imagine that the situation isn't ideal, and/or not that
>> > clear. Then again a check with git log should have straightened things
>> > out.
>> > If not _please_ help us improve this (documentation and/or others).
>> >
>> >
>> > And last but not least, please share with up what inspired this -
>> > (build/runtime) regression, attempted sync with libdrm, other ?
>>
>> Syncing with libdrm became difficult. I'd like the diff between kernel
>> and libdrm to be as small as possible.
>>
>> We must take into account that the uapi headers can potentially be
>> implemented by a different OS. That's why they are in libdrm and
>> that's why nobody should make random changes to them in the kernel
>> tree. Do not think like a kernel developer isolated in Linux and just
>> consider the broader use case. If you do, you'll realize that it
>> simply doesn't make sense to use the __uX types here.
>
> When libdrm is combined with Linux kernel, then libdrm should be using
> the uapi headers from the kernel. For various reasons there are embedded
> kernel header copies in libdrm, glibc and basically everywhere but there
> should not be need for that.

You quoted what I had written but you didn't read it.

>
> What exact problems did you now encounter with libdrm? Did something fail
> to compile on Linux or other OS'es?

Read the thread again. I described the problem clearly.

Marek

Re: [PATCH] Try to support analog audio codec at firefly reload

[John Keeping]

On Tue, Aug 16, 2016 at 04:42:06AM +0800, Randy Li wrote:
>   This patch could enabled the es8328 codec at firefly reload board,
> but it doesn't not really work. I disable the mute of channel 
> Left mix and Right mix in alsamixer, I could hear the noise from
> my headphone, but it never be a music. 
>   I just send this patch here to see whether somebody could figure
> out what is wrong, I am really not familiar with sound.

Have you tried adding an mclk-fs setting to the simple-audio-card?  You
probably want to set it to 256, which will allow 44.1kHz, 48kHz, 88.2kHz
and 96kHz at the codec.  This will give more functionality than pinning
the clock to a specific rate.

For the Rock2 Square, I write a machine driver for the sound because the
headphone GPIO setup cannot be made to work with simple-audio-card; I
found the Firefly Reload schematic and it looks like the configuration
hardware is very similar.  It's a bit of a mess but you can find it on
Github [1] if you want to take a look.

[1] https://github.com/johnkeeping/linux/tree/topic/audio

[RESEND PATCH v2 0/4] pwm: Add Amlogic Meson SoC PWM Controller

[Neil Armstrong]

Add support for the PWM controller found in Amlogic Meson SoCs.
This controller provides a dual PWM output with 4 selectable clock source
and a two level divider to achieve a better PWM range.

Currently Meson8b and GXBB SoCs are supported.

Changes since v1 at 
http://lkml.kernel.org/r/1466173784-15625-1-git-send-email-narmstr...@baylibre.com
 :
- fix meson8b dtsi

Neil Armstrong (4):
  pwm: Add support for Meson PWM Controller
  dt-bindings: pwm: Add bindings for Meson PWM Controller
  ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes
  ARM: dts: meson8b: Add Meson8b PWM Controller nodes

 .../devicetree/bindings/pwm/pwm-meson.txt  |  21 +
 arch/arm/boot/dts/meson8b.dtsi |  21 +
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|  28 ++
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-meson.c| 491 +
 6 files changed, 571 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt
 create mode 100644 drivers/pwm/pwm-meson.c

-- 
1.9.1

[RESEND PATCH v2 4/4] ARM: dts: meson8b: Add Meson8b PWM Controller nodes

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/meson8b.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index fc4080d..41fd536 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -162,6 +162,27 @@
reg = <0xc1108000 0x4>, <0xc1104000 0x460>;
};
 
+   pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc1108550 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_cd: pwm@8650 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc1108650 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_ef: pwm@86c0 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc11086c0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
pinctrl_cbus: pinctrl@c1109880 {
compatible = "amlogic,meson8b-cbus-pinctrl";
reg = <0xc1109880 0x10>;
-- 
1.9.1

[RESEND PATCH v2 1/4] pwm: Add support for Meson PWM Controller

[Neil Armstrong]

Add support for the PWM controller found in the Amlogic SoCs.
This driver supports the Meson8b and GXBB SoCs.

Signed-off-by: Neil Armstrong 
---
 drivers/pwm/Kconfig |   9 +
 drivers/pwm/Makefile|   1 +
 drivers/pwm/pwm-meson.c | 491 
 3 files changed, 501 insertions(+)
 create mode 100644 drivers/pwm/pwm-meson.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 80a566a..bf01288 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -262,6 +262,15 @@ config PWM_LPSS_PLATFORM
  To compile this driver as a module, choose M here: the module
  will be called pwm-lpss-platform.
 
+config PWM_MESON
+   tristate "Amlogic Meson PWM driver"
+   depends on ARCH_MESON
+   help
+ The platform driver for Amlogic Meson PWM controller.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-meson.
+
 config PWM_MTK_DISP
tristate "MediaTek display PWM driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index feef1dd..1194c54 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
 obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
 obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
 obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o
+obj-$(CONFIG_PWM_MESON)+= pwm-meson.o
 obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
 obj-$(CONFIG_PWM_MXS)  += pwm-mxs.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
new file mode 100644
index 000..9e7ecf5
--- /dev/null
+++ b/drivers/pwm/pwm-meson.c
@@ -0,0 +1,491 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Copyright (C) 2014 Amlogic, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Copyright (C) 2014 Amlogic, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_PWM_A  0x0
+#define REG_PWM_B  0x4
+#define PWM_HIGH_SHIFT 16
+
+#define REG_MISC_AB0x8
+#define MISC_B_CLK_EN  BIT(23)
+#define MISC_A_CLK_EN  BIT(15)
+#define MISC_CLK_DIV_MASK  0x7f
+#define MISC_B_CLK_DIV_SHIFT   16
+#define MISC_A_CLK_DIV_SHIFT   8
+#define MISC_B_CLK_SEL_SHIFT   6
+#define MISC_A_CLK_SEL_SHIFT   4
+#define MISC_CLK_SEL_WIDTH 2
+#defi

[RESEND PATCH v2 3/4] ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index e502c24..e3f4d36 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -153,6 +153,27 @@
status = "disabled";
};
 
+   pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_cd: pwm@8650 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08650 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_ef: pwm@86c0 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x086c0 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
uart_C: serial@8700 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x8700 0x0 0x14>;
@@ -212,6 +233,13 @@
clocks = <&xtal>;
status = "disabled";
};
+
+   pwm_ab_AO: pwm@550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x0550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
};
 
periphs: periphs@c8834000 {
-- 
1.9.1

[RESEND PATCH v2 2/4] dt-bindings: pwm: Add bindings for Meson PWM Controller

[Neil Armstrong]

Add bindings for the Amlogic PWM Controller in Meson8b and GXBB SoCs.

Signed-off-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/pwm/pwm-meson.txt | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-meson.txt 
b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
new file mode 100644
index 000..e06aed0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
@@ -0,0 +1,21 @@
+Amlogic Meson PWM Controller
+=
+
+Required properties:
+- compatible: Shall contain "amlogic,meson8b-pwm" or "amlogic,meson-gxbb-pwm".
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
+  the cells format.
+
+Optional properties:
+- clocks: Could contain one or two parents clocks phandle for each of the two 
pwm channels.
+- clock-names: Could contain at least the "clkin0" and/or "clkin1" names.
+
+Example:
+pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   clocks = <&xtal>, <&xtal>;
+   clock-names = "clkin0", "clkin1";
+}
-- 
1.9.1

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Marek Olšák]

On Sat, Aug 20, 2016 at 8:28 PM, Marek Olšák  wrote:
> On Sat, Aug 20, 2016 at 8:08 PM, Mikko Rapeli  wrote:
>> Cc'ing lkml.
>>
>> On Sat, Aug 20, 2016 at 12:05:54PM +0200, Marek Olšák wrote:
>>> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov  
>>> wrote:
>>> > On 19 August 2016 at 15:26, Christian König  
>>> > wrote:
>>> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>> >>>
>>> >>> From: Marek Olšák 
>>> >>>
>>> >>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>>> >>>
>>> >>> See the comment in the code. Basically, don't do cleanups in this 
>>> >>> header.
>>> >>>
>>> >>> Signed-off-by: Marek Olšák 
>>> >>
>>> >>
>>> >> I completely agree with you that this was a bad move, but I fear that we
>>> >> will run into opposition with that.
>>> >>
>>> > Please check the facts before introducing RATHER ANNOYING AND HARD TO
>>> > READ COMMENT IN ALL CAPS.
>>> >
>>> > Story time:
>>> > I was dreaming of a day were we can stop installing these headers,
>>> > thus making deprecation a bit easier process.
>>> > Yet after failing to convince Dave and Daniel on a number of occasions
>>> > I've accepted that those headers _are_ here to stay. And yes they
>>> > _are_ the UAPI, even though no applications are meant to use them but
>>> > the libdrm 'version'.
>>> > Thus any changes to the libdrm ones should be a mirror of the ones
>>> > here and libdrm should _not_ differ.
>>> >
>>> > But let's ignore all that and imagine that those headers are _not_
>>> > UAPI. That gives us even greater reason to _not_ use the uintx_t types
>>> > but the kernel __uX ones. The series that did these changes had a fair
>>> > few references why we want that.
>>> >
>>> > Yes, I can imagine that the situation isn't ideal, and/or not that
>>> > clear. Then again a check with git log should have straightened things
>>> > out.
>>> > If not _please_ help us improve this (documentation and/or others).
>>> >
>>> >
>>> > And last but not least, please share with up what inspired this -
>>> > (build/runtime) regression, attempted sync with libdrm, other ?
>>>
>>> Syncing with libdrm became difficult. I'd like the diff between kernel
>>> and libdrm to be as small as possible.
>>>
>>> We must take into account that the uapi headers can potentially be
>>> implemented by a different OS. That's why they are in libdrm and
>>> that's why nobody should make random changes to them in the kernel
>>> tree. Do not think like a kernel developer isolated in Linux and just
>>> consider the broader use case. If you do, you'll realize that it
>>> simply doesn't make sense to use the __uX types here.
>>
>> When libdrm is combined with Linux kernel, then libdrm should be using
>> the uapi headers from the kernel. For various reasons there are embedded
>> kernel header copies in libdrm, glibc and basically everywhere but there
>> should not be need for that.
>
> You quoted what I had written but you didn't read it.

Here's why libdrm can't use the uapi headers: It would break the very
common use case and that is building the latest userspace driver stack
on top of an old kernel. The userspace needs the latest headers, not
the installed ones. Only then is it fully compatible both ways.

Marek

Re: [Documentation] State of CPU controller in cgroup v2

[Andy Lutomirski]

On Sat, Aug 20, 2016 at 8:56 AM, Tejun Heo  wrote:
> Hello, Andy.
>
> On Wed, Aug 17, 2016 at 01:18:24PM -0700, Andy Lutomirski wrote:
>> >   2-1-1. Process Granularity
>> >
>> >   For memory, because an address space is shared between all threads
>> >   of a process, the terminal consumer is a process, not a thread.
>> >   Separating the threads of a single process into different memory
>> >   control domains doesn't make semantical sense.  cgroup v2 ensures
>> >   that all controller can agree on the same organization by requiring
>> >   that threads of the same process belong to the same cgroup.
>>
>> I haven't followed all of the history here, but it seems to me that
>> this argument is less accurate than it appears.  Linux, for better or
>> for worse, has somewhat orthogonal concepts of thread groups
>> (processes), mms, and file tables.  An mm has VMAs in it, and VMAs can
>> reference things (files, etc) that hold resources.  (Two mms can share
>> resources by mapping the same thing or using fork().)  File tables
>> hold files, and files can use resources.  Both of these are, at best,
>> moderately good approximations of what actually holds resources.
>> Meanwhile, threads (tasks) do syscalls, take page faults, *allocate*
>> resources, etc.
>>
>> So I think it's not really true to say that the "terminal consumer" of
>> anything is a process, not a thread.
>
> The terminal consumer is actually the mm context.  A task may be the
> allocating entity but not always for itself.
>
> This becomes clear whenever an entity is allocating memory on behalf
> of someone else - get_user_pages(), khugepaged, swapoff and so on (and
> likely userfaultfd too).  When a task is trying to add a page to a
> VMA, the task might not have any relationship with the VMA other than
> that it's operating on it for someone else.  The page has to be
> charged to whoever is responsible for the VMA and the only ownership
> which can be established is the containing mm_struct.

This surprises me a bit.  If I do access_process_vm(), then I would
have expected the charge to go the caller, not the mm being accessed.

What happens if a program calls read(2), though?  A page may be
inserted into page cache on behalf of an address_space without any
particular mm being involved.  There will usually be a calling task,
though.

But this is all very memcg-specific.  What about other cgroups?  I/O
is per-task, right?  Scheduling is definitely per-task.

>
> While a mm_struct technically may not map to a process, it is a very
> close approxmiation which is hardly ever broken in practice.
>
>> While it's certainly easier to think about assigning processes to
>> cgroups, and I certainly agree that, in the common case, it's the
>> right thing to do, I don't see why requiring it is a good idea.  Can
>> we turn this around: what actually goes wrong if cgroup v2 were to
>> allow assigning individual threads if a user specifically requests it?
>
> Consider the scenario where you have somebody faulting on behalf of a
> foreign VMA, but the thread who created and is actively using that VMA
> is in a different cgroup than the process leader.  Who are we going to
> charge?  All possible answers seem erratic.
>

Indeed, and this problem is probably not solvable in practice unless
you charge all involved cgroups.  But the caller's *mm* is entirely
irrelevant here, so I don't see how this implies that cgroups need to
keep tasks in the same process together.  The relevant entities are
the calling *task* and the target mm, and you're going to be
hard-pressed to ensure that they belong to the same cgroup, so I think
you need to be able handle weird cases in which there isn't an
obviously correct cgroup to charge.

>> >   there are other reasons to enforce process granularity.  One
>> >   important one is isolating system-level management operations from
>> >   in-process application operations.  The cgroup interface, being a
>> >   virtual filesystem, is very unfit for multiple independent
>> >   operations taking place at the same time as most operations have to
>> >   be multi-step and there is no way to synchronize multiple accessors.
>> >   See also [5] Documentation/cgroup-v2.txt, "R-2. Thread Granularity"
>>
>> I don't buy this argument at all.  System-level code is likely to
>> assign single process *trees*, which are a different beast entirely.
>> I.e. you fork, move the child into a cgroup, and that child and its
>> children stay in that cgroup.  I don't see how the thread/process
>> distinction matters.
>
> Good point on the multi-process issue, this is something which nagged
> me a bit while working on rgroup, although I have to point out that
> the issue here is one of not going far enough rather than the approach
> being wrong.  There are limitations to scoping it to individual
> processes but that doesn't negate the underlying problem or the
> usefulness of in-process control.
>
> For system-level and process-level operations to not step on each
> 

hi

[Tjenarvi Tjenarvi]

good evening 

http://saydamyazilim.net/serve.php?temperature=s1m6nk9p7yw4nu





Tjenarvi Tjenarvi

Re: [PATCH 0/3] hostap: Fine-tuning for a few functions

[Arend van Spriel]

On 20-08-16 18:43, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 20 Aug 2016 18:35:43 +0200
> 
> A few update suggestions were taken into account
> from static source code analysis.

Is it worth touching this old stuff especially when you are not making
any functional changes.

Regards,
Arend

> Markus Elfring (3):
>   Use memdup_user()
>   Delete an unnecessary jump label
>   Delete unnecessary variable initialisations
> 
>  .../net/wireless/intersil/hostap/hostap_ioctl.c| 36 
> --
>  1 file changed, 12 insertions(+), 24 deletions(-)
> 

Re: [PATCH 1/2] net: ethernet: renesas: ravb: use phydev from struct net_device

[Sergei Shtylyov]

Hello.

On 08/20/2016 01:52 AM, Philippe Reynes wrote:


The private structure contain a pointer to phydev, but the structure
net_device already contain such pointer. So we can remove the pointer
phy_dev in the private structure, and update the driver to use the
one contained in struct net_device.

Signed-off-by: Philippe Reynes 

[...]

Acked-by: Sergei Shtylyov 

MBR, Sergei

Re: [PATCH 2/2] net: ethernet: renesas: ravb: use new api ethtool_{get|set}_link_ksettings

[Sergei Shtylyov]

On 08/20/2016 01:52 AM, Philippe Reynes wrote:


The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 

[...]

Acked-by: Sergei Shtylyov 

   Sorry for missing the sh_eth patchset. :-<

MBR, Sergei

Re: [PATCH 6/6] Add dockerfile

[Theodore Ts'o]

On Sat, Aug 20, 2016 at 02:31:26PM +0300, Dmitry Monakhov wrote:
> > I'm not sure I see the advantage of doing this in a container, I
> > guess.  I just do in my standard laptop environment today.
> I can not because I laptop from famous thinkpad t430 series with
> flaky SSD which starts to return EIO after intensive load.
> https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T430s-Intel-SSD-520-180GB-issue/td-p/888083

Hmm, I never buy a Lenovo SSD; they're overpriced.  So I always get my
Thinkpads with a 500mb HDD, and then replace it with a Samsumg 840/850
EVO/PRO SSD.

> Also. What about RH/SUSE/Fedora or even Gentoo people? They are exit :)
> And if we give them just chance to try debian w/o complexities
> maybe they will become debian adepts.

You only need Debain to build the image.  If you are just using the
pre-built root_fs.img, you can just download it and go.

Speaking of which, that's one thing which I don't understand about
your Dockerfile.  In the build step you just download the prebuilt
root_fs.img from kernel.org.  There are comments in your Dockerfile which say:

# Fetch and build xfstests-bld
# In order to build root_image from scratch privileged operation are required,
# so it is impossible during build stage.
# One can make it like this:
# docker run -i -t --privileged --rm dmonakhov/xfstests-bld "cd 
kvm-xfstests/test-appliance && ./gen-image"
# During build stage we simply fetch image precreated by tytso@

... but while this will create a new root_fs.img file, as soon as
you're you're done the container will exit, and then the root_fs.img
file will be blown away, right?

The other thing I'll note here is that the Dockerfile is serving two
use cases.  One is to user Docker to do automated build testing.  The
other is for people who want to run multiple instances of kvm-xfstests
using the container services.

For the second, we don't really want to include all of the build
artifacts and build and source trees in Docker image that the users
will have to pull down over the network.  And using kvm-xfstests
--update-xfstests means a lot of extra wasted I/O, since we're
packaging up the tar file, then copying it into file, and then
unpacking it inside the guest VM, etc.

So for the second case, you'd really want to create a Docker image
which had the minimum packages needed to actually *run* the tests,
with the pre-installed root_fs image.

For the first case, all you need to do is to have the Dockerfile
create the xfstests.tar.gz file.  I suppose this could be used as a
poor man's build engine if you don't want to run the build on your
local machine.  What I do is my top-level config.custom has:

BUILD_ENV="schroot -c jessie64 --"
SUDO_ENV="schroot -c jessie64 -u root --"

That's my pristine build chroot, and so when I run ./do-all, what gets
executed is:

schroot -c jessie64 -- make clean
schroot -c jessie64 -- make
schroot -c jessie64 -- make tarball
cd kvm-xfstests/test-appliance
schroot -c jessie64 -u root -- ./gen-image

I'm pretty sure this is going to be faster than waiting for Docker to
build the image, and then for me to download the image and extract the
xfststs.tar.gz file.  (But then again, I have a fully working laptop
with functional SSD's not sourced by Lenovo :-).

- Ted

[PATCH 0/4 v4] usb: dwc2: fix the usb host for host port at RK32

[Randy Li]

Hello All:
 This version would move reset into phy. I wanted to implement a hard
code version but I meet some problem with ioremap reset controller,
in order to keep my word, I offer this version this time.

Randy Li (4):
  phy: Add reset callback
  phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during
wakeup
  usb: dwc2: assert phy reset when waking up in rk3288 platform
  ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

 arch/arm/boot/dts/rk3288.dtsi  |  5 +
 drivers/phy/phy-rockchip-usb.c | 20 
 drivers/usb/dwc2/core_intr.c   |  9 +
 include/linux/phy/phy.h|  2 ++
 4 files changed, 36 insertions(+)

-- 
2.7.4

[PATCH 4/4] ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

[Randy Li]

The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup.  We'll use the reset that's in the CRU to reset the
port when it's in a bad state.

Note that we add the reset to both dwc2 controllers even though only one
has the errata in case we find some other use for this reset that's
unrelated to the current hardware errata.  Only the host port gets the
quirk property, though.

This patch came from Doug Anderson  originally.

Signed-off-by: Randy Li 
---
 arch/arm/boot/dts/rk3288.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 48ca4e4..646f49d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -855,6 +855,8 @@
clocks = <&cru SCLK_OTGPHY0>;
clock-names = "phyclk";
#clock-cells = <0>;
+   resets = <&cru SRST_USBOTG_PHY>;
+   reset-names = "phy-reset";
};
 
usbphy1: usb-phy@334 {
@@ -871,6 +873,9 @@
clocks = <&cru SCLK_OTGPHY2>;
clock-names = "phyclk";
#clock-cells = <0>;
+   resets = <&cru SRST_USBHOST1_PHY>;
+   reset-names = "phy-reset";
+
};
};
};
-- 
2.7.4

[PATCH 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

[Randy Li]

On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

The original patches came from Doug Anderson .

Signed-off-by: Randy Li 
---
 drivers/usb/dwc2/core_intr.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index d85c5c9..c31c3fe 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg 
*hsotg)
 static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
 {
int ret;
+   struct device_node *np = hsotg->dev->of_node;
 
/* Clear interrupt */
dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
@@ -379,6 +380,14 @@ static void dwc2_handle_wakeup_detected_intr(struct 
dwc2_hsotg *hsotg)
/* Restart the Phy Clock */
pcgcctl &= ~PCGCTL_STOPPCLK;
dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
+
+   /* It is a quirk in Rockchip RK3288, causing by
+* a hardware bug. This will propagate out and
+* eventually we'll re-enumerate the device. 
+* Not great but the best we can do */
+   if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
+   hsotg->phy->ops->reset(hsotg->phy);
+
mod_timer(&hsotg->wkp_timer,
  jiffies + msecs_to_jiffies(71));
} else {
-- 
2.7.4

[PATCH 2/4] phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during wakeup

[Randy Li]

It is a hardware bug in RK3288, the only way to solve it is to
reset the phy.

Signed-off-by: Randy Li 
---
 drivers/phy/phy-rockchip-usb.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index 2a7381f..734987f 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int enable_usb_uart;
 
@@ -64,6 +65,7 @@ struct rockchip_usb_phy {
struct clk_hw   clk480m_hw;
struct phy  *phy;
booluart_enabled;
+   struct reset_control *reset;
 };
 
 static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
@@ -144,9 +146,23 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
return clk_prepare_enable(phy->clk480m);
 }
 
+static int rockchip_usb_phy_reset(struct phy *_phy)
+{
+   struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+
+   if (phy->reset) {
+   reset_control_assert(phy->reset);
+   udelay(10);
+   reset_control_deassert(phy->reset);
+   }
+
+   return 0;
+}
+
 static const struct phy_ops ops = {
.power_on   = rockchip_usb_phy_power_on,
.power_off  = rockchip_usb_phy_power_off,
+   .reset  = rockchip_usb_phy_reset,
.owner  = THIS_MODULE,
 };
 
@@ -185,6 +201,10 @@ static int rockchip_usb_phy_init(struct 
rockchip_usb_phy_base *base,
return -EINVAL;
}
 
+   rk_phy->reset = of_reset_control_get(child, "phy-reset");
+   if (IS_ERR(rk_phy->reset))
+   rk_phy->reset = NULL;
+
rk_phy->reg_offset = reg_offset;
 
rk_phy->clk = of_clk_get_by_name(child, "phyclk");
-- 
2.7.4

[PATCH 1/4] phy: Add reset callback

[Randy Li]

The only use for this is for solving a hardware design problem in
usb of Rockchip RK3288.

Signed-off-by: Randy Li 
---
 include/linux/phy/phy.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index f08b672..4d34607 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -36,6 +36,7 @@ enum phy_mode {
  * @power_on: powering on the phy
  * @power_off: powering off the phy
  * @set_mode: set the mode of the phy
+ * @reset: reseting the phy
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -44,6 +45,7 @@ struct phy_ops {
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
int (*set_mode)(struct phy *phy, enum phy_mode mode);
+   int (*reset)(struct phy *phy);
struct module *owner;
 };
 
-- 
2.7.4

Re: [PATCH 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

[Sergei Shtylyov]

Hello.

On 08/20/2016 11:32 PM, Randy Li wrote:


On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

The original patches came from Doug Anderson .

Signed-off-by: Randy Li 
---
 drivers/usb/dwc2/core_intr.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index d85c5c9..c31c3fe 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c

[...]

@@ -379,6 +380,14 @@ static void dwc2_handle_wakeup_detected_intr(struct 
dwc2_hsotg *hsotg)
/* Restart the Phy Clock */
pcgcctl &= ~PCGCTL_STOPPCLK;
dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
+
+   /* It is a quirk in Rockchip RK3288, causing by
+* a hardware bug. This will propagate out and
+* eventually we'll re-enumerate the device.
+* Not great but the best we can do */


  The preferred multi-line comment style is this:

/*
 * bla
 * bla
 */

   Yours is close. :-)

[...]

MBR, Sergei

[PATCH 05/13] lustre: constify lib-move.c stuff

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/include/linux/lnet/lib-lnet.h   | 28 +++---
 drivers/staging/lustre/lnet/lnet/lib-move.c| 20 
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h 
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index 513a822..1c5418e 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -605,34 +605,34 @@ void lnet_counters_reset(void);
 
 unsigned int lnet_iov_nob(unsigned int niov, struct kvec *iov);
 int lnet_extract_iov(int dst_niov, struct kvec *dst,
-int src_niov, struct kvec *src,
+int src_niov, const struct kvec *src,
  unsigned int offset, unsigned int len);
 
 unsigned int lnet_kiov_nob(unsigned int niov, lnet_kiov_t *iov);
 int lnet_extract_kiov(int dst_niov, lnet_kiov_t *dst,
- int src_niov, lnet_kiov_t *src,
+ int src_niov, const lnet_kiov_t *src,
  unsigned int offset, unsigned int len);
 
-void lnet_copy_iov2iov(unsigned int ndiov, struct kvec *diov,
+void lnet_copy_iov2iov(unsigned int ndiov, const struct kvec *diov,
   unsigned int doffset,
-   unsigned int nsiov, struct kvec *siov,
+   unsigned int nsiov, const struct kvec *siov,
unsigned int soffset, unsigned int nob);
-void lnet_copy_kiov2iov(unsigned int niov, struct kvec *iov,
+void lnet_copy_kiov2iov(unsigned int niov, const struct kvec *iov,
unsigned int iovoffset,
-unsigned int nkiov, lnet_kiov_t *kiov,
+unsigned int nkiov, const lnet_kiov_t *kiov,
 unsigned int kiovoffset, unsigned int nob);
-void lnet_copy_iov2kiov(unsigned int nkiov, lnet_kiov_t *kiov,
+void lnet_copy_iov2kiov(unsigned int nkiov, const lnet_kiov_t *kiov,
unsigned int kiovoffset,
-unsigned int niov, struct kvec *iov,
+unsigned int niov, const struct kvec *iov,
 unsigned int iovoffset, unsigned int nob);
-void lnet_copy_kiov2kiov(unsigned int ndkiov, lnet_kiov_t *dkiov,
+void lnet_copy_kiov2kiov(unsigned int ndkiov, const lnet_kiov_t *dkiov,
 unsigned int doffset,
- unsigned int nskiov, lnet_kiov_t *skiov,
+ unsigned int nskiov, const lnet_kiov_t *skiov,
  unsigned int soffset, unsigned int nob);
 
 static inline void
 lnet_copy_iov2flat(int dlen, void *dest, unsigned int doffset,
-  unsigned int nsiov, struct kvec *siov, unsigned int soffset,
+  unsigned int nsiov, const struct kvec *siov, unsigned int 
soffset,
   unsigned int nob)
 {
struct kvec diov = {/*.iov_base = */ dest, /*.iov_len = */ dlen};
@@ -643,7 +643,7 @@ lnet_copy_iov2flat(int dlen, void *dest, unsigned int 
doffset,
 
 static inline void
 lnet_copy_kiov2flat(int dlen, void *dest, unsigned int doffset,
-   unsigned int nsiov, lnet_kiov_t *skiov,
+   unsigned int nsiov, const lnet_kiov_t *skiov,
unsigned int soffset, unsigned int nob)
 {
struct kvec diov = {/* .iov_base = */ dest, /* .iov_len = */ dlen};
@@ -653,7 +653,7 @@ lnet_copy_kiov2flat(int dlen, void *dest, unsigned int 
doffset,
 }
 
 static inline void
-lnet_copy_flat2iov(unsigned int ndiov, struct kvec *diov, unsigned int doffset,
+lnet_copy_flat2iov(unsigned int ndiov, const struct kvec *diov, unsigned int 
doffset,
   int slen, void *src, unsigned int soffset, unsigned int nob)
 {
struct kvec siov = {/*.iov_base = */ src, /*.iov_len = */slen};
@@ -663,7 +663,7 @@ lnet_copy_flat2iov(unsigned int ndiov, struct kvec *diov, 
unsigned int doffset,
 }
 
 static inline void
-lnet_copy_flat2kiov(unsigned int ndiov, lnet_kiov_t *dkiov,
+lnet_copy_flat2kiov(unsigned int ndiov, const lnet_kiov_t *dkiov,
unsigned int doffset, int slen, void *src,
unsigned int soffset, unsigned int nob)
 {
diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c 
b/drivers/staging/lustre/lnet/lnet/lib-move.c
index 6a3f2e1..7d8d2d6 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
@@ -166,8 +166,8 @@ lnet_iov_nob(unsigned int niov, struct kvec *iov)
 EXPORT_SYMBOL(lnet_iov_nob);
 
 void
-lnet_copy_iov2iov(unsigned int ndiov, struct kvec *diov, unsigned int doffset,
- unsigned int nsiov, struct kvec *siov, unsigned int soffset,
+lnet_copy_iov2iov(unsigned int ndiov, const struct kvec *diov, unsigned int 
doffset,
+ unsigned int nsiov, const struct kvec *siov, un

[PATCH 08/13] staging/lustre: Always return EEXIST on mkdir for existing names

[Oleg Drokin]

if the name already exists, but we don't have write permissions
in the parent, force talking to the MDS to determine what
more sensical error code to return.
This also happens to fix matlab and other such programs that
assume that EEXIST is the only valid error code for mkdir of
an existing directory.

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/llite/namei.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 09e1801..8350943 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -541,8 +541,12 @@ static struct dentry *ll_lookup_nd(struct inode *parent, 
struct dentry *dentry,
CDEBUG(D_VFSTRACE, "VFS Op:name=%pd, dir="DFID"(%p),flags=%u\n",
   dentry, PFID(ll_inode2fid(parent)), parent, flags);
 
-   /* Optimize away (CREATE && !OPEN). Let .create handle the race. */
-   if ((flags & LOOKUP_CREATE) && !(flags & LOOKUP_OPEN))
+   /* Optimize away (CREATE && !OPEN). Let .create handle the race.
+* but only if we have write permissions there, otherwise we need
+* to proceed with lookup. LU-4185
+*/
+   if ((flags & LOOKUP_CREATE) && !(flags & LOOKUP_OPEN) &&
+   (inode_permission(parent, MAY_WRITE | MAY_EXEC) == 0))
return NULL;
 
if (flags & (LOOKUP_PARENT|LOOKUP_OPEN|LOOKUP_CREATE))
-- 
2.7.4

[PATCH 01/13] ksocknal_lib_recv_iov(): recvmsg doesn't bugger iovec anymore...

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../lustre/lnet/klnds/socklnd/socklnd_lib.c| 22 +-
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
index fe7b9f9..77bb29ff 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
@@ -201,14 +201,7 @@ ksocknal_lib_eager_ack(struct ksock_conn *conn)
 int
 ksocknal_lib_recv_iov(struct ksock_conn *conn)
 {
-#if SOCKNAL_SINGLE_FRAG_RX
-   struct kvec scratch;
-   struct kvec *scratchiov = &scratch;
-   unsigned int niov = 1;
-#else
-   struct kvec *scratchiov = conn->ksnc_scheduler->kss_scratch_iov;
unsigned int niov = conn->ksnc_rx_niov;
-#endif
struct kvec *iov = conn->ksnc_rx_iov;
struct msghdr msg = {
.msg_flags = 0
@@ -220,20 +213,15 @@ ksocknal_lib_recv_iov(struct ksock_conn *conn)
int sum;
__u32 saved_csum;
 
-   /*
-* NB we can't trust socket ops to either consume our iovs
-* or leave them alone.
-*/
LASSERT(niov > 0);
 
-   for (nob = i = 0; i < niov; i++) {
-   scratchiov[i] = iov[i];
-   nob += scratchiov[i].iov_len;
-   }
+   for (nob = i = 0; i < niov; i++)
+   nob += iov[i].iov_len;
+
LASSERT(nob <= conn->ksnc_rx_nob_wanted);
 
-   rc = kernel_recvmsg(conn->ksnc_sock, &msg, scratchiov, niov, nob,
-   MSG_DONTWAIT);
+   iov_iter_kvec(&msg.msg_iter, READ | ITER_KVEC, iov, niov, nob);
+   rc = sock_recvmsg(conn->ksnc_sock, &msg, MSG_DONTWAIT);
 
saved_csum = 0;
if (conn->ksnc_proto == &ksocknal_protocol_v2x) {
-- 
2.7.4

[PATCH 13/13] Add James Simmons as another Lustre maintainer

[Oleg Drokin]

James Simmons is also spendign a lot of efforts on
cleaning up staging tree Lustre code and also
helps to sync up all the missing changes from the other tree.

Signed-off-by: Oleg Drokin 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a306795..f277cfd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11154,6 +11154,7 @@ F:  drivers/staging/media/lirc/
 STAGING - LUSTRE PARALLEL FILESYSTEM
 M: Oleg Drokin 
 M: Andreas Dilger 
+M: James Simmons 
 L: lustre-de...@lists.lustre.org (moderated for non-subscribers)
 W: http://wiki.lustre.org/
 S: Maintained
-- 
2.7.4

[PATCH 11/13] staging/lustre: Make alignment match open parenthesis

[Oleg Drokin]

From: Emoly Liu 

This patch fixes most of checkpatch occurences of
"CHECK: Alignment should match open parenthesis"
in Lustre code.

Signed-off-by: Emoly Liu 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/include/linux/libcfs/libcfs.h   |   6 +-
 .../lustre/include/linux/libcfs/libcfs_debug.h |  10 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|   2 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |   5 +-
 .../staging/lustre/lnet/klnds/socklnd/socklnd.h|   2 +-
 .../lustre/lnet/libcfs/linux/linux-crypto.c|   4 +-
 drivers/staging/lustre/lustre/include/cl_object.h  |   2 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_extent.c   |   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c|   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_internal.h |  17 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lib.c  |   8 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lock.c |  26 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c|  21 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c |   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_request.c  |  10 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c |   5 +-
 drivers/staging/lustre/lustre/llite/dir.c  |   3 +-
 drivers/staging/lustre/lustre/llite/llite_lib.c|   4 +-
 drivers/staging/lustre/lustre/llite/rw.c   |   4 +-
 drivers/staging/lustre/lustre/llite/statahead.c|   3 +-
 drivers/staging/lustre/lustre/llite/vvp_page.c |   4 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c|   4 +-
 drivers/staging/lustre/lustre/mdc/mdc_locks.c  |   3 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |   2 +-
 drivers/staging/lustre/lustre/osc/osc_cache.c  |   4 +-
 drivers/staging/lustre/lustre/ptlrpc/niobuf.c  |   3 +-
 .../staging/lustre/lustre/ptlrpc/pack_generic.c|   5 +-
 drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c|   5 +-
 drivers/staging/lustre/lustre/ptlrpc/sec_plain.c   |  18 +-
 drivers/staging/lustre/lustre/ptlrpc/service.c |  22 +-
 drivers/staging/lustre/lustre/ptlrpc/wiretest.c| 288 ++---
 31 files changed, 257 insertions(+), 245 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
index 3f6447c..3b92d38 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
@@ -138,8 +138,8 @@ struct lnet_debugfs_symlink_def {
 void lustre_insert_debugfs(struct ctl_table *table,
   const struct lnet_debugfs_symlink_def *symlinks);
 int lprocfs_call_handler(void *data, int write, loff_t *ppos,
- void __user *buffer, size_t *lenp,
- int (*handler)(void *data, int write,
- loff_t pos, void __user *buffer, int len));
+void __user *buffer, size_t *lenp,
+int (*handler)(void *data, int write, loff_t pos,
+   void __user *buffer, int len));
 
 #endif /* _LIBCFS_H */
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
index 25adab1..b7bd6e8 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
@@ -247,19 +247,19 @@ do {  
\
 #define LCONSOLE_EMERG(format, ...) CDEBUG(D_CONSOLE | D_EMERG, format, ## 
__VA_ARGS__)
 
 int libcfs_debug_msg(struct libcfs_debug_msg_data *msgdata,
-   const char *format1, ...)
+const char *format1, ...)
__printf(2, 3);
 
 int libcfs_debug_vmsg2(struct libcfs_debug_msg_data *msgdata,
- const char *format1,
- va_list args, const char *format2, ...)
+  const char *format1,
+  va_list args, const char *format2, ...)
__printf(4, 5);
 
 /* other external symbols that tracefile provides: */
 int cfs_trace_copyin_string(char *knl_buffer, int knl_buffer_nob,
-   const char __user *usr_buffer, int usr_buffer_nob);
+   const char __user *usr_buffer, int usr_buffer_nob);
 int cfs_trace_copyout_string(char __user *usr_buffer, int usr_buffer_nob,
-   const char *knl_buffer, char *append);
+const char *knl_buffer, char *append);
 
 #define LIBCFS_DEBUG_FILE_PATH_DEFAULT "/tmp/lustre-log"
 
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 4f5978b..e93dbeb 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -618,7 +618,7 @@ static int kiblnd_get_completion_vector(struct kib_conn 
*conn, int cpt)
 }
 
 struct kib_

[PATCH 09/13] staging/lustre: Add spaces preferred around that '{+,-,*,/,|,<<

[Oleg Drokin]

From: Emoly Liu 

This patch fixes all checkpatch occurences of
"CHECK: spaces preferred around that '{+,-,*,/,|,<<,>>,&}' (ctx:VxV)"
in Lustre code.

Signed-off-by: Emoly Liu 
Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/lu_object.h  |  3 +-
 .../lustre/lustre/include/lustre/lustre_idl.h  | 42 +++---
 .../lustre/lustre/include/lustre/lustre_user.h |  2 +-
 drivers/staging/lustre/lustre/include/lustre_fid.h |  2 +-
 .../staging/lustre/lustre/include/lustre_lite.h|  2 +-
 .../staging/lustre/lustre/include/obd_support.h| 13 +++
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c|  4 +--
 drivers/staging/lustre/lustre/ldlm/ldlm_request.c  |  4 +--
 drivers/staging/lustre/lustre/llite/dir.c  |  2 +-
 drivers/staging/lustre/lustre/llite/file.c |  4 +--
 drivers/staging/lustre/lustre/llite/llite_lib.c| 21 ++-
 drivers/staging/lustre/lustre/llite/llite_mmap.c   |  4 +--
 drivers/staging/lustre/lustre/llite/lproc_llite.c  | 14 
 drivers/staging/lustre/lustre/llite/namei.c|  4 +--
 drivers/staging/lustre/lustre/llite/rw.c   |  5 +--
 drivers/staging/lustre/lustre/llite/rw26.c |  2 +-
 drivers/staging/lustre/lustre/llite/super25.c  |  4 +--
 drivers/staging/lustre/lustre/llite/vvp_object.c   |  2 +-
 drivers/staging/lustre/lustre/lov/lov_ea.c |  3 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c| 14 
 drivers/staging/lustre/lustre/lov/lov_pool.c   |  2 +-
 drivers/staging/lustre/lustre/mdc/mdc_locks.c  |  2 +-
 drivers/staging/lustre/lustre/mdc/mdc_reint.c  |  5 +--
 drivers/staging/lustre/lustre/obdclass/debug.c |  4 +--
 drivers/staging/lustre/lustre/obdclass/genops.c|  2 +-
 .../staging/lustre/lustre/obdclass/obd_config.c| 12 +++
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |  6 ++--
 drivers/staging/lustre/lustre/obdclass/obdo.c  |  6 ++--
 .../staging/lustre/lustre/obdecho/echo_internal.h  |  4 +--
 drivers/staging/lustre/lustre/osc/osc_cache.c  |  2 +-
 .../staging/lustre/lustre/osc/osc_cl_internal.h|  2 +-
 drivers/staging/lustre/lustre/osc/osc_io.c |  2 +-
 drivers/staging/lustre/lustre/osc/osc_request.c| 12 ---
 drivers/staging/lustre/lustre/ptlrpc/import.c  |  6 ++--
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|  2 +-
 drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c |  4 +--
 drivers/staging/lustre/lustre/ptlrpc/service.c |  2 +-
 37 files changed, 121 insertions(+), 105 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lu_object.h 
b/drivers/staging/lustre/lustre/include/lu_object.h
index 6e25c1b..1e8421c 100644
--- a/drivers/staging/lustre/lustre/include/lu_object.h
+++ b/drivers/staging/lustre/lustre/include/lu_object.h
@@ -1025,7 +1025,8 @@ enum lu_context_tag {
/**
 * Contexts usable in cache shrinker thread.
 */
-   LCT_SHRINKER  = LCT_MD_THREAD|LCT_DT_THREAD|LCT_CL_THREAD|LCT_NOREF
+   LCT_SHRINKER  = LCT_MD_THREAD | LCT_DT_THREAD | LCT_CL_THREAD |
+   LCT_NOREF
 };
 
 /**
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 32471a6..7410a8a 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1318,13 +1318,13 @@ void lustre_swab_ptlrpc_body(struct ptlrpc_body *pb);
 #define CLIENT_CONNECT_MDT_REQD (OBD_CONNECT_IBITS | OBD_CONNECT_FID | \
 OBD_CONNECT_FULL20)
 
-#define OBD_OCD_VERSION(major, minor, patch, fix) (((major)<<24) + \
- ((minor)<<16) + \
- ((patch)<<8) + (fix))
-#define OBD_OCD_VERSION_MAJOR(version) ((int)((version)>>24)&255)
-#define OBD_OCD_VERSION_MINOR(version) ((int)((version)>>16)&255)
-#define OBD_OCD_VERSION_PATCH(version) ((int)((version)>>8)&255)
-#define OBD_OCD_VERSION_FIX(version)   ((int)(version)&255)
+#define OBD_OCD_VERSION(major, minor, patch, fix) (((major) << 24) + \
+  ((minor) << 16) + \
+  ((patch) << 8) + (fix))
+#define OBD_OCD_VERSION_MAJOR(version) ((int)((version) >> 24) & 255)
+#define OBD_OCD_VERSION_MINOR(version) ((int)((version) >> 16) & 255)
+#define OBD_OCD_VERSION_PATCH(version) ((int)((version) >> 8) & 255)
+#define OBD_OCD_VERSION_FIX(version)   ((int)(version) & 255)
 
 /* This structure is used for both request and reply.
  *
@@ -2028,7 +2028,7 @@ void lustre_swab_generic_32s(__u32 *val);
 
 #define MDS_INODELOCK_MAXSHIFT 5
 /* This FULL lock is useful to take on unlink sort of operations */
-#define MDS_INODELOCK_FULL ((1<<(MDS_INODELOCK_MAXSHIFT+1))-1)
+#define MDS_INODELOCK_FULL ((1 << (MDS_INODELOCK_MAXSHIFT + 1)) - 1)
 
 /* NOTE: until Lustre 1.8.7/2.1.1 the fid

[PATCH 12/13] staging/lustre: Remove unused cp_error from struct cl_page

[Oleg Drokin]

cp_error member is not really set anywhere, so kill
it and the only printing user of it too.

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/cl_object.h | 2 --
 drivers/staging/lustre/lustre/obdclass/cl_page.c  | 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/cl_object.h 
b/drivers/staging/lustre/lustre/include/cl_object.h
index 78613a9..6d8f956 100644
--- a/drivers/staging/lustre/lustre/include/cl_object.h
+++ b/drivers/staging/lustre/lustre/include/cl_object.h
@@ -726,8 +726,6 @@ struct cl_page {
struct mutexcp_mutex;
/** Linkage of pages within cl_req. */
struct list_head   cp_flight;
-   /** Transfer error. */
-   int   cp_error;
 
/**
 * Page type. Only CPT_TRANSIENT is used so far. Immutable after
diff --git a/drivers/staging/lustre/lustre/obdclass/cl_page.c 
b/drivers/staging/lustre/lustre/obdclass/cl_page.c
index db2dc6b..d903f71 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_page.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_page.c
@@ -989,9 +989,9 @@ void cl_page_header_print(const struct lu_env *env, void 
*cookie,
  lu_printer_t printer, const struct cl_page *pg)
 {
(*printer)(env, cookie,
-  "page@%p[%d %p %d %d %d %p %p %#x]\n",
+  "page@%p[%d %p %d %d %p %p %#x]\n",
   pg, atomic_read(&pg->cp_ref), pg->cp_obj,
-  pg->cp_state, pg->cp_error, pg->cp_type,
+  pg->cp_state, pg->cp_type,
   pg->cp_owner, pg->cp_req, pg->cp_flags);
 }
 EXPORT_SYMBOL(cl_page_header_print);
-- 
2.7.4

[PATCH 10/13] staging/lustre: Fix unnecessary parentheses around variables

[Oleg Drokin]

From: Emoly Liu 

This patch fixes all checkpatch occurences of
"CHECK: Unnecessary parentheses around xxx"
in Lustre code.

Signed-off-by: Emoly Liu 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/lustre/include/lustre/lustre_user.h   |  2 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c  |  4 ++--
 drivers/staging/lustre/lustre/lov/lov_pool.c | 16 
 drivers/staging/lustre/lustre/obdclass/genops.c  |  4 ++--
 drivers/staging/lustre/lustre/obdclass/llog.c|  2 +-
 drivers/staging/lustre/lustre/obdclass/lustre_handles.c  |  2 +-
 drivers/staging/lustre/lustre/obdclass/obd_config.c  |  2 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c   |  2 +-
 drivers/staging/lustre/lustre/osc/osc_request.c  |  2 +-
 drivers/staging/lustre/lustre/ptlrpc/pack_generic.c  |  6 +++---
 10 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
index 5fc0c5c..e077687 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
@@ -978,7 +978,7 @@ struct hsm_user_request {
 /** Return pointer to data field in a hsm user request */
 static inline void *hur_data(struct hsm_user_request *hur)
 {
-   return &(hur->hur_user_item[hur->hur_request.hr_itemcount]);
+   return &hur->hur_user_item[hur->hur_request.hr_itemcount];
 }
 
 /**
diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c 
b/drivers/staging/lustre/lustre/lov/lov_obd.c
index bc71e4f..52651c4 100644
--- a/drivers/staging/lustre/lustre/lov/lov_obd.c
+++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
@@ -940,7 +940,7 @@ int lov_process_config_base(struct obd_device *obd, struct 
lustre_cfg *lcfg,
}
case LCFG_PARAM: {
struct lprocfs_static_vars lvars = { NULL };
-   struct lov_desc *desc = &(obd->u.lov.desc);
+   struct lov_desc *desc = &obd->u.lov.desc;
 
if (!desc) {
rc = -EINVAL;
@@ -1460,7 +1460,7 @@ static int lov_iocontrol(unsigned int cmd, struct 
obd_export *exp, int len,
}
 
desc = (struct lov_desc *)data->ioc_inlbuf1;
-   memcpy(desc, &(lov->desc), sizeof(*desc));
+   memcpy(desc, &lov->desc, sizeof(*desc));
 
uuidp = (struct obd_uuid *)data->ioc_inlbuf2;
genp = (__u32 *)data->ioc_inlbuf3;
diff --git a/drivers/staging/lustre/lustre/lov/lov_pool.c 
b/drivers/staging/lustre/lustre/lov/lov_pool.c
index 639e086..f8c8a36 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pool.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pool.c
@@ -61,7 +61,7 @@ void lov_pool_putref(struct pool_desc *pool)
LASSERT(hlist_unhashed(&pool->pool_hash));
LASSERT(list_empty(&pool->pool_list));
LASSERT(!pool->pool_debugfs_entry);
-   lov_ost_pool_free(&(pool->pool_obds));
+   lov_ost_pool_free(&pool->pool_obds);
kfree(pool);
}
 }
@@ -260,7 +260,7 @@ static int pool_proc_show(struct seq_file *s, void *v)
tgt = pool_tgt(iter->pool, iter->idx);
up_read(&pool_tgt_rw_sem(iter->pool));
if (tgt)
-   seq_printf(s, "%s\n", obd_uuid2str(&(tgt->ltd_uuid)));
+   seq_printf(s, "%s\n", obd_uuid2str(&tgt->ltd_uuid));
 
return 0;
 }
@@ -400,7 +400,7 @@ int lov_pool_new(struct obd_device *obd, char *poolname)
struct pool_desc *new_pool;
int rc;
 
-   lov = &(obd->u.lov);
+   lov = &obd->u.lov;
 
if (strlen(poolname) > LOV_MAXPOOLNAME)
return -ENAMETOOLONG;
@@ -471,7 +471,7 @@ int lov_pool_del(struct obd_device *obd, char *poolname)
struct lov_obd *lov;
struct pool_desc *pool;
 
-   lov = &(obd->u.lov);
+   lov = &obd->u.lov;
 
/* lookup and kill hash reference */
pool = cfs_hash_del_key(lov->lov_pools_hash_body, poolname);
@@ -503,7 +503,7 @@ int lov_pool_add(struct obd_device *obd, char *poolname, 
char *ostname)
unsigned int lov_idx;
int rc;
 
-   lov = &(obd->u.lov);
+   lov = &obd->u.lov;
 
pool = cfs_hash_lookup(lov->lov_pools_hash_body, poolname);
if (!pool)
@@ -517,7 +517,7 @@ int lov_pool_add(struct obd_device *obd, char *poolname, 
char *ostname)
if (!lov->lov_tgts[lov_idx])
continue;
if (obd_uuid_equals(&ost_uuid,
-   &(lov->lov_tgts[lov_idx]->ltd_uuid)))
+   &lov->lov_tgts[lov_idx]->ltd_uuid))
break;
}
/* test if ost found in lov */
@@ -547,7 +547,7 @@ int lov_pool_remove(struct obd_device *obd, char *poolname, 
char *ostname)
unsigned int lov_idx;
int rc = 0;
 
-   lov 

[PATCH 07/13] lustre: introduce lnet_copy_{k,}iov2iter(), kill lnet_copy_{k,}iov2{k,}iov()

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: James Simmons 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/include/linux/lnet/lib-lnet.h   |  57 +---
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |  37 ++-
 drivers/staging/lustre/lnet/lnet/lib-move.c| 314 -
 drivers/staging/lustre/lnet/lnet/lo.c  |  35 +--
 4 files changed, 86 insertions(+), 357 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h 
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index 1c5418e..a59c5e99c 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -613,65 +613,12 @@ int lnet_extract_kiov(int dst_niov, lnet_kiov_t *dst,
  int src_niov, const lnet_kiov_t *src,
  unsigned int offset, unsigned int len);
 
-void lnet_copy_iov2iov(unsigned int ndiov, const struct kvec *diov,
-  unsigned int doffset,
+void lnet_copy_iov2iter(struct iov_iter *to,
unsigned int nsiov, const struct kvec *siov,
unsigned int soffset, unsigned int nob);
-void lnet_copy_kiov2iov(unsigned int niov, const struct kvec *iov,
-   unsigned int iovoffset,
+void lnet_copy_kiov2iter(struct iov_iter *to,
 unsigned int nkiov, const lnet_kiov_t *kiov,
 unsigned int kiovoffset, unsigned int nob);
-void lnet_copy_iov2kiov(unsigned int nkiov, const lnet_kiov_t *kiov,
-   unsigned int kiovoffset,
-unsigned int niov, const struct kvec *iov,
-unsigned int iovoffset, unsigned int nob);
-void lnet_copy_kiov2kiov(unsigned int ndkiov, const lnet_kiov_t *dkiov,
-unsigned int doffset,
- unsigned int nskiov, const lnet_kiov_t *skiov,
- unsigned int soffset, unsigned int nob);
-
-static inline void
-lnet_copy_iov2flat(int dlen, void *dest, unsigned int doffset,
-  unsigned int nsiov, const struct kvec *siov, unsigned int 
soffset,
-  unsigned int nob)
-{
-   struct kvec diov = {/*.iov_base = */ dest, /*.iov_len = */ dlen};
-
-   lnet_copy_iov2iov(1, &diov, doffset,
- nsiov, siov, soffset, nob);
-}
-
-static inline void
-lnet_copy_kiov2flat(int dlen, void *dest, unsigned int doffset,
-   unsigned int nsiov, const lnet_kiov_t *skiov,
-   unsigned int soffset, unsigned int nob)
-{
-   struct kvec diov = {/* .iov_base = */ dest, /* .iov_len = */ dlen};
-
-   lnet_copy_kiov2iov(1, &diov, doffset,
-  nsiov, skiov, soffset, nob);
-}
-
-static inline void
-lnet_copy_flat2iov(unsigned int ndiov, const struct kvec *diov, unsigned int 
doffset,
-  int slen, void *src, unsigned int soffset, unsigned int nob)
-{
-   struct kvec siov = {/*.iov_base = */ src, /*.iov_len = */slen};
-
-   lnet_copy_iov2iov(ndiov, diov, doffset,
- 1, &siov, soffset, nob);
-}
-
-static inline void
-lnet_copy_flat2kiov(unsigned int ndiov, const lnet_kiov_t *dkiov,
-   unsigned int doffset, int slen, void *src,
-   unsigned int soffset, unsigned int nob)
-{
-   struct kvec siov = {/* .iov_base = */ src, /* .iov_len = */ slen};
-
-   lnet_copy_iov2kiov(ndiov, dkiov, doffset,
-  1, &siov, soffset, nob);
-}
 
 void lnet_me_unlink(lnet_me_t *me);
 
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 1b20ae8..2581744 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -1499,6 +1499,7 @@ kiblnd_send(lnet_ni_t *ni, void *private, lnet_msg_t 
*lntmsg)
lnet_kiov_t *payload_kiov = lntmsg->msg_kiov;
unsigned int payload_offset = lntmsg->msg_offset;
unsigned int payload_nob = lntmsg->msg_len;
+   struct iov_iter from;
struct kib_msg *ibmsg;
struct kib_rdma_desc  *rd;
struct kib_tx *tx;
@@ -1518,6 +1519,17 @@ kiblnd_send(lnet_ni_t *ni, void *private, lnet_msg_t 
*lntmsg)
/* payload is either all vaddrs or all pages */
LASSERT(!(payload_kiov && payload_iov));
 
+   if (payload_kiov)
+   iov_iter_bvec(&from, ITER_BVEC | WRITE,
+ payload_kiov, payload_niov,
+ payload_nob + payload_offset);
+   else
+   iov_iter_kvec(&from, ITER_KVEC | WRITE,
+ payload_iov, payload_niov,
+ payload_nob + payload_offset);
+
+   iov_iter_advance(&from, payload_offset);
+
switch (type) {
default:
LBUG();
@@ -1637,17 +1649,8 @@ kiblnd_send(lnet_ni_t *n

[PATCH 00/13] Lustre patches

[Oleg Drokin]

This is rebase of the previous set that got merged only half-way with
added signed-offs as requested.

I also added a patch to include James Simmons as a Lustre maintainer too
since he is performing a lot of work in the area.

Al Viro (7):
  ksocknal_lib_recv_iov(): recvmsg doesn't bugger iovec anymore...
  ksocknal_lib_send_iov(): sendmsg doesn't bugger iovec...
  ksocknal_lib_send_kiov(): sendmsg doesn't bugger iovec...
  lustre: ->kss_scratch... are unused now
  lustre: constify lib-move.c stuff
  lustre: pass iov_iter to ->lnd_recv()
  lustre: introduce lnet_copy_{k,}iov2iter(), kill
lnet_copy_{k,}iov2{k,}iov()

Emoly Liu (3):
  staging/lustre: Add spaces preferred around that '{+,-,*,/,|,<<,>>,&}'
  staging/lustre: Fix unnecessary parentheses around variables
  staging/lustre: Make alignment match open parenthesis

Oleg Drokin (3):
  staging/lustre: Always return EEXIST on mkdir for existing names
  staging/lustre: Remove unused cp_error from struct cl_page
  Add James Simmons as another Lustre maintainer

 MAINTAINERS|   1 +
 .../staging/lustre/include/linux/libcfs/libcfs.h   |   6 +-
 .../lustre/include/linux/libcfs/libcfs_debug.h |  10 +-
 .../staging/lustre/include/linux/lnet/lib-lnet.h   |  65 +---
 .../staging/lustre/include/linux/lnet/lib-types.h  |   5 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|   2 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|   3 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |  64 ++--
 .../staging/lustre/lnet/klnds/socklnd/socklnd.h|  10 +-
 .../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c |  21 +-
 .../lustre/lnet/klnds/socklnd/socklnd_lib.c|  89 ++
 .../lustre/lnet/libcfs/linux/linux-crypto.c|   4 +-
 drivers/staging/lustre/lnet/lnet/lib-move.c| 329 +
 drivers/staging/lustre/lnet/lnet/lo.c  |  39 +--
 drivers/staging/lustre/lustre/include/cl_object.h  |   4 +-
 drivers/staging/lustre/lustre/include/lu_object.h  |   3 +-
 .../lustre/lustre/include/lustre/lustre_idl.h  |  42 +--
 .../lustre/lustre/include/lustre/lustre_user.h |   4 +-
 drivers/staging/lustre/lustre/include/lustre_fid.h |   2 +-
 .../staging/lustre/lustre/include/lustre_lite.h|   2 +-
 .../staging/lustre/lustre/include/obd_support.h|  13 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_extent.c   |   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c|   8 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_internal.h |  17 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lib.c  |   8 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lock.c |  26 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c|  21 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c |   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_request.c  |  14 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c |   5 +-
 drivers/staging/lustre/lustre/llite/dir.c  |   5 +-
 drivers/staging/lustre/lustre/llite/file.c |   4 +-
 drivers/staging/lustre/lustre/llite/llite_lib.c|  25 +-
 drivers/staging/lustre/lustre/llite/llite_mmap.c   |   4 +-
 drivers/staging/lustre/lustre/llite/lproc_llite.c  |  14 +-
 drivers/staging/lustre/lustre/llite/namei.c|  12 +-
 drivers/staging/lustre/lustre/llite/rw.c   |   9 +-
 drivers/staging/lustre/lustre/llite/rw26.c |   2 +-
 drivers/staging/lustre/lustre/llite/statahead.c|   3 +-
 drivers/staging/lustre/lustre/llite/super25.c  |   4 +-
 drivers/staging/lustre/lustre/llite/vvp_object.c   |   2 +-
 drivers/staging/lustre/lustre/llite/vvp_page.c |   4 +-
 drivers/staging/lustre/lustre/lov/lov_ea.c |   3 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c|  22 +-
 drivers/staging/lustre/lustre/lov/lov_pool.c   |  18 +-
 drivers/staging/lustre/lustre/mdc/mdc_locks.c  |   5 +-
 drivers/staging/lustre/lustre/mdc/mdc_reint.c  |   5 +-
 drivers/staging/lustre/lustre/obdclass/cl_page.c   |   4 +-
 drivers/staging/lustre/lustre/obdclass/debug.c |   4 +-
 drivers/staging/lustre/lustre/obdclass/genops.c|   6 +-
 drivers/staging/lustre/lustre/obdclass/llog.c  |   2 +-
 .../lustre/lustre/obdclass/lustre_handles.c|   2 +-
 .../staging/lustre/lustre/obdclass/obd_config.c|  14 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |  10 +-
 drivers/staging/lustre/lustre/obdclass/obdo.c  |   6 +-
 .../staging/lustre/lustre/obdecho/echo_internal.h  |   4 +-
 drivers/staging/lustre/lustre/osc/osc_cache.c  |   6 +-
 .../staging/lustre/lustre/osc/osc_cl_internal.h|   2 +-
 drivers/staging/lustre/lustre/osc/osc_io.c |   2 +-
 drivers/staging/lustre/lustre/osc/osc_request.c|  14 +-
 drivers/staging/lustre/lustre/ptlrpc/import.c  |   6 +-
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|   2 +-
 drivers/staging/lustre/lustre/ptlrpc/niobuf.c  |   3 +-
 .../staging/lustre/lustre/ptlrpc/pack_generic.c|  11 +-
 drivers/staging/lustre/lustre/ptlrp

[PATCH 03/13] ksocknal_lib_send_kiov(): sendmsg doesn't bugger iovec...

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../lustre/lnet/klnds/socklnd/socklnd_lib.c| 29 --
 1 file changed, 5 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
index 8eb4a68..6c95e98 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
@@ -106,10 +106,6 @@ ksocknal_lib_send_kiov(struct ksock_conn *conn, struct 
ksock_tx *tx)
/* Not NOOP message */
LASSERT(tx->tx_lnetmsg);
 
-   /*
-* NB we can't trust socket ops to either consume our iovs
-* or leave them alone.
-*/
if (tx->tx_msg.ksm_zc_cookies[0]) {
/* Zero copy is enabled */
struct sock *sk = sock->sk;
@@ -132,34 +128,19 @@ ksocknal_lib_send_kiov(struct ksock_conn *conn, struct 
ksock_tx *tx)
rc = tcp_sendpage(sk, page, offset, fragsize, msgflg);
}
} else {
-#if SOCKNAL_SINGLE_FRAG_TX || !SOCKNAL_RISK_KMAP_DEADLOCK
-   struct kvec scratch;
-   struct kvec *scratchiov = &scratch;
-   unsigned int niov = 1;
-#else
-#ifdef CONFIG_HIGHMEM
-#warning "XXX risk of kmap deadlock on multiple frags..."
-#endif
-   struct kvec *scratchiov = conn->ksnc_scheduler->kss_scratch_iov;
-   unsigned int niov = tx->tx_nkiov;
-#endif
struct msghdr msg = {.msg_flags = MSG_DONTWAIT};
int i;
 
-   for (nob = i = 0; i < niov; i++) {
-   scratchiov[i].iov_base = kmap(kiov[i].bv_page) +
-kiov[i].bv_offset;
-   nob += scratchiov[i].iov_len = kiov[i].bv_len;
-   }
+   for (nob = i = 0; i < tx->tx_nkiov; i++)
+   nob += kiov[i].bv_len;
 
if (!list_empty(&conn->ksnc_tx_queue) ||
nob < tx->tx_resid)
msg.msg_flags |= MSG_MORE;
 
-   rc = kernel_sendmsg(sock, &msg, (struct kvec *)scratchiov, 
niov, nob);
-
-   for (i = 0; i < niov; i++)
-   kunmap(kiov[i].bv_page);
+   iov_iter_bvec(&msg.msg_iter, WRITE | ITER_BVEC,
+ kiov, tx->tx_nkiov, nob);
+   rc = sock_sendmsg(sock, &msg);
}
return rc;
 }
-- 
2.7.4

[PATCH 04/13] lustre: ->kss_scratch... are unused now

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
index d5efb42..84a915c 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
@@ -86,10 +86,6 @@ struct ksock_sched { /* per 
scheduler state */
int kss_nconns; /* # connections assigned to
 * this scheduler */
struct ksock_sched_info *kss_info;  /* owner of it */
-   union {
-   struct bio_vec  kss_scratch_bvec[LNET_MAX_IOV];
-   struct kvec kss_scratch_iov[LNET_MAX_IOV];
-   };
 };
 
 struct ksock_sched_info {
-- 
2.7.4

[PATCH 06/13] lustre: pass iov_iter to ->lnd_recv()

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/include/linux/lnet/lib-types.h  |  5 +---
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|  3 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 32 --
 .../staging/lustre/lnet/klnds/socklnd/socklnd.h|  4 +--
 .../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 21 ++
 drivers/staging/lustre/lnet/lnet/lib-move.c| 11 ++--
 drivers/staging/lustre/lnet/lnet/lo.c  | 24 
 7 files changed, 49 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h 
b/drivers/staging/lustre/include/linux/lnet/lib-types.h
index 7967b01..640ff72 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
@@ -220,10 +220,7 @@ typedef struct lnet_lnd {
 * credit if the LND does flow control.
 */
int (*lnd_recv)(struct lnet_ni *ni, void *private, lnet_msg_t *msg,
-   int delayed, unsigned int niov,
-   struct kvec *iov, lnet_kiov_t *kiov,
-   unsigned int offset, unsigned int mlen,
-   unsigned int rlen);
+   int delayed, struct iov_iter *to, unsigned int rlen);
 
/*
 * lnet_parse() has had to delay processing of this message
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
index 078a0c3..f49483e 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
@@ -1034,5 +1034,4 @@ int  kiblnd_post_rx(struct kib_rx *rx, int credit);
 
 int  kiblnd_send(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg);
 int  kiblnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg, int delayed,
-unsigned int niov, struct kvec *iov, lnet_kiov_t *kiov,
-unsigned int offset, unsigned int mlen, unsigned int rlen);
+struct iov_iter *to, unsigned int rlen);
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 9eb1db6..1b20ae8 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -648,7 +648,7 @@ static int kiblnd_map_tx(lnet_ni_t *ni, struct kib_tx *tx, 
struct kib_rdma_desc
 
 static int
 kiblnd_setup_rd_iov(lnet_ni_t *ni, struct kib_tx *tx, struct kib_rdma_desc *rd,
-   unsigned int niov, struct kvec *iov, int offset, int nob)
+   unsigned int niov, const struct kvec *iov, int offset, int 
nob)
 {
struct kib_net *net = ni->ni_data;
struct page *page;
@@ -705,7 +705,7 @@ kiblnd_setup_rd_iov(lnet_ni_t *ni, struct kib_tx *tx, 
struct kib_rdma_desc *rd,
 
 static int
 kiblnd_setup_rd_kiov(lnet_ni_t *ni, struct kib_tx *tx, struct kib_rdma_desc 
*rd,
-int nkiov, lnet_kiov_t *kiov, int offset, int nob)
+int nkiov, const lnet_kiov_t *kiov, int offset, int nob)
 {
struct kib_net *net = ni->ni_data;
struct scatterlist *sg;
@@ -1719,8 +1719,7 @@ kiblnd_reply(lnet_ni_t *ni, struct kib_rx *rx, lnet_msg_t 
*lntmsg)
 
 int
 kiblnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg, int delayed,
-   unsigned int niov, struct kvec *iov, lnet_kiov_t *kiov,
-   unsigned int offset, unsigned int mlen, unsigned int rlen)
+   struct iov_iter *to, unsigned int rlen)
 {
struct kib_rx *rx = private;
struct kib_msg *rxmsg = rx->rx_msg;
@@ -1730,10 +1729,9 @@ kiblnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t 
*lntmsg, int delayed,
int post_credit = IBLND_POSTRX_PEER_CREDIT;
int rc = 0;
 
-   LASSERT(mlen <= rlen);
+   LASSERT(iov_iter_count(to) <= rlen);
LASSERT(!in_interrupt());
/* Either all pages or all vaddrs */
-   LASSERT(!(kiov && iov));
 
switch (rxmsg->ibm_type) {
default:
@@ -1749,16 +1747,16 @@ kiblnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t 
*lntmsg, int delayed,
break;
}
 
-   if (kiov)
-   lnet_copy_flat2kiov(niov, kiov, offset,
+   if (to->type & ITER_BVEC)
+   lnet_copy_flat2kiov(to->nr_segs, to->bvec, 
to->iov_offset,
IBLND_MSG_SIZE, rxmsg,
offsetof(struct kib_msg, 
ibm_u.immediate.ibim_payload),
-   mlen);
+   iov_iter_count(to));
else
-   lnet_copy_flat2iov(niov, iov, offset,
+   lnet_copy_flat2iov(to->nr_segs, to->kvec, 
to->iov_offset,
  

[PATCH 02/13] ksocknal_lib_send_iov(): sendmsg doesn't bugger iovec...

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../lustre/lnet/klnds/socklnd/socklnd_lib.c| 38 ++
 1 file changed, 10 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
index 77bb29ff..8eb4a68 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
@@ -73,9 +73,9 @@ ksocknal_lib_zc_capable(struct ksock_conn *conn)
 int
 ksocknal_lib_send_iov(struct ksock_conn *conn, struct ksock_tx *tx)
 {
+   struct msghdr msg = {.msg_flags = MSG_DONTWAIT};
struct socket *sock = conn->ksnc_sock;
-   int nob;
-   int rc;
+   int nob, i;
 
if (*ksocknal_tunables.ksnd_enable_csum && /* checksum enabled */
conn->ksnc_proto == &ksocknal_protocol_v2x && /* V2.x connection  */
@@ -83,34 +83,16 @@ ksocknal_lib_send_iov(struct ksock_conn *conn, struct 
ksock_tx *tx)
!tx->tx_msg.ksm_csum)/* not checksummed  */
ksocknal_lib_csum_tx(tx);
 
-   /*
-* NB we can't trust socket ops to either consume our iovs
-* or leave them alone.
-*/
-   {
-#if SOCKNAL_SINGLE_FRAG_TX
-   struct kvec scratch;
-   struct kvec *scratchiov = &scratch;
-   unsigned int niov = 1;
-#else
-   struct kvec *scratchiov = conn->ksnc_scheduler->kss_scratch_iov;
-   unsigned int niov = tx->tx_niov;
-#endif
-   struct msghdr msg = {.msg_flags = MSG_DONTWAIT};
-   int i;
-
-   for (nob = i = 0; i < niov; i++) {
-   scratchiov[i] = tx->tx_iov[i];
-   nob += scratchiov[i].iov_len;
-   }
+   for (nob = i = 0; i < tx->tx_niov; i++)
+   nob += tx->tx_iov[i].iov_len;
 
-   if (!list_empty(&conn->ksnc_tx_queue) ||
-   nob < tx->tx_resid)
-   msg.msg_flags |= MSG_MORE;
+   if (!list_empty(&conn->ksnc_tx_queue) ||
+   nob < tx->tx_resid)
+   msg.msg_flags |= MSG_MORE;
 
-   rc = kernel_sendmsg(sock, &msg, scratchiov, niov, nob);
-   }
-   return rc;
+   iov_iter_kvec(&msg.msg_iter, WRITE | ITER_KVEC,
+ tx->tx_iov, tx->tx_niov, nob);
+   return sock_sendmsg(sock, &msg);
 }
 
 int
-- 
2.7.4

re

[Ali Saeed]

I need your assistance in executing a profitable project...

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Rob Clark]

On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli  wrote:
> Cc'ing lkml too.
>
> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>> Story time:
>> I was dreaming of a day were we can stop installing these headers,
>> thus making deprecation a bit easier process.
>> Yet after failing to convince Dave and Daniel on a number of occasions
>> I've accepted that those headers _are_ here to stay. And yes they
>> _are_ the UAPI, even though no applications are meant to use them but
>> the libdrm 'version'.
>> Thus any changes to the libdrm ones should be a mirror of the ones
>> here and libdrm should _not_ differ.
>
> Another day dream:
>
> Wouldn't it be nice if the uapi headers from Linux kernel would pass
> a simple quality check of compiling in userspace where they are meant to be
> used? Stand alone. Without magic tricks and additional libraries and their
> headers. Without glibc or any other libc implementation specific additions.
> The uapi headers define many parts of the Linux kernel API and ABI, and thus
> compiling them also without the 'official' GNU/Linux userspace libraries
> like glibc or libdrm does have some uses. For example API and ABI
> compatibility checks and API/ABI/system call fuzzers.
>
> Many headers required stdint.h types but Linux kernel headers do not
> define them in userspace, and then Linus has said that uapi headers
> should use the linux/types.h with double underscores. Thus my patches
> for fixing trivial compile errors turned into changing several stdint.h
> definitions to linux/types.h.

The problem is, for the most part, the driver specific gpu related
ioctl interfaces are not intended for general public consumption.
They have one consumer, ie. libdrm_$drivername (or perhaps mesa
directly).  They are complex interfaces, because GPUs are complex.
They are not intended to be used directly (or for the most part, even
indirectly) by random userspace applications.  And in fact the uapi
headers exported from kernel are not actually ever used.  (ie.
libdrm_$drivername uses it's own copy internally within libdrm.)

So Linus's argument against stdint types, as weak as it is, doesn't
even apply for gpu driver specific ioctls.

BR,
-R


> Yes, there have been some regressions in this work but to err is human.
> What is the actual problem and how can we (yes, including me) try to
> solve it?
>
> -Mikko
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel