Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

[Sergey Senozhatsky]

On (03/22/16 11:13), Byungchul Park wrote:
[..]

what about a "normal" case, when things are not going to explode printk(),
but we have several lockups on the same lock (which is probably more
likely than printk recursion)?

suppose:
- there are 8 CPUs on the system
- 1 cpus owns the spin_lock for too long
- 4 cpus are trying to lock the spin_lock w/o any success
- so all 4 trigger spin_dump.

what we have at the moment, is that all 4 CPUs will report a lockup,
but with this static pointer only X (between 1 and 4, depending on the
timing; on how fast spin_dump() will return (logbuf lock can
be busy for a while); etc.) CPUs will do so.

-ss

Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

[Sergey Senozhatsky]

On (03/22/16 11:13), Byungchul Park wrote:
[..]

what about a "normal" case, when things are not going to explode printk(),
but we have several lockups on the same lock (which is probably more
likely than printk recursion)?

suppose:
- there are 8 CPUs on the system
- 1 cpus owns the spin_lock for too long
- 4 cpus are trying to lock the spin_lock w/o any success
- so all 4 trigger spin_dump.

what we have at the moment, is that all 4 CPUs will report a lockup,
but with this static pointer only X (between 1 and 4, depending on the
timing; on how fast spin_dump() will return (logbuf lock can
be busy for a while); etc.) CPUs will do so.

-ss

Re: [PATCH v2 13/18] mm/compaction: support non-lru movable page migration

[Joonsoo Kim]

On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote:
> We have allowed migration for only LRU pages until now and it was
> enough to make high-order pages. But recently, embedded system(e.g.,
> webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
> so we have seen several reports about troubles of small high-order
> allocation. For fixing the problem, there were several efforts
> (e,g,. enhance compaction algorithm, SLUB fallback to 0-order page,
> reserved memory, vmalloc and so on) but if there are lots of
> non-movable pages in system, their solutions are void in the long run.
> 
> So, this patch is to support facility to change non-movable pages
> with movable. For the feature, this patch introduces functions related
> to migration to address_space_operations as well as some page flags.
> 
> Basically, this patch supports two page-flags and two functions related
> to page migration. The flag and page->mapping stability are protected
> by PG_lock.
> 
>   PG_movable
>   PG_isolated
> 
>   bool (*isolate_page) (struct page *, isolate_mode_t);
>   void (*putback_page) (struct page *);
> 
> Duty of subsystem want to make their pages as migratable are
> as follows:
> 
> 1. It should register address_space to page->mapping then mark
> the page as PG_movable via __SetPageMovable.
> 
> 2. It should mark the page as PG_isolated via SetPageIsolated
> if isolation is sucessful and return true.
> 
> 3. If migration is successful, it should clear PG_isolated and
> PG_movable of the page for free preparation then release the
> reference of the page to free.
> 
> 4. If migration fails, putback function of subsystem should
> clear PG_isolated via ClearPageIsolated.

I think that this feature needs a separate document to describe
requirement of each step in more detail. For example, #1 can be
possible without holding a lock? I'm not sure because you lock
the page when implementing zsmalloc page migration in 15th patch.

#3 also need more explanation. Before release, we need to
unregister address_space. I guess that it needs to be done
in migratepage() but there is no explanation.

> 
> Cc: Vlastimil Babka 
> Cc: Mel Gorman 
> Cc: Hugh Dickins 
> Cc: dri-de...@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Gioh Kim 
> Signed-off-by: Minchan Kim 
> ---
>  Documentation/filesystems/Locking  |   4 +
>  Documentation/filesystems/vfs.txt  |   5 ++
>  fs/proc/page.c |   3 +
>  include/linux/fs.h |   2 +
>  include/linux/migrate.h|   2 +
>  include/linux/page-flags.h |  29 
>  include/uapi/linux/kernel-page-flags.h |   1 +
>  mm/compaction.c|  14 +++-
>  mm/migrate.c   | 132 
> +
>  9 files changed, 177 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/filesystems/Locking 
> b/Documentation/filesystems/Locking
> index 619af9bfdcb3..0bb79560abb3 100644
> --- a/Documentation/filesystems/Locking
> +++ b/Documentation/filesystems/Locking
> @@ -195,7 +195,9 @@ unlocks and drops the reference.
>   int (*releasepage) (struct page *, int);
>   void (*freepage)(struct page *);
>   int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset);
> + bool (*isolate_page) (struct page *, isolate_mode_t);
>   int (*migratepage)(struct address_space *, struct page *, struct page 
> *);
> + void (*putback_page) (struct page *);
>   int (*launder_page)(struct page *);
>   int (*is_partially_uptodate)(struct page *, unsigned long, unsigned 
> long);
>   int (*error_remove_page)(struct address_space *, struct page *);
> @@ -219,7 +221,9 @@ invalidatepage:   yes
>  releasepage: yes
>  freepage:yes
>  direct_IO:
> +isolate_page:yes
>  migratepage: yes (both)
> +putback_page:yes
>  launder_page:yes
>  is_partially_uptodate:   yes
>  error_remove_page:   yes
> diff --git a/Documentation/filesystems/vfs.txt 
> b/Documentation/filesystems/vfs.txt
> index b02a7d598258..4c1b6c3b4bc8 100644
> --- a/Documentation/filesystems/vfs.txt
> +++ b/Documentation/filesystems/vfs.txt
> @@ -592,9 +592,14 @@ struct address_space_operations {
>   int (*releasepage) (struct page *, int);
>   void (*freepage)(struct page *);
>   ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t 
> offset);
> + /* isolate a page for migration */
> + bool (*isolate_page) (struct page *, isolate_mode_t);
>   /* migrate the contents of a page to the specified target */
>   int (*migratepage) (struct page *, struct page *);
> + /* put the page back to right list */
> + void (*putback_page) (struct page *);
>   int (*launder_page) (struct page *);
> +
>   

Re: [PATCH v2 13/18] mm/compaction: support non-lru movable page migration

[Joonsoo Kim]

On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote:
> We have allowed migration for only LRU pages until now and it was
> enough to make high-order pages. But recently, embedded system(e.g.,
> webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
> so we have seen several reports about troubles of small high-order
> allocation. For fixing the problem, there were several efforts
> (e,g,. enhance compaction algorithm, SLUB fallback to 0-order page,
> reserved memory, vmalloc and so on) but if there are lots of
> non-movable pages in system, their solutions are void in the long run.
> 
> So, this patch is to support facility to change non-movable pages
> with movable. For the feature, this patch introduces functions related
> to migration to address_space_operations as well as some page flags.
> 
> Basically, this patch supports two page-flags and two functions related
> to page migration. The flag and page->mapping stability are protected
> by PG_lock.
> 
>   PG_movable
>   PG_isolated
> 
>   bool (*isolate_page) (struct page *, isolate_mode_t);
>   void (*putback_page) (struct page *);
> 
> Duty of subsystem want to make their pages as migratable are
> as follows:
> 
> 1. It should register address_space to page->mapping then mark
> the page as PG_movable via __SetPageMovable.
> 
> 2. It should mark the page as PG_isolated via SetPageIsolated
> if isolation is sucessful and return true.
> 
> 3. If migration is successful, it should clear PG_isolated and
> PG_movable of the page for free preparation then release the
> reference of the page to free.
> 
> 4. If migration fails, putback function of subsystem should
> clear PG_isolated via ClearPageIsolated.

I think that this feature needs a separate document to describe
requirement of each step in more detail. For example, #1 can be
possible without holding a lock? I'm not sure because you lock
the page when implementing zsmalloc page migration in 15th patch.

#3 also need more explanation. Before release, we need to
unregister address_space. I guess that it needs to be done
in migratepage() but there is no explanation.

> 
> Cc: Vlastimil Babka 
> Cc: Mel Gorman 
> Cc: Hugh Dickins 
> Cc: dri-de...@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Gioh Kim 
> Signed-off-by: Minchan Kim 
> ---
>  Documentation/filesystems/Locking  |   4 +
>  Documentation/filesystems/vfs.txt  |   5 ++
>  fs/proc/page.c |   3 +
>  include/linux/fs.h |   2 +
>  include/linux/migrate.h|   2 +
>  include/linux/page-flags.h |  29 
>  include/uapi/linux/kernel-page-flags.h |   1 +
>  mm/compaction.c|  14 +++-
>  mm/migrate.c   | 132 
> +
>  9 files changed, 177 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/filesystems/Locking 
> b/Documentation/filesystems/Locking
> index 619af9bfdcb3..0bb79560abb3 100644
> --- a/Documentation/filesystems/Locking
> +++ b/Documentation/filesystems/Locking
> @@ -195,7 +195,9 @@ unlocks and drops the reference.
>   int (*releasepage) (struct page *, int);
>   void (*freepage)(struct page *);
>   int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset);
> + bool (*isolate_page) (struct page *, isolate_mode_t);
>   int (*migratepage)(struct address_space *, struct page *, struct page 
> *);
> + void (*putback_page) (struct page *);
>   int (*launder_page)(struct page *);
>   int (*is_partially_uptodate)(struct page *, unsigned long, unsigned 
> long);
>   int (*error_remove_page)(struct address_space *, struct page *);
> @@ -219,7 +221,9 @@ invalidatepage:   yes
>  releasepage: yes
>  freepage:yes
>  direct_IO:
> +isolate_page:yes
>  migratepage: yes (both)
> +putback_page:yes
>  launder_page:yes
>  is_partially_uptodate:   yes
>  error_remove_page:   yes
> diff --git a/Documentation/filesystems/vfs.txt 
> b/Documentation/filesystems/vfs.txt
> index b02a7d598258..4c1b6c3b4bc8 100644
> --- a/Documentation/filesystems/vfs.txt
> +++ b/Documentation/filesystems/vfs.txt
> @@ -592,9 +592,14 @@ struct address_space_operations {
>   int (*releasepage) (struct page *, int);
>   void (*freepage)(struct page *);
>   ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t 
> offset);
> + /* isolate a page for migration */
> + bool (*isolate_page) (struct page *, isolate_mode_t);
>   /* migrate the contents of a page to the specified target */
>   int (*migratepage) (struct page *, struct page *);
> + /* put the page back to right list */
> + void (*putback_page) (struct page *);
>   int (*launder_page) (struct page *);
> +
>   int (*is_partially_uptodate) (struct page *, unsigned long,
>   

Re: Nonterministic hang during bootconsole/console handover on ath79

[Antony Pavlov]

On Tue, 22 Mar 2016 00:02:57 +0100
Matthias Schiffer  wrote:

> Hi,
> we're experiencing weird nondeterministic hangs during bootconsole/console
> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
> QCA953x likewise.
> 
> See the log below for the exact place it hangs; the log was taken in during
> a good boot; a bad boot will just hang forever at the marked location. The
> issue is extremely hard to debug, as changing the timing in any way (like
> adding additional printk) will usually make it work without problems. (Even
> recompiling the kernel with the same config, but different uname timestamp
> will make the occurence more or less likely)
> 
> My theory is the following:
> 
> As soon as ttyS0 is detected and installed as the console, there are two
> console drivers active on the serial port at the same time: early0 and
> ttyS0. I suspect that the hang occurs when the primitive early0
> implementation prom_putchar_ar71xx waits indefinitely on THRE,

Can you use EJTAG to prove your theory?

-- 
Best regards,
  Antony Pavlov

Re: Nonterministic hang during bootconsole/console handover on ath79

[Antony Pavlov]

On Tue, 22 Mar 2016 00:02:57 +0100
Matthias Schiffer  wrote:

> Hi,
> we're experiencing weird nondeterministic hangs during bootconsole/console
> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
> QCA953x likewise.
> 
> See the log below for the exact place it hangs; the log was taken in during
> a good boot; a bad boot will just hang forever at the marked location. The
> issue is extremely hard to debug, as changing the timing in any way (like
> adding additional printk) will usually make it work without problems. (Even
> recompiling the kernel with the same config, but different uname timestamp
> will make the occurence more or less likely)
> 
> My theory is the following:
> 
> As soon as ttyS0 is detected and installed as the console, there are two
> console drivers active on the serial port at the same time: early0 and
> ttyS0. I suspect that the hang occurs when the primitive early0
> implementation prom_putchar_ar71xx waits indefinitely on THRE,

Can you use EJTAG to prove your theory?

-- 
Best regards,
  Antony Pavlov

Re: [BUG] packet loss with PROVE_LOCKING, bisected to EDAC fix

[Borislav Petkov]

On Mon, Mar 21, 2016 at 09:42:09PM +, Chris Bainbridge wrote:
> Hi,
> 
> I was testing something on an old server (Dell T105 opteron) and noticed
> packet loss after updating the kernel from 3.10 to 4.5. The test was:
> 
> On Dell run: iperf -s
> On another system: iperf3 -c dell -u -b 20M -l 1k -t 1000
> 
> This sends a 20mbit UDP stream to the Dell. It works fine normally (0%
> packet loss), but when CONFIG_PROVE_LOCKING is enabled there is high
> (35%) packet loss. (DEBUG_LOCKDEP also seems to cause packet loss)
> 
> The packet loss bisected back to:
> 
> commit 88d84ac97378c2f1d5fec9af1e8b7d9a662d6b00
> Author: Borislav Petkov 
> Date:   Fri Jul 19 12:28:25 2013 +0200
> 
> EDAC: Fix lockdep splat

Hmm, how would that cause a packet loss?!

> I have confirmed that the commit preceding this (v3.11-rc1) is fine and
> that 88d84a introduced the bug.

Did you revert this commit ontop of 4.5 and reproduce again? Do you see
the same packet loss?

What kind of hw is that target system, can you send full dmesg and
.config?

Thanks.

-- 
Regards/Gruss,
Boris.

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

Re: [BUG] packet loss with PROVE_LOCKING, bisected to EDAC fix

[Borislav Petkov]

On Mon, Mar 21, 2016 at 09:42:09PM +, Chris Bainbridge wrote:
> Hi,
> 
> I was testing something on an old server (Dell T105 opteron) and noticed
> packet loss after updating the kernel from 3.10 to 4.5. The test was:
> 
> On Dell run: iperf -s
> On another system: iperf3 -c dell -u -b 20M -l 1k -t 1000
> 
> This sends a 20mbit UDP stream to the Dell. It works fine normally (0%
> packet loss), but when CONFIG_PROVE_LOCKING is enabled there is high
> (35%) packet loss. (DEBUG_LOCKDEP also seems to cause packet loss)
> 
> The packet loss bisected back to:
> 
> commit 88d84ac97378c2f1d5fec9af1e8b7d9a662d6b00
> Author: Borislav Petkov 
> Date:   Fri Jul 19 12:28:25 2013 +0200
> 
> EDAC: Fix lockdep splat

Hmm, how would that cause a packet loss?!

> I have confirmed that the commit preceding this (v3.11-rc1) is fine and
> that 88d84a introduced the bug.

Did you revert this commit ontop of 4.5 and reproduce again? Do you see
the same packet loss?

What kind of hw is that target system, can you send full dmesg and
.config?

Thanks.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 31/71] exofs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros

[Boaz Harrosh]

On 03/20/2016 08:40 PM, Kirill A. Shutemov wrote:
> PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago
> with promise that one day it will be possible to implement page cache with
> bigger chunks than PAGE_SIZE.
> 
> This promise never materialized. And unlikely will.
> 
> We have many places where PAGE_CACHE_SIZE assumed to be equal to
> PAGE_SIZE. And it's constant source of confusion on whether PAGE_CACHE_*
> or PAGE_* constant should be used in a particular case, especially on the
> border between fs and mm.
> 
> Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
> breakage to be doable.
> 
> Let's stop pretending that pages in page cache are special. They are not.
> 
> The changes are pretty straight-forward:
> 
>  -  << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;
> 
>  - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
> 
>  - page_cache_get() -> get_page();
> 
>  - page_cache_release() -> put_page();
> 
> Signed-off-by: Kirill A. Shutemov 
> Cc: Boaz Harrosh 

ACK-by: Boaz Harrosh 

Could you please push this through some other maintainer perhaps
the vfs tree?

Thank you Kirill
Boaz

