Re: [PATCH v3] KVM: X86: Allow userspace to define the microcode version

[Wanpeng Li]

2018-02-27 9:30 GMT+08:00 Nadav Amit :
> Wanpeng Li  wrote:
>
>> From: Wanpeng Li 
>>
>> Linux (among the others) has checks to make sure that certain features
>> aren't enabled on a certain family/model/stepping if the microcode version
>> isn't greater than or equal to a known good version.
>>
>> By exposing the real microcode version, we're preventing buggy guests that
>> don't check that they are running virtualized (i.e., they should trust the
>> hypervisor) from disabling features that are effectively not buggy.
>>
>> Suggested-by: Filippo Sironi 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Liran Alon 
>> Signed-off-by: Wanpeng Li 
>> ---
>> v2 -> v3:
>> * remove the shifts
>> * add the MSR_IA32_UCODE_REV version to the "feature MSRs"
>> v1 -> v2:
>> * add MSR_IA32_UCODE_REV to emulated_msrs
>>
>> arch/x86/include/asm/kvm_host.h |  1 +
>> arch/x86/kvm/x86.c  | 19 +++
>> 2 files changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h 
>> b/arch/x86/include/asm/kvm_host.h
>> index 938d453..6e13f2f 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
>>   u64 smi_count;
>>   bool tpr_access_reporting;
>>   u64 ia32_xss;
>> + u32 microcode_version;
>>
>>   /*
>>* Paging state of the vcpu
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index d4985a9..00af28e 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1058,6 +1058,7 @@ static unsigned num_emulated_msrs;
>> static u32 msr_based_features[] = {
>>   MSR_IA32_ARCH_CAPABILITIES,
>>   MSR_F10H_DECFG,
>> + MSR_IA32_UCODE_REV,
>> };
>>
>> static unsigned int num_msr_based_features;
>> @@ -1067,8 +1068,14 @@ static int do_get_msr_feature(struct kvm_vcpu *vcpu, 
>> unsigned index, u64 *data)
>>   struct kvm_msr_entry msr;
>>
>>   msr.index = index;
>> - if (kvm_x86_ops->get_msr_feature())
>> - return 1;
>> + switch (msr.index) {
>> + case MSR_IA32_UCODE_REV:
>> + rdmsrl(msr.index, msr.data);
>> + break;
>> + default:
>> + if (kvm_x86_ops->get_msr_feature())
>> + return 1;
>> + }
>>
>>   *data = msr.data;
>>
>> @@ -2248,7 +2255,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>
>>   switch (msr) {
>>   case MSR_AMD64_NB_CFG:
>> - case MSR_IA32_UCODE_REV:
>>   case MSR_IA32_UCODE_WRITE:
>>   case MSR_VM_HSAVE_PA:
>>   case MSR_AMD64_PATCH_LOADER:
>> @@ -2256,6 +2262,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>   case MSR_AMD64_DC_CFG:
>>   break;
>>
>> + case MSR_IA32_UCODE_REV:
>> + if (msr_info->host_initiated)
>> + vcpu->arch.microcode_version = data;
>> + break;
>>   case MSR_EFER:
>>   return set_efer(vcpu, data);
>>   case MSR_K7_HWCR:
>> @@ -2551,7 +2561,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>   msr_info->data = 0;
>>   break;
>>   case MSR_IA32_UCODE_REV:
>> - msr_info->data = 0x1ULL;
>> + msr_info->data = (u64)vcpu->arch.microcode_version;
>
> I think that the shifts are missing here (the version should be on the high
> bits according to intel_get_microcode_revision() ).

You are right, it seems that we all miss it before.

Regards,
Wanpeng Li

Re: [PATCH v3] KVM: X86: Allow userspace to define the microcode version

[Wanpeng Li]

2018-02-27 9:30 GMT+08:00 Nadav Amit :
> Wanpeng Li  wrote:
>
>> From: Wanpeng Li 
>>
>> Linux (among the others) has checks to make sure that certain features
>> aren't enabled on a certain family/model/stepping if the microcode version
>> isn't greater than or equal to a known good version.
>>
>> By exposing the real microcode version, we're preventing buggy guests that
>> don't check that they are running virtualized (i.e., they should trust the
>> hypervisor) from disabling features that are effectively not buggy.
>>
>> Suggested-by: Filippo Sironi 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Liran Alon 
>> Signed-off-by: Wanpeng Li 
>> ---
>> v2 -> v3:
>> * remove the shifts
>> * add the MSR_IA32_UCODE_REV version to the "feature MSRs"
>> v1 -> v2:
>> * add MSR_IA32_UCODE_REV to emulated_msrs
>>
>> arch/x86/include/asm/kvm_host.h |  1 +
>> arch/x86/kvm/x86.c  | 19 +++
>> 2 files changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h 
>> b/arch/x86/include/asm/kvm_host.h
>> index 938d453..6e13f2f 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
>>   u64 smi_count;
>>   bool tpr_access_reporting;
>>   u64 ia32_xss;
>> + u32 microcode_version;
>>
>>   /*
>>* Paging state of the vcpu
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index d4985a9..00af28e 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1058,6 +1058,7 @@ static unsigned num_emulated_msrs;
>> static u32 msr_based_features[] = {
>>   MSR_IA32_ARCH_CAPABILITIES,
>>   MSR_F10H_DECFG,
>> + MSR_IA32_UCODE_REV,
>> };
>>
>> static unsigned int num_msr_based_features;
>> @@ -1067,8 +1068,14 @@ static int do_get_msr_feature(struct kvm_vcpu *vcpu, 
>> unsigned index, u64 *data)
>>   struct kvm_msr_entry msr;
>>
>>   msr.index = index;
>> - if (kvm_x86_ops->get_msr_feature())
>> - return 1;
>> + switch (msr.index) {
>> + case MSR_IA32_UCODE_REV:
>> + rdmsrl(msr.index, msr.data);
>> + break;
>> + default:
>> + if (kvm_x86_ops->get_msr_feature())
>> + return 1;
>> + }
>>
>>   *data = msr.data;
>>
>> @@ -2248,7 +2255,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>
>>   switch (msr) {
>>   case MSR_AMD64_NB_CFG:
>> - case MSR_IA32_UCODE_REV:
>>   case MSR_IA32_UCODE_WRITE:
>>   case MSR_VM_HSAVE_PA:
>>   case MSR_AMD64_PATCH_LOADER:
>> @@ -2256,6 +2262,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>   case MSR_AMD64_DC_CFG:
>>   break;
>>
>> + case MSR_IA32_UCODE_REV:
>> + if (msr_info->host_initiated)
>> + vcpu->arch.microcode_version = data;
>> + break;
>>   case MSR_EFER:
>>   return set_efer(vcpu, data);
>>   case MSR_K7_HWCR:
>> @@ -2551,7 +2561,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>   msr_info->data = 0;
>>   break;
>>   case MSR_IA32_UCODE_REV:
>> - msr_info->data = 0x1ULL;
>> + msr_info->data = (u64)vcpu->arch.microcode_version;
>
> I think that the shifts are missing here (the version should be on the high
> bits according to intel_get_microcode_revision() ).

You are right, it seems that we all miss it before.

Regards,
Wanpeng Li

Re: [PATCH v4 01/24] docs: fpga: add a document for FPGA Device Feature List (DFL) Framework Overview

[Wu Hao]

On Mon, Feb 26, 2018 at 04:48:55PM -0600, Alan Tull wrote:
> On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao  wrote:
> 
> Hi Hao,
> 
> The new overview and diagrams are a great improvement, thanks!
> 
> Some comments below.

Hi Alan

Thanks a lot for the comments.

> 
> > Add a document for FPGA Device Feature List (DFL) Framework Overview.
> >
> > Signed-off-by: Enno Luebbers 
> > Signed-off-by: Xiao Guangrong 
> > Signed-off-by: Wu Hao 
> > ---
> > v2: added FME fpga-mgr/bridge/region platform driver to driver organization.
> > updated open discussion per current implementation.
> > fixed some typos.
> > v3: use FPGA base region as container device instead of fpga-dev class.
> > split common enumeration code from pcie driver to functions exposed by
> > device feature list framework.
> > update FME performance reporting which supports both integrated (iperf/)
> > and discrete (dperf/) FPGA solutions.
> > v4: rename this doc to Device Feature List (DFL) Framework Overview 
> > (dfl.txt)
> > add Device Feature List introduction and re-organize the content.
> > add description for port reset, bitstream_id/metadata and etc.
> > ---
> >  Documentation/fpga/dfl.txt | 382 
> > +
> >  1 file changed, 382 insertions(+)
> >  create mode 100644 Documentation/fpga/dfl.txt
> >
> > diff --git a/Documentation/fpga/dfl.txt b/Documentation/fpga/dfl.txt
> > new file mode 100644
> > index 000..28e4e22
> > --- /dev/null
> > +++ b/Documentation/fpga/dfl.txt
> > @@ -0,0 +1,382 @@
> > +===
> > +  FPGA Device Feature List (DFL) Framework Overview
> > +---
> > +Enno Luebbers 
> > +Xiao Guangrong 
> > +Wu Hao 
> > +
> > +The Device Feature List (DFL) FPGA framework (and drivers according to this
> > +this framework) hides the very details of low layer hardwares and provides
> > +unified interfaces for userspace applications to configure, enumerate, open
> > +and access FPGA accelerators on platforms implemented the DFL in the device
> > +memory, and enables system level management functions such as FPGA
> > +reconfiguration, power management and virtualization.
> 
> This is good, but could be clearer if you break this up into > 1 sentence.

Sure.

> 
> Power management and virtualization are coming in the future, aren't
> implemented here.  The upstream will push back on documentation of
> features that aren't included in a patchset, since that can all
> change.   The cover letter can mention the direction you intend to go
> in the future.  The future patchsets can document whatever
> functionality they add.  Noted below a few times also.

OK, then I will remove the features that aren't included in this patchset,
and add them later with implementation.

> 
> > +
> > +Device Feature List (DFL) Overview
> > +==
> > +Device Feature List (DFL) defines a link list of feature headers within the
> 
> *linked

will fix this.

> 
> > +device MMIO space to provide an extensible way of adding features. 
> > Software can
> > +walk through these predefined data structures to enumerate FPGA features:
> > +FPGA Interface Unit (FIU), Accelerated Function Unit (AFU) and Private 
> > Features,
> > +as illustrated below:
> > +
> > +HeaderHeaderHeaderHeader
> > + +--+  +-->+--+  +-->+--+  +-->+--+
> > + |   Type   |  |   |  Type|  |   |  Type|  |   |  Type|
> > + |   FIU|  |   | Private  |  |   | Private  |  |   | Private  |
> > + +--+  |   | Feature  |  |   | Feature  |  |   | Feature  |
> > + | Next_DFH |--+   +--+  |   +--+  |   +--+
> > + +--+  | Next_DFH |--+   | Next_DFH |--+   | Next_DFH |--> NULL
> > + |ID|  +--+  +--+  +--+
> > + +--+  |ID|  |ID|  |ID|
> > + | Next_AFU |--+   +--+  +--+  +--+
> > + +--+  |   | Feature  |  | Feature  |  | Feature  |
> > + | Feature  |  |   | Region   |  | Region   |  | Region   |
> > + | Region   |  |   +--+  +--+  +--+
> > + +--+  |  Header
> > +   +-->+--+
> > +   |   Type   |
> > +   |   AFU|
> > +   +--+
> > +   |   GUID   |
> > +   +--+
> > +   |  Feature |
> > +   |  Region  |
> > +   +--+
> > +
> 
> OK, yes, this is much more clear.
> 
> > 

Re: [PATCH v4 01/24] docs: fpga: add a document for FPGA Device Feature List (DFL) Framework Overview

[Wu Hao]

On Mon, Feb 26, 2018 at 04:48:55PM -0600, Alan Tull wrote:
> On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao  wrote:
> 
> Hi Hao,
> 
> The new overview and diagrams are a great improvement, thanks!
> 
> Some comments below.

Hi Alan

Thanks a lot for the comments.

> 
> > Add a document for FPGA Device Feature List (DFL) Framework Overview.
> >
> > Signed-off-by: Enno Luebbers 
> > Signed-off-by: Xiao Guangrong 
> > Signed-off-by: Wu Hao 
> > ---
> > v2: added FME fpga-mgr/bridge/region platform driver to driver organization.
> > updated open discussion per current implementation.
> > fixed some typos.
> > v3: use FPGA base region as container device instead of fpga-dev class.
> > split common enumeration code from pcie driver to functions exposed by
> > device feature list framework.
> > update FME performance reporting which supports both integrated (iperf/)
> > and discrete (dperf/) FPGA solutions.
> > v4: rename this doc to Device Feature List (DFL) Framework Overview 
> > (dfl.txt)
> > add Device Feature List introduction and re-organize the content.
> > add description for port reset, bitstream_id/metadata and etc.
> > ---
> >  Documentation/fpga/dfl.txt | 382 
> > +
> >  1 file changed, 382 insertions(+)
> >  create mode 100644 Documentation/fpga/dfl.txt
> >
> > diff --git a/Documentation/fpga/dfl.txt b/Documentation/fpga/dfl.txt
> > new file mode 100644
> > index 000..28e4e22
> > --- /dev/null
> > +++ b/Documentation/fpga/dfl.txt
> > @@ -0,0 +1,382 @@
> > +===
> > +  FPGA Device Feature List (DFL) Framework Overview
> > +---
> > +Enno Luebbers 
> > +Xiao Guangrong 
> > +Wu Hao 
> > +
> > +The Device Feature List (DFL) FPGA framework (and drivers according to this
> > +this framework) hides the very details of low layer hardwares and provides
> > +unified interfaces for userspace applications to configure, enumerate, open
> > +and access FPGA accelerators on platforms implemented the DFL in the device
> > +memory, and enables system level management functions such as FPGA
> > +reconfiguration, power management and virtualization.
> 
> This is good, but could be clearer if you break this up into > 1 sentence.

Sure.

> 
> Power management and virtualization are coming in the future, aren't
> implemented here.  The upstream will push back on documentation of
> features that aren't included in a patchset, since that can all
> change.   The cover letter can mention the direction you intend to go
> in the future.  The future patchsets can document whatever
> functionality they add.  Noted below a few times also.

OK, then I will remove the features that aren't included in this patchset,
and add them later with implementation.

> 
> > +
> > +Device Feature List (DFL) Overview
> > +==
> > +Device Feature List (DFL) defines a link list of feature headers within the
> 
> *linked

will fix this.

> 
> > +device MMIO space to provide an extensible way of adding features. 
> > Software can
> > +walk through these predefined data structures to enumerate FPGA features:
> > +FPGA Interface Unit (FIU), Accelerated Function Unit (AFU) and Private 
> > Features,
> > +as illustrated below:
> > +
> > +HeaderHeaderHeaderHeader
> > + +--+  +-->+--+  +-->+--+  +-->+--+
> > + |   Type   |  |   |  Type|  |   |  Type|  |   |  Type|
> > + |   FIU|  |   | Private  |  |   | Private  |  |   | Private  |
> > + +--+  |   | Feature  |  |   | Feature  |  |   | Feature  |
> > + | Next_DFH |--+   +--+  |   +--+  |   +--+
> > + +--+  | Next_DFH |--+   | Next_DFH |--+   | Next_DFH |--> NULL
> > + |ID|  +--+  +--+  +--+
> > + +--+  |ID|  |ID|  |ID|
> > + | Next_AFU |--+   +--+  +--+  +--+
> > + +--+  |   | Feature  |  | Feature  |  | Feature  |
> > + | Feature  |  |   | Region   |  | Region   |  | Region   |
> > + | Region   |  |   +--+  +--+  +--+
> > + +--+  |  Header
> > +   +-->+--+
> > +   |   Type   |
> > +   |   AFU|
> > +   +--+
> > +   |   GUID   |
> > +   +--+
> > +   |  Feature |
> > +   |  Region  |
> > +   +--+
> > +
> 
> OK, yes, this is much more clear.
> 
> > +FPGA Interface Unit (FIU) represents a standalone functional unit for the
> > +interface to FPGA, e.g the FPGA Management Engine (FME) and Port. (more
> 
> Nit, don't 

Re: [PATCH 04/11] signal/parisc: Document a conflict with SI_USER with SIGFPE

[Eric W. Biederman]

Helge Deller  writes:

> On 23.02.2018 01:15, Eric W. Biederman wrote:
>> Helge Deller  writes:
>> 
>>> * Eric W. Biederman :
 Setting si_code to 0 results in a userspace seeing an si_code of 0.
 This is the same si_code as SI_USER.  Posix and common sense requires
 that SI_USER not be a signal specific si_code.  As such this use of 0
 for the si_code is a pretty horribly broken ABI.

 Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
 value of __SI_KILL and now sees a value of SIL_KILL with the result
 that uid and pid fields are copied and which might copying the si_addr
 field by accident but certainly not by design.  Making this a very
 flakey implementation.

 Utilizing FPE_FIXME siginfo_layout will now return SIL_FAULT and the
 appropriate fields will reliably be copied.

 This bug is 13 years old and parsic machines are no longer being built
 so I don't know if it possible or worth fixing it.  But it is at least
 worth documenting this so other architectures don't make the same
 mistake.
>>>
>>>
>>> I think we should fix it, even if we now break the ABI.
>>>
>>> It's about a "conditional trap" which needs to be handled by userspace.
>>> I doubt there is any Linux code out which is utilizing this
>>> parisc-specific trap.
>>>
>>> I'd suggest to add a new FPE trap si_code (e.g. FPE_CONDTRAP).
>>> While at it, maybe we should include the already existing FPE_MDAOVF
>>> from the frv architecture, so that arch/frv/include/uapi/asm/siginfo.h
>>> can go completely.
>>>
>>> Suggested patch is below.
>>>
>>> I'm willing to test the patch below on the parisc architecture for a few
>>> weeks. And it will break arch/x86/kernel/signal_compat.c which needs
>>> looking at then too.
>> 
>> Have you managed to test this change?
>
> Sadly I haven't done any further testing yet.

So at this point for purposed of testing I don't think it matters which
number FPE_CONDTRAP gets as long as it is non-zero.
>  
>> I am sitting looking at another new FPE si_code and if this has been tested
>> I figure FPE_CONDTRAP should get the next available FPE si_code and the
>> other change should get the one that follows.
>
> I'm fine either way. Do you have a git tree I can pull which includes
> all your patches? I can then start testing.

Everything finalized is in Linus's tree.  There is a patch pending
review on linux-arch that defines FPE_FLTUNK that looks to be useful
on several architectures.

I had probably misread our earlier exchange.  I had hoped you had tested
that FPE_CONDTRAP did not cause problems.

If that level of testing was complete I would have given FPE_CONDTRAP
the next FPE number and FPE_FLTUNK the one after.

As it sounds like FPE_CONDTRAP hasn't been tested enough to know if it
causes problems I will encourage the patches to be merged in the other
order.

Eric

Re: [PATCH 04/11] signal/parisc: Document a conflict with SI_USER with SIGFPE

[Eric W. Biederman]

Helge Deller  writes:

> On 23.02.2018 01:15, Eric W. Biederman wrote:
>> Helge Deller  writes:
>> 
>>> * Eric W. Biederman :
 Setting si_code to 0 results in a userspace seeing an si_code of 0.
 This is the same si_code as SI_USER.  Posix and common sense requires
 that SI_USER not be a signal specific si_code.  As such this use of 0
 for the si_code is a pretty horribly broken ABI.

 Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
 value of __SI_KILL and now sees a value of SIL_KILL with the result
 that uid and pid fields are copied and which might copying the si_addr
 field by accident but certainly not by design.  Making this a very
 flakey implementation.

 Utilizing FPE_FIXME siginfo_layout will now return SIL_FAULT and the
 appropriate fields will reliably be copied.

 This bug is 13 years old and parsic machines are no longer being built
 so I don't know if it possible or worth fixing it.  But it is at least
 worth documenting this so other architectures don't make the same
 mistake.
>>>
>>>
>>> I think we should fix it, even if we now break the ABI.
>>>
>>> It's about a "conditional trap" which needs to be handled by userspace.
>>> I doubt there is any Linux code out which is utilizing this
>>> parisc-specific trap.
>>>
>>> I'd suggest to add a new FPE trap si_code (e.g. FPE_CONDTRAP).
>>> While at it, maybe we should include the already existing FPE_MDAOVF
>>> from the frv architecture, so that arch/frv/include/uapi/asm/siginfo.h
>>> can go completely.
>>>
>>> Suggested patch is below.
>>>
>>> I'm willing to test the patch below on the parisc architecture for a few
>>> weeks. And it will break arch/x86/kernel/signal_compat.c which needs
>>> looking at then too.
>> 
>> Have you managed to test this change?
>
> Sadly I haven't done any further testing yet.

So at this point for purposed of testing I don't think it matters which
number FPE_CONDTRAP gets as long as it is non-zero.
>  
>> I am sitting looking at another new FPE si_code and if this has been tested
>> I figure FPE_CONDTRAP should get the next available FPE si_code and the
>> other change should get the one that follows.
>
> I'm fine either way. Do you have a git tree I can pull which includes
> all your patches? I can then start testing.

Everything finalized is in Linus's tree.  There is a patch pending
review on linux-arch that defines FPE_FLTUNK that looks to be useful
on several architectures.

I had probably misread our earlier exchange.  I had hoped you had tested
that FPE_CONDTRAP did not cause problems.

If that level of testing was complete I would have given FPE_CONDTRAP
the next FPE number and FPE_FLTUNK the one after.

As it sounds like FPE_CONDTRAP hasn't been tested enough to know if it
causes problems I will encourage the patches to be merged in the other
order.

Eric

Re: [PATCH 12/15] drm/sun4i: Allow building on arm64

[kbuild test robot]

Hi Jernej,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20180226]
[cannot apply to robh/for-next v4.16-rc3]
[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/Jernej-Skrabec/Implement-H3-H5-HDMI-driver/20180227-054135
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-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
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu//drm/sun4i/sun8i_dw_hdmi.h:12:0,
from drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c:9:
   drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c: In function 
'sun8i_hdmi_phy_config_h3':
>> drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c:188:7: warning: large integer 
>> implicitly truncated to unsigned type [-Woverflow]
  ~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK, pll_cfg2_init);
  ^
   include/linux/regmap.h:75:36: note: in definition of macro 
'regmap_update_bits'
 regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
   ^~~~

vim +188 drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c

b7c7436a Jernej Skrabec 2018-02-148  
b7c7436a Jernej Skrabec 2018-02-14   @9  #include "sun8i_dw_hdmi.h"
b7c7436a Jernej Skrabec 2018-02-14   10  
b7c7436a Jernej Skrabec 2018-02-14   11  /*
b7c7436a Jernej Skrabec 2018-02-14   12   * Address can be actually any value. 
Here is set to same value as
b7c7436a Jernej Skrabec 2018-02-14   13   * it is set in BSP driver.
b7c7436a Jernej Skrabec 2018-02-14   14   */
b7c7436a Jernej Skrabec 2018-02-14   15  #define I2C_ADDR   0x69
b7c7436a Jernej Skrabec 2018-02-14   16  
322900e8 Jernej Skrabec 2018-02-24   17  static int 
sun8i_hdmi_phy_config_a83t(struct dw_hdmi *hdmi,
322900e8 Jernej Skrabec 2018-02-24   18   
struct sun8i_hdmi_phy *phy,
322900e8 Jernej Skrabec 2018-02-24   19   
unsigned int clk_rate)
b7c7436a Jernej Skrabec 2018-02-14   20  {
b7c7436a Jernej Skrabec 2018-02-14   21 regmap_update_bits(phy->regs, 
SUN8I_HDMI_PHY_REXT_CTRL_REG,
b7c7436a Jernej Skrabec 2018-02-14   22
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
b7c7436a Jernej Skrabec 2018-02-14   23
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN);
b7c7436a Jernej Skrabec 2018-02-14   24  
b7c7436a Jernej Skrabec 2018-02-14   25 /* power down */
b7c7436a Jernej Skrabec 2018-02-14   26 dw_hdmi_phy_gen2_txpwron(hdmi, 
0);
b7c7436a Jernej Skrabec 2018-02-14   27 dw_hdmi_phy_gen2_pddq(hdmi, 1);
b7c7436a Jernej Skrabec 2018-02-14   28  
b7c7436a Jernej Skrabec 2018-02-14   29 dw_hdmi_phy_reset(hdmi);
b7c7436a Jernej Skrabec 2018-02-14   30  
b7c7436a Jernej Skrabec 2018-02-14   31 dw_hdmi_phy_gen2_pddq(hdmi, 0);
b7c7436a Jernej Skrabec 2018-02-14   32  
b7c7436a Jernej Skrabec 2018-02-14   33 dw_hdmi_phy_i2c_set_addr(hdmi, 
I2C_ADDR);
b7c7436a Jernej Skrabec 2018-02-14   34  
b7c7436a Jernej Skrabec 2018-02-14   35 /*
b7c7436a Jernej Skrabec 2018-02-14   36  * Values are taken from BSP 
HDMI driver. Although AW didn't
b7c7436a Jernej Skrabec 2018-02-14   37  * release any documentation, 
explanation of this values can
b7c7436a Jernej Skrabec 2018-02-14   38  * be found in i.MX 6Dual/6Quad 
Reference Manual.
b7c7436a Jernej Skrabec 2018-02-14   39  */
322900e8 Jernej Skrabec 2018-02-24   40 if (clk_rate <= 2700) {
b7c7436a Jernej Skrabec 2018-02-14   41 
dw_hdmi_phy_i2c_write(hdmi, 0x01e0, 0x06);
b7c7436a Jernej Skrabec 2018-02-14   42 
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x15);
b7c7436a Jernej Skrabec 2018-02-14   43 
dw_hdmi_phy_i2c_write(hdmi, 0x08da, 0x10);
b7c7436a Jernej Skrabec 2018-02-14   44 
dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
b7c7436a Jernej Skrabec 2018-02-14   45 
dw_hdmi_phy_i2c_write(hdmi, 0x0318, 0x0e);
b7c7436a Jernej Skrabec 2018-02-14   46 
dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
322900e8 Jernej Skrabec 2018-02-24   47 } else if (clk_rate <= 
7425) {
b7c7436a Jernej Skrabec 2018-02-14   48 
dw_hdmi_phy_i2c_write(hdmi, 0x0540, 0x06);
b7c7436a Jernej Skrabec 2018-02-14   49 
dw_hdmi_phy_i2c_write(hdmi, 0x0005, 0x15);
b7c7436a Jernej Skrabec 2018-02-14   50 
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x10);
b7c7436a Jernej Skrabec 2018-02-14   51 
dw_

Re: [PATCH 12/15] drm/sun4i: Allow building on arm64

[kbuild test robot]

Hi Jernej,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20180226]
[cannot apply to robh/for-next v4.16-rc3]
[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/Jernej-Skrabec/Implement-H3-H5-HDMI-driver/20180227-054135
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-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
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu//drm/sun4i/sun8i_dw_hdmi.h:12:0,
from drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c:9:
   drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c: In function 
'sun8i_hdmi_phy_config_h3':
>> drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c:188:7: warning: large integer 
>> implicitly truncated to unsigned type [-Woverflow]
  ~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK, pll_cfg2_init);
  ^
   include/linux/regmap.h:75:36: note: in definition of macro 
'regmap_update_bits'
 regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
   ^~~~

vim +188 drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c

b7c7436a Jernej Skrabec 2018-02-148  
b7c7436a Jernej Skrabec 2018-02-14   @9  #include "sun8i_dw_hdmi.h"
b7c7436a Jernej Skrabec 2018-02-14   10  
b7c7436a Jernej Skrabec 2018-02-14   11  /*
b7c7436a Jernej Skrabec 2018-02-14   12   * Address can be actually any value. 
Here is set to same value as
b7c7436a Jernej Skrabec 2018-02-14   13   * it is set in BSP driver.
b7c7436a Jernej Skrabec 2018-02-14   14   */
b7c7436a Jernej Skrabec 2018-02-14   15  #define I2C_ADDR   0x69
b7c7436a Jernej Skrabec 2018-02-14   16  
322900e8 Jernej Skrabec 2018-02-24   17  static int 
sun8i_hdmi_phy_config_a83t(struct dw_hdmi *hdmi,
322900e8 Jernej Skrabec 2018-02-24   18   
struct sun8i_hdmi_phy *phy,
322900e8 Jernej Skrabec 2018-02-24   19   
unsigned int clk_rate)
b7c7436a Jernej Skrabec 2018-02-14   20  {
b7c7436a Jernej Skrabec 2018-02-14   21 regmap_update_bits(phy->regs, 
SUN8I_HDMI_PHY_REXT_CTRL_REG,
b7c7436a Jernej Skrabec 2018-02-14   22
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
b7c7436a Jernej Skrabec 2018-02-14   23
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN);
b7c7436a Jernej Skrabec 2018-02-14   24  
b7c7436a Jernej Skrabec 2018-02-14   25 /* power down */
b7c7436a Jernej Skrabec 2018-02-14   26 dw_hdmi_phy_gen2_txpwron(hdmi, 
0);
b7c7436a Jernej Skrabec 2018-02-14   27 dw_hdmi_phy_gen2_pddq(hdmi, 1);
b7c7436a Jernej Skrabec 2018-02-14   28  
b7c7436a Jernej Skrabec 2018-02-14   29 dw_hdmi_phy_reset(hdmi);
b7c7436a Jernej Skrabec 2018-02-14   30  
b7c7436a Jernej Skrabec 2018-02-14   31 dw_hdmi_phy_gen2_pddq(hdmi, 0);
b7c7436a Jernej Skrabec 2018-02-14   32  
b7c7436a Jernej Skrabec 2018-02-14   33 dw_hdmi_phy_i2c_set_addr(hdmi, 
I2C_ADDR);
b7c7436a Jernej Skrabec 2018-02-14   34  
b7c7436a Jernej Skrabec 2018-02-14   35 /*
b7c7436a Jernej Skrabec 2018-02-14   36  * Values are taken from BSP 
HDMI driver. Although AW didn't
b7c7436a Jernej Skrabec 2018-02-14   37  * release any documentation, 
explanation of this values can
b7c7436a Jernej Skrabec 2018-02-14   38  * be found in i.MX 6Dual/6Quad 
Reference Manual.
b7c7436a Jernej Skrabec 2018-02-14   39  */
322900e8 Jernej Skrabec 2018-02-24   40 if (clk_rate <= 2700) {
b7c7436a Jernej Skrabec 2018-02-14   41 
dw_hdmi_phy_i2c_write(hdmi, 0x01e0, 0x06);
b7c7436a Jernej Skrabec 2018-02-14   42 
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x15);
b7c7436a Jernej Skrabec 2018-02-14   43 
dw_hdmi_phy_i2c_write(hdmi, 0x08da, 0x10);
b7c7436a Jernej Skrabec 2018-02-14   44 
dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
b7c7436a Jernej Skrabec 2018-02-14   45 
dw_hdmi_phy_i2c_write(hdmi, 0x0318, 0x0e);
b7c7436a Jernej Skrabec 2018-02-14   46 
dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
322900e8 Jernej Skrabec 2018-02-24   47 } else if (clk_rate <= 
7425) {
b7c7436a Jernej Skrabec 2018-02-14   48 
dw_hdmi_phy_i2c_write(hdmi, 0x0540, 0x06);
b7c7436a Jernej Skrabec 2018-02-14   49 
dw_hdmi_phy_i2c_write(hdmi, 0x0005, 0x15);
b7c7436a Jernej Skrabec 2018-02-14   50 
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x10);
b7c7436a Jernej Skrabec 2018-02-14   51 
dw_

Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

[Dmitry V. Levin]

