Re: [PATCH] thermal: ti-soc-thermal: Add set_emul_temp hook

[Keerthy]

On Tuesday 10 May 2016 05:12 PM, Keerthy wrote:

Setting the emulation temperature helps reproduce critical
temperature scenarios without risking the actual hardware at
extreme temperatures. Adding __ti_thermal_set_emul_temp as
the set_emul_temp hook.


A gentle ping on this.



Signed-off-by: Keerthy 
---

Tested the emulation temperature feature on DRA72-EVM.

  drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index b213a12..e6f7025 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -278,6 +278,20 @@ static int ti_thermal_get_trend(struct thermal_zone_device 
*thermal,
return 0;
  }

+static int __ti_thermal_set_emul_temp(void *p, int temp)
+{
+   struct ti_thermal_data *data = p;
+   struct thermal_zone_device *tz;
+
+   tz = data->ti_thermal;
+
+   mutex_lock(>lock);
+   tz->emul_temperature = temp;
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
  /* Get critical temperature callback functions for thermal zone */
  static int ti_thermal_get_crit_temp(struct thermal_zone_device *thermal,
int *temp)
@@ -289,6 +303,7 @@ static int ti_thermal_get_crit_temp(struct 
thermal_zone_device *thermal,
  static const struct thermal_zone_of_device_ops ti_of_thermal_ops = {
.get_temp = __ti_thermal_get_temp,
.get_trend = __ti_thermal_get_trend,
+   .set_emul_temp = __ti_thermal_set_emul_temp,
  };

  static struct thermal_zone_device_ops ti_thermal_ops = {

Re: [PATCH] thermal: ti-soc-thermal: Add set_emul_temp hook

[Keerthy]

On Tuesday 10 May 2016 05:12 PM, Keerthy wrote:

Setting the emulation temperature helps reproduce critical
temperature scenarios without risking the actual hardware at
extreme temperatures. Adding __ti_thermal_set_emul_temp as
the set_emul_temp hook.


A gentle ping on this.



Signed-off-by: Keerthy 
---

Tested the emulation temperature feature on DRA72-EVM.

  drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index b213a12..e6f7025 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -278,6 +278,20 @@ static int ti_thermal_get_trend(struct thermal_zone_device 
*thermal,
return 0;
  }

+static int __ti_thermal_set_emul_temp(void *p, int temp)
+{
+   struct ti_thermal_data *data = p;
+   struct thermal_zone_device *tz;
+
+   tz = data->ti_thermal;
+
+   mutex_lock(>lock);
+   tz->emul_temperature = temp;
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
  /* Get critical temperature callback functions for thermal zone */
  static int ti_thermal_get_crit_temp(struct thermal_zone_device *thermal,
int *temp)
@@ -289,6 +303,7 @@ static int ti_thermal_get_crit_temp(struct 
thermal_zone_device *thermal,
  static const struct thermal_zone_of_device_ops ti_of_thermal_ops = {
.get_temp = __ti_thermal_get_temp,
.get_trend = __ti_thermal_get_trend,
+   .set_emul_temp = __ti_thermal_set_emul_temp,
  };

  static struct thermal_zone_device_ops ti_thermal_ops = {

Re: linux-next: build warnings after merge of the net tree

[David Miller]

From: Stephen Rothwell 
Date: Fri, 20 May 2016 13:33:30 +1000

> After merging the net tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
 ...
> Introduced by commit
> 
>   e00be9e4d0ff ("net: pegasus: remove dead coding")

This change has other problems too and I have just reverted it.

Thanks.

Re: linux-next: build warnings after merge of the net tree

[David Miller]

From: Stephen Rothwell 
Date: Fri, 20 May 2016 13:33:30 +1000

> After merging the net tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
 ...
> Introduced by commit
> 
>   e00be9e4d0ff ("net: pegasus: remove dead coding")

This change has other problems too and I have just reverted it.

Thanks.

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

[Wanpeng Li]

2016-05-20 10:04 GMT+08:00 Yang Zhang :
> On 2016/5/20 2:36, David Matlack wrote:
>>
>> On Thu, May 19, 2016 at 11:01 AM, David Matlack 
>> wrote:
>>>
>>> On Thu, May 19, 2016 at 6:27 AM, Wanpeng Li  wrote:

 From: Wanpeng Li 

 If an emulated lapic timer will fire soon(in the scope of 10us the
 base of dynamic halt-polling, lower-end of message passing workload
 latency TCP_RR's poll time < 10us) we can treat it as a short halt,
 and poll to wait it fire, the fire callback apic_timer_fn() will set
 KVM_REQ_PENDING_TIMER, and this flag will be check during busy poll.
 This can avoid context switch overhead and the latency which we wake
 up vCPU.
>>>
>>>
>>> If I understand correctly, your patch aims to reduce the latency of
>>> (APIC Timer expires) -> (Guest resumes execution) using halt-polling.
>>> Let me know if I'm misunderstanding.
>>>
>>> In general, I don't think it makes sense to poll for timer interrupts.
>>> We know when the timer interrupt is going to arrive. If we care about
>>> the latency of delivering that interrupt to the guest, we should
>>> program the hrtimer to wake us up slightly early, and then deliver the
>>> virtual timer interrupt right on time (I think KVM's TSC Deadline
>>> Timer emulation already does this).
>>
>>
>> (It looks like the way to enable this feature is to set the module
>> parameter lapic_timer_advance_ns and make sure your guest is using the
>> TSC Deadline timer instead of the APIC Timer.)
>
>
> This feature is slightly different from current advance expiration way.
> Advance expiration rely on the VCPU is running(do polling before vmentry).
> But in some cases, the timer interrupt may be blocked by other thread(i.e.,
> IF bit is clear) and VCPU cannot be scheduled to run immediately. So even
> advance the timer early, VCPU may still see the latency. But polling is
> different, it ensures the VCPU to aware the timer expiration before schedule
> out.

Great explanation, Yang! I prefer to include this statement in my
patch description.

>
>>
>>> I'm curious to know if this scheme
>>> would give the same performance improvement to iperf as your patch.
>>>
>>> We discussed this a bit before on the mailing list before
>>> (https://lkml.org/lkml/2016/3/29/680). I'd like to see halt-polling
>>> and timer interrupts go in the opposite direction: if the next timer
>>> event (from any timer) is less than vcpu->halt_poll_ns, don't poll at
>>> all.
>>>

 iperf TCP get ~6% bandwidth improvement.
>>>
>>>
>>> Can you explain why your patch results in this bandwidth improvement?
>
>
> It should be reasonable. I have seen the same improvement with ctx switch
> benchmark: The latency is reduce from ~2600ns to ~2300ns with the similar
> mechanism.(The same idea but different implementation)

Good to know it. ;-)

Regards,
Wanpeng Li

>
>>>

 Cc: Paolo Bonzini 
 Cc: Radim Krčmář 
 Cc: David Matlack 
 Cc: Christian Borntraeger 
 Signed-off-by: Wanpeng Li 
 ---
 v1 -> v2:
  * add return statement to non-x86 archs
  * capture never expire case for x86 (hrtimer is not started)

  arch/arm/include/asm/kvm_host.h |  4 
  arch/arm64/include/asm/kvm_host.h   |  4 
  arch/mips/include/asm/kvm_host.h|  4 
  arch/powerpc/include/asm/kvm_host.h |  4 
  arch/s390/include/asm/kvm_host.h|  4 
  arch/x86/kvm/lapic.c| 11 +++
  arch/x86/kvm/lapic.h|  1 +
  arch/x86/kvm/x86.c  |  5 +
  include/linux/kvm_host.h|  1 +
  virt/kvm/kvm_main.c | 14 ++
  10 files changed, 48 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/include/asm/kvm_host.h
 b/arch/arm/include/asm/kvm_host.h
 index 4cd8732..a5fd858 100644
 --- a/arch/arm/include/asm/kvm_host.h
 +++ b/arch/arm/include/asm/kvm_host.h
 @@ -284,6 +284,10 @@ static inline void kvm_arch_sync_events(struct kvm
 *kvm) {}
  static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
  static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
  static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
 +static inline u64 kvm_arch_timer_remaining(struct kvm_vcpu *vcpu)
 +{
 +   return -1ULL;
 +}

  static inline void kvm_arm_init_debug(void) {}
  static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
 diff --git a/arch/arm64/include/asm/kvm_host.h
 b/arch/arm64/include/asm/kvm_host.h
 index d49399d..94e227a 100644
 --- a/arch/arm64/include/asm/kvm_host.h
 +++ b/arch/arm64/include/asm/kvm_host.h
 @@ -359,6 +359,10 @@ static inline void 

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

[Wanpeng Li]

2016-05-20 10:04 GMT+08:00 Yang Zhang :
> On 2016/5/20 2:36, David Matlack wrote:
>>
>> On Thu, May 19, 2016 at 11:01 AM, David Matlack 
>> wrote:
>>>
>>> On Thu, May 19, 2016 at 6:27 AM, Wanpeng Li  wrote:

 From: Wanpeng Li 

 If an emulated lapic timer will fire soon(in the scope of 10us the
 base of dynamic halt-polling, lower-end of message passing workload
 latency TCP_RR's poll time < 10us) we can treat it as a short halt,
 and poll to wait it fire, the fire callback apic_timer_fn() will set
 KVM_REQ_PENDING_TIMER, and this flag will be check during busy poll.
 This can avoid context switch overhead and the latency which we wake
 up vCPU.
>>>
>>>
>>> If I understand correctly, your patch aims to reduce the latency of
>>> (APIC Timer expires) -> (Guest resumes execution) using halt-polling.
>>> Let me know if I'm misunderstanding.
>>>
>>> In general, I don't think it makes sense to poll for timer interrupts.
>>> We know when the timer interrupt is going to arrive. If we care about
>>> the latency of delivering that interrupt to the guest, we should
>>> program the hrtimer to wake us up slightly early, and then deliver the
>>> virtual timer interrupt right on time (I think KVM's TSC Deadline
>>> Timer emulation already does this).
>>
>>
>> (It looks like the way to enable this feature is to set the module
>> parameter lapic_timer_advance_ns and make sure your guest is using the
>> TSC Deadline timer instead of the APIC Timer.)
>
>
> This feature is slightly different from current advance expiration way.
> Advance expiration rely on the VCPU is running(do polling before vmentry).
> But in some cases, the timer interrupt may be blocked by other thread(i.e.,
> IF bit is clear) and VCPU cannot be scheduled to run immediately. So even
> advance the timer early, VCPU may still see the latency. But polling is
> different, it ensures the VCPU to aware the timer expiration before schedule
> out.

Great explanation, Yang! I prefer to include this statement in my
patch description.

>
>>
>>> I'm curious to know if this scheme
>>> would give the same performance improvement to iperf as your patch.
>>>
>>> We discussed this a bit before on the mailing list before
>>> (https://lkml.org/lkml/2016/3/29/680). I'd like to see halt-polling
>>> and timer interrupts go in the opposite direction: if the next timer
>>> event (from any timer) is less than vcpu->halt_poll_ns, don't poll at
>>> all.
>>>

 iperf TCP get ~6% bandwidth improvement.
>>>
>>>
>>> Can you explain why your patch results in this bandwidth improvement?
>
>
> It should be reasonable. I have seen the same improvement with ctx switch
> benchmark: The latency is reduce from ~2600ns to ~2300ns with the similar
> mechanism.(The same idea but different implementation)

Good to know it. ;-)

Regards,
Wanpeng Li

>
>>>

 Cc: Paolo Bonzini 
 Cc: Radim Krčmář 
 Cc: David Matlack 
 Cc: Christian Borntraeger 
 Signed-off-by: Wanpeng Li 
 ---
 v1 -> v2:
  * add return statement to non-x86 archs
  * capture never expire case for x86 (hrtimer is not started)

  arch/arm/include/asm/kvm_host.h |  4 
  arch/arm64/include/asm/kvm_host.h   |  4 
  arch/mips/include/asm/kvm_host.h|  4 
  arch/powerpc/include/asm/kvm_host.h |  4 
  arch/s390/include/asm/kvm_host.h|  4 
  arch/x86/kvm/lapic.c| 11 +++
  arch/x86/kvm/lapic.h|  1 +
  arch/x86/kvm/x86.c  |  5 +
  include/linux/kvm_host.h|  1 +
  virt/kvm/kvm_main.c | 14 ++
  10 files changed, 48 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/include/asm/kvm_host.h
 b/arch/arm/include/asm/kvm_host.h
 index 4cd8732..a5fd858 100644
 --- a/arch/arm/include/asm/kvm_host.h
 +++ b/arch/arm/include/asm/kvm_host.h
 @@ -284,6 +284,10 @@ static inline void kvm_arch_sync_events(struct kvm
 *kvm) {}
  static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
  static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
  static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
 +static inline u64 kvm_arch_timer_remaining(struct kvm_vcpu *vcpu)
 +{
 +   return -1ULL;
 +}

  static inline void kvm_arm_init_debug(void) {}
  static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
 diff --git a/arch/arm64/include/asm/kvm_host.h
 b/arch/arm64/include/asm/kvm_host.h
 index d49399d..94e227a 100644
 --- a/arch/arm64/include/asm/kvm_host.h
 +++ b/arch/arm64/include/asm/kvm_host.h
 @@ -359,6 +359,10 @@ static inline void kvm_arch_sync_events(struct kvm
 *kvm) {}
  static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
  static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
  static inline void 

[PATCH] net: alx: use custom skb allocator

[Feng Tang]

This patch follows Eric Dumazet's commit 7b70176421 to fix one
exactly same bug in alx driver, that the network link will
be lost in 1-5 minutes after the device is up.

Following is a git log from Eric's 7b70176421:

"We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 )
that using high order pages for skb allocations is problematic for atl1c

We do not know exactly what the problem is, but we suspect that crossing
4K pages is not well supported by this hardware.

Use a custom allocator, using page allocator and 2K fragments for
optimal stack behavior. We might make this allocator generic
 in future kernels."

And my debug shows the same suspect, most of the errors happen
when there is a RX buffer address with 0x..f80, hopefully
this will get noticed and fixed from silicon side.

My victim is a Lenovo Y580 Laptop with Atheros ALX AR8161 etherenet
device(PCI ID 1969:1091), with this patch the ethernet dev
works just fine

Signed-off-by: Feng Tang 
---
 drivers/net/ethernet/atheros/alx/alx.h  |  4 +++
 drivers/net/ethernet/atheros/alx/main.c | 48 -
 2 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/atheros/alx/alx.h 
b/drivers/net/ethernet/atheros/alx/alx.h
index 8fc93c5..d02c424 100644
--- a/drivers/net/ethernet/atheros/alx/alx.h
+++ b/drivers/net/ethernet/atheros/alx/alx.h
@@ -96,6 +96,10 @@ struct alx_priv {
unsigned int rx_ringsz;
unsigned int rxbuf_size;
 
+   struct page  *rx_page;
+   unsigned int rx_page_offset;
+   unsigned int rx_frag_size;
+
struct napi_struct napi;
struct alx_tx_queue txq;
struct alx_rx_queue rxq;
diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index 9fe8b5e..c98acdc 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -70,6 +70,35 @@ static void alx_free_txbuf(struct alx_priv *alx, int entry)
}
 }
 
+static struct sk_buff *alx_alloc_skb(struct alx_priv *alx, gfp_t gfp)
+{
+   struct sk_buff *skb;
+   struct page *page;
+
+   if (alx->rx_frag_size > PAGE_SIZE)
+   return __netdev_alloc_skb(alx->dev, alx->rxbuf_size, gfp);
+
+   page = alx->rx_page;
+   if (!page) {
+   alx->rx_page = page = alloc_page(gfp);
+   if (unlikely(!page))
+   return NULL;
+   alx->rx_page_offset = 0;
+   }
+
+   skb = build_skb(page_address(page) + alx->rx_page_offset,
+   alx->rx_frag_size);
+   if (likely(skb)) {
+   alx->rx_page_offset += alx->rx_frag_size;
+   if (alx->rx_page_offset >= PAGE_SIZE)
+   alx->rx_page = NULL;
+   else
+   get_page(page);
+   }
+   return skb;
+}
+
+
 static int alx_refill_rx_ring(struct alx_priv *alx, gfp_t gfp)
 {
struct alx_rx_queue *rxq = >rxq;
@@ -86,7 +115,7 @@ static int alx_refill_rx_ring(struct alx_priv *alx, gfp_t 
gfp)
while (!cur_buf->skb && next != rxq->read_idx) {
struct alx_rfd *rfd = >rfd[cur];
 
-   skb = __netdev_alloc_skb(alx->dev, alx->rxbuf_size, gfp);
+   skb = alx_alloc_skb(alx, gfp);
if (!skb)
break;
dma = dma_map_single(>hw.pdev->dev,
@@ -124,6 +153,7 @@ static int alx_refill_rx_ring(struct alx_priv *alx, gfp_t 
gfp)
alx_write_mem16(>hw, ALX_RFD_PIDX, cur);
}
 
+
return count;
 }
 
@@ -592,6 +622,11 @@ static void alx_free_rings(struct alx_priv *alx)
kfree(alx->txq.bufs);
kfree(alx->rxq.bufs);
 
+   if (alx->rx_page) {
+   put_page(alx->rx_page);
+   alx->rx_page = NULL;
+   }
+
dma_free_coherent(>hw.pdev->dev,
  alx->descmem.size,
  alx->descmem.virt,
@@ -646,6 +681,7 @@ static int alx_request_irq(struct alx_priv *alx)
  alx->dev->name, alx);
if (!err)
goto out;
+
/* fall back to legacy interrupt */
pci_disable_msi(alx->hw.pdev);
}
@@ -689,6 +725,7 @@ static int alx_init_sw(struct alx_priv *alx)
struct pci_dev *pdev = alx->hw.pdev;
struct alx_hw *hw = >hw;
int err;
+   unsigned int head_size;
 
err = alx_identify_hw(alx);
if (err) {
@@ -704,7 +741,12 @@ static int alx_init_sw(struct alx_priv *alx)
 
hw->smb_timer = 400;
hw->mtu = alx->dev->mtu;
+
alx->rxbuf_size = ALX_MAX_FRAME_LEN(hw->mtu);
+   head_size = SKB_DATA_ALIGN(alx->rxbuf_size + NET_SKB_PAD) +
+   SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+   alx->rx_frag_size = roundup_pow_of_two(head_size);
+
alx->tx_ringsz = 256;
alx->rx_ringsz = 512;
hw->imt = 200;

[PATCH] net: alx: use custom skb allocator

[Feng Tang]

This patch follows Eric Dumazet's commit 7b70176421 to fix one
exactly same bug in alx driver, that the network link will
be lost in 1-5 minutes after the device is up.

Following is a git log from Eric's 7b70176421:

"We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 )
that using high order pages for skb allocations is problematic for atl1c

We do not know exactly what the problem is, but we suspect that crossing
4K pages is not well supported by this hardware.

Use a custom allocator, using page allocator and 2K fragments for
optimal stack behavior. We might make this allocator generic
 in future kernels."

And my debug shows the same suspect, most of the errors happen
when there is a RX buffer address with 0x..f80, hopefully
this will get noticed and fixed from silicon side.

My victim is a Lenovo Y580 Laptop with Atheros ALX AR8161 etherenet
device(PCI ID 1969:1091), with this patch the ethernet dev
works just fine

Signed-off-by: Feng Tang 
---
 drivers/net/ethernet/atheros/alx/alx.h  |  4 +++
 drivers/net/ethernet/atheros/alx/main.c | 48 -
 2 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/atheros/alx/alx.h 
b/drivers/net/ethernet/atheros/alx/alx.h
index 8fc93c5..d02c424 100644
--- a/drivers/net/ethernet/atheros/alx/alx.h
+++ b/drivers/net/ethernet/atheros/alx/alx.h
@@ -96,6 +96,10 @@ struct alx_priv {
unsigned int rx_ringsz;
unsigned int rxbuf_size;
 
+   struct page  *rx_page;
+   unsigned int rx_page_offset;
+   unsigned int rx_frag_size;
+
struct napi_struct napi;
struct alx_tx_queue txq;
struct alx_rx_queue rxq;
diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index 9fe8b5e..c98acdc 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -70,6 +70,35 @@ static void alx_free_txbuf(struct alx_priv *alx, int entry)
}
 }
 
+static struct sk_buff *alx_alloc_skb(struct alx_priv *alx, gfp_t gfp)
+{
+   struct sk_buff *skb;
+   struct page *page;
+
+   if (alx->rx_frag_size > PAGE_SIZE)
+   return __netdev_alloc_skb(alx->dev, alx->rxbuf_size, gfp);
+
+   page = alx->rx_page;
+   if (!page) {
+   alx->rx_page = page = alloc_page(gfp);
+   if (unlikely(!page))
+   return NULL;
+   alx->rx_page_offset = 0;
+   }
+
+   skb = build_skb(page_address(page) + alx->rx_page_offset,
+   alx->rx_frag_size);
+   if (likely(skb)) {
+   alx->rx_page_offset += alx->rx_frag_size;
+   if (alx->rx_page_offset >= PAGE_SIZE)
+   alx->rx_page = NULL;
+   else
+   get_page(page);
+   }
+   return skb;
+}
+
+
 static int alx_refill_rx_ring(struct alx_priv *alx, gfp_t gfp)
 {
struct alx_rx_queue *rxq = >rxq;
@@ -86,7 +115,7 @@ static int alx_refill_rx_ring(struct alx_priv *alx, gfp_t 
gfp)
while (!cur_buf->skb && next != rxq->read_idx) {
struct alx_rfd *rfd = >rfd[cur];
 
-   skb = __netdev_alloc_skb(alx->dev, alx->rxbuf_size, gfp);
+   skb = alx_alloc_skb(alx, gfp);
if (!skb)
break;
dma = dma_map_single(>hw.pdev->dev,
@@ -124,6 +153,7 @@ static int alx_refill_rx_ring(struct alx_priv *alx, gfp_t 
gfp)
alx_write_mem16(>hw, ALX_RFD_PIDX, cur);
}
 
+
return count;
 }
 
@@ -592,6 +622,11 @@ static void alx_free_rings(struct alx_priv *alx)
kfree(alx->txq.bufs);
kfree(alx->rxq.bufs);
 
+   if (alx->rx_page) {
+   put_page(alx->rx_page);
+   alx->rx_page = NULL;
+   }
+
dma_free_coherent(>hw.pdev->dev,
  alx->descmem.size,
  alx->descmem.virt,
@@ -646,6 +681,7 @@ static int alx_request_irq(struct alx_priv *alx)
  alx->dev->name, alx);
if (!err)
goto out;
+
/* fall back to legacy interrupt */
pci_disable_msi(alx->hw.pdev);
}
@@ -689,6 +725,7 @@ static int alx_init_sw(struct alx_priv *alx)
struct pci_dev *pdev = alx->hw.pdev;
struct alx_hw *hw = >hw;
int err;
+   unsigned int head_size;
 
err = alx_identify_hw(alx);
if (err) {
@@ -704,7 +741,12 @@ static int alx_init_sw(struct alx_priv *alx)
 
hw->smb_timer = 400;
hw->mtu = alx->dev->mtu;
+
alx->rxbuf_size = ALX_MAX_FRAME_LEN(hw->mtu);
+   head_size = SKB_DATA_ALIGN(alx->rxbuf_size + NET_SKB_PAD) +
+   SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+   alx->rx_frag_size = roundup_pow_of_two(head_size);
+
alx->tx_ringsz = 256;
alx->rx_ringsz = 512;
hw->imt = 200;
@@ -806,6 +848,7 @@ 

Re: linux-next 20160512 - ACPI issue with screen brightness

[Aaron Lu]

On 05/20/2016 11:05 AM, valdis.kletni...@vt.edu wrote:
> On Thu, 19 May 2016 18:53:17 -0400, valdis.kletni...@vt.edu said:
> 
 next-20160512 sets the screen brightness to about 40%-ish or so, rather
 than the 100% intensity I want.

Do you mean after boot, the screen brightness is now 40% instead of the
previous 100%? Are you using a GUI? If so, please boot into console mode
to see if this is still the case as GUI sometimes will change backlight
levels so better isolate its impact when testing.

And please list your backlight interfaces:
# ls /sys/class/backlight
I assume it is acpi_video0 that is controlling your backlight levels,
can you please check if it is still working well?
# cd /sys/class/backlight/acpi_video0
# cat max_brightness
XXX
# echo a_value_smaller_or_euqal_to_XXX > brightness

BTW, do you see any error messages in your dmesg?
Probably you can file a new bug at https://bugzilla.kernel.org under the
ACPI/Power-Video category and attach your dmesg/acpidump there, thanks.

Re: linux-next 20160512 - ACPI issue with screen brightness

[Aaron Lu]

On 05/20/2016 11:05 AM, valdis.kletni...@vt.edu wrote:
> On Thu, 19 May 2016 18:53:17 -0400, valdis.kletni...@vt.edu said:
> 
 next-20160512 sets the screen brightness to about 40%-ish or so, rather
 than the 100% intensity I want.

Do you mean after boot, the screen brightness is now 40% instead of the
previous 100%? Are you using a GUI? If so, please boot into console mode
to see if this is still the case as GUI sometimes will change backlight
levels so better isolate its impact when testing.

And please list your backlight interfaces:
# ls /sys/class/backlight
I assume it is acpi_video0 that is controlling your backlight levels,
can you please check if it is still working well?
# cd /sys/class/backlight/acpi_video0
# cat max_brightness
XXX
# echo a_value_smaller_or_euqal_to_XXX > brightness

BTW, do you see any error messages in your dmesg?
Probably you can file a new bug at https://bugzilla.kernel.org under the
ACPI/Power-Video category and attach your dmesg/acpidump there, thanks.

sem_lock() vs qspinlocks

[Davidlohr Bueso]

Hi,

Giovanni ran into a pretty reproducible situation in which the libmicro 
benchmark[1]
shows a functional regression in sysv semaphores, on upstream kernels. 
Specifically
for the 'cascade_cond' and 'cascade_flock' programs, which exhibit hangs in 
libc's
semop() blocked waiting for zero. Alternatively, the following splats may 
appear:

[  692.991258] BUG: unable to handle kernel NULL pointer dereference (null)
[  692.992062] IP: [] unmerge_queues+0x2f/0x70
[  692.992062] PGD 862fab067 PUD 858bbc067 PMD 0
[  692.992062] Oops:  [#1] SMP
[  692.992062] Modules linked in: ...
[  692.992062] CPU: 18 PID: 7398 Comm: cascade_flock Tainted: GE   
4.6.0-juancho2-default+ #18
[  692.992062] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS 
GRNDSDP1.86B.0030.R03.1405061547 05/06/2014
[  692.992062] task: 88084a7e9640 ti: 880854748000 task.ti: 
880854748000
[  692.992062] RIP: 0010:[]  [] 
unmerge_queues+0x2f/0x70
[  692.992062] RSP: 0018:88085474bce8  EFLAGS: 00010216
[  692.992062] RAX:  RBX:  RCX: 88086cc3d0d0
[  692.992062] RDX: 88086cc3d0d0 RSI: 88086cc3d0d0 RDI: 88086cc3d040
[  692.992062] RBP: 88085474bce8 R08: 0007 R09: 88086cc3d088
[  692.992062] R10:  R11: 00a1597ea64c R12: 88085474bd90
[  692.992062] R13: 88086cc3d040 R14:  R15: 
[  692.992062] FS:  7faa46a2d700() GS:88086e50() 
knlGS:
[  692.992062] CS:  0010 DS:  ES:  CR0: 80050033
[  692.992062] CR2:  CR3: 000862faa000 CR4: 001406e0
[  692.992062] Stack:
[  692.992062]  88085474bf38 812a2ac3 810c3995 
88084a7e9640
[  692.992062]   81cb1f48 0002 
880400038000
[  692.992062]  88084a7e9640 88085474bd40 fffc 
88085474bd40
[  692.992062] Call Trace:
[  692.992062]  [] SYSC_semtimedop+0x833/0xc00
[  692.992062]  [] ? __wake_up_common+0x55/0x90
[  692.992062]  [] ? kmem_cache_alloc+0x1e0/0x200
[  692.992062]  [] ? locks_alloc_lock+0x1b/0x70
[  692.992062]  [] ? locks_insert_lock_ctx+0x93/0xa0
[  692.992062]  [] ? flock_lock_inode+0xf4/0x220
[  692.992062]  [] ? locks_lock_inode_wait+0x47/0x160
[  692.992062]  [] ? kmem_cache_alloc+0x1e0/0x200
[  692.992062]  [] ? locks_alloc_lock+0x1b/0x70
[  692.992062]  [] ? locks_free_lock+0x4f/0x60
[  692.992062]  [] SyS_semop+0x10/0x20
[  692.992062]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4
[  692.992062] Code: 00 55 8b 47 7c 48 89 e5 85 c0 75 53 48 8b 4f 48 4c 8d 4f 48 4c 
39 c9 48 8b 11 48 89 ce 75 08 eb 36 48 89 d1 48 89 c2 48 8b 41 28 <0f> b7 00 48 
c1 e0 06 48 03 47 40 4c 8b 40 18 48 89 70 18 48 83
[  692.992062] RIP  [] unmerge_queues+0x2f/0x70
[  692.992062]  RSP 
[  692.992062] CR2: 
[  693.882179] ---[ end trace 5605f108ab79cdb2 ]---

Or,

[  463.567641] BUG: unable to handle kernel paging request at fffa
[  463.576246] IP: [] perform_atomic_semop.isra.5+0xcf/0x170
[  463.584553] PGD 1c0d067 PUD 1c0f067 PMD 0
[  463.590071] Oops:  [#1] SMP
[  463.594667] Modules linked in: ...
[  463.664710] Supported: Yes
[  463.668682] CPU: 6 PID: 2912 Comm: cascade_cond Not tainted 4.4.3-29-default 
#1
[  463.677230] Hardware name: SGI.COM C2112-4GP3/X10DRT-P, BIOS 1.0b 04/07/2015
[  463.685588] task: 88105dba0b40 ti: 8808fc7e task.ti: 
8808fc7e
[  463.694366] RIP: 0010:[]  [] 
perform_atomic_semop.isra.5+0xcf/0x170
[  463.705084] RSP: 0018:8808fc7e3c60  EFLAGS: 00010217
[  463.711610] RAX:  RBX: 88085d22dae0 RCX: 5732f1e7
[  463.719952] RDX: fffa RSI: 88085d22dad0 RDI: 88085d22da80
[  463.728270] RBP:  R08: fff7 R09: 
[  463.736561] R10:  R11: 0206 R12: 88085d22da88
[  463.745001] R13: 88085d22dad0 R14: ffc0 R15: 88085d22da40
[  463.753450] FS:  7f30fd9e5700() GS:88085fac() 
knlGS:
[  463.762684] CS:  0010 DS:  ES:  CR0: 80050033
[  463.769731] CR2: fffa CR3: 00017bc09000 CR4: 001406e0
[  463.778039] Stack:
[  463.781130]  8808fc7e3d50 88085d22dad0 8126dfe1 
4d226800
[  463.789704]  88085d22da80 0001 88085d22da88 
0001
[  463.798254]  0001 88085d22da40 8808fc7e3d50 
8808fc7e3da0
[  463.806758] Call Trace:
[  463.810305]  [] update_queue+0xa1/0x180
[  463.816706]  [] do_smart_update+0x45/0xf0
[  463.823276]  [] SYSC_semtimedop+0x3d1/0xb00
[  463.830035]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[  463.838608] DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x12/0x71
[  463.846331]
[  463.848747] Leftover inexact backtrace:
[  463.848747]
[  463.855853] Code: 80 00 00 81 f9 ff ff 00 00 0f 87 98 00 00 00 66 45 89 0b 
48 83 c2 06 44
89 00 48 39 

sem_lock() vs qspinlocks

[Davidlohr Bueso]

Hi,

Giovanni ran into a pretty reproducible situation in which the libmicro 
benchmark[1]
shows a functional regression in sysv semaphores, on upstream kernels. 
Specifically
for the 'cascade_cond' and 'cascade_flock' programs, which exhibit hangs in 
libc's
semop() blocked waiting for zero. Alternatively, the following splats may 
appear:

[  692.991258] BUG: unable to handle kernel NULL pointer dereference (null)
[  692.992062] IP: [] unmerge_queues+0x2f/0x70
[  692.992062] PGD 862fab067 PUD 858bbc067 PMD 0
[  692.992062] Oops:  [#1] SMP
[  692.992062] Modules linked in: ...
[  692.992062] CPU: 18 PID: 7398 Comm: cascade_flock Tainted: GE   
4.6.0-juancho2-default+ #18
[  692.992062] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS 
GRNDSDP1.86B.0030.R03.1405061547 05/06/2014
[  692.992062] task: 88084a7e9640 ti: 880854748000 task.ti: 
880854748000
[  692.992062] RIP: 0010:[]  [] 
unmerge_queues+0x2f/0x70
[  692.992062] RSP: 0018:88085474bce8  EFLAGS: 00010216
[  692.992062] RAX:  RBX:  RCX: 88086cc3d0d0
[  692.992062] RDX: 88086cc3d0d0 RSI: 88086cc3d0d0 RDI: 88086cc3d040
[  692.992062] RBP: 88085474bce8 R08: 0007 R09: 88086cc3d088
[  692.992062] R10:  R11: 00a1597ea64c R12: 88085474bd90
[  692.992062] R13: 88086cc3d040 R14:  R15: 
[  692.992062] FS:  7faa46a2d700() GS:88086e50() 
knlGS:
[  692.992062] CS:  0010 DS:  ES:  CR0: 80050033
[  692.992062] CR2:  CR3: 000862faa000 CR4: 001406e0
[  692.992062] Stack:
[  692.992062]  88085474bf38 812a2ac3 810c3995 
88084a7e9640
[  692.992062]   81cb1f48 0002 
880400038000
[  692.992062]  88084a7e9640 88085474bd40 fffc 
88085474bd40
[  692.992062] Call Trace:
[  692.992062]  [] SYSC_semtimedop+0x833/0xc00
[  692.992062]  [] ? __wake_up_common+0x55/0x90
[  692.992062]  [] ? kmem_cache_alloc+0x1e0/0x200
[  692.992062]  [] ? locks_alloc_lock+0x1b/0x70
[  692.992062]  [] ? locks_insert_lock_ctx+0x93/0xa0
[  692.992062]  [] ? flock_lock_inode+0xf4/0x220
[  692.992062]  [] ? locks_lock_inode_wait+0x47/0x160
[  692.992062]  [] ? kmem_cache_alloc+0x1e0/0x200
[  692.992062]  [] ? locks_alloc_lock+0x1b/0x70
[  692.992062]  [] ? locks_free_lock+0x4f/0x60
[  692.992062]  [] SyS_semop+0x10/0x20
[  692.992062]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4
[  692.992062] Code: 00 55 8b 47 7c 48 89 e5 85 c0 75 53 48 8b 4f 48 4c 8d 4f 48 4c 
39 c9 48 8b 11 48 89 ce 75 08 eb 36 48 89 d1 48 89 c2 48 8b 41 28 <0f> b7 00 48 
c1 e0 06 48 03 47 40 4c 8b 40 18 48 89 70 18 48 83
[  692.992062] RIP  [] unmerge_queues+0x2f/0x70
[  692.992062]  RSP 
[  692.992062] CR2: 
[  693.882179] ---[ end trace 5605f108ab79cdb2 ]---

Or,

[  463.567641] BUG: unable to handle kernel paging request at fffa
[  463.576246] IP: [] perform_atomic_semop.isra.5+0xcf/0x170
[  463.584553] PGD 1c0d067 PUD 1c0f067 PMD 0
[  463.590071] Oops:  [#1] SMP
[  463.594667] Modules linked in: ...
[  463.664710] Supported: Yes
[  463.668682] CPU: 6 PID: 2912 Comm: cascade_cond Not tainted 4.4.3-29-default 
#1
[  463.677230] Hardware name: SGI.COM C2112-4GP3/X10DRT-P, BIOS 1.0b 04/07/2015
[  463.685588] task: 88105dba0b40 ti: 8808fc7e task.ti: 
8808fc7e
[  463.694366] RIP: 0010:[]  [] 
perform_atomic_semop.isra.5+0xcf/0x170
[  463.705084] RSP: 0018:8808fc7e3c60  EFLAGS: 00010217
[  463.711610] RAX:  RBX: 88085d22dae0 RCX: 5732f1e7
[  463.719952] RDX: fffa RSI: 88085d22dad0 RDI: 88085d22da80
[  463.728270] RBP:  R08: fff7 R09: 
[  463.736561] R10:  R11: 0206 R12: 88085d22da88
[  463.745001] R13: 88085d22dad0 R14: ffc0 R15: 88085d22da40
[  463.753450] FS:  7f30fd9e5700() GS:88085fac() 
knlGS:
[  463.762684] CS:  0010 DS:  ES:  CR0: 80050033
[  463.769731] CR2: fffa CR3: 00017bc09000 CR4: 001406e0
[  463.778039] Stack:
[  463.781130]  8808fc7e3d50 88085d22dad0 8126dfe1 
4d226800
[  463.789704]  88085d22da80 0001 88085d22da88 
0001
[  463.798254]  0001 88085d22da40 8808fc7e3d50 
8808fc7e3da0
[  463.806758] Call Trace:
[  463.810305]  [] update_queue+0xa1/0x180
[  463.816706]  [] do_smart_update+0x45/0xf0
[  463.823276]  [] SYSC_semtimedop+0x3d1/0xb00
[  463.830035]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[  463.838608] DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x12/0x71
[  463.846331]
[  463.848747] Leftover inexact backtrace:
[  463.848747]
[  463.855853] Code: 80 00 00 81 f9 ff ff 00 00 0f 87 98 00 00 00 66 45 89 0b 
48 83 c2 06 44
89 00 48 39 

Re: mmotm 2016-05-19-19-59 uploaded

[Andrew Morton]

Someone stuck a load of for-4.8 stuff into -next during the merge
window.  It had better be for 4.8 anyway - it is super-late.

I intend to simply ignore it and merge the for-4.7 material.

On Fri, 20 May 2016 14:36:28 +0900 Minchan Kim  wrote:

> Ccing Jan,
> 
> dax: Remove complete_unwritten argument
> 
> On Fri, May 20, 2016 at 02:14:17PM +0900, Minchan Kim wrote:
> > On Thu, May 19, 2016 at 07:59:50PM -0700, a...@linux-foundation.org wrote:
> > > The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to
> > > 
> > >http://www.ozlabs.org/~akpm/mmotm/
> > > 
> > > mmotm-readme.txt says
> > > 
> > > README for mm-of-the-moment:
> > > 
> > > http://www.ozlabs.org/~akpm/mmotm/
> > > 
> > > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > > more than once a week.
> > > 
> > > You will need quilt to apply these patches to the latest Linus release 
> > > (4.x
> > > or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > > http://ozlabs.org/~akpm/mmotm/series
> > > 
> > > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > > .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> > > followed by the base kernel version against which this patch series is to
> > > be applied.
> > > 
> > > This tree is partially included in linux-next.  To see which patches are
> > > included in linux-next, consult the `series' file.  Only the patches
> > > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> > > linux-next.
> > > 
> > > A git tree which contains the memory management portion of this tree is
> > > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > > by Michal Hocko.  It contains the patches which are between the
> > > "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
> > > file, http://www.ozlabs.org/~akpm/mmotm/series.
> > > 
> > > 
> > > A full copy of the full kernel tree with the linux-next and mmotm patches
> > > already applied is available through git within an hour of the mmotm
> > > release.  Individual mmotm releases are tagged.  The master branch always
> > > points to the latest release, so it's constantly rebasing.
> > > 
> > > http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
> > > 
> > > To develop on top of mmotm git:
> > > 
> > >   $ git remote add mmotm 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > >   $ git remote update mmotm
> > >   $ git checkout -b topic mmotm/master
> > >   
> > >   $ git send-email mmotm/master.. [...]
> > > 
> > > To rebase a branch with older patches to a new mmotm release:
> > > 
> > >   $ git remote update mmotm
> > >   $ git rebase --onto mmotm/master  topic
> > > 
> > > 
> > > 
> > > 
> > > The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
> > > contains daily snapshots of the -mm tree.  It is updated more frequently
> > > than mmotm, and is untested.
> > > 
> > > A git copy of this tree is available at
> > > 
> > >   http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
> > > 
> > > and use of this tree is similar to
> > > http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
> > > 
> > 
> > In first build, I got this.
> > 
> > In file included from mm/filemap.c:14:0:
> > include/linux/dax.h:14:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:16:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:39:5: error: unknown type name ___dax_iodone_t___
> >  dax_iodone_t di)
> >  ^
> > In file included from mm/vmscan.c:49:0:
> > include/linux/dax.h:14:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:16:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:39:5: error: unknown type name ___dax_iodone_t___
> >  dax_iodone_t di)
> >  ^
> > In file included from mm/truncate.c:12:0:
> > include/linux/dax.h:14:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:16:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:39:5: error: unknown type name ___dax_iodone_t___
> >  dax_iodone_t di)
> >  ^
> > make[1]: *** [mm/truncate.o] Error 1
> > make[1]: *** Waiting for unfinished jobs
> > make[1]: *** [mm/filemap.o] Error 1
> > make[1]: *** [mm/vmscan.o] Error 1
> > make: *** [mm/] Error 2
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majord...@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: mmotm 2016-05-19-19-59 uploaded

[Andrew Morton]

Someone stuck a load of for-4.8 stuff into -next during the merge
window.  It had better be for 4.8 anyway - it is super-late.

I intend to simply ignore it and merge the for-4.7 material.

On Fri, 20 May 2016 14:36:28 +0900 Minchan Kim  wrote:

> Ccing Jan,
> 
> dax: Remove complete_unwritten argument
> 
> On Fri, May 20, 2016 at 02:14:17PM +0900, Minchan Kim wrote:
> > On Thu, May 19, 2016 at 07:59:50PM -0700, a...@linux-foundation.org wrote:
> > > The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to
> > > 
> > >http://www.ozlabs.org/~akpm/mmotm/
> > > 
> > > mmotm-readme.txt says
> > > 
> > > README for mm-of-the-moment:
> > > 
> > > http://www.ozlabs.org/~akpm/mmotm/
> > > 
> > > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > > more than once a week.
> > > 
> > > You will need quilt to apply these patches to the latest Linus release 
> > > (4.x
> > > or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > > http://ozlabs.org/~akpm/mmotm/series
> > > 
> > > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > > .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> > > followed by the base kernel version against which this patch series is to
> > > be applied.
> > > 
> > > This tree is partially included in linux-next.  To see which patches are
> > > included in linux-next, consult the `series' file.  Only the patches
> > > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> > > linux-next.
> > > 
> > > A git tree which contains the memory management portion of this tree is
> > > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > > by Michal Hocko.  It contains the patches which are between the
> > > "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
> > > file, http://www.ozlabs.org/~akpm/mmotm/series.
> > > 
> > > 
> > > A full copy of the full kernel tree with the linux-next and mmotm patches
> > > already applied is available through git within an hour of the mmotm
> > > release.  Individual mmotm releases are tagged.  The master branch always
> > > points to the latest release, so it's constantly rebasing.
> > > 
> > > http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
> > > 
> > > To develop on top of mmotm git:
> > > 
> > >   $ git remote add mmotm 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > >   $ git remote update mmotm
> > >   $ git checkout -b topic mmotm/master
> > >   
> > >   $ git send-email mmotm/master.. [...]
> > > 
> > > To rebase a branch with older patches to a new mmotm release:
> > > 
> > >   $ git remote update mmotm
> > >   $ git rebase --onto mmotm/master  topic
> > > 
> > > 
> > > 
> > > 
> > > The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
> > > contains daily snapshots of the -mm tree.  It is updated more frequently
> > > than mmotm, and is untested.
> > > 
> > > A git copy of this tree is available at
> > > 
> > >   http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
> > > 
> > > and use of this tree is similar to
> > > http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
> > > 
> > 
> > In first build, I got this.
> > 
> > In file included from mm/filemap.c:14:0:
> > include/linux/dax.h:14:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:16:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:39:5: error: unknown type name ___dax_iodone_t___
> >  dax_iodone_t di)
> >  ^
> > In file included from mm/vmscan.c:49:0:
> > include/linux/dax.h:14:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:16:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:39:5: error: unknown type name ___dax_iodone_t___
> >  dax_iodone_t di)
> >  ^
> > In file included from mm/truncate.c:12:0:
> > include/linux/dax.h:14:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:16:3: error: unknown type name ___dax_iodone_t___
> >dax_iodone_t);
> >^
> > include/linux/dax.h:39:5: error: unknown type name ___dax_iodone_t___
> >  dax_iodone_t di)
> >  ^
> > make[1]: *** [mm/truncate.o] Error 1
> > make[1]: *** Waiting for unfinished jobs
> > make[1]: *** [mm/filemap.o] Error 1
> > make[1]: *** [mm/vmscan.o] Error 1
> > make: *** [mm/] Error 2
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majord...@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: mmotm 2016-05-19-19-59 uploaded

[Minchan Kim]

Ccing Jan,

dax: Remove complete_unwritten argument

On Fri, May 20, 2016 at 02:14:17PM +0900, Minchan Kim wrote:
> On Thu, May 19, 2016 at 07:59:50PM -0700, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to
> > 
> >http://www.ozlabs.org/~akpm/mmotm/
> > 
> > mmotm-readme.txt says
> > 
> > README for mm-of-the-moment:
> > 
> > http://www.ozlabs.org/~akpm/mmotm/
> > 
> > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > more than once a week.
> > 
> > You will need quilt to apply these patches to the latest Linus release (4.x
> > or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > http://ozlabs.org/~akpm/mmotm/series
> > 
> > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> > followed by the base kernel version against which this patch series is to
> > be applied.
> > 
> > This tree is partially included in linux-next.  To see which patches are
> > included in linux-next, consult the `series' file.  Only the patches
> > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> > linux-next.
> > 
> > A git tree which contains the memory management portion of this tree is
> > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > by Michal Hocko.  It contains the patches which are between the
> > "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
> > file, http://www.ozlabs.org/~akpm/mmotm/series.
> > 
> > 
> > A full copy of the full kernel tree with the linux-next and mmotm patches
> > already applied is available through git within an hour of the mmotm
> > release.  Individual mmotm releases are tagged.  The master branch always
> > points to the latest release, so it's constantly rebasing.
> > 
> > http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
> > 
> > To develop on top of mmotm git:
> > 
> >   $ git remote add mmotm 
> > git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> >   $ git remote update mmotm
> >   $ git checkout -b topic mmotm/master
> >   
> >   $ git send-email mmotm/master.. [...]
> > 
> > To rebase a branch with older patches to a new mmotm release:
> > 
> >   $ git remote update mmotm
> >   $ git rebase --onto mmotm/master  topic
> > 
> > 
> > 
> > 
> > The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
> > contains daily snapshots of the -mm tree.  It is updated more frequently
> > than mmotm, and is untested.
> > 
> > A git copy of this tree is available at
> > 
> > http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
> > 
> > and use of this tree is similar to
> > http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
> > 
> 
> In first build, I got this.
> 
> In file included from mm/filemap.c:14:0:
> include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
>  dax_iodone_t di)
>  ^
> In file included from mm/vmscan.c:49:0:
> include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
>  dax_iodone_t di)
>  ^
> In file included from mm/truncate.c:12:0:
> include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
>  dax_iodone_t di)
>  ^
> make[1]: *** [mm/truncate.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: *** [mm/filemap.o] Error 1
> make[1]: *** [mm/vmscan.o] Error 1
> make: *** [mm/] Error 2
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: mmotm 2016-05-19-19-59 uploaded

[Minchan Kim]

Ccing Jan,

dax: Remove complete_unwritten argument

On Fri, May 20, 2016 at 02:14:17PM +0900, Minchan Kim wrote:
> On Thu, May 19, 2016 at 07:59:50PM -0700, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to
> > 
> >http://www.ozlabs.org/~akpm/mmotm/
> > 
> > mmotm-readme.txt says
> > 
> > README for mm-of-the-moment:
> > 
> > http://www.ozlabs.org/~akpm/mmotm/
> > 
> > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > more than once a week.
> > 
> > You will need quilt to apply these patches to the latest Linus release (4.x
> > or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > http://ozlabs.org/~akpm/mmotm/series
> > 
> > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> > followed by the base kernel version against which this patch series is to
> > be applied.
> > 
> > This tree is partially included in linux-next.  To see which patches are
> > included in linux-next, consult the `series' file.  Only the patches
> > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> > linux-next.
> > 
> > A git tree which contains the memory management portion of this tree is
> > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > by Michal Hocko.  It contains the patches which are between the
> > "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
> > file, http://www.ozlabs.org/~akpm/mmotm/series.
> > 
> > 
> > A full copy of the full kernel tree with the linux-next and mmotm patches
> > already applied is available through git within an hour of the mmotm
> > release.  Individual mmotm releases are tagged.  The master branch always
> > points to the latest release, so it's constantly rebasing.
> > 
> > http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
> > 
> > To develop on top of mmotm git:
> > 
> >   $ git remote add mmotm 
> > git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> >   $ git remote update mmotm
> >   $ git checkout -b topic mmotm/master
> >   
> >   $ git send-email mmotm/master.. [...]
> > 
> > To rebase a branch with older patches to a new mmotm release:
> > 
> >   $ git remote update mmotm
> >   $ git rebase --onto mmotm/master  topic
> > 
> > 
> > 
> > 
> > The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
> > contains daily snapshots of the -mm tree.  It is updated more frequently
> > than mmotm, and is untested.
> > 
> > A git copy of this tree is available at
> > 
> > http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
> > 
> > and use of this tree is similar to
> > http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
> > 
> 
> In first build, I got this.
> 
> In file included from mm/filemap.c:14:0:
> include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
>  dax_iodone_t di)
>  ^
> In file included from mm/vmscan.c:49:0:
> include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
>  dax_iodone_t di)
>  ^
> In file included from mm/truncate.c:12:0:
> include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
>dax_iodone_t);
>^
> include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
>  dax_iodone_t di)
>  ^
> make[1]: *** [mm/truncate.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: *** [mm/filemap.o] Error 1
> make[1]: *** [mm/vmscan.o] Error 1
> make: *** [mm/] Error 2
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

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

[David Long]

On 05/12/2016 10:49 AM, James Morse wrote:

Hi David, Pratyush

On 27/04/16 19:53, David Long wrote:

From: Pratyush Anand 

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

Signed-off-by: Pratyush Anand 



diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index dfa1b1f..6a1292b 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "kprobes-arm64.h"

@@ -514,6 +515,15 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
return 1;
  }

+bool arch_within_kprobe_blacklist(unsigned long addr)
+{
+   return  (addr >= (unsigned long)__kprobes_text_start &&
+addr < (unsigned long)__kprobes_text_end) ||
+   (addr >= (unsigned long)__entry_text_start &&
+addr < (unsigned long)__entry_text_end) ||
+!!search_exception_tables(addr);
+}
+


Looking at __kvm_hyp_vector, we don't have support for handling breakpoints at
EL2, so we should forbid kprobing these address ranges too:
__hyp_text_start -> __hyp_text_end
__hyp_idmap_text_start -> __hyp_idmap_text_end

These can probably be guarded with is_kernel_in_hyp_mode(), if this is true then
we are running with VHE where this code runs at the same exception level as the
rest of the kernel, so we can probe them. (In this case you may want to add
'eret' to aarch64_insn_is_branch() in patch 2)



OK.



Probing things in the kernel idmap sounds dangerous! Lets blacklist that too:
__idmap_text_start -> __idmap_text_end



OK.




Thanks,

James

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

[David Long]

On 05/12/2016 10:49 AM, James Morse wrote:

Hi David, Pratyush

On 27/04/16 19:53, David Long wrote:

From: Pratyush Anand 

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

Signed-off-by: Pratyush Anand 



diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index dfa1b1f..6a1292b 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "kprobes-arm64.h"

@@ -514,6 +515,15 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
return 1;
  }

+bool arch_within_kprobe_blacklist(unsigned long addr)
+{
+   return  (addr >= (unsigned long)__kprobes_text_start &&
+addr < (unsigned long)__kprobes_text_end) ||
+   (addr >= (unsigned long)__entry_text_start &&
+addr < (unsigned long)__entry_text_end) ||
+!!search_exception_tables(addr);
+}
+


Looking at __kvm_hyp_vector, we don't have support for handling breakpoints at
EL2, so we should forbid kprobing these address ranges too:
__hyp_text_start -> __hyp_text_end
__hyp_idmap_text_start -> __hyp_idmap_text_end

These can probably be guarded with is_kernel_in_hyp_mode(), if this is true then
we are running with VHE where this code runs at the same exception level as the
rest of the kernel, so we can probe them. (In this case you may want to add
'eret' to aarch64_insn_is_branch() in patch 2)



OK.



Probing things in the kernel idmap sounds dangerous! Lets blacklist that too:
__idmap_text_start -> __idmap_text_end



OK.




Thanks,

James

Re: path-lookup inconsistency ?

[Al Viro]

On Thu, May 19, 2016 at 07:20:26PM -0700, Badhri Jagan Sridharan wrote:
> Hi,
> 
> I mounted overlayfs at /
> 
> My cat /proc/mounts looks like the following.
> # cat /proc/mounts
> /dev/root / squashfs ro,seclabel,relatime 0 0
> ..
> overlayfs / overlay
> rw,relatime,lowerdir=/,upperdir=/cache/upper,workdir=/cache/working 0
> 0
> 
> The original blockdevice at fs root is squashfs formatted so doesnt
> support write operations. I mounted overlayfs on fs root to cache the
> writes made.
> 
> While in /, the filesystem does not allow me to create files/directories,
> if I dont prefix it with ".." directive.

Chroot to the thing that overmounts root.  All that .. is doing here is
triggering the traversal to whatever covers the parent (== whatever
covers the root itself, since the parent of root is the root itself).
And we do *not* cross a mountpoint if the starting point of lookup
happens to be covered.  Might've been better if we did a different semantics,
but this one is userland-exposed and, worse yet, a bunch of early boot
userland code relies upon it.

What you want is to be chrooted to whatever overmounts the global root.
The easiest way is probably chroot("/..");chdir("/"); when you are
setting the things up.  Before you exec the final /sbin/init...

Re: path-lookup inconsistency ?

[Al Viro]

On Thu, May 19, 2016 at 07:20:26PM -0700, Badhri Jagan Sridharan wrote:
> Hi,
> 
> I mounted overlayfs at /
> 
> My cat /proc/mounts looks like the following.
> # cat /proc/mounts
> /dev/root / squashfs ro,seclabel,relatime 0 0
> ..
> overlayfs / overlay
> rw,relatime,lowerdir=/,upperdir=/cache/upper,workdir=/cache/working 0
> 0
> 
> The original blockdevice at fs root is squashfs formatted so doesnt
> support write operations. I mounted overlayfs on fs root to cache the
> writes made.
> 
> While in /, the filesystem does not allow me to create files/directories,
> if I dont prefix it with ".." directive.

Chroot to the thing that overmounts root.  All that .. is doing here is
triggering the traversal to whatever covers the parent (== whatever
covers the root itself, since the parent of root is the root itself).
And we do *not* cross a mountpoint if the starting point of lookup
happens to be covered.  Might've been better if we did a different semantics,
but this one is userland-exposed and, worse yet, a bunch of early boot
userland code relies upon it.

What you want is to be chrooted to whatever overmounts the global root.
The easiest way is probably chroot("/..");chdir("/"); when you are
setting the things up.  Before you exec the final /sbin/init...

[PATCH] ALSA: hda - Fix headphone noise on Dell XPS 13 9360

[Kai-Heng Feng]

The headphone has noise when playing sound or switching microphone sources.
It uses the same codec on XPS 13 9350, but with different subsystem ID.
Applying the fixup can solve the issue.
Also, changing the model name to better differentiate models.

Signed-off-by: Kai-Heng Feng 
---
 sound/pci/hda/patch_realtek.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 002f153..e6af865 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5466,7 +5466,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1028, 0x06de, "Dell", 
ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
SND_PCI_QUIRK(0x1028, 0x06df, "Dell", 
ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
SND_PCI_QUIRK(0x1028, 0x06e0, "Dell", 
ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
-   SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13", 
ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+   SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13 9350", 
ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+   SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", 
ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162", 
ALC255_FIXUP_DELL_SPK_NOISE),
SND_PCI_QUIRK(0x1028, 0x164a, "Dell", 
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x164b, "Dell", 
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
-- 
2.8.1

Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop instruction

[Paul Mackerras]

On Tue, May 03, 2016 at 01:54:36PM +0530, Shreyas B. Prabhu wrote:
> POWER ISA v3 defines a new idle processor core mechanism. In summary,
>  a) new instruction named stop is added. This instruction replaces
>   instructions like nap, sleep, rvwinkle.
>  b) new per thread SPR named PSSCR is added which controls the behavior
>   of stop instruction.
> 
> PSSCR has following key fields
>   Bits 0:3  - Power-Saving Level Status. This field indicates the lowest
>   power-saving state the thread entered since stop instruction was last
>   executed.
> 
>   Bit 42 - Enable State Loss
>   0 - No state is lost irrespective of other fields
>   1 - Allows state loss
> 
>   Bits 44:47 - Power-Saving Level Limit
>   This limits the power-saving level that can be entered into.
> 
>   Bits 60:63 - Requested Level
>   Used to specify which power-saving level must be entered on executing
>   stop instruction
> 
> This patch adds support for stop instruction and PSSCR handling.

I notice that you have duplicated a whole lot of assembly code
relating to synchronizing between threads going into and out of
power-saving modes, saving/restoring SPRs, resyncing the timebase, and
so on.

Two questions arise:

- Are we really going to have to do all of that in the same way for
  POWER9 as we did for POWER8?  You even copied over a comment about
  the fastsleep workaround, which I really hope we won't have to do on
  POWER9.  Also, on POWER9, the threads are much more independent, so
  I was not expecting that there would still be shared registers.

- If we do have to do all that, could we use the same code as on
  POWER8 rather than having another copy of all that code?

Paul.

Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop instruction

[Paul Mackerras]

On Tue, May 03, 2016 at 01:54:36PM +0530, Shreyas B. Prabhu wrote:
> POWER ISA v3 defines a new idle processor core mechanism. In summary,
>  a) new instruction named stop is added. This instruction replaces
>   instructions like nap, sleep, rvwinkle.
>  b) new per thread SPR named PSSCR is added which controls the behavior
>   of stop instruction.
> 
> PSSCR has following key fields
>   Bits 0:3  - Power-Saving Level Status. This field indicates the lowest
>   power-saving state the thread entered since stop instruction was last
>   executed.
> 
>   Bit 42 - Enable State Loss
>   0 - No state is lost irrespective of other fields
>   1 - Allows state loss
> 
>   Bits 44:47 - Power-Saving Level Limit
>   This limits the power-saving level that can be entered into.
> 
>   Bits 60:63 - Requested Level
>   Used to specify which power-saving level must be entered on executing
>   stop instruction
> 
> This patch adds support for stop instruction and PSSCR handling.

I notice that you have duplicated a whole lot of assembly code
relating to synchronizing between threads going into and out of
power-saving modes, saving/restoring SPRs, resyncing the timebase, and
so on.

Two questions arise:

- Are we really going to have to do all of that in the same way for
  POWER9 as we did for POWER8?  You even copied over a comment about
  the fastsleep workaround, which I really hope we won't have to do on
  POWER9.  Also, on POWER9, the threads are much more independent, so
  I was not expecting that there would still be shared registers.

- If we do have to do all that, could we use the same code as on
  POWER8 rather than having another copy of all that code?

Paul.

[PATCH] ALSA: hda - Fix headphone noise on Dell XPS 13 9360

[Kai-Heng Feng]

The headphone has noise when playing sound or switching microphone sources.
It uses the same codec on XPS 13 9350, but with different subsystem ID.
Applying the fixup can solve the issue.
Also, changing the model name to better differentiate models.

Signed-off-by: Kai-Heng Feng 
---
 sound/pci/hda/patch_realtek.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 002f153..e6af865 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5466,7 +5466,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1028, 0x06de, "Dell", 
ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
SND_PCI_QUIRK(0x1028, 0x06df, "Dell", 
ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
SND_PCI_QUIRK(0x1028, 0x06e0, "Dell", 
ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
-   SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13", 
ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+   SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13 9350", 
ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+   SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", 
ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162", 
ALC255_FIXUP_DELL_SPK_NOISE),
SND_PCI_QUIRK(0x1028, 0x164a, "Dell", 
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x164b, "Dell", 
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
-- 
2.8.1

Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

[David Long]

On 05/12/2016 11:01 AM, James Morse wrote:

Hi David, Sandeepa,

On 27/04/16 19:53, David Long wrote:

From: Sandeepa Prabhu 



diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
new file mode 100644
index 000..dfa1b1f
--- /dev/null
+++ b/arch/arm64/kernel/kprobes.c
@@ -0,0 +1,520 @@
+/*
+ * arch/arm64/kernel/kprobes.c
+ *
+ * Kprobes support for ARM64
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Author: Sandeepa Prabhu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "kprobes-arm64.h"
+
+#define MIN_STACK_SIZE(addr)   min((unsigned long)MAX_STACK_SIZE,  \
+   (unsigned long)current_thread_info() + THREAD_START_SP - (addr))


What if we probe something called on the irq stack?
This needs the on_irq_stack() checks too, the start/end can be found from the
per-cpu irq_stack value.

[ ... ]



OK.


+int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
+{
+   struct jprobe *jp = container_of(p, struct jprobe, kp);
+   struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+   long stack_ptr = kernel_stack_pointer(regs);
+
+   kcb->jprobe_saved_regs = *regs;
+   memcpy(kcb->jprobes_stack, (void *)stack_ptr,
+  MIN_STACK_SIZE(stack_ptr));


I wonder if we need this stack save/restore?

The comment next to the equivalent code for x86 says:

gcc assumes that the callee owns the argument space and could overwrite it,
e.g. tailcall optimization. So, to be absolutely safe we also save and
restore enough stack bytes to cover the argument area.


On arm64 the first eight arguments are passed in registers, so we might not need
this stack copy. (sparc and powerpc work like this too, their versions of this
function don't copy chunks of the stack).

... then I went looking for functions with >8 arguments...

Looking at the arm64 defconfig dwarf debug data, there are 71 of these that
don't get inlined, picking at random:

rockchip_clk_register_pll() has 13
fib_dump_info() has 11
vma_merge() has 10
vring_create_virtqueue() has 10

etc...

So we do need this stack copying, so that we can probe these function without
risking the arguments being modified.

It may be worth including a comment to the effect that this stack save/restore
is needed for functions that pass >8 arguments where the pre-handler may change
these values on the stack.




I can add a comment.


+   preempt_enable_no_resched();
+   return 1;
+}
+



Thanks,

James



Thanks,
-dl

Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

[David Long]

On 05/12/2016 11:01 AM, James Morse wrote:

Hi David, Sandeepa,

On 27/04/16 19:53, David Long wrote:

From: Sandeepa Prabhu 



diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
new file mode 100644
index 000..dfa1b1f
--- /dev/null
+++ b/arch/arm64/kernel/kprobes.c
@@ -0,0 +1,520 @@
+/*
+ * arch/arm64/kernel/kprobes.c
+ *
+ * Kprobes support for ARM64
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Author: Sandeepa Prabhu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "kprobes-arm64.h"
+
+#define MIN_STACK_SIZE(addr)   min((unsigned long)MAX_STACK_SIZE,  \
+   (unsigned long)current_thread_info() + THREAD_START_SP - (addr))


What if we probe something called on the irq stack?
This needs the on_irq_stack() checks too, the start/end can be found from the
per-cpu irq_stack value.

[ ... ]



OK.


+int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
+{
+   struct jprobe *jp = container_of(p, struct jprobe, kp);
+   struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+   long stack_ptr = kernel_stack_pointer(regs);
+
+   kcb->jprobe_saved_regs = *regs;
+   memcpy(kcb->jprobes_stack, (void *)stack_ptr,
+  MIN_STACK_SIZE(stack_ptr));


I wonder if we need this stack save/restore?

The comment next to the equivalent code for x86 says:

gcc assumes that the callee owns the argument space and could overwrite it,
e.g. tailcall optimization. So, to be absolutely safe we also save and
restore enough stack bytes to cover the argument area.


On arm64 the first eight arguments are passed in registers, so we might not need
this stack copy. (sparc and powerpc work like this too, their versions of this
function don't copy chunks of the stack).

... then I went looking for functions with >8 arguments...

Looking at the arm64 defconfig dwarf debug data, there are 71 of these that
don't get inlined, picking at random:

rockchip_clk_register_pll() has 13
fib_dump_info() has 11
vma_merge() has 10
vring_create_virtqueue() has 10

etc...

So we do need this stack copying, so that we can probe these function without
risking the arguments being modified.

It may be worth including a comment to the effect that this stack save/restore
is needed for functions that pass >8 arguments where the pre-handler may change
these values on the stack.




I can add a comment.


+   preempt_enable_no_resched();
+   return 1;
+}
+



Thanks,

James



Thanks,
-dl

Re: mmotm 2016-05-19-19-59 uploaded

[Minchan Kim]

On Thu, May 19, 2016 at 07:59:50PM -0700, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (4.x
> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
> 
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
> 
> This tree is partially included in linux-next.  To see which patches are
> included in linux-next, consult the `series' file.  Only the patches
> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
> 
> A git tree which contains the memory management portion of this tree is
> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> by Michal Hocko.  It contains the patches which are between the
> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
> file, http://www.ozlabs.org/~akpm/mmotm/series.
> 
> 
> A full copy of the full kernel tree with the linux-next and mmotm patches
> already applied is available through git within an hour of the mmotm
> release.  Individual mmotm releases are tagged.  The master branch always
> points to the latest release, so it's constantly rebasing.
> 
> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
> 
> To develop on top of mmotm git:
> 
>   $ git remote add mmotm 
> git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>   $ git remote update mmotm
>   $ git checkout -b topic mmotm/master
>   
>   $ git send-email mmotm/master.. [...]
> 
> To rebase a branch with older patches to a new mmotm release:
> 
>   $ git remote update mmotm
>   $ git rebase --onto mmotm/master  topic
> 
> 
> 
> 
> The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
> contains daily snapshots of the -mm tree.  It is updated more frequently
> than mmotm, and is untested.
> 
> A git copy of this tree is available at
> 
>   http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
> 
> and use of this tree is similar to
> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
> 

In first build, I got this.

In file included from mm/filemap.c:14:0:
include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
 dax_iodone_t di)
 ^
In file included from mm/vmscan.c:49:0:
include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
 dax_iodone_t di)
 ^
In file included from mm/truncate.c:12:0:
include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
 dax_iodone_t di)
 ^
make[1]: *** [mm/truncate.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: *** [mm/filemap.o] Error 1
make[1]: *** [mm/vmscan.o] Error 1
make: *** [mm/] Error 2

Re: mmotm 2016-05-19-19-59 uploaded

[Minchan Kim]

On Thu, May 19, 2016 at 07:59:50PM -0700, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (4.x
> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
> 
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
> 
> This tree is partially included in linux-next.  To see which patches are
> included in linux-next, consult the `series' file.  Only the patches
> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
> 
> A git tree which contains the memory management portion of this tree is
> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> by Michal Hocko.  It contains the patches which are between the
> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
> file, http://www.ozlabs.org/~akpm/mmotm/series.
> 
> 
> A full copy of the full kernel tree with the linux-next and mmotm patches
> already applied is available through git within an hour of the mmotm
> release.  Individual mmotm releases are tagged.  The master branch always
> points to the latest release, so it's constantly rebasing.
> 
> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
> 
> To develop on top of mmotm git:
> 
>   $ git remote add mmotm 
> git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>   $ git remote update mmotm
>   $ git checkout -b topic mmotm/master
>   
>   $ git send-email mmotm/master.. [...]
> 
> To rebase a branch with older patches to a new mmotm release:
> 
>   $ git remote update mmotm
>   $ git rebase --onto mmotm/master  topic
> 
> 
> 
> 
> The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
> contains daily snapshots of the -mm tree.  It is updated more frequently
> than mmotm, and is untested.
> 
> A git copy of this tree is available at
> 
>   http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
> 
> and use of this tree is similar to
> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
> 

In first build, I got this.

In file included from mm/filemap.c:14:0:
include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
 dax_iodone_t di)
 ^
In file included from mm/vmscan.c:49:0:
include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
 dax_iodone_t di)
 ^
In file included from mm/truncate.c:12:0:
include/linux/dax.h:14:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:16:3: error: unknown type name ‘dax_iodone_t’
   dax_iodone_t);
   ^
include/linux/dax.h:39:5: error: unknown type name ‘dax_iodone_t’
 dax_iodone_t di)
 ^
make[1]: *** [mm/truncate.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: *** [mm/filemap.o] Error 1
make[1]: *** [mm/vmscan.o] Error 1
make: *** [mm/] Error 2

Re: [PATCH] mpssd: fix buffer overflow warning

[Ashutosh Dixit]

On Fri, May 20 2016 at 12:54:51 AM, Mike Danese  wrote:
> The compilation emits a warning in function ‘snprintf’,
> inlined from ‘set_cmdline’ at
> ../Documentation/mic/mpssd/mpssd.c:1541:9:
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10:
> warning: call to __builtin___snprintf_chk will always overflow
> destination buffer
>
> This was introduced in commit f4a66c204482 ("misc: mic: Update MIC host
> daemon with COSM changes") and is fixed by reverting the changes to the
> size argument of these snprintf statements.

Thanks for the patch, the fix is fine.

Re: [PATCH] mpssd: fix buffer overflow warning

[Ashutosh Dixit]

On Fri, May 20 2016 at 12:54:51 AM, Mike Danese  wrote:
> The compilation emits a warning in function ‘snprintf’,
> inlined from ‘set_cmdline’ at
> ../Documentation/mic/mpssd/mpssd.c:1541:9:
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10:
> warning: call to __builtin___snprintf_chk will always overflow
> destination buffer
>
> This was introduced in commit f4a66c204482 ("misc: mic: Update MIC host
> daemon with COSM changes") and is fixed by reverting the changes to the
> size argument of these snprintf statements.

Thanks for the patch, the fix is fine.

Re: [PATCH] fbcon: warn on invalid cursor blink intervals

[Jeremy Kerr]

Hi Ming,

>Then looks there are two fix patches acked & tested:
>
> - the patch in this thread
> - another one "[PATCH] tty: vt: Fix soft lockup in fbcon cursor
>blink timer."
> https://lkml.org/lkml/2016/5/17/455
>
>So which one will be pushed to linus?

Not that it's my call, but we may want both; the first as a safety
measure to prevent an invalid cur_blink_jiffies ever being set, and the
second one to actually fix the initialisation of vc_cur_blink_ms (and
address the warning introduced by the first).

I guess we could just go with the latter for stable...

Cheers,


Jeremy

Re: [PATCH] fbcon: warn on invalid cursor blink intervals

[Jeremy Kerr]

Hi Ming,

>Then looks there are two fix patches acked & tested:
>
> - the patch in this thread
> - another one "[PATCH] tty: vt: Fix soft lockup in fbcon cursor
>blink timer."
> https://lkml.org/lkml/2016/5/17/455
>
>So which one will be pushed to linus?

Not that it's my call, but we may want both; the first as a safety
measure to prevent an invalid cur_blink_jiffies ever being set, and the
second one to actually fix the initialisation of vc_cur_blink_ms (and
address the warning introduced by the first).

I guess we could just go with the latter for stable...

Cheers,


Jeremy

[PATCH] mpssd: fix buffer overflow warning

[Mike Danese]

The compilation emits a warning in function ‘snprintf’,
inlined from ‘set_cmdline’ at
../Documentation/mic/mpssd/mpssd.c:1541:9:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10:
warning: call to __builtin___snprintf_chk will always overflow
destination buffer

This was introduced in commit f4a66c204482 ("misc: mic: Update MIC host
daemon with COSM changes") and is fixed by reverting the changes to the
size argument of these snprintf statements.

Cc: Ashutosh Dixit 
Signed-off-by: Mike Danese 
---
 Documentation/mic/mpssd/mpssd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/mic/mpssd/mpssd.c b/Documentation/mic/mpssd/mpssd.c
index 30fb842..49db1de 100644
--- a/Documentation/mic/mpssd/mpssd.c
+++ b/Documentation/mic/mpssd/mpssd.c
@@ -1538,9 +1538,9 @@ set_cmdline(struct mic_info *mic)
 
len = snprintf(buffer, PATH_MAX,
"clocksource=tsc highres=off nohz=off ");
-   len += snprintf(buffer + len, PATH_MAX,
+   len += snprintf(buffer + len, PATH_MAX - len,
"cpufreq_on;corec6_off;pc3_off;pc6_off ");
-   len += snprintf(buffer + len, PATH_MAX,
+   len += snprintf(buffer + len, PATH_MAX - len,
"ifcfg=static;address,172.31.%d.1;netmask,255.255.255.0",
mic->id + 1);
 
-- 
2.5.0

[PATCH] mpssd: fix buffer overflow warning

[Mike Danese]

The compilation emits a warning in function ‘snprintf’,
inlined from ‘set_cmdline’ at
../Documentation/mic/mpssd/mpssd.c:1541:9:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10:
warning: call to __builtin___snprintf_chk will always overflow
destination buffer

This was introduced in commit f4a66c204482 ("misc: mic: Update MIC host
daemon with COSM changes") and is fixed by reverting the changes to the
size argument of these snprintf statements.

Cc: Ashutosh Dixit 
Signed-off-by: Mike Danese 
---
 Documentation/mic/mpssd/mpssd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/mic/mpssd/mpssd.c b/Documentation/mic/mpssd/mpssd.c
index 30fb842..49db1de 100644
--- a/Documentation/mic/mpssd/mpssd.c
+++ b/Documentation/mic/mpssd/mpssd.c
@@ -1538,9 +1538,9 @@ set_cmdline(struct mic_info *mic)
 
len = snprintf(buffer, PATH_MAX,
"clocksource=tsc highres=off nohz=off ");
-   len += snprintf(buffer + len, PATH_MAX,
+   len += snprintf(buffer + len, PATH_MAX - len,
"cpufreq_on;corec6_off;pc3_off;pc6_off ");
-   len += snprintf(buffer + len, PATH_MAX,
+   len += snprintf(buffer + len, PATH_MAX - len,
"ifcfg=static;address,172.31.%d.1;netmask,255.255.255.0",
mic->id + 1);
 
-- 
2.5.0

Re: [PATCH perf/core v8 00/16] perf-probe --cache and SDT support

[Hemant Kumar]

On 05/15/2016 08:49 AM, Masami Hiramatsu wrote:

Hi,

Here is the 8th version of the patchset for probe-cache and
initial SDT support.

The previous version is here; https://lkml.org/lkml/2016/5/11/446

This version I droped the second patch in v7 because it may
involves unintended behavior change and we'd better discuss it
out of this series. I also added comments why we can't use
access(R_OK) for /proc/kcore.

Hemant, could you review and test this series so that we can
proceed to your patch depending on this?


So, apart from the two issues which I mentioned in
the individual patches, it seems fine.

However, I think we will need a bit detailed documentation for the
probe cache feature as well as for the SDT support, given that we
have different commands to add {probe,sdt} events for a binary
and use them. I will write that that doc up based on your next
version.



Thank you,

---

Hemant Kumar (1):
   perf/sdt: ELF support for SDT

Masami Hiramatsu (15):
   perf buildid: Introduce DSO__NAME_KALLSYMS and DSO__NAME_KCORE
   perf symbol: Cleanup the code flow of dso__find_kallsyms
   perf-buildid-cache: Use path/to/bin/buildid/elf instead of 
path/to/bin/buildid
   perf probe: Add --cache option to cache the probe definitions
   perf probe: Use cache entry if possible
   perf probe: Show all cached probes
   perf probe: Remove caches when --cache is given
   perf probe: Add group name support
   perf buildid-cache: Scan and import user SDT events to probe cache
   perf probe: Accept %sdt and %cached event name
   perf-list: Show SDT and pre-cached events
   perf-list: Skip SDTs placed in invalid binaries
   perf probe: Allow wildcard for cached events
   perf probe: Support @BUILDID or @FILE suffix for SDT events
   perf probe: Support a special SDT probe format


  tools/perf/Documentation/perf-probe.txt |   26 +-
  tools/perf/builtin-buildid-cache.c  |8
  tools/perf/builtin-list.c   |4
  tools/perf/builtin-probe.c  |   30 ++
  tools/perf/util/annotate.c  |2
  tools/perf/util/build-id.c  |  295 --
  tools/perf/util/build-id.h  |8
  tools/perf/util/dso.h   |5
  tools/perf/util/machine.c   |2
  tools/perf/util/parse-events.c  |   83 +
  tools/perf/util/parse-events.h  |2
  tools/perf/util/probe-event.c   |  492 +++---
  tools/perf/util/probe-event.h   |7
  tools/perf/util/probe-file.c|  502 +++
  tools/perf/util/probe-file.h|   41 +++
  tools/perf/util/symbol-elf.c|  252 
  tools/perf/util/symbol.c|   73 ++---
  tools/perf/util/symbol.h|   25 ++
  18 files changed, 1719 insertions(+), 138 deletions(-)

--
Masami Hiramatsu



--
Thanks,
Hemant Kumar

Re: [PATCH perf/core v8 00/16] perf-probe --cache and SDT support

[Hemant Kumar]

On 05/15/2016 08:49 AM, Masami Hiramatsu wrote:

Hi,

Here is the 8th version of the patchset for probe-cache and
initial SDT support.

The previous version is here; https://lkml.org/lkml/2016/5/11/446

This version I droped the second patch in v7 because it may
involves unintended behavior change and we'd better discuss it
out of this series. I also added comments why we can't use
access(R_OK) for /proc/kcore.

Hemant, could you review and test this series so that we can
proceed to your patch depending on this?


So, apart from the two issues which I mentioned in
the individual patches, it seems fine.

However, I think we will need a bit detailed documentation for the
probe cache feature as well as for the SDT support, given that we
have different commands to add {probe,sdt} events for a binary
and use them. I will write that that doc up based on your next
version.



Thank you,

---

Hemant Kumar (1):
   perf/sdt: ELF support for SDT

Masami Hiramatsu (15):
   perf buildid: Introduce DSO__NAME_KALLSYMS and DSO__NAME_KCORE
   perf symbol: Cleanup the code flow of dso__find_kallsyms
   perf-buildid-cache: Use path/to/bin/buildid/elf instead of 
path/to/bin/buildid
   perf probe: Add --cache option to cache the probe definitions
   perf probe: Use cache entry if possible
   perf probe: Show all cached probes
   perf probe: Remove caches when --cache is given
   perf probe: Add group name support
   perf buildid-cache: Scan and import user SDT events to probe cache
   perf probe: Accept %sdt and %cached event name
   perf-list: Show SDT and pre-cached events
   perf-list: Skip SDTs placed in invalid binaries
   perf probe: Allow wildcard for cached events
   perf probe: Support @BUILDID or @FILE suffix for SDT events
   perf probe: Support a special SDT probe format


  tools/perf/Documentation/perf-probe.txt |   26 +-
  tools/perf/builtin-buildid-cache.c  |8
  tools/perf/builtin-list.c   |4
  tools/perf/builtin-probe.c  |   30 ++
  tools/perf/util/annotate.c  |2
  tools/perf/util/build-id.c  |  295 --
  tools/perf/util/build-id.h  |8
  tools/perf/util/dso.h   |5
  tools/perf/util/machine.c   |2
  tools/perf/util/parse-events.c  |   83 +
  tools/perf/util/parse-events.h  |2
  tools/perf/util/probe-event.c   |  492 +++---
  tools/perf/util/probe-event.h   |7
  tools/perf/util/probe-file.c|  502 +++
  tools/perf/util/probe-file.h|   41 +++
  tools/perf/util/symbol-elf.c|  252 
  tools/perf/util/symbol.c|   73 ++---
  tools/perf/util/symbol.h|   25 ++
  18 files changed, 1719 insertions(+), 138 deletions(-)

--
Masami Hiramatsu



--
Thanks,
Hemant Kumar

Re: [patch V2 3/7] futex: Add op for hash preallocation

[Peter Zijlstra]

On Thu, May 19, 2016 at 12:38:19PM -0700, Darren Hart wrote:
> On Thu, May 19, 2016 at 02:24:57PM +0200, Peter Zijlstra wrote:
> > OK, so no on-line rehashing possible?
> 
> It doesn't do it currently... did you see something that makes it impossible 
> to
> add?

No, just tons of tricky.

Re: [patch V2 3/7] futex: Add op for hash preallocation

[Peter Zijlstra]

On Thu, May 19, 2016 at 12:38:19PM -0700, Darren Hart wrote:
> On Thu, May 19, 2016 at 02:24:57PM +0200, Peter Zijlstra wrote:
> > OK, so no on-line rehashing possible?
> 
> It doesn't do it currently... did you see something that makes it impossible 
> to
> add?

No, just tons of tricky.

linux-next: Tree for May 20

[Stephen Rothwell]

Hi all,

Please do not add any v4.8 destined material to your linux-next included
branches until after v4.7-rc1 has been released.

Changes since 20160519:

The vfs tree gained a conflict against the cifs tree.

The tty tree gained a conflict against Linus' tree.

The dax-misc tree gained a conflict against Linus' tree.

The akpm-current tree gained a conflict against the dax-misc tree.

Non-merge commits (relative to Linus' tree): 4907
 3848 files changed, 218368 insertions(+), 94973 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 236 trees (counting Linus' and 35 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 (f4c80d5a16eb Merge tag 'sound-4.7-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound)
Merging fixes/master (b507146bb6b9 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (44549e8f5eea Linux 4.6-rc7)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (33656a1f2ee5 Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging net/master (e22cb5e78762 Merge tag 'batman-adv-fix-for-davem' of 
git://git.open-mesh.org/linux-merge)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (cbbba30f1ac9 Merge tag 
'iwlwifi-for-kalle-2016-05-04' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (17e1717c11a3 ALSA: firewire-lib: change a 
member of event structure to suppress sparse wanings to bool type)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb.current/usb-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (44549e8f5eea Linux 4.6-rc7)
Merging char-misc.current/char-misc-linus (44549e8f5eea Linux 4.6-rc7)
Merging input-current/for-linus (23ea5967d6bd Merge branch 'next' into 
for-linus)
Merging crypto-current/master (bad6a185b4d6 crypto: public_key: select 
CRYPTO_AKCIPHER)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 

linux-next: Tree for May 20

[Stephen Rothwell]

Hi all,

Please do not add any v4.8 destined material to your linux-next included
branches until after v4.7-rc1 has been released.

Changes since 20160519:

The vfs tree gained a conflict against the cifs tree.

The tty tree gained a conflict against Linus' tree.

The dax-misc tree gained a conflict against Linus' tree.

The akpm-current tree gained a conflict against the dax-misc tree.

Non-merge commits (relative to Linus' tree): 4907
 3848 files changed, 218368 insertions(+), 94973 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 236 trees (counting Linus' and 35 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 (f4c80d5a16eb Merge tag 'sound-4.7-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound)
Merging fixes/master (b507146bb6b9 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (44549e8f5eea Linux 4.6-rc7)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (33656a1f2ee5 Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging net/master (e22cb5e78762 Merge tag 'batman-adv-fix-for-davem' of 
git://git.open-mesh.org/linux-merge)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (cbbba30f1ac9 Merge tag 
'iwlwifi-for-kalle-2016-05-04' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (17e1717c11a3 ALSA: firewire-lib: change a 
member of event structure to suppress sparse wanings to bool type)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb.current/usb-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (44549e8f5eea Linux 4.6-rc7)
Merging char-misc.current/char-misc-linus (44549e8f5eea Linux 4.6-rc7)
Merging input-current/for-linus (23ea5967d6bd Merge branch 'next' into 
for-linus)
Merging crypto-current/master (bad6a185b4d6 crypto: public_key: select 
CRYPTO_AKCIPHER)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 

Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller

[Jon Masters]

Hi Tomasz, all,

On 05/11/2016 07:08 AM, Tomasz Nowicki wrote:

> On 11.05.2016 12:41, Gabriele Paoloni wrote:

>>> v6 -> v7
>>> - drop quirks handling
>>
>> Maybe I missed something in the v6 discussion thread; when was it
>> decided to drop quirk handling?
> 
> I had such requests in previous series.

A quick note on quirk handling. This, I believe, applies post-merge of
the base infrastructure, which I realize will likely not have quirks.

We've some "gen1" ARMv8 server platforms where we end up doing quirks
(for things like forcing 32-bit config space accessors and the like) due
to people repurposing existing embedded PCIe IP blocks or using them for
the first time (especially in servers), and those being involved in the
design not necessarily seeing this problem ahead of time, or not
realizing that it would be an issue for servers. In the early days of
ARM server designs 3-4 years ago, many of us had never really played
with ECAM or realized how modern topologies are built.

Anyway. We missed this one in our SBSA requirements. They say (words to
the effect of) "thou shalt do PCIe the way it is done on servers" but
they aren't prescriptive, and they don't tell people how that actually
is in reality. That is being fixed. A lot of things are happening behind
the scenes - especially with third party IP block providers (all of whom
myself and others are speaking with directly about this) - to ensure
that the next wave of designs won't repeat these mistakes. We don't have
a time machine, but we can contain this from becoming an ongoing mess
for upstream, and we will do so. It won't be a zoo.

Various proposals have arisen for how to handle quirks in the longer
term, including elaborate frameworks and tables to describe them
generically. I would like to caution against such approaches, especially
in the case that they deviate from practice on x86, or prior to being
standardized fully with other Operating System vendors. I don't expect
there to be too many more than the existing initial set of quirks we
have seen posted. A number of "future" server SoCs have already been
fixed prior to silicon, and new design starts are being warned not to
make this a problem for us to have to clean up later.

So, I would like to suggest that the eventual framework mirror the
existing approach on x86 systems (matching DMI, etc.) and not be made
into some kind of generic, utopia. This is a case where we want there to
be pain involved (and upstream patches required) when people screw up,
so that they have a level of pain in response to ever making this
mistake in the future. If we try to create too grand a generic scheme
and make it too easy to handle this kind of situation beyond the small
number of existing offenders, we undermine efforts to force vendors to
ensure that their IP blocks are compliant going forward.

Side note: if you're a third party IP vendor and we didn't already speak
about this one, drop me a line, and let's collaborate also on your test
frameworks to make sure you're covered as well.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller

[Jon Masters]

Hi Tomasz, all,

On 05/11/2016 07:08 AM, Tomasz Nowicki wrote:

> On 11.05.2016 12:41, Gabriele Paoloni wrote:

>>> v6 -> v7
>>> - drop quirks handling
>>
>> Maybe I missed something in the v6 discussion thread; when was it
>> decided to drop quirk handling?
> 
> I had such requests in previous series.

A quick note on quirk handling. This, I believe, applies post-merge of
the base infrastructure, which I realize will likely not have quirks.

We've some "gen1" ARMv8 server platforms where we end up doing quirks
(for things like forcing 32-bit config space accessors and the like) due
to people repurposing existing embedded PCIe IP blocks or using them for
the first time (especially in servers), and those being involved in the
design not necessarily seeing this problem ahead of time, or not
realizing that it would be an issue for servers. In the early days of
ARM server designs 3-4 years ago, many of us had never really played
with ECAM or realized how modern topologies are built.

Anyway. We missed this one in our SBSA requirements. They say (words to
the effect of) "thou shalt do PCIe the way it is done on servers" but
they aren't prescriptive, and they don't tell people how that actually
is in reality. That is being fixed. A lot of things are happening behind
the scenes - especially with third party IP block providers (all of whom
myself and others are speaking with directly about this) - to ensure
that the next wave of designs won't repeat these mistakes. We don't have
a time machine, but we can contain this from becoming an ongoing mess
for upstream, and we will do so. It won't be a zoo.

Various proposals have arisen for how to handle quirks in the longer
term, including elaborate frameworks and tables to describe them
generically. I would like to caution against such approaches, especially
in the case that they deviate from practice on x86, or prior to being
standardized fully with other Operating System vendors. I don't expect
there to be too many more than the existing initial set of quirks we
have seen posted. A number of "future" server SoCs have already been
fixed prior to silicon, and new design starts are being warned not to
make this a problem for us to have to clean up later.

So, I would like to suggest that the eventual framework mirror the
existing approach on x86 systems (matching DMI, etc.) and not be made
into some kind of generic, utopia. This is a case where we want there to
be pain involved (and upstream patches required) when people screw up,
so that they have a level of pain in response to ever making this
mistake in the future. If we try to create too grand a generic scheme
and make it too easy to handle this kind of situation beyond the small
number of existing offenders, we undermine efforts to force vendors to
ensure that their IP blocks are compliant going forward.

Side note: if you're a third party IP vendor and we didn't already speak
about this one, drop me a line, and let's collaborate also on your test
frameworks to make sure you're covered as well.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

[PATCH] security: tomoyo: simplify the gc kthread creation

[Mike Danese]

The code is doing the equivalent of the kthread_run macro.

Signed-off-by: Mike Danese 
---
 security/tomoyo/gc.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/security/tomoyo/gc.c b/security/tomoyo/gc.c
index 986a6a7..540bc29 100644
--- a/security/tomoyo/gc.c
+++ b/security/tomoyo/gc.c
@@ -645,11 +645,6 @@ void tomoyo_notify_gc(struct tomoyo_io_buffer *head, const 
bool is_register)
}
}
spin_unlock(_io_buffer_list_lock);
-   if (is_write) {
-   struct task_struct *task = kthread_create(tomoyo_gc_thread,
- NULL,
- "GC for TOMOYO");
-   if (!IS_ERR(task))
-   wake_up_process(task);
-   }
+   if (is_write)
+   kthread_run(tomoyo_gc_thread, NULL, "GC for TOMOYO");
 }
-- 
2.5.0

[PATCH] security: tomoyo: simplify the gc kthread creation

[Mike Danese]

The code is doing the equivalent of the kthread_run macro.

Signed-off-by: Mike Danese 
---
 security/tomoyo/gc.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/security/tomoyo/gc.c b/security/tomoyo/gc.c
index 986a6a7..540bc29 100644
--- a/security/tomoyo/gc.c
+++ b/security/tomoyo/gc.c
@@ -645,11 +645,6 @@ void tomoyo_notify_gc(struct tomoyo_io_buffer *head, const 
bool is_register)
}
}
spin_unlock(_io_buffer_list_lock);
-   if (is_write) {
-   struct task_struct *task = kthread_create(tomoyo_gc_thread,
- NULL,
- "GC for TOMOYO");
-   if (!IS_ERR(task))
-   wake_up_process(task);
-   }
+   if (is_write)
+   kthread_run(tomoyo_gc_thread, NULL, "GC for TOMOYO");
 }
-- 
2.5.0

Re: [PATCH 0/4] regulator: tps65917/palmas: Cleanups and bugfixes

[Keerthy]

+ Lee Jones

On Saturday 07 May 2016 12:31 AM, Nishanth Menon wrote:

On 05/06/2016 12:14 PM, Mark Brown wrote:

On Fri, May 06, 2016 at 12:44:23PM +0530, Laxman Dewangan wrote:


When you are here, can you implement the dt parsing with the new method from
regulator framework.
Regulator FW calls callback to parse customized DT property, just need to
pass the node and pointer when registering.



This will helps lots in cleanups and readability.


Yes, please.


yeah, the driver has started showing it's age, it will be good to do a
refactor.


Laxman,

I got the dt parsing with new method from regulator framework part, But
by new method do you also want to remove the dt compatible of regulators 
and let only the mfd compatible stay?


replace of_platform_populate with mfd_add_devices so that linux handles 
the drivers split up and not the device tree?


Regards,
Keerthy

Re: [PATCH 0/4] regulator: tps65917/palmas: Cleanups and bugfixes

[Keerthy]

+ Lee Jones

On Saturday 07 May 2016 12:31 AM, Nishanth Menon wrote:

On 05/06/2016 12:14 PM, Mark Brown wrote:

On Fri, May 06, 2016 at 12:44:23PM +0530, Laxman Dewangan wrote:


When you are here, can you implement the dt parsing with the new method from
regulator framework.
Regulator FW calls callback to parse customized DT property, just need to
pass the node and pointer when registering.



This will helps lots in cleanups and readability.


Yes, please.


yeah, the driver has started showing it's age, it will be good to do a
refactor.


Laxman,

I got the dt parsing with new method from regulator framework part, But
by new method do you also want to remove the dt compatible of regulators 
and let only the mfd compatible stay?


replace of_platform_populate with mfd_add_devices so that linux handles 
the drivers split up and not the device tree?


Regards,
Keerthy

Re: [PATCH v3] gpio: UniPhier: add driver for UniPhier GPIO controller

[Masahiro Yamada]

Hi Linus,


2015-07-16 16:48 GMT+09:00 Masahiro Yamada :
> Hi Linus,

>
> OK, I will do it in v4.


I has been away from my GPIO driver upstreaming
for a long time for some reason.

I sent v3 ten months ago.
http://patchwork.ozlabs.org/patch/494860/


In the meantime, there have been various updates
in the GPIO frame-work.

So, I'd like to know the recommended driver coding style
based on 4.7-rc1.


Diving into the git-log so far, I came up the following list:

[1] The "dev" member of gpiochip was renamed to "parent"

[2] The most recommended register function is now
devm_gpiochip_add_data()

[3] Pass the driver private data to the
3rd argument of devm_gpiochip_add_data().

[4] Do not use container_of() to covert
from gpiochip to driver private data.
Instead, gpiochip_get_data() should be used.

(I used of_mm_gpio_chip in v3,
 but I needed to use container_of() to
 convert from gpiochip to of_mm_gpio_chip.
 I am wondering if you are happy with it or not.)

[5] gpiochip.owner is being deprecated.
So, platform drivers need not set
 "gpiochip.owner =  THIS_MODULE".


Correct?
Is there anything else missing?

Any advice is appreciated.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3] gpio: UniPhier: add driver for UniPhier GPIO controller

[Masahiro Yamada]

Hi Linus,


2015-07-16 16:48 GMT+09:00 Masahiro Yamada :
> Hi Linus,

>
> OK, I will do it in v4.


I has been away from my GPIO driver upstreaming
for a long time for some reason.

I sent v3 ten months ago.
http://patchwork.ozlabs.org/patch/494860/


In the meantime, there have been various updates
in the GPIO frame-work.

So, I'd like to know the recommended driver coding style
based on 4.7-rc1.


Diving into the git-log so far, I came up the following list:

[1] The "dev" member of gpiochip was renamed to "parent"

[2] The most recommended register function is now
devm_gpiochip_add_data()

[3] Pass the driver private data to the
3rd argument of devm_gpiochip_add_data().

[4] Do not use container_of() to covert
from gpiochip to driver private data.
Instead, gpiochip_get_data() should be used.

(I used of_mm_gpio_chip in v3,
 but I needed to use container_of() to
 convert from gpiochip to of_mm_gpio_chip.
 I am wondering if you are happy with it or not.)

[5] gpiochip.owner is being deprecated.
So, platform drivers need not set
 "gpiochip.owner =  THIS_MODULE".


Correct?
Is there anything else missing?

Any advice is appreciated.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v12 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

[David Long]

On 05/17/2016 05:14 AM, Huang Shijie wrote:

On Wed, Apr 27, 2016 at 02:52:56PM -0400, David Long wrote:

From: "David A. Long" 
+/**
+ * regs_within_kernel_stack() - check the address in the stack
+ * @regs:  pt_regs which contains kernel stack pointer.
+ * @addr:  address which is checked.
+ *
+ * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
+ * If @addr is within the kernel stack, it returns true. If not, returns false.
+ */
+bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
+{
+   return ((addr & ~(THREAD_SIZE - 1))  ==
+   (kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1))) ||
+   on_irq_stack(addr, raw_smp_processor_id());
+}
+
+/**
+ * regs_get_kernel_stack_nth() - get Nth entry of the stack
+ * @regs:  pt_regs which contains kernel stack pointer.
+ * @n: stack entry number.
+ *
+ * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
+ * is specified by @regs. If the @n th entry is NOT in the kernel stack,
+ * this returns 0.
+ */_
+unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
+{
+   unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+
+   addr += n;
+   if (regs_within_kernel_stack(regs, (unsigned long)addr))

If the @addr fall in the interrupt stack, the regs_within_kernel_stack()
will return true. But Is it what we want?



Yes, I think it is.  The function is used in regs_get_kernel_stack_nth() 
to make sure the data being asked for (based on the pt_regs saved stack 
pointer) is actually on the stack, whether it's "kernel" stack or "irq" 
stack.


Thanks,
-dl

Re: [PATCH v12 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

[David Long]

On 05/17/2016 05:14 AM, Huang Shijie wrote:

On Wed, Apr 27, 2016 at 02:52:56PM -0400, David Long wrote:

From: "David A. Long" 
+/**
+ * regs_within_kernel_stack() - check the address in the stack
+ * @regs:  pt_regs which contains kernel stack pointer.
+ * @addr:  address which is checked.
+ *
+ * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
+ * If @addr is within the kernel stack, it returns true. If not, returns false.
+ */
+bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
+{
+   return ((addr & ~(THREAD_SIZE - 1))  ==
+   (kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1))) ||
+   on_irq_stack(addr, raw_smp_processor_id());
+}
+
+/**
+ * regs_get_kernel_stack_nth() - get Nth entry of the stack
+ * @regs:  pt_regs which contains kernel stack pointer.
+ * @n: stack entry number.
+ *
+ * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
+ * is specified by @regs. If the @n th entry is NOT in the kernel stack,
+ * this returns 0.
+ */_
+unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
+{
+   unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+
+   addr += n;
+   if (regs_within_kernel_stack(regs, (unsigned long)addr))

If the @addr fall in the interrupt stack, the regs_within_kernel_stack()
will return true. But Is it what we want?



Yes, I think it is.  The function is used in regs_get_kernel_stack_nth() 
to make sure the data being asked for (based on the pt_regs saved stack 
pointer) is actually on the stack, whether it's "kernel" stack or "irq" 
stack.


Thanks,
-dl

Re: [PATCH v3 3/5] mmc: core: implement enhanced strobe support

[Shawn Lin]

Hi

在 2016-5-20 11:54, Jaehoon Chung 写道:

On 05/20/2016 12:15 PM, Shawn Lin wrote:

Hi

在 2016-5-20 10:45, Jaehoon Chung 写道:

On 05/10/2016 06:09 PM, Shawn Lin wrote:

Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.

Signed-off-by: Shawn Lin 
---

Changes in v3: None
Changes in v2: None

   drivers/mmc/core/bus.c   |  3 +-
   drivers/mmc/core/core.c  |  8 +
   drivers/mmc/core/mmc.c   | 79 
++--
   include/linux/mmc/card.h |  1 +
   include/linux/mmc/host.h | 11 +++
   include/linux/mmc/mmc.h  |  3 ++
   6 files changed, 102 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 4bc48f1..7e94b9d 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -332,12 +332,13 @@ int mmc_add_card(struct mmc_card *card)
   mmc_card_ddr52(card) ? "DDR " : "",
   type);
   } else {
-pr_info("%s: new %s%s%s%s%s card at address %04x\n",
+pr_info("%s: new %s%s%s%s%s%s card at address %04x\n",
   mmc_hostname(card->host),
   mmc_card_uhs(card) ? "ultra high speed " :
   (mmc_card_hs(card) ? "high speed " : ""),
   mmc_card_hs400(card) ? "HS400 " :
   (mmc_card_hs200(card) ? "HS200 " : ""),
+mmc_card_hs400es(card) ? "Enhanced strobe" : "",
   mmc_card_ddr52(card) ? "DDR " : "",
   uhs_bus_speed_mode, type, card->rca);
   }
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 99275e4..a559501 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1127,6 +1127,14 @@ void mmc_set_initial_state(struct mmc_host *host)
   host->ios.bus_width = MMC_BUS_WIDTH_1;
   host->ios.timing = MMC_TIMING_LEGACY;
   host->ios.drv_type = 0;
+host->ios.enhanced_strobe = false;
+
+/*
+ * Make sure we are in non-enhanced strobe mode before we
+ * actually enable it in ext_csd.
+ */
+if (host->ops->hs400_enhanced_strobe)
+host->ops->hs400_enhanced_strobe(host, >ios);

   mmc_set_ios(host);
   }
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f99c47e..c2d1981 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -235,6 +235,11 @@ static void mmc_select_card_type(struct mmc_card *card)
   avail_type |= EXT_CSD_CARD_TYPE_HS400_1_2V;
   }

+if ((caps2 & MMC_CAP2_HS400_ES) &&
+card->ext_csd.strobe_support &&
+(card_type & EXT_CSD_CARD_TYPE_HS400))
+avail_type |= EXT_CSD_CARD_TYPE_HS400ES;


Does it need to check whether support HS400_1.8V/1.2V or not?
It should be more stable than now.



Ahh, right.
I need to add "avail_type & EXT_CSD_CARD_TYPE_HS400" instead of
"card_type & EXT_CSD_CARD_TYPE_HS400"... because if "avail_type &
EXT_CSD_CARD_TYPE_HS400" is true, it implies that "card_type & 
EXT_CSD_CARD_TYPE_HS400" must be true.


Otherwise, you can check or add the capabilities in the parse_of_mmc().
It can choose according to your preference. :)

Anyway, i have tested your patches..If you send the patch V4, i will also test.


Thanks for testing. I will cc you when pushing V4.



Best Regards,
Jaehoon Chung




Thansk for catching this!



if (avail_type & (EXT_CSD_CARD_TYPE_HS400_1.8V | EXT_CSD_CARD_TYPE_HS400_1.2V)) 
{
 if ((cap2 & MMC_CAP2_HS400_ES) && ...
}

how about this?

Best Regards,
Jaehoon Chung


+
   card->ext_csd.hs_max_dtr = hs_max_dtr;
   card->ext_csd.hs200_max_dtr = hs200_max_dtr;
   card->mmc_avail_type = avail_type;
@@ -383,6 +388,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
   mmc_card_set_blockaddr(card);
   }

+card->ext_csd.strobe_support = ext_csd[EXT_CSD_STROBE_SUPPORT];
   card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
   mmc_select_card_type(card);

@@ -1216,6 +1222,73 @@ out_err:
   return err;
   }

+static int mmc_select_hs400es(struct mmc_card *card)
+{
+struct mmc_host *host = card->host;
+int err = 0;
+u8 val;
+
+err = mmc_select_bus_width(card);
+if (IS_ERR_VALUE(err))
+goto out_err;
+
+/* Switch card to HS mode */
+err = mmc_select_hs(card);
+if (err) {
+pr_err("%s: switch to high-speed failed, err:%d\n",
+mmc_hostname(host), err);
+goto out_err;
+}
+
+err = mmc_switch_status(card);
+if (err)
+goto out_err;
+
+/* Switch card to DDR with strobe bit */
+val = EXT_CSD_DDR_BUS_WIDTH_8 | EXT_CSD_BUS_WIDTH_STROBE;
+err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_BUS_WIDTH,
+ val,
+ 

Re: [PATCH v3 3/5] mmc: core: implement enhanced strobe support

[Shawn Lin]

Hi

在 2016-5-20 11:54, Jaehoon Chung 写道:

On 05/20/2016 12:15 PM, Shawn Lin wrote:

Hi

在 2016-5-20 10:45, Jaehoon Chung 写道:

On 05/10/2016 06:09 PM, Shawn Lin wrote:

Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.

Signed-off-by: Shawn Lin 
---

Changes in v3: None
Changes in v2: None

   drivers/mmc/core/bus.c   |  3 +-
   drivers/mmc/core/core.c  |  8 +
   drivers/mmc/core/mmc.c   | 79 
++--
   include/linux/mmc/card.h |  1 +
   include/linux/mmc/host.h | 11 +++
   include/linux/mmc/mmc.h  |  3 ++
   6 files changed, 102 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 4bc48f1..7e94b9d 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -332,12 +332,13 @@ int mmc_add_card(struct mmc_card *card)
   mmc_card_ddr52(card) ? "DDR " : "",
   type);
   } else {
-pr_info("%s: new %s%s%s%s%s card at address %04x\n",
+pr_info("%s: new %s%s%s%s%s%s card at address %04x\n",
   mmc_hostname(card->host),
   mmc_card_uhs(card) ? "ultra high speed " :
   (mmc_card_hs(card) ? "high speed " : ""),
   mmc_card_hs400(card) ? "HS400 " :
   (mmc_card_hs200(card) ? "HS200 " : ""),
+mmc_card_hs400es(card) ? "Enhanced strobe" : "",
   mmc_card_ddr52(card) ? "DDR " : "",
   uhs_bus_speed_mode, type, card->rca);
   }
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 99275e4..a559501 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1127,6 +1127,14 @@ void mmc_set_initial_state(struct mmc_host *host)
   host->ios.bus_width = MMC_BUS_WIDTH_1;
   host->ios.timing = MMC_TIMING_LEGACY;
   host->ios.drv_type = 0;
+host->ios.enhanced_strobe = false;
+
+/*
+ * Make sure we are in non-enhanced strobe mode before we
+ * actually enable it in ext_csd.
+ */
+if (host->ops->hs400_enhanced_strobe)
+host->ops->hs400_enhanced_strobe(host, >ios);

   mmc_set_ios(host);
   }
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f99c47e..c2d1981 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -235,6 +235,11 @@ static void mmc_select_card_type(struct mmc_card *card)
   avail_type |= EXT_CSD_CARD_TYPE_HS400_1_2V;
   }

