Re: [PATCH 10/10] softirq: Remove __ARCH_SET_SOFTIRQ_PENDING

[Martin Schwidefsky]

On Thu, 29 Mar 2018 20:08:36 +0200
Peter Zijlstra  wrote:

> On Thu, Mar 29, 2018 at 04:53:43PM +0200, Martin Schwidefsky wrote:
> > The lowcore optimization for softirq_pending field is not really needed,
> > just nice to have. But if there is a strong reason to make a common
> > definition for it we can certainly do that.  
> 
> A slightly related question; would it make sense to move all kernel
> static per-cpu stuff into lowcore, or is that asking for too much
> trickery?
 
The space in lowcore is quite limited, for zArch the structure is 8K with
many pre-defined fields. I fear that putting all of the static per-cpu
stuff in there is too much. 

So far I used the lowcore as optimization for selected per-cpu fields
which are performance relevant.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH 10/10] softirq: Remove __ARCH_SET_SOFTIRQ_PENDING

[Martin Schwidefsky]

On Thu, 29 Mar 2018 20:08:36 +0200
Peter Zijlstra  wrote:

> On Thu, Mar 29, 2018 at 04:53:43PM +0200, Martin Schwidefsky wrote:
> > The lowcore optimization for softirq_pending field is not really needed,
> > just nice to have. But if there is a strong reason to make a common
> > definition for it we can certainly do that.  
> 
> A slightly related question; would it make sense to move all kernel
> static per-cpu stuff into lowcore, or is that asking for too much
> trickery?
 
The space in lowcore is quite limited, for zArch the structure is 8K with
many pre-defined fields. I fear that putting all of the static per-cpu
stuff in there is too much. 

So far I used the lowcore as optimization for selected per-cpu fields
which are performance relevant.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [GIT PULL] Andes(nds32) Port for Linux 4.17

[Greentime Hu]

2018-04-03 0:04 GMT+08:00 Linus Torvalds :
> On Sun, Apr 1, 2018 at 11:01 PM, Greentime Hu  wrote:
>>
>> This tag contains the core nds32 Linux port(including interrupt controller
>> driver and timer driver), which has been through 7 rounds of review on 
>> mailing
>> list.
>
> Can I get an overview of the nds32 architecture (uses, quirks, reasons
> for existing?) to add to the initial merge message? Just an overview,
> not some kind of architecture manual thing.
>
> Yeah, yeah, I can google it myself and write something up, but it's
> the kind of information I'd like to see when merging an architecture I
> hadn't really ever heard about, and I suspect most others haven't
> either.
>

Hi, Linus:

Andes nds32 architecture supports Linux for Andes's N10, D10, N13,
N15, D15 processor cores.

Based on the patented 16/32-bit AndeStar RISC-like architecture, we
designed the configurable AndesCore series of embedded processor
families. AndesCores range from highly performance-efficient
small-footprint cores for microcontrollers and deeply-embedded
applications to 1GHz+ cores running Linux, covering general-purpose
N-series cores for a wide range of computing need, DSP-capable
D-series cores for digital signal control, instruction-extensible
E-series cores for application-specific acceleration, and secure
S-series cores for best protection of the most valuable.

Our customers together have shipped over 2.5 billion SoC’s with Andes
processors embedded (including non-MMU IP cores). It will help our
customers to get better Linux support if we are merged into mainline.

Re: [GIT PULL] Andes(nds32) Port for Linux 4.17

[Greentime Hu]

2018-04-03 0:04 GMT+08:00 Linus Torvalds :
> On Sun, Apr 1, 2018 at 11:01 PM, Greentime Hu  wrote:
>>
>> This tag contains the core nds32 Linux port(including interrupt controller
>> driver and timer driver), which has been through 7 rounds of review on 
>> mailing
>> list.
>
> Can I get an overview of the nds32 architecture (uses, quirks, reasons
> for existing?) to add to the initial merge message? Just an overview,
> not some kind of architecture manual thing.
>
> Yeah, yeah, I can google it myself and write something up, but it's
> the kind of information I'd like to see when merging an architecture I
> hadn't really ever heard about, and I suspect most others haven't
> either.
>

Hi, Linus:

Andes nds32 architecture supports Linux for Andes's N10, D10, N13,
N15, D15 processor cores.

Based on the patented 16/32-bit AndeStar RISC-like architecture, we
designed the configurable AndesCore series of embedded processor
families. AndesCores range from highly performance-efficient
small-footprint cores for microcontrollers and deeply-embedded
applications to 1GHz+ cores running Linux, covering general-purpose
N-series cores for a wide range of computing need, DSP-capable
D-series cores for digital signal control, instruction-extensible
E-series cores for application-specific acceleration, and secure
S-series cores for best protection of the most valuable.

Our customers together have shipped over 2.5 billion SoC’s with Andes
processors embedded (including non-MMU IP cores). It will help our
customers to get better Linux support if we are merged into mainline.

Re: [PATCH v8 42/42] ARM: dts: da850: Add clocks

[Sekhar Nori]

On Monday 02 April 2018 09:45 PM, David Lechner wrote:
> On 04/02/2018 06:12 AM, Sekhar Nori wrote:
>> On Friday 16 March 2018 10:50 PM, David Lechner wrote:
>>> On 03/15/2018 09:52 PM, David Lechner wrote:
 This adds clock provider nodes for da850 and wires them up to all of
 the
 devices.

 Signed-off-by: David Lechner 
 ---
>>>
>>> ...
>>>
>>> This is the mcasp0: mcasp@10 node...
>>>
 @@ -560,6 +720,7 @@
    dmas = < 1 1>,
    < 0 1>;
    dma-names = "tx", "rx";
 +    clocks = < 7>;
>>>
>>> After some testing, it looks like it needs to be:
>>>
>>> +    power-domains = < 7>;
>>>
>>> instead of
>>>
>>> +    clocks = < 7>;
>>
>> We should probably have both clocks and power-domains properties for all
>> PSC clocks. This way, the driver can change without a corresponding DT
>> update dependency.
>>
>> Thanks,
>> Sekhar
>>
> 
> That's fine with me. I just didn't know how people felt about using
> properties
> that are not documented.

Good point. How to ease documentation for generic properties like these
was discussed in the past, but there is no guidance in
Documentation/devicetree/bindings that I can see.

So, in the interest of reduced controversy, its probably better to do
what you already have and only populate properties already documented in
the bindings.

Thanks,
Sekhar

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

[Alex Vesker]

On 4/2/2018 12:12 PM, Jiri Pirko wrote:

Fri, Mar 30, 2018 at 05:11:29PM CEST, and...@lunn.ch wrote:

Please see:
http://patchwork.ozlabs.org/project/netdev/list/?series=36524

I bevieve that the solution in the patchset could be used for
your usecase too.

Hi Jiri

https://lkml.org/lkml/2018/3/20/436

How well does this API work for a 2Gbyte snapshot?

Ccing Alex who did the tests.


I didn't check the performance for such a large snapshot.
From my measurement it takes 0.09s for 1 MB of data this means
about ~3m.
This can be tuned and improved since this is a socket application.


Andrew

Re: [PATCH v8 42/42] ARM: dts: da850: Add clocks

[Sekhar Nori]

On Monday 02 April 2018 09:45 PM, David Lechner wrote:
> On 04/02/2018 06:12 AM, Sekhar Nori wrote:
>> On Friday 16 March 2018 10:50 PM, David Lechner wrote:
>>> On 03/15/2018 09:52 PM, David Lechner wrote:
 This adds clock provider nodes for da850 and wires them up to all of
 the
 devices.

 Signed-off-by: David Lechner 
 ---
>>>
>>> ...
>>>
>>> This is the mcasp0: mcasp@10 node...
>>>
 @@ -560,6 +720,7 @@
    dmas = < 1 1>,
    < 0 1>;
    dma-names = "tx", "rx";
 +    clocks = < 7>;
>>>
>>> After some testing, it looks like it needs to be:
>>>
>>> +    power-domains = < 7>;
>>>
>>> instead of
>>>
>>> +    clocks = < 7>;
>>
>> We should probably have both clocks and power-domains properties for all
>> PSC clocks. This way, the driver can change without a corresponding DT
>> update dependency.
>>
>> Thanks,
>> Sekhar
>>
> 
> That's fine with me. I just didn't know how people felt about using
> properties
> that are not documented.

Good point. How to ease documentation for generic properties like these
was discussed in the past, but there is no guidance in
Documentation/devicetree/bindings that I can see.

So, in the interest of reduced controversy, its probably better to do
what you already have and only populate properties already documented in
the bindings.

Thanks,
Sekhar

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

[Alex Vesker]

On 4/2/2018 12:12 PM, Jiri Pirko wrote:

Fri, Mar 30, 2018 at 05:11:29PM CEST, and...@lunn.ch wrote:

Please see:
http://patchwork.ozlabs.org/project/netdev/list/?series=36524

I bevieve that the solution in the patchset could be used for
your usecase too.

Hi Jiri

https://lkml.org/lkml/2018/3/20/436

How well does this API work for a 2Gbyte snapshot?

Ccing Alex who did the tests.


I didn't check the performance for such a large snapshot.
From my measurement it takes 0.09s for 1 MB of data this means
about ~3m.
This can be tuned and improved since this is a socket application.


Andrew

linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

net/rxrpc/call_object.c: In function 'rxrpc_rcu_destroy_call':
net/rxrpc/call_object.c:661:3: error: implicit declaration of function 
'wake_up_atomic_t'; did you mean 'wake_up_bit'? 
[-Werror=implicit-function-declaration]
   wake_up_atomic_t(>nr_calls);
   ^~~~
   wake_up_bit
net/rxrpc/call_object.c: In function 'rxrpc_destroy_all_calls':
net/rxrpc/call_object.c:728:2: error: implicit declaration of function 
'wait_on_atomic_t'; did you mean 'wait_on_bit'? 
[-Werror=implicit-function-declaration]
  wait_on_atomic_t(>nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
  ^~~~
  wait_on_bit
net/rxrpc/call_object.c:728:37: error: 'atomic_t_wait' undeclared (first use in 
this function); did you mean 'atomic_long_t'?
  wait_on_atomic_t(>nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
 ^
 atomic_long_t
net/rxrpc/call_object.c:728:37: note: each undeclared identifier is reported 
only once for each function it appears in
net/rxrpc/call_accept.c: In function 'rxrpc_discard_prealloc':
net/rxrpc/call_accept.c:223:4: error: implicit declaration of function 
'wake_up_atomic_t'; did you mean 'wake_up_bit'? 
[-Werror=implicit-function-declaration]
wake_up_atomic_t(>nr_conns);
^~~~
wake_up_bit

Caused by commit

  9b8cce52c4b5 ("sched/wait: Remove the wait_on_atomic_t() API")

interacting with commits

  d3be4d244330 ("xrpc: Fix potential call vs socket/net destruction race")
  31f5f9a1691e ("rxrpc: Fix apparent leak of rxrpc_local objects")

from the net-next tree.

Haven't we figured out how to remove/change APIs yet? :-(

That tip tree commit is now in Linus' tree (merged since I started this
morning) so the net-next tree will need the below patch (or something
similar when it is merged.

I have applied the following merge fix patch (this may need more work):

From: Stephen Rothwell 
Date: Tue, 3 Apr 2018 15:34:48 +1000
Subject: [PATCH] sched/wait: merge fix up for wait_on_atomic() API removal

Signed-off-by: Stephen Rothwell 
---
 net/rxrpc/call_accept.c | 2 +-
 net/rxrpc/call_object.c | 4 ++--
 net/rxrpc/conn_object.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index f67017dcb25e..a9a9be5519b9 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -220,7 +220,7 @@ void rxrpc_discard_prealloc(struct rxrpc_sock *rx)
write_unlock(>conn_lock);
kfree(conn);
if (atomic_dec_and_test(>nr_conns))
-   wake_up_atomic_t(>nr_conns);
+   wake_up_var(>nr_conns);
tail = (tail + 1) & (size - 1);
}
 
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index f721c2b7e234..f6734d8cb01a 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -658,7 +658,7 @@ static void rxrpc_rcu_destroy_call(struct rcu_head *rcu)
kfree(call->rxtx_annotations);
kmem_cache_free(rxrpc_call_jar, call);
if (atomic_dec_and_test(>nr_calls))
-   wake_up_atomic_t(>nr_calls);
+   wake_up_var(>nr_calls);
 }
 
 /*
@@ -725,5 +725,5 @@ void rxrpc_destroy_all_calls(struct rxrpc_net *rxnet)
write_unlock(>call_lock);
 
atomic_dec(>nr_calls);
-   wait_on_atomic_t(>nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
+   wait_var_event(>nr_calls, !atomic_read(>nr_calls));
 }
diff --git a/net/rxrpc/conn_object.c b/net/rxrpc/conn_object.c
index 0950ee3d26f5..4c77a78a252a 100644
--- a/net/rxrpc/conn_object.c
+++ b/net/rxrpc/conn_object.c
@@ -367,7 +367,7 @@ static void rxrpc_destroy_connection(struct rcu_head *rcu)
rxrpc_put_peer(conn->params.peer);
 
if (atomic_dec_and_test(>params.local->rxnet->nr_conns))
-   wake_up_atomic_t(>params.local->rxnet->nr_conns);
+   wake_up_var(>params.local->rxnet->nr_conns);
rxrpc_put_local(conn->params.local);
 
kfree(conn);
@@ -482,6 +482,6 @@ void rxrpc_destroy_all_connections(struct rxrpc_net *rxnet)
/* We need to wait for the connections to be destroyed by RCU as they
 * pin things that we still need to get rid of.
 */
-   wait_on_atomic_t(>nr_conns, atomic_t_wait, TASK_UNINTERRUPTIBLE);
+   wait_var_event(>nr_conns, !atomic_read(>nr_conns));
_leave("");
 }
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell


pgpevV6eCQKBa.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

net/rxrpc/call_object.c: In function 'rxrpc_rcu_destroy_call':
net/rxrpc/call_object.c:661:3: error: implicit declaration of function 
'wake_up_atomic_t'; did you mean 'wake_up_bit'? 
[-Werror=implicit-function-declaration]
   wake_up_atomic_t(>nr_calls);
   ^~~~
   wake_up_bit
net/rxrpc/call_object.c: In function 'rxrpc_destroy_all_calls':
net/rxrpc/call_object.c:728:2: error: implicit declaration of function 
'wait_on_atomic_t'; did you mean 'wait_on_bit'? 
[-Werror=implicit-function-declaration]
  wait_on_atomic_t(>nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
  ^~~~
  wait_on_bit
net/rxrpc/call_object.c:728:37: error: 'atomic_t_wait' undeclared (first use in 
this function); did you mean 'atomic_long_t'?
  wait_on_atomic_t(>nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
 ^
 atomic_long_t
net/rxrpc/call_object.c:728:37: note: each undeclared identifier is reported 
only once for each function it appears in
net/rxrpc/call_accept.c: In function 'rxrpc_discard_prealloc':
net/rxrpc/call_accept.c:223:4: error: implicit declaration of function 
'wake_up_atomic_t'; did you mean 'wake_up_bit'? 
[-Werror=implicit-function-declaration]
wake_up_atomic_t(>nr_conns);
^~~~
wake_up_bit

Caused by commit

  9b8cce52c4b5 ("sched/wait: Remove the wait_on_atomic_t() API")

interacting with commits

  d3be4d244330 ("xrpc: Fix potential call vs socket/net destruction race")
  31f5f9a1691e ("rxrpc: Fix apparent leak of rxrpc_local objects")

from the net-next tree.

Haven't we figured out how to remove/change APIs yet? :-(

That tip tree commit is now in Linus' tree (merged since I started this
morning) so the net-next tree will need the below patch (or something
similar when it is merged.

I have applied the following merge fix patch (this may need more work):

From: Stephen Rothwell 
Date: Tue, 3 Apr 2018 15:34:48 +1000
Subject: [PATCH] sched/wait: merge fix up for wait_on_atomic() API removal

Signed-off-by: Stephen Rothwell 
---
 net/rxrpc/call_accept.c | 2 +-
 net/rxrpc/call_object.c | 4 ++--
 net/rxrpc/conn_object.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index f67017dcb25e..a9a9be5519b9 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -220,7 +220,7 @@ void rxrpc_discard_prealloc(struct rxrpc_sock *rx)
write_unlock(>conn_lock);
kfree(conn);
if (atomic_dec_and_test(>nr_conns))
-   wake_up_atomic_t(>nr_conns);
+   wake_up_var(>nr_conns);
tail = (tail + 1) & (size - 1);
}
 
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index f721c2b7e234..f6734d8cb01a 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -658,7 +658,7 @@ static void rxrpc_rcu_destroy_call(struct rcu_head *rcu)
kfree(call->rxtx_annotations);
kmem_cache_free(rxrpc_call_jar, call);
if (atomic_dec_and_test(>nr_calls))
-   wake_up_atomic_t(>nr_calls);
+   wake_up_var(>nr_calls);
 }
 
 /*
@@ -725,5 +725,5 @@ void rxrpc_destroy_all_calls(struct rxrpc_net *rxnet)
write_unlock(>call_lock);
 
atomic_dec(>nr_calls);
-   wait_on_atomic_t(>nr_calls, atomic_t_wait, TASK_UNINTERRUPTIBLE);
+   wait_var_event(>nr_calls, !atomic_read(>nr_calls));
 }
diff --git a/net/rxrpc/conn_object.c b/net/rxrpc/conn_object.c
index 0950ee3d26f5..4c77a78a252a 100644
--- a/net/rxrpc/conn_object.c
+++ b/net/rxrpc/conn_object.c
@@ -367,7 +367,7 @@ static void rxrpc_destroy_connection(struct rcu_head *rcu)
rxrpc_put_peer(conn->params.peer);
 
if (atomic_dec_and_test(>params.local->rxnet->nr_conns))
-   wake_up_atomic_t(>params.local->rxnet->nr_conns);
+   wake_up_var(>params.local->rxnet->nr_conns);
rxrpc_put_local(conn->params.local);
 
kfree(conn);
@@ -482,6 +482,6 @@ void rxrpc_destroy_all_connections(struct rxrpc_net *rxnet)
/* We need to wait for the connections to be destroyed by RCU as they
 * pin things that we still need to get rid of.
 */
-   wait_on_atomic_t(>nr_conns, atomic_t_wait, TASK_UNINTERRUPTIBLE);
+   wait_var_event(>nr_conns, !atomic_read(>nr_conns));
_leave("");
 }
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell


pgpevV6eCQKBa.pgp
Description: OpenPGP digital signature

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

[Kishon Vijay Abraham I]

On Tuesday 03 April 2018 01:07 AM, Niklas Cassel wrote:
> On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote:
>>> Since a 64-bit BAR consists of a BAR pair, we need to write to both
>>> BARs in the BAR pair to setup the BAR properly.
>>>
>>> Signed-off-by: Niklas Cassel 
>>> ---
>>>  drivers/pci/dwc/pcie-designware-ep.c | 11 +--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
>>> b/drivers/pci/dwc/pcie-designware-ep.c
>>> index 5a0bb53c795c..571b90f88d84 100644
>>> --- a/drivers/pci/dwc/pcie-designware-ep.c
>>> +++ b/drivers/pci/dwc/pcie-designware-ep.c
>>> @@ -138,8 +138,15 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 
>>> func_no,
>>> return ret;
>>>  
>>> dw_pcie_dbi_ro_wr_en(pci);
>>> -   dw_pcie_writel_dbi2(pci, reg, size - 1);
>>> -   dw_pcie_writel_dbi(pci, reg, flags);
>>> +   if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
>>> +   dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
>>> +   dw_pcie_writel_dbi(pci, reg, flags);
>>> +   dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
>>> +   dw_pcie_writel_dbi(pci, reg + 4, 0);
>>> +   } else {
>>> +   dw_pcie_writel_dbi2(pci, reg, size - 1);
>>> +   dw_pcie_writel_dbi(pci, reg, flags);
>>> +   }
>>
>>
>> I think this should work too?
>>  dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
>>  dw_pcie_writel_dbi(pci, reg, flags);
>>
>>  if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
>>  dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
>>  dw_pcie_writel_dbi(pci, reg + 4, 0);
>>  }
>>
> 
> Hello Kishon,
> 
> I agree, your suggestion is more neat.
> 
> 
> Kishon, please tell me if you insist that the long if-statement
> in pci_epc_set_bar() should be split, since there are 5 different
> conditions. Because imho, having 5 succeeding if-statements isn't

I'm okay as it is as well if Lorenzo/Bjorn is also fine with it.

Thanks
Kishon

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

[Kishon Vijay Abraham I]

On Tuesday 03 April 2018 01:07 AM, Niklas Cassel wrote:
> On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote:
>>> Since a 64-bit BAR consists of a BAR pair, we need to write to both
>>> BARs in the BAR pair to setup the BAR properly.
>>>
>>> Signed-off-by: Niklas Cassel 
>>> ---
>>>  drivers/pci/dwc/pcie-designware-ep.c | 11 +--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
>>> b/drivers/pci/dwc/pcie-designware-ep.c
>>> index 5a0bb53c795c..571b90f88d84 100644
>>> --- a/drivers/pci/dwc/pcie-designware-ep.c
>>> +++ b/drivers/pci/dwc/pcie-designware-ep.c
>>> @@ -138,8 +138,15 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 
>>> func_no,
>>> return ret;
>>>  
>>> dw_pcie_dbi_ro_wr_en(pci);
>>> -   dw_pcie_writel_dbi2(pci, reg, size - 1);
>>> -   dw_pcie_writel_dbi(pci, reg, flags);
>>> +   if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
>>> +   dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
>>> +   dw_pcie_writel_dbi(pci, reg, flags);
>>> +   dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
>>> +   dw_pcie_writel_dbi(pci, reg + 4, 0);
>>> +   } else {
>>> +   dw_pcie_writel_dbi2(pci, reg, size - 1);
>>> +   dw_pcie_writel_dbi(pci, reg, flags);
>>> +   }
>>
>>
>> I think this should work too?
>>  dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
>>  dw_pcie_writel_dbi(pci, reg, flags);
>>
>>  if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
>>  dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
>>  dw_pcie_writel_dbi(pci, reg + 4, 0);
>>  }
>>
> 
> Hello Kishon,
> 
> I agree, your suggestion is more neat.
> 
> 
> Kishon, please tell me if you insist that the long if-statement
> in pci_epc_set_bar() should be split, since there are 5 different
> conditions. Because imho, having 5 succeeding if-statements isn't

I'm okay as it is as well if Lorenzo/Bjorn is also fine with it.

Thanks
Kishon

[PATCH] drm/sti: Depend on OF rather than selecting it

[Oliver O'Halloran]

Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg
structure") reworked some code inside of this driver and made it select
CONFIG_OF. This results in the entire OF layer being enabled when
building an allmodconfig on ia64. OF on ia64 is completely unsupported
so this isn't a great state of affairs.

The 0day robot noticed a link-time failure on ia64 caused by
using of_node_to_nid() in an otherwise unrelated driver. The
generic fallback for of_node_to_nid() only exists when:

defined(CONFIG_OF) && defined(CONFIG_NUMA) == false

Since CONFIG_NUMA is usually selected for IA64 we get the link failure.
Fix this by making the driver depend on OF rather than selecting it,
odds are that was the original intent.

Link: https://lists.01.org/pipermail/kbuild-all/2018-March/045172.html
Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure")
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-i...@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Oliver O'Halloran 
---
Cc`ed to stable since the ia64 guys might want it backported. I'm not
bothered if it just goes into mainline.
---
 drivers/gpu/drm/sti/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index cca4b3c9aeb5..1963cc1b1cc5 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,6 @@
 config DRM_STI
tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
-   depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
+   depends on OF && DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
select RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
@@ -8,6 +8,5 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
-   select OF
help
  Choose this option to enable DRM on STM stiH4xx chipset
-- 
2.9.5

[PATCH] drm/sti: Depend on OF rather than selecting it

[Oliver O'Halloran]

Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg
structure") reworked some code inside of this driver and made it select
CONFIG_OF. This results in the entire OF layer being enabled when
building an allmodconfig on ia64. OF on ia64 is completely unsupported
so this isn't a great state of affairs.

The 0day robot noticed a link-time failure on ia64 caused by
using of_node_to_nid() in an otherwise unrelated driver. The
generic fallback for of_node_to_nid() only exists when:

defined(CONFIG_OF) && defined(CONFIG_NUMA) == false

Since CONFIG_NUMA is usually selected for IA64 we get the link failure.
Fix this by making the driver depend on OF rather than selecting it,
odds are that was the original intent.

Link: https://lists.01.org/pipermail/kbuild-all/2018-March/045172.html
Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure")
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-i...@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Oliver O'Halloran 
---
Cc`ed to stable since the ia64 guys might want it backported. I'm not
bothered if it just goes into mainline.
---
 drivers/gpu/drm/sti/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index cca4b3c9aeb5..1963cc1b1cc5 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,6 @@
 config DRM_STI
tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
-   depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
+   depends on OF && DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
select RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
@@ -8,6 +8,5 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
-   select OF
help
  Choose this option to enable DRM on STM stiH4xx chipset
-- 
2.9.5

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

[Jaegeuk Kim]

On 04/03, Chao Yu wrote:
> On 2018/3/31 0:30, Jaegeuk Kim wrote:
> > Change log from v1:
> >  - add more description
> > 
> > This fixes xfstests/generic/392.
> > 
> > The failure was caused by different times between 1) one marked in the last
> > fsync(2) call and 2) the other given by roll-forward recovery after 
> > power-cut.
> > The reason was that we skipped updating inode block at 1), since its i_size
> > was recoverable along with 4KB-aligned data writes, which was fixed by:
> >   "f2fs: fix a wrong condition in f2fs_skip_inode_update"
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/f2fs.h  | 15 +++
> >  fs/f2fs/inode.c |  4 
> >  2 files changed, 19 insertions(+)
> > 
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 000f93f6767e..675c39d85111 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -664,6 +664,7 @@ struct f2fs_inode_info {
> > kprojid_t i_projid; /* id for project quota */
> > int i_inline_xattr_size;/* inline xattr size */
> > struct timespec i_crtime;   /* inode creation time */
> > +   struct timespec i_disk_time[4]; /* inode disk times */
> >  };
> >  
> >  static inline void get_extent_info(struct extent_info *ext,
> > @@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, 
> > int type)
> > f2fs_mark_inode_dirty_sync(inode, true);
> >  }
> >  
> > +static inline bool time_equal(struct timespec a, struct timespec b)
> > +{
> > +   return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
> > +}
> 
> We can use existing timespec_equal in  instead of defining a
> duplicated one?

