Re: [PATCH] pci/sriov: Add an option to probe VFs or not before enabling SR-IOV

[Gavin Shan]

On Mon, Mar 20, 2017 at 10:57:08PM -0600, Alex Williamson wrote:
>On Mon, 20 Mar 2017 18:34:23 -0500
>Bodong Wang  wrote:

.../...

>> > Bodong, I'm not sure if there is a requirement to load driver for the
>> > specified number of VFs? That indicates no driver will be loaded for
>> > other VFs. If so, this interface might serve the purpose as well.  
>> Gavin, thanks for the review. That is indeed an interesting suggestion. 
>> Theoretically,  we can change that probe_vfs from boolean to integer. 
>> And use it as a counter to probe the first N VFs(if N < total_vfs).  
>> Let's see if there are any objections.
>
>Is it just me or does this seem like a confusing user interface, ie. to
>get binary on/off behavior a user now needs to 'cat total_vfs >
>sriov_probe_vfs'.  It's not very intuitive, what's the use case for it?
>

After it's changed to integer, it accepts number. If users want to load
driver for all VFs and don't want to check the maximal number of VFs,
they can simply write 0x. So "on" and "off" are replaced with 0x
and 0, but users has to press the keyboard more times though.

drivers/net/ethernet/mellanox/mlx4/main.c::probe_vfs_argc allows to specify
the number of VFs with which we're going to bind drivers. Less time is needed
to enable SRIOV capability. As I had in some development environment: assume
PF supports 256 VFs and I'm going to enable all of them, but I only want to
load driver for two of them, then test the data path on those two VFs. Besides,
I can image the VF needn't a driver in host if it's going to be passed to 
guest. 
Not sure how much sense it makes.

Thanks,
Gavin

Re: [PATCH] pci/sriov: Add an option to probe VFs or not before enabling SR-IOV

[Gavin Shan]

On Mon, Mar 20, 2017 at 10:57:08PM -0600, Alex Williamson wrote:
>On Mon, 20 Mar 2017 18:34:23 -0500
>Bodong Wang  wrote:

.../...

>> > Bodong, I'm not sure if there is a requirement to load driver for the
>> > specified number of VFs? That indicates no driver will be loaded for
>> > other VFs. If so, this interface might serve the purpose as well.  
>> Gavin, thanks for the review. That is indeed an interesting suggestion. 
>> Theoretically,  we can change that probe_vfs from boolean to integer. 
>> And use it as a counter to probe the first N VFs(if N < total_vfs).  
>> Let's see if there are any objections.
>
>Is it just me or does this seem like a confusing user interface, ie. to
>get binary on/off behavior a user now needs to 'cat total_vfs >
>sriov_probe_vfs'.  It's not very intuitive, what's the use case for it?
>

After it's changed to integer, it accepts number. If users want to load
driver for all VFs and don't want to check the maximal number of VFs,
they can simply write 0x. So "on" and "off" are replaced with 0x
and 0, but users has to press the keyboard more times though.

drivers/net/ethernet/mellanox/mlx4/main.c::probe_vfs_argc allows to specify
the number of VFs with which we're going to bind drivers. Less time is needed
to enable SRIOV capability. As I had in some development environment: assume
PF supports 256 VFs and I'm going to enable all of them, but I only want to
load driver for two of them, then test the data path on those two VFs. Besides,
I can image the VF needn't a driver in host if it's going to be passed to 
guest. 
Not sure how much sense it makes.

Thanks,
Gavin

Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

[Kai-Heng Feng]

On Tue, Mar 21, 2017 at 11:07 AM, Bard Liao  wrote:
>> -Original Message-
>> From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com]
>> Sent: Monday, March 20, 2017 11:59 AM
>> To: broo...@kernel.org
>> Cc: lgirdw...@gmail.com; Bard Liao; Oder Chiou;
>> alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org; Kai-Heng Feng
>> Subject: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS
>> 9343 I2S mode
>>
>> + switch (event) {
>> + case SND_SOC_DAPM_PRE_PMD:
>> + case SND_SOC_DAPM_POST_PMD:
>> + case SND_SOC_DAPM_POST_PMU:
>> + snd_soc_write(codec, RT286_SET_AMP_GAIN_HPO,
>> AMP_OUT_MUTE);
>> + break;
>> + case SND_SOC_DAPM_PRE_PMU:
>> + snd_soc_write(codec, RT286_SET_AMP_GAIN_HPO,
>> AMP_OUT_UNMUTE);
>> + break;
>
> Besides Mark's comment, I have question here. It seems you want to mute
> HPO before "HP Power" is powered up and after "HP Power" is powered down.
> But "HPO L" and "HPO R" are autodisable. And "HP Power" is only connect to

What I really want to do is something rt5670's rt5670_hp_event(),
maybe autodisable is not enough sometimes?

> "HPO L" and "HPO R". From my understanding, HPO will mute if "HP Power"
> is powered down. Any specific reason for muting HPO again before "HP Power"
> is powered up?

You are right. Either one of them should be sufficient.

> Will HPO be unmuted before "HP Power" is powered up on your system?

Yes.
I am no audio expert here - but from what I read from HDA, there's
actually no AMP unmute counterpart to AMP mute.

> Or should the event be associated with "LDO1"?  Which power will
> cause the click noise?

I found that the effect is most noticeable if the mute callback is
associated with "LDO2" and "HP Power".
But again, this is just what I observed.

>
>

Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

[Kai-Heng Feng]

On Tue, Mar 21, 2017 at 11:07 AM, Bard Liao  wrote:
>> -Original Message-
>> From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com]
>> Sent: Monday, March 20, 2017 11:59 AM
>> To: broo...@kernel.org
>> Cc: lgirdw...@gmail.com; Bard Liao; Oder Chiou;
>> alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org; Kai-Heng Feng
>> Subject: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS
>> 9343 I2S mode
>>
>> + switch (event) {
>> + case SND_SOC_DAPM_PRE_PMD:
>> + case SND_SOC_DAPM_POST_PMD:
>> + case SND_SOC_DAPM_POST_PMU:
>> + snd_soc_write(codec, RT286_SET_AMP_GAIN_HPO,
>> AMP_OUT_MUTE);
>> + break;
>> + case SND_SOC_DAPM_PRE_PMU:
>> + snd_soc_write(codec, RT286_SET_AMP_GAIN_HPO,
>> AMP_OUT_UNMUTE);
>> + break;
>
> Besides Mark's comment, I have question here. It seems you want to mute
> HPO before "HP Power" is powered up and after "HP Power" is powered down.
> But "HPO L" and "HPO R" are autodisable. And "HP Power" is only connect to

What I really want to do is something rt5670's rt5670_hp_event(),
maybe autodisable is not enough sometimes?

> "HPO L" and "HPO R". From my understanding, HPO will mute if "HP Power"
> is powered down. Any specific reason for muting HPO again before "HP Power"
> is powered up?

You are right. Either one of them should be sufficient.

> Will HPO be unmuted before "HP Power" is powered up on your system?

Yes.
I am no audio expert here - but from what I read from HDA, there's
actually no AMP unmute counterpart to AMP mute.

> Or should the event be associated with "LDO1"?  Which power will
> cause the click noise?

I found that the effect is most noticeable if the mute callback is
associated with "LDO2" and "HP Power".
But again, this is just what I observed.

>
>

[PATCH] soc/tegra: pmc: Don't allocate struct tegra_powergate on stack

[Viresh Kumar]

The size of the struct tegra_powergate is quite big and if any more
fields are added to the internal genpd structure, following warnings are
thrown:

drivers/soc/tegra/pmc.c:577:1: warning: the frame size of 1176 bytes is larger 
than 1024 bytes [-Wframe-larger-than=]

Avoid such warnings by allocating the structure dynamically.

Signed-off-by: Viresh Kumar 
---
 drivers/soc/tegra/pmc.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index e233dd5dcab3..c94196b939a4 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -557,22 +557,28 @@ EXPORT_SYMBOL(tegra_powergate_remove_clamping);
 int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
  struct reset_control *rst)
 {
-   struct tegra_powergate pg;
+   struct tegra_powergate *pg;
int err;
 
if (!tegra_powergate_is_available(id))
return -EINVAL;
 
-   pg.id = id;
-   pg.clks = 
-   pg.num_clks = 1;
-   pg.resets = 
-   pg.num_resets = 1;
+   pg = kzalloc(sizeof(*pg), GFP_KERNEL);
+   if (!pg)
+   return -ENOMEM;
+
+   pg->id = id;
+   pg->clks = 
+   pg->num_clks = 1;
+   pg->resets = 
+   pg->num_resets = 1;
 
-   err = tegra_powergate_power_up(, false);
+   err = tegra_powergate_power_up(pg, false);
if (err)
pr_err("failed to turn on partition %d: %d\n", id, err);
 
+   kfree(pg);
+
return err;
 }
 EXPORT_SYMBOL(tegra_powergate_sequence_power_up);
-- 
2.12.0.432.g71c3a4f4ba37

[PATCH] soc/tegra: pmc: Don't allocate struct tegra_powergate on stack

[Viresh Kumar]

The size of the struct tegra_powergate is quite big and if any more
fields are added to the internal genpd structure, following warnings are
thrown:

drivers/soc/tegra/pmc.c:577:1: warning: the frame size of 1176 bytes is larger 
than 1024 bytes [-Wframe-larger-than=]

Avoid such warnings by allocating the structure dynamically.

Signed-off-by: Viresh Kumar 
---
 drivers/soc/tegra/pmc.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index e233dd5dcab3..c94196b939a4 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -557,22 +557,28 @@ EXPORT_SYMBOL(tegra_powergate_remove_clamping);
 int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
  struct reset_control *rst)
 {
-   struct tegra_powergate pg;
+   struct tegra_powergate *pg;
int err;
 
if (!tegra_powergate_is_available(id))
return -EINVAL;
 
-   pg.id = id;
-   pg.clks = 
-   pg.num_clks = 1;
-   pg.resets = 
-   pg.num_resets = 1;
+   pg = kzalloc(sizeof(*pg), GFP_KERNEL);
+   if (!pg)
+   return -ENOMEM;
+
+   pg->id = id;
+   pg->clks = 
+   pg->num_clks = 1;
+   pg->resets = 
+   pg->num_resets = 1;
 
-   err = tegra_powergate_power_up(, false);
+   err = tegra_powergate_power_up(pg, false);
if (err)
pr_err("failed to turn on partition %d: %d\n", id, err);
 
+   kfree(pg);
+
return err;
 }
 EXPORT_SYMBOL(tegra_powergate_sequence_power_up);
-- 
2.12.0.432.g71c3a4f4ba37

Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

[Kai-Heng Feng]

On Tue, Mar 21, 2017 at 1:26 AM, Mark Brown  wrote:
> On Tue, Mar 21, 2017 at 12:23:53AM +0800, Kai-Heng Feng wrote:
>> On Tue, Mar 21, 2017 at 12:06 AM, Mark Brown  wrote:
>
>> > As it says there "...and inserted automatically following the three dash
>> > line".
>
>> I saw iteration changelog in git log all over the place, maybe add a
>> rule section for each subsystem?
>
> Some people won't push back, the only people who insist on anything
> different are the graphics people.

Got it. I think the way you suggested is better.

>
>> I had the same thought originally, but printk under each case suggests
>> otherwise - _POST_PMU is triggered not right after _PRE_PMU but right
>> before _PRE_PMD.
>
> Then you've broken something else on your system, that is obviously
> completely nonsensical and would break anything that relies on having a
> _POST_PMU event.  Why would we have two events that run at the same time
> one of which is obviously misnamed?

Hmm, that's weird though. I did the same test to rt286_spk_event()
(without applying the patch I sent), what I observed was the same:
_POST_PMU was triggered right after I stopped play sound, i.e. right
before _PRE_PMD not right after _PRE_PMU.

>
>> > > You didn't reply to my review comment and you sent the same code
>> > > again.
>> > That looks an awful lot like being ignored.
>
>> Fair enough, I thought changelog is sufficient.
>
> I'm not seeing anything in the changelog that addresses this.

Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

[Kai-Heng Feng]

On Tue, Mar 21, 2017 at 1:26 AM, Mark Brown  wrote:
> On Tue, Mar 21, 2017 at 12:23:53AM +0800, Kai-Heng Feng wrote:
>> On Tue, Mar 21, 2017 at 12:06 AM, Mark Brown  wrote:
>
>> > As it says there "...and inserted automatically following the three dash
>> > line".
>
>> I saw iteration changelog in git log all over the place, maybe add a
>> rule section for each subsystem?
>
> Some people won't push back, the only people who insist on anything
> different are the graphics people.

Got it. I think the way you suggested is better.

>
>> I had the same thought originally, but printk under each case suggests
>> otherwise - _POST_PMU is triggered not right after _PRE_PMU but right
>> before _PRE_PMD.
>
> Then you've broken something else on your system, that is obviously
> completely nonsensical and would break anything that relies on having a
> _POST_PMU event.  Why would we have two events that run at the same time
> one of which is obviously misnamed?

Hmm, that's weird though. I did the same test to rt286_spk_event()
(without applying the patch I sent), what I observed was the same:
_POST_PMU was triggered right after I stopped play sound, i.e. right
before _PRE_PMD not right after _PRE_PMU.

>
>> > > You didn't reply to my review comment and you sent the same code
>> > > again.
>> > That looks an awful lot like being ignored.
>
>> Fair enough, I thought changelog is sufficient.
>
> I'm not seeing anything in the changelog that addresses this.

Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

[Chanwoo Choi]

On 2017년 03월 21일 12:54, Chanwoo Choi wrote:
> On 2017년 03월 20일 22:00, Andy Shevchenko wrote:
>> On Mon, 2017-03-20 at 10:33 +0900, Chanwoo Choi wrote:
>>> On 2017년 03월 17일 18:55, Hans de Goede wrote:
>>
 +static const struct platform_device_id cht_wc_extcon_table[] = {
 +  { .name = "cht_wcove_pwrsrc" },
>>>
>>> You use the 'cht_wc' word instead of 'cht_wcove_pwrsrc'.
>>> So, To maintain the consistency, you better to use the 'cht-wc' as the
>>> name.
>>> - I prefer to use '-' instead of '_' in the name.
>>> .name ="cht-wc"
>>
>> I would keep as Hans did for the sake of consistency among all Whiskey
>> Cove device drivers (and predecessors like Crystal Cove).
> 
> The 'wcove' short word is not used in this patch.
> If the author want to use the 'wcove', I recommend that
> you should use the 'wcove' instead of 'wc' in this patch.
> 
> And, I think that  'pwrsrc' is not ambiguous.

I'm sorry. I used the wrong word. I mean that 'pwrsrc' is not correct.

> Hans might use the 'pwrsrc' as the 'Power Source'.
> But, this driver is not power source. Instead,
> this driver supports the detection of external connector.
> 
> I think 'power source' means the power supply instead of detector.
> 
>>
>> I understand your point from extcon subsystem view, but PMICs like
>> Whiskey Cove are multi-functional devices, and thus naming across them
>> (same prefix in use to be precise) is better idea.
>>
>>>
 +  {},
 +};
 +MODULE_DEVICE_TABLE(platform, cht_wc_extcon_table);
>>
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

[Chanwoo Choi]

On 2017년 03월 21일 12:54, Chanwoo Choi wrote:
> On 2017년 03월 20일 22:00, Andy Shevchenko wrote:
>> On Mon, 2017-03-20 at 10:33 +0900, Chanwoo Choi wrote:
>>> On 2017년 03월 17일 18:55, Hans de Goede wrote:
>>
 +static const struct platform_device_id cht_wc_extcon_table[] = {
 +  { .name = "cht_wcove_pwrsrc" },
>>>
>>> You use the 'cht_wc' word instead of 'cht_wcove_pwrsrc'.
>>> So, To maintain the consistency, you better to use the 'cht-wc' as the
>>> name.
>>> - I prefer to use '-' instead of '_' in the name.
>>> .name ="cht-wc"
>>
>> I would keep as Hans did for the sake of consistency among all Whiskey
>> Cove device drivers (and predecessors like Crystal Cove).
> 
> The 'wcove' short word is not used in this patch.
> If the author want to use the 'wcove', I recommend that
> you should use the 'wcove' instead of 'wc' in this patch.
> 
> And, I think that  'pwrsrc' is not ambiguous.

I'm sorry. I used the wrong word. I mean that 'pwrsrc' is not correct.

> Hans might use the 'pwrsrc' as the 'Power Source'.
> But, this driver is not power source. Instead,
> this driver supports the detection of external connector.
> 
> I think 'power source' means the power supply instead of detector.
> 
>>
>> I understand your point from extcon subsystem view, but PMICs like
>> Whiskey Cove are multi-functional devices, and thus naming across them
>> (same prefix in use to be precise) is better idea.
>>
>>>
 +  {},
 +};
 +MODULE_DEVICE_TABLE(platform, cht_wc_extcon_table);
>>
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v2] perf/probe: Change MAX_CMDLEN

[Masami Hiramatsu]

On Tue,  7 Feb 2017 11:15:47 +0530
Ravi Bangoria  wrote:

> There are many SDT markers in powerpc whose uprobe definition goes
> beyond current MAX_CMDLEN, especially when target filename is long
> and sdt marker has long list of arguments. For example, definition
> of sdt marker
> 
>   method__compile__end: 8@17 8@9 8@10 -4@8 8@7 -4@6 8@5 -4@4 1@37(28)
> 
> from file
> 
>   /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-2.b14.fc22.ppc64/jre/lib/\
>  ppc64/server/libjvm.so
> 
> is
> 
>   p:sdt_hotspot/method__compile__end /usr/lib/jvm/java-1.8.0-openjdk-\
> 1.8.0.91-2.b14.fc22.ppc64/jre/lib/ppc64/server/libjvm.so:0x4c4e00\
> arg1=%gpr17:u64 arg2=%gpr9:u64 arg3=%gpr10:u64 arg4=%gpr8:s32\
> arg5=%gpr7:u64 arg6=%gpr6:s32 arg7=%gpr5:u64 arg8=%gpr4:s32\
> arg9=+37(%gpr28):u8
> 
> Perf probe fails with seg fault for such markers. As uprobe_events file
> accepts definition upto 4094 characters(4096 - 2 (\n\0)), increase value
> of MAX_CMDLEN to 4094.

This looks good to me.

Acked-by: Masami Hiramatsu 

Thanks,

> 
> Signed-off-by: Ravi Bangoria 
> ---
> Changes in v2:
>   - Set MAX_CMDLEN to 4094 instead of 512
> 
>  tools/perf/util/probe-event.c | 1 -
>  tools/perf/util/probe-file.c  | 3 ++-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 6a6f44d..e6e3244 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -47,7 +47,6 @@
>  #include "probe-file.h"
>  #include "session.h"
>  
> -#define MAX_CMDLEN 256
>  #define PERFPROBE_GROUP "probe"
>  
>  bool probe_event_dry_run;/* Dry run flag */
> diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
> index 38eca3c..fdabe7e 100644
> --- a/tools/perf/util/probe-file.c
> +++ b/tools/perf/util/probe-file.c
> @@ -29,7 +29,8 @@
>  #include "session.h"
>  #include "perf_regs.h"
>  
> -#define MAX_CMDLEN 256
> +/* 4096 - 2 ('\n' + '\0') */
> +#define MAX_CMDLEN 4094
>  
>  static void print_open_warning(int err, bool uprobe)
>  {
> -- 
> 2.9.3
> 


-- 
Masami Hiramatsu 

Re: [PATCH v2] perf/probe: Change MAX_CMDLEN

[Masami Hiramatsu]

On Tue,  7 Feb 2017 11:15:47 +0530
Ravi Bangoria  wrote:

> There are many SDT markers in powerpc whose uprobe definition goes
> beyond current MAX_CMDLEN, especially when target filename is long
> and sdt marker has long list of arguments. For example, definition
> of sdt marker
> 
>   method__compile__end: 8@17 8@9 8@10 -4@8 8@7 -4@6 8@5 -4@4 1@37(28)
> 
> from file
> 
>   /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-2.b14.fc22.ppc64/jre/lib/\
>  ppc64/server/libjvm.so
> 
> is
> 
>   p:sdt_hotspot/method__compile__end /usr/lib/jvm/java-1.8.0-openjdk-\
> 1.8.0.91-2.b14.fc22.ppc64/jre/lib/ppc64/server/libjvm.so:0x4c4e00\
> arg1=%gpr17:u64 arg2=%gpr9:u64 arg3=%gpr10:u64 arg4=%gpr8:s32\
> arg5=%gpr7:u64 arg6=%gpr6:s32 arg7=%gpr5:u64 arg8=%gpr4:s32\
> arg9=+37(%gpr28):u8
> 
> Perf probe fails with seg fault for such markers. As uprobe_events file
> accepts definition upto 4094 characters(4096 - 2 (\n\0)), increase value
> of MAX_CMDLEN to 4094.

This looks good to me.

Acked-by: Masami Hiramatsu 

Thanks,

> 
> Signed-off-by: Ravi Bangoria 
> ---
> Changes in v2:
>   - Set MAX_CMDLEN to 4094 instead of 512
> 
>  tools/perf/util/probe-event.c | 1 -
>  tools/perf/util/probe-file.c  | 3 ++-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 6a6f44d..e6e3244 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -47,7 +47,6 @@
>  #include "probe-file.h"
>  #include "session.h"
>  
> -#define MAX_CMDLEN 256
>  #define PERFPROBE_GROUP "probe"
>  
>  bool probe_event_dry_run;/* Dry run flag */
> diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
> index 38eca3c..fdabe7e 100644
> --- a/tools/perf/util/probe-file.c
> +++ b/tools/perf/util/probe-file.c
> @@ -29,7 +29,8 @@
>  #include "session.h"
>  #include "perf_regs.h"
>  
> -#define MAX_CMDLEN 256
> +/* 4096 - 2 ('\n' + '\0') */
> +#define MAX_CMDLEN 4094
>  
>  static void print_open_warning(int err, bool uprobe)
>  {
> -- 
> 2.9.3
> 


-- 
Masami Hiramatsu 

Re: [PATCH] vfio pci: kernel support of error recovery only for non fatal error

[Alex Williamson]

On Mon, 20 Mar 2017 16:32:33 +0200
"Michael S. Tsirkin"  wrote:

> On Mon, Mar 20, 2017 at 08:50:39PM +0800, Cao jin wrote:
> > Sorry for late.
> > 
> > On 03/14/2017 06:06 AM, Alex Williamson wrote:  
> > > On Mon, 27 Feb 2017 15:28:43 +0800
> > > Cao jin  wrote:
> > >   
> > >> 0. What happens now (PCIE AER only)
> > >>Fatal errors cause a link reset.
> > >>Non fatal errors don't.
> > >>All errors stop the VM eventually, but not immediately
> > >>because it's detected and reported asynchronously.
> > >>Interrupts are forwarded as usual.
> > >>Correctable errors are not reported to guest at all.
> > >>Note: PPC EEH is different. This focuses on AER.  
> > > 
> > > Perhaps you're only focusing on AER, but don't the error handlers we're
> > > using support both AER and EEH generically?  I don't think we can
> > > completely disregard how this affects EEH behavior, if at all.
> > >   
> > 
> > After taking a rough look at the EEH,  find that EEH always feed
> > error_detected with pci_channel_io_frozen, from perspective of
> > error_detected, EEH is not affected.  
> > 
> > I am not sure about a question: when assign devices in spapr host,
> > should all functions/devices in a PE be bound to vfio? I am kind of
> > confused about the relationship between a PE & a tce iommu group
> >   
> > >>
> > >> 1. Correctable errors
> > >>There is no need to report these to guest. So let's not.  
> > > 
> > > What does this patch change to make this happen?  I don't see
> > > anything.  Was this always the case?  No change?
> > >   
> > 
> > yes, no change on correctable error.
> >   
> > >>
> > >> 2. Fatal errors
> > >>It's not easy to handle them gracefully since link reset
> > >>is needed. As a first step, let's use the existing mechanism
> > >>in that case.  
> > > 
> > > Ok, so no change here either.
> > >   
> > >> 2. Non-fatal errors
> > >>Here we could make progress by reporting them to guest
> > >>and have guest handle them.  
> > > 
> > > In practice, what actual errors do we expect userspace to see as
> > > non-fatal errors? It would be useful for the commit log to describe
> > > the actual benefit we're going to see by splitting out non-fatal errors
> > > for the user (not always a guest) to see separately.  Justify that this
> > > is actually useful.
> > >   
> > >>
> > >>Issues:
> > >>a. this behaviour should only be enabled with new userspace,
> > >>   old userspace should work without changes.
> > >>
> > >>   Suggestion: One way to address this would be to add a new eventfd
> > >>   non_fatal_err_trigger. If not set, invoke err_trigger.  
> > > 
> > > This outline format was really more useful for Michael to try to
> > > generate discussion, for a commit log, I'd much rather see a definitive
> > > statement such as:
> > > 
> > >  "To maintain backwards compatibility with userspace, non-fatal errors
> > >  will continue to trigger via the existing error interrupt index if a
> > >  non-fatal signaling mechanism has not been registered."
> > >   
> > >>b. drivers are supposed to stop MMIO when error is reported,
> > >>   if vm keeps going, we will keep doing MMIO/config.
> > >>
> > >>   Suggestion 1: ignore this. vm stop happens much later when
> > >>   userspace runs anyway, so we are not making things much worse.
> > >>
> > >>   Suggestion 2: try to stop MMIO/config, resume on resume call
> > >>
> > >>   Patch below implements Suggestion 1.
> > >>
> > >>   Note that although this is really against the documentation, which
> > >>   states error_detected() is the point at which the driver should 
> > >> quiesce
> > >>   the device and not touch it further (until diagnostic poking at
> > >>   mmio_enabled or full access at resume callback).
> > >>
> > >>   Fixing this won't be easy. However, this is not a regression.
> > >>
> > >>   Also note this does nothing about interrupts, documentation
> > >>   suggests returning IRQ_NONE until reset.
> > >>   Again, not a regression.  
> > > 
> > > So again, no change here.  I'm not sure what this adds to the commit
> > > log, perhaps we can reference this as a link to Michael's original
> > > proposal.
> > >
> > >>c. PF driver might detect that function is completely broken,
> > >>   if vm keeps going, we will keep doing MMIO/config.
> > >>
> > >>   Suggestion 1: ignore this. vm stop happens much later when
> > >>   userspace runs anyway, so we are not making things much worse.
> > >>
> > >>   Suggestion 2: detect this and invoke err_trigger to stop VM.
> > >>
> > >>   Patch below implements Suggestion 2.  
> > > 
> > > This needs more description and seems a bit misleading.  This patch
> > > adds a slot_reset handler, such that if the slot is reset, we notify
> > > the user, essentially promoting the non-fatal error to fatal.  But what
> > > condition gets us to this 

Re: [PATCH] vfio pci: kernel support of error recovery only for non fatal error

[Alex Williamson]

On Mon, 20 Mar 2017 16:32:33 +0200
"Michael S. Tsirkin"  wrote:

> On Mon, Mar 20, 2017 at 08:50:39PM +0800, Cao jin wrote:
> > Sorry for late.
> > 
> > On 03/14/2017 06:06 AM, Alex Williamson wrote:  
> > > On Mon, 27 Feb 2017 15:28:43 +0800
> > > Cao jin  wrote:
> > >   
> > >> 0. What happens now (PCIE AER only)
> > >>Fatal errors cause a link reset.
> > >>Non fatal errors don't.
> > >>All errors stop the VM eventually, but not immediately
> > >>because it's detected and reported asynchronously.
> > >>Interrupts are forwarded as usual.
> > >>Correctable errors are not reported to guest at all.
> > >>Note: PPC EEH is different. This focuses on AER.  
> > > 
> > > Perhaps you're only focusing on AER, but don't the error handlers we're
> > > using support both AER and EEH generically?  I don't think we can
> > > completely disregard how this affects EEH behavior, if at all.
> > >   
> > 
> > After taking a rough look at the EEH,  find that EEH always feed
> > error_detected with pci_channel_io_frozen, from perspective of
> > error_detected, EEH is not affected.  
> > 
> > I am not sure about a question: when assign devices in spapr host,
> > should all functions/devices in a PE be bound to vfio? I am kind of
> > confused about the relationship between a PE & a tce iommu group
> >   
> > >>
> > >> 1. Correctable errors
> > >>There is no need to report these to guest. So let's not.  
> > > 
> > > What does this patch change to make this happen?  I don't see
> > > anything.  Was this always the case?  No change?
> > >   
> > 
> > yes, no change on correctable error.
> >   
> > >>
> > >> 2. Fatal errors
> > >>It's not easy to handle them gracefully since link reset
> > >>is needed. As a first step, let's use the existing mechanism
> > >>in that case.  
> > > 
> > > Ok, so no change here either.
> > >   
> > >> 2. Non-fatal errors
> > >>Here we could make progress by reporting them to guest
> > >>and have guest handle them.  
> > > 
> > > In practice, what actual errors do we expect userspace to see as
> > > non-fatal errors? It would be useful for the commit log to describe
> > > the actual benefit we're going to see by splitting out non-fatal errors
> > > for the user (not always a guest) to see separately.  Justify that this
> > > is actually useful.
> > >   
> > >>
> > >>Issues:
> > >>a. this behaviour should only be enabled with new userspace,
> > >>   old userspace should work without changes.
> > >>
> > >>   Suggestion: One way to address this would be to add a new eventfd
> > >>   non_fatal_err_trigger. If not set, invoke err_trigger.  
> > > 
> > > This outline format was really more useful for Michael to try to
> > > generate discussion, for a commit log, I'd much rather see a definitive
> > > statement such as:
> > > 
> > >  "To maintain backwards compatibility with userspace, non-fatal errors
> > >  will continue to trigger via the existing error interrupt index if a
> > >  non-fatal signaling mechanism has not been registered."
> > >   
> > >>b. drivers are supposed to stop MMIO when error is reported,
> > >>   if vm keeps going, we will keep doing MMIO/config.
> > >>
> > >>   Suggestion 1: ignore this. vm stop happens much later when
> > >>   userspace runs anyway, so we are not making things much worse.
> > >>
> > >>   Suggestion 2: try to stop MMIO/config, resume on resume call
> > >>
> > >>   Patch below implements Suggestion 1.
> > >>
> > >>   Note that although this is really against the documentation, which
> > >>   states error_detected() is the point at which the driver should 
> > >> quiesce
> > >>   the device and not touch it further (until diagnostic poking at
> > >>   mmio_enabled or full access at resume callback).
> > >>
> > >>   Fixing this won't be easy. However, this is not a regression.
> > >>
> > >>   Also note this does nothing about interrupts, documentation
> > >>   suggests returning IRQ_NONE until reset.
> > >>   Again, not a regression.  
> > > 
> > > So again, no change here.  I'm not sure what this adds to the commit
> > > log, perhaps we can reference this as a link to Michael's original
> > > proposal.
> > >
> > >>c. PF driver might detect that function is completely broken,
> > >>   if vm keeps going, we will keep doing MMIO/config.
> > >>
> > >>   Suggestion 1: ignore this. vm stop happens much later when
> > >>   userspace runs anyway, so we are not making things much worse.
> > >>
> > >>   Suggestion 2: detect this and invoke err_trigger to stop VM.
> > >>
> > >>   Patch below implements Suggestion 2.  
> > > 
> > > This needs more description and seems a bit misleading.  This patch
> > > adds a slot_reset handler, such that if the slot is reset, we notify
> > > the user, essentially promoting the non-fatal error to fatal.  But what
> > > condition gets us to this point?  AIUI, AER is a voting scheme and if
> 

Re: [PATCH tip:x86/mm] x86/tls: Forcibly set the accessed bit in TLS segments

[Andy Lutomirski]

On Sat, Mar 18, 2017 at 10:17 PM, Andy Lutomirski  wrote:
> For mysterious historical reasons, struct user_desc doesn't indicate
> whether segments are accessed.  set_thread_area() has always
> programmed segments as non-accessed, so the first write will set the
> accessed bit.  This will fault if the GDT is read-only.
>
> Fix it by making TLS segments start out accessed.
>
> If this ends up breaking something, we could, in principle, leave
> TLS segments non-accessed and fix them up when we get the page
> fault.  I'd be surprised, though -- AFAIK all the nasty legacy
> segmented programs (DOSEMU, Wine, things that run on DOSEMU and
> Wine, etc.) do their nasty segmented things using the LDT and not
> the GDT.  I assume this is mainly because old OSes (Linux and
> otherwise) didn't historically provide APIs to do nasty things in
> the GDT.
>
> Fixes: 45fc8757d1d2 ("x86: Make the GDT remapping read-only on 64-bit")
> Signed-off-by: Andy Lutomirski 

FWIW, I'm now extra convinced that this won't break anything: the
accessed bit didn't work properly before this patch.  When we
scheduled a task in, we'd copy the TLS segment descriptors to the GDT,
but we never copied them back out when we scheduled out, so the
accessed bit would randomly clear itself.  Whoops :)

So arguably this patch would be a bugfix even without Thomas' changes.

Re: [PATCH tip:x86/mm] x86/tls: Forcibly set the accessed bit in TLS segments

[Andy Lutomirski]

On Sat, Mar 18, 2017 at 10:17 PM, Andy Lutomirski  wrote:
> For mysterious historical reasons, struct user_desc doesn't indicate
> whether segments are accessed.  set_thread_area() has always
> programmed segments as non-accessed, so the first write will set the
> accessed bit.  This will fault if the GDT is read-only.
>
> Fix it by making TLS segments start out accessed.
>
> If this ends up breaking something, we could, in principle, leave
> TLS segments non-accessed and fix them up when we get the page
> fault.  I'd be surprised, though -- AFAIK all the nasty legacy
> segmented programs (DOSEMU, Wine, things that run on DOSEMU and
> Wine, etc.) do their nasty segmented things using the LDT and not
> the GDT.  I assume this is mainly because old OSes (Linux and
> otherwise) didn't historically provide APIs to do nasty things in
> the GDT.
>
> Fixes: 45fc8757d1d2 ("x86: Make the GDT remapping read-only on 64-bit")
> Signed-off-by: Andy Lutomirski 

FWIW, I'm now extra convinced that this won't break anything: the
accessed bit didn't work properly before this patch.  When we
scheduled a task in, we'd copy the TLS segment descriptors to the GDT,
but we never copied them back out when we scheduled out, so the
accessed bit would randomly clear itself.  Whoops :)

