Re: [PATCH v1 6/7] vfio: ap: register guest ISC with GISA and GIB

[kbuild test robot]

Hi Pierre,

I love your patch! Yet something to improve:

[auto build test ERROR on s390/features]
[also build test ERROR on next-20181101]
[cannot apply to v4.19]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pierre-Morel/s390-vfio-ap-Using-GISA-for-AP-Interrupt/20181102-010854
base:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=s390 

All errors (new ones prefixed by >>):

>> ERROR: "kvm_s390_gisc_unregister" [drivers/s390/crypto/vfio_ap.ko] undefined!
>> ERROR: "kvm_s390_gisc_register" [drivers/s390/crypto/vfio_ap.ko] undefined!
   ERROR: "__node_distance" [drivers/nvme/host/nvme-core.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH v1 6/7] vfio: ap: register guest ISC with GISA and GIB

[kbuild test robot]

Hi Pierre,

I love your patch! Yet something to improve:

[auto build test ERROR on s390/features]
[also build test ERROR on next-20181101]
[cannot apply to v4.19]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pierre-Morel/s390-vfio-ap-Using-GISA-for-AP-Interrupt/20181102-010854
base:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=s390 

All errors (new ones prefixed by >>):

>> ERROR: "kvm_s390_gisc_unregister" [drivers/s390/crypto/vfio_ap.ko] undefined!
>> ERROR: "kvm_s390_gisc_register" [drivers/s390/crypto/vfio_ap.ko] undefined!
   ERROR: "__node_distance" [drivers/nvme/host/nvme-core.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

[Anshuman Khandual]

 

On 10/18/2018 07:47 AM, Naoya Horiguchi wrote:
> On Tue, Oct 16, 2018 at 10:31:50AM -0400, Zi Yan wrote:
>> On 15 Oct 2018, at 0:06, Anshuman Khandual wrote:
>>
>>> On 10/15/2018 06:23 AM, Zi Yan wrote:
 On 12 Oct 2018, at 4:00, Anshuman Khandual wrote:

> On 10/10/2018 06:13 PM, Zi Yan wrote:
>> On 10 Oct 2018, at 0:05, Anshuman Khandual wrote:
>>
>>> On 10/09/2018 07:28 PM, Zi Yan wrote:
 cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE 
 for x86
 PMD migration entry check)

 On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:

> A normal mapped THP page at PMD level should be correctly 
> differentiated
> from a PMD migration entry while walking the page table. A mapped THP 
> would
> additionally check positive for pmd_present() along with 
> pmd_trans_huge()
> as compared to a PMD migration entry. This just adds a new 
> conditional test
> differentiating the two while walking the page table.
>
> Fixes: 616b8371539a6 ("mm: thp: enable thp migration in generic path")
> Signed-off-by: Anshuman Khandual 
> ---
> On X86, pmd_trans_huge() and is_pmd_migration_entry() are always 
> mutually
> exclusive which makes the current conditional block work for both 
> mapped
> and migration entries. This is not same with arm64 where 
> pmd_trans_huge()

 !pmd_present() && pmd_trans_huge() is used to represent THPs under 
 splitting,
>>>
>>> Not really if we just look at code in the conditional blocks.
>>
>> Yeah, I explained it wrong above. Sorry about that.
>>
>> In x86, pmd_present() checks (_PAGE_PRESENT | _PAGE_PROTNONE | 
>> _PAGE_PSE),
>> thus, it returns true even if the present bit is cleared but PSE bit is 
>> set.
>
> Okay.
>
>> This is done so, because THPs under splitting are regarded as present in 
>> the kernel
>> but not present when a hardware page table walker checks it.
>
> Okay.
>
>>
>> For PMD migration entry, which should be regarded as not present, if PSE 
>> bit
>> is set, which makes pmd_trans_huge() returns true, like ARM64 does, all
>> PMD migration entries will be regarded as present
>
> Okay to make pmd_present() return false pmd_trans_huge() has to return 
> false
> as well. Is there anything which can be done to get around this problem on
> X86 ? pmd_trans_huge() returning true for a migration entry sounds 
> logical.
> Otherwise we would revert the condition block order to accommodate both 
> the
> implementation for pmd_trans_huge() as suggested by Kirill before or just
> consider this patch forward.
>
> Because I am not really sure yet about the idea of getting pmd_present()
> check into pmd_trans_huge() on arm64 just to make it fit into this 
> semantics
> as suggested by Will. If a PMD is trans huge page or not should not 
> depend on
> whether it is present or not.

 In terms of THPs, we have three cases: a present THP, a THP under 
 splitting,
 and a THP under migration. pmd_present() and pmd_trans_huge() both return 
 true
 for a present THP and a THP under splitting, because they discover 
 _PAGE_PSE bit
>>>
>>> Then how do we differentiate between a mapped THP and a splitting THP.
>>
>> AFAIK, in x86, there is no distinction between a mapped THP and a splitting 
>> THP
>> using helper functions.
>>
>> A mapped THP has _PAGE_PRESENT bit and _PAGE_PSE bit set, whereas a 
>> splitting THP
>> has only _PAGE_PSE bit set. But both pmd_present() and pmd_trans_huge() 
>> return
>> true as long as _PAGE_PSE bit is set.
>>
>>>
 is set for both cases, whereas they both return false for a THP under 
 migration.
 You want to change them to make pmd_trans_huge() returns true for a THP 
 under migration
 instead of false to help ARM64’s support for THP migration.
>>> I am just trying to understand the rationale behind this semantics and see 
>>> where
>>> it should be fixed.
>>>
>>> I think the fundamental problem here is that THP under split has been 
>>> difficult
>>> to be re-presented through the available helper functions and in turn PTE 
>>> bits.
>>>
>>> The following checks
>>>
>>> 1) pmd_present()
>>> 2) pmd_trans_huge()
>>>
>>> Represent three THP states
>>>
>>> 1) Mapped THP   (pmd_present && pmd_trans_huge)
>>> 2) Splitting THP(pmd_present && pmd_trans_huge)
>>> 3) Migrating THP(!pmd_present && !pmd_trans_huge)
>>>
>>> The problem is if we make pmd_trans_huge() return true for all the three 
>>> states
>>> which sounds logical because they are all still trans huge PMD, then 
>>> pmd_present()
>>> can only represent two states not three as required.
>>
>> We are on the same page about 

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

[Anshuman Khandual]

 

On 10/18/2018 07:47 AM, Naoya Horiguchi wrote:
> On Tue, Oct 16, 2018 at 10:31:50AM -0400, Zi Yan wrote:
>> On 15 Oct 2018, at 0:06, Anshuman Khandual wrote:
>>
>>> On 10/15/2018 06:23 AM, Zi Yan wrote:
 On 12 Oct 2018, at 4:00, Anshuman Khandual wrote:

> On 10/10/2018 06:13 PM, Zi Yan wrote:
>> On 10 Oct 2018, at 0:05, Anshuman Khandual wrote:
>>
>>> On 10/09/2018 07:28 PM, Zi Yan wrote:
 cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE 
 for x86
 PMD migration entry check)

 On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:

> A normal mapped THP page at PMD level should be correctly 
> differentiated
> from a PMD migration entry while walking the page table. A mapped THP 
> would
> additionally check positive for pmd_present() along with 
> pmd_trans_huge()
> as compared to a PMD migration entry. This just adds a new 
> conditional test
> differentiating the two while walking the page table.
>
> Fixes: 616b8371539a6 ("mm: thp: enable thp migration in generic path")
> Signed-off-by: Anshuman Khandual 
> ---
> On X86, pmd_trans_huge() and is_pmd_migration_entry() are always 
> mutually
> exclusive which makes the current conditional block work for both 
> mapped
> and migration entries. This is not same with arm64 where 
> pmd_trans_huge()

 !pmd_present() && pmd_trans_huge() is used to represent THPs under 
 splitting,
>>>
>>> Not really if we just look at code in the conditional blocks.
>>
>> Yeah, I explained it wrong above. Sorry about that.
>>
>> In x86, pmd_present() checks (_PAGE_PRESENT | _PAGE_PROTNONE | 
>> _PAGE_PSE),
>> thus, it returns true even if the present bit is cleared but PSE bit is 
>> set.
>
> Okay.
>
>> This is done so, because THPs under splitting are regarded as present in 
>> the kernel
>> but not present when a hardware page table walker checks it.
>
> Okay.
>
>>
>> For PMD migration entry, which should be regarded as not present, if PSE 
>> bit
>> is set, which makes pmd_trans_huge() returns true, like ARM64 does, all
>> PMD migration entries will be regarded as present
>
> Okay to make pmd_present() return false pmd_trans_huge() has to return 
> false
> as well. Is there anything which can be done to get around this problem on
> X86 ? pmd_trans_huge() returning true for a migration entry sounds 
> logical.
> Otherwise we would revert the condition block order to accommodate both 
> the
> implementation for pmd_trans_huge() as suggested by Kirill before or just
> consider this patch forward.
>
> Because I am not really sure yet about the idea of getting pmd_present()
> check into pmd_trans_huge() on arm64 just to make it fit into this 
> semantics
> as suggested by Will. If a PMD is trans huge page or not should not 
> depend on
> whether it is present or not.

 In terms of THPs, we have three cases: a present THP, a THP under 
 splitting,
 and a THP under migration. pmd_present() and pmd_trans_huge() both return 
 true
 for a present THP and a THP under splitting, because they discover 
 _PAGE_PSE bit
>>>
>>> Then how do we differentiate between a mapped THP and a splitting THP.
>>
>> AFAIK, in x86, there is no distinction between a mapped THP and a splitting 
>> THP
>> using helper functions.
>>
>> A mapped THP has _PAGE_PRESENT bit and _PAGE_PSE bit set, whereas a 
>> splitting THP
>> has only _PAGE_PSE bit set. But both pmd_present() and pmd_trans_huge() 
>> return
>> true as long as _PAGE_PSE bit is set.
>>
>>>
 is set for both cases, whereas they both return false for a THP under 
 migration.
 You want to change them to make pmd_trans_huge() returns true for a THP 
 under migration
 instead of false to help ARM64’s support for THP migration.
>>> I am just trying to understand the rationale behind this semantics and see 
>>> where
>>> it should be fixed.
>>>
>>> I think the fundamental problem here is that THP under split has been 
>>> difficult
>>> to be re-presented through the available helper functions and in turn PTE 
>>> bits.
>>>
>>> The following checks
>>>
>>> 1) pmd_present()
>>> 2) pmd_trans_huge()
>>>
>>> Represent three THP states
>>>
>>> 1) Mapped THP   (pmd_present && pmd_trans_huge)
>>> 2) Splitting THP(pmd_present && pmd_trans_huge)
>>> 3) Migrating THP(!pmd_present && !pmd_trans_huge)
>>>
>>> The problem is if we make pmd_trans_huge() return true for all the three 
>>> states
>>> which sounds logical because they are all still trans huge PMD, then 
>>> pmd_present()
>>> can only represent two states not three as required.
>>
>> We are on the same page about 

[GIT PULL] vfs: fix many problems in vfs clone/dedupe implementation

[Dave Chinner]

Hi Linus,

Can you please pull update containing a rework of the VFS clone and
dedupe file range infrastructure from the tag listed below?

We discovered many issues with these interfaces late in the 4.19
cycle - the worst of them (data corruption, setuid stripping) were
fixed for XFS in 4.19-rc8, but a larger rework of the infrastructure
fixing all the problems was needed. That rework is the contents of
this pull request.

The base tree is 4.19 because there was an unrelated
vfs_clone_file_range API cleanup merged in v4.19-rc7, and combined
with the mods in 4.19-rc8 it was simpler for everyone to base this
work on a tree with all those changes already in it.

There is a simple conflict with your current tree in
Documentation/filesystems/porting. However, if you pull Al's pending
VFS tree before this there will also be a more significant conflict
fs/read_write.c in the vfs_dedupe_file_range_one() function rework.
The details of the conflict  and the resolution that the linux-next
tree is carrying can be found here:

https://lore.kernel.org/lkml/20181031115247.6adcb...@canb.auug.org.au/

If you need any more info or a tree with the conflicts already
resolved, please let me know.

Thanks,

Dave.

PS. Darrick is back up to speed so the next XFS pull request for
fixes later in the -rc cycle will probably come from him again.

The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:

  Linux 4.19 (2018-10-22 07:37:37 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/fs/xfs/xfs-linux tags/xfs-4.20-merge-2

for you to fetch changes up to bf4a1fcf0bc18d52cf0fce6571d6f327ab5eaf22:

  xfs: remove [cm]time update from reflink calls (2018-10-30 10:47:48 +1100)


vfs: rework data cloning infrastructure

Rework the vfs_clone_file_range and vfs_dedupe_file_range infrastructure to use
a common .remap_file_range method and supply generic bounds and sanity checking
functions that are shared with the data write path. The current VFS
infrastructure has problems with rlimit, LFS file sizes, file time stamps,
maximum filesystem file sizes, stripping setuid bits, etc and so they are
addressed in these commits.

We also introduce the ability for the ->remap_file_range methods to return short
clones so that clones for vfs_copy_file_range() don't get rejected if the entire
range can't be cloned. It also allows filesystems to sliently skip deduplication
of partial EOF blocks if they are not capable of doing so without requiring
errors to be thrown to userspace.

All existing filesystems are converted to user the new .remap_file_range method,
and both XFS and ocfs2 are modified to make use of the new generic checking
infrastructure.


Darrick J. Wong (28):
  vfs: vfs_clone_file_prep_inodes should return EINVAL for a clone from 
beyond EOF
  vfs: check file ranges before cloning files
  vfs: exit early from zero length remap operations
  vfs: strengthen checking of file range inputs to generic_remap_checks
  vfs: avoid problematic remapping requests into partial EOF block
  vfs: skip zero-length dedupe requests
  vfs: rename vfs_clone_file_prep to be more descriptive
  vfs: rename clone_verify_area to remap_verify_area
  vfs: combine the clone and dedupe into a single remap_file_range
  vfs: pass remap flags to generic_remap_file_range_prep
  vfs: pass remap flags to generic_remap_checks
  vfs: remap helper should update destination inode metadata
  vfs: make remap_file_range functions take and return bytes completed
  vfs: plumb remap flags through the vfs clone functions
  vfs: plumb remap flags through the vfs dedupe functions
  vfs: enable remap callers that can handle short operations
  vfs: hide file range comparison function
  vfs: clean up generic_remap_file_range_prep return value
  ocfs2: truncate page cache for clone destination file before remapping
  ocfs2: fix pagecache truncation prior to reflink
  ocfs2: support partial clone range and dedupe range
  ocfs2: remove ocfs2_reflink_remap_range
  xfs: fix pagecache truncation prior to reflink
  xfs: clean up xfs_reflink_remap_blocks call site
  xfs: support returning partial reflink results
  xfs: remove redundant remap partial EOF block checks
  xfs: remove xfs_reflink_remap_range
  xfs: remove [cm]time update from reflink calls

 Documentation/filesystems/porting |   5 +
 Documentation/filesystems/vfs.txt |  22 ++-
 fs/btrfs/ctree.h  |   8 +-
 fs/btrfs/file.c   |   3 +-
 fs/btrfs/ioctl.c  |  50 ++---
 fs/cifs/cifsfs.c  |  24 ++-
 fs/ioctl.c|  10 +-
 fs/nfs/nfs4file.c |  12 +-
 fs/nfsd/vfs.c |   8 +-
 fs/ocfs2/file.c   |  93 +++--
 

[GIT PULL] vfs: fix many problems in vfs clone/dedupe implementation

[Dave Chinner]

Hi Linus,

Can you please pull update containing a rework of the VFS clone and
dedupe file range infrastructure from the tag listed below?

We discovered many issues with these interfaces late in the 4.19
cycle - the worst of them (data corruption, setuid stripping) were
fixed for XFS in 4.19-rc8, but a larger rework of the infrastructure
fixing all the problems was needed. That rework is the contents of
this pull request.

The base tree is 4.19 because there was an unrelated
vfs_clone_file_range API cleanup merged in v4.19-rc7, and combined
with the mods in 4.19-rc8 it was simpler for everyone to base this
work on a tree with all those changes already in it.

There is a simple conflict with your current tree in
Documentation/filesystems/porting. However, if you pull Al's pending
VFS tree before this there will also be a more significant conflict
fs/read_write.c in the vfs_dedupe_file_range_one() function rework.
The details of the conflict  and the resolution that the linux-next
tree is carrying can be found here:

https://lore.kernel.org/lkml/20181031115247.6adcb...@canb.auug.org.au/

If you need any more info or a tree with the conflicts already
resolved, please let me know.

Thanks,

Dave.

PS. Darrick is back up to speed so the next XFS pull request for
fixes later in the -rc cycle will probably come from him again.

The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:

  Linux 4.19 (2018-10-22 07:37:37 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/fs/xfs/xfs-linux tags/xfs-4.20-merge-2

for you to fetch changes up to bf4a1fcf0bc18d52cf0fce6571d6f327ab5eaf22:

  xfs: remove [cm]time update from reflink calls (2018-10-30 10:47:48 +1100)


vfs: rework data cloning infrastructure

Rework the vfs_clone_file_range and vfs_dedupe_file_range infrastructure to use
a common .remap_file_range method and supply generic bounds and sanity checking
functions that are shared with the data write path. The current VFS
infrastructure has problems with rlimit, LFS file sizes, file time stamps,
maximum filesystem file sizes, stripping setuid bits, etc and so they are
addressed in these commits.

We also introduce the ability for the ->remap_file_range methods to return short
clones so that clones for vfs_copy_file_range() don't get rejected if the entire
range can't be cloned. It also allows filesystems to sliently skip deduplication
of partial EOF blocks if they are not capable of doing so without requiring
errors to be thrown to userspace.

All existing filesystems are converted to user the new .remap_file_range method,
and both XFS and ocfs2 are modified to make use of the new generic checking
infrastructure.


Darrick J. Wong (28):
  vfs: vfs_clone_file_prep_inodes should return EINVAL for a clone from 
beyond EOF
  vfs: check file ranges before cloning files
  vfs: exit early from zero length remap operations
  vfs: strengthen checking of file range inputs to generic_remap_checks
  vfs: avoid problematic remapping requests into partial EOF block
  vfs: skip zero-length dedupe requests
  vfs: rename vfs_clone_file_prep to be more descriptive
  vfs: rename clone_verify_area to remap_verify_area
  vfs: combine the clone and dedupe into a single remap_file_range
  vfs: pass remap flags to generic_remap_file_range_prep
  vfs: pass remap flags to generic_remap_checks
  vfs: remap helper should update destination inode metadata
  vfs: make remap_file_range functions take and return bytes completed
  vfs: plumb remap flags through the vfs clone functions
  vfs: plumb remap flags through the vfs dedupe functions
  vfs: enable remap callers that can handle short operations
  vfs: hide file range comparison function
  vfs: clean up generic_remap_file_range_prep return value
  ocfs2: truncate page cache for clone destination file before remapping
  ocfs2: fix pagecache truncation prior to reflink
  ocfs2: support partial clone range and dedupe range
  ocfs2: remove ocfs2_reflink_remap_range
  xfs: fix pagecache truncation prior to reflink
  xfs: clean up xfs_reflink_remap_blocks call site
  xfs: support returning partial reflink results
  xfs: remove redundant remap partial EOF block checks
  xfs: remove xfs_reflink_remap_range
  xfs: remove [cm]time update from reflink calls

 Documentation/filesystems/porting |   5 +
 Documentation/filesystems/vfs.txt |  22 ++-
 fs/btrfs/ctree.h  |   8 +-
 fs/btrfs/file.c   |   3 +-
 fs/btrfs/ioctl.c  |  50 ++---
 fs/cifs/cifsfs.c  |  24 ++-
 fs/ioctl.c|  10 +-
 fs/nfs/nfs4file.c |  12 +-
 fs/nfsd/vfs.c |   8 +-
 fs/ocfs2/file.c   |  93 +++--
 

Re: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

[gre...@linuxfoundation.org]

On Thu, Nov 01, 2018 at 07:22:28PM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org 
> > Sent: Thursday, November 1, 2018 11:57
> > To: Dexuan Cui 
> > 
> > On Wed, Oct 31, 2018 at 11:23:54PM +, Dexuan Cui wrote:
> > > > From: Michael Kelley 
> > > > Sent: Wednesday, October 24, 2018 08:38
> > > > From: k...@linuxonhyperv.com   Sent:
> > Wednesday,
> > > > October 17, 2018 10:10 PM
> > > > > From: Dexuan Cui 
> > > > >
> > > > > In kvp_send_key(), we do need call process_ib_ipinfo() if
> > > > > message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns
> > out
> > > > > the userland hv_kvp_daemon needs the info of operation, adapter_id
> > and
> > > > > addr_family. With the incorrect fc62c3b1977d, the host can't get the
> > > > > VM's IP via KVP.
> > > > >
> > > > > And, fc62c3b1977d added a "break;", but actually forgot to initialize
> > > > > the key_size/value in the case of KVP_OP_SET, so the default key_size 
> > > > > of
> > > > > 0 is passed to the kvp daemon, and the pool files
> > > > > /var/lib/hyperv/.kvp_pool_* can't be updated.
> > > > >
> > > > > This patch effectively rolls back the previous fc62c3b1977d, and
> > > > > correctly fixes the "this statement may fall through" warnings.
> > > > >
> > > > > This patch is tested on WS 2012 R2 and 2016.
> > > > >
> > > > > Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may 
> > > > > fall
> > > > through" warnings")
> > > > > Signed-off-by: Dexuan Cui 
> > > > > Cc: K. Y. Srinivasan 
> > > > > Cc: Haiyang Zhang 
> > > > > Cc: Stephen Hemminger 
> > > > > Cc: 
> > > > > Signed-off-by: K. Y. Srinivasan 
> > > > > ---
> > > > >  drivers/hv/hv_kvp.c | 26 ++
> > > > >  1 file changed, 22 insertions(+), 4 deletions(-)
> > > > >
> > > > Reviewed-by: Michael Kelley 
> > >
> > > Hi Greg,
> > > Can you please take a look at this patch?
> > 
> > Nope, I'm not the hv maintainer, they need to look at this and ack it,
> > not me :)
> > 
> > greg k-h
> 
> Hi Greg,
> KY has added his Signed-off-by in the mail.
> 
> I'll ask the other HV maintainers to take a look as well.

Ok, then I'll look at it after 4.20-rc1 is out, nothing I can do until
then anyway...

thanks,

greg k-h

Re: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

[gre...@linuxfoundation.org]

On Thu, Nov 01, 2018 at 07:22:28PM +, Dexuan Cui wrote:
> > From: gre...@linuxfoundation.org 
> > Sent: Thursday, November 1, 2018 11:57
> > To: Dexuan Cui 
> > 
> > On Wed, Oct 31, 2018 at 11:23:54PM +, Dexuan Cui wrote:
> > > > From: Michael Kelley 
> > > > Sent: Wednesday, October 24, 2018 08:38
> > > > From: k...@linuxonhyperv.com   Sent:
> > Wednesday,
> > > > October 17, 2018 10:10 PM
> > > > > From: Dexuan Cui 
> > > > >
> > > > > In kvp_send_key(), we do need call process_ib_ipinfo() if
> > > > > message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns
> > out
> > > > > the userland hv_kvp_daemon needs the info of operation, adapter_id
> > and
> > > > > addr_family. With the incorrect fc62c3b1977d, the host can't get the
> > > > > VM's IP via KVP.
> > > > >
> > > > > And, fc62c3b1977d added a "break;", but actually forgot to initialize
> > > > > the key_size/value in the case of KVP_OP_SET, so the default key_size 
> > > > > of
> > > > > 0 is passed to the kvp daemon, and the pool files
> > > > > /var/lib/hyperv/.kvp_pool_* can't be updated.
> > > > >
> > > > > This patch effectively rolls back the previous fc62c3b1977d, and
> > > > > correctly fixes the "this statement may fall through" warnings.
> > > > >
> > > > > This patch is tested on WS 2012 R2 and 2016.
> > > > >
> > > > > Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may 
> > > > > fall
> > > > through" warnings")
> > > > > Signed-off-by: Dexuan Cui 
> > > > > Cc: K. Y. Srinivasan 
> > > > > Cc: Haiyang Zhang 
> > > > > Cc: Stephen Hemminger 
> > > > > Cc: 
> > > > > Signed-off-by: K. Y. Srinivasan 
> > > > > ---
> > > > >  drivers/hv/hv_kvp.c | 26 ++
> > > > >  1 file changed, 22 insertions(+), 4 deletions(-)
> > > > >
> > > > Reviewed-by: Michael Kelley 
> > >
> > > Hi Greg,
> > > Can you please take a look at this patch?
> > 
> > Nope, I'm not the hv maintainer, they need to look at this and ack it,
> > not me :)
> > 
> > greg k-h
> 
> Hi Greg,
> KY has added his Signed-off-by in the mail.
> 
> I'll ask the other HV maintainers to take a look as well.