On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
> On 02/21/2018 03:44 AM, Andrew Morton wrote:
> > On Tue,  9 Jan 2018 08:30:49 +0200 Mike Rapoport  
> > wrote:
> > 
> >> This patches introduces new process_vmsplice system call that combines
> >> functionality of process_vm_read and vmsplice.
> > 
> > All seems fairly strightforward.  The big question is: do we know that
> > people will actually use this, and get sufficient value from it to
> > justify its addition?
> 
> Yes, that's what bothers us a lot too :) I've tried to start with finding out 
> if anyone 
> used the sys_read/write_process_vm() calls, but failed :( Does anybody know 
> how popular
> these syscalls are?

Well, process_vm_readv itself is quite popular, it's used by debuggers nowadays,
see e.g.
$ strace -qq -esignal=none -eprocess_vm_readv strace -qq -o/dev/null cat 
/dev/null


-- 
ldv


signature.asc
Description: PGP signature

Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

[Dmitry V. Levin]

On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
> On 02/21/2018 03:44 AM, Andrew Morton wrote:
> > On Tue,  9 Jan 2018 08:30:49 +0200 Mike Rapoport  
> > wrote:
> > 
> >> This patches introduces new process_vmsplice system call that combines
> >> functionality of process_vm_read and vmsplice.
> > 
> > All seems fairly strightforward.  The big question is: do we know that
> > people will actually use this, and get sufficient value from it to
> > justify its addition?
> 
> Yes, that's what bothers us a lot too :) I've tried to start with finding out 
> if anyone 
> used the sys_read/write_process_vm() calls, but failed :( Does anybody know 
> how popular
> these syscalls are?

Well, process_vm_readv itself is quite popular, it's used by debuggers nowadays,
see e.g.
$ strace -qq -esignal=none -eprocess_vm_readv strace -qq -o/dev/null cat 
/dev/null


-- 
ldv


signature.asc
Description: PGP signature

Re: [PATCH bpf-next v2] samples/bpf: Add program for CPU state statistics

[Leo Yan]

On Mon, Feb 26, 2018 at 11:26:52AM +0100, Daniel Borkmann wrote:
> On 02/26/2018 02:19 AM, Leo Yan wrote:

[...]

> > CPU states statistics:
> > state(ms)  cstate-0cstate-1cstate-2pstate-0pstate-1
> > pstate-2pstate-3pstate-4
> > CPU-0  767 6111111863  561 31  756  
> >853 190
> > CPU-1  241 10606   107956  484 125 646  
> >990 85
> > CPU-2  413 19721   98735   636 84  696  
> >757 89
> > CPU-3  84  11711   79989   17516   909 4811 
> >5773341
> > CPU-4  152 19610   98229   444 53  649  
> >708 1283
> > CPU-5  185 8781108697  666 91  671  
> >677 1365
> > CPU-6  157 21964   95825   581 67  566  
> >684 1284
> > CPU-7  125 15238   102704  398 20  665  
> >786 1197
> > 
> > Cc: Daniel Lezcano 
> > Cc: Vincent Guittot 
> > Signed-off-by: Leo Yan 
> 
> Applied to bpf-next, thanks Leo!

Thanks for help, Daniel.

Re: [PATCH bpf-next v2] samples/bpf: Add program for CPU state statistics

[Leo Yan]

On Mon, Feb 26, 2018 at 11:26:52AM +0100, Daniel Borkmann wrote:
> On 02/26/2018 02:19 AM, Leo Yan wrote:

[...]

> > CPU states statistics:
> > state(ms)  cstate-0cstate-1cstate-2pstate-0pstate-1
> > pstate-2pstate-3pstate-4
> > CPU-0  767 6111111863  561 31  756  
> >853 190
> > CPU-1  241 10606   107956  484 125 646  
> >990 85
> > CPU-2  413 19721   98735   636 84  696  
> >757 89
> > CPU-3  84  11711   79989   17516   909 4811 
> >5773341
> > CPU-4  152 19610   98229   444 53  649  
> >708 1283
> > CPU-5  185 8781108697  666 91  671  
> >677 1365
> > CPU-6  157 21964   95825   581 67  566  
> >684 1284
> > CPU-7  125 15238   102704  398 20  665  
> >786 1197
> > 
> > Cc: Daniel Lezcano 
> > Cc: Vincent Guittot 
> > Signed-off-by: Leo Yan 
> 
> Applied to bpf-next, thanks Leo!

Thanks for help, Daniel.

[PATCH v8 2/2] media: V3s: Add support for Allwinner CSI.

[Yong Deng]

Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
interface and CSI1 is used for parallel interface. This is not
documented in datasheet but by test and guess.

This patch implement a v4l2 framework driver for it.

Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.

Tested-by: Maxime Ripard 
Signed-off-by: Yong Deng 
---
 MAINTAINERS|   8 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/sunxi/sun6i-csi/Kconfig |   9 +
 drivers/media/platform/sunxi/sun6i-csi/Makefile|   3 +
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 911 +
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 143 
 .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 196 +
 .../media/platform/sunxi/sun6i-csi/sun6i_video.c   | 753 +
 .../media/platform/sunxi/sun6i-csi/sun6i_video.h   |  53 ++
 10 files changed, 2079 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 91ed6adfa4a6..b4a331ad35b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3793,6 +3793,14 @@ M:   Jaya Kumar 
 S: Maintained
 F: sound/pci/cs5535audio/
 
+CSI DRIVERS FOR ALLWINNER V3s
+M: Yong Deng 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/sunxi/sun6i-csi/
+F: Documentation/devicetree/bindings/media/sun6i-csi.txt
+
 CW1200 WLAN driver
 M: Solomon Peachy 
 S: Maintained
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f9cc0582c8a9..7f1ee46c3258 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -159,6 +159,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 85e112122f32..143d8a473b0a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -96,3 +96,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= 
qcom/camss-8x16/
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
 
 obj-y  += meson/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI)  += sunxi/sun6i-csi/
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
new file mode 100644
index ..314188aae2c2
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+   tristate "Allwinner V3s Camera Sensor Interface driver"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SUNXI || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   select V4L2_FWNODE
+   ---help---
+  Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Makefile 
b/drivers/media/platform/sunxi/sun6i-csi/Makefile
new file mode 100644
index ..213cb6be9e9c
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_video.o sun6i_csi.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
new file mode 100644
index ..1e238d57
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,911 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2011-2018 Magewell Electronics Co., Ltd. (Nanjing)
+ * All rights reserved.
+ * Author: Yong Deng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_csi.h"
+#include "sun6i_csi_reg.h"
+
+#define MODULE_NAME"sun6i-csi"
+
+struct sun6i_csi_dev {
+   

[PATCH v8 2/2] media: V3s: Add support for Allwinner CSI.

[Yong Deng]

Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
interface and CSI1 is used for parallel interface. This is not
documented in datasheet but by test and guess.

This patch implement a v4l2 framework driver for it.

Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.

Tested-by: Maxime Ripard 
Signed-off-by: Yong Deng 
---
 MAINTAINERS|   8 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/sunxi/sun6i-csi/Kconfig |   9 +
 drivers/media/platform/sunxi/sun6i-csi/Makefile|   3 +
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 911 +
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 143 
 .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 196 +
 .../media/platform/sunxi/sun6i-csi/sun6i_video.c   | 753 +
 .../media/platform/sunxi/sun6i-csi/sun6i_video.h   |  53 ++
 10 files changed, 2079 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 91ed6adfa4a6..b4a331ad35b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3793,6 +3793,14 @@ M:   Jaya Kumar 
 S: Maintained
 F: sound/pci/cs5535audio/
 
+CSI DRIVERS FOR ALLWINNER V3s
+M: Yong Deng 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/sunxi/sun6i-csi/
+F: Documentation/devicetree/bindings/media/sun6i-csi.txt
+
 CW1200 WLAN driver
 M: Solomon Peachy 
 S: Maintained
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f9cc0582c8a9..7f1ee46c3258 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -159,6 +159,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 85e112122f32..143d8a473b0a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -96,3 +96,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= 
qcom/camss-8x16/
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
 
 obj-y  += meson/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI)  += sunxi/sun6i-csi/
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
new file mode 100644
index ..314188aae2c2
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+   tristate "Allwinner V3s Camera Sensor Interface driver"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SUNXI || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   select V4L2_FWNODE
+   ---help---
+  Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Makefile 
b/drivers/media/platform/sunxi/sun6i-csi/Makefile
new file mode 100644
index ..213cb6be9e9c
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_video.o sun6i_csi.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
new file mode 100644
index ..1e238d57
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,911 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2011-2018 Magewell Electronics Co., Ltd. (Nanjing)
+ * All rights reserved.
+ * Author: Yong Deng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_csi.h"
+#include "sun6i_csi_reg.h"
+
+#define MODULE_NAME"sun6i-csi"
+
+struct sun6i_csi_dev {
+   struct sun6i_csicsi;
+   struct device   *dev;
+
+   struct regmap   *regmap;
+   struct clk 

Re: [PATCH] mm: Provide consistent declaration for num_poisoned_pages

[Guenter Roeck]

On 02/26/2018 03:57 PM, David Rientjes wrote:

On Mon, 26 Feb 2018, Guenter Roeck wrote:


clang reports the following compile warning.

In file included from mm/vmscan.c:56:
./include/linux/swapops.h:327:22: warning:
section attribute is specified on redeclared variable [-Wsection]
extern atomic_long_t num_poisoned_pages __read_mostly;
  ^
./include/linux/mm.h:2585:22: note: previous declaration is here
extern atomic_long_t num_poisoned_pages;
  ^

Let's use __read_mostly everywhere.

Signed-off-by: Guenter Roeck 
Cc: Matthias Kaehlcke 
---
  include/linux/mm.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42adb1a..bd4bd59f02c1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2582,7 +2582,7 @@ extern int get_hwpoison_page(struct page *page);
  extern int sysctl_memory_failure_early_kill;
  extern int sysctl_memory_failure_recovery;
  extern void shake_page(struct page *p, int access);
-extern atomic_long_t num_poisoned_pages;
+extern atomic_long_t num_poisoned_pages __read_mostly;
  extern int soft_offline_page(struct page *page, int flags);
  
  


No objection to the patch, of course, but I'm wondering if it's (1) the
only such clang compile warning for mm/, and (2) if the re-declaration in


It is the only one I recall seeing in mm/ while testing the clang/retpoline
changes with ToT clang 7.0.0, but then I didn't pay too close attention.


mm.h could be avoided by including swapops.h?



Another alternative would be to remove the extern fom swapops.h and have
swapops.h include mm.h instead. I chose the least invasive change since
I didn't want to risk breaking some other build (after all, maybe there
was a reason for declaring num_poisoned_pages in two include files).

Guenter

Re: [PATCH] mm: Provide consistent declaration for num_poisoned_pages

[Guenter Roeck]

On 02/26/2018 03:57 PM, David Rientjes wrote:

On Mon, 26 Feb 2018, Guenter Roeck wrote:


clang reports the following compile warning.

In file included from mm/vmscan.c:56:
./include/linux/swapops.h:327:22: warning:
section attribute is specified on redeclared variable [-Wsection]
extern atomic_long_t num_poisoned_pages __read_mostly;
  ^
./include/linux/mm.h:2585:22: note: previous declaration is here
extern atomic_long_t num_poisoned_pages;
  ^

Let's use __read_mostly everywhere.

Signed-off-by: Guenter Roeck 
Cc: Matthias Kaehlcke 
---
  include/linux/mm.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42adb1a..bd4bd59f02c1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2582,7 +2582,7 @@ extern int get_hwpoison_page(struct page *page);
  extern int sysctl_memory_failure_early_kill;
  extern int sysctl_memory_failure_recovery;
  extern void shake_page(struct page *p, int access);
-extern atomic_long_t num_poisoned_pages;
+extern atomic_long_t num_poisoned_pages __read_mostly;
  extern int soft_offline_page(struct page *page, int flags);
  
  


No objection to the patch, of course, but I'm wondering if it's (1) the
only such clang compile warning for mm/, and (2) if the re-declaration in


It is the only one I recall seeing in mm/ while testing the clang/retpoline
changes with ToT clang 7.0.0, but then I didn't pay too close attention.


mm.h could be avoided by including swapops.h?



Another alternative would be to remove the extern fom swapops.h and have
swapops.h include mm.h instead. I chose the least invasive change since
I didn't want to risk breaking some other build (after all, maybe there
was a reason for declaring num_poisoned_pages in two include files).

Guenter

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

[skannan]

On 2018-02-25 06:38, Mark Rutland wrote:

On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote:

Some PMUs events can be read from any CPU. So allow the PMU to mark
events as such. For these events, we don't need to reject reads or
make smp calls to the event's CPU and cause unnecessary wake ups.

Good examples of such events would be events from caches shared across
all CPUs.


I think that if we need to generalize PERF_EV_CAP_READ_ACTIVE_PKG, it 
would be
better to give events a pointer to a cpumask. That could then cover all 
cases

quite trivially:

static int __perf_event_read_cpu(struct perf_event *event, int 
event_cpu)

{
int local_cpu = smp_processor_id();

if (event->read_mask &&
cpumask_test_cpu(local_cpu, event->read_mask))
event_cpu = local_cpu;

return event_cpu;
}



This is a good improvement on my attempt. If I send a patch for this, is 
that something you'd be willing to incorporate into your patch set and 
make sure the DSU pmu driver handles it correctly?


... in the PERF_EV_CAP_READ_ACTIVE_PKG case, we can use the exiting(?) 
package
masks, and more generally we can re-use the PMU's affinit mask if it 
has one.


That said, I see that many pmu::read() implementations have 
side-effects on
hwc->prev_count, and event->count, so I worry that this won't be sfe in 
general

(e.g. if we race with the IRQ handler on another CPU).



Yeah, this doesn't have to be mandatory. It can be an optional mask the 
PMU can set up during perf event init.


Peter,

Is this something that's acceptable to you?

Thanks,
Saravana

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

[skannan]

On 2018-02-25 06:38, Mark Rutland wrote:

On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote:

Some PMUs events can be read from any CPU. So allow the PMU to mark
events as such. For these events, we don't need to reject reads or
make smp calls to the event's CPU and cause unnecessary wake ups.

Good examples of such events would be events from caches shared across
all CPUs.


I think that if we need to generalize PERF_EV_CAP_READ_ACTIVE_PKG, it 
would be
better to give events a pointer to a cpumask. That could then cover all 
cases

quite trivially:

static int __perf_event_read_cpu(struct perf_event *event, int 
event_cpu)

{
int local_cpu = smp_processor_id();

if (event->read_mask &&
cpumask_test_cpu(local_cpu, event->read_mask))
event_cpu = local_cpu;

return event_cpu;
}



This is a good improvement on my attempt. If I send a patch for this, is 
that something you'd be willing to incorporate into your patch set and 
make sure the DSU pmu driver handles it correctly?


... in the PERF_EV_CAP_READ_ACTIVE_PKG case, we can use the exiting(?) 
package
masks, and more generally we can re-use the PMU's affinit mask if it 
has one.


That said, I see that many pmu::read() implementations have 
side-effects on
hwc->prev_count, and event->count, so I worry that this won't be sfe in 
general

(e.g. if we race with the IRQ handler on another CPU).



Yeah, this doesn't have to be mandatory. It can be an optional mask the 
PMU can set up during perf event init.


Peter,

Is this something that's acceptable to you?

Thanks,
Saravana

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

[Alexei Starovoitov]

On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote:
> The seccomp(2) syscall can be used by a task to apply a Landlock program
> to itself. As a seccomp filter, a Landlock program is enforced for the
> current task and all its future children. A program is immutable and a
> task can only add new restricting programs to itself, forming a list of
> programss.
> 
> A Landlock program is tied to a Landlock hook. If the action on a kernel
> object is allowed by the other Linux security mechanisms (e.g. DAC,
> capabilities, other LSM), then a Landlock hook related to this kind of
> object is triggered. The list of programs for this hook is then
> evaluated. Each program return a 32-bit value which can deny the action
> on a kernel object with a non-zero value. If every programs of the list
> return zero, then the action on the object is allowed.
> 
> Multiple Landlock programs can be chained to share a 64-bits value for a
> call chain (e.g. evaluating multiple elements of a file path).  This
> chaining is restricted when a process construct this chain by loading a
> program, but additional checks are performed when it requests to apply
> this chain of programs to itself.  The restrictions ensure that it is
> not possible to call multiple programs in a way that would imply to
> handle multiple shared values (i.e. cookies) for one chain.  For now,
> only a fs_pick program can be chained to the same type of program,
> because it may make sense if they have different triggers (cf. next
> commits).  This restrictions still allows to reuse Landlock programs in
> a safe way (e.g. use the same loaded fs_walk program with multiple
> chains of fs_pick programs).
> 
> Signed-off-by: Mickaël Salaün 

...