+if ((caps2 & MMC_CAP2_HS400_ES) &&
+card->ext_csd.strobe_support &&
+(card_type & EXT_CSD_CARD_TYPE_HS400))
+avail_type |= EXT_CSD_CARD_TYPE_HS400ES;


Does it need to check whether support HS400_1.8V/1.2V or not?
It should be more stable than now.



Ahh, right.
I need to add "avail_type & EXT_CSD_CARD_TYPE_HS400" instead of
"card_type & EXT_CSD_CARD_TYPE_HS400"... because if "avail_type &
EXT_CSD_CARD_TYPE_HS400" is true, it implies that "card_type & 
EXT_CSD_CARD_TYPE_HS400" must be true.


Otherwise, you can check or add the capabilities in the parse_of_mmc().
It can choose according to your preference. :)

Anyway, i have tested your patches..If you send the patch V4, i will also test.


Thanks for testing. I will cc you when pushing V4.



Best Regards,
Jaehoon Chung




Thansk for catching this!



if (avail_type & (EXT_CSD_CARD_TYPE_HS400_1.8V | EXT_CSD_CARD_TYPE_HS400_1.2V)) 
{
 if ((cap2 & MMC_CAP2_HS400_ES) && ...
}

how about this?

Best Regards,
Jaehoon Chung


+
   card->ext_csd.hs_max_dtr = hs_max_dtr;
   card->ext_csd.hs200_max_dtr = hs200_max_dtr;
   card->mmc_avail_type = avail_type;
@@ -383,6 +388,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
   mmc_card_set_blockaddr(card);
   }

