Re: MD-RAID: Use seq_putc() in three status functions?

[Hannes Reinecke]

On 10/16/2016 07:10 PM, SF Markus Elfring wrote:
>> Does it improve code? Does it improve anything?
> 
> Yes. - I got such an impression.
> 
> * Is it more efficient to call the function "seq_printf" for the desired data 
> processing
>   for a single character than to pass it to the function "" in a string?
> 
> * Will the required data transfer shrink a bit for the affected functions 
> because of
>   such a change?
> 
Which are questions _you_ should be able to answer.
It's your patch, after all.
Once you do (and prove that the answer is 'yes' to the above two
questions) the patch will be applied.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: MD-RAID: Use seq_putc() in three status functions?

[Hannes Reinecke]

On 10/16/2016 07:10 PM, SF Markus Elfring wrote:
>> Does it improve code? Does it improve anything?
> 
> Yes. - I got such an impression.
> 
> * Is it more efficient to call the function "seq_printf" for the desired data 
> processing
>   for a single character than to pass it to the function "" in a string?
> 
> * Will the required data transfer shrink a bit for the affected functions 
> because of
>   such a change?
> 
Which are questions _you_ should be able to answer.
It's your patch, after all.
Once you do (and prove that the answer is 'yes' to the above two
questions) the patch will be applied.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Tomi Valkeinen]

On 15/10/16 20:42, Sekhar Nori wrote:

>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..32908ae 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
> 
>> @@ -399,6 +420,14 @@
>>  < 0 1>;
>>  dma-names = "tx", "rx";
>>  };
>> +
>> +display: display@213000 {
>> +compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
> 
> This should instead be:
> 
> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
> 
> as the closest match should appear first in the list.

Actually I don't think that's correct. The LCDC on da850 is not
compatible with the LCDC on AM335x. I think it should be just
"ti,da850-tilcdc".

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v6 17/17] dax: remove "depends on BROKEN" from FS_DAX_PMD

[Aneesh Kumar K.V]

Ross Zwisler  writes:

> Now that DAX PMD faults are once again working and are now participating in
> DAX's radix tree locking scheme, allow their config option to be enabled.
>
> Signed-off-by: Ross Zwisler 
> ---
>  fs/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 2bc7ad7..b6f0fce 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -55,7 +55,6 @@ config FS_DAX_PMD
>   depends on FS_DAX
>   depends on ZONE_DEVICE
>   depends on TRANSPARENT_HUGEPAGE
> - depends on BROKEN
>  
>  endif # BLOCK


This series made dax_pmd_fault return VM_FAULT_FALLBACK in [PATCH v6 09/17] 
dax: remove dax_pmd_fault(). 
That essentially disable dax pmd for ext4. Any plans to fix that ?

-aneesh

Re: [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Tomi Valkeinen]

On 15/10/16 20:42, Sekhar Nori wrote:

>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..32908ae 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
> 
>> @@ -399,6 +420,14 @@
>>  < 0 1>;
>>  dma-names = "tx", "rx";
>>  };
>> +
>> +display: display@213000 {
>> +compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
> 
> This should instead be:
> 
> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
> 
> as the closest match should appear first in the list.

Actually I don't think that's correct. The LCDC on da850 is not
compatible with the LCDC on AM335x. I think it should be just
"ti,da850-tilcdc".

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v6 17/17] dax: remove "depends on BROKEN" from FS_DAX_PMD

[Aneesh Kumar K.V]

Ross Zwisler  writes:

> Now that DAX PMD faults are once again working and are now participating in
> DAX's radix tree locking scheme, allow their config option to be enabled.
>
> Signed-off-by: Ross Zwisler 
> ---
>  fs/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 2bc7ad7..b6f0fce 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -55,7 +55,6 @@ config FS_DAX_PMD
>   depends on FS_DAX
>   depends on ZONE_DEVICE
>   depends on TRANSPARENT_HUGEPAGE
> - depends on BROKEN
>  
>  endif # BLOCK


This series made dax_pmd_fault return VM_FAULT_FALLBACK in [PATCH v6 09/17] 
dax: remove dax_pmd_fault(). 
That essentially disable dax pmd for ext4. Any plans to fix that ?

-aneesh

Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

[Viresh Kumar]

On Sun, Oct 16, 2016 at 3:29 PM, Pankaj Bharadiya
 wrote:
> gb_audio_manager_module_descriptor's cport field is actually used to
> manage and pass interface id to user space.
>
> Thus rename gb_audio_manager_module_descriptor's 'cport' field and
> few other things to avoid confusion.
>
> Signed-off-by: Pankaj Bharadiya 
> ---
>  drivers/staging/greybus/audio_manager.h|  2 +-
>  drivers/staging/greybus/audio_manager_module.c | 20 ++--
>  drivers/staging/greybus/audio_manager_sysfs.c  |  4 ++--
>  drivers/staging/greybus/audio_module.c |  2 +-
>  4 files changed, 14 insertions(+), 14 deletions(-)

Acked-by: Viresh Kumar 

Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

[Viresh Kumar]

On Sun, Oct 16, 2016 at 3:29 PM, Pankaj Bharadiya
 wrote:
> gb_audio_manager_module_descriptor's cport field is actually used to
> manage and pass interface id to user space.
>
> Thus rename gb_audio_manager_module_descriptor's 'cport' field and
> few other things to avoid confusion.
>
> Signed-off-by: Pankaj Bharadiya 
> ---
>  drivers/staging/greybus/audio_manager.h|  2 +-
>  drivers/staging/greybus/audio_manager_module.c | 20 ++--
>  drivers/staging/greybus/audio_manager_sysfs.c  |  4 ++--
>  drivers/staging/greybus/audio_module.c |  2 +-
>  4 files changed, 14 insertions(+), 14 deletions(-)

Acked-by: Viresh Kumar 

Re: [PATCH v1 00/10] *** imx-sdma: misc fix ***

[Vinod Koul]

On Mon, Oct 17, 2016 at 01:51:26PM +0900, Jiada Wang wrote:
> Hello community
> 
> Is there any comment regarding this patch set?

I dont seem to have this, can you please rebase this and resend..

-- 
~Vinod

Re: [PATCH v1 00/10] *** imx-sdma: misc fix ***

[Vinod Koul]

On Mon, Oct 17, 2016 at 01:51:26PM +0900, Jiada Wang wrote:
> Hello community
> 
> Is there any comment regarding this patch set?

I dont seem to have this, can you please rebase this and resend..

-- 
~Vinod

[RFC PATCH v3 2/2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

[R. Parameswaran]

[v3: Picked up review comments from James Chapman, added a
 function  to compute ip header + ip option overhead on a socket, and factored
 it  into L2TP change-set, RFC, would like early feedback on name and
 placement  of new function while I test this.

 Part 2/2: Changes in l2tp_eth.c, using the new API from part 1]

>From f4066da53e781ef167055c1e89ca1a7819215a40 Mon Sep 17 00:00:00 2001
From: "R. Parameswaran" 
Date: Sun, 16 Oct 2016 20:27:20 -0700

In existing kernel code, when setting up the L2TP interface, all of the
tunnel encapsulation headers are not taken into account when setting
up the MTU on the  L2TP logical interface device. Due to this, the
packets created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, which leads to
needless fragmentation once the L2TP packet is encapsulated in an outer IP
packet.

Specifically, the MTU calculation  does not take into account the (outer)
IP header imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner L2TP packet prior to encapsulation. The patch posted
here takes care of these.

Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
patch uses the PMTU mechanism and the dst entry in the L2TP tunnel socket
to directly pull up the underlay MTU (as the baseline number on top of
which the encapsulation headers are factored in).  Ethernet MTU is
assumed as a fallback only if this fails.

Picked up review comments from James Chapman, added a function
to compute ip header + ip option overhead on a socket, and factored it
into L2TP change-set.

Signed-off-by: nprac...@brocade.com,
Signed-off-by: bh...@brocade.com,
Signed-off-by: rshea...@brocade.com,
Signed-off-by: dfaw...@brocade.com
---
 net/l2tp/l2tp_eth.c | 51 +++
 1 file changed, 47 insertions(+), 4 deletions(-)

diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 965f7e3..75eb5d3 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "l2tp_core.h"
 
@@ -206,6 +209,49 @@ static void l2tp_eth_show(struct seq_file *m, void *arg)
 }
 #endif
 
+static void l2tp_eth_adjust_mtu(struct l2tp_tunnel *tunnel,
+   struct l2tp_session *session,
+   struct net_device *dev)
+{
+   unsigned int overhead = 0;
+   struct dst_entry *dst;
+   u32 l3_overhead = 0;
+
+   if (session->mtu != 0) {
+   dev->mtu = session->mtu;
+   dev->needed_headroom += session->hdr_len;
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+   dev->needed_headroom += sizeof(struct udphdr);
+   return;
+   }
+   overhead = session->hdr_len;
+   l3_overhead = kernel_sock_ip_overhead(tunnel->sock);
+   if (!tunnel->sock || (l3_overhead == 0)) {
+   /* L3 Overhead couldn't be identified, dev mtu stays at 1500 */
+   return;
+   }
+   /* Adjust MTU, factor overhead - underlay L3, overlay L2 hdr*/
+   overhead += ETH_HLEN + l3_overhead;
+   /* Additionally, if the encap is UDP, account for UDP header size */
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+   overhead += sizeof(struct udphdr);
+   /* If PMTU discovery was enabled, use discovered MTU on L2TP device */
+   dst = sk_dst_get(tunnel->sock);
+   if (dst) {
+   /* dst_mtu will use PMTU if found, else fallback to intf MTU */
+   u32 pmtu = dst_mtu(dst);
+
+   if (pmtu != 0)
+   dev->mtu = pmtu;
+   dst_release(dst);
+   }
+   session->mtu = dev->mtu - overhead;
+   dev->mtu = session->mtu;
+   dev->needed_headroom += session->hdr_len;
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+   dev->needed_headroom += sizeof(struct udphdr);
+}
+
 static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 
peer_session_id, struct l2tp_session_cfg *cfg)
 {
struct net_device *dev;
@@ -255,11 +301,8 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, 
u32 session_id, u32 p
}
 
dev_net_set(dev, net);
-   if (session->mtu == 0)
-   session->mtu = dev->mtu - session->hdr_len;
-   dev->mtu = session->mtu;
-   dev->needed_headroom += session->hdr_len;
 
+   l2tp_eth_adjust_mtu(tunnel, session, dev);
priv = netdev_priv(dev);
priv->dev = dev;
priv->session = session;
-- 
2.1.4



> 
> I think keep it simple. A function to return the size of the IP header
> associated with any IP socket, not necessarily a tunnel socket. Don't
> mix in any MTU derivation logic or UDP header size etc.
> 
> Post code early as an RFC. You're more likely to get review feedback
> from others.
> 
> 
> 
> 

[RFC PATCH v3 2/2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

[R. Parameswaran]

[v3: Picked up review comments from James Chapman, added a
 function  to compute ip header + ip option overhead on a socket, and factored
 it  into L2TP change-set, RFC, would like early feedback on name and
 placement  of new function while I test this.

 Part 2/2: Changes in l2tp_eth.c, using the new API from part 1]

>From f4066da53e781ef167055c1e89ca1a7819215a40 Mon Sep 17 00:00:00 2001
From: "R. Parameswaran" 
Date: Sun, 16 Oct 2016 20:27:20 -0700

In existing kernel code, when setting up the L2TP interface, all of the
tunnel encapsulation headers are not taken into account when setting
up the MTU on the  L2TP logical interface device. Due to this, the
packets created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, which leads to
needless fragmentation once the L2TP packet is encapsulated in an outer IP
packet.

Specifically, the MTU calculation  does not take into account the (outer)
IP header imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner L2TP packet prior to encapsulation. The patch posted
here takes care of these.

Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
patch uses the PMTU mechanism and the dst entry in the L2TP tunnel socket
to directly pull up the underlay MTU (as the baseline number on top of
which the encapsulation headers are factored in).  Ethernet MTU is
assumed as a fallback only if this fails.

Picked up review comments from James Chapman, added a function
to compute ip header + ip option overhead on a socket, and factored it
into L2TP change-set.

Signed-off-by: nprac...@brocade.com,
Signed-off-by: bh...@brocade.com,
Signed-off-by: rshea...@brocade.com,
Signed-off-by: dfaw...@brocade.com
---
 net/l2tp/l2tp_eth.c | 51 +++
 1 file changed, 47 insertions(+), 4 deletions(-)

diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 965f7e3..75eb5d3 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "l2tp_core.h"
 
@@ -206,6 +209,49 @@ static void l2tp_eth_show(struct seq_file *m, void *arg)
 }
 #endif
 
+static void l2tp_eth_adjust_mtu(struct l2tp_tunnel *tunnel,
+   struct l2tp_session *session,
+   struct net_device *dev)
+{
+   unsigned int overhead = 0;
+   struct dst_entry *dst;
+   u32 l3_overhead = 0;
+
+   if (session->mtu != 0) {
+   dev->mtu = session->mtu;
+   dev->needed_headroom += session->hdr_len;
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+   dev->needed_headroom += sizeof(struct udphdr);
+   return;
+   }
+   overhead = session->hdr_len;
+   l3_overhead = kernel_sock_ip_overhead(tunnel->sock);
+   if (!tunnel->sock || (l3_overhead == 0)) {
+   /* L3 Overhead couldn't be identified, dev mtu stays at 1500 */
+   return;
+   }
+   /* Adjust MTU, factor overhead - underlay L3, overlay L2 hdr*/
+   overhead += ETH_HLEN + l3_overhead;
+   /* Additionally, if the encap is UDP, account for UDP header size */
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+   overhead += sizeof(struct udphdr);
+   /* If PMTU discovery was enabled, use discovered MTU on L2TP device */
+   dst = sk_dst_get(tunnel->sock);
+   if (dst) {
+   /* dst_mtu will use PMTU if found, else fallback to intf MTU */
+   u32 pmtu = dst_mtu(dst);
+
+   if (pmtu != 0)
+   dev->mtu = pmtu;
+   dst_release(dst);
+   }
+   session->mtu = dev->mtu - overhead;
+   dev->mtu = session->mtu;
+   dev->needed_headroom += session->hdr_len;
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+   dev->needed_headroom += sizeof(struct udphdr);
+}
+
 static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 
peer_session_id, struct l2tp_session_cfg *cfg)
 {
struct net_device *dev;
@@ -255,11 +301,8 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, 
u32 session_id, u32 p
}
 
dev_net_set(dev, net);
-   if (session->mtu == 0)
-   session->mtu = dev->mtu - session->hdr_len;
-   dev->mtu = session->mtu;
-   dev->needed_headroom += session->hdr_len;
 
+   l2tp_eth_adjust_mtu(tunnel, session, dev);
priv = netdev_priv(dev);
priv->dev = dev;
priv->session = session;
-- 
2.1.4



> 
> I think keep it simple. A function to return the size of the IP header
> associated with any IP socket, not necessarily a tunnel socket. Don't
> mix in any MTU derivation logic or UDP header size etc.
> 
> Post code early as an RFC. You're more likely to get review feedback
> from others.
> 
> 
> 
> 

Re: [PATCH v1 00/10] *** imx-sdma: misc fix ***

[Jiada Wang]

Hello community

Is there any comment regarding this patch set?

Thanks,
Jiada

On 05/17/2016 12:48 PM, Jiada Wang wrote:

this patch set contains the following changes
1. fix issues in cyclic dma
2. add support to SYNC DMA termination
3. avoid system hang, when SDMA channel 0 timeouts
4. add lock to prevent race condition

Jiada Wang (10):
  dma: imx-sdma: use chn_real_count to report residue for UART
  dma: imx-sdma: don't update BD in isr routine
  dma: imx-sdma: clear BD_RROR flag before pass it to sdma script
  dma: imx-sdma: update sdma channel status for cyclic dma
  dma: imx-sdma: add flag to indicate SDMA channel state
  dma: imx-sdma: add terminate_all support
  dma: imx-sdma: Add synchronization support
  dma: imx-sdma: abort updating channel when it has been terminated
  dma: imx-sdma: disable channel 0 when it timeouts
  dma: imx-sdma: clear channel0 interrupt bit in irq routine

 drivers/dma/imx-sdma.c | 113 +++--
 1 file changed, 82 insertions(+), 31 deletions(-)

Re: [PATCH v1 00/10] *** imx-sdma: misc fix ***

[Jiada Wang]

Hello community

Is there any comment regarding this patch set?

Thanks,
Jiada

On 05/17/2016 12:48 PM, Jiada Wang wrote:

this patch set contains the following changes
1. fix issues in cyclic dma
2. add support to SYNC DMA termination
3. avoid system hang, when SDMA channel 0 timeouts
4. add lock to prevent race condition

Jiada Wang (10):
  dma: imx-sdma: use chn_real_count to report residue for UART
  dma: imx-sdma: don't update BD in isr routine
  dma: imx-sdma: clear BD_RROR flag before pass it to sdma script
  dma: imx-sdma: update sdma channel status for cyclic dma
  dma: imx-sdma: add flag to indicate SDMA channel state
  dma: imx-sdma: add terminate_all support
  dma: imx-sdma: Add synchronization support
  dma: imx-sdma: abort updating channel when it has been terminated
  dma: imx-sdma: disable channel 0 when it timeouts
  dma: imx-sdma: clear channel0 interrupt bit in irq routine

 drivers/dma/imx-sdma.c | 113 +++--
 1 file changed, 82 insertions(+), 31 deletions(-)

Re: [PATCH 2/3] zram: support page-based parallel write

[Minchan Kim]

Hi Sergey,

On Fri, Oct 07, 2016 at 03:33:22PM +0900, Minchan Kim wrote:

< snip >

> > so the question is -- can we move this parallelization out of zram
> > and instead flush bdi in more than one kthread? how bad that would
> > be? can anyone else benefit from this?
> 
> Isn't it blk-mq you mentioned? With blk-mq, I have some concerns.
> 
> 1. read speed degradation
> 2. no work with rw_page
> 3. more memory footprint by bio/request queue allocation
> 
> Having said, it's worth to look into it in detail more.
> I will have time to see that approach to know what I can do
> with that.

queue_mode=2 bs=4096 nr_devices=1 submit_queues=4 hw_queue_depth=128

Last week, I played with null_blk and blk-mq.c to get an idea how
blk-mq works and I realized it's not good for zram because it aims
to solve 1) dispatch queue bottleneck 2) cache-friendly IO completion
through IRQ so 3) avoids remote memory accesses.

For zram which is used for embedded as primary purpose, ones listed
abvoe are not a severe problem. Most imporant thing is there is no
model to support that a process queueing IO request on *a* CPU while
other CPUs issues the queued IO to driver.

Anyway, Although blk-mrq can support that model, it is blk-layer thing.
IOW, it's software stuff for fast IO delievry but what we need is
device parallelism of zram itself. So, although we follow blk-mq,
we still need multiple threads to compress in parallel which is most of
code I wrote in this patchset.

If I cannot get huge benefit(e.g., reduce a lot of zram-speicif code
to support such model) with blk-mq, I don't feel to switch to request
model at the cost of reasons I stated above.

Thanks.

Re: [PATCH 2/3] zram: support page-based parallel write

[Minchan Kim]

Hi Sergey,

On Fri, Oct 07, 2016 at 03:33:22PM +0900, Minchan Kim wrote:

< snip >

> > so the question is -- can we move this parallelization out of zram
> > and instead flush bdi in more than one kthread? how bad that would
> > be? can anyone else benefit from this?
> 
> Isn't it blk-mq you mentioned? With blk-mq, I have some concerns.
> 
> 1. read speed degradation
> 2. no work with rw_page
> 3. more memory footprint by bio/request queue allocation
> 
> Having said, it's worth to look into it in detail more.
> I will have time to see that approach to know what I can do
> with that.

queue_mode=2 bs=4096 nr_devices=1 submit_queues=4 hw_queue_depth=128

Last week, I played with null_blk and blk-mq.c to get an idea how
blk-mq works and I realized it's not good for zram because it aims
to solve 1) dispatch queue bottleneck 2) cache-friendly IO completion
through IRQ so 3) avoids remote memory accesses.

For zram which is used for embedded as primary purpose, ones listed
abvoe are not a severe problem. Most imporant thing is there is no
model to support that a process queueing IO request on *a* CPU while
other CPUs issues the queued IO to driver.

Anyway, Although blk-mrq can support that model, it is blk-layer thing.
IOW, it's software stuff for fast IO delievry but what we need is
device parallelism of zram itself. So, although we follow blk-mq,
we still need multiple threads to compress in parallel which is most of
code I wrote in this patchset.

If I cannot get huge benefit(e.g., reduce a lot of zram-speicif code
to support such model) with blk-mq, I don't feel to switch to request
model at the cost of reasons I stated above.

Thanks.

Re: [PATCH] x86/smp: Add irq_enter/exit() in smp_reschedule_interrupt()

[Wanpeng Li]

2016-10-16 21:39 GMT+08:00 Peter Zijlstra :
> On Fri, Oct 14, 2016 at 09:48:53AM +0800, Wanpeng Li wrote:
>>  ===
>>  [ INFO: suspicious RCU usage. ]
>>  4.8.0+ #24 Not tainted
>>  ---
>>  ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() 
>> usage!
>>
>>  other info that might help us debug this:
>>
>>
>>  RCU used illegally from idle CPU!
>>  rcu_scheduler_active = 1, debug_locks = 0
>>  RCU used illegally from extended quiescent state!
>>  no locks held by swapper/1/0.
>>
>>  stack backtrace:
>>  CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #24
>>  Hardware name: Dell Inc. OptiPlex 7020/0F5C5X, BIOS A03 01/08/2015
>>   90285de03f58 9d44a0c9 90285ca5d100 0001
>>   90285de03f88 9d0ebd67 902845165410 080b
>>     90285de03fb8 9d492b95
>>  Call Trace:
>> [] dump_stack+0x99/0xd0
>>   [] lockdep_rcu_suspicious+0xe7/0x120
>>   [] do_trace_write_msr+0x135/0x140
>>   [] native_write_msr+0x20/0x30
>>   [] native_apic_msr_eoi_write+0x1d/0x30
>>   [] smp_reschedule_interrupt+0x1d/0x30
>>   [] reschedule_interrupt+0x96/0xa0
>> [] ? cpuidle_enter_state+0xe4/0x360
>>   [] ? cpuidle_enter_state+0xcf/0x360
>>   [] cpuidle_enter+0x17/0x20
>>   [] call_cpuidle+0x23/0x50
>>   [] cpu_startup_entry+0x15c/0x280
>>   [] start_secondary+0x154/0x180
>>
>> Reschedule interrupt may be called in cpu idle state. This causes lockdep
>> check warning above.
>>
>> Add irq_enter/exit() in smp_reschedule_interrupt(), irq_enter() tells the RCU
>> subsystems to end the extended quiescent state, so the following trace call 
>> in
>> ack_APIC_irq() works correctly.
>>
>> Cc: Ingo Molnar 
>> Cc: Mike Galbraith 
>> Cc: Peter Zijlstra 
>> Cc: Thomas Gleixner 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/kernel/smp.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
>> index 658777c..ac2ee87 100644
>> --- a/arch/x86/kernel/smp.c
>> +++ b/arch/x86/kernel/smp.c
>> @@ -259,8 +259,10 @@ static inline void __smp_reschedule_interrupt(void)
>>
>>  __visible void smp_reschedule_interrupt(struct pt_regs *regs)
>>  {
>> + irq_enter();
>>   ack_APIC_irq();
>>   __smp_reschedule_interrupt();
>> + irq_exit();
>
> Urgh, I really hate this...
>
> So now we're making a very frequent interrupt slower because of debug
> code :/

Do you have a better idea? :)

Regards,
Wanpeng Li

Re: [PATCH] x86/smp: Add irq_enter/exit() in smp_reschedule_interrupt()

[Wanpeng Li]

