[tip:irq/core] irqchip/GIC: Fix EOImode setting for non-DT/ ACPI systems

[tip-bot for Marc Zyngier]

Commit-ID:  4a6ac3044f1504fe4521efa7334095c9c9ceecfd
Gitweb: http://git.kernel.org/tip/4a6ac3044f1504fe4521efa7334095c9c9ceecfd
Author: Marc Zyngier 
AuthorDate: Tue, 1 Sep 2015 10:08:53 +0100
Committer:  Thomas Gleixner 
CommitDate: Tue, 1 Sep 2015 18:56:25 +0200

irqchip/GIC: Fix EOImode setting for non-DT/ACPI systems

Non-DT/ACPI systems call directly into the GIC driver at init time.
Turns out 0b996fd35957 ("irqchip/GIC: Convert to EOImode == 1")
breaks old non firmware-driven platforms, as the driver only
works out the capability of the platform on the DT/ACPI paths.

Fix this thinko by forcing EOImode==0 on non-DT platforms,
which are not capable of supporting a hypervisor anyway.

Reported-and-tested-by: Guenter Roeck 
Signed-off-by: Marc Zyngier 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Jason Cooper 
Link: 
http://lkml.kernel.org/r/1441098533-31523-1-git-send-email-marc.zyng...@arm.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-gic.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 72bf81b..e6b7ed5 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -993,7 +993,7 @@ static const struct irq_domain_ops gic_irq_domain_ops = {
.xlate = gic_irq_domain_xlate,
 };
 
-void __init gic_init_bases(unsigned int gic_nr, int irq_start,
+static void __init __gic_init_bases(unsigned int gic_nr, int irq_start,
   void __iomem *dist_base, void __iomem *cpu_base,
   u32 percpu_offset, struct device_node *node)
 {
@@ -1103,6 +1103,19 @@ void __init gic_init_bases(unsigned int gic_nr, int 
irq_start,
gic_pm_init(gic);
 }
 
+void __init gic_init_bases(unsigned int gic_nr, int irq_start,
+  void __iomem *dist_base, void __iomem *cpu_base,
+  u32 percpu_offset, struct device_node *node)
+{
+   /*
+* Non-DT/ACPI systems won't run a hypervisor, so let's not
+* bother with these...
+*/
+   static_key_slow_dec(_deactivate);
+   __gic_init_bases(gic_nr, irq_start, dist_base, cpu_base,
+percpu_offset, node);
+}
+
 #ifdef CONFIG_OF
 static int gic_cnt __initdata;
 
@@ -1137,7 +1150,7 @@ gic_of_init(struct device_node *node, struct device_node 
*parent)
if (of_property_read_u32(node, "cpu-offset", _offset))
percpu_offset = 0;
 
-   gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset, node);
+   __gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset, node);
if (!gic_cnt)
gic_init_physaddr(node);
 
@@ -1265,7 +1278,7 @@ gic_v2_acpi_init(struct acpi_table_header *table)
 * as default IRQ domain to allow for GSI registration and GSI to IRQ
 * number translation (see acpi_register_gsi() and acpi_gsi_to_irq()).
 */
-   gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
+   __gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
irq_set_default_host(gic_data[0].domain);
 
acpi_irq_model = ACPI_IRQ_MODEL_GIC;
--
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: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[Pinski, Andrew]

> On Sep 2, 2015, at 12:51 AM, "pins...@gmail.com"  wrote:
> 
> 
> 
> 
> 
>> On Sep 2, 2015, at 12:33 AM, Mark Rutland  wrote:
>> 
>> Hi,
>> 
>>> On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
>>> It is useful to pass down MIDR register down to userland if all of
>>> the online cores are all the same type.  This adds AT_ARM64_MIDR
>>> aux vector type and passes down the midr system register.
>>> 
>>> This is alternative to MIDR_EL1 part of
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
>>> It allows for faster access to midr_el1 than going through a trap and
>>> does not exist if the set of cores are not the same.
>> 
>> I'm not sure I follow the rationale. If speed is important the
>> application can cache the value the first time it reads it with a trap.
> 
> It is also about compatibility also. Exposing the register is not backwards 
> compatible but using the aux vector is. 

That would also break big.little too. So either break it with hot plug or break 
it in userland, your choice. 


> 
>> 
>> This also means that the behaviour is different across homogeneous and
>> heterogeneous systems.

That should be ok because it is still backwards compatible with what was done 
before.  My goal here is just to allow quick easy access to midr in the case of 
a homogeneous system which I care about, thunderx and to allow glibc to select 
a memcpy/memset that is better for thunderx. 

Thanks,
Andrew

>> 
>>> Changes from v1:
>>> Forgot to include the auxvec.h part.
>>> 
>>> Signed-off-by: Andrew Pinski 
>>> ---
>>> arch/arm64/include/asm/cpu.h |1 +
>>> arch/arm64/include/asm/elf.h |6 ++
>>> arch/arm64/include/uapi/asm/auxvec.h |3 +++
>>> arch/arm64/kernel/cpuinfo.c  |   22 ++
>>> 4 files changed, 32 insertions(+)
>>> 
>>> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
>>> index 8e797b2..fab0aa1 100644
>>> --- a/arch/arm64/include/asm/cpu.h
>>> +++ b/arch/arm64/include/asm/cpu.h
>>> @@ -62,5 +62,6 @@ DECLARE_PER_CPU(struct cpuinfo_arm64, cpu_data);
>>> 
>>> void cpuinfo_store_cpu(void);
>>> void __init cpuinfo_store_boot_cpu(void);
>>> +u32 get_arm64_midr(void);
>>> 
>>> #endif /* __ASM_CPU_H */
>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>> index faad6df..d3549de 100644
>>> --- a/arch/arm64/include/asm/elf.h
>>> +++ b/arch/arm64/include/asm/elf.h
>>> @@ -17,6 +17,7 @@
>>> #define __ASM_ELF_H
>>> 
>>> #include 
>>> +#include 
>>> 
>>> /*
>>> * ELF register definitions..
>>> @@ -138,8 +139,13 @@ typedef struct user_fpsimd_state elf_fpregset_t;
>>> 
>>> #define ARCH_DLINFO\
>>> do {\
>>> +u32 midr;\
>>> +\
>>>   NEW_AUX_ENT(AT_SYSINFO_EHDR,\
>>>   (elf_addr_t)current->mm->context.vdso);\
>>> +midr = get_arm64_midr();\
>>> +if (midr != 0)\
>>> +NEW_AUX_ENT(AT_ARM64_MIDR, (elf_addr_t)midr);\
>>> } while (0)
>>> 
>>> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
>>> diff --git a/arch/arm64/include/uapi/asm/auxvec.h 
>>> b/arch/arm64/include/uapi/asm/auxvec.h
>>> index 22d6d88..dc55c56 100644
>>> --- a/arch/arm64/include/uapi/asm/auxvec.h
>>> +++ b/arch/arm64/include/uapi/asm/auxvec.h
>>> @@ -19,4 +19,7 @@
>>> /* vDSO location */
>>> #define AT_SYSINFO_EHDR33
>>> 
>>> +/* Machine IDenfier Register (MDIR). */
>>> +#define AT_ARM64_MIDR 38
>>> +
>>> #endif
>>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>>> index 75d5a86..b14c87d 100644
>>> --- a/arch/arm64/kernel/cpuinfo.c
>>> +++ b/arch/arm64/kernel/cpuinfo.c
>>> @@ -254,3 +254,25 @@ void __init cpuinfo_store_boot_cpu(void)
>>> 
>>>   boot_cpu_data = *info;
>>> }
>>> +
>>> +u32 get_arm64_midr(void)
>>> +{
>>> +int i;
>>> +u32 midr = 0;
>>> +
>>> +for_each_online_cpu(i) {
>>> +struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
>>> +u32 oldmidr = midr;
>>> +
>>> +midr = cpuinfo->reg_midr;
>>> +/*
>>> + * If there are cpus which have a different
>>> + * midr just return 0.
>>> + */
>>> +if (oldmidr && oldmidr != midr)
>>> +return 0;
>>> +}
>>> +
>>> +return midr;
>>> +}
>> 
>> If I have a big.LITTLE system where all the big CPUs are currently
>> offline, this will leave the MIDR the little CPUs in the auxvec.
>> However, at any point after this has run, I could hotplug the big CPUs
>> on and the little CPUs off, leaving this reporting a MIDR that
>> represents none of the online CPUs.
>> 
>> Given big.LITTLE and the potential for physical/dynamic hotplug (where
>> we won't know all the MIDRs in advance), I don't think that we can
>> generally expose a common MIDR in this fashion, and I 

Re: [PATCH] mm: Change global memory state symbols to GPL-only

[Richard Yao]

I seem to have botched the reply headers, so I am resending this. I use mutt
fairly infrequently, but I am making an effort to use it more it more.

On Tue, Sep 01, 2015 at 02:21:43PM +0100, Ben Hutchings wrote:
> On Tue, 2015-09-01 at 01:24 +, Richard Yao wrote:
> > On Mon, 2015-08-17 09:56:55 -0700, Ben Hutchings wrote:
> > > On Mon, 2015-08-17 at 17:11 +0200, Michal Hocko wrote:
> > > > On Mon 17-08-15 16:56:32, Ben Hutchings wrote:
> > > > > On Mon, 2015-08-17 at 15:54 +0200, Michal Hocko wrote:
> > > > > > On Sun 16-08-15 01:42:27, Ben Hutchings wrote:
> > > > > > > Proprietary modules should not be able to touch vm_stat or 
> > > > > > > participate
> > > > > > > in shrinking.
> > > > > > 
> > > > > > How does the external and !GPL fs does slab reclaim? Those 
> > > > > > are essential
> > > > > > for the proper memory balancing.
> > > > > 
> > > > > If they know how to do shrinking on Linux then they are 
> > > > > probably
> > > > > derivative works of Linux.
> > > > 
> > > > I am not sure I understand. They are shrinking their internal 
> > > > cached
> > > > objects and that is hardly a derivative work. The shrinker API is 
> > > > only
> > > > meant to let them know _when_ this should happen and the 
> > > > interface is
> > > > a pretty much simple callback API.
> > > 
> > > It is a Linux-specific API and I don't think other kernels provide
> > > something similar to loadable modules.  It enables a module to turn 
> > > a
> > > large part of the system RAM into a cache and have the MM 
> > > effectively
> > > tell it the correct size of that cache, thus tightly integrating 
> > > with
> > > global memory management.
> > 
> > The idea of providing third party drivers with the hooks that they 
> > need to
> > respond to memory pressure is by no means Linux-specific. In 
> > OpenSolaris, there
> > are counters for drivers to keep track of memory usage and try to 
> > stay ahead of
> > it, which works because there is no direct reclaim. There are also 
> > callbacks
> > for the SLAB code to defragment the caches used by the drivers. 
> 
> 
> So you confirm that the Linux and Solaris APIs for this are quite
> different.

They both have VFS implementations, but the designs are different. According to
attorneys, adapting code to port a filesystem driver from a foreign VFS to the
Linux VFS to make a port is insufficient to form a derived work of Linux. All
kernels have memory management and preferred ways of dealing with pressure.
Using the preferred way of dealing with it should be similarly insufficient to
form a derived work of Linux.

> > Giving non-GPL
> > drivers to respond to memory pressure seems reasonable.
> 
> I don't see why.

It is an existing function and it is needs to be avaliable to allow third party
drivers to be good citizens inside the kernel.

I do not know all of the filesystems whose memory management will become worse
from this, but I know that ZFS is one. Lustre is another because it hooks into
ZFS. I am told that the OpenAFS client uses this too..

> > > Yes, that's the idea, proprietary code should not be helped in this
> > > way.
> > 
> > The ZFSOnLinux kernel driver uses these symbols. It is fully open 
> > source and
> > not proprietary.
> [...]
> 
> It's not GPL-compatible, which in terms of Linux kernel modules is no
> better than proprietary.

Any code under a F/OSS license follows the OSD, which means that it is under a
better license than proprietary code:

http://opensource.org/definition

Rather than sabotaging working code (especially working F/OSS code), maybe it
would be better to ask why it being used instead of code under your preferred
license and invest energy into developing better alternatives under licenses
that you prefer. If someone makes something better, people would use it and
developers will flock to it. Artificially damaging competition does not help
anyone.
--
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 -next] rtc: drop unused ret variable orphaned by misc_deregister becoming void

[Geert Uytterhoeven]

On Sat, Aug 22, 2015 at 9:26 PM, Paul Gortmaker
 wrote:
> In commit f368ed6088ae9c1fbe1c897bb5f215ce5e63fa1e ("char: make
> misc_deregister a void function") this ret variable became unused
> which now generates a compile warning.  Get rid of it.
>
> Cc: Alessandro Zummo 
> Cc: Alexandre Belloni 
> Cc: rtc-li...@googlegroups.com
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Paul Gortmaker 

Acked-by: Geert Uytterhoeven 

It's funny how these things end up in mainline, despite at least two
people providing a patch.

> ---
>  drivers/rtc/rtc-ds1374.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
> index 7067232ba507..742ac67eb702 100644
> --- a/drivers/rtc/rtc-ds1374.c
> +++ b/drivers/rtc/rtc-ds1374.c
> @@ -663,9 +663,8 @@ static int ds1374_probe(struct i2c_client *client,
>  static int ds1374_remove(struct i2c_client *client)
>  {
> struct ds1374 *ds1374 = i2c_get_clientdata(client);
> -#ifdef CONFIG_RTC_DRV_DS1374_WDT
> -   int res;
>
> +#ifdef CONFIG_RTC_DRV_DS1374_WDT
> misc_deregister(_miscdev);
> ds1374_miscdev.parent = NULL;
> unregister_reboot_notifier(_wdt_notifier);

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] mm/slab_common: add SLAB_NO_MERGE flag for use when creating slabs

[Mike Snitzer]

The slab aliasing/merging by default transition went unnoticed (at least
to the DM subsystem).  Add a new SLAB_NO_MERGE flag that allows
individual slabs to be created without slab merging.  This beats forcing
all slabs to be created in this fashion by specifying sl[au]b_nomerge on
the kernel commandline.

DM has historically taken care to have separate named slabs that each
devices' mempool_t are backed by.  These separate slabs are useful --
even if only to aid inspection of DM's memory use (via /proc/slabinfo)
on production systems.

I stumbled onto slab merging as a side-effect of a leak in dm-cache
being attributed to 'kmalloc-96' rather than the expected
'dm_bio_prison_cell' named slab.  Moving forward DM will disable slab
merging for all of DM's slabs by using SLAB_NO_MERGE.

Signed-off-by: Mike Snitzer 
---
 include/linux/slab.h | 2 ++
 mm/slab.h| 2 +-
 mm/slab_common.c | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/slab.h b/include/linux/slab.h
index a99f0e5..d007407 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -87,6 +87,8 @@
 # define SLAB_FAILSLAB 0xUL
 #endif
 
+#define SLAB_NO_MERGE  0x0400UL/* Do not merge with existing 
slab */
+
 /* The following flags affect the page allocator grouping pages by mobility */
 #define SLAB_RECLAIM_ACCOUNT   0x0002UL/* Objects are 
reclaimable */
 #define SLAB_TEMPORARY SLAB_RECLAIM_ACCOUNT/* Objects are 
short-lived */
diff --git a/mm/slab.h b/mm/slab.h
index 8da63e4..35eb6f4 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -115,7 +115,7 @@ static inline unsigned long kmem_cache_flags(unsigned long 
object_size,
 
 /* Legal flag mask for kmem_cache_create(), for various configurations */
 #define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | SLAB_PANIC | \
-SLAB_DESTROY_BY_RCU | SLAB_DEBUG_OBJECTS )
+SLAB_DESTROY_BY_RCU | SLAB_DEBUG_OBJECTS | 
SLAB_NO_MERGE)
 
 #if defined(CONFIG_DEBUG_SLAB)
 #define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 8683110..3a5a8ed 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -35,7 +35,7 @@ struct kmem_cache *kmem_cache;
  */
 #define SLAB_NEVER_MERGE (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \
SLAB_TRACE | SLAB_DESTROY_BY_RCU | SLAB_NOLEAKTRACE | \
-   SLAB_FAILSLAB)
+   SLAB_FAILSLAB | SLAB_NO_MERGE)
 
 #define SLAB_MERGE_SAME (SLAB_RECLAIM_ACCOUNT | SLAB_CACHE_DMA | SLAB_NOTRACK)
 
-- 
2.3.2 (Apple Git-55)

--
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] dm: disable slab merging for all DM slabs

[Mike Snitzer]

It is useful to be able to observe DM's slab memory use by looking at
"dm_" named slabs in /proc/slabinfo without having to enable SLAB_DEBUG
options on production systems.

before:
$ cat /proc/slabinfo | grep dm_ | cut -d' ' -f1
dm_mpath_io
dm_uevent
dm_rq_target_io

after:
$ cat /proc/slabinfo | grep dm_ | cut -d' ' -f1
dm_thin_new_mapping
dm_mpath_io
dm_mq_policy_cache_entry
dm_cache_migration
dm_bio_prison_cell
dm_snap_pending_exception
dm_exception
dm_dirty_log_flush_entry
dm_kcopyd_job
dm_io
dm_uevent
dm_clone_request
dm_rq_target_io
dm_target_io

Signed-off-by: Mike Snitzer 
---
 drivers/md/dm-bio-prison.c | 2 +-
 drivers/md/dm-bufio.c  | 2 +-
 drivers/md/dm-cache-policy-mq.c| 2 +-
 drivers/md/dm-cache-target.c   | 3 +--
 drivers/md/dm-io.c | 3 ++-
 drivers/md/dm-kcopyd.c | 4 ++--
 drivers/md/dm-log-userspace-base.c | 2 +-
 drivers/md/dm-mpath.c  | 3 +--
 drivers/md/dm-snap.c   | 4 ++--
 drivers/md/dm-thin.c   | 2 +-
 drivers/md/dm-uevent.c | 2 +-
 drivers/md/dm.c| 8 
 12 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/md/dm-bio-prison.c b/drivers/md/dm-bio-prison.c