+card->ext_csd.strobe_support = ext_csd[EXT_CSD_STROBE_SUPPORT];
   card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
   mmc_select_card_type(card);

@@ -1216,6 +1222,73 @@ out_err:
   return err;
   }

+static int mmc_select_hs400es(struct mmc_card *card)
+{
+struct mmc_host *host = card->host;
+int err = 0;
+u8 val;
+
+err = mmc_select_bus_width(card);
+if (IS_ERR_VALUE(err))
+goto out_err;
+
+/* Switch card to HS mode */
+err = mmc_select_hs(card);
+if (err) {
+pr_err("%s: switch to high-speed failed, err:%d\n",
+mmc_hostname(host), err);
+goto out_err;
+}
+
+err = mmc_switch_status(card);
+if (err)
+goto out_err;
+
+/* Switch card to DDR with strobe bit */
+val = EXT_CSD_DDR_BUS_WIDTH_8 | EXT_CSD_BUS_WIDTH_STROBE;
+err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_BUS_WIDTH,
+ val,
+ 

Re: 4.5-rc0 regression: GPRS breaks after very short while

[Sebastian Reichel]

Hi,

On Wed, May 18, 2016 at 10:12:51PM +0200, Pavel Machek wrote:
> > The last one only changes a comment, so not relevant, the other
> > two fix error handling during initialization and are most likely
> > also not the problem. Can you try to bisect the problem?
> 
> It will not be fun, but I guess it is doable. But before I start it
> would be good to know -- does it work for you?

I currently don't have a second SIM card with network access for my
dev phone, so I usually only test without gprs connection. As a
result I don't really know if longer data connection would work.

Also I'm quite busy until next weekend with other stuff. If you did
not find anything until then, I will do some testing/debugging.

-- Sebastian


signature.asc
Description: PGP signature

Re: 4.5-rc0 regression: GPRS breaks after very short while

[Sebastian Reichel]

Hi,

On Wed, May 18, 2016 at 10:12:51PM +0200, Pavel Machek wrote:
> > The last one only changes a comment, so not relevant, the other
> > two fix error handling during initialization and are most likely
> > also not the problem. Can you try to bisect the problem?
> 
> It will not be fun, but I guess it is doable. But before I start it
> would be good to know -- does it work for you?

I currently don't have a second SIM card with network access for my
dev phone, so I usually only test without gprs connection. As a
result I don't really know if longer data connection would work.

Also I'm quite busy until next weekend with other stuff. If you did
not find anything until then, I will do some testing/debugging.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCHv2] mm/zsmalloc: don't fail if can't create debugfs info

