Re: [PATCH v4] netlink: Fix autobind race condition that leads to zero port ID

[David Miller]

From: Herbert Xu 
Date: Fri, 18 Sep 2015 19:16:50 +0800

> The commit c0bb07df7d981e4091432754e30c9c720e2c0c78 ("netlink:
> Reset portid after netlink_insert failure") introduced a race
> condition where if two threads try to autobind the same socket
> one of them may end up with a zero port ID.  This led to kernel
> deadlocks that were observed by multiple people.
> 
> This patch reverts that commit and instead fixes it by introducing
> a separte rhash_portid variable so that the real portid is only set
> after the socket has been successfully hashed.
> 
> Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
> Reported-by: Tejun Heo 
> Reported-by: Linus Torvalds 
> Signed-off-by: Herbert Xu 

Applied and queued up for -stable, thanks Herbert.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[Juergen Gross]

On 09/15/2015 06:50 PM, Dario Faggioli wrote:

On Thu, 2015-08-20 at 20:16 +0200, Juergen Groß wrote:

On 08/18/2015 05:55 PM, Dario Faggioli wrote:

Hey everyone,

So, as a followup of what we were discussing in this thread:

   [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest
   http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03241.html

I started looking in more details at scheduling domains in the Linux
kernel. Now, that thread was about CPUID and vNUMA, and their weird way
of interacting, while this thing I'm proposing here is completely
independent from them both.

In fact, no matter whether vNUMA is supported and enabled, and no matter
whether CPUID is reporting accurate, random, meaningful or completely
misleading information, I think that we should do something about how
scheduling domains are build.

Fact is, unless we use 1:1, and immutable (across all the guest
lifetime) pinning, scheduling domains should not be constructed, in
Linux, by looking at *any* topology information, because that just does
not make any sense, when vcpus move around.

Let me state this again (hoping to make myself as clear as possible): no
matter in  how much good shape we put CPUID support, no matter how
beautifully and consistently that will interact with both vNUMA,
licensing requirements and whatever else. It will be always possible for
vCPU #0 and vCPU #3 to be scheduled on two SMT threads at time t1, and
on two different NUMA nodes at time t2. Hence, the Linux scheduler
should really not skew his load balancing logic toward any of those two
situations, as neither of them could be considered correct (since
nothing is!).

For now, this only covers the PV case. HVM case shouldn't be any
different, but I haven't looked at how to make the same thing happen in
there as well.

OVERALL DESCRIPTION
===
What this RFC patch does is, in the Xen PV case, configure scheduling
domains in such a way that there is only one of them, spanning all the
pCPUs of the guest.

Note that the patch deals directly with scheduling domains, and there is
no need to alter the masks that will then be used for building and
reporting the topology (via CPUID, /proc/cpuinfo, /sysfs, etc.). That is
the main difference between it and the patch proposed by Juergen here:
http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg05088.html

This means that when, in future, we will fix CPUID handling and make it
comply with whatever logic or requirements we want, that won't have  any
unexpected side effects on scheduling domains.

Information about how the scheduling domains are being constructed
during boot are available in `dmesg', if the kernel is booted with the
'sched_debug' parameter. It is also possible to look
at /proc/sys/kernel/sched_domain/cpu*, and at /proc/schedstat.

With the patch applied, only one scheduling domain is created, called
the 'VCPU' domain, spanning all the guest's (or Dom0's) vCPUs. You can
tell that from the fact that every cpu* folder
in /proc/sys/kernel/sched_domain/ only have one subdirectory
('domain0'), with all the tweaks and the tunables for our scheduling
domain.

EVALUATION
==
I've tested this with UnixBench, and by looking at Xen build time, on a
16, 24 and 48 pCPUs hosts. I've run the benchmarks in Dom0 only, for
now, but I plan to re-run them in DomUs soon (Juergen may be doing
something similar to this in DomU already, AFAUI).

I've run the benchmarks with and without the patch applied ('patched'
and 'vanilla', respectively, in the tables below), and with different
number of build jobs (in case of the Xen build) or of parallel copy of
the benchmarks (in the case of UnixBench).

What I get from the numbers is that the patch almost always brings
benefits, in some cases even huge ones. There are a couple of cases
where we regress, but always only slightly so, especially if comparing
that to the magnitude of some of the improvement that we get.

Bear also in mind that these results are gathered from Dom0, and without
any overcommitment at the vCPU level (i.e., nr. vCPUs == nr pCPUs). If
we move things in DomU and do overcommit at the Xen scheduler level, I
am expecting even better results.


...

REQUEST FOR COMMENTS

Basically, the kind of feedback I'd be really glad to hear is:
   - what you guys thing of the approach,


Yesterday at the end of the developer meeting we (Andrew, Elena and
myself) discussed this topic again.


Hey,

Sorry for replying so late, I've been on vacation from right after
XenSummit up until yesterday. :-)


Regarding a possible future scenario with credit2 eventually supporting
gang scheduling on hyperthreads (which is desirable due to security
reasons [side channel attack] and fairness) my patch seems to be more
suited for that direction than yours.


Ok. Just let me mention that 'Credit2 + gang scheduling' might not be
exactly around the corner (although, we can prioritize working on it if
we want).

In 

Re: include/linux/kvm_host.h:488 suspicious rcu_dereference_check() usage!

[Paolo Bonzini]

On 20/09/2015 18:48, Borislav Petkov wrote:
> [26421.584526] walk_shadow_page_get_mmio_spte: detect reserved bits on spte, 
> addr 0xb8000, dump hierarchy:
> [26421.593927] -- spte 0x3e5a22027 level 4.
> [26421.598228] -- spte 0x38a00b027 level 3.
> [26421.602505] -- spte 0x387334027 level 2.
> [26421.602506] -- spte 0x000b8f67 level 1.
> [26421.602506] [ cut here ]
> [26421.602530] WARNING: CPU: 2 PID: 17000 at arch/x86/kvm/mmu.c:3385 
> handle_mmio_page_fault.part.93+0x1a/0x20 [kvm]()
> [26421.602550] Modules linked in: tun sha256_ssse3 sha256_generic drbg 
> binfmt_misc ipv6 vfat fat fuse dm_crypt dm_mod kvm_amd kvm crc32_pclmul 
> aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd 
> fam15h_power amd64_edac_mod k10temp edac_core amdkfd amd_iommu_v2 radeon 
> acpi_cpufreq
> [26421.602552] CPU: 2 PID: 17000 Comm: qemu-system-i38 Not tainted 4.3.0-rc1+ 
> #1
> [26421.602553] Hardware name: To be filled by O.E.M. To be filled by 
> O.E.M./M5A97 EVO R2.0, BIOS 1503 01/16/2013
> [26421.602555]  a02fc7d2 880386c0fb80 812c8c2a 
> 
> [26421.602556]  880386c0fbb8 81053e55 880429ff8000 
> 000f
> [26421.602558]  000b8000   
> 880386c0fbc8
> [26421.602558] Call Trace:
> [26421.602564]  [] dump_stack+0x4e/0x84
> [26421.602566]  [] warn_slowpath_common+0x95/0xe0
> [26421.602567]  [] warn_slowpath_null+0x1a/0x20
> [26421.602577]  [] handle_mmio_page_fault.part.93+0x1a/0x20 
> [kvm]
> [26421.602587]  [] tdp_page_fault+0x231/0x290 [kvm]
> [26421.602596]  [] ? emulator_pio_in_out+0x6e/0xf0 [kvm]
> [26421.602606]  [] kvm_mmu_page_fault+0x36/0x240 [kvm]
> [26421.602609]  [] ? svm_set_cr0+0x95/0xc0 [kvm_amd]
> [26421.602610]  [] pf_interception+0xde/0x1d0 [kvm_amd]
> [26421.602613]  [] handle_exit+0x181/0xa70 [kvm_amd]
> [26421.602622]  [] ? kvm_arch_vcpu_ioctl_run+0x68b/0x1730 
> [kvm]
> [26421.602631]  [] kvm_arch_vcpu_ioctl_run+0x6f6/0x1730 
> [kvm]
> [26421.602640]  [] ? kvm_arch_vcpu_ioctl_run+0x68b/0x1730 
> [kvm]
> [26421.602642]  [] ? preempt_count_sub+0x9b/0xf0
> [26421.602644]  [] ? mutex_lock_killable_nested+0x26f/0x490
> [26421.602645]  [] ? preempt_count_sub+0x9b/0xf0
> [26421.602651]  [] kvm_vcpu_ioctl+0x358/0x710 [kvm]
> [26421.602654]  [] ? __fget+0x5/0x210
> [26421.602655]  [] ? __fget+0x101/0x210
> [26421.602657]  [] do_vfs_ioctl+0x2f4/0x560
> [26421.602658]  [] ? __fget_light+0x29/0x90
> [26421.602660]  [] SyS_ioctl+0x4c/0x90
> [26421.602661]  [] entry_SYSCALL_64_fastpath+0x16/0x73
> [26421.602663] ---[ end trace 37901c8686d84de6 ]---
> 
> Any ideas?

I am sending a patch for the RCU splat, for this I'll take a look later
this week.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] KVM: x86: put vcpu_create under kvm->srcu critical section

[Paolo Bonzini]

This is needed in case vcpu_create wants to access the memslots array.
Fixes this lockdep splat:

[26421.303750] ===
[26421.307952] [ INFO: suspicious RCU usage. ]
[26421.312161] 4.3.0-rc1+ #1 Not tainted
[26421.312161] ---
[26421.312162] include/linux/kvm_host.h:488 suspicious rcu_dereference_check() 
usage!
[26421.312163]
other info that might help us debug this:

[26421.312164]
rcu_scheduler_active = 1, debug_locks = 0
[26421.312165] 1 lock held by qemu-system-i38/17000:
[26421.312189]  #0:  (&(>mmu_lock)->rlock){+.+...}, at: 
[] kvm_zap_gfn_range+0x24/0x1a0 [kvm]
[26421.312189]
stack backtrace:
[26421.312191] CPU: 3 PID: 17000 Comm: qemu-system-i38 Not tainted 4.3.0-rc1+ #1
[26421.312192] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./M5A97 EVO R2.0, BIOS 1503 01/16/2013
[26421.312195]  0001 880386c0fc90 812c8c2a 
880423f0c740
[26421.312197]  880386c0fcc0 8109e60d 880429ff8000 

[26421.312199]  880386844000 8800 880386c0fd30 
a02d6c18
[26421.312199] Call Trace:
[26421.312205]  [] dump_stack+0x4e/0x84
[26421.312208]  [] lockdep_rcu_suspicious+0xfd/0x130
[26421.312223]  [] kvm_zap_gfn_range+0x188/0x1a0 [kvm]
[26421.312235]  [] kvm_set_cr0+0xde/0x1e0 [kvm]
[26421.312244]  [] init_vmcb+0x760/0xad0 [kvm_amd]
[26421.312246]  [] svm_create_vcpu+0x197/0x250 [kvm_amd]
[26421.312259]  [] kvm_arch_vcpu_create+0x47/0x70 [kvm]
[26421.312268]  [] kvm_vm_ioctl+0x302/0x7e0 [kvm]
[26421.312271]  [] ? __lock_is_held+0x51/0x70
[26421.312273]  [] ? __fget+0x101/0x210
[26421.312276]  [] do_vfs_ioctl+0x2f4/0x560
[26421.312277]  [] ? __fget_light+0x29/0x90
[26421.312279]  [] SyS_ioctl+0x4c/0x90
[26421.312282]  [] entry_SYSCALL_64_fastpath+0x16/0x73

Reported-by: Borislav Petkov 
Signed-off-by: Paolo Bonzini 
---
 arch/x86/kvm/x86.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 991466bf8dee..dab524bf326c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7064,13 +7064,16 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
unsigned int id)
 {
struct kvm_vcpu *vcpu;
+   int idx;
 
if (check_tsc_unstable() && atomic_read(>online_vcpus) != 0)
printk_once(KERN_WARNING
"kvm: SMP vm created on host with unstable TSC; "
"guest TSC will not be reliable\n");
 
+   idx = srcu_read_lock(>kvm->srcu);
vcpu = kvm_x86_ops->vcpu_create(kvm, id);
+   srcu_read_unlock(>kvm->srcu, idx);
 
return vcpu;
 }
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

[Wu, Feng]

> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, September 21, 2015 1:33 PM
> To: Wu, Feng; Alex Williamson; j...@8bytes.org; Marcelo Tosatti
> Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; KVM list;
> Eric Auger
> Subject: Re: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when
> vCPU is blocked
> 
> 
> 
> On 21/09/2015 04:16, Wu, Feng wrote:
> > I tested the above patch you suggested, it works fine. Thank you! So
> > do I need to resend a new version or you can handle it in your tree?
> 
> I will handle it.

Thanks a lot for your review on this series!

Thanks,
Feng

> 
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] macvtap: fix TUNSETSNDBUF values > 64k

[David Miller]

From: "Michael S. Tsirkin" 
Date: Fri, 18 Sep 2015 13:41:09 +0300

> Upon TUNSETSNDBUF,  macvtap reads the requested sndbuf size into
> a local variable u.
> commit 39ec7de7092b ("macvtap: fix uninitialized access on
> TUNSETIFF") changed its type to u16 (which is the right thing to
> do for all other macvtap ioctls), breaking all values > 64k.
> 
> The value of TUNSETSNDBUF is actually a signed 32 bit integer, so
> the right thing to do is to read it into an int.
> 
> Cc: David S. Miller 
> Fixes: 39ec7de7092b ("macvtap: fix uninitialized access on TUNSETIFF")
> Reported-by: Mark A. Peloquin
> Bisected-by: Matthew Rosato 
> Reported-by: Christian Borntraeger 
> Signed-off-by: Michael S. Tsirkin 

Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc 4.3] mei: hbm: fix error in state check logic

[Greg Kroah-Hartman]

On Sun, Sep 13, 2015 at 10:29:26AM +0300, Tomas Winkler wrote:
> From: Alexander Usyskin 
> 
> Use || instead && in state check.
> Latter is bogus and leads to following warning:
> 
> drivers/misc/mei/hbm.c:1212:46: warning: logical ‘and’ of mutually exclusive 
> tests is always false [-Wlogical-op]
> 
> Fixes: 073e6274 ("mei: support for dynamic clients")

This isn't a commit id in Linus's tree anywhere, where did you get that
number from?  Please fix it and use a valid one.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 000/102] 4.1.8-stable review

[Sudip Mukherjee]

On Sat, Sep 19, 2015 at 10:27:12AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.1.8 release.
> There are 102 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 Mon Sep 21 17:15:55 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> @@ -61,7 +61,8 @@ static struct crypto_alg alg = {
>   .cra_module = THIS_MODULE,
>   .cra_u  = { .compress = {
>   .coa_compress   = crypto842_compress,
> - .coa_decompress = crypto842_decompress } }
> + .coa_decompress = crypto842_decompress,
> + .coa_decompress_noctx   = NULL } }
>  };
>  
>  static int __init crypto842_mod_init(void)
> diff --git a/crypto/compress.c b/crypto/compress.c
> index c33f076..abb36a8 100644
> --- a/crypto/compress.c
> +++ b/crypto/compress.c
> @@ -33,12 +33,21 @@ static int crypto_decompress(struct crypto_tfm *tfm,
>  dlen);
>  }
>  
> +static int crypto_decompress_noctx(struct crypto_tfm *tfm,
> + const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen)
> +{
> + return tfm->__crt_alg->cra_compress.coa_decompress_noctx(src, slen,
> + dst, dlen);
> +}


hm... well... sorry, if irrelevant.
if the algorithm can have a _noctx() decompression function, does it
automatically guarantee that this algorithm never dereferences a passed
`struct crypto_tfm *tfm' pointer in its decompress function? in other words,
can we simply pass that `shared tfm pointer' to the existing decompress
function instead of defining new symbols, new callbacks, etc.?

cot_decompress_noctx()  ==  cot_decompress(shared_ftm) ?

just a thought.

[..]
> +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name,
> + u32 type, u32 mask)
> +{
> + struct crypto_comp *comp;
> + struct crypto_tfm *tfm;
> + struct compress_tfm *ops;
> +
> + comp = crypto_alloc_comp(alg_name, type, mask);
> + if (IS_ERR(comp))
> + return comp;
> +
> + tfm = crypto_comp_tfm(comp);
> + if (!tfm->__crt_alg->cra_compress.coa_decompress_noctx) {
> + crypto_free_comp(comp);
> + return ERR_PTR(-EINVAL);

-ENOMEM?

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.2 000/120] 4.2.1-stable review

[Greg Kroah-Hartman]

On Mon, Sep 21, 2015 at 10:40:42AM +0530, Sudip Mukherjee wrote:
> On Sat, Sep 19, 2015 at 10:27:20AM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.2.1 release.
> > There are 120 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 Mon Sep 21 17:15:44 UTC 2015.
> > Anything received after that time might be too late.
> Compiled and booted on x86_32. No errors in dmesg.

Great, thanks for testing and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] drivers/misc/sgi-gru: add return on error

[Greg Kroah-Hartman]

On Mon, Sep 21, 2015 at 11:04:10AM +0530, Sudip Mukherjee wrote:
> On Sun, Sep 20, 2015 at 07:26:29PM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Sep 15, 2015 at 01:20:41PM +0530, Sudip Mukherjee wrote:
> > > On Thu, Sep 03, 2015 at 01:21:38PM -0500, Dimitri Sivanich wrote:
> > > > Acked-by: Dimitri Sivanich 
> > > > 
> > > > On Thu, Sep 03, 2015 at 08:20:47PM +0530, Sudip Mukherjee wrote:
> > > > > If the buffer is too small then return the error and in the process
> > > > > remove the variables which became unused.
> > > > > 
> > > > > Signed-off-by: Sudip Mukherjee 
> > > > > ---
> > > Hi Greg,
> > > I know its too early to ping you but just wanted to know that this
> > > should go through your char-misc tree or through Andrew.
> > > Looking at all the previous patches, it all went through Andrew but
> > > being a char/misc I thought it will go through you.
> > 
> > I'll take it, thanks.
> Thanks. But just to let you know that getmaintainer.pl is not showing
> your and Arnd's name. But MAINTAINER shows drivers/misc/* for you and
> Arnd. And besides I noticed there are one or two patches still lying
> around with maintainer ACK but never picked up as they didnot have you
> or Andrew in the To or CC list.

That's odd, care to forward them on to me?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] misc: mcp4xxx_dpot: Driver for Microchip digital potentiometers

[Greg Kroah-Hartman]

On Mon, Aug 31, 2015 at 10:08:08PM +0200, p...@lysator.liu.se wrote:
> From: Peter Rosin 
> 
> Signed-off-by: Peter Rosin 

A whole new driver with exactly no changelog description at all?  I
can't take that :(

> ---
>  Documentation/misc-devices/mcp4xxx_dpot.txt |   47 +
>  MAINTAINERS |5 +
>  drivers/misc/Kconfig|   15 ++
>  drivers/misc/Makefile   |1 +
>  drivers/misc/mcp4xxx_dpot.c |  269 
> +++
>  drivers/misc/mcp4xxx_dpot.h |   44 +
>  6 files changed, 381 insertions(+)
>  create mode 100644 Documentation/misc-devices/mcp4xxx_dpot.txt
>  create mode 100644 drivers/misc/mcp4xxx_dpot.c
>  create mode 100644 drivers/misc/mcp4xxx_dpot.h
> 
> This patch has two checkpatch errors but I really don't know how to fix them.
> The offending code was copied from drivers/misc/ad525x_dpot.c and the errors
> are:
> 
> ERROR: Macros with complex values should be enclosed in parentheses
> #266: FILE: drivers/misc/mcp4xxx_dpot.c:129:
> +#define MCP4XXX_DPOT_DEVICE_SHOW_SET(name, reg) \
> +MCP4XXX_DPOT_DEVICE_SHOW(name, reg) \
> +MCP4XXX_DPOT_DEVICE_SET(name, reg) \
> +static DEVICE_ATTR(name, S_IWUSR | S_IRUGO, show_##name, set_##name)
> 
> ERROR: Macros with complex values should be enclosed in parentheses
> #271: FILE: drivers/misc/mcp4xxx_dpot.c:134:
> +#define MCP4XXX_DPOT_DEVICE_SHOW_ONLY(name, reg) \
> +MCP4XXX_DPOT_DEVICE_SHOW(name, reg) \
> +static DEVICE_ATTR(name, S_IWUSR | S_IRUGO, show_##name, NULL)
> 
> I have tried to add various parentheses, but no luck.
> 
> I am also unsure if I have modelled this on deprecated stuff. Is
> there a better place to add a digital potentiometer driver?
> 
> Industrial IO perhaps? In any case, this is a sufficient implementation
> for my needs, and a more complex user-space api is only going to be a
> burden.
> 
> Cheers,
> Peter
> 
> diff --git a/Documentation/misc-devices/mcp4xxx_dpot.txt 
> b/Documentation/misc-devices/mcp4xxx_dpot.txt
> new file mode 100644
> index ..10ed02958775
> --- /dev/null
> +++ b/Documentation/misc-devices/mcp4xxx_dpot.txt
> @@ -0,0 +1,47 @@
> +-
> +  MCP4XXX Digital Potentiometers
> +-
> +
> +The mcp4xxx_dpot driver exports a simple sysfs interface.  This allows you to
> +work with the immediate resistance settings.

sysfs files all need to be documented in Documentation/ABI/ not in
random Documentation files :)

Also, why isn't this just an IIO driver?  Creating one-off sysfs files
for each driver is a path to madness, please work on using standard
interfaces if at all possible.

> +-
> +  Files
> +-
> +
> +Each dpot device will have its own rdac files.  How many depends on the 
> actual
> +part you have, as will the range of allowed values.
> +
> +This rdac file is used to program the immediate value of the device.
> +
> +---
> +  Example
> +---
> +
> +Locate the device in your sysfs tree.  This is probably easiest by going into
> +the common i2c directory and locating the device by the i2c slave address.
> +
> + # ls /sys/bus/i2c/devices/
> + 0-0028  0-0050
> +
> +So assuming the device in question is on the first i2c bus and has the slave
> +address of 0x28, we descend (unrelated sysfs entries have been trimmed).
> +
> + # ls /sys/bus/i2c/devices/0-0028/
> + rdac0 rdac1
> +
> +You can use simple reads/writes to access these files:
> +
> + # cd /sys/bus/i2c/devices/0-0028/
> +
> + # cat rdac0
> + 0
> + # echo 128 > rdac0
> + # cat rdac0
> + 128
> +
> + # cat rdac1
> + 5
> + # echo 35 > rdac1
> + # cat rdac1
> + 35

You never say what the contents of these files really are.  Nor what the
units are, if any, or what this driver even does or is used for.  For
all I know it just is a sysfs file value storage driver :)

> diff --git a/MAINTAINERS b/MAINTAINERS
> index b60e2b2369d2..c7bc2cc8051d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6600,6 +6600,11 @@ W: http://linuxtv.org
>  S:   Maintained
>  F:   drivers/media/radio/radio-maxiradio*
>  
> +MPC4XXX MICROCHIP DIGITAL POTENTIOMETERS DRIVER
> +M:   Peter Rosin 
> +S:   Maintained
> +F:   drivers/misc/mcp4xxx_dpot.*
> +
>  MEDIA DRIVERS FOR RENESAS - VSP1
>  M:   Laurent Pinchart 
>  L:   linux-me...@vger.kernel.org
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 42c38525904b..a4e5e42b6b92 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -51,6 +51,21 @@ config AD525X_DPOT_SPI
> To compile this driver as a module, choose M here: the
> module will be called ad525x_dpot-spi.
>  
> +config MCP4XXX_DPOT
> + tristate "Microchip Digital Potentiometer"
> + depends on I2C && SYSFS
> + help
> +   If you say yes here, you get support for the Microchip
> +   MCP4531, MCP4532, MCP4551, MCP4552,
> +   

Re: [PATCH v2 1/5] drivers/misc/sgi-gru: add return on error

[Sudip Mukherjee]

On Sun, Sep 20, 2015 at 07:26:29PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Sep 15, 2015 at 01:20:41PM +0530, Sudip Mukherjee wrote:
> > On Thu, Sep 03, 2015 at 01:21:38PM -0500, Dimitri Sivanich wrote:
> > > Acked-by: Dimitri Sivanich 
> > > 
> > > On Thu, Sep 03, 2015 at 08:20:47PM +0530, Sudip Mukherjee wrote:
> > > > If the buffer is too small then return the error and in the process
> > > > remove the variables which became unused.
> > > > 
> > > > Signed-off-by: Sudip Mukherjee 
> > > > ---
> > Hi Greg,
> > I know its too early to ping you but just wanted to know that this
> > should go through your char-misc tree or through Andrew.
> > Looking at all the previous patches, it all went through Andrew but
> > being a char/misc I thought it will go through you.
> 
> I'll take it, thanks.
Thanks. But just to let you know that getmaintainer.pl is not showing
your and Arnd's name. But MAINTAINER shows drivers/misc/* for you and
Arnd. And besides I noticed there are one or two patches still lying
around with maintainer ACK but never picked up as they didnot have you
or Andrew in the To or CC list.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

[Paolo Bonzini]

On 21/09/2015 04:16, Wu, Feng wrote:
> I tested the above patch you suggested, it works fine. Thank you! So
> do I need to resend a new version or you can handle it in your tree?

I will handle it.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] misc: sram: extend usage of reserved partitions

[Greg Kroah-Hartman]

On Mon, Aug 10, 2015 at 12:40:02AM +0300, Vladimir Zapolskiy wrote:
> This change adds functionality to operate on reserved SRAM partitions
> described in device tree file. Two partition properties are added,
> "pool" and "export", the first one allows to share a specific partition
> for usage by a kernel consumer in the same manner as it is done for
> the whole SRAM device, and "export" property provides access to some
> SRAM area from userspace over sysfs interface. Practically it is
> possible to specify both properties for an SRAM partition, however
> simultaneous access from a kernel consumer and from userspace is not
> serialized, but still the combination may be useful for debugging
> purpose.

This scares me, why do we need to partition sram off in this manner?
What uses it in this way?

I need some other people to weigh in on this, and at the very least, I
need some DT people to bless the changes there...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] drivers:hv: Define the channel type for Hyper-V PCI Express pass-through

[Greg KH]

On Tue, Sep 15, 2015 at 06:26:49PM -0700, K. Y. Srinivasan wrote:
> From: Jake Oshins 
> 
> This defines the channel type for PCI front-ends in Hyper-V VMs.
> 
> Signed-off-by: Jake Oshins 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  include/linux/hyperv.h |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index ea0a0e3..5587899 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -1140,6 +1140,17 @@ u64 hv_do_hypercall(u64 control, void *input, void 
> *output);
>   }
>  
>  /*
> + * PCI Express Pass Through
> + * {44C4F61D--4400-9D52-802E27EDE19F}
> + */
> +
> +#define HV_PCIE_GUID \
> + .guid = { \
> + 0x1D, 0xF6, 0xC4, 0x44, 0x44, 0x44, 0x00, 0x44, \
> + 0x9D, 0x52, 0x80, 0x2E, 0x27, 0xED, 0xE1, 0x9F \
> + }
> +
> +/*
>   * Common header for Hyper-V ICs
>   */

Yet you do nothing with this, so why add it to the code at this point in
time?  I can't take pointless things like this...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] drivers:hv: Export the API to invoke a hypercall on Hyper-V

[Greg KH]

On Tue, Sep 15, 2015 at 06:26:48PM -0700, K. Y. Srinivasan wrote:
> From: Jake Oshins 
> 
> This patch exposes the function that hv_vmbus.ko uses to make hypercalls.  
> This
> is necessary for retargeting an interrupt when it is given a new affinity.
> 
> Since we are exporting this API, rename the API as it will be visible outside
> the hv.c file.
> 
> Signed-off-by: Jake Oshins 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/hv/hv.c|9 +
>  include/linux/hyperv.h |1 +
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> index 6341be8..a7b6c6a 100644
> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -89,9 +89,9 @@ static int query_hypervisor_info(void)
>  }
>  
>  /*
> - * do_hypercall- Invoke the specified hypercall
> + * hv_do_hypercall- Invoke the specified hypercall
>   */
> -static u64 do_hypercall(u64 control, void *input, void *output)
> +u64 hv_do_hypercall(u64 control, void *input, void *output)
>  {
>   u64 input_address = (input) ? virt_to_phys(input) : 0;
>   u64 output_address = (output) ? virt_to_phys(output) : 0;
> @@ -132,6 +132,7 @@ static u64 do_hypercall(u64 control, void *input, void 
> *output)
>   return hv_status_lo | ((u64)hv_status_hi << 32);
>  #endif /* !x86_64 */
>  }
> +EXPORT_SYMBOL_GPL(hv_do_hypercall);
>  
>  #ifdef CONFIG_X86_64
>  static cycle_t read_hv_clock_tsc(struct clocksource *arg)
> @@ -329,7 +330,7 @@ int hv_post_message(union hv_connection_id connection_id,
>   aligned_msg->payload_size = payload_size;
>   memcpy((void *)aligned_msg->payload, payload, payload_size);
>  
> - status = do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL)
> + status = hv_do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL)
>   & 0x;
>  
>   put_cpu();
> @@ -347,7 +348,7 @@ u16 hv_signal_event(void *con_id)
>  {
>   u16 status;
>  
> - status = (do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL) & 0x);
> + status = (hv_do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL) & 0x);

What's with the crazy () around a function call?

And why are you passing a 64bit return value into a 16bit status value?
That seems like something is broken.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
> -/* Never return NULL, may sleep */
> +/* May return NULL, may sleep */
>  struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
>  {
> + if (comp->tfm_noctx)
> + return NULL;
> +
>   return zcomp_strm_find(comp);
>  }
>  
> @@ -346,11 +349,18 @@ int zcomp_decompress(struct zcomp *comp, struct 
> zcomp_strm *zstrm,
>  {
>   unsigned int size = PAGE_SIZE;
>  
> + if (!zstrm) {
> + return crypto_comp_decompress_noctx(comp->tfm_noctx,
> + src, src_len, dst, );
> + }

unneeded braces.

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] hv: kvp: use wrappers to propaigate state

[Greg KH]

On Tue, Sep 15, 2015 at 05:37:53PM -0700, K. Y. Srinivasan wrote:
> From: Olaf Hering 
> 
> The "state" is used by several threads of execution.
> Propagate the state to make changes visible. Also propagate context
> change in kvp_on_msg.
> 
> Signed-off-by: Olaf Hering 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/hv/hv_kvp.c |   39 +--
>  1 files changed, 21 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> index 74c38a9..778d353 100644
> --- a/drivers/hv/hv_kvp.c
> +++ b/drivers/hv/hv_kvp.c
> @@ -61,7 +61,7 @@
>   */
>  
>  static struct {
> - int state;   /* hvutil_device_state */
> + enum hvutil_device_state state;
>   int recv_len; /* number of bytes received. */
>   struct hv_kvp_msg  *kvp_msg; /* current message */
>   struct vmbus_channel *recv_channel; /* chn we got the request */
> @@ -74,6 +74,9 @@ static struct {
>   */
>  static int dm_reg_value;
>  
> +#define kvp_get_state() hvutil_device_get_state(_transaction.state)
> +#define kvp_set_state(s) hvutil_device_set_state(_transaction.state, s)
> +
>  static void kvp_send_key(struct work_struct *dummy);
>  
>  
> @@ -122,8 +125,8 @@ static void kvp_timeout_func(struct work_struct *dummy)
>   kvp_respond_to_host(NULL, HV_E_FAIL);
>  
>   /* Transaction is finished, reset the state. */
> - if (kvp_transaction.state > HVUTIL_READY)
> - kvp_transaction.state = HVUTIL_READY;
> + if (kvp_get_state() > HVUTIL_READY)
> + kvp_set_state(HVUTIL_READY);
>  

And what if the state changed the line after this?  Oops, your code is
hosed.  See, you need a lock, do this correctly.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] hv: add helpers to handle hv_util device state

[Greg KH]

On Tue, Sep 15, 2015 at 05:37:51PM -0700, K. Y. Srinivasan wrote:
> From: Olaf Hering 
> 
> The callbacks in kvp, vss and fcopy code are called both from the main thread
> as well as from interrupt context. If a state change is done by the main
> thread it is not immediately seen by the interrupt. As a result the
> state machine gets out of sync.
> 
> Force propagation of state changes via get/set helpers with a memory barrier.
> 
> Signed-off-by: Olaf Hering 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/hv/hyperv_vmbus.h |   14 ++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 4b1eb6d..dee5798 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -780,4 +780,18 @@ enum hvutil_device_state {
>   HVUTIL_DEVICE_DYING, /* driver unload is in progress */
>  };
>  
> +static inline void hvutil_device_set_state(enum hvutil_device_state *p,
> +enum hvutil_device_state s)
> +{
> + *p = s;
> + wmb();
> +}
> +
> +static inline enum hvutil_device_state
> +hvutil_device_get_state(enum hvutil_device_state *p)
> +{
> + rmb();
> + return *p;
> +}
> +
>  #endif /* _HYPERV_VMBUS_H */

This is crazy.  If you need to know the state of something (pun
intended) then you had better be using a lock, and not relying on a
random pointer to contain a random value and be able to do something
based on that.

This shows the code is broken, don't paper over things by throwing in
random read/write barriers, that is a HUGE flag that something bad is
happening here.

Just use a lock, that's what it is there for.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 8/9] zram: use crypto API for compression

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> -static struct zcomp_backend *find_backend(const char *compress)
> +static const char *find_backend(const char *compress)
>  {
>   int i = 0;
>   while (backends[i]) {
> - if (sysfs_streq(compress, backends[i]->name))
> + if (sysfs_streq(compress, backends[i]) &&
> + crypto_has_comp(compress, 0, 0))

ok, just for note. zcomp does sysfs_streq(), because sysfs data
usually contain a trailing new line, crypto_has_comp() does strcmp().


>  int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> - const unsigned char *src, size_t *dst_len)
> + const unsigned char *src, unsigned int *dst_len)
>  {
> - return comp->backend->compress(src, zstrm->buffer, dst_len,
> - zstrm->private);
> + *dst_len = PAGE_SIZE << 1;
> +

hm... wouldn't it be better to say crypto api that we have a PAGE_SIZE
buffer instead of PAGE_SIZE << 1, so in case of buffer overrun (or
whatever is the correct term here) it will stop compression earlier
(well, possibly)? zram will drop compressed data larger than PAGE_SIZE
anyway, so if passing a smaller buffer size can save us CPU time then
let's do it.


> + return crypto_comp_compress(zstrm->tfm, src, PAGE_SIZE,
> + zstrm->buffer, dst_len);
>  }
>  
>  int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
>   const unsigned char *src,
> - size_t src_len, unsigned char *dst)
> + unsigned int src_len, unsigned char *dst)
>  {
> - return comp->backend->decompress(src, src_len, dst);
> + unsigned int size = PAGE_SIZE;
> +
> + return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );

 tab?

>  }
>  
>  void zcomp_destroy(struct zcomp *comp)
> @@ -359,7 +365,7 @@ void zcomp_destroy(struct zcomp *comp)
>  struct zcomp *zcomp_create(const char *compress, int max_strm)
>  {
>   struct zcomp *comp;
> - struct zcomp_backend *backend;
> + const char *backend;

rebase against the current linux-next. this and the next patch do not
apply cleanly. the function was touched recently: '+int error'.


>  
>   backend = find_backend(compress);
>   if (!backend)
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index 4c09c01..4f9df8e 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -11,38 +11,22 @@
>  #define _ZCOMP_H_
>  
>  #include 
> +#include 
>  
>  struct zcomp_strm {
> + struct crypto_comp *tfm;
> +
>   /* compression/decompression buffer */
>   void *buffer;
> - /*
> -  * The private data of the compression stream, only compression
> -  * stream backend can touch this (e.g. compression algorithm
> -  * working memory)
> -  */
> - void *private;
> +
>   /* used in multi stream backend, protected by backend strm_lock */
>   struct list_head list;
>  };
>  
> -/* static compression backend */
> -struct zcomp_backend {
> - int (*compress)(const unsigned char *src, unsigned char *dst,
> - size_t *dst_len, void *private);
> -
> - int (*decompress)(const unsigned char *src, size_t src_len,
> - unsigned char *dst);
> -
> - void *(*create)(void);
> - void (*destroy)(void *private);
> -
> - const char *name;
> -};
> -
>  /* dynamic per-device compression frontend */
>  struct zcomp {
>   void *stream;
> - struct zcomp_backend *backend;
> + const char *backend;

^^ what for?

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.2 000/120] 4.2.1-stable review

[Sudip Mukherjee]

On Sat, Sep 19, 2015 at 10:27:20AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.2.1 release.
> There are 120 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 Mon Sep 21 17:15:44 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tty/vt: don't set font mappings on vc not supporting this

[Sudip Mukherjee]

On Sun, Sep 20, 2015 at 06:40:15PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Sep 13, 2015 at 11:33:51AM +0530, Sudip Mukherjee wrote:
> > commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream
 
> > Cc:  # 3.14.x
> > Signed-off-by: Sudip Mukherjee 
> > ---
> > 
> > backporting for the first time so not exactly sure if the format is ok.
> 
> You need to keep the original authorship of the patch around, as well as
> their signed-off-by information.  Also, you didn't backport it
> identically:
> 

> > +
> > +   if (!p) {
> > +   err = -EINVAL;
> > +   goto out_unlock;
> 
> The original has a blank line between these two lines, why not keep it?
> 
> I'll fix it up, but be a bit more careful next time please.
Sure, next time you will have no complaints about this.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Replace get_seconds with ktime_get_seconds

[David Miller]

From: Ksenija Stanojevic 
Date: Thu, 17 Sep 2015 18:12:53 +0200

> Replace time_t type and get_seconds function which are not y2038 safe
> on 32-bit systems. Function ktime_get_seconds use monotonic instead of
> real time and therefore will not cause overflow.
> 
> Signed-off-by: Ksenija Stanojevic 
> Reviewed-by: Arnd Bergmann 

Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH tip/core/rcu 14/19] rcu: Extend expedited funnel locking to rcu_data structure

[Paul E. McKenney]

On Sun, Sep 20, 2015 at 10:58:34AM -0400, Sasha Levin wrote:
> On 07/17/2015 07:29 PM, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" 
> > 
> > The strictly rcu_node based funnel-locking scheme works well in many
> > cases, but systems with CONFIG_RCU_FANOUT_LEAF=64 won't necessarily get
> > all that much concurrency.  This commit therefore extends the funnel
> > locking into the per-CPU rcu_data structure, providing concurrency equal
> > to the number of CPUs.
> 
> Hi Paul,
> 
> I'm seeing the following lockdep warning:
> 
> [1625143.116818] ==
> [1625143.117918] [ INFO: possible circular locking dependency detected ]
> [1625143.118853] 4.3.0-rc1-next-20150918-sasha-00081-g4b7392a-dirty #2565 Not 
> tainted
> [1625143.119938] ---
> [1625143.120868] trinity-c134/25451 is trying to acquire lock:
> [1625143.121686] (>exp_funnel_mutex){+.+...}, at: exp_funnel_lock 
> (kernel/rcu/tree.c:3439)
> [1625143.123364] Mutex: counter: 1 owner: None
> [1625143.124052]
> [1625143.124052] but task is already holding lock:
> [1625143.125045] (rcu_node_exp_0){+.+...}, at: exp_funnel_lock 
> (kernel/rcu/tree.c:3419)
> [1625143.126534]
> [1625143.126534] which lock already depends on the new lock.
> [1625143.126534]
> [1625143.127893]
> [1625143.127893] the existing dependency chain (in reverse order) is:
> [1625143.129137]
> -> #1 (rcu_node_exp_0){+.+...}:
> [1625143.129978] lock_acquire (kernel/locking/lockdep.c:3620)
> [1625143.131006] mutex_lock_nested (kernel/locking/mutex.c:526 
> kernel/locking/mutex.c:617)
> [1625143.133122] exp_funnel_lock (kernel/rcu/tree.c:3445)
> [1625143.134014] synchronize_rcu_expedited (kernel/rcu/tree_plugin.h:710)
> [1625143.135180] synchronize_rcu (kernel/rcu/tree_plugin.h:532)
> [1625143.136228] rds_bind (net/rds/bind.c:207)
> [1625143.137214] SYSC_bind (net/socket.c:1383)
> [1625143.138243] SyS_bind (net/socket.c:1369)
> [1625143.139170] tracesys_phase2 (arch/x86/entry/entry_64.S:273)
> [1625143.140206]
> -> #0 (>exp_funnel_mutex){+.+...}:
> [1625143.141165] __lock_acquire (kernel/locking/lockdep.c:1877 
> kernel/locking/lockdep.c:1982 kernel/locking/lockdep.c:2168 
> kernel/locking/lockdep.c:3239)
> [1625143.142230] lock_acquire (kernel/locking/lockdep.c:3620)
> [1625143.143388] mutex_lock_nested (kernel/locking/mutex.c:526 
> kernel/locking/mutex.c:617)
> [1625143.144462] exp_funnel_lock (kernel/rcu/tree.c:3439)
> [1625143.145515] synchronize_sched_expedited (kernel/rcu/tree.c:3550 
> (discriminator 58))
> [1625143.146739] synchronize_rcu_expedited (kernel/rcu/tree_plugin.h:725)
> [1625143.147893] synchronize_rcu (kernel/rcu/tree_plugin.h:532)
> [1625143.148932] rds_release (net/rds/af_rds.c:83)
> [1625143.149921] sock_release (net/socket.c:572)
> [1625143.150922] sock_close (net/socket.c:1024)
> [1625143.151893] __fput (fs/file_table.c:209)
> [1625143.152869] fput (fs/file_table.c:245)
> [1625143.153799] task_work_run (kernel/task_work.c:117 (discriminator 1))
> [1625143.155126] do_exit (kernel/exit.c:747)
> [1625143.156124] do_group_exit (./arch/x86/include/asm/current.h:14 
> kernel/exit.c:859)
> [1625143.157134] get_signal (kernel/signal.c:2307)
> [1625143.158142] do_signal (arch/x86/kernel/signal.c:709)
> [1625143.159129] prepare_exit_to_usermode (arch/x86/entry/common.c:251)
> [1625143.160231] syscall_return_slowpath (arch/x86/entry/common.c:318)
> [1625143.161443] int_ret_from_sys_call (arch/x86/entry/entry_64.S:285)
> [1625143.162431]
> [1625143.162431] other info that might help us debug this:
> [1625143.162431]
> [1625143.163737]  Possible unsafe locking scenario:
> [1625143.163737]
> [1625143.164724]CPU0CPU1
> [1625143.165466]
> [1625143.166198]   lock(rcu_node_exp_0);
> [1625143.166841]lock(>exp_funnel_mutex);
> [1625143.168193]lock(rcu_node_exp_0);
> [1625143.169288]   lock(>exp_funnel_mutex);
> [1625143.170064]
> [1625143.170064]  *** DEADLOCK ***
> [1625143.170064]
> [1625143.171076] 2 locks held by trinity-c134/25451:
> [1625143.171816] #0: (rcu_node_exp_0){+.+...}, at: exp_funnel_lock 
> (kernel/rcu/tree.c:3419)
> [1625143.173458] #1: (cpu_hotplug.lock){++}, at: try_get_online_cpus 
> (kernel/cpu.c:111)
> [1625143.175090]
> [1625143.175090] stack backtrace:
> [1625143.176095] CPU: 4 PID: 25451 Comm: trinity-c134 Not tainted 
> 4.3.0-rc1-next-20150918-sasha-00081-g4b7392a-dirty #2565
> [1625143.177833]  ad1e2130 880169047250 9efe97ba 
> ad273df0
> [1625143.179224]  8801690472a0 9d46b701 880169047370 
> dc00
> [1625143.180543]  69038d30 880169038cc0 880169038cf2 
> 880169038000
> [1625143.181845] Call Trace:
> [1625143.182326] dump_stack (lib/dump_stack.c:52)
> [1625143.183212] print_circular_bug (kernel/locking/lockdep.c:1252)
> [1625143.184186] 

Re: [PATCH] USB: EHCI: fix dereference of ERR_PTR

[Sudip Mukherjee]

On Mon, Sep 21, 2015 at 10:48:52AM +0800, Lu, Baolu wrote:
> 
> 
> On 09/16/2015 10:08 PM, Sudip Mukherjee wrote:
> >On error find_tt() returns either a NULL pointer or the error value in
> >ERR_PTR. But we were dereferencing it directly without even checking if
> >find_tt() returned a valid pointer or not.
> >
> >Signed-off-by: Sudip Mukherjee 
> >---
> >  drivers/usb/host/ehci-sched.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> >diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> >index f9a3327..27bced7 100644
> >--- a/drivers/usb/host/ehci-sched.c
> >+++ b/drivers/usb/host/ehci-sched.c
> >@@ -257,6 +257,8 @@ static void reserve_release_intr_bandwidth(struct 
> >ehci_hcd *ehci,
> > /* FS/LS bus bandwidth */
> > if (tt_usecs) {
> > tt = find_tt(qh->ps.udev);
> >+if (!tt || IS_ERR(tt))
> 
> Why not IS_ERR_OR_NULL()?
This was v1, corrected in v2. And Alan has already explained why this
patch is not required.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] input: Add Qualcomm PM8941 power key driver

[Bjorn Andersson]

On Tue 15 Sep 04:36 PDT 2015, Ivan T. Ivanov wrote:

> 
> On Fri, 2015-01-23 at 16:19 -0800, Bjorn Andersson wrote:
> > From: Courtney Cavin ca...@sonymobile.com>
> > 
> > Signed-off-by: Courtney Cavin ca...@sonymobile.com>
> > Signed-off-by: Bjorn Andersson anders...@sonymobile.com>
> > 
> 
> 
> 
> > 
> > +config INPUT_PM8941_PWRKEY
> > +   tristate "Qualcomm PM8941 power key support"
> > +   depends on MFD_SPMI_PMIC
> > +   help
> > +   Say Y here if you want support for the power key 
> > usually found
> > +   on boards using a Qualcomm PM8941 compatible PMIC.
> > +
> 
> Hi Bjorn, Courtney, 
> 
> Do you plan to extend this driver to support RESIN_N PMIC input?
>  

It's way down on the todo-list, so not right now.

> It looks like the same downstream "qcom,qpnp-power-on" handle
> this functionality for recent PMIC versions.
> 

Right, it seems to be functionality in the PON block.

> What will be the best way to add this new functionality, extend
> this driver, write new one...?
> 

Perhaps the naming of the driver isn't the best in the end, but I think
it should be implemented by the same driver...

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[linux-next] khugepaged inconsistent lock state

[Sergey Senozhatsky]

Hi,

4.3.0-rc1-next-20150918

[18344.236625] =
[18344.236628] [ INFO: inconsistent lock state ]
[18344.236633] 4.3.0-rc1-next-20150918-dbg-00014-ge5128d0-dirty #361 Not tainted
[18344.236636] -
[18344.236640] inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
[18344.236645] khugepaged/32 [HC0[0]:SC0[0]:HE1:SE1] takes:
[18344.236648]  (_vma->rwsem){?.}, at: [] 
khugepaged+0x8b0/0x1987
[18344.236662] {IN-RECLAIM_FS-W} state was registered at:
[18344.23]   [] __lock_acquire+0x8e2/0x1183
[18344.236673]   [] lock_acquire+0x10b/0x1a6
[18344.236678]   [] down_write+0x3b/0x6a
[18344.236686]   [] split_huge_page_to_list+0x5b/0x61f
[18344.236689]   [] add_to_swap+0x37/0x78
[18344.236691]   [] shrink_page_list+0x4c2/0xb9a
[18344.236694]   [] shrink_inactive_list+0x371/0x5d9
[18344.236696]   [] shrink_lruvec+0x410/0x5ae
[18344.236698]   [] shrink_zone+0x57/0x140
[18344.236700]   [] kswapd+0x6a5/0x91b
[18344.236702]   [] kthread+0x107/0x10f
[18344.236706]   [] ret_from_fork+0x3f/0x70
[18344.236708] irq event stamp: 6517947
[18344.236709] hardirqs last  enabled at (6517947): [] 
get_page_from_freelist+0x362/0x59e
[18344.236713] hardirqs last disabled at (6517946): [] 
_raw_spin_lock_irqsave+0x18/0x51
[18344.236715] softirqs last  enabled at (6507072): [] 
__do_softirq+0x2df/0x3f5
[18344.236719] softirqs last disabled at (6507055): [] 
irq_exit+0x40/0x94
[18344.236722] 
   other info that might help us debug this:
[18344.236723]  Possible unsafe locking scenario:

[18344.236724]CPU0
[18344.236725]
[18344.236726]   lock(_vma->rwsem);
[18344.236728]   
[18344.236729] lock(_vma->rwsem);
[18344.236731] 
*** DEADLOCK ***

[18344.236733] 2 locks held by khugepaged/32:
[18344.236733]  #0:  (>mmap_sem){++}, at: [] 
khugepaged+0x5cf/0x1987
[18344.236738]  #1:  (_vma->rwsem){?.}, at: [] 
khugepaged+0x8b0/0x1987
[18344.236741] 
   stack backtrace:
[18344.236744] CPU: 3 PID: 32 Comm: khugepaged Not tainted 
4.3.0-rc1-next-20150918-dbg-00014-ge5128d0-dirty #361
[18344.236747]   880132827a00 81230867 
8237ba90
[18344.236750]  880132827a38 810ea9b9 000a 
8801333b52e0
[18344.236753]  8801333b4c00 8107b3ce 000a 
880132827a78
[18344.236755] Call Trace:
[18344.236758]  [] dump_stack+0x4e/0x79
[18344.236761]  [] print_usage_bug.part.24+0x259/0x268
[18344.236763]  [] ? 
print_shortest_lock_dependencies+0x180/0x180
[18344.236765]  [] mark_lock+0x381/0x567
[18344.236766]  [] mark_held_locks+0x5e/0x74
[18344.236768]  [] lockdep_trace_alloc+0xb0/0xb3
[18344.236771]  [] __alloc_pages_nodemask+0x99/0x856
[18344.236772]  [] ? find_get_entry+0x14b/0x17a
[18344.236774]  [] ? find_get_entry+0x168/0x17a
[18344.236777]  [] __read_swap_cache_async+0x7b/0x1aa
[18344.236778]  [] read_swap_cache_async+0x15/0x2d
[18344.236780]  [] swapin_readahead+0x11a/0x16a
[18344.236783]  [] do_swap_page+0xa7/0x36b
[18344.236784]  [] ? do_swap_page+0xa7/0x36b
[18344.236787]  [] khugepaged+0x8f9/0x1987
[18344.236790]  [] ? wait_woken+0x88/0x88
[18344.236792]  [] ? maybe_pmd_mkwrite+0x1a/0x1a
[18344.236794]  [] kthread+0x107/0x10f
[18344.236797]  [] ? kthread_create_on_node+0x1ea/0x1ea
[18344.236799]  [] ret_from_fork+0x3f/0x70
[18344.236801]  [] ? kthread_create_on_node+0x1ea/0x1ea


-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/5] net: Hisilicon Network Subsystem support

[David Miller]

From: huangdaode 
Date: Thu, 17 Sep 2015 14:51:45 +0800

> This is V2 of Hisilicon Network Subsystem(HNS) patchesets taking care
> about LKML comments.
> 
> Please find out the changes from the change logs. 
> This patchset is rebased on mainline kernel Linux 4.3-rc1 branch.
> 
> [PATCH v2 1/5] Device Tree Binding Documentation
> [PATCH v2 2/5] Merge MDIO Module
> [PATCH v2 3/5] Hisilicon Network Acceleration Engine Framework
> [PATCH v2 4/5] Distributed System Area Fabric Module
> [PATCH v2 5/5] Basic Ethernet Driver Module
> 
> Changes from V1:
> 1. Remove "inline" in C file (according to LKML comment, same in below).
> 2. Fix a bug about class_find_device.
> 3. Change the DTS pattern on hnae, restruct it to compatible with Hi1610 soc.
> 4. Unified hip04_mdio and hip05_mdio into hns_mdio, which is more usaul for 
>later SOCs.
> 
> V1 Patches Reference: https://lkml.org/lkml/2015/8/14/165

Series applied, thanks.

 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tty/vt: don't set font mappings on vc not supporting this

[Greg Kroah-Hartman]

On Sun, Sep 13, 2015 at 11:33:51AM +0530, Sudip Mukherjee wrote:
> commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream
> 
> We can call this function for a dummy console that doesn't support
> setting the font mapping, which will result in a null ptr BUG. So check
> for this case and return error for consoles w/o font mapping support.
> 
> Cc:  # 3.14.x
> Signed-off-by: Sudip Mukherjee 
> ---
> 
> backporting for the first time so not exactly sure if the format is ok.

You need to keep the original authorship of the patch around, as well as
their signed-off-by information.  Also, you didn't backport it
identically:

> 
>  drivers/tty/vt/consolemap.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/tty/vt/consolemap.c b/drivers/tty/vt/consolemap.c
> index 2978ca5..08d36e4 100644
> --- a/drivers/tty/vt/consolemap.c
> +++ b/drivers/tty/vt/consolemap.c
> @@ -540,6 +540,11 @@ int con_set_unimap(struct vc_data *vc, ushort ct, struct 
> unipair __user *list)
>  
>   /* Save original vc_unipagdir_loc in case we allocate a new one */
>   p = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
> +
> + if (!p) {
> + err = -EINVAL;
> + goto out_unlock;

The original has a blank line between these two lines, why not keep it?

I'll fix it up, but be a bit more careful next time please.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.2 000/120] 4.2.1-stable review

[Greg Kroah-Hartman]

On Sat, Sep 19, 2015 at 05:27:34PM -0700, Guenter Roeck wrote:
> On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 4.2.1 release.
> >There are 120 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 Mon Sep 21 17:15:44 UTC 2015.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 144 pass: 143 fail: 1
> Failed builds:
>   arm:allmodconfig
> Qemu test results:
>   total: 93 pass: 83 fail: 10
> Failed tests:
>   arm:beagle:multi_v7_defconfig:omap3-beagle
>   arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
>   arm:overo:multi_v7_defconfig:omap3-overo-tobi
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
>   arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
>   arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
>   mips:fuloong2e_defconfig
> 
> Same problems as with 4.1.
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Should be fixed with the patch now added.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] drivers/misc/sgi-gru: add return on error

[Greg Kroah-Hartman]

On Tue, Sep 15, 2015 at 01:20:41PM +0530, Sudip Mukherjee wrote:
> On Thu, Sep 03, 2015 at 01:21:38PM -0500, Dimitri Sivanich wrote:
> > Acked-by: Dimitri Sivanich 
> > 
> > On Thu, Sep 03, 2015 at 08:20:47PM +0530, Sudip Mukherjee wrote:
> > > If the buffer is too small then return the error and in the process
> > > remove the variables which became unused.
> > > 
> > > Signed-off-by: Sudip Mukherjee 
> > > ---
> Hi Greg,
> I know its too early to ping you but just wanted to know that this
> should go through your char-misc tree or through Andrew.
> Looking at all the previous patches, it all went through Andrew but
> being a char/misc I thought it will go through you.

I'll take it, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 02/15] staging: rtl8192u: r8192U_core: add temporary variables to keep lines under 80 characters

[Greg Kroah-Hartman]

On Sun, Sep 20, 2015 at 01:14:14PM -0400, Raphaël Beamonte wrote:
> Add some temporary variables to reduce line length under the maximum
> of 80 characters, as per the kernel code style.
> 
> Signed-off-by: Raphaël Beamonte 
> ---
>  drivers/staging/rtl8192u/r8192U_core.c | 139 
> ++---
>  1 file changed, 94 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 28b54ba..2abc3e77 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -171,6 +171,7 @@ static void rtl819x_set_channel_map(u8 channel_plan, 
> struct r8192_priv *priv)
>  {
>   int i, max_chan = -1, min_chan = -1;
>   struct ieee80211_device *ieee = priv->ieee80211;
> + struct CHANNEL_LIST cl;

A whole structure on the stack?  Are you sure you want to do that?

>  
>   switch (channel_plan) {
>   case COUNTRY_CODE_FCC:
> @@ -194,15 +195,18 @@ static void rtl819x_set_channel_map(u8 channel_plan, 
> struct r8192_priv *priv)
>"unknown rf chip, can't set channel map in 
> function:%s()\n",
>__func__);
>   }
> - if (ChannelPlan[channel_plan].Len != 0) {
> + cl = ChannelPlan[channel_plan];

You just did a memory copy of a whole structure, did you really want to
do that?  If so, why?  You just changed the logic of this function,
potentially slowing things down and setting yourself up for causing real
bugs (hint, anything you now change in that structure is not going to be
ever saved, it will go away after the function is exited.)

Please be more aware of how structures and pointers work in C before
doing changes like this, I can't take this change.

> + if (cl.Len != 0) {
>   /* Clear old channel map */
>   memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
>  sizeof(GET_DOT11D_INFO(ieee)->channel_map));
>   /* Set new channel map */
> - for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
> - if (ChannelPlan[channel_plan].Channel[i] < 
> min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
> + for (i = 0; i < cl.Len; i++) {
> + u8 chan = cl.Channel[i];
> +
> + if (chan < min_chan || chan > max_chan)
>   break;
> - 
> GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1;
> + GET_DOT11D_INFO(ieee)->channel_map[chan] = 1;
>   }
>   }
>   break;
> @@ -1649,9 +1653,12 @@ short rtl8192_tx(struct net_device *dev, struct 
> sk_buff *skb)
> , 0, tx_zero_isr, dev);
>   status = usb_submit_urb(tx_urb_zero, GFP_ATOMIC);
>   if (status) {
> + atomic_t tx =
> + priv->tx_pending[tcb_desc->queue_index];

Oh that's funny, think about what you just did here.

Please get some more experience with C before doing kernel development.
C is tricky and will let you shoot yourself in the foot and any other
body part if you are not _VERY_ careful.  You just blew off a few limbs
without realizing it at all in just the first two changes you made.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2, 2/2] misc: hpilo: Change e-mail address from hp.com to hpe.com

[Greg KH]

On Fri, Sep 18, 2015 at 12:32:13PM +0900, Masanari Iida wrote:
> This patch changes maintainer's email address from
> hp.com to hpe.com in hpilo.c.
> 
> Signed-off-by: Masanari Iida 
> ---
>  drivers/misc/hpilo.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

I'd like to get an ack from the driver author before accepting something
like this...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mei, make modules.alias UUID information easier to read

[Greg Kroah-Hartman]

On Fri, Aug 14, 2015 at 09:05:40AM -0400, Prarit Bhargava wrote:
> 2nd try on this ...

What changed from the first patch?  I need some "version information" to
figure out what is going on.

Can you resend it with that information?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc 1/2] mei: Fix debugfs filename in error output

[Greg Kroah-Hartman]

On Mon, Aug 24, 2015 at 03:27:36PM +0300, Tomas Winkler wrote:
> From: "Signed-off-by: Alexander Kuleshov" 

I kind of doubt that's the real author name :(

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: lustre: lustre: libcfs: Added a blank line

[Greg KH]

On Sun, Sep 20, 2015 at 10:35:01PM +0530, Anjali Menon wrote:
> Added a blank line after declaration. Coding style
> warning detected by checkpatch.pl
> 
> WARNING: Missing a blank line after declarations
> 
> Signed-off-by: Anjali Menon 
> ---
>  drivers/staging/lustre/lustre/libcfs/module.c | 1 +
>  1 file changed, 1 insertion(+)

What tree are you making this against, it's not quite "clean" and should
be rebased.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: lustre: lustre: libcfs: Removed a space

[Greg KH]

On Sun, Sep 20, 2015 at 10:59:16PM +0530, Anjali Menon wrote:
> Removed space between function name and open paranthesis
> detected by checkpatch.pl
> 
> 112: WARNING: space prohibited between function name and open
> parenthesis '('

Please don't wrap error/warning messages like these.

And this patch doesn't apply at all to my tree, what are you making it
against?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.10 00/20] 3.10.89-stable review

[Greg Kroah-Hartman]

On Sun, Sep 20, 2015 at 09:05:53AM -0700, Guenter Roeck wrote:
> On 09/20/2015 01:53 AM, Sudip Mukherjee wrote:
> >On Sat, Sep 19, 2015 at 10:27:15AM -0700, Greg Kroah-Hartman wrote:
> >>This is the start of the stable review cycle for the 3.10.89 release.
> >>There are 20 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 Mon Sep 21 17:16:03 UTC 2015.
> >>Anything received after that time might be too late.
> >defconfig and allmodconfig with xtensa failed. With 3.10.88-rc1 I reported
> >that 123f15e669d5 ("xtensa: don't use echo -e needlessly") is required to fix
> >the build failure.
> >
> 
> Note that it probably only fails to build for you because you use dash
> as default shell.

Which I think Debian does :(

I've queued this up, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Greg Kroah-Hartman]

On Mon, Sep 14, 2015 at 02:31:51PM +0530, Sudip Mukherjee wrote:
> On Sat, Sep 12, 2015 at 07:22:39PM +0300, Max Filippov wrote:
> > On Sat, Sep 12, 2015 at 6:55 PM, Greg Kroah-Hartman
> >  wrote:
> > > On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
> > >> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
> > >> > This is the start of the stable review cycle for the 3.10.88 release.
> > >> > There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
> > >> > Anything received after that time might be too late.
> > >> Compiled and booted on x86_32. No errors in dmesg.
> > >>
> > >> cross_compiled with allmodconfig:
> > ...
> > >> xtensa - failed
> > >
> > > Are these all new failures?
> > 
> > Build log says
> > 
> > /home/travis/local/gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-objcopy:
> > Unable to change endianness of input file(s)
> > make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
> > 
> > which looks like misconfigured toolchain.
> 
> With same toolchain and same script upstream commit
> 123f15e669d5a5a2e2f260ba4a5fc2efd93df20e solves the problem. Tested
> after applying it on v3.10.88.
> 
> Greg - This will apply directly, backporting not required. Do you want
> me to send to you and stable (for 3.10.89) or will you pick it up?

Now applied, sorry I missed this before now.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.14 00/29] 3.14.53-stable review

[Greg Kroah-Hartman]

On Sat, Sep 19, 2015 at 05:19:06PM -0700, Guenter Roeck wrote:
> On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.14.53 release.
> >There are 29 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 Mon Sep 21 17:18:53 UTC 2015.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 127 pass: 127 fail: 0
> Qemu test results:
>   total: 80 pass: 80 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 000/102] 4.1.8-stable review

[Greg Kroah-Hartman]

On Sun, Sep 20, 2015 at 07:28:44AM +0200, Willy Tarreau wrote:
> Hi Guenter,
> 
> On Sat, Sep 19, 2015 at 05:25:59PM -0700, Guenter Roeck wrote:
> > On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote:
> > >This is the start of the stable review cycle for the 4.1.8 release.
> > >There are 102 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 Mon Sep 21 17:15:55 UTC 2015.
> > >Anything received after that time might be too late.
> > >
> > 
> > Build results:
> > total: 137 pass: 136 fail: 1
> > Failed builds:
> > arm:allmodconfig
> > Qemu test results:
> > total: 93 pass: 83 fail: 10
> > Failed tests:
> > arm:beagle:multi_v7_defconfig:omap3-beagle
> > arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
> > arm:overo:multi_v7_defconfig:omap3-overo-tobi
> > arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> > arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
> > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
> > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
> > arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
> > mips:fuloong2e_defconfig
> > 
> > The new failures are all caused by a single new build failure.
> > 
> > arch/arm/mach-rockchip/platsmp.c: In function 'rockchip_boot_secondary':
> > arch/arm/mach-rockchip/platsmp.c:155:3: error: 
> > 'rockchip_secondary_startup' undeclared
> > 
> > Caused by 'ARM: rockchip: fix the CPU soft reset'.
> 
> It looks like this patch needs to be backported as well :
> 
> commit cb8cc37f4d38d96552f2c52deb15e511cdacf906
> Author: Caesar Wang 
> Date:   Mon Jul 6 11:37:23 2015 +0800
> 
> ARM: rockchip: fix broken build
> 
> The following was seen in branch[0] build.
> 
> arch/arm/mach-rockchip/platsmp.c:154:23: error:
> 'rockchip_secondary_startup' undeclared (first use in this function)
> 
> branch[0]:
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
> v4.3-armsoc/soc
> 
> The broken build is caused by the commit fe4407c0dc58
> ("ARM: rockchip: fix the CPU soft reset").
> 
> Signed-off-by: Caesar Wang 
> 
> The breakage was a result of it being wrongly merged in my branch with
> the cache invalidation rework from Russell 02b4e2756e01c
> ("ARM: v7 setup function should invalidate L1 cache").

Thanks for this, I've queued it up now.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 26/26] x86, pkeys: Documentation

[Dave Hansen]

On 09/20/2015 01:55 AM, Ingo Molnar wrote:
> * Dave Hansen  wrote:
>> +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature
>> +which will be found on future Intel CPUs.
>> +
>> +Memory Protection Keys provides a mechanism for enforcing page-based
>> +protections, but without requiring modification of the page tables
>> +when an application changes protection domains.  It works by
>> +dedicating 4 previously ignored bits in each page table entry to a
>> +"protection key", giving 16 possible keys.
> 
> Wondering how user-space is supposed to discover the number of protection 
> keys,
> is that CPUID leaf based, or hardcoded on the CPU feature bit?

The 16 keys are essentially hard-coded from the cpuid bit.

>> +There is also a new user-accessible register (PKRU) with two separate
>> +bits (Access Disable and Write Disable) for each key.  Being a CPU
>> +register, PKRU is inherently thread-local, potentially giving each
>> +thread a different set of protections from every other thread.
>> +
>> +There are two new instructions (RDPKRU/WRPKRU) for reading and writing
>> +to the new register.  The feature is only available in 64-bit mode,
>> +even though there is theoretically space in the PAE PTEs.  These
>> +permissions are enforced on data access only and have no effect on
>> +instruction fetches.
> 
> Another question, related to enumeration as well: I'm wondering whether 
> there's 
> any way for the kernel to allocate a bit or two for its own purposes - such 
> as 
> protecting crypto keys? Or is the facility fundamentally intended for 
> user-space 
> use only?

No, that's not possible with the current setup.

Userspace has complete control over the contents of the PKRU register
with unprivileged instructions.  So the kernel can not practically
protect any of its own data with this.

> Similarly, the pmem (persistent memory) driver could employ protection keys 
> to 
> keep terabytes of data 'masked out' most of the time - protecting data from 
> kernel 
> space memory corruption bugs.

I wish we could do this, but we can not with the current implementation.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] Add initial support for RPM clocks

[Bjorn Andersson]

On Mon 03 Aug 09:48 PDT 2015, Georgi Djakov wrote:

> This patchset adds initial support for the clocks controlled by
> the RPM (Resource Power Manager) processor on Qualcomm platforms.
> It depends on Bjorn's Qualcomm SMD & RPM patches, that are now in
> linux-next: https://lkml.org/lkml/2015/7/27/1125
> 
> The first patch implements the RPM clock operations, which are
> using a shared memory for sending requests to the RPM processor.
> The second patch adds the support of RPM clocks on the MSM8916
> platform.
> 

I pulled this set into my local tree and added a MSM8974 driver; so I
could enable cxo_a2 and load the WCNSS firmware. This works great.

I do however have a problem that if I revise the gcc and mmcc drivers to
be rooted in cxo_clk_src (like you have for 8916) the clk_set_rate() in
msm_serial messes up my uart - way before the rpmcc driver is loaded.
I have not debugged this further (as it wasn't needed for my usecase),
but have you seen any issues related to this?


Will you be able to send out v3 anytime soon, so I can rebase my 8974
patch and send that out? Or would you be interested in me sending you my
8974 and you can include that in your series later?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] MMC/SDIO: enable SDIO device to suspend/resume asynchronously

[Fu, Zhonghui]

Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables SDIO card and function devices to suspend/resume
asynchronously. This will take advantage of multicore and improve
system suspend/resume speed.

Signed-off-by: Zhonghui Fu 
---
Changes in v2:
- Amend commit message.

 drivers/mmc/core/sdio.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index b91abed..6719b77 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -1106,6 +1106,8 @@ int mmc_attach_sdio(struct mmc_host *host)
pm_runtime_enable(>dev);
}
 
+   device_enable_async_suspend(>dev);
+
/*
 * The number of functions on the card is encoded inside
 * the ocr.
@@ -1126,6 +1128,8 @@ int mmc_attach_sdio(struct mmc_host *host)
 */
if (host->caps & MMC_CAP_POWER_OFF_CARD)
pm_runtime_enable(>sdio_func[i]->dev);
+
+   device_enable_async_suspend(>sdio_func[i]->dev);
}
 
/*
-- 1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: gpio_keys: Don't report events on gpio failure

[Bjorn Andersson]

On Tue 28 Jul 14:00 PDT 2015, Dmitry Torokhov wrote:

> Hi Bjorn,
> 
> On Mon, Jul 27, 2015 at 06:50:04PM -0700, Bjorn Andersson wrote:
> > In the cases where the gpio chip fails to acquire the current state an
> > error is reported back to gpio_keys. This is currently interpreted as if
> > the line went high, which just confuses the developer.
> > 
> > This patch introduces an error print in this case and skipps the
> > reporting of a input event; to aid in debugging this issue.
> > 
> > Reported-by: John Stultz 
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  drivers/input/keyboard/gpio_keys.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/input/keyboard/gpio_keys.c 
> > b/drivers/input/keyboard/gpio_keys.c
> > index ddf4045de084..3ce3298ac09e 100644
> > --- a/drivers/input/keyboard/gpio_keys.c
> > +++ b/drivers/input/keyboard/gpio_keys.c
> > @@ -336,8 +336,14 @@ static void gpio_keys_gpio_report_event(struct 
> > gpio_button_data *bdata)
> > const struct gpio_keys_button *button = bdata->button;
> > struct input_dev *input = bdata->input;
> > unsigned int type = button->type ?: EV_KEY;
> > -   int state = (gpio_get_value_cansleep(button->gpio) ? 1 : 0) ^ 
> > button->active_low;
> > +   int state = gpio_get_value_cansleep(button->gpio);
> >  
> > +   if (state < 0) {
> > +   dev_err(input->dev.parent, "failed to get gpio state\n");
> 

[..]

> 
> So how exactly do we get negative here?
> 

Linus merged my change in gpiolib to propagate the error value, so as of
v4.3-rc2 this behaviour is now changed.

So please have a look at this patch again.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/input/joystick/walkera0701.c:153:4: error: implicit declaration of 
function 'abs64' [-Werror=implicit-function-declaration]
if (abs64(pulse_time - SYNC_PULSE) < RESERVE) /* new frame sync */
^

Caused by commit

  ea91f9c72512 ("Remove abs64()")

interacting with commit

  46b018fa9500 ("Input: walkera0701 - fix abs() calculations on 64 bit values")

from the input-current tree.

I just reverted 46b018fa9500 as ti will no longer be needed.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] prepare zbud to be used by zram as underlying allocator

[Minchan Kim]

Hello Vitaly,

On Thu, Sep 17, 2015 at 12:26:12PM +0200, Vitaly Wool wrote:
> On Thu, Sep 17, 2015 at 1:30 AM, Sergey Senozhatsky
>  wrote:
> 
> >
> > just a side note,
> > I'm afraid this is not how it works. numbers go first, to justify
> > the patch set.

I totally agree Sergey's opinion.

> >
> 
> These patches are extension/alignment patches, why would anyone need
> to justify that?

Sorry, because you wrote up "zram" in the title.
As I said earlier, we need several numbers to investigate.

First of all, what is culprit of your latency?
It seems you are thinking about compaction. so compaction what?
Frequent scanning? lock collision? or frequent sleeping in compaction
code somewhere? And then why does zbud solve it? If we use zbud for zram,
we lose memory efficiency so there is something to justify it.

The reason I am asking is I have investigated similar problems
in android and other plaforms and the reason of latency was not zsmalloc
but agressive high-order allocations from subsystems, watermark check
race, deferring of compaction, LMK not working and too much swapout so
it causes to reclaim lots of page cache pages which was main culprit
in my cases. When I checks with perf, compaction stall count is increased,
the time spent in there is not huge so it was not main factor of latency.

Your problem might be differnt with me so convincing us, you should
give us real data and investigation story.

Thanks.


> 
> But just to help you understand where I am coming from, here are some numbers:
>zsmalloc   zbud
> kswapd_low_wmark_hit_quickly   4513   5696
> kswapd_high_wmark_hit_quickly  861902
> allocstall 2236   1122
> pgmigrate_success  78229  31244
> compact_stall  1172   634
> compact_fail   19495
> compact_success464210
> 
> These are results from an Android device having run 3 'monkey' tests
> each 20 minutes, with user switch to guest and back in between.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:

mm/vmscan.c: In function 'sane_reclaim':
mm/vmscan.c:178:2: error: implicit declaration of function 'cgroup_on_dfl' 
[-Werror=implicit-function-declaration]
  if (cgroup_on_dfl(memcg->css.cgroup))
  ^

Caused by commit

  d08255ab4d66 ("vmscan: fix sane_reclaim helper for legacy memcg")

interacting with commit

  9e10a130d9b6 ("cgroup: replace cgroup_on_dfl() tests in controllers with 
cgroup_subsys_on_dfl()")

from the cgroup tree.

I don't know what the correct firx is here (help, please) so I have just
open coded the cgroup_on_dfl() call for now:

From: Stephen Rothwell 
Date: Mon, 21 Sep 2015 14:06:17 +1000
Subject: [PATCH] vmscan-fix-sane_reclaim-helper-for-legacy-memcg-fix

Signed-off-by: Stephen Rothwell 
---
 mm/vmscan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 6ad68edbd260..8c7b1f5c6a6d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -175,7 +175,7 @@ static bool sane_reclaim(struct scan_control *sc)
if (!memcg)
return true;
 #ifdef CONFIG_CGROUP_WRITEBACK
-   if (cgroup_on_dfl(memcg->css.cgroup))
+   if (memcg->css.cgroup->root == _dfl_root)
return true;
 #endif
return false;
-- 
2.5.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/9] zram: introduce crypto decompress noctx API and use it on zram

[Minchan Kim]

On Fri, Sep 18, 2015 at 02:19:15PM +0900, Joonsoo Kim wrote:
> This patchset makes zram to use crypto API in order to support
> more compression algorithm.
> 
> The reason we need to support vairous compression algorithms is that
> zram's performance is highly depend on workload and compression algorithm
> and architecture. Every compression algorithm has it's own strong point.
> For example, zlib is the best for compression ratio, but, it's
> (de)compression speed is rather slow. Against my expectation, in my kernel
> build test with zram swap, in low-memory condition on x86, zlib shows best
> performance than others. In this case, I guess that compression ratio is
> the most important factor. Unlike this situation, on ARM, maybe fast
> (de)compression speed is the most important because it's computation speed
> is slower than x86.

Fair enough. lzo and lz4 cannot cover all of workloads so surely, there are
workloads other compressor algorithm can win. As well, we could support
H/W compressor with crypto support so I think crypto is a way to go.

One thing I have a concern is I don't want to bind some of compressor
algorithm to zram statically. User can see what kinds of crypto compressor
support in his system via /proc/crypto and use it dynamically.
I hope zram supports it.

> 
> Anyway, there is a concern from Sergey to use crypto API in zram. Current
> crypto API has a limitation that always require tfm object to (de)compress
> something because some of (de)compression function requires scratch buffer
> embedded on tfm even if some of (de)compression function doesn't
> require it. Due to above reason, using crypto API rather than calling

Nice catch from Sergey!

> compression library directly causes more memory footprint and this is
> why zram doesn't use crypto API before.
> 
> In this patchset, crypto compress noctx API is introduced to reduce memory
> footprint caused by maintaining multiple tfm and zram uses it. Before
> noctx API, zram's performace is down-graded if tfm is insufficient. But,
> after applying noctx API, performace is restored.
> 
> This addresses Sergey's concern perfectly and provides possibility to use
> various compression algorithm in zram.
> 
> Following is zram's read performance number.
> 
> * iozone -t 4 -R -r 16K -s 60M -I +Z -i 0 -i 1
> * max_stream is set to 1
> * Output is in Kbytes/sec
> 
> zram-base vs zram-crypto vs zram-crypto-noctx
> 
> Read  10411701.88 6426911.62  9423894.38 
> Re-read   10017386.62 6428218.88  1163.50 

Another patch and number we need to merge this patchset is zlib support
patchset and number you had experiement.

> 
> Thanks.
> 
> Joonsoo Kim (7):
>   crypto: introduce decompression API that can be called via sharable
> tfm object
>   crypto/lzo: support decompress_noctx
>   crypyo/lz4: support decompress_noctx
>   crypto/lz4hc: support decompress_noctx
>   crypto/842: support decompress_noctx
>   zram: use crypto API for compression
>   zram: use crypto decompress_noctx API
> 
> Sergey Senozhatsky (2):
>   zram: make stream find and release functions static
>   zram: pass zstrm down to decompression path
> 
>  crypto/842.c   |   9 +++-
>  crypto/compress.c  |  36 +++
>  crypto/crypto_null.c   |   3 +-
>  crypto/deflate.c   |   3 +-
>  crypto/lz4.c   |   9 +++-
>  crypto/lz4hc.c |   9 +++-
>  crypto/lzo.c   |   9 +++-
>  drivers/block/zram/Kconfig |   8 ++--
>  drivers/block/zram/Makefile|   4 +-
>  drivers/block/zram/zcomp.c | 102 
> +++--
>  drivers/block/zram/zcomp.h |  42 +++--
>  drivers/block/zram/zcomp_lz4.c |  47 ---
>  drivers/block/zram/zcomp_lz4.h |  17 ---
>  drivers/block/zram/zcomp_lzo.c |  47 ---
>  drivers/block/zram/zcomp_lzo.h |  17 ---
>  drivers/block/zram/zram_drv.c  |  32 +
>  include/linux/crypto.h |  20 
>  17 files changed, 211 insertions(+), 203 deletions(-)
>  delete mode 100644 drivers/block/zram/zcomp_lz4.c
>  delete mode 100644 drivers/block/zram/zcomp_lz4.h
>  delete mode 100644 drivers/block/zram/zcomp_lzo.c
>  delete mode 100644 drivers/block/zram/zcomp_lzo.h
> 
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API

[Minchan Kim]

On Fri, Sep 18, 2015 at 02:19:24PM +0900, Joonsoo Kim wrote:
> Crypto subsystem now supports decompress_noctx API that requires
> special tfm_noctx. This tfm can be shared by multiple concurrent
> decompress user because this API doesn't rely on this tfm object
> except to fetch decompress function pointer.
> 
> Until changing to use crypto API, zram doesn't require any zstrm
> on decompress so decompress is parallelized unlimitedly. But, previous
> patch make zram to use crypto API and this requires one zstrm on every
> decompress users so, in some zstrm contended situations, zram's
> performance would be degraded.
> 
> This patch makes zram use decompress_noctx API and restore zram's
> performance as the time that zram doesn't use crypto API.
> 
> Following is zram's read performance number.
> 
> * iozone -t 4 -R -r 16K -s 60M -I +Z -i 0 -i 1
> * max_stream is set to 1
> * Output is in Kbytes/sec
> 
> zram-base vs zram-crypto vs zram-crypto-noctx
> 
> Read  10411701.88 6426911.62  9423894.38
> Re-read   10017386.62 6428218.88  1163.50
> 
> Signed-off-by: Joonsoo Kim 
> ---
>  drivers/block/zram/zcomp.c | 24 +++-
>  drivers/block/zram/zcomp.h |  1 +
>  2 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index c2ed7c8..a020200 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -319,9 +319,12 @@ void zcomp_compress_end(struct zcomp *comp, struct 
> zcomp_strm *zstrm)
>   zcomp_strm_release(comp, zstrm);
>  }
>  
> -/* Never return NULL, may sleep */
> +/* May return NULL, may sleep */
>  struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
>  {
> + if (comp->tfm_noctx)
> + return NULL;

Hmm,, I understand why returns NULL but it seems to be awkward to use NULL
to express meaningful semantic and following functions relies on.
If I have a time, I will think over.

> +
>   return zcomp_strm_find(comp);
>  }
>  
> @@ -346,11 +349,18 @@ int zcomp_decompress(struct zcomp *comp, struct 
> zcomp_strm *zstrm,
>  {
>   unsigned int size = PAGE_SIZE;
>  
> + if (!zstrm) {
> + return crypto_comp_decompress_noctx(comp->tfm_noctx,
> + src, src_len, dst, );
> + }
> +
>   return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
>  }
>  
>  void zcomp_destroy(struct zcomp *comp)
>  {
> + if (comp->tfm_noctx)
> + crypto_free_comp_noctx(comp->tfm_noctx);
>   comp->destroy(comp);
>   kfree(comp);
>  }
> @@ -366,6 +376,7 @@ struct zcomp *zcomp_create(const char *compress, int 
> max_strm)
>  {
>   struct zcomp *comp;
>   const char *backend;
> + struct crypto_comp *tfm;
>  
>   backend = find_backend(compress);
>   if (!backend)
> @@ -384,5 +395,16 @@ struct zcomp *zcomp_create(const char *compress, int 
> max_strm)
>   kfree(comp);
>   return ERR_PTR(-ENOMEM);
>   }
> +
> + /*
> +  * Prepare to use crypto decompress_noctx API. One tfm is required
> +  * to initialize crypto algorithm properly and fetch corresponding
> +  * function pointer. But, it is sharable for multiple concurrent
> +  * decompress users.
> +  */

Please comment out that this API will return NULL if the compressor doesn't
support noctx mode.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

[Pengyu Ma]

On 09/18/2015 11:43 PM, Jacob Pan wrote:

On Fri, 18 Sep 2015 02:09:55 +0200
"Rafael J. Wysocki"  wrote:


On Thursday, September 17, 2015 03:31:41 PM Pengyu Ma wrote:

iosf_mbi is supported on Quark, Braswell, Baytrail and some Atom
SoC, but RAPL is not limited to these SoC, it supports almost Intel
CPUs. Remove this dependece to make RAPL support more Intel CPUs.

Please select IOSF_MBI on Atom SoCs.


Unlike Quark, I don't think we want to or do differentiate Atom from
other x86 at compile time. IOSF driver can be compiled as a module also,
therefore RAPL driver needs this explicit dependency at compile time.

As commit had exported iosf_mbi to let user use it.

commit aa8e4f22ab7773352ba3895597189b8097f2c307
Author: David E. Box 
Date:   Wed Aug 27 14:40:39 2014 -0700

x86/iosf: Add Kconfig prompt for IOSF_MBI selection


While selecting IOSF_MBI is preferred, it does mean carrying extra code 
on non-SoC architectures.


We can NOT force user to build in iosf_mbi if they want use RAPL on 
haswell/broadwell/skylake.
And RAPL can be compiled and worked well on haswell/broadwell/skylake 
without IOSF_MBI.

RAPL is really NOT depended on IOSF_MBI.

Pengyu

Signed-off-by: Pengyu Ma 

Jacob?


---
  drivers/powercap/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
index 85727ef..a7c81b5 100644
--- a/drivers/powercap/Kconfig
+++ b/drivers/powercap/Kconfig
@@ -17,7 +17,7 @@ if POWERCAP
  # Client driver configurations go here.
  config INTEL_RAPL
tristate "Intel RAPL Support"
-   depends on X86 && IOSF_MBI
+   depends on X86
default n
---help---
  This enables support for the Intel Running Average Power
Limit (RAPL)


[Jacob Pan]


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

[David Ahern]

On 9/20/15 7:33 PM, Huang Ying wrote:

Clarification: The reproduce file shows 128 instances of 'netperf -t
TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does
that
mean these 128 commands are run serially?


Sorry.  It's a script bug, there should be a "&" on the end.  Will fix
the script.


Ok.





Also, this is the end patch of a series that first refactors and then
adds a capability. The more relevant comparison is 8f58336d3f78 to
192132b9a034 (8f58336d3f78 is the commit before the series). Is it
possible to get this test run on your system comparing those 2
commits?


Sure.  It is attached with the mail.


Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/1] btrfs: remove an unsed varialbe first_index

[Shan Hai]

This patch removes an unused variable from file.c for code clearance
purpose.

Thanks
Shan Hai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] btrfs/file.c: remove an unsed varialbe first_index

[Shan Hai]

From: Shan Hai 

The commit b37392ea86761 ("Btrfs: cleanup unnecessary parameter
and variant of prepare_pages()") makes it redundant.

Signed-off-by: Shan Hai 
---
 fs/btrfs/file.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index b823fac..b6695c4 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1469,7 +1469,6 @@ static noinline ssize_t __btrfs_buffered_write(struct 
file *file,
u64 release_bytes = 0;
u64 lockstart;
u64 lockend;
-   unsigned long first_index;
size_t num_written = 0;
int nrptrs;
int ret = 0;
@@ -1485,8 +1484,6 @@ static noinline ssize_t __btrfs_buffered_write(struct 
file *file,
if (!pages)
return -ENOMEM;
 
-   first_index = pos >> PAGE_CACHE_SHIFT;
-
while (iov_iter_count(i) > 0) {
size_t offset = pos & (PAGE_CACHE_SIZE - 1);
size_t write_bytes = min(iov_iter_count(i),
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 8/9] zram: use crypto API for compression

[Minchan Kim]

Hi Joonsoo,

On Fri, Sep 18, 2015 at 02:19:23PM +0900, Joonsoo Kim wrote:
> Until now, zram uses compression algorithm through direct call
> to core algorithm function, but, it has drawback that we need to add
> compression algorithm manually to zram if needed. Without this work,
> we cannot utilize various compression algorithms in the system.
> Moreover, to add new compression algorithm, we need to know how to use it
> and this is somewhat time-consuming.
> 
> When I tested new algorithms such as zlib, these problems make me hard
> to test them. To prevent these problem in the future, I think that
> using crypto API for compression is better approach and this patch
> implements it.
> 
> The reason we need to support vairous compression algorithms is that
> zram's performance is highly depend on workload and compression algorithm
> and architecture. Every compression algorithm has it's own strong point.
> For example, zlib is the best for compression ratio, but, it's
> (de)compression speed is rather slow. Against my expectation, in my kernel
> build test with zram swap, in low-memory condition on x86, zlib shows best
> performance than others. In this case, I guess that compression ratio is
> the most important factor. Unlike this situation, on ARM, maybe fast
> (de)compression speed is the most important because it's computation speed
> is slower than x86.
> 
> We can't expect what algorithm is the best fit for one's system, because
> it needs too complex calculation. We need to test it in case by case and
> easy to use new compression algorithm by this patch will help
> that situation.
> 
> There is one problem that crypto API requires tfm object to (de)compress
> something and zram abstract it on zstrm which is very limited resource.
> If number of zstrm is set to low and is contended, zram's performace could
> be down-graded due to this change. But, following patch support to use
> crypto decompress_noctx API and would restore the performance as is.
> 
> Signed-off-by: Joonsoo Kim 
> ---
>  drivers/block/zram/Kconfig |  8 +++
>  drivers/block/zram/Makefile|  4 +---
>  drivers/block/zram/zcomp.c | 54 
> +++---
>  drivers/block/zram/zcomp.h | 30 ++-
>  drivers/block/zram/zcomp_lz4.c | 47 
>  drivers/block/zram/zcomp_lz4.h | 17 -
>  drivers/block/zram/zcomp_lzo.c | 47 
>  drivers/block/zram/zcomp_lzo.h | 17 -
>  drivers/block/zram/zram_drv.c  |  6 ++---
>  9 files changed, 44 insertions(+), 186 deletions(-)
>  delete mode 100644 drivers/block/zram/zcomp_lz4.c
>  delete mode 100644 drivers/block/zram/zcomp_lz4.h
>  delete mode 100644 drivers/block/zram/zcomp_lzo.c
>  delete mode 100644 drivers/block/zram/zcomp_lzo.h
> 
> diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
> index 386ba3d..7619bed 100644
> --- a/drivers/block/zram/Kconfig
> +++ b/drivers/block/zram/Kconfig
> @@ -1,8 +1,7 @@
>  config ZRAM
>   tristate "Compressed RAM block device support"
>   depends on BLOCK && SYSFS && ZSMALLOC
> - select LZO_COMPRESS
> - select LZO_DECOMPRESS
> + select CRYPTO_LZO
>   default n
>   help
> Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
> @@ -18,9 +17,8 @@ config ZRAM
>  config ZRAM_LZ4_COMPRESS
>   bool "Enable LZ4 algorithm support"
>   depends on ZRAM
> - select LZ4_COMPRESS
> - select LZ4_DECOMPRESS
> + select CRYPTO_LZ4

It is out of my expectation.

When I heard crypto support for zRAM first, I imagined zram user can
use any crypto compressor algorithm easily if system has the algorithm.
IOW, I expect zRAM shouldn't bind CONFIG_CRYPTO_ALGONAME statically
except the default one(ie, CONFIG_CRYPTO_LZO) like zswap and It seems
you did in eariler version.

You seem to have a trouble to adapt crypto to current comp_algorithm
because crypto doesn't export any API to enumerate algorithm name
while zram should export supporting algorithm name via comp_algorithm
and I heard crypto maintainer doesn't want to export it. Instead,
user can use /proc/crypto to know what kinds of compressor system
can support.

Hmm,
At the first glance, I was about to say "let's sort it out with
futher patches" but I changed my mind. ;-).

We should sort it out before you are adding zlib support(ie, please
include zlib support patch with number data in this patchset). Otherwise,
we should add new hard-wired stuff for zlib like lzo, lz4 to
comp_algorithm and will depreate soon.

My idea is ABI change of comp_algorithm. Namely, let's deprecate it
and guide to use /proc/crypto to show available compressor.
Someday, we removes backends string array finally.

Welcome to any ideas.

>   default n
>   help
> This option enables LZ4 compression algorithm support. Compression
> -   algorithm can be changed using `comp_algorithm' device attribute.
> \ No newline 

Problem about " rcu_sched self-detected stall on CPU "on arm64 platform

[majun (F)]

Hi all:
I have a cpu stall problem need you help.

On my arm64 board, when
[1] set maxcpus=17 or other value < 32 and > 16 (total 32 cpus in soc 
with 2 cpu die. each die has 16 cpus)
[2] enable CONFIG_NUMA or CONFIG_SCHED_MC or both.
system would stall on cpu( log list as below)

When I set maxcpus=32, this problem gone and system boots fine.

If you ever meet or know about this problem,please give me some 
suggestion.
Thanks
Ma Jun

//---log-

[  OK  ] Reached target Swap.
[  OK  ] Mounted Debug File System.
[  OK  ] Mounted Huge Pages File System.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Started Create static device nodes in /dev.
[  OK  ] Started udev Coldplug all Devices.
INFO: rcu_sched self-detected stall on CPU
16: (5250 ticks this GP) idle=407/141/0 softirq=527/527 
fqs=5242
INFO: rcu_sched detected stalls on CPUs/tasks:
16: (5250 ticks this GP) idle=407/141/0 softirq=527/527 
fqs=5242
(detected by 0, t=5252 jiffies, g=229, c=228, q=3574)
Task dump for CPU 16:
systemd-journal R  running task0   978  1 0x0002
Call trace:
[] __switch_to+0x74/0x8c
 (t=5260 jiffies g=229 c=228 q=3574)
Task dump for CPU 16:
systemd-journal R  running task0   978  1 0x0002
Call trace:
[] dump_backtrace+0x0/0x124
[] show_stack+0x10/0x1c
[] sched_show_task+0x94/0xdc
[] dump_cpu_task+0x3c/0x4c
[] rcu_dump_cpu_stacks+0x98/0xe8
[] rcu_check_callbacks+0x47c/0x788
[] update_process_times+0x38/0x6c
[] tick_sched_handle.isra.16+0x1c/0x68
[] tick_sched_timer+0x40/0x88
[] __run_hrtimer.isra.34+0x4c/0x10c
[] hrtimer_interrupt+0xd0/0x258
[] arch_timer_handler_phys+0x28/0x38
[] handle_percpu_devid_irq+0x74/0x9c
[] generic_handle_irq+0x30/0x4c
[] __handle_domain_irq+0x5c/0xac
[] gic_handle_irq+0xb8/0x1c8
Exception stack(0xffef5f343af0 to 0xffef5f343c10)
3ae0: 7fb069c0 ffef 7fb069c8 ffef
3b00: 5f343c70 ffef 00113990 ffc0 8145  0001 
3b20: 001130c4 ffc0   00856718 ffc0 0040 
3b40: 0210  00856000 ffc0 7fa19ff8 ffef 7fa19fe0 ffef
3b60: 0001  008568f0 ffc0 0001  fffe 
3b80:     0900  65747379 6a2f646d
3ba0: 6c616e72 636f732f 6e72756f 732f6c61 65747379 6a2f646d  
3bc0: 95716a94 007f 5749  00511f54 ffc0 957f09d0 007f
3be0: e42b0110 007f 7fb069c0 ffef 7fb069c8 ffef 00856000 ffc0
3c00: 00856718 ffc0 00846980 ffc0
[] el1_irq+0x64/0xc0
[] kick_all_cpus_sync+0x24/0x30
[] aarch64_insn_patch_text+0x84/0x90
[] arch_jump_label_transform+0x58/0x64
[] __jump_label_update+0x68/0x84
[] jump_label_update+0x84/0xa8
[] static_key_slow_inc+0xf4/0xfc
[] net_enable_timestamp+0x6c/0x7c
[] sock_enable_timestamp+0x70/0x7c
[] sock_setsockopt+0x234/0x838
[] SyS_setsockopt+0x94/0xa8
NMI watchdog: BUG: soft lockup - CPU#16 stuck for 22s! [systemd-journal:978]
Modules linked in:

CPU: 16 PID: 978 Comm: systemd-journal Not tainted 4.1.6+ #9
Hardware name: Hisilicon PhosphorV660 2P1S Development Board (DT)
task: ffef5f38b700 ti: ffef5f34 task.ti: ffef5f34
PC is at smp_call_function_many+0x284/0x2f0
LR is at smp_call_function_many+0x250/0x2f0
pc : [] lr : [] pstate: 8145
sp : ffef5f343c70
x29: ffef5f343c70 x28: 0040
x27: ffc000856718 x26: 
x25: ffc0001130c4 x24: 0001
x23: ffc000846980 x22: ffc000856718
x21: ffc000856000 x20: ffef7fb069c8
x19: ffef7fb069c0 x18: 007fe42b0110
x17: 007f957f09d0 x16: ffc000511f54
x15: 5749 x14: 007f95716a94
x13:  x12: 6a2f646d65747379
x11: 732f6c616e72756f x10: 636f732f6c616e72
x9 : 6a2f646d65747379 x8 : 0900
x7 :  x6 : 
x5 : fffe x4 : 0001
x3 : ffc0008568f0 x2 : 0001
x1 : ffef7fa19fe0 x0 : ffef7fa19ff8

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH RFC] pidns: introduce syscall getvpid

[Chen Fan]

On 09/17/2015 12:31 AM, Serge E. Hallyn wrote:

On Wed, Sep 16, 2015 at 09:49:02AM -0500, Eric W. Biederman wrote:

"Serge E. Hallyn"  writes:


On Wed, Sep 16, 2015 at 10:37:33AM +0300, Konstantin Khlebnikov wrote:

On 15.09.2015 20:41, Serge Hallyn wrote:

Quoting Stéphane Graber (stgra...@ubuntu.com):

On Tue, Sep 15, 2015 at 06:01:38PM +0300, Konstantin Khlebnikov wrote:

On 15.09.2015 17:27, Eric W. Biederman wrote:

Konstantin Khlebnikov  writes:


pid_t getvpid(pid_t pid, pid_t source, pid_t target);

This syscall converts pid from one pid-ns into pid in another pid-ns:
it takes @pid in namespace of @source task (zero for current) and
returns related pid in namespace of @target task (zero for current too).
If pid is unreachable from target pid-ns then it returns zero.

This interface as presented is inherently racy.  It would be better
if source and target were file descriptors referring to the namespaces
you wish to translate between.

Yep, it's racy. As well as any operation with non-child pids.
With file descriptors for source/target result will be racy anyway.


Such conversion is required for interaction between processes from
different pid-namespaces. For example when system service talks with
client from isolated container via socket about task in container:

Sockets are already supported.  At least the metadata of sockets is.

Maybe we need this but I am not convinced of it's utility.

What are you trying to do that motivates this?

I'm working on hierarchical container management system which
allows to create and control nested sub-containers from containers
( https://github.com/yandex/porto ). Main server works in host and
have to interact with all levels of nested namespaces. This syscall
makes some operations much easier: server must remember only pid in
host pid namespace and convert it into right vpid on demand.

Note that as Eric said earlier, sending a PID inside a ucred through a
unix socket will have the pid translated.

So while your solution certainly should be faster, you can already achieve
what you want today by doing:

== Translate PID in container to PID in host
  - open a socket
  - setns to container's pidns
  - send ucred from that container containing the requested container PID
  - host sees the host PID

== Translate PID on host to PID in container
  - open a socket
  - setns to container's pidns
  - send ucred from the host containing the request host PID
(send will fail if the host PID isn't part of that container)
  - container sees the container PID

In addition, since commit e4bc332451 : /proc/PID/status: show all sets of pid 
according to ns
we now also have 'NSpid' etc in /proc/$$/status.


As I see this works perfectly only for converting host pid into virtual.

Backward conversion is troublesome: we have to scan all pids in host
procfs and somehow filter tasks from container and its sub-pid-ns.
Or I am missing something trivial?

Ah, no that doesn't help with this.

What Stéphane describes is what I've done in several projects.
Getting it right is however actually quite tricky.  I'm not
convinced it's at the level of "since you can do (sweep hands)
all this, we don't need a simple syscall to do it."

So I'd encourage you to resend using namespace inode fds for
source and target as Eric suggested.  We still may decide that
the syscall isn't needed, but it's a trivial change to your
patch and removes that race.  And I'm not convinced it's not
needed.

At this point my primary concern is that a pattern that would need to be
convering to and from pids quickly is potentially fundamentally racy to
the point of broken.

The cgmanager GetTasks and GetTasksRecursive, and reading of the
lxcfs cgroup /tasks files, require converting every pid from the
cgmanager's namespace to the reading task's namespace.


Especially with unix domain sockets passing and converting pids in a way
that covers the common case.

I am clearly missing some nuance of this use case.

lxcfs and cgmanager are imo proof that we *can* do without the new
syscall.  However, the git history will show that there are some
complications, and the system load when a few systemds are starting
will show that it does take a performance toll on the host at some
point.  Still as I say it's doable.  The syscall implementation was
very simple, though.


Yes, previous email discussed about the implementation of syscall or procfs:
http://www.gossamer-threads.com/lists/linux/kernel/1971723?search_string=chen%20hanxiao;#1971723

but it seems complicated implemented by procfs, the original discussion at:
http://www.gossamer-threads.com/lists/linux/kernel/2076440?search_string=chen%20hanxiao;#2076440

Thanks,
Chen



-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
.



--
To unsubscribe from this list: send the 

Re: [PATCH] USB: EHCI: fix dereference of ERR_PTR

[Lu, Baolu]

On 09/16/2015 10:08 PM, Sudip Mukherjee wrote:

On error find_tt() returns either a NULL pointer or the error value in
ERR_PTR. But we were dereferencing it directly without even checking if
find_tt() returned a valid pointer or not.

Signed-off-by: Sudip Mukherjee 
---
  drivers/usb/host/ehci-sched.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index f9a3327..27bced7 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -257,6 +257,8 @@ static void reserve_release_intr_bandwidth(struct ehci_hcd 
*ehci,
/* FS/LS bus bandwidth */
if (tt_usecs) {
tt = find_tt(qh->ps.udev);
+   if (!tt || IS_ERR(tt))


Why not IS_ERR_OR_NULL()?


+   return;
if (sign > 0)
list_add_tail(>ps.ps_list, >ps_list);
else
@@ -1373,6 +1375,8 @@ static void reserve_release_iso_bandwidth(struct ehci_hcd 
*ehci,
}
  
  		tt = find_tt(stream->ps.udev);

+   if (!tt || IS_ERR(tt))
+   return;
if (sign > 0)
list_add_tail(>ps.ps_list, >ps_list);
else


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/3] mfd: add CSR SiRFSoC on-chip power management module driver

[Barry Song]

hi Lee,
 thanks very much!

2015-09-20 12:15 GMT+08:00 Lee Jones :
> On Thu, 17 Sep 2015, Barry Song wrote:
>
>> From: Guo Zeng 
>>
>> CSR SiRFSoC Power Control Module includes power on or power
>> off for sysctl power and gnss, it also includes onkey, RTC
>> domain clock controllers and interrupt controller for power
>> events.
>
> There are lots of Three (and four) Letter Abbreviations (TLAs) here,
> which mean nothing to the average reader.  Please break them out in
> the commit log as I have done i.e. "Long Abbreviated Word (LAW)", so
> us normies can see what they mean.
>
>> Signed-off-by: Guo Zeng 
>> Signed-off-by: Barry Song 
>> ---
>>  .../devicetree/bindings/mfd/sirf-pwrc.txt  |  37 
>
> This should be in a separate patch.
>
>>  drivers/mfd/Kconfig|  12 ++
>>  drivers/mfd/Makefile   |   2 +
>>  drivers/mfd/sirfsoc_pwrc.c | 238 
>> +
>>  include/linux/mfd/sirfsoc_pwrc.h   |  97 +
>>  5 files changed, 386 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
>>  create mode 100644 drivers/mfd/sirfsoc_pwrc.c
>>  create mode 100644 include/linux/mfd/sirfsoc_pwrc.h
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt 
>> b/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
>> new file mode 100644
>> index 000..b919cdd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
>> @@ -0,0 +1,37 @@
>> +SiRFSoC Power Controller (PWRC) module
>> +
>> +Power Controller is used to control the whole SoC power process.
>> +The power controller controls the process of Power-On sequence,
>
> s/power controller/Power Controller/
>
>> +Power-Off sequence, different power modes switching and power
>> +status configuration. the pwrc is access by io bridge, so the
>
> s/the pwrc/The PWRC/
>
> s/access/accessed/
>
> s/io/IO/
>
>> +node's parent should be io bridge.
>
> s/io/IO/
>
> Not quite sure what an IO bridge is though.
>
>> +Required properties:
>> +- compatible: "sirf,prima2-pwrc", or "sirf,atlas7-pwrc"
>> +- reg: Address range of pwrc register set
>
> Address start and size.
>
>> +- sysctl:mfd cell device of pwrc
>> +- rtcm-clk:mfd cell device of pwrc
>> +- onkey:mfd cell device of pwrc
>
> MFD is a Linuxisum.  Please find another way to document them.
>
> I always find documentation easier to read then it's tabbed out
> nicely.  Like:
>
> Required properties:
> - compatible: "sirf,prima2-pwrc", or "sirf,atlas7-pwrc"
> - reg   : Address range of pwrc register set
> - sysctl: mfd cell device of pwrc
> - rtcm-clk  : mfd cell device of pwrc
> - onkey : mfd cell device of pwrc
>
>> +Example:
>> +
>> +pwrc@3000 {
>> + compatible = "sirf,atlas7-pwrc";
>> + reg = <0x3000 0x100>;
>
> This doesn't look like a real address.  It looks like an offset.
> Please provide a full example, complete with the parent node (which I
> assume has ranges set-up).
>
>> + sysctl {
>> + compatible = "sirf,sirf-sysctl";
>> + };
>> +
>> + rtcm-clk {
>> + compatible = "sirf,atlas7-rtcmclk";
>> + };
>> +
>> + onkey {
>> + compatible = "sirf,prima2-onkey";
>> + };
>
> Why do these require their own cells?
>
> Do they have their own properties?  If so, where are they documented?
>
>> +};
>> +
>> +pwrc@3000 {
>> + compatible = "sirf,prima2-pwrc";
>> + reg = <0x3000 0x100>;
>> +};
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 99d6367..5b67bee 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -1515,5 +1515,17 @@ config MFD_VEXPRESS_SYSREG
>> System Registers are the platform configuration block
>> on the ARM Ltd. Versatile Express board.
>>
>> +config MFD_SIRFSOC_PWRC
>> +bool "CSR SiRFSoC on-chip Power Control Module"
>> + depends on ARCH_SIRF
>> + default y
>> +select MFD_CORE
>> +select REGMAP_IRQ
>> +help
>> + CSR SiRFSoC Power Control Module includes power on or power
>> +  off for sysctl power and gnss, it also includes onkey, RTC
>> +  domain clock controllers and interrupt controller for power
>> +  events.
>
> Break out the TLAs.
>
> Your tabbing is all over the place here.  Please match existing
> entries.
>
>>  endmenu
>>  endif
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index a59e3fc..255fb80 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -192,3 +192,5 @@ obj-$(CONFIG_MFD_SKY81452)+= sky81452.o
>>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
>>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>> +
>> +obj-$(CONFIG_MFD_SIRFSOC_PWRC)   += sirfsoc_pwrc.o
>> diff --git a/drivers/mfd/sirfsoc_pwrc.c b/drivers/mfd/sirfsoc_pwrc.c
>> new file mode 100644
>> index 

Re: [PATCH] mips: vmcore: forced convert 'hdr' in elf_check_arch()

[yjin]

It seems the last mail has been blocked, resend it.

On 2015年09月21日 10:16, yjin wrote:
The new version patch only modifies mips/elf.h, so add Ralf Baechle 
and cc linux-m...@linux-mips.org.

This is a V2 patch, attach the V1 patch for reference.

Thanks!
Yanjiang

On 2015年09月18日 15:42, yanjiang@windriver.com wrote:

From: Yanjiang Jin 

elf_check_arch() will be called both in parse_crash_elf64_headers()
and parse_crash_elf32_headers(). But in these two functions, the type of
the parameter ehdr is different: Elf32_Ehdr and Elf64_Ehdr.

Function parse_crash_elf_headers() reads e_ident[EI_CLASS] then 
decides to

call parse_crash_elf64_headers() or parse_crash_elf32_headers().
This happens in run time, not compile time. So compiler will report
the below warning:

In file included from include/linux/elf.h:4:0,
  from fs/proc/vmcore.c:13:
fs/proc/vmcore.c: In function 'parse_crash_elf32_headers':
arch/mips/include/asm/elf.h:258:23: warning: initializatio
n from incompatible pointer type
   struct elfhdr *__h = (hdr); \
^
fs/proc/vmcore.c:1071:4: note: in expansion of macro 'elf_
check_arch'
!elf_check_arch() ||
 ^

Signed-off-by: Yanjiang Jin 
---
  arch/mips/include/asm/elf.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/elf.h b/arch/mips/include/asm/elf.h
index f19e890..ece490d 100644
--- a/arch/mips/include/asm/elf.h
+++ b/arch/mips/include/asm/elf.h
@@ -224,7 +224,7 @@ struct mips_elf_abiflags_v0 {
  #define elf_check_arch(hdr)\
  ({\
  int __res = 1;\
-struct elfhdr *__h = (hdr);\
+struct elfhdr *__h = (struct elfhdr *)(hdr);\
  \
  if (__h->e_machine != EM_MIPS)\
  __res = 0;\
@@ -255,7 +255,7 @@ struct mips_elf_abiflags_v0 {
  #define elf_check_arch(hdr)\
  ({\
  int __res = 1;\
-struct elfhdr *__h = (hdr);\
+struct elfhdr *__h = (struct elfhdr *)(hdr);\
  \
  if (__h->e_machine != EM_MIPS)\
  __res = 0;\




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] arm64: dts: add dts file for Marvell Berlin4CT STB board

[Jisheng Zhang]

On Sun, 20 Sep 2015 21:06:19 +0200
Sebastian Hesselbarth  wrote:

> On 18.09.2015 15:47, Jisheng Zhang wrote:
> > This patch adds dts for the Berlin4CT STB reference board which is also
> > based on the Berlin4CT SoC. The Berlin4CT DMP board will be deprecated as
> > time goes.
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> >   arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 66 
> > +++
> 
> This is missing the corresponding Makefile change to add the
> board to the default dtb build list.

oops, sorry, I missed it.

> 
> I've fixed it up and
> 
> Applied the two dts patches to berlin64/dt

Thanks a lot ;)

> 
> Sebastian
> 
> >   1 file changed, 66 insertions(+)
> >   create mode 100644 arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> >
> > diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts 
> > b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> > new file mode 100644
> > index 000..348c37e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> > @@ -0,0 +1,66 @@
> > +/*
> > + * Copyright (C) 2015 Marvell Technology Group Ltd.
> > + *
> > + * Author: Jisheng Zhang 
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPLv2 or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + *  a) This library 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 library is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + *  b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "berlin4ct.dtsi"
> > +
> > +/ {
> > +   model = "Marvell BG4CT STB board";
> > +   compatible = "marvell,berlin4ct-stb", "marvell,berlin4ct", 
> > "marvell,berlin";
> > +
> > +   chosen {
> > +   stdout-path = "serial0:115200n8";
> > +   };
> > +
> > +   memory {
> > +   device_type = "memory";
> > +   /* the first 16MB is for firmwares' usage */
> > +   reg = <0 0x0100 0 0x7f00>;
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> >
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 1/2] arm: berlin: use non-self-cleared reset register to reset cpu

[Jisheng Zhang]

Dear Sebastian,

On Sun, 20 Sep 2015 20:04:01 +0200
Sebastian Hesselbarth  wrote:

> On 14.09.2015 08:47, Jisheng Zhang wrote:
> > In Berlin SoCs, there are two kinds of cpu reset control registers: the
> > first one's corresponding bits will be self-cleared after some cycles,
> > while the second one's bits won't. Previously the first kind of reset
> > control register is used, this patch uses the second kind one to prepare
> > for the next hotplug commit.
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> >   arch/arm/mach-berlin/platsmp.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
> > index 34a3753..bde327b 100644
> > --- a/arch/arm/mach-berlin/platsmp.c
> > +++ b/arch/arm/mach-berlin/platsmp.c
> > @@ -17,7 +17,7 @@
> >   #include 
> >   #include 
> >
> > -#define CPU_RESET  0x00
> > +#define CPU_RESET  0x20
> 
> Jisheng,
> 
> I am fine with the patch itself, except that I'd like to rather
> rename the 0x00-register to CPU_RESET_SC with a comment about
> the self-clearing nature. The 0x20-register would then be named
> CPU_RESET_NON_SC and used the way you propose.

Good idea. And such comment would let people understand why do we change
as that.

> 
> Are you fine with me naming the registers accordingly while
> applying the patches?

Sure, I'm fine. Thank you very much.

> 
> Sebastian
> 
> >   #define RESET_VECT0x00
> >   #define SW_RESET_ADDR 0x94
> > @@ -31,6 +31,8 @@ static inline void berlin_perform_reset_cpu(unsigned int 
> > cpu)
> > u32 val;
> >
> > val = readl(cpu_ctrl + CPU_RESET);
> > +   val &= ~BIT(cpu_logical_map(cpu));
> > +   writel(val, cpu_ctrl + CPU_RESET);
> > val |= BIT(cpu_logical_map(cpu));
> > writel(val, cpu_ctrl + CPU_RESET);
> >   }
> >
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kvm: svm: reset mmu on VCPU reset

[Xiao Guangrong]

On 09/18/2015 09:39 PM, Igor Mammedov wrote:

When INIT/SIPI sequence is sent to VCPU which before that
was in use by OS, VMRUN might fail with:

  KVM: entry failed, hardware error 0x
  EAX= EBX= ECX= EDX=06d3
  ESI= EDI= EBP= ESP=
  EIP= EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
  ES =   9300
  CS =9a00 0009a000  9a00
  [...]
  CR0=6010 CR2=b6f3e000 CR3=01942000 CR4=07e0
  [...]
  EFER=

with corresponding SVM error:
  KVM: FAILED VMRUN WITH VMCB:
  [...]
  cpl:0efer: 1000
  cr0:80010010 cr2:  7fd7fe85bf90
  cr3:000187d0c000 cr4:  0020
  [...]

What happens is that VCPU state right after offlinig:
CR0: 0x80050033  EFER: 0xd01  CR4: 0x7e0
   -> long mode with CR3 pointing to longmode page tables

and when VCPU gets INIT/SIPI following transition happens
CR0: 0 -> 0x6010 EFER: 0x0  CR4: 0x7e0
   -> paging disabled with stale CR3

However SVM under the hood puts VCPU in Paged Real Mode*
which effectively translates CR0 0x6010 -> 80010010 after

svm_vcpu_reset()
-> init_vmcb()
-> kvm_set_cr0()
-> svm_set_cr0()

but from  kvm_set_cr0() perspective CR0: 0 -> 0x6010
only caching bits are changed and
commit d81135a57aa6
  ("KVM: x86: do not reset mmu if CR0.CD and CR0.NW are changed")'
regressed svm_vcpu_reset() which relied on MMU being reset.

As result VMRUN after svm_vcpu_reset() tries to run
VCPU in Paged Real Mode with stale MMU context (longmode page tables),
which causes some AMD CPUs** to bail out with VMEXIT_INVALID.

Fix issue by unconditionally resetting MMU context
at init_vmcb() time.

--
* AMD64 Architecture Programmer’s Manual,
 Volume 2: System Programming, rev: 3.25
   15.19 Paged Real Mode
** Opteron 1216



Good catch and nice analysis. Thanks for your fix, Igor!

Reviewed-by: Xiao Guangrong 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mips: vmcore: forced convert 'hdr' in elf_check_arch()

[yjin]

The new version patch only modifies mips/elf.h, so add Ralf Baechle and 
cc linux-m...@linux-mips.org.

This is a V2 patch, attach the V1 patch for reference.

Thanks!
Yanjiang

On 2015年09月18日 15:42, yanjiang@windriver.com wrote:

From: Yanjiang Jin 

elf_check_arch() will be called both in parse_crash_elf64_headers()
and parse_crash_elf32_headers(). But in these two functions, the type of
the parameter ehdr is different: Elf32_Ehdr and Elf64_Ehdr.

Function parse_crash_elf_headers() reads e_ident[EI_CLASS] then decides to
call parse_crash_elf64_headers() or parse_crash_elf32_headers().
This happens in run time, not compile time. So compiler will report
the below warning:

In file included from include/linux/elf.h:4:0,
  from fs/proc/vmcore.c:13:
fs/proc/vmcore.c: In function 'parse_crash_elf32_headers':
arch/mips/include/asm/elf.h:258:23: warning: initializatio
n from incompatible pointer type
   struct elfhdr *__h = (hdr); \
^
fs/proc/vmcore.c:1071:4: note: in expansion of macro 'elf_
check_arch'
!elf_check_arch() ||
 ^

Signed-off-by: Yanjiang Jin 
---
  arch/mips/include/asm/elf.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/elf.h b/arch/mips/include/asm/elf.h
index f19e890..ece490d 100644
--- a/arch/mips/include/asm/elf.h
+++ b/arch/mips/include/asm/elf.h
@@ -224,7 +224,7 @@ struct mips_elf_abiflags_v0 {
  #define elf_check_arch(hdr)   \
  ({\
int __res = 1;  \
-   struct elfhdr *__h = (hdr); \
+   struct elfhdr *__h = (struct elfhdr *)(hdr);\
\
if (__h->e_machine != EM_MIPS)   \
__res = 0;  \
@@ -255,7 +255,7 @@ struct mips_elf_abiflags_v0 {
  #define elf_check_arch(hdr)   \
  ({\
int __res = 1;  \
-   struct elfhdr *__h = (hdr); \
+   struct elfhdr *__h = (struct elfhdr *)(hdr);\
\
if (__h->e_machine != EM_MIPS)   \
__res = 0;  \




Re: [PATCH] vmcore: replace Elf64_Ehdr_Elf32_Ehdr with elfhdr.eml
Description: application/extension-eml

Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed

[Inha Song]

Hi, Charles,

I've already tried to change.
If I change to that, we can't enter the suspen during the playback.

-
[   72.538263] arizona spi1.0: Suspend, disabling IRQ
...
[   72.585823] arizona spi1.0: Late suspend, reengabling IRQ
[   72.585904] arizona spi1.0: Early resume, disabling IRQ
...
[   72.646770] PM: noirq suspend of devices failed
<- because of "spi1.0" pm_wakeup_pending() in suspend_noirq()
...
[   72.663623] s3c64xx_spi_resume
[   72.851089] arizona spi1.0: Late resume, reenabling IRQ


Best Regards,
Inha Song.


On Fri, 18 Sep 2015 09:24:46 +0100
Charles Keepax  wrote:

> On Fri, Sep 18, 2015 at 03:49:03PM +0900, Inha Song wrote:
> > Hi,
> > 
> > I just change dev_err() to dev_info() in arizona-core.
> > 
> > 
> > root@localhost:~# aplay test.wav
> > [   42.731358] arizona spi1.0: Leaving AoD mode
> > 
> > [   42.823514] s3c64xx_spi_runtime_resume
> > [   42.828270] arizona spi1.0: ASRC underclocked
> > [   42.828281] s3c64xx_spi_runtime_suspend
> > 
> > -> suspend ()
> > [   72.398152] arizona spi1.0: Suspend, disabling IRQ
> > [   72.410471] s3c64xx_spi_runtime_resume
> > [   72.429045] s3c64xx_spi_suspend
> > -> spi suspended
> > [   72.429905] PM: suspend of devices complete after 67.309 msecs
> > [   72.440084] arizona spi1.0: Late suspend, reenabling IRQ
> > -> try to access spi irq after spi suspend()
> > [   72.440165] arizona spi1.0: Failed to read IRQ status: -108
> > [   72.440174] arizona spi1.0: Failed to read main IRQ status: -108
> > [   72.440242] arizona spi1.0: Failed to read IRQ status: -108
> > [   72.440249] arizona spi1.0: Failed to read main IRQ status: -108
> > [   72.440275] arizona spi1.0: Failed to read IRQ status: -108
> > [   72.440282] arizona spi1.0: Failed to read main IRQ status: -108
> > [   72.440304] arizona spi1.0: Failed to read IRQ status: -108
> 
> Ok so looking at the system PM code I think the problem here is
> there is currently a small window between when we enable this IRQ
> and when the suspend proceedure disables IRQs and this IRQ is
> sneaking in at that point.
> 
> Can you try the following diff and let me know what happens:
> 
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -727,7 +727,7 @@ const struct dev_pm_ops arizona_pm_ops = {
>NULL)
> SET_SYSTEM_SLEEP_PM_OPS(arizona_suspend, arizona_resume)
>  #ifdef CONFIG_PM_SLEEP
> -   .suspend_late = arizona_suspend_late,
> +   .suspend_noirq = arizona_suspend_late,
> .resume_noirq = arizona_resume_noirq,
>  #endif
> 
> Thanks,
> Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

[Wu, Feng]

> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Saturday, September 19, 2015 12:07 AM
> To: Wu, Feng; Alex Williamson; j...@8bytes.org; Marcelo Tosatti
> Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; KVM list;
> Eric Auger
> Subject: Re: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when
> vCPU is blocked
> 
> 
> 
> On 18/09/2015 16:29, Feng Wu wrote:
> > This patch updates the Posted-Interrupts Descriptor when vCPU
> > is blocked.
> >
> > pre-block:
> > - Add the vCPU to the blocked per-CPU list
> > - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
> >
> > post-block:
> > - Remove the vCPU from the per-CPU list
> >
> > Signed-off-by: Feng Wu
> 
> > ---
> > v9:
> > - Add description for blocked_vcpu_on_cpu_lock in
> Documentation/virtual/kvm/locking.txt
> > - Check !kvm_arch_has_assigned_device(vcpu->kvm) first, then
> >   !irq_remapping_cap(IRQ_POSTING_CAP)
> >
> > v8:
> > - Rename 'pi_pre_block' to 'pre_block'
> > - Rename 'pi_post_block' to 'post_block'
> > - Change some comments
> > - Only add the vCPU to the blocking list when the VM has assigned devices.
> >
> >  Documentation/virtual/kvm/locking.txt |  12 +++
> >  arch/x86/include/asm/kvm_host.h   |  13 +++
> >  arch/x86/kvm/vmx.c| 153
> ++
> >  arch/x86/kvm/x86.c|  53 +---
> >  include/linux/kvm_host.h  |   3 +
> >  virt/kvm/kvm_main.c   |   3 +
> >  6 files changed, 227 insertions(+), 10 deletions(-)
> >
> > diff --git a/Documentation/virtual/kvm/locking.txt
> b/Documentation/virtual/kvm/locking.txt
> > index d68af4d..19f94a6 100644
> > --- a/Documentation/virtual/kvm/locking.txt
> > +++ b/Documentation/virtual/kvm/locking.txt
> > @@ -166,3 +166,15 @@ Comment:   The srcu read lock must be held while
> accessing memslots (e.g.
> > MMIO/PIO address->device structure mapping (kvm->buses).
> > The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu
> > if it is needed by multiple functions.
> > +
> > +Name:  blocked_vcpu_on_cpu_lock
> > +Type:  spinlock_t
> > +Arch:  x86
> > +Protects:  blocked_vcpu_on_cpu
> > +Comment:   This is a per-CPU lock and it is used for VT-d 
> > posted-interrupts.
> > +   When VT-d posted-interrupts is supported and the VM has assigned
> > +   devices, we put the blocked vCPU on the list blocked_vcpu_on_cpu
> > +   protected by blocked_vcpu_on_cpu_lock, when VT-d hardware issues
> > +   wakeup notification event since external interrupts from the
> > +   assigned devices happens, we will find the vCPU on the list to
> > +   wakeup.
> > diff --git a/arch/x86/include/asm/kvm_host.h
> b/arch/x86/include/asm/kvm_host.h
> > index 0ddd353..304fbb5 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -552,6 +552,8 @@ struct kvm_vcpu_arch {
> >  */
> > bool write_fault_to_shadow_pgtable;
> >
> > +   bool halted;
> > +
> > /* set at EPT violation at this point */
> > unsigned long exit_qualification;
> >
> > @@ -864,6 +866,17 @@ struct kvm_x86_ops {
> > /* pmu operations of sub-arch */
> > const struct kvm_pmu_ops *pmu_ops;
> >
> > +   /*
> > +* Architecture specific hooks for vCPU blocking due to
> > +* HLT instruction.
> > +* Returns for .pre_block():
> > +*- 0 means continue to block the vCPU.
> > +*- 1 means we cannot block the vCPU since some event
> > +*happens during this period, such as, 'ON' bit in
> > +*posted-interrupts descriptor is set.
> > +*/
> > +   int (*pre_block)(struct kvm_vcpu *vcpu);
> > +   void (*post_block)(struct kvm_vcpu *vcpu);
> > int (*update_pi_irte)(struct kvm *kvm, unsigned int host_irq,
> >   uint32_t guest_irq, bool set);
> >  };
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index 902a67d..9968896 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -879,6 +879,13 @@ static DEFINE_PER_CPU(struct vmcs *,
> current_vmcs);
> >  static DEFINE_PER_CPU(struct list_head, loaded_vmcss_on_cpu);
> >  static DEFINE_PER_CPU(struct desc_ptr, host_gdt);
> >
> > +/*
> > + * We maintian a per-CPU linked-list of vCPU, so in wakeup_handler() we
> > + * can find which vCPU should be waken up.
> > + */
> > +static DEFINE_PER_CPU(struct list_head, blocked_vcpu_on_cpu);
> > +static DEFINE_PER_CPU(spinlock_t, blocked_vcpu_on_cpu_lock);
> > +
> >  static unsigned long *vmx_io_bitmap_a;
> >  static unsigned long *vmx_io_bitmap_b;
> >  static unsigned long *vmx_msr_bitmap_legacy;
> > @@ -2985,6 +2992,8 @@ static int hardware_enable(void)
> > return -EBUSY;
> >
> > INIT_LIST_HEAD(_cpu(loaded_vmcss_on_cpu, cpu));
> > +   INIT_LIST_HEAD(_cpu(blocked_vcpu_on_cpu, cpu));
> > +   

[PATCH v7 0/6] Altera PCIe host controller driver with MSI support

[Ley Foon Tan]

This is the 7th version of patch set to add support for Altera PCIe host
controller with MSI feature on Altera FPGA device families. This patchset
mainly resolve comments from Lorenzo Pieralisi in v6 and minor fixes.

This patchset is based on v4.3-rc1.

v6->v7 changes:
-pcie-altera: add pcie_bus_configure_settings()
-pcie-altera: update comment
-pcie-altera: merge tlp_write_packet_unaligned and tlp_write_packet_aligned
-pcie-altera: pass in NULL for iobase for of_pci_get_host_bridge_resources
-pcie-altera: remove pcie->root_bus_nr = 0

History:
---
[v1]: https://lkml.org/lkml/2015/7/28/395
[v2]: https://lkml.org/lkml/2015/7/31/267
[v3]: http://www.kernelhub.org/?msg=811940=2
[v4]: https://lkml.org/lkml/2015/8/17/141
[v5]: https://lkml.org/lkml/2015/8/25/238
[v6]: https://lkml.org/lkml/2015/9/1/177

Ley Foon Tan (6):
  arm: add msi.h to Kbuild
  pci: add Altera PCI vendor ID
  pci:host: Add Altera PCIe host controller driver
  pci: altera: Add Altera PCIe MSI driver
  Documentation: dt-bindings: pci: altera pcie device tree binding
  MAINTAINERS: Add Altera PCIe and MSI drivers maintainer

 .../devicetree/bindings/pci/altera-pcie-msi.txt|  28 +
 .../devicetree/bindings/pci/altera-pcie.txt|  49 ++
 MAINTAINERS|  16 +
 arch/arm/include/asm/Kbuild|   1 +
 drivers/pci/host/Kconfig   |  16 +
 drivers/pci/host/Makefile  |   2 +
 drivers/pci/host/pcie-altera-msi.c | 310 +++
 drivers/pci/host/pcie-altera.c | 591 +
 include/linux/pci_ids.h|   2 +
 9 files changed, 1015 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt
 create mode 100644 drivers/pci/host/pcie-altera-msi.c
 create mode 100644 drivers/pci/host/pcie-altera.c

-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Input: elan_i2c - Add ic type 0x03

[duson]

The 0x03 is valid 3000 serial ic type too.

Signed-off-by: Duson Lin 
---
 drivers/input/mouse/elan_i2c_core.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index fa94530..16ac595 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -102,6 +102,7 @@ static int elan_get_fwinfo(u8 iap_version, u16 
*validpage_count,
*validpage_count = 512;
break;
case 0x09:
+   case 0x03:
*validpage_count = 768;
break;
case 0x0D:
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 5/6] Documentation: dt-bindings: pci: altera pcie device tree binding

[Ley Foon Tan]

This patch adds the bindings for Altera PCIe host controller driver and
Altera PCIe MSI driver.

Signed-off-by: Ley Foon Tan 
---
 .../devicetree/bindings/pci/altera-pcie-msi.txt| 28 +
 .../devicetree/bindings/pci/altera-pcie.txt| 49 ++
 2 files changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt 
b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
new file mode 100644
index 000..53ad2388
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
@@ -0,0 +1,28 @@
+* Altera PCIe MSI controller
+
+Required properties:
+- compatible:  should contain "altr,msi-1.0"
+- reg: specifies the physical base address of the controller and
+   the length of the memory mapped region.
+- reg-names:   must include the following entries:
+   "csr": CSR registers
+   "vector_slave": vectors slave port region
+- interrupt-parent:interrupt source phandle.
+- interrupts:  specifies the interrupt source of the parent interrupt
+   controller. The format of the interrupt specifier depends on the
+   parent interrupt controller.
+- num-vectors: number of vectors, range 1 to 32.
+- msi-controller:  indicates that this is MSI controller node
+
+
+Example
+msi0: msi@0xFF20 {
+   compatible = "altr,msi-1.0";
+   reg = <0xFF20 0x0010
+   0xFF200010 0x0080>;
+   reg-names = "csr", "vector_slave";
+   interrupt-parent = <_0_arm_gic_0>;
+   interrupts = <0 42 4>;
+   msi-controller = <1>;
+   num-vectors = <32>;
+};
diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt 
b/Documentation/devicetree/bindings/pci/altera-pcie.txt
new file mode 100644
index 000..4440db1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt
@@ -0,0 +1,49 @@
+* Altera PCIe controller
+
+Required properties:
+- compatible : should contain "altr,pcie-root-port-1.0"
+- reg: a list of physical base address and length for TXS and CRA.
+- reg-names:   must include the following entries:
+   "Txs" or "txs": TX slave port region
+   "Cra" or "cra": Control register access region
+- interrupt-parent:interrupt source phandle.
+- interrupts:  specifies the interrupt source of the parent interrupt 
controller.
+   The format of the interrupt specifier depends on the parent 
interrupt
+   controller.
+- device_type: must be "pci"
+- #address-cells:  set to <3>
+- #size-cells: set to <2>
+- #interrupt-cells:set to <1>
+- ranges:  describes the translation of addresses for root ports 
and standard
+   PCI regions.
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCIe interface to interrupt numbers.
+
+Optional properties:
+- msi-parent:  Link to the hardware entity that serves as the MSI controller 
for this PCIe
+   controller.
+- bus-range:   PCI bus numbers covered
+
+Example
+   pcie_0: pcie@0xc {
+   compatible = "altr,pcie-root-port-1.0";
+   reg = <0xc000 0x2000>,
+   <0xff22 0x4000>;
+   reg-names = "Txs", "Cra";
+   interrupt-parent = <_0_arm_gic_0>;
+   interrupts = <0 40 4>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   bus-range = <0x0 0xFF>;
+   device_type = "pci";
+   msi-parent = <_to_gic_gen_0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 _0 1>,
+   <0 0 0 2 _0 2>,
+   <0 0 0 3 _0 3>,
+   <0 0 0 4 _0 4>;
+   ranges = <0x8200 0x 0x 0xc000 
0x 0x1000
+   0x8200 0x 0x1000 0xd000 
0x 0x1000>;
+   };
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 4/6] pci: altera: Add Altera PCIe MSI driver

[Ley Foon Tan]

This patch adds Altera PCIe MSI driver. This soft IP supports configurable
number of vectors, which is a dts parameter.

Signed-off-by: Ley Foon Tan 
Reviewed-by: Marc Zyngier 
---
 drivers/pci/host/Kconfig   |   8 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-altera-msi.c | 310 +
 3 files changed, 319 insertions(+)
 create mode 100644 drivers/pci/host/pcie-altera-msi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index df9ed4f..0da697e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -153,4 +153,12 @@ config PCIE_ALTERA
  Say Y here if you want to enable PCIe controller support for Altera
  SoCFPGA family of SoCs.
 
+config PCIE_ALTERA_MSI
+   bool "Altera PCIe MSI feature"
+   depends on PCI_MSI
+   select PCI_MSI_IRQ_DOMAIN
+   help
+ Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
+ This MSI driver supports Altera MSI to GIC controller IP.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 6954f76..6c4913d 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
+obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
diff --git a/drivers/pci/host/pcie-altera-msi.c 
b/drivers/pci/host/pcie-altera-msi.c
new file mode 100644
index 000..667421c
--- /dev/null
+++ b/drivers/pci/host/pcie-altera-msi.c
@@ -0,0 +1,310 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MSI_STATUS 0x0
+#define MSI_ERROR  0x4
+#define MSI_INTMASK0x8
+
+#define MAX_MSI_VECTORS32
+struct altera_msi {
+   DECLARE_BITMAP(used, MAX_MSI_VECTORS);
+   struct mutexlock;   /* proctect used variable */
+   struct platform_device  *pdev;
+   struct irq_domain   *msi_domain;
+   struct irq_domain   *inner_domain;
+   void __iomem*csr_base;
+   void __iomem*vector_base;
+   phys_addr_t vector_phy;
+   u32 num_of_vectors;
+   int irq;
+};
+
+static inline void msi_writel(struct altera_msi *msi, u32 value, u32 reg)
+{
+   writel_relaxed(value, msi->csr_base + reg);
+}
+
+static inline u32 msi_readl(struct altera_msi *msi, u32 reg)
+{
+   return readl_relaxed(msi->csr_base + reg);
+}
+
+static void altera_msi_isr(unsigned int irq, struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct altera_msi *msi;
+   unsigned long status;
+   u32 num_of_vectors;
+   u32 bit;
+   u32 virq;
+
+   chained_irq_enter(chip, desc);
+   msi = irq_desc_get_handler_data(desc);
+   num_of_vectors = msi->num_of_vectors;
+
+   while ((status = msi_readl(msi, MSI_STATUS)) != 0) {
+   for_each_set_bit(bit, , msi->num_of_vectors) {
+   /* Dummy read from vector to clear the interrupt */
+   readl_relaxed(msi->vector_base + (bit * sizeof(u32)));
+
+   virq = irq_find_mapping(msi->inner_domain, bit);
+   if (virq)
+   generic_handle_irq(virq);
+   else
+   dev_err(>pdev->dev, "unexpected MSI\n");
+   }
+   }
+
+   chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip altera_msi_irq_chip = {
+   .name = "Altera PCIe MSI",
+   .irq_mask = pci_msi_mask_irq,
+   .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info altera_msi_domain_info = {
+   .flags  = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+MSI_FLAG_PCI_MSIX),
+   .chip   = _msi_irq_chip,
+};
+
+static void altera_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+   struct altera_msi *msi = irq_data_get_irq_chip_data(data);
+   phys_addr_t addr = msi->vector_phy + (data->hwirq * 

[PATCH v7 3/6] pci:host: Add Altera PCIe host controller driver

[Ley Foon Tan]

This patch adds the Altera PCIe host controller driver.

Signed-off-by: Ley Foon Tan 
---
 drivers/pci/host/Kconfig   |   8 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-altera.c | 591 +
 3 files changed, 600 insertions(+)
 create mode 100644 drivers/pci/host/pcie-altera.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..df9ed4f 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
  Say Y here if you want to use the Broadcom iProc PCIe controller
  through the BCMA bus interface
 
+config PCIE_ALTERA
+   tristate "Altera PCIe controller"
+   depends on ARCH_SOCFPGA || NIOS2
+   select PCI_DOMAINS
+   help
+ Say Y here if you want to enable PCIe controller support for Altera
+ SoCFPGA family of SoCs.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6954f76 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
 obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
new file mode 100644
index 000..41cd4fd
--- /dev/null
+++ b/drivers/pci/host/pcie-altera.c
@@ -0,0 +1,591 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define A2P_ADDR_MAP_LO0   0x1000
+#define A2P_ADDR_MAP_HI0   0x1004
+#define RP_TX_REG0 0x2000
+#define RP_TX_REG1 0x2004
+#define RP_TX_CNTRL0x2008
+#define RP_TX_EOP  0x2
+#define RP_TX_SOP  0x1
+#define RP_RXCPL_STATUS0x2010
+#define RP_RXCPL_EOP   0x2
+#define RP_RXCPL_SOP   0x1
+#define RP_RXCPL_REG0  0x2014
+#define RP_RXCPL_REG1  0x2018
+#define P2A_INT_STATUS 0x3060
+#define P2A_INT_STS_ALL0xF
+#define P2A_INT_ENABLE 0x3070
+#define P2A_INT_ENA_ALL0xF
+#define RP_LTSSM   0x3C64
+#define LTSSM_L0   0xF
+
+/* TLP configuration type 0 and 1 */
+#define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 */
+#define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 */
+#define TLP_FMTTYPE_CFGRD1 0x05/* Configuration Read Type 1 */
+#define TLP_FMTTYPE_CFGWR1 0x45/* Configuration Write Type 1 */
+#define TLP_PAYLOAD_SIZE   0x01
+#define TLP_READ_TAG   0x1D
+#define TLP_WRITE_TAG  0x10
+#define TLP_CFG_DW0(fmttype)   (((fmttype) << 24) | TLP_PAYLOAD_SIZE)
+#define TLP_CFG_DW1(reqid, tag)(((reqid) << 16) | (tag << 8) | 
0xF)
+#define TLP_CFG_DW2(bus, devfn, offset)\
+   (((bus) << 24) | ((devfn) << 16) | (offset))
+#define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
+#define TLP_COMPL_STATUS(hdr)  (((hdr) & 0xE0) >> 13)
+#define TLP_HDR_SIZE   3
+#define TLP_LOOP   500
+
+#define INTX_NUM   4
+
+#define DWORD_MASK 3
+
+struct altera_pcie {
+   struct platform_device  *pdev;
+   void __iomem*cra_base;
+   int irq;
+   u8  root_bus_nr;
+   struct irq_domain   *irq_domain;
+   struct resource bus_range;
+   struct list_headresources;
+};
+
+struct tlp_rp_regpair_t {
+   u32 ctrl;
+   u32 reg0;
+   u32 reg1;
+};
+
+static void altera_pcie_retrain(struct pci_dev *dev)
+{
+   u16 linkcap, linkstat;
+
+   /*
+* Set the retrain bit if the PCIe rootport support > 2.5GB/s, but
+* current speed is 2.5 GB/s.
+*/
+   pcie_capability_read_word(dev, PCI_EXP_LNKCAP, );
+
+   if ((linkcap & 

[PATCH v7 2/6] pci: add Altera PCI vendor ID

[Ley Foon Tan]

Signed-off-by: Ley Foon Tan 
---
 include/linux/pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d9ba49c..08e4462 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1550,6 +1550,8 @@
 #define PCI_DEVICE_ID_SERVERWORKS_CSB6LPC 0x0227
 #define PCI_DEVICE_ID_SERVERWORKS_HT1100LD 0x0408
 
+#define PCI_VENDOR_ID_ALTERA   0x1172
+
 #define PCI_VENDOR_ID_SBE  0x1176
 #define PCI_DEVICE_ID_SBE_WANXL100 0x0301
 #define PCI_DEVICE_ID_SBE_WANXL200 0x0302
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 6/6] MAINTAINERS: Add Altera PCIe and MSI drivers maintainer

[Ley Foon Tan]

Signed-off-by: Ley Foon Tan 
---
 MAINTAINERS | 16 
 1 file changed, 16 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..eeb9ec9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7938,6 +7938,14 @@ F:   include/linux/pci*
 F: arch/x86/pci/
 F: arch/x86/kernel/quirks.c
 
+PCI DRIVER FOR ALTERA PCIE IP
+M: Ley Foon Tan 
+L: r...@lists.rocketboards.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/pci/altera-pcie.txt
+F: drivers/pci/host/pcie-altera.c
+
 PCI DRIVER FOR ARM VERSATILE PLATFORM
 M: Rob Herring 
 L: linux-...@vger.kernel.org
@@ -8039,6 +8047,14 @@ L:   linux-...@vger.kernel.org
 S: Maintained
 F: drivers/pci/host/*spear*
 
+PCI MSI DRIVER FOR ALTERA MSI IP
+M: Ley Foon Tan 
+L: r...@lists.rocketboards.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
+F: drivers/pci/host/pcie-altera-msi.c
+
 PCI MSI DRIVER FOR APPLIEDMICRO XGENE
 M: Duc Dang 
 L: linux-...@vger.kernel.org
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 1/6] arm: add msi.h to Kbuild

[Ley Foon Tan]

Include asm-generic/msi.h to support CONFIG_GENERIC_MSI_IRQ_DOMAIN.
This to fix compilation error:
"include/linux/msi.h:123:21: fatal error: asm/msi.h:
No such file or directory"

Signed-off-by: Ley Foon Tan 
---
 arch/arm/include/asm/Kbuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index be648eb..bd42530 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -14,6 +14,7 @@ generic-y += local.h
 generic-y += local64.h
 generic-y += mm-arch-hooks.h
 generic-y += msgbuf.h
+generic-y += msi.h
 generic-y += param.h
 generic-y += parport.h
 generic-y += poll.h
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Rob Herring]

On Fri, Sep 18, 2015 at 12:54 PM, David Daney  wrote:
> On 09/18/2015 01:51 AM, Marc Zyngier wrote:
>>
>> On Thu, 17 Sep 2015 11:00:59 -0700
>> David Daney  wrote:
>>
>> Hi David,
>>
>>> From: David Daney 
>>>
>>> Search up the device hierarchy to find devices with a "msi-map"
>>> property, if found apply the mapping to the GIC device id.

[...]

>>> +   masked_devid = msi_mask & dev_alias.dev_id;
>>> +   matched = false;
>>> +   while (msi_map_len >= 4 * sizeof(__be32)) {
>>> +   rid_base = be32_to_cpup(msi_map + 0);
>>> +   phandle = be32_to_cpup(msi_map + 1);
>>> +   msi_base = be32_to_cpup(msi_map + 2);
>>> +   rid_len = be32_to_cpup(msi_map + 3);
>>
>>
>> Ouch. I wonder if that kind of thing should deserve a generic helper.
>> of_property_read_u32_array_from_index()? Rob, what do you think?
>
>
> I think it is possible to add too many wrapper functions.  IMO, this is not
> too unreadable.

Given you are not reading into an array, I don't think a new helper
would help. You could just use of_property_read_u32_index though.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] arm64: dts: qcom: 8x16: UARTDM additions

[Andy Gross]

On Fri, Sep 18, 2015 at 04:18:52PM +0300, Ivan T. Ivanov wrote:
> Hi,
> 
> This is second version of the changes previously posted [1].
> I have to rebase them on top of Andy's for-next[2] branch and rework them
> a little bit, because some of the definitions have been already merged.
> 
> Regards,
> Ivan
> 
> [1] https://lkml.org/lkml/2015/9/12/114
> [2] https://www.codeaurora.org/cgit/quic/kernel/agross-msm/

Thanks!  I have these applied.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v6 3/3] mfd: add Intel Broxton Whiskey Cove PMIC driver

[Zha, Qipeng]

> > ---
> > change in v6
> >  Replace INIT_REGMAP_IRQ with REGMAP_IRQ_REG.

> If that's all that has changed my Ack can carry:

> Acked-by: Lee Jones 

> Still no Ack for the regmap side though, so still can't apply.
Yes, compare to V5, that's all change for V6.
Mark acked patch set 1 for regmap core change, and need to wait for that's 
applied, right ?
Thanks.

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: Please suggest proper format for DT properties.

[Rob Herring]

On Fri, Sep 18, 2015 at 5:36 PM, Constantine Shulyupin
 wrote:
> Hi,
>
> I am designing DT support for a hwmon chip.
> It has some sensors, each of them can be:
>  - "disabled"
>  - "thermal diode"
>  - "thermistor"
>  - "voltage"
>
> Four possible options for DT properties format.
>
> Option 1: Separated property for each sensor.
>
> Example nct7802 node:
>
> nct7802 {
> compatible = "nuvoton,nct7802";
> reg = <0x2a>;
> nuvoton,sensor1-type = "thermistor";
> nuvoton,sensor2-type = "disabled";
> nuvoton,sensor3-type = "voltage";
> };
>
> Option 2: Array of strings for all sensors.
>
> nct7802 {
> compatible = "nuvoton,nct7802";
> reg = <0x2a>;
> nuvoton,sensors-types = "thermistor", "disabled", "voltage";
> };

It seems you are just listing out all possible modes. Why do you need
this in the DT at all? This can be inferred by the compatible string.

>
> Option 3: Sets of 4 cells.
>
>   Borrowed from marvell,reg-init and broadcom,c45-reg-init.
>
>   The first cell is the page address,
>   the second a register address within the page,
>   the third cell contains a mask to be ANDed with the existing register
>   value, and the fourth cell is ORed with the result to yield the
>   new register value. If the third cell has a value of zero,
>   no read of the existing value is performed.

I don't see how this relates to the first 2 options. The register you
write selects the mode? In general, we don't want bindings of just
random register writes.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] extcon: Fix module autoload for OF platform drivers

[Chanwoo Choi]

Hello Luis,

On 2015년 09월 17일 20:58, Javier Martinez Canillas wrote:
> Hello Luis,
> 
> On 09/17/2015 01:54 PM, Luis de Bethencourt wrote:
>> Hello,
>>
>> These patches add the missing MODULE_DEVICE_TABLE() for OF to export
>> the information so modules have the correct aliases built-in and
>> autoloading works correctly.
>>
>> A longer explanation by Javier Canillas can be found here:
>> https://lkml.org/lkml/2015/7/30/519
>>
>> Thanks,
>> Luis
>>
>> Luis de Bethencourt (2):
>>   extcon: rt8973a: Fix module autoload for OF platform driver
>>   extcon: sm5502: Fix module autoload for OF platform driver
>>
>>  drivers/extcon/extcon-rt8973a.c | 1 +
>>  drivers/extcon/extcon-sm5502.c  | 1 +
>>  2 files changed, 2 insertions(+)
>>
> 
> I already posted the same patch https://patchwork.kernel.org/patch/6904111/
> as a part of the series with fixes for the I2C drivers.
> 
> Best regards,
> 

As Javier said, the same patch was already applied on following branch[1].
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next

Thanks,
Chanwoo Choi


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

[Huang Ying]

On Sun, 2015-09-20 at 19:19 -0600, David Ahern wrote:
> On 9/20/15 6:30 AM, kernel test robot wrote:
> > FYI, we noticed the below changes on
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > master
> > commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support
> > for VRFs to inetpeer cache")
> > 
> > 
> > ===
> > ==
> > tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtim
> > e/nr_threads/cluster/test:
> >lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc
> > -4.9/performance/300s/200%/cs-localhost/TCP_CRR
> > 
> > commit:
> >5345c2e12d41f815c1009c9dee72f3d5fcfd4282
> >192132b9a034d87566294be0fba5f8f75c2cf16b
> > 
> 
> Clarification: The reproduce file shows 128 instances of 'netperf -t 
> TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does
> that 
> mean these 128 commands are run serially?

Sorry.  It's a script bug, there should be a "&" on the end.  Will fix
the script.

> 
> Also, this is the end patch of a series that first refactors and then
> adds a capability. The more relevant comparison is 8f58336d3f78 to 
> 192132b9a034 (8f58336d3f78 is the commit before the series). Is it 
> possible to get this test run on your system comparing those 2
> commits?

Sure.  It is attached with the mail.

Best Regards,
Huang, Ying
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtime/nr_threads/cluster/test:
  
lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/300s/200%/cs-localhost/TCP_CRR

commit: 
  8f58336d3f78aef61c8023c18546155f5fdf3224
  192132b9a034d87566294be0fba5f8f75c2cf16b

8f58336d3f78aef6 192132b9a034d87566294be0fb 
 -- 
 %stddev %change %stddev
 \  |\  
  2825 ±  2% -17.0%   2344 ±  1%  netperf.Throughput_tps
 1.089e+08 ±  2% -16.9%   90493497 ±  1%  
netperf.time.involuntary_context_switches
 1.086e+08 ±  2% -17.0%   90186076 ±  1%  netperf.time.minor_page_faults
  4599 ±  0% +10.1%   5062 ±  1%  
netperf.time.percent_of_cpu_this_job_got
 13112 ±  0% +12.0%  14686 ±  1%  netperf.time.system_time
940.67 ±  2% -16.9% 781.88 ±  1%  netperf.time.user_time
 1.085e+08 ±  2% -17.0%   90055371 ±  1%  
netperf.time.voluntary_context_switches
 4.342e+08 ±  2% -17.0%  3.604e+08 ±  1%  softirqs.NET_RX
  2258 ±  1% +10.4%   2494 ±  4%  uptime.idle
320.54 ±  0%  -2.4% 312.95 ±  0%  turbostat.CorWatt
376.48 ±  0%  -2.0% 368.88 ±  0%  turbostat.PkgWatt
   1420157 ±  2% -16.9%1180769 ±  1%  vmstat.system.cs
 68961 ±  0%  +1.0%  69635 ±  0%  vmstat.system.in
  18193082 ± 11% -14.3%   15594591 ± 16%  cpuidle.C1-SNB.time
   3054463 ± 16% +45.0%4428730 ± 19%  cpuidle.C1E-SNB.time
238.50 ± 29%   +5507.2%  13373 ± 83%  cpuidle.C6-SNB.time
 1.119e+08 ±  2% -16.9%   93008884 ±  1%  proc-vmstat.numa_hit
 1.119e+08 ±  2% -16.9%   93008682 ±  1%  proc-vmstat.numa_local
   6365197 ±  2% -18.4%5191906 ±  2%  proc-vmstat.pgalloc_dma32
  1.07e+08 ±  2% -16.6%   89162443 ±  1%  proc-vmstat.pgalloc_normal
 1.095e+08 ±  2% -16.9%   91044527 ±  1%  proc-vmstat.pgfault
 1.133e+08 ±  2% -16.7%   94305253 ±  1%  proc-vmstat.pgfree
 1.089e+08 ±  2% -16.9%   90493497 ±  1%  time.involuntary_context_switches
 1.086e+08 ±  2% -17.0%   90186076 ±  1%  time.minor_page_faults
  4599 ±  0% +10.1%   5062 ±  1%  time.percent_of_cpu_this_job_got
 13112 ±  0% +12.0%  14686 ±  1%  time.system_time
940.67 ±  2% -16.9% 781.88 ±  1%  time.user_time
 1.085e+08 ±  2% -17.0%   90055371 ±  1%  time.voluntary_context_switches
  28168329 ±  1% -17.9%   23130696 ±  2%  numa-numastat.node0.local_node
  28168412 ±  1% -17.9%   23130763 ±  2%  numa-numastat.node0.numa_hit
  28038183 ±  3% -15.4%   23732122 ±  1%  numa-numastat.node1.local_node
  28038223 ±  3% -15.4%   23732168 ±  1%  numa-numastat.node1.numa_hit
  27687321 ±  2% -17.1%   22948672 ±  2%  numa-numastat.node2.local_node
  27687946 ±  2% -17.1%   22948710 ±  2%  numa-numastat.node2.numa_hit
  27979864 ±  2% -17.1%   23200094 ±  1%  numa-numastat.node3.local_node
  27980945 ±  2% -17.1%   23200610 ±  1%  numa-numastat.node3.numa_hit
  1080 ± 93% -52.3% 515.75 ±157%  numa-numastat.node3.other_node
 90608 ±  2% -11.3%  80327 ±  1%  slabinfo.Acpi-State.active_objs
  1783 ±  2% -11.3%   1581 ±  1%  slabinfo.Acpi-State.active_slabs
 90950 ±  2% -11.3%  80684 ±  1%  slabinfo.Acpi-State.num_objs
  1783 ±  2% -11.3%   1581 ±  1%  slabinfo.Acpi-State.num_slabs
 45161 ±  4% -27.4%  32776 ±  

linux-next: build failure after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

sound/soc/codecs/rt5645.c: In function 'rt5645_i2c_probe':
sound/soc/codecs/rt5645.c:3277:21: error: 'dmi_platform_intel_broadwel' 
undeclared (first use in this function)
dmi_check_system(dmi_platform_intel_broadwel)
 ^
sound/soc/codecs/rt5645.c:3277:21: note: each undeclared identifier is reported 
only once for each function it appears in
sound/soc/codecs/rt5645.c:3278:3: error: expected ')' before 'rt5645'
   rt5645->pdata = *rt5645_pdata;
   ^
sound/soc/codecs/rt5645.c:3478:1: error: expected expression before '}' token
 }
 ^
sound/soc/codecs/rt5645.c:3264:15: warning: unused variable 'val' 
[-Wunused-variable]
  unsigned int val;
   ^
sound/soc/codecs/rt5645.c:3263:11: warning: unused variable 'i' 
[-Wunused-variable]
  int ret, i;
   ^
sound/soc/codecs/rt5645.c:3263:6: warning: unused variable 'ret' 
[-Wunused-variable]
  int ret, i;
  ^
sound/soc/codecs/rt5645.c: At top level:
sound/soc/codecs/rt5645.c:2894:13: warning: 'rt5645_jack_detect_work' defined 
but not used [-Wunused-function]
 static void rt5645_jack_detect_work(struct work_struct *work)
 ^
sound/soc/codecs/rt5645.c:3090:34: warning: 'rt5645_dai' defined but not used 
[-Wunused-variable]
 static struct snd_soc_dai_driver rt5645_dai[] = {
  ^
sound/soc/codecs/rt5645.c:3131:36: warning: 'soc_codec_dev_rt5645' defined but 
not used [-Wunused-variable]
 static struct snd_soc_codec_driver soc_codec_dev_rt5645 = {
^
sound/soc/codecs/rt5645.c:3232:29: warning: 'dmi_platform_intel_broadwell' 
defined but not used [-Wunused-variable]
 static struct snd_soc_codec_driver soc_codec_dev_rt5645 = {
^
sound/soc/codecs/rt5645.c:3232:29: warning: 'dmi_platform_intel_broadwell' 
defined but not used [-Wunused-variable]
 static struct dmi_system_id dmi_platform_intel_broadwell[] __initdata = {
 ^
sound/soc/codecs/rt5645.c:3244:12: warning: 'rt5645_parse_dt' defined but not 
used [-Wunused-function]
 static int rt5645_parse_dt(struct rt5645_priv *rt5645, struct device *dev)
^
sound/soc/codecs/rt5645.c: In function 'rt5645_i2c_probe':
sound/soc/codecs/rt5645.c:3478:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^

Caused by commit

  3dbabe60c832 ("ASoC: rt5645: Add dmi for Broadwell")

I have used the sound-asoc tree from next-20150918 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: at91/dt: ov2640: add hsync/vsync-active property

[Josh Wu]

Hi, Nicolas

On 9/18/2015 10:09 PM, Nicolas Ferre wrote:

Le 18/09/2015 13:28, Josh Wu a écrit :

On at91sam9x5ek/at91sam9m10g45ek/sama5d3xek boards, we use the parallel
connection for ov2640. So we must set the hsync/vsync property (1 means
active high).
Otherwise, the connection would be seen as BT.656 or BT.1120.

Signed-off-by: Josh Wu 

Hi Josh,

Does this patch apply because of the new enhancement that you had
proposed in "media: atmel-isi: parse the DT parameters for
vsync/hsync/pixclock polarity" or does it apply even before?
Is it a fix that applies to older kernels?

It's is a fix, according to the dt binding of video interface.
So it should be applied before:

"media: atmel-isi: parse the DT parameters for
vsync/hsync/pixclock polarity".


it has no impact in older kernel as the driver doesn't parse that 
property yet.




So, should I wait for the enhancements to enter media git tree or can I
take them anyway?


yes, you can take it without waiting for the media tree. Thanks.

Best Regards,
Josh Wu



Bye,


---

  arch/arm/boot/dts/at91sam9m10g45ek.dts | 2 ++
  arch/arm/boot/dts/at91sam9x5ek.dtsi| 2 ++
  arch/arm/boot/dts/sama5d3xmb.dtsi  | 2 ++
  3 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts 
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index d1ae60a..9d16ef8 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -198,6 +198,8 @@
isi_0: endpoint {
remote-endpoint = <_0>;
bus-width = <8>;
+   vsync-active = <1>;
+   hsync-active = <1>;
};
};
};
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi 
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index d237c46..479f200 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -66,6 +66,8 @@
isi_0: endpoint@0 {
remote-endpoint = <_0>;
bus-width = <8>;
+   vsync-active = <1>;
+   hsync-active = <1>;
};
};
};
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi 
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 83bee7a..8901042 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -87,6 +87,8 @@
isi_0: endpoint {
remote-endpoint = <_0>;
bus-width = <8>;
+   vsync-active = <1>;
+   hsync-active = <1>;
};
};
};





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

[David Ahern]

On 9/20/15 6:30 AM, kernel test robot wrote:

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support for VRFs to 
inetpeer cache")


=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/runtime/nr_threads/cluster/test:
   
lkp-sbx04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/300s/200%/cs-localhost/TCP_CRR

commit:
   5345c2e12d41f815c1009c9dee72f3d5fcfd4282
   192132b9a034d87566294be0fba5f8f75c2cf16b



Clarification: The reproduce file shows 128 instances of 'netperf -t 
TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does that 
mean these 128 commands are run serially?


Also, this is the end patch of a series that first refactors and then 
adds a capability. The more relevant comparison is 8f58336d3f78 to 
192132b9a034 (8f58336d3f78 is the commit before the series). Is it 
possible to get this test run on your system comparing those 2 commits?


Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Sep 20, 2015 5:15 PM, "Linus Torvalds"  wrote:
>
> On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski  wrote:
> > This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> > access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
> > We still write a pr_info entry unconditionally for debugging.
>
> No, this is wrong.
>
> If you really want to do something like this, then just make all MSR
> reads safe. So the only difference between "safe" and "unsafe" is that
> the unsafe version just doesn't check the return value, and silently
> just returns zero for reads (or writes nothing).
>
> To quote Obi-Wan: "Use the exception table, Luke".
>
> Because decoding instructions is just too ugly. We'll do it for CPU
> errata where we might have to do it for user space code too (ie the
> AMD prefetch mess), but for code that _we_ control? Hell no.
>
> So NAK on this.

My personal preference is to just not do this at all.  A couple people
disagree.  If we make the unsafe variants not oops, then I think we
want to have the nice loud warning, since these issues are bugs if
they happen.

We could certainly use the exception table for this, but it'll result
in bigger core, since each MSR access will need an exception table
entry and an associated fixup to call some helper that warns and sets
the result to zero.

I'd be happy to implement that, but only if it'll be applied.
Otherwise I'd rather just drop this patch and keep the rest of the
series.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] perf record: Synthesize COMM event for a command line workload

[Namhyung Kim]

When perf creates a new child to profile, the events are enabled on
exec().  And in this case, it doesn't synthesize any event for the
child since they'll be generated during exec().  But there's an window
between the enabling and the event generation.

It used to be overcome since samples are only in kernel (so we always
have the map) and the comm is overridden by a later COMM event.
However it won't work if events are processed and displayed before the
COMM event overrides like in 'perf script'.  This leads to those early
samples (like native_write_msr_safe) not having a comm but pid (like
':15328').

So it needs to synthesize COMM event for the child explicitly before
enabling so that it can have a correct comm.  But at this time, the
comm will be "perf" since it's not exec-ed yet.

Acked-by: Jiri Olsa 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 142eeb341b29..b83373adb9f8 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -469,6 +469,43 @@ static void workload_exec_failed_signal(int signo 
__maybe_unused,
child_finished = 1;
 }
 
+static int synthesize_workload_comm_event(struct perf_evlist *evlist, void 
*arg)
+{
+   union perf_event *event;
+   struct record *rec = arg;
+   struct machine *machine = >session->machines.host;
+   int pid = evlist->workload.pid;
+   const char *comm_str = program_invocation_short_name;
+   size_t comm_size, total_size;
+   int ret;
+
+   comm_size = PERF_ALIGN(strlen(comm_str) + 1, sizeof(u64));
+   total_size = sizeof(event->comm) + machine->id_hdr_size;
+   /*
+* (aligned) comm size might be smaller than expected size
+* (i.e.  size of event->comm.comm[]), in that case it needs
+* to shrink the total size.
+*/
+   if (comm_size < sizeof(event->comm.comm))
+   total_size -= sizeof(event->comm.comm) - comm_size;
+
+   event = zalloc(total_size);
+   if (event == NULL)
+   return -ENOMEM;
+
+   event->comm.header.type = PERF_RECORD_COMM;
+   event->comm.header.size = total_size;
+
+   event->comm.pid = pid;
+   event->comm.tid = pid;
+   strncpy(event->comm.comm, comm_str, comm_size);
+
+   ret = record__write(rec, event, total_size);
+
+   free(event);
+   return ret;
+}
+
 static void snapshot_sig_handler(int sig);
 
 static int __cmd_record(struct record *rec, int argc, const char **argv)
@@ -637,7 +674,9 @@ static int __cmd_record(struct record *rec, int argc, const 
char **argv)
 * Let the child rip
 */
if (forks)
-   perf_evlist__start_workload(rec->evlist);
+   perf_evlist__start_workload_ex(rec->evlist,
+  synthesize_workload_comm_event,
+  rec);
 
if (opts->initial_delay) {
usleep(opts->initial_delay * 1000);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] perf tools: Introduce perf_evlist__start_workload_ex()

[Namhyung Kim]

The perf_evlist__start_workload_ex() does same as __start_work() but
also invokes callback which does additional work for each command.

Acked-by: Jiri Olsa 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/evlist.c | 11 +++
 tools/perf/util/evlist.h |  4 
 2 files changed, 15 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index a8643735dcea..12b32a059772 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1593,6 +1593,17 @@ int perf_evlist__start_workload(struct perf_evlist 
*evlist)
return 0;
 }
 
+int perf_evlist__start_workload_ex(struct perf_evlist *evlist,
+  workload_callback_t callback, void *arg)
+{
+   int ret = callback(evlist, arg);
+
+   if (ret == 0)
+   ret = perf_evlist__start_workload(evlist);
+
+   return ret;
+}
+
 int perf_evlist__parse_sample(struct perf_evlist *evlist, union perf_event 
*event,
  struct perf_sample *sample)
 {
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 115d8b53c601..a8ee12c54195 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -128,6 +128,10 @@ int perf_evlist__prepare_workload(struct perf_evlist 
*evlist,
 void *ucontext));
 int perf_evlist__start_workload(struct perf_evlist *evlist);
 
+typedef int (*workload_callback_t)(struct perf_evlist *evlist, void *arg);
+int perf_evlist__start_workload_ex(struct perf_evlist *evlist,
+  workload_callback_t callback, void *arg);
+
 struct option;
 
 int __perf_evlist__parse_mmap_pages(unsigned int *mmap_pages, const char *str);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Linus Torvalds]

On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski  wrote:
> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
> We still write a pr_info entry unconditionally for debugging.

No, this is wrong.

If you really want to do something like this, then just make all MSR
reads safe. So the only difference between "safe" and "unsafe" is that
the unsafe version just doesn't check the return value, and silently
just returns zero for reads (or writes nothing).

To quote Obi-Wan: "Use the exception table, Luke".

Because decoding instructions is just too ugly. We'll do it for CPU
errata where we might have to do it for user space code too (ie the
AMD prefetch mess), but for code that _we_ control? Hell no.

So NAK on this.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/2] x86/msr: MSR access failure changes

[Andy Lutomirski]

This applies on top of my earlier paravirt MSR series.

Changes from v1:
 - Return zero instead of poison on bad RDMSRs.

Andy Lutomirski (2):
  x86/msr: Carry on after a non-"safe" MSR access fails without
!panic_on_oops
  x86/msr: Set the return value to zero when native_rdmsr_safe fails

 arch/x86/include/asm/msr.h |  5 -
 arch/x86/kernel/traps.c| 55 ++
 2 files changed, 59 insertions(+), 1 deletion(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] x86/msr: Set the return value to zero when native_rdmsr_safe fails

[Andy Lutomirski]

This will cause unchecked native_rdmsr_safe failures to return
deterministic results.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/msr.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 77d8b284e4a7..9eda52205d42 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -73,7 +73,10 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
asm volatile("2: rdmsr ; xor %[err],%[err]\n"
 "1:\n\t"
 ".section .fixup,\"ax\"\n\t"
-"3:  mov %[fault],%[err] ; jmp 1b\n\t"
+"3: mov %[fault],%[err]\n\t"
+"xorl %%eax, %%eax\n\t"
+"xorl %%edx, %%edx\n\t"
+"jmp 1b\n\t"
 ".previous\n\t"
 _ASM_EXTABLE(2b, 3b)
 : [err] "=r" (*err), EAX_EDX_RET(val, low, high)
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

This demotes an OOPS and likely panic due to a failed non-"safe" MSR
access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
We still write a pr_info entry unconditionally for debugging.

To be clear, this type of failure should *not* happen.  This patch
exists to minimize the chance of nasty undebuggable failures due on
systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/traps.c | 55 +
 1 file changed, 55 insertions(+)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 346eec73f7db..f82987643e32 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -437,6 +437,58 @@ exit_trap:
do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, NULL);
 }
 
+static bool paper_over_kernel_gpf(struct pt_regs *regs)
+{
+   /*
+* Try to decode the opcode that failed.  So far, we only care
+* about boring two-byte unprefixed opcodes, so we don't need
+* the full instruction decoder machinery.
+*/
+   u16 opcode;
+
+   if (probe_kernel_read(, (const void *)regs->ip, sizeof(opcode)))
+   return false;
+
+   if (opcode == 0x320f) {
+   /* RDMSR */
+   pr_info("bad kernel RDMSR from non-existent MSR 0x%x",
+   (unsigned int)regs->cx);
+   if (!panic_on_oops) {
+   WARN_ON_ONCE(true);
+
+   /*
+* Pretend that RDMSR worked and returned zero.  We
+* chose zero because zero seems less likely to
+* cause further malfunctions than any other value.
+*/
+   regs->ax = 0;
+   regs->dx = 0;
+   regs->ip += 2;
+   return true;
+   } else {
+   /* Don't fix it up. */
+   return false;
+   }
+   } else if (opcode == 0x300f) {
+   /* WRMSR */
+   pr_info("bad kernel WRMSR writing 0x%08x%08x to MSR 0x%x",
+   (unsigned int)regs->dx, (unsigned int)regs->ax,
+   (unsigned int)regs->cx);
+   if (!panic_on_oops) {
+   WARN_ON_ONCE(true);
+
+   /* Pretend it worked and carry on. */
+   regs->ip += 2;
+   return true;
+   } else {
+   /* Don't fix it up. */
+   return false;
+   }
+   }
+
+   return false;
+}
+
 dotraplinkage void
 do_general_protection(struct pt_regs *regs, long error_code)
 {
@@ -456,6 +508,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
if (fixup_exception(regs))
return;
 
+   if (paper_over_kernel_gpf(regs))
+   return;
+
tsk->thread.error_code = error_code;
tsk->thread.trap_nr = X86_TRAP_GP;
if (notify_die(DIE_GPF, "general protection fault", regs, 
error_code,
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 7/9] zram: pass zstrm down to decompression path

[Minchan Kim]

On Fri, Sep 18, 2015 at 02:19:22PM +0900, Joonsoo Kim wrote:
> From: Sergey Senozhatsky 
> 
> Introduce zcomp_decompress_begin()/zcomp_decompress_end() as a
> preparation for crypto API-powered zcomp.
> 
> Change zcomp_decompress() signature to require zstrm parameter.
> 
> Unlike zcomp_compress_begin(), zcomp_decompress_begin() may return
> zstrm if currently selected compression backend require zstrm for
> decompression or NULL if it does not.
> 
> Signed-off-by: Sergey Senozhatsky 
> Signed-off-by: Joonsoo Kim 
Acked-by: Minchan Kim 

There is a trivial comment below.

> ---
>  drivers/block/zram/zcomp.c|  3 ++-
>  drivers/block/zram/zcomp.h|  3 ++-
>  drivers/block/zram/zram_drv.c | 20 
>  3 files changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index fc13bf2..3456d5a 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -336,7 +336,8 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm 
> *zstrm,
>   zstrm->private);
>  }
>  
> -int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
> +int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
> + const unsigned char *src,
>   size_t src_len, unsigned char *dst)
>  {
>   return comp->backend->decompress(src, src_len, dst);
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index 616e013..4c09c01 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -66,7 +66,8 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm 
> *zstrm,
>  struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp);
>  void zcomp_decompress_end(struct zcomp *comp, struct zcomp_strm *zstrm);
>  
> -int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
> +int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
> + const unsigned char *src,
>   size_t src_len, unsigned char *dst);
>  
>  bool zcomp_set_max_streams(struct zcomp *comp, int num_strm);
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 20c41ed..55e09db1 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -560,7 +560,8 @@ static void zram_free_page(struct zram *zram, size_t 
> index)
>   zram_set_obj_size(meta, index, 0);
>  }
>  
> -static int zram_decompress_page(struct zram *zram, char *mem, u32 index)
> +static int zram_decompress_page(struct zram *zram, struct zcomp_strm *zstrm,
> + char *mem, u32 index)
>  {
>   int ret = 0;
>   unsigned char *cmem;
> @@ -582,7 +583,7 @@ static int zram_decompress_page(struct zram *zram, char 
> *mem, u32 index)
>   if (size == PAGE_SIZE)
>   copy_page(mem, cmem);
>   else
> - ret = zcomp_decompress(zram->comp, cmem, size, mem);
> + ret = zcomp_decompress(zram->comp, zstrm, cmem, size, mem);
>   zs_unmap_object(meta->mem_pool, handle);
>   bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
>  
> @@ -602,6 +603,7 @@ static int zram_bvec_read(struct zram *zram, struct 
> bio_vec *bvec,
>   struct page *page;
>   unsigned char *user_mem, *uncmem = NULL;
>   struct zram_meta *meta = zram->meta;
> + struct zcomp_strm *zstrm = NULL;

No need to initialize with NULL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 6/9] zram: make stream find and release functions static

[Minchan Kim]

On Fri, Sep 18, 2015 at 02:19:21PM +0900, Joonsoo Kim wrote:
> From: Sergey Senozhatsky 
> 
> Hide (make static) zstrm find and release function and introduce
> zcomp_compress_begin()/zcomp_compress_end(). We will have begin
> and end functions around compression (this patch) and decompression
> (next patch). So the work flow is evolving to:
> 
>   zstrm = foo_begin();
>   foo(zstrm);
>   foo_end(zstrm);
> 
> where foo is compress or decompress zcomp functions.
> 
> This patch is a preparation to make crypto API-powered zcomp
> possible. The reasoning is that some crypto compression backends
> require zstrm for decompression.
> 
> Signed-off-by: Sergey Senozhatsky 
> Signed-off-by: Joonsoo Kim 
Acked-by: Minchan Kim 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] x86: NMI vs paravirt fixes

[Andy Lutomirski]

These are for x86/urgent.

This fixes at least one problem that Sasha can trigger using some
crazy configuration + Trinity.  I can't reproduce the full file of
nastiness that he's seeing, but these patches both look legit to me,
they fix what look like real bugs, and they seem to help Sasha's
tests.

Patch 1 is ugly.  Feel free to tell me to shove the asm into the
entry asm files, although that will involve duplicating it for
32-bit and 64-bit kernels.

Andy Lutomirski (2):
  x86/paravirt: Replace the paravirt nop with a bona fide empty function
  x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code

 arch/x86/entry/entry_64.S  | 16 +++-
 arch/x86/kernel/paravirt.c | 16 
 2 files changed, 27 insertions(+), 5 deletions(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code

[Andy Lutomirski]

The NMI entry code that switches to the normal kernel stack needs to
be very careful not to clobber any extra stack slots on the NMI
stack.  The code is fine under the assumption that SWAPGS is just a
normal instruction, but that assumption isn't really true.  Use
SWAPGS_UNSAFE_STACK instead.

This is part of a fix for some random crashes that Sasha saw.

Fixes: 9b6e6a8334d5 ("x86/nmi/64: Switch stacks on userspace NMI entry")
Cc: sta...@vger.kernel.org
Reported-and-tested-by: Sasha Levin 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/entry_64.S | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index f7492133a7bb..2c61e8070ba4 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1205,9 +1205,12 @@ ENTRY(nmi)
 * we don't want to enable interrupts, because then we'll end
 * up in an awkward situation in which IRQs are on but NMIs
 * are off.
+*
+* We also must not push anything to the stack before switching
+* stacks lest we corrupt the "NMI executing" variable.
 */
 
-   SWAPGS
+   SWAPGS_UNSAFE_STACK
cld
movq%rsp, %rdx
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] x86/paravirt: Replace the paravirt nop with a bona fide empty function

[Andy Lutomirski]

PARAVIRT_ADJUST_EXCEPTION_FRAME generates this code (using nmi as an
example, trimmed for readability):

ff 15 00 00 00 00   callq  *0x0(%rip)# 2796 
  2792: R_X86_64_PC32 pv_irq_ops+0x2c

That's a call through a function pointer to regular C function that
does nothing on native boots, but that function isn't protected
against kprobes, isn't marked notrace, and is certainly not
guaranteed to preserve any registers if the compiler is feeling
perverse.  This is bad news for a CLBR_NONE operation.

Of course, if everything works correctly, once paravirt ops are
patched, it gets nopped out, but what if we hit this code before
paravirt ops are patched in?  This can potentially cause breakage
that is very difficult to debug.

A more subtle failure is possible here, too: if _paravirt_nop uses
the stack at all (even just to push RBP), it will overwrite the "NMI
executing" variable if it's called in the NMI prologue.

The Xen case, perhaps surprisingly, is fine, because it's already
written in asm.

Fix all of the cases that default to paravirt_nop (including
adjust_exception_frame) with a big hammer: replace paravirt_nop with
an asm function that is just a ret instruction.

The Xen case may have other problems, so document them.

This is part of a fix for some random crashes that Sasha saw.

Cc: sta...@vger.kernel.org
Reported-and-tested-by: Sasha Levin 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/entry_64.S  | 11 +++
 arch/x86/kernel/paravirt.c | 16 
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a25ac7afc951..f7492133a7bb 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1135,7 +1135,18 @@ END(error_exit)
 
 /* Runs on exception stack */
 ENTRY(nmi)
+   /*
+* Fix up the exception frame if we're on Xen.
+* PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most
+* one value to the stack on native, so it may clobber the rdx
+* scratch slot, but it won't clobber any of the important
+* slots past it.
+*
+* Xen is a different story, because the Xen frame itself overlaps
+* the "NMI executing" variable.
+*/
PARAVIRT_ADJUST_EXCEPTION_FRAME
+
/*
 * We allow breakpoints in NMIs. If a breakpoint occurs, then
 * the iretq it performs will take us out of NMI context.
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index f68e48f5f6c2..c2130aef3f9d 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -41,10 +41,18 @@
 #include 
 #include 
 
-/* nop stub */
-void _paravirt_nop(void)
-{
-}
+/*
+ * nop stub, which must not clobber anything *including the stack* to
+ * avoid confusing the entry prologues.
+ */
+extern void _paravirt_nop(void);
+asm (".pushsection .entry.text, \"ax\"\n"
+ ".global _paravirt_nop\n"
+ "_paravirt_nop:\n\t"
+ "ret\n\t"
+ ".size _paravirt_nop, . - _paravirt_nop\n\t"
+ ".type _paravirt_nop, @function\n\t"
+ ".popsection");
 
 /* identity function, which can be inlined */
 u32 _paravirt_ident_32(u32 x)
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

[Marcelo Tosatti]

On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote:
> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is
> RFC because I haven't explored many potential problems or tested it.

The justification to disable PVCLOCK_COUNTS_FROM_ZERO is because you
haven't explored potential problems or tested it? Sorry can't parse it.

> 
> [1/2] uses a different algorithm in the guest to start counting from 0.
> [2/2] stops exposing PVCLOCK_COUNTS_FROM_ZERO in the hypervisor.
> 
> A viable alternative would be to implement opt-in features in kvm clock.
> 
> And because we probably only broke one old user (the infamous SLES 10), a
> workaround like this is also possible: (but I'd rather not do that)

Please describe why SLES 10 breaks in detail: the state of the guest and
the host before the patch, the state of the guest and host after the
patch.

What does SLES10 expect?
Is it counting from zero that breaks SLES10? 

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index a60bdbccff51..ae9049248aaf 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2007,7 +2007,8 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>  
>   ka->boot_vcpu_runs_old_kvmclock = tmp;
>  
> - ka->kvmclock_offset = -get_kernel_ns();
> + if (!ka->boot_vcpu_runs_old_kvmclock)
> + ka->kvmclock_offset = -get_kernel_ns();
>   }
>  
>   vcpu->arch.time = data;
> 
> 
> Radim Krčmář (2):
>   x86: kvmclock: abolish PVCLOCK_COUNTS_FROM_ZERO
>   Revert "KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock
> system MSR"
> 
>  arch/x86/include/asm/pvclock-abi.h |  1 +
>  arch/x86/kernel/kvmclock.c | 46 
> +-
>  arch/x86/kvm/x86.c |  4 
>  3 files changed, 36 insertions(+), 15 deletions(-)
> 
> -- 
> 2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thunderbolt: Allow loading of module on recent Apple MacBooks with thunderbolt 2 controller

[Greg KH]

On Sun, Sep 20, 2015 at 09:25:22PM +0200, Knuth Posern wrote:
> The pci device ids listed in the thunderbolt driver are to restrictive,
> which prevents the driver from being loaded on recent Apple MacBooks
> using a thunderbolt 2 controller. In particular this prevented any
> hot-plugging functionality for thunderbolt based ethernet dongles
> (i.e. Apples thunderbolt gigabit ethernet broadcom tg3 based dongle
> Model A1433 EMC 2590).
> 
> Changing the subvendor and subdevice to PCI_ANY_ID the thunderbolt driver
> loads and binds to the pci device 07:00.0 System peripheral:
> Intel Corporation Device 156c which is the thunderbolt 2 controller on
> the MacBookPro12,1.
> 
> Successfully tested on MacBookPro12,1. With the patch the thunderbolt
> module gets now loaded on boot. And it provides hot-plugging support both
> for a cold-plugged and a warm-plugged ethernet dongle.
> 
> Signed-off-by: Andreas Noever 
> Acked-by: Knuth Posern 
> ---
> 
> ... never 2 without 3 ;)

Thanks for being persistent, that worked fine and is now queued up, you
should have received an email with all of the details.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.2 000/120] 4.2.1-stable review

[Greg Kroah-Hartman]

On Sun, Sep 20, 2015 at 08:52:25PM +0200, Hans-Peter Jansen wrote:
> Dear Greg,
> 
> FYI, this revision seems to be missing https://lkml.org/lkml/2015/9/3/411
> 
> [PATCH 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL 
> modules
> 
> which actually defers 4.2 rollout for some cases, hence for 4.2.1 too.

I still have 200+ patches to go through for the 4.2-stable series.
Patches that are submitted for -rc1 merging obviously must not be all
that series for maintainers, otherwise they would have gotten them
merged into the -final release, so take it up with the author/maintainer
of this patch :)

In other words, be patient, it will make it into some future 4.2-stable
release.  If you _must_ have this patch now, it's trivial for you to add
it to your own kernels that you build.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement

[Leo Yan]

On Sun, Sep 20, 2015 at 11:39:16AM -0700, Steve Muckle wrote:
> On 09/18/2015 03:34 AM, Dietmar Eggemann wrote:
> >> Here should consider scenario for two groups have same capacity?
> >> This will benefit for the case LITTLE.LITTLE. So the code will be
> >> looks like below:
> >>
> >>int target_sg_cpu = INT_MAX;
> >>
> >>if (capacity_of(max_cap_cpu) <= target_max_cap &&
> >> task_fits_capacity(p, max_cap_cpu)) {
> >>
> >> if ((capacity_of(max_cap_cpu) == target_max_cap) &&
> >>(target_sg_cpu < max_cap_cpu))
> >>continue;
> >>
> >>target_sg_cpu = max_cap_cpu;
> >>sg_target = sg;
> >>target_max_cap = capacity_of(max_cap_cpu);
> >>}
> >>
> > 
> > It's true that on your SMP system the target sched_group 'sg_target'
> > depends only on 'task_cpu(p)' because this determines sched_domain 'sd'
> > (and so the order of sched_groups for the iteration).
> > 
> > So the current do-while loop to select 'sg_target' for an SMP system
> > makes little sense.
> > 
> > But why should we favour the first sched_group (cluster) (the one w/ the
> > lower max_cap_cpu number) in this situation?
> 
> Running the originally proposed code on a system with two identical
> clusters, it looks like we'll always end up doing an energy-aware search
> in the task's prev_cpu cluster (sched_group). If you had small tasks
> scattered across both clusters, energy_aware_wake_cpu() would not
> consider condensing them on a single cluster. Leo was this the issue you
> were seeing?

Exactly.

> However I think there may be negative side effects with the proposed
> policy above as well - won't this cause us to pack the first cluster
> until it's 100% full (running at fmax) before using the second cluster?
> That would also be bad for power.

In this case of CPU is running at fmax, it's true that
task_fits_capacity() will return true. But here i think
cpu_overutilized() also will return true, so that means scheduler will
go back to use CFS's old way for loading balance. Finally tasks also
will be spread into two clusters.

Also reviewed the profiling result on Hikey with this modification
[1], rt-app 6%/13%/19%/25% place 8 tasks into one cluster as
possible, but rt-app 31%/38%/44%/50% also will place tasks to second
cluster. NOTE, I get this conclusion from CPU idle's duty cycle, but
not from real power data.

[1] https://lists.linaro.org/pipermail/eas-dev/2015-September/000218.html

Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/