So arguably this patch would be a bugfix even without Thomas' changes.

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Andrei Vagin]

Here is my bisect log:
[avagin@laptop linux-next]$ git bisect log
# bad: [f921b263d9602fb7873710c2df70671f2ffcf658] Add linux-next
specific files for 20170320
# good: [4495c08e84729385774601b5146d51d9e5849f81] Linux 4.11-rc2
git bisect start 'HEAD' 'v4.11-rc2'
# good: [adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac] Merge
remote-tracking branch 'drm/drm-next'
git bisect good adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac
# bad: [e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2] Merge
remote-tracking branch 'tty/tty-next'
git bisect bad e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2
# good: [81cde6aecf21113c6bc65bc944587db4cbd3f64d] Merge
remote-tracking branch 'mmc/next'
git bisect good 81cde6aecf21113c6bc65bc944587db4cbd3f64d
# bad: [69d76288005784205678520826a74c28e49a1703] Merge
remote-tracking branch 'tip/auto-latest'
git bisect bad 69d76288005784205678520826a74c28e49a1703
# good: [6d32edf2be6c4e0f08b102e2d3227278ebb477c9] Merge
remote-tracking branch 'spi/for-next'
git bisect good 6d32edf2be6c4e0f08b102e2d3227278ebb477c9
# good: [61f63e383784bd0ab6529cfc95ddc59c713afcc9] Merge tag
'perf-core-for-mingo-4.12-20170316' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
perf/core
git bisect good 61f63e383784bd0ab6529cfc95ddc59c713afcc9
# good: [3069c5a046ec92dc552194686c95e27c8c9e919d] Merge branch 'x86/asm'
git bisect good 3069c5a046ec92dc552194686c95e27c8c9e919d
# bad: [5b804ec2fd3272385ba7530c3a67d7402fb6d8a0] Merge branch 'x86/mm'
git bisect bad 5b804ec2fd3272385ba7530c3a67d7402fb6d8a0
# good: [06c830a48346643e195801460dfe16d96ba4dff5] x86/power: Add
5-level paging support
git bisect good 06c830a48346643e195801460dfe16d96ba4dff5
# good: [2bbbd194fdca01f694e2ca3fb447a1acf9d19f76] Merge branch 'x86/cpu'
git bisect good 2bbbd194fdca01f694e2ca3fb447a1acf9d19f76
# good: [69218e47994da614e7af600bf06887750ab6657a] x86: Remap GDT
tables in the fixmap section
git bisect good 69218e47994da614e7af600bf06887750ab6657a
# bad: [74c8ce958dbf0b64f198becb5d8aa93afb967438] Merge branch 'linus'
into x86/mm, to pick up a bugfix
git bisect bad 74c8ce958dbf0b64f198becb5d8aa93afb967438
# bad: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86: Make the GDT
remapping read-only on 64-bit
git bisect bad 45fc8757d1d2128e342b4e7ef39adedf7752faac
# first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
Make the GDT remapping read-only on 64-bit