[Sergey Senozhatsky]

On (05/19/16 11:18), Dan Streetman wrote:
[..]
>   zs_stat_root = debugfs_create_dir("zsmalloc", NULL);
>   if (!zs_stat_root)
> - return -ENOMEM;
> -
> - return 0;
> + pr_warn("debugfs 'zsmalloc' stat dir creation failed\n");
>  }
>  
>  static void __exit zs_stat_exit(void)
> @@ -573,17 +575,19 @@ static const struct file_operations zs_stat_size_ops = {
>   .release= single_release,
>  };
>  
> -static int zs_pool_stat_create(struct zs_pool *pool, const char *name)
> +static void zs_pool_stat_create(struct zs_pool *pool, const char *name)
>  {
>   struct dentry *entry;
>  
> - if (!zs_stat_root)
> - return -ENODEV;
> + if (!zs_stat_root) {
> + pr_warn("no root stat dir, not creating <%s> stat dir\n", name);
> + return;
> + }

just a small nit, there are basically two warn messages now for
`!zs_stat_root':

debugfs 'zsmalloc' stat dir creation failed
no root stat dir, not creating <%s> stat dir

may be we need only one of them; but no strong opinions.

-ss

Re: [PATCHv2] mm/zsmalloc: don't fail if can't create debugfs info

[Sergey Senozhatsky]

On (05/19/16 11:18), Dan Streetman wrote:
[..]
>   zs_stat_root = debugfs_create_dir("zsmalloc", NULL);
>   if (!zs_stat_root)
> - return -ENOMEM;
> -
> - return 0;
> + pr_warn("debugfs 'zsmalloc' stat dir creation failed\n");
>  }
>  
>  static void __exit zs_stat_exit(void)
> @@ -573,17 +575,19 @@ static const struct file_operations zs_stat_size_ops = {
>   .release= single_release,
>  };
>  
> -static int zs_pool_stat_create(struct zs_pool *pool, const char *name)
> +static void zs_pool_stat_create(struct zs_pool *pool, const char *name)
>  {
>   struct dentry *entry;
>  
> - if (!zs_stat_root)
> - return -ENODEV;
> + if (!zs_stat_root) {
> + pr_warn("no root stat dir, not creating <%s> stat dir\n", name);
> + return;
> + }

just a small nit, there are basically two warn messages now for
`!zs_stat_root':

debugfs 'zsmalloc' stat dir creation failed
no root stat dir, not creating <%s> stat dir

may be we need only one of them; but no strong opinions.

-ss

Re: [rcu_sched stall] regression/miss-config ?

[Paul E. McKenney]

On Thu, May 19, 2016 at 04:45:26PM -0700, Santosh Shilimkar wrote:
> Hi Paul,
> 
> On 5/17/2016 12:15 PM, Paul E. McKenney wrote:
> >On Tue, May 17, 2016 at 06:46:22AM -0700, santosh.shilim...@oracle.com wrote:
> >>On 5/16/16 5:58 PM, Paul E. McKenney wrote:
> >>>On Mon, May 16, 2016 at 12:49:41PM -0700, Santosh Shilimkar wrote:
> On 5/16/2016 10:34 AM, Paul E. McKenney wrote:
> >On Mon, May 16, 2016 at 09:33:57AM -0700, Santosh Shilimkar wrote:
> >>
> >>[...]
> >>
> >Are you running CONFIG_NO_HZ_FULL=y?  If so, the problem might be that
> >you need more housekeeping CPUs than you currently have configured.
> >
> Yes, CONFIG_NO_HZ_FULL=y. Do you mean "CONFIG_NO_HZ_FULL_ALL=y" for
> book keeping. Seems like without that clock-event code will just use
> CPU0 for things like broadcasting which might become bottleneck.
> This could explain connect the hrtimer_interrupt() path getting slowed
> down because of book keeping bottleneck.
> 
> $cat .config | grep NO_HZ
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_NO_HZ_IDLE is not set
> CONFIG_NO_HZ_FULL=y
> # CONFIG_NO_HZ_FULL_ALL is not set
> # CONFIG_NO_HZ_FULL_SYSIDLE is not set
> CONFIG_NO_HZ=y
> # CONFIG_RCU_FAST_NO_HZ is not set
> >>>
> >>>Yes, CONFIG_NO_HZ_FULL_ALL=y would give you only one CPU for all
> >>>housekeeping tasks, including the RCU grace-period kthreads.  So you are
> >>>booting without any nohz_full boot parameter?  You can end up with the
> >>>same problem with CONFIG_NO_HZ_FULL=y and the nohz_full boot parameter
> >>>that you can with CONFIG_NO_HZ_FULL_ALL=y.
> >>>
> >>I see. Yes, the systems are booting without nohz_full boot parameter.
> >>Will try to add more CPUs to it & update the thread
> >>after the verification since it takes time to reproduce the issue.
> >>
> >>Thanks for discussion so far Paul. Its very insightful for me.
> >
> >Please let me know how things go with further testing, especially with
> >the priority setting.
> >
> Sorry for delay. I manage to get information about XEN usecase
> custom config as discussed above. To reduce variables, I disabled
> "CONFIG_NO_HZ_FULL" altogether. So the effective setting was:
> 
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_TREE_RCU_TRACE=y
> CONFIG_RCU_KTHREAD_PRIO=1
> CONFIG_RCU_CPU_STALL_TIMEOUT=21
> CONFIG_RCU_TRACE=y
> 
> Unfortunately the XEN test still failed. Log end of
> the email. This test(s) is bit peculiar though since
> its database running in VM with 1 or 2 CPUs. One of
> the suspect is because the database RT processes are
> hogging the CPU(s), kernel RCU thread is not getting chance
> to run which eventually results in stall. Does it
> make sense ?
> 
> Please note that its non-preempt kernel using RT processes. ;-)