2016-10-16 21:39 GMT+08:00 Peter Zijlstra :
> On Fri, Oct 14, 2016 at 09:48:53AM +0800, Wanpeng Li wrote:
>>  ===
>>  [ INFO: suspicious RCU usage. ]
>>  4.8.0+ #24 Not tainted
>>  ---
>>  ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() 
>> usage!
>>
>>  other info that might help us debug this:
>>
>>
>>  RCU used illegally from idle CPU!
>>  rcu_scheduler_active = 1, debug_locks = 0
>>  RCU used illegally from extended quiescent state!
>>  no locks held by swapper/1/0.
>>
>>  stack backtrace:
>>  CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #24
>>  Hardware name: Dell Inc. OptiPlex 7020/0F5C5X, BIOS A03 01/08/2015
>>   90285de03f58 9d44a0c9 90285ca5d100 0001
>>   90285de03f88 9d0ebd67 902845165410 080b
>>     90285de03fb8 9d492b95
>>  Call Trace:
>> [] dump_stack+0x99/0xd0
>>   [] lockdep_rcu_suspicious+0xe7/0x120
>>   [] do_trace_write_msr+0x135/0x140
>>   [] native_write_msr+0x20/0x30
>>   [] native_apic_msr_eoi_write+0x1d/0x30
>>   [] smp_reschedule_interrupt+0x1d/0x30
>>   [] reschedule_interrupt+0x96/0xa0
>> [] ? cpuidle_enter_state+0xe4/0x360
>>   [] ? cpuidle_enter_state+0xcf/0x360
>>   [] cpuidle_enter+0x17/0x20
>>   [] call_cpuidle+0x23/0x50
>>   [] cpu_startup_entry+0x15c/0x280
>>   [] start_secondary+0x154/0x180
>>
>> Reschedule interrupt may be called in cpu idle state. This causes lockdep
>> check warning above.
>>
>> Add irq_enter/exit() in smp_reschedule_interrupt(), irq_enter() tells the RCU
>> subsystems to end the extended quiescent state, so the following trace call 
>> in
>> ack_APIC_irq() works correctly.
>>
>> Cc: Ingo Molnar 
>> Cc: Mike Galbraith 
>> Cc: Peter Zijlstra 
>> Cc: Thomas Gleixner 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/kernel/smp.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
>> index 658777c..ac2ee87 100644
>> --- a/arch/x86/kernel/smp.c
>> +++ b/arch/x86/kernel/smp.c
>> @@ -259,8 +259,10 @@ static inline void __smp_reschedule_interrupt(void)
>>
>>  __visible void smp_reschedule_interrupt(struct pt_regs *regs)
>>  {
>> + irq_enter();
>>   ack_APIC_irq();
>>   __smp_reschedule_interrupt();
>> + irq_exit();
>
> Urgh, I really hate this...
>
> So now we're making a very frequent interrupt slower because of debug
> code :/

Do you have a better idea? :)

Regards,
Wanpeng Li

