Re: [PATCH v4 01/29] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

[Marcel Holtmann]

Hi Andy,

> SMP does ECB crypto on stack buffers.  This is complicated and
> fragile, and it will not work if the stack is virtually allocated.
> 
> Switch to the crypto_cipher interface, which is simpler and safer.
> 
> Cc: Marcel Holtmann 
> Cc: Gustavo Padovan 
> Cc: Johan Hedberg 
> Cc: "David S. Miller" 
> Cc: linux-blueto...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Acked-by: Herbert Xu 
> Acked-and-tested-by: Johan Hedberg 
> Signed-off-by: Andy Lutomirski 
> ---
> net/bluetooth/smp.c | 67 ++---
> 1 file changed, 28 insertions(+), 39 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [PATCH v4 01/29] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

[Marcel Holtmann]

Hi Andy,

> SMP does ECB crypto on stack buffers.  This is complicated and
> fragile, and it will not work if the stack is virtually allocated.
> 
> Switch to the crypto_cipher interface, which is simpler and safer.
> 
> Cc: Marcel Holtmann 
> Cc: Gustavo Padovan 
> Cc: Johan Hedberg 
> Cc: "David S. Miller" 
> Cc: linux-blueto...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Acked-by: Herbert Xu 
> Acked-and-tested-by: Johan Hedberg 
> Signed-off-by: Andy Lutomirski 
> ---
> net/bluetooth/smp.c | 67 ++---
> 1 file changed, 28 insertions(+), 39 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [PATCH] cpufreq: dt: call of_node_put() before error out

[Viresh Kumar]

On 27-06-16, 14:50, Masahiro Yamada wrote:
> If of_match_node() fails, this init function bails out without
> calling of_node_put().
> 
> I also changed of_node_put(of_root) to of_node_put(np); both of them
> hold the same pointer, but it seems better to call of_node_put()
> against the node returned by of_find_node_by_path().
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/cpufreq/cpufreq-dt-platdev.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Thanks.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: dt: call of_node_put() before error out

[Viresh Kumar]

On 27-06-16, 14:50, Masahiro Yamada wrote:
> If of_match_node() fails, this init function bails out without
> calling of_node_put().
> 
> I also changed of_node_put(of_root) to of_node_put(np); both of them
> hold the same pointer, but it seems better to call of_node_put()
> against the node returned by of_find_node_by_path().
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/cpufreq/cpufreq-dt-platdev.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Thanks.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 3/4] iio: potentiometer: mcp4531: Add device tree binding

[Florian Vaussard]

Hi Peter,

Le 27. 06. 16 à 00:12, Peter Rosin a écrit :
> Hi Florian,
> 
> On 2016-06-26 22:22, Florian Vaussard wrote:
>> This patch adds the necessary device tree binding to allow DT probing of
>> currently supported parts.
>>
>> Signed-off-by: Florian Vaussard 
>> ---
>>  drivers/iio/potentiometer/mcp4531.c | 273 
>> +++-
>>  1 file changed, 272 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/potentiometer/mcp4531.c 
>> b/drivers/iio/potentiometer/mcp4531.c
>> index 2251173..bf7b853 100644
>> --- a/drivers/iio/potentiometer/mcp4531.c
>> +++ b/drivers/iio/potentiometer/mcp4531.c
>> @@ -31,6 +31,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  
>>  #include 
>>  
>> @@ -188,12 +190,275 @@ static const struct iio_info mcp4531_info = {
>>  .driver_module = THIS_MODULE,
>>  };
>>  
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id mcp4531_of_match[] = {
>> +{
>> +.compatible = "microchip,mcp4531-502",
>> +.data = _cfg[MCP453x_502]
>> +},
> 
> All this vertical whitespace makes this unreadable. I'd be
> happier with either ignoring the 80 char rule, or skipping
> the leading tab. I.e.
> 
>   { .compatible = "microchip,mcp4531-502", .data = 
> _cfg[MCP453x_502] },
>   { .compatible = "microchip,mcp4531-103", .data = 
> _cfg[MCP453x_103] },
>   { .compatible = "microchip,mcp4531-503", .data = 
> _cfg[MCP453x_503] },
>   ...
> 
> or
> 
> { .compatible = "microchip,mcp4531-502", .data = _cfg[MCP453x_502] },
> { .compatible = "microchip,mcp4531-103", .data = _cfg[MCP453x_103] },
> { .compatible = "microchip,mcp4531-503", .data = _cfg[MCP453x_503] },
> ...
> 
> Or perhaps using a macro?
> 
> #define MCP4531_COMPATIBLE(of_compatible, cfg) {  \
>   .compatible = of_compatible,\
>   .data = _cfg[cfg],  \
> }
> 
> and then
> 
>   MCP4531_COMPATIBLE("microchip,mcp4531-502", MCP453x_502),
>   MCP4531_COMPATIBLE("microchip,mcp4531-103", MCP453x_103),
>   MCP4531_COMPATIBLE("microchip,mcp4531-503", MCP453x_503),
>   ...
> 
> Pick any of those, and you have my ack. Maybe Jonathan has an opinion
> on which is best?
> 

The macro is my preferred one, as it makes things easier to read. Jonathan?

Thanks for the suggestion!

Best,
Florian

Re: [PATCH v2 3/4] iio: potentiometer: mcp4531: Add device tree binding

[Florian Vaussard]

Hi Peter,

Le 27. 06. 16 à 00:12, Peter Rosin a écrit :
> Hi Florian,
> 
> On 2016-06-26 22:22, Florian Vaussard wrote:
>> This patch adds the necessary device tree binding to allow DT probing of
>> currently supported parts.
>>
>> Signed-off-by: Florian Vaussard 
>> ---
>>  drivers/iio/potentiometer/mcp4531.c | 273 
>> +++-
>>  1 file changed, 272 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/potentiometer/mcp4531.c 
>> b/drivers/iio/potentiometer/mcp4531.c
>> index 2251173..bf7b853 100644
>> --- a/drivers/iio/potentiometer/mcp4531.c
>> +++ b/drivers/iio/potentiometer/mcp4531.c
>> @@ -31,6 +31,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  
>>  #include 
>>  
>> @@ -188,12 +190,275 @@ static const struct iio_info mcp4531_info = {
>>  .driver_module = THIS_MODULE,
>>  };
>>  
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id mcp4531_of_match[] = {
>> +{
>> +.compatible = "microchip,mcp4531-502",
>> +.data = _cfg[MCP453x_502]
>> +},
> 
> All this vertical whitespace makes this unreadable. I'd be
> happier with either ignoring the 80 char rule, or skipping
> the leading tab. I.e.
> 
>   { .compatible = "microchip,mcp4531-502", .data = 
> _cfg[MCP453x_502] },
>   { .compatible = "microchip,mcp4531-103", .data = 
> _cfg[MCP453x_103] },
>   { .compatible = "microchip,mcp4531-503", .data = 
> _cfg[MCP453x_503] },
>   ...
> 
> or
> 
> { .compatible = "microchip,mcp4531-502", .data = _cfg[MCP453x_502] },
> { .compatible = "microchip,mcp4531-103", .data = _cfg[MCP453x_103] },
> { .compatible = "microchip,mcp4531-503", .data = _cfg[MCP453x_503] },
> ...
> 
> Or perhaps using a macro?
> 
> #define MCP4531_COMPATIBLE(of_compatible, cfg) {  \
>   .compatible = of_compatible,\
>   .data = _cfg[cfg],  \
> }
> 
> and then
> 
>   MCP4531_COMPATIBLE("microchip,mcp4531-502", MCP453x_502),
>   MCP4531_COMPATIBLE("microchip,mcp4531-103", MCP453x_103),
>   MCP4531_COMPATIBLE("microchip,mcp4531-503", MCP453x_503),
>   ...
> 
> Pick any of those, and you have my ack. Maybe Jonathan has an opinion
> on which is best?
> 

The macro is my preferred one, as it makes things easier to read. Jonathan?

Thanks for the suggestion!

Best,
Florian

Re: [PATCH v2 2/4] iio: potentiometer: mcp4531: Add device tree binding documentation

[Florian Vaussard]

Hello Peter,

Le 26. 06. 16 à 23:38, Peter Rosin a écrit :
> On 2016-06-26 22:22, Florian Vaussard wrote:
>> Add the device tree documentation for all the supported parts. Apart the
>> compatible string and standard I2C binding, no other binding is currently
>> needed.
>>
>> Signed-off-by: Florian Vaussard 
>> ---
>>  .../devicetree/bindings/i2c/trivial-devices.txt| 64 
>> ++
>>  1 file changed, 64 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
>> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>> index 53987449..4ffe9a9 100644
>> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>> @@ -56,6 +56,70 @@ maxim,ds1050  5 Bit Programmable, Pulse-Width 
>> Modulator
>>  maxim,max1237   Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit 
>> ADCs
>>  maxim,max6625   9-Bit/12-Bit Temperature Sensors with 
>> I²C-Compatible Serial Interface
>>  mc,rv3029c2 Real Time Clock Module with I2C-Bus
>> +microchip,mcp4531-502   Microchip 8-bit Single I2C Digital 
>> Potentiometer (5k)
>   ^
> You have mixed up 7/8-bit, here and below.
> 

Oh you are right, stupid me. I will fix.

Thanks,
Florian

> Cheers,
> Peter
> 
>> +microchip,mcp4531-103   Microchip 8-bit Single I2C Digital 
>> Potentiometer (10k)
>> +microchip,mcp4531-503   Microchip 8-bit Single I2C Digital 
>> Potentiometer (50k)
>> +microchip,mcp4531-104   Microchip 8-bit Single I2C Digital 
>> Potentiometer (100k)
>> +microchip,mcp4532-502   Microchip 8-bit Single I2C Digital 
>> Potentiometer (5k)
>> +microchip,mcp4532-103   Microchip 8-bit Single I2C Digital 
>> Potentiometer (10k)
>> +microchip,mcp4532-503   Microchip 8-bit Single I2C Digital 
>> Potentiometer (50k)
>> +microchip,mcp4532-104   Microchip 8-bit Single I2C Digital 
>> Potentiometer (100k)
>> +microchip,mcp4541-502   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (5k)
>> +microchip,mcp4541-103   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (10k)
>> +microchip,mcp4541-503   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (50k)
>> +microchip,mcp4541-104   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (100k)
>> +microchip,mcp4542-502   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (5k)
>> +microchip,mcp4542-103   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (10k)
>> +microchip,mcp4542-503   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (50k)
>> +microchip,mcp4542-104   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (100k)
>> +microchip,mcp4551-502   Microchip 7-bit Single I2C Digital 
>> Potentiometer (5k)
>> +microchip,mcp4551-103   Microchip 7-bit Single I2C Digital 
>> Potentiometer (10k)
>> +microchip,mcp4551-503   Microchip 7-bit Single I2C Digital 
>> Potentiometer (50k)
>> +microchip,mcp4551-104   Microchip 7-bit Single I2C Digital 
>> Potentiometer (100k)
>> +microchip,mcp4552-502   Microchip 7-bit Single I2C Digital 
>> Potentiometer (5k)
>> +microchip,mcp4552-103   Microchip 7-bit Single I2C Digital 
>> Potentiometer (10k)
>> +microchip,mcp4552-503   Microchip 7-bit Single I2C Digital 
>> Potentiometer (50k)
>> +microchip,mcp4552-104   Microchip 7-bit Single I2C Digital 
>> Potentiometer (100k)
>> +microchip,mcp4561-502   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (5k)
>> +microchip,mcp4561-103   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (10k)
>> +microchip,mcp4561-503   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (50k)
>> +microchip,mcp4561-104   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (100k)
>> +microchip,mcp4562-502   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (5k)
>> +microchip,mcp4562-103   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (10k)
>> +microchip,mcp4562-503   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (50k)
>> +microchip,mcp4562-104   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (100k)
>> +microchip,mcp4631-502   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (5k)
>> +microchip,mcp4631-103   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (10k)
>> +microchip,mcp4631-503   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (50k)
>> +microchip,mcp4631-104   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (100k)
>> +microchip,mcp4632-502   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (5k)
>> +microchip,mcp4632-103   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (10k)
>> 

Re: [PATCH 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

[Florian Vaussard]

Hi Pavel,

Le 26. 06. 16 à 23:49, Pavel Machek a écrit :
> Hi!
> 
>>> +struct ncp5623_led {
>>> +   bool active;
>>> +   unsigned int led_no;
>>> +   struct led_classdev ldev;
>>> +   struct work_struct work;
>>> +   struct ncp5623_priv *priv;
>>> +};
>>> +
>>> +struct ncp5623_priv {
>>> +   struct ncp5623_led leds[NCP5623_MAX_LEDS];
>>
>> Please allocate memory dynamically, depending on the number
>> of LEDs defined in a Device Tree.
> 
> MAX_LEDs is three. Are you sure overhead of dynamic allocation is
> worth it?
> 
> And if this is for RGB leds... very probably device will want to use
> all 3 channels.
> 

I was about to raise the same question during the v2 of this patch. In addition
to your arguments, this also changes the way this array is indexed.

Currently the LED number is used as index, but with dynamic allocation I have to
use an abstract index. This makes some logic a bit harder, especially to check
if the same LED is declared twice in the device tree (duplicated 'reg' 
property).

Best,
Florian

Re: [PATCH v2 2/4] iio: potentiometer: mcp4531: Add device tree binding documentation

[Florian Vaussard]

Hello Peter,

Le 26. 06. 16 à 23:38, Peter Rosin a écrit :
> On 2016-06-26 22:22, Florian Vaussard wrote:
>> Add the device tree documentation for all the supported parts. Apart the
>> compatible string and standard I2C binding, no other binding is currently
>> needed.
>>
>> Signed-off-by: Florian Vaussard 
>> ---
>>  .../devicetree/bindings/i2c/trivial-devices.txt| 64 
>> ++
>>  1 file changed, 64 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
>> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>> index 53987449..4ffe9a9 100644
>> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>> @@ -56,6 +56,70 @@ maxim,ds1050  5 Bit Programmable, Pulse-Width 
>> Modulator
>>  maxim,max1237   Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit 
>> ADCs
>>  maxim,max6625   9-Bit/12-Bit Temperature Sensors with 
>> I²C-Compatible Serial Interface
>>  mc,rv3029c2 Real Time Clock Module with I2C-Bus
>> +microchip,mcp4531-502   Microchip 8-bit Single I2C Digital 
>> Potentiometer (5k)
>   ^
> You have mixed up 7/8-bit, here and below.
> 

Oh you are right, stupid me. I will fix.

Thanks,
Florian

> Cheers,
> Peter
> 
>> +microchip,mcp4531-103   Microchip 8-bit Single I2C Digital 
>> Potentiometer (10k)
>> +microchip,mcp4531-503   Microchip 8-bit Single I2C Digital 
>> Potentiometer (50k)
>> +microchip,mcp4531-104   Microchip 8-bit Single I2C Digital 
>> Potentiometer (100k)
>> +microchip,mcp4532-502   Microchip 8-bit Single I2C Digital 
>> Potentiometer (5k)
>> +microchip,mcp4532-103   Microchip 8-bit Single I2C Digital 
>> Potentiometer (10k)
>> +microchip,mcp4532-503   Microchip 8-bit Single I2C Digital 
>> Potentiometer (50k)
>> +microchip,mcp4532-104   Microchip 8-bit Single I2C Digital 
>> Potentiometer (100k)
>> +microchip,mcp4541-502   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (5k)
>> +microchip,mcp4541-103   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (10k)
>> +microchip,mcp4541-503   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (50k)
>> +microchip,mcp4541-104   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (100k)
>> +microchip,mcp4542-502   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (5k)
>> +microchip,mcp4542-103   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (10k)
>> +microchip,mcp4542-503   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (50k)
>> +microchip,mcp4542-104   Microchip 8-bit Single I2C Digital 
>> Potentiometer with NV Memory (100k)
>> +microchip,mcp4551-502   Microchip 7-bit Single I2C Digital 
>> Potentiometer (5k)
>> +microchip,mcp4551-103   Microchip 7-bit Single I2C Digital 
>> Potentiometer (10k)
>> +microchip,mcp4551-503   Microchip 7-bit Single I2C Digital 
>> Potentiometer (50k)
>> +microchip,mcp4551-104   Microchip 7-bit Single I2C Digital 
>> Potentiometer (100k)
>> +microchip,mcp4552-502   Microchip 7-bit Single I2C Digital 
>> Potentiometer (5k)
>> +microchip,mcp4552-103   Microchip 7-bit Single I2C Digital 
>> Potentiometer (10k)
>> +microchip,mcp4552-503   Microchip 7-bit Single I2C Digital 
>> Potentiometer (50k)
>> +microchip,mcp4552-104   Microchip 7-bit Single I2C Digital 
>> Potentiometer (100k)
>> +microchip,mcp4561-502   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (5k)
>> +microchip,mcp4561-103   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (10k)
>> +microchip,mcp4561-503   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (50k)
>> +microchip,mcp4561-104   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (100k)
>> +microchip,mcp4562-502   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (5k)
>> +microchip,mcp4562-103   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (10k)
>> +microchip,mcp4562-503   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (50k)
>> +microchip,mcp4562-104   Microchip 7-bit Single I2C Digital 
>> Potentiometer with NV Memory (100k)
>> +microchip,mcp4631-502   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (5k)
>> +microchip,mcp4631-103   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (10k)
>> +microchip,mcp4631-503   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (50k)
>> +microchip,mcp4631-104   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (100k)
>> +microchip,mcp4632-502   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (5k)
>> +microchip,mcp4632-103   Microchip 8-bit Dual I2C Digital Potentiometer 
>> (10k)
>> +microchip,mcp4632-503   

Re: [PATCH 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

[Florian Vaussard]

Hi Pavel,

Le 26. 06. 16 à 23:49, Pavel Machek a écrit :
> Hi!
> 
>>> +struct ncp5623_led {
>>> +   bool active;
>>> +   unsigned int led_no;
>>> +   struct led_classdev ldev;
>>> +   struct work_struct work;
>>> +   struct ncp5623_priv *priv;
>>> +};
>>> +
>>> +struct ncp5623_priv {
>>> +   struct ncp5623_led leds[NCP5623_MAX_LEDS];
>>
>> Please allocate memory dynamically, depending on the number
>> of LEDs defined in a Device Tree.
> 
> MAX_LEDs is three. Are you sure overhead of dynamic allocation is
> worth it?
> 
> And if this is for RGB leds... very probably device will want to use
> all 3 channels.
> 

I was about to raise the same question during the v2 of this patch. In addition
to your arguments, this also changes the way this array is indexed.

Currently the LED number is used as index, but with dynamic allocation I have to
use an abstract index. This makes some logic a bit harder, especially to check
if the same LED is declared twice in the device tree (duplicated 'reg' 
property).

Best,
Florian

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

[Anshuman Khandual]

On 06/16/2016 11:07 AM, Minchan Kim wrote:
> On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote:
>> On 06/16/2016 05:56 AM, Minchan Kim wrote:
>>> On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
 On 06/15/2016 08:02 AM, Minchan Kim wrote:
> Hi,
>
> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
>>> On 05/31/2016 05:31 AM, Minchan Kim wrote:
> @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, 
> struct page *newpage,
>   int rc = -EAGAIN;
>   int page_was_mapped = 0;
>   struct anon_vma *anon_vma = NULL;
> + bool is_lru = !__PageMovable(page);
>  
>   if (!trylock_page(page)) {
>   if (!force || mode == MIGRATE_ASYNC)
> @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, 
> struct page *newpage,
>   goto out_unlock_both;
>   }
>  
> + if (unlikely(!is_lru)) {
> + rc = move_to_new_page(newpage, page, mode);
> + goto out_unlock_both;
> + }
> +
>>>
>>> Hello Minchan,
>>>
>>> I might be missing something here but does this implementation support 
>>> the
>>> scenario where these non LRU pages owned by the driver mapped as PTE 
>>> into
>>> process page table ? Because the "goto out_unlock_both" statement above
>>> skips all the PTE unmap, putting a migration PTE and removing the 
>>> migration
>>> PTE steps.
> You're right. Unfortunately, it doesn't support right now but surely,
> it's my TODO after landing this work.
>
> Could you share your usecase?

 Sure.
>>>
>>> Thanks a lot!
>>>

 My driver has privately managed non LRU pages which gets mapped into user 
 space
 process page table through f_ops->mmap() and vmops->fault() which then 
 updates
 the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). 
 One thing
>>>
>>> Hmm, page_add_file_rmap is not exported function. How does your driver can 
>>> use it?
>>
>> Its not using the function directly, I just re-iterated the sequence of 
>> functions
>> above. (do_set_pte -> page_add_file_rmap) gets called after we grab the page 
>> from
>> driver through (__do_fault->vma->vm_ops->fault()).
>>
>>> Do you use vm_insert_pfn?
>>> What type your vma is? VM_PFNMMAP or VM_MIXEDMAP?
>>
>> I dont use vm_insert_pfn(). Here is the sequence of events how the user space
>> VMA gets the non LRU pages from the driver.
>>
>> - Driver registers a character device with 'struct file_operations' binding
>> - Then the 'fops->mmap()' just binds the incoming 'struct vma' with a 'struct
>>   vm_operations_struct' which provides the 'vmops->fault()' routine which
>>   basically traps all page faults on the VMA and provides one page at a time
>>   through a driver specific allocation routine which hands over non LRU pages
>>
>> The VMA is not anything special as such. Its what we get when we try to do a
>> simple mmap() on a file descriptor pointing to a character device. I can
>> figure out all the VM_* flags it holds after creation.
>>
>>>
>>> I want to make dummy driver to simulate your case.
>>
>> Sure. I hope the above mentioned steps will help you but in case you need 
>> more
>> information, please do let me know.
> 
> I got understood now. :)
> I will test it with dummy driver and will Cc'ed when I send a patch.

Hello Minchan,

Do you have any updates on this ? The V7 of the series still has this 
limitation.
Did you get a chance to test the driver out ? I am still concerned about how to
handle the struct address_space override problem within the struct page.

- Anshuman

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

[Anshuman Khandual]

On 06/16/2016 11:07 AM, Minchan Kim wrote:
> On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote:
>> On 06/16/2016 05:56 AM, Minchan Kim wrote:
>>> On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
 On 06/15/2016 08:02 AM, Minchan Kim wrote:
> Hi,
>
> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
>>> On 05/31/2016 05:31 AM, Minchan Kim wrote:
> @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, 
> struct page *newpage,
>   int rc = -EAGAIN;
>   int page_was_mapped = 0;
>   struct anon_vma *anon_vma = NULL;
> + bool is_lru = !__PageMovable(page);
>  
>   if (!trylock_page(page)) {
>   if (!force || mode == MIGRATE_ASYNC)
> @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, 
> struct page *newpage,
>   goto out_unlock_both;
>   }
>  
> + if (unlikely(!is_lru)) {
> + rc = move_to_new_page(newpage, page, mode);
> + goto out_unlock_both;
> + }
> +
>>>
>>> Hello Minchan,
>>>
>>> I might be missing something here but does this implementation support 
>>> the
>>> scenario where these non LRU pages owned by the driver mapped as PTE 
>>> into
>>> process page table ? Because the "goto out_unlock_both" statement above
>>> skips all the PTE unmap, putting a migration PTE and removing the 
>>> migration
>>> PTE steps.
> You're right. Unfortunately, it doesn't support right now but surely,
> it's my TODO after landing this work.
>
> Could you share your usecase?

 Sure.
>>>
>>> Thanks a lot!
>>>

 My driver has privately managed non LRU pages which gets mapped into user 
 space
 process page table through f_ops->mmap() and vmops->fault() which then 
 updates
 the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). 
 One thing
>>>
>>> Hmm, page_add_file_rmap is not exported function. How does your driver can 
>>> use it?
>>
>> Its not using the function directly, I just re-iterated the sequence of 
>> functions
>> above. (do_set_pte -> page_add_file_rmap) gets called after we grab the page 
>> from
>> driver through (__do_fault->vma->vm_ops->fault()).
>>
>>> Do you use vm_insert_pfn?
>>> What type your vma is? VM_PFNMMAP or VM_MIXEDMAP?
>>
>> I dont use vm_insert_pfn(). Here is the sequence of events how the user space
>> VMA gets the non LRU pages from the driver.
>>
>> - Driver registers a character device with 'struct file_operations' binding
>> - Then the 'fops->mmap()' just binds the incoming 'struct vma' with a 'struct
>>   vm_operations_struct' which provides the 'vmops->fault()' routine which
>>   basically traps all page faults on the VMA and provides one page at a time
>>   through a driver specific allocation routine which hands over non LRU pages
>>
>> The VMA is not anything special as such. Its what we get when we try to do a
>> simple mmap() on a file descriptor pointing to a character device. I can
>> figure out all the VM_* flags it holds after creation.
>>
>>>
>>> I want to make dummy driver to simulate your case.
>>
>> Sure. I hope the above mentioned steps will help you but in case you need 
>> more
>> information, please do let me know.
> 
> I got understood now. :)
> I will test it with dummy driver and will Cc'ed when I send a patch.

Hello Minchan,

Do you have any updates on this ? The V7 of the series still has this 
limitation.
Did you get a chance to test the driver out ? I am still concerned about how to
handle the struct address_space override problem within the struct page.

- Anshuman

[PATCH] cpufreq: dt: call of_node_put() before error out

[Masahiro Yamada]

If of_match_node() fails, this init function bails out without
calling of_node_put().

I also changed of_node_put(of_root) to of_node_put(np); both of them
hold the same pointer, but it seems better to call of_node_put()
against the node returned by of_find_node_by_path().

Signed-off-by: Masahiro Yamada 
---

 drivers/cpufreq/cpufreq-dt-platdev.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3646b14..0bb44d5 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -79,15 +79,16 @@ static const struct of_device_id machines[] __initconst = {
 static int __init cpufreq_dt_platdev_init(void)
 {
struct device_node *np = of_find_node_by_path("/");
+   const struct of_device_id *match;
 
if (!np)
return -ENODEV;
 
-   if (!of_match_node(machines, np))
+   match = of_match_node(machines, np);
+   of_node_put(np);
+   if (!match)
return -ENODEV;
 
-   of_node_put(of_root);
-
return PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-dt", -1,
   NULL, 0));
 }
-- 
1.9.1

[PATCH] cpufreq: dt: call of_node_put() before error out

[Masahiro Yamada]

If of_match_node() fails, this init function bails out without
calling of_node_put().

I also changed of_node_put(of_root) to of_node_put(np); both of them
hold the same pointer, but it seems better to call of_node_put()
against the node returned by of_find_node_by_path().

Signed-off-by: Masahiro Yamada 
---

 drivers/cpufreq/cpufreq-dt-platdev.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3646b14..0bb44d5 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -79,15 +79,16 @@ static const struct of_device_id machines[] __initconst = {
 static int __init cpufreq_dt_platdev_init(void)
 {
struct device_node *np = of_find_node_by_path("/");
+   const struct of_device_id *match;
 
if (!np)
return -ENODEV;
 
-   if (!of_match_node(machines, np))
+   match = of_match_node(machines, np);
+   of_node_put(np);
+   if (!match)
return -ENODEV;
 
-   of_node_put(of_root);
-
return PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-dt", -1,
   NULL, 0));
 }
-- 
1.9.1

Re: [PATCH v3 0/9] reduce memory usage by page_owner

[Joonsoo Kim]

On Fri, Jun 24, 2016 at 04:19:35PM -0700, Andrew Morton wrote:
> On Fri, 17 Jun 2016 16:57:30 +0900 js1...@gmail.com wrote:
> 
> > There was a bug reported by Sasha and minor fixes is needed
> > so I send v3.
> > 
> > o fix a bg reported by Sasha (mm/compaction: split freepages
> > without holding the zone lock)
> > o add code comment for todo list (mm/page_owner: use stackdepot
> > to store stacktrace) per Michal
> > o add 'inline' keyword (mm/page_alloc: introduce post allocation
> > processing on page allocator) per Vlastimil
> > o add a patch that clean-up code per Vlastimil
> 
> I've gone through v3 patches 2-9 and have plucked out the deltas to
> take what-i-had and turn that into what-you-sent.  Patch 1/9 has seen a
> lot of competing churn in isolate_freepages_block(), so please review
> the current version of that, below.  Between the "===" markers:

Hello, Andrew.

Below looks okay to me.

Thanks.