index cd6d1d2..d033eee 100644
--- a/drivers/md/dm-bio-prison.c
+++ b/drivers/md/dm-bio-prison.c
@@ -398,7 +398,7 @@ EXPORT_SYMBOL_GPL(dm_deferred_set_add_work);
 
 static int __init dm_bio_prison_init(void)
 {
-   _cell_cache = KMEM_CACHE(dm_bio_prison_cell, 0);
+   _cell_cache = KMEM_CACHE(dm_bio_prison_cell, SLAB_NO_MERGE);
if (!_cell_cache)
return -ENOMEM;
 
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index 86dbbc7..1187470 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -1636,7 +1636,7 @@ struct dm_bufio_client *dm_bufio_client_create(struct 
block_device *bdev, unsign
if (!DM_BUFIO_CACHE(c)) {
DM_BUFIO_CACHE(c) = 
kmem_cache_create(DM_BUFIO_CACHE_NAME(c),
  c->block_size,
- c->block_size, 0, 
NULL);
+ c->block_size, 
SLAB_NO_MERGE, NULL);
if (!DM_BUFIO_CACHE(c)) {
r = -ENOMEM;
mutex_unlock(_bufio_clients_lock);
diff --git a/drivers/md/dm-cache-policy-mq.c b/drivers/md/dm-cache-policy-mq.c
index aa1b41c..ecc9f7d 100644
--- a/drivers/md/dm-cache-policy-mq.c
+++ b/drivers/md/dm-cache-policy-mq.c
@@ -1444,7 +1444,7 @@ static int __init mq_init(void)
mq_entry_cache = kmem_cache_create("dm_mq_policy_cache_entry",
   sizeof(struct entry),
   __alignof__(struct entry),
-  0, NULL);
+  SLAB_NO_MERGE, NULL);
if (!mq_entry_cache)
return -ENOMEM;
 
diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index f9d9cc6..199fa437 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -394,7 +394,6 @@ static void wake_worker(struct cache *cache)
 
 static struct dm_bio_prison_cell *alloc_prison_cell(struct cache *cache)
 {
-   /* FIXME: change to use a local slab. */
return dm_bio_prison_alloc_cell(cache->prison, GFP_NOWAIT);
 }
 
@@ -3854,7 +3853,7 @@ static int __init dm_cache_init(void)
return r;
}
 
-   migration_cache = KMEM_CACHE(dm_cache_migration, 0);
+   migration_cache = KMEM_CACHE(dm_cache_migration, SLAB_NO_MERGE);
if (!migration_cache) {
dm_unregister_target(_target);
return -ENOMEM;
diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
index 74adcd2..f7efeec 100644
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@ -526,7 +526,8 @@ EXPORT_SYMBOL(dm_io);
 
 int __init dm_io_init(void)
 {
-   _dm_io_cache = KMEM_CACHE(io, 0);
+   _dm_io_cache = kmem_cache_create("dm_io", sizeof(struct io),
+__alignof__(struct io), SLAB_NO_MERGE, 
NULL);
if (!_dm_io_cache)
return -ENOMEM;
 
diff --git a/drivers/md/dm-kcopyd.c b/drivers/md/dm-kcopyd.c
index 3a7cade..f2a55a8 100644
--- a/drivers/md/dm-kcopyd.c
+++ b/drivers/md/dm-kcopyd.c
@@ -364,9 +364,9 @@ static struct kmem_cache *_job_cache;
 
 int __init dm_kcopyd_init(void)
 {
-   _job_cache = kmem_cache_create("kcopyd_job",
+   _job_cache = kmem_cache_create("dm_kcopyd_job",
sizeof(struct kcopyd_job) * (SPLIT_COUNT + 1),
-   __alignof__(struct kcopyd_job), 0, NULL);
+   __alignof__(struct kcopyd_job), SLAB_NO_MERGE, 
NULL);
if (!_job_cache)
return -ENOMEM;
 

Re: [PATCH] clk: h8s2678: Fix compile error

[Stephen Boyd]

On 08/31, Guenter Roeck wrote:
> Recent cleanup removed some include files without checking if the cleaned
> up code still compiles. This results in the following compile error.
> 
> drivers/clk/h8300/clk-h8s2678.c: In function ‘h8s2678_pll_clk_setup’:
> drivers/clk/h8300/clk-h8s2678.c:99:14: error:
>   implicit declaration of function ‘kzalloc’
> drivers/clk/h8300/clk-h8s2678.c:138:2: error:
>   implicit declaration of function ‘kfree’
> 
> Cc: Yoshinori Sato 
> Cc: Stephen Boyd 
> Signed-off-by: Guenter Roeck 
> ---

Urgh. I thought I compiled that one. Applied to clk-fixes.

-- 
Qualcomm Innovation Center, Inc. is a member of 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/

[PATCH] perf, tools: Always use non inlined file name for srcfile

[Andi Kleen]

From: Andi Kleen 

When profiling the kernel with srcfile it's common to "get
stuck" in include. For example a lot of code uses current
or other inlines, so they get accounted to some random
include file. This is not very useful as a high level
categorization.

For example just profiling the idle loop usually shows
mostly inlines, so you never see the actual cpuidle file.

This patch changes srcfile to always unwind the inline
stack using BFD/dwarf. So we always account to the base
function that called the inline.

In a few cases include is still shown (for example for MSR
accesses), but that is because they get inlining expanded as part
of assigning to a global function pointer. For the majority
it works fine though.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/sort.c|  4 ++--
 tools/perf/util/srcline.c | 27 ++-
 tools/perf/util/util.h|  2 ++
 3 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 7e38716..a97bcee 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -328,8 +328,8 @@ static char *get_srcfile(struct hist_entry *e)
char *sf, *p;
struct map *map = e->ms.map;
 
-   sf = get_srcline(map->dso, map__rip_2objdump(map, e->ip),
-e->ms.sym, true);
+   sf = __get_srcline(map->dso, map__rip_2objdump(map, e->ip),
+e->ms.sym, false, true);
if (!strcmp(sf, SRCLINE_UNKNOWN))
return no_srcfile;
p = strchr(sf, ':');
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index fc08248..8f025e2 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -150,7 +150,8 @@ static void addr2line_cleanup(struct a2l_data *a2l)
 }
 
 static int addr2line(const char *dso_name, u64 addr,
-char **file, unsigned int *line, struct dso *dso)
+char **file, unsigned int *line, struct dso *dso,
+bool unwind_inlines)
 {
int ret = 0;
struct a2l_data *a2l = dso->a2l;
@@ -170,6 +171,15 @@ static int addr2line(const char *dso_name, u64 addr,
 
bfd_map_over_sections(a2l->abfd, find_address_in_section, a2l);
 
+   if (a2l->found && unwind_inlines) {
+   bool found;
+
+   do {
+   found = bfd_find_inliner_info(a2l->abfd, >filename,
+ >funcname, 
>line);
+   } while (found);
+   }
+
if (a2l->found && a2l->filename) {
*file = strdup(a2l->filename);
*line = a2l->line;
@@ -197,7 +207,8 @@ void dso__free_a2l(struct dso *dso)
 
 static int addr2line(const char *dso_name, u64 addr,
 char **file, unsigned int *line_nr,
-struct dso *dso __maybe_unused)
+struct dso *dso __maybe_unused,
+bool unwind_inlines __maybe_unused)
 {
FILE *fp;
char cmd[PATH_MAX];
@@ -254,8 +265,8 @@ void dso__free_a2l(struct dso *dso __maybe_unused)
  */
 #define A2L_FAIL_LIMIT 123
 
-char *get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
- bool show_sym)
+char *__get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
+ bool show_sym, bool unwind_inlines)
 {
char *file = NULL;
unsigned line = 0;
@@ -276,7 +287,7 @@ char *get_srcline(struct dso *dso, u64 addr, struct symbol 
*sym,
if (!strncmp(dso_name, "/tmp/perf-", 10))
goto out;
 
-   if (!addr2line(dso_name, addr, , , dso))
+   if (!addr2line(dso_name, addr, , , dso, unwind_inlines))
goto out;
 
if (asprintf(, "%s:%u",
@@ -310,3 +321,9 @@ void free_srcline(char *srcline)
if (srcline && strcmp(srcline, SRCLINE_UNKNOWN) != 0)
free(srcline);
 }
+
+char *get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
+ bool show_sym)
+{
+   return __get_srcline(dso, addr, sym, show_sym, false);
+}
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 291be1d..09c1a8b 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -321,6 +321,8 @@ struct symbol;
 extern bool srcline_full_filename;
 char *get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
  bool show_sym);
+char *__get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
+ bool show_sym, bool unwind_inlines);
 void free_srcline(char *srcline);
 
 int filename__read_str(const char *filename, char **buf, size_t *sizep);
-- 
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] perf, tools: Always use non inlined file name for srcfile

[Andi Kleen]

On Tue, Sep 01, 2015 at 03:36:57PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 01, 2015 at 11:11:42AM -0700, Andi Kleen escreveu:
> > From: Andi Kleen 
> > 
> > When profiling the kernel with srcfile it's common to "get
> > stuck" in include. For example a lot of code uses current
> > or other inlines, so they get accounted to some random
> > include file. This is not very useful as a high level
> > categorization.
> 
> Cool idea :-)

Yes.

It would be also nice to use this information for unwinding
(so to show the inline stack as part of the call graph)

> Why not the so much simpler:
> 
>   while (bfd_find_inliner_info(...));
> 
> But other than that, wouldn't be better to put an upper limit on this?
> 
> Say, 1024 levels of unwinding to avoid tripping in some bfd lib bug that
> could make this function always return true and make addr2line get stuck
> in an infinite loop?

Done. I sent a v2.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
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: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[Siarhei Siamashka]

On Wed, 2 Sep 2015 01:58:56 +0800
pins...@gmail.com wrote:

> > On Sep 2, 2015, at 1:30 AM, Mark Rutland  wrote:
> > 
> > [...]
> > 
> > On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
> > It is useful to pass down MIDR register down to userland if all of
> > the online cores are all the same type.  This adds AT_ARM64_MIDR
> > aux vector type and passes down the midr system register.
> > 
> > This is alternative to MIDR_EL1 part of
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
> > It allows for faster access to midr_el1 than going through a trap and
> > does not exist if the set of cores are not the same.
>  
>  I'm not sure I follow the rationale. If speed is important the
>  application can cache the value the first time it reads it with a trap.
> >>> 
> >>> It is also about compatibility also. Exposing the register is not 
> >>> backwards compatible but using the aux vector is.
> >> 
> >> That would also break big.little too. So either break it with hot plug or 
> >> break it in userland, your choice.
> > 
> > The value wouldn't be representative of the system as a whole; that is
> > true. However, we never guaranteed that it was, while the aux vector
> > code implied that we did.
> 
> Yes but I guess you talk about caching the value in userspace but doing
> it via the aux vector is the same as your suggestion. Just one
> difference is you don't get the aux vector entry if there is a CPU
> that is online which is different. No difference from your suggestion
> of caching it. Without considering hot pug for a second (that is a
> huge different issue all together), if userland wants to know if all
> up CPUs have the same midr, they would either read /sys entries (lots
> of syscalls) or bind to each CPU and do the trap. That means at least
> three or two syscalls/traps for each CPU. My way is none and gets a
> value of midr if they are all the Same for free. 

Andrew, how do you propose to get the value of MIDR? Open the
"/proc/self/auxv", read it, do a linear search in the buffer to find
the required entry and then read the value? Or use the glibc specific
getauxval() function (https://lwn.net/Articles/519085) ?

Regarding the caching implementation, one can open and parse the
"/proc/cpuinfo" file (with older kernels) or read the new sysfs
entries to get the MIDR value for each core. Then create a lookup
table. As an additional bonus, this lookup table can contain not
just the MIDR values, but any arbitrary data in any format (for
example, a function pointer to the memcpy function or anything else).

After the lookup table is available, one can use the getcpu() syscall
for getting the CPU number and do the table lookup. And for getting
reasonable performance, implement the vdso variant of the getcpu()
syscall.

All of this internal ugliness would be best abstracted inside
of the GCC __builtin_cpu_init(), __builtin_cpu_is() and
__builtin_cpu_supports() builtins:
http://gcc.gnu.org/gcc-4.8/changes.html

One big.LITTLE systems, the __builtin_cpu_is() could be implemented
via a single getcpu() syscall and the table lookup, like explained
above. The __builtin_cpu_init() could prepare the lookup table.
And on normal systems with identical cores, the use of the syscall
is not required.

It might be interesting to also optionally allow something like this:
__builtin_cpu_is("cortex-a7 || cortex-a15")
Which would mean that we are interested in checking for the
Cortex-A7+Cortex-A15 pair in a big.LITTLE system, but are not
interested in knowing whether we are running on A7 or A15 in this
particular moment (and avoid the syscall overhead).

We had an old discussion on a similar CPU type identification topic
in the past:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/220542.html
I have been told that it had been forwarded to the Linaro toolchain
people, but did not track if this resulted in anything useful or not.

I think that it would be best to prefer something that is easily usable
for all applications and libraries, and not just something for a private
use by glibc. To sum everything up:

One the kernel side it means:
  1. Maybe implement vdso for getcpu(), this will make things faster
 on big.LITTLE systems.
  2. Maybe implement sysfs entries for per-core MIDR values from
   
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359127.html
 This will make things faster and allow to avoid potentially
 messy and cumbersome /proc/cpuinfo text parsing.

On the GCC side it means:
  1. Implement __builtin_cpu_init(), __builtin_cpu_is() and
 __builtin_cpu_supports() builtins, which rely on reading sysfs
 entries (with a fallback to /proc/cpuinfo parsing on old kernels)
 and the getcpu() syscall for the reasonably accurate core type
 runtime identification on big.LITTLE systems.

On the applications/libraries side (including, 

Re: [PATCH] x86: fix small LDT allocation for Xen

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 3:48 AM, Jan Beulich  wrote:
> While commit 37868fe113 ("x86/ldt: Make modify_ldt synchronous") added
> a nice comment explaining that Xen needs page-aligned whole page chunks
> for guest descriptor tables, it then nevertheless used kzalloc() on the
> small size path. As I'm unaware of guarantees for kmalloc(PAGE_SIZE, )
> to return page-aligned memory blocks, I believe this needs to be
> switched back to __get_free_page().
>
> Signed-off-by: Jan Beulich 
> Cc: Andy Lutomirski 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/kernel/ldt.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 4.2/arch/x86/kernel/ldt.c
> +++ 4.2-x86-LDT-alloc/arch/x86/kernel/ldt.c
> @@ -58,7 +58,7 @@ static struct ldt_struct *alloc_ldt_stru
> if (alloc_size > PAGE_SIZE)
> new_ldt->entries = vzalloc(alloc_size);
> else
> -   new_ldt->entries = kzalloc(PAGE_SIZE, GFP_KERNEL);
> +   new_ldt->entries = (void 
> *)__get_free_page(GFP_KERNEL|__GFP_ZERO);

This would need a corresponding change to the kfree path, right?

--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/

Re: [PATCH 0/4] x86/insn: perf tools: Add a few new x86 instructions

[Arnaldo Carvalho de Melo]

Em Tue, Sep 01, 2015 at 03:16:52PM +0300, Adrian Hunter escreveu:
> On 01/09/15 11:54, Ingo Molnar wrote:
> > 
> > * Adrian Hunter  wrote:
> > 
> >> Hi
> >>
> >> perf tools has a copy of the x86 instruction decoder for decoding
> >> Intel PT. [...]
> > 
> > So that's the arch/x86/lib/insn.c instruction length decoder that the 
> > kernel uses 
> > for kprobes et al - and the two versions already forked slightly:
> > 
> > -#include "inat.h"
> > -#include "insn.h"
> > +#include 
> > +#include 
> > 
> > it would be nice to add a diff check to the perf build, and (non-fatally) 
> > warn 
> > during the build if the two versions depart from each other?
> 
> I had a go and came up with this.  Arnaldo, Jiri any comments?

So, I was going to try and merge this series, can you please collect the
Acks by Masami and Jiri and resubmit?

I'd say no need to stop this just to get a build function to use with
this, the test below should do the trick _for this specific instance_
and then, after we get this, you should use it as the initial usecase
for adding the build function, d'accord?

Jiri, are you ok with this?

- Arnaldo
 
> diff --git a/tools/perf/util/intel-pt-decoder/Build 
> b/tools/perf/util/intel-pt-decoder/Build
> index 240730d682c1..1b8a32de8504 100644
> --- a/tools/perf/util/intel-pt-decoder/Build
> +++ b/tools/perf/util/intel-pt-decoder/Build
> @@ -6,6 +6,17 @@ inat_tables_maps = util/intel-pt-decoder/x86-opcode-map.txt
>  $(OUTPUT)util/intel-pt-decoder/inat-tables.c: $(inat_tables_script) 
> $(inat_tables_maps)
>   @$(call echo-cmd,gen)$(AWK) -f $(inat_tables_script) 
> $(inat_tables_maps) > $@ || rm -f $@
>  
> -$(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: 
> util/intel-pt-decoder/inat.c $(OUTPUT)util/intel-pt-decoder/inat-tables.c
> +$(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: 
> util/intel-pt-decoder/intel-pt-insn-decoder.c util/intel-pt-decoder/inat.c 
> $(OUTPUT)util/intel-pt-decoder/inat-tables.c
> + @test -d ../../arch/x86 && (( \
> + diff -B -I'^#include' util/intel-pt-decoder/insn.c 
> ../../arch/x86/lib/insn.c >/dev/null && \
> + diff -B -I'^#include' util/intel-pt-decoder/inat.c 
> ../../arch/x86/lib/inat.c >/dev/null && \
> + diff -B util/intel-pt-decoder/x86-opcode-map.txt 
> ../../arch/x86/lib/x86-opcode-map.txt >/dev/null && \
> + diff -B util/intel-pt-decoder/gen-insn-attr-x86.awk 
> ../../arch/x86/tools/gen-insn-attr-x86.awk >/dev/null && \
> + diff -B -I'^#include' util/intel-pt-decoder/insn.h 
> ../../arch/x86/include/asm/insn.h >/dev/null && \
> + diff -B -I'^#include' util/intel-pt-decoder/inat.h 
> ../../arch/x86/include/asm/inat.h >/dev/null && \
> + diff -B -I'^#include' util/intel-pt-decoder/inat_types.h 
> ../../arch/x86/include/asm/inat_types.h >/dev/null) \
> + || echo "Warning: Intel PT: x86 instruction decoder differs from 
> kernel" >&2 )
> + $(call rule_mkdir)
> + $(call if_changed_dep,cc_o_c)
>  
>  CFLAGS_intel-pt-insn-decoder.o += -I$(OUTPUT)util/intel-pt-decoder 
> -Wno-override-init
> 
--
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/4] MIPS: ath79: Add the EHCI controller and USB phy to the AR9132 dtsi

[Sergei Shtylyov]

Hello.

On 09/01/2015 06:23 PM, Alban Bedel wrote:


Signed-off-by: Alban Bedel 
---
  arch/mips/boot/dts/qca/ar9132.dtsi | 24 
  1 file changed, 24 insertions(+)

diff --git a/arch/mips/boot/dts/qca/ar9132.dtsi 
b/arch/mips/boot/dts/qca/ar9132.dtsi
index fb7734e..665ee84 100644
--- a/arch/mips/boot/dts/qca/ar9132.dtsi
+++ b/arch/mips/boot/dts/qca/ar9132.dtsi
@@ -125,6 +125,21 @@
};
};

+   ehci@1b000100 {


   Please name the node "usb", not "ehci" in order to comply to the ePAPR 
standard.



+   compatible = "qca,ar7100-ehci", "generic-ehci";


MBR, Sergei

--
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] firmware: annotate thou shalt not request fw on init or probe

[Josh Boyer]

On Fri, Aug 28, 2015 at 9:18 PM, Luis R. Rodriguez
 wrote:
> From: "Luis R. Rodriguez" 
>
> We are phasing out the usermode helper from the kernel,
> systemd already ripped support for this a while ago, the
> only remaining valid user is the Dell rbu driver. The

Actually, I don't think that is accurate any longer.  The Dell rbu
driver certainly requires this, but it seems that the following
drivers select FW_LOADER_USER_HELPER_FALLBACK as well:

CONFIG_DRM_STI
CONFIG_LEDS_LP55XX_COMMON

Why they do that, I have no idea.  It's kind of disappointing.

josh
--
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/

[GIT PULL] first round of SCSI updates for the 4.2+ merge window

[James Bottomley]

This includes one new driver: cxlflash plus the usual grab bag of
updates for the major drivers: qla2xxx, ipr, storvsc, pm80xx, hptiop,
plus a few assorted fixes.  There's another tranch coming, but I want to
incubate it another few days in the checkers, plus it includes a mpt2sas
separated lifetime fix, which Avago won't get done testing until
Friday. 

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc

The Short Changelog is:


Alexey Khoroshilov (1):
  bfa: fix leak of bfad_im_port_index on module unload

Arun Easi (1):
  qla2xxx: Fix missing device login retries.

Bart Van Assche (11):
  qla2xxx: Avoid that sparse complains about context imbalances
  qla2xxx: Remove dead code
  qla2xxx: Remove a superfluous test
  qla2xxx: Fix sparse annotations
  qla2xxx: Avoid that sparse complains about duplicate [noderef] attributes
  qla2xxx: Remove __constant_ prefix
  qla2xxx: Replace two macros with an inline function
  qla2xxx: Remove set-but-not-used variables
  qla2xxx: Declare local functions static
  qla2xxx: Report both rsp_info and rsp_info_len
  libfc: Fix a typo in a source code comment

Bjorn Helgaas (3):
  megaraid_sas: fix whitespace errors
  megaraid_sas: use dev_printk when possible
  megaraid : use dev_printk when possible

Brian King (2):
  ipr: Driver version 2.6.2
  ipr: Endian / sparse fixes

Chad Dupuis (3):
  qla2xxx: Remove decrement of sp reference count in abort handler.
  qla2xxx: Do not reset ISP for error entry with an out of range handle.
  qla2xxx: Do not reset adapter if SRB handle is in range.

Chris Leech (1):
  iSCSI: let session recovery_tmo sysfs writes persist across recovery

Dan Carpenter (5):
  aic94xx: set an error code on failure
  cxlflash: shift wrapping bug in afu_link_reset()
  cxlflash: off by one bug in cxlflash_show_port_status()
  mptfusion: prevent some memory corruption
  hpsa: fix an sprintf() overflow in the reset handler

Dilip Kumar Uppugandla (1):
  qla2xxx: Return the fabric command state for non-task management requests

Don Brace (7):
  hpsa: fix rmmod issues
  hpsa: add in new controllers
  hpsa: cleanup update scsi devices
  hpsa: add PMC to copyright
  hpsa: correct static checker warnings on driver init cleanup
  hpsa: correct decode sense data
  hpsa: Correct double unlock of mutex

Hannes Reinecke (2):
  scsi: Add ALUA state change UA handling
  scsi: retry MODE SENSE on unit attention

Himanshu Madhani (2):
  qla2xxx: Update driver version to 8.07.00.26-k
  qla2xxx: do not clear slot in outstanding cmd array

Hiral Patel (1):
  qla2xxx: Do not crash system for sp ref count zero

Jack Wang (1):
  MAINTAINERS: update email for pm8001

Joe Carnuccio (4):
  qla2xxx: Pause risc before manipulating risc semaphore.
  qla2xxx: Use ssdid to gate semaphore manipulation.
  qla2xxx: Handle AEN8014 incoming port logout.
  qla2xxx: Add serdes register read/write support for ISP25xx.

Joe Handzik (1):
  hpsa: add sysfs entry path_info to show box and bay information

Johannes Thumshirn (2):
  st: Destroy st_index_idr on module exit
  mvsas: always iounmap resources

K. Y. Srinivasan (1):
  storvsc: Set the error code correctly in failure conditions

Keith Mange (6):
  storvsc: Allow write_same when host is windows 10
  storvsc: use storage protocol version to determine storage capabilities
  storvsc: use correct defaults for values determined by protocol 
negotiation
  storvsc: Untangle the storage protocol negotiation from the vmbus 
protocol negotiation.
  storvsc: Use a single value to track protocol versions
  storvsc: Rather than look for sets of specific protocol versions, make 
decisions based on ranges.

Kevin Barnett (1):
  Change how controllers in mixed mode are handled.

Matthew R. Ochs (5):
  cxlflash: Remove unused variable from queuecommand
  cxlflash: Virtual LUN support
  cxlflash: Superpipe support
  cxlflash: Base error recovery support
  cxlflash: Base support for IBM CXL Flash Adapter

Saurav Kashyap (1):
  qla2xxx: Add adapter checks for FAWWN functionality.

Sawan Chandak (2):
  qla2xxx: Add pci device id 0x2261.
  qla2xxx: Add support to show MPI and PEP FW version for ISP27xx.

Scott Benesh (1):
  hpsa: add in new offline mode

Sebastian Herbszt (1):
  lpfc: Use && instead of & for boolean expression

Seymour, Shane M (2):
  st: convert DRIVER_ATTR macros to DRIVER_ATTR_RO
  st: convert to using driver attr groups for sysfs

Sreekanth Reddy (1):
  mpt2sas, mpt3sas: Abort initialization if no memory I/O resources detected

Suresh Thiagarajan (1):
  pm80xx: Added pm8006 controller support

Thadeu Lima de Souza Cascardo (1):
  qla2xxx: prevent board_disable from running during EEH

Viswas G (8):
  pm80xx: 

[PATCH] fs: have flush_delayed_fput flush the workqueue job

[Jeff Layton]

I think there's a potential race in flush_delayed_fput. A kthread does
an fput() and that file gets added to the list and the delayed work is
scheduled. More than 1 jiffy passes, and the workqueue thread picks up
the work and starts running it. Then the kthread calls
flush_delayed_work.  It sees that the list is empty and returns
immediately, even though the __fput for its file may not have run yet.

Close this by making flush_delayed_fput use flush_delayed_work instead,
which should just block until the workqueue job completes if it's
already running.

Signed-off-by: Jeff Layton 
---
 fs/file_table.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/file_table.c b/fs/file_table.c
index 7f9d407c7595..f4833af62eae 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -243,6 +243,8 @@ static void fput(struct callback_head *work)
__fput(container_of(work, struct file, f_u.fu_rcuhead));
 }
 
+static DECLARE_DELAYED_WORK(delayed_fput_work, delayed_fput);
+
 /*
  * If kernel thread really needs to have the final fput() it has done
  * to complete, call this.  The only user right now is the boot - we
@@ -255,11 +257,9 @@ static void fput(struct callback_head *work)
  */
 void flush_delayed_fput(void)
 {
-   delayed_fput(NULL);
+   flush_delayed_work(_fput_work);
 }
 
-static DECLARE_DELAYED_WORK(delayed_fput_work, delayed_fput);
-
 void fput(struct file *file)
 {
if (atomic_long_dec_and_test(>f_count)) {
-- 
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 -next] rtc: drop unused ret variable orphaned by misc_deregister becoming void

[Geert Uytterhoeven]

On Tue, Sep 1, 2015 at 7:37 PM, Geert Uytterhoeven  wrote:
> On Sat, Aug 22, 2015 at 9:26 PM, Paul Gortmaker
>  wrote:
>> In commit f368ed6088ae9c1fbe1c897bb5f215ce5e63fa1e ("char: make
>> misc_deregister a void function") this ret variable became unused
>> which now generates a compile warning.  Get rid of it.
>>
>> Cc: Alessandro Zummo 
>> Cc: Alexandre Belloni 
>> Cc: rtc-li...@googlegroups.com
>> Cc: Greg Kroah-Hartman 
>> Signed-off-by: Paul Gortmaker 
>
> Acked-by: Geert Uytterhoeven 
>
> It's funny how these things end up in mainline, despite at least two
> people providing a patch.

Ah, Greg sent a very early pull request. That explains it...

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] watchdog_dev: Use device tree alias for naming watchdogs

[Guenter Roeck]

On Tue, Sep 01, 2015 at 10:20:36AM -0700, Justin Chen wrote:
> On Sat, Aug 29, 2015 at 2:53 AM, Guenter Roeck  wrote:
> > On 08/28/2015 02:58 PM, Justin Chen wrote:
> >>
> >> Currently there is no way to easily differentiate multiple
> >> watchdog devices. The watchdogs are named by the order they
> >> are probed.
> >> 1st probed watchdog: /dev/watchdog0
> >> 2nd probed watchdog: /dev/watchdog1
> >> ...
> >>
> >> This change uses the alias of the watchdog device node for
> >> the name of the watchdog.
> >> aliases {
> >> watchdog0 = "/./"
> >> watchdog3 = "//."
> >> watchdog2 = "//."
> >> ...
> >> }
> >>
> >> This will translate to...
> >> /dev/watchdog0
> >> /dev/watchdog3
> >> /dev/watchdog2
> >>
> >> Signed-off-by: Justin Chen 
> >
> >
> > Interesting idea. Checking through other subsystems, many others do the
> > same,
> > so it makes sense to use that mechanism.
> >
> > However, the id assignment should be in the calling code, in
> > __watchdog_register_device,
> > to avoid that another id, possibly conflicting, is assigned through the
> ida
> > mechanism.
> >
> > This is a bit more complicated than it looks like to ensure correct id
> > assignment.
> > Have a look into the i2c code to see how it is handled. Essentially we
> must
> > pass
> > the requested number to ida_simple_get().
> >
> > Thanks,
> > Guenter
> 
> Ok that makes sense. I will put a wrapper function around ida_simple_get()
> that will request a specific number, if that fails then do a normal request.
> Something like this...
> 
> ret = of_alias_get_id()
> 
> id = ida_simple_get(_ida, ret, ret, GFP_KERNEL);
> 
ret, ret + 1

but something like
ret =  of_alias_get_id(...);
if (ret >= 0)
id = ida_simple_get(_ida, ret, ret + 1, GFP_KERNEL);
else
id = ida_simple_get(_ida, 0, MAX_DOGS, GFP_KERNEL);
if (id < 0)
return id;

would be better. Passing 'ret' directly would not work, because
ida_simple_get() expects an unsigned range as parameters, and
of_alias_get_id() can return a negative error code.

Thanks,
Guenter
--
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: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[Pinski, Andrew]

> On Sep 2, 2015, at 1:19 AM, Mark Rutland  wrote:
> 
>> On Tue, Sep 01, 2015 at 05:51:44PM +0100, pins...@gmail.com wrote:
>> 
>> 
>> 
>> 
>>> On Sep 2, 2015, at 12:33 AM, Mark Rutland  wrote:
>>> 
>>> Hi,
>>> 
 On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
 It is useful to pass down MIDR register down to userland if all of
 the online cores are all the same type.  This adds AT_ARM64_MIDR
 aux vector type and passes down the midr system register.
 
 This is alternative to MIDR_EL1 part of
 http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
 It allows for faster access to midr_el1 than going through a trap and
 does not exist if the set of cores are not the same.
>>> 
>>> I'm not sure I follow the rationale. If speed is important the
>>> application can cache the value the first time it reads it with a trap.
>> 
>> It is also about compatibility also. Exposing the register is not
>> backwards compatible but using the aux vector is. 
> 
> So long as we have HWCAP_CPUID describing the availability of register
> access [2], then userspace can test for that before attempting to access
> the MIDR.

So two checks always. Bad choice. 

> 
> Other than that, I don't see a backwards or forwards compatibility
> issue.
> 
 +u32 get_arm64_midr(void)
 +{
 +int i;
 +u32 midr = 0;
 +
 +for_each_online_cpu(i) {
 +struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
 +u32 oldmidr = midr;
 +
 +midr = cpuinfo->reg_midr;
 +/*
 + * If there are cpus which have a different
 + * midr just return 0.
 + */
 +if (oldmidr && oldmidr != midr)
 +return 0;
 +}
 +
 +return midr;
 +}
>>> 
>>> If I have a big.LITTLE system where all the big CPUs are currently
>>> offline, this will leave the MIDR the little CPUs in the auxvec.
>>> However, at any point after this has run, I could hotplug the big CPUs
>>> on and the little CPUs off, leaving this reporting a MIDR that
>>> represents none of the online CPUs.
>>> 
>>> Given big.LITTLE and the potential for physical/dynamic hotplug (where
>>> we won't know all the MIDRs in advance), I don't think that we can
>>> generally expose a common MIDR in this fashion, and I don't think that
>>> we should give the impression that we can.
>> 
>> This is standard issue with hot plug and big.little. Really big.little
>> is a design flaw but I am not going into that here. 
> 
> Regardless of our personal feelings on big.LITTLE, it's something we
> have to deal with.

You did not respond to the caching in userspace issue. You raised that as a 
speed optimization but then considered my patch as a non starter. 

> 
> Hopefully it's a non-issue anyway; a MIDR provided by this interface can
> really only be used to derive optimisation criteria rather than
> non-architected properties required for correctness.

Like hardware workarounds? Yes that is going to be used for that and is already 
right now by reading /proc/cpuinfo . Also it would useful to use what ever 
interface for gcc's -mcpu=native option. 


> 
>>> I think that the only things we can do are expose the MIDR for CPU the
>>> code is currently executing on (as Suzuki's patches do), and/or expose
>>> all the MIDRs for currently online CPUs (as Steve's [1] patch does).
>>> Anything else leaves us trying to provide semantics that we cannot
>>> guarantee.
>> 
>> Except they are not backwards compatible which means nobody in their
>> right mind would use the register to get the midr that way.
> 
> I assume you missed the discussion of HWCAP_CPUID, which prevents the
> compatibility issue I believe you're considering here.

And you suggested to cache midr while not considering big.little. You can't 
have it both ways. I read those and I still think they were wrong in rejecting 
this.  Also there are two markets arm is in and things like this is causing one 
of those markets to suffer. Big.little is not going into servers. 

> 
>> I am sorry but having a newer version of glibc working on a year old
>> kernel is not going to fly. 
> 
> I'm not sure I follow this, unless you meant _not_ working.

Because of the double checks, it will be slower and the trap. And gives a bad 
interface to userland really.  Aux vector is a much cleaner interface to 
userland than a trapped instruction. 

Thanks,
Andrew

> 
> Thanks,
> Mark.
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359127.html
> [2] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363559.html
--
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] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*

[Tony Lindgren]

* Keerthy  [150901 10:22]:
> 
> 
> On Wednesday 26 August 2015 09:29 AM, Keerthy wrote:
> >Currently apart from dra7, omap5 and amx3 all the other SoCs
> >are identified using cpu_is_* functions which is not right since
> >they are all SoCs(System on Chips). Hence changing the SoC
> >identification code to use soc_is instead of cpu_is and keeping
> >defines for cpu_is where needed. This allows us to replace the
> >rest of cpu_is usage along with other fixes as needed.
> 
> Tony,
> 
> A Gentle ping on this.

Looks good to me for v4.4. I'll apply it after some testing
after -rc1.

Regards,

Tony
--
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] soc: qcom: smd: Use __iowrite32_copy() instead of open-coding it

[Stephen Boyd]

On 08/31, Bjorn Andersson wrote:
> On Mon 31 Aug 18:39 PDT 2015, Stephen Boyd wrote:
> 
> > We already have a function to do this and it silences some sparse
> > warnings along the way.
> > 
> 
> Didn't know that, thanks. Do you know why there's no equivalent for
> transfers in the other direction? Should we hack one up to do the same
> simplification in smd_copy_from_fifo()?

Don't know. We can certainly write one although it would be nice
if we had two users. I'll take a look.

-- 
Qualcomm Innovation Center, Inc. is a member of 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 1/2] regulator: pbias: use untranslated address to program pbias regulator

[Mark Brown]

On Tue, Sep 01, 2015 at 07:17:21AM -0700, Tony Lindgren wrote:

> Why don't you just make reg unused for pbias_regulator since
> we already use regmap for this driver?

> Then in the pbias driver just define the register offset from
> the syscon base? You may need to set it based on the compatible
> value, but it's not like it's going to change for SoC.

> If we eventually add some API to calculate reg base offset
> from the syscon base it's easy to update the driver to use
> that.

That'd work.  The other thing I was thinking we could do is to get
syscon to treat any excessively large address that gets passed in that
looks like an absolute address appropriately.


signature.asc
Description: Digital signature

Re: [PATCH] perf, tools: Always use non inlined file name for srcfile

[Arnaldo Carvalho de Melo]

Em Tue, Sep 01, 2015 at 11:11:42AM -0700, Andi Kleen escreveu:
> From: Andi Kleen 
> 
> When profiling the kernel with srcfile it's common to "get
> stuck" in include. For example a lot of code uses current
> or other inlines, so they get accounted to some random
> include file. This is not very useful as a high level
> categorization.

Cool idea :-)
 
> For example just profiling the idle loop usually shows
> mostly inlines, so you never see the actual cpuidle file.
> @@ -170,6 +171,15 @@ static int addr2line(const char *dso_name, u64 addr,
>  
>   bfd_map_over_sections(a2l->abfd, find_address_in_section, a2l);
>  
> + if (a2l->found && unwind_inlines) {
> + bool found;
> +
> + do {
> + found = bfd_find_inliner_info(a2l->abfd, >filename,
> +   >funcname, 
> >line);
> + } while (found);
> + }

Why not the so much simpler:

while (bfd_find_inliner_info(...));

But other than that, wouldn't be better to put an upper limit on this?

Say, 1024 levels of unwinding to avoid tripping in some bfd lib bug that
could make this function always return true and make addr2line get stuck
in an infinite loop?

- Arnaldo
--
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 8/9] clocksource: Improve unstable clocksource detection

[Thomas Gleixner]

On Tue, 1 Sep 2015, Shaohua Li wrote:
> On Tue, Sep 01, 2015 at 07:13:40PM +0200, Thomas Gleixner wrote:
> > On Mon, 31 Aug 2015, Shaohua Li wrote:
> > > On Mon, Aug 31, 2015 at 11:47:52PM +0200, Thomas Gleixner wrote:
> > > > On Mon, 31 Aug 2015, Shaohua Li wrote:
> > > > > > The HPET wraps interval is 0x / 1 = 42.9s
> > > > > > 
> > > > > > tsc interval is (0x481250b45b - 0x219e6efb50) / 22 = 75s
> > > > > > 
> > > > > > 32.1 + 42.9 = 75
> > > > > > 
> > > > > > The example shows hpet wraps, while tsc is marked unstable
> > > > > 
> > > > > Thomas & John,
> > > > > Is this data enough to prove TSC unstable issue can be triggered by 
> > > > > HPET
> > > > > wrap? I can resend the patch with the data included.
> > > > 
> > > > Well, it's enough data to prove:
> > > > 
> > > >  - that keeping a VM off the CPU for 75 seconds is insane.
> > > 
> > > It wraps in 42.9s. 42.9s isn't a long time hard to block. I don’t think
> > 
> > You think that blocking softirq execution for 42.9 seconds is normal?
> > Seems we are living in a different universe.
> 
> I don't say it's normal. I say it's not hard to trigger.

So and because its not hard to trigger, we cure the symptom and do not
think about the insanity of blocking the watchdog for 42+ or 300+
seconds.
 
> > > it's just VM off. A softirq can hog the cpu.
> > 
> > I still want to see prove of that. There is just handwaving about
> > that, but nobody has provided proper data to back that up.
> 
> I showed you the TSC runs 75s, while hpet wraps. What info you think can
> prove this?

You prove nothing. You showed me the symptom, but you never showed
real data that a softirq hogs the cpu for 300+ seconds. Still you keep
claiming that.

You did neither provide a proper explanation WHY your VM test blocked
the watchdog for 75 seconds. No, you merily showed me the numbers. And
just because the numbers explain the symptom, that's no justification
WHY we should cure the symptom instead of looking at the root cause.

> > > >  - that emulating the HPET with 100MHz shortens the HPET wraparound by
> > > >a factor of 7 compared to real hardware. With a realist HPET
> > > >frequency you have about 300 seconds.
> > > > 
> > > >Who though that using 100MHz HPET frequency is a brilliant idea?
> > > 
> > > I'm not a VM expert. My guess is the 100Mhz can reduce interrupt. It’s
> > > insane hypervisor updates HPET count in 14.3Mhz. Switching to HPET can
> > > introduce even higher overhead in virtual, because of the vmexit of
> > > iomemory access
> > 
> > Sorry, that does not make any sense at all.
> > 
> > - How does 100Mhz HPET frequency reduce interrupts?
> > 
> > - What's insane about a lower emulated HPET frequency?
> > 
> > - We all know that switching to HPET is more expensive than just
> >   using TSC. That's not the question at all and completely
> >   unrelated to the 100MHz HPET emulation frequency.
> 
> It's meaningless to argue about HPET frequency. The code should not just
> work for 14.3Mhz HPET.

You carefully avoid to answer any of my questions, but you expect from
me to accept your wild guess argumentations?
 
> > I'm not pretending anything. I'm merily refusing to accept that change
> > w/o a proper explanation WHY the watchdog fails on physical hardware,
> > i.e. WHY it does not run for more than 300 seconds.
> 
> It's meaningless to argue about virtual/physical machine too. Linux
> works for both virtual/physical machines.

That has nothing to do with virt vs. physical. Virtualization is meant
to provide proper hardware emulation. Does Linux work with a buggy
APIC emulation? Not at all, but you expect that it just handles an
insane HPET emulation, right? 
 
> What about acpi_pm clocksource then? It wraps in abour 5s. It's sane
> HPET is disabled and acpi_pm is used for watchdog. Do you still think 5s
> is long?

Yes, five seconds is long. It's more than 10 billions worth of cpu
cycles on a 2GHz machine. If your desktop stalls for 5 seconds you are
probably less enthusiatic.

Again, I'm not against making the watchdog more robust, but I'm
against curing the symptoms. As long as you refuse to provide proper
explanations WHY the watchdog is blocked unduly long, this is going
nowhere.

Thanks,

tglx

Re: Security/cgroup suspicious RCU usage with v4.2-2744-g65a99597f044

[Josh Boyer]

On Tue, Sep 1, 2015 at 12:37 PM, Paul Moore  wrote:
> On Tue, Sep 1, 2015 at 12:21 PM, Josh Boyer  wrote:
>> Hi All,
>>
>> All of my test machines hit the backtrace below with Linus' tree as of
>> this morning.  Any ideas?
>
> It looks like you are seeing the same as below:
>
>  * https://lkml.org/lkml/2015/8/31/440

Indeed.  I'll keep an eye on that thread and see if another patch comes from it.

josh

>
>> [  +0.160966] ===
>> [  +0.01] [ INFO: suspicious RCU usage. ]
>> [  +0.02] 4.3.0-0.rc0.git1.1.fc24.x86_64 #1 Not tainted
>> [  +0.01] ---
>> [  +0.02] security/device_cgroup.c:405 device_cgroup:verify_new_ex
>> called without proper synchronization!
>> [  +0.00]
>>   other info that might help us debug this:
>>
>> [  +0.01]
>>   rcu_scheduler_active = 1, debug_locks = 0
>> [  +0.02] 4 locks held by systemd/1:
>> [  +0.10]  #0:  (sb_writers#6){.+.+.+}, at: []
>> vfs_write+0x187/0x1a0
>> [  +0.06]  #1:  (>mutex){+.+.+.}, at: []
>> kernfs_fop_write+0x66/0x190
>> [  +0.05]  #2:  (s_active#61){.+}, at: []
>> kernfs_fop_write+0x6e/0x190
>> [  +0.07]  #3:  (devcgroup_mutex){+.+...}, at:
>> [] devcgroup_access_write+0x3c/0x6e0
>> [  +0.00]
>>   stack backtrace:
>> [  +0.03] CPU: 3 PID: 1 Comm: systemd Not tainted
>> 4.3.0-0.rc0.git1.1.fc24.x86_64 #1
>> [  +0.01] Hardware name:  /D34010WYK, BIOS
>> WYLPT10H.86A.0026.2014.0514.1714 05/14/2014
>> [  +0.04]   6dc9945a 88040ce73c68
>> 8184e49c
>> [  +0.03]   88040cdd4000 88040ce73c98
>> 81101437
>> [  +0.03]  880408646d00 88040ce73d00 0002
>> 0001
>> [  +0.01] Call Trace:
>> [  +0.06]  [] dump_stack+0x4c/0x65
>> [  +0.04]  [] lockdep_rcu_suspicious+0xd7/0x110
>> [  +0.04]  [] verify_new_ex+0xd8/0xe0
>> [  +0.03]  [] devcgroup_access_write+0x3af/0x6e0
>> [  +0.05]  [] ? sched_clock+0x9/0x10
>> [  +0.04]  [] cgroup_file_write+0x44/0x1e0
>> [  +0.03]  [] kernfs_fop_write+0x141/0x190
>> [  +0.02]  [] __vfs_write+0x37/0x100
>> [  +0.02]  [] ? vfs_write+0x187/0x1a0
>> [  +0.04]  [] ? security_file_permission+0x3d/0xc0
>> [  +0.02]  [] vfs_write+0xa9/0x1a0
>> [  +0.03]  [] SyS_write+0x58/0xd0
>> [  +0.04]  [] entry_SYSCALL_64_fastpath+0x12/0x76
>> --
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-security-module" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> paul moore
> www.paul-moore.com
--
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: ipath: fix build failure

[Doug Ledford]

On 09/01/2015 12:54 PM, Jim Davis wrote:
> On Tue, Sep 1, 2015 at 7:52 AM, Doug Ledford  wrote:
>> On 09/01/2015 09:01 AM, Sudip Mukherjee wrote:
>>> building of ipath depends on infiniband. And if ipath is selected and
>>> infiniband is not then build fails with:
>>> ERROR: "ib_alloc_device" [drivers/staging/ipath/ib_ipath.ko] undefined!
>>> ERROR: "ib_dealloc_device" [drivers/staging/ipath/ib_ipath.ko] undefined!
>>> ERROR: "ib_dispatch_event" [drivers/staging/ipath/ib_ipath.ko] undefined!
>>> ERROR: "ib_register_device" [drivers/staging/ipath/ib_ipath.ko] undefined!
>>> ERROR: "ib_unregister_device" [drivers/staging/ipath/ib_ipath.ko] undefined!
>>> ERROR: "ib_modify_qp_is_ok" [drivers/staging/ipath/ib_ipath.ko] undefined!
>>> ERROR: "ib_wq" [drivers/staging/ipath/ib_ipath.ko] undefined!
>>>
>>> Config at: https://lkml.org/lkml/2015/8/31/328
>>>
>>> Reported-by: Jim Davis 
>>> Signed-off-by: Sudip Mukherjee 
>>> ---
>>>  drivers/staging/ipath/Kconfig | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/staging/ipath/Kconfig b/drivers/staging/ipath/Kconfig
>>> index 041ce06..1edc21b 100644
>>> --- a/drivers/staging/ipath/Kconfig
>>> +++ b/drivers/staging/ipath/Kconfig
>>> @@ -1,6 +1,7 @@
>>>  config INFINIBAND_IPATH
>>>   tristate "QLogic HTX HCA support"
>>>   depends on 64BIT && NET && HT_IRQ
>>> + depends on INFINIBAND
>>>   ---help---
>>>   This is a driver for the deprecated QLogic Hyper-Transport
>>>   IB host channel adapter (model QHT7140),
>>>
>>
>> The ipath driver was moved to staging/rdma/ipath and has proper
>> protection against being built without the InfiniBand subsystem.  Where
>> are you seeing this tree?  I'm curious because I no longer have this
>> driver in this location in my tree and I never pushed it anywhere other
>> than one of my trees.  Is this maybe in linux-next?
> 
> Yes; http://marc.info/?l=linux-kernel=144104080331664=3
> 

OK.  The current setup has this in drivers/staging/rdma/Kconfig:

menuconfig STAGING_RDMA
bool "RDMA staging drivers"
depends on INFINIBAND
depends on PCI || BROKEN
depends on HAS_IOMEM
depends on NET
depends on INET
default n
---help---
  This option allows you to select a number of RDMA drivers that
  fall into one of two categories: deprecated drivers being held
  here before finally being removed or new drivers that still need
  some work before being moved to the normal RDMA driver area.

  If you wish to work on these drivers, to help improve them, or
  to report problems you have with them, please use the
  linux-r...@vger.kernel.org mailing list.

  If in doubt, say N here.


# Please keep entries in alphabetic order
if STAGING_RDMA

source "drivers/staging/rdma/amso1100/Kconfig"

source "drivers/staging/rdma/hfi1/Kconfig"

source "drivers/staging/rdma/ipath/Kconfig"

endif


As you can see, it has proper depends for all of the drivers, so no need
to add dependencies piecemeal any longer.

-- 
Doug Ledford 
  GPG KeyID: 0E572FDD




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/3] selftests: add membarrier syscall test

[Mathieu Desnoyers]

- On Aug 31, 2015, at 2:54 AM, Michael Ellerman m...@ellerman.id.au wrote:

> On Fri, 2015-07-10 at 16:58 -0400, Mathieu Desnoyers wrote:
>> From: Pranith Kumar 
>> 
>> This patch adds a self test for the membarrier system call.
>> 
>> CC: Michael Ellerman 
> 
> Sorry I only just saw this due to some over zealous filtering on my end.
> 
> 
>> diff --git a/tools/testing/selftests/membarrier/Makefile
>> b/tools/testing/selftests/membarrier/Makefile
>> new file mode 100644
>> index 000..877a503
>> --- /dev/null
>> +++ b/tools/testing/selftests/membarrier/Makefile
>> @@ -0,0 +1,11 @@
>> +CFLAGS += -g -I../../../../usr/include/
>> +
>> +all:
>> +$(CC) $(CFLAGS) membarrier_test.c -o membarrier_test
>>
>> +TEST_PROGS := membarrier_test
> 
> You don't need to specify the rule, the implict one will do exactly the same,
> so you can just do:
> 
> TEST_PROGS := membarrier_test
> 
> all: $(TEST_PROGS)
> 
>> diff --git a/tools/testing/selftests/membarrier/membarrier_test.c
>> b/tools/testing/selftests/membarrier/membarrier_test.c
>> new file mode 100644
>> index 000..3c9f217
>> --- /dev/null
>> +++ b/tools/testing/selftests/membarrier/membarrier_test.c
>> @@ -0,0 +1,71 @@
>> +#define _GNU_SOURCE
>> +#define __EXPORTED_HEADERS__
> 
> Why are you exporting that?
> 
> I suspect to try and get around the "Attempt to use kernel headers from user
> space" warning.
> 
> But you're correctly building against the installed headers, not the kernel
> headers, so you don't need to do that.

Just to make sure I understand: should we expect that
everyone will issue "make headers_install" on their system
before doing a make kselftest ?

I see that a few selftests (e.g. memfd) are adding the
source tree include paths to the compiler include paths,
which I guess is to ensure that the kselftest will
work even if the system headers are not up to date.

Thanks,

Mathieu

> 
>> +
>> +#include 
>> +#include 
> 
> This should just be 
> 
> 
> cheers

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
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 19/20] xen/privcmd: Add support for Linux 64KB page granularity