On Mon, Mar 20, 2017 at 4:57 PM, Andrei Vagin <ava...@gmail.com> wrote:
> Hello,
>
> We run CRIU tests on linux-next. And today we found that when we start
> x32 processes, a kernel bug is triggered:
>
> [root@fc24 ~]# uname -a
> Linux fc24 4.11.0-rc2-next-20170320 #159 SMP Mon Mar 20 16:53:58 PDT
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> [root@fc24 ~]# cat t.c
> int main()
> {
> return 0;
> }
> [root@fc24 ~]# gcc -m32 t.c
> [root@fc24 ~]# ./a.out
> Killed
> [root@fc24 ~]# dmesg
> [   90.033310] BUG: unable to handle kernel paging request at ff576060
> [   90.034008] IP: 0xf76fa9f4
> [   90.034008] PGD 13de1e067
> [   90.034008] P4D 13de1e067
> [   90.034008] PUD 13de20067
> [   90.034008] PMD 13de21067
> [   90.034008] PTE 80013fd09161
>
> [   90.034008] Oops: 0003 [#1] SMP
> [   90.034008] Modules linked in:
> [   90.034008] CPU: 1 PID: 475 Comm: a.out Not tainted
> 4.11.0-rc2-next-20170320 #159
> [   90.034008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.9.3-1.fc25 04/01/2014
> [   90.034008] task: 9d11efdca700 task.stack: b0ccc0d4c000
> [   90.034008] RIP: 0023:0xf76fa9f4
> [   90.034008] RSP: 002b:ffafc860 EFLAGS: 00010246
> [   90.034008] RAX: 0063 RBX: ffafc860 RCX: 
> 08aea440
> [   90.034008] RDX: f7515700 RSI: f771dfcc RDI: 
> 0040
> [   90.034008] RBP: ffafc928 R08:  R09: 
> 
> [   90.034008] R10:  R11:  R12: 
> 
> [   90.034008] R13:  R14:  R15: 
> 
> [   90.034008] FS:  () GS:9d11ffd0()
> knlGS:
> [   90.034008] CS:  0010 DS: 002b ES: 002b CR0: 80050033
> [   90.034008] CR2: ff576060 CR3: 00012fd8d000 CR4: 
> 003406e0
> [   90.034008] RIP: 0xf76fa9f4 RSP: ffafc860
> [   90.034008] CR2: ff576060
> [   90.034008] ---[ end trace 3c9a8bbd0d11f377 ]---
> [   90.034008] BUG: sleeping function called from invalid context at
> ./include/linux/percpu-rwsem.h:33
> [   90.034008] in_atomic(): 0, irqs_disabled(): 1, pid: 475, name: a.out
> [   90.034008] INFO: lockdep is turned off.
> [   90.034008] irq event stamp: 2014
> [   90.034008] hardirqs last  enabled at (2013): []
> entry_INT80_compat+0x3d/0x50
> [   90.034008] hardirqs last disabled at (2014): []
> error_entry+0x6c/0xd0

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

[Andrei Vagin]

Here is my bisect log:
[avagin@laptop linux-next]$ git bisect log
# bad: [f921b263d9602fb7873710c2df70671f2ffcf658] Add linux-next
specific files for 20170320
# good: [4495c08e84729385774601b5146d51d9e5849f81] Linux 4.11-rc2
git bisect start 'HEAD' 'v4.11-rc2'
# good: [adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac] Merge
remote-tracking branch 'drm/drm-next'
git bisect good adeec71e7b8a11ff44103cfa4e1c6002c27ae9ac
# bad: [e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2] Merge
remote-tracking branch 'tty/tty-next'
git bisect bad e5b1cee1bb9d8a66b28d64db9d8250ae2b0803d2
# good: [81cde6aecf21113c6bc65bc944587db4cbd3f64d] Merge
remote-tracking branch 'mmc/next'
git bisect good 81cde6aecf21113c6bc65bc944587db4cbd3f64d
# bad: [69d76288005784205678520826a74c28e49a1703] Merge
remote-tracking branch 'tip/auto-latest'
git bisect bad 69d76288005784205678520826a74c28e49a1703
# good: [6d32edf2be6c4e0f08b102e2d3227278ebb477c9] Merge
remote-tracking branch 'spi/for-next'
git bisect good 6d32edf2be6c4e0f08b102e2d3227278ebb477c9
# good: [61f63e383784bd0ab6529cfc95ddc59c713afcc9] Merge tag
'perf-core-for-mingo-4.12-20170316' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
perf/core
git bisect good 61f63e383784bd0ab6529cfc95ddc59c713afcc9
# good: [3069c5a046ec92dc552194686c95e27c8c9e919d] Merge branch 'x86/asm'
git bisect good 3069c5a046ec92dc552194686c95e27c8c9e919d
# bad: [5b804ec2fd3272385ba7530c3a67d7402fb6d8a0] Merge branch 'x86/mm'
git bisect bad 5b804ec2fd3272385ba7530c3a67d7402fb6d8a0
# good: [06c830a48346643e195801460dfe16d96ba4dff5] x86/power: Add
5-level paging support
git bisect good 06c830a48346643e195801460dfe16d96ba4dff5
# good: [2bbbd194fdca01f694e2ca3fb447a1acf9d19f76] Merge branch 'x86/cpu'
git bisect good 2bbbd194fdca01f694e2ca3fb447a1acf9d19f76
# good: [69218e47994da614e7af600bf06887750ab6657a] x86: Remap GDT
tables in the fixmap section
git bisect good 69218e47994da614e7af600bf06887750ab6657a
# bad: [74c8ce958dbf0b64f198becb5d8aa93afb967438] Merge branch 'linus'
into x86/mm, to pick up a bugfix
git bisect bad 74c8ce958dbf0b64f198becb5d8aa93afb967438
# bad: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86: Make the GDT
remapping read-only on 64-bit
git bisect bad 45fc8757d1d2128e342b4e7ef39adedf7752faac
# first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
Make the GDT remapping read-only on 64-bit

On Mon, Mar 20, 2017 at 4:57 PM, Andrei Vagin  wrote:
> Hello,
>
> We run CRIU tests on linux-next. And today we found that when we start
> x32 processes, a kernel bug is triggered:
>
> [root@fc24 ~]# uname -a
> Linux fc24 4.11.0-rc2-next-20170320 #159 SMP Mon Mar 20 16:53:58 PDT
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> [root@fc24 ~]# cat t.c
> int main()
> {
> return 0;
> }
> [root@fc24 ~]# gcc -m32 t.c
> [root@fc24 ~]# ./a.out
> Killed
> [root@fc24 ~]# dmesg
> [   90.033310] BUG: unable to handle kernel paging request at ff576060
> [   90.034008] IP: 0xf76fa9f4
> [   90.034008] PGD 13de1e067
> [   90.034008] P4D 13de1e067
> [   90.034008] PUD 13de20067
> [   90.034008] PMD 13de21067
> [   90.034008] PTE 80013fd09161
>
> [   90.034008] Oops: 0003 [#1] SMP
> [   90.034008] Modules linked in:
> [   90.034008] CPU: 1 PID: 475 Comm: a.out Not tainted
> 4.11.0-rc2-next-20170320 #159
> [   90.034008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.9.3-1.fc25 04/01/2014
> [   90.034008] task: 9d11efdca700 task.stack: b0ccc0d4c000
> [   90.034008] RIP: 0023:0xf76fa9f4
> [   90.034008] RSP: 002b:ffafc860 EFLAGS: 00010246
> [   90.034008] RAX: 0063 RBX: ffafc860 RCX: 
> 08aea440
> [   90.034008] RDX: f7515700 RSI: f771dfcc RDI: 
> 0040
> [   90.034008] RBP: ffafc928 R08:  R09: 
> 
> [   90.034008] R10:  R11:  R12: 
> 
> [   90.034008] R13:  R14:  R15: 
> 
> [   90.034008] FS:  () GS:9d11ffd0()
> knlGS:
> [   90.034008] CS:  0010 DS: 002b ES: 002b CR0: 80050033
> [   90.034008] CR2: ff576060 CR3: 00012fd8d000 CR4: 
> 003406e0
> [   90.034008] RIP: 0xf76fa9f4 RSP: ffafc860
> [   90.034008] CR2: ff576060
> [   90.034008] ---[ end trace 3c9a8bbd0d11f377 ]---
> [   90.034008] BUG: sleeping function called from invalid context at
> ./include/linux/percpu-rwsem.h:33
> [   90.034008] in_atomic(): 0, irqs_disabled(): 1, pid: 475, name: a.out
> [   90.034008] INFO: lockdep is turned off.
> [   90.034008] irq event stamp: 2014
> [   90.034008] hardirqs last  enabled at (2013): []
> entry_INT80_compat+0x3d/0x50
> [   90.034008] hardirqs last disabled at (2014): []
> error_entry+0x6c/0xd0
> [   90.034008

Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

[Chanwoo Choi]

Hi,

On 2017년 03월 21일 04:57, Hans de Goede wrote:
> Hi,
> 
> On 20-03-17 02:33, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2017년 03월 17일 18:55, Hans de Goede wrote:
>>> Add a driver for charger detection / control on the Intel Cherrytrail
>>> Whiskey Cove PMIC.
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  drivers/extcon/Kconfig |   7 +
>>>  drivers/extcon/Makefile|   1 +
>>>  drivers/extcon/extcon-cht-wc.c | 356 
>>> +
>>>  3 files changed, 364 insertions(+)
>>>  create mode 100644 drivers/extcon/extcon-cht-wc.c
>>>
>>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
>>> index 96bbae5..4cace6b 100644
>>> --- a/drivers/extcon/Kconfig
>>> +++ b/drivers/extcon/Kconfig
>>> @@ -52,6 +52,13 @@ config EXTCON_INTEL_INT3496
>>>This ACPI device is typically found on Intel Baytrail or Cherrytrail
>>>based tablets, or other Baytrail / Cherrytrail devices.
>>>
>>> +config EXTCON_CHT_WC
>>
>> Need to reorder it alpabetically as the following Makefile.
> 
> The idea is to have the items alphabetically listed in "make menuconfig"
> and the name of the menu item starts with Intel:

If you want to locate it under the EXTCON_INTEL_INT3496,
you should change the filename as following style:
- extcon-intel-cht-wc.c

I want to locate all entry alphabetically. 

> 
>>
>>> +tristate "Intel Cherrytrail Whiskey Cove PMIC extcon driver"
>>> +depends on INTEL_SOC_PMIC_CHTWC
>>> +help
>>> +  Say Y here to enable extcon support for charger detection / control
>>> +  on the Intel Cherrytrail Whiskey Cove PMIC.
>>> +
>>>  config EXTCON_MAX14577
>>>  tristate "Maxim MAX14577/77836 EXTCON Support"
>>>  depends on MFD_MAX14577
>>> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
>>> index 237ac3f..160f88b 100644
>>> --- a/drivers/extcon/Makefile
>>> +++ b/drivers/extcon/Makefile
>>> @@ -7,6 +7,7 @@ extcon-core-objs+= extcon.o devres.o
>>>  obj-$(CONFIG_EXTCON_ADC_JACK)+= extcon-adc-jack.o
>>>  obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-arizona.o
>>>  obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
>>> +obj-$(CONFIG_EXTCON_CHT_WC)+= extcon-cht-wc.o
>>>  obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
>>>  obj-$(CONFIG_EXTCON_INTEL_INT3496) += extcon-intel-int3496.o
>>>  obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o
>>> diff --git a/drivers/extcon/extcon-cht-wc.c b/drivers/extcon/extcon-cht-wc.c
>>> new file mode 100644
>>> index 000..896eee6
>>> --- /dev/null
>>> +++ b/drivers/extcon/extcon-cht-wc.c
>>> @@ -0,0 +1,356 @@
>>> +/*
>>> + * Extcon charger detection driver for Intel Cherrytrail Whiskey Cove PMIC
>>> + * Copyright (C) 2017 Hans de Goede 
>>> + *
>>> + * Based on various non upstream patches to support the CHT Whiskey Cove 
>>> PMIC:
>>
>> Maybe, you don't need to add ':' at the end of line.
> 
> Th ':' is there because the following copyright line:
>>
>>> + * Copyright (C) 2013-2015 Intel Corporation. All rights reserved.
> 
> Comes from those various non upstream patches.
> 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms and conditions of the GNU General Public License,
>>> + * version 2, as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope it will be useful, but WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
>>> for
>>> + * more details.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define CHT_WC_PWRSRC_IRQ0x6e03
>>> +#define CHT_WC_PWRSRC_IRQ_MASK0x6e0f
>>> +#define CHT_WC_PWRSRC_STS0x6e1e
>>> +#define CHT_WC_PWRSRC_VBUSBIT(0)
>>> +#define CHT_WC_PWRSRC_DCBIT(1)
>>> +#define CHT_WC_PWRSRC_BATBIT(2)
>>> +#define CHT_WC_PWRSRC_ID_GNDBIT(3)
>>> +#define CHT_WC_PWRSRC_ID_FLOATBIT(4)
>>> +
>>> +#define CHT_WC_PHYCTRL0x5e07
>>> +
>>> +#define CHT_WC_CHGRCTRL00x5e16
>>> +
>>> +#define CHT_WC_CHGRCTRL00x5e16
>>> +#define CHT_WC_CHGRCTRL0_CHGRRESETBIT(0)
>>> +#define CHT_WC_CHGRCTRL0_EMRGCHRENBIT(1)
>>> +#define CHT_WC_CHGRCTRL0_EXTCHRDISBIT(2)
>>> +#define CHT_WC_CHGRCTRL0_SWCONTROLBIT(3)
>>> +#define CHT_WC_CHGRCTRL0_TTLCK_MASKBIT(4)
>>> +#define CHT_WC_CHGRCTRL0_CCSM_OFF_MASKBIT(5)
>>> +#define CHT_WC_CHGRCTRL0_DBPOFF_MASKBIT(6)
>>> +#define CHT_WC_CHGRCTRL0_WDT_NOKICKBIT(7)
>>> +
>>> +#define CHT_WC_CHGRCTRL10x5e17
>>> +
>>> +#define CHT_WC_USBSRC0x5e29
>>> +#define CHT_WC_USBSRC_STS_MASKGENMASK(1, 0)
>>> +#define CHT_WC_USBSRC_STS_SUCCESS2
>>> +#define CHT_WC_USBSRC_STS_FAIL3
>>> +#define CHT_WC_USBSRC_TYPE_SHIFT2
>>> +#define 

Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

[Chanwoo Choi]

Hi,

On 2017년 03월 21일 04:57, Hans de Goede wrote:
> Hi,
> 
> On 20-03-17 02:33, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2017년 03월 17일 18:55, Hans de Goede wrote:
>>> Add a driver for charger detection / control on the Intel Cherrytrail
>>> Whiskey Cove PMIC.
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  drivers/extcon/Kconfig |   7 +
>>>  drivers/extcon/Makefile|   1 +
>>>  drivers/extcon/extcon-cht-wc.c | 356 
>>> +
>>>  3 files changed, 364 insertions(+)
>>>  create mode 100644 drivers/extcon/extcon-cht-wc.c
>>>
>>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
>>> index 96bbae5..4cace6b 100644
>>> --- a/drivers/extcon/Kconfig
>>> +++ b/drivers/extcon/Kconfig
>>> @@ -52,6 +52,13 @@ config EXTCON_INTEL_INT3496
>>>This ACPI device is typically found on Intel Baytrail or Cherrytrail
>>>based tablets, or other Baytrail / Cherrytrail devices.
>>>
>>> +config EXTCON_CHT_WC
>>
>> Need to reorder it alpabetically as the following Makefile.
> 
> The idea is to have the items alphabetically listed in "make menuconfig"
> and the name of the menu item starts with Intel:

If you want to locate it under the EXTCON_INTEL_INT3496,
you should change the filename as following style:
- extcon-intel-cht-wc.c

I want to locate all entry alphabetically. 

> 
>>
>>> +tristate "Intel Cherrytrail Whiskey Cove PMIC extcon driver"
>>> +depends on INTEL_SOC_PMIC_CHTWC
>>> +help
>>> +  Say Y here to enable extcon support for charger detection / control
>>> +  on the Intel Cherrytrail Whiskey Cove PMIC.
>>> +
>>>  config EXTCON_MAX14577
>>>  tristate "Maxim MAX14577/77836 EXTCON Support"
>>>  depends on MFD_MAX14577
>>> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
>>> index 237ac3f..160f88b 100644
>>> --- a/drivers/extcon/Makefile
>>> +++ b/drivers/extcon/Makefile
>>> @@ -7,6 +7,7 @@ extcon-core-objs+= extcon.o devres.o
>>>  obj-$(CONFIG_EXTCON_ADC_JACK)+= extcon-adc-jack.o
>>>  obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-arizona.o
>>>  obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
>>> +obj-$(CONFIG_EXTCON_CHT_WC)+= extcon-cht-wc.o
>>>  obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
>>>  obj-$(CONFIG_EXTCON_INTEL_INT3496) += extcon-intel-int3496.o
>>>  obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o
>>> diff --git a/drivers/extcon/extcon-cht-wc.c b/drivers/extcon/extcon-cht-wc.c
>>> new file mode 100644
>>> index 000..896eee6
>>> --- /dev/null
>>> +++ b/drivers/extcon/extcon-cht-wc.c
>>> @@ -0,0 +1,356 @@
>>> +/*
>>> + * Extcon charger detection driver for Intel Cherrytrail Whiskey Cove PMIC
>>> + * Copyright (C) 2017 Hans de Goede 
>>> + *
>>> + * Based on various non upstream patches to support the CHT Whiskey Cove 
>>> PMIC:
>>
>> Maybe, you don't need to add ':' at the end of line.
> 
> Th ':' is there because the following copyright line:
>>
>>> + * Copyright (C) 2013-2015 Intel Corporation. All rights reserved.
> 
> Comes from those various non upstream patches.
> 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms and conditions of the GNU General Public License,
>>> + * version 2, as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope it will be useful, but WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
>>> for
>>> + * more details.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define CHT_WC_PWRSRC_IRQ0x6e03
>>> +#define CHT_WC_PWRSRC_IRQ_MASK0x6e0f
>>> +#define CHT_WC_PWRSRC_STS0x6e1e
>>> +#define CHT_WC_PWRSRC_VBUSBIT(0)
>>> +#define CHT_WC_PWRSRC_DCBIT(1)
>>> +#define CHT_WC_PWRSRC_BATBIT(2)
>>> +#define CHT_WC_PWRSRC_ID_GNDBIT(3)
>>> +#define CHT_WC_PWRSRC_ID_FLOATBIT(4)
>>> +
>>> +#define CHT_WC_PHYCTRL0x5e07
>>> +
>>> +#define CHT_WC_CHGRCTRL00x5e16
>>> +
>>> +#define CHT_WC_CHGRCTRL00x5e16
>>> +#define CHT_WC_CHGRCTRL0_CHGRRESETBIT(0)
>>> +#define CHT_WC_CHGRCTRL0_EMRGCHRENBIT(1)
>>> +#define CHT_WC_CHGRCTRL0_EXTCHRDISBIT(2)
>>> +#define CHT_WC_CHGRCTRL0_SWCONTROLBIT(3)
>>> +#define CHT_WC_CHGRCTRL0_TTLCK_MASKBIT(4)
>>> +#define CHT_WC_CHGRCTRL0_CCSM_OFF_MASKBIT(5)
>>> +#define CHT_WC_CHGRCTRL0_DBPOFF_MASKBIT(6)
>>> +#define CHT_WC_CHGRCTRL0_WDT_NOKICKBIT(7)
>>> +
>>> +#define CHT_WC_CHGRCTRL10x5e17
>>> +
>>> +#define CHT_WC_USBSRC0x5e29
>>> +#define CHT_WC_USBSRC_STS_MASKGENMASK(1, 0)
>>> +#define CHT_WC_USBSRC_STS_SUCCESS2
>>> +#define CHT_WC_USBSRC_STS_FAIL3
>>> +#define CHT_WC_USBSRC_TYPE_SHIFT2
>>> +#define CHT_WC_USBSRC_TYPE_MASKGENMASK(5, 2)
>>> +#define 

Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

[Masami Hiramatsu]

Hello Alexis and Arnaldo,

I think this series is now good to go.
Could you pick these? 

Acked-by: Masami Hiramatsu 

for this series.

Thank you,

On Wed, 14 Dec 2016 01:07:30 +0100
Alexis Berlemont  wrote:

> Hi Masami,
> 
> Many thanks for your mail.
> 
> Here is another patch set which tries to fix the points you mentioned:
> 
> * Skip the arguments containing a constant ($123); 
> * Review the code in charge of the register renaming (search for '%'
>   and parse it);
> * Minor changes (print the argument in case of error, skipping, check
>   the sdt arg type index);
> 
> Many thanks,
> 
> Alexis.
> 
> Alexis Berlemont (2):
>   perf sdt: add scanning of sdt probles arguments
>   perf probe: add sdt probes arguments into the uprobe cmd string
> 
>  tools/perf/arch/x86/util/perf_regs.c |  83 +
>  tools/perf/util/perf_regs.c  |   6 ++
>  tools/perf/util/perf_regs.h  |   6 ++
>  tools/perf/util/probe-file.c | 170 
> ++-
>  tools/perf/util/symbol-elf.c |  25 +-
>  tools/perf/util/symbol.h |   1 +
>  6 files changed, 285 insertions(+), 6 deletions(-)
> 
> -- 
> 2.10.2
> 


-- 
Masami Hiramatsu 

Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

[Masami Hiramatsu]

Hello Alexis and Arnaldo,

I think this series is now good to go.
Could you pick these? 

Acked-by: Masami Hiramatsu 

for this series.

Thank you,

On Wed, 14 Dec 2016 01:07:30 +0100
Alexis Berlemont  wrote:

> Hi Masami,
> 
> Many thanks for your mail.
> 
> Here is another patch set which tries to fix the points you mentioned:
> 
> * Skip the arguments containing a constant ($123); 
> * Review the code in charge of the register renaming (search for '%'
>   and parse it);
> * Minor changes (print the argument in case of error, skipping, check
>   the sdt arg type index);
> 
> Many thanks,
> 
> Alexis.
> 
> Alexis Berlemont (2):
>   perf sdt: add scanning of sdt probles arguments
>   perf probe: add sdt probes arguments into the uprobe cmd string
> 
>  tools/perf/arch/x86/util/perf_regs.c |  83 +
>  tools/perf/util/perf_regs.c  |   6 ++
>  tools/perf/util/perf_regs.h  |   6 ++
>  tools/perf/util/probe-file.c | 170 
> ++-
>  tools/perf/util/symbol-elf.c |  25 +-
>  tools/perf/util/symbol.h |   1 +
>  6 files changed, 285 insertions(+), 6 deletions(-)
> 
> -- 
> 2.10.2
> 


-- 
Masami Hiramatsu 

Re: [PATCH v21 13/13] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver

[Fu Wei]

Hi Mark,

On 21 March 2017 at 02:09, Mark Rutland  wrote:
> On Tue, Mar 21, 2017 at 01:57:58AM +0800, Fu Wei wrote:
>> On 18 March 2017 at 04:01, Mark Rutland  wrote:
>> > On Tue, Feb 07, 2017 at 02:50:15AM +0800, fu@linaro.org wrote:
>
>> > I've not been able to find where the ACPI spec says that zero is not a
>> > valid GSIV. This may simply be an oversight/ambiguity in the spec.
>> >
>> > Is there any statement to that effect?
>>
>> you are right, zero is a  valid GSIV, I will delete this check. Thanks
>
> That being the case, how does one describe a watchdog that does not have
> an interrupt?

I think we may can use "Timer Flags", because all the GSIV come with a flag,
if we can define a bit field called "valid" for all GSIV

Bit Field   Bit Offset   Number of bits Description
Valid31 1  This bit
indicates the validity of the timer interrupt
 1:
Interrupt is valid
 0:
Interrupt is invalid
Then we don't need to test the value of GSIV, just test this bit instead.

Just my thought, hope this makes sense to all of you :-)

>
> As I mentioned, I think this is an oversight/ambiguity in the spec tat
> we should address.
>
>> > My reading of SBSA is that there is one watchdog in the system.
>> >
>> > Is that not the case?
>>
>> do you mean:
>> ---
>> 4.2.4 Watchdogs
>> The base server system implements a Generic Watchdog as specified in
>> APPENDIX A: Generic Watchdog.
>> ---
>>
>> I am not sure about that if this is saying "we only have one SBSA
>> watchdog in a system"
>>
>> would you let me know where mention it? Do I miss something?
>
> My reading was that the 'a' above meant a single element. i.e.
>
> The base server system implements _a_ Generic Watchdog as
> specified in APPENDIX A: Generic Watchdog.
>
> Subsequently in 4.2.5, it is stated:
>
> In this scenario, the system wakeup timer or generic watchdog is
> still required to send its interrupt.
>
> ... which only makes sense if there is a single watchdog in the system.
>
> Perhaps this is an oversight in the specification.
>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v21 13/13] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver

[Fu Wei]

Hi Mark,

On 21 March 2017 at 02:09, Mark Rutland  wrote:
> On Tue, Mar 21, 2017 at 01:57:58AM +0800, Fu Wei wrote:
>> On 18 March 2017 at 04:01, Mark Rutland  wrote:
>> > On Tue, Feb 07, 2017 at 02:50:15AM +0800, fu@linaro.org wrote:
>
>> > I've not been able to find where the ACPI spec says that zero is not a
>> > valid GSIV. This may simply be an oversight/ambiguity in the spec.
>> >
>> > Is there any statement to that effect?
>>
>> you are right, zero is a  valid GSIV, I will delete this check. Thanks
>
> That being the case, how does one describe a watchdog that does not have
> an interrupt?

I think we may can use "Timer Flags", because all the GSIV come with a flag,
if we can define a bit field called "valid" for all GSIV

Bit Field   Bit Offset   Number of bits Description
Valid31 1  This bit
indicates the validity of the timer interrupt
 1:
Interrupt is valid
 0:
Interrupt is invalid
Then we don't need to test the value of GSIV, just test this bit instead.

Just my thought, hope this makes sense to all of you :-)

>
> As I mentioned, I think this is an oversight/ambiguity in the spec tat
> we should address.
>
>> > My reading of SBSA is that there is one watchdog in the system.
>> >
>> > Is that not the case?
>>
>> do you mean:
>> ---
>> 4.2.4 Watchdogs
>> The base server system implements a Generic Watchdog as specified in
>> APPENDIX A: Generic Watchdog.
>> ---
>>
>> I am not sure about that if this is saying "we only have one SBSA
>> watchdog in a system"
>>
>> would you let me know where mention it? Do I miss something?
>
> My reading was that the 'a' above meant a single element. i.e.
>
> The base server system implements _a_ Generic Watchdog as
> specified in APPENDIX A: Generic Watchdog.
>
> Subsequently in 4.2.5, it is stated:
>
> In this scenario, the system wakeup timer or generic watchdog is
> still required to send its interrupt.
>
> ... which only makes sense if there is a single watchdog in the system.
>
> Perhaps this is an oversight in the specification.
>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH] pci/sriov: Add an option to probe VFs or not before enabling SR-IOV

[Alex Williamson]

On Mon, 20 Mar 2017 18:34:23 -0500
Bodong Wang  wrote:

> On 3/20/2017 6:07 PM, Gavin Shan wrote:
> > On Mon, Mar 20, 2017 at 05:14:34PM +0200, bod...@mellanox.com wrote:  
> >> From: Bodong Wang 
> >>
> >> Sometimes it is not desirable to probe the virtual functions after
> >> SRIOV is enabled. This can save host side resource usage by VF
> >> instances which would be eventually probed to VMs.

What resources would not be released when the VF driver is unbound?

> >> Added a new PCI sysfs interface "sriov_probe_vfs" to control that
> > >from PF, all current callers still retain the same functionality.
> >> To modify it, echo 0/n/N (disable probe) or 1/y/Y (enable probe) to
> >>
> >> /sys/bus/pci/devices//sriov_probe_vfs
> >>
> >> Note that, the choice must be made before enabling VFs. The change
> >> will not take effect if VFs are already enabled. Simply, one can set
> >> sriov_numvfs to 0, choose whether to probe or not, and then resume
> >> sriov_numvfs.
> >>  
> > Bodong, I'm not sure if there is a requirement to load driver for the
> > specified number of VFs? That indicates no driver will be loaded for
> > other VFs. If so, this interface might serve the purpose as well.  
> Gavin, thanks for the review. That is indeed an interesting suggestion. 
> Theoretically,  we can change that probe_vfs from boolean to integer. 
> And use it as a counter to probe the first N VFs(if N < total_vfs).  
> Let's see if there are any objections.

Is it just me or does this seem like a confusing user interface, ie. to
get binary on/off behavior a user now needs to 'cat total_vfs >
sriov_probe_vfs'.  It's not very intuitive, what's the use case for it?


> >
> >
> > +#ifdef CONFIG_PCI_IOV
> > +   if (!pci_dev->is_virtfn ||
> > +   (pci_dev->is_virtfn && pci_dev->physfn->sriov->probe_vfs)) {
> > +#endif
> > +   error = __pci_device_probe(drv, pci_dev);
> > +   if (error) {
> > +   pcibios_free_irq(pci_dev);
> > +   pci_dev_put(pci_dev);
> > +   }
> > +#ifdef CONFIG_PCI_IOV
> > }
> > +#endif
> >
> > I think it's reasonable to have a inline function for this check:  
> It's doable, but what's the benefit?

Way cleaner.

> >
> > #ifdef CONFIG_PCI_IOV
> > static inline bool pci_device_can_probe(struct pci_dev *pdev)
> > {
> > return (!pdev->is_virtfn || pdev->physfn->sriov->probe_vfs);  
> should be return (!pdev->is_virtfn || (pci_dev->is_virtfn && 
> pci_dev->physfn->sriov->probe_vfs));
> 
> We want to probe that device if 1) it's a PF 2) it'a VF and probe_vfs is set
> > }
> > #else
> > static inline bool pci_device_can_probe(struct pci_dev *pdev)
> > {
> > return true;
> > }  
> This function will be a waste if CONFIG_PCI_IOV is not defined.
> > #endif  
> 
> > Thanks,
> > Gavin
> >  
> 

Re: [PATCH] pci/sriov: Add an option to probe VFs or not before enabling SR-IOV

[Alex Williamson]

On Mon, 20 Mar 2017 18:34:23 -0500
Bodong Wang  wrote:

> On 3/20/2017 6:07 PM, Gavin Shan wrote:
> > On Mon, Mar 20, 2017 at 05:14:34PM +0200, bod...@mellanox.com wrote:  
> >> From: Bodong Wang 
> >>
> >> Sometimes it is not desirable to probe the virtual functions after
> >> SRIOV is enabled. This can save host side resource usage by VF
> >> instances which would be eventually probed to VMs.

What resources would not be released when the VF driver is unbound?

> >> Added a new PCI sysfs interface "sriov_probe_vfs" to control that
> > >from PF, all current callers still retain the same functionality.
> >> To modify it, echo 0/n/N (disable probe) or 1/y/Y (enable probe) to
> >>
> >> /sys/bus/pci/devices//sriov_probe_vfs
> >>
> >> Note that, the choice must be made before enabling VFs. The change
> >> will not take effect if VFs are already enabled. Simply, one can set
> >> sriov_numvfs to 0, choose whether to probe or not, and then resume
> >> sriov_numvfs.
> >>  
> > Bodong, I'm not sure if there is a requirement to load driver for the
> > specified number of VFs? That indicates no driver will be loaded for
> > other VFs. If so, this interface might serve the purpose as well.  
> Gavin, thanks for the review. That is indeed an interesting suggestion. 
> Theoretically,  we can change that probe_vfs from boolean to integer. 
> And use it as a counter to probe the first N VFs(if N < total_vfs).  
> Let's see if there are any objections.

Is it just me or does this seem like a confusing user interface, ie. to
get binary on/off behavior a user now needs to 'cat total_vfs >
sriov_probe_vfs'.  It's not very intuitive, what's the use case for it?


> >
> >
> > +#ifdef CONFIG_PCI_IOV
> > +   if (!pci_dev->is_virtfn ||
> > +   (pci_dev->is_virtfn && pci_dev->physfn->sriov->probe_vfs)) {
> > +#endif
> > +   error = __pci_device_probe(drv, pci_dev);
> > +   if (error) {
> > +   pcibios_free_irq(pci_dev);
> > +   pci_dev_put(pci_dev);
> > +   }
> > +#ifdef CONFIG_PCI_IOV
> > }
> > +#endif
> >
> > I think it's reasonable to have a inline function for this check:  
> It's doable, but what's the benefit?

Way cleaner.

> >
> > #ifdef CONFIG_PCI_IOV
> > static inline bool pci_device_can_probe(struct pci_dev *pdev)
> > {
> > return (!pdev->is_virtfn || pdev->physfn->sriov->probe_vfs);  
> should be return (!pdev->is_virtfn || (pci_dev->is_virtfn && 
> pci_dev->physfn->sriov->probe_vfs));
> 
> We want to probe that device if 1) it's a PF 2) it'a VF and probe_vfs is set
> > }
> > #else
> > static inline bool pci_device_can_probe(struct pci_dev *pdev)
> > {
> > return true;
> > }  
> This function will be a waste if CONFIG_PCI_IOV is not defined.
> > #endif  
> 
> > Thanks,
> > Gavin
> >  
> 

Re: lockdep warning: console vs. mem hotplug

[Sergey Senozhatsky]

[..]
> 3) move add_timer() out of sclp_con_lock console in sclp_console_write().

I take it back. Won't improve anything.

-ss

Re: lockdep warning: console vs. mem hotplug

[Sergey Senozhatsky]

[..]
> 3) move add_timer() out of sclp_con_lock console in sclp_console_write().

I take it back. Won't improve anything.

-ss

[PATCH 2/2] regulator: hi655x: Bump parent pmic module use count

[Jeremy Linton]

The hi655x-regulator driver depends on the parent pmic/mfc
device driver but doesn't increase its use count. This results
in system crashes if the parent module is unloaded while the
regulators are still in use. Add explicit module get/put
calls to keep the parent from being unloaded.

Signed-off-by: Jeremy Linton 
---
 drivers/regulator/hi655x-regulator.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/hi655x-regulator.c 
b/drivers/regulator/hi655x-regulator.c
index aca1846..5a461d4 100644
--- a/drivers/regulator/hi655x-regulator.c
+++ b/drivers/regulator/hi655x-regulator.c
@@ -185,16 +185,29 @@ static int hi655x_regulator_probe(struct platform_device 
*pdev)
struct hi655x_pmic *pmic;
struct regulator_config config = { };
struct regulator_dev *rdev;
+   struct device *parent = pdev->dev.parent;
 
-   pmic = dev_get_drvdata(pdev->dev.parent);
+   if (!parent) {
+   dev_err(>dev, "no regulator parent node\n");
+   return -ENODEV;
+   }
+
+   pmic = dev_get_drvdata(parent);
if (!pmic) {
dev_err(>dev, "no pmic in the regulator parent node\n");
return -ENODEV;
}
 
+   if (!try_module_get(parent->driver->owner)) {
+   dev_err(>dev, "unable to get parent module\n");
+   return -ENODEV;
+   }
+
regulator = devm_kzalloc(>dev, sizeof(*regulator), GFP_KERNEL);
-   if (!regulator)
+   if (!regulator) {
+   module_put(parent->driver->owner);
return -ENOMEM;
+   }
 
platform_set_drvdata(pdev, regulator);
 
@@ -214,11 +227,20 @@ static int hi655x_regulator_probe(struct platform_device 
*pdev)
return 0;
 }
 
+static int hi655x_regulator_remove(struct platform_device *pdev)
+{
+   struct device *parent = pdev->dev.parent;
+
+   module_put(parent->driver->owner);
+   return 0;
+}
+
 static struct platform_driver hi655x_regulator_driver = {
.driver = {
.name   = "hi655x-regulator",
},
.probe  = hi655x_regulator_probe,
+   .remove = hi655x_regulator_remove
 };
 module_platform_driver(hi655x_regulator_driver);
 
-- 
2.10.2

[PATCH 2/2] regulator: hi655x: Bump parent pmic module use count

[Jeremy Linton]

The hi655x-regulator driver depends on the parent pmic/mfc
device driver but doesn't increase its use count. This results
in system crashes if the parent module is unloaded while the
regulators are still in use. Add explicit module get/put
calls to keep the parent from being unloaded.

Signed-off-by: Jeremy Linton 
---
 drivers/regulator/hi655x-regulator.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/hi655x-regulator.c 
b/drivers/regulator/hi655x-regulator.c
index aca1846..5a461d4 100644
--- a/drivers/regulator/hi655x-regulator.c
+++ b/drivers/regulator/hi655x-regulator.c
@@ -185,16 +185,29 @@ static int hi655x_regulator_probe(struct platform_device 
*pdev)
struct hi655x_pmic *pmic;
struct regulator_config config = { };
struct regulator_dev *rdev;
+   struct device *parent = pdev->dev.parent;
 
-   pmic = dev_get_drvdata(pdev->dev.parent);
+   if (!parent) {
+   dev_err(>dev, "no regulator parent node\n");
+   return -ENODEV;
+   }
+
+   pmic = dev_get_drvdata(parent);
if (!pmic) {
dev_err(>dev, "no pmic in the regulator parent node\n");
return -ENODEV;
}
 
+   if (!try_module_get(parent->driver->owner)) {
+   dev_err(>dev, "unable to get parent module\n");
+   return -ENODEV;
+   }
+
regulator = devm_kzalloc(>dev, sizeof(*regulator), GFP_KERNEL);
-   if (!regulator)
+   if (!regulator) {
+   module_put(parent->driver->owner);
return -ENOMEM;
+   }
 
platform_set_drvdata(pdev, regulator);
 
@@ -214,11 +227,20 @@ static int hi655x_regulator_probe(struct platform_device 
*pdev)
return 0;
 }
 
+static int hi655x_regulator_remove(struct platform_device *pdev)
+{
+   struct device *parent = pdev->dev.parent;
+
+   module_put(parent->driver->owner);
+   return 0;
+}
+
 static struct platform_driver hi655x_regulator_driver = {
.driver = {
.name   = "hi655x-regulator",
},
.probe  = hi655x_regulator_probe,
+   .remove = hi655x_regulator_remove
 };
 module_platform_driver(hi655x_regulator_driver);
 
-- 
2.10.2

[lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

[kernel test robot]

FYI, we noticed the following commit:

commit: 69218e47994da614e7af600bf06887750ab6657a ("x86: Remap GDT tables in the 
fixmap section")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | f06bdd4001 | 
69218e4799 |
+--+++
| boot_successes   | 3  | 0 
 |
| boot_failures| 5  | 8 
 |
| BUG:kernel_reboot-without-warning_in_boot_stage  | 4  |   
 |
| WARNING:at_arch/x86/include/asm/fpu/internal.h:#fpu__restore | 1  |   
 |
| BUG:kernel_hang_in_boot_stage| 0  | 8 
 |
+--+++

[0.00] sysrq: sysrq always enabled.
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Initializing CPU#0
[0.00] allocated 331644 bytes of page_ext
[0.00] Initializing HighMem for node 0 (:)
[0.00] Memory: 267332K/327160K available (14061K kernel code, 1104K 
rwdata, 4696K rodata, 2460K init, 13208K bss, 59828K reserved, 0K cma-reserved, 
0K highmem)
[0.00] virtual kernel memory layout:
[0.00] fixmap  : 0xffa74000 - 0xf000   (5676 kB)
[0.00] pkmap   : 0xff40 - 0xff80   (4096 kB)
[0.00] vmalloc : 0x547e - 0xff3fe000   (2732 MB)
[0.00] lowmem  : 0x4000 - 0x53fe   ( 319 MB)
[0.00]   .init : 0x4236a000 - 0x425d1000   (2460 kB)
[0.00]   .data : 0x41dbb72c - 0x42368300   (5810 kB)
[0.00]   .text : 0x4100 - 0x41dbb72c   (14061 kB)


Elapsed time: 480
BUG: kernel hang in boot stage

initrds=(
/osimage/yocto/yocto-tiny-i386-2016-04-22.cgz

/lkp/scheduled/vm-lkp-hsw01-yocto-i386-25/trinity-300s-yocto-tiny-i386-2016-04-22.cgz-69218e47994da614e7af600bf06887750ab6657a-20170319-117821-bls48g-0.cgz
/lkp/lkp/lkp-i386.cgz


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.11.0-rc2 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

[lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

[kernel test robot]

FYI, we noticed the following commit:

commit: 69218e47994da614e7af600bf06887750ab6657a ("x86: Remap GDT tables in the 
fixmap section")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | f06bdd4001 | 
69218e4799 |
+--+++
| boot_successes   | 3  | 0 
 |
| boot_failures| 5  | 8 
 |
| BUG:kernel_reboot-without-warning_in_boot_stage  | 4  |   
 |
| WARNING:at_arch/x86/include/asm/fpu/internal.h:#fpu__restore | 1  |   
 |
| BUG:kernel_hang_in_boot_stage| 0  | 8 
 |
+--+++

[0.00] sysrq: sysrq always enabled.
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Initializing CPU#0
[0.00] allocated 331644 bytes of page_ext
[0.00] Initializing HighMem for node 0 (:)
[0.00] Memory: 267332K/327160K available (14061K kernel code, 1104K 
rwdata, 4696K rodata, 2460K init, 13208K bss, 59828K reserved, 0K cma-reserved, 
0K highmem)
[0.00] virtual kernel memory layout:
[0.00] fixmap  : 0xffa74000 - 0xf000   (5676 kB)
[0.00] pkmap   : 0xff40 - 0xff80   (4096 kB)
[0.00] vmalloc : 0x547e - 0xff3fe000   (2732 MB)
[0.00] lowmem  : 0x4000 - 0x53fe   ( 319 MB)
[0.00]   .init : 0x4236a000 - 0x425d1000   (2460 kB)
[0.00]   .data : 0x41dbb72c - 0x42368300   (5810 kB)
[0.00]   .text : 0x4100 - 0x41dbb72c   (14061 kB)


Elapsed time: 480
BUG: kernel hang in boot stage

initrds=(
/osimage/yocto/yocto-tiny-i386-2016-04-22.cgz

/lkp/scheduled/vm-lkp-hsw01-yocto-i386-25/trinity-300s-yocto-tiny-i386-2016-04-22.cgz-69218e47994da614e7af600bf06887750ab6657a-20170319-117821-bls48g-0.cgz
/lkp/lkp/lkp-i386.cgz


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.11.0-rc2 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

[PATCH 1/2] mfd: hi655x: Reference required regulator driver

[Jeremy Linton]

The hisi pmic requires an independent regulator driver to be
loaded so that devices dependent on the pmic/regulator are
started properly. Currently there is only a single compatible
regulator driver in the tree, so reference it with a module soft
dependency so that modprobe loads it whenever the hisi pmic
driver is loaded.

Signed-off-by: Jeremy Linton 
---
 drivers/mfd/hi655x-pmic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
index ba706ad..56e027d 100644
--- a/drivers/mfd/hi655x-pmic.c
+++ b/drivers/mfd/hi655x-pmic.c
@@ -184,3 +184,4 @@ module_platform_driver(hi655x_pmic_driver);
 MODULE_AUTHOR("Chen Feng ");
 MODULE_DESCRIPTION("Hisilicon hi655x PMIC driver");
 MODULE_LICENSE("GPL v2");
+MODULE_SOFTDEP("post: hi655x-regulator");
-- 
2.10.2

[PATCH 1/2] mfd: hi655x: Reference required regulator driver

[Jeremy Linton]

The hisi pmic requires an independent regulator driver to be
loaded so that devices dependent on the pmic/regulator are
started properly. Currently there is only a single compatible
regulator driver in the tree, so reference it with a module soft
dependency so that modprobe loads it whenever the hisi pmic
driver is loaded.

Signed-off-by: Jeremy Linton 
---
 drivers/mfd/hi655x-pmic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
index ba706ad..56e027d 100644
--- a/drivers/mfd/hi655x-pmic.c
+++ b/drivers/mfd/hi655x-pmic.c
@@ -184,3 +184,4 @@ module_platform_driver(hi655x_pmic_driver);
 MODULE_AUTHOR("Chen Feng ");
 MODULE_DESCRIPTION("Hisilicon hi655x PMIC driver");
 MODULE_LICENSE("GPL v2");
+MODULE_SOFTDEP("post: hi655x-regulator");
-- 
2.10.2

[lkp-robot] [locking/ww_mutex] bf7b3ac2e3: INFO:task_blocked_for_more_than#seconds

[kernel test robot]

FYI, we noticed the following commit:

commit: bf7b3ac2e36ac054f93e5dd8d85dfd754b5e1c09 ("locking/ww_mutex: Improve 
test to cover acquire context changes")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 2G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 383776fa75 | bf7b3ac2e3 |
+--+++
| boot_successes   | 18 | 3  |
| boot_failures| 0  | 15 |
| INFO:task_blocked_for_more_than#seconds  | 0  | 15 |
| Kernel_panic-not_syncing:hung_task:blocked_tasks | 0  | 15 |
| calltrace:debug_show_all_locks   | 0  | 6  |
+--+++



[  248.961691] INFO: task swapper:1 blocked for more than 120 seconds.
[  248.961691] INFO: task swapper:1 blocked for more than 120 seconds.
[  249.009818]   Not tainted 4.11.0-rc2-00010-gbf7b3ac #1
[  249.009818]   Not tainted 4.11.0-rc2-00010-gbf7b3ac #1
[  249.038399] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  249.038399] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  249.083512] swapper D11856 1  0 0x
[  249.083512] swapper D11856 1  0 0x
[  249.113610] Call Trace:
[  249.113610] Call Trace:
[  249.140090]  __schedule+0x4c2/0x520
[  249.140090]  __schedule+0x4c2/0x520
[  249.161677]  ? ___preempt_schedule+0x16/0x18
[  249.161677]  ? ___preempt_schedule+0x16/0x18
[  249.210605]  schedule+0x26/0x3b
[  249.210605]  schedule+0x26/0x3b
[  249.229561]  schedule_timeout+0x2b/0x2bc
[  249.229561]  schedule_timeout+0x2b/0x2bc
[  249.257556]  wait_for_common+0x11e/0x1b5
[  249.257556]  wait_for_common+0x11e/0x1b5
[  249.279561]  ? try_to_wake_up+0x19f/0x19f
[  249.279561]  ? try_to_wake_up+0x19f/0x19f
[  249.319167]  wait_for_completion+0x18/0x1a
[  249.319167]  wait_for_completion+0x18/0x1a
[  249.341751]  flush_workqueue+0x2ac/0x5c9
[  249.341751]  flush_workqueue+0x2ac/0x5c9
[  249.384465]  ? flush_workqueue+0xa7/0x5c9
[  249.384465]  ? flush_workqueue+0xa7/0x5c9
[  249.406499]  ? _raw_spin_unlock_irqrestore+0x49/0x5d
[  249.406499]  ? _raw_spin_unlock_irqrestore+0x49/0x5d
[  249.436407]  ? _raw_spin_unlock+0x3f/0x43
[  249.436407]  ? _raw_spin_unlock+0x3f/0x43
[  249.458614]  ? __queue_work+0x2c1/0x2d0
[  249.458614]  ? __queue_work+0x2c1/0x2d0
[  249.485798]  ? get_random_order+0x7e/0x7e
[  249.485798]  ? get_random_order+0x7e/0x7e
[  249.511661]  ? get_random_order+0x7e/0x7e
[  249.511661]  ? get_random_order+0x7e/0x7e
[  249.533689]  stress+0x1a0/0x1d4
[  249.533689]  stress+0x1a0/0x1d4
[  249.551804]  test_ww_mutex_init+0x28a/0x2ce
[  249.551804]  test_ww_mutex_init+0x28a/0x2ce
[  249.590171]  ? proc_create_data+0xa1/0xbc
[  249.590171]  ? proc_create_data+0xa1/0xbc
[  249.613023]  ? lock_torture_init+0x59b/0x59b
[  249.613023]  ? lock_torture_init+0x59b/0x59b
[  249.639818]  do_one_initcall+0x86/0x155
[  249.639818]  do_one_initcall+0x86/0x155
[  249.661813]  kernel_init_freeable+0x110/0x19a
[  249.661813]  kernel_init_freeable+0x110/0x19a
[  249.696422]  ? kernel_init_freeable+0x19a/0x19a
[  249.696422]  ? kernel_init_freeable+0x19a/0x19a
[  249.728401]  ? rest_init+0xbf/0xbf
[  249.728401]  ? rest_init+0xbf/0xbf
[  249.755948]  kernel_init+0x9/0xf3
[  249.755948]  kernel_init+0x9/0xf3
[  249.771735]  ret_from_fork+0x2c/0x40
[  249.771735]  ret_from_fork+0x2c/0x40
[  249.793736] 
[  249.793736] Showing all locks held in the system:
[  249.793736] 
[  249.793736] Showing all locks held in the system:
[  249.831650] 2 locks held by khungtaskd/15:
[  249.831650] 2 locks held by khungtaskd/15:
[  249.851454]  #0:  (rcu_read_lock){..}, at: [] 
watchdog+0x96/0x352
[  249.851454]  #0:  (rcu_read_lock){..}, at: [] 
watchdog+0x96/0x352
[  249.885734]  #1:  (tasklist_lock){..}, at: [] 
debug_show_all_locks+0x52/0x193
[  249.885734]  #1:  (tasklist_lock){..}, at: [] 
debug_show_all_locks+0x52/0x193
[  249.923459] 
[  249.923459] 
[  249.929288] =
[  249.929288] 
[  249.929288] =
[  249.929288] 
[  249.969510] NMI backtrace for cpu 0
[  249.969510] NMI backtrace for cpu 0
[  249.985283] CPU: 0 PID: 15 Comm: khungtaskd Not tainted 
4.11.0-rc2-00010-gbf7b3ac #1
[  249.985283] CPU: 0 PID: 15 Comm: khungtaskd Not tainted 
4.11.0-rc2-00010-gbf7b3ac #1
[  250.019213] Call Trace:
[  250.019213] Call Trace:
[  250.030263]  dump_stack+0x19/0x1b
[  250.030263]  dump_stack+0x19/0x1b
[  250.045041]  

[lkp-robot] [locking/ww_mutex] bf7b3ac2e3: INFO:task_blocked_for_more_than#seconds

[kernel test robot]

FYI, we noticed the following commit:

commit: bf7b3ac2e36ac054f93e5dd8d85dfd754b5e1c09 ("locking/ww_mutex: Improve 
test to cover acquire context changes")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 2G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 383776fa75 | bf7b3ac2e3 |
+--+++
| boot_successes   | 18 | 3  |
| boot_failures| 0  | 15 |
| INFO:task_blocked_for_more_than#seconds  | 0  | 15 |
| Kernel_panic-not_syncing:hung_task:blocked_tasks | 0  | 15 |
| calltrace:debug_show_all_locks   | 0  | 6  |
+--+++



[  248.961691] INFO: task swapper:1 blocked for more than 120 seconds.
[  248.961691] INFO: task swapper:1 blocked for more than 120 seconds.
[  249.009818]   Not tainted 4.11.0-rc2-00010-gbf7b3ac #1
[  249.009818]   Not tainted 4.11.0-rc2-00010-gbf7b3ac #1
[  249.038399] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  249.038399] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  249.083512] swapper D11856 1  0 0x
[  249.083512] swapper D11856 1  0 0x
[  249.113610] Call Trace:
[  249.113610] Call Trace:
[  249.140090]  __schedule+0x4c2/0x520
[  249.140090]  __schedule+0x4c2/0x520
[  249.161677]  ? ___preempt_schedule+0x16/0x18
[  249.161677]  ? ___preempt_schedule+0x16/0x18
[  249.210605]  schedule+0x26/0x3b
[  249.210605]  schedule+0x26/0x3b
[  249.229561]  schedule_timeout+0x2b/0x2bc
[  249.229561]  schedule_timeout+0x2b/0x2bc
[  249.257556]  wait_for_common+0x11e/0x1b5
[  249.257556]  wait_for_common+0x11e/0x1b5
[  249.279561]  ? try_to_wake_up+0x19f/0x19f
[  249.279561]  ? try_to_wake_up+0x19f/0x19f
[  249.319167]  wait_for_completion+0x18/0x1a
[  249.319167]  wait_for_completion+0x18/0x1a
[  249.341751]  flush_workqueue+0x2ac/0x5c9
[  249.341751]  flush_workqueue+0x2ac/0x5c9
[  249.384465]  ? flush_workqueue+0xa7/0x5c9
[  249.384465]  ? flush_workqueue+0xa7/0x5c9
[  249.406499]  ? _raw_spin_unlock_irqrestore+0x49/0x5d
[  249.406499]  ? _raw_spin_unlock_irqrestore+0x49/0x5d
[  249.436407]  ? _raw_spin_unlock+0x3f/0x43
[  249.436407]  ? _raw_spin_unlock+0x3f/0x43
[  249.458614]  ? __queue_work+0x2c1/0x2d0
[  249.458614]  ? __queue_work+0x2c1/0x2d0
[  249.485798]  ? get_random_order+0x7e/0x7e
[  249.485798]  ? get_random_order+0x7e/0x7e
[  249.511661]  ? get_random_order+0x7e/0x7e
[  249.511661]  ? get_random_order+0x7e/0x7e
[  249.533689]  stress+0x1a0/0x1d4
[  249.533689]  stress+0x1a0/0x1d4
[  249.551804]  test_ww_mutex_init+0x28a/0x2ce
[  249.551804]  test_ww_mutex_init+0x28a/0x2ce
[  249.590171]  ? proc_create_data+0xa1/0xbc
[  249.590171]  ? proc_create_data+0xa1/0xbc
[  249.613023]  ? lock_torture_init+0x59b/0x59b
[  249.613023]  ? lock_torture_init+0x59b/0x59b
[  249.639818]  do_one_initcall+0x86/0x155
[  249.639818]  do_one_initcall+0x86/0x155
[  249.661813]  kernel_init_freeable+0x110/0x19a
[  249.661813]  kernel_init_freeable+0x110/0x19a
[  249.696422]  ? kernel_init_freeable+0x19a/0x19a
[  249.696422]  ? kernel_init_freeable+0x19a/0x19a
[  249.728401]  ? rest_init+0xbf/0xbf
[  249.728401]  ? rest_init+0xbf/0xbf
[  249.755948]  kernel_init+0x9/0xf3
[  249.755948]  kernel_init+0x9/0xf3
[  249.771735]  ret_from_fork+0x2c/0x40
[  249.771735]  ret_from_fork+0x2c/0x40
[  249.793736] 
[  249.793736] Showing all locks held in the system:
[  249.793736] 
[  249.793736] Showing all locks held in the system:
[  249.831650] 2 locks held by khungtaskd/15:
[  249.831650] 2 locks held by khungtaskd/15:
[  249.851454]  #0:  (rcu_read_lock){..}, at: [] 
watchdog+0x96/0x352
[  249.851454]  #0:  (rcu_read_lock){..}, at: [] 
watchdog+0x96/0x352
[  249.885734]  #1:  (tasklist_lock){..}, at: [] 
debug_show_all_locks+0x52/0x193
[  249.885734]  #1:  (tasklist_lock){..}, at: [] 
debug_show_all_locks+0x52/0x193
[  249.923459] 
[  249.923459] 
[  249.929288] =
[  249.929288] 
[  249.929288] =
[  249.929288] 
[  249.969510] NMI backtrace for cpu 0
[  249.969510] NMI backtrace for cpu 0
[  249.985283] CPU: 0 PID: 15 Comm: khungtaskd Not tainted 
4.11.0-rc2-00010-gbf7b3ac #1
[  249.985283] CPU: 0 PID: 15 Comm: khungtaskd Not tainted 
4.11.0-rc2-00010-gbf7b3ac #1
[  250.019213] Call Trace:
[  250.019213] Call Trace:
[  250.030263]  dump_stack+0x19/0x1b
[  250.030263]  dump_stack+0x19/0x1b
[  250.045041]  

[PATCH 0/2] Hi655x: mfd/pmic: regulator: Correct dependencies

[Jeremy Linton]

In an environment where the hi655x pmic is being built as a 
standalone module, it fails to automatically load resulting
in boot failures, machine hangs, etc. First we correct this
by setting an appropriate module dependency. Then we bump the
module use count on the mfd/pmic driver so that it cannot be
unloaded when in use. Again this avoids machine crashes.

Jeremy Linton (2):
  mfd: hi655x: Reference required regulator driver
  regulator: hi655x: Bump parent pmic module use count

 drivers/mfd/hi655x-pmic.c|  1 +
 drivers/regulator/hi655x-regulator.c | 26 --
 2 files changed, 25 insertions(+), 2 deletions(-)

-- 
2.10.2

[PATCH 0/2] Hi655x: mfd/pmic: regulator: Correct dependencies

[Jeremy Linton]

In an environment where the hi655x pmic is being built as a 
standalone module, it fails to automatically load resulting
in boot failures, machine hangs, etc. First we correct this
by setting an appropriate module dependency. Then we bump the
module use count on the mfd/pmic driver so that it cannot be
unloaded when in use. Again this avoids machine crashes.

Jeremy Linton (2):
  mfd: hi655x: Reference required regulator driver
  regulator: hi655x: Bump parent pmic module use count

 drivers/mfd/hi655x-pmic.c|  1 +
 drivers/regulator/hi655x-regulator.c | 26 --
 2 files changed, 25 insertions(+), 2 deletions(-)

-- 
2.10.2

Re: [PATCH v5 4/7] perf/sdt: Allow recording of existing events

[Masami Hiramatsu]

On Mon, 20 Mar 2017 14:42:22 +0530
Ravi Bangoria  wrote:

[SNIP]
> >>  }
> >>  
> >> -/*
> >> - * Find the SDT event from the cache and if found add it/them
> >> - * to the uprobe_events file
> >> - */
> >> +static bool sdt_is_ptrn_used(struct perf_probe_event *pev)
> > This might be sdt_name_is_glob().
> 
> Hmm looks good. Will change it.
> 
> >> +{
> >> +  return !is_c_func_name(pev->group) || !is_c_func_name(pev->event);
> > Would you mean strisglob()@util.h ? :)
> 
> Yes, BUT this needs to be changed now.
> 
> I found perf probe accepts glob wildcards(*, ?) and character classes like
> [a-z]. But perf record only allow wildcards. So I can't use strisglob()
> function.

Oops, right. Hmm, Jiri, can we support full glob matching for events?
(or what happen if we use it?)

> 
> Please let me know if that is wrong.
> 
> >> +}
> >> +
> >> +static bool sdt_name_match(struct perf_probe_event *pev,
> >> + struct probe_trace_event *tev)
> >> +{
> >> +  if (sdt_is_ptrn_used(pev))
> >> +  return strglobmatch(tev->group, pev->group) &&
> >> +  strglobmatch(tev->event, pev->event);
> >> +
> >> +  return !strcmp(tev->group, pev->group) &&
> >> +  !strcmp(tev->event, pev->event);
> > Would we really need these two? Since strglobmatch() accepts a string
> > without wildcard, you don't need strcmp() version...
> 
> Hmm. yes, second part looks unnecessary.
> 
> >> +}
> >> +
> >> +static void sdt_warn_multi_events(int ctr, struct perf_probe_event *pev)
> >> +{
> >> +  pr_warning("Warning: Recording on %d occurrences of %s:%s\n",
> >> + ctr, pev->group, pev->event);
> > Could you show what event will be recorded instead of just showing 
> > the number of events?
> 
> Sure. I'll remove this warning and show all events as 'event addr@file'.
> Please let me know if you want to list it differently.
> 
> Actually, I do that, but partially. Please see patch 6/7. It list all those
> *existing* events which are being recorded.

OK, that will be enough for users to warn.

[SNIP]
> >> @@ -3606,23 +3727,37 @@ int add_sdt_event(char *event, struct list_head 
> >> *sdt_evlist)
> >>probe_conf.max_probes = MAX_PROBES;
> >>probe_conf.force_add = 1;
> >>  
> >> +  /* Fetch all sdt events from uprobe_events */
> >> +  exst_ntevs = probe_file__get_sdt_events(_tevs);
> >> +  if (exst_ntevs < 0) {
> >> +  ret = exst_ntevs;
> >> +  goto free_pev;
> >> +  }
> >> +
> >> +  /* Check if events with same name already exists in uprobe_events. */
> >> +  ret = sdt_event_probepoint_exists(pev, exst_tevs,
> >> +   exst_ntevs, sdt_evlist);
> >> +  if (ret) {
> >> +  ret = ret > 0 ? 0 : ret;
> >> +  goto free_pev;
> >> +  }
> >> +
> >>/* Fetch all matching events from cache. */
> >>ret = get_sdt_events_from_cache(pev);
> >>if (ret < 0)
> >>goto free_pev;
> > Hmm, IMHO, you'd better call get_sdt_events_from_cache() first, and
> > check the existence of those events afterwards. Then you may not
> > need the "shift" function.
> 
> "shift" function is needed. let me explain.
> 
> As we are allowing both, 'perf probe' as well as 'perf record' on SDT
> events, there are two sources of events for 'perf record'
>   1. uprobe_events file
>   2. probe-cache
> 
> When perf fetches events from cache, it fetch all matching events,
> no matter if any event already exists in uprobe_events or not.
> 
> Consider an example, There are 3 events with same name sdt_a:b
> exists in 'test' binary.
> 
>   $ readelf -n test
> sdt_a:b @ addr 0x123
> sdt_a:b @ addr 0x456
> sdt_a:b @ addr 0x789
> 
>   $ perf probe -x test sdt_a:b
>  /* Add all 3 events sdt_a:b  sdt_a:b_1 and sdt_a:b_2 */
>   $ perf probe -d sdt_a:b
>   $ perf probe -d sdt_a:b_2
> 
>   $ perf record sdt_a:b
> /*
>   arr1 = probe_file__get_sdt_events();
>  {sdt_a:b_1 addr 0x456}
> 
>   arr2 = get_sdt_events_from_cache();
>  {sdt_a:b addr 0x123, sdt_a:b addr 0x456, sdt_a:b addr 0x789}
> 
>   Now, as sdt event of addr 0x456 already exists in arr1, it needs to
>   be reused and thus it needs to be removed from arr2. Removing
>   2nd element needs shifting of third element to 2nd position.
> */

Ah, I see. In that case, you can just set the tev->point.symbol = NULL,
then it is just skipped to apply in __add_probe_trace_events().

So what you need to do is, 1) get_sdt_events_from_cache(pev); and
2) set tev[x].point.symbol = NULL in sdt_event_probepoint_exists().
(I also recommend to release tev[x].event and group, then you can
 easilly find what events should be removed afterwards)

Thank you,



> 
> I don't think it's easy to remove "shift" function. I can remove it but
> that needs changes in existing infrastructure like fetch only those
> events from cache which are not present in uprobe_events. But,
> IMHO, it's not a good way to go.
> 
> Let me know 

Re: [PATCH v5 4/7] perf/sdt: Allow recording of existing events

[Masami Hiramatsu]

On Mon, 20 Mar 2017 14:42:22 +0530
Ravi Bangoria  wrote:

[SNIP]
> >>  }
> >>  
> >> -/*
> >> - * Find the SDT event from the cache and if found add it/them
> >> - * to the uprobe_events file
> >> - */
> >> +static bool sdt_is_ptrn_used(struct perf_probe_event *pev)
> > This might be sdt_name_is_glob().
> 
> Hmm looks good. Will change it.
> 
> >> +{
> >> +  return !is_c_func_name(pev->group) || !is_c_func_name(pev->event);
> > Would you mean strisglob()@util.h ? :)
> 
> Yes, BUT this needs to be changed now.
> 
> I found perf probe accepts glob wildcards(*, ?) and character classes like
> [a-z]. But perf record only allow wildcards. So I can't use strisglob()
> function.

Oops, right. Hmm, Jiri, can we support full glob matching for events?
(or what happen if we use it?)

> 
> Please let me know if that is wrong.
> 
> >> +}
> >> +
> >> +static bool sdt_name_match(struct perf_probe_event *pev,
> >> + struct probe_trace_event *tev)
> >> +{
> >> +  if (sdt_is_ptrn_used(pev))
> >> +  return strglobmatch(tev->group, pev->group) &&
> >> +  strglobmatch(tev->event, pev->event);
> >> +
> >> +  return !strcmp(tev->group, pev->group) &&
> >> +  !strcmp(tev->event, pev->event);
> > Would we really need these two? Since strglobmatch() accepts a string
> > without wildcard, you don't need strcmp() version...
> 
> Hmm. yes, second part looks unnecessary.
> 
> >> +}
> >> +
> >> +static void sdt_warn_multi_events(int ctr, struct perf_probe_event *pev)
> >> +{
> >> +  pr_warning("Warning: Recording on %d occurrences of %s:%s\n",
> >> + ctr, pev->group, pev->event);
> > Could you show what event will be recorded instead of just showing 
> > the number of events?
> 
> Sure. I'll remove this warning and show all events as 'event addr@file'.
> Please let me know if you want to list it differently.
> 
> Actually, I do that, but partially. Please see patch 6/7. It list all those
> *existing* events which are being recorded.

OK, that will be enough for users to warn.

[SNIP]
> >> @@ -3606,23 +3727,37 @@ int add_sdt_event(char *event, struct list_head 
> >> *sdt_evlist)
> >>probe_conf.max_probes = MAX_PROBES;
> >>probe_conf.force_add = 1;
> >>  
> >> +  /* Fetch all sdt events from uprobe_events */
> >> +  exst_ntevs = probe_file__get_sdt_events(_tevs);
> >> +  if (exst_ntevs < 0) {
> >> +  ret = exst_ntevs;
> >> +  goto free_pev;
> >> +  }
> >> +
> >> +  /* Check if events with same name already exists in uprobe_events. */
> >> +  ret = sdt_event_probepoint_exists(pev, exst_tevs,
> >> +   exst_ntevs, sdt_evlist);
> >> +  if (ret) {
> >> +  ret = ret > 0 ? 0 : ret;
> >> +  goto free_pev;
> >> +  }
> >> +
> >>/* Fetch all matching events from cache. */
> >>ret = get_sdt_events_from_cache(pev);
> >>if (ret < 0)
> >>goto free_pev;
> > Hmm, IMHO, you'd better call get_sdt_events_from_cache() first, and
> > check the existence of those events afterwards. Then you may not
> > need the "shift" function.
> 
> "shift" function is needed. let me explain.
> 
> As we are allowing both, 'perf probe' as well as 'perf record' on SDT
> events, there are two sources of events for 'perf record'
>   1. uprobe_events file
>   2. probe-cache
> 
> When perf fetches events from cache, it fetch all matching events,
> no matter if any event already exists in uprobe_events or not.
> 
> Consider an example, There are 3 events with same name sdt_a:b
> exists in 'test' binary.
> 
>   $ readelf -n test
> sdt_a:b @ addr 0x123
> sdt_a:b @ addr 0x456
> sdt_a:b @ addr 0x789
> 
>   $ perf probe -x test sdt_a:b
>  /* Add all 3 events sdt_a:b  sdt_a:b_1 and sdt_a:b_2 */
>   $ perf probe -d sdt_a:b
>   $ perf probe -d sdt_a:b_2
> 
>   $ perf record sdt_a:b
> /*
>   arr1 = probe_file__get_sdt_events();
>  {sdt_a:b_1 addr 0x456}
> 
>   arr2 = get_sdt_events_from_cache();
>  {sdt_a:b addr 0x123, sdt_a:b addr 0x456, sdt_a:b addr 0x789}
> 
>   Now, as sdt event of addr 0x456 already exists in arr1, it needs to
>   be reused and thus it needs to be removed from arr2. Removing
>   2nd element needs shifting of third element to 2nd position.
> */

Ah, I see. In that case, you can just set the tev->point.symbol = NULL,
then it is just skipped to apply in __add_probe_trace_events().

So what you need to do is, 1) get_sdt_events_from_cache(pev); and
2) set tev[x].point.symbol = NULL in sdt_event_probepoint_exists().
(I also recommend to release tev[x].event and group, then you can
 easilly find what events should be removed afterwards)