Ok, then I'll look at it after 4.20-rc1 is out, nothing I can do until
then anyway...

thanks,

greg k-h

[PATCH v2 1/3] x86: add support for Huawei WMI hotkeys.

[Ayman Bagabas]

This driver adds support for missing hotkeys on some Huawei laptops.
Currently, only Huawei Matebook X Pro is supported. The driver
recognizes the following keys: brightness keys, micmute, wlan, and
Huawei special key. The brightness keys are ignored since they work out
of the box.

Signed-off-by: Ayman Bagabas 
---
 drivers/platform/x86/Kconfig  |  13 ++
 drivers/platform/x86/Makefile |   1 +
 drivers/platform/x86/huawei_wmi.c | 223 ++
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/platform/x86/huawei_wmi.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 0c1aa6c314f5..c6813981e45c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1229,6 +1229,19 @@ config I2C_MULTI_INSTANTIATE
  To compile this driver as a module, choose M here: the module
  will be called i2c-multi-instantiate.
 
+config HUAWEI_LAPTOP
+   tristate "Huawei WMI hotkeys driver"
+   depends on ACPI
+   depends on ACPI_WMI
+   depends on INPUT
+   select INPUT_SPARSEKMAP
+   help
+ This driver provides support for Huawei WMI hotkeys.
+ It enables the missing keys and adds support to micmute
+ led found on these laptops.q
+ Supported devices are:
+ - Matebook X Pro
+
 endif # X86_PLATFORM_DEVICES
 
 config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index e6d1becf81ce..5984354e18ff 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ACERHDF) += acerhdf.o
 obj-$(CONFIG_HP_ACCEL) += hp_accel.o
 obj-$(CONFIG_HP_WIRELESS)  += hp-wireless.o
 obj-$(CONFIG_HP_WMI)   += hp-wmi.o
+obj-$(CONFIG_HUAWEI_LAPTOP)+= huawei_wmi.o
 obj-$(CONFIG_AMILO_RFKILL) += amilo-rfkill.o
 obj-$(CONFIG_GPD_POCKET_FAN)   += gpd-pocket-fan.o
 obj-$(CONFIG_TC1100_WMI)   += tc1100-wmi.o