[Julien Grall]

Hi Stefano,

On 10/08/15 13:03, Stefano Stabellini wrote:
>> +xen_pfn = xen_page_to_pfn(page);
>> +}
>> +fn(pfn_to_gfn(xen_pfn++), data);
> 
> What is the purpose of incrementing xen_pfn here?

Because the Linux page is split into multiple xen_pfn, so we want to get
the next xen_pfn for the next iteration.

Regards,

-- 
Julien Grall
--
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: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[Mark Rutland]

On Tue, Sep 01, 2015 at 05:51:44PM +0100, pins...@gmail.com wrote:
> 
> 
> 
> 
> > On Sep 2, 2015, at 12:33 AM, Mark Rutland  wrote:
> > 
> > Hi,
> > 
> >> On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
> >> It is useful to pass down MIDR register down to userland if all of
> >> the online cores are all the same type.  This adds AT_ARM64_MIDR
> >> aux vector type and passes down the midr system register.
> >> 
> >> This is alternative to MIDR_EL1 part of
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
> >> It allows for faster access to midr_el1 than going through a trap and
> >> does not exist if the set of cores are not the same.
> > 
> > I'm not sure I follow the rationale. If speed is important the
> > application can cache the value the first time it reads it with a trap.
> 
> It is also about compatibility also. Exposing the register is not
> backwards compatible but using the aux vector is. 

So long as we have HWCAP_CPUID describing the availability of register
access [2], then userspace can test for that before attempting to access
the MIDR.

Other than that, I don't see a backwards or forwards compatibility
issue.