Thank you,



> 
> I don't think it's easy to remove "shift" function. I can remove it but
> that needs changes in existing infrastructure like fetch only those
> events from cache which are not present in uprobe_events. But,
> IMHO, it's not a good way to go.
> 
> Let me know if I misunderstood your point.
> 
> 

Re: [PATCH 4.10 00/63] 4.10.5-stable review

[Greg Kroah-Hartman]

On Mon, Mar 20, 2017 at 07:14:30PM -0700, Guenter Roeck wrote:
> On 03/20/2017 10:51 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.5 release.
> > There are 63 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Mar 22 17:47:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.10 00/63] 4.10.5-stable review

[Greg Kroah-Hartman]

On Mon, Mar 20, 2017 at 07:14:30PM -0700, Guenter Roeck wrote:
> On 03/20/2017 10:51 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.5 release.
> > There are 63 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Mar 22 17:47:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h

Re: lockdep warning: console vs. mem hotplug

[Sergey Senozhatsky]

Cc Michal, Linus, Peter, Thomas, Andrew, Martin


// I kept only lockdep splats from the original report and cut off .configs
// full version:
// lkml.kernel.org/r/alpine.LFD.2.20.1703201736070.1753@schleppi

Sebastian, thanks.


On (03/20/17 17:43), Sebastian Ott wrote:
[..]
> Since commit f975237b7682 ("printk: use printk_safe buffers in printk")
> I observe lockdep warnings on s390 when doing memory hotplug:
> 
> [  132.379220] ==
> [  132.379220] [ INFO: possible circular locking dependency detected ]
> [  132.379221] 4.11.0-rc3 #330 Not tainted
> [  132.379221] ---
> [  132.379222] sh/708 is trying to acquire lock:
> [  132.379222]  (&(_con_lock)->rlock){-.-...}, at: [<0074524a>] 
> sclp_console_write+0x4a/0x2b8
> [  132.379224]
> [  132.379224] but task is already holding lock:
> [  132.379224]  (&(>lock)->rlock){..-...}, at: [<002a65a8>] 
> __offline_isolated_pages+0xe0/0x340
> [  132.379226]
> [  132.379227] which lock already depends on the new lock.
> [  132.379227]
> [  132.379227]
> [  132.379228] the existing dependency chain (in reverse order) is:
> [  132.379228]
> [  132.379229] -> #2 (&(>lock)->rlock){..-...}:
> [  132.379230]validate_chain.isra.22+0xb36/0xd18
> [  132.379231]__lock_acquire+0x650/0x880
> [  132.379231]lock_acquire+0x24e/0x2b0
> [  132.379232]_raw_spin_lock_irqsave+0x70/0xb8
> [  132.379232]get_page_from_freelist+0x548/0xf30
> [  132.379233]__alloc_pages_nodemask+0x1c8/0x14c0
> [  132.379233]allocate_slab+0xde/0x668
> [  132.379233]new_slab+0x94/0xa8
> [  132.379234]___slab_alloc.constprop.66+0x556/0x578
> [  132.379234]__slab_alloc.isra.62.constprop.65+0x74/0xa8
> [  132.379235]kmem_cache_alloc+0x136/0x4b8
> [  132.379235]__debug_object_init+0xaa/0x448
> [  132.379236]debug_object_activate+0x182/0x238
> [  132.379236]mod_timer+0xe6/0x450
> [  132.379236]prandom_reseed+0x44/0x50
> [  132.379237]do_one_initcall+0xa2/0x150
> [  132.379237]kernel_init_freeable+0x228/0x2d8
> [  132.379238]kernel_init+0x2a/0x138
> [  132.379238]kernel_thread_starter+0x6/0xc
> [  132.379239]kernel_thread_starter+0x0/0xc
> [  132.379239]
> [  132.379239] -> #1 (&(>lock)->rlock){-.-.-.}:
> [  132.379241]validate_chain.isra.22+0xb36/0xd18
> [  132.379242]__lock_acquire+0x650/0x880
> [  132.379242]lock_acquire+0x24e/0x2b0
> [  132.379242]_raw_spin_lock_irqsave+0x70/0xb8
> [  132.379243]lock_timer_base+0x78/0xa8
> [  132.379243]mod_timer+0xba/0x450
> [  132.379244]sclp_console_write+0x262/0x2b8
> [  132.379244]console_unlock+0x4a6/0x658
> [  132.379245]register_console+0x31c/0x430
> [  132.379245]sclp_console_init+0x152/0x170
> [  132.379245]console_init+0x3a/0x58
> [  132.379246]start_kernel+0x350/0x480
> [  132.379246]_stext+0x20/0x80
> [  132.379246]
> [  132.379247] -> #0 (&(_con_lock)->rlock){-.-...}:
> [  132.379249]check_prev_add+0x150/0x648
> [  132.379249]validate_chain.isra.22+0xb36/0xd18
> [  132.379249]__lock_acquire+0x650/0x880
> [  132.379250]lock_acquire+0x24e/0x2b0
> [  132.379250]_raw_spin_lock_irqsave+0x70/0xb8
> [  132.379251]sclp_console_write+0x4a/0x2b8
> [  132.379251]console_unlock+0x4a6/0x658
> [  132.379252]vprintk_emit+0x33e/0x350
> [  132.379252]vprintk_default+0x44/0x58
> [  132.379252]printk+0x4e/0x58
> [  132.379253]__offline_isolated_pages+0x1a0/0x340
> [  132.379253]offline_isolated_pages_cb+0x2e/0x40
> [  132.379254]walk_system_ram_range+0x96/0xe8
> [  132.379254]__offline_pages.constprop.43+0x6da/0x918
> [  132.379255]memory_subsys_offline+0x6a/0xa0
> [  132.379255]device_offline+0x84/0xd8
> [  132.379255]store_mem_state+0xfe/0x120
> [  132.379256]kernfs_fop_write+0x126/0x1d0
> [  132.379256]__vfs_write+0x46/0x140
> [  132.379257]vfs_write+0xb8/0x1a8
> [  132.379257]SyS_write+0x66/0xc0
> [  132.379257]system_call+0xc4/0x240
> [  132.379258]
> [  132.379258] other info that might help us debug this:
> [  132.379258]
> [  132.379259] Chain exists of:
> [  132.379259]   &(_con_lock)->rlock --> &(>lock)->rlock --> 
> &(>lock)->rlock
> [  132.379262]
> [  132.379262]  Possible unsafe locking scenario:
> [  132.379262]
> [  132.379263]CPU0CPU1
> [  132.379263]
> [  132.379264]   lock(&(>lock)->rlock);
> [  132.379265]lock(&(>lock)->rlock);
> [  132.379266]lock(&(>lock)->rlock);
> [  132.379267]   lock(&(_con_lock)->rlock);


