Re: [RfC PATCH] Add udmabuf misc device

[Oleksandr Andrushchenko]

On 04/10/2018 08:26 PM, Dongwon Kim wrote:

On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:

On 04/06/2018 09:57 PM, Dongwon Kim wrote:

On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:

On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:

   Hi,


I fail to see any common ground for xen-zcopy and udmabuf ...

Does the above mean you can assume that xen-zcopy and udmabuf
can co-exist as two different solutions?

Well, udmabuf route isn't fully clear yet, but yes.

See also gvt (intel vgpu), where the hypervisor interface is abstracted
away into a separate kernel modules even though most of the actual vgpu
emulation code is common.

Thank you for your input, I'm just trying to figure out
which of the three z-copy solutions intersect and how much

And what about hyper-dmabuf?

xen z-copy solution is pretty similar fundamentally to hyper_dmabuf
in terms of these core sharing feature:

1. the sharing process - import prime/dmabuf from the producer -> extract
underlying pages and get those shared -> return references for shared pages

Another thing is danvet was kind of against to the idea of importing existing
dmabuf/prime buffer and forward it to the other domain due to synchronization
issues. He proposed to make hyper_dmabuf only work as an exporter so that it
can have a full control over the buffer. I think we need to talk about this
further as well.

Yes, I saw this. But this limits the use-cases so much.
For instance, running Android as a Guest (which uses ION to allocate
buffers) means that finally HW composer will import dma-buf into
the DRM driver. Then, in case of xen-front for example, it needs to be
shared with the backend (Host side). Of course, we can change user-space
to make xen-front allocate the buffers (make it exporter), but what we try
to avoid is to change user-space which in normal world would have remain
unchanged otherwise.
So, I do think we have to support this use-case and just have to understand
the complexity.



danvet, can you comment on this topic?


2. the page sharing mechanism - it uses Xen-grant-table.

And to give you a quick summary of differences as far as I understand
between two implementations (please correct me if I am wrong, Oleksandr.)

1. xen-zcopy is DRM specific - can import only DRM prime buffer
while hyper_dmabuf can export any dmabuf regardless of originator

Well, this is true. And at the same time this is just a matter
of extending the API: xen-zcopy is a helper driver designed for
xen-front/back use-case, so this is why it only has DRM PRIME API

2. xen-zcopy doesn't seem to have dma-buf synchronization between two VMs
while (as danvet called it as remote dmabuf api sharing) hyper_dmabuf sends
out synchronization message to the exporting VM for synchronization.

This is true. Again, this is because of the use-cases it covers.
But having synchronization for a generic solution seems to be a good idea.

Yeah, understood xen-zcopy works ok with your use case. But I am just curious
if it is ok not to have any inter-domain synchronization in this sharing model.

The synchronization is done with displif protocol [1]

The buffer being shared is technically dma-buf and originator needs to be able
to keep track of it.

As I am working in DRM terms the tracking is done by the DRM core
for me for free. (This might be one of the reasons Daniel sees DRM
based implementation fit very good from code-reuse POV).



3. 1-level references - when using grant-table for sharing pages, there will
be same # of refs (each 8 byte)

To be precise, grant ref is 4 bytes

You are right. Thanks for correction.;)


as # of shared pages, which is passed to
the userspace to be shared with importing VM in case of xen-zcopy.

The reason for that is that xen-zcopy is a helper driver, e.g.
the grant references come from the display backend [1], which implements
Xen display protocol [2]. So, effectively the backend extracts references
from frontend's requests and passes those to xen-zcopy as an array
of refs.

  Compared
to this, hyper_dmabuf does multiple level addressing to generate only one
reference id that represents all shared pages.

In the protocol [2] only one reference to the gref directory is passed
between VMs
(and the gref directory is a single-linked list of shared pages containing
all
of the grefs of the buffer).

ok, good to know. I will look into its implementation in more details but is
this gref directory (chained grefs) something that can be used for any general
memory sharing use case or is it jsut for xen-display (in current code base)?

Not to mislead you: one grant ref is passed via displif protocol,
but the page it's referencing contains the rest of the grant refs.

As to if this can be used for any memory: yes. It is the same for
sndif and displif Xen protocols, but defined twice as strictly speaking
sndif and displif are two separate protocols.

While reviewing your RFC v2 one of the comments I had [2] was that if we
can start 

[PATCH v2 1/2] Fix NULL pointer in page_cache_tree_insert

[Matthew Wilcox]

From: Matthew Wilcox 

f2fs specifies the __GFP_ZERO flag for allocating some of its pages.
Unfortunately, the page cache also uses the mapping's GFP flags for
allocating radix tree nodes.  It always masked off the __GFP_HIGHMEM
flag, and masks off __GFP_ZERO in some paths, but not all.  That causes
radix tree nodes to be allocated with a NULL list_head, which causes
backtraces like:

[] __list_del_entry+0x30/0xd0
[] list_lru_del+0xac/0x1ac
[] page_cache_tree_insert+0xd8/0x110

The __GFP_DMA and __GFP_DMA32 flags would also be able to sneak through
if they are ever used.  Fix them all by using GFP_RECLAIM_MASK at the
innermost location, and remove it from earlier in the callchain.

Fixes: 449dd6984d0e ("mm: keep page cache radix tree nodes in check")
Reported-by: Chris Fries 
Debugged-by: Minchan Kim 
Signed-off-by: Matthew Wilcox 
Acked-by: Johannes Weiner 
Acked-by: Michal Hocko 
Reviewed-by: Jan Kara 
Cc: sta...@vger.kernel.org
---
 mm/filemap.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index c2147682f4c3..1a4bfc5ed3dc 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -785,7 +785,7 @@ int replace_page_cache_page(struct page *old, struct page 
*new, gfp_t gfp_mask)
VM_BUG_ON_PAGE(!PageLocked(new), new);
VM_BUG_ON_PAGE(new->mapping, new);
 