> >> +u32 get_arm64_midr(void)
> >> +{
> >> +int i;
> >> +u32 midr = 0;
> >> +
> >> +for_each_online_cpu(i) {
> >> +struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
> >> +u32 oldmidr = midr;
> >> +
> >> +midr = cpuinfo->reg_midr;
> >> +/*
> >> + * If there are cpus which have a different
> >> + * midr just return 0.
> >> + */
> >> +if (oldmidr && oldmidr != midr)
> >> +return 0;
> >> +}
> >> +
> >> +return midr;
> >> +}
> > 
> > If I have a big.LITTLE system where all the big CPUs are currently
> > offline, this will leave the MIDR the little CPUs in the auxvec.
> > However, at any point after this has run, I could hotplug the big CPUs
> > on and the little CPUs off, leaving this reporting a MIDR that
> > represents none of the online CPUs.
> > 
> > Given big.LITTLE and the potential for physical/dynamic hotplug (where
> > we won't know all the MIDRs in advance), I don't think that we can
> > generally expose a common MIDR in this fashion, and I don't think that
> > we should give the impression that we can.
> 
> This is standard issue with hot plug and big.little. Really big.little
> is a design flaw but I am not going into that here. 

Regardless of our personal feelings on big.LITTLE, it's something we
have to deal with.

Hopefully it's a non-issue anyway; a MIDR provided by this interface can
really only be used to derive optimisation criteria rather than
non-architected properties required for correctness.

> > I think that the only things we can do are expose the MIDR for CPU the
> > code is currently executing on (as Suzuki's patches do), and/or expose
> > all the MIDRs for currently online CPUs (as Steve's [1] patch does).
> > Anything else leaves us trying to provide semantics that we cannot
> > guarantee.
> 
> Except they are not backwards compatible which means nobody in their
> right mind would use the register to get the midr that way.

I assume you missed the discussion of HWCAP_CPUID, which prevents the
compatibility issue I believe you're considering here.

> I am sorry but having a newer version of glibc working on a year old
> kernel is not going to fly. 

I'm not sure I follow this, unless you meant _not_ working.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359127.html
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363559.html
--
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] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*

[Keerthy]

On Wednesday 26 August 2015 09:29 AM, Keerthy wrote:

Currently apart from dra7, omap5 and amx3 all the other SoCs
are identified using cpu_is_* functions which is not right since
they are all SoCs(System on Chips). Hence changing the SoC
identification code to use soc_is instead of cpu_is and keeping
defines for cpu_is where needed. This allows us to replace the
rest of cpu_is usage along with other fixes as needed.


Tony,

A Gentle ping on this.

Regards,
Keerthy



Acked-by: Russell King 
Signed-off-by: Keerthy 
---

Changes in v2:

   * Corrected a typo in the commit log.

  arch/arm/mach-omap2/id.c  |  30 +++
  arch/arm/mach-omap2/soc.h | 193 ++
  2 files changed, 123 insertions(+), 100 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f713f..24f24d4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -57,15 +57,15 @@ int omap_type(void)
if (val < OMAP2_DEVICETYPE_MASK)
return val;

-   if (cpu_is_omap24xx()) {
+   if (soc_is_omap24xx()) {
val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
-   } else if (cpu_is_ti81xx()) {
+   } else if (soc_is_ti81xx()) {
val = omap_ctrl_readl(TI81XX_CONTROL_STATUS);
} else if (soc_is_am33xx() || soc_is_am43xx()) {
val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
-   } else if (cpu_is_omap34xx()) {
+   } else if (soc_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
-   } else if (cpu_is_omap44xx()) {
+   } else if (soc_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
@@ -122,7 +122,7 @@ static u16 tap_prod_id;

  void omap_get_die_id(struct omap_die_id *odi)
  {
-   if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
+   if (soc_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -218,17 +218,17 @@ static void __init omap3_cpuinfo(void)
 * on available features. Upon detection, update the CPU id
 * and CPU class bits.
 */
-   if (cpu_is_omap3630()) {
+   if (soc_is_omap3630()) {
cpu_name = "OMAP3630";
} else if (soc_is_am35xx()) {
cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
-   } else if (cpu_is_ti816x()) {
+   } else if (soc_is_ti816x()) {
cpu_name = "TI816X";
} else if (soc_is_am335x()) {
cpu_name =  "AM335X";
} else if (soc_is_am437x()) {
cpu_name =  "AM437x";
-   } else if (cpu_is_ti814x()) {
+   } else if (soc_is_ti814x()) {
cpu_name = "TI814X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
@@ -275,11 +275,11 @@ void __init omap3xxx_check_features(void)
OMAP3_CHECK_FEATURE(status, SGX);
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
-   if (cpu_is_omap3630())
+   if (soc_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
-   if (cpu_is_omap3430() || cpu_is_omap3630())
+   if (soc_is_omap3430() || soc_is_omap3630())
omap_features |= OMAP3_HAS_IO_WAKEUP;
-   if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
+   if (soc_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
omap_rev() == OMAP3430_REV_ES3_1_2)
omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;

@@ -697,7 +697,7 @@ void __init omap2_set_globals_tap(u32 class, void __iomem 
*tap)
tap_base = tap;

/* XXX What is this intended to do? */
-   if (cpu_is_omap34xx())
+   if (soc_is_omap34xx())
tap_prod_id = 0x0210;
else
tap_prod_id = 0x0208;
@@ -715,11 +715,11 @@ static const char * const omap_types[] = {

  static const char * __init omap_get_family(void)
  {
-   if (cpu_is_omap24xx())
+   if (soc_is_omap24xx())
return kasprintf(GFP_KERNEL, "OMAP2");
-   else if (cpu_is_omap34xx())
+   else if (soc_is_omap34xx())
return kasprintf(GFP_KERNEL, "OMAP3");
-   else if (cpu_is_omap44xx())
+   else if (soc_is_omap44xx())
return kasprintf(GFP_KERNEL, "OMAP4");
else if (soc_is_omap54xx())
return kasprintf(GFP_KERNEL, "OMAP5");
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index f97654d..bb824ae 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -148,13 +148,13 @@ 

Re: [PATCH] ps3-vuart: BUG_ON on null drv before dereferencing it on dev_dbg

[Geoff Levand]

On Tue, 2015-09-01 at 11:21 +0100, Colin King wrote:
> On the unlikely event that drv is null, the current code will
> perform a null pointer dereference with it when printing a dev_dbg
> message.  Instead, the BUG_ON check on drv should be performed
> before we emit the dev_dbg message.
> 
> Signed-off-by: Colin Ian King 

I applied this to my ps3-linux repo.  I can update it if you decide to
do the other fixes Geert mentioned.

-Geoff

--
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: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[Mark Rutland]

[...]

> >>> On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
> >>> It is useful to pass down MIDR register down to userland if all of
> >>> the online cores are all the same type.  This adds AT_ARM64_MIDR
> >>> aux vector type and passes down the midr system register.
> >>> 
> >>> This is alternative to MIDR_EL1 part of
> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
> >>> It allows for faster access to midr_el1 than going through a trap and
> >>> does not exist if the set of cores are not the same.
> >> 
> >> I'm not sure I follow the rationale. If speed is important the
> >> application can cache the value the first time it reads it with a trap.
> > 
> > It is also about compatibility also. Exposing the register is not backwards 
> > compatible but using the aux vector is. 
> 
> That would also break big.little too. So either break it with hot plug or 
> break it in userland, your choice. 

The value wouldn't be representative of the system as a whole; that is
true. However, we never guaranteed that it was, while the aux vector
code implied that we did.

For optimisation that may be good enough; code optimized for a different
uArch should still function on another, even if it is slower.

> >> This also means that the behaviour is different across homogeneous and
> >> heterogeneous systems.
> 
> That should be ok because it is still backwards compatible with what
> was done before.  My goal here is just to allow quick easy access to
> midr in the case of a homogeneous system which I care about, thunderx
> and to allow glibc to select a memcpy/memset that is better for
> thunderx. 

As I mentioned in the other thread, I think that HWCAP_CPUID is
sufficient to enable forwards and backwards compatibility. If it is
present then you can use the current CPU's MIDR to select a better
memcpy/memset if required.

Thanks,
Mark.
--
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] fs: have flush_delayed_fput flush the workqueue job

[Jeff Layton]

On Tue,  1 Sep 2015 13:35:53 -0400
Jeff Layton  wrote:

> I think there's a potential race in flush_delayed_fput. A kthread does
> an fput() and that file gets added to the list and the delayed work is
> scheduled. More than 1 jiffy passes, and the workqueue thread picks up
> the work and starts running it. Then the kthread calls
> flush_delayed_work.  It sees that the list is empty and returns
> immediately, even though the __fput for its file may not have run yet.
> 
> Close this by making flush_delayed_fput use flush_delayed_work instead,
> which should just block until the workqueue job completes if it's
> already running.
> 
> Signed-off-by: Jeff Layton 
> ---
>  fs/file_table.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/file_table.c b/fs/file_table.c
> index 7f9d407c7595..f4833af62eae 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -243,6 +243,8 @@ static void fput(struct callback_head *work)
>   __fput(container_of(work, struct file, f_u.fu_rcuhead));
>  }
>  
> +static DECLARE_DELAYED_WORK(delayed_fput_work, delayed_fput);
> +
>  /*
>   * If kernel thread really needs to have the final fput() it has done
>   * to complete, call this.  The only user right now is the boot - we
> @@ -255,11 +257,9 @@ static void fput(struct callback_head *work)
>   */
>  void flush_delayed_fput(void)
>  {
> - delayed_fput(NULL);
> + flush_delayed_work(_fput_work);
>  }
>  
> -static DECLARE_DELAYED_WORK(delayed_fput_work, delayed_fput);
> -
>  void fput(struct file *file)
>  {
>   if (atomic_long_dec_and_test(>f_count)) {

Hi Al,

I just noticed this by inspection. I had a suspicion that I had hit
this race in some code I'm developing, but it turned out to be a
different problem. Still, I think the race looks plausible.

I do have another (somewhat related) problem though that I could use
your advice on. In a nutshell, there doesn't seem to be an equivalent
to flush_delayed_fput for fputs that have been task_work_add'ed.

I'm working on an open file cache for knfsd. What we want to do is to
allow knfsd to hold files open indefinitely until:

- the exports cache is flushed
- there is a REMOVE or RENAME call that would unlink the dentry
- someone wants to set a lease on the file

The setlease the main problem. When we close down the cache entry, we
call fput on the struct file we hold, but since it's running in normal
process context it gets queued to task_work. We need the final __fput
to run before we try to set the lease though or the refcounts will
remain high and block the lease attempt.

Is it reasonable to call task_work_run() to flush the work, or will
that turn out to be nasty? Alternately, could we allow __fput_sync to
be run from normal process context? If so, then I could just
synchronously put the files when I need to close them to allow a
setlease to proceed.

What would be the best approach for flushing delayed fputs from normal
process context, before returning to userland?

-- 
Jeff Layton 
--
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 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

[Will Deacon]

On Fri, Aug 28, 2015 at 04:39:21PM +0100, Peter Zijlstra wrote:
> On Fri, Aug 28, 2015 at 10:16:02PM +0800, Boqun Feng wrote:
> > Ah.. just read through the thread you mentioned, I might misunderstand
> > you, probably because I didn't understand RCpc well..
> > 
> > You are saying that in a RELEASE we -might- switch from smp_lwsync() to
> > smp_mb() semantically, right? I guess this means we -might- switch from
> > RCpc to RCsc, right?
> > 
> > If so, I think I'd better to wait until we have a conclusion for this.
> 
> Yes, the difference between RCpc and RCsc is in the meaning of RELEASE +
> ACQUIRE. With RCsc that implies a full memory barrier, with RCpc it does
> not.

We've discussed this before, but for the sake of completeness, I don't
think we're fully RCsc either because we don't order the actual RELEASE
operation again a subsequent ACQUIRE operation:


P0
smp_store_release(, 1);
foo = smp_load_acquire();

P1
smp_store_release(, 1);
bar = smp_load_acquire();

We allow foo == bar == 0, which is prohibited by SC.


However, we *do* enforce ordering on any prior or subsequent accesses
for the code snippet above (the release and acquire combine to give a
full barrier), which makes these primitives well suited to things like
message passing.

Will
--
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] arch/x86/mm/srat: Print non-volatile flag in SRAT

[Thomas Gleixner]

On Tue, 1 Sep 2015, Linda Knippers wrote:
> On 9/1/2015 3:17 PM, Thomas Gleixner wrote:
> > On Tue, 1 Sep 2015, Linda Knippers wrote:
> >> Nobody checks this flag but it would be interesting to know if it's being
> >> set on any platforms.
> > 
> > What you're omitting to explain, is WHY it would be interesting.
> 
> With the addition of NVDIMM support, a question came up as to whether
> NVDIMM ranges should be in the SRAT with this bit set.  I think the
> consensus was no because the ranges are in the NFIT with proximity
> domain information there.
> 
> ACPI is not clear on the meaning of this bit in the SRAT.
> If someone is setting it, we might want to ask them what they expect
> to happen with it.
> 
> Right now this bit is only printed if all the ACPI debug information is
> turned on.
> 
> Sorry, I should have explained more.

Indeed. And that explanation wants to be in the changelog. Care to resend?

Thanks,

tglx
--
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/

[RFC 0/3] mmc: sdhci: pass signal voltage as an argument to ->voltage_switch()

[Vaibhav Hiremath]

In order to do particular voltage specific configuration in
sdhci_ops->voltage_switch() callback function, we need to
pass respective voltage value as well.

So this patch series pass signal voltage to the controller
specific ->voltage_switch() callback.
Adds controller specific configuration for other voltages as well,
and add implementation for ->voltage_switch to pxav3 driver.


Note:
Currently ->voltage_switch() callback is only supported
in f_sdh30 driver. And I am not sure on the dependency of execution
sequence for that device. I could have moved ->voltage_switch() call
at one common place (above/below), but was not quite sure about it.
So, replicated/duplicated the call for other voltages.


Vaibhav Hiremath (3):
  mmc: sdhci: pass signal_voltage as an argument to voltage_switch
callback
  mmc: sdhci: add host_ops->voltage_switch callback for all other
voltages
  mmc: sdhci-pxav3: Add ->voltage_switch callback support

 drivers/mmc/host/sdhci-pxav3.c   | 59 
 drivers/mmc/host/sdhci.c | 10 ++-
 drivers/mmc/host/sdhci.h |  2 +-
 drivers/mmc/host/sdhci_f_sdh30.c |  3 +-
 4 files changed, 71 insertions(+), 3 deletions(-)

-- 
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 8/9] clocksource: Improve unstable clocksource detection

[Steven Rostedt]

On Tue, 1 Sep 2015 11:14:17 -0700
Shaohua Li  wrote:

> > You think that blocking softirq execution for 42.9 seconds is normal?
> > Seems we are living in a different universe.
> 
> I don't say it's normal. I say it's not hard to trigger.
> 
> > > it's just VM off. A softirq can hog the cpu.
> > 

Please provide a test case that shows the softirq hogging the cpu for
over 40 seconds.

-- Steve
--
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: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski  wrote:
> On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer  wrote:
>> So if someone wants to rebuild a kernel that contains the kdbus driver
>> and jump through the hoops you describe, then yes they might very well
>> run into problems you suggest might be present.  However, they will
>> also not be running Fedora 23 at that point.  I wish such users well
>> and thank them for their upstream testing efforts.
>>
>
> This does highlight a difference in configurations that the upstream
> kernel configures supported versus what Fedora considers supported.
> From Fedora's POV (correct me if I'm wrong), if you boot with a kernel
> with an unsupported configuration, it's unsupported.  From the
> upstream kernel's POV, if you flip on new features and boot an old
> distro, it's supposed to work with *very* few exceptions.

Well, mostly.  We've certainly turned on configuration options in the
Fedora kernel, reported problems with them, and been told by upstream
"why would you enable that?  It's not ready/relevant for distro use."
So in theory I agree with you, but not everyone follows those rules it
seems.

>> To be honest, I'm not sure what "process" you're talking about.
>> Kernel development is kind of rife with examples of new features
>> having security issues and it taking time to sort them out.  I don't
>> mean to cast aspersions, but user namespaces has had numerous CVEs
>> since it's inclusion.  I don't think anyone here has ever accused its
>> development of not following some kind of process.  And distros took
>> some time before enabling that feature, which is what I expect to
>> happen with kdbus should it ever be merged.  That certainly isn't an
>> argument for allowing _known_ security issues into the kernel, but as
>> you said, you haven't found a security hole as of yet.
>
> No one in user namespace land has considered it acceptable for an old
> userspace that's running a new kernel with user namespaces turned on
> to have security problems as a result of user namespaces.  It's
> happened, but it's considered a problem to be fixed with high
> priority.  I'd be reassured if kdbus took a similar stance.

And again, I'm not sure why you think the kdbus developers aren't?
You haven't found any security holes.  They haven't submitted a pull
request for 4.3.  As far as I can tell, things are still being worked
on and developed as expected.  I personally really appreciate your
diligence on the security aspects of kdbus.  Frankly, I hope you _do_
find security holes so that they can be fixed before it is merged.
But I've not seen anything that would indicate to me the kdbus
developers would ignore such an issue if you found one.

josh
--
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: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  wrote:
>> Hi
>>
>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  wrote:
>>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
>>> wrote:
 On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
 wrote:
> I haven't checked the context in which it's used, but in order for
> kdbus_proc_permission to do what it claims to do, it appears to be
> missing calls to security_inode_permission and
> security_file_permission.

 Both are expected to be added by lsm patches (both hooks you mentioned
 are empty if no lsm is selected).
>>>
>>> Will that mean that existing MAC policies stop being fully enforced
>>> (in effect) if kdbus is installed?
>>
>> It means kdbus messages carry information about the sender, which LSMs
>> might prevent you to read via /proc. Just like you can send dbus
>> messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>
> It's a security-sensitive function that doesn't do what the name and
> description suggest.  Whether that's an active problem or not is
> unknown, but it's certainly a maintainability problem.
>
>> If
>> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
>> support. We explicitly support legacy dbus1-compat for exactly such
>> reasons.
>
> This is not an acceptable attitude for security.
>
> There are so many things wrong with your statement that I'll limit
> myself to one of them: Fedora 23/Rawhide, which is the *reference*
> platform, uses SELinux.

Clarification: Fedora Rawhide only.  The kdbus code is not included in
the F23 kernel.

Your point otherwise stands.  I just don't want Phoronix or someone
else getting confused and thinking Fedora 23 will ship with kdbus.  It
will not.

josh
--
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 8/9] clocksource: Improve unstable clocksource detection

[Thomas Gleixner]

On Mon, 31 Aug 2015, Shaohua Li wrote:
> On Mon, Aug 31, 2015 at 11:47:52PM +0200, Thomas Gleixner wrote:
> > On Mon, 31 Aug 2015, Shaohua Li wrote:
> > > > The HPET wraps interval is 0x / 1 = 42.9s
> > > > 
> > > > tsc interval is (0x481250b45b - 0x219e6efb50) / 22 = 75s
> > > > 
> > > > 32.1 + 42.9 = 75
> > > > 
> > > > The example shows hpet wraps, while tsc is marked unstable
> > > 
> > > Thomas & John,
> > > Is this data enough to prove TSC unstable issue can be triggered by HPET
> > > wrap? I can resend the patch with the data included.
> > 
> > Well, it's enough data to prove:
> > 
> >  - that keeping a VM off the CPU for 75 seconds is insane.
> 
> It wraps in 42.9s. 42.9s isn't a long time hard to block. I don’t think

You think that blocking softirq execution for 42.9 seconds is normal?
Seems we are living in a different universe.

> it's just VM off. A softirq can hog the cpu.

I still want to see prove of that. There is just handwaving about
that, but nobody has provided proper data to back that up.

> >  - that emulating the HPET with 100MHz shortens the HPET wraparound by
> >a factor of 7 compared to real hardware. With a realist HPET
> >frequency you have about 300 seconds.
> > 
> >Who though that using 100MHz HPET frequency is a brilliant idea?
> 
> I'm not a VM expert. My guess is the 100Mhz can reduce interrupt. It’s
> insane hypervisor updates HPET count in 14.3Mhz. Switching to HPET can
> introduce even higher overhead in virtual, because of the vmexit of
> iomemory access

Sorry, that does not make any sense at all.

- How does 100Mhz HPET frequency reduce interrupts?

- What's insane about a lower emulated HPET frequency?

- We all know that switching to HPET is more expensive than just
  using TSC. That's not the question at all and completely
  unrelated to the 100MHz HPET emulation frequency.

> > So we should add crappy heuristics to the watchdog just to workaround
> > virt insanities? I'm not convinced.
> 
> This is a real issue which could impact performance seriously. Though
> the data is collected in vm, we do see the issue happens in physical
> machines too.

And what's the exact reason for this on physical machines? Some magic
softirq hog again for which you cannot provide proof?

> The watchdog clock source shows restriction here apparently, it
> deserves an improvement if we can do.

The restriction in a sane environment is 300 seconds. And the only
fallout on physical hardware which we have seen so far is on
preempt-RT where the softirq can actually be blocked by RT hogs, but
that's a completely different issue and has nothing to do with the
situation in mainline.

> I'm happy to hear from you if there is better solution, but we
> shouldn't pretend there is no issue here.

I'm not pretending anything. I'm merily refusing to accept that change
w/o a proper explanation WHY the watchdog fails on physical hardware,
i.e. WHY it does not run for more than 300 seconds.

Thanks,

tglx

Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection

[Shaohua Li]

On Tue, Sep 01, 2015 at 07:13:40PM +0200, Thomas Gleixner wrote:
> On Mon, 31 Aug 2015, Shaohua Li wrote:
> > On Mon, Aug 31, 2015 at 11:47:52PM +0200, Thomas Gleixner wrote:
> > > On Mon, 31 Aug 2015, Shaohua Li wrote:
> > > > > The HPET wraps interval is 0x / 1 = 42.9s
> > > > > 
> > > > > tsc interval is (0x481250b45b - 0x219e6efb50) / 22 = 75s
> > > > > 
> > > > > 32.1 + 42.9 = 75
> > > > > 
> > > > > The example shows hpet wraps, while tsc is marked unstable
> > > > 
> > > > Thomas & John,
> > > > Is this data enough to prove TSC unstable issue can be triggered by HPET
> > > > wrap? I can resend the patch with the data included.
> > > 
> > > Well, it's enough data to prove:
> > > 
> > >  - that keeping a VM off the CPU for 75 seconds is insane.
> > 
> > It wraps in 42.9s. 42.9s isn't a long time hard to block. I don’t think
> 
> You think that blocking softirq execution for 42.9 seconds is normal?
> Seems we are living in a different universe.

I don't say it's normal. I say it's not hard to trigger.

> > it's just VM off. A softirq can hog the cpu.
> 
> I still want to see prove of that. There is just handwaving about
> that, but nobody has provided proper data to back that up.

I showed you the TSC runs 75s, while hpet wraps. What info you think can
prove this?
> > >  - that emulating the HPET with 100MHz shortens the HPET wraparound by
> > >a factor of 7 compared to real hardware. With a realist HPET
> > >frequency you have about 300 seconds.
> > > 
> > >Who though that using 100MHz HPET frequency is a brilliant idea?
> > 
> > I'm not a VM expert. My guess is the 100Mhz can reduce interrupt. It’s
> > insane hypervisor updates HPET count in 14.3Mhz. Switching to HPET can
> > introduce even higher overhead in virtual, because of the vmexit of
> > iomemory access
> 
> Sorry, that does not make any sense at all.
> 
> - How does 100Mhz HPET frequency reduce interrupts?
> 
> - What's insane about a lower emulated HPET frequency?
> 
> - We all know that switching to HPET is more expensive than just
>   using TSC. That's not the question at all and completely
>   unrelated to the 100MHz HPET emulation frequency.

It's meaningless to argue about HPET frequency. The code should not just
work for 14.3Mhz HPET.

> > > So we should add crappy heuristics to the watchdog just to workaround
> > > virt insanities? I'm not convinced.
> > 
> > This is a real issue which could impact performance seriously. Though
> > the data is collected in vm, we do see the issue happens in physical
> > machines too.
> 
> And what's the exact reason for this on physical machines? Some magic
> softirq hog again for which you cannot provide proof?
> 
> > The watchdog clock source shows restriction here apparently, it
> > deserves an improvement if we can do.
> 
> The restriction in a sane environment is 300 seconds. And the only
> fallout on physical hardware which we have seen so far is on
> preempt-RT where the softirq can actually be blocked by RT hogs, but
> that's a completely different issue and has nothing to do with the
> situation in mainline.
> 
> > I'm happy to hear from you if there is better solution, but we
> > shouldn't pretend there is no issue here.
> 
> I'm not pretending anything. I'm merily refusing to accept that change
> w/o a proper explanation WHY the watchdog fails on physical hardware,
> i.e. WHY it does not run for more than 300 seconds.

It's meaningless to argue about virtual/physical machine too. Linux
works for both virtual/physical machines.

What about acpi_pm clocksource then? It wraps in abour 5s. It's sane
HPET is disabled and acpi_pm is used for watchdog. Do you still think 5s
is long?

Thanks,
Shaohua
--
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: omap2: vc: fix 'or' always true warning

[Frans Klaver]

On Tue, Sep 1, 2015 at 5:46 PM, Tony Lindgren  wrote:
> * Frans Klaver  [150828 03:14]:
>> From: Frans Klaver 
>>
>> Fix the warning:
>> arch/arm/mach-omap2/vc.c:302:47: warning: logical ‘or’ of collectively 
>> exhaustive tests is always true [-Wlogical-op]
>>
>> As we're toggling both CLKREQ and OFFMODE, we should also be checking
>> OFFMODE.
>>
>> Signed-off-by: Frans Klaver 
>
> Thanks apppying into omap-for-v4.3/fixes.

Thanks!

Frans
--
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] power: bq24261_charger: Add support for TI BQ24261 charger

[Pallala, Ramakrishna]

Hi Andreas,

> On Wed, Aug 26, 2015 at 11:03:00AM +, Pallala, Ramakrishna wrote:
> > Hi Andreas,
> >
> > I went on a unplanned leave and I came back to office recently. I will go
> through your comments and get back to you.
> 
> Hi Ram,
> hope all is well. Please let me know your plans/timeline for completing this
> because I'm on the hook for delivering support for bq24261M and
> bq24262 and I was planning on adding it to your driver.
> 
> Also should bandwidth be an issue I will be happy to help out in any way I can
> even taking over the completion of this driver if needed - just let me know.

I will resubmit the patch by this weekend. I Hope this works for you.

Thanks,
Ram
--
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: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  wrote:
> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
>> wrote:
>>> Hi
>>>
>>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
>>> wrote:
 On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
 wrote:
> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
> wrote:
>> I haven't checked the context in which it's used, but in order for
>> kdbus_proc_permission to do what it claims to do, it appears to be
>> missing calls to security_inode_permission and
>> security_file_permission.
>
> Both are expected to be added by lsm patches (both hooks you mentioned
> are empty if no lsm is selected).

 Will that mean that existing MAC policies stop being fully enforced
 (in effect) if kdbus is installed?
>>>
>>> It means kdbus messages carry information about the sender, which LSMs
>>> might prevent you to read via /proc. Just like you can send dbus
>>> messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>>
>> It's a security-sensitive function that doesn't do what the name and
>> description suggest.  Whether that's an active problem or not is
>> unknown, but it's certainly a maintainability problem.
>>
>>> If
>>> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
>>> support. We explicitly support legacy dbus1-compat for exactly such
>>> reasons.
>>
>> This is not an acceptable attitude for security.
>>
>> There are so many things wrong with your statement that I'll limit
>> myself to one of them: Fedora 23/Rawhide, which is the *reference*
>> platform, uses SELinux.
>
> Clarification: Fedora Rawhide only.  The kdbus code is not included in
> the F23 kernel.
>
> Your point otherwise stands.  I just don't want Phoronix or someone
> else getting confused and thinking Fedora 23 will ship with kdbus.  It
> will not.

But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
Granted, systemd is build with --disable-kdbus, but if it's a new
enough version, then I think that means that the code is still there.

To be clear, I don't claim to have found a specific security hole, but
in the event that running Fedora 23 with a kdbus-supporting kernel and
booting with kdbus=1 [1] introduces security problems, then we have a
problem. (This isn't nearly as bad as it would be if we had problems
just by upgrading the kernel.)  And there is certainly something wrong
with the process if the kdbus team thinks it's okay that enabling
kdbus can break existing security policy.

--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/

Re: [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is enabled

[Michal Hocko]

On Tue 01-09-15 19:55:54, Vladimir Davydov wrote:
> On Tue, Sep 01, 2015 at 05:01:20PM +0200, Michal Hocko wrote:
> > On Tue 01-09-15 16:40:03, Vladimir Davydov wrote:
> > > On Tue, Sep 01, 2015 at 02:36:12PM +0200, Michal Hocko wrote:
[...]
> > > > How the fallback is implemented and whether trying other node before
> > > > reclaiming from the preferred one is reasonable I dunno. This is for
> > > > SLAB to decide. But ignoring GFP_NOWAIT for this path makes the behavior
> > > > for memcg enabled setups subtly different. And that is bad.
> > > 
> > > Quite the contrary. Trying to charge memcg w/o __GFP_WAIT while
> > > inspecting if a NUMA node has free pages makes SLAB behaviour subtly
> > > differently: SLAB will walk over all NUMA nodes for nothing instead of
> > > invoking memcg reclaim once a free page is found.
> > 
> > So you are saying that the SLAB kmem accounting in this particular path
> > is suboptimal because the fallback mode doesn't retry local node with
> > the reclaim enabled before falling back to other nodes?
> 
> I'm just pointing out some subtle behavior changes in slab you were
> opposed to.

I guess we are still not at the same page here. If the slab has a subtle
behavior (and from what you are saying it seems it has the same behavior
at the global scope) then we should strive to fix it rather than making
it more obscure just to not expose GFP_NOWAIT to memcg which is not
handled properly currently wrt. high limit (more on that below) which
was the primary motivation for the patch AFAIU.

> > I would consider it quite surprising as well even for the global case
> > because __GFP_THISNODE doesn't wake up kswapd to make room on that node.
> > 
> > > You are talking about memcg/kmem accounting as if it were done in the
> > > buddy allocator on top of which the slab layer is built knowing nothing
> > > about memcg accounting on the lower layer. That's not true and that
> > > simply can't be true. Kmem accounting is implemented at the slab layer.
> > > Memcg provides its memcg_charge_slab/uncharge methods solely for
> > > slab core, so it's OK to have some calling conventions between them.
> > > What we are really obliged to do is to preserve behavior of slab's
> > > external API, i.e. kmalloc and friends.
> > 
> > I guess I understand what you are saying here but it sounds like special
> > casing which tries to be clever because the current code understands
> > both the lower level allocator and kmem charge paths to decide how to
> 
> What do you mean by saying "it understands the lower level allocator"?

I mean it requires/abuses special behavior from the page allocator like
__GFP_THISNODE && !wait for the hot path. 

> AFAIK we have memcg callbacks only in special places, like page fault
> handler or kmalloc.

But anybody might opt-in to be charged. I can see some other buffers
which are even not accounted for right now will be charged in future.

> > juggle with them. This is imho bad and hard to maintain long term.
> 
> We already juggle. Just grep where and how we insert
> mem_cgroup_try_charge.

We should always preserve the gfp context (at least its reclaim
part). If we are not then it is a bug.
 
> > > > >  2. SLUB. Someone calls kmalloc and there is enough free high order
> > > > > pages. If there is no memcg limit, we will allocate a high order
> > > > > slab page, which is in accordance with SLUB internal logic. With
> > > > > memcg limit set, we are likely to fail to charge high order page
> > > > > (because we currently try to charge high order pages w/o 
> > > > > __GFP_WAIT)
> > > > > and fallback on a low order page. The latter is unexpected and
> > > > > unjustified.
> > > > 
> > > > And this case very similar and I even argue that it shows more
> > > > brokenness with your patch. The SLUB allocator has _explicitly_ asked
> > > > for an allocation _without_ reclaim because that would be unnecessarily
> > > > too costly and there is other less expensive fallback. But memcg would
> > > 
> > > You are ignoring the fact that, in contrast to alloc_pages, for memcg
> > > there is practically no difference between charging a 4-order page or a
> > > 1-order page.
> > 
> > But this is an implementation details which might change anytime in
> > future.
> 
> The fact that memcg reclaim does not invoke compactor is indeed an
> implementation detail, but how can it change?

Compaction is indeed not something memcg reclaim cares about right now
or will care in foreseeable future. I meant something else. order-1 vs.
ordern-N differ in the reclaim target which then controls the potential
latency of the reclaim. The fact that order-1 and order-4 do not really
make any difference _right now_ because of the large SWAP_CLUSTER_MAX is
the implementation detail I was referring to.
 
> > > OTOH, using 1-order pages where we could go with 4-order
> > > pages increases page fragmentation at the global level. This subtly
> > > breaks internal SLUB optimization. Once 

[PATCH V2] PM / Domains: Remove cpuidle attach

[Daniel Lezcano]

The power domains code allows to tie a cpuidle state with a power domain.

Preventing the cpuidle framework to enter a specific idle state by disabling
from the power domain framework is a good idea. Unfortunately, the current
implementation has some gaps with a SMP system and a complex cpuidle
implementation. Enabling a power domain wakes up all the cpus even if a cpu
does not belong to the power domain.

There is some work to do a logical representation with the power domains of
the hardware dependencies (eg. a cpu belongs to a power domains, these power
domains belong to a higher power domain for a cluster, etc ...). A new code
relying on the genpd hierarchy to disable the idle states would make more
sense.

As the unique user of this code has been removed, let's wipe out this code
to prevent new user and to have a clean place to put a new implementation.

Signed-off-by: Daniel Lezcano 
---
 drivers/base/power/domain.c | 154 
 include/linux/pm_domain.h   |  27 
 2 files changed, 181 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 0ee43c1..f468627 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -171,19 +171,6 @@ static void genpd_set_active(struct generic_pm_domain 
*genpd)
genpd->status = GPD_STATE_ACTIVE;
 }
 
-static void genpd_recalc_cpu_exit_latency(struct generic_pm_domain *genpd)
-{
-   s64 usecs64;
-
-   if (!genpd->cpuidle_data)
-   return;
-
-   usecs64 = genpd->power_on_latency_ns;
-   do_div(usecs64, NSEC_PER_USEC);
-   usecs64 += genpd->cpuidle_data->saved_exit_latency;
-   genpd->cpuidle_data->idle_state->exit_latency = usecs64;
-}
-
 static int genpd_power_on(struct generic_pm_domain *genpd, bool timed)
 {
ktime_t time_start;
@@ -207,7 +194,6 @@ static int genpd_power_on(struct generic_pm_domain *genpd, 
bool timed)
 
genpd->power_on_latency_ns = elapsed_ns;
genpd->max_off_time_changed = true;
-   genpd_recalc_cpu_exit_latency(genpd);
pr_debug("%s: Power-%s latency exceeded, new value %lld ns\n",
 genpd->name, "on", elapsed_ns);
 
@@ -280,13 +266,6 @@ static int __pm_genpd_poweron(struct generic_pm_domain 
*genpd)
return 0;
}
 
-   if (genpd->cpuidle_data) {
-   cpuidle_pause_and_lock();
-   genpd->cpuidle_data->idle_state->disabled = true;
-   cpuidle_resume_and_unlock();
-   goto out;
-   }
-
/*
 * The list is guaranteed not to change while the loop below is being
 * executed, unless one of the masters' .power_on() callbacks fiddles
@@ -595,21 +574,6 @@ static int pm_genpd_poweroff(struct generic_pm_domain 
*genpd)
}
}
 
-   if (genpd->cpuidle_data) {
-   /*
-* If cpuidle_data is set, cpuidle should turn the domain off
-* when the CPU in it is idle.  In that case we don't decrement
-* the subdomain counts of the master domains, so that power is
-* not removed from the current domain prematurely as a result
-* of cutting off the masters' power.
-*/
-   genpd->status = GPD_STATE_POWER_OFF;
-   cpuidle_pause_and_lock();
-   genpd->cpuidle_data->idle_state->disabled = false;
-   cpuidle_resume_and_unlock();
-   goto out;
-   }
-
if (genpd->power_off) {
if (atomic_read(>sd_count) > 0) {
ret = -EBUSY;
@@ -1725,124 +1689,6 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain 
*genpd,
return ret;
 }
 
-/**
- * pm_genpd_attach_cpuidle - Connect the given PM domain with cpuidle.
- * @genpd: PM domain to be connected with cpuidle.
- * @state: cpuidle state this domain can disable/enable.
- *
- * Make a PM domain behave as though it contained a CPU core, that is, instead
- * of calling its power down routine it will enable the given cpuidle state so
- * that the cpuidle subsystem can power it down (if possible and desirable).
- */
-int pm_genpd_attach_cpuidle(struct generic_pm_domain *genpd, int state)
-{
-   struct cpuidle_driver *cpuidle_drv;
-   struct gpd_cpuidle_data *cpuidle_data;
-   struct cpuidle_state *idle_state;
-   int ret = 0;
-
-   if (IS_ERR_OR_NULL(genpd) || state < 0)
-   return -EINVAL;
-
-   genpd_acquire_lock(genpd);
-
-   if (genpd->cpuidle_data) {
-   ret = -EEXIST;
-   goto out;
-   }
-   cpuidle_data = kzalloc(sizeof(*cpuidle_data), GFP_KERNEL);
-   if (!cpuidle_data) {
-   ret = -ENOMEM;
-   goto out;
-   }
-   cpuidle_drv = cpuidle_driver_ref();
-   if (!cpuidle_drv) {
-   ret = -ENODEV;
-   goto err_drv;
-   }
-   if 

[PATCH 2/2] mmc: sdhci-pxav3: Print ret value on error from sdhci_add_host() fn

[Vaibhav Hiremath]

Return value would give clear information about the actual root-cause
of the failure.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index d02bc37..5d26fe0 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -455,7 +455,7 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
 
ret = sdhci_add_host(host);
if (ret) {
-   dev_err(>dev, "failed to add host\n");
+   dev_err(>dev, "failed to add host ret - %d\n", ret);
goto err_add_host;
}
 
-- 
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/

[PATCH 1/2] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

There were some coding style issues where spaces have been used instead
of tabs, for example, in macro definitions, alignment of function
declarations/definitions, etc...

This patch fixes all such occurrences in the code.
And also use BIT for bit definitions.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 63 ++
 1 file changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 946d37f..d02bc37 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -39,24 +39,29 @@
 #include "sdhci.h"
 #include "sdhci-pltfm.h"
 
-#define PXAV3_RPM_DELAY_MS 50
+#define PXAV3_RPM_DELAY_MS 50
 
-#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define SDCLK_DELAY_SHIFT  9
-#define SDCLK_DELAY_MASK   0x1f
+#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
+#define SDCLK_SEL  0x100
+#define  SDCLK_DELAY_SHIFT 9
+#define  SDCLK_DELAY_MASK  0x1f
 
-#define SD_CFG_FIFO_PARAM   0x100
-#define SDCFG_GEN_PAD_CLK_ON   (1<<6)
-#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
-#define SDCFG_GEN_PAD_CLK_CNT_SHIFT24
+#define SD_CFG_FIFO_PARAM  0x100
+#define  SDCFG_GEN_PAD_CLK_ON  BIT(6)
+#define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
+#define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
-#define SD_SPI_MODE  0x108
-#define SD_CE_ATA_1  0x10C
+#define SD_SPI_MODE0x108
+#define SD_CE_ATA_10x10C
 
-#define SD_CE_ATA_2  0x10E
-#define SDCE_MISC_INT  (1<<2)
-#define SDCE_MISC_INT_EN   (1<<1)
+#define SD_CE_ATA_20x10E
+#define  SDCE_MISC_INT BIT(2)
+#define  SDCE_MISC_INT_EN  BIT(1)
+
+/* IO Power control */
+#define IO_PWR_AKEY_ASFAR  0xbaba
+#define IO_PWR_AKEY_ASSAR  0xeb10
+#define IO_PWR_MMC1_PAD_1V8BIT(2)
 
 struct sdhci_pxa {
struct clk *clk_core;
@@ -128,7 +133,7 @@ static int mv_conf_mbus_windows(struct platform_device 
*pdev,
 }
 
 static int armada_38x_quirks(struct platform_device *pdev,
-struct sdhci_host *host)
+   struct sdhci_host *host)
 {
struct device_node *np = pdev->dev.of_node;
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -136,8 +141,7 @@ static int armada_38x_quirks(struct platform_device *pdev,
struct resource *res;
 
host->quirks |= SDHCI_QUIRK_MISSING_CAPS;
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "conf-sdio3");
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "conf-sdio3");
if (res) {
pxa->sdio3_conf_reg = devm_ioremap_resource(>dev, res);
if (IS_ERR(pxa->sdio3_conf_reg))
@@ -284,10 +288,10 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
 * FE-2946959
 */
if (pxa->sdio3_conf_reg) {
-   u8 reg_val  = readb(pxa->sdio3_conf_reg);
+   u8 reg_val = readb(pxa->sdio3_conf_reg);
 
if (uhs == MMC_TIMING_UHS_SDR50 ||
-   uhs == MMC_TIMING_UHS_DDR50) {
+   uhs == MMC_TIMING_UHS_DDR50) {
reg_val &= ~SDIO3_CONF_CLK_INV;
reg_val |= SDIO3_CONF_SD_FB_CLK;
} else {
@@ -304,20 +308,20 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
 }
 
 static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock = sdhci_set_clock,
-   .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
-   .get_max_clock = sdhci_pltfm_clk_get_max_clock,
-   .set_bus_width = sdhci_set_bus_width,
-   .reset = pxav3_reset,
-   .set_uhs_signaling = pxav3_set_uhs_signaling,
+   .set_clock  = sdhci_set_clock,
+   .platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
+   .get_max_clock  = sdhci_pltfm_clk_get_max_clock,
+   .set_bus_width  = sdhci_set_bus_width,
+   .reset  = pxav3_reset,
+   .set_uhs_signaling  = pxav3_set_uhs_signaling,
 };
 
 static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
-   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
+   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
| SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC
| SDHCI_QUIRK_32BIT_ADMA_SIZE
| SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
-   .ops = _sdhci_ops,
+   .ops= _sdhci_ops,
 };
 
 #ifdef CONFIG_OF
@@ -343,7 +347,7 @@ static struct sdhci_pxa_platdata 
*pxav3_get_mmc_pdata(struct device *dev)
return NULL;
 
if (!of_property_read_u32(np, 

[PATCH 0/2] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

Trivial patch-series, which fixes the tabbing issue in the driver
and second patch prints the return value from sdhci_add_host() function


Vaibhav Hiremath (2):
  mmc: sdhci-pxav3: Fix tabbing issue
  mmc: sdhci-pxav3: Print ret value on error from sdhci_add_host() fn

 drivers/mmc/host/sdhci-pxav3.c | 65 ++
 1 file changed, 34 insertions(+), 31 deletions(-)

-- 
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] genpd: cpuidle: Remove cpuidle attach

[Ulf Hansson]

On 1 September 2015 at 16:39, Daniel Lezcano  wrote:
> The power domains code allows to tie a cpuidle state with a power domain.
>
> Preventing the cpuidle framework to enter a specific idle state by disabling
> from the power domain framework is a good idea. Unfortunately, the current
> implementation has some gaps with a SMP system and a complex cpuidle
> implementation. Enabling a power domain wakes up all the cpus even if a cpu
> does not belong to the power domain.
>
> There is some work to do a logical representation with the power domains of
> the hardware dependencies (eg. a cpu belongs to a power domains, these power
> domains belong to a higher power domain for a cluster, etc ...). A new code
> relying on the genpd hierarchy to disable the idle states would make more
> sense.
>
> As the unique user of this code has been removed, let's wipe out this code
> to have a clean place to put a new implementation.
>
> Signed-off-by: Daniel Lezcano 

This is certainly a good idea, not only to pave the road for a new
implementation but also to prevent us from adding more users of the
existing API.

I would suggest a minor update of the prefix of the commit message, to
align with earlier genpd patches. Please change from "genpd: cpuidle"
to "PM / Domains:".

With that change:
Acked-by: Ulf Hansson 

Kind regards
Uffe

> ---
>  drivers/base/power/domain.c | 154 
> 
>  include/linux/pm_domain.h   |  27 
>  2 files changed, 181 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 0ee43c1..f468627 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -171,19 +171,6 @@ static void genpd_set_active(struct generic_pm_domain 
> *genpd)
> genpd->status = GPD_STATE_ACTIVE;
>  }
>
> -static void genpd_recalc_cpu_exit_latency(struct generic_pm_domain *genpd)
> -{
> -   s64 usecs64;
> -
> -   if (!genpd->cpuidle_data)
> -   return;
> -
> -   usecs64 = genpd->power_on_latency_ns;
> -   do_div(usecs64, NSEC_PER_USEC);
> -   usecs64 += genpd->cpuidle_data->saved_exit_latency;
> -   genpd->cpuidle_data->idle_state->exit_latency = usecs64;
> -}
> -
>  static int genpd_power_on(struct generic_pm_domain *genpd, bool timed)
>  {
> ktime_t time_start;
> @@ -207,7 +194,6 @@ static int genpd_power_on(struct generic_pm_domain 
> *genpd, bool timed)
>
> genpd->power_on_latency_ns = elapsed_ns;
> genpd->max_off_time_changed = true;
> -   genpd_recalc_cpu_exit_latency(genpd);
> pr_debug("%s: Power-%s latency exceeded, new value %lld ns\n",
>  genpd->name, "on", elapsed_ns);
>
> @@ -280,13 +266,6 @@ static int __pm_genpd_poweron(struct generic_pm_domain 
> *genpd)
> return 0;
> }
>
> -   if (genpd->cpuidle_data) {
> -   cpuidle_pause_and_lock();
> -   genpd->cpuidle_data->idle_state->disabled = true;
> -   cpuidle_resume_and_unlock();
> -   goto out;
> -   }
> -
> /*
>  * The list is guaranteed not to change while the loop below is being
>  * executed, unless one of the masters' .power_on() callbacks fiddles
> @@ -595,21 +574,6 @@ static int pm_genpd_poweroff(struct generic_pm_domain 
> *genpd)
> }
> }
>
> -   if (genpd->cpuidle_data) {
> -   /*
> -* If cpuidle_data is set, cpuidle should turn the domain off
> -* when the CPU in it is idle.  In that case we don't 
> decrement
> -* the subdomain counts of the master domains, so that power 
> is
> -* not removed from the current domain prematurely as a result
> -* of cutting off the masters' power.
> -*/
> -   genpd->status = GPD_STATE_POWER_OFF;
> -   cpuidle_pause_and_lock();
> -   genpd->cpuidle_data->idle_state->disabled = false;
> -   cpuidle_resume_and_unlock();
> -   goto out;
> -   }
> -
> if (genpd->power_off) {
> if (atomic_read(>sd_count) > 0) {
> ret = -EBUSY;
> @@ -1725,124 +1689,6 @@ int pm_genpd_remove_subdomain(struct 
> generic_pm_domain *genpd,
> return ret;
>  }
>
> -/**
> - * pm_genpd_attach_cpuidle - Connect the given PM domain with cpuidle.
> - * @genpd: PM domain to be connected with cpuidle.
> - * @state: cpuidle state this domain can disable/enable.
> - *
> - * Make a PM domain behave as though it contained a CPU core, that is, 
> instead
> - * of calling its power down routine it will enable the given cpuidle state 
> so
> - * that the cpuidle subsystem can power it down (if possible and desirable).
> - */
> -int pm_genpd_attach_cpuidle(struct generic_pm_domain *genpd, int state)
> -{
> -   struct 

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

[Tony Lindgren]

* Mark Brown  [150901 11:40]:
> On Tue, Sep 01, 2015 at 07:17:21AM -0700, Tony Lindgren wrote:
> 
> > Why don't you just make reg unused for pbias_regulator since
> > we already use regmap for this driver?
> 
> > Then in the pbias driver just define the register offset from
> > the syscon base? You may need to set it based on the compatible
> > value, but it's not like it's going to change for SoC.
> 
> > If we eventually add some API to calculate reg base offset
> > from the syscon base it's easy to update the driver to use
> > that.
> 
> That'd work.  The other thing I was thinking we could do is to get
> syscon to treat any excessively large address that gets passed in that
> looks like an absolute address appropriately.

Hmm wouldn't that get messy for 64-bit :) How about something
like:

unsigned long syscon_regmap_get_offset(struct regmap *syscon,
void __iomem *base)

Not sure if that's something that some drivers would start to
misuse with read/writel though.. Presumably not if the driver
already is using syscon.

Regards,

Tony
--
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/

randconfig build error with next-20150901, in drivers/media/pci/netup_unidvb/netup_unidvb_core.c

[Jim Davis]

Building with the attached random configuration file,

warning: (SND_SOC_INTEL_BYTCR_RT5640_MACH &&
SND_SOC_INTEL_CHT_BSW_RT5672_MACH && SND_SOC_INTEL_CHT_BSW_RT5645_MACH
&& SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH) selects SND_SST_IPC_ACPI
which has unmet direct dependencies (SOUND && !M68K && !UML && SND &&
SND_SOC && ACPI)

In file included from drivers/media/pci/netup_unidvb/netup_unidvb_core.c:36:0:
drivers/media/dvb-frontends/lnbh25.h:46:15: error: unknown type name
‘dvb_frontend’
 static inline dvb_frontend *lnbh25_attach(
   ^

-- 
Jim
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.2.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
# CONFIG_AUDITSYSCALL is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_NONE=y
# CONFIG_RCU_NOCB_CPU_ZERO is not set
# CONFIG_RCU_NOCB_CPU_ALL is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
# CONFIG_NUMA_BALANCING is not set
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
# CONFIG_MEMCG_KMEM is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
CONFIG_DEBUG_BLK_CGROUP=y
CONFIG_CGROUP_WRITEBACK=y
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_USER_NS=y
# CONFIG_PID_NS is not set
# 

[PATCH] scripts/kernel-doc: Processing -nofunc for functions only

[Danilo Cesar Lemes de Paula]

Docproc process EXPORT_SYMBOL(f1) macro and uses -nofunc f1 to
avoid duplicated documentation in the next call.
It works for most of the cases, but there are some specific situations
where a struct has the same name of an already-exported function.

Current kernel-doc behavior ignores those structs and do not add them
to the final documentation. This patch fixes it.

This is non-usual and the only case I've found is the drm_modeset_lock
(function and struct) defined in drm_modeset_lock.h and
drm_modeset_lock.c. Considering this, it should only affect the DRM
documentation by including struct drm_modeset_lock to the final Docbook.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Daniel Vetter 
Cc: Jonathan Corbet 
Cc: Andrew Morton 
Cc: Johannes Berg 
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 scripts/kernel-doc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 12a106c..047deb7 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1827,7 +1827,7 @@ sub output_declaration {
 my $func = "output_${functype}_$output_mode";
 if (($function_only==0) ||
( $function_only == 1 && defined($function_table{$name})) ||
-   ( $function_only == 2 && !defined($function_table{$name})))
+   ( $function_only == 2 && !($functype eq "function" && 
defined($function_table{$name}
 {
&$func(@_);
$section_counter++;
-- 
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 3/3] soc: qcom: smd: Handle big endian CPUs

[Stephen Boyd]

On 08/31, Bjorn Andersson wrote:
> On Mon 31 Aug 18:39 PDT 2015, Stephen Boyd wrote:
> 
> > The smd structures are always in little endian, but the smd
> > driver is not capable of being used on big endian CPUs. Annotate
> > the little endian data members and update the code to do the
> > proper byte swapping.
> > 
> 
> I think this looks good, but I think it would be better to reference
> the 8-bit entries of the info struct as "flags" rather than INFO8s.
> 
> Could you please change the name of the macros to
> {G,S}ET_{R,T}X_CHANNEL_FLAG() to make the code slightly easier to

Sure. I also found another missing __le32 marking on the "hdr"
stack structure. I'll test out some smd sending before resending
the patches.

-- 
Qualcomm Innovation Center, Inc. is a member of 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] arch/x86/mm/srat: Print non-volatile flag in SRAT

[Thomas Gleixner]

On Tue, 1 Sep 2015, Linda Knippers wrote:
> Nobody checks this flag but it would be interesting to know if it's being
> set on any platforms.

What you're omitting to explain, is WHY it would be interesting.

Thanks,

tglx
--
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 -next] rtc: drop unused ret variable orphaned by misc_deregister becoming void

[Alexandre Belloni]

Hi,

On 01/09/2015 at 19:37:07 +0200, Geert Uytterhoeven wrote :
> On Sat, Aug 22, 2015 at 9:26 PM, Paul Gortmaker
>  wrote:
> > In commit f368ed6088ae9c1fbe1c897bb5f215ce5e63fa1e ("char: make
> > misc_deregister a void function") this ret variable became unused
> > which now generates a compile warning.  Get rid of it.
> >
> > Cc: Alessandro Zummo 
> > Cc: Alexandre Belloni 
> > Cc: rtc-li...@googlegroups.com
> > Cc: Greg Kroah-Hartman 
> > Signed-off-by: Paul Gortmaker 
> 
> Acked-by: Geert Uytterhoeven 
> 
> It's funny how these things end up in mainline, despite at least two
> people providing a patch.
> 

The fact is that I've asked Greg to take the first fix as he is the one
carrying the offending patch. He didn't do it so I'll ensure that the
fix reaches Linus before -rc1.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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: [GIT PULL] Early batch of KVM changes for 4.3 merge window

[Paolo Bonzini]

On 01/09/2015 07:45, Xiao Guangrong wrote:
> 
> 
> Actually i triggered this warning in my another box and posted a patch
> to fix it which can be found at:
> http://lkml.iu.edu/hypermail/linux/kernel/1508.2/02771.html
> I guess Paolo is currently busy with KVM forum so the patch has not been
> reviewed yet.

Currently I'm busy with the Dolomites, actually.  I'll send a fix
together with the PPC+ARM pull request.

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] [v4] surface pro 3: Add support driver for Surface Pro 3 buttons

[Josh Boyer]

On Fri, Aug 28, 2015 at 1:56 PM, Darren Hart  wrote:
> On Wed, Aug 26, 2015 at 05:04:01AM -0700, Joe Perches wrote:
>> On Wed, 2015-08-26 at 00:22 -0700, Darren Hart wrote:
>> > On Tue, Aug 18, 2015 at 11:30:25PM +0800, Chen Yu wrote:
>> > > Since Surface Pro 3 does not follow the specs of "Windows ACPI Design
>> > > Guide for SoC Platform", code in drivers/input/misc/soc_array.c can
>> > > not detect these buttons on it. According to bios implementation,
>> > > Surface Pro 3 encapsulates these buttons in a device named "VGBI",
>> > > with _HID "MSHW0028". When any of the buttons is pressed, a specify
>> > > ACPI notification code for this button will be delivered to "VGBI". For
>> > > example, if power button is pressed down, ACPI notification code of 0xc6
>> > > will be sent by Notify(VGBI, 0xc6).
>> []
>> > Joe, you provided a lot of review, are you happy with this version?
>>
>> It looks fine.
>>
>> Thanks for picking the other little nits too Darren.
>
> This is not queued for next.

Not or now?  If not, why not?

josh
--
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] arm64: don't load 32-bit binaries if platform has no aarch32_el0

[Suzuki K. Poulose]

On 01/09/15 17:04, Mark Rutland wrote:

On Tue, Sep 01, 2015 at 03:41:12PM +0100, Yury Norov wrote:

Kernel option COMPAT defines the ability of executing aarch32 binaries.
Some platforms does not support aarch32 mode, and so cannot execute that
binaries. But we cannot just disable COMPAT for them because the same
kernel binary may be used by multiple platforms.

In this patch, system_supports_aarch32_el0() is introduced to detect
aarch32 support at run-time.

Signed-off-by: Yury Norov 
---
  arch/arm64/include/asm/cpufeature.h | 1 +
  arch/arm64/include/asm/elf.h| 6 --
  arch/arm64/kernel/cpuinfo.c | 9 +
  3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h 
b/arch/arm64/include/asm/cpufeature.h
index 20cdc26..d24ea15 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -81,6 +81,7 @@ void check_local_cpu_errata(void);
  void check_local_cpu_features(void);
  bool cpu_supports_mixed_endian_el0(void);
  bool system_supports_mixed_endian_el0(void);
+bool system_supports_aarch32_el0(void);

  #endif /* __ASSEMBLY__ */

diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index faad6df..461897b 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -21,6 +21,7 @@
  /*
   * ELF register definitions..
   */
+#include 
  #include 
  #include 

@@ -173,8 +174,9 @@ typedef compat_elf_greg_t   
compat_elf_gregset_t[COMPAT_ELF_NGREG];

  /* AArch32 EABI. */
  #define EF_ARM_EABI_MASK  0xff00
-#define compat_elf_check_arch(x)   (((x)->e_machine == EM_ARM) && \
-((x)->e_flags & EF_ARM_EABI_MASK))
+#define compat_elf_check_arch(x)   (system_supports_aarch32_el0()  \
+   && ((x)->e_machine == EM_ARM)\
+   && ((x)->e_flags & EF_ARM_EABI_MASK))

  #define compat_start_thread   compat_start_thread
  #define COMPAT_SET_PERSONALITY(ex)set_thread_flag(TIF_32BIT);
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 75d5a86..95d953f 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -79,6 +79,15 @@ bool system_supports_mixed_endian_el0(void)
return mixed_endian_el0;
  }

+#define AARCH641
+#define AARCH32_64 2


These should be better namespaced. Perhaps ID_AA64PFR0_EL1_EL0_64 and
ID_AA64PFR0_EL1_EL0_6432 ?


+bool system_supports_aarch32_el0(void)
+{
+   struct cpuinfo_arm64 *info = this_cpu_ptr(_data);
+   u64 arm64_el0 = info->reg_id_aa64pfr0 & 0xf;
+   return arm64_el0 == AARCH32_64;
+}


We should handle this the same way as we do for endianness support and
check that all CPUs support AArch32, and set a global flag, rather than
assuming that all CPUs are symmetric. Likewise for any other feature we
have to dynamically detect.


Correct. With my series, which I will post after the merge window, we should be 
able to
define this as a CPU capability and check that bit instead, which would give us 
a system
wide value.

Suzuki




Thanks,
Mark.



--
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] soc: qcom: Make qcom_smem_get() return a pointer

[Stephen Boyd]

On 08/31/2015 09:50 PM, Bjorn Andersson wrote:
> On Mon 31 Aug 18:41 PDT 2015, Stephen Boyd wrote:
>> Signed-off-by: Stephen Boyd 
>> ---
>>
>> This is on top of the smd and smem big endian support.
>>
> How sneaky of you, then we need to approve those patches before we
> add new consumers of this API...

I was being explicit to remove any subterfuge. I actually rebased this
to the end of the series, so I suspect it will apply fine without the
big endian stuff. This was mostly making a note that I tested this on
top of those commits.

-- 
Qualcomm Innovation Center, Inc. is a member of 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/

Get a safe loan within 48/hours.

I am Mr.Mathew Raymond I give out affordable loan at 2% interest rate we offer 
easy personal loans, commercial/business loan, car loan, leasing/equipment 
finance, debt consolidation loan, home loan, for all citizens and non-citizens 
with either a good or bad credit history. If you are interested in our above 
loan offer, let Mathew Raymond Financial Service assist you today… by filling 
the below information and return to us by clicking reply;

(1)Full name:
(2)Country:
(3)Contact Tel No. (Work/cell)
(4)Occupation:
(5)Amount needed as loan:
(6)Loan duration:
(7)Monthly Salary:
(8)Purpose of loan:
(9)Home Address:

Regard
Mr.Mathew Raymond
Managing Director
Mathew Raymond Financial Service.
--
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: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Tue, Sep 1, 2015 at 2:31 PM, Andy Lutomirski  wrote:
> On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  wrote:
>> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
>>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
>>> wrote:
 Hi

 On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
 wrote:
> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
> wrote:
>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
>> wrote:
>>> I haven't checked the context in which it's used, but in order for
>>> kdbus_proc_permission to do what it claims to do, it appears to be
>>> missing calls to security_inode_permission and
>>> security_file_permission.
>>
>> Both are expected to be added by lsm patches (both hooks you mentioned
>> are empty if no lsm is selected).
>
> Will that mean that existing MAC policies stop being fully enforced
> (in effect) if kdbus is installed?

 It means kdbus messages carry information about the sender, which LSMs
 might prevent you to read via /proc. Just like you can send dbus
 messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>>>
>>> It's a security-sensitive function that doesn't do what the name and
>>> description suggest.  Whether that's an active problem or not is
>>> unknown, but it's certainly a maintainability problem.
>>>
 If
 you use LSMs, we clearly advise you to wait for kdbus to gain LSM
 support. We explicitly support legacy dbus1-compat for exactly such
 reasons.
>>>
>>> This is not an acceptable attitude for security.
>>>
>>> There are so many things wrong with your statement that I'll limit
>>> myself to one of them: Fedora 23/Rawhide, which is the *reference*
>>> platform, uses SELinux.
>>
>> Clarification: Fedora Rawhide only.  The kdbus code is not included in
>> the F23 kernel.
>>
>> Your point otherwise stands.  I just don't want Phoronix or someone
>> else getting confused and thinking Fedora 23 will ship with kdbus.  It
>> will not.
>
> But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
> Granted, systemd is build with --disable-kdbus, but if it's a new
> enough version, then I think that means that the code is still there.
>
> To be clear, I don't claim to have found a specific security hole, but
> in the event that running Fedora 23 with a kdbus-supporting kernel and
> booting with kdbus=1 [1] introduces security problems, then we have a
> problem. (This isn't nearly as bad as it would be if we had problems
> just by upgrading the kernel.)  And there is certainly something wrong
> with the process if the kdbus team thinks it's okay that enabling
> kdbus can break existing security policy.

You seem to have interpreted my email as argumentation.  I don't want
to argue.  I simply want to point out that Fedora 23 will not ship
with kdbus in the kernel.  Therefore the Fedora 23 release, for its
entire supported timeframe, will not utilize kdbus.

So if someone wants to rebuild a kernel that contains the kdbus driver
and jump through the hoops you describe, then yes they might very well
run into problems you suggest might be present.  However, they will
also not be running Fedora 23 at that point.  I wish such users well
and thank them for their upstream testing efforts.

To be honest, I'm not sure what "process" you're talking about.
Kernel development is kind of rife with examples of new features
having security issues and it taking time to sort them out.  I don't
mean to cast aspersions, but user namespaces has had numerous CVEs
since it's inclusion.  I don't think anyone here has ever accused its
development of not following some kind of process.  And distros took
some time before enabling that feature, which is what I expect to
happen with kdbus should it ever be merged.  That certainly isn't an
argument for allowing _known_ security issues into the kernel, but as
you said, you haven't found a security hole as of yet.

josh
--
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 Resend 2/5] PM / OPP: Prefix exported opp routines with dev_pm_opp_

[Pavel Machek]

Hi!

> -EXPORT_SYMBOL_GPL(of_cpumask_init_opp_table);
> +EXPORT_SYMBOL_GPL(dev_pm_opp_cpumask_init_opp);

Well... it starts to be rather long and repetitive.

> @@ -237,7 +237,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
>*
>* OPPs might be populated at runtime, don't check for error here
>*/
> - of_cpumask_init_opp_table(policy->cpus);
> + dev_pm_opp_cpumask_init_opp(policy->cpus);
>  
>   if (need_update) {
>   struct cpufreq_dt_platform_data *pd = cpufreq_get_driver_data();
...
> @@ -356,7 +356,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
>  out_free_priv:
>   kfree(priv);
>  out_free_opp:
> - of_cpumask_free_opp_table(policy->cpus);
> + dev_pm_opp_cpumask_free_table(policy->cpus);
>  out_node_put:
>   of_node_put(np);
>  out_put_reg_clk:

Is ..._free_table opposite of ..._init_opp? If so, you might want to
name them such that it is clear...

Thanks,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] perf, tools: Always use non inlined file name for srcfile

[Arnaldo Carvalho de Melo]

Em Tue, Sep 01, 2015 at 11:48:39AM -0700, Andi Kleen escreveu:
> On Tue, Sep 01, 2015 at 03:36:57PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Sep 01, 2015 at 11:11:42AM -0700, Andi Kleen escreveu:
> > > From: Andi Kleen 
> > > 
> > > When profiling the kernel with srcfile it's common to "get
> > > stuck" in include. For example a lot of code uses current
> > > or other inlines, so they get accounted to some random
> > > include file. This is not very useful as a high level
> > > categorization.
> > 
> > Cool idea :-)
> 
> Yes.
> 
> It would be also nice to use this information for unwinding
> (so to show the inline stack as part of the call graph)

Yes, agreed.

> > Why not the so much simpler:
> > 
> > while (bfd_find_inliner_info(...));
> > 
> > But other than that, wouldn't be better to put an upper limit on this?
> > 
> > Say, 1024 levels of unwinding to avoid tripping in some bfd lib bug that
> > could make this function always return true and make addr2line get stuck
> > in an infinite loop?
> 
> Done. I sent a v2.

Thanks, I applied v2.

- Arnaldo
--
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 21/31] perf tools: Move linux/filter.h to tools/include

[Arnaldo Carvalho de Melo]

Em Sat, Aug 29, 2015 at 04:21:55AM +, Wang Nan escreveu:
> From: He Kuang 
> 
> This patch moves filter.h from include/linux/kernel.h to

I said that before: this is not moving anything, it is copying :-)

> tools/include/linux/filter.h to enable other libraries use macros in
> it, like libbpf which will be introduced by further patches. Currenty,
> the moved filter.h only contains the useful macros needed by libbpf
> for not introducing too much dependence.
> 
> MANIFEST is also updated for 'make perf-*-src-pkg'.

So, I did a:

$ diff -u include/linux/filter.h tools/include/linux/filter.h

And noticed these:

-/* Endianess conversion, cpu_to_{l,b}e(), {l,b}e_to_cpu() */
+/* Endianness conversion, cpu_to_{l,b}e(), {l,b}e_to_cpu() */

-/* Short form of mov based on type, BPF_X: dst_reg = src_reg, BPF_K: dst_reg = 
imm32 */
+/* Short form of mov based on type,
+ * BPF_X: dst_reg = src_reg, BPF_K: dst_reg = imm32
+ */

-/* Conditional jumps against registers, if (dst_reg 'op' src_reg) goto pc + 
off16 */
+/* Conditional jumps against registers,
+ * if (dst_reg 'op' src_reg) goto pc + off16
+ */

-/* Conditional jumps against immediates, if (dst_reg 'op' imm32) goto pc + 
off16 */
+/* Conditional jumps against immediates,
+ * if (dst_reg 'op' imm32) goto pc + off16
+ */

--

Please refrain from doing that... I.e. spell checking is kinda useful,
introducing gratuitous further drift from include/linux/FOO.h to
tools/include/linux/FOO.h is not.

So either resist the urge to do these stylistic changes or do those changes in
include/linux/FOO.h and _then_ copy it to tools/include/linux/FOO.h.

If the copy was already done, fix both, so that when we do that diff again, we
can see what is really different in kernel and userspace copies and that maybe
will help us spot things that aren't diverging over time.

- Arnaldo
--
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: [GIT PULL] Ext3 removal, quota & udf fixes

[Austin S Hemmelgarn]

On 2015-09-01 06:29, Albino B Neto wrote:

2015-08-31 19:31 GMT-03:00 Raymond Jennings :

I think also that we should remove the ext2 driver before we remove the ext3
driver.


Yes. It is logical to remove the old ext2 drive, because there are
more computers with ext3 that ext2. Ext2 is obsolete by existing
technologies.

NO, it is not logical.  A vast majority of Android smartphones in the 
wild use ext2, as do a very significant portion of embedded systems that 
don't have room for the few hundred kilobytes of extra code that the 
ext4 driver has in comparison to ext2.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 1/3] soc: qcom: smd: Represent channel layout in structures

[Stephen Boyd]

On 08/31/2015 09:55 PM, Bjorn Andersson wrote:
> On Mon 31 Aug 18:39 PDT 2015, Stephen Boyd wrote:
>
>> The rx and tx channel info are laid out in memory next to each
>> other, and there are two types of channel info structures, byte
>> based and word based. We have 4 pointers to these info
>> structures, when we really only need two to point to the
>> different types of structures. Encapsulate the byte based and word
>> based tx/rx structures in a "full channel" structure that
>> describes the layout of memory and reduces the number of pointers
>> in the smd channel structure by two.
>>
> Saving the extra pointer doesn't feel like worth the change, but
> representing the pair of info structs as one sounds like a reasonable
> cleanup.

Agreed.

>
> Reviewed-by: Bjorn Andersson 
>> Signed-off-by: Stephen Boyd 
>> ---
>>  drivers/soc/qcom/smd.c | 61 
>> +++---
>>  1 file changed, 33 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
>> index edd9d9a37238..c16547b85e05 100644
>> --- a/drivers/soc/qcom/smd.c
>> +++ b/drivers/soc/qcom/smd.c
>> @@ -65,7 +65,9 @@
>>   */
>>  
>>  struct smd_channel_info;
>> +struct smd_full_channel_info;
> I would have called this "smd_channel_info_pair"...

Sure I'll make the change and add your Reviewed-by.

-- 
Qualcomm Innovation Center, Inc. is a member of 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: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[pinskia]

> On Sep 2, 2015, at 1:30 AM, Mark Rutland  wrote:
> 
> [...]
> 
> On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
> It is useful to pass down MIDR register down to userland if all of
> the online cores are all the same type.  This adds AT_ARM64_MIDR
> aux vector type and passes down the midr system register.
> 
> This is alternative to MIDR_EL1 part of
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
> It allows for faster access to midr_el1 than going through a trap and
> does not exist if the set of cores are not the same.
 
 I'm not sure I follow the rationale. If speed is important the
 application can cache the value the first time it reads it with a trap.
>>> 
>>> It is also about compatibility also. Exposing the register is not backwards 
>>> compatible but using the aux vector is.
>> 
>> That would also break big.little too. So either break it with hot plug or 
>> break it in userland, your choice.
> 
> The value wouldn't be representative of the system as a whole; that is
> true. However, we never guaranteed that it was, while the aux vector
> code implied that we did.

Yes but I guess you talk about caching the value in userspace but doing it via 
the aux vector is the same as your suggestion. Just one difference is you don't 
get the aux vector entry if there is a CPU that is online which is different. 
No difference from your suggestion of caching it. Without considering hot pug 
for a second (that is a huge different issue all together), if userland wants 
to know if all up CPUs have the same midr, they would either read /sys entries 
(lots of syscalls) or bind to each CPU and do the trap. That means at least 
three or two syscalls/traps for each CPU. My way is none and gets a value of 
midr if they are all the Same for free. 

Again what is the difference between the aux vector and caching the value in 
userspace? Because it seems like you suggesting I do that but then avoiding 
big.little also. 

Thanks,
Andrew

> 
> For optimisation that may be good enough; code optimized for a different
> uArch should still function on another, even if it is slower.
> 
 This also means that the behaviour is different across homogeneous and
 heterogeneous systems.
>> 
>> That should be ok because it is still backwards compatible with what
>> was done before.  My goal here is just to allow quick easy access to
>> midr in the case of a homogeneous system which I care about, thunderx
>> and to allow glibc to select a memcpy/memset that is better for
>> thunderx.
> 
> As I mentioned in the other thread, I think that HWCAP_CPUID is
> sufficient to enable forwards and backwards compatibility. If it is
> present then you can use the current CPU's MIDR to select a better
> memcpy/memset if required.
> 
> Thanks,
> Mark.
--
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] arm64: don't load 32-bit binaries if platform has no aarch32_el0

[Yury]

On Tue, Sep 01, 2015 at 05:04:26PM +0100, Mark Rutland wrote:
> On Tue, Sep 01, 2015 at 03:41:12PM +0100, Yury Norov wrote:
> > Kernel option COMPAT defines the ability of executing aarch32 binaries.
> > Some platforms does not support aarch32 mode, and so cannot execute that
> > binaries. But we cannot just disable COMPAT for them because the same
> > kernel binary may be used by multiple platforms.
> > 
> > In this patch, system_supports_aarch32_el0() is introduced to detect
> > aarch32 support at run-time.
> > 
> > Signed-off-by: Yury Norov 
> > ---
> >  arch/arm64/include/asm/cpufeature.h | 1 +
> >  arch/arm64/include/asm/elf.h| 6 --
> >  arch/arm64/kernel/cpuinfo.c | 9 +
> >  3 files changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/cpufeature.h 
> > b/arch/arm64/include/asm/cpufeature.h
> > index 20cdc26..d24ea15 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -81,6 +81,7 @@ void check_local_cpu_errata(void);
> >  void check_local_cpu_features(void);
> >  bool cpu_supports_mixed_endian_el0(void);
> >  bool system_supports_mixed_endian_el0(void);
> > +bool system_supports_aarch32_el0(void);
> >  
> >  #endif /* __ASSEMBLY__ */
> >  
> > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > index faad6df..461897b 100644
> > --- a/arch/arm64/include/asm/elf.h
> > +++ b/arch/arm64/include/asm/elf.h
> > @@ -21,6 +21,7 @@
> >  /*
> >   * ELF register definitions..
> >   */
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -173,8 +174,9 @@ typedef compat_elf_greg_t   
> > compat_elf_gregset_t[COMPAT_ELF_NGREG];
> >  
> >  /* AArch32 EABI. */
> >  #define EF_ARM_EABI_MASK   0xff00
> > -#define compat_elf_check_arch(x)   (((x)->e_machine == EM_ARM) && \
> > -((x)->e_flags & EF_ARM_EABI_MASK))
> > +#define compat_elf_check_arch(x)   (system_supports_aarch32_el0()  \
> > +   && ((x)->e_machine == EM_ARM)   \
> > +   && ((x)->e_flags & EF_ARM_EABI_MASK))
> >  
> >  #define compat_start_threadcompat_start_thread
> >  #define COMPAT_SET_PERSONALITY(ex) set_thread_flag(TIF_32BIT);
> > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> > index 75d5a86..95d953f 100644
> > --- a/arch/arm64/kernel/cpuinfo.c
> > +++ b/arch/arm64/kernel/cpuinfo.c
> > @@ -79,6 +79,15 @@ bool system_supports_mixed_endian_el0(void)
> > return mixed_endian_el0;
> >  }
> >  
> > +#define AARCH641
> > +#define AARCH32_64 2
> 
> These should be better namespaced. Perhaps ID_AA64PFR0_EL1_EL0_64 and
> ID_AA64PFR0_EL1_EL0_6432 ?
> 
> > +bool system_supports_aarch32_el0(void)
> > +{
> > +   struct cpuinfo_arm64 *info = this_cpu_ptr(_data);
> > +   u64 arm64_el0 = info->reg_id_aa64pfr0 & 0xf;
> > +   return arm64_el0 == AARCH32_64;
> > +}
> 
> We should handle this the same way as we do for endianness support and
> check that all CPUs support AArch32, and set a global flag, rather than
> assuming that all CPUs are symmetric. Likewise for any other feature we
> have to dynamically detect.
> 