after a rather quick look.


as far as I understand it, the problem here 

Re: lockdep warning: console vs. mem hotplug

[Sergey Senozhatsky]

Cc Michal, Linus, Peter, Thomas, Andrew, Martin


// I kept only lockdep splats from the original report and cut off .configs
// full version:
// lkml.kernel.org/r/alpine.LFD.2.20.1703201736070.1753@schleppi

Sebastian, thanks.


On (03/20/17 17:43), Sebastian Ott wrote:
[..]
> Since commit f975237b7682 ("printk: use printk_safe buffers in printk")
> I observe lockdep warnings on s390 when doing memory hotplug:
> 
> [  132.379220] ==
> [  132.379220] [ INFO: possible circular locking dependency detected ]
> [  132.379221] 4.11.0-rc3 #330 Not tainted
> [  132.379221] ---
> [  132.379222] sh/708 is trying to acquire lock:
> [  132.379222]  (&(_con_lock)->rlock){-.-...}, at: [<0074524a>] 
> sclp_console_write+0x4a/0x2b8
> [  132.379224]
> [  132.379224] but task is already holding lock:
> [  132.379224]  (&(>lock)->rlock){..-...}, at: [<002a65a8>] 
> __offline_isolated_pages+0xe0/0x340
> [  132.379226]
> [  132.379227] which lock already depends on the new lock.
> [  132.379227]
> [  132.379227]
> [  132.379228] the existing dependency chain (in reverse order) is:
> [  132.379228]
> [  132.379229] -> #2 (&(>lock)->rlock){..-...}:
> [  132.379230]validate_chain.isra.22+0xb36/0xd18
> [  132.379231]__lock_acquire+0x650/0x880
> [  132.379231]lock_acquire+0x24e/0x2b0
> [  132.379232]_raw_spin_lock_irqsave+0x70/0xb8
> [  132.379232]get_page_from_freelist+0x548/0xf30
> [  132.379233]__alloc_pages_nodemask+0x1c8/0x14c0
> [  132.379233]allocate_slab+0xde/0x668
> [  132.379233]new_slab+0x94/0xa8
> [  132.379234]___slab_alloc.constprop.66+0x556/0x578
> [  132.379234]__slab_alloc.isra.62.constprop.65+0x74/0xa8
> [  132.379235]kmem_cache_alloc+0x136/0x4b8
> [  132.379235]__debug_object_init+0xaa/0x448
> [  132.379236]debug_object_activate+0x182/0x238
> [  132.379236]mod_timer+0xe6/0x450
> [  132.379236]prandom_reseed+0x44/0x50
> [  132.379237]do_one_initcall+0xa2/0x150
> [  132.379237]kernel_init_freeable+0x228/0x2d8
> [  132.379238]kernel_init+0x2a/0x138
> [  132.379238]kernel_thread_starter+0x6/0xc
> [  132.379239]kernel_thread_starter+0x0/0xc
> [  132.379239]
> [  132.379239] -> #1 (&(>lock)->rlock){-.-.-.}:
> [  132.379241]validate_chain.isra.22+0xb36/0xd18
> [  132.379242]__lock_acquire+0x650/0x880
> [  132.379242]lock_acquire+0x24e/0x2b0
> [  132.379242]_raw_spin_lock_irqsave+0x70/0xb8
> [  132.379243]lock_timer_base+0x78/0xa8
> [  132.379243]mod_timer+0xba/0x450
> [  132.379244]sclp_console_write+0x262/0x2b8
> [  132.379244]console_unlock+0x4a6/0x658
> [  132.379245]register_console+0x31c/0x430
> [  132.379245]sclp_console_init+0x152/0x170
> [  132.379245]console_init+0x3a/0x58
> [  132.379246]start_kernel+0x350/0x480
> [  132.379246]_stext+0x20/0x80
> [  132.379246]
> [  132.379247] -> #0 (&(_con_lock)->rlock){-.-...}:
> [  132.379249]check_prev_add+0x150/0x648
> [  132.379249]validate_chain.isra.22+0xb36/0xd18
> [  132.379249]__lock_acquire+0x650/0x880
> [  132.379250]lock_acquire+0x24e/0x2b0
> [  132.379250]_raw_spin_lock_irqsave+0x70/0xb8
> [  132.379251]sclp_console_write+0x4a/0x2b8
> [  132.379251]console_unlock+0x4a6/0x658
> [  132.379252]vprintk_emit+0x33e/0x350
> [  132.379252]vprintk_default+0x44/0x58
> [  132.379252]printk+0x4e/0x58
> [  132.379253]__offline_isolated_pages+0x1a0/0x340
> [  132.379253]offline_isolated_pages_cb+0x2e/0x40
> [  132.379254]walk_system_ram_range+0x96/0xe8
> [  132.379254]__offline_pages.constprop.43+0x6da/0x918
> [  132.379255]memory_subsys_offline+0x6a/0xa0
> [  132.379255]device_offline+0x84/0xd8
> [  132.379255]store_mem_state+0xfe/0x120
> [  132.379256]kernfs_fop_write+0x126/0x1d0
> [  132.379256]__vfs_write+0x46/0x140
> [  132.379257]vfs_write+0xb8/0x1a8
> [  132.379257]SyS_write+0x66/0xc0
> [  132.379257]system_call+0xc4/0x240
> [  132.379258]
> [  132.379258] other info that might help us debug this:
> [  132.379258]
> [  132.379259] Chain exists of:
> [  132.379259]   &(_con_lock)->rlock --> &(>lock)->rlock --> 
> &(>lock)->rlock
> [  132.379262]
> [  132.379262]  Possible unsafe locking scenario:
> [  132.379262]
> [  132.379263]CPU0CPU1
> [  132.379263]
> [  132.379264]   lock(&(>lock)->rlock);
> [  132.379265]lock(&(>lock)->rlock);
> [  132.379266]lock(&(>lock)->rlock);
> [  132.379267]   lock(&(_con_lock)->rlock);


after a rather quick look.


as far as I understand it, the problem here 

Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

[Michael Zoran]

On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> Michael Zoran  writes:
> 
> > > > Since the API is completely documented, I see no reason we or
> > > > anybody
> > > > couldn't essentially rewrite the driver while it's in
> > > > staging.  I
> > > > just
> > > > think it would be best for everyone if the new version was a
> > > > drop
> > > > in
> > > > replacement for the original version.  Essential an enhancement
> > > > rather
> > > > then a competitor.
> > > 
> > > I think my comments weren't fundamental changes, but you surely
> > > mean
> > > the devicetree ABI? I like to see this driver ASAP out of staging
> > > and
> > > i'm not interested to maintain 2 functional identical driver only
> > > to
> > > keep compability with the Foundation tree. Currently i'm afraid
> > > that
> > > we build up many drivers in staging, which need a complete
> > > rewrite
> > > later if they should come out of staging. It would be nice if we
> > > could avoid the situation we have with the thermal driver.
> > > 
> > > Stefan
> > 
> > The API I'm talking about here is the mailbox API that is used to
> > talk
> > to the firmware.  The numbers and structures to pass are
> > documented. 
> > Nothing prevents anybody from rewriting this driver and submitting
> > it
> > to the appropriate subsystems.  It's certainly small enough.
> > 
> > If you really want working thermal or cpu speed drivers today,
> > nothing
> > stops anybody from submitting the downstream drivers after doing
> > some
> > minor touchups and submitting them to staging.  That would at least
> > get
> > things working while people argue about what the correct DT nodes
> > should be.
> > 
> > I would also like to point out that the RPI 3 has been out for over
> > a
> > year and nobody has been able to get working video out of it
> > through
> > VC4 on a mainline tree.  At least until now.  So I'm not sure the
> > best
> > way to go is for the expander driver to go under the GPIO subtree.
> 
> Excuse me?  Display works fine on my Pi3.  VC4 uses DDC to probe for
> connection when the GPIO line isn't present in the DT.

Just a FYI, Eric Anholt has offically announced support for VC4 for
HDMI on mainline Linus build without any support from the expander on
the RPI 3.  

Sounds like this particular driver isn't needed then, correct?

Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

[Michael Zoran]

On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> Michael Zoran  writes:
> 
> > > > Since the API is completely documented, I see no reason we or
> > > > anybody
> > > > couldn't essentially rewrite the driver while it's in
> > > > staging.  I
> > > > just
> > > > think it would be best for everyone if the new version was a
> > > > drop
> > > > in
> > > > replacement for the original version.  Essential an enhancement
> > > > rather
> > > > then a competitor.
> > > 
> > > I think my comments weren't fundamental changes, but you surely
> > > mean
> > > the devicetree ABI? I like to see this driver ASAP out of staging
> > > and
> > > i'm not interested to maintain 2 functional identical driver only
> > > to
> > > keep compability with the Foundation tree. Currently i'm afraid
> > > that
> > > we build up many drivers in staging, which need a complete
> > > rewrite
> > > later if they should come out of staging. It would be nice if we
> > > could avoid the situation we have with the thermal driver.
> > > 
> > > Stefan
> > 
> > The API I'm talking about here is the mailbox API that is used to
> > talk
> > to the firmware.  The numbers and structures to pass are
> > documented. 
> > Nothing prevents anybody from rewriting this driver and submitting
> > it
> > to the appropriate subsystems.  It's certainly small enough.
> > 
> > If you really want working thermal or cpu speed drivers today,
> > nothing
> > stops anybody from submitting the downstream drivers after doing
> > some
> > minor touchups and submitting them to staging.  That would at least
> > get
> > things working while people argue about what the correct DT nodes
> > should be.
> > 
> > I would also like to point out that the RPI 3 has been out for over
> > a
> > year and nobody has been able to get working video out of it
> > through
> > VC4 on a mainline tree.  At least until now.  So I'm not sure the
> > best
> > way to go is for the expander driver to go under the GPIO subtree.
> 
> Excuse me?  Display works fine on my Pi3.  VC4 uses DDC to probe for
> connection when the GPIO line isn't present in the DT.

Just a FYI, Eric Anholt has offically announced support for VC4 for
HDMI on mainline Linus build without any support from the expander on
the RPI 3.  

Sounds like this particular driver isn't needed then, correct?

Re: [PATCH 4.10 00/63] 4.10.5-stable review

[Greg Kroah-Hartman]

On Mon, Mar 20, 2017 at 06:13:13PM -0600, Shuah Khan wrote:
> On 03/20/2017 11:51 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.5 release.
> > There are 63 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Mar 22 17:47:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.5-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.10 00/63] 4.10.5-stable review

[Greg Kroah-Hartman]

On Mon, Mar 20, 2017 at 06:13:13PM -0600, Shuah Khan wrote:
> On 03/20/2017 11:51 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.5 release.
> > There are 63 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Mar 22 17:47:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.5-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH] KVM: nVMX: Fix L2 guest crash when VPID is disabled on L0

[Wanpeng Li]

2017-03-20 22:58 GMT+08:00 Radim Krčmář :
> 2017-03-20 05:25-0700, Wanpeng Li:
>> From: Wanpeng Li 
>>
>> L2 guest crash during boot if VPID is enabled on L1 and disabled on L0. This
>> also can be catched by kvm-unit-tests/vmx.flat when VPID is disabled on L0.
>>
>> KVM: entry failed, hardware error 0x7
>> EAX= EBX= ECX= EDX=000306c3
>> ESI= EDI= EBP= ESP=
>> EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
>> ES =   9300
>> CS =f000   9b00
>> SS =   9300
>> DS =   9300
>> FS =   9300
>> GS =   9300
>> LDT=   8200
>> TR =   8b00
>> GDT=  
>> IDT=  
>> CR0=6010 CR2= CR3= CR4=
>> DR0= DR1= DR2= 
>> DR3=
>> DR6=0ff0 DR7=0400
>> EFER=
>
> I couldn't reproduce the hardware error.  Unit test just got #UD and
> exited, which seems to be because KVM doesn't add the exec controls in
> vmcs02.

I fix this unit test #UD in v2 1/3, and the above crash in v2 2/3.

>
>> The enable_vpid sysfs perm parameter miss the 0 prefix, so the enable_vpid
>> is failed to be disabled though vmcs_config bit is not set. This patch fixes
>> it by utilizing S_IRUGO which includes 0 prefix instead.
>>
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/kvm/vmx.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 98e82ee..a7e4880 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -66,7 +66,7 @@ static const struct x86_cpu_id vmx_cpu_id[] = {
>>  MODULE_DEVICE_TABLE(x86cpu, vmx_cpu_id);
>>
>>  static bool __read_mostly enable_vpid = 1;
>> -module_param_named(vpid, enable_vpid, bool, 0444);
>> +module_param_named(vpid, enable_vpid, bool, S_IRUGO);
>
> Aren't "0444" and "(00400 | 00040 | 4)" the same number?
>
> I'm not convinced this patch fixes anything and I think we have two

Yeah, maybe I'm too tired yesterday and more coffee is really appreciated. :)

> options when approaching VPID:
>  1) hide and forbid VPIDs in L1 if they are disabled on L0
>  2) expose VPID hardware to L1 regardless of L0 settings
>
> We treat other features like (1), because it simplifies implementation,
> so I'd do the same for VPID ...

Good point. Please review v2. :)

Regards,
Wanpeng Li

Re: [PATCH] KVM: nVMX: Fix L2 guest crash when VPID is disabled on L0

[Wanpeng Li]

2017-03-20 22:58 GMT+08:00 Radim Krčmář :
> 2017-03-20 05:25-0700, Wanpeng Li:
>> From: Wanpeng Li 
>>
>> L2 guest crash during boot if VPID is enabled on L1 and disabled on L0. This
>> also can be catched by kvm-unit-tests/vmx.flat when VPID is disabled on L0.
>>
>> KVM: entry failed, hardware error 0x7
>> EAX= EBX= ECX= EDX=000306c3
>> ESI= EDI= EBP= ESP=
>> EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
>> ES =   9300
>> CS =f000   9b00
>> SS =   9300
>> DS =   9300
>> FS =   9300
>> GS =   9300
>> LDT=   8200
>> TR =   8b00
>> GDT=  
>> IDT=  
>> CR0=6010 CR2= CR3= CR4=
>> DR0= DR1= DR2= 
>> DR3=
>> DR6=0ff0 DR7=0400
>> EFER=
>
> I couldn't reproduce the hardware error.  Unit test just got #UD and
> exited, which seems to be because KVM doesn't add the exec controls in
> vmcs02.

I fix this unit test #UD in v2 1/3, and the above crash in v2 2/3.

>
>> The enable_vpid sysfs perm parameter miss the 0 prefix, so the enable_vpid
>> is failed to be disabled though vmcs_config bit is not set. This patch fixes
>> it by utilizing S_IRUGO which includes 0 prefix instead.
>>
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/kvm/vmx.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 98e82ee..a7e4880 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -66,7 +66,7 @@ static const struct x86_cpu_id vmx_cpu_id[] = {
>>  MODULE_DEVICE_TABLE(x86cpu, vmx_cpu_id);
>>
>>  static bool __read_mostly enable_vpid = 1;
>> -module_param_named(vpid, enable_vpid, bool, 0444);
>> +module_param_named(vpid, enable_vpid, bool, S_IRUGO);
>
> Aren't "0444" and "(00400 | 00040 | 4)" the same number?
>
> I'm not convinced this patch fixes anything and I think we have two

Yeah, maybe I'm too tired yesterday and more coffee is really appreciated. :)

> options when approaching VPID:
>  1) hide and forbid VPIDs in L1 if they are disabled on L0
>  2) expose VPID hardware to L1 regardless of L0 settings
>
> We treat other features like (1), because it simplifies implementation,
> so I'd do the same for VPID ...

Good point. Please review v2. :)

Regards,
Wanpeng Li

[PATCH v2 1/3] KVM: nVMX: Fix nested VPID vmx exec control

[Wanpeng Li]

From: Wanpeng Li 

This can be reproduced by running kvm-unit-tests/vmx.flat on L0 w/ vpid 
disabled.

Test suite: VPID
Unhandled exception 6 #UD at ip 004051a6
error_code=  rflags=00010047  cs=0008
rax= rcx=0001 rdx=0047 
rbx=00402f79
rbp=00456240 rsi=0001 rdi=
r8=000a  r9=03f8 r10=80010011 
r11=
r12=0003 r13=0708 r14= 
r15=
cr0=80010031 cr2= cr3=07fff000 
cr4=2020
cr8=
STACK: @4051a6 40523e 400f7f 402059 40028f

We should hide and forbid VPID in L1 if it is disabled on L0. However, nested 
VPID
enable bit is set unconditionally during setup nested vmx exec controls though 
VPID 
is not exposed through nested VMX capablity. This patch fixes it by don't set 
nested 
VPID enable bit if it is disabled on L0.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Fixes: 5c614b3583e (KVM: nVMX: nested VPID emulation)
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 98e82ee..8795a70 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2753,7 +2753,6 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
*vmx)
SECONDARY_EXEC_RDTSCP |
SECONDARY_EXEC_DESC |
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
-   SECONDARY_EXEC_ENABLE_VPID |
SECONDARY_EXEC_APIC_REGISTER_VIRT |
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
SECONDARY_EXEC_WBINVD_EXITING |
@@ -2781,10 +2780,12 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
*vmx)
 * though it is treated as global context.  The alternative is
 * not failing the single-context invvpid, and it is worse.
 */
-   if (enable_vpid)
+   if (enable_vpid) {
+   vmx->nested.nested_vmx_secondary_ctls_high |=
+   SECONDARY_EXEC_ENABLE_VPID;
vmx->nested.nested_vmx_vpid_caps = VMX_VPID_INVVPID_BIT |
VMX_VPID_EXTENT_SUPPORTED_MASK;
-   else
+   } else
vmx->nested.nested_vmx_vpid_caps = 0;
 
if (enable_unrestricted_guest)
-- 
2.7.4

[PATCH v2 1/3] KVM: nVMX: Fix nested VPID vmx exec control

[Wanpeng Li]

From: Wanpeng Li 

This can be reproduced by running kvm-unit-tests/vmx.flat on L0 w/ vpid 
disabled.

Test suite: VPID
Unhandled exception 6 #UD at ip 004051a6
error_code=  rflags=00010047  cs=0008
rax= rcx=0001 rdx=0047 
rbx=00402f79
rbp=00456240 rsi=0001 rdi=
r8=000a  r9=03f8 r10=80010011 
r11=
r12=0003 r13=0708 r14= 
r15=
cr0=80010031 cr2= cr3=07fff000 
cr4=2020
cr8=
STACK: @4051a6 40523e 400f7f 402059 40028f

We should hide and forbid VPID in L1 if it is disabled on L0. However, nested 
VPID
enable bit is set unconditionally during setup nested vmx exec controls though 
VPID 
is not exposed through nested VMX capablity. This patch fixes it by don't set 
nested 
VPID enable bit if it is disabled on L0.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Fixes: 5c614b3583e (KVM: nVMX: nested VPID emulation)
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 98e82ee..8795a70 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2753,7 +2753,6 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
*vmx)
SECONDARY_EXEC_RDTSCP |
SECONDARY_EXEC_DESC |
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
-   SECONDARY_EXEC_ENABLE_VPID |
SECONDARY_EXEC_APIC_REGISTER_VIRT |
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
SECONDARY_EXEC_WBINVD_EXITING |
@@ -2781,10 +2780,12 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
*vmx)
 * though it is treated as global context.  The alternative is
 * not failing the single-context invvpid, and it is worse.
 */
-   if (enable_vpid)
+   if (enable_vpid) {
+   vmx->nested.nested_vmx_secondary_ctls_high |=
+   SECONDARY_EXEC_ENABLE_VPID;
vmx->nested.nested_vmx_vpid_caps = VMX_VPID_INVVPID_BIT |
VMX_VPID_EXTENT_SUPPORTED_MASK;
-   else
+   } else
vmx->nested.nested_vmx_vpid_caps = 0;
 
if (enable_unrestricted_guest)
-- 
2.7.4

[PATCH v2 3/3] KVM: x86: correct async page present tracepoint

[Wanpeng Li]

From: Wanpeng Li 

After async pf setup successfully, there is a broadcast wakeup w/ special 
token 0x which tells vCPU that it should wake up all processes 
waiting for APFs though there is no real process waiting at the moment.

The async page present tracepoint print prematurely and fails to catch the 
special token setup. This patch fixes it by moving the async page present 
tracepoint after the special token setup.

Before patch:

qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 0x0 
gva 0x0

After patch:

qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 
0x gva 0x0

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1faf620..e27eb7f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8566,11 +8566,11 @@ void kvm_arch_async_page_present(struct kvm_vcpu *vcpu,
 {
struct x86_exception fault;
 
-   trace_kvm_async_pf_ready(work->arch.token, work->gva);
if (work->wakeup_all)
work->arch.token = ~0; /* broadcast wakeup */
else
kvm_del_async_pf_gfn(vcpu, work->arch.gfn);
+   trace_kvm_async_pf_ready(work->arch.token, work->gva);
 
if ((vcpu->arch.apf.msr_val & KVM_ASYNC_PF_ENABLED) &&
!apf_put_user(vcpu, KVM_PV_REASON_PAGE_READY)) {
-- 
2.7.4

[PATCH v2 3/3] KVM: x86: correct async page present tracepoint

[Wanpeng Li]

From: Wanpeng Li 

After async pf setup successfully, there is a broadcast wakeup w/ special 
token 0x which tells vCPU that it should wake up all processes 
waiting for APFs though there is no real process waiting at the moment.

The async page present tracepoint print prematurely and fails to catch the 
special token setup. This patch fixes it by moving the async page present 
tracepoint after the special token setup.

Before patch:

qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 0x0 
gva 0x0

After patch:

qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 
0x gva 0x0

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1faf620..e27eb7f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8566,11 +8566,11 @@ void kvm_arch_async_page_present(struct kvm_vcpu *vcpu,
 {
struct x86_exception fault;
 
-   trace_kvm_async_pf_ready(work->arch.token, work->gva);
if (work->wakeup_all)
work->arch.token = ~0; /* broadcast wakeup */
else
kvm_del_async_pf_gfn(vcpu, work->arch.gfn);
+   trace_kvm_async_pf_ready(work->arch.token, work->gva);
 
if ((vcpu->arch.apf.msr_val & KVM_ASYNC_PF_ENABLED) &&
!apf_put_user(vcpu, KVM_PV_REASON_PAGE_READY)) {
-- 
2.7.4

[PATCH v2 2/3] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

[Wanpeng Li]

From: Wanpeng Li 

This can be reproduced by running L2 on L1, and disable VPID on L0 if w/o 
commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 crash as below:

KVM: entry failed, hardware error 0x7
EAX= EBX= ECX= EDX=000306c3
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   9300
CS =f000   9b00
SS =   9300
DS =   9300
FS =   9300
GS =   9300
LDT=   8200
TR =   8b00
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2= 
DR3= 
DR6=0ff0 DR7=0400
EFER=

Reference SDM 30.3 INVVPID:
 
Protected Mode Exceptions
#UD 
  - If not in VMX operation.
  - If the logical processor does not support VPIDs 
(IA32_VMX_PROCBASED_CTLS2[37]=0).
  - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) 
but does 
not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).

So we should check both VPID enable bit in vmx exec control and INVVPID support 
bit 
in vmx capability MSRs to enable VPID. This patch adds the guarantee to not 
enable VPID
if INVVPID is not exposed in vmx capability MSRs.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 06d8080..b310214 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
 }
 
+static inline bool cpu_has_vmx_invvpid(void)
+{
+   return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
+}
+
 static inline bool cpu_has_vmx_ept(void)
 {
return vmcs_config.cpu_based_2nd_exec_ctrl &
@@ -6519,8 +6524,10 @@ static __init int hardware_setup(void)
if (boot_cpu_has(X86_FEATURE_NX))
kvm_enable_efer_bits(EFER_NX);
 
-   if (!cpu_has_vmx_vpid())
+   if (!cpu_has_vmx_vpid() ||
+   !(cpu_has_vmx_invvpid()))
enable_vpid = 0;
+
if (!cpu_has_vmx_shadow_vmcs())
enable_shadow_vmcs = 0;
if (enable_shadow_vmcs)
-- 
2.7.4

[PATCH v2 2/3] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

[Wanpeng Li]

From: Wanpeng Li 

This can be reproduced by running L2 on L1, and disable VPID on L0 if w/o 
commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 crash as below:

KVM: entry failed, hardware error 0x7
EAX= EBX= ECX= EDX=000306c3
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   9300
CS =f000   9b00
SS =   9300
DS =   9300
FS =   9300
GS =   9300
LDT=   8200
TR =   8b00
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2= 
DR3= 
DR6=0ff0 DR7=0400
EFER=

Reference SDM 30.3 INVVPID:
 
Protected Mode Exceptions
#UD 
  - If not in VMX operation.
  - If the logical processor does not support VPIDs 
(IA32_VMX_PROCBASED_CTLS2[37]=0).
  - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) 
but does 
not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).

So we should check both VPID enable bit in vmx exec control and INVVPID support 
bit 
in vmx capability MSRs to enable VPID. This patch adds the guarantee to not 
enable VPID
if INVVPID is not exposed in vmx capability MSRs.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 06d8080..b310214 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
 }
 
+static inline bool cpu_has_vmx_invvpid(void)
+{
+   return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
+}
+
 static inline bool cpu_has_vmx_ept(void)
 {
return vmcs_config.cpu_based_2nd_exec_ctrl &
@@ -6519,8 +6524,10 @@ static __init int hardware_setup(void)
if (boot_cpu_has(X86_FEATURE_NX))
kvm_enable_efer_bits(EFER_NX);
 
-   if (!cpu_has_vmx_vpid())
+   if (!cpu_has_vmx_vpid() ||
+   !(cpu_has_vmx_invvpid()))
enable_vpid = 0;
+
if (!cpu_has_vmx_shadow_vmcs())
enable_shadow_vmcs = 0;
if (enable_shadow_vmcs)
-- 
2.7.4

[PATCH net-next 7/8] vhost_net: try batch dequing from skb array

[Jason Wang]

We used to dequeue one skb during recvmsg() from skb_array, this could
be inefficient because of the bad cache utilization and spinlock
touching for each packet. This patch tries to batch them by calling
batch dequeuing helpers explicitly on the exported skb array and pass
the skb back through msg_control for underlayer socket to finish the
userspace copying.

Tests were done by XDP1:
- small buffer:
  Before: 1.88Mpps
  After : 2.25Mpps (+19.6%)
- mergeable buffer:
  Before: 1.83Mpps
  After : 2.10Mpps (+14.7%)

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 64 +
 1 file changed, 60 insertions(+), 4 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 9b51989..53f09f2 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -85,6 +87,7 @@ struct vhost_net_ubuf_ref {
struct vhost_virtqueue *vq;
 };
 
+#define VHOST_RX_BATCH 64
 struct vhost_net_virtqueue {
struct vhost_virtqueue vq;
size_t vhost_hlen;
@@ -99,6 +102,10 @@ struct vhost_net_virtqueue {
/* Reference counting for outstanding ubufs.
 * Protected by vq mutex. Writers must also take device mutex. */
struct vhost_net_ubuf_ref *ubufs;
+   struct skb_array *rx_array;
+   void *rxq[VHOST_RX_BATCH];
+   int rt;
+   int rh;
 };
 
 struct vhost_net {
@@ -201,6 +208,8 @@ static void vhost_net_vq_reset(struct vhost_net *n)
n->vqs[i].ubufs = NULL;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+   n->vqs[i].rt = 0;
+   n->vqs[i].rh = 0;
}
 
 }
@@ -503,13 +512,30 @@ static void handle_tx(struct vhost_net *net)
mutex_unlock(>mutex);
 }
 
-static int peek_head_len(struct sock *sk)
+static int peek_head_len_batched(struct vhost_net_virtqueue *rvq)
+{
+   if (rvq->rh != rvq->rt)
+   goto out;
+
+   rvq->rh = rvq->rt = 0;
+   rvq->rt = skb_array_consume_batched_bh(rvq->rx_array, rvq->rxq,
+   VHOST_RX_BATCH);
+   if (!rvq->rt)
+   return 0;
+out:
+   return __skb_array_len_with_tag(rvq->rxq[rvq->rh]);
+}
+
+static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)
 {
struct socket *sock = sk->sk_socket;
struct sk_buff *head;
int len = 0;
unsigned long flags;
 
+   if (rvq->rx_array)
+   return peek_head_len_batched(rvq);
+
if (sock->ops->peek_len)
return sock->ops->peek_len(sock);
 
@@ -535,12 +561,14 @@ static int sk_has_rx_data(struct sock *sk)
return skb_queue_empty(>sk_receive_queue);
 }
 