diff --git a/drivers/platform/x86/huawei_wmi.c 
b/drivers/platform/x86/huawei_wmi.c
new file mode 100644
index ..83545217ac19
--- /dev/null
+++ b/drivers/platform/x86/huawei_wmi.c
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Huawei WMI Hotkeys Driver
+ *
+ *  Copyright (C) 2018   Ayman Bagabas 
+ *
+ *  This program is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program.  If not, see .
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("Ayman Bagabas ");
+MODULE_DESCRIPTION("Huawei WMI hotkeys");
+MODULE_LICENSE("GPL");
+
+#define DEVICE_NAME "huawei"
+#define MODULE_NAME DEVICE_NAME"_wmi"
+
+/*
+ * Huawei WMI Devices GUIDs
+ */
+#define AMW0_GUID "ABBC0F5B-8EA1-11D1-A000-C9062910" // \_SB.AMW0
+
+/*
+ * Huawei WMI Events GUIDs
+ */
+#define EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+
+MODULE_ALIAS("wmi:"AMW0_GUID);
+MODULE_ALIAS("wmi:"EVENT_GUID);
+
+enum {
+   MICMUTE_LED_ON = 0x00010B04,
+   MICMUTE_LED_OFF = 0x0B04,
+};
+
+static const struct key_entry huawei_wmi_keymap[] __initconst = {
+   { KE_IGNORE, 0x281, { KEY_BRIGHTNESSDOWN } },
+   { KE_IGNORE, 0x282, { KEY_BRIGHTNESSUP } },
+   { KE_KEY,   0x287, { KEY_MICMUTE } },
+   { KE_KEY,   0x289, { KEY_WLAN } },
+   // Huawei |M| button
+   { KE_KEY,   0x28a, { KEY_PROG1 } },
+   { KE_END,   0 }
+};
+
+struct huawei_wmi_device {
+   struct input_dev *inputdev;
+};
+static struct huawei_wmi_device *wmi_device;
+
+int huawei_wmi_micmute_led_set(bool on)
+{
+   u32 args = (on) ? MICMUTE_LED_ON : MICMUTE_LED_OFF;
+   struct acpi_buffer input = { (acpi_size)sizeof(args),  };
+   acpi_status status;
+
+   status = wmi_evaluate_method(AMW0_GUID, 0, 1, , NULL);
+   if (ACPI_FAILURE(status))
+   return status;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(huawei_wmi_micmute_led_set);
+
+static void huawei_wmi_process_key(struct input_dev *input_dev, int code)
+{
+   const struct key_entry *key;
+
+   key = sparse_keymap_entry_from_scancode(input_dev, code);
+
+   if (!key) {
+   pr_info("%s: Unknown key pressed, code: 0x%04x\n",
+   MODULE_NAME, code);
+   return;
+   }
+
+   sparse_keymap_report_entry(input_dev, key, 1, 

[PATCH v2 0/3] Huawei laptops WMI & sound fixes

[Ayman Bagabas]

This patch set fixes some of the issues with Huawei laptops. 

[PATCH v2 1/3] 
The first patch adds support for missing hotkeys on some models. Some hotkeys,
like brightness keys, work out of the box on these models.

[PATCH v2 2/3]
This one enables the front speakers on the Huawei Matebook X Pro (MBXP). This
solves bug 200501 https://bugzilla.kernel.org/show_bug.cgi?id=200501
It simply uses the pins configurations generated by hdajackretast using the
settings posted on the bug page https://imgur.com/a/N1xsCVZ

[PATCH v2 3/3]
This enables the micmute LED on Huawei laptops. It calls an WMI method, using
PATCH #1, to turn the micmute LED on/off.

Ayman Bagabas (3):
  x86: add support for Huawei WMI hotkeys.
  ALSA: hda: fix front speakers on Huawei MBXP.
  ALSA: hda: add support for Huawei WMI MicMute LED

 drivers/platform/x86/Kconfig  |  13 ++
 drivers/platform/x86/Makefile |   1 +
 drivers/platform/x86/huawei_wmi.c | 224 ++
 include/linux/huawei_wmi.h|   7 +
 sound/pci/hda/huawei_wmi_helper.c |  48 +++
 sound/pci/hda/patch_realtek.c |  28 
 6 files changed, 321 insertions(+)
 create mode 100644 drivers/platform/x86/huawei_wmi.c
 create mode 100644 include/linux/huawei_wmi.h
 create mode 100644 sound/pci/hda/huawei_wmi_helper.c

-- 
2.17.2

[PATCH v2 3/3] ALSA: hda: add support for Huawei WMI MicMute LED

[Ayman Bagabas]

Some of Huawei laptops come with a LED in the mic mute key. This patch
enables and disable this LED accordingly.

Signed-off-by: Ayman Bagabas 
---
 drivers/platform/x86/huawei_wmi.c |  1 +
 include/linux/huawei_wmi.h|  7 +
 sound/pci/hda/huawei_wmi_helper.c | 48 +++
 sound/pci/hda/patch_realtek.c | 10 +++
 4 files changed, 66 insertions(+)
 create mode 100644 include/linux/huawei_wmi.h
 create mode 100644 sound/pci/hda/huawei_wmi_helper.c

diff --git a/drivers/platform/x86/huawei_wmi.c 
b/drivers/platform/x86/huawei_wmi.c
index 83545217ac19..cc5492571727 100644
--- a/drivers/platform/x86/huawei_wmi.c
+++ b/drivers/platform/x86/huawei_wmi.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("Ayman Bagabas ");
 MODULE_DESCRIPTION("Huawei WMI hotkeys");
diff --git a/include/linux/huawei_wmi.h b/include/linux/huawei_wmi.h
new file mode 100644
index ..69b656c5029b
--- /dev/null
+++ b/include/linux/huawei_wmi.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __HUAWEI_WMI_H__
+#define __HUAWEI_WMI_H__
+
+int huawei_wmi_micmute_led_set(bool on);
+
+#endif
diff --git a/sound/pci/hda/huawei_wmi_helper.c 
b/sound/pci/hda/huawei_wmi_helper.c
new file mode 100644
index ..77edb658cbf0
--- /dev/null
+++ b/sound/pci/hda/huawei_wmi_helper.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Helper functions for Huawei WMI Mic Mute LED;
+ * to be included from codec driver
+ */
+
+#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP)
+#include 
+
+static int (*huawei_wmi_micmute_led_set_func)(bool);
+
+static void update_huawei_wmi_micmute_led(struct hda_codec *codec)
+{
+   struct hda_gen_spec *spec = codec->spec;
+
+   huawei_wmi_micmute_led_set_func(spec->micmute_led.led_value);
+}
+
+static void alc_fixup_huawei_wmi(struct hda_codec *codec,
+  const struct hda_fixup *fix, int action)
+{
+   bool removefunc = false;
+
+   if (action == HDA_FIXUP_ACT_PROBE) {
+   if (!huawei_wmi_micmute_led_set_func)
+   huawei_wmi_micmute_led_set_func = 
symbol_request(huawei_wmi_micmute_led_set);
+   if (!huawei_wmi_micmute_led_set_func) {
+   codec_warn(codec, "Failed to find huawei_wmi symbol 
huawei_wmi_micmute_led_set\n");
+   return;
+   }
+   removefunc = (huawei_wmi_micmute_led_set_func(false) < 0)
+   || (snd_hda_gen_add_micmute_led(codec, 
update_huawei_wmi_micmute_led) < 0);
+
+   }
+
+   if (huawei_wmi_micmute_led_set_func && (action == HDA_FIXUP_ACT_FREE || 
removefunc)) {
+   symbol_put(huawei_wmi_micmute_led_set);
+   huawei_wmi_micmute_led_set_func = NULL;
+   }
+}
+
+#else
+
+static void alc_fixup_huawei_wmi(struct hda_codec *codec,
+   const struct hda_fixup *fix, int action)
+{
+}
+
+#endif
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4f7a39c7883c..d09457d2a4f3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5374,6 +5374,9 @@ static void alc_fixup_thinkpad_acpi(struct hda_codec 
*codec,
 /* for alc295_fixup_hp_top_speakers */
 #include "hp_x360_helper.c"
 
+/* for alc_fixup_huawei_micmute_led */
+#include "huawei_wmi_helper.c"
+
 enum {
ALC269_FIXUP_SONY_VAIO,
ALC275_FIXUP_SONY_VAIO_GPIO2,
@@ -5494,6 +5497,7 @@ enum {
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
ALC256_FIXUP_HUAWEI_MBXP_PINS,
+   ALC256_FIXUP_HUAWEI_WMI_MICMUTE_LED,
ALC295_FIXUP_HP_X360,
ALC221_FIXUP_HP_HEADSET_MIC,
 };
@@ -6348,6 +6352,10 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+   [ALC256_FIXUP_HUAWEI_WMI_MICMUTE_LED] = {
+   .type = HDA_FIXUP_FUNC,
+   .v.func = alc_fixup_huawei_wmi
+   },
[ALC256_FIXUP_HUAWEI_MBXP_PINS] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
@@ -6363,6 +6371,8 @@ static const struct hda_fixup alc269_fixups[] = {
{0x21, 0x04211020},
{ },
},
+   .chained = true,
+   .chain_id = ALC256_FIXUP_HUAWEI_WMI_MICMUTE_LED
},
[ALC295_FIXUP_HP_X360] = {
.type = HDA_FIXUP_FUNC,
-- 
2.17.2

[PATCH v2 1/3] x86: add support for Huawei WMI hotkeys.

[Ayman Bagabas]

This driver adds support for missing hotkeys on some Huawei laptops.
Currently, only Huawei Matebook X Pro is supported. The driver
recognizes the following keys: brightness keys, micmute, wlan, and
Huawei special key. The brightness keys are ignored since they work out
of the box.

Signed-off-by: Ayman Bagabas 
---
 drivers/platform/x86/Kconfig  |  13 ++
 drivers/platform/x86/Makefile |   1 +
 drivers/platform/x86/huawei_wmi.c | 223 ++
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/platform/x86/huawei_wmi.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 0c1aa6c314f5..c6813981e45c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1229,6 +1229,19 @@ config I2C_MULTI_INSTANTIATE
  To compile this driver as a module, choose M here: the module
  will be called i2c-multi-instantiate.
 
+config HUAWEI_LAPTOP
+   tristate "Huawei WMI hotkeys driver"
+   depends on ACPI
+   depends on ACPI_WMI
+   depends on INPUT
+   select INPUT_SPARSEKMAP
+   help
+ This driver provides support for Huawei WMI hotkeys.
+ It enables the missing keys and adds support to micmute
+ led found on these laptops.q
+ Supported devices are:
+ - Matebook X Pro
+
 endif # X86_PLATFORM_DEVICES
 
 config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index e6d1becf81ce..5984354e18ff 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ACERHDF) += acerhdf.o
 obj-$(CONFIG_HP_ACCEL) += hp_accel.o
 obj-$(CONFIG_HP_WIRELESS)  += hp-wireless.o
 obj-$(CONFIG_HP_WMI)   += hp-wmi.o
+obj-$(CONFIG_HUAWEI_LAPTOP)+= huawei_wmi.o
 obj-$(CONFIG_AMILO_RFKILL) += amilo-rfkill.o
 obj-$(CONFIG_GPD_POCKET_FAN)   += gpd-pocket-fan.o
 obj-$(CONFIG_TC1100_WMI)   += tc1100-wmi.o
diff --git a/drivers/platform/x86/huawei_wmi.c 
b/drivers/platform/x86/huawei_wmi.c
new file mode 100644
index ..83545217ac19
--- /dev/null
+++ b/drivers/platform/x86/huawei_wmi.c
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Huawei WMI Hotkeys Driver
+ *
+ *  Copyright (C) 2018   Ayman Bagabas 
+ *
+ *  This program is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program.  If not, see .
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("Ayman Bagabas ");
+MODULE_DESCRIPTION("Huawei WMI hotkeys");
+MODULE_LICENSE("GPL");
+
+#define DEVICE_NAME "huawei"
+#define MODULE_NAME DEVICE_NAME"_wmi"
+
+/*
+ * Huawei WMI Devices GUIDs
+ */
+#define AMW0_GUID "ABBC0F5B-8EA1-11D1-A000-C9062910" // \_SB.AMW0
+
+/*
+ * Huawei WMI Events GUIDs
+ */
+#define EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+
+MODULE_ALIAS("wmi:"AMW0_GUID);
+MODULE_ALIAS("wmi:"EVENT_GUID);
+
+enum {
+   MICMUTE_LED_ON = 0x00010B04,
+   MICMUTE_LED_OFF = 0x0B04,
+};
+
+static const struct key_entry huawei_wmi_keymap[] __initconst = {
+   { KE_IGNORE, 0x281, { KEY_BRIGHTNESSDOWN } },
+   { KE_IGNORE, 0x282, { KEY_BRIGHTNESSUP } },
+   { KE_KEY,   0x287, { KEY_MICMUTE } },
+   { KE_KEY,   0x289, { KEY_WLAN } },
+   // Huawei |M| button
+   { KE_KEY,   0x28a, { KEY_PROG1 } },
+   { KE_END,   0 }
+};
+
+struct huawei_wmi_device {
+   struct input_dev *inputdev;
+};
+static struct huawei_wmi_device *wmi_device;
+
+int huawei_wmi_micmute_led_set(bool on)
+{
+   u32 args = (on) ? MICMUTE_LED_ON : MICMUTE_LED_OFF;
+   struct acpi_buffer input = { (acpi_size)sizeof(args),  };
+   acpi_status status;
+
+   status = wmi_evaluate_method(AMW0_GUID, 0, 1, , NULL);
+   if (ACPI_FAILURE(status))
+   return status;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(huawei_wmi_micmute_led_set);
+
+static void huawei_wmi_process_key(struct input_dev *input_dev, int code)
+{
+   const struct key_entry *key;
+
+   key = sparse_keymap_entry_from_scancode(input_dev, code);
+
+   if (!key) {
+   pr_info("%s: Unknown key pressed, code: 0x%04x\n",
+   MODULE_NAME, code);
+   return;
+   }
+
+   sparse_keymap_report_entry(input_dev, key, 1, 

[PATCH v2 0/3] Huawei laptops WMI & sound fixes

[Ayman Bagabas]

This patch set fixes some of the issues with Huawei laptops. 

[PATCH v2 1/3] 
The first patch adds support for missing hotkeys on some models. Some hotkeys,
like brightness keys, work out of the box on these models.

[PATCH v2 2/3]
This one enables the front speakers on the Huawei Matebook X Pro (MBXP). This
solves bug 200501 https://bugzilla.kernel.org/show_bug.cgi?id=200501
It simply uses the pins configurations generated by hdajackretast using the
settings posted on the bug page https://imgur.com/a/N1xsCVZ

[PATCH v2 3/3]
This enables the micmute LED on Huawei laptops. It calls an WMI method, using
PATCH #1, to turn the micmute LED on/off.

Ayman Bagabas (3):
  x86: add support for Huawei WMI hotkeys.
  ALSA: hda: fix front speakers on Huawei MBXP.
  ALSA: hda: add support for Huawei WMI MicMute LED

 drivers/platform/x86/Kconfig  |  13 ++
 drivers/platform/x86/Makefile |   1 +
 drivers/platform/x86/huawei_wmi.c | 224 ++
 include/linux/huawei_wmi.h|   7 +
 sound/pci/hda/huawei_wmi_helper.c |  48 +++
 sound/pci/hda/patch_realtek.c |  28 
 6 files changed, 321 insertions(+)
 create mode 100644 drivers/platform/x86/huawei_wmi.c
 create mode 100644 include/linux/huawei_wmi.h
 create mode 100644 sound/pci/hda/huawei_wmi_helper.c

-- 
2.17.2

[PATCH v2 3/3] ALSA: hda: add support for Huawei WMI MicMute LED

[Ayman Bagabas]

Some of Huawei laptops come with a LED in the mic mute key. This patch
enables and disable this LED accordingly.

Signed-off-by: Ayman Bagabas 
---
 drivers/platform/x86/huawei_wmi.c |  1 +
 include/linux/huawei_wmi.h|  7 +
 sound/pci/hda/huawei_wmi_helper.c | 48 +++
 sound/pci/hda/patch_realtek.c | 10 +++
 4 files changed, 66 insertions(+)
 create mode 100644 include/linux/huawei_wmi.h
 create mode 100644 sound/pci/hda/huawei_wmi_helper.c

diff --git a/drivers/platform/x86/huawei_wmi.c 
b/drivers/platform/x86/huawei_wmi.c
index 83545217ac19..cc5492571727 100644
--- a/drivers/platform/x86/huawei_wmi.c
+++ b/drivers/platform/x86/huawei_wmi.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("Ayman Bagabas ");
 MODULE_DESCRIPTION("Huawei WMI hotkeys");
diff --git a/include/linux/huawei_wmi.h b/include/linux/huawei_wmi.h
new file mode 100644
index ..69b656c5029b
--- /dev/null
+++ b/include/linux/huawei_wmi.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __HUAWEI_WMI_H__
+#define __HUAWEI_WMI_H__
+
+int huawei_wmi_micmute_led_set(bool on);
+
+#endif
diff --git a/sound/pci/hda/huawei_wmi_helper.c 
b/sound/pci/hda/huawei_wmi_helper.c
new file mode 100644
index ..77edb658cbf0
--- /dev/null
+++ b/sound/pci/hda/huawei_wmi_helper.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Helper functions for Huawei WMI Mic Mute LED;
+ * to be included from codec driver
+ */
+
+#if IS_ENABLED(CONFIG_HUAWEI_LAPTOP)
+#include 
+
+static int (*huawei_wmi_micmute_led_set_func)(bool);
+
+static void update_huawei_wmi_micmute_led(struct hda_codec *codec)
+{
+   struct hda_gen_spec *spec = codec->spec;
+
+   huawei_wmi_micmute_led_set_func(spec->micmute_led.led_value);
+}
+
+static void alc_fixup_huawei_wmi(struct hda_codec *codec,
+  const struct hda_fixup *fix, int action)
+{
+   bool removefunc = false;
+
+   if (action == HDA_FIXUP_ACT_PROBE) {
+   if (!huawei_wmi_micmute_led_set_func)
+   huawei_wmi_micmute_led_set_func = 
symbol_request(huawei_wmi_micmute_led_set);
+   if (!huawei_wmi_micmute_led_set_func) {
+   codec_warn(codec, "Failed to find huawei_wmi symbol 
huawei_wmi_micmute_led_set\n");
+   return;
+   }
+   removefunc = (huawei_wmi_micmute_led_set_func(false) < 0)
+   || (snd_hda_gen_add_micmute_led(codec, 
update_huawei_wmi_micmute_led) < 0);
+
+   }
+
+   if (huawei_wmi_micmute_led_set_func && (action == HDA_FIXUP_ACT_FREE || 
removefunc)) {
+   symbol_put(huawei_wmi_micmute_led_set);
+   huawei_wmi_micmute_led_set_func = NULL;
+   }
+}
+
+#else
+
+static void alc_fixup_huawei_wmi(struct hda_codec *codec,
+   const struct hda_fixup *fix, int action)
+{
+}
+
+#endif
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4f7a39c7883c..d09457d2a4f3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5374,6 +5374,9 @@ static void alc_fixup_thinkpad_acpi(struct hda_codec 
*codec,
 /* for alc295_fixup_hp_top_speakers */
 #include "hp_x360_helper.c"
 
+/* for alc_fixup_huawei_micmute_led */
+#include "huawei_wmi_helper.c"
+
 enum {
ALC269_FIXUP_SONY_VAIO,
ALC275_FIXUP_SONY_VAIO_GPIO2,
@@ -5494,6 +5497,7 @@ enum {
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
ALC256_FIXUP_HUAWEI_MBXP_PINS,
+   ALC256_FIXUP_HUAWEI_WMI_MICMUTE_LED,
ALC295_FIXUP_HP_X360,
ALC221_FIXUP_HP_HEADSET_MIC,
 };
@@ -6348,6 +6352,10 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+   [ALC256_FIXUP_HUAWEI_WMI_MICMUTE_LED] = {
+   .type = HDA_FIXUP_FUNC,
+   .v.func = alc_fixup_huawei_wmi
+   },
[ALC256_FIXUP_HUAWEI_MBXP_PINS] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
@@ -6363,6 +6371,8 @@ static const struct hda_fixup alc269_fixups[] = {
{0x21, 0x04211020},
{ },
},
+   .chained = true,
+   .chain_id = ALC256_FIXUP_HUAWEI_WMI_MICMUTE_LED
},
[ALC295_FIXUP_HP_X360] = {
.type = HDA_FIXUP_FUNC,
-- 
2.17.2

[PATCH v2 2/3] ALSA: hda: fix front speakers on Huawei MBXP.

[Ayman Bagabas]

This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
https://bugzilla.kernel.org/show_bug.cgi?id=200501
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.

Signed-off-by: Ayman Bagabas 
---
 sound/pci/hda/patch_realtek.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 3ac7ba9b342d..4f7a39c7883c 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5493,6 +5493,7 @@ enum {
ALC298_FIXUP_TPT470_DOCK,
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
+   ALC256_FIXUP_HUAWEI_MBXP_PINS,
ALC295_FIXUP_HP_X360,
ALC221_FIXUP_HP_HEADSET_MIC,
 };
@@ -6347,6 +6348,22 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+   [ALC256_FIXUP_HUAWEI_MBXP_PINS] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   {0x12, 0x90a60130},
+   {0x13, 0x4000},
+   {0x14, 0x90170110},
+   {0x18, 0x41f0},
+   {0x19, 0x04a11040},
+   {0x1a, 0x41f0},
+   {0x1b, 0x90170112},
+   {0x1d, 0x40759a05},
+   {0x1e, 0x41f0},
+   {0x21, 0x04211020},
+   { },
+   },
+   },
[ALC295_FIXUP_HP_X360] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc295_fixup_hp_top_speakers,
@@ -6592,6 +6609,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x5109, "Thinkpad", 
ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
SND_PCI_QUIRK(0x17aa, 0x511e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
+   SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP", 
ALC256_FIXUP_HUAWEI_MBXP_PINS),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", 
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
-- 
2.17.2

[PATCH v2 2/3] ALSA: hda: fix front speakers on Huawei MBXP.

[Ayman Bagabas]

This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
https://bugzilla.kernel.org/show_bug.cgi?id=200501
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.

Signed-off-by: Ayman Bagabas 
---
 sound/pci/hda/patch_realtek.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 3ac7ba9b342d..4f7a39c7883c 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5493,6 +5493,7 @@ enum {
ALC298_FIXUP_TPT470_DOCK,
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
+   ALC256_FIXUP_HUAWEI_MBXP_PINS,
ALC295_FIXUP_HP_X360,
ALC221_FIXUP_HP_HEADSET_MIC,
 };
@@ -6347,6 +6348,22 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+   [ALC256_FIXUP_HUAWEI_MBXP_PINS] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   {0x12, 0x90a60130},
+   {0x13, 0x4000},
+   {0x14, 0x90170110},
+   {0x18, 0x41f0},
+   {0x19, 0x04a11040},
+   {0x1a, 0x41f0},
+   {0x1b, 0x90170112},
+   {0x1d, 0x40759a05},
+   {0x1e, 0x41f0},
+   {0x21, 0x04211020},
+   { },
+   },
+   },
[ALC295_FIXUP_HP_X360] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc295_fixup_hp_top_speakers,
@@ -6592,6 +6609,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x5109, "Thinkpad", 
ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
SND_PCI_QUIRK(0x17aa, 0x511e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
+   SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP", 
ALC256_FIXUP_HUAWEI_MBXP_PINS),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", 
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
-- 
2.17.2

Re: [git pull] mount API series

[Al Viro]

On Thu, Nov 01, 2018 at 11:59:23PM +, David Howells wrote:

>  (*) mount-api-core.  These are the internal-only patches that add the
>  fs_context, the legacy wrapper and the security hooks and make certain
>  filesystems make use of it.

FWIW, while rereading that series I'd spotted something very odd in erofs.
It's orthogonal to everything else, but just to make sure it doesn't get
lost:
* sbi->dev_name thing in erofs is used only for debugging printks,
basically.  Just use sb->s_id[] and be done with that.
* dump struct erofs_mount_private - you don't need dev_name in
your erofs_fill_super().  Just use mount_bdev() in usual fashion.
* what the hell are you doing with ->s_root???  Why would you
possibly want it hashed and what kind of dcache lookup could find it?
That d_rehash() looks deeply confused; what are you trying to do there?

Re: [git pull] mount API series

[Al Viro]

On Thu, Nov 01, 2018 at 11:59:23PM +, David Howells wrote:

>  (*) mount-api-core.  These are the internal-only patches that add the
>  fs_context, the legacy wrapper and the security hooks and make certain
>  filesystems make use of it.

FWIW, while rereading that series I'd spotted something very odd in erofs.
It's orthogonal to everything else, but just to make sure it doesn't get
lost:
* sbi->dev_name thing in erofs is used only for debugging printks,
basically.  Just use sb->s_id[] and be done with that.
* dump struct erofs_mount_private - you don't need dev_name in
your erofs_fill_super().  Just use mount_bdev() in usual fashion.
* what the hell are you doing with ->s_root???  Why would you
possibly want it hashed and what kind of dcache lookup could find it?
That d_rehash() looks deeply confused; what are you trying to do there?

Re: [PATCH] memory_hotplug: cond_resched in __remove_pages

[Balbir Singh]

On Wed, Oct 31, 2018 at 01:58:40PM +0100, Michal Hocko wrote:
> From: Michal Hocko 
> 
> We have received a bug report that unbinding a large pmem (>1TB)
> can result in a soft lockup:
> [  380.339203] NMI watchdog: BUG: soft lockup - CPU#9 stuck for 23s! 
> [ndctl:4365]
> [...]
> [  380.339316] Supported: Yes
> [  380.339318] CPU: 9 PID: 4365 Comm: ndctl Not tainted 4.12.14-94.40-default 
> #1 SLE12-SP4
> [  380.339318] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS 
> SE5C620.86B.01.00.0833.051120182255 05/11/2018
> [  380.339319] task: 9cce7d4410c0 task.stack: be9eb1bc4000
> [  380.339325] RIP: 0010:__put_page+0x62/0x80
> [  380.339326] RSP: 0018:be9eb1bc7d30 EFLAGS: 0282 ORIG_RAX: 
> ff10
> [  380.339327] RAX: 40540081c0d3 RBX: eb8f03557200 RCX: 
> 63af4000
> [  380.339328] RDX: 0002 RSI: 9cce75bff498 RDI: 
> 9e4a76072ff8
> [  380.339329] RBP: 000a43557200 R08:  R09: 
> be9eb1bc7bb0
> [  380.339329] R10: be9eb1bc7d08 R11:  R12: 
> 9e194a22a0e0
> [  380.339330] R13: 9cce7062fc10 R14: 9e194a22a0a0 R15: 
> 9cce6559c0e0
> [  380.339331] FS:  7fd132368880() GS:9cce7ea4() 
> knlGS:
> [  380.339332] CS:  0010 DS:  ES:  CR0: 80050033
> [  380.339332] CR2: 020820a0 CR3: 00017ef7a003 CR4: 
> 007606e0
> [  380.339333] DR0:  DR1:  DR2: 
> 
> [  380.339334] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [  380.339334] PKRU: 5554
> [  380.339334] Call Trace:
> [  380.339338]  devm_memremap_pages_release+0x152/0x260
> [  380.339342]  release_nodes+0x18d/0x1d0
> [  380.339347]  device_release_driver_internal+0x160/0x210
> [  380.339350]  unbind_store+0xb3/0xe0
> [  380.339355]  kernfs_fop_write+0x102/0x180
> [  380.339358]  __vfs_write+0x26/0x150
> [  380.339363]  ? security_file_permission+0x3c/0xc0
> [  380.339364]  vfs_write+0xad/0x1a0
> [  380.339366]  SyS_write+0x42/0x90
> [  380.339370]  do_syscall_64+0x74/0x150
> [  380.339375]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [  380.339377] RIP: 0033:0x7fd13166b3d0
> 
> It has been reported on an older (4.12) kernel but the current upstream
> code doesn't cond_resched in the hot remove code at all and the given
> range to remove might be really large. Fix the issue by calling cond_resched
> once per memory section.
> 
> Signed-off-by: Michal Hocko 
> ---
>  mm/memory_hotplug.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 7e6509a53d79..1d87724fa558 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -587,6 +587,7 @@ int __remove_pages(struct zone *zone, unsigned long 
> phys_start_pfn,
>   for (i = 0; i < sections_to_remove; i++) {
>   unsigned long pfn = phys_start_pfn + i*PAGES_PER_SECTION;
>  
> + cond_resched();
>   ret = __remove_section(zone, __pfn_to_section(pfn), map_offset,
>   altmap);
>   map_offset = 0;

Quick math tells me we're doing less than 44GiB's per second of offlining then?

Here is a quick untested patch that might help with the speed as well

In hot remove, we try to clear poisoned pages, but
a small optimization to check if num_poisoned_pages
is 0 helps remove the iteration through nr_pages.

NOTE: We can make num_poisoned_pages counter per
section and speed this up even more in case we
do have some poisoned pages

Signed-off-by: Balbir Singh 
---
 mm/sparse.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/sparse.c b/mm/sparse.c
index 33307fc05c4d..c4280ef0f383 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -724,6 +724,9 @@ static void clear_hwpoisoned_pages(struct page *memmap, int 
nr_pages)
if (!memmap)
return;
 
+   if (atomic_long_read(_poisoned_pages) == 0)
+   return;
+
for (i = 0; i < nr_pages; i++) {
if (PageHWPoison([i])) {
atomic_long_sub(1, _poisoned_pages);

Anyway for this patch:
Acked-by: Balbir Singh 

Re: [PATCH] memory_hotplug: cond_resched in __remove_pages

[Balbir Singh]

On Wed, Oct 31, 2018 at 01:58:40PM +0100, Michal Hocko wrote:
> From: Michal Hocko 
> 
> We have received a bug report that unbinding a large pmem (>1TB)
> can result in a soft lockup:
> [  380.339203] NMI watchdog: BUG: soft lockup - CPU#9 stuck for 23s! 
> [ndctl:4365]
> [...]
> [  380.339316] Supported: Yes
> [  380.339318] CPU: 9 PID: 4365 Comm: ndctl Not tainted 4.12.14-94.40-default 
> #1 SLE12-SP4
> [  380.339318] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS 
> SE5C620.86B.01.00.0833.051120182255 05/11/2018
> [  380.339319] task: 9cce7d4410c0 task.stack: be9eb1bc4000
> [  380.339325] RIP: 0010:__put_page+0x62/0x80
> [  380.339326] RSP: 0018:be9eb1bc7d30 EFLAGS: 0282 ORIG_RAX: 
> ff10
> [  380.339327] RAX: 40540081c0d3 RBX: eb8f03557200 RCX: 
> 63af4000
> [  380.339328] RDX: 0002 RSI: 9cce75bff498 RDI: 
> 9e4a76072ff8
> [  380.339329] RBP: 000a43557200 R08:  R09: 
> be9eb1bc7bb0
> [  380.339329] R10: be9eb1bc7d08 R11:  R12: 
> 9e194a22a0e0
> [  380.339330] R13: 9cce7062fc10 R14: 9e194a22a0a0 R15: 
> 9cce6559c0e0
> [  380.339331] FS:  7fd132368880() GS:9cce7ea4() 
> knlGS:
> [  380.339332] CS:  0010 DS:  ES:  CR0: 80050033
> [  380.339332] CR2: 020820a0 CR3: 00017ef7a003 CR4: 
> 007606e0
> [  380.339333] DR0:  DR1:  DR2: 
> 
> [  380.339334] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [  380.339334] PKRU: 5554
> [  380.339334] Call Trace:
> [  380.339338]  devm_memremap_pages_release+0x152/0x260
> [  380.339342]  release_nodes+0x18d/0x1d0
> [  380.339347]  device_release_driver_internal+0x160/0x210
> [  380.339350]  unbind_store+0xb3/0xe0
> [  380.339355]  kernfs_fop_write+0x102/0x180
> [  380.339358]  __vfs_write+0x26/0x150
> [  380.339363]  ? security_file_permission+0x3c/0xc0
> [  380.339364]  vfs_write+0xad/0x1a0
> [  380.339366]  SyS_write+0x42/0x90
> [  380.339370]  do_syscall_64+0x74/0x150
> [  380.339375]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [  380.339377] RIP: 0033:0x7fd13166b3d0
> 
> It has been reported on an older (4.12) kernel but the current upstream
> code doesn't cond_resched in the hot remove code at all and the given
> range to remove might be really large. Fix the issue by calling cond_resched
> once per memory section.
> 
> Signed-off-by: Michal Hocko 
> ---
>  mm/memory_hotplug.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 7e6509a53d79..1d87724fa558 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -587,6 +587,7 @@ int __remove_pages(struct zone *zone, unsigned long 
> phys_start_pfn,
>   for (i = 0; i < sections_to_remove; i++) {
>   unsigned long pfn = phys_start_pfn + i*PAGES_PER_SECTION;
>  
> + cond_resched();
>   ret = __remove_section(zone, __pfn_to_section(pfn), map_offset,
>   altmap);
>   map_offset = 0;

Quick math tells me we're doing less than 44GiB's per second of offlining then?

Here is a quick untested patch that might help with the speed as well

In hot remove, we try to clear poisoned pages, but
a small optimization to check if num_poisoned_pages
is 0 helps remove the iteration through nr_pages.

NOTE: We can make num_poisoned_pages counter per
section and speed this up even more in case we
do have some poisoned pages

Signed-off-by: Balbir Singh 
---
 mm/sparse.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/sparse.c b/mm/sparse.c
index 33307fc05c4d..c4280ef0f383 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -724,6 +724,9 @@ static void clear_hwpoisoned_pages(struct page *memmap, int 
nr_pages)
if (!memmap)
return;
 
+   if (atomic_long_read(_poisoned_pages) == 0)
+   return;
+
for (i = 0; i < nr_pages; i++) {
if (PageHWPoison([i])) {
atomic_long_sub(1, _poisoned_pages);

Anyway for this patch:
Acked-by: Balbir Singh 

Re: [PATCH v1 4/7] vfio: ap: AP Queue Interrupt Control VFIO ioctl calls

[kbuild test robot]

Hi Pierre,

I love your patch! Yet something to improve:

[auto build test ERROR on s390/features]
[also build test ERROR on next-20181101]
[cannot apply to v4.19]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pierre-Morel/s390-vfio-ap-Using-GISA-for-AP-Interrupt/20181102-010854
base:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=s390 

Note: the 
linux-review/Pierre-Morel/s390-vfio-ap-Using-GISA-for-AP-Interrupt/20181102-010854
 HEAD 1235cf4914e223e3da89385619976de8eea4e9db builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/s390/crypto/vfio_ap_ops.c: In function 'ap_ioctl_setirq':
>> drivers/s390/crypto/vfio_ap_ops.c:915:18: error: 'GAL_ISC' undeclared (first 
>> use in this function); did you mean 'MAX_ISC'?
 aqic_gisa.isc = GAL_ISC;
 ^~~
 MAX_ISC
   drivers/s390/crypto/vfio_ap_ops.c:915:18: note: each undeclared identifier 
is reported only once for each function it appears in

vim +915 drivers/s390/crypto/vfio_ap_ops.c

   897  
   898  static int ap_ioctl_setirq(struct ap_matrix_mdev *matrix_mdev,
   899 struct vfio_ap_aqic *parm)
   900  {
   901  struct aqic_gisa aqic_gisa = reg2aqic(0);
   902  struct kvm_s390_gisa *gisa = matrix_mdev->kvm->arch.gisa;
   903  struct ap_status ap_status = reg2status(0);
   904  unsigned long p;
   905  int ret = -1;
   906  int apqn;
   907  uint32_t gd;
   908  
   909  apqn = (int)(parm->cmd & 0x);
   910  
   911  gd = matrix_mdev->kvm->vcpus[0]->arch.sie_block->gd;
   912  if (gd & 0x01)
   913  aqic_gisa.f = 1;
   914  aqic_gisa.gisc = matrix_mdev->gisc;
 > 915  aqic_gisa.isc = GAL_ISC;
   916  aqic_gisa.ir = 1;
   917  aqic_gisa.gisao = gisa->next_alert >> 4;
   918  
   919  p = (unsigned long) page_address(matrix_mdev->map->page);
   920  p += (matrix_mdev->map->guest_addr & 0x0fff);
   921  
   922  ret = ap_host_aqic((uint64_t)apqn, aqic2reg(aqic_gisa), p);
   923  parm->status = ret;
   924  
   925  ap_status = reg2status(ret);
   926  return (ap_status.rc) ? -EIO : 0;
   927  }
   928  

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


.config.gz
Description: application/gzip

Re: [PATCH v1 4/7] vfio: ap: AP Queue Interrupt Control VFIO ioctl calls

[kbuild test robot]

Hi Pierre,

I love your patch! Yet something to improve:

[auto build test ERROR on s390/features]
[also build test ERROR on next-20181101]
[cannot apply to v4.19]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pierre-Morel/s390-vfio-ap-Using-GISA-for-AP-Interrupt/20181102-010854
base:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=s390 

Note: the 
linux-review/Pierre-Morel/s390-vfio-ap-Using-GISA-for-AP-Interrupt/20181102-010854
 HEAD 1235cf4914e223e3da89385619976de8eea4e9db builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/s390/crypto/vfio_ap_ops.c: In function 'ap_ioctl_setirq':
>> drivers/s390/crypto/vfio_ap_ops.c:915:18: error: 'GAL_ISC' undeclared (first 
>> use in this function); did you mean 'MAX_ISC'?
 aqic_gisa.isc = GAL_ISC;
 ^~~
 MAX_ISC
   drivers/s390/crypto/vfio_ap_ops.c:915:18: note: each undeclared identifier 
is reported only once for each function it appears in

vim +915 drivers/s390/crypto/vfio_ap_ops.c

   897  
   898  static int ap_ioctl_setirq(struct ap_matrix_mdev *matrix_mdev,
   899 struct vfio_ap_aqic *parm)
   900  {
   901  struct aqic_gisa aqic_gisa = reg2aqic(0);
   902  struct kvm_s390_gisa *gisa = matrix_mdev->kvm->arch.gisa;
   903  struct ap_status ap_status = reg2status(0);
   904  unsigned long p;
   905  int ret = -1;
   906  int apqn;
   907  uint32_t gd;
   908  
   909  apqn = (int)(parm->cmd & 0x);
   910  
   911  gd = matrix_mdev->kvm->vcpus[0]->arch.sie_block->gd;
   912  if (gd & 0x01)
   913  aqic_gisa.f = 1;
   914  aqic_gisa.gisc = matrix_mdev->gisc;
 > 915  aqic_gisa.isc = GAL_ISC;
   916  aqic_gisa.ir = 1;
   917  aqic_gisa.gisao = gisa->next_alert >> 4;
   918  
   919  p = (unsigned long) page_address(matrix_mdev->map->page);
   920  p += (matrix_mdev->map->guest_addr & 0x0fff);
   921  
   922  ret = ap_host_aqic((uint64_t)apqn, aqic2reg(aqic_gisa), p);
   923  parm->status = ret;
   924  
   925  ap_status = reg2status(ret);
   926  return (ap_status.rc) ? -EIO : 0;
   927  }
   928  

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


.config.gz
Description: application/gzip

[PATCH] driver: input: fix UBSAN warning in input_defuzz_abs_event

[liujian]

syzkaller triggered a UBCAN warning:

[  196.188950] UBSAN: Undefined behaviour in drivers/input/input.c:62:23
[  196.188958] signed integer overflow:
[  196.188964] -2147483647 - 104 cannot be represented in type 'int [2]'
[  196.188973] CPU: 7 PID: 4763 Comm: syz-executor Not tainted
4.19.0-514.55.6.9.x86_64+ #7
[  196.188977] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  196.188979] Call Trace:
[  196.189001]  dump_stack+0x91/0xeb
[  196.189014]  ubsan_epilogue+0x9/0x7c
[  196.189020]  handle_overflow+0x1d7/0x22c
[  196.189028]  ? __ubsan_handle_negate_overflow+0x18f/0x18f
[  196.189038]  ? __mutex_lock+0x213/0x13f0
[  196.189053]  ? drop_futex_key_refs+0xa0/0xa0
[  196.189070]  ? __might_fault+0xef/0x1b0
[  196.189096]  input_handle_event+0xe1b/0x1290
[  196.189108]  input_inject_event+0x1d7/0x27e
[  196.189119]  evdev_write+0x2cf/0x3f0
[  196.189129]  ? evdev_pass_values+0xd40/0xd40
[  196.189157]  ? mark_held_locks+0x160/0x160
[  196.189171]  ? __vfs_write+0xe0/0x6c0
[  196.189175]  ? evdev_pass_values+0xd40/0xd40
[  196.189179]  __vfs_write+0xe0/0x6c0
[  196.189186]  ? kernel_read+0x130/0x130
[  196.189204]  ? _cond_resched+0x15/0x30
[  196.189214]  ? __inode_security_revalidate+0xb8/0xe0
[  196.189222]  ? selinux_file_permission+0x354/0x430
[  196.189233]  vfs_write+0x160/0x440
[  196.189242]  ksys_write+0xc1/0x190
[  196.189248]  ? __ia32_sys_read+0xb0/0xb0
[  196.189259]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  196.189267]  ? do_syscall_64+0x22/0x4a0
[  196.189276]  do_syscall_64+0xa5/0x4a0
[  196.189287]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  196.189293] RIP: 0033:0x44e7c9
[  196.189299] Code: fc ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00

the syzkaller reproduce script(but can't reproduce it every time):

r0 = syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2,
0x1)
write$binfmt_elf64(r0, &(0x7f000240)={{0x7f, 0x45, 0x4c, 0x46, 0x40,
0x2, 0x2, 0x, 0x374c, 0x3, 0x0, 0x8001, 0x103,
0x40, 0x22e, 0x26, 0x1, 0x38, 0x2, 0xa23, 0x1, 0x2}, [{0x6474e557, 0x5,
0x6, 0x2, 0x9, 0x9, 0x6c3, 0x1ff}], "", [[], [], [], []]}, 0x478)
ioctl$EVIOCGSW(0x, 0x8040451b, &(0x7f40)=""/7)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)
r1 = syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2,
0x1)
openat$smack_task_current(0xff9c,
&(0x7f40)='/proc/self/attr/current\x00', 0x2, 0x0)
ioctl$EVIOCSABS0(r1, 0x401845c0, &(0x7f00)={0x4, 0x1, 0x4,
0xd1, 0x81, 0x3})
eventfd(0x1ff)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2,
0x200)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)

Typecast int to long to fix the issue.

Signed-off-by: liujian 
---
 drivers/input/input.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 3304aaa..24615ef 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -59,14 +59,17 @@ static inline int is_event_supported(unsigned int code,
 static int input_defuzz_abs_event(int value, int old_val, int fuzz)
 {
if (fuzz) {
-   if (value > old_val - fuzz / 2 && value < old_val + fuzz / 2)
+   if (value > (long)old_val - fuzz / 2 &&
+   value < (long)old_val + fuzz / 2)
return old_val;
 
-   if (value > old_val - fuzz && value < old_val + fuzz)
-   return (old_val * 3 + value) / 4;
+   if (value > (long)old_val - fuzz &&
+   value < (long)old_val + fuzz)
+   return ((long)old_val * 3 + value) / 4;
 
-   if (value > old_val - fuzz * 2 && value < old_val + fuzz * 2)
-   return (old_val + value) / 2;
+   if (value > (long)old_val - fuzz * 2 &&
+   value < (long)old_val + fuzz * 2)
+   return ((long)old_val + value) / 2;
}
 
return value;
-- 
2.7.4

[PATCH] driver: input: fix UBSAN warning in input_defuzz_abs_event

[liujian]

syzkaller triggered a UBCAN warning:

[  196.188950] UBSAN: Undefined behaviour in drivers/input/input.c:62:23
[  196.188958] signed integer overflow:
[  196.188964] -2147483647 - 104 cannot be represented in type 'int [2]'
[  196.188973] CPU: 7 PID: 4763 Comm: syz-executor Not tainted
4.19.0-514.55.6.9.x86_64+ #7
[  196.188977] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  196.188979] Call Trace:
[  196.189001]  dump_stack+0x91/0xeb
[  196.189014]  ubsan_epilogue+0x9/0x7c
[  196.189020]  handle_overflow+0x1d7/0x22c
[  196.189028]  ? __ubsan_handle_negate_overflow+0x18f/0x18f
[  196.189038]  ? __mutex_lock+0x213/0x13f0
[  196.189053]  ? drop_futex_key_refs+0xa0/0xa0
[  196.189070]  ? __might_fault+0xef/0x1b0
[  196.189096]  input_handle_event+0xe1b/0x1290
[  196.189108]  input_inject_event+0x1d7/0x27e
[  196.189119]  evdev_write+0x2cf/0x3f0
[  196.189129]  ? evdev_pass_values+0xd40/0xd40
[  196.189157]  ? mark_held_locks+0x160/0x160
[  196.189171]  ? __vfs_write+0xe0/0x6c0
[  196.189175]  ? evdev_pass_values+0xd40/0xd40
[  196.189179]  __vfs_write+0xe0/0x6c0
[  196.189186]  ? kernel_read+0x130/0x130
[  196.189204]  ? _cond_resched+0x15/0x30
[  196.189214]  ? __inode_security_revalidate+0xb8/0xe0
[  196.189222]  ? selinux_file_permission+0x354/0x430
[  196.189233]  vfs_write+0x160/0x440
[  196.189242]  ksys_write+0xc1/0x190
[  196.189248]  ? __ia32_sys_read+0xb0/0xb0
[  196.189259]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  196.189267]  ? do_syscall_64+0x22/0x4a0
[  196.189276]  do_syscall_64+0xa5/0x4a0
[  196.189287]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  196.189293] RIP: 0033:0x44e7c9
[  196.189299] Code: fc ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00

the syzkaller reproduce script(but can't reproduce it every time):

r0 = syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2,
0x1)
write$binfmt_elf64(r0, &(0x7f000240)={{0x7f, 0x45, 0x4c, 0x46, 0x40,
0x2, 0x2, 0x, 0x374c, 0x3, 0x0, 0x8001, 0x103,
0x40, 0x22e, 0x26, 0x1, 0x38, 0x2, 0xa23, 0x1, 0x2}, [{0x6474e557, 0x5,
0x6, 0x2, 0x9, 0x9, 0x6c3, 0x1ff}], "", [[], [], [], []]}, 0x478)
ioctl$EVIOCGSW(0x, 0x8040451b, &(0x7f40)=""/7)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)
r1 = syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2,
0x1)
openat$smack_task_current(0xff9c,
&(0x7f40)='/proc/self/attr/current\x00', 0x2, 0x0)
ioctl$EVIOCSABS0(r1, 0x401845c0, &(0x7f00)={0x4, 0x1, 0x4,
0xd1, 0x81, 0x3})
eventfd(0x1ff)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2,
0x200)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)
syz_open_dev$evdev(&(0x7f000100)='/dev/input/event#\x00', 0x2, 0x1)

Typecast int to long to fix the issue.

Signed-off-by: liujian 
---
 drivers/input/input.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 3304aaa..24615ef 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -59,14 +59,17 @@ static inline int is_event_supported(unsigned int code,
 static int input_defuzz_abs_event(int value, int old_val, int fuzz)
 {
if (fuzz) {
-   if (value > old_val - fuzz / 2 && value < old_val + fuzz / 2)
+   if (value > (long)old_val - fuzz / 2 &&
+   value < (long)old_val + fuzz / 2)
return old_val;
 
-   if (value > old_val - fuzz && value < old_val + fuzz)
-   return (old_val * 3 + value) / 4;
+   if (value > (long)old_val - fuzz &&
+   value < (long)old_val + fuzz)
+   return ((long)old_val * 3 + value) / 4;
 
-   if (value > old_val - fuzz * 2 && value < old_val + fuzz * 2)
-   return (old_val + value) / 2;
+   if (value > (long)old_val - fuzz * 2 &&
+   value < (long)old_val + fuzz * 2)
+   return ((long)old_val + value) / 2;
}
 
return value;
-- 
2.7.4

Re: [PATCH 1/2] CHROMIUM: ASoC: rt5663: Add documentation for power supply support

[Cheng-yi Chiang]

Sorry! I made a mistake in the title.
I will fix them and re-post.
On Thu, Nov 1, 2018 at 8:40 PM Cheng-Yi Chiang  wrote:
>
> rt5663 codec driver will support setting CPVDD and AVDD power supply
> from device tree.
>
> Signed-off-by: Cheng-Yi Chiang 
> ---
>  Documentation/devicetree/bindings/sound/rt5663.txt | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt 
> b/Documentation/devicetree/bindings/sound/rt5663.txt
> index 23386446c63d6..d4058dfde0392 100644
> --- a/Documentation/devicetree/bindings/sound/rt5663.txt
> +++ b/Documentation/devicetree/bindings/sound/rt5663.txt
> @@ -36,6 +36,9 @@ Optional properties:
>"realtek,impedance_sensing_num" is 2. It means that there are 2 ranges of
>impedance in the impedance sensing function.
>
> +- avdd-supply: Power supply for AVDD, providing 1.8V.
> +- cpvdd-supply: Power supply for CPVDD, providing 3.5V.
> +
>  Pins on the device (for linking into audio routes) for RT5663:
>
>* IN1P
> @@ -51,4 +54,6 @@ rt5663: codec@12 {
> compatible = "realtek,rt5663";
> reg = <0x12>;
> interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
> +   avdd-supply = <_a_alc5662>;
> +   cpvdd-supply = <_a_alc5662>;
>  };
> --
> 2.19.1.568.g152ad8e336-goog
>

Re: [PATCH 1/2] CHROMIUM: ASoC: rt5663: Add documentation for power supply support

[Cheng-yi Chiang]

Sorry! I made a mistake in the title.
I will fix them and re-post.
On Thu, Nov 1, 2018 at 8:40 PM Cheng-Yi Chiang  wrote:
>
> rt5663 codec driver will support setting CPVDD and AVDD power supply
> from device tree.
>
> Signed-off-by: Cheng-Yi Chiang 
> ---
>  Documentation/devicetree/bindings/sound/rt5663.txt | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt 
> b/Documentation/devicetree/bindings/sound/rt5663.txt
> index 23386446c63d6..d4058dfde0392 100644
> --- a/Documentation/devicetree/bindings/sound/rt5663.txt
> +++ b/Documentation/devicetree/bindings/sound/rt5663.txt
> @@ -36,6 +36,9 @@ Optional properties:
>"realtek,impedance_sensing_num" is 2. It means that there are 2 ranges of
>impedance in the impedance sensing function.
>
> +- avdd-supply: Power supply for AVDD, providing 1.8V.
> +- cpvdd-supply: Power supply for CPVDD, providing 3.5V.
> +
>  Pins on the device (for linking into audio routes) for RT5663:
>
>* IN1P
> @@ -51,4 +54,6 @@ rt5663: codec@12 {
> compatible = "realtek,rt5663";
> reg = <0x12>;
> interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
> +   avdd-supply = <_a_alc5662>;
> +   cpvdd-supply = <_a_alc5662>;
>  };
> --
> 2.19.1.568.g152ad8e336-goog
>

Re: [PATCH 4.9 23/35] x86/mm: Expand static page table for fixmap space

[Feng Tang]

Hi Ben,

On Thu, Nov 01, 2018 at 10:25:43PM +, Ben Hutchings wrote:
> On Thu, 2018-10-11 at 17:35 +0200, Greg Kroah-Hartman wrote:
> > 4.9-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Feng Tang 
> > 
> > commit 05ab1d8a4b36ee912b7087c6da127439ed0a903e upstream.
> 
> This backport is incorrect.  The part that updated __startup_64() in
> arch/x86/kernel/head64.c was dropped, presumably because that function
> doesn't exist in 4.9.  However that seems to be an essential of the
> fix.  In 4.9 the startup_64 routine in arch/x86/kernel/head_64.S would
> need to be changed instead.
> 
> I also found that this introduces new boot-time warnings on some
> systems if CONFIG_DEBUG_WX is enabled.
> 
> So, unless someone provides fixes for those issues, I think this should
> be reverted for the 4.9 branch.

Thanks for the catch, I'm fine with the revert for now.

- Feng

Re: [PATCH 4.9 23/35] x86/mm: Expand static page table for fixmap space

[Feng Tang]

Hi Ben,

On Thu, Nov 01, 2018 at 10:25:43PM +, Ben Hutchings wrote:
> On Thu, 2018-10-11 at 17:35 +0200, Greg Kroah-Hartman wrote:
> > 4.9-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Feng Tang 
> > 
> > commit 05ab1d8a4b36ee912b7087c6da127439ed0a903e upstream.
> 
> This backport is incorrect.  The part that updated __startup_64() in
> arch/x86/kernel/head64.c was dropped, presumably because that function
> doesn't exist in 4.9.  However that seems to be an essential of the
> fix.  In 4.9 the startup_64 routine in arch/x86/kernel/head_64.S would
> need to be changed instead.
> 
> I also found that this introduces new boot-time warnings on some
> systems if CONFIG_DEBUG_WX is enabled.
> 
> So, unless someone provides fixes for those issues, I think this should
> be reverted for the 4.9 branch.

Thanks for the catch, I'm fine with the revert for now.

- Feng

linux-next: Tree for Nov 2

[Stephen Rothwell]

Hi all,

Please do not add any v4.21/v5.1 code to your linux-next included trees
until after the merge window closes.

Changes since 20181101:

Removed trees: hvc (finished with)

Non-merge commits (relative to Linus' tree): 628
 817 files changed, 36481 insertions(+), 8817 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 290 trees (counting Linus' and 66 trees of bug
fix patches pending for the current merge release).

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 (7260935d71b6 Merge tag 'ovl-update-4.20' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs)
Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux)
Merging kbuild-current/fixes (310c7585e830 Merge tag 'nfsd-4.20' of 
git://linux-nfs.org/~bfields/linux)
Merging arc-current/for-curr (a75e410a8bc2 ARCv2: boot log unaligned access in 
use)
Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() 
offset check)
Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject 
stand-alone CHAIN events for PMUv3)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (84df9525b0c2 Linux 4.19)
Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and 
getsockname.)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (7de414a9dd91 net: drop skb on failure in ip_check_defrag())
Merging bpf/master (dfeb8f4c9692 Merge branch 'verifier-fixes')
Merging ipsec/master (533555e5cbb6 xfrm: Fix error return code in 
xfrm_output_one())
Merging netfilter/master (29a0dd66e953 netfilter: xt_IDLETIMER: add sysfs 
filename checking routine)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue 
size)
Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error 
paths for netlink)
Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 vulnerability)
Merging sound-current/for-linus (826b5de90c0b ALSA: firewire-lib: fix 
insufficient PCM rule for period/buffer size)
Merging sound-asoc-fixes/for-linus (fec2c565951e Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8)
Merging regulator-fixes/for-linus (84df9525b0c2 Linux 4.19)
Merging spi-fixes/for-linus (83665c6da9d3 Merge branch 'spi-4.19' into 
spi-linus)
Merging pci-current/for-linus (2edab4df98d9 PCI: Expand the "PF" acronym in 
Kconfig help text)
Merging driver-core.current/driver-core-linus (310c7585e830 Merge tag 
'nfsd-4.20' of git://linux-nfs.org/~bfields/linux)
Merging tty.current/tty-linus (202dc3cc10b4 serial: sh-sci: Fix receive on 
SCIFA/SCIFB variants with DMA)
Merging usb.current/usb-linus (310c7585e830 Merge tag 'nfsd-4.20' of 
git://linux-nfs.org/~bfields/linux)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (5b394b2ddf03 Linux 4.19-rc1)
Merging staging.current/staging-linus (310

linux-next: Tree for Nov 2

[Stephen Rothwell]

Hi all,

Please do not add any v4.21/v5.1 code to your linux-next included trees
until after the merge window closes.

Changes since 20181101:

Removed trees: hvc (finished with)

Non-merge commits (relative to Linus' tree): 628
 817 files changed, 36481 insertions(+), 8817 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 290 trees (counting Linus' and 66 trees of bug
fix patches pending for the current merge release).

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 (7260935d71b6 Merge tag 'ovl-update-4.20' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs)
Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux)
Merging kbuild-current/fixes (310c7585e830 Merge tag 'nfsd-4.20' of 
git://linux-nfs.org/~bfields/linux)
Merging arc-current/for-curr (a75e410a8bc2 ARCv2: boot log unaligned access in 
use)
Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() 
offset check)
Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject 
stand-alone CHAIN events for PMUv3)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (84df9525b0c2 Linux 4.19)
Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and 
getsockname.)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (7de414a9dd91 net: drop skb on failure in ip_check_defrag())
Merging bpf/master (dfeb8f4c9692 Merge branch 'verifier-fixes')
Merging ipsec/master (533555e5cbb6 xfrm: Fix error return code in 
xfrm_output_one())
Merging netfilter/master (29a0dd66e953 netfilter: xt_IDLETIMER: add sysfs 
filename checking routine)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue 
size)
Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error 
paths for netlink)
Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 vulnerability)
Merging sound-current/for-linus (826b5de90c0b ALSA: firewire-lib: fix 
insufficient PCM rule for period/buffer size)
Merging sound-asoc-fixes/for-linus (fec2c565951e Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8)
Merging regulator-fixes/for-linus (84df9525b0c2 Linux 4.19)
Merging spi-fixes/for-linus (83665c6da9d3 Merge branch 'spi-4.19' into 
spi-linus)
Merging pci-current/for-linus (2edab4df98d9 PCI: Expand the "PF" acronym in 
Kconfig help text)
Merging driver-core.current/driver-core-linus (310c7585e830 Merge tag 
'nfsd-4.20' of git://linux-nfs.org/~bfields/linux)
Merging tty.current/tty-linus (202dc3cc10b4 serial: sh-sci: Fix receive on 
SCIFA/SCIFB variants with DMA)
Merging usb.current/usb-linus (310c7585e830 Merge tag 'nfsd-4.20' of 
git://linux-nfs.org/~bfields/linux)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (5b394b2ddf03 Linux 4.19-rc1)
Merging staging.current/staging-linus (310

Re: Will the recent memory leak fixes be backported to longterm kernels?

[Roman Gushchin]

On Fri, Nov 02, 2018 at 02:45:42AM +, Dexuan Cui wrote:
> > From: Roman Gushchin 
> > Sent: Thursday, November 1, 2018 17:58
> > 
> > On Fri, Nov 02, 2018 at 12:16:02AM +, Dexuan Cui wrote:
> > Hello, Dexuan!
> > 
> > A couple of issues has been revealed recently, here are fixes
> > (hashes are from the next tree):
> > 
> > 5f4b04528b5f mm: don't reclaim inodes with many attached pages
> > 5a03b371ad6a mm: handle no memcg case in memcg_kmem_charge()
> > properly
> > 
> > These two patches should be added to the serie.
> 
> Thanks for the new info!
>  
> > Re stable backporting, I'd really wait for some time. Memory reclaim is a
> > quite complex and fragile area, so even if patches are correct by 
> > themselves,
> > they can easily cause a regression by revealing some other issues (as it was
> > with the inode reclaim case).
> 
> I totally agree. I'm now just wondering if there is any temporary workaround,
> even if that means we have to run the kernel with some features disabled or
> with a suboptimal performance?

I don't think there is any, except not using memory cgroups at all.
Limiting the amount of cgroups which are created and destroyed helps too:
a faulty service running under systemd can be especially painful.

Thanks!

Re: Will the recent memory leak fixes be backported to longterm kernels?

[Roman Gushchin]

On Fri, Nov 02, 2018 at 02:45:42AM +, Dexuan Cui wrote:
> > From: Roman Gushchin 
> > Sent: Thursday, November 1, 2018 17:58
> > 
> > On Fri, Nov 02, 2018 at 12:16:02AM +, Dexuan Cui wrote:
> > Hello, Dexuan!
> > 
> > A couple of issues has been revealed recently, here are fixes
> > (hashes are from the next tree):
> > 
> > 5f4b04528b5f mm: don't reclaim inodes with many attached pages
> > 5a03b371ad6a mm: handle no memcg case in memcg_kmem_charge()
> > properly
> > 
> > These two patches should be added to the serie.
> 
> Thanks for the new info!
>  
> > Re stable backporting, I'd really wait for some time. Memory reclaim is a
> > quite complex and fragile area, so even if patches are correct by 
> > themselves,
> > they can easily cause a regression by revealing some other issues (as it was
> > with the inode reclaim case).
> 
> I totally agree. I'm now just wondering if there is any temporary workaround,
> even if that means we have to run the kernel with some features disabled or
> with a suboptimal performance?

I don't think there is any, except not using memory cgroups at all.
Limiting the amount of cgroups which are created and destroyed helps too:
a faulty service running under systemd can be especially painful.

Thanks!

[PATCH] arm64: dts: nxp: add more thermal zone support

[Yuantian Tang]

To enable all the supported thermal sensors, add sensor id information
to thermal zone node.
Dts for ls1012a, ls1046a, ls1043a, ls1088a are updated.

Signed-off-by: Yuantian Tang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |   39 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |   59 +++
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |   55 ++
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |   54 ++
 4 files changed, 75 insertions(+), 132 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 68ac78c..9526b66 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -28,7 +28,7 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu0: cpu@0 {
+   cooling_map0: cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x0>;
@@ -100,36 +100,7 @@
mask = <0x02>;
};
 
-   thermal-zones {
-   cpu_thermal: cpu-thermal {
-   polling-delay-passive = <1000>;
-   polling-delay = <5000>;
-   thermal-sensors = < 0>;
-
-   trips {
-   cpu_alert: cpu-alert {
-   temperature = <85000>;
-   hysteresis = <2000>;
-   type = "passive";
-   };
-
-   cpu_crit: cpu-crit {
-   temperature = <95000>;
-   hysteresis = <2000>;
-   type = "critical";
-   };
-   };
-
-   cooling-maps {
-   map0 {
-   trip = <_alert>;
-   cooling-device =
-   < THERMAL_NO_LIMIT
-   THERMAL_NO_LIMIT>;
-   };
-   };
-   };
-   };
+   #include "fsl-tmu.dtsi"
 
soc {
compatible = "simple-bus";
@@ -506,3 +477,9 @@
};
};
 };
+
+_zones {
+   thermal-zone0 {
+   status = "okay";
+   };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 7881e3d..3afc6d4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -37,7 +37,7 @@
 *
 * Currently supported enable-method is psci v0.2
 */
-   cpu0: cpu@0 {
+   cooling_map0: cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x0>;
@@ -146,36 +146,7 @@
mask = <0x02>;
};
 
-   thermal-zones {
-   cpu_thermal: cpu-thermal {
-   polling-delay-passive = <1000>;
-   polling-delay = <5000>;
-
-   thermal-sensors = < 3>;
-
-   trips {
-   cpu_alert: cpu-alert {
-   temperature = <85000>;
-   hysteresis = <2000>;
-   type = "passive";
-   };
-   cpu_crit: cpu-crit {
-   temperature = <95000>;
-   hysteresis = <2000>;
-   type = "critical";
-   };
-   };
-
-   cooling-maps {
-   map0 {
-   trip = <_alert>;
-   cooling-device =
-   < THERMAL_NO_LIMIT
-   THERMAL_NO_LIMIT>;
-   };
-   };
-   };
-   };
+   #include "fsl-tmu.dtsi"
 
timer {
compatible = "arm,armv8-timer";
@@ -747,3 +718,29 @@
 
 #include "qoriq-qman-portals.dtsi"
 #include "qoriq-bman-portals.dtsi"
+
+_zones {
+   thermal-zone0 {
+   status = "okay";
+   };
+
+   thermal-zone1 {
+   status = "okay";
+   };
+
+   thermal-zone2 {
+   status = "okay";
+   };
+
+   thermal-zone3 {
+   status = "okay";
+   

[PATCH] arm64: dts: nxp: add more thermal zone support

[Yuantian Tang]

To enable all the supported thermal sensors, add sensor id information
to thermal zone node.
Dts for ls1012a, ls1046a, ls1043a, ls1088a are updated.

Signed-off-by: Yuantian Tang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |   39 +++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |   59 +++
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |   55 ++
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |   54 ++
 4 files changed, 75 insertions(+), 132 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 68ac78c..9526b66 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -28,7 +28,7 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu0: cpu@0 {
+   cooling_map0: cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x0>;
@@ -100,36 +100,7 @@
mask = <0x02>;
};
 
-   thermal-zones {
-   cpu_thermal: cpu-thermal {
-   polling-delay-passive = <1000>;
-   polling-delay = <5000>;
-   thermal-sensors = < 0>;
-
-   trips {
-   cpu_alert: cpu-alert {
-   temperature = <85000>;
-   hysteresis = <2000>;
-   type = "passive";
-   };
-
-   cpu_crit: cpu-crit {
-   temperature = <95000>;
-   hysteresis = <2000>;
-   type = "critical";
-   };
-   };
-
-   cooling-maps {
-   map0 {
-   trip = <_alert>;
-   cooling-device =
-   < THERMAL_NO_LIMIT
-   THERMAL_NO_LIMIT>;
-   };
-   };
-   };
-   };
+   #include "fsl-tmu.dtsi"
 
soc {
compatible = "simple-bus";
@@ -506,3 +477,9 @@
};
};
 };
+
+_zones {
+   thermal-zone0 {
+   status = "okay";
+   };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 7881e3d..3afc6d4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -37,7 +37,7 @@
 *
 * Currently supported enable-method is psci v0.2
 */
-   cpu0: cpu@0 {
+   cooling_map0: cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x0>;
@@ -146,36 +146,7 @@
mask = <0x02>;
};
 
-   thermal-zones {
-   cpu_thermal: cpu-thermal {
-   polling-delay-passive = <1000>;
-   polling-delay = <5000>;
-
-   thermal-sensors = < 3>;
-
-   trips {
-   cpu_alert: cpu-alert {
-   temperature = <85000>;
-   hysteresis = <2000>;
-   type = "passive";
-   };
-   cpu_crit: cpu-crit {
-   temperature = <95000>;
-   hysteresis = <2000>;
-   type = "critical";
-   };
-   };
-
-   cooling-maps {
-   map0 {
-   trip = <_alert>;
-   cooling-device =
-   < THERMAL_NO_LIMIT
-   THERMAL_NO_LIMIT>;
-   };
-   };
-   };
-   };
+   #include "fsl-tmu.dtsi"
 
timer {
compatible = "arm,armv8-timer";
@@ -747,3 +718,29 @@
 
 #include "qoriq-qman-portals.dtsi"
 #include "qoriq-bman-portals.dtsi"
+
+_zones {
+   thermal-zone0 {
+   status = "okay";
+   };
+
+   thermal-zone1 {
+   status = "okay";
+   };
+
+   thermal-zone2 {
+   status = "okay";
+   };
+
+   thermal-zone3 {
+   status = "okay";
+   

Re: [git pull] work.afs

[Linus Torvalds]

On Thu, Nov 1, 2018 at 4:46 PM Al Viro  wrote:
>
> AFS series, with some iov_iter bits included.

Grr. Bad summary explanation of what actually is happening.

Also, this is very late in the merge window for no discernible reason for this.

I'm not happy. I'm taking it, but I'm no longer pulling random stuff
that I get after this.

   Linus

Re: [git pull] work.afs

[Linus Torvalds]

On Thu, Nov 1, 2018 at 4:46 PM Al Viro  wrote:
>
> AFS series, with some iov_iter bits included.

Grr. Bad summary explanation of what actually is happening.

Also, this is very late in the merge window for no discernible reason for this.

I'm not happy. I'm taking it, but I'm no longer pulling random stuff
that I get after this.

   Linus

[PATCH] pinctrl: mediatek: Fix dependencies for EINT_MTK

[Olof Johansson]

Fixes the following config-time warning:

WARNING: unmet direct dependencies detected for EINT_MTK
  Depends on [n]: PINCTRL [=y] && (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && 
(PINCTRL_MTK [=n] || PINCTRL_MTK_MOORE [=n] || COMPILE_TEST [=n])
  Selected by [y]:
  - PINCTRL_MTK_PARIS [=y] && PINCTRL [=y] && OF [=y] && (ARCH_MEDIATEK [=y] || 
COMPILE_TEST [=n])

Fixes: 805250982bb5 ("pinctrl: mediatek: add pinctrl-paris that implements the 
vendor dt-bindings")
Signed-off-by: Olof Johansson 
---
 drivers/pinctrl/mediatek/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 9d142e1da567..50efc9cc8ee7 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -3,7 +3,7 @@ menu "MediaTek pinctrl drivers"
 
 config EINT_MTK
bool "MediaTek External Interrupt Support"
-   depends on PINCTRL_MTK || PINCTRL_MTK_MOORE || COMPILE_TEST
+   depends on PINCTRL_MTK || PINCTRL_MTK_MOORE || PINCTRL_MTK_PARIS || 
COMPILE_TEST
select GPIOLIB
select IRQ_DOMAIN
 
-- 
2.11.0

[PATCH] pinctrl: mediatek: Fix dependencies for EINT_MTK

[Olof Johansson]

Fixes the following config-time warning:

WARNING: unmet direct dependencies detected for EINT_MTK
  Depends on [n]: PINCTRL [=y] && (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && 
(PINCTRL_MTK [=n] || PINCTRL_MTK_MOORE [=n] || COMPILE_TEST [=n])
  Selected by [y]:
  - PINCTRL_MTK_PARIS [=y] && PINCTRL [=y] && OF [=y] && (ARCH_MEDIATEK [=y] || 
COMPILE_TEST [=n])

Fixes: 805250982bb5 ("pinctrl: mediatek: add pinctrl-paris that implements the 
vendor dt-bindings")
Signed-off-by: Olof Johansson 
---
 drivers/pinctrl/mediatek/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 9d142e1da567..50efc9cc8ee7 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -3,7 +3,7 @@ menu "MediaTek pinctrl drivers"
 
 config EINT_MTK
bool "MediaTek External Interrupt Support"
-   depends on PINCTRL_MTK || PINCTRL_MTK_MOORE || COMPILE_TEST
+   depends on PINCTRL_MTK || PINCTRL_MTK_MOORE || PINCTRL_MTK_PARIS || 
COMPILE_TEST
select GPIOLIB
select IRQ_DOMAIN
 
-- 
2.11.0

Question: perf dso support for /proc/kallsyms

[leo . yan]

Hi all,

Now I found that if use the command 'perf script' for Arm CoreSight trace
data, it fails to parse kernel symbols if we don't specify kernel vmlinux
file.   So when we don't specify kernel symbol files then perf tool will
roll back to use /proc/kallsyms for kernel symbols parsing, as result it will
run into below flow:

  thread__find_addr_map(thread, cpumode, MAP__FUNCTION, address, );
  map__load(al.map);
  dso__data_read_offset(al.map->dso, machine, offset, buffer, size);
`-> data_read_offset()

I can observe the function data_read_offset() returns failure, this is caused
by checking the offset sanity "if (offset > dso->data.file_size)"  (I pasted
the whole function code at below in case you want to get more context for it),
but if perf use "/proc/kallsyms" to load kernel symbols, the variable
'dso->data.file_size' will be set to zero thus the sanity checking always
thinks the offset is out of the file size bound.

Now I still don't understand how the dso/map support "/proc/kallsyms" and
have no idea to fix this issue, though I spent some time to look into it.

Could you give some suggestion for this?  Or even better if you have fixing
for this, I am glad to test at my side.

static ssize_t data_read_offset(struct dso *dso, struct machine *machine,
u64 offset, u8 *data, ssize_t size)
{
if (data_file_size(dso, machine))
return -1;

/* Check the offset sanity. */
if (offset > dso->data.file_size)
return -1;

if (offset + size < offset)
return -1;

return cached_read(dso, machine, offset, data, size);
}

Thanks,
Leo Yan

Question: perf dso support for /proc/kallsyms

[leo . yan]

Hi all,

Now I found that if use the command 'perf script' for Arm CoreSight trace
data, it fails to parse kernel symbols if we don't specify kernel vmlinux
file.   So when we don't specify kernel symbol files then perf tool will
roll back to use /proc/kallsyms for kernel symbols parsing, as result it will
run into below flow:

  thread__find_addr_map(thread, cpumode, MAP__FUNCTION, address, );
  map__load(al.map);
  dso__data_read_offset(al.map->dso, machine, offset, buffer, size);
`-> data_read_offset()

I can observe the function data_read_offset() returns failure, this is caused
by checking the offset sanity "if (offset > dso->data.file_size)"  (I pasted
the whole function code at below in case you want to get more context for it),
but if perf use "/proc/kallsyms" to load kernel symbols, the variable
'dso->data.file_size' will be set to zero thus the sanity checking always
thinks the offset is out of the file size bound.

Now I still don't understand how the dso/map support "/proc/kallsyms" and
have no idea to fix this issue, though I spent some time to look into it.

Could you give some suggestion for this?  Or even better if you have fixing
for this, I am glad to test at my side.

static ssize_t data_read_offset(struct dso *dso, struct machine *machine,
u64 offset, u8 *data, ssize_t size)
{
if (data_file_size(dso, machine))
return -1;

/* Check the offset sanity. */
if (offset > dso->data.file_size)
return -1;

if (offset + size < offset)
return -1;

return cached_read(dso, machine, offset, data, size);
}

Thanks,
Leo Yan

RE: Will the recent memory leak fixes be backported to longterm kernels?

[Dexuan Cui]

> From: Roman Gushchin 
> Sent: Thursday, November 1, 2018 17:58
> 
> On Fri, Nov 02, 2018 at 12:16:02AM +, Dexuan Cui wrote:
> Hello, Dexuan!
> 
> A couple of issues has been revealed recently, here are fixes
> (hashes are from the next tree):
> 
> 5f4b04528b5f mm: don't reclaim inodes with many attached pages
> 5a03b371ad6a mm: handle no memcg case in memcg_kmem_charge()
> properly
> 
> These two patches should be added to the serie.

Thanks for the new info!
 
> Re stable backporting, I'd really wait for some time. Memory reclaim is a
> quite complex and fragile area, so even if patches are correct by themselves,
> they can easily cause a regression by revealing some other issues (as it was
> with the inode reclaim case).

I totally agree. I'm now just wondering if there is any temporary workaround,
even if that means we have to run the kernel with some features disabled or
with a suboptimal performance?

Thanks!
--Dexuan

RE: Will the recent memory leak fixes be backported to longterm kernels?

[Dexuan Cui]

> From: Roman Gushchin 
> Sent: Thursday, November 1, 2018 17:58
> 
> On Fri, Nov 02, 2018 at 12:16:02AM +, Dexuan Cui wrote:
> Hello, Dexuan!
> 
> A couple of issues has been revealed recently, here are fixes
> (hashes are from the next tree):
> 
> 5f4b04528b5f mm: don't reclaim inodes with many attached pages
> 5a03b371ad6a mm: handle no memcg case in memcg_kmem_charge()
> properly
> 
> These two patches should be added to the serie.

Thanks for the new info!
 
> Re stable backporting, I'd really wait for some time. Memory reclaim is a
> quite complex and fragile area, so even if patches are correct by themselves,
> they can easily cause a regression by revealing some other issues (as it was
> with the inode reclaim case).

I totally agree. I'm now just wondering if there is any temporary workaround,
even if that means we have to run the kernel with some features disabled or
with a suboptimal performance?

Thanks!
--Dexuan

[PATCH v2] ARM:kexec:offline panic_smp_self_stop CPU

[wangyufen]

In case panic() and panic() called at the same time on different CPUS.
For example:
CPU 0:
  panic()
 __crash_kexec
   machine_crash_shutdown
 crash_smp_send_stop
   machine_kexec
 BUG_ON(num_online_cpus() > 1);

CPU 1:
  panic()
local_irq_disable
panic_smp_self_stop

If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump
fails. CPU1 can't receive the ipi irq, CPU1 will be always online.
To fix this problem, this patch split out the panic_smp_self_stop()
and add set_cpu_online(smp_processor_id(), false).

Signed-off-by: Yufen Wang 
---
 arch/arm/kernel/smp.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 9000d8b..d7b86e4 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -682,6 +682,21 @@ void smp_send_stop(void)
pr_warn("SMP: failed to stop secondary CPUs\n");
 }
 
+/* In case panic() and panic() called at the same time on CPU1 and CPU2,
+ * and CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop()
+ * CPU1 can't receive the ipi irqs from CPU2, CPU1 will be always online,
+ * kdump fails. So split out the panic_smp_self_stop() and add
+ * set_cpu_online(smp_processor_id(), false).
+ */
+void panic_smp_self_stop(void)
+{
+   pr_debug("CPU %u will stop doing anything useful since another CPU has 
paniced\n",
+smp_processor_id());
+   set_cpu_online(smp_processor_id(), false);
+   while (1)
+   cpu_relax();
+}
+
 /*
  * not supported here
  */
-- 
2.7.4

[PATCH v2] ARM:kexec:offline panic_smp_self_stop CPU

[wangyufen]

In case panic() and panic() called at the same time on different CPUS.
For example:
CPU 0:
  panic()
 __crash_kexec
   machine_crash_shutdown
 crash_smp_send_stop
   machine_kexec
 BUG_ON(num_online_cpus() > 1);

CPU 1:
  panic()
local_irq_disable
panic_smp_self_stop

If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump
fails. CPU1 can't receive the ipi irq, CPU1 will be always online.
To fix this problem, this patch split out the panic_smp_self_stop()
and add set_cpu_online(smp_processor_id(), false).

Signed-off-by: Yufen Wang 
---
 arch/arm/kernel/smp.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 9000d8b..d7b86e4 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -682,6 +682,21 @@ void smp_send_stop(void)
pr_warn("SMP: failed to stop secondary CPUs\n");
 }
 
+/* In case panic() and panic() called at the same time on CPU1 and CPU2,
+ * and CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop()
+ * CPU1 can't receive the ipi irqs from CPU2, CPU1 will be always online,
+ * kdump fails. So split out the panic_smp_self_stop() and add
+ * set_cpu_online(smp_processor_id(), false).
+ */
+void panic_smp_self_stop(void)
+{
+   pr_debug("CPU %u will stop doing anything useful since another CPU has 
paniced\n",
+smp_processor_id());
+   set_cpu_online(smp_processor_id(), false);
+   while (1)
+   cpu_relax();
+}
+
 /*
  * not supported here
  */
-- 
2.7.4

[GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 3

[Palmer Dabbelt]

The following changes since commit baa888d25ea64d0c59344d474284ca99cfdd449a:

  Merge branch 'next-keys2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security 
(2018-11-01 15:23:59 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git 
tags/riscv-for-linus-4.20-mw3

for you to fetch changes up to ba1f0d95576902c10930d3467e638bac38f942f1:

  RISC-V: refresh defconfig (2018-11-01 17:04:07 -0700)


RISC-V Patches for the 4.20 Merge Window, Part 3

Sorry for the last minute patches, but it was suggested we try to push
this in before rc1 to make it easier for people to keep their branch
rebases sane.  Since this is just a single defconfig update that is
intended to have no functional change I thought it would be worth
breaking my own PR rules.


Anup Patel (1):
  RISC-V: refresh defconfig

 arch/riscv/configs/defconfig | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

[GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 3

[Palmer Dabbelt]

The following changes since commit baa888d25ea64d0c59344d474284ca99cfdd449a:

  Merge branch 'next-keys2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security 
(2018-11-01 15:23:59 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git 
tags/riscv-for-linus-4.20-mw3

for you to fetch changes up to ba1f0d95576902c10930d3467e638bac38f942f1:

  RISC-V: refresh defconfig (2018-11-01 17:04:07 -0700)


RISC-V Patches for the 4.20 Merge Window, Part 3

Sorry for the last minute patches, but it was suggested we try to push
this in before rc1 to make it easier for people to keep their branch
rebases sane.  Since this is just a single defconfig update that is
intended to have no functional change I thought it would be worth
breaking my own PR rules.


Anup Patel (1):
  RISC-V: refresh defconfig

 arch/riscv/configs/defconfig | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

[PATCH] ASoC: wm8996: fix small typo

[sh liu]

>From e9b923690675ca8fa883fd25dcead5b457856735 Mon Sep 17 00:00:00 2001
From: liush 
Date: Fri, 2 Nov 2018 08:57:00 +0800
Subject: [PATCH] ASoC: wm8996: fix small typo

atleast -> at least

Change-Id: Icc970b438166daef13518b7d1a62b13eb8752f5f
Signed-off-by: liush 
---
 sound/soc/codecs/wm8996.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index 8affa49..d039835 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -2109,7 +2109,7 @@ static int wm8996_set_fll(struct snd_soc_codec
*codec, int fll_id, int source,
  if (i2c->irq)
  timeout *= 10;
  else
- /* ensure timeout of atleast 1 jiffies */
+ /* ensure timeout of at least 1 jiffies */
  timeout = timeout/2 ? : 1;

  for (retry = 0; retry < 10; retry++) {
-- 
1.9.1

[PATCH] ASoC: wm8996: fix small typo

[sh liu]

>From e9b923690675ca8fa883fd25dcead5b457856735 Mon Sep 17 00:00:00 2001
From: liush 
Date: Fri, 2 Nov 2018 08:57:00 +0800
Subject: [PATCH] ASoC: wm8996: fix small typo

atleast -> at least

Change-Id: Icc970b438166daef13518b7d1a62b13eb8752f5f
Signed-off-by: liush 
---
 sound/soc/codecs/wm8996.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index 8affa49..d039835 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -2109,7 +2109,7 @@ static int wm8996_set_fll(struct snd_soc_codec
*codec, int fll_id, int source,
  if (i2c->irq)
  timeout *= 10;
  else
- /* ensure timeout of atleast 1 jiffies */
+ /* ensure timeout of at least 1 jiffies */
  timeout = timeout/2 ? : 1;

  for (retry = 0; retry < 10; retry++) {
-- 
1.9.1

[PATCH] ASoC: wm8996: fix small typo

[lshua312]

From e9b923690675ca8fa883fd25dcead5b457856735 Mon Sep 17 00:00:00 2001
From: liush 
Date: Fri, 2 Nov 2018 08:57:00 +0800
Subject: [PATCH] ASoC: wm8996: fix small typo

atleast -> at least

Change-Id: Icc970b438166daef13518b7d1a62b13eb8752f5f
Signed-off-by: liush 
---
 sound/soc/codecs/wm8996.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index 8affa49..d039835 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -2109,7 +2109,7 @@ static int wm8996_set_fll(struct snd_soc_codec *codec, 
int fll_id, int source,
if (i2c->irq)
timeout *= 10;
else
-   /* ensure timeout of atleast 1 jiffies */
+   /* ensure timeout of at least 1 jiffies */
timeout = timeout/2 ? : 1;
 
for (retry = 0; retry < 10; retry++) {
-- 
1.9.1

[PATCH] ASoC: wm8996: fix small typo

[lshua312]

From e9b923690675ca8fa883fd25dcead5b457856735 Mon Sep 17 00:00:00 2001
From: liush 
Date: Fri, 2 Nov 2018 08:57:00 +0800
Subject: [PATCH] ASoC: wm8996: fix small typo

atleast -> at least

Change-Id: Icc970b438166daef13518b7d1a62b13eb8752f5f
Signed-off-by: liush 
---
 sound/soc/codecs/wm8996.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index 8affa49..d039835 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -2109,7 +2109,7 @@ static int wm8996_set_fll(struct snd_soc_codec *codec, 
int fll_id, int source,
if (i2c->irq)
timeout *= 10;
else
-   /* ensure timeout of atleast 1 jiffies */
+   /* ensure timeout of at least 1 jiffies */
timeout = timeout/2 ? : 1;
 
for (retry = 0; retry < 10; retry++) {
-- 
1.9.1

Re: [PATCH] ARM:kexec:offline panic_smp_self_stop CPU

[wangyufen]

On 2018/11/1 19:34, Russell King - ARM Linux wrote:
> On Thu, Nov 01, 2018 at 07:20:49PM +0800, Wang Yufen wrote:
>> From: Yufen Wang 
>>
>> In case panic() and panic() called at the same time on different CPUS.
>> For example:
>> CPU 0:
>>   panic()
>>  __crash_kexec
>>machine_crash_shutdown
>>  crash_smp_send_stop
>>machine_kexec
>>  BUG_ON(num_online_cpus() > 1);
>>
>> CPU 1:
>>   panic()
>> local_irq_disable
>> panic_smp_self_stop
>>
>> If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump
>> fails. CPU1 can't receive the ipi irq, CPU1 will be always online.
>> I changed BUG_ON to WARN in kexec crash as arm64 does, kdump also fails.
>> Because num_online_cpus() > 1, can't disable the L2 in _soft_restart.
>> To fix this problem, this patch split out the panic_smp_self_stop()
>> and add set_cpu_online(smp_processor_id(), false).
> Thanks.
>
> I think this may as well go into arch/arm/kernel/smp.c - it won't be
> required for single-CPU systems, since there aren't "other" CPUs.
>
> It's probably also worth a comment above the function as to why we
> have this.

Thanks.

I will send v2.

>> Signed-off-by: Yufen Wang 
>> ---
>>  arch/arm/kernel/setup.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index 31940bd..151861f 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -602,6 +602,16 @@ static void __init smp_build_mpidr_hash(void)
>>  }
>>  #endif
>>  
>> +void panic_smp_self_stop(void)
>> +{
>> +printk(KERN_DEBUG "CPU %u will stop doing anything useful since another 
>> CPU has paniced\n",
>> +smp_processor_id());
>> +set_cpu_online(smp_processor_id(), false);
>> +while (1)
>> +cpu_relax();
>> +
>> +}
>> +
>>  static void __init setup_processor(void)
>>  {
>>  struct proc_info_list *list;
>> -- 
>> 2.7.4
>>
>>

Re: [PATCH] ARM:kexec:offline panic_smp_self_stop CPU

[wangyufen]

On 2018/11/1 19:34, Russell King - ARM Linux wrote:
> On Thu, Nov 01, 2018 at 07:20:49PM +0800, Wang Yufen wrote:
>> From: Yufen Wang 
>>
>> In case panic() and panic() called at the same time on different CPUS.
>> For example:
>> CPU 0:
>>   panic()
>>  __crash_kexec
>>machine_crash_shutdown
>>  crash_smp_send_stop
>>machine_kexec
>>  BUG_ON(num_online_cpus() > 1);
>>
>> CPU 1:
>>   panic()
>> local_irq_disable
>> panic_smp_self_stop
>>
>> If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump
>> fails. CPU1 can't receive the ipi irq, CPU1 will be always online.
>> I changed BUG_ON to WARN in kexec crash as arm64 does, kdump also fails.
>> Because num_online_cpus() > 1, can't disable the L2 in _soft_restart.
>> To fix this problem, this patch split out the panic_smp_self_stop()
>> and add set_cpu_online(smp_processor_id(), false).
> Thanks.
>
> I think this may as well go into arch/arm/kernel/smp.c - it won't be
> required for single-CPU systems, since there aren't "other" CPUs.
>
> It's probably also worth a comment above the function as to why we
> have this.

Thanks.

I will send v2.

>> Signed-off-by: Yufen Wang 
>> ---
>>  arch/arm/kernel/setup.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index 31940bd..151861f 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -602,6 +602,16 @@ static void __init smp_build_mpidr_hash(void)
>>  }
>>  #endif
>>  
>> +void panic_smp_self_stop(void)
>> +{
>> +printk(KERN_DEBUG "CPU %u will stop doing anything useful since another 
>> CPU has paniced\n",
>> +smp_processor_id());
>> +set_cpu_online(smp_processor_id(), false);
>> +while (1)
>> +cpu_relax();
>> +
>> +}
>> +
>>  static void __init setup_processor(void)
>>  {
>>  struct proc_info_list *list;
>> -- 
>> 2.7.4
>>
>>

Re: Will the recent memory leak fixes be backported to longterm kernels?

[Roman Gushchin]

On Fri, Nov 02, 2018 at 12:16:02AM +, Dexuan Cui wrote:
> Hi all,
> When debugging a memory leak issue 
> (https://github.com/coreos/bugs/issues/2516)
> with v4.14.11-coreos, we noticed the same issue may have been fixed recently 
> by
> Roman in the latest mainline (i.e. Linus's master branch) according to 
> comment #7 of 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_ubuntu_-2Bsource_linux_-2Bbug_1792349=DwIFAg=5VD0RTtNlTh3ycd41b3MUw=i6WobKxbeG3slzHSIOxTVtYIJw7qjCE6S0spDTKL-J4=mrT9jcrhFvVxDpVBlxihJg6S6U91rlevOJby7y1YynE=1eHLVA-oQGqMd2ujRPU8kZMbkShOuIDD5CUgpM1IzGI=,
>  which lists these
> patches (I'm not sure if the 5-patch list is complete):
> 
> 010cb21d4ede math64: prevent double calculation of DIV64_U64_ROUND_UP() 
> arguments
> f77d7a05670d mm: don't miss the last page because of round-off error
> d18bf0af683e mm: drain memcg stocks on css offlining
> 71cd51b2e1ca mm: rework memcg kernel stack accounting
> f3a2fccbce15 mm: slowly shrink slabs with a relatively small number of objects
> 
> Obviously at least some of the fixes are also needed in the longterm kernels 
> like v4.14.y,
> but none of the 5 patches has the "Cc: sta...@vger.kernel.org" tag? I'm 
> wondering if
> these patches will be backported to the longterm kernels. BTW, the patches 
> are not
> in v4.19, but I suppose they will be in v4.19.1-rc1?

Hello, Dexuan!

A couple of issues has been revealed recently, here are fixes
(hashes are from the next tree):

5f4b04528b5f mm: don't reclaim inodes with many attached pages
5a03b371ad6a mm: handle no memcg case in memcg_kmem_charge() properly

These two patches should be added to the serie.

Re stable backporting, I'd really wait for some time. Memory reclaim is a
quite complex and fragile area, so even if patches are correct by themselves,
they can easily cause a regression by revealing some other issues (as it was
with the inode reclaim case).

Thanks!

Re: Will the recent memory leak fixes be backported to longterm kernels?

[Roman Gushchin]

On Fri, Nov 02, 2018 at 12:16:02AM +, Dexuan Cui wrote:
> Hi all,
> When debugging a memory leak issue 
> (https://github.com/coreos/bugs/issues/2516)
> with v4.14.11-coreos, we noticed the same issue may have been fixed recently 
> by
> Roman in the latest mainline (i.e. Linus's master branch) according to 
> comment #7 of 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_ubuntu_-2Bsource_linux_-2Bbug_1792349=DwIFAg=5VD0RTtNlTh3ycd41b3MUw=i6WobKxbeG3slzHSIOxTVtYIJw7qjCE6S0spDTKL-J4=mrT9jcrhFvVxDpVBlxihJg6S6U91rlevOJby7y1YynE=1eHLVA-oQGqMd2ujRPU8kZMbkShOuIDD5CUgpM1IzGI=,
>  which lists these
> patches (I'm not sure if the 5-patch list is complete):
> 
> 010cb21d4ede math64: prevent double calculation of DIV64_U64_ROUND_UP() 
> arguments
> f77d7a05670d mm: don't miss the last page because of round-off error
> d18bf0af683e mm: drain memcg stocks on css offlining
> 71cd51b2e1ca mm: rework memcg kernel stack accounting
> f3a2fccbce15 mm: slowly shrink slabs with a relatively small number of objects
> 
> Obviously at least some of the fixes are also needed in the longterm kernels 
> like v4.14.y,
> but none of the 5 patches has the "Cc: sta...@vger.kernel.org" tag? I'm 
> wondering if
> these patches will be backported to the longterm kernels. BTW, the patches 
> are not
> in v4.19, but I suppose they will be in v4.19.1-rc1?

Hello, Dexuan!

A couple of issues has been revealed recently, here are fixes
(hashes are from the next tree):

5f4b04528b5f mm: don't reclaim inodes with many attached pages
5a03b371ad6a mm: handle no memcg case in memcg_kmem_charge() properly

These two patches should be added to the serie.

Re stable backporting, I'd really wait for some time. Memory reclaim is a
quite complex and fragile area, so even if patches are correct by themselves,
they can easily cause a regression by revealing some other issues (as it was
with the inode reclaim case).

Thanks!

[PATCH v3] x86/kvmclock : convert to SPDX identifiers

[Peng Hao]

Update the verbose license text with the matching SPDX 
license identifier.

Signed-off-by: Peng Hao 
---
 arch/x86/kernel/kvmclock.c | 15 +--
 1 files changed, 1 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 1e67646..a59325e 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -1,19 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*  KVM paravirtual clock driver. A clocksource implementation
 Copyright (C) 2008 Glauber de Oliveira Costa, Red Hat Inc.
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #include 
-- 
1.8.3.1

[PATCH v3] x86/kvmclock : convert to SPDX identifiers

[Peng Hao]

Update the verbose license text with the matching SPDX 
license identifier.

Signed-off-by: Peng Hao 
---
 arch/x86/kernel/kvmclock.c | 15 +--
 1 files changed, 1 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 1e67646..a59325e 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -1,19 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*  KVM paravirtual clock driver. A clocksource implementation
 Copyright (C) 2008 Glauber de Oliveira Costa, Red Hat Inc.
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #include 
-- 
1.8.3.1

Re: [LKP] [sunrpc] 6a7da2a288: kernel_BUG_at_lib/iov_iter.c

[David Howells]

kernel test robot  wrote:

> FYI, we noticed the following commit (built with gcc-7):
> 
> commit: 6a7da2a288ce412d7ac117a2912a7b0d9104ee6d ("[RFC] sunrpc: Fix flood of 
> warnings from iov_iter_kvec in linux-next")
> url: 
> https://github.com/0day-ci/linux/commits/Leonard-Crestez/sunrpc-Fix-flood-of-warnings-from-iov_iter_kvec-in-linux-next/20181101-070713
> base: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git linux-next
> 
> in testcase: boot
> 
> on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):

Ummm...  You can't just apply that commit to Trond's linux-next branch unless
that branch also includes the iov_iter changes from my afs-next branch.

Before those changes, ITER_KVEC is required:

BUG_ON(!(direction & ITER_KVEC));

and after, it will be prohibited:

WARN_ON(direction & ~(READ | WRITE));

The reason for this is that have yet more patches that split the direction
from the iov_iter::type member into their own member and turn the types into a
simple integer sequence instead of a bit mask.

David

Re: [LKP] [sunrpc] 6a7da2a288: kernel_BUG_at_lib/iov_iter.c

[David Howells]

kernel test robot  wrote:

> FYI, we noticed the following commit (built with gcc-7):
> 
> commit: 6a7da2a288ce412d7ac117a2912a7b0d9104ee6d ("[RFC] sunrpc: Fix flood of 
> warnings from iov_iter_kvec in linux-next")
> url: 
> https://github.com/0day-ci/linux/commits/Leonard-Crestez/sunrpc-Fix-flood-of-warnings-from-iov_iter_kvec-in-linux-next/20181101-070713
> base: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git linux-next
> 
> in testcase: boot
> 
> on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):

Ummm...  You can't just apply that commit to Trond's linux-next branch unless
that branch also includes the iov_iter changes from my afs-next branch.

Before those changes, ITER_KVEC is required:

BUG_ON(!(direction & ITER_KVEC));

and after, it will be prohibited:

WARN_ON(direction & ~(READ | WRITE));

The reason for this is that have yet more patches that split the direction
from the iov_iter::type member into their own member and turn the types into a
simple integer sequence instead of a bit mask.

David

Re: Will the recent memory leak fixes be backported to longterm kernels?

[Sasha Levin]

On Fri, Nov 02, 2018 at 12:16:02AM +, Dexuan Cui wrote:

Hi all,
When debugging a memory leak issue (https://github.com/coreos/bugs/issues/2516)
with v4.14.11-coreos, we noticed the same issue may have been fixed recently by
Roman in the latest mainline (i.e. Linus's master branch) according to comment 
#7 of
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1792349, which lists these
patches (I'm not sure if the 5-patch list is complete):

010cb21d4ede math64: prevent double calculation of DIV64_U64_ROUND_UP() 
arguments
f77d7a05670d mm: don't miss the last page because of round-off error
d18bf0af683e mm: drain memcg stocks on css offlining
71cd51b2e1ca mm: rework memcg kernel stack accounting
f3a2fccbce15 mm: slowly shrink slabs with a relatively small number of objects

Obviously at least some of the fixes are also needed in the longterm kernels 
like v4.14.y,
but none of the 5 patches has the "Cc: sta...@vger.kernel.org" tag? I'm 
wondering if
these patches will be backported to the longterm kernels. BTW, the patches are 
not
in v4.19, but I suppose they will be in v4.19.1-rc1?


There was an issue with this series:
https://lkml.org/lkml/2018/10/23/586, so it's waiting on a fix to be
properly tested.

--
Thanks,
Sasha

Re: Will the recent memory leak fixes be backported to longterm kernels?

[Sasha Levin]

On Fri, Nov 02, 2018 at 12:16:02AM +, Dexuan Cui wrote:

Hi all,
When debugging a memory leak issue (https://github.com/coreos/bugs/issues/2516)
with v4.14.11-coreos, we noticed the same issue may have been fixed recently by
Roman in the latest mainline (i.e. Linus's master branch) according to comment 
#7 of
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1792349, which lists these
patches (I'm not sure if the 5-patch list is complete):

010cb21d4ede math64: prevent double calculation of DIV64_U64_ROUND_UP() 
arguments
f77d7a05670d mm: don't miss the last page because of round-off error
d18bf0af683e mm: drain memcg stocks on css offlining
71cd51b2e1ca mm: rework memcg kernel stack accounting
f3a2fccbce15 mm: slowly shrink slabs with a relatively small number of objects

Obviously at least some of the fixes are also needed in the longterm kernels 
like v4.14.y,
but none of the 5 patches has the "Cc: sta...@vger.kernel.org" tag? I'm 
wondering if
these patches will be backported to the longterm kernels. BTW, the patches are 
not
in v4.19, but I suppose they will be in v4.19.1-rc1?


There was an issue with this series:
https://lkml.org/lkml/2018/10/23/586, so it's waiting on a fix to be
properly tested.

--
Thanks,
Sasha

Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE

[William Kucharski]

> On Nov 1, 2018, at 3:47 PM, Andrew Morton  wrote:
> 
> - count = count > PAGE_SIZE ? PAGE_SIZE : count;
> + count = min_t(size_t, count, PAGE_SIZE);
>   kbuf = kmalloc(count, GFP_KERNEL);
>   if (!kbuf)
>   return -ENOMEM;

Is the use of min_t vs. the C conditional mostly to be more self-documenting?

The compiler-generated assembly between the two versions seems mostly a wash.

William Kucharski

Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE

[William Kucharski]

> On Nov 1, 2018, at 3:47 PM, Andrew Morton  wrote:
> 
> - count = count > PAGE_SIZE ? PAGE_SIZE : count;
> + count = min_t(size_t, count, PAGE_SIZE);
>   kbuf = kmalloc(count, GFP_KERNEL);
>   if (!kbuf)
>   return -ENOMEM;

Is the use of min_t vs. the C conditional mostly to be more self-documenting?

The compiler-generated assembly between the two versions seems mostly a wash.

William Kucharski

Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code

[Alan Kao]

On Thu, Nov 01, 2018 at 10:50:04AM -0700, Palmer Dabbelt wrote:
> On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote:
> >On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote:
> >>On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> >>> I agree that we need a place for vendor-specific ISA extensions and
> >>> having vendor-specific directories is also good.
> >>
> >>The only sensible answer is that we should not allow vendor specific
> >>extensions in the kernel at all.  ...
> >
> >How can this even be possible if a extension includes an extra register
> >set as some domain-specific context?  In such a case, kernel should
> >at least process the context during any context switch, just like how it
> >deals with the FP context.
> 
> Ya, I think there are cases where vendor-specific extensions are going to be
> necessary to handle within the kernel.  Right now the only one I can think
> of is the performance counter stuff, where we explicitly allow
> vendor-specific counters as part of the ISA spec.
> 
> For stateful extensions, we currently have a standard mechanism where the XS
> bits get set in sstatus and the actual save/restore code is hidden behind an
> SBI call.  That call doesn't currently exist, but if we just go ahead and
> add one it should be easy to support this from within Linux.  We'll need to
> figure out how to enable these custom extensions from userspace, but that
> seems tractable as well.  We'll probably also want some fast-path for the V
> extension (and any other stateful standard extensions), but I think as long
> as the V extension adds a quick check for dirtiness then it's not a big
> deal.
> 
> Do you guys have stateful extensions?  We're trying really hard to avoid
> them at SiFive because they're a huge headache, so unless there's a
> compelling base of software using one I don't want to go add support if we
> can avoid it.

Currently no, but the future is hard to see.  As long as the extensible freedom
claimed by the RISC-V foundation remains true, such extensions may have their
role to play.  Don't worry now, I was just to give a example that in some 
possible vendor-specific cases the kernel cannot keep itself from involving.

Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code

[Alan Kao]

On Thu, Nov 01, 2018 at 10:50:04AM -0700, Palmer Dabbelt wrote:
> On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote:
> >On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote:
> >>On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> >>> I agree that we need a place for vendor-specific ISA extensions and
> >>> having vendor-specific directories is also good.
> >>
> >>The only sensible answer is that we should not allow vendor specific
> >>extensions in the kernel at all.  ...
> >
> >How can this even be possible if a extension includes an extra register
> >set as some domain-specific context?  In such a case, kernel should
> >at least process the context during any context switch, just like how it
> >deals with the FP context.
> 
> Ya, I think there are cases where vendor-specific extensions are going to be
> necessary to handle within the kernel.  Right now the only one I can think
> of is the performance counter stuff, where we explicitly allow
> vendor-specific counters as part of the ISA spec.
> 
> For stateful extensions, we currently have a standard mechanism where the XS
> bits get set in sstatus and the actual save/restore code is hidden behind an
> SBI call.  That call doesn't currently exist, but if we just go ahead and
> add one it should be easy to support this from within Linux.  We'll need to
> figure out how to enable these custom extensions from userspace, but that
> seems tractable as well.  We'll probably also want some fast-path for the V
> extension (and any other stateful standard extensions), but I think as long
> as the V extension adds a quick check for dirtiness then it's not a big
> deal.
> 
> Do you guys have stateful extensions?  We're trying really hard to avoid
> them at SiFive because they're a huge headache, so unless there's a
> compelling base of software using one I don't want to go add support if we
> can avoid it.

Currently no, but the future is hard to see.  As long as the extensible freedom
claimed by the RISC-V foundation remains true, such extensions may have their
role to play.  Don't worry now, I was just to give a example that in some 
possible vendor-specific cases the kernel cannot keep itself from involving.

Re: [PATCH] Make JFFS2 endianness configurable

[Al Viro]

On Thu, Nov 01, 2018 at 05:02:36PM -0700, Daniel Walker wrote:
> 
> 
> 
> On Thu, Nov 01, 2018 at 03:56:03PM -0700, Nikunj Kela wrote:
> > This patch allows the endianness of the JFSS2 filesystem to be
> > specified by config options.
> > 
> > It defaults to native-endian (the previously hard-coded option).
> > 
> > Some architectures benefit from having a single known endianness
> > of JFFS2 filesystem (for data, not executables) independent of the
> > endianness of the processor (ARM processors can be switched to either
> > endianness at run-time).
> > 
> 
> 
> The description is pretty sad .. We have a product which we released that uses
> JFFS2, and that product was release with a kernel in one endianness. Then 
> later
> on we decided to change the endianness and now we're stuck with a JFFS2
> partition that has the wrong endiannes, in a released product. This patch 
> allows
> us to set the endianness to something different from the architecture setting.
> 
> So there a significant use case for the change, at least for Cisco.

FWIW, can't we detect it at mount time, as e.g. UFS does?

Re: [PATCH] Make JFFS2 endianness configurable

[Al Viro]

On Thu, Nov 01, 2018 at 05:02:36PM -0700, Daniel Walker wrote:
> 
> 
> 
> On Thu, Nov 01, 2018 at 03:56:03PM -0700, Nikunj Kela wrote:
> > This patch allows the endianness of the JFSS2 filesystem to be
> > specified by config options.
> > 
> > It defaults to native-endian (the previously hard-coded option).
> > 
> > Some architectures benefit from having a single known endianness
> > of JFFS2 filesystem (for data, not executables) independent of the
> > endianness of the processor (ARM processors can be switched to either
> > endianness at run-time).
> > 
> 
> 
> The description is pretty sad .. We have a product which we released that uses
> JFFS2, and that product was release with a kernel in one endianness. Then 
> later
> on we decided to change the endianness and now we're stuck with a JFFS2
> partition that has the wrong endiannes, in a released product. This patch 
> allows
> us to set the endianness to something different from the architecture setting.
> 
> So there a significant use case for the change, at least for Cisco.

FWIW, can't we detect it at mount time, as e.g. UFS does?

[PATCH v3] genirq/matrix: Choose CPU for managed IRQs based on how many of them are allocated

[Long Li]

From: Long Li 

On a large system with multiple devices of the same class (e.g. NVMe disks,
using managed IRQs), the kernel tends to concentrate their IRQs on several
CPUs.

The issue is that when NVMe calls irq_matrix_alloc_managed(), the assigned
CPU tends to be the first several CPUs in the cpumask, because they check for
cpumap->available that will not change after managed IRQs are reserved.

For a managed IRQ, it tends to reserve more than one CPU, based on cpumask in
irq_matrix_reserve_managed. But later when actually allocating CPU for this
IRQ, only one CPU is allocated. Because "available" is calculated at the time
managed IRQ is reserved, it tends to indicate a CPU has more IRQs than the 
actual
number it's assigned.

To get a more even distribution for allocating managed IRQs, we need to keep 
track
of how many of them are allocated on a given CPU. Introduce "managed_allocated"
in struct cpumap to track those managed IRQs that are allocated on this CPU, and
change the code to use this information for deciding how to allocate CPU for
managed IRQs.

Signed-off-by: Long Li 
---
 kernel/irq/matrix.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 6e6d467f3dec..94dd173f24d6 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -14,6 +14,7 @@ struct cpumap {
unsigned intavailable;
unsigned intallocated;
unsigned intmanaged;
+   unsigned intmanaged_allocated;
boolinitialized;
boolonline;
unsigned long   alloc_map[IRQ_MATRIX_SIZE];
@@ -145,6 +146,27 @@ static unsigned int matrix_find_best_cpu(struct irq_matrix 
*m,
return best_cpu;
 }
 
+/* Find the best CPU which has the lowest number of managed IRQs allocated */
+static unsigned int matrix_find_best_cpu_managed(struct irq_matrix *m,
+   const struct cpumask *msk)
+{
+   unsigned int cpu, best_cpu, allocated = UINT_MAX;
+   struct cpumap *cm;
+
+   best_cpu = UINT_MAX;
+
+   for_each_cpu(cpu, msk) {
+   cm = per_cpu_ptr(m->maps, cpu);
+
+   if (!cm->online || cm->managed_allocated > allocated)
+   continue;
+
+   best_cpu = cpu;
+   allocated = cm->managed_allocated;
+   }
+   return best_cpu;
+}
+
 /**
  * irq_matrix_assign_system - Assign system wide entry in the matrix
  * @m: Matrix pointer
@@ -269,7 +291,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, const 
struct cpumask *msk,
if (cpumask_empty(msk))
return -EINVAL;
 
-   cpu = matrix_find_best_cpu(m, msk);
+   cpu = matrix_find_best_cpu_managed(m, msk);
if (cpu == UINT_MAX)
return -ENOSPC;
 
@@ -282,6 +304,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, const 
struct cpumask *msk,
return -ENOSPC;
set_bit(bit, cm->alloc_map);
cm->allocated++;
+   cm->managed_allocated++;
m->total_allocated++;
*mapped_cpu = cpu;
trace_irq_matrix_alloc_managed(bit, cpu, m, cm);
-- 
2.14.1

[PATCH v3] genirq/matrix: Choose CPU for managed IRQs based on how many of them are allocated

[Long Li]

From: Long Li 

On a large system with multiple devices of the same class (e.g. NVMe disks,
using managed IRQs), the kernel tends to concentrate their IRQs on several
CPUs.

The issue is that when NVMe calls irq_matrix_alloc_managed(), the assigned
CPU tends to be the first several CPUs in the cpumask, because they check for
cpumap->available that will not change after managed IRQs are reserved.

For a managed IRQ, it tends to reserve more than one CPU, based on cpumask in
irq_matrix_reserve_managed. But later when actually allocating CPU for this
IRQ, only one CPU is allocated. Because "available" is calculated at the time
managed IRQ is reserved, it tends to indicate a CPU has more IRQs than the 
actual
number it's assigned.

To get a more even distribution for allocating managed IRQs, we need to keep 
track
of how many of them are allocated on a given CPU. Introduce "managed_allocated"
in struct cpumap to track those managed IRQs that are allocated on this CPU, and
change the code to use this information for deciding how to allocate CPU for
managed IRQs.

Signed-off-by: Long Li 
---
 kernel/irq/matrix.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 6e6d467f3dec..94dd173f24d6 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -14,6 +14,7 @@ struct cpumap {
unsigned intavailable;
unsigned intallocated;
unsigned intmanaged;
+   unsigned intmanaged_allocated;
boolinitialized;
boolonline;
unsigned long   alloc_map[IRQ_MATRIX_SIZE];
@@ -145,6 +146,27 @@ static unsigned int matrix_find_best_cpu(struct irq_matrix 
*m,
return best_cpu;
 }
 
+/* Find the best CPU which has the lowest number of managed IRQs allocated */
+static unsigned int matrix_find_best_cpu_managed(struct irq_matrix *m,
+   const struct cpumask *msk)
+{
+   unsigned int cpu, best_cpu, allocated = UINT_MAX;
+   struct cpumap *cm;
+
+   best_cpu = UINT_MAX;
+
+   for_each_cpu(cpu, msk) {
+   cm = per_cpu_ptr(m->maps, cpu);
+
+   if (!cm->online || cm->managed_allocated > allocated)
+   continue;
+
+   best_cpu = cpu;
+   allocated = cm->managed_allocated;
+   }
+   return best_cpu;
+}
+
 /**
  * irq_matrix_assign_system - Assign system wide entry in the matrix
  * @m: Matrix pointer
@@ -269,7 +291,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, const 
struct cpumask *msk,
if (cpumask_empty(msk))
return -EINVAL;
 
-   cpu = matrix_find_best_cpu(m, msk);
+   cpu = matrix_find_best_cpu_managed(m, msk);
if (cpu == UINT_MAX)
return -ENOSPC;
 
@@ -282,6 +304,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, const 
struct cpumask *msk,
return -ENOSPC;
set_bit(bit, cm->alloc_map);
cm->allocated++;
+   cm->managed_allocated++;
m->total_allocated++;
*mapped_cpu = cpu;
trace_irq_matrix_alloc_managed(bit, cpu, m, cm);
-- 
2.14.1

Re: [PATCH v2] sched/core: Introduce set_next_task() helper for better code readability

[Muchun Song]

Hi, Peter

Thanks for your review.

Just update commit message. So there is no difference between them on the code.

Yours,
Muchun Song

Peter Zijlstra  于2018年11月2日周五 上午12:52写道：
>
>
>
> What if anything is the difference with v1 (which I found yesterday and
> have pending testing).

Re: [PATCH v2] sched/core: Introduce set_next_task() helper for better code readability

[Muchun Song]

Hi, Peter

Thanks for your review.

Just update commit message. So there is no difference between them on the code.

Yours,
Muchun Song

Peter Zijlstra  于2018年11月2日周五 上午12:52写道：
>
>
>
> What if anything is the difference with v1 (which I found yesterday and
> have pending testing).

Will the recent memory leak fixes be backported to longterm kernels?

[Dexuan Cui]

Hi all,
When debugging a memory leak issue (https://github.com/coreos/bugs/issues/2516)
with v4.14.11-coreos, we noticed the same issue may have been fixed recently by
Roman in the latest mainline (i.e. Linus's master branch) according to comment 
#7 of 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1792349, which lists these
patches (I'm not sure if the 5-patch list is complete):

010cb21d4ede math64: prevent double calculation of DIV64_U64_ROUND_UP() 
arguments
f77d7a05670d mm: don't miss the last page because of round-off error
d18bf0af683e mm: drain memcg stocks on css offlining
71cd51b2e1ca mm: rework memcg kernel stack accounting
f3a2fccbce15 mm: slowly shrink slabs with a relatively small number of objects

Obviously at least some of the fixes are also needed in the longterm kernels 
like v4.14.y,
but none of the 5 patches has the "Cc: sta...@vger.kernel.org" tag? I'm 
wondering if
these patches will be backported to the longterm kernels. BTW, the patches are 
not
in v4.19, but I suppose they will be in v4.19.1-rc1?

Thanks,
-- Dexuan

Will the recent memory leak fixes be backported to longterm kernels?

[Dexuan Cui]

Hi all,
When debugging a memory leak issue (https://github.com/coreos/bugs/issues/2516)
with v4.14.11-coreos, we noticed the same issue may have been fixed recently by
Roman in the latest mainline (i.e. Linus's master branch) according to comment 
#7 of 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1792349, which lists these
patches (I'm not sure if the 5-patch list is complete):

010cb21d4ede math64: prevent double calculation of DIV64_U64_ROUND_UP() 
arguments
f77d7a05670d mm: don't miss the last page because of round-off error
d18bf0af683e mm: drain memcg stocks on css offlining
71cd51b2e1ca mm: rework memcg kernel stack accounting
f3a2fccbce15 mm: slowly shrink slabs with a relatively small number of objects

Obviously at least some of the fixes are also needed in the longterm kernels 
like v4.14.y,
but none of the 5 patches has the "Cc: sta...@vger.kernel.org" tag? I'm 
wondering if
these patches will be backported to the longterm kernels. BTW, the patches are 
not
in v4.19, but I suppose they will be in v4.19.1-rc1?

Thanks,
-- Dexuan

Re: [PATCH] Make JFFS2 endianness configurable

[Daniel Walker]

On Thu, Nov 01, 2018 at 03:56:03PM -0700, Nikunj Kela wrote:
> This patch allows the endianness of the JFSS2 filesystem to be
> specified by config options.
> 
> It defaults to native-endian (the previously hard-coded option).
> 
> Some architectures benefit from having a single known endianness
> of JFFS2 filesystem (for data, not executables) independent of the
> endianness of the processor (ARM processors can be switched to either
> endianness at run-time).
> 


The description is pretty sad .. We have a product which we released that uses
JFFS2, and that product was release with a kernel in one endianness. Then later
on we decided to change the endianness and now we're stuck with a JFFS2
partition that has the wrong endiannes, in a released product. This patch allows
us to set the endianness to something different from the architecture setting.

So there a significant use case for the change, at least for Cisco.

Daniel

Re: [PATCH] Make JFFS2 endianness configurable

[Daniel Walker]

On Thu, Nov 01, 2018 at 03:56:03PM -0700, Nikunj Kela wrote:
> This patch allows the endianness of the JFSS2 filesystem to be
> specified by config options.
> 
> It defaults to native-endian (the previously hard-coded option).
> 
> Some architectures benefit from having a single known endianness
> of JFFS2 filesystem (for data, not executables) independent of the
> endianness of the processor (ARM processors can be switched to either
> endianness at run-time).
> 


The description is pretty sad .. We have a product which we released that uses
JFFS2, and that product was release with a kernel in one endianness. Then later
on we decided to change the endianness and now we're stuck with a JFFS2
partition that has the wrong endiannes, in a released product. This patch allows
us to set the endianness to something different from the architecture setting.

So there a significant use case for the change, at least for Cisco.

Daniel

Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE

[Matthew Wilcox]

On Thu, Nov 01, 2018 at 04:30:12PM -0700, Joe Perches wrote:
> On Thu, 2018-11-01 at 14:47 -0700, Andrew Morton wrote:
> > +++ a/mm/page_owner.c
> > @@ -351,7 +351,7 @@ print_page_owner(char __user *buf, size_
> > .skip = 0
> > };
> >  
> > -   count = count > PAGE_SIZE ? PAGE_SIZE : count;
> > +   count = min_t(size_t, count, PAGE_SIZE);
> > kbuf = kmalloc(count, GFP_KERNEL);
> > if (!kbuf)
> > return -ENOMEM;
> 
> A bit tidier still might be
> 
>   if (count > PAGE_SIZE)
>   count = PAGE_SIZE;
> 
> as that would not always cause a write back to count.

90% chance 'count' is already in a register and will stay there.  99.9%
chance that if it's not in a register, it's on the top of the stack,
which is by definition a hot, local, dirty cacheline.

What you're saying makes sense for a struct which might well be in a
shared cacheline state.  But for a function-local variable?  No.

Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE

[Matthew Wilcox]

On Thu, Nov 01, 2018 at 04:30:12PM -0700, Joe Perches wrote:
> On Thu, 2018-11-01 at 14:47 -0700, Andrew Morton wrote:
> > +++ a/mm/page_owner.c
> > @@ -351,7 +351,7 @@ print_page_owner(char __user *buf, size_
> > .skip = 0
> > };
> >  
> > -   count = count > PAGE_SIZE ? PAGE_SIZE : count;
> > +   count = min_t(size_t, count, PAGE_SIZE);
> > kbuf = kmalloc(count, GFP_KERNEL);
> > if (!kbuf)
> > return -ENOMEM;
> 
> A bit tidier still might be
> 
>   if (count > PAGE_SIZE)
>   count = PAGE_SIZE;
> 
> as that would not always cause a write back to count.

90% chance 'count' is already in a register and will stay there.  99.9%
chance that if it's not in a register, it's on the top of the stack,
which is by definition a hot, local, dirty cacheline.

What you're saying makes sense for a struct which might well be in a
shared cacheline state.  But for a function-local variable?  No.

Re: [git pull] mount API series

[David Howells]

Linus Torvalds  wrote:

> So if the patch series can be split up into a prep-phase that doesn't
> change any user-visible semantics (including the security side), but
> that uses the fs_context internally and allows the filesystems to be
> converted to the new world order, than that would make merging the
> early work much easier (and then my worry about the later phases would
> probably be much less too).

As a first go, I've rebased the patches to v4.19 (which required no other
changes), folded in some small bugfixes (fix error handling in remount, fix
incorrect user_ns in proc and mqueue) and split the set up.

There are now three branches in my git tree:

 (*) mount-api-core.  These are the internal-only patches that add the
 fs_context, the legacy wrapper and the security hooks and make certain
 filesystems make use of it.

 (*) mount-api-uapi.  This is mount-api-core with the UAPI-visible patches
 stacked thereon.

 (*) mount-api.  This is the original patchset.

"git diff mount-api mount-api-uapi" shows no differences.

Note that the commit "vfs: Implement logging through fs_context" appears in
both sets.  I was just going to leave it as macros that just wrap pr_notice(),
but I think it might be wiser to pull it out of line (as will be required
later) and make it produce messages at different levels.

The git tree in question is at:

https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git

David

Re: [git pull] mount API series

[David Howells]

Linus Torvalds  wrote:

> So if the patch series can be split up into a prep-phase that doesn't
> change any user-visible semantics (including the security side), but
> that uses the fs_context internally and allows the filesystems to be
> converted to the new world order, than that would make merging the
> early work much easier (and then my worry about the later phases would
> probably be much less too).

As a first go, I've rebased the patches to v4.19 (which required no other
changes), folded in some small bugfixes (fix error handling in remount, fix
incorrect user_ns in proc and mqueue) and split the set up.

There are now three branches in my git tree:

 (*) mount-api-core.  These are the internal-only patches that add the
 fs_context, the legacy wrapper and the security hooks and make certain
 filesystems make use of it.

 (*) mount-api-uapi.  This is mount-api-core with the UAPI-visible patches
 stacked thereon.

 (*) mount-api.  This is the original patchset.

"git diff mount-api mount-api-uapi" shows no differences.

Note that the commit "vfs: Implement logging through fs_context" appears in
both sets.  I was just going to leave it as macros that just wrap pr_notice(),
but I think it might be wiser to pull it out of line (as will be required
later) and make it produce messages at different levels.

The git tree in question is at:

https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git

David

Re: [PATCH] clk: fixed-factor: fix of_node_get-put imbalance

[Stephen Boyd]

Quoting Ricardo Ribalda Delgado (2018-11-01 06:15:49)
> When the fixed factor clock is created by devicetree,
> of_clk_add_provider is called.  Add a call to
> of_clk_del_provider in the remove function to balance
> it out.
> 
> Reported-by: Alan Tull 
> Fixes: 971451b3b15d ("clk: fixed-factor: Convert into a module platform 
> driver")
> Signed-off-by: Ricardo Ribalda Delgado 
> ---

Looks good. I'll queue this up for clk-fixes next week.

Re: [PATCH] clk: fixed-factor: fix of_node_get-put imbalance

[Stephen Boyd]

Quoting Ricardo Ribalda Delgado (2018-11-01 06:15:49)
> When the fixed factor clock is created by devicetree,
> of_clk_add_provider is called.  Add a call to
> of_clk_del_provider in the remove function to balance
> it out.
> 
> Reported-by: Alan Tull 
> Fixes: 971451b3b15d ("clk: fixed-factor: Convert into a module platform 
> driver")
> Signed-off-by: Ricardo Ribalda Delgado 
> ---

Looks good. I'll queue this up for clk-fixes next week.

[PATCH linux-next 1/8] pstore/ram: Standardize module name in ramoops

[Kees Cook]

With both ram.c and ram_core.c built into ramoops.ko, it doesn't make
sense to have differing pr_fmt prefixes. This fixes ram_core.c to use
the module name (as ram.c already does). Additionally improves region
reservation error to include the region name.

Signed-off-by: Kees Cook 
---
 fs/pstore/ram_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 23ca6f2c98a0..f5d0173901aa 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -12,7 +12,7 @@
  *
  */
 
-#define pr_fmt(fmt) "persistent_ram: " fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
 #include 
@@ -443,7 +443,8 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t 
size,
void *va;
 
if (!request_mem_region(start, size, label ?: "ramoops")) {
-   pr_err("request mem region (0x%llx@0x%llx) failed\n",
+   pr_err("request mem region (%s 0x%llx@0x%llx) failed\n",
+   label ?: "ramoops",
(unsigned long long)size, (unsigned long long)start);
return NULL;
}
-- 
2.17.1

[PATCH 6/8] pstore: Replace open-coded << with BIT()

[Kees Cook]

Minor clean-up to use BIT() (as already done in pstore_ram.h).

Signed-off-by: Kees Cook 
---
 include/linux/pstore.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 877ed81de346..3549f2ba865c 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -189,10 +189,10 @@ struct pstore_info {
 };
 
 /* Supported frontends */
-#define PSTORE_FLAGS_DMESG (1 << 0)
-#define PSTORE_FLAGS_CONSOLE   (1 << 1)
-#define PSTORE_FLAGS_FTRACE(1 << 2)
-#define PSTORE_FLAGS_PMSG  (1 << 3)
+#define PSTORE_FLAGS_DMESG BIT(0)
+#define PSTORE_FLAGS_CONSOLE   BIT(1)
+#define PSTORE_FLAGS_FTRACEBIT(2)
+#define PSTORE_FLAGS_PMSG  BIT(3)
 
 extern int pstore_register(struct pstore_info *);
 extern void pstore_unregister(struct pstore_info *);
-- 
2.17.1

[PATCH 2/8] pstore: Do not use crash buffer for decompression

[Kees Cook]

The pre-allocated compression buffer used for crash dumping was also
being used for decompression. This isn't technically safe, since it's
possible the kernel may attempt a crashdump while pstore is populating the
pstore filesystem (and performing decompression). Instead, just allocate
a separate buffer for decompression. Correctness is preferred over
performance here.

Signed-off-by: Kees Cook 
---
 fs/pstore/platform.c | 56 
 1 file changed, 25 insertions(+), 31 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index b821054ca3ed..8b6028948cf3 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -258,20 +258,6 @@ static int pstore_compress(const void *in, void *out,
return outlen;
 }
 
-static int pstore_decompress(void *in, void *out,
-unsigned int inlen, unsigned int outlen)
-{
-   int ret;
-
-   ret = crypto_comp_decompress(tfm, in, inlen, out, );
-   if (ret) {
-   pr_err("crypto_comp_decompress failed, ret = %d!\n", ret);
-   return ret;
-   }
-
-   return outlen;
-}
-
 static void allocate_buf_for_compression(void)
 {
struct crypto_comp *ctx;
@@ -656,8 +642,9 @@ EXPORT_SYMBOL_GPL(pstore_unregister);
 
 static void decompress_record(struct pstore_record *record)
 {
+   int ret;
int unzipped_len;
-   char *decompressed;
+   char *unzipped, *workspace;
 
if (!record->compressed)
return;
@@ -668,35 +655,42 @@ static void decompress_record(struct pstore_record 
*record)
return;
}
 
-   /* No compression method has created the common buffer. */
+   /* Missing compression buffer means compression was not initialized. */
if (!big_oops_buf) {
-   pr_warn("no decompression buffer allocated\n");
+   pr_warn("no decompression method initialized!\n");
return;
}
 
-   unzipped_len = pstore_decompress(record->buf, big_oops_buf,
-record->size, big_oops_buf_sz);
-   if (unzipped_len <= 0) {
-   pr_err("decompression failed: %d\n", unzipped_len);
+   /* Allocate enough space to hold max decompression and ECC. */
+   unzipped_len = big_oops_buf_sz;
+   workspace = kmalloc(unzipped_len + record->ecc_notice_size,
+   GFP_KERNEL);
+   if (!workspace)
return;
-   }
 
-   /* Build new buffer for decompressed contents. */
-   decompressed = kmalloc(unzipped_len + record->ecc_notice_size,
-  GFP_KERNEL);
-   if (!decompressed) {
-   pr_err("decompression ran out of memory\n");
+   /* After decompression "unzipped_len" is almost certainly smaller. */
+   ret = crypto_comp_decompress(tfm, record->buf, record->size,
+ workspace, _len);
+   if (ret) {
+   pr_err("crypto_comp_decompress failed, ret = %d!\n", ret);
+   kfree(workspace);
return;
}
-   memcpy(decompressed, big_oops_buf, unzipped_len);
 
/* Append ECC notice to decompressed buffer. */
-   memcpy(decompressed + unzipped_len, record->buf + record->size,
+   memcpy(workspace + unzipped_len, record->buf + record->size,
   record->ecc_notice_size);
 
-   /* Swap out compresed contents with decompressed contents. */
+   /* Copy decompressed contents into an minimum-sized allocation. */
+   unzipped = kmemdup(workspace, unzipped_len + record->ecc_notice_size,
+  GFP_KERNEL);
+   kfree(workspace);
+   if (!unzipped)
+   return;
+
+   /* Swap out compressed contents with decompressed contents. */
kfree(record->buf);
-   record->buf = decompressed;
+   record->buf = unzipped;
record->size = unzipped_len;
record->compressed = false;
 }
-- 
2.17.1

[PATCH 2/8] pstore: Do not use crash buffer for decompression

[Kees Cook]

The pre-allocated compression buffer used for crash dumping was also
being used for decompression. This isn't technically safe, since it's
possible the kernel may attempt a crashdump while pstore is populating the
pstore filesystem (and performing decompression). Instead, just allocate
a separate buffer for decompression. Correctness is preferred over
performance here.

Signed-off-by: Kees Cook 
---
 fs/pstore/platform.c | 56 
 1 file changed, 25 insertions(+), 31 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index b821054ca3ed..8b6028948cf3 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -258,20 +258,6 @@ static int pstore_compress(const void *in, void *out,
return outlen;
 }
 
-static int pstore_decompress(void *in, void *out,
-unsigned int inlen, unsigned int outlen)
-{
-   int ret;
-
-   ret = crypto_comp_decompress(tfm, in, inlen, out, );
-   if (ret) {
-   pr_err("crypto_comp_decompress failed, ret = %d!\n", ret);
-   return ret;
-   }
-
-   return outlen;
-}
-
 static void allocate_buf_for_compression(void)
 {
struct crypto_comp *ctx;
@@ -656,8 +642,9 @@ EXPORT_SYMBOL_GPL(pstore_unregister);
 
 static void decompress_record(struct pstore_record *record)
 {
+   int ret;
int unzipped_len;
-   char *decompressed;
+   char *unzipped, *workspace;
 
if (!record->compressed)
return;
@@ -668,35 +655,42 @@ static void decompress_record(struct pstore_record 
*record)
return;
}
 
-   /* No compression method has created the common buffer. */
+   /* Missing compression buffer means compression was not initialized. */
if (!big_oops_buf) {
-   pr_warn("no decompression buffer allocated\n");
+   pr_warn("no decompression method initialized!\n");
return;
}
 
-   unzipped_len = pstore_decompress(record->buf, big_oops_buf,
-record->size, big_oops_buf_sz);
-   if (unzipped_len <= 0) {
-   pr_err("decompression failed: %d\n", unzipped_len);
+   /* Allocate enough space to hold max decompression and ECC. */
+   unzipped_len = big_oops_buf_sz;
+   workspace = kmalloc(unzipped_len + record->ecc_notice_size,
+   GFP_KERNEL);
+   if (!workspace)
return;
-   }
 
-   /* Build new buffer for decompressed contents. */
-   decompressed = kmalloc(unzipped_len + record->ecc_notice_size,
-  GFP_KERNEL);
-   if (!decompressed) {
-   pr_err("decompression ran out of memory\n");
+   /* After decompression "unzipped_len" is almost certainly smaller. */
+   ret = crypto_comp_decompress(tfm, record->buf, record->size,
+ workspace, _len);
+   if (ret) {
+   pr_err("crypto_comp_decompress failed, ret = %d!\n", ret);
+   kfree(workspace);
return;
}
-   memcpy(decompressed, big_oops_buf, unzipped_len);
 
/* Append ECC notice to decompressed buffer. */
-   memcpy(decompressed + unzipped_len, record->buf + record->size,
+   memcpy(workspace + unzipped_len, record->buf + record->size,
   record->ecc_notice_size);
 
-   /* Swap out compresed contents with decompressed contents. */
+   /* Copy decompressed contents into an minimum-sized allocation. */
+   unzipped = kmemdup(workspace, unzipped_len + record->ecc_notice_size,
+  GFP_KERNEL);
+   kfree(workspace);
+   if (!unzipped)
+   return;
+
+   /* Swap out compressed contents with decompressed contents. */
kfree(record->buf);
-   record->buf = decompressed;
+   record->buf = unzipped;
record->size = unzipped_len;
record->compressed = false;
 }
-- 
2.17.1

[PATCH linux-next 1/8] pstore/ram: Standardize module name in ramoops

[Kees Cook]

With both ram.c and ram_core.c built into ramoops.ko, it doesn't make
sense to have differing pr_fmt prefixes. This fixes ram_core.c to use
the module name (as ram.c already does). Additionally improves region
reservation error to include the region name.

Signed-off-by: Kees Cook 
---
 fs/pstore/ram_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 23ca6f2c98a0..f5d0173901aa 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -12,7 +12,7 @@
  *
  */
 
-#define pr_fmt(fmt) "persistent_ram: " fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
 #include 
@@ -443,7 +443,8 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t 
size,
void *va;
 
if (!request_mem_region(start, size, label ?: "ramoops")) {
-   pr_err("request mem region (0x%llx@0x%llx) failed\n",
+   pr_err("request mem region (%s 0x%llx@0x%llx) failed\n",
+   label ?: "ramoops",
(unsigned long long)size, (unsigned long long)start);
return NULL;
}
-- 
2.17.1

[PATCH 6/8] pstore: Replace open-coded << with BIT()

[Kees Cook]

Minor clean-up to use BIT() (as already done in pstore_ram.h).

Signed-off-by: Kees Cook 
---
 include/linux/pstore.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 877ed81de346..3549f2ba865c 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -189,10 +189,10 @@ struct pstore_info {
 };
 
 /* Supported frontends */
-#define PSTORE_FLAGS_DMESG (1 << 0)
-#define PSTORE_FLAGS_CONSOLE   (1 << 1)
-#define PSTORE_FLAGS_FTRACE(1 << 2)
-#define PSTORE_FLAGS_PMSG  (1 << 3)
+#define PSTORE_FLAGS_DMESG BIT(0)
+#define PSTORE_FLAGS_CONSOLE   BIT(1)
+#define PSTORE_FLAGS_FTRACEBIT(2)
+#define PSTORE_FLAGS_PMSG  BIT(3)
 
 extern int pstore_register(struct pstore_info *);
 extern void pstore_unregister(struct pstore_info *);
-- 
2.17.1

[PATCH] genirq/affinity: Spread IRQs to all available NUMA nodes

[Long Li]

From: Long Li 

On systems with large number of NUMA nodes, there may be more NUMA nodes than
the number of MSI/MSI-X interrupts that device requests for. The current code
always picks up the NUMA nodes starting from the node 0, up to the number of
interrupts requested. This may left some later NUMA nodes unused.

For example, if the system has 16 NUMA nodes, and the device reqeusts for 8
interrupts, NUMA node 0 to 7 are assigned for those interrupts, NUMA 8 to 15
are unused.

There are several problems with this approach:
1. Later, when those managed IRQs are allocated, they can not be assigned to
NUMA 8 to 15, this may create an IRQ concentration on NUMA 0 to 7.
2. Some upper layers assume affinity mask has a complete coverage over NUMA 
nodes.
For example, block layer use the affinity mask to decide how to map CPU queues 
to
hardware queues, missing NUMA nodes in the masks may result in an uneven mapping
of queues. For the above example of 16 NUMA nodes, CPU queues on NUMA node 0 to 
7
are assigned to the hardware queues 0 to 7, respectively. But CPU queues on NUMA
node 8 to 15 are all assigned to the hardware queue 0.

Fix this problem by going over all NUMA nodes and assign them round-robin to
all IRQs.

Signed-off-by: Long Li 
---
 kernel/irq/affinity.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index f4f29b9d90ee..2d08b560d4b6 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -117,12 +117,13 @@ static int irq_build_affinity_masks(const struct 
irq_affinity *affd,
 */
if (numvecs <= nodes) {
for_each_node_mask(n, nodemsk) {
-   cpumask_copy(masks + curvec, node_to_cpumask[n]);
-   if (++done == numvecs)
-   break;
+   cpumask_or(masks + curvec, masks + curvec, 
node_to_cpumask[n]);
+   done++;
if (++curvec == last_affv)
curvec = affd->pre_vectors;
}
+   if (done > numvecs)
+   done = numvecs;
goto out;
}
 
-- 
2.14.1

[PATCH] genirq/affinity: Spread IRQs to all available NUMA nodes

[Long Li]

From: Long Li 

On systems with large number of NUMA nodes, there may be more NUMA nodes than
the number of MSI/MSI-X interrupts that device requests for. The current code
always picks up the NUMA nodes starting from the node 0, up to the number of
interrupts requested. This may left some later NUMA nodes unused.

For example, if the system has 16 NUMA nodes, and the device reqeusts for 8
interrupts, NUMA node 0 to 7 are assigned for those interrupts, NUMA 8 to 15
are unused.

There are several problems with this approach:
1. Later, when those managed IRQs are allocated, they can not be assigned to
NUMA 8 to 15, this may create an IRQ concentration on NUMA 0 to 7.
2. Some upper layers assume affinity mask has a complete coverage over NUMA 
nodes.
For example, block layer use the affinity mask to decide how to map CPU queues 
to
hardware queues, missing NUMA nodes in the masks may result in an uneven mapping
of queues. For the above example of 16 NUMA nodes, CPU queues on NUMA node 0 to 
7
are assigned to the hardware queues 0 to 7, respectively. But CPU queues on NUMA
node 8 to 15 are all assigned to the hardware queue 0.

Fix this problem by going over all NUMA nodes and assign them round-robin to
all IRQs.

Signed-off-by: Long Li 
---
 kernel/irq/affinity.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index f4f29b9d90ee..2d08b560d4b6 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -117,12 +117,13 @@ static int irq_build_affinity_masks(const struct 
irq_affinity *affd,
 */
if (numvecs <= nodes) {
for_each_node_mask(n, nodemsk) {
-   cpumask_copy(masks + curvec, node_to_cpumask[n]);
-   if (++done == numvecs)
-   break;
+   cpumask_or(masks + curvec, masks + curvec, 
node_to_cpumask[n]);
+   done++;
if (++curvec == last_affv)
curvec = affd->pre_vectors;
}
+   if (done > numvecs)
+   done = numvecs;
goto out;
}
 
-- 
2.14.1

[PATCH 7/8] pstore: Remove needless lock during console writes

[Kees Cook]

Since commit 70ad35db3321 ("pstore: Convert console write to use
->write_buf"), the console writer does not use the preallocated crash
dump buffer any more, so there is no reason to perform locking around it.

Signed-off-by: Kees Cook 
---
 fs/pstore/platform.c | 29 ++---
 1 file changed, 6 insertions(+), 23 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index a956c7bc3f67..32340e7dd6a5 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -461,31 +461,14 @@ static void pstore_unregister_kmsg(void)
 #ifdef CONFIG_PSTORE_CONSOLE
 static void pstore_console_write(struct console *con, const char *s, unsigned 
c)
 {
-   const char *e = s + c;
+   struct pstore_record record;
 
-   while (s < e) {
-   struct pstore_record record;
-   unsigned long flags;
-
-   pstore_record_init(, psinfo);
-   record.type = PSTORE_TYPE_CONSOLE;
-
-   if (c > psinfo->bufsize)
-   c = psinfo->bufsize;
+   pstore_record_init(, psinfo);
+   record.type = PSTORE_TYPE_CONSOLE;
 
-   if (oops_in_progress) {
-   if (!spin_trylock_irqsave(>buf_lock, flags))
-   break;
-   } else {
-   spin_lock_irqsave(>buf_lock, flags);
-   }
-   record.buf = (char *)s;
-   record.size = c;
-   psinfo->write();
-   spin_unlock_irqrestore(>buf_lock, flags);
-   s += c;
-   c = e - s;
-   }
+   record.buf = (char *)s;
+   record.size = c;
+   psinfo->write();
 }
 
 static struct console pstore_console = {
-- 
2.17.1

[PATCH 3/8] pstore/ram: Report backend assignments with finer granularity

[Kees Cook]

In order to more easily perform automated regression testing, this
adds pr_debug() calls to report each prz allocation which can then be
verified against persistent storage. Specifically, seeing the dividing
line between header, data, any ECC bytes. (And the general assignment
output is updated to remove the bogus ECC blocksize which isn't actually
recorded outside the prz instance.)

Signed-off-by: Kees Cook 
---
 fs/pstore/ram.c  | 4 ++--
 fs/pstore/ram_core.c | 6 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index b51901f97dc2..25bede911809 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -856,9 +856,9 @@ static int ramoops_probe(struct platform_device *pdev)
ramoops_pmsg_size = pdata->pmsg_size;
ramoops_ftrace_size = pdata->ftrace_size;
 
-   pr_info("attached 0x%lx@0x%llx, ecc: %d/%d\n",
+   pr_info("using 0x%lx@0x%llx, ecc: %d\n",
cxt->size, (unsigned long long)cxt->phys_addr,
-   cxt->ecc_info.ecc_size, cxt->ecc_info.block_size);
+   cxt->ecc_info.ecc_size);
 
return 0;
 
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index f5d0173901aa..d5bf9be82545 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -576,6 +576,12 @@ struct persistent_ram_zone *persistent_ram_new(phys_addr_t 
start, size_t size,
if (ret)
goto err;
 
+   pr_debug("attached %s 0x%lx@0x%llx: %lu header, %lu data, %lu ecc 
(%d/%d)\n",
+   prz->label, prz->size, (unsigned long long)prz->paddr,
+   sizeof(*prz->buffer), prz->buffer_size,
+   prz->size - sizeof(*prz->buffer) - prz->buffer_size,
+   prz->ecc_info.ecc_size, prz->ecc_info.block_size);
+
return prz;
 err:
persistent_ram_free(prz);
-- 
2.17.1

[PATCH 4/8] pstore/ram: Add kern-doc for struct persistent_ram_zone

[Kees Cook]

The struct persistent_ram_zone wasn't well documented. This adds kern-doc
for it.

Signed-off-by: Kees Cook 
---
 fs/pstore/ram_core.c   | 10 +
 include/linux/pstore_ram.h | 46 +++---
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index d5bf9be82545..1cda5922b4b4 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -29,6 +29,16 @@
 #include 
 #include 
 
+/**
+ * struct persistent_ram_buffer - persistent circular RAM buffer
+ *
+ * @sig:
+ * signature to indicate header (PERSISTENT_RAM_SIG xor PRZ-type value)
+ * @start:
+ * offset into @data where the beginning of the stored bytes begin
+ * @size:
+ * number of valid bytes stored in @data
+ */
 struct persistent_ram_buffer {
uint32_tsig;
atomic_tstart;
diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
index 6e94980357d2..5d10ad51c1c4 100644
--- a/include/linux/pstore_ram.h
+++ b/include/linux/pstore_ram.h
@@ -30,6 +30,10 @@
  * PRZ_FLAG_NO_LOCK is used. For all other cases, locking is required.
  */
 #define PRZ_FLAG_NO_LOCK   BIT(0)
+/*
+ * If a PRZ should only have a single-boot lifetime, this marks it as
+ * getting wiped after its contents get copied out after boot.
+ */
 #define PRZ_FLAG_ZAP_OLD   BIT(1)
 
 struct persistent_ram_buffer;
@@ -43,17 +47,53 @@ struct persistent_ram_ecc_info {
uint16_t *par;
 };
 
+/**
+ * struct persistent_ram_zone - Details of a persistent RAM zone (PRZ)
+ *  used as a pstore backend
+ *
+ * @paddr: physical address of the mapped RAM area
+ * @size:  size of mapping
+ * @label: unique name of this PRZ
+ * @flags: holds PRZ_FLAGS_* bits
+ *
+ * @buffer_lock:
+ * locks access to @buffer "size" bytes and "start" offset
+ * @buffer:
+ * pointer to actual RAM area managed by this PRZ
+ * @buffer_size:
+ * bytes in @buffer->data (not including any trailing ECC bytes)
+ *
+ * @par_buffer:
+ * pointer into @buffer->data containing ECC bytes for @buffer->data
+ * @par_header:
+ * pointer into @buffer->data containing ECC bytes for @buffer header
+ * (i.e. all fields up to @data)
+ * @rs_decoder:
+ * RSLIB instance for doing ECC calculations
+ * @corrected_bytes:
+ * ECC corrected bytes accounting since boot
+ * @bad_blocks:
+ * ECC uncorrectable bytes accounting since boot
+ * @ecc_info:
+ * ECC configuration details
+ *
+ * @old_log:
+ * saved copy of @buffer->data prior to most recent wipe
+ * @old_log_size:
+ * bytes contained in @old_log
+ *
+ */
 struct persistent_ram_zone {
phys_addr_t paddr;
size_t size;
void *vaddr;
char *label;
-   struct persistent_ram_buffer *buffer;
-   size_t buffer_size;
u32 flags;
+
raw_spinlock_t buffer_lock;
+   struct persistent_ram_buffer *buffer;
+   size_t buffer_size;
 
-   /* ECC correction */
char *par_buffer;
char *par_header;
struct rs_control *rs_decoder;
-- 
2.17.1

[PATCH 0/8] pstore improvements (pstore-next)

[Kees Cook]

This is a posting of several patches I've been working on to improve
pstore. Most of it is better comments, output, and naming, but one
bug fix stands out to fix head-truncationg of compressed records.
Details in the individual patches. Review appreciated! :)

-Kees

Kees Cook (8):
  pstore/ram: Standardize module name in ramoops
  pstore: Do not use crash buffer for decompression
  pstore/ram: Report backend assignments with finer granularity
  pstore/ram: Add kern-doc for struct persistent_ram_zone
  pstore: Improve and update some comments and status output
  pstore: Replace open-coded << with BIT()
  pstore: Remove needless lock during console writes
  pstore/ram: Correctly calculate usable PRZ bytes

 fs/pstore/platform.c   | 92 ++
 fs/pstore/ram.c| 19 
 fs/pstore/ram_core.c   | 25 +--
 include/linux/pstore.h | 15 ---
 include/linux/pstore_ram.h | 46 +--
 5 files changed, 116 insertions(+), 81 deletions(-)

-- 
2.17.1

[PATCH 8/8] pstore/ram: Correctly calculate usable PRZ bytes

[Kees Cook]

The actual number of bytes stored in a PRZ is smaller than the
bytes requested by platform data, since there is a header on each
PRZ. Additionally, if ECC is enabled, there are trailing bytes used
as well. Normally this mismatch doesn't matter since PRZs are circular
buffers and the leading "overflow" bytes are just thrown away. However, in
the case of a compressed record, this rather badly corrupts the results.

This corruption was visible with "ramoops.mem_size=204800 ramoops.ecc=1".
Any stored crashes would not be uncompressable (producing a pstorefs
"dmesg-*.enc.z" file), and triggering errors at boot:

  [2.790759] pstore: crypto_comp_decompress failed, ret = -22!

Reported-by: Joel Fernandes 
Fixes: b0aad7a99c1d ("pstore: Add compression support to pstore")
Signed-off-by: Kees Cook 
---
 fs/pstore/ram.c| 15 ++-
 include/linux/pstore.h |  5 -
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 25bede911809..10ac4d23c423 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -814,17 +814,14 @@ static int ramoops_probe(struct platform_device *pdev)
 
cxt->pstore.data = cxt;
/*
-* Console can handle any buffer size, so prefer LOG_LINE_MAX. If we
-* have to handle dumps, we must have at least record_size buffer. And
-* for ftrace, bufsize is irrelevant (if bufsize is 0, buf will be
-* ZERO_SIZE_PTR).
+* Since bufsize is only used for dmesg crash dumps, it
+* must match the size of the dprz record (after PRZ header
+* and ECC bytes have been accounted for).
 */
-   if (cxt->console_size)
-   cxt->pstore.bufsize = 1024; /* LOG_LINE_MAX */
-   cxt->pstore.bufsize = max(cxt->record_size, cxt->pstore.bufsize);
-   cxt->pstore.buf = kmalloc(cxt->pstore.bufsize, GFP_KERNEL);
+   cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size;
+   cxt->pstore.buf = kzalloc(cxt->pstore.bufsize, GFP_KERNEL);
if (!cxt->pstore.buf) {
-   pr_err("cannot allocate pstore buffer\n");
+   pr_err("cannot allocate pstore crash dump buffer\n");
err = -ENOMEM;
goto fail_clear;
}
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 3549f2ba865c..f46e5df76b58 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -90,7 +90,10 @@ struct pstore_record {
  *
  * @buf_lock:  spinlock to serialize access to @buf
  * @buf:   preallocated crash dump buffer
- * @bufsize:   size of @buf available for crash dump writes
+ * @bufsize:   size of @buf available for crash dump bytes (must match
+ * smallest number of bytes available for writing to a
+ * backend entry, since compressed bytes don't take kindly
+ * to being truncated)
  *
  * @read_mutex:serializes @open, @read, @close, and @erase callbacks
  * @flags: bitfield of frontends the backend can accept writes for
-- 
2.17.1

[PATCH 7/8] pstore: Remove needless lock during console writes

[Kees Cook]

Since commit 70ad35db3321 ("pstore: Convert console write to use
->write_buf"), the console writer does not use the preallocated crash
dump buffer any more, so there is no reason to perform locking around it.

Signed-off-by: Kees Cook 
---
 fs/pstore/platform.c | 29 ++---
 1 file changed, 6 insertions(+), 23 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index a956c7bc3f67..32340e7dd6a5 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -461,31 +461,14 @@ static void pstore_unregister_kmsg(void)
 #ifdef CONFIG_PSTORE_CONSOLE
 static void pstore_console_write(struct console *con, const char *s, unsigned 
c)
 {
-   const char *e = s + c;
+   struct pstore_record record;
 
-   while (s < e) {
-   struct pstore_record record;
-   unsigned long flags;
-
-   pstore_record_init(, psinfo);
-   record.type = PSTORE_TYPE_CONSOLE;
-
-   if (c > psinfo->bufsize)
-   c = psinfo->bufsize;
+   pstore_record_init(, psinfo);
+   record.type = PSTORE_TYPE_CONSOLE;
 
-   if (oops_in_progress) {
-   if (!spin_trylock_irqsave(>buf_lock, flags))
-   break;
-   } else {
-   spin_lock_irqsave(>buf_lock, flags);
-   }
-   record.buf = (char *)s;
-   record.size = c;
-   psinfo->write();
-   spin_unlock_irqrestore(>buf_lock, flags);
-   s += c;
-   c = e - s;
-   }
+   record.buf = (char *)s;
+   record.size = c;
+   psinfo->write();
 }
 
 static struct console pstore_console = {
-- 
2.17.1

[PATCH 3/8] pstore/ram: Report backend assignments with finer granularity

[Kees Cook]

In order to more easily perform automated regression testing, this
adds pr_debug() calls to report each prz allocation which can then be
verified against persistent storage. Specifically, seeing the dividing
line between header, data, any ECC bytes. (And the general assignment
output is updated to remove the bogus ECC blocksize which isn't actually
recorded outside the prz instance.)

Signed-off-by: Kees Cook 
---
 fs/pstore/ram.c  | 4 ++--
 fs/pstore/ram_core.c | 6 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index b51901f97dc2..25bede911809 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -856,9 +856,9 @@ static int ramoops_probe(struct platform_device *pdev)
ramoops_pmsg_size = pdata->pmsg_size;
ramoops_ftrace_size = pdata->ftrace_size;
 
-   pr_info("attached 0x%lx@0x%llx, ecc: %d/%d\n",
+   pr_info("using 0x%lx@0x%llx, ecc: %d\n",
cxt->size, (unsigned long long)cxt->phys_addr,
-   cxt->ecc_info.ecc_size, cxt->ecc_info.block_size);
+   cxt->ecc_info.ecc_size);
 
return 0;
 
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index f5d0173901aa..d5bf9be82545 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -576,6 +576,12 @@ struct persistent_ram_zone *persistent_ram_new(phys_addr_t 
start, size_t size,
if (ret)
goto err;
 
+   pr_debug("attached %s 0x%lx@0x%llx: %lu header, %lu data, %lu ecc 
(%d/%d)\n",
+   prz->label, prz->size, (unsigned long long)prz->paddr,
+   sizeof(*prz->buffer), prz->buffer_size,
+   prz->size - sizeof(*prz->buffer) - prz->buffer_size,
+   prz->ecc_info.ecc_size, prz->ecc_info.block_size);
+
return prz;
 err:
persistent_ram_free(prz);
-- 
2.17.1

[PATCH 4/8] pstore/ram: Add kern-doc for struct persistent_ram_zone

[Kees Cook]

The struct persistent_ram_zone wasn't well documented. This adds kern-doc
for it.

Signed-off-by: Kees Cook 
---
 fs/pstore/ram_core.c   | 10 +
 include/linux/pstore_ram.h | 46 +++---
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index d5bf9be82545..1cda5922b4b4 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -29,6 +29,16 @@
 #include 
 #include 
 
+/**
+ * struct persistent_ram_buffer - persistent circular RAM buffer
+ *
+ * @sig:
+ * signature to indicate header (PERSISTENT_RAM_SIG xor PRZ-type value)
+ * @start:
+ * offset into @data where the beginning of the stored bytes begin
+ * @size:
+ * number of valid bytes stored in @data
+ */
 struct persistent_ram_buffer {
uint32_tsig;
atomic_tstart;
diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
index 6e94980357d2..5d10ad51c1c4 100644
--- a/include/linux/pstore_ram.h
+++ b/include/linux/pstore_ram.h
@@ -30,6 +30,10 @@
  * PRZ_FLAG_NO_LOCK is used. For all other cases, locking is required.
  */
 #define PRZ_FLAG_NO_LOCK   BIT(0)
+/*
+ * If a PRZ should only have a single-boot lifetime, this marks it as
+ * getting wiped after its contents get copied out after boot.
+ */
 #define PRZ_FLAG_ZAP_OLD   BIT(1)
 
 struct persistent_ram_buffer;
@@ -43,17 +47,53 @@ struct persistent_ram_ecc_info {
uint16_t *par;
 };
 
+/**
+ * struct persistent_ram_zone - Details of a persistent RAM zone (PRZ)
+ *  used as a pstore backend
+ *
+ * @paddr: physical address of the mapped RAM area
+ * @size:  size of mapping
+ * @label: unique name of this PRZ
+ * @flags: holds PRZ_FLAGS_* bits
+ *
+ * @buffer_lock:
+ * locks access to @buffer "size" bytes and "start" offset
+ * @buffer:
+ * pointer to actual RAM area managed by this PRZ
+ * @buffer_size:
+ * bytes in @buffer->data (not including any trailing ECC bytes)
+ *
+ * @par_buffer:
+ * pointer into @buffer->data containing ECC bytes for @buffer->data
+ * @par_header:
+ * pointer into @buffer->data containing ECC bytes for @buffer header
+ * (i.e. all fields up to @data)
+ * @rs_decoder:
+ * RSLIB instance for doing ECC calculations
+ * @corrected_bytes:
+ * ECC corrected bytes accounting since boot
+ * @bad_blocks:
+ * ECC uncorrectable bytes accounting since boot
+ * @ecc_info:
+ * ECC configuration details
+ *
+ * @old_log:
+ * saved copy of @buffer->data prior to most recent wipe
+ * @old_log_size:
+ * bytes contained in @old_log
+ *
+ */
 struct persistent_ram_zone {
phys_addr_t paddr;
size_t size;
void *vaddr;
char *label;
-   struct persistent_ram_buffer *buffer;
-   size_t buffer_size;
u32 flags;
+
raw_spinlock_t buffer_lock;
+   struct persistent_ram_buffer *buffer;
+   size_t buffer_size;
 
-   /* ECC correction */
char *par_buffer;
char *par_header;
struct rs_control *rs_decoder;
-- 
2.17.1

[PATCH 0/8] pstore improvements (pstore-next)

[Kees Cook]

This is a posting of several patches I've been working on to improve
pstore. Most of it is better comments, output, and naming, but one
bug fix stands out to fix head-truncationg of compressed records.
Details in the individual patches. Review appreciated! :)

-Kees

Kees Cook (8):
  pstore/ram: Standardize module name in ramoops
  pstore: Do not use crash buffer for decompression
  pstore/ram: Report backend assignments with finer granularity
  pstore/ram: Add kern-doc for struct persistent_ram_zone
  pstore: Improve and update some comments and status output
  pstore: Replace open-coded << with BIT()
  pstore: Remove needless lock during console writes
  pstore/ram: Correctly calculate usable PRZ bytes

 fs/pstore/platform.c   | 92 ++
 fs/pstore/ram.c| 19 
 fs/pstore/ram_core.c   | 25 +--
 include/linux/pstore.h | 15 ---
 include/linux/pstore_ram.h | 46 +--
 5 files changed, 116 insertions(+), 81 deletions(-)

-- 
2.17.1

[PATCH 8/8] pstore/ram: Correctly calculate usable PRZ bytes

[Kees Cook]

The actual number of bytes stored in a PRZ is smaller than the
bytes requested by platform data, since there is a header on each
PRZ. Additionally, if ECC is enabled, there are trailing bytes used
as well. Normally this mismatch doesn't matter since PRZs are circular
buffers and the leading "overflow" bytes are just thrown away. However, in
the case of a compressed record, this rather badly corrupts the results.

This corruption was visible with "ramoops.mem_size=204800 ramoops.ecc=1".
Any stored crashes would not be uncompressable (producing a pstorefs
"dmesg-*.enc.z" file), and triggering errors at boot:

  [2.790759] pstore: crypto_comp_decompress failed, ret = -22!

Reported-by: Joel Fernandes 
Fixes: b0aad7a99c1d ("pstore: Add compression support to pstore")
Signed-off-by: Kees Cook 
---
 fs/pstore/ram.c| 15 ++-
 include/linux/pstore.h |  5 -
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 25bede911809..10ac4d23c423 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -814,17 +814,14 @@ static int ramoops_probe(struct platform_device *pdev)
 
cxt->pstore.data = cxt;
/*
-* Console can handle any buffer size, so prefer LOG_LINE_MAX. If we
-* have to handle dumps, we must have at least record_size buffer. And
-* for ftrace, bufsize is irrelevant (if bufsize is 0, buf will be
-* ZERO_SIZE_PTR).
+* Since bufsize is only used for dmesg crash dumps, it
+* must match the size of the dprz record (after PRZ header
+* and ECC bytes have been accounted for).
 */
-   if (cxt->console_size)
-   cxt->pstore.bufsize = 1024; /* LOG_LINE_MAX */
-   cxt->pstore.bufsize = max(cxt->record_size, cxt->pstore.bufsize);
-   cxt->pstore.buf = kmalloc(cxt->pstore.bufsize, GFP_KERNEL);
+   cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size;
+   cxt->pstore.buf = kzalloc(cxt->pstore.bufsize, GFP_KERNEL);
if (!cxt->pstore.buf) {
-   pr_err("cannot allocate pstore buffer\n");
+   pr_err("cannot allocate pstore crash dump buffer\n");
err = -ENOMEM;
goto fail_clear;
}
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 3549f2ba865c..f46e5df76b58 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -90,7 +90,10 @@ struct pstore_record {
  *
  * @buf_lock:  spinlock to serialize access to @buf
  * @buf:   preallocated crash dump buffer
- * @bufsize:   size of @buf available for crash dump writes
+ * @bufsize:   size of @buf available for crash dump bytes (must match
+ * smallest number of bytes available for writing to a
+ * backend entry, since compressed bytes don't take kindly
+ * to being truncated)
  *
  * @read_mutex:serializes @open, @read, @close, and @erase callbacks
  * @flags: bitfield of frontends the backend can accept writes for
-- 
2.17.1

[PATCH 5/8] pstore: Improve and update some comments and status output

[Kees Cook]

This improves and updates some comments:
 - dump handler comment out of sync from calling convention
 - fix kern-doc typo

and improves status output:
 - reminder that only kernel crash dumps are compressed
 - do not be silent about ECC infrastructure failures

Signed-off-by: Kees Cook 
---
 fs/pstore/platform.c   | 7 +++
 fs/pstore/ram_core.c   | 4 +++-
 include/linux/pstore.h | 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 8b6028948cf3..a956c7bc3f67 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -304,7 +304,7 @@ static void allocate_buf_for_compression(void)
big_oops_buf_sz = size;
big_oops_buf = buf;
 
-   pr_info("Using compression: %s\n", zbackend->name);
+   pr_info("Using crash dump compression: %s\n", zbackend->name);
 }
 
 static void free_buf_for_compression(void)
@@ -354,9 +354,8 @@ void pstore_record_init(struct pstore_record *record,
 }
 
 /*
- * callback from kmsg_dump. (s2,l2) has the most recently
- * written bytes, older bytes are in (s1,l1). Save as much
- * as we can from the end of the buffer.
+ * callback from kmsg_dump. Save as much as we can (up to kmsg_bytes) from the
+ * end of the buffer.
  */
 static void pstore_dump(struct kmsg_dumper *dumper,
enum kmsg_dump_reason reason)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 1cda5922b4b4..e859e02f67a8 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -503,8 +503,10 @@ static int persistent_ram_post_init(struct 
persistent_ram_zone *prz, u32 sig,
bool zap = !!(prz->flags & PRZ_FLAG_ZAP_OLD);
 
ret = persistent_ram_init_ecc(prz, ecc_info);
-   if (ret)
+   if (ret) {
+   pr_warn("ECC failed %s\n", prz->label);
return ret;
+   }
 
sig ^= PERSISTENT_RAM_SIG;
 
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index a15bc4d48752..877ed81de346 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -85,7 +85,7 @@ struct pstore_record {
 /**
  * struct pstore_info - backend pstore driver structure
  *
- * @owner: module which is repsonsible for this backend driver
+ * @owner: module which is responsible for this backend driver
  * @name:  name of the backend driver
  *
  * @buf_lock:  spinlock to serialize access to @buf
-- 
2.17.1

[PATCH 5/8] pstore: Improve and update some comments and status output

[Kees Cook]

This improves and updates some comments:
 - dump handler comment out of sync from calling convention
 - fix kern-doc typo

and improves status output:
 - reminder that only kernel crash dumps are compressed
 - do not be silent about ECC infrastructure failures

Signed-off-by: Kees Cook 
---
 fs/pstore/platform.c   | 7 +++
 fs/pstore/ram_core.c   | 4 +++-
 include/linux/pstore.h | 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 8b6028948cf3..a956c7bc3f67 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -304,7 +304,7 @@ static void allocate_buf_for_compression(void)
big_oops_buf_sz = size;
big_oops_buf = buf;
 
-   pr_info("Using compression: %s\n", zbackend->name);
+   pr_info("Using crash dump compression: %s\n", zbackend->name);
 }
 
 static void free_buf_for_compression(void)
@@ -354,9 +354,8 @@ void pstore_record_init(struct pstore_record *record,
 }
 
 /*
- * callback from kmsg_dump. (s2,l2) has the most recently
- * written bytes, older bytes are in (s1,l1). Save as much
- * as we can from the end of the buffer.
+ * callback from kmsg_dump. Save as much as we can (up to kmsg_bytes) from the
+ * end of the buffer.
  */
 static void pstore_dump(struct kmsg_dumper *dumper,
enum kmsg_dump_reason reason)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 1cda5922b4b4..e859e02f67a8 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -503,8 +503,10 @@ static int persistent_ram_post_init(struct 
persistent_ram_zone *prz, u32 sig,
bool zap = !!(prz->flags & PRZ_FLAG_ZAP_OLD);
 
ret = persistent_ram_init_ecc(prz, ecc_info);
-   if (ret)
+   if (ret) {
+   pr_warn("ECC failed %s\n", prz->label);
return ret;
+   }
 
sig ^= PERSISTENT_RAM_SIG;
 
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index a15bc4d48752..877ed81de346 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -85,7 +85,7 @@ struct pstore_record {
 /**
  * struct pstore_info - backend pstore driver structure
  *
- * @owner: module which is repsonsible for this backend driver
+ * @owner: module which is responsible for this backend driver
  * @name:  name of the backend driver
  *
  * @buf_lock:  spinlock to serialize access to @buf
-- 
2.17.1