> Cc: Benny Halevy 
> ---
>  fs/exofs/dir.c   | 30 +++---
>  fs/exofs/inode.c | 34 +-
>  fs/exofs/namei.c |  4 ++--
>  3 files changed, 34 insertions(+), 34 deletions(-)
> 
> diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
> index e5bb2abf77f9..547b93cbea63 100644
> --- a/fs/exofs/dir.c
> +++ b/fs/exofs/dir.c
> @@ -41,16 +41,16 @@ static inline unsigned exofs_chunk_size(struct inode 
> *inode)
>  static inline void exofs_put_page(struct page *page)
>  {
>   kunmap(page);
> - page_cache_release(page);
> + put_page(page);
>  }
>  
>  static unsigned exofs_last_byte(struct inode *inode, unsigned long page_nr)
>  {
>   loff_t last_byte = inode->i_size;
>  
> - last_byte -= page_nr << PAGE_CACHE_SHIFT;
> - if (last_byte > PAGE_CACHE_SIZE)
> - last_byte = PAGE_CACHE_SIZE;
> + last_byte -= page_nr << PAGE_SHIFT;
> + if (last_byte > PAGE_SIZE)
> + last_byte = PAGE_SIZE;
>   return last_byte;
>  }
>  
> @@ -85,13 +85,13 @@ static void exofs_check_page(struct page *page)
>   unsigned chunk_size = exofs_chunk_size(dir);
>   char *kaddr = page_address(page);
>   unsigned offs, rec_len;
> - unsigned limit = PAGE_CACHE_SIZE;
> + unsigned limit = PAGE_SIZE;
>   struct exofs_dir_entry *p;
>   char *error;
>  
>   /* if the page is the last one in the directory */
> - if ((dir->i_size >> PAGE_CACHE_SHIFT) == page->index) {
> - limit = dir->i_size & ~PAGE_CACHE_MASK;
> + if ((dir->i_size >> PAGE_SHIFT) == page->index) {
> + limit = dir->i_size & ~PAGE_MASK;
>   if (limit & (chunk_size - 1))
>   goto Ebadsize;
>   if (!limit)
> @@ -138,7 +138,7 @@ bad_entry:
>   EXOFS_ERR(
>   "ERROR [exofs_check_page]: bad entry in directory(0x%lx): %s - "
>   "offset=%lu, inode=0x%llu, rec_len=%d, name_len=%d\n",
> - dir->i_ino, error, (page->index< + dir->i_ino, error, (page->index<   _LLU(le64_to_cpu(p->inode_no)),
>   rec_len, p->name_len);
>   goto fail;
> @@ -147,7 +147,7 @@ Eend:
>   EXOFS_ERR("ERROR [exofs_check_page]: "
>   "entry in directory(0x%lx) spans the page boundary"
>   "offset=%lu, inode=0x%llx\n",
> - dir->i_ino, (page->index< + dir->i_ino, (page->index<   _LLU(le64_to_cpu(p->inode_no)));
>  fail:
>   SetPageChecked(page);
> @@ -237,8 +237,8 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
>  {
>   loff_t pos = ctx->pos;
>   struct inode *inode = file_inode(file);
> - unsigned int offset = pos & ~PAGE_CACHE_MASK;
> - unsigned long n = pos >> PAGE_CACHE_SHIFT;
> + unsigned int offset = pos & ~PAGE_MASK;
> + unsigned long n = pos >> PAGE_SHIFT;
>   unsigned long npages = dir_pages(inode);
>   unsigned chunk_mask = ~(exofs_chunk_size(inode)-1);
>   int need_revalidate = (file->f_version != inode->i_version);
> @@ -254,7 +254,7 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
>   if (IS_ERR(page)) {
>   EXOFS_ERR("ERROR: bad page in directory(0x%lx)\n",
> inode->i_ino);
> - ctx->pos += PAGE_CACHE_SIZE - offset;
> + ctx->pos += PAGE_SIZE - offset;
>   return PTR_ERR(page);
>   }
>   kaddr = page_address(page);
> @@ -262,7 +262,7 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
>   if (offset) {
>

Re: [PATCH 31/71] exofs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros

[Boaz Harrosh]

On 03/20/2016 08:40 PM, Kirill A. Shutemov wrote:
> PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago
> with promise that one day it will be possible to implement page cache with
> bigger chunks than PAGE_SIZE.
> 
> This promise never materialized. And unlikely will.
> 
> We have many places where PAGE_CACHE_SIZE assumed to be equal to
> PAGE_SIZE. And it's constant source of confusion on whether PAGE_CACHE_*
> or PAGE_* constant should be used in a particular case, especially on the
> border between fs and mm.
> 
> Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
> breakage to be doable.
> 
> Let's stop pretending that pages in page cache are special. They are not.
> 
> The changes are pretty straight-forward:
> 
>  -  << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;
> 
>  - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
> 
>  - page_cache_get() -> get_page();
> 
>  - page_cache_release() -> put_page();
> 
> Signed-off-by: Kirill A. Shutemov 
> Cc: Boaz Harrosh 

ACK-by: Boaz Harrosh 

Could you please push this through some other maintainer perhaps
the vfs tree?

Thank you Kirill
Boaz

> Cc: Benny Halevy 
> ---
>  fs/exofs/dir.c   | 30 +++---
>  fs/exofs/inode.c | 34 +-
>  fs/exofs/namei.c |  4 ++--
>  3 files changed, 34 insertions(+), 34 deletions(-)
> 
> diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
> index e5bb2abf77f9..547b93cbea63 100644
> --- a/fs/exofs/dir.c
> +++ b/fs/exofs/dir.c
> @@ -41,16 +41,16 @@ static inline unsigned exofs_chunk_size(struct inode 
> *inode)
>  static inline void exofs_put_page(struct page *page)
>  {
>   kunmap(page);
> - page_cache_release(page);
> + put_page(page);
>  }
>  
>  static unsigned exofs_last_byte(struct inode *inode, unsigned long page_nr)
>  {
>   loff_t last_byte = inode->i_size;
>  
> - last_byte -= page_nr << PAGE_CACHE_SHIFT;
> - if (last_byte > PAGE_CACHE_SIZE)
> - last_byte = PAGE_CACHE_SIZE;
> + last_byte -= page_nr << PAGE_SHIFT;
> + if (last_byte > PAGE_SIZE)
> + last_byte = PAGE_SIZE;
>   return last_byte;
>  }
>  
> @@ -85,13 +85,13 @@ static void exofs_check_page(struct page *page)
>   unsigned chunk_size = exofs_chunk_size(dir);
>   char *kaddr = page_address(page);
>   unsigned offs, rec_len;
> - unsigned limit = PAGE_CACHE_SIZE;
> + unsigned limit = PAGE_SIZE;
>   struct exofs_dir_entry *p;
>   char *error;
>  
>   /* if the page is the last one in the directory */
> - if ((dir->i_size >> PAGE_CACHE_SHIFT) == page->index) {
> - limit = dir->i_size & ~PAGE_CACHE_MASK;
> + if ((dir->i_size >> PAGE_SHIFT) == page->index) {
> + limit = dir->i_size & ~PAGE_MASK;
>   if (limit & (chunk_size - 1))
>   goto Ebadsize;
>   if (!limit)
> @@ -138,7 +138,7 @@ bad_entry:
>   EXOFS_ERR(
>   "ERROR [exofs_check_page]: bad entry in directory(0x%lx): %s - "
>   "offset=%lu, inode=0x%llu, rec_len=%d, name_len=%d\n",
> - dir->i_ino, error, (page->index< + dir->i_ino, error, (page->index<   _LLU(le64_to_cpu(p->inode_no)),
>   rec_len, p->name_len);
>   goto fail;
> @@ -147,7 +147,7 @@ Eend:
>   EXOFS_ERR("ERROR [exofs_check_page]: "
>   "entry in directory(0x%lx) spans the page boundary"
>   "offset=%lu, inode=0x%llx\n",
> - dir->i_ino, (page->index< + dir->i_ino, (page->index<   _LLU(le64_to_cpu(p->inode_no)));
>  fail:
>   SetPageChecked(page);
> @@ -237,8 +237,8 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
>  {
>   loff_t pos = ctx->pos;
>   struct inode *inode = file_inode(file);
> - unsigned int offset = pos & ~PAGE_CACHE_MASK;
> - unsigned long n = pos >> PAGE_CACHE_SHIFT;
> + unsigned int offset = pos & ~PAGE_MASK;
> + unsigned long n = pos >> PAGE_SHIFT;
>   unsigned long npages = dir_pages(inode);
>   unsigned chunk_mask = ~(exofs_chunk_size(inode)-1);
>   int need_revalidate = (file->f_version != inode->i_version);
> @@ -254,7 +254,7 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
>   if (IS_ERR(page)) {
>   EXOFS_ERR("ERROR: bad page in directory(0x%lx)\n",
> inode->i_ino);
> - ctx->pos += PAGE_CACHE_SIZE - offset;
> + ctx->pos += PAGE_SIZE - offset;
>   return PTR_ERR(page);
>   }
>   kaddr = page_address(page);
> @@ -262,7 +262,7 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
>   if (offset) {
>   offset = exofs_validate_entry(kaddr, offset,
>   chunk_mask);
> - ctx->pos = 

RE: [f2fs-dev] [PATCH v2] f2fs: fix to convert inline directory correctly

[Chao Yu]

Ping,

Any problem in this patch?

Thanks,

> -Original Message-
> From: Chao Yu [mailto:chao2...@samsung.com]
> Sent: Monday, February 22, 2016 6:29 PM
> To: Jaegeuk Kim
> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net
> Subject: [f2fs-dev] [PATCH v2] f2fs: fix to convert inline directory correctly

RE: [f2fs-dev] [PATCH v2] f2fs: fix to convert inline directory correctly

[Chao Yu]

Ping,

Any problem in this patch?

Thanks,

> -Original Message-
> From: Chao Yu [mailto:chao2...@samsung.com]
> Sent: Monday, February 22, 2016 6:29 PM
> To: Jaegeuk Kim
> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net
> Subject: [f2fs-dev] [PATCH v2] f2fs: fix to convert inline directory correctly

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

[Rajesh Bhagat]

> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@intel.com]
> Sent: Monday, March 21, 2016 2:46 PM
> To: Rajesh Bhagat ; Mathias Nyman
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: gre...@linuxfoundation.org; Sriram Dash 
> Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI
> commmand timeout
> 
> On 21.03.2016 06:18, Rajesh Bhagat wrote:
> >
> >
> >>
> >> Hi
> >>
> >> I think clearing the whole command ring is a bit too much in this case.
> >> It may cause issues for all attached devices when one command times out.
> >>
> >
> > Hi Mathias,
> >
> > I understand your point, But I want to understand how would completion
> > handler be called if a command is timed out and xhci_abort_cmd_ring is
> > successful. In this case all the code would be waiting on completion 
> > handler forever.
> >
> >
> > 2. xhci_handle_command_timeout -> xhci_abort_cmd_ring(failure) ->
> > xhci_cleanup_command_queue -> xhci_complete_del_and_free_cmd
> >
> > In our case command is timed out, Hence we hit the case #2 but
> > xhci_abort_cmd_ring is success which does not calls complete.
> 
> xhci_abort_cmd_ring() will write CA bit (CMD_RING_ABORT) to CRCR register.
> This will generate a command completion event with status "command aborted" 
> for
> the pending command.
> This event is then followed by a "command ring stopped" command completion 
> event.
> 
> See xHCI specs 5.4.5 and 4.6.1.2
> 
> handle_cmd_completion() will check if cmd_comp_code == COMP_CMD_ABORT, goto
> event_handled, and call xhci_complete_del_and_free_cmd(cmd, cmd_comp_code) for
> the aborted command.
> 
> If xHCI already processed the aborted command, we might only get a command 
> ring
> stopped event, in this case handle_cmd_completion() will call
> xhci_handle_stopped_cmd_ring(xhci, cmd), which will turn the commands that 
> were
> tagged for "abort" that still remain on the command ring to NO-OP commands.
> 
> The completion callback will be called for these NO-OP command later when we 
> get a
> command completion event for them.
> 

Thanks Mathias for detailed explanation. Now I understand how completion 
handler is 
supposed to be called in this scenario. 

But in our case, somehow we are not getting any event and handle_cmd_completion 
function 
is not getting called even after successful xhci_abort_cmd_ring when command 
timed out. 

Now, my point here is code prior to this patch xhci: rework command timeout and 
cancellation,
Code would have returned in case command timed out in xhci_alloc_dev itself.

-   /* XXX: how much time for xHC slot assignment? */
-   timeleft = wait_for_completion_interruptible_timeout(
-   command->completion,
-   XHCI_CMD_DEFAULT_TIMEOUT);
-   if (timeleft <= 0) {
-   xhci_warn(xhci, "%s while waiting for a slot\n",
-   timeleft == 0 ? "Timeout" : "Signal");
-   /* cancel the enable slot request */
-   ret = xhci_cancel_cmd(xhci, NULL, command->command_trb);
-   return ret;
-   }
+   wait_for_completion(command->completion);

But after this patch, we are waiting for hardware event, which is somehow not 
generated 
and causing a hang scenario. 

IMO, The assumption that "xhci_abort_cmd_ring would always generate an event 
and handle_cmd_completion would be called" will not be always be true if HW is 
in bad state.

Please share your opinion.

> >> What kernel version, and what xhci vendor was this triggered on?
> >>
> >
> > We are using 4.1.8 kernel
> >
> 
> Are you able to try a more recent version?
> 

Using a newer kernel version would be bit difficult, but I would surely try it.

> -Mathias

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

[Rajesh Bhagat]

> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@intel.com]
> Sent: Monday, March 21, 2016 2:46 PM
> To: Rajesh Bhagat ; Mathias Nyman
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: gre...@linuxfoundation.org; Sriram Dash 
> Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI
> commmand timeout
> 
> On 21.03.2016 06:18, Rajesh Bhagat wrote:
> >
> >
> >>
> >> Hi
> >>
> >> I think clearing the whole command ring is a bit too much in this case.
> >> It may cause issues for all attached devices when one command times out.
> >>
> >
> > Hi Mathias,
> >
> > I understand your point, But I want to understand how would completion
> > handler be called if a command is timed out and xhci_abort_cmd_ring is
> > successful. In this case all the code would be waiting on completion 
> > handler forever.
> >
> >
> > 2. xhci_handle_command_timeout -> xhci_abort_cmd_ring(failure) ->
> > xhci_cleanup_command_queue -> xhci_complete_del_and_free_cmd
> >
> > In our case command is timed out, Hence we hit the case #2 but
> > xhci_abort_cmd_ring is success which does not calls complete.
> 
> xhci_abort_cmd_ring() will write CA bit (CMD_RING_ABORT) to CRCR register.
> This will generate a command completion event with status "command aborted" 
> for
> the pending command.
> This event is then followed by a "command ring stopped" command completion 
> event.
> 
> See xHCI specs 5.4.5 and 4.6.1.2
> 
> handle_cmd_completion() will check if cmd_comp_code == COMP_CMD_ABORT, goto
> event_handled, and call xhci_complete_del_and_free_cmd(cmd, cmd_comp_code) for
> the aborted command.
> 
> If xHCI already processed the aborted command, we might only get a command 
> ring
> stopped event, in this case handle_cmd_completion() will call
> xhci_handle_stopped_cmd_ring(xhci, cmd), which will turn the commands that 
> were
> tagged for "abort" that still remain on the command ring to NO-OP commands.
> 
> The completion callback will be called for these NO-OP command later when we 
> get a
> command completion event for them.
> 

Thanks Mathias for detailed explanation. Now I understand how completion 
handler is 
supposed to be called in this scenario. 

But in our case, somehow we are not getting any event and handle_cmd_completion 
function 
is not getting called even after successful xhci_abort_cmd_ring when command 
timed out. 

Now, my point here is code prior to this patch xhci: rework command timeout and 
cancellation,
Code would have returned in case command timed out in xhci_alloc_dev itself.

-   /* XXX: how much time for xHC slot assignment? */
-   timeleft = wait_for_completion_interruptible_timeout(
-   command->completion,
-   XHCI_CMD_DEFAULT_TIMEOUT);
-   if (timeleft <= 0) {
-   xhci_warn(xhci, "%s while waiting for a slot\n",
-   timeleft == 0 ? "Timeout" : "Signal");
-   /* cancel the enable slot request */
-   ret = xhci_cancel_cmd(xhci, NULL, command->command_trb);
-   return ret;
-   }
+   wait_for_completion(command->completion);

But after this patch, we are waiting for hardware event, which is somehow not 
generated 
and causing a hang scenario. 

IMO, The assumption that "xhci_abort_cmd_ring would always generate an event 
and handle_cmd_completion would be called" will not be always be true if HW is 
in bad state.

Please share your opinion.

> >> What kernel version, and what xhci vendor was this triggered on?
> >>
> >
> > We are using 4.1.8 kernel
> >
> 
> Are you able to try a more recent version?
> 

Using a newer kernel version would be bit difficult, but I would surely try it.

> -Mathias

Re: Build error due to commit 458aa76d132dc ("mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range")

[Aneesh Kumar K.V]

Guenter Roeck  writes:

> [ text/plain ]
> Hi,
>
> Your commit 458aa76d132dc1 ("mm/thp/migration: switch from flush_tlb_range
> to flush_pmd_tlb_range") causes a build error when building
> arcv2:vdk_hs38_smp_defconfig.
>
> include/asm-generic/pgtable.h:799:45: note: in expansion of macro ‘BUILD_BUG’
>  #define flush_pmd_tlb_range(vma, addr, end) BUILD_BUG()
>   ^
> ./arch/arc/include/asm/tlbflush.h:37:13: note:
>   in expansion of macro ‘flush_pmd_tlb_range’
>
> The build triggers the newly introduced BUILD_BUG().
>
> When building the image without the BUILD_BUG(), ie with no definition
> of flush_pmd_tlb_range(), the problem is gone. This suggests that the
> function is not needed for this build.
>
> I could submit a patch to remove the BUILD_BUG(), but maybe you had a reason
> for introducing it. Can you elaborate why you introduced the BUILD_BUG() ?
>

Isn't this going to be fixed by an update to ARC tree ?

http://article.gmane.org/gmane.linux.kernel.mm/148412

I also don't understand why we would hit that BUILD_BUG, if we are not
calling flush_pmd_tlb_range().

-aneesh

Re: Build error due to commit 458aa76d132dc ("mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range")

[Aneesh Kumar K.V]

Guenter Roeck  writes:

> [ text/plain ]
> Hi,
>
> Your commit 458aa76d132dc1 ("mm/thp/migration: switch from flush_tlb_range
> to flush_pmd_tlb_range") causes a build error when building
> arcv2:vdk_hs38_smp_defconfig.
>
> include/asm-generic/pgtable.h:799:45: note: in expansion of macro ‘BUILD_BUG’
>  #define flush_pmd_tlb_range(vma, addr, end) BUILD_BUG()
>   ^
> ./arch/arc/include/asm/tlbflush.h:37:13: note:
>   in expansion of macro ‘flush_pmd_tlb_range’
>
> The build triggers the newly introduced BUILD_BUG().
>
> When building the image without the BUILD_BUG(), ie with no definition
> of flush_pmd_tlb_range(), the problem is gone. This suggests that the
> function is not needed for this build.
>
> I could submit a patch to remove the BUILD_BUG(), but maybe you had a reason
> for introducing it. Can you elaborate why you introduced the BUILD_BUG() ?
>

Isn't this going to be fixed by an update to ARC tree ?

http://article.gmane.org/gmane.linux.kernel.mm/148412

I also don't understand why we would hit that BUILD_BUG, if we are not
calling flush_pmd_tlb_range().

-aneesh

Re: [PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.

[dawei chien]

On Tue, 2016-03-15 at 13:17 +0700, Viresh Kumar wrote:
> On 15-03-16, 12:53, dawei chien wrote:
> > On Thu, 2015-12-17 at 09:52 +0800, Viresh Kumar wrote:
> > > On 16-12-15, 21:29, Dawei Chien wrote:
> > > > Use Intelligent Power Allocation (IPA) technical to add dynamic power 
> > > > model
> > > > for binding CPU thermal zone. The power allocator governor allocates 
> > > > power
> > > > budget to control CPU temperature.
> > > >
> > > > Power Allocator governor is able to keep SOC temperature within a 
> > > > defined
> > > > temperature range to avoid SOC overheat and keep it's performance.
> > > > mt8173-cpufreq.c need to register its' own power model with power 
> > > > allocator
> > > > thermal governor, so that power allocator governor can allocates 
> > > > suitable
> > > > power budget to control CPU temperature.
> > > >
> > > > Binding document is refer to this patchset
> > > > https://lkml.org/lkml/2015/11/30/239
> > > >
> > > > Change since V5:
> > > > 1. Remove thermal sensor ID from phandles
> > > 
> > > Though you should have included this in the new version, but still
> > > 
> > > Acked-by: Viresh Kumar 
> > > 
> > > --
> > > viresh
> > 
> > Hi Viresh,
> > Would you please pull this patch to your tree since following patch
> > already pulled in, thank you.
> > 
> > https://lkml.org/lkml/2015/11/30/239
> 
> Its Rafael, who is going to apply this one.
> 
> Can you please resend it as he may not have it in patchworks?
> 

Hi Rafael,
Would you merge this patch to your tee, thank you.

BR,
Dawei

Re: [PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.

[dawei chien]

On Tue, 2016-03-15 at 13:17 +0700, Viresh Kumar wrote:
> On 15-03-16, 12:53, dawei chien wrote:
> > On Thu, 2015-12-17 at 09:52 +0800, Viresh Kumar wrote:
> > > On 16-12-15, 21:29, Dawei Chien wrote:
> > > > Use Intelligent Power Allocation (IPA) technical to add dynamic power 
> > > > model
> > > > for binding CPU thermal zone. The power allocator governor allocates 
> > > > power
> > > > budget to control CPU temperature.
> > > >
> > > > Power Allocator governor is able to keep SOC temperature within a 
> > > > defined
> > > > temperature range to avoid SOC overheat and keep it's performance.
> > > > mt8173-cpufreq.c need to register its' own power model with power 
> > > > allocator
> > > > thermal governor, so that power allocator governor can allocates 
> > > > suitable
> > > > power budget to control CPU temperature.
> > > >
> > > > Binding document is refer to this patchset
> > > > https://lkml.org/lkml/2015/11/30/239
> > > >
> > > > Change since V5:
> > > > 1. Remove thermal sensor ID from phandles
> > > 
> > > Though you should have included this in the new version, but still
> > > 
> > > Acked-by: Viresh Kumar 
> > > 
> > > --
> > > viresh
> > 
> > Hi Viresh,
> > Would you please pull this patch to your tree since following patch
> > already pulled in, thank you.
> > 
> > https://lkml.org/lkml/2015/11/30/239
> 
> Its Rafael, who is going to apply this one.
> 
> Can you please resend it as he may not have it in patchworks?
> 

Hi Rafael,
Would you merge this patch to your tee, thank you.

BR,
Dawei

Re: [PATCH] zram: revive swap_slot_free_notify

[Joonsoo Kim]

On Fri, Mar 18, 2016 at 04:58:31PM +0900, Minchan Kim wrote:
>  "remove compressed copy from zram in-memory"
> applied swap_slot_free_notify call in *end_swap_bio_read* to
> remove duplicated memory between zram and memory.
> 
> However, with introducing rw_page in zram <8c7f01025f7b>
> "zram: implement rw_page operation of zram", it became void
> because rw_page doesn't need bio.
> 
> This patch restores the function for rw_page.
> 
> Signed-off-by: Minchan Kim 
> ---
>  mm/page_io.c | 93 
> 
>  1 file changed, 50 insertions(+), 43 deletions(-)
> 
> diff --git a/mm/page_io.c b/mm/page_io.c
> index ff74e512f029..18aac7819cc9 100644
> --- a/mm/page_io.c
> +++ b/mm/page_io.c
> @@ -66,6 +66,54 @@ void end_swap_bio_write(struct bio *bio)
>   bio_put(bio);
>  }
>  
> +static void swap_slot_free_notify(struct page *page)
> +{
> + struct swap_info_struct *sis;
> + struct gendisk *disk;
> +
> + /*
> +  * There is no guarantee that the page is in swap cache - the software
> +  * suspend code (at least) uses end_swap_bio_read() against a non-
> +  * swapcache page.  So we must check PG_swapcache before proceeding with
> +  * this optimization.
> +  */
> + if (unlikely(!PageSwapCache(page)))
> + return;
> +
> + sis = page_swap_info(page);
> + if (!(sis->flags & SWP_BLKDEV))
> + return;
> +
> + /*
> +  * The swap subsystem performs lazy swap slot freeing,
> +  * expecting that the page will be swapped out again.
> +  * So we can avoid an unnecessary write if the page
> +  * isn't redirtied.
> +  * This is good for real swap storage because we can
> +  * reduce unnecessary I/O and enhance wear-leveling
> +  * if an SSD is used as the as swap device.
> +  * But if in-memory swap device (eg zram) is used,
> +  * this causes a duplicated copy between uncompressed
> +  * data in VM-owned memory and compressed data in
> +  * zram-owned memory.  So let's free zram-owned memory
> +  * and make the VM-owned decompressed page *dirty*,
> +  * so the page should be swapped out somewhere again if
> +  * we again wish to reclaim it.
> +  */
> + disk = sis->bdev->bd_disk;
> + if (disk->fops->swap_slot_free_notify) {
> + swp_entry_t entry;
> + unsigned long offset;
> +
> + entry.val = page_private(page);
> + offset = swp_offset(entry);
> +
> + SetPageDirty(page);
> + disk->fops->swap_slot_free_notify(sis->bdev,
> + offset);
> + }
> +}
> +
>  static void end_swap_bio_read(struct bio *bio)
>  {
>   struct page *page = bio->bi_io_vec[0].bv_page;
> @@ -81,49 +129,7 @@ static void end_swap_bio_read(struct bio *bio)
>   }
>  
>   SetPageUptodate(page);
> -
> - /*
> -  * There is no guarantee that the page is in swap cache - the software
> -  * suspend code (at least) uses end_swap_bio_read() against a non-
> -  * swapcache page.  So we must check PG_swapcache before proceeding with
> -  * this optimization.
> -  */
> - if (likely(PageSwapCache(page))) {
> - struct swap_info_struct *sis;
> -
> - sis = page_swap_info(page);
> - if (sis->flags & SWP_BLKDEV) {
> - /*
> -  * The swap subsystem performs lazy swap slot freeing,
> -  * expecting that the page will be swapped out again.
> -  * So we can avoid an unnecessary write if the page
> -  * isn't redirtied.
> -  * This is good for real swap storage because we can
> -  * reduce unnecessary I/O and enhance wear-leveling
> -  * if an SSD is used as the as swap device.
> -  * But if in-memory swap device (eg zram) is used,
> -  * this causes a duplicated copy between uncompressed
> -  * data in VM-owned memory and compressed data in
> -  * zram-owned memory.  So let's free zram-owned memory
> -  * and make the VM-owned decompressed page *dirty*,
> -  * so the page should be swapped out somewhere again if
> -  * we again wish to reclaim it.
> -  */
> - struct gendisk *disk = sis->bdev->bd_disk;
> - if (disk->fops->swap_slot_free_notify) {
> - swp_entry_t entry;
> - unsigned long offset;
> -
> - entry.val = page_private(page);
> - offset = swp_offset(entry);
> -
> - SetPageDirty(page);
> - disk->fops->swap_slot_free_notify(sis->bdev,
> - 

Re: [PATCH] zram: revive swap_slot_free_notify

[Joonsoo Kim]

On Fri, Mar 18, 2016 at 04:58:31PM +0900, Minchan Kim wrote:
>  "remove compressed copy from zram in-memory"
> applied swap_slot_free_notify call in *end_swap_bio_read* to
> remove duplicated memory between zram and memory.
> 
> However, with introducing rw_page in zram <8c7f01025f7b>
> "zram: implement rw_page operation of zram", it became void
> because rw_page doesn't need bio.
> 
> This patch restores the function for rw_page.
> 
> Signed-off-by: Minchan Kim 
> ---
>  mm/page_io.c | 93 
> 
>  1 file changed, 50 insertions(+), 43 deletions(-)
> 
> diff --git a/mm/page_io.c b/mm/page_io.c
> index ff74e512f029..18aac7819cc9 100644
> --- a/mm/page_io.c
> +++ b/mm/page_io.c
> @@ -66,6 +66,54 @@ void end_swap_bio_write(struct bio *bio)
>   bio_put(bio);
>  }
>  
> +static void swap_slot_free_notify(struct page *page)
> +{
> + struct swap_info_struct *sis;
> + struct gendisk *disk;
> +
> + /*
> +  * There is no guarantee that the page is in swap cache - the software
> +  * suspend code (at least) uses end_swap_bio_read() against a non-
> +  * swapcache page.  So we must check PG_swapcache before proceeding with
> +  * this optimization.
> +  */
> + if (unlikely(!PageSwapCache(page)))
> + return;
> +
> + sis = page_swap_info(page);
> + if (!(sis->flags & SWP_BLKDEV))
> + return;
> +
> + /*
> +  * The swap subsystem performs lazy swap slot freeing,
> +  * expecting that the page will be swapped out again.
> +  * So we can avoid an unnecessary write if the page
> +  * isn't redirtied.
> +  * This is good for real swap storage because we can
> +  * reduce unnecessary I/O and enhance wear-leveling
> +  * if an SSD is used as the as swap device.
> +  * But if in-memory swap device (eg zram) is used,
> +  * this causes a duplicated copy between uncompressed
> +  * data in VM-owned memory and compressed data in
> +  * zram-owned memory.  So let's free zram-owned memory
> +  * and make the VM-owned decompressed page *dirty*,
> +  * so the page should be swapped out somewhere again if
> +  * we again wish to reclaim it.
> +  */
> + disk = sis->bdev->bd_disk;
> + if (disk->fops->swap_slot_free_notify) {
> + swp_entry_t entry;
> + unsigned long offset;
> +
> + entry.val = page_private(page);
> + offset = swp_offset(entry);
> +
> + SetPageDirty(page);
> + disk->fops->swap_slot_free_notify(sis->bdev,
> + offset);
> + }
> +}
> +
>  static void end_swap_bio_read(struct bio *bio)
>  {
>   struct page *page = bio->bi_io_vec[0].bv_page;
> @@ -81,49 +129,7 @@ static void end_swap_bio_read(struct bio *bio)
>   }
>  
>   SetPageUptodate(page);
> -
> - /*
> -  * There is no guarantee that the page is in swap cache - the software
> -  * suspend code (at least) uses end_swap_bio_read() against a non-
> -  * swapcache page.  So we must check PG_swapcache before proceeding with
> -  * this optimization.
> -  */
> - if (likely(PageSwapCache(page))) {
> - struct swap_info_struct *sis;
> -
> - sis = page_swap_info(page);
> - if (sis->flags & SWP_BLKDEV) {
> - /*
> -  * The swap subsystem performs lazy swap slot freeing,
> -  * expecting that the page will be swapped out again.
> -  * So we can avoid an unnecessary write if the page
> -  * isn't redirtied.
> -  * This is good for real swap storage because we can
> -  * reduce unnecessary I/O and enhance wear-leveling
> -  * if an SSD is used as the as swap device.
> -  * But if in-memory swap device (eg zram) is used,
> -  * this causes a duplicated copy between uncompressed
> -  * data in VM-owned memory and compressed data in
> -  * zram-owned memory.  So let's free zram-owned memory
> -  * and make the VM-owned decompressed page *dirty*,
> -  * so the page should be swapped out somewhere again if
> -  * we again wish to reclaim it.
> -  */
> - struct gendisk *disk = sis->bdev->bd_disk;
> - if (disk->fops->swap_slot_free_notify) {
> - swp_entry_t entry;
> - unsigned long offset;
> -
> - entry.val = page_private(page);
> - offset = swp_offset(entry);
> -
> - SetPageDirty(page);
> - disk->fops->swap_slot_free_notify(sis->bdev,
> - offset);
> - 

Re: [PATCH 1/6] mm/page_alloc: fix same zone check in __pageblock_pfn_to_page()

[Joonsoo Kim]

On Mon, Mar 21, 2016 at 11:37:19AM +, Mel Gorman wrote:
> On Mon, Mar 14, 2016 at 04:31:32PM +0900, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> > 
> > There is a system that node's pfn are overlapped like as following.
> > 
> > -pfn>
> > N0 N1 N2 N0 N1 N2
> > 
> > Therefore, we need to care this overlapping when iterating pfn range.
> > 
> > In __pageblock_pfn_to_page(), there is a check for this but it's
> > not sufficient. This check cannot distinguish the case that zone id
> > is the same but node id is different. This patch fixes it.
> > 
> 
> I think you may be mixing up page_zone_id with page_zonenum.

Oops... Indeed.

I will drop the patch. Thanks for catching it. :)

Thanks.

Re: [PATCH 1/6] mm/page_alloc: fix same zone check in __pageblock_pfn_to_page()

[Joonsoo Kim]

On Mon, Mar 21, 2016 at 11:37:19AM +, Mel Gorman wrote:
> On Mon, Mar 14, 2016 at 04:31:32PM +0900, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> > 
> > There is a system that node's pfn are overlapped like as following.
> > 
> > -pfn>
> > N0 N1 N2 N0 N1 N2
> > 
> > Therefore, we need to care this overlapping when iterating pfn range.
> > 
> > In __pageblock_pfn_to_page(), there is a check for this but it's
> > not sufficient. This check cannot distinguish the case that zone id
> > is the same but node id is different. This patch fixes it.
> > 
> 
> I think you may be mixing up page_zone_id with page_zonenum.

Oops... Indeed.

I will drop the patch. Thanks for catching it. :)

Thanks.

Re: [PATCH RESEND v2 00/14] lib/mpi: bug fixes and cleanup

[Tadeusz Struk]

Hi Nicolai,
On 03/21/2016 06:26 AM, Nicolai Stange wrote:
> This is a resend of v2 with the crypto people properly CC'd.
> 
> The original v1 can be found here:
> 
>   
> http://lkml.kernel.org/g/1458237606-4954-1-git-send-email-nicsta...@gmail.com
> 
> 
> While v1 (hopefully) fixed some issues in mpi_write_sgl() and
> mpi_read_buffer() introduced by
>   commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") and by
>   commit 9cbe21d8f89d ("lib/mpi: only require buffers as big as needed for
> the integer"),
> I missed that there are some, including out-of-bounds buffer accesses,
> in mpi_read_raw_from_sgl() as well.
> 
> Hence v2, which includes the original stuff from v1 plus my new fixes to
> mpi_read_raw_from_sgl().
> 
> 
> Applicable to linux-next-20160318.
> 
> 
> Changes to v1:
>   - [1-8/14]
> former [1-8/8], unchanged.
> 
>   - [9-14/14]
> Added in v2. Fixes to mpi_read_raw_from_sgl().
> 
> Nicolai Stange (14):
>   lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs
>   lib/mpi: mpi_write_sgl(): fix style issue with lzero decrement
>   lib/mpi: mpi_write_sgl(): purge redundant pointer arithmetic
>   lib/mpi: mpi_write_sgl(): fix out-of-bounds stack access
>   lib/mpi: mpi_write_sgl(): replace open coded endian conversion
>   lib/mpi: mpi_read_buffer(): optimize skipping of leading zero limbs
>   lib/mpi: mpi_read_buffer(): replace open coded endian conversion
>   lib/mpi: mpi_read_buffer(): fix buffer overflow
>   lib/mpi: mpi_read_raw_from_sgl(): replace len argument by nbytes
>   lib/mpi: mpi_read_raw_from_sgl(): don't include leading zero SGEs in
> nbytes
>   lib/mpi: mpi_read_raw_from_sgl(): purge redundant clearing of nbits
>   lib/mpi: mpi_read_raw_from_sgl(): fix nbits calculation
>   lib/mpi: mpi_read_raw_from_sgl(): sanitize meaning of indices
>   lib/mpi: mpi_read_raw_from_sgl(): fix out-of-bounds buffer access
> 
>  lib/mpi/mpicoder.c | 122 
> +++--
>  1 file changed, 43 insertions(+), 79 deletions(-)

Thanks for sending this. Nice work. In fact the mpi_write_sgl() function
worked only because the mpi_normalize() stripped all MSB zero limbs.
Given that this will hold for all cases we can simplify this even more.
Unfortunately I don't know if this will be true for mpi_sub() or
mpi_set_ui() because they are declared in include/linux/mpi.h,
but never defined anywhere.

I've found one problem in 08/14 in mpi_read_buffer()
It's a pointer arithmetic issue, which causes the first limb to be
written at an invalid address if lzeros > 0. This incremental patch
fixes it.

---8<---
Subject: [PATCH] lib/mpi: fix pointer arithmetic issue in mpi_read_buffer

Fix pointer arithmetic issue, which causes the first limb to be
written at invalid address if lzeros > 0.

Signed-off-by: Tadeusz Struk 
---
 lib/mpi/mpicoder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 0c534ac..747606f 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -201,7 +201,7 @@ int mpi_read_buffer(MPI a, uint8_t *buf, unsigned buf_len, 
unsigned *nbytes,
 #else
 #error please implement for this limb size.
 #endif
-   memcpy(p,  + lzeros, BYTES_PER_MPI_LIMB - lzeros);
+   memcpy(p, (u8 *) + lzeros, BYTES_PER_MPI_LIMB - lzeros);
p += BYTES_PER_MPI_LIMB - lzeros;
lzeros = 0;
}

---
Other than that  please include my 
Tested-by: Tadeusz Struk 
for the whole series.
Thanks,
-- 
TS

Re: [PATCH RESEND v2 00/14] lib/mpi: bug fixes and cleanup

[Tadeusz Struk]

Hi Nicolai,
On 03/21/2016 06:26 AM, Nicolai Stange wrote:
> This is a resend of v2 with the crypto people properly CC'd.
> 
> The original v1 can be found here:
> 
>   
> http://lkml.kernel.org/g/1458237606-4954-1-git-send-email-nicsta...@gmail.com
> 
> 
> While v1 (hopefully) fixed some issues in mpi_write_sgl() and
> mpi_read_buffer() introduced by
>   commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") and by
>   commit 9cbe21d8f89d ("lib/mpi: only require buffers as big as needed for
> the integer"),
> I missed that there are some, including out-of-bounds buffer accesses,
> in mpi_read_raw_from_sgl() as well.
> 
> Hence v2, which includes the original stuff from v1 plus my new fixes to
> mpi_read_raw_from_sgl().
> 
> 
> Applicable to linux-next-20160318.
> 
> 
> Changes to v1:
>   - [1-8/14]
> former [1-8/8], unchanged.
> 
>   - [9-14/14]
> Added in v2. Fixes to mpi_read_raw_from_sgl().
> 
> Nicolai Stange (14):
>   lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs
>   lib/mpi: mpi_write_sgl(): fix style issue with lzero decrement
>   lib/mpi: mpi_write_sgl(): purge redundant pointer arithmetic
>   lib/mpi: mpi_write_sgl(): fix out-of-bounds stack access
>   lib/mpi: mpi_write_sgl(): replace open coded endian conversion
>   lib/mpi: mpi_read_buffer(): optimize skipping of leading zero limbs
>   lib/mpi: mpi_read_buffer(): replace open coded endian conversion
>   lib/mpi: mpi_read_buffer(): fix buffer overflow
>   lib/mpi: mpi_read_raw_from_sgl(): replace len argument by nbytes
>   lib/mpi: mpi_read_raw_from_sgl(): don't include leading zero SGEs in
> nbytes
>   lib/mpi: mpi_read_raw_from_sgl(): purge redundant clearing of nbits
>   lib/mpi: mpi_read_raw_from_sgl(): fix nbits calculation
>   lib/mpi: mpi_read_raw_from_sgl(): sanitize meaning of indices
>   lib/mpi: mpi_read_raw_from_sgl(): fix out-of-bounds buffer access
> 
>  lib/mpi/mpicoder.c | 122 
> +++--
>  1 file changed, 43 insertions(+), 79 deletions(-)

Thanks for sending this. Nice work. In fact the mpi_write_sgl() function
worked only because the mpi_normalize() stripped all MSB zero limbs.
Given that this will hold for all cases we can simplify this even more.
Unfortunately I don't know if this will be true for mpi_sub() or
mpi_set_ui() because they are declared in include/linux/mpi.h,
but never defined anywhere.

I've found one problem in 08/14 in mpi_read_buffer()
It's a pointer arithmetic issue, which causes the first limb to be
written at an invalid address if lzeros > 0. This incremental patch
fixes it.

---8<---
Subject: [PATCH] lib/mpi: fix pointer arithmetic issue in mpi_read_buffer

Fix pointer arithmetic issue, which causes the first limb to be
written at invalid address if lzeros > 0.

Signed-off-by: Tadeusz Struk 
---
 lib/mpi/mpicoder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 0c534ac..747606f 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -201,7 +201,7 @@ int mpi_read_buffer(MPI a, uint8_t *buf, unsigned buf_len, 
unsigned *nbytes,
 #else
 #error please implement for this limb size.
 #endif
-   memcpy(p,  + lzeros, BYTES_PER_MPI_LIMB - lzeros);
+   memcpy(p, (u8 *) + lzeros, BYTES_PER_MPI_LIMB - lzeros);
p += BYTES_PER_MPI_LIMB - lzeros;
lzeros = 0;
}

---
Other than that  please include my 
Tested-by: Tadeusz Struk 
for the whole series.
Thanks,
-- 
TS

Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update

[Mike Galbraith]

On Tue, 2016-03-22 at 08:21 +0530, Viresh Kumar wrote:
> On 22-03-16, 01:17, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > Modify dbs_irq_work() to always schedule the process-context work
> > on the current CPU which also ran the dbs_update_util_handler()
> > that the irq_work being handled came from.
> > 
> > This causes the entire frequency update handling (involving the
> > "ondemand" or "conservative" governors) to be carried out by the
> > CPU whose frequency is to be updated and reduces the overall amount
> > of inter-CPU noise related to cpufreq.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >  drivers/cpufreq/cpufreq_governor.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> > ===
> > --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> > +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> > @@ -245,7 +245,7 @@ static void dbs_irq_work(struct irq_work
> > struct policy_dbs_info *policy_dbs;
> >  
> > policy_dbs = container_of(irq_work,
> > structwq_unbound_cpumask policy_dbs_info, irq_work);
> > -   schedule_work(_dbs->work);
> > +   schedule_work_on(smp_processor_id(), _dbs->work);
> >  }
> >  
> >  static void dbs_update_util_handler(struct update_util_data *data,
> > u64 time,
> 
> queue_work() used to queue the work on local cpu by default, has that
> changed now ?

By default it still will, but the user now has the option to deflect
work items with an unspecified target.  These will land on a CPU
included in wq_unbound_cpumask iff the current CPU is excluded
therefrom.

-Mike

Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update

[Mike Galbraith]

On Tue, 2016-03-22 at 08:21 +0530, Viresh Kumar wrote:
> On 22-03-16, 01:17, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > Modify dbs_irq_work() to always schedule the process-context work
> > on the current CPU which also ran the dbs_update_util_handler()
> > that the irq_work being handled came from.
> > 
> > This causes the entire frequency update handling (involving the
> > "ondemand" or "conservative" governors) to be carried out by the
> > CPU whose frequency is to be updated and reduces the overall amount
> > of inter-CPU noise related to cpufreq.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >  drivers/cpufreq/cpufreq_governor.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> > ===
> > --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> > +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> > @@ -245,7 +245,7 @@ static void dbs_irq_work(struct irq_work
> > struct policy_dbs_info *policy_dbs;
> >  
> > policy_dbs = container_of(irq_work,
> > structwq_unbound_cpumask policy_dbs_info, irq_work);
> > -   schedule_work(_dbs->work);
> > +   schedule_work_on(smp_processor_id(), _dbs->work);
> >  }
> >  
> >  static void dbs_update_util_handler(struct update_util_data *data,
> > u64 time,
> 
> queue_work() used to queue the work on local cpu by default, has that
> changed now ?

By default it still will, but the user now has the option to deflect
work items with an unspecified target.  These will land on a CPU
included in wq_unbound_cpumask iff the current CPU is excluded
therefrom.

-Mike

[PATCH] tpm: drop int_queue from tpm_vendor_specific

[Jarkko Sakkinen]

Drop field int_queue from tpm_vendor_specific as it is used only by
tpm_tis. Probably all of the fields should be eventually dropped and
moved to the private structures of different drivers but it is better to
do this one step at a time in order not to break anything.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h |  1 -
 drivers/char/tpm/tpm_i2c_nuvoton.c |  1 -
 drivers/char/tpm/tpm_tis.c | 19 ---
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f197eef..4764545 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -148,7 +148,6 @@ struct tpm_vendor_specific {
void *priv;
 
wait_queue_head_t read_queue;
-   wait_queue_head_t int_queue;
 
u16 manufacturer_id;
 };
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c 
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index d61d43f..a43b5f3 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -540,7 +540,6 @@ static int i2c_nuvoton_probe(struct i2c_client *client,
return -ENOMEM;
 
init_waitqueue_head(>vendor.read_queue);
-   init_waitqueue_head(>vendor.int_queue);
 
/* Default timeouts */
chip->vendor.timeout_a = msecs_to_jiffies(TPM_I2C_SHORT_TIMEOUT);
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index eed3bf5..7d7a776 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -95,6 +95,7 @@ struct tpm_info {
 
 struct priv_data {
bool irq_tested;
+   wait_queue_head_t int_queue;
 };
 
 #if defined(CONFIG_PNP) && defined(CONFIG_ACPI)
@@ -157,6 +158,7 @@ static void release_locality(struct tpm_chip *chip, int l, 
int force)
 
 static int request_locality(struct tpm_chip *chip, int l)
 {
+   struct priv_data *priv = chip->vendor.priv;
unsigned long stop, timeout;
long rc;
 
@@ -173,7 +175,7 @@ again:
timeout = stop - jiffies;
if ((long)timeout <= 0)
return -1;
-   rc = wait_event_interruptible_timeout(chip->vendor.int_queue,
+   rc = wait_event_interruptible_timeout(priv->int_queue,
  (check_locality
   (chip, l) >= 0),
  timeout);
@@ -249,6 +251,7 @@ static int recv_data(struct tpm_chip *chip, u8 *buf, size_t 
count)
 
 static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
 {
+   struct priv_data *priv = chip->vendor.priv;
int size = 0;
int expected, status;
 
@@ -279,7 +282,7 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, 
size_t count)
}
 
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- >vendor.int_queue, false);
+ >int_queue, false);
status = tpm_tis_status(chip);
if (status & TPM_STS_DATA_AVAIL) {  /* retry? */
dev_err(>dev, "Error left over data\n");
@@ -304,6 +307,7 @@ MODULE_PARM_DESC(itpm, "Force iTPM workarounds (found on 
some Lenovo laptops)");
  */
 static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
 {
+   struct priv_data *priv = chip->vendor.priv;
int rc, status, burstcnt;
size_t count = 0;
 
@@ -315,7 +319,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
tpm_tis_ready(chip);
if (wait_for_tpm_stat
(chip, TPM_STS_COMMAND_READY, chip->vendor.timeout_b,
->vendor.int_queue, false) < 0) {
+>int_queue, false) < 0) {
rc = -ETIME;
goto out_err;
}
@@ -330,7 +334,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
}
 
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- >vendor.int_queue, false);
+ >int_queue, false);
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
rc = -EIO;
@@ -342,7 +346,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
iowrite8(buf[count],
 chip->vendor.iobase + TPM_DATA_FIFO(chip->vendor.locality));
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- >vendor.int_queue, false);
+ >int_queue, false);
status = tpm_tis_status(chip);
if ((status & TPM_STS_DATA_EXPECT) != 0) {
rc = -EIO;
@@ -537,6 +541,7 @@ static const struct tpm_class_ops tpm_tis = {
 static irqreturn_t tis_int_handler(int dummy, void *dev_id)
 {
  

[PATCH] tpm: drop int_queue from tpm_vendor_specific

[Jarkko Sakkinen]

Drop field int_queue from tpm_vendor_specific as it is used only by
tpm_tis. Probably all of the fields should be eventually dropped and
moved to the private structures of different drivers but it is better to
do this one step at a time in order not to break anything.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h |  1 -
 drivers/char/tpm/tpm_i2c_nuvoton.c |  1 -
 drivers/char/tpm/tpm_tis.c | 19 ---
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f197eef..4764545 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -148,7 +148,6 @@ struct tpm_vendor_specific {
void *priv;
 
wait_queue_head_t read_queue;
-   wait_queue_head_t int_queue;
 
u16 manufacturer_id;
 };
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c 
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index d61d43f..a43b5f3 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -540,7 +540,6 @@ static int i2c_nuvoton_probe(struct i2c_client *client,
return -ENOMEM;
 
init_waitqueue_head(>vendor.read_queue);
-   init_waitqueue_head(>vendor.int_queue);
 
/* Default timeouts */
chip->vendor.timeout_a = msecs_to_jiffies(TPM_I2C_SHORT_TIMEOUT);
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index eed3bf5..7d7a776 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -95,6 +95,7 @@ struct tpm_info {
 
 struct priv_data {
bool irq_tested;
+   wait_queue_head_t int_queue;
 };
 
 #if defined(CONFIG_PNP) && defined(CONFIG_ACPI)
@@ -157,6 +158,7 @@ static void release_locality(struct tpm_chip *chip, int l, 
int force)
 
 static int request_locality(struct tpm_chip *chip, int l)
 {
+   struct priv_data *priv = chip->vendor.priv;
unsigned long stop, timeout;
long rc;
 
@@ -173,7 +175,7 @@ again:
timeout = stop - jiffies;
if ((long)timeout <= 0)
return -1;
-   rc = wait_event_interruptible_timeout(chip->vendor.int_queue,
+   rc = wait_event_interruptible_timeout(priv->int_queue,
  (check_locality
   (chip, l) >= 0),
  timeout);
@@ -249,6 +251,7 @@ static int recv_data(struct tpm_chip *chip, u8 *buf, size_t 
count)
 
 static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
 {
+   struct priv_data *priv = chip->vendor.priv;
int size = 0;
int expected, status;
 
@@ -279,7 +282,7 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, 
size_t count)
}
 
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- >vendor.int_queue, false);
+ >int_queue, false);
status = tpm_tis_status(chip);
if (status & TPM_STS_DATA_AVAIL) {  /* retry? */
dev_err(>dev, "Error left over data\n");
@@ -304,6 +307,7 @@ MODULE_PARM_DESC(itpm, "Force iTPM workarounds (found on 
some Lenovo laptops)");
  */
 static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
 {
+   struct priv_data *priv = chip->vendor.priv;
int rc, status, burstcnt;
size_t count = 0;
 
@@ -315,7 +319,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
tpm_tis_ready(chip);
if (wait_for_tpm_stat
(chip, TPM_STS_COMMAND_READY, chip->vendor.timeout_b,
->vendor.int_queue, false) < 0) {
+>int_queue, false) < 0) {
rc = -ETIME;
goto out_err;
}
@@ -330,7 +334,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
}
 
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- >vendor.int_queue, false);
+ >int_queue, false);
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
rc = -EIO;
@@ -342,7 +346,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
iowrite8(buf[count],
 chip->vendor.iobase + TPM_DATA_FIFO(chip->vendor.locality));
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- >vendor.int_queue, false);
+ >int_queue, false);
status = tpm_tis_status(chip);
if ((status & TPM_STS_DATA_EXPECT) != 0) {
rc = -EIO;
@@ -537,6 +541,7 @@ static const struct tpm_class_ops tpm_tis = {
 static irqreturn_t tis_int_handler(int dummy, void *dev_id)
 {
struct tpm_chip *chip = 

Re: [PATCH v2] mwifiex: advertise low priority scan feature

[Wei-Ning Huang]

Tested-by: Wei-Ning Huang 

On Tue, Mar 22, 2016 at 12:09 PM, Wei-Ning Huang  wrote:
> From: Amitkumar Karwar 
>
> Low priority scan handling code which delays or aborts scan
> operation based on Tx traffic is removed recently. The reason
> is firmware already takes care of it in our new feature scan
> channel gap. Hence we should advertise low priority scan
> support to cfg80211.
>
> This patch fixes a problem in which OBSS scan request from
> wpa_supplicant was being rejected by cfg80211.
>
> Signed-off-by: Amitkumar Karwar 
> Signed-off-by: Wei-Ning Huang 
> ---
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index bb7235e..7dafc5b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter 
> *adapter)
>
> wiphy->features |= NL80211_FEATURE_HT_IBSS |
>NL80211_FEATURE_INACTIVITY_TIMER |
> +  NL80211_FEATURE_LOW_PRIORITY_SCAN |
>NL80211_FEATURE_NEED_OBSS_SCAN;
>
> if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info))
> --
> 2.8.0.rc3.226.g39d4020
>



-- 
Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan |
wnhu...@google.com | Cell: +886 910-380678

Re: [PATCH v2] mwifiex: advertise low priority scan feature

[Wei-Ning Huang]

Tested-by: Wei-Ning Huang 

On Tue, Mar 22, 2016 at 12:09 PM, Wei-Ning Huang  wrote:
> From: Amitkumar Karwar 
>
> Low priority scan handling code which delays or aborts scan
> operation based on Tx traffic is removed recently. The reason
> is firmware already takes care of it in our new feature scan
> channel gap. Hence we should advertise low priority scan
> support to cfg80211.
>
> This patch fixes a problem in which OBSS scan request from
> wpa_supplicant was being rejected by cfg80211.
>
> Signed-off-by: Amitkumar Karwar 
> Signed-off-by: Wei-Ning Huang 
> ---
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index bb7235e..7dafc5b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter 
> *adapter)
>
> wiphy->features |= NL80211_FEATURE_HT_IBSS |
>NL80211_FEATURE_INACTIVITY_TIMER |
> +  NL80211_FEATURE_LOW_PRIORITY_SCAN |
>NL80211_FEATURE_NEED_OBSS_SCAN;
>
> if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info))
> --
> 2.8.0.rc3.226.g39d4020
>



-- 
Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan |
wnhu...@google.com | Cell: +886 910-380678

Re: [PATCH] mwifiex: advertise low priority scan feature

[Wei-Ning Huang]

Hi Kalle,

Thanks for the review. I accidentally removed the s-o-b line from
akarwar in this version.
The original patch can be found at:
https://chromium-review.googlesource.com/#/c/246052/
I've resent a new one.

Wei-Ning

On Mon, Mar 21, 2016 at 6:28 PM, Kalle Valo  wrote:
> Wei-Ning Huang  writes:
>
>> From: Amitkumar Karwar 
>>
>> Low priority scan handling code which delays or aborts scan
>> operation based on Tx traffic is removed recently. The reason
>> is firmware already takes care of it in our new feature scan
>> channel gap. Hence we should advertise low priority scan
>> support to cfg80211.
>>
>> This patch fixes a problem in which OBSS scan request from
>> wpa_supplicant was being rejected by cfg80211.
>>
>> Signed-off-by: Wei-Ning Huang 
>
> The From line states that this is written by Amitkumar but there's no
> Signed-off-By line from him. I can't take this without that, please
> resend.
>
> (Wei-Ning's s-o-b line is correct, I just need also Amitkumar's line.)
>
> --
> Kalle Valo



-- 
Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan |
wnhu...@google.com | Cell: +886 910-380678

Re: [PATCH] mwifiex: advertise low priority scan feature

[Wei-Ning Huang]

Hi Kalle,

Thanks for the review. I accidentally removed the s-o-b line from
akarwar in this version.
The original patch can be found at:
https://chromium-review.googlesource.com/#/c/246052/
I've resent a new one.

Wei-Ning

On Mon, Mar 21, 2016 at 6:28 PM, Kalle Valo  wrote:
> Wei-Ning Huang  writes:
>
>> From: Amitkumar Karwar 
>>
>> Low priority scan handling code which delays or aborts scan
>> operation based on Tx traffic is removed recently. The reason
>> is firmware already takes care of it in our new feature scan
>> channel gap. Hence we should advertise low priority scan
>> support to cfg80211.
>>
>> This patch fixes a problem in which OBSS scan request from
>> wpa_supplicant was being rejected by cfg80211.
>>
>> Signed-off-by: Wei-Ning Huang 
>
> The From line states that this is written by Amitkumar but there's no
> Signed-off-By line from him. I can't take this without that, please
> resend.
>
> (Wei-Ning's s-o-b line is correct, I just need also Amitkumar's line.)
>
> --
> Kalle Valo



-- 
Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan |
wnhu...@google.com | Cell: +886 910-380678

[PATCH v2] mwifiex: advertise low priority scan feature

[Wei-Ning Huang]

From: Amitkumar Karwar 

Low priority scan handling code which delays or aborts scan
operation based on Tx traffic is removed recently. The reason
is firmware already takes care of it in our new feature scan
channel gap. Hence we should advertise low priority scan
support to cfg80211.

This patch fixes a problem in which OBSS scan request from
wpa_supplicant was being rejected by cfg80211.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Wei-Ning Huang 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index bb7235e..7dafc5b 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter 
*adapter)
 
wiphy->features |= NL80211_FEATURE_HT_IBSS |
   NL80211_FEATURE_INACTIVITY_TIMER |
+  NL80211_FEATURE_LOW_PRIORITY_SCAN |
   NL80211_FEATURE_NEED_OBSS_SCAN;
 
if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info))
-- 
2.8.0.rc3.226.g39d4020

[PATCH v2] mwifiex: advertise low priority scan feature

[Wei-Ning Huang]

From: Amitkumar Karwar 

Low priority scan handling code which delays or aborts scan
operation based on Tx traffic is removed recently. The reason
is firmware already takes care of it in our new feature scan
channel gap. Hence we should advertise low priority scan
support to cfg80211.

This patch fixes a problem in which OBSS scan request from
wpa_supplicant was being rejected by cfg80211.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Wei-Ning Huang 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index bb7235e..7dafc5b 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter 
*adapter)
 
wiphy->features |= NL80211_FEATURE_HT_IBSS |
   NL80211_FEATURE_INACTIVITY_TIMER |
+  NL80211_FEATURE_LOW_PRIORITY_SCAN |
   NL80211_FEATURE_NEED_OBSS_SCAN;
 
if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info))
-- 
2.8.0.rc3.226.g39d4020

[PATCH] media: au0828 fix au0828_v4l2_close() dev_state race condition

[Shuah Khan]

au0828_v4l2_close() check for dev_state == DEV_DISCONNECTED will fail to
detect the device disconnected state correctly, if au0828_v4l2_open() runs
to set the DEV_INITIALIZED bit. A loop test of bind/unbind found this bug
by increasing the likelihood of au0828_v4l2_open() occurring while unbind
is in progress. When au0828_v4l2_close() fails to detect that the device
is in disconnect state, it attempts to power down the device and fails with
the following general protection fault:

[  260.992962] Call Trace:
[  260.993008]  [] ? xc5000_sleep+0x8f/0xd0 [xc5000]
[  260.993095]  [] ? fe_standby+0x3c/0x50 [tuner]
[  260.993186]  [] au0828_v4l2_close+0x53c/0x620 [au0828]
[  260.993298]  [] v4l2_release+0xf0/0x210 [videodev]
[  260.993382]  [] __fput+0x1fc/0x6c0
[  260.993449]  [] fput+0xe/0x10
[  260.993519]  [] task_work_run+0x133/0x1f0
[  260.993602]  [] exit_to_usermode_loop+0x140/0x170
[  260.993681]  [] syscall_return_slowpath+0x16a/0x1a0
[  260.993754]  [] entry_SYSCALL_64_fastpath+0xa6/0xa8

Signed-off-by: Shuah Khan 
---
 drivers/media/usb/au0828/au0828-video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c 
b/drivers/media/usb/au0828/au0828-video.c
index 13f6dab..88dcc6e 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -1075,7 +1075,7 @@ static int au0828_v4l2_close(struct file *filp)
del_timer_sync(>vbi_timeout);
}
 
-   if (dev->dev_state == DEV_DISCONNECTED)
+   if (dev->dev_state & DEV_DISCONNECTED)
goto end;
 
if (dev->users == 1) {
-- 
2.5.0

[PATCH] media: au0828 fix au0828_v4l2_close() dev_state race condition

[Shuah Khan]

au0828_v4l2_close() check for dev_state == DEV_DISCONNECTED will fail to
detect the device disconnected state correctly, if au0828_v4l2_open() runs
to set the DEV_INITIALIZED bit. A loop test of bind/unbind found this bug
by increasing the likelihood of au0828_v4l2_open() occurring while unbind
is in progress. When au0828_v4l2_close() fails to detect that the device
is in disconnect state, it attempts to power down the device and fails with
the following general protection fault:

[  260.992962] Call Trace:
[  260.993008]  [] ? xc5000_sleep+0x8f/0xd0 [xc5000]
[  260.993095]  [] ? fe_standby+0x3c/0x50 [tuner]
[  260.993186]  [] au0828_v4l2_close+0x53c/0x620 [au0828]
[  260.993298]  [] v4l2_release+0xf0/0x210 [videodev]
[  260.993382]  [] __fput+0x1fc/0x6c0
[  260.993449]  [] fput+0xe/0x10
[  260.993519]  [] task_work_run+0x133/0x1f0
[  260.993602]  [] exit_to_usermode_loop+0x140/0x170
[  260.993681]  [] syscall_return_slowpath+0x16a/0x1a0
[  260.993754]  [] entry_SYSCALL_64_fastpath+0xa6/0xa8

Signed-off-by: Shuah Khan 
---
 drivers/media/usb/au0828/au0828-video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c 
b/drivers/media/usb/au0828/au0828-video.c
index 13f6dab..88dcc6e 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -1075,7 +1075,7 @@ static int au0828_v4l2_close(struct file *filp)
del_timer_sync(>vbi_timeout);
}
 
-   if (dev->dev_state == DEV_DISCONNECTED)
+   if (dev->dev_state & DEV_DISCONNECTED)
goto end;
 
if (dev->users == 1) {
-- 
2.5.0

Re: [PATCH] sound/usb: fix to release stream resources from media_snd_device_delete()

[Shuah Khan]

On 03/19/2016 07:31 AM, Shuah Khan wrote:
> On 03/19/2016 06:10 AM, Mauro Carvalho Chehab wrote:
>> Em Fri, 18 Mar 2016 20:50:31 -0600
>> Shuah Khan  escreveu:
>>
>>> Fix to release stream resources from media_snd_device_delete() before
>>> media device is unregistered. Without this change, stream resource free
>>> is attempted after the media device is unregistered which would result
>>> in use-after-free errors.
>>>
>>> Signed-off-by: Shuah Khan 
>>> ---
>>>
>>> - Ran bind/unbind loop (1000 iteration) test on snd-usb-audio
>>>   while running mc_nextgen_test loop (1000 iterations) in parallel.
>>> - Ran bind/unbind and rmmod/modprobe tests on both drivers. Also
>>>   generated graphs when after bind/unbind, rmmod/modprobe. Graphs
>>>   look good.
>>> - Note: Please apply the following patch to fix memory leak:
>>>   sound/usb: Fix memory leak in media_snd_stream_delete() during unbind
>>>   https://lkml.org/lkml/2016/3/16/1050
>>
>> Yeah, a way better!
>>
>> For normal bind/unbind, it seems to be working fine. Also
>> for driver's rmmod, so:
>>
>> Tested-by: Mauro Carvalho Chehab 
>>
>> PS.:
>> ===
>>
>> There are still some troubles if we run an infinite loop
>> binding/unbinding au0828 and another one binding/unbinding
>> snd-usb-audio, like this one:
> 
> Yes. I noticed this one when I was running a loop of 1000 on au0828.
> I couldn't reproduce this when I tested this patch.
> 
> P.S: au08282 loops takes longer btw since au0828 initialization is lot more
> complex. We have to look at this one.
> 
>>
>>
>> [   91.556188] [ cut here ]
>> [   91.556500] WARNING: CPU: 1 PID: 2920 at drivers/media/media-entity.c:392 
>> __media_entity_pipeline_start+0x271/0xce0 [media]()
>> [   91.556626] Modules linked in: ir_lirc_codec lirc_dev au8522_dig xc5000 
>> tuner au8522_decoder au8522_common au0828 videobuf2_vmalloc videobuf2_memops 
>> videobuf2_v4l2 videobuf2_core tveeprom dvb_core rc_core v4l2_common videodev 
>> snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device media 
>> cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats 
>> parport_pc ppdev lp parport snd_hda_codec_hdmi intel_rapl 
>> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt kvm 
>> iTCO_vendor_support irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel 
>> ghash_clmulni_intel sha256_ssse3 sha256_generic hmac drbg 
>> snd_hda_codec_realtek i915 snd_hda_codec_generic aesni_intel aes_x86_64 
>> btusb lrw btrtl gf128mul snd_hda_intel glue_helper ablk_helper btbcm btintel 
>> cryptd psmouse snd_hda_codec bluetooth
>> [   91.556693]  snd_hwdep i2c_algo_bit sg snd_hda_core serio_raw pcspkr 
>> evdev drm_kms_helper snd_pcm rfkill drm snd_timer mei_me snd i2c_i801 
>> soundcore lpc_ich mei mfd_core battery video dw_dmac i2c_designware_platform 
>> dw_dmac_core i2c_designware_core acpi_pad button tpm_tis tpm ext4 crc16 
>> mbcache jbd2 dm_mod sd_mod hid_generic usbhid ahci libahci libata e1000e 
>> xhci_pci ptp scsi_mod ehci_pci ehci_hcd pps_core xhci_hcd fan thermal 
>> sdhci_acpi sdhci mmc_core i2c_hid hid
>> [   91.556748] CPU: 1 PID: 2920 Comm: v4l_id Tainted: G  D W   
>> 4.5.0+ #62
>> [   91.556751] Hardware name:  /NUC5i7RYB, BIOS 
>> RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
>> [   91.556754]  a0e247a0 8803a3d17b08 819447c1 
>> 
>> [   91.556759]  88009bbe17c0 8803a3d17b48 8114fd16 
>> a0e20651
>> [   91.556763]  8803a47c9c58 8803a477d2c8 8803a5ac96f8 
>> dc00
>> [   91.556768] Call Trace:
>> [   91.556774]  [] dump_stack+0x85/0xc4
>> [   91.556778]  [] warn_slowpath_common+0xc6/0x120
>> [   91.556783]  [] ? 
>> __media_entity_pipeline_start+0x271/0xce0 [media]
>> [   91.556786]  [] warn_slowpath_null+0x1a/0x20
>> [   91.556790]  [] 
>> __media_entity_pipeline_start+0x271/0xce0 [media]
>> [   91.556794]  [] ? __schedule+0x78a/0x2570
>> [   91.556797]  [] ? memset+0x28/0x30
>> [   91.556802]  [] ? media_entity_pipeline_stop+0x60/0x60 
>> [media]
>> [   91.556806]  [] ? trace_hardirqs_on+0xd/0x10
>> [   91.556810]  [] ? au0828_enable_source+0x55/0x9f0 
>> [au0828]
>> [   91.556813]  [] ? mutex_trylock+0x400/0x400
>> [   91.556818]  [] ? au0828_v4l2_close+0xb3/0x590 [au0828]
>> [   91.556822]  [] au0828_enable_source+0x3f4/0x9f0 
>> [au0828]
>> [   91.556824]  [] ? mutex_trylock+0x400/0x400
>> [   91.556834]  [] v4l_enable_media_source+0x66/0x90 
>> [videodev]
>> [   91.556839]  [] au0828_v4l2_close+0x25a/0x590 [au0828]
>> [   91.556846]  [] v4l2_release+0xf0/0x210 [videodev]
>> [   91.556849]  [] __fput+0x20f/0x6d0
>> [   91.556853]  [] fput+0xe/0x10
>> [   91.556856]  [] task_work_run+0x137/0x200
>> [   91.556859]  [] exit_to_usermode_loop+0x154/0x180
>> [   91.556863]  [] ? trace_hardirqs_on_caller+0x16/0x590
>> [   91.556866]  [] syscall_return_slowpath+0x186/0x1c0
>> [   91.556869]  [] 

Re: [PATCH] sound/usb: fix to release stream resources from media_snd_device_delete()

[Shuah Khan]

On 03/19/2016 07:31 AM, Shuah Khan wrote:
> On 03/19/2016 06:10 AM, Mauro Carvalho Chehab wrote:
>> Em Fri, 18 Mar 2016 20:50:31 -0600
>> Shuah Khan  escreveu:
>>
>>> Fix to release stream resources from media_snd_device_delete() before
>>> media device is unregistered. Without this change, stream resource free
>>> is attempted after the media device is unregistered which would result
>>> in use-after-free errors.
>>>
>>> Signed-off-by: Shuah Khan 
>>> ---
>>>
>>> - Ran bind/unbind loop (1000 iteration) test on snd-usb-audio
>>>   while running mc_nextgen_test loop (1000 iterations) in parallel.
>>> - Ran bind/unbind and rmmod/modprobe tests on both drivers. Also
>>>   generated graphs when after bind/unbind, rmmod/modprobe. Graphs
>>>   look good.
>>> - Note: Please apply the following patch to fix memory leak:
>>>   sound/usb: Fix memory leak in media_snd_stream_delete() during unbind
>>>   https://lkml.org/lkml/2016/3/16/1050
>>
>> Yeah, a way better!
>>
>> For normal bind/unbind, it seems to be working fine. Also
>> for driver's rmmod, so:
>>
>> Tested-by: Mauro Carvalho Chehab 
>>
>> PS.:
>> ===
>>
>> There are still some troubles if we run an infinite loop
>> binding/unbinding au0828 and another one binding/unbinding
>> snd-usb-audio, like this one:
> 
> Yes. I noticed this one when I was running a loop of 1000 on au0828.
> I couldn't reproduce this when I tested this patch.
> 
> P.S: au08282 loops takes longer btw since au0828 initialization is lot more
> complex. We have to look at this one.
> 
>>
>>
>> [   91.556188] [ cut here ]
>> [   91.556500] WARNING: CPU: 1 PID: 2920 at drivers/media/media-entity.c:392 
>> __media_entity_pipeline_start+0x271/0xce0 [media]()
>> [   91.556626] Modules linked in: ir_lirc_codec lirc_dev au8522_dig xc5000 
>> tuner au8522_decoder au8522_common au0828 videobuf2_vmalloc videobuf2_memops 
>> videobuf2_v4l2 videobuf2_core tveeprom dvb_core rc_core v4l2_common videodev 
>> snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device media 
>> cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats 
>> parport_pc ppdev lp parport snd_hda_codec_hdmi intel_rapl 
>> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt kvm 
>> iTCO_vendor_support irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel 
>> ghash_clmulni_intel sha256_ssse3 sha256_generic hmac drbg 
>> snd_hda_codec_realtek i915 snd_hda_codec_generic aesni_intel aes_x86_64 
>> btusb lrw btrtl gf128mul snd_hda_intel glue_helper ablk_helper btbcm btintel 
>> cryptd psmouse snd_hda_codec bluetooth
>> [   91.556693]  snd_hwdep i2c_algo_bit sg snd_hda_core serio_raw pcspkr 
>> evdev drm_kms_helper snd_pcm rfkill drm snd_timer mei_me snd i2c_i801 
>> soundcore lpc_ich mei mfd_core battery video dw_dmac i2c_designware_platform 
>> dw_dmac_core i2c_designware_core acpi_pad button tpm_tis tpm ext4 crc16 
>> mbcache jbd2 dm_mod sd_mod hid_generic usbhid ahci libahci libata e1000e 
>> xhci_pci ptp scsi_mod ehci_pci ehci_hcd pps_core xhci_hcd fan thermal 
>> sdhci_acpi sdhci mmc_core i2c_hid hid
>> [   91.556748] CPU: 1 PID: 2920 Comm: v4l_id Tainted: G  D W   
>> 4.5.0+ #62
>> [   91.556751] Hardware name:  /NUC5i7RYB, BIOS 
>> RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
>> [   91.556754]  a0e247a0 8803a3d17b08 819447c1 
>> 
>> [   91.556759]  88009bbe17c0 8803a3d17b48 8114fd16 
>> a0e20651
>> [   91.556763]  8803a47c9c58 8803a477d2c8 8803a5ac96f8 
>> dc00
>> [   91.556768] Call Trace:
>> [   91.556774]  [] dump_stack+0x85/0xc4
>> [   91.556778]  [] warn_slowpath_common+0xc6/0x120
>> [   91.556783]  [] ? 
>> __media_entity_pipeline_start+0x271/0xce0 [media]
>> [   91.556786]  [] warn_slowpath_null+0x1a/0x20
>> [   91.556790]  [] 
>> __media_entity_pipeline_start+0x271/0xce0 [media]
>> [   91.556794]  [] ? __schedule+0x78a/0x2570
>> [   91.556797]  [] ? memset+0x28/0x30
>> [   91.556802]  [] ? media_entity_pipeline_stop+0x60/0x60 
>> [media]
>> [   91.556806]  [] ? trace_hardirqs_on+0xd/0x10
>> [   91.556810]  [] ? au0828_enable_source+0x55/0x9f0 
>> [au0828]
>> [   91.556813]  [] ? mutex_trylock+0x400/0x400
>> [   91.556818]  [] ? au0828_v4l2_close+0xb3/0x590 [au0828]
>> [   91.556822]  [] au0828_enable_source+0x3f4/0x9f0 
>> [au0828]
>> [   91.556824]  [] ? mutex_trylock+0x400/0x400
>> [   91.556834]  [] v4l_enable_media_source+0x66/0x90 
>> [videodev]
>> [   91.556839]  [] au0828_v4l2_close+0x25a/0x590 [au0828]
>> [   91.556846]  [] v4l2_release+0xf0/0x210 [videodev]
>> [   91.556849]  [] __fput+0x20f/0x6d0
>> [   91.556853]  [] fput+0xe/0x10
>> [   91.556856]  [] task_work_run+0x137/0x200
>> [   91.556859]  [] exit_to_usermode_loop+0x154/0x180
>> [   91.556863]  [] ? trace_hardirqs_on_caller+0x16/0x590
>> [   91.556866]  [] syscall_return_slowpath+0x186/0x1c0
>> [   91.556869]  [] entry_SYSCALL_64_fastpath+0xbf/0xc1
>> [   91.556872] ---[ end trace 

Re: [PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU

[Alexandre Courbot]

On 03/22/2016 10:41 AM, Rob Herring wrote:

On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot  wrote:

On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring  wrote:

On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote:

GM20B's definition is mostly similar to GK20A's, but requires an
additional clock.


[...]


   gpu@0,5700 {
   compatible = "nvidia,gk20a";
@@ -45,3 +49,22 @@ Example:
   iommus = < TEGRA_SWGROUP_GPU>;
   status = "disabled";
   };
+
+Example for GM20B:
+
+ gpu@0,5700 {


Drop the comma and leading zero.


Even though this is how it appears in the actual DT?


Yes, those will need to get fixed, too.


Sorry, I just want to confirm that I understand why this needs to be 
fixed. The parent node has #address-cells = <2>, and the practice of 
specifying two cells in the node name is consistent with what I see in 
http://www.devicetree.org/Device_Tree_Usage.


However in the device tree usage example one can interpret the two cells 
as being two different components of the address, whereas in our case we 
are using two cells because the address is 64-bit - hence we should 
specify it in the name as a single entity. Is this correct?


Thanks,
Alex.

Re: [PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU

[Alexandre Courbot]

On 03/22/2016 10:41 AM, Rob Herring wrote:

On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot  wrote:

On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring  wrote:

On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote:

GM20B's definition is mostly similar to GK20A's, but requires an
additional clock.


[...]


   gpu@0,5700 {
   compatible = "nvidia,gk20a";
@@ -45,3 +49,22 @@ Example:
   iommus = < TEGRA_SWGROUP_GPU>;
   status = "disabled";
   };
+
+Example for GM20B:
+
+ gpu@0,5700 {


Drop the comma and leading zero.


Even though this is how it appears in the actual DT?


Yes, those will need to get fixed, too.


Sorry, I just want to confirm that I understand why this needs to be 
fixed. The parent node has #address-cells = <2>, and the practice of 
specifying two cells in the node name is consistent with what I see in 
http://www.devicetree.org/Device_Tree_Usage.


However in the device tree usage example one can interpret the two cells 
as being two different components of the address, whereas in our case we 
are using two cells because the address is 64-bit - hence we should 
specify it in the name as a single entity. Is this correct?


Thanks,
Alex.

RE: [f2fs-dev] [PATCH 1/2] f2fs: cover large section in sanity check of super

[Chao Yu]

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, March 22, 2016 2:56 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim; stable 4 . 5+
> Subject: [f2fs-dev] [PATCH 1/2] f2fs: cover large section in sanity check of 
> super
> 
> This patch fixes the bug which does not cover a large section case when 
> checking
> the sanity of superblock.
> 
> Reported-by: Matthias Prager 
> Reported-by: David Gnedt 
> Cc: stable 4.5+ 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/super.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 15bb81f..fc9147f 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1000,6 +1000,7 @@ static inline bool sanity_check_area_boundary(struct 
> super_block *sb,
>   u32 segment_count_main = le32_to_cpu(raw_super->segment_count_main);
>   u32 segment_count = le32_to_cpu(raw_super->segment_count);
>   u32 log_blocks_per_seg = le32_to_cpu(raw_super->log_blocks_per_seg);
> + u32 segs_per_sec = le32_to_cpu(raw_super->segs_per_sec);
> 
>   if (segment0_blkaddr != cp_blkaddr) {
>   f2fs_msg(sb, KERN_INFO,
> @@ -1044,12 +1045,26 @@ static inline bool sanity_check_area_boundary(struct 
> super_block *sb,
>   return true;
>   }
> 
> - if (main_blkaddr + (segment_count_main << log_blocks_per_seg) !=
> + if (segs_per_sec == 1 &&
> + main_blkaddr + (segment_count_main << log_blocks_per_seg) !=
>   segment0_blkaddr + (segment_count << log_blocks_per_seg)) {
>   f2fs_msg(sb, KERN_INFO,
>   "Wrong MAIN_AREA boundary, start(%u) end(%u) 
> blocks(%u)",
>   main_blkaddr,
> - segment0_blkaddr + (segment_count << 
> log_blocks_per_seg),
> + segment0_blkaddr +
> + (segment_count << log_blocks_per_seg),
> + segment_count_main << log_blocks_per_seg);
> + return true;
> + }
> +
> + if (segs_per_sec > 1 &&

if ((segs_per_sec > 1 || secs_per_zone > 1)) && ?

Thanks,

> + main_blkaddr + (segment_count_main << log_blocks_per_seg) >
> + segment0_blkaddr + (segment_count << log_blocks_per_seg)) {
> + f2fs_msg(sb, KERN_INFO,
> + "Wrong MAIN_AREA boundary in large section, start(%u) 
> end(%u) blocks(%u)",
> + main_blkaddr,
> + segment0_blkaddr +
> + (segment_count << log_blocks_per_seg),
>   segment_count_main << log_blocks_per_seg);
>   return true;
>   }
> --
> 2.6.3
> 
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

RE: [f2fs-dev] [PATCH 1/2] f2fs: cover large section in sanity check of super

[Chao Yu]

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, March 22, 2016 2:56 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim; stable 4 . 5+
> Subject: [f2fs-dev] [PATCH 1/2] f2fs: cover large section in sanity check of 
> super
> 
> This patch fixes the bug which does not cover a large section case when 
> checking
> the sanity of superblock.
> 
> Reported-by: Matthias Prager 
> Reported-by: David Gnedt 
> Cc: stable 4.5+ 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/super.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 15bb81f..fc9147f 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1000,6 +1000,7 @@ static inline bool sanity_check_area_boundary(struct 
> super_block *sb,
>   u32 segment_count_main = le32_to_cpu(raw_super->segment_count_main);
>   u32 segment_count = le32_to_cpu(raw_super->segment_count);
>   u32 log_blocks_per_seg = le32_to_cpu(raw_super->log_blocks_per_seg);
> + u32 segs_per_sec = le32_to_cpu(raw_super->segs_per_sec);
> 
>   if (segment0_blkaddr != cp_blkaddr) {
>   f2fs_msg(sb, KERN_INFO,
> @@ -1044,12 +1045,26 @@ static inline bool sanity_check_area_boundary(struct 
> super_block *sb,
>   return true;
>   }
> 
> - if (main_blkaddr + (segment_count_main << log_blocks_per_seg) !=
> + if (segs_per_sec == 1 &&
> + main_blkaddr + (segment_count_main << log_blocks_per_seg) !=
>   segment0_blkaddr + (segment_count << log_blocks_per_seg)) {
>   f2fs_msg(sb, KERN_INFO,
>   "Wrong MAIN_AREA boundary, start(%u) end(%u) 
> blocks(%u)",
>   main_blkaddr,
> - segment0_blkaddr + (segment_count << 
> log_blocks_per_seg),
> + segment0_blkaddr +
> + (segment_count << log_blocks_per_seg),
> + segment_count_main << log_blocks_per_seg);
> + return true;
> + }
> +
> + if (segs_per_sec > 1 &&

if ((segs_per_sec > 1 || secs_per_zone > 1)) && ?

Thanks,

> + main_blkaddr + (segment_count_main << log_blocks_per_seg) >
> + segment0_blkaddr + (segment_count << log_blocks_per_seg)) {
> + f2fs_msg(sb, KERN_INFO,
> + "Wrong MAIN_AREA boundary in large section, start(%u) 
> end(%u) blocks(%u)",
> + main_blkaddr,
> + segment0_blkaddr +
> + (segment_count << log_blocks_per_seg),
>   segment_count_main << log_blocks_per_seg);
>   return true;
>   }
> --
> 2.6.3
> 
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

[Doug Anderson]

Shawn,

On Mon, Mar 21, 2016 at 7:53 PM, Shawn Lin  wrote:
> + Vinod
>
>
> On 2016/3/22 10:33, Doug Anderson wrote:
>>
>> Shawn,
>>
>> On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin 
>> wrote:

 ...but, looking at this, presumably before landing any patch that made
 dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
 _all_ users of dma_request_slave_channel to handle error pointers
 being returned.  Right now dma_request_slave_channel() says it returns
 a pointer to a channel or NULL and the function explicitly avoids
 returning any errors.  That might be possible, but it's a big
 change...
>>>
>>>
>>>
>>> At first glance, it's a big change, but maybe not really.
>>> Almost all of them use the templet like:
>>> ch = dma_request_slave_channel
>>> if (!ch)
>>>  balabala
>>>
>>> It's same for all the non-null return pointer/non-zero value ?
>>>
>>> So from my view, we can safely change dma_request_slave_channel,
>>> and leave the caller here. I presumably the respective
>>> drivers will graduately migrate to check the return value with
>>> EPROBE_DEFER if they do care this issue. Otherwise, we believe
>>> they don't suffer the changes we make, just as what they did in the
>>> past. Does that make sense?
>>
>>
>> ...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
>> callers, then existing callers will think you've returned a valid
>> pointer when you really returned an error pointer.  They'll pass this
>> error pointer around like it's a valid "struct dma_chan", won't then?
>>
>
> possibly, it depends on how caller deal with it. Should check it case by
> case for each caller.
>
>> Actually, could your code just call
>> dma_request_slave_channel_reason().  Oh, looks like that's exactly
>> what you want.  See commit 0ad7c00057dc ("dma: add channel request API
>> that supports deferred probe").  Oh, but I'm looking at 4.4.  Looking
>> at linuxnext, it looks like this got renamed to dma_request_chan().
>> ...so you need to use that, no?
>>
>> Strange, but on 4.4 there was some extra code in
>> dma_request_slave_channel() that wasn't in
>> dma_request_slave_channel_reason().  ...but looks like that all got
>> cleaned up in the same CL that added the new name.
>
>
> dma_request_chan already return ERR_PTR(-EPROBE_DEFER), but
> dma_request_slave_channel ignore this and rewrite it to be NULL.
> Strange behaviour looks to me. commit 0ad7c00057dc ("dma: add channel
> request API that supports deferred probe")  did the right thing, but
> what happened then?  It was drop for some reasons?
>
> Hello Vinod,
>
> Could you please elaborate some more infomation to commit 0ad7c00057dc
> ("dma: add channel request API that supports deferred probe") :) ?

I think it's relatively straightforward.

The scheme they came up with allows them to more easily update one
client at a time.  AKA:

* If your code has been updated to handle ERR_PTR() returns, you call
dma_request_slave_channel_reason().

* If your code hasn't been updated, it will still call
dma_request_slave_channel().  In this case EPROBE_DEFER is treated
like any other failure.  That's not ideal but better than the
alternative.

* In recent kernels dma_request_slave_channel() was renamed to
dma_request_chan().  Old code can still use
dma_request_slave_channel_reason() but presumably they want you to use
dma_request_chan() for new code.  They are equivalent:

> #define dma_request_slave_channel_reason(dev, name) dma_request_chan(dev, 
> name)


So your patch should be:

-   rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
-   if (!rs->dma_tx.ch)
+   rs->dma_tx.ch = dma_request_slave_chan(rs->dev, "tx");
+   if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
+   /* Check tx to see if we need defer probing driver */
+   if (rs->dma_tx.ch == ERR_PTR(-EPROBE_DEFER)) {
+   ret = -EPROBE_DEFER;
+   goto err_get_fifo_len;
+   }
dev_warn(rs->dev, "Failed to request TX DMA channel\n");
+   rs->dma_tx.ch = NULL;
+   }

...and then a similar patch for the "rx" side of things.

-Doug

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

[Doug Anderson]

Shawn,

On Mon, Mar 21, 2016 at 7:53 PM, Shawn Lin  wrote:
> + Vinod
>
>
> On 2016/3/22 10:33, Doug Anderson wrote:
>>
>> Shawn,
>>
>> On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin 
>> wrote:

 ...but, looking at this, presumably before landing any patch that made
 dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
 _all_ users of dma_request_slave_channel to handle error pointers
 being returned.  Right now dma_request_slave_channel() says it returns
 a pointer to a channel or NULL and the function explicitly avoids
 returning any errors.  That might be possible, but it's a big
 change...
>>>
>>>
>>>
>>> At first glance, it's a big change, but maybe not really.
>>> Almost all of them use the templet like:
>>> ch = dma_request_slave_channel
>>> if (!ch)
>>>  balabala
>>>
>>> It's same for all the non-null return pointer/non-zero value ?
>>>
>>> So from my view, we can safely change dma_request_slave_channel,
>>> and leave the caller here. I presumably the respective
>>> drivers will graduately migrate to check the return value with
>>> EPROBE_DEFER if they do care this issue. Otherwise, we believe
>>> they don't suffer the changes we make, just as what they did in the
>>> past. Does that make sense?
>>
>>
>> ...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
>> callers, then existing callers will think you've returned a valid
>> pointer when you really returned an error pointer.  They'll pass this
>> error pointer around like it's a valid "struct dma_chan", won't then?
>>
>
> possibly, it depends on how caller deal with it. Should check it case by
> case for each caller.
>
>> Actually, could your code just call
>> dma_request_slave_channel_reason().  Oh, looks like that's exactly
>> what you want.  See commit 0ad7c00057dc ("dma: add channel request API
>> that supports deferred probe").  Oh, but I'm looking at 4.4.  Looking
>> at linuxnext, it looks like this got renamed to dma_request_chan().
>> ...so you need to use that, no?
>>
>> Strange, but on 4.4 there was some extra code in
>> dma_request_slave_channel() that wasn't in
>> dma_request_slave_channel_reason().  ...but looks like that all got
>> cleaned up in the same CL that added the new name.
>
>
> dma_request_chan already return ERR_PTR(-EPROBE_DEFER), but
> dma_request_slave_channel ignore this and rewrite it to be NULL.
> Strange behaviour looks to me. commit 0ad7c00057dc ("dma: add channel
> request API that supports deferred probe")  did the right thing, but
> what happened then?  It was drop for some reasons?
>
> Hello Vinod,
>
> Could you please elaborate some more infomation to commit 0ad7c00057dc
> ("dma: add channel request API that supports deferred probe") :) ?

I think it's relatively straightforward.

The scheme they came up with allows them to more easily update one
client at a time.  AKA:

* If your code has been updated to handle ERR_PTR() returns, you call
dma_request_slave_channel_reason().

* If your code hasn't been updated, it will still call
dma_request_slave_channel().  In this case EPROBE_DEFER is treated
like any other failure.  That's not ideal but better than the
alternative.

* In recent kernels dma_request_slave_channel() was renamed to
dma_request_chan().  Old code can still use
dma_request_slave_channel_reason() but presumably they want you to use
dma_request_chan() for new code.  They are equivalent:

> #define dma_request_slave_channel_reason(dev, name) dma_request_chan(dev, 
> name)


So your patch should be:

-   rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
-   if (!rs->dma_tx.ch)
+   rs->dma_tx.ch = dma_request_slave_chan(rs->dev, "tx");
+   if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
+   /* Check tx to see if we need defer probing driver */
+   if (rs->dma_tx.ch == ERR_PTR(-EPROBE_DEFER)) {
+   ret = -EPROBE_DEFER;
+   goto err_get_fifo_len;
+   }
dev_warn(rs->dev, "Failed to request TX DMA channel\n");
+   rs->dma_tx.ch = NULL;
+   }

...and then a similar patch for the "rx" side of things.

-Doug

Re: [PATCH 3/3] cpufreq: Always update current frequency before startig governor

[Viresh Kumar]

On 21-03-16, 15:47, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Make policy->cur match the current frequency returned by the driver's
> ->get() callback before starting the governor in case they went out of
> sync in the meantime and drop the piece of code attempting to
> resync policy->cur with the real frequency of the boot CPU from
> cpufreq_resume() as it serves no purpose any more (and it's racy and
> super-ugly anyway).
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   14 +++---
>  1 file changed, 3 insertions(+), 11 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -1680,17 +1680,6 @@ void cpufreq_resume(void)
>  __func__, policy);
>   }
>   }
> -
> - /*
> -  * schedule call cpufreq_update_policy() for first-online CPU, as that
> -  * wouldn't be hotplugged-out on suspend. It will verify that the
> -  * current freq is in sync with what we believe it to be.
> -  */
> - policy = cpufreq_cpu_get_raw(cpumask_first(cpu_online_mask));
> - if (WARN_ON(!policy))
> - return;
> -
> - schedule_work(>update);
>  }
>  
>  /**
> @@ -2062,6 +2051,9 @@ static int cpufreq_start_governor(struct
>  {
>   int ret;
>  
> + if (cpufreq_driver->get && !cpufreq_driver->setpolicy)
> + cpufreq_update_current_freq(policy);
> +
>   ret = cpufreq_governor(policy, CPUFREQ_GOV_START);
>   return ret ? ret : cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
>  }

This looks fine, but I am searching for answers to few doubts, maybe
you can help..

Why we did the same in process context earlier? And why it wouldn't be
a problem now, when we do it in interrupt context? Will IRQs be
disabled here? If so, then will you hit following ?

static void __cpufreq_notify_transition(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, unsigned int state)
{
BUG_ON(irqs_disabled());

...
}

And will calling notifiers from interrupt-context just fine ?

-- 
viresh

Re: [PATCH 3/3] cpufreq: Always update current frequency before startig governor

[Viresh Kumar]

On 21-03-16, 15:47, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Make policy->cur match the current frequency returned by the driver's
> ->get() callback before starting the governor in case they went out of
> sync in the meantime and drop the piece of code attempting to
> resync policy->cur with the real frequency of the boot CPU from
> cpufreq_resume() as it serves no purpose any more (and it's racy and
> super-ugly anyway).
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   14 +++---
>  1 file changed, 3 insertions(+), 11 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -1680,17 +1680,6 @@ void cpufreq_resume(void)
>  __func__, policy);
>   }
>   }
> -
> - /*
> -  * schedule call cpufreq_update_policy() for first-online CPU, as that
> -  * wouldn't be hotplugged-out on suspend. It will verify that the
> -  * current freq is in sync with what we believe it to be.
> -  */
> - policy = cpufreq_cpu_get_raw(cpumask_first(cpu_online_mask));
> - if (WARN_ON(!policy))
> - return;
> -
> - schedule_work(>update);
>  }
>  
>  /**
> @@ -2062,6 +2051,9 @@ static int cpufreq_start_governor(struct
>  {
>   int ret;
>  
> + if (cpufreq_driver->get && !cpufreq_driver->setpolicy)
> + cpufreq_update_current_freq(policy);
> +
>   ret = cpufreq_governor(policy, CPUFREQ_GOV_START);
>   return ret ? ret : cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
>  }

This looks fine, but I am searching for answers to few doubts, maybe
you can help..

Why we did the same in process context earlier? And why it wouldn't be
a problem now, when we do it in interrupt context? Will IRQs be
disabled here? If so, then will you hit following ?

static void __cpufreq_notify_transition(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, unsigned int state)
{
BUG_ON(irqs_disabled());

...
}

And will calling notifiers from interrupt-context just fine ?

-- 
viresh

linux-next: Tree for Mar 22

[Stephen Rothwell]

Hi all,

Please do not add any v4.7 related material to your linux-next included
trees until after v4.6-rc1 is released.

Changes since 20160321:

The arm64 tree gained a conflict against Linus' tree.

The rdma tree gained conflicts against Linus' tree.

The drm tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1943
 1620 files changed, 111055 insertions(+), 31754 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (e531cdf50a8a Merge tag 'mmc-v4.6' of 
git://git.linaro.org/people/ulf.hansson/mmc)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (deaf7565eb61 ARCv2: ioremap: Support dynamic 
peripheral address space)
Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b562e44f507e Linux 4.5)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (9ef595d83aea sparc: Convert naked unsigned uses to 
unsigned int)
Merging net/master (6b0725232dd1 Merge branch 'bridge-gso-segs-and-size')
Merging ipsec/master (215276c0147e xfrm: Reset encapsulation field of the skb 
before transformation)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (10da848f67a7 ssb: host_soc depends on sprom)
Merging mac80211/master (ad8ec957f693 wext: unregister_pernet_subsys() on 
notifier registration failure)
Merging sound-current/for-linus (c64c1437afb1 ALSA: hda - Fix missing ELD 
update at unplugging)
Merging pci-current/for-linus (30b5b8808c12 PCI: Restore inclusion of 
pci/hotplug Kconfig)
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (6b5f04b6cf8e Merge branch 'for-4.6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup)
Merging usb-gadget-fixes/fixes (3b2435192fe9 MAINTAINERS: drop OMAP USB and 
MUSB maintainership)
Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (1200b6809dfd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next)
Merging char-misc.current/char-misc-linus (5cd0911a9e0e Merge tag 
'please-pull-pstore' of 
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux)
Merging input-current/for-linus (4d2508a55990 ARM: pxa/raumfeld: use 
PROPERTY_ENTRY_INTEGER to define props)
Merging crypto-current/master (dfe97ad30e8c crypto: marvell/cesa - forward 
devm_ioremap_resource() error code)
Merging ide/master (0d7ef45cdeeb ide: palm_bk3710: test clock rate to avoid 
division by 0)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for

linux-next: Tree for Mar 22

[Stephen Rothwell]

Hi all,

Please do not add any v4.7 related material to your linux-next included
trees until after v4.6-rc1 is released.

Changes since 20160321:

The arm64 tree gained a conflict against Linus' tree.

The rdma tree gained conflicts against Linus' tree.

The drm tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1943
 1620 files changed, 111055 insertions(+), 31754 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (e531cdf50a8a Merge tag 'mmc-v4.6' of 
git://git.linaro.org/people/ulf.hansson/mmc)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (deaf7565eb61 ARCv2: ioremap: Support dynamic 
peripheral address space)
Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b562e44f507e Linux 4.5)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (9ef595d83aea sparc: Convert naked unsigned uses to 
unsigned int)
Merging net/master (6b0725232dd1 Merge branch 'bridge-gso-segs-and-size')
Merging ipsec/master (215276c0147e xfrm: Reset encapsulation field of the skb 
before transformation)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (10da848f67a7 ssb: host_soc depends on sprom)
Merging mac80211/master (ad8ec957f693 wext: unregister_pernet_subsys() on 
notifier registration failure)
Merging sound-current/for-linus (c64c1437afb1 ALSA: hda - Fix missing ELD 
update at unplugging)
Merging pci-current/for-linus (30b5b8808c12 PCI: Restore inclusion of 
pci/hotplug Kconfig)
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (6b5f04b6cf8e Merge branch 'for-4.6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup)
Merging usb-gadget-fixes/fixes (3b2435192fe9 MAINTAINERS: drop OMAP USB and 
MUSB maintainership)
Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (1200b6809dfd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next)
Merging char-misc.current/char-misc-linus (5cd0911a9e0e Merge tag 
'please-pull-pstore' of 
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux)
Merging input-current/for-linus (4d2508a55990 ARM: pxa/raumfeld: use 
PROPERTY_ENTRY_INTEGER to define props)
Merging crypto-current/master (dfe97ad30e8c crypto: marvell/cesa - forward 
devm_ioremap_resource() error code)
Merging ide/master (0d7ef45cdeeb ide: palm_bk3710: test clock rate to avoid 
division by 0)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for

Re: [PATCH v2 0/4] locking/mutex: Enable optimistic spinning of lock waiter

[Waiman Long]

On 02/16/2016 03:51 AM, Peter Zijlstra wrote:

On Fri, Feb 12, 2016 at 12:32:11PM -0500, Waiman Long wrote:

My own test on a 4-socket E7-4820 v3 system showed a regression of
about 4% in the high_systime workload with Peter's patch which this
new patch effectively eliminates.

Testing on an 8-socket Westmere-EX server, however, has performance
change from -9% to than +140% on the fserver workload of AIM7
depending on how the system was set up.

Subject: [lkp] [locking/mutex] aaca135480: -72.9% fsmark.files_per_sec

My patch also generated the above email.

Please also test that benchmark against this approach.



I also got an email from "kernel test robot", it didn't list fsmark at 
all. Instead, the subject was


[lkp] [locking/mutex] 5267438002: +38.9% 
fileio.time.involuntary_context_switches


  4409 ±  1% +38.9%   6126 ±  2%  
fileio.time.involuntary_context_switches
  6.00 ±  0% +33.3%   8.00 ±  0%  
fileio.time.percent_of_cpu_this_job_got

 36.06 ±  0% +43.0%  51.55 ±  0%  fileio.time.system_time
   1828660 ±  0% -92.5% 137258 ±  0%  
fileio.time.voluntary_context_switches


Given that the number of voluntary context switches dropped by 92.5%, an 
increase in involuntary context switches that is order of magnitude less 
than the voluntary context switches should be OK, I think.


Do you know how to report back that this increase is expected and is 
nothing to worry about? Do I just reply it back?


Cheers,
Longman

Re: [PATCH v2 0/4] locking/mutex: Enable optimistic spinning of lock waiter

[Waiman Long]

On 02/16/2016 03:51 AM, Peter Zijlstra wrote:

On Fri, Feb 12, 2016 at 12:32:11PM -0500, Waiman Long wrote:

My own test on a 4-socket E7-4820 v3 system showed a regression of
about 4% in the high_systime workload with Peter's patch which this
new patch effectively eliminates.

Testing on an 8-socket Westmere-EX server, however, has performance
change from -9% to than +140% on the fserver workload of AIM7
depending on how the system was set up.

Subject: [lkp] [locking/mutex] aaca135480: -72.9% fsmark.files_per_sec

My patch also generated the above email.

Please also test that benchmark against this approach.



I also got an email from "kernel test robot", it didn't list fsmark at 
all. Instead, the subject was


[lkp] [locking/mutex] 5267438002: +38.9% 
fileio.time.involuntary_context_switches


  4409 ±  1% +38.9%   6126 ±  2%  
fileio.time.involuntary_context_switches
  6.00 ±  0% +33.3%   8.00 ±  0%  
fileio.time.percent_of_cpu_this_job_got

 36.06 ±  0% +43.0%  51.55 ±  0%  fileio.time.system_time
   1828660 ±  0% -92.5% 137258 ±  0%  
fileio.time.voluntary_context_switches


Given that the number of voluntary context switches dropped by 92.5%, an 
increase in involuntary context switches that is order of magnitude less 
than the voluntary context switches should be OK, I think.


Do you know how to report back that this increase is expected and is 
nothing to worry about? Do I just reply it back?


Cheers,
Longman

[PATCH v3 1/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

[Zhen Lei]

1.For coherent DMA
  In swiotlb_alloc_coherent, it directly return vaddr on success, and
pass vaddr to free_pages on failure. So, we can directly transparent pass
vaddr from __dma_free to swiotlb_free_coherent.
  According to my testing, it can save 8 clock cycles.

2.For non-coherent DMA.
  Keep no change for the original processing flow.
  Because all DDR memory mapped as cacheable by default. But for
non-coherent devices, both CPUs and devices should use NC(non-cacheable)
attributes to access memory, to keep consistency. So we can not directly
use vaddr retured by __dma_alloc_coherent, but should further remap the
physical memory as NC and return it. So in __dma_free, we first use the
NC-vaddr to unmap, then get vaddr base upon dma_handle and use it to free
memory back to buddy.

Signed-off-by: Zhen Lei 
---
 arch/arm64/mm/dma-mapping.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index a6e757c..ceb2018 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -187,16 +187,22 @@ static void __dma_free(struct device *dev, size_t size,
   void *vaddr, dma_addr_t dma_handle,
   struct dma_attrs *attrs)
 {
-   void *swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
-
size = PAGE_ALIGN(size);

if (!is_device_dma_coherent(dev)) {
if (__free_from_pool(vaddr, size))
return;
vunmap(vaddr);
+
+   /*
+* For non-coherent DMA, the vaddr is not part of the linear
+* mapping as it has been remapped by __dma_alloc() via
+* dma_common_contiguous_remap(), hence for swiotlb freeing we
+* need the actual linear map address.
+*/
+   vaddr = phys_to_virt(dma_to_phys(dev, dma_handle));
}
-   __dma_free_coherent(dev, size, swiotlb_addr, dma_handle, attrs);
+   __dma_free_coherent(dev, size, vaddr, dma_handle, attrs);
 }

 static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
--
2.5.0

[PATCH v3 1/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

[Zhen Lei]

1.For coherent DMA
  In swiotlb_alloc_coherent, it directly return vaddr on success, and
pass vaddr to free_pages on failure. So, we can directly transparent pass
vaddr from __dma_free to swiotlb_free_coherent.
  According to my testing, it can save 8 clock cycles.

2.For non-coherent DMA.
  Keep no change for the original processing flow.
  Because all DDR memory mapped as cacheable by default. But for
non-coherent devices, both CPUs and devices should use NC(non-cacheable)
attributes to access memory, to keep consistency. So we can not directly
use vaddr retured by __dma_alloc_coherent, but should further remap the
physical memory as NC and return it. So in __dma_free, we first use the
NC-vaddr to unmap, then get vaddr base upon dma_handle and use it to free
memory back to buddy.

Signed-off-by: Zhen Lei 
---
 arch/arm64/mm/dma-mapping.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index a6e757c..ceb2018 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -187,16 +187,22 @@ static void __dma_free(struct device *dev, size_t size,
   void *vaddr, dma_addr_t dma_handle,
   struct dma_attrs *attrs)
 {
-   void *swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
-
size = PAGE_ALIGN(size);

if (!is_device_dma_coherent(dev)) {
if (__free_from_pool(vaddr, size))
return;
vunmap(vaddr);
+
+   /*
+* For non-coherent DMA, the vaddr is not part of the linear
+* mapping as it has been remapped by __dma_alloc() via
+* dma_common_contiguous_remap(), hence for swiotlb freeing we
+* need the actual linear map address.
+*/
+   vaddr = phys_to_virt(dma_to_phys(dev, dma_handle));
}
-   __dma_free_coherent(dev, size, swiotlb_addr, dma_handle, attrs);
+   __dma_free_coherent(dev, size, vaddr, dma_handle, attrs);
 }

 static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
--
2.5.0

[PATCH v3 0/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

[Zhen Lei]

Changelog:
v2 -> v3:
1. Just add some description for this patch.

v1 -> v2:
1. Give up removing the conversion, because of thoughtless, instead moved it
into branch if (!is_device_dma_coherent(dev)). Thanks for Catalin's detailed
explanation, I directly take some relies as comment in the code.

Zhen Lei (1):
  arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

 arch/arm64/mm/dma-mapping.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

-- 
2.5.0

[PATCH v3 0/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

[Zhen Lei]

Changelog:
v2 -> v3:
1. Just add some description for this patch.

v1 -> v2:
1. Give up removing the conversion, because of thoughtless, instead moved it
into branch if (!is_device_dma_coherent(dev)). Thanks for Catalin's detailed
explanation, I directly take some relies as comment in the code.

Zhen Lei (1):
  arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

 arch/arm64/mm/dma-mapping.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

-- 
2.5.0

Re: [PATCH 2/3] cpufreq: Introduce cpufreq_update_current_freq()

[Viresh Kumar]

On 21-03-16, 15:46, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Move the part of cpufreq_update_policy() that obtains the current
> frequency from the driver and updates policy->cur if necessary to
> a separate function, cpufreq_get_current_freq().
> 
> That should not introduce functional changes and subsequent change
> set will need it.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   28 +++-
>  1 file changed, 19 insertions(+), 9 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 2/3] cpufreq: Introduce cpufreq_update_current_freq()

[Viresh Kumar]

On 21-03-16, 15:46, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Move the part of cpufreq_update_policy() that obtains the current
> frequency from the driver and updates policy->cur if necessary to
> a separate function, cpufreq_get_current_freq().
> 
> That should not introduce functional changes and subsequent change
> set will need it.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   28 +++-
>  1 file changed, 19 insertions(+), 9 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/3] cpufreq: Introduce cpufreq_start_governor()

[Viresh Kumar]

On 21-03-16, 15:45, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Starting a governor in cpufreq always follows the same pattern
> involving two calls to cpufreq_governor(), one with the event
> argument set to CPUFREQ_GOV_START and one with that argument set to
> CPUFREQ_GOV_LIMITS.
> 
> Introduce cpufreq_start_governor() that will carry out those two
> operations and make all places where governors are started use it.
> 
> That slightly modifies the behavior of cpufreq_set_policy() which
> now also will go back to the old governor if the second call to
> cpufreq_governor() (the one with event equal to CPUFREQ_GOV_LIMITS)
> fails, but that really is how it should work in the first place.
> 
> Also cpufreq_resume() will now pring an error message if the
> CPUFREQ_GOV_LIMITS call to cpufreq_governor() fails, but that
> makes it follow cpufreq_add_policy_cpu() and cpufreq_offline()
> in that respect.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   44 ++--
>  1 file changed, 22 insertions(+), 22 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/3] cpufreq: Introduce cpufreq_start_governor()

[Viresh Kumar]

On 21-03-16, 15:45, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Starting a governor in cpufreq always follows the same pattern
> involving two calls to cpufreq_governor(), one with the event
> argument set to CPUFREQ_GOV_START and one with that argument set to
> CPUFREQ_GOV_LIMITS.
> 
> Introduce cpufreq_start_governor() that will carry out those two
> operations and make all places where governors are started use it.
> 
> That slightly modifies the behavior of cpufreq_set_policy() which
> now also will go back to the old governor if the second call to
> cpufreq_governor() (the one with event equal to CPUFREQ_GOV_LIMITS)
> fails, but that really is how it should work in the first place.
> 
> Also cpufreq_resume() will now pring an error message if the
> CPUFREQ_GOV_LIMITS call to cpufreq_governor() fails, but that
> makes it follow cpufreq_add_policy_cpu() and cpufreq_offline()
> in that respect.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   44 ++--
>  1 file changed, 22 insertions(+), 22 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[majun (F)]

在 2016/3/21 18:29, Thomas Gleixner 写道:
> On Thu, 17 Mar 2016, MaJun wrote:
>> This patch set is used to fix the problem of remap a set of registers
>> repeatedly in current mbigen driver.
>>
>>   irqchip/mbigen:Change the mbigen node definition in dt binding file
>>   irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
>> definition
> 
> These subject lines are still horrible as they tell nothing about the nature
> of the change. I fixed them up along with the changelogs and applied them to
> irq/urgent. Can you spot the difference?

Yes, after you changing, the subject and change log clearly show why we need to
do this change.
I have learned a lot from you :)

> 
> While at it. The config switch for this driver is horrible. It's just in the
> middle of the device driver configs. Why is this configurable by the user at
> all? It simply should be selected by arm64 or some subarch configuration
> there. Please clean that up.
> 
will do.

Thanks!
MaJun

> Thanks,
> 
>   tglx
> 
> .
> 

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[majun (F)]

在 2016/3/21 18:29, Thomas Gleixner 写道:
> On Thu, 17 Mar 2016, MaJun wrote:
>> This patch set is used to fix the problem of remap a set of registers
>> repeatedly in current mbigen driver.
>>
>>   irqchip/mbigen:Change the mbigen node definition in dt binding file
>>   irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
>> definition
> 
> These subject lines are still horrible as they tell nothing about the nature
> of the change. I fixed them up along with the changelogs and applied them to
> irq/urgent. Can you spot the difference?

Yes, after you changing, the subject and change log clearly show why we need to
do this change.
I have learned a lot from you :)

> 
> While at it. The config switch for this driver is horrible. It's just in the
> middle of the device driver configs. Why is this configurable by the user at
> all? It simply should be selected by arm64 or some subarch configuration
> there. Please clean that up.
> 
will do.

Thanks!
MaJun

> Thanks,
> 
>   tglx
> 
> .
> 

Linux 3.4.111

[Zefan Li]

I'm announcing the release of the 3.4.111 kernel.

All users of the 3.4 kernel series must upgrade.

The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary





The following changes since commit 3edd6224c2a677bb59efe0b083a51fc2b3b5c64d:

  Linux 3.4.110 (2015-10-22 09:20:09 +0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lizf/linux-3.4.y.git 
tags/v3.4.111

for you to fetch changes up to 3389604d77540abf738b486d650c1745b2d663ca:

  Linux 3.4.111 (2016-03-21 09:17:59 +0800)


This is the 3.4.111 stable release


AMAN DEEP (1):
  usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() 
function

Al Viro (3):
  9p: don't leave a half-initialized inode sitting around
  sg_start_req(): make sure that there's not too many elements in iovec
  get rid of s_files and files_lock

Aleksei Mamlin (1):
  libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk 
VB0250EAVER

Alex Deucher (1):
  drm/radeon/combios: add some validation of lvds values

Alexei Potashnik (1):
  target/iscsi: Fix double free of a TUR followed by a solicited NOPOUT

Andrey Vagin (1):
  netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get

Andy Lutomirski (2):
  x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
  x86/ldt: Make modify_ldt synchronous

Anssi Hannula (1):
  ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly

Arne Fitzenreiter (2):
  libata: add ATA_HORKAGE_NOTRIM
  libata: force disable trim for SuperSSpeed S238

Bart Van Assche (1):
  libfc: Fix fc_fcp_cleanup_each_cmd()

Ben Hutchings (2):
  isdn_ppp: Add checks for allocation failure in isdn_ppp_open()
  ppp, slip: Validate VJ compression slot parameters completely

Ben Zhang (1):
  kernel/watchdog.c: touch_nmi_watchdog should only touch local cpu not 
every one

Bernhard Bender (1):
  Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen

Brian Campbell (1):
  xhci: Calculate old endpoints correctly on device reset

Chris Metcalf (1):
  tile: use free_bootmem_late() for initrd

Claudio Cappelli (1):
  USB: option: add 2020:4000 ID

Clemens Ladisch (2):
  ALSA: tlv: compute TLV_*_ITEM lengths automatically
  ALSA: tlv: add DECLARE_TLV_DB_RANGE()

Dan Carpenter (1):
  rds: fix an integer overflow test in rds_info_getsockopt()

Daniel Borkmann (1):
  rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver

David Ahern (1):
  net: Fix RCU splat in af_key

David Daney (1):
  MIPS: Make set_pte() SMP safe.

David Howells (2):
  KEYS: Fix race between key destruction and finding a keyring by name
  KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring

Dennis Yang (1):
  dm btree remove: fix bug in redistribute3

Dirk Behme (1):
  USB: sierra: add 1199:68AB device ID

Dominic Sacr茅 (1):
  ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4

Edward Hyunkoo Jee (1):
  inet: frags: fix defragmented packet's IP header for af_packet

Eric Northup (1):
  KVM: x86: work around infinite loop in microcode when #AC is delivered

Felix Fietkau (1):
  MIPS: Fix sched_getaffinity with MT FPAFF enabled

Filipe Manana (1):
  Btrfs: use kmem_cache_free when freeing entry in inode cache

Gioh Kim (1):
  fs/buffer.c: support buffer cache allocations with gfp modifiers

Hannes Frederic Sowa (3):
  net: add validation for the socket syscall protocol argument
  ipv6: probe routes asynchronous in rt6_probe
  net: fix warnings in 'make htmldocs' by moving macro definition out of 
field declaration

Heiko Carstens (1):
  s390/process: fix sfpc inline assembly

Herbert Xu (2):
  net: Clone skb before setting peeked flag
  crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer

Herton R. Krzesinski (1):
  ipc,sem: fix use after free on IPC_RMID after a task using same semaphore 
set exits

Jan Beulich (1):
  x86/LDT: Print the real LDT base address

Jason Wang (1):
  virtio-net: drop NETIF_F_FRAGLIST

Jiri Pirko (1):
  niu: don't count tx error twice in case of headroom realloc fails

Joe Perches (1):
  hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead

Joe Stringer (1):
  netfilter: nf_conntrack: Support expectations in different zones

Joe Thornber (4):
  dm thin: allocate the cell_sort_array dynamically
  dm btree: silence lockdep lock inversion in dm_btree_del()
  dm btree: add 

Linux 3.4.111

[Zefan Li]

I'm announcing the release of the 3.4.111 kernel.

All users of the 3.4 kernel series must upgrade.

The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary





The following changes since commit 3edd6224c2a677bb59efe0b083a51fc2b3b5c64d:

  Linux 3.4.110 (2015-10-22 09:20:09 +0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lizf/linux-3.4.y.git 
tags/v3.4.111

for you to fetch changes up to 3389604d77540abf738b486d650c1745b2d663ca:

  Linux 3.4.111 (2016-03-21 09:17:59 +0800)


This is the 3.4.111 stable release


AMAN DEEP (1):
  usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() 
function

Al Viro (3):
  9p: don't leave a half-initialized inode sitting around
  sg_start_req(): make sure that there's not too many elements in iovec
  get rid of s_files and files_lock

Aleksei Mamlin (1):
  libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk 
VB0250EAVER

Alex Deucher (1):
  drm/radeon/combios: add some validation of lvds values

Alexei Potashnik (1):
  target/iscsi: Fix double free of a TUR followed by a solicited NOPOUT

Andrey Vagin (1):
  netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get

Andy Lutomirski (2):
  x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
  x86/ldt: Make modify_ldt synchronous

Anssi Hannula (1):
  ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly

Arne Fitzenreiter (2):
  libata: add ATA_HORKAGE_NOTRIM
  libata: force disable trim for SuperSSpeed S238

Bart Van Assche (1):
  libfc: Fix fc_fcp_cleanup_each_cmd()

Ben Hutchings (2):
  isdn_ppp: Add checks for allocation failure in isdn_ppp_open()
  ppp, slip: Validate VJ compression slot parameters completely

Ben Zhang (1):
  kernel/watchdog.c: touch_nmi_watchdog should only touch local cpu not 
every one

Bernhard Bender (1):
  Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen

Brian Campbell (1):
  xhci: Calculate old endpoints correctly on device reset

Chris Metcalf (1):
  tile: use free_bootmem_late() for initrd

Claudio Cappelli (1):
  USB: option: add 2020:4000 ID

Clemens Ladisch (2):
  ALSA: tlv: compute TLV_*_ITEM lengths automatically
  ALSA: tlv: add DECLARE_TLV_DB_RANGE()

Dan Carpenter (1):
  rds: fix an integer overflow test in rds_info_getsockopt()

Daniel Borkmann (1):
  rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver

David Ahern (1):
  net: Fix RCU splat in af_key

David Daney (1):
  MIPS: Make set_pte() SMP safe.

David Howells (2):
  KEYS: Fix race between key destruction and finding a keyring by name
  KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring

Dennis Yang (1):
  dm btree remove: fix bug in redistribute3

Dirk Behme (1):
  USB: sierra: add 1199:68AB device ID

Dominic Sacr茅 (1):
  ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4

Edward Hyunkoo Jee (1):
  inet: frags: fix defragmented packet's IP header for af_packet

Eric Northup (1):
  KVM: x86: work around infinite loop in microcode when #AC is delivered

Felix Fietkau (1):
  MIPS: Fix sched_getaffinity with MT FPAFF enabled

Filipe Manana (1):
  Btrfs: use kmem_cache_free when freeing entry in inode cache

Gioh Kim (1):
  fs/buffer.c: support buffer cache allocations with gfp modifiers

Hannes Frederic Sowa (3):
  net: add validation for the socket syscall protocol argument
  ipv6: probe routes asynchronous in rt6_probe
  net: fix warnings in 'make htmldocs' by moving macro definition out of 
field declaration

Heiko Carstens (1):
  s390/process: fix sfpc inline assembly

Herbert Xu (2):
  net: Clone skb before setting peeked flag
  crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer

Herton R. Krzesinski (1):
  ipc,sem: fix use after free on IPC_RMID after a task using same semaphore 
set exits

Jan Beulich (1):
  x86/LDT: Print the real LDT base address

Jason Wang (1):
  virtio-net: drop NETIF_F_FRAGLIST

Jiri Pirko (1):
  niu: don't count tx error twice in case of headroom realloc fails

Joe Perches (1):
  hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead

Joe Stringer (1):
  netfilter: nf_conntrack: Support expectations in different zones

Joe Thornber (4):
  dm thin: allocate the cell_sort_array dynamically
  dm btree: silence lockdep lock inversion in dm_btree_del()
  dm btree: add 

[lkp] [cpuidle] b67bb65b9d: No primary result change, -33.1% turbostat.%Busy

[kernel test robot]

  O  O   O |
 |  |
  12 ++-+


turbostat.CPU_c1

  66 ++-+
 O O|
  65 ++ O  O  O  O  O   O  O  O  O   O  O  O  O  O   O  O  O  O   O |
  64 ++ |
 |  |
  63 ++ |
  62 ++ |
 |  |
  61 ++ |
  60 ++ |
 |  |
  59 ++ |
  58 ++ |
 *..*..*...*..*..*..*...*..*..*..*...*..*..*..*..*...*..*..*..*...*..*..*
  57 ++-+


 turbostat.PkgWatt

  374 +++
  372 *+.*.. .*..*.. ..*..*..*..  .*..*...*..  .*
  | *...*..*..*..*..*..*...*.   *..*.   *.   *. |
  370 ++|
  368 ++|
  | |
  366 ++|
  364 ++|
  362 ++|
  | |
  360 ++|
  358 ++|
  O |
  356 ++ O  O   O  O  O  O  O  O   O O  O  O  OO  O |
  354 ++--OO-O--O-O-+



[*] bisect-good sample
[O] bisect-bad  sample

To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml  # job file is attached in this email
bin/lkp run job.yaml


Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.


Thanks,
Xiaolong Ye
---
LKP_SERVER: inn
LKP_CGI_PORT: 80
LKP_CIFS_PORT: 139
testcase: vm-scalability
default-monitors:
  wait: activate-monitor
  kmsg: 
  uptime: 
  iostat: 
  heartbeat: 
  vmstat: 
  numa-numastat: 
  numa-vmstat: 
  numa-meminfo: 
  proc-vmstat: 
  proc-stat:
interval: 10
  meminfo: 
  slabinfo: 
  interrupts: 
  lock_stat: 
  latency_stats: 
  softirqs: 
  bdi_dev_mapping: 
  diskstats: 
  nfsstat: 
  cpuidle: 
  cpufreq-stats: 
  turbostat: 
  pmeter: 
  sched_debug:
interval: 60
cpufreq_governor: performance
default-watchdogs:
  oom-killer: 
  watchdog: 
commit: b67bb65b9de2d3c070073028aeb30cca6c6790a7
model: Brickland Haswell-EX
nr_cpu: 120
memory: 512G
nr_ssd_partitions: 1
ssd_partitions: "/dev/nvme0n1p1"
swap_partitions: 
rootfs_partition: 
pmeter_server: lkp-st01
pmeter_device: yokogawa-wt310
category: benchmark
perf-profile: 
runtime: 300s
size: 1T
vm-scalability:
  test: msync-mt
queue: bisect
testbox: lkp-hsx04
tbox_group: lkp-hsx04
kconfig: x86_64-rhel
enqueue_time: 2016-03-21 11:41:09.815149567 +08:00
compiler: gcc-4.9
rootfs: debian-x86_64-2015-02-07.cgz
id: 002c8e1d3658e5cd8978ad0552ee7fe543f64af0
user: lkp
head_commit: cd1a8af09f25054f01c0f06dcd43d99a3196eb0c
base_commit: b562e44f507e863c6792946e4e1b1449fbbac85d
branch: linux-devel/devel-hourly-2016032015
result_root: 
"/result/vm-scalability/performance-300s-1T-msync-mt/lkp-hsx04/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/b67bb65b9de2d3c070073028aeb30cca6c6790a7/0"
job_file: 
"/lkp/scheduled/lkp-hsx04/bisect_vm-scalability-performance-300s-1T-msync-mt-debian-x86_64-2015-02-07.cgz-x86_64-rhel-b67bb65b9de2d3c070073028aeb30cca6c6790a7-20160321-79544-wxo1vq-0.yaml"
max_uptime: 1500
initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz"
bootloader_append:
- root=/dev/ram0
- user=lkp
- 
job=/lkp/scheduled/lkp-hsx04/bisect_

[lkp] [cpuidle] b67bb65b9d: No primary result change, -33.1% turbostat.%Busy

[kernel test robot]

  O  O   O |
 |  |
  12 ++-+


turbostat.CPU_c1

  66 ++-+
 O O|
  65 ++ O  O  O  O  O   O  O  O  O   O  O  O  O  O   O  O  O  O   O |
  64 ++ |
 |  |
  63 ++ |
  62 ++ |
 |  |
  61 ++ |
  60 ++ |
 |  |
  59 ++ |
  58 ++ |
 *..*..*...*..*..*..*...*..*..*..*...*..*..*..*..*...*..*..*..*...*..*..*
  57 ++-+


 turbostat.PkgWatt

  374 +++
  372 *+.*.. .*..*.. ..*..*..*..  .*..*...*..  .*
  | *...*..*..*..*..*..*...*.   *..*.   *.   *. |
  370 ++|
  368 ++|
  | |
  366 ++|
  364 ++|
  362 ++|
  | |
  360 ++|
  358 ++|
  O |
  356 ++ O  O   O  O  O  O  O  O   O O  O  O  OO  O |
  354 ++--OO-O--O-O-+



[*] bisect-good sample
[O] bisect-bad  sample

To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml  # job file is attached in this email
bin/lkp run job.yaml


Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.


Thanks,
Xiaolong Ye
---
LKP_SERVER: inn
LKP_CGI_PORT: 80
LKP_CIFS_PORT: 139
testcase: vm-scalability
default-monitors:
  wait: activate-monitor
  kmsg: 
  uptime: 
  iostat: 
  heartbeat: 
  vmstat: 
  numa-numastat: 
  numa-vmstat: 
  numa-meminfo: 
  proc-vmstat: 
  proc-stat:
interval: 10
  meminfo: 
  slabinfo: 
  interrupts: 
  lock_stat: 
  latency_stats: 
  softirqs: 
  bdi_dev_mapping: 
  diskstats: 
  nfsstat: 
  cpuidle: 
  cpufreq-stats: 
  turbostat: 
  pmeter: 
  sched_debug:
interval: 60
cpufreq_governor: performance
default-watchdogs:
  oom-killer: 
  watchdog: 
commit: b67bb65b9de2d3c070073028aeb30cca6c6790a7
model: Brickland Haswell-EX
nr_cpu: 120
memory: 512G
nr_ssd_partitions: 1
ssd_partitions: "/dev/nvme0n1p1"
swap_partitions: 
rootfs_partition: 
pmeter_server: lkp-st01
pmeter_device: yokogawa-wt310
category: benchmark
perf-profile: 
runtime: 300s
size: 1T
vm-scalability:
  test: msync-mt
queue: bisect
testbox: lkp-hsx04
tbox_group: lkp-hsx04
kconfig: x86_64-rhel
enqueue_time: 2016-03-21 11:41:09.815149567 +08:00
compiler: gcc-4.9
rootfs: debian-x86_64-2015-02-07.cgz
id: 002c8e1d3658e5cd8978ad0552ee7fe543f64af0
user: lkp
head_commit: cd1a8af09f25054f01c0f06dcd43d99a3196eb0c
base_commit: b562e44f507e863c6792946e4e1b1449fbbac85d
branch: linux-devel/devel-hourly-2016032015
result_root: 
"/result/vm-scalability/performance-300s-1T-msync-mt/lkp-hsx04/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/b67bb65b9de2d3c070073028aeb30cca6c6790a7/0"
job_file: 
"/lkp/scheduled/lkp-hsx04/bisect_vm-scalability-performance-300s-1T-msync-mt-debian-x86_64-2015-02-07.cgz-x86_64-rhel-b67bb65b9de2d3c070073028aeb30cca6c6790a7-20160321-79544-wxo1vq-0.yaml"
max_uptime: 1500
initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz"
bootloader_append:
- root=/dev/ram0
- user=lkp
- 
job=/lkp/scheduled/lkp-hsx04/bisect_

Re: [PATCH v2] net: add missing descriptions in net_device_priv_flags

[David Miller]

From: Luis de Bethencourt 
Date: Mon, 21 Mar 2016 20:58:28 +

> The flags IFF_XMIT_DST_RELEASE_PERM, IFF_IPVLAN_MASTER and
> IFF_IPVLAN_SLAVE are missing descriptions for the Documentation. Adding
> them.
> 
> Signed-off-by: Luis de Bethencourt 
> Suggested-by: Benjamin Poirier 

Applied.

Re: [PATCH v2] net: add missing descriptions in net_device_priv_flags

[David Miller]

From: Luis de Bethencourt 
Date: Mon, 21 Mar 2016 20:58:28 +

> The flags IFF_XMIT_DST_RELEASE_PERM, IFF_IPVLAN_MASTER and
> IFF_IPVLAN_SLAVE are missing descriptions for the Documentation. Adding
> them.
> 
> Signed-off-by: Luis de Bethencourt 
> Suggested-by: Benjamin Poirier 

Applied.

arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (240) for 'rur240'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   968f3e374faf41e5e6049399eb7302777a09a1e8
commit: 2c684d892bb2ee31cc48f4a8b91e86a0f15e82f9 xtensa: add Three Core HiFi-2 
MX Variant.
date:   4 days ago
config: xtensa-smp_lx200_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2c684d892bb2ee31cc48f4a8b91e86a0f15e82f9
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   arch/xtensa/kernel/coprocessor.S: Assembler messages:
>> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (240) 
>> for 'rur240'
>> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (241) 
>> for 'rur241'
>> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (242) 
>> for 'rur242'
>> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (243) 
>> for 'rur243'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sq56s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sq56s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sq56s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sq56s.i'
>> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (240) 
>> for 'wur240'
>> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (241) 
>> for 'wur241'
>> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (242) 
>> for 'wur242'
>> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (243) 
>> for 'wur243'
--
   arch/xtensa/include/asm/processor.h: Assembler messages:
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
--
   arch/xtensa/kernel/head.S: Assembler messages:
>> arch/xtensa/kernel/head.S:187: Error: unknown opcode or format name 'wer'
   arch/xtensa/kernel/head.S:317: Error: unknown opcode or format name 'wer'
--
   arch/xtensa/include/asm/processor.h: Assembler messages:
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'

vim +/rur240 +93 arch/xtensa/kernel/coprocessor.S

c658eac6 Chris Zankel 2008-02-12   87   .else;  
\
c658eac6 Chris Zankel 2008-02-12   88   .long 0;
\
c658eac6 Chris Zankel 2008-02-12   89   .endif; 
\
c658eac6 Chris Zankel 2008-02-12   90   .long THREAD_XTREGS_CP##x
5a0015d6 Chris Zankel 2005-06-23   91  
c658eac6 Chris Zankel 2008-02-12   92   SAVE_CP_REGS(0)
c658eac6 Chris Zankel 2008-02-12  @93   SAVE_CP_REGS(1)
c658eac6 Chris Zankel 2008-02-12   94   SAVE_CP_REGS(2)
c658eac6 Chris Zankel 2008-02-12   95   SAVE_CP_REGS(3)
c658eac6 Chris Zankel 2008-02-12   96   SAVE_CP_REGS(4)
c658eac6 Chris 

arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (240) for 'rur240'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   968f3e374faf41e5e6049399eb7302777a09a1e8
commit: 2c684d892bb2ee31cc48f4a8b91e86a0f15e82f9 xtensa: add Three Core HiFi-2 
MX Variant.
date:   4 days ago
config: xtensa-smp_lx200_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2c684d892bb2ee31cc48f4a8b91e86a0f15e82f9
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   arch/xtensa/kernel/coprocessor.S: Assembler messages:
>> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (240) 
>> for 'rur240'
>> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (241) 
>> for 'rur241'
>> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (242) 
>> for 'rur242'
>> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (243) 
>> for 'rur243'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sp24x2s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sq56s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sq56s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sq56s.i'
>> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name 
>> 'ae_sq56s.i'
>> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (240) 
>> for 'wur240'
>> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (241) 
>> for 'wur241'
>> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (242) 
>> for 'wur242'
>> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (243) 
>> for 'wur243'
--
   arch/xtensa/include/asm/processor.h: Assembler messages:
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
>> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format 
>> name 'rer'
--
   arch/xtensa/kernel/head.S: Assembler messages:
>> arch/xtensa/kernel/head.S:187: Error: unknown opcode or format name 'wer'
   arch/xtensa/kernel/head.S:317: Error: unknown opcode or format name 'wer'
--
   arch/xtensa/include/asm/processor.h: Assembler messages:
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'
>> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format 
>> name 'wer'

vim +/rur240 +93 arch/xtensa/kernel/coprocessor.S

c658eac6 Chris Zankel 2008-02-12   87   .else;  
\
c658eac6 Chris Zankel 2008-02-12   88   .long 0;
\
c658eac6 Chris Zankel 2008-02-12   89   .endif; 
\
c658eac6 Chris Zankel 2008-02-12   90   .long THREAD_XTREGS_CP##x
5a0015d6 Chris Zankel 2005-06-23   91  
c658eac6 Chris Zankel 2008-02-12   92   SAVE_CP_REGS(0)
c658eac6 Chris Zankel 2008-02-12  @93   SAVE_CP_REGS(1)
c658eac6 Chris Zankel 2008-02-12   94   SAVE_CP_REGS(2)
c658eac6 Chris Zankel 2008-02-12   95   SAVE_CP_REGS(3)
c658eac6 Chris Zankel 2008-02-12   96   SAVE_CP_REGS(4)
c658eac6 Chris 

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

[Shawn Lin]

+ Vinod

On 2016/3/22 10:33, Doug Anderson wrote:

Shawn,

On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin  wrote:

...but, looking at this, presumably before landing any patch that made
dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
_all_ users of dma_request_slave_channel to handle error pointers
being returned.  Right now dma_request_slave_channel() says it returns
a pointer to a channel or NULL and the function explicitly avoids
returning any errors.  That might be possible, but it's a big
change...



At first glance, it's a big change, but maybe not really.
Almost all of them use the templet like:
ch = dma_request_slave_channel
if (!ch)
 balabala

It's same for all the non-null return pointer/non-zero value ?

So from my view, we can safely change dma_request_slave_channel,
and leave the caller here. I presumably the respective
drivers will graduately migrate to check the return value with
EPROBE_DEFER if they do care this issue. Otherwise, we believe
they don't suffer the changes we make, just as what they did in the
past. Does that make sense?


...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
callers, then existing callers will think you've returned a valid
pointer when you really returned an error pointer.  They'll pass this
error pointer around like it's a valid "struct dma_chan", won't then?



possibly, it depends on how caller deal with it. Should check it case by
case for each caller.


Actually, could your code just call
dma_request_slave_channel_reason().  Oh, looks like that's exactly
what you want.  See commit 0ad7c00057dc ("dma: add channel request API
that supports deferred probe").  Oh, but I'm looking at 4.4.  Looking
at linuxnext, it looks like this got renamed to dma_request_chan().
...so you need to use that, no?

Strange, but on 4.4 there was some extra code in
dma_request_slave_channel() that wasn't in
dma_request_slave_channel_reason().  ...but looks like that all got
cleaned up in the same CL that added the new name.


dma_request_chan already return ERR_PTR(-EPROBE_DEFER), but
dma_request_slave_channel ignore this and rewrite it to be NULL.
Strange behaviour looks to me. commit 0ad7c00057dc ("dma: add channel
request API that supports deferred probe")  did the right thing, but
what happened then?  It was drop for some reasons?

Hello Vinod,

Could you please elaborate some more infomation to commit 0ad7c00057dc
("dma: add channel request API that supports deferred probe") :) ?




-Doug






--
Best Regards
Shawn Lin

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

[Shawn Lin]

+ Vinod

On 2016/3/22 10:33, Doug Anderson wrote:

Shawn,

On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin  wrote:

...but, looking at this, presumably before landing any patch that made
dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
_all_ users of dma_request_slave_channel to handle error pointers
being returned.  Right now dma_request_slave_channel() says it returns
a pointer to a channel or NULL and the function explicitly avoids
returning any errors.  That might be possible, but it's a big
change...



At first glance, it's a big change, but maybe not really.
Almost all of them use the templet like:
ch = dma_request_slave_channel
if (!ch)
 balabala

It's same for all the non-null return pointer/non-zero value ?

So from my view, we can safely change dma_request_slave_channel,
and leave the caller here. I presumably the respective
drivers will graduately migrate to check the return value with
EPROBE_DEFER if they do care this issue. Otherwise, we believe
they don't suffer the changes we make, just as what they did in the
past. Does that make sense?


...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
callers, then existing callers will think you've returned a valid
pointer when you really returned an error pointer.  They'll pass this
error pointer around like it's a valid "struct dma_chan", won't then?



possibly, it depends on how caller deal with it. Should check it case by
case for each caller.


Actually, could your code just call
dma_request_slave_channel_reason().  Oh, looks like that's exactly
what you want.  See commit 0ad7c00057dc ("dma: add channel request API
that supports deferred probe").  Oh, but I'm looking at 4.4.  Looking
at linuxnext, it looks like this got renamed to dma_request_chan().
...so you need to use that, no?

Strange, but on 4.4 there was some extra code in
dma_request_slave_channel() that wasn't in
dma_request_slave_channel_reason().  ...but looks like that all got
cleaned up in the same CL that added the new name.


dma_request_chan already return ERR_PTR(-EPROBE_DEFER), but
dma_request_slave_channel ignore this and rewrite it to be NULL.
Strange behaviour looks to me. commit 0ad7c00057dc ("dma: add channel
request API that supports deferred probe")  did the right thing, but
what happened then?  It was drop for some reasons?

Hello Vinod,

Could you please elaborate some more infomation to commit 0ad7c00057dc
("dma: add channel request API that supports deferred probe") :) ?




-Doug






--
Best Regards
Shawn Lin

Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update

[Viresh Kumar]

On 22-03-16, 01:17, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Modify dbs_irq_work() to always schedule the process-context work
> on the current CPU which also ran the dbs_update_util_handler()
> that the irq_work being handled came from.
> 
> This causes the entire frequency update handling (involving the
> "ondemand" or "conservative" governors) to be carried out by the
> CPU whose frequency is to be updated and reduces the overall amount
> of inter-CPU noise related to cpufreq.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_governor.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -245,7 +245,7 @@ static void dbs_irq_work(struct irq_work
>   struct policy_dbs_info *policy_dbs;
>  
>   policy_dbs = container_of(irq_work, struct policy_dbs_info, irq_work);
> - schedule_work(_dbs->work);
> + schedule_work_on(smp_processor_id(), _dbs->work);
>  }
>  
>  static void dbs_update_util_handler(struct update_util_data *data, u64 time,

queue_work() used to queue the work on local cpu by default, has that
changed now ?

-- 
viresh

Re: Nonterministic hang during bootconsole/console handover on ath79

[Peter Hurley]

On 03/21/2016 05:52 PM, Matthias Schiffer wrote:
> On 03/22/2016 12:08 AM, Greg KH wrote:
>> On Tue, Mar 22, 2016 at 12:02:57AM +0100, Matthias Schiffer wrote:
>>> Hi,
>>> we're experiencing weird nondeterministic hangs during bootconsole/console
>>> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
>>> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
>>> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
>>> QCA953x likewise.
>>
>> Can you try 4.4 or ideally, 4.5?  There's been a lot of console/tty
>> fixes/changes since the obsolete 3.18 kernel you are using...
>>
>> thanks,
>>
>> greg k-h
>>
> 
> With 4.4, I was not able to reproduce this hang, but I have no idea if this
> is caused by an actual bugfix, or just random timing changes hiding the
> bug.

Can you continue testing with 4.4.x and see if it eventually reproduces?


> I suspect the latter might be the case (as I wrote in my first mail,
> even minor differences in kernel images of the same version and the same
> config make the hang more or less probable.) I was not yet able to test
> 4.5, as OpenWrt is a hell of kernel patches...
> 
> On 3.18, I also tried other things like disabling the early console
> altogether, which also made the hang go away, but as even much smaller
> changes hid the bug, this doesn't really say much.

FWIW, printk() is not a small change; takes ~500us @ 115200


> 
> The basic code path during the console handover seems to be the same in
> 3.18 and 4.4, even though a few functions have been moved; the relevant
> part of the log looks the same:
> 
>> [0.756298] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
>> [0.766754] console [ttyS0] disabled
>> [0.790293] serial8250.0: ttyS0 at MMIO 0x1802 (irq = 11, base_baud = 
>> 1250) is a 16550A
>> [0.798909] console [ttyS0] enabled
>> [0.798909] console [ttyS0] enabled
>> [0.805854] bootconsole [early0] disabled
>> [0.805854] bootconsole [early0] disabled
> 
> So, in propect of an actual bugfix or backport, this boils down to two
> questions, which I hope the serial or MIPS maintainers can answer me:
> 
> * Is it sane to have two console drivers using the same serial port? In
> particular, is it sane for the early console to use the serial port after
> serial8250_config_port has reset/configured it, but before the rest of the
> setup of uart_configure_port has run? (this would be the case for the
> message "serial8250.0: ttyS0 at MMIO...")
> * Is it possible to get the serial controller into a state in which
> early_printk might wait for THRE forever?

I think I addressed these questions in my other reply; let me know if not.

Regards,
Peter Hurley

[lkp] [drm/i915] 97f9010af0: No primary result change, -36.2% piglit.time.percent_of_cpu_this_job_got

[kernel test robot]

FYI, we noticed that piglit.time.percent_of_cpu_this_job_got -36.2% change with 
your commit.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715 ("drm/i915: mdelay(10) 
considered harmful")


=
compiler/group/kconfig/rootfs/tbox_group/testcase:
  gcc-4.9/igt-037/x86_64-rhel/debian-x86_64-2015-02-07.cgz/snb-drag/piglit

commit: 
  57a2af6bbc7a4f1b145cc216c34476402836f0b8
  97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715

57a2af6bbc7a4f1b 97f9010af05c15e0b7e6b4ef6f 
 -- 
   fail:runs  %reproductionfail:runs
 %stddev %change %stddev
 \  |\  
 69.00 ±  0% -36.2%  44.00 ±  0%  
piglit.time.percent_of_cpu_this_job_got
 44.77 ±  0% -36.0%  28.66 ±  0%  piglit.time.system_time
 38337 ±  0%  +4.1%  39904 ±  0%  
piglit.time.voluntary_context_switches
 69.00 ±  0% -36.2%  44.00 ±  0%  time.percent_of_cpu_this_job_got
 44.77 ±  0% -36.0%  28.66 ±  0%  time.system_time


snb-drag: Sandy Bridge
Memory: 6G



 piglit.time.system_time

  46 ++-+
 *..*..*..*..*..*..*..*..*..*..*..*..*.*..*..*..*..*..*..*..*..*..* |
  44 ++ |
  42 ++ |
 |  |
  40 ++ |
  38 ++ |
 |  |
  36 ++ |
  34 ++ |
 |  |
  32 ++ |
  30 ++ |
 O  O  O  O  O  O  O  O  O  O  O  O  O O  O  O  O  O  O  O  O  O  O  O  O
  28 ++-+


 piglit.time.percent_of_cpu_this_job_got

  70 *+*--*--*--*--*--*--*--*--*--*--*-*--*--*--*--*--*--*--*--*--*-+
 |   .. |
  65 ++ *   |
  60 ++ |
 |  |
  55 ++ |
  50 ++ |
 |  |
  45 ++O  O  O  O
  40 ++ |
 |O  O O  O  O  O  O  O  O  O   |
  35 ++ |
  30 ++ |
 |  |
  25 O+-O--O--O--O--O--O--O--O--O--O+


   piglit.time.voluntary_context_switches

  46000 ++--+
O  O  O  O O  O  O  O  O  O O   |
  45000 ++  |
  44000 ++  |
|   |
  43000 ++  |
|   |
  42000 ++  |
|   |
  41000 ++ O  O  O  O  O O  O  O  O  O  |
  4 ++  |
|   O O  O  O
  39000 ++  |
*..*..*..*.*..*..*..*..*..*.*..*..*..*..*..*.*..*..*..*..*..*.* |
  38000 ++--+


[*] bisect-good sample
[O] bisect-bad  sample

To reproduce:

Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update

[Viresh Kumar]

On 22-03-16, 01:17, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Modify dbs_irq_work() to always schedule the process-context work
> on the current CPU which also ran the dbs_update_util_handler()
> that the irq_work being handled came from.
> 
> This causes the entire frequency update handling (involving the
> "ondemand" or "conservative" governors) to be carried out by the
> CPU whose frequency is to be updated and reduces the overall amount
> of inter-CPU noise related to cpufreq.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_governor.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -245,7 +245,7 @@ static void dbs_irq_work(struct irq_work
>   struct policy_dbs_info *policy_dbs;
>  
>   policy_dbs = container_of(irq_work, struct policy_dbs_info, irq_work);
> - schedule_work(_dbs->work);
> + schedule_work_on(smp_processor_id(), _dbs->work);
>  }
>  
>  static void dbs_update_util_handler(struct update_util_data *data, u64 time,

queue_work() used to queue the work on local cpu by default, has that
changed now ?

-- 
viresh

Re: Nonterministic hang during bootconsole/console handover on ath79

[Peter Hurley]

On 03/21/2016 05:52 PM, Matthias Schiffer wrote:
> On 03/22/2016 12:08 AM, Greg KH wrote:
>> On Tue, Mar 22, 2016 at 12:02:57AM +0100, Matthias Schiffer wrote:
>>> Hi,
>>> we're experiencing weird nondeterministic hangs during bootconsole/console
>>> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
>>> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
>>> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
>>> QCA953x likewise.
>>
>> Can you try 4.4 or ideally, 4.5?  There's been a lot of console/tty
>> fixes/changes since the obsolete 3.18 kernel you are using...
>>
>> thanks,
>>
>> greg k-h
>>
> 
> With 4.4, I was not able to reproduce this hang, but I have no idea if this
> is caused by an actual bugfix, or just random timing changes hiding the
> bug.

Can you continue testing with 4.4.x and see if it eventually reproduces?


> I suspect the latter might be the case (as I wrote in my first mail,
> even minor differences in kernel images of the same version and the same
> config make the hang more or less probable.) I was not yet able to test
> 4.5, as OpenWrt is a hell of kernel patches...
> 
> On 3.18, I also tried other things like disabling the early console
> altogether, which also made the hang go away, but as even much smaller
> changes hid the bug, this doesn't really say much.

FWIW, printk() is not a small change; takes ~500us @ 115200


> 
> The basic code path during the console handover seems to be the same in
> 3.18 and 4.4, even though a few functions have been moved; the relevant
> part of the log looks the same:
> 
>> [0.756298] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
>> [0.766754] console [ttyS0] disabled
>> [0.790293] serial8250.0: ttyS0 at MMIO 0x1802 (irq = 11, base_baud = 
>> 1250) is a 16550A
>> [0.798909] console [ttyS0] enabled
>> [0.798909] console [ttyS0] enabled
>> [0.805854] bootconsole [early0] disabled
>> [0.805854] bootconsole [early0] disabled
> 
> So, in propect of an actual bugfix or backport, this boils down to two
> questions, which I hope the serial or MIPS maintainers can answer me:
> 
> * Is it sane to have two console drivers using the same serial port? In
> particular, is it sane for the early console to use the serial port after
> serial8250_config_port has reset/configured it, but before the rest of the
> setup of uart_configure_port has run? (this would be the case for the
> message "serial8250.0: ttyS0 at MMIO...")
> * Is it possible to get the serial controller into a state in which
> early_printk might wait for THRE forever?

I think I addressed these questions in my other reply; let me know if not.

Regards,
Peter Hurley

[lkp] [drm/i915] 97f9010af0: No primary result change, -36.2% piglit.time.percent_of_cpu_this_job_got

[kernel test robot]

FYI, we noticed that piglit.time.percent_of_cpu_this_job_got -36.2% change with 
your commit.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715 ("drm/i915: mdelay(10) 
considered harmful")


=
compiler/group/kconfig/rootfs/tbox_group/testcase:
  gcc-4.9/igt-037/x86_64-rhel/debian-x86_64-2015-02-07.cgz/snb-drag/piglit

commit: 
  57a2af6bbc7a4f1b145cc216c34476402836f0b8
  97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715

57a2af6bbc7a4f1b 97f9010af05c15e0b7e6b4ef6f 
 -- 
   fail:runs  %reproductionfail:runs
 %stddev %change %stddev
 \  |\  
 69.00 ±  0% -36.2%  44.00 ±  0%  
piglit.time.percent_of_cpu_this_job_got
 44.77 ±  0% -36.0%  28.66 ±  0%  piglit.time.system_time
 38337 ±  0%  +4.1%  39904 ±  0%  
piglit.time.voluntary_context_switches
 69.00 ±  0% -36.2%  44.00 ±  0%  time.percent_of_cpu_this_job_got
 44.77 ±  0% -36.0%  28.66 ±  0%  time.system_time


snb-drag: Sandy Bridge
Memory: 6G



 piglit.time.system_time

  46 ++-+
 *..*..*..*..*..*..*..*..*..*..*..*..*.*..*..*..*..*..*..*..*..*..* |
  44 ++ |
  42 ++ |
 |  |
  40 ++ |
  38 ++ |
 |  |
  36 ++ |
  34 ++ |
 |  |
  32 ++ |
  30 ++ |
 O  O  O  O  O  O  O  O  O  O  O  O  O O  O  O  O  O  O  O  O  O  O  O  O
  28 ++-+


 piglit.time.percent_of_cpu_this_job_got

  70 *+*--*--*--*--*--*--*--*--*--*--*-*--*--*--*--*--*--*--*--*--*-+
 |   .. |
  65 ++ *   |
  60 ++ |
 |  |
  55 ++ |
  50 ++ |
 |  |
  45 ++O  O  O  O
  40 ++ |
 |O  O O  O  O  O  O  O  O  O   |
  35 ++ |
  30 ++ |
 |  |
  25 O+-O--O--O--O--O--O--O--O--O--O+


   piglit.time.voluntary_context_switches

  46000 ++--+
O  O  O  O O  O  O  O  O  O O   |
  45000 ++  |
  44000 ++  |
|   |
  43000 ++  |
|   |
  42000 ++  |
|   |
  41000 ++ O  O  O  O  O O  O  O  O  O  |
  4 ++  |
|   O O  O  O
  39000 ++  |
*..*..*..*.*..*..*..*..*..*.*..*..*..*..*..*.*..*..*..*..*..*.* |
  38000 ++--+


[*] bisect-good sample
[O] bisect-bad  sample

To reproduce:

Re: [PATCH v11] cpufreq: powernv: Add sysfs attributes to show throttle stats

[Viresh Kumar]

On 21-03-16, 22:29, Shilpasri G Bhat wrote:
> + create_throttle_sysfs = kcalloc(cpu_nr_cores(), sizeof(bool),
> + GFP_KERNEL);
> + if (!create_throttle_sysfs) {
> + kfree(chips);
> + return -ENOMEM;
> + }
> +
>   for (i = 0; i < nr_chips; i++) {
>   chips[i].id = chip[i];
>   cpumask_copy([i].mask, cpumask_of_node(chip[i]));
> @@ -582,6 +655,7 @@ static int init_chip_info(void)
>  
>  static inline void clean_chip_info(void)
>  {
> + kfree(create_throttle_sysfs);
>   kfree(chips);
>  }

Why do you need this at all?. You can use policy->driver data, isn't
it ?

-- 
viresh

Re: [PATCH v11] cpufreq: powernv: Add sysfs attributes to show throttle stats

[Viresh Kumar]

On 21-03-16, 22:29, Shilpasri G Bhat wrote:
> + create_throttle_sysfs = kcalloc(cpu_nr_cores(), sizeof(bool),
> + GFP_KERNEL);
> + if (!create_throttle_sysfs) {
> + kfree(chips);
> + return -ENOMEM;
> + }
> +
>   for (i = 0; i < nr_chips; i++) {
>   chips[i].id = chip[i];
>   cpumask_copy([i].mask, cpumask_of_node(chip[i]));
> @@ -582,6 +655,7 @@ static int init_chip_info(void)
>  
>  static inline void clean_chip_info(void)
>  {
> + kfree(create_throttle_sysfs);
>   kfree(chips);
>  }

Why do you need this at all?. You can use policy->driver data, isn't
it ?

-- 
viresh

Re: Nonterministic hang during bootconsole/console handover on ath79

[Peter Hurley]

Hi Matthias,

On 03/21/2016 04:02 PM, Matthias Schiffer wrote:
> Hi,
> we're experiencing weird nondeterministic hangs during bootconsole/console
> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
> QCA953x likewise.
> 
> See the log below for the exact place it hangs; the log was taken in during
> a good boot; a bad boot will just hang forever at the marked location. The
> issue is extremely hard to debug, as changing the timing in any way (like
> adding additional printk) will usually make it work without problems. (Even
> recompiling the kernel with the same config, but different uname timestamp
> will make the occurence more or less likely)
> 
> My theory is the following:
> 
> As soon as ttyS0 is detected and installed as the console, there are two
> console drivers active on the serial port at the same time: early0 and
> ttyS0. I suspect that the hang occurs when the primitive early0
> implementation prom_putchar_ar71xx waits indefinitely on THRE, but the real
> driver has just reset the serial controller in a way that makes THRE never
> come.

Doubtful.

console writes are performed with ints disabled, as is the 8250 driver's
autoconfig probing. Since this is a UP platform, as long as you're not
using the DEBUG_AUTOCONF switch in the 8250 driver, I don't think there's
a way for the boot console to be outputting while the 8250 driver is
configuring.

> When the boot is successful, I also sometimes see just garbage
> instead of the message "serial8250.0: ttyS0 at MMIO 0x1802...", which
> supports my idea that the kernel is trying to use the serial console while
> it is not correctly setup.
> 
> Is is possible that the first "console [ttyS0] disabled" message caused by
> the call chain
> 
>   serial8250_register_8250_port
>   uart_remove_one_port
>   unregister_console
> 
> should rather unregister early0 (as ttyS0 is not even registered at this
> point), so having both drivers active at the same time is avoided?

No.

Having both consoles active briefly at the handover is not really a problem;
all consoles are serialized with each other. Only one console can be outputting
at any one time.

The unregister_console() producing the bogus "ttyS0 disabled" message
is wrong but harmless.

That part happens because the 8250 driver creates phantom ports which are
unregistered as new ports are probed, but the ttyS0 console hadn't actually
been registered yet.


> Does this make any sense? Or do you have any other idea what might cause this?

I wonder if autoconfig probing (that's what discovers the uart port type)
is broken.

You could test this hypothesis by setting the port type directly and
set UPF_FIXED_TYPE; ie., in arch/mips/ath79/dev-common.c

diff --git a/arch/mips/ath79/dev-common.c b/arch/mips/ath79/dev-common.c
index 516225d..3814a42 100644
--- a/arch/mips/ath79/dev-common.c
+++ b/arch/mips/ath79/dev-common.c
@@ -36,7 +36,8 @@ static struct plat_serial8250_port ath79_uart_data[] = {
{
.mapbase= AR71XX_UART_BASE,
.irq= ATH79_MISC_IRQ(3),
-   .flags  = AR71XX_UART_FLAGS,
+   .flags  = AR71XX_UART_FLAGS | UPF_FIXED_TYPE,
+   .type   = PORT_16550A,
.iotype = UPIO_MEM32,
.regshift   = 2,
}, {


Regards,
Peter Hurley

> Thanks in advance,
> Matthias
> 
> 
> [1] https://dev.openwrt.org/ticket/21773
> [2] https://dev.openwrt.org/ticket/21857
> 
> 
>> [0.00] Linux version 3.18.27 (neoraider@avalon) (gcc version 4.8.3 
>> (OpenWrt/Linaro GCC 4.8-2014.04 r47335) ) #6 Sun Mar 20 22:40:15 CET 2016
>> [0.00] bootconsole [early0] enabled
>> [0.00] CPU0 revision is: 00019374 (MIPS 24Kc)
>> [0.00] SoC: Atheros AR7241 rev 1
>> [0.00] Determined physical RAM map:
>> [0.00]  memory: 0200 @  (usable)
>> [0.00] Initrd not found or empty - disabling initrd
>> [0.00] Zone ranges:
>> [0.00]   Normal   [mem 0x-0x01ff]
>> [0.00] Movable zone start for each node
>> [0.00] Early memory node ranges
>> [0.00]   node   0: [mem 0x-0x01ff]
>> [0.00] Initmem setup node 0 [mem 0x-0x01ff]
>> [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 
>> bytes.
>> [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 
>> 32 bytes
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
>> pages: 8128
>> [0.00] Kernel command line:  board=TL-WR841N-v7 console=ttyS0,115200 
>> rootfstype=squashfs,jffs2 noinitrd
>> [0.00] PID hash table entries: 128 (order: -3, 512 bytes)
>> [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
>> [0.00] 

Re: Nonterministic hang during bootconsole/console handover on ath79

[Peter Hurley]

Hi Matthias,

On 03/21/2016 04:02 PM, Matthias Schiffer wrote:
> Hi,
> we're experiencing weird nondeterministic hangs during bootconsole/console
> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
> QCA953x likewise.
> 
> See the log below for the exact place it hangs; the log was taken in during
> a good boot; a bad boot will just hang forever at the marked location. The
> issue is extremely hard to debug, as changing the timing in any way (like
> adding additional printk) will usually make it work without problems. (Even
> recompiling the kernel with the same config, but different uname timestamp
> will make the occurence more or less likely)
> 
> My theory is the following:
> 
> As soon as ttyS0 is detected and installed as the console, there are two
> console drivers active on the serial port at the same time: early0 and
> ttyS0. I suspect that the hang occurs when the primitive early0
> implementation prom_putchar_ar71xx waits indefinitely on THRE, but the real
> driver has just reset the serial controller in a way that makes THRE never
> come.

Doubtful.

console writes are performed with ints disabled, as is the 8250 driver's
autoconfig probing. Since this is a UP platform, as long as you're not
using the DEBUG_AUTOCONF switch in the 8250 driver, I don't think there's
a way for the boot console to be outputting while the 8250 driver is
configuring.

> When the boot is successful, I also sometimes see just garbage
> instead of the message "serial8250.0: ttyS0 at MMIO 0x1802...", which
> supports my idea that the kernel is trying to use the serial console while
> it is not correctly setup.
> 
> Is is possible that the first "console [ttyS0] disabled" message caused by
> the call chain
> 
>   serial8250_register_8250_port
>   uart_remove_one_port
>   unregister_console
> 
> should rather unregister early0 (as ttyS0 is not even registered at this
> point), so having both drivers active at the same time is avoided?

No.

Having both consoles active briefly at the handover is not really a problem;
all consoles are serialized with each other. Only one console can be outputting
at any one time.

The unregister_console() producing the bogus "ttyS0 disabled" message
is wrong but harmless.

That part happens because the 8250 driver creates phantom ports which are
unregistered as new ports are probed, but the ttyS0 console hadn't actually
been registered yet.


> Does this make any sense? Or do you have any other idea what might cause this?

I wonder if autoconfig probing (that's what discovers the uart port type)
is broken.

You could test this hypothesis by setting the port type directly and
set UPF_FIXED_TYPE; ie., in arch/mips/ath79/dev-common.c

diff --git a/arch/mips/ath79/dev-common.c b/arch/mips/ath79/dev-common.c
index 516225d..3814a42 100644
--- a/arch/mips/ath79/dev-common.c
+++ b/arch/mips/ath79/dev-common.c
@@ -36,7 +36,8 @@ static struct plat_serial8250_port ath79_uart_data[] = {
{
.mapbase= AR71XX_UART_BASE,
.irq= ATH79_MISC_IRQ(3),
-   .flags  = AR71XX_UART_FLAGS,
+   .flags  = AR71XX_UART_FLAGS | UPF_FIXED_TYPE,
+   .type   = PORT_16550A,
.iotype = UPIO_MEM32,
.regshift   = 2,
}, {


Regards,
Peter Hurley

> Thanks in advance,
> Matthias
> 
> 
> [1] https://dev.openwrt.org/ticket/21773
> [2] https://dev.openwrt.org/ticket/21857
> 
> 
>> [0.00] Linux version 3.18.27 (neoraider@avalon) (gcc version 4.8.3 
>> (OpenWrt/Linaro GCC 4.8-2014.04 r47335) ) #6 Sun Mar 20 22:40:15 CET 2016
>> [0.00] bootconsole [early0] enabled
>> [0.00] CPU0 revision is: 00019374 (MIPS 24Kc)
>> [0.00] SoC: Atheros AR7241 rev 1
>> [0.00] Determined physical RAM map:
>> [0.00]  memory: 0200 @  (usable)
>> [0.00] Initrd not found or empty - disabling initrd
>> [0.00] Zone ranges:
>> [0.00]   Normal   [mem 0x-0x01ff]
>> [0.00] Movable zone start for each node
>> [0.00] Early memory node ranges
>> [0.00]   node   0: [mem 0x-0x01ff]
>> [0.00] Initmem setup node 0 [mem 0x-0x01ff]
>> [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 
>> bytes.
>> [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 
>> 32 bytes
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
>> pages: 8128
>> [0.00] Kernel command line:  board=TL-WR841N-v7 console=ttyS0,115200 
>> rootfstype=squashfs,jffs2 noinitrd
>> [0.00] PID hash table entries: 128 (order: -3, 512 bytes)
>> [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
>> [0.00] 

Re: [GIT PULL] Btrfs

[Linus Torvalds]

On Mon, Mar 21, 2016 at 7:24 PM, Chris Mason  wrote:
>
> Hmmm, rereading my answer I realized I didn't actually answer.  I really
> think this is fixed.  I left the warning only because I originally
> expected something much more exotic.

Ok. It's more that you said the top commit fixes a problem, and the
only case where the top commit makes a difference it will also do that
WARN_ON_ONCE.

But it's pulled, test-built, and pushed out now.

  Linus

Re: [GIT PULL] Btrfs

[Linus Torvalds]

On Mon, Mar 21, 2016 at 7:24 PM, Chris Mason  wrote:
>
> Hmmm, rereading my answer I realized I didn't actually answer.  I really
> think this is fixed.  I left the warning only because I originally
> expected something much more exotic.

Ok. It's more that you said the top commit fixes a problem, and the
only case where the top commit makes a difference it will also do that
WARN_ON_ONCE.

But it's pulled, test-built, and pushed out now.

  Linus

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

[Doug Anderson]

Shawn,

On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin  wrote:
>> ...but, looking at this, presumably before landing any patch that made
>> dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
>> _all_ users of dma_request_slave_channel to handle error pointers
>> being returned.  Right now dma_request_slave_channel() says it returns
>> a pointer to a channel or NULL and the function explicitly avoids
>> returning any errors.  That might be possible, but it's a big
>> change...
>
>
> At first glance, it's a big change, but maybe not really.
> Almost all of them use the templet like:
> ch = dma_request_slave_channel
> if (!ch)
> balabala
>
> It's same for all the non-null return pointer/non-zero value ?
>
> So from my view, we can safely change dma_request_slave_channel,
> and leave the caller here. I presumably the respective
> drivers will graduately migrate to check the return value with
> EPROBE_DEFER if they do care this issue. Otherwise, we believe
> they don't suffer the changes we make, just as what they did in the
> past. Does that make sense?

...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
callers, then existing callers will think you've returned a valid
pointer when you really returned an error pointer.  They'll pass this
error pointer around like it's a valid "struct dma_chan", won't then?

Actually, could your code just call
dma_request_slave_channel_reason().  Oh, looks like that's exactly
what you want.  See commit 0ad7c00057dc ("dma: add channel request API
that supports deferred probe").  Oh, but I'm looking at 4.4.  Looking
at linuxnext, it looks like this got renamed to dma_request_chan().
...so you need to use that, no?

Strange, but on 4.4 there was some extra code in
dma_request_slave_channel() that wasn't in
dma_request_slave_channel_reason().  ...but looks like that all got
cleaned up in the same CL that added the new name.


-Doug

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

[Doug Anderson]

Shawn,

On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin  wrote:
>> ...but, looking at this, presumably before landing any patch that made
>> dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
>> _all_ users of dma_request_slave_channel to handle error pointers
>> being returned.  Right now dma_request_slave_channel() says it returns
>> a pointer to a channel or NULL and the function explicitly avoids
>> returning any errors.  That might be possible, but it's a big
>> change...
>
>
> At first glance, it's a big change, but maybe not really.
> Almost all of them use the templet like:
> ch = dma_request_slave_channel
> if (!ch)
> balabala
>
> It's same for all the non-null return pointer/non-zero value ?
>
> So from my view, we can safely change dma_request_slave_channel,
> and leave the caller here. I presumably the respective
> drivers will graduately migrate to check the return value with
> EPROBE_DEFER if they do care this issue. Otherwise, we believe
> they don't suffer the changes we make, just as what they did in the
> past. Does that make sense?

...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
callers, then existing callers will think you've returned a valid
pointer when you really returned an error pointer.  They'll pass this
error pointer around like it's a valid "struct dma_chan", won't then?

Actually, could your code just call
dma_request_slave_channel_reason().  Oh, looks like that's exactly
what you want.  See commit 0ad7c00057dc ("dma: add channel request API
that supports deferred probe").  Oh, but I'm looking at 4.4.  Looking
at linuxnext, it looks like this got renamed to dma_request_chan().
...so you need to use that, no?

Strange, but on 4.4 there was some extra code in
dma_request_slave_channel() that wasn't in
dma_request_slave_channel_reason().  ...but looks like that all got
cleaned up in the same CL that added the new name.


-Doug

Re: [PATCH v6 1/4] lib/percpu-list: Per-cpu list with associated per-cpu locks

[Waiman Long]

On 03/21/2016 05:49 AM, Jan Kara wrote:

On Fri 18-03-16 15:44:01, Waiman Long wrote:

+static __always_inline bool
+__pcpu_list_next_cpu(struct pcpu_list_head *head, struct pcpu_list_state 
*state)
+{
+   if (state->lock)
+   spin_unlock(state->lock);
+next_cpu:
+   /*
+* for_each_possible_cpu(cpu)
+*/
+   state->cpu = cpumask_next(state->cpu, cpu_possible_mask);
+   if (state->cpu>= nr_cpu_ids)
+   return false;   /* All the per-cpu lists iterated */
+
+   state->head =_cpu_ptr(head, state->cpu)->list;
+   if (list_empty(state->head))
+   goto next_cpu;
+
+   state->lock =_cpu_ptr(head, state->cpu)->lock;
+   spin_lock(state->lock);
+   state->curr = list_entry(state->head->next,
+struct pcpu_list_node, list);
+   return true;

Waiman, I repeat it for the third time as you keep ignoring it: This is
*racy*. The list for state->cpu can be empty by the time you acquire
state->lock and thus state->curr will point somewhere around the head of
the list but definitely not to a list member where it should.

Honza


I am sorry for missing your previous comment. Yes, it is possible that 
the list is empty after the lock. So I should have checked for that 
before returning. Thanks for reminding me that. I will fix that later on.


Cheers,
Longman

Re: [PATCH v6 1/4] lib/percpu-list: Per-cpu list with associated per-cpu locks

[Waiman Long]

On 03/21/2016 05:49 AM, Jan Kara wrote:

On Fri 18-03-16 15:44:01, Waiman Long wrote:

+static __always_inline bool
+__pcpu_list_next_cpu(struct pcpu_list_head *head, struct pcpu_list_state 
*state)
+{
+   if (state->lock)
+   spin_unlock(state->lock);
+next_cpu:
+   /*
+* for_each_possible_cpu(cpu)
+*/
+   state->cpu = cpumask_next(state->cpu, cpu_possible_mask);
+   if (state->cpu>= nr_cpu_ids)
+   return false;   /* All the per-cpu lists iterated */
+
+   state->head =_cpu_ptr(head, state->cpu)->list;
+   if (list_empty(state->head))
+   goto next_cpu;
+
+   state->lock =_cpu_ptr(head, state->cpu)->lock;
+   spin_lock(state->lock);
+   state->curr = list_entry(state->head->next,
+struct pcpu_list_node, list);
+   return true;

Waiman, I repeat it for the third time as you keep ignoring it: This is
*racy*. The list for state->cpu can be empty by the time you acquire
state->lock and thus state->curr will point somewhere around the head of
the list but definitely not to a list member where it should.

Honza


I am sorry for missing your previous comment. Yes, it is possible that 
the list is empty after the lock. So I should have checked for that 
before returning. Thanks for reminding me that. I will fix that later on.


Cheers,
Longman

Re: [PATCH] staging: rts5208: coding style clean-ups

[Greg KH]

On Tue, Mar 22, 2016 at 07:45:25AM +0530, Sohom Bhattacharjee wrote:
> On Mon, Mar 21, 2016 at 05:29:24PM -0400, Greg KH wrote:
> > On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote:
> > > fixed *only* comments that did not follow kernel coding style.
> > > the errors were caught by the checkpatch.pl tool
> > > 
> > > Signed-off-by: Sohom Bhattacharjee 
> > 
> > Does not apply to the tree at all :(
> what do you mean ? 
> i used the Linus's latest git tree. :)

That's usually quite a bit behind the current development tree.  Always
use linux-next to work against, you can miss almost 3 months of
development effort at times.

thanks,

greg k-h

Re: [PATCH] staging: rts5208: coding style clean-ups

[Greg KH]

On Tue, Mar 22, 2016 at 07:45:25AM +0530, Sohom Bhattacharjee wrote:
> On Mon, Mar 21, 2016 at 05:29:24PM -0400, Greg KH wrote:
> > On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote:
> > > fixed *only* comments that did not follow kernel coding style.
> > > the errors were caught by the checkpatch.pl tool
> > > 
> > > Signed-off-by: Sohom Bhattacharjee 
> > 
> > Does not apply to the tree at all :(
> what do you mean ? 
> i used the Linus's latest git tree. :)

That's usually quite a bit behind the current development tree.  Always
use linux-next to work against, you can miss almost 3 months of
development effort at times.

thanks,

greg k-h

Re: [GIT PULL] Btrfs

[Chris Mason]

On Mon, Mar 21, 2016 at 10:15:33PM -0400, Chris Mason wrote:
> On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote:
> > On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason  wrote:
> > >
> > > I waited an extra day to send this one out because I hit a crash late
> > > last week with CONFIG_DEBUG_PAGEALLOC enabled (fixed in the top commit).
> > 
> > Hmm. If that commit helps, it will spit out a warning.
> > 
> > So is it actually fixed, or just hacked around to the point where you
> > don't get a page fault?

Hmmm, rereading my answer I realized I didn't actually answer.  I really
think this is fixed.  I left the warning only because I originally
expected something much more exotic.

-chris

Re: [GIT PULL] Btrfs

[Chris Mason]

On Mon, Mar 21, 2016 at 10:15:33PM -0400, Chris Mason wrote:
> On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote:
> > On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason  wrote:
> > >
> > > I waited an extra day to send this one out because I hit a crash late
> > > last week with CONFIG_DEBUG_PAGEALLOC enabled (fixed in the top commit).
> > 
> > Hmm. If that commit helps, it will spit out a warning.
> > 
> > So is it actually fixed, or just hacked around to the point where you
> > don't get a page fault?

Hmmm, rereading my answer I realized I didn't actually answer.  I really
think this is fixed.  I left the warning only because I originally
expected something much more exotic.

-chris

Re: [PATCH] zsmalloc: fix semicolon.cocci warnings

[Minchan Kim]

On Mon, Mar 21, 2016 at 05:48:25PM +0800, kbuild test robot wrote:
> mm/zsmalloc.c:1103:2-3: Unneeded semicolon
> 
> 
>  Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> CC: Minchan Kim 
> Signed-off-by: Fengguang Wu 
> ---
> 
>  zsmalloc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1100,7 +1100,7 @@ void unlock_zspage(struct page *first_pa
>   VM_BUG_ON_PAGE(!PageLocked(cursor), cursor);
>   if (cursor != locked_page)
>   unlock_page(cursor);
> - };
> + }
>  }
>  
>  static void free_zspage(struct zs_pool *pool, struct page *first_page)

Thanks.
Fixed.


>From bb46f8265b55228f31b8096bd1c13dd6e6ee1bc4 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Wed, 9 Mar 2016 09:37:57 +0900
Subject: [PATCH] zsmalloc: migrate tail pages in zspage

This patch enables tail page migration of zspage.

In this point, I tested zsmalloc regression with micro-benchmark
which does zs_malloc/map/unmap/zs_free for all size class
in every CPU(my system is 12) during 20 sec.

It shows 1% regression which is really small when we consider
the benefit of this feature and realworkload overhead(i.e.,
most overhead comes from compression).

Signed-off-by: Minchan Kim 
---
 mm/zsmalloc.c | 131 +++---
 1 file changed, 115 insertions(+), 16 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9b4b03d8f993..3f1d488633e1 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -551,6 +551,19 @@ static void set_zspage_mapping(struct page *first_page,
m->class = class_idx;
 }
 
+static bool check_isolated_page(struct page *first_page)
+{
+   struct page *cursor;
+
+   for (cursor = first_page; cursor != NULL; cursor =
+   get_next_page(cursor)) {
+   if (PageIsolated(cursor))
+   return true;
+   }
+
+   return false;
+}
+
 /*
  * zsmalloc divides the pool into various size classes where each
  * class maintains a list of zspages where each zspage is divided
@@ -1052,6 +1065,44 @@ void lock_zspage(struct page *first_page)
} while ((cursor = get_next_page(cursor)) != NULL);
 }
 
+int trylock_zspage(struct page *first_page, struct page *locked_page)
+{
+   struct page *cursor, *fail;
+
+   VM_BUG_ON_PAGE(!is_first_page(first_page), first_page);
+
+   for (cursor = first_page; cursor != NULL; cursor =
+   get_next_page(cursor)) {
+   if (cursor != locked_page) {
+   if (!trylock_page(cursor)) {
+   fail = cursor;
+   goto unlock;
+   }
+   }
+   }
+
+   return 1;
+unlock:
+   for (cursor = first_page; cursor != fail; cursor =
+   get_next_page(cursor)) {
+   if (cursor != locked_page)
+   unlock_page(cursor);
+   }
+
+   return 0;
+}
+
+void unlock_zspage(struct page *first_page, struct page *locked_page)
+{
+   struct page *cursor = first_page;
+
+   for (; cursor != NULL; cursor = get_next_page(cursor)) {
+   VM_BUG_ON_PAGE(!PageLocked(cursor), cursor);
+   if (cursor != locked_page)
+   unlock_page(cursor);
+   }
+}
+
 static void free_zspage(struct zs_pool *pool, struct page *first_page)
 {
struct page *nextp, *tmp;
@@ -1090,16 +1141,17 @@ static void init_zspage(struct size_class *class, 
struct page *first_page,
first_page->freelist = NULL;
INIT_LIST_HEAD(_page->lru);
set_zspage_inuse(first_page, 0);
-   BUG_ON(!trylock_page(first_page));
-   first_page->mapping = mapping;
-   __SetPageMovable(first_page);
-   unlock_page(first_page);
 
while (page) {
struct page *next_page;
struct link_free *link;
void *vaddr;
 
+   BUG_ON(!trylock_page(page));
+   page->mapping = mapping;
+   __SetPageMovable(page);
+   unlock_page(page);
+
vaddr = kmap_atomic(page);
link = (struct link_free *)vaddr + off / sizeof(*link);
 
@@ -1850,6 +1902,7 @@ static enum fullness_group putback_zspage(struct 
size_class *class,
 
VM_BUG_ON_PAGE(!list_empty(_page->lru), first_page);
VM_BUG_ON_PAGE(ZsPageIsolate(first_page), first_page);
+   VM_BUG_ON_PAGE(check_isolated_page(first_page), first_page);
 
fullness = get_fullness_group(class, first_page);
insert_zspage(class, fullness, first_page);
@@ -1956,6 +2009,12 @@ static struct page *isolate_source_page(struct 
size_class *class)
if (!page)
continue;
 
+   /* To prevent race 

Re: [PATCH] zsmalloc: fix semicolon.cocci warnings

[Minchan Kim]

On Mon, Mar 21, 2016 at 05:48:25PM +0800, kbuild test robot wrote:
> mm/zsmalloc.c:1103:2-3: Unneeded semicolon
> 
> 
>  Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> CC: Minchan Kim 
> Signed-off-by: Fengguang Wu 
> ---
> 
>  zsmalloc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1100,7 +1100,7 @@ void unlock_zspage(struct page *first_pa
>   VM_BUG_ON_PAGE(!PageLocked(cursor), cursor);
>   if (cursor != locked_page)
>   unlock_page(cursor);
> - };
> + }
>  }
>  
>  static void free_zspage(struct zs_pool *pool, struct page *first_page)

Thanks.
Fixed.


>From bb46f8265b55228f31b8096bd1c13dd6e6ee1bc4 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Wed, 9 Mar 2016 09:37:57 +0900
Subject: [PATCH] zsmalloc: migrate tail pages in zspage

This patch enables tail page migration of zspage.

In this point, I tested zsmalloc regression with micro-benchmark
which does zs_malloc/map/unmap/zs_free for all size class
in every CPU(my system is 12) during 20 sec.

It shows 1% regression which is really small when we consider
the benefit of this feature and realworkload overhead(i.e.,
most overhead comes from compression).

Signed-off-by: Minchan Kim 
---
 mm/zsmalloc.c | 131 +++---
 1 file changed, 115 insertions(+), 16 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9b4b03d8f993..3f1d488633e1 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -551,6 +551,19 @@ static void set_zspage_mapping(struct page *first_page,
m->class = class_idx;
 }
 
+static bool check_isolated_page(struct page *first_page)
+{
+   struct page *cursor;
+
+   for (cursor = first_page; cursor != NULL; cursor =
+   get_next_page(cursor)) {
+   if (PageIsolated(cursor))
+   return true;
+   }
+
+   return false;
+}
+
 /*
  * zsmalloc divides the pool into various size classes where each
  * class maintains a list of zspages where each zspage is divided
@@ -1052,6 +1065,44 @@ void lock_zspage(struct page *first_page)
} while ((cursor = get_next_page(cursor)) != NULL);
 }
 
+int trylock_zspage(struct page *first_page, struct page *locked_page)
+{
+   struct page *cursor, *fail;
+
+   VM_BUG_ON_PAGE(!is_first_page(first_page), first_page);
+
+   for (cursor = first_page; cursor != NULL; cursor =
+   get_next_page(cursor)) {
+   if (cursor != locked_page) {
+   if (!trylock_page(cursor)) {
+   fail = cursor;
+   goto unlock;
+   }
+   }
+   }
+
+   return 1;
+unlock:
+   for (cursor = first_page; cursor != fail; cursor =
+   get_next_page(cursor)) {
+   if (cursor != locked_page)
+   unlock_page(cursor);
+   }
+
+   return 0;
+}
+
+void unlock_zspage(struct page *first_page, struct page *locked_page)
+{
+   struct page *cursor = first_page;
+
+   for (; cursor != NULL; cursor = get_next_page(cursor)) {
+   VM_BUG_ON_PAGE(!PageLocked(cursor), cursor);
+   if (cursor != locked_page)
+   unlock_page(cursor);
+   }
+}
+
 static void free_zspage(struct zs_pool *pool, struct page *first_page)
 {
struct page *nextp, *tmp;
@@ -1090,16 +1141,17 @@ static void init_zspage(struct size_class *class, 
struct page *first_page,
first_page->freelist = NULL;
INIT_LIST_HEAD(_page->lru);
set_zspage_inuse(first_page, 0);
-   BUG_ON(!trylock_page(first_page));
-   first_page->mapping = mapping;
-   __SetPageMovable(first_page);
-   unlock_page(first_page);
 
while (page) {
struct page *next_page;
struct link_free *link;
void *vaddr;
 
+   BUG_ON(!trylock_page(page));
+   page->mapping = mapping;
+   __SetPageMovable(page);
+   unlock_page(page);
+
vaddr = kmap_atomic(page);
link = (struct link_free *)vaddr + off / sizeof(*link);
 
@@ -1850,6 +1902,7 @@ static enum fullness_group putback_zspage(struct 
size_class *class,
 
VM_BUG_ON_PAGE(!list_empty(_page->lru), first_page);
VM_BUG_ON_PAGE(ZsPageIsolate(first_page), first_page);
+   VM_BUG_ON_PAGE(check_isolated_page(first_page), first_page);
 
fullness = get_fullness_group(class, first_page);
insert_zspage(class, fullness, first_page);
@@ -1956,6 +2009,12 @@ static struct page *isolate_source_page(struct 
size_class *class)
if (!page)
continue;
 
+   /* To prevent race between object and page migration */
+   if (!trylock_zspage(page, NULL)) {
+ 

Re: [PATCH] locking/qrwlock: Allow multiple spinning readers

[Waiman Long]

On 03/20/2016 06:43 AM, Peter Zijlstra wrote:

We still have that starvation case in mutex, I would think that is far
more important to fix.


Peter, I am sorry that I let the mutex patch languish for a while. I 
will work on that next.


Cheers,
Longman

Re: [PATCH] locking/qrwlock: Allow multiple spinning readers

[Waiman Long]

On 03/20/2016 06:43 AM, Peter Zijlstra wrote:

We still have that starvation case in mutex, I would think that is far
more important to fix.


Peter, I am sorry that I let the mutex patch languish for a while. I 
will work on that next.


Cheers,
Longman

Re: [PATCH v2 14/18] mm/balloon: use general movable page feature into balloon

[Minchan Kim]

On Mon, Mar 21, 2016 at 04:29:55PM +0800, kbuild test robot wrote:
> Hi Minchan,
> 
> [auto build test ERROR on next-20160318]
> [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339
> config: x86_64-randconfig-x000-201612 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers/virtio/virtio_balloon.c: In function 'virtballoon_probe':
> >> drivers/virtio/virtio_balloon.c:578:15: error: 'balloon_mnt' undeclared 
> >> (first use in this function)
>  kern_unmount(balloon_mnt);
>   ^
>drivers/virtio/virtio_balloon.c:578:15: note: each undeclared identifier 
> is reported only once for each function it appears in
> >> drivers/virtio/virtio_balloon.c:579:1: warning: label 'out_free_vb' 
> >> defined but not used [-Wunused-label]
> out_free_vb:
> ^
> 
> vim +/balloon_mnt +578 drivers/virtio/virtio_balloon.c
> 
>572
>573out_oom_notify:
>574vdev->config->del_vqs(vdev);
>575out_unmount:
>576if (vb->vb_dev_info.inode)
>577iput(vb->vb_dev_info.inode);
>  > 578kern_unmount(balloon_mnt);
>  > 579out_free_vb:
>580kfree(vb);
>581out:
>582return err;
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


Thanks, kbuild.
Fixed.

>From 7006a7ee62bb09273f96d8cb45c32e42453ab931 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minc...@kernel.org>
Date: Thu, 3 Mar 2016 14:28:45 +0900
Subject: [PATCH] mm/balloon: use general movable page feature into balloon

Now, VM has a feature to migrate non-lru movable pages so
balloon doesn't need custom migration hooks in migrate.c
and compact.c. Instead, this patch implements page->mapping
->{isolate|migrate|putback} functions.

With that, we could remove hooks for ballooning in general
migration functions and make balloon compaction simple.

Cc: virtualizat...@lists.linux-foundation.org
Cc: Rafael Aquini <aqu...@redhat.com>
Cc: Konstantin Khlebnikov <koc...@gmail.com>
Signed-off-by: Gioh Kim <guru...@hanmail.net>
Signed-off-by: Minchan Kim <minc...@kernel.org>
---
 drivers/virtio/virtio_balloon.c|  53 ---
 include/linux/balloon_compaction.h |  47 -
 include/linux/page-flags.h |  52 +++
 include/uapi/linux/magic.h |   1 +
 mm/balloon_compaction.c| 101 -
 mm/compaction.c|   7 ---
 mm/migrate.c   |  22 ++--
 mm/vmscan.c|   2 +-
 8 files changed, 116 insertions(+), 169 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 7b6d74f0c72f..0c16192d2684 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Balloon device works in 4K page units.  So each page is pointed to by
@@ -45,6 +46,10 @@ static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
 module_param(oom_pages, int, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
 
+#ifdef CONFIG_BALLOON_COMPACTION
+static struct vfsmount *balloon_mnt;
+#endif
+
 struct virtio_balloon {
struct virtio_device *vdev;
struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
@@ -482,10 +487,29 @@ static int virtballoon_migratepage(struct 
balloon_dev_info *vb_dev_info,
 
mutex_unlock(>balloon_lock);
 
+   ClearPageIsolated(page);
put_page(page); /* balloon reference */
 
return MIGRATEPAGE_SUCCESS;
 }
+
+static struct dentry *balloon_mount(struct file_system_type *fs_type,
+   int flags, const char *dev_name, void *data)
+{
+   static const struct dentry_operations ops = {
+   .d_dname = simple_dname,
+   };
+
+   return mount_pseudo(fs_type, "balloon-kvm:", NULL, ,
+   BALLOON_KVM_MAGIC);
+}
+
+static struct file_system_type balloon_fs = {
+   .name   = "balloon-kvm",
+   .mount  = balloon_mount,
+   .kill_sb= kill_anon_super,
+};
+
 #endif /* CONFIG_BALLOON_COMPACTION */
 
 static int virtballoon_probe(struct virtio_device *vdev)
@@ -515,10 +539,6 @@ stati

Re: [PATCH v2 14/18] mm/balloon: use general movable page feature into balloon

[Minchan Kim]

On Mon, Mar 21, 2016 at 04:29:55PM +0800, kbuild test robot wrote:
> Hi Minchan,
> 
> [auto build test ERROR on next-20160318]
> [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339
> config: x86_64-randconfig-x000-201612 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers/virtio/virtio_balloon.c: In function 'virtballoon_probe':
> >> drivers/virtio/virtio_balloon.c:578:15: error: 'balloon_mnt' undeclared 
> >> (first use in this function)
>  kern_unmount(balloon_mnt);
>   ^
>drivers/virtio/virtio_balloon.c:578:15: note: each undeclared identifier 
> is reported only once for each function it appears in
> >> drivers/virtio/virtio_balloon.c:579:1: warning: label 'out_free_vb' 
> >> defined but not used [-Wunused-label]
> out_free_vb:
> ^
> 
> vim +/balloon_mnt +578 drivers/virtio/virtio_balloon.c
> 
>572
>573out_oom_notify:
>574vdev->config->del_vqs(vdev);
>575out_unmount:
>576if (vb->vb_dev_info.inode)
>577iput(vb->vb_dev_info.inode);
>  > 578kern_unmount(balloon_mnt);
>  > 579out_free_vb:
>580kfree(vb);
>581out:
>582return err;
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


Thanks, kbuild.
Fixed.

>From 7006a7ee62bb09273f96d8cb45c32e42453ab931 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Thu, 3 Mar 2016 14:28:45 +0900
Subject: [PATCH] mm/balloon: use general movable page feature into balloon

Now, VM has a feature to migrate non-lru movable pages so
balloon doesn't need custom migration hooks in migrate.c
and compact.c. Instead, this patch implements page->mapping
->{isolate|migrate|putback} functions.

With that, we could remove hooks for ballooning in general
migration functions and make balloon compaction simple.

Cc: virtualizat...@lists.linux-foundation.org
Cc: Rafael Aquini 
Cc: Konstantin Khlebnikov 
Signed-off-by: Gioh Kim 
Signed-off-by: Minchan Kim 
---
 drivers/virtio/virtio_balloon.c|  53 ---
 include/linux/balloon_compaction.h |  47 -
 include/linux/page-flags.h |  52 +++
 include/uapi/linux/magic.h |   1 +
 mm/balloon_compaction.c| 101 -
 mm/compaction.c|   7 ---
 mm/migrate.c   |  22 ++--
 mm/vmscan.c|   2 +-
 8 files changed, 116 insertions(+), 169 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 7b6d74f0c72f..0c16192d2684 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Balloon device works in 4K page units.  So each page is pointed to by
@@ -45,6 +46,10 @@ static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
 module_param(oom_pages, int, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
 
+#ifdef CONFIG_BALLOON_COMPACTION
+static struct vfsmount *balloon_mnt;
+#endif
+
 struct virtio_balloon {
struct virtio_device *vdev;
struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
@@ -482,10 +487,29 @@ static int virtballoon_migratepage(struct 
balloon_dev_info *vb_dev_info,
 
mutex_unlock(>balloon_lock);
 
+   ClearPageIsolated(page);
put_page(page); /* balloon reference */
 
return MIGRATEPAGE_SUCCESS;
 }
+
+static struct dentry *balloon_mount(struct file_system_type *fs_type,
+   int flags, const char *dev_name, void *data)
+{
+   static const struct dentry_operations ops = {
+   .d_dname = simple_dname,
+   };
+
+   return mount_pseudo(fs_type, "balloon-kvm:", NULL, ,
+   BALLOON_KVM_MAGIC);
+}
+
+static struct file_system_type balloon_fs = {
+   .name   = "balloon-kvm",
+   .mount  = balloon_mount,
+   .kill_sb= kill_anon_super,
+};
+
 #endif /* CONFIG_BALLOON_COMPACTION */
 
 static int virtballoon_probe(struct virtio_device *vdev)
@@ -515,10 +539,6 @@ static int virtballoon_probe(struct virtio_device *vdev)
vb->vdev = vdev;
 
balloon_devinfo_init(>v

Re: [PATCH] x86: Avoid undefined behavior in macro expansion

[Vinicius Tinti]

On Fri, Mar 18, 2016 at 11:15 PM, Al Viro  wrote:
> On Wed, Mar 16, 2016 at 11:48:49PM -0300, Vinicius Tinti wrote:
>> C11 standard (at 6.10.3.3) says that ## operator (paste) has undefined
>> behavior when one of the result operands is not a valid preprocessing
>> token.
>>
>> Therefore the macro expansion may depend on compiler implementation
>> which may or no preserve the leading white space.
>>
>> Moreover other places in kernel use CONCAT(a,b) instead of CONCAT(a, b).
>> Changing favors concise usage.
>
> Huh?
>
>> -#define  XMM(i)  CONCAT(%xmm, i)
>> +#define  XMM(i)  CONCAT(%xmm,i)
>
> What are you talking about?  Undefined behaviour is when the result of
> concatenation of adjacent tokens is not a valid preprocessor token.
> It says nothing about the either argument being a single token.

Please check the example below otherwise it will be hard to explain.

The problem is that _i_ can be a macro to be expanded too. And
it can be a parameter for a _paste_ operator.

  // tricky code
  #define CONCAT(a,b)a##b
  #defineXMM(i)CONCAT(%xmm, i)
  .macro foo n
x = XMM(\n)
  .endm

_%xmm_ is not a problem but _i_ is.

> In this case after the substitution of e.g. XMM(42) we get 3 tokens:
> Punctuator[%] Identifier[xmm] Pp-number[42]
> with ## instructing us to replace the last two with preprocessor token that
> would be represented as concatenation of their representations.  Which is
> to say, concatenation of xmm and 42, i.e. xmm42.  Which *is* a
> representation of a valid preprocessor token - namely, Identifier[xmm42].

Agree. But it is not this case. I will add the code above at commit and
describe it. It will be easy to explain what I am trying to solve.

> No undefined behaviour at all.  And yes, you get two preprocessor tokens
> in the expansion - % and xmm42.  Preprocessor works in terms of tokens,
> not strings...

Understood.

> If you know of any compiler where these two variants would produce different
> expansions of XMM(), please report it to maintainers of
> the compiler in question; it's a bug, plain and simple.  And no, there's
> no undefined behaviour in that.

I reported a bug and discussed over it and I too believe that the tricky
code that I have just sent triggers an undefined behavior.

What do you think?

-- 
Simplicity is the ultimate sophistication

Re: [PATCH] x86: Avoid undefined behavior in macro expansion

[Vinicius Tinti]

On Fri, Mar 18, 2016 at 11:15 PM, Al Viro  wrote:
> On Wed, Mar 16, 2016 at 11:48:49PM -0300, Vinicius Tinti wrote:
>> C11 standard (at 6.10.3.3) says that ## operator (paste) has undefined
>> behavior when one of the result operands is not a valid preprocessing
>> token.
>>
>> Therefore the macro expansion may depend on compiler implementation
>> which may or no preserve the leading white space.
>>
>> Moreover other places in kernel use CONCAT(a,b) instead of CONCAT(a, b).
>> Changing favors concise usage.
>
> Huh?
>
>> -#define  XMM(i)  CONCAT(%xmm, i)
>> +#define  XMM(i)  CONCAT(%xmm,i)
>
> What are you talking about?  Undefined behaviour is when the result of
> concatenation of adjacent tokens is not a valid preprocessor token.
> It says nothing about the either argument being a single token.

Please check the example below otherwise it will be hard to explain.

The problem is that _i_ can be a macro to be expanded too. And
it can be a parameter for a _paste_ operator.

  // tricky code
  #define CONCAT(a,b)a##b
  #defineXMM(i)CONCAT(%xmm, i)
  .macro foo n
x = XMM(\n)
  .endm

_%xmm_ is not a problem but _i_ is.

> In this case after the substitution of e.g. XMM(42) we get 3 tokens:
> Punctuator[%] Identifier[xmm] Pp-number[42]
> with ## instructing us to replace the last two with preprocessor token that
> would be represented as concatenation of their representations.  Which is
> to say, concatenation of xmm and 42, i.e. xmm42.  Which *is* a
> representation of a valid preprocessor token - namely, Identifier[xmm42].

Agree. But it is not this case. I will add the code above at commit and
describe it. It will be easy to explain what I am trying to solve.

> No undefined behaviour at all.  And yes, you get two preprocessor tokens
> in the expansion - % and xmm42.  Preprocessor works in terms of tokens,
> not strings...

Understood.

> If you know of any compiler where these two variants would produce different
> expansions of XMM(), please report it to maintainers of
> the compiler in question; it's a bug, plain and simple.  And no, there's
> no undefined behaviour in that.

I reported a bug and discussed over it and I too believe that the tricky
code that I have just sent triggers an undefined behavior.

What do you think?

-- 
Simplicity is the ultimate sophistication

Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

[Byungchul Park]

On Tue, Mar 22, 2016 at 02:11:05AM +0900, Sergey Senozhatsky wrote:
> On (03/21/16 16:33), Jan Kara wrote:
> [..]
> > > > And by calling wake_up_process() under logbuf_lock, you actually 
> > > > introduce
> > > > recursion issues for printk_deferred() messages which are supposed to be
> > > > working from under rq->lock and similar. So I think you have to keep 
> > > > this
> > > > section outside of logbuf_lock.
> > > 
> > > hm, in_sched (printk_deferred()) messages are printed by
> > > irq work->wake_up_klogd_work_func(), not by wake_up_process()
> > > from vprintk_emit(). or am I missing something?
> > 
> > Think of following:
> > 
> > some function
> >   printk()
> > vprintk_emit()
> >   spin_lock(_lock);
> >   ...
> >   wake_up_process()
> > printk_deferred()
> >   vprintk_emit() -> recursion on logbuf_lock
> 
> uh, indeed. I was more concerned about printk() calls that are
> troublemakers and are already in wake_up_process() - spin_dump()s.
> but yes, braking printk_deferred() in this case is a regression.

Already said any kind of printk() cannot work within logbuf_lock. :-(

> thanks for pointing that out. and also thanks to Byungchul.

My pleasure.

Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

[Byungchul Park]

On Tue, Mar 22, 2016 at 02:11:05AM +0900, Sergey Senozhatsky wrote:
> On (03/21/16 16:33), Jan Kara wrote:
> [..]
> > > > And by calling wake_up_process() under logbuf_lock, you actually 
> > > > introduce
> > > > recursion issues for printk_deferred() messages which are supposed to be
> > > > working from under rq->lock and similar. So I think you have to keep 
> > > > this
> > > > section outside of logbuf_lock.
> > > 
> > > hm, in_sched (printk_deferred()) messages are printed by
> > > irq work->wake_up_klogd_work_func(), not by wake_up_process()
> > > from vprintk_emit(). or am I missing something?
> > 
> > Think of following:
> > 
> > some function
> >   printk()
> > vprintk_emit()
> >   spin_lock(_lock);
> >   ...
> >   wake_up_process()
> > printk_deferred()
> >   vprintk_emit() -> recursion on logbuf_lock
> 
> uh, indeed. I was more concerned about printk() calls that are
> troublemakers and are already in wake_up_process() - spin_dump()s.
> but yes, braking printk_deferred() in this case is a regression.

Already said any kind of printk() cannot work within logbuf_lock. :-(

> thanks for pointing that out. and also thanks to Byungchul.

My pleasure.