-   error = radix_tree_preload(gfp_mask & ~__GFP_HIGHMEM);
+   error = radix_tree_preload(gfp_mask & GFP_RECLAIM_MASK);
if (!error) {
struct address_space *mapping = old->mapping;
void (*freepage)(struct page *);
@@ -841,7 +841,7 @@ static int __add_to_page_cache_locked(struct page *page,
return error;
}
 
-   error = radix_tree_maybe_preload(gfp_mask & ~__GFP_HIGHMEM);
+   error = radix_tree_maybe_preload(gfp_mask & GFP_RECLAIM_MASK);
if (error) {
if (!huge)
mem_cgroup_cancel_charge(page, memcg, false);
@@ -1574,8 +1574,7 @@ struct page *pagecache_get_page(struct address_space 
*mapping, pgoff_t offset,
if (fgp_flags & FGP_ACCESSED)
__SetPageReferenced(page);
 
-   err = add_to_page_cache_lru(page, mapping, offset,
-   gfp_mask & GFP_RECLAIM_MASK);
+   err = add_to_page_cache_lru(page, mapping, offset, gfp_mask);
if (unlikely(err)) {
put_page(page);
page = NULL;
@@ -2378,7 +2377,7 @@ static int page_cache_read(struct file *file, pgoff_t 
offset, gfp_t gfp_mask)
if (!page)
return -ENOMEM;
 
-   ret = add_to_page_cache_lru(page, mapping, offset, gfp_mask & 
GFP_KERNEL);
+   ret = add_to_page_cache_lru(page, mapping, offset, gfp_mask);
if (ret == 0)
ret = mapping->a_ops->readpage(file, page);
else if (ret == -EEXIST)
-- 
2.16.3

[PATCH v2 2/2] slab: __GFP_ZERO is incompatible with a constructor

[Matthew Wilcox]

From: Matthew Wilcox 

__GFP_ZERO requests that the object be initialised to all-zeroes,
while the purpose of a constructor is to initialise an object to a
particular pattern.  We cannot do both.  Add a warning to catch any
users who mistakenly pass a __GFP_ZERO flag when allocating a slab with
a constructor.

Fixes: d07dbea46405 ("Slab allocators: support __GFP_ZERO in all allocators")
Signed-off-by: Matthew Wilcox 
Acked-by: Johannes Weiner 
Acked-by: Vlastimil Babka 
---
 mm/slab.c | 7 ---
 mm/slab.h | 7 +++
 mm/slob.c | 4 +++-
 mm/slub.c | 5 +++--
 4 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 58c8cecc26ab..9ad85fd9fca8 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2661,6 +2661,7 @@ static struct page *cache_grow_begin(struct kmem_cache 
*cachep,
invalid_mask, _mask, flags, );
dump_stack();
}
+   BUG_ON(cachep->ctor && (flags & __GFP_ZERO));
local_flags = flags & (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK);
 
check_irq_off();
@@ -3325,7 +3326,7 @@ slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, 
int nodeid,
local_irq_restore(save_flags);
ptr = cache_alloc_debugcheck_after(cachep, flags, ptr, caller);
 
-   if (unlikely(flags & __GFP_ZERO) && ptr)
+   if (unlikely(flags & __GFP_ZERO) && ptr && slab_no_ctor(cachep))
memset(ptr, 0, cachep->object_size);
 
slab_post_alloc_hook(cachep, flags, 1, );
@@ -3382,7 +3383,7 @@ slab_alloc(struct kmem_cache *cachep, gfp_t flags, 
unsigned long caller)
objp = cache_alloc_debugcheck_after(cachep, flags, objp, caller);
prefetchw(objp);
 
-   if (unlikely(flags & __GFP_ZERO) && objp)
+   if (unlikely(flags & __GFP_ZERO) && objp && slab_no_ctor(cachep))
memset(objp, 0, cachep->object_size);
 
slab_post_alloc_hook(cachep, flags, 1, );
@@ -3589,7 +3590,7 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t 
flags, size_t size,
cache_alloc_debugcheck_after_bulk(s, flags, size, p, _RET_IP_);
 
/* Clear memory outside IRQ disabled section */
-   if (unlikely(flags & __GFP_ZERO))
+   if (unlikely(flags & __GFP_ZERO) && slab_no_ctor(s))
for (i = 0; i < size; i++)
memset(p[i], 0, s->object_size);
 
diff --git a/mm/slab.h b/mm/slab.h
index 3cd4677953c6..896818c7b30a 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -515,6 +515,13 @@ static inline void dump_unreclaimable_slab(void)
 
 void ___cache_free(struct kmem_cache *cache, void *x, unsigned long addr);
 
+static inline bool slab_no_ctor(struct kmem_cache *s)
+{
+   if (IS_ENABLED(CONFIG_DEBUG_VM))
+   return !WARN_ON_ONCE(s->ctor);
+   return true;
+}
+
 #ifdef CONFIG_SLAB_FREELIST_RANDOM
 int cache_random_seq_create(struct kmem_cache *cachep, unsigned int count,
gfp_t gfp);
diff --git a/mm/slob.c b/mm/slob.c
index 1a46181b675c..958173fd7c24 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -556,8 +556,10 @@ static void *slob_alloc_node(struct kmem_cache *c, gfp_t 
flags, int node)
flags, node);
}
 
-   if (b && c->ctor)
+   if (b && c->ctor) {
+   WARN_ON_ONCE(flags & __GFP_ZERO);
c->ctor(b);
+   }
 
kmemleak_alloc_recursive(b, c->size, 1, c->flags, flags);
return b;
diff --git a/mm/slub.c b/mm/slub.c
index a28488643603..9f8f38a552e5 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1576,6 +1576,7 @@ static struct page *allocate_slab(struct kmem_cache *s, 
gfp_t flags, int node)
 
if (gfpflags_allow_blocking(flags))
local_irq_enable();
+   BUG_ON(s->ctor && (flags & __GFP_ZERO));
 
flags |= s->allocflags;
 
@@ -2725,7 +2726,7 @@ static __always_inline void *slab_alloc_node(struct 
kmem_cache *s,
stat(s, ALLOC_FASTPATH);
}
 
-   if (unlikely(gfpflags & __GFP_ZERO) && object)
+   if (unlikely(gfpflags & __GFP_ZERO) && object && slab_no_ctor(s))
memset(object, 0, s->object_size);
 
slab_post_alloc_hook(s, gfpflags, 1, );
@@ -3149,7 +3150,7 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t 
flags, size_t size,
local_irq_enable();
 
/* Clear memory outside IRQ disabled fastpath loop */
-   if (unlikely(flags & __GFP_ZERO)) {
+   if (unlikely(flags & __GFP_ZERO) && slab_no_ctor(s)) {
int j;
 
for (j = 0; j < i; j++)
-- 
2.16.3

[PATCH v2 0/2] Fix __GFP_ZERO vs constructor

[Matthew Wilcox]

From: Matthew Wilcox 

v1->v2:
 - Added review/ack tags (thanks!)
 - Switched the order of the patches
 - Reworded commit message of the patch which actually fixes the bug
 - Moved slab debug patches under CONFIG_DEBUG_VM to check _every_
   allocation and added checks in the slowpath for the allocations which
   end up allocating a page.

Matthew Wilcox (2):
  Fix NULL pointer in page_cache_tree_insert
  slab: __GFP_ZERO is incompatible with a constructor

 mm/filemap.c | 9 -
 mm/slab.c| 7 ---
 mm/slab.h| 7 +++
 mm/slob.c| 4 +++-
 mm/slub.c| 5 +++--
 5 files changed, 21 insertions(+), 11 deletions(-)

-- 
2.16.3

[PATCH][next] scsi: fnic: fix spelling mistake in fnic stats "Abord" -> "Abort"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in fnic stats message text

Signed-off-by: Colin Ian King 
---
 drivers/scsi/fnic/fnic_trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/fnic/fnic_trace.c b/drivers/scsi/fnic/fnic_trace.c
index abddde11982b..98597b59c12a 100644
--- a/drivers/scsi/fnic/fnic_trace.c
+++ b/drivers/scsi/fnic/fnic_trace.c
@@ -296,7 +296,7 @@ int fnic_get_stats_data(struct stats_debug_info *debug,
  "Number of Abort FW Timeouts: %lld\n"
  "Number of Abort IO NOT Found: %lld\n"
 
- "Abord issued times: \n"
+ "Abort issued times: \n"
  "< 6 sec : %lld\n"
  " 6 sec - 20 sec : %lld\n"
  "20 sec - 30 sec : %lld\n"
-- 
2.15.1

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

Hi Boris,

On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:
> Hi Ladislav,
> 
> On Wed, 11 Apr 2018 08:26:07 +0200
> Ladislav Michl  wrote:
> 
> > Hi Andreas,
> > 
> > On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> > > Hi Ladis,
> > > 
> > > On Tue, 10 Apr 2018 22:56:43 +0200
> > > Ladislav Michl  wrote:
> > >   
> > > > Hi Nikolaus,
> > > > 
> > > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:  
> > > > > Hi,
> > > > > we just started testing the v4.16 kernel and found the
> > > > > device no longer bootable (works with v4.15). It turned
> > > > > out that there was a harmful modification somewhere between
> > > > > v4.15.0 and v4.16-rc1.
> > > > > 
> > > > > A git bisect points to this patch:
> > > > 
> > > > Well, that's a shame... However, this code is in production for several
> > > > months now, so could you, please put 'goto out_copy' if 'buf >= 
> > > > high_memory'
> > > > condition is met, ie:
> > > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct 
> > > > mtd_info *mtd, int area,
> > > > if (buf >= high_memory) {
> > > > struct page *p1;
> > > >  
> > > > +   goto out_copy;
> > > > if (((size_t)buf & PAGE_MASK) !=
> > > > ((size_t)(buf + count - 1) & PAGE_MASK))
> > > > goto out_copy;  
> > > 
> > > I had the same problem here, and that snippet  helps here. ubiattach
> > > -p /dev/mtdX does not cause kernel oopses here anymore  
> > 
> > It seems reviving old code always comes at a price :-) Could you try
> > following patch, so far compile tested only?
> > (we'll need to do the same for omap2_onenand_write_bufferram, but
> > it sould be enough for testing purposes now)
> > 
> > diff --git a/drivers/mtd/nand/onenand/omap2.c 
> > b/drivers/mtd/nand/onenand/omap2.c
> > index 9c159f0dd9a6..04cefd7a6487 100644
> > --- a/drivers/mtd/nand/onenand/omap2.c
> > +++ b/drivers/mtd/nand/onenand/omap2.c
> > @@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> >  {
> > struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > struct onenand_chip *this = mtd->priv;
> > +   struct device *dev = >pdev->dev;
> > dma_addr_t dma_src, dma_dst;
> > int bram_offset;
> > void *buf = (void *)buffer;
> > size_t xtra;
> > -   int ret;
> > +   int ret, page_dma = 0;
> >  
> > bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> > if (in_interrupt() || oops_in_progress)
> > goto out_copy;
> >  
> > +   xtra = count & 3;
> > +   if (xtra) {
> > +   count -= xtra;
> > +   memcpy(buf + count, this->base + bram_offset + count, xtra);
> > +   }
> > +
> > +   /* Handle vmalloc address */
> > if (buf >= high_memory) {
> > -   struct page *p1;
> > +   struct page *page;
> >  
> > if (((size_t)buf & PAGE_MASK) !=
> > ((size_t)(buf + count - 1) & PAGE_MASK))
> > goto out_copy;
> > -   p1 = vmalloc_to_page(buf);
> > -   if (!p1)
> > +   page = vmalloc_to_page(buf);
> 
> Not sure this approach is safe on all archs: if the cache is VIVT or
> VIPT, you may have several entries pointing to the same phys page, and
> then, when dma_map_page() does its cache maintenance operations, it's
> only taking one of these entries into account.

Hmm, I used the same approach Samsung OneNAND driver does since commit
dcf08227e964a53a2cb39130b74842c7dcb6adde.
Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
is VIPT. In that case samsung's driver code has the same problem.

> In other parts of the MTD subsystem, we tend to not do DMA on buffers
> that have been vmalloc-ed.
> 
> You can do something like
> 
>   if (virt_addr_valid(buf))
>   /* Use DMA */
>   else
>   /*
>* Do not use DMA, or use a bounce buffer
>* allocated with kmalloc
>*/

Okay, I'll use this approach then, but first I'd like to be sure above is
correct. Anyone?

> Regards,
> 
> Boris

Thank you,
ladis

> > +   if (!page)
> > goto out_copy;
> > -   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
> > -   }
> > -
> > -   xtra = count & 3;
> > -   if (xtra) {
> > -   count -= xtra;
> > -   memcpy(buf + count, this->base + bram_offset + count, xtra);
> > +   page_dma = 1;
> > +   dma_dst = dma_map_page(dev, page, (size_t) buf & ~PAGE_MASK,
> > + 

Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.

[Miroslav Benes]

On Tue, 10 Apr 2018, Josh Poimboeuf wrote:

> > > I agree here. Practically we use only cumulative replacement patches at
> > > SUSE. So with that in mind I don't care about the stacking much. But, it
> > > may make sense for someone else. Evgenii mentioned they used it for
> > > hotfixes. Therefore I'm reluctant to remove it completely.
> > 
> > Well, it was convenient in some cases to provide a hot fix for a given bug
> > on top of our official cumulative patch. So far, such fixes were only used
> > on a few of the customers' machines (where they were needed ASAP). It just
> > made it easier to see where is the common set of fixes and where is the
> > customer-specific addition.
> > 
> > I think, we can use cumulative patches in such cases too without much
> > additional effort. For example, we can encode the distinction (base set of
> > fixes + addition) in the module name or somewhere else.
> > 
> > So, I think, it is fine for us, if stacking support is removed. Especially
> > if that makes the implementation of livepatch less complex and more
> > reliable.
> 
> Just to clarify, I think we are just proposing the removal of the
> enforcement of the stacking order.  We will still allow multiple
> non-replace patches to be applied.  We just won't enforce which patches
> can be disabled/removed at any given time.

Heh, so I misunderstood. I thought you were talking about the removal of 
the stacking. Now it makes more sense.
 
> So I think your old way of doing things (individual unrelated patches on
> top of a cumulative patch) would still work.

Yes. On the other hand the user needs to be even more careful, so I'd 
expect an update of documentation with the removal :).

Miroslav

Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.

[Miroslav Benes]

On Tue, 10 Apr 2018, Josh Poimboeuf wrote:

> On Tue, Apr 10, 2018 at 10:34:55AM +0200, Petr Mladek wrote:
> > > > > > > We were just recently discussing the possibility of not allowing 
> > > > > > > the
> > > > > > > disabling of patches at all.  If we're not going that far, let's 
> > > > > > > at
> > > > > > > least further restrict it, for the sanity of our code, so we 
> > > > > > > don't have
> > > > > > > to worry about a nasty mismatched stack of 
> > > > > > > enabled/disabled/enabled/etc,
> > > > > > > at least for the cases where 'replace' patches aren't used.
> > > > > > 
> > > > > > I am not completely sure where all these fears come from. From my
> > > > > > point of view, this change is pretty safe and trivial thanks to NOPs
> > > > > > and overall design. It would be a shame to do not have it. But I
> > > > > > might be blind after spending so much time with the feature.
> > > > > 
> > > > > I think you're missing my point.  This isn't about your patch set, per
> > > > > se.  It's really about our existing code.  Today, our patch stack
> > > > > doesn't follow real stack semantics, because patches in the middle 
> > > > > might
> > > > > be disabled.  I see that as a problem.
> > > 
> > > No, please read it again.  I wasn't talking about replaced patches.
> > 
> > I was confused by wording "in the middle". It suggested that there
> > might had been enabled patches on the top and the bottom of the stack
> > and some disabled patches in between at the same time (or vice versa).
> > This was not true.
> 
> That *was* what I meant.  Consider the following sequence of events:
> 
> - Register patch 1
> - Enable patch 1
> - Register patch 2
> - Enable patch 2
> - Disable patch 2
> - Register patch 3
> - Enable patch 3
> 
> Notice that patch 2 (in the middle) is disabled, whereas patch 1 (on the
> bottom) and patch 3 (on the top) are enabled.

This should not be possible at all.

__klp_enable_patch:

if (patch->list.prev != _patches &&
!list_prev_entry(patch, list)->enabled)
return -EBUSY;

When patch 3 is enabled, list_prev_entry() returns patch 2 and its 
->enabled is false.
 
> > Do I understand it correctly that you do not like that the patches
> > on the stack might be in two states (disabled/enabled). This might
> > be translated that you do not like the state when the patch is
> > registered and disabled.
> 
> No, that wasn't really what I meant, but I have often wondered whether
> we need such a distinction.
> 
> > I wonder if the problem is in the "stack" abstraction. Would it help
> > if we call it "sorted list" or whatever more suitable?
> 
> But I don't even see a reason to have a sorted list (more on that
> below).
> 
> > Another possibility would be to get rid of the enable/disable states.
> > I mean that the patch will be automatically enabled during
> > registration and removed during unregistration.
> 
> I don't see how disabling during unregistration would be possible, since
> the unregister is called from the patch module exit function, which
> can only be called *after* the patch is disabled.
> 
> However, we could unregister immediately after disabling (i.e., in
> enabled_store context).

I think this is what Petr meant. So there would be nothing in the patch 
module exit function. Well, not exactly. We'd need to remove sysfs dir and 
maybe something more.

> > Or we could rename the operation do add/remove or anything else. In
> > fact, this is how it worked in kGraft.
> 
> I'm not sure what renaming would solve, unless you mean to combine
> registration and enablement into a single concept?  Sounds good to me.
> 
> > AFAIK, the enable/disabled state made more sense for immediate
> > patches that could not be unloaded. We still need to keep the patches
> > when the transaction is forced. The question is if we need to keep
> > the sysfs entries for loaded but unused patches.
> 
> I think we wouldn't need the sysfs entries.  Just disable/unregister
> forced patches like normal, except skipping the module_put().
> 
> > > Either way, why do we still need a stack?
> > 
> > Good question. I suggest to agree on some terms first:
> > 
> >+ Independent patches make unrelated changes. Any new function
> >  must not rely on changes done by any other patch.
> > 
> >+ Dependent patches mean that a later patch depend on changes
> >  done by an earlier patch. For example, a new function might
> >  use function added by an earlier patch.
> > 
> >+ Each cumulative patch include all necessary changes. I would say
> >  that it is self-containing and independent. Except that they should
> >  be able to continue using changes made by earlier patches (shadow
> >  variables, callbacks).
> > 
> > 
> > Then we could say:
> > 
> >+ The stack helps to enforce dependencies between dependent
> >  patches. But there is needed also some external solution
> >  that forces loading the patches in the right order.
> > 
> >

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Boris Brezillon]

On Wed, 11 Apr 2018 09:36:56 +0200
Ladislav Michl  wrote:

> Hi Boris,
> 
> On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:
> > Hi Ladislav,
> > 
> > On Wed, 11 Apr 2018 08:26:07 +0200
> > Ladislav Michl  wrote:
> >   
> > > Hi Andreas,
> > > 
> > > On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:  
> > > > Hi Ladis,
> > > > 
> > > > On Tue, 10 Apr 2018 22:56:43 +0200
> > > > Ladislav Michl  wrote:
> > > > 
> > > > > Hi Nikolaus,
> > > > > 
> > > > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote: 
> > > > >
> > > > > > Hi,
> > > > > > we just started testing the v4.16 kernel and found the
> > > > > > device no longer bootable (works with v4.15). It turned
> > > > > > out that there was a harmful modification somewhere between
> > > > > > v4.15.0 and v4.16-rc1.
> > > > > > 
> > > > > > A git bisect points to this patch:  
> > > > > 
> > > > > Well, that's a shame... However, this code is in production for 
> > > > > several
> > > > > months now, so could you, please put 'goto out_copy' if 'buf >= 
> > > > > high_memory'
> > > > > condition is met, ie:
> > > > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > > > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct 
> > > > > mtd_info *mtd, int area,
> > > > >   if (buf >= high_memory) {
> > > > >   struct page *p1;
> > > > >  
> > > > > + goto out_copy;
> > > > >   if (((size_t)buf & PAGE_MASK) !=
> > > > >   ((size_t)(buf + count - 1) & PAGE_MASK))
> > > > >   goto out_copy;
> > > > 
> > > > I had the same problem here, and that snippet  helps here. ubiattach
> > > > -p /dev/mtdX does not cause kernel oopses here anymore
> > > 
> > > It seems reviving old code always comes at a price :-) Could you try
> > > following patch, so far compile tested only?
> > > (we'll need to do the same for omap2_onenand_write_bufferram, but
> > > it sould be enough for testing purposes now)
> > > 
> > > diff --git a/drivers/mtd/nand/onenand/omap2.c 
> > > b/drivers/mtd/nand/onenand/omap2.c
> > > index 9c159f0dd9a6..04cefd7a6487 100644
> > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > @@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct 
> > > mtd_info *mtd, int area,
> > >  {
> > >   struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > >   struct onenand_chip *this = mtd->priv;
> > > + struct device *dev = >pdev->dev;
> > >   dma_addr_t dma_src, dma_dst;
> > >   int bram_offset;
> > >   void *buf = (void *)buffer;
> > >   size_t xtra;
> > > - int ret;
> > > + int ret, page_dma = 0;
> > >  
> > >   bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > >   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > > @@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct 
> > > mtd_info *mtd, int area,
> > >   if (in_interrupt() || oops_in_progress)
> > >   goto out_copy;
> > >  
> > > + xtra = count & 3;
> > > + if (xtra) {
> > > + count -= xtra;
> > > + memcpy(buf + count, this->base + bram_offset + count, xtra);
> > > + }
> > > +
> > > + /* Handle vmalloc address */
> > >   if (buf >= high_memory) {
> > > - struct page *p1;
> > > + struct page *page;
> > >  
> > >   if (((size_t)buf & PAGE_MASK) !=
> > >   ((size_t)(buf + count - 1) & PAGE_MASK))
> > >   goto out_copy;
> > > - p1 = vmalloc_to_page(buf);
> > > - if (!p1)
> > > + page = vmalloc_to_page(buf);  
> > 
> > Not sure this approach is safe on all archs: if the cache is VIVT or
> > VIPT, you may have several entries pointing to the same phys page, and
> > then, when dma_map_page() does its cache maintenance operations, it's
> > only taking one of these entries into account.  
> 
> Hmm, I used the same approach Samsung OneNAND driver does since commit
> dcf08227e964a53a2cb39130b74842c7dcb6adde.
> Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> is VIPT. In that case samsung's driver code has the same problem.
> 
> > In other parts of the MTD subsystem, we tend to not do DMA on buffers
> > that have been vmalloc-ed.
> > 
> > You can do something like
> > 
> > if (virt_addr_valid(buf))
> > /* Use DMA */
> > else
> > /*
> >  * Do not use DMA, or use a bounce buffer
> >  * allocated with kmalloc
> >  */  
> 
> Okay, I'll use this approach then, but first I'd like to be sure above is
> correct. Anyone?

See this discussion [1]. The problem came up a few times already, so
might find other threads describing why it's not safe.

Re: [PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers

[Simon Horman]

On Tue, Apr 10, 2018 at 09:49:14PM +0200, Wolfram Sang wrote:
> From: Wolfram Sang 
> 
> Intentionally missing i2c-riic here, Chris Brandt will add himself for
> that one later.
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

[PATCH v4] writeback: safer lock nesting

[Greg Thelen]

lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if
the page's memcg is undergoing move accounting, which occurs when a
process leaves its memcg for a new one that has
memory.move_charge_at_immigrate set.

unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if the
given inode is switching writeback domains.  Switches occur when enough
writes are issued from a new domain.

This existing pattern is thus suspicious:
lock_page_memcg(page);
unlocked_inode_to_wb_begin(inode, );
...
unlocked_inode_to_wb_end(inode, locked);
unlock_page_memcg(page);

If both inode switch and process memcg migration are both in-flight then
unlocked_inode_to_wb_end() will unconditionally enable interrupts while
still holding the lock_page_memcg() irq spinlock.  This suggests the
possibility of deadlock if an interrupt occurs before
unlock_page_memcg().

truncate
__cancel_dirty_page
lock_page_memcg
unlocked_inode_to_wb_begin
unlocked_inode_to_wb_end


end_page_writeback
test_clear_page_writeback
lock_page_memcg

unlock_page_memcg

Due to configuration limitations this deadlock is not currently possible
because we don't mix cgroup writeback (a cgroupv2 feature) and
memory.move_charge_at_immigrate (a cgroupv1 feature).

If the kernel is hacked to always claim inode switching and memcg
moving_account, then this script triggers lockup in less than a minute:
  cd /mnt/cgroup/memory
  mkdir a b
  echo 1 > a/memory.move_charge_at_immigrate
  echo 1 > b/memory.move_charge_at_immigrate
  (
echo $BASHPID > a/cgroup.procs
while true; do
  dd if=/dev/zero of=/mnt/big bs=1M count=256
done
  ) &
  while true; do
sync
  done &
  sleep 1h &
  SLEEP=$!
  while true; do
echo $SLEEP > a/cgroup.procs
echo $SLEEP > b/cgroup.procs
  done

The deadlock does not seem possible, so it's debatable if there's
any reason to modify the kernel.  I suggest we should to prevent future
surprises.  And Wang Long said "this deadlock occurs three times in our
environment", so there's more reason to apply this, even to stable.
Stable 4.4 has minor conflicts applying this patch.
For a clean 4.4 patch see "[PATCH for-4.4] writeback: safer lock nesting"
https://lkml.org/lkml/2018/4/11/146

Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and 
use it for stat updates")
Cc: sta...@vger.kernel.org # v4.2+
Reported-by: Wang Long 
Signed-off-by: Greg Thelen 
Acked-by: Michal Hocko 
Acked-by: Wang Long 
---

Changelog since v3:
- initialize wb_lock_cookie wiht {} rather than {0}.
- comment grammar fix
- commit log footer cleanup (-Change-Id, +Fixes, +Acks, +stable), though patch
  does not cleanly apply to 4.4.  I'll post a 4.4-stable specific patch.

Changelog since v2:
- explicitly initialize wb_lock_cookie to silence compiler warnings.

Changelog since v1:
- add wb_lock_cookie to record lock context.

 fs/fs-writeback.c|  7 ---
 include/linux/backing-dev-defs.h |  5 +
 include/linux/backing-dev.h  | 31 +--
 mm/page-writeback.c  | 18 +-
 4 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 1280f915079b..b1178acfcb08 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -745,11 +745,12 @@ int inode_congested(struct inode *inode, int cong_bits)
 */
if (inode && inode_to_wb_is_valid(inode)) {
struct bdi_writeback *wb;
-   bool locked, congested;
+   struct wb_lock_cookie lock_cookie = {};
+   bool congested;
 
-   wb = unlocked_inode_to_wb_begin(inode, );
+   wb = unlocked_inode_to_wb_begin(inode, _cookie);
congested = wb_congested(wb, cong_bits);
-   unlocked_inode_to_wb_end(inode, locked);
+   unlocked_inode_to_wb_end(inode, _cookie);
return congested;
}
 
diff --git a/include/linux/backing-dev-defs.h b/include/linux/backing-dev-defs.h
index bfe86b54f6c1..0bd432a4d7bd 100644
--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -223,6 +223,11 @@ static inline void set_bdi_congested(struct 
backing_dev_info *bdi, int sync)
set_wb_congested(bdi->wb.congested, sync);
 }
 
+struct wb_lock_cookie {
+   bool locked;
+   unsigned long flags;
+};
+
 #ifdef CONFIG_CGROUP_WRITEBACK
 
 /**
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index 3e4ce54d84ab..96f4a3ddfb81 100644
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -346,7 +346,7 @@ static inline struct bdi_writeback *inode_to_wb(const 
struct inode 

Re: [RFC 1/6] dt-bindings: dma: xilinx_dma: Add optional property has_axieth_connected

[Vinod Koul]

On Mon, Apr 02, 2018 at 04:09:01PM +0530, Radhey Shyam Pandey wrote:
> Add an optional AXI DMA property 'has_axieth_connected'. This can be
> specified to indicate that AXI DMA is connected to AXI Ethernet in
> hardware design and dma driver needs to do some additional handling.

1. why are DT people and list not added to this? I have added that
2. should we have a property for a specific peripheral? Wouldn't it help to have
a generic property for peripheral connected which can be scaled to more IPs
being connected in future?
3. Please use right subsystem name, it damengine: not dma:

> 
> Signed-off-by: Radhey Shyam Pandey 
> ---
>  .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
> b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> index a2b8bfa..5d592e3 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -42,6 +42,7 @@ Optional properties:
>   the hardware.
>  Optional properties for AXI DMA:
>  - xlnx,mcdma: Tells whether configured for multi-channel mode in the 
> hardware.
> +- xlnx,axieth-connected: Tells whether AXI DMA is connected to AXI Ethernet.
>  Optional properties for VDMA:
>  - xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
>   It takes following values:
> -- 
> 1.7.1
> 

-- 
~Vinod

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

[Christian König]

Am 11.04.2018 um 08:26 schrieb Huang Rui:

On Tue, Apr 10, 2018 at 04:59:55PM -0400, Sinan Kaya wrote:

Code is expecing to observe the same number of buffers returned from
dma_map_sg() function compared to sg_alloc_table_from_pages(). This
doesn't hold true universally especially for systems with IOMMU.

IOMMU driver tries to combine buffers into a single DMA address as much
as it can. The right thing is to tell the DMA layer how much combining
IOMMU can do.

Signed-off-by: Sinan Kaya 

Sinan, I guess Christian's suggestion is to add amdgpu_device_init function
like here:


Yes, exactly. Looks like Sinan just tried to place the call next to 
pci_set_dma_mask()/pci_set_consistent_dma_mask().


Not necessary a bad idea, but in this case not optimal.

Sinan please refine your patch as Rui suggested and resend.

Thanks,
Christian.



8<---
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 0e798b3..9b96771 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2339,6 +2339,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 /* init the mode config */
 drm_mode_config_init(adev->ddev);

+   dma_set_max_seg_size(adev->dev, PAGE_SIZE);
+
 r = amdgpu_device_ip_init(adev);
 if (r) {
 /* failed in exclusive mode due to timeout */
8<---

After that, we don't do it in each generation.

Thanks,
Ray
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/2] vfio: platform: Fix reset module leak in error path

[Geert Uytterhoeven]

If the IOMMU group setup fails, the reset module is not released.

Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by 
default")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Eric Auger 
Reviewed-by: Simon Horman 
---
v3:
  - Add Reviewed-by,

v2:
  - Add Reviewed-by.
---
 drivers/vfio/platform/vfio_platform_common.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 35469af87f88678e..b60bb5326668498c 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -680,18 +680,23 @@ int vfio_platform_probe_common(struct 
vfio_platform_device *vdev,
group = vfio_iommu_group_get(dev);
if (!group) {
pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put_reset;
}
 
ret = vfio_add_group_dev(dev, _platform_ops, vdev);
-   if (ret) {
-   vfio_iommu_group_put(group, dev);
-   return ret;
-   }
+   if (ret)
+   goto put_iommu;
 
mutex_init(>igate);
 
return 0;
+
+put_iommu:
+   vfio_iommu_group_put(group, dev);
+put_reset:
+   vfio_platform_put_reset(vdev);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(vfio_platform_probe_common);
 
-- 
2.7.4

Re: [PATCH 1/5] dmaengine: sprd: Define the DMA transfer step type

[Vinod Koul]

On Tue, Apr 10, 2018 at 03:46:03PM +0800, Baolin Wang wrote:
> From: Eric Long 
> 
> Define the DMA transfer step type to make code more readable.
> 
> Signed-off-by: Eric Long 
> Signed-off-by: Baolin Wang 
> ---
>  drivers/dma/sprd-dma.c |   28 ++--
>  1 file changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
> index b106e8a..af9c156 100644
> --- a/drivers/dma/sprd-dma.c
> +++ b/drivers/dma/sprd-dma.c
> @@ -169,6 +169,22 @@ enum sprd_dma_int_type {
>   SPRD_DMA_CFGERR_INT,
>  };
>  
> +/*
> + * enum sprd_dma_step: define the DMA transfer step type
> + * @SPRD_DMA_NONE_STEP: transfer do not need step
> + * @SPRD_DMA_BYTE_STEP: transfer step is one byte
> + * @SPRD_DMA_SHORT_STEP: transfer step is two bytes
> + * @SPRD_DMA_WORD_STEP: transfer step is one word
> + * @SPRD_DMA_DWORD_STEP: transfer step is double word
> + */
> +enum sprd_dma_step {

looking at bit defines, does it need to be enum? a #define would just be fine.

> + SPRD_DMA_NONE_STEP,
> + SPRD_DMA_BYTE_STEP = BIT(0),
> + SPRD_DMA_SHORT_STEP = BIT(1),
> + SPRD_DMA_WORD_STEP = BIT(2),
> + SPRD_DMA_DWORD_STEP = BIT(3),
> +};
> +
>  /* dma channel hardware configuration */
>  struct sprd_dma_chn_hw {
>   u32 pause;
> @@ -598,16 +614,16 @@ static int sprd_dma_config(struct dma_chan *chan, 
> struct sprd_dma_desc *sdesc,
>  
>   if (IS_ALIGNED(len, 4)) {
>   datawidth = 2;
> - src_step = 4;
> - des_step = 4;
> + src_step = SPRD_DMA_WORD_STEP;
> + des_step = SPRD_DMA_WORD_STEP;
>   } else if (IS_ALIGNED(len, 2)) {
>   datawidth = 1;
> - src_step = 2;
> - des_step = 2;
> + src_step = SPRD_DMA_SHORT_STEP;
> + des_step = SPRD_DMA_SHORT_STEP;
>   } else {
>   datawidth = 0;
> - src_step = 1;
> - des_step = 1;
> + src_step = SPRD_DMA_BYTE_STEP;
> + des_step = SPRD_DMA_BYTE_STEP;
>   }
>  
>   fragment_len = SPRD_DMA_MEMCPY_MIN_SIZE;
> -- 
> 1.7.9.5
> 

-- 
~Vinod

Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration

[Vinod Koul]

On Tue, Apr 10, 2018 at 03:46:06PM +0800, Baolin Wang wrote:

> +/*
> + * struct sprd_dma_config - DMA configuration structure
> + * @config: dma slave channel config
> + * @fragment_len: specify one fragment transfer length
> + * @block_len: specify one block transfer length
> + * @transcation_len: specify one transcation transfer length
> + * @wrap_ptr: wrap pointer address, once the transfer address reaches the
> + * 'wrap_ptr', the next transfer address will jump to the 'wrap_to' address.
> + * @wrap_to: wrap jump to address
> + * @req_mode: specify the DMA request mode
> + * @int_mode: specify the DMA interrupt type
> + */
> +struct sprd_dma_config {
> + struct dma_slave_config config;
> + u32 fragment_len;

why not use _maxburst?

> + u32 block_len;
> + u32 transcation_len;

what does block and transaction len refer to here

> + phys_addr_t wrap_ptr;
> + phys_addr_t wrap_to;

this sound sg_list to me, why are we not using that here

> + enum sprd_dma_req_mode req_mode;

Looking at definition of request mode we have frag, block, transaction list
etc.. That should depend upon dma request. If you have been asked to
transfer a list, you shall configure list mode. if it is a single
transaction then it should be transaction mode!

> + enum sprd_dma_int_type int_mode;

Here again I think driver needs to take a call based on dma_ctrl_flags.

Okay I dont think we are proceeding in right direction on this one. This
seems to be fairly generic dma controller and in line with other IP blocks
and you should take reference from those one. I dont think we need this
configuration and can do with generic api and configuration provided.

Thanks
-- 
~Vinod

Re: [PATCH v2 4/9] lib/vsprintf: Make flag_spec global

[Petr Mladek]

On Fri 2018-02-16 23:07:06, Andy Shevchenko wrote:
> There are places where default specification to print flags as number
> is in use.
> 
> Make it global and convert existing users.
> 
> Signed-off-by: Andy Shevchenko 

Reviewed-by: Petr Mladek 

I have pushed it into printk.git, branch for-4.18-vsprintf-cleanup.

Best Regards,
Petr

Re: [PATCH v4] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

[Julien Grall]

Hi,

On 10/04/18 08:58, Paul Durrant wrote:

+static long privcmd_ioctl_mmap_resource(struct file *file, void __user *udata)
+{
+   struct privcmd_data *data = file->private_data;
+   struct mm_struct *mm = current->mm;
+   struct vm_area_struct *vma;
+   struct privcmd_mmap_resource kdata;
+   xen_pfn_t *pfns = NULL;
+   struct xen_mem_acquire_resource xdata;
+   int rc;
+
+   if (copy_from_user(, udata, sizeof(kdata)))
+   return -EFAULT;
+
+   /* If restriction is in place, check the domid matches */
+   if (data->domid != DOMID_INVALID && data->domid != kdata.dom)
+   return -EPERM;
+
+   down_write(>mmap_sem);
+
+   vma = find_vma(mm, kdata.addr);
+   if (!vma || vma->vm_ops != _vm_ops) {
+   rc = -EINVAL;
+   goto out;
+   }
+
+   pfns = kcalloc(kdata.num, sizeof(*pfns), GFP_KERNEL);
+   if (!pfns) {
+   rc = -ENOMEM;
+   goto out;
+   }
+
+   if (xen_feature(XENFEAT_auto_translated_physmap)) {
+   struct page **pages;
+   unsigned int i;
+
+   rc = alloc_empty_pages(vma, kdata.num);
+   if (rc < 0)
+   goto out;
+
+   pages = vma->vm_private_data;
+   for (i = 0; i < kdata.num; i++)
+   pfns[i] = page_to_pfn(pages[i]);


I don't think this is going to work well if the hypervisor is using a 
different granularity for the page.


Imagine Xen is using 4K but the kernel 64K. You would end up to have the 
resource not mapped contiguously in the memory.


Cheers,

--
Julien Grall

Re: [PATCH v2 5/9] lib/vsprintf: Move pointer_string() upper

[Petr Mladek]

On Fri 2018-02-16 23:07:07, Andy Shevchenko wrote:
> As preparatory patch to further clean up.
> 
> No functional change.
> 
> Signed-off-by: Andy Shevchenko 

Reviewed-by: Petr Mladek 

I have pushed it into printk.git, branch for-4.18-vsprintf-cleanup.

Best Regards,
Petr

Re: [PATCH v2] cpufreq/schedutil: Cleanup, document and fix iowait boost

[Patrick Bellasi]

On 10-Apr 21:37, Peter Zijlstra wrote:
> On Tue, Apr 10, 2018 at 04:59:31PM +0100, Patrick Bellasi wrote:
> > The iowait boosting code has been recently updated to add a progressive
> > boosting behavior which allows to be less aggressive in boosting tasks
> > doing only sporadic IO operations, thus being more energy efficient for
> > example on mobile platforms.
> > 
> > The current code is now however a bit convoluted. Some functionalities
> > (e.g. iowait boost reset) are replicated in different paths and their
> > documentation is slightly misaligned.
> 
> While your patch does seem to improve things, it still has duplicated
> bits in. Eg. the TICK_NSEC clearing exists in both functions.

Yes, that duplication has been added in v2 since, as Viresh pointed
out, iowait boost reset was still broken for IO wait tasks waking up
on a CPU idle for more then TICK_NSEC... we should probably have it on
a separate patch.

> > - sugov_set_iowait_boost: is now in charge only to set/increase the IO
> >  wait boost, every time a task wakes up from an IO wait.
> > 
> > - sugov_iowait_boost: is now in charge to reset/reduce the IO wait
> >  boost, every time a sugov update is triggered, as well as
> >  to (eventually) enforce the currently required IO boost value.
> 
> I'm not sold on those function names; feels like we can do better,
> although I'm struggling to come up with anything sensible just now.

What about something like:

 sugov_iowait_init()
 since here we are mainly initializing the iowait boost

 sugov_iowait_boost()
 since here we are mainly applying the proper boost to each cpu

Although they are not really so different...

> >  
> > if (delta_ns > TICK_NSEC) {
> > +   sg_cpu->iowait_boost = iowait
> > +   ? sg_cpu->sg_policy->policy->min : 0;
> > +   sg_cpu->iowait_boost_pending = iowait;
> > +   return;
> > }
> 
> > +   if (delta_ns > TICK_NSEC) {
> > +   sg_cpu->iowait_boost = 0;
> > +   sg_cpu->iowait_boost_pending = false;
> > +   return;
> > +   }
> 
> Looks like something we can maybe put in a helper or something.

... but we can also probably fold the two chunks above into something
like:

---8<---
static bool sugov_iowait_reset(struct sugov_cpu *sg_cpu, u64 time,
   bool iowait_boost)
{
s64 delta_ns = time - sg_cpu->last_update;

if (delta_ns <= TICK_NSEC)
return false;

sg_cpu->iowait_boost = iowait_boost
? sg_cpu->sg_policy->policy->min : 0;
sg_cpu->iowait_boost_pending = iowait_boost;

return true;
}
---8<---

-- 
#include 

Patrick Bellasi

Re: [PATCHv2 2/7] sched/fair: Add group_misfit_task load-balance type

[Peter Zijlstra]

On Thu, Mar 15, 2018 at 02:46:59PM +, Morten Rasmussen wrote:

> +static inline unsigned long task_util(struct task_struct *p);
> +static inline int task_fits_capacity(struct task_struct *p, long capacity)
> +{
> + return capacity * 1024 > task_util(p) * capacity_margin;
> +}
> +
> +static inline void update_misfit_status(struct task_struct *p, struct rq *rq)
> +{
> + if (!static_branch_unlikely(_asym_cpucapacity))
> + return;
> +
> + if (!p) {
> + rq->misfit_task_load = 0;
> + return;
> + }
> +
> + if (task_fits_capacity(p, capacity_of(cpu_of(rq {
> + rq->misfit_task_load = 0;
> + return;
> + }
> +
> + rq->misfit_task_load = task_h_load(p);
> +}

So RT/IRQ pressure can also cause misfit..


> @@ -7972,6 +8005,10 @@ static inline void update_sg_lb_stats(struct lb_env 
> *env,
>*/
>   if (!nr_running && idle_cpu(i))
>   sgs->idle_cpus++;
> +
> + if (env->sd->flags & SD_ASYM_CPUCAPACITY &&
> + !sgs->group_misfit_task_load && rq->misfit_task_load)
> + sgs->group_misfit_task_load = rq->misfit_task_load;
>   }

Should we not look for the biggest misfit instead of the first?

>  
>   /* Adjust by relative CPU capacity of the group */

Re: [PATCH v2] cpufreq/schedutil: Cleanup, document and fix iowait boost

[Peter Zijlstra]

On Wed, Apr 11, 2018 at 11:44:45AM +0100, Patrick Bellasi wrote:
> > > - sugov_set_iowait_boost: is now in charge only to set/increase the IO
> > >  wait boost, every time a task wakes up from an IO wait.
> > > 
> > > - sugov_iowait_boost: is now in charge to reset/reduce the IO wait
> > >  boost, every time a sugov update is triggered, as well as
> > >  to (eventually) enforce the currently required IO boost value.
> > 
> > I'm not sold on those function names; feels like we can do better,
> > although I'm struggling to come up with anything sensible just now.
> 
> What about something like:
> 
>  sugov_iowait_init()
>  since here we are mainly initializing the iowait boost
> 
>  sugov_iowait_boost()
>  since here we are mainly applying the proper boost to each cpu
> 
> Although they are not really so different...

How about:

  sugov_iowait_boost() -- does the actual impulse/boost
  sugov_iowait_apply() -- applies the boost state

?

Re: [PATCH] memory-model: fix cheat sheet typo

[Paolo Bonzini]

On 10/04/2018 23:34, Paul E. McKenney wrote:
> Glad it helps, and I have queued it for the next merge window.  Of course,
> if a further improvement comes to mind, please do not keep it a secret.  ;-)

Yes, there are several changes that could be included:

- SV could be added to the prior operation case as well?  It should be
symmetric

- The *_relaxed() case also applies to void RMW

- smp_store_mb() is missing

- smp_rmb() orders prior reads fully against subsequent RMW because SV
applies between the two parts of the RMW; likewise smp_wmb() orders prior
RMW fully against subsequent writes


I am going submit these changes separately, but before doing that I can show
also my rewrite of the cheat sheet.

The advantage is that, at least to me, it's clearer (and gets rid of
"Self" :)).

The disadvantage is that it's much longer---almost twice the lines, even if
you discount the splitting out of cumulative/propagating to a separate table
(which in turn is because to me it's a different level of black magic).

-
Memory operations are listed in this document as follows:

R:  Read portion of RMW
W:  Write portion of RMW
DR: Dependent read (address dependency)
DW: Dependent write (address, data, or control dependency)
RMW:Atomic read-modify-write operation
SV  Other accesses to the same variable


Memory access operations order other memory operations against themselves as
follows:

   Prior Operation   Subsequent Operation
   ---   -
   R  W  RMW  SV R  W  DR  DW  RMW  SV
   -  -  ---  -- -  -  --  --  ---  --
Store, e.g., WRITE_ONCE()  Y Y
Load, e.g., READ_ONCE()YY   YY
Unsuccessful RMW operation YY   YY
*_relaxed() or void RMW operation  YY   YY
rcu_dereference()  YY   YY
Successful *_acquire() Y  r  r  r   rr   Y
Successful *_release() w  ww   Y Y
smp_store_mb() Y  YY   Y  Y  Y   Y   Y   Y   Y
Successful full non-void RMW   Y  YY   Y  Y  Y   Y   Y   Y   Y

Key:Y:  Memory operation provides ordering
r:  Cannot move past the read portion of the *_acquire()
w:  Cannot move past the write portion of the *_release()


Memory barriers order prior memory operations against subsequent memory
operations.  Two operations are ordered if both have non-empty cells in
the following table:

   Prior Operation   Subsequent Operation
   ---   
   R  W  RMW R  W  DR  DW  RMW
   -  -  --- -  -  --  --  ---
smp_rmb()  Y  r  Y  Y   Y
smp_wmb() Y   Y Y   Y   w
smp_mb() & synchronize_rcu()   Y  Y   Y  Y  Y   Y   Y   Y
smp_mb__before_atomic()Y  Y   Y  a  a   a   a   Y
smp_mb__after_atomic() a  a   Y  Y  Y   Y   Y


Key:Y:  Barrier provides ordering
r:  Barrier provides ordering against the read portion of RMW
w:  Barrier provides ordering against the write portion of RMW
a:  Barrier provides ordering given intervening RMW atomic operation


Finally the following describes which operations provide cumulative and
propagating fences:

 Cumulative Propagates
 -- --
Store, e.g., WRITE_ONCE()
Load, e.g., READ_ONCE()
Unsuccessful RMW operation
*_relaxed() or void RMW operation
rcu_dereference()
Successful *_acquire()
Successful *_release()   Y
smp_store_mb()   Y  Y
Successful full non-void RMW Y  Y
smp_rmb()
smp_wmb()
smp_mb() & synchronize_rcu() Y  Y
smp_mb__before_atomic()  Y  Y
smp_mb__after_atomic()   Y  Y
--

Perhaps you can see some obvious improvements.  Otherwise I'll send patches
for the above issues.

Thanks,

Paolo

Re: [PATCH] cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN

[Oliver Neukum]

Am Mittwoch, den 11.04.2018, 13:15 +0200 schrieb Bassem Boubaker:
>     The Cinterion AHS8 is a 3G device with one embedded WWAN interface
>     using cdc_ether as a driver.
> 
>     The modem is  controlled via AT commands through the exposed TTYs.
> 
>     AT+CGDCONT write command can be used to activate or deactivate a WWAN
>     connection for a PDP context defined with the same command. UE supports
>     one WWAN adapter.
> 
> Signed-off-by: Bassem Boubaker 
Acked-by: Oliver Neukum 

[PATCH v6 1/4] Add notrace to lib/ucmpdi2.c

[Matt Redfearn]

From: Palmer Dabbelt 

As part of the MIPS conversion to use the generic GCC library routines,
Matt Redfearn discovered that I'd missed a notrace on __ucmpdi2().  This
patch rectifies the problem.

CC: Matt Redfearn 
CC: Antony Pavlov 
Signed-off-by: Palmer Dabbelt 
Reviewed-by: Matt Redfearn 
Signed-off-by: Matt Redfearn 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
  add notrace to lib/ucmpdi2.c

 lib/ucmpdi2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/ucmpdi2.c b/lib/ucmpdi2.c
index 25ca2d4c1e19..597998169a96 100644
--- a/lib/ucmpdi2.c
+++ b/lib/ucmpdi2.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 
-word_type __ucmpdi2(unsigned long long a, unsigned long long b)
+word_type notrace __ucmpdi2(unsigned long long a, unsigned long long b)
 {
const DWunion au = {.ll = a};
const DWunion bu = {.ll = b};
-- 
2.7.4

[PATCH] ide: hpt366: Replace mdelay with usleep_range in init_chipset_hpt366

[Jia-Ju Bai]

init_chipset_hpt366() is never called in atomic context.

init_chipset_hpt366() is set as ".init_chipset" in struct ide_port_info.
This function is not called in atomic context.

Despite never getting called from atomic context, init_chipset_hpt366()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/ide/hpt366.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ide/hpt366.c b/drivers/ide/hpt366.c
index 4b5dc01..4045559 100644
--- a/drivers/ide/hpt366.c
+++ b/drivers/ide/hpt366.c
@@ -984,7 +984,7 @@ static int init_chipset_hpt366(struct pci_dev *dev)
for (temp = i = 0; i < 128; i++) {
pci_read_config_word(dev, 0x78, _cnt);
temp += f_cnt & 0x1ff;
-   mdelay(1);
+   usleep_range(1000, 2000);
}
f_cnt = temp / 128;
} else
-- 
1.9.1

Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload

[Jia-Ju Bai]

On 2018/4/11 16:03, Greg KH wrote:

On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote:


On 2018/4/11 14:41, Greg KH wrote:

On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote:

stir421x_fw_upload() is never called in atomic context.

The call chain ending up at stir421x_fw_upload() is:
[1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe()

irda_usb_probe() is set as ".probe" in struct usb_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, stir421x_fw_upload()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
   drivers/staging/irda/drivers/irda-usb.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

Please, at the very least, work off of Linus's tree.  There is no
drivers/staging/irda/ anymore :)


Okay, sorry.
Could you please recommend me a right tree or its git address?

Have you looked in the MAINTAINERS file?  Worst case, always use
linux-next.

greg k-h


Oh, sorry, I did notice the git tree in the MAINTAINERS file.
I always used linux-stable.
Thanks for telling me this :)


Best wishes,
Jia-Ju Bai

[PATCH v1 2/2] mm: migrate: add vm event counters hugetlb_migrate_(success|fail)

[Naoya Horiguchi]

>From the same motivation as the previous patch, this patch is suggesting
to add separate counters for hugetlb migration.

Signed-off-by: Naoya Horiguchi 
---
 include/linux/vm_event_item.h |  3 +++
 mm/migrate.c  | 10 ++
 mm/vmstat.c   |  4 
 3 files changed, 17 insertions(+)

diff --git v4.16-mmotm-2018-04-10-17-02/include/linux/vm_event_item.h 
v4.16-mmotm-2018-04-10-17-02_patched/include/linux/vm_event_item.h
index fa2d2e0..24966ae 100644
--- v4.16-mmotm-2018-04-10-17-02/include/linux/vm_event_item.h
+++ v4.16-mmotm-2018-04-10-17-02_patched/include/linux/vm_event_item.h
@@ -62,6 +62,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
 #endif
 #ifdef CONFIG_HUGETLB_PAGE
HTLB_BUDDY_PGALLOC, HTLB_BUDDY_PGALLOC_FAIL,
+#ifdef CONFIG_MIGRATION
+   HTLB_MIGRATE_SUCCESS, HTLB_MIGRATE_FAIL,
+#endif
 #endif
UNEVICTABLE_PGCULLED,   /* culled to noreclaim list */
UNEVICTABLE_PGSCANNED,  /* scanned for reclaimability */
diff --git v4.16-mmotm-2018-04-10-17-02/mm/migrate.c 
v4.16-mmotm-2018-04-10-17-02_patched/mm/migrate.c
index 46ff23a..279b143 100644
--- v4.16-mmotm-2018-04-10-17-02/mm/migrate.c
+++ v4.16-mmotm-2018-04-10-17-02_patched/mm/migrate.c
@@ -1357,6 +1357,9 @@ enum migrate_result_type {
 
 enum migrate_page_type {
MIGRATE_PAGE_NORMAL,
+#ifdef CONFIG_HUGETLB_PAGE
+   MIGRATE_PAGE_HUGETLB,
+#endif
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
MIGRATE_PAGE_THP,
 #endif
@@ -1368,6 +1371,9 @@ static struct migrate_event {
int failed;
 } migrate_events[] = {
{ PGMIGRATE_SUCCESS,PGMIGRATE_FAIL },
+#ifdef CONFIG_HUGETLB_PAGE
+   { HTLB_MIGRATE_SUCCESS, HTLB_MIGRATE_FAIL },
+#endif
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
{ THP_MIGRATE_SUCCESS,  THP_MIGRATE_FAIL },
 #endif
@@ -1375,6 +1381,10 @@ static struct migrate_event {
 
 static inline enum migrate_page_type get_type(struct page *page)
 {
+#ifdef CONFIG_HUGETLB_PAGE
+   if (PageHuge(page))
+   return MIGRATE_PAGE_HUGETLB;
+#endif
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
if (PageTransHuge(page))
return MIGRATE_PAGE_THP;
diff --git v4.16-mmotm-2018-04-10-17-02/mm/vmstat.c 
v4.16-mmotm-2018-04-10-17-02_patched/mm/vmstat.c
index 57e9cc3..27a005f 100644
--- v4.16-mmotm-2018-04-10-17-02/mm/vmstat.c
+++ v4.16-mmotm-2018-04-10-17-02_patched/mm/vmstat.c
@@ -1236,6 +1236,10 @@ const char * const vmstat_text[] = {
 #ifdef CONFIG_HUGETLB_PAGE
"htlb_buddy_alloc_success",
"htlb_buddy_alloc_fail",
+#ifdef CONFIG_MIGRATION
+   "htlb_migrate_success",
+   "htlb_migrate_fail",
+#endif
 #endif
"unevictable_pgs_culled",
"unevictable_pgs_scanned",
-- 
2.7.0

[PATCH] cpuidle: menu: tidy up some indenting

[Dan Carpenter]

These lines were indented 4 spaces less than they should have been.  It
was a little confusing.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 1bfe03ceb236..b733dc6aa42b 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -426,8 +426,8 @@ static int menu_select(struct cpuidle_driver *drv, struct 
cpuidle_device *dev,
 * tick, so try to correct that.
 */
for (i = idx - 1; i >= 0; i--) {
-   if (drv->states[i].disabled ||
-   dev->states_usage[i].disable)
+   if (drv->states[i].disabled ||
+   dev->states_usage[i].disable)
continue;
 
idx = i;

Re: [PATCH] ARM: dts: sunxi: Change sun7i-a20-olimex-som204-evb to not use cd-inverted

[Maxime Ripard]

On Tue, Apr 10, 2018 at 05:51:19PM +0300, Tuomas Tynkkynen wrote:
> Commit 45e01f401a2a16 ("ARM: dts: sunxi: Switch MMC nodes away from
> cd-inverted property") changed most of the sunxi boards away from using
> the cd-inverted property in MMC nodes. However, the
> sun7i-a20-olimex-som204-evb board which got merged concurrently with
> that commit is now using cd-inverted. Switch it away from using
> cd-inverted to be consistent with rest of the sunxi boards.
> 
> Signed-off-by: Tuomas Tynkkynen 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH] pinctrl/samsung: Correct EINTG banks order

[Tomasz Figa]

2018-04-10 17:38 GMT+09:00 Tomasz Figa :
> 2018-04-10 16:06 GMT+09:00 Krzysztof Kozlowski :
>> On Sun, Apr 8, 2018 at 8:07 PM, Paweł Chmiel
>>  wrote:
>>> All banks with GPIO interrupts should be at beginning
>>> of bank array and without any other types of banks between them.
>>> This order is expected by exynos_eint_gpio_irq, when doing
>>> interrupt group to bank translation.
>>> Otherwise, kernel NULL pointer dereference would happen
>>> when trying to handle interrupt, due to wrong bank being looked up.
>>> Observed on s5pv210, when trying to handle gpj0 interrupt,
>>> where kernel was mapping it to gpi bank.
>>
>> Thanks for the patch. The issue looks real although one thing was
>> missed - there is a gap in SVC group between GPK2 and GPL0 (pointed by
>> Marek Szyprowski):
>>
>> 0x0 - EINT_23 - gpk0
>> 0x1 - EINT_24 - gpk1
>> 0x2 - EINT_25 - gpk2
>> 0x4 - EINT_27 - gpl0
>> 0x7 - EINT_8 - gpm0
>>
>> Maybe this should be done differently - to remove such hidden
>> requirement entirely in favor of another parameter of
>> EXYNOS_PIN_BANK_EINTG argument?
>
> Perhaps let's limit this patch to s5pv210 and Exynos5410 alone, where
> a simple swap of bank order in the arrays should be okay.
>
> We might also need to have some fixes on 4x12, because I noticed that
> in exynos4x12_pin_banks0[] there is a hole in eint_offsets between
> gpd1 and gpf0 and exynos4x12_pin_banks1[] starts with gpk0 that has
> eint_offset equal to 0x08 (not 0).

To close the loop, after talking offline and checking the
documentation, Exynos4x12 is fine, because the group numbers in SVC
register actually match what is defined in bank arrays.

Best regards,
Tomasz

Re: [PATCH 1/2] ide: pdc202xx_new: Replace mdelay with usleep_range in detect_pll_input_clock

[Jia-Ju Bai]

On 2018/4/11 16:33, Sergei Shtylyov wrote:

Hello!

On 4/11/2018 10:52 AM, Jia-Ju Bai wrote:


detect_pll_input_clock() is never called in atomic context.

detect_pll_input_clock() is only called by init_chipset_pdcnew(), which
is set as ".init_chipset" in struct ide_port_info.
This function is not called in atomic context.

Despite never getting called from atomic context, 
detect_pll_input_clock()

calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
  drivers/ide/pdc202xx_new.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c
index b33646b..6afa66d 100644
--- a/drivers/ide/pdc202xx_new.c
+++ b/drivers/ide/pdc202xx_new.c
@@ -258,7 +258,7 @@ static long detect_pll_input_clock(unsigned long 
dma_base)

  outb(scr1 | 0x40, dma_base + 0x03);
/* Let the counter run for 10 ms. */
-mdelay(10);
+usleep_range(10);


   This function takes 2 arguments.

[...]

MBR, Sergei


Oops, sorry for my fault.
Thanks for telling me this :)
I will modify it and send V2.


Best wishes,
Jia-Ju Bai

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Viresh Kumar]

On 05-04-18, 18:16, Daniel Lezcano wrote:
> The cpu idle cooling driver performs synchronized idle injection across all
> cpus belonging to the same cluster and offers a new method to cool down a SoC.
> 
> Each cluster has its own idle cooling device, each core has its own idle
> injection thread, each idle injection thread uses play_idle to enter idle.  In
> order to reach the deepest idle state, each cooling device has the idle
> injection threads synchronized together.
> 
> It has some similarity with the intel power clamp driver but it is actually
> designed to work on the ARM architecture via the DT with a mathematical proof
> with the power model which comes with the Documentation.
> 
> The idle injection cycle is fixed while the running cycle is variable. That
> allows to have control on the device reactivity for the user experience. At
> the mitigation point the idle threads are unparked, they play idle the
> specified amount of time and they schedule themselves. The last thread sets
> the next idle injection deadline and when the timer expires it wakes up all
> the threads which in turn play idle again. Meanwhile the running cycle is
> changed by set_cur_state.  When the mitigation ends, the threads are parked.
> The algorithm is self adaptive, so there is no need to handle hotplugging.
> 
> If we take an example of the balanced point, we can use the DT for the hi6220.
> 
> The sustainable power for the SoC is 3326mW to mitigate at 75°C. Eight cores
> running at full blast at the maximum OPP consumes 5280mW. The first value is
> given in the DT, the second is calculated from the OPP with the formula:
> 
>Pdyn = Cdyn x Voltage^2 x Frequency
> 
> As the SoC vendors don't want to share the static leakage values, we assume
> it is zero, so the Prun = Pdyn + Pstatic = Pdyn + 0 = Pdyn.
> 
> In order to reduce the power to 3326mW, we have to apply a ratio to the
> running time.
> 
> ratio = (Prun - Ptarget) / Ptarget = (5280 - 3326) / 3326 = 0,5874
> 
> We know the idle cycle which is fixed, let's assume 10ms. However from this
> duration we have to substract the wake up latency for the cluster idle state.
> In our case, it is 1.5ms. So for a 10ms latency for idle, we are really idle
> 8.5ms.
> 
> As we know the idle duration and the ratio, we can compute the running cycle.
> 
>running_cycle = 8.5 / 0.5874 = 14.47ms
> 
> So for 8.5ms of idle, we have 14.47ms of running cycle, and that brings the
> SoC to the balanced trip point of 75°C.
> 
> The driver has been tested on the hi6220 and it appears the temperature
> stabilizes at 75°C with an idle injection time of 10ms (8.5ms real) and
> running cycle of 14ms as expected by the theory above.
> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/Kconfig   |  10 +
>  drivers/thermal/cpu_cooling.c | 479 
> ++
>  include/linux/cpu_cooling.h   |   6 +
>  3 files changed, 495 insertions(+)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 5aaae1b..6c34117 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -166,6 +166,16 @@ config CPU_FREQ_THERMAL
> This will be useful for platforms using the generic thermal interface
> and not the ACPI interface.
>  
> +config CPU_IDLE_THERMAL
> +   bool "CPU idle cooling strategy"
> +   depends on CPU_IDLE
> +   help
> +  This implements the generic CPU cooling mechanism through
> +  idle injection.  This will throttle the CPU by injecting
> +  fixed idle cycle.  All CPUs belonging to the same cluster
> +  will enter idle synchronously to reach the deepest idle
> +  state.
> +
>  endchoice
>  
>  config CLOCK_THERMAL
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 5c219dc..1eec8d6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -10,18 +10,33 @@
>   *   Viresh Kumar 
>   *
>   */
> +#define pr_fmt(fmt) "CPU cooling: " fmt
> +
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> +#include 

What part of the code is using this one ?

> +

Why add above 2 blank lines ?

> +#include 
> +#include 
> +
>  #include 
>  
> +#include 
> +
>  #ifdef CONFIG_CPU_FREQ_THERMAL
>  /*
>   * Cooling state <-> CPUFreq frequency
> @@ -928,3 +943,467 @@ void cpufreq_cooling_unregister(struct 
> thermal_cooling_device *cdev)
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_cooling_unregister);
>  #endif /* CONFIG_CPU_FREQ_THERMAL */
> +
> +#ifdef CONFIG_CPU_IDLE_THERMAL
> +/**
> + * struct cpuidle_cooling_device - data for the idle cooling device
> + * @cdev: a pointer to a struct thermal_cooling_device
> + * @cpumask: a cpumask containing the CPU managed by the cooling 

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Boris Brezillon]

On Wed, 11 Apr 2018 10:27:46 +0200
Ladislav Michl  wrote:

> On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote:
> > On Wed, 11 Apr 2018 09:36:56 +0200
> > Ladislav Michl  wrote:
> >   
> > > Hi Boris,
> > > 
> > > On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:  
> [...]
> > > > Not sure this approach is safe on all archs: if the cache is VIVT or
> > > > VIPT, you may have several entries pointing to the same phys page, and
> > > > then, when dma_map_page() does its cache maintenance operations, it's
> > > > only taking one of these entries into account.
> > > 
> > > Hmm, I used the same approach Samsung OneNAND driver does since commit
> > > dcf08227e964a53a2cb39130b74842c7dcb6adde.
> > > Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> > > is VIPT. In that case samsung's driver code has the same problem.
> > >   
> > > > In other parts of the MTD subsystem, we tend to not do DMA on buffers
> > > > that have been vmalloc-ed.
> > > > 
> > > > You can do something like
> > > > 
> > > > if (virt_addr_valid(buf))
> > > > /* Use DMA */
> > > > else
> > > > /*
> > > >  * Do not use DMA, or use a bounce buffer
> > > >  * allocated with kmalloc
> > > >  */
> > > 
> > > Okay, I'll use this approach then, but first I'd like to be sure above is
> > > correct. Anyone?  
> > 
> > See this discussion [1]. The problem came up a few times already, so
> > might find other threads describing why it's not safe.
> > 
> > [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html 
> >  
> 
> Question was more likely whenever there might exist more that one mapping
> of the same page.

I'm clearly not an expert, so I might be wrong, but I think a physical
page can be both in the identity mapping and mapped in the vmalloc
space. Now, is there a real risk that both ends are accessed in
parallel thus making different cache entries pointing to the same phys
page dirty, I'm not sure. Or maybe there are other corner case, but
you'll have to ask Russell (or any other ARM expert) to get a clearer
answer.

> But okay, I'll disable DMA for highmem. Patch will follow.
> 
>   ladis

3 version of MKDEV: kernel, uapi, libc, why?

[Zhang, Ning A]

Hi, Greg, Thomas

I find 3 version of MKDEV (actually 2 + makedev)

in include/linux/kdev_t.h

#define MINORBITS   20
#define MKDEV(ma,mi)(((ma) << MINORBITS) | (mi))

in inlcude/uapi/linux/kdev_t.h

#define MKDEV(ma,mi)((ma)<<8 | (mi))

in Android bionic

#define makedev(__major, __minor) \
  ( \
(((__major) & 0xf000ULL) << 32) | (((__major) & 0xfffULL) <<
8) | \
(((__minor) & 0xff00ULL) << 12) | (((__minor) & 0xffULL)) \
  )

if I use mknod("renderD128", S_IFCHR|0666, MKDEV(226, 128));
I get wrong device:
crw-rw-rw- 1 root graphics 0, 57984 2011-11-11 11:20 renderD128


if I use ("renderD128",S_IFCHR|0666, makedev(226, 128));
I get right device.

but, when I use: mknod("card0", S_IFCHR|0666, MKDEV(226, 0));
I can get right device.

BR.
Ning.

Re: [PATCH v3 7/7] cpuidle/drivers/cpuidle-arm: Register the cooling device

[Viresh Kumar]

On 05-04-18, 18:16, Daniel Lezcano wrote:
> Register the ARM generic cpuidle driver as a cooling device.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/cpuidle/cpuidle-arm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
> index ddee1b6..44b4fe3 100644
> --- a/drivers/cpuidle/cpuidle-arm.c
> +++ b/drivers/cpuidle/cpuidle-arm.c
> @@ -11,6 +11,7 @@
>  
>  #define pr_fmt(fmt) "CPUidle arm: " fmt
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -172,6 +173,8 @@ static int __init arm_idle_init(void)
>   goto out_fail;
>   }
>  
> + cpuidle_cooling_register();
> +
>   return 0;
>  
>  out_fail:

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] MAINTAINERS: Update ASPEED entry with details

[Arnd Bergmann]

On Wed, Apr 11, 2018 at 6:06 AM, Joel Stanley  wrote:
> Hey Arnd,
>
> On 22 February 2018 at 15:33, Joel Stanley  wrote:
>> I am interested in all ASPEED drivers, and the previous match wasn't
>> grabbing files in nested directories. Use N instead.
>>
>> Add the arm kernel mailing list so that patches get reviewed there, and
>> the linux-aspeed list which exists only so I can use patchwork to track
>> patches.
>>
>> Add Andrew as a reviewer, because he is involved in reviewing ASPEED
>> stuff.
>>
>> Signed-off-by: Joel Stanley 
>
> can you please pick this one up? It would be great to get it into
> fixes as Andrew and I have been missing being cc'd on stuff we would
> have like to review.

Sure, applied to the fixes branch now.

In general, when you want a patch to be applied, please send it to
a...@kernel.org so we know it's for us. As a rule, I don't pick up patches
otherwise but assume that you are asking for feedback and/or Acks
but will resend it once everyone is happy with the change.

  Arnd

Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client

[Vinod Koul]

On Mon, Apr 02, 2018 at 04:09:02PM +0530, Radhey Shyam Pandey wrote:

> +
> + if (chan->xdev->has_axieth_connected) {
> + seg = list_first_entry(>segments,
> + struct xilinx_axidma_tx_segment, node);
> + if (cb.callback_param) {
> + app_w = (u32 *) cb.callback_param;

why are you interpreting callback_param? This is plainly wrong.
we do not know what is the interpretation of callback_param and it is
internal to submitter.

What exactly is the problem you are trying to solve?

> + hw = >hw;
> + *app_w = hw->status & XILINX_DMA_MAX_TRANS_LEN;
> + memcpy(app_w, hw->app, sizeof(u32) *
> + XILINX_DMA_NUM_APP_WORDS);
> + }

-- 
~Vinod

[PATCH v3 0/2] vfio: platform: Improve reset support

[Geert Uytterhoeven]

Hi all,

This patch series improves reset support for vfio-platform:
  - The first patch fixes a bug I ran into while working on this.
  - The second patch implements generic DT reset controller support, for
devices that are connected to an SoC-internal reset controller and
can be reset in a generic way.  This avoids having to write/change a
vfio-specific reset driver for each and every device to be
passed-through to a guest.

Changes compared to v2:
  - Add Reviewed-by,
  - Merge similar checks in vfio_platform_has_reset().

Changes compared to v1:
  - Add Reviewed-by,
  - Don't store error values in vdev->reset_control,
  - Use of_reset_control_get_exclusive() instead of
__of_reset_control_get(),
  - Improve description.

This has been tested on R-Car H3/Salvator-XS by exporting a GPIO module
to a QEMU+KWM guest: the GPIO module is reset before QEMU opens the vfio
device, and reset again after QEMU has released it, as can be witnessed
by the LEDs connected to the GPIOs.

Thanks!

Geert Uytterhoeven (2):
  vfio: platform: Fix reset module leak in error path
  vfio: platform: Add generic DT reset support

 drivers/vfio/platform/vfio_platform_common.c  | 35 +--
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 29 insertions(+), 7 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: AMD graphics performance regression in 4.15 and later

[Christian König]

Am 11.04.2018 um 06:00 schrieb Gabriel C:

2018-04-09 11:42 GMT+02:00 Christian König :

Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:

Hi Christian,

Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.

One last question: right now I'm running 4.15.0 with the "offending"
patch reverted. Is that safe to run or are there possible bad
interactions with other changes.


That should work without problems.

But I just had another idea as well, if you want you could still test the
new code path which will be using in 4.17.


While Firefox may do some strange things is not about only Firefox.

With your patches my EPYC box is unusable with  4.15++ kernels.
The whole Desktop is acting weird.  This one is using
an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.

Box is  2 * EPYC 7281 with 128 GB ECC RAM

Also a 14C Xeon box with a HD7700 is broken same way.


The hardware is irrelevant for this. We need to know what software stack 
you use on top of it.


E.g. desktop environment/Mesa and DDX version etc...



Everything breaks in X .. scrolling , moving windows , flickering etc.


reverting f4c809914a7c3e4a59cf543da6c2a15d0f75ee38 and
648bc3574716400acc06f99915815f80d9563783
from an 4.15 kernel makes things work again.



Backporting all the detection logic is to invasive, but you could just go
into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other
code path.

Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.


Well you really can't be serious about these suggestions ? Are you ?

Telling peoples to #if 0 random code is not a solution.


That is for testing and not a permanent solution.


You broke existsing working userland with your patches and at least
please fix that for 4.16.

I can help testing code for 4.17/++ if you wish but that is *different* storry.


Please test Alex's amd-staging-drm-next branch from 
git://people.freedesktop.org/~agd5f/linux.


Regards,
Christian.



Regards,

Gabriel C

Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release

[Alexandru Moise]

On Mon, Apr 09, 2018 at 03:09:38PM -0700, Tejun Heo wrote:
> (cc'ing Joseph as he worked on the area recently, hi!)
> 
> Hello,
> 
> On Sat, Apr 07, 2018 at 12:21:48PM +0200, Alexandru Moise wrote:
> > The q->id is used as an index within the blkg_tree radix tree.
> > 
> > If the entry is not released before reclaiming the blk_queue_ida's id
> > blkcg_init_queue() within a different driver from which this id
> > was originally for can fail due to the entry at that index within
> > the radix tree already existing.
> > 
> > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
> > ---
> > v2: Added no-op for !CONFIG_BLK_CGROUP
> > 
> >  block/blk-cgroup.c | 2 +-
> >  block/blk-sysfs.c  | 4 
> >  include/linux/blk-cgroup.h | 3 +++
> >  3 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> > index 1c16694ae145..224e937dbb59 100644
> > --- a/block/blk-cgroup.c
> > +++ b/block/blk-cgroup.c
> > @@ -369,7 +369,7 @@ static void blkg_destroy(struct blkcg_gq *blkg)
> >   *
> >   * Destroy all blkgs associated with @q.
> >   */
> > -static void blkg_destroy_all(struct request_queue *q)
> > +void blkg_destroy_all(struct request_queue *q)
> >  {
> > struct blkcg_gq *blkg, *n;
> >  
> > diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
> > index d00d1b0ec109..a72866458f22 100644
> > --- a/block/blk-sysfs.c
> > +++ b/block/blk-sysfs.c
> > @@ -816,6 +816,10 @@ static void __blk_release_queue(struct work_struct 
> > *work)
> > if (q->bio_split)
> > bioset_free(q->bio_split);
> >  
> > +   spin_lock_irq(q->queue_lock);
> > +   blkg_destroy_all(q);
> > +   spin_unlock_irq(q->queue_lock);
> > +
> > ida_simple_remove(_queue_ida, q->id);
> > call_rcu(>rcu_head, blk_free_queue_rcu);
> 
> But we already do this through calling blkcg_exit_queue() from
> __blk_release_queue().  What's missing?

Hi,

It might be the jetlag but I can't see how you end up calling
blkcg_exit_queue() from __blk_release_queue().

As I see it the only way to reach blkcg_exit_queue() is from
blk_cleanup_queue(), which I don't see anywhere in __blk_release_queue().

I suspect that I'm just fixing a corner case though and
the general case is what you describe or similar.

../Alex
> 
> Thanks.
> 
> -- 
> tejun

Re: [PATCH][v2] tools/power turbostat: if --max_loop, print for specific time of loops

[Yu Chen]

On Wed, Apr 11, 2018 at 12:29:04PM +0300, Artem Bityutskiy wrote:
> On Tue, 2018-04-10 at 22:51 +0800, Yu Chen wrote:
> > +   case 't':
> > +   {
> > +   int loops = strtod(optarg, NULL);
> > +
> > +   if (loops <= 0) {
> > +   fprintf(outf, "loops %d should be 
> > positive number\n",
> > +   iterations);
> > +   exit(2);
> > +   }
> > +   iterations = loops;
> > +   }
> 
> What is the point of the additional {} scope and the 'loops' variable
> in it? You could use the 'iterations' variable directly and simplify
> the code.
Got your point, will change it.
> 
> Artem.

Re: [PATCH 1/4] eeprom: at24: don't assign the i2c ID table to at24_driver

[Peter Rosin]

On 2018-04-11 12:09, Bartosz Golaszewski wrote:
> 2018-04-11 11:56 GMT+02:00 Peter Rosin :
>> On 2018-04-10 15:12, Bartosz Golaszewski wrote:
>>> We switched to using probe_new(), so this is no longer used
>>> by i2c core.
>>
>> It seems to be used in i2c_device_match() ???
>>
>> This could easily be me not understanding something...
>>
> 
> Yes, but i2c core no longer uses the id_table field in struct
> i2c_driver. We call i2c_device_match() ourselves instead of letting
> i2c core do it and pass the driver data to probe().
> 
> Hope that helps,
> Bartosz
> 

But, i2c_device_match is a static function in the core. I think you
are confusing it with i2c_match_id, which is in fact called from
the static i2c_device_match (with is a bus operation).

So, no, it didn't really help...

Cheers,
Peter

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

[Peter Zijlstra]

On Tue, Apr 10, 2018 at 06:05:46PM -0400, Steven Rostedt wrote:
> 
> Peter,
> 
> Going through my inbox, I stumbled across this one. And it doesn't
> appear to be addressed.
> 
> I think this patch is a reasonable solution.

Urgh, yeah, also seem to have forgotten about it. The proposed solution
is in fact simpler than the existing code. Also, I think deadline.c has
the exact same problem.

Zhou, could you respin and fix both?

Re: [PATCH 4.15/4.16 150/168] net_sched: fix a missing idr_remove() in u32_delete_key()

[admin]

W dniu 2018-04-11 00:24, Greg Kroah-Hartman napisał(a):
4.15-stable review patch.  If anyone has any objections, please let me 
know.


--

From: Cong Wang 


[ Upstream commit f12c643209db0626f2f54780d86bb93bfa7a9c2d ]

When we delete a u32 key via u32_delete_key(), we forget to
call idr_remove() to remove its handle from IDR.

Fixes: e7614370d6f0 ("net_sched: use idr to allocate u32 filter 
handles")

Reported-by: Marcin Kabiesz 
Tested-by: Marcin Kabiesz 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/sched/cls_u32.c |1 +
 1 file changed, 1 insertion(+)

--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -478,6 +478,7 @@ static int u32_delete_key(struct tcf_pro
RCU_INIT_POINTER(*kp, key->next);

tcf_unbind_filter(tp, >res);
+   idr_remove(>handle_idr, key->handle);
tcf_exts_get_net(>exts);
call_rcu(>rcu, u32_delete_key_freepf_rcu);
return 0;


Hello,
Thank you for the correction. If you had a problem or was not sure, 
please speak. I will try to test new changes or give relevant 
information on how to best test this. I have experience in this because 
I am currently working on the configuration of routers and in this cut 
QoS band.


Thank you again for making the correction.  :)

Best Regards
Marcin Kabiesz

Re: [PATCH] tty: ipwireless: Replace GFP_ATOMIC with GFP_KERNEL in ipwireless_network_create

[David Sterba]

On Tue, Apr 10, 2018 at 04:31:46PM +0800, Jia-Ju Bai wrote:
> ipwireless_network_create() is never called in atomic context.
> 
> The call chain ending up at ipwireless_network_create() is:
> [1] ipwireless_network_create() <- config_ipwireless() <- 
>   ipwireless_attach()
> ipwireless_attach() is only set as ".probe" in struct pcmcia_driver.
> 
> Despite never getting called from atomic context,
> ipwireless_network_create() calls kzalloc() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of sucessful allocation.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 

Reviewed-by: David Sterba 

We don't have any other patches queued for this driver so it would be
best if this patch goes via net or Greg's tree.

Re: [PATCH] KVM: X86: fix incorrect reference of trace_kvm_pi_irte_update

[Paolo Bonzini]

On 11/04/2018 09:16, hu huajun wrote:
> In arch/x86/kvm/trace.h, this function is declared as host_irq the
> first input, and vcpu_id the second, instead of otherwise.
> 
> Signed-off-by: hu huajun 
> ---
>  arch/x86/kvm/svm.c | 5 ++---
>  arch/x86/kvm/vmx.c | 2 +-
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index be9c839..f4e9fb4 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -5118,9 +5118,8 @@ static int svm_update_pi_irte(struct kvm *kvm, unsigned 
> int host_irq,
>   }
>  
>   if (!ret && svm) {
> - trace_kvm_pi_irte_update(svm->vcpu.vcpu_id,
> -  host_irq, e->gsi,
> -  vcpu_info.vector,
> + trace_kvm_pi_irte_update(host_irq, svm->vcpu.vcpu_id,
> +  e->gsi, vcpu_info.vector,
>vcpu_info.pi_desc_addr, set);
>   }
>  
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index f0fd50b..86fd775 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -12204,7 +12204,7 @@ static int vmx_update_pi_irte(struct kvm *kvm, 
> unsigned int host_irq,
>   vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
>   vcpu_info.vector = irq.vector;
>  
> - trace_kvm_pi_irte_update(vcpu->vcpu_id, host_irq, e->gsi,
> + trace_kvm_pi_irte_update(host_irq, vcpu->vcpu_id, e->gsi,
>   vcpu_info.vector, vcpu_info.pi_desc_addr, set);
>  
>   if (set)
> 

Applied, thanks!

Paolo

Re: simultaneous voice/data works (was Re: call/normal switch was Re: omap4-droid4: voice call support was)

[Pavel Machek]

On Tue 2018-04-10 06:50:29, Tony Lindgren wrote:
> * Pavel Machek  [180410 11:00]:
> > On Mon 2018-04-09 07:08:47, Tony Lindgren wrote:
> > > * Dan Williams  [180408 02:46]:
> > > > On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote:
> > > > > I tried --location-enable-gps-unmanaged , but that did not work for
> > > > > me.
> > > > 
> > > > That requires a TTY that would spit out the GPS data; in this mode MM
> > > > only sends the start/stop commands, and what comes out the GPS TTY is
> > > > undefined (at least by MM).
> > > > 
> > > > So unless you know that one of the 6600's TTYs does GPS and in what
> > > > format it does GPS, then no.
> > > 
> > > There should be a NMEA port within the unknown port range ttyUSB[123].
> > > 
> > > Is there some easy way to enable --location-enable-gps-unmanaged for
> > > testing so I can check if GPS gets enabled for one of the ports?
> > 
> > This should be userful for testing:
> > 
> > Just pass --pds-start-gps and you should get NMEA on stdout.
> 
> Hmm maybe also try to check if enabling the GPS this way starts
> printing something out of /dev/ttyUSB[123]?

No, I did not find anything there :-(.

This combination seems to give me working gps:

sudo src/qmicli/qmicli -d /dev/cdc-wdm0 --pds-start-gps | nc -u 127.0.0.1 5000

/usr/sbin/gpsd -ND 4 udp://127.0.0.1:5000

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] net: dsa: b53: Replace mdelay with msleep in b53_switch_reset_gpio

[Jia-Ju Bai]

On 2018/4/11 13:30, Phil Reid wrote:

On 11/04/2018 09:51, Jia-Ju Bai wrote:

b53_switch_reset_gpio() is never called in atomic context.

The call chain ending up at b53_switch_reset_gpio() is:
[1] b53_switch_reset_gpio() <- b53_switch_reset() <-
b53_reset_switch() <- b53_setup()

b53_switch_reset_gpio() is set as ".setup" in struct dsa_switch_ops.
This function is not called in atomic context.

Despite never getting called from atomic context, 
b53_switch_reset_gpio()

calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/dsa/b53/b53_common.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c 
b/drivers/net/dsa/b53/b53_common.c

index 274f367..e070ff6 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -597,10 +597,10 @@ static void b53_switch_reset_gpio(struct 
b53_device *dev)

  /* Reset sequence: RESET low(50ms)->high(20ms)
   */
  gpio_set_value(gpio, 0);
-mdelay(50);
+msleep(50);
gpio_set_value(gpio, 1);
-mdelay(20);
+msleep(20);
dev->current_page = 0xff;
  }


Would that also imply gpio_set_value could be gpio_set_value_cansleep?



Yes, I think gpio_set_value_cansleep() is okay here?
Do I need to send a V2 patch to replace gpio_set_value()?


Best wishes,
Jia-Ju Bai

[PATCH v8 1/6] arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID

[Jia He]

Make CONFIG_HAVE_MEMBLOCK_PFN_VALID a config option so it can move
memblock_next_valid_pfn to generic code file.

arm/arm64 can benefit from this booting time improvement.

Signed-off-by: Jia He 
---
 arch/arm/Kconfig   | 4 
 arch/arm64/Kconfig | 4 
 mm/Kconfig | 3 +++
 3 files changed, 11 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 51c8df5..77bc1bb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1637,6 +1637,10 @@ config ARCH_SELECT_MEMORY_MODEL
 config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
 
+config HAVE_MEMBLOCK_PFN_VALID
+   def_bool y
+   depends on HAVE_ARCH_PFN_VALID
+
 config HAVE_GENERIC_GUP
def_bool y
depends on ARM_LPAE
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c9a7e9e..f374203 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -747,6 +747,10 @@ config ARCH_SELECT_MEMORY_MODEL
 config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
 
+config HAVE_MEMBLOCK_PFN_VALID
+   def_bool y
+   depends on HAVE_ARCH_PFN_VALID
+
 config HW_PERF_EVENTS
def_bool y
depends on ARM_PMU
diff --git a/mm/Kconfig b/mm/Kconfig
index c782e8f..c53ac38 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -137,6 +137,9 @@ config HAVE_MEMBLOCK_NODE_MAP
 config HAVE_MEMBLOCK_PHYS_MAP
bool
 
+config HAVE_MEMBLOCK_PFN_VALID
+   bool
+
 config HAVE_GENERIC_GUP
bool
 
-- 
2.7.4

[PATCH v8 2/6] mm: page_alloc: remain memblock_next_valid_pfn() on arm/arm64

[Jia He]

Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.

But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.

On arm and arm64, memblock is used by default. But generic version of
pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
not always return the next valid one but skips more resulting in some
valid frames to be skipped (as if they were invalid). And that's why
kernel was eventually crashing on some !arm machines.

And as verified by Eugeniu Rosca, arm can benifit from commit
b92df1de5d28. So remain the memblock_next_valid_pfn on arm/arm64 and
move the related codes to one file include/linux/arm96_common.h

Suggested-by: Daniel Vacek 
Signed-off-by: Jia He 
---
 arch/arm/mm/init.c|  1 +
 arch/arm64/mm/init.c  |  1 +
 include/linux/early_pfn.h | 34 ++
 include/linux/mmzone.h| 11 +++
 mm/page_alloc.c   |  5 -
 5 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/early_pfn.h

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index a1f11a7..de225a2 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 00e7b90..913c327 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/include/linux/early_pfn.h b/include/linux/early_pfn.h
new file mode 100644
index 000..1b001c7
--- /dev/null
+++ b/include/linux/early_pfn.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2018 HXT-semitech Corp. */
+#ifndef __EARLY_PFN_H
+#define __EARLY_PFN_H
+#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
+ulong __init_memblock memblock_next_valid_pfn(ulong pfn)
+{
+   struct memblock_type *type = 
+   unsigned int right = type->cnt;
+   unsigned int mid, left = 0;
+   phys_addr_t addr = PFN_PHYS(++pfn);
+
+   do {
+   mid = (right + left) / 2;
+
+   if (addr < type->regions[mid].base)
+   right = mid;
+   else if (addr >= (type->regions[mid].base +
+ type->regions[mid].size))
+   left = mid + 1;
+   else {
+   /* addr is within the region, so pfn is valid */
+   return pfn;
+   }
+   } while (left < right);
+
+   if (right == type->cnt)
+   return -1UL;
+   else
+   return PHYS_PFN(type->regions[right].base);
+}
+EXPORT_SYMBOL(memblock_next_valid_pfn);
+#endif /*CONFIG_HAVE_MEMBLOCK_PFN_VALID*/
+#endif /*__EARLY_PFN_H*/
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d797716..c40297d 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1245,6 +1245,8 @@ static inline int pfn_valid(unsigned long pfn)
return 0;
return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
 }
+
+#define next_valid_pfn(pfn)(pfn + 1)
 #endif
 
 static inline int pfn_present(unsigned long pfn)
@@ -1270,6 +1272,10 @@ static inline int pfn_present(unsigned long pfn)
 #endif
 
 #define early_pfn_valid(pfn)   pfn_valid(pfn)
+#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
+extern ulong memblock_next_valid_pfn(ulong pfn);
+#define next_valid_pfn(pfn)memblock_next_valid_pfn(pfn)
+#endif
 void sparse_init(void);
 #else
 #define sparse_init()  do {} while (0)
@@ -1291,6 +1297,11 @@ struct mminit_pfnnid_cache {
 #define early_pfn_valid(pfn)   (1)
 #endif
 
+/* fallback to default defitions*/
+#ifndef next_valid_pfn
+#define next_valid_pfn(pfn)(pfn + 1)
+#endif
+
 void memory_present(int nid, unsigned long start, unsigned long end);
 unsigned long __init node_memmap_size_bytes(int, unsigned long, unsigned long);
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c19f5ac..bab8e1a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5483,8 +5483,11 @@ void __meminit memmap_init_zone(unsigned long size, int 
nid, unsigned long zone,
if (context != MEMMAP_EARLY)
goto not_early;
 
-   if (!early_pfn_valid(pfn))
+   if (!early_pfn_valid(pfn)) {
+   pfn = next_valid_pfn(pfn) - 1;
continue;
+   }
+
if (!early_pfn_in_nid(pfn, nid))
continue;
if (!update_defer_init(pgdat, pfn, end_pfn, _initialised))
-- 
2.7.4

[PATCH v8 4/6] mm/memblock: introduce memblock_search_pfn_regions()

[Jia He]

This api is to find the memory region index of input pfn. With this
helper, we can improve the loop in early_pfn_valid by recording last
region index. If current pfn and last pfn are in the same memory
region, we needn't do the unnecessary binary searches because the
result of memblock_is_nomap is the same for whole memory region.

Signed-off-by: Jia He 
---
 include/linux/memblock.h | 2 ++
 mm/memblock.c| 9 +
 2 files changed, 11 insertions(+)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 0257aee..a0127b3 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -203,6 +203,8 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned long 
*out_start_pfn,
 i >= 0; __next_mem_pfn_range(, nid, p_start, p_end, p_nid))
 #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 
+int memblock_search_pfn_regions(unsigned long pfn);
+
 /**
  * for_each_free_mem_range - iterate through free memblock areas
  * @i: u64 used as loop variable
diff --git a/mm/memblock.c b/mm/memblock.c
index ba7c878..0f4004c 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1617,6 +1617,15 @@ static int __init_memblock memblock_search(struct 
memblock_type *type, phys_addr
return -1;
 }
 
+/* search memblock with the input pfn, return the region idx */
+int __init_memblock memblock_search_pfn_regions(unsigned long pfn)
+{
+   struct memblock_type *type = 
+   int mid = memblock_search(type, PFN_PHYS(pfn));
+
+   return mid;
+}
+
 bool __init memblock_is_reserved(phys_addr_t addr)
 {
return memblock_search(, addr) != -1;
-- 
2.7.4

[PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64

[Jia He]

Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") tried to optimize the loop in memmap_init_zone(). But
there is still some room for improvement.

Patch 1 introduce new config to make codes more generic
Patch 2 remain the memblock_next_valid_pfn on arm and arm64
Patch 3 optimizes the memblock_next_valid_pfn()
Patch 4~6 optimizes the early_pfn_valid()

As for the performance improvement, after this set, I can see the time
overhead of memmap_init() is reduced from 41313 us to 24389 us in my
armv8a server(QDF2400 with 96G memory).

Without this patchset:
[  117.113677] before memmap_init
[  117.118195] after  memmap_init
>>> memmap_init takes 4518 us
[  117.121446] before memmap_init
[  117.154992] after  memmap_init
>>> memmap_init takes 33546 us
[  117.158241] before memmap_init
[  117.161490] after  memmap_init
>>> memmap_init takes 3249 us
>>> totally takes 41313 us

With this patchset:
[  123.222962] before memmap_init
[  123.226819] after  memmap_init
>>> memmap_init takes 3857
[  123.230070] before memmap_init
[  123.247354] after  memmap_init
>>> memmap_init takes 17284
[  123.250604] before memmap_init
[  123.253852] after  memmap_init
>>> memmap_init takes 3248
>>> totally takes 24389 us

Attached the memblock region information in my server.
[   86.956758] Zone ranges:
[   86.959452]   DMA  [mem 0x0020-0x]
[   86.966041]   Normal   [mem 0x0001-0x0017]
[   86.972631] Movable zone start for each node
[   86.977179] Early memory node ranges
[   86.980985]   node   0: [mem 0x0020-0x0021]
[   86.987666]   node   0: [mem 0x0082-0x0307]
[   86.994348]   node   0: [mem 0x0308-0x0308]
[   87.001029]   node   0: [mem 0x0309-0x031f]
[   87.007710]   node   0: [mem 0x0320-0x033f]
[   87.014392]   node   0: [mem 0x0341-0x0563]
[   87.021073]   node   0: [mem 0x0564-0x0567]
[   87.027754]   node   0: [mem 0x0568-0x056d]
[   87.034435]   node   0: [mem 0x056e-0x086f]
[   87.041117]   node   0: [mem 0x0870-0x0871]
[   87.047798]   node   0: [mem 0x0872-0x0894]
[   87.054479]   node   0: [mem 0x0895-0x08ba]
[   87.061161]   node   0: [mem 0x08bb-0x08bc]
[   87.067842]   node   0: [mem 0x08bd-0x08c4]
[   87.074524]   node   0: [mem 0x08c5-0x08e2]
[   87.081205]   node   0: [mem 0x08e3-0x08e4]
[   87.087886]   node   0: [mem 0x08e5-0x08fc]
[   87.094568]   node   0: [mem 0x08fd-0x0910]
[   87.101249]   node   0: [mem 0x0911-0x092e]
[   87.107930]   node   0: [mem 0x092f-0x0930]
[   87.114612]   node   0: [mem 0x0931-0x0963]
[   87.121293]   node   0: [mem 0x0964-0x0e61]
[   87.127975]   node   0: [mem 0x0e62-0x0e64]
[   87.134657]   node   0: [mem 0x0e65-0x0fff]
[   87.141338]   node   0: [mem 0x1080-0x17fe]
[   87.148019]   node   0: [mem 0x1c00-0x1c00]
[   87.154701]   node   0: [mem 0x1c01-0x1c7f]
[   87.161383]   node   0: [mem 0x1c81-0x7efb]
[   87.168064]   node   0: [mem 0x7efc-0x7efd]
[   87.174746]   node   0: [mem 0x7efe-0x7efe]
[   87.181427]   node   0: [mem 0x7eff-0x7eff]
[   87.188108]   node   0: [mem 0x7f00-0x0017]
[   87.194791] Initmem setup node 0 [mem 0x0020-0x0017]

Changelog:
V8: - introduce new config and move generic code to early_pfn.h
- optimize memblock_next_valid_pfn as suggested by Matthew Wilcox
V7: - fix i386 compilation error. refine the commit description
V6: - simplify the codes, move arm/arm64 common codes to one file.
- refine patches as suggested by Danial Vacek and Ard Biesheuvel
V5: - further refining as suggested by Danial Vacek. Make codes
  arm/arm64 more arch specific
V4: - refine patches as suggested by Danial Vacek and Wei Yang
- optimized on arm besides arm64
V3: - fix 2 issues reported by kbuild test robot
V2: - rebase to mmotm latest
- remain memblock_next_valid_pfn on arm64
- refine memblock_search_pfn_regions and pfn_valid_region

Jia He (6):
  arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID
  mm: page_alloc: remain memblock_next_valid_pfn() on arm/arm64
  arm: arm64: page_alloc: reduce unnecessary binary search in
memblock_next_valid_pfn()
  mm/memblock: introduce memblock_search_pfn_regions()
  arm: arm64: introduce pfn_valid_region()
  mm: page_alloc: reduce 

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Simon Horman]

On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> fix this user (until a better, system-wide solution is in place).
> 
> Signed-off-by: Wolfram Sang 
> Acked-by: Daniel Thompson 

Reviewed-by: Simon Horman 

> ---
> 
> Changes since V1:
>   * rebased to top-of-linus-tree
>   * added tag from Daniel, thanks!
> 
> Through which tree does this need to go?
> 
>  drivers/video/backlight/pwm_bl.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index 1c2289ddd555..0fa7d2bd0e48 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
>  
>   /*
>* If the GPIO is not known to be already configured as output, that
> -  * is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
> -  * change the direction to output and set the GPIO as active.
> +  * is, if gpiod_get_direction returns either 1 or -EINVAL, change the
> +  * direction to output and set the GPIO as active.
>* Do not force the GPIO to active when it was already output as it
>* could cause backlight flickering or we would enable the backlight too
>* early. Leave the decision of the initial backlight state for later.
>*/
>   if (pb->enable_gpio &&
> - gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
> + gpiod_get_direction(pb->enable_gpio) != 0)
>   gpiod_direction_output(pb->enable_gpio, 1);
>  
>   pb->power_supply = devm_regulator_get(>dev, "power");
> -- 
> 2.11.0
> 

[PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

[Jia-Ju Bai]

i40iw_add_mqh_4() is never called in atomic context, because it 
calls rtnl_lock() that can sleep.

Despite never getting called from atomic context,
i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c 
b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 5230dd3..4e79af5 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -1758,7 +1758,7 @@ static enum i40iw_status_code i40iw_add_mqh_4(
>ifa_address,
rdma_vlan_dev_vlan_id(dev),
dev->dev_addr);
-   child_listen_node = 
kzalloc(sizeof(*child_listen_node), GFP_ATOMIC);
+   child_listen_node = 
kzalloc(sizeof(*child_listen_node), GFP_KERNEL);

cm_parent_listen_node->cm_core->stats_listen_nodes_created++;
i40iw_debug(>sc_dev,
I40IW_DEBUG_CM,
-- 
1.9.1

[PATCH 3/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_l2param_change

[Jia-Ju Bai]

i40iw_l2param_change() is never called in atomic context.

i40iw_make_listen_node() is only set as ".l2_param_change" 
in struct i40e_client_ops, and this function pointer is not called 
in atomic context.

Despite never getting called from atomic context,
i40iw_l2param_change() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/infiniband/hw/i40iw/i40iw_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_main.c 
b/drivers/infiniband/hw/i40iw/i40iw_main.c
index 27590ae..b86bda8 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_main.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_main.c
@@ -1737,7 +1737,7 @@ static void i40iw_l2param_change(struct i40e_info *ldev, 
struct i40e_client *cli
return;
 
 
-   work = kzalloc(sizeof(*work), GFP_ATOMIC);
+   work = kzalloc(sizeof(*work), GFP_KERNEL);
if (!work)
return;
 
-- 
1.9.1

[PATCH 2/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_make_listen_node

[Jia-Ju Bai]

i40iw_make_listen_node() is never called in atomic context.

i40iw_make_listen_node() is only called by i40iw_create_listen, which is 
set as ".create_listen" in struct iw_cm_verbs.

Despite never getting called from atomic context,
i40iw_make_listen_node() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c 
b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 5230dd3..d021399 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -2834,7 +2834,7 @@ static struct i40iw_cm_listener *i40iw_make_listen_node(
 
if (!listener) {
/* create a CM listen node (1/2 node to compare incoming 
traffic to) */
-   listener = kzalloc(sizeof(*listener), GFP_ATOMIC);
+   listener = kzalloc(sizeof(*listener), GFP_KERNEL);
if (!listener)
return NULL;
cm_core->stats_listen_nodes_created++;
-- 
1.9.1

Re: [linux-sunxi] [PATCH v3] ARM: sun8i: v40: enable USB host ports for Banana Pi M2 Berry

[Maxime Ripard]

On Mon, Apr 09, 2018 at 03:33:34PM +0800, Chen-Yu Tsai wrote:
> On Fri, Apr 6, 2018 at 10:03 PM, Icenowy Zheng  wrote:
> > Banana Pi M2 Berry has an on-board USB Hub that provides 4 USB Type-A
> > ports, and it's connected to the USB1 port of the SoC.
> >
> > Enable it.
> >
> > Signed-off-by: Icenowy Zheng 
> 
> Verified against public schematics.
> 
> Reviewed-by: Chen-Yu Tsai 

Applied for 4.18

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: KASAN: slab-out-of-bounds Read in pfkey_add

[Dmitry Vyukov]

On Wed, Apr 11, 2018 at 8:18 AM, Kevin Easton  wrote:
> On Mon, Apr 09, 2018 at 01:56:36AM -0400, Kevin Easton wrote:
>> On Sun, Apr 08, 2018 at 09:04:33PM -0700, Eric Biggers wrote:
>> ...
>> >
>> > Looks like this is going to be fixed by
>> > https://patchwork.kernel.org/patch/10327883/ ("af_key: Always verify 
>> > length of
>> > provided sadb_key"), but it's not applied yet to the ipsec tree yet.  
>> > Kevin, for
>> > future reference, for syzbot bugs it would be helpful to reply to the 
>> > original
>> > bug report and say that a patch was sent out, or even better send the 
>> > patch as a
>> > reply to the bug report email, e.g.
>> >
>> > git format-patch 
>> > --in-reply-to="<001a114292fadd3e250560706...@google.com>"
>> >
>> > for this one (and the Message ID can be found in the syzkaller-bugs 
>> > archive even
>> > if the email isn't in your inbox).
>>
>> Sure, I can do that.
>
> I recalled one reason I _didn't_ do this - the message ID is retrievable
> from the archived email, but because the archive is Google Groups the
> message recipients aren't (only masked).
>
> - Kevin
>

Hi Kevin,

This was mailed to other lists too:

To: davem@, herbert@, linux-kernel@vger.kernel.org,
net...@vger.kernel.org, steffen.klassert@,
syzkaller-b...@googlegroups.com

In the groups UI there is a drop down menu with "Show Original" option
which shows raw email which include Message-ID: header.

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

[Zhaoyang Huang]

On Wed, Apr 11, 2018 at 2:39 AM, Joel Fernandes  wrote:
> Hi Steve,
>
> On Tue, Apr 10, 2018 at 11:00 AM, Steven Rostedt  wrote:
>> On Tue, 10 Apr 2018 09:45:54 -0700
>> Joel Fernandes  wrote:
>>
>>> > diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
>>> > index a0233edc0718..807e2bcb21b3 100644
>>> > --- a/include/linux/ring_buffer.h
>>> > +++ b/include/linux/ring_buffer.h
>>> > @@ -106,7 +106,8 @@ __poll_t ring_buffer_poll_wait(struct ring_buffer 
>>> > *buffer, int cpu,
>>> >
>>> >  void ring_buffer_free(struct ring_buffer *buffer);
>>> >
>>> > -int ring_buffer_resize(struct ring_buffer *buffer, unsigned long size, 
>>> > int cpu);
>>> > +int ring_buffer_resize(struct ring_buffer *buffer, unsigned long size,
>>> > +   int cpu, int rbflags);
>>> >
>>> >  void ring_buffer_change_overwrite(struct ring_buffer *buffer, int val);
>>> >
>>> > @@ -201,6 +202,7 @@ int ring_buffer_print_page_header(struct trace_seq 
>>> > *s);
>>> >
>>> >  enum ring_buffer_flags {
>>> > RB_FL_OVERWRITE = 1 << 0,
>>> > +   RB_FL_NO_RECLAIM= 1 << 1,
>>>
>>> But the thing is, set_oom_origin doesn't seem to be doing the
>>> desirable thing every time anyway as per my tests last week [1] and
>>> the si_mem_available check alone seems to be working fine for me (and
>>> also Zhaoyang as he mentioned).
>>
>> But did you try it with just plain GFP_KERNEL, and not RETRY_MAYFAIL.
>
> Yes I tried it with just GFP_KERNEL as well. What I did based on your
> suggestion for testing the OOM hint is:
> 1. Comment the si_mem_available check
> 2. Do only GFP_KERNEL
>
> The system gets destabilized with this combination even with the OOM
> hint. These threads are here:
> https://lkml.org/lkml/2018/4/5/720
>
>> My tests would always trigger the allocating task without the
>> RETRY_MAYFAIL, but with RETRY_MAYFAIL it would sometimes take out other
>> tasks.
>>
>>>
>>> Since the problem Zhaoyang is now referring to is caused because of
>>> calling set_oom_origin in the first place, can we not just drop that
>>> patch and avoid adding more complexity?
>>
>> Actually, I'm thinking of dropping the MAYFAIL part. It really should
>> be the one targeted if you are extending the ring buffer.
>
> This then sounds like it should be fixed in -mm code? If we're giving
> the hint and its not getting killed there then that's an -mm issue.
>
>> I could add two loops. One that does NORETRY without the oom origin,
>> and if it succeeds, its fine. But if it requires reclaim, it will then
>> set oom_origin and go harder (where it should be the one targeted).
>>
>> But that may be pointless, because if NORETRY succeeds, there's not
>> really any likelihood of oom triggering in the first place.
>
> Yes.
>
>>
>>>
>>> IMHO I feel like for things like RB memory allocation, we shouldn't
>>> add a knob if we don't need to.
>>
>> It was just a suggestion.
>
> Cool, I understand.
>
>>>
>>> Also I think Zhaoyang is developing for Android too since he mentioned
>>> he ran CTS tests so we both have the same "usecase" but he can feel
>>> free to correct me if that's not the case ;)
>>
>> I think if you are really worried with the task being killed by oom,
>> then I agree with Michal and just fork a process to do the allocation
>> for you.
>
> Yes I agree. So lets just do that and no other patches additional
> patches are needed then. Let me know if there's anything else I
> missed?
>
> Also I got a bit confused, I reread all the threads. Zhaoyang's
> current issue is that the OOM hint *IS* working which is what
> triggered your patch to toggle the behavior through an option. Where
> was in this message we are discussing that the OOM hint doesn't always
> work which is not Zhaoyang's current issue. Let me know if I missed
> something? Sorry if I did.
>
> thanks,
>
> - Joel
Hi Joel, you are right. My issue is to make Steven's patch safer by
keeping -1000 process out of OOM. I think it is ok either we just have
si_mem_available or apply set/clear_current_oom_origin with absolving
-1000 process. The CTS case failed because the system_server was
killed as the innocent. If Steven think it is rared corner case, I am
ok with that.

[PATCH v3 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

[Laurent Dufour]

Currently the PTE special supports is turned on in per architecture header
files. Most of the time, it is defined in arch/*/include/asm/pgtable.h
depending or not on some other per architecture static definition.

This patch introduce a new configuration variable to manage this directly
in the Kconfig files. It would later replace __HAVE_ARCH_PTE_SPECIAL.

Here notes for some architecture where the definition of
__HAVE_ARCH_PTE_SPECIAL is not obvious:

arm
 __HAVE_ARCH_PTE_SPECIAL which is currently defined in
arch/arm/include/asm/pgtable-3level.h which is included by
arch/arm/include/asm/pgtable.h when CONFIG_ARM_LPAE is set.
So select ARCH_HAS_PTE_SPECIAL if ARM_LPAE.

powerpc
__HAVE_ARCH_PTE_SPECIAL is defined in 2 files:
 - arch/powerpc/include/asm/book3s/64/pgtable.h
 - arch/powerpc/include/asm/pte-common.h
The first one is included if (PPC_BOOK3S & PPC64) while the second is
included in all the other cases.
So select ARCH_HAS_PTE_SPECIAL all the time.

sparc:
__HAVE_ARCH_PTE_SPECIAL is defined if defined(__sparc__) &&
defined(__arch64__) which are defined through the compiler in
sparc/Makefile if !SPARC32 which I assume to be if SPARC64.
So select ARCH_HAS_PTE_SPECIAL if SPARC64

There is no functional change introduced by this patch.

Suggested-by: Jerome Glisse 
Reviewed-by: Jerome Glisse 
Acked-by: David Rientjes 
Signed-off-by: Laurent Dufour 
---
 Documentation/features/vm/pte_special/arch-support.txt | 2 +-
 arch/arc/Kconfig   | 1 +
 arch/arc/include/asm/pgtable.h | 2 --
 arch/arm/Kconfig   | 1 +
 arch/arm/include/asm/pgtable-3level.h  | 1 -
 arch/arm64/Kconfig | 1 +
 arch/arm64/include/asm/pgtable.h   | 2 --
 arch/powerpc/Kconfig   | 1 +
 arch/powerpc/include/asm/book3s/64/pgtable.h   | 3 ---
 arch/powerpc/include/asm/pte-common.h  | 3 ---
 arch/riscv/Kconfig | 1 +
 arch/riscv/include/asm/pgtable-bits.h  | 3 ---
 arch/s390/Kconfig  | 1 +
 arch/s390/include/asm/pgtable.h| 1 -
 arch/sh/Kconfig| 1 +
 arch/sh/include/asm/pgtable.h  | 2 --
 arch/sparc/Kconfig | 1 +
 arch/sparc/include/asm/pgtable_64.h| 3 ---
 arch/x86/Kconfig   | 1 +
 arch/x86/include/asm/pgtable_types.h   | 1 -
 include/linux/pfn_t.h  | 4 ++--
 mm/Kconfig | 3 +++
 mm/gup.c   | 4 ++--
 mm/memory.c| 2 +-
 24 files changed, 18 insertions(+), 27 deletions(-)

diff --git a/Documentation/features/vm/pte_special/arch-support.txt 
b/Documentation/features/vm/pte_special/arch-support.txt
index 055004f467d2..cd05924ea875 100644
--- a/Documentation/features/vm/pte_special/arch-support.txt
+++ b/Documentation/features/vm/pte_special/arch-support.txt
@@ -1,6 +1,6 @@
 #
 # Feature name:  pte_special
-# Kconfig:   __HAVE_ARCH_PTE_SPECIAL
+# Kconfig:   ARCH_HAS_PTE_SPECIAL
 # description:   arch supports the pte_special()/pte_mkspecial() VM 
APIs
 #
 ---
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index d76bf4a83740..8516e2b0239a 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -44,6 +44,7 @@ config ARC
select HAVE_GENERIC_DMA_COHERENT
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA
+   select ARCH_HAS_PTE_SPECIAL
 
 config MIGHT_HAVE_PCI
bool
diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index 08fe33830d4b..8ec5599a0957 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -320,8 +320,6 @@ PTE_BIT_FUNC(mkexec,|= (_PAGE_EXECUTE));
 PTE_BIT_FUNC(mkspecial,|= (_PAGE_SPECIAL));
 PTE_BIT_FUNC(mkhuge,   |= (_PAGE_HW_SZ));
 
-#define __HAVE_ARCH_PTE_SPECIAL
-
 static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
 {
return __pte((pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot));
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7f8e7f4b88f..c088c851b235 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -8,6 +8,7 @@ config ARM
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
+   select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_PHYS_TO_DMA
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
diff --git a/arch/arm/include/asm/pgtable-3level.h 

Re: [PATCH 4.14 134/138] vhost: validate log when IOTLB is enabled

[Greg KH]

On Tue, Apr 10, 2018 at 08:55:53PM -0400, David Miller wrote:
> From: "Michael S. Tsirkin" 
> Date: Wed, 11 Apr 2018 02:33:16 +0300
> 
> > That's a bug, davem just queued a patch to fix this upstream.
> 
> It did not get queued up.
> 
> The patch series didn't apply so I asked the submitter to
> respin and resubmit:
> 
>   https://marc.info/?l=linux-netdev=152337186209819=2

So should I drop this until a fix comes in?  Or keep it for now?
I have no objection to staying "bug compatible" with Linus's tree :)

thanks,

greg k-h

[PATCH v3 2/2] mm: remove odd HAVE_PTE_SPECIAL

[Laurent Dufour]

Remove the additional define HAVE_PTE_SPECIAL and rely directly on
CONFIG_ARCH_HAS_PTE_SPECIAL.

There is no functional change introduced by this patch

Signed-off-by: Laurent Dufour 
---
 mm/memory.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 96910c625daa..7f7dc7b2a341 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -817,17 +817,12 @@ static void print_bad_pte(struct vm_area_struct *vma, 
unsigned long addr,
  * PFNMAP mappings in order to support COWable mappings.
  *
  */
-#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
-# define HAVE_PTE_SPECIAL 1
-#else
-# define HAVE_PTE_SPECIAL 0
-#endif
 struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
 pte_t pte, bool with_public_device)
 {
unsigned long pfn = pte_pfn(pte);
 
-   if (HAVE_PTE_SPECIAL) {
+   if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) {
if (likely(!pte_special(pte)))
goto check_pfn;
if (vma->vm_ops && vma->vm_ops->find_special_page)
@@ -862,7 +857,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, 
unsigned long addr,
return NULL;
}
 
-   /* !HAVE_PTE_SPECIAL case follows: */
+   /* !CONFIG_ARCH_HAS_PTE_SPECIAL case follows: */
 
if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
if (vma->vm_flags & VM_MIXEDMAP) {
@@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, 
unsigned long addr,
 
if (is_zero_pfn(pfn))
return NULL;
-check_pfn:
+
+check_pfn: __maybe_unused
if (unlikely(pfn > highest_memmap_pfn)) {
print_bad_pte(vma, addr, pte, NULL);
return NULL;
@@ -891,7 +887,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, 
unsigned long addr,
 * NOTE! We still have PageReserved() pages in the page tables.
 * eg. VDSO mappings can cause them to exist.
 */
-out:
+out: __maybe_unused
return pfn_to_page(pfn);
 }
 
@@ -904,7 +900,7 @@ struct page *vm_normal_page_pmd(struct vm_area_struct *vma, 
unsigned long addr,
/*
 * There is no pmd_special() but there may be special pmds, e.g.
 * in a direct-access (dax) mapping, so let's just replicate the
-* !HAVE_PTE_SPECIAL case from vm_normal_page() here.
+* !CONFIG_ARCH_HAS_PTE_SPECIAL case from vm_normal_page() here.
 */
if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
if (vma->vm_flags & VM_MIXEDMAP) {
@@ -1933,7 +1929,8 @@ static int __vm_insert_mixed(struct vm_area_struct *vma, 
unsigned long addr,
 * than insert_pfn).  If a zero_pfn were inserted into a VM_MIXEDMAP
 * without pte special, it would there be refcounted as a normal page.
 */
-   if (!HAVE_PTE_SPECIAL && !pfn_t_devmap(pfn) && pfn_t_valid(pfn)) {
+   if (!IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL) &&
+   !pfn_t_devmap(pfn) && pfn_t_valid(pfn)) {
struct page *page;
 
/*
-- 
2.7.4

[PATCH v3 0/2] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

[Laurent Dufour]

The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the
per architecture header files. This doesn't allow to make other
configuration dependent on it.

The first patch of this series is replacing __HAVE_ARCH_PTE_SPECIAL by
CONFIG_ARCH_HAS_PTE_SPECIAL defined into the Kconfig files,
setting it automatically when architectures was already setting it in
header file.

The second patch is removing the odd define HAVE_PTE_SPECIAL which is a
duplicate of CONFIG_ARCH_HAS_PTE_SPECIAL.

There is no functional change introduced by this series.

--
Changes since v2:
 * remove __HAVE_ARCH_PTE_SPECIAL in arch/riscv/include/asm/pgtable-bits.h
 * use IS_ENABLED() instead of #ifdef blocks in patch 2

Laurent Dufour (2):
  mm: introduce ARCH_HAS_PTE_SPECIAL
  mm: remove odd HAVE_PTE_SPECIAL

 .../features/vm/pte_special/arch-support.txt  |  2 +-
 arch/arc/Kconfig  |  1 +
 arch/arc/include/asm/pgtable.h|  2 --
 arch/arm/Kconfig  |  1 +
 arch/arm/include/asm/pgtable-3level.h |  1 -
 arch/arm64/Kconfig|  1 +
 arch/arm64/include/asm/pgtable.h  |  2 --
 arch/powerpc/Kconfig  |  1 +
 arch/powerpc/include/asm/book3s/64/pgtable.h  |  3 ---
 arch/powerpc/include/asm/pte-common.h |  3 ---
 arch/riscv/Kconfig|  1 +
 arch/riscv/include/asm/pgtable-bits.h |  3 ---
 arch/s390/Kconfig |  1 +
 arch/s390/include/asm/pgtable.h   |  1 -
 arch/sh/Kconfig   |  1 +
 arch/sh/include/asm/pgtable.h |  2 --
 arch/sparc/Kconfig|  1 +
 arch/sparc/include/asm/pgtable_64.h   |  3 ---
 arch/x86/Kconfig  |  1 +
 arch/x86/include/asm/pgtable_types.h  |  1 -
 include/linux/pfn_t.h |  4 ++--
 mm/Kconfig|  3 +++
 mm/gup.c  |  4 ++--
 mm/memory.c   | 19 ---
 24 files changed, 25 insertions(+), 37 deletions(-)

-- 
2.7.4

[PATCH 1/2] gpu: drm: ast: Replace mdelay with msleep in reset_mmc_2500

[Jia-Ju Bai]

reset_mmc_2500() is never called in atomic context.

The call chains ending up at reset_mmc_2500() are:
[1] reset_mmc_2500() <- ast_dram_init_2500() <- ast_post_chip_2500() <- 
ast_post_gpu() <- ast_drm_thaw()
[2] reset_mmc_2500() <- ast_dram_init_2500() <- ast_post_chip_2500() <- 
ast_post_gpu() <- ast_driver_load()

ast_drm_thaw() calls console_lock() which can sleep.
ast_driver_load() is set as ".load" in struct drm_driver.
These functions are not called in atomic context.

Despite never getting called from atomic context, reset_mmc_2500()
calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/gpu/drm/ast/ast_post.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index f7d4213..12bbf64 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -1840,7 +1840,7 @@ static void reset_mmc_2500(struct ast_private *ast)
ast_moutdwm(ast, 0x1E785044, 0x0001);
ast_moutdwm(ast, 0x1E785048, 0x4755);
ast_moutdwm(ast, 0x1E78504C, 0x0013);
-   mdelay(100);
+   msleep(100);
ast_moutdwm(ast, 0x1E785054, 0x0077);
ast_moutdwm(ast, 0x1E6E, 0xFC600309);
 }
-- 
1.9.1

[PATCH 2/2] gpu: drm: ast: Replace mdelay with msleep in ast_post_chip_2500

[Jia-Ju Bai]

ast_post_chip_2500() is never called in atomic context.

The call chains ending up at reset_mmc_2500() are:
[1] ast_post_chip_2500() <- ast_post_gpu() <- ast_drm_thaw()
[2] ast_post_chip_2500() <- ast_post_gpu() <- ast_driver_load()

ast_drm_thaw() calls console_lock() which can sleep.
ast_driver_load() is set as ".load" in struct drm_driver.
These functions are not called in atomic context.

Despite never getting called from atomic context, ast_post_chip_2500()
calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/gpu/drm/ast/ast_post.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index f7d4213..67c5e50 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -2063,7 +2063,7 @@ void ast_post_chip_2500(struct drm_device *dev)
temp  = ast_mindwm(ast, 0x1e6e2070);
if (temp & 0x0080) {
ast_moutdwm(ast, 0x1e6e207c, 0x0080);
-   mdelay(100);
+   msleep(100);
ast_moutdwm(ast, 0x1e6e2070, 0x0080);
}
 
-- 
1.9.1

Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

[Geert Uytterhoeven]

Hi Philipp,

On Wed, Apr 11, 2018 at 10:22 AM, Philipp Zabel  wrote:
> On Tue, 2018-04-10 at 17:53 +0200, Geert Uytterhoeven wrote:
>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>> platforms, by a device-specific reset driver matching against the
>> device's compatible value.
>>
>> On many SoCs, devices are connected to an SoC-internal reset controller.
>> If the reset hierarchy is described in DT using "resets" properties,
>> such devices can be reset in a generic way through the reset controller
>> subsystem.  Hence add support for this, avoiding the need to write
>> device-specific reset drivers for each single device on affected SoCs.
>>
>> Devices that do require a more complex reset procedure can still provide
>> a device-specific reset driver, as that takes precedence.
>>
>> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
>> becomes a no-op (as in: "No reset function found for device") if reset
>> controller support is disabled.
>>
>> Signed-off-by: Geert Uytterhoeven 
>
> Reviewed-by: Philipp Zabel 

Thanks!

>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
> [...]
>> @@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct 
>> vfio_platform_device *vdev)
>>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>>   >reset_module);
>>   }
>> + if (vdev->of_reset)
>> + return 0;
>> +
>> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
>
> If vdev->device->of_node == NULL, this will return -EINVAL ...
>
>> + if (!IS_ERR(rstc)) {
>> + vdev->reset_control = rstc;
>> + return 0;
>> + }
>>
>> - return vdev->of_reset ? 0 : -ENOENT;
>> + return PTR_ERR(rstc);
>
> ... instead of -ENOENT, if that makes any difference.

Not really. The single caller (vfio_platform_probe_common()) already returns
-EINVAL if no IOMMU group is found, so this should be handled fine.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 2/2] mm: remove odd HAVE_PTE_SPECIAL

[Christophe LEROY]

Le 11/04/2018 à 10:41, Laurent Dufour a écrit :

On 11/04/2018 10:33, Michal Hocko wrote:

On Wed 11-04-18 10:03:36, Laurent Dufour wrote:

@@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, 
unsigned long addr,
  
  	if (is_zero_pfn(pfn))

return NULL;
-check_pfn:
+
+check_pfn: __maybe_unused
if (unlikely(pfn > highest_memmap_pfn)) {
print_bad_pte(vma, addr, pte, NULL);
return NULL;
@@ -891,7 +887,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, 
unsigned long addr,
 * NOTE! We still have PageReserved() pages in the page tables.
 * eg. VDSO mappings can cause them to exist.
 */
-out:
+out: __maybe_unused
return pfn_to_page(pfn);


Why do we need this ugliness all of the sudden?

Indeed the compiler doesn't complaint but in theory it should since these
labels are not used depending on CONFIG_ARCH_HAS_PTE_SPECIAL.


Why should it complain ?

Regards
Christophe

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

On Wed, Apr 11, 2018 at 10:52:01AM +0200, Boris Brezillon wrote:
> On Wed, 11 Apr 2018 10:27:46 +0200
> Ladislav Michl  wrote:
> 
> > On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote:
> > > On Wed, 11 Apr 2018 09:36:56 +0200
> > > Ladislav Michl  wrote:
> > >   
> > > > Hi Boris,
> > > > 
> > > > On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:  
> > [...]
> > > > > Not sure this approach is safe on all archs: if the cache is VIVT or
> > > > > VIPT, you may have several entries pointing to the same phys page, and
> > > > > then, when dma_map_page() does its cache maintenance operations, it's
> > > > > only taking one of these entries into account.
> > > > 
> > > > Hmm, I used the same approach Samsung OneNAND driver does since commit
> > > > dcf08227e964a53a2cb39130b74842c7dcb6adde.
> > > > Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> > > > is VIPT. In that case samsung's driver code has the same problem.
> > > >   
> > > > > In other parts of the MTD subsystem, we tend to not do DMA on buffers
> > > > > that have been vmalloc-ed.
> > > > > 
> > > > > You can do something like
> > > > > 
> > > > >   if (virt_addr_valid(buf))
> > > > >   /* Use DMA */
> > > > >   else
> > > > >   /*
> > > > >* Do not use DMA, or use a bounce buffer
> > > > >* allocated with kmalloc
> > > > >*/
> > > > 
> > > > Okay, I'll use this approach then, but first I'd like to be sure above 
> > > > is
> > > > correct. Anyone?  
> > > 
> > > See this discussion [1]. The problem came up a few times already, so
> > > might find other threads describing why it's not safe.
> > > 
> > > [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html
> > >   
> > 
> > Question was more likely whenever there might exist more that one mapping
> > of the same page.
> 
> I'm clearly not an expert, so I might be wrong, but I think a physical
> page can be both in the identity mapping and mapped in the vmalloc
> space. Now, is there a real risk that both ends are accessed in
> parallel thus making different cache entries pointing to the same phys
> page dirty, I'm not sure. Or maybe there are other corner case, but
> you'll have to ask Russell (or any other ARM expert) to get a clearer
> answer.

Thank you anyway. As DMA was disabled completely for all DT enabled boards
until 4.16 let's play safe and disable it for HIGHMEM case as you suggested.
Later, we might eventually use the same {read,write}_bufferram for both
OMAP and S5PC110.

> > But okay, I'll disable DMA for highmem. Patch will follow.
> > 
> > ladis

Andreas, Nikolaus, could you please test patch bellow? It is against
linux.git and should apply also against 4.16 once you modify path.

Thank you,
ladis

--- >8 ---

From: Ladislav Michl 
Subject: [PATCH] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

dma_map_single doesn't get the proper DMA address for vmalloced area,
so disable DMA in this case.

Signed-off-by: Ladislav Michl 
Reported-by: "H. Nikolaus Schaller" 
---
 drivers/mtd/nand/onenand/omap2.c | 105 +++
 1 file changed, 38 insertions(+), 67 deletions(-)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..321137158ff3 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
size_t xtra;
-   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=
-   ((size_t)(buf + count - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = 

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

[Geert Uytterhoeven]

On Wed, Apr 11, 2018 at 11:15 AM, Geert Uytterhoeven
 wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM.  Without Runtime PM, the device
> may not be powered up, causing subtle failures, crashes, or system
> lock-ups when the device is accessed by the guest.
>
> Fix this by adding Runtime PM support, powering the device when the VFIO
> device is opened by the guest.
>
> Note that while more fine-grained power management could be implemented
> on the guest side, if exported, this would be inherently unsafe, as
> abusing it may kill the whole system.
>
> Signed-off-by: Geert Uytterhoeven 

Please ignore, this was sent accidentally with another series.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

[Jan Beulich]

>>> On 11.04.18 at 09:08,  wrote:
> On 14/03/18 09:48, Jan Beulich wrote:
> On 26.02.18 at 15:08,  wrote:
>>> @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled)
>>>  
>>>  static void xen_vcpu_notify_restore(void *data)
>>>  {
>>> +   if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
>>> +   wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
>>> +
>>> /* Boot processor notified via generic timekeeping_resume() */
>>> if (smp_processor_id() == 0)
>>> return;
>>> @@ -44,7 +52,15 @@ static void xen_vcpu_notify_restore(void *data)
>>>  
>>>  static void xen_vcpu_notify_suspend(void *data)
>>>  {
>>> +   u64 tmp;
>>> +
>>> tick_suspend_local();
>>> +
>>> +   if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
>>> +   rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
>>> +   this_cpu_write(spec_ctrl, tmp);
>>> +   wrmsrl(MSR_IA32_SPEC_CTRL, 0);
>>> +   }
>>>  }
>> 
>> While investigating ways how to do something similar on our old,
>> non-pvops kernels I've started wondering if this solution is actually
>> correct in all cases. Of course discussing this is complicated by the
>> fact that the change there might be a conflict with hasn't landed
>> in Linus'es tree yet (see e.g.
>> https://patchwork.kernel.org/patch/10153843/ for an upstream
>> submission; I haven't been able to find any discussion on that
>> patch or why it isn't upstream yet), but we have it in our various
>> branches. The potential problem I'm seeing is with the clearing
>> and re-setting of SPEC_CTRL around CPUs going idle. While the
>> active CPU could have preemption disabled (if that isn't the case
>> already), the passive CPUs are - afaict - neither under full control
>> of drivers/xen/manage.c:do_suspend() nor excluded yet from
>> any further scheduling activity. Hence with code like this (taken
>> from one of our branches)
>> 
>> static void mwait_idle(void)
>> {
>>  if (!current_set_polling_and_test()) {
>>  trace_cpu_idle_rcuidle(1, smp_processor_id());
>>  if (this_cpu_has(X86_BUG_CLFLUSH_MONITOR)) {
>>  smp_mb(); /* quirk */
>>  clflush((void *)_thread_info()->flags);
>>  smp_mb(); /* quirk */
>>  }
>> 
>>  x86_disable_ibrs();
>> 
>>  __monitor((void *)_thread_info()->flags, 0, 0);
>>  if (!need_resched())
>>  __sti_mwait(0, 0);
>>  else
>>  local_irq_enable();
>> 
>>  x86_enable_ibrs();
>>  ...
>> 
>> the MSR might get set to non-zero again after having been
>> cleared by the code your patch adds. I therefore think that the
>> only race free solution would be to do the clearing from
>> stop-machine context. But maybe I'm overlooking something.
> 
> Currently and with the above mentioned patch there is no problem: Xen pv
> guests always use default_idle(), so mwait_idle() eventually playing
> with MSR_IA32_SPEC_CTRL won't affect us.

It's pretty unclear to me why default_idle() doesn't have this - in
Xen we do it for all idle routines.

> In order to ensure that won't change in future default_idle() should
> never modify MSR_IA32_SPEC_CTRL. In case something like that would be
> required we should rather add another idle function doing that.

This looks like a pretty strange/non-obvious requirement, which I
don't think anyone would remember.

Additionally, x86 maintainers: is there a particular reason this (or
any functionally equivalent patch) isn't upstream yet? As indicated
before, I had not been able to find any discussion, and hence I
see no reason why this is a patch we effectively carry privately in
our distro branches (and likely other distros do so too).

Jan

Re: [PATCH 5/5] dmaengine: sprd: Add 'device_config' and 'device_prep_slave_sg' interfaces

[Vinod Koul]

On Tue, Apr 10, 2018 at 03:46:07PM +0800, Baolin Wang wrote:
> This patch adds the 'device_config' and 'device_prep_slave_sg' interfaces
> for users to configure DMA.
> 
> Signed-off-by: Baolin Wang 
> ---
>  drivers/dma/sprd-dma.c |   48 
> 
>  1 file changed, 48 insertions(+)
> 
> diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
> index f8038de..c923fb0 100644
> --- a/drivers/dma/sprd-dma.c
> +++ b/drivers/dma/sprd-dma.c
> @@ -869,6 +869,52 @@ static int sprd_dma_config(struct dma_chan *chan, struct 
> sprd_dma_desc *sdesc,
>   return vchan_tx_prep(>vc, >vd, flags);
>  }
>  
> +static struct dma_async_tx_descriptor *
> +sprd_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> +unsigned int sglen, enum dma_transfer_direction dir,
> +unsigned long flags, void *context)
> +{
> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> + struct sprd_dma_config *slave_cfg = >slave_cfg;
> + struct sprd_dma_desc *sdesc;
> + struct scatterlist *sg;
> + int ret, i;
> +
> + /* TODO: now we only support one sg for each DMA configuration. */
> + if (!is_slave_direction(slave_cfg->config.direction) || sglen > 1)

the slave direction check seems wrong to me. .device_config shall give you
dma_slave_config. You should check here if dir passed is slave or not. If
you want to check parameters in slave_config then please use .device_config

> + return NULL;
> +
> + sdesc = kzalloc(sizeof(*sdesc), GFP_NOWAIT);
> + if (!sdesc)
> + return NULL;
> +
> + for_each_sg(sgl, sg, sglen, i) {
> + if (slave_cfg->config.direction == DMA_MEM_TO_DEV)
> + slave_cfg->config.src_addr = sg_dma_address(sg);

Nope slave_config specifies peripheral address and not memory one passed here

-- 
~Vinod

Re: [PATCH] pinctrl/samsung: Correct EINTG banks order

[Krzysztof Kozlowski]

On Wed, Apr 11, 2018 at 10:36 AM, Tomasz Figa  wrote:
> 2018-04-10 17:38 GMT+09:00 Tomasz Figa :
>> 2018-04-10 16:06 GMT+09:00 Krzysztof Kozlowski :
>>> On Sun, Apr 8, 2018 at 8:07 PM, Paweł Chmiel
>>>  wrote:
 All banks with GPIO interrupts should be at beginning
 of bank array and without any other types of banks between them.
 This order is expected by exynos_eint_gpio_irq, when doing
 interrupt group to bank translation.
 Otherwise, kernel NULL pointer dereference would happen
 when trying to handle interrupt, due to wrong bank being looked up.
 Observed on s5pv210, when trying to handle gpj0 interrupt,
 where kernel was mapping it to gpi bank.
>>>
>>> Thanks for the patch. The issue looks real although one thing was
>>> missed - there is a gap in SVC group between GPK2 and GPL0 (pointed by
>>> Marek Szyprowski):
>>>
>>> 0x0 - EINT_23 - gpk0
>>> 0x1 - EINT_24 - gpk1
>>> 0x2 - EINT_25 - gpk2
>>> 0x4 - EINT_27 - gpl0
>>> 0x7 - EINT_8 - gpm0
>>>
>>> Maybe this should be done differently - to remove such hidden
>>> requirement entirely in favor of another parameter of
>>> EXYNOS_PIN_BANK_EINTG argument?
>>
>> Perhaps let's limit this patch to s5pv210 and Exynos5410 alone, where
>> a simple swap of bank order in the arrays should be okay.
>>
>> We might also need to have some fixes on 4x12, because I noticed that
>> in exynos4x12_pin_banks0[] there is a hole in eint_offsets between
>> gpd1 and gpf0 and exynos4x12_pin_banks1[] starts with gpk0 that has
>> eint_offset equal to 0x08 (not 0).
>
> To close the loop, after talking offline and checking the
> documentation, Exynos4x12 is fine, because the group numbers in SVC
> register actually match what is defined in bank arrays.

Great! Thanks for checking.

Best regards,
Krzysztof

Re: [PATCH v2 3/4] arm64: dts: renesas: r8a77970: add LVDS support

[jacopo mondi]

Hi Sergei, Niklas

On Tue, Apr 10, 2018 at 08:12:36PM +0300, Sergei Shtylyov wrote:
> On 04/10/2018 03:13 PM, jacopo mondi wrote:
>
> >>> From: Niklas Söderlund 
> >>>
> >>> Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
> >>> the it to the LVDS output of the DU.
> >>>
> >>> Signed-off-by: Niklas Söderlund 
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Laurent Pinchart 
> >>>
> >>> ---
> >>> v1 -> v2:
> >>> - Rebased on the modified endpoint name and changed patch subject to
> >>>   comply with other patches in the series from Sergei.
> >>
> >>Stop, what was wrong with my R8A77970 LVDS patch, reposted on the 
> >> popular
> >> demand? :-)
> >>
> >
> > Nothing wrong, I found out about your right now.
> > I see a very small difference as
> >  lvds@feb9 vs lvds-encoder@feb9
>
>Yes, I thought the latter was closer to a "generic" name that DT spec 
> requires...
>
> > You can add your signed-off-by ofc if you think that's the case.
>
>Didn't understand what you mean here...

Don't worry, I will resend this and use (part of) your series
[PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

But please note that:
[1/5] from your series has already been collected by Simon
I have to reapply Laurent's comment on this series to your one (so I
have to resend it anyhow)
[5/5] from your series shall be resent to take into account the newly
developed LVDS decoder driver (once it has been accepted)

I have anyway to repost your patches then, and as I did in this series
you are ofc listed as author already, so I have missed what's the
difference actually except from LVDS patch I collected from Niklas and not
from your series.

Niklas I picked up patches 1-3 of this series from your tree.
1 and 2 are patches from Sergei's series
3 is from you but was also in Sergei's series and I picked yours as it
was there already. Can I rebase on top of Sergei's one instead?

Thanks
   j


signature.asc
Description: PGP signature

Re: 3 version of MKDEV: kernel, uapi, libc, why?

[gre...@linuxfoundation.org]

On Wed, Apr 11, 2018 at 08:51:03AM +, Zhang, Ning A wrote:
> Hi, Greg, Thomas
> 
> I find 3 version of MKDEV (actually 2 + makedev)
> 
> in include/linux/kdev_t.h
> 
> #define MINORBITS 20
> #define MKDEV(ma,mi)  (((ma) << MINORBITS) | (mi))
> 
> in inlcude/uapi/linux/kdev_t.h
> 
> #define MKDEV(ma,mi)  ((ma)<<8 | (mi))

Isn't history grand :)
Those are different because we increased the size way back in the 2.5
kernel (I think), so we had to do so in a way that did not break
userspace.

> in Android bionic
> 
> #define makedev(__major, __minor) \
>   ( \
> (((__major) & 0xf000ULL) << 32) | (((__major) & 0xfffULL) <<
> 8) | \
> (((__minor) & 0xff00ULL) << 12) | (((__minor) & 0xffULL)) \
>   )

Fun stuff :)

> if I use mknod("renderD128", S_IFCHR|0666, MKDEV(226, 128));
> I get wrong device:
> crw-rw-rw- 1 root graphics 0, 57984 2011-11-11 11:20 renderD128
> 
> 
> if I use ("renderD128",S_IFCHR|0666, makedev(226, 128));
> I get right device.
> 
> but, when I use: mknod("card0", S_IFCHR|0666, MKDEV(226, 0));
> I can get right device.

Why are you calling 'mknod' at all?  The kernel does this automagically
for you already, in devtmpfs.  You should not have to do this on your
own ever.

Unless you are using a crazy Android system that doesn't use that
filesystem.  And if you are, go complain to those developers about it,
not much we can do from within the kernel.

And the answer is yes, use the right macro, for when you want to really
do this.  Your libc should provide the correct one, trust it.

good luck!

greg k-h

Re: [PATCH] sched/fair: schedutil: update only with all info available

[Patrick Bellasi]

On 11-Apr 08:57, Vincent Guittot wrote:
> On 10 April 2018 at 13:04, Patrick Bellasi  wrote:
> > On 09-Apr 10:51, Vincent Guittot wrote:
> >> On 6 April 2018 at 19:28, Patrick Bellasi  wrote:
> >> Peter,
> >> what was your goal with adding the condition "if
> >> (rq->cfs.h_nr_running)" for the aggragation of CFS utilization
> >
> > The original intent was to get rid of sched class flags, used to track
> > which class has tasks runnable from within schedutil. The reason was
> > to solve some misalignment between scheduler class status and
> > schedutil status.
> 
> This was mainly for RT tasks but it was not the case for cfs task
> before commit 8f111bc357aa

True, but with his solution Peter has actually come up with a unified
interface which is now (and can be IMO) based just on RUNNABLE
counters for each class.

> > The solution, initially suggested by Viresh, and finally proposed by
> > Peter was to exploit RQ knowledges directly from within schedutil.
> >
> > The problem is that now schedutil updated depends on two information:
> > utilization changes and number of RT and CFS runnable tasks.
> >
> > Thus, using cfs_rq::h_nr_running is not the problem... it's actually
> > part of a much more clean solution of the code we used to have.
> 
> So there are 2 problems there:
> - using cfs_rq::h_nr_running when aggregating cfs utilization which
> generates a lot of frequency drop

You mean because we now completely disregard the blocked utilization
where a CPU is idle, right?

Given how PELT works and the recent support for IDLE CPUs updated, we
should probably always add contributions for the CFS class.

> - making sure that the nr-running are up-to-date when used in sched_util

Right... but, if we always add the cfs_rq (to always account for
blocked utilization), we don't have anymore this last dependency,
isn't it?

We still have to account for the util_est dependency.

Should I add a patch to this series to disregard cfs_rq::h_nr_running
from schedutil as you suggested?

> > The problem, IMO is that we now depend on other information which
> > needs to be in sync before calling schedutil... and the patch I
> > proposed is meant to make it less likely that all the information
> > required are not aligned (also in the future).
> >
> > --
> > #include 
> >
> > Patrick Bellasi

-- 
#include 

Patrick Bellasi

Re: [PATCH] irqchip/gic-v3: Support v2m frame backwards compatibility mode

[Srinivas Kandagatla]

On 10/04/18 19:17, Stephen Boyd wrote:

Anyway, this is mostly an FYI that I don't have the hardware to test
with anymore and I'm not going to keep sending patches on this topic.
Srini should have some hardware to test whatever solution you come up
with.

Yep, I can test PCI MSI side of it with DragonBoard 820c.

thanks,
srini

Re: [PATCH v3 2/2] mm: remove odd HAVE_PTE_SPECIAL

[Laurent Dufour]

On 11/04/2018 11:09, Christophe LEROY wrote:
> 
> 
> Le 11/04/2018 à 11:03, Laurent Dufour a écrit :
>>
>>
>> On 11/04/2018 10:58, Christophe LEROY wrote:
>>>
>>>
>>> Le 11/04/2018 à 10:03, Laurent Dufour a écrit :
 Remove the additional define HAVE_PTE_SPECIAL and rely directly on
 CONFIG_ARCH_HAS_PTE_SPECIAL.

 There is no functional change introduced by this patch

 Signed-off-by: Laurent Dufour 
 ---
    mm/memory.c | 19 ---
    1 file changed, 8 insertions(+), 11 deletions(-)

 diff --git a/mm/memory.c b/mm/memory.c
 index 96910c625daa..7f7dc7b2a341 100644
 --- a/mm/memory.c
 +++ b/mm/memory.c
 @@ -817,17 +817,12 @@ static void print_bad_pte(struct vm_area_struct *vma,
 unsigned long addr,
     * PFNMAP mappings in order to support COWable mappings.
     *
     */
 -#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
 -# define HAVE_PTE_SPECIAL 1
 -#else
 -# define HAVE_PTE_SPECIAL 0
 -#endif
    struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long
 addr,
     pte_t pte, bool with_public_device)
    {
    unsigned long pfn = pte_pfn(pte);
    -    if (HAVE_PTE_SPECIAL) {
 +    if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) {
    if (likely(!pte_special(pte)))
    goto check_pfn;
    if (vma->vm_ops && vma->vm_ops->find_special_page)
 @@ -862,7 +857,7 @@ struct page *_vm_normal_page(struct vm_area_struct 
 *vma,
 unsigned long addr,
    return NULL;
    }
    -    /* !HAVE_PTE_SPECIAL case follows: */
 +    /* !CONFIG_ARCH_HAS_PTE_SPECIAL case follows: */
      if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
    if (vma->vm_flags & VM_MIXEDMAP) {
 @@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct 
 *vma,
 unsigned long addr,
      if (is_zero_pfn(pfn))
    return NULL;
 -check_pfn:
 +
 +check_pfn: __maybe_unused
>>>
>>> See below
>>>
    if (unlikely(pfn > highest_memmap_pfn)) {
    print_bad_pte(vma, addr, pte, NULL);
    return NULL;
 @@ -891,7 +887,7 @@ struct page *_vm_normal_page(struct vm_area_struct 
 *vma,
 unsigned long addr,
     * NOTE! We still have PageReserved() pages in the page tables.
     * eg. VDSO mappings can cause them to exist.
     */
 -out:
 +out: __maybe_unused
>>>
>>> Why do you need that change ?
>>>
>>> There is no reason for the compiler to complain. It would complain if the 
>>> goto
>>> was within a #ifdef, but all the purpose of using IS_ENABLED() is to allow 
>>> the
>>> compiler to properly handle all possible cases. That's all the force of
>>> IS_ENABLED() compared to ifdefs, and that the reason why they are 
>>> plebicited,
>>> ref Linux Codying style for a detailed explanation.
>>
>> Fair enough.
>>
>> Should I submit a v4 just to remove these so ugly __maybe_unused ?
>>
> 
> Most likely, unless the mm maintainer agrees to remove them by himself when
> applying your patch ?

That was my point.

Andrew, should I send a v4 or could you wipe the 2 __maybe_unsued when applying
the patch ?

Thanks,
Laurent.

Re: [PATCH v3] net: tipc: Replace GFP_ATOMIC with GFP_KERNEL in tipc_mon_create

[Ying Xue]

On 04/11/2018 06:24 PM, Jia-Ju Bai wrote:
> tipc_mon_create() is never called in atomic context.
> 
> The call chain ending up at tipc_mon_create() is:
> [1] tipc_mon_create() <- tipc_enable_bearer() <- tipc_nl_bearer_enable()
> tipc_nl_bearer_enable() calls rtnl_lock(), which indicates this function
> is not called in atomic context.
> 
> Despite never getting called from atomic context,
> tipc_mon_create() calls kzalloc() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of successful allocation.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 

Acked-by: Ying Xue 

> ---
> v2:
> * Modify the description of GFP_ATOMIC in v1.
>   Thank Eric for good advice.
> v3:
> * Modify wrong text in description in v2.
>   Thank Ying for good advice.
> ---
>  net/tipc/monitor.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/net/tipc/monitor.c b/net/tipc/monitor.c
> index 9e109bb..9714d80 100644
> --- a/net/tipc/monitor.c
> +++ b/net/tipc/monitor.c
> @@ -604,9 +604,9 @@ int tipc_mon_create(struct net *net, int bearer_id)
>   if (tn->monitors[bearer_id])
>   return 0;
>  
> - mon = kzalloc(sizeof(*mon), GFP_ATOMIC);
> - self = kzalloc(sizeof(*self), GFP_ATOMIC);
> - dom = kzalloc(sizeof(*dom), GFP_ATOMIC);
> + mon = kzalloc(sizeof(*mon), GFP_KERNEL);
> + self = kzalloc(sizeof(*self), GFP_KERNEL);
> + dom = kzalloc(sizeof(*dom), GFP_KERNEL);
>   if (!mon || !self || !dom) {
>   kfree(mon);
>   kfree(self);
> 

Re: [PATCH v2] net: tipc: Replace GFP_ATOMIC with GFP_KERNEL in tipc_mon_create

[Ying Xue]

On 04/10/2018 09:17 AM, Jia-Ju Bai wrote:
> tipc_mon_create() is never called in atomic context.
> 
> The call chain ending up at dn_route_init() is:

Sorry, I don't think there is any relationship between the following
call chain with dn_route_init().

> [1] tipc_mon_create() <- tipc_enable_bearer() <- tipc_nl_bearer_enable()
> tipc_nl_bearer_enable() calls rtnl_lock(), which indicates this function
> is not called in atomic context.
> 
> Despite never getting called from atomic context,
> tipc_mon_create() calls kzalloc() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of sucessful allocation.

s/sucessful/successful

> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai > ---
> v2:
> * Modify the description of GFP_ATOMIC in v1.
>   Thank Eric for good advice.
> ---
>  net/tipc/monitor.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/net/tipc/monitor.c b/net/tipc/monitor.c
> index 9e109bb..9714d80 100644
> --- a/net/tipc/monitor.c
> +++ b/net/tipc/monitor.c
> @@ -604,9 +604,9 @@ int tipc_mon_create(struct net *net, int bearer_id)
>   if (tn->monitors[bearer_id])
>   return 0;
>  
> - mon = kzalloc(sizeof(*mon), GFP_ATOMIC);
> - self = kzalloc(sizeof(*self), GFP_ATOMIC);
> - dom = kzalloc(sizeof(*dom), GFP_ATOMIC);
> + mon = kzalloc(sizeof(*mon), GFP_KERNEL);
> + self = kzalloc(sizeof(*self), GFP_KERNEL);
> + dom = kzalloc(sizeof(*dom), GFP_KERNEL);
>   if (!mon || !self || !dom) {
>   kfree(mon);
>   kfree(self);
> 

[PATCH] lan78xx: Avoid spurious kevent 4 "error"

[Phil Elwell]

lan78xx_defer_event generates an error message whenever the work item
is already scheduled. lan78xx_open defers three events -
EVENT_STAT_UPDATE, EVENT_DEV_OPEN and EVENT_LINK_RESET. Being aware
of the likelihood (or certainty) of an error message, the DEV_OPEN
event is added to the set of pending events directly, relying on
the subsequent deferral of the EVENT_LINK_RESET call to schedule the
work.  Take the same precaution with EVENT_STAT_UPDATE to avoid a
totally unnecessary error message.

Signed-off-by: Phil Elwell 
---
 drivers/net/usb/lan78xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 32cf217..3102374 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2507,7 +2507,7 @@ static void lan78xx_init_stats(struct lan78xx_net *dev)
dev->stats.rollover_max.eee_tx_lpi_transitions = 0x;
dev->stats.rollover_max.eee_tx_lpi_time = 0x;
 
-   lan78xx_defer_kevent(dev, EVENT_STAT_UPDATE);
+   set_bit(EVENT_STAT_UPDATE, >flags);
 }
 
 static int lan78xx_open(struct net_device *net)
-- 
2.7.4

[RFC/PATCH] Add a socketoption IPV6_MULTICAST_ALL analogue to the IPV4 version

[Andre Naujoks]

Hi.

I was running into a problem, when trying to join multiple multicast groups
on a single socket and thus binding to the any-address on said socket. I
received traffic from multicast groups, I did not join on that socket and
was at first surprised by that. After reading some old e-mails/threads,
which came to the conclusion "It is, as it is."
(e.g https://marc.info/?l=linux-kernel=115815686626791=2), I discovered
the IPv4 socketoption IP_MULTICAST_ALL, which, when disabled, does exactly
what I would expect from a socket by default.

I propose a socket option for IPv6, which does the same and has the same
default as the IPv4 version. My first thought was, to just apply
IP_MULTICAST_ALL to a ipv6 socket, but that would change the behavior of
current applications and would probably be a big no-no.

Regards
  Andre


>From 473653086c05a3de839c3504885053f6254c7bc5 Mon Sep 17 00:00:00 2001
From: Andre Naujoks 
Date: Wed, 11 Apr 2018 12:38:28 +0200
Subject: [PATCH] Add a socketoption IPV6_MULTICAST_ALL analogue to the IPV4
 version

The socket option will be enabled by default to ensure current behaviour
is not changed. This is the same for the IPv4 version.

A socket bound to in6addr_any and a specific port will receive all traffic
on that port. Analogue to IP_MULTICAST_ALL, disable this behaviour, if
one or more multicast groups were joined (using said socket) and only
pass on multicast traffic from groups, which were explicitly joined via
this socket.

Without this option disabled a socket (system even) joined to multiple
multicast groups is very hard to get right. Filtering by destination
address has to take place in user space to avoid receiving multicast
traffic from other multicast groups, which might have traffic on the same
port.

The extension of the IP_MULTICAST_ALL socketoption to just apply to ipv6,
too, is not done to avoid changing the behaviour of current applications.

Signed-off-by: Andre Naujoks 
---
 include/linux/ipv6.h |  3 ++-
 include/uapi/linux/in6.h |  1 +
 net/ipv6/af_inet6.c  |  1 +
 net/ipv6/ipv6_sockglue.c | 11 +++
 net/ipv6/mcast.c |  2 +-
 5 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 8415bf1a9776..495e834c1367 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -274,7 +274,8 @@ struct ipv6_pinfo {
 */
dontfrag:1,
autoflowlabel:1,
-   autoflowlabel_set:1;
+   autoflowlabel_set:1,
+   mc_all:1;
__u8min_hopcount;
__u8tclass;
__be32  rcv_flowinfo;
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index ed291e55f024..71d82fe15b03 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -177,6 +177,7 @@ struct in6_flowlabel_req {
 #define IPV6_V6ONLY26
 #define IPV6_JOIN_ANYCAST  27
 #define IPV6_LEAVE_ANYCAST 28
+#define IPV6_MULTICAST_ALL 29
 
 /* IPV6_MTU_DISCOVER values */
 #define IPV6_PMTUDISC_DONT 0
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 8da0b513f188..7844cd9d2f10 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -209,6 +209,7 @@ static int inet6_create(struct net *net, struct socket 
*sock, int protocol,
np->hop_limit   = -1;
np->mcast_hops  = IPV6_DEFAULT_MCASTHOPS;
np->mc_loop = 1;
+   np->mc_all  = 1;
np->pmtudisc= IPV6_PMTUDISC_WANT;
np->repflow = net->ipv6.sysctl.flowlabel_reflect;
sk->sk_ipv6only = net->ipv6.sysctl.bindv6only;
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 4d780c7f0130..b2bc1942a2ee 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -664,6 +664,13 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, 
int optname,
retv = ipv6_sock_ac_drop(sk, mreq.ipv6mr_ifindex, 
_acaddr);
break;
}
+   case IPV6_MULTICAST_ALL:
+   if (optlen < sizeof(int))
+   goto e_inval;
+   np->mc_all = valbool;
+   retv = 0;
+   break;
+
case MCAST_JOIN_GROUP:
case MCAST_LEAVE_GROUP:
{
@@ -1255,6 +1262,10 @@ static int do_ipv6_getsockopt(struct sock *sk, int 
level, int optname,
val = np->mcast_oif;
break;
 
+   case IPV6_MULTICAST_ALL:
+   val = np->mc_all;
+   break;
+
case IPV6_UNICAST_IF:
val = (__force int)htonl((__u32) np->ucast_oif);
break;
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 793159d77d8a..623ad00eb3c2 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -622,7 +622,7 @@ bool 

[PATCH v6 2/4] lib: Rename compiler intrinsic selects to GENERIC_LIB_*

[Matt Redfearn]

When these are included into arch Kconfig files, maintaining
alphabetical ordering of the selects means these get split up. To allow
for keeping things tidier and alphabetical, rename the selects to
GENERIC_LIB_*

Signed-off-by: Matt Redfearn 
Reviewed-by: Palmer Dabbelt 

---

Changes in v6: None
Changes in v5: None
Changes in v4:
Rename Kconfig symbols GENERIC_* -> GENERIC_LIB_*

Changes in v3: None
Changes in v2: None

 arch/riscv/Kconfig |  6 +++---
 lib/Kconfig| 12 ++--
 lib/Makefile   | 12 ++--
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 04807c7f64cc..20185aaaf933 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -104,9 +104,9 @@ config ARCH_RV32I
bool "RV32I"
select CPU_SUPPORTS_32BIT_KERNEL
select 32BIT
-   select GENERIC_ASHLDI3
-   select GENERIC_ASHRDI3
-   select GENERIC_LSHRDI3
+   select GENERIC_LIB_ASHLDI3
+   select GENERIC_LIB_ASHRDI3
+   select GENERIC_LIB_LSHRDI3
 
 config ARCH_RV64I
bool "RV64I"
diff --git a/lib/Kconfig b/lib/Kconfig
index e96089499371..e54ebe00937e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -588,20 +588,20 @@ config STRING_SELFTEST
 
 endmenu
 
-config GENERIC_ASHLDI3
+config GENERIC_LIB_ASHLDI3
bool
 
-config GENERIC_ASHRDI3
+config GENERIC_LIB_ASHRDI3
bool
 
-config GENERIC_LSHRDI3
+config GENERIC_LIB_LSHRDI3
bool
 
-config GENERIC_MULDI3
+config GENERIC_LIB_MULDI3
bool
 
-config GENERIC_CMPDI2
+config GENERIC_LIB_CMPDI2
bool
 
-config GENERIC_UCMPDI2
+config GENERIC_LIB_UCMPDI2
bool
diff --git a/lib/Makefile b/lib/Makefile
index a90d4fcd748f..7425e177f08c 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -253,9 +253,9 @@ obj-$(CONFIG_SBITMAP) += sbitmap.o
 obj-$(CONFIG_PARMAN) += parman.o
 
 # GCC library routines
-obj-$(CONFIG_GENERIC_ASHLDI3) += ashldi3.o
-obj-$(CONFIG_GENERIC_ASHRDI3) += ashrdi3.o
-obj-$(CONFIG_GENERIC_LSHRDI3) += lshrdi3.o
-obj-$(CONFIG_GENERIC_MULDI3) += muldi3.o
-obj-$(CONFIG_GENERIC_CMPDI2) += cmpdi2.o
-obj-$(CONFIG_GENERIC_UCMPDI2) += ucmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_ASHLDI3) += ashldi3.o
+obj-$(CONFIG_GENERIC_LIB_ASHRDI3) += ashrdi3.o
+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
-- 
2.7.4

Re: [PATCH v4] isofs compress: Remove VLA usage

[Jan Kara]

On Tue 10-04-18 17:02:29, Kyle Spiers wrote:
> As part of the effort to remove VLAs from the kernel[1], this changes
> the allocation of the bhs and pages arrays from being on the stack to being
> kcalloc()ed. This also allows for the removal of the explicit zeroing
> of bhs.
> 
> https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Kyle Spiers 
> ---
> Fix sparc64 build
> Fix Error recovery Mistakes

Thanks, the patch looks good now and I've merged it to my tree and will
push it to Linus (likely for rc2).

Honza

> ---
>  fs/isofs/compress.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/isofs/compress.c b/fs/isofs/compress.c
> index 9bb2fe35799d..10205ececc27 100644
> --- a/fs/isofs/compress.c
> +++ b/fs/isofs/compress.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -59,7 +60,7 @@ static loff_t zisofs_uncompress_block(struct inode *inode, 
> loff_t block_start,
>   >> bufshift;
>   int haveblocks;
>   blkcnt_t blocknum;
> - struct buffer_head *bhs[needblocks + 1];
> + struct buffer_head **bhs;
>   int curbh, curpage;
>  
>   if (block_size > deflateBound(1UL << zisofs_block_shift)) {
> @@ -80,7 +81,11 @@ static loff_t zisofs_uncompress_block(struct inode *inode, 
> loff_t block_start,
>  
>   /* Because zlib is not thread-safe, do all the I/O at the top. */
>   blocknum = block_start >> bufshift;
> - memset(bhs, 0, (needblocks + 1) * sizeof(struct buffer_head *));
> + bhs = kcalloc(needblocks + 1, sizeof(*bhs), GFP_KERNEL);
> + if (!bhs) {
> + *errp = -ENOMEM;
> + return 0;
> + }
>   haveblocks = isofs_get_blocks(inode, blocknum, bhs, needblocks);
>   ll_rw_block(REQ_OP_READ, 0, haveblocks, bhs);
>  
> @@ -190,6 +195,7 @@ static loff_t zisofs_uncompress_block(struct inode 
> *inode, loff_t block_start,
>  b_eio:
>   for (i = 0; i < haveblocks; i++)
>   brelse(bhs[i]);
> + kfree(bhs);
>   return stream.total_out;
>  }
>  
> @@ -305,7 +311,7 @@ static int zisofs_readpage(struct file *file, struct page 
> *page)
>   unsigned int zisofs_pages_per_cblock =
>   PAGE_SHIFT <= zisofs_block_shift ?
>   (1 << (zisofs_block_shift - PAGE_SHIFT)) : 0;
> - struct page *pages[max_t(unsigned, zisofs_pages_per_cblock, 1)];
> + struct page **pages;
>   pgoff_t index = page->index, end_index;
>  
>   end_index = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> @@ -330,6 +336,12 @@ static int zisofs_readpage(struct file *file, struct 
> page *page)
>   full_page = 0;
>   pcount = 1;
>   }
> + pages = kcalloc(max_t(unsigned int, zisofs_pages_per_cblock, 1),
> + sizeof(*pages), GFP_KERNEL);
> + if (!pages) {
> + unlock_page(page);
> + return -ENOMEM;
> + }
>   pages[full_page] = page;
>  
>   for (i = 0; i < pcount; i++, index++) {
> @@ -357,6 +369,7 @@ static int zisofs_readpage(struct file *file, struct page 
> *page)
>   }   
>  
>   /* At this point, err contains 0 or -EIO depending on the "critical" 
> page */
> + kfree(pages);
>   return err;
>  }
>  
> -- 
> 2.17.0.484.g0c8726318c-goog
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] sched/fair: schedutil: update only with all info available

[Vincent Guittot]

On 6 April 2018 at 19:28, Patrick Bellasi  wrote:

>  }
> @@ -5454,8 +5441,11 @@ static void dequeue_task_fair(struct rq *rq, struct 
> task_struct *p, int flags)
> update_cfs_group(se);
> }
>
> -   if (!se)
> +   /* The task is no more visible from the root cfs_rq */
> +   if (!se) {
> sub_nr_running(rq, 1);
> +   cpufreq_update_util(rq, 0);

call to cpufreq_update_util() should be done after util_est_dequeue()

> +   }
>
> util_est_dequeue(>cfs, p, task_sleep);
> hrtick_update(rq);

[PATCH] panel-jdi-lt070me05000: Replace mdelay with usleep_range and msleep in jdi_panel_init

[Jia-Ju Bai]

jdi_panel_init() is never called in atomic context.

Despite never getting called from atomic context, jdi_panel_init()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() 
and msleep() to avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 5b2340e..46b12a6 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -128,7 +128,7 @@ static int jdi_panel_init(struct jdi_panel *jdi)
return ret;
}
 
-   mdelay(10);
+   usleep_range(1, 11000);
 
/* Interface setting, video mode */
ret = mipi_dsi_generic_write(dsi, (u8[])
@@ -139,7 +139,7 @@ static int jdi_panel_init(struct jdi_panel *jdi)
return ret;
}
 
-   mdelay(20);
+   msleep(20);
 
ret = mipi_dsi_generic_write(dsi, (u8[]){0xB0, 0x03}, 2);
if (ret < 0) {
-- 
1.9.1

[GIT PULL] Thermal management updates for v4.17-rc1

[Zhang Rui]

Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.17-rc1 with
top-most commit f8837aac36cdc7430422cd65f4466071b42654bb:

  Merge branches 'thermal-core' and 'thermal-soc' into next (2018-04-02 
21:49:31 +0800)

on top of commit 0c8efd610b58cb23cefdfa12015799079aef94ae:

  Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)

Specifics:

- Fix race condition in imx_thermal_probe(). (Mikhail Lappo)

- Add cooling device's statistics in sysfs. (Viresh Kumar)

- add support for i.MX7 thermal sensor in imx_thermal driver. (Anson
Huang)

- add support for MT7622 SoC in mtk_thermal driver. (Sean Wang)

- Remove unused min/max cpu cooling DT property. (Viresh Kumar).

- A series of fixes on exynos driver. (Bartlomiej Zolnierkiewicz,
Maciej Purski, Marek Szyprowski)

thanks,
rui




Anson Huang (1):
  thermal: imx: add i.MX7 thermal sensor support

Bartlomiej Zolnierkiewicz (10):
  thermal: exynos: remove unused "type" field from struct
exynos_tmu_platform_data
  thermal: exynos: remove parsing of samsung,
tmu_default_temp_offset property
  thermal: exynos: remove parsing of samsung, tmu_[first,
second]_point_trim properties
  thermal: exynos: remove parsing of samsung, tmu_noise_cancel_mode
property
  thermal: exynos: remove parsing of samsung, tmu[_min,
_max]_efuse_value properties
  thermal: exynos: remove parsing of samsung, tmu_reference_voltage
property
  thermal: exynos: remove parsing of samsung,tmu_gain property
  thermal: exynos: remove parsing of samsung, tmu_cal_type property
  thermal: exynos: remove separate exynos_tmu.h header file
  dt-bindings: thermal: remove no longer needed samsung thermal
properties

Maciej Purski (1):
  thermal: exynos: Read soc_type from match data

Marek Szyprowski (2):
  thermal: exynos: Reading temperature makes sense only when TMU is
turned on
  thermal: exynos: Propagate error value from tmu_read()

Mikhail Lappo (1):
  thermal: imx: Fix race condition in imx_thermal_probe()

Sean Wang (2):
  dt-bindings: thermal: add binding for MT7622 SoC
  thermal: mediatek: add support for MT7622 SoC

Viresh Kumar (2):
  dt-bindings: thermal: Remove "cooling-{min|max}-level" properties
  thermal: Add cooling device's statistics in sysfs

Zhang Rui (2):
  Merge branch 'linus' of git://git.kernel.org/.../evalenti/linux-
soc-thermal into thermal-soc
  Merge branches 'thermal-core' and 'thermal-soc' into next

 .../devicetree/bindings/thermal/exynos-thermal.txt |  23 +-
 .../devicetree/bindings/thermal/imx-thermal.txt|   9 +-
 .../bindings/thermal/mediatek-thermal.txt  |   1 +
 .../devicetree/bindings/thermal/thermal.txt|  16 +-
 Documentation/thermal/sysfs-api.txt|  31 +++
 drivers/thermal/Kconfig|   7 +
 drivers/thermal/imx_thermal.c  | 301
-
 drivers/thermal/mtk_thermal.c  |  35 +++
 drivers/thermal/samsung/exynos_tmu.c   | 268 +--
---
 drivers/thermal/samsung/exynos_tmu.h   |  75 -
 drivers/thermal/thermal_core.c |   3 +-
 drivers/thermal/thermal_core.h |  10 +
 drivers/thermal/thermal_helpers.c  |   5 +-
 drivers/thermal/thermal_sysfs.c| 225
+++
 include/linux/thermal.h|   1 +
 15 files changed, 706 insertions(+), 304 deletions(-)
 delete mode 100644 drivers/thermal/samsung/exynos_tmu.h

[PATCH 1/2 v2] ide: pdc202xx_new: Replace mdelay with usleep_range in detect_pll_input_clock

[Jia-Ju Bai]

detect_pll_input_clock() is never called in atomic context.

detect_pll_input_clock() is only called by init_chipset_pdcnew(), which 
is set as ".init_chipset" in struct ide_port_info.
This function is not called in atomic context.

Despite never getting called from atomic context, detect_pll_input_clock()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
---
v2:
* Correct wrong usage of usleep_range() in v1.
  Thank Sergei for pointing it out.
---
 drivers/ide/pdc202xx_new.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c
index b33646b..6afa66d 100644
--- a/drivers/ide/pdc202xx_new.c
+++ b/drivers/ide/pdc202xx_new.c
@@ -258,7 +258,7 @@ static long detect_pll_input_clock(unsigned long dma_base)
outb(scr1 | 0x40, dma_base + 0x03);
 
/* Let the counter run for 10 ms. */
-   mdelay(10);
+   usleep_range(1, 11000);
 
end_count = read_counter(dma_base);
end_time = ktime_get();
-- 
1.9.1

Re: [PATCH v3 2/2] mm: remove odd HAVE_PTE_SPECIAL

[Laurent Dufour]

On 11/04/2018 10:33, Michal Hocko wrote:
> On Wed 11-04-18 10:03:36, Laurent Dufour wrote:
>> @@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, 
>> unsigned long addr,
>>  
>>  if (is_zero_pfn(pfn))
>>  return NULL;
>> -check_pfn:
>> +
>> +check_pfn: __maybe_unused
>>  if (unlikely(pfn > highest_memmap_pfn)) {
>>  print_bad_pte(vma, addr, pte, NULL);
>>  return NULL;
>> @@ -891,7 +887,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, 
>> unsigned long addr,
>>   * NOTE! We still have PageReserved() pages in the page tables.
>>   * eg. VDSO mappings can cause them to exist.
>>   */
>> -out:
>> +out: __maybe_unused
>>  return pfn_to_page(pfn);
> 
> Why do we need this ugliness all of the sudden?
Indeed the compiler doesn't complaint but in theory it should since these
labels are not used depending on CONFIG_ARCH_HAS_PTE_SPECIAL.

[PATCH v2 00/12] refactor dts and add support for more boards

[sean.wang]

From: Sean Wang 

Changes since v1:
- Dropped several patches which have been merged.
- Rebased to linux-next-20180410 where those dependent patches including
  [1] and [2] all have been got merged.
- Revised according to suggestions and comments on v1, where the major work is
  to put board-specific nodes into DTS files and to leave the common nodes
  among boards in DTSI files as done in patch 7,9,10,11 and 12.
- Merged Ryder Lee's patch for update audio nodes reflecting the latest
  bindings.
- Revised commit message.

The series is to refactor current .dts for allowing more boards can properly
join and reuse almost the same device node definitions.

Before we're doing that, some works about enhancements and fixups are being
made on the dt-binding document and .dts files. In addition, the series has to
depend on the patch [1][2]. Otherwise, certain build failure would have an
occurrence.

[1] arm: dts: mt7623: add PCIe related nodes
http://lists.infradead.org/pipermail/linux-mediatek/2018-February/012053.html

[2] dt-bindings: soc: add header files required for MT7623A SCPSYS dt-binding
http://lists.infradead.org/pipermail/linux-mediatek/2018-February/011930.html

Ryder Lee (1):
  arm: dts: mediatek: modify audio related nodes for both MT2701 and
MT7623

Sean Wang (11):
  dt-bindings: cpufreq: mediatek: use - instead of _ in examples
  arm: dts: mediatek: converted to using SPDX identifiers
  arm: dts: mt7623: fix invalid memory node being generated
  arm: dts: mt7623: fix available memory size on bananapi-r2
  arm: dts: mt7623: fix all Warnings (unit_address_vs_reg)
  arm: dts: mt7623: add BTIF, HSDMA and SPI-NOR device nodes
  arm: dts: mt6323: move node mt6323 leds to mt6323.dtsi
  arm: dts: mt7623: extend common file reused by all boards with MT7623
SoCs
  arm: dts: mt7623: add MT7623A SoC level DTS
  arm: dts: mt7623: add MT7623A reference boards
  arm: dts: mt7623: add MT7623N reference board with eMMC

 .../bindings/cpufreq/cpufreq-mediatek.txt  |   6 +-
 arch/arm/boot/dts/Makefile |   3 +
 arch/arm/boot/dts/mt2701-evb.dts   |   9 +-
 arch/arm/boot/dts/mt2701.dtsi  | 197 
 arch/arm/boot/dts/mt6323.dtsi  |  17 +-
 arch/arm/boot/dts/mt6580-evbp1.dts |   9 +-
 arch/arm/boot/dts/mt6580.dtsi  |   9 +-
 arch/arm/boot/dts/mt6589-aquaris5.dts  |  10 +-
 arch/arm/boot/dts/mt6589.dtsi  |  12 +-
 arch/arm/boot/dts/mt6592-evb.dts   |   9 +-
 arch/arm/boot/dts/mt6592.dtsi  |   9 +-
 arch/arm/boot/dts/mt7623.dtsi  | 537 -
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 291 +++
 arch/arm/boot/dts/mt7623a-rfb-nand.dts | 337 +
 arch/arm/boot/dts/mt7623a.dtsi |  44 ++
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts  | 279 ++-
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 326 +
 arch/arm/boot/dts/mt7623n-rfb-nand.dts |  40 +-
 arch/arm/boot/dts/mt7623n-rfb.dtsi |  12 +-
 arch/arm/boot/dts/mt8127-moose.dts |   9 +-
 arch/arm/boot/dts/mt8127.dtsi  |   9 +-
 arch/arm/boot/dts/mt8135-evbp1.dts |   9 +-
 arch/arm/boot/dts/mt8135.dtsi  |   9 +-
 23 files changed, 1576 insertions(+), 616 deletions(-)
 create mode 100644 arch/arm/boot/dts/mt7623a-rfb-emmc.dts
 create mode 100644 arch/arm/boot/dts/mt7623a-rfb-nand.dts
 create mode 100644 arch/arm/boot/dts/mt7623a.dtsi
 create mode 100644 arch/arm/boot/dts/mt7623n-rfb-emmc.dts

-- 
2.7.4

[PATCH v2 07/12] arm: dts: mt6323: move node mt6323 leds to mt6323.dtsi

[sean.wang]

From: Sean Wang 

Since those LEDs are parts of PMIC MT6323, it is reasonable to merge
those LEDs node definition back into mt6323.dtsi. This way can improve
the reusability of those nodes among different boards with the same PMIC.

And LED is very much board specific and thus the mt6323.dtsi only includes
the parent node here and leave these child nodes in the board specific
dts file.

Signed-off-by: Sean Wang 
Cc: Lee Jones 
Cc: Rob Herring 
---
 arch/arm/boot/dts/mt6323.dtsi |  9 -
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 50 ---
 2 files changed, 30 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boot/dts/mt6323.dtsi b/arch/arm/boot/dts/mt6323.dtsi
index 958980c..ba39740 100644
--- a/arch/arm/boot/dts/mt6323.dtsi
+++ b/arch/arm/boot/dts/mt6323.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) 2017 MediaTek Inc.
+ * Copyright (c) 2017-2018 MediaTek Inc.
  * Author: John Crispin 
  *Sean Wang 
  *
@@ -14,6 +14,13 @@
interrupt-controller;
#interrupt-cells = <2>;
 
+   mt6323_leds: leds {
+   compatible = "mediatek,mt6323-led";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
mt6323regulator: mt6323regulator{
compatible = "mediatek,mt6323-regulator";
 
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts 
b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 1fd6f55..395912e 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -237,6 +237,28 @@
vqmmc-supply = <_3p3v>;
 };
 
+_leds {
+   status = "okay";
+
+   led@0 {
+   reg = <0>;
+   label = "bpi-r2:isink:green";
+   default-state = "off";
+   };
+
+   led@1 {
+   reg = <1>;
+   label = "bpi-r2:isink:red";
+   default-state = "off";
+   };
+
+   led@2 {
+   reg = <2>;
+   label = "bpi-r2:isink:blue";
+   default-state = "off";
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_default>;
@@ -482,34 +504,6 @@
status = "okay";
 };
 
- {
-   mt6323 {
-   mt6323led: led {
-   compatible = "mediatek,mt6323-led";
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   led@0 {
-   reg = <0>;
-   label = "bpi-r2:isink:green";
-   default-state = "off";
-   };
-
-   led@1 {
-   reg = <1>;
-   label = "bpi-r2:isink:red";
-   default-state = "off";
-   };
-
-   led@2 {
-   reg = <2>;
-   label = "bpi-r2:isink:blue";
-   default-state = "off";
-   };
-   };
-   };
-};
-
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.7.4

[PATCH v2 09/12] arm: dts: mt7623: extend common file reused by all boards with MT7623 SoCs

[sean.wang]

From: Sean Wang 

Move all possible setups for pio into SoC level DTSI file mt7623.dtsi in
order to introduce more boards such as official MT7623A reference boards
without copy-n-pasting almost the same content of nodes in pio into every
new file.

So, it should be better to reuse those nodes by consolidating them into
the common file mt7623.dtsi from the current existent DTS and allow new
DTS files to refer to them.

Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623.dtsi | 246 ++
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 217 ---
 arch/arm/boot/dts/mt7623n-rfb-nand.dts|  31 
 3 files changed, 246 insertions(+), 248 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index eef81d2..01893858 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -935,3 +935,249 @@
status = "disabled";
};
 };
+
+ {
+   cir_pins_a:cir-default {
+   pins-cir {
+   pinmux = ;
+   bias-disable;
+   };
+   };
+
+   i2c0_pins_a: i2c0-default {
+   pins-i2c0 {
+   pinmux = ,
+;
+   bias-disable;
+   };
+   };
+
+   i2c1_pins_a: i2c1-default {
+   pin-i2c1 {
+   pinmux = ,
+;
+   bias-disable;
+   };
+   };
+
+   i2s0_pins_a: i2s0-default {
+   pin-i2s0 {
+   pinmux = ,
+,
+,
+,
+;
+   drive-strength = ;
+   bias-pull-down;
+   };
+   };
+
+   i2s1_pins_a: i2s1-default {
+   pin-i2s1 {
+   pinmux = ,
+,
+,
+,
+;
+   drive-strength = ;
+   bias-pull-down;
+   };
+   };
+
+   key_pins_a: keys-alt {
+   pins-keys {
+   pinmux = ,
+ ;
+   input-enable;
+   };
+   };
+
+   led_pins_a: leds-alt {
+   pins-leds {
+   pinmux = ,
+,
+;
+   };
+   };
+
+   mmc0_pins_default: mmc0default {
+   pins-cmd-dat {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   input-enable;
+   bias-pull-up;
+   };
+
+   pins-clk {
+   pinmux = ;
+   bias-pull-down;
+   };
+
+   pins-rst {
+   pinmux = ;
+   bias-pull-up;
+   };
+   };
+
+   mmc0_pins_uhs: mmc0 {
+   pins-cmd-dat {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   input-enable;
+   drive-strength = ;
+   bias-pull-up = ;
+   };
+
+   pins-clk {
+   pinmux = ;
+   drive-strength = ;
+   bias-pull-down = ;
+   };
+
+   pins-rst {
+   pinmux = ;
+   bias-pull-up;
+   };
+   };
+
+   mmc1_pins_default: mmc1default {
+   pins-cmd-dat {
+   pinmux = ,
+,
+,
+,
+;
+   input-enable;
+   drive-strength = ;
+   bias-pull-up = ;
+   };
+
+   pins-clk {
+   pinmux = ;
+   bias-pull-down;
+   drive-strength = ;
+   };
+
+   pins-wp {
+   pinmux = ;
+   input-enable;
+   bias-pull-up;
+   };
+
+   

[PATCH v2 01/12] dt-bindings: cpufreq: mediatek: use - instead of _ in examples

[sean.wang]

From: Sean Wang 

It should be good that no use "_" is in examples. Consequently,
those nodes in certain files which have an inappropriate name containing
"_" are all being replaced with "-".

Signed-off-by: Sean Wang 
Cc: "Rafael J. Wysocki" 
Cc: Viresh Kumar 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Acked-by: Viresh Kumar 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
index d36f07e..38cfbb5 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
@@ -26,7 +26,7 @@ Optional properties:
 
 Example 1 (MT7623 SoC):
 
-   cpu_opp_table: opp_table {
+   cpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-shared;
 
@@ -86,7 +86,7 @@ Example 1 (MT7623 SoC):
};
 
 Example 2 (MT8173 SoC):
-   cpu_opp_table_a: opp_table_a {
+   cpu_opp_table_a: opp-table-a {
compatible = "operating-points-v2";
opp-shared;
 
@@ -131,7 +131,7 @@ Example 2 (MT8173 SoC):
};
};
 
-   cpu_opp_table_b: opp_table_b {
+   cpu_opp_table_b: opp-table-b {
compatible = "operating-points-v2";
opp-shared;
 
-- 
2.7.4

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Daniel Lezcano]

Hi Viresh,

thanks for the review.


On 11/04/2018 10:51, Viresh Kumar wrote:

[ ... ]

>> +void __init cpuidle_cooling_register(void)
>> +{
>> +struct cpuidle_cooling_device *idle_cdev = NULL;
>> +struct thermal_cooling_device *cdev;
>> +struct device_node *np;
>> +cpumask_var_t cpumask;
> 
> maybe call it clustermask ?

Yeah, sounds better.

>> +cdev = thermal_of_cooling_device_register(np, dev_name,
>> +  idle_cdev,
>> +  _cooling_ops);
>> +if (IS_ERR(cdev)) {
>> +ret = PTR_ERR(cdev);
>> +goto out;
>> +}
>> +
>> +idle_cdev->cdev = cdev;
>> +cpumask_set_cpu(cluster_id, cpumask);
>> +}
>> +
>> +ret = smpboot_register_percpu_thread(_cooling_threads);
>> +if (ret)
>> +goto out;
>> +
>> +pr_info("Created cpuidle cooling device\n");
>> +out:
>> +free_cpumask_var(cpumask);
>> +
>> +if (ret) {
>> +cpuidle_cooling_unregister();
>> +pr_err("Failed to create idle cooling device (%d)\n", ret);
>> +}
> 
> Maybe rearrange it a bit:
> 
> + ret = smpboot_register_percpu_thread(_cooling_threads);
> +
> +out:
> + if (ret) {
> + cpuidle_cooling_unregister();
> + pr_err("Failed to create idle cooling device (%d)\n", ret);
> + } else {
> + pr_info("Created cpuidle cooling devices\n");
> +   }
> +
> + free_cpumask_var(cpumask);
> 
> ??

I usually tend to avoid using 'else' statements when possible (a coding
style practice) but if you prefer this version I'm fine with that.



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[H. Nikolaus Schaller]

> Am 11.04.2018 um 11:12 schrieb Ladislav Michl :
> 
> On Wed, Apr 11, 2018 at 10:52:01AM +0200, Boris Brezillon wrote:
>> On Wed, 11 Apr 2018 10:27:46 +0200
>> Ladislav Michl  wrote:
>> 
>>> On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote:
 On Wed, 11 Apr 2018 09:36:56 +0200
 Ladislav Michl  wrote:
 
> Hi Boris,
> 
> On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:  
>>> [...]
>> Not sure this approach is safe on all archs: if the cache is VIVT or
>> VIPT, you may have several entries pointing to the same phys page, and
>> then, when dma_map_page() does its cache maintenance operations, it's
>> only taking one of these entries into account.
> 
> Hmm, I used the same approach Samsung OneNAND driver does since commit
> dcf08227e964a53a2cb39130b74842c7dcb6adde.
> Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> is VIPT. In that case samsung's driver code has the same problem.
> 
>> In other parts of the MTD subsystem, we tend to not do DMA on buffers
>> that have been vmalloc-ed.
>> 
>> You can do something like
>> 
>>  if (virt_addr_valid(buf))
>>  /* Use DMA */
>>  else
>>  /*
>>   * Do not use DMA, or use a bounce buffer
>>   * allocated with kmalloc
>>   */
> 
> Okay, I'll use this approach then, but first I'd like to be sure above is
> correct. Anyone?  
 
 See this discussion [1]. The problem came up a few times already, so
 might find other threads describing why it's not safe.
 
 [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html
   
>>> 
>>> Question was more likely whenever there might exist more that one mapping
>>> of the same page.
>> 
>> I'm clearly not an expert, so I might be wrong, but I think a physical
>> page can be both in the identity mapping and mapped in the vmalloc
>> space. Now, is there a real risk that both ends are accessed in
>> parallel thus making different cache entries pointing to the same phys
>> page dirty, I'm not sure. Or maybe there are other corner case, but
>> you'll have to ask Russell (or any other ARM expert) to get a clearer
>> answer.
> 
> Thank you anyway. As DMA was disabled completely for all DT enabled boards
> until 4.16 let's play safe and disable it for HIGHMEM case as you suggested.
> Later, we might eventually use the same {read,write}_bufferram for both
> OMAP and S5PC110.
> 
>>> But okay, I'll disable DMA for highmem. Patch will follow.
>>> 
>>> ladis
> 
> Andreas, Nikolaus, could you please test patch bellow? It is against
> linux.git and should apply also against 4.16 once you modify path.

Works with v4.16!

I have done "tar cf /dev/null /mnt/nand" and have only
got some fixable bit flips. Writing a test file to OneNAND
also worked and doing a sync did move the weak block to a new PEB.

So I think read & write works again.

> 
> Thank you,
>   ladis

BR and thanks,
Nikolaus

> 
> --- >8 ---
> 
> From: Ladislav Michl 
> Subject: [PATCH] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers
> 
> dma_map_single doesn't get the proper DMA address for vmalloced area,
> so disable DMA in this case.
> 
> Signed-off-by: Ladislav Michl 
> Reported-by: "H. Nikolaus Schaller" 
> ---
> drivers/mtd/nand/onenand/omap2.c | 105 +++
> 1 file changed, 38 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/mtd/nand/onenand/omap2.c 
> b/drivers/mtd/nand/onenand/omap2.c
> index 9c159f0dd9a6..321137158ff3 100644
> --- a/drivers/mtd/nand/onenand/omap2.c
> +++ b/drivers/mtd/nand/onenand/omap2.c
> @@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
> *mtd, int area,
> {
>   struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
>   struct onenand_chip *this = mtd->priv;
> - dma_addr_t dma_src, dma_dst;
> - int bram_offset;
> + struct device *dev = >pdev->dev;
>   void *buf = (void *)buffer;
> + dma_addr_t dma_src, dma_dst;
> + int bram_offset, err;
>   size_t xtra;
> - int ret;
> 
>   bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> - if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> - goto out_copy;
> -
> - /* panic_write() may be in an interrupt context */
> - if (in_interrupt() || oops_in_progress)
> + /*
> +  * If the buffer address is not DMA-able, len is not long enough to make
> +  * DMA transfers profitable or panic_write() may be in an interrupt
> +  * context fallback to PIO mode.
> +  */
> + if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
> + count < 384 || in_interrupt() || 

Re: [PATCH v2 3/9] lib/vsprintf: Make strspec global

[Petr Mladek]

On Fri 2018-02-16 23:07:05, Andy Shevchenko wrote:
> There are places where default specification to print strings
> is in use.
> 
> Make it global and convert existing users.
> 
> Signed-off-by: Andy Shevchenko 

Reviewed-by: Petr Mladek 

I have pushed it into printk.git, branch for-4.18-vsprintf-cleanup.

Best Regards,
Petr

Re: [PATCH v2 2/9] lib/vsprintf: Make dec_spec global

[Petr Mladek]

On Fri 2018-02-16 23:07:04, Andy Shevchenko wrote:
> There are places where default specification to print decimal numbers
> is in use.
> 
> Make it global and convert existing users.
> 
> Signed-off-by: Andy Shevchenko 

Reviewed-by: Petr Mladek 

I have pushed it into printk.git, branch for-4.18-vsprintf-cleanup.

Best Regards,
Petr

Re: [PATCH] bug.h: Work around GCC PR82365 in BUG()

[James Hogan]

On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote:
> On Wed, Apr 11, 2018 at 12:48 AM, James Hogan  wrote:
> > Before I forward port those patches to add .insn for MIPS, is that sort
> > of approach (an arch specific asm/compiler-gcc.h to allow MIPS to
> > override barrier_before_unreachable()) an acceptable fix?
> 
> That sounds fine to me. However, I would suggest making that
> asm/compiler.h instead of asm/compiler-gcc.h, so we can also
> use the same file to include workarounds for clang if needed.

Yes, though there are a few asm/compiler.h's already, and the alpha one
includes linux/compiler.h before undefining inline, so seems to have its
own specific purpose...

Cheers
James


signature.asc
Description: Digital signature

[PATCH] lan78xx: Correctly indicate invalid OTP

[Phil Elwell]

lan78xx_read_otp tries to return -EINVAL in the event of invalid OTP
content, but the value gets overwritten before it is returned and the
read goes ahead anyway. Make the read conditional as it should be
and preserve the error code.

Signed-off-by: Phil Elwell 
---
 drivers/net/usb/lan78xx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 55a78eb..32cf217 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -928,7 +928,8 @@ static int lan78xx_read_otp(struct lan78xx_net *dev, u32 
offset,
offset += 0x100;
else
ret = -EINVAL;
-   ret = lan78xx_read_raw_otp(dev, offset, length, data);
+   if (!ret)
+   ret = lan78xx_read_raw_otp(dev, offset, length, data);
}
 
return ret;
-- 
2.7.4

Re: [PATCH] bug.h: Work around GCC PR82365 in BUG()

[James Hogan]

On Wed, Apr 11, 2018 at 12:08:51PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 11, 2018 at 11:54 AM, James Hogan  wrote:
> > On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote:
> >> On Wed, Apr 11, 2018 at 12:48 AM, James Hogan  wrote:
> >> > Before I forward port those patches to add .insn for MIPS, is that sort
> >> > of approach (an arch specific asm/compiler-gcc.h to allow MIPS to
> >> > override barrier_before_unreachable()) an acceptable fix?
> >>
> >> That sounds fine to me. However, I would suggest making that
> >> asm/compiler.h instead of asm/compiler-gcc.h, so we can also
> >> use the same file to include workarounds for clang if needed.
> >
> > Yes, though there are a few asm/compiler.h's already, and the alpha one
> > includes linux/compiler.h before undefining inline, so seems to have its
> > own specific purpose...
> 
> Interesting. For the other ones, including asm/compiler.h from 
> linux/compiler.h
> seems appropriate though, so the question would be what to do with the
> alpha case. I think we can simply remove that header file and replace
> it with this patch:
> 
> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
> index b2022885ced8..5502404f54cd 100644
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -81,6 +81,9 @@ config PGTABLE_LEVELS
> int
> default 3
> 
> +config OPTIMIZE_INLINING
> +   def_bool y
> +
>  source "init/Kconfig"
>  source "kernel/Kconfig.freezer"
> 
> which should have the same effect.

Hmm yes, and I suppose alpha would need ARCH_SUPPORTS_OPTIMIZED_INLINING
too. I'll give it a try.

Cheers
James


signature.asc
Description: Digital signature