If you have enough real-time processes to consume all CPU, you will
indeed starve the grace-period kthread, so what you see below would
then be expected behavior.

Try setting CONFIG_RCU_KTHREAD_PRIO to be larger than the real-time
priority of your processes.

Thanx, Paul

> # cat .config | grep PREEMPT
> CONFIG_PREEMPT_NOTIFIERS=y
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> # CONFIG_PREEMPT is not set
> 
> Regards,
> Santosh
> ...
> 
> rcu_sched kthread starved for 399032 jiffies!
> INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 0,
> t=462037 jiffies, g=11, c=118887, q=0)
> All QSes seen, last rcu_sched kthread activity 462037
> (4296277632-4295815595), jiffies_till_next_fqs=3, root ->qsmask 0x0
> ocssd.bin   R  running task0 15375  1 0x
>   8800ec003bc8 810a8581 81abf980
>  0001d068 8800ec003c28 810e9c98 
>  0086  0086 0082
> Call Trace:
>[] sched_show_task+0xb1/0x120
>  [] print_other_cpu_stall+0x288/0x2d0
>  [] __rcu_pending+0x180/0x230
>  [] rcu_check_callbacks+0x95/0x140
>  [] update_process_times+0x42/0x70
>  [] tick_sched_handle+0x39/0x80
>  [] tick_sched_timer+0x52/0xa0
>  [] __run_hrtimer+0x74/0x1d0
>  [] ? tick_nohz_handler+0xc0/0xc0
>  [] hrtimer_interrupt+0x102/0x240
>  [] xen_timer_interrupt+0x2e/0x130
>  [] ? add_interrupt_randomness+0x3a/0x1f0
>  [] ? store_cursor_blink+0xc0/0xc0
>  [] handle_irq_event_percpu+0x54/0x1b0
>  [] handle_percpu_irq+0x47/0x70
>  [] generic_handle_irq+0x27/0x40
>  [] evtchn_2l_handle_events+0x25a/0x260
>  [] ? __do_softirq+0x191/0x2f0
>  [] __xen_evtchn_do_upcall+0x4f/0x90
>  [] xen_evtchn_do_upcall+0x34/0x50
>  [] xen_hvm_callback_vector+0x6e/0x80
>  
> rcu_sched kthread starved for 462037 jiffies!
> 
> 

Re: [rcu_sched stall] regression/miss-config ?

[Paul E. McKenney]

On Thu, May 19, 2016 at 04:45:26PM -0700, Santosh Shilimkar wrote:
> Hi Paul,
> 
> On 5/17/2016 12:15 PM, Paul E. McKenney wrote:
> >On Tue, May 17, 2016 at 06:46:22AM -0700, santosh.shilim...@oracle.com wrote:
> >>On 5/16/16 5:58 PM, Paul E. McKenney wrote:
> >>>On Mon, May 16, 2016 at 12:49:41PM -0700, Santosh Shilimkar wrote:
> On 5/16/2016 10:34 AM, Paul E. McKenney wrote:
> >On Mon, May 16, 2016 at 09:33:57AM -0700, Santosh Shilimkar wrote:
> >>
> >>[...]
> >>
> >Are you running CONFIG_NO_HZ_FULL=y?  If so, the problem might be that
> >you need more housekeeping CPUs than you currently have configured.
> >
> Yes, CONFIG_NO_HZ_FULL=y. Do you mean "CONFIG_NO_HZ_FULL_ALL=y" for
> book keeping. Seems like without that clock-event code will just use
> CPU0 for things like broadcasting which might become bottleneck.
> This could explain connect the hrtimer_interrupt() path getting slowed
> down because of book keeping bottleneck.
> 
> $cat .config | grep NO_HZ
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_NO_HZ_IDLE is not set
> CONFIG_NO_HZ_FULL=y
> # CONFIG_NO_HZ_FULL_ALL is not set
> # CONFIG_NO_HZ_FULL_SYSIDLE is not set
> CONFIG_NO_HZ=y
> # CONFIG_RCU_FAST_NO_HZ is not set
> >>>
> >>>Yes, CONFIG_NO_HZ_FULL_ALL=y would give you only one CPU for all
> >>>housekeeping tasks, including the RCU grace-period kthreads.  So you are
> >>>booting without any nohz_full boot parameter?  You can end up with the
> >>>same problem with CONFIG_NO_HZ_FULL=y and the nohz_full boot parameter
> >>>that you can with CONFIG_NO_HZ_FULL_ALL=y.
> >>>
> >>I see. Yes, the systems are booting without nohz_full boot parameter.
> >>Will try to add more CPUs to it & update the thread
> >>after the verification since it takes time to reproduce the issue.
> >>
> >>Thanks for discussion so far Paul. Its very insightful for me.
> >
> >Please let me know how things go with further testing, especially with
> >the priority setting.
> >
> Sorry for delay. I manage to get information about XEN usecase
> custom config as discussed above. To reduce variables, I disabled
> "CONFIG_NO_HZ_FULL" altogether. So the effective setting was:
> 
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_TREE_RCU_TRACE=y
> CONFIG_RCU_KTHREAD_PRIO=1
> CONFIG_RCU_CPU_STALL_TIMEOUT=21
> CONFIG_RCU_TRACE=y
> 
> Unfortunately the XEN test still failed. Log end of
> the email. This test(s) is bit peculiar though since
> its database running in VM with 1 or 2 CPUs. One of
> the suspect is because the database RT processes are
> hogging the CPU(s), kernel RCU thread is not getting chance
> to run which eventually results in stall. Does it
> make sense ?
> 
> Please note that its non-preempt kernel using RT processes. ;-)

If you have enough real-time processes to consume all CPU, you will
indeed starve the grace-period kthread, so what you see below would
then be expected behavior.

Try setting CONFIG_RCU_KTHREAD_PRIO to be larger than the real-time
priority of your processes.

Thanx, Paul

> # cat .config | grep PREEMPT
> CONFIG_PREEMPT_NOTIFIERS=y
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> # CONFIG_PREEMPT is not set
> 
> Regards,
> Santosh
> ...
> 
> rcu_sched kthread starved for 399032 jiffies!
> INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 0,
> t=462037 jiffies, g=11, c=118887, q=0)
> All QSes seen, last rcu_sched kthread activity 462037
> (4296277632-4295815595), jiffies_till_next_fqs=3, root ->qsmask 0x0
> ocssd.bin   R  running task0 15375  1 0x
>   8800ec003bc8 810a8581 81abf980
>  0001d068 8800ec003c28 810e9c98 
>  0086  0086 0082
> Call Trace:
>[] sched_show_task+0xb1/0x120
>  [] print_other_cpu_stall+0x288/0x2d0
>  [] __rcu_pending+0x180/0x230
>  [] rcu_check_callbacks+0x95/0x140
>  [] update_process_times+0x42/0x70
>  [] tick_sched_handle+0x39/0x80
>  [] tick_sched_timer+0x52/0xa0
>  [] __run_hrtimer+0x74/0x1d0
>  [] ? tick_nohz_handler+0xc0/0xc0
>  [] hrtimer_interrupt+0x102/0x240
>  [] xen_timer_interrupt+0x2e/0x130
>  [] ? add_interrupt_randomness+0x3a/0x1f0
>  [] ? store_cursor_blink+0xc0/0xc0
>  [] handle_irq_event_percpu+0x54/0x1b0
>  [] handle_percpu_irq+0x47/0x70
>  [] generic_handle_irq+0x27/0x40
>  [] evtchn_2l_handle_events+0x25a/0x260
>  [] ? __do_softirq+0x191/0x2f0
>  [] __xen_evtchn_do_upcall+0x4f/0x90
>  [] xen_evtchn_do_upcall+0x34/0x50
>  [] xen_hvm_callback_vector+0x6e/0x80
>  
> rcu_sched kthread starved for 462037 jiffies!
> 
> 

Re: [GIT PULL] ARC updates for 4.7-rc1

[Vineet Gupta]

On Friday 20 May 2016 02:04 AM, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 11:24 PM, Vineet Gupta
>  wrote:
>>
>> The highlight is support for EZChip (now Mellanox) NPS-400 network processor 
>> [..]
> 
> Oh, and that brought in the
> 
> drivers/irqchip/irq-eznps.c
> 
> driver that is compile-test enabled.
> 
> And that driver is not 64-bit clean:
> 
>   In file included from drivers/irqchip/irq-eznps.c:39:0:
>   include/soc/nps/common.h: In function ‘nps_host_reg_non_cl’:
>   include/soc/nps/common.h:148:9: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]
> return (void *)reg_address.value;
>^
>   include/soc/nps/common.h: In function ‘nps_host_reg’:
>   include/soc/nps/common.h:162:9: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]
> return (void *)reg_address.value;
>^
> 
> so it needs to either be disabled or fixed. Annoying everybody else
> with warnings is not an option.

Sorry about that. We already have a fix from Arnd which was just waiting for
things to settle down per discussion here:

https://lkml.org/lkml/2016/5/13/132

I guess it was wrong call on my part to not include it in this pull request.

Another lesson learnt to not add other subsys stuff via your tree. I should have
merged the new soc header in 4.6 and paved way for NPS changes via other trees.
Live and learn !

Is inline patch below OK or else I can send a pull request:

--->
>From 69d911ecf3e2a0dd6bf99b2e5c36fbabf09dfa75 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann 
Date: Thu, 12 May 2016 23:03:35 +0200
Subject: [PATCH] irqchip: nps: add 64BIT dependency

The newly added nps irqchip driver causes build warnings on ARM64.

include/soc/nps/common.h: In function 'nps_host_reg_non_cl':
include/soc/nps/common.h:148:9: warning: cast to pointer from integer of 
different
size [-Wint-to-pointer-cast]

As the driver is only used on ARC, we don't need to see it without
COMPILE_TEST elsewhere, and we can avoid the warnings by only
building on 32-bit architectures even with CONFIG_COMPILE_TEST.

Acked-by: Marc Zyngier 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Vineet Gupta 
---
 drivers/irqchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 1ab632a94db3..8e97c2ab560c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -247,6 +247,7 @@ config MVEBU_ODMI

 config EZNPS_GIC
bool "NPS400 Global Interrupt Manager (GIM)"
+   depends on ARC || (COMPILE_TEST && !64BIT)
select IRQ_DOMAIN
help
  Support the EZchip NPS400 global interrupt controller
-- 
2.5.0

Re: [GIT PULL] ARC updates for 4.7-rc1

[Vineet Gupta]

On Friday 20 May 2016 02:04 AM, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 11:24 PM, Vineet Gupta
>  wrote:
>>
>> The highlight is support for EZChip (now Mellanox) NPS-400 network processor 
>> [..]
> 
> Oh, and that brought in the
> 
> drivers/irqchip/irq-eznps.c
> 
> driver that is compile-test enabled.
> 
> And that driver is not 64-bit clean:
> 
>   In file included from drivers/irqchip/irq-eznps.c:39:0:
>   include/soc/nps/common.h: In function ‘nps_host_reg_non_cl’:
>   include/soc/nps/common.h:148:9: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]
> return (void *)reg_address.value;
>^
>   include/soc/nps/common.h: In function ‘nps_host_reg’:
>   include/soc/nps/common.h:162:9: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]
> return (void *)reg_address.value;
>^
> 
> so it needs to either be disabled or fixed. Annoying everybody else
> with warnings is not an option.

Sorry about that. We already have a fix from Arnd which was just waiting for
things to settle down per discussion here:

https://lkml.org/lkml/2016/5/13/132

I guess it was wrong call on my part to not include it in this pull request.

Another lesson learnt to not add other subsys stuff via your tree. I should have
merged the new soc header in 4.6 and paved way for NPS changes via other trees.
Live and learn !

Is inline patch below OK or else I can send a pull request:

--->
>From 69d911ecf3e2a0dd6bf99b2e5c36fbabf09dfa75 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann 
Date: Thu, 12 May 2016 23:03:35 +0200
Subject: [PATCH] irqchip: nps: add 64BIT dependency

The newly added nps irqchip driver causes build warnings on ARM64.

include/soc/nps/common.h: In function 'nps_host_reg_non_cl':
include/soc/nps/common.h:148:9: warning: cast to pointer from integer of 
different
size [-Wint-to-pointer-cast]

As the driver is only used on ARC, we don't need to see it without
COMPILE_TEST elsewhere, and we can avoid the warnings by only
building on 32-bit architectures even with CONFIG_COMPILE_TEST.

Acked-by: Marc Zyngier 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Vineet Gupta 
---
 drivers/irqchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 1ab632a94db3..8e97c2ab560c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -247,6 +247,7 @@ config MVEBU_ODMI

 config EZNPS_GIC
bool "NPS400 Global Interrupt Manager (GIM)"
+   depends on ARC || (COMPILE_TEST && !64BIT)
select IRQ_DOMAIN
help
  Support the EZchip NPS400 global interrupt controller
-- 
2.5.0

linux-next: manual merge of the akpm-current tree with the dax-misc tree

[Stephen Rothwell]

Hi Andrew,

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

  include/linux/dax.h

between commit:

  bc2466e42573 ("dax: Use radix tree entry lock to protect cow faults")

from the dax-misc tree and commit:

  c2ce6adc69c8 ("dax: add dax_get_unmapped_area for pmd mappings")

from the akpm-current tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/dax.h
index 43d5f0b799c7,0cd64c152361..
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@@ -21,36 -17,26 +21,39 @@@ void dax_wake_mapping_entry_waiter(stru
  
  #ifdef CONFIG_FS_DAX
  struct page *read_dax_sector(struct block_device *bdev, sector_t n);
 +void dax_unlock_mapping_entry(struct address_space *mapping, pgoff_t index);
 +int __dax_zero_page_range(struct block_device *bdev, sector_t sector,
 +  unsigned int offset, unsigned int length);
+ unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
+   unsigned long len, unsigned long pgoff, unsigned long flags);
  #else
  static inline struct page *read_dax_sector(struct block_device *bdev,
sector_t n)
  {
return ERR_PTR(-ENXIO);
  }
 +/* Shouldn't ever be called when dax is disabled. */
 +static inline void dax_unlock_mapping_entry(struct address_space *mapping,
 +  pgoff_t index)
 +{
 +  BUG();
 +}
 +static inline int __dax_zero_page_range(struct block_device *bdev,
 +  sector_t sector, unsigned int offset, unsigned int length)
 +{
 +  return -ENXIO;
 +}
+ #define dax_get_unmapped_area NULL
  #endif
  
 -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 +#if defined(CONFIG_TRANSPARENT_HUGEPAGE)
  int dax_pmd_fault(struct vm_area_struct *, unsigned long addr, pmd_t *,
 -  unsigned int flags, get_block_t, dax_iodone_t);
 +  unsigned int flags, get_block_t);
  int __dax_pmd_fault(struct vm_area_struct *, unsigned long addr, pmd_t *,
 -  unsigned int flags, get_block_t, dax_iodone_t);
 +  unsigned int flags, get_block_t);
  #else
  static inline int dax_pmd_fault(struct vm_area_struct *vma, unsigned long 
addr,
 -  pmd_t *pmd, unsigned int flags, get_block_t gb,
 -  dax_iodone_t di)
 +  pmd_t *pmd, unsigned int flags, get_block_t gb)
  {
return VM_FAULT_FALLBACK;
  }

linux-next: manual merge of the akpm-current tree with the dax-misc tree

[Stephen Rothwell]

Hi Andrew,

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

  include/linux/dax.h

between commit:

  bc2466e42573 ("dax: Use radix tree entry lock to protect cow faults")

from the dax-misc tree and commit:

  c2ce6adc69c8 ("dax: add dax_get_unmapped_area for pmd mappings")

from the akpm-current tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/dax.h
index 43d5f0b799c7,0cd64c152361..
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@@ -21,36 -17,26 +21,39 @@@ void dax_wake_mapping_entry_waiter(stru
  
  #ifdef CONFIG_FS_DAX
  struct page *read_dax_sector(struct block_device *bdev, sector_t n);
 +void dax_unlock_mapping_entry(struct address_space *mapping, pgoff_t index);
 +int __dax_zero_page_range(struct block_device *bdev, sector_t sector,
 +  unsigned int offset, unsigned int length);
+ unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
+   unsigned long len, unsigned long pgoff, unsigned long flags);
  #else
  static inline struct page *read_dax_sector(struct block_device *bdev,
sector_t n)
  {
return ERR_PTR(-ENXIO);
  }
 +/* Shouldn't ever be called when dax is disabled. */
 +static inline void dax_unlock_mapping_entry(struct address_space *mapping,
 +  pgoff_t index)
 +{
 +  BUG();
 +}
 +static inline int __dax_zero_page_range(struct block_device *bdev,
 +  sector_t sector, unsigned int offset, unsigned int length)
 +{
 +  return -ENXIO;
 +}
+ #define dax_get_unmapped_area NULL
  #endif
  
 -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 +#if defined(CONFIG_TRANSPARENT_HUGEPAGE)
  int dax_pmd_fault(struct vm_area_struct *, unsigned long addr, pmd_t *,
 -  unsigned int flags, get_block_t, dax_iodone_t);
 +  unsigned int flags, get_block_t);
  int __dax_pmd_fault(struct vm_area_struct *, unsigned long addr, pmd_t *,
 -  unsigned int flags, get_block_t, dax_iodone_t);
 +  unsigned int flags, get_block_t);
  #else
  static inline int dax_pmd_fault(struct vm_area_struct *vma, unsigned long 
addr,
 -  pmd_t *pmd, unsigned int flags, get_block_t gb,
 -  dax_iodone_t di)
 +  pmd_t *pmd, unsigned int flags, get_block_t gb)
  {
return VM_FAULT_FALLBACK;
  }

Re: [PATCH v3 3/5] mmc: core: implement enhanced strobe support

[Jaehoon Chung]

On 05/20/2016 12:15 PM, Shawn Lin wrote:
> Hi
> 
> 在 2016-5-20 10:45, Jaehoon Chung 写道:
>> On 05/10/2016 06:09 PM, Shawn Lin wrote:
>>> Controllers use data strobe line to latch data from devices
>>> under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
>>> introduces enhanced strobe mode for latching cmd response from
>>> emmc devices to host controllers. This new feature is optional,
>>> so it depends both on device's cap and host's cap to decide
>>> whether to use it or not.
>>>
>>> Signed-off-by: Shawn Lin 
>>> ---
>>>
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>>   drivers/mmc/core/bus.c   |  3 +-
>>>   drivers/mmc/core/core.c  |  8 +
>>>   drivers/mmc/core/mmc.c   | 79 
>>> ++--
>>>   include/linux/mmc/card.h |  1 +
>>>   include/linux/mmc/host.h | 11 +++
>>>   include/linux/mmc/mmc.h  |  3 ++
>>>   6 files changed, 102 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>>> index 4bc48f1..7e94b9d 100644
>>> --- a/drivers/mmc/core/bus.c
>>> +++ b/drivers/mmc/core/bus.c
>>> @@ -332,12 +332,13 @@ int mmc_add_card(struct mmc_card *card)
>>>   mmc_card_ddr52(card) ? "DDR " : "",
>>>   type);
>>>   } else {
>>> -pr_info("%s: new %s%s%s%s%s card at address %04x\n",
>>> +pr_info("%s: new %s%s%s%s%s%s card at address %04x\n",
>>>   mmc_hostname(card->host),
>>>   mmc_card_uhs(card) ? "ultra high speed " :
>>>   (mmc_card_hs(card) ? "high speed " : ""),
>>>   mmc_card_hs400(card) ? "HS400 " :
>>>   (mmc_card_hs200(card) ? "HS200 " : ""),
>>> +mmc_card_hs400es(card) ? "Enhanced strobe" : "",
>>>   mmc_card_ddr52(card) ? "DDR " : "",
>>>   uhs_bus_speed_mode, type, card->rca);
>>>   }
>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>> index 99275e4..a559501 100644
>>> --- a/drivers/mmc/core/core.c
>>> +++ b/drivers/mmc/core/core.c
>>> @@ -1127,6 +1127,14 @@ void mmc_set_initial_state(struct mmc_host *host)
>>>   host->ios.bus_width = MMC_BUS_WIDTH_1;
>>>   host->ios.timing = MMC_TIMING_LEGACY;
>>>   host->ios.drv_type = 0;
>>> +host->ios.enhanced_strobe = false;
>>> +
>>> +/*
>>> + * Make sure we are in non-enhanced strobe mode before we
>>> + * actually enable it in ext_csd.
>>> + */
>>> +if (host->ops->hs400_enhanced_strobe)
>>> +host->ops->hs400_enhanced_strobe(host, >ios);
>>>
>>>   mmc_set_ios(host);
>>>   }
>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>>> index f99c47e..c2d1981 100644
>>> --- a/drivers/mmc/core/mmc.c
>>> +++ b/drivers/mmc/core/mmc.c
>>> @@ -235,6 +235,11 @@ static void mmc_select_card_type(struct mmc_card *card)
>>>   avail_type |= EXT_CSD_CARD_TYPE_HS400_1_2V;
>>>   }
>>>
>>> +if ((caps2 & MMC_CAP2_HS400_ES) &&
>>> +card->ext_csd.strobe_support &&
>>> +(card_type & EXT_CSD_CARD_TYPE_HS400))
>>> +avail_type |= EXT_CSD_CARD_TYPE_HS400ES;
>>
>> Does it need to check whether support HS400_1.8V/1.2V or not?
>> It should be more stable than now.
>>
> 
> Ahh, right.
> I need to add "avail_type & EXT_CSD_CARD_TYPE_HS400" instead of
> "card_type & EXT_CSD_CARD_TYPE_HS400"... because if "avail_type &
> EXT_CSD_CARD_TYPE_HS400" is true, it implies that "card_type & 
> EXT_CSD_CARD_TYPE_HS400" must be true.

Otherwise, you can check or add the capabilities in the parse_of_mmc().
It can choose according to your preference. :)

Anyway, i have tested your patches..If you send the patch V4, i will also test.

Best Regards,
Jaehoon Chung

> 
> 
> Thansk for catching this!
> 
> 
>> if (avail_type & (EXT_CSD_CARD_TYPE_HS400_1.8V | 
>> EXT_CSD_CARD_TYPE_HS400_1.2V)) {
>> if ((cap2 & MMC_CAP2_HS400_ES) && ...
>> }
>>
>> how about this?
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>> +
>>>   card->ext_csd.hs_max_dtr = hs_max_dtr;
>>>   card->ext_csd.hs200_max_dtr = hs200_max_dtr;
>>>   card->mmc_avail_type = avail_type;
>>> @@ -383,6 +388,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
>>> *ext_csd)
>>>   mmc_card_set_blockaddr(card);
>>>   }
>>>
>>> +card->ext_csd.strobe_support = ext_csd[EXT_CSD_STROBE_SUPPORT];
>>>   card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>>>   mmc_select_card_type(card);
>>>
>>> @@ -1216,6 +1222,73 @@ out_err:
>>>   return err;
>>>   }
>>>
>>> +static int mmc_select_hs400es(struct mmc_card *card)
>>> +{
>>> +struct mmc_host *host = card->host;
>>> +int err = 0;
>>> +u8 val;
>>> +
>>> +err = mmc_select_bus_width(card);
>>> +if (IS_ERR_VALUE(err))
>>> +goto out_err;
>>> +
>>> +/* Switch card to HS mode */
>>> +err = mmc_select_hs(card);
>>> +if (err) {
>>> +pr_err("%s: switch to high-speed failed, err:%d\n",
>>> +mmc_hostname(host), err);
>>> +  

Re: [PATCH v3 3/5] mmc: core: implement enhanced strobe support

[Jaehoon Chung]

On 05/20/2016 12:15 PM, Shawn Lin wrote:
> Hi
> 
> 在 2016-5-20 10:45, Jaehoon Chung 写道:
>> On 05/10/2016 06:09 PM, Shawn Lin wrote:
>>> Controllers use data strobe line to latch data from devices
>>> under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
>>> introduces enhanced strobe mode for latching cmd response from
>>> emmc devices to host controllers. This new feature is optional,
>>> so it depends both on device's cap and host's cap to decide
>>> whether to use it or not.
>>>
>>> Signed-off-by: Shawn Lin 
>>> ---
>>>
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>>   drivers/mmc/core/bus.c   |  3 +-
>>>   drivers/mmc/core/core.c  |  8 +
>>>   drivers/mmc/core/mmc.c   | 79 
>>> ++--
>>>   include/linux/mmc/card.h |  1 +
>>>   include/linux/mmc/host.h | 11 +++
>>>   include/linux/mmc/mmc.h  |  3 ++
>>>   6 files changed, 102 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>>> index 4bc48f1..7e94b9d 100644
>>> --- a/drivers/mmc/core/bus.c
>>> +++ b/drivers/mmc/core/bus.c
>>> @@ -332,12 +332,13 @@ int mmc_add_card(struct mmc_card *card)
>>>   mmc_card_ddr52(card) ? "DDR " : "",
>>>   type);
>>>   } else {
>>> -pr_info("%s: new %s%s%s%s%s card at address %04x\n",
>>> +pr_info("%s: new %s%s%s%s%s%s card at address %04x\n",
>>>   mmc_hostname(card->host),
>>>   mmc_card_uhs(card) ? "ultra high speed " :
>>>   (mmc_card_hs(card) ? "high speed " : ""),
>>>   mmc_card_hs400(card) ? "HS400 " :
>>>   (mmc_card_hs200(card) ? "HS200 " : ""),
>>> +mmc_card_hs400es(card) ? "Enhanced strobe" : "",
>>>   mmc_card_ddr52(card) ? "DDR " : "",
>>>   uhs_bus_speed_mode, type, card->rca);
>>>   }
>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>> index 99275e4..a559501 100644
>>> --- a/drivers/mmc/core/core.c
>>> +++ b/drivers/mmc/core/core.c
>>> @@ -1127,6 +1127,14 @@ void mmc_set_initial_state(struct mmc_host *host)
>>>   host->ios.bus_width = MMC_BUS_WIDTH_1;
>>>   host->ios.timing = MMC_TIMING_LEGACY;
>>>   host->ios.drv_type = 0;
>>> +host->ios.enhanced_strobe = false;
>>> +
>>> +/*
>>> + * Make sure we are in non-enhanced strobe mode before we
>>> + * actually enable it in ext_csd.
>>> + */
>>> +if (host->ops->hs400_enhanced_strobe)
>>> +host->ops->hs400_enhanced_strobe(host, >ios);
>>>
>>>   mmc_set_ios(host);
>>>   }
>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>>> index f99c47e..c2d1981 100644
>>> --- a/drivers/mmc/core/mmc.c
>>> +++ b/drivers/mmc/core/mmc.c
>>> @@ -235,6 +235,11 @@ static void mmc_select_card_type(struct mmc_card *card)
>>>   avail_type |= EXT_CSD_CARD_TYPE_HS400_1_2V;
>>>   }
>>>
>>> +if ((caps2 & MMC_CAP2_HS400_ES) &&
>>> +card->ext_csd.strobe_support &&
>>> +(card_type & EXT_CSD_CARD_TYPE_HS400))
>>> +avail_type |= EXT_CSD_CARD_TYPE_HS400ES;
>>
>> Does it need to check whether support HS400_1.8V/1.2V or not?
>> It should be more stable than now.
>>
> 
> Ahh, right.
> I need to add "avail_type & EXT_CSD_CARD_TYPE_HS400" instead of
> "card_type & EXT_CSD_CARD_TYPE_HS400"... because if "avail_type &
> EXT_CSD_CARD_TYPE_HS400" is true, it implies that "card_type & 
> EXT_CSD_CARD_TYPE_HS400" must be true.