OK. Will do in V2

> Thanks,
> Mark.
--
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] scripts/kernel-doc: Improve Markdown results

[Danilo Cesar Lemes de Paula]

On 08/21/2015 04:39 PM, Danilo Cesar Lemes de Paula wrote:
> Using pandoc as the Markdown engine cause some minor side effects as
> pandoc includes  main  tags for almost everything.
> Original Markdown support approach removes those main tags, but it caused
> some inconsistencies when that tag is not the main one, like:
> ..
> ...
> 
> As kernel-doc was already including a  tag, it causes the presence
> of double  tags (), which is not supported by DocBook
> spec.
> 
> Html target gets away with it, so it causes no harm, although other
> targets might not be so lucky (pdf as example).
> 
> We're now delegating the inclusion of the main  tag to pandoc
> only, as it knows when it's necessary or not.
> 
> That behavior causes a corner case, the only situation where we're
> certainly that  is not needed, which is the  content.
> For those cases, we're using a $output_markdown_nopara = 1 control var.
> 
> Signed-off-by: Danilo Cesar Lemes de Paula 
> Cc: Randy Dunlap 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Jonathan Corbet 
> Cc: Herbert Xu 
> Cc: Stephan Mueller 
> Cc: Michal Marek 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: intel-gfx 
> Cc: dri-devel 
> Cc: Graham Whaley 
> ---
>  Thanks to Graham Whaley who helped me to debug this.
> 
>  scripts/kernel-doc | 48 ++--
>  1 file changed, 34 insertions(+), 14 deletions(-)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 3850c1e..12a106c 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -288,6 +288,7 @@ my $use_markdown = 0;
>  my $verbose = 0;
>  my $output_mode = "man";
>  my $output_preformatted = 0;
> +my $output_markdown_nopara = 0;
>  my $no_doc_sections = 0;
>  my @highlights = @highlights_man;
>  my $blankline = $blankline_man;
> @@ -529,8 +530,11 @@ sub markdown_to_docbook {
>   close(CHLD_OUT);
>   close(CHLD_ERR);
>  
> - # pandoc insists in adding Main , we should remove them.
> - $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
> + if ($output_markdown_nopara) {
> + # pandoc insists in adding Main , sometimes we
> + # want to remove them.
> + $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
> + }
>  
>   return $content;
>  }
> @@ -605,7 +609,7 @@ sub output_highlight {
>   $line =~ s/^\s*//;
>   }
>   if ($line eq ""){
> - if (! $output_preformatted) {
> + if (! $output_preformatted && ! $use_markdown) {
>   print $lineprefix, local_unescape($blankline);
>   }
>   } else {
> @@ -1026,7 +1030,7 @@ sub output_section_xml(%) {
>   # programlisting is already included by pandoc
>   print "\n" unless $use_markdown;
>   $output_preformatted = 1;
> - } else {
> + } elsif (! $use_markdown) {
>   print "\n";
>   }
>   output_highlight($args{'sections'}{$section});
> @@ -1034,7 +1038,7 @@ sub output_section_xml(%) {
>   if ($section =~ m/EXAMPLE/i) {
>   print "\n" unless $use_markdown;
>   print "\n";
> - } else {
> + } elsif (! $use_markdown) {
>   print "\n";
>   }
>   print "\n";
> @@ -1066,7 +1070,9 @@ sub output_function_xml(%) {
>  print " " . $args{'function'} . "\n";
>  print " \n";
>  print "  ";
> +$output_markdown_nopara = 1;
>  output_highlight ($args{'purpose'});
> +$output_markdown_nopara = 0;
>  print " \n";
>  print "\n";
>  
> @@ -1104,10 +1110,12 @@ sub output_function_xml(%) {
>   $parameter_name =~ s/\[.*//;
>  
>   print "  \n   
> $parameter\n";
> - print "   \n\n";
> + print "   \n";
> + print "\n" unless $use_markdown;
>   $lineprefix=" ";
>   output_highlight($args{'parameterdescs'}{$parameter_name});
> - print "\n   \n  \n";
> + print "\n" unless $use_markdown;
> + print "   \n  \n";
>   }
>   print " \n";
>  } else {
> @@ -1143,7 +1151,9 @@ sub output_struct_xml(%) {
>  print " " . $args{'type'} . " " . $args{'struct'} . 
> "\n";
>  print " \n";
>  print "  ";
> +$output_markdown_nopara = 1;
>  output_highlight ($args{'purpose'});
> +$output_markdown_nopara = 0;
>  print " \n";
>  print "\n";
>  
> @@ -1196,9 +1206,11 @@ sub output_struct_xml(%) {
>($args{'parameterdescs'}{$parameter_name} ne $undescribed) || next;
>print "";
>print "  $parameter\n";
> -  print "  \n";
> +  print "  \n";
> +  print " \n" unless $use_markdown;
>output_highlight($args{'parameterdescs'}{$parameter_name});
> - 

Re: [PATCH 2/3] selftests: add membarrier syscall test

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 10:11 AM, Mathieu Desnoyers
 wrote:
> - On Aug 31, 2015, at 2:54 AM, Michael Ellerman m...@ellerman.id.au wrote:
>
>> On Fri, 2015-07-10 at 16:58 -0400, Mathieu Desnoyers wrote:
>>> From: Pranith Kumar 
>>>
>>> This patch adds a self test for the membarrier system call.
>>>
>>> CC: Michael Ellerman 
>>
>> Sorry I only just saw this due to some over zealous filtering on my end.
>>
>>
>>> diff --git a/tools/testing/selftests/membarrier/Makefile
>>> b/tools/testing/selftests/membarrier/Makefile
>>> new file mode 100644
>>> index 000..877a503
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/membarrier/Makefile
>>> @@ -0,0 +1,11 @@
>>> +CFLAGS += -g -I../../../../usr/include/
>>> +
>>> +all:
>>> +$(CC) $(CFLAGS) membarrier_test.c -o membarrier_test
>>>
>>> +TEST_PROGS := membarrier_test
>>
>> You don't need to specify the rule, the implict one will do exactly the same,
>> so you can just do:
>>
>> TEST_PROGS := membarrier_test
>>
>> all: $(TEST_PROGS)
>>
>>> diff --git a/tools/testing/selftests/membarrier/membarrier_test.c
>>> b/tools/testing/selftests/membarrier/membarrier_test.c
>>> new file mode 100644
>>> index 000..3c9f217
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/membarrier/membarrier_test.c
>>> @@ -0,0 +1,71 @@
>>> +#define _GNU_SOURCE
>>> +#define __EXPORTED_HEADERS__
>>
>> Why are you exporting that?
>>
>> I suspect to try and get around the "Attempt to use kernel headers from user
>> space" warning.
>>
>> But you're correctly building against the installed headers, not the kernel
>> headers, so you don't need to do that.
>
> Just to make sure I understand: should we expect that
> everyone will issue "make headers_install" on their system
> before doing a make kselftest ?
>
> I see that a few selftests (e.g. memfd) are adding the
> source tree include paths to the compiler include paths,
> which I guess is to ensure that the kselftest will
> work even if the system headers are not up to date.

It would be really nice if there were a clean way for selftests to
include the kernel headers.  Perhaps make should build the exportable
headers somewhere as a dependency of kselftests.

--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/

Re: [PATCH] Regulator: Suppress compiler warnings

[Keith Busch]

On Tue, 1 Sep 2015, Mark Brown wrote:

On Tue, Sep 01, 2015 at 09:52:13AM +0900, Krzysztof Kozlowski wrote:

2015-09-01 1:41 GMT+09:00 Keith Busch :

 int regulator_is_enabled_regmap(struct regulator_dev *rdev)
 {
-   unsigned int val;
+   unsigned int uninitialized_var(val);
int ret;

ret = regmap_read(rdev->regmap, rdev->desc->enable_reg, );



This is quite common pattern so such work-around should be added to
many other functions leading to code obfuscation. Which compiler do
you have in mind?


Right, plus this will shut up valid compiler warnings which is poor
practice anyway.  I'd say this is a bug in the compiler.


Using gcc 4.7.2 with '-Os'. The warning does not happen when that option
is not used, i.e. disable CONFIG_CC_OPTIMIZE_FOR_SIZE.

I will certainly try other gcc versions with the same config and see
what happens.
--
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] perf, tools: Always use non inlined file name for srcfile

[Andi Kleen]

From: Andi Kleen 

When profiling the kernel with srcfile it's common to "get
stuck" in include. For example a lot of code uses current
or other inlines, so they get accounted to some random
include file. This is not very useful as a high level
categorization.

For example just profiling the idle loop usually shows
mostly inlines, so you never see the actual cpuidle file.

This patch changes srcfile to always unwind the inline
stack using BFD/dwarf. So we always account to the base
function that called the inline.

In a few cases include is still shown (for example for MSR
accesses), but that is because they get inlining expanded as part
of assigning to a global function pointer. For the majority
it works fine though.

v2: Use simpler while loop. Add maximum iteration count.
Signed-off-by: Andi Kleen 
---
 tools/perf/util/sort.c|  4 ++--
 tools/perf/util/srcline.c | 29 -
 tools/perf/util/util.h|  2 ++
 3 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 7e38716..a97bcee 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -328,8 +328,8 @@ static char *get_srcfile(struct hist_entry *e)
char *sf, *p;
struct map *map = e->ms.map;
 
-   sf = get_srcline(map->dso, map__rip_2objdump(map, e->ip),
-e->ms.sym, true);
+   sf = __get_srcline(map->dso, map__rip_2objdump(map, e->ip),
+e->ms.sym, false, true);
if (!strcmp(sf, SRCLINE_UNKNOWN))
return no_srcfile;
p = strchr(sf, ':');
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index fc08248..c36bab6 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -149,8 +149,11 @@ static void addr2line_cleanup(struct a2l_data *a2l)
free(a2l);
 }
 
+#define MAX_INLINE_NEST 1024
+
 static int addr2line(const char *dso_name, u64 addr,
-char **file, unsigned int *line, struct dso *dso)
+char **file, unsigned int *line, struct dso *dso,
+bool unwind_inlines)
 {
int ret = 0;
struct a2l_data *a2l = dso->a2l;
@@ -170,6 +173,15 @@ static int addr2line(const char *dso_name, u64 addr,
 
bfd_map_over_sections(a2l->abfd, find_address_in_section, a2l);
 
+   if (a2l->found && unwind_inlines) {
+   int cnt = 0;
+
+   while (bfd_find_inliner_info(a2l->abfd, >filename,
+ >funcname, 
>line)
+   && cnt++ < MAX_INLINE_NEST)
+   ;
+   }
+
if (a2l->found && a2l->filename) {
*file = strdup(a2l->filename);
*line = a2l->line;
@@ -197,7 +209,8 @@ void dso__free_a2l(struct dso *dso)
 
 static int addr2line(const char *dso_name, u64 addr,
 char **file, unsigned int *line_nr,
-struct dso *dso __maybe_unused)
+struct dso *dso __maybe_unused,
+bool unwind_inlines __maybe_unused)
 {
FILE *fp;
char cmd[PATH_MAX];
@@ -254,8 +267,8 @@ void dso__free_a2l(struct dso *dso __maybe_unused)
  */
 #define A2L_FAIL_LIMIT 123
 
-char *get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
- bool show_sym)
+char *__get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
+ bool show_sym, bool unwind_inlines)
 {
char *file = NULL;
unsigned line = 0;
@@ -276,7 +289,7 @@ char *get_srcline(struct dso *dso, u64 addr, struct symbol 
*sym,
if (!strncmp(dso_name, "/tmp/perf-", 10))
goto out;
 
-   if (!addr2line(dso_name, addr, , , dso))
+   if (!addr2line(dso_name, addr, , , dso, unwind_inlines))
goto out;
 
if (asprintf(, "%s:%u",
@@ -310,3 +323,9 @@ void free_srcline(char *srcline)
if (srcline && strcmp(srcline, SRCLINE_UNKNOWN) != 0)
free(srcline);
 }
+
+char *get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
+ bool show_sym)
+{
+   return __get_srcline(dso, addr, sym, show_sym, false);
+}
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 291be1d..09c1a8b 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -321,6 +321,8 @@ struct symbol;
 extern bool srcline_full_filename;
 char *get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
  bool show_sym);
+char *__get_srcline(struct dso *dso, u64 addr, struct symbol *sym,
+ bool show_sym, bool unwind_inlines);
 void free_srcline(char *srcline);
 
 int filename__read_str(const char *filename, char **buf, size_t *sizep);
-- 
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  

Re: Potential data race in psmouse_interrupt

[Dmitry Vyukov]

On Fri, Aug 28, 2015 at 8:32 PM, Dmitry Torokhov
 wrote:
> On Fri, Aug 28, 2015 at 11:08 AM, Dmitry Vyukov  wrote:
>> On Fri, Aug 28, 2015 at 7:51 PM, Dmitry Torokhov
>>  wrote:
>>> On Fri, Aug 28, 2015 at 10:34 AM, Dmitry Vyukov  wrote:
 Hello,

 I am looking at this code in __ps2_command again:

 /*
 * The reset command takes a long time to execute.
 */
 timeout = msecs_to_jiffies(command == PS2_CMD_RESET_BAT ? 4000 : 500);

 timeout = wait_event_timeout(ps2dev->wait,
 !(READ_ONCE(ps2dev->flags) & PS2_FLAG_CMD1), timeout);

 if (smp_load_acquire(>cmdcnt) &&
 !(smp_load_acquire(>flags) & PS2_FLAG_CMD1)) {
   timeout = ps2_adjust_timeout(ps2dev, command, timeout);
   wait_event_timeout(ps2dev->wait,
 !(smp_load_acquire(>flags) &
 PS2_FLAG_CMD), timeout);
 }

 if (param)
 for (i = 0; i < receive; i++)
   param[i] = ps2dev->cmdbuf[(receive - 1) - i];


 Here are two moments I don't understand:
 1. The last parameter of ps2_adjust_timeout is timeout in jiffies (it
 is compared against 100ms). However, timeout is assigned to result of
 wait_event_timeout, which returns 0 or 1. This does not make sense to
 me. What am I missing?
>>>
>>> The fact that wait_event_timeout can return value greater than one:
>>>
>>>  * Returns:
>>>  * 0 if the @condition evaluated to %false after the @timeout elapsed,
>>>  * 1 if the @condition evaluated to %true after the @timeout elapsed,
>>>  * or the remaining jiffies (at least 1) if the @condition evaluated
>>>   ^
>>
>>
>> OK, makes sense now!
>>
 2. This code pays great attention to timeouts, but in the end I don't
 see how it handles timeouts. That is, if a timeout is happened, we
 still copyout (garbage) from cmdbuf. What am I missing here?
>>>
>>> Once upon a time wait_event() did not return positive value when
>>> timeout expired and then condition satisfied. So we just examine the
>>> final state (psmpouse->cmdcnt should be 0 if command actually
>>> succeeded) and even if we copy in garbage nobody should care since
>>> we'll return error in this case.
>>
>>
>> I see.
>> But the cmdcnt is re-read after copying out response. So it is
>> possible that we read garbage response, but then read cmdcnt==0 and
>> return OK to caller.
>
> That assumes that we actually timed out, and while we were copying the
> data the response finally came.

Right.

>>
>> So far I have something along the following lines to fix data races in 
>> libps2.c
>
> I don't know, maybe we should simply move call to
> serio_pause_rx(ps2dev->serio) higher, before we check ps2dev->cmdcnt,
> and move copying of the buffer down, after checking cmdcnt.

I don't know about serio_pause_rx, but copying of response should be
done after checking cmdcnt.
Also you need to use smp_store_release/smp_load_acquire cmdcnt and
flags when they have dependent data. And READ_ONCE/WRITE_ONCE on
shared state otherwise is highly desirable.

>> diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
>> index 7551699..51c747f 100644
>> --- a/drivers/input/serio/libps2.c
>> +++ b/drivers/input/serio/libps2.c
>> @@ -43,7 +43,7 @@ int ps2_sendbyte(struct ps2dev *ps2dev, unsigned
>> char byte, int timeout)
>>
>>  if (serio_write(ps2dev->serio, byte) == 0)
>>  wait_event_timeout(ps2dev->wait,
>> -   !(ps2dev->flags & PS2_FLAG_ACK),
>> +   !(READ_ONCE(ps2dev->flags) & 
>> PS2_FLAG_ACK),
>> msecs_to_jiffies(timeout));
>>
>>  serio_pause_rx(ps2dev->serio);
>> @@ -187,6 +187,7 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned
>> char *param, int command)
>>  int receive = (command >> 8) & 0xf;
>>  int rc = -1;
>>  int i;
>> +unsigned char cmdcnt;
>>
>>  if (receive > sizeof(ps2dev->cmdbuf)) {
>>  WARN_ON(1);
>> @@ -225,23 +226,22 @@ int __ps2_command(struct ps2dev *ps2dev,
>> unsigned char *param, int command)
>>  timeout = msecs_to_jiffies(command == PS2_CMD_RESET_BAT ? 4000 : 
>> 500);
>>
>>  timeout = wait_event_timeout(ps2dev->wait,
>> - !(ps2dev->flags &
>> PS2_FLAG_CMD1), timeout);
>> -
>> -if (ps2dev->cmdcnt && !(ps2dev->flags & PS2_FLAG_CMD1)) {
>> +!(READ_ONCE(ps2dev->flags) & PS2_FLAG_CMD1), timeout);
>>
>> +if (READ_ONCE(>cmdcnt) &&
>> +!(READ_ONCE(>flags) & PS2_FLAG_CMD1)) {
>>  timeout = ps2_adjust_timeout(ps2dev, command, timeout);
>>  wait_event_timeout(ps2dev->wait,
>> -   !(ps2dev->flags & PS2_FLAG_CMD), 
>> timeout);
>> 

Re: futex atomic vs ordering constraints

[Thomas Gleixner]

On Tue, 1 Sep 2015, Peter Zijlstra wrote:
> On Tue, Sep 01, 2015 at 05:31:40PM +0100, Will Deacon wrote:
> > Hi Peter,
> > 
> > On Wed, Aug 26, 2015 at 07:16:59PM +0100, Peter Zijlstra wrote:
> > > I tried to keep this email short, but failed miserably at this. For
> > > the TL;DR skip to the tail.
> > 
> > [...]
> > 
> > > There are a few options:
> > > 
> > >  1) punt, mandate they're both fully ordered and stop thinking about it
> > > 
> > >  2) make them both fully relaxed, rely on implied barriers and employ
> > > smp_mb__{before,after}_atomic in key places
> > > 
> > > Given the current state of things and that I don't really think there is
> > > a compelling performance argument to be made for 2, I would suggest we
> > > go with 1.
> > 
> > I'd also go for (1). Since there is a userspace side to this, I'd *really*
> > like to avoid a potential situation on arm64 where the kernel builds its
> > side of the futex using barrier instructions (e.g. treat LDR + smp_mb()
> > as acquire) and userspace builds its side out of native acquire/release
> > instructions and the two end up interacting badly (for example, loss of
> > SC).
> 
> I thought your native acquire/release were RCsc, or is it that in
> combination with the 'fancy' 'full' barrier of stlxr + dmb-ish something
> goes sideways?
> 
> But yes, unless Thomas has other plans, I'll go ahead and create some
> patches to make sure everybody is fully ordered so we can forget about
> it again.

No, I don't. There are too many ways to screw that up, so unless
someone has a serious performance issue, we should keep it on the safe
side.

Thanks,

tglx

--
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] arch/x86/mm/srat: Print non-volatile flag in SRAT

[Linda Knippers]

On 9/1/2015 3:17 PM, Thomas Gleixner wrote:
> On Tue, 1 Sep 2015, Linda Knippers wrote:
>> Nobody checks this flag but it would be interesting to know if it's being
>> set on any platforms.
> 
> What you're omitting to explain, is WHY it would be interesting.

With the addition of NVDIMM support, a question came up as to whether
NVDIMM ranges should be in the SRAT with this bit set.  I think the
consensus was no because the ranges are in the NFIT with proximity
domain information there.

ACPI is not clear on the meaning of this bit in the SRAT.
If someone is setting it, we might want to ask them what they expect
to happen with it.

Right now this bit is only printed if all the ACPI debug information is
turned on.

Sorry, I should have explained more.

-- ljk

> 
> Thanks,
> 
>   tglx
> 

--
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/

[RFC 1/3] mmc: sdhci: pass signal_voltage as an argument to voltage_switch callback

[Vaibhav Hiremath]

In order to do particular voltage specific configuration in
sdhci_ops->voltage_switch() callback function, we need to
pass respective voltage value as well.
So this patch adds an extra argument for signal voltage to the
callback function.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Kevin Liu 
---
 drivers/mmc/host/sdhci.c | 2 +-
 drivers/mmc/host/sdhci.h | 2 +-
 drivers/mmc/host/sdhci_f_sdh30.c | 3 ++-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1dbe932..3dd295f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1782,7 +1782,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
/* Some controller need to do more when switching */
if (host->ops->voltage_switch)
-   host->ops->voltage_switch(host);
+   host->ops->voltage_switch(host, MMC_SIGNAL_VOLTAGE_180);
 
/* 1.8V regulator output should be stable within 5 ms */
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 5521d29..9b0e2a8 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -537,7 +537,7 @@ struct sdhci_ops {
void(*adma_workaround)(struct sdhci_host *host, u32 intmask);
void(*platform_init)(struct sdhci_host *host);
void(*card_event)(struct sdhci_host *host);
-   void(*voltage_switch)(struct sdhci_host *host);
+   void(*voltage_switch)(struct sdhci_host *host, u8 signal_voltage);
int (*select_drive_strength)(struct sdhci_host *host,
 struct mmc_card *card,
 unsigned int max_dtr, int host_drv,
diff --git a/drivers/mmc/host/sdhci_f_sdh30.c b/drivers/mmc/host/sdhci_f_sdh30.c
index 983b8b3..7ab1c20 100644
--- a/drivers/mmc/host/sdhci_f_sdh30.c
+++ b/drivers/mmc/host/sdhci_f_sdh30.c
@@ -49,7 +49,8 @@ struct f_sdhost_priv {
struct device *dev;
 };
 
-static void sdhci_f_sdh30_soft_voltage_switch(struct sdhci_host *host)
+static void sdhci_f_sdh30_soft_voltage_switch(struct sdhci_host *host,
+   u8 signal_voltage)
 {
struct f_sdhost_priv *priv = sdhci_priv(host);
u32 ctrl = 0;
-- 
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/

[RFC 3/3] mmc: sdhci-pxav3: Add ->voltage_switch callback support

[Vaibhav Hiremath]

In case PXA1928 family of devices, there is device/controller specific
configuration to control voltage/power on the IO pins.

This patch implements and enables the sdhci_ops->voltage_switch()
callback api.
Note that IO pad register addresses are fetched as a memory resource.

For example, in case of PXA1928 and family of devices, the DT property
would look something like,

sdh1: sdh@d428 {
compatible = "mrvl,pxav3-mmc";
reg-names = "sdhci", "io-pwr", "io-pwr-lock-unlock";
reg = <0xd428 0x120>,
<0xd401e81c 4>,
<0xd4015068 8>;
...
};

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 59 ++
 1 file changed, 59 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 5d26fe0..cebb2f9 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -63,11 +63,18 @@
 #define IO_PWR_AKEY_ASSAR  0xeb10
 #define IO_PWR_MMC1_PAD_1V8BIT(2)
 
+/* IO Power control */
+#define IO_PWR_AKEY_ASFAR  0xbaba
+#define IO_PWR_AKEY_ASSAR  0xeb10
+#define IO_PWR_MMC1_PAD_1V8BIT(2)
+
 struct sdhci_pxa {
struct clk *clk_core;
struct clk *clk_io;
u8  power_mode;
void __iomem *sdio3_conf_reg;
+   void __iomem *io_pwr_reg;
+   void __iomem *io_pwr_lock_reg;
 };
 
 /*
@@ -307,6 +314,38 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
__func__, uhs, ctrl_2);
 }
 
+static void pxav3_voltage_switch(struct sdhci_host *host,
+   u8 signal_voltage)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   unsigned int val;
+
+   if (!pxa->io_pwr_reg || !pxa->io_pwr_lock_reg)
+   return;
+
+   /* Lock register is 64 bit: First & Second access register */
+   writel(IO_PWR_AKEY_ASFAR, pxa->io_pwr_lock_reg);
+   writel(IO_PWR_AKEY_ASSAR, pxa->io_pwr_lock_reg + 4);
+   val = readl(pxa->io_pwr_reg);
+
+   switch (signal_voltage) {
+   case MMC_SIGNAL_VOLTAGE_180:
+   case MMC_SIGNAL_VOLTAGE_120:
+   val |= IO_PWR_MMC1_PAD_1V8;
+   break;
+   case MMC_SIGNAL_VOLTAGE_330:
+   default:
+   val &= ~IO_PWR_MMC1_PAD_1V8;
+   break;
+   }
+
+   writel(IO_PWR_AKEY_ASFAR, pxa->io_pwr_lock_reg);
+   writel(IO_PWR_AKEY_ASSAR, pxa->io_pwr_lock_reg + 4);
+
+   writel(val, pxa->io_pwr_reg);
+}
+
 static const struct sdhci_ops pxav3_sdhci_ops = {
.set_clock  = sdhci_set_clock,
.platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
@@ -314,6 +353,7 @@ static const struct sdhci_ops pxav3_sdhci_ops = {
.set_bus_width  = sdhci_set_bus_width,
.reset  = pxav3_reset,
.set_uhs_signaling  = pxav3_set_uhs_signaling,
+   .voltage_switch = pxav3_voltage_switch,
 };
 
 static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
@@ -368,6 +408,7 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
struct sdhci_host *host = NULL;
struct sdhci_pxa *pxa = NULL;
const struct of_device_id *match;
+   struct resource *res;
int ret;
 
pxa = devm_kzalloc(>dev, sizeof(struct sdhci_pxa), GFP_KERNEL);
@@ -408,6 +449,24 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
goto err_mbus_win;
}
 
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "io-pwr-conf");
+   if (res) {
+   pxa->io_pwr_reg = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(pxa->io_pwr_reg)) {
+   ret = PTR_ERR(pxa->io_pwr_reg);
+   goto err_mbus_win;
+   }
+   }
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 
"io-pwr-lock-unlock");
+   if (res) {
+   pxa->io_pwr_lock_reg = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(pxa->io_pwr_lock_reg)) {
+   ret = PTR_ERR(pxa->io_pwr_lock_reg);
+   goto err_mbus_win;
+   }
+   }
+
match = of_match_device(of_match_ptr(sdhci_pxav3_of_match), >dev);
if (match) {
ret = mmc_of_parse(host->mmc);
-- 
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/

[RFC 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages

[Vaibhav Hiremath]

Currently, the sdhci_do_start_signal_voltage_switch() function invokes
controller specific voltage switch configuration only for 1.8v usecase;
but it is required for others as well.

For example, in case of PXA1928 SDH controller, we need to set different
configuration for 3.3, 1.8 and 1.2 volt support (I/O domain power
control register).

Signed-off-by: Vaibhav Hiremath 
---
Note:
Currently ->voltage_switch() callback is only supported
in f_sdh30 driver. And I am not sure on the dependency of execution
sequence for that device. I could have moved ->voltage_switch() call
at one common place (above/below), but was not quite sure about it.
So, replicated/duplicated the call for other voltages.

 drivers/mmc/host/sdhci.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 3dd295f..b59b76d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1753,6 +1753,10 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
/* Wait for 5ms */
usleep_range(5000, 5500);
 
+   /* Some controller need to do more when switching */
+   if (host->ops->voltage_switch)
+   host->ops->voltage_switch(host, MMC_SIGNAL_VOLTAGE_330);
+
/* 3.3V regulator output should be stable within 5 ms */
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
if (!(ctrl & SDHCI_CTRL_VDD_180))
@@ -1803,6 +1807,10 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
return -EIO;
}
}
+   /* Some controller need to do more when switching */
+   if (host->ops->voltage_switch)
+   host->ops->voltage_switch(host, MMC_SIGNAL_VOLTAGE_120);
+
return 0;
default:
/* No signal voltage switch required */
-- 
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: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer  wrote:
> On Tue, Sep 1, 2015 at 2:31 PM, Andy Lutomirski  wrote:
>> On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  
>> wrote:
>>> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  
>>> wrote:
 On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
 wrote:
> Hi
>
> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
> wrote:
>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
>> wrote:
>>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
>>> wrote:
 I haven't checked the context in which it's used, but in order for
 kdbus_proc_permission to do what it claims to do, it appears to be
 missing calls to security_inode_permission and
 security_file_permission.
>>>
>>> Both are expected to be added by lsm patches (both hooks you mentioned
>>> are empty if no lsm is selected).
>>
>> Will that mean that existing MAC policies stop being fully enforced
>> (in effect) if kdbus is installed?
>
> It means kdbus messages carry information about the sender, which LSMs
> might prevent you to read via /proc. Just like you can send dbus
> messages to a peer, which LSM-enhanced dbus-daemon might not allow.

 It's a security-sensitive function that doesn't do what the name and
 description suggest.  Whether that's an active problem or not is
 unknown, but it's certainly a maintainability problem.

> If
> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> support. We explicitly support legacy dbus1-compat for exactly such
> reasons.

 This is not an acceptable attitude for security.

 There are so many things wrong with your statement that I'll limit
 myself to one of them: Fedora 23/Rawhide, which is the *reference*
 platform, uses SELinux.
>>>
>>> Clarification: Fedora Rawhide only.  The kdbus code is not included in
>>> the F23 kernel.
>>>
>>> Your point otherwise stands.  I just don't want Phoronix or someone
>>> else getting confused and thinking Fedora 23 will ship with kdbus.  It
>>> will not.
>>
>> But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
>> Granted, systemd is build with --disable-kdbus, but if it's a new
>> enough version, then I think that means that the code is still there.
>>
>> To be clear, I don't claim to have found a specific security hole, but
>> in the event that running Fedora 23 with a kdbus-supporting kernel and
>> booting with kdbus=1 [1] introduces security problems, then we have a
>> problem. (This isn't nearly as bad as it would be if we had problems
>> just by upgrading the kernel.)  And there is certainly something wrong
>> with the process if the kdbus team thinks it's okay that enabling
>> kdbus can break existing security policy.
>
> You seem to have interpreted my email as argumentation.  I don't want
> to argue.  I simply want to point out that Fedora 23 will not ship
> with kdbus in the kernel.  Therefore the Fedora 23 release, for its
> entire supported timeframe, will not utilize kdbus.

I don't want to argue either :)

>
> So if someone wants to rebuild a kernel that contains the kdbus driver
> and jump through the hoops you describe, then yes they might very well
> run into problems you suggest might be present.  However, they will
> also not be running Fedora 23 at that point.  I wish such users well
> and thank them for their upstream testing efforts.
>

This does highlight a difference in configurations that the upstream
kernel configures supported versus what Fedora considers supported.
>From Fedora's POV (correct me if I'm wrong), if you boot with a kernel
with an unsupported configuration, it's unsupported.  From the
upstream kernel's POV, if you flip on new features and boot an old
distro, it's supposed to work with *very* few exceptions.

> To be honest, I'm not sure what "process" you're talking about.
> Kernel development is kind of rife with examples of new features
> having security issues and it taking time to sort them out.  I don't
> mean to cast aspersions, but user namespaces has had numerous CVEs
> since it's inclusion.  I don't think anyone here has ever accused its
> development of not following some kind of process.  And distros took
> some time before enabling that feature, which is what I expect to
> happen with kdbus should it ever be merged.  That certainly isn't an
> argument for allowing _known_ security issues into the kernel, but as
> you said, you haven't found a security hole as of yet.

No one in user namespace land has considered it acceptable for an old
userspace that's running a new kernel with user namespaces turned on
to have security problems as a result of user namespaces.  It's
happened, but it's considered a 

Re: [PATCH 21/31] perf tools: Move linux/filter.h to tools/include

[Arnaldo Carvalho de Melo]

Em Tue, Sep 01, 2015 at 04:39:59PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sat, Aug 29, 2015 at 04:21:55AM +, Wang Nan escreveu:
> > From: He Kuang 
> -/* Conditional jumps against immediates, if (dst_reg 'op' imm32) goto pc + 
> off16 */
> +/* Conditional jumps against immediates,
> + * if (dst_reg 'op' imm32) goto pc + off16
> + */
 
> Please refrain from doing that... I.e. spell checking is kinda useful,
> introducing gratuitous further drift from include/linux/FOO.h to
> tools/include/linux/FOO.h is not.

I've done it this time. I.e. left it as a strict copy, modulo the unused
parts that were purposefuly removed in the original patch. Trying to
cherry pick as many patches from this series as possible, to help in
getting the eBPF patchkit in.

- Arnaldo
--
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: [GIT PULL] Early batch of KVM changes for 4.3 merge window

[Paolo Bonzini]

On 01/09/2015 02:47, Linus Torvalds wrote:
> Hmm:
> 
> On Fri, Aug 14, 2015 at 4:57 PM, Paolo Bonzini  wrote:
>>
>> Xiao Guangrong (9):
>>   KVM: MMU: fully check zero bits for sptes
> 
> The above commit causes an annoying new compiler warning.
> 
> The warning is bogus ("variable 'leaf' possibly uninitialized"),
> because the use of the variable is protected by the 'bool reserved'
> flag, but gcc is apparently not smart enough to understand that.

Unfortunately it doesn't reproduce on all compiler versions.

Something like this should do it:

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index fb16a8ea3dee..3c745f3abde8 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3309,13 +3309,13 @@ walk_shadow_page_get_mmio_spte(struct kvm_vcpu *vcpu, 
u64 addr, u64 *sptep)
 
walk_shadow_page_lockless_begin(vcpu);
 
-   for (shadow_walk_init(, vcpu, addr), root = iterator.level;
+   for (shadow_walk_init(, vcpu, addr),
+leaf = root = iterator.level;
 shadow_walk_okay();
 __shadow_walk_next(, spte)) {
-   leaf = iterator.level;
spte = mmu_spte_get_lockless(iterator.sptep);
 
-   sptes[leaf - 1] = spte;
+   sptes[--leaf] = spte;
 
if (!is_shadow_present_pte(spte))
break;
@@ -3329,7 +3329,7 @@ walk_shadow_page_get_mmio_spte(struct kvm_vcpu *vcpu, u64 
addr, u64 *sptep)
if (reserved) {
pr_err("%s: detect reserved bits on spte, addr 0x%llx, dump 
hierarchy:\n",
   __func__, addr);
-   while (root >= leaf) {
+   while (root > leaf) {
pr_err("-- spte 0x%llx level %d.\n",
   sptes[root - 1], root);
root--;


But honestly I haven't even compiled it yet.  Xiao, what do you think?

Paolo

> Since bogus warnings cause people to possibly ignore the *real*
> warnings, this should be fixed. Maybe the code should get rid of that
> 'reserved' flag, and instead initialize "leaf" to zero, and use that
> as the flag instead (since zero isn't a valid level)? That would
> actually avoid an extra variable, and would get rid of the warning.
> 
> Hmm?
> 
>  Linus
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
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: [BUG] Boot hangs at clocksource_done_booting on large configs

[Alex Thorlton]

On Mon, Aug 31, 2015 at 11:12:12PM +0200, Thomas Gleixner wrote:
> On Mon, 31 Aug 2015, Alex Thorlton wrote:
> > I was able to hit this issue on 4.2-rc1 with our RTC disabled, to rule
> > out any scaling issues related to multiple concurrent reads to our
> > RTC's MMR.
> 
> And to rule out scaling issues you replaced the RTC MMR with HPET. Not
> a very good choice:
> 
> HPET does not scale either. It's uncached memory mapped I/O. See
> below.

Ahhh.  I wondered if there might be an issue there.  I can say that I've
seen it hit a very similar issue with some other possible solutions that
we've tried, but this was the most recent, fairly unmodified kernel that
I've played with, so I went with this.

> > I'm hoping to get some input from the experts in this area, first of
> > all, on whether the problem I'm seeing is actually what I think it is,
> > and, if so, if I've solved it in the correct way.
> 
> I fear both the analysis and the solution is wrong.
> 
> Up to the point where the actual clocksource change happens there is
> no reason why timer interrupts should not happen. And the code which
> actually changes the clocksource is definitely called with interrupts
> disabled. When that function returns the new clocksource is fully
> functional and interrupts can happen again.
> 
> Now looking at your backtraces. Most CPUs are in the migration thread
> and a few (3073,3078,3079,3082) are in the idle task.
> 
> From the trace artifacts (? read_hpet) it looks like the clock source
> change has been done and the cpus are on the way back from stop
> machine.

That's good to note.  I'll keep that in mind as I continue gathering
info.

> But they are obviously held off by something. And that something looks
> like the timekeeper sequence lock. 

Ok.  IIRC, that lock prevents reads to the clocksource until all
necessary write operations have finished, correct?  i.e. tk_core.seq?

I looked at that as being a possible place to get stuck in ktime_get:

do {
seq = read_seqcount_begin(_core.seq);
base = tk->tkr_mono.base;
nsecs = timekeeping_get_ns(>tkr_mono);

} while (read_seqcount_retry(_core.seq, seq));

But I don't have enough evidence to point there for sure.

> Too bad, that we don't have a backtrace for CPU0 in the log.

I think that may have gotten swallowed up with all the lost printks that
you'll notice in there.  Does the hung task backtrace not cover that
though?

> I really wonder how a machine that large works with HPET as
> clocksource at all. hpet_read() is uncached memory mapped IO which
> takes thousands of CPU cycles. Last time I looked it was around
> 1us. Let's take that number to do some math.
> 
> If all CPUs do that access at the same time, then it takes NCPUS
> microseconds to complete if the memory mapped I/O scheduling is
> completely fair, which I doubt. So with 4k CPUs thats whopping 4.096ms
> and it gets worse if you go larger. That's more than a tick with
> HZ=250.
> 
> I'm quite sure that you are staring at the HPET scalability bottleneck
> and not at some actual kernel bug.

That could well be the case.

> Your patch shifts some timing around so the issue does not happen, but
> that's certainly not a solution.

I was fairly sure of that, but it's good to know that you agree.

I'll try and get a backtrace from a completely unmodified kernel here in
the next few days.  Unfortunately, as mentioned, we only hit the issue
intermittently.  I was able to reproduce pretty regularly on kernels
from 4.0 and before, but it seems to be less common on newer kernels,
though we definitely still manage to hit it from time to time.

Thanks for all the help!

- Alex
--
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 1/2] nohz: Affine unpinned timers to housekeepers

[Jiang, Yunhong]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Frederic Weisbecker
> Sent: Tuesday, September 1, 2015 7:51 AM
> To: Ingo Molnar; Peter Zijlstra
> Cc: LKML; Vatika Harlalka; Chris Metcalf; Thomas Gleixner; Preeti U Murthy;
> Christoph Lameter; Frederic Weisbecker; Paul E . McKenney
> Subject: [PATCH 1/2] nohz: Affine unpinned timers to housekeepers
> 
> From: Vatika Harlalka 
> 
> The problem addressed in this patch is about affining unpinned timers.
> Adaptive or Full Dynticks CPUs are currently disturbed by unnecessary
> jitter due to firing of such timers on them.
> 
> This patch will affine timers to online CPUs which are not full dynticks
> in NOHZ_FULL configured systems. It should not introduce overhead in
> nohz full off case due to static keys.
> 
> Reviewed-by: Preeti U Murthy 
> Signed-off by: Vatika Harlalka 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Christoph Lameter 
> Cc: Thomas Gleixner 
> Cc: Paul E. McKenney 
> Cc: Chris Metcalf 
> Signed-off-by: Frederic Weisbecker 
> ---
>  include/linux/tick.h | 9 +
>  kernel/sched/core.c  | 7 +--
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index 48d901f..e312219 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -147,11 +147,20 @@ static inline void tick_nohz_full_add_cpus_to(struct
> cpumask *mask)
>   cpumask_or(mask, mask, tick_nohz_full_mask);
>  }
> 
> +static inline int housekeeping_any_cpu(void)
> +{
> + return cpumask_any_and(housekeeping_mask, cpu_online_mask);
> +}
> +
>  extern void tick_nohz_full_kick(void);
>  extern void tick_nohz_full_kick_cpu(int cpu);
>  extern void tick_nohz_full_kick_all(void);
>  extern void __tick_nohz_task_switch(void);
>  #else
> +static inline int housekeeping_any_cpu(void)
> +{
> + return smp_processor_id();
> +}
>  static inline bool tick_nohz_full_enabled(void) { return false; }
>  static inline bool tick_nohz_full_cpu(int cpu) { return false; }
>  static inline void tick_nohz_full_add_cpus_to(struct cpumask *mask) { }
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 8b864ec..0902e4d 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -623,18 +623,21 @@ int get_nohz_timer_target(void)
>   int i, cpu = smp_processor_id();
>   struct sched_domain *sd;
> 
> - if (!idle_cpu(cpu))
> + if (!idle_cpu(cpu) && is_housekeeping_cpu(cpu))
>   return cpu;
> 
>   rcu_read_lock();
>   for_each_domain(cpu, sd) {
>   for_each_cpu(i, sched_domain_span(sd)) {
> - if (!idle_cpu(i)) {
> + if (!idle_cpu(i) && is_housekeeping_cpu(cpu)) {

Hi, Frederic, sorry for a naive question. Per my understanding, the 
tick_nohz_full_mask is added to cpu_isolated_map in sched_init_smp(), and the 
cpu_isolated_map is excluded from sched_domain in init_sched_domains(), so why 
check here?

Thanks
--jyh
--
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] arch/x86/mm/srat: Print non-volatile flag in SRAT

[Linda Knippers]

With the addition of NVDIMM support, a question came up as to whether
NVDIMM ranges should be in the SRAT with this bit set.  I think the
consensus was no because the ranges are in the NFIT with proximity
domain information there.

ACPI is not clear on the meaning of this bit in the SRAT.
If someone is setting it, we might want to ask them what they expect
to happen with it.

Right now this bit is only printed if all the ACPI debug information is
turned on.  

Signed-off-by: Linda Knippers 
---
 arch/x86/mm/srat.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 66338a6..c2aea63 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -192,10 +192,11 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
 
node_set(node, numa_nodes_parsed);
 
-   pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s\n",
+   pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
node, pxm,
(unsigned long long) start, (unsigned long long) end - 1,
-   hotpluggable ? " hotplug" : "");
+   hotpluggable ? " hotplug" : "",
+   ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
 
/* Mark hotplug range in memblock. */
if (hotpluggable && memblock_mark_hotplug(start, ma->length))
-- 
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] perf tools: Fix random building error

[Adrian Hunter]

On 01/09/15 08:56, Wang Nan wrote:
> I hit following building error randomly:

Random presumably because there is a race to use/create the directory by
different make jobs (i.e. -j option).

> 
>   ...
> /bin/sh: /path/to/kernel/buildperf/util/intel-pt-decoder/inat-tables.c: No 
> such file or directory
>   ...
>   LINK /path/to/kernel/buildperf/plugin_mac80211.so
>   LINK /path/to/kernel/buildperf/plugin_kmem.so
>   LINK /path/to/kernel/buildperf/plugin_xen.so
>   LINK /path/to/kernel/buildperf/plugin_hrtimer.so
> In file included from util/intel-pt-decoder/intel-pt-insn-decoder.c:25:0:
> util/intel-pt-decoder/inat.c:24:25: fatal error: inat-tables.c: No such file 
> or directory
>  #include "inat-tables.c"
>  ^
> compilation terminated.
> make[4]: *** 
> [/path/to/kernel/buildperf/util/intel-pt-decoder/intel-pt-insn-decoder.o] 
> Error 1
> make[4]: *** Waiting for unfinished jobs
>   LINK /path/to/kernel/buildperf/plugin_function.so
> 
> This is caused by tools/perf/util/intel-pt-decoder/Build that, it tries to
> generate $(OUTPUT)util/intel-pt-decoder/inat-tables.c atomatically but
> forget to ensure the existance of $(OUTPUT)util/intel-pt-decoder directory.
> 
> This patch fixes it by adding $(call rule_mkdir) like other similar rules.
> 
> Signed-off-by: Wang Nan 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Adrian Hunter 

Looks ok to me. Jiri?

> ---
>  tools/perf/util/intel-pt-decoder/Build | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/util/intel-pt-decoder/Build 
> b/tools/perf/util/intel-pt-decoder/Build
> index 240730d..2386322 100644
> --- a/tools/perf/util/intel-pt-decoder/Build
> +++ b/tools/perf/util/intel-pt-decoder/Build
> @@ -4,6 +4,7 @@ inat_tables_script = 
> util/intel-pt-decoder/gen-insn-attr-x86.awk
>  inat_tables_maps = util/intel-pt-decoder/x86-opcode-map.txt
>  
>  $(OUTPUT)util/intel-pt-decoder/inat-tables.c: $(inat_tables_script) 
> $(inat_tables_maps)
> + $(call rule_mkdir)
>   @$(call echo-cmd,gen)$(AWK) -f $(inat_tables_script) 
> $(inat_tables_maps) > $@ || rm -f $@
>  
>  $(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: 
> util/intel-pt-decoder/inat.c $(OUTPUT)util/intel-pt-decoder/inat-tables.c
> 

--
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] PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos and use them

[David Howells]

James Morris  wrote:

> Please always specify which kernel a patch/pull request is for.

security/next in this case.

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/

[PATCH v4 08/16] drm: rockchip/dp: add rockchip platform dp driver

[Yakir Yang]

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.

Changes in v3:
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
  dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
  core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform
  driver which name to "pclk".
- Take Heiko suggest, add devicetree binding document.
- Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
  point to get panel node.
- Add the new function point analogix_dp_platdata.get_modes init.

Changes in v2:
- Take Heiko suggest, get panel node with remote-endpoint method,
  and create devicetree binding for driver.
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.

 .../bindings/video/analogix_dp-rockchip.txt|  74 
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 389 +
 4 files changed, 473 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
new file mode 100644
index 000..502483e
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
@@ -0,0 +1,74 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+  Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+   dp-controller: dp@ff97 {
+   compatible = "rockchip,rk3288-dp";
+   reg = <0xff97 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
+   clock-names = "dp", "pclk";
+   phys = <_phy>;
+   phy-names = "dp";
+
+   rockchip,grf = <>;
+   resets = < 111>;
+   reset-names = "dp";
+
+   status = "disabled";
+
+   ports {
+   edp_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_edp>;
+   };
+   edp_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_edp>;
+   };
+   };
+
+   edp_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_out_panel: endpoint {
+   reg = <0>;
+   remote-endpoint = <_in_edp>
+   };
+   };
+   };
+   };
+
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..c2ba945 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_ANALOGIX_DP
+tristate "Rockchip specific extensions for Analogix DP driver"
+depends on DRM_ROCKCHIP
+select DRM_ANALOGIX_DP
+help
+ This selects 

Re: [BUG 4.2-rc8] Interrupt occurs while apply_alternatives() is patching the handler

[Richard W.M. Jones]

On Sun, Aug 30, 2015 at 10:37:57PM -0400, Chuck Ebbert wrote:
> This is from https://bugzilla.redhat.com/show_bug.cgi?id=1258223
> 
> [0.036000] BUG: unable to handle kernel paging request at 55501e06
[...]
> [0.036000]  [] ? add_nops+0x90/0xa0
> [0.036000]  [] apply_alternatives+0x274/0x630
> [0.036000]  [] ? wait_for_xmitr+0xa0/0xa0
> [0.036000]  [] ? sprintf+0x1c/0x20
> [0.036000]  [] ? irq_entries_start+0x698/0x698
> [0.036000]  [] ? memcpy+0xb/0x30
> [0.036000]  [] ? serial8250_set_termios+0x20/0x20
[...]
> Interrupt 0x30 occurred while the alternatives code was replacing the
> initial 0x90,0x90,0x90 NOPs (from the ASM_CLAC macro) with the optimized
> version, 0x8d,0x76,0x00. Only the first byte has been replaced so far,
> and it makes a mess out of the insn decoding.

Chuck, thanks for reporting this.

I have only been able to reproduce this so far using qemu and TCG (not
KVM) which of course raises a range of questions: could it be a qemu
bug or a TCG bug?  Could it be that an atomic op is not correctly
implemented by qemu?  I will keep trying on KVM.  Because I don't have
a convenient server with 32 bit kernel and a serial port that I can
reboot thousands of times, I have not tried to reproduce on baremetal yet.

Here's how to reproduce it.  (The host can be x86-64)

(1) Grab the 32 bit Fedora kernel we are using from
https://kojipkgs.fedoraproject.org//packages/kernel/4.2.0/1.fc24/i686/kernel-core-4.2.0-1.fc24.i686.rpm
(from http://koji.fedoraproject.org/koji/buildinfo?buildID=681723)

(2) Unpack it to extract vmlinuz:

cd /tmp
rpm2cpio /mnt/scratch/kernel-core-4.2.0-1.fc24.i686.rpm | cpio -id
cp ./lib/modules/4.2.0-1.fc24.i686/vmlinuz .

(3) Boot the kernel under qemu/KVM.  The following single line command
repeatedly boots the kernel until the bug is hit:

while qemu-system-x86_64 -nographic -no-reboot -M accel=kvm:tcg -kernel vmlinuz 
-append 'console=ttyS0 panic=1' -serial stdio -monitor none >& log; ! grep 
add_nops log; do echo -n .; done

It takes many iterations (100s with TCG) to hit the bug.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
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 v4 15/16] drm: bridge: analogix/dp: move hpd detect to connector detect function

[Yakir Yang]

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e6b328a..499ec57 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -908,12 +908,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = analogix_dp_detect_hpd(dp);
-   if (ret) {
-   /* Cable has been disconnected, we're done */
-   return;
-   }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -949,6 +943,12 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
 static enum drm_connector_status
 analogix_dp_detect(struct drm_connector *connector, bool force)
 {
+   struct analogix_dp_device *dp = connector_to_dp(connector);
+
+   if (analogix_dp_detect_hpd(dp))
+   /* Cable has been disconnected, we're done */
+   return connector_status_disconnected;
+
return connector_status_connected;
 }
 
-- 
2.1.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 v2 1/6] perf: Introduce extended syscall error reporting

[Alexander Shishkin]

Andy Shevchenko  writes:

> On Mon, Aug 24, 2015 at 5:32 PM, Alexander Shishkin
>  wrote:
>> +   /* trim the buffer to the supplied boundary */
>> +   len = strlen(buffer);
>> +   if (len >= attr->perf_err_size) {
>> +   len = attr->perf_err_size - 1;
>> +   buffer[len] = 0;
>> +   }
>
> len = strnlen(buffer, attr->perf_err_size);
> buffer[len] = 0;
>
> And perhaps perf_err_size has to be length (perf_err_len) ?
>
>> +
>> +   if (copy_to_user((void __user *)attr->perf_err, buffer, len + 1)) {
>> +   /* if we failed to copy once, don't bother later */
>> +   attr->perf_err_size = 0;
>
> Kaboom next time on buffer[-1] = 0; since len >= 0?

Of course, we never get here if attr::perf_err_size is 0, there's an
explicit check for that, but nice try.

Regards,
--
Alex
--
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 1/2] perf,kvm/powerpc: Add kvm_perf.h for powerpc

[Hemant Kumar]

(cc'ing Michael Ellerman with this reply)

Hi Arnaldo,

On 09/01/2015 01:43 AM, Arnaldo Carvalho de Melo wrote:

Em Mon, Aug 31, 2015 at 12:18:00PM +0530, Hemant Kumar escreveu:

To analyze the exit events with perf, we need to export the related
tracepoints through kvm_perf.h. kvm_perf.h is to be added in the
arch/powerpc directory, where the kvm tracepoints needed to trace the
KVM exit events are defined.

To indicate that the tracepoints are book3s_hv specific, suffix _HV has
been added to the tracepoint macros. Additionally, we also need to
define the generic macros (albeit, with null strings) suffix, because
the preprocessor looks for them in the generic code in builtin-kvm.c.

Signed-off-by: Hemant Kumar 

humm, there are two patchkits, this one with two patches, the other with
3, this one for the kernel, the other one for tools/, but for the tools/
part to work, does this one needs to be applied first?

Should I try to process the 5 together, applying thest two first?


Yes, this patchset needs to be applied before applying the other patchset,
since there is a direct dependency on these two for the tooling part to
work.


I see there are no acks from powerpc arch maintainers, how should we
proceed here? If there are no problems with the arch bits, and if it is
just to enable the tooling part, again, should I process the 5 as just
one series?


The reason to split the earlier patchset into two was to separate the
tooling/perf/ and arch/powerpc/ side patches, as asked by Michael..

Here is the link to that discussion :
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg86916.html

If Michael is ok with the patches, you can process all the 5 patches 
together. Michael?




- Arnaldo


---
Changes since v5:
- Moved back the tracepoint definitions from kvm_perf_book3s.h to kvm_perf.h

  arch/powerpc/include/uapi/asm/kvm_perf.h | 21 +
  1 file changed, 21 insertions(+)
  create mode 100644 arch/powerpc/include/uapi/asm/kvm_perf.h

diff --git a/arch/powerpc/include/uapi/asm/kvm_perf.h 
b/arch/powerpc/include/uapi/asm/kvm_perf.h
new file mode 100644
index 000..68f105e
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/kvm_perf.h
@@ -0,0 +1,21 @@
+#ifndef _ASM_POWERPC_KVM_PERF_H
+#define _ASM_POWERPC_KVM_PERF_H
+
+#include 
+
+#define DECODE_STR_LEN 40
+
+#define VCPU_ID "vcpu_id"
+
+/* For Book3S_HV machines */
+#define KVM_ENTRY_TRACE_HV "kvm_hv:kvm_guest_enter"
+#define KVM_EXIT_TRACE_HV "kvm_hv:kvm_guest_exit"
+#define KVM_EXIT_REASON_HV "trap"
+
+/* This is to shut the compiler up */
+#define KVM_ENTRY_TRACE ""
+#define KVM_EXIT_TRACE ""
+#define KVM_EXIT_REASON ""
+
+
+#endif /* _ASM_POWERPC_KVM_PERF_H */
--
1.9.3

___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


--
Thanks,
Hemant Kumar

--
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/

Possible deadlock related to CPU hotplug and kernfs

[Jiang Liu]

Hi Rafael and Tejun,
When running CPU hotplug tests, it triggers an lockdep warning
as follow. The two possible deadlock paths are:
1) echo x > /sys/devices/system/cpu/cpux/online
   ->kernfs_fop_write()
 ->kernfs_get_active()
1.a)   ->rwsem_acquire_read(>dep_map, 0, 1, _RET_IP_);
 ->cpu_up()
1.b)   ->cpu_hotplug_begin()[lock_map_acquire(_hotplug.dep_map)]
2) hardware triggers hotplug evetns
   ->acpi_device_hotplug()
 ->acpi_processor_remove()