It is defined with const parameters.

> 
> > +
> >  static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
> >  {
> > bool ret;
> > @@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct 
> > inode *inode, int dsync)
> > i_size_read(inode) & ~PAGE_MASK)
> > return false;
> >  
> > +   if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
> > +   return false;
> > +   if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
> > +   return false;
> > +   if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
> > +   return false;
> > +   if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
> > +   return false;
> > +
> > down_read(_I(inode)->i_sem);
> > ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
> > up_read(_I(inode)->i_sem);
> > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> > index 401f09ccce7e..70aba580f4b0 100644
> > --- a/fs/f2fs/inode.c
> > +++ b/fs/f2fs/inode.c
> > @@ -444,6 +444,10 @@ void update_inode(struct inode *inode, struct page 
> > *node_page)
> > if (inode->i_nlink == 0)
> > clear_inline_node(node_page);
> >  
> > +   F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
> > +   F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
> > +   F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
> > +   F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
> 
> We need initialize them in do_read_inode?

Done.
Thanks,

> 
> Thanks,
> 
> >  }
> >  
> >  void update_inode_page(struct inode *inode)
> > 

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

[Jaegeuk Kim]

On 04/03, Chao Yu wrote:
> On 2018/3/31 0:30, Jaegeuk Kim wrote:
> > Change log from v1:
> >  - add more description
> > 
> > This fixes xfstests/generic/392.
> > 
> > The failure was caused by different times between 1) one marked in the last
> > fsync(2) call and 2) the other given by roll-forward recovery after 
> > power-cut.
> > The reason was that we skipped updating inode block at 1), since its i_size
> > was recoverable along with 4KB-aligned data writes, which was fixed by:
> >   "f2fs: fix a wrong condition in f2fs_skip_inode_update"
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/f2fs.h  | 15 +++
> >  fs/f2fs/inode.c |  4 
> >  2 files changed, 19 insertions(+)
> > 
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 000f93f6767e..675c39d85111 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -664,6 +664,7 @@ struct f2fs_inode_info {
> > kprojid_t i_projid; /* id for project quota */
> > int i_inline_xattr_size;/* inline xattr size */
> > struct timespec i_crtime;   /* inode creation time */
> > +   struct timespec i_disk_time[4]; /* inode disk times */
> >  };
> >  
> >  static inline void get_extent_info(struct extent_info *ext,
> > @@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, 
> > int type)
> > f2fs_mark_inode_dirty_sync(inode, true);
> >  }
> >  
> > +static inline bool time_equal(struct timespec a, struct timespec b)
> > +{
> > +   return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
> > +}
> 
> We can use existing timespec_equal in  instead of defining a
> duplicated one?

It is defined with const parameters.

> 
> > +
> >  static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
> >  {
> > bool ret;
> > @@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct 
> > inode *inode, int dsync)
> > i_size_read(inode) & ~PAGE_MASK)
> > return false;
> >  
> > +   if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
> > +   return false;
> > +   if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
> > +   return false;
> > +   if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
> > +   return false;
> > +   if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
> > +   return false;
> > +
> > down_read(_I(inode)->i_sem);
> > ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
> > up_read(_I(inode)->i_sem);
> > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> > index 401f09ccce7e..70aba580f4b0 100644
> > --- a/fs/f2fs/inode.c
> > +++ b/fs/f2fs/inode.c
> > @@ -444,6 +444,10 @@ void update_inode(struct inode *inode, struct page 
> > *node_page)
> > if (inode->i_nlink == 0)
> > clear_inline_node(node_page);
> >  
> > +   F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
> > +   F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
> > +   F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
> > +   F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
> 
> We need initialize them in do_read_inode?

Done.
Thanks,

> 
> Thanks,
> 
> >  }
> >  
> >  void update_inode_page(struct inode *inode)
> > 

Re: [f2fs-dev] [PATCH v3] f2fs: remain written times to update inode during fsync

[Jaegeuk Kim]

Change log from v2:
 - update do_read_inode

Change log from v1:
 - add more description

This fixes xfstests/generic/392.

The failure was caused by different times between 1) one marked in the last
fsync(2) call and 2) the other given by roll-forward recovery after power-cut.
The reason was that we skipped updating inode block at 1), since its i_size
was recoverable along with 4KB-aligned data writes, which was fixed by:
  "f2fs: fix a wrong condition in f2fs_skip_inode_update"

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h  | 15 +++
 fs/f2fs/inode.c |  8 
 2 files changed, 23 insertions(+)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7102d3965fea..33be61b19a5f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -664,6 +664,7 @@ struct f2fs_inode_info {
kprojid_t i_projid; /* id for project quota */
int i_inline_xattr_size;/* inline xattr size */
struct timespec i_crtime;   /* inode creation time */
+   struct timespec i_disk_time[4]; /* inode disk times */
 };
 
 static inline void get_extent_info(struct extent_info *ext,
@@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, int 
type)
f2fs_mark_inode_dirty_sync(inode, true);
 }
 
+static inline bool time_equal(struct timespec a, struct timespec b)
+{
+   return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
+}
+
 static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
 {
bool ret;
@@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct inode 
*inode, int dsync)
i_size_read(inode) & ~PAGE_MASK)
return false;
 
+   if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
+   return false;
+   if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
+   return false;
+   if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
+   return false;
+   if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
+   return false;
+
down_read(_I(inode)->i_sem);
ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
up_read(_I(inode)->i_sem);
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 401f09ccce7e..e0d9e8f27ed2 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -284,6 +284,10 @@ static int do_read_inode(struct inode *inode)
fi->i_crtime.tv_nsec = le32_to_cpu(ri->i_crtime_nsec);
}
 
+   F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
+   F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
+   F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
+   F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
f2fs_put_page(node_page, 1);
 
stat_inc_inline_xattr(inode);
@@ -444,6 +448,10 @@ void update_inode(struct inode *inode, struct page 
*node_page)
if (inode->i_nlink == 0)
clear_inline_node(node_page);
 
+   F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
+   F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
+   F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
+   F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
 }
 
 void update_inode_page(struct inode *inode)
-- 
2.15.0.531.g2ccb3012c9-goog

Re: [f2fs-dev] [PATCH v3] f2fs: remain written times to update inode during fsync

[Jaegeuk Kim]

Change log from v2:
 - update do_read_inode

Change log from v1:
 - add more description

This fixes xfstests/generic/392.

The failure was caused by different times between 1) one marked in the last
fsync(2) call and 2) the other given by roll-forward recovery after power-cut.
The reason was that we skipped updating inode block at 1), since its i_size
was recoverable along with 4KB-aligned data writes, which was fixed by:
  "f2fs: fix a wrong condition in f2fs_skip_inode_update"

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h  | 15 +++
 fs/f2fs/inode.c |  8 
 2 files changed, 23 insertions(+)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7102d3965fea..33be61b19a5f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -664,6 +664,7 @@ struct f2fs_inode_info {
kprojid_t i_projid; /* id for project quota */
int i_inline_xattr_size;/* inline xattr size */
struct timespec i_crtime;   /* inode creation time */
+   struct timespec i_disk_time[4]; /* inode disk times */
 };
 
 static inline void get_extent_info(struct extent_info *ext,
@@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, int 
type)
f2fs_mark_inode_dirty_sync(inode, true);
 }
 
+static inline bool time_equal(struct timespec a, struct timespec b)
+{
+   return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
+}
+
 static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
 {
bool ret;
@@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct inode 
*inode, int dsync)
i_size_read(inode) & ~PAGE_MASK)
return false;
 
+   if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
+   return false;
+   if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
+   return false;
+   if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
+   return false;
+   if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
+   return false;
+
down_read(_I(inode)->i_sem);
ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
up_read(_I(inode)->i_sem);
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 401f09ccce7e..e0d9e8f27ed2 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -284,6 +284,10 @@ static int do_read_inode(struct inode *inode)
fi->i_crtime.tv_nsec = le32_to_cpu(ri->i_crtime_nsec);
}
 
+   F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
+   F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
+   F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
+   F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
f2fs_put_page(node_page, 1);
 
stat_inc_inline_xattr(inode);
@@ -444,6 +448,10 @@ void update_inode(struct inode *inode, struct page 
*node_page)
if (inode->i_nlink == 0)
clear_inline_node(node_page);
 
+   F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
+   F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
+   F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
+   F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
 }
 
 void update_inode_page(struct inode *inode)
-- 
2.15.0.531.g2ccb3012c9-goog

Re: [PATCH v3 0/2] ASoC: topology: Improve parsing hw_configs

[Kirill Marinushkin]

On 04/03/18 02:57, Pierre-Louis Bossart wrote:
>
>
> On 04/02/2018 04:17 PM, Kirill Marinushkin wrote:
>> Hello Pierre-Louis,
>>
>> I explicitly clarified with Takashi: to have this patch series merged, we 
>> need a
>> tag "Reviewed-by" from you.
> I am fine with the changes, but maybe while we are at it, we should clarify
> what mclk_direction means?

That's a good idea to have it solved within this patch series.

>
>     __u8 mclk_direction;    /* 0 for input, 1 for output */
>
> This is really awful and might benefit for additional clarity using
> codec-centric conventions.
>

I agree that having a clear naming will avoid confusion for future usage.
I see from the code, that this variable is ignored. So we have no technical
restriction on how to interpret this.
I suggest to do similar to what we did for bclk_master:

/* DAI mclk_direction */
#define SND_SOC_TPLG_MCLK_CO    0 /* for codec, mclk is output */
#define SND_SOC_TPLG_MCLK_CI  1 /* for codec, mclk is input */

> We also had a discussion internally and can't figure out why the strings are
> different from the fields in the structure, I feel it'd be simpler to align
> config and code to avoid issues but keep existing notation for backwards
> compatibility, e.g.
>
> if (strcmp(id, "mclk_freq") == 0) || strcmp(id, "mclk_rate") == 0) {
>         if (snd_config_get_string(n, ) < 0)
>                 return -EINVAL;
>
>             hw_cfg->mclk_rate = atoi(val);
>             continue;
> }

I agree with this. I will also do the same (keeping backwards-compatibility) 
for:

"format" => "fmt"
"bclk" => "bclk_master"
"bclk_freq" => "bclk_rate"
"bclk_invert" => "invert_bclk"
"fsync" => "fsync_master"
"fsync_invert" => "invert_fsync"
"fsync_freq" => "fsync_rate"
"mclk_freq" => "mclk_rate"
"mclk" => "mclk_direction"
"pm_gate_clocks" => "clock_gated"

If you agree with both proposals, I will add patches to this patch series, and
re-send as patch v4.
Or can we handle it in a better way?

>>
>> Patches [2] and [5]:
>> You already tested them. May I put a tag "Reviewed-by" with your name into 
>> them?
>>
>> Patches [3] and [6]:
>> Those are new for you; I added them to this patch series, because they are
>> logically similar to [2] and [5].
>> Could you please review these patches?
>>
>> Best Regards,
>> Kirill
>>
>> [1] [PATCH v3 0/2] ASoC: topology: Improve parsing hw_configs
>> [2] [PATCH v3 1/2] ASoC: topology: Fix bclk and fsync inversion in
>> set_link_hw_format()
>> [3] [PATCH v3 2/2] ASoC: topology: Add missing clock gating parameter when
>> parsing hw_configs
>> [4] [PATCH, alsa-lib, v3 0/2] alsa-lib: ASoC: topology: Improve parsing
>> hw_configs
>> [5] [PATCH, alsa-lib, v3 1/2] ASoC: topology: Fix bclk and fsync inversion in
>> set_link_hw_format()
>> [6] [PATCH, alsa-lib, v3 2/2] ASoC: topology: Add missing clock gating
>> parameter when parsing hw_configs
>>
>>
>> On 03/27/18 22:56, Kirill Marinushkin wrote:
>>> Hello Jaroslav, Takashi, Mark,
>>>
>>> This patch series is a resend of [1] and [2], rebased on top of the latest
>>> head. It was logical to resend them together.
>>>
>>> It includes 2 patches for linux + 2 patches for alsa-lib.
>>>
>>> Please have a look.
>>>
>>> Best Regards,
>>> Kirill
>>>
>>> [1] https://patchwork.kernel.org/patch/10250485/
>>> [2] https://patchwork.kernel.org/patch/10230611/
>>>
>>> Kirill Marinushkin (2):
>>>    ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()
>>>    ASoC: topology: Add missing clock gating parameter when parsing
>>>  hw_configs
>>>
>>>   include/uapi/sound/asoc.h | 23 ---
>>>   sound/soc/soc-topology.c  | 19 ++-
>>>   2 files changed, 34 insertions(+), 8 deletions(-)
>>>
>

Re: [PATCH v3 0/2] ASoC: topology: Improve parsing hw_configs

[Kirill Marinushkin]

On 04/03/18 02:57, Pierre-Louis Bossart wrote:
>
>
> On 04/02/2018 04:17 PM, Kirill Marinushkin wrote:
>> Hello Pierre-Louis,
>>
>> I explicitly clarified with Takashi: to have this patch series merged, we 
>> need a
>> tag "Reviewed-by" from you.
> I am fine with the changes, but maybe while we are at it, we should clarify
> what mclk_direction means?

That's a good idea to have it solved within this patch series.

>
>     __u8 mclk_direction;    /* 0 for input, 1 for output */
>
> This is really awful and might benefit for additional clarity using
> codec-centric conventions.
>

I agree that having a clear naming will avoid confusion for future usage.
I see from the code, that this variable is ignored. So we have no technical
restriction on how to interpret this.
I suggest to do similar to what we did for bclk_master:

/* DAI mclk_direction */
#define SND_SOC_TPLG_MCLK_CO    0 /* for codec, mclk is output */
#define SND_SOC_TPLG_MCLK_CI  1 /* for codec, mclk is input */

> We also had a discussion internally and can't figure out why the strings are
> different from the fields in the structure, I feel it'd be simpler to align
> config and code to avoid issues but keep existing notation for backwards
> compatibility, e.g.
>
> if (strcmp(id, "mclk_freq") == 0) || strcmp(id, "mclk_rate") == 0) {
>         if (snd_config_get_string(n, ) < 0)
>                 return -EINVAL;
>
>             hw_cfg->mclk_rate = atoi(val);
>             continue;
> }

I agree with this. I will also do the same (keeping backwards-compatibility) 
for:

"format" => "fmt"
"bclk" => "bclk_master"
"bclk_freq" => "bclk_rate"
"bclk_invert" => "invert_bclk"
"fsync" => "fsync_master"
"fsync_invert" => "invert_fsync"
"fsync_freq" => "fsync_rate"
"mclk_freq" => "mclk_rate"
"mclk" => "mclk_direction"
"pm_gate_clocks" => "clock_gated"

If you agree with both proposals, I will add patches to this patch series, and
re-send as patch v4.
Or can we handle it in a better way?

>>
>> Patches [2] and [5]:
>> You already tested them. May I put a tag "Reviewed-by" with your name into 
>> them?
>>
>> Patches [3] and [6]:
>> Those are new for you; I added them to this patch series, because they are
>> logically similar to [2] and [5].
>> Could you please review these patches?
>>
>> Best Regards,
>> Kirill
>>
>> [1] [PATCH v3 0/2] ASoC: topology: Improve parsing hw_configs
>> [2] [PATCH v3 1/2] ASoC: topology: Fix bclk and fsync inversion in
>> set_link_hw_format()
>> [3] [PATCH v3 2/2] ASoC: topology: Add missing clock gating parameter when
>> parsing hw_configs
>> [4] [PATCH, alsa-lib, v3 0/2] alsa-lib: ASoC: topology: Improve parsing
>> hw_configs
>> [5] [PATCH, alsa-lib, v3 1/2] ASoC: topology: Fix bclk and fsync inversion in
>> set_link_hw_format()
>> [6] [PATCH, alsa-lib, v3 2/2] ASoC: topology: Add missing clock gating
>> parameter when parsing hw_configs
>>
>>
>> On 03/27/18 22:56, Kirill Marinushkin wrote:
>>> Hello Jaroslav, Takashi, Mark,
>>>
>>> This patch series is a resend of [1] and [2], rebased on top of the latest
>>> head. It was logical to resend them together.
>>>
>>> It includes 2 patches for linux + 2 patches for alsa-lib.
>>>
>>> Please have a look.
>>>
>>> Best Regards,
>>> Kirill
>>>
>>> [1] https://patchwork.kernel.org/patch/10250485/
>>> [2] https://patchwork.kernel.org/patch/10230611/
>>>
>>> Kirill Marinushkin (2):
>>>    ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()
>>>    ASoC: topology: Add missing clock gating parameter when parsing
>>>  hw_configs
>>>
>>>   include/uapi/sound/asoc.h | 23 ---
>>>   sound/soc/soc-topology.c  | 19 ++-
>>>   2 files changed, 34 insertions(+), 8 deletions(-)
>>>
>

Re: [PATCH][RESEND] ASoC: Intel: atom: fix ACPI/PCI Kconfig

[Vinod Koul]

