Re: [PATCH] exit: move exit_task_namespaces() after exit_task_work()

2017-12-15 Thread Dmitry Vyukov
On Sat, Dec 16, 2017 at 1:00 AM, Cong Wang  wrote:
> syzbot reported we have a use-after-free when mqueue_evict_inode()
> is called on __cleanup_mnt() path, where the ipc ns is already
> freed by the previous exit_task_namespaces(). We can just move
> it after after exit_task_work() to avoid this use-after-free.

 How does that possibly work. (I haven't seen this syzbot report).

 Looking at the code we have get_ns_from_inode.  Which takes the mq_lock,
 sees if the pointer is NULL and takes a reference if it is non-NULL.

 Meanwhile put_ipc_ns calls mq_clear_sbinfo(ns) with the mq_lock held
 when the count drops to zero.

 Where is the race in that?

 The rest of mqueue_evict_inode uses the returned pointer and
 tests that the pointer is non-NULL before user it.

 So either szbot is giving you a bad report or there is a subtle race
 there I am not seeing.  The change below is not at all the proper way to
 fix a subtle race.

 Eric
>>>
>>> Cong, what was that report? Searching by
>>> "exit_task_work|exit_task_namespaces" there are too many of them:
>>> https://groups.google.com/forum/#!searchin/syzkaller-bugs/%22exit_task_work$7Cexit_task_namespaces%22%7Csort:date
>>>
>>> I can only say that syzbot does not make up reports. That's something
>>> that actually happened and was provoked by userspace.
>>
>>
>> Ah, found that bug:
>> https://groups.google.com/d/msg/syzkaller-bugs/1XBaqnPSXzs/VF-eCSPuCQAJ
>
> Yeah, and it is introduced by:
>
> http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/commit/?id=9c583773d036336176e9e50441890659bc4eeae8


If it's going to be discussed here, note that it was reported by
syzbot and requires "#syz fix" tag after fixing here:
https://groups.google.com/d/msg/syzkaller-bugs/1XBaqnPSXzs/jGDCMoz_AQAJ


Re: [PATCH] mm: Reduce memory bloat with THP

2017-12-15 Thread Nitin Gupta
On 12/15/17 2:01 AM, Kirill A. Shutemov wrote:
> On Thu, Dec 14, 2017 at 05:28:52PM -0800, Nitin Gupta wrote:
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index 751e97a..b2ec07b 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -508,6 +508,7 @@ static long madvise_dontneed_single_vma(struct 
>> vm_area_struct *vma,
>>  unsigned long start, unsigned long end)
>>  {
>>  zap_page_range(vma, start, end - start);
>> +vma->space_efficient = true;
>>  return 0;
>>  }
>>  
> 
> And this modifies vma without down_write(mmap_sem).
> 

I thought this function was always called with mmmap_sem write locked.
I will check again.

- Nitin




Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

2017-12-15 Thread Tetsuo Handa
On 2017/12/16 8:04, Andrew Morton wrote:
>> The implementation is steered toward an expensive slowpath, such as after
>> the oom reaper has grabbed mm->mmap_sem of a still alive oom victim.
> 
> some tweakage, please review.
> 
> From: Andrew Morton 
> Subject: 
> mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks-fix
> 
> make mm_has_blockable_invalidate_notifiers() return bool, use 
> rwsem_is_locked()
> 

> @@ -240,13 +240,13 @@ EXPORT_SYMBOL_GPL(__mmu_notifier_invalid
>   * Must be called while holding mm->mmap_sem for either read or write.
>   * The result is guaranteed to be valid until mm->mmap_sem is dropped.
>   */
> -int mm_has_blockable_invalidate_notifiers(struct mm_struct *mm)
> +bool mm_has_blockable_invalidate_notifiers(struct mm_struct *mm)
>  {
>   struct mmu_notifier *mn;
>   int id;
> - int ret = 0;
> + bool ret = false;
>  
> - WARN_ON_ONCE(down_write_trylock(>mmap_sem));
> + WARN_ON_ONCE(!rwsem_is_locked(>mmap_sem));
>  
>   if (!mm_has_notifiers(mm))
>   return ret;

rwsem_is_locked() test isn't equivalent with __mutex_owner() == current test, 
is it?
If rwsem_is_locked() returns true because somebody else has locked it, there is
no guarantee that current thread has locked it before calling this function.

down_write_trylock() test isn't equivalent with __mutex_owner() == current 
test, is it?
What if somebody else held it for read or write (the worst case is registration 
path),
down_write_trylock() will return false even if current thread has not locked it 
for
read or write.

I think this WARN_ON_ONCE() can not detect incorrect call to this function.


Re: [Question ]: Avoid kernel panic when killing an application if happen RAS page table error

2017-12-15 Thread gengdongjiu
On 2017/12/16 3:35, Matthew Wilcox wrote:
>> It's going to be complicated to do, I don't think its worth the effort.
> We can find a bit in struct page that we guarantee will only be set if
> this is allocated as a pagetable.  Bit 1 of the third union is currently
> available (compound_head is a pointer if bit 0 is set, so nothing is
> using bit 1).  We can put a pointer to the mm_struct in the same word.
> 
> Finding all the allocated pages will be the tricky bit.  We could put a
> list_head into struct page; perhaps in the same spot as page_deferred_list
> for tail pages.  Then we can link all the pagetables belonging to
> this mm together and tear them all down if any of them get an error.
> They'll repopulate on demand.  It won't be quick or scalable, but when
> the alternative is death, it looks relatively attractive.
Thanks for the comments, I will check it in detailed and investigate whether it 
is worth to do for it.
Thanks!

> 
> .
> 



Re: [PATCH] mm: Reduce memory bloat with THP

2017-12-15 Thread Nitin Gupta
On 12/15/17 2:00 AM, Kirill A. Shutemov wrote:
> On Thu, Dec 14, 2017 at 05:28:52PM -0800, Nitin Gupta wrote:
>> Currently, if the THP enabled policy is "always", or the mode
>> is "madvise" and a region is marked as MADV_HUGEPAGE, a hugepage
>> is allocated on a page fault if the pud or pmd is empty.  This
>> yields the best VA translation performance, but increases memory
>> consumption if some small page ranges within the huge page are
>> never accessed.
>>
>> An alternate behavior for such page faults is to install a
>> hugepage only when a region is actually found to be (almost)
>> fully mapped and active.  This is a compromise between
>> translation performance and memory consumption.  Currently there
>> is no way for an application to choose this compromise for the
>> page fault conditions above.
>>
>> With this change, when an application issues MADV_DONTNEED on a
>> memory region, the region is marked as "space-efficient". For
>> such regions, a hugepage is not immediately allocated on first
>> write.  Instead, it is left to the khugepaged thread to do
>> delayed hugepage promotion depending on whether the region is
>> actually mapped and active. When application issues
>> MADV_HUGEPAGE, the region is marked again as non-space-efficient
>> wherein hugepage is allocated on first touch.
> 
> I think this would be NAK. At least in this form.
> 
> What performance testing have you done? Any numbers?
> 

I wrote a throw-away code which mmaps 128G area and writes to a random
address in a loop. Together with writes, madvise(MADV_DONTNEED) are
issued at another random addresses. Writes are issued with 70%
probability and DONTNEED with 30%. With this test, I'm trying to emulate
workload of a large in-memory hash-table.

With the patch, I see that memory bloat is much less severe.
I've uploaded the test program with the memory usage plot here:

https://gist.github.com/nitingupta910/42ddf969e17556d74a14fbd84640ddb3

THP was set to 'always' mode in both cases but the result would be the
same if madvise mode was used instead.

> Making whole vma "space_efficient" just because somebody freed one page
> from it is just wrong. And there's no way back after this.
>

I'm using MADV_DONTNEED as a hint that although user wants to
transparently use hugepages but at the same time wants to be more
conservative with respect to memory usage. If a MADV_HUGEPAGE is issued
for a VMA range after any DONTNEEDs then the space_efficient bit is
again cleared, so we revert back to allocating hugepage on fault on
empty pud/pmd.

>>
>> Orabug: 26910556
> 
> Wat?
> 

It's oracle internal identifier used to track this work.

Thanks,
Nitin



Re: [PATCH 5/8] drm/sun4i: Add a driver for the display frontend

2017-12-15 Thread kbuild test robot
Hi Maxime,

I love your patch! Yet something to improve:

[auto build test ERROR on ]

url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
base:
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

Note: the 
linux-review/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
 HEAD c38c4ce4b14c4c68a9fde0cc35ead5b1c894776b builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_bind':
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:22: error: implicit declaration of 
>> function 'sun4i_backend_find_frontend'; did you mean 'sun4i_backend_bind'? 
>> [-Werror=implicit-function-declaration]
 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
 ^~~
 sun4i_backend_bind
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:20: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
   ^
   cc1: some warnings being treated as errors

vim +370 drivers/gpu/drm/sun4i/sun4i_backend.c

   346  
   347  static int sun4i_backend_bind(struct device *dev, struct device *master,
   348void *data)
   349  {
   350  struct platform_device *pdev = to_platform_device(dev);
   351  struct drm_device *drm = data;
   352  struct sun4i_drv *drv = drm->dev_private;
   353  struct sun4i_backend *backend;
   354  const struct sun4i_backend_quirks *quirks;
   355  struct resource *res;
   356  void __iomem *regs;
   357  int i, ret;
   358  
   359  backend = devm_kzalloc(dev, sizeof(*backend), GFP_KERNEL);
   360  if (!backend)
   361  return -ENOMEM;
   362  dev_set_drvdata(dev, backend);
   363  
   364  backend->engine.node = dev->of_node;
   365  backend->engine.ops = _backend_engine_ops;
   366  backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
   367  if (backend->engine.id < 0)
   368  return backend->engine.id;
   369  
 > 370  backend->frontend = sun4i_backend_find_frontend(drv, 
 > dev->of_node);
   371  if (IS_ERR(backend->frontend)) {
   372  dev_err(dev, "Couldn't find matching frontend, frontend 
features disabled\n");
   373  }
   374  
   375  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   376  regs = devm_ioremap_resource(dev, res);
   377  if (IS_ERR(regs))
   378  return PTR_ERR(regs);
   379  
   380  backend->reset = devm_reset_control_get(dev, NULL);
   381  if (IS_ERR(backend->reset)) {
   382  dev_err(dev, "Couldn't get our reset line\n");
   383  return PTR_ERR(backend->reset);
   384  }
   385  
   386  ret = reset_control_deassert(backend->reset);
   387  if (ret) {
   388  dev_err(dev, "Couldn't deassert our reset line\n");
   389  return ret;
   390  }
   391  
   392  backend->bus_clk = devm_clk_get(dev, "ahb");
   393  if (IS_ERR(backend->bus_clk)) {
   394  dev_err(dev, "Couldn't get the backend bus clock\n");
   395  ret = PTR_ERR(backend->bus_clk);
   396  goto err_assert_reset;
   397  }
   398  clk_prepare_enable(backend->bus_clk);
   399  
   400  backend->mod_clk = devm_clk_get(dev, "mod");
   401  if (IS_ERR(backend->mod_clk)) {
   402  dev_err(dev, "Couldn't get the backend module clock\n");
   403  ret = PTR_ERR(backend->mod_clk);
   404  goto err_disable_bus_clk;
   405  }
   406  clk_prepare_enable(backend->mod_clk);
   407  
   408  backend->ram_clk = devm_clk_get(dev, "ram");
   409  if (IS_ERR(backend->ram_clk)) {
   410  dev_err(dev, "Couldn't get the backend RAM clock\n");
   411  ret = PTR_ERR(backend->ram_clk);
   412  goto err_disable_mod_clk;
   413  }
   414  clk_prepare_enable(backend->ram_clk);
   415  
   416  if (of_device_is_compatible(dev->of_node,
   417  
"allwinner,sun8i-a33-display-backend")) {
   418  ret = sun4i_backend_init_sat(dev);
   419  if (ret) {
   420  

[PATCH 1/1] usb: xhci: dbc: Fix lockdep warning

2017-12-15 Thread Lu Baolu
The xHCI DbC implementation might enter a deadlock situation because
there is no sufficient protection against the shared data between
process and softirq contexts. This can lead to the following lockdep
warnings. This patch changes to use spin_{,un}lock_irq{save,restore}
to avoid potential deadlock.

[ 528.248084] 
[ 528.252914] WARNING: inconsistent lock state
[ 528.257756] 4.15.0-rc1+ #1630 Not tainted
[ 528.262305] 
[ 528.267145] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 528.273953] ksoftirqd/1/17 [HC0[0]:SC1[1]:HE0:SE0] takes:
[ 528.280075] (&(>port_lock)->rlock){+.?.}, at: [] 
dbc_rx_push+0x38/0x1c0
[ 528.290043] {SOFTIRQ-ON-W} state was registered at:
[ 528.295570] _raw_spin_lock+0x2f/0x40
[ 528.299818] dbc_write_complete+0x27/0xa0
[ 528.304458] xhci_dbc_giveback+0xd1/0x200
[ 528.309098] xhci_dbc_flush_endpoint_requests+0x50/0x70
[ 528.315116] xhci_dbc_handle_events+0x696/0x7b0
[ 528.320349] process_one_work+0x1ee/0x6e0
[ 528.324988] worker_thread+0x4a/0x430
[ 528.329236] kthread+0x13e/0x170
[ 528.332992] ret_from_fork+0x24/0x30
[ 528.337141] irq event stamp: 2861
[ 528.340897] hardirqs last enabled at (2860): [] 
tasklet_action+0x6a/0x250
[ 528.350460] hardirqs last disabled at (2861): [] 
_raw_spin_lock_irq+0xf/0x40
[ 528.360219] softirqs last enabled at (2852): [] 
__do_softirq+0x3dc/0x4f9
[ 528.369683] softirqs last disabled at (2857): [] 
run_ksoftirqd+0x1b/0x60
[ 528.379048]
[ 528.379048] other info that might help us debug this:
[ 528.386443] Possible unsafe locking scenario:
[ 528.386443]
[ 528.393150] CPU0
[ 528.395917] 
[ 528.398687] lock(&(>port_lock)->rlock);
[ 528.403821] 
[ 528.406786] lock(&(>port_lock)->rlock);
[ 528.412116]
[ 528.412116] *** DEADLOCK ***
[ 528.412116]
[ 528.418825] no locks held by ksoftirqd/1/17.
[ 528.423662]
[ 528.423662] stack backtrace:
[ 528.428598] CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.15.0-rc1+ #1630
[ 528.436387] Call Trace:
[ 528.439158] dump_stack+0x5e/0x8e
[ 528.442914] print_usage_bug+0x1fc/0x220
[ 528.447357] mark_lock+0x4db/0x5a0
[ 528.451210] __lock_acquire+0x726/0x1130
[ 528.455655] ? __lock_acquire+0x557/0x1130
[ 528.460296] lock_acquire+0xa2/0x200
[ 528.464347] ? dbc_rx_push+0x38/0x1c0
[ 528.468496] _raw_spin_lock_irq+0x35/0x40
[ 528.473038] ? dbc_rx_push+0x38/0x1c0
[ 528.477186] dbc_rx_push+0x38/0x1c0
[ 528.481139] tasklet_action+0x1d2/0x250
[ 528.485483] __do_softirq+0x1dc/0x4f9
[ 528.489630] run_ksoftirqd+0x1b/0x60
[ 528.493682] smpboot_thread_fn+0x179/0x270
[ 528.498324] kthread+0x13e/0x170
[ 528.501981] ? sort_range+0x20/0x20
[ 528.505933] ? kthread_delayed_work_timer_fn+0x80/0x80
[ 528.511755] ret_from_fork+0x24/0x30

Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci-dbgcap.c | 20 
 drivers/usb/host/xhci-dbgtty.c | 20 
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c
index 452df0f..c048d2a 100644
--- a/drivers/usb/host/xhci-dbgcap.c
+++ b/drivers/usb/host/xhci-dbgcap.c
@@ -328,13 +328,14 @@ dbc_ep_do_queue(struct dbc_ep *dep, struct dbc_request 
*req)
 int dbc_ep_queue(struct dbc_ep *dep, struct dbc_request *req,
 gfp_t gfp_flags)
 {
+   unsigned long   flags;
struct xhci_dbc *dbc = dep->dbc;
int ret = -ESHUTDOWN;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
if (dbc->state == DS_CONFIGURED)
ret = dbc_ep_do_queue(dep, req);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
mod_delayed_work(system_wq, >event_work, 0);
 
@@ -521,15 +522,16 @@ static void xhci_do_dbc_stop(struct xhci_hcd *xhci)
 static int xhci_dbc_start(struct xhci_hcd *xhci)
 {
int ret;
+   unsigned long   flags;
struct xhci_dbc *dbc = xhci->dbc;
 
WARN_ON(!dbc);
 
pm_runtime_get_sync(xhci_to_hcd(xhci)->self.controller);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ret = xhci_do_dbc_start(xhci);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
if (ret) {
pm_runtime_put(xhci_to_hcd(xhci)->self.controller);
@@ -541,6 +543,7 @@ static int xhci_dbc_start(struct xhci_hcd *xhci)
 
 static void xhci_dbc_stop(struct xhci_hcd *xhci)
 {
+   unsigned long   flags;
struct xhci_dbc *dbc = xhci->dbc;
struct dbc_port *port = >port;
 
@@ -551,9 +554,9 @@ static void xhci_dbc_stop(struct xhci_hcd *xhci)
if (port->registered)
xhci_dbc_tty_unregister_device(xhci);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
xhci_do_dbc_stop(xhci);
-   spin_unlock(>lock);
+   

Re: [PATCH PTI v3 10/10] x86/pti: Put the LDT in its own PGD if PTI is on

2017-12-15 Thread Andy Lutomirski
On Fri, Dec 15, 2017 at 2:54 PM, Thomas Gleixner  wrote:
> On Tue, 12 Dec 2017, Andy Lutomirski wrote:
>> +/* This is a multiple of PAGE_SIZE. */
>> +#define LDT_SLOT_STRIDE (LDT_ENTRIES * LDT_ENTRY_SIZE)
>> +
>> +static void *ldt_slot_va(int slot)
>
> How is that supposed to compile w/o warnings? Want's to be inline 

Good question.  But it does compile for me and apparently for the 0day
bot without warnings.  Fixed in my tree.

On Fri, Dec 15, 2017 at 4:39 PM, Thomas Gleixner  wrote:
> On Tue, 12 Dec 2017, Andy Lutomirski wrote:
>> +
>> + return 0;
>> +#else
>> + return -EINVAL;
>
> Errm. What's the point of that? Breaking non PTI?

That's embarrassing.

>
>>   new_ldt = alloc_ldt_struct(old_mm->context.ldt->nr_entries);
>>   if (!new_ldt) {
>> @@ -155,8 +266,17 @@ int init_new_context_ldt(struct task_struct *tsk, 
>> struct mm_struct *mm)
>>   memcpy(new_ldt->entries, old_mm->context.ldt->entries,
>>  new_ldt->nr_entries * LDT_ENTRY_SIZE);
>>   finalize_ldt_struct(new_ldt);
>> + retval = map_ldt_struct(mm, new_ldt, 0);
>> + if (retval)
>> + goto out_free;
>>
>>   mm->context.ldt = new_ldt;
>> + goto out_unlock;
>> +
>> +out_free:
>> + free_ldt_pgtables(mm);
>> + free_ldt_struct(new_ldt);
>> + return retval;
>
> Leaks old_mm->context_lock;
>

Indeed.

I'm going to go test the failure paths better tomorrow.  Meanwhile,
all three issues should be fixed in my tree.


Re: [PATCH v2 0/4] Utilization estimation (util_est) for FAIR tasks

2017-12-15 Thread Mike Galbraith
On Fri, 2017-12-15 at 21:23 +0100, Mike Galbraith wrote:
> 
> Point: if you think it's OK to serialize these firefox threads, would
> you still think so if those were kernel threads instead?  Serializing
> your kernel is a clear fail, but unpinned kthreads can be stacked up
> just as effectively as those browser threads are, eat needless wakeup
> latency and pass it on.

FWIW, somewhat cheezy example of that below.

(later, /me returns to [apparently endless] squabble w. PELT/SIS;)

bonnie in nfs mount of own box competing with 7 hogs:
 

  Task  |   Runtime ms  | Switches | Average delay ms | Maximum 
delay ms | Sum delay ms | Maximum delay at  |
 

  kworker/3:0:29|630.078 ms |89669 | avg:0.011 ms | max:  
102.340 ms | sum:  962.919 ms | max at:310.501277 |
  kworker/3:1H:464  |   1179.868 ms |   101944 | avg:0.005 ms | max:  
102.232 ms | sum:  480.915 ms | max at:310.501273 |
  kswapd0:78|   2662.230 ms | 1661 | avg:0.128 ms | max:   
93.935 ms | sum:  213.258 ms | max at:310.503419 |
  nfsd:2039 |   3257.143 ms |78448 | avg:0.112 ms | max:   
86.039 ms | sum: 8795.767 ms | max at:258.847140 |
  nfsd:2038 |   3185.730 ms |76253 | avg:0.113 ms | max:   
78.348 ms | sum: 8580.676 ms | max at:258.831370 |
  nfsd:2042 |   3256.554 ms |81423 | avg:0.110 ms | max:   
74.941 ms | sum: 8929.015 ms | max at:288.397203 |
  nfsd:2040 |   3314.826 ms |80396 | avg:0.105 ms | max:   
51.039 ms | sum: 8471.816 ms | max at:363.870078 |
  nfsd:2036 |   3058.867 ms |70460 | avg:0.115 ms | max:   
44.629 ms | sum: 8092.319 ms | max at:250.074253 |
  nfsd:2037 |   3113.592 ms |74276 | avg:0.115 ms | max:   
43.294 ms | sum: 8556.110 ms | max at:310.443722 |
  konsole:4013  |402.509 ms |  894 | avg:0.148 ms | max:   
38.129 ms | sum:  132.050 ms | max at:332.156495 |
  haveged:497   | 11.831 ms | 1224 | avg:0.104 ms | max:   
37.575 ms | sum:  127.706 ms | max at:350.669645 |
  nfsd:2043 |   3316.033 ms |78303 | avg:0.115 ms | max:   
36.511 ms | sum: 8995.138 ms | max at:248.576108 |
  nfsd:2035 |   3064.108 ms |67413 | avg:0.115 ms | max:   
28.221 ms | sum: 7746.306 ms | max at:313.785682 |
  bash:7022 |  0.342 ms |1 | avg:   22.959 ms | max:   
22.959 ms | sum:   22.959 ms | max at:262.258960 |
  kworker/u16:4:354 |   2073.383 ms | 1550 | avg:0.050 ms | max:   
21.203 ms | sum:   77.185 ms | max at:332.220678 |
  kworker/4:3:6975  |   1189.868 ms |   115776 | avg:0.018 ms | max:   
20.856 ms | sum: 2071.894 ms | max at:348.142757 |
  kworker/2:4:6981  |335.895 ms |26617 | avg:0.023 ms | max:   
20.726 ms | sum:  625.102 ms | max at:248.522083 |
  bash:7021 |  0.517 ms |2 | avg:   10.363 ms | max:   
20.726 ms | sum:   20.727 ms | max at:262.235708 |
  ksoftirqd/2:22| 65.718 ms |  998 | avg:0.138 ms | max:   
19.072 ms | sum:  137.827 ms | max at:332.221676 |
  kworker/7:3:6969  |625.724 ms |84153 | avg:0.010 ms | max:   
18.838 ms | sum:  876.603 ms | max at:264.188983 |
  bonnie:6965   |  79637.998 ms |35434 | avg:0.007 ms | max:   
18.719 ms | sum:  256.748 ms | max at:331.299867 | 


Re: [PATCH v2 net-next 2/4] net: tracepoint: replace tcp_set_state tracepoint with sock_set_state tracepoint

2017-12-15 Thread Yafang Shao
2017-12-16 6:47 GMT+08:00 Song Liu :
>
>> On Dec 15, 2017, at 9:56 AM, Yafang Shao  wrote:
>>
>> As sk_state is a common field for struct sock, so the state
>> transition should not be a TCP specific feature.
>> So I rename tcp_set_state tracepoint to sock_set_state tracepoint with
>> some minor changes and move it into file trace/events/sock.h.
>>
>> Two helpers are introduced to trace sk_state transition
>>- void sk_state_store(struct sock *sk, int state);
>>- void sk_set_state(struct sock *sk, int state);
>> As trace header should not be included in other header files,
>> so they are defined in sock.c.
>>
>> The protocol such as SCTP maybe compiled as a ko, hence export
>> sk_set_state().
>>
>> Signed-off-by: Yafang Shao 
>> ---
>> include/net/sock.h  |  15 +-
>> include/trace/events/sock.h | 106 
>> 
>> include/trace/events/tcp.h  |  91 --
>> net/core/sock.c |  13 +
>> net/ipv4/inet_connection_sock.c |   4 +-
>> net/ipv4/inet_hashtables.c  |   2 +-
>> net/ipv4/tcp.c  |   4 --
>> 7 files changed, 124 insertions(+), 111 deletions(-)
>>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index 9a90472..988ce82 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -2344,19 +2344,8 @@ static inline int sk_state_load(const struct sock *sk)
>>   return smp_load_acquire(>sk_state);
>> }
>>
>> -/**
>> - * sk_state_store - update sk->sk_state
>> - * @sk: socket pointer
>> - * @newstate: new state
>> - *
>> - * Paired with sk_state_load(). Should be used in contexts where
>> - * state change might impact lockless readers.
>> - */
>> -static inline void sk_state_store(struct sock *sk, int newstate)
>> -{
>> - smp_store_release(>sk_state, newstate);
>> -}
>> -
>> +void sk_state_store(struct sock *sk, int newstate);
>> +void sk_set_state(struct sock *sk, int state);
>> void sock_enable_timestamp(struct sock *sk, int flag);
>> int sock_get_timestamp(struct sock *, struct timeval __user *);
>> int sock_get_timestampns(struct sock *, struct timespec __user *);
>> diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
>> index ec4dade..61977e5 100644
>> --- a/include/trace/events/sock.h
>> +++ b/include/trace/events/sock.h
>> @@ -6,7 +6,49 @@
>> #define _TRACE_SOCK_H
>>
>> #include 
>> +#include 
>> #include 
>> +#include 
>> +#include 
>> +
>> +#define inet_protocol_names  \
>> + EM(IPPROTO_TCP) \
>> + EM(IPPROTO_DCCP)\
>> + EMe(IPPROTO_SCTP)
>> +
>> +#define tcp_state_names  \
>> + EM(TCP_ESTABLISHED) \
>> + EM(TCP_SYN_SENT)\
>> + EM(TCP_SYN_RECV)\
>> + EM(TCP_FIN_WAIT1)  \
>> + EM(TCP_FIN_WAIT2)  \
>> + EM(TCP_TIME_WAIT)  \
>> + EM(TCP_CLOSE)  \
>> + EM(TCP_CLOSE_WAIT)\
>> + EM(TCP_LAST_ACK)\
>> + EM(TCP_LISTEN)\
>> + EM(TCP_CLOSING)  \
>> + EMe(TCP_NEW_SYN_RECV)
>
> Please keep these backslashes aligned.
>

OK
This is because  I made it aligned with TAB in my original code.


>> +/* enums need to be exported to user space */
>> +#undef EM
>> +#undef EMe
>> +#define EM(a)   TRACE_DEFINE_ENUM(a);
>> +#define EMe(a)  TRACE_DEFINE_ENUM(a);
>> +
>> +inet_protocol_names
>> +tcp_state_names
>> +
>> +#undef EM
>> +#undef EMe
>> +#define EM(a)   { a, #a },
>> +#define EMe(a)  { a, #a }
>> +
>> +#define show_inet_protocol_name(val) \
>> + __print_symbolic(val, inet_protocol_names)
>> +
>> +#define show_tcp_state_name(val) \
>> + __print_symbolic(val, tcp_state_names)
>>
>> TRACE_EVENT(sock_rcvqueue_full,
>>
>> @@ -63,6 +105,70 @@
>>   __entry->rmem_alloc)
>> );
>>
>> +TRACE_EVENT(sock_set_state,
>> +
>> + TP_PROTO(const struct sock *sk, const int oldstate, const int 
>> newstate),
>> +
>> + TP_ARGS(sk, oldstate, newstate),
>> +
>> + TP_STRUCT__entry(
>> + __field(const void *, skaddr)
>> + __field(int, oldstate)
>> + __field(int, newstate)
>> + __field(__u16, sport)
>> + __field(__u16, dport)
>> + __field(__u8, protocol)
>> + __array(__u8, saddr, 4)
>> + __array(__u8, daddr, 4)
>> + __array(__u8, saddr_v6, 16)
>> + __array(__u8, daddr_v6, 16)
>> + ),
>> +
>> + TP_fast_assign(
>> + struct inet_sock *inet = inet_sk(sk);
>> + struct in6_addr *pin6;
>> + __be32 *p32;
>> +
>> + __entry->skaddr = sk;
>> + __entry->oldstate = oldstate;
>> + __entry->newstate = 

Re: jsm_tty: Deletion of a null pointer check in two functions?

2017-12-15 Thread SF Markus Elfring
> Thanks for the fix.

Thanks for your positive feedback.


> I was on vacation - but now seeing all the analysis made here,

I assume that special communication settings could trigger
corresponding consequences for the discussed source code adjustment.


> if "ch" can't be NULL then please go ahead and remove the check =)

Would you dare to convert this request into a concrete patch?

Regards,
Markus


Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

2017-12-15 Thread Tetsuo Handa
On 2017/12/16 1:25, Michal Hocko wrote:
>>  struct mmu_notifier_ops {
>> +/*
>> + * Flags to specify behavior of callbacks for this MMU notifier.
>> + * Used to determine which context an operation may be called.
>> + *
>> + * MMU_INVALIDATE_DOES_NOT_BLOCK: invalidate_{start,end} does not
>> + *block
>> + */
>> +int flags;
> 
> This should be more specific IMHO. What do you think about the following
> wording?
> 
> invalidate_{start,end,range} doesn't block on any locks which depend
> directly or indirectly (via lock chain or resources e.g. worker context)
> on a memory allocation.

I disagree. It needlessly complicates validating the correctness.

What if the invalidate_{start,end} calls schedule_timeout_idle(10 * HZ) ?
schedule_timeout_idle() will not block on any locks which depend directly or
indirectly on a memory allocation, but we are already blocking other memory
allocating threads at mutex_trylock(_lock) in __alloc_pages_may_oom().

This is essentially same with "sleeping forever due to 
schedule_timeout_killable(1) by
SCHED_IDLE thread with oom_lock held" versus "looping due to 
mutex_trylock(_lock)
by all other allocating threads" lockup problem. The OOM reaper does not want 
to get
blocked for so long.


Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

2017-12-15 Thread Benson Leung
On Fri, Dec 01, 2017 at 11:49:54AM -0800, Gwendal Grignou wrote:
> Checked against 7412f0a0d90ee6ddbad4cde794f88f1489422f3a (CHROMIUM:
> platform/chrome: Support MKBP protocol over ACPI)
> Reviewed-by: Gwendal Grignou 
> 

Thanks Gwendal.

(ps, don't top post.)

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature


Re: [PATCH v5 2/3] platform/chrome: cros_ec_lpc: Add support for Google Glimmer

2017-12-15 Thread Benson Leung
Hi Thierry,

On Fri, Dec 01, 2017 at 02:42:22PM +0100, Thierry Escande wrote:
> This patch adds device information to the DMI table of the cros_ec_lpc
> driver for Google Glimmer devices. Since Google BIOS does not enumerate
> devices in the LPC bus, the cros_ec_lpc driver checks for system
> compatibility and registers the cros_ec device itself.
> 
> Signed-off-by: Thierry Escande 

Applied. Thanks.

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 0b26a09..4a2fc55 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -365,6 +365,13 @@ static const struct dmi_system_id 
> cros_ec_lpc_dmi_table[] __initconst = {
>   DMI_MATCH(DMI_PRODUCT_NAME, "Peppy"),
>   },
>   },
> + {
> + /* x86-glimmer, the Lenovo Thinkpad Yoga 11e. */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Glimmer"),
> + },
> + },
>   { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(dmi, cros_ec_lpc_dmi_table);
> -- 
> 2.7.4
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature


Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

2017-12-15 Thread Benson Leung
Hi Thierry,

On Fri, Dec 01, 2017 at 02:42:21PM +0100, Thierry Escande wrote:
> From: Enric Balletbo i Serra 
> 
> Commit 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for
> GOOG004 ACPI device") added support when the firmware reports the ACPI
> device, there are some firmwares though that doesn't report this device
> but have it. In such cases we need to instantiate the driver explicitly
> if it is not instantiated through ACPI.
> 
> Fixes: 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for GOOG004 
> ACPI device")
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
> Signed-off-by: Thierry Escande 

Applied for v4.16.

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 1baf720..0b26a09 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -35,6 +35,9 @@
>  #define DRV_NAME "cros_ec_lpcs"
>  #define ACPI_DRV_NAME "GOOG0004"
>  
> +/* True if ACPI device is present */
> +static bool cros_ec_lpc_acpi_device_found;
> +
>  static int ec_response_timed_out(void)
>  {
>   unsigned long one_second = jiffies + HZ;
> @@ -396,9 +399,21 @@ static struct platform_driver cros_ec_lpc_driver = {
>   .remove = cros_ec_lpc_remove,
>  };
>  
> +static struct platform_device cros_ec_lpc_device = {
> + .name = DRV_NAME
> +};
> +
> +static acpi_status cros_ec_lpc_parse_device(acpi_handle handle, u32 level,
> + void *context, void **retval)
> +{
> + *(bool *)context = true;
> + return AE_CTRL_TERMINATE;
> +}
> +
>  static int __init cros_ec_lpc_init(void)
>  {
>   int ret;
> + acpi_status status;
>  
>   if (!dmi_check_system(cros_ec_lpc_dmi_table)) {
>   pr_err(DRV_NAME ": unsupported system.\n");
> @@ -415,11 +430,28 @@ static int __init cros_ec_lpc_init(void)
>   return ret;
>   }
>  
> - return 0;
> + status = acpi_get_devices(ACPI_DRV_NAME, cros_ec_lpc_parse_device,
> +   _ec_lpc_acpi_device_found, NULL);
> + if (ACPI_FAILURE(status))
> + pr_warn(DRV_NAME ": Looking for %s failed\n", ACPI_DRV_NAME);
> +
> + if (!cros_ec_lpc_acpi_device_found) {
> + /* Register the device, and it'll get hooked up automatically */
> + ret = platform_device_register(_ec_lpc_device);
> + if (ret) {
> + pr_err(DRV_NAME ": can't register device: %d\n", ret);
> + platform_driver_unregister(_ec_lpc_driver);
> + cros_ec_lpc_reg_destroy();
> + }
> + }
> +
> + return ret;
>  }
>  
>  static void __exit cros_ec_lpc_exit(void)
>  {
> + if (!cros_ec_lpc_acpi_device_found)
> + platform_device_unregister(_ec_lpc_device);
>   platform_driver_unregister(_ec_lpc_driver);
>   cros_ec_lpc_reg_destroy();
>  }
> -- 
> 2.7.4
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature


Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

2017-12-15 Thread Benson Leung
Hi Thierry,

Sorry for the delay in processing these.

On Fri, Dec 01, 2017 at 02:42:21PM +0100, Thierry Escande wrote:
> From: Enric Balletbo i Serra 
> 
> Commit 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for
> GOOG004 ACPI device") added support when the firmware reports the ACPI
> device, there are some firmwares though that doesn't report this device
> but have it. In such cases we need to instantiate the driver explicitly
> if it is not instantiated through ACPI.
> 
> Fixes: 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for GOOG004 
> ACPI device")
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
> Signed-off-by: Thierry Escande 

Applied for v4.16.

Thanks,
Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature


Re: [PATCH v19 3/7] xbitmap: add more operations

2017-12-15 Thread Tetsuo Handa
Matthew Wilcox wrote:
> On Sat, Dec 16, 2017 at 01:31:24PM +0900, Tetsuo Handa wrote:
> > Michael S. Tsirkin wrote:
> > > On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > > > My understanding is that virtio-balloon wants to handle sparsely 
> > > > spreaded
> > > > unsigned long values (which is PATCH 4/7) and wants to find all chunks 
> > > > of
> > > > consecutive "1" bits efficiently. Therefore, I guess that holding the 
> > > > values
> > > > in ascending order at store time is faster than sorting the values at 
> > > > read
> > > > time.
> 
> What makes you think that the radix tree (also xbitmap, also idr) doesn't
> sort the values at store time?

I don't care whether the radix tree sorts the values at store time.
What I care is how to read stored values in ascending order with less overhead.

Existing users are too much optimized and difficult to understand for new
comers. I appreciate if there are simple sample codes which explain how to
use library functions and which can be compiled/tested in userspace.
Your "- look at ->head, see it is NULL, return false." answer did not
give me any useful information.

> 
> > I'm asking whether we really need to invent a new library module (i.e.
> > PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.
> > 
> > What virtio-balloon needs is ability to
> > 
> >   (1) record any integer value in [0, ULONG_MAX] range
> > 
> >   (2) fetch all recorded values, with consecutive values combined in
> >   min,max (or start,count) form for efficiently
> > 
> > and I wonder whether we need to invent complete API set which
> > Matthew Wilcox and Wei Wang are planning for generic purpose.
> 
> The xbitmap absolutely has that ability.

Current patches are too tricky to review.
When will all corner cases be closed?

>   And making it generic code
> means more people see it, use it, debug it, optimise it.

I'm not objecting against generic code. But trying to optimize it can
enbug it, like using exception path keeps me difficult to review whether
the implementation is correct. I'm suggesting to start xbitmap without
exception path, and I haven't seen a version without exception path.

>   I originally
> wrote the implementation for bcache, when Kent was complaining we didn't
> have such a thing.  His needs weren't as complex as Wei's, which is why
> I hadn't implemented everything that Wei needed.
> 

Unless current xbitmap patches become clear, virtio-balloon changes won't
be able to be get merged. We are repeating this series without closing
many bugs. We can start virtio-balloon changes with a stub code which
provides (1) and (2), and that's my version.


Re: [PATCH 4.9 00/27] 4.9.70-stable review

2017-12-15 Thread Naresh Kamboju
On 15 December 2017 at 15:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.70 release.
> There are 27 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Dec 17 09:22:42 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.70-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64 and x86_64.

Note:
We do not have arm64 hikey board results due to the changes required
from the firmware update. Hikey board is under maintenance.

Newly added selftests/net/reuseport_bpf FAILED in full run on x86_64
and beagle board x15 and the independent test execution resulted as PASS.
For the internal investigation bug reported.
https://bugs.linaro.org/show_bug.cgi?id=3502#c4

Summary


kernel: 4.9.70-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: cc35c65be8bb29a0282724447bc694353125a35d
git describe: v4.9.69-28-gcc35c65be8bb
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.69-28-gcc35c65be8bb

No regressions (compared to build v4.9.69-22-g9ba613a08872)

Boards, architectures and test suites:
-
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 40, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 985, skip: 121
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - fail: 1, pass: 36, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - fail: 1, pass: 54, skip: 23
* libhugetlbfs - pass: 89, skip: 1
* ltp-cap_bounds-tests - pass: 1,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 10,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 


Re: [PATCH] dt-bindings: chosen: Document linux,initrd-{start,end}

2017-12-15 Thread Jonathan Neuschäfer
On Fri, Dec 15, 2017 at 03:01:47PM -0600, Rob Herring wrote:
> On Sat, Dec 09, 2017 at 04:33:02PM +0100, Jonathan Neuschäfer wrote:
> > These properties have been in use for a very long time (at least since
> > 2005), but were never documented in chosen.txt.
> > 
> > Signed-off-by: Jonathan Neuschäfer 
> > ---
> >  Documentation/devicetree/bindings/chosen.txt | 15 +++
> >  1 file changed, 15 insertions(+)
> 
> Applied.

Thanks.

> I'm inclined to say to document these in the DT spec, but I'm assuming 
> there was some reason why they weren't put into the spec (ePAPR at the 
> time) originally.

I don't know about the history of this, but I think if and when these
properties were specified in DTSpec, they should get a non-linux-specific
name, such as initrd-start/initrd-end, and a compatibility fallback to
linux,initrd-* (similar to stdout-path and phandle).


Jonathan Neuschäfer


signature.asc
Description: PGP signature


Re: [PATCH 4.4 000/105] 4.4.106-stable review

2017-12-15 Thread Naresh Kamboju
On 15 December 2017 at 15:13, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.4.106 release.
> There are 105 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Dec 17 09:22:39 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.106-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
We do not have arm64 hikey board results due to the changes required
from the firmware update. Hikey board is under maintenance.

readahead02 failed once in 3 iterations of full syscall run which is
intermittently failure on ARM64 juno running 4.4.106-rc1.
Resubmitted test looped for 20 Iterations out of which 7 times TCONF
and 13 times PASS.

Test log failed instance:
  readahead020  TINFO  :  read_testfile(0) used cache: 65468 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 32592 kB
  readahead020  TWARN  :  readahead02.c:351: using less cache than expected

Test pass log:
  readahead020  TINFO  :  read_testfile(0) used cache: 65568 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 65268 kB
  readahead023  TPASS  :  using cache as expected

Test CONF log:
  readahead020  TINFO  :  read_testfile(0) used cache: 65376 kB
  readahead020  TINFO  :  read_testfile(1) used cache: 65564 kB
  readahead023  TCONF  :  readahead02.c:354: Page cache on your
system is too small to hold whole testfile.

Bug reported for the investigation.
https://bugs.linaro.org/show_bug.cgi?id=3539

Summary


kernel: 4.4.106-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 67065bd41780929c2b8406ac3dd5356e83cd2d19
git describe: v4.4.105-106-g67065bd41780
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.105-106-g67065bd41780

No regressions (compared to build v4.4.105-108-g894d367e5d93)


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - fail: 2, pass: 980, skip: 124
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 29
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1035, skip: 67
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 44, skip: 32
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 956, skip: 164
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 


Re: [PATCH 4.14 00/52] 4.14.7-stable review

2017-12-15 Thread Naresh Kamboju
On 15 December 2017 at 15:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.7 release.
> There are 52 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Dec 17 09:22:47 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.7-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
We do not have arm64 hikey board results due to the changes required
from the firmware update.
Hikey board is under maintenance.

Newly added selftests/net/reuseport_bpf FAILED in full run on x86_64 and
the independent test execution resulted as PASS.
For the internal investigation bug reported.
https://bugs.linaro.org/show_bug.cgi?id=3502#c4

Summary

kernel: 4.14.7-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: a89be024745d1205f14c2a598b32d26a1224361f
git describe: v4.14.6-53-ga89be024745d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.6-53-ga89be024745d

No regressions (compared to build v4.14.6-39-g190d0d404c61)

Boards, architectures and test suites:
-
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 45, skip: 17
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 985, skip: 121
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 41, skip: 20
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - fail: 1, pass: 60, skip: 16
* libhugetlbfs - pass: 89, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 1,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 1,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 1,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 11,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 


Re: [PATCH v2 10/10] arm64: dts: qcom: msm8916: add nodes for i2c1, i2c3, i2c5

2017-12-15 Thread Bjorn Andersson
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Signed-off-by: Damien Riegel 

Please move pinconf settings into the structure in
apq8016-sbc-soc-pins.dtsi (didn't see this when commenting on the
previous patch).

Apart from this, the patch looks good.

Regards,
Bjorn

> ---
> Changes in v2:
>  - Reworded commit title
>  - Changed size to 0x500
> 
>  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 48 
> ++
>  arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 42 ++
>  arch/arm64/boot/dts/qcom/msm8916.dtsi  | 45 
>  3 files changed, 135 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 53c1ddd281a4..11305015ba0b 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -630,6 +630,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio2", "gpio3";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio2", "gpio3";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio6", "gpio7";
> @@ -646,6 +662,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio10", "gpio11";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio10", "gpio11";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio14", "gpio15";
> @@ -662,6 +694,22 @@
>   };
>  };
>  
> +_default {
> + pinconf {
> + pins = "gpio18", "gpio19";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +_sleep {
> + pinconf {
> + pins = "gpio18", "gpio19";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
>  _default {
>   pinconf {
>   pins = "gpio22", "gpio23";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> index 7704ddecb6c4..44e68860fc8c 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> @@ -152,6 +152,20 @@
>   };
>   };
>  
> + i2c1_default: i2c1_default {
> + pinmux {
> + function = "blsp_i2c1";
> + pins = "gpio2", "gpio3";
> + };
> + };
> +
> + i2c1_sleep: i2c1_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio2", "gpio3";
> + };
> + };
> +
>   i2c2_default: i2c2_default {
>   pinmux {
>   function = "blsp_i2c2";
> @@ -166,6 +180,20 @@
>   };
>   };
>  
> + i2c3_default: i2c3_default {
> + pinmux {
> + function = "blsp_i2c3";
> + pins = "gpio10", "gpio11";
> + };
> + };
> +
> + i2c3_sleep: i2c3_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio10", "gpio11";
> + };
> + };
> +
>   i2c4_default: i2c4_default {
>   pinmux {
>   function = "blsp_i2c4";
> @@ -180,6 +208,20 @@
>   };
>   };
>  
> + i2c5_default: i2c5_default {
> + pinmux {
> + function = "blsp_i2c5";
> + pins = "gpio18", "gpio19";
> + };
> + };
> +
> + i2c5_sleep: i2c5_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio18", "gpio19";
> + };
> + };
> +
>   i2c6_default: i2c6_default {
>   pinmux {
>   function = "blsp_i2c6";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index ac440f287633..7478c7337995 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -455,6 +455,21 @@
>   status = "disabled";
>   };
>  
> + blsp_i2c1: i2c@78b5000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x078b5000 0x500>;
> + interrupts = ;
> + clocks = < GCC_BLSP1_AHB_CLK>,
> +  < GCC_BLSP1_QUP1_I2C_APPS_CLK>;
> + clock-names = "iface", "core";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_default>;
> + pinctrl-1 = <_sleep>;
> +

Re: [PATCH v2 09/10] arm64: dts: qcom: msm8916: normalize I2C and SPI nodes

2017-12-15 Thread Bjorn Andersson
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> The QUP core can be used either for I2C or SPI, so the same IP is mapped
> by a driver or the other. SPI bindings use a leading 0 for the start
> address and a size of 0x600, I2C bindings don't have the leading 0 and
> have a size 0x1000.
> 
> To make them more similar, add the leading 0 to I2C bindings and changes
> the size to 0x500 for all of them, as this is the actual size of these
> blocks. Also align the second entry of the clocks array.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn


Re: [PATCH v2 07/10] arm64: dts: qcom: msm8916: drop remaining unused pinconfs

2017-12-15 Thread Bjorn Andersson
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> This commit drops pin configs that cannot be moved to board files as
> no boards use them.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn


Re: [PATCH v2 08/10] arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings

2017-12-15 Thread Bjorn Andersson
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Nodes relative to the first sdhc node were interlaced with node of the
> second sdhc. Move sdhc2_cd_pin with its siblings to prevent that. Also
> rename the grouping node from sdhc2_cd_pin to pmx_sdc2_cd_pin, as
> "pmx_sdc" is the prefix used by other nodes.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Bjorn Andersson 

Regards,
Bjorn


Re: [PATCH v2 06/10] arm64: dts: qcom: msm8916: move pinconfs to board files

2017-12-15 Thread Bjorn Andersson
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Following a suggestion from Bjorn Andersson [1], this commit moves
> electrical specifications which were defined in mms8916-pins.dtsi to
> board files, where they actually belong.
> 
> Pinmuxing is kept in the platform file because there are no alternative
> pins on which all these functions could be routed, so this part is
> indeed common to all boards using this SoC.
> 
> [1] https://www.spinics.net/lists/devicetree/msg201764.html
> 
> Signed-off-by: Damien Riegel 
> Suggested-by: Bjorn Andersson 

I like the move, but I would prefer that you mimic the base structure,
rather than just appending properties based on labels.

Regards,
Bjorn


Re: [PATCH v2 05/10] arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically

2017-12-15 Thread Bjorn Andersson
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> Also, it was using whitespaces for indentation on some lines, fix that
> while moving it.
> 
> Signed-off-by: Damien Riegel 

Rather than extending single nodes like this I would prefer that we
bring in the associated pmic node, by this we avoid just having a huge
flat list of nodes. I.e. that we make this:

_1 {
codec@f000 {
status = "okay";
clocks = < GCC_CODEC_DIGCODEC_CLK>;
clock-names = "mclk";
qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
};
};

Regards,
Bjorn


Re: [PATCH] platform/chrome: cros_ec_lpc: remove redundant pointer request

2017-12-15 Thread Benson Leung
Hi Colin,

On Tue, Oct 31, 2017 at 10:27:47AM +, Colin King wrote:
> From: Colin Ian King 
> 
> Pointer request is being assigned but never used, so remove it. Cleans
> up the clang warning:
> 
> drivers/platform/chrome/cros_ec_lpc.c:68:2: warning: Value stored to
> 'request' is never read
> 
> Signed-off-by: Colin Ian King 

Thanks for the patch. Sorry for the delay. Applied for v4.16.

Thanks,
Benson

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 1baf720faf69..87e9747d229a 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -54,7 +54,6 @@ static int ec_response_timed_out(void)
>  static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>   struct cros_ec_command *msg)
>  {
> - struct ec_host_request *request;
>   struct ec_host_response response;
>   u8 sum;
>   int ret = 0;
> @@ -65,8 +64,6 @@ static int cros_ec_pkt_xfer_lpc(struct cros_ec_device *ec,
>   /* Write buffer */
>   cros_ec_lpc_write_bytes(EC_LPC_ADDR_HOST_PACKET, ret, ec->dout);
>  
> - request = (struct ec_host_request *)ec->dout;
> -
>   /* Here we go */
>   sum = EC_COMMAND_PROTOCOL_3;
>   cros_ec_lpc_write_bytes(EC_LPC_ADDR_HOST_CMD, 1, );
> -- 
> 2.14.1
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature


Re: [PATCH v2 04/10] arm64: dts: qcom: msm8916: drop unused board-specific nodes

2017-12-15 Thread Bjorn Andersson
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:

> These nodes reserve and configure some pins as GPIOs. They are not
> generic pinctrls, they actually belong to board files but they are not
> used by any other node, so just drop them altogether.
> 
> Signed-off-by: Damien Riegel 

Reviewed-by: Bjorn Andersson 

Let's introduce them back into the db410c when we define a client.

Regards,
Bjorn


Re: [PATCH] cros_ec: fix nul-termination for firmware build info

2017-12-15 Thread Benson Leung
Hi Arnd,

On Mon, Dec 04, 2017 at 03:49:48PM +0100, Arnd Bergmann wrote:
> As gcc-8 reports, we zero out the wrong byte:
> 
> drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
> drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 
> 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
> 
> This changes the code back to what it did before changing to a
> zero-length array structure.
> 
> Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
> Signed-off-by: Arnd Bergmann 

Applied. Thanks!

Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature


Re: [PATCH v19 3/7] xbitmap: add more operations

2017-12-15 Thread Matthew Wilcox
On Sat, Dec 16, 2017 at 01:31:24PM +0900, Tetsuo Handa wrote:
> Michael S. Tsirkin wrote:
> > On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > > My understanding is that virtio-balloon wants to handle sparsely spreaded
> > > unsigned long values (which is PATCH 4/7) and wants to find all chunks of
> > > consecutive "1" bits efficiently. Therefore, I guess that holding the 
> > > values
> > > in ascending order at store time is faster than sorting the values at read
> > > time.

What makes you think that the radix tree (also xbitmap, also idr) doesn't
sort the values at store time?

> I'm asking whether we really need to invent a new library module (i.e.
> PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.
> 
> What virtio-balloon needs is ability to
> 
>   (1) record any integer value in [0, ULONG_MAX] range
> 
>   (2) fetch all recorded values, with consecutive values combined in
>   min,max (or start,count) form for efficiently
> 
> and I wonder whether we need to invent complete API set which
> Matthew Wilcox and Wei Wang are planning for generic purpose.

The xbitmap absolutely has that ability.  And making it generic code
means more people see it, use it, debug it, optimise it.  I originally
wrote the implementation for bcache, when Kent was complaining we didn't
have such a thing.  His needs weren't as complex as Wei's, which is why
I hadn't implemented everything that Wei needed.


Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

2017-12-15 Thread Brian Norris
+ RTC maintainers

On Fri, Dec 15, 2017 at 08:57:50PM -0800, Brian Norris wrote:
> On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote:
> > From: Stephen Barber 
> > 
> > On platforms with a Chrome OS EC, the EC can function as a simple RTC.
> > Add a basic driver with this functionality.
> > 
> > Signed-off-by: Stephen Barber 
> > Signed-off-by: Enric Balletbo i Serra 
> > Acked-by: Alexandre Belloni 
> > Acked-by: Benson Leung 
> > ---
> >  drivers/rtc/Kconfig   |  10 ++
> >  drivers/rtc/Makefile  |   1 +
> >  drivers/rtc/rtc-cros-ec.c | 413 
> > ++
> >  3 files changed, 424 insertions(+)
> >  create mode 100644 drivers/rtc/rtc-cros-ec.c
> 
> This isn't quite super-helpful without the CrOS-EC / MFD additions to
> actually create the device, but it's a good start, and I don't see any
> problems with it. Any reason this isn't merged? Are the RTC maintainers
> intendending to merge this, or should Lee (for the MFD header)? I
> thought normally Lee deferred to other subsystem maintainers when the
> only "MFD" stuff was a simple header change (such as in patch 1).
> 
> Anyway, FWIW:
> 
> Reviewed-by: Brian Norris 
> Tested-by: Brian Norris 


Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

2017-12-15 Thread Brian Norris
On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote:
> From: Stephen Barber 
> 
> On platforms with a Chrome OS EC, the EC can function as a simple RTC.
> Add a basic driver with this functionality.
> 
> Signed-off-by: Stephen Barber 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Alexandre Belloni 
> Acked-by: Benson Leung 
> ---
>  drivers/rtc/Kconfig   |  10 ++
>  drivers/rtc/Makefile  |   1 +
>  drivers/rtc/rtc-cros-ec.c | 413 
> ++
>  3 files changed, 424 insertions(+)
>  create mode 100644 drivers/rtc/rtc-cros-ec.c

This isn't quite super-helpful without the CrOS-EC / MFD additions to
actually create the device, but it's a good start, and I don't see any
problems with it. Any reason this isn't merged? Are the RTC maintainers
intendending to merge this, or should Lee (for the MFD header)? I
thought normally Lee deferred to other subsystem maintainers when the
only "MFD" stuff was a simple header change (such as in patch 1).

Anyway, FWIW:

Reviewed-by: Brian Norris 
Tested-by: Brian Norris 


Re: [PATCH v4 1/2] mfd: cros_ec: Introduce RTC commands and events definitions.

2017-12-15 Thread Brian Norris
Hi,

On Fri, Nov 10, 2017 at 10:55:52PM +0100, Enric Balletbo i Serra wrote:
> From: Stephen Barber 
> 
> The EC can function as a simple RT, this patch adds the RTC related
> definitions needed by the rtc-cros-ec driver.
> 
> Signed-off-by: Stephen Barber 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Lee Jones 
> Acked-by: Benson Leung 

Reviewed-by: Brian Norris 

I guess this is waiting to get merged by an RTC maintainer, since it's a
dependency for the RTC driver in patch 2? Alessandro or Alexandre, any
thoughts?

Brian

> ---
>  include/linux/mfd/cros_ec_commands.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index 2b16e95..c6046a2 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -291,6 +291,9 @@ enum host_event_code {
>   /* EC desires to change state of host-controlled USB mux */
>   EC_HOST_EVENT_USB_MUX = 28,
>  
> + /* EC RTC event occurred */
> + EC_HOST_EVENT_RTC = 26,
> +
>   /*
>* The high bit of the event mask is not used as a host event code.  If
>* it reads back as set, then the entire event mask should be
> @@ -799,6 +802,8 @@ enum ec_feature_code {
>   EC_FEATURE_USB_MUX = 23,
>   /* Motion Sensor code has an internal software FIFO */
>   EC_FEATURE_MOTION_SENSE_FIFO = 24,
> + /* EC has RTC feature that can be controlled by host commands */
> + EC_FEATURE_RTC = 27,
>  };
>  
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -1709,6 +1714,9 @@ struct ec_response_rtc {
>  #define EC_CMD_RTC_SET_VALUE 0x46
>  #define EC_CMD_RTC_SET_ALARM 0x47
>  
> +/* Pass as param to SET_ALARM to clear the current alarm */
> +#define EC_RTC_ALARM_CLEAR 0
> +
>  
> /*/
>  /* Port80 log access */
>  


Re: [PATCH v3 00/11] ASoC: fsl_ssi: Clean up - coding style level

2017-12-15 Thread Timur Tabi

On 12/13/17 5:18 PM, Nicolin Chen wrote:

Additionally, in order to fix/work-around hardware bugs and design
flaws, the driver made a lot of compromise so now its program flow
looks very complicated and it's getting hard to maintain or update.

So I am going to clean up the driver on both coding style level and
program flow level.


I'm okay with everything except patch #3.


Re: KASAN: use-after-free Write in irq_bypass_register_consumer

2017-12-15 Thread Tianyu Lan
I reproduced the issue. Will have a look.

-- 
Best regards
Tianyu Lan

2017-12-15 18:14 GMT+08:00 syzbot
:
> syzkaller has found reproducer for the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> ==
> BUG: KASAN: use-after-free in __list_add include/linux/list.h:64 [inline]
> BUG: KASAN: use-after-free in list_add include/linux/list.h:79 [inline]
> BUG: KASAN: use-after-free in irq_bypass_register_consumer+0x4b4/0x500
> virt/lib/irqbypass.c:217
> Write of size 8 at addr 8801cdf51180 by task syzkaller436086/15031
>
> CPU: 1 PID: 15031 Comm: syzkaller436086 Not tainted 4.15.0-rc2-mm1+ #39
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:435
>  __list_add include/linux/list.h:64 [inline]
>  list_add include/linux/list.h:79 [inline]
>  irq_bypass_register_consumer+0x4b4/0x500 virt/lib/irqbypass.c:217
>  kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:417 [inline]
>  kvm_irqfd+0x137f/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
>  kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x44d379
> RSP: 002b:7fc5ff9a9d08 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 7fc5ff9aa700 RCX: 0044d379
> RDX: 20080fe0 RSI: 4020ae76 RDI: 0005
> RBP: 007ff900 R08: 7fc5ff9aa700 R09: 7fc5ff9aa700
> R10: 7fc5ff9aa700 R11: 0246 R12: 
> R13: 007ff8ff R14: 7fc5ff9aa9c0 R15: 
>
> Allocated by task 15031:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3614
>  kmalloc include/linux/slab.h:516 [inline]
>  kzalloc include/linux/slab.h:705 [inline]
>  kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:296 [inline]
>  kvm_irqfd+0x16c/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
>  kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>  SYSC_ioctl fs/ioctl.c:701 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>  entry_SYSCALL_64_fastpath+0x1f/0x96
>
> Freed by task 1402:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3492 [inline]
>  kfree+0xca/0x250 mm/slab.c:3807
>  irqfd_shutdown+0x13c/0x1a0 arch/x86/kvm/../../../virt/kvm/eventfd.c:148
>  process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
>
> The buggy address belongs to the object at 8801cdf51000
>  which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 384 bytes inside of
>  512-byte region [8801cdf51000, 8801cdf51200)
> The buggy address belongs to the page:
> page:d08a0d63 count:1 mapcount:0 mapping:d54c7be6 index:0x0
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801cdf51000  00010006
> raw: ea00073a7660 ea000737f3a0 8801dac00940 
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
>  8801cdf51080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8801cdf51100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> 8801cdf51180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
>^
>  8801cdf51200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  8801cdf51280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
>


Re: [GIT PULL] Immutable branch between MFD and Platform due for the v4.16 merge window

2017-12-15 Thread Benson Leung
Hi Lee,

On Fri, Dec 15, 2017 at 10:48:20AM +, Lee Jones wrote:
> Enjoy!
> 
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
> 
>   Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-platform-v4.16
> 
> for you to fetch changes up to 5e0115581bbc367c7958bf5ab8c511b808558533:
> 
>   cros_ec: Move cros_ec_dev module to drivers/mfd (2017-12-15 10:46:06 +)
> 
> 
> Immutable branch between MFD and Platform due for the v4.16 merge window
> 
> 
> Thierry Escande (2):
>   cros_ec: Split cros_ec_devs module
>   cros_ec: Move cros_ec_dev module to drivers/mfd
> 
>  drivers/mfd/Kconfig| 10 ++
>  drivers/mfd/Makefile   |  1 +
>  drivers/mfd/cros_ec.c  |  4 ++--
>  drivers/{platform/chrome => mfd}/cros_ec_dev.c |  8 +---
>  drivers/{platform/chrome => mfd}/cros_ec_dev.h |  0
>  drivers/platform/chrome/Kconfig| 10 ++
>  drivers/platform/chrome/Makefile   |  7 +++
>  drivers/platform/chrome/cros_ec_debugfs.c  |  5 ++---
>  drivers/platform/chrome/cros_ec_debugfs.h  | 27 
> --
>  drivers/platform/chrome/cros_ec_lightbar.c |  6 --
>  drivers/platform/chrome/cros_ec_sysfs.c|  5 +++--
>  drivers/platform/chrome/cros_ec_vbc.c  |  1 +
>  include/linux/mfd/cros_ec.h|  4 
>  13 files changed, 37 insertions(+), 51 deletions(-)
>  rename drivers/{platform/chrome => mfd}/cros_ec_dev.c (99%)
>  rename drivers/{platform/chrome => mfd}/cros_ec_dev.h (100%)
>  delete mode 100644 drivers/platform/chrome/cros_ec_debugfs.h
>  
> -- 
> Lee Jones
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog


Excellent. Pulled. Thank you so much!

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature


Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

2017-12-15 Thread gengdongjiu
[...]
>
>> + case ESR_ELx_AET_UER:   /* The error has not been propagated */
>> + /*
>> +  * Userspace only handle the guest SError Interrupt(SEI) if the
>> +  * error has not been propagated
>> +  */
>> + run->exit_reason = KVM_EXIT_EXCEPTION;
>> + run->ex.exception = ESR_ELx_EC_SERROR;
>> + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>> + return 0;
>
> We should not pass RAS notifications to user space. The kernel either handles
> them, or it panics(). User space shouldn't even know if the kernel supports 
> RAS

For the  ESR_ELx_AET_UER(Recoverable error), let us see its definition
below, which get from [0]

The state of the PE is Recoverable if all of the following are true:
— The error has not been silently propagated.
— The error has not been architecturally consumed by the PE. (The PE
architectural state is not infected.)
— The exception is precise and PE can recover execution from the
preferred return address of the exception, if software locates and
repairs the error.
The PE cannot make correct progress without either consuming the error
or otherwise making the error unrecoverable. The error remains latent
in the system.
If software cannot locate and repair the error, either the application
or the VM, or both, must be isolated by software.

so we can see the  exception is precise and PE can recover execution
from the preferred return address of the exception, so let guest
handling it is
better, for example, if it is guest application RAS error, we can kill
the guest application instead of panic whole OS; if it is guest kernel
RAS error, guest will panic.
Host does not know which application of guest has error, so host can
not handle it, panic OS is not a good choice for the Recoverable
error.

[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf


> until it gets an MCEERR signal.

user space will detect whether kernel support RAS before handing it.

>
> You're making your firmware-first notification an EL3->EL0 signal, bypassing 
> the OS.
>
> If we get a RAS SError and there are no CPER records or values in the ERR 
> nodes,
> we should panic as it looks like the CPU/firmware is broken. (spurious RAS 
> errors)


>
>
>> + default:
>> + /*
>> +  * Until now, the CPU supports RAS and SEI is fatal, or host
>> +  * does not support to handle the SError.
>> +  */
>> + panic("This Asynchronous SError interrupt is dangerous, 
>> panic");
>> + }
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
>>   * proper exit to userspace.
>
>
>
> James
> ___
> kvmarm mailing list
> kvm...@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

2017-12-15 Thread Timur Tabi

On 12/13/17 5:18 PM, Nicolin Chen wrote:

-* We are running on a SoC which does not support online SSI
-* reconfiguration, so we have to enable all necessary flags at once
-* even if we do not use them later (capture and playback configuration)
+* Online configuration is not supported
+* Enable or Disable all necessary bits at once


This is an example of a bad change, IMHO.  The original was written in 
elegant prose.  The new version is just two short sentences.


[PATCH] ext4: delayed inode update for the consistency of file size after a crash

2017-12-15 Thread Seongbae Son
> > 1. Current file offset of fileA is 14 KB. An application appends 2 KB data 
> > to
> > fileA by executing a write() system call. At this time, the file size in
> > the ext4_inode of fileA is updated to 16 KB by ext4_da_write_end().
> > 2. Current file offset of fileB is 14 KB. An application appends 2 KB data 
> > to
> > fileB by executing a write() system call. At this time, the file size in
> > the ext4_inode of fileB is updated to 16 KB by ext4_da_write_end().
> > 3. A fsync(fileB) is called before the kworker thread runs. At this time,
> > the application thread transfers the data block of fileB to storage and
> > wakes up the JBD2. Then, JBD2 writes the ext4_inodes of fileA and fileB in
> > the running transaction to the journal area. The ext4_inode of fileA in
> > the journal area has the file size, 16 KB, even though the data block of
> > fileA has not been written to storage.
> > 4. Assume that a system crash occurs. The EXT4 recovery module recovers
> > the inodes of fileA and fileB. The recovered inode of fileA has the updated
> > file size, 16 KB, even though the data of fileA has not been made durable.
> > The data block of fileA between 14 KB and 16 KB is seen as zeros.

> There's nothing wrong with this.  The user space application called
> fsync on fileB, and *not* on fileA.  Therefore, there is absolutely no
> guarantee that fileA's data contents are valid.
> 
> Consider the exact same thing will happen if the application had
> written data to fileA at offsets 6k to 8k.  If those offsets were
> previously zero, then after the crash, those offsets *might* still be
> zero after the crash, *unless* the application had first called
> fsync() or fdatasync() first.

> > Details can be found as follows.
> >
> > Son et al. "Guaranteeing the Metadata Update Atomicity in EXT4 Filesystem”,
> > In Proc. of APSYS 2017, Mumbai, India

> This is behind a paywall, so I can't access it.  I am sorry I wasn't
> on the program committee, or I would have pointed this out while the
> paper was being reviewed.

Hello Ted,

Thanks for your quick answer.
I am sorry about that. I could not think about the paywall.

> The problem with providing more guarantees than what is strictly
> provided for by POSIX is that it degrades the performance of the file
> system.  It can also promote application writes to depend on semantics
> which are non-portable, which can cause problems when they try to run
> that progam on other operating systems or other file systems.

I have performed the above scenario to xfs, btrfs, f2fs, and zfs.
As the test result, all of the four file systems does not have the problem
that fileA in which fsync() was not executed has the wrong file size
after a system crash. So, I think, the portability of applications might be
okay even though EXT4 guarantees the consistency between the file size and
the data blocks of the file that fsync() is not executed after a system crash.

Many thanks,

Seongbae Son.


Re: [PATCH v19 3/7] xbitmap: add more operations

2017-12-15 Thread Tetsuo Handa
Michael S. Tsirkin wrote:
> On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote:
> > My understanding is that virtio-balloon wants to handle sparsely spreaded
> > unsigned long values (which is PATCH 4/7) and wants to find all chunks of
> > consecutive "1" bits efficiently. Therefore, I guess that holding the values
> > in ascending order at store time is faster than sorting the values at read
> > time.
> 
> Are you asking why is a bitmap used here, as opposed to a tree?

No. I'm OK with "segments using trees" + "offsets using bitmaps".

>  It's
> not just store versus read. There's also the issue that memory can get
> highly fragmented, if it is, the number of 1s is potentially very high.
> A bitmap can use as little as 1 bit per value, it is hard to beat in
> this respect.
> 

I'm asking whether we really need to invent a new library module (i.e.
PATCH 1/7 + PATCH 2/7 + PATCH 3/7) for virtio-balloon compared to mine.

What virtio-balloon needs is ability to

  (1) record any integer value in [0, ULONG_MAX] range

  (2) fetch all recorded values, with consecutive values combined in
  min,max (or start,count) form for efficiently

and I wonder whether we need to invent complete API set which
Matthew Wilcox and Wei Wang are planning for generic purpose.


[PATCH V2] x86/efi: fix kernel param add_efi_memmap regression

2017-12-15 Thread Dave Young
'add_efi_memmap' is an early param, but do_add_efi_memmap() has no
chance to run because the code path is before parse_early_param().
I believe it worked when the param was introduced but probably later
some other changes caused the wrong order and nobody noticed it.

Move efi_memblock_x86_reserve_range() after parse_early_param()
to fix it.

Signed-off-by: Dave Young 
---
 arch/x86/kernel/setup.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -906,9 +906,6 @@ void __init setup_arch(char **cmdline_p)
set_bit(EFI_BOOT, );
set_bit(EFI_64BIT, );
}
-
-   if (efi_enabled(EFI_BOOT))
-   efi_memblock_x86_reserve_range();
 #endif
 
x86_init.oem.arch_setup();
@@ -962,6 +959,8 @@ void __init setup_arch(char **cmdline_p)
 
parse_early_param();
 
+   if (efi_enabled(EFI_BOOT))
+   efi_memblock_x86_reserve_range();
 #ifdef CONFIG_MEMORY_HOTPLUG
/*
 * Memory used by the kernel cannot be hot-removed because Linux


Re: [PATCH 01/19] fs: new API for handling inode->i_version

2017-12-15 Thread NeilBrown
On Wed, Dec 13 2017, Jeff Layton wrote:

> On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote:
>> On Wed, Dec 13 2017, Jeff Layton wrote:
>> 
>> > +/*
>> > + * The change attribute (i_version) is mandated by NFSv4 and is mostly for
>> > + * knfsd, but is also used for other purposes (e.g. IMA). The i_version 
>> > must
>> > + * appear different to observers if there was a change to the inode's 
>> > data or
>> > + * metadata since it was last queried.
>> > + *
>> > + * It should be considered an opaque value by observers. If it remains 
>> > the same
>> > + * since it was last checked, then nothing has changed in the inode. If 
>> > it's
>> > + * different then something has changed. Observers cannot infer anything 
>> > about
>> > + * the nature or magnitude of the changes from the value, only that the 
>> > inode
>> > + * has changed in some fashion.
>> 
>> I agree that it "should be" considered opaque, but I have a suspicion
>> that NFSv4 doesn't consider it opaque.
>> There is something about write delegations and the server performing a
>> GETATTR callback to the delegated client so that it can answer GETATTR
>> from other clients without recalling the delegation.
>> 
>> Specifically section "10.4.3 Handling of CB_GETATTR" of RFC5661 contains
>> the text:
>> 
>>o  The client will create a value greater than c that will be used
>>   for communicating that modified data is held at the client.  Let
>>   this value be represented by d.
>> 
>> "c" here is a 'change' attribute.
>> 
>> Then:
>> 
>>While the change attribute is opaque to the client in the sense that
>>it has no idea what units of time, if any, the server is counting
>>change with, it is not opaque in that the client has to treat it as
>>an unsigned integer, and the server has to be able to see the results
>>of the client's changes to that integer.  Therefore, the server MUST
>>encode the change attribute in network order when sending it to the
>>client.  The client MUST decode it from network order to its native
>>order when receiving it, and the client MUST encode it in network
>>order when sending it to the server.  For this reason, change is
>>defined as an unsigned integer rather than an opaque array of bytes.
>> 
>> This all suggests that nfsd needs to be certain that "incrementing" the
>> change id will produce a new changeid, which has not been used before,
>> and also suggests that nfsd needs to be able to control the changeid
>> stored after writes that result from a delegation being returned.
>> 
>> I'd just like to say that this is one of the most annoying dumb features
>> of NFSv4, because it is trivial to fix and I suggested a fix before
>> NFSv4.0 was finalized.  Grumble.
>> 
>> Otherwise the patch set looks good.  I haven't gone over the code
>> closely, the but approach is spot-on.
>
> I don't think we have to do that. There are really only two states with
> a client holding a write delegation, as far as the server is concerned.
> Either:
>
> a) the client has done no writes to the file, in which case it'll return
> the same i_version that the server has when issued a CB_GETATTR
>
> ...or...
>
> b) it has written to the file while holding the delegation, in which
> case it'll return a different CB_GETATTR to the server
>
> The simplest thing for the server to do is to just increment the change
> attribute _once_ when it gets back a CB_GETATTR with a different change
> attr than it has.
>
> That's sufficient to tell another client issuing a a GETATTR that the
> file has changed without needing to recall the delegation.
>
> Prior to the delegation being returned, the client will send at least
> one WRITE RPC, and that's enough to ensure that the the next stat will
> see the thing increase.

"increment" and "increase" are not words that mean anything for an
"opaque value".
NFSd is, presumably, an "observer" of i_version (as it isn't the
filesytem that controls it), so your text says it must treat i_version as
opaque.  That means it cannot detect an "increase" (only a change), and
it certainly cannot "increment" the value.

I think you need to allow observers to treat i_version as a 64 bit number
which will monotonically increase.  Any change to the file will result
in an increment of at least '1'.

Thanks,
NeilBrown


signature.asc
Description: PGP signature


[PATCH for-4.15] ASoC: rt5514-spi: only enable wakeup when fully initialized

2017-12-15 Thread Brian Norris
If an rt5514-spi device is probed but the platform hasn't linked it in,
we might never fully request the SPI IRQ, nor configure the rt5514 DSP,
but we still might try to enable the SPI IRQ (enable_irq_wake()). This
is bad, and among other things, can cause the interrupt to trigger every
time we try to suspend the system (e.g., because the interrupt trigger
setting was never set properly).

Instead of setting our wakeup capabilities in the SPI driver probe
routine, let's wait until we've actually requested the IRQ.

Fixes issues seen on the "kevin" Chromebook (Samsung Chromebook Plus).

Fixes: 58f1c07d23cd ("ASoC: rt5514: Voice wakeup support.")
Signed-off-by: Brian Norris 
---
The patch that introduced the wakeup was in 4.15-rc1. I think this qualifies as
a bugfix, and should probably go into 4.15.

Other relevant patches that are useful, and fix similar (or the same) issues:

https://patchwork.kernel.org/patch/10067725/
[PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

https://patchwork.kernel.org/patch/10116761/
[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

 sound/soc/codecs/rt5514-spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/rt5514-spi.c b/sound/soc/codecs/rt5514-spi.c
index 9255afcf2c3a..48e4b9002caf 100644
--- a/sound/soc/codecs/rt5514-spi.c
+++ b/sound/soc/codecs/rt5514-spi.c
@@ -289,6 +289,8 @@ static int rt5514_spi_pcm_probe(struct snd_soc_platform 
*platform)
dev_err(_spi->dev,
"%s Failed to reguest IRQ: %d\n", __func__,
ret);
+   else
+   device_init_wakeup(rt5514_dsp->dev, true);
}
 
return 0;
@@ -456,8 +458,6 @@ static int rt5514_spi_probe(struct spi_device *spi)
return ret;
}
 
-   device_init_wakeup(>dev, true);
-
return 0;
 }
 
-- 
2.15.1.504.g5279b80103-goog



[PATCH v3] staging: ion: Fix ion_cma_heap allocations

2017-12-15 Thread John Stultz
In trying to add support for drm_hwcomposer to HiKey,
I've needed to utilize the ION CMA heap, and I've noticed
problems with allocations on newer kernels failing.

It seems back with 204f672255c2 ("ion: Use CMA APIs directly"),
the ion_cma_heap code was modified to use the CMA API, but
kept the arguments as buffer lengths rather then number of pages.

This results in errors as we don't have enough pages in CMA to
satisfy the exaggerated requests.

This patch converts the ion_cma_heap CMA API usage to properly
request pages.

It also fixes a minor issue in the allocation where in the error
path, the cma_release is called with the buffer->size value which
hasn't yet been set.

Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Benjamin Gaignard 
Cc: Archit Taneja 
Cc: Greg KH 
Cc: Daniel Vetter 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Amit Pundir 
Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
Acked-by: Laura Abbott 
Signed-off-by: John Stultz 
---
v2: Fix build errors when CONFIG_CMA_ALIGNMENT isn't defined
v3: Make CMA heap depend on DMA_CMA instead of just CMA to address
the undefined CONFIG_CMA_ALIGNMENT issue.

 drivers/staging/android/ion/Kconfig|  2 +-
 drivers/staging/android/ion/ion_cma_heap.c | 15 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index a517b2d..8f64941 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -37,7 +37,7 @@ config ION_CHUNK_HEAP
 
 config ION_CMA_HEAP
bool "Ion CMA heap support"
-   depends on ION && CMA
+   depends on ION && DMA_CMA
help
  Choose this option to enable CMA heaps with Ion. This heap is backed
  by the Contiguous Memory Allocator (CMA). If your system has these
diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index dd5545d..86196ff 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -39,9 +39,15 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
struct sg_table *table;
struct page *pages;
+   unsigned long size = PAGE_ALIGN(len);
+   unsigned long nr_pages = size >> PAGE_SHIFT;
+   unsigned long align = get_order(size);
int ret;
 
-   pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
+   if (align > CONFIG_CMA_ALIGNMENT)
+   align = CONFIG_CMA_ALIGNMENT;
+
+   pages = cma_alloc(cma_heap->cma, nr_pages, align, GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -53,7 +59,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (ret)
goto free_mem;
 
-   sg_set_page(table->sgl, pages, len, 0);
+   sg_set_page(table->sgl, pages, size, 0);
 
buffer->priv_virt = pages;
buffer->sg_table = table;
@@ -62,7 +68,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
 free_mem:
kfree(table);
 err:
-   cma_release(cma_heap->cma, pages, buffer->size);
+   cma_release(cma_heap->cma, pages, nr_pages);
return -ENOMEM;
 }
 
@@ -70,9 +76,10 @@ static void ion_cma_free(struct ion_buffer *buffer)
 {
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
struct page *pages = buffer->priv_virt;
+   unsigned long nr_pages = PAGE_ALIGN(buffer->size) >> PAGE_SHIFT;
 
/* release memory */
-   cma_release(cma_heap->cma, pages, buffer->size);
+   cma_release(cma_heap->cma, pages, nr_pages);
/* release sg table */
sg_free_table(buffer->sg_table);
kfree(buffer->sg_table);
-- 
2.7.4



[PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller

2017-12-15 Thread Yixun Lan
Add DT info for the stmmac ethernet MAC which found in
the Amlogic's Meson-AXG SoC, also describe the ethernet
pinctrl & clock information here.

Reviewed-by: Neil Armstrong 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d288d4724ae3..dea1bc31b4de 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "amlogic,meson-axg";
@@ -155,6 +156,19 @@
};
};
 
+   ethmac: ethernet@ff3f {
+   compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+   reg = <0x0 0xff3f 0x0 0x1
+   0x0 0xff634540 0x0 0x8>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < CLKID_ETH>,
+< CLKID_FCLK_DIV2>,
+< CLKID_MPLL2>;
+   clock-names = "stmmaceth", "clkin0", "clkin1";
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
reg = <0x0 0xffc01000 0 0x1000>,
@@ -215,6 +229,46 @@
gpio-ranges = <_periphs 0 0 86>;
};
 
+   eth_rgmii_x_pins: eth-x-rgmii {
+   mux {
+   groups = "eth_mdio_x",
+  "eth_mdc_x",
+  "eth_rgmii_rx_clk_x",
+  "eth_rx_dv_x",
+  "eth_rxd0_x",
+  "eth_rxd1_x",
+  "eth_rxd2_rgmii",
+  "eth_rxd3_rgmii",
+  "eth_rgmii_tx_clk",
+  "eth_txen_x",
+  "eth_txd0_x",
+  "eth_txd1_x",
+  "eth_txd2_rgmii",
+  "eth_txd3_rgmii";
+   function = "eth";
+   };
+   };
+
+   eth_rgmii_y_pins: eth-y-rgmii {
+   mux {
+   groups = "eth_mdio_y",
+  "eth_mdc_y",
+  "eth_rgmii_rx_clk_y",
+  "eth_rx_dv_y",
+  "eth_rxd0_y",
+  "eth_rxd1_y",
+  "eth_rxd2_rgmii",
+  "eth_rxd3_rgmii",
+  "eth_rgmii_tx_clk",
+  "eth_txen_y",
+  "eth_txd0_y",
+  "eth_txd1_y",
+  "eth_txd2_rgmii",
+  "eth_txd3_rgmii";
+   function = "eth";
+   };
+   };
+
pwm_a_a_pins: pwm_a_a {
mux {
groups = "pwm_a_a";
-- 
2.15.1



[PATCH v4 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board

2017-12-15 Thread Yixun Lan
This is tested in the S400 dev board which use a RTL8211F PHY,
and the pins connect to the 'eth_rgmii_y_pins' group.

Reviewed-by: Neil Armstrong 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts 
b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..8932654f5090 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -17,6 +17,13 @@
};
 };
 
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+   pinctrl-0 = <_rgmii_y_pins>;
+   pinctrl-names = "default";
+};
+
 _AO {
status = "okay";
 };
-- 
2.15.1



[PATCH v4 0/2] Add ethernet support for Meson-AXG SoC

2017-12-15 Thread Yixun Lan
This series try to add support for the ethernet MAC controller
found in Meson-AXG SoC, and also enable it in the S400 board.

Hi Kevin:
  You still need to at least merge the clock patch[3] in order to
compile the DTS, or just merge the tag from meson-clock's tree[6]
- the tag is 'meson-clk-for-v4.16-2', since the clock part already
taken there.


Changes in v4 since [5]:
 - rebase to kevin's v4.16/dt64
 - fix order

Changes in v3 since [4]:
 - put clock DT info in soc.dtsi
 - separate DT for 'add support for the controller' vs 'enable in board'

Changes in v2 since [1]:
 - rebase to kevin's v4.16/dt64 branch
 - add Neil's Reviewed-by
 - move clock info to board.dts instead of in soc.dtsi
 - drop "meson-axg-dwmac" compatible string, since we didn't use this
   we could re-add it later when we really need.
 - note: to make ethernet work properly,it depend on clock & pinctrl[2],
   to compile the DTS, the patch [3] is required.
   the code part will be taken via clock & pinctrl subsystem tree.

[5]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005783.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005784.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005785.html

[4]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005768.html

[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html

[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html

[3]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html

[6] git://github.com/BayLibre/clk-meson.git

Yixun Lan (2):
  ARM64: dts: meson-axg: add ethernet mac controller
  ARM64: dts: meson-axg: enable ethernet for A113D S400 board

 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts |  7 
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++
 2 files changed, 61 insertions(+)

-- 
2.15.1



Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

2017-12-15 Thread gengdongjiu
Hi James,

On 2017/12/16 2:52, James Morse wrote:
>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown 
>> below:
>>
>> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
>> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>>
>> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify 
>> trigger method, which all
>>
>> not involve _trigger_ an SError.
> It's a policy choice. How does your virtual CPU notify RAS errors to its 
> virtual
> software? You could use SError for SIGBUS_MCEERR_AR, it depends on what type 
> of
> CPU you are trying to emulate.
> 
> I'd suggest using NOTIFY_SEA for SIGBUS_MCEERR_AR as it avoids problems where
> the guest doesn't take the SError immediately, instead tries to re-execute the
I agree it is better to use NOTIFY_SEA for SIGBUS_MCEERR_AR in this case.

> code KVM has unmapped from stage2 because its corrupt. (You could detect this
> happening in Qemu and try something else)For something else, using NOTIFY_SEI 
> for SIGBUS_MCEERR_AR? At current implementation,
It seems only have this case that "KVM has unmapped from stage2", do you thing 
we still have something else?

> 
> 
> Synchronous/asynchronous external abort matters to the CPU, but once the error
> has been notified to software the reasons for this distinction disappear. Once
> the error has been handled, all trace of this distinction is gone.
> 
> CPER records only describe component failures. You are trying to re-create 
> some
> state that disappeared with one of the firmware-first abstractions. Trying to
> re-create this information isn't worth the effort as the distinction doesn't
> matter to linux, only to the CPU.
> 
> 
>> so there is no chance for Qemu to trigger the SError when gets the 
>> SIGBUS_MCEERR_A{O,R}.
> You mean there is no reason for Qemu to trigger an SError when it gets a 
> signal
> from the kernel.
> 
> The reasons the CPU might have to generate an SError don't apply to linux and
> KVM user space. User-space will never get a signal for an uncontained error, 
> we
> will always panic(). We can't give user-space a signal for imprecise 
> exceptions,
> as it can't return from the signal. The classes of error that are left are
> covered by polled/irq and NOTIFY_SEA.
> 
> Qemu can decide to generate RAS SErrors for SIGBUS_MCEERR_AR if it really 
> wants
> to, (but I don't think you should, the kernel may have unmapped the page at PC
> from stage2 due to corruption).
yes, you also said you do not want to generate RAS SErrors for SIGBUS_MCEERR_AR,
so Qemu does not know in which condition to generate RAS SErrors.

> 
> I think the problem here is you're applying the CPU->software behaviour and
> choices to software->software. By the time user-space gets the error, the
> behaviour is different.
In the KVM, as a policy choice to reserve this API to specify guest ESR and 
drive to trigger SError is OK,
At least for Qemu it does not know in which condition to trigger it.





[PATCH v1 1/1] usb: xhci: do not create and register shared_hcd when USB3.0 is disabled

2017-12-15 Thread Thang Q. Nguyen
From: Tung Nguyen 

Currently, hcd->shared_hcd always creates and registers to the usb-core.
If, for some reasons, USB3 downstream port is disabled, no roothub port for
USB3.0 is found. This causes kernel to display an error:
hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
This patch checks, creates and registers shared_hcd if USB3.0 downstream
port is available.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
---
 drivers/usb/host/xhci-mem.c  |  2 +-
 drivers/usb/host/xhci-plat.c | 26 +++--
 drivers/usb/host/xhci.c  | 54 
 3 files changed, 54 insertions(+), 28 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 554a8a5..157d1e7 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1067,7 +1067,7 @@ static u32 xhci_find_real_port_number(struct xhci_hcd 
*xhci,
struct usb_device *top_dev;
struct usb_hcd *hcd;
 
-   if (udev->speed >= USB_SPEED_SUPER)
+   if (udev->speed >= USB_SPEED_SUPER && xhci->shared_hcd)
hcd = xhci->shared_hcd;
else
hcd = xhci->main_hcd;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6f03830..e812e3d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -253,12 +253,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
 
xhci->clk = clk;
xhci->main_hcd = hcd;
-   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
-   dev_name(>dev), hcd);
-   if (!xhci->shared_hcd) {
-   ret = -ENOMEM;
-   goto disable_clk;
-   }
 
if (device_property_read_bool(sysdev, "usb2-lpm-disable"))
xhci->quirks |= XHCI_HW_LPM_DISABLE;
@@ -290,12 +284,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto disable_usb_phy;
 
-   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
-   xhci->shared_hcd->can_do_streams = 1;
-
-   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
-   if (ret)
-   goto dealloc_usb2_hcd;
+   if (xhci->num_usb3_ports > 0) {
+   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
+   dev_name(>dev), hcd);
+   if (!xhci->shared_hcd) {
+   ret = -ENOMEM;
+   goto disable_clk;
+   }
+   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+   xhci->shared_hcd->can_do_streams = 1;
+
+   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+   if (ret)
+   goto dealloc_usb2_hcd;
+   }
 
device_enable_async_suspend(>dev);
pm_runtime_put_noidle(>dev);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 05104bd..4824bf6 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -417,12 +417,14 @@ static void compliance_mode_recovery(struct timer_list *t)
i + 1);
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
"Attempting compliance mode recovery");
-   hcd = xhci->shared_hcd;
+   if (xhci->shared_hcd) {
+   hcd = xhci->shared_hcd;
 
-   if (hcd->state == HC_STATE_SUSPENDED)
-   usb_hcd_resume_root_hub(hcd);
+   if (hcd->state == HC_STATE_SUSPENDED)
+   usb_hcd_resume_root_hub(hcd);
 
-   usb_hcd_poll_rh_status(hcd);
+   usb_hcd_poll_rh_status(hcd);
+   }
}
}
 
@@ -611,6 +613,18 @@ int xhci_run(struct usb_hcd *hcd)
if (ret)
xhci_free_command(xhci, command);
}
+   /*
+* Execute xhci_start() in case xhci->shared_hcd is not registered.
+* If the xhci->shared_hcd doesn't exist, no one triggers to start
+* the xhci which should be done before exitting run function
+*/
+   if (!xhci->shared_hcd) {
+   if (xhci_start(xhci)) {
+   xhci_halt(xhci);
+   return -ENODEV;
+   }
+   xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
+   }
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Finished xhci_run for USB2 roothub");
 
@@ -861,8 +875,8 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
if (!hcd->state)
return 0;
 
-   if (hcd->state != HC_STATE_SUSPENDED ||
-   xhci->shared_hcd->state != HC_STATE_SUSPENDED)
+   if (hcd->state != HC_STATE_SUSPENDED || 

Re: [PATCH v3 1/2] ARM64: dts: meson-axg: add ethernet mac controller

2017-12-15 Thread Yixun Lan
HI Kevin


On 12/16/2017 03:29 AM, Kevin Hilman wrote:
> Yixun Lan  writes:
> 
>> Add DT info for the stmmac ethernet MAC which found in
>> the Amlogic's Meson-AXG SoC, also describe the ethernet
>> pinctrl & clock information here.
>>
>> Reviewed-by: Neil Armstrong 
>> Signed-off-by: Yixun Lan 
> 
> This patch does not apply, and dependencies are not described.
> 
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 
>> ++
>>  1 file changed, 54 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
>> b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index d356ce74ad89..94c497b7 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -7,6 +7,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  / {
>>  compatible = "amlogic,meson-axg";
>> @@ -148,6 +149,19 @@
>>  #address-cells = <0>;
>>  };
>>  
>> +ethmac: ethernet@ff3f {
>> +compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
>> +reg = <0x0 0xff3f 0x0 0x1
>> +0x0 0xff634540 0x0 0x8>;
>> +interrupts = ;
>> +interrupt-names = "macirq";
>> +clocks = < CLKID_ETH>,
>> + < CLKID_FCLK_DIV2>,
>> + < CLKID_MPLL2>;
>> +clock-names = "stmmaceth", "clkin0", "clkin1";
>> +status = "disabled";
>> +};
>> +
>>  hiubus: bus@ff63c000 {
>>  compatible = "simple-bus";
>>  reg = <0x0 0xff63c000 0x0 0x1c00>;
> 
> Based on the hiubus node, presumably this depends on the patch from the
> clock series.
> 
yes, it depend on clock, also the pinctrl patch

>> @@ -194,6 +208,46 @@
>>  #gpio-cells = <2>;
>>  gpio-ranges = <_periphs 0 0 86>;
>>  };
> 
> I'm not sure where this part is coming from, but it causes the rest of
> it to not apply.
> 
> Please be sure to describe all dependencies.
> 
.
exactly, it depend on pinctrl

actually, once you apply the clock & pinctrl DT patch, this one should
go fine. I will send another v4 which base on your recent v4.16/dt64
branch for your convenience.

Yixun





Re: [PATCH v4 0/2] dt: add pinctrl driver for Meson-AXG SoC

2017-12-15 Thread Yixun Lan
On 12/16/2017 03:48 AM, Kevin Hilman wrote:
> Yixun Lan  writes:
> 
>> This is DT part patchset for adding pinctrl support for
>> the Amlogic's Meson-AXG SoC.
>>   
>> Changes since v3 at [3]
>>   -- rebase to khilman's v4.16/dt64 branch and re-send
>>   -- add Rob's Ack
>>
>> Changes since v2 at [2]:
>>   -- Resend this patch series due to fail to send patch [2/2]
>>
>> Changes since v1 at [1]:
>>   -- Separate DT part patches
>>   -- Add Neil Armstrong's Ack
>>
>> [3]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005392.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005393.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005394.html
>>
>> [2]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005390.html
>>
>> [1] 
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005270.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005271.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005272.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005273.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005274.html
>>
>> Xingyu Chen (2):
>>   documentation: Add compatibles for Amlogic Meson AXG pin controllers
>>   ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
> 
> Applied both to v4.14/dt64
> 
> Normally, the documentation patch should go with the driver, but since
> Linus has already merged the driver, this time I'll take it with the DT
> itself.
> 

Hi Kevin
 sorry, I just checked Linus' pinctrl tree - the for-next branch, the
documentation patch is already taken there. so probably you could drop
it here?

Yixun



Re: [PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

2017-12-15 Thread Brian Norris
Hi,

On Tue, Nov 21, 2017 at 04:25:17PM +0800, Jeffy Chen wrote:
> The rt5514 dsp captures pcm data through spi directly, so we should not
> use rockchip-i2s as it's cpu dai like other codecs.
> 
> Use dummy_dai for rt5514 dsp dailink to make voice wakeup work again.
> 
> Reported-by: Jimmy Cheng-Yi Chiang 
> Fixes: (72cfb0f20c75 ASoC: rockchip: Use codec of_node and dai_name for 
> rt5514 dsp)
> Signed-off-by: Jeffy Chen 

I didn't review this closely (and I don't know ASoC that well), but this
does fix regressions I've seen on 4.15 RCs, where

(a) the rt5514 DAI link doesn't get set up
(b) the rt5514 *always* causes my device to wake up, because we arm the
wakeup IRQ even though we never actually configured the DSP
(c) there are system crashes on resume because the rt5514-spi driver
assumes that the DAI link was correctly configured (that's the
subject of another patch I sent [1]

I believe this was working fine on 4.14? At least, I know (b) didn't
happen, and I'm not sure about (a). (c) is a new issue in 4.15-rc1.

Anyway, that's all to say:

Tested-by: Brian Norris 

on the "kevin" Chromebook (Samsung Chromebook Plus).

I also suspect this might be regression-fixing material, for 4.15. Or if
not, at least something like patch [1] should be.

Thanks,
Brian

[1] https://patchwork.kernel.org/patch/10116761/
[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"


Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Dave Hansen
On 12/15/2017 06:52 PM, Linus Torvalds wrote:
> On Fri, Dec 15, 2017 at 6:48 PM, Al Viro  wrote:
>> Treating protection key bits as "escalate to page fault and let that
>> deal with the checks" should be fine
> 
> Well, it's *semantically* fine and I think it's the right model from
> that standpoint.

It's _close_ to fine.  :)

Practically, we're going to have two classes of things in the world:
1. Things that are protected with protection keys and have non-zero bits
   in the pkey PTE bits.
2. Things that are _not_ protected will have zeros in there.

But, in the hardware, *everything* has a pkey.  0 is the default,
obviously, but the hardware treats it the same as all the other values.
So, if we go checking for the "pkey bits being set", and have behavior
diverge when they are set, we end up with pkey=0 being even more special
compared to the rest.

This might be OK, but it's going to be interesting to document and write
tests for it.  I'm already dreading the manpage updates.

> However, since the main use case of protection keys is probably
> databases (Dave?) and since those also might be performance-sensitive
> about direct-IO doing page table lookups, it might not be great in
> practice.

Yeah, databases are definitely the heavy-hitters that care about it.

But, these PKRU checks are cheap.  I forget the actual cycle counts, but
I remember thinking that it's pretty darn cheap to read PKRU.  In the
grand scheme of doing a page table walk and incrementing an atomic, it's
surely in the noise for direct I/O to large pages, which is basically
guaranteed for the database guys.

I did some get_user_pages() torture tests (on small pages IIRC) before I
put the code in and could not detect a delta from the code being there
or not.


Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

2017-12-15 Thread Brian Norris
+ others

On Fri, Dec 15, 2017 at 05:12:30PM -0800, Brian Norris wrote:
> I've found that on Google's "Kevin" Chromebook, the rt5514 codec might
> not be set up completely, yet its device is still present, and therefore
> its PM suspend/resume is called. This hits a NULL pointer exception,
> since we never had the chance to set our drvdata pointer.
> 
> This resolves crashes seen when trying to resume my system.
> 
> Fixes: e9c50aa6bd39 ("ASoC: rt5514-spi: check irq status to schedule data 
> copy in resume function")
> Signed-off-by: Brian Norris 
> ---
> This is a v4.15-rc1 regression

I see that this is probably a bug on its own, which should be fixed on
its own (e.g., with the $subject patch), but FYI I was also pointed at
this patch, which also "resolves" this problem by fixing the rt5514 DAI
setup:

https://patchwork.kernel.org/patch/10067725/
[PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

Would be nice to see it get handled too, possibly in 4.15 as well (I
think that's a regression too?).

Brian

> 
>  sound/soc/codecs/rt5514-spi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/codecs/rt5514-spi.c b/sound/soc/codecs/rt5514-spi.c
> index 2df91db765ac..9255afcf2c3a 100644
> --- a/sound/soc/codecs/rt5514-spi.c
> +++ b/sound/soc/codecs/rt5514-spi.c
> @@ -482,7 +482,7 @@ static int __maybe_unused rt5514_resume(struct device 
> *dev)
>   if (device_may_wakeup(dev))
>   disable_irq_wake(irq);
>  
> - if (rt5514_dsp->substream) {
> + if (rt5514_dsp && rt5514_dsp->substream) {
>   rt5514_spi_burst_read(RT5514_IRQ_CTRL, (u8 *), sizeof(buf));
>   if (buf[0] & RT5514_IRQ_STATUS_BIT)
>   rt5514_schedule_copy(rt5514_dsp);
> -- 
> 2.15.1.504.g5279b80103-goog
> 


Re: [PATCH] kbuild: fix dependency of dtbs targets

2017-12-15 Thread Masahiro Yamada
2017-12-14 6:31 GMT+09:00 Rob Herring :
> On Wed, Oct 25, 2017 at 12:40 AM, Masahiro Yamada
>  wrote:
>> Hi.
>>
>>
>> 2017-10-10 0:05 GMT+09:00 Russell King - ARM Linux :
>>> On Wed, Oct 04, 2017 at 01:27:20PM +0900, Masahiro Yamada wrote:
 The target "dtbs" should depend on "scripts" because it needs to
 build dtc.  The "prepare" target is unneeded here.
>>>
>>> Looks fine for ARM, as the only thing the dtbs should depend on is
>>> the kernel configuration (to decide which to build) and DT tooling.
>>>
>>> Acked-by: Russell King 
>>>
>>> --
>>
>>
>> I found a potential issue on this
>> because the default DTB install path depends on $(KERNELRELEASE).
>>
>>
>> In top-level Makefile:
>> export INSTALL_DTBS_PATH ?= $(INSTALL_PATH)/dtbs/$(KERNELRELEASE)
>>
>>
>> The include/config/kernel.release is created by "prepare3" target.
>>
>> If the dependency on "parepare" is removed,
>> it is possible to run "make dtbs" and "make dtbs_install"
>> without creating include/config/kernel.release.
>>
>> So, the $(KERNELRELEASE) could be empty when installing DTB.
>>
>>
>> Maybe, drop this patch, or reduce the dependency to "parepare3"?
>
> I was doing some work to get dtb builds to work without depending on
> $arch cross compiler and this patch fixes some of the issues. The
> dtbs_install target has the prepare dependency,

Which line?

I checked arch/{arm,arm64,mips}/Makefile, but I did not see any
dependency.


> so that should be
> sufficient and your patch should be fine.

Generally, adding dependencies to install targets is dangerous
because install targets are often invoked in root privilege.

This is stated by, for example,
commit 19514fc665ffbce624785f76ee7ad0ea6378a527



> BTW, Based on prior
> discussion on "ARM: kbuild: Fix forced rebuild after 'make dtbs'"
> thread, prepare should not be needed just for $(KERNELRELEASE).
>
> Rob

No.
If "prepare" target is dropped, you can run dtbs_install
without include/config/kenrel.release





-- 
Best Regards
Masahiro Yamada


Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume

2017-12-15 Thread Matthias Kaehlcke
Hi,

El Sun, Nov 19, 2017 at 03:43:50PM +0100 Greg Kroah-Hartman ha dit:

> 4.13-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Leif Liddy 
> 
> commit fd865802c66bc451dc515ed89360f84376ce1a56 upstream.
> 
> There's been numerous reported instances where BTUSB_QCA_ROME
> bluetooth controllers stop functioning upon resume from suspend. These
> devices seem to be losing power during suspend. Patch will detect a status
> change on resume and perform a reset.
> 
> Signed-off-by: Leif Liddy 
> Signed-off-by: Marcel Holtmann 
> Cc: Kai Heng Feng 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  drivers/bluetooth/btusb.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3068,6 +3068,12 @@ static int btusb_probe(struct usb_interf
>   if (id->driver_info & BTUSB_QCA_ROME) {
>   data->setup_on_usb = btusb_setup_qca;
>   hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
> +
> + /* QCA Rome devices lose their updated firmware over suspend,
> +  * but the USB hub doesn't notice any status change.
> +  * Explicitly request a device reset on resume.
> +  */
> + set_bit(BTUSB_RESET_RESUME, >flags);
>   }
>  
>  #ifdef CONFIG_BT_HCIBTUSB_RTL
> 
> 

On Chrome OS QCA Bluetooth stopped working after a merge from v4.4-stable:

[  124.789298] usb 2-1.1: reset full-speed USB device number 3 using 
ehci-platform
[  126.624274] Bluetooth: hci0 command 0x2005 tx timeout
[  128.672262] Bluetooth: hci0 command 0x200b tx timeout
[  130.720264] Bluetooth: hci0 command 0x200c tx timeout

We identified the above patch as the culprit, in combination with USB
autosuspend being enabled for the Bluetooth controller.

We found that the following (recent) upstream patch fixes the issue on
most devices (we are still investigating one case on a specific device):

commit a0085f2510e8976614ad8f766b209448b385492f
Author: Sukumar Ghorai 
Date:   Wed Aug 16 14:46:55 2017 -0700

Bluetooth: btusb: driver to enable the usb-wakeup feature

BT-Controller connected as platform non-root-hub device and
usb-driver initialize such device with wakeup disabled,
Ref. usb_new_device().

At present wakeup-capability get enabled by hid-input device from usb
function driver(e.g. BT HID device) at runtime. Again some functional
driver does not set usb-wakeup capability(e.g LE HID device implement
as HID-over-GATT), and can't wakeup the host on USB.

Most of the device operation (such as mass storage) initiated from host
(except HID) and USB wakeup aligned with host resume procedure. For BT
device, usb-wakeup capability need to enable form btusc driver as a
generic solution for multiple profile use case and required for USB remote
wakeup (in-bus wakeup) while host is suspended. Also usb-wakeup feature
need to enable/disable with HCI interface up and down.


stable branches are currently broken for BTUSB_QCA_ROME with USB
autosuspend enabled, since the above patch is not included (I only
checked v4.4 and v4.9), so we probably want to integrate it.

Thanks

Matthias


Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Linus Torvalds
On Fri, Dec 15, 2017 at 6:52 PM, Linus Torvalds
 wrote:
>
> However, since the main use case of protection keys is probably
> databases (Dave?) and since those also might be performance-sensitive
> about direct-IO doing page table lookups, it might not be great in
> practice.

Anyway, I reverted the three commits Dan pointed to, and we can always
revisit the exact path forward later

Because regardless of what the eventual future checks will be, for
4.15 I think we'll just go back to doing what we used to do.

If somebody sees problems, holler.

  Linus


[PATCH v2,net-next 1/2] ip_gre: fix error path when erspan_rcv failed

2017-12-15 Thread Haishuang Yan
When erspan_rcv call return PACKET_REJECT, we shoudn't call ipgre_rcv to
process packets again, instead send icmp unreachable message in error
path.

Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
Acked-by: William Tu 
Cc: William Tu 
Signed-off-by: Haishuang Yan 

Change since v2:
  * Rebase on latest master branch.
---
 net/ipv4/ip_gre.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 33af55a..ccfc5bc 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -434,11 +434,13 @@ static int gre_rcv(struct sk_buff *skb)
 tpi.proto == htons(ETH_P_ERSPAN2))) {
if (erspan_rcv(skb, , hdr_len) == PACKET_RCVD)
return 0;
+   goto out;
}
 
if (ipgre_rcv(skb, , hdr_len) == PACKET_RCVD)
return 0;
 
+out:
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
 drop:
kfree_skb(skb);
-- 
1.8.3.1





[PATCH v2,net-next 2/2] ip6_gre: fix error path when ip6erspan_rcv failed

2017-12-15 Thread Haishuang Yan
Same as ipv4 code, when ip6erspan_rcv call return PACKET_REJECT, we
should call icmpv6_send to send icmp unreachable message in error path.

Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
Acked-by: William Tu 
Cc: William Tu 
Signed-off-by: Haishuang Yan 

Change since v2:
  * Rebase on latest master branch.
---
 net/ipv6/ip6_gre.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 8ce9d42..f210f9c 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -603,12 +603,13 @@ static int gre_rcv(struct sk_buff *skb)
 tpi.proto == htons(ETH_P_ERSPAN2))) {
if (ip6erspan_rcv(skb, hdr_len, ) == PACKET_RCVD)
return 0;
-   goto drop;
+   goto out;
}
 
if (ip6gre_rcv(skb, ) == PACKET_RCVD)
return 0;
 
+out:
icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0);
 drop:
kfree_skb(skb);
-- 
1.8.3.1





Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Linus Torvalds
On Fri, Dec 15, 2017 at 6:48 PM, Al Viro  wrote:
>
> Treating protection key bits as "escalate to page fault and let that
> deal with the checks" should be fine

Well, it's *semantically* fine and I think it's the right model from
that standpoint.

However, since the main use case of protection keys is probably
databases (Dave?) and since those also might be performance-sensitive
about direct-IO doing page table lookups, it might not be great in
practice.

 Linus


[RFC 4/5] ARM: dts: sun8i: a83t: Add support for the ir interface

2017-12-15 Thread Philipp Rossak
The ir interface is like the H3 at 0x01f02000 located and is exactly
the same. This patch adds support for the ir interface on the A83T.

Signed-off-by: Philipp Rossak 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 5edb645b506f..5dbf2f0891c1 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -470,6 +470,16 @@
#reset-cells = <1>;
};
 
+   ir: ir@01f02000 {
+   compatible = "allwinner,sun5i-a13-ir";
+   clocks = <_ccu CLK_APB0_IR>, <_ccu CLK_IR>;
+   clock-names = "apb", "ir";
+   resets = <_ccu RST_APB0_IR>;
+   interrupts = ;
+   reg = <0x01f02000 0x40>;
+   status = "disabled";
+   };
+
r_pio: pinctrl@1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
-- 
2.11.0



[RFC 5/5] ARM: dts: sun8i: a83t: bananapi-m3: Enable IR controller

2017-12-15 Thread Philipp Rossak
The Bananapi M3 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Other than the other IR receivers this one needs a base clock frequency
of 300 Hz (3 MHz), to be able to work.

Signed-off-by: Philipp Rossak 
---
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++
 arch/arm/boot/dts/sun8i-a83t.dtsi| 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index c606af3dbfed..2c92c501cd59 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -88,6 +88,13 @@
/* TODO GL830 USB-to-SATA bridge downstream w/ GPIO power controls */
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   base-clk-frequency = <300>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 5dbf2f0891c1..679ce3a66b4b 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -470,7 +470,7 @@
#reset-cells = <1>;
};
 
-   ir: ir@01f02000 {
+   ir: ir@1f02000 {
compatible = "allwinner,sun5i-a13-ir";
clocks = <_ccu CLK_APB0_IR>, <_ccu CLK_IR>;
clock-names = "apb", "ir";
-- 
2.11.0



[RFC 1/5] [media] rc: update sunxi-ir driver to get base frequency from devicetree

2017-12-15 Thread Philipp Rossak
This patch updates the sunxi-ir driver to set the ir base clock from
devicetree.

This is neccessary since there are different ir recievers on the
market, that operate with different frequencys. So this value needs to
be set depending on the attached receiver.

Signed-off-by: Philipp Rossak 
---
 drivers/media/rc/sunxi-cir.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..55b53d6463e9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,6 @@
 /* CIR_REG register idle threshold */
 #define REG_CIR_ITHR(val)(((val) << 8) & (GENMASK(15, 8)))
 
-/* Required frequency for IR0 or IR1 clock in CIR mode */
-#define SUNXI_IR_BASE_CLK 800
-/* Frequency after IR internal divider  */
-#define SUNXI_IR_CLK  (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE   (10ul / SUNXI_IR_CLK)
 /* Noise threshold in samples  */
 #define SUNXI_IR_RXNOISE  1
 /* Idle Threshold in samples */
@@ -122,7 +116,7 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
-   rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+   rawir.duration = ((dt & 0x7f) + 1) * 
ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, );
}
}
@@ -148,6 +142,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+   u32 b_clk_freq;
 
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +167,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
 
+   /* Required frequency for IR0 or IR1 clock in CIR mode */
+   if (of_property_read_u32(dn, "base-clk-frequency", _clk_freq)) {
+   dev_err(dev, "failed to get ir base clock frequency.\n");
+   return -ENODATA;
+   }
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,7 +181,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+   ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
@@ -225,7 +226,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
-   ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+   /* Frequency after IR internal divider with sample period in ns */
+   ir->rc->rx_resolution = (10ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
 
-- 
2.11.0



[RFC 3/5] ARM: dts: sun8i: a83t: Add the ir pin for the A83T

2017-12-15 Thread Philipp Rossak
The CIR Pin of the A83T is located at PL12

Signed-off-by: Philipp Rossak 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 19acae1b4089..5edb645b506f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -488,6 +488,11 @@
drive-strength = <20>;
bias-pull-up;
};
+
+   ir_pins_a: ir@0 {
+   pins = "PL12";
+   function = "s_cir_rx";
+   };
};
 
r_rsb: rsb@1f03400 {
-- 
2.11.0



[RFC 0/5] IR support for A83T - sunxi-ir driver update

2017-12-15 Thread Philipp Rossak
This patch series adds support for the sunxi A83T ir module and enhances the 
sunxi-ir driver.
Right now the base clock frequency for the ir driver is a hard coded define and 
is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3 the ir 
receiver needs,
a 3 MHz base clock frequency to work without problems with this driver (like in 
the legacy kernel).

To fix this issue I reworked the driver that this value could be set over the 
devicetree.

About 37 devices would have a devicetree change if this patch series would be 
applied.
Therfore I would like to ask you to give me some feedback about the patch 
series, before I finialize it.


Thanks in advance!

Philipp


Philipp Rossak (5):
  [media] rc: update sunxi-ir driver to get base frequency from
devicetree
  [media] dt: bindings: Update binding documentation for sunxi IR
controller
  ARM: dts: sun8i: a83t: Add the ir pin for the A83T
  ARM: dts: sun8i: a83t: Add support for the ir interface
  ARM: dts: sun8i: a83t: bananapi-m3: Enable IR controller

 Documentation/devicetree/bindings/media/sunxi-ir.txt | 14 --
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts |  7 +++
 arch/arm/boot/dts/sun8i-a83t.dtsi| 15 +++
 drivers/media/rc/sunxi-cir.c | 20 +++-
 4 files changed, 41 insertions(+), 15 deletions(-)

-- 
2.11.0



[RFC 2/5] [media] dt: bindings: Update binding documentation for sunxi IR controller

2017-12-15 Thread Philipp Rossak
This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new requiered property for the base clock frequency.

Signed-off-by: Philipp Rossak 
---
 Documentation/devicetree/bindings/media/sunxi-ir.txt | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..5f4960c61245 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -1,12 +1,13 @@
 Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
 
 Required properties:
-- compatible   : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
-- clocks   : list of clock specifiers, corresponding to
- entries in clock-names property;
-- clock-names  : should contain "apb" and "ir" entries;
-- interrupts   : should contain IR IRQ number;
-- reg  : should contain IO map address for IR.
+- compatible : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
+- clocks : list of clock specifiers, corresponding to
+   entries in clock-names property;
+- clock-names: should contain "apb" and "ir" entries;
+- interrupts : should contain IR IRQ number;
+- reg: should contain IO map address for IR.
+- base-clk-frequency  : should contain the base clock frequency
 
 Optional properties:
 - linux,rc-map-name: see rc.txt file in the same directory.
@@ -21,5 +22,6 @@ ir0: ir@1c21800 {
resets = <_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
+   base-clk-frequency = <800>;
linux,rc-map-name = "rc-rc6-mce";
 };
-- 
2.11.0



[PATCH v2,net-next 2/2] ip6_gre: fix potential memory leak in ip6erspan_rcv

2017-12-15 Thread Haishuang Yan
If md is NULL, tun_dst must be freed, otherwise it will cause memory
leak.

Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode")
Cc: William Tu 
Signed-off-by: Haishuang Yan 

Change since v2:
  * Rebase on latest master branch.
  * Correct wrong fix information.
---
 net/ipv6/ip6_gre.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 5c9c65f..8ce9d42 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -549,8 +549,10 @@ static int ip6erspan_rcv(struct sk_buff *skb, int 
gre_hdr_len,
 
info = _dst->u.tun_info;
md = ip_tunnel_info_opts(info);
-   if (!md)
+   if (!md) {
+   dst_release((struct dst_entry *)tun_dst);
return PACKET_REJECT;
+   }
 
memcpy(md, pkt_md, sizeof(*md));
md->version = ver;
-- 
1.8.3.1





[PATCH v2,net-next 1/2] ip_gre: fix potential memory leak in erspan_rcv

2017-12-15 Thread Haishuang Yan
If md is NULL, tun_dst must be freed, otherwise it will cause memory
leak.

Fixes: 1a66a836da6 ("gre: add collect_md mode to ERSPAN tunnel")
Cc: William Tu 
Signed-off-by: Haishuang Yan 

Change since v2:
  * Rebase on latest master branch.
  * Correct wrong fix information.
---
 net/ipv4/ip_gre.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 004800b..33af55a 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -311,8 +311,10 @@ static int erspan_rcv(struct sk_buff *skb, struct 
tnl_ptk_info *tpi,
return PACKET_REJECT;
 
md = ip_tunnel_info_opts(_dst->u.tun_info);
-   if (!md)
+   if (!md) {
+   dst_release((struct dst_entry *)tun_dst);
return PACKET_REJECT;
+   }
 
memcpy(md, pkt_md, sizeof(*md));
md->version = ver;
-- 
1.8.3.1





Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Al Viro
On Fri, Dec 15, 2017 at 06:28:36PM -0800, Linus Torvalds wrote:
> On Fri, Dec 15, 2017 at 5:25 PM, Dave Hansen  wrote:
> >
> > I think the reason we needed VMA and PTE checks was the
> > get_user_pages_fast() path not having a VMA.
> 
> That is indeed the point of get_user_pages_fast(): no vma lookup, no
> locking, just "do the default case as streamlined as possible".
> 
> But part of it is also that we should fall back to the slow case if
> the fast case doesn't work (eg because the page isn't there or
> whatever).
> 
> So what we could do - perhaps - is to just make get_user_pages_fast()
> check whether any of the protection key bits are set, and fail for
> that case.

FWIW, a good description of fast path in get_user_pages_fast() is
"simulate a TLB miss", the slow path being "... and go for simulated
page fault if TLB miss would have escalated to #PF".

Treating protection key bits as "escalate to page fault and let that
deal with the checks" should be fine - page fault handler must
cope with the page actually being present in page tables anyway, for
obvious reasons...


[PATCH] trace: reenable preemption if we modify the ip

2017-12-15 Thread Josef Bacik
From: Josef Bacik 

Things got moved around between the original bpf_override_return patches
and the final version, and now the ftrace kprobe dispatcher assumes if
you modified the ip that you also enabled preemption.  Make a comment of
this and enable preemption, this fixes the lockdep splat that happened
when using this feature.

Signed-off-by: Josef Bacik 
---
 kernel/trace/trace_kprobe.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 5db849809a56..91f4b57dab82 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1322,8 +1322,15 @@ static int kprobe_dispatcher(struct kprobe *kp, struct 
pt_regs *regs)
if (tk->tp.flags & TP_FLAG_TRACE)
kprobe_trace_func(tk, regs);
 #ifdef CONFIG_PERF_EVENTS
-   if (tk->tp.flags & TP_FLAG_PROFILE)
+   if (tk->tp.flags & TP_FLAG_PROFILE) {
ret = kprobe_perf_func(tk, regs);
+   /*
+* The ftrace kprobe handler leaves it up to us to re-enable
+* preemption here before returning if we've modified the ip.
+*/
+   if (ret)
+   preempt_enable_no_resched();
+   }
 #endif
return ret;
 }
-- 
2.7.5



Re: [PATCH] locking/lockdep: Remove the cross-release locking checks

2017-12-15 Thread Byungchul Park
On Sat, Dec 16, 2017 at 6:15 AM, Theodore Ts'o  wrote:
> On Fri, Dec 15, 2017 at 05:39:25PM +0900, Byungchul Park wrote:
>>
>> All locks should belong to one class if each path of acquisition
>> can be switchable each other within the class at any time.
>> Otherwise, they should belong to a different class.
>
> OK, so let's go back to my case of a Network Block Device with a local
> file system mounted on it, which is then exported via NFS.
>
> So an incoming TCP packet can go into the NFS server subsystem, then
> be processed by local disk file system, which then does an I/O
> operation to the NBD device, which results in an TCP packet being sent
> out.  Then the response will come back over TCP, into the NBD block
> layer, then into the local disk file system, and that will result in
> an outgoing response to the TCP connection for the NFS protocol.
>
> In order to avoid cross release problems, all locks associated with
> the incoming TCP connection will need to be classified as belonging to
> a different class as the outgoing TCP connection.  Correct?  One
> solution might be to put every single TCP connection into a separate
> class --- but that will explode the number of lock classes which
> Lockdep will need to track, and there is a limited number of lock
> classes (set at compile time) that Lockdep can track.  So if that
> doesn't work, we will have to put something ugly which manually makes
> certain TCP connections "magic" and require them to be put into a
> separate class than all other TCP connections, which will get
> collapsed into a single class.  Basically, any TCP connection which is
> either originated by the kernel, or passed in from userspace into the
> kernel and used by some kernel subsystem, will have to be assigned its
> own lockdep class.
>
> If the TCP connection gets closed, we don't need to track that lockdep
> class any more.  (Or if a device mapper device is torn down, we
> similarly don't need any unique lockdep classes created for that
> device mapper device.)  Is there a way to tell lockdep that a set of
> lockdep classes can be released so we can recover the kernel memory to
> be used to track some new TCP connection or some new device mapper
> device?

Right. I also think lockdep should be able to reflect that
kind of dynamic situations to do a better job.

The fact that kernel works well w/o that work doesn't
mean current status is perfect, in my opinion.

As you know, lockdep is running within very limited
environment so it's very hard to achieve it.

However, anyway, I think that's a problem and should
be solved by modifying lockdep core. Actually, that had
been one on my to-dos, if allowed.

For some waiters, for which this is only solution to play
with cross-release, I think we can invalidate those
waiters for now, while all others still get benefit.

We have added acquire annotations manually to
consider waiters one by one, and I am sure it's going
to continue in the future.

IMO, considering all waiters at once and fixing false
positives in a right way or invalidating one by one is
better than considering waiters one by one as is, of
course, while keeping off by default.

-- 
Thanks,
Byungchul


Re: [PATCH v2 4/4] sched/cpufreq_schedutil: use util_est for OPP selection

2017-12-15 Thread Rafael J. Wysocki
On Tuesday, December 5, 2017 6:10:18 PM CET Patrick Bellasi wrote:
> When schedutil looks at the CPU utilization, the current PELT value for
> that CPU is returned straight away. In certain scenarios this can have
> undesired side effects and delays on frequency selection.
> 
> For example, since the task utilization is decayed at wakeup time, a
> long sleeping big task newly enqueued does not add immediately a
> significant contribution to the target CPU. This introduces some latency
> before schedutil will be able to detect the best frequency required by
> that task.
> 
> Moreover, the PELT signal build-up time is function of the current
> frequency, because of the scale invariant load tracking support. Thus,
> starting from a lower frequency, the utilization build-up time will
> increase even more and further delays the selection of the actual
> frequency which better serves the task requirements.
> 
> In order to reduce these kind of latencies, this patch integrates the
> usage of the CPU's estimated utilization in the sugov_get_util function.
> 
> The estimated utilization of a CPU is defined to be the maximum between
> its PELT's utilization and the sum of the estimated utilization of each
> currently RUNNABLE task on that CPU.
> This allows to properly represent the expected utilization of a CPU which,
> for example, has just got a big task running after a long sleep period,
> and ultimately it allows to select the best frequency to run a task
> right after it wakes up.
> 
> Signed-off-by: Patrick Bellasi 
> Reviewed-by: Brendan Jackman 
> Reviewed-by: Dietmar Eggemann 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Paul Turner 
> Cc: Vincent Guittot 
> Cc: Morten Rasmussen 
> Cc: Dietmar Eggemann 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> 
> ---
> Changes v1->v2:
>  - rebase on top of v4.15-rc2
>  - tested that overhauled PELT code does not affect the util_est
> ---
>  kernel/sched/cpufreq_schedutil.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 2f52ec0f1539..465430d99440 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -183,7 +183,11 @@ static void sugov_get_util(unsigned long *util, unsigned 
> long *max, int cpu)
>  
>   cfs_max = arch_scale_cpu_capacity(NULL, cpu);
>  
> - *util = min(rq->cfs.avg.util_avg, cfs_max);
> + *util = rq->cfs.avg.util_avg;

I would use a local variable here.

That *util everywhere looks a bit dirtyish.

> + if (sched_feat(UTIL_EST))
> + *util = max(*util, rq->cfs.util_est_runnable);
> + *util = min(*util, cfs_max);
> +
>   *max = cfs_max;
>  }
>  
> 




Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Linus Torvalds
On Fri, Dec 15, 2017 at 5:25 PM, Dave Hansen  wrote:
>
> I think the reason we needed VMA and PTE checks was the
> get_user_pages_fast() path not having a VMA.

That is indeed the point of get_user_pages_fast(): no vma lookup, no
locking, just "do the default case as streamlined as possible".

But part of it is also that we should fall back to the slow case if
the fast case doesn't work (eg because the page isn't there or
whatever).

So what we could do - perhaps - is to just make get_user_pages_fast()
check whether any of the protection key bits are set, and fail for
that case.

If we care, that is.

   Linus


[PATCH v2,net-next] ip6_gre: fix a pontential issue in ip6erspan_rcv

2017-12-15 Thread Haishuang Yan
pskb_may_pull() can change skb->data, so we need to load ipv6h/ershdr at
the right place.

Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
Acked-by: William Tu 
Cc: William Tu 
Signed-off-by: Haishuang Yan 

---
Change since v2:
  * Rebase on latest master.
---
 net/ipv6/ip6_gre.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index f210f9c..aa1512e 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -507,12 +507,11 @@ static int ip6erspan_rcv(struct sk_buff *skb, int 
gre_hdr_len,
struct ip6_tnl *tunnel;
u8 ver;
 
-   ipv6h = ipv6_hdr(skb);
-   ershdr = (struct erspan_base_hdr *)skb->data;
-
if (unlikely(!pskb_may_pull(skb, sizeof(*ershdr
return PACKET_REJECT;
 
+   ipv6h = ipv6_hdr(skb);
+   ershdr = (struct erspan_base_hdr *)skb->data;
ver = (ntohs(ershdr->ver_vlan) & VER_MASK) >> VER_OFFSET;
tpi->key = cpu_to_be32(ntohs(ershdr->session_id) & ID_MASK);
pkt_md = (struct erspan_metadata *)(ershdr + 1);
-- 
1.8.3.1





Re: [PATCH 10/17] mm: merge vmem_altmap_alloc into altmap_alloc_block_buf

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> There is no clear separation between the two, so merge them.
>
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Logan Gunthorpe 

Looks good,

Reviewed-by: Dan Williams 


Re: [PATCH 09/17] mm: split altmap memory map allocation from normal case

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> No functional changes, just untangling the call chain.

I'd also mention that creating more helper functions in the altmap_
namespace helps document why altmap is passed all around the hotplug
code.

>
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Logan Gunthorpe 

Reviewed-by: Dan Williams 


Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

2017-12-15 Thread Rafael J. Wysocki
On Sat, Dec 16, 2017 at 2:57 AM, Dan Williams  wrote:
> On Fri, Dec 15, 2017 at 5:53 PM, Rafael J. Wysocki  wrote:
>> On Friday, December 15, 2017 2:10:17 AM CET Dan Williams wrote:
>>> On Wed, Dec 13, 2017 at 6:10 PM, Ross Zwisler
>>>  wrote:
>>> > The current implementation of acpi_parse_entries_array() assumes that each
>>> > subtable has a standard ACPI subtable entry of type struct
>>> > acpi_subtable_header.  This standard subtable header has a one byte length
>>> > followed by a one byte type.
>>> >
>>> > The HMAT subtables have to allow for a longer length so they have subtable
>>> > headers of type struct acpi_hmat_structure which has a 2 byte type and a 4
>>> > byte length.
>>>
>>> Hmm, NFIT has a 2 byte type and a 2 byte length, so its one more
>>> permutation. I happened to reinvent sub-table parsing in the NFIT
>>> driver, but it might be nice in the future to refactor that to use the
>>> common parsing.
>>>
>>> >
>>> > Enhance the subtable parsing in acpi_parse_entries_array() so that it can
>>> > handle these new HMAT subtables.
>>> >
>>> > Signed-off-by: Ross Zwisler 
>>> > ---
>>> >  drivers/acpi/tables.c | 52 
>>> > ---
>>> >  1 file changed, 41 insertions(+), 11 deletions(-)
>>> >
>>> > diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
>>> > index 80ce2a7d224b..f777b94c234a 100644
>>> > --- a/drivers/acpi/tables.c
>>> > +++ b/drivers/acpi/tables.c
>>> > @@ -218,6 +218,33 @@ void acpi_table_print_madt_entry(struct 
>>> > acpi_subtable_header *header)
>>> > }
>>> >  }
>>> >
>>> > +static unsigned long __init
>>> > +acpi_get_entry_type(char *id, void *entry)
>>> > +{
>>> > +   if (strncmp(id, ACPI_SIG_HMAT, 4) == 0)
>>> > +   return ((struct acpi_hmat_structure *)entry)->type;
>>> > +   else
>>> > +   return ((struct acpi_subtable_header *)entry)->type;
>>> > +}
>>>
>>> It seems inefficient to make all checks keep asking "is HMAT?".
>>
>> Well, ideally, the signature should be checked once.  I guess that can be
>> arranged for here.
>>
>>> Especially if we want to extend this to other table types should we
>>> instead setup and pass a pair of function pointers to parse the
>>> sub-table format?
>>
>> Function pointers may be too much even. :-)
>
> True, how about an enum of acpi sub-table header types?

That works.


Re: [PATCH 08/17] mm: pass the vmem_altmap to memmap_init_zone

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> Pass the vmem_altmap two levels down instead of needing a lookup.
>
> Signed-off-by: Christoph Hellwig 

Given the fact that HMM and now P2P are attracted to
devm_memremap_pages() I think this churn is worth it. vmem_altmap is
worth being considered a first class citizen of memory hotplug and not
a hidden hack.

Reviewed-by: Dan Williams 


Re: [PATCH 07/17] mm: pass the vmem_altmap to vmemmap_free

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> We can just pass this on instead of having to do a radix tree lookup
> without proper locking a few levels into the callchain.
>
> Signed-off-by: Christoph Hellwig 

Now I remember why I went with the radix lookup, laziness!

This looks good to me, I appreciate you digging in.

Reviewed-by: Dan Williams 


Re: [PATCH 06/17] mm: pass the vmem_altmap to arch_remove_memory and __remove_pages

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> We can just pass this on instead of having to do a radix tree lookup
> without proper locking 2 levels into the callchain.
>
> Signed-off-by: Christoph Hellwig wip

I assume that "wip" is a typo?

Otherwise,

Reviewed-by: Dan Williams 


Re: [PATCH 05/17] mm: pass the vmem_altmap to vmemmap_populate

2017-12-15 Thread Dan Williams
[ cc Michal ]

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> We can just pass this on instead of having to do a radix tree lookup
> without proper locking a few levels into the callchain.
>
> Signed-off-by: Christoph Hellwig 

I know Michal has concerns about the complexity of the memory hotplug
implementation, but I think this just means I need to go write up
better kerneldoc for the vmem_altmap definition so that memory hotplug
developers know what's happening.

Other than that:

Reviewed-by: Dan Williams 

Including the patch for Michal just in case he doesn't have it in his archives.

> ---
>  arch/arm64/mm/mmu.c|  6 --
>  arch/ia64/mm/discontig.c   |  3 ++-
>  arch/powerpc/mm/init_64.c  |  7 ++-
>  arch/s390/mm/vmem.c|  3 ++-
>  arch/sparc/mm/init_64.c|  2 +-
>  arch/x86/mm/init_64.c  |  4 ++--
>  include/linux/memory_hotplug.h |  3 ++-
>  include/linux/mm.h |  6 --
>  mm/memory_hotplug.c|  7 ---
>  mm/sparse-vmemmap.c|  7 ---
>  mm/sparse.c| 20 
>  11 files changed, 39 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 267d2b79d52d..ec8952ff13be 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -654,12 +654,14 @@ int kern_addr_valid(unsigned long addr)
>  }
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
>  #if !ARM64_SWAPPER_USES_SECTION_MAPS
> -int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node)
> +int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node,
> +   struct vmem_altmap *altmap)
>  {
> return vmemmap_populate_basepages(start, end, node);
>  }
>  #else  /* !ARM64_SWAPPER_USES_SECTION_MAPS */
> -int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node)
> +int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node,
> +   struct vmem_altmap *altmap)
>  {
> unsigned long addr = start;
> unsigned long next;
> diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
> index 9b2d994cddf6..1555aecaaf85 100644
> --- a/arch/ia64/mm/discontig.c
> +++ b/arch/ia64/mm/discontig.c
> @@ -754,7 +754,8 @@ void arch_refresh_nodedata(int update_node, pg_data_t 
> *update_pgdat)
>  #endif
>
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
> -int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node)
> +int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node,
> +   struct vmem_altmap *altmap)
>  {
> return vmemmap_populate_basepages(start, end, node);
>  }
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index a07722531b32..779b74a96b8f 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -183,7 +183,8 @@ static __meminit void vmemmap_list_populate(unsigned long 
> phys,
> vmemmap_list = vmem_back;
>  }
>
> -int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node)
> +int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node,
> +   struct vmem_altmap *altmap)
>  {
> unsigned long page_size = 1 << 
> mmu_psize_defs[mmu_vmemmap_psize].shift;
>
> @@ -193,16 +194,12 @@ int __meminit vmemmap_populate(unsigned long start, 
> unsigned long end, int node)
> pr_debug("vmemmap_populate %lx..%lx, node %d\n", start, end, node);
>
> for (; start < end; start += page_size) {
> -   struct vmem_altmap *altmap;
> void *p;
> int rc;
>
> if (vmemmap_populated(start, page_size))
> continue;
>
> -   /* altmap lookups only work at section boundaries */
> -   altmap = to_vmem_altmap(SECTION_ALIGN_DOWN(start));
> -
> p =  __vmemmap_alloc_block_buf(page_size, node, altmap);
> if (!p)
> return -ENOMEM;
> diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
> index 3316d463fc29..c44ef0e7c466 100644
> --- a/arch/s390/mm/vmem.c
> +++ b/arch/s390/mm/vmem.c
> @@ -211,7 +211,8 @@ static void vmem_remove_range(unsigned long start, 
> unsigned long size)
>  /*
>   * Add a backed mem_map array to the virtual mem_map array.
>   */
> -int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node)
> +int __meminit vmemmap_populate(unsigned long start, unsigned long end, int 
> node,
> +   struct vmem_altmap *altmap)
>  {
> unsigned long pgt_prot, sgt_prot;
> unsigned long address = start;
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 55ba62957e64..42d27a1a042a 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -2628,7 +2628,7 @@ EXPORT_SYMBOL(_PAGE_CACHE);
>
>  #ifdef 

[RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

2017-12-15 Thread Ingo Molnar
Linus,

Please consider pulling the latest x86-pti-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pti-for-linus

   # HEAD: eeb17ad55b3f7959805ae995fe955d6d93e67e89 Merge branch 
'WIP.x86/pti.entry' into x86/pti

These are the x86-64 low level entry code preparatory patches for the page 
table 
isolation patches - which are required for PTI, which addresses KASLR and 
similar 
information leaks.

The merges and commits have the following structure:

1)

The tree with HEAD 2533a63618fc is the 'v4.14 backporting base tree': it's a 
handful of x86 entry code specific merges, combined with a handful of 
cherry-picks.
The cherry-picks are marked in such a clear fashion:

[ Note, this commit is a cherry-picked version of:

d17a1d97dc20: ("x86/mm/kasan: don't use vmemmap_populate() to 
initialize shadow")

  ... for easier x86 entry code testing and back-porting. ]

Otherwise they contain the original changelog. There's also a namespace
preparatory patch:

  d78b637b29a2: drivers/misc/intel/pti: Rename the header file to free up the 
namespace

2)

The cherry-picked tree is merged with a matching v4.14 tree in a conflict-free 
fashion, i.e. an upstream tree version is merged where all the cherry-picks 
match 
and there's no content conflict.

3)

The remaining new commits are the PTI entry code changes:

aaa01e2049fb: x86/entry/64: Don't use the entry stack on XENPV and optimize 
sync_regs()
c5e1a2f04b59: x86/cpufeatures: Make CPU bugs sticky
1f6688f1b26c: x86/paravirt: Provide a way to check for hypervisors
4a24c80e6f8a: x86/paravirt: Dont patch flush_tlb_single
11a1251e3a3c: x86/entry/64: Make cpu_entry_area.tss read-only
dff71e3c0e18: x86/entry: Clean up the SYSENTER_stack code
f3116218fe9e: x86/entry/64: Remove the SYSENTER stack canary
9e2dc3874178: x86/entry/64: Move the IST stacks into struct cpu_entry_area
65bbc819a025: x86/entry/64: Create a per-CPU SYSCALL entry trampoline
813b4125a835: x86/entry/64: Return to userspace from the trampoline stack
4f79eec94c07: x86/entry/64: Use a per-CPU trampoline stack for IDT entries
21b90b9dc777: x86/espfix/64: Stop assuming that pt_regs is on the entry stack
73761a513764: x86/entry/64: Separate cpu_current_top_of_stack from TSS.sp0
566999c89d26: x86/entry: Remap the TSS into the CPU entry area
df55611bc5d0: x86/entry: Move SYSENTER_stack to the beginning of struct 
tss_struct
97a1894ff954: x86/dumpstack: Handle stack overflow on all stacks
5ed1fcd523b9: x86/entry: Fix assumptions that the HW TSS is at the beginning of 
cpu_tss
60b6c4ac2d51: x86/kasan/64: Teach KASAN about the cpu_entry_area
5bf215b74703: x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce 
struct cpu_entry_area
f61ef66a7bb4: x86/entry/gdt: Put per-CPU GDT remaps in ascending order
3ae6bdda6853: x86/dumpstack: Add get_stack_info() support for the SYSENTER stack
63372c118470: x86/entry/64: Allocate and enable the SYSENTER stack
69282699385f: x86/irq/64: Print the offending IP in the stack overflow warning
1192b8b8232a: x86/irq: Remove an old outdated comment about context tracking 
races
b8573e790649: x86/unwinder: Handle stack overflows more gracefully
58b6fe6672f8: x86/unwinder/orc: Dont bail on stack overflow
3961a7f4adc8: x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

The main changes here are Andy Lutomirski's changes to switch the x86-64 entry 
code
to use the 'entry trampoline stack', which is in the fixmap area, and as such 
doesn't
require any %gs relative kernel percpu data to enter/exit the kernel. This, 
besides
helping fix KASLR leaks, also robustifies the x86 entry code.

 Thanks,

Ingo

-->

Andi Kleen (1):
  perf/x86: Enable free running PEBS for REGS_USER/INTR

Andrey Ryabinin (1):
  x86/mm/kasan: Don't use vmemmap_populate() to initialize shadow

Andy Lutomirski (22):
  x86/unwinder/orc: Dont bail on stack overflow
  x86/irq: Remove an old outdated comment about context tracking races
  x86/irq/64: Print the offending IP in the stack overflow warning
  x86/entry/64: Allocate and enable the SYSENTER stack
  x86/dumpstack: Add get_stack_info() support for the SYSENTER stack
  x86/entry/gdt: Put per-CPU GDT remaps in ascending order
  x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce struct 
cpu_entry_area
  x86/kasan/64: Teach KASAN about the cpu_entry_area
  x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
  x86/dumpstack: Handle stack overflow on all stacks
  x86/entry: Move SYSENTER_stack to the beginning of struct tss_struct
  x86/entry: Remap the TSS into the CPU entry area
  x86/entry/64: Separate cpu_current_top_of_stack from TSS.sp0
  x86/espfix/64: Stop assuming that pt_regs is on the entry stack
  x86/entry/64: Use a per-CPU trampoline stack for IDT entries
  x86/entry/64: Return to userspace from the trampoline stack
  x86/entry/64: Create a 

Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection

2017-12-15 Thread Grygorii Strashko


On 12/13/2017 12:53 PM, Alexandre Belloni wrote:
> The clocksource and clockevent timer are probed early in the boot process.
> At that time it is difficult for linux to know whether a particular timer
> can be used as the clocksource or the clockevent or by another driver,
> especially when they are all identical or have similar features.
> 
> Until now, multiple strategies have been used to solve that:
>   - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK
>   - use a kernel parameter as the "clocksource" early_param in mach-omap2
>   - registering the first seen timer as a clockevent and the second one as
>   a clocksource as in rk_timer_init or dw_apb_timer_init
> 
> Add a linux,clocksource and a linux,clockevent node in chosen with a timer
> property pointing to the timer to use. Other properties, like the targeted
> precision may be added later.
> 
> Signed-off-by: Alexandre Belloni 
> ---
>   Documentation/devicetree/bindings/chosen.txt | 20 
>   1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/chosen.txt 
> b/Documentation/devicetree/bindings/chosen.txt
> index e3b13ea7d2ae..c7ee3ecb5276 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -120,3 +120,23 @@ e.g.
>   While this property does not represent a real hardware, the address
>   and the size are expressed in #address-cells and #size-cells,
>   respectively, of the root node.
> +
> +linux,clocksource and linux,clockevent
> +--
> +
> +Those nodes have a timer property. This property is a phandle to the timer 
> to be
> +chosen as the clocksource or clockevent. This is only useful when the 
> platform
> +has multiple identical timers and it is not possible to let linux make the
> +correct choice.
> +
> +/ {
> + chosen {
> + linux,clocksource {
> + timer = <>;
> + };
> +
> + linux,clockevent {
> + timer = <>;
> + };
> + };
> +};
> 

It'd be nice if smth. like this will actually happen, as on some OMAP
platforms can be up to 3-4 alternatives for each clocksource/clockevent and
different combination need to be selected depending on SoC and platform
(and sometime - use case) which is pain in multi-platform environment now.

But more important note from my side is clocksource and clockevent selections 
seems 
not enough :( There are also sched clock (sched_clock_register()) and 
delay_timer
 (register_current_timer_delay() at least on ARM).
Both above can't be unregistered (at least last time I've checked).

-- 
regards,
-grygorii


Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 5:53 PM, Rafael J. Wysocki  wrote:
> On Friday, December 15, 2017 2:10:17 AM CET Dan Williams wrote:
>> On Wed, Dec 13, 2017 at 6:10 PM, Ross Zwisler
>>  wrote:
>> > The current implementation of acpi_parse_entries_array() assumes that each
>> > subtable has a standard ACPI subtable entry of type struct
>> > acpi_subtable_header.  This standard subtable header has a one byte length
>> > followed by a one byte type.
>> >
>> > The HMAT subtables have to allow for a longer length so they have subtable
>> > headers of type struct acpi_hmat_structure which has a 2 byte type and a 4
>> > byte length.
>>
>> Hmm, NFIT has a 2 byte type and a 2 byte length, so its one more
>> permutation. I happened to reinvent sub-table parsing in the NFIT
>> driver, but it might be nice in the future to refactor that to use the
>> common parsing.
>>
>> >
>> > Enhance the subtable parsing in acpi_parse_entries_array() so that it can
>> > handle these new HMAT subtables.
>> >
>> > Signed-off-by: Ross Zwisler 
>> > ---
>> >  drivers/acpi/tables.c | 52 
>> > ---
>> >  1 file changed, 41 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
>> > index 80ce2a7d224b..f777b94c234a 100644
>> > --- a/drivers/acpi/tables.c
>> > +++ b/drivers/acpi/tables.c
>> > @@ -218,6 +218,33 @@ void acpi_table_print_madt_entry(struct 
>> > acpi_subtable_header *header)
>> > }
>> >  }
>> >
>> > +static unsigned long __init
>> > +acpi_get_entry_type(char *id, void *entry)
>> > +{
>> > +   if (strncmp(id, ACPI_SIG_HMAT, 4) == 0)
>> > +   return ((struct acpi_hmat_structure *)entry)->type;
>> > +   else
>> > +   return ((struct acpi_subtable_header *)entry)->type;
>> > +}
>>
>> It seems inefficient to make all checks keep asking "is HMAT?".
>
> Well, ideally, the signature should be checked once.  I guess that can be
> arranged for here.
>
>> Especially if we want to extend this to other table types should we
>> instead setup and pass a pair of function pointers to parse the
>> sub-table format?
>
> Function pointers may be too much even. :-)