2.a)   ->cpu_hotplug_begin()[lock_map_acquire(_hotplug.dep_map)]
 ->unregister_cpu()
   ->device_del()
 ->kernfs_remove_by_name_ns()
   ->__kernfs_remove()
 ->kernfs_drain()
2.b)   ->rwsem_acquire(>dep_map, 0, 0, _RET_IP_)

So there is a possible deadlock scenario among 1.a, 1.b, 2.a and 2.b.
I'm not familiar with kernfs, so could you please help to comment:
1) whether is a real deadlock issue?
2) any recommended way to get it fixed?
Thanks!
Gerry

Full lockdep warnings:
[  310.309391] [ INFO: possible circular locking dependency detected ]
[  310.316462] 4.2.0-rc8+ #7 Not tainted
[  310.320613] ---
[  310.327684] kworker/u288:3/388 is trying to acquire lock:
[  310.333780]  (s_active#97){.+}, at: []
kernfs_remove_by_name_ns+0x49/0xb0
[  310.343885]
[  310.343885] but task is already holding lock:
[  310.350466]  (cpu_hotplug.lock#2){+.+.+.}, at: []
cpu_hotplug_begin+0x7b/0xc0
[  310.360564]
[  310.360564] which lock already depends on the new lock.
[  310.360564]
[  310.369766]
[  310.369766] the existing dependency chain (in reverse order) is:
[  310.378198]
[  310.378198] -> #3 (cpu_hotplug.lock#2){+.+.+.}:
[  310.383821][] lock_acquire+0xdd/0x2a0
[  310.390591][] mutex_lock_nested+0x70/0x3e0
[  310.397847][] cpu_hotplug_begin+0x7b/0xc0
[  310.405004][] _cpu_up+0x31/0x140
[  310.411285][] cpu_up+0x7c/0xa0
[  310.417362][] smp_init+0x86/0x88
[  310.423647][] kernel_init_freeable+0x171/0x286
[  310.431292][] kernel_init+0xe/0xe0
[  310.437771][] ret_from_fork+0x3f/0x70
[  310.444540]
[  310.444540] -> #2 (cpu_hotplug.lock){++}:
[  310.449957][] lock_acquire+0xdd/0x2a0
[  310.456714][] cpu_hotplug_begin+0x6d/0xc0
[  310.463871][] _cpu_up+0x31/0x140
[  310.470143][] cpu_up+0x7c/0xa0
[  310.476228][] smp_init+0x86/0x88
[  310.482509][] kernel_init_freeable+0x171/0x286
[  310.490153][] kernel_init+0xe/0xe0
[  310.496628][] ret_from_fork+0x3f/0x70
[  310.503393]
[  310.503393] -> #1 (cpu_add_remove_lock){+.+.+.}:
[  310.509099][] lock_acquire+0xdd/0x2a0
[  310.515866][] __might_fault+0x84/0xb0
[  310.522635][] kernfs_fop_write+0x8f/0x190
[  310.529793][] __vfs_write+0x28/0xe0
[  310.536368][] vfs_write+0xac/0x1a0
[  310.542833][] SyS_write+0x49/0xb0
[  310.549212][]
entry_SYSCALL_64_fastpath+0x16/0x7a
[  310.557149]
[  310.557149] -> #0 (s_active#97){.+}:
[  310.562135][] __lock_acquire+0x21b9/0x21c0
[  310.569391][] lock_acquire+0xdd/0x2a0
[  310.576159][] __kernfs_remove+0x231/0x330
[  310.583318][]
kernfs_remove_by_name_ns+0x49/0xb0
[  310.591154][] sysfs_remove_file_ns+0x15/0x20
[  310.598594][] device_remove_attrs+0x3e/0x80
[  310.605948][] device_del+0x138/0x270
[  310.612617][] device_unregister+0x22/0x70
[  310.619767][] unregister_cpu+0x39/0x60
[  310.626622][] arch_unregister_cpu+0x23/0x30
[  310.633974][] acpi_processor_remove+0x91/0xca
[  310.641524][] acpi_bus_trim+0x5a/0x8d
[  310.648292][] acpi_bus_trim+0x38/0x8d
[  310.655060][]
acpi_scan_device_not_present+0x1d/0x3d
[  310.663312][] acpi_scan_bus_check+0x29/0xa2
[  310.670654][] acpi_device_hotplug+0x99/0x3fa
[  310.678103][] acpi_hotplug_work_fn+0x1f/0x2b
[  310.68][] process_one_work+0x1f1/0x7c0
[  310.692814][] worker_thread+0x69/0x480
[  310.699677][] kthread+0x11f/0x140
[  310.706046][] ret_from_fork+0x3f/0x70
[  310.712815]
[  310.712815] other info that might help us debug this:
[  310.712815]
[  310.721907] Chain exists of:
[  310.721907]   s_active#97 --> cpu_hotplug.lock --> cpu_hotplug.lock#2
[  310.721907]
[  310.731680]  Possible unsafe locking scenario:
[  310.731680]
[  310.738413]CPU0CPU1
[  310.743562]
[  310.748710]   lock(cpu_hotplug.lock#2);
[  310.753261]lock(cpu_hotplug.lock);
[  310.760382]lock(cpu_hotplug.lock#2);
[  310.767755]   lock(s_active#97);
[  310.771625]
[  310.771625]  *** DEADLOCK ***
[  310.771625]
[  310.778382] 7 locks held by kworker/u288:3/388:
[  310.783530]  #0:  ("kacpi_hotplug"){.+.+.+}, at: []

Re: [PATCH 2/3][v2] drivers: usb: dwc3: Add frame length adjustment quirk

[Felipe Balbi]

Hi,

On Mon, Aug 17, 2015 at 09:54:56AM +0530, Nikhil Badola wrote:
> +static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj)
> +{
> + if (dwc->revision < DWC3_REVISION_250A)
> + return;
> +
> + if (fladj == 0)
> + return;
> +
> + if (fladj) {

right here you know fladj to be non-zero.

> @@ -957,6 +990,7 @@ static int dwc3_probe(struct platform_device *pdev)
>   goto err1;
>   }
>  
> +

stray change

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] usb: core: Fix side effect of clear port feature in hub port reset

[hyunho747.kim]

After successful port reset by set_port_feature, some devices show
immediate link connection which generates port connect change interrupt.
But, the next step is an unconditional usb_clear_port_feature
and this flow always clears USB_PORT_FEAT_C_CONNECTION bit in port status
though next kick_khubd is reserved by link connection interrupt.
This flow can make an ambiguous state in the next port_evnet operation,
port_status is connected state such as 0x203 but
port_change is zero value caused by the previous clear port feature.
So, port_event can't call hub_port_connect_change and
there is no other way to peform connect procedure.

Signed-off-by: hyunho747.kim 
---
 drivers/usb/core/hub.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 73dfa19..4508aff 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2761,18 +2761,21 @@ static int hub_port_reset(struct usb_hub *hub, int 
port1,
 
/* Check for disconnect or reset */
if (status == 0 || status == -ENOTCONN || status == -ENODEV) {
-   usb_clear_port_feature(hub->hdev, port1,
+   if (status)
+   usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_RESET);
 
if (!hub_is_superspeed(hub->hdev))
goto done;
 
-   usb_clear_port_feature(hub->hdev, port1,
+   if (status) {
+   usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_BH_PORT_RESET);
-   usb_clear_port_feature(hub->hdev, port1,
+   usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
-   usb_clear_port_feature(hub->hdev, port1,
+   usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
+   }
 
/*
 * If a USB 3.0 device migrates from reset to an error
-- 
2.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: [GIT PULL] scheduler changes for v4.3

[Ingo Molnar]

* Markus Trippelsdorf  wrote:

> On 2015.08.31 at 19:24 +0200, Ingo Molnar wrote:
> > Please pull the latest sched-core-for-linus git tree from:
> > 
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > sched-core-for-linus
> > 
> ># HEAD: ff277d4250fe715b219b1a3423b863418794 sched/deadline: Fix 
> > comment in enqueue_task_dl()
> 
> Linus,
> 
> your merge (commit a1d8561172f369ba) breaks booting on my machine.

So I just double checked Linus's merge resolution, re-created it from scratch, 
and 
it looks correct. Furthermore, I resolved the conflict similarly in the past 
and 
this resolution had been in -tip and linux-next testing for some while.

But I noticed something weird in your revert patch:

> 
> I wrote down the backtrace:
> 
> map_vsyscall
> kvm_arch_hardware_setup
> map_vsyscall
> kvm_init
> map_vsyscall
> do_one_initcall
> kernel_init_freeable
> rest_init
> kernel_init
> ret_from_fork
> rest_init
> 
> RIP: svm_hardware_setup
> 
> Reverting your merge resolution fixes the issue:
> 
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 82cf9dff4295..873aa0757b04 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -397,12 +397,11 @@ static int _cpu_down(unsigned int cpu, int tasks_frozen)
>* Prevent irq alloc/free while the dying cpu reorganizes the
>* interrupt affinities.
>*/
> - irq_lock_sparse();

So where does this chunk come from? None of the trees nor the merge resolution 
touches this code.

Maybe you had other changes in your tree that interfered?

That missing irq_lock_sparse() might indeed break the boot. But that's not 
something that got in there from Linus's tree AFAICS.

>   /*
>* So now all preempt/rcu users must observe !cpu_active().
>*/
> - err = stop_machine(take_cpu_down, _param, cpumask_of(cpu));
> + err = __stop_machine(take_cpu_down, _param, cpumask_of(cpu));
>   if (err) {
>   /* CPU didn't die: tell everyone.  Can't complain. */
>   cpu_notify_nofail(CPU_DOWN_FAILED | mod, hcpu);

This change cannot possibly have built on Linus's tree, as __stop_machine() got 
unexported, it is now internal and static to kernel/stop_machine.c...

So could you please double check your side?

Thanks,

Ingo
--
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] xhci: fix warning when CONFIG_PM disabled.

[Mathias Nyman]

On 01.09.2015 00:26, Dave Hansen wrote:

From: Dave Hansen 

I have a .config with CONFIG_PM disabled.  I get the following
whenever compiling the xhci driver:

drivers/usb/host/xhci-pci.c:192:13: warning: ‘xhci_pme_quirk’ defined but 
not used [-Wunused-function]

Looks like we just need to move xhci_pme_quirk() to be underneath
the CONFIG_PM #ifdef.



There is a patch for this already, I'll send it forward right after the merge 
window

http://marc.info/?l=linux-usb=143988457116356=2

-Mathias

--
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] [s390]: Use .rept directive to store/load fpu registers

[Christian Borntraeger]

Am 28.08.2015 um 15:49 schrieb Alexander Kuleshov:
> We can use .rept directive to simplify/decrease assembly code
> that makes storing and loading floating point registers in the
> arch/s390/kernel/swsusp.S.
> 
> The resulting code after the patch is the same that before
> 
>  2c4: 68 00 d2 00 ld  %f0,512(%r13)
>  2c8: 68 10 d2 08 ld  %f1,520(%r13)
>  2cc: 68 20 d2 10 ld  %f2,528(%r13)
>  2d0: 68 30 d2 18 ld  %f3,536(%r13)
>  2d4: 68 40 d2 20 ld  %f4,544(%r13)
>  2d8: 68 50 d2 28 ld  %f5,552(%r13)
>  2dc: 68 60 d2 30 ld  %f6,560(%r13)
>  2e0: 68 70 d2 38 ld  %f7,568(%r13)
>  2e4: 68 80 d2 40 ld  %f8,576(%r13)
>  2e8: 68 90 d2 48 ld  %f9,584(%r13)
>  2ec: 68 a0 d2 50 ld  %f10,592(%r13)
>  2f0: 68 b0 d2 58 ld  %f11,600(%r13)
>  2f4: 68 c0 d2 60 ld  %f12,608(%r13)
>  2f8: 68 d0 d2 68 ld  %f13,616(%r13)
>  2fc: 68 e0 d2 70 ld  %f14,624(%r13)
>  300: 68 f0 d2 78 ld  %f15,632(%r13)
> 
> Signed-off-by: Alexander Kuleshov 
> ---
>  arch/s390/kernel/swsusp.S | 49 
> ---
>  1 file changed, 17 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/s390/kernel/swsusp.S b/arch/s390/kernel/swsusp.S
> index ca62946..8011e14 100644
> --- a/arch/s390/kernel/swsusp.S
> +++ b/arch/s390/kernel/swsusp.S
> @@ -48,22 +48,15 @@ ENTRY(swsusp_arch_suspend)
>   /* Store registers */
>   mvc 0x318(4,%r1),__SF_EMPTY(%r15)   /* move prefix to lowcore */
>   stfpc   0x31c(%r1)  /* store fpu control */
> - std 0,0x200(%r1)/* store f0 */
> - std 1,0x208(%r1)/* store f1 */
> - std 2,0x210(%r1)/* store f2 */
> - std 3,0x218(%r1)/* store f3 */
> - std 4,0x220(%r1)/* store f4 */
> - std 5,0x228(%r1)/* store f5 */
> - std 6,0x230(%r1)/* store f6 */
> - std 7,0x238(%r1)/* store f7 */
> - std 8,0x240(%r1)/* store f8 */
> - std 9,0x248(%r1)/* store f9 */
> - std 10,0x250(%r1)   /* store f10 */
> - std 11,0x258(%r1)   /* store f11 */
> - std 12,0x260(%r1)   /* store f12 */
> - std 13,0x268(%r1)   /* store f13 */
> - std 14,0x270(%r1)   /* store f14 */
> - std 15,0x278(%r1)   /* store f15 */
> +
> + /* store f0..f15 floating point registers */
> + .set i, 0
> + .set f, 0x200
> + .rept 16
> + std i, f(%r1)
> + .set i, (i+1)
> + .set f, (f+0x8)
> + .endr

I personally find the existing code easier to read, especially as it matches the
assembler output and I can directly where the slots are, (e.g. f11 is 0x258)

--
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 v4 10/16] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

This phy driver would control the Rockchip DisplayPort module
phy clock and phy power, it is relate to analogix_dp-rockchip
dp driver. If you want DP works rightly on rockchip platform,
then you should select both of them.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Take Kishon suggest, add commit message, and remove the redundant
  rockchip_dp_phy_init() function, move those code to probe() method.
  And remove driver .owner number.

Changes in v3:
- Take Heiko suggest, add rockchip dp phy driver,
  collect the phy clocks and power control.

Changes in v2: None

 .../devicetree/bindings/phy/rockchip-dp-phy.txt|  26 
 drivers/phy/Kconfig|   7 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-rockchip-dp.c  | 166 +
 4 files changed, 200 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..5de1088
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,26 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+
+- reg : a list of registers used by phy driver
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding:
+   Required elements: "sclk_dp" "sclk_dp_24m"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: phy@ff770274 {
+   compatilble = "rockchip,rk3288-dp-phy";
+   reg = <0xff770274 4>;
+   rockchip,grf = <>;
+   clocks = < SCLK_EDP_24M>;
+   clock-names = "24m";
+   #phy-cells = <0>;
+}
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..8f2bc4f 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_DP
+   tristate "Rockchip Display Port PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..e281f35 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..e9a726e
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,166 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
+
+#define DP_PHY_SIDDQ_WRITE_EN   BIT(21)
+#define DP_PHY_SIDDQ_ON 0
+#define DP_PHY_SIDDQ_OFFBIT(5)
+
+struct rockchip_dp_phy {
+   struct device  *dev;
+   struct regmap  *grf;
+   void __iomem   *regs;
+   struct clk *phy_24m;
+};
+
+static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
+{
+   int ret = 0;
+
+   ret = clk_set_rate(dp->phy_24m, 2400);
+   if (ret < 0) {
+   dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(dp->phy_24m);
+   if (ret < 0) {
+   dev_err(dp->dev, "cannot enable clock phy_24m %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int rockchip_dp_phy_clk_disable(struct rockchip_dp_phy *dp)
+{
+   clk_disable_unprepare(dp->phy_24m);
+
+  

[PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support

[Yakir Yang]

Signed-off-by: Yakir Yang 
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add GNU license v2 declared and samsung copyright

 drivers/gpu/drm/exynos/exynos_dp.c  |  1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  1 +
 include/drm/bridge/analogix_dp.h| 16 
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index 6060d2c..40ef727 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -224,6 +224,7 @@ static int exynos_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->dev = dev;
dp->drm_dev = drm_dev;
 
+   dp->plat_data.dev_type = EXYNOS_DP;
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.get_modes = exynos_dp_get_modes;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index efea045..4934271 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -293,6 +293,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
return ret;
}
 
+   dp->plat_data.dev_type = RK3288_DP;
dp->plat_data.attach = NULL;
dp->plat_data.get_modes = NULL;
dp->plat_data.power_on = rockchip_dp_poweron;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 8b4ffad..7209a64 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -1,9 +1,25 @@
+/*
+ * Analogix Core DP (Display Port) interface driver.
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
 #ifndef _ANALOGIX_DP_H_
 #define _ANALOGIX_DP_H_
 
 #include 
 
+enum analogix_dp_devtype {
+   EXYNOS_DP,
+   RK3288_DP,
+};
+
 struct analogix_dp_plat_data {
+   enum analogix_dp_devtype dev_type;
struct drm_panel *panel;
 
int (*power_on)(struct analogix_dp_plat_data *);
-- 
2.1.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/