On Mon, Apr 02, 2018 at 12:06:14PM -0500, Pierre-Louis Bossart wrote:
> The split between ACPI and PCI platforms generated issues with randconfig:
> 
> with SND_SST_ATOM_HIFI2_PLATFORM_PCI=y and
> SND_SST_ATOM_HIFI2_PLATFORM=m, we get this module link failure:
> 
> ERROR: "sst_context_init"
> [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
> 
> ERROR: "sst_context_cleanup"
> [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
> 
> ERROR: "sst_alloc_drv_context"
> [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
> 
> ERROR: "intel_sst_pm" [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko]
> undefined!
> 
> ERROR: "sst_configure_runtime_pm"
> [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
> 
> To keep things simple, let's expose two configs for
> SND_SST_ATOM_HIFI2_PLATFORM_PCI and SND_SST_ATOM_HIFI2_PLATFORM_ACPI,
> which select a common SND_SST_ATOM_HIFI2_PLATFORM option. To avoid
> breaking existing solutions with the semantics change,
> SND_SST_ATOM_HIFI2_PLATFORM_ACPI uses "default ACPI" so that "make
> oldnoconfig" and "make olddefconfig" still work as expected.
> 
> Also remove mentions of Medfield while we are at it since it was
> removed recently.

Acked-By: Vinod Koul 

-- 
~Vinod

[GIT PULL] xfs: new features for 4.17

[Darrick J. Wong]

Hi Linus,

Here's the first round of fixes for XFS for 4.17.  The biggest new
features this time around are the addition of lazytime support, further
enhancement of the on-disk inode metadata verifiers, and a patch to
smooth over some of the AGFL padding problems that have intermittently
plagued users since 4.5.  I forsee sending a second pull request next
week with further bug fixes and speedups in the online scrub code and
elsewhere.

This series has been run through a full xfstests run over the weekend
and through a quick xfstests run against this morning's master, with no
major failures reported.  Let me know if there's any merge problems.

--D

The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae:

  Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-4.17-merge-1

for you to fetch changes up to dc1baa715bbfbb1902da942d06497e79b40e7bc7:

  xfs: do not log/recover swapext extent owner changes for deleted inodes 
(2018-03-29 10:19:15 -0700)


Changes for this release:
- Various cleanups and code fixes
- Implement lazytime as a mount option
- Convert various on-disk metadata checks from asserts to -EFSCORRUPTED
- Fix accounting problems with the rmap per-ag reservations
- Refactorings and cleanups for xfs_log_force
- Various bugfixes for the reflink code
- Work around v5 AGFL padding problems to prevent fs shutdowns
- Establish inode fork verifiers to inspect on-disk metadata correctness
- Various online scrub fixes
- Fix v5 swapext blowing up on deleted inodes


Brian Foster (6):
  xfs: shutdown if block allocation overruns tx reservation
  xfs: account format bouncing into rmapbt swapext tx reservation
  xfs: rename agfl perag res type to rmapbt
  xfs: account only rmapbt-used blocks against rmapbt perag res
  xfs: detect agfl count corruption and reset agfl
  xfs: clean up xfs_mount allocation and dynamic initializers

Carlos Maiolino (1):
  Cleanup old XFS_BTREE_* traces

Christoph Hellwig (16):
  fs: don't clear I_DIRTY_TIME before calling mark_inode_dirty_sync
  xfs: implement the lazytime mount option
  xfs: remove misleading comment text on xfs_inode_item_unlock
  xfs: remove an outdated comment for xfs_inode_item_committing
  xfs: remove the unused log_flushed variable in xfs_extent_busy_flush
  xfs: merge _xfs_log_force and xfs_log_force
  xfs: merge _xfs_log_force_lsn and xfs_log_force_lsn
  xfs: refactor xfs_log_force
  xfs: fix the check for COW extents in xfs_swap_extents
  xfs: don't use XFS_BMAPI_ENTRIRE in xfs_get_blocks
  xfs: assert that xfs_reflink_allocate_cow is called with XFS_ILOCK_EXCL
  xfs: remove xfs_zero_range
  xfs: minor cleanup for xfs_get_blocks
  xfs: minor cleanup for xfs_reflink_end_cow
  xfs: refactor xfs_log_force_lsn
  xfs: unwind the try_again loop in xfs_log_force

Darrick J. Wong (15):
  xfs: don't iunlock the quota ip when quota block
  xfs: convert a few more directory asserts to corruption
  xfs: check for cow blocks before trying to clear them
  xfs: sanity-check the unused space before trying to use it
  xfs: refactor bmap record validation
  xfs: refactor inode verifier error logging
  xfs: refactor inode buffer verifier error logging
  xfs: bmap scrubber should do rmap xref with bmap for sparse files
  xfs: inode scrubber shouldn't bother with raw checks
  xfs: remove xfs_buf parameter from inode scrub methods
  xfs: record inode buf errors as a xref error in inobt scrubber
  xfs: move inode extent size hint validation to libxfs
  xfs: don't accept inode buffers with suspicious unlinked chains
  xfs: flag inode corruption if parent ptr doesn't get us a real inode
  xfs: xfs_scrub_iallocbt_xref_rmap_inodes should use xref_set_corrupt

Dave Chinner (6):
  xfs: fall back to vmalloc when allocation log vector buffers
  xfs: fix transaction allocation deadlock in IO path
  xfs: convert XFS_AGFL_SIZE to a helper function
  inode: don't memset the inode address space twice
  xfs: catch inode allocation state mismatch corruption
  xfs: remove dead inode version setting code

Eric Sandeen (2):
  xfs: remove unused m_dmevmask from xfs_mount struct
  xfs: do not log/recover swapext extent owner changes for deleted inodes

Matthew Wilcox (1):
  xfs: Rename xa_ elements to ail_

Nikolay Borisov (1):
  xfs: Remove dead code from inode recover function

Vratislav Bendel (1):
  xfs: Correctly invert xfs_buftarg LRU isolation logic

 fs/inode.c |  12 --
 fs/sync.c  |   6 +--
 fs/xfs/kmem.c  |   6 +--
 fs/xfs/kmem.h  |   8 +++-
 

Re: [PATCH][RESEND] ASoC: Intel: atom: fix ACPI/PCI Kconfig

[Vinod Koul]

On Mon, Apr 02, 2018 at 12:06:14PM -0500, Pierre-Louis Bossart wrote:
> The split between ACPI and PCI platforms generated issues with randconfig:
> 
> with SND_SST_ATOM_HIFI2_PLATFORM_PCI=y and
> SND_SST_ATOM_HIFI2_PLATFORM=m, we get this module link failure:
> 
> ERROR: "sst_context_init"
> [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
> 
> ERROR: "sst_context_cleanup"
> [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
> 
> ERROR: "sst_alloc_drv_context"
> [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
> 
> ERROR: "intel_sst_pm" [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko]
> undefined!
> 
> ERROR: "sst_configure_runtime_pm"
> [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
> 
> To keep things simple, let's expose two configs for
> SND_SST_ATOM_HIFI2_PLATFORM_PCI and SND_SST_ATOM_HIFI2_PLATFORM_ACPI,
> which select a common SND_SST_ATOM_HIFI2_PLATFORM option. To avoid
> breaking existing solutions with the semantics change,
> SND_SST_ATOM_HIFI2_PLATFORM_ACPI uses "default ACPI" so that "make
> oldnoconfig" and "make olddefconfig" still work as expected.
> 
> Also remove mentions of Medfield while we are at it since it was
> removed recently.

Acked-By: Vinod Koul 

-- 
~Vinod

[GIT PULL] xfs: new features for 4.17

[Darrick J. Wong]

Hi Linus,

Here's the first round of fixes for XFS for 4.17.  The biggest new
features this time around are the addition of lazytime support, further
enhancement of the on-disk inode metadata verifiers, and a patch to
smooth over some of the AGFL padding problems that have intermittently
plagued users since 4.5.  I forsee sending a second pull request next
week with further bug fixes and speedups in the online scrub code and
elsewhere.

This series has been run through a full xfstests run over the weekend
and through a quick xfstests run against this morning's master, with no
major failures reported.  Let me know if there's any merge problems.

--D

The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae:

  Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-4.17-merge-1

for you to fetch changes up to dc1baa715bbfbb1902da942d06497e79b40e7bc7:

  xfs: do not log/recover swapext extent owner changes for deleted inodes 
(2018-03-29 10:19:15 -0700)


Changes for this release:
- Various cleanups and code fixes
- Implement lazytime as a mount option
- Convert various on-disk metadata checks from asserts to -EFSCORRUPTED
- Fix accounting problems with the rmap per-ag reservations
- Refactorings and cleanups for xfs_log_force
- Various bugfixes for the reflink code
- Work around v5 AGFL padding problems to prevent fs shutdowns
- Establish inode fork verifiers to inspect on-disk metadata correctness
- Various online scrub fixes
- Fix v5 swapext blowing up on deleted inodes


Brian Foster (6):
  xfs: shutdown if block allocation overruns tx reservation
  xfs: account format bouncing into rmapbt swapext tx reservation
  xfs: rename agfl perag res type to rmapbt
  xfs: account only rmapbt-used blocks against rmapbt perag res
  xfs: detect agfl count corruption and reset agfl
  xfs: clean up xfs_mount allocation and dynamic initializers

Carlos Maiolino (1):
  Cleanup old XFS_BTREE_* traces

Christoph Hellwig (16):
  fs: don't clear I_DIRTY_TIME before calling mark_inode_dirty_sync
  xfs: implement the lazytime mount option
  xfs: remove misleading comment text on xfs_inode_item_unlock
  xfs: remove an outdated comment for xfs_inode_item_committing
  xfs: remove the unused log_flushed variable in xfs_extent_busy_flush
  xfs: merge _xfs_log_force and xfs_log_force
  xfs: merge _xfs_log_force_lsn and xfs_log_force_lsn
  xfs: refactor xfs_log_force
  xfs: fix the check for COW extents in xfs_swap_extents
  xfs: don't use XFS_BMAPI_ENTRIRE in xfs_get_blocks
  xfs: assert that xfs_reflink_allocate_cow is called with XFS_ILOCK_EXCL
  xfs: remove xfs_zero_range
  xfs: minor cleanup for xfs_get_blocks
  xfs: minor cleanup for xfs_reflink_end_cow
  xfs: refactor xfs_log_force_lsn
  xfs: unwind the try_again loop in xfs_log_force

Darrick J. Wong (15):
  xfs: don't iunlock the quota ip when quota block
  xfs: convert a few more directory asserts to corruption
  xfs: check for cow blocks before trying to clear them
  xfs: sanity-check the unused space before trying to use it
  xfs: refactor bmap record validation
  xfs: refactor inode verifier error logging
  xfs: refactor inode buffer verifier error logging
  xfs: bmap scrubber should do rmap xref with bmap for sparse files
  xfs: inode scrubber shouldn't bother with raw checks
  xfs: remove xfs_buf parameter from inode scrub methods
  xfs: record inode buf errors as a xref error in inobt scrubber
  xfs: move inode extent size hint validation to libxfs
  xfs: don't accept inode buffers with suspicious unlinked chains
  xfs: flag inode corruption if parent ptr doesn't get us a real inode
  xfs: xfs_scrub_iallocbt_xref_rmap_inodes should use xref_set_corrupt

Dave Chinner (6):
  xfs: fall back to vmalloc when allocation log vector buffers
  xfs: fix transaction allocation deadlock in IO path
  xfs: convert XFS_AGFL_SIZE to a helper function
  inode: don't memset the inode address space twice
  xfs: catch inode allocation state mismatch corruption
  xfs: remove dead inode version setting code

Eric Sandeen (2):
  xfs: remove unused m_dmevmask from xfs_mount struct
  xfs: do not log/recover swapext extent owner changes for deleted inodes

Matthew Wilcox (1):
  xfs: Rename xa_ elements to ail_

Nikolay Borisov (1):
  xfs: Remove dead code from inode recover function

Vratislav Bendel (1):
  xfs: Correctly invert xfs_buftarg LRU isolation logic

 fs/inode.c |  12 --
 fs/sync.c  |   6 +--
 fs/xfs/kmem.c  |   6 +--
 fs/xfs/kmem.h  |   8 +++-
 

[PATCH v1] mm: consider non-anonymous thp as unmovable page

[Naoya Horiguchi]

My testing for the latest kernel supporting thp migration found out an
infinite loop in offlining the memory block that is filled with shmem
thps.  We can get out of the loop with a signal, but kernel should
return with failure in this case.

What happens in the loop is that scan_movable_pages() repeats returning
the same pfn without any progress. That's because page migration always
fails for shmem thps.

In memory offline code, memory blocks containing unmovable pages should
be prevented from being offline targets by has_unmovable_pages() inside
start_isolate_page_range(). So this patch simply does it for
non-anonymous thps.

Fixes: commit 72b39cfc4d75 ("mm, memory_hotplug: do not fail offlining too 
early")
Signed-off-by: Naoya Horiguchi 
Cc: sta...@vger.kernel.org # v4.15+
---
Actually I'm not sure which commit we should set to "Fixes" tag.
Commit 8135d8926c08 ("mm: memory_hotplug: memory hotremove supports thp
migration") failed to introduce the code that this patch is suggesting.
But the infinite loop became visible by commit 72b39cfc4d75 ("mm,
memory_hotplug: do not fail offlining too early") where retry code was
removed.
---
 mm/page_alloc.c | 12 
 1 file changed, 12 insertions(+)

diff --git v4.16-rc7-mmotm-2018-03-28-16-05/mm/page_alloc.c 
v4.16-rc7-mmotm-2018-03-28-16-05_patched/mm/page_alloc.c
index 905db9d..dbbe8fa 100644
--- v4.16-rc7-mmotm-2018-03-28-16-05/mm/page_alloc.c
+++ v4.16-rc7-mmotm-2018-03-28-16-05_patched/mm/page_alloc.c
@@ -7682,6 +7682,18 @@ bool has_unmovable_pages(struct zone *zone, struct page 
*page, int count,
 
if (!PageLRU(page))
found++;
+
+   /*
+* Thp migration is available only for anonymous thps for now.
+* So let's consider non-anonymous thps as unmovable pages.
+*/
+   if (PageTransCompound(page)) {
+   if (PageAnon(page))
+   iter += (1 << page_order(page)) - 1;
+   else
+   found++;
+   }
+
/*
 * If there are RECLAIMABLE pages, we need to check
 * it.  But now, memory offline itself doesn't call
-- 
2.7.0

[PATCH v1] mm: consider non-anonymous thp as unmovable page

[Naoya Horiguchi]

My testing for the latest kernel supporting thp migration found out an
infinite loop in offlining the memory block that is filled with shmem
thps.  We can get out of the loop with a signal, but kernel should
return with failure in this case.

What happens in the loop is that scan_movable_pages() repeats returning
the same pfn without any progress. That's because page migration always
fails for shmem thps.

In memory offline code, memory blocks containing unmovable pages should
be prevented from being offline targets by has_unmovable_pages() inside
start_isolate_page_range(). So this patch simply does it for
non-anonymous thps.

Fixes: commit 72b39cfc4d75 ("mm, memory_hotplug: do not fail offlining too 
early")
Signed-off-by: Naoya Horiguchi 
Cc: sta...@vger.kernel.org # v4.15+
---
Actually I'm not sure which commit we should set to "Fixes" tag.
Commit 8135d8926c08 ("mm: memory_hotplug: memory hotremove supports thp
migration") failed to introduce the code that this patch is suggesting.
But the infinite loop became visible by commit 72b39cfc4d75 ("mm,
memory_hotplug: do not fail offlining too early") where retry code was
removed.
---
 mm/page_alloc.c | 12 
 1 file changed, 12 insertions(+)

diff --git v4.16-rc7-mmotm-2018-03-28-16-05/mm/page_alloc.c 
v4.16-rc7-mmotm-2018-03-28-16-05_patched/mm/page_alloc.c
index 905db9d..dbbe8fa 100644
--- v4.16-rc7-mmotm-2018-03-28-16-05/mm/page_alloc.c
+++ v4.16-rc7-mmotm-2018-03-28-16-05_patched/mm/page_alloc.c
@@ -7682,6 +7682,18 @@ bool has_unmovable_pages(struct zone *zone, struct page 
*page, int count,
 
if (!PageLRU(page))
found++;
+
+   /*
+* Thp migration is available only for anonymous thps for now.
+* So let's consider non-anonymous thps as unmovable pages.
+*/
+   if (PageTransCompound(page)) {
+   if (PageAnon(page))
+   iter += (1 << page_order(page)) - 1;
+   else
+   found++;
+   }
+
/*
 * If there are RECLAIMABLE pages, we need to check
 * it.  But now, memory offline itself doesn't call
-- 
2.7.0

linux-next: manual merge of the selinux tree with the security tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the selinux tree got a conflict in:

  include/linux/lsm_hooks.h

between commit:

  22402b0b736d ("security: convert security hooks to use hlist")

from the security tree and commit:

  72e89f50084c ("security: Add support for SCTP security hooks")

from the selinux tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/lsm_hooks.h
index b76897cbc42d,84c0b927ea85..
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@@ -1736,231 -1763,233 +1769,234 @@@ union security_list_options 
  };
  
  struct security_hook_heads {
 -  struct list_head binder_set_context_mgr;
 -  struct list_head binder_transaction;
 -  struct list_head binder_transfer_binder;
 -  struct list_head binder_transfer_file;
 -  struct list_head ptrace_access_check;
 -  struct list_head ptrace_traceme;
 -  struct list_head capget;
 -  struct list_head capset;
 -  struct list_head capable;
 -  struct list_head quotactl;
 -  struct list_head quota_on;
 -  struct list_head syslog;
 -  struct list_head settime;
 -  struct list_head vm_enough_memory;
 -  struct list_head bprm_set_creds;
 -  struct list_head bprm_check_security;
 -  struct list_head bprm_committing_creds;
 -  struct list_head bprm_committed_creds;
 -  struct list_head sb_alloc_security;
 -  struct list_head sb_free_security;
 -  struct list_head sb_copy_data;
 -  struct list_head sb_remount;
 -  struct list_head sb_kern_mount;
 -  struct list_head sb_show_options;
 -  struct list_head sb_statfs;
 -  struct list_head sb_mount;
 -  struct list_head sb_umount;
 -  struct list_head sb_pivotroot;
 -  struct list_head sb_set_mnt_opts;
 -  struct list_head sb_clone_mnt_opts;
 -  struct list_head sb_parse_opts_str;
 -  struct list_head dentry_init_security;
 -  struct list_head dentry_create_files_as;
 +  struct hlist_head binder_set_context_mgr;
 +  struct hlist_head binder_transaction;
 +  struct hlist_head binder_transfer_binder;
 +  struct hlist_head binder_transfer_file;
 +  struct hlist_head ptrace_access_check;
 +  struct hlist_head ptrace_traceme;
 +  struct hlist_head capget;
 +  struct hlist_head capset;
 +  struct hlist_head capable;
 +  struct hlist_head quotactl;
 +  struct hlist_head quota_on;
 +  struct hlist_head syslog;
 +  struct hlist_head settime;
 +  struct hlist_head vm_enough_memory;
 +  struct hlist_head bprm_set_creds;
 +  struct hlist_head bprm_check_security;
 +  struct hlist_head bprm_committing_creds;
 +  struct hlist_head bprm_committed_creds;
 +  struct hlist_head sb_alloc_security;
 +  struct hlist_head sb_free_security;
 +  struct hlist_head sb_copy_data;
 +  struct hlist_head sb_remount;
 +  struct hlist_head sb_kern_mount;
 +  struct hlist_head sb_show_options;
 +  struct hlist_head sb_statfs;
 +  struct hlist_head sb_mount;
 +  struct hlist_head sb_umount;
 +  struct hlist_head sb_pivotroot;
 +  struct hlist_head sb_set_mnt_opts;
 +  struct hlist_head sb_clone_mnt_opts;
 +  struct hlist_head sb_parse_opts_str;
 +  struct hlist_head dentry_init_security;
 +  struct hlist_head dentry_create_files_as;
  #ifdef CONFIG_SECURITY_PATH
 -  struct list_head path_unlink;
 -  struct list_head path_mkdir;
 -  struct list_head path_rmdir;
 -  struct list_head path_mknod;
 -  struct list_head path_truncate;
 -  struct list_head path_symlink;
 -  struct list_head path_link;
 -  struct list_head path_rename;
 -  struct list_head path_chmod;
 -  struct list_head path_chown;
 -  struct list_head path_chroot;
 +  struct hlist_head path_unlink;
 +  struct hlist_head path_mkdir;
 +  struct hlist_head path_rmdir;
 +  struct hlist_head path_mknod;
 +  struct hlist_head path_truncate;
 +  struct hlist_head path_symlink;
 +  struct hlist_head path_link;
 +  struct hlist_head path_rename;
 +  struct hlist_head path_chmod;
 +  struct hlist_head path_chown;
 +  struct hlist_head path_chroot;
  #endif
 -  struct list_head inode_alloc_security;
 -  struct list_head inode_free_security;
 -  struct list_head inode_init_security;
 -  struct list_head inode_create;
 -  struct list_head inode_link;
 -  struct list_head inode_unlink;
 -  struct list_head inode_symlink;
 -  struct list_head inode_mkdir;
 -  struct list_head inode_rmdir;
 -  struct list_head inode_mknod;
 - 

linux-next: manual merge of the selinux tree with the security tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the selinux tree got a conflict in:

  include/linux/lsm_hooks.h

between commit:

  22402b0b736d ("security: convert security hooks to use hlist")

from the security tree and commit:

  72e89f50084c ("security: Add support for SCTP security hooks")

from the selinux tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/lsm_hooks.h
index b76897cbc42d,84c0b927ea85..
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@@ -1736,231 -1763,233 +1769,234 @@@ union security_list_options 
  };
  
  struct security_hook_heads {
 -  struct list_head binder_set_context_mgr;
 -  struct list_head binder_transaction;
 -  struct list_head binder_transfer_binder;
 -  struct list_head binder_transfer_file;
 -  struct list_head ptrace_access_check;
 -  struct list_head ptrace_traceme;
 -  struct list_head capget;
 -  struct list_head capset;
 -  struct list_head capable;
 -  struct list_head quotactl;
 -  struct list_head quota_on;
 -  struct list_head syslog;
 -  struct list_head settime;
 -  struct list_head vm_enough_memory;
 -  struct list_head bprm_set_creds;
 -  struct list_head bprm_check_security;
 -  struct list_head bprm_committing_creds;
 -  struct list_head bprm_committed_creds;
 -  struct list_head sb_alloc_security;
 -  struct list_head sb_free_security;
 -  struct list_head sb_copy_data;
 -  struct list_head sb_remount;
 -  struct list_head sb_kern_mount;
 -  struct list_head sb_show_options;
 -  struct list_head sb_statfs;
 -  struct list_head sb_mount;
 -  struct list_head sb_umount;
 -  struct list_head sb_pivotroot;
 -  struct list_head sb_set_mnt_opts;
 -  struct list_head sb_clone_mnt_opts;
 -  struct list_head sb_parse_opts_str;
 -  struct list_head dentry_init_security;
 -  struct list_head dentry_create_files_as;
 +  struct hlist_head binder_set_context_mgr;
 +  struct hlist_head binder_transaction;
 +  struct hlist_head binder_transfer_binder;
 +  struct hlist_head binder_transfer_file;
 +  struct hlist_head ptrace_access_check;
 +  struct hlist_head ptrace_traceme;
 +  struct hlist_head capget;
 +  struct hlist_head capset;
 +  struct hlist_head capable;
 +  struct hlist_head quotactl;
 +  struct hlist_head quota_on;
 +  struct hlist_head syslog;
 +  struct hlist_head settime;
 +  struct hlist_head vm_enough_memory;
 +  struct hlist_head bprm_set_creds;
 +  struct hlist_head bprm_check_security;
 +  struct hlist_head bprm_committing_creds;
 +  struct hlist_head bprm_committed_creds;
 +  struct hlist_head sb_alloc_security;
 +  struct hlist_head sb_free_security;
 +  struct hlist_head sb_copy_data;
 +  struct hlist_head sb_remount;
 +  struct hlist_head sb_kern_mount;
 +  struct hlist_head sb_show_options;
 +  struct hlist_head sb_statfs;
 +  struct hlist_head sb_mount;
 +  struct hlist_head sb_umount;
 +  struct hlist_head sb_pivotroot;
 +  struct hlist_head sb_set_mnt_opts;
 +  struct hlist_head sb_clone_mnt_opts;
 +  struct hlist_head sb_parse_opts_str;
 +  struct hlist_head dentry_init_security;
 +  struct hlist_head dentry_create_files_as;
  #ifdef CONFIG_SECURITY_PATH
 -  struct list_head path_unlink;
 -  struct list_head path_mkdir;
 -  struct list_head path_rmdir;
 -  struct list_head path_mknod;
 -  struct list_head path_truncate;
 -  struct list_head path_symlink;
 -  struct list_head path_link;
 -  struct list_head path_rename;
 -  struct list_head path_chmod;
 -  struct list_head path_chown;
 -  struct list_head path_chroot;
 +  struct hlist_head path_unlink;
 +  struct hlist_head path_mkdir;
 +  struct hlist_head path_rmdir;
 +  struct hlist_head path_mknod;
 +  struct hlist_head path_truncate;
 +  struct hlist_head path_symlink;
 +  struct hlist_head path_link;
 +  struct hlist_head path_rename;
 +  struct hlist_head path_chmod;
 +  struct hlist_head path_chown;
 +  struct hlist_head path_chroot;
  #endif
 -  struct list_head inode_alloc_security;
 -  struct list_head inode_free_security;
 -  struct list_head inode_init_security;
 -  struct list_head inode_create;
 -  struct list_head inode_link;
 -  struct list_head inode_unlink;
 -  struct list_head inode_symlink;
 -  struct list_head inode_mkdir;
 -  struct list_head inode_rmdir;
 -  struct list_head inode_mknod;
 - 

Re: WARNING: bad unlock balance in xfs_iunlock

[Dave Chinner]

On Mon, Apr 02, 2018 at 07:01:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +)
> Merge branch 'ras-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=84a67953651a971809ba
> 
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5719304272084992
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5767783983874048

What a mess. A hand built, hopelessly broken filesystem image made
up of hex dumps, written into a mmap()d region of memory, then
copied into a tmpfs file and mounted with the loop device.

Engineers that can debug broken filesystems don't grow on trees.  If
we are to have any hope of understanding what the hell this test is
doing, the bot needs to supply us with a copy of the built
filesystem image the test uses. We need to be able to point forensic
tools at the image to decode all the structures into human readable
format - if we are forced to do that by hand or jump through hoops
to create our own filesystem image than I'm certainly not going to
waste time looking at these reports...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: WARNING: bad unlock balance in xfs_iunlock

[Dave Chinner]

On Mon, Apr 02, 2018 at 07:01:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +)
> Merge branch 'ras-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=84a67953651a971809ba
> 
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5719304272084992
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5767783983874048

What a mess. A hand built, hopelessly broken filesystem image made
up of hex dumps, written into a mmap()d region of memory, then
copied into a tmpfs file and mounted with the loop device.

Engineers that can debug broken filesystems don't grow on trees.  If
we are to have any hope of understanding what the hell this test is
doing, the bot needs to supply us with a copy of the built
filesystem image the test uses. We need to be able to point forensic
tools at the image to decode all the structures into human readable
format - if we are forced to do that by hand or jump through hoops
to create our own filesystem image than I'm certainly not going to
waste time looking at these reports...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 4/5] powerpc/pm: add sleep and deep sleep on QorIQ SoCs

[kbuild test robot]

Hi Ran,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on powerpc/next]
[also build test WARNING on v4.16 next-20180329]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ran-Wang/powerpc-pm-Fix-suspend-n-in-menuconfig-for-e500mc-platforms/20180330-072848
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-ppc64e_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-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=powerpc 

All warnings (new ones prefixed by >>):

   arch/powerpc/platforms/85xx/sleep.S: Assembler messages:
>> arch/powerpc/platforms/85xx/sleep.S:1174: Warning: invalid register 
>> expression

vim +1174 arch/powerpc/platforms/85xx/sleep.S

  1137  
  1138  _GLOBAL(fsl_booke_deep_sleep_resume)
  1139  /* disable interrupts */
  1140  FSL_DIS_ALL_IRQ
  1141  
  1142  /* switch to 64-bit mode */
  1143  bl  .enable_64b_mode
  1144  
  1145  /* set TOC pointer */
  1146  bl  .relative_toc
  1147  
  1148  /* setup initial TLBs, switch to kernel space ... */
  1149  bl  .start_initialization_book3e
  1150  
  1151  /* address space changed, set TOC pointer again */
  1152  bl  .relative_toc
  1153  
  1154  /* call a cpu state restore handler */
  1155  LOAD_REG_ADDR(r23, cur_cpu_spec)
  1156  ld  r23,0(r23)
  1157  ld  r23,CPU_SPEC_RESTORE(r23)
  1158  cmpdi   0,r23,0
  1159  beq 1f
  1160  ld  r23,0(r23)
  1161  mtctr   r23
  1162  bctrl
  1163  1:
  1164  LOAD_REG_ADDR(r3, regs_buffer)
  1165  bl  e5500_cpu_state_restore
  1166  
  1167  /* Load each CAM entry */
  1168  LOAD_REG_ADDR(r3, tlbcam_index)
  1169  lwz r3, 0(r3)
  1170  mtctr   r3
  1171  li  r0, 0
  1172  3:  mr  r3, r0
  1173  bl  loadcam_entry
> 1174  addir0, r0, 1
  1175  bdnz3b
  1176  
  1177  /* restore return address */
  1178  LOAD_REG_ADDR(r3, buf_tmp)
  1179  ld  r4, 16(r3)
  1180  mtspr   SPRN_TCR, r4
  1181  ld  r4, 0(r3)
  1182  mtlrr4
  1183  ld  r4, 8(r3)
  1184  mtmsr   r4
  1185  ld  r4, 24(r3)
  1186  mtcrr4
  1187  
  1188  blr
  1189  

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


.config.gz
Description: application/gzip

Re: [PATCH 4/5] powerpc/pm: add sleep and deep sleep on QorIQ SoCs

[kbuild test robot]

Hi Ran,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on powerpc/next]
[also build test WARNING on v4.16 next-20180329]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ran-Wang/powerpc-pm-Fix-suspend-n-in-menuconfig-for-e500mc-platforms/20180330-072848
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-ppc64e_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-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=powerpc 

All warnings (new ones prefixed by >>):

   arch/powerpc/platforms/85xx/sleep.S: Assembler messages:
>> arch/powerpc/platforms/85xx/sleep.S:1174: Warning: invalid register 
>> expression

vim +1174 arch/powerpc/platforms/85xx/sleep.S

  1137  
  1138  _GLOBAL(fsl_booke_deep_sleep_resume)
  1139  /* disable interrupts */
  1140  FSL_DIS_ALL_IRQ
  1141  
  1142  /* switch to 64-bit mode */
  1143  bl  .enable_64b_mode
  1144  
  1145  /* set TOC pointer */
  1146  bl  .relative_toc
  1147  
  1148  /* setup initial TLBs, switch to kernel space ... */
  1149  bl  .start_initialization_book3e
  1150  
  1151  /* address space changed, set TOC pointer again */
  1152  bl  .relative_toc
  1153  
  1154  /* call a cpu state restore handler */
  1155  LOAD_REG_ADDR(r23, cur_cpu_spec)
  1156  ld  r23,0(r23)
  1157  ld  r23,CPU_SPEC_RESTORE(r23)
  1158  cmpdi   0,r23,0
  1159  beq 1f
  1160  ld  r23,0(r23)
  1161  mtctr   r23
  1162  bctrl
  1163  1:
  1164  LOAD_REG_ADDR(r3, regs_buffer)
  1165  bl  e5500_cpu_state_restore
  1166  
  1167  /* Load each CAM entry */
  1168  LOAD_REG_ADDR(r3, tlbcam_index)
  1169  lwz r3, 0(r3)
  1170  mtctr   r3
  1171  li  r0, 0
  1172  3:  mr  r3, r0
  1173  bl  loadcam_entry
> 1174  addir0, r0, 1
  1175  bdnz3b
  1176  
  1177  /* restore return address */
  1178  LOAD_REG_ADDR(r3, buf_tmp)
  1179  ld  r4, 16(r3)
  1180  mtspr   SPRN_TCR, r4
  1181  ld  r4, 0(r3)
  1182  mtlrr4
  1183  ld  r4, 8(r3)
  1184  mtmsr   r4
  1185  ld  r4, 24(r3)
  1186  mtcrr4
  1187  
  1188  blr
  1189  

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


.config.gz
Description: application/gzip

Re: [GIT PULL] remove in-kernel calls to syscalls

[Linus Torvalds]

On Mon, Apr 2, 2018 at 12:04 PM, Dominik Brodowski
 wrote:
>
> This patchset removes all in-kernel calls to syscall functions in the
> kernel with the exception of arch/.

Ok, this finished off my arch updates for today, I'll probably move on
to driver pulls tomorrow.

Anyway, it's in my tree, will push out once my test build finishes.

Linus

Re: [GIT PULL] remove in-kernel calls to syscalls

[Linus Torvalds]

On Mon, Apr 2, 2018 at 12:04 PM, Dominik Brodowski
 wrote:
>
> This patchset removes all in-kernel calls to syscall functions in the
> kernel with the exception of arch/.

Ok, this finished off my arch updates for today, I'll probably move on
to driver pulls tomorrow.

Anyway, it's in my tree, will push out once my test build finishes.

Linus

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

[Viresh Kumar]

On 03-04-18, 08:11, Sricharan R wrote:
>  Right, i was adding a similar one for krait cores [1]. There is code common 
> in the
>  init sequence across both (little). Do you suggest to make them common ?

It may make sense as we are talking about one SoC family here :)

-- 
viresh

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

[Viresh Kumar]

On 03-04-18, 08:11, Sricharan R wrote:
>  Right, i was adding a similar one for krait cores [1]. There is code common 
> in the
>  init sequence across both (little). Do you suggest to make them common ?

It may make sense as we are talking about one SoC family here :)

-- 
viresh

Re: [PATCH v2 2/2] cpufreq: ti-cpufreq: Use devres managed API in probe()

[Viresh Kumar]

On 02-04-18, 11:49, Suman Anna wrote:
> The ti_cpufreq_probe() function uses regular kzalloc to allocate
> the ti_cpufreq_data structure and kfree for freeing this memory
> on failures. Simplify this code by using the devres managed
> API.
> 
> Cc: Zumeng Chen 
> Signed-off-by: Suman Anna 
> ---
>  drivers/cpufreq/ti-cpufreq.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> index 46d1ab2dea87..7d353a21935b 100644
> --- a/drivers/cpufreq/ti-cpufreq.c
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -217,7 +217,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>   if (!match)
>   return -ENODEV;
>  
> - opp_data = kzalloc(sizeof(*opp_data), GFP_KERNEL);
> + opp_data = devm_kzalloc(>dev, sizeof(*opp_data), GFP_KERNEL);
>   if (!opp_data)
>   return -ENOMEM;
>  
> @@ -226,8 +226,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>   opp_data->cpu_dev = get_cpu_device(0);
>   if (!opp_data->cpu_dev) {
>   pr_err("%s: Failed to get device for CPU0\n", __func__);
> - ret = -ENODEV;
> - goto free_opp_data;
> + return -ENODEV;
>   }
>  
>   opp_data->opp_node = dev_pm_opp_of_get_opp_desc_node(opp_data->cpu_dev);
> @@ -285,8 +284,6 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>  
>  fail_put_node:
>   of_node_put(opp_data->opp_node);
> -free_opp_data:
> - kfree(opp_data);
>  
>   return ret;
>  }

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 2/2] cpufreq: ti-cpufreq: Use devres managed API in probe()

[Viresh Kumar]

On 02-04-18, 11:49, Suman Anna wrote:
> The ti_cpufreq_probe() function uses regular kzalloc to allocate
> the ti_cpufreq_data structure and kfree for freeing this memory
> on failures. Simplify this code by using the devres managed
> API.
> 
> Cc: Zumeng Chen 
> Signed-off-by: Suman Anna 
> ---
>  drivers/cpufreq/ti-cpufreq.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> index 46d1ab2dea87..7d353a21935b 100644
> --- a/drivers/cpufreq/ti-cpufreq.c
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -217,7 +217,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>   if (!match)
>   return -ENODEV;
>  
> - opp_data = kzalloc(sizeof(*opp_data), GFP_KERNEL);
> + opp_data = devm_kzalloc(>dev, sizeof(*opp_data), GFP_KERNEL);
>   if (!opp_data)
>   return -ENOMEM;
>  
> @@ -226,8 +226,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>   opp_data->cpu_dev = get_cpu_device(0);
>   if (!opp_data->cpu_dev) {
>   pr_err("%s: Failed to get device for CPU0\n", __func__);
> - ret = -ENODEV;
> - goto free_opp_data;
> + return -ENODEV;
>   }
>  
>   opp_data->opp_node = dev_pm_opp_of_get_opp_desc_node(opp_data->cpu_dev);
> @@ -285,8 +284,6 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>  
>  fail_put_node:
>   of_node_put(opp_data->opp_node);
> -free_opp_data:
> - kfree(opp_data);
>  
>   return ret;
>  }

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 1/2] cpufreq: ti-cpufreq: Fix an incorrect error return value

[Viresh Kumar]

On 02-04-18, 11:49, Suman Anna wrote:
> Commit 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when
> failure") has fixed a memory leak in the failure path, however
> the patch returned a positive value on get_cpu_device() failure
> instead of the previous negative value. Fix this incorrect error
> return value properly.
> 
> Fixes: 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when failure")
> Cc: Zumeng Chen 
> Cc: sta...@vger.kernel.org

You also need to mention which version of the stable kernel this patch
should be applied to, like this:

Cc: 3.15+  # v3.15+

Rafael would probably fix this while applying, so no need to resend
again for now.

> Signed-off-by: Suman Anna 
> ---
>  drivers/cpufreq/ti-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> index a099b7bf74cd..46d1ab2dea87 100644
> --- a/drivers/cpufreq/ti-cpufreq.c
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -226,7 +226,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>   opp_data->cpu_dev = get_cpu_device(0);
>   if (!opp_data->cpu_dev) {
>   pr_err("%s: Failed to get device for CPU0\n", __func__);
> - ret = ENODEV;
> + ret = -ENODEV;
>   goto free_opp_data;
>   }

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 1/2] cpufreq: ti-cpufreq: Fix an incorrect error return value

[Viresh Kumar]

On 02-04-18, 11:49, Suman Anna wrote:
> Commit 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when
> failure") has fixed a memory leak in the failure path, however
> the patch returned a positive value on get_cpu_device() failure
> instead of the previous negative value. Fix this incorrect error
> return value properly.
> 
> Fixes: 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when failure")
> Cc: Zumeng Chen 
> Cc: sta...@vger.kernel.org

You also need to mention which version of the stable kernel this patch
should be applied to, like this:

Cc: 3.15+  # v3.15+

Rafael would probably fix this while applying, so no need to resend
again for now.

> Signed-off-by: Suman Anna 
> ---
>  drivers/cpufreq/ti-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> index a099b7bf74cd..46d1ab2dea87 100644
> --- a/drivers/cpufreq/ti-cpufreq.c
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -226,7 +226,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>   opp_data->cpu_dev = get_cpu_device(0);
>   if (!opp_data->cpu_dev) {
>   pr_err("%s: Failed to get device for CPU0\n", __func__);
> - ret = ENODEV;
> + ret = -ENODEV;
>   goto free_opp_data;
>   }

Acked-by: Viresh Kumar 

-- 
viresh

Re: WARNING in refcount_dec

[DaeRyong Jeong]

No. Only the first crash (WARNING in refcount_dec) is reproduced by
the attached reproducer.

The second crash (kernel bug at af_packet.c:3107) is reproduced by
another reproducer.
We reported it here.
http://lkml.iu.edu/hypermail/linux/kernel/1803.3/05324.html

On Sun, Apr 1, 2018 at 4:38 PM, Willem de Bruijn
 wrote:
> On Thu, Mar 29, 2018 at 1:16 AM, Cong Wang  wrote:
>> (Cc'ing netdev and Willem)
>>
>> On Wed, Mar 28, 2018 at 12:03 PM, Byoungyoung Lee
>>  wrote:
>>> Another crash patterns observed: race between (setsockopt$packet_int)
>>> and (bind$packet).
>>>
>>> --
>>> [  357.731597] kernel BUG at
>>> /home/blee/project/race-fuzzer/kernels/kernel_v4.16-rc3/net/packet/af_packet.c:3107!
>>> [  357.733382] invalid opcode:  [#1] SMP KASAN
>>> [  357.734017] Modules linked in:
>>> [  357.734662] CPU: 1 PID: 3871 Comm: repro.exe Not tainted 4.16.0-rc3 #1
>>> [  357.735791] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>>> BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
>>> [  357.737434] RIP: 0010:packet_do_bind+0x88d/0x950
>>> [  357.738121] RSP: 0018:8800b2787b08 EFLAGS: 00010293
>>> [  357.738906] RAX: 8800b2fdc780 RBX: 880234358cc0 RCX: 
>>> 838b244c
>>> [  357.739905] RDX:  RSI: 838b257d RDI: 
>>> 0001
>>> [  357.741315] RBP: 8800b2787c10 R08: 8800b2fdc780 R09: 
>>> 
>>> [  357.743055] R10: 0001 R11:  R12: 
>>> 88023352ecc0
>>> [  357.744744] R13:  R14: 0001 R15: 
>>> 1d00
>>> [  357.746377] FS:  7f4b43733700() GS:8800b8b0()
>>> knlGS:
>>> [  357.749599] CS:  0010 DS:  ES:  CR0: 80050033
>>> [  357.752096] CR2: 20058000 CR3: 0002334b8000 CR4: 
>>> 06e0
>>> [  357.755045] Call Trace:
>>> [  357.755822]  ? compat_packet_setsockopt+0x100/0x100
>>> [  357.757324]  ? __sanitizer_cov_trace_const_cmp8+0x18/0x20
>>> [  357.758810]  packet_bind+0xa2/0xe0
>>> [  357.759640]  SYSC_bind+0x279/0x2f0
>>> [  357.760364]  ? move_addr_to_kernel.part.19+0xc0/0xc0
>>> [  357.761491]  ? __handle_mm_fault+0x25d0/0x25d0
>>> [  357.762449]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>>> [  357.763663]  ? __do_page_fault+0x417/0xba0
>>> [  357.764569]  ? vmalloc_fault+0x910/0x910
>>> [  357.765405]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>>> [  357.766525]  ? mark_held_locks+0x25/0xb0
>>> [  357.767336]  ? SyS_socketpair+0x4a0/0x4a0
>>> [  357.768182]  SyS_bind+0x24/0x30
>>> [  357.768851]  do_syscall_64+0x209/0x5d0
>>> [  357.769650]  ? syscall_return_slowpath+0x3e0/0x3e0
>>> [  357.770665]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>>> [  357.771779]  ? syscall_return_slowpath+0x260/0x3e0
>>> [  357.772748]  ? mark_held_locks+0x25/0xb0
>>> [  357.773581]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>>> [  357.774720]  ? retint_user+0x18/0x18
>>> [  357.775493]  ? trace_hardirqs_off_caller+0xb5/0x120
>>> [  357.776567]  ? trace_hardirqs_off_thunk+0x1a/0x1c
>>> [  357.777512]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
>>> [  357.778508] RIP: 0033:0x4503a9
>>> [  357.779156] RSP: 002b:7f4b43732ce8 EFLAGS: 0246 ORIG_RAX:
>>> 0031
>>> [  357.780737] RAX: ffda RBX:  RCX: 
>>> 004503a9
>>> [  357.782169] RDX: 0014 RSI: 20058000 RDI: 
>>> 0003
>>> [  357.783710] RBP: 7f4b43732d10 R08:  R09: 
>>> 
>>> [  357.785202] R10:  R11: 0246 R12: 
>>> 
>>> [  357.786664] R13:  R14: 7f4b437339c0 R15: 
>>> 7f4b43733700
>>> [  357.788210] Code: c0 fd 48 c7 c2 00 c8 d9 84 be ab 02 00 00 48 c7
>>> c7 60 c8 d9 84 c6 05 e7 a2 48 02 01 e8 3f 17 af fd e9 60 fb ff ff e8
>>> 43 b3 c0 fd <0f> 0b e8 3c b3 c0 fd 48 8b bd 20 ff ff ff e8 60 1e e7 fd
>>> 4c 89
>>> [  357.792260] RIP: packet_do_bind+0x88d/0x950 RSP: 8800b2787b08
>>> [  357.793698] ---[ end trace 0c5a2539f0247369 ]---
>>> [  357.794696] Kernel panic - not syncing: Fatal exception
>>> [  357.795918] Kernel Offset: disabled
>>> [  357.796614] Rebooting in 86400 seconds..
>>>
>>> On Wed, Mar 28, 2018 at 1:19 AM, Byoungyoung Lee  
>>> wrote:
 We report the crash: WARNING in refcount_dec

 This crash has been found in v4.16-rc3 using RaceFuzzer (a modified
 version of Syzkaller), which we describe more at the end of this
 report. Our analysis shows that the race occurs when invoking two
 syscalls concurrently, (setsockopt$packet_int) and
 (setsockopt$packet_rx_ring).

 C repro code : 
 https://kiwi.cs.purdue.edu/static/race-fuzzer/repro-refcount_dec.c
 kernel config: 
 https://kiwi.cs.purdue.edu/static/race-fuzzer/kernel-config-v4.16-rc3
>>
>>
>> I tried your 

Re: WARNING in refcount_dec

[DaeRyong Jeong]

No. Only the first crash (WARNING in refcount_dec) is reproduced by
the attached reproducer.

The second crash (kernel bug at af_packet.c:3107) is reproduced by
another reproducer.
We reported it here.
http://lkml.iu.edu/hypermail/linux/kernel/1803.3/05324.html

On Sun, Apr 1, 2018 at 4:38 PM, Willem de Bruijn
 wrote:
> On Thu, Mar 29, 2018 at 1:16 AM, Cong Wang  wrote:
>> (Cc'ing netdev and Willem)
>>
>> On Wed, Mar 28, 2018 at 12:03 PM, Byoungyoung Lee
>>  wrote:
>>> Another crash patterns observed: race between (setsockopt$packet_int)
>>> and (bind$packet).
>>>
>>> --
>>> [  357.731597] kernel BUG at
>>> /home/blee/project/race-fuzzer/kernels/kernel_v4.16-rc3/net/packet/af_packet.c:3107!
>>> [  357.733382] invalid opcode:  [#1] SMP KASAN
>>> [  357.734017] Modules linked in:
>>> [  357.734662] CPU: 1 PID: 3871 Comm: repro.exe Not tainted 4.16.0-rc3 #1
>>> [  357.735791] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>>> BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
>>> [  357.737434] RIP: 0010:packet_do_bind+0x88d/0x950
>>> [  357.738121] RSP: 0018:8800b2787b08 EFLAGS: 00010293
>>> [  357.738906] RAX: 8800b2fdc780 RBX: 880234358cc0 RCX: 
>>> 838b244c
>>> [  357.739905] RDX:  RSI: 838b257d RDI: 
>>> 0001
>>> [  357.741315] RBP: 8800b2787c10 R08: 8800b2fdc780 R09: 
>>> 
>>> [  357.743055] R10: 0001 R11:  R12: 
>>> 88023352ecc0
>>> [  357.744744] R13:  R14: 0001 R15: 
>>> 1d00
>>> [  357.746377] FS:  7f4b43733700() GS:8800b8b0()
>>> knlGS:
>>> [  357.749599] CS:  0010 DS:  ES:  CR0: 80050033
>>> [  357.752096] CR2: 20058000 CR3: 0002334b8000 CR4: 
>>> 06e0
>>> [  357.755045] Call Trace:
>>> [  357.755822]  ? compat_packet_setsockopt+0x100/0x100
>>> [  357.757324]  ? __sanitizer_cov_trace_const_cmp8+0x18/0x20
>>> [  357.758810]  packet_bind+0xa2/0xe0
>>> [  357.759640]  SYSC_bind+0x279/0x2f0
>>> [  357.760364]  ? move_addr_to_kernel.part.19+0xc0/0xc0
>>> [  357.761491]  ? __handle_mm_fault+0x25d0/0x25d0
>>> [  357.762449]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>>> [  357.763663]  ? __do_page_fault+0x417/0xba0
>>> [  357.764569]  ? vmalloc_fault+0x910/0x910
>>> [  357.765405]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>>> [  357.766525]  ? mark_held_locks+0x25/0xb0
>>> [  357.767336]  ? SyS_socketpair+0x4a0/0x4a0
>>> [  357.768182]  SyS_bind+0x24/0x30
>>> [  357.768851]  do_syscall_64+0x209/0x5d0
>>> [  357.769650]  ? syscall_return_slowpath+0x3e0/0x3e0
>>> [  357.770665]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>>> [  357.771779]  ? syscall_return_slowpath+0x260/0x3e0
>>> [  357.772748]  ? mark_held_locks+0x25/0xb0
>>> [  357.773581]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>>> [  357.774720]  ? retint_user+0x18/0x18
>>> [  357.775493]  ? trace_hardirqs_off_caller+0xb5/0x120
>>> [  357.776567]  ? trace_hardirqs_off_thunk+0x1a/0x1c
>>> [  357.777512]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
>>> [  357.778508] RIP: 0033:0x4503a9
>>> [  357.779156] RSP: 002b:7f4b43732ce8 EFLAGS: 0246 ORIG_RAX:
>>> 0031
>>> [  357.780737] RAX: ffda RBX:  RCX: 
>>> 004503a9
>>> [  357.782169] RDX: 0014 RSI: 20058000 RDI: 
>>> 0003
>>> [  357.783710] RBP: 7f4b43732d10 R08:  R09: 
>>> 
>>> [  357.785202] R10:  R11: 0246 R12: 
>>> 
>>> [  357.786664] R13:  R14: 7f4b437339c0 R15: 
>>> 7f4b43733700
>>> [  357.788210] Code: c0 fd 48 c7 c2 00 c8 d9 84 be ab 02 00 00 48 c7
>>> c7 60 c8 d9 84 c6 05 e7 a2 48 02 01 e8 3f 17 af fd e9 60 fb ff ff e8
>>> 43 b3 c0 fd <0f> 0b e8 3c b3 c0 fd 48 8b bd 20 ff ff ff e8 60 1e e7 fd
>>> 4c 89
>>> [  357.792260] RIP: packet_do_bind+0x88d/0x950 RSP: 8800b2787b08
>>> [  357.793698] ---[ end trace 0c5a2539f0247369 ]---
>>> [  357.794696] Kernel panic - not syncing: Fatal exception
>>> [  357.795918] Kernel Offset: disabled
>>> [  357.796614] Rebooting in 86400 seconds..
>>>
>>> On Wed, Mar 28, 2018 at 1:19 AM, Byoungyoung Lee  
>>> wrote:
 We report the crash: WARNING in refcount_dec

 This crash has been found in v4.16-rc3 using RaceFuzzer (a modified
 version of Syzkaller), which we describe more at the end of this
 report. Our analysis shows that the race occurs when invoking two
 syscalls concurrently, (setsockopt$packet_int) and
 (setsockopt$packet_rx_ring).

 C repro code : 
 https://kiwi.cs.purdue.edu/static/race-fuzzer/repro-refcount_dec.c
 kernel config: 
 https://kiwi.cs.purdue.edu/static/race-fuzzer/kernel-config-v4.16-rc3
>>
>>
>> I tried your reproducer, no luck here.
>>
>
> Are both crashes with the same reproducer?
>
> It races setsockopt PACKET_RX_RING 

Re: [GIT PULL] arch: remove obsolete architecture ports

[Linus Torvalds]

On Mon, Apr 2, 2018 at 12:17 AM, Arnd Bergmann  wrote:
>
> The series is rather long and conflicts in trivial ways with lots
> of subsystem trees. You probably want to pull it either really
> early in the merge window or really late.

Ok, I've been pulling arch updates, so it went in now.

Side note: the most concise yet useful form of diff I found for your
pull request was this:

git diff -M --stat=5000 --summary merge^..merge | grep '\+'

which shows the diffstat, but skips anything that doesn't have a plus
sign in it. So all the pure removal lines are entirely gone.

So it shows stuff that had actual modifications, and perhaps more
importantly, it still shows the final summary, which matches yours:

 2498 files changed, 95 insertions(+), 467668 deletions(-)

which is pretty nice to see. Closer to hal a million lines gone. (Or,
as the drm people would say "one header file").

You should probably check the end result (I haven't pushed out yet,
doing a few more things and build tests, but it should be out soon).

Linus

Re: [GIT PULL] arch: remove obsolete architecture ports

[Linus Torvalds]

On Mon, Apr 2, 2018 at 12:17 AM, Arnd Bergmann  wrote:
>
> The series is rather long and conflicts in trivial ways with lots
> of subsystem trees. You probably want to pull it either really
> early in the merge window or really late.

Ok, I've been pulling arch updates, so it went in now.

Side note: the most concise yet useful form of diff I found for your
pull request was this:

git diff -M --stat=5000 --summary merge^..merge | grep '\+'

which shows the diffstat, but skips anything that doesn't have a plus
sign in it. So all the pure removal lines are entirely gone.

So it shows stuff that had actual modifications, and perhaps more
importantly, it still shows the final summary, which matches yours:

 2498 files changed, 95 insertions(+), 467668 deletions(-)

which is pretty nice to see. Closer to hal a million lines gone. (Or,
as the drm people would say "one header file").

You should probably check the end result (I haven't pushed out yet,
doing a few more things and build tests, but it should be out soon).

Linus

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

[Herbert Xu]

On Tue, Apr 03, 2018 at 01:41:26PM +1000, NeilBrown wrote:
>
> Do we really need a rhashtable_walk_peek() interface?
> I imagine that a seqfile ->start function can do:
> 
>   if (*ppos == 0 && last_pos != 0) {
>   rhashtable_walk_exit();
> rhashtable_walk_enter(, );
> last_pos = 0;
>   }
>   rhashtable_walk_start();
>   if (*ppos == last_pos && iter.p)
>   return iter.p;
>   last_pos = *ppos;

We don't want users poking into the internals of iter.  If you're
suggesting we could simplify rhashtable_walk_peek to just this after
your patch then yes possibly.  You also need to ensure that not only
seqfs users continue to work but also netlink dump users which are
slightly different.

> It might be OK to have a function call instead of expecting people to
> use iter.p directly.

Yes that would definitely be the preferred option.

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

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

[Herbert Xu]

On Tue, Apr 03, 2018 at 01:41:26PM +1000, NeilBrown wrote:
>
> Do we really need a rhashtable_walk_peek() interface?
> I imagine that a seqfile ->start function can do:
> 
>   if (*ppos == 0 && last_pos != 0) {
>   rhashtable_walk_exit();
> rhashtable_walk_enter(, );
> last_pos = 0;
>   }
>   rhashtable_walk_start();
>   if (*ppos == last_pos && iter.p)
>   return iter.p;
>   last_pos = *ppos;

We don't want users poking into the internals of iter.  If you're
suggesting we could simplify rhashtable_walk_peek to just this after
your patch then yes possibly.  You also need to ensure that not only
seqfs users continue to work but also netlink dump users which are
slightly different.

> It might be OK to have a function call instead of expecting people to
> use iter.p directly.

Yes that would definitely be the preferred option.

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

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

[NeilBrown]

On Fri, Mar 30 2018, Herbert Xu wrote:

> On Thu, Mar 29, 2018 at 06:52:34PM +0200, Andreas Gruenbacher wrote:
>>
>> Should rhashtable_walk_peek be kept around even if there are no more
>> users? I have my doubts.
>
> Absolutely.  All netlink dumps using rhashtable_walk_next are buggy
> and need to switch over to rhashtable_walk_peek.  As otherwise
> the object that triggers the out-of-space condition will be skipped
> upon resumption.

Do we really need a rhashtable_walk_peek() interface?
I imagine that a seqfile ->start function can do:

  if (*ppos == 0 && last_pos != 0) {
rhashtable_walk_exit();
rhashtable_walk_enter(, );
last_pos = 0;
  }
  rhashtable_walk_start();
  if (*ppos == last_pos && iter.p)
return iter.p;
  last_pos = *ppos;
  return rhashtable_walk_next()


and the ->next function just does

  last_pos = *ppos;
  *ppos += 1;
  do p = rhashtable_walk_next(); while (IS_ERR(p));
  return p;

It might be OK to have a function call instead of expecting people to
use iter.p directly.

static inline void *rhashtable_walk_prev(struct rhashtable_iter *iter)
{
return iter->p;
}

Thoughts?

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

[NeilBrown]

On Fri, Mar 30 2018, Herbert Xu wrote:

> On Thu, Mar 29, 2018 at 06:52:34PM +0200, Andreas Gruenbacher wrote:
>>
>> Should rhashtable_walk_peek be kept around even if there are no more
>> users? I have my doubts.
>
> Absolutely.  All netlink dumps using rhashtable_walk_next are buggy
> and need to switch over to rhashtable_walk_peek.  As otherwise
> the object that triggers the out-of-space condition will be skipped
> upon resumption.

Do we really need a rhashtable_walk_peek() interface?
I imagine that a seqfile ->start function can do:

  if (*ppos == 0 && last_pos != 0) {
rhashtable_walk_exit();
rhashtable_walk_enter(, );
last_pos = 0;
  }
  rhashtable_walk_start();
  if (*ppos == last_pos && iter.p)
return iter.p;
  last_pos = *ppos;
  return rhashtable_walk_next()


and the ->next function just does

  last_pos = *ppos;
  *ppos += 1;
  do p = rhashtable_walk_next(); while (IS_ERR(p));
  return p;

It might be OK to have a function call instead of expecting people to
use iter.p directly.

static inline void *rhashtable_walk_prev(struct rhashtable_iter *iter)
{
return iter->p;
}

Thoughts?

Thanks,
NeilBrown


signature.asc
Description: PGP signature

[RESEND PATCH] x86/boot/KASLR: Extend movable_node option for KASLR

[Dou Liyang]

The movable_node option is a boot-time switch to make sure the physical
NUMA nodes can be hot-added/removed when ACPI table can't be parsed to
provide the memory hotplug information.

As we all know, there is always one node, called "home node", which
can't be movabled and the kernel image resides in it. With movable_node
option, Linux allocates new early memorys near the kernel image to avoid
using the other movable node.

But, due to KASLR also can't get the the memory hotplug information, it may
randomize the kernel image into a movable node which breaks the rule of
movable_node option and makes the physical hot-add/remove operation failed.

The perfect solution is providing the memory hotplug information to KASLR.
But, it needs the efforts from hardware engineers and software engineers.

Here is an alternative method. Extend movable_node option to restrict kernel
to be randomized in the home node by adding a parameter. this parameter sets
up the boundaries between the home nodes and other nodes.

Reported-by: Chao Fan 
Signed-off-by: Dou Liyang 
Reviewed-by: Kees Cook 
---
Changelog:
  -Rewrite the commit log and document.

 Documentation/admin-guide/kernel-parameters.txt | 12 ++--
 arch/x86/boot/compressed/kaslr.c| 19 ---
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 1d1d53f85ddd..0cfc0b10a117 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2353,7 +2353,8 @@
mousedev.yres=  [MOUSE] Vertical screen resolution, used for devices
reporting absolute coordinates, such as tablets
 
-   movablecore=nn[KMG] [KNL,X86,IA-64,PPC] This parameter
+   movablecore=nn[KMG]
+   [KNL,X86,IA-64,PPC] This parameter
is similar to kernelcore except it specifies the
amount of memory used for migratable allocations.
If both kernelcore and movablecore is specified,
@@ -2363,12 +2364,19 @@
that the amount of memory usable for all allocations
is not too small.
 
-   movable_node[KNL] Boot-time switch to make hotplugable memory
+   movable_node[KNL] Boot-time switch to make hot-pluggable memory
NUMA nodes to be movable. This means that the memory
of such nodes will be usable only for movable
allocations which rules out almost all kernel
allocations. Use with caution!
 
+   movable_node=nn[KMG]
+   [KNL] Extend movable_node to make it work well with 
KASLR.
+   This parameter is the boundaries between the "home 
node" and
+   the other nodes. The "home node" is an immovable node 
and is
+   defined by BIOS. Set the 'nn' to the memory size of 
"home
+   node", the kernel image will be extracted in immovable 
nodes.
+
MTD_Partition=  [MTD]
Format: ,,,
 
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 8199a6187251..f906d7890e69 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -92,7 +92,10 @@ struct mem_vector {
 static bool memmap_too_large;
 
 
-/* Store memory limit specified by "mem=nn[KMG]" or "memmap=nn[KMG]" */
+/*
+ * Store memory limit specified by the following situations:
+ * "mem=nn[KMG]" or "memmap=nn[KMG]" or "movable_node=nn[KMG]"
+ */
 unsigned long long mem_limit = ULLONG_MAX;
 
 
@@ -214,7 +217,8 @@ static int handle_mem_memmap(void)
char *param, *val;
u64 mem_size;
 
-   if (!strstr(args, "memmap=") && !strstr(args, "mem="))
+   if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
+   !strstr(args, "movable_node="))
return 0;
 
tmp_cmdline = malloc(len + 1);
@@ -249,7 +253,16 @@ static int handle_mem_memmap(void)
free(tmp_cmdline);
return -EINVAL;
}
-   mem_limit = mem_size;
+   mem_limit = mem_limit > mem_size ? mem_size : mem_limit;
+   } else if (!strcmp(param, "movable_node")) {
+   char *p = val;
+
+   mem_size = memparse(p, );
+   if (mem_size == 0) {
+   free(tmp_cmdline);
+   return -EINVAL;
+   }
+   mem_limit = mem_limit > mem_size ? mem_size : mem_limit;
}
}
 
-- 
2.14.3

[RESEND PATCH] x86/boot/KASLR: Extend movable_node option for KASLR

[Dou Liyang]

The movable_node option is a boot-time switch to make sure the physical
NUMA nodes can be hot-added/removed when ACPI table can't be parsed to
provide the memory hotplug information.

As we all know, there is always one node, called "home node", which
can't be movabled and the kernel image resides in it. With movable_node
option, Linux allocates new early memorys near the kernel image to avoid
using the other movable node.

But, due to KASLR also can't get the the memory hotplug information, it may
randomize the kernel image into a movable node which breaks the rule of
movable_node option and makes the physical hot-add/remove operation failed.

The perfect solution is providing the memory hotplug information to KASLR.
But, it needs the efforts from hardware engineers and software engineers.

Here is an alternative method. Extend movable_node option to restrict kernel
to be randomized in the home node by adding a parameter. this parameter sets
up the boundaries between the home nodes and other nodes.

Reported-by: Chao Fan 
Signed-off-by: Dou Liyang 
Reviewed-by: Kees Cook 
---
Changelog:
  -Rewrite the commit log and document.

 Documentation/admin-guide/kernel-parameters.txt | 12 ++--
 arch/x86/boot/compressed/kaslr.c| 19 ---
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 1d1d53f85ddd..0cfc0b10a117 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2353,7 +2353,8 @@
mousedev.yres=  [MOUSE] Vertical screen resolution, used for devices
reporting absolute coordinates, such as tablets
 
-   movablecore=nn[KMG] [KNL,X86,IA-64,PPC] This parameter
+   movablecore=nn[KMG]
+   [KNL,X86,IA-64,PPC] This parameter
is similar to kernelcore except it specifies the
amount of memory used for migratable allocations.
If both kernelcore and movablecore is specified,
@@ -2363,12 +2364,19 @@
that the amount of memory usable for all allocations
is not too small.
 
-   movable_node[KNL] Boot-time switch to make hotplugable memory
+   movable_node[KNL] Boot-time switch to make hot-pluggable memory
NUMA nodes to be movable. This means that the memory
of such nodes will be usable only for movable
allocations which rules out almost all kernel
allocations. Use with caution!
 
+   movable_node=nn[KMG]
+   [KNL] Extend movable_node to make it work well with 
KASLR.
+   This parameter is the boundaries between the "home 
node" and
+   the other nodes. The "home node" is an immovable node 
and is
+   defined by BIOS. Set the 'nn' to the memory size of 
"home
+   node", the kernel image will be extracted in immovable 
nodes.
+
MTD_Partition=  [MTD]
Format: ,,,
 
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 8199a6187251..f906d7890e69 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -92,7 +92,10 @@ struct mem_vector {
 static bool memmap_too_large;
 
 
-/* Store memory limit specified by "mem=nn[KMG]" or "memmap=nn[KMG]" */
+/*
+ * Store memory limit specified by the following situations:
+ * "mem=nn[KMG]" or "memmap=nn[KMG]" or "movable_node=nn[KMG]"
+ */
 unsigned long long mem_limit = ULLONG_MAX;
 
 
@@ -214,7 +217,8 @@ static int handle_mem_memmap(void)
char *param, *val;
u64 mem_size;
 
-   if (!strstr(args, "memmap=") && !strstr(args, "mem="))
+   if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
+   !strstr(args, "movable_node="))
return 0;
 
tmp_cmdline = malloc(len + 1);
@@ -249,7 +253,16 @@ static int handle_mem_memmap(void)
free(tmp_cmdline);
return -EINVAL;
}
-   mem_limit = mem_size;
+   mem_limit = mem_limit > mem_size ? mem_size : mem_limit;
+   } else if (!strcmp(param, "movable_node")) {
+   char *p = val;
+
+   mem_size = memparse(p, );
+   if (mem_size == 0) {
+   free(tmp_cmdline);
+   return -EINVAL;
+   }
+   mem_limit = mem_limit > mem_size ? mem_size : mem_limit;
}
}
 
-- 
2.14.3

Re: [PATCH] list_debug: Print unmangled addresses

[Tobin C. Harding]

On Sun, Apr 01, 2018 at 03:32:37PM -0700, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> The entire point of printing the pointers in list_debug is to see if
> there's any useful information in them (eg poison values, ASCII, etc);
> obscuring them to see if they compare equal makes them much less useful.
> If an attacker can force this message to be printed, we've already lost.

Is this because CONFIG_DEBUG_LIST should not be enabled on production
kernels so an attacker should never hit this?

I'm inclined to agree, if there is already a memory corruption bug,
causing this code to execute, the extra address is probably not making
the situation any worse.

(I am in no way a security expert.)

> Signed-off-by: Matthew Wilcox 

Reviewed-by: Tobin C. Harding 

> diff --git a/lib/list_debug.c b/lib/list_debug.c
> index a34db8d27667..5d5424b51b74 100644
> --- a/lib/list_debug.c
> +++ b/lib/list_debug.c
> @@ -21,13 +21,13 @@ bool __list_add_valid(struct list_head *new, struct 
> list_head *prev,
> struct list_head *next)
>  {
>   if (CHECK_DATA_CORRUPTION(next->prev != prev,
> - "list_add corruption. next->prev should be prev (%p), 
> but was %p. (next=%p).\n",
> + "list_add corruption. next->prev should be prev (%px), 
> but was %px. (next=%px).\n",
>   prev, next->prev, next) ||
>   CHECK_DATA_CORRUPTION(prev->next != next,
> - "list_add corruption. prev->next should be next (%p), 
> but was %p. (prev=%p).\n",
> + "list_add corruption. prev->next should be next (%px), 
> but was %px. (prev=%px).\n",
>   next, prev->next, prev) ||
>   CHECK_DATA_CORRUPTION(new == prev || new == next,
> - "list_add double add: new=%p, prev=%p, next=%p.\n",
> + "list_add double add: new=%px, prev=%px, next=%px.\n",
>   new, prev, next))
>   return false;
>  
> @@ -43,16 +43,16 @@ bool __list_del_entry_valid(struct list_head *entry)
>   next = entry->next;
>  
>   if (CHECK_DATA_CORRUPTION(next == LIST_POISON1,
> - "list_del corruption, %p->next is LIST_POISON1 (%p)\n",
> + "list_del corruption, %px->next is LIST_POISON1 
> (%px)\n",
>   entry, LIST_POISON1) ||
>   CHECK_DATA_CORRUPTION(prev == LIST_POISON2,
> - "list_del corruption, %p->prev is LIST_POISON2 (%p)\n",
> + "list_del corruption, %px->prev is LIST_POISON2 
> (%px)\n",
>   entry, LIST_POISON2) ||
>   CHECK_DATA_CORRUPTION(prev->next != entry,
> - "list_del corruption. prev->next should be %p, but was 
> %p\n",
> + "list_del corruption. prev->next should be %px, but was 
> %px\n",
>   entry, prev->next) ||
>   CHECK_DATA_CORRUPTION(next->prev != entry,
> - "list_del corruption. next->prev should be %p, but was 
> %p\n",
> + "list_del corruption. next->prev should be %px, but was 
> %px\n",
>   entry, next->prev))
>   return false;
>  

Re: [PATCH] list_debug: Print unmangled addresses

[Tobin C. Harding]

On Sun, Apr 01, 2018 at 03:32:37PM -0700, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> The entire point of printing the pointers in list_debug is to see if
> there's any useful information in them (eg poison values, ASCII, etc);
> obscuring them to see if they compare equal makes them much less useful.
> If an attacker can force this message to be printed, we've already lost.

Is this because CONFIG_DEBUG_LIST should not be enabled on production
kernels so an attacker should never hit this?

I'm inclined to agree, if there is already a memory corruption bug,
causing this code to execute, the extra address is probably not making
the situation any worse.

(I am in no way a security expert.)

> Signed-off-by: Matthew Wilcox 

Reviewed-by: Tobin C. Harding 

> diff --git a/lib/list_debug.c b/lib/list_debug.c
> index a34db8d27667..5d5424b51b74 100644
> --- a/lib/list_debug.c
> +++ b/lib/list_debug.c
> @@ -21,13 +21,13 @@ bool __list_add_valid(struct list_head *new, struct 
> list_head *prev,
> struct list_head *next)
>  {
>   if (CHECK_DATA_CORRUPTION(next->prev != prev,
> - "list_add corruption. next->prev should be prev (%p), 
> but was %p. (next=%p).\n",
> + "list_add corruption. next->prev should be prev (%px), 
> but was %px. (next=%px).\n",
>   prev, next->prev, next) ||
>   CHECK_DATA_CORRUPTION(prev->next != next,
> - "list_add corruption. prev->next should be next (%p), 
> but was %p. (prev=%p).\n",
> + "list_add corruption. prev->next should be next (%px), 
> but was %px. (prev=%px).\n",
>   next, prev->next, prev) ||
>   CHECK_DATA_CORRUPTION(new == prev || new == next,
> - "list_add double add: new=%p, prev=%p, next=%p.\n",
> + "list_add double add: new=%px, prev=%px, next=%px.\n",
>   new, prev, next))
>   return false;
>  
> @@ -43,16 +43,16 @@ bool __list_del_entry_valid(struct list_head *entry)
>   next = entry->next;
>  
>   if (CHECK_DATA_CORRUPTION(next == LIST_POISON1,
> - "list_del corruption, %p->next is LIST_POISON1 (%p)\n",
> + "list_del corruption, %px->next is LIST_POISON1 
> (%px)\n",
>   entry, LIST_POISON1) ||
>   CHECK_DATA_CORRUPTION(prev == LIST_POISON2,
> - "list_del corruption, %p->prev is LIST_POISON2 (%p)\n",
> + "list_del corruption, %px->prev is LIST_POISON2 
> (%px)\n",
>   entry, LIST_POISON2) ||
>   CHECK_DATA_CORRUPTION(prev->next != entry,
> - "list_del corruption. prev->next should be %p, but was 
> %p\n",
> + "list_del corruption. prev->next should be %px, but was 
> %px\n",
>   entry, prev->next) ||
>   CHECK_DATA_CORRUPTION(next->prev != entry,
> - "list_del corruption. next->prev should be %p, but was 
> %p\n",
> + "list_del corruption. next->prev should be %px, but was 
> %px\n",
>   entry, next->prev))
>   return false;
>  

Re: [PATCH AUTOSEL for 4.15 058/124] ipv6: Set nexthop flags during route creation

[Sasha Levin]

On Mon, Mar 19, 2018 at 08:04:34PM +0200, Ido Schimmel wrote:
>On Mon, Mar 19, 2018 at 03:48:00PM +, Sasha Levin wrote:
>> From: Ido Schimmel 
>>
>> [ Upstream commit 5609b80a37f69f796548339e675256188b29c17d ]
>>
>> It is valid to install routes with a nexthop device that does not have a
>> carrier, so we need to make sure they're marked accordingly.
>>
>> As explained in the previous patch, host and anycast routes are never
>> marked with the 'linkdown' flag.
>>
>> Note that reject routes are unaffected, as these use the loopback device
>> which always has a carrier.
>>
>> Signed-off-by: Ido Schimmel 
>> Acked-by: David Ahern 
>> Signed-off-by: David S. Miller 
>> Signed-off-by: Sasha Levin 
>
>Hi Sasha,
>
>It doesn't really make sense to take this patch to 4.15 (and 4.14 from
>your other mail). The flag is never used there.
>
>In these kernels the flag is dumped to user space based on a carrier
>check. See commit 44c9f2f206f8 ("ipv6: Check nexthop flags in route dump
>instead of carrier").
>
>Similarly, during route lookup the carrier is checked and not the flag.
>See commit 14c5206c2d02 ("ipv6: Check nexthop flags during route lookup
>instead of carrier").
>
>Thanks

Now removed, thanks!

Re: [PATCH AUTOSEL for 4.15 058/124] ipv6: Set nexthop flags during route creation

[Sasha Levin]

On Mon, Mar 19, 2018 at 08:04:34PM +0200, Ido Schimmel wrote:
>On Mon, Mar 19, 2018 at 03:48:00PM +, Sasha Levin wrote:
>> From: Ido Schimmel 
>>
>> [ Upstream commit 5609b80a37f69f796548339e675256188b29c17d ]
>>
>> It is valid to install routes with a nexthop device that does not have a
>> carrier, so we need to make sure they're marked accordingly.
>>
>> As explained in the previous patch, host and anycast routes are never
>> marked with the 'linkdown' flag.
>>
>> Note that reject routes are unaffected, as these use the loopback device
>> which always has a carrier.
>>
>> Signed-off-by: Ido Schimmel 
>> Acked-by: David Ahern 
>> Signed-off-by: David S. Miller 
>> Signed-off-by: Sasha Levin 
>
>Hi Sasha,
>
>It doesn't really make sense to take this patch to 4.15 (and 4.14 from
>your other mail). The flag is never used there.
>
>In these kernels the flag is dumped to user space based on a carrier
>check. See commit 44c9f2f206f8 ("ipv6: Check nexthop flags in route dump
>instead of carrier").
>
>Similarly, during route lookup the carrier is checked and not the flag.
>See commit 14c5206c2d02 ("ipv6: Check nexthop flags during route lookup
>instead of carrier").
>
>Thanks

Now removed, thanks!

Re: [PATCH AUTOSEL for 4.15 070/124] netfilter: core: only allow one nat hook per hook point

[Sasha Levin]

On Mon, Mar 19, 2018 at 04:56:49PM +0100, Florian Westphal wrote:
>Sasha Levin  wrote:
>> From: Florian Westphal 
>>
>> [ Upstream commit f92b40a8b2645af38bd6814651c59c1e690db53d ]
>
>This patch is broken and a fix is not in any tree yet.

Removed for now, thanks!

Re: [PATCH AUTOSEL for 4.15 070/124] netfilter: core: only allow one nat hook per hook point

[Sasha Levin]

On Mon, Mar 19, 2018 at 04:56:49PM +0100, Florian Westphal wrote:
>Sasha Levin  wrote:
>> From: Florian Westphal 
>>
>> [ Upstream commit f92b40a8b2645af38bd6814651c59c1e690db53d ]
>
>This patch is broken and a fix is not in any tree yet.

Removed for now, thanks!

Re: [PATCH AUTOSEL for 4.15 104/124] clk: fix reentrancy of clk_enable() on UP systems

[Sasha Levin]

On Mon, Mar 19, 2018 at 10:55:16AM -0500, David Lechner wrote:
>On 03/19/2018 10:48 AM, Sasha Levin wrote:
>>From: David Lechner 
>>
>>[ Upstream commit a12aa8a68dfef5de181f2e555aa950a0ab05411f ]
>>
>>Reentrant calls to clk_enable() are not working on UP systems. This is
>>caused by the fact spin_trylock_irqsave() always returns true when
>>CONFIG_SMP=n (and CONFIG_DEBUG_SPINLOCK=n) which causes the reference
>>counting to not work correctly when clk_enable_lock() is called twice
>>before clk_enable_unlock() is called (this happens when clk_enable()
>>is called from within another clk_enable()).
>>
>>This fixes the problem by skipping the call to spin_trylock_irqsave() on UP
>>systems and relying solely on reference counting. We also make sure to set
>>flags in this case so that we are not returning an uninitialized value.
>>
>>Suggested-by: Stephen Boyd 
>>Signed-off-by: David Lechner 
>>Signed-off-by: Stephen Boyd 
>>Signed-off-by: Sasha Levin 
>>---
>
>I don't know of any existing bugs in v4.15 that this fixes, so I don't
>think this really fits the criteria for stable.
>

Now removed, thanks!

Re: [PATCH AUTOSEL for 4.15 104/124] clk: fix reentrancy of clk_enable() on UP systems

[Sasha Levin]

On Mon, Mar 19, 2018 at 10:55:16AM -0500, David Lechner wrote:
>On 03/19/2018 10:48 AM, Sasha Levin wrote:
>>From: David Lechner 
>>
>>[ Upstream commit a12aa8a68dfef5de181f2e555aa950a0ab05411f ]
>>
>>Reentrant calls to clk_enable() are not working on UP systems. This is
>>caused by the fact spin_trylock_irqsave() always returns true when
>>CONFIG_SMP=n (and CONFIG_DEBUG_SPINLOCK=n) which causes the reference
>>counting to not work correctly when clk_enable_lock() is called twice
>>before clk_enable_unlock() is called (this happens when clk_enable()
>>is called from within another clk_enable()).
>>
>>This fixes the problem by skipping the call to spin_trylock_irqsave() on UP
>>systems and relying solely on reference counting. We also make sure to set
>>flags in this case so that we are not returning an uninitialized value.
>>
>>Suggested-by: Stephen Boyd 
>>Signed-off-by: David Lechner 
>>Signed-off-by: Stephen Boyd 
>>Signed-off-by: Sasha Levin 
>>---
>
>I don't know of any existing bugs in v4.15 that this fixes, so I don't
>think this really fits the criteria for stable.
>

Now removed, thanks!

Re: [PATCH AUTOSEL for 4.15 050/124] ACPICA: Recognize the Windows 10 version 1607 and 1703 OSI strings

[Sasha Levin]

On Mon, Mar 26, 2018 at 09:12:03AM +, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Sasha Levin [mailto:alexander.le...@microsoft.com]
>> Sent: Monday, March 19, 2018 10:48 AM
>> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org
>> Cc: Limonciello, Mario ; Bob Moore
>> ; Erik Schmauss ; Rafael J .
>> Wysocki ; Sasha Levin
>> 
>> Subject: [PATCH AUTOSEL for 4.15 050/124] ACPICA: Recognize the Windows 10
>> version 1607 and 1703 OSI strings
>>
>> From: Mario Limonciello 
>>
>> [ Upstream commit bc4d413a819f9d0764a80a55875a5d7e1f4efed4 ]
>>
>> ACPICA commit 35a4a3ea723b3066f575e63e5f0116f7ce65e713
>>
>> The public Microsoft document listing recognized OSI strings [1]
>> shows that these two strings were introduced.
>> version 1607 / Anniversary Update / "Redstone 1"
>> version 1703 / Creators Update / "Redstone 2"
>>
>> [1] 
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F7%2Fe%2F7%2F7e7662cf-cbea-470b-a97e-=02%7C01%7CAlexander.Levin%40microsoft.com%7Cb0cf5563b7b94791931308d592f9ae36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636576523455359326=7lMyl7MXqi9L1P4YXo2PwUzTH40lX79sNvUlPwCvwDE%3D=0
>> ce7ce0d98dc2/winacpi_osi.docx
>>
>> Link: 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Facpica%2Facpica%2Fcommit%2F35a4a3ea=02%7C01%7CAlexander.Levin%40microsoft.com%7Cb0cf5563b7b94791931308d592f9ae36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636576523455359326=UJvpvV9lxIlDCsWsLjTmpFJjEWFUiWUOmFu%2B5jjk800%3D=0
>> Signed-off-by: Mario Limonciello 
>> Signed-off-by: Bob Moore 
>> Signed-off-by: Erik Schmauss 
>> Signed-off-by: Rafael J. Wysocki 
>> Signed-off-by: Sasha Levin 
>> ---
>>  drivers/acpi/acpica/utosi.c | 2 ++
>>  include/acpi/actypes.h  | 2 ++
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/acpi/acpica/utosi.c b/drivers/acpi/acpica/utosi.c
>> index 3175b133c0e4..f6b8dd24b006 100644
>> --- a/drivers/acpi/acpica/utosi.c
>> +++ b/drivers/acpi/acpica/utosi.c
>> @@ -101,6 +101,8 @@ static struct acpi_interface_info
>> acpi_default_supported_interfaces[] = {
>>  {"Windows 2012", NULL, 0, ACPI_OSI_WIN_8},  /* Windows 8 and Server
>> 2012 - Added 08/2012 */
>>  {"Windows 2013", NULL, 0, ACPI_OSI_WIN_8},  /* Windows 8.1 and 
>> Server
>> 2012 R2 - Added 01/2014 */
>>  {"Windows 2015", NULL, 0, ACPI_OSI_WIN_10}, /* Windows 10 - Added
>> 03/2015 */
>> +{"Windows 2016", NULL, 0, ACPI_OSI_WIN_10_RS1}, /* Windows 10
>> version 1607 - Added 12/2017 */
>> +{"Windows 2017", NULL, 0, ACPI_OSI_WIN_10_RS2}, /* Windows 10
>> version 1703 - Added 12/2017 */
>>
>>  /* Feature Group Strings */
>>
>> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
>> index 4f077edb9b81..bfc8a814379a 100644
>> --- a/include/acpi/actypes.h
>> +++ b/include/acpi/actypes.h
>> @@ -1299,6 +1299,8 @@ typedef enum {
>>  #define ACPI_OSI_WIN_7  0x0B
>>  #define ACPI_OSI_WIN_8  0x0C
>>  #define ACPI_OSI_WIN_10 0x0D
>> +#define ACPI_OSI_WIN_10_RS1 0x0E
>> +#define ACPI_OSI_WIN_10_RS2 0x0F
>>
>>  /* Definitions of getopt */
>>
>> --
>> 2.14.1
>
>This is fine by me for 4.15, as mentioned in other email I don't think it 
>should go to 4.14, 4.9 or 4.4.

Fixed it up, thanks!

Re: [PATCH AUTOSEL for 4.15 050/124] ACPICA: Recognize the Windows 10 version 1607 and 1703 OSI strings

[Sasha Levin]

On Mon, Mar 26, 2018 at 09:12:03AM +, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Sasha Levin [mailto:alexander.le...@microsoft.com]
>> Sent: Monday, March 19, 2018 10:48 AM
>> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org
>> Cc: Limonciello, Mario ; Bob Moore
>> ; Erik Schmauss ; Rafael J .
>> Wysocki ; Sasha Levin
>> 
>> Subject: [PATCH AUTOSEL for 4.15 050/124] ACPICA: Recognize the Windows 10
>> version 1607 and 1703 OSI strings
>>
>> From: Mario Limonciello 
>>
>> [ Upstream commit bc4d413a819f9d0764a80a55875a5d7e1f4efed4 ]
>>
>> ACPICA commit 35a4a3ea723b3066f575e63e5f0116f7ce65e713
>>
>> The public Microsoft document listing recognized OSI strings [1]
>> shows that these two strings were introduced.
>> version 1607 / Anniversary Update / "Redstone 1"
>> version 1703 / Creators Update / "Redstone 2"
>>
>> [1] 
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F7%2Fe%2F7%2F7e7662cf-cbea-470b-a97e-=02%7C01%7CAlexander.Levin%40microsoft.com%7Cb0cf5563b7b94791931308d592f9ae36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636576523455359326=7lMyl7MXqi9L1P4YXo2PwUzTH40lX79sNvUlPwCvwDE%3D=0
>> ce7ce0d98dc2/winacpi_osi.docx
>>
>> Link: 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Facpica%2Facpica%2Fcommit%2F35a4a3ea=02%7C01%7CAlexander.Levin%40microsoft.com%7Cb0cf5563b7b94791931308d592f9ae36%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636576523455359326=UJvpvV9lxIlDCsWsLjTmpFJjEWFUiWUOmFu%2B5jjk800%3D=0
>> Signed-off-by: Mario Limonciello 
>> Signed-off-by: Bob Moore 
>> Signed-off-by: Erik Schmauss 
>> Signed-off-by: Rafael J. Wysocki 
>> Signed-off-by: Sasha Levin 
>> ---
>>  drivers/acpi/acpica/utosi.c | 2 ++
>>  include/acpi/actypes.h  | 2 ++
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/acpi/acpica/utosi.c b/drivers/acpi/acpica/utosi.c
>> index 3175b133c0e4..f6b8dd24b006 100644
>> --- a/drivers/acpi/acpica/utosi.c
>> +++ b/drivers/acpi/acpica/utosi.c
>> @@ -101,6 +101,8 @@ static struct acpi_interface_info
>> acpi_default_supported_interfaces[] = {
>>  {"Windows 2012", NULL, 0, ACPI_OSI_WIN_8},  /* Windows 8 and Server
>> 2012 - Added 08/2012 */
>>  {"Windows 2013", NULL, 0, ACPI_OSI_WIN_8},  /* Windows 8.1 and 
>> Server
>> 2012 R2 - Added 01/2014 */
>>  {"Windows 2015", NULL, 0, ACPI_OSI_WIN_10}, /* Windows 10 - Added
>> 03/2015 */
>> +{"Windows 2016", NULL, 0, ACPI_OSI_WIN_10_RS1}, /* Windows 10
>> version 1607 - Added 12/2017 */
>> +{"Windows 2017", NULL, 0, ACPI_OSI_WIN_10_RS2}, /* Windows 10
>> version 1703 - Added 12/2017 */
>>
>>  /* Feature Group Strings */
>>
>> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
>> index 4f077edb9b81..bfc8a814379a 100644
>> --- a/include/acpi/actypes.h
>> +++ b/include/acpi/actypes.h
>> @@ -1299,6 +1299,8 @@ typedef enum {
>>  #define ACPI_OSI_WIN_7  0x0B
>>  #define ACPI_OSI_WIN_8  0x0C
>>  #define ACPI_OSI_WIN_10 0x0D
>> +#define ACPI_OSI_WIN_10_RS1 0x0E
>> +#define ACPI_OSI_WIN_10_RS2 0x0F
>>
>>  /* Definitions of getopt */
>>
>> --
>> 2.14.1
>
>This is fine by me for 4.15, as mentioned in other email I don't think it 
>should go to 4.14, 4.9 or 4.4.

Fixed it up, thanks!

Re: [PATCH 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

[Palmer Dabbelt]

On Mon, 02 Apr 2018 05:31:22 PDT (-0700), alan...@andestech.com wrote:

This implements the baseline PMU for RISC-V platforms.

To ease future PMU portings, a guide is also written, containing
perf concepts, arch porting practices and some hints.

Changes in v2:
 - Fix the bug reported by Alex, which was caused by not sufficient
   initialization.  Check https://lkml.org/lkml/2018/3/31/251 for the
   discussion.

Alan Kao (2):
  perf: riscv: preliminary RISC-V support
  perf: riscv: Add Document for Future Porting Guide

 Documentation/riscv/pmu.txt | 249 +++
 arch/riscv/Kconfig  |  12 +
 arch/riscv/include/asm/perf_event.h |  76 +-
 arch/riscv/kernel/Makefile  |   1 +
 arch/riscv/kernel/perf_event.c  | 468 
 5 files changed, 802 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/riscv/pmu.txt
 create mode 100644 arch/riscv/kernel/perf_event.c


I'm having some trouble pulling this into my tree.  I think you might have 
another patch floating around somewhere, as I don't have any 
arch/riscv/include/asm/perf_event.h right now.


Do you mind rebasing this on top of linux-4.16 so I can look properly?

Thanks!

Re: [PATCH 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

[Palmer Dabbelt]

On Mon, 02 Apr 2018 05:31:22 PDT (-0700), alan...@andestech.com wrote:

This implements the baseline PMU for RISC-V platforms.

To ease future PMU portings, a guide is also written, containing
perf concepts, arch porting practices and some hints.

Changes in v2:
 - Fix the bug reported by Alex, which was caused by not sufficient
   initialization.  Check https://lkml.org/lkml/2018/3/31/251 for the
   discussion.

Alan Kao (2):
  perf: riscv: preliminary RISC-V support
  perf: riscv: Add Document for Future Porting Guide

 Documentation/riscv/pmu.txt | 249 +++
 arch/riscv/Kconfig  |  12 +
 arch/riscv/include/asm/perf_event.h |  76 +-
 arch/riscv/kernel/Makefile  |   1 +
 arch/riscv/kernel/perf_event.c  | 468 
 5 files changed, 802 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/riscv/pmu.txt
 create mode 100644 arch/riscv/kernel/perf_event.c


I'm having some trouble pulling this into my tree.  I think you might have 
another patch floating around somewhere, as I don't have any 
arch/riscv/include/asm/perf_event.h right now.


Do you mind rebasing this on top of linux-4.16 so I can look properly?

Thanks!

linux-next: manual merge of the net-next tree with the pci tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/ethernet/mellanox/mlx5/core/en_main.c

between commit:

  2907938d2375 ("net/mlx5e: Use pcie_bandwidth_available() to compute 
bandwidth")

from the pci tree and commit:

  0608d4dbaf4e ("net/mlx5e: Unify slow PCI heuristic")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 884337f88589,0aab3afc6885..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -3880,16 -4026,50 +4033,20 @@@ void mlx5e_build_default_indir_rqt(u32 
indirection_rqt[i] = i % num_channels;
  }
  
- static bool cqe_compress_heuristic(u32 link_speed, u32 pci_bw)
 -static int mlx5e_get_pci_bw(struct mlx5_core_dev *mdev, u32 *pci_bw)
 -{
 -  enum pcie_link_width width;
 -  enum pci_bus_speed speed;
 -  int err = 0;
 -
 -  err = pcie_get_minimum_link(mdev->pdev, , );
 -  if (err)
 -  return err;
 -
 -  if (speed == PCI_SPEED_UNKNOWN || width == PCIE_LNK_WIDTH_UNKNOWN)
 -  return -EINVAL;
 -
 -  switch (speed) {
 -  case PCIE_SPEED_2_5GT:
 -  *pci_bw = 2500 * width;
 -  break;
 -  case PCIE_SPEED_5_0GT:
 -  *pci_bw = 5000 * width;
 -  break;
 -  case PCIE_SPEED_8_0GT:
 -  *pci_bw = 8000 * width;
 -  break;
 -  default:
 -  return -EINVAL;
 -  }
 -
 -  return 0;
 -}
 -
+ static bool slow_pci_heuristic(struct mlx5_core_dev *mdev)
  {
-   return (link_speed && pci_bw &&
-   (pci_bw < 4) && (pci_bw < link_speed));
- }
+   u32 link_speed = 0;
+   u32 pci_bw = 0;
  
- static bool hw_lro_heuristic(u32 link_speed, u32 pci_bw)
- {
-   return !(link_speed && pci_bw &&
-(pci_bw <= 16000) && (pci_bw < link_speed));
+   mlx5e_get_max_linkspeed(mdev, _speed);
 -  mlx5e_get_pci_bw(mdev, _bw);
++  pci_bw = pcie_bandwidth_available(mdev->pdev, NULL, NULL, NULL);
+   mlx5_core_dbg_once(mdev, "Max link speed = %d, PCI BW = %d\n",
+  link_speed, pci_bw);
+ 
+ #define MLX5E_SLOW_PCI_RATIO (2)
+ 
+   return link_speed && pci_bw &&
+   link_speed > MLX5E_SLOW_PCI_RATIO * pci_bw;
  }
  
  void mlx5e_set_tx_cq_mode_params(struct mlx5e_params *params, u8 
cq_period_mode)


pgpUqNqnSHUYs.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the net-next tree with the pci tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/ethernet/mellanox/mlx5/core/en_main.c

between commit:

  2907938d2375 ("net/mlx5e: Use pcie_bandwidth_available() to compute 
bandwidth")

from the pci tree and commit:

  0608d4dbaf4e ("net/mlx5e: Unify slow PCI heuristic")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 884337f88589,0aab3afc6885..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -3880,16 -4026,50 +4033,20 @@@ void mlx5e_build_default_indir_rqt(u32 
indirection_rqt[i] = i % num_channels;
  }
  
- static bool cqe_compress_heuristic(u32 link_speed, u32 pci_bw)
 -static int mlx5e_get_pci_bw(struct mlx5_core_dev *mdev, u32 *pci_bw)
 -{
 -  enum pcie_link_width width;
 -  enum pci_bus_speed speed;
 -  int err = 0;
 -
 -  err = pcie_get_minimum_link(mdev->pdev, , );
 -  if (err)
 -  return err;
 -
 -  if (speed == PCI_SPEED_UNKNOWN || width == PCIE_LNK_WIDTH_UNKNOWN)
 -  return -EINVAL;
 -
 -  switch (speed) {
 -  case PCIE_SPEED_2_5GT:
 -  *pci_bw = 2500 * width;
 -  break;
 -  case PCIE_SPEED_5_0GT:
 -  *pci_bw = 5000 * width;
 -  break;
 -  case PCIE_SPEED_8_0GT:
 -  *pci_bw = 8000 * width;
 -  break;
 -  default:
 -  return -EINVAL;
 -  }
 -
 -  return 0;
 -}
 -
+ static bool slow_pci_heuristic(struct mlx5_core_dev *mdev)
  {
-   return (link_speed && pci_bw &&
-   (pci_bw < 4) && (pci_bw < link_speed));
- }
+   u32 link_speed = 0;
+   u32 pci_bw = 0;
  
- static bool hw_lro_heuristic(u32 link_speed, u32 pci_bw)
- {
-   return !(link_speed && pci_bw &&
-(pci_bw <= 16000) && (pci_bw < link_speed));
+   mlx5e_get_max_linkspeed(mdev, _speed);
 -  mlx5e_get_pci_bw(mdev, _bw);
++  pci_bw = pcie_bandwidth_available(mdev->pdev, NULL, NULL, NULL);
+   mlx5_core_dbg_once(mdev, "Max link speed = %d, PCI BW = %d\n",
+  link_speed, pci_bw);
+ 
+ #define MLX5E_SLOW_PCI_RATIO (2)
+ 
+   return link_speed && pci_bw &&
+   link_speed > MLX5E_SLOW_PCI_RATIO * pci_bw;
  }
  
  void mlx5e_set_tx_cq_mode_params(struct mlx5e_params *params, u8 
cq_period_mode)


pgpUqNqnSHUYs.pgp
Description: OpenPGP digital signature

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

[Eric Biggers]

On Mon, Apr 02, 2018 at 06:00:57PM -0500, Eric W. Biederman wrote:
> syzbot  writes:
> 
> > Hello,
> >
> > syzbot hit the following crash on upstream commit
> > 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
> > Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client
> > syzbot dashboard link:
> > https://syzkaller.appspot.com/bug?extid=7a1cff37dbbef9e7ba4c
> >
> > So far this crash happened 4 times on upstream.
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> 
> Do you have any of the other traces?  This looks like a something is
> calling put_pid_ns more than it is calling get_pid_ns causing a
> reference count mismatch.
> 
> If this is not: 9ee332d99e4d5a97548943b81c54668450ce641b
> 
> I could use a few more hints to help narrow down what is going wrong.
> 
> It would be nice to know what the other 3 crashes looked like and
> exactly which upstream they were on.
> 

The other crashes are shown on the syzbot dashboard (link was given in the
original email).

Eric

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

[Eric Biggers]

On Mon, Apr 02, 2018 at 06:00:57PM -0500, Eric W. Biederman wrote:
> syzbot  writes:
> 
> > Hello,
> >
> > syzbot hit the following crash on upstream commit
> > 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
> > Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client
> > syzbot dashboard link:
> > https://syzkaller.appspot.com/bug?extid=7a1cff37dbbef9e7ba4c
> >
> > So far this crash happened 4 times on upstream.
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> 
> Do you have any of the other traces?  This looks like a something is
> calling put_pid_ns more than it is calling get_pid_ns causing a
> reference count mismatch.
> 
> If this is not: 9ee332d99e4d5a97548943b81c54668450ce641b
> 
> I could use a few more hints to help narrow down what is going wrong.
> 
> It would be nice to know what the other 3 crashes looked like and
> exactly which upstream they were on.
> 

The other crashes are shown on the syzbot dashboard (link was given in the
original email).

Eric

Re: [PATCH v5 1/5] mm: page_alloc: remain memblock_next_valid_pfn() on arm and arm64

[Jia He]

On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote:

On 2 April 2018 at 09:49, Jia He  wrote:


On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote:

On 2 April 2018 at 04:30, Jia He  wrote:

Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.

But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.

On arm and arm64, memblock is used by default. But generic version of
pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
not always return the next valid one but skips more resulting in some
valid frames to be skipped (as if they were invalid). And that's why
kernel was eventually crashing on some !arm machines.

And as verified by Eugeniu Rosca, arm can benifit from commit
b92df1de5d28. So remain the memblock_next_valid_pfn on arm{,64} and move
the related codes to arm64 arch directory.

Suggested-by: Daniel Vacek 
Signed-off-by: Jia He 

Hello Jia,

Apologies for chiming in late.

no problem, thanks for your comments  ;-)


If we are going to rearchitect this, I'd rather we change the loop in
memmap_init_zone() so that we skip to the next valid PFN directly
rather than skipping to the last invalid PFN so that the pfn++ in the

hmm... Maybe this macro name makes you confused

pfn = skip_to_last_invalid_pfn(pfn);

how about skip_to_next_valid_pfn?


for () results in the next value. Can we replace the pfn++ there with
a function calls that defaults to 'return pfn + 1', but does the skip
for architectures that implement it?

I am not sure I understand your question here.
With this patch, on !arm arches, skip_to_last_invalid_pfn is equal to (pfn),
and will be increased
when for{} loop continue. We only *skip* to the start pfn of next valid
region when
CONFIG_HAVE_MEMBLOCK and CONFIG_HAVE_ARCH_PFN_VALID(arm/arm64 supports
both).


What I am saying is that the loop in memmap_init_zone

for (pfn = start_pfn; pfn < end_pfn; pfn++) { ... }

should be replaced by something like

for (pfn = start_pfn; pfn < end_pfn; pfn = next_valid_pfn(pfn))

where next_valid_pfn() is simply defined as

static ulong next_valid_pfn(ulong pfn)
{
   return pfn + 1;
}

Hi Ard,
Do you think a macro instead of simply fuction is better here?
--
Cheer,
Jia

Re: [PATCH v5 1/5] mm: page_alloc: remain memblock_next_valid_pfn() on arm and arm64

[Jia He]

On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote:

On 2 April 2018 at 09:49, Jia He  wrote:


On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote:

On 2 April 2018 at 04:30, Jia He  wrote:

Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.

But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.

On arm and arm64, memblock is used by default. But generic version of
pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
not always return the next valid one but skips more resulting in some
valid frames to be skipped (as if they were invalid). And that's why
kernel was eventually crashing on some !arm machines.

And as verified by Eugeniu Rosca, arm can benifit from commit
b92df1de5d28. So remain the memblock_next_valid_pfn on arm{,64} and move
the related codes to arm64 arch directory.

Suggested-by: Daniel Vacek 
Signed-off-by: Jia He 

Hello Jia,

Apologies for chiming in late.

no problem, thanks for your comments  ;-)


If we are going to rearchitect this, I'd rather we change the loop in
memmap_init_zone() so that we skip to the next valid PFN directly
rather than skipping to the last invalid PFN so that the pfn++ in the

hmm... Maybe this macro name makes you confused

pfn = skip_to_last_invalid_pfn(pfn);

how about skip_to_next_valid_pfn?


for () results in the next value. Can we replace the pfn++ there with
a function calls that defaults to 'return pfn + 1', but does the skip
for architectures that implement it?

I am not sure I understand your question here.
With this patch, on !arm arches, skip_to_last_invalid_pfn is equal to (pfn),
and will be increased
when for{} loop continue. We only *skip* to the start pfn of next valid
region when
CONFIG_HAVE_MEMBLOCK and CONFIG_HAVE_ARCH_PFN_VALID(arm/arm64 supports
both).


What I am saying is that the loop in memmap_init_zone

for (pfn = start_pfn; pfn < end_pfn; pfn++) { ... }

should be replaced by something like

for (pfn = start_pfn; pfn < end_pfn; pfn = next_valid_pfn(pfn))

where next_valid_pfn() is simply defined as

static ulong next_valid_pfn(ulong pfn)
{
   return pfn + 1;
}

Hi Ard,
Do you think a macro instead of simply fuction is better here?
--
Cheer,
Jia

KASAN: use-after-free Read in uprobe_perf_close

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +)
Merge branch 'ras-core-for-linus' of  
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=cef9473c7fa0fe8ab95e


So far this crash happened 4 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6655209589702656
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6230110906613760
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5321669220499456
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6801295859785128502

compiler: gcc (GCC) 7.1.1 20170620

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cef9473c7fa0fe8ab...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

IPVS: ftp: loaded support on port[0] = 21
==
BUG: KASAN: use-after-free in uprobe_perf_close+0x3e0/0x570  
kernel/trace/trace_uprobe.c:1048

Read of size 4 at addr 8801d955264c by task syzkaller474457/4485

CPU: 0 PID: 4485 Comm: syzkaller474457 Not tainted 4.16.0+ #376
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+0x1a7/0x27d lib/dump_stack.c:53
 print_address_description+0x73/0x250 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x23c/0x360 mm/kasan/report.c:412
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
 uprobe_perf_close+0x3e0/0x570 kernel/trace/trace_uprobe.c:1048
 trace_uprobe_register+0x4cb/0xc00 kernel/trace/trace_uprobe.c:1210
 perf_trace_event_close kernel/trace/trace_event_perf.c:186 [inline]
 perf_uprobe_destroy+0x9b/0x130 kernel/trace/trace_event_perf.c:335
 _free_event+0x3d7/0x11f0 kernel/events/core.c:4445
 put_event+0x35/0x40 kernel/events/core.c:4528
 perf_event_release_kernel+0x6e8/0xfe0 kernel/events/core.c:4634
 perf_release+0x37/0x50 kernel/events/core.c:4644
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:243
 task_work_run+0x1ab/0x280 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0xa75/0x2700 kernel/exit.c:865
 do_group_exit+0x149/0x400 kernel/exit.c:968
 SYSC_exit_group kernel/exit.c:979 [inline]
 SyS_exit_group+0x1d/0x20 kernel/exit.c:977
 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x445c89
RSP: 002b:7ffd332827e8 EFLAGS: 0206 ORIG_RAX: 00e7
RAX: ffda RBX:  RCX: 00445c89
RDX: 00445c89 RSI: 00445c89 RDI: 0001
RBP: 006da018 R08:  R09: 00406fd0
R10:  R11: 0206 R12: 00406f40
R13: 00406fd0 R14:  R15: 

Allocated by task 4485:
 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:552
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
 kmem_cache_alloc_node+0x144/0x760 mm/slab.c:3632
 alloc_task_struct_node kernel/fork.c:157 [inline]
 dup_task_struct kernel/fork.c:770 [inline]
 copy_process.part.38+0x1ab9/0x6140 kernel/fork.c:1631
 copy_process kernel/fork.c:1606 [inline]
 _do_fork+0x1f7/0xfa0 kernel/fork.c:2087
 SYSC_clone kernel/fork.c:2194 [inline]
 SyS_clone+0x37/0x50 kernel/fork.c:2188
 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

Freed by task 0:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459 [inline]
 __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
 __cache_free mm/slab.c:3486 [inline]
 kmem_cache_free+0x83/0x2a0 mm/slab.c:3744
 free_task_struct kernel/fork.c:162 [inline]
 free_task+0x155/0x1b0 kernel/fork.c:391
 __put_task_struct+0x24b/0x3e0 kernel/fork.c:657
 put_task_struct include/linux/sched/task.h:96 [inline]
 delayed_put_task_struct+0xd8/0x3e0 kernel/exit.c:180
 __rcu_reclaim kernel/rcu/rcu.h:178 [inline]
 rcu_do_batch kernel/rcu/tree.c:2675 [inline]
 invoke_rcu_callbacks kernel/rcu/tree.c:2930 [inline]
 __rcu_process_callbacks kernel/rcu/tree.c:2897 [inline]
 rcu_process_callbacks+0xd6c/0x17b0 kernel/rcu/tree.c:2914
 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285

The buggy address belongs to the object at 8801d9552600
 which belongs to the cache task_struct of size 6016
The buggy address is located 76 bytes inside of
 6016-byte region [8801d9552600, 8801d9553d80)
The buggy address belongs to the page:
page:ea0007655480 count:1 mapcount:0 mapping:8801d9552600 index:0x0  
compound_mapcount: 0

flags: 

KASAN: use-after-free Read in uprobe_perf_close

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +)
Merge branch 'ras-core-for-linus' of  
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=cef9473c7fa0fe8ab95e


So far this crash happened 4 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6655209589702656
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6230110906613760
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5321669220499456
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6801295859785128502

compiler: gcc (GCC) 7.1.1 20170620

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cef9473c7fa0fe8ab...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

IPVS: ftp: loaded support on port[0] = 21
==
BUG: KASAN: use-after-free in uprobe_perf_close+0x3e0/0x570  
kernel/trace/trace_uprobe.c:1048

Read of size 4 at addr 8801d955264c by task syzkaller474457/4485

CPU: 0 PID: 4485 Comm: syzkaller474457 Not tainted 4.16.0+ #376
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+0x1a7/0x27d lib/dump_stack.c:53
 print_address_description+0x73/0x250 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x23c/0x360 mm/kasan/report.c:412
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
 uprobe_perf_close+0x3e0/0x570 kernel/trace/trace_uprobe.c:1048
 trace_uprobe_register+0x4cb/0xc00 kernel/trace/trace_uprobe.c:1210
 perf_trace_event_close kernel/trace/trace_event_perf.c:186 [inline]
 perf_uprobe_destroy+0x9b/0x130 kernel/trace/trace_event_perf.c:335
 _free_event+0x3d7/0x11f0 kernel/events/core.c:4445
 put_event+0x35/0x40 kernel/events/core.c:4528
 perf_event_release_kernel+0x6e8/0xfe0 kernel/events/core.c:4634
 perf_release+0x37/0x50 kernel/events/core.c:4644
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:243
 task_work_run+0x1ab/0x280 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0xa75/0x2700 kernel/exit.c:865
 do_group_exit+0x149/0x400 kernel/exit.c:968
 SYSC_exit_group kernel/exit.c:979 [inline]
 SyS_exit_group+0x1d/0x20 kernel/exit.c:977
 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x445c89
RSP: 002b:7ffd332827e8 EFLAGS: 0206 ORIG_RAX: 00e7
RAX: ffda RBX:  RCX: 00445c89
RDX: 00445c89 RSI: 00445c89 RDI: 0001
RBP: 006da018 R08:  R09: 00406fd0
R10:  R11: 0206 R12: 00406f40
R13: 00406fd0 R14:  R15: 

Allocated by task 4485:
 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:552
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
 kmem_cache_alloc_node+0x144/0x760 mm/slab.c:3632
 alloc_task_struct_node kernel/fork.c:157 [inline]
 dup_task_struct kernel/fork.c:770 [inline]
 copy_process.part.38+0x1ab9/0x6140 kernel/fork.c:1631
 copy_process kernel/fork.c:1606 [inline]
 _do_fork+0x1f7/0xfa0 kernel/fork.c:2087
 SYSC_clone kernel/fork.c:2194 [inline]
 SyS_clone+0x37/0x50 kernel/fork.c:2188
 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

Freed by task 0:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459 [inline]
 __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
 __cache_free mm/slab.c:3486 [inline]
 kmem_cache_free+0x83/0x2a0 mm/slab.c:3744
 free_task_struct kernel/fork.c:162 [inline]
 free_task+0x155/0x1b0 kernel/fork.c:391
 __put_task_struct+0x24b/0x3e0 kernel/fork.c:657
 put_task_struct include/linux/sched/task.h:96 [inline]
 delayed_put_task_struct+0xd8/0x3e0 kernel/exit.c:180
 __rcu_reclaim kernel/rcu/rcu.h:178 [inline]
 rcu_do_batch kernel/rcu/tree.c:2675 [inline]
 invoke_rcu_callbacks kernel/rcu/tree.c:2930 [inline]
 __rcu_process_callbacks kernel/rcu/tree.c:2897 [inline]
 rcu_process_callbacks+0xd6c/0x17b0 kernel/rcu/tree.c:2914
 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285

The buggy address belongs to the object at 8801d9552600
 which belongs to the cache task_struct of size 6016
The buggy address is located 76 bytes inside of
 6016-byte region [8801d9552600, 8801d9553d80)
The buggy address belongs to the page:
page:ea0007655480 count:1 mapcount:0 mapping:8801d9552600 index:0x0  
compound_mapcount: 0

flags: 

KASAN: use-after-free Read in cma_cancel_operation

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +)
Merge branch 'ras-core-for-linus' of  
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=6956235342b7317ec564


So far this crash happened 4 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6621340819783680
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6075521074987008
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6447569127342080
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6801295859785128502

compiler: gcc (GCC) 7.1.1 20170620

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6956235342b7317ec...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

==
BUG: KASAN: use-after-free in __list_del_entry_valid+0x144/0x150  
lib/list_debug.c:54

Read of size 8 at addr 8801d8dc7d20 by task syzkaller468166/4496

CPU: 0 PID: 4496 Comm: syzkaller468166 Not tainted 4.16.0+ #376
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+0x1a7/0x27d lib/dump_stack.c:53
 print_address_description+0x73/0x250 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x23c/0x360 mm/kasan/report.c:412
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
 __list_del_entry_valid+0x144/0x150 lib/list_debug.c:54
 __list_del_entry include/linux/list.h:117 [inline]
 list_del include/linux/list.h:125 [inline]
 cma_cancel_listens drivers/infiniband/core/cma.c:1569 [inline]
 cma_cancel_operation+0x455/0xd60 drivers/infiniband/core/cma.c:1597
 rdma_destroy_id+0xff/0xda0 drivers/infiniband/core/cma.c:1661
 ucma_close+0x100/0x2f0 drivers/infiniband/core/ucma.c:1735
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:243
 task_work_run+0x1ab/0x280 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x1986/0x2700 kernel/exit.c:865
 do_group_exit+0x149/0x400 kernel/exit.c:968
 get_signal+0x74c/0x16e0 kernel/signal.c:2469
 do_signal+0x90/0x1e90 arch/x86/kernel/signal.c:809
 exit_to_usermode_loop+0x258/0x2f0 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
 do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x446b09
RSP: 002b:7f2b89150da8 EFLAGS: 0246 ORIG_RAX: 00ca
RAX: fe00 RBX: 006e29fc RCX: 00446b09
RDX:  RSI:  RDI: 006e29fc
RBP: 006e29f8 R08:  R09: 
R10:  R11: 0246 R12: 006d635f616d6472
R13: 2f646e6162696e69 R14: 666e692f7665642f R15: 0005

Allocated by task 4493:
 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:552
 kmem_cache_alloc_trace+0x136/0x740 mm/slab.c:3608
 kmalloc include/linux/slab.h:512 [inline]
 kzalloc include/linux/slab.h:701 [inline]
 rdma_create_id+0xd0/0x640 drivers/infiniband/core/cma.c:787
 ucma_create_id+0x35f/0x920 drivers/infiniband/core/ucma.c:480
 ucma_write+0x2d6/0x3d0 drivers/infiniband/core/ucma.c:1656
 __vfs_write+0xef/0x970 fs/read_write.c:480
 vfs_write+0x189/0x510 fs/read_write.c:544
 SYSC_write fs/read_write.c:589 [inline]
 SyS_write+0xef/0x220 fs/read_write.c:581
 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

Freed by task 4496:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459 [inline]
 __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
 __cache_free mm/slab.c:3486 [inline]
 kfree+0xd9/0x260 mm/slab.c:3801
 rdma_destroy_id+0x821/0xda0 drivers/infiniband/core/cma.c:1691
 ucma_close+0x100/0x2f0 drivers/infiniband/core/ucma.c:1735
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:243
 task_work_run+0x1ab/0x280 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x1986/0x2700 kernel/exit.c:865
 do_group_exit+0x149/0x400 kernel/exit.c:968
 get_signal+0x74c/0x16e0 kernel/signal.c:2469
 do_signal+0x90/0x1e90 arch/x86/kernel/signal.c:809
 exit_to_usermode_loop+0x258/0x2f0 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
 do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

The buggy 

KASAN: use-after-free Read in cma_cancel_operation

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +)
Merge branch 'ras-core-for-linus' of  
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=6956235342b7317ec564


So far this crash happened 4 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6621340819783680
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6075521074987008
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6447569127342080
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6801295859785128502

compiler: gcc (GCC) 7.1.1 20170620

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6956235342b7317ec...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

==
BUG: KASAN: use-after-free in __list_del_entry_valid+0x144/0x150  
lib/list_debug.c:54

Read of size 8 at addr 8801d8dc7d20 by task syzkaller468166/4496

CPU: 0 PID: 4496 Comm: syzkaller468166 Not tainted 4.16.0+ #376
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+0x1a7/0x27d lib/dump_stack.c:53
 print_address_description+0x73/0x250 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x23c/0x360 mm/kasan/report.c:412
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
 __list_del_entry_valid+0x144/0x150 lib/list_debug.c:54
 __list_del_entry include/linux/list.h:117 [inline]
 list_del include/linux/list.h:125 [inline]
 cma_cancel_listens drivers/infiniband/core/cma.c:1569 [inline]
 cma_cancel_operation+0x455/0xd60 drivers/infiniband/core/cma.c:1597
 rdma_destroy_id+0xff/0xda0 drivers/infiniband/core/cma.c:1661
 ucma_close+0x100/0x2f0 drivers/infiniband/core/ucma.c:1735
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:243
 task_work_run+0x1ab/0x280 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x1986/0x2700 kernel/exit.c:865
 do_group_exit+0x149/0x400 kernel/exit.c:968
 get_signal+0x74c/0x16e0 kernel/signal.c:2469
 do_signal+0x90/0x1e90 arch/x86/kernel/signal.c:809
 exit_to_usermode_loop+0x258/0x2f0 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
 do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x446b09
RSP: 002b:7f2b89150da8 EFLAGS: 0246 ORIG_RAX: 00ca
RAX: fe00 RBX: 006e29fc RCX: 00446b09
RDX:  RSI:  RDI: 006e29fc
RBP: 006e29f8 R08:  R09: 
R10:  R11: 0246 R12: 006d635f616d6472
R13: 2f646e6162696e69 R14: 666e692f7665642f R15: 0005

Allocated by task 4493:
 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:552
 kmem_cache_alloc_trace+0x136/0x740 mm/slab.c:3608
 kmalloc include/linux/slab.h:512 [inline]
 kzalloc include/linux/slab.h:701 [inline]
 rdma_create_id+0xd0/0x640 drivers/infiniband/core/cma.c:787
 ucma_create_id+0x35f/0x920 drivers/infiniband/core/ucma.c:480
 ucma_write+0x2d6/0x3d0 drivers/infiniband/core/ucma.c:1656
 __vfs_write+0xef/0x970 fs/read_write.c:480
 vfs_write+0x189/0x510 fs/read_write.c:544
 SYSC_write fs/read_write.c:589 [inline]
 SyS_write+0xef/0x220 fs/read_write.c:581
 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

Freed by task 4496:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459 [inline]
 __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
 __cache_free mm/slab.c:3486 [inline]
 kfree+0xd9/0x260 mm/slab.c:3801
 rdma_destroy_id+0x821/0xda0 drivers/infiniband/core/cma.c:1691
 ucma_close+0x100/0x2f0 drivers/infiniband/core/ucma.c:1735
 __fput+0x327/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:243
 task_work_run+0x1ab/0x280 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x1986/0x2700 kernel/exit.c:865
 do_group_exit+0x149/0x400 kernel/exit.c:968
 get_signal+0x74c/0x16e0 kernel/signal.c:2469
 do_signal+0x90/0x1e90 arch/x86/kernel/signal.c:809
 exit_to_usermode_loop+0x258/0x2f0 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
 do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292
 entry_SYSCALL_64_after_hwframe+0x42/0xb7

The buggy 

Re: [GIT PULL] arch: remove obsolete architecture ports

[Palmer Dabbelt]

On Mon, 02 Apr 2018 00:17:30 PDT (-0700), Arnd Bergmann wrote:

- openrisc, risc-v and nds32 are still in the process of finishing their
  support or getting it added to mainline gcc in the first place.
  They all have patched gcc-7.3 ports that work to some degree, but
  complete upstream support won't happen before gcc-8.1. Csky posted
  their first kernel patch set last week, their situation will be similar.


FWIW, RISC-V landed in GCC 7.  The 7.3.0 release (and binutils-2.30) is the 
first one we recommend for kernel development as there have been a handful of 
bug fixes, but there's nothing major.  SiFive ships GCC versions with a few 
extra patches applied, and while I still recommend people use these they should 
all be performance improvements at this point.  With compilers you never know 
if a performance improvement is hiding a bug, but what's tagged as gcc-7.3.0 
passes the test suite.


Our 32-bit glibc port isn't upstream yet, but our 32-bit kernel is a bit of a 
mess so that's not the blocking issue in rv32-land right now :).

Re: [GIT PULL] arch: remove obsolete architecture ports

[Palmer Dabbelt]

On Mon, 02 Apr 2018 00:17:30 PDT (-0700), Arnd Bergmann wrote:

- openrisc, risc-v and nds32 are still in the process of finishing their
  support or getting it added to mainline gcc in the first place.
  They all have patched gcc-7.3 ports that work to some degree, but
  complete upstream support won't happen before gcc-8.1. Csky posted
  their first kernel patch set last week, their situation will be similar.


FWIW, RISC-V landed in GCC 7.  The 7.3.0 release (and binutils-2.30) is the 
first one we recommend for kernel development as there have been a handful of 
bug fixes, but there's nothing major.  SiFive ships GCC versions with a few 
extra patches applied, and while I still recommend people use these they should 
all be performance improvements at this point.  With compilers you never know 
if a performance improvement is hiding a bug, but what's tagged as gcc-7.3.0 
passes the test suite.


Our 32-bit glibc port isn't upstream yet, but our 32-bit kernel is a bit of a 
mess so that's not the blocking issue in rv32-land right now :).

Re: [PATCH] f2fs: make assignment of t->dentry_bitmap more readable

[Chao Yu]

On 2018/4/2 20:22, Yunlong Song wrote:
> In make_dentry_ptr_block, it is confused with "&" for t->dentry_bitmap
> but without "&" for t->dentry, so delete "&" to make code more readable.
> 
> Signed-off-by: Yunlong Song 

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH] f2fs: make assignment of t->dentry_bitmap more readable

[Chao Yu]

On 2018/4/2 20:22, Yunlong Song wrote:
> In make_dentry_ptr_block, it is confused with "&" for t->dentry_bitmap
> but without "&" for t->dentry, so delete "&" to make code more readable.
> 
> Signed-off-by: Yunlong Song 

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

[Sricharan R]

Hi Viresh,

On 4/2/2018 8:37 PM, Sricharan R wrote:
> Hi Viresh,
> 
> On 4/2/2018 3:00 PM, Viresh Kumar wrote:
>> +Sricharan,
>>
>> On 30-03-18, 00:26, Ilia Lin wrote:
>>> In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
>>> that have KRYO processors, the CPU ferequencies subset and voltage value
>>> of each OPP varies based on the silicon variant in use.
>>> Qualcomm Technologies, Inc. Process Voltage Scaling Tables
>>> defines the voltage and frequency value based on the msm-id in SMEM
>>> and speedbin blown in the efuse combination.
>>> The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
>>> to provide the OPP framework with required information.
>>> This is used to determine the voltage and frequency value for each OPP of
>>> operating-points-v2 table when it is parsed by the OPP framework.
>>>
>>> This change adds documentation.
>>>
>>> Change-Id: I1953f652a48249fb516d175f0e965a9510cd4209
>>> Signed-off-by: Ilia Lin 
>>> ---
>>>  .../devicetree/bindings/cpufreq/kryo-cpufreq.txt   | 693 
>>> +
>>>  1 file changed, 693 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/cpufreq/kryo-cpufreq.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/cpufreq/kryo-cpufreq.txt 
>>> b/Documentation/devicetree/bindings/cpufreq/kryo-cpufreq.txt
>>
>> This should really go in opp directory.
>>
>>> new file mode 100644
>>> index 000..20cef9d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/cpufreq/kryo-cpufreq.txt
>>> @@ -0,0 +1,693 @@
>>> +Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
>>> +===
>>> +
>>> +In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
>>> +that have KRYO processors, the CPU ferequencies subset and voltage value
>>> +of each OPP varies based on the silicon variant in use.
>>> +Qualcomm Technologies, Inc. Process Voltage Scaling Tables
>>> +defines the voltage and frequency value based on the msm-id in SMEM
>>> +and speedbin blown in the efuse combination.
>>> +The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
>>> +to provide the OPP framework with required information (existing HW 
>>> bitmap).
>>> +This is used to determine the voltage and frequency value for each OPP of
>>> +operating-points-v2 table when it is parsed by the OPP framework.
>>> +
>>> +Required properties:
>>> +
>>> +In 'cpus' nodes:
>>> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
>>> +
>>> +In 'operating-points-v2' table:
>>> +- compatible: Should be
>>> +   - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
>>> +- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
>>> +   efuse registers that has information about the
>>> +   speedbin that is used to select the right frequency/voltage
>>> +   value pair.
>>> +   Please refer the for nvmem-cells
>>> +   bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
>>> +   and also examples below.
>>
>> Sricharan is also working on adding these, just make sure you guys do the 
>> same
>> thing..
>>
 Right, i was adding a similar one for krait cores [1]. There is code common in 
the
 init sequence across both (little). Do you suggest to make them common ?

Regards,
 Sricharan

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

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

[Sricharan R]

Hi Viresh,

On 4/2/2018 8:37 PM, Sricharan R wrote:
> Hi Viresh,
> 
> On 4/2/2018 3:00 PM, Viresh Kumar wrote:
>> +Sricharan,
>>
>> On 30-03-18, 00:26, Ilia Lin wrote:
>>> In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
>>> that have KRYO processors, the CPU ferequencies subset and voltage value
>>> of each OPP varies based on the silicon variant in use.
>>> Qualcomm Technologies, Inc. Process Voltage Scaling Tables
>>> defines the voltage and frequency value based on the msm-id in SMEM
>>> and speedbin blown in the efuse combination.
>>> The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
>>> to provide the OPP framework with required information.
>>> This is used to determine the voltage and frequency value for each OPP of
>>> operating-points-v2 table when it is parsed by the OPP framework.
>>>
>>> This change adds documentation.
>>>
>>> Change-Id: I1953f652a48249fb516d175f0e965a9510cd4209
>>> Signed-off-by: Ilia Lin 
>>> ---
>>>  .../devicetree/bindings/cpufreq/kryo-cpufreq.txt   | 693 
>>> +
>>>  1 file changed, 693 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/cpufreq/kryo-cpufreq.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/cpufreq/kryo-cpufreq.txt 
>>> b/Documentation/devicetree/bindings/cpufreq/kryo-cpufreq.txt
>>
>> This should really go in opp directory.
>>
>>> new file mode 100644
>>> index 000..20cef9d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/cpufreq/kryo-cpufreq.txt
>>> @@ -0,0 +1,693 @@
>>> +Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
>>> +===
>>> +
>>> +In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
>>> +that have KRYO processors, the CPU ferequencies subset and voltage value
>>> +of each OPP varies based on the silicon variant in use.
>>> +Qualcomm Technologies, Inc. Process Voltage Scaling Tables
>>> +defines the voltage and frequency value based on the msm-id in SMEM
>>> +and speedbin blown in the efuse combination.
>>> +The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
>>> +to provide the OPP framework with required information (existing HW 
>>> bitmap).
>>> +This is used to determine the voltage and frequency value for each OPP of
>>> +operating-points-v2 table when it is parsed by the OPP framework.
>>> +
>>> +Required properties:
>>> +
>>> +In 'cpus' nodes:
>>> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
>>> +
>>> +In 'operating-points-v2' table:
>>> +- compatible: Should be
>>> +   - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
>>> +- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
>>> +   efuse registers that has information about the
>>> +   speedbin that is used to select the right frequency/voltage
>>> +   value pair.
>>> +   Please refer the for nvmem-cells
>>> +   bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
>>> +   and also examples below.
>>
>> Sricharan is also working on adding these, just make sure you guys do the 
>> same
>> thing..
>>
 Right, i was adding a similar one for krait cores [1]. There is code common in 
the
 init sequence across both (little). Do you suggest to make them common ?

Regards,
 Sricharan

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

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] f2fs: truncate preallocated blocks in error case

[Chao Yu]

On 2018/3/31 9:57, Jaegeuk Kim wrote:
> If write is failed, we must deallocate the blocks that we couldn't write.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH] f2fs: truncate preallocated blocks in error case

[Chao Yu]

On 2018/3/31 9:57, Jaegeuk Kim wrote:
> If write is failed, we must deallocate the blocks that we couldn't write.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Thanks,

[PATCH] usb: serial: option: add HP LT4220 support

[Edward Chang]

This patch adds support for HP LT4220. 

Signed-off-by: Edward Chang 

---
 drivers/usb/serial/option.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 2d8d915..a8988d5 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -548,6 +548,10 @@ static int  option_probe(struct usb_serial *serial,
 #define WETELECOM_PRODUCT_6802 0x6802
 #define WETELECOM_PRODUCT_WMD300   0x6803
 
+/* HP products */
+#define HP_VENDOR_ID   0x03f0
+#define HP_PRODUCT_LT4220  0x0857
+
 struct option_blacklist_info {
/* bitmask of interface numbers blacklisted for send_setup */
const unsigned long sendsetup;
@@ -2066,6 +2070,8 @@ struct option_blacklist_info {
{ USB_DEVICE_AND_INTERFACE_INFO(WETELECOM_VENDOR_ID, 
WETELECOM_PRODUCT_6802, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(WETELECOM_VENDOR_ID, 
WETELECOM_PRODUCT_WMD300, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x421d, 0xff, 0xff, 0xff) }, /* 
HP lt2523 (Novatel E371) */
+   { USB_DEVICE_INTERFACE_CLASS(HP_VENDOR_ID, HP_PRODUCT_LT4220, 
USB_CLASS_VENDOR_SPEC),
+ .driver_info = (kernel_ulong_t)_le920a4_blacklist_1 },
{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);
-- 
1.9.1

[PATCH] usb: serial: option: add HP LT4220 support

[Edward Chang]

This patch adds support for HP LT4220. 

Signed-off-by: Edward Chang 

---
 drivers/usb/serial/option.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 2d8d915..a8988d5 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -548,6 +548,10 @@ static int  option_probe(struct usb_serial *serial,
 #define WETELECOM_PRODUCT_6802 0x6802
 #define WETELECOM_PRODUCT_WMD300   0x6803
 
+/* HP products */
+#define HP_VENDOR_ID   0x03f0
+#define HP_PRODUCT_LT4220  0x0857
+
 struct option_blacklist_info {
/* bitmask of interface numbers blacklisted for send_setup */
const unsigned long sendsetup;
@@ -2066,6 +2070,8 @@ struct option_blacklist_info {
{ USB_DEVICE_AND_INTERFACE_INFO(WETELECOM_VENDOR_ID, 
WETELECOM_PRODUCT_6802, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(WETELECOM_VENDOR_ID, 
WETELECOM_PRODUCT_WMD300, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x421d, 0xff, 0xff, 0xff) }, /* 
HP lt2523 (Novatel E371) */
+   { USB_DEVICE_INTERFACE_CLASS(HP_VENDOR_ID, HP_PRODUCT_LT4220, 
USB_CLASS_VENDOR_SPEC),
+ .driver_info = (kernel_ulong_t)_le920a4_blacklist_1 },
{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);
-- 
1.9.1

Re: [PATCH 0/2] rhashtable_walk fixes

[David Miller]

From: NeilBrown 
Date: Tue, 03 Apr 2018 12:23:40 +1000

>  I'm sorry if I've caused some confusion, but I didn't think that I was
>  submitting patches to you and know nothing about your two trees.
>  I was submitting patches to Thomas and Herbert, the registered
>  maintainers of rhashtable.  I assumed they would review, respond, and
>  take responsibility for getting them upstream, if that's what they
>  decided, based on whatever arrangements they have in place.
> 
>  If it is appropriate I can resend all of my patches that receive an
>  Ack as a coherent series, and send this to you nominating a particular
>  tree, but I'm unlikely to do that unless asked and told which tree to
>  nominate.

Herbert and Thomas generally review rhashtable patches, but rhashtable
itself is generally maintained in the networking tree(s).  So once
they review and ACK it, I would apply it.

Re: [PATCH 0/2] rhashtable_walk fixes

[David Miller]

From: NeilBrown 
Date: Tue, 03 Apr 2018 12:23:40 +1000

>  I'm sorry if I've caused some confusion, but I didn't think that I was
>  submitting patches to you and know nothing about your two trees.
>  I was submitting patches to Thomas and Herbert, the registered
>  maintainers of rhashtable.  I assumed they would review, respond, and
>  take responsibility for getting them upstream, if that's what they
>  decided, based on whatever arrangements they have in place.
> 
>  If it is appropriate I can resend all of my patches that receive an
>  Ack as a coherent series, and send this to you nominating a particular
>  tree, but I'm unlikely to do that unless asked and told which tree to
>  nominate.

Herbert and Thomas generally review rhashtable patches, but rhashtable
itself is generally maintained in the networking tree(s).  So once
they review and ACK it, I would apply it.

linux-next: manual merge of the pci tree with Linus' tree

[Stephen Rothwell]

Hi Bjorn,

Today's linux-next merge of the pci tree got a conflict in:

  drivers/pci/quirks.c

between commit:

  7dcf688d4c78 ("PCI/cxgb4: Extend T3 PCI quirk to T4+ devices")

from Linus' tree and commit:

  996058573b22 ("PCI/VPD: Move VPD quirks to vpd.c")

from the pci tree.

I fixed it up (I removed the section from this file and added the
following merge fix patch) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell 
Date: Tue, 3 Apr 2018 12:17:20 +1000
Subject: [PATCH] PCI/cxgb4: merge fix up for move of quirk_chelsio_extend_vpd()

Signed-off-by: Stephen Rothwell 
---
 drivers/pci/vpd.c | 37 +++--
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index 00b8b5d37056..8617565ba561 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -617,19 +617,28 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
 
 static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
 {
-   pci_set_vpd_size(dev, 8192);
+   int chip = (dev->device & 0xf000) >> 12;
+   int func = (dev->device & 0x0f00) >>  8;
+   int prod = (dev->device & 0x00ff) >>  0;
+
+   /*
+* If this is a T3-based adapter, there's a 1KB VPD area at offset
+* 0xc00 which contains the preferred VPD values.  If this is a T4 or
+* later based adapter, the special VPD is at offset 0x400 for the
+* Physical Functions (the SR-IOV Virtual Functions have no VPD
+* Capabilities).  The PCI VPD Access core routines will normally
+* compute the size of the VPD by parsing the VPD Data Structure at
+* offset 0x000.  This will result in silent failures when attempting
+* to accesses these other VPD areas which are beyond those computed
+* limits.
+*/
+   if (chip == 0x0 && prod >= 0x20)
+   pci_set_vpd_size(dev, 8192);
+   else if (chip >= 0x4 && func < 0x8)
+   pci_set_vpd_size(dev, 2048);
 }
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
+   quirk_chelsio_extend_vpd);
+
 #endif
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell


pgpMVyB9uOALD.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the pci tree with Linus' tree

[Stephen Rothwell]

Hi Bjorn,

Today's linux-next merge of the pci tree got a conflict in:

  drivers/pci/quirks.c

between commit:

  7dcf688d4c78 ("PCI/cxgb4: Extend T3 PCI quirk to T4+ devices")

from Linus' tree and commit:

  996058573b22 ("PCI/VPD: Move VPD quirks to vpd.c")

from the pci tree.

I fixed it up (I removed the section from this file and added the
following merge fix patch) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell 
Date: Tue, 3 Apr 2018 12:17:20 +1000
Subject: [PATCH] PCI/cxgb4: merge fix up for move of quirk_chelsio_extend_vpd()

Signed-off-by: Stephen Rothwell 
---
 drivers/pci/vpd.c | 37 +++--
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index 00b8b5d37056..8617565ba561 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -617,19 +617,28 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
 
 static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
 {
-   pci_set_vpd_size(dev, 8192);
+   int chip = (dev->device & 0xf000) >> 12;
+   int func = (dev->device & 0x0f00) >>  8;
+   int prod = (dev->device & 0x00ff) >>  0;
+
+   /*
+* If this is a T3-based adapter, there's a 1KB VPD area at offset
+* 0xc00 which contains the preferred VPD values.  If this is a T4 or
+* later based adapter, the special VPD is at offset 0x400 for the
+* Physical Functions (the SR-IOV Virtual Functions have no VPD
+* Capabilities).  The PCI VPD Access core routines will normally
+* compute the size of the VPD by parsing the VPD Data Structure at
+* offset 0x000.  This will result in silent failures when attempting
+* to accesses these other VPD areas which are beyond those computed
+* limits.
+*/
+   if (chip == 0x0 && prod >= 0x20)
+   pci_set_vpd_size(dev, 8192);
+   else if (chip >= 0x4 && func < 0x8)
+   pci_set_vpd_size(dev, 2048);
 }
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
+   quirk_chelsio_extend_vpd);
+
 #endif
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell


pgpMVyB9uOALD.pgp
Description: OpenPGP digital signature

Re: [GIT PULL] f2fs update for 4.16-rc1

[Stephen Rothwell]

Hi all,

Ping?

On Wed, 14 Mar 2018 10:17:04 +1100 Stephen Rothwell  
wrote:
>
> On Thu, 1 Feb 2018 09:25:51 +1100 Stephen Rothwell  
> wrote:
> >
> > On Tue, 30 Jan 2018 16:25:35 -0800 Jaegeuk Kim  wrote:  
> > >
> > > On 01/31, Stephen Rothwell wrote:
> > > > 
> > > > On Tue, 30 Jan 2018 14:32:20 -0800 Jaegeuk Kim  
> > > > wrote:  
> > > > >
> > > > > Could you please consider the below pull request?
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > The following changes since commit 
> > > > > ace52288edf0cb5e7a52b681f057f86224c49c27:
> > > > > 
> > > > >   Merge tag 'for-linus-20171218' of git://git.infradead.org/linux-mtd 
> > > > > (2017-12-18 16:18:01 -0800)
> > > > > 
> > > > > are available in the Git repository at:
> > > > > 
> > > > >   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git 
> > > > > tags/f2fs-for-4.16-rc1
> > > > > 
> > > > > for you to fetch changes up to 
> > > > > 1c1d35df71104c76a4a2e25862926f22c334c9d6:
> > > > > 
> > > > >   f2fs: support inode creation time (2018-01-25 14:10:39 -0800)  
> > > > 
> > > > This has an interesting conflict with the btrfs tree:
> > > > 
> > > > ---
> > > > After merging the f2fs tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > /home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_fill_super':
> > > > /home/sfr/next/next/fs/f2fs/super.c:2563:18: error: 'SB_I_CGROUPWB' 
> > > > undeclared (first use in this function); did you mean 'S_CGROUPWB'?
> > > >   sb->s_iflags |= SB_I_CGROUPWB;
> > > >   ^
> > > >   S_CGROUPWB
> > > > 
> > > > Caused by commit
> > > > 
> > > >   578c647879f7 ("f2fs: implement cgroup writeback support")
> > > > 
> > > > interacting with commit
> > > > 
> > > >   34934189a3dd ("cgroup, writeback: replace SB_I_CGROUPWB with 
> > > > per-inode S_CGROUPWB"
> > > > 
> > > > from the btrfs tree.
> > > > 
> > > > I have reverted the f2fs tree commit for today, but a better resolution
> > > > would be appreciated.
> > > > ---
> > > > 
> > > > I have seen no response to the above email and have been reverting that
> > > > commit since Jan 18.  
> > > 
> > > I think this can be addressed by:
> > > 
> > > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> > > index 89c838bfb067..c743b73976d0 100644
> > > --- a/fs/f2fs/inode.c
> > > +++ b/fs/f2fs/inode.c
> > > @@ -48,9 +48,10 @@ void f2fs_set_inode_flags(struct inode *inode)
> > > new_fl |= S_DIRSYNC;
> > > if (f2fs_encrypted_inode(inode))
> > > new_fl |= S_ENCRYPTED;
> > > +   new_fl |= S_CGROUPWB;
> > > inode_set_flags(inode, new_fl,
> > > S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|
> > > -   S_ENCRYPTED);
> > > +   S_ENCRYPTED|S_CGROUPWB);
> > >  }
> > > 
> > >  static void __get_inode_rdev(struct inode *inode, struct f2fs_inode *ri)
> > > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > > index 8173ae688814..ebcd58476fc7 100644
> > > --- a/fs/f2fs/super.c
> > > +++ b/fs/f2fs/super.c
> > > @@ -2560,7 +2560,6 @@ static int f2fs_fill_super(struct super_block *sb, 
> > > void *data, int silent)
> > > sb->s_flags = (sb->s_flags & ~SB_POSIXACL) |
> > > (test_opt(sbi, POSIX_ACL) ? SB_POSIXACL : 0);
> > > memcpy(>s_uuid, raw_super->uuid, sizeof(raw_super->uuid));
> > > -   sb->s_iflags |= SB_I_CGROUPWB;
> > > 
> > > /* init f2fs-specific super block info */
> > > sbi->valid_super_block = valid_super_block;
> > > 
> > 
> > I have applied that (by hand) as a merge fix patch for the merge of teh
> > btrfs tree for today.  Thanks for the resolution.  
> 
> I am still applying this to the merge of the btrfs tree every day ...
> 
> Commit
>   578c647879f7 ("f2fs: implement cgroup writeback support")
> was merged into Linus' tree on Jan 31.
> 
> Here is the actual merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Thu, 1 Feb 2018 09:21:06 +1100
> Subject: [PATCH] f2fs: fixup for cgroup/writeback change
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/f2fs/inode.c | 3 ++-
>  fs/f2fs/super.c | 1 -
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index 205add3d0f3a..f34652c4288f 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -48,9 +48,10 @@ void f2fs_set_inode_flags(struct inode *inode)
>   new_fl |= S_DIRSYNC;
>   if (f2fs_encrypted_inode(inode))
>   new_fl |= S_ENCRYPTED;
> + new_fl |= S_CGROUPWB;
>   inode_set_flags(inode, new_fl,
>   S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|
> - 

Re: [GIT PULL] f2fs update for 4.16-rc1

[Stephen Rothwell]

Hi all,

Ping?

On Wed, 14 Mar 2018 10:17:04 +1100 Stephen Rothwell  
wrote:
>
> On Thu, 1 Feb 2018 09:25:51 +1100 Stephen Rothwell  
> wrote:
> >
> > On Tue, 30 Jan 2018 16:25:35 -0800 Jaegeuk Kim  wrote:  
> > >
> > > On 01/31, Stephen Rothwell wrote:
> > > > 
> > > > On Tue, 30 Jan 2018 14:32:20 -0800 Jaegeuk Kim  
> > > > wrote:  
> > > > >
> > > > > Could you please consider the below pull request?
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > The following changes since commit 
> > > > > ace52288edf0cb5e7a52b681f057f86224c49c27:
> > > > > 
> > > > >   Merge tag 'for-linus-20171218' of git://git.infradead.org/linux-mtd 
> > > > > (2017-12-18 16:18:01 -0800)
> > > > > 
> > > > > are available in the Git repository at:
> > > > > 
> > > > >   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git 
> > > > > tags/f2fs-for-4.16-rc1
> > > > > 
> > > > > for you to fetch changes up to 
> > > > > 1c1d35df71104c76a4a2e25862926f22c334c9d6:
> > > > > 
> > > > >   f2fs: support inode creation time (2018-01-25 14:10:39 -0800)  
> > > > 
> > > > This has an interesting conflict with the btrfs tree:
> > > > 
> > > > ---
> > > > After merging the f2fs tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > /home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_fill_super':
> > > > /home/sfr/next/next/fs/f2fs/super.c:2563:18: error: 'SB_I_CGROUPWB' 
> > > > undeclared (first use in this function); did you mean 'S_CGROUPWB'?
> > > >   sb->s_iflags |= SB_I_CGROUPWB;
> > > >   ^
> > > >   S_CGROUPWB
> > > > 
> > > > Caused by commit
> > > > 
> > > >   578c647879f7 ("f2fs: implement cgroup writeback support")
> > > > 
> > > > interacting with commit
> > > > 
> > > >   34934189a3dd ("cgroup, writeback: replace SB_I_CGROUPWB with 
> > > > per-inode S_CGROUPWB"
> > > > 
> > > > from the btrfs tree.
> > > > 
> > > > I have reverted the f2fs tree commit for today, but a better resolution
> > > > would be appreciated.
> > > > ---
> > > > 
> > > > I have seen no response to the above email and have been reverting that
> > > > commit since Jan 18.  
> > > 
> > > I think this can be addressed by:
> > > 
> > > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> > > index 89c838bfb067..c743b73976d0 100644
> > > --- a/fs/f2fs/inode.c
> > > +++ b/fs/f2fs/inode.c
> > > @@ -48,9 +48,10 @@ void f2fs_set_inode_flags(struct inode *inode)
> > > new_fl |= S_DIRSYNC;
> > > if (f2fs_encrypted_inode(inode))
> > > new_fl |= S_ENCRYPTED;
> > > +   new_fl |= S_CGROUPWB;
> > > inode_set_flags(inode, new_fl,
> > > S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|
> > > -   S_ENCRYPTED);
> > > +   S_ENCRYPTED|S_CGROUPWB);
> > >  }
> > > 
> > >  static void __get_inode_rdev(struct inode *inode, struct f2fs_inode *ri)
> > > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > > index 8173ae688814..ebcd58476fc7 100644
> > > --- a/fs/f2fs/super.c
> > > +++ b/fs/f2fs/super.c
> > > @@ -2560,7 +2560,6 @@ static int f2fs_fill_super(struct super_block *sb, 
> > > void *data, int silent)
> > > sb->s_flags = (sb->s_flags & ~SB_POSIXACL) |
> > > (test_opt(sbi, POSIX_ACL) ? SB_POSIXACL : 0);
> > > memcpy(>s_uuid, raw_super->uuid, sizeof(raw_super->uuid));
> > > -   sb->s_iflags |= SB_I_CGROUPWB;
> > > 
> > > /* init f2fs-specific super block info */
> > > sbi->valid_super_block = valid_super_block;
> > > 
> > 
> > I have applied that (by hand) as a merge fix patch for the merge of teh
> > btrfs tree for today.  Thanks for the resolution.  
> 
> I am still applying this to the merge of the btrfs tree every day ...
> 
> Commit
>   578c647879f7 ("f2fs: implement cgroup writeback support")
> was merged into Linus' tree on Jan 31.
> 
> Here is the actual merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Thu, 1 Feb 2018 09:21:06 +1100
> Subject: [PATCH] f2fs: fixup for cgroup/writeback change
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/f2fs/inode.c | 3 ++-
>  fs/f2fs/super.c | 1 -
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index 205add3d0f3a..f34652c4288f 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -48,9 +48,10 @@ void f2fs_set_inode_flags(struct inode *inode)
>   new_fl |= S_DIRSYNC;
>   if (f2fs_encrypted_inode(inode))
>   new_fl |= S_ENCRYPTED;
> + new_fl |= S_CGROUPWB;
>   inode_set_flags(inode, new_fl,
>   S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|
> - S_ENCRYPTED);
> + S_ENCRYPTED|S_CGROUPWB);
>  }
>  
>  static void __get_inode_rdev(struct inode *inode, struct 

Re: [PATCH v5 3/3] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2

[Sinan Kaya]

On 3/22/2018 12:26 PM, Sinan Kaya wrote:
> @@ -860,7 +860,7 @@ static void doorbell_cq(struct qedr_cq *cq, u32 cons, u8 
> flags)
>   wmb();
>   cq->db.data.agg_flags = flags;
>   cq->db.data.value = cpu_to_le32(cons);
> - writeq(cq->db.raw, cq->db_addr);
> + writeq_relaxed(cq->db.raw, cq->db_addr);

Given the direction to get rid of wmb() in front of writeX() functions, I have 
been
reviewing this code. Under normal circumstances, I can get rid of all wmb() as 
follows.

However, I started having my doubts now. Are these wmb() used as a SMP barrier 
too?
I can't find any smp_Xmb() in drivers/infiniband/hw/qedr directory.

static void doorbell_cq(struct qedr_cq *cq, u32 cons, u8 flags)
 {
-   /* Flush data before signalling doorbell */
-   wmb();
cq->db.data.agg_flags = flags;
cq->db.data.value = cpu_to_le32(cons);
writeq(cq->db.raw, cq->db_addr);
@@ -1870,8 +1868,7 @@ static int qedr_update_qp_state(struct qedr_dev *dev,
 */

if (rdma_protocol_roce(>ibdev, 1)) {
-   wmb();
-   writel_relaxed(qp->rq.db_data.raw, qp->rq.db);
+   writel(qp->rq.db_data.raw, qp->rq.db);
/* Make sure write takes effect */
mmiowb();
}
@@ -3275,8 +3272,7 @@ int qedr_post_send(struct ib_qp *ibqp, struct ib_send_wr 
*wr,
 * unchanged). For performance reasons we avoid checking for this
 * redundant doorbell.
 */
-   wmb();
-   writel_relaxed(qp->sq.db_data.raw, qp->sq.db);
+   writel(qp->sq.db_data.raw, qp->sq.db);

/* Make sure write sticks */
mmiowb();
@@ -3362,9 +3358,6 @@ int qedr_post_recv(struct ib_qp *ibqp, struct ib_recv_wr 
*wr,

qedr_inc_sw_prod(>rq);

-   /* Flush all the writes before signalling doorbell */
-   wmb();





-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH v5 3/3] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2

[Sinan Kaya]

On 3/22/2018 12:26 PM, Sinan Kaya wrote:
> @@ -860,7 +860,7 @@ static void doorbell_cq(struct qedr_cq *cq, u32 cons, u8 
> flags)
>   wmb();
>   cq->db.data.agg_flags = flags;
>   cq->db.data.value = cpu_to_le32(cons);
> - writeq(cq->db.raw, cq->db_addr);
> + writeq_relaxed(cq->db.raw, cq->db_addr);

Given the direction to get rid of wmb() in front of writeX() functions, I have 
been
reviewing this code. Under normal circumstances, I can get rid of all wmb() as 
follows.

However, I started having my doubts now. Are these wmb() used as a SMP barrier 
too?
I can't find any smp_Xmb() in drivers/infiniband/hw/qedr directory.

static void doorbell_cq(struct qedr_cq *cq, u32 cons, u8 flags)
 {
-   /* Flush data before signalling doorbell */
-   wmb();
cq->db.data.agg_flags = flags;
cq->db.data.value = cpu_to_le32(cons);
writeq(cq->db.raw, cq->db_addr);
@@ -1870,8 +1868,7 @@ static int qedr_update_qp_state(struct qedr_dev *dev,
 */

if (rdma_protocol_roce(>ibdev, 1)) {
-   wmb();
-   writel_relaxed(qp->rq.db_data.raw, qp->rq.db);
+   writel(qp->rq.db_data.raw, qp->rq.db);
/* Make sure write takes effect */
mmiowb();
}
@@ -3275,8 +3272,7 @@ int qedr_post_send(struct ib_qp *ibqp, struct ib_send_wr 
*wr,
 * unchanged). For performance reasons we avoid checking for this
 * redundant doorbell.
 */
-   wmb();
-   writel_relaxed(qp->sq.db_data.raw, qp->sq.db);
+   writel(qp->sq.db_data.raw, qp->sq.db);

/* Make sure write sticks */
mmiowb();
@@ -3362,9 +3358,6 @@ int qedr_post_recv(struct ib_qp *ibqp, struct ib_recv_wr 
*wr,

qedr_inc_sw_prod(>rq);

-   /* Flush all the writes before signalling doorbell */
-   wmb();





-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

[Chao Yu]

On 2018/3/31 0:30, Jaegeuk Kim wrote:
> Change log from v1:
>  - add more description
> 
> This fixes xfstests/generic/392.
> 
> The failure was caused by different times between 1) one marked in the last
> fsync(2) call and 2) the other given by roll-forward recovery after power-cut.
> The reason was that we skipped updating inode block at 1), since its i_size
> was recoverable along with 4KB-aligned data writes, which was fixed by:
>   "f2fs: fix a wrong condition in f2fs_skip_inode_update"
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h  | 15 +++
>  fs/f2fs/inode.c |  4 
>  2 files changed, 19 insertions(+)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 000f93f6767e..675c39d85111 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -664,6 +664,7 @@ struct f2fs_inode_info {
>   kprojid_t i_projid; /* id for project quota */
>   int i_inline_xattr_size;/* inline xattr size */
>   struct timespec i_crtime;   /* inode creation time */
> + struct timespec i_disk_time[4]; /* inode disk times */
>  };
>  
>  static inline void get_extent_info(struct extent_info *ext,
> @@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, int 
> type)
>   f2fs_mark_inode_dirty_sync(inode, true);
>  }
>  
> +static inline bool time_equal(struct timespec a, struct timespec b)
> +{
> + return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
> +}

We can use existing timespec_equal in  instead of defining a
duplicated one?

> +
>  static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
>  {
>   bool ret;
> @@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct inode 
> *inode, int dsync)
>   i_size_read(inode) & ~PAGE_MASK)
>   return false;
>  
> + if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
> + return false;
> +
>   down_read(_I(inode)->i_sem);
>   ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
>   up_read(_I(inode)->i_sem);
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index 401f09ccce7e..70aba580f4b0 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -444,6 +444,10 @@ void update_inode(struct inode *inode, struct page 
> *node_page)
>   if (inode->i_nlink == 0)
>   clear_inline_node(node_page);
>  
> + F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
> + F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
> + F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
> + F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;

We need initialize them in do_read_inode?

Thanks,

>  }
>  
>  void update_inode_page(struct inode *inode)
> 

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

[Chao Yu]

On 2018/3/31 0:30, Jaegeuk Kim wrote:
> Change log from v1:
>  - add more description
> 
> This fixes xfstests/generic/392.
> 
> The failure was caused by different times between 1) one marked in the last
> fsync(2) call and 2) the other given by roll-forward recovery after power-cut.
> The reason was that we skipped updating inode block at 1), since its i_size
> was recoverable along with 4KB-aligned data writes, which was fixed by:
>   "f2fs: fix a wrong condition in f2fs_skip_inode_update"
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h  | 15 +++
>  fs/f2fs/inode.c |  4 
>  2 files changed, 19 insertions(+)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 000f93f6767e..675c39d85111 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -664,6 +664,7 @@ struct f2fs_inode_info {
>   kprojid_t i_projid; /* id for project quota */
>   int i_inline_xattr_size;/* inline xattr size */
>   struct timespec i_crtime;   /* inode creation time */
> + struct timespec i_disk_time[4]; /* inode disk times */
>  };
>  
>  static inline void get_extent_info(struct extent_info *ext,
> @@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, int 
> type)
>   f2fs_mark_inode_dirty_sync(inode, true);
>  }
>  
> +static inline bool time_equal(struct timespec a, struct timespec b)
> +{
> + return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
> +}

We can use existing timespec_equal in  instead of defining a
duplicated one?

> +
>  static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
>  {
>   bool ret;
> @@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct inode 
> *inode, int dsync)
>   i_size_read(inode) & ~PAGE_MASK)
>   return false;
>  
> + if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
> + return false;
> +
>   down_read(_I(inode)->i_sem);
>   ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
>   up_read(_I(inode)->i_sem);
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index 401f09ccce7e..70aba580f4b0 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -444,6 +444,10 @@ void update_inode(struct inode *inode, struct page 
> *node_page)
>   if (inode->i_nlink == 0)
>   clear_inline_node(node_page);
>  
> + F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
> + F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
> + F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
> + F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;

We need initialize them in do_read_inode?

Thanks,

>  }
>  
>  void update_inode_page(struct inode *inode)
> 

Re: linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/super.c: In function 'do_thaw_all_callback':
> fs/super.c:942:3: error: implicit declaration of function 
> 'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
> [-Werror=implicit-function-declaration]
>emergency_thaw_bdev(sb);
>^~~
>emergency_remount
> 
> Caused by commit
> 
>   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> 
> I have reverted that commit for today.

I am still doing that revert ...

-- 
Cheers,
Stephen Rothwell


pgpWF3Hbjzbmz.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/super.c: In function 'do_thaw_all_callback':
> fs/super.c:942:3: error: implicit declaration of function 
> 'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
> [-Werror=implicit-function-declaration]
>emergency_thaw_bdev(sb);
>^~~
>emergency_remount
> 
> Caused by commit
> 
>   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> 
> I have reverted that commit for today.

I am still doing that revert ...

-- 
Cheers,
Stephen Rothwell


pgpWF3Hbjzbmz.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/2] rhashtable_walk fixes

[NeilBrown]

On Fri, Mar 30 2018, David Miller wrote:

> From: NeilBrown 
> Date: Thu, 29 Mar 2018 12:19:09 +1100
>
>> These two patches apply on top of my previous "rhashtable: reset iter
>> when rhashtable_walk_start sees new table" patch.
>> 
>> The first fixes a bug that I found in rhltable_insert().
>> 
>> The second is an alternate to my "rhashtable: allow a walk of the hash
>> table without missing object."
>> This version doesn't require an API change and should be reliable for
>> rhltables too (my first version didn't handle these correctly).
>
> Neil, please don't mix and match patches.
>
> Also when you need to change a patch in a series, please post the entire
> new series not just the patch that changes.
>
> Patch #1 in this series is unnecessary.  As Herbert explained this has
> been fixed already.
>
> So please repost freshly the patches that are relevant and you want me
> to consider for inclusion.  Also be explicit and clear about which of
> my two networking trees you are targetting these changes.

Hi Dave,
 I'm sorry if I've caused some confusion, but I didn't think that I was
 submitting patches to you and know nothing about your two trees.
 I was submitting patches to Thomas and Herbert, the registered
 maintainers of rhashtable.  I assumed they would review, respond, and
 take responsibility for getting them upstream, if that's what they
 decided, based on whatever arrangements they have in place.

 If it is appropriate I can resend all of my patches that receive an
 Ack as a coherent series, and send this to you nominating a particular
 tree, but I'm unlikely to do that unless asked and told which tree to
 nominate.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 0/2] rhashtable_walk fixes

[NeilBrown]

On Fri, Mar 30 2018, David Miller wrote:

> From: NeilBrown 
> Date: Thu, 29 Mar 2018 12:19:09 +1100
>
>> These two patches apply on top of my previous "rhashtable: reset iter
>> when rhashtable_walk_start sees new table" patch.
>> 
>> The first fixes a bug that I found in rhltable_insert().
>> 
>> The second is an alternate to my "rhashtable: allow a walk of the hash
>> table without missing object."
>> This version doesn't require an API change and should be reliable for
>> rhltables too (my first version didn't handle these correctly).
>
> Neil, please don't mix and match patches.
>
> Also when you need to change a patch in a series, please post the entire
> new series not just the patch that changes.
>
> Patch #1 in this series is unnecessary.  As Herbert explained this has
> been fixed already.
>
> So please repost freshly the patches that are relevant and you want me
> to consider for inclusion.  Also be explicit and clear about which of
> my two networking trees you are targetting these changes.

Hi Dave,
 I'm sorry if I've caused some confusion, but I didn't think that I was
 submitting patches to you and know nothing about your two trees.
 I was submitting patches to Thomas and Herbert, the registered
 maintainers of rhashtable.  I assumed they would review, respond, and
 take responsibility for getting them upstream, if that's what they
 decided, based on whatever arrangements they have in place.

 If it is appropriate I can resend all of my patches that receive an
 Ack as a coherent series, and send this to you nominating a particular
 tree, but I'm unlikely to do that unless asked and told which tree to
 nominate.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH net] net: dsa: mt7530: Use NULL instead of plain integer

[Sean Wang]

On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote:
> We would be passing 0 instead of NULL as the rsp argument to
> mt7530_fdb_cmd(), fix that.
> 

Acked-by: Sean Wang 

BTW, does the part of the commit message should be updated with "passing
NULL instead of 0"?


> Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 
> switch")
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/dsa/mt7530.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 4e53c5ce23ff..a7f6c0a62fc7 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -917,7 +917,7 @@ mt7530_port_fdb_add(struct dsa_switch *ds, int port,
>  
>   mutex_lock(>reg_mutex);
>   mt7530_fdb_write(priv, vid, port_mask, addr, -1, STATIC_ENT);
> - ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, 0);
> + ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, NULL);
>   mutex_unlock(>reg_mutex);
>  
>   return ret;
> @@ -933,7 +933,7 @@ mt7530_port_fdb_del(struct dsa_switch *ds, int port,
>  
>   mutex_lock(>reg_mutex);
>   mt7530_fdb_write(priv, vid, port_mask, addr, -1, STATIC_EMP);
> - ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, 0);
> + ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, NULL);
>   mutex_unlock(>reg_mutex);
>  
>   return ret;
> @@ -1293,7 +1293,7 @@ mt7530_setup(struct dsa_switch *ds)
>   }
>  
>   /* Flush the FDB table */
> - ret = mt7530_fdb_cmd(priv, MT7530_FDB_FLUSH, 0);
> + ret = mt7530_fdb_cmd(priv, MT7530_FDB_FLUSH, NULL);
>   if (ret < 0)
>   return ret;
>  