True, how about an enum of acpi sub-table header types?


Re: [PATCH v2] ACPI / PMIC: constify platform_device_id

2017-12-15 Thread Rafael J. Wysocki
On Wednesday, November 29, 2017 9:51:32 AM CET Mika Westerberg wrote:
> On Wed, Nov 29, 2017 at 10:05:02AM +0530, Arvind Yadav wrote:
> > platform_device_id are not supposed to change at runtime. All functions
> > working with platform_device_id provided by 
> > work with const platform_device_id. So mark the non-const structs as
> > const.
> > 
> > Signed-off-by: Arvind Yadav 
> 
> Acked-by: Mika Westerberg 

Patch applied, thanks!



Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

2017-12-15 Thread Rafael J. Wysocki
On Friday, December 15, 2017 2:10:17 AM CET Dan Williams wrote:
> On Wed, Dec 13, 2017 at 6:10 PM, Ross Zwisler
>  wrote:
> > The current implementation of acpi_parse_entries_array() assumes that each
> > subtable has a standard ACPI subtable entry of type struct
> > acpi_subtable_header.  This standard subtable header has a one byte length
> > followed by a one byte type.
> >
> > The HMAT subtables have to allow for a longer length so they have subtable
> > headers of type struct acpi_hmat_structure which has a 2 byte type and a 4
> > byte length.
> 
> Hmm, NFIT has a 2 byte type and a 2 byte length, so its one more
> permutation. I happened to reinvent sub-table parsing in the NFIT
> driver, but it might be nice in the future to refactor that to use the
> common parsing.
> 
> >
> > Enhance the subtable parsing in acpi_parse_entries_array() so that it can
> > handle these new HMAT subtables.
> >
> > Signed-off-by: Ross Zwisler 
> > ---
> >  drivers/acpi/tables.c | 52 
> > ---
> >  1 file changed, 41 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> > index 80ce2a7d224b..f777b94c234a 100644
> > --- a/drivers/acpi/tables.c
> > +++ b/drivers/acpi/tables.c
> > @@ -218,6 +218,33 @@ void acpi_table_print_madt_entry(struct 
> > acpi_subtable_header *header)
> > }
> >  }
> >
> > +static unsigned long __init
> > +acpi_get_entry_type(char *id, void *entry)
> > +{
> > +   if (strncmp(id, ACPI_SIG_HMAT, 4) == 0)
> > +   return ((struct acpi_hmat_structure *)entry)->type;
> > +   else
> > +   return ((struct acpi_subtable_header *)entry)->type;
> > +}
> 
> It seems inefficient to make all checks keep asking "is HMAT?".