[RFC PATCH v3 1/2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

[R. Parameswaran]

[v3: Picked up review comments from James Chapman, added a
 function  to compute ip header + ip option overhead on a socket, and factored
 it  into L2TP change-set, RFC, would like early feedback on name and
 placement, and logic  of new function while I test this]

>From 30c4b3900d09deb912fc6ce4af3c19e870f84e14 Mon Sep 17 00:00:00 2001
From: "R. Parameswaran" 
Date: Sun, 16 Oct 2016 20:19:38 -0700

In existing kernel code, when setting up the L2TP interface, all of the
tunnel encapsulation headers are not taken into account when setting
up the MTU on the  L2TP logical interface device. Due to this, the
packets created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, which leads to
needless fragmentation once the L2TP packet is encapsulated in an outer IP
packet.

Specifically, the MTU calculation  does not take into account the (outer)
IP header imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner L2TP packet prior to encapsulation. The patch posted
here takes care of these.

Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
patch uses the PMTU mechanism and the dst entry in the L2TP tunnel socket
to directly pull up the underlay MTU (as the baseline number on top of
which the encapsulation headers are factored in).  Ethernet MTU is
assumed as a fallback only if this fails.

Picked up review comments from James Chapman, added a function
to compute ip header + ip option overhead on a socket, and factored it
into L2TP change-set.

Signed-off-by: nprac...@brocade.com,
Signed-off-by: bh...@brocade.com,
Signed-off-by: rshea...@brocade.com,
Signed-off-by: dfaw...@brocade.com
---
 include/linux/net.h |  3 +++
 net/socket.c| 37 +
 2 files changed, 40 insertions(+)

diff --git a/include/linux/net.h b/include/linux/net.h
index cd0c8bd..2c8b092 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -298,6 +298,9 @@ int kernel_sendpage(struct socket *sock, struct page *page, 
int offset,
 int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
 int kernel_sock_shutdown(struct socket *sock, enum sock_shutdown_cmd how);
 
+/* Following routine returns the IP overhead imposed by a socket.  */
+u32 kernel_sock_ip_overhead(struct sock *sk);
+
 #define MODULE_ALIAS_NETPROTO(proto) \
MODULE_ALIAS("net-pf-" __stringify(proto))
 
diff --git a/net/socket.c b/net/socket.c
index 5a9bf5e..d5e79c2 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -3293,3 +3293,40 @@ int kernel_sock_shutdown(struct socket *sock, enum 
sock_shutdown_cmd how)
return sock->ops->shutdown(sock, how);
 }
 EXPORT_SYMBOL(kernel_sock_shutdown);
+
+/*
+ * This routine returns the IP overhead imposed by a socket i.e.
+ * the length of the underlying IP header, depending on whether
+ *  this is an IPv4 or IPv6 socket and the length from IP options turned
+ *  on at the socket.
+ */
+u32 kernel_sock_ip_overhead(struct sock *sk)
+{
+   u32 overhead = 0;
+   if (!sk)
+   goto done;
+   if (sk->sk_family == AF_INET) {
+   struct ip_options_rcu *opt = NULL;
+   struct inet_sock *inet = inet_sk(sk);
+   overhead += sizeof(struct iphdr);
+   if (inet)
+   opt = rcu_dereference_protected(inet->inet_opt,
+   sock_owned_by_user(sk));
+   if (opt)
+   overhead += opt->opt.optlen;
+   }
+   else if (sk->sk_family == AF_INET6) {
+   struct ipv6_pinfo *np = inet6_sk(sk);
+   struct ipv6_txoptions *opt = NULL;
+   overhead += sizeof(struct ipv6hdr);
+   if (np)
+   opt = rcu_dereference_protected(np->opt,
+   sock_owned_by_user(sk));
+   if (opt)
+   overhead += (opt->opt_flen + opt->opt_nflen);
+   }
+
+done:
+   return overhead;
+}
+EXPORT_SYMBOL_GPL(kernel_sock_ip_overhead);
-- 
2.1.4


On Tue, 11 Oct 2016, James Chapman wrote:

> 
> I think keep it simple. A function to return the size of the IP header
> associated with any IP socket, not necessarily a tunnel socket. Don't
> mix in any MTU derivation logic or UDP header size etc.
> 
> Post code early as an RFC. You're more likely to get review feedback
> from others.
> 
> 
> 
> 

[RFC PATCH v3 1/2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

[R. Parameswaran]

[v3: Picked up review comments from James Chapman, added a
 function  to compute ip header + ip option overhead on a socket, and factored
 it  into L2TP change-set, RFC, would like early feedback on name and
 placement, and logic  of new function while I test this]

>From 30c4b3900d09deb912fc6ce4af3c19e870f84e14 Mon Sep 17 00:00:00 2001
From: "R. Parameswaran" 
Date: Sun, 16 Oct 2016 20:19:38 -0700

In existing kernel code, when setting up the L2TP interface, all of the
tunnel encapsulation headers are not taken into account when setting
up the MTU on the  L2TP logical interface device. Due to this, the
packets created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, which leads to
needless fragmentation once the L2TP packet is encapsulated in an outer IP
packet.

Specifically, the MTU calculation  does not take into account the (outer)
IP header imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner L2TP packet prior to encapsulation. The patch posted
here takes care of these.

Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
patch uses the PMTU mechanism and the dst entry in the L2TP tunnel socket
to directly pull up the underlay MTU (as the baseline number on top of
which the encapsulation headers are factored in).  Ethernet MTU is
assumed as a fallback only if this fails.

Picked up review comments from James Chapman, added a function
to compute ip header + ip option overhead on a socket, and factored it
into L2TP change-set.

Signed-off-by: nprac...@brocade.com,
Signed-off-by: bh...@brocade.com,
Signed-off-by: rshea...@brocade.com,
Signed-off-by: dfaw...@brocade.com
---
 include/linux/net.h |  3 +++
 net/socket.c| 37 +
 2 files changed, 40 insertions(+)

diff --git a/include/linux/net.h b/include/linux/net.h
index cd0c8bd..2c8b092 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -298,6 +298,9 @@ int kernel_sendpage(struct socket *sock, struct page *page, 
int offset,
 int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
 int kernel_sock_shutdown(struct socket *sock, enum sock_shutdown_cmd how);
 
+/* Following routine returns the IP overhead imposed by a socket.  */
+u32 kernel_sock_ip_overhead(struct sock *sk);
+
 #define MODULE_ALIAS_NETPROTO(proto) \
MODULE_ALIAS("net-pf-" __stringify(proto))
 
diff --git a/net/socket.c b/net/socket.c
index 5a9bf5e..d5e79c2 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -3293,3 +3293,40 @@ int kernel_sock_shutdown(struct socket *sock, enum 
sock_shutdown_cmd how)
return sock->ops->shutdown(sock, how);
 }
 EXPORT_SYMBOL(kernel_sock_shutdown);
+
+/*
+ * This routine returns the IP overhead imposed by a socket i.e.
+ * the length of the underlying IP header, depending on whether
+ *  this is an IPv4 or IPv6 socket and the length from IP options turned
+ *  on at the socket.
+ */
+u32 kernel_sock_ip_overhead(struct sock *sk)
+{
+   u32 overhead = 0;
+   if (!sk)
+   goto done;
+   if (sk->sk_family == AF_INET) {
+   struct ip_options_rcu *opt = NULL;
+   struct inet_sock *inet = inet_sk(sk);
+   overhead += sizeof(struct iphdr);
+   if (inet)
+   opt = rcu_dereference_protected(inet->inet_opt,
+   sock_owned_by_user(sk));
+   if (opt)
+   overhead += opt->opt.optlen;
+   }
+   else if (sk->sk_family == AF_INET6) {
+   struct ipv6_pinfo *np = inet6_sk(sk);
+   struct ipv6_txoptions *opt = NULL;
+   overhead += sizeof(struct ipv6hdr);
+   if (np)
+   opt = rcu_dereference_protected(np->opt,
+   sock_owned_by_user(sk));
+   if (opt)
+   overhead += (opt->opt_flen + opt->opt_nflen);
+   }
+
+done:
+   return overhead;
+}
+EXPORT_SYMBOL_GPL(kernel_sock_ip_overhead);
-- 
2.1.4


On Tue, 11 Oct 2016, James Chapman wrote:

> 
> I think keep it simple. A function to return the size of the IP header
> associated with any IP socket, not necessarily a tunnel socket. Don't
> mix in any MTU derivation logic or UDP header size etc.
> 
> Post code early as an RFC. You're more likely to get review feedback
> from others.
> 
> 
> 
> 

Re: [PATCH 04/10] fault injection: prevent recursive fault injection

[Hillf Danton]

On Sunday, October 16, 2016 11:56 PM Vegard Nossum wrote:
> 
> If something we call in the fail_dump() code path tries to acquire a
> resource that might fail (due to fault injection), then we should not
> try to recurse back into the fault injection code.
> 
> I've seen this happen with the console semaphore in the upcoming
> semaphore trylock fault injection code.
> 
> Cc: Hillf Danton 
> Signed-off-by: Vegard Nossum 
> ---
>  lib/fault-inject.c | 34 --
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/fault-inject.c b/lib/fault-inject.c
> index 6a823a5..adba7c9 100644
> --- a/lib/fault-inject.c
> +++ b/lib/fault-inject.c
> @@ -100,6 +100,33 @@ static inline bool fail_stacktrace(struct fault_attr 
> *attr)
> 
>  #endif /* CONFIG_FAULT_INJECTION_STACKTRACE_FILTER */
> 
> +static DEFINE_PER_CPU(int, fault_active);
> +
> +static bool __fail(struct fault_attr *attr)
> +{
> + bool ret = false;
> +
> + /*
> +  * Prevent recursive fault injection (this could happen if for
> +  * example printing the fault would itself run some code that
> +  * could fail)
> +  */
> + preempt_disable();
> + if (unlikely(__this_cpu_inc_return(fault_active) != 1))
> + goto out;
> +
> + ret = true;
> + fail_dump(attr);
> +
> + if (atomic_read(>times) != -1)
> + atomic_dec_not_zero(>times);
> +
> +out:
> + __this_cpu_dec(fault_active);
> + preempt_enable();

Given no see other patches in this set, I could easily miss 
anything important and correct me please. 

Though added, there are no words in the change log about 
preempt, and my wonder again is: can we add it in contexts
like the fast path of buddy allocator?

thanks
Hillf
> + return ret;
> +}
> +
>  /*
>   * This code is stolen from failmalloc-1.0
>   * http://www.nongnu.org/failmalloc/
> @@ -134,12 +161,7 @@ bool should_fail(struct fault_attr *attr, ssize_t size)
>   if (!fail_stacktrace(attr))
>   return false;
> 
> - fail_dump(attr);
> -
> - if (atomic_read(>times) != -1)
> - atomic_dec_not_zero(>times);
> -
> - return true;
> + return __fail(attr);
>  }
>  EXPORT_SYMBOL_GPL(should_fail);
> 
> --
> 2.10.0.479.g221bd91

Re: [PATCH 04/10] fault injection: prevent recursive fault injection

[Hillf Danton]

On Sunday, October 16, 2016 11:56 PM Vegard Nossum wrote:
> 
> If something we call in the fail_dump() code path tries to acquire a
> resource that might fail (due to fault injection), then we should not
> try to recurse back into the fault injection code.
> 
> I've seen this happen with the console semaphore in the upcoming
> semaphore trylock fault injection code.
> 
> Cc: Hillf Danton 
> Signed-off-by: Vegard Nossum 
> ---
>  lib/fault-inject.c | 34 --
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/fault-inject.c b/lib/fault-inject.c
> index 6a823a5..adba7c9 100644
> --- a/lib/fault-inject.c
> +++ b/lib/fault-inject.c
> @@ -100,6 +100,33 @@ static inline bool fail_stacktrace(struct fault_attr 
> *attr)
> 
>  #endif /* CONFIG_FAULT_INJECTION_STACKTRACE_FILTER */
> 
> +static DEFINE_PER_CPU(int, fault_active);
> +
> +static bool __fail(struct fault_attr *attr)
> +{
> + bool ret = false;
> +
> + /*
> +  * Prevent recursive fault injection (this could happen if for
> +  * example printing the fault would itself run some code that
> +  * could fail)
> +  */
> + preempt_disable();
> + if (unlikely(__this_cpu_inc_return(fault_active) != 1))
> + goto out;
> +
> + ret = true;
> + fail_dump(attr);
> +
> + if (atomic_read(>times) != -1)
> + atomic_dec_not_zero(>times);
> +
> +out:
> + __this_cpu_dec(fault_active);
> + preempt_enable();

Given no see other patches in this set, I could easily miss 
anything important and correct me please. 

Though added, there are no words in the change log about 
preempt, and my wonder again is: can we add it in contexts
like the fast path of buddy allocator?

thanks
Hillf
> + return ret;
> +}
> +
>  /*
>   * This code is stolen from failmalloc-1.0
>   * http://www.nongnu.org/failmalloc/
> @@ -134,12 +161,7 @@ bool should_fail(struct fault_attr *attr, ssize_t size)
>   if (!fail_stacktrace(attr))
>   return false;
> 
> - fail_dump(attr);
> -
> - if (atomic_read(>times) != -1)
> - atomic_dec_not_zero(>times);
> -
> - return true;
> + return __fail(attr);
>  }
>  EXPORT_SYMBOL_GPL(should_fail);
> 
> --
> 2.10.0.479.g221bd91

Re: [PATCH v2] mm: vmalloc: Replace purge_lock spinlock with atomic refcount

[Nicholas Piggin]

On Sat, 15 Oct 2016 03:42:42 -0700
Joel Fernandes  wrote:

> The purge_lock spinlock causes high latencies with non RT kernel. This has 
> been
> reported multiple times on lkml [1] [2] and affects applications like audio.
> 
> In this patch, I replace the spinlock with an atomic refcount so that
> preemption is kept turned on during purge. This Ok to do since [3] builds the
> lazy free list in advance and atomically retrieves the list so any instance of
> purge will have its own list it is purging. Since the individual vmap area
> frees are themselves protected by a lock, this is Ok.

This is a good idea, and good results, but that's not what the spinlock was
for -- it was for enforcing the sync semantics.

Going this route, you'll have to audit callers to expect changed behavior
and change documentation of sync parameter.

I suspect a better approach would be to instead use a mutex for this, and
require that all sync=1 callers be able to sleep. I would say that most
probably already can.

Thanks,
Nick

Re: [PATCH v2] mm: vmalloc: Replace purge_lock spinlock with atomic refcount

[Nicholas Piggin]

On Sat, 15 Oct 2016 03:42:42 -0700
Joel Fernandes  wrote:

> The purge_lock spinlock causes high latencies with non RT kernel. This has 
> been
> reported multiple times on lkml [1] [2] and affects applications like audio.
> 
> In this patch, I replace the spinlock with an atomic refcount so that
> preemption is kept turned on during purge. This Ok to do since [3] builds the
> lazy free list in advance and atomically retrieves the list so any instance of
> purge will have its own list it is purging. Since the individual vmap area
> frees are themselves protected by a lock, this is Ok.

This is a good idea, and good results, but that's not what the spinlock was
for -- it was for enforcing the sync semantics.

Going this route, you'll have to audit callers to expect changed behavior
and change documentation of sync parameter.

I suspect a better approach would be to instead use a mutex for this, and
require that all sync=1 callers be able to sleep. I would say that most
probably already can.

Thanks,
Nick

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nicholas Piggin]

On Sat, 15 Oct 2016 17:22:05 -0700
Omar Sandoval  wrote:

> On Fri, Oct 14, 2016 at 10:12:46PM +0200, Michal Marek wrote:
> > Hi Linus,
> > 
> > please pull these kbuild changes for v4.9-rc1:
> > 
> > - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
> >   because genksyms no longer generates checksums for these symbols
> >   (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
> >   Plus, we are talking about functions like strcpy(), which rarely
> >   change prototypes.  
> 
> So this has broken all module loading for me. I get the following dmesg
> spew:
> 
> ...
> [4.586914] scsi_mod: no symbol version for memset
> [4.587920] scsi_mod: Unknown symbol memset (err -22)
> [4.588443] scsi_mod: no symbol version for ___preempt_schedule
> [4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
> ...
> 
> Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
> it for me. This is with GCC 6.2.1, binutils 2.27, attached config.
> 

Thanks for the report. Could you try this patch and see if it helps?


Allow architectures to create asm/asm-prototypes.h file that
provides C prototypes for exported asm functions, which enables
proper CRC versions to be generated for them.

It's done by creating a trivial C program that includes that file
and the EXPORT_SYMBOL()s from the .S file, and preprocesses that
then sends the result to genksyms.

Signed-off-by: Nicholas Piggin 
---
 scripts/Makefile.build | 71 +-
 1 file changed, 65 insertions(+), 6 deletions(-)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index de46ab0..edcf876 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -159,7 +159,8 @@ cmd_cpp_i_c   = $(CPP) $(c_flags) -o $@ $<
 $(obj)/%.i: $(src)/%.c FORCE
$(call if_changed_dep,cpp_i_c)
 
-cmd_gensymtypes =   \
+# These mirror gensymtypes_S and co below, keep them in synch.
+cmd_gensymtypes_c = \
 $(CPP) -D__GENKSYMS__ $(c_flags) $< |   \
 $(GENKSYMS) $(if $(1), -T $(2)) \
  $(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX)) \
@@ -169,7 +170,7 @@ cmd_gensymtypes =   
\
 quiet_cmd_cc_symtypes_c = SYM $(quiet_modtag) $@
 cmd_cc_symtypes_c = \
 set -e; \
-$(call cmd_gensymtypes,true,$@) >/dev/null; \
+$(call cmd_gensymtypes_c,true,$@) >/dev/null;   \
 test -s $@ || rm -f $@
 
 $(obj)/%.symtypes : $(src)/%.c FORCE
@@ -198,9 +199,10 @@ else
 #   the actual value of the checksum generated by genksyms
 
 cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $<
-cmd_modversions =  
\
+
+cmd_modversions_c =
\
if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then 
\
-   $(call cmd_gensymtypes,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))
\
+   $(call cmd_gensymtypes_c,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))  
\
> $(@D)/.tmp_$(@F:.o=.ver); 
\

\
$(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F)  
\
@@ -268,13 +270,14 @@ endif # CONFIG_STACK_VALIDATION
 define rule_cc_o_c
$(call echo-cmd,checksrc) $(cmd_checksrc) \
$(call cmd_and_fixdep,cc_o_c) \
-   $(cmd_modversions)\
+   $(cmd_modversions_c)  \
$(cmd_objtool)\
$(call echo-cmd,record_mcount) $(cmd_record_mcount)
 endef
 
 define rule_as_o_S
$(call cmd_and_fixdep,as_o_S) \
+   $(cmd_modversions_S)  \
$(cmd_objtool)
 endef
 
@@ -314,6 +317,32 @@ modkern_aflags := $(KBUILD_AFLAGS_KERNEL) $(AFLAGS_KERNEL)
 $(real-objs-m)  : modkern_aflags := $(KBUILD_AFLAGS_MODULE) 
$(AFLAGS_MODULE)
 $(real-objs-m:.o=.s): modkern_aflags := $(KBUILD_AFLAGS_MODULE) 
$(AFLAGS_MODULE)
 
+# .S file exports must have their C prototypes defined in asm/asm-prototypes.h
+# or a file that it includes, in order to get versioned symbols. We build a
+# dummy C file that includes asm-prototypes and the EXPORT_SYMBOL lines from
+# the .S file (with trailing ';'), and run genksyms on 

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nicholas Piggin]

On Sat, 15 Oct 2016 17:22:05 -0700
Omar Sandoval  wrote:

> On Fri, Oct 14, 2016 at 10:12:46PM +0200, Michal Marek wrote:
> > Hi Linus,
> > 
> > please pull these kbuild changes for v4.9-rc1:
> > 
> > - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
> >   because genksyms no longer generates checksums for these symbols
> >   (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
> >   Plus, we are talking about functions like strcpy(), which rarely
> >   change prototypes.  
> 
> So this has broken all module loading for me. I get the following dmesg
> spew:
> 
> ...
> [4.586914] scsi_mod: no symbol version for memset
> [4.587920] scsi_mod: Unknown symbol memset (err -22)
> [4.588443] scsi_mod: no symbol version for ___preempt_schedule
> [4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
> ...
> 
> Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
> it for me. This is with GCC 6.2.1, binutils 2.27, attached config.
> 

Thanks for the report. Could you try this patch and see if it helps?


Allow architectures to create asm/asm-prototypes.h file that
provides C prototypes for exported asm functions, which enables
proper CRC versions to be generated for them.

It's done by creating a trivial C program that includes that file
and the EXPORT_SYMBOL()s from the .S file, and preprocesses that
then sends the result to genksyms.

Signed-off-by: Nicholas Piggin 
---
 scripts/Makefile.build | 71 +-
 1 file changed, 65 insertions(+), 6 deletions(-)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index de46ab0..edcf876 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -159,7 +159,8 @@ cmd_cpp_i_c   = $(CPP) $(c_flags) -o $@ $<
 $(obj)/%.i: $(src)/%.c FORCE
$(call if_changed_dep,cpp_i_c)
 
-cmd_gensymtypes =   \
+# These mirror gensymtypes_S and co below, keep them in synch.
+cmd_gensymtypes_c = \
 $(CPP) -D__GENKSYMS__ $(c_flags) $< |   \
 $(GENKSYMS) $(if $(1), -T $(2)) \
  $(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX)) \
@@ -169,7 +170,7 @@ cmd_gensymtypes =   
\
 quiet_cmd_cc_symtypes_c = SYM $(quiet_modtag) $@
 cmd_cc_symtypes_c = \
 set -e; \
-$(call cmd_gensymtypes,true,$@) >/dev/null; \
+$(call cmd_gensymtypes_c,true,$@) >/dev/null;   \
 test -s $@ || rm -f $@
 
 $(obj)/%.symtypes : $(src)/%.c FORCE
@@ -198,9 +199,10 @@ else
 #   the actual value of the checksum generated by genksyms
 
 cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $<
-cmd_modversions =  
\
+
+cmd_modversions_c =
\
if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then 
\
-   $(call cmd_gensymtypes,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))
\
+   $(call cmd_gensymtypes_c,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))  
\
> $(@D)/.tmp_$(@F:.o=.ver); 
\

\
$(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F)  
\
@@ -268,13 +270,14 @@ endif # CONFIG_STACK_VALIDATION
 define rule_cc_o_c
$(call echo-cmd,checksrc) $(cmd_checksrc) \
$(call cmd_and_fixdep,cc_o_c) \
-   $(cmd_modversions)\
+   $(cmd_modversions_c)  \
$(cmd_objtool)\
$(call echo-cmd,record_mcount) $(cmd_record_mcount)
 endef
 
 define rule_as_o_S
$(call cmd_and_fixdep,as_o_S) \
+   $(cmd_modversions_S)  \
$(cmd_objtool)
 endef
 
@@ -314,6 +317,32 @@ modkern_aflags := $(KBUILD_AFLAGS_KERNEL) $(AFLAGS_KERNEL)
 $(real-objs-m)  : modkern_aflags := $(KBUILD_AFLAGS_MODULE) 
$(AFLAGS_MODULE)
 $(real-objs-m:.o=.s): modkern_aflags := $(KBUILD_AFLAGS_MODULE) 
$(AFLAGS_MODULE)
 
+# .S file exports must have their C prototypes defined in asm/asm-prototypes.h
+# or a file that it includes, in order to get versioned symbols. We build a
+# dummy C file that includes asm-prototypes and the EXPORT_SYMBOL lines from
+# the .S file (with trailing ';'), and run genksyms on that, to extract vers.
+#
+# These 

Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

[Vaibhav Agarwal]

On Sun, Oct 16, 2016 at 3:29 PM, Pankaj Bharadiya
 wrote:
> gb_audio_manager_module_descriptor's cport field is actually used to
> manage and pass interface id to user space.
>
> Thus rename gb_audio_manager_module_descriptor's 'cport' field and
> few other things to avoid confusion.
>
> Signed-off-by: Pankaj Bharadiya 
> ---
>  drivers/staging/greybus/audio_manager.h|  2 +-
>  drivers/staging/greybus/audio_manager_module.c | 20 ++--
>  drivers/staging/greybus/audio_manager_sysfs.c  |  4 ++--
>  drivers/staging/greybus/audio_module.c |  2 +-
>  4 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/staging/greybus/audio_manager.h 
> b/drivers/staging/greybus/audio_manager.h
> index c4ca097..056088e 100644
> --- a/drivers/staging/greybus/audio_manager.h
> +++ b/drivers/staging/greybus/audio_manager.h
> @@ -21,7 +21,7 @@ struct gb_audio_manager_module_descriptor {
> int slot;
> int vid;
> int pid;
> -   int cport;
> +   int intf_id;
> unsigned int ip_devices;
> unsigned int op_devices;
>  };
> diff --git a/drivers/staging/greybus/audio_manager_module.c 
> b/drivers/staging/greybus/audio_manager_module.c
> index a10e96a..2bf40a9 100644
> --- a/drivers/staging/greybus/audio_manager_module.c
> +++ b/drivers/staging/greybus/audio_manager_module.c
> @@ -111,16 +111,16 @@ static ssize_t gb_audio_module_pid_show(
>  static struct gb_audio_manager_module_attribute 
> gb_audio_module_pid_attribute =
> __ATTR(pid, 0664, gb_audio_module_pid_show, NULL);
>
> -static ssize_t gb_audio_module_cport_show(
> +static ssize_t gb_audio_module_intf_id_show(
> struct gb_audio_manager_module *module,
> struct gb_audio_manager_module_attribute *attr, char *buf)
>  {
> -   return sprintf(buf, "%d", module->desc.cport);
> +   return sprintf(buf, "%d", module->desc.intf_id);
>  }
>
>  static struct gb_audio_manager_module_attribute
> -   gb_audio_module_cport_attribute =
> -   __ATTR(cport, 0664, gb_audio_module_cport_show, NULL);
> +   gb_audio_module_intf_id_attribute =
> +   __ATTR(intf_id, 0664, gb_audio_module_intf_id_show, NULL);
>
>  static ssize_t gb_audio_module_ip_devices_show(
> struct gb_audio_manager_module *module,
> @@ -149,7 +149,7 @@ static ssize_t gb_audio_module_op_devices_show(
> _audio_module_slot_attribute.attr,
> _audio_module_vid_attribute.attr,
> _audio_module_pid_attribute.attr,
> -   _audio_module_cport_attribute.attr,
> +   _audio_module_intf_id_attribute.attr,
> _audio_module_ip_devices_attribute.attr,
> _audio_module_op_devices_attribute.attr,
> NULL,   /* need to NULL terminate the list of attributes */
> @@ -167,7 +167,7 @@ static void send_add_uevent(struct 
> gb_audio_manager_module *module)
> char slot_string[64];
> char vid_string[64];
> char pid_string[64];
> -   char cport_string[64];
> +   char intf_id_string[64];
> char ip_devices_string[64];
> char op_devices_string[64];
>
> @@ -176,7 +176,7 @@ static void send_add_uevent(struct 
> gb_audio_manager_module *module)
> slot_string,
> vid_string,
> pid_string,
> -   cport_string,
> +   intf_id_string,
> ip_devices_string,
> op_devices_string,
> NULL
> @@ -186,7 +186,7 @@ static void send_add_uevent(struct 
> gb_audio_manager_module *module)
> snprintf(slot_string, 64, "SLOT=%d", module->desc.slot);
> snprintf(vid_string, 64, "VID=%d", module->desc.vid);
> snprintf(pid_string, 64, "PID=%d", module->desc.pid);
> -   snprintf(cport_string, 64, "CPORT=%d", module->desc.cport);
> +   snprintf(intf_id_string, 64, "INTF_ID=%d", module->desc.intf_id);
> snprintf(ip_devices_string, 64, "I/P DEVICES=0x%X",
>  module->desc.ip_devices);
> snprintf(op_devices_string, 64, "O/P DEVICES=0x%X",
> @@ -246,13 +246,13 @@ int gb_audio_manager_module_create(
>
>  void gb_audio_manager_module_dump(struct gb_audio_manager_module *module)
>  {
> -   pr_info("audio module #%d name=%s slot=%d vid=%d pid=%d cport=%d i/p 
> devices=0x%X o/p devices=0x%X\n",
> +   pr_info("audio module #%d name=%s slot=%d vid=%d pid=%d intf_id=%d 
> i/p devices=0x%X o/p devices=0x%X\n",
> module->id,
> module->desc.name,
> module->desc.slot,
> module->desc.vid,
> module->desc.pid,
> -   module->desc.cport,
> +   module->desc.intf_id,
> module->desc.ip_devices,
> module->desc.op_devices);
>  }
> diff --git a/drivers/staging/greybus/audio_manager_sysfs.c 
> 

Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

[Vaibhav Agarwal]

On Sun, Oct 16, 2016 at 3:29 PM, Pankaj Bharadiya
 wrote:
> gb_audio_manager_module_descriptor's cport field is actually used to
> manage and pass interface id to user space.
>
> Thus rename gb_audio_manager_module_descriptor's 'cport' field and
> few other things to avoid confusion.
>
> Signed-off-by: Pankaj Bharadiya 
> ---
>  drivers/staging/greybus/audio_manager.h|  2 +-
>  drivers/staging/greybus/audio_manager_module.c | 20 ++--
>  drivers/staging/greybus/audio_manager_sysfs.c  |  4 ++--
>  drivers/staging/greybus/audio_module.c |  2 +-
>  4 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/staging/greybus/audio_manager.h 
> b/drivers/staging/greybus/audio_manager.h
> index c4ca097..056088e 100644
> --- a/drivers/staging/greybus/audio_manager.h
> +++ b/drivers/staging/greybus/audio_manager.h
> @@ -21,7 +21,7 @@ struct gb_audio_manager_module_descriptor {
> int slot;
> int vid;
> int pid;
> -   int cport;
> +   int intf_id;
> unsigned int ip_devices;
> unsigned int op_devices;
>  };
> diff --git a/drivers/staging/greybus/audio_manager_module.c 
> b/drivers/staging/greybus/audio_manager_module.c
> index a10e96a..2bf40a9 100644
> --- a/drivers/staging/greybus/audio_manager_module.c
> +++ b/drivers/staging/greybus/audio_manager_module.c
> @@ -111,16 +111,16 @@ static ssize_t gb_audio_module_pid_show(
>  static struct gb_audio_manager_module_attribute 
> gb_audio_module_pid_attribute =
> __ATTR(pid, 0664, gb_audio_module_pid_show, NULL);
>
> -static ssize_t gb_audio_module_cport_show(
> +static ssize_t gb_audio_module_intf_id_show(
> struct gb_audio_manager_module *module,
> struct gb_audio_manager_module_attribute *attr, char *buf)
>  {
> -   return sprintf(buf, "%d", module->desc.cport);
> +   return sprintf(buf, "%d", module->desc.intf_id);
>  }
>
>  static struct gb_audio_manager_module_attribute
> -   gb_audio_module_cport_attribute =
> -   __ATTR(cport, 0664, gb_audio_module_cport_show, NULL);
> +   gb_audio_module_intf_id_attribute =
> +   __ATTR(intf_id, 0664, gb_audio_module_intf_id_show, NULL);
>
>  static ssize_t gb_audio_module_ip_devices_show(
> struct gb_audio_manager_module *module,
> @@ -149,7 +149,7 @@ static ssize_t gb_audio_module_op_devices_show(
> _audio_module_slot_attribute.attr,
> _audio_module_vid_attribute.attr,
> _audio_module_pid_attribute.attr,
> -   _audio_module_cport_attribute.attr,
> +   _audio_module_intf_id_attribute.attr,
> _audio_module_ip_devices_attribute.attr,
> _audio_module_op_devices_attribute.attr,
> NULL,   /* need to NULL terminate the list of attributes */
> @@ -167,7 +167,7 @@ static void send_add_uevent(struct 
> gb_audio_manager_module *module)
> char slot_string[64];
> char vid_string[64];
> char pid_string[64];
> -   char cport_string[64];
> +   char intf_id_string[64];
> char ip_devices_string[64];
> char op_devices_string[64];
>
> @@ -176,7 +176,7 @@ static void send_add_uevent(struct 
> gb_audio_manager_module *module)
> slot_string,
> vid_string,
> pid_string,
> -   cport_string,
> +   intf_id_string,
> ip_devices_string,
> op_devices_string,
> NULL
> @@ -186,7 +186,7 @@ static void send_add_uevent(struct 
> gb_audio_manager_module *module)
> snprintf(slot_string, 64, "SLOT=%d", module->desc.slot);
> snprintf(vid_string, 64, "VID=%d", module->desc.vid);
> snprintf(pid_string, 64, "PID=%d", module->desc.pid);
> -   snprintf(cport_string, 64, "CPORT=%d", module->desc.cport);
> +   snprintf(intf_id_string, 64, "INTF_ID=%d", module->desc.intf_id);
> snprintf(ip_devices_string, 64, "I/P DEVICES=0x%X",
>  module->desc.ip_devices);
> snprintf(op_devices_string, 64, "O/P DEVICES=0x%X",
> @@ -246,13 +246,13 @@ int gb_audio_manager_module_create(
>
>  void gb_audio_manager_module_dump(struct gb_audio_manager_module *module)
>  {
> -   pr_info("audio module #%d name=%s slot=%d vid=%d pid=%d cport=%d i/p 
> devices=0x%X o/p devices=0x%X\n",
> +   pr_info("audio module #%d name=%s slot=%d vid=%d pid=%d intf_id=%d 
> i/p devices=0x%X o/p devices=0x%X\n",
> module->id,
> module->desc.name,
> module->desc.slot,
> module->desc.vid,
> module->desc.pid,
> -   module->desc.cport,
> +   module->desc.intf_id,
> module->desc.ip_devices,
> module->desc.op_devices);
>  }
> diff --git a/drivers/staging/greybus/audio_manager_sysfs.c 
> b/drivers/staging/greybus/audio_manager_sysfs.c
> index d8bf859..feb195d 100644
> --- 

Re: [RFC][PATCH 2/2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

[Chen Yu]

On 2016/10/15 3:37, John Youn wrote:
> On 10/13/2016 4:36 PM, John Stultz wrote:
>> From: Chen Yu 
>>
>> The Hi6220's usb controller is limited in that it does not
>> automatically autonegotiate the usb speed. Thus it requires a
>> quirk so that we can manually negotiate the best usb speed for
>> the attached device.
> 
> Hi,
> 
> Could you expand more on this by explaining what exactly is the
> limitation and the workaround?
> 

The USB host limitation of Hisilicon Hi6220 is full-speed and low-speed
devices can not be enumerated when gets plugged behind a hub.

> [snip]
> 
>> +/*
>> + * HPRT0_SPD_HIGH_SPEED: high speed
>> + * HPRT0_SPD_FULL_SPEED: full speed
>> + */
>> +static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
>> +{
>> +struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>> +
>> +if (hsotg->core_params->speed == speed)
>> +return;
>> +
>> +hsotg->core_params->speed = speed;
>> +queue_work(hsotg->wq_otg, >wf_otg);
>> +}
>> +
>> +static int dwc2_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
>> +{
>> +struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>> +
>> +if (!hsotg->change_speed_quirk)
>> +return 1;
>> +
>> +hsotg->device_count++;
> 
> Why do you need to track the device count?
> 
>> +dev_info(hsotg->dev, "Device count is %u after alloc dev\n",
>> +hsotg->device_count);
>> +
>> +return 1;
>> +}
>> +
>> +static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
>> +{
>> +struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>> +
>> +if (!hsotg->change_speed_quirk)
>> +return;
>> +
>> +if (hsotg->device_count)
>> +hsotg->device_count--;
>> +
>> +dev_info(hsotg->dev, "Device count is %u after free dev\n",
>> +hsotg->device_count);
>> +
>> +if (hsotg->device_count == 1 && udev->parent &&
>> +udev->parent->speed > USB_SPEED_UNKNOWN &&
>> +udev->parent->speed < USB_SPEED_HIGH) {
>> +dev_info(hsotg->dev, "Set speed to default high-speed\n");
>> +dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
>> +}
>> +}
>> +
>> +static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
>> +{
>> +struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>> +
>> +if (!hsotg->change_speed_quirk)
>> +return 0;
>> +
>> +if (udev->speed == USB_SPEED_HIGH) {
>> +dev_info(hsotg->dev, "Set speed to high-speed\n");
>> +dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
>> +} else if (udev->speed == USB_SPEED_FULL
>> +|| udev->speed == USB_SPEED_LOW) {
>> +dev_info(hsotg->dev, "Set speed to full-speed\n");
>> +dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
>> +}
> 
> It seems you are reinitializing the core every time a device is reset
> and the udev->speed does not match the core_param speed. But how is
> the udev->speed being set correctly if the hw cannot negotiate the
> speed in the first place?
> 

The hardware can negotiate the speed, but communication with a full-speed or
low-speed device behind a hub is the problem.

> Also should it be for every device? What about if a device gets
> plugged in behind a hub? I don't think you want to execute this code
> in that case.
> 
> This should only affect devices plugged into the root hub, correct?
> And the hsotg controller only has one root hub port. It seems things
> could be simplified a bit.
> 

The patch is initially written for Hikey Hi6220 board, and there is a
hub always connected to root hub, so the patch sets the configuration to
HPRT0_SPD_HIGH_SPEED when there is only one device(the hub).

Thanks for your suggestions, the patch needs modified in these aspect:
1. Change the speed setting only when the device is behind a hub in 
dwc2_reset_device.
2. Change the speed to HPRT0_SPD_HIGH_SPEED only when the last device is a hub.

What do you think about the fix? Any suggestions will be appreciate!

thanks
- Chen Yu

Re: [RFC][PATCH 2/2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

[Chen Yu]

On 2016/10/15 3:37, John Youn wrote:
> On 10/13/2016 4:36 PM, John Stultz wrote:
>> From: Chen Yu 
>>
>> The Hi6220's usb controller is limited in that it does not
>> automatically autonegotiate the usb speed. Thus it requires a
>> quirk so that we can manually negotiate the best usb speed for
>> the attached device.
> 
> Hi,
> 
> Could you expand more on this by explaining what exactly is the
> limitation and the workaround?
> 

The USB host limitation of Hisilicon Hi6220 is full-speed and low-speed
devices can not be enumerated when gets plugged behind a hub.

> [snip]
> 
>> +/*
>> + * HPRT0_SPD_HIGH_SPEED: high speed
>> + * HPRT0_SPD_FULL_SPEED: full speed
>> + */
>> +static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
>> +{
>> +struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>> +
>> +if (hsotg->core_params->speed == speed)
>> +return;
>> +
>> +hsotg->core_params->speed = speed;
>> +queue_work(hsotg->wq_otg, >wf_otg);
>> +}
>> +
>> +static int dwc2_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
>> +{
>> +struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>> +
>> +if (!hsotg->change_speed_quirk)
>> +return 1;
>> +
>> +hsotg->device_count++;
> 
> Why do you need to track the device count?
> 
>> +dev_info(hsotg->dev, "Device count is %u after alloc dev\n",
>> +hsotg->device_count);
>> +
>> +return 1;
>> +}
>> +
>> +static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
>> +{
>> +struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>> +
>> +if (!hsotg->change_speed_quirk)
>> +return;
>> +
>> +if (hsotg->device_count)
>> +hsotg->device_count--;
>> +
>> +dev_info(hsotg->dev, "Device count is %u after free dev\n",
>> +hsotg->device_count);
>> +
>> +if (hsotg->device_count == 1 && udev->parent &&
>> +udev->parent->speed > USB_SPEED_UNKNOWN &&
>> +udev->parent->speed < USB_SPEED_HIGH) {
>> +dev_info(hsotg->dev, "Set speed to default high-speed\n");
>> +dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
>> +}
>> +}
>> +
>> +static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
>> +{
>> +struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
>> +
>> +if (!hsotg->change_speed_quirk)
>> +return 0;
>> +
>> +if (udev->speed == USB_SPEED_HIGH) {
>> +dev_info(hsotg->dev, "Set speed to high-speed\n");
>> +dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
>> +} else if (udev->speed == USB_SPEED_FULL
>> +|| udev->speed == USB_SPEED_LOW) {
>> +dev_info(hsotg->dev, "Set speed to full-speed\n");
>> +dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
>> +}
> 
> It seems you are reinitializing the core every time a device is reset
> and the udev->speed does not match the core_param speed. But how is
> the udev->speed being set correctly if the hw cannot negotiate the
> speed in the first place?
> 

The hardware can negotiate the speed, but communication with a full-speed or
low-speed device behind a hub is the problem.

> Also should it be for every device? What about if a device gets
> plugged in behind a hub? I don't think you want to execute this code
> in that case.
> 
> This should only affect devices plugged into the root hub, correct?
> And the hsotg controller only has one root hub port. It seems things
> could be simplified a bit.
> 

The patch is initially written for Hikey Hi6220 board, and there is a
hub always connected to root hub, so the patch sets the configuration to
HPRT0_SPD_HIGH_SPEED when there is only one device(the hub).

Thanks for your suggestions, the patch needs modified in these aspect:
1. Change the speed setting only when the device is behind a hub in 
dwc2_reset_device.
2. Change the speed to HPRT0_SPD_HIGH_SPEED only when the last device is a hub.

What do you think about the fix? Any suggestions will be appreciate!

thanks
- Chen Yu

[PATCH] btrfs: assign error values to the correct bio structs

[Junjie Mao]

Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")

Signed-off-by: Junjie Mao 
---
 fs/btrfs/compression.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index ccc70d96958d..d4d8b7e36b2f 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -698,7 +698,7 @@ int btrfs_submit_compressed_read(struct inode *inode, 
struct bio *bio,
 
ret = btrfs_map_bio(root, comp_bio, mirror_num, 0);
if (ret) {
-   bio->bi_error = ret;
+   comp_bio->bi_error = ret;
bio_endio(comp_bio);
}
 
@@ -728,7 +728,7 @@ int btrfs_submit_compressed_read(struct inode *inode, 
struct bio *bio,
 
ret = btrfs_map_bio(root, comp_bio, mirror_num, 0);
if (ret) {
-   bio->bi_error = ret;
+   comp_bio->bi_error = ret;
bio_endio(comp_bio);
}
 
-- 
1.9.3

[PATCH] btrfs: assign error values to the correct bio structs

[Junjie Mao]

Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")

Signed-off-by: Junjie Mao 
---
 fs/btrfs/compression.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index ccc70d96958d..d4d8b7e36b2f 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -698,7 +698,7 @@ int btrfs_submit_compressed_read(struct inode *inode, 
struct bio *bio,
 
ret = btrfs_map_bio(root, comp_bio, mirror_num, 0);
if (ret) {
-   bio->bi_error = ret;
+   comp_bio->bi_error = ret;
bio_endio(comp_bio);
}
 
@@ -728,7 +728,7 @@ int btrfs_submit_compressed_read(struct inode *inode, 
struct bio *bio,
 
ret = btrfs_map_bio(root, comp_bio, mirror_num, 0);
if (ret) {
-   bio->bi_error = ret;
+   comp_bio->bi_error = ret;
bio_endio(comp_bio);
}
 
-- 
1.9.3

Re: [PATCH 7/8] tools lib bpf: fix maps resolution

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

It is not correct to assimilate the elf data of the maps section
to an array of map definition. In fact the sizes differ. The
offset provided in the symbol section has to be used instead.

This patch fixes a bug causing a elf with two maps not to load
correctly.


Could you please give an example so we can understand why
section 'maps' is not an array?

Thank you.

Re: [PATCH 7/8] tools lib bpf: fix maps resolution

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

It is not correct to assimilate the elf data of the maps section
to an array of map definition. In fact the sizes differ. The
offset provided in the symbol section has to be used instead.

This patch fixes a bug causing a elf with two maps not to load
correctly.


Could you please give an example so we can understand why
section 'maps' is not an array?

Thank you.

[lkp] [mm] b1f58b69ba: BUG: sleeping function called from invalid context at mm/vmalloc.c:667

[kernel test robot]

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Joel-Fernandes/mm-vmalloc-Replace-purge_lock-spinlock-with-atomic-refcount/20161015-184633
commit b1f58b69ba586afbe70d2f3931370fc1f701d1c2 ("mm: vmalloc: Replace 
purge_lock spinlock with atomic refcount")

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes:


++++
|| 
fe4cd888f7 | b1f58b69ba |
++++
| boot_successes | 
8  | 5  |
| boot_failures  | 
14 | 17 |
| Kernel_panic-not_syncing:VFS:Unable_to_mount_root_fs_on_unknown-block(#,#) | 
2  ||
| calltrace:prepare_namespace| 
2  ||
| BUG:kernel_reboot-without-warning_in_test_stage| 
12 | 3  |
| BUG:sleeping_function_called_from_invalid_context_at_mm/vmalloc.c  | 
0  | 14 |
| invoked_oom-killer:gfp_mask=0x | 
0  | 1  |
| Mem-Info   | 
0  | 1  |
++++



[init] Using pid_max = 32768
[init] Started watchdog process, PID is 9385
[main] Main thread is alive.
[   13.986544] BUG: sleeping function called from invalid context at 
mm/vmalloc.c:667
[   13.988089] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
[   13.989281] 1 lock held by swapper/0/0:
[   13.989935]  #0: 
[   13.990281]  (
vmap_area_lock
[   13.990772] ){..}
, at: 
[   13.991264] [] __purge_vmap_area_lazy+0x28e/0x306
[   13.992284] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.8.0-mm1-00158-gb1f58b6 #1
[   13.993297]  81c03d08 8131753a 81c0b540 
880014581360
[   13.994371]  81c03d20 8108d64c 880014581120 
81c03d88
[   13.995439]  81112b31 811124e6 81c03db0 
81112723
[   13.996570] Call Trace:
[   13.996933]  [] dump_stack+0x79/0x95
[   13.997631]  [] ___might_sleep+0x110/0x11f
[   13.998395]  [] __purge_vmap_area_lazy+0x2d3/0x306
[   13.999242]  [] ? pmd_offset+0x19/0x49
[   14.08]  [] free_vmap_area_noflush+0x6d/0x72
[   14.000834]  [] remove_vm_area+0x84/0x90
[   14.001575]  [] __vunmap+0x36/0xae
[   14.002247]  [] vfree+0x5f/0x62
[   14.002885]  [] free_thread_stack+0x54/0xcb
[   14.003656]  [] put_task_stack+0x2a/0x4f
[   14.004451]  [] finish_task_switch+0x188/0x1b4
[   14.005278]  [] __schedule+0x3c8/0x4a7
[   14.006014]  [] schedule+0x84/0x95
[   14.006676]  [] schedule_preempt_disabled+0x10/0x19
[   14.007544]  [] cpu_startup_entry+0x1c7/0x1cc
[   14.008386]  [] rest_init+0xb3/0xb9
[   14.009086]  [] start_kernel+0x43a/0x447
[   14.009812]  [] ? early_idt_handler_array+0x120/0x120
[   14.010702]  [] x86_64_start_reservations+0x38/0x3a
[   14.011564]  [] x86_64_start_kernel+0x10a/0x117
[main] Setsockopt(1 6 16ba000 5a) on fd 7 [1:2:1]
[main] Setsockopt(1 9 16ba000 e3) on fd 9 [16:3:2]
[main] Setsockopt(1 2d 16ba000 4) on fd 10 [1:1:1]





Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.8.0-mm1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
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_BUG_RELATIVE_POINTERS=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_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

[lkp] [mm] b1f58b69ba: BUG: sleeping function called from invalid context at mm/vmalloc.c:667

[kernel test robot]

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Joel-Fernandes/mm-vmalloc-Replace-purge_lock-spinlock-with-atomic-refcount/20161015-184633
commit b1f58b69ba586afbe70d2f3931370fc1f701d1c2 ("mm: vmalloc: Replace 
purge_lock spinlock with atomic refcount")

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes:


++++
|| 
fe4cd888f7 | b1f58b69ba |
++++
| boot_successes | 
8  | 5  |
| boot_failures  | 
14 | 17 |
| Kernel_panic-not_syncing:VFS:Unable_to_mount_root_fs_on_unknown-block(#,#) | 
2  ||
| calltrace:prepare_namespace| 
2  ||
| BUG:kernel_reboot-without-warning_in_test_stage| 
12 | 3  |
| BUG:sleeping_function_called_from_invalid_context_at_mm/vmalloc.c  | 
0  | 14 |
| invoked_oom-killer:gfp_mask=0x | 
0  | 1  |
| Mem-Info   | 
0  | 1  |
++++



[init] Using pid_max = 32768
[init] Started watchdog process, PID is 9385
[main] Main thread is alive.
[   13.986544] BUG: sleeping function called from invalid context at 
mm/vmalloc.c:667
[   13.988089] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
[   13.989281] 1 lock held by swapper/0/0:
[   13.989935]  #0: 
[   13.990281]  (
vmap_area_lock
[   13.990772] ){..}
, at: 
[   13.991264] [] __purge_vmap_area_lazy+0x28e/0x306
[   13.992284] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.8.0-mm1-00158-gb1f58b6 #1
[   13.993297]  81c03d08 8131753a 81c0b540 
880014581360
[   13.994371]  81c03d20 8108d64c 880014581120 
81c03d88
[   13.995439]  81112b31 811124e6 81c03db0 
81112723
[   13.996570] Call Trace:
[   13.996933]  [] dump_stack+0x79/0x95
[   13.997631]  [] ___might_sleep+0x110/0x11f
[   13.998395]  [] __purge_vmap_area_lazy+0x2d3/0x306
[   13.999242]  [] ? pmd_offset+0x19/0x49
[   14.08]  [] free_vmap_area_noflush+0x6d/0x72
[   14.000834]  [] remove_vm_area+0x84/0x90
[   14.001575]  [] __vunmap+0x36/0xae
[   14.002247]  [] vfree+0x5f/0x62
[   14.002885]  [] free_thread_stack+0x54/0xcb
[   14.003656]  [] put_task_stack+0x2a/0x4f
[   14.004451]  [] finish_task_switch+0x188/0x1b4
[   14.005278]  [] __schedule+0x3c8/0x4a7
[   14.006014]  [] schedule+0x84/0x95
[   14.006676]  [] schedule_preempt_disabled+0x10/0x19
[   14.007544]  [] cpu_startup_entry+0x1c7/0x1cc
[   14.008386]  [] rest_init+0xb3/0xb9
[   14.009086]  [] start_kernel+0x43a/0x447
[   14.009812]  [] ? early_idt_handler_array+0x120/0x120
[   14.010702]  [] x86_64_start_reservations+0x38/0x3a
[   14.011564]  [] x86_64_start_kernel+0x10a/0x117
[main] Setsockopt(1 6 16ba000 5a) on fd 7 [1:2:1]
[main] Setsockopt(1 9 16ba000 e3) on fd 9 [16:3:2]
[main] Setsockopt(1 2d 16ba000 4) on fd 10 [1:1:1]





Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.8.0-mm1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
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_BUG_RELATIVE_POINTERS=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_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

Re: [alsa-devel] [PATCH 1/7] ASoC: intel: broadwell: constify snd_soc_ops structures

[Keyon Jie]

On 2016年10月15日 22:55, Julia Lawall wrote:

Check for snd_soc_ops structures that are only stored in the ops field of a
snd_soc_dai_link structure.  This field is declared const, so snd_soc_ops
structures that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_soc_ops i@p = { ... };

@ok1@
identifier r.i;
struct snd_soc_dai_link e;
position p;
@@
e.ops = @p;

@ok2@
identifier r.i, e;
position p;
@@
struct snd_soc_dai_link e[] = { ..., { .ops = @p, }, ..., };

@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_soc_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
  struct snd_soc_ops i = { ... };
// 

The effect on the layout of the .o file is shown by the following output of
the size command, first before then after the transformation:

textdata bss dec hex filename
38652784 38470331b79 sound/soc/intel/boards/broadwell.o
39292720 38470331b79 sound/soc/intel/boards/broadwell.o

Signed-off-by: Julia Lawall 


Thanks. That works for me.

Acked-by: Jie Yang 

thanks,
~Keyon



---
  sound/soc/intel/boards/broadwell.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff -u -p a/sound/soc/intel/boards/broadwell.c 
b/sound/soc/intel/boards/broadwell.c
--- a/sound/soc/intel/boards/broadwell.c
+++ b/sound/soc/intel/boards/broadwell.c
@@ -126,7 +126,7 @@ static int broadwell_rt286_hw_params(str
return ret;
  }

-static struct snd_soc_ops broadwell_rt286_ops = {
+static const struct snd_soc_ops broadwell_rt286_ops = {
.hw_params = broadwell_rt286_hw_params,
  };


___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 1/7] ASoC: intel: broadwell: constify snd_soc_ops structures

[Keyon Jie]

On 2016年10月15日 22:55, Julia Lawall wrote:

Check for snd_soc_ops structures that are only stored in the ops field of a
snd_soc_dai_link structure.  This field is declared const, so snd_soc_ops
structures that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_soc_ops i@p = { ... };

@ok1@
identifier r.i;
struct snd_soc_dai_link e;
position p;
@@
e.ops = @p;

@ok2@
identifier r.i, e;
position p;
@@
struct snd_soc_dai_link e[] = { ..., { .ops = @p, }, ..., };

@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_soc_ops e;
@@
e@i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
  struct snd_soc_ops i = { ... };
// 

The effect on the layout of the .o file is shown by the following output of
the size command, first before then after the transformation:

textdata bss dec hex filename
38652784 38470331b79 sound/soc/intel/boards/broadwell.o
39292720 38470331b79 sound/soc/intel/boards/broadwell.o

Signed-off-by: Julia Lawall 


Thanks. That works for me.

Acked-by: Jie Yang 

thanks,
~Keyon



---
  sound/soc/intel/boards/broadwell.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff -u -p a/sound/soc/intel/boards/broadwell.c 
b/sound/soc/intel/boards/broadwell.c
--- a/sound/soc/intel/boards/broadwell.c
+++ b/sound/soc/intel/boards/broadwell.c
@@ -126,7 +126,7 @@ static int broadwell_rt286_hw_params(str
return ret;
  }

-static struct snd_soc_ops broadwell_rt286_ops = {
+static const struct snd_soc_ops broadwell_rt286_ops = {
.hw_params = broadwell_rt286_hw_params,
  };


___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 6/8] tools lib bpf: improve warning

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

Signed-off-by: Eric Leblond 


Please add some commit messages.

Thank you.


---
  tools/lib/bpf/libbpf.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 7cd341e..1fe4532 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -802,7 +802,8 @@ bpf_object__create_maps(struct bpf_object *obj)
size_t j;
int err = *pfd;
  
-			pr_warning("failed to create map: %s\n",

+   pr_warning("failed to create map (name: '%s'): %s\n",
+  obj->maps[i].name,
   strerror(errno));
for (j = 0; j < i; j++)
zclose(obj->maps[j].fd);

Re: [PATCH 6/8] tools lib bpf: improve warning

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

Signed-off-by: Eric Leblond 


Please add some commit messages.

Thank you.


---
  tools/lib/bpf/libbpf.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 7cd341e..1fe4532 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -802,7 +802,8 @@ bpf_object__create_maps(struct bpf_object *obj)
size_t j;
int err = *pfd;
  
-			pr_warning("failed to create map: %s\n",

+   pr_warning("failed to create map (name: '%s'): %s\n",
+  obj->maps[i].name,
   strerror(errno));
for (j = 0; j < i; j++)
zclose(obj->maps[j].fd);

Re: [PATCH 5/8] tools lib bpf: add missing functions

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

Some functions were missing in the library to be able to use it
in the case where the userspace is handling the maps in kernel.

The patch also renames functions to have a homogeneous naming
convention.

Signed-off-by: Eric Leblond 
---
  tools/lib/bpf/bpf.c| 35 ++-
  tools/lib/bpf/bpf.h|  2 --
  tools/lib/bpf/libbpf.h |  5 +
  3 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 4212ed6..c0e07bd 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -25,6 +25,7 @@
  #include 
  #include 
  #include "bpf.h"
+#include "libbpf.h"
  
  /*

   * When building perf, unistd.h is overrided. __NR_bpf is
@@ -97,7 +98,7 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn 
*insns,
return sys_bpf(BPF_PROG_LOAD, , sizeof(attr));
  }
  
-int bpf_map_update_elem(int fd, void *key, void *value,

+int bpf_map__update_elem(int fd, void *key, void *value,
u64 flags)


Please don't use '__' style API here. It is easily be confused with
bpf_map__*() in libbpf.h. They are APIs at different level.

bpf_map__*() are APIs for 'struct bpf_map's, they are object introduced
by libbpf, defined in libbpf.h. bpf_map_*() APIs operate on fd, they are
objects defined by kernel. bpf_map_*() APIs are declared in bpf.h.

In libbpf, bpf.h directly operates on kernel objects (fd), APIs in it
are named bpf_map_*(); libbpf.h operates on 'struct bpf_map' object,
APIs in it are named using bpf_map__*(). libbpf.h and bpf.h are independent
with each other.


  {
union bpf_attr attr;
@@ -110,3 +111,35 @@ int bpf_map_update_elem(int fd, void *key, void *value,
  
  	return sys_bpf(BPF_MAP_UPDATE_ELEM, , sizeof(attr));

  }
+
+int bpf_map__lookup_elem(int fd, void *key, void *value)
+{
+   union bpf_attr attr = {
+   .map_fd = fd,
+   .key = ptr_to_u64(key),
+   .value = ptr_to_u64(value),
+   };
+
+   return sys_bpf(BPF_MAP_LOOKUP_ELEM, , sizeof(attr));
+}
+
+int bpf_map__delete_elem(int fd, void *key)
+{
+   union bpf_attr attr = {
+   .map_fd = fd,
+   .key = ptr_to_u64(key),
+   };
+
+   return sys_bpf(BPF_MAP_DELETE_ELEM, , sizeof(attr));
+}
+
+int bpf_map__get_next_key(int fd, void *key, void *next_key)
+{
+   union bpf_attr attr = {
+   .map_fd = fd,
+   .key = ptr_to_u64(key),
+   .next_key = ptr_to_u64(next_key),
+   };
+
+   return sys_bpf(BPF_MAP_GET_NEXT_KEY, , sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index e8ba540..5ca834a 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -33,6 +33,4 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn 
*insns,
 u32 kern_version, char *log_buf,
 size_t log_buf_sz);
  
-int bpf_map_update_elem(int fd, void *key, void *value,

-   u64 flags);
  #endif
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index a18783b..dfb46d0 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -207,6 +207,11 @@ bpf_map__next(struct bpf_map *map, struct bpf_object *obj);
  int bpf_map__fd(struct bpf_map *map);
  const struct bpf_map_def *bpf_map__def(struct bpf_map *map);
  const char *bpf_map__name(struct bpf_map *map);
+int bpf_map__update_elem(int fd, void *key, void *value,
+   uint64_t flags);
+int bpf_map__lookup_elem(int fd, void *key, void *value);
+int bpf_map__delete_elem(int fd, void *key);
+int bpf_map__get_next_key(int fd, void *key, void *next_key);


As what we have discussed, the newly introduced functions should be added
in bpf.h.

Thank you.

Re: [PATCH 5/8] tools lib bpf: add missing functions

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

Some functions were missing in the library to be able to use it
in the case where the userspace is handling the maps in kernel.

The patch also renames functions to have a homogeneous naming
convention.

Signed-off-by: Eric Leblond 
---
  tools/lib/bpf/bpf.c| 35 ++-
  tools/lib/bpf/bpf.h|  2 --
  tools/lib/bpf/libbpf.h |  5 +
  3 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 4212ed6..c0e07bd 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -25,6 +25,7 @@
  #include 
  #include 
  #include "bpf.h"
+#include "libbpf.h"
  
  /*

   * When building perf, unistd.h is overrided. __NR_bpf is
@@ -97,7 +98,7 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn 
*insns,
return sys_bpf(BPF_PROG_LOAD, , sizeof(attr));
  }
  
-int bpf_map_update_elem(int fd, void *key, void *value,

+int bpf_map__update_elem(int fd, void *key, void *value,
u64 flags)


Please don't use '__' style API here. It is easily be confused with
bpf_map__*() in libbpf.h. They are APIs at different level.

bpf_map__*() are APIs for 'struct bpf_map's, they are object introduced
by libbpf, defined in libbpf.h. bpf_map_*() APIs operate on fd, they are
objects defined by kernel. bpf_map_*() APIs are declared in bpf.h.

In libbpf, bpf.h directly operates on kernel objects (fd), APIs in it
are named bpf_map_*(); libbpf.h operates on 'struct bpf_map' object,
APIs in it are named using bpf_map__*(). libbpf.h and bpf.h are independent
with each other.


  {
union bpf_attr attr;
@@ -110,3 +111,35 @@ int bpf_map_update_elem(int fd, void *key, void *value,
  
  	return sys_bpf(BPF_MAP_UPDATE_ELEM, , sizeof(attr));

  }
+
+int bpf_map__lookup_elem(int fd, void *key, void *value)
+{
+   union bpf_attr attr = {
+   .map_fd = fd,
+   .key = ptr_to_u64(key),
+   .value = ptr_to_u64(value),
+   };
+
+   return sys_bpf(BPF_MAP_LOOKUP_ELEM, , sizeof(attr));
+}
+
+int bpf_map__delete_elem(int fd, void *key)
+{
+   union bpf_attr attr = {
+   .map_fd = fd,
+   .key = ptr_to_u64(key),
+   };
+
+   return sys_bpf(BPF_MAP_DELETE_ELEM, , sizeof(attr));
+}
+
+int bpf_map__get_next_key(int fd, void *key, void *next_key)
+{
+   union bpf_attr attr = {
+   .map_fd = fd,
+   .key = ptr_to_u64(key),
+   .next_key = ptr_to_u64(next_key),
+   };
+
+   return sys_bpf(BPF_MAP_GET_NEXT_KEY, , sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index e8ba540..5ca834a 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -33,6 +33,4 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn 
*insns,
 u32 kern_version, char *log_buf,
 size_t log_buf_sz);
  
-int bpf_map_update_elem(int fd, void *key, void *value,

-   u64 flags);
  #endif
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index a18783b..dfb46d0 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -207,6 +207,11 @@ bpf_map__next(struct bpf_map *map, struct bpf_object *obj);
  int bpf_map__fd(struct bpf_map *map);
  const struct bpf_map_def *bpf_map__def(struct bpf_map *map);
  const char *bpf_map__name(struct bpf_map *map);
+int bpf_map__update_elem(int fd, void *key, void *value,
+   uint64_t flags);
+int bpf_map__lookup_elem(int fd, void *key, void *value);
+int bpf_map__delete_elem(int fd, void *key);
+int bpf_map__get_next_key(int fd, void *key, void *next_key);


As what we have discussed, the newly introduced functions should be added
in bpf.h.

Thank you.

Re: [PATCH] kconfig.h: remove config_enabled() macro

[Masahiro Yamada]

Hi Peter.


2016-10-17 3:44 GMT+09:00  :
>
> How is __is_defined() different from defined()?



defined() can be used only in pre-processor's #if context, like

#if defined(FOO)
  ...
#endif



__is_defined() can be used more flexibly.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH] kconfig.h: remove config_enabled() macro

[Masahiro Yamada]

Hi Peter.


2016-10-17 3:44 GMT+09:00  :
>
> How is __is_defined() different from defined()?



defined() can be used only in pre-processor's #if context, like

#if defined(FOO)
  ...
#endif



__is_defined() can be used more flexibly.




-- 
Best Regards
Masahiro Yamada

linux-next: Tree for Oct 17

[Stephen Rothwell]

Hi all,

Changes since 20161016:

The akpm-current tree still had its build failures for which I applied
2 patches.

Non-merge commits (relative to Linus' tree): 770
 999 files changed, 29247 insertions(+), 16481 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
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

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 (1001354ca341 Linux 4.9-rc1)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (8df0cc75f530 ARC: [build] Support gz, lzma 
compressed uImage)
Merging arm-current/fixes (fb833b1fbb68 ARM: fix delays)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (4c1fad64eff4 Merge tag 'for-f2fs-4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)
Merging net/master (fb5c6cfaec12 vmxnet3: avoid assumption about invalid dma_pa 
in vmxnet3_set_mc())
CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig
Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (6d3a4c404648 strparser: Propagate correct error code 
in strp_recv())
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for 
the Venue 8 Pro)
Merging mac80211/master (1d4de2e222b4 mac80211: fix CMD_FRAME for AP_VLAN)
Merging sound-current/for-linus (fdd8218d7d1b ALSA: line6: fix a crash in 
line6_hwdep_write())
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (b66484cd7470 Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (b66484cd7470 Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (b66484cd7470 Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6b7f456e67a1 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging staging.current/staging-linus (1001354ca341 Linux 4.9-rc1)
Merging char-misc.current/char-misc-linus (b66484cd7470 Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (1134ca268e73 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (c3afafa47898 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
e

linux-next: Tree for Oct 17

[Stephen Rothwell]

Hi all,

Changes since 20161016:

The akpm-current tree still had its build failures for which I applied
2 patches.

Non-merge commits (relative to Linus' tree): 770
 999 files changed, 29247 insertions(+), 16481 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
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

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 (1001354ca341 Linux 4.9-rc1)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (8df0cc75f530 ARC: [build] Support gz, lzma 
compressed uImage)
Merging arm-current/fixes (fb833b1fbb68 ARM: fix delays)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (4c1fad64eff4 Merge tag 'for-f2fs-4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)
Merging net/master (fb5c6cfaec12 vmxnet3: avoid assumption about invalid dma_pa 
in vmxnet3_set_mc())
CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig
Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (6d3a4c404648 strparser: Propagate correct error code 
in strp_recv())
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for 
the Venue 8 Pro)
Merging mac80211/master (1d4de2e222b4 mac80211: fix CMD_FRAME for AP_VLAN)
Merging sound-current/for-linus (fdd8218d7d1b ALSA: line6: fix a crash in 
line6_hwdep_write())
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (b66484cd7470 Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (b66484cd7470 Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (b66484cd7470 Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6b7f456e67a1 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging staging.current/staging-linus (1001354ca341 Linux 4.9-rc1)
Merging char-misc.current/char-misc-linus (b66484cd7470 Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (1134ca268e73 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (c3afafa47898 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
e

drivers/scsi/BusLogic.c:2554:1: warning: the frame size of 1148 bytes is larger than 1024 bytes

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 0766f788eb727e2e330d55d30545db65bcf2623f latent_entropy: Mark functions 
with __latent_entropy
date:   6 days ago
config: i386-randconfig-c0-10170932 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 0766f788eb727e2e330d55d30545db65bcf2623f
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/scsi/BusLogic.c: In function 'blogic_init':
>> drivers/scsi/BusLogic.c:2554:1: warning: the frame size of 1148 bytes is 
>> larger than 1024 bytes [-Wframe-larger-than=]
}
^

vim +2554 drivers/scsi/BusLogic.c

839cb99e Khalid Aziz2013-05-16  2538   remove Host 
Adapter from the list of registered
839cb99e Khalid Aziz2013-05-16  2539   BusLogic 
Host Adapters, destroy the CCBs, Release
839cb99e Khalid Aziz2013-05-16  2540   the System 
Resources, and Unregister the SCSI
^1da177e Linus Torvalds 2005-04-16  2541   Host.
^1da177e Linus Torvalds 2005-04-16  2542 */
839cb99e Khalid Aziz2013-05-16  2543
blogic_destroy_ccbs(myadapter);
839cb99e Khalid Aziz2013-05-16  2544
blogic_relres(myadapter);
839cb99e Khalid Aziz2013-05-16  2545
list_del(>host_list);
839cb99e Khalid Aziz2013-05-16  2546
scsi_host_put(host);
d2afb3ae Daniel Walker  2006-08-14  2547ret = -ENODEV;
^1da177e Linus Torvalds 2005-04-16  2548}
^1da177e Linus Torvalds 2005-04-16  2549}
839cb99e Khalid Aziz2013-05-16  2550kfree(adapter);
839cb99e Khalid Aziz2013-05-16  2551kfree(blogic_probeinfo_list);
839cb99e Khalid Aziz2013-05-16  2552blogic_probeinfo_list = NULL;
d2afb3ae Daniel Walker  2006-08-14  2553return ret;
^1da177e Linus Torvalds 2005-04-16 @2554  }
^1da177e Linus Torvalds 2005-04-16  2555  
^1da177e Linus Torvalds 2005-04-16  2556  
^1da177e Linus Torvalds 2005-04-16  2557  /*
839cb99e Khalid Aziz2013-05-16  2558blogic_deladapter releases all 
resources previously acquired to
^1da177e Linus Torvalds 2005-04-16  2559support a specific Host Adapter, 
including the I/O Address range, and
^1da177e Linus Torvalds 2005-04-16  2560unregisters the BusLogic Host 
Adapter.
^1da177e Linus Torvalds 2005-04-16  2561  */
^1da177e Linus Torvalds 2005-04-16  2562  

:: The code at line 2554 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

drivers/scsi/BusLogic.c:2554:1: warning: the frame size of 1148 bytes is larger than 1024 bytes

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 0766f788eb727e2e330d55d30545db65bcf2623f latent_entropy: Mark functions 
with __latent_entropy
date:   6 days ago
config: i386-randconfig-c0-10170932 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 0766f788eb727e2e330d55d30545db65bcf2623f
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/scsi/BusLogic.c: In function 'blogic_init':
>> drivers/scsi/BusLogic.c:2554:1: warning: the frame size of 1148 bytes is 
>> larger than 1024 bytes [-Wframe-larger-than=]
}
^

vim +2554 drivers/scsi/BusLogic.c

839cb99e Khalid Aziz2013-05-16  2538   remove Host 
Adapter from the list of registered
839cb99e Khalid Aziz2013-05-16  2539   BusLogic 
Host Adapters, destroy the CCBs, Release
839cb99e Khalid Aziz2013-05-16  2540   the System 
Resources, and Unregister the SCSI
^1da177e Linus Torvalds 2005-04-16  2541   Host.
^1da177e Linus Torvalds 2005-04-16  2542 */
839cb99e Khalid Aziz2013-05-16  2543
blogic_destroy_ccbs(myadapter);
839cb99e Khalid Aziz2013-05-16  2544
blogic_relres(myadapter);
839cb99e Khalid Aziz2013-05-16  2545
list_del(>host_list);
839cb99e Khalid Aziz2013-05-16  2546
scsi_host_put(host);
d2afb3ae Daniel Walker  2006-08-14  2547ret = -ENODEV;
^1da177e Linus Torvalds 2005-04-16  2548}
^1da177e Linus Torvalds 2005-04-16  2549}
839cb99e Khalid Aziz2013-05-16  2550kfree(adapter);
839cb99e Khalid Aziz2013-05-16  2551kfree(blogic_probeinfo_list);
839cb99e Khalid Aziz2013-05-16  2552blogic_probeinfo_list = NULL;
d2afb3ae Daniel Walker  2006-08-14  2553return ret;
^1da177e Linus Torvalds 2005-04-16 @2554  }
^1da177e Linus Torvalds 2005-04-16  2555  
^1da177e Linus Torvalds 2005-04-16  2556  
^1da177e Linus Torvalds 2005-04-16  2557  /*
839cb99e Khalid Aziz2013-05-16  2558blogic_deladapter releases all 
resources previously acquired to
^1da177e Linus Torvalds 2005-04-16  2559support a specific Host Adapter, 
including the I/O Address range, and
^1da177e Linus Torvalds 2005-04-16  2560unregisters the BusLogic Host 
Adapter.
^1da177e Linus Torvalds 2005-04-16  2561  */
^1da177e Linus Torvalds 2005-04-16  2562  

:: The code at line 2554 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle

[zhong jiang]

Hi,  Vitaly

About the following patch,  is it right?

Thanks
zhongjiang
On 2016/10/13 12:02, zhongjiang wrote:
> From: zhong jiang 
>
> At present, zhdr->first_num plus bud can exceed the BUDDY_MASK
> in encode_handle, it will lead to the the caller handle_to_buddy
> return the error value.
>
> The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK,
> it will be consistent with handle_to_z3fold_header. At the same time,
> change the BUDDY_MASK to PAGE_MASK in handle_to_buddy is better.
>
> Signed-off-by: zhong jiang 
> ---
>  mm/z3fold.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/z3fold.c b/mm/z3fold.c
> index 8f9e89c..e8fc216 100644
> --- a/mm/z3fold.c
> +++ b/mm/z3fold.c
> @@ -169,7 +169,7 @@ static unsigned long encode_handle(struct z3fold_header 
> *zhdr, enum buddy bud)
>  
>   handle = (unsigned long)zhdr;
>   if (bud != HEADLESS)
> - handle += (bud + zhdr->first_num) & BUDDY_MASK;
> + handle += (bud + zhdr->first_num) & PAGE_MASK;
>   return handle;
>  }
>  
> @@ -183,7 +183,7 @@ static struct z3fold_header 
> *handle_to_z3fold_header(unsigned long handle)
>  static enum buddy handle_to_buddy(unsigned long handle)
>  {
>   struct z3fold_header *zhdr = handle_to_z3fold_header(handle);
> - return (handle - zhdr->first_num) & BUDDY_MASK;
> + return (handle - zhdr->first_num) & PAGE_MASK;
>  }
>  
>  /*

Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle

[zhong jiang]

Hi,  Vitaly

About the following patch,  is it right?

Thanks
zhongjiang
On 2016/10/13 12:02, zhongjiang wrote:
> From: zhong jiang 
>
> At present, zhdr->first_num plus bud can exceed the BUDDY_MASK
> in encode_handle, it will lead to the the caller handle_to_buddy
> return the error value.
>
> The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK,
> it will be consistent with handle_to_z3fold_header. At the same time,
> change the BUDDY_MASK to PAGE_MASK in handle_to_buddy is better.
>
> Signed-off-by: zhong jiang 
> ---
>  mm/z3fold.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/z3fold.c b/mm/z3fold.c
> index 8f9e89c..e8fc216 100644
> --- a/mm/z3fold.c
> +++ b/mm/z3fold.c
> @@ -169,7 +169,7 @@ static unsigned long encode_handle(struct z3fold_header 
> *zhdr, enum buddy bud)
>  
>   handle = (unsigned long)zhdr;
>   if (bud != HEADLESS)
> - handle += (bud + zhdr->first_num) & BUDDY_MASK;
> + handle += (bud + zhdr->first_num) & PAGE_MASK;
>   return handle;
>  }
>  
> @@ -183,7 +183,7 @@ static struct z3fold_header 
> *handle_to_z3fold_header(unsigned long handle)
>  static enum buddy handle_to_buddy(unsigned long handle)
>  {
>   struct z3fold_header *zhdr = handle_to_z3fold_header(handle);
> - return (handle - zhdr->first_num) & BUDDY_MASK;
> + return (handle - zhdr->first_num) & PAGE_MASK;
>  }
>  
>  /*

Re: [PATCH 4/8] tools lib bpf: export function to set type

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

Current API was not allowing the user to set a type like socket
filter. To avoid a setter function for each type, the patch simply
exports a set function that takes the type in parameter.

Signed-off-by: Eric Leblond 
---
  tools/lib/bpf/libbpf.c | 19 +--
  tools/lib/bpf/libbpf.h |  3 +++
  2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 90932f1..7cd341e 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1336,26 +1336,25 @@ int bpf_program__nth_fd(struct bpf_program *prog, int n)
return fd;
  }
  
-static void bpf_program__set_type(struct bpf_program *prog,

- enum bpf_prog_type type)
+int bpf_program__set_type(struct bpf_program *prog, unsigned int type)
  {
+   if (!prog)
+   return -EINVAL;
+   if (type >= __MAX_BPF_PROG_TYPE)
+   return -EINVAL;
+
prog->type = type;
+   return 0;
  }
  
  int bpf_program__set_tracepoint(struct bpf_program *prog)

  {
-   if (!prog)
-   return -EINVAL;
-   bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
-   return 0;
+   return bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
  }
  
  int bpf_program__set_kprobe(struct bpf_program *prog)

  {
-   if (!prog)
-   return -EINVAL;
-   bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
-   return 0;
+   return bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
  }
  
  static bool bpf_program__is_type(struct bpf_program *prog,

diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index e40c8d3..a18783b 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -173,6 +173,9 @@ int bpf_program__set_kprobe(struct bpf_program *prog);
  bool bpf_program__is_tracepoint(struct bpf_program *prog);
  bool bpf_program__is_kprobe(struct bpf_program *prog);
  
+int bpf_program__set_type(struct bpf_program *prog,

+ unsigned int type);
+


Although you don't include uapi/linux/bpf.h in this patch, logically
you add this dependency.

Please continously add bpf_program__set_socket_filter() and
bpf_program__is_socket_filter() like what we do for tracepoint.
This way libbpf.h is indenpendent from kernel header.

We can use macro in both .h and .c.

Thank you.

Re: [PATCH 4/8] tools lib bpf: export function to set type

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

Current API was not allowing the user to set a type like socket
filter. To avoid a setter function for each type, the patch simply
exports a set function that takes the type in parameter.

Signed-off-by: Eric Leblond 
---
  tools/lib/bpf/libbpf.c | 19 +--
  tools/lib/bpf/libbpf.h |  3 +++
  2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 90932f1..7cd341e 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1336,26 +1336,25 @@ int bpf_program__nth_fd(struct bpf_program *prog, int n)
return fd;
  }
  
-static void bpf_program__set_type(struct bpf_program *prog,

- enum bpf_prog_type type)
+int bpf_program__set_type(struct bpf_program *prog, unsigned int type)
  {
+   if (!prog)
+   return -EINVAL;
+   if (type >= __MAX_BPF_PROG_TYPE)
+   return -EINVAL;
+
prog->type = type;
+   return 0;
  }
  
  int bpf_program__set_tracepoint(struct bpf_program *prog)

  {
-   if (!prog)
-   return -EINVAL;
-   bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
-   return 0;
+   return bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
  }
  
  int bpf_program__set_kprobe(struct bpf_program *prog)

  {
-   if (!prog)
-   return -EINVAL;
-   bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
-   return 0;
+   return bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
  }
  
  static bool bpf_program__is_type(struct bpf_program *prog,

diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index e40c8d3..a18783b 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -173,6 +173,9 @@ int bpf_program__set_kprobe(struct bpf_program *prog);
  bool bpf_program__is_tracepoint(struct bpf_program *prog);
  bool bpf_program__is_kprobe(struct bpf_program *prog);
  
+int bpf_program__set_type(struct bpf_program *prog,

+ unsigned int type);
+


Although you don't include uapi/linux/bpf.h in this patch, logically
you add this dependency.

Please continously add bpf_program__set_socket_filter() and
bpf_program__is_socket_filter() like what we do for tracepoint.
This way libbpf.h is indenpendent from kernel header.

We can use macro in both .h and .c.

Thank you.

Re: USB GADGET: have a question about usb2eth

[Peter Chen]

On Sat, Oct 15, 2016 at 09:19:33AM +, Lipengcheng wrote:
> Hi,
>   I have a question about usb2eth. In the function gen_ndis_set_resp of 
> the rndis.c, the value of *params->filter may be 0x20 from the pc set 
> command; Howerver the value is used cdc_filter = dev->port_usb->cdc_filter in 
> the function eth_start_xmit of the u_ether.c. If we do not judge the 
> RNDIS_PACKET_TYPE_PROMISCUOUS and the value is 0x20, the broadcast packet can 
> not send the pc win7; At the result, the linux ping the win7 is slow an the 
> first.
> 

The Felipe's email has changed, please check MAINTAINERS.
Besides, would you wrap up line to 75 characters please?

-- 

Best Regards,
Peter Chen

Re: [LKP] [x86] 811565123a: BUG: kernel hang in early-boot stage, last printk: Probing EDD (edd=off to disable)... ok

[Ye Xiaolong]

On 10/14, Andi Kleen wrote:
>On Fri, Oct 14, 2016 at 12:56:00PM +0800, Ye Xiaolong wrote:
>> On 10/14, Ye Xiaolong wrote:
>> >On 10/13, Andi Kleen wrote:
>> >>Andi Kleen  writes:
>> >>
>> >>Any comments on this?
>> >>
>> >>I still cannot reproduce the failure unfortunately.
>> >>
>> >
>> >Btw, you can try below commands to reproduce the error on your local
>> >host, they will download the necessary images and run QEMU:
>> >
>> >   git clone 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> >   cd lkp-tests
>> >   bin/lkp qemu -k KERNEL job-script  # job-script is attached in the 
>> > original report email
>> 
>> Results show this hang may be related to gcc version, with gcc version
>> 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3), kernel could boot without early
>> hang, but if kernel was built with gcc version 6.2.0 20160901 (Debian
>> 6.2.0-3), it will stuck in the early stage:
>
>I built a mainline gcc 6.2, unfortunately still doesn't reproduce. The kernel
>with your config boots to root.
>
>My guess is that something is broken with paravirt ops on 32bit
>on that compiler.
>
>I created a new patch with the probing code moved to a separate
>function. Can you test if that works?
>

Kernel can boot to root with this new version patch.

Tested-by: Xiaolong Ye 


Thanks,
Xiaolong


>-Andi
>
>
>commit 65c92de6678f04ce14b237d7073e164b98d9a8be
>Author: Andi Kleen 
>Date:   Wed May 4 06:07:44 2016 -0700
>
>x86: Report Intel platform_id in /proc/cpuinfo
>
>We have a need to distinguish systems based on their platform ID.
>For example this is useful to distinguish systems with L4 cache
>versus ones without.
>
>There is a 3 bit identifier (also called processor flags) in
>the IA32_PLATFORM_ID MSR that can give a more fine grained
>identification of the CPU than just the model number/stepping.
>
>IA32_PLATFORM_ID is architectural.
>
>The MSR can be also accessed through /dev/cpu/*/msr, but that
>requires root and is awkward.
>
>The patch moves the reading of PLATFORM_INFO from the
>(late) microcode driver code into the main intel CPU initialization
>path and then also prints it in /proc/cpuinfo
>
>v2: Handle 0 platform_id. Fix commit message.
>v3: Move some code to cpu/intel.c
>v4: Update description too.
>v5: Move msr probe code out of line to w/a potential gcc 6 bug
>Cc: h...@hmh.eng.br
>Signed-off-by: Andi Kleen 
>
>diff --git a/arch/x86/include/asm/processor.h 
>b/arch/x86/include/asm/processor.h
>index 63def9537a2d..c1313b3f3e59 100644
>--- a/arch/x86/include/asm/processor.h
>+++ b/arch/x86/include/asm/processor.h
>@@ -135,6 +135,8 @@ struct cpuinfo_x86 {
>   /* Index into per_cpu list: */
>   u16 cpu_index;
>   u32 microcode;
>+  u32 platform_id;
>+  u8  has_platform_id;
> };
> 
> #define X86_VENDOR_INTEL  0
>diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
>index fcd484d2bb03..7da7f008cee0 100644
>--- a/arch/x86/kernel/cpu/intel.c
>+++ b/arch/x86/kernel/cpu/intel.c
>@@ -61,6 +61,19 @@ void check_mpx_erratum(struct cpuinfo_x86 *c)
>   }
> }
> 
>+/* noinline to work around problem with gcc 6.2 */
>+static noinline void probe_platformid(struct cpuinfo_x86 *c)
>+{
>+  if ((c->x86_model >= 5) || (c->x86 > 6)) {
>+  unsigned val[2];
>+
>+  /* get processor flags from MSR 0x17 */
>+  rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
>+  c->platform_id = (val[1] >> 18) & 7;
>+  c->has_platform_id = true;
>+  }
>+}
>+
> static void early_init_intel(struct cpuinfo_x86 *c)
> {
>   u64 misc_enable;
>@@ -211,6 +224,8 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>   }
> 
>   check_mpx_erratum(c);
>+
>+  probe_platformid(c);
> }
> 
> #ifdef CONFIG_X86_32
>diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
>b/arch/x86/kernel/cpu/microcode/intel.c
>index cdc0deab00c9..fab07e49192e 100644
>--- a/arch/x86/kernel/cpu/microcode/intel.c
>+++ b/arch/x86/kernel/cpu/microcode/intel.c
>@@ -855,17 +855,13 @@ static int collect_cpu_info(int cpu_num, struct 
>cpu_signature *csig)
> {
>   static struct cpu_signature prev;
>   struct cpuinfo_x86 *c = _data(cpu_num);
>-  unsigned int val[2];
> 
>   memset(csig, 0, sizeof(*csig));
> 
>   csig->sig = cpuid_eax(0x0001);
> 
>-  if ((c->x86_model >= 5) || (c->x86 > 6)) {
>-  /* get processor flags from MSR 0x17 */
>-  rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
>-  csig->pf = 1 << ((val[1] >> 18) & 7);
>-  }
>+  if (c->has_platform_id)
>+  csig->pf = 1 << c->platform_id;
> 
>   csig->rev = c->microcode;
> 
>diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c

Re: USB GADGET: have a question about usb2eth

[Peter Chen]

On Sat, Oct 15, 2016 at 09:19:33AM +, Lipengcheng wrote:
> Hi,
>   I have a question about usb2eth. In the function gen_ndis_set_resp of 
> the rndis.c, the value of *params->filter may be 0x20 from the pc set 
> command; Howerver the value is used cdc_filter = dev->port_usb->cdc_filter in 
> the function eth_start_xmit of the u_ether.c. If we do not judge the 
> RNDIS_PACKET_TYPE_PROMISCUOUS and the value is 0x20, the broadcast packet can 
> not send the pc win7; At the result, the linux ping the win7 is slow an the 
> first.
> 

The Felipe's email has changed, please check MAINTAINERS.
Besides, would you wrap up line to 75 characters please?

-- 

Best Regards,
Peter Chen

Re: [LKP] [x86] 811565123a: BUG: kernel hang in early-boot stage, last printk: Probing EDD (edd=off to disable)... ok

[Ye Xiaolong]

On 10/14, Andi Kleen wrote:
>On Fri, Oct 14, 2016 at 12:56:00PM +0800, Ye Xiaolong wrote:
>> On 10/14, Ye Xiaolong wrote:
>> >On 10/13, Andi Kleen wrote:
>> >>Andi Kleen  writes:
>> >>
>> >>Any comments on this?
>> >>
>> >>I still cannot reproduce the failure unfortunately.
>> >>
>> >
>> >Btw, you can try below commands to reproduce the error on your local
>> >host, they will download the necessary images and run QEMU:
>> >
>> >   git clone 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> >   cd lkp-tests
>> >   bin/lkp qemu -k KERNEL job-script  # job-script is attached in the 
>> > original report email
>> 
>> Results show this hang may be related to gcc version, with gcc version
>> 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3), kernel could boot without early
>> hang, but if kernel was built with gcc version 6.2.0 20160901 (Debian
>> 6.2.0-3), it will stuck in the early stage:
>
>I built a mainline gcc 6.2, unfortunately still doesn't reproduce. The kernel
>with your config boots to root.
>
>My guess is that something is broken with paravirt ops on 32bit
>on that compiler.
>
>I created a new patch with the probing code moved to a separate
>function. Can you test if that works?
>

Kernel can boot to root with this new version patch.

Tested-by: Xiaolong Ye 


Thanks,
Xiaolong


>-Andi
>
>
>commit 65c92de6678f04ce14b237d7073e164b98d9a8be
>Author: Andi Kleen 
>Date:   Wed May 4 06:07:44 2016 -0700
>
>x86: Report Intel platform_id in /proc/cpuinfo
>
>We have a need to distinguish systems based on their platform ID.
>For example this is useful to distinguish systems with L4 cache
>versus ones without.
>
>There is a 3 bit identifier (also called processor flags) in
>the IA32_PLATFORM_ID MSR that can give a more fine grained
>identification of the CPU than just the model number/stepping.
>
>IA32_PLATFORM_ID is architectural.
>
>The MSR can be also accessed through /dev/cpu/*/msr, but that
>requires root and is awkward.
>
>The patch moves the reading of PLATFORM_INFO from the
>(late) microcode driver code into the main intel CPU initialization
>path and then also prints it in /proc/cpuinfo
>
>v2: Handle 0 platform_id. Fix commit message.
>v3: Move some code to cpu/intel.c
>v4: Update description too.
>v5: Move msr probe code out of line to w/a potential gcc 6 bug
>Cc: h...@hmh.eng.br
>Signed-off-by: Andi Kleen 
>
>diff --git a/arch/x86/include/asm/processor.h 
>b/arch/x86/include/asm/processor.h
>index 63def9537a2d..c1313b3f3e59 100644
>--- a/arch/x86/include/asm/processor.h
>+++ b/arch/x86/include/asm/processor.h
>@@ -135,6 +135,8 @@ struct cpuinfo_x86 {
>   /* Index into per_cpu list: */
>   u16 cpu_index;
>   u32 microcode;
>+  u32 platform_id;
>+  u8  has_platform_id;
> };
> 
> #define X86_VENDOR_INTEL  0
>diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
>index fcd484d2bb03..7da7f008cee0 100644
>--- a/arch/x86/kernel/cpu/intel.c
>+++ b/arch/x86/kernel/cpu/intel.c
>@@ -61,6 +61,19 @@ void check_mpx_erratum(struct cpuinfo_x86 *c)
>   }
> }
> 
>+/* noinline to work around problem with gcc 6.2 */
>+static noinline void probe_platformid(struct cpuinfo_x86 *c)
>+{
>+  if ((c->x86_model >= 5) || (c->x86 > 6)) {
>+  unsigned val[2];
>+
>+  /* get processor flags from MSR 0x17 */
>+  rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
>+  c->platform_id = (val[1] >> 18) & 7;
>+  c->has_platform_id = true;
>+  }
>+}
>+
> static void early_init_intel(struct cpuinfo_x86 *c)
> {
>   u64 misc_enable;
>@@ -211,6 +224,8 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>   }
> 
>   check_mpx_erratum(c);
>+
>+  probe_platformid(c);
> }
> 
> #ifdef CONFIG_X86_32
>diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
>b/arch/x86/kernel/cpu/microcode/intel.c
>index cdc0deab00c9..fab07e49192e 100644
>--- a/arch/x86/kernel/cpu/microcode/intel.c
>+++ b/arch/x86/kernel/cpu/microcode/intel.c
>@@ -855,17 +855,13 @@ static int collect_cpu_info(int cpu_num, struct 
>cpu_signature *csig)
> {
>   static struct cpu_signature prev;
>   struct cpuinfo_x86 *c = _data(cpu_num);
>-  unsigned int val[2];
> 
>   memset(csig, 0, sizeof(*csig));
> 
>   csig->sig = cpuid_eax(0x0001);
> 
>-  if ((c->x86_model >= 5) || (c->x86 > 6)) {
>-  /* get processor flags from MSR 0x17 */
>-  rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
>-  csig->pf = 1 << ((val[1] >> 18) & 7);
>-  }
>+  if (c->has_platform_id)
>+  csig->pf = 1 << c->platform_id;
> 
>   csig->rev = c->microcode;
> 
>diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
>index 18ca99f2798b..5345d50ed709 100644
>--- a/arch/x86/kernel/cpu/proc.c
>+++ 

Re: [PATCH] z3fold: remove the unnecessary limit in z3fold_compact_page

[zhong jiang]

On 2016/10/15 3:25, Vitaly Wool wrote:
> On Fri, Oct 14, 2016 at 3:35 PM, zhongjiang  wrote:
>> From: zhong jiang 
>>
>> z3fold compact page has nothing with the last_chunks. even if
>> last_chunks is not free, compact page will proceed.
>>
>> The patch just remove the limit without functional change.
>>
>> Signed-off-by: zhong jiang 
>> ---
>>  mm/z3fold.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/mm/z3fold.c b/mm/z3fold.c
>> index e8fc216..4668e1c 100644
>> --- a/mm/z3fold.c
>> +++ b/mm/z3fold.c
>> @@ -258,8 +258,7 @@ static int z3fold_compact_page(struct z3fold_header 
>> *zhdr)
>>
>>
>> if (!test_bit(MIDDLE_CHUNK_MAPPED, >private) &&
>> -   zhdr->middle_chunks != 0 &&
>> -   zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
>> +   zhdr->middle_chunks != 0 && zhdr->first_chunks == 0) {
>> memmove(beg + ZHDR_SIZE_ALIGNED,
>> beg + (zhdr->start_middle << CHUNK_SHIFT),
>> zhdr->middle_chunks << CHUNK_SHIFT);
> This check is actually important because if we move the middle chunk
> to the first and leave the last chunk, handles will become invalid and
> there won't be any easy way to fix that.
>
> Best regards,
>Vitaly
>
> .
>
 Thanks for you reply. you are right. Leave the last chunk to compact will
 lead to the first_num increase. Thus, handle_to_buddy will become invalid.

 Thanks
 zhongjiang
 

Re: [PATCH] z3fold: remove the unnecessary limit in z3fold_compact_page

[zhong jiang]

On 2016/10/15 3:25, Vitaly Wool wrote:
> On Fri, Oct 14, 2016 at 3:35 PM, zhongjiang  wrote:
>> From: zhong jiang 
>>
>> z3fold compact page has nothing with the last_chunks. even if
>> last_chunks is not free, compact page will proceed.
>>
>> The patch just remove the limit without functional change.
>>
>> Signed-off-by: zhong jiang 
>> ---
>>  mm/z3fold.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/mm/z3fold.c b/mm/z3fold.c
>> index e8fc216..4668e1c 100644
>> --- a/mm/z3fold.c
>> +++ b/mm/z3fold.c
>> @@ -258,8 +258,7 @@ static int z3fold_compact_page(struct z3fold_header 
>> *zhdr)
>>
>>
>> if (!test_bit(MIDDLE_CHUNK_MAPPED, >private) &&
>> -   zhdr->middle_chunks != 0 &&
>> -   zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
>> +   zhdr->middle_chunks != 0 && zhdr->first_chunks == 0) {
>> memmove(beg + ZHDR_SIZE_ALIGNED,
>> beg + (zhdr->start_middle << CHUNK_SHIFT),
>> zhdr->middle_chunks << CHUNK_SHIFT);
> This check is actually important because if we move the middle chunk
> to the first and leave the last chunk, handles will become invalid and
> there won't be any easy way to fix that.
>
> Best regards,
>Vitaly
>
> .
>
 Thanks for you reply. you are right. Leave the last chunk to compact will
 lead to the first_num increase. Thus, handle_to_buddy will become invalid.

 Thanks
 zhongjiang
 

Re: [PATCH 3/8] tools: Sync tools/include/uapi/linux/bpf.h with the kernel

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

Signed-off-by: Eric Leblond 


Commit message is required.

Thank you.


---
  tools/include/uapi/linux/bpf.h | 52 ++
  1 file changed, 52 insertions(+)

diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9e5fc16..570287f 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -95,6 +95,8 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SCHED_ACT,
BPF_PROG_TYPE_TRACEPOINT,
BPF_PROG_TYPE_XDP,
+   BPF_PROG_TYPE_PERF_EVENT,
+   __MAX_BPF_PROG_TYPE,
  };
  
  #define BPF_PSEUDO_MAP_FD	1

@@ -375,6 +377,56 @@ enum bpf_func_id {
 */
BPF_FUNC_probe_write_user,
  
+	/**

+* bpf_current_task_under_cgroup(map, index) - Check cgroup2 membership 
of current task
+* @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
+* @index: index of the cgroup in the bpf_map
+* Return:
+*   == 0 current failed the cgroup2 descendant test
+*   == 1 current succeeded the cgroup2 descendant test
+*< 0 error
+*/
+   BPF_FUNC_current_task_under_cgroup,
+
+   /**
+* bpf_skb_change_tail(skb, len, flags)
+* The helper will resize the skb to the given new size,
+* to be used f.e. with control messages.
+* @skb: pointer to skb
+* @len: new skb length
+* @flags: reserved
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_tail,
+
+   /**
+* bpf_skb_pull_data(skb, len)
+* The helper will pull in non-linear data in case the
+* skb is non-linear and not all of len are part of the
+* linear section. Only needed for read/write with direct
+* packet access.
+* @skb: pointer to skb
+* @len: len to make read/writeable
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_pull_data,
+
+   /**
+* bpf_csum_update(skb, csum)
+* Adds csum into skb->csum in case of CHECKSUM_COMPLETE.
+* @skb: pointer to skb
+* @csum: csum to add
+* Return: csum on success or negative error
+*/
+   BPF_FUNC_csum_update,
+
+   /**
+* bpf_set_hash_invalid(skb)
+* Invalidate current skb>hash.
+* @skb: pointer to skb
+*/
+   BPF_FUNC_set_hash_invalid,
+
__BPF_FUNC_MAX_ID,
  };
  

Re: [PATCH 3/8] tools: Sync tools/include/uapi/linux/bpf.h with the kernel

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

Signed-off-by: Eric Leblond 


Commit message is required.

Thank you.


---
  tools/include/uapi/linux/bpf.h | 52 ++
  1 file changed, 52 insertions(+)

diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9e5fc16..570287f 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -95,6 +95,8 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SCHED_ACT,
BPF_PROG_TYPE_TRACEPOINT,
BPF_PROG_TYPE_XDP,
+   BPF_PROG_TYPE_PERF_EVENT,
+   __MAX_BPF_PROG_TYPE,
  };
  
  #define BPF_PSEUDO_MAP_FD	1

@@ -375,6 +377,56 @@ enum bpf_func_id {
 */
BPF_FUNC_probe_write_user,
  
+	/**

+* bpf_current_task_under_cgroup(map, index) - Check cgroup2 membership 
of current task
+* @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
+* @index: index of the cgroup in the bpf_map
+* Return:
+*   == 0 current failed the cgroup2 descendant test
+*   == 1 current succeeded the cgroup2 descendant test
+*< 0 error
+*/
+   BPF_FUNC_current_task_under_cgroup,
+
+   /**
+* bpf_skb_change_tail(skb, len, flags)
+* The helper will resize the skb to the given new size,
+* to be used f.e. with control messages.
+* @skb: pointer to skb
+* @len: new skb length
+* @flags: reserved
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_tail,
+
+   /**
+* bpf_skb_pull_data(skb, len)
+* The helper will pull in non-linear data in case the
+* skb is non-linear and not all of len are part of the
+* linear section. Only needed for read/write with direct
+* packet access.
+* @skb: pointer to skb
+* @len: len to make read/writeable
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_pull_data,
+
+   /**
+* bpf_csum_update(skb, csum)
+* Adds csum into skb->csum in case of CHECKSUM_COMPLETE.
+* @skb: pointer to skb
+* @csum: csum to add
+* Return: csum on success or negative error
+*/
+   BPF_FUNC_csum_update,
+
+   /**
+* bpf_set_hash_invalid(skb)
+* Invalidate current skb>hash.
+* @skb: pointer to skb
+*/
+   BPF_FUNC_set_hash_invalid,
+
__BPF_FUNC_MAX_ID,
  };
  

Re: [PATCH 1/8] tools lib bpf: add error functions

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

The include of err.h is not explicitely needed in exported
functions and it was causing include conflict with some existing
code due to redefining some macros.

To fix this, let's have error handling functions provided by the
library. Furthermore this will allow user to have an homogeneous
API.

Signed-off-by: Eric Leblond 
---
  tools/lib/bpf/libbpf.c | 11 +++
  tools/lib/bpf/libbpf.h |  4 +++-
  2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index b699aea..90932f1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -1447,3 +1448,13 @@ bpf_object__find_map_by_name(struct bpf_object *obj, const char *name)

}
return NULL;
  }
+
+bool bpf__is_error(const void *ptr)


Please use libbpf_is_error(), like libbpf_set_print. We use '__' because 
we want

to use the OO concept. This utility is not OO.


+{
+   return IS_ERR(ptr);
+}
+
+long bpf__get_error(const void *ptr)


Same, please call it libbpf_get_error().

Thank you.

Re: [PATCH 1/8] tools lib bpf: add error functions

[Wangnan (F)]

On 2016/10/17 5:18, Eric Leblond wrote:

The include of err.h is not explicitely needed in exported
functions and it was causing include conflict with some existing
code due to redefining some macros.

To fix this, let's have error handling functions provided by the
library. Furthermore this will allow user to have an homogeneous
API.

Signed-off-by: Eric Leblond 
---
  tools/lib/bpf/libbpf.c | 11 +++
  tools/lib/bpf/libbpf.h |  4 +++-
  2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index b699aea..90932f1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -1447,3 +1448,13 @@ bpf_object__find_map_by_name(struct bpf_object *obj, const char *name)

}
return NULL;
  }
+
+bool bpf__is_error(const void *ptr)


Please use libbpf_is_error(), like libbpf_set_print. We use '__' because 
we want

to use the OO concept. This utility is not OO.


+{
+   return IS_ERR(ptr);
+}
+
+long bpf__get_error(const void *ptr)


Same, please call it libbpf_get_error().

Thank you.

Re: [PATCH v8 0/8] power: add power sequence library

[Peter Chen]

On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > Hi all,
> > 
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >  
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> > driver).
> > 
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> > 
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> > 
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> > 
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> > 
> > Changes for v8:
> > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
> >   preallocate instances problem which the number of instance is decided at
> >   compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> > - Delete pwrseq_compatible_sample.c which is the demo purpose to show 
> > compatible
> >   match method. [Patch 2/8]
> > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
> > 
> > Changes for v7:
> > - Create kinds of power sequence instance at postcore_initcall, and match
> >   the instance with node using compatible string, the beneit of this is
> >   the host driver doesn't need to consider which pwrseq instance needs
> >   to be used, and pwrseq core will match it, however, it eats some memories
> >   if less power sequence instances are used. [Patch 2/8]
> > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. 
> > [Patch 2/8]
> > - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> >   use device_node for parameters at pwrseq_on. [Patch 2/8]
> > - Simplify the caller to use power sequence, follows Alan's commnets [Patch 
> > 4/8]
> > - Tested three pwrseq instances together using both specific compatible 
> > string and
> >   generic libraries.
> > 
> > Changes for v6:
> > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> > - Change chipidea core of_node assignment for coming user. (patch [5/6])
> > - Applies Joshua Clayton's three dts changes for two boards,
> >   the USB device's reg has only #address-cells, but without #size-cells.
> > 
> > Changes for v5:
> > - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> > - Fix the linker error when the pwrseq user is compiled as module
> > 
> > Changes for v4:
> > - Create the patch on next-20160722 
> > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> > - Using more friendly wait method for reset gpio [Patch 2/6]
> > - Support multiple input clocks [Patch 2/6]
> > - Add Rob Herring's ack for DT changes
> > - Add Joshua Clayton's Tested-by
> > 
> > Changes for v3:
> > - Delete "power-sequence" property at binding-doc, and change related code
> >   at both library and user code.
> > - Change binding-doc example node name with Rob's comments
> > - of_get_named_gpio_flags only gets the gpio, but without setting gpio 
> > flags,
> >   add additional code request gpio with proper gpio flags
> > - Add Philipp Zabel's Ack and MAINTAINER's entry
> > 
> > Changes for v2:
> > - Delete "pwrseq" prefix and clock-names for properties at dt binding
> > - Should use structure not but its pointer for kzalloc
> > - Since chipidea core has no of_node, let core's of_node equals glue
> >   layer's at core's probe
> > 
> > Joshua Clayton (2):
> >   ARM: dts: imx6qdl: Enable usb node children with 
> >   ARM: dts: imx6q-evi: Fix onboard hub reset line
> > 
> > Peter Chen (6):
> >   binding-doc: power: pwrseq-generic: add binding doc for generic power
> > sequence library
> >   power: add power sequence library
> >   binding-doc: usb: usb-device: add optional properties for power
> > sequence
> >   usb: core: add power sequence handling for USB devices
> >   usb: chipidea: let chipidea core device of_node equal's glue layer
> > device of_node
> >   ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
> > 
> >  .../bindings/power/pwrseq/pwrseq-generic.txt   |  48 ++
> >  .../devicetree/bindings/usb/usb-device.txt

Re: [PATCH v8 0/8] power: add power sequence library

[Peter Chen]

On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > Hi all,
> > 
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >  
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> > driver).
> > 
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> > 
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> > 
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> > 
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> > 
> > Changes for v8:
> > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
> >   preallocate instances problem which the number of instance is decided at
> >   compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> > - Delete pwrseq_compatible_sample.c which is the demo purpose to show 
> > compatible
> >   match method. [Patch 2/8]
> > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
> > 
> > Changes for v7:
> > - Create kinds of power sequence instance at postcore_initcall, and match
> >   the instance with node using compatible string, the beneit of this is
> >   the host driver doesn't need to consider which pwrseq instance needs
> >   to be used, and pwrseq core will match it, however, it eats some memories
> >   if less power sequence instances are used. [Patch 2/8]
> > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. 
> > [Patch 2/8]
> > - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> >   use device_node for parameters at pwrseq_on. [Patch 2/8]
> > - Simplify the caller to use power sequence, follows Alan's commnets [Patch 
> > 4/8]
> > - Tested three pwrseq instances together using both specific compatible 
> > string and
> >   generic libraries.
> > 
> > Changes for v6:
> > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> > - Change chipidea core of_node assignment for coming user. (patch [5/6])
> > - Applies Joshua Clayton's three dts changes for two boards,
> >   the USB device's reg has only #address-cells, but without #size-cells.
> > 
> > Changes for v5:
> > - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> > - Fix the linker error when the pwrseq user is compiled as module
> > 
> > Changes for v4:
> > - Create the patch on next-20160722 
> > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> > - Using more friendly wait method for reset gpio [Patch 2/6]
> > - Support multiple input clocks [Patch 2/6]
> > - Add Rob Herring's ack for DT changes
> > - Add Joshua Clayton's Tested-by
> > 
> > Changes for v3:
> > - Delete "power-sequence" property at binding-doc, and change related code
> >   at both library and user code.
> > - Change binding-doc example node name with Rob's comments
> > - of_get_named_gpio_flags only gets the gpio, but without setting gpio 
> > flags,
> >   add additional code request gpio with proper gpio flags
> > - Add Philipp Zabel's Ack and MAINTAINER's entry
> > 
> > Changes for v2:
> > - Delete "pwrseq" prefix and clock-names for properties at dt binding
> > - Should use structure not but its pointer for kzalloc
> > - Since chipidea core has no of_node, let core's of_node equals glue
> >   layer's at core's probe
> > 
> > Joshua Clayton (2):
> >   ARM: dts: imx6qdl: Enable usb node children with 
> >   ARM: dts: imx6q-evi: Fix onboard hub reset line
> > 
> > Peter Chen (6):
> >   binding-doc: power: pwrseq-generic: add binding doc for generic power
> > sequence library
> >   power: add power sequence library
> >   binding-doc: usb: usb-device: add optional properties for power
> > sequence
> >   usb: core: add power sequence handling for USB devices
> >   usb: chipidea: let chipidea core device of_node equal's glue layer
> > device of_node
> >   ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
> > 
> >  .../bindings/power/pwrseq/pwrseq-generic.txt   |  48 ++
> >  .../devicetree/bindings/usb/usb-device.txt

Re: rockchip: drm: analogix_dp-rockchip would stock the kernel

[Randy Li]

On 10/17/2016 08:57 AM, Mark yao wrote:

On 2016年10月16日 02:03, ayaka wrote:

Hello:
   I meet a problem with eDP in rk3288 with the linux next 20161006,
it is just like the early stage of 4.4
kernel.  I have added a eDP panel entry in the firefly reload board,
once the kernel loaded analogix_dp-rockchip.ko, after printed the
following two lines, the kernel stop working.
rockchip-drm display-subsystem: bound ff94.vop (ops
vop_component_ops [rockchipdrm])
rockchip-drm display-subsystem: bound ff93.vop (ops
vop_component_ops [rockchipdrm])


Hi ayaka

This log seems no problem.
I found the problem, it is the eDP_AVDD_1V0 and eDP_AVDD_1V8 must have a 
proper power supply. I would submit a patch to enable the regulator at 
DP driver.


How about tested it with build-in? we had test it with build-in.

Maybe this patch can help you, you can have a try.
https://patchwork.kernel.org/patch/9374135

Thanks.


In the early June of the 4.4 kernel, I meet the same problem with
rk3288 evb board with different error message, I have to disable the
display system that time.
  In the today test, I meet the same problem with rk3399 evb board in
4.4.
  I have no idea what caused that, and it is a little hard to debug as
kernel still would never kill that task.
Randy Li








--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===

Re: rockchip: drm: analogix_dp-rockchip would stock the kernel

[Randy Li]

On 10/17/2016 08:57 AM, Mark yao wrote:

On 2016年10月16日 02:03, ayaka wrote:

Hello:
   I meet a problem with eDP in rk3288 with the linux next 20161006,
it is just like the early stage of 4.4
kernel.  I have added a eDP panel entry in the firefly reload board,
once the kernel loaded analogix_dp-rockchip.ko, after printed the
following two lines, the kernel stop working.
rockchip-drm display-subsystem: bound ff94.vop (ops
vop_component_ops [rockchipdrm])
rockchip-drm display-subsystem: bound ff93.vop (ops
vop_component_ops [rockchipdrm])


Hi ayaka

This log seems no problem.
I found the problem, it is the eDP_AVDD_1V0 and eDP_AVDD_1V8 must have a 
proper power supply. I would submit a patch to enable the regulator at 
DP driver.


How about tested it with build-in? we had test it with build-in.

Maybe this patch can help you, you can have a try.
https://patchwork.kernel.org/patch/9374135

Thanks.


In the early June of the 4.4 kernel, I meet the same problem with
rk3288 evb board with different error message, I have to disable the
display system that time.
  In the today test, I meet the same problem with rk3399 evb board in
4.4.
  I have no idea what caused that, and it is a little hard to debug as
kernel still would never kill that task.
Randy Li








--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===

Re: rockchip: drm: analogix_dp-rockchip would stock the kernel

[Mark yao]

On 2016年10月16日 02:03, ayaka wrote:

Hello:
   I meet a problem with eDP in rk3288 with the linux next 20161006, 
it is just like the early stage of 4.4
kernel.  I have added a eDP panel entry in the firefly reload board, 
once the kernel loaded analogix_dp-rockchip.ko, after printed the 
following two lines, the kernel stop working.
rockchip-drm display-subsystem: bound ff94.vop (ops 
vop_component_ops [rockchipdrm])
rockchip-drm display-subsystem: bound ff93.vop (ops 
vop_component_ops [rockchipdrm])


Hi ayaka

This log seems no problem.

How about tested it with build-in? we had test it with build-in.

Maybe this patch can help you, you can have a try.
https://patchwork.kernel.org/patch/9374135

Thanks.

In the early June of the 4.4 kernel, I meet the same problem with 
rk3288 evb board with different error message, I have to disable the 
display system that time.
  In the today test, I meet the same problem with rk3399 evb board in 
4.4.
  I have no idea what caused that, and it is a little hard to debug as 
kernel still would never kill that task.

Randy Li






--
Ｍark Yao

Re: rockchip: drm: analogix_dp-rockchip would stock the kernel

[Mark yao]

On 2016年10月16日 02:03, ayaka wrote:

Hello:
   I meet a problem with eDP in rk3288 with the linux next 20161006, 
it is just like the early stage of 4.4
kernel.  I have added a eDP panel entry in the firefly reload board, 
once the kernel loaded analogix_dp-rockchip.ko, after printed the 
following two lines, the kernel stop working.
rockchip-drm display-subsystem: bound ff94.vop (ops 
vop_component_ops [rockchipdrm])
rockchip-drm display-subsystem: bound ff93.vop (ops 
vop_component_ops [rockchipdrm])


Hi ayaka

This log seems no problem.

How about tested it with build-in? we had test it with build-in.

Maybe this patch can help you, you can have a try.
https://patchwork.kernel.org/patch/9374135

Thanks.

In the early June of the 4.4 kernel, I meet the same problem with 
rk3288 evb board with different error message, I have to disable the 
display system that time.
  In the today test, I meet the same problem with rk3399 evb board in 
4.4.
  I have no idea what caused that, and it is a little hard to debug as 
kernel still would never kill that task.

Randy Li






--
Ｍark Yao

Re: amazing people

[fistvani]

Hi! 


I just wanted to share some  interesting thoughts about amazing  people I met  
yesterday, please read more here 


Warm regards, fistvani

Re: amazing people

[fistvani]

Hi! 


I just wanted to share some  interesting thoughts about amazing  people I met  
yesterday, please read more here 


Warm regards, fistvani

Re: [patch] power: supply: lp8788: remove an unneeded NULL check

[Kim, Milo]

On 10/14/2016 4:33 PM, Dan Carpenter wrote:

We checked that "pdata->chg_params" is non-NULL earlier in this function
so when we add "i" to it, it's still non-NULL.

Signed-off-by: Dan Carpenter 


Acked-by: Milo Kim 

Thanks for catching this.

Best regards,
Milo

Re: [patch] power: supply: lp8788: remove an unneeded NULL check

[Kim, Milo]

On 10/14/2016 4:33 PM, Dan Carpenter wrote:

We checked that "pdata->chg_params" is non-NULL earlier in this function
so when we add "i" to it, it's still non-NULL.

Signed-off-by: Dan Carpenter 


Acked-by: Milo Kim 

Thanks for catching this.

Best regards,
Milo

Re: [PATCH v3 00/10] Start of skl watermark cleanup

[Lyude]

Pushed patches 1-4 in this series (with some very small style changes
to make checkpatch happy), drm-intel-nightly also rebuilt.

On Fri, 2016-10-14 at 17:31 -0400, Lyude wrote:
> While it (mostly) works, the code for handling watermarks on Skylake
> has been
> kind of ugly for a while. As well a lot of it isn't that friendly to
> atomic
> transactions, Lots of copy paste, redundant wm values, etc. While
> this isn't a
> full cleanup, it's a good start. As well, we add a couple of features
> for
> making debugging watermarks a little easier.
> 
> Rebased for latest nightly, new r-bs added + some changes
> 
> Lyude (10):
>   drm/i915/skl: Move per-pipe ddb allocations into crtc states
>   drm/i915/skl: Remove linetime from skl_wm_values
>   drm/i915/gen9: Make skl_wm_level per-plane
>   drm/i915/gen9: Cleanup skl_pipe_wm_active_state
>   drm/i915/gen9: Get rid of redundant watermark values
>   drm/i915/gen9: Add ddb changes to atomic debug output
>   drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable
>   drm/i915/gen9: Add skl_wm_level_equals()
>   drm/i915/gen9: Actually verify WM levels in verify_wm_state()
>   drm/i915/gen9: Don't wrap strings in verify_wm_state()
> 
>  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
>  drivers/gpu/drm/i915/intel_display.c | 138 ---
>  drivers/gpu/drm/i915/intel_drv.h |  24 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 466 +--
> 
>  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
>  5 files changed, 355 insertions(+), 291 deletions(-)
> 
-- 
Cheers,
Lyude

Re: [PATCH v3 00/10] Start of skl watermark cleanup

[Lyude]

Pushed patches 1-4 in this series (with some very small style changes
to make checkpatch happy), drm-intel-nightly also rebuilt.

On Fri, 2016-10-14 at 17:31 -0400, Lyude wrote:
> While it (mostly) works, the code for handling watermarks on Skylake
> has been
> kind of ugly for a while. As well a lot of it isn't that friendly to
> atomic
> transactions, Lots of copy paste, redundant wm values, etc. While
> this isn't a
> full cleanup, it's a good start. As well, we add a couple of features
> for
> making debugging watermarks a little easier.
> 
> Rebased for latest nightly, new r-bs added + some changes
> 
> Lyude (10):
>   drm/i915/skl: Move per-pipe ddb allocations into crtc states
>   drm/i915/skl: Remove linetime from skl_wm_values
>   drm/i915/gen9: Make skl_wm_level per-plane
>   drm/i915/gen9: Cleanup skl_pipe_wm_active_state
>   drm/i915/gen9: Get rid of redundant watermark values
>   drm/i915/gen9: Add ddb changes to atomic debug output
>   drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable
>   drm/i915/gen9: Add skl_wm_level_equals()
>   drm/i915/gen9: Actually verify WM levels in verify_wm_state()
>   drm/i915/gen9: Don't wrap strings in verify_wm_state()
> 
>  drivers/gpu/drm/i915/i915_drv.h  |  10 +-
>  drivers/gpu/drm/i915/intel_display.c | 138 ---
>  drivers/gpu/drm/i915/intel_drv.h |  24 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 466 +--
> 
>  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
>  5 files changed, 355 insertions(+), 291 deletions(-)
> 
-- 
Cheers,
Lyude

Re: [PATCH v2] mm: exclude isolated non-lru pages from NR_ISOLATED_ANON or NR_ISOLATED_FILE.

[Minchan Kim]

Hi Michal,

On Sat, Oct 15, 2016 at 09:10:45AM +0200, Michal Hocko wrote:
> On Sat 15-10-16 00:26:33, Minchan Kim wrote:
> > On Fri, Oct 14, 2016 at 05:03:55PM +0200, Michal Hocko wrote:
> [...]
> > > diff --git a/mm/compaction.c b/mm/compaction.c
> > > index 0409a4ad6ea1..6584705a46f6 100644
> > > --- a/mm/compaction.c
> > > +++ b/mm/compaction.c
> > > @@ -685,7 +685,8 @@ static bool too_many_isolated(struct zone *zone)
> > >   */
> > >  static unsigned long
> > >  isolate_migratepages_block(struct compact_control *cc, unsigned long 
> > > low_pfn,
> > > - unsigned long end_pfn, isolate_mode_t isolate_mode)
> > > + unsigned long end_pfn, isolate_mode_t isolate_mode,
> > > + unsigned long *isolated_file, unsigned long 
> > > *isolated_anon)
> > >  {
> > >   struct zone *zone = cc->zone;
> > >   unsigned long nr_scanned = 0, nr_isolated = 0;
> > > @@ -866,6 +867,10 @@ isolate_migratepages_block(struct compact_control 
> > > *cc, unsigned long low_pfn,
> > >  
> > >   /* Successfully isolated */
> > >   del_page_from_lru_list(page, lruvec, page_lru(page));
> > > + if (page_is_file_cache(page))
> > > + (*isolated_file)++;
> > > + else
> > > + (*isolated_anon)++;
> > >  
> > >  isolate_success:
> > >   list_add(>lru, >migratepages);
> > > 
> > > Makes more sense?
> > 
> > It is doable for isolation part. IOW, maybe we can make acct_isolated
> > simple with those counters but we need to handle migrate, putback part.
> > If you want to remove the check of __PageMoable with those counter, it
> > means we should pass the counter on every functions related migration
> > where isolate, migrate, putback parts.
> 
> OK, I see. Can we just get rid of acct_isolated altogether? Why cannot
> we simply update NR_ISOLATED_* while isolating pages? Just looking at
> isolate_migratepages_block:
>   acct_isolated(zone, cc);
>   putback_movable_pages(>migratepages);
> 
> suggests we are doing something suboptimal. I guess we cannot get rid of
> __PageMoveble checks which is sad because that just adds a lot of
> confusion because checking for !__PageMovable(page) for LRU pages is
> just a head scratcher (LRU pages are movable arent' they?). Maybe it
> would be even good to get rid of this misnomer. PageNonLRUMovable?

Yeah, I hated the naming but didn't have a good idea.
PageNonLRUMovable, definitely, one I thought as candidate but dropped
by lenghthy naming. If others don't object, I am happy to change it.

> 
> Anyway, I would suggest to do something like this. Batching NR_ISOLATED*
> just doesn't make all that much sense as these are per-cpu and the
> resulting code seems to be easier without it.

Agree. Could you resend it as formal patch?

> ---
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 0409a4ad6ea1..df1fd0c20e5c 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -634,22 +634,6 @@ isolate_freepages_range(struct compact_control *cc,
>   return pfn;
>  }
>  
> -/* Update the number of anon and file isolated pages in the zone */
> -static void acct_isolated(struct zone *zone, struct compact_control *cc)
> -{
> - struct page *page;
> - unsigned int count[2] = { 0, };
> -
> - if (list_empty(>migratepages))
> - return;
> -
> - list_for_each_entry(page, >migratepages, lru)
> - count[!!page_is_file_cache(page)]++;
> -
> - mod_node_page_state(zone->zone_pgdat, NR_ISOLATED_ANON, count[0]);
> - mod_node_page_state(zone->zone_pgdat, NR_ISOLATED_FILE, count[1]);
> -}
> -
>  /* Similar to reclaim, but different enough that they don't share logic */
>  static bool too_many_isolated(struct zone *zone)
>  {
> @@ -866,6 +850,8 @@ isolate_migratepages_block(struct compact_control *cc, 
> unsigned long low_pfn,
>  
>   /* Successfully isolated */
>   del_page_from_lru_list(page, lruvec, page_lru(page));
> + inc_node_page_state(zone->zone_pgdat,
> + NR_ISOLATED_ANON + page_is_file_cache(page));
>  
>  isolate_success:
>   list_add(>lru, >migratepages);
> @@ -902,7 +888,6 @@ isolate_migratepages_block(struct compact_control *cc, 
> unsigned long low_pfn,
>   spin_unlock_irqrestore(zone_lru_lock(zone), 
> flags);
>   locked = false;
>   }
> - acct_isolated(zone, cc);
>   putback_movable_pages(>migratepages);
>   cc->nr_migratepages = 0;
>   cc->last_migrated_pfn = 0;
> @@ -988,7 +973,6 @@ isolate_migratepages_range(struct compact_control *cc, 
> unsigned long start_pfn,
>   if (cc->nr_migratepages == COMPACT_CLUSTER_MAX)
>   break;
>   }
> - acct_isolated(cc->zone, cc);
>  
>   return pfn;
>  }
> @@ -1258,10 +1242,8 @@ static isolate_migrate_t 

Re: [PATCH v2] mm: exclude isolated non-lru pages from NR_ISOLATED_ANON or NR_ISOLATED_FILE.

[Minchan Kim]

Hi Michal,

On Sat, Oct 15, 2016 at 09:10:45AM +0200, Michal Hocko wrote:
> On Sat 15-10-16 00:26:33, Minchan Kim wrote:
> > On Fri, Oct 14, 2016 at 05:03:55PM +0200, Michal Hocko wrote:
> [...]
> > > diff --git a/mm/compaction.c b/mm/compaction.c
> > > index 0409a4ad6ea1..6584705a46f6 100644
> > > --- a/mm/compaction.c
> > > +++ b/mm/compaction.c
> > > @@ -685,7 +685,8 @@ static bool too_many_isolated(struct zone *zone)
> > >   */
> > >  static unsigned long
> > >  isolate_migratepages_block(struct compact_control *cc, unsigned long 
> > > low_pfn,
> > > - unsigned long end_pfn, isolate_mode_t isolate_mode)
> > > + unsigned long end_pfn, isolate_mode_t isolate_mode,
> > > + unsigned long *isolated_file, unsigned long 
> > > *isolated_anon)
> > >  {
> > >   struct zone *zone = cc->zone;
> > >   unsigned long nr_scanned = 0, nr_isolated = 0;
> > > @@ -866,6 +867,10 @@ isolate_migratepages_block(struct compact_control 
> > > *cc, unsigned long low_pfn,
> > >  
> > >   /* Successfully isolated */
> > >   del_page_from_lru_list(page, lruvec, page_lru(page));
> > > + if (page_is_file_cache(page))
> > > + (*isolated_file)++;
> > > + else
> > > + (*isolated_anon)++;
> > >  
> > >  isolate_success:
> > >   list_add(>lru, >migratepages);
> > > 
> > > Makes more sense?
> > 
> > It is doable for isolation part. IOW, maybe we can make acct_isolated
> > simple with those counters but we need to handle migrate, putback part.
> > If you want to remove the check of __PageMoable with those counter, it
> > means we should pass the counter on every functions related migration
> > where isolate, migrate, putback parts.
> 
> OK, I see. Can we just get rid of acct_isolated altogether? Why cannot
> we simply update NR_ISOLATED_* while isolating pages? Just looking at
> isolate_migratepages_block:
>   acct_isolated(zone, cc);
>   putback_movable_pages(>migratepages);
> 
> suggests we are doing something suboptimal. I guess we cannot get rid of
> __PageMoveble checks which is sad because that just adds a lot of
> confusion because checking for !__PageMovable(page) for LRU pages is
> just a head scratcher (LRU pages are movable arent' they?). Maybe it
> would be even good to get rid of this misnomer. PageNonLRUMovable?

Yeah, I hated the naming but didn't have a good idea.
PageNonLRUMovable, definitely, one I thought as candidate but dropped
by lenghthy naming. If others don't object, I am happy to change it.

> 
> Anyway, I would suggest to do something like this. Batching NR_ISOLATED*
> just doesn't make all that much sense as these are per-cpu and the
> resulting code seems to be easier without it.

Agree. Could you resend it as formal patch?

> ---
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 0409a4ad6ea1..df1fd0c20e5c 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -634,22 +634,6 @@ isolate_freepages_range(struct compact_control *cc,
>   return pfn;
>  }
>  
> -/* Update the number of anon and file isolated pages in the zone */
> -static void acct_isolated(struct zone *zone, struct compact_control *cc)
> -{
> - struct page *page;
> - unsigned int count[2] = { 0, };
> -
> - if (list_empty(>migratepages))
> - return;
> -
> - list_for_each_entry(page, >migratepages, lru)
> - count[!!page_is_file_cache(page)]++;
> -
> - mod_node_page_state(zone->zone_pgdat, NR_ISOLATED_ANON, count[0]);
> - mod_node_page_state(zone->zone_pgdat, NR_ISOLATED_FILE, count[1]);
> -}
> -
>  /* Similar to reclaim, but different enough that they don't share logic */
>  static bool too_many_isolated(struct zone *zone)
>  {
> @@ -866,6 +850,8 @@ isolate_migratepages_block(struct compact_control *cc, 
> unsigned long low_pfn,
>  
>   /* Successfully isolated */
>   del_page_from_lru_list(page, lruvec, page_lru(page));
> + inc_node_page_state(zone->zone_pgdat,
> + NR_ISOLATED_ANON + page_is_file_cache(page));
>  
>  isolate_success:
>   list_add(>lru, >migratepages);
> @@ -902,7 +888,6 @@ isolate_migratepages_block(struct compact_control *cc, 
> unsigned long low_pfn,
>   spin_unlock_irqrestore(zone_lru_lock(zone), 
> flags);
>   locked = false;
>   }
> - acct_isolated(zone, cc);
>   putback_movable_pages(>migratepages);
>   cc->nr_migratepages = 0;
>   cc->last_migrated_pfn = 0;
> @@ -988,7 +973,6 @@ isolate_migratepages_range(struct compact_control *cc, 
> unsigned long start_pfn,
>   if (cc->nr_migratepages == COMPACT_CLUSTER_MAX)
>   break;
>   }
> - acct_isolated(cc->zone, cc);
>  
>   return pfn;
>  }
> @@ -1258,10 +1242,8 @@ static isolate_migrate_t 

[PATCH] mac80211_hwsim: suggest nl80211 instead of wext driver in documentation

[Linus Lüssing]

For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the more
modern, netlink based driver instead of wext.

Signed-off-by: Linus Lüssing 
---

Actually, I wasn't even able to make a connection with the configuration
files and information provided in
Documentation/networking/mac80211_hwsim/{README,hostapd.conf/wpa_supplicant.conf}

Changing -Dwext to -Dnl80211 helped and made the WPA-PSK connection with
mac80211_hwsim interfaces work for me.
---
 Documentation/networking/mac80211_hwsim/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/networking/mac80211_hwsim/README 
b/Documentation/networking/mac80211_hwsim/README
index 24ac91d..3566a72 100644
--- a/Documentation/networking/mac80211_hwsim/README
+++ b/Documentation/networking/mac80211_hwsim/README
@@ -60,7 +60,7 @@ modprobe mac80211_hwsim
 hostapd hostapd.conf
 
 # Run wpa_supplicant (station) for wlan1
-wpa_supplicant -Dwext -iwlan1 -c wpa_supplicant.conf
+wpa_supplicant -Dnl80211 -iwlan1 -c wpa_supplicant.conf
 
 
 More test cases are available in hostap.git:
-- 
2.1.4

[PATCH] mac80211_hwsim: suggest nl80211 instead of wext driver in documentation

[Linus Lüssing]

For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the more
modern, netlink based driver instead of wext.

Signed-off-by: Linus Lüssing 
---

Actually, I wasn't even able to make a connection with the configuration
files and information provided in
Documentation/networking/mac80211_hwsim/{README,hostapd.conf/wpa_supplicant.conf}

Changing -Dwext to -Dnl80211 helped and made the WPA-PSK connection with
mac80211_hwsim interfaces work for me.
---
 Documentation/networking/mac80211_hwsim/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/networking/mac80211_hwsim/README 
b/Documentation/networking/mac80211_hwsim/README
index 24ac91d..3566a72 100644
--- a/Documentation/networking/mac80211_hwsim/README
+++ b/Documentation/networking/mac80211_hwsim/README
@@ -60,7 +60,7 @@ modprobe mac80211_hwsim
 hostapd hostapd.conf
 
 # Run wpa_supplicant (station) for wlan1
-wpa_supplicant -Dwext -iwlan1 -c wpa_supplicant.conf
+wpa_supplicant -Dnl80211 -iwlan1 -c wpa_supplicant.conf
 
 
 More test cases are available in hostap.git:
-- 
2.1.4

[PATCH] cxgb4: fix memory leak of qe on error exit path

[Colin King]

From: Colin Ian King 

A memory leak of qe occurs when t4_sched_queue_unbind fails,
so fix this by free'ing qe on the error exit path.

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/chelsio/cxgb4/sched.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c 
b/drivers/net/ethernet/chelsio/cxgb4/sched.c
index 539de76..cbd68a8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c
@@ -210,8 +210,10 @@ static int t4_sched_queue_bind(struct port_info *pi, 
struct ch_sched_queue *p)
 
/* Unbind queue from any existing class */
err = t4_sched_queue_unbind(pi, p);
-   if (err)
+   if (err) {
+   t4_free_mem(qe);
goto out;
+   }
 
/* Bind queue to specified class */
memset(qe, 0, sizeof(*qe));
-- 
2.9.3

[PATCH] cxgb4: fix memory leak of qe on error exit path

[Colin King]

From: Colin Ian King 

A memory leak of qe occurs when t4_sched_queue_unbind fails,
so fix this by free'ing qe on the error exit path.

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/chelsio/cxgb4/sched.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c 
b/drivers/net/ethernet/chelsio/cxgb4/sched.c
index 539de76..cbd68a8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c
@@ -210,8 +210,10 @@ static int t4_sched_queue_bind(struct port_info *pi, 
struct ch_sched_queue *p)
 
/* Unbind queue from any existing class */
err = t4_sched_queue_unbind(pi, p);
-   if (err)
+   if (err) {
+   t4_free_mem(qe);
goto out;
+   }
 
/* Bind queue to specified class */
memset(qe, 0, sizeof(*qe));
-- 
2.9.3

Re: [PATCH v3] mm: vmalloc: Replace purge_lock spinlock with atomic refcount

[Joel Fernandes]

Hi Christoph,

On Sun, Oct 16, 2016 at 3:06 PM, Joel Fernandes  wrote:
> On Sat, Oct 15, 2016 at 11:10 PM, Christoph Hellwig  
> wrote:
>> On Sat, Oct 15, 2016 at 03:59:34PM -0700, Joel Fernandes wrote:
>>> Also, could you share your concerns about use of atomic_t in my patch?
>>> I believe that since this is not a contented variable, the question of
>>> lock fairness is not a concern. It is also not a lock really the way
>>> I'm using it, it just keeps track of how many purges are in progress..
>>
>> atomic_t doesn't have any acquire/release semantics, and will require
>> off memory barrier dances to actually get the behavior you intended.
>> And from looking at the code I can't really see why we even would
>> want synchronization behavior - for the sort of problems where we
>> don't want multiple threads to run the same code at the same time
>> for effiency but not correctness reasons it's usually better to have
>> batch thresholds and/or splicing into local data structures before
>> operations.  Both are techniques used in this code, and I'd rather
>> rely on them and if required improve on them then using very odd
>> hoc synchronization methods.
>
> Thanks for the explanation. If you know of a better way to handle the sync=1
> case, let me know. In defense of atomics, even vmap_lazy_nr in the same code 
> is
> atomic_t :) I am also not using it as a lock really, but just to count how 
> many
> times something is in progress that's all - I added some more comments to my
> last patch to make this clearer in the code and now I'm also handling the case
> for sync=1.

Also, one more thing about the barrier dances you mentioned, this will
also be done by the spinlock which was there before my patch. So in
favor of my patch, it doesn't make things any worse than they were and
actually fixes the reported issue while preserving the original code
behavior. So I think it is a good thing to fix the issue considering
so many people are reporting it and any clean ups of the vmalloc code
itself can follow.

If you want I can looking into replacing the atomic_cmpxchg with an
atomic_inc and not do anything different for sync vs !sync except for
spinning when purges are pending. Would that make you feel a bit
better?

So instead of:
if (!sync && !force_flush) {
/*
 * Incase a purge is already in progress, just return.
 */
if (atomic_cmpxchg(, 0, 1))
return;
} else
atomic_inc();
,
Just do a:
atomic_inc();


This should be Ok to do since in the !sync case, we'll just return
anyway if another purge was in progress.

Thanks,

Joel

Re: [PATCH v3] mm: vmalloc: Replace purge_lock spinlock with atomic refcount

[Joel Fernandes]

Hi Christoph,

On Sun, Oct 16, 2016 at 3:06 PM, Joel Fernandes  wrote:
> On Sat, Oct 15, 2016 at 11:10 PM, Christoph Hellwig  
> wrote:
>> On Sat, Oct 15, 2016 at 03:59:34PM -0700, Joel Fernandes wrote:
>>> Also, could you share your concerns about use of atomic_t in my patch?
>>> I believe that since this is not a contented variable, the question of
>>> lock fairness is not a concern. It is also not a lock really the way
>>> I'm using it, it just keeps track of how many purges are in progress..
>>
>> atomic_t doesn't have any acquire/release semantics, and will require
>> off memory barrier dances to actually get the behavior you intended.
>> And from looking at the code I can't really see why we even would
>> want synchronization behavior - for the sort of problems where we
>> don't want multiple threads to run the same code at the same time
>> for effiency but not correctness reasons it's usually better to have
>> batch thresholds and/or splicing into local data structures before
>> operations.  Both are techniques used in this code, and I'd rather
>> rely on them and if required improve on them then using very odd
>> hoc synchronization methods.
>
> Thanks for the explanation. If you know of a better way to handle the sync=1
> case, let me know. In defense of atomics, even vmap_lazy_nr in the same code 
> is
> atomic_t :) I am also not using it as a lock really, but just to count how 
> many
> times something is in progress that's all - I added some more comments to my
> last patch to make this clearer in the code and now I'm also handling the case
> for sync=1.

Also, one more thing about the barrier dances you mentioned, this will
also be done by the spinlock which was there before my patch. So in
favor of my patch, it doesn't make things any worse than they were and
actually fixes the reported issue while preserving the original code
behavior. So I think it is a good thing to fix the issue considering
so many people are reporting it and any clean ups of the vmalloc code
itself can follow.

If you want I can looking into replacing the atomic_cmpxchg with an
atomic_inc and not do anything different for sync vs !sync except for
spinning when purges are pending. Would that make you feel a bit
better?

So instead of:
if (!sync && !force_flush) {
/*
 * Incase a purge is already in progress, just return.
 */
if (atomic_cmpxchg(, 0, 1))
return;
} else
atomic_inc();
,
Just do a:
atomic_inc();


This should be Ok to do since in the !sync case, we'll just return
anyway if another purge was in progress.

Thanks,

Joel

Re: [tip:x86/urgent] x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

[Borislav Petkov]

On Sun, Oct 16, 2016 at 11:42:26AM -0700, h...@zytor.com wrote:
> It's needlessly adding complexity for no reason, at least for the

What complexity? The init_scattered_cpuid_features() version is a
trivial patch in comparison to the current version.

> leaves that are going to add bits over time.

Sure, except they don't get added or we don't need them or whatever, and
we end up with only a small number of bits actually being used.

I don't mind moving them to x86_capability later, when a high percentage
of the respective leaf is actually being used but not for a couple of
bits. That's just waste.

> The x86_capability array is not an expensive resource.

0.1% here, 0.1% there, the creeping bloat thing.

And again, the init_scattered_cpuid_features() hunk is much smaller.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

Re: [tip:x86/urgent] x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

[Borislav Petkov]

On Sun, Oct 16, 2016 at 11:42:26AM -0700, h...@zytor.com wrote:
> It's needlessly adding complexity for no reason, at least for the

What complexity? The init_scattered_cpuid_features() version is a
trivial patch in comparison to the current version.

> leaves that are going to add bits over time.

Sure, except they don't get added or we don't need them or whatever, and
we end up with only a small number of bits actually being used.

I don't mind moving them to x86_capability later, when a high percentage
of the respective leaf is actually being used but not for a couple of
bits. That's just waste.

> The x86_capability array is not an expensive resource.

0.1% here, 0.1% there, the creeping bloat thing.

And again, the init_scattered_cpuid_features() hunk is much smaller.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH v3] mm: vmalloc: Replace purge_lock spinlock with atomic refcount

[Joel Fernandes]

On Sat, Oct 15, 2016 at 11:10 PM, Christoph Hellwig  wrote:
> On Sat, Oct 15, 2016 at 03:59:34PM -0700, Joel Fernandes wrote:
>> Your patch changes the behavior of the original code I think.
>
> It does.  And it does so as I don't think the existing behavior makes
> sense, as mentioned in the changelog.
>
>> With the
>> patch, for the case where you have 2 concurrent tasks executing
>> alloc_vmap_area function, say both hit the overflow label and enter
>> the __purge_vmap_area_lazy at the same time. The first task empties
>> the purge list and sets nr to the total number of pages of all the
>> vmap areas in the list. Say the first task has just emptied the list
>> but hasn't started freeing the vmap areas and is preempted at this
>> point. Now the second task runs and since the purge list is empty, the
>> second task doesn't have anything to do and immediately returns to
>> alloc_vmap_area. Once it returns, it sets purged to 1 in
>> alloc_vmap_area and retries. Say it hits overflow label again in the
>> retry path. Now because purged was set to 1, it goes to err_free.
>> Without your patch, it would have waited on the spin_lock (sync = 1)
>> instead of just erroring out, so your patch does change the behavior
>> of the original code by not using the purge_lock. I realize my patch
>> also changes the behavior, but in mine I think we can make it behave
>> like the original code by spinning until purging=0 (if sync = 1)
>> because I still have the purging variable..
>
> But for sync = 1 you don't spin on it in any way.  This is the logic
> in your patch:
>
> if (!sync && !force_flush) {
> if (atomic_cmpxchg(, 0, 1))
> return;
> } else
> atomic_inc();

I agree my patch doesn't spin too, I mentioned this above: "I realize my patch
also changes the behavior". However if you dont have too much of a problem with
my use of atomics, then my below new patch handles the case for sync=1 and is
identical in behavior to the original code while still fixing the preempt off
latency issues.

Your patch just got rid of sync completely, I'm not sure if that's Ok to do?
the alloc_vmap_area overflow case was assuming sync=1. The original
alloc_vmap_area code calls purge with sync=1 and waits for pending purges to
complete, instead of erroring out. I wanted to preserve this behavior.

>> Also, could you share your concerns about use of atomic_t in my patch?
>> I believe that since this is not a contented variable, the question of
>> lock fairness is not a concern. It is also not a lock really the way
>> I'm using it, it just keeps track of how many purges are in progress..
>
> atomic_t doesn't have any acquire/release semantics, and will require
> off memory barrier dances to actually get the behavior you intended.
> And from looking at the code I can't really see why we even would
> want synchronization behavior - for the sort of problems where we
> don't want multiple threads to run the same code at the same time
> for effiency but not correctness reasons it's usually better to have
> batch thresholds and/or splicing into local data structures before
> operations.  Both are techniques used in this code, and I'd rather
> rely on them and if required improve on them then using very odd
> hoc synchronization methods.

Thanks for the explanation. If you know of a better way to handle the sync=1
case, let me know. In defense of atomics, even vmap_lazy_nr in the same code is
atomic_t :) I am also not using it as a lock really, but just to count how many
times something is in progress that's all - I added some more comments to my
last patch to make this clearer in the code and now I'm also handling the case
for sync=1.

-8<
From: Joel Fernandes 
Date: Sat, 15 Oct 2016 01:04:14 -0700
Subject: [PATCH v4] mm: vmalloc: Replace purge_lock spinlock with atomic 
refcount

The purge_lock spinlock causes high latencies with non RT kernel. This has been
reported multiple times on lkml [1] [2] and affects applications like audio.

In this patch, I replace the spinlock with an atomic refcount so that
preemption is kept turned on during purge. This Ok to do since [3] builds the
lazy free list in advance and atomically retrieves the list so any instance of
purge will have its own list it is purging. Since the individual vmap area
frees are themselves protected by a lock, this is Ok.

The only thing left is the fact that previously it had trylock behavior, so
preserve that by using the refcount to keep track of in-progress purges and
abort like previously if there is an ongoing purge. Lastly, decrement
vmap_lazy_nr as the vmap areas are freed, and not in advance, so that the
vmap_lazy_nr is not reduced too soon as suggested in [2].

Tests:
x86_64 quad core machine on kernel 4.8, run: cyclictest -p 99 -n
Concurrently in a kernel module, run vmalloc and vfree 8K buffer in a loop.
Preemption configuration: 

Re: [PATCH v3] mm: vmalloc: Replace purge_lock spinlock with atomic refcount

[Joel Fernandes]

On Sat, Oct 15, 2016 at 11:10 PM, Christoph Hellwig  wrote:
> On Sat, Oct 15, 2016 at 03:59:34PM -0700, Joel Fernandes wrote:
>> Your patch changes the behavior of the original code I think.
>
> It does.  And it does so as I don't think the existing behavior makes
> sense, as mentioned in the changelog.
>
>> With the
>> patch, for the case where you have 2 concurrent tasks executing
>> alloc_vmap_area function, say both hit the overflow label and enter
>> the __purge_vmap_area_lazy at the same time. The first task empties
>> the purge list and sets nr to the total number of pages of all the
>> vmap areas in the list. Say the first task has just emptied the list
>> but hasn't started freeing the vmap areas and is preempted at this
>> point. Now the second task runs and since the purge list is empty, the
>> second task doesn't have anything to do and immediately returns to
>> alloc_vmap_area. Once it returns, it sets purged to 1 in
>> alloc_vmap_area and retries. Say it hits overflow label again in the
>> retry path. Now because purged was set to 1, it goes to err_free.
>> Without your patch, it would have waited on the spin_lock (sync = 1)
>> instead of just erroring out, so your patch does change the behavior
>> of the original code by not using the purge_lock. I realize my patch
>> also changes the behavior, but in mine I think we can make it behave
>> like the original code by spinning until purging=0 (if sync = 1)
>> because I still have the purging variable..
>
> But for sync = 1 you don't spin on it in any way.  This is the logic
> in your patch:
>
> if (!sync && !force_flush) {
> if (atomic_cmpxchg(, 0, 1))
> return;
> } else
> atomic_inc();

I agree my patch doesn't spin too, I mentioned this above: "I realize my patch
also changes the behavior". However if you dont have too much of a problem with
my use of atomics, then my below new patch handles the case for sync=1 and is
identical in behavior to the original code while still fixing the preempt off
latency issues.

Your patch just got rid of sync completely, I'm not sure if that's Ok to do?
the alloc_vmap_area overflow case was assuming sync=1. The original
alloc_vmap_area code calls purge with sync=1 and waits for pending purges to
complete, instead of erroring out. I wanted to preserve this behavior.

>> Also, could you share your concerns about use of atomic_t in my patch?
>> I believe that since this is not a contented variable, the question of
>> lock fairness is not a concern. It is also not a lock really the way
>> I'm using it, it just keeps track of how many purges are in progress..
>
> atomic_t doesn't have any acquire/release semantics, and will require
> off memory barrier dances to actually get the behavior you intended.
> And from looking at the code I can't really see why we even would
> want synchronization behavior - for the sort of problems where we
> don't want multiple threads to run the same code at the same time
> for effiency but not correctness reasons it's usually better to have
> batch thresholds and/or splicing into local data structures before
> operations.  Both are techniques used in this code, and I'd rather
> rely on them and if required improve on them then using very odd
> hoc synchronization methods.

Thanks for the explanation. If you know of a better way to handle the sync=1
case, let me know. In defense of atomics, even vmap_lazy_nr in the same code is
atomic_t :) I am also not using it as a lock really, but just to count how many
times something is in progress that's all - I added some more comments to my
last patch to make this clearer in the code and now I'm also handling the case
for sync=1.

-8<
From: Joel Fernandes 
Date: Sat, 15 Oct 2016 01:04:14 -0700
Subject: [PATCH v4] mm: vmalloc: Replace purge_lock spinlock with atomic 
refcount

The purge_lock spinlock causes high latencies with non RT kernel. This has been
reported multiple times on lkml [1] [2] and affects applications like audio.

In this patch, I replace the spinlock with an atomic refcount so that
preemption is kept turned on during purge. This Ok to do since [3] builds the
lazy free list in advance and atomically retrieves the list so any instance of
purge will have its own list it is purging. Since the individual vmap area
frees are themselves protected by a lock, this is Ok.

The only thing left is the fact that previously it had trylock behavior, so
preserve that by using the refcount to keep track of in-progress purges and
abort like previously if there is an ongoing purge. Lastly, decrement
vmap_lazy_nr as the vmap areas are freed, and not in advance, so that the
vmap_lazy_nr is not reduced too soon as suggested in [2].

Tests:
x86_64 quad core machine on kernel 4.8, run: cyclictest -p 99 -n
Concurrently in a kernel module, run vmalloc and vfree 8K buffer in a loop.
Preemption configuration: CONFIG_PREEMPT__LL=y (low-latency desktop)

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

[Dave Chinner]

On Thu, Oct 13, 2016 at 01:04:56PM +0200, Michal Hocko wrote:
> On Thu 13-10-16 09:39:47, Michal Hocko wrote:
> > On Thu 13-10-16 11:29:24, Dave Chinner wrote:
> > > On Fri, Oct 07, 2016 at 03:18:14PM +0200, Michal Hocko wrote:
> > [...]
> > > > Unpatched kernel:
> > > > #   Version 3.3, 16 thread(s) starting at Fri Oct  7 09:55:05 2016
> > > > #   Sync method: NO SYNC: Test does not issue sync() or fsync() 
> > > > calls.
> > > > #   Directories:  Time based hash between directories across 1 
> > > > subdirectories with 180 seconds per subdirectory.
> > > > #   File names: 40 bytes long, (16 initial bytes of time stamp with 
> > > > 24 random bytes at end of name)
> > > > #   Files info: size 0 bytes, written with an IO size of 16384 
> > > > bytes per write
> > > > #   App overhead is time in microseconds spent in the test not 
> > > > doing file writing related system calls.
> > > > #
> > > > FSUse%Count SizeFiles/sec App Overhead
> > > >  1  1600   4300.1 20745838
> > > >  3  3200   4239.9 23849857
> > > >  5  4800   4243.4 25939543
> > > >  6  6400   4248.4 19514050
> > > >  8  8000   4262.1 20796169
> > > >  9  9600   4257.6 21288675
> > > > 11 11200   4259.7 19375120
> > > > 13 12800   4220.7 22734141
> > > > 14 14400   4238.5 31936458
> > > > 16 16000   4231.5 23409901
> > > > 18 17600   4045.3 23577700
> > > > 19 19200   2783.4 58299526
> > > > 21 20800   2678.2 40616302
> > > > 23 22400   2693.5 83973996
> > > > Ctrl+C because it just took too long.
> > > 
> > > Try running it on a larger filesystem, or configure the fs with more
> > > AGs and a larger log (i.e. mkfs.xfs -f -dagcount=24 -l size=512m
> > > ). That will speed up modifications and increase concurrency.
> > > This test should be able to run 5-10x faster than this (it
> > > sustains 55,000 files/s @ 300MB/s write on my test fs on a cheap
> > > SSD).
> > 
> > Will add more memory to the machine. Will report back on that.
> 
> increasing the memory to 1G didn't help. So I've tried to add
> -dagcount=24 -l size=512m and that didn't help much either. I am at 5k
> files/s so nowhere close to your 55k. I thought this is more about CPUs
> count than about the amount of memory. So I've tried a larger machine
> with 24 CPUs (no dagcount etc...), this one doesn't have a fast storage
> so I've backed the fs image by ramdisk but even then I am getting very
> similar results. No idea what is wrong with my kvm setup.

What's the backing storage? I use an image file in an XFS
filesystem, configured with virtio,cache=none so it's concurrency
model matches that of a real disk...

Cheers,

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

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

[Dave Chinner]

On Thu, Oct 13, 2016 at 01:04:56PM +0200, Michal Hocko wrote:
> On Thu 13-10-16 09:39:47, Michal Hocko wrote:
> > On Thu 13-10-16 11:29:24, Dave Chinner wrote:
> > > On Fri, Oct 07, 2016 at 03:18:14PM +0200, Michal Hocko wrote:
> > [...]
> > > > Unpatched kernel:
> > > > #   Version 3.3, 16 thread(s) starting at Fri Oct  7 09:55:05 2016
> > > > #   Sync method: NO SYNC: Test does not issue sync() or fsync() 
> > > > calls.
> > > > #   Directories:  Time based hash between directories across 1 
> > > > subdirectories with 180 seconds per subdirectory.
> > > > #   File names: 40 bytes long, (16 initial bytes of time stamp with 
> > > > 24 random bytes at end of name)
> > > > #   Files info: size 0 bytes, written with an IO size of 16384 
> > > > bytes per write
> > > > #   App overhead is time in microseconds spent in the test not 
> > > > doing file writing related system calls.
> > > > #
> > > > FSUse%Count SizeFiles/sec App Overhead
> > > >  1  1600   4300.1 20745838
> > > >  3  3200   4239.9 23849857
> > > >  5  4800   4243.4 25939543
> > > >  6  6400   4248.4 19514050
> > > >  8  8000   4262.1 20796169
> > > >  9  9600   4257.6 21288675
> > > > 11 11200   4259.7 19375120
> > > > 13 12800   4220.7 22734141
> > > > 14 14400   4238.5 31936458
> > > > 16 16000   4231.5 23409901
> > > > 18 17600   4045.3 23577700
> > > > 19 19200   2783.4 58299526
> > > > 21 20800   2678.2 40616302
> > > > 23 22400   2693.5 83973996
> > > > Ctrl+C because it just took too long.
> > > 
> > > Try running it on a larger filesystem, or configure the fs with more
> > > AGs and a larger log (i.e. mkfs.xfs -f -dagcount=24 -l size=512m
> > > ). That will speed up modifications and increase concurrency.
> > > This test should be able to run 5-10x faster than this (it
> > > sustains 55,000 files/s @ 300MB/s write on my test fs on a cheap
> > > SSD).
> > 
> > Will add more memory to the machine. Will report back on that.
> 
> increasing the memory to 1G didn't help. So I've tried to add
> -dagcount=24 -l size=512m and that didn't help much either. I am at 5k
> files/s so nowhere close to your 55k. I thought this is more about CPUs
> count than about the amount of memory. So I've tried a larger machine
> with 24 CPUs (no dagcount etc...), this one doesn't have a fast storage
> so I've backed the fs image by ramdisk but even then I am getting very
> similar results. No idea what is wrong with my kvm setup.

What's the backing storage? I use an image file in an XFS
filesystem, configured with virtio,cache=none so it's concurrency
model matches that of a real disk...

Cheers,

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

[PATCH 6/8] tools lib bpf: improve warning

[Eric Leblond]

Signed-off-by: Eric Leblond 
---
 tools/lib/bpf/libbpf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 7cd341e..1fe4532 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -802,7 +802,8 @@ bpf_object__create_maps(struct bpf_object *obj)
size_t j;
int err = *pfd;
 
-   pr_warning("failed to create map: %s\n",
+   pr_warning("failed to create map (name: '%s'): %s\n",
+  obj->maps[i].name,
   strerror(errno));
for (j = 0; j < i; j++)
zclose(obj->maps[j].fd);
-- 
2.9.3

[PATCH 4/8] tools lib bpf: export function to set type

[Eric Leblond]

Current API was not allowing the user to set a type like socket
filter. To avoid a setter function for each type, the patch simply
exports a set function that takes the type in parameter.

Signed-off-by: Eric Leblond 
---
 tools/lib/bpf/libbpf.c | 19 +--
 tools/lib/bpf/libbpf.h |  3 +++
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 90932f1..7cd341e 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1336,26 +1336,25 @@ int bpf_program__nth_fd(struct bpf_program *prog, int n)
return fd;
 }
 
-static void bpf_program__set_type(struct bpf_program *prog,
- enum bpf_prog_type type)
+int bpf_program__set_type(struct bpf_program *prog, unsigned int type)
 {
+   if (!prog)
+   return -EINVAL;
+   if (type >= __MAX_BPF_PROG_TYPE)
+   return -EINVAL;
+
prog->type = type;
+   return 0;
 }
 
 int bpf_program__set_tracepoint(struct bpf_program *prog)
 {
-   if (!prog)
-   return -EINVAL;
-   bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
-   return 0;
+   return bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
 }
 
 int bpf_program__set_kprobe(struct bpf_program *prog)
 {
-   if (!prog)
-   return -EINVAL;
-   bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
-   return 0;
+   return bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
 }
 
 static bool bpf_program__is_type(struct bpf_program *prog,
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index e40c8d3..a18783b 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -173,6 +173,9 @@ int bpf_program__set_kprobe(struct bpf_program *prog);
 bool bpf_program__is_tracepoint(struct bpf_program *prog);
 bool bpf_program__is_kprobe(struct bpf_program *prog);
 
+int bpf_program__set_type(struct bpf_program *prog,
+ unsigned int type);
+
 /*
  * We don't need __attribute__((packed)) now since it is
  * unnecessary for 'bpf_map_def' because they are all aligned.
-- 
2.9.3

[PATCH 6/8] tools lib bpf: improve warning

[Eric Leblond]

Signed-off-by: Eric Leblond 
---
 tools/lib/bpf/libbpf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 7cd341e..1fe4532 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -802,7 +802,8 @@ bpf_object__create_maps(struct bpf_object *obj)
size_t j;
int err = *pfd;
 
-   pr_warning("failed to create map: %s\n",
+   pr_warning("failed to create map (name: '%s'): %s\n",
+  obj->maps[i].name,
   strerror(errno));
for (j = 0; j < i; j++)
zclose(obj->maps[j].fd);
-- 
2.9.3

[PATCH 4/8] tools lib bpf: export function to set type

[Eric Leblond]

Current API was not allowing the user to set a type like socket
filter. To avoid a setter function for each type, the patch simply
exports a set function that takes the type in parameter.

Signed-off-by: Eric Leblond 
---
 tools/lib/bpf/libbpf.c | 19 +--
 tools/lib/bpf/libbpf.h |  3 +++
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 90932f1..7cd341e 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1336,26 +1336,25 @@ int bpf_program__nth_fd(struct bpf_program *prog, int n)
return fd;
 }
 
-static void bpf_program__set_type(struct bpf_program *prog,
- enum bpf_prog_type type)
+int bpf_program__set_type(struct bpf_program *prog, unsigned int type)
 {
+   if (!prog)
+   return -EINVAL;
+   if (type >= __MAX_BPF_PROG_TYPE)
+   return -EINVAL;
+
prog->type = type;
+   return 0;
 }
 
 int bpf_program__set_tracepoint(struct bpf_program *prog)
 {
-   if (!prog)
-   return -EINVAL;
-   bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
-   return 0;
+   return bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
 }
 
 int bpf_program__set_kprobe(struct bpf_program *prog)
 {
-   if (!prog)
-   return -EINVAL;
-   bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
-   return 0;
+   return bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
 }
 
 static bool bpf_program__is_type(struct bpf_program *prog,
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index e40c8d3..a18783b 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -173,6 +173,9 @@ int bpf_program__set_kprobe(struct bpf_program *prog);
 bool bpf_program__is_tracepoint(struct bpf_program *prog);
 bool bpf_program__is_kprobe(struct bpf_program *prog);
 
+int bpf_program__set_type(struct bpf_program *prog,
+ unsigned int type);
+
 /*
  * We don't need __attribute__((packed)) now since it is
  * unnecessary for 'bpf_map_def' because they are all aligned.
-- 
2.9.3

[PATCH 1/8] tools lib bpf: add error functions

[Eric Leblond]

The include of err.h is not explicitely needed in exported
functions and it was causing include conflict with some existing
code due to redefining some macros.

To fix this, let's have error handling functions provided by the
library. Furthermore this will allow user to have an homogeneous
API.

Signed-off-by: Eric Leblond 
---
 tools/lib/bpf/libbpf.c | 11 +++
 tools/lib/bpf/libbpf.h |  4 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index b699aea..90932f1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1447,3 +1448,13 @@ bpf_object__find_map_by_name(struct bpf_object *obj, 
const char *name)
}
return NULL;
 }
+
+bool bpf__is_error(const void *ptr)
+{
+   return IS_ERR(ptr);
+}
+
+long bpf__get_error(const void *ptr)
+{
+   return PTR_ERR(ptr);
+}
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index dd7a513..e40c8d3 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -23,7 +23,6 @@
 
 #include 
 #include 
-#include 
 
 enum libbpf_errno {
__LIBBPF_ERRNO__START = 4000,
@@ -211,4 +210,7 @@ int bpf_map__set_priv(struct bpf_map *map, void *priv,
  bpf_map_clear_priv_t clear_priv);
 void *bpf_map__priv(struct bpf_map *map);
 
+bool bpf__is_error(const void *ptr);
+long bpf__get_error(const void *ptr);
+
 #endif
-- 
2.9.3

[PATCH 0/8] tools lib bpf: fixes and functional upgrade

[Eric Leblond]

Hello,

Here's a patchset on the libbpf library that can be found in
tools/lib/bpf.

Patch 0 to patch 4 add a new function to be able to set the BPF
program type. Till then program type such as network filter can't
be loaded by the library:

* tools lib bpf: add error functions
* uapi linux bpf: add max value to enum
* tools: Sync tools/include/uapi/linux/bpf.h with the
* tools lib bpf: export function to set type

Patch 5 is adding functions that were missing to handle maps in
userspace.

* tools lib bpf: add missing functions

Patch 7 fixes a bug in the parsing of BPF ELF file.

* tools lib bpf: fix maps resolution

Patch 8 update 'make install' to install the header on the system.

* tools lib bpf: install header file


Patchset statistics:
 include/uapi/linux/bpf.h   |  1 +
 tools/include/uapi/linux/bpf.h | 56 
++--
 tools/lib/bpf/Makefile | 11 +--
 tools/lib/bpf/bpf.c| 35 ++-
 tools/lib/bpf/bpf.h|  2 --
 tools/lib/bpf/libbpf.c | 83 
+--
 tools/lib/bpf/libbpf.h | 12 +++-
 7 files changed, 166 insertions(+), 34 deletions(-)

Best regards,
--
Eric Leblond

[PATCH 0/8] tools lib bpf: fixes and functional upgrade

[Eric Leblond]

Hello,

Here's a patchset on the libbpf library that can be found in
tools/lib/bpf.

Patch 0 to patch 4 add a new function to be able to set the BPF
program type. Till then program type such as network filter can't
be loaded by the library:

* tools lib bpf: add error functions
* uapi linux bpf: add max value to enum
* tools: Sync tools/include/uapi/linux/bpf.h with the
* tools lib bpf: export function to set type

Patch 5 is adding functions that were missing to handle maps in
userspace.

* tools lib bpf: add missing functions

Patch 7 fixes a bug in the parsing of BPF ELF file.

* tools lib bpf: fix maps resolution

Patch 8 update 'make install' to install the header on the system.

* tools lib bpf: install header file


Patchset statistics:
 include/uapi/linux/bpf.h   |  1 +
 tools/include/uapi/linux/bpf.h | 56 
++--
 tools/lib/bpf/Makefile | 11 +--
 tools/lib/bpf/bpf.c| 35 ++-
 tools/lib/bpf/bpf.h|  2 --
 tools/lib/bpf/libbpf.c | 83 
+--
 tools/lib/bpf/libbpf.h | 12 +++-
 7 files changed, 166 insertions(+), 34 deletions(-)

Best regards,
--
Eric Leblond

[PATCH 1/8] tools lib bpf: add error functions

[Eric Leblond]

The include of err.h is not explicitely needed in exported
functions and it was causing include conflict with some existing
code due to redefining some macros.

To fix this, let's have error handling functions provided by the
library. Furthermore this will allow user to have an homogeneous
API.

Signed-off-by: Eric Leblond 
---
 tools/lib/bpf/libbpf.c | 11 +++
 tools/lib/bpf/libbpf.h |  4 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index b699aea..90932f1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1447,3 +1448,13 @@ bpf_object__find_map_by_name(struct bpf_object *obj, 
const char *name)
}
return NULL;
 }
+
+bool bpf__is_error(const void *ptr)
+{
+   return IS_ERR(ptr);
+}
+
+long bpf__get_error(const void *ptr)
+{
+   return PTR_ERR(ptr);
+}
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index dd7a513..e40c8d3 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -23,7 +23,6 @@
 
 #include 
 #include 
-#include 
 
 enum libbpf_errno {
__LIBBPF_ERRNO__START = 4000,
@@ -211,4 +210,7 @@ int bpf_map__set_priv(struct bpf_map *map, void *priv,
  bpf_map_clear_priv_t clear_priv);
 void *bpf_map__priv(struct bpf_map *map);
 
+bool bpf__is_error(const void *ptr);
+long bpf__get_error(const void *ptr);
+
 #endif
-- 
2.9.3

[PATCH 3/8] tools: Sync tools/include/uapi/linux/bpf.h with the kernel

[Eric Leblond]

Signed-off-by: Eric Leblond 
---
 tools/include/uapi/linux/bpf.h | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9e5fc16..570287f 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -95,6 +95,8 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SCHED_ACT,
BPF_PROG_TYPE_TRACEPOINT,
BPF_PROG_TYPE_XDP,
+   BPF_PROG_TYPE_PERF_EVENT,
+   __MAX_BPF_PROG_TYPE,
 };
 
 #define BPF_PSEUDO_MAP_FD  1
@@ -375,6 +377,56 @@ enum bpf_func_id {
 */
BPF_FUNC_probe_write_user,
 
+   /**
+* bpf_current_task_under_cgroup(map, index) - Check cgroup2 membership 
of current task
+* @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
+* @index: index of the cgroup in the bpf_map
+* Return:
+*   == 0 current failed the cgroup2 descendant test
+*   == 1 current succeeded the cgroup2 descendant test
+*< 0 error
+*/
+   BPF_FUNC_current_task_under_cgroup,
+
+   /**
+* bpf_skb_change_tail(skb, len, flags)
+* The helper will resize the skb to the given new size,
+* to be used f.e. with control messages.
+* @skb: pointer to skb
+* @len: new skb length
+* @flags: reserved
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_tail,
+
+   /**
+* bpf_skb_pull_data(skb, len)
+* The helper will pull in non-linear data in case the
+* skb is non-linear and not all of len are part of the
+* linear section. Only needed for read/write with direct
+* packet access.
+* @skb: pointer to skb
+* @len: len to make read/writeable
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_pull_data,
+
+   /**
+* bpf_csum_update(skb, csum)
+* Adds csum into skb->csum in case of CHECKSUM_COMPLETE.
+* @skb: pointer to skb
+* @csum: csum to add
+* Return: csum on success or negative error
+*/
+   BPF_FUNC_csum_update,
+
+   /**
+* bpf_set_hash_invalid(skb)
+* Invalidate current skb>hash.
+* @skb: pointer to skb
+*/
+   BPF_FUNC_set_hash_invalid,
+
__BPF_FUNC_MAX_ID,
 };
 
-- 
2.9.3

[PATCH 7/8] tools lib bpf: fix maps resolution

[Eric Leblond]

It is not correct to assimilate the elf data of the maps section
to an array of map definition. In fact the sizes differ. The
offset provided in the symbol section has to be used instead.

This patch fixes a bug causing a elf with two maps not to load
correctly.

Signed-off-by: Eric Leblond 
---
 tools/lib/bpf/libbpf.c | 50 +++---
 1 file changed, 35 insertions(+), 15 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 1fe4532..f72628b 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -186,6 +186,7 @@ struct bpf_program {
 struct bpf_map {
int fd;
char *name;
+   size_t offset;
struct bpf_map_def def;
void *priv;
bpf_map_clear_priv_t clear_priv;
@@ -529,13 +530,6 @@ bpf_object__init_maps(struct bpf_object *obj, void *data,
 
pr_debug("maps in %s: %zd bytes\n", obj->path, size);
 
-   obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
-   if (!obj->maps) {
-   pr_warning("alloc maps for object failed\n");
-   return -ENOMEM;
-   }
-   obj->nr_maps = nr_maps;
-
for (i = 0; i < nr_maps; i++) {
struct bpf_map_def *def = >maps[i].def;
 
@@ -547,23 +541,42 @@ bpf_object__init_maps(struct bpf_object *obj, void *data,
obj->maps[i].fd = -1;
 
/* Save map definition into obj->maps */
-   *def = ((struct bpf_map_def *)data)[i];
+   *def = *(struct bpf_map_def *)(data + obj->maps[i].offset);
}
return 0;
 }
 
 static int
-bpf_object__init_maps_name(struct bpf_object *obj)
+bpf_object__init_maps_symbol(struct bpf_object *obj)
 {
int i;
+   int nr_maps = 0;
Elf_Data *symbols = obj->efile.symbols;
+   size_t map_idx = 0;
 
if (!symbols || obj->efile.maps_shndx < 0)
return -EINVAL;
 
+   /* get the number of maps */
+   for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
+   GElf_Sym sym;
+
+   if (!gelf_getsym(symbols, i, ))
+   continue;
+   if (sym.st_shndx != obj->efile.maps_shndx)
+   continue;
+   nr_maps++;
+   }
+
+   obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
+   if (!obj->maps) {
+   pr_warning("alloc maps for object failed\n");
+   return -ENOMEM;
+   }
+   obj->nr_maps = nr_maps;
+
for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
GElf_Sym sym;
-   size_t map_idx;
const char *map_name;
 
if (!gelf_getsym(symbols, i, ))
@@ -574,12 +587,12 @@ bpf_object__init_maps_name(struct bpf_object *obj)
map_name = elf_strptr(obj->efile.elf,
  obj->efile.strtabidx,
  sym.st_name);
-   map_idx = sym.st_value / sizeof(struct bpf_map_def);
if (map_idx >= obj->nr_maps) {
pr_warning("index of map \"%s\" is buggy: %zu > %zu\n",
   map_name, map_idx, obj->nr_maps);
continue;
}
+   obj->maps[map_idx].offset = sym.st_value;
obj->maps[map_idx].name = strdup(map_name);
if (!obj->maps[map_idx].name) {
pr_warning("failed to alloc map name\n");
@@ -587,6 +600,7 @@ bpf_object__init_maps_name(struct bpf_object *obj)
}
pr_debug("map %zu is \"%s\"\n", map_idx,
 obj->maps[map_idx].name);
+   map_idx++;
}
return 0;
 }
@@ -647,8 +661,6 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
data->d_buf,
data->d_size);
else if (strcmp(name, "maps") == 0) {
-   err = bpf_object__init_maps(obj, data->d_buf,
-   data->d_size);
obj->efile.maps_shndx = idx;
} else if (sh.sh_type == SHT_SYMTAB) {
if (obj->efile.symbols) {
@@ -698,8 +710,16 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
pr_warning("Corrupted ELF file: index of strtab invalid\n");
return LIBBPF_ERRNO__FORMAT;
}
-   if (obj->efile.maps_shndx >= 0)
-   err = bpf_object__init_maps_name(obj);
+   if (obj->efile.maps_shndx >= 0) {
+   Elf_Data *data;
+   err = bpf_object__init_maps_symbol(obj);
+   if (err)
+   goto out;
+
+   scn = elf_getscn(elf, obj->efile.maps_shndx);
+   data = elf_getdata(scn, 0);
+   err = bpf_object__init_maps(obj, 

[PATCH 8/8] tools lib bpf: install header file

[Eric Leblond]

Makefile was not installing the header file of the library and a
manual copy was needed to have a usable library on the system.

Signed-off-by: Eric Leblond 
---
 tools/lib/bpf/Makefile | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 62d89d5..9525956 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -47,6 +47,7 @@ endif
 
 prefix ?= /usr/local
 libdir = $(prefix)/$(libdir_relative)
+includedir = $(prefix)/include/bpf
 man_dir = $(prefix)/share/man
 man_dir_SQ = '$(subst ','\'',$(man_dir))'
 
@@ -87,14 +88,16 @@ include $(FEATURES_DUMP)
 endif
 endif
 
-export prefix libdir src obj
+export prefix libdir includedir src obj
 
 # Shell quotes
 libdir_SQ = $(subst ','\'',$(libdir))
 libdir_relative_SQ = $(subst ','\'',$(libdir_relative))
+includedir_SQ = $(subst ','\'',$(includedir))
 plugin_dir_SQ = $(subst ','\'',$(plugin_dir))
 
 LIB_FILE = libbpf.a libbpf.so
+HEADER_FILE = libbpf.h
 
 VERSION= $(BPF_VERSION)
 PATCHLEVEL = $(BPF_PATCHLEVEL)
@@ -189,7 +192,11 @@ install_lib: all_cmd
$(call QUIET_INSTALL, $(LIB_FILE)) \
$(call do_install,$(LIB_FILE),$(libdir_SQ))
 
-install: install_lib
+install_header: all_cmd
+   $(call QUIET_INSTALL, $(HEADER_FILE)) \
+   $(call do_install,$(HEADER_FILE),$(includedir_SQ))
+
+install: install_lib install_header
 
 ### Cleaning rules
 
-- 
2.9.3

[PATCH 3/8] tools: Sync tools/include/uapi/linux/bpf.h with the kernel

[Eric Leblond]

Signed-off-by: Eric Leblond 
---
 tools/include/uapi/linux/bpf.h | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9e5fc16..570287f 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -95,6 +95,8 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SCHED_ACT,
BPF_PROG_TYPE_TRACEPOINT,
BPF_PROG_TYPE_XDP,
+   BPF_PROG_TYPE_PERF_EVENT,
+   __MAX_BPF_PROG_TYPE,
 };
 
 #define BPF_PSEUDO_MAP_FD  1
@@ -375,6 +377,56 @@ enum bpf_func_id {
 */
BPF_FUNC_probe_write_user,
 
+   /**
+* bpf_current_task_under_cgroup(map, index) - Check cgroup2 membership 
of current task
+* @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
+* @index: index of the cgroup in the bpf_map
+* Return:
+*   == 0 current failed the cgroup2 descendant test
+*   == 1 current succeeded the cgroup2 descendant test
+*< 0 error
+*/
+   BPF_FUNC_current_task_under_cgroup,
+
+   /**
+* bpf_skb_change_tail(skb, len, flags)
+* The helper will resize the skb to the given new size,
+* to be used f.e. with control messages.
+* @skb: pointer to skb
+* @len: new skb length
+* @flags: reserved
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_tail,
+
+   /**
+* bpf_skb_pull_data(skb, len)
+* The helper will pull in non-linear data in case the
+* skb is non-linear and not all of len are part of the
+* linear section. Only needed for read/write with direct
+* packet access.
+* @skb: pointer to skb
+* @len: len to make read/writeable
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_pull_data,
+
+   /**
+* bpf_csum_update(skb, csum)
+* Adds csum into skb->csum in case of CHECKSUM_COMPLETE.
+* @skb: pointer to skb
+* @csum: csum to add
+* Return: csum on success or negative error
+*/
+   BPF_FUNC_csum_update,
+
+   /**
+* bpf_set_hash_invalid(skb)
+* Invalidate current skb>hash.
+* @skb: pointer to skb
+*/
+   BPF_FUNC_set_hash_invalid,
+
__BPF_FUNC_MAX_ID,
 };
 
-- 
2.9.3