-static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
+static int vhost_net_rx_peek_head_len(struct vhost_net *net,
+ struct sock *sk)
 {
+   struct vhost_net_virtqueue *rvq = >vqs[VHOST_NET_VQ_RX];
struct vhost_net_virtqueue *nvq = >vqs[VHOST_NET_VQ_TX];
struct vhost_virtqueue *vq = >vq;
unsigned long uninitialized_var(endtime);
-   int len = peek_head_len(sk);
+   int len = peek_head_len(rvq, sk);
 
if (!len && vq->busyloop_timeout) {
/* Both tx vq and rx socket were polled here */
@@ -561,7 +589,7 @@ static int vhost_net_rx_peek_head_len(struct vhost_net 
*net, struct sock *sk)
vhost_poll_queue(>poll);
mutex_unlock(>mutex);
 
-   len = peek_head_len(sk);
+   len = peek_head_len(rvq, sk);
}
 
return len;
@@ -699,6 +727,8 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
+   if (nvq->rx_array)
+   msg.msg_control = nvq->rxq[nvq->rh++];
/* On overrun, truncate and discard */
if (unlikely(headcount > UIO_MAXIOV)) {
iov_iter_init(_iter, READ, vq->iov, 1, 1);
@@ -841,6 +871,8 @@ static int vhost_net_open(struct inode *inode, struct file 
*f)
n->vqs[i].done_idx = 0;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+   n->vqs[i].rt = 0;
+   n->vqs[i].rh = 0;
}
vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
 
@@ -856,11 +888,15 @@ static struct socket *vhost_net_stop_vq(struct vhost_net 
*n,
struct vhost_virtqueue *vq)
 {
struct socket *sock;
+   struct vhost_net_virtqueue *nvq =
+   container_of(vq, struct vhost_net_virtqueue, vq);
 
mutex_lock(>mutex);
sock = vq->private_data;
vhost_net_disable_vq(n, vq);
vq->private_data = NULL;
+   while 

[PATCH net-next 7/8] vhost_net: try batch dequing from skb array

[Jason Wang]

We used to dequeue one skb during recvmsg() from skb_array, this could
be inefficient because of the bad cache utilization and spinlock
touching for each packet. This patch tries to batch them by calling
batch dequeuing helpers explicitly on the exported skb array and pass
the skb back through msg_control for underlayer socket to finish the
userspace copying.

Tests were done by XDP1:
- small buffer:
  Before: 1.88Mpps
  After : 2.25Mpps (+19.6%)
- mergeable buffer:
  Before: 1.83Mpps
  After : 2.10Mpps (+14.7%)

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 64 +
 1 file changed, 60 insertions(+), 4 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 9b51989..53f09f2 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -85,6 +87,7 @@ struct vhost_net_ubuf_ref {
struct vhost_virtqueue *vq;
 };
 
+#define VHOST_RX_BATCH 64
 struct vhost_net_virtqueue {
struct vhost_virtqueue vq;
size_t vhost_hlen;
@@ -99,6 +102,10 @@ struct vhost_net_virtqueue {
/* Reference counting for outstanding ubufs.
 * Protected by vq mutex. Writers must also take device mutex. */
struct vhost_net_ubuf_ref *ubufs;
+   struct skb_array *rx_array;
+   void *rxq[VHOST_RX_BATCH];
+   int rt;
+   int rh;
 };
 
 struct vhost_net {
@@ -201,6 +208,8 @@ static void vhost_net_vq_reset(struct vhost_net *n)
n->vqs[i].ubufs = NULL;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+   n->vqs[i].rt = 0;
+   n->vqs[i].rh = 0;
}
 
 }
@@ -503,13 +512,30 @@ static void handle_tx(struct vhost_net *net)
mutex_unlock(>mutex);
 }
 
-static int peek_head_len(struct sock *sk)
+static int peek_head_len_batched(struct vhost_net_virtqueue *rvq)
+{
+   if (rvq->rh != rvq->rt)
+   goto out;
+
+   rvq->rh = rvq->rt = 0;
+   rvq->rt = skb_array_consume_batched_bh(rvq->rx_array, rvq->rxq,
+   VHOST_RX_BATCH);
+   if (!rvq->rt)
+   return 0;
+out:
+   return __skb_array_len_with_tag(rvq->rxq[rvq->rh]);
+}
+
+static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)
 {
struct socket *sock = sk->sk_socket;
struct sk_buff *head;
int len = 0;
unsigned long flags;
 
+   if (rvq->rx_array)
+   return peek_head_len_batched(rvq);
+
if (sock->ops->peek_len)
return sock->ops->peek_len(sock);
 
@@ -535,12 +561,14 @@ static int sk_has_rx_data(struct sock *sk)
return skb_queue_empty(>sk_receive_queue);
 }
 
-static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
+static int vhost_net_rx_peek_head_len(struct vhost_net *net,
+ struct sock *sk)
 {
+   struct vhost_net_virtqueue *rvq = >vqs[VHOST_NET_VQ_RX];
struct vhost_net_virtqueue *nvq = >vqs[VHOST_NET_VQ_TX];
struct vhost_virtqueue *vq = >vq;
unsigned long uninitialized_var(endtime);
-   int len = peek_head_len(sk);
+   int len = peek_head_len(rvq, sk);
 
if (!len && vq->busyloop_timeout) {
/* Both tx vq and rx socket were polled here */
@@ -561,7 +589,7 @@ static int vhost_net_rx_peek_head_len(struct vhost_net 
*net, struct sock *sk)
vhost_poll_queue(>poll);
mutex_unlock(>mutex);
 
-   len = peek_head_len(sk);
+   len = peek_head_len(rvq, sk);
}
 
return len;
@@ -699,6 +727,8 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
+   if (nvq->rx_array)
+   msg.msg_control = nvq->rxq[nvq->rh++];
/* On overrun, truncate and discard */
if (unlikely(headcount > UIO_MAXIOV)) {
iov_iter_init(_iter, READ, vq->iov, 1, 1);
@@ -841,6 +871,8 @@ static int vhost_net_open(struct inode *inode, struct file 
*f)
n->vqs[i].done_idx = 0;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+   n->vqs[i].rt = 0;
+   n->vqs[i].rh = 0;
}
vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
 
@@ -856,11 +888,15 @@ static struct socket *vhost_net_stop_vq(struct vhost_net 
*n,
struct vhost_virtqueue *vq)
 {
struct socket *sock;
+   struct vhost_net_virtqueue *nvq =
+   container_of(vq, struct vhost_net_virtqueue, vq);
 
mutex_lock(>mutex);
sock = vq->private_data;
vhost_net_disable_vq(n, vq);
vq->private_data = NULL;
+   while (nvq->rh != nvq->rt)
+   

[PATCH net-next 5/8] tun: support receiving skb through msg_control

[Jason Wang]

This patch makes tun_recvmsg() can receive from skb from its caller
through msg_control. Vhost_net will be the first user.

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 70dd9ec..a82bced 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1498,9 +1498,8 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
 
 static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
   struct iov_iter *to,
-  int noblock)
+  int noblock, struct sk_buff *skb)
 {
-   struct sk_buff *skb;
ssize_t ret;
int err;
 
@@ -1509,10 +1508,12 @@ static ssize_t tun_do_read(struct tun_struct *tun, 
struct tun_file *tfile,
if (!iov_iter_count(to))
return 0;
 
-   /* Read frames from ring */
-   skb = tun_ring_recv(tfile, noblock, );
-   if (!skb)
-   return err;
+   if (!skb) {
+   /* Read frames from ring */
+   skb = tun_ring_recv(tfile, noblock, );
+   if (!skb)
+   return err;
+   }
 
ret = tun_put_user(tun, tfile, skb, to);
if (unlikely(ret < 0))
@@ -1532,7 +1533,7 @@ static ssize_t tun_chr_read_iter(struct kiocb *iocb, 
struct iov_iter *to)
 
if (!tun)
return -EBADFD;
-   ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK);
+   ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
@@ -1634,7 +1635,8 @@ static int tun_recvmsg(struct socket *sock, struct msghdr 
*m, size_t total_len,
 SOL_PACKET, TUN_TX_TIMESTAMP);
goto out;
}
-   ret = tun_do_read(tun, tfile, >msg_iter, flags & MSG_DONTWAIT);
+   ret = tun_do_read(tun, tfile, >msg_iter, flags & MSG_DONTWAIT,
+ m->msg_control);
if (ret > (ssize_t)total_len) {
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
-- 
2.7.4

[PATCH net-next 3/8] tun: export skb_array

[Jason Wang]

This patch exports skb_array through tun_get_skb_array(). Caller can
then manipulate skb array directly.

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c  | 13 +
 include/linux/if_tun.h |  5 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index c418f0a..70dd9ec 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2613,6 +2613,19 @@ struct socket *tun_get_socket(struct file *file)
 }
 EXPORT_SYMBOL_GPL(tun_get_socket);
 
+struct skb_array *tun_get_skb_array(struct file *file)
+{
+   struct tun_file *tfile;
+
+   if (file->f_op != _fops)
+   return ERR_PTR(-EINVAL);
+   tfile = file->private_data;
+   if (!tfile)
+   return ERR_PTR(-EBADFD);
+   return >tx_array;
+}
+EXPORT_SYMBOL_GPL(tun_get_skb_array);
+
 module_init(tun_init);
 module_exit(tun_cleanup);
 MODULE_DESCRIPTION(DRV_DESCRIPTION);
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index ed6da2e..bf9bdf4 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -19,6 +19,7 @@
 
 #if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
 struct socket *tun_get_socket(struct file *);
+struct skb_array *tun_get_skb_array(struct file *file);
 #else
 #include 
 #include 
@@ -28,5 +29,9 @@ static inline struct socket *tun_get_socket(struct file *f)
 {
return ERR_PTR(-EINVAL);
 }
+static inline struct skb_array *tun_get_skb_array(struct file *f)
+{
+   return ERR_PTR(-EINVAL);
+}
 #endif /* CONFIG_TUN */
 #endif /* __IF_TUN_H */
-- 
2.7.4

[PATCH net-next 3/8] tun: export skb_array

[Jason Wang]

This patch exports skb_array through tun_get_skb_array(). Caller can
then manipulate skb array directly.

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c  | 13 +
 include/linux/if_tun.h |  5 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index c418f0a..70dd9ec 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2613,6 +2613,19 @@ struct socket *tun_get_socket(struct file *file)
 }
 EXPORT_SYMBOL_GPL(tun_get_socket);
 
+struct skb_array *tun_get_skb_array(struct file *file)
+{
+   struct tun_file *tfile;
+
+   if (file->f_op != _fops)
+   return ERR_PTR(-EINVAL);
+   tfile = file->private_data;
+   if (!tfile)
+   return ERR_PTR(-EBADFD);
+   return >tx_array;
+}
+EXPORT_SYMBOL_GPL(tun_get_skb_array);
+
 module_init(tun_init);
 module_exit(tun_cleanup);
 MODULE_DESCRIPTION(DRV_DESCRIPTION);
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index ed6da2e..bf9bdf4 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -19,6 +19,7 @@
 
 #if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
 struct socket *tun_get_socket(struct file *);
+struct skb_array *tun_get_skb_array(struct file *file);
 #else
 #include 
 #include 
@@ -28,5 +29,9 @@ static inline struct socket *tun_get_socket(struct file *f)
 {
return ERR_PTR(-EINVAL);
 }
+static inline struct skb_array *tun_get_skb_array(struct file *f)
+{
+   return ERR_PTR(-EINVAL);
+}
 #endif /* CONFIG_TUN */
 #endif /* __IF_TUN_H */
-- 
2.7.4

[PATCH net-next 5/8] tun: support receiving skb through msg_control

[Jason Wang]

This patch makes tun_recvmsg() can receive from skb from its caller
through msg_control. Vhost_net will be the first user.

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 70dd9ec..a82bced 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1498,9 +1498,8 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
 
 static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
   struct iov_iter *to,
-  int noblock)
+  int noblock, struct sk_buff *skb)
 {
-   struct sk_buff *skb;
ssize_t ret;
int err;
 
@@ -1509,10 +1508,12 @@ static ssize_t tun_do_read(struct tun_struct *tun, 
struct tun_file *tfile,
if (!iov_iter_count(to))
return 0;
 
-   /* Read frames from ring */
-   skb = tun_ring_recv(tfile, noblock, );
-   if (!skb)
-   return err;
+   if (!skb) {
+   /* Read frames from ring */
+   skb = tun_ring_recv(tfile, noblock, );
+   if (!skb)
+   return err;
+   }
 
ret = tun_put_user(tun, tfile, skb, to);
if (unlikely(ret < 0))
@@ -1532,7 +1533,7 @@ static ssize_t tun_chr_read_iter(struct kiocb *iocb, 
struct iov_iter *to)
 
if (!tun)
return -EBADFD;
-   ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK);
+   ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
@@ -1634,7 +1635,8 @@ static int tun_recvmsg(struct socket *sock, struct msghdr 
*m, size_t total_len,
 SOL_PACKET, TUN_TX_TIMESTAMP);
goto out;
}
-   ret = tun_do_read(tun, tfile, >msg_iter, flags & MSG_DONTWAIT);
+   ret = tun_do_read(tun, tfile, >msg_iter, flags & MSG_DONTWAIT,
+ m->msg_control);
if (ret > (ssize_t)total_len) {
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
-- 
2.7.4

[PATCH net-next 1/8] ptr_ring: introduce batch dequeuing

[Jason Wang]

Signed-off-by: Jason Wang 
---
 include/linux/ptr_ring.h | 65 
 1 file changed, 65 insertions(+)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 6c70444..4771ded 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -247,6 +247,22 @@ static inline void *__ptr_ring_consume(struct ptr_ring *r)
return ptr;
 }
 
+static inline int __ptr_ring_consume_batched(struct ptr_ring *r,
+void **array, int n)
+{
+   void *ptr;
+   int i = 0;
+
+   while (i < n) {
+   ptr = __ptr_ring_consume(r);
+   if (!ptr)
+   break;
+   array[i++] = ptr;
+   }
+
+   return i;
+}
+
 /*
  * Note: resize (below) nests producer lock within consumer lock, so if you
  * call this in interrupt or BH context, you must disable interrupts/BH when
@@ -297,6 +313,55 @@ static inline void *ptr_ring_consume_bh(struct ptr_ring *r)
return ptr;
 }
 
+static inline int ptr_ring_consume_batched(struct ptr_ring *r,
+  void **array, int n)
+{
+   int ret;
+
+   spin_lock(>consumer_lock);
+   ret = __ptr_ring_consume_batched(r, array, n);
+   spin_unlock(>consumer_lock);
+
+   return ret;
+}
+
+static inline int ptr_ring_consume_batched_irq(struct ptr_ring *r,
+  void **array, int n)
+{
+   int ret;
+
+   spin_lock_irq(>consumer_lock);
+   ret = __ptr_ring_consume_batched(r, array, n);
+   spin_unlock_irq(>consumer_lock);
+
+   return ret;
+}
+
+static inline int ptr_ring_consume_batched_any(struct ptr_ring *r,
+  void **array, int n)
+{
+   unsigned long flags;
+   int ret;
+
+   spin_lock_irqsave(>consumer_lock, flags);
+   ret = __ptr_ring_consume_batched(r, array, n);
+   spin_unlock_irqrestore(>consumer_lock, flags);
+
+   return ret;
+}
+
+static inline int ptr_ring_consume_batched_bh(struct ptr_ring *r,
+ void **array, int n)
+{
+   int ret;
+
+   spin_lock_bh(>consumer_lock);
+   ret = __ptr_ring_consume_batched(r, array, n);
+   spin_unlock_bh(>consumer_lock);
+
+   return ret;
+}
+
 /* Cast to structure type and call a function without discarding from FIFO.
  * Function must return a value.
  * Callers must take consumer_lock.
-- 
2.7.4

[PATCH net-next 1/8] ptr_ring: introduce batch dequeuing

[Jason Wang]

Signed-off-by: Jason Wang 
---
 include/linux/ptr_ring.h | 65 
 1 file changed, 65 insertions(+)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 6c70444..4771ded 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -247,6 +247,22 @@ static inline void *__ptr_ring_consume(struct ptr_ring *r)
return ptr;
 }
 
+static inline int __ptr_ring_consume_batched(struct ptr_ring *r,
+void **array, int n)
+{
+   void *ptr;
+   int i = 0;
+
+   while (i < n) {
+   ptr = __ptr_ring_consume(r);
+   if (!ptr)
+   break;
+   array[i++] = ptr;
+   }
+
+   return i;
+}
+
 /*
  * Note: resize (below) nests producer lock within consumer lock, so if you
  * call this in interrupt or BH context, you must disable interrupts/BH when
@@ -297,6 +313,55 @@ static inline void *ptr_ring_consume_bh(struct ptr_ring *r)
return ptr;
 }
 
+static inline int ptr_ring_consume_batched(struct ptr_ring *r,
+  void **array, int n)
+{
+   int ret;
+
+   spin_lock(>consumer_lock);
+   ret = __ptr_ring_consume_batched(r, array, n);
+   spin_unlock(>consumer_lock);
+
+   return ret;
+}
+
+static inline int ptr_ring_consume_batched_irq(struct ptr_ring *r,
+  void **array, int n)
+{
+   int ret;
+
+   spin_lock_irq(>consumer_lock);
+   ret = __ptr_ring_consume_batched(r, array, n);
+   spin_unlock_irq(>consumer_lock);
+
+   return ret;
+}
+
+static inline int ptr_ring_consume_batched_any(struct ptr_ring *r,
+  void **array, int n)
+{
+   unsigned long flags;
+   int ret;
+
+   spin_lock_irqsave(>consumer_lock, flags);
+   ret = __ptr_ring_consume_batched(r, array, n);
+   spin_unlock_irqrestore(>consumer_lock, flags);
+
+   return ret;
+}
+
+static inline int ptr_ring_consume_batched_bh(struct ptr_ring *r,
+ void **array, int n)
+{
+   int ret;
+
+   spin_lock_bh(>consumer_lock);
+   ret = __ptr_ring_consume_batched(r, array, n);
+   spin_unlock_bh(>consumer_lock);
+
+   return ret;
+}
+
 /* Cast to structure type and call a function without discarding from FIFO.
  * Function must return a value.
  * Callers must take consumer_lock.
-- 
2.7.4

[PATCH net-next 2/8] skb_array: introduce batch dequeuing

[Jason Wang]

Signed-off-by: Jason Wang 
---
 include/linux/skb_array.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index f4dfade..90e44b9 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -97,21 +97,46 @@ static inline struct sk_buff *skb_array_consume(struct 
skb_array *a)
return ptr_ring_consume(>ring);
 }
 
+static inline int skb_array_consume_batched(struct skb_array *a,
+   void **array, int n)
+{
+   return ptr_ring_consume_batched(>ring, array, n);
+}
+
 static inline struct sk_buff *skb_array_consume_irq(struct skb_array *a)
 {
return ptr_ring_consume_irq(>ring);
 }
 
+static inline int skb_array_consume_batched_irq(struct skb_array *a,
+   void **array, int n)
+{
+   return ptr_ring_consume_batched_irq(>ring, array, n);
+}
+
 static inline struct sk_buff *skb_array_consume_any(struct skb_array *a)
 {
return ptr_ring_consume_any(>ring);
 }
 
+static inline int skb_array_consume_batched_any(struct skb_array *a,
+   void **array, int n)
+{
+   return ptr_ring_consume_batched_any(>ring, array, n);
+}
+
+
 static inline struct sk_buff *skb_array_consume_bh(struct skb_array *a)
 {
return ptr_ring_consume_bh(>ring);
 }
 
+static inline int skb_array_consume_batched_bh(struct skb_array *a,
+  void **array, int n)
+{
+   return ptr_ring_consume_batched_bh(>ring, array, n);
+}
+
 static inline int __skb_array_len_with_tag(struct sk_buff *skb)
 {
if (likely(skb)) {
-- 
2.7.4

[PATCH net-next 2/8] skb_array: introduce batch dequeuing

[Jason Wang]

Signed-off-by: Jason Wang 
---
 include/linux/skb_array.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index f4dfade..90e44b9 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -97,21 +97,46 @@ static inline struct sk_buff *skb_array_consume(struct 
skb_array *a)
return ptr_ring_consume(>ring);
 }
 
+static inline int skb_array_consume_batched(struct skb_array *a,
+   void **array, int n)
+{
+   return ptr_ring_consume_batched(>ring, array, n);
+}
+
 static inline struct sk_buff *skb_array_consume_irq(struct skb_array *a)
 {
return ptr_ring_consume_irq(>ring);
 }
 
+static inline int skb_array_consume_batched_irq(struct skb_array *a,
+   void **array, int n)
+{
+   return ptr_ring_consume_batched_irq(>ring, array, n);
+}
+
 static inline struct sk_buff *skb_array_consume_any(struct skb_array *a)
 {
return ptr_ring_consume_any(>ring);
 }
 
+static inline int skb_array_consume_batched_any(struct skb_array *a,
+   void **array, int n)
+{
+   return ptr_ring_consume_batched_any(>ring, array, n);
+}
+
+
 static inline struct sk_buff *skb_array_consume_bh(struct skb_array *a)
 {
return ptr_ring_consume_bh(>ring);
 }
 
+static inline int skb_array_consume_batched_bh(struct skb_array *a,
+  void **array, int n)
+{
+   return ptr_ring_consume_batched_bh(>ring, array, n);
+}
+
 static inline int __skb_array_len_with_tag(struct sk_buff *skb)
 {
if (likely(skb)) {
-- 
2.7.4

linux-next: Tree for Mar 21

[Stephen Rothwell]

Hi all,

Changes since 20170320:

New trees: pinctrl-samsung

The drm tree gained a conflict against the drm-intel-fixes tree.

The drm-intel tree gained a conflict against the drm-intel-fixes tree.

The drm-tegra tree gained a conflict against the drm tree.

The char-misc tree still had its build failure for which I applied a
fix patch.

Non-merge commits (relative to Linus' tree): 3729
 4573 files changed, 352144 insertions(+), 60911 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (97da3854c526 Linux 4.11-rc3)
Merging fixes/master (c470abd4fde4 Linux 4.10)
Merging kbuild-current/fixes (b334e19ae938 Kbuild: use cc-disable-warning 
consistently for maybe-uninitialized)
Merging arc-current/for-curr (7f35144cea21 ARC: get rate from clk driver 
instead of reading device tree)
Merging arm-current/fixes (a1016e94cce9 ARM: wire up statx syscall)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (8971e1c79d3f powerpc/pseries: Don't give a warning 
when HPT resizing isn't available)
Merging sparc/master (f8e6859ea9d0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (db7f00b8dba6 tcp: tcp_get_info() should read tcp_time_stamp 
later)
Merging ipsec/master (72ef9c4125c7 dccp: fix memory leak during tear-down of 
unsuccessful connection request)
Merging netfilter/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if 
Wake-on-LAN is enabled)
Merging ipvs/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if 
Wake-on-LAN is enabled)
Merging wireless-drivers/master (cf8c44d42c4f MAINTAINERS: update for mwifiex 
driver maintainers)
Merging mac80211/master (ea90e0dc8cec nl80211: fix dumpit error path RTNL 
deadlocks)
Merging sound-current/for-linus (cc3a47a248d7 ALSA: hda - add support for 
docking station for HP 840 G3)
Merging pci-current/for-linus (6e347b5e05ea PCI: iproc: Save host bridge window 
resource in struct iproc_pcie)
Merging driver-core.current/driver-core-linus (966fa72a716c kernfs: Check 
KERNFS_HAS_RELEASE before calling kernfs_release_file())
Merging tty.current/tty-linus (a4a3e061149f tty: fix data race in 
tty_ldisc_ref_wait())
Merging usb.current/usb-linus (7b2db29fbb4e usb: hub: Fix crash after failure 
to read BOS descriptor)
Merging usb-gadget-fixes/fixes (35b2719e72d3 usb: dwc3: gadget: make to 
increment req->remaining in all cases)
Merging usb-serial-fixes/usb-linus (436ecf5519d8 USB: serial: qcserial: add 
Dell DW5811e)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (4495c08e8472 Linux 4.11-rc2)
Merging char-misc.current/char-misc-linus (c3423563c68f vmw_vmci: handle the 
return value from pci_alloc_irq_vectors correctly)
Merging input-current/for-linus (47e6fb4212d0 Input: ALPS - fix trackstick 
button handling on V8 devices)
Merging crypto-current/master (8c75704ebcac hwrng: geode - Revert managed API 
chan

linux-next: Tree for Mar 21

[Stephen Rothwell]

Hi all,

Changes since 20170320:

New trees: pinctrl-samsung

The drm tree gained a conflict against the drm-intel-fixes tree.

The drm-intel tree gained a conflict against the drm-intel-fixes tree.

The drm-tegra tree gained a conflict against the drm tree.

The char-misc tree still had its build failure for which I applied a
fix patch.

Non-merge commits (relative to Linus' tree): 3729
 4573 files changed, 352144 insertions(+), 60911 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (97da3854c526 Linux 4.11-rc3)
Merging fixes/master (c470abd4fde4 Linux 4.10)
Merging kbuild-current/fixes (b334e19ae938 Kbuild: use cc-disable-warning 
consistently for maybe-uninitialized)
Merging arc-current/for-curr (7f35144cea21 ARC: get rate from clk driver 
instead of reading device tree)
Merging arm-current/fixes (a1016e94cce9 ARM: wire up statx syscall)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (8971e1c79d3f powerpc/pseries: Don't give a warning 
when HPT resizing isn't available)
Merging sparc/master (f8e6859ea9d0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (db7f00b8dba6 tcp: tcp_get_info() should read tcp_time_stamp 
later)
Merging ipsec/master (72ef9c4125c7 dccp: fix memory leak during tear-down of 
unsuccessful connection request)
Merging netfilter/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if 
Wake-on-LAN is enabled)
Merging ipvs/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if 
Wake-on-LAN is enabled)
Merging wireless-drivers/master (cf8c44d42c4f MAINTAINERS: update for mwifiex 
driver maintainers)
Merging mac80211/master (ea90e0dc8cec nl80211: fix dumpit error path RTNL 
deadlocks)
Merging sound-current/for-linus (cc3a47a248d7 ALSA: hda - add support for 
docking station for HP 840 G3)
Merging pci-current/for-linus (6e347b5e05ea PCI: iproc: Save host bridge window 
resource in struct iproc_pcie)
Merging driver-core.current/driver-core-linus (966fa72a716c kernfs: Check 
KERNFS_HAS_RELEASE before calling kernfs_release_file())
Merging tty.current/tty-linus (a4a3e061149f tty: fix data race in 
tty_ldisc_ref_wait())
Merging usb.current/usb-linus (7b2db29fbb4e usb: hub: Fix crash after failure 
to read BOS descriptor)
Merging usb-gadget-fixes/fixes (35b2719e72d3 usb: dwc3: gadget: make to 
increment req->remaining in all cases)
Merging usb-serial-fixes/usb-linus (436ecf5519d8 USB: serial: qcserial: add 
Dell DW5811e)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (4495c08e8472 Linux 4.11-rc2)
Merging char-misc.current/char-misc-linus (c3423563c68f vmw_vmci: handle the 
return value from pci_alloc_irq_vectors correctly)
Merging input-current/for-linus (47e6fb4212d0 Input: ALPS - fix trackstick 
button handling on V8 devices)
Merging crypto-current/master (8c75704ebcac hwrng: geode - Revert managed API 
chan

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

[Steve Longerbeam]

On 03/20/2017 10:23 AM, Philipp Zabel wrote:

Hi Steve, Russell,

On Mon, 2017-03-20 at 14:17 +, Russell King - ARM Linux wrote:

On Mon, Mar 20, 2017 at 03:00:51PM +0100, Philipp Zabel wrote:

On Mon, 2017-03-20 at 12:08 +, Russell King - ARM Linux wrote:

The same document says:

  Scaling support is optional. When supported by a subdev, the crop
  rectangle on the subdev's sink pad is scaled to the size configured
  using the
  :ref:`VIDIOC_SUBDEV_S_SELECTION ` IOCTL
  using ``V4L2_SEL_TGT_COMPOSE`` selection target on the same pad. If the
  subdev supports scaling but not composing, the top and left values are
  not used and must always be set to zero.


Right, this sentence does imply that when scaling is supported, there
must be a sink compose rectangle, even when composing is not.

I have previously set up scaling like this:

media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080@1/60]"
media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/960x540@1/30]"

Does this mean, it should work like this instead?

media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080@1/60]"
media-ctl --set-v4l2 
"'ipu1_csi0':0[fmt:UYVY2X8/1920x1080@1/60,compose:(0,0)/960x540]"
media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/960x540@1/30]"

I suppose setting the source pad format should not be allowed to modify
the sink compose rectangle.


That is what I believe having read these documents several times, but
we need v4l2 people to confirm.


What do you think of this:

--8<--
From 2830aebc404bdfc9d7fc1ec94e5282d0b668e8f6 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Mon, 20 Mar 2017 17:10:21 +0100
Subject: [PATCH] media: imx: csi: add sink selection rectangles

Move the crop rectangle to the sink pad and add a sink compose rectangle
to configure scaling. Also propagate rectangles from sink pad to crop
rectangle, to compose rectangle, and to the source pads both in ACTIVE
and TRY variants of set_fmt/selection, and initialize the default crop
and compose rectangles.



I haven't had a chance to look at this patch in detail yet, but on
first glance it looks good to me. I'll try to find the time tomorrow
to incorporate it and then fixup Russell's subsequent patches for
the enum frame sizes/intervals.

Steve


Signed-off-by: Philipp Zabel 
---
 drivers/staging/media/imx/imx-media-csi.c | 216 +-
 1 file changed, 152 insertions(+), 64 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 560da3abdd70b..b026a5d602ddf 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -79,6 +79,7 @@ struct csi_priv {
const struct imx_media_pixfmt *cc[CSI_NUM_PADS];
struct v4l2_fract frame_interval;
struct v4l2_rect crop;
+   struct v4l2_rect compose;
const struct csi_skip_desc *skip[CSI_NUM_PADS - 1];

/* active vb2 buffers to send to video dev sink */
@@ -574,8 +575,8 @@ static int csi_setup(struct csi_priv *priv)
ipu_csi_set_window(priv->csi, >crop);