Well, ideally, the signature should be checked once.  I guess that can be
arranged for here.

> Especially if we want to extend this to other table types should we
> instead setup and pass a pair of function pointers to parse the
> sub-table format?

Function pointers may be too much even. :-)

Thanks,
Rafael



Re: [PATCH v8 4/8] intel_sgx: driver for Intel Software Guard Extensions

2017-12-15 Thread Philippe Ombredanne
Jarkko, Suresh,

On Fri, Dec 15, 2017 at 9:27 PM, Jarkko Sakkinen
 wrote:
> Intel SGX is a set of CPU instructions that can be used by applications
> to set aside private regions of code and data.  The code outside the
> enclave is disallowed to access the memory inside the enclave by the CPU
> access control.
[...]

> Signed-off-by: Jarkko Sakkinen 
> Tested-by: Serge Ayoun 

[...]

> --- /dev/null
> +++ b/arch/x86/include/asm/sgx.h
> @@ -0,0 +1,233 @@
> +/*
> + * 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-2017 Intel Corporation.
> + *
> + * 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.
> + *
> + * Contact Information:
> + * Jarkko Sakkinen 
> + * Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> + *
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016-2017 Intel Corporation.
> + *
> + * 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.
> + *
> + * Authors:
> + *
> + * Jarkko Sakkinen 
> + * Suresh Siddha 
> + */