> +struct landlock_prog_set *landlock_prepend_prog(
> + struct landlock_prog_set *current_prog_set,
> + struct bpf_prog *prog)
> +{
> + struct landlock_prog_set *new_prog_set = current_prog_set;
> + unsigned long pages;
> + int err;
> + size_t i;
> + struct landlock_prog_set tmp_prog_set = {};
> +
> + if (prog->type != BPF_PROG_TYPE_LANDLOCK_HOOK)
> + return ERR_PTR(-EINVAL);
> +
> + /* validate memory size allocation */
> + pages = prog->pages;
> + if (current_prog_set) {
> + size_t i;
> +
> + for (i = 0; i < ARRAY_SIZE(current_prog_set->programs); i++) {
> + struct landlock_prog_list *walker_p;
> +
> + for (walker_p = current_prog_set->programs[i];
> + walker_p; walker_p = walker_p->prev)
> + pages += walker_p->prog->pages;
> + }
> + /* count a struct landlock_prog_set if we need to allocate one 
> */
> + if (refcount_read(_prog_set->usage) != 1)
> + pages += round_up(sizeof(*current_prog_set), PAGE_SIZE)
> + / PAGE_SIZE;
> + }
> + if (pages > LANDLOCK_PROGRAMS_MAX_PAGES)
> + return ERR_PTR(-E2BIG);
> +
> + /* ensure early that we can allocate enough memory for the new
> +  * prog_lists */
> + err = store_landlock_prog(_prog_set, current_prog_set, prog);
> + if (err)
> + return ERR_PTR(err);
> +
> + /*
> +  * Each task_struct points to an array of prog list pointers.  These
> +  * tables are duplicated when additions are made (which means each
> +  * table needs to be refcounted for the processes using it). When a new
> +  * table is created, all the refcounters on the prog_list are bumped (to
> +  * track each table that references the prog). When a new prog is
> +  * added, it's just prepended to the list for the new table to point
> +  * at.
> +  *
> +  * Manage all the possible errors before this step to not uselessly
> +  * duplicate current_prog_set and avoid a rollback.
> +  */
> + if (!new_prog_set) {
> + /*
> +  * If there is no Landlock program set used by the current task,
> +  * then create a new one.
> +  */
> + new_prog_set = new_landlock_prog_set();
> + if (IS_ERR(new_prog_set))
> + goto put_tmp_lists;
> + } else if (refcount_read(_prog_set->usage) > 1) {
> + /*
> +  * If the current task is not the sole user of its Landlock
> +  * program set, then duplicate them.
> +  */
> + new_prog_set = new_landlock_prog_set();
> + if (IS_ERR(new_prog_set))
> + goto put_tmp_lists;
> + for (i = 0; i < ARRAY_SIZE(new_prog_set->programs); i++) {
> + new_prog_set->programs[i] =
> + READ_ONCE(current_prog_set->programs[i]);
> + if (new_prog_set->programs[i])
> + refcount_inc(_prog_set->programs[i]->usage);
> + }
> 

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

[Alexei Starovoitov]

On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote:
> The seccomp(2) syscall can be used by a task to apply a Landlock program
> to itself. As a seccomp filter, a Landlock program is enforced for the
> current task and all its future children. A program is immutable and a
> task can only add new restricting programs to itself, forming a list of
> programss.
> 
> A Landlock program is tied to a Landlock hook. If the action on a kernel
> object is allowed by the other Linux security mechanisms (e.g. DAC,
> capabilities, other LSM), then a Landlock hook related to this kind of
> object is triggered. The list of programs for this hook is then
> evaluated. Each program return a 32-bit value which can deny the action
> on a kernel object with a non-zero value. If every programs of the list
> return zero, then the action on the object is allowed.
> 
> Multiple Landlock programs can be chained to share a 64-bits value for a
> call chain (e.g. evaluating multiple elements of a file path).  This
> chaining is restricted when a process construct this chain by loading a
> program, but additional checks are performed when it requests to apply
> this chain of programs to itself.  The restrictions ensure that it is
> not possible to call multiple programs in a way that would imply to
> handle multiple shared values (i.e. cookies) for one chain.  For now,
> only a fs_pick program can be chained to the same type of program,
> because it may make sense if they have different triggers (cf. next
> commits).  This restrictions still allows to reuse Landlock programs in
> a safe way (e.g. use the same loaded fs_walk program with multiple
> chains of fs_pick programs).
> 
> Signed-off-by: Mickaël Salaün 

...

> +struct landlock_prog_set *landlock_prepend_prog(
> + struct landlock_prog_set *current_prog_set,
> + struct bpf_prog *prog)
> +{
> + struct landlock_prog_set *new_prog_set = current_prog_set;
> + unsigned long pages;
> + int err;
> + size_t i;
> + struct landlock_prog_set tmp_prog_set = {};
> +
> + if (prog->type != BPF_PROG_TYPE_LANDLOCK_HOOK)
> + return ERR_PTR(-EINVAL);
> +
> + /* validate memory size allocation */
> + pages = prog->pages;
> + if (current_prog_set) {
> + size_t i;
> +
> + for (i = 0; i < ARRAY_SIZE(current_prog_set->programs); i++) {
> + struct landlock_prog_list *walker_p;
> +
> + for (walker_p = current_prog_set->programs[i];
> + walker_p; walker_p = walker_p->prev)
> + pages += walker_p->prog->pages;
> + }
> + /* count a struct landlock_prog_set if we need to allocate one 
> */
> + if (refcount_read(_prog_set->usage) != 1)
> + pages += round_up(sizeof(*current_prog_set), PAGE_SIZE)
> + / PAGE_SIZE;
> + }
> + if (pages > LANDLOCK_PROGRAMS_MAX_PAGES)
> + return ERR_PTR(-E2BIG);
> +
> + /* ensure early that we can allocate enough memory for the new
> +  * prog_lists */
> + err = store_landlock_prog(_prog_set, current_prog_set, prog);
> + if (err)
> + return ERR_PTR(err);
> +
> + /*
> +  * Each task_struct points to an array of prog list pointers.  These
> +  * tables are duplicated when additions are made (which means each
> +  * table needs to be refcounted for the processes using it). When a new
> +  * table is created, all the refcounters on the prog_list are bumped (to
> +  * track each table that references the prog). When a new prog is
> +  * added, it's just prepended to the list for the new table to point
> +  * at.
> +  *
> +  * Manage all the possible errors before this step to not uselessly
> +  * duplicate current_prog_set and avoid a rollback.
> +  */
> + if (!new_prog_set) {
> + /*
> +  * If there is no Landlock program set used by the current task,
> +  * then create a new one.
> +  */
> + new_prog_set = new_landlock_prog_set();
> + if (IS_ERR(new_prog_set))
> + goto put_tmp_lists;
> + } else if (refcount_read(_prog_set->usage) > 1) {
> + /*
> +  * If the current task is not the sole user of its Landlock
> +  * program set, then duplicate them.
> +  */
> + new_prog_set = new_landlock_prog_set();
> + if (IS_ERR(new_prog_set))
> + goto put_tmp_lists;
> + for (i = 0; i < ARRAY_SIZE(new_prog_set->programs); i++) {
> + new_prog_set->programs[i] =
> + READ_ONCE(current_prog_set->programs[i]);
> + if (new_prog_set->programs[i])
> + refcount_inc(_prog_set->programs[i]->usage);
> + }
> +
> + 

[PATCH v8 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Yong Deng]

Add binding documentation for Allwinner V3s CSI.

Acked-by: Maxime Ripard 
Acked-by: Sakari Ailus 
Reviewed-by: Rob Herring 
Signed-off-by: Yong Deng 
---
 .../devicetree/bindings/media/sun6i-csi.txt| 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index ..2ff47a9507a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,59 @@
+Allwinner V3s Camera Sensor Interface
+-
+
+Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
+interface and CSI1 is used for parallel interface.
+
+Required properties:
+  - compatible: value must be "allwinner,sun8i-v3s-csi"
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the CSI
+* bus: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the CSI
+
+Each CSI node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. As mentioned
+above, the endpoint's bus type should be MIPI CSI-2 for CSI0 and parallel or
+Bt656 for CSI1.
+
+Endpoint node properties for CSI1
+-
+
+- remote-endpoint  : (required) a phandle to the bus receiver's endpoint
+  node
+- bus-width:   : (required) must be 8, 10, 12 or 16
+- pclk-sample  : (optional) (default: sample on falling edge)
+- hsync-active : (only required for parallel)
+- vsync-active : (only required for parallel)
+
+Example:
+
+csi1: csi@1cb4000 {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb4000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+
+   port {
+   /* Parallel bus endpoint */
+   csi1_ep: endpoint {
+   remote-endpoint = <_ep>;
+   bus-width = <16>;
+
+   /* If hsync-active/vsync-active are missing,
+  embedded BT.656 sync is used */
+   hsync-active = <0>; /* Active low */
+   vsync-active = <0>; /* Active low */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+};
-- 
1.8.3.1

[PATCH v8 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Yong Deng]

Add binding documentation for Allwinner V3s CSI.

Acked-by: Maxime Ripard 
Acked-by: Sakari Ailus 
Reviewed-by: Rob Herring 
Signed-off-by: Yong Deng 
---
 .../devicetree/bindings/media/sun6i-csi.txt| 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index ..2ff47a9507a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,59 @@
+Allwinner V3s Camera Sensor Interface
+-
+
+Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
+interface and CSI1 is used for parallel interface.
+
+Required properties:
+  - compatible: value must be "allwinner,sun8i-v3s-csi"
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the CSI
+* bus: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the CSI
+
+Each CSI node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. As mentioned
+above, the endpoint's bus type should be MIPI CSI-2 for CSI0 and parallel or
+Bt656 for CSI1.
+
+Endpoint node properties for CSI1
+-
+
+- remote-endpoint  : (required) a phandle to the bus receiver's endpoint
+  node
+- bus-width:   : (required) must be 8, 10, 12 or 16
+- pclk-sample  : (optional) (default: sample on falling edge)
+- hsync-active : (only required for parallel)
+- vsync-active : (only required for parallel)
+
+Example:
+
+csi1: csi@1cb4000 {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb4000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+
+   port {
+   /* Parallel bus endpoint */
+   csi1_ep: endpoint {
+   remote-endpoint = <_ep>;
+   bus-width = <16>;
+
+   /* If hsync-active/vsync-active are missing,
+  embedded BT.656 sync is used */
+   hsync-active = <0>; /* Active low */
+   vsync-active = <0>; /* Active low */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+};
-- 
1.8.3.1

[PATCH v8 0/2] Initial Allwinner V3s CSI Support

[Yong Deng]

This patchset add initial support for Allwinner V3s CSI.

Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
interface and CSI1 is used for parallel interface. This is not
documented in datasheet but by test and guess.

This patchset implement a v4l2 framework driver and add a binding 
documentation for it. 

Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
  - ISP 
  - MIPI-CSI2
  - Master clock for camera sensor
  - Power regulator for the front end IC

Changes in v8:
  * Revert to v6 and add 'hack' for PHYS_OFFSET.

Changes in v7:
  * Add 'depends on ARM' in Kconfig to avoid built with non-ARM arch.

Changes in v6:
  * Add Rob Herring's review tag.
  * Fix a NULL pointer dereference by picking Maxime Ripard's patch.
  * Add Maxime Ripard's test tag.

Changes in v5:
  * Using the new SPDX tags.
  * Fix MODULE_LICENSE.
  * Add many default cases and warning messages.
  * Detail the parallel bus properties
  * Fix some spelling and syntax mistakes.

Changes in v4:
  * Deal with the CSI 'INNER QUEUE'.
CSI will lookup the next dma buffer for next frame before the
the current frame done IRQ triggered. This is not documented
but reported by Ondřej Jirman.
The BSP code has workaround for this too. It skip to mark the
first buffer as frame done for VB2 and pass the second buffer
to CSI in the first frame done ISR call. Then in second frame
done ISR call, it mark the first buffer as frame done for VB2
and pass the third buffer to CSI. And so on. The bad thing is
that the first buffer will be written twice and the first frame
is dropped even the queued buffer is sufficient.
So, I make some improvement here. Pass the next buffer to CSI
just follow starting the CSI. In this case, the first frame
will be stored in first buffer, second frame in second buffer.
This mothed is used to avoid dropping the first frame, it
would also drop frame when lacking of queued buffer.
  * Fix: using a wrong mbus_code when getting the supported formats
  * Change all fourcc to pixformat
  * Change some function names

Changes in v3:
  * Get rid of struct sun6i_csi_ops
  * Move sun6i-csi to new directory drivers/media/platform/sunxi
  * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
  * Use generic fwnode endpoints parser
  * Only support a single subdev to make things simple
  * Many complaintion fix

Changes in v2: 
  * Change sunxi-csi to sun6i-csi
  * Rebase to media_tree master branch 

Following is the 'v4l2-compliance -s -f' output, I have test this
with both interlaced and progressive signal:

# ./v4l2-compliance -s -f
v4l2-compliance SHA   : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1

Driver Info:
Driver name   : sun6i-video
Card type : sun6i-csi
Bus info  : platform:csi
Driver version: 4.15.0
Capabilities  : 0x8421
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0421
Video Capture
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: 

[PATCH v8 0/2] Initial Allwinner V3s CSI Support

[Yong Deng]

This patchset add initial support for Allwinner V3s CSI.

Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
interface and CSI1 is used for parallel interface. This is not
documented in datasheet but by test and guess.

This patchset implement a v4l2 framework driver and add a binding 
documentation for it. 

Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
  - ISP 
  - MIPI-CSI2
  - Master clock for camera sensor
  - Power regulator for the front end IC

Changes in v8:
  * Revert to v6 and add 'hack' for PHYS_OFFSET.

Changes in v7:
  * Add 'depends on ARM' in Kconfig to avoid built with non-ARM arch.

Changes in v6:
  * Add Rob Herring's review tag.
  * Fix a NULL pointer dereference by picking Maxime Ripard's patch.
  * Add Maxime Ripard's test tag.

Changes in v5:
  * Using the new SPDX tags.
  * Fix MODULE_LICENSE.
  * Add many default cases and warning messages.
  * Detail the parallel bus properties
  * Fix some spelling and syntax mistakes.

Changes in v4:
  * Deal with the CSI 'INNER QUEUE'.
CSI will lookup the next dma buffer for next frame before the
the current frame done IRQ triggered. This is not documented
but reported by Ondřej Jirman.
The BSP code has workaround for this too. It skip to mark the
first buffer as frame done for VB2 and pass the second buffer
to CSI in the first frame done ISR call. Then in second frame
done ISR call, it mark the first buffer as frame done for VB2
and pass the third buffer to CSI. And so on. The bad thing is
that the first buffer will be written twice and the first frame
is dropped even the queued buffer is sufficient.
So, I make some improvement here. Pass the next buffer to CSI
just follow starting the CSI. In this case, the first frame
will be stored in first buffer, second frame in second buffer.
This mothed is used to avoid dropping the first frame, it
would also drop frame when lacking of queued buffer.
  * Fix: using a wrong mbus_code when getting the supported formats
  * Change all fourcc to pixformat
  * Change some function names

Changes in v3:
  * Get rid of struct sun6i_csi_ops
  * Move sun6i-csi to new directory drivers/media/platform/sunxi
  * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
  * Use generic fwnode endpoints parser
  * Only support a single subdev to make things simple
  * Many complaintion fix

Changes in v2: 
  * Change sunxi-csi to sun6i-csi
  * Rebase to media_tree master branch 

Following is the 'v4l2-compliance -s -f' output, I have test this
with both interlaced and progressive signal:

# ./v4l2-compliance -s -f
v4l2-compliance SHA   : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1

Driver Info:
Driver name   : sun6i-video
Card type : sun6i-csi
Bus info  : platform:csi
Driver version: 4.15.0
Capabilities  : 0x8421
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0421
Video Capture
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: 

Re: [PATCH v8 03/13] kexec_file, x86, powerpc: factor out kexec_file_ops functions

[AKASHI Takahiro]

On Mon, Feb 26, 2018 at 12:17:18PM +0100, Philipp Rudo wrote:
> Hi AKASHI
> 
> On Thu, 22 Feb 2018 20:17:22 +0900
> AKASHI Takahiro  wrote:
> 
> [...]
> 
> > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> > index 990adae52151..a6d14a768b3e 100644
> > --- a/kernel/kexec_file.c
> > +++ b/kernel/kexec_file.c
> > @@ -26,34 +26,83 @@
> >  #include 
> >  #include "kexec_internal.h"
> > 
> > +const __weak struct kexec_file_ops * const kexec_file_loaders[] = {NULL};
> > +
> 
> Having a weak definition of kexec_file_loaders causes trouble on s390 with 
> gcc 4.8 (newer versions seem to work fine). For me it looks like that in this
> version gcc doesn't recognize __weak but use the default value for
> optimization. This leads to _kexec_kernel_image_probe to always return ENOEXEC
> because the for-loop gets optimized out.

I gave it a try to compile with gcc 4.9 (not 4.8) for arm64
and didn't see any errors or warnings, but

> The problem can easily be worked around by declaring kexec_file_loaders in
> include/linux/kexec.h and defining it in arch code. In particular doing this
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 37e9dce518aa..fc0788540d90 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -139,6 +139,8 @@ struct kexec_file_ops {
>  #endif
>  };
>  
> +extern const struct kexec_file_ops * const kexec_file_loaders[];
> +
>  /**
>   * struct kexec_buf - parameters for finding a place for a buffer in memory
>   * @image:   kexec image in which memory to search.
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 17ba407d0e79..4e3d1e4bc7f6 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -31,8 +31,6 @@
>  #include 
>  #include "kexec_internal.h"
>  
> -const __weak struct kexec_file_ops * const kexec_file_loaders[] = {NULL};
> -
>  #ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY
>  static int kexec_calculate_store_digests(struct kimage *image);
>  #else

Your change is just fine with me, too.
I will incorporate it in my next version.

Thanks,
-Takahiro AKASHI

> A nice side effect of this solution is, that a developer who forgets to define
> kexec_file_loaders gets a linker error. So he directly knows what's missing
> instead of first having to find out where/why an error gets returned.
> 
> Otherwise the series is fine for me.
> 
> Thanks
> Philipp
> 
> >  #ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY
> >  static int kexec_calculate_store_digests(struct kimage *image);
> >  #else
> >  static int kexec_calculate_store_digests(struct kimage *image) { return 0; 
> > };
> >  #endif
> > 
> > +int _kexec_kernel_image_probe(struct kimage *image, void *buf,
> > +unsigned long buf_len)
> > +{
> > +   const struct kexec_file_ops * const *fops;
> > +   int ret = -ENOEXEC;
> > +
> > +   for (fops = _file_loaders[0]; *fops && (*fops)->probe; ++fops) {
> > +   ret = (*fops)->probe(buf, buf_len);
> > +   if (!ret) {
> > +   image->fops = *fops;
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  /* Architectures can provide this probe function */
> >  int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> >  unsigned long buf_len)
> >  {
> > -   return -ENOEXEC;
> > +   return _kexec_kernel_image_probe(image, buf, buf_len);
> > +}
> > +
> > +void *_kexec_kernel_image_load(struct kimage *image)
> > +{
> > +   if (!image->fops || !image->fops->load)
> > +   return ERR_PTR(-ENOEXEC);
> > +
> > +   return image->fops->load(image, image->kernel_buf,
> > +image->kernel_buf_len, image->initrd_buf,
> > +image->initrd_buf_len, image->cmdline_buf,
> > +image->cmdline_buf_len);
> >  }
> > 
> >  void * __weak arch_kexec_kernel_image_load(struct kimage *image)
> >  {
> > -   return ERR_PTR(-ENOEXEC);
> > +   return _kexec_kernel_image_load(image);
> > +}
> > +
> > +int _kimage_file_post_load_cleanup(struct kimage *image)
> > +{
> > +   if (!image->fops || !image->fops->cleanup)
> > +   return 0;
> > +
> > +   return image->fops->cleanup(image->image_loader_data);
> >  }
> > 
> >  int __weak arch_kimage_file_post_load_cleanup(struct kimage *image)
> >  {
> > -   return -EINVAL;
> > +   return _kimage_file_post_load_cleanup(image);
> >  }
> > 
> >  #ifdef CONFIG_KEXEC_VERIFY_SIG
> > +int _kexec_kernel_verify_sig(struct kimage *image, void *buf,
> > +   unsigned long buf_len)
> > +{
> > +   if (!image->fops || !image->fops->verify_sig) {
> > +   pr_debug("kernel loader does not support signature 
> > verification.\n");
> > +   return -EKEYREJECTED;
> > +   }
> > +
> > +   return image->fops->verify_sig(buf, buf_len);
> > +}
> > +
> >  int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
> > 

Re: [PATCH v8 03/13] kexec_file, x86, powerpc: factor out kexec_file_ops functions

[AKASHI Takahiro]

On Mon, Feb 26, 2018 at 12:17:18PM +0100, Philipp Rudo wrote:
> Hi AKASHI
> 
> On Thu, 22 Feb 2018 20:17:22 +0900
> AKASHI Takahiro  wrote:
> 
> [...]
> 
> > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> > index 990adae52151..a6d14a768b3e 100644
> > --- a/kernel/kexec_file.c
> > +++ b/kernel/kexec_file.c
> > @@ -26,34 +26,83 @@
> >  #include 
> >  #include "kexec_internal.h"
> > 
> > +const __weak struct kexec_file_ops * const kexec_file_loaders[] = {NULL};
> > +
> 
> Having a weak definition of kexec_file_loaders causes trouble on s390 with 
> gcc 4.8 (newer versions seem to work fine). For me it looks like that in this
> version gcc doesn't recognize __weak but use the default value for
> optimization. This leads to _kexec_kernel_image_probe to always return ENOEXEC
> because the for-loop gets optimized out.

I gave it a try to compile with gcc 4.9 (not 4.8) for arm64
and didn't see any errors or warnings, but

> The problem can easily be worked around by declaring kexec_file_loaders in
> include/linux/kexec.h and defining it in arch code. In particular doing this
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 37e9dce518aa..fc0788540d90 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -139,6 +139,8 @@ struct kexec_file_ops {
>  #endif
>  };
>  
> +extern const struct kexec_file_ops * const kexec_file_loaders[];
> +
>  /**
>   * struct kexec_buf - parameters for finding a place for a buffer in memory
>   * @image:   kexec image in which memory to search.
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 17ba407d0e79..4e3d1e4bc7f6 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -31,8 +31,6 @@
>  #include 
>  #include "kexec_internal.h"
>  
> -const __weak struct kexec_file_ops * const kexec_file_loaders[] = {NULL};
> -
>  #ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY
>  static int kexec_calculate_store_digests(struct kimage *image);
>  #else

Your change is just fine with me, too.
I will incorporate it in my next version.

Thanks,
-Takahiro AKASHI

> A nice side effect of this solution is, that a developer who forgets to define
> kexec_file_loaders gets a linker error. So he directly knows what's missing
> instead of first having to find out where/why an error gets returned.
> 
> Otherwise the series is fine for me.
> 
> Thanks
> Philipp
> 
> >  #ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY
> >  static int kexec_calculate_store_digests(struct kimage *image);
> >  #else
> >  static int kexec_calculate_store_digests(struct kimage *image) { return 0; 
> > };
> >  #endif
> > 
> > +int _kexec_kernel_image_probe(struct kimage *image, void *buf,
> > +unsigned long buf_len)
> > +{
> > +   const struct kexec_file_ops * const *fops;
> > +   int ret = -ENOEXEC;
> > +
> > +   for (fops = _file_loaders[0]; *fops && (*fops)->probe; ++fops) {
> > +   ret = (*fops)->probe(buf, buf_len);
> > +   if (!ret) {
> > +   image->fops = *fops;
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  /* Architectures can provide this probe function */
> >  int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> >  unsigned long buf_len)
> >  {
> > -   return -ENOEXEC;
> > +   return _kexec_kernel_image_probe(image, buf, buf_len);
> > +}
> > +
> > +void *_kexec_kernel_image_load(struct kimage *image)
> > +{
> > +   if (!image->fops || !image->fops->load)
> > +   return ERR_PTR(-ENOEXEC);
> > +
> > +   return image->fops->load(image, image->kernel_buf,
> > +image->kernel_buf_len, image->initrd_buf,
> > +image->initrd_buf_len, image->cmdline_buf,
> > +image->cmdline_buf_len);
> >  }
> > 
> >  void * __weak arch_kexec_kernel_image_load(struct kimage *image)
> >  {
> > -   return ERR_PTR(-ENOEXEC);
> > +   return _kexec_kernel_image_load(image);
> > +}
> > +
> > +int _kimage_file_post_load_cleanup(struct kimage *image)
> > +{
> > +   if (!image->fops || !image->fops->cleanup)
> > +   return 0;
> > +
> > +   return image->fops->cleanup(image->image_loader_data);
> >  }
> > 
> >  int __weak arch_kimage_file_post_load_cleanup(struct kimage *image)
> >  {
> > -   return -EINVAL;
> > +   return _kimage_file_post_load_cleanup(image);
> >  }
> > 
> >  #ifdef CONFIG_KEXEC_VERIFY_SIG
> > +int _kexec_kernel_verify_sig(struct kimage *image, void *buf,
> > +   unsigned long buf_len)
> > +{
> > +   if (!image->fops || !image->fops->verify_sig) {
> > +   pr_debug("kernel loader does not support signature 
> > verification.\n");
> > +   return -EKEYREJECTED;
> > +   }
> > +
> > +   return image->fops->verify_sig(buf, buf_len);
> > +}
> > +
> >  int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
> > unsigned long buf_len)

Re: [PATCH v3 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

[Aaron Lu]

On Mon, Feb 26, 2018 at 01:53:10PM -0800, David Rientjes wrote:
> On Mon, 26 Feb 2018, Aaron Lu wrote:
> 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 3154859cccd6..35576da0a6c9 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1116,13 +1116,11 @@ static void free_pcppages_bulk(struct zone *zone, 
> > int count,
> > int migratetype = 0;
> > int batch_free = 0;
> > bool isolated_pageblocks;
> > +   struct page *page, *tmp;
> > +   LIST_HEAD(head);
> >  
> > pcp->count -= count;
> > -   spin_lock(>lock);
> > -   isolated_pageblocks = has_isolate_pageblock(zone);
> > -
> > while (count) {
> > -   struct page *page;
> > struct list_head *list;
> >  
> > /*
> > @@ -1144,26 +1142,31 @@ static void free_pcppages_bulk(struct zone *zone, 
> > int count,
> > batch_free = count;
> >  
> > do {
> > -   int mt; /* migratetype of the to-be-freed page */
> > -
> > page = list_last_entry(list, struct page, lru);
> > /* must delete as __free_one_page list manipulates */
> 
> Looks good in general, but I'm not sure how I reconcile this comment with 
> the new implementation that later links page->lru again.

Thanks for pointing this out.

I think the comment is useless now since there is a list_add_tail right
below so it's obvious we need to take the page off its original list.
I'll remove the comment in an update.

> 
> > list_del(>lru);
> >  
> > -   mt = get_pcppage_migratetype(page);
> > -   /* MIGRATE_ISOLATE page should not go to pcplists */
> > -   VM_BUG_ON_PAGE(is_migrate_isolate(mt), page);
> > -   /* Pageblock could have been isolated meanwhile */
> > -   if (unlikely(isolated_pageblocks))
> > -   mt = get_pageblock_migratetype(page);
> > -
> > if (bulkfree_pcp_prepare(page))
> > continue;
> >  
> > -   __free_one_page(page, page_to_pfn(page), zone, 0, mt);
> > -   trace_mm_page_pcpu_drain(page, 0, mt);
> > +   list_add_tail(>lru, );
> > } while (--count && --batch_free && !list_empty(list));
> > }

Re: [PATCH v3 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free

[Aaron Lu]

On Mon, Feb 26, 2018 at 01:53:10PM -0800, David Rientjes wrote:
> On Mon, 26 Feb 2018, Aaron Lu wrote:
> 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 3154859cccd6..35576da0a6c9 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1116,13 +1116,11 @@ static void free_pcppages_bulk(struct zone *zone, 
> > int count,
> > int migratetype = 0;
> > int batch_free = 0;
> > bool isolated_pageblocks;
> > +   struct page *page, *tmp;
> > +   LIST_HEAD(head);
> >  
> > pcp->count -= count;
> > -   spin_lock(>lock);
> > -   isolated_pageblocks = has_isolate_pageblock(zone);
> > -
> > while (count) {
> > -   struct page *page;
> > struct list_head *list;
> >  
> > /*
> > @@ -1144,26 +1142,31 @@ static void free_pcppages_bulk(struct zone *zone, 
> > int count,
> > batch_free = count;
> >  
> > do {
> > -   int mt; /* migratetype of the to-be-freed page */
> > -
> > page = list_last_entry(list, struct page, lru);
> > /* must delete as __free_one_page list manipulates */
> 
> Looks good in general, but I'm not sure how I reconcile this comment with 
> the new implementation that later links page->lru again.

Thanks for pointing this out.

I think the comment is useless now since there is a list_add_tail right
below so it's obvious we need to take the page off its original list.
I'll remove the comment in an update.

> 
> > list_del(>lru);
> >  
> > -   mt = get_pcppage_migratetype(page);
> > -   /* MIGRATE_ISOLATE page should not go to pcplists */
> > -   VM_BUG_ON_PAGE(is_migrate_isolate(mt), page);
> > -   /* Pageblock could have been isolated meanwhile */
> > -   if (unlikely(isolated_pageblocks))
> > -   mt = get_pageblock_migratetype(page);
> > -
> > if (bulkfree_pcp_prepare(page))
> > continue;
> >  
> > -   __free_one_page(page, page_to_pfn(page), zone, 0, mt);
> > -   trace_mm_page_pcpu_drain(page, 0, mt);
> > +   list_add_tail(>lru, );
> > } while (--count && --batch_free && !list_empty(list));
> > }

Re: [PATCH v3 1/3] mm/free_pcppages_bulk: update pcp->count inside

[Aaron Lu]

On Mon, Feb 26, 2018 at 01:48:14PM -0800, David Rientjes wrote:
> On Mon, 26 Feb 2018, Aaron Lu wrote:
> 
> > Matthew Wilcox found that all callers of free_pcppages_bulk() currently
> > update pcp->count immediately after so it's natural to do it inside
> > free_pcppages_bulk().
> > 
> > No functionality or performance change is expected from this patch.
> > 
> > Suggested-by: Matthew Wilcox 
> > Signed-off-by: Aaron Lu 
> > ---
> >  mm/page_alloc.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index cb416723538f..3154859cccd6 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1117,6 +1117,7 @@ static void free_pcppages_bulk(struct zone *zone, int 
> > count,
> > int batch_free = 0;
> > bool isolated_pageblocks;
> >  
> > +   pcp->count -= count;
> > spin_lock(>lock);
> > isolated_pageblocks = has_isolate_pageblock(zone);
> >  
> 
> Why modify pcp->count before the pages have actually been freed?

When count is still count and not zero after pages have actually been
freed :-)

> 
> I doubt that it matters too much, but at least /proc/zoneinfo uses 
> zone->lock.  I think it should be done after the lock is dropped.

Agree that it looks a bit weird to do it beforehand and I just want to
avoid adding one more local variable here.

pcp->count is not protected by zone->lock though so even we do it after
dropping the lock, it could still happen that zoneinfo shows a wrong
value of pcp->count while it should be zero(this isn't a problem since
zoneinfo doesn't need to be precise).

Anyway, I'll follow your suggestion here to avoid confusion.
 
> Otherwise, looks good.

Thanks for taking a look at this.

Re: [PATCH v3 1/3] mm/free_pcppages_bulk: update pcp->count inside

[Aaron Lu]

On Mon, Feb 26, 2018 at 01:48:14PM -0800, David Rientjes wrote:
> On Mon, 26 Feb 2018, Aaron Lu wrote:
> 
> > Matthew Wilcox found that all callers of free_pcppages_bulk() currently
> > update pcp->count immediately after so it's natural to do it inside
> > free_pcppages_bulk().
> > 
> > No functionality or performance change is expected from this patch.
> > 
> > Suggested-by: Matthew Wilcox 
> > Signed-off-by: Aaron Lu 
> > ---
> >  mm/page_alloc.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index cb416723538f..3154859cccd6 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1117,6 +1117,7 @@ static void free_pcppages_bulk(struct zone *zone, int 
> > count,
> > int batch_free = 0;
> > bool isolated_pageblocks;
> >  
> > +   pcp->count -= count;
> > spin_lock(>lock);
> > isolated_pageblocks = has_isolate_pageblock(zone);
> >  
> 
> Why modify pcp->count before the pages have actually been freed?

When count is still count and not zero after pages have actually been
freed :-)

> 
> I doubt that it matters too much, but at least /proc/zoneinfo uses 
> zone->lock.  I think it should be done after the lock is dropped.

Agree that it looks a bit weird to do it beforehand and I just want to
avoid adding one more local variable here.

pcp->count is not protected by zone->lock though so even we do it after
dropping the lock, it could still happen that zoneinfo shows a wrong
value of pcp->count while it should be zero(this isn't a problem since
zoneinfo doesn't need to be precise).

Anyway, I'll follow your suggestion here to avoid confusion.
 
> Otherwise, looks good.

Thanks for taking a look at this.

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

[skannan]

On 2018-02-24 00:41, Peter Zijlstra wrote:

On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote:

Some PMUs events can be read from any CPU. So allow the PMU to mark
events as such. For these events, we don't need to reject reads or
make smp calls to the event's CPU and cause unnecessary wake ups.

Good examples of such events would be events from caches shared across
all CPUs.


So why would the existing ACTIVE_PKG not work for you? Because clearly
your example does not cross a package.


Because based on testing it on hardware, it looks like the two clusters 
in an ARM DynamIQ design are not considered part of the same "package". 
When I say clusters, I using the more common interpretation of 
"homogeneous CPUs running on the same clock"/CPUs in a cpufreq policy 
and not ARM's new redefinition of cluster. So, on a SoC with 4 little 
and 4 big cores, it'll still trigger a lot of unnecessary smp calls/IPIs 
that cause unnecessary wakeups.


Although, I like Mark's suggestion of just giving a cpumask for every 
event and using that instead. Because the meaning of "active package" is 
very ambiguous. For example if a SoC has 2 DynamIQ blocks (not sure if 
that's possible), what's considered a package? CPUs that are sitting on 
one L3 can't read the PMU counters of a different L3. In that case, 
neither "Any CPU" nor "Active Package" is correct/usable for reducing 
IPIs.





Signed-off-by: Saravana Kannan 
---
 include/linux/perf_event.h |  3 +++
 kernel/events/core.c   | 10 --
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 7546822..ee8978f 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -510,9 +510,12 @@ typedef void (*perf_overflow_handler_t)(struct 
perf_event *,

  * PERF_EV_CAP_SOFTWARE: Is a software event.
  * PERF_EV_CAP_READ_ACTIVE_PKG: A CPU event (or cgroup event) that 
can be read

  * from any CPU in the package where it is active.
+ * PERF_EV_CAP_READ_ANY_CPU: A CPU event (or cgroup event) that can 
be read

+ * from any CPU.
  */
 #define PERF_EV_CAP_SOFTWARE   BIT(0)
 #define PERF_EV_CAP_READ_ACTIVE_PKGBIT(1)
+#define PERF_EV_CAP_READ_ANY_CPU   BIT(2)

 #define SWEVENT_HLIST_BITS 8
 #define SWEVENT_HLIST_SIZE (1 << SWEVENT_HLIST_BITS)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5d3df58..570187b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3484,6 +3484,10 @@ static int __perf_event_read_cpu(struct 
perf_event *event, int event_cpu)

 {
u16 local_pkg, event_pkg;

+   if (event->group_caps & PERF_EV_CAP_READ_ANY_CPU) {
+   return smp_processor_id();
+   }
+
if (event->group_caps & PERF_EV_CAP_READ_ACTIVE_PKG) {
int local_cpu = smp_processor_id();



@@ -3575,6 +3579,7 @@ int perf_event_read_local(struct perf_event 
*event, u64 *value,

 {
unsigned long flags;
int ret = 0;
+   bool is_any_cpu = !!(event->group_caps & PERF_EV_CAP_READ_ANY_CPU);

/*
 * Disabling interrupts avoids all counter scheduling (context
@@ -3600,7 +3605,8 @@ int perf_event_read_local(struct perf_event 
*event, u64 *value,


/* If this is a per-CPU event, it must be for this CPU */
if (!(event->attach_state & PERF_ATTACH_TASK) &&
-   event->cpu != smp_processor_id()) {
+   event->cpu != smp_processor_id() &&
+   !is_any_cpu) {
ret = -EINVAL;
goto out;
}
@@ -3610,7 +3616,7 @@ int perf_event_read_local(struct perf_event 
*event, u64 *value,

 * or local to this CPU. Furthermore it means its ACTIVE (otherwise
 * oncpu == -1).
 */
-   if (event->oncpu == smp_processor_id())
+   if (event->oncpu == smp_processor_id() || is_any_cpu)
event->pmu->read(event);

*value = local64_read(>count);


And why are you modifying read_local for this? That didn't support
ACTIVE_PKG, so why should it support this?


Maybe I'll make a separate patch to first have perf_event_read_local() 
also handle ACTIVE_PACKAGE? Because in those cases, the smp call made by 
read_local is unnecessary too.




And again, where are the users?


The DynamIQ PMU driver would be the user.

-Saravana

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

[skannan]

On 2018-02-24 00:41, Peter Zijlstra wrote:

On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote:

Some PMUs events can be read from any CPU. So allow the PMU to mark
events as such. For these events, we don't need to reject reads or
make smp calls to the event's CPU and cause unnecessary wake ups.

Good examples of such events would be events from caches shared across
all CPUs.


So why would the existing ACTIVE_PKG not work for you? Because clearly
your example does not cross a package.


Because based on testing it on hardware, it looks like the two clusters 
in an ARM DynamIQ design are not considered part of the same "package". 
When I say clusters, I using the more common interpretation of 
"homogeneous CPUs running on the same clock"/CPUs in a cpufreq policy 
and not ARM's new redefinition of cluster. So, on a SoC with 4 little 
and 4 big cores, it'll still trigger a lot of unnecessary smp calls/IPIs 
that cause unnecessary wakeups.


Although, I like Mark's suggestion of just giving a cpumask for every 
event and using that instead. Because the meaning of "active package" is 
very ambiguous. For example if a SoC has 2 DynamIQ blocks (not sure if 
that's possible), what's considered a package? CPUs that are sitting on 
one L3 can't read the PMU counters of a different L3. In that case, 
neither "Any CPU" nor "Active Package" is correct/usable for reducing 
IPIs.





Signed-off-by: Saravana Kannan 
---
 include/linux/perf_event.h |  3 +++
 kernel/events/core.c   | 10 --
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 7546822..ee8978f 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -510,9 +510,12 @@ typedef void (*perf_overflow_handler_t)(struct 
perf_event *,

  * PERF_EV_CAP_SOFTWARE: Is a software event.
  * PERF_EV_CAP_READ_ACTIVE_PKG: A CPU event (or cgroup event) that 
can be read

  * from any CPU in the package where it is active.
+ * PERF_EV_CAP_READ_ANY_CPU: A CPU event (or cgroup event) that can 
be read

+ * from any CPU.
  */
 #define PERF_EV_CAP_SOFTWARE   BIT(0)
 #define PERF_EV_CAP_READ_ACTIVE_PKGBIT(1)
+#define PERF_EV_CAP_READ_ANY_CPU   BIT(2)

 #define SWEVENT_HLIST_BITS 8
 #define SWEVENT_HLIST_SIZE (1 << SWEVENT_HLIST_BITS)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5d3df58..570187b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3484,6 +3484,10 @@ static int __perf_event_read_cpu(struct 
perf_event *event, int event_cpu)

 {
u16 local_pkg, event_pkg;

+   if (event->group_caps & PERF_EV_CAP_READ_ANY_CPU) {
+   return smp_processor_id();
+   }
+
if (event->group_caps & PERF_EV_CAP_READ_ACTIVE_PKG) {
int local_cpu = smp_processor_id();



@@ -3575,6 +3579,7 @@ int perf_event_read_local(struct perf_event 
*event, u64 *value,

 {
unsigned long flags;
int ret = 0;
+   bool is_any_cpu = !!(event->group_caps & PERF_EV_CAP_READ_ANY_CPU);

/*
 * Disabling interrupts avoids all counter scheduling (context
@@ -3600,7 +3605,8 @@ int perf_event_read_local(struct perf_event 
*event, u64 *value,


/* If this is a per-CPU event, it must be for this CPU */
if (!(event->attach_state & PERF_ATTACH_TASK) &&
-   event->cpu != smp_processor_id()) {
+   event->cpu != smp_processor_id() &&
+   !is_any_cpu) {
ret = -EINVAL;
goto out;
}
@@ -3610,7 +3616,7 @@ int perf_event_read_local(struct perf_event 
*event, u64 *value,

 * or local to this CPU. Furthermore it means its ACTIVE (otherwise
 * oncpu == -1).
 */
-   if (event->oncpu == smp_processor_id())
+   if (event->oncpu == smp_processor_id() || is_any_cpu)
event->pmu->read(event);

*value = local64_read(>count);


And why are you modifying read_local for this? That didn't support
ACTIVE_PKG, so why should it support this?


Maybe I'll make a separate patch to first have perf_event_read_local() 
also handle ACTIVE_PACKAGE? Because in those cases, the smp call made by 
read_local is unnecessary too.




And again, where are the users?


The DynamIQ PMU driver would be the user.

-Saravana

Re: [PATCH v2] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

[Quytelda Kahja]

Hans,

Thank you very much for your input on the patch; however this patch
has already been applied to the staging tree.  Additionally:

> What coding style problem? You should give a short description of
> what you are fixing.
The subject of the patch (which becomes the subject of the email when
using `git format-patch`) describes the change more fully: "Staging:
bcm2048: Fix function argument alignment in radio-bcm2048.c".  It's a
really trivial patch, so there's not too much to say.  That extra
comment is just redundant, I suppose.

> Just drop this change: it will replace one warning (non-aligned) with
> another (> 80 cols).
Breaking the 80 character line limit is arguably excusable for this
code because of the 36 character function name and 30 character
constant name; additionally, it has been said that the 80 character
line limit will probably be increased in the future since we run
modern machines that aren't limited to 80 character terminals anymore,
so this warning may soon be irrelevant anyway.

Thank you,
Quytelda Kahja

On Mon, Feb 26, 2018 at 5:51 AM, Hans Verkuil  wrote:
> On 02/20/2018 07:53 AM, Quytelda Kahja wrote:
>> Fix a coding style problem.
>
> What coding style problem? You should give a short description of
> what you are fixing.
>
>>
>> Signed-off-by: Quytelda Kahja 
>> ---
>> This is the patch without the unnecessary fixes for line length.
>>
>>  drivers/staging/media/bcm2048/radio-bcm2048.c | 22 +++---
>>  1 file changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
>> b/drivers/staging/media/bcm2048/radio-bcm2048.c
>> index 06d1920150da..f38a4f2acdde 100644
>> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
>> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
>> @@ -1864,7 +1864,7 @@ static int bcm2048_probe(struct bcm2048_device *bdev)
>>   goto unlock;
>>
>>   err = bcm2048_set_fm_search_rssi_threshold(bdev,
>> - BCM2048_DEFAULT_RSSI_THRESHOLD);
>> +
>> BCM2048_DEFAULT_RSSI_THRESHOLD);
>>   if (err < 0)
>>   goto unlock;
>>
>
> Just drop this change: it will replace one warning (non-aligned) with
> another (> 80 cols).
>
> This code is fine as it is.
>
> Regards,
>
> Hans
>
>> @@ -1942,9 +1942,9 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
>>   */
>>  #define property_write(prop, type, mask, check) 
>>  \
>>  static ssize_t bcm2048_##prop##_write(struct device *dev,\
>> - struct device_attribute *attr,  \
>> - const char *buf,\
>> - size_t count)   \
>> +   struct device_attribute *attr,\
>> +   const char *buf,  \
>> +   size_t count) \
>>  {\
>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>   type value; \
>> @@ -1966,8 +1966,8 @@ static ssize_t bcm2048_##prop##_write(struct device 
>> *dev,   \
>>
>>  #define property_read(prop, mask)\
>>  static ssize_t bcm2048_##prop##_read(struct device *dev, \
>> - struct device_attribute *attr,  \
>> - char *buf)  \
>> +  struct device_attribute *attr, \
>> +  char *buf) \
>>  {\
>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>   int value;  \
>> @@ -1985,8 +1985,8 @@ static ssize_t bcm2048_##prop##_read(struct device 
>> *dev,\
>>
>>  #define property_signed_read(prop, size, mask)  
>>  \
>>  static ssize_t bcm2048_##prop##_read(struct device *dev, \
>> - struct device_attribute *attr,  \
>> - char *buf)  \
>> +  struct device_attribute *attr, \
>> +  char *buf) \
>>  {\
>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>   size value; \
>> @@ -2005,8 +2005,8 @@ property_read(prop, mask)  
>>  \
>>
>>  

Re: [PATCH v2] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

[Quytelda Kahja]

Hans,

Thank you very much for your input on the patch; however this patch
has already been applied to the staging tree.  Additionally:

> What coding style problem? You should give a short description of
> what you are fixing.
The subject of the patch (which becomes the subject of the email when
using `git format-patch`) describes the change more fully: "Staging:
bcm2048: Fix function argument alignment in radio-bcm2048.c".  It's a
really trivial patch, so there's not too much to say.  That extra
comment is just redundant, I suppose.

> Just drop this change: it will replace one warning (non-aligned) with
> another (> 80 cols).
Breaking the 80 character line limit is arguably excusable for this
code because of the 36 character function name and 30 character
constant name; additionally, it has been said that the 80 character
line limit will probably be increased in the future since we run
modern machines that aren't limited to 80 character terminals anymore,
so this warning may soon be irrelevant anyway.

Thank you,
Quytelda Kahja

On Mon, Feb 26, 2018 at 5:51 AM, Hans Verkuil  wrote:
> On 02/20/2018 07:53 AM, Quytelda Kahja wrote:
>> Fix a coding style problem.
>
> What coding style problem? You should give a short description of
> what you are fixing.
>
>>
>> Signed-off-by: Quytelda Kahja 
>> ---
>> This is the patch without the unnecessary fixes for line length.
>>
>>  drivers/staging/media/bcm2048/radio-bcm2048.c | 22 +++---
>>  1 file changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
>> b/drivers/staging/media/bcm2048/radio-bcm2048.c
>> index 06d1920150da..f38a4f2acdde 100644
>> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
>> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
>> @@ -1864,7 +1864,7 @@ static int bcm2048_probe(struct bcm2048_device *bdev)
>>   goto unlock;
>>
>>   err = bcm2048_set_fm_search_rssi_threshold(bdev,
>> - BCM2048_DEFAULT_RSSI_THRESHOLD);
>> +
>> BCM2048_DEFAULT_RSSI_THRESHOLD);
>>   if (err < 0)
>>   goto unlock;
>>
>
> Just drop this change: it will replace one warning (non-aligned) with
> another (> 80 cols).
>
> This code is fine as it is.
>
> Regards,
>
> Hans
>
>> @@ -1942,9 +1942,9 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
>>   */
>>  #define property_write(prop, type, mask, check) 
>>  \
>>  static ssize_t bcm2048_##prop##_write(struct device *dev,\
>> - struct device_attribute *attr,  \
>> - const char *buf,\
>> - size_t count)   \
>> +   struct device_attribute *attr,\
>> +   const char *buf,  \
>> +   size_t count) \
>>  {\
>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>   type value; \
>> @@ -1966,8 +1966,8 @@ static ssize_t bcm2048_##prop##_write(struct device 
>> *dev,   \
>>
>>  #define property_read(prop, mask)\
>>  static ssize_t bcm2048_##prop##_read(struct device *dev, \
>> - struct device_attribute *attr,  \
>> - char *buf)  \
>> +  struct device_attribute *attr, \
>> +  char *buf) \
>>  {\
>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>   int value;  \
>> @@ -1985,8 +1985,8 @@ static ssize_t bcm2048_##prop##_read(struct device 
>> *dev,\
>>
>>  #define property_signed_read(prop, size, mask)  
>>  \
>>  static ssize_t bcm2048_##prop##_read(struct device *dev, \
>> - struct device_attribute *attr,  \
>> - char *buf)  \
>> +  struct device_attribute *attr, \
>> +  char *buf) \
>>  {\
>>   struct bcm2048_device *bdev = dev_get_drvdata(dev); \
>>   size value; \
>> @@ -2005,8 +2005,8 @@ property_read(prop, mask)  
>>  \
>>
>>  #define property_str_read(prop, size)   

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

[Laura Abbott]

On 02/26/2018 09:07 AM, Shuah Khan wrote:

On 02/19/2018 11:33 AM, Daniel Vetter wrote:

On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:

On 02/19/2018 07:31 AM, Daniel Vetter wrote:

On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:

Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.

Signed-off-by: Laura Abbott 
---
   tools/testing/selftests/android/ion/Makefile  |   3 +-
   tools/testing/selftests/android/ion/config|   1 +
   tools/testing/selftests/android/ion/ionmap_test.c | 136 
++
   3 files changed, 139 insertions(+), 1 deletion(-)
   create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c

diff --git a/tools/testing/selftests/android/ion/Makefile 
b/tools/testing/selftests/android/ion/Makefile
index 96e0c448b39d..d23b6d537d8b 100644
--- a/tools/testing/selftests/android/ion/Makefile
+++ b/tools/testing/selftests/android/ion/Makefile
@@ -2,7 +2,7 @@
   INCLUDEDIR := -I. -I../../../../../drivers/staging/android/uapi/
   CFLAGS := $(CFLAGS) $(INCLUDEDIR) -Wall -O2 -g
-TEST_GEN_FILES := ionapp_export ionapp_import
+TEST_GEN_FILES := ionapp_export ionapp_import ionmap_test
   all: $(TEST_GEN_FILES)
@@ -14,3 +14,4 @@ include ../../lib.mk
   $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
   $(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
+$(OUTPUT)/ionmap_test: ionmap_test.c ionutils.c
diff --git a/tools/testing/selftests/android/ion/config 
b/tools/testing/selftests/android/ion/config
index 19db6ca9aa2b..b4ad748a9dd9 100644
--- a/tools/testing/selftests/android/ion/config
+++ b/tools/testing/selftests/android/ion/config
@@ -2,3 +2,4 @@ CONFIG_ANDROID=y
   CONFIG_STAGING=y
   CONFIG_ION=y
   CONFIG_ION_SYSTEM_HEAP=y
+CONFIG_DRM_VGEM=y
diff --git a/tools/testing/selftests/android/ion/ionmap_test.c 
b/tools/testing/selftests/android/ion/ionmap_test.c
new file mode 100644
index ..dab36b06b37d
--- /dev/null
+++ b/tools/testing/selftests/android/ion/ionmap_test.c
@@ -0,0 +1,136 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "ion.h"
+#include "ionutils.h"
+
+int check_vgem(int fd)
+{
+   drm_version_t version = { 0 };
+   char name[5];
+   int ret;
+
+   version.name_len = 4;
+   version.name = name;
+
+   ret = ioctl(fd, DRM_IOCTL_VERSION, );
+   if (ret)
+   return 1;
+
+   return strcmp(name, "vgem");
+}
+
+int open_vgem(void)
+{
+   int i, fd;
+   const char *drmstr = "/dev/dri/card";
+
+   fd = -1;
+   for (i = 0; i < 16; i++) {
+   char name[80];
+
+   sprintf(name, "%s%u", drmstr, i);
+
+   fd = open(name, O_RDWR);
+   if (fd < 0)
+   continue;
+
+   if (check_vgem(fd)) {
+   close(fd);
+   continue;
+   } else {
+   break;
+   }
+
+   }
+   return fd;
+}
+
+int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+   struct drm_prime_handle import_handle = { 0 };
+   int ret;
+
+   import_handle.fd = dma_buf_fd;
+   import_handle.flags = 0;
+   import_handle.handle = 0;
+
+   ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+   if (ret == 0)
+   *handle = import_handle.handle;
+   return ret;
+}
+
+void close_handle(int vgem_fd, uint32_t handle)
+{
+   struct drm_gem_close close = { 0 };
+
+   close.handle = handle;
+   ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+int main()
+{
+   int ret, vgem_fd;
+   struct ion_buffer_info info;
+   uint32_t handle = 0;
+   struct dma_buf_sync sync = { 0 };
+
+   info.heap_type = ION_HEAP_TYPE_SYSTEM;
+   info.heap_size = 4096;
+   info.flag_type = ION_FLAG_CACHED;
+
+   ret = ion_export_buffer_fd();
+   if (ret < 0) {
+   printf("ion buffer alloc failed\n");
+   return -1;
+   }
+
+   vgem_fd = open_vgem();
+   if (vgem_fd < 0) {
+   ret = vgem_fd;
+   printf("Failed to open vgem\n");
+   goto out_ion;
+   }
+
+   ret = import_vgem_fd(vgem_fd, info.buffd, );
+
+   if (ret < 0) {
+   printf("Failed to import buffer\n");
+   goto out_vgem;
+   }
+
+   sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW;
+   ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, );
+   if (ret)
+   printf("sync start failed %d\n", errno);
+
+   memset(info.buffer, 0xff, 4096);
+
+   sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW;
+   ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, );
+   if 

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

[Laura Abbott]

On 02/26/2018 09:07 AM, Shuah Khan wrote:

On 02/19/2018 11:33 AM, Daniel Vetter wrote:

On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:

On 02/19/2018 07:31 AM, Daniel Vetter wrote:

On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:

Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.

Signed-off-by: Laura Abbott 
---
   tools/testing/selftests/android/ion/Makefile  |   3 +-
   tools/testing/selftests/android/ion/config|   1 +
   tools/testing/selftests/android/ion/ionmap_test.c | 136 
++
   3 files changed, 139 insertions(+), 1 deletion(-)
   create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c

diff --git a/tools/testing/selftests/android/ion/Makefile 
b/tools/testing/selftests/android/ion/Makefile
index 96e0c448b39d..d23b6d537d8b 100644
--- a/tools/testing/selftests/android/ion/Makefile
+++ b/tools/testing/selftests/android/ion/Makefile
@@ -2,7 +2,7 @@
   INCLUDEDIR := -I. -I../../../../../drivers/staging/android/uapi/
   CFLAGS := $(CFLAGS) $(INCLUDEDIR) -Wall -O2 -g
-TEST_GEN_FILES := ionapp_export ionapp_import
+TEST_GEN_FILES := ionapp_export ionapp_import ionmap_test
   all: $(TEST_GEN_FILES)
@@ -14,3 +14,4 @@ include ../../lib.mk
   $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
   $(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
+$(OUTPUT)/ionmap_test: ionmap_test.c ionutils.c
diff --git a/tools/testing/selftests/android/ion/config 
b/tools/testing/selftests/android/ion/config
index 19db6ca9aa2b..b4ad748a9dd9 100644
--- a/tools/testing/selftests/android/ion/config
+++ b/tools/testing/selftests/android/ion/config
@@ -2,3 +2,4 @@ CONFIG_ANDROID=y
   CONFIG_STAGING=y
   CONFIG_ION=y
   CONFIG_ION_SYSTEM_HEAP=y
+CONFIG_DRM_VGEM=y
diff --git a/tools/testing/selftests/android/ion/ionmap_test.c 
b/tools/testing/selftests/android/ion/ionmap_test.c
new file mode 100644
index ..dab36b06b37d
--- /dev/null
+++ b/tools/testing/selftests/android/ion/ionmap_test.c
@@ -0,0 +1,136 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "ion.h"
+#include "ionutils.h"
+
+int check_vgem(int fd)
+{
+   drm_version_t version = { 0 };
+   char name[5];
+   int ret;
+
+   version.name_len = 4;
+   version.name = name;
+
+   ret = ioctl(fd, DRM_IOCTL_VERSION, );
+   if (ret)
+   return 1;
+
+   return strcmp(name, "vgem");
+}
+
+int open_vgem(void)
+{
+   int i, fd;
+   const char *drmstr = "/dev/dri/card";
+
+   fd = -1;
+   for (i = 0; i < 16; i++) {
+   char name[80];
+
+   sprintf(name, "%s%u", drmstr, i);
+
+   fd = open(name, O_RDWR);
+   if (fd < 0)
+   continue;
+
+   if (check_vgem(fd)) {
+   close(fd);
+   continue;
+   } else {
+   break;
+   }
+
+   }
+   return fd;
+}
+
+int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+   struct drm_prime_handle import_handle = { 0 };
+   int ret;
+
+   import_handle.fd = dma_buf_fd;
+   import_handle.flags = 0;
+   import_handle.handle = 0;
+
+   ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+   if (ret == 0)
+   *handle = import_handle.handle;
+   return ret;
+}
+
+void close_handle(int vgem_fd, uint32_t handle)
+{
+   struct drm_gem_close close = { 0 };
+
+   close.handle = handle;
+   ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+int main()
+{
+   int ret, vgem_fd;
+   struct ion_buffer_info info;
+   uint32_t handle = 0;
+   struct dma_buf_sync sync = { 0 };
+
+   info.heap_type = ION_HEAP_TYPE_SYSTEM;
+   info.heap_size = 4096;
+   info.flag_type = ION_FLAG_CACHED;
+
+   ret = ion_export_buffer_fd();
+   if (ret < 0) {
+   printf("ion buffer alloc failed\n");
+   return -1;
+   }
+
+   vgem_fd = open_vgem();
+   if (vgem_fd < 0) {
+   ret = vgem_fd;
+   printf("Failed to open vgem\n");
+   goto out_ion;
+   }
+
+   ret = import_vgem_fd(vgem_fd, info.buffd, );
+
+   if (ret < 0) {
+   printf("Failed to import buffer\n");
+   goto out_vgem;
+   }
+
+   sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW;
+   ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, );
+   if (ret)
+   printf("sync start failed %d\n", errno);
+
+   memset(info.buffer, 0xff, 4096);
+
+   sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW;
+   ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, );
+   if (ret)
+   

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

[David Rientjes]

On Mon, 26 Feb 2018, Yang Shi wrote:

> > Rather than killable, we have patches that introduce down_read_unfair()
> > variants for the files you've modified (cmdline and environ) as well as
> > others (maps, numa_maps, smaps).
> 
> You mean you have such functionality used by google internally?
> 

Yup, see https://lwn.net/Articles/387720.

> > When another thread is holding down_read() and there are queued
> > down_write()'s, down_read_unfair() allows for grabbing the rwsem without
> > queueing for it.  Additionally, when another thread is holding
> > down_write(), down_read_unfair() allows for queueing in front of other
> > threads trying to grab it for write as well.
> 
> It sounds the __unfair variant make the caller have chance to jump the gun to
> grab the semaphore before other waiters, right? But when a process holds the
> semaphore, i.e. mmap_sem, for a long time, it still has to sleep in
> uninterruptible state, right?
> 

Right, it's solving two separate things which I think may be able to be 
merged together.  Killable is solving an issue where the rwsem is blocking 
for a long period of time in uninterruptible sleep, and unfair is solving 
an issue where reading the procfs files gets stalled for a long period of 
time.  We haven't run into an issue (yet) where killable would have solved 
it; we just have the unfair variants to grab the rwsem asap and then, if 
killable, gracefully return.

> > Ingo would know more about whether a variant like that in upstream Linux
> > would be acceptable.
> > 
> > Would you be interested in unfair variants instead of only addressing
> > killable?
> 
> Yes, I'm although it still looks overkilling to me for reading /proc.
> 

We make certain inferences on the readablility of procfs files for other 
threads to determine how much its mm's mmap_sem is contended.

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

[David Rientjes]

On Mon, 26 Feb 2018, Yang Shi wrote:

> > Rather than killable, we have patches that introduce down_read_unfair()
> > variants for the files you've modified (cmdline and environ) as well as
> > others (maps, numa_maps, smaps).
> 
> You mean you have such functionality used by google internally?
> 

Yup, see https://lwn.net/Articles/387720.

> > When another thread is holding down_read() and there are queued
> > down_write()'s, down_read_unfair() allows for grabbing the rwsem without
> > queueing for it.  Additionally, when another thread is holding
> > down_write(), down_read_unfair() allows for queueing in front of other
> > threads trying to grab it for write as well.
> 
> It sounds the __unfair variant make the caller have chance to jump the gun to
> grab the semaphore before other waiters, right? But when a process holds the
> semaphore, i.e. mmap_sem, for a long time, it still has to sleep in
> uninterruptible state, right?
> 

Right, it's solving two separate things which I think may be able to be 
merged together.  Killable is solving an issue where the rwsem is blocking 
for a long period of time in uninterruptible sleep, and unfair is solving 
an issue where reading the procfs files gets stalled for a long period of 
time.  We haven't run into an issue (yet) where killable would have solved 
it; we just have the unfair variants to grab the rwsem asap and then, if 
killable, gracefully return.

> > Ingo would know more about whether a variant like that in upstream Linux
> > would be acceptable.
> > 
> > Would you be interested in unfair variants instead of only addressing
> > killable?
> 
> Yes, I'm although it still looks overkilling to me for reading /proc.
> 

We make certain inferences on the readablility of procfs files for other 
threads to determine how much its mm's mmap_sem is contended.

[PATCH v2] perf annotate: Support to display the IPC/Cycle in tui mode

[Jin Yao]

Unlike the perf report interactive annotate mode, the perf annotate
doesn't display the IPC/Cycle even if branch info is recorded in perf
data file.

perf record -b ...
perf annotate function

It should show IPC/cycle, but it doesn't.

This patch lets perf annotate support the displaying of IPC/Cycle if
branch info is in perf data.

For example,

perf annotate compute_flag

Percent│ IPC Cycle
   │
   │
   │Disassembly of section .text:
   │
   │00400640 :
   │compute_flag():
   │volatile int count;
   │static unsigned int s_randseed;
   │
   │__attribute__((noinline))
   │int compute_flag()
   │{
 22.96 │1.18   584sub$0x8,%rsp
   │int i;
   │
   │i = rand() % 2;
 23.02 │1.18 1  → callq  rand@plt
   │
   │return i;
 27.05 │3.37  mov%eax,%edx
   │}
   │3.37  add$0x8,%rsp
   │{
   │int i;
   │
   │i = rand() % 2;
   │
   │return i;
   │3.37  shr$0x1f,%edx
   │3.37  add%edx,%eax
   │3.37  and$0x1,%eax
   │3.37  sub%edx,%eax
   │}
 26.97 │3.37 2  ← retq

Note that, this patch only supports tui mode. For stdio,
now it just keeps original behavior. Will support it in a
follow-up patch.

perf annotate compute_flag --stdio

 Percent |  Source code & Disassembly of div for cycles:ppp (7993 samples)
--
 :
 :
 :
 :Disassembly of section .text:
 :
 :00400640 :
 :compute_flag():
 :volatile int count;
 :static unsigned int s_randseed;
 :
 :__attribute__((noinline))
 :int compute_flag()
 :{
0.29 :   400640:   sub$0x8,%rsp # +100.00%
 :int i;
 :
 :i = rand() % 2;
   42.93 :   400644:   callq  400490  # -100.00% (p:100.00%)
 :
 :return i;
0.10 :   400649:   mov%eax,%edx # +100.00%
 :}
0.94 :   40064b:   add$0x8,%rsp
 :{
 :int i;
 :
 :i = rand() % 2;
 :
 :return i;
   27.02 :   40064f:   shr$0x1f,%edx
0.15 :   400652:   add%edx,%eax
1.24 :   400654:   and$0x1,%eax
2.08 :   400657:   sub%edx,%eax
 :}
   25.26 :   400659:   retq # -100.00% (p:100.00%)

Change-log:
---
v2:
---
No code change. Just change the patch description to make it more clear.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-annotate.c | 88 ---
 1 file changed, 82 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index f15731a..ead6ae4 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -44,6 +44,7 @@ struct perf_annotate {
bool   full_paths;
bool   print_line;
bool   skip_missing;
+   bool   has_br_stack;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -146,16 +147,73 @@ static void process_branch_stack(struct branch_stack *bs, 
struct addr_location *
free(bi);
 }
 
+static int hist_iter__branch_callback(struct hist_entry_iter *iter,
+ struct addr_location *al __maybe_unused,
+ bool single __maybe_unused,
+ void *arg __maybe_unused)
+{
+   struct hist_entry *he = iter->he;
+   struct branch_info *bi;
+   struct perf_sample *sample = iter->sample;
+   struct perf_evsel *evsel = iter->evsel;
+   int err;
+
+   hist__account_cycles(sample->branch_stack, al, sample, false);
+
+   bi = he->branch_info;
+   err = addr_map_symbol__inc_samples(>from, sample, evsel->idx);
+
+   if (err)
+   goto out;
+
+   err = addr_map_symbol__inc_samples(>to, sample, evsel->idx);
+
+out:
+   return err;
+}
+
+static int process_branch_callback(struct perf_evsel *evsel,
+  struct perf_sample *sample,
+  struct addr_location *al __maybe_unused,
+

[PATCH v2] perf annotate: Support to display the IPC/Cycle in tui mode

[Jin Yao]

Unlike the perf report interactive annotate mode, the perf annotate
doesn't display the IPC/Cycle even if branch info is recorded in perf
data file.

perf record -b ...
perf annotate function

It should show IPC/cycle, but it doesn't.

This patch lets perf annotate support the displaying of IPC/Cycle if
branch info is in perf data.

For example,

perf annotate compute_flag

Percent│ IPC Cycle
   │
   │
   │Disassembly of section .text:
   │
   │00400640 :
   │compute_flag():
   │volatile int count;
   │static unsigned int s_randseed;
   │
   │__attribute__((noinline))
   │int compute_flag()
   │{
 22.96 │1.18   584sub$0x8,%rsp
   │int i;
   │
   │i = rand() % 2;
 23.02 │1.18 1  → callq  rand@plt
   │
   │return i;
 27.05 │3.37  mov%eax,%edx
   │}
   │3.37  add$0x8,%rsp
   │{
   │int i;
   │
   │i = rand() % 2;
   │
   │return i;
   │3.37  shr$0x1f,%edx
   │3.37  add%edx,%eax
   │3.37  and$0x1,%eax
   │3.37  sub%edx,%eax
   │}
 26.97 │3.37 2  ← retq

Note that, this patch only supports tui mode. For stdio,
now it just keeps original behavior. Will support it in a
follow-up patch.

perf annotate compute_flag --stdio

 Percent |  Source code & Disassembly of div for cycles:ppp (7993 samples)
--
 :
 :
 :
 :Disassembly of section .text:
 :
 :00400640 :
 :compute_flag():
 :volatile int count;
 :static unsigned int s_randseed;
 :
 :__attribute__((noinline))
 :int compute_flag()
 :{
0.29 :   400640:   sub$0x8,%rsp # +100.00%
 :int i;
 :
 :i = rand() % 2;
   42.93 :   400644:   callq  400490  # -100.00% (p:100.00%)
 :
 :return i;
0.10 :   400649:   mov%eax,%edx # +100.00%
 :}
0.94 :   40064b:   add$0x8,%rsp
 :{
 :int i;
 :
 :i = rand() % 2;
 :
 :return i;
   27.02 :   40064f:   shr$0x1f,%edx
0.15 :   400652:   add%edx,%eax
1.24 :   400654:   and$0x1,%eax
2.08 :   400657:   sub%edx,%eax
 :}
   25.26 :   400659:   retq # -100.00% (p:100.00%)

Change-log:
---
v2:
---
No code change. Just change the patch description to make it more clear.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-annotate.c | 88 ---
 1 file changed, 82 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index f15731a..ead6ae4 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -44,6 +44,7 @@ struct perf_annotate {
bool   full_paths;
bool   print_line;
bool   skip_missing;
+   bool   has_br_stack;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -146,16 +147,73 @@ static void process_branch_stack(struct branch_stack *bs, 
struct addr_location *
free(bi);
 }
 
+static int hist_iter__branch_callback(struct hist_entry_iter *iter,
+ struct addr_location *al __maybe_unused,
+ bool single __maybe_unused,
+ void *arg __maybe_unused)
+{
+   struct hist_entry *he = iter->he;
+   struct branch_info *bi;
+   struct perf_sample *sample = iter->sample;
+   struct perf_evsel *evsel = iter->evsel;
+   int err;
+
+   hist__account_cycles(sample->branch_stack, al, sample, false);
+
+   bi = he->branch_info;
+   err = addr_map_symbol__inc_samples(>from, sample, evsel->idx);
+
+   if (err)
+   goto out;
+
+   err = addr_map_symbol__inc_samples(>to, sample, evsel->idx);
+
+out:
+   return err;
+}
+
+static int process_branch_callback(struct perf_evsel *evsel,
+  struct perf_sample *sample,
+  struct addr_location *al __maybe_unused,
+  struct perf_annotate *ann,
+ 

[PATCH] x86: devicetree: enable multiprocessing and interrupt setting in DT

[Ivan Gorinov]

The x86-specific Device Tree implementation only supported single CPU,
and IRQ allocation from DT parameters was broken in recent versions.

This change enables multiprocessing and fixes broken IRQ allocation.

Signed-off-by: Ivan Gorinov 
---
 arch/x86/kernel/devicetree.c | 41 ++---
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 25de5f6..f885eab 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -130,6 +130,29 @@ static void __init dtb_setup_hpet(void)
 #endif
 }
 
+static void __init dtb_cpu_setup(void)
+{
+   struct device_node *dn;
+   struct resource r;
+   const void *prop;
+   int apic_id, version;
+   int ret;
+
+   version = GET_APIC_VERSION(apic_read(APIC_LVR));
+   for_each_node_by_type(dn, "cpu") {
+   prop = of_get_property(dn, "intel,apic-id", NULL);
+   if (prop) {
+   apic_id = be32_to_cpup(prop);
+   } else {
+   ret = of_address_to_resource(dn, 0, );
+   if (WARN_ON(ret))
+   continue;
+   apic_id = r.start;
+   }
+   generic_processor_info(apic_id, version);
+   }
+}
+
 static void __init dtb_lapic_setup(void)
 {
 #ifdef CONFIG_X86_LOCAL_APIC
@@ -153,8 +176,6 @@ static void __init dtb_lapic_setup(void)
    smp_found_config = 1;
    pic_mode = 1;
    register_lapic_address(r.start);
-   generic_processor_info(boot_cpu_physical_apicid,
-      GET_APIC_VERSION(apic_read(APIC_LVR)));
 #endif
 }
 
@@ -194,19 +215,22 @@ static struct of_ioapic_type of_ioapic_type[] =
 static int dt_irqdomain_alloc(struct irq_domain *domain, unsigned int virq,
      unsigned int nr_irqs, void *arg)
 {
-   struct of_phandle_args *irq_data = (void *)arg;
+   struct irq_fwspec *fwspec = (struct irq_fwspec *)arg;
    struct of_ioapic_type *it;
    struct irq_alloc_info tmp;
+   int type_index;
 
-   if (WARN_ON(irq_data->args_count < 2))
+   if (WARN_ON(fwspec->param_count < 2))
    return -EINVAL;
-   if (irq_data->args[1] >= ARRAY_SIZE(of_ioapic_type))
+
+   type_index = fwspec->param[1];
+   if (type_index >= ARRAY_SIZE(of_ioapic_type))
    return -EINVAL;
 
-   it = _ioapic_type[irq_data->args[1]];
+   it = _ioapic_type[type_index];
    ioapic_set_alloc_attr(, NUMA_NO_NODE, it->trigger, it->polarity);
    tmp.ioapic_id = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
-   tmp.ioapic_pin = irq_data->args[0];
+   tmp.ioapic_pin = fwspec->param[0];
 
    return mp_irqdomain_alloc(domain, virq, nr_irqs, );
 }
@@ -256,6 +280,7 @@ static void __init dtb_ioapic_setup(void) {}
 static void __init dtb_apic_setup(void)
 {
    dtb_lapic_setup();
+   dtb_cpu_setup();
    dtb_ioapic_setup();
 }
 
@@ -278,6 +303,8 @@ static void __init x86_flattree_get_config(void)
    map_len = size;
    }
 
+   early_init_dt_verify(dt);
+
    unflatten_and_copy_device_tree();
    early_memunmap(dt, map_len);
 }
-- 
2.7.4

[PATCH] x86: devicetree: enable multiprocessing and interrupt setting in DT

[Ivan Gorinov]

The x86-specific Device Tree implementation only supported single CPU,
and IRQ allocation from DT parameters was broken in recent versions.

This change enables multiprocessing and fixes broken IRQ allocation.

Signed-off-by: Ivan Gorinov 
---
 arch/x86/kernel/devicetree.c | 41 ++---
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 25de5f6..f885eab 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -130,6 +130,29 @@ static void __init dtb_setup_hpet(void)
 #endif
 }
 
+static void __init dtb_cpu_setup(void)
+{
+   struct device_node *dn;
+   struct resource r;
+   const void *prop;
+   int apic_id, version;
+   int ret;
+
+   version = GET_APIC_VERSION(apic_read(APIC_LVR));
+   for_each_node_by_type(dn, "cpu") {
+   prop = of_get_property(dn, "intel,apic-id", NULL);
+   if (prop) {
+   apic_id = be32_to_cpup(prop);
+   } else {
+   ret = of_address_to_resource(dn, 0, );
+   if (WARN_ON(ret))
+   continue;
+   apic_id = r.start;
+   }
+   generic_processor_info(apic_id, version);
+   }
+}
+
 static void __init dtb_lapic_setup(void)
 {
 #ifdef CONFIG_X86_LOCAL_APIC
@@ -153,8 +176,6 @@ static void __init dtb_lapic_setup(void)
    smp_found_config = 1;
    pic_mode = 1;
    register_lapic_address(r.start);
-   generic_processor_info(boot_cpu_physical_apicid,
-      GET_APIC_VERSION(apic_read(APIC_LVR)));
 #endif
 }
 
@@ -194,19 +215,22 @@ static struct of_ioapic_type of_ioapic_type[] =
 static int dt_irqdomain_alloc(struct irq_domain *domain, unsigned int virq,
      unsigned int nr_irqs, void *arg)
 {
-   struct of_phandle_args *irq_data = (void *)arg;
+   struct irq_fwspec *fwspec = (struct irq_fwspec *)arg;
    struct of_ioapic_type *it;
    struct irq_alloc_info tmp;
+   int type_index;
 
-   if (WARN_ON(irq_data->args_count < 2))
+   if (WARN_ON(fwspec->param_count < 2))
    return -EINVAL;
-   if (irq_data->args[1] >= ARRAY_SIZE(of_ioapic_type))
+
+   type_index = fwspec->param[1];
+   if (type_index >= ARRAY_SIZE(of_ioapic_type))
    return -EINVAL;
 
-   it = _ioapic_type[irq_data->args[1]];
+   it = _ioapic_type[type_index];
    ioapic_set_alloc_attr(, NUMA_NO_NODE, it->trigger, it->polarity);
    tmp.ioapic_id = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
-   tmp.ioapic_pin = irq_data->args[0];
+   tmp.ioapic_pin = fwspec->param[0];
 
    return mp_irqdomain_alloc(domain, virq, nr_irqs, );
 }
@@ -256,6 +280,7 @@ static void __init dtb_ioapic_setup(void) {}
 static void __init dtb_apic_setup(void)
 {
    dtb_lapic_setup();
+   dtb_cpu_setup();
    dtb_ioapic_setup();
 }
 
@@ -278,6 +303,8 @@ static void __init x86_flattree_get_config(void)
    map_len = size;
    }
 
+   early_init_dt_verify(dt);
+
    unflatten_and_copy_device_tree();
    early_memunmap(dt, map_len);
 }
-- 
2.7.4

Re: [PATCH v3] KVM: X86: Allow userspace to define the microcode version

[Nadav Amit]

Wanpeng Li  wrote:

> From: Wanpeng Li 
> 
> Linux (among the others) has checks to make sure that certain features 
> aren't enabled on a certain family/model/stepping if the microcode version 
> isn't greater than or equal to a known good version.
> 
> By exposing the real microcode version, we're preventing buggy guests that
> don't check that they are running virtualized (i.e., they should trust the
> hypervisor) from disabling features that are effectively not buggy.
> 
> Suggested-by: Filippo Sironi 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Liran Alon 
> Signed-off-by: Wanpeng Li 
> ---
> v2 -> v3:
> * remove the shifts
> * add the MSR_IA32_UCODE_REV version to the "feature MSRs"
> v1 -> v2:
> * add MSR_IA32_UCODE_REV to emulated_msrs
> 
> arch/x86/include/asm/kvm_host.h |  1 +
> arch/x86/kvm/x86.c  | 19 +++
> 2 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 938d453..6e13f2f 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
>   u64 smi_count;
>   bool tpr_access_reporting;
>   u64 ia32_xss;
> + u32 microcode_version;
> 
>   /*
>* Paging state of the vcpu
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index d4985a9..00af28e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1058,6 +1058,7 @@ static unsigned num_emulated_msrs;
> static u32 msr_based_features[] = {
>   MSR_IA32_ARCH_CAPABILITIES,
>   MSR_F10H_DECFG,
> + MSR_IA32_UCODE_REV,
> };
> 
> static unsigned int num_msr_based_features;
> @@ -1067,8 +1068,14 @@ static int do_get_msr_feature(struct kvm_vcpu *vcpu, 
> unsigned index, u64 *data)
>   struct kvm_msr_entry msr;
> 
>   msr.index = index;
> - if (kvm_x86_ops->get_msr_feature())
> - return 1;
> + switch (msr.index) {
> + case MSR_IA32_UCODE_REV:
> + rdmsrl(msr.index, msr.data);
> + break;
> + default:
> + if (kvm_x86_ops->get_msr_feature())
> + return 1;
> + }
> 
>   *data = msr.data;
> 
> @@ -2248,7 +2255,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
> 
>   switch (msr) {
>   case MSR_AMD64_NB_CFG:
> - case MSR_IA32_UCODE_REV:
>   case MSR_IA32_UCODE_WRITE:
>   case MSR_VM_HSAVE_PA:
>   case MSR_AMD64_PATCH_LOADER:
> @@ -2256,6 +2262,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   case MSR_AMD64_DC_CFG:
>   break;
> 
> + case MSR_IA32_UCODE_REV:
> + if (msr_info->host_initiated)
> + vcpu->arch.microcode_version = data;
> + break;
>   case MSR_EFER:
>   return set_efer(vcpu, data);
>   case MSR_K7_HWCR:
> @@ -2551,7 +2561,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   msr_info->data = 0;
>   break;
>   case MSR_IA32_UCODE_REV:
> - msr_info->data = 0x1ULL;
> + msr_info->data = (u64)vcpu->arch.microcode_version;

I think that the shifts are missing here (the version should be on the high
bits according to intel_get_microcode_revision() ).

Re: [PATCH v3] KVM: X86: Allow userspace to define the microcode version

[Nadav Amit]

Wanpeng Li  wrote:

> From: Wanpeng Li 
> 
> Linux (among the others) has checks to make sure that certain features 
> aren't enabled on a certain family/model/stepping if the microcode version 
> isn't greater than or equal to a known good version.
> 
> By exposing the real microcode version, we're preventing buggy guests that
> don't check that they are running virtualized (i.e., they should trust the
> hypervisor) from disabling features that are effectively not buggy.
> 
> Suggested-by: Filippo Sironi 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Liran Alon 
> Signed-off-by: Wanpeng Li 
> ---
> v2 -> v3:
> * remove the shifts
> * add the MSR_IA32_UCODE_REV version to the "feature MSRs"
> v1 -> v2:
> * add MSR_IA32_UCODE_REV to emulated_msrs
> 
> arch/x86/include/asm/kvm_host.h |  1 +
> arch/x86/kvm/x86.c  | 19 +++
> 2 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 938d453..6e13f2f 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
>   u64 smi_count;
>   bool tpr_access_reporting;
>   u64 ia32_xss;
> + u32 microcode_version;
> 
>   /*
>* Paging state of the vcpu
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index d4985a9..00af28e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1058,6 +1058,7 @@ static unsigned num_emulated_msrs;
> static u32 msr_based_features[] = {
>   MSR_IA32_ARCH_CAPABILITIES,
>   MSR_F10H_DECFG,
> + MSR_IA32_UCODE_REV,
> };
> 
> static unsigned int num_msr_based_features;
> @@ -1067,8 +1068,14 @@ static int do_get_msr_feature(struct kvm_vcpu *vcpu, 
> unsigned index, u64 *data)
>   struct kvm_msr_entry msr;
> 
>   msr.index = index;
> - if (kvm_x86_ops->get_msr_feature())
> - return 1;
> + switch (msr.index) {
> + case MSR_IA32_UCODE_REV:
> + rdmsrl(msr.index, msr.data);
> + break;
> + default:
> + if (kvm_x86_ops->get_msr_feature())
> + return 1;
> + }
> 
>   *data = msr.data;
> 
> @@ -2248,7 +2255,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
> 
>   switch (msr) {
>   case MSR_AMD64_NB_CFG:
> - case MSR_IA32_UCODE_REV:
>   case MSR_IA32_UCODE_WRITE:
>   case MSR_VM_HSAVE_PA:
>   case MSR_AMD64_PATCH_LOADER:
> @@ -2256,6 +2262,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   case MSR_AMD64_DC_CFG:
>   break;
> 
> + case MSR_IA32_UCODE_REV:
> + if (msr_info->host_initiated)
> + vcpu->arch.microcode_version = data;
> + break;
>   case MSR_EFER:
>   return set_efer(vcpu, data);
>   case MSR_K7_HWCR:
> @@ -2551,7 +2561,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   msr_info->data = 0;
>   break;
>   case MSR_IA32_UCODE_REV:
> - msr_info->data = 0x1ULL;
> + msr_info->data = (u64)vcpu->arch.microcode_version;

I think that the shifts are missing here (the version should be on the high
bits according to intel_get_microcode_revision() ).

Re: [PATCH v5 2/9] watchdog/hpwdt: Remove legacy NMI sourcing.

[Guenter Roeck]

On 02/26/2018 05:02 PM, Jerry Hoemann wrote:

On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote:

On 02/26/2018 06:11 AM, Arnd Bergmann wrote:

On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann  wrote:

Gen8 and prior Proliant systems supported the "CRU" interface
to firmware.  This interfaces allows linux to "call back" into firmware
to source the cause of an NMI.  This feature isn't fully utilized
as the actual source of the NMI isn't printed, the driver only
indicates that the source couldn't be determined when the call
fails.

With the advent of Gen9, iCRU replaces the CRU. The call back
feature is no longer available in firmware.  To be compatible and
not attempt to call back into firmware on system not supporting CRU,
the SMBIOS table is consulted to determine if it is safe to
make the call back or not.

This results in about half of the driver code being devoted
to either making CRU calls or determing if it is safe to make
CRU calls.  As noted, the driver isn't really using the results of
the CRU calls.

Furthermore, as a consequence of the Spectre security issue, the
BIOS/EFI calls are being wrapped into Spectre-disabling section.
Removing the call back in hpwdt_pretimeout assists in this effort.

As the CRU sourcing of the NMI isn't required for handling the
NMI and there are security concerns with making the call back, remove
the legacy (pre Gen9) NMI sourcing and the DMI code to determine if
the system had the CRU interface.

Signed-off-by: Jerry Hoemann 


This avoids a warning in mainline kernels, so that's great:

drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call
found in RETPOLINE build

I wonder what we do about stable kernels. Are both this patch and the patch
that added the objtool warning message candidates for backports to
stable kernels?



Makes sense to me, but it is really a bit more than a bug fix, so I'll
leave it up to Jerry/HPE to make the call in respect to hpwdt.



Generally speaking, HPE customers who run linux do so through a distro
vendor and pick up patches from them.  But I'm sure there are some
customers who do things differently.

The distro vendor's have their own repos and we'll work with them
to back port patches to their code base.  So, I typically don't do a lot
of kernel.org stable branch work.

Looks like objtool has been enhanced to find Spectre vulnerable code.
Are the other kernel patches related to Spectre being back ported
to stable release lines?  If yes, it probably make sense to do
the hpwdt change as well.



Spectre has been backported to v4.4 and later. I don't know about earlier 
kernels.


Is just the patch removing the firmware call back wanted/needed? Or the
whole driver rewrite?  (The older baseline don't have all the watchdog
features that the patch set uses.)



We would only want to backport this patch. The rest is really out of scope.


Which stable baseline(s) would need to be patched?  Priority?

Who does it?  (i.e. do you want me to submit patches to the stable baseline?)


We would tag the patch for stable (and submit it into v4.16-rc). Greg would
take care of the rest unless there are conflicts, in which case we get a note
telling us that a backport is needed.

Guenter

Re: [PATCH v5 2/9] watchdog/hpwdt: Remove legacy NMI sourcing.

[Guenter Roeck]

On 02/26/2018 05:02 PM, Jerry Hoemann wrote:

On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote:

On 02/26/2018 06:11 AM, Arnd Bergmann wrote:

On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann  wrote:

Gen8 and prior Proliant systems supported the "CRU" interface
to firmware.  This interfaces allows linux to "call back" into firmware
to source the cause of an NMI.  This feature isn't fully utilized
as the actual source of the NMI isn't printed, the driver only
indicates that the source couldn't be determined when the call
fails.

With the advent of Gen9, iCRU replaces the CRU. The call back
feature is no longer available in firmware.  To be compatible and
not attempt to call back into firmware on system not supporting CRU,
the SMBIOS table is consulted to determine if it is safe to
make the call back or not.

This results in about half of the driver code being devoted
to either making CRU calls or determing if it is safe to make
CRU calls.  As noted, the driver isn't really using the results of
the CRU calls.

Furthermore, as a consequence of the Spectre security issue, the
BIOS/EFI calls are being wrapped into Spectre-disabling section.
Removing the call back in hpwdt_pretimeout assists in this effort.

As the CRU sourcing of the NMI isn't required for handling the
NMI and there are security concerns with making the call back, remove
the legacy (pre Gen9) NMI sourcing and the DMI code to determine if
the system had the CRU interface.

Signed-off-by: Jerry Hoemann 


This avoids a warning in mainline kernels, so that's great:

drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call
found in RETPOLINE build

I wonder what we do about stable kernels. Are both this patch and the patch
that added the objtool warning message candidates for backports to
stable kernels?



Makes sense to me, but it is really a bit more than a bug fix, so I'll
leave it up to Jerry/HPE to make the call in respect to hpwdt.



Generally speaking, HPE customers who run linux do so through a distro
vendor and pick up patches from them.  But I'm sure there are some
customers who do things differently.

The distro vendor's have their own repos and we'll work with them
to back port patches to their code base.  So, I typically don't do a lot
of kernel.org stable branch work.

Looks like objtool has been enhanced to find Spectre vulnerable code.
Are the other kernel patches related to Spectre being back ported
to stable release lines?  If yes, it probably make sense to do
the hpwdt change as well.



Spectre has been backported to v4.4 and later. I don't know about earlier 
kernels.


Is just the patch removing the firmware call back wanted/needed? Or the
whole driver rewrite?  (The older baseline don't have all the watchdog
features that the patch set uses.)



We would only want to backport this patch. The rest is really out of scope.


Which stable baseline(s) would need to be patched?  Priority?

Who does it?  (i.e. do you want me to submit patches to the stable baseline?)


We would tag the patch for stable (and submit it into v4.16-rc). Greg would
take care of the rest unless there are conflicts, in which case we get a note
telling us that a backport is needed.

Guenter

Re: [PATCH RFC] riscv/barrier: Define __smp_{mb,rmb,wmb}

[Palmer Dabbelt]

On Mon, 26 Feb 2018 02:35:52 PST (-0800), parri.and...@gmail.com wrote:

On Thu, Feb 22, 2018 at 03:14:52PM -0800, Palmer Dabbelt wrote:

On Tue, 20 Feb 2018 02:17:28 PST (-0800), parri.and...@gmail.com wrote:
>Introduce __smp_{mb,rmb,wmb}, and rely on the generic definitions
>for smp_{mb,rmb,wmb}. A first consequence is that smp_{mb,rmb,wmb}
>map to a compiler barrier on !SMP (while their definition remains
>unchanged on SMP). As a further consequence, smp_load_acquire and
>smp_store_release have "fence rw,rw" instead of "fence iorw,iorw".
>
>Signed-off-by: Andrea Parri 
>---
> arch/riscv/include/asm/barrier.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/arch/riscv/include/asm/barrier.h 
b/arch/riscv/include/asm/barrier.h
>index c0319cbf1eec5..5510366d169ae 100644
>--- a/arch/riscv/include/asm/barrier.h
>+++ b/arch/riscv/include/asm/barrier.h
>@@ -34,9 +34,9 @@
> #define wmb()  RISCV_FENCE(ow,ow)
>
> /* These barriers do not need to enforce ordering on devices, just memory. */
>-#define smp_mb()   RISCV_FENCE(rw,rw)
>-#define smp_rmb()  RISCV_FENCE(r,r)
>-#define smp_wmb()  RISCV_FENCE(w,w)
>+#define __smp_mb() RISCV_FENCE(rw,rw)
>+#define __smp_rmb()RISCV_FENCE(r,r)
>+#define __smp_wmb()RISCV_FENCE(w,w)
>
> /*
>  * This is a very specific barrier: it's currently only used in two places in

Thanks!  I'm going to take this for the next RC.


Thank you, Palmer.  I'm planning to post more changes to the file,
but I'd like to build on top of this change: could you point me to
the appropriate branch/repo for this?


Here's the canonical RISC-V Linux git repo

   https://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git/

Your branch is now the HEAD of the "for-linus" branch, which means it'll be 
sent to Linus the next time I send patches.  I generate and tag "for-linus" on 
Monday mornings and then send it out on Wednesday mornings, just to make sure 
everything has time to bake.


   https://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git/

Additionally, I mantain a "for-next" branch that contains everything that's 
been sufficiently reviewed to be made part of Linux, but that is being staged 
for a bit longer than what's in for-linus for one reason or another (usually 
it's just not RC material and is targeted for the next merge window).  There is 
also a RISC-V integration branch named "riscv-all" that contains all our work 
in progress patches.  This is likely to be unstable, but it's best to check 
there to see if anything interesting is going on related to what you're working 
on to avoid duplicating work.


These branches are all generated from my personal git tree

   https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/

There's a bunch of branches in here tracking each change set (yours is called 
"fix-smp_mb", to indicate it can go in during an RC) that's still in flight.  
There's some scripts to generate some of these branches, but the commits I 
actually send upstream are merged by hand


   https://github.com/riscv/riscv-linux-infra

"for-next" and "riscv-all" are rebased regularly, so it's probably best to 
track commits back to their original WIP branch and work from there to avoid 
major headaches.

Re: [PATCH RFC] riscv/barrier: Define __smp_{mb,rmb,wmb}

[Palmer Dabbelt]

On Mon, 26 Feb 2018 02:35:52 PST (-0800), parri.and...@gmail.com wrote:

On Thu, Feb 22, 2018 at 03:14:52PM -0800, Palmer Dabbelt wrote:

On Tue, 20 Feb 2018 02:17:28 PST (-0800), parri.and...@gmail.com wrote:
>Introduce __smp_{mb,rmb,wmb}, and rely on the generic definitions
>for smp_{mb,rmb,wmb}. A first consequence is that smp_{mb,rmb,wmb}
>map to a compiler barrier on !SMP (while their definition remains
>unchanged on SMP). As a further consequence, smp_load_acquire and
>smp_store_release have "fence rw,rw" instead of "fence iorw,iorw".
>
>Signed-off-by: Andrea Parri 
>---
> arch/riscv/include/asm/barrier.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/arch/riscv/include/asm/barrier.h 
b/arch/riscv/include/asm/barrier.h
>index c0319cbf1eec5..5510366d169ae 100644
>--- a/arch/riscv/include/asm/barrier.h
>+++ b/arch/riscv/include/asm/barrier.h
>@@ -34,9 +34,9 @@
> #define wmb()  RISCV_FENCE(ow,ow)
>
> /* These barriers do not need to enforce ordering on devices, just memory. */
>-#define smp_mb()   RISCV_FENCE(rw,rw)
>-#define smp_rmb()  RISCV_FENCE(r,r)
>-#define smp_wmb()  RISCV_FENCE(w,w)
>+#define __smp_mb() RISCV_FENCE(rw,rw)
>+#define __smp_rmb()RISCV_FENCE(r,r)
>+#define __smp_wmb()RISCV_FENCE(w,w)
>
> /*
>  * This is a very specific barrier: it's currently only used in two places in

Thanks!  I'm going to take this for the next RC.


Thank you, Palmer.  I'm planning to post more changes to the file,
but I'd like to build on top of this change: could you point me to
the appropriate branch/repo for this?


Here's the canonical RISC-V Linux git repo

   https://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git/

Your branch is now the HEAD of the "for-linus" branch, which means it'll be 
sent to Linus the next time I send patches.  I generate and tag "for-linus" on 
Monday mornings and then send it out on Wednesday mornings, just to make sure 
everything has time to bake.


   https://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git/

Additionally, I mantain a "for-next" branch that contains everything that's 
been sufficiently reviewed to be made part of Linux, but that is being staged 
for a bit longer than what's in for-linus for one reason or another (usually 
it's just not RC material and is targeted for the next merge window).  There is 
also a RISC-V integration branch named "riscv-all" that contains all our work 
in progress patches.  This is likely to be unstable, but it's best to check 
there to see if anything interesting is going on related to what you're working 
on to avoid duplicating work.


These branches are all generated from my personal git tree

   https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/

There's a bunch of branches in here tracking each change set (yours is called 
"fix-smp_mb", to indicate it can go in during an RC) that's still in flight.  
There's some scripts to generate some of these branches, but the commits I 
actually send upstream are merged by hand


   https://github.com/riscv/riscv-linux-infra

"for-next" and "riscv-all" are rebased regularly, so it's probably best to 
track commits back to their original WIP branch and work from there to avoid 
major headaches.

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

[Yang Shi]

On 2/26/18 5:02 PM, David Rientjes wrote:

On Tue, 27 Feb 2018, Yang Shi wrote:


Background:
When running vm-scalability with large memory (> 300GB), the below hung
task issue happens occasionally.

INFO: task ps:14018 blocked for more than 120 seconds.
Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  ps  D0 14018  1 0x0004
   885582f84000 885e8682f000 880972943000 885ebf499bc0
   8828ee12 c900349bfca8 817154d0 0040
   00ff812f872a 885ebf499bc0 024000d000948300 880972943000
  Call Trace:
   [] ? __schedule+0x250/0x730
   [] schedule+0x36/0x80
   [] rwsem_down_read_failed+0xf0/0x150
   [] call_rwsem_down_read_failed+0x18/0x30
   [] down_read+0x20/0x40
   [] proc_pid_cmdline_read+0xd9/0x4e0
   [] ? do_filp_open+0xa5/0x100
   [] __vfs_read+0x37/0x150
   [] ? security_file_permission+0x9b/0xc0
   [] vfs_read+0x96/0x130
   [] SyS_read+0x55/0xc0
   [] entry_SYSCALL_64_fastpath+0x1a/0xc5

When manipulating a large mapping, the process may hold the mmap_sem for
long time, so reading /proc//cmdline may be blocked in
uninterruptible state for long time.
We already have killable version APIs for semaphore, here use 
down_read_killable()
to improve the responsiveness.


Rather than killable, we have patches that introduce down_read_unfair()
variants for the files you've modified (cmdline and environ) as well as
others (maps, numa_maps, smaps).


You mean you have such functionality used by google internally?



When another thread is holding down_read() and there are queued
down_write()'s, down_read_unfair() allows for grabbing the rwsem without
queueing for it.  Additionally, when another thread is holding
down_write(), down_read_unfair() allows for queueing in front of other
threads trying to grab it for write as well.


It sounds the __unfair variant make the caller have chance to jump the 
gun to grab the semaphore before other waiters, right? But when a 
process holds the semaphore, i.e. mmap_sem, for a long time, it still 
has to sleep in uninterruptible state, right?


But, it seems __unfair variant may not be very helpful in this usecase. 
Reading /proc might be not that important to require any special care to 
grab the semaphore before other waiters. I just hope it doesn't sleep in 
uninterruptible state for a long time. If the user is not patient enough 
due to some reason, they can have a chance to abort.




Ingo would know more about whether a variant like that in upstream Linux
would be acceptable.

Would you be interested in unfair variants instead of only addressing
killable?


Yes, I'm although it still looks overkilling to me for reading /proc.

Thanks,
Yang

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

[Yang Shi]

On 2/26/18 5:02 PM, David Rientjes wrote:

On Tue, 27 Feb 2018, Yang Shi wrote:


Background:
When running vm-scalability with large memory (> 300GB), the below hung
task issue happens occasionally.

INFO: task ps:14018 blocked for more than 120 seconds.
Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  ps  D0 14018  1 0x0004
   885582f84000 885e8682f000 880972943000 885ebf499bc0
   8828ee12 c900349bfca8 817154d0 0040
   00ff812f872a 885ebf499bc0 024000d000948300 880972943000
  Call Trace:
   [] ? __schedule+0x250/0x730
   [] schedule+0x36/0x80
   [] rwsem_down_read_failed+0xf0/0x150
   [] call_rwsem_down_read_failed+0x18/0x30
   [] down_read+0x20/0x40
   [] proc_pid_cmdline_read+0xd9/0x4e0
   [] ? do_filp_open+0xa5/0x100
   [] __vfs_read+0x37/0x150
   [] ? security_file_permission+0x9b/0xc0
   [] vfs_read+0x96/0x130
   [] SyS_read+0x55/0xc0
   [] entry_SYSCALL_64_fastpath+0x1a/0xc5

When manipulating a large mapping, the process may hold the mmap_sem for
long time, so reading /proc//cmdline may be blocked in
uninterruptible state for long time.
We already have killable version APIs for semaphore, here use 
down_read_killable()
to improve the responsiveness.


Rather than killable, we have patches that introduce down_read_unfair()
variants for the files you've modified (cmdline and environ) as well as
others (maps, numa_maps, smaps).


You mean you have such functionality used by google internally?



When another thread is holding down_read() and there are queued
down_write()'s, down_read_unfair() allows for grabbing the rwsem without
queueing for it.  Additionally, when another thread is holding
down_write(), down_read_unfair() allows for queueing in front of other
threads trying to grab it for write as well.


It sounds the __unfair variant make the caller have chance to jump the 
gun to grab the semaphore before other waiters, right? But when a 
process holds the semaphore, i.e. mmap_sem, for a long time, it still 
has to sleep in uninterruptible state, right?


But, it seems __unfair variant may not be very helpful in this usecase. 
Reading /proc might be not that important to require any special care to 
grab the semaphore before other waiters. I just hope it doesn't sleep in 
uninterruptible state for a long time. If the user is not patient enough 
due to some reason, they can have a chance to abort.




Ingo would know more about whether a variant like that in upstream Linux
would be acceptable.

Would you be interested in unfair variants instead of only addressing
killable?


Yes, I'm although it still looks overkilling to me for reading /proc.

Thanks,
Yang

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

[Al Viro]

On Tue, Feb 27, 2018 at 12:57:21AM +, Al Viro wrote:
> On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote:
> > The function current_nameidata_security(struct inode *) can be used to
> > retrieve a blob's pointer address tied to the inode being walk through.
> > This enable to follow a path lookup and know where an inode access come
> > from. This is needed for the Landlock LSM to be able to restrict access
> > to file path.
> > 
> > The LSM hook nameidata_free_security(struct inode *) is called before
> > freeing the associated nameidata.
> 
> NAK.  Not without well-defined semantics and "some Linux S uses that for
> something, don't ask what" does not count.

Incidentally, pathwalk mechanics is subject to change at zero notice, so
if you want something, you'd better
* have explicitly defined semantics
* explain what it is - on fsdevel
* not have it hidden behind the layers of opaque LSM dreck, pardon
the redundance.

Again, pathwalk internals have changed in the past and may bloody well
change again in the future.  There's a damn good reason why struct nameidata
is _not_ visible outside of fs/namei.c, and quietly relying upon any
implementation details is no-go.

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

[Al Viro]

On Tue, Feb 27, 2018 at 12:57:21AM +, Al Viro wrote:
> On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote:
> > The function current_nameidata_security(struct inode *) can be used to
> > retrieve a blob's pointer address tied to the inode being walk through.
> > This enable to follow a path lookup and know where an inode access come
> > from. This is needed for the Landlock LSM to be able to restrict access
> > to file path.
> > 
> > The LSM hook nameidata_free_security(struct inode *) is called before
> > freeing the associated nameidata.
> 
> NAK.  Not without well-defined semantics and "some Linux S uses that for
> something, don't ask what" does not count.

Incidentally, pathwalk mechanics is subject to change at zero notice, so
if you want something, you'd better
* have explicitly defined semantics
* explain what it is - on fsdevel
* not have it hidden behind the layers of opaque LSM dreck, pardon
the redundance.

Again, pathwalk internals have changed in the past and may bloody well
change again in the future.  There's a damn good reason why struct nameidata
is _not_ visible outside of fs/namei.c, and quietly relying upon any
implementation details is no-go.

Re: [PATCH v2] KVM: X86: Allow userspace to define the microcode version

[Wanpeng Li]

2018-02-26 19:42 GMT+08:00 Paolo Bonzini :
> On 26/02/2018 11:17, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> Linux (among the others) has checks to make sure that certain features
>> aren't enabled on a certain family/model/stepping if the microcode version
>> isn't greater than or equal to a known good version.
>>
>> By exposing the real microcode version, we're preventing buggy guests that
>> don't check that they are running virtualized (i.e., they should trust the
>> hypervisor) from disabling features that are effectively not buggy.
>>
>> Suggested-by: Filippo Sironi 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Liran Alon 
>> Signed-off-by: Wanpeng Li 
>> ---
>> v1 -> v2:
>>  * add MSR_IA32_UCODE_REV to emulated_msrs
>>
>>  arch/x86/include/asm/kvm_host.h | 1 +
>>  arch/x86/kvm/x86.c  | 9 +++--
>>  2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h 
>> b/arch/x86/include/asm/kvm_host.h
>> index 938d453..6e13f2f 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
>>   u64 smi_count;
>>   bool tpr_access_reporting;
>>   u64 ia32_xss;
>> + u32 microcode_version;
>>
>>   /*
>>* Paging state of the vcpu
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 1a3ed81..4ae9517 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1047,6 +1047,7 @@ static u32 emulated_msrs[] = {
>>   MSR_SMI_COUNT,
>>   MSR_PLATFORM_INFO,
>>   MSR_MISC_FEATURES_ENABLES,
>> + MSR_IA32_UCODE_REV,
>>  };
>>
>>  static unsigned num_emulated_msrs;
>> @@ -2247,7 +2248,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>
>>   switch (msr) {
>>   case MSR_AMD64_NB_CFG:
>> - case MSR_IA32_UCODE_REV:
>>   case MSR_IA32_UCODE_WRITE:
>>   case MSR_VM_HSAVE_PA:
>>   case MSR_AMD64_PATCH_LOADER:
>> @@ -2255,6 +2255,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>   case MSR_AMD64_DC_CFG:
>>   break;
>>
>> + case MSR_IA32_UCODE_REV:
>> + if (msr_info->host_initiated)
>> + vcpu->arch.microcode_version = data >> 32;
>
> Please remove the shifts, and add the MSR_IA32_UCODE_REV version to the
> "feature MSRs" recently added by Tom Lendacky.

Do it in v3, thanks for the review. :)

Regards,
Wanpeng Li

>
> Thanks,
>
> Paolo
>
>> + break;
>>   case MSR_EFER:
>>   return set_efer(vcpu, data);
>>   case MSR_K7_HWCR:
>> @@ -2550,7 +2554,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>   msr_info->data = 0;
>>   break;
>>   case MSR_IA32_UCODE_REV:
>> - msr_info->data = 0x1ULL;
>> + msr_info->data = (u64)vcpu->arch.microcode_version << 32;
>>   break;
>>   case MSR_MTRRcap:
>>   case 0x200 ... 0x2ff:
>> @@ -8232,6 +8236,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
>> init_event)
>>   vcpu->arch.regs_dirty = ~0;
>>
>>   vcpu->arch.ia32_xss = 0;
>> + vcpu->arch.microcode_version = 0x1;
>>
>>   kvm_x86_ops->vcpu_reset(vcpu, init_event);
>>  }
>>
>

Re: [PATCH v2] KVM: X86: Allow userspace to define the microcode version

[Wanpeng Li]

2018-02-26 19:42 GMT+08:00 Paolo Bonzini :
> On 26/02/2018 11:17, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> Linux (among the others) has checks to make sure that certain features
>> aren't enabled on a certain family/model/stepping if the microcode version
>> isn't greater than or equal to a known good version.
>>
>> By exposing the real microcode version, we're preventing buggy guests that
>> don't check that they are running virtualized (i.e., they should trust the
>> hypervisor) from disabling features that are effectively not buggy.
>>
>> Suggested-by: Filippo Sironi 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Liran Alon 
>> Signed-off-by: Wanpeng Li 
>> ---
>> v1 -> v2:
>>  * add MSR_IA32_UCODE_REV to emulated_msrs
>>
>>  arch/x86/include/asm/kvm_host.h | 1 +
>>  arch/x86/kvm/x86.c  | 9 +++--
>>  2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h 
>> b/arch/x86/include/asm/kvm_host.h
>> index 938d453..6e13f2f 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
>>   u64 smi_count;
>>   bool tpr_access_reporting;
>>   u64 ia32_xss;
>> + u32 microcode_version;
>>
>>   /*
>>* Paging state of the vcpu
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 1a3ed81..4ae9517 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1047,6 +1047,7 @@ static u32 emulated_msrs[] = {
>>   MSR_SMI_COUNT,
>>   MSR_PLATFORM_INFO,
>>   MSR_MISC_FEATURES_ENABLES,
>> + MSR_IA32_UCODE_REV,
>>  };
>>
>>  static unsigned num_emulated_msrs;
>> @@ -2247,7 +2248,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>
>>   switch (msr) {
>>   case MSR_AMD64_NB_CFG:
>> - case MSR_IA32_UCODE_REV:
>>   case MSR_IA32_UCODE_WRITE:
>>   case MSR_VM_HSAVE_PA:
>>   case MSR_AMD64_PATCH_LOADER:
>> @@ -2255,6 +2255,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>   case MSR_AMD64_DC_CFG:
>>   break;
>>
>> + case MSR_IA32_UCODE_REV:
>> + if (msr_info->host_initiated)
>> + vcpu->arch.microcode_version = data >> 32;
>
> Please remove the shifts, and add the MSR_IA32_UCODE_REV version to the
> "feature MSRs" recently added by Tom Lendacky.

Do it in v3, thanks for the review. :)

Regards,
Wanpeng Li

>
> Thanks,
>
> Paolo
>
>> + break;
>>   case MSR_EFER:
>>   return set_efer(vcpu, data);
>>   case MSR_K7_HWCR:
>> @@ -2550,7 +2554,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
>> msr_data *msr_info)
>>   msr_info->data = 0;
>>   break;
>>   case MSR_IA32_UCODE_REV:
>> - msr_info->data = 0x1ULL;
>> + msr_info->data = (u64)vcpu->arch.microcode_version << 32;
>>   break;
>>   case MSR_MTRRcap:
>>   case 0x200 ... 0x2ff:
>> @@ -8232,6 +8236,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
>> init_event)
>>   vcpu->arch.regs_dirty = ~0;
>>
>>   vcpu->arch.ia32_xss = 0;
>> + vcpu->arch.microcode_version = 0x1;
>>
>>   kvm_x86_ops->vcpu_reset(vcpu, init_event);
>>  }
>>
>

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

[Yong]

Hi,

On Mon, 26 Feb 2018 12:06:37 +0100
Hans Verkuil  wrote:

> Hi all,
> 
> On 01/30/2018 03:48 AM, Yong wrote:
> > Hi,
> > 
> > On Mon, 29 Jan 2018 13:49:14 -0800
> > Randy Dunlap  wrote:
> > 
> >> On 01/29/2018 01:21 AM, Yong Deng wrote:
> >>> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> >>> interface and CSI1 is used for parallel interface. This is not
> >>> documented in datasheet but by test and guess.
> >>>
> >>> This patch implement a v4l2 framework driver for it.
> >>>
> >>> Currently, the driver only support the parallel interface. MIPI-CSI2,
> >>> ISP's support are not included in this patch.
> >>>
> >>> Tested-by: Maxime Ripard 
> >>> Signed-off-by: Yong Deng 
> >>> ---
> >>
> >>
> >> A previous version (I think v6) had a build error with the use of
> >> PHYS_OFFSET, so Kconfig was modified to depend on ARM and ARCH_SUNXI
> >> (one of which seems to be overkill).  As is here, the COMPILE_TEST piece is
> >> meaningless for all arches except ARM.  If you care enough for COMPILE_TEST
> >> (and I would), then you could make COMPILE_TEST useful on any arch by
> >> removing the "depends on ARM" (the ARCH_SUNXI takes care of that) and by
> >> having an alternate value for PHYS_OFFSET, like so:
> >>
> >> +#if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
> >> +#define PHYS_OFFSET   0
> >> +#endif
> >>
> >> With those 2 changes, the driver builds for me on x86_64.
> > 
> > I have considered this method.
> > But it's so sick to put these code in dirver (for my own). I mean 
> > this is meaningless for the driver itself and make people confused.
> > 
> > I grepped the driver/ code and I found many drivers writing Kconfig
> > like this. For example:
> > ARM && COMPILE_TEST
> > MIPS && COMPILE_TEST
> > PPC64 && COMPILE_TEST
> > 
> > BTW, for my own, I do not care about COMPILE_TEST.
> 
> There was a discussion about this in the v6 patch, but it petered out.
> 
> I want to merge this driver, but I would very much prefer that this
> compiles with COMPILE_TEST. So unless someone has a better solution, then
> adding 'hack' that defines PHYS_OFFSET to 0 for COMPILE_TEST would be 
> required.

If so, I will take the advice of Randy.

> 
> Otherwise this driver looks good, so it is just this issue blocking it.
> 
> Regards,
> 
>   Hans
> 
> > 
> >>
> >>> diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
> >>> b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> >>> new file mode 100644
> >>> index 000..f80c965
> >>> --- /dev/null
> >>> +++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> >>> @@ -0,0 +1,10 @@
> >>> +config VIDEO_SUN6I_CSI
> >>> + tristate "Allwinner V3s Camera Sensor Interface driver"
> >>> + depends on ARM
> >>> + depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> >>> + depends on ARCH_SUNXI || COMPILE_TEST
> >>> + select VIDEOBUF2_DMA_CONTIG
> >>> + select REGMAP_MMIO
> >>> + select V4L2_FWNODE
> >>> + ---help---
> >>> +Support for the Allwinner Camera Sensor Interface Controller on V3s.
> >>
> >> thanks,
> >> -- 
> >> ~Randy
> > 
> > 
> > Thanks,
> > Yong
> > 


Thanks,
Yong

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

[Yong]

Hi,

On Mon, 26 Feb 2018 12:06:37 +0100
Hans Verkuil  wrote:

> Hi all,
> 
> On 01/30/2018 03:48 AM, Yong wrote:
> > Hi,
> > 
> > On Mon, 29 Jan 2018 13:49:14 -0800
> > Randy Dunlap  wrote:
> > 
> >> On 01/29/2018 01:21 AM, Yong Deng wrote:
> >>> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> >>> interface and CSI1 is used for parallel interface. This is not
> >>> documented in datasheet but by test and guess.
> >>>
> >>> This patch implement a v4l2 framework driver for it.
> >>>
> >>> Currently, the driver only support the parallel interface. MIPI-CSI2,
> >>> ISP's support are not included in this patch.
> >>>
> >>> Tested-by: Maxime Ripard 
> >>> Signed-off-by: Yong Deng 
> >>> ---
> >>
> >>
> >> A previous version (I think v6) had a build error with the use of
> >> PHYS_OFFSET, so Kconfig was modified to depend on ARM and ARCH_SUNXI
> >> (one of which seems to be overkill).  As is here, the COMPILE_TEST piece is
> >> meaningless for all arches except ARM.  If you care enough for COMPILE_TEST
> >> (and I would), then you could make COMPILE_TEST useful on any arch by
> >> removing the "depends on ARM" (the ARCH_SUNXI takes care of that) and by
> >> having an alternate value for PHYS_OFFSET, like so:
> >>
> >> +#if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
> >> +#define PHYS_OFFSET   0
> >> +#endif
> >>
> >> With those 2 changes, the driver builds for me on x86_64.
> > 
> > I have considered this method.
> > But it's so sick to put these code in dirver (for my own). I mean 
> > this is meaningless for the driver itself and make people confused.
> > 
> > I grepped the driver/ code and I found many drivers writing Kconfig
> > like this. For example:
> > ARM && COMPILE_TEST
> > MIPS && COMPILE_TEST
> > PPC64 && COMPILE_TEST
> > 
> > BTW, for my own, I do not care about COMPILE_TEST.
> 
> There was a discussion about this in the v6 patch, but it petered out.
> 
> I want to merge this driver, but I would very much prefer that this
> compiles with COMPILE_TEST. So unless someone has a better solution, then
> adding 'hack' that defines PHYS_OFFSET to 0 for COMPILE_TEST would be 
> required.

If so, I will take the advice of Randy.

> 
> Otherwise this driver looks good, so it is just this issue blocking it.
> 
> Regards,
> 
>   Hans
> 
> > 
> >>
> >>> diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
> >>> b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> >>> new file mode 100644
> >>> index 000..f80c965
> >>> --- /dev/null
> >>> +++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> >>> @@ -0,0 +1,10 @@
> >>> +config VIDEO_SUN6I_CSI
> >>> + tristate "Allwinner V3s Camera Sensor Interface driver"
> >>> + depends on ARM
> >>> + depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> >>> + depends on ARCH_SUNXI || COMPILE_TEST
> >>> + select VIDEOBUF2_DMA_CONTIG
> >>> + select REGMAP_MMIO
> >>> + select V4L2_FWNODE
> >>> + ---help---
> >>> +Support for the Allwinner Camera Sensor Interface Controller on V3s.
> >>
> >> thanks,
> >> -- 
> >> ~Randy
> > 
> > 
> > Thanks,
> > Yong
> > 


Thanks,
Yong

[PATCH v3] KVM: X86: Allow userspace to define the microcode version

[Wanpeng Li]

From: Wanpeng Li 

Linux (among the others) has checks to make sure that certain features 
aren't enabled on a certain family/model/stepping if the microcode version 
isn't greater than or equal to a known good version.

By exposing the real microcode version, we're preventing buggy guests that
don't check that they are running virtualized (i.e., they should trust the
hypervisor) from disabling features that are effectively not buggy.

Suggested-by: Filippo Sironi 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Liran Alon 
Signed-off-by: Wanpeng Li 
---
v2 -> v3:
 * remove the shifts
 * add the MSR_IA32_UCODE_REV version to the "feature MSRs"
v1 -> v2:
 * add MSR_IA32_UCODE_REV to emulated_msrs

 arch/x86/include/asm/kvm_host.h |  1 +
 arch/x86/kvm/x86.c  | 19 +++
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 938d453..6e13f2f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
u64 smi_count;
bool tpr_access_reporting;
u64 ia32_xss;
+   u32 microcode_version;
 
/*
 * Paging state of the vcpu
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d4985a9..00af28e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1058,6 +1058,7 @@ static unsigned num_emulated_msrs;
 static u32 msr_based_features[] = {
MSR_IA32_ARCH_CAPABILITIES,
MSR_F10H_DECFG,
+   MSR_IA32_UCODE_REV,
 };
 
 static unsigned int num_msr_based_features;
@@ -1067,8 +1068,14 @@ static int do_get_msr_feature(struct kvm_vcpu *vcpu, 
unsigned index, u64 *data)
struct kvm_msr_entry msr;
 
msr.index = index;
-   if (kvm_x86_ops->get_msr_feature())
-   return 1;
+   switch (msr.index) {
+   case MSR_IA32_UCODE_REV:
+   rdmsrl(msr.index, msr.data);
+   break;
+   default:
+   if (kvm_x86_ops->get_msr_feature())
+   return 1;
+   }
 
*data = msr.data;
 
@@ -2248,7 +2255,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
 
switch (msr) {
case MSR_AMD64_NB_CFG:
-   case MSR_IA32_UCODE_REV:
case MSR_IA32_UCODE_WRITE:
case MSR_VM_HSAVE_PA:
case MSR_AMD64_PATCH_LOADER:
@@ -2256,6 +2262,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
case MSR_AMD64_DC_CFG:
break;
 
+   case MSR_IA32_UCODE_REV:
+   if (msr_info->host_initiated)
+   vcpu->arch.microcode_version = data;
+   break;
case MSR_EFER:
return set_efer(vcpu, data);
case MSR_K7_HWCR:
@@ -2551,7 +2561,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
msr_info->data = 0;
break;
case MSR_IA32_UCODE_REV:
-   msr_info->data = 0x1ULL;
+   msr_info->data = (u64)vcpu->arch.microcode_version;
break;
case MSR_MTRRcap:
case 0x200 ... 0x2ff:
@@ -8233,6 +8243,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
init_event)
vcpu->arch.regs_dirty = ~0;
 
vcpu->arch.ia32_xss = 0;
+   vcpu->arch.microcode_version = 0x1;
 
kvm_x86_ops->vcpu_reset(vcpu, init_event);
 }
-- 
2.7.4

[PATCH v3] KVM: X86: Allow userspace to define the microcode version

[Wanpeng Li]

From: Wanpeng Li 

Linux (among the others) has checks to make sure that certain features 
aren't enabled on a certain family/model/stepping if the microcode version 
isn't greater than or equal to a known good version.

By exposing the real microcode version, we're preventing buggy guests that
don't check that they are running virtualized (i.e., they should trust the
hypervisor) from disabling features that are effectively not buggy.

Suggested-by: Filippo Sironi 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Liran Alon 
Signed-off-by: Wanpeng Li 
---
v2 -> v3:
 * remove the shifts
 * add the MSR_IA32_UCODE_REV version to the "feature MSRs"
v1 -> v2:
 * add MSR_IA32_UCODE_REV to emulated_msrs

 arch/x86/include/asm/kvm_host.h |  1 +
 arch/x86/kvm/x86.c  | 19 +++
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 938d453..6e13f2f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
u64 smi_count;
bool tpr_access_reporting;
u64 ia32_xss;
+   u32 microcode_version;
 
/*
 * Paging state of the vcpu
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d4985a9..00af28e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1058,6 +1058,7 @@ static unsigned num_emulated_msrs;
 static u32 msr_based_features[] = {
MSR_IA32_ARCH_CAPABILITIES,
MSR_F10H_DECFG,
+   MSR_IA32_UCODE_REV,
 };
 
 static unsigned int num_msr_based_features;
@@ -1067,8 +1068,14 @@ static int do_get_msr_feature(struct kvm_vcpu *vcpu, 
unsigned index, u64 *data)
struct kvm_msr_entry msr;
 
msr.index = index;
-   if (kvm_x86_ops->get_msr_feature())
-   return 1;
+   switch (msr.index) {
+   case MSR_IA32_UCODE_REV:
+   rdmsrl(msr.index, msr.data);
+   break;
+   default:
+   if (kvm_x86_ops->get_msr_feature())
+   return 1;
+   }
 
*data = msr.data;
 
@@ -2248,7 +2255,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
 
switch (msr) {
case MSR_AMD64_NB_CFG:
-   case MSR_IA32_UCODE_REV:
case MSR_IA32_UCODE_WRITE:
case MSR_VM_HSAVE_PA:
case MSR_AMD64_PATCH_LOADER:
@@ -2256,6 +2262,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
case MSR_AMD64_DC_CFG:
break;
 
+   case MSR_IA32_UCODE_REV:
+   if (msr_info->host_initiated)
+   vcpu->arch.microcode_version = data;
+   break;
case MSR_EFER:
return set_efer(vcpu, data);
case MSR_K7_HWCR:
@@ -2551,7 +2561,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
msr_info->data = 0;
break;
case MSR_IA32_UCODE_REV:
-   msr_info->data = 0x1ULL;
+   msr_info->data = (u64)vcpu->arch.microcode_version;
break;
case MSR_MTRRcap:
case 0x200 ... 0x2ff:
@@ -8233,6 +8243,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
init_event)
vcpu->arch.regs_dirty = ~0;
 
vcpu->arch.ia32_xss = 0;
+   vcpu->arch.microcode_version = 0x1;
 
kvm_x86_ops->vcpu_reset(vcpu, init_event);
 }
-- 
2.7.4

Re: [PATCH 1/2 v3] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

[Shawn Lin]

Tested-by: Vineet Gupta 
Fixes: ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files

Signed-off-by: Evgeniy Didin 

CC: Alexey Brodkin 
CC: Eugeniy Paltsev 
CC: Douglas Anderson 
CC: Ulf Hansson 
CC: linux-kernel@vger.kernel.org
CC: linux-snps-...@lists.infradead.org
Cc:  #  9d9491a7da2a mmc: dw_mmc: Fix the DTO timeout 
calculation


As I said, the correct tag may be:

Reported-by: Vineet Gupta  # ARC STAR 
9001306872 HSDK, sdio: board crashes when copying big files

Tested-by: Vineet Gupta 
Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
Cc: 
Signed-off-by: Evgeniy Didin 
...
...



---
Nothing changed since v2.
  drivers/mmc/host/dw_mmc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)




-   drto_ms = DIV_ROUND_UP(MSEC_PER_SEC * drto_clks * drto_div,
+
+   drto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * drto_clks * drto_div,
   host->bus_hz);
  


Hmm?

#define DIV_ROUND_DOWN_ULL(ll, d) \
({ unsigned long long _tmp = (ll); do_div(_tmp, d); _tmp; })

#define DIV_ROUND_UP_ULL(ll, d) DIV_ROUND_DOWN_ULL((ll) + (d) - 1, (d))


It uses intermediate unsigned long long _tmp for your "multiply", namely
MSEC_PER_SEC * drto_clks * drto_div, which could solves the problem.
So I don't see why DIV_ROUND_UP_ULL can't work for you?



/* add a bit spare time */

Re: [PATCH 1/2 v3] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

[Shawn Lin]

Tested-by: Vineet Gupta 
Fixes: ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files

Signed-off-by: Evgeniy Didin 

CC: Alexey Brodkin 
CC: Eugeniy Paltsev 
CC: Douglas Anderson 
CC: Ulf Hansson 
CC: linux-kernel@vger.kernel.org
CC: linux-snps-...@lists.infradead.org
Cc:  #  9d9491a7da2a mmc: dw_mmc: Fix the DTO timeout 
calculation


As I said, the correct tag may be:

Reported-by: Vineet Gupta  # ARC STAR 
9001306872 HSDK, sdio: board crashes when copying big files

Tested-by: Vineet Gupta 
Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
Cc: 
Signed-off-by: Evgeniy Didin 
...
...



---
Nothing changed since v2.
  drivers/mmc/host/dw_mmc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)




-   drto_ms = DIV_ROUND_UP(MSEC_PER_SEC * drto_clks * drto_div,
+
+   drto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * drto_clks * drto_div,
   host->bus_hz);
  


Hmm?

#define DIV_ROUND_DOWN_ULL(ll, d) \
({ unsigned long long _tmp = (ll); do_div(_tmp, d); _tmp; })

#define DIV_ROUND_UP_ULL(ll, d) DIV_ROUND_DOWN_ULL((ll) + (d) - 1, (d))


It uses intermediate unsigned long long _tmp for your "multiply", namely
MSEC_PER_SEC * drto_clks * drto_div, which could solves the problem.
So I don't see why DIV_ROUND_UP_ULL can't work for you?



/* add a bit spare time */

[GIT PULL] seccomp update for v4.16-rc4

[Kees Cook]

Hi James,

Please pull this seccomp change for v4.16-rc4. This disables the seccomp
samples when cross compiling. We're seen too many build issues here, so
it's best to just disable it, especially since they're just the samples.

Thanks!

-Kees

The following changes since commit d057dc4e35e16050befa3dda943876dab39cbf80:

  seccomp: add a selftest for get_metadata (2018-02-21 16:56:03 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/seccomp-v4.16-rc4

for you to fetch changes up to 6275ecbcd3ae3aaf47c3bc1e46343a50f16b2577:

  samples/seccomp: do not compile when cross compiled (2018-02-22 09:31:43 
-0800)


- do not build samples when cross compiling (Michal Hocko)


Michal Hocko (1):
  samples/seccomp: do not compile when cross compiled

 samples/seccomp/Makefile | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

-- 
Kees Cook
Pixel Security

Re: [PATCH v7 3/7] fs/posix_acl: Document that get_acl respects ACL_DONT_CACHE

[Linus Torvalds]

On Mon, Feb 26, 2018 at 3:52 PM, Eric W. Biederman
 wrote:
>
> Additionaly update the comment above the call to get_acl itself and
> remove the wrong information that an implementation of get_acl can
> prevent caching by calling forget_cached_acl.

This part is just confusing.

First off, that comment is correct: a filesystem _can_ prevent the
returning of cached data by just calling forget_cached_acl().

Note that there are two different cases: saying that you _never_ want
to cache things (ACL_DONT_CACHE) and saying that there _currently_ is
no cached data (ACL_NOT_CACHED).

forget_cached_acl() just removes the current cache.

You're just replacing one case of "no cached" information with the other.

Just explain the two cases, don't try to muddy the waters even more..

PLUS you are just confusing things entirely. That whole new comment of yours:

+* ACL_DONT_CACHE is treated as another task updating the acl and
+* remains set.

is just garbage.

The code is very clear - it will only replace a ACL_NOT_CACHED entry.
The code is clear:

if (cmpxchg(p, ACL_NOT_CACHED, sentinel) != ACL_NOT_CACHED)
/* fall through */ ;

this is basically just an atomic "if *p == ACL_NOT_CACHED then replace
it with 'sentinel'".

Your comment does not add any clarity at all, and only confuses
things. It has nothing to do with "treated as another task updating
the acl".

The fact is, ACL_DONT_CACHE is treated as if the cache is simply
already filled - it's just filled with "no cache".

So the only thing special is ACL_NOT_CACHED, which is the only thing
we will try to _replace_.

So NAK on this patch entirely. It's just adding confusion, not adding
clarifications.

Linus

[GIT PULL] seccomp update for v4.16-rc4

[Kees Cook]

Hi James,

Please pull this seccomp change for v4.16-rc4. This disables the seccomp
samples when cross compiling. We're seen too many build issues here, so
it's best to just disable it, especially since they're just the samples.

Thanks!

-Kees

The following changes since commit d057dc4e35e16050befa3dda943876dab39cbf80:

  seccomp: add a selftest for get_metadata (2018-02-21 16:56:03 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/seccomp-v4.16-rc4

for you to fetch changes up to 6275ecbcd3ae3aaf47c3bc1e46343a50f16b2577:

  samples/seccomp: do not compile when cross compiled (2018-02-22 09:31:43 
-0800)


- do not build samples when cross compiling (Michal Hocko)


Michal Hocko (1):
  samples/seccomp: do not compile when cross compiled

 samples/seccomp/Makefile | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

-- 
Kees Cook
Pixel Security

Re: [PATCH v7 3/7] fs/posix_acl: Document that get_acl respects ACL_DONT_CACHE

[Linus Torvalds]

On Mon, Feb 26, 2018 at 3:52 PM, Eric W. Biederman
 wrote:
>
> Additionaly update the comment above the call to get_acl itself and
> remove the wrong information that an implementation of get_acl can
> prevent caching by calling forget_cached_acl.

This part is just confusing.

First off, that comment is correct: a filesystem _can_ prevent the
returning of cached data by just calling forget_cached_acl().

Note that there are two different cases: saying that you _never_ want
to cache things (ACL_DONT_CACHE) and saying that there _currently_ is
no cached data (ACL_NOT_CACHED).

forget_cached_acl() just removes the current cache.

You're just replacing one case of "no cached" information with the other.

Just explain the two cases, don't try to muddy the waters even more..

PLUS you are just confusing things entirely. That whole new comment of yours:

+* ACL_DONT_CACHE is treated as another task updating the acl and
+* remains set.

is just garbage.

The code is very clear - it will only replace a ACL_NOT_CACHED entry.
The code is clear:

if (cmpxchg(p, ACL_NOT_CACHED, sentinel) != ACL_NOT_CACHED)
/* fall through */ ;

this is basically just an atomic "if *p == ACL_NOT_CACHED then replace
it with 'sentinel'".

Your comment does not add any clarity at all, and only confuses
things. It has nothing to do with "treated as another task updating
the acl".

The fact is, ACL_DONT_CACHE is treated as if the cache is simply
already filled - it's just filled with "no cache".

So the only thing special is ACL_NOT_CACHED, which is the only thing
we will try to _replace_.

So NAK on this patch entirely. It's just adding confusion, not adding
clarifications.

Linus

Re: [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU

[Shawn Guo]

On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote:
> Hi Shawn,
> 
> On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote:
> > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote:
> > > On i.MX53 it is necessary to set the DBG_EN bit in the
> > > platform GPC register to enable access to PMU counters
> > > other than the cycle counter.
> > > 
> > > Signed-off-by: Sebastian Reichel 
> > > ---
> > >  arch/arm/mach-imx/mach-imx53.c | 39 
> > > ++-
> > >  1 file changed, 38 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/mach-imx/mach-imx53.c 
> > > b/arch/arm/mach-imx/mach-imx53.c
> > > index 07c2e8dca494..658e28604dca 100644
> > > --- a/arch/arm/mach-imx/mach-imx53.c
> > > +++ b/arch/arm/mach-imx/mach-imx53.c
> > > @@ -28,10 +28,47 @@ static void __init imx53_init_early(void)
> > >   mxc_set_cpu_type(MXC_CPU_MX53);
> > >  }
> > >  
> > > +#define MXC_CORTEXA8_PLAT_GPC 0x63fa0004
> > 
> > The base address should be retrieved from device tree.
> 
> DT has no entry for 0x63fa-0x63fa3fff. iMX53 TRM lists it as "ARM 
> Platform"
> with 8 platform specific 32 bit registers. Do you think it's worth the trouble
> adding a new binding? Do you have a suggestion for a compatible value?

Looking at it more closely, I feel that patching every single platform
which needs to set up additional register for secure-reg-access support
doesn't really scale.  Can we have pmu driver do it with a phandle in
DT pointing to the register and bit that need to be configured?

Shawn

> > > +#define GPC_DBG_EN BIT(16)
> > > +
> > > +/*
> > > + * This enables the DBGEN bit in ARM_GPC register, which is
> > > + * required for accessing some performance counter features.
> > > + * Technically it is only required while perf is used, but to
> > > + * keep the source code simple we just enable it all the time
> > > + * when the kernel configuration allows using the feature.
> > > + */
> > > +static void imx53_pmu_init(void)
> > > +{
> > > + void __iomem *gpc_reg;
> > > + struct device_node *node;
> > > + u32 gpc;
> > > +
> > > + if (!IS_ENABLED(CONFIG_ARM_PMU))
> > > + return;
> > > +
> > > + node = of_find_compatible_node(NULL, NULL, "arm,cortex-a8-pmu");
> > > + if (!node)
> > > + return;
> > > +
> > > + if (!of_property_read_bool(node, "secure-reg-access"))
> > > + return;
> > > +
> > > + gpc_reg = ioremap(MXC_CORTEXA8_PLAT_GPC, 4);
> > > + if (!gpc_reg) {
> > > + pr_warning("unable to map GPC to enable perf\n");
> > > + return;
> > > + }
> > > +
> > > + gpc = readl_relaxed(gpc_reg);
> > > + gpc |= GPC_DBG_EN;
> > > + writel_relaxed(gpc, gpc_reg);
> > > +}
> > > +
> > >  static void __init imx53_dt_init(void)
> > >  {
> > >   imx_src_init();
> > > -
> > > + imx53_pmu_init();
> > >   imx_aips_allow_unprivileged_access("fsl,imx53-aipstz");
> > >  }
> > >  
> > > -- 
> > > 2.15.1
> > > 

Re: [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU

[Shawn Guo]

On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote:
> Hi Shawn,
> 
> On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote:
> > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote:
> > > On i.MX53 it is necessary to set the DBG_EN bit in the
> > > platform GPC register to enable access to PMU counters
> > > other than the cycle counter.
> > > 
> > > Signed-off-by: Sebastian Reichel 
> > > ---
> > >  arch/arm/mach-imx/mach-imx53.c | 39 
> > > ++-
> > >  1 file changed, 38 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/mach-imx/mach-imx53.c 
> > > b/arch/arm/mach-imx/mach-imx53.c
> > > index 07c2e8dca494..658e28604dca 100644
> > > --- a/arch/arm/mach-imx/mach-imx53.c
> > > +++ b/arch/arm/mach-imx/mach-imx53.c
> > > @@ -28,10 +28,47 @@ static void __init imx53_init_early(void)
> > >   mxc_set_cpu_type(MXC_CPU_MX53);
> > >  }
> > >  
> > > +#define MXC_CORTEXA8_PLAT_GPC 0x63fa0004
> > 
> > The base address should be retrieved from device tree.
> 
> DT has no entry for 0x63fa-0x63fa3fff. iMX53 TRM lists it as "ARM 
> Platform"
> with 8 platform specific 32 bit registers. Do you think it's worth the trouble
> adding a new binding? Do you have a suggestion for a compatible value?

Looking at it more closely, I feel that patching every single platform
which needs to set up additional register for secure-reg-access support
doesn't really scale.  Can we have pmu driver do it with a phandle in
DT pointing to the register and bit that need to be configured?

Shawn

> > > +#define GPC_DBG_EN BIT(16)
> > > +
> > > +/*
> > > + * This enables the DBGEN bit in ARM_GPC register, which is
> > > + * required for accessing some performance counter features.
> > > + * Technically it is only required while perf is used, but to
> > > + * keep the source code simple we just enable it all the time
> > > + * when the kernel configuration allows using the feature.
> > > + */
> > > +static void imx53_pmu_init(void)
> > > +{
> > > + void __iomem *gpc_reg;
> > > + struct device_node *node;
> > > + u32 gpc;
> > > +
> > > + if (!IS_ENABLED(CONFIG_ARM_PMU))
> > > + return;
> > > +
> > > + node = of_find_compatible_node(NULL, NULL, "arm,cortex-a8-pmu");
> > > + if (!node)
> > > + return;
> > > +
> > > + if (!of_property_read_bool(node, "secure-reg-access"))
> > > + return;
> > > +
> > > + gpc_reg = ioremap(MXC_CORTEXA8_PLAT_GPC, 4);
> > > + if (!gpc_reg) {
> > > + pr_warning("unable to map GPC to enable perf\n");
> > > + return;
> > > + }
> > > +
> > > + gpc = readl_relaxed(gpc_reg);
> > > + gpc |= GPC_DBG_EN;
> > > + writel_relaxed(gpc, gpc_reg);
> > > +}
> > > +
> > >  static void __init imx53_dt_init(void)
> > >  {
> > >   imx_src_init();
> > > -
> > > + imx53_pmu_init();
> > >   imx_aips_allow_unprivileged_access("fsl,imx53-aipstz");
> > >  }
> > >  
> > > -- 
> > > 2.15.1
> > > 

Re: [PATCH] ipmi: Add or fix SPDX-License-Identifier in all files

[Joel Stanley]

On Tue, Feb 27, 2018 at 1:54 AM,   wrote:
> From: Corey Minyard 
>
> And get rid of the license text that is no longer necessary.
>
> Signed-off-by: Corey Minyard 
> Cc: Kees Cook 
> Cc: Alistair Popple 
> Cc: Jeremy Kerr 
> Cc: Joel Stanley 
> Cc: Rocky Craig 
> ---
>
> Just a cleanup of these things.
>
>  drivers/char/ipmi/bt-bmc.c   |  6 +-
>  drivers/char/ipmi/ipmi_bt_sm.c   | 22 ++
>  drivers/char/ipmi/ipmi_devintf.c | 22 +-
>  drivers/char/ipmi/ipmi_kcs_sm.c  | 22 +-
>  drivers/char/ipmi/ipmi_msghandler.c  | 22 +-
>  drivers/char/ipmi/ipmi_powernv.c |  6 +-
>  drivers/char/ipmi/ipmi_poweroff.c| 22 +-
>  drivers/char/ipmi/ipmi_si.h  |  1 +
>  drivers/char/ipmi/ipmi_si_hardcode.c |  1 +
>  drivers/char/ipmi/ipmi_si_hotmod.c   |  1 +
>  drivers/char/ipmi/ipmi_si_intf.c | 22 +-
>  drivers/char/ipmi/ipmi_si_mem_io.c   |  1 +
>  drivers/char/ipmi/ipmi_si_parisc.c   |  1 +
>  drivers/char/ipmi/ipmi_si_pci.c  |  1 +
>  drivers/char/ipmi/ipmi_si_platform.c |  1 +
>  drivers/char/ipmi/ipmi_si_port_io.c  |  1 +
>  drivers/char/ipmi/ipmi_si_sm.h   | 22 +-
>  drivers/char/ipmi/ipmi_smic_sm.c | 24 ++--
>  drivers/char/ipmi/ipmi_ssif.c|  6 +-
>  drivers/char/ipmi/ipmi_watchdog.c| 22 +-
>  20 files changed, 22 insertions(+), 204 deletions(-)
>
> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
> index c95b93b..8328c82 100644
> --- a/drivers/char/ipmi/bt-bmc.c
> +++ b/drivers/char/ipmi/bt-bmc.c
> @@ -1,10 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0

IBM's preferred licence is GPL-2.0+ (as indicated in the text below).

Reading through the rest of the patch, it looks like there's some
other 2+ you missed.

Cheers,

Joel


>  /*
>   * Copyright (c) 2015-2016, IBM Corporation.
> - *
> - * 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.
>   */
>
>  #include 
> diff --git a/drivers/char/ipmi/ipmi_bt_sm.c b/drivers/char/ipmi/ipmi_bt_sm.c
> index feafdab..6e63819 100644
> --- a/drivers/char/ipmi/ipmi_bt_sm.c
> +++ b/drivers/char/ipmi/ipmi_bt_sm.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   *  ipmi_bt_sm.c
>   *
> @@ -5,26 +6,7 @@
>   *  of the driver architecture at http://sourceforge.net/projects/openipmi
>   *
>   *  Author:Rocky Craig 
> - *
> - *  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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> - *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> - *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> - *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> - *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> - *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> - *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> - *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> - *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> - *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> - *
> - *  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.,
> - *  675 Mass Ave, Cambridge, MA 02139, USA.  */
> + */
>
>  #include  /* For printk. */
>  #include 
> diff --git a/drivers/char/ipmi/ipmi_devintf.c 
> b/drivers/char/ipmi/ipmi_devintf.c
> index 5f1bc91..e21565b 100644
> --- a/drivers/char/ipmi/ipmi_devintf.c
> +++ b/drivers/char/ipmi/ipmi_devintf.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * ipmi_devintf.c
>   *
> @@ -8,27 +9,6 @@
>   * sou...@mvista.com
>   *
>   * Copyright 2002 MontaVista Software 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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> - *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> - *  

Re: [PATCH] ipmi: Add or fix SPDX-License-Identifier in all files

[Joel Stanley]

On Tue, Feb 27, 2018 at 1:54 AM,   wrote:
> From: Corey Minyard 
>
> And get rid of the license text that is no longer necessary.
>
> Signed-off-by: Corey Minyard 
> Cc: Kees Cook 
> Cc: Alistair Popple 
> Cc: Jeremy Kerr 
> Cc: Joel Stanley 
> Cc: Rocky Craig 
> ---
>
> Just a cleanup of these things.
>
>  drivers/char/ipmi/bt-bmc.c   |  6 +-
>  drivers/char/ipmi/ipmi_bt_sm.c   | 22 ++
>  drivers/char/ipmi/ipmi_devintf.c | 22 +-
>  drivers/char/ipmi/ipmi_kcs_sm.c  | 22 +-
>  drivers/char/ipmi/ipmi_msghandler.c  | 22 +-
>  drivers/char/ipmi/ipmi_powernv.c |  6 +-
>  drivers/char/ipmi/ipmi_poweroff.c| 22 +-
>  drivers/char/ipmi/ipmi_si.h  |  1 +
>  drivers/char/ipmi/ipmi_si_hardcode.c |  1 +
>  drivers/char/ipmi/ipmi_si_hotmod.c   |  1 +
>  drivers/char/ipmi/ipmi_si_intf.c | 22 +-
>  drivers/char/ipmi/ipmi_si_mem_io.c   |  1 +
>  drivers/char/ipmi/ipmi_si_parisc.c   |  1 +
>  drivers/char/ipmi/ipmi_si_pci.c  |  1 +
>  drivers/char/ipmi/ipmi_si_platform.c |  1 +
>  drivers/char/ipmi/ipmi_si_port_io.c  |  1 +
>  drivers/char/ipmi/ipmi_si_sm.h   | 22 +-
>  drivers/char/ipmi/ipmi_smic_sm.c | 24 ++--
>  drivers/char/ipmi/ipmi_ssif.c|  6 +-
>  drivers/char/ipmi/ipmi_watchdog.c| 22 +-
>  20 files changed, 22 insertions(+), 204 deletions(-)
>
> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
> index c95b93b..8328c82 100644
> --- a/drivers/char/ipmi/bt-bmc.c
> +++ b/drivers/char/ipmi/bt-bmc.c
> @@ -1,10 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0

IBM's preferred licence is GPL-2.0+ (as indicated in the text below).

Reading through the rest of the patch, it looks like there's some
other 2+ you missed.

Cheers,

Joel


>  /*
>   * Copyright (c) 2015-2016, IBM Corporation.
> - *
> - * 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.
>   */
>
>  #include 
> diff --git a/drivers/char/ipmi/ipmi_bt_sm.c b/drivers/char/ipmi/ipmi_bt_sm.c
> index feafdab..6e63819 100644
> --- a/drivers/char/ipmi/ipmi_bt_sm.c
> +++ b/drivers/char/ipmi/ipmi_bt_sm.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   *  ipmi_bt_sm.c
>   *
> @@ -5,26 +6,7 @@
>   *  of the driver architecture at http://sourceforge.net/projects/openipmi
>   *
>   *  Author:Rocky Craig 
> - *
> - *  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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> - *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> - *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> - *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> - *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> - *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> - *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> - *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> - *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> - *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> - *
> - *  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.,
> - *  675 Mass Ave, Cambridge, MA 02139, USA.  */
> + */
>
>  #include  /* For printk. */
>  #include 
> diff --git a/drivers/char/ipmi/ipmi_devintf.c 
> b/drivers/char/ipmi/ipmi_devintf.c
> index 5f1bc91..e21565b 100644
> --- a/drivers/char/ipmi/ipmi_devintf.c
> +++ b/drivers/char/ipmi/ipmi_devintf.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * ipmi_devintf.c
>   *
> @@ -8,27 +9,6 @@
>   * sou...@mvista.com
>   *
>   * Copyright 2002 MontaVista Software 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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> - *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> - *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> - *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> - *  INCIDENTAL, SPECIAL, EXEMPLARY, OR 

Re: [PATCH v5 2/9] watchdog/hpwdt: Remove legacy NMI sourcing.

[Jerry Hoemann]

On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote:
> On 02/26/2018 06:11 AM, Arnd Bergmann wrote:
> > On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann  
> > wrote:
> > > Gen8 and prior Proliant systems supported the "CRU" interface
> > > to firmware.  This interfaces allows linux to "call back" into firmware
> > > to source the cause of an NMI.  This feature isn't fully utilized
> > > as the actual source of the NMI isn't printed, the driver only
> > > indicates that the source couldn't be determined when the call
> > > fails.
> > > 
> > > With the advent of Gen9, iCRU replaces the CRU. The call back
> > > feature is no longer available in firmware.  To be compatible and
> > > not attempt to call back into firmware on system not supporting CRU,
> > > the SMBIOS table is consulted to determine if it is safe to
> > > make the call back or not.
> > > 
> > > This results in about half of the driver code being devoted
> > > to either making CRU calls or determing if it is safe to make
> > > CRU calls.  As noted, the driver isn't really using the results of
> > > the CRU calls.
> > > 
> > > Furthermore, as a consequence of the Spectre security issue, the
> > > BIOS/EFI calls are being wrapped into Spectre-disabling section.
> > > Removing the call back in hpwdt_pretimeout assists in this effort.
> > > 
> > > As the CRU sourcing of the NMI isn't required for handling the
> > > NMI and there are security concerns with making the call back, remove
> > > the legacy (pre Gen9) NMI sourcing and the DMI code to determine if
> > > the system had the CRU interface.
> > > 
> > > Signed-off-by: Jerry Hoemann 
> > 
> > This avoids a warning in mainline kernels, so that's great:
> > 
> > drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call
> > found in RETPOLINE build
> > 
> > I wonder what we do about stable kernels. Are both this patch and the patch
> > that added the objtool warning message candidates for backports to
> > stable kernels?
> > 
> 
> Makes sense to me, but it is really a bit more than a bug fix, so I'll
> leave it up to Jerry/HPE to make the call in respect to hpwdt.
> 

Generally speaking, HPE customers who run linux do so through a distro
vendor and pick up patches from them.  But I'm sure there are some
customers who do things differently.

The distro vendor's have their own repos and we'll work with them
to back port patches to their code base.  So, I typically don't do a lot
of kernel.org stable branch work.

Looks like objtool has been enhanced to find Spectre vulnerable code.
Are the other kernel patches related to Spectre being back ported
to stable release lines?  If yes, it probably make sense to do
the hpwdt change as well.

Is just the patch removing the firmware call back wanted/needed? Or the
whole driver rewrite?  (The older baseline don't have all the watchdog
features that the patch set uses.)

Which stable baseline(s) would need to be patched?  Priority?

Who does it?  (i.e. do you want me to submit patches to the stable baseline?)

Thanks

-- 

-
Jerry Hoemann  Software Engineer   Hewlett Packard Enterprise
-

Re: [PATCH v5 2/9] watchdog/hpwdt: Remove legacy NMI sourcing.

[Jerry Hoemann]

On Mon, Feb 26, 2018 at 06:32:30AM -0800, Guenter Roeck wrote:
> On 02/26/2018 06:11 AM, Arnd Bergmann wrote:
> > On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann  
> > wrote:
> > > Gen8 and prior Proliant systems supported the "CRU" interface
> > > to firmware.  This interfaces allows linux to "call back" into firmware
> > > to source the cause of an NMI.  This feature isn't fully utilized
> > > as the actual source of the NMI isn't printed, the driver only
> > > indicates that the source couldn't be determined when the call
> > > fails.
> > > 
> > > With the advent of Gen9, iCRU replaces the CRU. The call back
> > > feature is no longer available in firmware.  To be compatible and
> > > not attempt to call back into firmware on system not supporting CRU,
> > > the SMBIOS table is consulted to determine if it is safe to
> > > make the call back or not.
> > > 
> > > This results in about half of the driver code being devoted
> > > to either making CRU calls or determing if it is safe to make
> > > CRU calls.  As noted, the driver isn't really using the results of
> > > the CRU calls.
> > > 
> > > Furthermore, as a consequence of the Spectre security issue, the
> > > BIOS/EFI calls are being wrapped into Spectre-disabling section.
> > > Removing the call back in hpwdt_pretimeout assists in this effort.
> > > 
> > > As the CRU sourcing of the NMI isn't required for handling the
> > > NMI and there are security concerns with making the call back, remove
> > > the legacy (pre Gen9) NMI sourcing and the DMI code to determine if
> > > the system had the CRU interface.
> > > 
> > > Signed-off-by: Jerry Hoemann 
> > 
> > This avoids a warning in mainline kernels, so that's great:
> > 
> > drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call
> > found in RETPOLINE build
> > 
> > I wonder what we do about stable kernels. Are both this patch and the patch
> > that added the objtool warning message candidates for backports to
> > stable kernels?
> > 
> 
> Makes sense to me, but it is really a bit more than a bug fix, so I'll
> leave it up to Jerry/HPE to make the call in respect to hpwdt.
> 

Generally speaking, HPE customers who run linux do so through a distro
vendor and pick up patches from them.  But I'm sure there are some
customers who do things differently.

The distro vendor's have their own repos and we'll work with them
to back port patches to their code base.  So, I typically don't do a lot
of kernel.org stable branch work.

Looks like objtool has been enhanced to find Spectre vulnerable code.
Are the other kernel patches related to Spectre being back ported
to stable release lines?  If yes, it probably make sense to do
the hpwdt change as well.

Is just the patch removing the firmware call back wanted/needed? Or the
whole driver rewrite?  (The older baseline don't have all the watchdog
features that the patch set uses.)

Which stable baseline(s) would need to be patched?  Priority?

Who does it?  (i.e. do you want me to submit patches to the stable baseline?)

Thanks

-- 

-
Jerry Hoemann  Software Engineer   Hewlett Packard Enterprise
-

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

[David Rientjes]

On Tue, 27 Feb 2018, Yang Shi wrote:

> 
> Background:
> When running vm-scalability with large memory (> 300GB), the below hung
> task issue happens occasionally.
> 
> INFO: task ps:14018 blocked for more than 120 seconds.
>Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
>  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>  ps  D0 14018  1 0x0004
>   885582f84000 885e8682f000 880972943000 885ebf499bc0
>   8828ee12 c900349bfca8 817154d0 0040
>   00ff812f872a 885ebf499bc0 024000d000948300 880972943000
>  Call Trace:
>   [] ? __schedule+0x250/0x730
>   [] schedule+0x36/0x80
>   [] rwsem_down_read_failed+0xf0/0x150
>   [] call_rwsem_down_read_failed+0x18/0x30
>   [] down_read+0x20/0x40
>   [] proc_pid_cmdline_read+0xd9/0x4e0
>   [] ? do_filp_open+0xa5/0x100
>   [] __vfs_read+0x37/0x150
>   [] ? security_file_permission+0x9b/0xc0
>   [] vfs_read+0x96/0x130
>   [] SyS_read+0x55/0xc0
>   [] entry_SYSCALL_64_fastpath+0x1a/0xc5
> 
> When manipulating a large mapping, the process may hold the mmap_sem for
> long time, so reading /proc//cmdline may be blocked in
> uninterruptible state for long time.
> We already have killable version APIs for semaphore, here use 
> down_read_killable()
> to improve the responsiveness.
> 

Rather than killable, we have patches that introduce down_read_unfair() 
variants for the files you've modified (cmdline and environ) as well as 
others (maps, numa_maps, smaps).

When another thread is holding down_read() and there are queued 
down_write()'s, down_read_unfair() allows for grabbing the rwsem without 
queueing for it.  Additionally, when another thread is holding 
down_write(), down_read_unfair() allows for queueing in front of other 
threads trying to grab it for write as well.

Ingo would know more about whether a variant like that in upstream Linux 
would be acceptable.

Would you be interested in unfair variants instead of only addressing 
killable?

Re: [RFC PATCH 0/4 v2] Define killable version for access_remote_vm() and use it in fs/proc

[David Rientjes]

On Tue, 27 Feb 2018, Yang Shi wrote:

> 
> Background:
> When running vm-scalability with large memory (> 300GB), the below hung
> task issue happens occasionally.
> 
> INFO: task ps:14018 blocked for more than 120 seconds.
>Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
>  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>  ps  D0 14018  1 0x0004
>   885582f84000 885e8682f000 880972943000 885ebf499bc0
>   8828ee12 c900349bfca8 817154d0 0040
>   00ff812f872a 885ebf499bc0 024000d000948300 880972943000
>  Call Trace:
>   [] ? __schedule+0x250/0x730
>   [] schedule+0x36/0x80
>   [] rwsem_down_read_failed+0xf0/0x150
>   [] call_rwsem_down_read_failed+0x18/0x30
>   [] down_read+0x20/0x40
>   [] proc_pid_cmdline_read+0xd9/0x4e0
>   [] ? do_filp_open+0xa5/0x100
>   [] __vfs_read+0x37/0x150
>   [] ? security_file_permission+0x9b/0xc0
>   [] vfs_read+0x96/0x130
>   [] SyS_read+0x55/0xc0
>   [] entry_SYSCALL_64_fastpath+0x1a/0xc5
> 
> When manipulating a large mapping, the process may hold the mmap_sem for
> long time, so reading /proc//cmdline may be blocked in
> uninterruptible state for long time.
> We already have killable version APIs for semaphore, here use 
> down_read_killable()
> to improve the responsiveness.
> 

Rather than killable, we have patches that introduce down_read_unfair() 
variants for the files you've modified (cmdline and environ) as well as 
others (maps, numa_maps, smaps).

When another thread is holding down_read() and there are queued 
down_write()'s, down_read_unfair() allows for grabbing the rwsem without 
queueing for it.  Additionally, when another thread is holding 
down_write(), down_read_unfair() allows for queueing in front of other 
threads trying to grab it for write as well.

Ingo would know more about whether a variant like that in upstream Linux 
would be acceptable.

Would you be interested in unfair variants instead of only addressing 
killable?

[PATCH] ARM: dts: NSP: Fix amount of RAM on BCM958625HR

[Florian Fainelli]

Jon attempted to fix the amount of RAM on the BCM958625HR in commit
c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board")
but it seems like we tripped over some poorly documented schematics.

The top-level page of the schematics says the board has 2GB, but when
you end-up scrolling to page 6, you see two chips of 4GiB (512MB) but
what the bootloader really initializes only 512MB, any attempt to use
more than that results in data aborts. Fix this again back to 512MB.

Fixes: c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board")
Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/bcm958625hr.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm958625hr.dts 
b/arch/arm/boot/dts/bcm958625hr.dts
index 6a44b8021702..f0e2008f7490 100644
--- a/arch/arm/boot/dts/bcm958625hr.dts
+++ b/arch/arm/boot/dts/bcm958625hr.dts
@@ -49,7 +49,7 @@
 
memory {
device_type = "memory";
-   reg = <0x6000 0x8000>;
+   reg = <0x6000 0x2000>;
};
 
gpio-restart {
-- 
2.14.1

[PATCH] ARM: dts: NSP: Fix amount of RAM on BCM958625HR

[Florian Fainelli]

Jon attempted to fix the amount of RAM on the BCM958625HR in commit
c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board")
but it seems like we tripped over some poorly documented schematics.

The top-level page of the schematics says the board has 2GB, but when
you end-up scrolling to page 6, you see two chips of 4GiB (512MB) but
what the bootloader really initializes only 512MB, any attempt to use
more than that results in data aborts. Fix this again back to 512MB.

Fixes: c53beb47f621 ("ARM: dts: NSP: Correct RAM amount for BCM958625HR board")
Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/bcm958625hr.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm958625hr.dts 
b/arch/arm/boot/dts/bcm958625hr.dts
index 6a44b8021702..f0e2008f7490 100644
--- a/arch/arm/boot/dts/bcm958625hr.dts
+++ b/arch/arm/boot/dts/bcm958625hr.dts
@@ -49,7 +49,7 @@
 
memory {
device_type = "memory";
-   reg = <0x6000 0x8000>;
+   reg = <0x6000 0x2000>;
};
 
gpio-restart {
-- 
2.14.1

Re: [PATCH 4.15 00/64] 4.15.7-stable review

[Shuah Khan]

On 02/26/2018 01:21 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.15.7 release.
> There are 64 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:21:30 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.7-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.15 00/64] 4.15.7-stable review

[Shuah Khan]

On 02/26/2018 01:21 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.15.7 release.
> There are 64 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:21:30 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.7-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

[Al Viro]

On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote:
> The function current_nameidata_security(struct inode *) can be used to
> retrieve a blob's pointer address tied to the inode being walk through.
> This enable to follow a path lookup and know where an inode access come
> from. This is needed for the Landlock LSM to be able to restrict access
> to file path.
> 
> The LSM hook nameidata_free_security(struct inode *) is called before
> freeing the associated nameidata.

NAK.  Not without well-defined semantics and "some Linux S uses that for
something, don't ask what" does not count.

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

[Al Viro]

On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote:
> The function current_nameidata_security(struct inode *) can be used to
> retrieve a blob's pointer address tied to the inode being walk through.
> This enable to follow a path lookup and know where an inode access come
> from. This is needed for the Landlock LSM to be able to restrict access
> to file path.
> 
> The LSM hook nameidata_free_security(struct inode *) is called before
> freeing the associated nameidata.

NAK.  Not without well-defined semantics and "some Linux S uses that for
something, don't ask what" does not count.

Re: [PATCH 4.14 00/54] 4.14.23-stable review

[Shuah Khan]

On 02/26/2018 01:21 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.23 release.
> There are 54 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:21:22 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.23-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.14 00/54] 4.14.23-stable review

[Shuah Khan]

On 02/26/2018 01:21 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.23 release.
> There are 54 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:21:22 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.23-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/39] 4.9.85-stable review

[Shuah Khan]

On 02/26/2018 01:20 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.85 release.
> There are 39 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:16:31 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.85-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/39] 4.9.85-stable review

[Shuah Khan]

On 02/26/2018 01:20 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.85 release.
> There are 39 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:16:31 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.85-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/22] 4.4.119-stable review

[Shuah Khan]

On 02/26/2018 01:16 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.119 release.
> There are 22 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:15:48 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.119-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/22] 4.4.119-stable review

[Shuah Khan]

On 02/26/2018 01:16 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.119 release.
> There are 22 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:15:48 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.119-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 00/13] 3.18.97-stable review

[Shuah Khan]

On 02/26/2018 01:15 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.97 release.
> There are 13 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.97-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 00/13] 3.18.97-stable review

[Shuah Khan]

On 02/26/2018 01:15 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.97 release.
> There are 13 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.97-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread

[Jin, Yao]

On 1/23/2018 10:19 PM, Jiri Olsa wrote:

On Mon, Jan 22, 2018 at 01:10:31PM +0800, Jin, Yao wrote:



On 1/16/2018 9:17 PM, Jiri Olsa wrote:

On Tue, Jan 16, 2018 at 09:06:09PM +0800, Jin, Yao wrote:

Just tested. But looks it's not OK for '--per-thread' case.


yea, I haven't tested much.. might need soem tweaking,
but my point was that it could be doable on one place
instead of introducing another if possible

jirka



Hi Jiri,

I ever considered to move the operation of removing error thread to
perf_evsel__fallback(). The perf_evsel__fallback() is common code and it's
shared by perf report, perf stat and perf top.

While finally I think it'd better let the caller decide to remove error
thread and try again, or just return the warning message.
perf_evsel__fallback() probably doesn't know what the caller want to do.

That's my current thinking. Maybe there will be a better fix...


ok, can't think of better fix atm.. looks good ;-)

Acked-by: Jiri Olsa 

thanks,
jirka



Hi Arnaldo,

Could this fix be accepted?

Thanks
Jin Yao

Re: [PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread

[Jin, Yao]

On 1/23/2018 10:19 PM, Jiri Olsa wrote:

On Mon, Jan 22, 2018 at 01:10:31PM +0800, Jin, Yao wrote:



On 1/16/2018 9:17 PM, Jiri Olsa wrote:

On Tue, Jan 16, 2018 at 09:06:09PM +0800, Jin, Yao wrote:

Just tested. But looks it's not OK for '--per-thread' case.


yea, I haven't tested much.. might need soem tweaking,
but my point was that it could be doable on one place
instead of introducing another if possible

jirka



Hi Jiri,

I ever considered to move the operation of removing error thread to
perf_evsel__fallback(). The perf_evsel__fallback() is common code and it's
shared by perf report, perf stat and perf top.

While finally I think it'd better let the caller decide to remove error
thread and try again, or just return the warning message.
perf_evsel__fallback() probably doesn't know what the caller want to do.

That's my current thinking. Maybe there will be a better fix...


ok, can't think of better fix atm.. looks good ;-)

Acked-by: Jiri Olsa 

thanks,
jirka



Hi Arnaldo,

Could this fix be accepted?

Thanks
Jin Yao

Re: [RFC 1/3] seccomp: add a return code to trap to userspace

[Kees Cook]

On Wed, Feb 14, 2018 at 9:19 AM, Andy Lutomirski  wrote:
> On Wed, Feb 14, 2018 at 3:29 PM, Tycho Andersen  wrote:
>> On Tue, Feb 13, 2018 at 01:09:20PM -0800, Kees Cook wrote:
>>> On Sun, Feb 4, 2018 at 2:49 AM, Tycho Andersen  wrote:
>>> I wonder if this communication should be netlink, which gives a more
>>> well-structured way to describe what's on the wire? The reason I ask
>>> is because if we ever change the seccomp_data structure, we'll now
>>> have two places where we need to deal with it (the first being within
>>> the BPF itself). My initial idea was to prefix the communication with
>>> a size field, then send the structure, and then I had nightmares, and
>>> realized this was basically netlink reinvented.
>>
>> I suggested netlink in LA, and everyone (especially Andy) groaned very
>> loudly :). I'm happy to switch it to netlink if you like, although i
>> think memcpy() of structs should be safe here, since the return value
>> from read or write can indicate the size of things.
>
> I could easily get on board with "netlink" (i.e. NLA) messages sent
> over an fd.  I will object strongly to the use of netlink *sockets*.

Yeah, I was thinking NLA over the fd; not a netlink socket.

>>> An ERRNO filter would block a USER_NOTIF because it's unconditional.
>>> TRACE could be either, USER_NOTIF could be either.
>>>
>>> This means TRACE rules would be bumped by a USER_NOTIF... hmm.
>>
>> Yes, I didn't exactly know what to do here. ERRNO, TRAP, and KILL all
>> seemed more important than USER_NOTIF, but TRACE didn't. I don't have
>> a strong opinion about what to do here, because users can adjust their
>> filters accordingly. Let me know what you prefer.
>
> If we switched to eBPF functions, this whole issue goes away.

Yeah, though we'd still need some kind of "wait for answer" eBPF
function. It feels wrong to re-use maps for that...

-Kees

-- 
Kees Cook
Pixel Security

Re: [RFC 1/3] seccomp: add a return code to trap to userspace

[Kees Cook]

On Wed, Feb 14, 2018 at 9:19 AM, Andy Lutomirski  wrote:
> On Wed, Feb 14, 2018 at 3:29 PM, Tycho Andersen  wrote:
>> On Tue, Feb 13, 2018 at 01:09:20PM -0800, Kees Cook wrote:
>>> On Sun, Feb 4, 2018 at 2:49 AM, Tycho Andersen  wrote:
>>> I wonder if this communication should be netlink, which gives a more
>>> well-structured way to describe what's on the wire? The reason I ask
>>> is because if we ever change the seccomp_data structure, we'll now
>>> have two places where we need to deal with it (the first being within
>>> the BPF itself). My initial idea was to prefix the communication with
>>> a size field, then send the structure, and then I had nightmares, and
>>> realized this was basically netlink reinvented.
>>
>> I suggested netlink in LA, and everyone (especially Andy) groaned very
>> loudly :). I'm happy to switch it to netlink if you like, although i
>> think memcpy() of structs should be safe here, since the return value
>> from read or write can indicate the size of things.
>
> I could easily get on board with "netlink" (i.e. NLA) messages sent
> over an fd.  I will object strongly to the use of netlink *sockets*.

Yeah, I was thinking NLA over the fd; not a netlink socket.

>>> An ERRNO filter would block a USER_NOTIF because it's unconditional.
>>> TRACE could be either, USER_NOTIF could be either.
>>>
>>> This means TRACE rules would be bumped by a USER_NOTIF... hmm.
>>
>> Yes, I didn't exactly know what to do here. ERRNO, TRAP, and KILL all
>> seemed more important than USER_NOTIF, but TRACE didn't. I don't have
>> a strong opinion about what to do here, because users can adjust their
>> filters accordingly. Let me know what you prefer.
>
> If we switched to eBPF functions, this whole issue goes away.

Yeah, though we'd still need some kind of "wait for answer" eBPF
function. It feels wrong to re-use maps for that...

-Kees

-- 
Kees Cook
Pixel Security

Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'

[Masahiro Yamada]

2018-02-26 21:43 GMT+09:00 Arnd Bergmann :
> On Mon, Feb 26, 2018 at 12:53 PM, Masahiro Yamada
>  wrote:
>> 2018-02-26 17:43 GMT+09:00 Arnd Bergmann :
>>> On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada
>>>  wrote:
 As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
 used with care - it forces a lower limit of another symbol, ignoring
 the dependency.

 MFD_SYSCON depends on HAS_IOMEM, but several drivers with COMPILE_TEST
 select it.

 This causes unmet dependencies for architecture without HAS_IOMEM.

   $ make ARCH=score randconfig
   scripts/kconfig/conf  --randconfig Kconfig
   KCONFIG_SEED=0x27C47F43
   warning: (HWSPINLOCK_QCOM && AHCI_MTK && STMMAC_PLATFORM && ...)
   selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

 Use 'depends on' to observe the dependency.

 This commit was created by the following command:

   $ find drivers -name 'Kconfig*' | xargs sed -i -e \
 's/select MFD_SYSCON$/depends on MFD_SYSCON/'

 Then, COMMON_CLK_NXP and S3C2410_WATCHDOG were fixed up manually.

 Also, make MFD_SYSCON 'default y' because some defconfig files may
 rely on someone select's MFD_SYSCON.

 Signed-off-by: Masahiro Yamada 
 ---

 If you have a better idea to fix 'unmet dependencies',
 please suggest.
>>>
>>> Changing 'select MFD_SYSCON' to 'depends on' will definitely break lots
>>> of defconfig configurations, I'd rather not do that.
>>
>>
>> Could you explain why?
>>
>> I set 'default y' for MFD_SYSCON.
>>
>> Would it still break defconfig configurations?
>
> No, you are right, that would not break defconfigs, it would just mean one
> useless driver being enabled for many configurations that don't need it.

If we are unhappy about this,
we can send per-arch patches
to add CONFIG_MTD_SYSCON=y to defconfigs that need it.

But, we need to decide what the right solution is.


>>> Only score, tile and um have some configurations that select 'NO_IOMEM'.
>>> Score is getting removed now, tile might get removed later (we could make
>>> PCI mandatory in the meantime to avoid that configuration), and I think for
>>> um, we already have a workaround for the NO_IOMEM dependencies
>>> (I forget the details).
>>
>> I do not think this is a stable solution.
>>
>> Or, do you mean to remove NO_IOMEM and HAS_IOMEM completely?
>
> We could either leave it for arch/um only and have that deal with the
> issues (which I think we already have), or we could remove the options
> entirely.
>
>   Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'

[Masahiro Yamada]

2018-02-26 21:43 GMT+09:00 Arnd Bergmann :
> On Mon, Feb 26, 2018 at 12:53 PM, Masahiro Yamada
>  wrote:
>> 2018-02-26 17:43 GMT+09:00 Arnd Bergmann :
>>> On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada
>>>  wrote:
 As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
 used with care - it forces a lower limit of another symbol, ignoring
 the dependency.

 MFD_SYSCON depends on HAS_IOMEM, but several drivers with COMPILE_TEST
 select it.

 This causes unmet dependencies for architecture without HAS_IOMEM.

   $ make ARCH=score randconfig
   scripts/kconfig/conf  --randconfig Kconfig
   KCONFIG_SEED=0x27C47F43
   warning: (HWSPINLOCK_QCOM && AHCI_MTK && STMMAC_PLATFORM && ...)
   selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

 Use 'depends on' to observe the dependency.

 This commit was created by the following command:

   $ find drivers -name 'Kconfig*' | xargs sed -i -e \
 's/select MFD_SYSCON$/depends on MFD_SYSCON/'

 Then, COMMON_CLK_NXP and S3C2410_WATCHDOG were fixed up manually.

 Also, make MFD_SYSCON 'default y' because some defconfig files may
 rely on someone select's MFD_SYSCON.

 Signed-off-by: Masahiro Yamada 
 ---

 If you have a better idea to fix 'unmet dependencies',
 please suggest.
>>>
>>> Changing 'select MFD_SYSCON' to 'depends on' will definitely break lots
>>> of defconfig configurations, I'd rather not do that.
>>
>>
>> Could you explain why?
>>
>> I set 'default y' for MFD_SYSCON.
>>
>> Would it still break defconfig configurations?
>
> No, you are right, that would not break defconfigs, it would just mean one
> useless driver being enabled for many configurations that don't need it.

If we are unhappy about this,
we can send per-arch patches
to add CONFIG_MTD_SYSCON=y to defconfigs that need it.

But, we need to decide what the right solution is.


>>> Only score, tile and um have some configurations that select 'NO_IOMEM'.
>>> Score is getting removed now, tile might get removed later (we could make
>>> PCI mandatory in the meantime to avoid that configuration), and I think for
>>> um, we already have a workaround for the NO_IOMEM dependencies
>>> (I forget the details).
>>
>> I do not think this is a stable solution.
>>
>> Or, do you mean to remove NO_IOMEM and HAS_IOMEM completely?
>
> We could either leave it for arch/um only and have that deal with the
> issues (which I think we already have), or we could remove the options
> entirely.
>
>   Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

[PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

[Mickaël Salaün]

The seccomp(2) syscall can be used by a task to apply a Landlock program
to itself. As a seccomp filter, a Landlock program is enforced for the
current task and all its future children. A program is immutable and a
task can only add new restricting programs to itself, forming a list of
programss.

A Landlock program is tied to a Landlock hook. If the action on a kernel
object is allowed by the other Linux security mechanisms (e.g. DAC,
capabilities, other LSM), then a Landlock hook related to this kind of
object is triggered. The list of programs for this hook is then
evaluated. Each program return a 32-bit value which can deny the action
on a kernel object with a non-zero value. If every programs of the list
return zero, then the action on the object is allowed.

Multiple Landlock programs can be chained to share a 64-bits value for a
call chain (e.g. evaluating multiple elements of a file path).  This
chaining is restricted when a process construct this chain by loading a
program, but additional checks are performed when it requests to apply
this chain of programs to itself.  The restrictions ensure that it is
not possible to call multiple programs in a way that would imply to
handle multiple shared values (i.e. cookies) for one chain.  For now,
only a fs_pick program can be chained to the same type of program,
because it may make sense if they have different triggers (cf. next
commits).  This restrictions still allows to reuse Landlock programs in
a safe way (e.g. use the same loaded fs_walk program with multiple
chains of fs_pick programs).

Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Cc: Will Drewry 
Link: https://lkml.kernel.org/r/c10a503d-5e35-7785-2f3d-25ed8dd63...@digikod.net
---

Changes since v7:
* handle and verify program chains
* split and rename providers.c to enforce.c and enforce_seccomp.c
* rename LANDLOCK_SUBTYPE_* to LANDLOCK_*

Changes since v6:
* rename some functions with more accurate names to reflect that an eBPF
  program for Landlock could be used for something else than a rule
* reword rule "appending" to "prepending" and explain it
* remove the superfluous no_new_privs check, only check global
  CAP_SYS_ADMIN when prepending a Landlock rule (needed for containers)
* create and use {get,put}_seccomp_landlock() (suggested by Kees Cook)
* replace ifdef with static inlined function (suggested by Kees Cook)
* use get_user() (suggested by Kees Cook)
* replace atomic_t with refcount_t (requested by Kees Cook)
* move struct landlock_{rule,events} from landlock.h to common.h
* cleanup headers

Changes since v5:
* remove struct landlock_node and use a similar inheritance mechanisme
  as seccomp-bpf (requested by Andy Lutomirski)
* rename SECCOMP_ADD_LANDLOCK_RULE to SECCOMP_APPEND_LANDLOCK_RULE
* rename file manager.c to providers.c
* add comments
* typo and cosmetic fixes

Changes since v4:
* merge manager and seccomp patches
* return -EFAULT in seccomp(2) when user_bpf_fd is null to easely check
  if Landlock is supported
* only allow a process with the global CAP_SYS_ADMIN to use Landlock
  (will be lifted in the future)
* add an early check to exit as soon as possible if the current process
  does not have Landlock rules

Changes since v3:
* remove the hard link with seccomp (suggested by Andy Lutomirski and
  Kees Cook):
  * remove the cookie which could imply multiple evaluation of Landlock
rules
  * remove the origin field in struct landlock_data
* remove documentation fix (merged upstream)
* rename the new seccomp command to SECCOMP_ADD_LANDLOCK_RULE
* internal renaming
* split commit
* new design to be able to inherit on the fly the parent rules

Changes since v2:
* Landlock programs can now be run without seccomp filter but for any
  syscall (from the process) or interruption
* move Landlock related functions and structs into security/landlock/*
  (to manage cgroups as well)
* fix seccomp filter handling: run Landlock programs for each of their
  legitimate seccomp filter
* properly clean up all seccomp results
* cosmetic changes to ease the understanding
* fix some ifdef
---
 include/linux/landlock.h|  37 
 include/linux/seccomp.h |   5 +
 include/uapi/linux/seccomp.h|   1 +
 kernel/fork.c   |   8 +-
 kernel/seccomp.c|   4 +
 security/landlock/Makefile  |   3 +-
 security/landlock/chain.c   |  39 
 security/landlock/chain.h   |  35 
 security/landlock/common.h  |  53 +
 security/landlock/enforce.c | 386 
 security/landlock/enforce.h |  21 ++
 security/landlock/enforce_seccomp.c | 102 ++
 12 files changed, 692 insertions(+), 2 

[PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

[Mickaël Salaün]

Hi,

This eight series is a major revamp of the Landlock design compared to
the previous series [1]. This enables more flexibility and granularity
of access control with file paths. It is now possible to enforce an
access control according to a file hierarchy. Landlock uses the concept
of inode and path to identify such hierarchy. In a way, it brings tools
to program what is a file hierarchy.

There is now three types of Landlock hooks: FS_WALK, FS_PICK and FS_GET.
Each of them accepts a dedicated eBPF program, called a Landlock
program.  They can be chained to enforce a full access control according
to a list of directories or files. The set of actions on a file is well
defined (e.g. read, write, ioctl, append, lock, mount...) taking
inspiration from the major Linux LSMs and some other access-controls
like Capsicum.  These program types are designed to be cache-friendly,
which give room for optimizations in the future.

The documentation patch contains some kernel documentation and
explanations on how to use Landlock.  The compiled documentation and
a talk I gave at FOSDEM can be found here: https://landlock.io
This patch series can be found in the branch landlock-v8 in this repo:
https://github.com/landlock-lsm/linux

There is still some minor issues with this patch series but it should
demonstrate how powerful this design may be. One of these issues is that
it is not a stackable LSM anymore, but the infrastructure management of
security blobs should allow to stack it with other LSM [4].

This is the first step of the roadmap discussed at LPC [2].  While the
intended final goal is to allow unprivileged users to use Landlock, this
series allows only a process with global CAP_SYS_ADMIN to load and
enforce a rule.  This may help to get feedback and avoid unexpected
behaviors.

This series can be applied on top of bpf-next, commit 7d72637eb39f
("Merge branch 'x86-jit'").  This can be tested with
CONFIG_SECCOMP_FILTER and CONFIG_SECURITY_LANDLOCK.  I would really
appreciate constructive comments on the design and the code.


# Landlock LSM

The goal of this new Linux Security Module (LSM) called Landlock is to
allow any process, including unprivileged ones, to create powerful
security sandboxes comparable to XNU Sandbox or OpenBSD Pledge. This
kind of sandbox is expected to help mitigate the security impact of bugs
or unexpected/malicious behaviors in user-space applications.

The approach taken is to add the minimum amount of code while still
allowing the user-space application to create quite complex access
rules.  A dedicated security policy language such as the one used by
SELinux, AppArmor and other major LSMs involves a lot of code and is
usually permitted to only a trusted user (i.e. root).  On the contrary,
eBPF programs already exist and are designed to be safely loaded by
unprivileged user-space.

This design does not seem too intrusive but is flexible enough to allow
a powerful sandbox mechanism accessible by any process on Linux. The use
of seccomp and Landlock is more suitable with the help of a user-space
library (e.g.  libseccomp) that could help to specify a high-level
language to express a security policy instead of raw eBPF programs.
Moreover, thanks to the LLVM front-end, it is quite easy to write an
eBPF program with a subset of the C language.


# Frequently asked questions

## Why is seccomp-bpf not enough?

A seccomp filter can access only raw syscall arguments (i.e. the
register values) which means that it is not possible to filter according
to the value pointed to by an argument, such as a file pathname. As an
embryonic Landlock version demonstrated, filtering at the syscall level
is complicated (e.g. need to take care of race conditions). This is
mainly because the access control checkpoints of the kernel are not at
this high-level but more underneath, at the LSM-hook level. The LSM
hooks are designed to handle this kind of checks.  Landlock abstracts
this approach to leverage the ability of unprivileged users to limit
themselves.

Cf. section "What it isn't?" in Documentation/prctl/seccomp_filter.txt


## Why use the seccomp(2) syscall?

Landlock use the same semantic as seccomp to apply access rule
restrictions. It add a new layer of security for the current process
which is inherited by its children. It makes sense to use an unique
access-restricting syscall (that should be allowed by seccomp filters)
which can only drop privileges. Moreover, a Landlock rule could come
from outside a process (e.g.  passed through a UNIX socket). It is then
useful to differentiate the creation/load of Landlock eBPF programs via
bpf(2), from rule enforcement via seccomp(2).


## Why a new LSM? Are SELinux, AppArmor, Smack and Tomoyo not good
   enough?

The current access control LSMs are fine for their purpose which is to
give the *root* the ability to enforce a security policy for the
*system*. What is missing is a way to enforce a security policy for any
application by its developer and 

[PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

[Mickaël Salaün]

The seccomp(2) syscall can be used by a task to apply a Landlock program
to itself. As a seccomp filter, a Landlock program is enforced for the
current task and all its future children. A program is immutable and a
task can only add new restricting programs to itself, forming a list of
programss.

A Landlock program is tied to a Landlock hook. If the action on a kernel
object is allowed by the other Linux security mechanisms (e.g. DAC,
capabilities, other LSM), then a Landlock hook related to this kind of
object is triggered. The list of programs for this hook is then
evaluated. Each program return a 32-bit value which can deny the action
on a kernel object with a non-zero value. If every programs of the list
return zero, then the action on the object is allowed.

Multiple Landlock programs can be chained to share a 64-bits value for a
call chain (e.g. evaluating multiple elements of a file path).  This
chaining is restricted when a process construct this chain by loading a
program, but additional checks are performed when it requests to apply
this chain of programs to itself.  The restrictions ensure that it is
not possible to call multiple programs in a way that would imply to
handle multiple shared values (i.e. cookies) for one chain.  For now,
only a fs_pick program can be chained to the same type of program,
because it may make sense if they have different triggers (cf. next
commits).  This restrictions still allows to reuse Landlock programs in
a safe way (e.g. use the same loaded fs_walk program with multiple
chains of fs_pick programs).

Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Cc: Will Drewry 
Link: https://lkml.kernel.org/r/c10a503d-5e35-7785-2f3d-25ed8dd63...@digikod.net
---

Changes since v7:
* handle and verify program chains
* split and rename providers.c to enforce.c and enforce_seccomp.c
* rename LANDLOCK_SUBTYPE_* to LANDLOCK_*

Changes since v6:
* rename some functions with more accurate names to reflect that an eBPF
  program for Landlock could be used for something else than a rule
* reword rule "appending" to "prepending" and explain it
* remove the superfluous no_new_privs check, only check global
  CAP_SYS_ADMIN when prepending a Landlock rule (needed for containers)
* create and use {get,put}_seccomp_landlock() (suggested by Kees Cook)
* replace ifdef with static inlined function (suggested by Kees Cook)
* use get_user() (suggested by Kees Cook)
* replace atomic_t with refcount_t (requested by Kees Cook)
* move struct landlock_{rule,events} from landlock.h to common.h
* cleanup headers

Changes since v5:
* remove struct landlock_node and use a similar inheritance mechanisme
  as seccomp-bpf (requested by Andy Lutomirski)
* rename SECCOMP_ADD_LANDLOCK_RULE to SECCOMP_APPEND_LANDLOCK_RULE
* rename file manager.c to providers.c
* add comments
* typo and cosmetic fixes

Changes since v4:
* merge manager and seccomp patches
* return -EFAULT in seccomp(2) when user_bpf_fd is null to easely check
  if Landlock is supported
* only allow a process with the global CAP_SYS_ADMIN to use Landlock
  (will be lifted in the future)
* add an early check to exit as soon as possible if the current process
  does not have Landlock rules

Changes since v3:
* remove the hard link with seccomp (suggested by Andy Lutomirski and
  Kees Cook):
  * remove the cookie which could imply multiple evaluation of Landlock
rules
  * remove the origin field in struct landlock_data
* remove documentation fix (merged upstream)
* rename the new seccomp command to SECCOMP_ADD_LANDLOCK_RULE
* internal renaming
* split commit
* new design to be able to inherit on the fly the parent rules

Changes since v2:
* Landlock programs can now be run without seccomp filter but for any
  syscall (from the process) or interruption
* move Landlock related functions and structs into security/landlock/*
  (to manage cgroups as well)
* fix seccomp filter handling: run Landlock programs for each of their
  legitimate seccomp filter
* properly clean up all seccomp results
* cosmetic changes to ease the understanding
* fix some ifdef
---
 include/linux/landlock.h|  37 
 include/linux/seccomp.h |   5 +
 include/uapi/linux/seccomp.h|   1 +
 kernel/fork.c   |   8 +-
 kernel/seccomp.c|   4 +
 security/landlock/Makefile  |   3 +-
 security/landlock/chain.c   |  39 
 security/landlock/chain.h   |  35 
 security/landlock/common.h  |  53 +
 security/landlock/enforce.c | 386 
 security/landlock/enforce.h |  21 ++
 security/landlock/enforce_seccomp.c | 102 ++
 12 files changed, 692 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/landlock.h
 create mode 100644 security/landlock/chain.c
 create mode 100644 security/landlock/chain.h
 create mode 100644 

[PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

[Mickaël Salaün]

Hi,

This eight series is a major revamp of the Landlock design compared to
the previous series [1]. This enables more flexibility and granularity
of access control with file paths. It is now possible to enforce an
access control according to a file hierarchy. Landlock uses the concept
of inode and path to identify such hierarchy. In a way, it brings tools
to program what is a file hierarchy.

There is now three types of Landlock hooks: FS_WALK, FS_PICK and FS_GET.
Each of them accepts a dedicated eBPF program, called a Landlock
program.  They can be chained to enforce a full access control according
to a list of directories or files. The set of actions on a file is well
defined (e.g. read, write, ioctl, append, lock, mount...) taking
inspiration from the major Linux LSMs and some other access-controls
like Capsicum.  These program types are designed to be cache-friendly,
which give room for optimizations in the future.

The documentation patch contains some kernel documentation and
explanations on how to use Landlock.  The compiled documentation and
a talk I gave at FOSDEM can be found here: https://landlock.io
This patch series can be found in the branch landlock-v8 in this repo:
https://github.com/landlock-lsm/linux

There is still some minor issues with this patch series but it should
demonstrate how powerful this design may be. One of these issues is that
it is not a stackable LSM anymore, but the infrastructure management of
security blobs should allow to stack it with other LSM [4].

This is the first step of the roadmap discussed at LPC [2].  While the
intended final goal is to allow unprivileged users to use Landlock, this
series allows only a process with global CAP_SYS_ADMIN to load and
enforce a rule.  This may help to get feedback and avoid unexpected
behaviors.

This series can be applied on top of bpf-next, commit 7d72637eb39f
("Merge branch 'x86-jit'").  This can be tested with
CONFIG_SECCOMP_FILTER and CONFIG_SECURITY_LANDLOCK.  I would really
appreciate constructive comments on the design and the code.


# Landlock LSM

The goal of this new Linux Security Module (LSM) called Landlock is to
allow any process, including unprivileged ones, to create powerful
security sandboxes comparable to XNU Sandbox or OpenBSD Pledge. This
kind of sandbox is expected to help mitigate the security impact of bugs
or unexpected/malicious behaviors in user-space applications.

The approach taken is to add the minimum amount of code while still
allowing the user-space application to create quite complex access
rules.  A dedicated security policy language such as the one used by
SELinux, AppArmor and other major LSMs involves a lot of code and is
usually permitted to only a trusted user (i.e. root).  On the contrary,
eBPF programs already exist and are designed to be safely loaded by
unprivileged user-space.

This design does not seem too intrusive but is flexible enough to allow
a powerful sandbox mechanism accessible by any process on Linux. The use
of seccomp and Landlock is more suitable with the help of a user-space
library (e.g.  libseccomp) that could help to specify a high-level
language to express a security policy instead of raw eBPF programs.
Moreover, thanks to the LLVM front-end, it is quite easy to write an
eBPF program with a subset of the C language.


# Frequently asked questions

## Why is seccomp-bpf not enough?

A seccomp filter can access only raw syscall arguments (i.e. the
register values) which means that it is not possible to filter according
to the value pointed to by an argument, such as a file pathname. As an
embryonic Landlock version demonstrated, filtering at the syscall level
is complicated (e.g. need to take care of race conditions). This is
mainly because the access control checkpoints of the kernel are not at
this high-level but more underneath, at the LSM-hook level. The LSM
hooks are designed to handle this kind of checks.  Landlock abstracts
this approach to leverage the ability of unprivileged users to limit
themselves.

Cf. section "What it isn't?" in Documentation/prctl/seccomp_filter.txt


## Why use the seccomp(2) syscall?

Landlock use the same semantic as seccomp to apply access rule
restrictions. It add a new layer of security for the current process
which is inherited by its children. It makes sense to use an unique
access-restricting syscall (that should be allowed by seccomp filters)
which can only drop privileges. Moreover, a Landlock rule could come
from outside a process (e.g.  passed through a UNIX socket). It is then
useful to differentiate the creation/load of Landlock eBPF programs via
bpf(2), from rule enforcement via seccomp(2).


## Why a new LSM? Are SELinux, AppArmor, Smack and Tomoyo not good
   enough?

The current access control LSMs are fine for their purpose which is to
give the *root* the ability to enforce a security policy for the
*system*. What is missing is a way to enforce a security policy for any
application by its developer and 

[PATCH bpf-next v8 03/11] bpf: Add eBPF program subtype and is_valid_subtype() verifier

[Mickaël Salaün]

The goal of the program subtype is to be able to have different static
fine-grained verifications for a unique program type.

The struct bpf_verifier_ops gets a new optional function:
is_valid_subtype(). This new verifier is called at the beginning of the
eBPF program verification to check if the (optional) program subtype is
valid.

The struct bpf_prog_ops gets a new optional function: put_extra(). This
may be used to put extra data.

For now, only Landlock eBPF programs are using a program subtype (see
next commits) but this could be used by other program types in the
future.

Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: David S. Miller 
Link: https://lkml.kernel.org/r/20160827205559.ga43...@ast-mbp.thefacebook.com
---

Changes since v7:
* rename LANDLOCK_SUBTYPE_* to LANDLOCK_*
* move subtype in bpf_prog_aux and use only one bit for has_subtype
  (suggested by Alexei Starovoitov)
* wrap the prog_subtype with a prog_extra to be able to reference kernel
  pointers:
  * add an optional put_extra() function to struct bpf_prog_ops to be
able to free the pointed data
  * replace all the prog_subtype with prog_extra in the struct
bpf_verifier_ops functions
* remove the ABI field (requested by Alexei Starovoitov)
* rename subtype fields

Changes since v6:
* rename Landlock version to ABI to better reflect its purpose
* fix unsigned integer checks
* fix pointer cast
* constify pointers
* rebase

Changes since v5:
* use a prog_subtype pointer and make it future-proof
* add subtype test
* constify bpf_load_program()'s subtype argument
* cleanup subtype initialization
* rebase

Changes since v4:
* replace the "status" field with "version" (more generic)
* replace the "access" field with "ability" (less confusing)

Changes since v3:
* remove the "origin" field
* add an "option" field
* cleanup comments
---
 include/linux/bpf.h | 17 ++-
 include/uapi/linux/bpf.h| 11 +
 kernel/bpf/cgroup.c |  6 ++-
 kernel/bpf/core.c   |  5 +-
 kernel/bpf/syscall.c| 35 -
 kernel/bpf/verifier.c   | 19 ++--
 kernel/trace/bpf_trace.c| 15 --
 net/core/filter.c   | 76 ++---
 samples/bpf/bpf_load.c  |  3 +-
 samples/bpf/cookie_uid_helper_example.c |  2 +-
 samples/bpf/fds_example.c   |  2 +-
 samples/bpf/sock_example.c  |  3 +-
 samples/bpf/test_cgrp2_attach.c |  2 +-
 samples/bpf/test_cgrp2_attach2.c|  4 +-
 samples/bpf/test_cgrp2_sock.c   |  2 +-
 tools/include/uapi/linux/bpf.h  | 11 +
 tools/lib/bpf/bpf.c | 15 --
 tools/lib/bpf/bpf.h |  8 +--
 tools/lib/bpf/libbpf.c  |  5 +-
 tools/perf/tests/bpf.c  |  2 +-
 tools/testing/selftests/bpf/test_align.c|  2 +-
 tools/testing/selftests/bpf/test_tag.c  |  2 +-
 tools/testing/selftests/bpf/test_verifier.c | 18 ++-
 23 files changed, 200 insertions(+), 65 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 66df387106de..377b2f3519f3 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -200,26 +200,38 @@ bpf_ctx_record_field_size(struct bpf_insn_access_aux 
*aux, u32 size)
aux->ctx_field_size = size;
 }
 
+/* specific data per program type */
+struct bpf_prog_extra {
+   union bpf_prog_subtype subtype;
+   union {
+   struct bpf_prog *previous;
+   } landlock_hook;
+};
+
 struct bpf_prog_ops {
int (*test_run)(struct bpf_prog *prog, const union bpf_attr *kattr,
union bpf_attr __user *uattr);
+   void (*put_extra)(struct bpf_prog_extra *prog_extra);
 };
 
 struct bpf_verifier_ops {
/* return eBPF function prototype for verification */
-   const struct bpf_func_proto *(*get_func_proto)(enum bpf_func_id 
func_id);
+   const struct bpf_func_proto *(*get_func_proto)(enum bpf_func_id func_id,
+ const struct bpf_prog_extra *prog_extra);
 
/* return true if 'size' wide access at offset 'off' within bpf_context
 * with 'type' (read or write) is allowed
 */
bool (*is_valid_access)(int off, int size, enum bpf_access_type type,
-   struct bpf_insn_access_aux *info);
+   struct bpf_insn_access_aux *info,
+   const struct bpf_prog_extra *prog_extra);
int (*gen_prologue)(struct bpf_insn *insn, bool direct_write,
const struct bpf_prog *prog);
u32 (*convert_ctx_access)(enum bpf_access_type type,
  const struct bpf_insn 

[PATCH bpf-next v8 03/11] bpf: Add eBPF program subtype and is_valid_subtype() verifier

[Mickaël Salaün]

The goal of the program subtype is to be able to have different static
fine-grained verifications for a unique program type.

The struct bpf_verifier_ops gets a new optional function:
is_valid_subtype(). This new verifier is called at the beginning of the
eBPF program verification to check if the (optional) program subtype is
valid.

The struct bpf_prog_ops gets a new optional function: put_extra(). This
may be used to put extra data.

For now, only Landlock eBPF programs are using a program subtype (see
next commits) but this could be used by other program types in the
future.

Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: David S. Miller 
Link: https://lkml.kernel.org/r/20160827205559.ga43...@ast-mbp.thefacebook.com
---

Changes since v7:
* rename LANDLOCK_SUBTYPE_* to LANDLOCK_*
* move subtype in bpf_prog_aux and use only one bit for has_subtype
  (suggested by Alexei Starovoitov)
* wrap the prog_subtype with a prog_extra to be able to reference kernel
  pointers:
  * add an optional put_extra() function to struct bpf_prog_ops to be
able to free the pointed data
  * replace all the prog_subtype with prog_extra in the struct
bpf_verifier_ops functions
* remove the ABI field (requested by Alexei Starovoitov)
* rename subtype fields

Changes since v6:
* rename Landlock version to ABI to better reflect its purpose
* fix unsigned integer checks
* fix pointer cast
* constify pointers
* rebase

Changes since v5:
* use a prog_subtype pointer and make it future-proof
* add subtype test
* constify bpf_load_program()'s subtype argument
* cleanup subtype initialization
* rebase

Changes since v4:
* replace the "status" field with "version" (more generic)
* replace the "access" field with "ability" (less confusing)

Changes since v3:
* remove the "origin" field
* add an "option" field
* cleanup comments
---
 include/linux/bpf.h | 17 ++-
 include/uapi/linux/bpf.h| 11 +
 kernel/bpf/cgroup.c |  6 ++-
 kernel/bpf/core.c   |  5 +-
 kernel/bpf/syscall.c| 35 -
 kernel/bpf/verifier.c   | 19 ++--
 kernel/trace/bpf_trace.c| 15 --
 net/core/filter.c   | 76 ++---
 samples/bpf/bpf_load.c  |  3 +-
 samples/bpf/cookie_uid_helper_example.c |  2 +-
 samples/bpf/fds_example.c   |  2 +-
 samples/bpf/sock_example.c  |  3 +-
 samples/bpf/test_cgrp2_attach.c |  2 +-
 samples/bpf/test_cgrp2_attach2.c|  4 +-
 samples/bpf/test_cgrp2_sock.c   |  2 +-
 tools/include/uapi/linux/bpf.h  | 11 +
 tools/lib/bpf/bpf.c | 15 --
 tools/lib/bpf/bpf.h |  8 +--
 tools/lib/bpf/libbpf.c  |  5 +-
 tools/perf/tests/bpf.c  |  2 +-
 tools/testing/selftests/bpf/test_align.c|  2 +-
 tools/testing/selftests/bpf/test_tag.c  |  2 +-
 tools/testing/selftests/bpf/test_verifier.c | 18 ++-
 23 files changed, 200 insertions(+), 65 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 66df387106de..377b2f3519f3 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -200,26 +200,38 @@ bpf_ctx_record_field_size(struct bpf_insn_access_aux 
*aux, u32 size)
aux->ctx_field_size = size;
 }
 
+/* specific data per program type */
+struct bpf_prog_extra {
+   union bpf_prog_subtype subtype;
+   union {
+   struct bpf_prog *previous;
+   } landlock_hook;
+};
+
 struct bpf_prog_ops {
int (*test_run)(struct bpf_prog *prog, const union bpf_attr *kattr,
union bpf_attr __user *uattr);
+   void (*put_extra)(struct bpf_prog_extra *prog_extra);
 };
 
 struct bpf_verifier_ops {
/* return eBPF function prototype for verification */
-   const struct bpf_func_proto *(*get_func_proto)(enum bpf_func_id 
func_id);
+   const struct bpf_func_proto *(*get_func_proto)(enum bpf_func_id func_id,
+ const struct bpf_prog_extra *prog_extra);
 
/* return true if 'size' wide access at offset 'off' within bpf_context
 * with 'type' (read or write) is allowed
 */
bool (*is_valid_access)(int off, int size, enum bpf_access_type type,
-   struct bpf_insn_access_aux *info);
+   struct bpf_insn_access_aux *info,
+   const struct bpf_prog_extra *prog_extra);
int (*gen_prologue)(struct bpf_insn *insn, bool direct_write,
const struct bpf_prog *prog);
u32 (*convert_ctx_access)(enum bpf_access_type type,
  const struct bpf_insn *src,
  struct bpf_insn *dst,

[PATCH bpf-next v8 04/11] bpf,landlock: Define an eBPF program type for Landlock hooks

[Mickaël Salaün]

Add a new type of eBPF program used by Landlock hooks. This type of
program can be chained with the same eBPF program type (according to
subtype rules). A state can be kept with a value available in the
program's context (e.g. named "cookie" for Landlock programs).

This new BPF program type will be registered with the Landlock LSM
initialization.

Add an initial Landlock Kconfig and update the MAINTAINERS file.

Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Andy Lutomirski 
Cc: Daniel Borkmann 
Cc: David S. Miller 
Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
---

Changes since v7:
* cosmetic fixes
* rename LANDLOCK_SUBTYPE_* to LANDLOCK_*
* cleanup UAPI definitions and move them from bpf.h to landlock.h
  (suggested by Alexei Starovoitov)
* disable Landlock by default (suggested by Alexei Starovoitov)
* rename BPF_PROG_TYPE_LANDLOCK_{RULE,HOOK}
* update the Kconfig
* update the MAINTAINERS file
* replace the IOCTL, LOCK and FCNTL events with FS_PICK, FS_WALK and
  FS_GET hook types
* add the ability to chain programs with an eBPF program file descriptor
  (i.e. the "previous" field in a Landlock subtype) and keep a state
  with a "cookie" value available from the context
* add a "triggers" subtype bitfield to match specific actions (e.g.
  append, chdir, read...)

Changes since v6:
* add 3 more sub-events: IOCTL, LOCK, FCNTL
  https://lkml.kernel.org/r/2fbc99a6-f190-f335-bd14-04bdeed35...@digikod.net
* rename LANDLOCK_VERSION to LANDLOCK_ABI to better reflect its purpose,
  and move it from landlock.h to common.h
* rename BPF_PROG_TYPE_LANDLOCK to BPF_PROG_TYPE_LANDLOCK_RULE: an eBPF
  program could be used for something else than a rule
* simplify struct landlock_context by removing the arch and syscall_nr fields
* remove all eBPF map functions call, remove ABILITY_WRITE
* refactor bpf_landlock_func_proto() (suggested by Kees Cook)
* constify pointers
* fix doc inclusion

Changes since v5:
* rename file hooks.c to init.c
* fix spelling

Changes since v4:
* merge a minimal (not enabled) LSM code and Kconfig in this commit

Changes since v3:
* split commit
* revamp the landlock_context:
  * add arch, syscall_nr and syscall_cmd (ioctl, fcntl…) to be able to
cross-check action with the event type
  * replace args array with dedicated fields to ease the addition of new
fields
---
 MAINTAINERS |  13 +++
 include/linux/bpf_types.h   |   3 +
 include/uapi/linux/bpf.h|   1 +
 include/uapi/linux/landlock.h   | 155 +++
 security/Kconfig|   1 +
 security/Makefile   |   2 +
 security/landlock/Kconfig   |  18 
 security/landlock/Makefile  |   3 +
 security/landlock/common.h  |  32 +++
 security/landlock/init.c| 180 
 tools/include/uapi/linux/bpf.h  |   1 +
 tools/include/uapi/linux/landlock.h | 155 +++
 12 files changed, 564 insertions(+)
 create mode 100644 include/uapi/linux/landlock.h
 create mode 100644 security/landlock/Kconfig
 create mode 100644 security/landlock/Makefile
 create mode 100644 security/landlock/common.h
 create mode 100644 security/landlock/init.c
 create mode 100644 tools/include/uapi/linux/landlock.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 3bdc260e36b7..ac0809094bae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7882,6 +7882,19 @@ S:   Maintained
 F: net/l3mdev
 F: include/net/l3mdev.h
 
+LANDLOCK SECURITY MODULE
+M: Mickaël Salaün 
+S: Supported
+F: Documentation/security/landlock/
+F: include/linux/landlock.h
+F: include/uapi/linux/landlock.h
+F: samples/bpf/landlock*
+F: security/landlock/
+F: tools/include/uapi/linux/landlock.h
+F: tools/testing/selftests/landlock/
+K: landlock
+K: LANDLOCK
+
 LANTIQ MIPS ARCHITECTURE
 M: John Crispin 
 L: linux-m...@linux-mips.org
diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
index 19b8349a3809..0ca019f3ae4a 100644
--- a/include/linux/bpf_types.h
+++ b/include/linux/bpf_types.h
@@ -22,6 +22,9 @@ BPF_PROG_TYPE(BPF_PROG_TYPE_PERF_EVENT, perf_event)
 #ifdef CONFIG_CGROUP_BPF
 BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_DEVICE, cg_dev)
 #endif
+#ifdef CONFIG_SECURITY_LANDLOCK
+BPF_PROG_TYPE(BPF_PROG_TYPE_LANDLOCK_HOOK, landlock)
+#endif
 
 BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY, array_map_ops)
 BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_ARRAY, percpu_array_map_ops)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 87885c92ca78..2433aa1a0fd4 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -133,6 +133,7 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SOCK_OPS,
BPF_PROG_TYPE_SK_SKB,

[PATCH bpf-next v8 04/11] bpf,landlock: Define an eBPF program type for Landlock hooks

[Mickaël Salaün]

Add a new type of eBPF program used by Landlock hooks. This type of
program can be chained with the same eBPF program type (according to
subtype rules). A state can be kept with a value available in the
program's context (e.g. named "cookie" for Landlock programs).

This new BPF program type will be registered with the Landlock LSM
initialization.

Add an initial Landlock Kconfig and update the MAINTAINERS file.

Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Andy Lutomirski 
Cc: Daniel Borkmann 
Cc: David S. Miller 
Cc: James Morris 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
---

Changes since v7:
* cosmetic fixes
* rename LANDLOCK_SUBTYPE_* to LANDLOCK_*
* cleanup UAPI definitions and move them from bpf.h to landlock.h
  (suggested by Alexei Starovoitov)
* disable Landlock by default (suggested by Alexei Starovoitov)
* rename BPF_PROG_TYPE_LANDLOCK_{RULE,HOOK}
* update the Kconfig
* update the MAINTAINERS file
* replace the IOCTL, LOCK and FCNTL events with FS_PICK, FS_WALK and
  FS_GET hook types
* add the ability to chain programs with an eBPF program file descriptor
  (i.e. the "previous" field in a Landlock subtype) and keep a state
  with a "cookie" value available from the context
* add a "triggers" subtype bitfield to match specific actions (e.g.
  append, chdir, read...)

Changes since v6:
* add 3 more sub-events: IOCTL, LOCK, FCNTL
  https://lkml.kernel.org/r/2fbc99a6-f190-f335-bd14-04bdeed35...@digikod.net
* rename LANDLOCK_VERSION to LANDLOCK_ABI to better reflect its purpose,
  and move it from landlock.h to common.h
* rename BPF_PROG_TYPE_LANDLOCK to BPF_PROG_TYPE_LANDLOCK_RULE: an eBPF
  program could be used for something else than a rule
* simplify struct landlock_context by removing the arch and syscall_nr fields
* remove all eBPF map functions call, remove ABILITY_WRITE
* refactor bpf_landlock_func_proto() (suggested by Kees Cook)
* constify pointers
* fix doc inclusion

Changes since v5:
* rename file hooks.c to init.c
* fix spelling

Changes since v4:
* merge a minimal (not enabled) LSM code and Kconfig in this commit

Changes since v3:
* split commit
* revamp the landlock_context:
  * add arch, syscall_nr and syscall_cmd (ioctl, fcntl…) to be able to
cross-check action with the event type
  * replace args array with dedicated fields to ease the addition of new
fields
---
 MAINTAINERS |  13 +++
 include/linux/bpf_types.h   |   3 +
 include/uapi/linux/bpf.h|   1 +
 include/uapi/linux/landlock.h   | 155 +++
 security/Kconfig|   1 +
 security/Makefile   |   2 +
 security/landlock/Kconfig   |  18 
 security/landlock/Makefile  |   3 +
 security/landlock/common.h  |  32 +++
 security/landlock/init.c| 180 
 tools/include/uapi/linux/bpf.h  |   1 +
 tools/include/uapi/linux/landlock.h | 155 +++
 12 files changed, 564 insertions(+)
 create mode 100644 include/uapi/linux/landlock.h
 create mode 100644 security/landlock/Kconfig
 create mode 100644 security/landlock/Makefile
 create mode 100644 security/landlock/common.h
 create mode 100644 security/landlock/init.c
 create mode 100644 tools/include/uapi/linux/landlock.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 3bdc260e36b7..ac0809094bae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7882,6 +7882,19 @@ S:   Maintained
 F: net/l3mdev
 F: include/net/l3mdev.h
 
+LANDLOCK SECURITY MODULE
+M: Mickaël Salaün 
+S: Supported
+F: Documentation/security/landlock/
+F: include/linux/landlock.h
+F: include/uapi/linux/landlock.h
+F: samples/bpf/landlock*
+F: security/landlock/
+F: tools/include/uapi/linux/landlock.h
+F: tools/testing/selftests/landlock/
+K: landlock
+K: LANDLOCK
+
 LANTIQ MIPS ARCHITECTURE
 M: John Crispin 
 L: linux-m...@linux-mips.org
diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
index 19b8349a3809..0ca019f3ae4a 100644
--- a/include/linux/bpf_types.h
+++ b/include/linux/bpf_types.h
@@ -22,6 +22,9 @@ BPF_PROG_TYPE(BPF_PROG_TYPE_PERF_EVENT, perf_event)
 #ifdef CONFIG_CGROUP_BPF
 BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_DEVICE, cg_dev)
 #endif
+#ifdef CONFIG_SECURITY_LANDLOCK
+BPF_PROG_TYPE(BPF_PROG_TYPE_LANDLOCK_HOOK, landlock)
+#endif
 
 BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY, array_map_ops)
 BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_ARRAY, percpu_array_map_ops)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 87885c92ca78..2433aa1a0fd4 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -133,6 +133,7 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SOCK_OPS,
BPF_PROG_TYPE_SK_SKB,
BPF_PROG_TYPE_CGROUP_DEVICE,
+   BPF_PROG_TYPE_LANDLOCK_HOOK,
 };
 
 enum bpf_attach_type {
diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
new file mode 100644
index