Otherwise, you can check or add the capabilities in the parse_of_mmc().
It can choose according to your preference. :)

Anyway, i have tested your patches..If you send the patch V4, i will also test.

Best Regards,
Jaehoon Chung

> 
> 
> Thansk for catching this!
> 
> 
>> if (avail_type & (EXT_CSD_CARD_TYPE_HS400_1.8V | 
>> EXT_CSD_CARD_TYPE_HS400_1.2V)) {
>> if ((cap2 & MMC_CAP2_HS400_ES) && ...
>> }
>>
>> how about this?
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>> +
>>>   card->ext_csd.hs_max_dtr = hs_max_dtr;
>>>   card->ext_csd.hs200_max_dtr = hs200_max_dtr;
>>>   card->mmc_avail_type = avail_type;
>>> @@ -383,6 +388,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
>>> *ext_csd)
>>>   mmc_card_set_blockaddr(card);
>>>   }
>>>
>>> +card->ext_csd.strobe_support = ext_csd[EXT_CSD_STROBE_SUPPORT];
>>>   card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>>>   mmc_select_card_type(card);
>>>
>>> @@ -1216,6 +1222,73 @@ out_err:
>>>   return err;
>>>   }
>>>
>>> +static int mmc_select_hs400es(struct mmc_card *card)
>>> +{
>>> +struct mmc_host *host = card->host;
>>> +int err = 0;
>>> +u8 val;
>>> +
>>> +err = mmc_select_bus_width(card);
>>> +if (IS_ERR_VALUE(err))
>>> +goto out_err;
>>> +
>>> +/* Switch card to HS mode */
>>> +err = mmc_select_hs(card);
>>> +if (err) {
>>> +pr_err("%s: switch to high-speed failed, err:%d\n",
>>> +mmc_hostname(host), err);
>>> +goto out_err;
>>> + 

crosstool builds - https://www.kernel.org/pub/tools/crosstool/

[Jon Masters]

Hi Tony,

I'm wondering whether you know of anyone who has picked up where you
left off, building cross toolchains for various and sundry alternative
architectures? I wanted to download an IA64 compiler recently (really)
and noticed that the most recent builds were against GCC 4.6.3.

Thanks in advance, and for making these before!

Jon.

-- 
Computer Architect

crosstool builds - https://www.kernel.org/pub/tools/crosstool/

[Jon Masters]

Hi Tony,

I'm wondering whether you know of anyone who has picked up where you
left off, building cross toolchains for various and sundry alternative
architectures? I wanted to download an IA64 compiler recently (really)
and noticed that the most recent builds were against GCC 4.6.3.

Thanks in advance, and for making these before!

Jon.

-- 
Computer Architect

Re: [PATCH RFC] user-namespaced file capabilities - now with more magic

[Serge E. Hallyn]

Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
> On Wed, 2016-05-18 at 16:57 -0500, Serge E. Hallyn wrote:
> > This patch introduces a new security.nscapability xattr.  It
> > is mostly like security.capability, but also lists a 'rootid'.
> > This is the uid_t (in init_user_ns) of the root id (uid 0 in a
> > namespace) in whose namespaces the file capabilities may take
> > effect.
> > 
> > A privileged (cap_setfcap) process in the initial user ns may
> > set and read this xattr directly.  However, its real intent is
> > to be used as a transparent fallback in user namespaces.
> > 
> > Root in a user ns cannot be trusted to write security.capability
> > xattrs, because any user on the host could map his own uid to root
> > in a namespace, write the xattr, and execute the file with privilege
> > on the host.
> > 
> > With this patch, when root in a user ns asks to write security.capability,
> > the kernel will transparently write a security.nscapability xattr
> > instead, filling in the kuid of the calling user's root uid.  Subsequently,
> > any task executing the file which has the noted k_uid as its root uid,
> > or which is in a descendent user_ns of such a user_ns, will run the
> > file with capabilities.
> > 
> > When reading the security.capability xattr from a non-init user_ns, a valid
> > security.nscapability will be shown if it exists.  Such a task is not
> > allowed to read security.nscapability.  This could be accomodated, however
> 
> Add the word "directly" as "to read security.nscapability directly".

Updated in my git tree.

> > it requires the kernel to convert the kuid_t to a valid uid in the reader's
> > user_ns.  So for now it's simply not supported.
> 
> I really like the idea that the kernel transparently replaces
> nscapability for capability.
> 
> > Only a single security.nscapability xattr may be written.  This patch
> > could be expanded to allow a list of capabilities and rootids, however
> > I do not believe that to be a worthwhile use case.
> 
> Ok
> 
> > This allows a simple setxattr to work, allows tar/untar to
> > work, and allows us to tar in one namespace and untar in
> > another while preserving the capability, without risking
> > leaking privilege into a parent namespace.
> > 
> > Note - listxattr is not being handled here.  So results of that can be
> > inconsistent with get/setxattr.  Fixing that will require yet more
> > deceit in fs/xattr.c.
> > 
> > Note2 - it may be less sneaky to hide all the magic behind the
> > security.nscapability xattr.  So userspace would need to know to
> > use that xattr name when needed, but with the same format as
> > security.capability.  The kuid_t rootid would be filled in by the
> > kernel.  That's a middle ground between my last patch and this one.
> 
> The less userspace needs to differentiate between running in a namespace
> and not, the better.
> 
> Note3 - capability is currently protected by EVM, when enabled.  Should
> ns_capability also be a protected xattr?

Hm - that would protect it from offline attacks, but allow the container
to update it, right?  That sounds good.

> > Signed-off-by: Serge Hallyn 
> > ---
> >  fs/xattr.c  |  18 ++-
> >  include/linux/capability.h  |   8 +-
> >  include/uapi/linux/capability.h |  19 +++
> >  include/uapi/linux/xattr.h  |   3 +
> >  security/commoncap.c| 253 
> > ++--
> >  5 files changed, 291 insertions(+), 10 deletions(-)
> > 
> > diff --git a/fs/xattr.c b/fs/xattr.c
> > index 4861322..5c0e7ae 100644
> > --- a/fs/xattr.c
> > +++ b/fs/xattr.c
> > @@ -94,11 +94,26 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const 
> > char *name,
> >  {
> > struct inode *inode = dentry->d_inode;
> > int error = -EOPNOTSUPP;
> > +   void *wvalue = NULL;
> > +   size_t wsize = 0;
> > int issec = !strncmp(name, XATTR_SECURITY_PREFIX,
> >XATTR_SECURITY_PREFIX_LEN);
> > 
> > -   if (issec)
> > +   if (issec) {
> > inode->i_flags &= ~S_NOSEC;
> > +   /* if root in a non-init user_ns tries to set
> > +* security.capability, write a security.nscapability
> > +* in its place */
> > +   if (!strcmp(name, "security.capability") &&
> > +   current_user_ns() != _user_ns) {
> > +   cap_setxattr_make_nscap(dentry, value, size, , 
> > );
> > +   if (!wvalue)
> > +   return -EPERM;
> > +   value = wvalue;
> > +   size = wsize;
> > +   name = "security.nscapability";
> > +   }
> 
> The call to capable_wrt_inode_uidgid() is hidden behind
> cap_setxattr_make_nscap().  Does it make sense to call it here instead,
> before the security.capability test?  This would lay the foundation for
> doing something similar for IMA.

Might make sense to move that.  Though looking at it with fresh eyes I 

Re: [PATCH RFC] user-namespaced file capabilities - now with more magic

[Serge E. Hallyn]

Quoting Mimi Zohar (zo...@linux.vnet.ibm.com):
> On Wed, 2016-05-18 at 16:57 -0500, Serge E. Hallyn wrote:
> > This patch introduces a new security.nscapability xattr.  It
> > is mostly like security.capability, but also lists a 'rootid'.
> > This is the uid_t (in init_user_ns) of the root id (uid 0 in a
> > namespace) in whose namespaces the file capabilities may take
> > effect.
> > 
> > A privileged (cap_setfcap) process in the initial user ns may
> > set and read this xattr directly.  However, its real intent is
> > to be used as a transparent fallback in user namespaces.
> > 
> > Root in a user ns cannot be trusted to write security.capability
> > xattrs, because any user on the host could map his own uid to root
> > in a namespace, write the xattr, and execute the file with privilege
> > on the host.
> > 
> > With this patch, when root in a user ns asks to write security.capability,
> > the kernel will transparently write a security.nscapability xattr
> > instead, filling in the kuid of the calling user's root uid.  Subsequently,
> > any task executing the file which has the noted k_uid as its root uid,
> > or which is in a descendent user_ns of such a user_ns, will run the
> > file with capabilities.
> > 
> > When reading the security.capability xattr from a non-init user_ns, a valid
> > security.nscapability will be shown if it exists.  Such a task is not
> > allowed to read security.nscapability.  This could be accomodated, however
> 
> Add the word "directly" as "to read security.nscapability directly".

Updated in my git tree.

> > it requires the kernel to convert the kuid_t to a valid uid in the reader's
> > user_ns.  So for now it's simply not supported.
> 
> I really like the idea that the kernel transparently replaces
> nscapability for capability.
> 
> > Only a single security.nscapability xattr may be written.  This patch
> > could be expanded to allow a list of capabilities and rootids, however
> > I do not believe that to be a worthwhile use case.
> 
> Ok
> 
> > This allows a simple setxattr to work, allows tar/untar to
> > work, and allows us to tar in one namespace and untar in
> > another while preserving the capability, without risking
> > leaking privilege into a parent namespace.
> > 
> > Note - listxattr is not being handled here.  So results of that can be
> > inconsistent with get/setxattr.  Fixing that will require yet more
> > deceit in fs/xattr.c.
> > 
> > Note2 - it may be less sneaky to hide all the magic behind the
> > security.nscapability xattr.  So userspace would need to know to
> > use that xattr name when needed, but with the same format as
> > security.capability.  The kuid_t rootid would be filled in by the
> > kernel.  That's a middle ground between my last patch and this one.
> 
> The less userspace needs to differentiate between running in a namespace
> and not, the better.
> 
> Note3 - capability is currently protected by EVM, when enabled.  Should
> ns_capability also be a protected xattr?

Hm - that would protect it from offline attacks, but allow the container
to update it, right?  That sounds good.

> > Signed-off-by: Serge Hallyn 
> > ---
> >  fs/xattr.c  |  18 ++-
> >  include/linux/capability.h  |   8 +-
> >  include/uapi/linux/capability.h |  19 +++
> >  include/uapi/linux/xattr.h  |   3 +
> >  security/commoncap.c| 253 
> > ++--
> >  5 files changed, 291 insertions(+), 10 deletions(-)
> > 
> > diff --git a/fs/xattr.c b/fs/xattr.c
> > index 4861322..5c0e7ae 100644
> > --- a/fs/xattr.c
> > +++ b/fs/xattr.c
> > @@ -94,11 +94,26 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const 
> > char *name,
> >  {
> > struct inode *inode = dentry->d_inode;
> > int error = -EOPNOTSUPP;
> > +   void *wvalue = NULL;
> > +   size_t wsize = 0;
> > int issec = !strncmp(name, XATTR_SECURITY_PREFIX,
> >XATTR_SECURITY_PREFIX_LEN);
> > 
> > -   if (issec)
> > +   if (issec) {
> > inode->i_flags &= ~S_NOSEC;
> > +   /* if root in a non-init user_ns tries to set
> > +* security.capability, write a security.nscapability
> > +* in its place */
> > +   if (!strcmp(name, "security.capability") &&
> > +   current_user_ns() != _user_ns) {
> > +   cap_setxattr_make_nscap(dentry, value, size, , 
> > );
> > +   if (!wvalue)
> > +   return -EPERM;
> > +   value = wvalue;
> > +   size = wsize;
> > +   name = "security.nscapability";
> > +   }
> 
> The call to capable_wrt_inode_uidgid() is hidden behind
> cap_setxattr_make_nscap().  Does it make sense to call it here instead,
> before the security.capability test?  This would lay the foundation for
> doing something similar for IMA.

Might make sense to move that.  Though looking at it with fresh eyes I wonder
whether adding less 

Re: [PATCH perf/core v8 12/16] perf-list: Show SDT and pre-cached events

[Hemant Kumar]

On 05/15/2016 08:51 AM, Masami Hiramatsu wrote:

From: Masami Hiramatsu 

Show SDT and pre-cached events by perf-list with "sdt". This also
shows the binary and build-id where the events are placed only
when there are same name events on different binaries.
e.g.
   
   # perf list sdt

   List of pre-defined events (to be used in -e):

 sdt_libc:lll_futex_wake[SDT event]
 sdt_libc:lll_lock_wait_private [SDT event]
 sdt_libc:longjmp   [SDT event]
 sdt_libc:longjmp_target[SDT event]
   ...
 sdt_libstdcxx:rethrow@/usr/bin/gcc(0cc207fc4b27)   [SDT event]
 sdt_libstdcxx:rethrow@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
 sdt_libstdcxx:throw@/usr/bin/gcc(0cc207fc4b27) [SDT event]
 sdt_libstdcxx:throw@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
   

The binary path and build-id are shown in below format;

   :@()

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Masami Hiramatsu 
---
  Changes in v5:
   - Fix a build error for minimal option.

  Changes in v4:
   - Update patch description.
   - Change event list format.
---
  tools/perf/builtin-list.c  |4 ++
  tools/perf/util/parse-events.c |   83 
  tools/perf/util/parse-events.h |2 +
  tools/perf/util/probe-file.h   |9 
  4 files changed, 98 insertions(+)

diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 5e22db4..3cba865 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -62,6 +62,8 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
print_pmu_events(NULL, raw_dump);
+   else if (strcmp(argv[i], "sdt") == 0)
+   print_sdt_events(NULL, NULL, raw_dump);


We will also need to add "sdt" to list_usage[] variable in this function :
const char * const list_usage[] = {
"perf list [hw|sw|cache|tracepoint|pmu|sdt|event_glob]",
NULL
};


else if ((sep = strchr(argv[i], ':')) != NULL) {
int sep_idx;

@@ -76,6 +78,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)

s[sep_idx] = '\0';
print_tracepoint_events(s, s + sep_idx + 1, raw_dump);
+   print_sdt_events(s, s + sep_idx + 1, raw_dump);
free(s);
} else {
if (asprintf(, "*%s*", argv[i]) < 0) {
@@ -89,6 +92,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
print_hwcache_events(s, raw_dump);
print_pmu_events(s, raw_dump);
print_tracepoint_events(NULL, s, raw_dump);
+   print_sdt_events(NULL, s, raw_dump);
free(s);
}
}
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index bcbc983..f9c8b7b 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -20,6 +20,7 @@
  #include "pmu.h"
  #include "thread_map.h"
  #include "cpumap.h"
+#include "probe-file.h"
  #include "asm/bug.h"

  #define MAX_NAME_LEN 100
@@ -1976,6 +1977,86 @@ static bool is_event_supported(u8 type, unsigned config)
return ret;
  }

+void print_sdt_events(const char *subsys_glob, const char *event_glob,
+ bool name_only)
+{
+   struct probe_cache *pcache;
+   struct probe_cache_entry *ent;
+   struct strlist *bidlist, *sdtlist;
+   struct strlist_config cfg = {.dont_dupstr = true};
+   struct str_node *nd, *nd2;
+   char *buf, *path, *ptr = NULL;
+   bool show_detail = false;
+   int ret;
+
+   sdtlist = strlist__new(NULL, );
+   if (!sdtlist) {
+   pr_debug("Failed to allocate new strlist for SDT\n");
+   return;
+   }
+   ret = build_id_cache__list_all();
+   if (ret < 0) {
+   pr_debug("Failed to get buildids: %d\n", ret);
+   return;
+   }
+   strlist__for_each(nd, bidlist) {
+   pcache = probe_cache__new(nd->s);
+   if (!pcache)
+   continue;
+   if (!list_empty(>list))
+   list_for_each_entry(ent, >list, list) {
+   if (!ent->sdt)
+   continue;
+   if (subsys_glob &&
+   !strglobmatch(ent->pev.group, subsys_glob))
+   continue;
+   if (event_glob &&
+

Re: [PATCH perf/core v8 12/16] perf-list: Show SDT and pre-cached events

[Hemant Kumar]

On 05/15/2016 08:51 AM, Masami Hiramatsu wrote:

From: Masami Hiramatsu 

Show SDT and pre-cached events by perf-list with "sdt". This also
shows the binary and build-id where the events are placed only
when there are same name events on different binaries.
e.g.
   
   # perf list sdt

   List of pre-defined events (to be used in -e):

 sdt_libc:lll_futex_wake[SDT event]
 sdt_libc:lll_lock_wait_private [SDT event]
 sdt_libc:longjmp   [SDT event]
 sdt_libc:longjmp_target[SDT event]
   ...
 sdt_libstdcxx:rethrow@/usr/bin/gcc(0cc207fc4b27)   [SDT event]
 sdt_libstdcxx:rethrow@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
 sdt_libstdcxx:throw@/usr/bin/gcc(0cc207fc4b27) [SDT event]
 sdt_libstdcxx:throw@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
   

The binary path and build-id are shown in below format;

   :@()

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Masami Hiramatsu 
---
  Changes in v5:
   - Fix a build error for minimal option.

  Changes in v4:
   - Update patch description.
   - Change event list format.
---
  tools/perf/builtin-list.c  |4 ++
  tools/perf/util/parse-events.c |   83 
  tools/perf/util/parse-events.h |2 +
  tools/perf/util/probe-file.h   |9 
  4 files changed, 98 insertions(+)

diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 5e22db4..3cba865 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -62,6 +62,8 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
print_pmu_events(NULL, raw_dump);
+   else if (strcmp(argv[i], "sdt") == 0)
+   print_sdt_events(NULL, NULL, raw_dump);


We will also need to add "sdt" to list_usage[] variable in this function :
const char * const list_usage[] = {
"perf list [hw|sw|cache|tracepoint|pmu|sdt|event_glob]",
NULL
};


else if ((sep = strchr(argv[i], ':')) != NULL) {
int sep_idx;

@@ -76,6 +78,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)

s[sep_idx] = '\0';
print_tracepoint_events(s, s + sep_idx + 1, raw_dump);
+   print_sdt_events(s, s + sep_idx + 1, raw_dump);
free(s);
} else {
if (asprintf(, "*%s*", argv[i]) < 0) {
@@ -89,6 +92,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
print_hwcache_events(s, raw_dump);
print_pmu_events(s, raw_dump);
print_tracepoint_events(NULL, s, raw_dump);
+   print_sdt_events(NULL, s, raw_dump);
free(s);
}
}
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index bcbc983..f9c8b7b 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -20,6 +20,7 @@
  #include "pmu.h"
  #include "thread_map.h"
  #include "cpumap.h"
+#include "probe-file.h"
  #include "asm/bug.h"

  #define MAX_NAME_LEN 100
@@ -1976,6 +1977,86 @@ static bool is_event_supported(u8 type, unsigned config)
return ret;
  }

+void print_sdt_events(const char *subsys_glob, const char *event_glob,
+ bool name_only)
+{
+   struct probe_cache *pcache;
+   struct probe_cache_entry *ent;
+   struct strlist *bidlist, *sdtlist;
+   struct strlist_config cfg = {.dont_dupstr = true};
+   struct str_node *nd, *nd2;
+   char *buf, *path, *ptr = NULL;
+   bool show_detail = false;
+   int ret;
+
+   sdtlist = strlist__new(NULL, );
+   if (!sdtlist) {
+   pr_debug("Failed to allocate new strlist for SDT\n");
+   return;
+   }
+   ret = build_id_cache__list_all();
+   if (ret < 0) {
+   pr_debug("Failed to get buildids: %d\n", ret);
+   return;
+   }
+   strlist__for_each(nd, bidlist) {
+   pcache = probe_cache__new(nd->s);
+   if (!pcache)
+   continue;
+   if (!list_empty(>list))
+   list_for_each_entry(ent, >list, list) {
+   if (!ent->sdt)
+   continue;
+   if (subsys_glob &&
+   !strglobmatch(ent->pev.group, subsys_glob))
+   continue;
+   if (event_glob &&
+   !strglobmatch(ent->pev.event, event_glob))
+

linux-next: build warnings after merge of the net tree

[Stephen Rothwell]

Hi all,

After merging the net tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:

drivers/net/usb/pegasus.c: In function 'read_bulk_callback':
drivers/net/usb/pegasus.c:475:1: warning: label 'goon' defined but not used 
[-Wunused-label]
 goon:
 ^
drivers/net/usb/pegasus.c:446:8: warning: unused variable 'pkt_len' 
[-Wunused-variable]
  __u16 pkt_len;
^
drivers/net/usb/pegasus.c:445:6: warning: unused variable 'buf' 
[-Wunused-variable]
  u8 *buf = urb->transfer_buffer;
  ^
drivers/net/usb/pegasus.c:443:17: warning: unused variable 'count' 
[-Wunused-variable]
  int rx_status, count = urb->actual_length;
 ^

Introduced by commit

  e00be9e4d0ff ("net: pegasus: remove dead coding")



-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the net tree

[Stephen Rothwell]

Hi all,

After merging the net tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:

drivers/net/usb/pegasus.c: In function 'read_bulk_callback':
drivers/net/usb/pegasus.c:475:1: warning: label 'goon' defined but not used 
[-Wunused-label]
 goon:
 ^
drivers/net/usb/pegasus.c:446:8: warning: unused variable 'pkt_len' 
[-Wunused-variable]
  __u16 pkt_len;
^
drivers/net/usb/pegasus.c:445:6: warning: unused variable 'buf' 
[-Wunused-variable]
  u8 *buf = urb->transfer_buffer;
  ^
drivers/net/usb/pegasus.c:443:17: warning: unused variable 'count' 
[-Wunused-variable]
  int rx_status, count = urb->actual_length;
 ^

Introduced by commit

  e00be9e4d0ff ("net: pegasus: remove dead coding")



-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

[Wu, Songjun]

Hi Rob,

Thank you for your comments.

On 5/19/2016 07:05, Rob Herring wrote:

On Wed, May 18, 2016 at 03:46:29PM +0800, Songjun Wu wrote:

DT binding documentation for ISC driver.

Signed-off-by: Songjun Wu 
---

Changes in v2:
- Remove the unit address of the endpoint.
- Add the unit address to the clock node.
- Avoid using underscores in node names.
- Drop the "0x" in the unit address of the i2c node.
- Modify the description of "atmel,sensor-preferred".
- Add the description for the ISC internal clock.

 .../devicetree/bindings/media/atmel-isc.txt| 100 +
 1 file changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt 
b/Documentation/devicetree/bindings/media/atmel-isc.txt
new file mode 100644
index 000..9e65395
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
@@ -0,0 +1,100 @@
+Atmel Image Sensor Controller (ISC)
+--
+
+Required properties for ISC:
+- compatible
+   Must be "atmel,sama5d2-isc"
+- reg
+   Physical base address and length of the registers set for the device;
+- interrupts
+   Should contain IRQ line for the ISC;
+- clocks
+   List of clock specifiers, corresponding to entries in
+   the clock-names property;
+   Please refer to clock-bindings.txt.
+- clock-names
+   Required elements: "hclock", "ispck".
+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
+- clk-in-isc
+   ISC internal clock node, it includes two clock nodes,
+   isc-ispck and isc-mck.


And you need to describe each of these nodes and the properties they
have. But more on this below...


Should I move the description of clock node below to here?


+- atmel,sensor-preferred
+   ISC may convert the raw format to the specified format when the sensor
+   outputs the raw format, and the sensor may output the specified format
+   directly. If sensor is preferred to output the specified format
+   directly, the value should be 1 (1-preferred, 0-not).
+   The default value is 1.


I don't think this belongs in DT. It sounds more like a configuration
and userspace decision. It is still not clear what you mean by
"specified format".


Accept, I will remove this.


+
+ISC supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required properties for the ISC internal clocks:
+- #address-cells
+   should be 1 (reg is used to encode clk id).
+- #size-cells
+   should be 0 (reg is used to encode clk id).
+- name
+   device tree node describing a ISC internal clock.
+   * #clock-cells: from common clock binding; should be set to 0.
+   * reg: clock id, there are two values,
+  <0> is ISP clock, <1> is master clock.
+   * clocks: shall be the isc internal clock source phandles.
+ e.g. clocks = <_clk>, <>, <_gclk>;
+
+Example:
+isc: isc@f0008000 {
+   compatible = "atmel,sama5d2-isc";
+   reg = <0xf0008000 0x4000>;
+   interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+   clocks = <_clk>, <_ispck>;
+   clock-names = "hclock", "ispck";
+   atmel,sensor-preferred = <1>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_0: endpoint {
+   remote-endpoint = <_0>;
+   hsync-active = <1>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   };
+   };
+
+   clk-in-isc {


Is this really separate from the rest of the isc block. It would be
much more simple to define all the input clocks at the parent and then
reference these 2 clocks with < 0> and < 1>.


Yes, it's separate from the rest of isc block.
It will register two clocks, one is used in ISC internal processor, the 
other will provide the clock to the sensor outside.
I think it's better that the parent clock is included in node 
'clk-in-isc' node. I will try to optimize this node.



+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_ispck: isc-ispck@0 {


These would need a compatible string otherwise.


+   #clock-cells = <0>;
+   reg = <0>;


Are 0 and 1 meaningful in terms of the hardware description?


Yes, It's meaningful.
The register field is different, 0 and 1 can distinguish the different 
clock.



+   clocks = <_clk>, <>;
+   };
+
+   isc_mck: isc-mck@1 {
+   #clock-cells = <0>;
+   reg = <1>;
+   clocks = <_clk>, <>, <_gclk>;
+   };
+   };
+};

Re: [PATCH v2 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

[Wu, Songjun]

Hi Rob,

Thank you for your comments.

On 5/19/2016 07:05, Rob Herring wrote:

On Wed, May 18, 2016 at 03:46:29PM +0800, Songjun Wu wrote:

DT binding documentation for ISC driver.

Signed-off-by: Songjun Wu 
---

Changes in v2:
- Remove the unit address of the endpoint.
- Add the unit address to the clock node.
- Avoid using underscores in node names.
- Drop the "0x" in the unit address of the i2c node.
- Modify the description of "atmel,sensor-preferred".
- Add the description for the ISC internal clock.

 .../devicetree/bindings/media/atmel-isc.txt| 100 +
 1 file changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt 
b/Documentation/devicetree/bindings/media/atmel-isc.txt
new file mode 100644
index 000..9e65395
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
@@ -0,0 +1,100 @@
+Atmel Image Sensor Controller (ISC)
+--
+
+Required properties for ISC:
+- compatible
+   Must be "atmel,sama5d2-isc"
+- reg
+   Physical base address and length of the registers set for the device;
+- interrupts
+   Should contain IRQ line for the ISC;
+- clocks
+   List of clock specifiers, corresponding to entries in
+   the clock-names property;
+   Please refer to clock-bindings.txt.
+- clock-names
+   Required elements: "hclock", "ispck".
+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
+- clk-in-isc
+   ISC internal clock node, it includes two clock nodes,
+   isc-ispck and isc-mck.


And you need to describe each of these nodes and the properties they
have. But more on this below...


Should I move the description of clock node below to here?


+- atmel,sensor-preferred
+   ISC may convert the raw format to the specified format when the sensor
+   outputs the raw format, and the sensor may output the specified format
+   directly. If sensor is preferred to output the specified format
+   directly, the value should be 1 (1-preferred, 0-not).
+   The default value is 1.


I don't think this belongs in DT. It sounds more like a configuration
and userspace decision. It is still not clear what you mean by
"specified format".


Accept, I will remove this.


+
+ISC supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required properties for the ISC internal clocks:
+- #address-cells
+   should be 1 (reg is used to encode clk id).
+- #size-cells
+   should be 0 (reg is used to encode clk id).
+- name
+   device tree node describing a ISC internal clock.
+   * #clock-cells: from common clock binding; should be set to 0.
+   * reg: clock id, there are two values,
+  <0> is ISP clock, <1> is master clock.
+   * clocks: shall be the isc internal clock source phandles.
+ e.g. clocks = <_clk>, <>, <_gclk>;
+
+Example:
+isc: isc@f0008000 {
+   compatible = "atmel,sama5d2-isc";
+   reg = <0xf0008000 0x4000>;
+   interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+   clocks = <_clk>, <_ispck>;
+   clock-names = "hclock", "ispck";
+   atmel,sensor-preferred = <1>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_0: endpoint {
+   remote-endpoint = <_0>;
+   hsync-active = <1>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   };
+   };
+
+   clk-in-isc {


Is this really separate from the rest of the isc block. It would be
much more simple to define all the input clocks at the parent and then
reference these 2 clocks with < 0> and < 1>.


Yes, it's separate from the rest of isc block.
It will register two clocks, one is used in ISC internal processor, the 
other will provide the clock to the sensor outside.
I think it's better that the parent clock is included in node 
'clk-in-isc' node. I will try to optimize this node.



+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_ispck: isc-ispck@0 {


These would need a compatible string otherwise.


+   #clock-cells = <0>;
+   reg = <0>;


Are 0 and 1 meaningful in terms of the hardware description?


Yes, It's meaningful.
The register field is different, 0 and 1 can distinguish the different 
clock.



+   clocks = <_clk>, <>;
+   };
+
+   isc_mck: isc-mck@1 {
+   #clock-cells = <0>;
+   reg = <1>;
+   clocks = <_clk>, <>, <_gclk>;
+   };
+   };
+};

Re: mmotm 2016-05-19-19-59 uploaded

[Stephen Rothwell]

Hi Andrew,

On Thu, 19 May 2016 19:59:50 -0700 a...@linux-foundation.org wrote:
>
> The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/

This one looks much better, thanks.

-- 
Cheers,
Stephen Rothwell

Re: mmotm 2016-05-19-19-59 uploaded

[Stephen Rothwell]

Hi Andrew,

On Thu, 19 May 2016 19:59:50 -0700 a...@linux-foundation.org wrote:
>
> The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/

This one looks much better, thanks.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

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

  include/linux/dax.h

between commit:

  c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO")

from Linus' tree and commit:

  e804315dd0f5 ("dax: Define DAX lock bit for radix tree exceptional entry")

from the dax-misc tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/dax.h
index 982a6c4a62f3,7bf12277c006..
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@@ -3,17 -3,21 +3,21 @@@
  
  #include 
  #include 
+ #include 
  #include 
  
+ /* We use lowest available exceptional entry bit for locking */
+ #define RADIX_DAX_ENTRY_LOCK (1 << RADIX_TREE_EXCEPTIONAL_SHIFT)
+ 
 -ssize_t dax_do_io(struct kiocb *, struct inode *, struct iov_iter *, loff_t,
 +ssize_t dax_do_io(struct kiocb *, struct inode *, struct iov_iter *,
  get_block_t, dio_iodone_t, int flags);
- int dax_clear_sectors(struct block_device *bdev, sector_t _sector, long 
_size);
  int dax_zero_page_range(struct inode *, loff_t from, unsigned len, 
get_block_t);
  int dax_truncate_page(struct inode *, loff_t from, get_block_t);
- int dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t,
-   dax_iodone_t);
- int __dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t,
-   dax_iodone_t);
+ int dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t);
+ int __dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t);
+ int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index);
+ void dax_wake_mapping_entry_waiter(struct address_space *mapping,
+  pgoff_t index, bool wake_all);
  
  #ifdef CONFIG_FS_DAX
  struct page *read_dax_sector(struct block_device *bdev, sector_t n);

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

[Stephen Rothwell]

Hi all,

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

  include/linux/dax.h

between commit:

  c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO")

from Linus' tree and commit:

  e804315dd0f5 ("dax: Define DAX lock bit for radix tree exceptional entry")

from the dax-misc tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/dax.h
index 982a6c4a62f3,7bf12277c006..
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@@ -3,17 -3,21 +3,21 @@@
  
  #include 
  #include 
+ #include 
  #include 
  
+ /* We use lowest available exceptional entry bit for locking */
+ #define RADIX_DAX_ENTRY_LOCK (1 << RADIX_TREE_EXCEPTIONAL_SHIFT)
+ 
 -ssize_t dax_do_io(struct kiocb *, struct inode *, struct iov_iter *, loff_t,
 +ssize_t dax_do_io(struct kiocb *, struct inode *, struct iov_iter *,
  get_block_t, dio_iodone_t, int flags);
- int dax_clear_sectors(struct block_device *bdev, sector_t _sector, long 
_size);
  int dax_zero_page_range(struct inode *, loff_t from, unsigned len, 
get_block_t);
  int dax_truncate_page(struct inode *, loff_t from, get_block_t);
- int dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t,
-   dax_iodone_t);
- int __dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t,
-   dax_iodone_t);
+ int dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t);
+ int __dax_fault(struct vm_area_struct *, struct vm_fault *, get_block_t);
+ int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index);
+ void dax_wake_mapping_entry_waiter(struct address_space *mapping,
+  pgoff_t index, bool wake_all);
  
  #ifdef CONFIG_FS_DAX
  struct page *read_dax_sector(struct block_device *bdev, sector_t n);

Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

[Xiaqing (A)]

在 2016/5/19 21:18, Catalin Marinas 写道:

On Thu, May 19, 2016 at 01:50:40PM +0100, Catalin Marinas wrote:

On Thu, May 19, 2016 at 07:06:40PM +0800, Xiaqing (A) wrote:



在 2016/5/19 18:49, Catalin Marinas 写道:

On Thu, May 19, 2016 at 10:44:33AM +0800, x00195127 wrote:

we find that some apps will read cpuinfo when start up,
they need the string  as follows:
"Processor   : AArch64 Processor rev 0 (aarch64)"

Then thay could load the corresponding libs. But now
arm64 platform's cpuinfo don't has this now, so
we need add this.


I have the same question as Martinez: what are those apps? If they are
64-bit apps, they can always assume AArch64 processor.


Those are 32-bit apps, and those apps are very popular in our country.


32-bit apps checking for "AArch64" is a really silly idea. What do they
do with this information?

I'm rather inclined to merge this patch:

diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470486f3..623d7d291dd6 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -127,7 +127,8 @@ static int c_show(struct seq_file *m, void *v)
 * software which does already (at least for 32-bit).
 */
seq_puts(m, "Features\t:");
-   if (personality(current->personality) == PER_LINUX32) {
+   if (is_compat_task() ||
+   personality(current->personality) == PER_LINUX32) {
  #ifdef CONFIG_COMPAT
for (j = 0; compat_hwcap_str[j]; j++)
if (compat_elf_hwcap & (1 << j))


To make it even more in line with the AArch32 kernel, let's add the
"model name":

--8<-
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470486f3..6bda9d30a769 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -22,6 +22,7 @@

  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -104,6 +105,8 @@ static const char *const compat_hwcap2_str[] = {
  static int c_show(struct seq_file *m, void *v)
  {
int i, j;
+   bool compat = is_compat_task() ||
+   personality(current->personality) == PER_LINUX32;

for_each_online_cpu(i) {
struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
@@ -115,6 +118,9 @@ static int c_show(struct seq_file *m, void *v)
 * "processor".  Give glibc what it expects.
 */
seq_printf(m, "processor\t: %d\n", i);
+   if (compat)
+   seq_printf(m, "model name\t: ARMv8 Processor rev %d 
(%s)\n",
+  MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);

seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
   loops_per_jiffy / (50UL/HZ),
@@ -127,7 +133,7 @@ static int c_show(struct seq_file *m, void *v)
 * software which does already (at least for 32-bit).
 */
seq_puts(m, "Features\t:");
-   if (personality(current->personality) == PER_LINUX32) {
+   if (compat) {
  #ifdef CONFIG_COMPAT
for (j = 0; compat_hwcap_str[j]; j++)
if (compat_elf_hwcap & (1 << j))
--8<-

With the above, a compat task or a native one with PER_LINUX32
personality would get:

processor   : 0
model name  : ARMv8 Processor rev 0 (v8l)
BogoMIPS: 100.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 0



I have tested with your patch, the app still can not start up at all.

I'm sorry I didn't explan this exactly before, those apps are 32-bit 
android apps(com.tencent.pao etc.). They want to get the information as

  "*D m3e : GetCPUType:AArch64 Processor rev 0 (aarch64)*"
and I'm sure the process is forked by zygote not zygote64 in android M.

Finally, I find that apps need the information "Processor :", so when I 
change your patch as below, the apps can start up.

--
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470..f14ea4a 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -104,6 +104,8 @@ static const char *const compat_hwcap2_str[] = {
 static int c_show(struct seq_file *m, void *v)
 {
int i, j;
+   bool compat = is_compat_task() ||
+   personality(current->personality) == PER_LINUX32;

for_each_online_cpu(i) {
struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
@@ -116,6 +118,10 @@ static int c_show(struct seq_file *m, void *v)
 */
seq_printf(m, "processor\t: %d\n", i);

+   if (compat)
+ 

Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

[Xiaqing (A)]

在 2016/5/19 21:18, Catalin Marinas 写道:

On Thu, May 19, 2016 at 01:50:40PM +0100, Catalin Marinas wrote:

On Thu, May 19, 2016 at 07:06:40PM +0800, Xiaqing (A) wrote:



在 2016/5/19 18:49, Catalin Marinas 写道:

On Thu, May 19, 2016 at 10:44:33AM +0800, x00195127 wrote:

we find that some apps will read cpuinfo when start up,
they need the string  as follows:
"Processor   : AArch64 Processor rev 0 (aarch64)"

Then thay could load the corresponding libs. But now
arm64 platform's cpuinfo don't has this now, so
we need add this.


I have the same question as Martinez: what are those apps? If they are
64-bit apps, they can always assume AArch64 processor.


Those are 32-bit apps, and those apps are very popular in our country.


32-bit apps checking for "AArch64" is a really silly idea. What do they
do with this information?

I'm rather inclined to merge this patch:

diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470486f3..623d7d291dd6 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -127,7 +127,8 @@ static int c_show(struct seq_file *m, void *v)
 * software which does already (at least for 32-bit).
 */
seq_puts(m, "Features\t:");
-   if (personality(current->personality) == PER_LINUX32) {
+   if (is_compat_task() ||
+   personality(current->personality) == PER_LINUX32) {
  #ifdef CONFIG_COMPAT
for (j = 0; compat_hwcap_str[j]; j++)
if (compat_elf_hwcap & (1 << j))


To make it even more in line with the AArch32 kernel, let's add the
"model name":

--8<-
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470486f3..6bda9d30a769 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -22,6 +22,7 @@

  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -104,6 +105,8 @@ static const char *const compat_hwcap2_str[] = {
  static int c_show(struct seq_file *m, void *v)
  {
int i, j;
+   bool compat = is_compat_task() ||
+   personality(current->personality) == PER_LINUX32;

for_each_online_cpu(i) {
struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
@@ -115,6 +118,9 @@ static int c_show(struct seq_file *m, void *v)
 * "processor".  Give glibc what it expects.
 */
seq_printf(m, "processor\t: %d\n", i);
+   if (compat)
+   seq_printf(m, "model name\t: ARMv8 Processor rev %d 
(%s)\n",
+  MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);

seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
   loops_per_jiffy / (50UL/HZ),
@@ -127,7 +133,7 @@ static int c_show(struct seq_file *m, void *v)
 * software which does already (at least for 32-bit).
 */
seq_puts(m, "Features\t:");
-   if (personality(current->personality) == PER_LINUX32) {
+   if (compat) {
  #ifdef CONFIG_COMPAT
for (j = 0; compat_hwcap_str[j]; j++)
if (compat_elf_hwcap & (1 << j))
--8<-

With the above, a compat task or a native one with PER_LINUX32
personality would get:

processor   : 0
model name  : ARMv8 Processor rev 0 (v8l)
BogoMIPS: 100.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 0



I have tested with your patch, the app still can not start up at all.

I'm sorry I didn't explan this exactly before, those apps are 32-bit 
android apps(com.tencent.pao etc.). They want to get the information as

  "*D m3e : GetCPUType:AArch64 Processor rev 0 (aarch64)*"
and I'm sure the process is forked by zygote not zygote64 in android M.

Finally, I find that apps need the information "Processor :", so when I 
change your patch as below, the apps can start up.

--
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470..f14ea4a 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -104,6 +104,8 @@ static const char *const compat_hwcap2_str[] = {
 static int c_show(struct seq_file *m, void *v)
 {
int i, j;
+   bool compat = is_compat_task() ||
+   personality(current->personality) == PER_LINUX32;

for_each_online_cpu(i) {
struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
@@ -116,6 +118,10 @@ static int c_show(struct seq_file *m, void *v)
 */
seq_printf(m, "processor\t: %d\n", i);

+   if (compat)
+ 

Re: perf probe -L on ubuntu 16.04

[Masami Hiramatsu]

On Thu, 19 May 2016 09:06:42 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Thu, May 19, 2016 at 11:00:39AM +0900, Masami Hiramatsu escreveu:
> > On Mon, 16 May 2016 22:56:36 -0300
> > Arnaldo Carvalho de Melo  wrote:
> > >   Have you ever tried using 'perf probe' on ubuntu?
> 
> > > acme@ubuntu:~/git/linux$ sudo apt-cache search linux-image-$(uname -r)
> > > linux-image-4.4.0-21-generic - Linux kernel image for version 4.4.0 on
> > > 64 bit x86 SMP
> > > linux-image-4.4.0-21-generic-dbgsym - Linux kernel debug image for
> > > version 4.4.0 on 64 bit x86 SMP
> > > acme@ubuntu:~/git/linux$ 
> > > acme@ubuntu:~/git/linux$ 
> > > 
> > > So those are installed, but then I try:
> > > 
> > > root@ubuntu:~# perf probe -vvv -L getname_flags
> > > Looking at the vmlinux_path (8 entries long)
> > > Using /usr/lib/debug/boot/vmlinux-4.4.0-21-generic for symbols
> > > Open Debuginfo file: /usr/lib/debug/boot/vmlinux-4.4.0-21-generic
> > > fname: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c, lineno:125
> > > New line range: 125 to 2147483647
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> 
> Ah, why do we repeat the above line that many times? Are we somehow
> reading this compile unit that many times?!?

Yes, because the getname_flags is inlined by compiler, depends on the
parameter, some lines in the function are never compiled at some call
points. In this case, we have to check every call points so that all
the available lines are found.

BTW, "this CU" has no meaning, it should show the diename, or remove
the useless message.

> > > path: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c
> > > Failed to find source file path.
> > >   Error: Failed to show lines. Reason: No such file or directory (Code: 
> > > -2)
> > > root@ubuntu:~# 
> 
> > > Have to dig deeper to see where the source code is, ideas?
>  
> > It shows the "path" is ;
> > > path: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c
>  
> > So, would you have the source code under this temporary directory?
> > (yeah, I guess No)
> 
> No, and I couldn't find a package that had it
> 
> > Anyway, ubuntu has "linux-source" package, or apt source linux-image-`uname 
> > -r`
> > will give you the source tree in current dir.
>  
> > After you get a proper kernel source code, you can use -s to show source 
> > code.
>  
> > -s, --source 
> >   path to kernel source
>  
> > I ensured it is working correctly by below command.
> > $ perf probe -s ./linux-4.4.0 -L getname_flags
> 
> Ok, how about telling the user this package is needed, since we can
> figure out the distro and the package name?

Did we do that already?

> Couldn't it figure out where
> the source code is and also not require using '-s'?

No, actually, ubuntu/debian are not providing kernel source tree package
as redhat/fedora do. User can only download source tarball and extract
it under current working directory. There seems no standard directory
where the source code is extracted to. I think it's debian/ubuntu's
packaging policy.

Anyway, even though we can provide how-to guide for them via Documentation.
I think it's better way because we also have to add some entries to 
apt.conf for installing kernel debuginfo.

Thank you,

> 
> - Arnaldo


-- 
Masami Hiramatsu 

Re: perf probe -L on ubuntu 16.04

[Masami Hiramatsu]

On Thu, 19 May 2016 09:06:42 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Thu, May 19, 2016 at 11:00:39AM +0900, Masami Hiramatsu escreveu:
> > On Mon, 16 May 2016 22:56:36 -0300
> > Arnaldo Carvalho de Melo  wrote:
> > >   Have you ever tried using 'perf probe' on ubuntu?
> 
> > > acme@ubuntu:~/git/linux$ sudo apt-cache search linux-image-$(uname -r)
> > > linux-image-4.4.0-21-generic - Linux kernel image for version 4.4.0 on
> > > 64 bit x86 SMP
> > > linux-image-4.4.0-21-generic-dbgsym - Linux kernel debug image for
> > > version 4.4.0 on 64 bit x86 SMP
> > > acme@ubuntu:~/git/linux$ 
> > > acme@ubuntu:~/git/linux$ 
> > > 
> > > So those are installed, but then I try:
> > > 
> > > root@ubuntu:~# perf probe -vvv -L getname_flags
> > > Looking at the vmlinux_path (8 entries long)
> > > Using /usr/lib/debug/boot/vmlinux-4.4.0-21-generic for symbols
> > > Open Debuginfo file: /usr/lib/debug/boot/vmlinux-4.4.0-21-generic
> > > fname: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c, lineno:125
> > > New line range: 125 to 2147483647
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> > > Get 3665 lines from this CU
> 
> Ah, why do we repeat the above line that many times? Are we somehow
> reading this compile unit that many times?!?

Yes, because the getname_flags is inlined by compiler, depends on the
parameter, some lines in the function are never compiled at some call
points. In this case, we have to check every call points so that all
the available lines are found.

BTW, "this CU" has no meaning, it should show the diename, or remove
the useless message.

> > > path: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c
> > > Failed to find source file path.
> > >   Error: Failed to show lines. Reason: No such file or directory (Code: 
> > > -2)
> > > root@ubuntu:~# 
> 
> > > Have to dig deeper to see where the source code is, ideas?
>  
> > It shows the "path" is ;
> > > path: /build/linux-Ay7j_C/linux-4.4.0/fs/namei.c
>  
> > So, would you have the source code under this temporary directory?
> > (yeah, I guess No)
> 
> No, and I couldn't find a package that had it
> 
> > Anyway, ubuntu has "linux-source" package, or apt source linux-image-`uname 
> > -r`
> > will give you the source tree in current dir.
>  
> > After you get a proper kernel source code, you can use -s to show source 
> > code.
>  
> > -s, --source 
> >   path to kernel source
>  
> > I ensured it is working correctly by below command.
> > $ perf probe -s ./linux-4.4.0 -L getname_flags
> 
> Ok, how about telling the user this package is needed, since we can
> figure out the distro and the package name?

Did we do that already?

> Couldn't it figure out where
> the source code is and also not require using '-s'?

No, actually, ubuntu/debian are not providing kernel source tree package
as redhat/fedora do. User can only download source tarball and extract
it under current working directory. There seems no standard directory
where the source code is extracted to. I think it's debian/ubuntu's
packaging policy.

Anyway, even though we can provide how-to guide for them via Documentation.
I think it's better way because we also have to add some entries to 
apt.conf for installing kernel debuginfo.

Thank you,

> 
> - Arnaldo


-- 
Masami Hiramatsu 

Re: [PATCH v2 2/9] powerpc/kvm: make hypervisor state restore a function

[Paul Mackerras]

On Tue, May 03, 2016 at 01:54:31PM +0530, Shreyas B. Prabhu wrote:
> In the current code, when the thread wakes up in reset vector, some
> of the state restore code and check for whether a thread needs to
> branch to kvm is duplicated. Reorder the code such that this
> duplication is avoided.

This is a nice cleanup.  The one minor comment I have is that since
power7_restore_hyp_resource has some unusual entry requirements (such
as requiring cr3 to be set a certain way), those requirements should
be documented in the comment just about the function entry point.  I
didn't see any unusual exit conditions, but if there are any they
should be documented too.

Reviewed-by: Paul Mackerras 

Re: [PATCH v2 2/9] powerpc/kvm: make hypervisor state restore a function

[Paul Mackerras]

On Tue, May 03, 2016 at 01:54:31PM +0530, Shreyas B. Prabhu wrote:
> In the current code, when the thread wakes up in reset vector, some
> of the state restore code and check for whether a thread needs to
> branch to kvm is duplicated. Reorder the code such that this
> duplication is avoided.

This is a nice cleanup.  The one minor comment I have is that since
power7_restore_hyp_resource has some unusual entry requirements (such
as requiring cr3 to be set a certain way), those requirements should
be documented in the comment just about the function entry point.  I
didn't see any unusual exit conditions, but if there are any they
should be documented too.

Reviewed-by: Paul Mackerras 

Re: [PATCH v3 3/5] mmc: core: implement enhanced strobe support

[Shawn Lin]

Hi

在 2016-5-20 10:45, Jaehoon Chung 写道:

On 05/10/2016 06:09 PM, Shawn Lin wrote:

Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.

Signed-off-by: Shawn Lin 
---

Changes in v3: None
Changes in v2: None

  drivers/mmc/core/bus.c   |  3 +-
  drivers/mmc/core/core.c  |  8 +
  drivers/mmc/core/mmc.c   | 79 ++--
  include/linux/mmc/card.h |  1 +
  include/linux/mmc/host.h | 11 +++
  include/linux/mmc/mmc.h  |  3 ++
  6 files changed, 102 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 4bc48f1..7e94b9d 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -332,12 +332,13 @@ int mmc_add_card(struct mmc_card *card)
mmc_card_ddr52(card) ? "DDR " : "",
type);
} else {
-   pr_info("%s: new %s%s%s%s%s card at address %04x\n",
+   pr_info("%s: new %s%s%s%s%s%s card at address %04x\n",
mmc_hostname(card->host),
mmc_card_uhs(card) ? "ultra high speed " :
(mmc_card_hs(card) ? "high speed " : ""),
mmc_card_hs400(card) ? "HS400 " :
(mmc_card_hs200(card) ? "HS200 " : ""),
+   mmc_card_hs400es(card) ? "Enhanced strobe" : "",
mmc_card_ddr52(card) ? "DDR " : "",
uhs_bus_speed_mode, type, card->rca);
}
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 99275e4..a559501 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1127,6 +1127,14 @@ void mmc_set_initial_state(struct mmc_host *host)
host->ios.bus_width = MMC_BUS_WIDTH_1;
host->ios.timing = MMC_TIMING_LEGACY;
host->ios.drv_type = 0;
+   host->ios.enhanced_strobe = false;
+
+   /*
+* Make sure we are in non-enhanced strobe mode before we
+* actually enable it in ext_csd.
+*/
+   if (host->ops->hs400_enhanced_strobe)
+   host->ops->hs400_enhanced_strobe(host, >ios);

mmc_set_ios(host);
  }
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f99c47e..c2d1981 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -235,6 +235,11 @@ static void mmc_select_card_type(struct mmc_card *card)
avail_type |= EXT_CSD_CARD_TYPE_HS400_1_2V;
}

+   if ((caps2 & MMC_CAP2_HS400_ES) &&
+   card->ext_csd.strobe_support &&
+   (card_type & EXT_CSD_CARD_TYPE_HS400))
+   avail_type |= EXT_CSD_CARD_TYPE_HS400ES;


Does it need to check whether support HS400_1.8V/1.2V or not?
It should be more stable than now.



Ahh, right.
I need to add "avail_type & EXT_CSD_CARD_TYPE_HS400" instead of
"card_type & EXT_CSD_CARD_TYPE_HS400"... because if "avail_type &
EXT_CSD_CARD_TYPE_HS400" is true, it implies that "card_type & 
EXT_CSD_CARD_TYPE_HS400" must be true.



Thansk for catching this!



if (avail_type & (EXT_CSD_CARD_TYPE_HS400_1.8V | EXT_CSD_CARD_TYPE_HS400_1.2V)) 
{
if ((cap2 & MMC_CAP2_HS400_ES) && ...
}

how about this?

Best Regards,
Jaehoon Chung


+
card->ext_csd.hs_max_dtr = hs_max_dtr;
card->ext_csd.hs200_max_dtr = hs200_max_dtr;
card->mmc_avail_type = avail_type;
@@ -383,6 +388,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
mmc_card_set_blockaddr(card);
}

+   card->ext_csd.strobe_support = ext_csd[EXT_CSD_STROBE_SUPPORT];
card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
mmc_select_card_type(card);

@@ -1216,6 +1222,73 @@ out_err:
return err;
  }

+static int mmc_select_hs400es(struct mmc_card *card)
+{
+   struct mmc_host *host = card->host;
+   int err = 0;
+   u8 val;
+
+   err = mmc_select_bus_width(card);
+   if (IS_ERR_VALUE(err))
+   goto out_err;
+
+   /* Switch card to HS mode */
+   err = mmc_select_hs(card);
+   if (err) {
+   pr_err("%s: switch to high-speed failed, err:%d\n",
+   mmc_hostname(host), err);
+   goto out_err;
+   }
+
+   err = mmc_switch_status(card);
+   if (err)
+   goto out_err;
+
+   /* Switch card to DDR with strobe bit */
+   val = EXT_CSD_DDR_BUS_WIDTH_8 | EXT_CSD_BUS_WIDTH_STROBE;
+   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BUS_WIDTH,
+val,
+card->ext_csd.generic_cmd6_time);
+   if (err) {
+   pr_err("%s: switch to 

Re: [PATCH v3 3/5] mmc: core: implement enhanced strobe support

[Shawn Lin]

Hi

在 2016-5-20 10:45, Jaehoon Chung 写道:

On 05/10/2016 06:09 PM, Shawn Lin wrote:

Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.

Signed-off-by: Shawn Lin 
---

Changes in v3: None
Changes in v2: None

  drivers/mmc/core/bus.c   |  3 +-
  drivers/mmc/core/core.c  |  8 +
  drivers/mmc/core/mmc.c   | 79 ++--
  include/linux/mmc/card.h |  1 +
  include/linux/mmc/host.h | 11 +++
  include/linux/mmc/mmc.h  |  3 ++
  6 files changed, 102 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 4bc48f1..7e94b9d 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -332,12 +332,13 @@ int mmc_add_card(struct mmc_card *card)
mmc_card_ddr52(card) ? "DDR " : "",
type);
} else {
-   pr_info("%s: new %s%s%s%s%s card at address %04x\n",
+   pr_info("%s: new %s%s%s%s%s%s card at address %04x\n",
mmc_hostname(card->host),
mmc_card_uhs(card) ? "ultra high speed " :
(mmc_card_hs(card) ? "high speed " : ""),
mmc_card_hs400(card) ? "HS400 " :
(mmc_card_hs200(card) ? "HS200 " : ""),
+   mmc_card_hs400es(card) ? "Enhanced strobe" : "",
mmc_card_ddr52(card) ? "DDR " : "",
uhs_bus_speed_mode, type, card->rca);
}
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 99275e4..a559501 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1127,6 +1127,14 @@ void mmc_set_initial_state(struct mmc_host *host)
host->ios.bus_width = MMC_BUS_WIDTH_1;
host->ios.timing = MMC_TIMING_LEGACY;
host->ios.drv_type = 0;
+   host->ios.enhanced_strobe = false;
+
+   /*
+* Make sure we are in non-enhanced strobe mode before we
+* actually enable it in ext_csd.
+*/
+   if (host->ops->hs400_enhanced_strobe)
+   host->ops->hs400_enhanced_strobe(host, >ios);

mmc_set_ios(host);
  }
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index f99c47e..c2d1981 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -235,6 +235,11 @@ static void mmc_select_card_type(struct mmc_card *card)
avail_type |= EXT_CSD_CARD_TYPE_HS400_1_2V;
}

+   if ((caps2 & MMC_CAP2_HS400_ES) &&
+   card->ext_csd.strobe_support &&
+   (card_type & EXT_CSD_CARD_TYPE_HS400))
+   avail_type |= EXT_CSD_CARD_TYPE_HS400ES;


Does it need to check whether support HS400_1.8V/1.2V or not?
It should be more stable than now.



Ahh, right.
I need to add "avail_type & EXT_CSD_CARD_TYPE_HS400" instead of
"card_type & EXT_CSD_CARD_TYPE_HS400"... because if "avail_type &
EXT_CSD_CARD_TYPE_HS400" is true, it implies that "card_type & 
EXT_CSD_CARD_TYPE_HS400" must be true.



Thansk for catching this!



if (avail_type & (EXT_CSD_CARD_TYPE_HS400_1.8V | EXT_CSD_CARD_TYPE_HS400_1.2V)) 
{
if ((cap2 & MMC_CAP2_HS400_ES) && ...
}

how about this?

Best Regards,
Jaehoon Chung


+
card->ext_csd.hs_max_dtr = hs_max_dtr;
card->ext_csd.hs200_max_dtr = hs200_max_dtr;
card->mmc_avail_type = avail_type;
@@ -383,6 +388,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
mmc_card_set_blockaddr(card);
}

+   card->ext_csd.strobe_support = ext_csd[EXT_CSD_STROBE_SUPPORT];
card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
mmc_select_card_type(card);

@@ -1216,6 +1222,73 @@ out_err:
return err;
  }

+static int mmc_select_hs400es(struct mmc_card *card)
+{
+   struct mmc_host *host = card->host;
+   int err = 0;
+   u8 val;
+
+   err = mmc_select_bus_width(card);
+   if (IS_ERR_VALUE(err))
+   goto out_err;
+
+   /* Switch card to HS mode */
+   err = mmc_select_hs(card);
+   if (err) {
+   pr_err("%s: switch to high-speed failed, err:%d\n",
+   mmc_hostname(host), err);
+   goto out_err;
+   }
+
+   err = mmc_switch_status(card);
+   if (err)
+   goto out_err;
+
+   /* Switch card to DDR with strobe bit */
+   val = EXT_CSD_DDR_BUS_WIDTH_8 | EXT_CSD_BUS_WIDTH_STROBE;
+   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BUS_WIDTH,
+val,
+card->ext_csd.generic_cmd6_time);
+   if (err) {
+   pr_err("%s: switch to bus width for hs400es 

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

[Steve French]

I fixed the build break (and some trivial compile warnings) due to the
change to the format of keyring_alloc and repushed the *"cifs: Create
dedicated keyring for spnego operations" patch to cifs-2.6.git
for-next

On Thu, May 19, 2016 at 6:14 PM, Stephen Rothwell  wrote:
> Hi Steve,
>
> On Thu, 19 May 2016 14:01:20 +1000 Stephen Rothwell  
> wrote:
>>
>> After merging the security tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> fs/cifs/cifs_spnego.c: In function 'init_cifs_spnego':
>> fs/cifs/cifs_spnego.c:206:12: error: too few arguments to function 
>> 'keyring_alloc'
>>   keyring = keyring_alloc(".cifs_spnego",
>> ^
>> In file included from include/linux/cred.h:17:0,
>>  from include/linux/sched.h:56,
>>  from include/linux/kasan.h:4,
>>  from include/linux/slab.h:118,
>>  from fs/cifs/cifs_spnego.c:23:
>> include/linux/key.h:302:20: note: declared here
>>  extern struct key *keyring_alloc(const char *description, kuid_t uid, 
>> kgid_t gid,
>> ^
>>
>> Caused by commit
>>
>>   5b82c5cbcfe4 ("cifs: Create dedicated keyring for spnego operations")
>>
>> from the cifs tree interacting with commit
>>
>>   5ac7eace2d00 ("KEYS: Add a facility to restrict new links into a keyring")
>>
>> from the security tree.
>>
>> I added the following merge fix patch (and someone will have to let
>> Linus know):
>>
>> From: Stephen Rothwell 
>> Date: Thu, 19 May 2016 13:45:10 +1000
>> Subject: [PATCH] cifs: fix for keyringalloc() API change
>>
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  fs/cifs/cifs_spnego.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/cifs/cifs_spnego.c b/fs/cifs/cifs_spnego.c
>> index 248ab431930c..9ef0dfcb2f95 100644
>> --- a/fs/cifs/cifs_spnego.c
>> +++ b/fs/cifs/cifs_spnego.c
>> @@ -207,7 +207,7 @@ init_cifs_spnego(void)
>>   GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, cred,
>>   (KEY_POS_ALL & ~KEY_POS_SETATTR) |
>>   KEY_USR_VIEW | KEY_USR_READ,
>> - KEY_ALLOC_NOT_IN_QUOTA, NULL);
>> + KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);
>>   if (IS_ERR(keyring)) {
>>   ret = PTR_ERR(keyring);
>>   goto failed_put_cred;
>> --
>> 2.7.0
>
> The security tree has now been merged into Linus' tree, so this build
> breakage occurs when I merge the cifs tree.  So you will need to tell
> Linus about this needed fixup when he merges the cifs tree.
>
> --
> Cheers,
> Stephen Rothwell



-- 
Thanks,

Steve

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

[Steve French]

I fixed the build break (and some trivial compile warnings) due to the
change to the format of keyring_alloc and repushed the *"cifs: Create
dedicated keyring for spnego operations" patch to cifs-2.6.git
for-next

On Thu, May 19, 2016 at 6:14 PM, Stephen Rothwell  wrote:
> Hi Steve,
>
> On Thu, 19 May 2016 14:01:20 +1000 Stephen Rothwell  
> wrote:
>>
>> After merging the security tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> fs/cifs/cifs_spnego.c: In function 'init_cifs_spnego':
>> fs/cifs/cifs_spnego.c:206:12: error: too few arguments to function 
>> 'keyring_alloc'
>>   keyring = keyring_alloc(".cifs_spnego",
>> ^
>> In file included from include/linux/cred.h:17:0,
>>  from include/linux/sched.h:56,
>>  from include/linux/kasan.h:4,
>>  from include/linux/slab.h:118,
>>  from fs/cifs/cifs_spnego.c:23:
>> include/linux/key.h:302:20: note: declared here
>>  extern struct key *keyring_alloc(const char *description, kuid_t uid, 
>> kgid_t gid,
>> ^
>>
>> Caused by commit
>>
>>   5b82c5cbcfe4 ("cifs: Create dedicated keyring for spnego operations")
>>
>> from the cifs tree interacting with commit
>>
>>   5ac7eace2d00 ("KEYS: Add a facility to restrict new links into a keyring")
>>
>> from the security tree.
>>
>> I added the following merge fix patch (and someone will have to let
>> Linus know):
>>
>> From: Stephen Rothwell 
>> Date: Thu, 19 May 2016 13:45:10 +1000
>> Subject: [PATCH] cifs: fix for keyringalloc() API change
>>
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  fs/cifs/cifs_spnego.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/cifs/cifs_spnego.c b/fs/cifs/cifs_spnego.c
>> index 248ab431930c..9ef0dfcb2f95 100644
>> --- a/fs/cifs/cifs_spnego.c
>> +++ b/fs/cifs/cifs_spnego.c
>> @@ -207,7 +207,7 @@ init_cifs_spnego(void)
>>   GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, cred,
>>   (KEY_POS_ALL & ~KEY_POS_SETATTR) |
>>   KEY_USR_VIEW | KEY_USR_READ,
>> - KEY_ALLOC_NOT_IN_QUOTA, NULL);
>> + KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);
>>   if (IS_ERR(keyring)) {
>>   ret = PTR_ERR(keyring);
>>   goto failed_put_cred;
>> --
>> 2.7.0
>
> The security tree has now been merged into Linus' tree, so this build
> breakage occurs when I merge the cifs tree.  So you will need to tell
> Linus about this needed fixup when he merges the cifs tree.
>
> --
> Cheers,
> Stephen Rothwell



-- 
Thanks,

Steve

Re: linux-next 20160512 - ACPI issue with screen brightness

[Valdis . Kletnieks]

On Thu, 19 May 2016 18:53:17 -0400, valdis.kletni...@vt.edu said:

> > > next-20160512 sets the screen brightness to about 40%-ish or so, rather
> > > than the 100% intensity I want.

> Put this one in the "things that go bump in the night" pile - the problem
> doesn't manifest on next-20160519, even though the commit I bisected to
> is in the tree for today, and I don't see any obvious smoking guns to
> have fixed it in the past week's worth of 'git log'

Actually, put it in "things that go bump in the night but need a stake driven
through them"- it looks like I booted the wrong kernel while testing, and in
fact next-20160519 *is* still broken.  However, after:

git revert -n e4f35c1339f0cfcf38d3f63dd6fea2b070399263
git revert -n 059500940defe285222d3b189b366dfe7f299cae

Things work again.


pgpqeMj8T6Gef.pgp
Description: PGP signature

Re: linux-next 20160512 - ACPI issue with screen brightness

[Valdis . Kletnieks]

On Thu, 19 May 2016 18:53:17 -0400, valdis.kletni...@vt.edu said:

> > > next-20160512 sets the screen brightness to about 40%-ish or so, rather
> > > than the 100% intensity I want.

> Put this one in the "things that go bump in the night" pile - the problem
> doesn't manifest on next-20160519, even though the commit I bisected to
> is in the tree for today, and I don't see any obvious smoking guns to
> have fixed it in the past week's worth of 'git log'

Actually, put it in "things that go bump in the night but need a stake driven
through them"- it looks like I booted the wrong kernel while testing, and in
fact next-20160519 *is* still broken.  However, after:

git revert -n e4f35c1339f0cfcf38d3f63dd6fea2b070399263
git revert -n 059500940defe285222d3b189b366dfe7f299cae

Things work again.


pgpqeMj8T6Gef.pgp
Description: PGP signature

Re: [PATCH v4 2/6] perf tools: Promote proper messages for cross-platform unwind

[Hekuang]

在 2016/5/20 0:19, Jiri Olsa 写道:

On Thu, May 19, 2016 at 11:50:10AM -0300, Arnaldo Carvalho de Melo wrote:

Em Thu, May 19, 2016 at 11:47:38AM +, He Kuang escreveu:

Currently, perf script uses host unwind methods to parse perf.data
callchain info regardless of the target architecture. So we get wrong
result and no promotion when unwinding callchains of x86(32-bit) on

What you mean by "promotion" here? Can you use some other synonym so
that I can make sense of this description?

I'd say something like: s/and no promotion/without any warning/

jirka


Yes, that's what I want to express.

Re: [PATCH v4 2/6] perf tools: Promote proper messages for cross-platform unwind

[Hekuang]

在 2016/5/20 0:19, Jiri Olsa 写道:

On Thu, May 19, 2016 at 11:50:10AM -0300, Arnaldo Carvalho de Melo wrote:

Em Thu, May 19, 2016 at 11:47:38AM +, He Kuang escreveu:

Currently, perf script uses host unwind methods to parse perf.data
callchain info regardless of the target architecture. So we get wrong
result and no promotion when unwinding callchains of x86(32-bit) on

What you mean by "promotion" here? Can you use some other synonym so
that I can make sense of this description?

I'd say something like: s/and no promotion/without any warning/

jirka


Yes, that's what I want to express.

Re: [PATCH v4 2/6] perf tools: Promote proper messages for cross-platform unwind

[Hekuang]

hi

在 2016/5/20 0:46, Jiri Olsa 写道:

On Thu, May 19, 2016 at 11:47:38AM +, He Kuang wrote:

SNIP


  #endif /* ARCH_PERF_COMMON_H */
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 1e46277..a86b864 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -345,6 +345,12 @@ ifeq ($(ARCH),powerpc)
  endif
  
  ifndef NO_LIBUNWIND

+  ifeq ($(feature-libunwind-x86), 1)
+LIBUNWIND_LIBS += -lunwind-x86
+$(call detected,CONFIG_LIBUNWIND_X86)
+CFLAGS += -DHAVE_LIBUNWIND_X86_SUPPORT
+  endif
+

how does one install that lirary?

thanks,
jirka


My work environment is on an old suse distribution, so it's
difficult to find libunwind-$arch rpm packages, so I build them
from source.

The git repository url is here:
http://git.savannah.gnu.org/r/libunwind.git(master)

Then flow the build step in README, first for i686:

  $ ./autogen.sh
  $ ./configure prefix=/xx/dst_i686 --target=i686-oe-linux 
CC=x86_64-oe-linux-gcc

  $ make && make install

Similar for aarch64:

  $ make clean
  $ ./configure prefix=/xx/dst_aarch64 --target=i686-oe-linux 
CC=x86_64-oe-linux-gcc

  $ make && make install

NOTICE: the contents in '--target' should be like
'i686-oe-linux', only give 'i686' cause strange build errors.

It looks like that libunwind don't support building for multiple
platforms at the same time, so I build them separately into
different directories.

Finally, copy the outputs into /usr/include and /usr/lib64, now
perf can detect them:

  $ make VF=1 ARCH=x86_64 CROSS_COMPILE=x86_64-oe-linux- 
EXTRA_CFLAGS="-m64"

  ...

  ... libunwind-x86: [ on  ]
  ...  libunwind-x86_64: [ OFF ]
  ... libunwind-arm: [ OFF ]
  ... libunwind-aarch64: [ on  ]

Thanks.

Re: [PATCH v4 2/6] perf tools: Promote proper messages for cross-platform unwind

[Hekuang]

hi

在 2016/5/20 0:46, Jiri Olsa 写道:

On Thu, May 19, 2016 at 11:47:38AM +, He Kuang wrote:

SNIP


  #endif /* ARCH_PERF_COMMON_H */
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 1e46277..a86b864 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -345,6 +345,12 @@ ifeq ($(ARCH),powerpc)
  endif
  
  ifndef NO_LIBUNWIND

+  ifeq ($(feature-libunwind-x86), 1)
+LIBUNWIND_LIBS += -lunwind-x86
+$(call detected,CONFIG_LIBUNWIND_X86)
+CFLAGS += -DHAVE_LIBUNWIND_X86_SUPPORT
+  endif
+

how does one install that lirary?

thanks,
jirka


My work environment is on an old suse distribution, so it's
difficult to find libunwind-$arch rpm packages, so I build them
from source.

The git repository url is here:
http://git.savannah.gnu.org/r/libunwind.git(master)

Then flow the build step in README, first for i686:

  $ ./autogen.sh
  $ ./configure prefix=/xx/dst_i686 --target=i686-oe-linux 
CC=x86_64-oe-linux-gcc

  $ make && make install

Similar for aarch64:

  $ make clean
  $ ./configure prefix=/xx/dst_aarch64 --target=i686-oe-linux 
CC=x86_64-oe-linux-gcc

  $ make && make install

NOTICE: the contents in '--target' should be like
'i686-oe-linux', only give 'i686' cause strange build errors.

It looks like that libunwind don't support building for multiple
platforms at the same time, so I build them separately into
different directories.

Finally, copy the outputs into /usr/include and /usr/lib64, now
perf can detect them:

  $ make VF=1 ARCH=x86_64 CROSS_COMPILE=x86_64-oe-linux- 
EXTRA_CFLAGS="-m64"

  ...

  ... libunwind-x86: [ on  ]
  ...  libunwind-x86_64: [ OFF ]
  ... libunwind-arm: [ OFF ]
  ... libunwind-aarch64: [ on  ]

Thanks.

mmotm 2016-05-19-19-59 uploaded

[akpm]

The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.6:
(patches marked "*" will be included in linux-next)

  origin.patch
* fsnotify-avoid-spurious-emfile-errors-from-inotify_init.patch
* time-add-missing-implementation-for-timespec64_add_safe.patch
* fs-poll-select-recvmmsg-use-timespec64-for-timeout-events.patch
* time-remove-timespec_add_safe.patch
* scripts-decode_stacktracesh-handle-symbols-in-modules.patch
* scripts-spellingtxt-add-fimware-misspelling.patch
* scripts-bloat-o-meter-print-percent-change.patch
* debugobjects-make-fixup-functions-return-bool-instead-of-int.patch
* debugobjects-correct-the-usage-of-fixup-call-results.patch
* workqueue-update-debugobjects-fixup-callbacks-return-type.patch
* timer-update-debugobjects-fixup-callbacks-return-type.patch
* rcu-update-debugobjects-fixup-callbacks-return-type.patch
* percpu_counter-update-debugobjects-fixup-callbacks-return-type.patch
* documentation-update-debugobjects-doc.patch
* 
debugobjects-insulate-non-fixup-logic-related-to-static-obj-from-fixup-callbacks.patch
* 
ocfs2-error-code-comments-and-amendments-the-comment-of-ocfs2_extended_slot-should-be-0x08.patch
* ocfs2-clean-up-an-unused-variable-wants_rotate-in-ocfs2_truncate_rec.patch
* ocfs2-clean-up-unused-parameter-count-in-o2hb_read_block_input.patch
* ocfs2-clean-up-an-unuseful-goto-in-ocfs2_put_slot-function.patch
* padata-removed-unused-code.patch
* kernel-padata-hide-unused-functions.patch
* mm-slab-fix-the-theoretical-race-by-holding-proper-lock.patch
* mm-slab-remove-bad_alien_magic-again.patch
* mm-slab-drain-the-free-slab-as-much-as-possible.patch
* mm-slab-factor-out-kmem_cache_node-initialization-code.patch
* mm-slab-clean-up-kmem_cache_node-setup.patch
* mm-slab-dont-keep-free-slabs-if-free_objects-exceeds-free_limit.patch
* mm-slab-racy-access-modify-the-slab-color.patch
* mm-slab-make-cache_grow-handle-the-page-allocated-on-arbitrary-node.patch
* mm-slab-separate-cache_grow-to-two-parts.patch
* mm-slab-refill-cpu-cache-through-a-new-slab-without-holding-a-node-lock.patch
* mm-slab-lockless-decision-to-grow-cache.patch
* 
mm-slub-replace-kick_all_cpus_sync-with-synchronize_sched-in-kmem_cache_shrink.patch
* mm-slab-freelist-randomization-v4.patch
* mm-slab-remove-zone_dma_flag.patch
* mm-slubc-fix-sysfs-filename-in-comment.patch
* mm-page_ref-use-page_ref-helper-instead-of-direct-modification-of-_count.patch
* mm-rename-_count-field-of-the-struct-page-to-_refcount.patch
* compilerh-add-support-for-malloc-attribute.patch
* include-linux-apply-__malloc-attribute.patch
* include-linux-nodemaskh-create-next_node_in-helper.patch
* 

mmotm 2016-05-19-19-59 uploaded

[akpm]

The mm-of-the-moment snapshot 2016-05-19-19-59 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.6:
(patches marked "*" will be included in linux-next)

  origin.patch
* fsnotify-avoid-spurious-emfile-errors-from-inotify_init.patch
* time-add-missing-implementation-for-timespec64_add_safe.patch
* fs-poll-select-recvmmsg-use-timespec64-for-timeout-events.patch
* time-remove-timespec_add_safe.patch
* scripts-decode_stacktracesh-handle-symbols-in-modules.patch
* scripts-spellingtxt-add-fimware-misspelling.patch
* scripts-bloat-o-meter-print-percent-change.patch
* debugobjects-make-fixup-functions-return-bool-instead-of-int.patch
* debugobjects-correct-the-usage-of-fixup-call-results.patch
* workqueue-update-debugobjects-fixup-callbacks-return-type.patch
* timer-update-debugobjects-fixup-callbacks-return-type.patch
* rcu-update-debugobjects-fixup-callbacks-return-type.patch
* percpu_counter-update-debugobjects-fixup-callbacks-return-type.patch
* documentation-update-debugobjects-doc.patch
* 
debugobjects-insulate-non-fixup-logic-related-to-static-obj-from-fixup-callbacks.patch
* 
ocfs2-error-code-comments-and-amendments-the-comment-of-ocfs2_extended_slot-should-be-0x08.patch
* ocfs2-clean-up-an-unused-variable-wants_rotate-in-ocfs2_truncate_rec.patch
* ocfs2-clean-up-unused-parameter-count-in-o2hb_read_block_input.patch
* ocfs2-clean-up-an-unuseful-goto-in-ocfs2_put_slot-function.patch
* padata-removed-unused-code.patch
* kernel-padata-hide-unused-functions.patch
* mm-slab-fix-the-theoretical-race-by-holding-proper-lock.patch
* mm-slab-remove-bad_alien_magic-again.patch
* mm-slab-drain-the-free-slab-as-much-as-possible.patch
* mm-slab-factor-out-kmem_cache_node-initialization-code.patch
* mm-slab-clean-up-kmem_cache_node-setup.patch
* mm-slab-dont-keep-free-slabs-if-free_objects-exceeds-free_limit.patch
* mm-slab-racy-access-modify-the-slab-color.patch
* mm-slab-make-cache_grow-handle-the-page-allocated-on-arbitrary-node.patch
* mm-slab-separate-cache_grow-to-two-parts.patch
* mm-slab-refill-cpu-cache-through-a-new-slab-without-holding-a-node-lock.patch
* mm-slab-lockless-decision-to-grow-cache.patch
* 
mm-slub-replace-kick_all_cpus_sync-with-synchronize_sched-in-kmem_cache_shrink.patch
* mm-slab-freelist-randomization-v4.patch
* mm-slab-remove-zone_dma_flag.patch
* mm-slubc-fix-sysfs-filename-in-comment.patch
* mm-page_ref-use-page_ref-helper-instead-of-direct-modification-of-_count.patch
* mm-rename-_count-field-of-the-struct-page-to-_refcount.patch
* compilerh-add-support-for-malloc-attribute.patch
* include-linux-apply-__malloc-attribute.patch
* include-linux-nodemaskh-create-next_node_in-helper.patch
* 

Re: mmotm 2016-05-19-18-01 uploaded

[Andrew Morton]

On Fri, 20 May 2016 12:37:15 +1000 Stephen Rothwell  
wrote:

> Hi Andrew,
> 
> On Thu, 19 May 2016 18:02:16 -0700 a...@linux-foundation.org wrote:
> >
> > The mm-of-the-moment snapshot 2016-05-19-18-01 has been uploaded to
> > 
> >http://www.ozlabs.org/~akpm/mmotm/
>   .
>   .
> >   mm-page_alloc-defer-debugging-checks-of-pages-allocated-from-the-pcp.patch
> >   mm-page_alloc-dont-duplicate-code-in-free_pcp_prepare.patch
> >   mm-page_alloc-uninline-the-bad-page-part-of-check_new_page.patch
> >   
> > mm-page_alloc-restore-the-original-nodemask-if-the-fast-path-allocation-failed.patch
> 
> Is that all there is?  No linux-next patch?

oop, let me try that again.

Re: mmotm 2016-05-19-18-01 uploaded

[Andrew Morton]

On Fri, 20 May 2016 12:37:15 +1000 Stephen Rothwell  
wrote:

> Hi Andrew,
> 
> On Thu, 19 May 2016 18:02:16 -0700 a...@linux-foundation.org wrote:
> >
> > The mm-of-the-moment snapshot 2016-05-19-18-01 has been uploaded to
> > 
> >http://www.ozlabs.org/~akpm/mmotm/
>   .
>   .
> >   mm-page_alloc-defer-debugging-checks-of-pages-allocated-from-the-pcp.patch
> >   mm-page_alloc-dont-duplicate-code-in-free_pcp_prepare.patch
> >   mm-page_alloc-uninline-the-bad-page-part-of-check_new_page.patch
> >   
> > mm-page_alloc-restore-the-original-nodemask-if-the-fast-path-allocation-failed.patch
> 
> Is that all there is?  No linux-next patch?

oop, let me try that again.

[PATCH v2 07/12] sh: add AT_HWCAP flag for J-Core cas.l instruction

[Rich Felker]

Signed-off-by: Rich Felker 
---
 arch/sh/include/uapi/asm/cpu-features.h | 1 +
 arch/sh/kernel/cpu/sh2/probe.c  | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/sh/include/uapi/asm/cpu-features.h 
b/arch/sh/include/uapi/asm/cpu-features.h
index 694abe4..2f1bc85 100644
--- a/arch/sh/include/uapi/asm/cpu-features.h
+++ b/arch/sh/include/uapi/asm/cpu-features.h
@@ -22,5 +22,6 @@
 #define CPU_HAS_L2_CACHE   0x0080  /* Secondary cache / URAM */
 #define CPU_HAS_OP32   0x0100  /* 32-bit instruction support */
 #define CPU_HAS_PTEAEX 0x0200  /* PTE ASID Extension support */
+#define CPU_HAS_CAS_L  0x0400  /* cas.l atomic compare-and-swap */
 
 #endif /* __ASM_SH_CPU_FEATURES_H */
diff --git a/arch/sh/kernel/cpu/sh2/probe.c b/arch/sh/kernel/cpu/sh2/probe.c
index 3dd8187..665fcfb 100644
--- a/arch/sh/kernel/cpu/sh2/probe.c
+++ b/arch/sh/kernel/cpu/sh2/probe.c
@@ -54,6 +54,8 @@ void __ref cpu_probe(void)
boot_cpu_data.dcache.entry_shift= 5;
boot_cpu_data.dcache.linesz = 32;
boot_cpu_data.dcache.flags  = 0;
+
+   boot_cpu_data.flags |= CPU_HAS_CAS_L;
 #else
/*
 * SH-2 doesn't have separate caches
-- 
2.8.1

[PATCH v2 07/12] sh: add AT_HWCAP flag for J-Core cas.l instruction

[Rich Felker]

Signed-off-by: Rich Felker 
---
 arch/sh/include/uapi/asm/cpu-features.h | 1 +
 arch/sh/kernel/cpu/sh2/probe.c  | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/sh/include/uapi/asm/cpu-features.h 
b/arch/sh/include/uapi/asm/cpu-features.h
index 694abe4..2f1bc85 100644
--- a/arch/sh/include/uapi/asm/cpu-features.h
+++ b/arch/sh/include/uapi/asm/cpu-features.h
@@ -22,5 +22,6 @@
 #define CPU_HAS_L2_CACHE   0x0080  /* Secondary cache / URAM */
 #define CPU_HAS_OP32   0x0100  /* 32-bit instruction support */
 #define CPU_HAS_PTEAEX 0x0200  /* PTE ASID Extension support */
+#define CPU_HAS_CAS_L  0x0400  /* cas.l atomic compare-and-swap */
 
 #endif /* __ASM_SH_CPU_FEATURES_H */
diff --git a/arch/sh/kernel/cpu/sh2/probe.c b/arch/sh/kernel/cpu/sh2/probe.c
index 3dd8187..665fcfb 100644
--- a/arch/sh/kernel/cpu/sh2/probe.c
+++ b/arch/sh/kernel/cpu/sh2/probe.c
@@ -54,6 +54,8 @@ void __ref cpu_probe(void)
boot_cpu_data.dcache.entry_shift= 5;
boot_cpu_data.dcache.linesz = 32;
boot_cpu_data.dcache.flags  = 0;
+
+   boot_cpu_data.flags |= CPU_HAS_CAS_L;
 #else
/*
 * SH-2 doesn't have separate caches
-- 
2.8.1