Would you be kind enough to use the SPDX tags instead of this fine but
super long (40+ lines) legalese? This is the new way as documented in
Thomas [1] patches and already adopted by other Intel contributors.

Thank you for your kind consideration!

[1] https://lkml.org/lkml/2017/12/4/934

CC: Vinod Koul 
CC: Jessica Marz 
-- 
Cordially
Philippe Ombredanne


Re: [PATCH] ACPI / CPPC: remove initial assignment of pcc_ss_data

2017-12-15 Thread Rafael J. Wysocki
On Saturday, December 9, 2017 12:59:49 AM CET Colin King wrote:
> From: Colin Ian King 
> 
> The initialization of pcc_ss_data from pcc_data[pcc_ss_id] before
> pcc_ss_id is being range checked could lead to an out-of-bounds array
> read.  This very same initialization is also being performed after
> the range check on pcc_ss_id, so we can just remove this problematic
> and also redundant assignment to fix the issue.
> 
> Detected by cppcheck:
> warning: Value stored to 'pcc_ss_data' during its initialization is never
> read
> 
> Fixes: commit 85b1407bf6d2 ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC 
> subspace IDs")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/acpi/cppc_acpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 30e84cc600ae..06ea4749ebd9 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -1171,7 +1171,7 @@ int cppc_set_perf(int cpu, struct cppc_perf_ctrls 
> *perf_ctrls)
>   struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpu);
>   struct cpc_register_resource *desired_reg;
>   int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu);
> - struct cppc_pcc_data *pcc_ss_data = pcc_data[pcc_ss_id];
> + struct cppc_pcc_data *pcc_ss_data;
>   int ret = 0;
>  
>   if (!cpc_desc || pcc_ss_id < 0) {
> 

Applied, thanks!



Re: [PATCH] ACPI / CPPC: Fix negative array index read in cppc_set_perf

2017-12-15 Thread Rafael J. Wysocki
On Wednesday, December 13, 2017 11:45:41 PM CET Gustavo A. R. Silva wrote:
> If pcc_ss_id is less than 0, there is a negative array index read
> before verifying pcc_ss_id is not a negative value.
> 
> Fix this by removing the code that triggers this issue.
> 
> Notice that this code is already properly placed after the check
> on pcc_ss_id at line 1182: pcc_ss_data = pcc_data[pcc_ss_id];
> 
> Addresses-Coverity-ID: 1426090 ("Negative array index read")
> Fixes: 1ecbd7170d65 ("ACPI / CPPC: Fix KASAN global out of bounds warning")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/acpi/cppc_acpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 30e84cc..06ea474 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -1171,7 +1171,7 @@ int cppc_set_perf(int cpu, struct cppc_perf_ctrls 
> *perf_ctrls)
>   struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpu);
>   struct cpc_register_resource *desired_reg;
>   int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu);
> - struct cppc_pcc_data *pcc_ss_data = pcc_data[pcc_ss_id];
> + struct cppc_pcc_data *pcc_ss_data;
>   int ret = 0;
>  
>   if (!cpc_desc || pcc_ss_id < 0) {
> 

I applied a patch from Coling Ian King that did the same thing and was
posted eaelier.

Thanks,
Rafael




Re: [PATCH 04/17] mm: pass the vmem_altmap to arch_add_memory and __add_pages

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> We can just pass this on instead of having to do a radix tree lookup
> without proper locking 2 levels into the callchain.
>
> Signed-off-by: Christoph Hellwig 

Yeah, the lookup of vmem_altmap is too magical and surprising this is better.

Reviewed-by: Dan Williams 


Re: [PATCH 03/17] mm: don't export __add_pages

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> This function isn't used by any modules, and is only to be called
> from core MM code.  This includes the calls for the add_pages wrapper
> that might be inlined.
>
> Signed-off-by: Christoph Hellwig 

Looks good,

Reviewed-by: Dan Williams 


Re: [PATCH 02/17] mm: don't export arch_add_memory

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> Only x86_64 and sh export this symbol, and it is not used by any
> modular code.
>
> Signed-off-by: Christoph Hellwig 

Looks good,

Reviewed-by: Dan Williams 


Re: [PATCH 01/17] memremap: provide stubs for vmem_altmap_offset and vmem_altmap_free

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig  wrote:
> Currently all calls to those functions are eliminated by the compiler when
> CONFIG_ZONE_DEVICE is not set, but this soon won't be the case.
>
> Signed-off-by: Christoph Hellwig 

Looks good,

Reviewed-by: Dan Williams 


Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Dan Williams
On Fri, Dec 15, 2017 at 5:10 PM, Linus Torvalds
 wrote:
> On Fri, Dec 15, 2017 at 4:29 PM, Dan Williams  
> wrote:
>> So do you want to do a straight revert of these that went in for 4.15:
>
> I think that's the right thing to do, but would want to verify that
> there are no *other* issues than just the attempt at PKRU.
>
> The commit message does talk about PAGE_USER, and as mentioned I do
> think that's a good thing to check, I just don't think it should be
> done this way,
>
> Was there something else going behind these commits? Because if not,
> let's revert and then perhaps later introduce a more targeted thing?

Yes, these three can be safely reverted.

5c9d2d5c269c mm: replace pte_write with pte_access_permitted...
c7da82b894e9 mm: replace pmd_write with pmd_access_permitted...
e7fe7b5cae90 mm: replace pud_write with pud_access_permitted...

They were part of a 4 patch series where this lead one below is the
one fix we actually need.

1501899a898d mm: fix device-dax pud write-faults triggered by...

---

Now, the original access permitted was born out of a cleanup to
introduce pte_allows_gup(), this is where the PAGE_USER check came
from:

1874f6895c92 x86/mm/gup: Simplify get_user_pages() PTE bit handling

...and that helper later grew pkey check support here:

   33a709b25a76 mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys

...sometime later it was all renamed and made kernel-global here when
the x86 gup implementation was converted to use the common
implementation:

e7884f8ead4a mm/gup: Move permission checks into helpers

All this to say that these are not revert candidates and need
incremental patches if we want to back out the pkey checking for the
gup-fast path and re-work the PAGE_USER checking.


Re: [PATCH] ip6_gre: fix a pontential issue in ip6erspan_rcv

2017-12-15 Thread 严海双


> On 2017年12月16日, at 上午3:11, David Miller  wrote:
> 
> From: Haishuang Yan 
> Date: Fri, 15 Dec 2017 10:46:38 +0800
> 
>> pskb_may_pull() can change skb->data, so we need to load ipv6h/ershdr at
>> the right place.
>> 
>> Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
>> Cc: William Tu 
>> Signed-off-by: Haishuang Yan 
> 
> The mentioned commit ID only exists in net-next, and this patch does not apply
> cleanly there.
> 

Okay, I will send v2 commit rebased on latest master and with prefix [net-next].

Thanks.





Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Dave Hansen
On 12/15/2017 05:10 PM, Linus Torvalds wrote:
> Because *if* we want to check protection keys, I think we should do
> that at the vma layer, partly exactly because the exact implementation
> of protection keys is so architecture-specific, and partly because I
> don't think it makes sense to check them for every page anyway.

So, there are VMA checks against protection keys.  The problem _here_ is
that we are checking against the VMA (and correctly skipping the PKRU
checks) and then _mistakenly_ applying the PTE checks against PKRU.

I think the reason we needed VMA and PTE checks was the
get_user_pages_fast() path not having a VMA.

I need to go re-read the commits, though.


[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

2017-12-15 Thread Brian Norris
I've found that on Google's "Kevin" Chromebook, the rt5514 codec might
not be set up completely, yet its device is still present, and therefore
its PM suspend/resume is called. This hits a NULL pointer exception,
since we never had the chance to set our drvdata pointer.

This resolves crashes seen when trying to resume my system.

Fixes: e9c50aa6bd39 ("ASoC: rt5514-spi: check irq status to schedule data copy 
in resume function")
Signed-off-by: Brian Norris 
---
This is a v4.15-rc1 regression

 sound/soc/codecs/rt5514-spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/rt5514-spi.c b/sound/soc/codecs/rt5514-spi.c
index 2df91db765ac..9255afcf2c3a 100644
--- a/sound/soc/codecs/rt5514-spi.c
+++ b/sound/soc/codecs/rt5514-spi.c
@@ -482,7 +482,7 @@ static int __maybe_unused rt5514_resume(struct device *dev)
if (device_may_wakeup(dev))
disable_irq_wake(irq);
 
-   if (rt5514_dsp->substream) {
+   if (rt5514_dsp && rt5514_dsp->substream) {
rt5514_spi_burst_read(RT5514_IRQ_CTRL, (u8 *), sizeof(buf));
if (buf[0] & RT5514_IRQ_STATUS_BIT)
rt5514_schedule_copy(rt5514_dsp);
-- 
2.15.1.504.g5279b80103-goog



Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Linus Torvalds
On Fri, Dec 15, 2017 at 4:29 PM, Dan Williams  wrote:
> So do you want to do a straight revert of these that went in for 4.15:

I think that's the right thing to do, but would want to verify that
there are no *other* issues than just the attempt at PKRU.

The commit message does talk about PAGE_USER, and as mentioned I do
think that's a good thing to check, I just don't think it should be
done this way,

Was there something else going behind these commits? Because if not,
let's revert and then perhaps later introduce a more targeted thing?

Also, aren't the protection keys encoded in the vma?

Because *if* we want to check protection keys, I think we should do
that at the vma layer, partly exactly because the exact implementation
of protection keys is so architecture-specific, and partly because I
don't think it makes sense to check them for every page anyway.

   Linus


Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

2017-12-15 Thread Linus Torvalds
On Fri, Dec 15, 2017 at 4:31 PM, Al Viro  wrote:
>>
>> The fact is, if we have non-user mappings in the user part of the
>> address space, we _need_ to teach access_ok() about them, because
>> fundamentally any "get_user()/put_user()" will happily ignore the lack
>> of PAGE_USER (since those happen from kernel space).
>
> Details, please - how *can* access_ok() be taught of that?

We'd have to do something like put the !PAGE_USER mapping at the top
of the user address space, and then simply make user_addr_max()
smaller than the actual user page table size.

Or some other silly hack.

I do not believe there is any sane way to have !PAGE_USER in
_general_, if you actually want to limit access to it.

(We _could_ use !PAGE_USER for things that aren't really strictly
about security - ie  we could have used it for the NUMA balancing
instead of using the P bit, and just let put_user/get_user blow
through them).

 Linus


  1   2   3   4   5   6   7   8   9   10   >