Re: [PATCH net] net: dsa: mt7530: Use NULL instead of plain integer

[Sean Wang]

On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote:
> We would be passing 0 instead of NULL as the rsp argument to
> mt7530_fdb_cmd(), fix that.
> 

Acked-by: Sean Wang 

BTW, does the part of the commit message should be updated with "passing
NULL instead of 0"?


> Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 
> switch")
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/dsa/mt7530.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 4e53c5ce23ff..a7f6c0a62fc7 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -917,7 +917,7 @@ mt7530_port_fdb_add(struct dsa_switch *ds, int port,
>  
>   mutex_lock(>reg_mutex);
>   mt7530_fdb_write(priv, vid, port_mask, addr, -1, STATIC_ENT);
> - ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, 0);
> + ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, NULL);
>   mutex_unlock(>reg_mutex);
>  
>   return ret;
> @@ -933,7 +933,7 @@ mt7530_port_fdb_del(struct dsa_switch *ds, int port,
>  
>   mutex_lock(>reg_mutex);
>   mt7530_fdb_write(priv, vid, port_mask, addr, -1, STATIC_EMP);
> - ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, 0);
> + ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, NULL);
>   mutex_unlock(>reg_mutex);
>  
>   return ret;
> @@ -1293,7 +1293,7 @@ mt7530_setup(struct dsa_switch *ds)
>   }
>  
>   /* Flush the FDB table */
> - ret = mt7530_fdb_cmd(priv, MT7530_FDB_FLUSH, 0);
> + ret = mt7530_fdb_cmd(priv, MT7530_FDB_FLUSH, NULL);
>   if (ret < 0)
>   return ret;
>  

linux-next: manual merge of the pci tree with the asm-generic tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the pci tree got a conflict in:

  arch/cris/arch-v32/drivers/pci/bios.c

between commits:

  c690eddc2f3b ("CRIS: Drop support for the CRIS port")
  fd8773f9f544 ("arch: remove frv port")
  739d875dd698 ("mn10300: Remove the architecture")

from the asm-generic tree and commit:

  31cbca85df15 ("PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled")

from the pci tree.

I fixed it up (I just removed the files) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpZAJjUn6vel.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the pci tree with the asm-generic tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the pci tree got a conflict in:

  arch/cris/arch-v32/drivers/pci/bios.c

between commits:

  c690eddc2f3b ("CRIS: Drop support for the CRIS port")
  fd8773f9f544 ("arch: remove frv port")
  739d875dd698 ("mn10300: Remove the architecture")

from the asm-generic tree and commit:

  31cbca85df15 ("PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled")

from the pci tree.

I fixed it up (I just removed the files) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpZAJjUn6vel.pgp
Description: OpenPGP digital signature