Re: [PATCH 15/16] apparmor: Replace spin_is_locked() with lockdep

[John Johansen]

On 10/02/2018 10:39 PM, Lance Roy wrote:
> lockdep_assert_held() is better suited to checking locking requirements,
> since it won't get confused when someone else holds the lock. This is
> also a step towards possibly removing spin_is_locked().
> 
> Signed-off-by: Lance Roy 
> Cc: John Johansen 
> Cc: James Morris 
> Cc: "Serge E. Hallyn" 
> Cc: 

Acked-by: John Johansen 

> ---
>  security/apparmor/file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index 4285943f7260..d0afed9ebd0e 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -496,7 +496,7 @@ static void update_file_ctx(struct aa_file_ctx *fctx, 
> struct aa_label *label,
>   /* update caching of label on file_ctx */
>   spin_lock(>lock);
>   old = rcu_dereference_protected(fctx->label,
> - spin_is_locked(>lock));
> + lockdep_is_held(>lock));
>   l = aa_label_merge(old, label, GFP_ATOMIC);
>   if (l) {
>   if (l != old) {
> 

Re: [PATCH 15/16] apparmor: Replace spin_is_locked() with lockdep

[John Johansen]

On 10/02/2018 10:39 PM, Lance Roy wrote:
> lockdep_assert_held() is better suited to checking locking requirements,
> since it won't get confused when someone else holds the lock. This is
> also a step towards possibly removing spin_is_locked().
> 
> Signed-off-by: Lance Roy 
> Cc: John Johansen 
> Cc: James Morris 
> Cc: "Serge E. Hallyn" 
> Cc: 

Acked-by: John Johansen 

> ---
>  security/apparmor/file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index 4285943f7260..d0afed9ebd0e 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -496,7 +496,7 @@ static void update_file_ctx(struct aa_file_ctx *fctx, 
> struct aa_label *label,
>   /* update caching of label on file_ctx */
>   spin_lock(>lock);
>   old = rcu_dereference_protected(fctx->label,
> - spin_is_locked(>lock));
> + lockdep_is_held(>lock));
>   l = aa_label_merge(old, label, GFP_ATOMIC);
>   if (l) {
>   if (l != old) {
> 

[PATCH 01/16] x86/PCI: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Bjorn Helgaas 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: 
Cc: 
---
 arch/x86/pci/i386.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index ed4ac215305d..24bb58a007de 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -59,7 +59,7 @@ static struct pcibios_fwaddrmap 
*pcibios_fwaddrmap_lookup(struct pci_dev *dev)
 {
struct pcibios_fwaddrmap *map;
 
-   WARN_ON_SMP(!spin_is_locked(_fwaddrmap_lock));
+   lockdep_assert_held(_fwaddrmap_lock);
 
list_for_each_entry(map, _fwaddrmappings, list)
if (map->dev == dev)
-- 
2.19.0

[PATCH 01/16] x86/PCI: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Bjorn Helgaas 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: 
Cc: 
---
 arch/x86/pci/i386.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index ed4ac215305d..24bb58a007de 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -59,7 +59,7 @@ static struct pcibios_fwaddrmap 
*pcibios_fwaddrmap_lookup(struct pci_dev *dev)
 {
struct pcibios_fwaddrmap *map;
 
-   WARN_ON_SMP(!spin_is_locked(_fwaddrmap_lock));
+   lockdep_assert_held(_fwaddrmap_lock);
 
list_for_each_entry(map, _fwaddrmappings, list)
if (map->dev == dev)
-- 
2.19.0

[PATCH 10/16] userfaultfd: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Alexander Viro 
Cc: 
---
 fs/userfaultfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index bfa0ec69f924..a20244ff0027 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -926,7 +926,7 @@ static inline struct userfaultfd_wait_queue 
*find_userfault_in(
wait_queue_entry_t *wq;
struct userfaultfd_wait_queue *uwq;
 
-   VM_BUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
uwq = NULL;
if (!waitqueue_active(wqh))
-- 
2.19.0

[PATCH 10/16] userfaultfd: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Alexander Viro 
Cc: 
---
 fs/userfaultfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index bfa0ec69f924..a20244ff0027 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -926,7 +926,7 @@ static inline struct userfaultfd_wait_queue 
*find_userfault_in(
wait_queue_entry_t *wq;
struct userfaultfd_wait_queue *uwq;
 
-   VM_BUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
uwq = NULL;
if (!waitqueue_active(wqh))
-- 
2.19.0

Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call

[John Hubbard]

On 10/1/18 7:35 AM, Dennis Dalessandro wrote:
> On 9/28/2018 11:12 PM, John Hubbard wrote:
>> On 9/28/18 8:39 AM, Jason Gunthorpe wrote:
>>> On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
 From: John Hubbard 
>> [...]

 diff --git a/drivers/infiniband/core/umem.c 
 b/drivers/infiniband/core/umem.c
 index a41792dbae1f..9430d697cb9f 100644
 +++ b/drivers/infiniband/core/umem.c
 @@ -60,7 +60,7 @@ static void __ib_umem_release(struct ib_device *dev, 
 struct ib_umem *umem, int d
   page = sg_page(sg);
   if (!PageDirty(page) && umem->writable && dirty)
   set_page_dirty_lock(page);
 -    put_page(page);
 +    put_user_page(page);
>>>
>>> Would it make sense to have a release/put_user_pages_dirtied to absorb
>>> the set_page_dity pattern too? I notice in this patch there is some
>>> variety here, I wonder what is the right way?
>>>
>>> Also, I'm told this code here is a big performance bottleneck when the
>>> number of pages becomes very long (think >> GB of memory), so having a
>>> future path to use some kind of batching/threading sound great.
>>>
>>
>> Yes. And you asked for this the first time, too. Consistent! :) Sorry for
>> being slow to pick it up. It looks like there are several patterns, and
>> we have to support both set_page_dirty() and set_page_dirty_lock(). So
>> the best combination looks to be adding a few variations of
>> release_user_pages*(), but leaving put_user_page() alone, because it's
>> the "do it yourself" basic one. Scatter-gather will be stuck with that.
>>
>> Here's a differential patch with that, that shows a nice little cleanup in
>> a couple of IB places, and as you point out, it also provides the hooks for
>> performance upgrades (via batching) in the future.
>>
>> Does this API look about right?
> 
> I'm on board with that and the changes to hfi1 and qib.
> 
> Reviewed-by: Dennis Dalessandro 

Hi Dennis, thanks for the review!

I'll add those new routines in and send out a v2 soon, now that it appears, 
from 
the recent discussion, that this aspect of the approach is still viable.


thanks,
-- 
John Hubbard
NVIDIA

Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call

[John Hubbard]

On 10/1/18 7:35 AM, Dennis Dalessandro wrote:
> On 9/28/2018 11:12 PM, John Hubbard wrote:
>> On 9/28/18 8:39 AM, Jason Gunthorpe wrote:
>>> On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
 From: John Hubbard 
>> [...]

 diff --git a/drivers/infiniband/core/umem.c 
 b/drivers/infiniband/core/umem.c
 index a41792dbae1f..9430d697cb9f 100644
 +++ b/drivers/infiniband/core/umem.c
 @@ -60,7 +60,7 @@ static void __ib_umem_release(struct ib_device *dev, 
 struct ib_umem *umem, int d
   page = sg_page(sg);
   if (!PageDirty(page) && umem->writable && dirty)
   set_page_dirty_lock(page);
 -    put_page(page);
 +    put_user_page(page);
>>>
>>> Would it make sense to have a release/put_user_pages_dirtied to absorb
>>> the set_page_dity pattern too? I notice in this patch there is some
>>> variety here, I wonder what is the right way?
>>>
>>> Also, I'm told this code here is a big performance bottleneck when the
>>> number of pages becomes very long (think >> GB of memory), so having a
>>> future path to use some kind of batching/threading sound great.
>>>
>>
>> Yes. And you asked for this the first time, too. Consistent! :) Sorry for
>> being slow to pick it up. It looks like there are several patterns, and
>> we have to support both set_page_dirty() and set_page_dirty_lock(). So
>> the best combination looks to be adding a few variations of
>> release_user_pages*(), but leaving put_user_page() alone, because it's
>> the "do it yourself" basic one. Scatter-gather will be stuck with that.
>>
>> Here's a differential patch with that, that shows a nice little cleanup in
>> a couple of IB places, and as you point out, it also provides the hooks for
>> performance upgrades (via batching) in the future.
>>
>> Does this API look about right?
> 
> I'm on board with that and the changes to hfi1 and qib.
> 
> Reviewed-by: Dennis Dalessandro 

Hi Dennis, thanks for the review!

I'll add those new routines in and send out a v2 soon, now that it appears, 
from 
the recent discussion, that this aspect of the approach is still viable.


thanks,
-- 
John Hubbard
NVIDIA

Using lockdep instead of spin_is_locked()

[Lance Roy]

One of the main uses of spin_is_locked() is to require that a lock is held when
a function is called, for debugging, but lockdep_assert_held() is better for
this purpose since it won't make a mistake when someone else is holding the
lock. This patch series replaces all of this kind of use of spin_is_locked()
with calls to lockdep_assert_held(). An ulterior motive is to reduce the number
of uses of spin_is_locked() from the kernel, to work towards possibly
eliminating it.

Thanks,
Lance

 arch/x86/pci/i386.c  |  2 +-
 drivers/hv/hv_balloon.c  |  2 +-
 drivers/misc/sgi-xp/xpc_channel.c|  6 +++---
 drivers/misc/sgi-xp/xpc_sn2.c|  2 +-
 drivers/misc/sgi-xp/xpc_uv.c |  2 +-
 drivers/net/ethernet/intel/i40e/i40e_main.c  |  3 +--
 drivers/net/ethernet/intel/igbvf/mbx.c   |  4 ++--
 drivers/net/ethernet/sfc/efx.c   |  2 +-
 drivers/net/ethernet/smsc/smsc911x.h |  2 +-
 drivers/net/wireless/zydas/zd1211rw/zd_mac.c |  2 +-
 drivers/scsi/snic/snic_scsi.c|  4 ++--
 fs/userfaultfd.c |  2 +-
 kernel/futex.c   |  4 ++--
 kernel/locking/mutex-debug.c |  4 ++--
 mm/khugepaged.c  |  4 ++--
 mm/swap.c|  3 +--
 net/netfilter/ipset/ip_set_hash_gen.h|  2 +-
 security/apparmor/file.c |  2 +-
 virt/kvm/arm/vgic/vgic.c | 12 ++--
 19 files changed, 31 insertions(+), 33 deletions(-)

[PATCH 08/16] wireless: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Daniel Drake 
Cc: Ulrich Kunitz 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: 
Cc: 
---
 drivers/net/wireless/zydas/zd1211rw/zd_mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c 
b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
index 1f6d9f357e57..9ccd780695f0 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
@@ -235,7 +235,7 @@ void zd_mac_clear(struct zd_mac *mac)
 {
flush_workqueue(zd_workqueue);
zd_chip_clear(>chip);
-   ZD_ASSERT(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
ZD_MEMCLEAR(mac, sizeof(struct zd_mac));
 }
 
-- 
2.19.0

[PATCH 14/16] netfilter: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Pablo Neira Ayuso 
Cc: Jozsef Kadlecsik 
Cc: Florian Westphal 
Cc: "David S. Miller" 
Cc: 
Cc: 
Cc: 
---
 net/netfilter/ipset/ip_set_hash_gen.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/ipset/ip_set_hash_gen.h 
b/net/netfilter/ipset/ip_set_hash_gen.h
index 8a33dac4e805..e287da68d5fa 100644
--- a/net/netfilter/ipset/ip_set_hash_gen.h
+++ b/net/netfilter/ipset/ip_set_hash_gen.h
@@ -15,7 +15,7 @@
 
 #define __ipset_dereference_protected(p, c)rcu_dereference_protected(p, c)
 #define ipset_dereference_protected(p, set) \
-   __ipset_dereference_protected(p, spin_is_locked(&(set)->lock))
+   __ipset_dereference_protected(p, lockdep_is_held(&(set)->lock))
 
 #define rcu_dereference_bh_nfnl(p) rcu_dereference_bh_check(p, 1)
 
-- 
2.19.0

[PATCH 04/16] i40e: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Jeff Kirsher 
Cc: "David S. Miller" 
Cc: intel-wired-...@lists.osuosl.org
Cc: 
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index ac685ad4d877..8ce3471723d3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1489,8 +1489,7 @@ int i40e_del_mac_filter(struct i40e_vsi *vsi, const u8 
*macaddr)
bool found = false;
int bkt;
 
-   WARN(!spin_is_locked(>mac_filter_hash_lock),
-"Missing mac_filter_hash_lock\n");
+   lockdep_assert_held(>mac_filter_hash_lock);
hash_for_each_safe(vsi->mac_filter_hash, bkt, h, f, hlist) {
if (ether_addr_equal(macaddr, f->macaddr)) {
__i40e_del_filter(vsi, f);
-- 
2.19.0

Using lockdep instead of spin_is_locked()

[Lance Roy]

One of the main uses of spin_is_locked() is to require that a lock is held when
a function is called, for debugging, but lockdep_assert_held() is better for
this purpose since it won't make a mistake when someone else is holding the
lock. This patch series replaces all of this kind of use of spin_is_locked()
with calls to lockdep_assert_held(). An ulterior motive is to reduce the number
of uses of spin_is_locked() from the kernel, to work towards possibly
eliminating it.

Thanks,
Lance

 arch/x86/pci/i386.c  |  2 +-
 drivers/hv/hv_balloon.c  |  2 +-
 drivers/misc/sgi-xp/xpc_channel.c|  6 +++---
 drivers/misc/sgi-xp/xpc_sn2.c|  2 +-
 drivers/misc/sgi-xp/xpc_uv.c |  2 +-
 drivers/net/ethernet/intel/i40e/i40e_main.c  |  3 +--
 drivers/net/ethernet/intel/igbvf/mbx.c   |  4 ++--
 drivers/net/ethernet/sfc/efx.c   |  2 +-
 drivers/net/ethernet/smsc/smsc911x.h |  2 +-
 drivers/net/wireless/zydas/zd1211rw/zd_mac.c |  2 +-
 drivers/scsi/snic/snic_scsi.c|  4 ++--
 fs/userfaultfd.c |  2 +-
 kernel/futex.c   |  4 ++--
 kernel/locking/mutex-debug.c |  4 ++--
 mm/khugepaged.c  |  4 ++--
 mm/swap.c|  3 +--
 net/netfilter/ipset/ip_set_hash_gen.h|  2 +-
 security/apparmor/file.c |  2 +-
 virt/kvm/arm/vgic/vgic.c | 12 ++--
 19 files changed, 31 insertions(+), 33 deletions(-)

[PATCH 08/16] wireless: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Daniel Drake 
Cc: Ulrich Kunitz 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: 
Cc: 
---
 drivers/net/wireless/zydas/zd1211rw/zd_mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c 
b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
index 1f6d9f357e57..9ccd780695f0 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
@@ -235,7 +235,7 @@ void zd_mac_clear(struct zd_mac *mac)
 {
flush_workqueue(zd_workqueue);
zd_chip_clear(>chip);
-   ZD_ASSERT(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
ZD_MEMCLEAR(mac, sizeof(struct zd_mac));
 }
 
-- 
2.19.0

[PATCH 14/16] netfilter: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Pablo Neira Ayuso 
Cc: Jozsef Kadlecsik 
Cc: Florian Westphal 
Cc: "David S. Miller" 
Cc: 
Cc: 
Cc: 
---
 net/netfilter/ipset/ip_set_hash_gen.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/ipset/ip_set_hash_gen.h 
b/net/netfilter/ipset/ip_set_hash_gen.h
index 8a33dac4e805..e287da68d5fa 100644
--- a/net/netfilter/ipset/ip_set_hash_gen.h
+++ b/net/netfilter/ipset/ip_set_hash_gen.h
@@ -15,7 +15,7 @@
 
 #define __ipset_dereference_protected(p, c)rcu_dereference_protected(p, c)
 #define ipset_dereference_protected(p, set) \
-   __ipset_dereference_protected(p, spin_is_locked(&(set)->lock))
+   __ipset_dereference_protected(p, lockdep_is_held(&(set)->lock))
 
 #define rcu_dereference_bh_nfnl(p) rcu_dereference_bh_check(p, 1)
 
-- 
2.19.0

[PATCH 04/16] i40e: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Jeff Kirsher 
Cc: "David S. Miller" 
Cc: intel-wired-...@lists.osuosl.org
Cc: 
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index ac685ad4d877..8ce3471723d3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1489,8 +1489,7 @@ int i40e_del_mac_filter(struct i40e_vsi *vsi, const u8 
*macaddr)
bool found = false;
int bkt;
 
-   WARN(!spin_is_locked(>mac_filter_hash_lock),
-"Missing mac_filter_hash_lock\n");
+   lockdep_assert_held(>mac_filter_hash_lock);
hash_for_each_safe(vsi->mac_filter_hash, bkt, h, f, hlist) {
if (ether_addr_equal(macaddr, f->macaddr)) {
__i40e_del_filter(vsi, f);
-- 
2.19.0

Re: [PATCH] regulator/mfd: fix pointer-to-int cast

[Matti Vaittinen]

Hello Arnd,

On Tue, Oct 02, 2018 at 11:07:32PM +0200, Arnd Bergmann wrote:
> gcc points out that a pointer is longer than an int on 64-bit
> architectures, and that casting between the two may be dangerous:
> 
> drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
> drivers/mfd/rohm-bd718x7.c:101:23: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> 
> In this driver it is correct, we just need the right kind of cast
> to avoid the warning.
> 
> Fixes: 494edd266b94 ("regulator/mfd: Support ROHM BD71847 power management 
> IC")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/mfd/rohm-bd718x7.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/rohm-bd718x7.c b/drivers/mfd/rohm-bd718x7.c
> index 161c8aac6d86..e66d59190a82 100644
> --- a/drivers/mfd/rohm-bd718x7.c
> +++ b/drivers/mfd/rohm-bd718x7.c
> @@ -98,7 +98,7 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
>   return -ENOMEM;
>  
>   bd718xx->chip_irq = i2c->irq;
> - bd718xx->chip_type = (unsigned int)
> + bd718xx->chip_type = (uintptr_t)
>   of_device_get_match_data(>dev);
>   bd718xx->dev = >dev;
>   dev_set_drvdata(>dev, bd718xx);

Big thanks for this activity =) I also got heads up mail from linux-next
so I also did a patch fixing this. I think Mark alrady applied that
patch to his tree.

(https://lore.kernel.org/lkml/20181002145901.899d41121...@debutante.sirena.org.uk/)

Br,
Matti Vaittinen

Re: [PATCH] regulator/mfd: fix pointer-to-int cast

[Matti Vaittinen]

Hello Arnd,

On Tue, Oct 02, 2018 at 11:07:32PM +0200, Arnd Bergmann wrote:
> gcc points out that a pointer is longer than an int on 64-bit
> architectures, and that casting between the two may be dangerous:
> 
> drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
> drivers/mfd/rohm-bd718x7.c:101:23: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> 
> In this driver it is correct, we just need the right kind of cast
> to avoid the warning.
> 
> Fixes: 494edd266b94 ("regulator/mfd: Support ROHM BD71847 power management 
> IC")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/mfd/rohm-bd718x7.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/rohm-bd718x7.c b/drivers/mfd/rohm-bd718x7.c
> index 161c8aac6d86..e66d59190a82 100644
> --- a/drivers/mfd/rohm-bd718x7.c
> +++ b/drivers/mfd/rohm-bd718x7.c
> @@ -98,7 +98,7 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
>   return -ENOMEM;
>  
>   bd718xx->chip_irq = i2c->irq;
> - bd718xx->chip_type = (unsigned int)
> + bd718xx->chip_type = (uintptr_t)
>   of_device_get_match_data(>dev);
>   bd718xx->dev = >dev;
>   dev_set_drvdata(>dev, bd718xx);

Big thanks for this activity =) I also got heads up mail from linux-next
so I also did a patch fixing this. I think Mark alrady applied that
patch to his tree.

(https://lore.kernel.org/lkml/20181002145901.899d41121...@debutante.sirena.org.uk/)

Br,
Matti Vaittinen

[PATCH 12/16] locking/mutex: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Will Deacon 
---
 kernel/locking/mutex-debug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
index 9aa713629387..771d4ca96dda 100644
--- a/kernel/locking/mutex-debug.c
+++ b/kernel/locking/mutex-debug.c
@@ -36,7 +36,7 @@ void debug_mutex_lock_common(struct mutex *lock, struct 
mutex_waiter *waiter)
 
 void debug_mutex_wake_waiter(struct mutex *lock, struct mutex_waiter *waiter)
 {
-   SMP_DEBUG_LOCKS_WARN_ON(!spin_is_locked(>wait_lock));
+   lockdep_assert_held(>wait_lock);
DEBUG_LOCKS_WARN_ON(list_empty(>wait_list));
DEBUG_LOCKS_WARN_ON(waiter->magic != waiter);
DEBUG_LOCKS_WARN_ON(list_empty(>list));
@@ -51,7 +51,7 @@ void debug_mutex_free_waiter(struct mutex_waiter *waiter)
 void debug_mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
struct task_struct *task)
 {
-   SMP_DEBUG_LOCKS_WARN_ON(!spin_is_locked(>wait_lock));
+   lockdep_assert_held(>wait_lock);
 
/* Mark the current thread as blocked on the lock: */
task->blocked_on = waiter;
-- 
2.19.0

[PATCH 07/16] smsc: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Steve Glendinning 
Cc: "David S. Miller" 
Cc: 
---
 drivers/net/ethernet/smsc/smsc911x.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/smsc/smsc911x.h 
b/drivers/net/ethernet/smsc/smsc911x.h
index 8d75508acd2b..51b2fc1a395f 100644
--- a/drivers/net/ethernet/smsc/smsc911x.h
+++ b/drivers/net/ethernet/smsc/smsc911x.h
@@ -67,7 +67,7 @@
 
 #ifdef CONFIG_DEBUG_SPINLOCK
 #define SMSC_ASSERT_MAC_LOCK(pdata) \
-   WARN_ON_SMP(!spin_is_locked(>mac_lock))
+   lockdep_assert_held(>mac_lock)
 #else
 #define SMSC_ASSERT_MAC_LOCK(pdata) do {} while (0)
 #endif /* CONFIG_DEBUG_SPINLOCK */
-- 
2.19.0

[PATCH 02/16] hv_balloon: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: 
---
 drivers/hv/hv_balloon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b1b788082793..41631512ae97 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -689,7 +689,7 @@ static void hv_page_online_one(struct hv_hotadd_state *has, 
struct page *pg)
__online_page_increment_counters(pg);
__online_page_free(pg);
 
-   WARN_ON_ONCE(!spin_is_locked(_device.ha_lock));
+   lockdep_assert_held(_device.ha_lock);
dm_device.num_pages_onlined++;
 }
 
-- 
2.19.0

[PATCH 11/16] futex: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Darren Hart 
---
 kernel/futex.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 11fc3bb456d6..3e2de8fc1891 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1365,9 +1365,9 @@ static void __unqueue_futex(struct futex_q *q)
 {
struct futex_hash_bucket *hb;
 
-   if (WARN_ON_SMP(!q->lock_ptr || !spin_is_locked(q->lock_ptr))
-   || WARN_ON(plist_node_empty(>list)))
+   if (WARN_ON_SMP(!q->lock_ptr) || WARN_ON(plist_node_empty(>list)))
return;
+   lockdep_assert_held(q->lock_ptr);
 
hb = container_of(q->lock_ptr, struct futex_hash_bucket, lock);
plist_del(>list, >chain);
-- 
2.19.0

[PATCH 13/16] mm: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Andrew Morton 
Cc: "Kirill A. Shutemov" 
Cc: Yang Shi 
Cc: Matthew Wilcox 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Jan Kara 
Cc: Shakeel Butt 
Cc: 
---
 mm/khugepaged.c | 4 ++--
 mm/swap.c   | 3 +--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index a31d740e6cd1..80f12467ccb3 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1225,7 +1225,7 @@ static void collect_mm_slot(struct mm_slot *mm_slot)
 {
struct mm_struct *mm = mm_slot->mm;
 
-   VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(_mm_lock));
+   lockdep_assert_held(_mm_lock);
 
if (khugepaged_test_exit(mm)) {
/* free mm_slot */
@@ -1665,7 +1665,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int 
pages,
int progress = 0;
 
VM_BUG_ON(!pages);
-   VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(_mm_lock));
+   lockdep_assert_held(_mm_lock);
 
if (khugepaged_scan.mm_slot)
mm_slot = khugepaged_scan.mm_slot;
diff --git a/mm/swap.c b/mm/swap.c
index 26fc9b5f1b6c..c89eb442c0bf 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -824,8 +824,7 @@ void lru_add_page_tail(struct page *page, struct page 
*page_tail,
VM_BUG_ON_PAGE(!PageHead(page), page);
VM_BUG_ON_PAGE(PageCompound(page_tail), page);
VM_BUG_ON_PAGE(PageLRU(page_tail), page);
-   VM_BUG_ON(NR_CPUS != 1 &&
- !spin_is_locked(_pgdat(lruvec)->lru_lock));
+   lockdep_assert_held(_pgdat(lruvec)->lru_lock);
 
if (!list)
SetPageLRU(page_tail);
-- 
2.19.0

[PATCH 15/16] apparmor: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: John Johansen 
Cc: James Morris 
Cc: "Serge E. Hallyn" 
Cc: 
---
 security/apparmor/file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index 4285943f7260..d0afed9ebd0e 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -496,7 +496,7 @@ static void update_file_ctx(struct aa_file_ctx *fctx, 
struct aa_label *label,
/* update caching of label on file_ctx */
spin_lock(>lock);
old = rcu_dereference_protected(fctx->label,
-   spin_is_locked(>lock));
+   lockdep_is_held(>lock));
l = aa_label_merge(old, label, GFP_ATOMIC);
if (l) {
if (l != old) {
-- 
2.19.0

[PATCH 03/16] sgi-xp: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Cliff Whickman 
Cc: Robin Holt 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
---
 drivers/misc/sgi-xp/xpc_channel.c | 6 +++---
 drivers/misc/sgi-xp/xpc_sn2.c | 2 +-
 drivers/misc/sgi-xp/xpc_uv.c  | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/sgi-xp/xpc_channel.c 
b/drivers/misc/sgi-xp/xpc_channel.c
index 05a890ce2ab8..8e6607fc8a67 100644
--- a/drivers/misc/sgi-xp/xpc_channel.c
+++ b/drivers/misc/sgi-xp/xpc_channel.c
@@ -28,7 +28,7 @@ xpc_process_connect(struct xpc_channel *ch, unsigned long 
*irq_flags)
 {
enum xp_retval ret;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (!(ch->flags & XPC_C_OPENREQUEST) ||
!(ch->flags & XPC_C_ROPENREQUEST)) {
@@ -82,7 +82,7 @@ xpc_process_disconnect(struct xpc_channel *ch, unsigned long 
*irq_flags)
struct xpc_partition *part = _partitions[ch->partid];
u32 channel_was_connected = (ch->flags & XPC_C_WASCONNECTED);
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (!(ch->flags & XPC_C_DISCONNECTING))
return;
@@ -755,7 +755,7 @@ xpc_disconnect_channel(const int line, struct xpc_channel 
*ch,
 {
u32 channel_was_connected = (ch->flags & XPC_C_CONNECTED);
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (ch->flags & (XPC_C_DISCONNECTING | XPC_C_DISCONNECTED))
return;
diff --git a/drivers/misc/sgi-xp/xpc_sn2.c b/drivers/misc/sgi-xp/xpc_sn2.c
index 5a12d2a54049..0ae69b9390ce 100644
--- a/drivers/misc/sgi-xp/xpc_sn2.c
+++ b/drivers/misc/sgi-xp/xpc_sn2.c
@@ -1671,7 +1671,7 @@ xpc_teardown_msg_structures_sn2(struct xpc_channel *ch)
 {
struct xpc_channel_sn2 *ch_sn2 = >sn.sn2;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
ch_sn2->remote_msgqueue_pa = 0;
 
diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c
index 340b44d9e8cf..0441abe87880 100644
--- a/drivers/misc/sgi-xp/xpc_uv.c
+++ b/drivers/misc/sgi-xp/xpc_uv.c
@@ -1183,7 +1183,7 @@ xpc_teardown_msg_structures_uv(struct xpc_channel *ch)
 {
struct xpc_channel_uv *ch_uv = >sn.uv;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
kfree(ch_uv->cached_notify_gru_mq_desc);
ch_uv->cached_notify_gru_mq_desc = NULL;
-- 
2.19.0

[PATCH 03/16] sgi-xp: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Cliff Whickman 
Cc: Robin Holt 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
---
 drivers/misc/sgi-xp/xpc_channel.c | 6 +++---
 drivers/misc/sgi-xp/xpc_sn2.c | 2 +-
 drivers/misc/sgi-xp/xpc_uv.c  | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/sgi-xp/xpc_channel.c 
b/drivers/misc/sgi-xp/xpc_channel.c
index 05a890ce2ab8..8e6607fc8a67 100644
--- a/drivers/misc/sgi-xp/xpc_channel.c
+++ b/drivers/misc/sgi-xp/xpc_channel.c
@@ -28,7 +28,7 @@ xpc_process_connect(struct xpc_channel *ch, unsigned long 
*irq_flags)
 {
enum xp_retval ret;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (!(ch->flags & XPC_C_OPENREQUEST) ||
!(ch->flags & XPC_C_ROPENREQUEST)) {
@@ -82,7 +82,7 @@ xpc_process_disconnect(struct xpc_channel *ch, unsigned long 
*irq_flags)
struct xpc_partition *part = _partitions[ch->partid];
u32 channel_was_connected = (ch->flags & XPC_C_WASCONNECTED);
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (!(ch->flags & XPC_C_DISCONNECTING))
return;
@@ -755,7 +755,7 @@ xpc_disconnect_channel(const int line, struct xpc_channel 
*ch,
 {
u32 channel_was_connected = (ch->flags & XPC_C_CONNECTED);
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
if (ch->flags & (XPC_C_DISCONNECTING | XPC_C_DISCONNECTED))
return;
diff --git a/drivers/misc/sgi-xp/xpc_sn2.c b/drivers/misc/sgi-xp/xpc_sn2.c
index 5a12d2a54049..0ae69b9390ce 100644
--- a/drivers/misc/sgi-xp/xpc_sn2.c
+++ b/drivers/misc/sgi-xp/xpc_sn2.c
@@ -1671,7 +1671,7 @@ xpc_teardown_msg_structures_sn2(struct xpc_channel *ch)
 {
struct xpc_channel_sn2 *ch_sn2 = >sn.sn2;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
ch_sn2->remote_msgqueue_pa = 0;
 
diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c
index 340b44d9e8cf..0441abe87880 100644
--- a/drivers/misc/sgi-xp/xpc_uv.c
+++ b/drivers/misc/sgi-xp/xpc_uv.c
@@ -1183,7 +1183,7 @@ xpc_teardown_msg_structures_uv(struct xpc_channel *ch)
 {
struct xpc_channel_uv *ch_uv = >sn.uv;
 
-   DBUG_ON(!spin_is_locked(>lock));
+   lockdep_assert_held(>lock);
 
kfree(ch_uv->cached_notify_gru_mq_desc);
ch_uv->cached_notify_gru_mq_desc = NULL;
-- 
2.19.0

[PATCH 12/16] locking/mutex: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Will Deacon 
---
 kernel/locking/mutex-debug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
index 9aa713629387..771d4ca96dda 100644
--- a/kernel/locking/mutex-debug.c
+++ b/kernel/locking/mutex-debug.c
@@ -36,7 +36,7 @@ void debug_mutex_lock_common(struct mutex *lock, struct 
mutex_waiter *waiter)
 
 void debug_mutex_wake_waiter(struct mutex *lock, struct mutex_waiter *waiter)
 {
-   SMP_DEBUG_LOCKS_WARN_ON(!spin_is_locked(>wait_lock));
+   lockdep_assert_held(>wait_lock);
DEBUG_LOCKS_WARN_ON(list_empty(>wait_list));
DEBUG_LOCKS_WARN_ON(waiter->magic != waiter);
DEBUG_LOCKS_WARN_ON(list_empty(>list));
@@ -51,7 +51,7 @@ void debug_mutex_free_waiter(struct mutex_waiter *waiter)
 void debug_mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
struct task_struct *task)
 {
-   SMP_DEBUG_LOCKS_WARN_ON(!spin_is_locked(>wait_lock));
+   lockdep_assert_held(>wait_lock);
 
/* Mark the current thread as blocked on the lock: */
task->blocked_on = waiter;
-- 
2.19.0

[PATCH 07/16] smsc: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Steve Glendinning 
Cc: "David S. Miller" 
Cc: 
---
 drivers/net/ethernet/smsc/smsc911x.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/smsc/smsc911x.h 
b/drivers/net/ethernet/smsc/smsc911x.h
index 8d75508acd2b..51b2fc1a395f 100644
--- a/drivers/net/ethernet/smsc/smsc911x.h
+++ b/drivers/net/ethernet/smsc/smsc911x.h
@@ -67,7 +67,7 @@
 
 #ifdef CONFIG_DEBUG_SPINLOCK
 #define SMSC_ASSERT_MAC_LOCK(pdata) \
-   WARN_ON_SMP(!spin_is_locked(>mac_lock))
+   lockdep_assert_held(>mac_lock)
 #else
 #define SMSC_ASSERT_MAC_LOCK(pdata) do {} while (0)
 #endif /* CONFIG_DEBUG_SPINLOCK */
-- 
2.19.0

[PATCH 02/16] hv_balloon: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: 
---
 drivers/hv/hv_balloon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b1b788082793..41631512ae97 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -689,7 +689,7 @@ static void hv_page_online_one(struct hv_hotadd_state *has, 
struct page *pg)
__online_page_increment_counters(pg);
__online_page_free(pg);
 
-   WARN_ON_ONCE(!spin_is_locked(_device.ha_lock));
+   lockdep_assert_held(_device.ha_lock);
dm_device.num_pages_onlined++;
 }
 
-- 
2.19.0

[PATCH 11/16] futex: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Darren Hart 
---
 kernel/futex.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 11fc3bb456d6..3e2de8fc1891 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1365,9 +1365,9 @@ static void __unqueue_futex(struct futex_q *q)
 {
struct futex_hash_bucket *hb;
 
-   if (WARN_ON_SMP(!q->lock_ptr || !spin_is_locked(q->lock_ptr))
-   || WARN_ON(plist_node_empty(>list)))
+   if (WARN_ON_SMP(!q->lock_ptr) || WARN_ON(plist_node_empty(>list)))
return;
+   lockdep_assert_held(q->lock_ptr);
 
hb = container_of(q->lock_ptr, struct futex_hash_bucket, lock);
plist_del(>list, >chain);
-- 
2.19.0

[PATCH 13/16] mm: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: Andrew Morton 
Cc: "Kirill A. Shutemov" 
Cc: Yang Shi 
Cc: Matthew Wilcox 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Jan Kara 
Cc: Shakeel Butt 
Cc: 
---
 mm/khugepaged.c | 4 ++--
 mm/swap.c   | 3 +--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index a31d740e6cd1..80f12467ccb3 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1225,7 +1225,7 @@ static void collect_mm_slot(struct mm_slot *mm_slot)
 {
struct mm_struct *mm = mm_slot->mm;
 
-   VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(_mm_lock));
+   lockdep_assert_held(_mm_lock);
 
if (khugepaged_test_exit(mm)) {
/* free mm_slot */
@@ -1665,7 +1665,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int 
pages,
int progress = 0;
 
VM_BUG_ON(!pages);
-   VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(_mm_lock));
+   lockdep_assert_held(_mm_lock);
 
if (khugepaged_scan.mm_slot)
mm_slot = khugepaged_scan.mm_slot;
diff --git a/mm/swap.c b/mm/swap.c
index 26fc9b5f1b6c..c89eb442c0bf 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -824,8 +824,7 @@ void lru_add_page_tail(struct page *page, struct page 
*page_tail,
VM_BUG_ON_PAGE(!PageHead(page), page);
VM_BUG_ON_PAGE(PageCompound(page_tail), page);
VM_BUG_ON_PAGE(PageLRU(page_tail), page);
-   VM_BUG_ON(NR_CPUS != 1 &&
- !spin_is_locked(_pgdat(lruvec)->lru_lock));
+   lockdep_assert_held(_pgdat(lruvec)->lru_lock);
 
if (!list)
SetPageLRU(page_tail);
-- 
2.19.0

[PATCH 15/16] apparmor: Replace spin_is_locked() with lockdep

[Lance Roy]

lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().

Signed-off-by: Lance Roy 
Cc: John Johansen 
Cc: James Morris 
Cc: "Serge E. Hallyn" 
Cc: 
---
 security/apparmor/file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index 4285943f7260..d0afed9ebd0e 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -496,7 +496,7 @@ static void update_file_ctx(struct aa_file_ctx *fctx, 
struct aa_label *label,
/* update caching of label on file_ctx */
spin_lock(>lock);
old = rcu_dereference_protected(fctx->label,
-   spin_is_locked(>lock));
+   lockdep_is_held(>lock));
l = aa_label_merge(old, label, GFP_ATOMIC);
if (l) {
if (l != old) {
-- 
2.19.0

linux-next: manual merge of the devicetree tree with the c6x tree

[Stephen Rothwell]

Hi all,

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

  arch/c6x/kernel/setup.c

between commit:

  31b02fe54206 ("c6x: switch to NO_BOOTMEM")

from the c6x tree and commit:

  be7cd2df1d22 ("c6x: use common built-in dtb support")

from the devicetree tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/c6x/kernel/setup.c
index cc74cb9d349b,05d96a9541b5..
--- a/arch/c6x/kernel/setup.c
+++ b/arch/c6x/kernel/setup.c
@@@ -352,7 -348,17 +347,7 @@@ void __init setup_arch(char **cmdline_p
init_mm.end_data   = memory_start;
init_mm.brk= memory_start;
  
-   unflatten_device_tree();
 -  /*
 -   * Give all the memory to the bootmap allocator,  tell it to put the
 -   * boot mem_map at the start of memory
 -   */
 -  bootmap_size = init_bootmem_node(NODE_DATA(0),
 -   memory_start >> PAGE_SHIFT,
 -   PAGE_OFFSET >> PAGE_SHIFT,
 -   memory_end >> PAGE_SHIFT);
 -  memblock_reserve(memory_start, bootmap_size);
 -
+   unflatten_and_copy_device_tree();
  
c6x_cache_init();
  


pgpO5uTGSTKGX.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the devicetree tree with the c6x tree

[Stephen Rothwell]

Hi all,

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

  arch/c6x/kernel/setup.c

between commit:

  31b02fe54206 ("c6x: switch to NO_BOOTMEM")

from the c6x tree and commit:

  be7cd2df1d22 ("c6x: use common built-in dtb support")

from the devicetree tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/c6x/kernel/setup.c
index cc74cb9d349b,05d96a9541b5..
--- a/arch/c6x/kernel/setup.c
+++ b/arch/c6x/kernel/setup.c
@@@ -352,7 -348,17 +347,7 @@@ void __init setup_arch(char **cmdline_p
init_mm.end_data   = memory_start;
init_mm.brk= memory_start;
  
-   unflatten_device_tree();
 -  /*
 -   * Give all the memory to the bootmap allocator,  tell it to put the
 -   * boot mem_map at the start of memory
 -   */
 -  bootmap_size = init_bootmem_node(NODE_DATA(0),
 -   memory_start >> PAGE_SHIFT,
 -   PAGE_OFFSET >> PAGE_SHIFT,
 -   memory_end >> PAGE_SHIFT);
 -  memblock_reserve(memory_start, bootmap_size);
 -
+   unflatten_and_copy_device_tree();
  
c6x_cache_init();
  


pgpO5uTGSTKGX.pgp
Description: OpenPGP digital signature

Re: Setting monotonic time?

[Thomas Gleixner]

On Wed, 3 Oct 2018, Eric W. Biederman wrote:
> Direct access to hardware/drivers and not through an abstraction like
> the vfs (an abstraction over block devices) can legitimately be handled
> by hotplug events.  I unplug one keyboard I plug in another.
> 
> I don't know if the input layer is more of a general abstraction
> or more of a hardware device.  I have not dug into it but my guess
> is abstraction from what I have heard.
> 
> The scary difficulty here is if after restart input is reporting times
> in CLOCK_MONOTONIC and the applications in the namespace are talking
> about times in CLOCK_MONOTONIC_SYNC.  Then there is an issue.  As even
> with a fixed offset the times don't match up.
> 
> So a time namespace absolutely needs to do is figure out how to deal
> with all of the kernel interfaces reporting times and figure out how to
> report them in the current time namespace.

So you want to talk to Arnd who is leading the y2038 effort. He knowns how
many and which interfaces are involved aside of the obvious core timer
ones. It's quite an amount and the problem is that you really need to do
that at the interface level, because many of those time stamps are taken in
contexts which are completely oblivious of name spaces. Ditto for timeouts
and similar things which are handed in through these interfaces.

Thanks,

tglx

Re: Setting monotonic time?

[Thomas Gleixner]

On Wed, 3 Oct 2018, Eric W. Biederman wrote:
> Direct access to hardware/drivers and not through an abstraction like
> the vfs (an abstraction over block devices) can legitimately be handled
> by hotplug events.  I unplug one keyboard I plug in another.
> 
> I don't know if the input layer is more of a general abstraction
> or more of a hardware device.  I have not dug into it but my guess
> is abstraction from what I have heard.
> 
> The scary difficulty here is if after restart input is reporting times
> in CLOCK_MONOTONIC and the applications in the namespace are talking
> about times in CLOCK_MONOTONIC_SYNC.  Then there is an issue.  As even
> with a fixed offset the times don't match up.
> 
> So a time namespace absolutely needs to do is figure out how to deal
> with all of the kernel interfaces reporting times and figure out how to
> report them in the current time namespace.

So you want to talk to Arnd who is leading the y2038 effort. He knowns how
many and which interfaces are involved aside of the obvious core timer
ones. It's quite an amount and the problem is that you really need to do
that at the interface level, because many of those time stamps are taken in
contexts which are completely oblivious of name spaces. Ditto for timeouts
and similar things which are handed in through these interfaces.

Thanks,

tglx

Re: [PATCH] cpufreq: dt-platdev: mark RK3399 as having separate policies per cluster

[Dmitry Torokhov]

On Tue, Oct 2, 2018 at 9:41 PM Viresh Kumar  wrote:
>
> On 01-10-18, 13:21, Dmitry Torokhov wrote:
> > RK3399 has one cluster with 4 small cores, and another one with 2 big
> > cores, with cores in different clusters having different OPPs and thus
> > different policies. Let's enable this via "have_governor_per_policy"
> > platform data.
>
> The policies are always different in such cases, with or without this flag. 
> What
> this flag rather enables is for us to have separate set of tunables for the
> governor for individual policies.
>
> For example, without this flag there will be a single governor directory:
>
> /sys/devices/system/cpu/cpufreq/schedutil/
>
> and the value of tunables in that directory will be used for all cpufreq
> policies.
>
> With this flag you wouldn't have the governor directory there, but rather in:
>
> /sys/devices/system/cpu/cpufreq/policy*/schedutil/
>
> i.e. tunables per policy and that's why the name of the flag is:
> have_governor_per_policy.
>
> > Signed-off-by: Dmitry Torokhov 
> > ---
> >
> > Not tested, but we had a patch unconditionally enabling
> > CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices
> > based on RK3399 platform.
>
> Sure, that sounds good. Just that you need to update the commit log a bit.

OK, I'll do that.

>
> >  drivers/cpufreq/cpufreq-dt-platdev.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
> > b/drivers/cpufreq/cpufreq-dt-platdev.c
> > index fe14c57de6ca..040ec0f711f9 100644
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst 
> > = {
> >   { .compatible = "rockchip,rk3328", },
> >   { .compatible = "rockchip,rk3366", },
> >   { .compatible = "rockchip,rk3368", },
> > - { .compatible = "rockchip,rk3399", },
> > + { .compatible = "rockchip,rk3399",
> > +   .data = &(struct cpufreq_dt_platform_data)
>
> data is void *. No need to provide typecast information. This shouldn't throw
> any build warnings I believe.

We however need to tell the compiler the type of structure we are
creating. The following won't compile:

.data = &{ .have_governor_per_policy = true, }

Thanks.

-- 
Dmitry

Re: [PATCH] cpufreq: dt-platdev: mark RK3399 as having separate policies per cluster

[Dmitry Torokhov]

On Tue, Oct 2, 2018 at 9:41 PM Viresh Kumar  wrote:
>
> On 01-10-18, 13:21, Dmitry Torokhov wrote:
> > RK3399 has one cluster with 4 small cores, and another one with 2 big
> > cores, with cores in different clusters having different OPPs and thus
> > different policies. Let's enable this via "have_governor_per_policy"
> > platform data.
>
> The policies are always different in such cases, with or without this flag. 
> What
> this flag rather enables is for us to have separate set of tunables for the
> governor for individual policies.
>
> For example, without this flag there will be a single governor directory:
>
> /sys/devices/system/cpu/cpufreq/schedutil/
>
> and the value of tunables in that directory will be used for all cpufreq
> policies.
>
> With this flag you wouldn't have the governor directory there, but rather in:
>
> /sys/devices/system/cpu/cpufreq/policy*/schedutil/
>
> i.e. tunables per policy and that's why the name of the flag is:
> have_governor_per_policy.
>
> > Signed-off-by: Dmitry Torokhov 
> > ---
> >
> > Not tested, but we had a patch unconditionally enabling
> > CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices
> > based on RK3399 platform.
>
> Sure, that sounds good. Just that you need to update the commit log a bit.

OK, I'll do that.

>
> >  drivers/cpufreq/cpufreq-dt-platdev.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
> > b/drivers/cpufreq/cpufreq-dt-platdev.c
> > index fe14c57de6ca..040ec0f711f9 100644
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst 
> > = {
> >   { .compatible = "rockchip,rk3328", },
> >   { .compatible = "rockchip,rk3366", },
> >   { .compatible = "rockchip,rk3368", },
> > - { .compatible = "rockchip,rk3399", },
> > + { .compatible = "rockchip,rk3399",
> > +   .data = &(struct cpufreq_dt_platform_data)
>
> data is void *. No need to provide typecast information. This shouldn't throw
> any build warnings I believe.

We however need to tell the compiler the type of structure we are
creating. The following won't compile:

.data = &{ .have_governor_per_policy = true, }

Thanks.

-- 
Dmitry

[PATCH] stm class: fix a missing-check bug

[Wenwen Wang]

In stm_char_policy_set_ioctl(), the 'size' field of the struct
'stp_polic_id' is firstly copied from the user space and then checked,
because the length of the 'id' field in this struct, which represents an
identification string, is not fixed. If the 'size' field cannot pass the
check, an error code EINVAL will be returned. However, after the check, the
whole struct is copied again from the user space. Given that the user data
resides in the user space, a malicious user-space process can race to
change the size between the two copies. By doing so, the attacker can
bypass the check on the 'size' field and inject malicious data.

This patch removes the re-copying of the 'size' field in the second copy to
avoid the above issue.

Signed-off-by: Wenwen Wang 
---
 drivers/hwtracing/stm/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 10bcb5d..7617fb4 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -570,11 +570,13 @@ static int stm_char_policy_set_ioctl(struct stm_file 
*stmf, void __user *arg)
if (!id)
return -ENOMEM;
 
-   if (copy_from_user(id, arg, size)) {
+   if (copy_from_user(>master, (char __user *)arg + sizeof(size),
+   size - sizeof(size))) {
ret = -EFAULT;
goto err_free;
}
 
+   id->size = size;
if (id->__reserved_0 || id->__reserved_1)
goto err_free;
 
-- 
2.7.4

[PATCH] stm class: fix a missing-check bug

[Wenwen Wang]

In stm_char_policy_set_ioctl(), the 'size' field of the struct
'stp_polic_id' is firstly copied from the user space and then checked,
because the length of the 'id' field in this struct, which represents an
identification string, is not fixed. If the 'size' field cannot pass the
check, an error code EINVAL will be returned. However, after the check, the
whole struct is copied again from the user space. Given that the user data
resides in the user space, a malicious user-space process can race to
change the size between the two copies. By doing so, the attacker can
bypass the check on the 'size' field and inject malicious data.

This patch removes the re-copying of the 'size' field in the second copy to
avoid the above issue.

Signed-off-by: Wenwen Wang 
---
 drivers/hwtracing/stm/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 10bcb5d..7617fb4 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -570,11 +570,13 @@ static int stm_char_policy_set_ioctl(struct stm_file 
*stmf, void __user *arg)
if (!id)
return -ENOMEM;
 
-   if (copy_from_user(id, arg, size)) {
+   if (copy_from_user(>master, (char __user *)arg + sizeof(size),
+   size - sizeof(size))) {
ret = -EFAULT;
goto err_free;
}
 
+   id->size = size;
if (id->__reserved_0 || id->__reserved_1)
goto err_free;
 
-- 
2.7.4

Re: Setting monotonic time?

[Eric W. Biederman]

Thomas Gleixner  writes:

> On Tue, 2 Oct 2018, Arnd Bergmann wrote:
>> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner  wrote:
>> >
>> > On Mon, 1 Oct 2018, Eric W. Biederman wrote:
>> > > In the context of process migration there is a simpler subproblem that I
>> > > think it is worth exploring if we can do something about.
>> > >
>> > > For a cluster of machines all running with synchronized
>> > > clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
>> > > machines.   Not having a matching CLOCK_MONOTONIC prevents successful
>> > > process migration between nodes in that cluster.
>> > >
>> > > Would it be possible to allow setting CLOCK_MONOTONIC at the very
>> > > beginning of time?  So that all of the nodes in a cluster can be in
>> > > sync?
>> > >
>> > > No change in skew just in offset for CLOCK_MONOTONIC.
>> > >
>> > > There are also dragons involved in coordinating things so that
>> > > CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used.  So I don't
>> > > know if allowing CLOCK_MONOTONIC to be set would be practical but it
>> > > seems work exploring all on it's own.
>> >
>> > It's used very early on in the kernel, so that would be a major surprise
>> > for many things including user space which has expectations on clock
>> > monotonic.
>> >
>> > It would be reasonably easy to add CLOCK_MONONOTIC_SYNC which can be set in
>> > the way you described and then in name spaces make it possible to magically
>> > map CLOCK_MONOTONIC to CLOCK_MONOTONIC_SYNC.
>> >
>> > It still wouldn't allow to have different NTP/PTP time domains, but might
>> > be a good start to address the main migration headaches.
>> 
>> If we make CLOCK_MONOTONIC settable this way in a namespace,
>> do you think that should include device drivers that report timestamps
>> in CLOCK_MONOTONIC base, or only the timekeeping clock and timer
>> interfaces?
>
> Uurgh. That gets messy very fast.
>
>> Examples for drivers that can report timestamps are input, sound, v4l,
>> and drm. I think most of these can report stamps in either monotonic
>> or realtime base, while socket timestamps notably are always in
>> realtime.
>> 
>> We can probably get away with not setting the timebase for those
>> device drivers as long as the checkpoint/restart and migration features
>> are not expected to restore the state of an open character device
>> in that way. I don't know if that is a reasonable assumption to make
>> for the examples I listed.
>
> No idea. I'm not a container migration wizard.

Direct access to hardware/drivers and not through an abstraction like
the vfs (an abstraction over block devices) can legitimately be handled
by hotplug events.  I unplug one keyboard I plug in another.

I don't know if the input layer is more of a general abstraction
or more of a hardware device.  I have not dug into it but my guess
is abstraction from what I have heard.

The scary difficulty here is if after restart input is reporting times
in CLOCK_MONOTONIC and the applications in the namespace are talking
about times in CLOCK_MONOTONIC_SYNC.  Then there is an issue.  As even
with a fixed offset the times don't match up.

So a time namespace absolutely needs to do is figure out how to deal
with all of the kernel interfaces reporting times and figure out how to
report them in the current time namespace.

Eric

Re: Setting monotonic time?

[Eric W. Biederman]

Thomas Gleixner  writes:

> On Tue, 2 Oct 2018, Arnd Bergmann wrote:
>> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner  wrote:
>> >
>> > On Mon, 1 Oct 2018, Eric W. Biederman wrote:
>> > > In the context of process migration there is a simpler subproblem that I
>> > > think it is worth exploring if we can do something about.
>> > >
>> > > For a cluster of machines all running with synchronized
>> > > clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
>> > > machines.   Not having a matching CLOCK_MONOTONIC prevents successful
>> > > process migration between nodes in that cluster.
>> > >
>> > > Would it be possible to allow setting CLOCK_MONOTONIC at the very
>> > > beginning of time?  So that all of the nodes in a cluster can be in
>> > > sync?
>> > >
>> > > No change in skew just in offset for CLOCK_MONOTONIC.
>> > >
>> > > There are also dragons involved in coordinating things so that
>> > > CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used.  So I don't
>> > > know if allowing CLOCK_MONOTONIC to be set would be practical but it
>> > > seems work exploring all on it's own.
>> >
>> > It's used very early on in the kernel, so that would be a major surprise
>> > for many things including user space which has expectations on clock
>> > monotonic.
>> >
>> > It would be reasonably easy to add CLOCK_MONONOTIC_SYNC which can be set in
>> > the way you described and then in name spaces make it possible to magically
>> > map CLOCK_MONOTONIC to CLOCK_MONOTONIC_SYNC.
>> >
>> > It still wouldn't allow to have different NTP/PTP time domains, but might
>> > be a good start to address the main migration headaches.
>> 
>> If we make CLOCK_MONOTONIC settable this way in a namespace,
>> do you think that should include device drivers that report timestamps
>> in CLOCK_MONOTONIC base, or only the timekeeping clock and timer
>> interfaces?
>
> Uurgh. That gets messy very fast.
>
>> Examples for drivers that can report timestamps are input, sound, v4l,
>> and drm. I think most of these can report stamps in either monotonic
>> or realtime base, while socket timestamps notably are always in
>> realtime.
>> 
>> We can probably get away with not setting the timebase for those
>> device drivers as long as the checkpoint/restart and migration features
>> are not expected to restore the state of an open character device
>> in that way. I don't know if that is a reasonable assumption to make
>> for the examples I listed.
>
> No idea. I'm not a container migration wizard.

Direct access to hardware/drivers and not through an abstraction like
the vfs (an abstraction over block devices) can legitimately be handled
by hotplug events.  I unplug one keyboard I plug in another.

I don't know if the input layer is more of a general abstraction
or more of a hardware device.  I have not dug into it but my guess
is abstraction from what I have heard.

The scary difficulty here is if after restart input is reporting times
in CLOCK_MONOTONIC and the applications in the namespace are talking
about times in CLOCK_MONOTONIC_SYNC.  Then there is an issue.  As even
with a fixed offset the times don't match up.

So a time namespace absolutely needs to do is figure out how to deal
with all of the kernel interfaces reporting times and figure out how to
report them in the current time namespace.

Eric

Re: [PATCH] cpufreq: dt-platdev: mark RK3399 as having separate policies per cluster

[Viresh Kumar]

On 01-10-18, 13:21, Dmitry Torokhov wrote:
> RK3399 has one cluster with 4 small cores, and another one with 2 big
> cores, with cores in different clusters having different OPPs and thus
> different policies. Let's enable this via "have_governor_per_policy"
> platform data.

The policies are always different in such cases, with or without this flag. What
this flag rather enables is for us to have separate set of tunables for the
governor for individual policies.

For example, without this flag there will be a single governor directory:

/sys/devices/system/cpu/cpufreq/schedutil/

and the value of tunables in that directory will be used for all cpufreq
policies.

With this flag you wouldn't have the governor directory there, but rather in:

/sys/devices/system/cpu/cpufreq/policy*/schedutil/

i.e. tunables per policy and that's why the name of the flag is:
have_governor_per_policy.

> Signed-off-by: Dmitry Torokhov 
> ---
> 
> Not tested, but we had a patch unconditionally enabling
> CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices
> based on RK3399 platform. 

Sure, that sounds good. Just that you need to update the commit log a bit.

>  drivers/cpufreq/cpufreq-dt-platdev.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index fe14c57de6ca..040ec0f711f9 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst = 
> {
>   { .compatible = "rockchip,rk3328", },
>   { .compatible = "rockchip,rk3366", },
>   { .compatible = "rockchip,rk3368", },
> - { .compatible = "rockchip,rk3399", },
> + { .compatible = "rockchip,rk3399",
> +   .data = &(struct cpufreq_dt_platform_data)

data is void *. No need to provide typecast information. This shouldn't throw
any build warnings I believe.

> + { .have_governor_per_policy = true, },

-- 
viresh

Re: [PATCH] cpufreq: dt-platdev: mark RK3399 as having separate policies per cluster

[Viresh Kumar]

On 01-10-18, 13:21, Dmitry Torokhov wrote:
> RK3399 has one cluster with 4 small cores, and another one with 2 big
> cores, with cores in different clusters having different OPPs and thus
> different policies. Let's enable this via "have_governor_per_policy"
> platform data.

The policies are always different in such cases, with or without this flag. What
this flag rather enables is for us to have separate set of tunables for the
governor for individual policies.

For example, without this flag there will be a single governor directory:

/sys/devices/system/cpu/cpufreq/schedutil/

and the value of tunables in that directory will be used for all cpufreq
policies.

With this flag you wouldn't have the governor directory there, but rather in:

/sys/devices/system/cpu/cpufreq/policy*/schedutil/

i.e. tunables per policy and that's why the name of the flag is:
have_governor_per_policy.

> Signed-off-by: Dmitry Torokhov 
> ---
> 
> Not tested, but we had a patch unconditionally enabling
> CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices
> based on RK3399 platform. 

Sure, that sounds good. Just that you need to update the commit log a bit.

>  drivers/cpufreq/cpufreq-dt-platdev.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index fe14c57de6ca..040ec0f711f9 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst = 
> {
>   { .compatible = "rockchip,rk3328", },
>   { .compatible = "rockchip,rk3366", },
>   { .compatible = "rockchip,rk3368", },
> - { .compatible = "rockchip,rk3399", },
> + { .compatible = "rockchip,rk3399",
> +   .data = &(struct cpufreq_dt_platform_data)

data is void *. No need to provide typecast information. This shouldn't throw
any build warnings I believe.

> + { .have_governor_per_policy = true, },

-- 
viresh

Re: linux-next: occassional build errors

[Masahiro Yamada]

Hi Stephen,

On Wed, Oct 3, 2018 at 12:51 PM Stephen Rothwell  wrote:
>
> Hi Masahiro,
>
> I don't know if that has anything to changes in the kbuild system, but
> since Tuesday, I have been getting random build errors that go away after
> I remove the object directory and build again.


I have no idea.

Is it fine if you use kbuild tree from the last week?


I added 4 kbuild patches this week, but they look irrelevant.

masahiro@pug:~/ref/linux-next$ git log  --oneline
next-20180928..next-20181002  | grep kbuild
4712eca8 Merge remote-tracking branch 'kbuild/for-next'
ae5c311 Merge remote-tracking branch 'kbuild-current/fixes'
7163c4d Merge branch 'kbuild' into for-next
7c59867 kbuild: simplify command line creation in scripts/mkmakefile
23d86e8 kbuild: do not pass $(objtree) to scripts/mkmakefile
166011a kbuild: remove user ID check in scripts/mkmakefile
e4db0f7 kbuild: remove VERSION and PATCHLEVEL from $(objtree)/Makefile



>  The latest example is this:
>
> include/linux/kconfig.h: file not recognized: file format not recognized
> make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
> make[1]: *** [Makefile:1057: crypto] Error 2
> make: *** [Makefile:152: sub-make] Error 2
> Command exited with non-zero status 2
>
> It is always complaining about a .h file ...
>
> Makefile:152 is the MAKE lien below:
>
> # Invoke a second make in the output directory, passing relevant variables
> sub-make:
> $(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
> -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
>
> Makefile:1057 is the MAKE line below:
>
> PHONY += $(vmlinux-dirs)
> $(vmlinux-dirs): prepare scripts
> $(Q)$(MAKE) $(build)=$@ need-builtin=1
>
> scripts/Makefile.build:492 is the if_changed line below:
>
> $(multi-used-m): FORCE
> $(call if_changed,link_multi-m)
> @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
>$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
> $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
>
> Not sure what else I can tell you.
>


Does this happen only when building a module?

Can you provide a procedure
to reproduce this?



-- 
Best Regards
Masahiro Yamada

Re: linux-next: occassional build errors

[Masahiro Yamada]

Hi Stephen,

On Wed, Oct 3, 2018 at 12:51 PM Stephen Rothwell  wrote:
>
> Hi Masahiro,
>
> I don't know if that has anything to changes in the kbuild system, but
> since Tuesday, I have been getting random build errors that go away after
> I remove the object directory and build again.


I have no idea.

Is it fine if you use kbuild tree from the last week?


I added 4 kbuild patches this week, but they look irrelevant.

masahiro@pug:~/ref/linux-next$ git log  --oneline
next-20180928..next-20181002  | grep kbuild
4712eca8 Merge remote-tracking branch 'kbuild/for-next'
ae5c311 Merge remote-tracking branch 'kbuild-current/fixes'
7163c4d Merge branch 'kbuild' into for-next
7c59867 kbuild: simplify command line creation in scripts/mkmakefile
23d86e8 kbuild: do not pass $(objtree) to scripts/mkmakefile
166011a kbuild: remove user ID check in scripts/mkmakefile
e4db0f7 kbuild: remove VERSION and PATCHLEVEL from $(objtree)/Makefile



>  The latest example is this:
>
> include/linux/kconfig.h: file not recognized: file format not recognized
> make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
> make[1]: *** [Makefile:1057: crypto] Error 2
> make: *** [Makefile:152: sub-make] Error 2
> Command exited with non-zero status 2
>
> It is always complaining about a .h file ...
>
> Makefile:152 is the MAKE lien below:
>
> # Invoke a second make in the output directory, passing relevant variables
> sub-make:
> $(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
> -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
>
> Makefile:1057 is the MAKE line below:
>
> PHONY += $(vmlinux-dirs)
> $(vmlinux-dirs): prepare scripts
> $(Q)$(MAKE) $(build)=$@ need-builtin=1
>
> scripts/Makefile.build:492 is the if_changed line below:
>
> $(multi-used-m): FORCE
> $(call if_changed,link_multi-m)
> @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
>$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
> $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
>
> Not sure what else I can tell you.
>


Does this happen only when building a module?

Can you provide a procedure
to reproduce this?



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 4.14 114/165] x86/vdso: Fix vDSO build if a retpoline is emitted

[Andy Lutomirski]

On Tue, Oct 2, 2018 at 1:21 AM Nikola Ciprich
 wrote:
>
> Hi Greg and others,
>
> sorry for reporting this so late, but still...
>
> this breaks build on older compilers, since it requires
> -mindirect-branch=thunk-inline -mindirect-branch-register even though
> retpoline support is disabled in kernel config.. is this expected?
>

Nope, my patch was buggy.  Can you test the fix I just sent?

Re: [PATCH 4.14 114/165] x86/vdso: Fix vDSO build if a retpoline is emitted

[Andy Lutomirski]

On Tue, Oct 2, 2018 at 1:21 AM Nikola Ciprich
 wrote:
>
> Hi Greg and others,
>
> sorry for reporting this so late, but still...
>
> this breaks build on older compilers, since it requires
> -mindirect-branch=thunk-inline -mindirect-branch-register even though
> retpoline support is disabled in kernel config.. is this expected?
>

Nope, my patch was buggy.  Can you test the fix I just sent?

[PATCH] x86/vdso: Only enable vDSO retpolines when enabled and supported

[Andy Lutomirski]

When I fixed the vDSO build to use inline retpolines, I messed up
the Makefile logic and made it unconditional.  It should have
depended on CONFIG_RETPOLINE and on the availability of compiler
support.  This broke the build on some older compilers.

Fixes: 2e549b2ee0e3 ("x86/vdso: Fix vDSO build if a retpoline is emitted")
Cc: sta...@vger.kernel.org
Reported-by: nikola.cipr...@linuxbox.cz
Cc: Thomas Gleixner 
Cc: Matt Rickard 
Cc: Borislav Petkov 
Cc: jason.vas.d...@gmail.com
Cc: David Woodhouse 
Cc: Peter Zijlstra 
Cc: Andi Kleen 
Cc: nikola.cipr...@linuxbox.cz
Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/vdso/Makefile | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index fa3f439f0a92..141d415a8c80 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -68,7 +68,13 @@ $(obj)/vdso-image-%.c: $(obj)/vdso%.so.dbg $(obj)/vdso%.so 
$(obj)/vdso2c FORCE
 CFL := $(PROFILING) -mcmodel=small -fPIC -O2 -fasynchronous-unwind-tables -m64 
\
$(filter -g%,$(KBUILD_CFLAGS)) $(call cc-option, -fno-stack-protector) \
-fno-omit-frame-pointer -foptimize-sibling-calls \
-   -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO $(RETPOLINE_VDSO_CFLAGS)
+   -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
+
+ifdef CONFIG_RETPOLINE
+ifneq ($(RETPOLINE_VDSO_CFLAGS),)
+  CFL += $(RETPOLINE_VDSO_CFLAGS)
+endif
+endif
 
 $(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) 
$(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
 
@@ -138,7 +144,13 @@ KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
 KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
 KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
 KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
-KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
+
+ifdef CONFIG_RETPOLINE
+ifneq ($(RETPOLINE_VDSO_CFLAGS),)
+  KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
+endif
+endif
+
 $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
 
 $(obj)/vdso32.so.dbg: FORCE \
-- 
2.17.1

[PATCH] x86/vdso: Only enable vDSO retpolines when enabled and supported

[Andy Lutomirski]

When I fixed the vDSO build to use inline retpolines, I messed up
the Makefile logic and made it unconditional.  It should have
depended on CONFIG_RETPOLINE and on the availability of compiler
support.  This broke the build on some older compilers.

Fixes: 2e549b2ee0e3 ("x86/vdso: Fix vDSO build if a retpoline is emitted")
Cc: sta...@vger.kernel.org
Reported-by: nikola.cipr...@linuxbox.cz
Cc: Thomas Gleixner 
Cc: Matt Rickard 
Cc: Borislav Petkov 
Cc: jason.vas.d...@gmail.com
Cc: David Woodhouse 
Cc: Peter Zijlstra 
Cc: Andi Kleen 
Cc: nikola.cipr...@linuxbox.cz
Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/vdso/Makefile | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index fa3f439f0a92..141d415a8c80 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -68,7 +68,13 @@ $(obj)/vdso-image-%.c: $(obj)/vdso%.so.dbg $(obj)/vdso%.so 
$(obj)/vdso2c FORCE
 CFL := $(PROFILING) -mcmodel=small -fPIC -O2 -fasynchronous-unwind-tables -m64 
\
$(filter -g%,$(KBUILD_CFLAGS)) $(call cc-option, -fno-stack-protector) \
-fno-omit-frame-pointer -foptimize-sibling-calls \
-   -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO $(RETPOLINE_VDSO_CFLAGS)
+   -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
+
+ifdef CONFIG_RETPOLINE
+ifneq ($(RETPOLINE_VDSO_CFLAGS),)
+  CFL += $(RETPOLINE_VDSO_CFLAGS)
+endif
+endif
 
 $(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) 
$(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
 
@@ -138,7 +144,13 @@ KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
 KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
 KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
 KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
-KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
+
+ifdef CONFIG_RETPOLINE
+ifneq ($(RETPOLINE_VDSO_CFLAGS),)
+  KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
+endif
+endif
+
 $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
 
 $(obj)/vdso32.so.dbg: FORCE \
-- 
2.17.1

linux-next: occassional build errors

[Stephen Rothwell]

Hi Masahiro,

I don't know if that has anything to changes in the kbuild system, but
since Tuesday, I have been getting random build errors that go away after
I remove the object directory and build again.  The latest example is this:

include/linux/kconfig.h: file not recognized: file format not recognized
make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
make[1]: *** [Makefile:1057: crypto] Error 2
make: *** [Makefile:152: sub-make] Error 2
Command exited with non-zero status 2

It is always complaining about a .h file ...

Makefile:152 is the MAKE lien below:

# Invoke a second make in the output directory, passing relevant variables
sub-make:
$(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
-f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))

Makefile:1057 is the MAKE line below:

PHONY += $(vmlinux-dirs)
$(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@ need-builtin=1

scripts/Makefile.build:492 is the if_changed line below:

$(multi-used-m): FORCE
$(call if_changed,link_multi-m)
@{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
   $(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
$(call multi_depend, $(multi-used-m), .o, -objs -y -m)

Not sure what else I can tell you.

-- 
Cheers,
Stephen Rothwell


pgpxd3Qr8UZX0.pgp
Description: OpenPGP digital signature

linux-next: occassional build errors

[Stephen Rothwell]

Hi Masahiro,

I don't know if that has anything to changes in the kbuild system, but
since Tuesday, I have been getting random build errors that go away after
I remove the object directory and build again.  The latest example is this:

include/linux/kconfig.h: file not recognized: file format not recognized
make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
make[1]: *** [Makefile:1057: crypto] Error 2
make: *** [Makefile:152: sub-make] Error 2
Command exited with non-zero status 2

It is always complaining about a .h file ...

Makefile:152 is the MAKE lien below:

# Invoke a second make in the output directory, passing relevant variables
sub-make:
$(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
-f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))

Makefile:1057 is the MAKE line below:

PHONY += $(vmlinux-dirs)
$(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@ need-builtin=1

scripts/Makefile.build:492 is the if_changed line below:

$(multi-used-m): FORCE
$(call if_changed,link_multi-m)
@{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
   $(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
$(call multi_depend, $(multi-used-m), .o, -objs -y -m)

Not sure what else I can tell you.

-- 
Cheers,
Stephen Rothwell


pgpxd3Qr8UZX0.pgp
Description: OpenPGP digital signature

Re: [PATCH] perf record: use unmapped IP for inline callchain cursors

[Ravi Bangoria]

On 10/02/2018 09:02 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2018 at 09:39:49AM +0200, Milian Wolff escreveu:
>> Only use the mapped IP to find inline frames, but keep
>> using the unmapped IP for the callchain cursor. This
>> ensures we properly show the unmapped IP when displaying
>> a frame we received via the dso__parse_addr_inlines API
>> for a module which does not contain sufficient debug symbols
>> to show the srcline.
> 
> So, the patch came mangled, I fixed it up, please check, I'm adding Ravi
> to the CC list, so that he can check as well and retest, right Ravi?
> 
> - Arnaldo
> 
> From d9ddee9653d5676130471de9bc688fc7ec7b4fc4 Mon Sep 17 00:00:00 2001
> From: Milian Wolff 
> Date: Tue, 2 Oct 2018 09:39:49 +0200
> Subject: [PATCH 1/1] perf record: use unmapped IP for inline callchain cursors
> 
> Only use the mapped IP to find inline frames, but keep using the unmapped IP
> for the callchain cursor. This ensures we properly show the unmapped IP when
> displaying a frame we received via the dso__parse_addr_inlines API for a 
> module
> which does not contain sufficient debug symbols to show the srcline.
> 
> Before:
> 
>   $ perf record -e cycles:u --call-graph ls
>   $ perf script
>   ...
>   ls 12853  2735.563911:  43354 cycles:u:
>  17878 __GI___tunables_init+0x01d1d63a0118 
> (/usr/lib/ld-2.28.so)
>  19ee9 _dl_sysdep_start+0x01d1d63a02e9 
> (/usr/lib/ld-2.28.so)
>   3087 _dl_start+0x01d1d63a0287 (/usr/lib/ld-2.28.so)
>   2007 _start+0x01d1d63a0007 (/usr/lib/ld-2.28.so)
> 
> After:
> 
>   $ perf script
>   ...
>   ls 12853  2735.563911:  43354 cycles:u:
>   7f1714e46878 __GI___tunables_init+0x118 (/usr/lib/ld-2.28.so)
>   7f1714e48ee9 _dl_sysdep_start+0x2e9 (/usr/lib/ld-2.28.so)
>   7f1714e32087 _dl_start+0x287 (/usr/lib/ld-2.28.so)
>   7f1714e31007 _start+0x7 (/usr/lib/ld-2.28.so)

With current perf/urgent:

  $ sudo ./perf record --call-graph=dwarf -e probe_libc:inet_pton -- ping -6 -c 
1 ::1
  $ sudo ./perf script
  ping  4109 [011] 767269.031273: probe_libc:inet_pton: (7fff944cb458)
  15b458 __inet_pton+0xd7920008 (inlined)
  10feb3 gaih_inet.constprop.7+0xd7920f43 
(/usr/lib64/libc-2.26.
  110a13 __GI_getaddrinfo+0xd7920163 (inlined)
   13c752d6f _init+0xbfb (/usr/bin/ping)
   2371f generic_start_main.isra.0+0xd792013f 
(/usr/lib64/libc-2
   2391b __libc_start_main+0xd79200bb 
(/usr/lib64/libc-2.26.so)

With this patch:

  $ sudo ./perf script
  ping  4109 [011] 767269.031273: probe_libc:inet_pton: (7fff944cb458)
7fff944cb458 __inet_pton+0x8 (inlined)
7fff9447feb3 gaih_inet.constprop.7+0xf43 (/usr/lib64/libc-2.26.so)
7fff94480a13 __GI_getaddrinfo+0x163 (inlined)
   13c752d6f _init+0xbfb (/usr/bin/ping)
7fff9439371f generic_start_main.isra.0+0x13f 
(/usr/lib64/libc-2.26.so)
7fff9439391b __libc_start_main+0xbb (/usr/lib64/libc-2.26.so)

LGTM.

Tested-by: Ravi Bangoria 

Re: [PATCH] perf record: use unmapped IP for inline callchain cursors

[Ravi Bangoria]

On 10/02/2018 09:02 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2018 at 09:39:49AM +0200, Milian Wolff escreveu:
>> Only use the mapped IP to find inline frames, but keep
>> using the unmapped IP for the callchain cursor. This
>> ensures we properly show the unmapped IP when displaying
>> a frame we received via the dso__parse_addr_inlines API
>> for a module which does not contain sufficient debug symbols
>> to show the srcline.
> 
> So, the patch came mangled, I fixed it up, please check, I'm adding Ravi
> to the CC list, so that he can check as well and retest, right Ravi?
> 
> - Arnaldo
> 
> From d9ddee9653d5676130471de9bc688fc7ec7b4fc4 Mon Sep 17 00:00:00 2001
> From: Milian Wolff 
> Date: Tue, 2 Oct 2018 09:39:49 +0200
> Subject: [PATCH 1/1] perf record: use unmapped IP for inline callchain cursors
> 
> Only use the mapped IP to find inline frames, but keep using the unmapped IP
> for the callchain cursor. This ensures we properly show the unmapped IP when
> displaying a frame we received via the dso__parse_addr_inlines API for a 
> module
> which does not contain sufficient debug symbols to show the srcline.
> 
> Before:
> 
>   $ perf record -e cycles:u --call-graph ls
>   $ perf script
>   ...
>   ls 12853  2735.563911:  43354 cycles:u:
>  17878 __GI___tunables_init+0x01d1d63a0118 
> (/usr/lib/ld-2.28.so)
>  19ee9 _dl_sysdep_start+0x01d1d63a02e9 
> (/usr/lib/ld-2.28.so)
>   3087 _dl_start+0x01d1d63a0287 (/usr/lib/ld-2.28.so)
>   2007 _start+0x01d1d63a0007 (/usr/lib/ld-2.28.so)
> 
> After:
> 
>   $ perf script
>   ...
>   ls 12853  2735.563911:  43354 cycles:u:
>   7f1714e46878 __GI___tunables_init+0x118 (/usr/lib/ld-2.28.so)
>   7f1714e48ee9 _dl_sysdep_start+0x2e9 (/usr/lib/ld-2.28.so)
>   7f1714e32087 _dl_start+0x287 (/usr/lib/ld-2.28.so)
>   7f1714e31007 _start+0x7 (/usr/lib/ld-2.28.so)

With current perf/urgent:

  $ sudo ./perf record --call-graph=dwarf -e probe_libc:inet_pton -- ping -6 -c 
1 ::1
  $ sudo ./perf script
  ping  4109 [011] 767269.031273: probe_libc:inet_pton: (7fff944cb458)
  15b458 __inet_pton+0xd7920008 (inlined)
  10feb3 gaih_inet.constprop.7+0xd7920f43 
(/usr/lib64/libc-2.26.
  110a13 __GI_getaddrinfo+0xd7920163 (inlined)
   13c752d6f _init+0xbfb (/usr/bin/ping)
   2371f generic_start_main.isra.0+0xd792013f 
(/usr/lib64/libc-2
   2391b __libc_start_main+0xd79200bb 
(/usr/lib64/libc-2.26.so)

With this patch:

  $ sudo ./perf script
  ping  4109 [011] 767269.031273: probe_libc:inet_pton: (7fff944cb458)
7fff944cb458 __inet_pton+0x8 (inlined)
7fff9447feb3 gaih_inet.constprop.7+0xf43 (/usr/lib64/libc-2.26.so)
7fff94480a13 __GI_getaddrinfo+0x163 (inlined)
   13c752d6f _init+0xbfb (/usr/bin/ping)
7fff9439371f generic_start_main.isra.0+0x13f 
(/usr/lib64/libc-2.26.so)
7fff9439391b __libc_start_main+0xbb (/usr/lib64/libc-2.26.so)

LGTM.

Tested-by: Ravi Bangoria 

Re: [PATCH v3 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

[Zong Li]

Christoph Hellwig  於 2018年10月2日 週二 下午10:51寫道：
>
> On Tue, Oct 02, 2018 at 04:52:31PM +0800, Zong Li wrote:
> > From: Vincent Chen 
> >
> > For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero
> > after AND with PAGE_MASK because the data type of PAGE_MASK is
> > unsigned long. To fix this problem, the page alignment is done by
> > subtracting the page offset instead of AND with PAGE_MASK.
> >
> > Signed-off-by: Vincent Chen 
>
> Looks good,
>
> Reviewed-by: Christoph Hellwig 
>
> (and I'm pretty sure I reviewed this before..)

Hi Christoph,

Very sorry about that. I didn't notice I lose these review tags. Could
you please help to review again in version 4 patches? Thank you.

Regards,
Zong

Re: [PATCH v3 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

[Zong Li]

Christoph Hellwig  於 2018年10月2日 週二 下午10:51寫道：
>
> On Tue, Oct 02, 2018 at 04:52:31PM +0800, Zong Li wrote:
> > From: Vincent Chen 
> >
> > For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero
> > after AND with PAGE_MASK because the data type of PAGE_MASK is
> > unsigned long. To fix this problem, the page alignment is done by
> > subtracting the page offset instead of AND with PAGE_MASK.
> >
> > Signed-off-by: Vincent Chen 
>
> Looks good,
>
> Reviewed-by: Christoph Hellwig 
>
> (and I'm pretty sure I reviewed this before..)

Hi Christoph,

Very sorry about that. I didn't notice I lose these review tags. Could
you please help to review again in version 4 patches? Thank you.

Regards,
Zong

[PATCH v4 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines

[Zong Li]

Add umoddi3 and udivmoddi4 support for 32-bit.

The RV32 need the umoddi3 to do modulo when the operands are long long
type, like other libraries implementation such as ucmpdi2, lshrdi3 and
so on.

I encounter the undefined reference 'umoddi3' when I use the in
house dma driver, although it is in house driver, but I think that
umoddi3 is a common function for RV32.

The udivmoddi4 and umoddi3 are copies from libgcc in gcc 4.2.1.
There are other functions use the udivmoddi4 in libgcc, so I separate
the umoddi3 and udivmoddi4 for flexible extension in the future.

Signed-off-by: Zong Li 
---
 lib/Kconfig  |   3 +
 lib/Makefile |   1 +
 lib/udivmoddi4.c | 326 +++
 lib/umoddi3.c|  48 
 4 files changed, 378 insertions(+)
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c

diff --git a/lib/Kconfig b/lib/Kconfig
index a3928d4..d82f206 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -621,3 +621,6 @@ config GENERIC_LIB_CMPDI2
 
 config GENERIC_LIB_UCMPDI2
bool
+
+config GENERIC_LIB_UMODDI3
+   bool
diff --git a/lib/Makefile b/lib/Makefile
index ca3f7eb..51bf24d 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -271,3 +271,4 @@ obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o
 obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o
 obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o
 obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_UMODDI3) += umoddi3.o udivmoddi4.o
diff --git a/lib/udivmoddi4.c b/lib/udivmoddi4.c
new file mode 100644
index 000..ddbe4fa
--- /dev/null
+++ b/lib/udivmoddi4.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* More subroutines needed by GCC output code on some machines.  */
+/* Compile this one with gcc.  */
+/* Copyright (C) 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
+ * 2000, 2001, 2002, 2003, 2004, 2005  Free Software Foundation, Inc.
+ *
+ * This file is part of GCC.
+ *
+ * GCC is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2, or (at your option) any later
+ * version.
+ *
+ * In addition to the permissions in the GNU General Public License, the
+ * Free Software Foundation gives you unlimited permission to link the
+ * compiled version of this file into combinations with other programs,
+ * and to distribute those combinations without any restriction coming
+ * from the use of this file.  (The General Public License restrictions
+ * do apply in other respects; for example, they cover modification of
+ * the file, and distribution when not linked into a combine
+ * executable.)
+ *
+ * GCC 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GCC; see the file COPYING.  If not, write to the Free
+ * Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include 
+
+#define count_leading_zeros(COUNT, X)   ((COUNT) = __builtin_clz(X))
+
+#define W_TYPE_SIZE 32
+
+#define __ll_B ((unsigned long) 1 << (W_TYPE_SIZE / 2))
+#define __ll_lowpart(t) ((unsigned long) (t) & (__ll_B - 1))
+#define __ll_highpart(t) ((unsigned long) (t) >> (W_TYPE_SIZE / 2))
+
+/* If we still don't have umul_ppmm, define it using plain C. */
+#if !defined(umul_ppmm)
+#define umul_ppmm(w1, w0, u, v)
\
+   do {\
+   unsigned long __x0, __x1, __x2, __x3;   \
+   unsigned short __ul, __vl, __uh, __vh;  \
+   \
+   __ul = __ll_lowpart(u); \
+   __uh = __ll_highpart(u);\
+   __vl = __ll_lowpart(v); \
+   __vh = __ll_highpart(v);\
+   \
+   __x0 = (unsigned long) __ul * __vl; \
+   __x1 = (unsigned long) __ul * __vh; \
+   __x2 = (unsigned long) __uh * __vl; \
+   __x3 = (unsigned long) __uh * __vh; \
+   \
+   __x1 += __ll_highpart(__x0);\
+   __x1 += __x2;   \
+   if (__x1 < __x2)\
+   __x3 += __ll_B; \

[PATCH v4 4/5] RISC-V: Select GENERIC_LIB_UMODDI3 on RV32

[Zong Li]

On RV32, it will use the __umoddi3. Select GENERIC_LIB_UMODDI3 to avoid
undefined reference.

Signed-off-by: Zong Li 
---
 arch/riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a344980..dc262fa 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -108,6 +108,7 @@ config ARCH_RV32I
select GENERIC_LIB_ASHRDI3
select GENERIC_LIB_LSHRDI3
select GENERIC_LIB_UCMPDI2
+   select GENERIC_LIB_UMODDI3
 
 config ARCH_RV64I
bool "RV64I"
-- 
2.7.4

[PATCH v4 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines

[Zong Li]

Add umoddi3 and udivmoddi4 support for 32-bit.

The RV32 need the umoddi3 to do modulo when the operands are long long
type, like other libraries implementation such as ucmpdi2, lshrdi3 and
so on.

I encounter the undefined reference 'umoddi3' when I use the in
house dma driver, although it is in house driver, but I think that
umoddi3 is a common function for RV32.

The udivmoddi4 and umoddi3 are copies from libgcc in gcc 4.2.1.
There are other functions use the udivmoddi4 in libgcc, so I separate
the umoddi3 and udivmoddi4 for flexible extension in the future.

Signed-off-by: Zong Li 
---
 lib/Kconfig  |   3 +
 lib/Makefile |   1 +
 lib/udivmoddi4.c | 326 +++
 lib/umoddi3.c|  48 
 4 files changed, 378 insertions(+)
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c

diff --git a/lib/Kconfig b/lib/Kconfig
index a3928d4..d82f206 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -621,3 +621,6 @@ config GENERIC_LIB_CMPDI2
 
 config GENERIC_LIB_UCMPDI2
bool
+
+config GENERIC_LIB_UMODDI3
+   bool
diff --git a/lib/Makefile b/lib/Makefile
index ca3f7eb..51bf24d 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -271,3 +271,4 @@ obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o
 obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o
 obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o
 obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_UMODDI3) += umoddi3.o udivmoddi4.o
diff --git a/lib/udivmoddi4.c b/lib/udivmoddi4.c
new file mode 100644
index 000..ddbe4fa
--- /dev/null
+++ b/lib/udivmoddi4.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* More subroutines needed by GCC output code on some machines.  */
+/* Compile this one with gcc.  */
+/* Copyright (C) 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
+ * 2000, 2001, 2002, 2003, 2004, 2005  Free Software Foundation, Inc.
+ *
+ * This file is part of GCC.
+ *
+ * GCC is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2, or (at your option) any later
+ * version.
+ *
+ * In addition to the permissions in the GNU General Public License, the
+ * Free Software Foundation gives you unlimited permission to link the
+ * compiled version of this file into combinations with other programs,
+ * and to distribute those combinations without any restriction coming
+ * from the use of this file.  (The General Public License restrictions
+ * do apply in other respects; for example, they cover modification of
+ * the file, and distribution when not linked into a combine
+ * executable.)
+ *
+ * GCC 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GCC; see the file COPYING.  If not, write to the Free
+ * Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include 
+
+#define count_leading_zeros(COUNT, X)   ((COUNT) = __builtin_clz(X))
+
+#define W_TYPE_SIZE 32
+
+#define __ll_B ((unsigned long) 1 << (W_TYPE_SIZE / 2))
+#define __ll_lowpart(t) ((unsigned long) (t) & (__ll_B - 1))
+#define __ll_highpart(t) ((unsigned long) (t) >> (W_TYPE_SIZE / 2))
+
+/* If we still don't have umul_ppmm, define it using plain C. */
+#if !defined(umul_ppmm)
+#define umul_ppmm(w1, w0, u, v)
\
+   do {\
+   unsigned long __x0, __x1, __x2, __x3;   \
+   unsigned short __ul, __vl, __uh, __vh;  \
+   \
+   __ul = __ll_lowpart(u); \
+   __uh = __ll_highpart(u);\
+   __vl = __ll_lowpart(v); \
+   __vh = __ll_highpart(v);\
+   \
+   __x0 = (unsigned long) __ul * __vl; \
+   __x1 = (unsigned long) __ul * __vh; \
+   __x2 = (unsigned long) __uh * __vl; \
+   __x3 = (unsigned long) __uh * __vh; \
+   \
+   __x1 += __ll_highpart(__x0);\
+   __x1 += __x2;   \
+   if (__x1 < __x2)\
+   __x3 += __ll_B; \

[PATCH v4 4/5] RISC-V: Select GENERIC_LIB_UMODDI3 on RV32

[Zong Li]

On RV32, it will use the __umoddi3. Select GENERIC_LIB_UMODDI3 to avoid
undefined reference.

Signed-off-by: Zong Li 
---
 arch/riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a344980..dc262fa 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -108,6 +108,7 @@ config ARCH_RV32I
select GENERIC_LIB_ASHRDI3
select GENERIC_LIB_LSHRDI3
select GENERIC_LIB_UCMPDI2
+   select GENERIC_LIB_UMODDI3
 
 config ARCH_RV64I
bool "RV64I"
-- 
2.7.4

[PATCH v4 1/5] RISC-V: Build tishift only on 64-bit

[Zong Li]

Only RV64 supports 128 integer size.

Signed-off-by: Zong Li 
---
 arch/riscv/lib/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 445ec84..5739bd0 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -2,6 +2,7 @@ lib-y   += delay.o
 lib-y  += memcpy.o
 lib-y  += memset.o
 lib-y  += uaccess.o
-lib-y  += tishift.o
+
+lib-(CONFIG_64BIT) += tishift.o
 
 lib-$(CONFIG_32BIT) += udivdi3.o
-- 
2.7.4

[PATCH v4 0/5] Fix some bugs on RV32 build fail and issue

[Zong Li]

This patches contain the modificaion as follows:
1. Fix up the building fail on RV32.
2. Add umoddi3 and udivmoddi4 functions for RV32.
3. Fix ioremap problem on RV32.

Thanks all for review these code and modify the copyright description.

Changes in v4:
 - Retain the complete copyright description.
 - Modify commit message.
 - Rebase upstream code.

Changes in v3:
 - Change the copyright notices to GPLv2 from  gcc 4.2.1.

Changes in v2:
 - Retain the copyright notices from libgcc in umoddi3.c and udivmoddi4.c.

Vincent Chen (1):
  RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

Zong Li (4):
  RISC-V: Build tishift only on 64-bit
  RISC-V: Add preprocessor directive for swiotlb
  lib: Add umoddi3 and udivmoddi4 of GCC library routines
  RISC-V: Select GENERIC_LIB_UMODDI3 on RV32

 arch/riscv/Kconfig|   1 +
 arch/riscv/kernel/setup.c |   3 +
 arch/riscv/lib/Makefile   |   3 +-
 arch/riscv/mm/ioremap.c   |   2 +-
 lib/Kconfig   |   3 +
 lib/Makefile  |   1 +
 lib/udivmoddi4.c  | 326 ++
 lib/umoddi3.c |  48 +++
 8 files changed, 385 insertions(+), 2 deletions(-)
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c

-- 
2.7.4

[PATCH v4 2/5] RISC-V: Add preprocessor directive for swiotlb

[Zong Li]

On RV32, it doesn't select the SWIOTLB, only RV64 support swiotlb now.

Signed-off-by: Zong Li 
---
 arch/riscv/kernel/setup.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index aee6031..6de6584 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -227,7 +227,10 @@ void __init setup_arch(char **cmdline_p)
setup_bootmem();
paging_init();
unflatten_device_tree();
+
+#ifdef CONFIG_SWIOTLB
swiotlb_init(1);
+#endif
 
 #ifdef CONFIG_SMP
setup_smp();
-- 
2.7.4

[PATCH v4 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

[Zong Li]

From: Vincent Chen 

For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero
after AND with PAGE_MASK because the data type of PAGE_MASK is
unsigned long. To fix this problem, the page alignment is done by
subtracting the page offset instead of AND with PAGE_MASK.

Signed-off-by: Vincent Chen 
---
 arch/riscv/mm/ioremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/ioremap.c b/arch/riscv/mm/ioremap.c
index 70ef272..bd2f2db 100644
--- a/arch/riscv/mm/ioremap.c
+++ b/arch/riscv/mm/ioremap.c
@@ -42,7 +42,7 @@ static void __iomem *__ioremap_caller(phys_addr_t addr, 
size_t size,
 
/* Page-align mappings */
offset = addr & (~PAGE_MASK);
-   addr &= PAGE_MASK;
+   addr -= offset;
size = PAGE_ALIGN(size + offset);
 
area = get_vm_area_caller(size, VM_IOREMAP, caller);
-- 
2.7.4

[PATCH v4 1/5] RISC-V: Build tishift only on 64-bit

[Zong Li]

Only RV64 supports 128 integer size.

Signed-off-by: Zong Li 
---
 arch/riscv/lib/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 445ec84..5739bd0 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -2,6 +2,7 @@ lib-y   += delay.o
 lib-y  += memcpy.o
 lib-y  += memset.o
 lib-y  += uaccess.o
-lib-y  += tishift.o
+
+lib-(CONFIG_64BIT) += tishift.o
 
 lib-$(CONFIG_32BIT) += udivdi3.o
-- 
2.7.4

[PATCH v4 0/5] Fix some bugs on RV32 build fail and issue

[Zong Li]

This patches contain the modificaion as follows:
1. Fix up the building fail on RV32.
2. Add umoddi3 and udivmoddi4 functions for RV32.
3. Fix ioremap problem on RV32.

Thanks all for review these code and modify the copyright description.

Changes in v4:
 - Retain the complete copyright description.
 - Modify commit message.
 - Rebase upstream code.

Changes in v3:
 - Change the copyright notices to GPLv2 from  gcc 4.2.1.

Changes in v2:
 - Retain the copyright notices from libgcc in umoddi3.c and udivmoddi4.c.

Vincent Chen (1):
  RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

Zong Li (4):
  RISC-V: Build tishift only on 64-bit
  RISC-V: Add preprocessor directive for swiotlb
  lib: Add umoddi3 and udivmoddi4 of GCC library routines
  RISC-V: Select GENERIC_LIB_UMODDI3 on RV32

 arch/riscv/Kconfig|   1 +
 arch/riscv/kernel/setup.c |   3 +
 arch/riscv/lib/Makefile   |   3 +-
 arch/riscv/mm/ioremap.c   |   2 +-
 lib/Kconfig   |   3 +
 lib/Makefile  |   1 +
 lib/udivmoddi4.c  | 326 ++
 lib/umoddi3.c |  48 +++
 8 files changed, 385 insertions(+), 2 deletions(-)
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c

-- 
2.7.4

[PATCH v4 2/5] RISC-V: Add preprocessor directive for swiotlb

[Zong Li]

On RV32, it doesn't select the SWIOTLB, only RV64 support swiotlb now.

Signed-off-by: Zong Li 
---
 arch/riscv/kernel/setup.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index aee6031..6de6584 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -227,7 +227,10 @@ void __init setup_arch(char **cmdline_p)
setup_bootmem();
paging_init();
unflatten_device_tree();
+
+#ifdef CONFIG_SWIOTLB
swiotlb_init(1);
+#endif
 
 #ifdef CONFIG_SMP
setup_smp();
-- 
2.7.4

[PATCH v4 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

[Zong Li]

From: Vincent Chen 

For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero
after AND with PAGE_MASK because the data type of PAGE_MASK is
unsigned long. To fix this problem, the page alignment is done by
subtracting the page offset instead of AND with PAGE_MASK.

Signed-off-by: Vincent Chen 
---
 arch/riscv/mm/ioremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/ioremap.c b/arch/riscv/mm/ioremap.c
index 70ef272..bd2f2db 100644
--- a/arch/riscv/mm/ioremap.c
+++ b/arch/riscv/mm/ioremap.c
@@ -42,7 +42,7 @@ static void __iomem *__ioremap_caller(phys_addr_t addr, 
size_t size,
 
/* Page-align mappings */
offset = addr & (~PAGE_MASK);
-   addr &= PAGE_MASK;
+   addr -= offset;
size = PAGE_ALIGN(size + offset);
 
area = get_vm_area_caller(size, VM_IOREMAP, caller);
-- 
2.7.4

Re: [ftrace/kprobes PATCH 0/3] tracing: probeevent: Fix module symbol probing

[Steven Rostedt]

On Mon, 1 Oct 2018 11:48:55 -0400
Steven Rostedt  wrote:

> On Thu, 27 Sep 2018 19:48:58 +0900
> Masami Hiramatsu  wrote:
> 
> > Hello Steve,
> > 
> > Could you also include this series to the branch?
> >   
> 
> Hi Masami, 
> 
> I just came back from Embedded / Kernel Recipes, I'll look at these
> today.
> 

Unfortunately, I've been pulled off to other tasks :-(

I'll make it a priority tomorrow (Wednesday).

-- Steve

Re: [ftrace/kprobes PATCH 0/3] tracing: probeevent: Fix module symbol probing

[Steven Rostedt]

On Mon, 1 Oct 2018 11:48:55 -0400
Steven Rostedt  wrote:

> On Thu, 27 Sep 2018 19:48:58 +0900
> Masami Hiramatsu  wrote:
> 
> > Hello Steve,
> > 
> > Could you also include this series to the branch?
> >   
> 
> Hi Masami, 
> 
> I just came back from Embedded / Kernel Recipes, I'll look at these
> today.
> 

Unfortunately, I've been pulled off to other tasks :-(

I'll make it a priority tomorrow (Wednesday).

-- Steve

Re: rcu: Kernel stack is corrupted in: perf_trace_rcu_dyntick

[Steven Rostedt]

On Sat, 29 Sep 2018 17:22:13 +0800
王晓东  wrote:

> Hi there,
> 
> We would like to report a kernel stack corrupted problem we identified
> in the perf_trace_rcu_dyntick function of tracing events subsystem.
> And the problem was founded by syzkaller.  We has tested the PoC on
> the lasted master branch of kernel(4.19.0-rc5+).
> 
> The crash log generated with KASAN enabled:
> 
> root@pc:~# ./perf_trace_rcu_dyntick
> [  582.069938] Kernel panic - not syncing: stack-protector: Kernel
> stack is corrupted in: perf_trace_rcu_dyntick+0x355/0x4f0
> [  582.069938]
> [  582.071341] CPU: 6 PID: 3417 Comm: perf_trace_rcu_ Not tainted 4.19.0-rc5+ 
> #1
> [  582.072134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [  582.073103] Call Trace:
> [  582.073364]  
> [  582.073614]  dump_stack+0x8c/0xce
> [  582.074039]  panic+0x1cb/0x3aa
> [  582.074427]  ? refcount_error_report+0x296/0x296
> [  582.075003]  ? timerqueue_del+0x71/0x130
> [  582.075553]  ? perf_trace_rcu_dyntick+0x355/0x4f0
> [  582.076063]  ? __stack_chk_fail+0x6/0x20
> [  582.076763]  ? perf_trace_rcu_dyntick+0x355/0x4f0
> [  582.077369]  __stack_chk_fail+0x1f/0x20
> [  582.077877]  perf_trace_rcu_dyntick+0x355/0x4f0
> [  582.078442]  ? rcu_gp_is_expedited+0xa0/0xa0
> [  582.078993]  ? rcu_gp_is_expedited+0xa0/0xa0
> [  582.079525]  ? check_preempt_curr+0x1c2/0x2a0
> [  582.080059]  ? sched_clock_cpu+0x18/0x160
> [  582.080551]  rcu_nmi_enter+0x1f0/0x2f0
> [  582.081036]  ? rcu_gp_is_expedited+0xa0/0xa0
> [  582.081507]  irq_enter+0xf/0x80
> [  582.081914]  smp_apic_timer_interrupt+0x1b/0x2d0
> [  582.082480]  apic_timer_interrupt+0xf/0x20
> [  582.082984]  
> [  582.083219] RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50
> [  582.087816] Code: e8 35 0b 20 00 48 8b 14 24 e9 fe fe ff ff 48 89
> df e8 24 0b 20 00 e9 d9 fe ff ff 4c 89 e7 e8 17 0b 20 00 e9 ab fe ff
> ff 90 90 <65> 48 8b 04 25 40 dd 01 00 65 8b 15 70 03 8f 63 81 e2 00 01
> 1f 00
> [  582.090289] RSP: 0018:8800651bf9e0 EFLAGS: 0206 ORIG_RAX:
> ff13
> [  582.091238] RAX:  RBX: 9eed12a5 RCX: 
> 9c6ca1b6
> [  582.092873] RDX: 0005 RSI: 9ee31d71 RDI: 
> 9eed12a4
> [  582.093934] RBP: 0078 R08: ed000d38dfb2 R09: 
> ed000d38dfb1
> [  582.095102] R10: 7350a3ba R11: 880069c6fd8f R12: 
> 8800651bfa6e
> [  582.096444] R13: 0001 R14: dc00 R15: 
> 006a
> [  582.097414]  ? kallsyms_expand_symbol.constprop.11+0x176/0x250
> [  582.098518]  kallsyms_expand_symbol.constprop.11+0x12e/0x250
> [  582.099707]  kallsyms_lookup_name+0xbe/0x1d0
> [  582.100369]  ? kallsyms_on_each_symbol+0x210/0x210
> [  582.101436]  ? snprintf+0xbd/0xf0
> [  582.102029]  ? vsprintf+0x30/0x30
> [  582.102805]  ? kasan_kmalloc+0xa9/0xd0
> [  582.103489]  ? alloc_trace_kprobe+0x6c0/0x930
> [  582.104073]  kprobe_on_func_entry+0x57/0xb0

I'm curious to what kretprobe was used.

-- Steve

> [  582.105421]  register_kretprobe+0x89/0xc10
> [  582.105930]  ? set_print_fmt+0x32/0xa0
> [  582.106376]  __register_trace_kprobe.part.10+0x14e/0x2e0
> [  582.106980]  create_local_trace_kprobe+0x29c/0x3f0
> [  582.107487]  perf_kprobe_init+0x15f/0x210
> [  582.107912]  perf_kprobe_event_init+0xc4/0x140
> [  582.108377]  perf_try_init_event+0xcb/0x290
> [  582.108817]  perf_event_alloc+0x1476/0x2020
> [  582.109264]  ? find_get_context.isra.106+0x690/0x690
> [  582.109922]  ? __alloc_fd+0x1a3/0x4e0
> [  582.120002]  __do_sys_perf_event_open+0x222/0x1f40
> [  582.123049]  ? avc_has_perm_noaudit+0x340/0x340
> [  582.131226]  ? perf_event_set_output+0x5f0/0x5f0
> [  582.134395]  ? handle_mm_fault+0x103/0x350
> [  582.138102]  ? ksys_ioctl+0x61/0x90
> [  582.140234]  do_syscall_64+0x9a/0x2c0
> [  582.142674]  ? prepare_exit_to_usermode+0xbc/0x150
> [  582.146856]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [  582.151127] RIP: 0033:0x446159
> [  582.152816] Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00
> 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 08 fc ff c3 66 2e 0f 1f 84 00 00
> 00 00
> [  582.167257] RSP: 002b:7fffc2b023d8 EFLAGS: 0246 ORIG_RAX:
> 012a
> [  582.171375] RAX: ffda RBX: 004002c8 RCX: 
> 00446159
> [  582.175760] RDX:  RSI:  RDI: 
> 2180
> [  582.176487] RBP: 7fffc2b025b0 R08:  R09: 
> 
> [  582.177189] R10:  R11: 0246 R12: 
> 00406e40
> [  582.177898] R13: 00406ed0 R14:  R15: 
> 
> [  583.353322] Shutting down cpus with NMI
> [  583.354285] Kernel Offset: 0x1b40 from 0x8100
> (relocation range: 0x8000-0xbfff)
> [  583.356743] Rebooting in 86400 seconds..
> 
> 
> This bug could be easily reproduced by running the PoC(generated by
> 

Re: rcu: Kernel stack is corrupted in: perf_trace_rcu_dyntick

[Steven Rostedt]

On Sat, 29 Sep 2018 17:22:13 +0800
王晓东  wrote:

> Hi there,
> 
> We would like to report a kernel stack corrupted problem we identified
> in the perf_trace_rcu_dyntick function of tracing events subsystem.
> And the problem was founded by syzkaller.  We has tested the PoC on
> the lasted master branch of kernel(4.19.0-rc5+).
> 
> The crash log generated with KASAN enabled:
> 
> root@pc:~# ./perf_trace_rcu_dyntick
> [  582.069938] Kernel panic - not syncing: stack-protector: Kernel
> stack is corrupted in: perf_trace_rcu_dyntick+0x355/0x4f0
> [  582.069938]
> [  582.071341] CPU: 6 PID: 3417 Comm: perf_trace_rcu_ Not tainted 4.19.0-rc5+ 
> #1
> [  582.072134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [  582.073103] Call Trace:
> [  582.073364]  
> [  582.073614]  dump_stack+0x8c/0xce
> [  582.074039]  panic+0x1cb/0x3aa
> [  582.074427]  ? refcount_error_report+0x296/0x296
> [  582.075003]  ? timerqueue_del+0x71/0x130
> [  582.075553]  ? perf_trace_rcu_dyntick+0x355/0x4f0
> [  582.076063]  ? __stack_chk_fail+0x6/0x20
> [  582.076763]  ? perf_trace_rcu_dyntick+0x355/0x4f0
> [  582.077369]  __stack_chk_fail+0x1f/0x20
> [  582.077877]  perf_trace_rcu_dyntick+0x355/0x4f0
> [  582.078442]  ? rcu_gp_is_expedited+0xa0/0xa0
> [  582.078993]  ? rcu_gp_is_expedited+0xa0/0xa0
> [  582.079525]  ? check_preempt_curr+0x1c2/0x2a0
> [  582.080059]  ? sched_clock_cpu+0x18/0x160
> [  582.080551]  rcu_nmi_enter+0x1f0/0x2f0
> [  582.081036]  ? rcu_gp_is_expedited+0xa0/0xa0
> [  582.081507]  irq_enter+0xf/0x80
> [  582.081914]  smp_apic_timer_interrupt+0x1b/0x2d0
> [  582.082480]  apic_timer_interrupt+0xf/0x20
> [  582.082984]  
> [  582.083219] RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50
> [  582.087816] Code: e8 35 0b 20 00 48 8b 14 24 e9 fe fe ff ff 48 89
> df e8 24 0b 20 00 e9 d9 fe ff ff 4c 89 e7 e8 17 0b 20 00 e9 ab fe ff
> ff 90 90 <65> 48 8b 04 25 40 dd 01 00 65 8b 15 70 03 8f 63 81 e2 00 01
> 1f 00
> [  582.090289] RSP: 0018:8800651bf9e0 EFLAGS: 0206 ORIG_RAX:
> ff13
> [  582.091238] RAX:  RBX: 9eed12a5 RCX: 
> 9c6ca1b6
> [  582.092873] RDX: 0005 RSI: 9ee31d71 RDI: 
> 9eed12a4
> [  582.093934] RBP: 0078 R08: ed000d38dfb2 R09: 
> ed000d38dfb1
> [  582.095102] R10: 7350a3ba R11: 880069c6fd8f R12: 
> 8800651bfa6e
> [  582.096444] R13: 0001 R14: dc00 R15: 
> 006a
> [  582.097414]  ? kallsyms_expand_symbol.constprop.11+0x176/0x250
> [  582.098518]  kallsyms_expand_symbol.constprop.11+0x12e/0x250
> [  582.099707]  kallsyms_lookup_name+0xbe/0x1d0
> [  582.100369]  ? kallsyms_on_each_symbol+0x210/0x210
> [  582.101436]  ? snprintf+0xbd/0xf0
> [  582.102029]  ? vsprintf+0x30/0x30
> [  582.102805]  ? kasan_kmalloc+0xa9/0xd0
> [  582.103489]  ? alloc_trace_kprobe+0x6c0/0x930
> [  582.104073]  kprobe_on_func_entry+0x57/0xb0

I'm curious to what kretprobe was used.

-- Steve

> [  582.105421]  register_kretprobe+0x89/0xc10
> [  582.105930]  ? set_print_fmt+0x32/0xa0
> [  582.106376]  __register_trace_kprobe.part.10+0x14e/0x2e0
> [  582.106980]  create_local_trace_kprobe+0x29c/0x3f0
> [  582.107487]  perf_kprobe_init+0x15f/0x210
> [  582.107912]  perf_kprobe_event_init+0xc4/0x140
> [  582.108377]  perf_try_init_event+0xcb/0x290
> [  582.108817]  perf_event_alloc+0x1476/0x2020
> [  582.109264]  ? find_get_context.isra.106+0x690/0x690
> [  582.109922]  ? __alloc_fd+0x1a3/0x4e0
> [  582.120002]  __do_sys_perf_event_open+0x222/0x1f40
> [  582.123049]  ? avc_has_perm_noaudit+0x340/0x340
> [  582.131226]  ? perf_event_set_output+0x5f0/0x5f0
> [  582.134395]  ? handle_mm_fault+0x103/0x350
> [  582.138102]  ? ksys_ioctl+0x61/0x90
> [  582.140234]  do_syscall_64+0x9a/0x2c0
> [  582.142674]  ? prepare_exit_to_usermode+0xbc/0x150
> [  582.146856]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [  582.151127] RIP: 0033:0x446159
> [  582.152816] Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00
> 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 08 fc ff c3 66 2e 0f 1f 84 00 00
> 00 00
> [  582.167257] RSP: 002b:7fffc2b023d8 EFLAGS: 0246 ORIG_RAX:
> 012a
> [  582.171375] RAX: ffda RBX: 004002c8 RCX: 
> 00446159
> [  582.175760] RDX:  RSI:  RDI: 
> 2180
> [  582.176487] RBP: 7fffc2b025b0 R08:  R09: 
> 
> [  582.177189] R10:  R11: 0246 R12: 
> 00406e40
> [  582.177898] R13: 00406ed0 R14:  R15: 
> 
> [  583.353322] Shutting down cpus with NMI
> [  583.354285] Kernel Offset: 0x1b40 from 0x8100
> (relocation range: 0x8000-0xbfff)
> [  583.356743] Rebooting in 86400 seconds..
> 
> 
> This bug could be easily reproduced by running the PoC(generated by
> 

Re: [PATCH] ARM: dts: imx6sx-sdb: Fix enet phy regulator

[Fabio Estevam]

Hi Leonard,

On Tue, Oct 2, 2018 at 3:42 PM Leonard Crestez  wrote:

> @@ -371,10 +372,12 @@
> MX6SX_PAD_RGMII1_RD1__ENET1_RX_DATA_1   0x3081
> MX6SX_PAD_RGMII1_RD2__ENET1_RX_DATA_2   0x3081
> MX6SX_PAD_RGMII1_RD3__ENET1_RX_DATA_3   0x3081
> MX6SX_PAD_RGMII1_RX_CTL__ENET1_RX_EN0x3081
> MX6SX_PAD_ENET2_RX_CLK__ENET2_REF_CLK_25M 
>   0x91
> +   /* phy reset */
> +   MX6SX_PAD_ENET2_CRS__GPIO2_IO_7 
> 0x8000

We should avoid using 0x8000 as this relies on the bootloader
setting the IOMUX.

Please do like this insted:

MX6SX_PAD_ENET2_CRS__GPIO2_IO_7 0x10b0

Then you can add:

Reviewed-by: Fabio Estevam 

Re: [PATCH] ARM: dts: imx6sx-sdb: Fix enet phy regulator

[Fabio Estevam]

Hi Leonard,

On Tue, Oct 2, 2018 at 3:42 PM Leonard Crestez  wrote:

> @@ -371,10 +372,12 @@
> MX6SX_PAD_RGMII1_RD1__ENET1_RX_DATA_1   0x3081
> MX6SX_PAD_RGMII1_RD2__ENET1_RX_DATA_2   0x3081
> MX6SX_PAD_RGMII1_RD3__ENET1_RX_DATA_3   0x3081
> MX6SX_PAD_RGMII1_RX_CTL__ENET1_RX_EN0x3081
> MX6SX_PAD_ENET2_RX_CLK__ENET2_REF_CLK_25M 
>   0x91
> +   /* phy reset */
> +   MX6SX_PAD_ENET2_CRS__GPIO2_IO_7 
> 0x8000

We should avoid using 0x8000 as this relies on the bootloader
setting the IOMUX.

Please do like this insted:

MX6SX_PAD_ENET2_CRS__GPIO2_IO_7 0x10b0

Then you can add:

Reviewed-by: Fabio Estevam 

Re: [PATCH] fs/ext4: Convert fault handler to use vm_fault_t type

[Theodore Y. Ts'o]

On Mon, Sep 10, 2018 at 09:16:12PM +0530, Souptick Joarder wrote:
> Return type of ext4_page_mkwrite and ext4_filemap_fault are
> changed to use vm_fault_t type.
> 
> With this patch all the callers of block_page_mkwrite_return()
> are changed to handle vm_fault_t. So converting the return type
> of block_page_mkwrite_return() to vm_fault_t.
> 
> Signed-off-by: Souptick Joarder 

Thanks, applied.

- Ted

Re: [PATCH] fs/ext4: Convert fault handler to use vm_fault_t type

[Theodore Y. Ts'o]

On Mon, Sep 10, 2018 at 09:16:12PM +0530, Souptick Joarder wrote:
> Return type of ext4_page_mkwrite and ext4_filemap_fault are
> changed to use vm_fault_t type.
> 
> With this patch all the callers of block_page_mkwrite_return()
> are changed to handle vm_fault_t. So converting the return type
> of block_page_mkwrite_return() to vm_fault_t.
> 
> Signed-off-by: Souptick Joarder 

Thanks, applied.

- Ted

Re: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration

[Anshuman Khandual]

On 10/02/2018 06:09 PM, Michal Hocko wrote:
> On Tue 02-10-18 17:45:28, Anshuman Khandual wrote:
>> Architectures like arm64 have PUD level HugeTLB pages for certain configs
>> (1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be
>> enabled for migration. It can be achieved through checking for PUD_SHIFT
>> order based HugeTLB pages during migration.
> 
> Well a long term problem with hugepage_migration_supported is that it is
> used in two different context 1) to bail out from the migration early
> because the arch doesn't support migration at all and 2) to use movable
> zone for hugetlb pages allocation. I am especially concerned about the
> later because the mere support for migration is not really good enough.
> Are you really able to find a different giga page during the runtime to
> move an existing giga page out of the movable zone?

I pre-allocate them before trying to initiate the migration (soft offline
in my experiments). Hence it should come from the pre-allocated HugeTLB
pool instead from the buddy. I might be missing something here but do we
ever allocate HugeTLB on the go when trying to migrate ? IIUC it always
came from the pool (unless its something related to ovecommit/surplus).
Could you please kindly explain regarding how migration target HugeTLB
pages are allocated on the fly from movable zone.

But even if there are some chances of run time allocation failure from
movable zone (as in point 2) that should not block the very initiation
of migration itself. IIUC thats not the semantics for either THP or
normal pages. Why should it be different here. If the allocation fails
we should report and abort as always. Its the caller of migration taking
the chances. why should we prevent that.

> 
> So I guess we want to split this into two functions
> arch_hugepage_migration_supported and hugepage_movable. The later would

So the set difference between arch_hugepage_migration_supported and 
hugepage_movable still remains un-migratable ? Then what is the purpose
for arch_hugepage_migration_supported page size set in the first place.
Does it mean we allow the migration at the beginning and the abort later
when the page size does not fall within the subset for hugepage_movable.
Could you please kindly explain this in more detail.

> be a reasonably migrateable subset of the former. Without that this
> patch migth introduce subtle regressions when somebody relies on movable
> zone to be really movable.
PUD based HugeTLB pages were never migratable, then how can there be any
regression here ? At present we even support PGD based HugeTLB pages for
migration. Wondering how PUD based ones are going to be any different.

Re: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration

[Anshuman Khandual]

On 10/02/2018 06:09 PM, Michal Hocko wrote:
> On Tue 02-10-18 17:45:28, Anshuman Khandual wrote:
>> Architectures like arm64 have PUD level HugeTLB pages for certain configs
>> (1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be
>> enabled for migration. It can be achieved through checking for PUD_SHIFT
>> order based HugeTLB pages during migration.
> 
> Well a long term problem with hugepage_migration_supported is that it is
> used in two different context 1) to bail out from the migration early
> because the arch doesn't support migration at all and 2) to use movable
> zone for hugetlb pages allocation. I am especially concerned about the
> later because the mere support for migration is not really good enough.
> Are you really able to find a different giga page during the runtime to
> move an existing giga page out of the movable zone?

I pre-allocate them before trying to initiate the migration (soft offline
in my experiments). Hence it should come from the pre-allocated HugeTLB
pool instead from the buddy. I might be missing something here but do we
ever allocate HugeTLB on the go when trying to migrate ? IIUC it always
came from the pool (unless its something related to ovecommit/surplus).
Could you please kindly explain regarding how migration target HugeTLB
pages are allocated on the fly from movable zone.

But even if there are some chances of run time allocation failure from
movable zone (as in point 2) that should not block the very initiation
of migration itself. IIUC thats not the semantics for either THP or
normal pages. Why should it be different here. If the allocation fails
we should report and abort as always. Its the caller of migration taking
the chances. why should we prevent that.

> 
> So I guess we want to split this into two functions
> arch_hugepage_migration_supported and hugepage_movable. The later would

So the set difference between arch_hugepage_migration_supported and 
hugepage_movable still remains un-migratable ? Then what is the purpose
for arch_hugepage_migration_supported page size set in the first place.
Does it mean we allow the migration at the beginning and the abort later
when the page size does not fall within the subset for hugepage_movable.
Could you please kindly explain this in more detail.

> be a reasonably migrateable subset of the former. Without that this
> patch migth introduce subtle regressions when somebody relies on movable
> zone to be really movable.
PUD based HugeTLB pages were never migratable, then how can there be any
regression here ? At present we even support PGD based HugeTLB pages for
migration. Wondering how PUD based ones are going to be any different.

Re: [GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.20

[Masahiro Yamada]

Hi Arnd, Olof,


Please hold on.

I've received a little more patches.

I will queue up them, and send a respin later on.

Thanks.


On Wed, Oct 3, 2018 at 8:47 AM Masahiro Yamada
 wrote:
>
> Hi Arnd, Olof,
>
> Please pull UniPhier DT updates for the v4.20 MW.
>
> In this cycle, I queued up all arm/arm64 changes
> into a single branch to avoid build errors.
>
> Thanks!
>
>
>
>
>
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
>
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
> tags/uniphier-dt-v4.20
>
> for you to fetch changes up to 84a9c4d55907feece68c6012d3c030cf5c841ceb:
>
>   arm64: dts: uniphier: add SD controller nodes (2018-10-03 08:21:27 +0900)
>
> 
> UniPhier ARM SoC DT updates for v4.20
>
> - Add more clocks to NAND controller nodes
>
> - Add SPI controller nodes
>
> - Add SD controller nodes
>
> 
> Kunihiko Hayashi (3):
>   ARM: dts: uniphier: add SPI pin-mux node
>   ARM: dts: uniphier: add SPI node for UniPhier 32bit SoCs
>   arm64: dts: uniphier: add SPI node for LD20, LD11 and PXs3
>
> Masahiro Yamada (4):
>   ARM: uniphier: dts: add more clocks to Denali NAND controller node
>   arm64: uniphier: dts: add more clocks to Denali NAND controller node
>   ARM: dts: uniphier: add SD/eMMC controller nodes
>   arm64: dts: uniphier: add SD controller nodes
>
>  arch/arm/boot/dts/uniphier-ld4-ref.dts|  4 ++
>  arch/arm/boot/dts/uniphier-ld4.dtsi   | 48 ++-
>  arch/arm/boot/dts/uniphier-ld6b-ref.dts   |  4 ++
>  arch/arm/boot/dts/uniphier-pinctrl.dtsi   | 25 
>  arch/arm/boot/dts/uniphier-pro4-ace.dts   |  4 ++
>  arch/arm/boot/dts/uniphier-pro4-ref.dts   |  4 ++
>  arch/arm/boot/dts/uniphier-pro4-sanji.dts |  4 ++
>  arch/arm/boot/dts/uniphier-pro4.dtsi  | 62 +++-
>  arch/arm/boot/dts/uniphier-pro5.dtsi  | 59 ++-
>  arch/arm/boot/dts/uniphier-pxs2-gentil.dts|  4 ++
>  arch/arm/boot/dts/uniphier-pxs2-vodka.dts |  4 ++
>  arch/arm/boot/dts/uniphier-pxs2.dtsi  | 59 ++-
>  arch/arm/boot/dts/uniphier-sld8-ref.dts   |  4 ++
>  arch/arm/boot/dts/uniphier-sld8.dtsi  | 48 ++-
>  arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi  | 25 +++-
>  arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi  | 61 ++-
>  .../boot/dts/socionext/uniphier-pxs3-ref.dts  |  4 ++
>  arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi  | 43 +-
>  18 files changed, 458 insertions(+), 8 deletions(-)
>
>
> --
> Best Regards
> Masahiro Yamada



-- 
Best Regards
Masahiro Yamada

Re: [GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.20

[Masahiro Yamada]

Hi Arnd, Olof,


Please hold on.

I've received a little more patches.

I will queue up them, and send a respin later on.

Thanks.


On Wed, Oct 3, 2018 at 8:47 AM Masahiro Yamada
 wrote:
>
> Hi Arnd, Olof,
>
> Please pull UniPhier DT updates for the v4.20 MW.
>
> In this cycle, I queued up all arm/arm64 changes
> into a single branch to avoid build errors.
>
> Thanks!
>
>
>
>
>
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
>
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
> tags/uniphier-dt-v4.20
>
> for you to fetch changes up to 84a9c4d55907feece68c6012d3c030cf5c841ceb:
>
>   arm64: dts: uniphier: add SD controller nodes (2018-10-03 08:21:27 +0900)
>
> 
> UniPhier ARM SoC DT updates for v4.20
>
> - Add more clocks to NAND controller nodes
>
> - Add SPI controller nodes
>
> - Add SD controller nodes
>
> 
> Kunihiko Hayashi (3):
>   ARM: dts: uniphier: add SPI pin-mux node
>   ARM: dts: uniphier: add SPI node for UniPhier 32bit SoCs
>   arm64: dts: uniphier: add SPI node for LD20, LD11 and PXs3
>
> Masahiro Yamada (4):
>   ARM: uniphier: dts: add more clocks to Denali NAND controller node
>   arm64: uniphier: dts: add more clocks to Denali NAND controller node
>   ARM: dts: uniphier: add SD/eMMC controller nodes
>   arm64: dts: uniphier: add SD controller nodes
>
>  arch/arm/boot/dts/uniphier-ld4-ref.dts|  4 ++
>  arch/arm/boot/dts/uniphier-ld4.dtsi   | 48 ++-
>  arch/arm/boot/dts/uniphier-ld6b-ref.dts   |  4 ++
>  arch/arm/boot/dts/uniphier-pinctrl.dtsi   | 25 
>  arch/arm/boot/dts/uniphier-pro4-ace.dts   |  4 ++
>  arch/arm/boot/dts/uniphier-pro4-ref.dts   |  4 ++
>  arch/arm/boot/dts/uniphier-pro4-sanji.dts |  4 ++
>  arch/arm/boot/dts/uniphier-pro4.dtsi  | 62 +++-
>  arch/arm/boot/dts/uniphier-pro5.dtsi  | 59 ++-
>  arch/arm/boot/dts/uniphier-pxs2-gentil.dts|  4 ++
>  arch/arm/boot/dts/uniphier-pxs2-vodka.dts |  4 ++
>  arch/arm/boot/dts/uniphier-pxs2.dtsi  | 59 ++-
>  arch/arm/boot/dts/uniphier-sld8-ref.dts   |  4 ++
>  arch/arm/boot/dts/uniphier-sld8.dtsi  | 48 ++-
>  arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi  | 25 +++-
>  arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi  | 61 ++-
>  .../boot/dts/socionext/uniphier-pxs3-ref.dts  |  4 ++
>  arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi  | 43 +-
>  18 files changed, 458 insertions(+), 8 deletions(-)
>
>
> --
> Best Regards
> Masahiro Yamada



-- 
Best Regards
Masahiro Yamada

Urgent,

[Juliet Muhammad]

Hello 

   Please i still await your response regarding my previous email.

Urgent,

[Juliet Muhammad]

Hello 

   Please i still await your response regarding my previous email.

Re: [PATCH v3 3/3] iio: magnetometer: Add driver support for PNI RM3100

[Phil Reid]

G'day Song,

Noticed a one more thing below

On 2/10/2018 10:38 PM, Song Qiang wrote:

PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with a MagI2C
interface.

Following functions are available:
  - Single-shot measurement from
/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
  - Triggerd buffer measurement.
  - Both i2c and spi interface are supported.
  - Both interrupt and polling measurement is supported, depends on if
the 'interrupts' in DT is declared.

Signed-off-by: Song Qiang 





---
  MAINTAINERS|   7 +
  drivers/iio/magnetometer/Kconfig   |  29 ++
  drivers/iio/magnetometer/Makefile  |   4 +
  drivers/iio/magnetometer/rm3100-core.c | 539 +
  drivers/iio/magnetometer/rm3100-i2c.c  |  58 +++
  drivers/iio/magnetometer/rm3100-spi.c  |  64 +++
  drivers/iio/magnetometer/rm3100.h  |  17 +
  7 files changed, 718 insertions(+)
  create mode 100644 drivers/iio/magnetometer/rm3100-core.c
  create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
  create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
  create mode 100644 drivers/iio/magnetometer/rm3100.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 967ce8cdd1cc..14eeeb072403 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11393,6 +11393,13 @@ M: "Rafael J. Wysocki" 
  S:Maintained
  F:drivers/pnp/
  
+PNI RM3100 IIO DRIVER

+M: Song Qiang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/magnetometer/rm3100*
+F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
+
  POSIX CLOCKS and TIMERS
  M:Thomas Gleixner 
  L:linux-kernel@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index ed9d776d01af..8a63cbbca4b7 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
  - hmc5843_core (core functions)
  - hmc5843_spi (support for HMC5983)
  
+config SENSORS_RM3100

+   tristate
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+
+config SENSORS_RM3100_I2C
+   tristate "PNI RM3100 3-Axis Magnetometer (I2C)"
+   depends on I2C
+   select SENSORS_RM3100
+   select REGMAP_I2C
+   help
+ Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-i2c.
+
+config SENSORS_RM3100_SPI
+   tristate "PNI RM3100 3-Axis Magnetometer (SPI)"
+   depends on SPI_MASTER
+   select SENSORS_RM3100
+   select REGMAP_SPI
+   help
+ Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-spi.
+
  endmenu
diff --git a/drivers/iio/magnetometer/Makefile 
b/drivers/iio/magnetometer/Makefile
index 664b2f866472..ba1bc34b82fa 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -24,3 +24,7 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
  obj-$(CONFIG_SENSORS_HMC5843) += hmc5843_core.o
  obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
  obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
+
+obj-$(CONFIG_SENSORS_RM3100)   += rm3100-core.o
+obj-$(CONFIG_SENSORS_RM3100_I2C)   += rm3100-i2c.o
+obj-$(CONFIG_SENSORS_RM3100_SPI)   += rm3100-spi.o
diff --git a/drivers/iio/magnetometer/rm3100-core.c 
b/drivers/iio/magnetometer/rm3100-core.c
new file mode 100644
index ..cacdaee28ae3
--- /dev/null
+++ b/drivers/iio/magnetometer/rm3100-core.c
@@ -0,0 +1,539 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PNI RM3100 3-axis geomagnetic sensor driver core.
+ *
+ * Copyright (C) 2018 Song Qiang 
+ *
+ * User Manual available at
+ * 
+ *
+ * TODO: event generation, pm.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rm3100.h"
+
+/* Cycle Count Registers. */
+#define RM3100_REG_CC_X0x05
+#define RM3100_REG_CC_Y0x07
+#define RM3100_REG_CC_Z0x09
+
+/* Continuous Measurement Mode register. */
+#define RM3100_REG_CMM 0x01
+#defineRM3100_CMM_STARTBIT(0)
+#defineRM3100_CMM_XBIT(4)
+#defineRM3100_CMM_YBIT(5)
+#defineRM3100_CMM_ZBIT(6)
+
+/* TiMe Rate Configuration register. */
+#define RM3100_REG_TMRC0x0B
+#define RM3100_TMRC_OFFSET 0x92
+
+/* Result Status register. */
+#define RM3100_REG_STATUS

Re: [PATCH v3 3/3] iio: magnetometer: Add driver support for PNI RM3100

[Phil Reid]

G'day Song,

Noticed a one more thing below

On 2/10/2018 10:38 PM, Song Qiang wrote:

PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with a MagI2C
interface.

Following functions are available:
  - Single-shot measurement from
/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
  - Triggerd buffer measurement.
  - Both i2c and spi interface are supported.
  - Both interrupt and polling measurement is supported, depends on if
the 'interrupts' in DT is declared.

Signed-off-by: Song Qiang 





---
  MAINTAINERS|   7 +
  drivers/iio/magnetometer/Kconfig   |  29 ++
  drivers/iio/magnetometer/Makefile  |   4 +
  drivers/iio/magnetometer/rm3100-core.c | 539 +
  drivers/iio/magnetometer/rm3100-i2c.c  |  58 +++
  drivers/iio/magnetometer/rm3100-spi.c  |  64 +++
  drivers/iio/magnetometer/rm3100.h  |  17 +
  7 files changed, 718 insertions(+)
  create mode 100644 drivers/iio/magnetometer/rm3100-core.c
  create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
  create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
  create mode 100644 drivers/iio/magnetometer/rm3100.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 967ce8cdd1cc..14eeeb072403 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11393,6 +11393,13 @@ M: "Rafael J. Wysocki" 
  S:Maintained
  F:drivers/pnp/
  
+PNI RM3100 IIO DRIVER

+M: Song Qiang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/magnetometer/rm3100*
+F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
+
  POSIX CLOCKS and TIMERS
  M:Thomas Gleixner 
  L:linux-kernel@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index ed9d776d01af..8a63cbbca4b7 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
  - hmc5843_core (core functions)
  - hmc5843_spi (support for HMC5983)
  
+config SENSORS_RM3100

+   tristate
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+
+config SENSORS_RM3100_I2C
+   tristate "PNI RM3100 3-Axis Magnetometer (I2C)"
+   depends on I2C
+   select SENSORS_RM3100
+   select REGMAP_I2C
+   help
+ Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-i2c.
+
+config SENSORS_RM3100_SPI
+   tristate "PNI RM3100 3-Axis Magnetometer (SPI)"
+   depends on SPI_MASTER
+   select SENSORS_RM3100
+   select REGMAP_SPI
+   help
+ Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-spi.
+
  endmenu
diff --git a/drivers/iio/magnetometer/Makefile 
b/drivers/iio/magnetometer/Makefile
index 664b2f866472..ba1bc34b82fa 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -24,3 +24,7 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
  obj-$(CONFIG_SENSORS_HMC5843) += hmc5843_core.o
  obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
  obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
+
+obj-$(CONFIG_SENSORS_RM3100)   += rm3100-core.o
+obj-$(CONFIG_SENSORS_RM3100_I2C)   += rm3100-i2c.o
+obj-$(CONFIG_SENSORS_RM3100_SPI)   += rm3100-spi.o
diff --git a/drivers/iio/magnetometer/rm3100-core.c 
b/drivers/iio/magnetometer/rm3100-core.c
new file mode 100644
index ..cacdaee28ae3
--- /dev/null
+++ b/drivers/iio/magnetometer/rm3100-core.c
@@ -0,0 +1,539 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PNI RM3100 3-axis geomagnetic sensor driver core.
+ *
+ * Copyright (C) 2018 Song Qiang 
+ *
+ * User Manual available at
+ * 
+ *
+ * TODO: event generation, pm.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rm3100.h"
+
+/* Cycle Count Registers. */
+#define RM3100_REG_CC_X0x05
+#define RM3100_REG_CC_Y0x07
+#define RM3100_REG_CC_Z0x09
+
+/* Continuous Measurement Mode register. */
+#define RM3100_REG_CMM 0x01
+#defineRM3100_CMM_STARTBIT(0)
+#defineRM3100_CMM_XBIT(4)
+#defineRM3100_CMM_YBIT(5)
+#defineRM3100_CMM_ZBIT(6)
+
+/* TiMe Rate Configuration register. */
+#define RM3100_REG_TMRC0x0B
+#define RM3100_TMRC_OFFSET 0x92
+
+/* Result Status register. */
+#define RM3100_REG_STATUS

Urgent,

[Juliet Muhammad]

Hello 

   Please i still await your response regarding my previous email.

Urgent,

[Juliet Muhammad]

Hello 

   Please i still await your response regarding my previous email.

Re: [PATCH v3 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines

[Zong Li]

Palmer Dabbelt  於 2018年10月2日 週二 下午11:02寫道：
>
> On Tue, 02 Oct 2018 07:50:41 PDT (-0700), Christoph Hellwig wrote:
> >> The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other
> >> functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and
> >> udivmoddi4 for flexible extension in the future.
> >
> > Can you please mention which exact version of an external projected
> > you imported things from?  That will generally help if/when someone
> > has to dig into diverging versions.
> >
> >> +++ b/lib/udivmoddi4.c
> >> @@ -0,0 +1,310 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +
> >> +/*
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is 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.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program; if not, see the file COPYING, or write
> >> + * to the Free Software Foundation, Inc.
> >> + */
> >
> > The SPDX tag was supposed to replace this boiler plate.  On the other
> > hand I'm surpriced there is no Copyright statement here - the FSF is
> > usually very good about having them uptodate in every GNU project.
>
> I suggested he import the gcc-4.2.1 version, which has a big copyright notice
>
> /* More subroutines needed by GCC output code on some machines.  */
> /* Compile this one with gcc.  */
> /* Copyright (C) 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
>2000, 2001, 2002, 2003, 2004, 2005  Free Software Foundation, Inc.
>
> This file is part of GCC.
>
> GCC is free software; you can redistribute it and/or modify it under
> the terms of the GNU General Public License as published by the Free
> Software Foundation; either version 2, or (at your option) any later
> version.
>
> In addition to the permissions in the GNU General Public License, the
> Free Software Foundation gives you unlimited permission to link the
> compiled version of this file into combinations with other programs,
> and to distribute those combinations without any restriction coming
> from the use of this file.  (The General Public License restrictions
> do apply in other respects; for example, they cover modification of
> the file, and distribution when not linked into a combine
> executable.)
>
> GCC 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.
>
> You should have received a copy of the GNU General Public License
> along with GCC; see the file COPYING.  If not, write to the Free
> Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301, USA.  */
>
> so it looks like something went wrong here.  Zong: did you go back and
> re-construct this function from the GPLv2 source?

Yes, I re-construct this function from GCC 4.2.1. The copyright part,
I referred to the other GCC routine copies in kernel such as ucmpdi2,
muldi3, ashldi3 and so on, I found they removed the 'GCC' string, so I
use the same copyright from these files.
I will re-write the copyright part and submit the next version. Thanks
to all for help.

Re: [PATCH v3 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines

[Zong Li]

Palmer Dabbelt  於 2018年10月2日 週二 下午11:02寫道：
>
> On Tue, 02 Oct 2018 07:50:41 PDT (-0700), Christoph Hellwig wrote:
> >> The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other
> >> functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and
> >> udivmoddi4 for flexible extension in the future.
> >
> > Can you please mention which exact version of an external projected
> > you imported things from?  That will generally help if/when someone
> > has to dig into diverging versions.
> >
> >> +++ b/lib/udivmoddi4.c
> >> @@ -0,0 +1,310 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +
> >> +/*
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is 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.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program; if not, see the file COPYING, or write
> >> + * to the Free Software Foundation, Inc.
> >> + */
> >
> > The SPDX tag was supposed to replace this boiler plate.  On the other
> > hand I'm surpriced there is no Copyright statement here - the FSF is
> > usually very good about having them uptodate in every GNU project.
>
> I suggested he import the gcc-4.2.1 version, which has a big copyright notice
>
> /* More subroutines needed by GCC output code on some machines.  */
> /* Compile this one with gcc.  */
> /* Copyright (C) 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
>2000, 2001, 2002, 2003, 2004, 2005  Free Software Foundation, Inc.
>
> This file is part of GCC.
>
> GCC is free software; you can redistribute it and/or modify it under
> the terms of the GNU General Public License as published by the Free
> Software Foundation; either version 2, or (at your option) any later
> version.
>
> In addition to the permissions in the GNU General Public License, the
> Free Software Foundation gives you unlimited permission to link the
> compiled version of this file into combinations with other programs,
> and to distribute those combinations without any restriction coming
> from the use of this file.  (The General Public License restrictions
> do apply in other respects; for example, they cover modification of
> the file, and distribution when not linked into a combine
> executable.)
>
> GCC 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.
>
> You should have received a copy of the GNU General Public License
> along with GCC; see the file COPYING.  If not, write to the Free
> Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301, USA.  */
>
> so it looks like something went wrong here.  Zong: did you go back and
> re-construct this function from the GPLv2 source?

Yes, I re-construct this function from GCC 4.2.1. The copyright part,
I referred to the other GCC routine copies in kernel such as ucmpdi2,
muldi3, ashldi3 and so on, I found they removed the 'GCC' string, so I
use the same copyright from these files.
I will re-write the copyright part and submit the next version. Thanks
to all for help.

[PATCH v6 3/3] Documentation/kernel-parameters.txt: Document rand_mem_physical_padding=

[Masayoshi Mizuma]

This kernel parameter allows the modification of the padding used
for the physical memory mapping section when KASLR memory is enabled.

For memory hotplug capable systems, the default padding size,
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, may not be enough.

The option is useful to adjust the padding size.

Signed-off-by: Masayoshi Mizuma 
---
 .../admin-guide/kernel-parameters.txt | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 92eb1f4..f0930e3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3529,6 +3529,25 @@
fully seed the kernel's CRNG. Default is controlled
by CONFIG_RANDOM_TRUST_CPU.
 
+   rand_mem_physical_padding=
+   [KNL] Define the padding size in terabytes
+   used for the physical memory mapping section
+   when KASLR is enabled.
+   If the padding size is not enough, you can see
+   'Set rand_mem_physical_padding=XX ...' in system
+   boot message, so set the parameter as the message
+   suggests.
+
+   This parameter is useful for memory hot-add capable
+   systems. Such systems may have more space than
+   actual memory size to hot-add memory. If the
+   padding size is not enough and memory is hot-added,
+   the hot-adding will fail because it destroys the
+   system memory map. So, the padding size needs to be
+   adjusted in such a system.
+   The default value is the value of
+   CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING.
+
ras=option[,option,...] [KNL] RAS-specific options
 
cec_disable [X86]
-- 
2.18.0

[PATCH v6 3/3] Documentation/kernel-parameters.txt: Document rand_mem_physical_padding=

[Masayoshi Mizuma]

This kernel parameter allows the modification of the padding used
for the physical memory mapping section when KASLR memory is enabled.

For memory hotplug capable systems, the default padding size,
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, may not be enough.

The option is useful to adjust the padding size.

Signed-off-by: Masayoshi Mizuma 
---
 .../admin-guide/kernel-parameters.txt | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 92eb1f4..f0930e3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3529,6 +3529,25 @@
fully seed the kernel's CRNG. Default is controlled
by CONFIG_RANDOM_TRUST_CPU.
 
+   rand_mem_physical_padding=
+   [KNL] Define the padding size in terabytes
+   used for the physical memory mapping section
+   when KASLR is enabled.
+   If the padding size is not enough, you can see
+   'Set rand_mem_physical_padding=XX ...' in system
+   boot message, so set the parameter as the message
+   suggests.
+
+   This parameter is useful for memory hot-add capable
+   systems. Such systems may have more space than
+   actual memory size to hot-add memory. If the
+   padding size is not enough and memory is hot-added,
+   the hot-adding will fail because it destroys the
+   system memory map. So, the padding size needs to be
+   adjusted in such a system.
+   The default value is the value of
+   CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING.
+
ras=option[,option,...] [KNL] RAS-specific options
 
cec_disable [X86]
-- 
2.18.0

[PATCH v6 1/3] x86/mm: Add a kernel parameter to change the padding used for the physical memory mapping

[Masayoshi Mizuma]

If each node of physical memory layout has huge space for hotplug,
the padding used for the physical memory mapping section is not enough.
For exapmle of the layout:

  SRAT: Node 6 PXM 4 [mem 0x1000-0x13ff] hotplug
  SRAT: Node 7 PXM 5 [mem 0x1400-0x17ff] hotplug
  SRAT: Node 2 PXM 6 [mem 0x1800-0x1bff] hotplug
  SRAT: Node 3 PXM 7 [mem 0x1c00-0x1fff] hotplug

We can increase the padding via CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
however, the needed padding size depends on the system environment.
The kernel option is better than changing the config.

Signed-off-by: Masayoshi Mizuma 
Reviewed-by: Baoquan He 
---
 arch/x86/include/asm/setup.h |  9 +
 arch/x86/mm/kaslr.c  | 22 +-
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ae13bc9..1765a15 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -80,6 +80,15 @@ static inline unsigned long kaslr_offset(void)
return (unsigned long)&_text - __START_KERNEL;
 }
 
+#ifdef CONFIG_RANDOMIZE_MEMORY
+extern inline int __init get_rand_mem_physical_padding(void);
+#else
+static inline int __init get_rand_mem_physical_padding(void)
+{
+   return 0;
+}
+#endif
+
 /*
  * Do NOT EVER look at the BIOS memory size location.
  * It does not work on many machines.
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 61db77b..eb47f05 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -40,6 +40,7 @@
  */
 static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
 
+static int rand_mem_physical_padding __initdata = 
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
 /*
  * Memory regions randomized by KASLR (except modules that use a separate logic
  * earlier during boot). The list is ordered based on virtual addresses. This
@@ -69,6 +70,25 @@ static inline bool kaslr_memory_enabled(void)
return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
 }
 
+inline int __init get_rand_mem_physical_padding(void)
+{
+   return rand_mem_physical_padding;
+}
+
+static int __init rand_mem_physical_padding_setup(char *str)
+{
+   int max_padding = (1 << (MAX_PHYSMEM_BITS - TB_SHIFT)) - 1;
+
+   get_option(, _mem_physical_padding);
+   if (rand_mem_physical_padding < 0)
+   rand_mem_physical_padding = 0;
+   else if (rand_mem_physical_padding > max_padding)
+   rand_mem_physical_padding = max_padding;
+
+   return 0;
+}
+early_param("rand_mem_physical_padding", rand_mem_physical_padding_setup);
+
 /* Initialize base and padding for each memory region randomized with KASLR */
 void __init kernel_randomize_memory(void)
 {
@@ -102,7 +122,7 @@ void __init kernel_randomize_memory(void)
 */
BUG_ON(kaslr_regions[0].base != _offset_base);
memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
-   CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
+   get_rand_mem_physical_padding();
 
/* Adapt phyiscal memory region size based on available memory */
if (memory_tb < kaslr_regions[0].size_tb)
-- 
2.18.0

[PATCH v6 1/3] x86/mm: Add a kernel parameter to change the padding used for the physical memory mapping

[Masayoshi Mizuma]

If each node of physical memory layout has huge space for hotplug,
the padding used for the physical memory mapping section is not enough.
For exapmle of the layout:

  SRAT: Node 6 PXM 4 [mem 0x1000-0x13ff] hotplug
  SRAT: Node 7 PXM 5 [mem 0x1400-0x17ff] hotplug
  SRAT: Node 2 PXM 6 [mem 0x1800-0x1bff] hotplug
  SRAT: Node 3 PXM 7 [mem 0x1c00-0x1fff] hotplug

We can increase the padding via CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
however, the needed padding size depends on the system environment.
The kernel option is better than changing the config.

Signed-off-by: Masayoshi Mizuma 
Reviewed-by: Baoquan He 
---
 arch/x86/include/asm/setup.h |  9 +
 arch/x86/mm/kaslr.c  | 22 +-
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ae13bc9..1765a15 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -80,6 +80,15 @@ static inline unsigned long kaslr_offset(void)
return (unsigned long)&_text - __START_KERNEL;
 }
 
+#ifdef CONFIG_RANDOMIZE_MEMORY
+extern inline int __init get_rand_mem_physical_padding(void);
+#else
+static inline int __init get_rand_mem_physical_padding(void)
+{
+   return 0;
+}
+#endif
+
 /*
  * Do NOT EVER look at the BIOS memory size location.
  * It does not work on many machines.
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 61db77b..eb47f05 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -40,6 +40,7 @@
  */
 static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
 
+static int rand_mem_physical_padding __initdata = 
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
 /*
  * Memory regions randomized by KASLR (except modules that use a separate logic
  * earlier during boot). The list is ordered based on virtual addresses. This
@@ -69,6 +70,25 @@ static inline bool kaslr_memory_enabled(void)
return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
 }
 
+inline int __init get_rand_mem_physical_padding(void)
+{
+   return rand_mem_physical_padding;
+}
+
+static int __init rand_mem_physical_padding_setup(char *str)
+{
+   int max_padding = (1 << (MAX_PHYSMEM_BITS - TB_SHIFT)) - 1;
+
+   get_option(, _mem_physical_padding);
+   if (rand_mem_physical_padding < 0)
+   rand_mem_physical_padding = 0;
+   else if (rand_mem_physical_padding > max_padding)
+   rand_mem_physical_padding = max_padding;
+
+   return 0;
+}
+early_param("rand_mem_physical_padding", rand_mem_physical_padding_setup);
+
 /* Initialize base and padding for each memory region randomized with KASLR */
 void __init kernel_randomize_memory(void)
 {
@@ -102,7 +122,7 @@ void __init kernel_randomize_memory(void)
 */
BUG_ON(kaslr_regions[0].base != _offset_base);
memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
-   CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
+   get_rand_mem_physical_padding();
 
/* Adapt phyiscal memory region size based on available memory */
if (memory_tb < kaslr_regions[0].size_tb)
-- 
2.18.0

[PATCH v6 0/3] Add a kernel parameter to change the padding size for KASLR

[Masayoshi Mizuma]

This patch series are adding an kernel parameter to change
the padding size used for KASLR. It is useful for memory hotplug
capable system. User can adjust the padding size to use it.

It is better if the padding size is calculated automatically,
however, ACPI SRAT is not available at the KASLR initialization
time. So, I add a message for user to tell the suitable padding
size. User can set it on next reboot.

This patch series don't change the current default padding size.

Change log from v5:
 - Fix build error if CONFIG_RANDOMIZE_MEMORY is not defined.

Change log from v4:
 - Fix the padding size check (2nd patch)
 - Add explanation for the parameter in the document. (3rd patch)

Change log from v3:
 - Add a warning message if the padding size for KASLR is not enough.
   And it says the suitable padding size to user.

Change log from v2:
 - Simplify the description. As Baoquan said, this is similar SGI UV issue,
   but a little different. Remove SGI UV description.

Masayoshi Mizuma (3):
  x86/mm: Add a kernel parameter to change the padding used for the
physical memory mapping
  ACPI/NUMA: Add warning message if the padding size for KASLR is not
enough
  Documentation/kernel-parameters.txt: Document
rand_mem_physical_padding=

 .../admin-guide/kernel-parameters.txt | 19 
 arch/x86/include/asm/setup.h  |  9 
 arch/x86/mm/kaslr.c   | 22 ++-
 drivers/acpi/numa.c   | 16 ++
 4 files changed, 65 insertions(+), 1 deletion(-)

-- 
2.18.0

[PATCH v6 2/3] ACPI/NUMA: Add warning message if the padding size for KASLR is not enough

[Masayoshi Mizuma]

Add warning message if the padding size for KASLR,
rand_mem_physical_padding, is not enough. The message also
says the suitable padding size.

Signed-off-by: Masayoshi Mizuma 
---
 drivers/acpi/numa.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 8516760..420ed2c 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static nodemask_t nodes_found_map = NODE_MASK_NONE;
 
@@ -435,6 +436,7 @@ acpi_table_parse_srat(enum acpi_srat_type id,
 int __init acpi_numa_init(void)
 {
int cnt = 0;
+   u64 max_possible_phys, max_actual_phys, threshold;
 
if (acpi_disabled)
return -EINVAL;
@@ -463,6 +465,20 @@ int __init acpi_numa_init(void)
 
cnt = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
acpi_parse_memory_affinity, 0);
+
+   /* check the padding size for KASLR is enough. */
+   if (parsed_numa_memblks && kaslr_enabled()) {
+   max_actual_phys = roundup(PFN_PHYS(max_pfn),
+   1ULL << 40);
+   max_possible_phys = roundup(PFN_PHYS(max_possible_pfn),
+   1ULL << 40);
+   threshold = max_actual_phys +
+   ((u64)get_rand_mem_physical_padding() << 40);
+
+   if (max_possible_phys > threshold)
+   pr_warn("Set 'rand_mem_physical_padding=%llu' 
to avoid memory hotadd failure.\n",
+ (max_possible_phys - max_actual_phys) >> 40);
+   }
}
 
/* SLIT: System Locality Information Table */
-- 
2.18.0

[PATCH v6 0/3] Add a kernel parameter to change the padding size for KASLR

[Masayoshi Mizuma]

This patch series are adding an kernel parameter to change
the padding size used for KASLR. It is useful for memory hotplug
capable system. User can adjust the padding size to use it.

It is better if the padding size is calculated automatically,
however, ACPI SRAT is not available at the KASLR initialization
time. So, I add a message for user to tell the suitable padding
size. User can set it on next reboot.

This patch series don't change the current default padding size.

Change log from v5:
 - Fix build error if CONFIG_RANDOMIZE_MEMORY is not defined.

Change log from v4:
 - Fix the padding size check (2nd patch)
 - Add explanation for the parameter in the document. (3rd patch)

Change log from v3:
 - Add a warning message if the padding size for KASLR is not enough.
   And it says the suitable padding size to user.

Change log from v2:
 - Simplify the description. As Baoquan said, this is similar SGI UV issue,
   but a little different. Remove SGI UV description.

Masayoshi Mizuma (3):
  x86/mm: Add a kernel parameter to change the padding used for the
physical memory mapping
  ACPI/NUMA: Add warning message if the padding size for KASLR is not
enough
  Documentation/kernel-parameters.txt: Document
rand_mem_physical_padding=

 .../admin-guide/kernel-parameters.txt | 19 
 arch/x86/include/asm/setup.h  |  9 
 arch/x86/mm/kaslr.c   | 22 ++-
 drivers/acpi/numa.c   | 16 ++
 4 files changed, 65 insertions(+), 1 deletion(-)

-- 
2.18.0

[PATCH v6 2/3] ACPI/NUMA: Add warning message if the padding size for KASLR is not enough

[Masayoshi Mizuma]

Add warning message if the padding size for KASLR,
rand_mem_physical_padding, is not enough. The message also
says the suitable padding size.

Signed-off-by: Masayoshi Mizuma 
---
 drivers/acpi/numa.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 8516760..420ed2c 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static nodemask_t nodes_found_map = NODE_MASK_NONE;
 
@@ -435,6 +436,7 @@ acpi_table_parse_srat(enum acpi_srat_type id,
 int __init acpi_numa_init(void)
 {
int cnt = 0;
+   u64 max_possible_phys, max_actual_phys, threshold;
 
if (acpi_disabled)
return -EINVAL;
@@ -463,6 +465,20 @@ int __init acpi_numa_init(void)
 
cnt = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
acpi_parse_memory_affinity, 0);
+
+   /* check the padding size for KASLR is enough. */
+   if (parsed_numa_memblks && kaslr_enabled()) {
+   max_actual_phys = roundup(PFN_PHYS(max_pfn),
+   1ULL << 40);
+   max_possible_phys = roundup(PFN_PHYS(max_possible_pfn),
+   1ULL << 40);
+   threshold = max_actual_phys +
+   ((u64)get_rand_mem_physical_padding() << 40);
+
+   if (max_possible_phys > threshold)
+   pr_warn("Set 'rand_mem_physical_padding=%llu' 
to avoid memory hotadd failure.\n",
+ (max_possible_phys - max_actual_phys) >> 40);
+   }
}
 
/* SLIT: System Locality Information Table */
-- 
2.18.0

Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"

[Steven Rostedt]

On Tue, 2 Oct 2018 17:15:17 -0700
Daniel Wang  wrote:

> On Tue, Oct 2, 2018 at 1:42 AM Petr Mladek  wrote:
> >
> > Well, I still wonder why it helped and why you do not see it with 4.4.
> > I have a feeling that the console owner switch helped only by chance.
> > In fact, you might be affected by a race in
> > printk_safe_flush_on_panic() that was fixed by the commit:
> >
> > 554755be08fba31c7 printk: drop in_nmi check from 
> > printk_safe_flush_on_panic()
> >
> > The above one commit might be enough. Well, there was one more
> > NMI-related race that was fixed by:
> >
> > ba552399954dde1b printk: Split the code for storing a message into the log 
> > buffer
> > a338f84dc196f44b printk: Create helper function to queue deferred console 
> > handling
> > 03fc7f9c99c1e7ae printk/nmi: Prevent deadlock when accessing the main log 
> > buffer in NMI  
> 
> All of these commits already exist in 4.14 stable, since 4.14.68. The deadlock
> still exists even when built from 4.14.73 (latest tag) though. And 
> cherrypicking
> dbdda842fe96 fixes it.
> 

I don't see the big deal of backporting this. The biggest complaints
about backports are from fixes that were added to late -rc releases
where the fixes didn't get much testing. This commit was added in 4.16,
and hasn't had any issues due to the design. Although a fix has been
added:

c14376de3a1 ("printk: Wake klogd when passing console_lock owner")

Also from 4.16, but nothing else according to searching for "Fixes"
tags.

-- Steve

Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"

[Steven Rostedt]

On Tue, 2 Oct 2018 17:15:17 -0700
Daniel Wang  wrote:

> On Tue, Oct 2, 2018 at 1:42 AM Petr Mladek  wrote:
> >
> > Well, I still wonder why it helped and why you do not see it with 4.4.
> > I have a feeling that the console owner switch helped only by chance.
> > In fact, you might be affected by a race in
> > printk_safe_flush_on_panic() that was fixed by the commit:
> >
> > 554755be08fba31c7 printk: drop in_nmi check from 
> > printk_safe_flush_on_panic()
> >
> > The above one commit might be enough. Well, there was one more
> > NMI-related race that was fixed by:
> >
> > ba552399954dde1b printk: Split the code for storing a message into the log 
> > buffer
> > a338f84dc196f44b printk: Create helper function to queue deferred console 
> > handling
> > 03fc7f9c99c1e7ae printk/nmi: Prevent deadlock when accessing the main log 
> > buffer in NMI  
> 
> All of these commits already exist in 4.14 stable, since 4.14.68. The deadlock
> still exists even when built from 4.14.73 (latest tag) though. And 
> cherrypicking
> dbdda842fe96 fixes it.
> 

I don't see the big deal of backporting this. The biggest complaints
about backports are from fixes that were added to late -rc releases
where the fixes didn't get much testing. This commit was added in 4.16,
and hasn't had any issues due to the design. Although a fix has been
added:

c14376de3a1 ("printk: Wake klogd when passing console_lock owner")

Also from 4.16, but nothing else according to searching for "Fixes"
tags.

-- Steve

Re: [PATCH v14 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

Hi Jacek,

On 3 October 2018 at 04:25, Jacek Anaszewski  wrote:
> Hi Baolin,
>
> Thank you for the v14. We'll probably need v15, though :-)
>
> I added the comments in the code below.
>
> On 10/02/2018 05:43 PM, Baolin Wang wrote:
>> This patch adds one new led trigger that LED device can configure
>> the software or hardware pattern and trigger it.
>>
>> Consumers can write 'pattern' file to enable the software pattern
>> which alters the brightness for the specified duration with one
>> software timer.
>>
>> Moreover consumers can write 'hw_pattern' file to enable the hardware
>> pattern for some LED controllers which can autonomously control
>> brightness over time, according to some preprogrammed hardware
>> patterns.
>>
>> Signed-off-by: Raphael Teysseyre 
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes from v13:
>>  - Add duration validation for gradual dimming.
>>  - Coding style optimization.
>>
>> Changes from v12:
>>  - Add gradual dimming support for software pattern.
>>
>> Changes from v11:
>>  - Change -1 means repeat indefinitely.
>>
>> Changes from v10:
>>  - Change 'int' to 'u32' for delta_t field.
>>
>> Changes from v9:
>>  - None.
>>
>> Changes from v8:
>>  - None.
>>
>> Changes from v7:
>>  - Move the SC27XX hardware patterns description into its own ABI file.
>>
>> Changes from v6:
>>  - Improve commit message.
>>  - Optimize the description of the hw_pattern file.
>>  - Simplify some logics.
>>
>> Changes from v5:
>>  - Add one 'hw_pattern' file for hardware patterns.
>>
>> Changes from v4:
>>  - Change the repeat file to return the originally written number.
>>  - Improve comments.
>>  - Fix some build warnings.
>>
>> Changes from v3:
>>  - Reset pattern number to 0 if user provides incorrect pattern string.
>>  - Support one pattern.
>>
>> Changes from v2:
>>  - Remove hardware_pattern boolen.
>>  - Chnage the pattern string format.
>>
>> Changes from v1:
>>  - Use ATTRIBUTE_GROUPS() to define attributes.
>>  - Introduce hardware_pattern flag to determine if software pattern
>>  or hardware pattern.
>>  - Re-implement pattern_trig_store_pattern() function.
>>  - Remove pattern_get() interface.
>>  - Improve comments.
>>  - Other small optimization.
>> ---
>>  .../ABI/testing/sysfs-class-led-trigger-pattern|  76 
>>  drivers/leds/trigger/Kconfig   |   7 +
>>  drivers/leds/trigger/Makefile  |   1 +
>>  drivers/leds/trigger/ledtrig-pattern.c | 431 
>> +
>>  include/linux/leds.h   |  15 +
>>  5 files changed, 530 insertions(+)
>>  create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>>  create mode 100644 drivers/leds/trigger/ledtrig-pattern.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern 
>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> new file mode 100644
>> index 000..22d7af7
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> @@ -0,0 +1,76 @@
>> +What:/sys/class/leds//pattern
>> +Date:September 2018
>> +KernelVersion:   4.20
>> +Description:
>> + Specify a software pattern for the LED, that supports altering
>> + the brightness for the specified duration with one software
>> + timer. It can do gradual dimming and constant brightness.
>> +
>> + The pattern is given by a series of tuples, of brightness and
>> + duration (ms). The LED is expected to traverse the series and
>> + each brightness value for the specified duration. Duration of
>> + 0 means brightness should immediately change to new value.
>> +
>> + 1. When doing gradual dimming, the led brightness will be 
>> updated
>> + every 50 milliseconds, so the duration of each step should not
>> + less than 50 milliseconds.
>
> I'd like to avoid this constraint. Lowest supported delta_t should be 1.
>
> We should only prevent entering dimming mode if current delta_t
> is lower than UPDATE_INTERVAL.

I do not think so. If the pattern format is used for dimming and the
delta_t is lower than UPDATE_INTERVAL, we should return errors. Since
in this case, we can not change to constant mode.

Like you mentioned:

echo "10 49 20 49" > pattern

We can not enter dimming, meanwhile the pattern format is not used for
constant brightness, so should return errors for the invalid pattern
values.

> I also propose to make the dimming interval configurable via sysfs
> dimming_interval file.

So the dimming_interva range is [1, 50] milliseconds?

I am fine with this. Pavel, do you also agree with adding one new file
to set the dimming interval or keep it as simple now?

>
>> The gradual dimming format of the
>> + software pattern values should be:
>> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3
>> + duration_3 ...". For 

Re: [PATCH v14 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

Hi Jacek,

On 3 October 2018 at 04:25, Jacek Anaszewski  wrote:
> Hi Baolin,
>
> Thank you for the v14. We'll probably need v15, though :-)
>
> I added the comments in the code below.
>
> On 10/02/2018 05:43 PM, Baolin Wang wrote:
>> This patch adds one new led trigger that LED device can configure
>> the software or hardware pattern and trigger it.
>>
>> Consumers can write 'pattern' file to enable the software pattern
>> which alters the brightness for the specified duration with one
>> software timer.
>>
>> Moreover consumers can write 'hw_pattern' file to enable the hardware
>> pattern for some LED controllers which can autonomously control
>> brightness over time, according to some preprogrammed hardware
>> patterns.
>>
>> Signed-off-by: Raphael Teysseyre 
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes from v13:
>>  - Add duration validation for gradual dimming.
>>  - Coding style optimization.
>>
>> Changes from v12:
>>  - Add gradual dimming support for software pattern.
>>
>> Changes from v11:
>>  - Change -1 means repeat indefinitely.
>>
>> Changes from v10:
>>  - Change 'int' to 'u32' for delta_t field.
>>
>> Changes from v9:
>>  - None.
>>
>> Changes from v8:
>>  - None.
>>
>> Changes from v7:
>>  - Move the SC27XX hardware patterns description into its own ABI file.
>>
>> Changes from v6:
>>  - Improve commit message.
>>  - Optimize the description of the hw_pattern file.
>>  - Simplify some logics.
>>
>> Changes from v5:
>>  - Add one 'hw_pattern' file for hardware patterns.
>>
>> Changes from v4:
>>  - Change the repeat file to return the originally written number.
>>  - Improve comments.
>>  - Fix some build warnings.
>>
>> Changes from v3:
>>  - Reset pattern number to 0 if user provides incorrect pattern string.
>>  - Support one pattern.
>>
>> Changes from v2:
>>  - Remove hardware_pattern boolen.
>>  - Chnage the pattern string format.
>>
>> Changes from v1:
>>  - Use ATTRIBUTE_GROUPS() to define attributes.
>>  - Introduce hardware_pattern flag to determine if software pattern
>>  or hardware pattern.
>>  - Re-implement pattern_trig_store_pattern() function.
>>  - Remove pattern_get() interface.
>>  - Improve comments.
>>  - Other small optimization.
>> ---
>>  .../ABI/testing/sysfs-class-led-trigger-pattern|  76 
>>  drivers/leds/trigger/Kconfig   |   7 +
>>  drivers/leds/trigger/Makefile  |   1 +
>>  drivers/leds/trigger/ledtrig-pattern.c | 431 
>> +
>>  include/linux/leds.h   |  15 +
>>  5 files changed, 530 insertions(+)
>>  create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>>  create mode 100644 drivers/leds/trigger/ledtrig-pattern.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern 
>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> new file mode 100644
>> index 000..22d7af7
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> @@ -0,0 +1,76 @@
>> +What:/sys/class/leds//pattern
>> +Date:September 2018
>> +KernelVersion:   4.20
>> +Description:
>> + Specify a software pattern for the LED, that supports altering
>> + the brightness for the specified duration with one software
>> + timer. It can do gradual dimming and constant brightness.
>> +
>> + The pattern is given by a series of tuples, of brightness and
>> + duration (ms). The LED is expected to traverse the series and
>> + each brightness value for the specified duration. Duration of
>> + 0 means brightness should immediately change to new value.
>> +
>> + 1. When doing gradual dimming, the led brightness will be 
>> updated
>> + every 50 milliseconds, so the duration of each step should not
>> + less than 50 milliseconds.
>
> I'd like to avoid this constraint. Lowest supported delta_t should be 1.
>
> We should only prevent entering dimming mode if current delta_t
> is lower than UPDATE_INTERVAL.

I do not think so. If the pattern format is used for dimming and the
delta_t is lower than UPDATE_INTERVAL, we should return errors. Since
in this case, we can not change to constant mode.

Like you mentioned:

echo "10 49 20 49" > pattern

We can not enter dimming, meanwhile the pattern format is not used for
constant brightness, so should return errors for the invalid pattern
values.

> I also propose to make the dimming interval configurable via sysfs
> dimming_interval file.

So the dimming_interva range is [1, 50] milliseconds?

I am fine with this. Pavel, do you also agree with adding one new file
to set the dimming interval or keep it as simple now?

>
>> The gradual dimming format of the
>> + software pattern values should be:
>> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3
>> + duration_3 ...". For