> 
> 
> static unsigned long isolate_freepages_block(struct compact_control *cc,
>   unsigned long *start_pfn,
>   unsigned long end_pfn,
>   struct list_head *freelist,
>   bool strict)
> {
>   int nr_scanned = 0, total_isolated = 0;
>   struct page *cursor, *valid_page = NULL;
>   unsigned long flags = 0;
>   bool locked = false;
>   unsigned long blockpfn = *start_pfn;
>   unsigned int order;
> 
>   cursor = pfn_to_page(blockpfn);
> 
>   /* Isolate free pages. */
>   for (; blockpfn < end_pfn; blockpfn++, cursor++) {
>   int isolated;
>   struct page *page = cursor;
> 
>   /*
>* Periodically drop the lock (if held) regardless of its
>* contention, to give chance to IRQs. Abort if fatal signal
>* pending or async compaction detects need_resched()
>*/
>   if (!(blockpfn % SWAP_CLUSTER_MAX)
>   && compact_unlock_should_abort(>zone->lock, flags,
>   , cc))
>   break;
> 
>   nr_scanned++;
>   if (!pfn_valid_within(blockpfn))
>   goto isolate_fail;
> 
>   if (!valid_page)
>   valid_page = page;
> 
>   /*
>* For compound pages such as THP and hugetlbfs, we can save
>* potentially a lot of iterations if we skip them at once.
>* The check is racy, but we can consider only valid values
>* and the only danger is skipping too much.
>*/
>   if (PageCompound(page)) {
>   unsigned int comp_order = compound_order(page);
> 
>   if (likely(comp_order < MAX_ORDER)) {
>   blockpfn += (1UL << comp_order) - 1;
>   cursor += (1UL << comp_order) - 1;
>   }
> 
>   goto isolate_fail;
>   }
> 
>   if (!PageBuddy(page))
>   goto isolate_fail;
> 
> 
>   /*
>* If we already hold the lock, we can skip some rechecking.
>* Note that if we hold the lock now, checked_pageblock was
>* already set in some previous iteration (or strict is true),
>* so it is correct to skip the suitable migration target
>* recheck as well.
>*/
>   if (!locked) {
>   /*
>* The zone lock must be held to isolate freepages.
>* Unfortunately this is a very coarse lock and can be
>* heavily contended if there are parallel allocations
>* or parallel compactions. For async compaction do not
>* spin on the lock and we acquire the lock as late as
>* possible.
>*/
>   locked = compact_trylock_irqsave(>zone->lock,
>   , cc);
>   if (!locked)
>   break;
> 
>   /* Recheck this is a buddy page under lock */
>   if (!PageBuddy(page))
>   goto isolate_fail;
>   }
> 
>   /* Found a free page, will break it into order-0 pages */
>   order = page_order(page);
>   isolated = __isolate_free_page(page, order);
>   if (!isolated)
>   break;
>   set_page_private(page, order);
> 
>   total_isolated += isolated;
>   cc->nr_freepages += isolated;
>   list_add_tail(>lru, freelist);
> 
>   if (!strict && cc->nr_migratepages <= 

Re: [PATCH v3 0/9] reduce memory usage by page_owner

[Joonsoo Kim]

On Fri, Jun 24, 2016 at 04:19:35PM -0700, Andrew Morton wrote:
> On Fri, 17 Jun 2016 16:57:30 +0900 js1...@gmail.com wrote:
> 
> > There was a bug reported by Sasha and minor fixes is needed
> > so I send v3.
> > 
> > o fix a bg reported by Sasha (mm/compaction: split freepages
> > without holding the zone lock)
> > o add code comment for todo list (mm/page_owner: use stackdepot
> > to store stacktrace) per Michal
> > o add 'inline' keyword (mm/page_alloc: introduce post allocation
> > processing on page allocator) per Vlastimil
> > o add a patch that clean-up code per Vlastimil
> 
> I've gone through v3 patches 2-9 and have plucked out the deltas to
> take what-i-had and turn that into what-you-sent.  Patch 1/9 has seen a
> lot of competing churn in isolate_freepages_block(), so please review
> the current version of that, below.  Between the "===" markers:

Hello, Andrew.

Below looks okay to me.

Thanks.

> 
> 
> static unsigned long isolate_freepages_block(struct compact_control *cc,
>   unsigned long *start_pfn,
>   unsigned long end_pfn,
>   struct list_head *freelist,
>   bool strict)
> {
>   int nr_scanned = 0, total_isolated = 0;
>   struct page *cursor, *valid_page = NULL;
>   unsigned long flags = 0;
>   bool locked = false;
>   unsigned long blockpfn = *start_pfn;
>   unsigned int order;
> 
>   cursor = pfn_to_page(blockpfn);
> 
>   /* Isolate free pages. */
>   for (; blockpfn < end_pfn; blockpfn++, cursor++) {
>   int isolated;
>   struct page *page = cursor;
> 
>   /*
>* Periodically drop the lock (if held) regardless of its
>* contention, to give chance to IRQs. Abort if fatal signal
>* pending or async compaction detects need_resched()
>*/
>   if (!(blockpfn % SWAP_CLUSTER_MAX)
>   && compact_unlock_should_abort(>zone->lock, flags,
>   , cc))
>   break;
> 
>   nr_scanned++;
>   if (!pfn_valid_within(blockpfn))
>   goto isolate_fail;
> 
>   if (!valid_page)
>   valid_page = page;
> 
>   /*
>* For compound pages such as THP and hugetlbfs, we can save
>* potentially a lot of iterations if we skip them at once.
>* The check is racy, but we can consider only valid values
>* and the only danger is skipping too much.
>*/
>   if (PageCompound(page)) {
>   unsigned int comp_order = compound_order(page);
> 
>   if (likely(comp_order < MAX_ORDER)) {
>   blockpfn += (1UL << comp_order) - 1;
>   cursor += (1UL << comp_order) - 1;
>   }
> 
>   goto isolate_fail;
>   }
> 
>   if (!PageBuddy(page))
>   goto isolate_fail;
> 
> 
>   /*
>* If we already hold the lock, we can skip some rechecking.
>* Note that if we hold the lock now, checked_pageblock was
>* already set in some previous iteration (or strict is true),
>* so it is correct to skip the suitable migration target
>* recheck as well.
>*/
>   if (!locked) {
>   /*
>* The zone lock must be held to isolate freepages.
>* Unfortunately this is a very coarse lock and can be
>* heavily contended if there are parallel allocations
>* or parallel compactions. For async compaction do not
>* spin on the lock and we acquire the lock as late as
>* possible.
>*/
>   locked = compact_trylock_irqsave(>zone->lock,
>   , cc);
>   if (!locked)
>   break;
> 
>   /* Recheck this is a buddy page under lock */
>   if (!PageBuddy(page))
>   goto isolate_fail;
>   }
> 
>   /* Found a free page, will break it into order-0 pages */
>   order = page_order(page);
>   isolated = __isolate_free_page(page, order);
>   if (!isolated)
>   break;
>   set_page_private(page, order);
> 
>   total_isolated += isolated;
>   cc->nr_freepages += isolated;
>   list_add_tail(>lru, freelist);
> 
>   if (!strict && cc->nr_migratepages <= 

Re: [PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace

[Yury Norov]

Hi Zhou,

Thank you for the patch. The idea is ok, but patch format got broken
for some reason. Could you re-send it?

Yury.

On Mon, Jun 27, 2016 at 12:49:05PM +0800, zhouchengming wrote:
> atus: RO
> Content-Length: 4732
> Lines: 181
> 
> The function compat_ptrace_request(used by ilp32) don't handle
> {GET,SET}SIGMASK request, so it will be handled by ptrace_request.
> But it's wrong because the compat_sigset_t of ilp32 differs from
> the sigset_t of aarch64. The patch fixes it.
> 
> Signed-off-by: Zhou Chengming 
> ---
>  arch/arm64/include/asm/signal_ilp32.h |   22 
>  arch/arm64/kernel/ptrace.c|   62
> +

Here -  unneeded line break

>  arch/arm64/kernel/signal_ilp32.c  |   23 +
>  3 files changed, 85 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/signal_ilp32.h
> b/arch/arm64/include/asm/signal_ilp32.h

and here

> index 30eff23..ed52607 100644
> --- a/arch/arm64/include/asm/signal_ilp32.h
> +++ b/arch/arm64/include/asm/signal_ilp32.h
> @@ -21,6 +21,28 @@
>  int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
> struct pt_regs *regs);
> 
> +static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t *set)
> +{
> + compat_sigset_t cset;
> +
> + cset.sig[0] = set->sig[0] & 0xull;
> + cset.sig[1] = set->sig[0] >> 32;
> +
> + return copy_to_user(uset, , sizeof(*uset));
> +}
> +
> +static inline int get_sigset_t(sigset_t *set,
> +const compat_sigset_t __user *uset)
> +{
> + compat_sigset_t s32;
> +
> + if (copy_from_user(, uset, sizeof(*uset)))
> + return -EFAULT;
> +
> + set->sig[0] = s32.sig[0] | (((long)s32.sig[1]) << 32);
> + return 0;
> +}
> +
>  #else
> 
>  static inline int ilp32_setup_rt_frame(int usig, struct ksignal *ksig,
> sigset_t *set,

and here

> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index a861105..8d4cad1 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #define CREATE_TRACE_POINTS
>  #include 
> @@ -1231,12 +1232,73 @@ COMPAT_SYSCALL_DEFINE4(aarch32_ptrace,
> compat_long_t, request, compat_long_t, pi

and later on the patch

> 
>  #endif /* CONFIG_AARCH32_EL0 */
> 
> +#ifdef CONFIG_ARM64_ILP32
> +
> +static int compat_ilp32_ptrace(struct task_struct *child, compat_long_t
> request,
> + compat_ulong_t addr, compat_ulong_t data)
> +{
> + compat_ulong_t __user *datap = compat_ptr(data);
> + int ret;
> +
> + switch (request) {
> + case PTRACE_GETSIGMASK:
> + if (addr != sizeof(compat_sigset_t)) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (put_sigset_t((compat_sigset_t __user *)datap, 
> >blocked))
> + ret = -EFAULT;
> + else
> + ret = 0;
> + break;
> +
> + case PTRACE_SETSIGMASK: {
> + sigset_t new_set;
> + if (addr != sizeof(compat_sigset_t)) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (get_sigset_t(_set, (compat_sigset_t __user *)datap)) {
> + ret = -EFAULT;
> + break;
> + }
> +
> + sigdelsetmask(_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
> +
> + /*
> +  * Every thread does recalc_sigpending() after resume, so
> +  * retarget_shared_pending() and recalc_sigpending() are not
> +  * called here.
> +  */
> + spin_lock_irq(>sighand->siglock);
> + child->blocked = new_set;
> + spin_unlock_irq(>sighand->siglock);
> +
> + ret = 0;
> + break;
> + }
> +
> + default:
> + ret = compat_ptrace_request(child, request, addr, data);
> + }
> +
> + return ret;
> +}
> +
> +#endif /* CONFIG_ARM64_ILP32 */
> +
>  #ifdef CONFIG_COMPAT
> 
>  long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
>   compat_ulong_t caddr, compat_ulong_t cdata)
>  {
> +#ifdef CONFIG_ARM64_ILP32
> + return compat_ilp32_ptrace(child, request, caddr, cdata);
> +#else
>   return compat_ptrace_request(child, request, caddr, cdata);
> +#endif
>  }
> 
>  #endif /* CONFIG_COMPAT */
> diff --git a/arch/arm64/kernel/signal_ilp32.c
> b/arch/arm64/kernel/signal_ilp32.c
> index 8ca64b9..3ef2749 100644
> --- a/arch/arm64/kernel/signal_ilp32.c
> +++ b/arch/arm64/kernel/signal_ilp32.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -58,28 +59,6 @@ struct ilp32_rt_sigframe {
>   struct ilp32_sigframe sig;
>  };
> 
> -static inline int 

Re: [PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace

[Yury Norov]

Hi Zhou,

Thank you for the patch. The idea is ok, but patch format got broken
for some reason. Could you re-send it?

Yury.

On Mon, Jun 27, 2016 at 12:49:05PM +0800, zhouchengming wrote:
> atus: RO
> Content-Length: 4732
> Lines: 181
> 
> The function compat_ptrace_request(used by ilp32) don't handle
> {GET,SET}SIGMASK request, so it will be handled by ptrace_request.
> But it's wrong because the compat_sigset_t of ilp32 differs from
> the sigset_t of aarch64. The patch fixes it.
> 
> Signed-off-by: Zhou Chengming 
> ---
>  arch/arm64/include/asm/signal_ilp32.h |   22 
>  arch/arm64/kernel/ptrace.c|   62
> +

Here -  unneeded line break

>  arch/arm64/kernel/signal_ilp32.c  |   23 +
>  3 files changed, 85 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/signal_ilp32.h
> b/arch/arm64/include/asm/signal_ilp32.h

and here

> index 30eff23..ed52607 100644
> --- a/arch/arm64/include/asm/signal_ilp32.h
> +++ b/arch/arm64/include/asm/signal_ilp32.h
> @@ -21,6 +21,28 @@
>  int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
> struct pt_regs *regs);
> 
> +static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t *set)
> +{
> + compat_sigset_t cset;
> +
> + cset.sig[0] = set->sig[0] & 0xull;
> + cset.sig[1] = set->sig[0] >> 32;
> +
> + return copy_to_user(uset, , sizeof(*uset));
> +}
> +
> +static inline int get_sigset_t(sigset_t *set,
> +const compat_sigset_t __user *uset)
> +{
> + compat_sigset_t s32;
> +
> + if (copy_from_user(, uset, sizeof(*uset)))
> + return -EFAULT;
> +
> + set->sig[0] = s32.sig[0] | (((long)s32.sig[1]) << 32);
> + return 0;
> +}
> +
>  #else
> 
>  static inline int ilp32_setup_rt_frame(int usig, struct ksignal *ksig,
> sigset_t *set,

and here

> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index a861105..8d4cad1 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #define CREATE_TRACE_POINTS
>  #include 
> @@ -1231,12 +1232,73 @@ COMPAT_SYSCALL_DEFINE4(aarch32_ptrace,
> compat_long_t, request, compat_long_t, pi

and later on the patch

> 
>  #endif /* CONFIG_AARCH32_EL0 */
> 
> +#ifdef CONFIG_ARM64_ILP32
> +
> +static int compat_ilp32_ptrace(struct task_struct *child, compat_long_t
> request,
> + compat_ulong_t addr, compat_ulong_t data)
> +{
> + compat_ulong_t __user *datap = compat_ptr(data);
> + int ret;
> +
> + switch (request) {
> + case PTRACE_GETSIGMASK:
> + if (addr != sizeof(compat_sigset_t)) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (put_sigset_t((compat_sigset_t __user *)datap, 
> >blocked))
> + ret = -EFAULT;
> + else
> + ret = 0;
> + break;
> +
> + case PTRACE_SETSIGMASK: {
> + sigset_t new_set;
> + if (addr != sizeof(compat_sigset_t)) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (get_sigset_t(_set, (compat_sigset_t __user *)datap)) {
> + ret = -EFAULT;
> + break;
> + }
> +
> + sigdelsetmask(_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
> +
> + /*
> +  * Every thread does recalc_sigpending() after resume, so
> +  * retarget_shared_pending() and recalc_sigpending() are not
> +  * called here.
> +  */
> + spin_lock_irq(>sighand->siglock);
> + child->blocked = new_set;
> + spin_unlock_irq(>sighand->siglock);
> +
> + ret = 0;
> + break;
> + }
> +
> + default:
> + ret = compat_ptrace_request(child, request, addr, data);
> + }
> +
> + return ret;
> +}
> +
> +#endif /* CONFIG_ARM64_ILP32 */
> +
>  #ifdef CONFIG_COMPAT
> 
>  long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
>   compat_ulong_t caddr, compat_ulong_t cdata)
>  {
> +#ifdef CONFIG_ARM64_ILP32
> + return compat_ilp32_ptrace(child, request, caddr, cdata);
> +#else
>   return compat_ptrace_request(child, request, caddr, cdata);
> +#endif
>  }
> 
>  #endif /* CONFIG_COMPAT */
> diff --git a/arch/arm64/kernel/signal_ilp32.c
> b/arch/arm64/kernel/signal_ilp32.c
> index 8ca64b9..3ef2749 100644
> --- a/arch/arm64/kernel/signal_ilp32.c
> +++ b/arch/arm64/kernel/signal_ilp32.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -58,28 +59,6 @@ struct ilp32_rt_sigframe {
>   struct ilp32_sigframe sig;
>  };
> 
> -static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t 

Re: undefined reference to `printk'

[Yoshinori Sato]

On Sun, 12 Jun 2016 13:38:10 +0900,
Josh Triplett wrote:
> 
> [Adding LKML, linux-arch, and Linus.]
> 
> On Sun, Jun 12, 2016 at 10:17:01AM +0800, kbuild test robot wrote:
> > All errors (new ones prefixed by >>):
> > 
> >arch/m32r/kernel/built-in.o: In function `default_eit_handler':
> > >> (.text+0x3f8): undefined reference to `printk'
> >arch/m32r/kernel/built-in.o: In function `default_eit_handler':
> >(.text+0x3f8): relocation truncated to fit: R_M32R_26_PCREL_RELA against 
> > undefined symbol `printk'
> 
> As far as I can tell, there has been a patch available for this for
> months, and it still doesn't seem to have been applied anywhere.
> 
> m32r is listed in MAINTAINERS as "Orphan", and has been since commit
> b4174867bee83e79dc155479cb1b67c452da6476 in 2014.  And that commit
> in turn observed no commits from the maintainer since 2009.  Looking at
> the log for arch/m32r, I don't see any activity other than random fixes
> by others, and based on the signoffs, all of those seem to go through
> miscellaneous trees.
> 
> Is anyone using m32r?  Is anyone willing to maintain it?  And if not,
> should we consider removing it?

I have m32r target.
So I can testing and housekeeping.
If I'm not in other ones, I work.

> - Josh Triplett
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Yoshinori Sato

Re: undefined reference to `printk'

[Yoshinori Sato]

On Sun, 12 Jun 2016 13:38:10 +0900,
Josh Triplett wrote:
> 
> [Adding LKML, linux-arch, and Linus.]
> 
> On Sun, Jun 12, 2016 at 10:17:01AM +0800, kbuild test robot wrote:
> > All errors (new ones prefixed by >>):
> > 
> >arch/m32r/kernel/built-in.o: In function `default_eit_handler':
> > >> (.text+0x3f8): undefined reference to `printk'
> >arch/m32r/kernel/built-in.o: In function `default_eit_handler':
> >(.text+0x3f8): relocation truncated to fit: R_M32R_26_PCREL_RELA against 
> > undefined symbol `printk'
> 
> As far as I can tell, there has been a patch available for this for
> months, and it still doesn't seem to have been applied anywhere.
> 
> m32r is listed in MAINTAINERS as "Orphan", and has been since commit
> b4174867bee83e79dc155479cb1b67c452da6476 in 2014.  And that commit
> in turn observed no commits from the maintainer since 2009.  Looking at
> the log for arch/m32r, I don't see any activity other than random fixes
> by others, and based on the signoffs, all of those seem to go through
> miscellaneous trees.
> 
> Is anyone using m32r?  Is anyone willing to maintain it?  And if not,
> should we consider removing it?

I have m32r target.
So I can testing and housekeeping.
If I'm not in other ones, I work.

> - Josh Triplett
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Yoshinori Sato

Re: [PATCH v3 2/2] phy: add a driver for the Rockchip SoC internal PCIe PHY

[Kishon Vijay Abraham I]

Hi,

On Friday 24 June 2016 05:07 AM, Brian Norris wrote:
> Hi,
> 
> On Thu, Jun 23, 2016 at 10:30:17AM +0800, Shawn Lin wrote:
>> 在 2016/6/20 14:36, Kishon Vijay Abraham I 写道:
>>> On Monday 20 June 2016 06:28 AM, Shawn Lin wrote:
 On 2016/6/17 21:08, Kishon Vijay Abraham I wrote:
> On Thursday 16 June 2016 06:52 AM, Shawn Lin wrote:
>> This patch to add a generic PHY driver for rockchip PCIe PHY.
>> Access the PHY via registers provided by GRF (general register
>> files) module.
>>
>> Signed-off-by: Shawn Lin 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
> [...]
>> diff --git a/drivers/phy/phy-rockchip-pcie.c 
>> b/drivers/phy/phy-rockchip-pcie.c
>> new file mode 100644
>> index 000..bc6cd17
>> --- /dev/null
>> +++ b/drivers/phy/phy-rockchip-pcie.c
>> @@ -0,0 +1,378 @@
> 
> [...]
> 
>> +void rockchip_pcie_phy_laneoff(struct phy *phy)
>> +{
>> +u32 status;
>> +struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
>> +int i;
>> +
>> +for (i = 0; i < PHY_MAX_LANE_NUM; i++) {
>> +status = phy_rd_cfg(rk_phy, PHY_LANE_A_STATUS + i);
>> +if (!((status >> PHY_LANE_RX_DET_SHIFT) &
>> +   PHY_LANE_RX_DET_TH))
>> +pr_debug("lane %d is used\n", i);
>> +else
>> +regmap_write(rk_phy->reg_base,
>> + rk_phy->phy_data->pcie_laneoff,
>> + HIWORD_UPDATE(PHY_LANE_IDLE_OFF,
>> +   PHY_LANE_IDLE_MASK,
>> +   PHY_LANE_IDLE_A_SHIFT + i));
>> +}
>> +}
>> +EXPORT_SYMBOL_GPL(rockchip_pcie_phy_laneoff);
> 
> Shawn, I can't find an example of how you planned to use this (though I
> can make educated guesses). As such, it's possible there's some
> misunderstanding. Maybe you can include a sample patch for the PCIe
> controller driver?
> 
> Related: it might make sense to have the PCIe controller and PHY
> drivers/bindings all in the same patch series (with proper threading,
> which we already talked about off-list).
> 
> Er.. don't use export symbols from phy driver. I think it would be nice 
> if you
> can model the driver in such a way that the PCIe driver can control 
> individual
> phy's.
>

 Yes, I was trying to look for a way not to export symbols from
 phy... But I failed to find it as there at least need three
 interaction between controller and phy which made me believe we
 at least need to export one symbol without adding new API for phy.
> 
> My interpretation of the above is that Shawn means we might turn off up
> to 3 different lanes (i.e., 3 of 4 supported lanes might be unused).
> 
>>> That can be managed by implementing a small state machine within the PHY 
>>> driver.
>>
>> I don't understand your point of implementing a small state machine
>> within the PHY driver.
> 
> I'm not 100% sure I understand, but I think I have a reasonable
> interpretation below.
> 
>> Do you mean I need to call vaarious of power_on/off and count the
>> on/off times to decide the state machine?
>>
>> I would appreciate it If you could elaborate this a bit more or
>> show me a example. :)
> 
> My interpretation: rather than associating a single PCIe controller
> device with a single struct phy that controls up to 4 lanes, Kishon is
> suggesting you should have this driver implement 4 phy objects, one for
> each lane. You'd need to add #phy-cells = <1> to the DT binding, and
> implement an ->of_xlate() hook so we can associate/address them
> properly. Then the PCIe controller would call phy_power_off() on each
> lane that's not used.
> 
> The state machine would come into play because you have additional power
> savings to utilize, but only when all PHYs are off. So the state machine
> would just track how many of the lane PHYs are still on, and when the
> count reaches 0, you call reset_control_assert(rk_phy->phy_rst).
> 
> The DT for this would be:
> 
>   pcie0: pcie@f800 {
>   compatible = "rockchip,rk3399-pcie";
>   ...
>   phys = <_phy 0>, <_phy 1>, <_phy 2>, <_phy 
> 3>;
>   phy-names = "pcie-lane0", "pcie-lane1", "pcie-lane2", 
> "pcie-lane3";
>   ...
>   };
> 
>   pcie_phy: pcie-phy {
>   compatible = "rockchip,rk3399-pcie-phy";
>   ...
>   #phy-cells = <1>;
>   ...
>   };
> 
> (See Documentation/devicetree/bindings/phy/phy-bindings.txt for the
> #phy-cells explanation.)
> 
> Is that close to what you're suggesting, Kishon? Seems reasonable enough
> to me, even if it's slightly more complicated.

That's pretty much what I had in mind. Thanks for putting this down in an
elaborate manner.

Thanks
Kishon

Re: [PATCH v3 2/2] phy: add a driver for the Rockchip SoC internal PCIe PHY

[Kishon Vijay Abraham I]

Hi,

On Friday 24 June 2016 05:07 AM, Brian Norris wrote:
> Hi,
> 
> On Thu, Jun 23, 2016 at 10:30:17AM +0800, Shawn Lin wrote:
>> 在 2016/6/20 14:36, Kishon Vijay Abraham I 写道:
>>> On Monday 20 June 2016 06:28 AM, Shawn Lin wrote:
 On 2016/6/17 21:08, Kishon Vijay Abraham I wrote:
> On Thursday 16 June 2016 06:52 AM, Shawn Lin wrote:
>> This patch to add a generic PHY driver for rockchip PCIe PHY.
>> Access the PHY via registers provided by GRF (general register
>> files) module.
>>
>> Signed-off-by: Shawn Lin 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
> [...]
>> diff --git a/drivers/phy/phy-rockchip-pcie.c 
>> b/drivers/phy/phy-rockchip-pcie.c
>> new file mode 100644
>> index 000..bc6cd17
>> --- /dev/null
>> +++ b/drivers/phy/phy-rockchip-pcie.c
>> @@ -0,0 +1,378 @@
> 
> [...]
> 
>> +void rockchip_pcie_phy_laneoff(struct phy *phy)
>> +{
>> +u32 status;
>> +struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
>> +int i;
>> +
>> +for (i = 0; i < PHY_MAX_LANE_NUM; i++) {
>> +status = phy_rd_cfg(rk_phy, PHY_LANE_A_STATUS + i);
>> +if (!((status >> PHY_LANE_RX_DET_SHIFT) &
>> +   PHY_LANE_RX_DET_TH))
>> +pr_debug("lane %d is used\n", i);
>> +else
>> +regmap_write(rk_phy->reg_base,
>> + rk_phy->phy_data->pcie_laneoff,
>> + HIWORD_UPDATE(PHY_LANE_IDLE_OFF,
>> +   PHY_LANE_IDLE_MASK,
>> +   PHY_LANE_IDLE_A_SHIFT + i));
>> +}
>> +}
>> +EXPORT_SYMBOL_GPL(rockchip_pcie_phy_laneoff);
> 
> Shawn, I can't find an example of how you planned to use this (though I
> can make educated guesses). As such, it's possible there's some
> misunderstanding. Maybe you can include a sample patch for the PCIe
> controller driver?
> 
> Related: it might make sense to have the PCIe controller and PHY
> drivers/bindings all in the same patch series (with proper threading,
> which we already talked about off-list).
> 
> Er.. don't use export symbols from phy driver. I think it would be nice 
> if you
> can model the driver in such a way that the PCIe driver can control 
> individual
> phy's.
>

 Yes, I was trying to look for a way not to export symbols from
 phy... But I failed to find it as there at least need three
 interaction between controller and phy which made me believe we
 at least need to export one symbol without adding new API for phy.
> 
> My interpretation of the above is that Shawn means we might turn off up
> to 3 different lanes (i.e., 3 of 4 supported lanes might be unused).
> 
>>> That can be managed by implementing a small state machine within the PHY 
>>> driver.
>>
>> I don't understand your point of implementing a small state machine
>> within the PHY driver.
> 
> I'm not 100% sure I understand, but I think I have a reasonable
> interpretation below.
> 
>> Do you mean I need to call vaarious of power_on/off and count the
>> on/off times to decide the state machine?
>>
>> I would appreciate it If you could elaborate this a bit more or
>> show me a example. :)
> 
> My interpretation: rather than associating a single PCIe controller
> device with a single struct phy that controls up to 4 lanes, Kishon is
> suggesting you should have this driver implement 4 phy objects, one for
> each lane. You'd need to add #phy-cells = <1> to the DT binding, and
> implement an ->of_xlate() hook so we can associate/address them
> properly. Then the PCIe controller would call phy_power_off() on each
> lane that's not used.
> 
> The state machine would come into play because you have additional power
> savings to utilize, but only when all PHYs are off. So the state machine
> would just track how many of the lane PHYs are still on, and when the
> count reaches 0, you call reset_control_assert(rk_phy->phy_rst).
> 
> The DT for this would be:
> 
>   pcie0: pcie@f800 {
>   compatible = "rockchip,rk3399-pcie";
>   ...
>   phys = <_phy 0>, <_phy 1>, <_phy 2>, <_phy 
> 3>;
>   phy-names = "pcie-lane0", "pcie-lane1", "pcie-lane2", 
> "pcie-lane3";
>   ...
>   };
> 
>   pcie_phy: pcie-phy {
>   compatible = "rockchip,rk3399-pcie-phy";
>   ...
>   #phy-cells = <1>;
>   ...
>   };
> 
> (See Documentation/devicetree/bindings/phy/phy-bindings.txt for the
> #phy-cells explanation.)
> 
> Is that close to what you're suggesting, Kishon? Seems reasonable enough
> to me, even if it's slightly more complicated.

That's pretty much what I had in mind. Thanks for putting this down in an
elaborate manner.

Thanks
Kishon

kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

[Andy Lutomirski]

My v4 series was doing pretty well until this explosion:

On Sun, Jun 26, 2016 at 9:41 PM, kernel test robot
 wrote:
>
>
> FYI, we noticed the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
> commit 26424589626d7f82d09d4e7c0569f9487b2e810a ("[DEBUG] force-enable 
> CONFIG_VMAP_STACK")
>

...

> [4.425052] BUG: unable to handle kernel paging request at c9997f18
> [4.426645] IP: [] _raw_spin_lock_irq+0x2c/0x3d
> [4.427869] PGD 1249e067 PUD 1249f067 PMD 11e4e067 PTE 0
> [4.429245] Oops: 0002 [#1] SMP
> [4.430086] Modules linked in:
> [4.430992] CPU: 0 PID: 1741 Comm: mount Not tainted 
> 4.7.0-rc4-00258-g26424589 #1
> [4.432727] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [4.434646] task: 88000d950c80 ti: 88000d950c80 task.ti: 
> 88000d950c80

Yeah, this line is meaningless with the thread_info cleanups, and I
have it fixed for v5.

> [4.436406] RIP: 0010:[]  [] 
> _raw_spin_lock_irq+0x2c/0x3d
> [4.438341] RSP: 0018:c9957c80  EFLAGS: 00010046
> [4.439438] RAX:  RBX: 7fff RCX: 
> 0a66
> [4.440735] RDX: 0001 RSI: 880013619bc0 RDI: 
> c9997f18
> [4.442035] RBP: c9957c88 R08: 00019bc0 R09: 
> 81200748
> [4.443323] R10: ea474900 R11: 0001a2a0 R12: 
> c9997f10
> [4.444614] R13: 0002 R14: c9997f18 R15: 
> ffea
> [4.445896] FS:  7f9ca6a32700() GS:88001360() 
> knlGS:
> [4.447690] CS:  0010 DS:  ES:  CR0: 80050033
> [4.448819] CR2: c9997f18 CR3: 0d87c000 CR4: 
> 06f0
> [4.450102] Stack:
> [4.450810]  c9997f18 c9957d00 81a982eb 
> 0246
> [4.452827]   c9957d00 8112584b 
> 
> [4.454838]  0246 88000e27f6bc  
> 88000e27f080
> [4.456845] Call Trace:
> [4.457616]  [] wait_for_common+0x44/0x197
> [4.458719]  [] ? try_to_wake_up+0x2dd/0x2ef
> [4.459877]  [] wait_for_completion+0x1d/0x1f
> [4.461027]  [] kthread_stop+0x82/0x10a
> [4.462125]  [] destroy_workqueue+0x10d/0x1cd
> [4.463347]  [] xfs_destroy_mount_workqueues+0x49/0x64
> [4.464620]  [] xfs_fs_fill_super+0x2c0/0x49c
> [4.465807]  [] mount_bdev+0x143/0x195
> [4.466937]  [] ? xfs_test_remount_options+0x5b/0x5b
> [4.468727]  [] xfs_fs_mount+0x15/0x17
> [4.469838]  [] mount_fs+0x15/0x8c
> [4.470882]  [] vfs_kern_mount+0x6a/0xfe
> [4.472005]  [] do_mount+0x985/0xa9a
> [4.473078]  [] ? strndup_user+0x3a/0x6a
> [4.474193]  [] SyS_mount+0x77/0x9f
> [4.475255]  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
> [4.476463] Code: 66 66 66 90 55 48 89 e5 50 48 89 7d f8 fa 66 66 90 66 66 
> 90 e8 2d 0a 70 ff 65 ff 05 73 18 57 7e 31 c0 ba 01 00 00 00 48 8b 7d f8  
> 0f b1 17 85 c0 74 07 89 c6 e8 3e 20 6a ff c9 c3 66 66 66 66
> [4.484413] RIP  [] _raw_spin_lock_irq+0x2c/0x3d
> [4.485639]  RSP 
> [4.486509] CR2: c9997f18
> [4.487366] ---[ end trace 79763b41869f2580 ]---
> [4.488367] Kernel panic - not syncing: Fatal exception
>

kthread_stop is *sick*.

struct kthread self;

...

current->vfork_done = 

...

do_exit(ret);

And then some other thread goes and waits for the completion, which is
*on the stack*, which, in any sane world (e.g. with my series
applied), is long gone by then.

But this is broken even without any changes: since when is gcc
guaranteed to preserve the stack contents when a function ends with a
sibling call, let alone with a __noreturn call?

Is there seriously no way to directly wait for a struct task_struct to
exit?  Could we, say, kmalloc the completion (or maybe even the whole
struct kthread) and (ick!) hang it off ->vfork_done?

Linus, maybe it's time for you to carve another wax figurine.

--Andy

kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)

[Andy Lutomirski]

My v4 series was doing pretty well until this explosion:

On Sun, Jun 26, 2016 at 9:41 PM, kernel test robot
 wrote:
>
>
> FYI, we noticed the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
> commit 26424589626d7f82d09d4e7c0569f9487b2e810a ("[DEBUG] force-enable 
> CONFIG_VMAP_STACK")
>

...

> [4.425052] BUG: unable to handle kernel paging request at c9997f18
> [4.426645] IP: [] _raw_spin_lock_irq+0x2c/0x3d
> [4.427869] PGD 1249e067 PUD 1249f067 PMD 11e4e067 PTE 0
> [4.429245] Oops: 0002 [#1] SMP
> [4.430086] Modules linked in:
> [4.430992] CPU: 0 PID: 1741 Comm: mount Not tainted 
> 4.7.0-rc4-00258-g26424589 #1
> [4.432727] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [4.434646] task: 88000d950c80 ti: 88000d950c80 task.ti: 
> 88000d950c80

Yeah, this line is meaningless with the thread_info cleanups, and I
have it fixed for v5.

> [4.436406] RIP: 0010:[]  [] 
> _raw_spin_lock_irq+0x2c/0x3d
> [4.438341] RSP: 0018:c9957c80  EFLAGS: 00010046
> [4.439438] RAX:  RBX: 7fff RCX: 
> 0a66
> [4.440735] RDX: 0001 RSI: 880013619bc0 RDI: 
> c9997f18
> [4.442035] RBP: c9957c88 R08: 00019bc0 R09: 
> 81200748
> [4.443323] R10: ea474900 R11: 0001a2a0 R12: 
> c9997f10
> [4.444614] R13: 0002 R14: c9997f18 R15: 
> ffea
> [4.445896] FS:  7f9ca6a32700() GS:88001360() 
> knlGS:
> [4.447690] CS:  0010 DS:  ES:  CR0: 80050033
> [4.448819] CR2: c9997f18 CR3: 0d87c000 CR4: 
> 06f0
> [4.450102] Stack:
> [4.450810]  c9997f18 c9957d00 81a982eb 
> 0246
> [4.452827]   c9957d00 8112584b 
> 
> [4.454838]  0246 88000e27f6bc  
> 88000e27f080
> [4.456845] Call Trace:
> [4.457616]  [] wait_for_common+0x44/0x197
> [4.458719]  [] ? try_to_wake_up+0x2dd/0x2ef
> [4.459877]  [] wait_for_completion+0x1d/0x1f
> [4.461027]  [] kthread_stop+0x82/0x10a
> [4.462125]  [] destroy_workqueue+0x10d/0x1cd
> [4.463347]  [] xfs_destroy_mount_workqueues+0x49/0x64
> [4.464620]  [] xfs_fs_fill_super+0x2c0/0x49c
> [4.465807]  [] mount_bdev+0x143/0x195
> [4.466937]  [] ? xfs_test_remount_options+0x5b/0x5b
> [4.468727]  [] xfs_fs_mount+0x15/0x17
> [4.469838]  [] mount_fs+0x15/0x8c
> [4.470882]  [] vfs_kern_mount+0x6a/0xfe
> [4.472005]  [] do_mount+0x985/0xa9a
> [4.473078]  [] ? strndup_user+0x3a/0x6a
> [4.474193]  [] SyS_mount+0x77/0x9f
> [4.475255]  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
> [4.476463] Code: 66 66 66 90 55 48 89 e5 50 48 89 7d f8 fa 66 66 90 66 66 
> 90 e8 2d 0a 70 ff 65 ff 05 73 18 57 7e 31 c0 ba 01 00 00 00 48 8b 7d f8  
> 0f b1 17 85 c0 74 07 89 c6 e8 3e 20 6a ff c9 c3 66 66 66 66
> [4.484413] RIP  [] _raw_spin_lock_irq+0x2c/0x3d
> [4.485639]  RSP 
> [4.486509] CR2: c9997f18
> [4.487366] ---[ end trace 79763b41869f2580 ]---
> [4.488367] Kernel panic - not syncing: Fatal exception
>

kthread_stop is *sick*.

struct kthread self;

...

current->vfork_done = 

...

do_exit(ret);

And then some other thread goes and waits for the completion, which is
*on the stack*, which, in any sane world (e.g. with my series
applied), is long gone by then.

But this is broken even without any changes: since when is gcc
guaranteed to preserve the stack contents when a function ends with a
sibling call, let alone with a __noreturn call?

Is there seriously no way to directly wait for a struct task_struct to
exit?  Could we, say, kmalloc the completion (or maybe even the whole
struct kthread) and (ick!) hang it off ->vfork_done?

Linus, maybe it's time for you to carve another wax figurine.

--Andy

Re: [RFC v4 0/7] extcon: usb-gpio: fixes and improvements

[Krzysztof Kozlowski]

On 06/26/2016 06:39 PM, Tobias Jakobi wrote:
> Hello Krzysztof,
> 
> just wanted to ask on which kernel branch the patchset is based on. At
> least for me the set doesn't apply cleanly to 4.7-rc4.

Hi,

It was based on next-20160608.

Best regards,
Krzysztof

Re: [RFC v4 0/7] extcon: usb-gpio: fixes and improvements

[Krzysztof Kozlowski]

On 06/26/2016 06:39 PM, Tobias Jakobi wrote:
> Hello Krzysztof,
> 
> just wanted to ask on which kernel branch the patchset is based on. At
> least for me the set doesn't apply cleanly to 4.7-rc4.

Hi,

It was based on next-20160608.

Best regards,
Krzysztof

Re: undefined reference to `printk'

[Yoshinori Sato]

I think fix it.
default_eit_handler rewritten in C, it is best way.
But it test difficult.

Signed-off-by: Yoshinori Sato 
---
 arch/m32r/kernel/entry.S | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/m32r/kernel/entry.S b/arch/m32r/kernel/entry.S
index c639bfa..a71105c 100644
--- a/arch/m32r/kernel/entry.S
+++ b/arch/m32r/kernel/entry.S
@@ -419,6 +419,12 @@ ENTRY(default_eit_handler)
 infinit:
bra infinit
 
+#ifndef CONFIG_PRINTK
+printk:
+   jmp lr
+   .fillinsn
+#endif
+
 #ifdef CONFIG_ MMU
 /*
  * Access Exception handler
2.7.0

On Sun, 26 Jun 2016 10:19:50 +0900,
kbuild test robot wrote:
> 
> Hi,
> 
> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   da2f6aba4a21f8da3331e5251a117c52764da579
> commit: 5d2acfc7b974bbd3858b4dd3f2cdc6362dd8843a kconfig: make allnoconfig 
> disable options behind EMBEDDED and EXPERT
> date:   2 years, 3 months ago
> config: m32r-allnoconfig (attached as .config)
> compiler: m32r-linux-gcc (GCC) 4.9.0
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 5d2acfc7b974bbd3858b4dd3f2cdc6362dd8843a
> # save the attached .config to linux build tree
> make.cross ARCH=m32r 
> 
> All errors (new ones prefixed by >>):
> 
>arch/m32r/kernel/built-in.o: In function `default_eit_handler':
> >> (.text+0x3f8): undefined reference to `printk'
>arch/m32r/kernel/built-in.o: In function `default_eit_handler':
>(.text+0x3f8): relocation truncated to fit: R_M32R_26_PCREL_RELA against 
> undefined symbol `printk'
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

-- 
Yoshinori Sato

Re: undefined reference to `printk'

[Yoshinori Sato]

I think fix it.
default_eit_handler rewritten in C, it is best way.
But it test difficult.

Signed-off-by: Yoshinori Sato 
---
 arch/m32r/kernel/entry.S | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/m32r/kernel/entry.S b/arch/m32r/kernel/entry.S
index c639bfa..a71105c 100644
--- a/arch/m32r/kernel/entry.S
+++ b/arch/m32r/kernel/entry.S
@@ -419,6 +419,12 @@ ENTRY(default_eit_handler)
 infinit:
bra infinit
 
+#ifndef CONFIG_PRINTK
+printk:
+   jmp lr
+   .fillinsn
+#endif
+
 #ifdef CONFIG_ MMU
 /*
  * Access Exception handler
2.7.0

On Sun, 26 Jun 2016 10:19:50 +0900,
kbuild test robot wrote:
> 
> Hi,
> 
> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   da2f6aba4a21f8da3331e5251a117c52764da579
> commit: 5d2acfc7b974bbd3858b4dd3f2cdc6362dd8843a kconfig: make allnoconfig 
> disable options behind EMBEDDED and EXPERT
> date:   2 years, 3 months ago
> config: m32r-allnoconfig (attached as .config)
> compiler: m32r-linux-gcc (GCC) 4.9.0
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 5d2acfc7b974bbd3858b4dd3f2cdc6362dd8843a
> # save the attached .config to linux build tree
> make.cross ARCH=m32r 
> 
> All errors (new ones prefixed by >>):
> 
>arch/m32r/kernel/built-in.o: In function `default_eit_handler':
> >> (.text+0x3f8): undefined reference to `printk'
>arch/m32r/kernel/built-in.o: In function `default_eit_handler':
>(.text+0x3f8): relocation truncated to fit: R_M32R_26_PCREL_RELA against 
> undefined symbol `printk'
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

-- 
Yoshinori Sato

[PATCH net-next 6/6] r8152: add byte_enable for ocp_read_word function

[Hayes Wang]

Add byte_enable for ocp_read_word() to replace reading 4 bytes data
with reading the desired 2 bytes data.

This is used to avoid the issue which is described in commit:b4d99def.
The origin method always reads 4 bytes data, and it may have problem
when reading the PHY regiters.

The new method is supported since RTL8152B, but it doesn't influence
the previous chips. The bits of the byte_enable for the previous chips
are the reserved bits, and the hw would ignore them.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2fd4944..0bb7c1b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -945,11 +945,13 @@ static u16 ocp_read_word(struct r8152 *tp, u16 type, u16 
index)
 {
u32 data;
__le32 tmp;
+   u16 byen = BYTE_EN_WORD;
u8 shift = index & 2;
 
index &= ~3;
+   byen <<= shift;
 
-   generic_ocp_read(tp, index, sizeof(tmp), , type);
+   generic_ocp_read(tp, index, sizeof(tmp), , type | byen);
 
data = __le32_to_cpu(tmp);
data >>= (shift * 8);
-- 
2.4.11

[PATCH net-next 6/6] r8152: add byte_enable for ocp_read_word function

[Hayes Wang]

Add byte_enable for ocp_read_word() to replace reading 4 bytes data
with reading the desired 2 bytes data.

This is used to avoid the issue which is described in commit:b4d99def.
The origin method always reads 4 bytes data, and it may have problem
when reading the PHY regiters.

The new method is supported since RTL8152B, but it doesn't influence
the previous chips. The bits of the byte_enable for the previous chips
are the reserved bits, and the hw would ignore them.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2fd4944..0bb7c1b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -945,11 +945,13 @@ static u16 ocp_read_word(struct r8152 *tp, u16 type, u16 
index)
 {
u32 data;
__le32 tmp;
+   u16 byen = BYTE_EN_WORD;
u8 shift = index & 2;
 
index &= ~3;
+   byen <<= shift;
 
-   generic_ocp_read(tp, index, sizeof(tmp), , type);
+   generic_ocp_read(tp, index, sizeof(tmp), , type | byen);
 
data = __le32_to_cpu(tmp);
data >>= (shift * 8);
-- 
2.4.11

[PATCH net-next 1/6] r8152: add aldps_enable for rtl_ops

[Hayes Wang]

Add aldps_enable() for rtl_ops.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 11178f9..b253003 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -619,6 +619,7 @@ struct r8152 {
int (*eee_get)(struct r8152 *, struct ethtool_eee *);
int (*eee_set)(struct r8152 *, struct ethtool_eee *);
bool (*in_nway)(struct r8152 *);
+   void (*aldps_enable)(struct r8152 *tp, bool enable);
void (*hw_phy_cfg)(struct r8152 *);
} rtl_ops;
 
@@ -2474,9 +2475,9 @@ static void r8152_aldps_en(struct r8152 *tp, bool enable)
 
 static void rtl8152_disable(struct r8152 *tp)
 {
-   r8152_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
rtl_disable(tp);
-   r8152_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
 }
 
 static void r8152b_hw_phy_cfg(struct r8152 *tp)
@@ -2801,9 +2802,7 @@ static void r8153_aldps_en(struct r8152 *tp, bool enable)
 
 static void rtl8153_disable(struct r8152 *tp)
 {
-   r8153_aldps_en(tp, false);
-   rtl_disable(tp);
-   r8153_aldps_en(tp, true);
+   rtl8152_disable(tp);
usb_enable_lpm(tp->udev);
 }
 
@@ -2924,9 +2923,9 @@ static void rtl8153_up(struct r8152 *tp)
return;
 
r8153_u1u2en(tp, false);
-   r8153_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
r8153_first_init(tp);
-   r8153_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
r8153_u2p3en(tp, true);
r8153_u1u2en(tp, true);
usb_enable_lpm(tp->udev);
@@ -2942,9 +2941,9 @@ static void rtl8153_down(struct r8152 *tp)
r8153_u1u2en(tp, false);
r8153_u2p3en(tp, false);
r8153_power_cut_en(tp, false);
-   r8153_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
r8153_enter_oob(tp);
-   r8153_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
 }
 
 static bool rtl8152_in_nway(struct r8152 *tp)
@@ -4142,6 +4141,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->eee_get= r8152_get_eee;
ops->eee_set= r8152_set_eee;
ops->in_nway= rtl8152_in_nway;
+   ops->aldps_enable   = r8152_aldps_en;
ops->hw_phy_cfg = r8152b_hw_phy_cfg;
break;
 
@@ -4158,6 +4158,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->eee_get= r8153_get_eee;
ops->eee_set= r8153_set_eee;
ops->in_nway= rtl8153_in_nway;
+   ops->aldps_enable   = r8153_aldps_en;
ops->hw_phy_cfg = r8153_hw_phy_cfg;
break;
 
-- 
2.4.11

[PATCH net-next 1/6] r8152: add aldps_enable for rtl_ops

[Hayes Wang]

Add aldps_enable() for rtl_ops.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 11178f9..b253003 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -619,6 +619,7 @@ struct r8152 {
int (*eee_get)(struct r8152 *, struct ethtool_eee *);
int (*eee_set)(struct r8152 *, struct ethtool_eee *);
bool (*in_nway)(struct r8152 *);
+   void (*aldps_enable)(struct r8152 *tp, bool enable);
void (*hw_phy_cfg)(struct r8152 *);
} rtl_ops;
 
@@ -2474,9 +2475,9 @@ static void r8152_aldps_en(struct r8152 *tp, bool enable)
 
 static void rtl8152_disable(struct r8152 *tp)
 {
-   r8152_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
rtl_disable(tp);
-   r8152_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
 }
 
 static void r8152b_hw_phy_cfg(struct r8152 *tp)
@@ -2801,9 +2802,7 @@ static void r8153_aldps_en(struct r8152 *tp, bool enable)
 
 static void rtl8153_disable(struct r8152 *tp)
 {
-   r8153_aldps_en(tp, false);
-   rtl_disable(tp);
-   r8153_aldps_en(tp, true);
+   rtl8152_disable(tp);
usb_enable_lpm(tp->udev);
 }
 
@@ -2924,9 +2923,9 @@ static void rtl8153_up(struct r8152 *tp)
return;
 
r8153_u1u2en(tp, false);
-   r8153_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
r8153_first_init(tp);
-   r8153_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
r8153_u2p3en(tp, true);
r8153_u1u2en(tp, true);
usb_enable_lpm(tp->udev);
@@ -2942,9 +2941,9 @@ static void rtl8153_down(struct r8152 *tp)
r8153_u1u2en(tp, false);
r8153_u2p3en(tp, false);
r8153_power_cut_en(tp, false);
-   r8153_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
r8153_enter_oob(tp);
-   r8153_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
 }
 
 static bool rtl8152_in_nway(struct r8152 *tp)
@@ -4142,6 +4141,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->eee_get= r8152_get_eee;
ops->eee_set= r8152_set_eee;
ops->in_nway= rtl8152_in_nway;
+   ops->aldps_enable   = r8152_aldps_en;
ops->hw_phy_cfg = r8152b_hw_phy_cfg;
break;
 
@@ -4158,6 +4158,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->eee_get= r8153_get_eee;
ops->eee_set= r8153_set_eee;
ops->in_nway= rtl8153_in_nway;
+   ops->aldps_enable   = r8153_aldps_en;
ops->hw_phy_cfg = r8153_hw_phy_cfg;
break;
 
-- 
2.4.11

Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt generation

[Pratyush Anand]

On 21/06/2016:10:25:34 AM, Pratyush Anand wrote:
> We have observed on few machines with rtc-cmos device that
> hpet_rtc_interrupt() is called before cmos_do_probe() could call
> hpet_rtc_timer_init(). It has not been observed during normal boot/reboot
> of machines. It *sometime* happens when system is booted with kdump
> secondary kernel. So, neither hpet_default_delta nor hpet_t1_cmp is
> initialized by the time interrupt is raised in the given situation.
> Therefore while loop of hpet_cnt_ahead() in hpet_rtc_timer_reinit() never
> completes. This leads to "NMI watchdog: Watchdog detected hard LOCKUP on
> cpu 0".
> 
> I am still clueless, how can an interrupt be raised before RTC is enabled.
> But i do not have any idea about this device, so I am putting this patch as
> RFC to get feedback from hpet/rtc-cmos developer. I am sure there would be
> some better solution than this.

Do you think that if I improve commit log of patches as pointed by Thomas and
send a formal version of these patches, then they should acceptable to upstream?

Thanks

~Pratyush
> 
> 
> 
> Pratyush Anand (2):
>   rtc/hpet: Factorize hpet_rtc_timer_init()
>   rtc/rtc-cmos: Initialize software counters before irq is registered
> 
>  arch/x86/include/asm/hpet.h |  2 ++
>  arch/x86/kernel/hpet.c  | 41 +++--
>  drivers/rtc/rtc-cmos.c  | 13 -
>  3 files changed, 49 insertions(+), 7 deletions(-)
> 
> -- 
> 2.5.5

Re: [PATCH RFC 0/2] rtc-cmos: Workaround unwanted interrupt generation

[Pratyush Anand]

On 21/06/2016:10:25:34 AM, Pratyush Anand wrote:
> We have observed on few machines with rtc-cmos device that
> hpet_rtc_interrupt() is called before cmos_do_probe() could call
> hpet_rtc_timer_init(). It has not been observed during normal boot/reboot
> of machines. It *sometime* happens when system is booted with kdump
> secondary kernel. So, neither hpet_default_delta nor hpet_t1_cmp is
> initialized by the time interrupt is raised in the given situation.
> Therefore while loop of hpet_cnt_ahead() in hpet_rtc_timer_reinit() never
> completes. This leads to "NMI watchdog: Watchdog detected hard LOCKUP on
> cpu 0".
> 
> I am still clueless, how can an interrupt be raised before RTC is enabled.
> But i do not have any idea about this device, so I am putting this patch as
> RFC to get feedback from hpet/rtc-cmos developer. I am sure there would be
> some better solution than this.

Do you think that if I improve commit log of patches as pointed by Thomas and
send a formal version of these patches, then they should acceptable to upstream?

Thanks

~Pratyush
> 
> 
> 
> Pratyush Anand (2):
>   rtc/hpet: Factorize hpet_rtc_timer_init()
>   rtc/rtc-cmos: Initialize software counters before irq is registered
> 
>  arch/x86/include/asm/hpet.h |  2 ++
>  arch/x86/kernel/hpet.c  | 41 +++--
>  drivers/rtc/rtc-cmos.c  | 13 -
>  3 files changed, 49 insertions(+), 7 deletions(-)
> 
> -- 
> 2.5.5

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

[Eric Dumazet]

On Mon, 2016-06-27 at 11:46 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/sch_netem.c
> 
> between commit:
> 
>   21de12ee5568 ("netem: fix a use after free")
> 
> from the net tree and commit:
> 
>   520ac30f4551 ("net_sched: drop packets after root qdisc lock is released")
> 
> 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.
> 

Looks good, although the 'use after free' does not happen anymore on
net-next since we defer skb freeing.

I spotted the bug in stable tree when cooking the net-next patch
actually ;)

Thanks.

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

[Eric Dumazet]

On Mon, 2016-06-27 at 11:46 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/sch_netem.c
> 
> between commit:
> 
>   21de12ee5568 ("netem: fix a use after free")
> 
> from the net tree and commit:
> 
>   520ac30f4551 ("net_sched: drop packets after root qdisc lock is released")
> 
> 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.
> 

Looks good, although the 'use after free' does not happen anymore on
net-next since we defer skb freeing.

I spotted the bug in stable tree when cooking the net-next patch
actually ;)

Thanks.

Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

[kbuild test robot]

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb 
ci-for-usb-next
config: arm-multi_v5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `ci_hdrc_msm_remove':
>> drivers/usb/chipidea/ci_hdrc_msm.c:275: undefined reference to 
>> `reset_controller_unregister'

vim +275 drivers/usb/chipidea/ci_hdrc_msm.c

   269  
   270  pm_runtime_put(>dev);
   271  pm_runtime_disable(>dev);
   272  ci_hdrc_remove_device(ci->ci);
   273  clk_disable_unprepare(ci->iface_clk);
   274  clk_disable_unprepare(ci->core_clk);
 > 275  reset_controller_unregister(>rcdev);
   276  
   277  return 0;
   278  }

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


.config.gz
Description: Binary data

Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

[kbuild test robot]

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb 
ci-for-usb-next
config: arm-multi_v5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `ci_hdrc_msm_remove':
>> drivers/usb/chipidea/ci_hdrc_msm.c:275: undefined reference to 
>> `reset_controller_unregister'

vim +275 drivers/usb/chipidea/ci_hdrc_msm.c

   269  
   270  pm_runtime_put(>dev);
   271  pm_runtime_disable(>dev);
   272  ci_hdrc_remove_device(ci->ci);
   273  clk_disable_unprepare(ci->iface_clk);
   274  clk_disable_unprepare(ci->core_clk);
 > 275  reset_controller_unregister(>rcdev);
   276  
   277  return 0;
   278  }

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


.config.gz
Description: Binary data

[PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace

[zhouchengming]

The function compat_ptrace_request(used by ilp32) don't handle
{GET,SET}SIGMASK request, so it will be handled by ptrace_request.
But it's wrong because the compat_sigset_t of ilp32 differs from
the sigset_t of aarch64. The patch fixes it.

Signed-off-by: Zhou Chengming 
---
 arch/arm64/include/asm/signal_ilp32.h |   22 
 arch/arm64/kernel/ptrace.c|   62 
+

 arch/arm64/kernel/signal_ilp32.c  |   23 +
 3 files changed, 85 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/include/asm/signal_ilp32.h 
b/arch/arm64/include/asm/signal_ilp32.h

index 30eff23..ed52607 100644
--- a/arch/arm64/include/asm/signal_ilp32.h
+++ b/arch/arm64/include/asm/signal_ilp32.h
@@ -21,6 +21,28 @@
 int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
  struct pt_regs *regs);

+static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t *set)
+{
+   compat_sigset_t cset;
+
+   cset.sig[0] = set->sig[0] & 0xull;
+   cset.sig[1] = set->sig[0] >> 32;
+
+   return copy_to_user(uset, , sizeof(*uset));
+}
+
+static inline int get_sigset_t(sigset_t *set,
+  const compat_sigset_t __user *uset)
+{
+   compat_sigset_t s32;
+
+   if (copy_from_user(, uset, sizeof(*uset)))
+   return -EFAULT;
+
+   set->sig[0] = s32.sig[0] | (((long)s32.sig[1]) << 32);
+   return 0;
+}
+
 #else

 static inline int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, 
sigset_t *set,

diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index a861105..8d4cad1 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 

 #define CREATE_TRACE_POINTS
 #include 
@@ -1231,12 +1232,73 @@ COMPAT_SYSCALL_DEFINE4(aarch32_ptrace, 
compat_long_t, request, compat_long_t, pi


 #endif /* CONFIG_AARCH32_EL0 */

+#ifdef CONFIG_ARM64_ILP32
+
+static int compat_ilp32_ptrace(struct task_struct *child, compat_long_t 
request,

+   compat_ulong_t addr, compat_ulong_t data)
+{
+   compat_ulong_t __user *datap = compat_ptr(data);
+   int ret;
+
+   switch (request) {
+   case PTRACE_GETSIGMASK:
+   if (addr != sizeof(compat_sigset_t)) {
+   ret = -EINVAL;
+   break;
+   }
+
+   if (put_sigset_t((compat_sigset_t __user *)datap, 
>blocked))
+   ret = -EFAULT;
+   else
+   ret = 0;
+   break;
+
+   case PTRACE_SETSIGMASK: {
+   sigset_t new_set;
+   if (addr != sizeof(compat_sigset_t)) {
+   ret = -EINVAL;
+   break;
+   }
+
+   if (get_sigset_t(_set, (compat_sigset_t __user *)datap)) {
+   ret = -EFAULT;
+   break;
+   }
+
+   sigdelsetmask(_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
+
+   /*
+* Every thread does recalc_sigpending() after resume, so
+* retarget_shared_pending() and recalc_sigpending() are not
+* called here.
+*/
+   spin_lock_irq(>sighand->siglock);
+   child->blocked = new_set;
+   spin_unlock_irq(>sighand->siglock);
+
+   ret = 0;
+   break;
+   }
+
+   default:
+   ret = compat_ptrace_request(child, request, addr, data);
+   }
+
+   return ret;
+}
+
+#endif /* CONFIG_ARM64_ILP32 */
+
 #ifdef CONFIG_COMPAT

 long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
 {
+#ifdef CONFIG_ARM64_ILP32
+   return compat_ilp32_ptrace(child, request, caddr, cdata);
+#else
return compat_ptrace_request(child, request, caddr, cdata);
+#endif
 }

 #endif /* CONFIG_COMPAT */
diff --git a/arch/arm64/kernel/signal_ilp32.c 
b/arch/arm64/kernel/signal_ilp32.c

index 8ca64b9..3ef2749 100644
--- a/arch/arm64/kernel/signal_ilp32.c
+++ b/arch/arm64/kernel/signal_ilp32.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,28 +59,6 @@ struct ilp32_rt_sigframe {
struct ilp32_sigframe sig;
 };

-static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t *set)
-{
-   compat_sigset_t cset;
-
-   cset.sig[0] = set->sig[0] & 0xull;
-   cset.sig[1] = set->sig[0] >> 32;
-
-   return copy_to_user(uset, , sizeof(*uset));
-}
-
-static inline int get_sigset_t(sigset_t *set,
-   const compat_sigset_t __user *uset)
-{
-   compat_sigset_t s32;
-
-   if (copy_from_user(, uset, sizeof(*uset)))
-   return -EFAULT;
-
-   set->sig[0] = s32.sig[0] | 

[PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace

[zhouchengming]

The function compat_ptrace_request(used by ilp32) don't handle
{GET,SET}SIGMASK request, so it will be handled by ptrace_request.
But it's wrong because the compat_sigset_t of ilp32 differs from
the sigset_t of aarch64. The patch fixes it.

Signed-off-by: Zhou Chengming 
---
 arch/arm64/include/asm/signal_ilp32.h |   22 
 arch/arm64/kernel/ptrace.c|   62 
+

 arch/arm64/kernel/signal_ilp32.c  |   23 +
 3 files changed, 85 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/include/asm/signal_ilp32.h 
b/arch/arm64/include/asm/signal_ilp32.h

index 30eff23..ed52607 100644
--- a/arch/arm64/include/asm/signal_ilp32.h
+++ b/arch/arm64/include/asm/signal_ilp32.h
@@ -21,6 +21,28 @@
 int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
  struct pt_regs *regs);

+static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t *set)
+{
+   compat_sigset_t cset;
+
+   cset.sig[0] = set->sig[0] & 0xull;
+   cset.sig[1] = set->sig[0] >> 32;
+
+   return copy_to_user(uset, , sizeof(*uset));
+}
+
+static inline int get_sigset_t(sigset_t *set,
+  const compat_sigset_t __user *uset)
+{
+   compat_sigset_t s32;
+
+   if (copy_from_user(, uset, sizeof(*uset)))
+   return -EFAULT;
+
+   set->sig[0] = s32.sig[0] | (((long)s32.sig[1]) << 32);
+   return 0;
+}
+
 #else

 static inline int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, 
sigset_t *set,

diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index a861105..8d4cad1 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 

 #define CREATE_TRACE_POINTS
 #include 
@@ -1231,12 +1232,73 @@ COMPAT_SYSCALL_DEFINE4(aarch32_ptrace, 
compat_long_t, request, compat_long_t, pi


 #endif /* CONFIG_AARCH32_EL0 */

+#ifdef CONFIG_ARM64_ILP32
+
+static int compat_ilp32_ptrace(struct task_struct *child, compat_long_t 
request,

+   compat_ulong_t addr, compat_ulong_t data)
+{
+   compat_ulong_t __user *datap = compat_ptr(data);
+   int ret;
+
+   switch (request) {
+   case PTRACE_GETSIGMASK:
+   if (addr != sizeof(compat_sigset_t)) {
+   ret = -EINVAL;
+   break;
+   }
+
+   if (put_sigset_t((compat_sigset_t __user *)datap, 
>blocked))
+   ret = -EFAULT;
+   else
+   ret = 0;
+   break;
+
+   case PTRACE_SETSIGMASK: {
+   sigset_t new_set;
+   if (addr != sizeof(compat_sigset_t)) {
+   ret = -EINVAL;
+   break;
+   }
+
+   if (get_sigset_t(_set, (compat_sigset_t __user *)datap)) {
+   ret = -EFAULT;
+   break;
+   }
+
+   sigdelsetmask(_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
+
+   /*
+* Every thread does recalc_sigpending() after resume, so
+* retarget_shared_pending() and recalc_sigpending() are not
+* called here.
+*/
+   spin_lock_irq(>sighand->siglock);
+   child->blocked = new_set;
+   spin_unlock_irq(>sighand->siglock);
+
+   ret = 0;
+   break;
+   }
+
+   default:
+   ret = compat_ptrace_request(child, request, addr, data);
+   }
+
+   return ret;
+}
+
+#endif /* CONFIG_ARM64_ILP32 */
+
 #ifdef CONFIG_COMPAT

 long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
 {
+#ifdef CONFIG_ARM64_ILP32
+   return compat_ilp32_ptrace(child, request, caddr, cdata);
+#else
return compat_ptrace_request(child, request, caddr, cdata);
+#endif
 }

 #endif /* CONFIG_COMPAT */
diff --git a/arch/arm64/kernel/signal_ilp32.c 
b/arch/arm64/kernel/signal_ilp32.c

index 8ca64b9..3ef2749 100644
--- a/arch/arm64/kernel/signal_ilp32.c
+++ b/arch/arm64/kernel/signal_ilp32.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,28 +59,6 @@ struct ilp32_rt_sigframe {
struct ilp32_sigframe sig;
 };

-static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t *set)
-{
-   compat_sigset_t cset;
-
-   cset.sig[0] = set->sig[0] & 0xull;
-   cset.sig[1] = set->sig[0] >> 32;
-
-   return copy_to_user(uset, , sizeof(*uset));
-}
-
-static inline int get_sigset_t(sigset_t *set,
-   const compat_sigset_t __user *uset)
-{
-   compat_sigset_t s32;
-
-   if (copy_from_user(, uset, sizeof(*uset)))
-   return -EFAULT;
-
-   set->sig[0] = s32.sig[0] | (((long)s32.sig[1]) << 32);
-   return 

[PATCH] [perf]: update makefile message for installing required libs

[neerajbadlani]

From: Neeraj Badlani 

In case of missing library (libslang), give hint to install library 
(libslang2-dev)
Since libslang-dev is not provided by Ubuntu's apt-package
---
 tools/perf/config/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 5ad0255..e57d4d7 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -437,7 +437,7 @@ endif
 
 ifndef NO_SLANG
   ifneq ($(feature-libslang), 1)
-msg := $(warning slang not found, disables TUI support. Please install 
slang-devel or libslang-dev);
+msg := $(warning slang not found, disables TUI support. Please install 
slang-devel or libslang-dev or libslang2-dev);
 NO_SLANG := 1
   else
 # Fedora has /usr/include/slang/slang.h, but ubuntu /usr/include/slang.h
-- 
2.7.4

[PATCH] [perf]: update makefile message for installing required libs

[neerajbadlani]

From: Neeraj Badlani 

In case of missing library (libslang), give hint to install library 
(libslang2-dev)
Since libslang-dev is not provided by Ubuntu's apt-package
---
 tools/perf/config/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 5ad0255..e57d4d7 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -437,7 +437,7 @@ endif
 
 ifndef NO_SLANG
   ifneq ($(feature-libslang), 1)
-msg := $(warning slang not found, disables TUI support. Please install 
slang-devel or libslang-dev);
+msg := $(warning slang not found, disables TUI support. Please install 
slang-devel or libslang-dev or libslang2-dev);
 NO_SLANG := 1
   else
 # Fedora has /usr/include/slang/slang.h, but ubuntu /usr/include/slang.h
-- 
2.7.4

Re: [PATCH 12/19] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

[zhouchengming]

The {GET,SET}SIGMASK request of ptrace on ilp32 is wrong, it's handled
by ptrace_request(like aarch64). So I write a patch to fix it(just for
ilp32). I will send the patch next.

Thanks!

On 2016/6/18 7:54, Yury Norov wrote:

Here new aarch32 ptrace syscall handler is introsuced to avoid run-time
detection of the task type.

Signed-off-by: Yury Norov
---
  arch/arm64/include/asm/unistd32.h |  2 +-
  arch/arm64/kernel/ptrace.c| 50 ++-
  arch/arm64/kernel/sys32.c |  1 +
  include/linux/ptrace.h|  6 +
  kernel/ptrace.c   | 10 
  5 files changed, 62 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index b7e8ef1..6da7cbd 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -74,7 +74,7 @@ __SYSCALL(__NR_getuid, sys_getuid16)
/* 25 was sys_stime */
  __SYSCALL(25, sys_ni_syscall)
  #define __NR_ptrace 26
-__SYSCALL(__NR_ptrace, compat_sys_ptrace)
+__SYSCALL(__NR_ptrace, compat_sys_aarch32_ptrace)
/* 27 was sys_alarm */
  __SYSCALL(27, sys_ni_syscall)
/* 28 was sys_fstat */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 38a09338..a861105 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -29,6 +29,7 @@
  #include
  #include
  #include
+#include
  #include
  #include
  #include
@@ -1114,7 +1115,7 @@ static int compat_ptrace_sethbpregs(struct task_struct 
*tsk, compat_long_t num,
  }
  #endif/* CONFIG_HAVE_HW_BREAKPOINT */

-long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
+static long compat_a32_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
  {
unsigned long addr = caddr;
@@ -1191,8 +1192,55 @@ long compat_arch_ptrace(struct task_struct *child, 
compat_long_t request,

return ret;
  }
+
+COMPAT_SYSCALL_DEFINE4(aarch32_ptrace, compat_long_t, request, compat_long_t, 
pid,
+  compat_long_t, addr, compat_long_t, data)
+{
+   struct task_struct *child;
+   long ret;
+
+   if (request == PTRACE_TRACEME) {
+   ret = ptrace_traceme();
+   goto out;
+   }
+
+   child = ptrace_get_task_struct(pid);
+   if (IS_ERR(child)) {
+   ret = PTR_ERR(child);
+   goto out;
+   }
+
+   if (request == PTRACE_ATTACH || request == PTRACE_SEIZE) {
+   ret = ptrace_attach(child, request, addr, data);
+   goto out_put_task_struct;
+   }
+
+   ret = ptrace_check_attach(child, request == PTRACE_KILL ||
+ request == PTRACE_INTERRUPT);
+   if (!ret) {
+   ret = compat_a32_ptrace(child, request, addr, data);
+   if (ret || request != PTRACE_DETACH)
+   ptrace_unfreeze_traced(child);
+   }
+
+ out_put_task_struct:
+   put_task_struct(child);
+ out:
+   return ret;
+}
+
  #endif /* CONFIG_AARCH32_EL0 */

+#ifdef CONFIG_COMPAT
+
+long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
+   compat_ulong_t caddr, compat_ulong_t cdata)
+{
+   return compat_ptrace_request(child, request, caddr, cdata);
+}
+
+#endif /* CONFIG_COMPAT */
+
  const struct user_regset_view *task_user_regset_view(struct task_struct *task)
  {
  #ifdef CONFIG_AARCH32_EL0
diff --git a/arch/arm64/kernel/sys32.c b/arch/arm64/kernel/sys32.c
index a40b134..3752443 100644
--- a/arch/arm64/kernel/sys32.c
+++ b/arch/arm64/kernel/sys32.c
@@ -38,6 +38,7 @@ asmlinkage long compat_sys_fadvise64_64_wrapper(void);
  asmlinkage long compat_sys_sync_file_range2_wrapper(void);
  asmlinkage long compat_sys_fallocate_wrapper(void);
  asmlinkage long compat_sys_mmap2_wrapper(void);
+asmlinkage long compat_sys_aarch32_ptrace(void);

  #undef __SYSCALL
  #define __SYSCALL(nr, sym)[nr] = sym,
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 504c98a..75887a0 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -97,6 +97,12 @@ int generic_ptrace_peekdata(struct task_struct *tsk, 
unsigned long addr,
unsigned long data);
  int generic_ptrace_pokedata(struct task_struct *tsk, unsigned long addr,
unsigned long data);
+int ptrace_traceme(void);
+struct task_struct *ptrace_get_task_struct(pid_t pid);
+int ptrace_attach(struct task_struct *task, long request,
+unsigned long addr, unsigned long flags);
+int ptrace_check_attach(struct task_struct *child, bool ignore_state);
+void ptrace_unfreeze_traced(struct task_struct *task);

  /**
   * ptrace_parent - return the task that is tracing the given task
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 

Re: [PATCH 12/19] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

[zhouchengming]

The {GET,SET}SIGMASK request of ptrace on ilp32 is wrong, it's handled
by ptrace_request(like aarch64). So I write a patch to fix it(just for
ilp32). I will send the patch next.

Thanks!

On 2016/6/18 7:54, Yury Norov wrote:

Here new aarch32 ptrace syscall handler is introsuced to avoid run-time
detection of the task type.

Signed-off-by: Yury Norov
---
  arch/arm64/include/asm/unistd32.h |  2 +-
  arch/arm64/kernel/ptrace.c| 50 ++-
  arch/arm64/kernel/sys32.c |  1 +
  include/linux/ptrace.h|  6 +
  kernel/ptrace.c   | 10 
  5 files changed, 62 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index b7e8ef1..6da7cbd 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -74,7 +74,7 @@ __SYSCALL(__NR_getuid, sys_getuid16)
/* 25 was sys_stime */
  __SYSCALL(25, sys_ni_syscall)
  #define __NR_ptrace 26
-__SYSCALL(__NR_ptrace, compat_sys_ptrace)
+__SYSCALL(__NR_ptrace, compat_sys_aarch32_ptrace)
/* 27 was sys_alarm */
  __SYSCALL(27, sys_ni_syscall)
/* 28 was sys_fstat */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 38a09338..a861105 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -29,6 +29,7 @@
  #include
  #include
  #include
+#include
  #include
  #include
  #include
@@ -1114,7 +1115,7 @@ static int compat_ptrace_sethbpregs(struct task_struct 
*tsk, compat_long_t num,
  }
  #endif/* CONFIG_HAVE_HW_BREAKPOINT */

-long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
+static long compat_a32_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
  {
unsigned long addr = caddr;
@@ -1191,8 +1192,55 @@ long compat_arch_ptrace(struct task_struct *child, 
compat_long_t request,

return ret;
  }
+
+COMPAT_SYSCALL_DEFINE4(aarch32_ptrace, compat_long_t, request, compat_long_t, 
pid,
+  compat_long_t, addr, compat_long_t, data)
+{
+   struct task_struct *child;
+   long ret;
+
+   if (request == PTRACE_TRACEME) {
+   ret = ptrace_traceme();
+   goto out;
+   }
+
+   child = ptrace_get_task_struct(pid);
+   if (IS_ERR(child)) {
+   ret = PTR_ERR(child);
+   goto out;
+   }
+
+   if (request == PTRACE_ATTACH || request == PTRACE_SEIZE) {
+   ret = ptrace_attach(child, request, addr, data);
+   goto out_put_task_struct;
+   }
+
+   ret = ptrace_check_attach(child, request == PTRACE_KILL ||
+ request == PTRACE_INTERRUPT);
+   if (!ret) {
+   ret = compat_a32_ptrace(child, request, addr, data);
+   if (ret || request != PTRACE_DETACH)
+   ptrace_unfreeze_traced(child);
+   }
+
+ out_put_task_struct:
+   put_task_struct(child);
+ out:
+   return ret;
+}
+
  #endif /* CONFIG_AARCH32_EL0 */

+#ifdef CONFIG_COMPAT
+
+long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
+   compat_ulong_t caddr, compat_ulong_t cdata)
+{
+   return compat_ptrace_request(child, request, caddr, cdata);
+}
+
+#endif /* CONFIG_COMPAT */
+
  const struct user_regset_view *task_user_regset_view(struct task_struct *task)
  {
  #ifdef CONFIG_AARCH32_EL0
diff --git a/arch/arm64/kernel/sys32.c b/arch/arm64/kernel/sys32.c
index a40b134..3752443 100644
--- a/arch/arm64/kernel/sys32.c
+++ b/arch/arm64/kernel/sys32.c
@@ -38,6 +38,7 @@ asmlinkage long compat_sys_fadvise64_64_wrapper(void);
  asmlinkage long compat_sys_sync_file_range2_wrapper(void);
  asmlinkage long compat_sys_fallocate_wrapper(void);
  asmlinkage long compat_sys_mmap2_wrapper(void);
+asmlinkage long compat_sys_aarch32_ptrace(void);

  #undef __SYSCALL
  #define __SYSCALL(nr, sym)[nr] = sym,
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 504c98a..75887a0 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -97,6 +97,12 @@ int generic_ptrace_peekdata(struct task_struct *tsk, 
unsigned long addr,
unsigned long data);
  int generic_ptrace_pokedata(struct task_struct *tsk, unsigned long addr,
unsigned long data);
+int ptrace_traceme(void);
+struct task_struct *ptrace_get_task_struct(pid_t pid);
+int ptrace_attach(struct task_struct *task, long request,
+unsigned long addr, unsigned long flags);
+int ptrace_check_attach(struct task_struct *child, bool ignore_state);
+void ptrace_unfreeze_traced(struct task_struct *task);

  /**
   * ptrace_parent - return the task that is tracing the given task
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index d49bfa1..cadf24c 100644
--- 

[[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
commit 26424589626d7f82d09d4e7c0569f9487b2e810a ("[DEBUG] force-enable 
CONFIG_VMAP_STACK")


on test machine: vm-intel12-yocto-x86_64: 2 threads qemu-system-x86_64 
-enable-kvm -cpu Nehalem with 320M memory

caused below changes:


+--+++
|  | 03e46fd441 | 2642458962 |
+--+++
| boot_successes   | 18 | 21 |
| boot_failures| 4  | 9  |
| BUG:kernel_boot_hang | 2  ||
| WARNING:at_kernel/fork.c:#free_task  | 2  ||
| backtrace:_do_fork   | 2  ||
| backtrace:SyS_clone  | 2  ||
| BUG:unable_to_handle_kernel  | 0  | 9  |
| Oops | 0  | 9  |
| RIP:_raw_spin_lock_irq   | 0  | 9  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 9  |
| backtrace:do_mount   | 0  | 8  |
| backtrace:SyS_mount  | 0  | 8  |
+--+++



[4.310442] Freeing unused kernel memory: 1980K (880002011000 - 
88000220)
[4.420716] UDF-fs: warning (device vdb): udf_fill_super: No partition found 
(2)
[4.422544] UDF-fs: warning (device vda): udf_fill_super: No partition found 
(2)
[4.425052] BUG: unable to handle kernel paging request at c9997f18
[4.426645] IP: [] _raw_spin_lock_irq+0x2c/0x3d
[4.427869] PGD 1249e067 PUD 1249f067 PMD 11e4e067 PTE 0
[4.429245] Oops: 0002 [#1] SMP
[4.430086] Modules linked in:
[4.430992] CPU: 0 PID: 1741 Comm: mount Not tainted 
4.7.0-rc4-00258-g26424589 #1
[4.432727] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[4.434646] task: 88000d950c80 ti: 88000d950c80 task.ti: 
88000d950c80
[4.436406] RIP: 0010:[]  [] 
_raw_spin_lock_irq+0x2c/0x3d
[4.438341] RSP: 0018:c9957c80  EFLAGS: 00010046
[4.439438] RAX:  RBX: 7fff RCX: 0a66
[4.440735] RDX: 0001 RSI: 880013619bc0 RDI: c9997f18
[4.442035] RBP: c9957c88 R08: 00019bc0 R09: 81200748
[4.443323] R10: ea474900 R11: 0001a2a0 R12: c9997f10
[4.444614] R13: 0002 R14: c9997f18 R15: ffea
[4.445896] FS:  7f9ca6a32700() GS:88001360() 
knlGS:
[4.447690] CS:  0010 DS:  ES:  CR0: 80050033
[4.448819] CR2: c9997f18 CR3: 0d87c000 CR4: 06f0
[4.450102] Stack:
[4.450810]  c9997f18 c9957d00 81a982eb 
0246
[4.452827]   c9957d00 8112584b 

[4.454838]  0246 88000e27f6bc  
88000e27f080
[4.456845] Call Trace:
[4.457616]  [] wait_for_common+0x44/0x197
[4.458719]  [] ? try_to_wake_up+0x2dd/0x2ef
[4.459877]  [] wait_for_completion+0x1d/0x1f
[4.461027]  [] kthread_stop+0x82/0x10a
[4.462125]  [] destroy_workqueue+0x10d/0x1cd
[4.463347]  [] xfs_destroy_mount_workqueues+0x49/0x64
[4.464620]  [] xfs_fs_fill_super+0x2c0/0x49c
[4.465807]  [] mount_bdev+0x143/0x195
[4.466937]  [] ? xfs_test_remount_options+0x5b/0x5b
[4.468727]  [] xfs_fs_mount+0x15/0x17
[4.469838]  [] mount_fs+0x15/0x8c
[4.470882]  [] vfs_kern_mount+0x6a/0xfe
[4.472005]  [] do_mount+0x985/0xa9a
[4.473078]  [] ? strndup_user+0x3a/0x6a
[4.474193]  [] SyS_mount+0x77/0x9f
[4.475255]  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
[4.476463] Code: 66 66 66 90 55 48 89 e5 50 48 89 7d f8 fa 66 66 90 66 66 
90 e8 2d 0a 70 ff 65 ff 05 73 18 57 7e 31 c0 ba 01 00 00 00 48 8b 7d f8  0f 
b1 17 85 c0 74 07 89 c6 e8 3e 20 6a ff c9 c3 66 66 66 66 
[4.484413] RIP  [] _raw_spin_lock_irq+0x2c/0x3d
[4.485639]  RSP 
[4.486509] CR2: c9997f18
[4.487366] ---[ end trace 79763b41869f2580 ]---
[4.488367] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu Nehalem -kernel 
/pkg/linux/x86_64-lkp/gcc-4.9/26424589626d7f82d09d4e7c0569f9487b2e810a/vmlinuz-4.7.0-rc4-00258-g26424589
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-intel12-yocto-x86_64-10/validate_boot-1-yocto-minimal-x86_64.cgz-x86_64-lkp-26424589626d7f82d09d4e7c0569f9487b2e810a-20160627-40546-2cgqlo-31.yaml
 ARCH=x86_64 kconfig=x86_64-lkp 

[[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
commit 26424589626d7f82d09d4e7c0569f9487b2e810a ("[DEBUG] force-enable 
CONFIG_VMAP_STACK")


on test machine: vm-intel12-yocto-x86_64: 2 threads qemu-system-x86_64 
-enable-kvm -cpu Nehalem with 320M memory

caused below changes:


+--+++
|  | 03e46fd441 | 2642458962 |
+--+++
| boot_successes   | 18 | 21 |
| boot_failures| 4  | 9  |
| BUG:kernel_boot_hang | 2  ||
| WARNING:at_kernel/fork.c:#free_task  | 2  ||
| backtrace:_do_fork   | 2  ||
| backtrace:SyS_clone  | 2  ||
| BUG:unable_to_handle_kernel  | 0  | 9  |
| Oops | 0  | 9  |
| RIP:_raw_spin_lock_irq   | 0  | 9  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 9  |
| backtrace:do_mount   | 0  | 8  |
| backtrace:SyS_mount  | 0  | 8  |
+--+++



[4.310442] Freeing unused kernel memory: 1980K (880002011000 - 
88000220)
[4.420716] UDF-fs: warning (device vdb): udf_fill_super: No partition found 
(2)
[4.422544] UDF-fs: warning (device vda): udf_fill_super: No partition found 
(2)
[4.425052] BUG: unable to handle kernel paging request at c9997f18
[4.426645] IP: [] _raw_spin_lock_irq+0x2c/0x3d
[4.427869] PGD 1249e067 PUD 1249f067 PMD 11e4e067 PTE 0
[4.429245] Oops: 0002 [#1] SMP
[4.430086] Modules linked in:
[4.430992] CPU: 0 PID: 1741 Comm: mount Not tainted 
4.7.0-rc4-00258-g26424589 #1
[4.432727] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[4.434646] task: 88000d950c80 ti: 88000d950c80 task.ti: 
88000d950c80
[4.436406] RIP: 0010:[]  [] 
_raw_spin_lock_irq+0x2c/0x3d
[4.438341] RSP: 0018:c9957c80  EFLAGS: 00010046
[4.439438] RAX:  RBX: 7fff RCX: 0a66
[4.440735] RDX: 0001 RSI: 880013619bc0 RDI: c9997f18
[4.442035] RBP: c9957c88 R08: 00019bc0 R09: 81200748
[4.443323] R10: ea474900 R11: 0001a2a0 R12: c9997f10
[4.444614] R13: 0002 R14: c9997f18 R15: ffea
[4.445896] FS:  7f9ca6a32700() GS:88001360() 
knlGS:
[4.447690] CS:  0010 DS:  ES:  CR0: 80050033
[4.448819] CR2: c9997f18 CR3: 0d87c000 CR4: 06f0
[4.450102] Stack:
[4.450810]  c9997f18 c9957d00 81a982eb 
0246
[4.452827]   c9957d00 8112584b 

[4.454838]  0246 88000e27f6bc  
88000e27f080
[4.456845] Call Trace:
[4.457616]  [] wait_for_common+0x44/0x197
[4.458719]  [] ? try_to_wake_up+0x2dd/0x2ef
[4.459877]  [] wait_for_completion+0x1d/0x1f
[4.461027]  [] kthread_stop+0x82/0x10a
[4.462125]  [] destroy_workqueue+0x10d/0x1cd
[4.463347]  [] xfs_destroy_mount_workqueues+0x49/0x64
[4.464620]  [] xfs_fs_fill_super+0x2c0/0x49c
[4.465807]  [] mount_bdev+0x143/0x195
[4.466937]  [] ? xfs_test_remount_options+0x5b/0x5b
[4.468727]  [] xfs_fs_mount+0x15/0x17
[4.469838]  [] mount_fs+0x15/0x8c
[4.470882]  [] vfs_kern_mount+0x6a/0xfe
[4.472005]  [] do_mount+0x985/0xa9a
[4.473078]  [] ? strndup_user+0x3a/0x6a
[4.474193]  [] SyS_mount+0x77/0x9f
[4.475255]  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
[4.476463] Code: 66 66 66 90 55 48 89 e5 50 48 89 7d f8 fa 66 66 90 66 66 
90 e8 2d 0a 70 ff 65 ff 05 73 18 57 7e 31 c0 ba 01 00 00 00 48 8b 7d f8  0f 
b1 17 85 c0 74 07 89 c6 e8 3e 20 6a ff c9 c3 66 66 66 66 
[4.484413] RIP  [] _raw_spin_lock_irq+0x2c/0x3d
[4.485639]  RSP 
[4.486509] CR2: c9997f18
[4.487366] ---[ end trace 79763b41869f2580 ]---
[4.488367] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu Nehalem -kernel 
/pkg/linux/x86_64-lkp/gcc-4.9/26424589626d7f82d09d4e7c0569f9487b2e810a/vmlinuz-4.7.0-rc4-00258-g26424589
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-intel12-yocto-x86_64-10/validate_boot-1-yocto-minimal-x86_64.cgz-x86_64-lkp-26424589626d7f82d09d4e7c0569f9487b2e810a-20160627-40546-2cgqlo-31.yaml
 ARCH=x86_64 kconfig=x86_64-lkp 

Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Hi Guenter

On 06/27/2016 12:01 PM, Guenter Roeck wrote:

On Sun, Jun 26, 2016 at 7:19 PM, Chris Zhong  wrote:

Hi Heiko


On 06/25/2016 03:39 AM, Heiko Stuebner wrote:

Am Donnerstag, 23. Juni 2016, 18:27:52 schrieb Kishon Vijay Abraham I:

Hi,

On Thursday 23 June 2016 06:21 PM, Chris Zhong wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 

---

Changes in v3:
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

   drivers/phy/Kconfig  |8 +
   drivers/phy/Makefile |1 +
   drivers/phy/phy-rockchip-typec.c | 1027
   ++ 3 files changed, 1036
   insertions(+)
   create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..ec87b3a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -351,6 +351,14 @@ config PHY_ROCKCHIP_DP

 help

   Enable this to support the Rockchip Display Port PHY.

+config PHY_ROCKCHIP_TYPEC
+   tristate "Rockchip TYPEC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY

Why? None of the generic PHY API's are used here. Why do you want select
generic PHY?

I'm actually wondering, why there are no phy ops to start and stop the py.
Right now the device seems to be on and handling all the extcon notifies
all
the time even if no-one is using the phy.

There are two users of this phy, the dp-controller as well as some usb
component. The phy framework is nicely refcounted, so can handle any
number
of phy users and somehow I'd expect the phy to do nothing (and try to not
consume power) if neither the dp-controller nor the usb-part is actually
running.

It may very well be my ignorance, but Chris could you explain, if there is
a
reason for this?


Thanks
Heiko



It is good idea, The USB3 and DP controller detect the extcon cable state:
USB/USB HOST/DP. If a Type-C device plugged, call phy power on, the phy
driver get all the state of extcon: dfp, ufp, dp, flip, pin assignment, and
then finish the phy init. So the phy driver need not register extcon
notification.
But this mechanism allows phy driver only focus plug/unplug event, if some
other things happen, such as data role change, the phy will not be notified.
I'm not sure if this situation exists.

Sorry, I think I am lost (again).

All roles can change on the fly. Role changes can be triggered from
user space, or by the remote partner. If we restrict such role
changes, we would have to reject all locally triggered role change
requests, as well as all role change requests from the remote, after
the initial connection was established. I don't really see the point
of doing that, though. Wasn't this what the notifications were all
about ?

Guenter


The following are the all 3 cases about data role changing:

1. "USB host only" mode(power_count ==1), switch to "USB device" mode
we can re-init phy by phy_power_off and then phy_power_on

2. "USB host + DP" mode(power_count ==2), switch to "USB device" mode
The phy can not support ufp+dp, so it is reasonable to do nothing. 
Moreover, does this situation exist?


3. "USB device" mode (power_count ==1), switch to "USB host only" or 
"USB host + DP"

it is similar with case 1, dp or usb host can re-init the phy again.

Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Hi Guenter

On 06/27/2016 12:01 PM, Guenter Roeck wrote:

On Sun, Jun 26, 2016 at 7:19 PM, Chris Zhong  wrote:

Hi Heiko


On 06/25/2016 03:39 AM, Heiko Stuebner wrote:

Am Donnerstag, 23. Juni 2016, 18:27:52 schrieb Kishon Vijay Abraham I:

Hi,

On Thursday 23 June 2016 06:21 PM, Chris Zhong wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and
HBR2 data rates.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 

---

Changes in v3:
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

   drivers/phy/Kconfig  |8 +
   drivers/phy/Makefile |1 +
   drivers/phy/phy-rockchip-typec.c | 1027
   ++ 3 files changed, 1036
   insertions(+)
   create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..ec87b3a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -351,6 +351,14 @@ config PHY_ROCKCHIP_DP

 help

   Enable this to support the Rockchip Display Port PHY.

+config PHY_ROCKCHIP_TYPEC
+   tristate "Rockchip TYPEC PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY

Why? None of the generic PHY API's are used here. Why do you want select
generic PHY?

I'm actually wondering, why there are no phy ops to start and stop the py.
Right now the device seems to be on and handling all the extcon notifies
all
the time even if no-one is using the phy.

There are two users of this phy, the dp-controller as well as some usb
component. The phy framework is nicely refcounted, so can handle any
number
of phy users and somehow I'd expect the phy to do nothing (and try to not
consume power) if neither the dp-controller nor the usb-part is actually
running.

It may very well be my ignorance, but Chris could you explain, if there is
a
reason for this?


Thanks
Heiko



It is good idea, The USB3 and DP controller detect the extcon cable state:
USB/USB HOST/DP. If a Type-C device plugged, call phy power on, the phy
driver get all the state of extcon: dfp, ufp, dp, flip, pin assignment, and
then finish the phy init. So the phy driver need not register extcon
notification.
But this mechanism allows phy driver only focus plug/unplug event, if some
other things happen, such as data role change, the phy will not be notified.
I'm not sure if this situation exists.

Sorry, I think I am lost (again).

All roles can change on the fly. Role changes can be triggered from
user space, or by the remote partner. If we restrict such role
changes, we would have to reject all locally triggered role change
requests, as well as all role change requests from the remote, after
the initial connection was established. I don't really see the point
of doing that, though. Wasn't this what the notifications were all
about ?

Guenter


The following are the all 3 cases about data role changing:

1. "USB host only" mode(power_count ==1), switch to "USB device" mode
we can re-init phy by phy_power_off and then phy_power_on

2. "USB host + DP" mode(power_count ==2), switch to "USB device" mode
The phy can not support ufp+dp, so it is reasonable to do nothing. 
Moreover, does this situation exist?


3. "USB device" mode (power_count ==1), switch to "USB host only" or 
"USB host + DP"

it is similar with case 1, dp or usb host can re-init the phy again.

Re: [PATCH] Decouple CFG and IO in Designware PCIe Driver

[Pratyush Anand]

On Wed, Jun 22, 2016 at 1:54 PM, dongbo (E)  wrote:
> From: Dong Bo 
>
> In designware PCIe driver, the iatu0 is used for both CFG and IO accesses.
> When PCIe sends CFGs to peripherals (e.g. lspci),
> iatu0 frequently switches between CFG and IO alternatively.
>
> If the LIMIT of MEMORY is a value between CFGs BASE_ADDR and IOs LIMIT,
> this probably results in a MEMORY beging matched to be an IO by mistake.
>
> Considering the following configurations:
> MEMORY  ->  BASE_ADDR: 0xb410, LIMIT: 0xb4100FFF, TYPE=mem
> CFG ->  BASE_ADDR: 0xb400, LIMIT: 0xb4000FFF, TYPE=cfg
> IO  ->  BASE_ADDR: 0x, LIMIT: 0xFFFE, TYPE=io
> Suppose PCIe has just completed a CFG access, to switch back to IO, it set 
> the BASE_ADDR to 0x, LIMIT 0xFFFE and TYPE to io.
> When another CFG access come,
> PCIe first set BASE_ADDR to 0xb400 to switch to CFG.
> At this moment, a MEMORY access shows up, due to `0xb400 <= MEMORY 
> BASE_ADDR <= MEMORY LIMIE <= 0xFFF, it matches with iatu0.
> And it is treated as an IO access by mistake, then sent to perpheral.
>

Hummm...This portion of driver has always been buggy.

> This patch fixes the problem by decoupling CFG and IO, reassigning iatu2 to 
> IO.

But, we can not just assign IOs to iatu2.
IIRC then, there are atleast two platforms which have only 2
viewports, therefore they can not program iatu2.

Jingoo,Bjorn: IMHO, we should modify this portion of code, since more
number of platforms has 4+ viewports. Probably, we can take following
approach:

(1) Pass number of viewports through DT. If we have *atleast*  3
viewports then assign separate viewports to memory and IO,  and share
one with CFG0 and CFG1.
(2) If we can have *atleast*  4 then, we may have separate for CFG0
and CFG1 as well.

(3) If we have *only* 2 then,  either we let them work as they work
today with bug, or may be we restrict them from using IO transactions.
So assign one to memory and share other for CFG0 and CFG1.

Please let me know your opnion.

~Pratyush

>
> Signed-off-by: Dong Bo 
> ---
>  drivers/pci/host/pcie-designware.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index aafd766..1a40305 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -51,6 +51,7 @@
>  #define PCIE_ATU_VIEWPORT  0x900
>  #define PCIE_ATU_REGION_INBOUND(0x1 << 31)
>  #define PCIE_ATU_REGION_OUTBOUND   (0x0 << 31)
> +#define PCIE_ATU_REGION_INDEX2 (0x2 << 0)
>  #define PCIE_ATU_REGION_INDEX1 (0x1 << 0)
>  #define PCIE_ATU_REGION_INDEX0 (0x0 << 0)
>  #define PCIE_ATU_CR1   0x904
> @@ -603,9 +604,6 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp, 
> struct pci_bus *bus,
>   type, cpu_addr,
>   busdev, cfg_size);
> ret = dw_pcie_cfg_read(va_cfg_base + where, size, val);
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> - PCIE_ATU_TYPE_IO, pp->io_base,
> - pp->io_bus_addr, pp->io_size);
>
> return ret;
>  }
> @@ -640,9 +638,6 @@ static int dw_pcie_wr_other_conf(struct pcie_port *pp, 
> struct pci_bus *bus,
>   type, cpu_addr,
>   busdev, cfg_size);
> ret = dw_pcie_cfg_write(va_cfg_base + where, size, val);
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> - PCIE_ATU_TYPE_IO, pp->io_base,
> - pp->io_bus_addr, pp->io_size);
>
> return ret;
>  }
> @@ -778,10 +773,15 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>  * uses its own address translation component rather than ATU, so
>  * we should not program the ATU here.
>  */
> -   if (!pp->ops->rd_other_conf)
> +   if (!pp->ops->rd_other_conf) {
> dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
>   PCIE_ATU_TYPE_MEM, pp->mem_base,
>   pp->mem_bus_addr, pp->mem_size);
> +   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX2,
> +   PCIE_ATU_TYPE_IO, pp->io_base,
> +   pp->io_bus_addr, pp->io_size);
> +
> +   }
>
> dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0);
>
> --
> 1.9.1
>

Re: [PATCH] Decouple CFG and IO in Designware PCIe Driver

[Pratyush Anand]

On Wed, Jun 22, 2016 at 1:54 PM, dongbo (E)  wrote:
> From: Dong Bo 
>
> In designware PCIe driver, the iatu0 is used for both CFG and IO accesses.
> When PCIe sends CFGs to peripherals (e.g. lspci),
> iatu0 frequently switches between CFG and IO alternatively.
>
> If the LIMIT of MEMORY is a value between CFGs BASE_ADDR and IOs LIMIT,
> this probably results in a MEMORY beging matched to be an IO by mistake.
>
> Considering the following configurations:
> MEMORY  ->  BASE_ADDR: 0xb410, LIMIT: 0xb4100FFF, TYPE=mem
> CFG ->  BASE_ADDR: 0xb400, LIMIT: 0xb4000FFF, TYPE=cfg
> IO  ->  BASE_ADDR: 0x, LIMIT: 0xFFFE, TYPE=io
> Suppose PCIe has just completed a CFG access, to switch back to IO, it set 
> the BASE_ADDR to 0x, LIMIT 0xFFFE and TYPE to io.
> When another CFG access come,
> PCIe first set BASE_ADDR to 0xb400 to switch to CFG.
> At this moment, a MEMORY access shows up, due to `0xb400 <= MEMORY 
> BASE_ADDR <= MEMORY LIMIE <= 0xFFF, it matches with iatu0.
> And it is treated as an IO access by mistake, then sent to perpheral.
>

Hummm...This portion of driver has always been buggy.

> This patch fixes the problem by decoupling CFG and IO, reassigning iatu2 to 
> IO.

But, we can not just assign IOs to iatu2.
IIRC then, there are atleast two platforms which have only 2
viewports, therefore they can not program iatu2.

Jingoo,Bjorn: IMHO, we should modify this portion of code, since more
number of platforms has 4+ viewports. Probably, we can take following
approach:

(1) Pass number of viewports through DT. If we have *atleast*  3
viewports then assign separate viewports to memory and IO,  and share
one with CFG0 and CFG1.
(2) If we can have *atleast*  4 then, we may have separate for CFG0
and CFG1 as well.

(3) If we have *only* 2 then,  either we let them work as they work
today with bug, or may be we restrict them from using IO transactions.
So assign one to memory and share other for CFG0 and CFG1.

Please let me know your opnion.

~Pratyush

>
> Signed-off-by: Dong Bo 
> ---
>  drivers/pci/host/pcie-designware.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index aafd766..1a40305 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -51,6 +51,7 @@
>  #define PCIE_ATU_VIEWPORT  0x900
>  #define PCIE_ATU_REGION_INBOUND(0x1 << 31)
>  #define PCIE_ATU_REGION_OUTBOUND   (0x0 << 31)
> +#define PCIE_ATU_REGION_INDEX2 (0x2 << 0)
>  #define PCIE_ATU_REGION_INDEX1 (0x1 << 0)
>  #define PCIE_ATU_REGION_INDEX0 (0x0 << 0)
>  #define PCIE_ATU_CR1   0x904
> @@ -603,9 +604,6 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp, 
> struct pci_bus *bus,
>   type, cpu_addr,
>   busdev, cfg_size);
> ret = dw_pcie_cfg_read(va_cfg_base + where, size, val);
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> - PCIE_ATU_TYPE_IO, pp->io_base,
> - pp->io_bus_addr, pp->io_size);
>
> return ret;
>  }
> @@ -640,9 +638,6 @@ static int dw_pcie_wr_other_conf(struct pcie_port *pp, 
> struct pci_bus *bus,
>   type, cpu_addr,
>   busdev, cfg_size);
> ret = dw_pcie_cfg_write(va_cfg_base + where, size, val);
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> - PCIE_ATU_TYPE_IO, pp->io_base,
> - pp->io_bus_addr, pp->io_size);
>
> return ret;
>  }
> @@ -778,10 +773,15 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>  * uses its own address translation component rather than ATU, so
>  * we should not program the ATU here.
>  */
> -   if (!pp->ops->rd_other_conf)
> +   if (!pp->ops->rd_other_conf) {
> dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
>   PCIE_ATU_TYPE_MEM, pp->mem_base,
>   pp->mem_bus_addr, pp->mem_size);
> +   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX2,
> +   PCIE_ATU_TYPE_IO, pp->io_base,
> +   pp->io_bus_addr, pp->io_size);
> +
> +   }
>
> dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0);
>
> --
> 1.9.1
>

[PATCH V5 1/2] cpufreq: Handle sorted frequency tables more efficiently

[Viresh Kumar]

cpufreq drivers aren't required to provide a sorted frequency table
today, and even the ones which provide a sorted table aren't handled
efficiently by cpufreq core.

This patch adds infrastructure to verify if the freq-table provided by
the drivers is sorted or not, and use efficient helpers if they are
sorted.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/freq_table.c |  73 --
 include/linux/cpufreq.h  | 234 ++-
 2 files changed, 296 insertions(+), 11 deletions(-)

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index eac8bcbdaad1..3bbbf9e6960c 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -113,9 +113,9 @@ int cpufreq_generic_frequency_table_verify(struct 
cpufreq_policy *policy)
 }
 EXPORT_SYMBOL_GPL(cpufreq_generic_frequency_table_verify);
 
-int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
-   unsigned int target_freq,
-   unsigned int relation)
+int cpufreq_table_index_unsorted(struct cpufreq_policy *policy,
+unsigned int target_freq,
+unsigned int relation)
 {
struct cpufreq_frequency_table optimal = {
.driver_data = ~0,
@@ -205,7 +205,7 @@ int cpufreq_frequency_table_target(struct cpufreq_policy 
*policy,
 table[index].frequency);
return index;
 }
-EXPORT_SYMBOL_GPL(cpufreq_frequency_table_target);
+EXPORT_SYMBOL_GPL(cpufreq_table_index_unsorted);
 
 int cpufreq_frequency_table_get_index(struct cpufreq_policy *policy,
unsigned int freq)
@@ -297,15 +297,72 @@ struct freq_attr *cpufreq_generic_attr[] = {
 };
 EXPORT_SYMBOL_GPL(cpufreq_generic_attr);
 
+static int set_freq_table_sorted(struct cpufreq_policy *policy)
+{
+   struct cpufreq_frequency_table *pos, *table = policy->freq_table;
+   struct cpufreq_frequency_table *prev = NULL;
+   int ascending = 0;
+
+   policy->freq_table_sorted = CPUFREQ_TABLE_UNSORTED;
+
+   cpufreq_for_each_valid_entry(pos, table) {
+   if (!prev) {
+   prev = pos;
+   continue;
+   }
+
+   if (pos->frequency == prev->frequency) {
+   pr_warn("Duplicate freq-table entries: %u\n",
+   pos->frequency);
+   return -EINVAL;
+   }
+
+   /* Frequency increased from prev to pos */
+   if (pos->frequency > prev->frequency) {
+   /* But frequency was decreasing earlier */
+   if (ascending < 0) {
+   pr_debug("Freq table is unsorted\n");
+   return 0;
+   }
+
+   ascending++;
+   } else {
+   /* Frequency decreased from prev to pos */
+
+   /* But frequency was increasing earlier */
+   if (ascending > 0) {
+   pr_debug("Freq table is unsorted\n");
+   return 0;
+   }
+
+   ascending--;
+   }
+
+   prev = pos;
+   }
+
+   if (ascending > 0)
+   policy->freq_table_sorted = CPUFREQ_TABLE_SORTED_ASCENDING;
+   else
+   policy->freq_table_sorted = CPUFREQ_TABLE_SORTED_DESCENDING;
+
+   pr_debug("Freq table is sorted in %s order\n",
+ascending > 0 ? "ascending" : "descending");
+
+   return 0;
+}
+
 int cpufreq_table_validate_and_show(struct cpufreq_policy *policy,
  struct cpufreq_frequency_table *table)
 {
-   int ret = cpufreq_frequency_table_cpuinfo(policy, table);
+   int ret;
 
-   if (!ret)
-   policy->freq_table = table;
+   ret = cpufreq_frequency_table_cpuinfo(policy, table);
+   if (ret)
+   return ret;
 
-   return ret;
+   policy->freq_table = table;
+   return set_freq_table_sorted(policy);
 }
 EXPORT_SYMBOL_GPL(cpufreq_table_validate_and_show);
 
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index c378776628b4..2d6c53c4284e 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -36,6 +36,12 @@
 
 struct cpufreq_governor;
 
+enum cpufreq_table_sorting {
+   CPUFREQ_TABLE_UNSORTED,
+   CPUFREQ_TABLE_SORTED_ASCENDING,
+   CPUFREQ_TABLE_SORTED_DESCENDING
+};
+
 struct cpufreq_freqs {
unsigned int cpu;   /* cpu nr */
unsigned int old;
@@ -87,6 +93,7 @@ struct cpufreq_policy {
 
struct cpufreq_user_policy user_policy;
struct cpufreq_frequency_table  *freq_table;
+   enum cpufreq_table_sorting freq_table_sorted;
 
struct list_headpolicy_list;
struct 

[PATCH V5 1/2] cpufreq: Handle sorted frequency tables more efficiently

[Viresh Kumar]

cpufreq drivers aren't required to provide a sorted frequency table
today, and even the ones which provide a sorted table aren't handled
efficiently by cpufreq core.

This patch adds infrastructure to verify if the freq-table provided by
the drivers is sorted or not, and use efficient helpers if they are
sorted.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/freq_table.c |  73 --
 include/linux/cpufreq.h  | 234 ++-
 2 files changed, 296 insertions(+), 11 deletions(-)

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index eac8bcbdaad1..3bbbf9e6960c 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -113,9 +113,9 @@ int cpufreq_generic_frequency_table_verify(struct 
cpufreq_policy *policy)
 }
 EXPORT_SYMBOL_GPL(cpufreq_generic_frequency_table_verify);
 
-int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
-   unsigned int target_freq,
-   unsigned int relation)
+int cpufreq_table_index_unsorted(struct cpufreq_policy *policy,
+unsigned int target_freq,
+unsigned int relation)
 {
struct cpufreq_frequency_table optimal = {
.driver_data = ~0,
@@ -205,7 +205,7 @@ int cpufreq_frequency_table_target(struct cpufreq_policy 
*policy,
 table[index].frequency);
return index;
 }
-EXPORT_SYMBOL_GPL(cpufreq_frequency_table_target);
+EXPORT_SYMBOL_GPL(cpufreq_table_index_unsorted);
 
 int cpufreq_frequency_table_get_index(struct cpufreq_policy *policy,
unsigned int freq)
@@ -297,15 +297,72 @@ struct freq_attr *cpufreq_generic_attr[] = {
 };
 EXPORT_SYMBOL_GPL(cpufreq_generic_attr);
 
+static int set_freq_table_sorted(struct cpufreq_policy *policy)
+{
+   struct cpufreq_frequency_table *pos, *table = policy->freq_table;
+   struct cpufreq_frequency_table *prev = NULL;
+   int ascending = 0;
+
+   policy->freq_table_sorted = CPUFREQ_TABLE_UNSORTED;
+
+   cpufreq_for_each_valid_entry(pos, table) {
+   if (!prev) {
+   prev = pos;
+   continue;
+   }
+
+   if (pos->frequency == prev->frequency) {
+   pr_warn("Duplicate freq-table entries: %u\n",
+   pos->frequency);
+   return -EINVAL;
+   }
+
+   /* Frequency increased from prev to pos */
+   if (pos->frequency > prev->frequency) {
+   /* But frequency was decreasing earlier */
+   if (ascending < 0) {
+   pr_debug("Freq table is unsorted\n");
+   return 0;
+   }
+
+   ascending++;
+   } else {
+   /* Frequency decreased from prev to pos */
+
+   /* But frequency was increasing earlier */
+   if (ascending > 0) {
+   pr_debug("Freq table is unsorted\n");
+   return 0;
+   }
+
+   ascending--;
+   }
+
+   prev = pos;
+   }
+
+   if (ascending > 0)
+   policy->freq_table_sorted = CPUFREQ_TABLE_SORTED_ASCENDING;
+   else
+   policy->freq_table_sorted = CPUFREQ_TABLE_SORTED_DESCENDING;
+
+   pr_debug("Freq table is sorted in %s order\n",
+ascending > 0 ? "ascending" : "descending");
+
+   return 0;
+}
+
 int cpufreq_table_validate_and_show(struct cpufreq_policy *policy,
  struct cpufreq_frequency_table *table)
 {
-   int ret = cpufreq_frequency_table_cpuinfo(policy, table);
+   int ret;
 
-   if (!ret)
-   policy->freq_table = table;
+   ret = cpufreq_frequency_table_cpuinfo(policy, table);
+   if (ret)
+   return ret;
 
-   return ret;
+   policy->freq_table = table;
+   return set_freq_table_sorted(policy);
 }
 EXPORT_SYMBOL_GPL(cpufreq_table_validate_and_show);
 
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index c378776628b4..2d6c53c4284e 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -36,6 +36,12 @@
 
 struct cpufreq_governor;
 
+enum cpufreq_table_sorting {
+   CPUFREQ_TABLE_UNSORTED,
+   CPUFREQ_TABLE_SORTED_ASCENDING,
+   CPUFREQ_TABLE_SORTED_DESCENDING
+};
+
 struct cpufreq_freqs {
unsigned int cpu;   /* cpu nr */
unsigned int old;
@@ -87,6 +93,7 @@ struct cpufreq_policy {
 
struct cpufreq_user_policy user_policy;
struct cpufreq_frequency_table  *freq_table;
+   enum cpufreq_table_sorting freq_table_sorted;
 
struct list_headpolicy_list;
struct kobject  kobj;
@@ 

[PATCH V5 2/2] cpufreq: Reuse new freq-table helpers

[Viresh Kumar]

This patch migrates few users of cpufreq tables to the new helpers that
work on sorted freq-tables.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/acpi-cpufreq.c | 14 --
 drivers/cpufreq/amd_freq_sensitivity.c |  4 ++--
 drivers/cpufreq/cpufreq_ondemand.c |  6 ++
 drivers/cpufreq/powernv-cpufreq.c  |  3 +--
 drivers/cpufreq/s5pv210-cpufreq.c  |  3 +--
 5 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 32a15052f363..11c9a078e0fd 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -468,20 +468,14 @@ unsigned int acpi_cpufreq_fast_switch(struct 
cpufreq_policy *policy,
struct acpi_cpufreq_data *data = policy->driver_data;
struct acpi_processor_performance *perf;
struct cpufreq_frequency_table *entry;
-   unsigned int next_perf_state, next_freq, freq;
+   unsigned int next_perf_state, next_freq, index;
 
/*
 * Find the closest frequency above target_freq.
-*
-* The table is sorted in the reverse order with respect to the
-* frequency and all of the entries are valid (see the initialization).
 */
-   entry = policy->freq_table;
-   do {
-   entry++;
-   freq = entry->frequency;
-   } while (freq >= target_freq && freq != CPUFREQ_TABLE_END);
-   entry--;
+   index = cpufreq_table_find_index_dl(policy, target_freq);
+
+   entry = >freq_table[index];
next_freq = entry->frequency;
next_perf_state = entry->driver_data;
 
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index 6d5dc04c3a37..042023bbbf62 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -91,8 +91,8 @@ static unsigned int amd_powersave_bias_target(struct 
cpufreq_policy *policy,
else {
unsigned int index;
 
-   index = cpufreq_frequency_table_target(policy,
-   policy->cur - 1, CPUFREQ_RELATION_H);
+   index = cpufreq_table_find_index_h(policy,
+  policy->cur - 1);
freq_next = policy->freq_table[index].frequency;
}
 
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 0c93cd9dee99..3a1f49f5f4c6 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -85,11 +85,9 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
freq_avg = freq_req - freq_reduc;
 
/* Find freq bounds for freq_avg in freq_table */
-   index = cpufreq_frequency_table_target(policy, freq_avg,
-  CPUFREQ_RELATION_H);
+   index = cpufreq_table_find_index_h(policy, freq_avg);
freq_lo = freq_table[index].frequency;
-   index = cpufreq_frequency_table_target(policy, freq_avg,
-  CPUFREQ_RELATION_L);
+   index = cpufreq_table_find_index_l(policy, freq_avg);
freq_hi = freq_table[index].frequency;
 
/* Find out how long we have to be in hi and lo freqs */
diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index b29c5c20c3a1..2a2920c4fdf9 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -760,8 +760,7 @@ void powernv_cpufreq_work_fn(struct work_struct *work)
struct cpufreq_policy policy;
 
cpufreq_get_policy(, cpu);
-   index = cpufreq_frequency_table_target(, policy.cur,
-  CPUFREQ_RELATION_C);
+   index = cpufreq_table_find_index_c(, policy.cur);
powernv_cpufreq_target_index(, index);
cpumask_andnot(, , policy.cpus);
}
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c 
b/drivers/cpufreq/s5pv210-cpufreq.c
index 4f4e9df9b7fc..9e07588ea9f5 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -246,8 +246,7 @@ static int s5pv210_target(struct cpufreq_policy *policy, 
unsigned int index)
new_freq = s5pv210_freq_table[index].frequency;
 
/* Finding current running level index */
-   priv_index = cpufreq_frequency_table_target(policy, old_freq,
-   CPUFREQ_RELATION_H);
+   priv_index = cpufreq_table_find_index_h(policy, old_freq);
 
arm_volt = dvs_conf[index].arm_volt;
int_volt = dvs_conf[index].int_volt;
-- 
2.7.4

[PATCH V5 0/2] cpufreq: Sorted policy->freq_table

[Viresh Kumar]

Hi Rafael,

This series is aimed to make traversing of cpufreq table more efficient
for platforms that already sort the frequency tables. The cpufreq core
now checks if the freq table is sorted and applies a different set of
helpers on such tables while traversing them.

All the patches are pushed here for testing in case anyone wants to try:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git 
cpufreq/sorted-freq-table

V4->V4:
- s/cpufreq_table_find_index_unsorted/cpufreq_table_index_unsorted
- return error for duplicate frequencies
- freq-table-sorted is an enum now
- Remove freq_is_invalid() and clamp the frequencies at the top of few
  helpers.
- Remove few checks which were impossible to hit (best == -1)

Viresh Kumar (2):
  cpufreq: Handle sorted frequency tables more efficiently
  cpufreq: Reuse new freq-table helpers

 drivers/cpufreq/acpi-cpufreq.c |  14 +-
 drivers/cpufreq/amd_freq_sensitivity.c |   4 +-
 drivers/cpufreq/cpufreq_ondemand.c |   6 +-
 drivers/cpufreq/freq_table.c   |  73 --
 drivers/cpufreq/powernv-cpufreq.c  |   3 +-
 drivers/cpufreq/s5pv210-cpufreq.c  |   3 +-
 include/linux/cpufreq.h| 234 -
 7 files changed, 306 insertions(+), 31 deletions(-)

-- 
2.7.4

[PATCH V5 2/2] cpufreq: Reuse new freq-table helpers

[Viresh Kumar]

This patch migrates few users of cpufreq tables to the new helpers that
work on sorted freq-tables.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/acpi-cpufreq.c | 14 --
 drivers/cpufreq/amd_freq_sensitivity.c |  4 ++--
 drivers/cpufreq/cpufreq_ondemand.c |  6 ++
 drivers/cpufreq/powernv-cpufreq.c  |  3 +--
 drivers/cpufreq/s5pv210-cpufreq.c  |  3 +--
 5 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 32a15052f363..11c9a078e0fd 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -468,20 +468,14 @@ unsigned int acpi_cpufreq_fast_switch(struct 
cpufreq_policy *policy,
struct acpi_cpufreq_data *data = policy->driver_data;
struct acpi_processor_performance *perf;
struct cpufreq_frequency_table *entry;
-   unsigned int next_perf_state, next_freq, freq;
+   unsigned int next_perf_state, next_freq, index;
 
/*
 * Find the closest frequency above target_freq.
-*
-* The table is sorted in the reverse order with respect to the
-* frequency and all of the entries are valid (see the initialization).
 */
-   entry = policy->freq_table;
-   do {
-   entry++;
-   freq = entry->frequency;
-   } while (freq >= target_freq && freq != CPUFREQ_TABLE_END);
-   entry--;
+   index = cpufreq_table_find_index_dl(policy, target_freq);
+
+   entry = >freq_table[index];
next_freq = entry->frequency;
next_perf_state = entry->driver_data;
 
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index 6d5dc04c3a37..042023bbbf62 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -91,8 +91,8 @@ static unsigned int amd_powersave_bias_target(struct 
cpufreq_policy *policy,
else {
unsigned int index;
 
-   index = cpufreq_frequency_table_target(policy,
-   policy->cur - 1, CPUFREQ_RELATION_H);
+   index = cpufreq_table_find_index_h(policy,
+  policy->cur - 1);
freq_next = policy->freq_table[index].frequency;
}
 
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 0c93cd9dee99..3a1f49f5f4c6 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -85,11 +85,9 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
freq_avg = freq_req - freq_reduc;
 
/* Find freq bounds for freq_avg in freq_table */
-   index = cpufreq_frequency_table_target(policy, freq_avg,
-  CPUFREQ_RELATION_H);
+   index = cpufreq_table_find_index_h(policy, freq_avg);
freq_lo = freq_table[index].frequency;
-   index = cpufreq_frequency_table_target(policy, freq_avg,
-  CPUFREQ_RELATION_L);
+   index = cpufreq_table_find_index_l(policy, freq_avg);
freq_hi = freq_table[index].frequency;
 
/* Find out how long we have to be in hi and lo freqs */
diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index b29c5c20c3a1..2a2920c4fdf9 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -760,8 +760,7 @@ void powernv_cpufreq_work_fn(struct work_struct *work)
struct cpufreq_policy policy;
 
cpufreq_get_policy(, cpu);
-   index = cpufreq_frequency_table_target(, policy.cur,
-  CPUFREQ_RELATION_C);
+   index = cpufreq_table_find_index_c(, policy.cur);
powernv_cpufreq_target_index(, index);
cpumask_andnot(, , policy.cpus);
}
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c 
b/drivers/cpufreq/s5pv210-cpufreq.c
index 4f4e9df9b7fc..9e07588ea9f5 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -246,8 +246,7 @@ static int s5pv210_target(struct cpufreq_policy *policy, 
unsigned int index)
new_freq = s5pv210_freq_table[index].frequency;
 
/* Finding current running level index */
-   priv_index = cpufreq_frequency_table_target(policy, old_freq,
-   CPUFREQ_RELATION_H);
+   priv_index = cpufreq_table_find_index_h(policy, old_freq);
 
arm_volt = dvs_conf[index].arm_volt;
int_volt = dvs_conf[index].int_volt;
-- 
2.7.4

[PATCH V5 0/2] cpufreq: Sorted policy->freq_table

[Viresh Kumar]

Hi Rafael,

This series is aimed to make traversing of cpufreq table more efficient
for platforms that already sort the frequency tables. The cpufreq core
now checks if the freq table is sorted and applies a different set of
helpers on such tables while traversing them.

All the patches are pushed here for testing in case anyone wants to try:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git 
cpufreq/sorted-freq-table

V4->V4:
- s/cpufreq_table_find_index_unsorted/cpufreq_table_index_unsorted
- return error for duplicate frequencies
- freq-table-sorted is an enum now
- Remove freq_is_invalid() and clamp the frequencies at the top of few
  helpers.
- Remove few checks which were impossible to hit (best == -1)

Viresh Kumar (2):
  cpufreq: Handle sorted frequency tables more efficiently
  cpufreq: Reuse new freq-table helpers

 drivers/cpufreq/acpi-cpufreq.c |  14 +-
 drivers/cpufreq/amd_freq_sensitivity.c |   4 +-
 drivers/cpufreq/cpufreq_ondemand.c |   6 +-
 drivers/cpufreq/freq_table.c   |  73 --
 drivers/cpufreq/powernv-cpufreq.c  |   3 +-
 drivers/cpufreq/s5pv210-cpufreq.c  |   3 +-
 include/linux/cpufreq.h| 234 -
 7 files changed, 306 insertions(+), 31 deletions(-)

-- 
2.7.4

linux-next: manual merge of the kvm-ppc-paulus tree with the powerpc tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the kvm-ppc-paulus tree got a conflict in:

  arch/powerpc/kernel/traps.c

between commit:

  42f5b4cacd78 ("powerpc: Introduce asm-prototypes.h")

from the powerpc tree and commit:

  fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on 
HMI interrupt")

from the kvm-ppc-paulus 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 arch/powerpc/kernel/traps.c
index f7e2f2e318bd,9ec95daccad9..
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@@ -60,7 -60,7 +60,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  #include 
  
  #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)

linux-next: manual merge of the kvm-ppc-paulus tree with the powerpc tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the kvm-ppc-paulus tree got a conflict in:

  arch/powerpc/kernel/traps.c

between commit:

  42f5b4cacd78 ("powerpc: Introduce asm-prototypes.h")

from the powerpc tree and commit:

  fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on 
HMI interrupt")

from the kvm-ppc-paulus 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 arch/powerpc/kernel/traps.c
index f7e2f2e318bd,9ec95daccad9..
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@@ -60,7 -60,7 +60,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  #include 
  
  #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)

Re: [patch V3 00/22] timer: Refactor the timer wheel

[Paul E. McKenney]

On Fri, Jun 24, 2016 at 02:32:00PM -, Thomas Gleixner wrote:
> This is the third version of the timer wheel rework series. The previous
> versions can be found here:
> 
> V1:   http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de
> V2:   http://lkml.kernel.org/r/20160617121134.417319...@linutronix.de
> 
> The series is also available in git:
> 
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers
> 
> Changes vs. V2:
> 
>  - Removed the 1000Hz granularity reduction to 4ms. Eric explained that
>datacenter workloads require the granularity in the first level wheel.
> 
>  - Fixed the typo in tilepro. 
> 
>  - Converted sigtimedwait() to hrtimers
> 
>  - To avoid the cascading I extended the wheel by another level. This removes
>the rarely executed cascading code path, but increases the storage size for
>HZ>100 slightly. If the tiny folks care, there is an simple option to cut
>the storage size in half for the price of reduced granularity.
> 
> Thanks,

And this series avoids the strange SRCU behavior that I saw with the
last version.  So looks to be getting there!

I will be torturing it more vigorously, but looking good so far.

Thanx, Paul

>   tglx
> 
> 
>  arch/x86/kernel/apic/x2apic_uv_x.c  |4 
>  arch/x86/kernel/cpu/mcheck/mce.c|4 
>  block/genhd.c   |5 
>  drivers/cpufreq/powernv-cpufreq.c   |5 
>  drivers/mmc/host/jz4740_mmc.c   |2 
>  drivers/net/ethernet/tile/tilepro.c |4 
>  drivers/power/bq27xxx_battery.c |5 
>  drivers/tty/metag_da.c  |4 
>  drivers/tty/mips_ejtag_fdc.c|4 
>  drivers/usb/host/ohci-hcd.c |1 
>  drivers/usb/host/xhci.c |2 
>  include/linux/list.h|   10 
>  include/linux/timer.h   |   34 -
>  kernel/signal.c |   24 
>  kernel/time/tick-internal.h |1 
>  kernel/time/tick-sched.c|   46 -
>  kernel/time/timer.c | 1096 
> +---
>  lib/random32.c  |1 
>  net/ipv4/inet_connection_sock.c |7 
>  net/ipv4/inet_timewait_sock.c   |5 
>  20 files changed, 734 insertions(+), 530 deletions(-)
> 
> 

Re: [patch V3 00/22] timer: Refactor the timer wheel

[Paul E. McKenney]

On Fri, Jun 24, 2016 at 02:32:00PM -, Thomas Gleixner wrote:
> This is the third version of the timer wheel rework series. The previous
> versions can be found here:
> 
> V1:   http://lkml.kernel.org/r/20160613070440.950649...@linutronix.de
> V2:   http://lkml.kernel.org/r/20160617121134.417319...@linutronix.de
> 
> The series is also available in git:
> 
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers
> 
> Changes vs. V2:
> 
>  - Removed the 1000Hz granularity reduction to 4ms. Eric explained that
>datacenter workloads require the granularity in the first level wheel.
> 
>  - Fixed the typo in tilepro. 
> 
>  - Converted sigtimedwait() to hrtimers
> 
>  - To avoid the cascading I extended the wheel by another level. This removes
>the rarely executed cascading code path, but increases the storage size for
>HZ>100 slightly. If the tiny folks care, there is an simple option to cut
>the storage size in half for the price of reduced granularity.
> 
> Thanks,

And this series avoids the strange SRCU behavior that I saw with the
last version.  So looks to be getting there!

I will be torturing it more vigorously, but looking good so far.

Thanx, Paul

>   tglx
> 
> 
>  arch/x86/kernel/apic/x2apic_uv_x.c  |4 
>  arch/x86/kernel/cpu/mcheck/mce.c|4 
>  block/genhd.c   |5 
>  drivers/cpufreq/powernv-cpufreq.c   |5 
>  drivers/mmc/host/jz4740_mmc.c   |2 
>  drivers/net/ethernet/tile/tilepro.c |4 
>  drivers/power/bq27xxx_battery.c |5 
>  drivers/tty/metag_da.c  |4 
>  drivers/tty/mips_ejtag_fdc.c|4 
>  drivers/usb/host/ohci-hcd.c |1 
>  drivers/usb/host/xhci.c |2 
>  include/linux/list.h|   10 
>  include/linux/timer.h   |   34 -
>  kernel/signal.c |   24 
>  kernel/time/tick-internal.h |1 
>  kernel/time/tick-sched.c|   46 -
>  kernel/time/timer.c | 1096 
> +---
>  lib/random32.c  |1 
>  net/ipv4/inet_connection_sock.c |7 
>  net/ipv4/inet_timewait_sock.c   |5 
>  20 files changed, 734 insertions(+), 530 deletions(-)
> 
> 

[PATCH v2] Bluetooth: btmrvl: fix slab-out-of-bounds access in btmrvl_sdio

[Ricky Liang]

Kasan reported slab-out-of-bounds access in btmrvl_sdio:

[   33.055400] 
==
[   33.062585] BUG: KASAN: slab-out-of-bounds in memcpy+0x24/0x50 at addr 
ffc0d89b4a00
[   33.070529] Read of size 256 by task btmrvl_main_ser/3576
[   33.075885] 
=
[   33.084002] BUG kmalloc-256 (Tainted: GB ): kasan: bad access 
detected
[   33.091511] 
-

[   33.413498] Call trace:
[   33.415928] [] dump_backtrace+0x0/0x190
[   33.421288] [] show_stack+0x1c/0x28
[   33.426305] [] dump_stack+0xa0/0xf8
[   33.431320] [] print_trailer+0x158/0x16c
[   33.436765] [] object_err+0x48/0x5c
[   33.441780] [] kasan_report+0x344/0x510
[   33.447141] [] __asan_loadN+0x20/0x150
[   33.452413] [] memcpy+0x20/0x50
[   33.457084] [] swiotlb_tbl_map_single+0x2ec/0x310
[   33.463305] [] map_single+0x24/0x30
[   33.468320] [] swiotlb_map_sg_attrs+0xec/0x21c
[   33.474286] [] __swiotlb_map_sg_attrs+0x48/0xec
[   33.480339] [] msdc_prepare_data.isra.11+0xf0/0x11c
[   33.486733] [] msdc_ops_request+0x74/0xf0
[   33.492266] [] __mmc_start_request+0x78/0x8c
[   33.498057] [] mmc_start_request+0x220/0x240
[   33.503848] [] mmc_wait_for_req+0x78/0x250
[   33.509468] [] mmc_io_rw_extended+0x2ec/0x388
[   33.515347] [] sdio_io_rw_ext_helper+0x160/0x268
[   33.521483] [] sdio_writesb+0x40/0x50
[   33.526677] [] btmrvl_sdio_host_to_card+0x124/0x1bc 
[btmrvl_sdio]
[   33.534283] [] btmrvl_service_main_thread+0x384/0x428 
[btmrvl]
[   33.541626] [] kthread+0x140/0x158
[   33.546550] Memory state around the buggy address:
[   33.551305]  ffc0d89b4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.558474]  ffc0d89b4a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[   33.565643] >ffc0d89b4a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
fc
[   33.572809] ^
[   33.579889]  ffc0d89b4b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.587055]  ffc0d89b4b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.594221] 
==

The cause of this is that btmrvl_sdio_host_to_card can access memory region
out of its allocated space due to:

  1. the requested block size is smaller than SDIO_BLOCK_SIZE, and/or
  2. the allocated memory is not BTSDIO_DMA_ALIGN-aligned.

Since sdio_writesb() is able to handle any size of data it's not necessary
to re-allocate memroy region which size is multiple of SDIO_BLOCK_SIZE. We
just need to make sure the relocation of memory for making the address
BTSDIO_DMA_ALIGN-aligned does not cause out-of-bound access.

CC: Wei-Ning Huang 
CC: Daniel Kurtz 
CC: Amitkumar Karwar 

Signed-off-by: Ricky Liang 
---
 drivers/bluetooth/btmrvl_sdio.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index f425ddf..ecc0191 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -1071,8 +1071,6 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 {
struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
int ret = 0;
-   int buf_block_len;
-   int blksz;
int i = 0;
u8 *buf = NULL;
void *tmpbuf = NULL;
@@ -1085,7 +1083,7 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 
buf = payload;
if ((unsigned long) payload & (BTSDIO_DMA_ALIGN - 1)) {
-   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN);
+   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN) + BTSDIO_DMA_ALIGN;
tmpbuf = kzalloc(tmpbufsz, GFP_KERNEL);
if (!tmpbuf)
return -ENOMEM;
@@ -1093,15 +1091,12 @@ static int btmrvl_sdio_host_to_card(struct 
btmrvl_private *priv,
memcpy(buf, payload, nb);
}
 
-   blksz = SDIO_BLOCK_SIZE;
-   buf_block_len = DIV_ROUND_UP(nb, blksz);
-
sdio_claim_host(card->func);
 
do {
/* Transfer data to card */
ret = sdio_writesb(card->func, card->ioport, buf,
-  buf_block_len * blksz);
+  nb);
if (ret < 0) {
i++;
BT_ERR("i=%d writesb failed: %d", i, ret);
-- 
2.1.2

[PATCH v2] Bluetooth: btmrvl: fix slab-out-of-bounds access in btmrvl_sdio

[Ricky Liang]

Kasan reported slab-out-of-bounds access in btmrvl_sdio:

[   33.055400] 
==
[   33.062585] BUG: KASAN: slab-out-of-bounds in memcpy+0x24/0x50 at addr 
ffc0d89b4a00
[   33.070529] Read of size 256 by task btmrvl_main_ser/3576
[   33.075885] 
=
[   33.084002] BUG kmalloc-256 (Tainted: GB ): kasan: bad access 
detected
[   33.091511] 
-

[   33.413498] Call trace:
[   33.415928] [] dump_backtrace+0x0/0x190
[   33.421288] [] show_stack+0x1c/0x28
[   33.426305] [] dump_stack+0xa0/0xf8
[   33.431320] [] print_trailer+0x158/0x16c
[   33.436765] [] object_err+0x48/0x5c
[   33.441780] [] kasan_report+0x344/0x510
[   33.447141] [] __asan_loadN+0x20/0x150
[   33.452413] [] memcpy+0x20/0x50
[   33.457084] [] swiotlb_tbl_map_single+0x2ec/0x310
[   33.463305] [] map_single+0x24/0x30
[   33.468320] [] swiotlb_map_sg_attrs+0xec/0x21c
[   33.474286] [] __swiotlb_map_sg_attrs+0x48/0xec
[   33.480339] [] msdc_prepare_data.isra.11+0xf0/0x11c
[   33.486733] [] msdc_ops_request+0x74/0xf0
[   33.492266] [] __mmc_start_request+0x78/0x8c
[   33.498057] [] mmc_start_request+0x220/0x240
[   33.503848] [] mmc_wait_for_req+0x78/0x250
[   33.509468] [] mmc_io_rw_extended+0x2ec/0x388
[   33.515347] [] sdio_io_rw_ext_helper+0x160/0x268
[   33.521483] [] sdio_writesb+0x40/0x50
[   33.526677] [] btmrvl_sdio_host_to_card+0x124/0x1bc 
[btmrvl_sdio]
[   33.534283] [] btmrvl_service_main_thread+0x384/0x428 
[btmrvl]
[   33.541626] [] kthread+0x140/0x158
[   33.546550] Memory state around the buggy address:
[   33.551305]  ffc0d89b4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.558474]  ffc0d89b4a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[   33.565643] >ffc0d89b4a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
fc
[   33.572809] ^
[   33.579889]  ffc0d89b4b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.587055]  ffc0d89b4b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.594221] 
==

The cause of this is that btmrvl_sdio_host_to_card can access memory region
out of its allocated space due to:

  1. the requested block size is smaller than SDIO_BLOCK_SIZE, and/or
  2. the allocated memory is not BTSDIO_DMA_ALIGN-aligned.

Since sdio_writesb() is able to handle any size of data it's not necessary
to re-allocate memroy region which size is multiple of SDIO_BLOCK_SIZE. We
just need to make sure the relocation of memory for making the address
BTSDIO_DMA_ALIGN-aligned does not cause out-of-bound access.

CC: Wei-Ning Huang 
CC: Daniel Kurtz 
CC: Amitkumar Karwar 

Signed-off-by: Ricky Liang 
---
 drivers/bluetooth/btmrvl_sdio.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index f425ddf..ecc0191 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -1071,8 +1071,6 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 {
struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
int ret = 0;
-   int buf_block_len;
-   int blksz;
int i = 0;
u8 *buf = NULL;
void *tmpbuf = NULL;
@@ -1085,7 +1083,7 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 
buf = payload;
if ((unsigned long) payload & (BTSDIO_DMA_ALIGN - 1)) {
-   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN);
+   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN) + BTSDIO_DMA_ALIGN;
tmpbuf = kzalloc(tmpbufsz, GFP_KERNEL);
if (!tmpbuf)
return -ENOMEM;
@@ -1093,15 +1091,12 @@ static int btmrvl_sdio_host_to_card(struct 
btmrvl_private *priv,
memcpy(buf, payload, nb);
}
 
-   blksz = SDIO_BLOCK_SIZE;
-   buf_block_len = DIV_ROUND_UP(nb, blksz);
-
sdio_claim_host(card->func);
 
do {
/* Transfer data to card */
ret = sdio_writesb(card->func, card->ioport, buf,
-  buf_block_len * blksz);
+  nb);
if (ret < 0) {
i++;
BT_ERR("i=%d writesb failed: %d", i, ret);
-- 
2.1.2

Re: Re: [PATCH] arm:swiotlb:keep disabled in default configuration

[Manjeet Pawar]

>> >
>> > From: Rohit Thapliyal 
>> >
>> > swiotlb implementation not required to be enabled in arm and
>> > disabling it reduces uImage size by 16KB.
>> >
>> 
>> How so? There are no DMA operations on ARM?

>Xen actively uses the swiotlb on ARM, see

>arch/arm64/include/asm/dma-mapping.h:get_dma_ops
>arch/arm/xen/mm.c:xen_swiotlb_dma_ops

Sorry, my last reply didn't go through so sending it again.
If XEN is enabled, it shall eventually enable SWIOTLB through SWIOTLB_XEN. So, 
there is no need to keep it enabled otherwise.


--- Original Message ---
Sender : Stefano Stabellini
Date : Jun 24, 2016 01:00 (GMT+09:00)
Title : Re: [PATCH] arm:swiotlb:keep disabled in default configuration

On Thu, 23 Jun 2016, Stefano Stabellini wrote:
> On Jun 23, 2016 8:27 AM, "Manjeet Pawar" wrote:
> >
> > From: Rohit Thapliyal 
> >
> > swiotlb implementation not required to be enabled in arm and
> > disabling it reduces uImage size by 16KB.
> >
> 
> How so? There are no DMA operations on ARM?

Xen actively uses the swiotlb on ARM, see

arch/arm64/include/asm/dma-mapping.h:get_dma_ops
arch/arm/xen/mm.c:xen_swiotlb_dma_ops


> > Signed-off-by: Rohit Thapliyal 
> > Signed-off-by: Ajeet Kumar Yadav 
> > ---
> >  arch/arm/Kconfig |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 90542db..ae65f29 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1754,7 +1754,7 @@ config SECCOMP
> >   defined by each seccomp mode.
> >
> >  config SWIOTLB
> > -   def_bool y
> > +   def_bool n
> >
> >  config IOMMU_HELPER
> > def_bool SWIOTLB
> > --
> > 1.7.9.5
> >
> 

Re: Re: [PATCH] arm:swiotlb:keep disabled in default configuration

[Manjeet Pawar]

>> >
>> > From: Rohit Thapliyal 
>> >
>> > swiotlb implementation not required to be enabled in arm and
>> > disabling it reduces uImage size by 16KB.
>> >
>> 
>> How so? There are no DMA operations on ARM?

>Xen actively uses the swiotlb on ARM, see

>arch/arm64/include/asm/dma-mapping.h:get_dma_ops
>arch/arm/xen/mm.c:xen_swiotlb_dma_ops

Sorry, my last reply didn't go through so sending it again.
If XEN is enabled, it shall eventually enable SWIOTLB through SWIOTLB_XEN. So, 
there is no need to keep it enabled otherwise.


--- Original Message ---
Sender : Stefano Stabellini
Date : Jun 24, 2016 01:00 (GMT+09:00)
Title : Re: [PATCH] arm:swiotlb:keep disabled in default configuration

On Thu, 23 Jun 2016, Stefano Stabellini wrote:
> On Jun 23, 2016 8:27 AM, "Manjeet Pawar" wrote:
> >
> > From: Rohit Thapliyal 
> >
> > swiotlb implementation not required to be enabled in arm and
> > disabling it reduces uImage size by 16KB.
> >
> 
> How so? There are no DMA operations on ARM?

Xen actively uses the swiotlb on ARM, see

arch/arm64/include/asm/dma-mapping.h:get_dma_ops
arch/arm/xen/mm.c:xen_swiotlb_dma_ops


> > Signed-off-by: Rohit Thapliyal 
> > Signed-off-by: Ajeet Kumar Yadav 
> > ---
> >  arch/arm/Kconfig |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 90542db..ae65f29 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1754,7 +1754,7 @@ config SECCOMP
> >   defined by each seccomp mode.
> >
> >  config SWIOTLB
> > -   def_bool y
> > +   def_bool n
> >
> >  config IOMMU_HELPER
> > def_bool SWIOTLB
> > --
> > 1.7.9.5
> >
> 

[PATCH] Bluetooth: btmrvl: fix slab-out-of-bounds access in btmrvl_sdio

[Ricky Liang]

Kasan reported slab-out-of-bounds access in btmrvl_sdio:

[   33.055400] 
==
[   33.062585] BUG: KASAN: slab-out-of-bounds in memcpy+0x24/0x50 at addr 
ffc0d89b4a00
[   33.070529] Read of size 256 by task btmrvl_main_ser/3576
[   33.075885] 
=
[   33.084002] BUG kmalloc-256 (Tainted: GB ): kasan: bad access 
detected
[   33.091511] 
-

[   33.413498] Call trace:
[   33.415928] [] dump_backtrace+0x0/0x190
[   33.421288] [] show_stack+0x1c/0x28
[   33.426305] [] dump_stack+0xa0/0xf8
[   33.431320] [] print_trailer+0x158/0x16c
[   33.436765] [] object_err+0x48/0x5c
[   33.441780] [] kasan_report+0x344/0x510
[   33.447141] [] __asan_loadN+0x20/0x150
[   33.452413] [] memcpy+0x20/0x50
[   33.457084] [] swiotlb_tbl_map_single+0x2ec/0x310
[   33.463305] [] map_single+0x24/0x30
[   33.468320] [] swiotlb_map_sg_attrs+0xec/0x21c
[   33.474286] [] __swiotlb_map_sg_attrs+0x48/0xec
[   33.480339] [] msdc_prepare_data.isra.11+0xf0/0x11c
[   33.486733] [] msdc_ops_request+0x74/0xf0
[   33.492266] [] __mmc_start_request+0x78/0x8c
[   33.498057] [] mmc_start_request+0x220/0x240
[   33.503848] [] mmc_wait_for_req+0x78/0x250
[   33.509468] [] mmc_io_rw_extended+0x2ec/0x388
[   33.515347] [] sdio_io_rw_ext_helper+0x160/0x268
[   33.521483] [] sdio_writesb+0x40/0x50
[   33.526677] [] btmrvl_sdio_host_to_card+0x124/0x1bc 
[btmrvl_sdio]
[   33.534283] [] btmrvl_service_main_thread+0x384/0x428 
[btmrvl]
[   33.541626] [] kthread+0x140/0x158
[   33.546550] Memory state around the buggy address:
[   33.551305]  ffc0d89b4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.558474]  ffc0d89b4a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[   33.565643] >ffc0d89b4a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
fc
[   33.572809] ^
[   33.579889]  ffc0d89b4b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.587055]  ffc0d89b4b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.594221] 
==

The cause of this is that btmrvl_sdio_host_to_card can access memory region
out of its allocated space due to:

  1. the requested block size is smaller than SDIO_BLOCK_SIZE, and/or
  2. the allocated memory is not BTSDIO_DMA_ALIGN-aligned.

Since sdio_writesb() is able to handle any size of data it's not necessary
to re-allocate memroy region which size is multiple of SDIO_BLOCK_SIZE. We
just need to make sure the relocation of memory for making the address
BTSDIO_DMA_ALIGN-aligned does not cause out-of-bound access.

CC: Wei-Ning Huang 
CC: Daniel Kurtz 
CC: Amitkumar Karwar 

Signed-off-by: Ricky Liang 
---
 drivers/bluetooth/btmrvl_sdio.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index f425ddf..ecc0191 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -1071,8 +1071,6 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 {
struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
int ret = 0;
-   int buf_block_len;
-   int blksz;
int i = 0;
u8 *buf = NULL;
void *tmpbuf = NULL;
@@ -1085,7 +1083,7 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 
buf = payload;
if ((unsigned long) payload & (BTSDIO_DMA_ALIGN - 1)) {
-   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN);
+   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN) + BTSDIO_DMA_ALIGN;
tmpbuf = kzalloc(tmpbufsz, GFP_KERNEL);
if (!tmpbuf)
return -ENOMEM;
@@ -1093,15 +1091,12 @@ static int btmrvl_sdio_host_to_card(struct 
btmrvl_private *priv,
memcpy(buf, payload, nb);
}
 
-   blksz = SDIO_BLOCK_SIZE;
-   buf_block_len = DIV_ROUND_UP(nb, blksz);
-
sdio_claim_host(card->func);
 
do {
/* Transfer data to card */
ret = sdio_writesb(card->func, card->ioport, buf,
-  buf_block_len * blksz);
+  nb);
if (ret < 0) {
i++;
BT_ERR("i=%d writesb failed: %d", i, ret);
-- 
2.1.2

[PATCH] Bluetooth: btmrvl: fix slab-out-of-bounds access in btmrvl_sdio

[Ricky Liang]

Kasan reported slab-out-of-bounds access in btmrvl_sdio:

[   33.055400] 
==
[   33.062585] BUG: KASAN: slab-out-of-bounds in memcpy+0x24/0x50 at addr 
ffc0d89b4a00
[   33.070529] Read of size 256 by task btmrvl_main_ser/3576
[   33.075885] 
=
[   33.084002] BUG kmalloc-256 (Tainted: GB ): kasan: bad access 
detected
[   33.091511] 
-

[   33.413498] Call trace:
[   33.415928] [] dump_backtrace+0x0/0x190
[   33.421288] [] show_stack+0x1c/0x28
[   33.426305] [] dump_stack+0xa0/0xf8
[   33.431320] [] print_trailer+0x158/0x16c
[   33.436765] [] object_err+0x48/0x5c
[   33.441780] [] kasan_report+0x344/0x510
[   33.447141] [] __asan_loadN+0x20/0x150
[   33.452413] [] memcpy+0x20/0x50
[   33.457084] [] swiotlb_tbl_map_single+0x2ec/0x310
[   33.463305] [] map_single+0x24/0x30
[   33.468320] [] swiotlb_map_sg_attrs+0xec/0x21c
[   33.474286] [] __swiotlb_map_sg_attrs+0x48/0xec
[   33.480339] [] msdc_prepare_data.isra.11+0xf0/0x11c
[   33.486733] [] msdc_ops_request+0x74/0xf0
[   33.492266] [] __mmc_start_request+0x78/0x8c
[   33.498057] [] mmc_start_request+0x220/0x240
[   33.503848] [] mmc_wait_for_req+0x78/0x250
[   33.509468] [] mmc_io_rw_extended+0x2ec/0x388
[   33.515347] [] sdio_io_rw_ext_helper+0x160/0x268
[   33.521483] [] sdio_writesb+0x40/0x50
[   33.526677] [] btmrvl_sdio_host_to_card+0x124/0x1bc 
[btmrvl_sdio]
[   33.534283] [] btmrvl_service_main_thread+0x384/0x428 
[btmrvl]
[   33.541626] [] kthread+0x140/0x158
[   33.546550] Memory state around the buggy address:
[   33.551305]  ffc0d89b4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.558474]  ffc0d89b4a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[   33.565643] >ffc0d89b4a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
fc
[   33.572809] ^
[   33.579889]  ffc0d89b4b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.587055]  ffc0d89b4b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.594221] 
==

The cause of this is that btmrvl_sdio_host_to_card can access memory region
out of its allocated space due to:

  1. the requested block size is smaller than SDIO_BLOCK_SIZE, and/or
  2. the allocated memory is not BTSDIO_DMA_ALIGN-aligned.

Since sdio_writesb() is able to handle any size of data it's not necessary
to re-allocate memroy region which size is multiple of SDIO_BLOCK_SIZE. We
just need to make sure the relocation of memory for making the address
BTSDIO_DMA_ALIGN-aligned does not cause out-of-bound access.

CC: Wei-Ning Huang 
CC: Daniel Kurtz 
CC: Amitkumar Karwar 

Signed-off-by: Ricky Liang 
---
 drivers/bluetooth/btmrvl_sdio.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index f425ddf..ecc0191 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -1071,8 +1071,6 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 {
struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
int ret = 0;
-   int buf_block_len;
-   int blksz;
int i = 0;
u8 *buf = NULL;
void *tmpbuf = NULL;
@@ -1085,7 +1083,7 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 
buf = payload;
if ((unsigned long) payload & (BTSDIO_DMA_ALIGN - 1)) {
-   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN);
+   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN) + BTSDIO_DMA_ALIGN;
tmpbuf = kzalloc(tmpbufsz, GFP_KERNEL);
if (!tmpbuf)
return -ENOMEM;
@@ -1093,15 +1091,12 @@ static int btmrvl_sdio_host_to_card(struct 
btmrvl_private *priv,
memcpy(buf, payload, nb);
}
 
-   blksz = SDIO_BLOCK_SIZE;
-   buf_block_len = DIV_ROUND_UP(nb, blksz);
-
sdio_claim_host(card->func);
 
do {
/* Transfer data to card */
ret = sdio_writesb(card->func, card->ioport, buf,
-  buf_block_len * blksz);
+  nb);
if (ret < 0) {
i++;
BT_ERR("i=%d writesb failed: %d", i, ret);
-- 
2.1.2

Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT

[kbuild test robot]

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb 
ci-for-usb-next
config: x86_64-randconfig-h0-06270614 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "of_device_request_module" [drivers/usb/common/ulpi.ko] undefined!
>> ERROR: "of_device_get_modalias" [drivers/usb/common/ulpi.ko] undefined!
>> ERROR: "of_device_uevent_modalias" [drivers/usb/common/ulpi.ko] undefined!

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


.config.gz
Description: Binary data

Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT

[kbuild test robot]

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb 
ci-for-usb-next
config: x86_64-randconfig-h0-06270614 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "of_device_request_module" [drivers/usb/common/ulpi.ko] undefined!
>> ERROR: "of_device_get_modalias" [drivers/usb/common/ulpi.ko] undefined!
>> ERROR: "of_device_uevent_modalias" [drivers/usb/common/ulpi.ko] undefined!

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


.config.gz
Description: Binary data

[x86] ddf4847e6f: BUG: unable to handle kernel paging request at ffffffff03862040

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
commit ddf4847e6f114c522fefb24c16fc7a1d75138f9f ("x86: Move thread_info into 
task_struct")


on test machine: vm-kbuild-yocto-x86_64: 1 threads qemu-system-x86_64 
-enable-kvm -cpu SandyBridge with 320M memory

caused below changes:


+--+++
|  | aeea9c1c41 | ddf4847e6f |
+--+++
| boot_successes   | 6  | 0  |
| boot_failures| 0  | 8  |
| BUG:unable_to_handle_kernel  | 0  | 8  |
| Oops:#[##]   | 0  | 8  |
| RIP:entry_SYSCALL_64_after_swapgs| 0  | 8  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 8  |
+--+++



[   10.105818] Freeing unused kernel memory: 1956K (880001617000 - 
88000180)
[   10.113305] Freeing unused kernel memory: 836K (880001b2f000 - 
880001c0)
[   10.132456] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[   10.134895] BUG: unable to handle kernel paging request at 03862040
[   10.136663] IP: [] entry_SYSCALL_64_after_swapgs+0x36/0x4c
[   10.138365] PGD 1c0d067 PUD 0 
[   10.139426] Oops:  [#1]
[   10.140235] Modules linked in:
[   10.141200] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-rc4-00254-gddf4847 #1
[   10.142752] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   10.147089] task: 88001205c040 ti: 88001205c040 task.ti: 
88001205c040
[   10.148945] RIP: 0010:[]  [] 
entry_SYSCALL_64_after_swapgs+0x36/0x4c
[   10.151240] RSP: 0018:880012063f58  EFLAGS: 00010082
[   10.152485] RAX: 000c RBX: 0008 RCX: 7f9b93195c9a
[   10.154058] RDX:  RSI: 7f9b931994a0 RDI: 
[   10.155635] RBP: 078bfbff R08: 7ffe3cb83479 R09: 7ffe3cbef000
[   10.157205] R10: 037f R11: 0246 R12: 7ffe3cb83489
[   10.158778] R13:  R14: 004028c4 R15: 1000
[   10.160481] FS:  () GS:81c2f000() 
knlGS:
[   10.163887] CS:  0010 DS:  ES:  CR0: 80050033
[   10.165221] CR2: 03862040 CR3: 13928000 CR4: 000406b0
[   10.166802] Stack:
[   10.167469]  7f9b93181a18 7f9b93181320 7f9b93181a18 
0046
[   10.169734]  880012063f98 810a5c6a 0246 
037f
[   10.171982]  7ffe3cbef000 7ffe3cb83479 ffda 
7f9b93195c9a
[   10.174223] Call Trace:
[   10.174990]  [] ? trace_hardirqs_off_caller+0x36/0xa4
[   10.176457] Code: 25 84 a3 c2 81 e8 f4 0d 9f ff 6a 2b ff 34 25 00 80 c2 81 
41 53 6a 33 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 83 ec 30 <65> 4c 
8b 1c 25 40 30 c3 81 41 f7 03 ff ff 08 10 0f 85 c2 00 00 
[   10.194036] RIP  [] entry_SYSCALL_64_after_swapgs+0x36/0x4c
[   10.195727]  RSP 
[   10.196655] CR2: 03862040
[   10.197564] ---[ end trace bedce588960ef6c2 ]---
[   10.198696] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
/pkg/linux/x86_64-randconfig-h0-06262018/gcc-6/ddf4847e6f114c522fefb24c16fc7a1d75138f9f/vmlinuz-4.7.0-rc4-00254-gddf4847
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-51/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-h0-06262018-ddf4847e6f114c522fefb24c16fc7a1d75138f9f-20160627-110660-dxqka-0.yaml
 ARCH=x86_64 kconfig=x86_64-randconfig-h0-06262018 
branch=linux-devel/devel-catchup-201606270129 
commit=ddf4847e6f114c522fefb24c16fc7a1d75138f9f 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-h0-06262018/gcc-6/ddf4847e6f114c522fefb24c16fc7a1d75138f9f/vmlinuz-4.7.0-rc4-00254-gddf4847
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-h0-06262018/gcc-6/ddf4847e6f114c522fefb24c16fc7a1d75138f9f/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-kbuild-yocto-x86_64-51::dhcp drbd.minor_count=8'  -initrd 
/fs/sdf1/initrd-vm-kbuild-yocto-x86_64-51 -m 320 -smp 1 -device 
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
i6300esb -rtc base=localtime -drive 
file=/fs/sdf1/disk0-vm-kbuild-yocto-x86_64-51,media=disk,if=virtio -pidfile 
/dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-51 -serial 

[x86] ddf4847e6f: BUG: unable to handle kernel paging request at ffffffff03862040

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
commit ddf4847e6f114c522fefb24c16fc7a1d75138f9f ("x86: Move thread_info into 
task_struct")


on test machine: vm-kbuild-yocto-x86_64: 1 threads qemu-system-x86_64 
-enable-kvm -cpu SandyBridge with 320M memory

caused below changes:


+--+++
|  | aeea9c1c41 | ddf4847e6f |
+--+++
| boot_successes   | 6  | 0  |
| boot_failures| 0  | 8  |
| BUG:unable_to_handle_kernel  | 0  | 8  |
| Oops:#[##]   | 0  | 8  |
| RIP:entry_SYSCALL_64_after_swapgs| 0  | 8  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 8  |
+--+++



[   10.105818] Freeing unused kernel memory: 1956K (880001617000 - 
88000180)
[   10.113305] Freeing unused kernel memory: 836K (880001b2f000 - 
880001c0)
[   10.132456] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[   10.134895] BUG: unable to handle kernel paging request at 03862040
[   10.136663] IP: [] entry_SYSCALL_64_after_swapgs+0x36/0x4c
[   10.138365] PGD 1c0d067 PUD 0 
[   10.139426] Oops:  [#1]
[   10.140235] Modules linked in:
[   10.141200] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-rc4-00254-gddf4847 #1
[   10.142752] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   10.147089] task: 88001205c040 ti: 88001205c040 task.ti: 
88001205c040
[   10.148945] RIP: 0010:[]  [] 
entry_SYSCALL_64_after_swapgs+0x36/0x4c
[   10.151240] RSP: 0018:880012063f58  EFLAGS: 00010082
[   10.152485] RAX: 000c RBX: 0008 RCX: 7f9b93195c9a
[   10.154058] RDX:  RSI: 7f9b931994a0 RDI: 
[   10.155635] RBP: 078bfbff R08: 7ffe3cb83479 R09: 7ffe3cbef000
[   10.157205] R10: 037f R11: 0246 R12: 7ffe3cb83489
[   10.158778] R13:  R14: 004028c4 R15: 1000
[   10.160481] FS:  () GS:81c2f000() 
knlGS:
[   10.163887] CS:  0010 DS:  ES:  CR0: 80050033
[   10.165221] CR2: 03862040 CR3: 13928000 CR4: 000406b0
[   10.166802] Stack:
[   10.167469]  7f9b93181a18 7f9b93181320 7f9b93181a18 
0046
[   10.169734]  880012063f98 810a5c6a 0246 
037f
[   10.171982]  7ffe3cbef000 7ffe3cb83479 ffda 
7f9b93195c9a
[   10.174223] Call Trace:
[   10.174990]  [] ? trace_hardirqs_off_caller+0x36/0xa4
[   10.176457] Code: 25 84 a3 c2 81 e8 f4 0d 9f ff 6a 2b ff 34 25 00 80 c2 81 
41 53 6a 33 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 83 ec 30 <65> 4c 
8b 1c 25 40 30 c3 81 41 f7 03 ff ff 08 10 0f 85 c2 00 00 
[   10.194036] RIP  [] entry_SYSCALL_64_after_swapgs+0x36/0x4c
[   10.195727]  RSP 
[   10.196655] CR2: 03862040
[   10.197564] ---[ end trace bedce588960ef6c2 ]---
[   10.198696] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
/pkg/linux/x86_64-randconfig-h0-06262018/gcc-6/ddf4847e6f114c522fefb24c16fc7a1d75138f9f/vmlinuz-4.7.0-rc4-00254-gddf4847
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-51/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-h0-06262018-ddf4847e6f114c522fefb24c16fc7a1d75138f9f-20160627-110660-dxqka-0.yaml
 ARCH=x86_64 kconfig=x86_64-randconfig-h0-06262018 
branch=linux-devel/devel-catchup-201606270129 
commit=ddf4847e6f114c522fefb24c16fc7a1d75138f9f 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-h0-06262018/gcc-6/ddf4847e6f114c522fefb24c16fc7a1d75138f9f/vmlinuz-4.7.0-rc4-00254-gddf4847
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-h0-06262018/gcc-6/ddf4847e6f114c522fefb24c16fc7a1d75138f9f/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-kbuild-yocto-x86_64-51::dhcp drbd.minor_count=8'  -initrd 
/fs/sdf1/initrd-vm-kbuild-yocto-x86_64-51 -m 320 -smp 1 -device 
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
i6300esb -rtc base=localtime -drive 
file=/fs/sdf1/disk0-vm-kbuild-yocto-x86_64-51,media=disk,if=virtio -pidfile 
/dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-51 -serial 

Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

[Guenter Roeck]

On Sun, Jun 26, 2016 at 7:19 PM, Chris Zhong  wrote:
> Hi Heiko
>
>
> On 06/25/2016 03:39 AM, Heiko Stuebner wrote:
>>
>> Am Donnerstag, 23. Juni 2016, 18:27:52 schrieb Kishon Vijay Abraham I:
>>>
>>> Hi,
>>>
>>> On Thursday 23 June 2016 06:21 PM, Chris Zhong wrote:

 Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
 Type-C PHY is designed to support the USB3 and DP applications. The
 PHY basically has two main components: USB3 and DisplyPort. USB3
 operates in SuperSpeed mode and the DP can operate at RBR, HBR and
 HBR2 data rates.

 Signed-off-by: Chris Zhong 
 Signed-off-by: Kever Yang 

 ---

 Changes in v3:
 - remove the phy framework(Kishon Vijay Abraham I)
 - add parentheses around the macro
 - use a single space between type and name
 - add spaces after opening and before closing braces.
 - use u16 for register value
 - remove type-c phy header file
 - CodingStyle optimization
 - use some cable extcon to get type-c port information
 - add a extcon to notify Display Port

 Changes in v2:
 - select RESET_CONTROLLER
 - alphabetic order
 - modify some spelling mistakes
 - make mode cleaner
 - use bool for enable/disable
 - check all of the return value
 - return a better err number
 - use more readx_poll_timeout()
 - clk_disable_unprepare(tcphy->clk_ref);
 - remove unuse functions, rockchip_typec_phy_power_on/off
 - remove unnecessary typecast from void *
 - use dts node to distinguish between phys.

 Changes in v1:
 - update the licence note
 - init core clock to 50MHz
 - use extcon API
 - remove unused global
 - add some comments for magic num
 - change usleep_range(1000, 2000) tousleep_range(1000, 1050)
 - remove __func__ from dev_err
 - return err number when get clk failed
 - remove ADDR_ADJ define
 - use devm_clk_get(>dev, "tcpdcore")

   drivers/phy/Kconfig  |8 +
   drivers/phy/Makefile |1 +
   drivers/phy/phy-rockchip-typec.c | 1027
   ++ 3 files changed, 1036
   insertions(+)
   create mode 100644 drivers/phy/phy-rockchip-typec.c

 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 26566db..ec87b3a 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -351,6 +351,14 @@ config PHY_ROCKCHIP_DP

 help

   Enable this to support the Rockchip Display Port PHY.

 +config PHY_ROCKCHIP_TYPEC
 +   tristate "Rockchip TYPEC PHY Driver"
 +   depends on ARCH_ROCKCHIP && OF
 +   select GENERIC_PHY
>>>
>>> Why? None of the generic PHY API's are used here. Why do you want select
>>> generic PHY?
>>
>> I'm actually wondering, why there are no phy ops to start and stop the py.
>> Right now the device seems to be on and handling all the extcon notifies
>> all
>> the time even if no-one is using the phy.
>>
>> There are two users of this phy, the dp-controller as well as some usb
>> component. The phy framework is nicely refcounted, so can handle any
>> number
>> of phy users and somehow I'd expect the phy to do nothing (and try to not
>> consume power) if neither the dp-controller nor the usb-part is actually
>> running.
>>
>> It may very well be my ignorance, but Chris could you explain, if there is
>> a
>> reason for this?
>>
>>
>> Thanks
>> Heiko
>>
>>
> It is good idea, The USB3 and DP controller detect the extcon cable state:
> USB/USB HOST/DP. If a Type-C device plugged, call phy power on, the phy
> driver get all the state of extcon: dfp, ufp, dp, flip, pin assignment, and
> then finish the phy init. So the phy driver need not register extcon
> notification.
> But this mechanism allows phy driver only focus plug/unplug event, if some
> other things happen, such as data role change, the phy will not be notified.
> I'm not sure if this situation exists.

Sorry, I think I am lost (again).

All roles can change on the fly. Role changes can be triggered from
user space, or by the remote partner. If we restrict such role
changes, we would have to reject all locally triggered role change
requests, as well as all role change requests from the remote, after
the initial connection was established. I don't really see the point
of doing that, though. Wasn't this what the notifications were all
about ?

Guenter

Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

[Guenter Roeck]

On Sun, Jun 26, 2016 at 7:19 PM, Chris Zhong  wrote:
> Hi Heiko
>
>
> On 06/25/2016 03:39 AM, Heiko Stuebner wrote:
>>
>> Am Donnerstag, 23. Juni 2016, 18:27:52 schrieb Kishon Vijay Abraham I:
>>>
>>> Hi,
>>>
>>> On Thursday 23 June 2016 06:21 PM, Chris Zhong wrote:

 Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
 Type-C PHY is designed to support the USB3 and DP applications. The
 PHY basically has two main components: USB3 and DisplyPort. USB3
 operates in SuperSpeed mode and the DP can operate at RBR, HBR and
 HBR2 data rates.

 Signed-off-by: Chris Zhong 
 Signed-off-by: Kever Yang 

 ---

 Changes in v3:
 - remove the phy framework(Kishon Vijay Abraham I)
 - add parentheses around the macro
 - use a single space between type and name
 - add spaces after opening and before closing braces.
 - use u16 for register value
 - remove type-c phy header file
 - CodingStyle optimization
 - use some cable extcon to get type-c port information
 - add a extcon to notify Display Port

 Changes in v2:
 - select RESET_CONTROLLER
 - alphabetic order
 - modify some spelling mistakes
 - make mode cleaner
 - use bool for enable/disable
 - check all of the return value
 - return a better err number
 - use more readx_poll_timeout()
 - clk_disable_unprepare(tcphy->clk_ref);
 - remove unuse functions, rockchip_typec_phy_power_on/off
 - remove unnecessary typecast from void *
 - use dts node to distinguish between phys.

 Changes in v1:
 - update the licence note
 - init core clock to 50MHz
 - use extcon API
 - remove unused global
 - add some comments for magic num
 - change usleep_range(1000, 2000) tousleep_range(1000, 1050)
 - remove __func__ from dev_err
 - return err number when get clk failed
 - remove ADDR_ADJ define
 - use devm_clk_get(>dev, "tcpdcore")

   drivers/phy/Kconfig  |8 +
   drivers/phy/Makefile |1 +
   drivers/phy/phy-rockchip-typec.c | 1027
   ++ 3 files changed, 1036
   insertions(+)
   create mode 100644 drivers/phy/phy-rockchip-typec.c

 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 26566db..ec87b3a 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -351,6 +351,14 @@ config PHY_ROCKCHIP_DP

 help

   Enable this to support the Rockchip Display Port PHY.

 +config PHY_ROCKCHIP_TYPEC
 +   tristate "Rockchip TYPEC PHY Driver"
 +   depends on ARCH_ROCKCHIP && OF
 +   select GENERIC_PHY
>>>
>>> Why? None of the generic PHY API's are used here. Why do you want select
>>> generic PHY?
>>
>> I'm actually wondering, why there are no phy ops to start and stop the py.
>> Right now the device seems to be on and handling all the extcon notifies
>> all
>> the time even if no-one is using the phy.
>>
>> There are two users of this phy, the dp-controller as well as some usb
>> component. The phy framework is nicely refcounted, so can handle any
>> number
>> of phy users and somehow I'd expect the phy to do nothing (and try to not
>> consume power) if neither the dp-controller nor the usb-part is actually
>> running.
>>
>> It may very well be my ignorance, but Chris could you explain, if there is
>> a
>> reason for this?
>>
>>
>> Thanks
>> Heiko
>>
>>
> It is good idea, The USB3 and DP controller detect the extcon cable state:
> USB/USB HOST/DP. If a Type-C device plugged, call phy power on, the phy
> driver get all the state of extcon: dfp, ufp, dp, flip, pin assignment, and
> then finish the phy init. So the phy driver need not register extcon
> notification.
> But this mechanism allows phy driver only focus plug/unplug event, if some
> other things happen, such as data role change, the phy will not be notified.
> I'm not sure if this situation exists.

Sorry, I think I am lost (again).

All roles can change on the fly. Role changes can be triggered from
user space, or by the remote partner. If we restrict such role
changes, we would have to reject all locally triggered role change
requests, as well as all role change requests from the remote, after
the initial connection was established. I don't really see the point
of doing that, though. Wasn't this what the notifications were all
about ?

Guenter

Re: [PATCH 2/2] mm: workingset: printk missing log level, use pr_info()

[Joe Perches]

On Mon, 2016-06-27 at 09:01 +1000, Anton Blanchard wrote:
> commit 612e44939c3c ("mm: workingset: eviction buckets for bigmem/lowbit
> machines") added a printk without a log level. Quieten it by using
> pr_info().
[]
> diff --git a/mm/workingset.c b/mm/workingset.c
[]
> @@ -491,7 +491,7 @@ static int __init workingset_init(void)
>   max_order = fls_long(totalram_pages - 1);
>   if (max_order > timestamp_bits)
>   bucket_order = max_order - timestamp_bits;
> - printk("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
> + pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
>      timestamp_bits, max_order, bucket_order);

Because it's possible to have more printks added,
perhaps it's better to add

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

before any #include and remove the "workingset: "
prefix here.

Re: [PATCH 2/2] mm: workingset: printk missing log level, use pr_info()

[Joe Perches]

On Mon, 2016-06-27 at 09:01 +1000, Anton Blanchard wrote:
> commit 612e44939c3c ("mm: workingset: eviction buckets for bigmem/lowbit
> machines") added a printk without a log level. Quieten it by using
> pr_info().
[]
> diff --git a/mm/workingset.c b/mm/workingset.c
[]
> @@ -491,7 +491,7 @@ static int __init workingset_init(void)
>   max_order = fls_long(totalram_pages - 1);
>   if (max_order > timestamp_bits)
>   bucket_order = max_order - timestamp_bits;
> - printk("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
> + pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
>      timestamp_bits, max_order, bucket_order);

Because it's possible to have more printks added,
perhaps it's better to add

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

before any #include and remove the "workingset: "
prefix here.

Re: [PATCH] m32r: fix build warning about putc

[kbuild test robot]

Hi,

[auto build test WARNING on v4.7-rc5]
[also build test WARNING on next-20160624]
[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/Sudip-Mukherjee/m32r-fix-build-warning-about-putc/20160627-094312
config: m32r-m32104ut_defconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All warnings (new ones prefixed by >>):

   In file included from arch/m32r/boot/compressed/misc.c:25:0:
   arch/m32r/boot/compressed/m32r_sio.c: In function 'puts':
>> arch/m32r/boot/compressed/m32r_sio.c:16:2: warning: suggest parentheses 
>> around assignment used as truth value [-Wparentheses]
 while (c = *s++)
 ^

vim +16 arch/m32r/boot/compressed/m32r_sio.c

 1  /*
 2   * arch/m32r/boot/compressed/m32r_sio.c
 3   *
 4   * 2003-02-12:  Takeo Takahashi
 5   * 2006-11-30:  OPSPUT support by Kazuhiro Inaoka
 6   *
 7   */
 8  
 9  #include 
10  
11  static void m32r_putc(char c);
12  
13  static int puts(const char *s)
14  {
15  char c;
  > 16  while (c = *s++)
17  m32r_putc(c);
18  return 0;
19  }
20  
21  #if defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_OPSPUT)
22  #include 
23  #include 
24  

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


.config.gz
Description: Binary data

Re: [PATCH] m32r: fix build warning about putc

[kbuild test robot]

Hi,

[auto build test WARNING on v4.7-rc5]
[also build test WARNING on next-20160624]
[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/Sudip-Mukherjee/m32r-fix-build-warning-about-putc/20160627-094312
config: m32r-m32104ut_defconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All warnings (new ones prefixed by >>):

   In file included from arch/m32r/boot/compressed/misc.c:25:0:
   arch/m32r/boot/compressed/m32r_sio.c: In function 'puts':
>> arch/m32r/boot/compressed/m32r_sio.c:16:2: warning: suggest parentheses 
>> around assignment used as truth value [-Wparentheses]
 while (c = *s++)
 ^

vim +16 arch/m32r/boot/compressed/m32r_sio.c

 1  /*
 2   * arch/m32r/boot/compressed/m32r_sio.c
 3   *
 4   * 2003-02-12:  Takeo Takahashi
 5   * 2006-11-30:  OPSPUT support by Kazuhiro Inaoka
 6   *
 7   */
 8  
 9  #include 
10  
11  static void m32r_putc(char c);
12  
13  static int puts(const char *s)
14  {
15  char c;
  > 16  while (c = *s++)
17  m32r_putc(c);
18  return 0;
19  }
20  
21  #if defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_OPSPUT)
22  #include 
23  #include 
24  

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


.config.gz
Description: Binary data

linux-next: manual merge of the devicetree tree with the arm-soc tree

[Stephen Rothwell]

Hi Rob,

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

  arch/arm/mach-bcm/board_bcm21664.c

between commit:

  406c8f6c9954 ("ARM: bcm21664: Remove reset code")

from the arm-soc tree and commit:

  850bea2335e4 ("arm: Remove unnecessary of_platform_populate with default 
match table")

from the devicetree 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 arch/arm/mach-bcm/board_bcm21664.c
index 65b3db06e57a,0d7034c57334..
--- a/arch/arm/mach-bcm/board_bcm21664.c
+++ b/arch/arm/mach-bcm/board_bcm21664.c
@@@ -11,15 -11,54 +11,12 @@@
   * GNU General Public License for more details.
   */
  
- #include 
 -#include 
 -#include 
--
  #include 
  
  #include "kona_l2_cache.h"
  
 -#define RSTMGR_DT_STRING  "brcm,bcm21664-resetmgr"
 -
 -#define RSTMGR_REG_WR_ACCESS_OFFSET   0
 -#define RSTMGR_REG_CHIP_SOFT_RST_OFFSET   4
 -
 -#define RSTMGR_WR_PASSWORD0xa5a5
 -#define RSTMGR_WR_PASSWORD_SHIFT  8
 -#define RSTMGR_WR_ACCESS_ENABLE   1
 -
 -static void bcm21664_restart(enum reboot_mode mode, const char *cmd)
 -{
 -  void __iomem *base;
 -  struct device_node *resetmgr;
 -
 -  resetmgr = of_find_compatible_node(NULL, NULL, RSTMGR_DT_STRING);
 -  if (!resetmgr) {
 -  pr_emerg("Couldn't find " RSTMGR_DT_STRING "\n");
 -  return;
 -  }
 -  base = of_iomap(resetmgr, 0);
 -  if (!base) {
 -  pr_emerg("Couldn't map " RSTMGR_DT_STRING "\n");
 -  return;
 -  }
 -
 -  /*
 -   * A soft reset is triggered by writing a 0 to bit 0 of the soft reset
 -   * register. To write to that register we must first write the password
 -   * and the enable bit in the write access enable register.
 -   */
 -  writel((RSTMGR_WR_PASSWORD << RSTMGR_WR_PASSWORD_SHIFT) |
 -  RSTMGR_WR_ACCESS_ENABLE,
 -  base + RSTMGR_REG_WR_ACCESS_OFFSET);
 -  writel(0, base + RSTMGR_REG_CHIP_SOFT_RST_OFFSET);
 -
 -  /* Wait for reset */
 -  while (1);
 -}
 -
  static void __init bcm21664_init(void)
  {
-   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
kona_l2_cache_init();
  }
  

linux-next: manual merge of the devicetree tree with the arm-soc tree

[Stephen Rothwell]

Hi Rob,

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

  arch/arm/mach-bcm/board_bcm21664.c

between commit:

  406c8f6c9954 ("ARM: bcm21664: Remove reset code")

from the arm-soc tree and commit:

  850bea2335e4 ("arm: Remove unnecessary of_platform_populate with default 
match table")

from the devicetree 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 arch/arm/mach-bcm/board_bcm21664.c
index 65b3db06e57a,0d7034c57334..
--- a/arch/arm/mach-bcm/board_bcm21664.c
+++ b/arch/arm/mach-bcm/board_bcm21664.c
@@@ -11,15 -11,54 +11,12 @@@
   * GNU General Public License for more details.
   */
  
- #include 
 -#include 
 -#include 
--
  #include 
  
  #include "kona_l2_cache.h"
  
 -#define RSTMGR_DT_STRING  "brcm,bcm21664-resetmgr"
 -
 -#define RSTMGR_REG_WR_ACCESS_OFFSET   0
 -#define RSTMGR_REG_CHIP_SOFT_RST_OFFSET   4
 -
 -#define RSTMGR_WR_PASSWORD0xa5a5
 -#define RSTMGR_WR_PASSWORD_SHIFT  8
 -#define RSTMGR_WR_ACCESS_ENABLE   1
 -
 -static void bcm21664_restart(enum reboot_mode mode, const char *cmd)
 -{
 -  void __iomem *base;
 -  struct device_node *resetmgr;
 -
 -  resetmgr = of_find_compatible_node(NULL, NULL, RSTMGR_DT_STRING);
 -  if (!resetmgr) {
 -  pr_emerg("Couldn't find " RSTMGR_DT_STRING "\n");
 -  return;
 -  }
 -  base = of_iomap(resetmgr, 0);
 -  if (!base) {
 -  pr_emerg("Couldn't map " RSTMGR_DT_STRING "\n");
 -  return;
 -  }
 -
 -  /*
 -   * A soft reset is triggered by writing a 0 to bit 0 of the soft reset
 -   * register. To write to that register we must first write the password
 -   * and the enable bit in the write access enable register.
 -   */
 -  writel((RSTMGR_WR_PASSWORD << RSTMGR_WR_PASSWORD_SHIFT) |
 -  RSTMGR_WR_ACCESS_ENABLE,
 -  base + RSTMGR_REG_WR_ACCESS_OFFSET);
 -  writel(0, base + RSTMGR_REG_CHIP_SOFT_RST_OFFSET);
 -
 -  /* Wait for reset */
 -  while (1);
 -}
 -
  static void __init bcm21664_init(void)
  {
-   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
kona_l2_cache_init();
  }
  

Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

[kbuild test robot]

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb 
ci-for-usb-next
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `ci_hdrc_msm_remove':
>> ci_hdrc_msm.c:(.text+0x4fffd2): undefined reference to 
>> `reset_controller_unregister'

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


.config.gz
Description: Binary data

Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

[kbuild test robot]

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb 
ci-for-usb-next
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `ci_hdrc_msm_remove':
>> ci_hdrc_msm.c:(.text+0x4fffd2): undefined reference to 
>> `reset_controller_unregister'

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


.config.gz
Description: Binary data

Re: [PATCH v2 2/2] namespaces: add transparent user namespaces

[Michael Kerrisk]

Hi Jann,

Patches such as this really should CC linux-api@ (added).

On Sat, Jun 25, 2016 at 2:23 AM, Jann Horn  wrote:
> This allows the admin of a user namespace to mark the namespace as
> transparent. All other namespaces, by default, are opaque.
>
> While the current behavior of user namespaces is appropriate for use in
> containers, there are many programs that only use user namespaces because
> doing so enables them to do other things (e.g. unsharing the mount or
> network namespace) that require namespaced capabilities. For them, the
> inability to see the real UIDs and GIDs of things from inside the user
> namespace can be very annoying.
>
> In a transparent namespace, all UIDs and GIDs that are mapped into its
> first opaque ancestor are visible and are not remapped. This means that if
> a process e.g. stat()s the real root directory in a namespace, it will
> still see it as owned by UID 0.
>
> Traditionally, any UID or GID that was visible in a user namespace was also
> mapped into the namespace, giving the namespace admin full access to it.
> This patch introduces a distinction: In a transparent namespace, UIDs and
> GIDs can be visible without being mapped. Non-mapped, visible UIDs can be
> passed from the kernel to userspace, but userspace can't send them back to
> the kernel.

Can you explain "can't send them back to the kernel" in more detail?
(Some examples of what is and isn't possible would be helpul.)

> In order to be able to fully use specific UIDs/GIDs and gain
> privileges over them, mappings need to be set up in the usual way -
> however, to avoid aliasing problems, only identity mappings are permitted.
>
> v2:
> Ensure that all relevant from_k[ug]id callers show up in the patch.
> _transparent would be more verbose than _tp, but considering the line
> length rule, that's just too long.
>
> Yes, this makes the patch rather large.
>
> Behavior should be the same as in v1, except that I'm not touching orangefs
> in this patch because every single use of from_k[ug]id in it is wrong in
> some way. (Thanks for making me reread all that stuff, Eric.) I'll write a
> separate patch or at least report the issue with more detail later.
>
> (Also, the handling of user namespaces when dealing with signals is
> super-ugly and kind of incorrect. That should probably be cleaned up.)

I'm curious about this detail: can you say some more about the issues here?

> posix_acl_to_xattr would have changed behavior in the v1 patch, but isn't
> changed here. Because it's only used with init_user_ns, that won't change
> user-visible behavior relative to v1.
>
> This patch was compile-tested with allyesconfig. I also ran a VM with this
> patch applied and checked that it still works, but that probably doesn't
> mean much.

One of the things notably lacking from this commit message is any sort
of description of the user-space-API changes that it makes. I presume
it's a matter of some /proc files. Could you explain the changes (ad
add that detail in any further commit message)?

Thanks,

Michael

> Signed-off-by: Jann Horn 
> ---
>  arch/alpha/kernel/osf_sys.c   |   4 +-
>  arch/arm/kernel/sys_oabi-compat.c |   4 +-
>  arch/ia64/kernel/signal.c |   4 +-
>  arch/s390/kernel/compat_linux.c   |  26 +++---
>  arch/sparc/kernel/sys_sparc32.c   |   4 +-
>  arch/x86/ia32/sys_ia32.c  |   4 +-
>  drivers/android/binder.c  |   2 +-
>  drivers/gpu/drm/drm_info.c|   2 +-
>  drivers/gpu/drm/drm_ioctl.c   |   2 +-
>  drivers/net/tun.c |   4 +-
>  fs/autofs4/dev-ioctl.c|   4 +-
>  fs/autofs4/waitq.c|   4 +-
>  fs/binfmt_elf.c   |  12 +--
>  fs/binfmt_elf_fdpic.c |  12 +--
>  fs/compat.c   |   4 +-
>  fs/fcntl.c|   4 +-
>  fs/ncpfs/ioctl.c  |  12 +--
>  fs/posix_acl.c|  11 ++-
>  fs/proc/array.c   |  18 ++--
>  fs/proc/base.c|  30 +--
>  fs/quota/kqid.c   |  12 ++-
>  fs/stat.c |  12 +--
>  include/linux/uidgid.h|  24 +++--
>  include/linux/user_namespace.h|   4 +
>  include/net/scm.h |   4 +-
>  ipc/mqueue.c  |   2 +-
>  ipc/msg.c |   8 +-
>  ipc/sem.c |   8 +-
>  ipc/shm.c |   8 +-
>  ipc/util.c|   8 +-
>  kernel/acct.c |   4 +-
>  kernel/exit.c |   6 +-
>  kernel/groups.c   |   2 +-
>  kernel/signal.c   |  16 ++--
>  kernel/sys.c  |  24 ++---
>  kernel/trace/trace.c  |   2 +-
>  kernel/tsacct.c   |   4 +-
>  kernel/uid16.c|  22 ++---
>  kernel/user.c |   1 +
>  kernel/user_namespace.c   | 178 
> 

Re: [PATCH v2 2/2] namespaces: add transparent user namespaces

[Michael Kerrisk]

Hi Jann,

Patches such as this really should CC linux-api@ (added).

On Sat, Jun 25, 2016 at 2:23 AM, Jann Horn  wrote:
> This allows the admin of a user namespace to mark the namespace as
> transparent. All other namespaces, by default, are opaque.
>
> While the current behavior of user namespaces is appropriate for use in
> containers, there are many programs that only use user namespaces because
> doing so enables them to do other things (e.g. unsharing the mount or
> network namespace) that require namespaced capabilities. For them, the
> inability to see the real UIDs and GIDs of things from inside the user
> namespace can be very annoying.
>
> In a transparent namespace, all UIDs and GIDs that are mapped into its
> first opaque ancestor are visible and are not remapped. This means that if
> a process e.g. stat()s the real root directory in a namespace, it will
> still see it as owned by UID 0.
>
> Traditionally, any UID or GID that was visible in a user namespace was also
> mapped into the namespace, giving the namespace admin full access to it.
> This patch introduces a distinction: In a transparent namespace, UIDs and
> GIDs can be visible without being mapped. Non-mapped, visible UIDs can be
> passed from the kernel to userspace, but userspace can't send them back to
> the kernel.

Can you explain "can't send them back to the kernel" in more detail?
(Some examples of what is and isn't possible would be helpul.)

> In order to be able to fully use specific UIDs/GIDs and gain
> privileges over them, mappings need to be set up in the usual way -
> however, to avoid aliasing problems, only identity mappings are permitted.
>
> v2:
> Ensure that all relevant from_k[ug]id callers show up in the patch.
> _transparent would be more verbose than _tp, but considering the line
> length rule, that's just too long.
>
> Yes, this makes the patch rather large.
>
> Behavior should be the same as in v1, except that I'm not touching orangefs
> in this patch because every single use of from_k[ug]id in it is wrong in
> some way. (Thanks for making me reread all that stuff, Eric.) I'll write a
> separate patch or at least report the issue with more detail later.
>
> (Also, the handling of user namespaces when dealing with signals is
> super-ugly and kind of incorrect. That should probably be cleaned up.)

I'm curious about this detail: can you say some more about the issues here?

> posix_acl_to_xattr would have changed behavior in the v1 patch, but isn't
> changed here. Because it's only used with init_user_ns, that won't change
> user-visible behavior relative to v1.
>
> This patch was compile-tested with allyesconfig. I also ran a VM with this
> patch applied and checked that it still works, but that probably doesn't
> mean much.

One of the things notably lacking from this commit message is any sort
of description of the user-space-API changes that it makes. I presume
it's a matter of some /proc files. Could you explain the changes (ad
add that detail in any further commit message)?

Thanks,

Michael

> Signed-off-by: Jann Horn 
> ---
>  arch/alpha/kernel/osf_sys.c   |   4 +-
>  arch/arm/kernel/sys_oabi-compat.c |   4 +-
>  arch/ia64/kernel/signal.c |   4 +-
>  arch/s390/kernel/compat_linux.c   |  26 +++---
>  arch/sparc/kernel/sys_sparc32.c   |   4 +-
>  arch/x86/ia32/sys_ia32.c  |   4 +-
>  drivers/android/binder.c  |   2 +-
>  drivers/gpu/drm/drm_info.c|   2 +-
>  drivers/gpu/drm/drm_ioctl.c   |   2 +-
>  drivers/net/tun.c |   4 +-
>  fs/autofs4/dev-ioctl.c|   4 +-
>  fs/autofs4/waitq.c|   4 +-
>  fs/binfmt_elf.c   |  12 +--
>  fs/binfmt_elf_fdpic.c |  12 +--
>  fs/compat.c   |   4 +-
>  fs/fcntl.c|   4 +-
>  fs/ncpfs/ioctl.c  |  12 +--
>  fs/posix_acl.c|  11 ++-
>  fs/proc/array.c   |  18 ++--
>  fs/proc/base.c|  30 +--
>  fs/quota/kqid.c   |  12 ++-
>  fs/stat.c |  12 +--
>  include/linux/uidgid.h|  24 +++--
>  include/linux/user_namespace.h|   4 +
>  include/net/scm.h |   4 +-
>  ipc/mqueue.c  |   2 +-
>  ipc/msg.c |   8 +-
>  ipc/sem.c |   8 +-
>  ipc/shm.c |   8 +-
>  ipc/util.c|   8 +-
>  kernel/acct.c |   4 +-
>  kernel/exit.c |   6 +-
>  kernel/groups.c   |   2 +-
>  kernel/signal.c   |  16 ++--
>  kernel/sys.c  |  24 ++---
>  kernel/trace/trace.c  |   2 +-
>  kernel/tsacct.c   |   4 +-
>  kernel/uid16.c|  22 ++---
>  kernel/user.c |   1 +
>  kernel/user_namespace.c   | 178 
> +++---
>  

linux-next: manual merge of the jc_docs tree with the drm tree

[Stephen Rothwell]

Hi Jonathan,

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

  Documentation/index.rst

between commit:

  cb597fcea5c2 ("Documentation/gpu: add new gpu.rst converted from DocBook 
gpu.tmpl")

from the drm tree and commit:

  17defc282fe6 ("Documentation: add meta-documentation for Sphinx and 
kernel-doc")

from the jc_docs 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 Documentation/index.rst
index dacc77b43c29,f92854f01773..
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@@ -13,8 -13,8 +13,10 @@@ Contents
  .. toctree::
 :maxdepth: 2
  
+kernel-documentation
+ 
 +   gpu/index
 +
  Indices and tables
  ==
  

linux-next: manual merge of the jc_docs tree with the drm tree

[Stephen Rothwell]

Hi Jonathan,

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

  Documentation/index.rst

between commit:

  cb597fcea5c2 ("Documentation/gpu: add new gpu.rst converted from DocBook 
gpu.tmpl")

from the drm tree and commit:

  17defc282fe6 ("Documentation: add meta-documentation for Sphinx and 
kernel-doc")

from the jc_docs 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 Documentation/index.rst
index dacc77b43c29,f92854f01773..
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@@ -13,8 -13,8 +13,10 @@@ Contents
  .. toctree::
 :maxdepth: 2
  
+kernel-documentation
+ 
 +   gpu/index
 +
  Indices and tables
  ==
  

Re: [RESEND PATCH v11] mtd: spi-nor: add hisilicon spi-nor flash controller driver

[Jiancheng Xue]

Hi Brian,
   I haven't received more other comments for two weeks since I resent this
patch except a compiling error. Could you help me merge this patch into the
-next tree after I fix the compiling error?  If so, I'll send out the new
version as soon as possible. Thank you very much!

Regards,
Jiancheng

On 2016/6/13 16:21, Jiancheng Xue wrote:
> Add hisilicon spi-nor flash controller driver
> 
> Signed-off-by: Binquan Peng 
> Signed-off-by: Jiancheng Xue 
> Acked-by: Rob Herring 
> Reviewed-by: Ezequiel Garcia 
> ---
> change log
> v11:
> Fixed issues pointed by Brian Norris and Cyrille Pitchen.
> 1)Changed hisi_spi_nor_read_reg()/write_reg() to configure registers
> without sniffing the opcodes.
> 2)Deleted hisi_spi_nor_erase() and used default implementation instead.
> 3)Changed hisi_spi_nor_dma_transfer() to return a integer type value
> instead of nothing.
> 4)Simplified hisi_spi_nor_read()/write() as Brian suggested.
> 
> v10:
> Fixed issues pointed by Marek Vasut.
> 1)Droped the underscores in the argument names of some macros' definition.
> 2)Changed some varibles to correct type.
> 3)Rewrote hisi_spi_nor_read/write for readability.
> 4)Added new functions hisi_spi_nor_register/unregister_all
> 5)Changed to dynamically allocation for spi_nor embeded in hifmc_host.
> Fixed issues pointed by Brian Norris.
> 1)Replaced some headers with more accurate ones.
> v9:
> Fixed issues pointed by Jagan Teki.
> v8:
> Fixed issues pointed by Ezequiel Garcia and Brian Norris.
> Moved dts binding file to mtd directory.
> Changed the compatible string more specific.
> v7:
> Rebased to v4.5-rc3.
> Fixed issues pointed by Ezequiel Garcia.
> v6:
> Based on v4.5-rc2
> Fixed issues pointed by Ezequiel Garcia.
> v5:
> Fixed a compile error.
> v4:
> Rebased to v4.5-rc1
> v3:
> Added a compatible string "hisilicon,hi3519-sfc".
> v2:
> Fixed some compiling warings.
> 
>  .../bindings/mtd/hisilicon,fmc-spi-nor.txt |  24 +
>  drivers/mtd/spi-nor/Kconfig|   7 +
>  drivers/mtd/spi-nor/Makefile   |   1 +
>  drivers/mtd/spi-nor/hisi-sfc.c | 489 
> +
>  4 files changed, 521 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
>  create mode 100644 drivers/mtd/spi-nor/hisi-sfc.c
> 
> diff --git a/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt 
> b/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
> new file mode 100644
> index 000..7498152
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
> @@ -0,0 +1,24 @@
> +HiSilicon SPI-NOR Flash Controller
> +
> +Required properties:
> +- compatible : Should be "hisilicon,fmc-spi-nor" and one of the following 
> strings:
> + "hisilicon,hi3519-spi-nor"
> +- address-cells : Should be 1.
> +- size-cells : Should be 0.
> +- reg : Offset and length of the register set for the controller device.
> +- reg-names : Must include the following two entries: "control", "memory".
> +- clocks : handle to spi-nor flash controller clock.
> +
> +Example:
> +spi-nor-controller@1000 {
> + compatible = "hisilicon,hi3519-spi-nor", "hisilicon,fmc-spi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1000 0x1000>, <0x1400 0x100>;
> + reg-names = "control", "memory";
> + clocks = < HI3519_FMC_CLK>;
> + spi-nor@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + };
> +};
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index d42c98e..b9ff675 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -38,6 +38,13 @@ config SPI_FSL_QUADSPI
> This controller does not support generic SPI. It only supports
> SPI NOR.
>  
> +config SPI_HISI_SFC
> + tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
> + depends on ARCH_HISI || COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> +   This enables support for hisilicon SPI-NOR flash controller.
> +
>  config SPI_NXP_SPIFI
>   tristate "NXP SPI Flash Interface (SPIFI)"
>   depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 0bf3a7f8..8a6fa69 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o
>  obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
> +obj-$(CONFIG_SPI_HISI_SFC)   += hisi-sfc.o
>  obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
>  obj-$(CONFIG_SPI_NXP_SPIFI)  += nxp-spifi.o
> diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
> new file mode 100644
> index 000..44664c3
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/hisi-sfc.c
> @@ -0,0 +1,489 @@
> +/*
> + * 

Re: [RESEND PATCH v11] mtd: spi-nor: add hisilicon spi-nor flash controller driver

[Jiancheng Xue]

Hi Brian,
   I haven't received more other comments for two weeks since I resent this
patch except a compiling error. Could you help me merge this patch into the
-next tree after I fix the compiling error?  If so, I'll send out the new
version as soon as possible. Thank you very much!

Regards,
Jiancheng

On 2016/6/13 16:21, Jiancheng Xue wrote:
> Add hisilicon spi-nor flash controller driver
> 
> Signed-off-by: Binquan Peng 
> Signed-off-by: Jiancheng Xue 
> Acked-by: Rob Herring 
> Reviewed-by: Ezequiel Garcia 
> ---
> change log
> v11:
> Fixed issues pointed by Brian Norris and Cyrille Pitchen.
> 1)Changed hisi_spi_nor_read_reg()/write_reg() to configure registers
> without sniffing the opcodes.
> 2)Deleted hisi_spi_nor_erase() and used default implementation instead.
> 3)Changed hisi_spi_nor_dma_transfer() to return a integer type value
> instead of nothing.
> 4)Simplified hisi_spi_nor_read()/write() as Brian suggested.
> 
> v10:
> Fixed issues pointed by Marek Vasut.
> 1)Droped the underscores in the argument names of some macros' definition.
> 2)Changed some varibles to correct type.
> 3)Rewrote hisi_spi_nor_read/write for readability.
> 4)Added new functions hisi_spi_nor_register/unregister_all
> 5)Changed to dynamically allocation for spi_nor embeded in hifmc_host.
> Fixed issues pointed by Brian Norris.
> 1)Replaced some headers with more accurate ones.
> v9:
> Fixed issues pointed by Jagan Teki.
> v8:
> Fixed issues pointed by Ezequiel Garcia and Brian Norris.
> Moved dts binding file to mtd directory.
> Changed the compatible string more specific.
> v7:
> Rebased to v4.5-rc3.
> Fixed issues pointed by Ezequiel Garcia.
> v6:
> Based on v4.5-rc2
> Fixed issues pointed by Ezequiel Garcia.
> v5:
> Fixed a compile error.
> v4:
> Rebased to v4.5-rc1
> v3:
> Added a compatible string "hisilicon,hi3519-sfc".
> v2:
> Fixed some compiling warings.
> 
>  .../bindings/mtd/hisilicon,fmc-spi-nor.txt |  24 +
>  drivers/mtd/spi-nor/Kconfig|   7 +
>  drivers/mtd/spi-nor/Makefile   |   1 +
>  drivers/mtd/spi-nor/hisi-sfc.c | 489 
> +
>  4 files changed, 521 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
>  create mode 100644 drivers/mtd/spi-nor/hisi-sfc.c
> 
> diff --git a/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt 
> b/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
> new file mode 100644
> index 000..7498152
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
> @@ -0,0 +1,24 @@
> +HiSilicon SPI-NOR Flash Controller
> +
> +Required properties:
> +- compatible : Should be "hisilicon,fmc-spi-nor" and one of the following 
> strings:
> + "hisilicon,hi3519-spi-nor"
> +- address-cells : Should be 1.
> +- size-cells : Should be 0.
> +- reg : Offset and length of the register set for the controller device.
> +- reg-names : Must include the following two entries: "control", "memory".
> +- clocks : handle to spi-nor flash controller clock.
> +
> +Example:
> +spi-nor-controller@1000 {
> + compatible = "hisilicon,hi3519-spi-nor", "hisilicon,fmc-spi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1000 0x1000>, <0x1400 0x100>;
> + reg-names = "control", "memory";
> + clocks = < HI3519_FMC_CLK>;
> + spi-nor@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + };
> +};
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index d42c98e..b9ff675 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -38,6 +38,13 @@ config SPI_FSL_QUADSPI
> This controller does not support generic SPI. It only supports
> SPI NOR.
>  
> +config SPI_HISI_SFC
> + tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
> + depends on ARCH_HISI || COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> +   This enables support for hisilicon SPI-NOR flash controller.
> +
>  config SPI_NXP_SPIFI
>   tristate "NXP SPI Flash Interface (SPIFI)"
>   depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 0bf3a7f8..8a6fa69 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o
>  obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
> +obj-$(CONFIG_SPI_HISI_SFC)   += hisi-sfc.o
>  obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
>  obj-$(CONFIG_SPI_NXP_SPIFI)  += nxp-spifi.o
> diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
> new file mode 100644
> index 000..44664c3
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/hisi-sfc.c
> @@ -0,0 +1,489 @@
> +/*
> + * HiSilicon SPI Nor Flash Controller Driver
> + *
> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., 

[PATCH v14 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

[David Long]

From: "David A. Long" 

Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64, including supporting
functions and defines.

Signed-off-by: David A. Long 
---
 arch/arm64/Kconfig  |   1 +
 arch/arm64/include/asm/ptrace.h |  52 ++
 arch/arm64/kernel/ptrace.c  | 118 
 3 files changed, 171 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5a0a691..fab133c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -85,6 +85,7 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+   select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select IOMMU_DMA if IOMMU_SUPPORT
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index a307eb6..6c0c7d3 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -74,6 +74,7 @@
 #define COMPAT_PT_DATA_ADDR0x10004
 #define COMPAT_PT_TEXT_END_ADDR0x10008
 #ifndef __ASSEMBLY__
+#include 
 
 /* sizeof(struct user) for AArch32 */
 #define COMPAT_USER_SZ 296
@@ -119,6 +120,8 @@ struct pt_regs {
u64 syscallno;
 };
 
+#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
+
 #define arch_has_single_step() (1)
 
 #ifdef CONFIG_COMPAT
@@ -147,6 +150,55 @@ struct pt_regs {
 #define user_stack_pointer(regs) \
(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
 
+extern int regs_query_register_offset(const char *name);
+extern const char *regs_query_register_name(unsigned int offset);
+extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+  unsigned int n);
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset:offset of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+   u64 val = 0;
+
+   WARN_ON(offset & 7);
+
+   offset >>= 3;
+   switch (offset) {
+   case0 ... 30:
+   val = regs->regs[offset];
+   break;
+   case offsetof(struct pt_regs, sp) >> 3:
+   val = regs->sp;
+   break;
+   case offsetof(struct pt_regs, pc) >> 3:
+   val = regs->pc;
+   break;
+   case offsetof(struct pt_regs, pstate) >> 3:
+   val = regs->pstate;
+   break;
+   default:
+   val = 0;
+   }
+
+   return val;
+}
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+   return regs->sp;
+}
+
 static inline unsigned long regs_return_value(struct pt_regs *regs)
 {
return regs->regs[0];
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 3f6cd5c..2c88c33 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,124 @@
 #define CREATE_TRACE_POINTS
 #include 
 
+struct pt_regs_offset {
+   const char *name;
+   int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+#defineGPR_OFFSET_NAME(r)  \
+   {.name = "x" #r, .offset = offsetof(struct pt_regs, regs[r])}
+
+static const struct pt_regs_offset regoffset_table[] = {
+   GPR_OFFSET_NAME(0),
+   GPR_OFFSET_NAME(1),
+   GPR_OFFSET_NAME(2),
+   GPR_OFFSET_NAME(3),
+   GPR_OFFSET_NAME(4),
+   GPR_OFFSET_NAME(5),
+   GPR_OFFSET_NAME(6),
+   GPR_OFFSET_NAME(7),
+   GPR_OFFSET_NAME(8),
+   GPR_OFFSET_NAME(9),
+   GPR_OFFSET_NAME(10),
+   GPR_OFFSET_NAME(11),
+   GPR_OFFSET_NAME(12),
+   GPR_OFFSET_NAME(13),
+   GPR_OFFSET_NAME(14),
+   GPR_OFFSET_NAME(15),
+   GPR_OFFSET_NAME(16),
+   GPR_OFFSET_NAME(17),
+   GPR_OFFSET_NAME(18),
+   GPR_OFFSET_NAME(19),
+   GPR_OFFSET_NAME(20),
+   GPR_OFFSET_NAME(21),
+   GPR_OFFSET_NAME(22),
+   GPR_OFFSET_NAME(23),
+   GPR_OFFSET_NAME(24),
+   GPR_OFFSET_NAME(25),
+   GPR_OFFSET_NAME(26),
+   GPR_OFFSET_NAME(27),
+   GPR_OFFSET_NAME(28),
+   GPR_OFFSET_NAME(29),
+   GPR_OFFSET_NAME(30),
+   {.name = "lr", .offset = offsetof(struct pt_regs, regs[30])},
+   REG_OFFSET_NAME(sp),
+   REG_OFFSET_NAME(pc),
+   REG_OFFSET_NAME(pstate),
+   REG_OFFSET_END,
+};
+
+/**
+ * 

[PATCH v14 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

[David Long]

From: "David A. Long" 

Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64, including supporting
functions and defines.

Signed-off-by: David A. Long 
---
 arch/arm64/Kconfig  |   1 +
 arch/arm64/include/asm/ptrace.h |  52 ++
 arch/arm64/kernel/ptrace.c  | 118 
 3 files changed, 171 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5a0a691..fab133c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -85,6 +85,7 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+   select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select IOMMU_DMA if IOMMU_SUPPORT
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index a307eb6..6c0c7d3 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -74,6 +74,7 @@
 #define COMPAT_PT_DATA_ADDR0x10004
 #define COMPAT_PT_TEXT_END_ADDR0x10008
 #ifndef __ASSEMBLY__
+#include 
 
 /* sizeof(struct user) for AArch32 */
 #define COMPAT_USER_SZ 296
@@ -119,6 +120,8 @@ struct pt_regs {
u64 syscallno;
 };
 
+#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
+
 #define arch_has_single_step() (1)
 
 #ifdef CONFIG_COMPAT
@@ -147,6 +150,55 @@ struct pt_regs {
 #define user_stack_pointer(regs) \
(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
 
+extern int regs_query_register_offset(const char *name);
+extern const char *regs_query_register_name(unsigned int offset);
+extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+  unsigned int n);
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset:offset of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+   u64 val = 0;
+
+   WARN_ON(offset & 7);
+
+   offset >>= 3;
+   switch (offset) {
+   case0 ... 30:
+   val = regs->regs[offset];
+   break;
+   case offsetof(struct pt_regs, sp) >> 3:
+   val = regs->sp;
+   break;
+   case offsetof(struct pt_regs, pc) >> 3:
+   val = regs->pc;
+   break;
+   case offsetof(struct pt_regs, pstate) >> 3:
+   val = regs->pstate;
+   break;
+   default:
+   val = 0;
+   }
+
+   return val;
+}
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+   return regs->sp;
+}
+
 static inline unsigned long regs_return_value(struct pt_regs *regs)
 {
return regs->regs[0];
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 3f6cd5c..2c88c33 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,124 @@
 #define CREATE_TRACE_POINTS
 #include 
 
+struct pt_regs_offset {
+   const char *name;
+   int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+#defineGPR_OFFSET_NAME(r)  \
+   {.name = "x" #r, .offset = offsetof(struct pt_regs, regs[r])}
+
+static const struct pt_regs_offset regoffset_table[] = {
+   GPR_OFFSET_NAME(0),
+   GPR_OFFSET_NAME(1),
+   GPR_OFFSET_NAME(2),
+   GPR_OFFSET_NAME(3),
+   GPR_OFFSET_NAME(4),
+   GPR_OFFSET_NAME(5),
+   GPR_OFFSET_NAME(6),
+   GPR_OFFSET_NAME(7),
+   GPR_OFFSET_NAME(8),
+   GPR_OFFSET_NAME(9),
+   GPR_OFFSET_NAME(10),
+   GPR_OFFSET_NAME(11),
+   GPR_OFFSET_NAME(12),
+   GPR_OFFSET_NAME(13),
+   GPR_OFFSET_NAME(14),
+   GPR_OFFSET_NAME(15),
+   GPR_OFFSET_NAME(16),
+   GPR_OFFSET_NAME(17),
+   GPR_OFFSET_NAME(18),
+   GPR_OFFSET_NAME(19),
+   GPR_OFFSET_NAME(20),
+   GPR_OFFSET_NAME(21),
+   GPR_OFFSET_NAME(22),
+   GPR_OFFSET_NAME(23),
+   GPR_OFFSET_NAME(24),
+   GPR_OFFSET_NAME(25),
+   GPR_OFFSET_NAME(26),
+   GPR_OFFSET_NAME(27),
+   GPR_OFFSET_NAME(28),
+   GPR_OFFSET_NAME(29),
+   GPR_OFFSET_NAME(30),
+   {.name = "lr", .offset = offsetof(struct pt_regs, regs[30])},
+   REG_OFFSET_NAME(sp),
+   REG_OFFSET_NAME(pc),
+   REG_OFFSET_NAME(pstate),
+   REG_OFFSET_END,
+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ 

[PATCH v14 06/10] arm64: Treat all entry code as non-kprobe-able

[David Long]

From: Pratyush Anand 

Entry symbols are not kprobe safe. So blacklist them for kprobing.

Signed-off-by: Pratyush Anand 
Signed-off-by: David A. Long 
Acked-by: Masami Hiramatsu 
---
 arch/arm64/kernel/entry.S   |  3 +++
 arch/arm64/kernel/kprobes/kprobes.c | 26 ++
 arch/arm64/kernel/vmlinux.lds.S |  1 +
 3 files changed, 30 insertions(+)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 12e8d2b..7d99bed 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -243,6 +243,7 @@ tsk .reqx28 // current thread_info
  * Exception vectors.
  */
 
+   .pushsection ".entry.text", "ax"
.align  11
 ENTRY(vectors)
ventry  el1_sync_invalid// Synchronous EL1t
@@ -781,3 +782,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
mov x0, sp
b   sys_rt_sigreturn
 ENDPROC(sys_rt_sigreturn_wrapper)
+
+   .popsection
diff --git a/arch/arm64/kernel/kprobes/kprobes.c 
b/arch/arm64/kernel/kprobes/kprobes.c
index 189b0d2..ca0c0c9 100644
--- a/arch/arm64/kernel/kprobes/kprobes.c
+++ b/arch/arm64/kernel/kprobes/kprobes.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "decode-insn.h"
 
@@ -519,6 +520,31 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
return 1;
 }
 
+bool arch_within_kprobe_blacklist(unsigned long addr)
+{
+   extern char __idmap_text_start[], __idmap_text_end[];
+   extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
+
+   if ((addr >= (unsigned long)__kprobes_text_start &&
+   addr < (unsigned long)__kprobes_text_end) ||
+   (addr >= (unsigned long)__entry_text_start &&
+   addr < (unsigned long)__entry_text_end) ||
+   (addr >= (unsigned long)__idmap_text_start &&
+   addr < (unsigned long)__idmap_text_end) ||
+   !!search_exception_tables(addr))
+   return true;
+
+   if (!is_kernel_in_hyp_mode()) {
+   if ((addr >= (unsigned long)__hyp_text_start &&
+   addr < (unsigned long)__hyp_text_end) ||
+   (addr >= (unsigned long)__hyp_idmap_text_start &&
+   addr < (unsigned long)__hyp_idmap_text_end))
+   return true;
+   }
+
+   return false;
+}
+
 int __init arch_init_kprobes(void)
 {
return 0;
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 075ce32..9f59394 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -118,6 +118,7 @@ SECTIONS
__exception_text_end = .;
IRQENTRY_TEXT
SOFTIRQENTRY_TEXT
+   ENTRY_TEXT
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
-- 
2.5.0

[PATCH v14 05/10] arm64: Blacklist non-kprobe-able symbol

[David Long]

From: Pratyush Anand 

Add all function symbols which are called from do_debug_exception under
NOKPROBE_SYMBOL, as they can not kprobed.

Signed-off-by: Pratyush Anand 
---
 arch/arm64/kernel/arm64ksyms.c |  2 ++
 arch/arm64/kernel/debug-monitors.c | 17 +
 arch/arm64/kernel/hw_breakpoint.c  |  8 
 arch/arm64/kernel/kgdb.c   |  4 
 4 files changed, 31 insertions(+)

diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 678f30b0..b96ff1a 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -68,6 +69,7 @@ EXPORT_SYMBOL(test_and_change_bit);
 
 #ifdef CONFIG_FUNCTION_TRACER
 EXPORT_SYMBOL(_mcount);
+NOKPROBE_SYMBOL(_mcount);
 #endif
 
/* arm-smccc */
diff --git a/arch/arm64/kernel/debug-monitors.c 
b/arch/arm64/kernel/debug-monitors.c
index 395de61..2fbc1b9 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -49,6 +49,7 @@ static void mdscr_write(u32 mdscr)
asm volatile("msr mdscr_el1, %0" :: "r" (mdscr));
local_dbg_restore(flags);
 }
+NOKPROBE_SYMBOL(mdscr_write);
 
 static u32 mdscr_read(void)
 {
@@ -56,6 +57,7 @@ static u32 mdscr_read(void)
asm volatile("mrs %0, mdscr_el1" : "=r" (mdscr));
return mdscr;
 }
+NOKPROBE_SYMBOL(mdscr_read);
 
 /*
  * Allow root to disable self-hosted debug from userspace.
@@ -104,6 +106,7 @@ void enable_debug_monitors(enum dbg_active_el el)
mdscr_write(mdscr);
}
 }
+NOKPROBE_SYMBOL(enable_debug_monitors);
 
 void disable_debug_monitors(enum dbg_active_el el)
 {
@@ -124,6 +127,7 @@ void disable_debug_monitors(enum dbg_active_el el)
mdscr_write(mdscr);
}
 }
+NOKPROBE_SYMBOL(disable_debug_monitors);
 
 /*
  * OS lock clearing.
@@ -174,6 +178,7 @@ static void set_regs_spsr_ss(struct pt_regs *regs)
spsr |= DBG_SPSR_SS;
regs->pstate = spsr;
 }
+NOKPROBE_SYMBOL(set_regs_spsr_ss);
 
 static void clear_regs_spsr_ss(struct pt_regs *regs)
 {
@@ -183,6 +188,7 @@ static void clear_regs_spsr_ss(struct pt_regs *regs)
spsr &= ~DBG_SPSR_SS;
regs->pstate = spsr;
 }
+NOKPROBE_SYMBOL(clear_regs_spsr_ss);
 
 /* EL1 Single Step Handler hooks */
 static LIST_HEAD(step_hook);
@@ -226,6 +232,7 @@ static int call_step_hook(struct pt_regs *regs, unsigned 
int esr)
 
return retval;
 }
+NOKPROBE_SYMBOL(call_step_hook);
 
 static void send_user_sigtrap(int si_code)
 {
@@ -284,6 +291,7 @@ static int single_step_handler(unsigned long addr, unsigned 
int esr,
 
return 0;
 }
+NOKPROBE_SYMBOL(single_step_handler);
 
 /*
  * Breakpoint handler is re-entrant as another breakpoint can
@@ -321,6 +329,7 @@ static int call_break_hook(struct pt_regs *regs, unsigned 
int esr)
 
return fn ? fn(regs, esr) : DBG_HOOK_ERROR;
 }
+NOKPROBE_SYMBOL(call_break_hook);
 
 static int brk_handler(unsigned long addr, unsigned int esr,
   struct pt_regs *regs)
@@ -341,6 +350,7 @@ static int brk_handler(unsigned long addr, unsigned int esr,
 
return 0;
 }
+NOKPROBE_SYMBOL(brk_handler);
 
 int aarch32_break_handler(struct pt_regs *regs)
 {
@@ -377,6 +387,7 @@ int aarch32_break_handler(struct pt_regs *regs)
send_user_sigtrap(TRAP_BRKPT);
return 0;
 }
+NOKPROBE_SYMBOL(aarch32_break_handler);
 
 static int __init debug_traps_init(void)
 {
@@ -398,6 +409,7 @@ void user_rewind_single_step(struct task_struct *task)
if (test_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP))
set_regs_spsr_ss(task_pt_regs(task));
 }
+NOKPROBE_SYMBOL(user_rewind_single_step);
 
 void user_fastforward_single_step(struct task_struct *task)
 {
@@ -413,6 +425,7 @@ void kernel_enable_single_step(struct pt_regs *regs)
mdscr_write(mdscr_read() | DBG_MDSCR_SS);
enable_debug_monitors(DBG_ACTIVE_EL1);
 }
+NOKPROBE_SYMBOL(kernel_enable_single_step);
 
 void kernel_disable_single_step(void)
 {
@@ -420,12 +433,14 @@ void kernel_disable_single_step(void)
mdscr_write(mdscr_read() & ~DBG_MDSCR_SS);
disable_debug_monitors(DBG_ACTIVE_EL1);
 }
+NOKPROBE_SYMBOL(kernel_disable_single_step);
 
 int kernel_active_single_step(void)
 {
WARN_ON(!irqs_disabled());
return mdscr_read() & DBG_MDSCR_SS;
 }
+NOKPROBE_SYMBOL(kernel_active_single_step);
 
 /* ptrace API */
 void user_enable_single_step(struct task_struct *task)
@@ -433,8 +448,10 @@ void user_enable_single_step(struct task_struct *task)
set_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
set_regs_spsr_ss(task_pt_regs(task));
 }
+NOKPROBE_SYMBOL(user_enable_single_step);
 
 void user_disable_single_step(struct task_struct *task)
 {
clear_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
 }
+NOKPROBE_SYMBOL(user_disable_single_step);
diff --git a/arch/arm64/kernel/hw_breakpoint.c 

[PATCH v14 06/10] arm64: Treat all entry code as non-kprobe-able

[David Long]

From: Pratyush Anand 

Entry symbols are not kprobe safe. So blacklist them for kprobing.

Signed-off-by: Pratyush Anand 
Signed-off-by: David A. Long 
Acked-by: Masami Hiramatsu 
---
 arch/arm64/kernel/entry.S   |  3 +++
 arch/arm64/kernel/kprobes/kprobes.c | 26 ++
 arch/arm64/kernel/vmlinux.lds.S |  1 +
 3 files changed, 30 insertions(+)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 12e8d2b..7d99bed 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -243,6 +243,7 @@ tsk .reqx28 // current thread_info
  * Exception vectors.
  */
 
+   .pushsection ".entry.text", "ax"
.align  11
 ENTRY(vectors)
ventry  el1_sync_invalid// Synchronous EL1t
@@ -781,3 +782,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
mov x0, sp
b   sys_rt_sigreturn
 ENDPROC(sys_rt_sigreturn_wrapper)
+
+   .popsection
diff --git a/arch/arm64/kernel/kprobes/kprobes.c 
b/arch/arm64/kernel/kprobes/kprobes.c
index 189b0d2..ca0c0c9 100644
--- a/arch/arm64/kernel/kprobes/kprobes.c
+++ b/arch/arm64/kernel/kprobes/kprobes.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "decode-insn.h"
 
@@ -519,6 +520,31 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
return 1;
 }
 
+bool arch_within_kprobe_blacklist(unsigned long addr)
+{
+   extern char __idmap_text_start[], __idmap_text_end[];
+   extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
+
+   if ((addr >= (unsigned long)__kprobes_text_start &&
+   addr < (unsigned long)__kprobes_text_end) ||
+   (addr >= (unsigned long)__entry_text_start &&
+   addr < (unsigned long)__entry_text_end) ||
+   (addr >= (unsigned long)__idmap_text_start &&
+   addr < (unsigned long)__idmap_text_end) ||
+   !!search_exception_tables(addr))
+   return true;
+
+   if (!is_kernel_in_hyp_mode()) {
+   if ((addr >= (unsigned long)__hyp_text_start &&
+   addr < (unsigned long)__hyp_text_end) ||
+   (addr >= (unsigned long)__hyp_idmap_text_start &&
+   addr < (unsigned long)__hyp_idmap_text_end))
+   return true;
+   }
+
+   return false;
+}
+
 int __init arch_init_kprobes(void)
 {
return 0;
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 075ce32..9f59394 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -118,6 +118,7 @@ SECTIONS
__exception_text_end = .;
IRQENTRY_TEXT
SOFTIRQENTRY_TEXT
+   ENTRY_TEXT
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
-- 
2.5.0

[PATCH v14 05/10] arm64: Blacklist non-kprobe-able symbol

[David Long]

From: Pratyush Anand 

Add all function symbols which are called from do_debug_exception under
NOKPROBE_SYMBOL, as they can not kprobed.

Signed-off-by: Pratyush Anand 
---
 arch/arm64/kernel/arm64ksyms.c |  2 ++
 arch/arm64/kernel/debug-monitors.c | 17 +
 arch/arm64/kernel/hw_breakpoint.c  |  8 
 arch/arm64/kernel/kgdb.c   |  4 
 4 files changed, 31 insertions(+)

diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 678f30b0..b96ff1a 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -68,6 +69,7 @@ EXPORT_SYMBOL(test_and_change_bit);
 
 #ifdef CONFIG_FUNCTION_TRACER
 EXPORT_SYMBOL(_mcount);
+NOKPROBE_SYMBOL(_mcount);
 #endif
 
/* arm-smccc */
diff --git a/arch/arm64/kernel/debug-monitors.c 
b/arch/arm64/kernel/debug-monitors.c
index 395de61..2fbc1b9 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -49,6 +49,7 @@ static void mdscr_write(u32 mdscr)
asm volatile("msr mdscr_el1, %0" :: "r" (mdscr));
local_dbg_restore(flags);
 }
+NOKPROBE_SYMBOL(mdscr_write);
 
 static u32 mdscr_read(void)
 {
@@ -56,6 +57,7 @@ static u32 mdscr_read(void)
asm volatile("mrs %0, mdscr_el1" : "=r" (mdscr));
return mdscr;
 }
+NOKPROBE_SYMBOL(mdscr_read);
 
 /*
  * Allow root to disable self-hosted debug from userspace.
@@ -104,6 +106,7 @@ void enable_debug_monitors(enum dbg_active_el el)
mdscr_write(mdscr);
}
 }
+NOKPROBE_SYMBOL(enable_debug_monitors);
 
 void disable_debug_monitors(enum dbg_active_el el)
 {
@@ -124,6 +127,7 @@ void disable_debug_monitors(enum dbg_active_el el)
mdscr_write(mdscr);
}
 }
+NOKPROBE_SYMBOL(disable_debug_monitors);
 
 /*
  * OS lock clearing.
@@ -174,6 +178,7 @@ static void set_regs_spsr_ss(struct pt_regs *regs)
spsr |= DBG_SPSR_SS;
regs->pstate = spsr;
 }
+NOKPROBE_SYMBOL(set_regs_spsr_ss);
 
 static void clear_regs_spsr_ss(struct pt_regs *regs)
 {
@@ -183,6 +188,7 @@ static void clear_regs_spsr_ss(struct pt_regs *regs)
spsr &= ~DBG_SPSR_SS;
regs->pstate = spsr;
 }
+NOKPROBE_SYMBOL(clear_regs_spsr_ss);
 
 /* EL1 Single Step Handler hooks */
 static LIST_HEAD(step_hook);
@@ -226,6 +232,7 @@ static int call_step_hook(struct pt_regs *regs, unsigned 
int esr)
 
return retval;
 }
+NOKPROBE_SYMBOL(call_step_hook);
 
 static void send_user_sigtrap(int si_code)
 {
@@ -284,6 +291,7 @@ static int single_step_handler(unsigned long addr, unsigned 
int esr,
 
return 0;
 }
+NOKPROBE_SYMBOL(single_step_handler);
 
 /*
  * Breakpoint handler is re-entrant as another breakpoint can
@@ -321,6 +329,7 @@ static int call_break_hook(struct pt_regs *regs, unsigned 
int esr)
 
return fn ? fn(regs, esr) : DBG_HOOK_ERROR;
 }
+NOKPROBE_SYMBOL(call_break_hook);
 
 static int brk_handler(unsigned long addr, unsigned int esr,
   struct pt_regs *regs)
@@ -341,6 +350,7 @@ static int brk_handler(unsigned long addr, unsigned int esr,
 
return 0;
 }
+NOKPROBE_SYMBOL(brk_handler);
 
 int aarch32_break_handler(struct pt_regs *regs)
 {
@@ -377,6 +387,7 @@ int aarch32_break_handler(struct pt_regs *regs)
send_user_sigtrap(TRAP_BRKPT);
return 0;
 }
+NOKPROBE_SYMBOL(aarch32_break_handler);
 
 static int __init debug_traps_init(void)
 {
@@ -398,6 +409,7 @@ void user_rewind_single_step(struct task_struct *task)
if (test_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP))
set_regs_spsr_ss(task_pt_regs(task));
 }
+NOKPROBE_SYMBOL(user_rewind_single_step);
 
 void user_fastforward_single_step(struct task_struct *task)
 {
@@ -413,6 +425,7 @@ void kernel_enable_single_step(struct pt_regs *regs)
mdscr_write(mdscr_read() | DBG_MDSCR_SS);
enable_debug_monitors(DBG_ACTIVE_EL1);
 }
+NOKPROBE_SYMBOL(kernel_enable_single_step);
 
 void kernel_disable_single_step(void)
 {
@@ -420,12 +433,14 @@ void kernel_disable_single_step(void)
mdscr_write(mdscr_read() & ~DBG_MDSCR_SS);
disable_debug_monitors(DBG_ACTIVE_EL1);
 }
+NOKPROBE_SYMBOL(kernel_disable_single_step);
 
 int kernel_active_single_step(void)
 {
WARN_ON(!irqs_disabled());
return mdscr_read() & DBG_MDSCR_SS;
 }
+NOKPROBE_SYMBOL(kernel_active_single_step);
 
 /* ptrace API */
 void user_enable_single_step(struct task_struct *task)
@@ -433,8 +448,10 @@ void user_enable_single_step(struct task_struct *task)
set_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
set_regs_spsr_ss(task_pt_regs(task));
 }
+NOKPROBE_SYMBOL(user_enable_single_step);
 
 void user_disable_single_step(struct task_struct *task)
 {
clear_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
 }
+NOKPROBE_SYMBOL(user_disable_single_step);
diff --git a/arch/arm64/kernel/hw_breakpoint.c 
b/arch/arm64/kernel/hw_breakpoint.c
index 

[PATCH v14 02/10] arm64: Add more test functions to insn.c

[David Long]

From: "David A. Long" 

Certain instructions are hard to execute correctly out-of-line (as in
kprobes).  Test functions are added to insn.[hc] to identify these.  The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.

Signed-off-by: David A. Long 
---
 arch/arm64/include/asm/insn.h | 36 
 arch/arm64/kernel/insn.c  | 34 ++
 2 files changed, 70 insertions(+)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 30e50eb..497f7a2 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -120,6 +120,29 @@ enum aarch64_insn_register {
AARCH64_INSN_REG_SP = 31  /* Stack pointer: as load/store base reg */
 };
 
+enum aarch64_insn_special_register {
+   AARCH64_INSN_SPCLREG_SPSR_EL1   = 0xC200,
+   AARCH64_INSN_SPCLREG_ELR_EL1= 0xC201,
+   AARCH64_INSN_SPCLREG_SP_EL0 = 0xC208,
+   AARCH64_INSN_SPCLREG_SPSEL  = 0xC210,
+   AARCH64_INSN_SPCLREG_CURRENTEL  = 0xC212,
+   AARCH64_INSN_SPCLREG_DAIF   = 0xDA11,
+   AARCH64_INSN_SPCLREG_NZCV   = 0xDA10,
+   AARCH64_INSN_SPCLREG_FPCR   = 0xDA20,
+   AARCH64_INSN_SPCLREG_DSPSR_EL0  = 0xDA28,
+   AARCH64_INSN_SPCLREG_DLR_EL0= 0xDA29,
+   AARCH64_INSN_SPCLREG_SPSR_EL2   = 0xE200,
+   AARCH64_INSN_SPCLREG_ELR_EL2= 0xE201,
+   AARCH64_INSN_SPCLREG_SP_EL1 = 0xE208,
+   AARCH64_INSN_SPCLREG_SPSR_INQ   = 0xE218,
+   AARCH64_INSN_SPCLREG_SPSR_ABT   = 0xE219,
+   AARCH64_INSN_SPCLREG_SPSR_UND   = 0xE21A,
+   AARCH64_INSN_SPCLREG_SPSR_FIQ   = 0xE21B,
+   AARCH64_INSN_SPCLREG_SPSR_EL3   = 0xF200,
+   AARCH64_INSN_SPCLREG_ELR_EL3= 0xF201,
+   AARCH64_INSN_SPCLREG_SP_EL2 = 0xF210
+};
+
 enum aarch64_insn_variant {
AARCH64_INSN_VARIANT_32BIT,
AARCH64_INSN_VARIANT_64BIT
@@ -223,8 +246,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32 
code) \
 static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
 { return (val); }
 
+__AARCH64_INSN_FUNCS(adr_adrp, 0x1F00, 0x1000)
+__AARCH64_INSN_FUNCS(prfm_lit, 0xFF00, 0xD800)
 __AARCH64_INSN_FUNCS(str_reg,  0x3FE0EC00, 0x38206800)
 __AARCH64_INSN_FUNCS(ldr_reg,  0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(ldr_lit,  0xBF00, 0x1800)
+__AARCH64_INSN_FUNCS(ldrsw_lit,0xFF00, 0x9800)
+__AARCH64_INSN_FUNCS(exclusive,0x3F80, 0x0800)
 __AARCH64_INSN_FUNCS(stp_post, 0x7FC0, 0x2880)
 __AARCH64_INSN_FUNCS(ldp_post, 0x7FC0, 0x28C0)
 __AARCH64_INSN_FUNCS(stp_pre,  0x7FC0, 0x2980)
@@ -273,10 +301,15 @@ __AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD401)
 __AARCH64_INSN_FUNCS(hvc,  0xFFE0001F, 0xD402)
 __AARCH64_INSN_FUNCS(smc,  0xFFE0001F, 0xD403)
 __AARCH64_INSN_FUNCS(brk,  0xFFE0001F, 0xD420)
+__AARCH64_INSN_FUNCS(exception,0xFF00, 0xD400)
 __AARCH64_INSN_FUNCS(hint, 0xF01F, 0xD503201F)
 __AARCH64_INSN_FUNCS(br,   0xFC1F, 0xD61F)
 __AARCH64_INSN_FUNCS(blr,  0xFC1F, 0xD63F)
 __AARCH64_INSN_FUNCS(ret,  0xFC1F, 0xD65F)
+__AARCH64_INSN_FUNCS(eret, 0x, 0xD69F03E0)
+__AARCH64_INSN_FUNCS(mrs,  0xFFF0, 0xD530)
+__AARCH64_INSN_FUNCS(msr_imm,  0xFFF8F01F, 0xD500401F)
+__AARCH64_INSN_FUNCS(msr_reg,  0xFFF0, 0xD510)
 
 #undef __AARCH64_INSN_FUNCS
 
@@ -286,6 +319,8 @@ bool aarch64_insn_is_branch_imm(u32 insn);
 int aarch64_insn_read(void *addr, u32 *insnp);
 int aarch64_insn_write(void *addr, u32 insn);
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+bool aarch64_insn_uses_literal(u32 insn);
+bool aarch64_insn_is_branch(u32 insn);
 u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn);
 u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
  u32 insn, u64 imm);
@@ -367,6 +402,7 @@ bool aarch32_insn_is_wide(u32 insn);
 #define A32_RT_OFFSET  12
 #define A32_RT2_OFFSET  0
 
+u32 aarch64_insn_extract_system_reg(u32 insn);
 u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
 u32 aarch32_insn_mcr_extract_opc2(u32 insn);
 u32 aarch32_insn_mcr_extract_crm(u32 insn);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 368c082..28c6110f 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -162,6 +162,32 @@ static bool __kprobes __aarch64_insn_hotpatch_safe(u32 
insn)
aarch64_insn_is_nop(insn);
 }
 
+bool __kprobes aarch64_insn_uses_literal(u32 insn)
+{
+   /* ldr/ldrsw (literal), prfm */
+
+   return aarch64_insn_is_ldr_lit(insn) ||
+   aarch64_insn_is_ldrsw_lit(insn) ||
+   aarch64_insn_is_adr_adrp(insn) ||
+   

[PATCH v14 02/10] arm64: Add more test functions to insn.c

[David Long]

From: "David A. Long" 

Certain instructions are hard to execute correctly out-of-line (as in
kprobes).  Test functions are added to insn.[hc] to identify these.  The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.

Signed-off-by: David A. Long 
---
 arch/arm64/include/asm/insn.h | 36 
 arch/arm64/kernel/insn.c  | 34 ++
 2 files changed, 70 insertions(+)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 30e50eb..497f7a2 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -120,6 +120,29 @@ enum aarch64_insn_register {
AARCH64_INSN_REG_SP = 31  /* Stack pointer: as load/store base reg */
 };
 
+enum aarch64_insn_special_register {
+   AARCH64_INSN_SPCLREG_SPSR_EL1   = 0xC200,
+   AARCH64_INSN_SPCLREG_ELR_EL1= 0xC201,
+   AARCH64_INSN_SPCLREG_SP_EL0 = 0xC208,
+   AARCH64_INSN_SPCLREG_SPSEL  = 0xC210,
+   AARCH64_INSN_SPCLREG_CURRENTEL  = 0xC212,
+   AARCH64_INSN_SPCLREG_DAIF   = 0xDA11,
+   AARCH64_INSN_SPCLREG_NZCV   = 0xDA10,
+   AARCH64_INSN_SPCLREG_FPCR   = 0xDA20,
+   AARCH64_INSN_SPCLREG_DSPSR_EL0  = 0xDA28,
+   AARCH64_INSN_SPCLREG_DLR_EL0= 0xDA29,
+   AARCH64_INSN_SPCLREG_SPSR_EL2   = 0xE200,
+   AARCH64_INSN_SPCLREG_ELR_EL2= 0xE201,
+   AARCH64_INSN_SPCLREG_SP_EL1 = 0xE208,
+   AARCH64_INSN_SPCLREG_SPSR_INQ   = 0xE218,
+   AARCH64_INSN_SPCLREG_SPSR_ABT   = 0xE219,
+   AARCH64_INSN_SPCLREG_SPSR_UND   = 0xE21A,
+   AARCH64_INSN_SPCLREG_SPSR_FIQ   = 0xE21B,
+   AARCH64_INSN_SPCLREG_SPSR_EL3   = 0xF200,
+   AARCH64_INSN_SPCLREG_ELR_EL3= 0xF201,
+   AARCH64_INSN_SPCLREG_SP_EL2 = 0xF210
+};
+
 enum aarch64_insn_variant {
AARCH64_INSN_VARIANT_32BIT,
AARCH64_INSN_VARIANT_64BIT
@@ -223,8 +246,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32 
code) \
 static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
 { return (val); }
 
+__AARCH64_INSN_FUNCS(adr_adrp, 0x1F00, 0x1000)
+__AARCH64_INSN_FUNCS(prfm_lit, 0xFF00, 0xD800)
 __AARCH64_INSN_FUNCS(str_reg,  0x3FE0EC00, 0x38206800)
 __AARCH64_INSN_FUNCS(ldr_reg,  0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(ldr_lit,  0xBF00, 0x1800)
+__AARCH64_INSN_FUNCS(ldrsw_lit,0xFF00, 0x9800)
+__AARCH64_INSN_FUNCS(exclusive,0x3F80, 0x0800)
 __AARCH64_INSN_FUNCS(stp_post, 0x7FC0, 0x2880)
 __AARCH64_INSN_FUNCS(ldp_post, 0x7FC0, 0x28C0)
 __AARCH64_INSN_FUNCS(stp_pre,  0x7FC0, 0x2980)
@@ -273,10 +301,15 @@ __AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD401)
 __AARCH64_INSN_FUNCS(hvc,  0xFFE0001F, 0xD402)
 __AARCH64_INSN_FUNCS(smc,  0xFFE0001F, 0xD403)
 __AARCH64_INSN_FUNCS(brk,  0xFFE0001F, 0xD420)
+__AARCH64_INSN_FUNCS(exception,0xFF00, 0xD400)
 __AARCH64_INSN_FUNCS(hint, 0xF01F, 0xD503201F)
 __AARCH64_INSN_FUNCS(br,   0xFC1F, 0xD61F)
 __AARCH64_INSN_FUNCS(blr,  0xFC1F, 0xD63F)
 __AARCH64_INSN_FUNCS(ret,  0xFC1F, 0xD65F)
+__AARCH64_INSN_FUNCS(eret, 0x, 0xD69F03E0)
+__AARCH64_INSN_FUNCS(mrs,  0xFFF0, 0xD530)
+__AARCH64_INSN_FUNCS(msr_imm,  0xFFF8F01F, 0xD500401F)
+__AARCH64_INSN_FUNCS(msr_reg,  0xFFF0, 0xD510)
 
 #undef __AARCH64_INSN_FUNCS
 
@@ -286,6 +319,8 @@ bool aarch64_insn_is_branch_imm(u32 insn);
 int aarch64_insn_read(void *addr, u32 *insnp);
 int aarch64_insn_write(void *addr, u32 insn);
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+bool aarch64_insn_uses_literal(u32 insn);
+bool aarch64_insn_is_branch(u32 insn);
 u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn);
 u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
  u32 insn, u64 imm);
@@ -367,6 +402,7 @@ bool aarch32_insn_is_wide(u32 insn);
 #define A32_RT_OFFSET  12
 #define A32_RT2_OFFSET  0
 
+u32 aarch64_insn_extract_system_reg(u32 insn);
 u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
 u32 aarch32_insn_mcr_extract_opc2(u32 insn);
 u32 aarch32_insn_mcr_extract_crm(u32 insn);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 368c082..28c6110f 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -162,6 +162,32 @@ static bool __kprobes __aarch64_insn_hotpatch_safe(u32 
insn)
aarch64_insn_is_nop(insn);
 }
 
+bool __kprobes aarch64_insn_uses_literal(u32 insn)
+{
+   /* ldr/ldrsw (literal), prfm */
+
+   return aarch64_insn_is_ldr_lit(insn) ||
+   aarch64_insn_is_ldrsw_lit(insn) ||
+   aarch64_insn_is_adr_adrp(insn) ||
+   aarch64_insn_is_prfm_lit(insn);
+}
+
+bool 

[PATCH v14 04/10] arm64: Kprobes with single stepping support

[David Long]

From: Sandeepa Prabhu 

Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.

Kprobes utilizes software breakpoint and single step debug
exceptions supported on ARM v8.

A software breakpoint is placed at the probe address to trap the
kernel execution into the kprobe handler.

ARM v8 supports enabling single stepping before the break exception
return (ERET), with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping. The PC is set to the out-of-line slot address
before the ERET. With this scheme, the instruction is executed with the
exact same register context except for the PC (and DAIF) registers.

Debug mask (PSTATE.D) is enabled only when single stepping a recursive
kprobe, e.g.: during kprobes reenter so that probed instruction can be
single stepped within the kprobe handler -exception- context.
The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
any further re-entry is prevented by not calling handlers and the case
counted as a missed kprobe).

Single stepping from the x-o-l slot has a drawback for PC-relative accesses
like branching and symbolic literals access as the offset from the new PC
(slot address) may not be ensured to fit in the immediate value of
the opcode. Such instructions need simulation, so reject
probing them.

Instructions generating exceptions or cpu mode change are rejected
for probing.

Exclusive load/store instructions are rejected too.  Additionally, the
code is checked to see if it is inside an exclusive load/store sequence
(code from Pratyush).

System instructions are mostly enabled for stepping, except MSR/MRS
accesses to "DAIF" flags in PSTATE, which are not safe for
probing.

Thanks to Steve Capper and Pratyush Anand for several suggested
Changes.

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: David A. Long 
Signed-off-by: Pratyush Anand 
---
 arch/arm64/Kconfig  |   1 +
 arch/arm64/include/asm/debug-monitors.h |   5 +
 arch/arm64/include/asm/insn.h   |   2 +
 arch/arm64/include/asm/kprobes.h|  60 
 arch/arm64/include/asm/probes.h |  34 +++
 arch/arm64/include/asm/ptrace.h |   1 +
 arch/arm64/kernel/Makefile  |   2 +-
 arch/arm64/kernel/debug-monitors.c  |  16 +-
 arch/arm64/kernel/kprobes/Makefile  |   1 +
 arch/arm64/kernel/kprobes/decode-insn.c | 143 +
 arch/arm64/kernel/kprobes/decode-insn.h |  34 +++
 arch/arm64/kernel/kprobes/kprobes.c | 525 
 arch/arm64/kernel/vmlinux.lds.S |   1 +
 arch/arm64/mm/fault.c   |  26 ++
 14 files changed, 848 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/include/asm/kprobes.h
 create mode 100644 arch/arm64/include/asm/probes.h
 create mode 100644 arch/arm64/kernel/kprobes/Makefile
 create mode 100644 arch/arm64/kernel/kprobes/decode-insn.c
 create mode 100644 arch/arm64/kernel/kprobes/decode-insn.h
 create mode 100644 arch/arm64/kernel/kprobes/kprobes.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fab133c..1f7d644 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -88,6 +88,7 @@ config ARM64
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
+   select HAVE_KPROBES
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/arm64/include/asm/debug-monitors.h 
b/arch/arm64/include/asm/debug-monitors.h
index 2fcb9b7..4b6b3f7 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -66,6 +66,11 @@
 
 #define CACHE_FLUSH_IS_SAFE1
 
+/* kprobes BRK opcodes with ESR encoding  */
+#define BRK64_ESR_MASK 0x
+#define BRK64_ESR_KPROBES  0x0004
+#define BRK64_OPCODE_KPROBES   (AARCH64_BREAK_MON | (BRK64_ESR_KPROBES << 5))
+
 /* AArch32 */
 #define DBG_ESR_EVT_BKPT   0x4
 #define DBG_ESR_EVT_VECC   0x5
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index a44abbd..1dbaa90 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -253,6 +253,8 @@ __AARCH64_INSN_FUNCS(ldr_reg,   0x3FE0EC00, 0x38606800)
 __AARCH64_INSN_FUNCS(ldr_lit,  0xBF00, 0x1800)
 __AARCH64_INSN_FUNCS(ldrsw_lit,0xFF00, 0x9800)
 __AARCH64_INSN_FUNCS(exclusive,0x3F80, 0x0800)
+__AARCH64_INSN_FUNCS(load_ex,  0x3F40, 0x0840)
+__AARCH64_INSN_FUNCS(store_ex, 0x3F40, 0x0800)
 __AARCH64_INSN_FUNCS(stp_post, 0x7FC0, 0x2880)
 __AARCH64_INSN_FUNCS(ldp_post, 0x7FC0, 0x28C0)
 __AARCH64_INSN_FUNCS(stp_pre,  0x7FC0, 0x2980)
diff --git a/arch/arm64/include/asm/kprobes.h 

[PATCH v14 09/10] arm64: Add kernel return probes support (kretprobes)

[David Long]

From: Sandeepa Prabhu 

The pre-handler of this special 'trampoline' kprobe executes the return
probe handler functions and restores original return address in ELR_EL1.
This way the saved pt_regs still hold the original register context to be
carried back to the probed kernel function.

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: David A. Long 
---
 arch/arm64/Kconfig  |  1 +
 arch/arm64/kernel/kprobes/kprobes.c | 90 -
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f7d644..6af0e2e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -89,6 +89,7 @@ config ARM64
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
+   select HAVE_KRETPROBES if HAVE_KPROBES
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/arm64/kernel/kprobes/kprobes.c 
b/arch/arm64/kernel/kprobes/kprobes.c
index 89936d2..b5d9b9c 100644
--- a/arch/arm64/kernel/kprobes/kprobes.c
+++ b/arch/arm64/kernel/kprobes/kprobes.c
@@ -578,7 +578,95 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
 
 void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
 {
-   return NULL;
+   struct kretprobe_instance *ri = NULL;
+   struct hlist_head *head, empty_rp;
+   struct hlist_node *tmp;
+   unsigned long flags, orig_ret_address = 0;
+   unsigned long trampoline_address =
+   (unsigned long)_trampoline;
+   kprobe_opcode_t *correct_ret_addr = NULL;
+
+   INIT_HLIST_HEAD(_rp);
+   kretprobe_hash_lock(current, , );
+
+   /*
+* It is possible to have multiple instances associated with a given
+* task either because multiple functions in the call path have
+* return probes installed on them, and/or more than one
+* return probe was registered for a target function.
+*
+* We can handle this because:
+* - instances are always pushed into the head of the list
+* - when multiple return probes are registered for the same
+*   function, the (chronologically) first instance's ret_addr
+*   will be the real return address, and all the rest will
+*   point to kretprobe_trampoline.
+*/
+   hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+   if (ri->task != current)
+   /* another task is sharing our hash bucket */
+   continue;
+
+   orig_ret_address = (unsigned long)ri->ret_addr;
+
+   if (orig_ret_address != trampoline_address)
+   /*
+* This is the real return address. Any other
+* instances associated with this task are for
+* other calls deeper on the call stack
+*/
+   break;
+   }
+
+   kretprobe_assert(ri, orig_ret_address, trampoline_address);
+
+   correct_ret_addr = ri->ret_addr;
+   hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+   if (ri->task != current)
+   /* another task is sharing our hash bucket */
+   continue;
+
+   orig_ret_address = (unsigned long)ri->ret_addr;
+   if (ri->rp && ri->rp->handler) {
+   __this_cpu_write(current_kprobe, >rp->kp);
+   get_kprobe_ctlblk()->kprobe_status = KPROBE_HIT_ACTIVE;
+   ri->ret_addr = correct_ret_addr;
+   ri->rp->handler(ri, regs);
+   __this_cpu_write(current_kprobe, NULL);
+   }
+
+   recycle_rp_inst(ri, _rp);
+
+   if (orig_ret_address != trampoline_address)
+   /*
+* This is the real return address. Any other
+* instances associated with this task are for
+* other calls deeper on the call stack
+*/
+   break;
+   }
+
+   kretprobe_hash_unlock(current, );
+
+   hlist_for_each_entry_safe(ri, tmp, _rp, hlist) {
+   hlist_del(>hlist);
+   kfree(ri);
+   }
+   return (void *)orig_ret_address;
+}
+
+void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
+ struct pt_regs *regs)
+{
+   ri->ret_addr = (kprobe_opcode_t *)regs->regs[30];
+
+   /* replace return addr (x30) with trampoline */
+   regs->regs[30] = (long)_trampoline;
+}
+
+int __kprobes arch_trampoline_kprobe(struct kprobe *p)
+{
+   return 0;
 }
 
 int __init arch_init_kprobes(void)
-- 
2.5.0

[PATCH v14 10/10] kprobes: Add arm64 case in kprobe example module

[David Long]

From: Sandeepa Prabhu 

Add info prints in sample kprobe handlers for ARM64

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: David A. Long 
---
 samples/kprobes/kprobe_example.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index ed0ca0c..f3b61b4 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -46,6 +46,11 @@ static int handler_pre(struct kprobe *p, struct pt_regs 
*regs)
" ex1 = 0x%lx\n",
p->symbol_name, p->addr, regs->pc, regs->ex1);
 #endif
+#ifdef CONFIG_ARM64
+   pr_info("<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx,"
+   " pstate = 0x%lx\n",
+   p->symbol_name, p->addr, (long)regs->pc, (long)regs->pstate);
+#endif
 
/* A dump_stack() here will give a stack backtrace */
return 0;
@@ -71,6 +76,10 @@ static void handler_post(struct kprobe *p, struct pt_regs 
*regs,
printk(KERN_INFO "<%s> post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
p->symbol_name, p->addr, regs->ex1);
 #endif
+#ifdef CONFIG_ARM64
+   pr_info("<%s> post_handler: p->addr = 0x%p, pstate = 0x%lx\n",
+   p->symbol_name, p->addr, (long)regs->pstate);
+#endif
 }
 
 /*
-- 
2.5.0

[PATCH v14 04/10] arm64: Kprobes with single stepping support

[David Long]

From: Sandeepa Prabhu 

Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.

Kprobes utilizes software breakpoint and single step debug
exceptions supported on ARM v8.

A software breakpoint is placed at the probe address to trap the
kernel execution into the kprobe handler.

ARM v8 supports enabling single stepping before the break exception
return (ERET), with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping. The PC is set to the out-of-line slot address
before the ERET. With this scheme, the instruction is executed with the
exact same register context except for the PC (and DAIF) registers.

Debug mask (PSTATE.D) is enabled only when single stepping a recursive
kprobe, e.g.: during kprobes reenter so that probed instruction can be
single stepped within the kprobe handler -exception- context.
The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
any further re-entry is prevented by not calling handlers and the case
counted as a missed kprobe).

Single stepping from the x-o-l slot has a drawback for PC-relative accesses
like branching and symbolic literals access as the offset from the new PC
(slot address) may not be ensured to fit in the immediate value of
the opcode. Such instructions need simulation, so reject
probing them.

Instructions generating exceptions or cpu mode change are rejected
for probing.

Exclusive load/store instructions are rejected too.  Additionally, the
code is checked to see if it is inside an exclusive load/store sequence
(code from Pratyush).

System instructions are mostly enabled for stepping, except MSR/MRS
accesses to "DAIF" flags in PSTATE, which are not safe for
probing.

Thanks to Steve Capper and Pratyush Anand for several suggested
Changes.

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: David A. Long 
Signed-off-by: Pratyush Anand 
---
 arch/arm64/Kconfig  |   1 +
 arch/arm64/include/asm/debug-monitors.h |   5 +
 arch/arm64/include/asm/insn.h   |   2 +
 arch/arm64/include/asm/kprobes.h|  60 
 arch/arm64/include/asm/probes.h |  34 +++
 arch/arm64/include/asm/ptrace.h |   1 +
 arch/arm64/kernel/Makefile  |   2 +-
 arch/arm64/kernel/debug-monitors.c  |  16 +-
 arch/arm64/kernel/kprobes/Makefile  |   1 +
 arch/arm64/kernel/kprobes/decode-insn.c | 143 +
 arch/arm64/kernel/kprobes/decode-insn.h |  34 +++
 arch/arm64/kernel/kprobes/kprobes.c | 525 
 arch/arm64/kernel/vmlinux.lds.S |   1 +
 arch/arm64/mm/fault.c   |  26 ++
 14 files changed, 848 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/include/asm/kprobes.h
 create mode 100644 arch/arm64/include/asm/probes.h
 create mode 100644 arch/arm64/kernel/kprobes/Makefile
 create mode 100644 arch/arm64/kernel/kprobes/decode-insn.c
 create mode 100644 arch/arm64/kernel/kprobes/decode-insn.h
 create mode 100644 arch/arm64/kernel/kprobes/kprobes.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fab133c..1f7d644 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -88,6 +88,7 @@ config ARM64
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
+   select HAVE_KPROBES
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/arm64/include/asm/debug-monitors.h 
b/arch/arm64/include/asm/debug-monitors.h
index 2fcb9b7..4b6b3f7 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -66,6 +66,11 @@
 
 #define CACHE_FLUSH_IS_SAFE1
 
+/* kprobes BRK opcodes with ESR encoding  */
+#define BRK64_ESR_MASK 0x
+#define BRK64_ESR_KPROBES  0x0004
+#define BRK64_OPCODE_KPROBES   (AARCH64_BREAK_MON | (BRK64_ESR_KPROBES << 5))
+
 /* AArch32 */
 #define DBG_ESR_EVT_BKPT   0x4
 #define DBG_ESR_EVT_VECC   0x5
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index a44abbd..1dbaa90 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -253,6 +253,8 @@ __AARCH64_INSN_FUNCS(ldr_reg,   0x3FE0EC00, 0x38606800)
 __AARCH64_INSN_FUNCS(ldr_lit,  0xBF00, 0x1800)
 __AARCH64_INSN_FUNCS(ldrsw_lit,0xFF00, 0x9800)
 __AARCH64_INSN_FUNCS(exclusive,0x3F80, 0x0800)
+__AARCH64_INSN_FUNCS(load_ex,  0x3F40, 0x0840)
+__AARCH64_INSN_FUNCS(store_ex, 0x3F40, 0x0800)
 __AARCH64_INSN_FUNCS(stp_post, 0x7FC0, 0x2880)
 __AARCH64_INSN_FUNCS(ldp_post, 0x7FC0, 0x28C0)
 __AARCH64_INSN_FUNCS(stp_pre,  0x7FC0, 0x2980)
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
new file mode 100644
index 000..79c9511
--- /dev/null
+++ 

[PATCH v14 09/10] arm64: Add kernel return probes support (kretprobes)

[David Long]

From: Sandeepa Prabhu 

The pre-handler of this special 'trampoline' kprobe executes the return
probe handler functions and restores original return address in ELR_EL1.
This way the saved pt_regs still hold the original register context to be
carried back to the probed kernel function.

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: David A. Long 
---
 arch/arm64/Kconfig  |  1 +
 arch/arm64/kernel/kprobes/kprobes.c | 90 -
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f7d644..6af0e2e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -89,6 +89,7 @@ config ARM64
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
+   select HAVE_KRETPROBES if HAVE_KPROBES
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/arm64/kernel/kprobes/kprobes.c 
b/arch/arm64/kernel/kprobes/kprobes.c
index 89936d2..b5d9b9c 100644
--- a/arch/arm64/kernel/kprobes/kprobes.c
+++ b/arch/arm64/kernel/kprobes/kprobes.c
@@ -578,7 +578,95 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
 
 void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
 {
-   return NULL;
+   struct kretprobe_instance *ri = NULL;
+   struct hlist_head *head, empty_rp;
+   struct hlist_node *tmp;
+   unsigned long flags, orig_ret_address = 0;
+   unsigned long trampoline_address =
+   (unsigned long)_trampoline;
+   kprobe_opcode_t *correct_ret_addr = NULL;
+
+   INIT_HLIST_HEAD(_rp);
+   kretprobe_hash_lock(current, , );
+
+   /*
+* It is possible to have multiple instances associated with a given
+* task either because multiple functions in the call path have
+* return probes installed on them, and/or more than one
+* return probe was registered for a target function.
+*
+* We can handle this because:
+* - instances are always pushed into the head of the list
+* - when multiple return probes are registered for the same
+*   function, the (chronologically) first instance's ret_addr
+*   will be the real return address, and all the rest will
+*   point to kretprobe_trampoline.
+*/
+   hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+   if (ri->task != current)
+   /* another task is sharing our hash bucket */
+   continue;
+
+   orig_ret_address = (unsigned long)ri->ret_addr;
+
+   if (orig_ret_address != trampoline_address)
+   /*
+* This is the real return address. Any other
+* instances associated with this task are for
+* other calls deeper on the call stack
+*/
+   break;
+   }
+
+   kretprobe_assert(ri, orig_ret_address, trampoline_address);
+
+   correct_ret_addr = ri->ret_addr;
+   hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+   if (ri->task != current)
+   /* another task is sharing our hash bucket */
+   continue;
+
+   orig_ret_address = (unsigned long)ri->ret_addr;
+   if (ri->rp && ri->rp->handler) {
+   __this_cpu_write(current_kprobe, >rp->kp);
+   get_kprobe_ctlblk()->kprobe_status = KPROBE_HIT_ACTIVE;
+   ri->ret_addr = correct_ret_addr;
+   ri->rp->handler(ri, regs);
+   __this_cpu_write(current_kprobe, NULL);
+   }
+
+   recycle_rp_inst(ri, _rp);
+
+   if (orig_ret_address != trampoline_address)
+   /*
+* This is the real return address. Any other
+* instances associated with this task are for
+* other calls deeper on the call stack
+*/
+   break;
+   }
+
+   kretprobe_hash_unlock(current, );
+
+   hlist_for_each_entry_safe(ri, tmp, _rp, hlist) {
+   hlist_del(>hlist);
+   kfree(ri);
+   }
+   return (void *)orig_ret_address;
+}
+
+void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
+ struct pt_regs *regs)
+{
+   ri->ret_addr = (kprobe_opcode_t *)regs->regs[30];
+
+   /* replace return addr (x30) with trampoline */
+   regs->regs[30] = (long)_trampoline;
+}
+
+int __kprobes arch_trampoline_kprobe(struct kprobe *p)
+{
+   return 0;
 }
 
 int __init arch_init_kprobes(void)
-- 
2.5.0

[PATCH v14 10/10] kprobes: Add arm64 case in kprobe example module

[David Long]

From: Sandeepa Prabhu 

Add info prints in sample kprobe handlers for ARM64

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: David A. Long 
---
 samples/kprobes/kprobe_example.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index ed0ca0c..f3b61b4 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -46,6 +46,11 @@ static int handler_pre(struct kprobe *p, struct pt_regs 
*regs)
" ex1 = 0x%lx\n",
p->symbol_name, p->addr, regs->pc, regs->ex1);
 #endif
+#ifdef CONFIG_ARM64
+   pr_info("<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx,"
+   " pstate = 0x%lx\n",
+   p->symbol_name, p->addr, (long)regs->pc, (long)regs->pstate);
+#endif
 
/* A dump_stack() here will give a stack backtrace */
return 0;
@@ -71,6 +76,10 @@ static void handler_post(struct kprobe *p, struct pt_regs 
*regs,
printk(KERN_INFO "<%s> post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
p->symbol_name, p->addr, regs->ex1);
 #endif
+#ifdef CONFIG_ARM64
+   pr_info("<%s> post_handler: p->addr = 0x%p, pstate = 0x%lx\n",
+   p->symbol_name, p->addr, (long)regs->pstate);
+#endif
 }
 
 /*
-- 
2.5.0