ipu_csi_set_downsize(priv->csi,
-priv->crop.width == 2 * outfmt->width,
-priv->crop.height == 2 * outfmt->height);
+priv->crop.width == 2 * priv->compose.width,
+priv->crop.height == 2 * priv->compose.height);

ipu_csi_init_interface(priv->csi, _mbus_cfg, _fmt);

@@ -1001,6 +1002,27 @@ __csi_get_fmt(struct csi_priv *priv, struct 
v4l2_subdev_pad_config *cfg,
return >format_mbus[pad];
 }

+static struct v4l2_rect *
+__csi_get_crop(struct csi_priv *priv, struct v4l2_subdev_pad_config *cfg,
+  enum v4l2_subdev_format_whence which)
+{
+   if (which == V4L2_SUBDEV_FORMAT_TRY)
+   return v4l2_subdev_get_try_crop(>sd, cfg, CSI_SINK_PAD);
+   else
+   return >crop;
+}
+
+static struct v4l2_rect *
+__csi_get_compose(struct csi_priv *priv, struct v4l2_subdev_pad_config *cfg,
+ enum v4l2_subdev_format_whence which)
+{
+   if (which == V4L2_SUBDEV_FORMAT_TRY)
+   return v4l2_subdev_get_try_compose(>sd, cfg,
+  CSI_SINK_PAD);
+   else
+   return >compose;
+}
+
 static void csi_try_crop(struct csi_priv *priv,
 struct v4l2_rect *crop,
 struct v4l2_subdev_pad_config *cfg,
@@ -1159,6 +1181,7 @@ static void csi_try_fmt(struct csi_priv *priv,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *sdformat,
struct v4l2_rect *crop,
+   struct v4l2_rect *compose,
const struct imx_media_pixfmt **cc)
 {
const struct imx_media_pixfmt *incc;
@@ -1173,15 +1196,8 @@ static void 

Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

[Steve Longerbeam]

On 03/20/2017 10:23 AM, Philipp Zabel wrote:

Hi Steve, Russell,

On Mon, 2017-03-20 at 14:17 +, Russell King - ARM Linux wrote:

On Mon, Mar 20, 2017 at 03:00:51PM +0100, Philipp Zabel wrote:

On Mon, 2017-03-20 at 12:08 +, Russell King - ARM Linux wrote:

The same document says:

  Scaling support is optional. When supported by a subdev, the crop
  rectangle on the subdev's sink pad is scaled to the size configured
  using the
  :ref:`VIDIOC_SUBDEV_S_SELECTION ` IOCTL
  using ``V4L2_SEL_TGT_COMPOSE`` selection target on the same pad. If the
  subdev supports scaling but not composing, the top and left values are
  not used and must always be set to zero.


Right, this sentence does imply that when scaling is supported, there
must be a sink compose rectangle, even when composing is not.

I have previously set up scaling like this:

media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080@1/60]"
media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/960x540@1/30]"

Does this mean, it should work like this instead?

media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080@1/60]"
media-ctl --set-v4l2 
"'ipu1_csi0':0[fmt:UYVY2X8/1920x1080@1/60,compose:(0,0)/960x540]"
media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/960x540@1/30]"

I suppose setting the source pad format should not be allowed to modify
the sink compose rectangle.


That is what I believe having read these documents several times, but
we need v4l2 people to confirm.


What do you think of this:

--8<--
From 2830aebc404bdfc9d7fc1ec94e5282d0b668e8f6 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Mon, 20 Mar 2017 17:10:21 +0100
Subject: [PATCH] media: imx: csi: add sink selection rectangles

Move the crop rectangle to the sink pad and add a sink compose rectangle
to configure scaling. Also propagate rectangles from sink pad to crop
rectangle, to compose rectangle, and to the source pads both in ACTIVE
and TRY variants of set_fmt/selection, and initialize the default crop
and compose rectangles.



I haven't had a chance to look at this patch in detail yet, but on
first glance it looks good to me. I'll try to find the time tomorrow
to incorporate it and then fixup Russell's subsequent patches for
the enum frame sizes/intervals.

Steve


Signed-off-by: Philipp Zabel 
---
 drivers/staging/media/imx/imx-media-csi.c | 216 +-
 1 file changed, 152 insertions(+), 64 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 560da3abdd70b..b026a5d602ddf 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -79,6 +79,7 @@ struct csi_priv {
const struct imx_media_pixfmt *cc[CSI_NUM_PADS];
struct v4l2_fract frame_interval;
struct v4l2_rect crop;
+   struct v4l2_rect compose;
const struct csi_skip_desc *skip[CSI_NUM_PADS - 1];

/* active vb2 buffers to send to video dev sink */
@@ -574,8 +575,8 @@ static int csi_setup(struct csi_priv *priv)
ipu_csi_set_window(priv->csi, >crop);

ipu_csi_set_downsize(priv->csi,
-priv->crop.width == 2 * outfmt->width,
-priv->crop.height == 2 * outfmt->height);
+priv->crop.width == 2 * priv->compose.width,
+priv->crop.height == 2 * priv->compose.height);

ipu_csi_init_interface(priv->csi, _mbus_cfg, _fmt);

@@ -1001,6 +1002,27 @@ __csi_get_fmt(struct csi_priv *priv, struct 
v4l2_subdev_pad_config *cfg,
return >format_mbus[pad];
 }

+static struct v4l2_rect *
+__csi_get_crop(struct csi_priv *priv, struct v4l2_subdev_pad_config *cfg,
+  enum v4l2_subdev_format_whence which)
+{
+   if (which == V4L2_SUBDEV_FORMAT_TRY)
+   return v4l2_subdev_get_try_crop(>sd, cfg, CSI_SINK_PAD);
+   else
+   return >crop;
+}
+
+static struct v4l2_rect *
+__csi_get_compose(struct csi_priv *priv, struct v4l2_subdev_pad_config *cfg,
+ enum v4l2_subdev_format_whence which)
+{
+   if (which == V4L2_SUBDEV_FORMAT_TRY)
+   return v4l2_subdev_get_try_compose(>sd, cfg,
+  CSI_SINK_PAD);
+   else
+   return >compose;
+}
+
 static void csi_try_crop(struct csi_priv *priv,
 struct v4l2_rect *crop,
 struct v4l2_subdev_pad_config *cfg,
@@ -1159,6 +1181,7 @@ static void csi_try_fmt(struct csi_priv *priv,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *sdformat,
struct v4l2_rect *crop,
+   struct v4l2_rect *compose,
const struct imx_media_pixfmt **cc)
 {
const struct imx_media_pixfmt *incc;
@@ -1173,15 +1196,8 @@ static void csi_try_fmt(struct csi_priv *priv,
incc = 

[PATCH net-next 8/8] vhost_net: use lockless peeking for skb array during busy polling

[Jason Wang]

For the socket that exports its skb array, we can use lockless polling
to avoid touching spinlock during busy polling.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 53f09f2..41153a3 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -551,10 +551,13 @@ static int peek_head_len(struct vhost_net_virtqueue *rvq, 
struct sock *sk)
return len;
 }
 
-static int sk_has_rx_data(struct sock *sk)
+static int sk_has_rx_data(struct vhost_net_virtqueue *rvq, struct sock *sk)
 {
struct socket *sock = sk->sk_socket;
 
+   if (rvq->rx_array)
+   return !__skb_array_empty(rvq->rx_array);
+
if (sock->ops->peek_len)
return sock->ops->peek_len(sock);
 
@@ -579,7 +582,7 @@ static int vhost_net_rx_peek_head_len(struct vhost_net *net,
endtime = busy_clock() + vq->busyloop_timeout;
 
while (vhost_can_busy_poll(>dev, endtime) &&
-  !sk_has_rx_data(sk) &&
+  !sk_has_rx_data(rvq, sk) &&
   vhost_vq_avail_empty(>dev, vq))
cpu_relax();
 
-- 
2.7.4

[PATCH net-next 8/8] vhost_net: use lockless peeking for skb array during busy polling

[Jason Wang]

For the socket that exports its skb array, we can use lockless polling
to avoid touching spinlock during busy polling.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 53f09f2..41153a3 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -551,10 +551,13 @@ static int peek_head_len(struct vhost_net_virtqueue *rvq, 
struct sock *sk)
return len;
 }
 
-static int sk_has_rx_data(struct sock *sk)
+static int sk_has_rx_data(struct vhost_net_virtqueue *rvq, struct sock *sk)
 {
struct socket *sock = sk->sk_socket;
 
+   if (rvq->rx_array)
+   return !__skb_array_empty(rvq->rx_array);
+
if (sock->ops->peek_len)
return sock->ops->peek_len(sock);
 
@@ -579,7 +582,7 @@ static int vhost_net_rx_peek_head_len(struct vhost_net *net,
endtime = busy_clock() + vq->busyloop_timeout;
 
while (vhost_can_busy_poll(>dev, endtime) &&
-  !sk_has_rx_data(sk) &&
+  !sk_has_rx_data(rvq, sk) &&
   vhost_vq_avail_empty(>dev, vq))
cpu_relax();
 
-- 
2.7.4

[PATCH net-next 4/8] tap: export skb_array

[Jason Wang]

This patch exports skb_array through tap_get_skb_array(). Caller can
then manipulate skb array directly.

Signed-off-by: Jason Wang 
---
 drivers/net/tap.c  | 13 +
 include/linux/if_tap.h |  5 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 4d4173d..abdaf86 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1193,6 +1193,19 @@ struct socket *tap_get_socket(struct file *file)
 }
 EXPORT_SYMBOL_GPL(tap_get_socket);
 
+struct skb_array *tap_get_skb_array(struct file *file)
+{
+   struct tap_queue *q;
+
+   if (file->f_op != _fops)
+   return ERR_PTR(-EINVAL);
+   q = file->private_data;
+   if (!q)
+   return ERR_PTR(-EBADFD);
+   return >skb_array;
+}
+EXPORT_SYMBOL_GPL(tap_get_skb_array);
+
 int tap_queue_resize(struct tap_dev *tap)
 {
struct net_device *dev = tap->dev;
diff --git a/include/linux/if_tap.h b/include/linux/if_tap.h
index 3482c3c..4837157 100644
--- a/include/linux/if_tap.h
+++ b/include/linux/if_tap.h
@@ -3,6 +3,7 @@
 
 #if IS_ENABLED(CONFIG_TAP)
 struct socket *tap_get_socket(struct file *);
+struct skb_array *tap_get_skb_array(struct file *file);
 #else
 #include 
 #include 
@@ -12,6 +13,10 @@ static inline struct socket *tap_get_socket(struct file *f)
 {
return ERR_PTR(-EINVAL);
 }
+static inline struct skb_array *tap_get_skb_array(struct file *f)
+{
+   return ERR_PTR(-EINVAL);
+}
 #endif /* CONFIG_TAP */
 
 #include 
-- 
2.7.4

[PATCH net-next 4/8] tap: export skb_array

[Jason Wang]

This patch exports skb_array through tap_get_skb_array(). Caller can
then manipulate skb array directly.

Signed-off-by: Jason Wang 
---
 drivers/net/tap.c  | 13 +
 include/linux/if_tap.h |  5 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 4d4173d..abdaf86 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1193,6 +1193,19 @@ struct socket *tap_get_socket(struct file *file)
 }
 EXPORT_SYMBOL_GPL(tap_get_socket);
 
+struct skb_array *tap_get_skb_array(struct file *file)
+{
+   struct tap_queue *q;
+
+   if (file->f_op != _fops)
+   return ERR_PTR(-EINVAL);
+   q = file->private_data;
+   if (!q)
+   return ERR_PTR(-EBADFD);
+   return >skb_array;
+}
+EXPORT_SYMBOL_GPL(tap_get_skb_array);
+
 int tap_queue_resize(struct tap_dev *tap)
 {
struct net_device *dev = tap->dev;
diff --git a/include/linux/if_tap.h b/include/linux/if_tap.h
index 3482c3c..4837157 100644
--- a/include/linux/if_tap.h
+++ b/include/linux/if_tap.h
@@ -3,6 +3,7 @@
 
 #if IS_ENABLED(CONFIG_TAP)
 struct socket *tap_get_socket(struct file *);
+struct skb_array *tap_get_skb_array(struct file *file);
 #else
 #include 
 #include 
@@ -12,6 +13,10 @@ static inline struct socket *tap_get_socket(struct file *f)
 {
return ERR_PTR(-EINVAL);
 }
+static inline struct skb_array *tap_get_skb_array(struct file *f)
+{
+   return ERR_PTR(-EINVAL);
+}
 #endif /* CONFIG_TAP */
 
 #include 
-- 
2.7.4

[PATCH net-next 6/8] tap: support receiving skb from msg_control

[Jason Wang]

This patch makes tap_recvmsg() can receive from skb from its caller
through msg_control. Vhost_net will be the first user.

Signed-off-by: Jason Wang 
---
 drivers/net/tap.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index abdaf86..07d9174 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -824,15 +824,17 @@ static ssize_t tap_put_user(struct tap_queue *q,
 
 static ssize_t tap_do_read(struct tap_queue *q,
   struct iov_iter *to,
-  int noblock)
+  int noblock, struct sk_buff *skb)
 {
DEFINE_WAIT(wait);
-   struct sk_buff *skb;
ssize_t ret = 0;
 
if (!iov_iter_count(to))
return 0;
 
+   if (skb)
+   goto done;
+
while (1) {
if (!noblock)
prepare_to_wait(sk_sleep(>sk), ,
@@ -856,6 +858,7 @@ static ssize_t tap_do_read(struct tap_queue *q,
if (!noblock)
finish_wait(sk_sleep(>sk), );
 
+done:
if (skb) {
ret = tap_put_user(q, skb, to);
if (unlikely(ret < 0))
@@ -872,7 +875,7 @@ static ssize_t tap_read_iter(struct kiocb *iocb, struct 
iov_iter *to)
struct tap_queue *q = file->private_data;
ssize_t len = iov_iter_count(to), ret;
 
-   ret = tap_do_read(q, to, file->f_flags & O_NONBLOCK);
+   ret = tap_do_read(q, to, file->f_flags & O_NONBLOCK, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
@@ -1155,7 +1158,8 @@ static int tap_recvmsg(struct socket *sock, struct msghdr 
*m,
int ret;
if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
return -EINVAL;
-   ret = tap_do_read(q, >msg_iter, flags & MSG_DONTWAIT);
+   ret = tap_do_read(q, >msg_iter, flags & MSG_DONTWAIT,
+ m->msg_control);
if (ret > total_len) {
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
-- 
2.7.4

[PATCH net-next 6/8] tap: support receiving skb from msg_control

[Jason Wang]

This patch makes tap_recvmsg() can receive from skb from its caller
through msg_control. Vhost_net will be the first user.

Signed-off-by: Jason Wang 
---
 drivers/net/tap.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index abdaf86..07d9174 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -824,15 +824,17 @@ static ssize_t tap_put_user(struct tap_queue *q,
 
 static ssize_t tap_do_read(struct tap_queue *q,
   struct iov_iter *to,
-  int noblock)
+  int noblock, struct sk_buff *skb)
 {
DEFINE_WAIT(wait);
-   struct sk_buff *skb;
ssize_t ret = 0;
 
if (!iov_iter_count(to))
return 0;
 
+   if (skb)
+   goto done;
+
while (1) {
if (!noblock)
prepare_to_wait(sk_sleep(>sk), ,
@@ -856,6 +858,7 @@ static ssize_t tap_do_read(struct tap_queue *q,
if (!noblock)
finish_wait(sk_sleep(>sk), );
 
+done:
if (skb) {
ret = tap_put_user(q, skb, to);
if (unlikely(ret < 0))
@@ -872,7 +875,7 @@ static ssize_t tap_read_iter(struct kiocb *iocb, struct 
iov_iter *to)
struct tap_queue *q = file->private_data;
ssize_t len = iov_iter_count(to), ret;
 
-   ret = tap_do_read(q, to, file->f_flags & O_NONBLOCK);
+   ret = tap_do_read(q, to, file->f_flags & O_NONBLOCK, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
@@ -1155,7 +1158,8 @@ static int tap_recvmsg(struct socket *sock, struct msghdr 
*m,
int ret;
if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
return -EINVAL;
-   ret = tap_do_read(q, >msg_iter, flags & MSG_DONTWAIT);
+   ret = tap_do_read(q, >msg_iter, flags & MSG_DONTWAIT,
+ m->msg_control);
if (ret > total_len) {
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
-- 
2.7.4

[PATCH net-next 0/8] vhost-net rx batching

[Jason Wang]

Hi all:

This series tries to implement rx batching for vhost-net. This is done
by batching the dequeuing from skb_array which was exported by
underlayer socket and pass the sbk back through msg_control to finish
userspace copying.

Tests shows at most 19% improvment on rx pps.

Please review.

Thanks

Jason Wang (8):
  ptr_ring: introduce batch dequeuing
  skb_array: introduce batch dequeuing
  tun: export skb_array
  tap: export skb_array
  tun: support receiving skb through msg_control
  tap: support receiving skb from msg_control
  vhost_net: try batch dequing from skb array
  vhost_net: use lockless peeking for skb array during busy polling

 drivers/net/tap.c | 25 ++---
 drivers/net/tun.c | 31 +++--
 drivers/vhost/net.c   | 71 +++
 include/linux/if_tap.h|  5 
 include/linux/if_tun.h|  5 
 include/linux/ptr_ring.h  | 65 +++
 include/linux/skb_array.h | 25 +
 7 files changed, 209 insertions(+), 18 deletions(-)

-- 
2.7.4

[PATCH net-next 0/8] vhost-net rx batching

[Jason Wang]

Hi all:

This series tries to implement rx batching for vhost-net. This is done
by batching the dequeuing from skb_array which was exported by
underlayer socket and pass the sbk back through msg_control to finish
userspace copying.

Tests shows at most 19% improvment on rx pps.

Please review.

Thanks

Jason Wang (8):
  ptr_ring: introduce batch dequeuing
  skb_array: introduce batch dequeuing
  tun: export skb_array
  tap: export skb_array
  tun: support receiving skb through msg_control
  tap: support receiving skb from msg_control
  vhost_net: try batch dequing from skb array
  vhost_net: use lockless peeking for skb array during busy polling

 drivers/net/tap.c | 25 ++---
 drivers/net/tun.c | 31 +++--
 drivers/vhost/net.c   | 71 +++
 include/linux/if_tap.h|  5 
 include/linux/if_tun.h|  5 
 include/linux/ptr_ring.h  | 65 +++
 include/linux/skb_array.h | 25 +
 7 files changed, 209 insertions(+), 18 deletions(-)

-- 
2.7.4

Re: [RFC][PATCH 2/4] printk: offload printing from wake_up_klogd_work_func()

[Sergey Senozhatsky]

On (03/20/17 17:09), Petr Mladek wrote:
[..]
> > I don't want that printk_kthread_need_flush_console to exist. instead,
> > I think, I want to move printk_pending out of per-cpu memory and use a
> > global printk_pending. set PRINTK_PENDING_OUTPUT bit to true in
> > vprintk_emit(), clear it in console_unlock(). and make both printk_kthread
> > scheduling condition and console_unlock() retry path depend on
> > `printk_pending == 0' being true.
> 
> I like the idea. The things closely related.
>  
> > something like below (the code is ugly and lacks a ton of barriers, etc.
> > etc.)
> 
> Sigh, I wanted to add few comments and it got me deeper than I wanted.

no worries, Petr.


[..]
> Anyway, it might make sense to do the change in more steps.

yes, sure. "per-CPU -> global printk_pending" transition first,
and then printk kthread.


[..]
> > +#define PRINTK_PENDING_WAKEUP  0x01
> > +#define PRINTK_PENDING_OUTPUT  0x02
> > +
> > +static int printk_pending = 0;
> 
> Something tells me that we need to use atomic_t. Otherwise, we could
> not safely manipulate the bits withtout a lock.

yes, I'm doing atomic set_bit/test_bit/clear_bit in current (unpublished) 
version.


> Alternative solution would be to use two separate variables.
> This might make the code easier to read. I think that they
> were combined only to safe space in the per-CPU area.

hm. I think one variable still can work for us; but can split it.

as of rename. dunno. I'm kinda OK with its current name.
PENDING_OUTPUT looks a bit better that POKE_CONSOLE to me.


[..]
> > if (console_suspended) {
> > +   printk_pending &= ~PRINTK_PENDING_OUTPUT;
> 
> Hmm, this is pretty non-intuitive. I guess that it is needed to
> avoid a busy cycle in the printk kthread?

it absolutely is.
sorry, the "code" I posted was too cryptic.

> > up_console_sem();
> > return;
> > }
> > @@ -2242,6 +2247,8 @@ void console_unlock(void)
> > console_may_schedule = 0;
> >  
> >  again:
> > +   wake_klogd = printk_pending & PRINTK_PENDING_WAKEUP;
> > +   printk_pending = 0;
> 
> This might be racy. PRINTK_PENDING_WAKEUP is set without
> a lock in bust_spinlocks() via wake_up_klogd(). The above
> code read and clears the state non-atomically.

the patch I'm looking at right now does atomic set_bit() and a bunch of
atomic test_and_clear_bit/test_bit/etc.

> > /*
> >  * We released the console_sem lock, so we need to recheck if
> >  * cpu is online and (if not) is there at least one CON_ANYTIME
> > @@ -2330,15 +2337,16 @@ void console_unlock(void)
> >  * flush, no worries.
> >  */
> > raw_spin_lock(_lock);
> > -   retry = console_seq != log_next_seq;
> > +   if (printk_pending != 0 || console_seq != log_next_seq)
> 
> printk_pending != 0 also when PRINTK_PENDING_WAKEUP is set.

yes.

> I would do it the other way. I would clear PRINTK_PENDING_OUTPUT
> when console_seq == log_next_seq and keep the check as is here.
[..]
> > +   retry = true;
> > raw_spin_unlock(_lock);
> > printk_safe_exit_irqrestore(flags);
> >  
> > -   if (retry && console_trylock())
> > -   goto again;
> > -
> > if (wake_klogd)
> > wake_up_klogd();
> > +
> > +   if (retry && console_trylock())
> > +   goto again;
> 
> Why do you actually modify the logic for klogd()?
> It might make sense but it is questionable. For example,
> klogd() will need logbuf_lock as well. It might fight over
> it with the console when the again target is used.
> I would do it in separate patch and probably not
> in this patchset.

I just wanted to keep printk_prnding check simpler and I figured out
that klogd logbuf_lock contention will not be something new, because
of the while() loop in kthread_printk function

printk_tkread func
while (1) {
if (!pending_output)
schedule();

console_lock()
console_unlock()
wake_up klogd   /*
 * and may be do another
 * console_lock() straight 
ahead if pending_output != 0
 */
}

but yes. I'll drop that part and will handle only PRINTK_PENDING_OUTPUT
bit in console_unlock(), leaving the PRINTK_PENDING_WAKEUP stuff to
irq work.

I'll try to send out a refreshed version soon.


> >  EXPORT_SYMBOL(console_unlock);
> >  
> > @@ -2722,19 +2730,9 @@ static int __init printk_late_init(void)
> >  late_initcall(printk_late_init);
> >  
> >  #if defined CONFIG_PRINTK
> > -/*
> > - * Delayed printk version, for scheduler-internal messages:
> > - */
> > -#define PRINTK_PENDING_WAKEUP  0x01
> > -#define PRINTK_PENDING_OUTPUT  0x02
> > -
> > -static DEFINE_PER_CPU(int, printk_pending);
> 
> BTW: wake_up_klogd_work does not need to be per-CPU as well.
> irq_work 

Re: [RFC][PATCH 2/4] printk: offload printing from wake_up_klogd_work_func()

[Sergey Senozhatsky]

On (03/20/17 17:09), Petr Mladek wrote:
[..]
> > I don't want that printk_kthread_need_flush_console to exist. instead,
> > I think, I want to move printk_pending out of per-cpu memory and use a
> > global printk_pending. set PRINTK_PENDING_OUTPUT bit to true in
> > vprintk_emit(), clear it in console_unlock(). and make both printk_kthread
> > scheduling condition and console_unlock() retry path depend on
> > `printk_pending == 0' being true.
> 
> I like the idea. The things closely related.
>  
> > something like below (the code is ugly and lacks a ton of barriers, etc.
> > etc.)
> 
> Sigh, I wanted to add few comments and it got me deeper than I wanted.

no worries, Petr.


[..]
> Anyway, it might make sense to do the change in more steps.

yes, sure. "per-CPU -> global printk_pending" transition first,
and then printk kthread.


[..]
> > +#define PRINTK_PENDING_WAKEUP  0x01
> > +#define PRINTK_PENDING_OUTPUT  0x02
> > +
> > +static int printk_pending = 0;
> 
> Something tells me that we need to use atomic_t. Otherwise, we could
> not safely manipulate the bits withtout a lock.

yes, I'm doing atomic set_bit/test_bit/clear_bit in current (unpublished) 
version.


> Alternative solution would be to use two separate variables.
> This might make the code easier to read. I think that they
> were combined only to safe space in the per-CPU area.

hm. I think one variable still can work for us; but can split it.

as of rename. dunno. I'm kinda OK with its current name.
PENDING_OUTPUT looks a bit better that POKE_CONSOLE to me.


[..]
> > if (console_suspended) {
> > +   printk_pending &= ~PRINTK_PENDING_OUTPUT;
> 
> Hmm, this is pretty non-intuitive. I guess that it is needed to
> avoid a busy cycle in the printk kthread?

it absolutely is.
sorry, the "code" I posted was too cryptic.

> > up_console_sem();
> > return;
> > }
> > @@ -2242,6 +2247,8 @@ void console_unlock(void)
> > console_may_schedule = 0;
> >  
> >  again:
> > +   wake_klogd = printk_pending & PRINTK_PENDING_WAKEUP;
> > +   printk_pending = 0;
> 
> This might be racy. PRINTK_PENDING_WAKEUP is set without
> a lock in bust_spinlocks() via wake_up_klogd(). The above
> code read and clears the state non-atomically.

the patch I'm looking at right now does atomic set_bit() and a bunch of
atomic test_and_clear_bit/test_bit/etc.

> > /*
> >  * We released the console_sem lock, so we need to recheck if
> >  * cpu is online and (if not) is there at least one CON_ANYTIME
> > @@ -2330,15 +2337,16 @@ void console_unlock(void)
> >  * flush, no worries.
> >  */
> > raw_spin_lock(_lock);
> > -   retry = console_seq != log_next_seq;
> > +   if (printk_pending != 0 || console_seq != log_next_seq)
> 
> printk_pending != 0 also when PRINTK_PENDING_WAKEUP is set.

yes.

> I would do it the other way. I would clear PRINTK_PENDING_OUTPUT
> when console_seq == log_next_seq and keep the check as is here.
[..]
> > +   retry = true;
> > raw_spin_unlock(_lock);
> > printk_safe_exit_irqrestore(flags);
> >  
> > -   if (retry && console_trylock())
> > -   goto again;
> > -
> > if (wake_klogd)
> > wake_up_klogd();
> > +
> > +   if (retry && console_trylock())
> > +   goto again;
> 
> Why do you actually modify the logic for klogd()?
> It might make sense but it is questionable. For example,
> klogd() will need logbuf_lock as well. It might fight over
> it with the console when the again target is used.
> I would do it in separate patch and probably not
> in this patchset.

I just wanted to keep printk_prnding check simpler and I figured out
that klogd logbuf_lock contention will not be something new, because
of the while() loop in kthread_printk function

printk_tkread func
while (1) {
if (!pending_output)
schedule();

console_lock()
console_unlock()
wake_up klogd   /*
 * and may be do another
 * console_lock() straight 
ahead if pending_output != 0
 */
}

but yes. I'll drop that part and will handle only PRINTK_PENDING_OUTPUT
bit in console_unlock(), leaving the PRINTK_PENDING_WAKEUP stuff to
irq work.

I'll try to send out a refreshed version soon.


> >  EXPORT_SYMBOL(console_unlock);
> >  
> > @@ -2722,19 +2730,9 @@ static int __init printk_late_init(void)
> >  late_initcall(printk_late_init);
> >  
> >  #if defined CONFIG_PRINTK
> > -/*
> > - * Delayed printk version, for scheduler-internal messages:
> > - */
> > -#define PRINTK_PENDING_WAKEUP  0x01
> > -#define PRINTK_PENDING_OUTPUT  0x02
> > -
> > -static DEFINE_PER_CPU(int, printk_pending);
> 
> BTW: wake_up_klogd_work does not need to be per-CPU as well.
> irq_work 

[PATCH net-next 2/2] net: dwc-xlgmac: add module license

[Jie Deng]

Fix the warning about missing MODULE_LICENSE().

Signed-off-by: Jie Deng 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index 53ad707..07def2b 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -21,6 +21,8 @@
 #include "dwc-xlgmac.h"
 #include "dwc-xlgmac-reg.h"
 
+MODULE_LICENSE("Dual BSD/GPL");
+
 static int debug = -1;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "DWC ethernet debug level (0=none,...,16=all)");
-- 
1.9.1

[PATCH net-next 2/2] net: dwc-xlgmac: add module license

[Jie Deng]

Fix the warning about missing MODULE_LICENSE().

Signed-off-by: Jie Deng 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index 53ad707..07def2b 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -21,6 +21,8 @@
 #include "dwc-xlgmac.h"
 #include "dwc-xlgmac-reg.h"
 
+MODULE_LICENSE("Dual BSD/GPL");
+
 static int debug = -1;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "DWC ethernet debug level (0=none,...,16=all)");
-- 
1.9.1

[PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

[Jie Deng]

This patch adds declaration of dual license in file headers.

Signed-off-by: Jie Deng 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c   | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-net.c| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-reg.h| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac.h| 6 ++
 7 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index 726d78a..53ad707 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
index 55c796e..bfe810e 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
index 5cf3e90..e2a58ec 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
index 5e8428b..6acf86c 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
index 504e80d..386bafe 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git 

[PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

[Jie Deng]

This patch adds declaration of dual license in file headers.

Signed-off-by: Jie Deng 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c   | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-net.c| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-reg.h| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac.h| 6 ++
 7 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index 726d78a..53ad707 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
index 55c796e..bfe810e 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
index 5cf3e90..e2a58ec 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
index 5e8428b..6acf86c 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
index 504e80d..386bafe 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git 

Re: [Linaro-acpi] [PATCH v21 13/13] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver

[Fu Wei]

Hi Mark, Lurndal,


On 21 March 2017 at 02:50, Lurndal, Scott  wrote:
> On Mon, Mar 20, 2017 at 06:09:50PM +, Mark Rutland wrote:
>> On Tue, Mar 21, 2017 at 01:57:58AM +0800, Fu Wei wrote:
>> > On 18 March 2017 at 04:01, Mark Rutland  wrote:
>> > > On Tue, Feb 07, 2017 at 02:50:15AM +0800, fu@linaro.org wrote:
>>
>> > > I've not been able to find where the ACPI spec says that zero is not a
>> > > valid GSIV. This may simply be an oversight/ambiguity in the spec.
>> > >
>> > > Is there any statement to that effect?
>> >
>> > you are right, zero is a  valid GSIV, I will delete this check. Thanks
>>
>> That being the case, how does one describe a watchdog that does not have
>> an interrupt?
>>
>> As I mentioned, I think this is an oversight/ambiguity in the spec tat
>> we should address.
>>
>> > > My reading of SBSA is that there is one watchdog in the system.
>> > >
>> > > Is that not the case?
>> >
>> > do you mean:
>> > ---
>> > 4.2.4 Watchdogs
>> > The base server system implements a Generic Watchdog as specified in
>> > APPENDIX A: Generic Watchdog.
>> > ---
>> >
>> > I am not sure about that if this is saying "we only have one SBSA
>> > watchdog in a system"
>> >
>> > would you let me know where mention it? Do I miss something?
>>
>> My reading was that the 'a' above meant a single element. i.e.
>>
>>   The base server system implements _a_ Generic Watchdog as
>>   specified in APPENDIX A: Generic Watchdog.
>
>   It is a requirement of a conforming implementation that there
> be a generic watchdog (impl as per the appendix).   That doesn't preclude
> an implmentation from providing additional watchdogs (for example, if
> the processor implements EL3, it is likely that an implementation
> will include a secure watchdog as well as a non-secure watchdog).
>
>   The SBSA describes the minimal hardware requirements for a
> compliant server.

So I think, for the SBSA watchdog:

(1) there maybe more then one non-secure watchdog in GTDT

(2) we may also need to skip  secure watchdogs in GTDT,
and only register non-secure watchdogs into platform resources.

Please correct me, if I misunderstand something.

>
> scott



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH] power: bq24190_charger: mark PM functions as __maybe_unused

[Mark Greer]

On Mon, Mar 20, 2017 at 02:14:15PM +0100, Arnd Bergmann wrote:
> Without CONFIG_PM, we get a harmless warning:
> 
> drivers/power/supply/bq24190_charger.c:1514:12: error: 
> 'bq24190_runtime_resume' defined but not used [-Werror=unused-function]
> drivers/power/supply/bq24190_charger.c:1501:12: error: 
> 'bq24190_runtime_suspend' defined but not used [-Werror=unused-function]
> 
> To avoid the warning, we can mark all four PM functions as __maybe_unused,
> which also lets us remove the incorrect #ifdef.
> 
> Fixes: 3d8090cba638 ("power: bq24190_charger: Check the interrupt status on 
> resume")
> Signed-off-by: Arnd Bergmann 
> ---

Probably too late but if it isn't...

Acked-by: Mark Greer 

Re: [Linaro-acpi] [PATCH v21 13/13] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver

[Fu Wei]

Hi Mark, Lurndal,


On 21 March 2017 at 02:50, Lurndal, Scott  wrote:
> On Mon, Mar 20, 2017 at 06:09:50PM +, Mark Rutland wrote:
>> On Tue, Mar 21, 2017 at 01:57:58AM +0800, Fu Wei wrote:
>> > On 18 March 2017 at 04:01, Mark Rutland  wrote:
>> > > On Tue, Feb 07, 2017 at 02:50:15AM +0800, fu@linaro.org wrote:
>>
>> > > I've not been able to find where the ACPI spec says that zero is not a
>> > > valid GSIV. This may simply be an oversight/ambiguity in the spec.
>> > >
>> > > Is there any statement to that effect?
>> >
>> > you are right, zero is a  valid GSIV, I will delete this check. Thanks
>>
>> That being the case, how does one describe a watchdog that does not have
>> an interrupt?
>>
>> As I mentioned, I think this is an oversight/ambiguity in the spec tat
>> we should address.
>>
>> > > My reading of SBSA is that there is one watchdog in the system.
>> > >
>> > > Is that not the case?
>> >
>> > do you mean:
>> > ---
>> > 4.2.4 Watchdogs
>> > The base server system implements a Generic Watchdog as specified in
>> > APPENDIX A: Generic Watchdog.
>> > ---
>> >
>> > I am not sure about that if this is saying "we only have one SBSA
>> > watchdog in a system"
>> >
>> > would you let me know where mention it? Do I miss something?
>>
>> My reading was that the 'a' above meant a single element. i.e.
>>
>>   The base server system implements _a_ Generic Watchdog as
>>   specified in APPENDIX A: Generic Watchdog.
>
>   It is a requirement of a conforming implementation that there
> be a generic watchdog (impl as per the appendix).   That doesn't preclude
> an implmentation from providing additional watchdogs (for example, if
> the processor implements EL3, it is likely that an implementation
> will include a secure watchdog as well as a non-secure watchdog).
>
>   The SBSA describes the minimal hardware requirements for a
> compliant server.

So I think, for the SBSA watchdog:

(1) there maybe more then one non-secure watchdog in GTDT

(2) we may also need to skip  secure watchdogs in GTDT,
and only register non-secure watchdogs into platform resources.

Please correct me, if I misunderstand something.

>
> scott



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH] power: bq24190_charger: mark PM functions as __maybe_unused

[Mark Greer]

On Mon, Mar 20, 2017 at 02:14:15PM +0100, Arnd Bergmann wrote:
> Without CONFIG_PM, we get a harmless warning:
> 
> drivers/power/supply/bq24190_charger.c:1514:12: error: 
> 'bq24190_runtime_resume' defined but not used [-Werror=unused-function]
> drivers/power/supply/bq24190_charger.c:1501:12: error: 
> 'bq24190_runtime_suspend' defined but not used [-Werror=unused-function]
> 
> To avoid the warning, we can mark all four PM functions as __maybe_unused,
> which also lets us remove the incorrect #ifdef.
> 
> Fixes: 3d8090cba638 ("power: bq24190_charger: Check the interrupt status on 
> resume")
> Signed-off-by: Arnd Bergmann 
> ---

Probably too late but if it isn't...

Acked-by: Mark Greer 

Re: [PATCH] PCI: rockchip: don't leak the PCI resource list

[jeffy]

Hi brian,

On 03/21/2017 10:21 AM, Brian Norris wrote:

On Tue, Mar 21, 2017 at 09:25:16AM +0800, Shawn Lin wrote:

On 2017/3/21 6:49, Brian Norris wrote:

This list is local to the probe() function. We should free it up in both
the success case and the error case, but currently we're only freeing it
in the error case (see commit f1d722b607d6 ("PCI: rockchip: Fix
rockchip_pcie_probe() error path to free resource list")).

Caught by kmemleak, when doing repeated bind/unbind tests.



It doesn't look natural to free it in probe, instead it looks more
like we should do the cleanup work when calling .remove


Hmm, I did write this one up pretty quickly, so I might have gotten it a
bit wrong. It's not clear there's a *real* problem with this patch,
since the bridge's window list doesn't actually get used much later, but
I agree this isn't correct.

And actually, I think my patch is a red herring; the leak is still
there. I notice that the resource list is actually freed in
pci_release_host_bridge_dev() already anyway.


I didn't know if there is something that still use this resource
, for instance, hotplug? But I noticed it from Bjron's statement[1]
that "The struct resource for each host bridge window must live as long
as the host bridge itself". So I didn't free it when finishing probe.
I guess the proper fix is to do it in pci_remove_root_bus or somewhere
of the cleanup code if I undertand it correctly.


That thread is talking about a different issue; in that driver, the
'struct resource' is on the stack. That's not good. In our case, it's
just the resource list head that's on the stack, which is fine. The
relevant entries get spliced onto a longer-lived list in the end.

But then, we have these to consider for leaks:

(a) the 'resource_entry's allocated in
of_pci_get_host_bridge_resources() (via pci_add_resource() and
pci_add_resource_offset())

(b) the 'resource's allocated in
of_pci_get_host_bridge_resources(), to go with each of the
'resource_entry's from (b)

As noted above, I think (a) is actually taken care of (and so my current
patch is not needed). The problem is only with (b). (I think?)
yes, it looks like there's no way to free resources allocated in 
of_pci_get_host_bridge_resources, expect for the err path: 
kfree(window->res).


i think it's a common issue, which may not get fix in rockchip pci driver.

maybe we should modify of_pci_get_host_bridge_resources, pass the struct 
device to it, and change all kzalloc to devm_kzalloc(also remove the kfree)





I'll double check this all tomorrow.

Brian


[1]: https://lkml.org/lkml/2017/2/8/802


Signed-off-by: Brian Norris 
---
drivers/pci/host/pcie-rockchip.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index bd6df7254de4..8087a0698d65 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1396,6 +1396,7 @@ static int rockchip_pcie_probe(struct platform_device 
*pdev)
goto err_free_res;
}
rockchip->root_bus = bus;
+   pci_free_resource_list();

pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);

Re: [PATCH] PCI: rockchip: don't leak the PCI resource list

[jeffy]

Hi brian,

On 03/21/2017 10:21 AM, Brian Norris wrote:

On Tue, Mar 21, 2017 at 09:25:16AM +0800, Shawn Lin wrote:

On 2017/3/21 6:49, Brian Norris wrote:

This list is local to the probe() function. We should free it up in both
the success case and the error case, but currently we're only freeing it
in the error case (see commit f1d722b607d6 ("PCI: rockchip: Fix
rockchip_pcie_probe() error path to free resource list")).

Caught by kmemleak, when doing repeated bind/unbind tests.



It doesn't look natural to free it in probe, instead it looks more
like we should do the cleanup work when calling .remove


Hmm, I did write this one up pretty quickly, so I might have gotten it a
bit wrong. It's not clear there's a *real* problem with this patch,
since the bridge's window list doesn't actually get used much later, but
I agree this isn't correct.

And actually, I think my patch is a red herring; the leak is still
there. I notice that the resource list is actually freed in
pci_release_host_bridge_dev() already anyway.


I didn't know if there is something that still use this resource
, for instance, hotplug? But I noticed it from Bjron's statement[1]
that "The struct resource for each host bridge window must live as long
as the host bridge itself". So I didn't free it when finishing probe.
I guess the proper fix is to do it in pci_remove_root_bus or somewhere
of the cleanup code if I undertand it correctly.


That thread is talking about a different issue; in that driver, the
'struct resource' is on the stack. That's not good. In our case, it's
just the resource list head that's on the stack, which is fine. The
relevant entries get spliced onto a longer-lived list in the end.

But then, we have these to consider for leaks:

(a) the 'resource_entry's allocated in
of_pci_get_host_bridge_resources() (via pci_add_resource() and
pci_add_resource_offset())

(b) the 'resource's allocated in
of_pci_get_host_bridge_resources(), to go with each of the
'resource_entry's from (b)

As noted above, I think (a) is actually taken care of (and so my current
patch is not needed). The problem is only with (b). (I think?)
yes, it looks like there's no way to free resources allocated in 
of_pci_get_host_bridge_resources, expect for the err path: 
kfree(window->res).


i think it's a common issue, which may not get fix in rockchip pci driver.

maybe we should modify of_pci_get_host_bridge_resources, pass the struct 
device to it, and change all kzalloc to devm_kzalloc(also remove the kfree)





I'll double check this all tomorrow.

Brian


[1]: https://lkml.org/lkml/2017/2/8/802


Signed-off-by: Brian Norris 
---
drivers/pci/host/pcie-rockchip.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index bd6df7254de4..8087a0698d65 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -1396,6 +1396,7 @@ static int rockchip_pcie_probe(struct platform_device 
*pdev)
goto err_free_res;
}
rockchip->root_bus = bus;
+   pci_free_resource_list();

pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);

[PATCH 2/2] staging: vt6656: rf.c: spaces preferred around that '-'

[Matthew Giassa]

Resolving 2 checkpatch warnings generated due to:
CHECK: spaces preferred around that '-'

Signed-off-by: Matthew Giassa 
---
 drivers/staging/vt6656/rf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 0e3a62a..fe09627 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -611,7 +611,7 @@ int vnt_rf_write_embedded(struct vnt_private *priv, u32 
data)
reg_data[3] = (u8)(data >> 24);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE_IFRF,
-   0, 0, ARRAY_SIZE(reg_data), reg_data);
+   0, 0, ARRAY_SIZE(reg_data), reg_data);
 
return true;
 }
@@ -643,9 +643,9 @@ int vnt_rf_setpower(struct vnt_private *priv, u32 rate, u32 
channel)
case RATE_48M:
case RATE_54M:
if (channel > CB_MAX_CHANNEL_24G)
-   power = priv->ofdm_a_pwr_tbl[channel-15];
+   power = priv->ofdm_a_pwr_tbl[channel - 15];
else
-   power = priv->ofdm_pwr_tbl[channel-1];
+   power = priv->ofdm_pwr_tbl[channel - 1];
break;
}
 
-- 
2.7.4

[PATCH 2/2] staging: vt6656: rf.c: spaces preferred around that '-'

[Matthew Giassa]

Resolving 2 checkpatch warnings generated due to:
CHECK: spaces preferred around that '-'

Signed-off-by: Matthew Giassa 
---
 drivers/staging/vt6656/rf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 0e3a62a..fe09627 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -611,7 +611,7 @@ int vnt_rf_write_embedded(struct vnt_private *priv, u32 
data)
reg_data[3] = (u8)(data >> 24);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE_IFRF,
-   0, 0, ARRAY_SIZE(reg_data), reg_data);
+   0, 0, ARRAY_SIZE(reg_data), reg_data);
 
return true;
 }
@@ -643,9 +643,9 @@ int vnt_rf_setpower(struct vnt_private *priv, u32 rate, u32 
channel)
case RATE_48M:
case RATE_54M:
if (channel > CB_MAX_CHANNEL_24G)
-   power = priv->ofdm_a_pwr_tbl[channel-15];
+   power = priv->ofdm_a_pwr_tbl[channel - 15];
else
-   power = priv->ofdm_pwr_tbl[channel-1];
+   power = priv->ofdm_pwr_tbl[channel - 1];
break;
}
 
-- 
2.7.4

[PATCH] staging: vt6656: rf.c: resolve all checkpatch issues.

[Matthew Giassa]

These patches address a few outstanding checkpatch warnings/errors in
rf.c, mainly due to space/indentation (style) issues.

---
 drivers/staging/vt6656/rf.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)
---

Re: [PATCH] staging: radio-bcm2048: Fix checkpatch warnings: WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

[kbuild test robot]

Hi unknown,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc3 next-20170320]
[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/unknown/staging-radio-bcm2048-Fix-checkpatch-warnings-WARNING-Prefer-unsigned-int-to-bare-use-of-unsigned/20170321-105721
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_power_state_write':
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2031:50: error: two or more 
>> data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2031:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_mute_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2032:43: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
  ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2032:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_audio_route_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2033:50: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2033:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_dac_output_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2034:49: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2034:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_hi_lo_injection_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2036:57: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2036:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_frequency_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2037:51: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
  ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2037:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_af_frequency_write':
   drivers/staging/media/bcm2048/radio-bcm2048

[PATCH] staging: vt6656: rf.c: resolve all checkpatch issues.

[Matthew Giassa]

These patches address a few outstanding checkpatch warnings/errors in
rf.c, mainly due to space/indentation (style) issues.

---
 drivers/staging/vt6656/rf.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)
---

Re: [PATCH] staging: radio-bcm2048: Fix checkpatch warnings: WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

[kbuild test robot]

Hi unknown,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc3 next-20170320]
[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/unknown/staging-radio-bcm2048-Fix-checkpatch-warnings-WARNING-Prefer-unsigned-int-to-bare-use-of-unsigned/20170321-105721
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_power_state_write':
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2031:50: error: two or more 
>> data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2031:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_mute_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2032:43: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
  ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2032:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_audio_route_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2033:50: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2033:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_dac_output_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2034:49: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2034:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_hi_lo_injection_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2036:57: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2036:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_frequency_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2037:51: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
  ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1951:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:2037:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_af_frequency_write':
   drivers/staging/media/bcm2048/radio-bcm2048

Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

[Chanwoo Choi]

On 2017년 03월 20일 22:00, Andy Shevchenko wrote:
> On Mon, 2017-03-20 at 10:33 +0900, Chanwoo Choi wrote:
>> On 2017년 03월 17일 18:55, Hans de Goede wrote:
> 
>>> +static const struct platform_device_id cht_wc_extcon_table[] = {
>>> +   { .name = "cht_wcove_pwrsrc" },
>>
>> You use the 'cht_wc' word instead of 'cht_wcove_pwrsrc'.
>> So, To maintain the consistency, you better to use the 'cht-wc' as the
>> name.
>> - I prefer to use '-' instead of '_' in the name.
>>  .name ="cht-wc"
> 
> I would keep as Hans did for the sake of consistency among all Whiskey
> Cove device drivers (and predecessors like Crystal Cove).

The 'wcove' short word is not used in this patch.
If the author want to use the 'wcove', I recommend that
you should use the 'wcove' instead of 'wc' in this patch.

And, I think that  'pwrsrc' is not ambiguous.
Hans might use the 'pwrsrc' as the 'Power Source'.
But, this driver is not power source. Instead,
this driver supports the detection of external connector.

I think 'power source' means the power supply instead of detector.

> 
> I understand your point from extcon subsystem view, but PMICs like
> Whiskey Cove are multi-functional devices, and thus naming across them
> (same prefix in use to be precise) is better idea.
> 
>>
>>> +   {},
>>> +};
>>> +MODULE_DEVICE_TABLE(platform, cht_wc_extcon_table);
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 03/15] extcon: cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon driver

[Chanwoo Choi]

On 2017년 03월 20일 22:00, Andy Shevchenko wrote:
> On Mon, 2017-03-20 at 10:33 +0900, Chanwoo Choi wrote:
>> On 2017년 03월 17일 18:55, Hans de Goede wrote:
> 
>>> +static const struct platform_device_id cht_wc_extcon_table[] = {
>>> +   { .name = "cht_wcove_pwrsrc" },
>>
>> You use the 'cht_wc' word instead of 'cht_wcove_pwrsrc'.
>> So, To maintain the consistency, you better to use the 'cht-wc' as the
>> name.
>> - I prefer to use '-' instead of '_' in the name.
>>  .name ="cht-wc"
> 
> I would keep as Hans did for the sake of consistency among all Whiskey
> Cove device drivers (and predecessors like Crystal Cove).

The 'wcove' short word is not used in this patch.
If the author want to use the 'wcove', I recommend that
you should use the 'wcove' instead of 'wc' in this patch.

And, I think that  'pwrsrc' is not ambiguous.
Hans might use the 'pwrsrc' as the 'Power Source'.
But, this driver is not power source. Instead,
this driver supports the detection of external connector.

I think 'power source' means the power supply instead of detector.

> 
> I understand your point from extcon subsystem view, but PMICs like
> Whiskey Cove are multi-functional devices, and thus naming across them
> (same prefix in use to be precise) is better idea.
> 
>>
>>> +   {},
>>> +};
>>> +MODULE_DEVICE_TABLE(platform, cht_wc_extcon_table);
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH 1/2] staging: vt6656: rf.c: alignment should match open parentheses

[Matthew Giassa]

Resolving 5 instances of checkpatch error/warning statements generated
due to:
ERROR: code indent should use tabs where possible
CHECK: Alignment should match open parenthesis

Signed-off-by: Matthew Giassa 
---
 drivers/staging/vt6656/rf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..0e3a62a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length,
+   array);
 
length2 -= length;
value += length;
-- 
2.7.4

[PATCH 1/2] staging: vt6656: rf.c: alignment should match open parentheses

[Matthew Giassa]

Resolving 5 instances of checkpatch error/warning statements generated
due to:
ERROR: code indent should use tabs where possible
CHECK: Alignment should match open parenthesis

Signed-off-by: Matthew Giassa 
---
 drivers/staging/vt6656/rf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..0e3a62a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length,
+   array);
 
length2 -= length;
value += length;
-- 
2.7.4