Re: [PATCH 2/2] powerpc/powernv : Disable subcore for UP configs
On 06/05/2014 08:54 PM, Shreyas B. Prabhu wrote: > Build throws following errors when CONFIG_SMP=n > arch/powerpc/platforms/powernv/subcore.c: In function ‘cpu_update_split_mode’: > arch/powerpc/platforms/powernv/subcore.c:274:15: error: ‘setup_max_cpus’ > undeclared (first use in this function) > arch/powerpc/platforms/powernv/subcore.c:285:5: error: lvalue required as > left operand of assignment > > 'setup_max_cpus' variable is relevant only on SMP, so there is no point > working around it for UP. Furthermore, subcore.c itself is relevant only > on SMP and hence the better solution is to exclude subcore.c for UP builds. > > Signed-off-by: Shreyas B. Prabhu > --- > This patch applies on top of ben/powerpc.git/next branch > > arch/powerpc/platforms/powernv/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/platforms/powernv/Makefile > b/arch/powerpc/platforms/powernv/Makefile > index 4ad0d34..636d206 100644 > --- a/arch/powerpc/platforms/powernv/Makefile > +++ b/arch/powerpc/platforms/powernv/Makefile > @@ -1,9 +1,9 @@ > obj-y+= setup.o opal-takeover.o opal-wrappers.o > opal.o opal-async.o > obj-y+= opal-rtc.o opal-nvram.o opal-lpc.o > opal-flash.o > obj-y+= rng.o opal-elog.o opal-dump.o > opal-sysparam.o opal-sensor.o > -obj-y+= opal-msglog.o subcore.o subcore-asm.o > +obj-y+= opal-msglog.o subcore-asm.o > subcore-asm.o can also move down here as well ? > -obj-$(CONFIG_SMP)+= smp.o > +obj-$(CONFIG_SMP)+= smp.o subcore.o -- 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: net: netlink executing RO memory
On 06/05/2014 04:21 PM, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel I've stumbled on the following spew: > > [ 306.065161] kernel tried to execute NX-protected page - exploit attempt? > (uid: 0) > [ 306.067295] BUG: unable to handle kernel paging request at 880053b8fd08 Same issue reproduced multiple times with exactly the same trace, so I think that it rules out random memory corruption. Thanks, Sasha -- 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 00/13][V3] kexec: A new system call to allow in kernel loading
On 06/05/2014 04:04 PM, Vivek Goyal wrote: > On Wed, Jun 04, 2014 at 09:39:10PM +0200, Michael Kerrisk wrote: >> Vivek, >> >> As per Documentation/SubmitChecklist , please CC linux-api@ on patces >> that change the ABI/API. See >> https://www.kernel.org/doc/man-pages/linux-api-ml.html. > > Hi Michael, > > Sorry, I did not notice that. I will CC linux-api@ in next version of > patches in patches which introduce new systemcal.. > >> >> Also, is there some draft man page for this new system call? > > No, there is none yet. In fact I don't see a man page for old kexec > system call either kexec_load(). Is this not what you are meaning: http://man7.org/linux/man-pages/man2/kexec_load.2.html ? (It probably could be improved...) > Do you want me to write man page for this new syscall? These days, that's considered a desirable accompaniment to new syscall proposals. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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/1] rtmutex: Handle when top lock owner changes
On Fri, 6 Jun 2014, Thomas Gleixner wrote: > On Thu, 5 Jun 2014, Steven Rostedt wrote: > > On Wed, 4 Jun 2014 17:32:37 +0200 (CEST) > > Thomas Gleixner wrote: > > + /* > > +* When we dropped the spinlocks, if the owner of the lock we > > +* are currently processing changed since we chain walked > > +* to that lock, we are done with the chain walk. The previous > > +* owner was obviously running to release it. > > +*/ > > + if (lock && rt_mutex_owner(lock) != task) > > + goto out_unlock_pi; > > NO. You CANNOT derefernce lock after dropping the locks. It might be > gone already. The only information we can check is, whether @task changed the blocked on lock, really. 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 1/2] rtmutex: Handle deadlock detection smarter
On Thu, 5 Jun 2014, Steven Rostedt wrote: > On Thu, 05 Jun 2014 15:28:32 - > Thomas Gleixner wrote: > > > > @@ -1112,7 +1134,8 @@ int rt_mutex_start_proxy_lock(struct rt_ > > return 1; > > } > > > > - ret = task_blocks_on_rt_mutex(lock, waiter, task, detect_deadlock); > > + /* We enforce deadlock detection for futexes */ > > + ret = task_blocks_on_rt_mutex(lock, waiter, task, 1); > > Why bother with passing in detect_deadlock then? > > Same goes for rt_mutex_finish_proxy_lock(). Because that's part of the cleanup series to remove it and I did not want mix stuff here. -- 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 v3] ARM: fix debug prints relevant to PCI devices
As per PCIe spec, fast back-to-back transactions feature
is not applicable to PCIe devices. Hence, do not print
that fast back-to-back trasactions are disabled when
there is a PCIe device found on the bus
Signed-off-by: Vidya Sagar
---
v3:
* removed KERN_INFO from pr_info() which was not removed by mistake in previous
patch
v2:
* Modified has_pcie_dev type to bool and used pci_is_pcie() instead of
pci_pcie_cap()
* replaced printk with pr_info
arch/arm/kernel/bios32.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 17a26c1..fcf2581 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -290,6 +290,7 @@ void pcibios_fixup_bus(struct pci_bus *bus)
{
struct pci_dev *dev;
u16 features = PCI_COMMAND_SERR | PCI_COMMAND_PARITY |
PCI_COMMAND_FAST_BACK;
+ bool has_pcie_dev = 0;
/*
* Walk the devices on this bus, working out what we can
@@ -298,6 +299,8 @@ void pcibios_fixup_bus(struct pci_bus *bus)
list_for_each_entry(dev, >devices, bus_list) {
u16 status;
+ if (!has_pcie_dev)
+ has_pcie_dev = pci_is_pcie(dev);
pci_read_config_word(dev, PCI_STATUS, );
/*
@@ -354,9 +357,11 @@ void pcibios_fixup_bus(struct pci_bus *bus)
/*
* Report what we did for this bus
+* (only if the bus doesn't have even one PCIe device)
*/
- printk(KERN_INFO "PCI: bus%d: Fast back to back transfers %sabled\n",
- bus->number, (features & PCI_COMMAND_FAST_BACK) ? "en" : "dis");
+ if (!has_pcie_dev)
+ pr_info("PCI: bus%d: Fast back to back transfers %sabled\n",
+ bus->number, (features & PCI_COMMAND_FAST_BACK) ? "en"
: "dis");
}
EXPORT_SYMBOL(pcibios_fixup_bus);
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] rtmutex: Handle deadlock detection smarter
On Thu, 5 Jun 2014, Steven Rostedt wrote:
> On Thu, 05 Jun 2014 15:28:32 -
> Thomas Gleixner wrote:
>
> > Index: tip/kernel/locking/rtmutex.h
> > ===
> > --- tip.orig/kernel/locking/rtmutex.h
> > +++ tip/kernel/locking/rtmutex.h
> > @@ -21,6 +21,10 @@
> > #define debug_rt_mutex_unlock(l) do { } while (0)
> > #define debug_rt_mutex_init(m, n) do { } while (0)
> > #define debug_rt_mutex_deadlock(d, a ,l) do { } while (0)
> > -#define debug_rt_mutex_print_deadlock(w) do { } while (0)
> > #define debug_rt_mutex_detect_deadlock(w,d)(d)
> > #define debug_rt_mutex_reset_waiter(w) do { } while (0)
> > +
> > +static inline void debug_rt_mutex_print_deadlock(struct rt_mutex_waiter *w)
> > +{
> > + WARN(1, "rtmutex deadlock detected\n");
> > +}
> >
>
> The above is called directly in rt_mutex_start_proxy_lock(), and as it
> doesn't have a conditional where the DEBUG_RT_MUTEXES version does, I
> get a ton of these:
Crap, yes. Of course I had debug enabled :)
--
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/1] rtmutex: Handle when top lock owner changes
On Thu, 5 Jun 2014, Steven Rostedt wrote: > On Wed, 4 Jun 2014 17:32:37 +0200 (CEST) > Thomas Gleixner wrote: > + /* > + * When we dropped the spinlocks, if the owner of the lock we > + * are currently processing changed since we chain walked > + * to that lock, we are done with the chain walk. The previous > + * owner was obviously running to release it. > + */ > + if (lock && rt_mutex_owner(lock) != task) > + goto out_unlock_pi; NO. You CANNOT derefernce lock after dropping the locks. It might be gone already. 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 1/2] powerpc/powernv: include asm/smp.h to handle UP config
On 06/05/2014 08:51 PM, Shreyas B. Prabhu wrote: > Build throws following errors when CONFIG_SMP=n > arch/powerpc/platforms/powernv/setup.c: In function > ‘pnv_kexec_wait_secondaries_down’: > arch/powerpc/platforms/powernv/setup.c:179:4: error: implicit declaration of > function ‘get_hard_smp_processor_id’ > rc = opal_query_cpu_status(get_hard_smp_processor_id(i), > > The usage of get_hard_smp_processor_id() needs the declaration from > . The file setup.c includes , which in-turn > includes . However, includes > only on SMP configs and hence UP builds fail. > > Fix this by directly including in setup.c unconditionally. Can you please clean up the description in the commit message ? and also the first line in the commit message should mention that the patch is trying to fix a UP specific build failure. -- 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/1] Staging:tidspbridge Fix minor checkpatch.pl warning
On Fri, 2014-06-06 at 10:24 +0530, Adithya wrote:
> From: Adithya K
>
> Fixed checkpatch "WARNING: Missing a blank line after declarations"
[]
> diff --git a/drivers/staging/tidspbridge/gen/gh.c
> b/drivers/staging/tidspbridge/gen/gh.c
[]
> @@ -28,6 +28,7 @@ struct gh_node {
> struct gh_t_hash_tab {
> u32 val_size;
> DECLARE_HASHTABLE(hash_table, GH_HASH_ORDER);
> +
> u32 (*hash)(const void *key);
> bool (*match)(const void *key, const void *value);
> void (*delete)(void *key);
this one is a checkpatch defect.
--
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 RESEND 2/2] mem-hotplug: Introduce MMOP_OFFLINE to replace the hard coding -1.
In store_mem_state(), we have:
..
334 else if (!strncmp(buf, "offline", min_t(int, count, 7)))
335 online_type = -1;
..
355 case -1:
356 ret = device_offline(>dev);
357 break;
..
Here, "offline" is hard coded as -1.
This patch does the following renaming:
ONLINE_KEEP -> MMOP_ONLINE_KEEP
ONLINE_KERNEL -> MMOP_ONLINE_KERNEL
ONLINE_MOVABLE -> MMOP_ONLINE_MOVABLE
and introduce MMOP_OFFLINE = -1 to avoid hard coding.
Signed-off-by: Tang Chen
---
drivers/base/memory.c | 18 +-
include/linux/memory_hotplug.h | 9 +
mm/memory_hotplug.c| 9 ++---
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index fa664b9..904442c 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -294,7 +294,7 @@ static int memory_subsys_online(struct device *dev)
* attribute and need to set the online_type.
*/
if (mem->online_type < 0)
- mem->online_type = ONLINE_KEEP;
+ mem->online_type = MMOP_ONLINE_KEEP;
ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
@@ -326,22 +326,22 @@ store_mem_state(struct device *dev,
return ret;
if (sysfs_streq(buf, "online_kernel"))
- online_type = ONLINE_KERNEL;
+ online_type = MMOP_ONLINE_KERNEL;
else if (sysfs_streq(buf, "online_movable"))
- online_type = ONLINE_MOVABLE;
+ online_type = MMOP_ONLINE_MOVABLE;
else if (sysfs_streq(buf, "online"))
- online_type = ONLINE_KEEP;
+ online_type = MMOP_ONLINE_KEEP;
else if (sysfs_streq(buf, "offline"))
- online_type = -1;
+ online_type = MMOP_OFFLINE;
else {
ret = -EINVAL;
goto err;
}
switch (online_type) {
- case ONLINE_KERNEL:
- case ONLINE_MOVABLE:
- case ONLINE_KEEP:
+ case MMOP_ONLINE_KERNEL:
+ case MMOP_ONLINE_MOVABLE:
+ case MMOP_ONLINE_KEEP:
/*
* mem->online_type is not protected so there can be a
* race here. However, when racing online, the first
@@ -352,7 +352,7 @@ store_mem_state(struct device *dev,
mem->online_type = online_type;
ret = device_online(>dev);
break;
- case -1:
+ case MMOP_OFFLINE:
ret = device_offline(>dev);
break;
default:
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 4ca3d95..b4240cf 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -26,11 +26,12 @@ enum {
MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE = NODE_INFO,
};
-/* Types for control the zone type of onlined memory */
+/* Types for control the zone type of onlined and offlined memory */
enum {
- ONLINE_KEEP,
- ONLINE_KERNEL,
- ONLINE_MOVABLE,
+ MMOP_OFFLINE = -1,
+ MMOP_ONLINE_KEEP,
+ MMOP_ONLINE_KERNEL,
+ MMOP_ONLINE_MOVABLE,
};
/*
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index a650db2..6075f04 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -907,19 +907,22 @@ int __ref online_pages(unsigned long pfn, unsigned long
nr_pages, int online_typ
*/
zone = page_zone(pfn_to_page(pfn));
- if ((zone_idx(zone) > ZONE_NORMAL || online_type == ONLINE_MOVABLE) &&
+ if ((zone_idx(zone) > ZONE_NORMAL ||
+online_type == MMOP_ONLINE_MOVABLE) &&
!can_online_high_movable(zone)) {
unlock_memory_hotplug();
return -EINVAL;
}
- if (online_type == ONLINE_KERNEL && zone_idx(zone) == ZONE_MOVABLE) {
+ if (online_type == MMOP_ONLINE_KERNEL &&
+ zone_idx(zone) == ZONE_MOVABLE) {
if (move_pfn_range_left(zone - 1, zone, pfn, pfn + nr_pages)) {
unlock_memory_hotplug();
return -EINVAL;
}
}
- if (online_type == ONLINE_MOVABLE && zone_idx(zone) == ZONE_MOVABLE -
1) {
+ if (online_type == MMOP_ONLINE_MOVABLE &&
+ zone_idx(zone) == ZONE_MOVABLE - 1) {
if (move_pfn_range_right(zone, zone + 1, pfn, pfn + nr_pages)) {
unlock_memory_hotplug();
return -EINVAL;
--
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 v2] ARM: fix debug prints relevant to PCI devices
oops... I missed it somehow. I'll post a new patch. > -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Friday, June 06, 2014 9:53 AM > To: Vidya Sagar > Cc: li...@arm.linux.org.uk; bhelg...@google.com; > wangyij...@huawei.com; thierry.red...@gmail.com; > ja...@lakedaemon.net; will.dea...@arm.com; Stephen Warren; Krishna > Thota; sagar...@gmail.com; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH v2] ARM: fix debug prints relevant to PCI devices > > On Fri, 2014-06-06 at 00:17 +0530, Vidya Sagar wrote: > > * replaced printk with pr_info > [] > > diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c > [] > > @@ -354,9 +357,11 @@ void pcibios_fixup_bus(struct pci_bus *bus) > > > > /* > > * Report what we did for this bus > > +* (only if the bus doesn't have even one PCIe device) > > */ > > - printk(KERN_INFO "PCI: bus%d: Fast back to back transfers > %sabled\n", > > - bus->number, (features & PCI_COMMAND_FAST_BACK) ? > "en" : "dis"); > > + if (!has_pcie_dev) > > + pr_info(KERN_INFO "PCI: bus%d: Fast back to back transfers > %sabled\n", > > + bus->number, (features & > PCI_COMMAND_FAST_BACK) ? "en" : "dis"); > > when you convert to pr_ you need to remove the KERN_ > from the format string too. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] mem-hotplug: Introduce MMOP_OFFLINE to replace the hard coding -1.
On Fri, Jun 06, 2014 at 11:58:54AM +0800, Tang Chen wrote:
> In store_mem_state(), we have:
> ..
> 334 else if (!strncmp(buf, "offline", min_t(int, count, 7)))
> 335 online_type = -1;
> ..
> 355 case -1:
> 356 ret = device_offline(>dev);
> 357 break;
> ..
>
> Here, "offline" is hard coded as -1.
>
> This patch does the following renaming:
> ONLINE_KEEP -> MMOP_ONLINE_KEEP
> ONLINE_KERNEL -> MMOP_ONLINE_KERNEL
> ONLINE_MOVABLE -> MMOP_ONLINE_MOVABLE
>
> and introduce MMOP_OFFLINE = -1 to avoid hard coding.
>
> Signed-off-by: Tang Chen
> ---
> drivers/base/memory.c | 16
> include/linux/memory_hotplug.h | 9 +
> mm/memory_hotplug.c| 9 ++---
> 3 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index fa664b9..0f3fa8c 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -294,7 +294,7 @@ static int memory_subsys_online(struct device *dev)
>* attribute and need to set the online_type.
>*/
> if (mem->online_type < 0)
> - mem->online_type = ONLINE_KEEP;
> + mem->online_type = MMOP_ONLINE_KEEP;
>
> ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
>
> @@ -326,22 +326,22 @@ store_mem_state(struct device *dev,
> return ret;
>
> if (sysfs_streq(buf, "online_kernel"))
> - online_type = ONLINE_KERNEL;
> + online_type = MMOP_ONLINE_KERNEL;
> else if (sysfs_streq(buf, "online_movable"))
> - online_type = ONLINE_MOVABLE;
> + online_type = MMOP_ONLINE_MOVABLE;
> else if (sysfs_streq(buf, "online"))
> - online_type = ONLINE_KEEP;
> + online_type = MMOP_ONLINE_KEEP;
> else if (sysfs_streq(buf, "offline"))
> - online_type = -1;
> + online_type = MMOP_OFFLINE;
> else {
> ret = -EINVAL;
> goto err;
> }
>
> switch (online_type) {
> - case ONLINE_KERNEL:
> - case ONLINE_MOVABLE:
> - case ONLINE_KEEP:
> + case MMOP_ONLINE_KERNEL:
> + case MMOP_ONLINE_MOVABLE:
> + case MMOP_ONLINE_KEEP:
There is a `case -1' several lines below should have been converted.
> /*
>* mem->online_type is not protected so there can be a
>* race here. However, when racing online, the first
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 4ca3d95..b4240cf 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -26,11 +26,12 @@ enum {
> MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE = NODE_INFO,
> };
>
> -/* Types for control the zone type of onlined memory */
> +/* Types for control the zone type of onlined and offlined memory */
> enum {
> - ONLINE_KEEP,
> - ONLINE_KERNEL,
> - ONLINE_MOVABLE,
> + MMOP_OFFLINE = -1,
> + MMOP_ONLINE_KEEP,
> + MMOP_ONLINE_KERNEL,
> + MMOP_ONLINE_MOVABLE,
> };
>
> /*
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index a650db2..6075f04 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -907,19 +907,22 @@ int __ref online_pages(unsigned long pfn, unsigned long
> nr_pages, int online_typ
>*/
> zone = page_zone(pfn_to_page(pfn));
>
> - if ((zone_idx(zone) > ZONE_NORMAL || online_type == ONLINE_MOVABLE) &&
> + if ((zone_idx(zone) > ZONE_NORMAL ||
> + online_type == MMOP_ONLINE_MOVABLE) &&
> !can_online_high_movable(zone)) {
> unlock_memory_hotplug();
> return -EINVAL;
> }
>
> - if (online_type == ONLINE_KERNEL && zone_idx(zone) == ZONE_MOVABLE) {
> + if (online_type == MMOP_ONLINE_KERNEL &&
> + zone_idx(zone) == ZONE_MOVABLE) {
> if (move_pfn_range_left(zone - 1, zone, pfn, pfn + nr_pages)) {
> unlock_memory_hotplug();
> return -EINVAL;
> }
> }
> - if (online_type == ONLINE_MOVABLE && zone_idx(zone) == ZONE_MOVABLE -
> 1) {
> + if (online_type == MMOP_ONLINE_MOVABLE &&
> + zone_idx(zone) == ZONE_MOVABLE - 1) {
> if (move_pfn_range_right(zone, zone + 1, pfn, pfn + nr_pages)) {
> unlock_memory_hotplug();
> return -EINVAL;
> --
> 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/
[PATCH 1/1] Staging:tidspbridge Fix minor checkpatch.pl warning
From: Adithya K
Fixed checkpatch "WARNING: Missing a blank line after declarations"
Signed-off-by: Adithya Krishnamurthy
---
drivers/staging/tidspbridge/core/chnl_sm.c |1 +
drivers/staging/tidspbridge/core/io_sm.c |1 +
drivers/staging/tidspbridge/core/tiomap3430.c|2 ++
drivers/staging/tidspbridge/core/tiomap_io.c |2 ++
drivers/staging/tidspbridge/core/wdt.c |1 +
drivers/staging/tidspbridge/dynload/cload.c |7 +++
drivers/staging/tidspbridge/dynload/reloc.c |2 ++
drivers/staging/tidspbridge/gen/gh.c |1 +
drivers/staging/tidspbridge/pmgr/chnl.c |1 +
drivers/staging/tidspbridge/rmgr/dbdcd.c |1 +
drivers/staging/tidspbridge/rmgr/drv_interface.c |2 ++
drivers/staging/tidspbridge/rmgr/nldr.c |1 +
drivers/staging/tidspbridge/rmgr/node.c |2 ++
drivers/staging/tidspbridge/rmgr/proc.c |3 +++
14 files changed, 27 insertions(+)
diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c
b/drivers/staging/tidspbridge/core/chnl_sm.c
index 16fa346..c855992 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -486,6 +486,7 @@ int bridge_chnl_get_info(struct chnl_object *chnl_obj,
{
int status = 0;
struct chnl_object *pchnl = (struct chnl_object *)chnl_obj;
+
if (channel_info != NULL) {
if (pchnl) {
/* Return the requested information: */
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index c2829aa..42f94e1 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -249,6 +249,7 @@ int bridge_io_create(struct io_mgr **io_man,
int bridge_io_destroy(struct io_mgr *hio_mgr)
{
int status = 0;
+
if (hio_mgr) {
/* Free IO DPC object */
tasklet_kill(_mgr->dpc_tasklet);
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 8945b4e..bf952ef 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1057,6 +1057,7 @@ static int bridge_brd_mem_copy(struct bridge_dev_context
*dev_ctxt,
u32 total_bytes = ul_num_bytes;
u8 host_buf[BUFFERSIZE];
struct bridge_dev_context *dev_context = dev_ctxt;
+
while (total_bytes > 0 && !status) {
copy_bytes =
total_bytes > BUFFERSIZE ? BUFFERSIZE : total_bytes;
@@ -1094,6 +1095,7 @@ static int bridge_brd_mem_write(struct bridge_dev_context
*dev_ctxt,
struct bridge_dev_context *dev_context = dev_ctxt;
u32 ul_remain_bytes = 0;
u32 ul_bytes = 0;
+
ul_remain_bytes = ul_num_bytes;
while (ul_remain_bytes > 0 && !status) {
ul_bytes =
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c
b/drivers/staging/tidspbridge/core/tiomap_io.c
index f53ed98..2836467 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -176,6 +176,7 @@ int write_dsp_data(struct bridge_dev_context *dev_context,
struct cfg_hostres *resources = dev_context->resources;
int status = 0;
u32 base1, base2, base3;
+
base1 = OMAP_DSP_MEM1_SIZE;
base2 = OMAP_DSP_MEM2_BASE - OMAP_DSP_MEM1_BASE;
base3 = OMAP_DSP_MEM3_BASE - OMAP_DSP_MEM1_BASE;
@@ -229,6 +230,7 @@ int write_ext_dsp_data(struct bridge_dev_context
*dev_context,
u32 ul_shm_offset_virt = 0;
struct cfg_hostres *host_res = dev_context->resources;
bool trace_load = false;
+
temp_byte1 = 0x0;
temp_byte2 = 0x0;
diff --git a/drivers/staging/tidspbridge/core/wdt.c b/drivers/staging/tidspbridge/core/wdt.c
index c7ee467..b19f887 100644
--- a/drivers/staging/tidspbridge/core/wdt.c
+++ b/drivers/staging/tidspbridge/core/wdt.c
@@ -33,6 +33,7 @@ static struct dsp_wdt_setting dsp_wdt;
void dsp_wdt_dpc(unsigned long data)
{
struct deh_mgr *deh_mgr;
+
dev_get_deh_mgr(dev_get_first(), _mgr);
if (deh_mgr)
bridge_deh_notify(deh_mgr, DSP_WDTOVERFLOW, 0);
diff --git a/drivers/staging/tidspbridge/dynload/cload.c
b/drivers/staging/tidspbridge/dynload/cload.c
index 9d54744..83f2106 100644
--- a/drivers/staging/tidspbridge/dynload/cload.c
+++ b/drivers/staging/tidspbridge/dynload/cload.c
@@ -160,6 +160,7 @@ int dynamic_load_module(struct dynamic_loader_stream
*module,
if (!dl_state.dload_errcount) {
/* fix up entry point address */
unsigned sref = dl_state.dfile_hdr.df_entry_secn - 1;
+
if (sref < dl_state.allocated_secn_count)
dl_state.dfile_hdr.df_entrypt +=
Re: [PATCH] Documentation, intel_pstate: Add a description of the intel_pstate internal governors [v3]
On 5 June 2014 22:51, Prarit Bhargava wrote: > The current documentation is incomplete wrt the intel_pstate internal > governors. The confusion comes from the general use internal governors > which also use the names performance and powersave. This patch > differentiates between the two sets of governors. > > Cc: Viresh Kumar > Cc: Dirk Brandewie > Cc: Randy Dunlap > Cc: Russell King > Cc: Jesper Nilsson > Cc: Viresh Kumar > Cc: "David S. Miller" > Cc: Ramkumar Ramachandra > Cc: "Rafael J. Wysocki" > Cc: linux-...@vger.kernel.org > Signed-off-by: Prarit Bhargava > > [v2]: text update > [v3]: text update This will get into 'git logs' :(, you should have placed those below the --- on the next line. In case we are going to do a resend of this please change subject to: I have seen some commits where [v3] in $subject is pushed into the logs, but I am not sure if that's the right way. Why would we need to know which version went into the kernel? In case maintainer picked the wrong version we can simply check the diff.. cpufreq: documentation/intel_pstate: Add a description of the intel_pstate internal governors Anyway, I think Rafael might do these changes himself. So don't resend it unless he asks for.. > --- > Documentation/cpu-freq/governors.txt|2 +- > Documentation/cpu-freq/intel-pstate.txt |8 > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/cpu-freq/governors.txt > b/Documentation/cpu-freq/governors.txt > index 77ec215..c15aa75 100644 > --- a/Documentation/cpu-freq/governors.txt > +++ b/Documentation/cpu-freq/governors.txt > @@ -36,7 +36,7 @@ Contents: > 1. What Is A CPUFreq Governor? > == > > -Most cpufreq drivers (in fact, all except one, longrun) or even most > +Most cpufreq drivers (except the intel_pstate and longrun) or even most > cpu frequency scaling algorithms only offer the CPU to be set to one > frequency. In order to offer dynamic frequency scaling, the cpufreq > core must be able to tell these drivers of a "target frequency". So > diff --git a/Documentation/cpu-freq/intel-pstate.txt > b/Documentation/cpu-freq/intel-pstate.txt > index e742d21..7e9db8f 100644 > --- a/Documentation/cpu-freq/intel-pstate.txt > +++ b/Documentation/cpu-freq/intel-pstate.txt > @@ -9,6 +9,14 @@ assumed to implement internal governors by the cpufreq core. > All the > logic for selecting the current P state is contained within the > driver; no external governor is used by the cpufreq core. > > +The Intel P-state driver has two internal governors, performance and > +powersave. These governors differ from the generally used governors of the > +same name in the kernel. The internal performance governor sets the > +max_perf_pct and min_perf_pct to 100; that is, the governor selects the > +highest available P state to maximize the performance of the core. The > +internal powersave governor selects the appropriate P state based on the > +current load on the CPU. > + > Intel SandyBridge+ processors are supported. > > New sysfs files for controlling P state selection have been added to Otherwise looks good: Acked-by: Viresh 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/
Re: [PATCH 3.4 000/214] 3.4.92-stable review
On Thu, Jun 05, 2014 at 04:19:24PM -0700, Greg Kroah-Hartman wrote: > On Wed, Jun 04, 2014 at 09:16:03PM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.92 release. > > There are 214 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Jun 7 04:15:47 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.92-rc1.gz > > and the diffstat can be found below. > > Given the recent changes in this tree, I've released a -rc2 to handle > all of the updates.: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.92-rc1.gz > Presumably you mean kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.92-rc2.gz Same for 3.10 and 3.14. 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: Change in security maintainer for a few weeks
Quoting Greg KH (gre...@linuxfoundation.org): > On Thu, Jun 05, 2014 at 06:39:09PM -0400, Paul Moore wrote: > > On Thursday, June 05, 2014 11:59:11 PM Jiri Kosina wrote: > > > On Thu, 5 Jun 2014, Greg KH wrote: > > > > James has had to step back from doing kernel work for a few weeks, so > > > > I've offered to step up and handle the security patches to get shuttled > > > > to Linus for merging for a while. > > > > > > As exactly this (working with active contributors to help co-maintain the > > > subsystem) has been brought at the ksummit maling list, I am just curious > > > whether noone else actively working in that area was willing to step up? > > > > > > $ ./scripts/get_maintainer.pl --git -f security/ > > > James Morris (supporter:SECURITY SUBSYSTEM) > > >... > > > > > > If not, then I think this can be shown as a prime example why the problem > > > of "non-substituability" of many maintainers is actually real. > > > > Once several of us became aware that James was stepping away for a few > > weeks > > (I should mention this was not a planned absence and took most of us by > > surprise) we had a brief discussion off-list and several of us did offer to > > "step-up"; Serge had already created a repo and since he had pushed patches > > while James was away in the past it seemed a reasonable approach this time > > around. > > That's great, as the communication around this has not been very much > (an non-existant on the subsystem mailing list) I was not aware of it. > > If Serge wants to do this, and as he has been the stand-in for James in > the past, I have _no_ objection to this at all. > > Serge, feel free to resend your patches to Linus if he doesn't pick them > up in a few days, with the information that you are doing this in > James's absence for a while. Will do (and wil cc: lsm). > So, that was easy, I don't have to do this at all, great. > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: tegra: update comment for clarity
Tegra's driver got updated a bit (00917dd cpufreq: Tegra: implement intermediate frequency callbacks) and implements new 'intermediate freq' infrastructure of core. Above commit updated comments about when to call clk_prepare_enable(pll_x_clk) and Doug wasn't satisfied with those comments and said this: > The "Though when target-freq is intermediate freq, we don't need to > take this reference." makes me think that this function is actually > called when target-freq is intermediate freq. I don't think it is, > right? For better clarity just make that comment more explicit about when we call tegra_target_intermediate(). Wasn't sure if we actually need a commit for this, but anyway lets other decide if its worth enough :) Reported-by: Doug Anderson Signed-off-by: Viresh Kumar --- drivers/cpufreq/tegra-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c index a5fbc0a..48bc89b 100644 --- a/drivers/cpufreq/tegra-cpufreq.c +++ b/drivers/cpufreq/tegra-cpufreq.c @@ -73,7 +73,7 @@ static int tegra_target_intermediate(struct cpufreq_policy *policy, * off when we move the cpu off of it as enabling it again while we * switch to it from tegra_target() would take additional time. Though * when target-freq is intermediate freq, we don't need to take this -* reference. +* reference and so this routine isn't called at all. */ clk_prepare_enable(pll_x_clk); -- 2.0.0.rc2 -- 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 V5 2/2] cpufreq: Tegra: implement intermediate frequency callbacks
On 6 June 2014 01:21, Doug Anderson wrote: > The "Though when target-freq is intermediate freq, we don't need to > take this reference." makes me think that this function is actually > called when target-freq is intermediate freq. I don't think it is, > right? Yes, it isn't called for that combination. > I don't think that's a huge deal, though and code wise this looks good to me. I don't know either, let me send a patch for that and see what people think :) > Reviewed-by: Doug Anderson Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 06/16] arm: topology: Define TC2 sched energy and provide it to scheduler
On Thu, Jun 05, 2014 at 08:03:15AM -0700, Dirk Brandewie wrote: > > You can request a P state per core but the package does coordination at > a package level for the P state that will be used based on all requests. > This is due to the fact that most SKUs have a single VR and PLL. So > the highest P state wins. When a core goes idle it loses it's vote > for the current package P state and that cores clock it turned off. > You need to differentiate Turbo and non-Turbo. The highest P state wins? Not really. Actually, silicon supports indepdent non-Turbo pstate, but just not enabled. For Turbo, it basically depends on power budget of both core and gfx (because they share) for each core to get which Turbo point. > > > >And while APERF/MPERF allows observing what it did, its afaik, nigh on > >impossible to predict wtf its going to do, and therefore any such energy > >computation is going to be a PRNG at best. > > > >Now, given all that I'm not sure what we need that P-state driver for, > >so supposedly I'm missing something. > > intel_pstate tries to keep the core P state as low as possible to satisfy > the given load, so when various cores go idle the package P state can be > as low as possible. The big power win is a core going idle. > In terms of prediction, it is definitely can't be 100% right. But the performance of most workloads does scale with pstate (frequency), may not be linearly. So it is to some point predictable FWIW. And this is all governors and Intel_pstate's basic assumption. Thanks, Yuyang -- 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] UniCore32 update for v3.15-rc8
On Thu, Jun 05, 2014 at 01:30:32PM +0800, guanxuetao wrote: > Hi Linus, > > This is unicore32 pull request for v3.15-rc8. > > This pull request includes bugfixes to make unicore32 successfully build > under defconfig, > and some changes for allmodconfig (though not finished). > > Please pull tags/for-linus with following updates. I hope it works this time. > > Thanks for your patience. > > Xuetao Guan > > The following changes since commit cae61ba37b4c2672704cbd8a626fbd85be7e67d9: > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2014-06-02 > 18:16:41 -0700) > > are available in the git repository at: > > > git://github.com/gxt/linux.git tags/for-linus > > for you to fetch changes up to 8c76c188d498a85c5b1a1f10840da57129a108a0: > > unicore32: Remove ARCH_HAS_CPUFREQ config option (2014-06-05 08:36:03 +0800) > > > UniCore32 bug fixes for 3.15-rc8 > FWIW: Compile-tested-by: Guenter Roeck Guenter signature.asc Description: Digital signature
Re: [PATCH V5 1/2] cpufreq: add support for intermediate (stable) frequencies
On 6 June 2014 01:21, Doug Anderson wrote: > LGTM. Thanks for doing this! :) Thanks and yours welcome :) > Reviewed-by: Doug Anderson Thanks a lot. Its pushed by Rafael now :) -- 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: fix debug prints relevant to PCI devices
On Fri, 2014-06-06 at 00:17 +0530, Vidya Sagar wrote: > * replaced printk with pr_info [] > diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c [] > @@ -354,9 +357,11 @@ void pcibios_fixup_bus(struct pci_bus *bus) > > /* >* Report what we did for this bus > + * (only if the bus doesn't have even one PCIe device) >*/ > - printk(KERN_INFO "PCI: bus%d: Fast back to back transfers %sabled\n", > - bus->number, (features & PCI_COMMAND_FAST_BACK) ? "en" : "dis"); > + if (!has_pcie_dev) > + pr_info(KERN_INFO "PCI: bus%d: Fast back to back transfers > %sabled\n", > + bus->number, (features & PCI_COMMAND_FAST_BACK) ? "en" > : "dis"); when you convert to pr_ you need to remove the KERN_ from the format string too. -- 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: linux-next: build failure after merge of the net-next tree
On Thu, Jun 5, 2014 at 9:06 PM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/core/filter.c: In function 'convert_bpf_extensions': > net/core/filter.c:696:17: error: 'A_REG' undeclared (first use in this > function) >insn->a_reg = A_REG; > ^ > > Caused by my bad merge resolution :-( > > I applied this in the hope that it is correct (at least it builds): Thank you. It is correct. I think Dave was about to push the same fix to net-next. You're too fast :) > From: Stephen Rothwell > Date: Fri, 6 Jun 2014 14:00:07 +1000 > Subject: [PATCH] net: filter: merge fix up > > Signed-off-by: Stephen Rothwell > --- > net/core/filter.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/net/core/filter.c b/net/core/filter.c > index 7b46e4553c17..74dd87596257 100644 > --- a/net/core/filter.c > +++ b/net/core/filter.c > @@ -691,10 +691,7 @@ static bool convert_bpf_extensions(struct sock_filter > *fp, > *insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX); > #ifdef __BIG_ENDIAN_BITFIELD > insn++; > - > - insn->code = BPF_ALU | BPF_RSH | BPF_K; > - insn->a_reg = A_REG; > - insn->imm = 5; > + *insn = BPF_ALU32_IMM(BPF_RSH, BPF_REG_A, 5); > #endif > break; > > -- > 2.0.0 > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH ftrace/core 3/3] trace: Fix memory leak when new instance creation failed
On Fri, 06 Jun 2014 07:35:22 +0900
Yoshihiro YUNOMAE wrote:
> Current new_instance_create() implements just two fail paths for four
> allocation operations. So, it can induce memory leak if new instance
> creation failed. This patch fixes it by defining all fail paths and
> freeing allocated memories appropriately.
>
We don't need all the labels. The kfree() can handle NULL pointers.
Also, it's for a very unlikely case so we don't care about performance.
Here's the patch I'm adding:
-- Steve
>From 5ae90d9db393ac1b6189f8cb712ac5f526abd50e Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Red Hat)"
Date: Fri, 6 Jun 2014 00:01:46 -0400
Subject: [PATCH] tracing: Fix leak of ring buffer data when new instances
creation fails
Yoshihiro Yunomae reported that the ring buffer data for a trace
instance does not get properly cleaned up when it fails. He proposed
a patch that manually cleaned the data up and addad a bunch of labels.
The labels are not needed because all trace array is allocated with
a kzalloc which initializes it to 0 and all kfree()s can take a NULL
pointer and will ignore it.
Adding a new helper function free_trace_buffers() that can also take
null buffers to free the buffers that were allocated by
allocate_trace_buffers().
Link: http://lkml.kernel.org/r/20140605223522.32311.31664.stgit@yunodevel
Reported-by: Yoshihiro YUNOMAE
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index e29edee..26cfff3 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6232,6 +6232,25 @@ static int allocate_trace_buffers(struct trace_array
*tr, int size)
return 0;
}
+static void free_trace_buffers(struct trace_array *tr)
+{
+ if (!tr)
+ return;
+
+ if (tr->trace_buffer.buffer) {
+ ring_buffer_free(tr->trace_buffer.buffer);
+ tr->trace_buffer.buffer = NULL;
+ free_percpu(tr->trace_buffer.data);
+ }
+
+#ifdef CONFIG_TRACER_MAX_TRACE
+ if (tr->max_buffer.buffer) {
+ ring_buffer_free(tr->max_buffer.buffer);
+ tr->max_buffer.buffer = NULL;
+ }
+#endif
+}
+
static int new_instance_create(const char *name)
{
struct trace_array *tr;
@@ -6290,8 +6309,7 @@ static int new_instance_create(const char *name)
return 0;
out_free_tr:
- if (tr->trace_buffer.buffer)
- ring_buffer_free(tr->trace_buffer.buffer);
+ free_trace_buffers(tr);
free_cpumask_var(tr->tracing_cpumask);
kfree(tr->name);
kfree(tr);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the net-next tree
Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/core/filter.c: In function 'convert_bpf_extensions': net/core/filter.c:696:17: error: 'A_REG' undeclared (first use in this function) insn->a_reg = A_REG; ^ Caused by my bad merge resolution :-( I applied this in the hope that it is correct (at least it builds): From: Stephen Rothwell Date: Fri, 6 Jun 2014 14:00:07 +1000 Subject: [PATCH] net: filter: merge fix up Signed-off-by: Stephen Rothwell --- net/core/filter.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 7b46e4553c17..74dd87596257 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -691,10 +691,7 @@ static bool convert_bpf_extensions(struct sock_filter *fp, *insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX); #ifdef __BIG_ENDIAN_BITFIELD insn++; - - insn->code = BPF_ALU | BPF_RSH | BPF_K; - insn->a_reg = A_REG; - insn->imm = 5; + *insn = BPF_ALU32_IMM(BPF_RSH, BPF_REG_A, 5); #endif break; -- 2.0.0 -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
[PATCH v2 2/2] mem-hotplug: Introduce MMOP_OFFLINE to replace the hard coding -1.
In store_mem_state(), we have:
..
334 else if (!strncmp(buf, "offline", min_t(int, count, 7)))
335 online_type = -1;
..
355 case -1:
356 ret = device_offline(>dev);
357 break;
..
Here, "offline" is hard coded as -1.
This patch does the following renaming:
ONLINE_KEEP -> MMOP_ONLINE_KEEP
ONLINE_KERNEL -> MMOP_ONLINE_KERNEL
ONLINE_MOVABLE -> MMOP_ONLINE_MOVABLE
and introduce MMOP_OFFLINE = -1 to avoid hard coding.
Signed-off-by: Tang Chen
---
drivers/base/memory.c | 16
include/linux/memory_hotplug.h | 9 +
mm/memory_hotplug.c| 9 ++---
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index fa664b9..0f3fa8c 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -294,7 +294,7 @@ static int memory_subsys_online(struct device *dev)
* attribute and need to set the online_type.
*/
if (mem->online_type < 0)
- mem->online_type = ONLINE_KEEP;
+ mem->online_type = MMOP_ONLINE_KEEP;
ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
@@ -326,22 +326,22 @@ store_mem_state(struct device *dev,
return ret;
if (sysfs_streq(buf, "online_kernel"))
- online_type = ONLINE_KERNEL;
+ online_type = MMOP_ONLINE_KERNEL;
else if (sysfs_streq(buf, "online_movable"))
- online_type = ONLINE_MOVABLE;
+ online_type = MMOP_ONLINE_MOVABLE;
else if (sysfs_streq(buf, "online"))
- online_type = ONLINE_KEEP;
+ online_type = MMOP_ONLINE_KEEP;
else if (sysfs_streq(buf, "offline"))
- online_type = -1;
+ online_type = MMOP_OFFLINE;
else {
ret = -EINVAL;
goto err;
}
switch (online_type) {
- case ONLINE_KERNEL:
- case ONLINE_MOVABLE:
- case ONLINE_KEEP:
+ case MMOP_ONLINE_KERNEL:
+ case MMOP_ONLINE_MOVABLE:
+ case MMOP_ONLINE_KEEP:
/*
* mem->online_type is not protected so there can be a
* race here. However, when racing online, the first
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 4ca3d95..b4240cf 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -26,11 +26,12 @@ enum {
MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE = NODE_INFO,
};
-/* Types for control the zone type of onlined memory */
+/* Types for control the zone type of onlined and offlined memory */
enum {
- ONLINE_KEEP,
- ONLINE_KERNEL,
- ONLINE_MOVABLE,
+ MMOP_OFFLINE = -1,
+ MMOP_ONLINE_KEEP,
+ MMOP_ONLINE_KERNEL,
+ MMOP_ONLINE_MOVABLE,
};
/*
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index a650db2..6075f04 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -907,19 +907,22 @@ int __ref online_pages(unsigned long pfn, unsigned long
nr_pages, int online_typ
*/
zone = page_zone(pfn_to_page(pfn));
- if ((zone_idx(zone) > ZONE_NORMAL || online_type == ONLINE_MOVABLE) &&
+ if ((zone_idx(zone) > ZONE_NORMAL ||
+online_type == MMOP_ONLINE_MOVABLE) &&
!can_online_high_movable(zone)) {
unlock_memory_hotplug();
return -EINVAL;
}
- if (online_type == ONLINE_KERNEL && zone_idx(zone) == ZONE_MOVABLE) {
+ if (online_type == MMOP_ONLINE_KERNEL &&
+ zone_idx(zone) == ZONE_MOVABLE) {
if (move_pfn_range_left(zone - 1, zone, pfn, pfn + nr_pages)) {
unlock_memory_hotplug();
return -EINVAL;
}
}
- if (online_type == ONLINE_MOVABLE && zone_idx(zone) == ZONE_MOVABLE -
1) {
+ if (online_type == MMOP_ONLINE_MOVABLE &&
+ zone_idx(zone) == ZONE_MOVABLE - 1) {
if (move_pfn_range_right(zone, zone + 1, pfn, pfn + nr_pages)) {
unlock_memory_hotplug();
return -EINVAL;
--
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/
[PATCH v2 1/2] mem-hotplug: Avoid illegal state prefixed with legal state when changing state of memory_block.
We use the following command to online a memory_block:
echo online|online_kernel|online_movable >
/sys/devices/system/memory/memoryXXX/state
But, if we do the following:
echo online_fhsjkghfkd > /sys/devices/system/memory/memoryXXX/state
the block will also be onlined.
This is because the following code in store_mem_state() does not compare the
whole string,
but only the prefix of the string.
store_mem_state()
{
..
328 if (!strncmp(buf, "online_kernel", min_t(int, count, 13)))
Here, only compare the first 13 letters of the string. If we give
"online_kernelXX",
it will be recognized as online_kernel, which is incorrect.
329 online_type = ONLINE_KERNEL;
330 else if (!strncmp(buf, "online_movable", min_t(int, count, 14)))
We have the same problem here,
331 online_type = ONLINE_MOVABLE;
332 else if (!strncmp(buf, "online", min_t(int, count, 6)))
here,
(Here is more problematic. If we give online_movalbe, which is a typo of
online_movable,
it will be recognized as online without noticing the author.)
333 online_type = ONLINE_KEEP;
334 else if (!strncmp(buf, "offline", min_t(int, count, 7)))
and here.
335 online_type = -1;
336 else {
337 ret = -EINVAL;
338 goto err;
339 }
..
}
This patch fix this problem by using sysfs_streq() to compare the whole string.
Reported-by: Hu Tao
Signed-off-by: Tang Chen
---
change log v1 -> v2:
Following Andrew's suggestion, use sysfs_streq() to compare the whole
string
so that we can simplify the code.
---
---
drivers/base/memory.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bece691..fa664b9 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -325,13 +325,13 @@ store_mem_state(struct device *dev,
if (ret)
return ret;
- if (!strncmp(buf, "online_kernel", min_t(int, count, 13)))
+ if (sysfs_streq(buf, "online_kernel"))
online_type = ONLINE_KERNEL;
- else if (!strncmp(buf, "online_movable", min_t(int, count, 14)))
+ else if (sysfs_streq(buf, "online_movable"))
online_type = ONLINE_MOVABLE;
- else if (!strncmp(buf, "online", min_t(int, count, 6)))
+ else if (sysfs_streq(buf, "online"))
online_type = ONLINE_KEEP;
- else if (!strncmp(buf, "offline", min_t(int, count, 7)))
+ else if (sysfs_streq(buf, "offline"))
online_type = -1;
else {
ret = -EINVAL;
--
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/
[PATCH v2 0/2] Fix for memory online/offline.
These two patches does some fixes in memory online/offline process. Tang Chen (2): mem-hotplug: Avoid illegal state prefixed with legal state when changing state of memory_block. mem-hotplug: Introduce MMOP_OFFLINE to replace the hard coding -1. drivers/base/memory.c | 24 include/linux/memory_hotplug.h | 9 + mm/memory_hotplug.c| 9 ++--- 3 files changed, 23 insertions(+), 19 deletions(-) -- 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 ftrace/core 3/3] trace: Fix memory leak when new instance creation failed
On Fri, 06 Jun 2014 07:35:22 +0900
Yoshihiro YUNOMAE wrote:
> Current new_instance_create() implements just two fail paths for four
> allocation operations. So, it can induce memory leak if new instance
> creation failed. This patch fixes it by defining all fail paths and
> freeing allocated memories appropriately.
>
> Signed-off-by: Yoshihiro YUNOMAE
> Cc: Steven Rostedt
> Cc: Ingo Molnar
> Cc: linux-kernel@vger.kernel.org
> ---
> kernel/trace/trace.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 473eb68..bbd86d2 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -6277,7 +6277,7 @@ static int new_instance_create(const char *name)
> goto out_free_tr;
>
> if (!alloc_cpumask_var(>tracing_cpumask, GFP_KERNEL))
> - goto out_free_tr;
> + goto out_free_tr_name;
>
> cpumask_copy(tr->tracing_cpumask, cpu_all_mask);
>
> @@ -6291,16 +6291,16 @@ static int new_instance_create(const char *name)
> INIT_LIST_HEAD(>events);
>
> if (allocate_trace_buffers(tr, trace_buf_size) < 0)
> - goto out_free_tr;
> + goto out_free_cpumask_var;
>
> tr->dir = debugfs_create_dir(name, trace_instance_dir);
> if (!tr->dir)
> - goto out_free_tr;
> + goto out_free_trace_buffers;
>
> ret = event_trace_add_tracer(tr->dir, tr);
> if (ret) {
> debugfs_remove_recursive(tr->dir);
> - goto out_free_tr;
> + goto out_free_trace_buffers;
> }
>
> init_tracer_debugfs(tr, tr->dir);
> @@ -6311,18 +6311,23 @@ static int new_instance_create(const char *name)
>
> return 0;
>
> - out_free_tr:
> - if (tr->trace_buffer.buffer)
> - ring_buffer_free(tr->trace_buffer.buffer);
> + out_free_trace_buffers:
> + ring_buffer_free(tr->trace_buffer.buffer);
> + free_percpu(tr->trace_buffer.data);
> +#ifdef CONFIG_TRACER_MAX_TRACE
> + ring_buffer_free(tr->max_buffer.buffer);
> + free_percpu(tr->max_buffer.data);
> +#endif
I think we need a free_trace_buffer() that complements
allocate_trace_buffer().
-- Steve
> + out_free_cpumask_var:
> free_cpumask_var(tr->tracing_cpumask);
> + out_free_tr_name:
> kfree(tr->name);
> + out_free_tr:
> kfree(tr);
> -
> out_unlock:
> mutex_unlock(_types_lock);
>
> return ret;
> -
> }
>
> static int instance_delete(const char *name)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/core/filter.c between commit 0dcceabb0c1b ("net: filter: fix
SKF_AD_PKTTYPE extension on big-endian") from the net tree and commit
9739eef13c92 ("net: filter: make BPF conversion more readable") from
the net-next tree.
I fixed it up (not well, but see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/core/filter.c
index ab3c74e49f07,9de0c25323b4..
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -685,17 -684,7 +688,14 @@@ static bool convert_bpf_extensions(stru
if (insn->off < 0)
return false;
insn++;
-
- insn->code = BPF_ALU | BPF_AND | BPF_K;
- insn->a_reg = A_REG;
- insn->imm = PKT_TYPE_MAX;
+ *insn = BPF_ALU32_IMM(BPF_AND, BPF_REG_A, PKT_TYPE_MAX);
+#ifdef __BIG_ENDIAN_BITFIELD
+ insn++;
+
+ insn->code = BPF_ALU | BPF_RSH | BPF_K;
+ insn->a_reg = A_REG;
+ insn->imm = 5;
+#endif
break;
case SKF_AD_OFF + SKF_AD_IFINDEX:
signature.asc
Description: PGP signature
Re: [PATCH-next] mfd: ab8500: fix dt irq mapping
On Tue, Jun 3, 2014 at 4:21 AM, Linus Walleij wrote: > On Mon, Jun 2, 2014 at 6:27 PM, Grygorii Strashko > wrote: > >> The AD8500 defines itself as interrupt-controller in DT, >> but it doesn't assign DT node to IRQ domain when creates it. >> As result, of_irq_xx() helpers don't work because they can't >> find necessary IRQ domain. >> >> Hence, fix it by assigning AD8500 core device DT node to IRQ >> domain when it's created. >> >> This patch fixes STE u8500 Snowball boot failure reported by Kevin Hilman >> https://lkml.org/lkml/2014/5/27/624 >> >> Cc: Samuel Ortiz >> Cc: Lee Jones >> Cc: Rob Herring >> Cc: Grant Likely >> Cc: Thierry Reding >> Reported-and-tested-by: Kevin Hilman >> Signed-off-by: Grygorii Strashko > > Reviewed-by: Linus Walleij Anyone picking this one up? It's still broken in -next, and will be needed for v3.16. Kevin -- 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 ftrace/core 1/3] trace/event: Return error if ftrace_trace_arrays is empty list
On Fri, 06 Jun 2014 07:35:17 +0900 Yoshihiro YUNOMAE wrote: > ftrace_trace_arrays links global_trace.list. However, global_trace is not > added > to ftrace_trace_arrays if trace_alloc_buffers() failed. As the result, > ftrace_trace_arrays becomes empty list. If ftrace_trace_arrays is empty list, > current top_trace_array() returns invalid pointer. As the result, the kernel > can induce memory corruption or panic. > > Current implementation does not check whether ftrace_trace_arrays is empty > list or not. So, in this patch, if ftrace_trace_arrays is empty list, > top_trace_array() returns NULL. Moreover, this patch makes all functions > calling > top_trace_array() handle it appropriately. As I'm still working on some more patches for 3.16, I can add this. It's not that critical, because if global_array fails to allocate on boot up, lots of other things may also break. -- Steve > > Signed-off-by: Yoshihiro YUNOMAE > Cc: Steven Rostedt > Cc: Ingo Molnar > Cc: linux-kernel@vger.kernel.org > --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/xen-netback/netback.c between commit 59ae9fc67007
("xen-netback: Fix handling of skbs requiring too many slots") from the
net tree and commit e9ce7cb6b107 ("xen-netback: Factor queue-specific
data into queue struct") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/xen-netback/netback.c
index a160b4ef5ba0,49efff9b99f4..
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@@ -556,12 -548,18 +563,12 @@@ static void xenvif_add_frag_responses(s
}
}
- void xenvif_kick_thread(struct xenvif *vif)
-struct xenvif_rx_cb {
- int meta_slots_used;
-};
-
-#define XENVIF_RX_CB(skb) ((struct xenvif_rx_cb *)(skb)->cb)
-
+ void xenvif_kick_thread(struct xenvif_queue *queue)
{
- wake_up(>wq);
+ wake_up(>wq);
}
- static void xenvif_rx_action(struct xenvif *vif)
+ static void xenvif_rx_action(struct xenvif_queue *queue)
{
s8 status;
u16 flags;
signature.asc
Description: PGP signature
Re: Change in security maintainer for a few weeks
On Thu, 2014-06-05 at 22:52 +0300, Dmitry Kasatkin wrote: > On 5 June 2014 21:30, Greg KH wrote: > > Hi all, > > > > James has had to step back from doing kernel work for a few weeks, so > > I've offered to step up and handle the security patches to get shuttled > > to Linus for merging for a while. > > > > I'll take his git tree on kernel.org and push those to Linus for > > 3.16-rc1, as those look like they have had proper testing in linux-next. > > > > But there only seems to be 14 patches in there. Are there pending > > patches that people have been sending and need to get in besides those? > > > > thanks, > > > > Hi Greg, > > Mimi sent pull request to James last week without any response... > > But that is based on James' 3.14 tree.. > May be Mimi need to rebase and send pull request to you.. I'm really sorry Dmitry. Unlike the SELinux patches, the integrity patches didn't make it into linux-next. Based on Paul's suggestion, I'll request that the linux-integrity tree be added to the list of trees that are pulled directly into linux-next, instead of waiting for it to go in via the security tree. Mimi -- 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 2/2]: powerpc/perf: Adjust callchain based on DWARF debug info
Replace the arch_skip_callchain_idx() stub in Powerpc with code that
checks the DWARF debug information and identifies the callchain entry
to skip.
Callgraph before the patch:
14.67% 2234 sprintft libc-2.18.so [.] __random
|
--- __random
|
|--61.12%-- __random
| |
| |--97.15%-- rand
| | do_my_sprintf
| | main
| | generic_start_main.isra.0
| | __libc_start_main
| | 0x0
| |
| --2.85%-- do_my_sprintf
| main
| generic_start_main.isra.0
| __libc_start_main
| 0x0
|
--38.88%-- rand
|
|--94.01%-- rand
| do_my_sprintf
| main
| generic_start_main.isra.0
| __libc_start_main
| 0x0
|
--5.99%-- do_my_sprintf
main
generic_start_main.isra.0
__libc_start_main
0x0
Callgraph after the patch:
14.67% 2234 sprintft libc-2.18.so [.] __random
|
--- __random
|
|--95.93%-- rand
| do_my_sprintf
| main
| generic_start_main.isra.0
| __libc_start_main
| 0x0
|
--4.07%-- do_my_sprintf
main
generic_start_main.isra.0
__libc_start_main
0x0
TODO: For split-debug info objects like glibc, we can only determine
the call-frame-address only when both .eh_frame and .debug_info
sections are available. We should be able to determin the CFA
even without the .eh_frame section.
Fix suggested by Anton Blanchard.
Thanks to valuable input on DWARF debug information from Ulrich Weigand.
Reported-by: Maynard Johnson
Tested-by: Maynard Johnson
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v4]
Move Powerpc-specific code into a separate patch
Changelog[v3]
[Jiri Olsa] Rename function to arch_skip_callchain_idx() to be
consistent with behavior.
[Jiri Olsa] Add '__maybe_unused' tags for unused parameters.
Changelog[v2]:
Add missing dwfl_end()
Fix merge conflicts due to some unwind code
tools/perf/arch/powerpc/util/skip-callchain-idx.c | 251 -
1 file changed, 246 insertions(+), 5 deletions(-)
diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index 7350c36..a7c23a4 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -16,10 +16,251 @@
#include "util/thread.h"
#include "util/callchain.h"
-/* Stub for now */
-int arch_skip_callchain_idx(struct machine *machine __maybe_unused,
- struct thread *thread __maybe_unused,
- struct ip_callchain *chain __maybe_unused)
+/*
+ * When saving the callchain on Power, the kernel conservatively saves
+ * excess entries in the callchain. A few of these entries are needed
+ * in some cases but not others. If the unnecessary entries are not
+ * ignored, we end up with duplicate arcs in the call-graphs. Use
+ * DWARF debug information to skip over any unnecessary callchain
+ * entries.
+ *
+ * See function header for arch_adjust_callchain() below for more details.
+ *
+ * The libdwfl code in this file is based on code from elfutils
+ * (libdwfl/argp-std.c, libdwfl/tests/addrcfi.c, etc).
+ */
+static char *debuginfo_path;
+
+static const Dwfl_Callbacks offline_callbacks = {
+ .debuginfo_path = _path,
+ .find_debuginfo = dwfl_standard_find_debuginfo,
+ .section_address = dwfl_offline_section_address,
+};
+
+
+/*
+ * Use the DWARF expression for the Call-frame-address and determine
+ * if return address is in LR and if a new frame was allocated.
+ */
+static int check_return_reg(int ra_regno, Dwarf_Frame *frame)
+{
+ Dwarf_Op ops_mem[2];
+ Dwarf_Op dummy;
+ Dwarf_Op *ops =
+ size_t nops;
+ int result;
+
+ result = dwarf_frame_register(frame, ra_regno, ops_mem, , );
+ if (result < 0) {
+
[PATCH v4 1/2]: Allow architectures to skip a callchain entry
The kernel code in Powerpc conservatively saves excess information in
the callchain. While most entries are often needed, under some specific
conditions, some of the entries are redundant and cause duplicate arcs
in the call-graph.
Eg: the value in the link register (LR) is needed only when it holds
the return address of a function. At other times it must be ignored.
In the next commit, we will use the application's DWARF debug information
to identify and skip over the redundant entries.
To minimize performance impact on other architectures, define and use two
following static inline interfaces:
arch_skip_callchain_idx()
next_callchain_ip()
Reported-by: Maynard Johnson
Tested-by: Maynard Johnson
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v4]
Move Powerpc-specific code to separate patch
[Jiri Olsa] Minimize performance impact to other architectures
include/uapi/linux/perf_event.h |2 ++
tools/perf/arch/powerpc/Makefile |1 +
tools/perf/arch/powerpc/util/skip-callchain-idx.c | 25 ++
tools/perf/config/Makefile|4 +++
tools/perf/util/callchain.h | 37 +
tools/perf/util/machine.c | 11 +++---
6 files changed, 76 insertions(+), 4 deletions(-)
create mode 100644 tools/perf/arch/powerpc/util/skip-callchain-idx.c
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index e3fc8f0..b671abf 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -719,6 +719,8 @@ enum perf_callchain_context {
PERF_CONTEXT_GUEST_KERNEL = (__u64)-2176,
PERF_CONTEXT_GUEST_USER = (__u64)-2560,
+ PERF_CONTEXT_IGNORE = (__u64)-3840,
+
PERF_CONTEXT_MAX= (__u64)-4095,
};
diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 744e629..b92219b 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -3,3 +3,4 @@ PERF_HAVE_DWARF_REGS := 1
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
endif
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/skip-callchain-idx.o
diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
new file mode 100644
index 000..7350c36
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -0,0 +1,25 @@
+/*
+ * Use DWARF Debug information to skip unnecessary callchain entries.
+ *
+ * Copyright (C) 2014 Sukadev Bhattiprolu, IBM Corporation.
+ * Copyright (C) 2014 Ulrich Weigand, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include
+#include
+#include
+
+#include "util/thread.h"
+#include "util/callchain.h"
+
+/* Stub for now */
+int arch_skip_callchain_idx(struct machine *machine __maybe_unused,
+ struct thread *thread __maybe_unused,
+ struct ip_callchain *chain __maybe_unused)
+{
+ return -1;
+}
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 729bbdf..8d1417d 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -48,6 +48,10 @@ ifneq ($(ARCH),$(filter $(ARCH),x86 arm))
NO_LIBDW_DWARF_UNWIND := 1
endif
+ifeq ($(ARCH),powerpc)
+ CFLAGS += -DHAVE_SKIP_CALLCHAIN_IDX
+endif
+
ifeq ($(LIBUNWIND_LIBS),)
NO_LIBUNWIND := 1
else
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 8f84423..57d3d33 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -176,4 +176,41 @@ static inline void callchain_cursor_snapshot(struct
callchain_cursor *dest,
dest->first = src->curr;
dest->nr -= src->pos;
}
+
+/*
+ * Some architectures (eg: Powerpc), check DWARF debug information
+ * and skip a specific callchain entry in the @chain->ips[] list.
+ *
+ * Return index of the entry to skip or -1 to not skip any entry.
+ */
+#ifdef HAVE_SKIP_CALLCHAIN_IDX
+extern int
+arch_skip_callchain_idx(struct machine *machine __maybe_unused,
+ struct thread *thread __maybe_unused,
+ struct ip_callchain *chain __maybe_unused);
+#else
+static inline int
+arch_skip_callchain_idx(struct machine *machine __maybe_unused,
+ struct thread *thread __maybe_unused,
+ struct ip_callchain *chain __maybe_unused)
+{
+ return -1;
+}
+#endif
+
+static inline u64
+next_callchain_ip(struct ip_callchain *chain,
+ enum chain_order order,
+ int idx,
+ int skip_idx __maybe_unused)
+{
+
Re: [PATCH 1/1] rtmutex: Handle when top lock owner changes
On Wed, 4 Jun 2014 17:32:37 +0200 (CEST)
Thomas Gleixner wrote:
> On Tue, 3 Jun 2014, Steven Rostedt wrote:
> > On Fri, 23 May 2014 09:30:10 -0500
> > "Brad Mouring" wrote:
> > > /* Deadlock detection */
> > > if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
> > > + /*
> > > + * If the prio chain has changed out from under us, set the task
> > > + * to the current owner of the lock in the current waiter and
> > > + * continue walking the prio chain
> > > + */
> > > + if (rt_mutex_owner(lock) && rt_mutex_owner(lock) != task) {
>
> No, sorry. That's wrong.
>
> Your change wreckages the rt_mutex_owner(lock) == top_task test
> simply because in that case:
>
>(rt_mutex_owner(lock) && rt_mutex_owner(lock) != task)
>
> evaluates to true.
I'm not so sure that's true. Because if this is a deadlock in the case
that rt_mutex_owner(lock) == top_task, then task == top_task should
also be true.
>
> Aside of that we need to figure out whether the lock chain changed
> while we dropped the locks even in the non dead lock case. Otherwise
> we follow up the wrong chain there.
>
> T0 blocked on L1 held by T1
> T1 blocked on L2 held by T2
> T2 blocked on L3 held by T3
>
> So we walk the chain and do:
>
>T1 -> L2 -> T2
>
> Now here we get preempted.
>
> T3 releases L3
> T2 gets L3
> T2 drops L3 and L2
> T2 blocks on L4 held by T4
> T4 blocked on L5 held by T5
>
> So we happily boost T4 and T5. Not what we really want to do.
>
> Nasty, isn't it ?
As I stated before, it just wastes cycles. But looking at both your
next_lock code and this, I'm thinking we can simply break out if we
find that rt_mutex_owner(lock) != task. Because that means when we let
go of the locks, the current lock we are going up was released and
retaken. That would mean the chain walk should stop. It's similar to
the next lock being what we expected.
Perhaps something like this:
---
kernel/locking/rtmutex.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
Index: linux-rt.git/kernel/locking/rtmutex.c
===
--- linux-rt.git.orig/kernel/locking/rtmutex.c 2014-06-05 23:00:56.197855465
-0400
+++ linux-rt.git/kernel/locking/rtmutex.c 2014-06-05 23:14:44.164414857
-0400
@@ -284,7 +284,7 @@
struct rt_mutex_waiter *orig_waiter,
struct task_struct *top_task)
{
- struct rt_mutex *lock;
+ struct rt_mutex *lock = orig_lock;
struct rt_mutex_waiter *waiter, *top_waiter = orig_waiter;
int detect_deadlock, ret = 0, depth = 0;
unsigned long flags;
@@ -322,6 +322,16 @@
*/
raw_spin_lock_irqsave(>pi_lock, flags);
+ /*
+* When we dropped the spinlocks, if the owner of the lock we
+* are currently processing changed since we chain walked
+* to that lock, we are done with the chain walk. The previous
+* owner was obviously running to release it.
+*/
+ if (lock && rt_mutex_owner(lock) != task)
+ goto out_unlock_pi;
+
+
waiter = task->pi_blocked_on;
/*
* Check whether the end of the boosting chain has been
--
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 1/1] remove redundant compare, cmpxchg already does it
On Thu, Jun 5, 2014 at 3:22 AM, Peter Zijlstra wrote:
> On Wed, Jun 04, 2014 at 04:56:50PM -0400, Andev wrote:
>> On Wed, Jun 4, 2014 at 4:38 PM, Pranith Kumar wrote:
>> > remove a redundant comparision
>> >
>> > Signed-off-by: Pranith Kumar
>> > ---
>> > kernel/locking/rwsem-xadd.c | 3 +--
>> > 1 file changed, 1 insertion(+), 2 deletions(-)
>> >
>> > diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
>> > index 1f99664b..6f8bd3c 100644
>> > --- a/kernel/locking/rwsem-xadd.c
>> > +++ b/kernel/locking/rwsem-xadd.c
>> > @@ -249,8 +249,7 @@ static inline bool rwsem_try_write_lock(long count,
>> > struct rw_semaphore *sem)
>> > {
>> > if (!(count & RWSEM_ACTIVE_MASK)) {
>> > /* try acquiring the write lock */
>> > -if (sem->count == RWSEM_WAITING_BIAS &&
>> > -cmpxchg(>count, RWSEM_WAITING_BIAS,
>> > +if (cmpxchg(>count, RWSEM_WAITING_BIAS,
>> > RWSEM_ACTIVE_WRITE_BIAS) == RWSEM_WAITING_BIAS) {
>>
>> This was mainly done to avoid the cost of a cmpxchg in case where they
>> are not equal. Not sure if it really makes a difference though.
>
> It does, a cache hot cmpxchg instruction is 24 cycles (as is pretty much
> any other LOCKed ins, as measured on my WSM-EP), not to mention that
> cmpxchg is a RMW so it needs to grab the cacheline in exclusive mode.
>
> A read, which allows the cacheline to remain in shared, and non LOCKed
> ops are way faster.
Ok, this means that we need to use more of such swaps on highly
contended paths. As Davidlohr suggested later on, I think it would be
a good idea to document this and add an API.
--
Pranith
--
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: autosleep suspend too frquent problem
Hi Pavel, This is kernel log from a Android phone: <6>[ 7262.353794] PM: suspend exit 2014-05-07 21:19:17.438320072 UTC <6>[ 7262.353820] PM: suspend entry 2014-05-07 21:19:17.438348353 UTC <6>[ 7264.822367] PM: suspend exit 2014-05-07 21:19:19.906892259 UTC <6>[ 7264.822391] PM: suspend entry 2014-05-07 21:19:19.906919447 UTC <6>[ 7266.100346] PM: suspend exit 2014-05-07 21:19:21.184872206 UTC <6>[ 7266.100371] PM: suspend entry 2014-05-07 21:19:21.184899342 UTC <6>[ 7268.650852] PM: suspend exit 2014-05-07 21:19:23.73538 UTC <6>[ 7268.650876] PM: suspend entry 2014-05-07 21:19:23.735404393 UTC <6>[ 7269.023665] PM: suspend exit 2014-05-07 21:19:26.398622725 UTC <6>[ 7269.023691] PM: suspend entry 2014-05-07 21:19:26.398651787 UTC <6>[ 7269.232675] PM: suspend exit 2014-05-07 21:19:28.959217201 UTC <6>[ 7269.250878] PM: suspend entry 2014-05-07 21:19:28.977414076 UTC <6>[ 7269.256004] PM: suspend exit 2014-05-07 21:19:28.982547202 UTC <6>[ 7269.260040] PM: suspend entry 2014-05-07 21:19:28.986580588 UTC <6>[ 7269.265169] PM: suspend exit 2014-05-07 21:19:28.991711785 UTC <6>[ 7269.269311] PM: suspend entry 2014-05-07 21:19:28.995851004 UTC <6>[ 7270.410962] PM: suspend exit 2014-05-07 21:19:30.137503920 UTC <6>[ 7270.410986] PM: suspend entry 2014-05-07 21:19:30.137529389 UTC <6>[ 7272.970123] PM: suspend exit 2014-05-07 21:19:32.696662461 UTC <6>[ 7272.973330] PM: suspend entry 2014-05-07 21:19:32.699869909 UTC <6>[ 7275.534527] PM: suspend exit 2014-05-07 21:19:35.261069387 UTC <6>[ 7275.534551] PM: suspend entry 2014-05-07 21:19:35.261095846 UTC <6>[ 7275.556227] PM: suspend exit 2014-05-07 21:19:35.282769491 UTC <6>[ 7275.579152] PM: suspend entry 2014-05-07 21:19:35.305686210 UTC <6>[ 7275.822618] PM: suspend exit 2014-05-07 21:19:37.918187092 UTC <6>[ 7275.822644] PM: suspend entry 2014-05-07 21:19:37.918215894 UTC <6>[ 7276.122721] PM: suspend exit 2014-05-07 21:19:40.479243344 UTC <6>[ 7276.122745] PM: suspend entry 2014-05-07 21:19:40.479269125 UTC <6>[ 7278.578212] PM: suspend exit 2014-05-07 21:19:42.934733395 UTC <6>[ 7278.578237] PM: suspend entry 2014-05-07 21:19:42.934761520 UTC You can see there is several times suspend / resume status change Form 2014-05-07 21:19:28. 959217201 to 2014-05-07 21:19:28.995851004 There is also some suspend fail in this log , the suspend return -EBUSY Because of driver wake up system during suspend process . During our power test , suspend frequently like this will consume more Power , because it will suspend/resume lots of Devices . Why don't we make a time window to make sure there is no more than 1 time suspend during the time window ? I remember Android use wakelock for suspend in older linux kernel , The wakelock will make some time window check to make sure Not suspend frequently , could autosleep also add this ? Thanks -Original Message- From: Pavel Machek [mailto:pa...@ucw.cz] Sent: Thursday, June 05, 2014 9:51 PM To: Wang, Yalin Cc: 'Ulf Hansson'; linux...@vger.kernel.org; len.br...@intel.com; r...@sisk.pl; linux-kernel@vger.kernel.org; linux-mmc Subject: Re: autosleep suspend too frquent problem On Thu 2014-06-05 14:51:41, Wang, Yalin wrote: > Hi > > Thanks for your clarification. > > One problem is the sd card driver itself . > > In addition, I also think kernel's autosleep.c module Have problem > too. > It just test wake up count ,if the count is zero, then enter suspend. > > This will result in frequent suspend / resume problems sometimes, It > is not acceptable, I think also need to be fixed to Avoid this special > scenario . Android phones pretty much want to sleep very very often. But if you think there's coding bug in there, let us know.. Pavel > Thanks > > > -Original Message- > From: Ulf Hansson [mailto:ulf.hans...@linaro.org] > Sent: Wednesday, June 04, 2014 5:53 AM > To: Pavel Machek > Cc: Wang, Yalin; len.br...@intel.com; r...@sisk.pl; > linux...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-mmc > Subject: Re: autosleep suspend too frquent problem > > On 3 June 2014 14:01, Pavel Machek wrote: > > Hi! > > > > > >> I found sd card sometimes are damaged/ destroyed On our devices . > >> And seems it is caused by kernel's frequently suspend/resume, > >> Because during suspend/resume, the driver will suspend/resume > >> sdcard Very frequently, this will damaged the sdcard sometimes, and > >> the damage is not recoverable .. > >> > >> Sometimes kernel will enter suspend and exit suspend very > >> frequently, Especially when the system is in idle, but some driver > >> is not idle, And it will wake up the system by irq frequently. > >> By our power test result, if system enter suspend /resume very > >> frequently, Will consume more power , because it will enable > >> /disable many devices During a short time . > >> > >> I make a patch to prevent the system to enter suspend/resume state > >> More than one time
Re: [patch 1/2] rtmutex: Handle deadlock detection smarter
On Thu, 05 Jun 2014 15:28:32 -
Thomas Gleixner wrote:
> Index: tip/kernel/locking/rtmutex.h
> ===
> --- tip.orig/kernel/locking/rtmutex.h
> +++ tip/kernel/locking/rtmutex.h
> @@ -21,6 +21,10 @@
> #define debug_rt_mutex_unlock(l) do { } while (0)
> #define debug_rt_mutex_init(m, n)do { } while (0)
> #define debug_rt_mutex_deadlock(d, a ,l) do { } while (0)
> -#define debug_rt_mutex_print_deadlock(w) do { } while (0)
> #define debug_rt_mutex_detect_deadlock(w,d) (d)
> #define debug_rt_mutex_reset_waiter(w) do { } while (0)
> +
> +static inline void debug_rt_mutex_print_deadlock(struct rt_mutex_waiter *w)
> +{
> + WARN(1, "rtmutex deadlock detected\n");
> +}
>
The above is called directly in rt_mutex_start_proxy_lock(), and as it
doesn't have a conditional where the DEBUG_RT_MUTEXES version does, I
get a ton of these:
[ 27.192428] WARNING: CPU: 1 PID: 1013 at
/home/rostedt/work/git/linux-rt.git/kernel/locking/rtmutex.h:29
rt_mutex_start_proxy_lock+0x89/0xc0()
[ 27.205212] rtmutex deadlock detected
[ 27.208901] Modules linked in: lockd bnep bluetooth nf_conntrack_ipv4
ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv4 nf_defrag_ipv6 xt_state
ip6table_filter nf_conntrack ip6_table
s snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
snd_hda_controller snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm
x86_pkg_temp_thermal hp_wmi
tpm_infineon snd_timer rfkill i2c_i801 lpc_ich coretemp sparse_keymap wmi
mfd_core tpm_tis tpm snd soundcore serio_raw microcode pcspkr uinput i915
i2c_algo_bit e1000e drm_kms_hel
per ptp crc32c_intel drm pps_core i2c_core video sunrpc
[ 27.262062] CPU: 1 PID: 1013 Comm: threaded-ml Tainted: GW
3.15.0-rc8-test+ #292
[ 27.270531] Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS
K01 v02.05 05/07/2012
[ 27.279504] 001d 8800c7bc3c48 816884fd
88011ea4ef68
[ 27.287008] 8800c7bc3c98 8800c7bc3c88 8106f28c
8800c7bc3c78
[ 27.294519] 8800c795a8b0 8800c890bd40
c9000476e7f0
[ 27.302018] Call Trace:
[ 27.304491] [] dump_stack+0x4f/0x7c
[ 27.309643] [] warn_slowpath_common+0x8c/0xc0
[ 27.315678] [] warn_slowpath_fmt+0x46/0x50
[ 27.321461] [] rt_mutex_start_proxy_lock+0x89/0xc0
[ 27.327921] [] futex_requeue+0x507/0x840
[ 27.333504] [] do_futex+0x2e6/0xb80
[ 27.338660] [] ? unmap_region+0xea/0x110
[ 27.344257] [] ? get_parent_ip+0x11/0x50
[ 27.349876] [] ? preempt_count_add+0x5d/0xb0
[ 27.355816] [] ? get_parent_ip+0x11/0x50
[ 27.361404] [] ? __this_cpu_preempt_check+0x13/0x20
[ 27.367947] [] ? __percpu_counter_add+0x93/0xd0
[ 27.374161] [] SyS_futex+0x142/0x1a0
[ 27.379403] [] ? __audit_syscall_exit+0x200/0x280
[ 27.385776] [] system_call_fastpath+0x16/0x1b
[ 27.391797] ---[ end trace 438aec68793ded61 ]---
[ 27.396483] [ cut here ]
-- 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: [Regression] commit 8a4aeec8d(libata/ahci: accommodate tag ordered controllers)
On Fri, 2014-06-06 at 09:47 +0800, Ming Lei wrote:
> Hi Tejun,
>
> On Thu, Jun 5, 2014 at 9:41 PM, Tejun Heo wrote:
> > Hello,
> >
> > (cc'ing ahci_xgene folks)
> >
> > On Thu, Jun 05, 2014 at 09:24:04PM +0800, Ming Lei wrote:
> >> On Thu, Jun 5, 2014 at 9:12 PM, Dan Williams
> >> wrote:
> >> > On Thu, Jun 5, 2014 at 1:53 AM, Ming Lei wrote:
> >> >> Hi Dan and Tejun,
> >> >>
> >> >> Looks the commit 8a4aeec8d(libata/ahci: accommodate tag ordered
> >> >> controllers) causes below sata failure[1] on APM AHCI controller.
> >> >>
> >> >> And the error does disappear after reverting the commit.
> >> >
> >> > Can you give some more details about the workload and the disk? What
> >> > is the APM AHCI?
> >>
> >> The commit causes the APM arm64 based system not bootable, and not
> >> special workload, just when mounting rootfs or reading init files.
> >>
> >> APM AHCI:
> >> drivers/ata/ahci_xgene.c
> >
> > Urgh... so, the controller can't handle tags allocated in round-robin
> > instead of lowest-first? Ming, can you please test with different
> > controllers / disks / ssds and see whether the problem stays with the
> > controller? Loc, can you guys please look into it so that at least
> > the next revision hardware can fix the issue?
>
> The problem has been observed on several apm arm64 boards
> with different disks.
>
> >
> > Provided that the tag allocation itself isn't broken, which isn't too
> > likely given the lack of bug reports on other controllers, we'll need
> > to blacklist ahci_xgene somehow. Either disable NCQ support on it or
> > implement an alternative lowest-first tag allocation for it. If this
> > actually is the controller freaking out about tags allocated in a
> > different order, I'm not sure how much confidence we can put in its
> > NCQ implementation tho and it might be a better idea to simply plug
> > NCQ support on it until we understand the details of the problem.
> >
> > So, something like the following? Ming, can you please verify whether
> > the following makes the machine boot again?
>
> Looks the problem still persists after applying your patch of disabling
> NCQ.
How about the following patch?
8<-
libata: allow xgene-ahci to opt-out of tag ordered submission
From: Dan Williams
Ming Lei reports:
"Looks the commit 8a4aeec8d(libata/ahci: accommodate tag ordered
controllers) causes below sata failure[1] on APM AHCI controller.
And the error does disappear after reverting the commit.
ata4.00: exception Emask 0x40 SAct 0xff00 SErr 0x800 action 0x6 frozen
ata4: SError: { HostInt }
ata4.00: failed command: READ FPDMA QUEUED
ata4.00: cmd 60/08:40:e0:a4:88/00:00:04:00:00/40 tag 8 ncq 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x44 (timeout)"
Maintain tag ordered submission as the default, but allow xgene-ahci to
continue with the old behavior.
Reported-by: Ming Lei
Signed-off-by: Dan Williams
---
drivers/ata/ahci_xgene.c |1 +
drivers/ata/libata-core.c | 42 +++---
drivers/ata/libata.h |2 ++
include/linux/libata.h|1 +
4 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 77c89bf171f1..9be069f5f58a 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -300,6 +300,7 @@ static struct ata_port_operations xgene_ahci_ops = {
.host_stop = xgene_ahci_host_stop,
.hardreset = xgene_ahci_hardreset,
.read_id = xgene_ahci_read_id,
+ .qc_new = ata_qc_new_fifo_order,
};
static const struct ata_port_info xgene_ahci_port_info = {
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 943cc8b83e59..dd554354791f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -83,6 +83,7 @@ const struct ata_port_operations ata_base_port_ops = {
.error_handler = ata_std_error_handler,
.sched_eh = ata_std_sched_eh,
.end_eh = ata_std_end_eh,
+ .qc_new = ata_qc_new_tag_order,
};
const struct ata_port_operations sata_port_ops = {
@@ -4784,14 +4785,17 @@ void swap_buf_le16(u16 *buf, unsigned int buf_words)
}
/**
- * ata_qc_new - Request an available ATA command, for queueing
+ * ata_qc_new_tag_order - Request an available ATA command, for queueing
* @ap: target port
*
+ * Accomodates controllers that issue commands in tag order rather
+ * than FIFO order (Intel AHCI).
+ *
* LOCKING:
* None.
*/
-static struct ata_queued_cmd *ata_qc_new(struct ata_port *ap)
+struct ata_queued_cmd *ata_qc_new_tag_order(struct ata_port *ap)
{
struct ata_queued_cmd *qc = NULL;
unsigned int i, tag;
@@ -4819,6 +4823,38 @@ static struct ata_queued_cmd *ata_qc_new(struct ata_port
*ap)
}
/**
+ * ata_qc_new_fifo_order - Request an available ATA command, for queueing
+ * @ap: target port
RE: [PATCH 1/1] [SCSI] Fix a bug in deriving the FLUSH_TIMEOUT from the basic I/O timeout
> -Original Message-
> From: Mike Christie [mailto:micha...@cs.wisc.edu]
> Sent: Thursday, June 5, 2014 6:33 PM
> To: KY Srinivasan
> Cc: James Bottomley; linux-kernel@vger.kernel.org; a...@canonical.com;
> de...@linuxdriverproject.org; h...@infradead.org; linux-
> s...@vger.kernel.org; oher...@suse.com; gre...@linuxfoundation.org;
> jasow...@redhat.com
> Subject: Re: [PATCH 1/1] [SCSI] Fix a bug in deriving the FLUSH_TIMEOUT
> from the basic I/O timeout
>
> On 06/04/2014 12:15 PM, KY Srinivasan wrote:
> >
> >
> >> -Original Message-
> >> From: James Bottomley [mailto:jbottom...@parallels.com]
> >> Sent: Wednesday, June 4, 2014 10:02 AM
> >> To: KY Srinivasan
> >> Cc: linux-kernel@vger.kernel.org; a...@canonical.com;
> >> de...@linuxdriverproject.org; h...@infradead.org; linux-
> >> s...@vger.kernel.org; oher...@suse.com; gre...@linuxfoundation.org;
> >> jasow...@redhat.com
> >> Subject: Re: [PATCH 1/1] [SCSI] Fix a bug in deriving the
> >> FLUSH_TIMEOUT from the basic I/O timeout
> >>
> >> On Wed, 2014-06-04 at 09:33 -0700, K. Y. Srinivasan wrote:
> >>> Commit ID: 7e660100d85af860e7ad763202fff717adcdaacd added code to
> >>> derive the FLUSH_TIMEOUT from the basic I/O timeout. However, this
> >>> patch did not use the basic I/O timeout of the device. Fix this bug.
> >>>
> >>> Signed-off-by: K. Y. Srinivasan
> >>> ---
> >>> drivers/scsi/sd.c |4 +++-
> >>> 1 files changed, 3 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index
> >>> e9689d5..54150b1 100644
> >>> --- a/drivers/scsi/sd.c
> >>> +++ b/drivers/scsi/sd.c
> >>> @@ -832,7 +832,9 @@ static int sd_setup_write_same_cmnd(struct
> >>> scsi_device *sdp, struct request *rq)
> >>>
> >>> static int scsi_setup_flush_cmnd(struct scsi_device *sdp, struct
> >>> request *rq) {
> >>> - rq->timeout *= SD_FLUSH_TIMEOUT_MULTIPLIER;
> >>> + int timeout = sdp->request_queue->rq_timeout;
> >>> +
> >>> + rq->timeout = (timeout * SD_FLUSH_TIMEOUT_MULTIPLIER);
> >>
> >> Could you share where you found this to be a problem? It looks like
> >> a bug in block because all inbound requests being prepared should
> >> have a timeout set, so block would be the place to fix it.
> >
> > Perhaps; what I found was that the value in rq->timeout was 0 coming
> > into this function and thus multiplying obviously has no effect.
> >
>
> I think you are right. We hit this problem because we are doing:
>
> scsi_request_fn -> blk_peek_request -> sd_prep_fn ->
> scsi_setup_flush_cmnd.
>
> At this time request->timeout is zero so the multiplication does nothing. See
> how sd_setup_write_same_cmnd will set the request->timeout at this time.
>
> Then in scsi_request_fn we do:
>
> scsi_request_fn -> blk_start_request -> blk_add_timer.
>
> At this time it will set the request->timeout if something like req block pc
> users (like scsi_execute() or block/scsi_ioctl.c) or the write same code
> mentioned above have not set the timeout.
I don't think this is a recent change. Prior to this commit, we were setting
the timeout
value in this function; it just happened to be a different constant unrelated
to the I/O
timeout.
K. Y
>
>
--
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: blk-mq: bitmap tag: performance degradation?
On 2014-06-05 20:35, Ming Lei wrote: On Fri, Jun 6, 2014 at 9:55 AM, Jens Axboe wrote: On 2014-06-05 17:33, Ming Lei wrote: On Fri, Jun 6, 2014 at 1:17 AM, Jens Axboe wrote: On 06/05/2014 08:16 AM, Ming Lei wrote: On Thu, Jun 5, 2014 at 10:03 PM, Jens Axboe wrote: On 2014-06-05 08:01, Alexander Gordeev wrote: On Wed, Jun 04, 2014 at 08:18:42AM -0600, Jens Axboe wrote: A null_blk test is the absolute best case for percpu_ida, since there are enough tags and everything is localized. The above test is more useful for testing blk-mq than any real world application of the tagging. I've done considerable testing on both 2 and 4 socket (32 and 64 CPUs) and bitmap tagging is better in a much wider range of applications. This includes even high tag depth devices like nvme, and more normal ranges like mtip32xx and scsi-mq setups. Just for the record: bitmap tags on a 48 CPU box with NVMe device indeed shows almost the same performance/cache rate as the stock kernel. Thanks for confirming. It's one of the dangers of null_blk, it's not always a very accurate simulation of what a real device will do. I think it's mostly a completion side thing, would be great with a small device that supported msi-x and could be used as an irq trigger :-) Maybe null_blk at IRQ_TIMER mode is more close to a real device, and I guess the result may be different with mode IRQ_NONE/IRQ_SOFTIRQ. It'd be closer in behavior, but the results might then be skewed by hitting the timer way too hard. And it'd be a general slowdown, again possibly skewing it. But I haven't tried with the timer completion, to see if that yields more accurate modelling for this test, so it might actually be a lot better. My test on a 16core VM(host: 2 sockets, 16core): 1, bitmap tag allocation(3.15-rc7-next): - softirq mode: 759K IOPS - timer mode: 409K IOPS 2, percpu_ida allocation(3.15-rc7) - softirq mode: 1116K IOPS - timer mode: 411K IOPS It's hard to say if this is close, or whether we are just timer bound at that point. You are right, my previous test should be timer bound, but it should be eased by increasing timer period. I do the test again with increasing parameter of completion_nsec to 235000 from default 1: 1, nullblk(timer mode)3.15-rc7: - each fio cpu utilization: 80% ~ 90% - 860K IOPS 2, nullbk(timer mode)3.15-rc7-next - each fio cpu utilization: 70~80% - 940K IOPS Then bitmap based allocation can be observed to be a bit better than percpu ida. That's more inline with the real device testing I did. If tags are plenty, it's a wash between the two. But once you exceed 50% utilization, percpu_ida starts to degrade, and in some cases very badly. This is especially apparent on bigger 2 socket, or 4 socket boxes. -- Jens Axboe -- 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: blk-mq: bitmap tag: performance degradation?
On Fri, Jun 6, 2014 at 9:55 AM, Jens Axboe wrote: > On 2014-06-05 17:33, Ming Lei wrote: >> >> On Fri, Jun 6, 2014 at 1:17 AM, Jens Axboe wrote: >>> >>> On 06/05/2014 08:16 AM, Ming Lei wrote: On Thu, Jun 5, 2014 at 10:03 PM, Jens Axboe wrote: > > On 2014-06-05 08:01, Alexander Gordeev wrote: >> >> >> On Wed, Jun 04, 2014 at 08:18:42AM -0600, Jens Axboe wrote: >>> >>> >>> A null_blk test is the absolute best case for percpu_ida, since >>> there are enough tags and everything is localized. The above test is >>> more useful for testing blk-mq than any real world application of >>> the tagging. >>> >>> I've done considerable testing on both 2 and 4 socket (32 and 64 >>> CPUs) and bitmap tagging is better in a much wider range of >>> applications. This includes even high tag depth devices like nvme, >>> and more normal ranges like mtip32xx and scsi-mq setups. >> >> >> >> Just for the record: bitmap tags on a 48 CPU box with NVMe device >> indeed shows almost the same performance/cache rate as the stock >> kernel. > > > > Thanks for confirming. It's one of the dangers of null_blk, it's not > always > a very accurate simulation of what a real device will do. I think it's > mostly a completion side thing, would be great with a small device that > supported msi-x and could be used as an irq trigger :-) Maybe null_blk at IRQ_TIMER mode is more close to a real device, and I guess the result may be different with mode IRQ_NONE/IRQ_SOFTIRQ. >>> >>> >>> It'd be closer in behavior, but the results might then be skewed by >>> hitting the timer way too hard. And it'd be a general slowdown, again >>> possibly skewing it. But I haven't tried with the timer completion, to >>> see if that yields more accurate modelling for this test, so it might >>> actually be a lot better. >> >> >> My test on a 16core VM(host: 2 sockets, 16core): >> >> 1, bitmap tag allocation(3.15-rc7-next): >> - softirq mode: 759K IOPS >> - timer mode: 409K IOPS >> >> 2, percpu_ida allocation(3.15-rc7) >> - softirq mode: 1116K IOPS >> - timer mode: 411K IOPS > > > It's hard to say if this is close, or whether we are just timer bound at > that point. You are right, my previous test should be timer bound, but it should be eased by increasing timer period. I do the test again with increasing parameter of completion_nsec to 235000 from default 1: 1, nullblk(timer mode)3.15-rc7: - each fio cpu utilization: 80% ~ 90% - 860K IOPS 2, nullbk(timer mode)3.15-rc7-next - each fio cpu utilization: 70~80% - 940K IOPS Then bitmap based allocation can be observed to be a bit better than percpu ida. Thanks, -- Ming Lei -- 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 07/13] kexec: Implementation of new syscall kexec_file_load
On Thu, Jun 05, 2014 at 04:17:32PM -0400, Vivek Goyal wrote:
> I think everything is already available in "struct kimage *image". So
> I don't have to pass all these separately. I think I will remove all
> these extra parameters and expect arch function to retrieve all that
> from "struct kimage *image".
Sounds good.
> I guess I was trying to make "struct kimage" mostly opaque to arch
> functions.
Sure, of course. The question is, is it really worth it at the price
of having a lot of args. And you're passing struct kimage to arch_*
functions anyway.
...
> It is obivious that we are freeing memory but what was not obivious to
> me that I already copied contents of these buffers in a seaparate memory
> region (segment), hence I am able to free it. So I would like to keep
> comment there.
Ok.
> > > +
> > > + result = -ENOMEM;
> > > + image->control_code_page = kimage_alloc_control_pages(image,
> > > +get_order(KEXEC_CONTROL_PAGE_SIZE));
> > > + if (!image->control_code_page) {
> > > + pr_err("Could not allocate control_code_buffer\n");
> >
> > Might wanna define pr_fmt when using the pr_* things fo the first time
> > in this file.
>
> Hmm
>
> I see that printk.h already provides a definition is pr_fmt is not
> defined. So that means I shouldn't have to define pr_fmt() before I
> use pr_*?
>
> #ifndef pr_fmt
> #define pr_fmt(fmt) fmt
> #endif
Yep, so you could do
#undef pr_fmt
#define pr_fmt(fmt) "kexec: "
or you can do the standard
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Just look around the tree for examples, there's plenty.
> > This test looks strange: according to it, kexec_file_load has to always
> > be called with both KEXEC_FILE_UNLOAD and KEXEC_FILE_ON_CRASH set.
>
> I think this test says that "flags" has to be some combination of valid
> flags and superset is in KEXEC_FILE_FLAGS.
>
> So user can pass only KEXEC_FILE_ON_CRASH.
> flags = 0x0002
> KEXEC_FILE_FLAGS = 0x0x0003
> flags & KEXEC_FILE_FLAGS = 0x0002 = flags.
Bah, ignore me - I got confused, sorry.
> > > + kbuf->buf_align = max(buf_align, PAGE_SIZE);
> > > + kbuf->buf_min = buf_min;
> > > + kbuf->buf_max = buf_max;
> > > + kbuf->top_down = top_down;
> > > +
> > > + /* Walk the RAM ranges and allocate a suitable range for the buffer */
> > > + walk_system_ram_res(0, -1, kbuf, walk_ram_range_callback);
> > > +
> > > + /*
> > > + * If range could be found successfully, it would have incremented
> > > + * the nr_segments value.
> > > + */
> > > + new_nr_segments = image->nr_segments;
> > > +
> > > + /* A suitable memory range could not be found for buffer */
> > > + if (new_nr_segments == nr_segments)
> > > + return -EADDRNOTAVAIL;
> >
> > Right, why don't you check walk_system_ram_res's retval? If it is != 0,
> > i.e. walk_ram_range_callback gives a 1 on "success", you can drop this
> > way of checking whether finding a new range succeeded.
>
> In last version when I had ELF header support, I was checking for return
> code 1 at one place and you had not liked that.
>
> Anyway, I am thinking that problem here is that walk_* variants use
> return code of called function to decide whether to continue looping
> or not. I think these are two independent activities. Pass a boolean
> to called function which should be set to false if callee wants to
> stop the loop.
>
> That way, callee can pass both errors and success without having to
> worry about loop. And callee can return 0 to represent success and
> negative error code to represent error.
But why? It should be caller's responsibility to deal with the errors.
If it encounters one, it either decides to stop looping or not.
In any case, you don't need a second bool arg to pass around.
If you want to make it more explicit, you could do
#define RES_OK 0
#define RES_ERR 1
#define RES_STOP2
("RES" for resource :-)) and signal what to do by returning one of those
return values. Or?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
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] hwmon: add support for Sensirion SHTC1 sensor
On Thu, Jun 05, 2014 at 03:24:19PM -0700, Tomas Pop wrote: > From: Tomas Pop > > Add support for Sensirion SHTC1 and compatible temperature and humidity > sensors. > > Signed-off-by: Tomas Pop Applied to hwmon-next. Thanks for your patience! 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: blk-mq: bitmap tag: performance degradation?
On Fri, Jun 6, 2014 at 9:55 AM, Jens Axboe wrote: > On 2014-06-05 17:33, Ming Lei wrote: >> >> On Fri, Jun 6, 2014 at 1:17 AM, Jens Axboe wrote: >>> >>> On 06/05/2014 08:16 AM, Ming Lei wrote: On Thu, Jun 5, 2014 at 10:03 PM, Jens Axboe wrote: > > On 2014-06-05 08:01, Alexander Gordeev wrote: >> >> >> On Wed, Jun 04, 2014 at 08:18:42AM -0600, Jens Axboe wrote: >>> >>> >>> A null_blk test is the absolute best case for percpu_ida, since >>> there are enough tags and everything is localized. The above test is >>> more useful for testing blk-mq than any real world application of >>> the tagging. >>> >>> I've done considerable testing on both 2 and 4 socket (32 and 64 >>> CPUs) and bitmap tagging is better in a much wider range of >>> applications. This includes even high tag depth devices like nvme, >>> and more normal ranges like mtip32xx and scsi-mq setups. >> >> >> >> Just for the record: bitmap tags on a 48 CPU box with NVMe device >> indeed shows almost the same performance/cache rate as the stock >> kernel. > > > > Thanks for confirming. It's one of the dangers of null_blk, it's not > always > a very accurate simulation of what a real device will do. I think it's > mostly a completion side thing, would be great with a small device that > supported msi-x and could be used as an irq trigger :-) Maybe null_blk at IRQ_TIMER mode is more close to a real device, and I guess the result may be different with mode IRQ_NONE/IRQ_SOFTIRQ. >>> >>> >>> It'd be closer in behavior, but the results might then be skewed by >>> hitting the timer way too hard. And it'd be a general slowdown, again >>> possibly skewing it. But I haven't tried with the timer completion, to >>> see if that yields more accurate modelling for this test, so it might >>> actually be a lot better. >> >> >> My test on a 16core VM(host: 2 sockets, 16core): >> >> 1, bitmap tag allocation(3.15-rc7-next): >> - softirq mode: 759K IOPS >> - timer mode: 409K IOPS >> >> 2, percpu_ida allocation(3.15-rc7) >> - softirq mode: 1116K IOPS >> - timer mode: 411K IOPS > > > It's hard to say if this is close, or whether we are just timer bound at > that point. > > What other parameters did you load null_blk with (unmber of queues, queue > depth)? depth: 256, submit queues: 1 Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the drm-intel-fixes tree
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build
(x86_64 allmodconfig) failed like this:
drivers/gpu/drm/i915/intel_fbdev.c: In function 'intel_fb_initial_config':
drivers/gpu/drm/i915/intel_fbdev.c:392:4: error: implicit declaration of
function 'drm_get_connector_name' [-Werror=implicit-function-declaration]
DRM_DEBUG_KMS("using first mode listed on connector %s\n",
^
This is just the error I reported yesterday against the drm and
drm-intel trees, but migrated to the drm-intel-fixes tree. Your -fixes
tree shoudl really only contain stuff that depend on Linus' trees ...
but here it include all of yesterday's drm tree as well.
I have used the drm-intel-fixes tree from next-20140605 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH v3] perf: fix kernel panic when parsing user space CS saved in pt_regs
From: Zhang Yanmin ChangeLog V3: Keep rsp pointing to pt_regs before sysexit. ChangeLog V2: Before sysexit, perf NMI might arrive. There is still a race. Here we change rsp to keep it pointing to pt_regs->orig_ax. In addition, after sti, before sysexit, an irq might arrives. That causes more chances for perf NMI to jump in. We hit a kernel panic when running perf to collect some performance data. kenel is x86_64 and user space apps are 32bit. BUG: unable to handle kernel NULL pointer dereference at 0004 IP: [] get_segment_base+0x71/0xc0 PGD 6c65f067 PUD 0 Oops: [#1] PREEMPT SMP Modules linked in: <...> CPU: 1 PID: 304 Comm: Binder_2 Tainted: GW O 3.10.20-263902-g184bfbc-dirty #14 task: 8800764dc300 ti: 88006c6e8000 task.ti: 88006c6e8000 RIP: 0010:[] [] get_segment_base+0x71/0xc0 RSP: 0018:^X8007ea87b98 EFLAGS: 00010092 RAX: 0024 RBX: RCX: RDX: RSI: RDI: 0009 RBP: 88007ea87ba8 R08: 83143b3c R09: 831848a8 R10: R11: 001bf2d8 R12: R13: 88006c6e9fd8 R14: 88006c6e9f58 R15: 8800764dc300 FS: () GS:88007ea8(006b) knlGS:f704add0 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 0004 CR3: 76588000 CR4: 0^P1007e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Stack: 88005f266c00 88007ea87c18 82013cac 88007ea87d58 0016fe4704a0 01a7 88007ea87ef8 88005f266c00 88007ea87ef8 8800!e07b400 88005f266c00 Call Trace: [] perf_callchain_user+0x15c/0x240 [] perf_callchain+0x134/0x180 [] ? local_clock+0x47/0x60 [] perf_prepare_sample+0x1bb/0x240 [] __perf_event_overflow+0x147/0x230 [] ? x86_perf_event_set_period+0xd8/0x150 [] perf_event_overflow+0x14/0x20 [] intel_pmu_handle_irq+0x1c2/0x270 [] ? call_softirq+0x30/0x30 [] perf_event_nmi_handler+0x21/0x30 [] nmi_handle.isr!.1+0x59/0x=0 [] default_do_nmi+0x58/0x240 [] do_nmi+0xb8/0xf0 [|ffgf828aebe7>] end_repeat_nmi+0x1e/0x2e [] ? call_softirq+0x30/0x30 [] ? call_softirq+0x30/0x30 [] ? call_softirq+0x30/0x30 Basically, ia32 uses sysenter to start system calls. sysexit_from_sys_call=>trace_hardirqs_on_thunk. Before calling, sysexit_from_sys_call already pops up pt_regs, then trace_hardirqs_on_thunk would reuse pt_regs space. If perf NMI happens here, perf might use a bad pt_regs. The patch fixes it by keeping rsp pointing to pt_regs. Signed-off-by: Zhang Yanmin Signed-off-by: Liu Shuox --- arch/x86/ia32/ia32entry.S | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index 4299eb0..d2f905b 100644 --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -172,15 +172,16 @@ sysexit_from_sys_call: andl $~0x200,EFLAGS-R11(%rsp) movl RIP-R11(%rsp),%edx /* User %eip */ CFI_REGISTER rip,rdx - RESTORE_ARGS 0,24,0,0,0,0 - xorq%r8,%r8 + RESTORE_ARGS 0,-ARG_SKIP,0,0,0,0 + movqEFLAGS-R11(%rsp),%r8/* rflags */ + movqRSP-R11(%rsp),%rcx /* User %esp */ xorq%r9,%r9 xorq%r10,%r10 xorq%r11,%r11 - popfq_cfi + pushq_cfi %r8 /*CFI_RESTORE rflags*/ - popq_cfi %rcx /* User %esp */ - CFI_REGISTER rsp,rcx + popfq_cfi + xorq%r8,%r8 TRACE_IRQS_ON ENABLE_INTERRUPTS_SYSEXIT32 -- 1.8.3.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: blk-mq: bitmap tag: performance degradation?
On 2014-06-05 17:33, Ming Lei wrote: On Fri, Jun 6, 2014 at 1:17 AM, Jens Axboe wrote: On 06/05/2014 08:16 AM, Ming Lei wrote: On Thu, Jun 5, 2014 at 10:03 PM, Jens Axboe wrote: On 2014-06-05 08:01, Alexander Gordeev wrote: On Wed, Jun 04, 2014 at 08:18:42AM -0600, Jens Axboe wrote: A null_blk test is the absolute best case for percpu_ida, since there are enough tags and everything is localized. The above test is more useful for testing blk-mq than any real world application of the tagging. I've done considerable testing on both 2 and 4 socket (32 and 64 CPUs) and bitmap tagging is better in a much wider range of applications. This includes even high tag depth devices like nvme, and more normal ranges like mtip32xx and scsi-mq setups. Just for the record: bitmap tags on a 48 CPU box with NVMe device indeed shows almost the same performance/cache rate as the stock kernel. Thanks for confirming. It's one of the dangers of null_blk, it's not always a very accurate simulation of what a real device will do. I think it's mostly a completion side thing, would be great with a small device that supported msi-x and could be used as an irq trigger :-) Maybe null_blk at IRQ_TIMER mode is more close to a real device, and I guess the result may be different with mode IRQ_NONE/IRQ_SOFTIRQ. It'd be closer in behavior, but the results might then be skewed by hitting the timer way too hard. And it'd be a general slowdown, again possibly skewing it. But I haven't tried with the timer completion, to see if that yields more accurate modelling for this test, so it might actually be a lot better. My test on a 16core VM(host: 2 sockets, 16core): 1, bitmap tag allocation(3.15-rc7-next): - softirq mode: 759K IOPS - timer mode: 409K IOPS 2, percpu_ida allocation(3.15-rc7) - softirq mode: 1116K IOPS - timer mode: 411K IOPS It's hard to say if this is close, or whether we are just timer bound at that point. What other parameters did you load null_blk with (unmber of queues, queue depth)? -- Jens Axboe -- 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: ima_mmap_file returning 0 to userspace as mmap result.
On Thu, Jun 05, 2014 at 09:49:29PM -0400, Mimi Zohar wrote: > > > > > There's no mention of this return value in the man page, so I dug > > > > > into the kernel code, and it appears that we do.. > > > > > > > > > > sys_mmap > > > > > vm_mmap_pgoff > > > > > security_mmap_file > > > > > ima_file_mmap <- returns 0 if not PROT_EXEC > > > > > > > > > > and then the 0 gets propagated up as a retval all the way to > > userspace. > > > > > > I just realised that this affects even kernels with CONFIG_IMA unset, > > > because there we just do 'return 0' unconditionally. > > > > > > Also, it appears that kernels with CONFIG_SECURITY unset will also > > > return a zero for the same reason. > > > > Hang on, I was misreading that whole security_mmap_file ret handling code. > > There's something else at work here. I'll dig and get a reproducer. > > According to security.h, it should return 0 if permission is granted. > If IMA is not enabled, it should also return 0. What exactly is the > problem? Still digging. I managed to get this to reproduce constantly last night, but no luck today. From re-reading the code though, I think IMA/lsm isn't the problem. Dave -- 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: ima_mmap_file returning 0 to userspace as mmap result.
On Thu, 2014-06-05 at 12:20 -0400, Dave Jones wrote: > On Thu, Jun 05, 2014 at 11:56:58AM -0400, Dave Jones wrote: > > On Thu, Jun 05, 2014 at 06:40:36AM +0200, Michael Kerrisk (man-pages) > wrote: > > > On 06/05/2014 01:31 AM, Dave Jones wrote: > > > > I just noticed that trinity was freaking out in places when mmap was > > > > returning zero. This surprised me, because I had the mmap_min_addr > > > > sysctl set to 64k, so it wasn't a MAP_FIXED mapping that did it. > > > > > > > > There's no mention of this return value in the man page, so I dug > > > > into the kernel code, and it appears that we do.. > > > > > > > > sys_mmap > > > > vm_mmap_pgoff > > > > security_mmap_file > > > > ima_file_mmap <- returns 0 if not PROT_EXEC > > > > > > > > and then the 0 gets propagated up as a retval all the way to > userspace. > > > > I just realised that this affects even kernels with CONFIG_IMA unset, > > because there we just do 'return 0' unconditionally. > > > > Also, it appears that kernels with CONFIG_SECURITY unset will also > > return a zero for the same reason. > > Hang on, I was misreading that whole security_mmap_file ret handling code. > There's something else at work here. I'll dig and get a reproducer. According to security.h, it should return 0 if permission is granted. If IMA is not enabled, it should also return 0. What exactly is the problem? thanks, Mimi -- 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: [Regression] commit 8a4aeec8d(libata/ahci: accommodate tag ordered controllers)
Hi Tejun,
On Thu, Jun 5, 2014 at 9:41 PM, Tejun Heo wrote:
> Hello,
>
> (cc'ing ahci_xgene folks)
>
> On Thu, Jun 05, 2014 at 09:24:04PM +0800, Ming Lei wrote:
>> On Thu, Jun 5, 2014 at 9:12 PM, Dan Williams
>> wrote:
>> > On Thu, Jun 5, 2014 at 1:53 AM, Ming Lei wrote:
>> >> Hi Dan and Tejun,
>> >>
>> >> Looks the commit 8a4aeec8d(libata/ahci: accommodate tag ordered
>> >> controllers) causes below sata failure[1] on APM AHCI controller.
>> >>
>> >> And the error does disappear after reverting the commit.
>> >
>> > Can you give some more details about the workload and the disk? What
>> > is the APM AHCI?
>>
>> The commit causes the APM arm64 based system not bootable, and not
>> special workload, just when mounting rootfs or reading init files.
>>
>> APM AHCI:
>> drivers/ata/ahci_xgene.c
>
> Urgh... so, the controller can't handle tags allocated in round-robin
> instead of lowest-first? Ming, can you please test with different
> controllers / disks / ssds and see whether the problem stays with the
> controller? Loc, can you guys please look into it so that at least
> the next revision hardware can fix the issue?
The problem has been observed on several apm arm64 boards
with different disks.
>
> Provided that the tag allocation itself isn't broken, which isn't too
> likely given the lack of bug reports on other controllers, we'll need
> to blacklist ahci_xgene somehow. Either disable NCQ support on it or
> implement an alternative lowest-first tag allocation for it. If this
> actually is the controller freaking out about tags allocated in a
> different order, I'm not sure how much confidence we can put in its
> NCQ implementation tho and it might be a better idea to simply plug
> NCQ support on it until we understand the details of the problem.
>
> So, something like the following? Ming, can you please verify whether
> the following makes the machine boot again?
Looks the problem still persists after applying your patch of disabling
NCQ.
>
> Thanks.
>
> diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
> index 77c89bf..4950600 100644
> --- a/drivers/ata/ahci_xgene.c
> +++ b/drivers/ata/ahci_xgene.c
> @@ -302,9 +302,16 @@ static struct ata_port_operations xgene_ahci_ops = {
> .read_id = xgene_ahci_read_id,
> };
>
> +/*
> + * The controller seems to freak out depending on the order of tag
> + * allocation. NCQ support is disabled until the problem is better
> + * understood.
> + *
> + *
> http://lkml.kernel.org/g/CACVXFVMnM6w5ZLX=S8fJHeVoEqxH2JG3Wg=gpmeovnopajs...@mail.gmail.com
> + */
> static const struct ata_port_info xgene_ahci_port_info = {
> - AHCI_HFLAGS(AHCI_HFLAG_NO_PMP | AHCI_HFLAG_YES_NCQ),
> - .flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
> + AHCI_HFLAGS(AHCI_HFLAG_NO_PMP),
> + .flags = AHCI_FLAG_COMMON,
> .pio_mask = ATA_PIO4,
> .udma_mask = ATA_UDMA6,
> .port_ops = _ahci_ops,
Thanks,
--
Ming Lei
--
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] ip_tunnel: fix possible rtable leak
From: Dmitry Popov Date: Fri, 6 Jun 2014 04:34:37 +0400 > ip_rt_put(rt) is always called in "error" branches above, but was missed in > skb_cow_head branch. As rt is not yet bound to skb here we have to release it > by > hand. > > Signed-off-by: Dmitry Popov Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] [SCSI] Fix a bug in deriving the FLUSH_TIMEOUT from the basic I/O timeout
On 06/04/2014 12:15 PM, KY Srinivasan wrote:
>
>
>> -Original Message-
>> From: James Bottomley [mailto:jbottom...@parallels.com]
>> Sent: Wednesday, June 4, 2014 10:02 AM
>> To: KY Srinivasan
>> Cc: linux-kernel@vger.kernel.org; a...@canonical.com;
>> de...@linuxdriverproject.org; h...@infradead.org; linux-
>> s...@vger.kernel.org; oher...@suse.com; gre...@linuxfoundation.org;
>> jasow...@redhat.com
>> Subject: Re: [PATCH 1/1] [SCSI] Fix a bug in deriving the FLUSH_TIMEOUT
>> from the basic I/O timeout
>>
>> On Wed, 2014-06-04 at 09:33 -0700, K. Y. Srinivasan wrote:
>>> Commit ID: 7e660100d85af860e7ad763202fff717adcdaacd added code to
>>> derive the FLUSH_TIMEOUT from the basic I/O timeout. However, this
>>> patch did not use the basic I/O timeout of the device. Fix this bug.
>>>
>>> Signed-off-by: K. Y. Srinivasan
>>> ---
>>> drivers/scsi/sd.c |4 +++-
>>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index
>>> e9689d5..54150b1 100644
>>> --- a/drivers/scsi/sd.c
>>> +++ b/drivers/scsi/sd.c
>>> @@ -832,7 +832,9 @@ static int sd_setup_write_same_cmnd(struct
>>> scsi_device *sdp, struct request *rq)
>>>
>>> static int scsi_setup_flush_cmnd(struct scsi_device *sdp, struct
>>> request *rq) {
>>> - rq->timeout *= SD_FLUSH_TIMEOUT_MULTIPLIER;
>>> + int timeout = sdp->request_queue->rq_timeout;
>>> +
>>> + rq->timeout = (timeout * SD_FLUSH_TIMEOUT_MULTIPLIER);
>>
>> Could you share where you found this to be a problem? It looks like a bug in
>> block because all inbound requests being prepared should have a timeout
>> set, so block would be the place to fix it.
>
> Perhaps; what I found was that the value in rq->timeout was 0 coming into
> this function and thus multiplying obviously has no effect.
>
I think you are right. We hit this problem because we are doing:
scsi_request_fn -> blk_peek_request -> sd_prep_fn -> scsi_setup_flush_cmnd.
At this time request->timeout is zero so the multiplication does
nothing. See how sd_setup_write_same_cmnd will set the request->timeout
at this time.
Then in scsi_request_fn we do:
scsi_request_fn -> blk_start_request -> blk_add_timer.
At this time it will set the request->timeout if something like req
block pc users (like scsi_execute() or block/scsi_ioctl.c) or the write
same code mentioned above have not set the timeout.
--
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] checkpatch: warn when patch exceeds a maximum message size
On Thu, 2014-06-05 at 17:00 -0700, Bruce Allan wrote:
> the maximum message size (100,000 characters) allowed by Majordomo at
> vger.kernel.org since that is where most Linux email lists are served.
I believe this is incorrect and the patch is unnecessary.
It'd maybe more interesting if the email header sizes
were calculated and if > 1024, then some bleating message
were emitted.
> Also provide a command-line option to specify a different maximum size.
>
> Signed-off-by: Bruce Allan
> ---
>
> scripts/checkpatch.pl | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 34eb216..79bd7fd6 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -40,6 +40,7 @@ my @ignore = ();
> my $help = 0;
> my $configuration_file = ".checkpatch.conf";
> my $max_line_length = 80;
> +my $max_msg_size = 10; # Max allowed by Majordomo at vger.kernel.org
> my $ignore_perl_version = 0;
> my $minimum_perl_version = 5.10.0;
>
> @@ -62,6 +63,7 @@ Options:
>--types TYPE(,TYPE2...)show only these comma separated message types
>--ignore TYPE(,TYPE2...) ignore various comma separated message types
>--max-line-length=nset the maximum line length, if exceeded, warn
> + --max-msg-size=n set the maximum message size, if exceeded, warn
>--show-types show the message "types" in the output
>--root=PATHPATH to the kernel tree root
>--no-summary suppress the per-file summary
> @@ -130,6 +132,7 @@ GetOptions(
> 'types=s' => \@use,
> 'show-types!' => \$show_types,
> 'max-line-length=i' => \$max_line_length,
> + 'max-msg-size=i' => \$max_msg_size,
> 'root=s'=> \$root,
> 'summary!' => \$summary,
> 'mailback!' => \$mailback,
> @@ -4600,6 +4603,18 @@ sub process {
> exit(0);
> }
>
> + # Warn if patch exceeds the maximum message size
> + if (!$file) {
> + my $cnt_chars = 0;
> + foreach my $rawline (@rawlines) {
> + $cnt_chars += length($rawline) + 1;
> + }
> + if ($cnt_chars > $max_msg_size) {
> + WARN("PATCH_TOO_LARGE",
> + "patch exceeds maximum message size
> ($max_msg_size) and might be blocked by email list server(s).\n");
> + }
> + }
> +
> if (!$is_patch) {
> ERROR("NOT_UNIFIED_DIFF",
> "Does not appear to be a unified-diff format patch\n");
>
--
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] rtmutex: Handle deadlock detection smarter
On Thu, 05 Jun 2014 15:28:32 - Thomas Gleixner wrote: > @@ -1112,7 +1134,8 @@ int rt_mutex_start_proxy_lock(struct rt_ > return 1; > } > > - ret = task_blocks_on_rt_mutex(lock, waiter, task, detect_deadlock); > + /* We enforce deadlock detection for futexes */ > + ret = task_blocks_on_rt_mutex(lock, waiter, task, 1); Why bother with passing in detect_deadlock then? Same goes for rt_mutex_finish_proxy_lock(). -- 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/
[PATCH v3] iio: dac: mcp4902/mcp4912/mcp4922 dac driver
This patch provides an iio device driver for the Microchip
MCP49x2 series DACs.
Signed-off-by: Michael Welling
---
drivers/iio/dac/Kconfig | 10 +++
drivers/iio/dac/Makefile |1 +
drivers/iio/dac/mcp49x2.c | 212 +
3 files changed, 223 insertions(+)
create mode 100644 drivers/iio/dac/mcp49x2.c
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index f378ca8..032d678 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -163,4 +163,14 @@ config MCP4725
To compile this driver as a module, choose M here: the module
will be called mcp4725.
+config MCP49X2
+ tristate "MCP4902, MCP4912, MCP4922 DAC driver"
+ depends on SPI
+ ---help---
+ Say yes here to build the driver for the Microchip MCP49x2
+ series DAC devices.
+
+ To compile this driver as a module, choose M here: the module
+ will be called mcp49x2.
+
endmenu
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index bb84ad6..2fdfc2e 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_AD5686) += ad5686.o
obj-$(CONFIG_AD7303) += ad7303.o
obj-$(CONFIG_MAX517) += max517.o
obj-$(CONFIG_MCP4725) += mcp4725.o
+obj-$(CONFIG_MCP49X2) += mcp49x2.o
diff --git a/drivers/iio/dac/mcp49x2.c b/drivers/iio/dac/mcp49x2.c
new file mode 100644
index 000..398282c
--- /dev/null
+++ b/drivers/iio/dac/mcp49x2.c
@@ -0,0 +1,212 @@
+/*
+ * mcp49x2.c
+ *
+ * Driver for Microchip Digital to Analog Converters.
+ * Supports MCP4902, MCP4912, and MCP4922.
+ *
+ * Copyright (c) 2014 EMAC Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MCP49X2_NUM_CHANNELS 2
+
+enum mcp49x2_supported_device_ids {
+ ID_MCP4902,
+ ID_MCP4912,
+ ID_MCP4922,
+};
+
+struct mcp49x2_state {
+ struct spi_device *spi;
+ unsigned int value[MCP49X2_NUM_CHANNELS];
+ unsigned int power_mode[MCP49X2_NUM_CHANNELS];
+ unsigned int vref_mv;
+ struct regulator *vref_reg;
+};
+
+#define MCP49X2_CHAN(chan, bits) { \
+ .type = IIO_VOLTAGE,\
+ .output = 1,\
+ .indexed = 1, \
+ .channel = chan,\
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .scan_type = IIO_ST('u', bits, 16, 12-bits),\
+}
+
+static int mcp49x2_spi_write(struct spi_device *spi, u8 addr, u32 val)
+{
+ u8 mosi[2] cacheline_aligned;
+
+ mosi[1] = val & 0xff;
+ mosi[0] = (addr == 0) ? 0x00 : 0x80;
+ mosi[0] |= 0x30 | ((val >> 8) & 0x0f);
+
+ return spi_write(spi, mosi, 2);
+}
+
+static int mcp49x2_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long mask)
+{
+ struct mcp49x2_state *state = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ *val = state->value[chan->channel];
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = state->vref_mv;
+ *val2 = chan->scan_type.realbits;
+ return IIO_VAL_FRACTIONAL_LOG2;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int mcp49x2_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val,
+ int val2,
+ long mask)
+{
+ struct mcp49x2_state *state = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (val > GENMASK(chan->scan_type.realbits-1, 0))
+ return -EINVAL;
+ val <<= chan->scan_type.shift;
+ state->value[chan->channel] = val;
+ return mcp49x2_spi_write(state->spi, chan->channel, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_chan_spec mcp49x2_channels[3][MCP49X2_NUM_CHANNELS] = {
+ [ID_MCP4902] = { MCP49X2_CHAN(0, 8),MCP49X2_CHAN(1, 8) },
+ [ID_MCP4912] = { MCP49X2_CHAN(0, 10), MCP49X2_CHAN(1, 10) },
+ [ID_MCP4922] = { MCP49X2_CHAN(0, 12), MCP49X2_CHAN(1, 12) },
+};
+
+static const
Re: [PATCH 1/1] use documented cmpxchg api
On 06/05/2014 08:34 PM, Peter Hurley wrote: > On 06/05/2014 06:19 PM, Pranith Kumar wrote: >> use the documented atomic_cmpxchg instead of __cmpxchg64 >> >> This kills the last user of said API in drivers code. >> >> >> Signed-off-by: Pranith Kumar >> --- >> drivers/iommu/intel-iommu.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c >> index 6bb3277..270113f 100644 >> --- a/drivers/iommu/intel-iommu.c >> +++ b/drivers/iommu/intel-iommu.c >> @@ -293,7 +293,7 @@ static inline u64 dma_pte_addr(struct dma_pte *pte) >> return pte->val & VTD_PAGE_MASK; >> #else >> /* Must have a full atomic 64-bit read */ >> -return __cmpxchg64(>val, 0ULL, 0ULL) & VTD_PAGE_MASK; >> +return atomic_cmpxchg(>val, 0ULL, 0ULL) & VTD_PAGE_MASK; > > This is not equivalent. > > The __cmpxchg64() is specifically being used in this case > when !CONFIG_64BIT for a full 64-bit RMW, whereas atomic_cmpxchg() > uses ints which would be 32-bit RMW. > You are right! The previous patch is wrong in that atomic_cmpxchg needs an atomic_t argument. cmpxchg() handles the size internally using typeof() to figure out the width of RMW. There is also an explicit cmpxchg64() which does the same thing. Fixed with the following v2: use the documented cmpxchg instead of __cmpxchg64 This kills the last user of said API in drivers code. Signed-off-by: Pranith Kumar --- drivers/iommu/intel-iommu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 6bb3277..270113f 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -293,7 +293,7 @@ static inline u64 dma_pte_addr(struct dma_pte *pte) return pte->val & VTD_PAGE_MASK; #else /* Must have a full atomic 64-bit read */ - return __cmpxchg64(>val, 0ULL, 0ULL) & VTD_PAGE_MASK; + return cmpxchg(>val, 0ULL, 0ULL) & VTD_PAGE_MASK; #endif } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH ftrace/core 2/3] trace/kprobes: Avoid self tests if tracing is disabled on boot up
(2014/06/06 7:35), Yoshihiro YUNOMAE wrote:
> If tracing is disabled on boot up, the kernel should not execute self tests.
> In this patch, the kernel checks whether tracing is disabled or not
> before executing self tests.
Looks good to me, thanks! :)
Acked-by: Masami Hiramatsu
>
> Signed-off-by: Yoshihiro YUNOMAE
> Cc: Steven Rostedt
> Cc: Ingo Molnar
> Cc: Masami Hiramatsu
> Cc: linux-kernel@vger.kernel.org
> ---
> kernel/trace/trace_kprobe.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index 903ae28..ef2fba1 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -1377,6 +1377,9 @@ static __init int kprobe_trace_self_tests_init(void)
> struct trace_kprobe *tk;
> struct ftrace_event_file *file;
>
> + if (tracing_is_disabled())
> + return -ENODEV;
> +
> target = kprobe_trace_selftest_target;
>
> pr_info("Testing kprobe tracing: ");
>
>
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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] clk: exynos5420: Remove aclk66_peric from the clock tree description
Mike, On Thu, Jun 5, 2014 at 5:03 PM, Mike Turquette wrote: > Quoting Doug Anderson (2014-06-05 13:35:14) >> The "aclk66_peric" clock is a gate clock with a whole bunch of gates >> underneath it. This big gate isn't very useful to include in our >> clock tree. If any of the children need to be turned on then the big >> gate will need to be on anyway. ...and there are plenty of other "big >> gates" that aren't described in our clock tree, some of which shut off >> collections of clocks that have no relationship in the hierarchy so >> are hard to model. > > I think this is a common problem. On OMAP we have something similar to > this called "clock domains" or "clkdm" and it has been historically > handled outside of the Linux clock framework[1]. There is a relationship > to the clock framework of course and in the future it might be > worthwhile to see if there is a generic way to handle this stuff. That sounds like something that would be nice to solve, but it's not going to happen now. On the off chance that the user manual mentioned the existence of one of these "big gate" bits, it tends to not be very specific about _exactly_ which sets of clocks it disables. Tracking down every one of these would be hugely time consuming. Also: as Tomasz has indicated they don't provide a huge amount of benefit since we're already dealing with clocks on a more fine-grained level... >> "aclk66_peric" is causing earlyprintk problems since it gets disabled >> as part of the boot process, so let's just remove it. >> >> Strangely (and for no good reason) this clock is exported as part of >> the common clock bindings. Remove it since there are no in-kernel >> device trees using it and no reason anyone out of tree should refer to >> it either. > > So Linux has no control over the big gate now, correct? You are > dependent on the bootloader to ungate this thing? A better way to put it is that you're dependent on the bootloader not to gate it. ...but that's also true for pretty much any clock marked IGNORE_UNUSED and not explicitly enabled anywhere. Are you opposed to this landing as-is to unblock things and people can continue to work on the clock driver to make it even better? -Doug -- 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] ip_tunnel: fix possible rtable leak
ip_rt_put(rt) is always called in "error" branches above, but was missed in
skb_cow_head branch. As rt is not yet bound to skb here we have to release it
by
hand.
Signed-off-by: Dmitry Popov
---
net/ipv4/ip_tunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 2acc233..3f6135b 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -668,6 +668,7 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device
*dev,
dev->needed_headroom = max_headroom;
if (skb_cow_head(skb, dev->needed_headroom)) {
+ ip_rt_put(rt);
dev->stats.tx_dropped++;
kfree_skb(skb);
return;
--
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/1] use documented cmpxchg api
On 06/05/2014 06:19 PM, Pranith Kumar wrote: use the documented atomic_cmpxchg instead of __cmpxchg64 This kills the last user of said API in drivers code. Signed-off-by: Pranith Kumar --- drivers/iommu/intel-iommu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 6bb3277..270113f 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -293,7 +293,7 @@ static inline u64 dma_pte_addr(struct dma_pte *pte) return pte->val & VTD_PAGE_MASK; #else /* Must have a full atomic 64-bit read */ - return __cmpxchg64(>val, 0ULL, 0ULL) & VTD_PAGE_MASK; + return atomic_cmpxchg(>val, 0ULL, 0ULL) & VTD_PAGE_MASK; This is not equivalent. The __cmpxchg64() is specifically being used in this case when !CONFIG_64BIT for a full 64-bit RMW, whereas atomic_cmpxchg() uses ints which would be 32-bit RMW. Regards, Peter Hurley -- 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] SCHED: remove proliferation of wait_on_bit action functions.
On Thu, 5 Jun 2014 14:45:09 +0200 Ingo Molnar wrote:
>
> * NeilBrown wrote:
>
> > On Thu, 22 May 2014 11:05:02 +0200 Ingo Molnar wrote:
> >
> > >
> > > * NeilBrown wrote:
> > >
> > > > [[ get_maintainer.pl suggested 61 email address for this patch.
> > > >I've trimmed that list somewhat. Hope I didn't miss anyone
> > > >important...
> > > >I'm hoping it will go in through the scheduler tree, but would
> > > >particularly like an Acked-by for the fscache parts. Other acks
> > > >welcome.
> > > > ]]
> > > >
> > > > The current "wait_on_bit" interface requires an 'action' function
> > > > to be provided which does the actual waiting.
> > > > There are over 20 such functions, many of them identical.
> > > > Most cases can be satisfied by one of just two functions, one
> > > > which uses io_schedule() and one which just uses schedule().
> > > >
> > > > So:
> > > > Rename wait_on_bit andwait_on_bit_lock to
> > > > wait_on_bit_action and wait_on_bit_lock_action
> > > > to make it explicit that they need an action function.
> > > >
> > > > Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
> > > > which are *not* given an action function but implicitly use
> > > > a standard one.
> > > > The decision to error-out if a signal is pending is now made
> > > > based on the 'mode' argument rather than being encoded in the action
> > > > function.
> > >
> > > this patch fails to build on x86-32 allyesconfigs.
> >
> > Could you share the build errors?
>
> Sure, find it attached below.
Thanks.
It looks like this is a wait_on_bit usage that was added after I created the
patch.
How about you drop my patch for now, we wait for -rc1 to come out, then I
submit a new version against -rc1 and we get that into -rc2.
That should minimise such conflicts.
Does that work for you?
Thanks,
NeilBrown
>
> > >
> > > Could we keep the old names for a while, and remove them in the next
> > > cycle or so?
> >
> > I don't see how changing the names later rather than now will reduce the
> > chance of errors... maybe I'm missing something.
>
> Well, it would reduce build errors?
>
> Thanks,
>
> Ingo
>
> >
> fs/cifs/file.c: In function ‘cifs_oplock_break’:
> fs/cifs/file.c:3652:4: warning: passing argument 3 of ‘wait_on_bit’ makes
> integer from pointer without a cast [enabled by default]
> cifs_pending_writers_wait, TASK_UNINTERRUPTIBLE);
> ^
> In file included from include/linux/fs.h:6:0,
> from fs/cifs/file.c:24:
> include/linux/wait.h:878:1: note: expected ‘unsigned int’ but argument is of
> type ‘int (*)(void *)’
> wait_on_bit(void *word, int bit, unsigned mode)
> ^
> fs/cifs/file.c:3652:4: error: too many arguments to function ‘wait_on_bit’
> cifs_pending_writers_wait, TASK_UNINTERRUPTIBLE);
> ^
> In file included from include/linux/fs.h:6:0,
> from fs/cifs/file.c:24:
> include/linux/wait.h:878:1: note: declared here
> wait_on_bit(void *word, int bit, unsigned mode)
> ^
> CC kernel/smp.o
> CC kernel/trace/trace_event_perf.o
> make[2]: *** [fs/cifs/file.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> CC drivers/bcma/sprom.o
> CC fs/btrfs/locking.o
> LD sound/isa/ad1848/snd-ad1848.o
> LD sound/isa/ad1848/built-in.o
> CC sound/isa/cs423x/cs4231.o
> CC lib/fonts/fonts.o
> CC lib/fonts/font_sun8x16.o
> CC drivers/bcma/driver_chipcommon.o
> CC lib/fonts/font_sun12x22.o
signature.asc
Description: PGP signature
Re: [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration
On 06/05/2014 09:57 PM, Alexander Graf wrote: > > On 05.06.14 09:25, Alexey Kardashevskiy wrote: >> This reserves 2 capability numbers. >> >> This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl. >> >> Please advise how to proceed with these patches as I suspect that >> first two should go via Paolo's tree while the last one via Alex Graf's tree >> (correct?). > > They would just go via my tree, but only be actually allocated (read: > mergable to qemu) when they hit Paolo's tree. > > In fact, I don't think it makes sense to split them off at all. So? Are these patches going anywhere? Thanks. -- Alexey -- 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] clk: exynos5420: Remove aclk66_peric from the clock tree description
Quoting Doug Anderson (2014-06-05 13:35:14)
> The "aclk66_peric" clock is a gate clock with a whole bunch of gates
> underneath it. This big gate isn't very useful to include in our
> clock tree. If any of the children need to be turned on then the big
> gate will need to be on anyway. ...and there are plenty of other "big
> gates" that aren't described in our clock tree, some of which shut off
> collections of clocks that have no relationship in the hierarchy so
> are hard to model.
I think this is a common problem. On OMAP we have something similar to
this called "clock domains" or "clkdm" and it has been historically
handled outside of the Linux clock framework[1]. There is a relationship
to the clock framework of course and in the future it might be
worthwhile to see if there is a generic way to handle this stuff.
>
> "aclk66_peric" is causing earlyprintk problems since it gets disabled
> as part of the boot process, so let's just remove it.
>
> Strangely (and for no good reason) this clock is exported as part of
> the common clock bindings. Remove it since there are no in-kernel
> device trees using it and no reason anyone out of tree should refer to
> it either.
So Linux has no control over the big gate now, correct? You are
dependent on the bootloader to ungate this thing?
Regards,
Mike
[1] http://deferred.io/images/clkdm.png
>
> Signed-off-by: Doug Anderson
> ---
> Changes in v3:
> - Now just remove aclk66_peric from the tree as suggested by Tomasz.
>
> Changes in v2:
> - Use GATE_A and clk_get(). Save the clock for putting later.
> - Return 0 from exynos5420_clk_late_init().
>
> drivers/clk/samsung/clk-exynos5420.c | 85
> ++
> include/dt-bindings/clock/exynos5420.h | 1 -
> 2 files changed, 55 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 9d7d7ee..61eccf0 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -890,8 +890,6 @@ static struct samsung_gate_clock exynos5x_gate_clks[]
> __initdata = {
> GATE_BUS_TOP, 9, CLK_IGNORE_UNUSED, 0),
> GATE(0, "aclk66_psgen", "mout_user_aclk66_psgen",
> GATE_BUS_TOP, 10, CLK_IGNORE_UNUSED, 0),
> - GATE(CLK_ACLK66_PERIC, "aclk66_peric", "mout_user_aclk66_peric",
> - GATE_BUS_TOP, 11, CLK_IGNORE_UNUSED, 0),
> GATE(0, "aclk266_isp", "mout_user_aclk266_isp",
> GATE_BUS_TOP, 13, 0, 0),
> GATE(0, "aclk166", "mout_user_aclk166",
> @@ -994,34 +992,61 @@ static struct samsung_gate_clock exynos5x_gate_clks[]
> __initdata = {
> SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
>
> /* PERIC Block */
> - GATE(CLK_UART0, "uart0", "aclk66_peric", GATE_IP_PERIC, 0, 0, 0),
> - GATE(CLK_UART1, "uart1", "aclk66_peric", GATE_IP_PERIC, 1, 0, 0),
> - GATE(CLK_UART2, "uart2", "aclk66_peric", GATE_IP_PERIC, 2, 0, 0),
> - GATE(CLK_UART3, "uart3", "aclk66_peric", GATE_IP_PERIC, 3, 0, 0),
> - GATE(CLK_I2C0, "i2c0", "aclk66_peric", GATE_IP_PERIC, 6, 0, 0),
> - GATE(CLK_I2C1, "i2c1", "aclk66_peric", GATE_IP_PERIC, 7, 0, 0),
> - GATE(CLK_I2C2, "i2c2", "aclk66_peric", GATE_IP_PERIC, 8, 0, 0),
> - GATE(CLK_I2C3, "i2c3", "aclk66_peric", GATE_IP_PERIC, 9, 0, 0),
> - GATE(CLK_USI0, "usi0", "aclk66_peric", GATE_IP_PERIC, 10, 0, 0),
> - GATE(CLK_USI1, "usi1", "aclk66_peric", GATE_IP_PERIC, 11, 0, 0),
> - GATE(CLK_USI2, "usi2", "aclk66_peric", GATE_IP_PERIC, 12, 0, 0),
> - GATE(CLK_USI3, "usi3", "aclk66_peric", GATE_IP_PERIC, 13, 0, 0),
> - GATE(CLK_I2C_HDMI, "i2c_hdmi", "aclk66_peric", GATE_IP_PERIC, 14, 0,
> 0),
> - GATE(CLK_TSADC, "tsadc", "aclk66_peric", GATE_IP_PERIC, 15, 0, 0),
> - GATE(CLK_SPI0, "spi0", "aclk66_peric", GATE_IP_PERIC, 16, 0, 0),
> - GATE(CLK_SPI1, "spi1", "aclk66_peric", GATE_IP_PERIC, 17, 0, 0),
> - GATE(CLK_SPI2, "spi2", "aclk66_peric", GATE_IP_PERIC, 18, 0, 0),
> - GATE(CLK_I2S1, "i2s1", "aclk66_peric", GATE_IP_PERIC, 20, 0, 0),
> - GATE(CLK_I2S2, "i2s2", "aclk66_peric", GATE_IP_PERIC, 21, 0, 0),
> - GATE(CLK_PCM1, "pcm1", "aclk66_peric", GATE_IP_PERIC, 22, 0, 0),
> - GATE(CLK_PCM2, "pcm2", "aclk66_peric", GATE_IP_PERIC, 23, 0, 0),
> - GATE(CLK_PWM, "pwm", "aclk66_peric", GATE_IP_PERIC, 24, 0, 0),
> - GATE(CLK_SPDIF, "spdif", "aclk66_peric", GATE_IP_PERIC, 26, 0, 0),
> - GATE(CLK_USI4, "usi4", "aclk66_peric", GATE_IP_PERIC, 28, 0, 0),
> - GATE(CLK_USI5, "usi5", "aclk66_peric", GATE_IP_PERIC, 30, 0, 0),
> - GATE(CLK_USI6, "usi6", "aclk66_peric", GATE_IP_PERIC, 31, 0, 0),
> -
> - GATE(CLK_KEYIF, "keyif", "aclk66_peric", GATE_BUS_PERIC, 22, 0, 0),
> + GATE(CLK_UART0, "uart0", "mout_user_aclk66_peric",
> + GATE_IP_PERIC, 0, 0, 0),
> +
[PATCH] checkpatch: warn when patch exceeds a maximum message size
Patch submissions which exceed a maximum message size imposed by email
list servers can be silently blocked. Warn when a patch message exceeds
the maximum message size (100,000 characters) allowed by Majordomo at
vger.kernel.org since that is where most Linux email lists are served.
Also provide a command-line option to specify a different maximum size.
Signed-off-by: Bruce Allan
---
scripts/checkpatch.pl | 15 +++
1 file changed, 15 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 34eb216..79bd7fd6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -40,6 +40,7 @@ my @ignore = ();
my $help = 0;
my $configuration_file = ".checkpatch.conf";
my $max_line_length = 80;
+my $max_msg_size = 10; # Max allowed by Majordomo at vger.kernel.org
my $ignore_perl_version = 0;
my $minimum_perl_version = 5.10.0;
@@ -62,6 +63,7 @@ Options:
--types TYPE(,TYPE2...)show only these comma separated message types
--ignore TYPE(,TYPE2...) ignore various comma separated message types
--max-line-length=nset the maximum line length, if exceeded, warn
+ --max-msg-size=n set the maximum message size, if exceeded, warn
--show-types show the message "types" in the output
--root=PATHPATH to the kernel tree root
--no-summary suppress the per-file summary
@@ -130,6 +132,7 @@ GetOptions(
'types=s' => \@use,
'show-types!' => \$show_types,
'max-line-length=i' => \$max_line_length,
+ 'max-msg-size=i' => \$max_msg_size,
'root=s'=> \$root,
'summary!' => \$summary,
'mailback!' => \$mailback,
@@ -4600,6 +4603,18 @@ sub process {
exit(0);
}
+ # Warn if patch exceeds the maximum message size
+ if (!$file) {
+ my $cnt_chars = 0;
+ foreach my $rawline (@rawlines) {
+ $cnt_chars += length($rawline) + 1;
+ }
+ if ($cnt_chars > $max_msg_size) {
+ WARN("PATCH_TOO_LARGE",
+"patch exceeds maximum message size
($max_msg_size) and might be blocked by email list server(s).\n");
+ }
+ }
+
if (!$is_patch) {
ERROR("NOT_UNIFIED_DIFF",
"Does not appear to be a unified-diff format patch\n");
--
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] pci/msi: fix memory leak in free_msi_irqs()
On Wed, Jun 04, 2014 at 03:49:50PM -0700, Alexei Starovoitov wrote:
> free_msi_irqs() is leaking memory, since
> list_for_each_entry(entry, >msi_list, list) {...}
> is never executed, because dev->msi_list is made empty by
> the loop just above this one.
>
> Fix it by relying on zero termination of attribute array like
> populate_msi_sysfs() does.
>
> Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not
> kobjects")
> Signed-off-by: Alexei Starovoitov
> ---
>
> This was found by kmemleak report:
> unreferenced object 0x880808eda600 (size 64):
> comm "modprobe", pid 1526, jiffies 4294902299 (age 58422.716s)
> hex dump (first 32 bytes):
> 20 c4 66 09 08 88 ff ff 24 01 00 00 00 00 00 00 .f.$...
> 50 97 77 82 ff ff ff ff 00 00 00 00 00 00 00 00 P.w.
> backtrace:
> [] kmemleak_alloc+0x28/0x50
> [] kmem_cache_alloc_trace+0xde/0x230
> [] populate_msi_sysfs+0xc6/0x250
> [] pci_enable_msix+0x34b/0x430
> [] pci_enable_msix_range+0x2c/0x70
> [] igb_init_interrupt_scheme+0x9e/0x420 [igb]
> [] igb_probe+0x4a8/0x1250 [igb]
> [] local_pci_probe+0x4e/0xa0
> [] pci_device_probe+0xd9/0x120
> [] driver_probe_device+0x8d/0x250
> [] __driver_attach+0xab/0xb0
> [] bus_for_each_dev+0x5d/0xa0
> [] driver_attach+0x1e/0x20
> [] bus_add_driver+0x117/0x220
> [] driver_register+0x64/0xf0
> [] __pci_register_driver+0x64/0x70
>
> IGB driver is calling pci_enable_msix_range() and immediately
> pci_disable_msix()
> which leaks the memory.
> Obviously the leak happens with any driver.
>
> drivers/pci/msi.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 955ab7990c5b..fb02fc2fb034 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -414,7 +414,7 @@ static void free_msi_irqs(struct pci_dev *dev)
> if (dev->msi_irq_groups) {
> sysfs_remove_groups(>dev.kobj, dev->msi_irq_groups);
> msi_attrs = dev->msi_irq_groups[0]->attrs;
> - list_for_each_entry(entry, >msi_list, list) {
> + while (msi_attrs[count]) {
> dev_attr = container_of(msi_attrs[count],
> struct device_attribute, attr);
> kfree(dev_attr->attr.name);
Looks good, thanks for catching this:
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH kvm-unit-tests1/2] x86: emulator: additional smsw test-case
An additional test case for the emulator was added to test smsw which is
trapped by the emulator. The other existing test-cases occur in the guest (at
least on VMX), since the values are read directly from the CR0 read shadow.
Signed-off-by: Nadav Amit
---
x86/emulator.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/x86/emulator.c b/x86/emulator.c
index 20e3a45..033f246 100644
--- a/x86/emulator.c
+++ b/x86/emulator.c
@@ -336,7 +336,7 @@ void test_incdecnotneg(void *mem)
report("lock notb", *mb == vb);
}
-void test_smsw(void)
+void test_smsw(uint64_t *h_mem)
{
char mem[16];
unsigned short msw, msw_orig, *pmsw;
@@ -355,6 +355,12 @@ void test_smsw(void)
if (i != 4 && pmsw[i])
zero = 0;
report("smsw (2)", msw == pmsw[4] && zero);
+
+ /* Trigger exit on smsw */
+ *h_mem = 0x12345678abcdeful;
+ asm volatile("smsw %0" : "=m"(*h_mem));
+ report("smsw (3)", msw == (unsigned short)*h_mem &&
+ (*h_mem & ~0xul) == 0x12345678abul);
}
void test_lmsw(void)
@@ -998,7 +1004,7 @@ int main()
test_cr8();
- test_smsw();
+ test_smsw(mem);
test_lmsw();
test_ljmp(mem);
test_stringio();
--
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 kvm-unit-tests 0/2] x86: Additional smsw tests
This patch set adds two tests for smsw. The first one is intended to add coverage of smsw. It covers the case smsw is executed with memory operand in a page which is write-protected by the hypervisor. Note that the existing smsw tests are not supposed to be trapped by the hypervisor. This test was added just for additional coverage. The realmode smsw test covers the recent patch that saves the high 16-bits to 32-bit register operand. Implementing a long-mode test is difficult since we need to cause an "invalid guest state" in long-mode. Nadav Amit (2): x86: emulator: additional smsw test-case x86: realmode: test smsw behavior with register operand x86/emulator.c | 10 -- x86/realmode.c | 15 +++ 2 files changed, 23 insertions(+), 2 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/
[PATCH kvm-unit-tests 2/2] x86: realmode: test smsw behavior with register operand
The smsw instruction has an undocumented behavior, in which the high-order
16-bits of CR0 are also saved in a 32-bit destination register. This is
similar to the way smsw behaves in long-mode. However, it is hard to test the
long-mode case, since we need to cause an "invalid guest state" in long-mode.
The test works as follows: it sets CR0.CD (bit 30), so any of the high 16-bits
would be set. It then executes smsw to register destination and compares the
register value with that of CR0. CR0 value is restored when the test is done.
This test is expected to fail only when unrestricted mode is disabled or
unsupported.
Signed-off-by: Nadav Amit
---
x86/realmode.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/x86/realmode.c b/x86/realmode.c
index 839ac34..6e74883 100644
--- a/x86/realmode.c
+++ b/x86/realmode.c
@@ -1646,6 +1646,20 @@ void test_dr_mod(void)
report("mov dr with mod bits", R_AX | R_BX, outregs.eax == 0xaced);
}
+void test_smsw(void)
+{
+ MK_INSN(smsw, "movl %cr0, %ebx\n\t"
+ "movl %ebx, %ecx\n\t"
+ "or $0x4000, %ebx\n\t"
+ "movl %ebx, %cr0\n\t"
+ "smswl %eax\n\t"
+ "movl %ecx, %cr0\n\t");
+ inregs.eax = 0x12345678;
+ exec_in_big_real_mode(_smsw);
+ report("smsw", R_AX | R_BX | R_CX, outregs.eax == outregs.ebx);
+}
+
+
void realmode_start(void)
{
test_null();
@@ -1692,6 +1706,7 @@ void realmode_start(void)
test_salc();
test_fninit();
test_dr_mod();
+ test_smsw();
test_nopl();
test_perf_loop();
test_perf_mov();
--
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: blk-mq: bitmap tag: performance degradation?
On Fri, Jun 6, 2014 at 1:17 AM, Jens Axboe wrote: > On 06/05/2014 08:16 AM, Ming Lei wrote: >> On Thu, Jun 5, 2014 at 10:03 PM, Jens Axboe wrote: >>> On 2014-06-05 08:01, Alexander Gordeev wrote: On Wed, Jun 04, 2014 at 08:18:42AM -0600, Jens Axboe wrote: > > A null_blk test is the absolute best case for percpu_ida, since > there are enough tags and everything is localized. The above test is > more useful for testing blk-mq than any real world application of > the tagging. > > I've done considerable testing on both 2 and 4 socket (32 and 64 > CPUs) and bitmap tagging is better in a much wider range of > applications. This includes even high tag depth devices like nvme, > and more normal ranges like mtip32xx and scsi-mq setups. Just for the record: bitmap tags on a 48 CPU box with NVMe device indeed shows almost the same performance/cache rate as the stock kernel. >>> >>> >>> Thanks for confirming. It's one of the dangers of null_blk, it's not always >>> a very accurate simulation of what a real device will do. I think it's >>> mostly a completion side thing, would be great with a small device that >>> supported msi-x and could be used as an irq trigger :-) >> >> Maybe null_blk at IRQ_TIMER mode is more close to >> a real device, and I guess the result may be different with >> mode IRQ_NONE/IRQ_SOFTIRQ. > > It'd be closer in behavior, but the results might then be skewed by > hitting the timer way too hard. And it'd be a general slowdown, again > possibly skewing it. But I haven't tried with the timer completion, to > see if that yields more accurate modelling for this test, so it might > actually be a lot better. My test on a 16core VM(host: 2 sockets, 16core): 1, bitmap tag allocation(3.15-rc7-next): - softirq mode: 759K IOPS - timer mode: 409K IOPS 2, percpu_ida allocation(3.15-rc7) - softirq mode: 1116K IOPS - timer mode: 411K IOPS Also on real hardware, I remember there is no such big difference between softirq mode and timer mode. [global] direct=1 size=128G bsrange=4k-4k timeout=20 numjobs=16 ioengine=libaio iodepth=64 filename=/dev/nullb0 group_reporting=1 [f2] stonewall rw=randread Thanks, -- Ming Lei -- 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 9/9] perf/x86: add syfs entry to disable HT bug workaround
> As Stephane pointed out, the sysfs entry is optional and the workaround > can be disabled only as root. > > It is not absolutely necessary and it's not important. > We will drop it in V2. I would prefer to keep it. It's fairly complex and it's always good to have a way to disable complex things in case something goes wrong. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 000/103] 3.10.42-stable review
On Wed, Jun 04, 2014 at 04:24:23PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.42 release. > There are 103 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Jun 6 23:24:52 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.42-rc1.gz > and the diffstat can be found below. As discussed on the 3.14-stable announcement I've updated this tree as well, so there is now a -rc2 out for people to test: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.42-rc1.gz thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 000/228] 3.14.6-stable review
On Wed, Jun 04, 2014 at 04:20:29PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.6 release. > There are 228 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Jun 6 23:23:11 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.6-rc1.gz > and the diffstat can be found below. I've updated the stable tree with the futex patches as lots of people have been asking me about them, so here is a -rc2 with them incorporated: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.6-rc1.gz -- 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 000/214] 3.4.92-stable review
On Wed, Jun 04, 2014 at 09:16:03PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.92 release. > There are 214 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Jun 7 04:15:47 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.92-rc1.gz > and the diffstat can be found below. Given the recent changes in this tree, I've released a -rc2 to handle all of the updates.: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.92-rc1.gz thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/1] Add kernel parameter for kernel version
On Fri, Jun 6, 2014 at 12:56 AM, eric ernst wrote: > > On 14-06-05 03:29 PM, Randy Dunlap wrote: >> >> On 06/05/2014 03:15 PM, eric ernst wrote: >>> >>> On 14-06-05 03:16 PM, Andrew Morton wrote: On Thu, 5 Jun 2014 15:09:17 -0700 eric.er...@linux.intel.com wrote: > Create a kernel cmdline parameter, "version_addendum", which can be > used to add text to the kernel version that is reported from > /proc/version. why? >>> >>> We have a need to keep a single product binary (kernel) across multiple >>> android devices. A subset of these platforms are looking for extra >>> versioning information appended to it, accessible via /proc/version. Rather >>> than build multiple otherwise identical kernels with only this extended >>> versioning as differentiation, we are looking to make this a command line >>> parameter. Understandable if there isn't enough value-add for the community >>> in this patch, but I figured I'd give the patch a shot, as we need this >>> functionality locally. Thanks. >> >> Please use a newline character every 70-72 characters instead of assuming >> that all email programs will break that extra long line up into a readable >> format. (mine does not.) > > Ack - sorry Randy - it was a quick cp / paste from earlier in the thread. > >> >> What software needs to know the version info? how early does it run? >> Could it get the version info from 'uname -r' instead of from >> /proc/version? >> >> thanks, > > This'll end up being used by a third party customer for tracking particular > devices, so I'm sure "much, much later" in user space. While I'm sure they > could use uname instead, the specific request was for /proc/version. sandpuppy:/home/rw # echo "Windows" > /tmp/version sandpuppy:/home/rw # mount --bind /tmp/version /proc/version sandpuppy:/home/rw # cat /proc/version Windows -- Thanks, //richard -- 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] firmware loader: allow disabling of udev as firmware loader
On Thu, Jun 5, 2014 at 11:15 PM, Tom Gundersen wrote: > On Thu, Jun 5, 2014 at 4:54 PM, Ming Lei wrote: >>> Ubuntu currently enables the firmware loader in both the kernel and in >>> udev, so would not yet have a problem here at the moment. However, I >>> spoke with Martin Pitt and he told me that both Debian and Ubuntu >>> would like to switch this off in udev once it is possible (i.e., once >>> this patch has been merged I guess). Fedora already did, and speaking >>> for Arch we definitely would like to do the same. I did not check with >>> other distros, but I'm pretty sure "everyone" will disable this in >>> udev by the next cycle. At which point having it enabled in the kernel >>> will cause real problems and bug reports. >> >> That won't cover the case of old distributions with new kernel, > > Again: disabling this option will not give problems (unless you have a > custom setup), even on old userspace, only keeping it enabled on > future userspace may. > >> do >> you want to break/confuse these users? > > Not really, no :) > >>> For distro kernels that's not a problem, as they know what to do, but >>> I guess for random kernel users we should give them the correct >>> recommendation. >> >> Also I remember that android users put firmware under their >> special path. > > That may be, but I don't think this text is primarily aimed at the > people who put together Android systems... Surely their non-standard > userspace means that a lot of the advice (and it is nothing else than > advice!) in the help text does not necessarily apply? > >> It only falls back if the request fw is _not_ found from direct loading, >> so it is reasonable to try to continue to look for it from user space. > Some drivers fall back to different firmware (e.g. different revision > suffix) if the requested file isn't found. So, this happens in > reality. So do you think the fallback is better or worse? For CPU microcode case, maybe it is fine, but for other devices, maybe it is better to get a firmware for working at least. >>> >>> What usecase do you have in mind here? For people using stock udev, >>> enabling the fallback will not give any benefit, but it will soon >> >> Again, we have old distributions, also it should make sense to fall back >> to userspace for non-exist firmwares under default path. > > Even on old distributions, falling back to stock udev will not give > any benefits. It will look in the same paths as the kernel and fail in > the same way. > >>> start giving real problems... >> >> If there isn't firmwares at default path for devices, the device may >> not work, and that is the real problem. > > These devices will never have worked with stock udev, as it looks in > the same path as the kernel (the paths the kernel looks in was taken > from udev to make sure they work the sam). So this must be a > special/custom setup by someone who knows what they are doing, and > hopefully knows how to answer the Kconfig. I have to say all your statement about old distributions is just your take for granted, and you can't verified on all old distributions at all. That is said, disabling fallback may cause regression on these distributions. Given that the user helper(fallback) has been used for tens of years on these distributions, I suggest you to change Kconfig help message as something like below: If your aren't sure, please check your udev/systemd version, if it is below than XXX or no udev/systemd shipped in your system, say Y here, otherwise say N. Thanks, -- Ming Lei -- 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 v1 1/1] Add kernel parameter for kernel version
On 14-06-05 03:29 PM, Randy Dunlap wrote: On 06/05/2014 03:15 PM, eric ernst wrote: On 14-06-05 03:16 PM, Andrew Morton wrote: On Thu, 5 Jun 2014 15:09:17 -0700 eric.er...@linux.intel.com wrote: Create a kernel cmdline parameter, "version_addendum", which can be used to add text to the kernel version that is reported from /proc/version. why? We have a need to keep a single product binary (kernel) across multiple android devices. A subset of these platforms are looking for extra versioning information appended to it, accessible via /proc/version. Rather than build multiple otherwise identical kernels with only this extended versioning as differentiation, we are looking to make this a command line parameter. Understandable if there isn't enough value-add for the community in this patch, but I figured I'd give the patch a shot, as we need this functionality locally. Thanks. Please use a newline character every 70-72 characters instead of assuming that all email programs will break that extra long line up into a readable format. (mine does not.) Ack - sorry Randy - it was a quick cp / paste from earlier in the thread. What software needs to know the version info? how early does it run? Could it get the version info from 'uname -r' instead of from /proc/version? thanks, This'll end up being used by a third party customer for tracking particular devices, so I'm sure "much, much later" in user space. While I'm sure they could use uname instead, the specific request was for /proc/version. The more I look into this patch, the more I think this is a pretty specific use case that probably doesn't have a lot of community value-add outside of our scenario. Thanks for the feedback. -- 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/4] of: Add NVIDIA Tegra XUSB pad controller binding
On 06/05/2014 04:08 PM, Thierry Reding wrote: > On Thu, Jun 05, 2014 at 10:47:45AM -0600, Stephen Warren wrote: >> On 06/04/2014 09:16 AM, Thierry Reding wrote: >>> From: Thierry Reding >>> >>> This patch adds the device tree binding documentation for the XUSB pad >>> controller found on NVIDIA Tegra SoCs. It exposes both pinmuxing and PHY >>> capabilities. >> >>> diff --git >>> a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt >>> b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt >> >>> +- #phy-cells: Should be 1. The specifier is the index of the PHY to >>> reference. >>> + Possible values are: >>> + - 0: PCIe >>> + - 1: SATA >> >> Those values are defined in >> include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h. I personally consider >> the header files to be part of the binding itself, rather >> than being derived from the binding. As such, I'd suggest the following >> changes: >> >> * Make this patch 1 not patch 2 >> * Move pinctrl-tegra-xusb.h into this patch. >> * Remove the list of values above, and replace it with the text "See >> for the set of valid values". > > I remember discussions where people explicitly said that relying on the > symbolic names in the DT bindings was a mistake because it would mean > that everyone would need to have access to a mechanism similar to what > we have in the Linux kernel (and that the header files would always need > to be shipped with the DT bindings). The entire point of the headers is so that the binding definitions and code using them can't get out of sync. In my opinion, the headers *are* part of the bindings, so of course anyone either reading DT bindings, or parsing DT, must have the headers, and hence the headers must be bundled with the DT files or with the bindings wherever they go. signature.asc Description: OpenPGP digital signature
Re: [PATCH v7 4/5] ARM: tegra: Add efuse and apbmisc bindings
On 06/05/2014 04:13 PM, Peter De Schrijver wrote:
> On Thu, Jun 05, 2014 at 08:41:55PM +0200, Stephen Warren wrote:
>> On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
>>> Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
>>
>>> diff --git a/arch/arm/boot/dts/tegra114.dtsi
>>> b/arch/arm/boot/dts/tegra114.dtsi
>>
>>> + apbmisc@7800 {
>>> + compatible = "nvidia,tegra114-apbmisc",
>>> "nvidia,tegra20-apbmisc";
>>
>> Is the Tegra114 APBMISC register layout 100% a backwards-compatible
>> superset of that in Tegra20? For both registers the code currently uses
>> *and* all possible registers the code could ever use? Since the APB MISC
>> is a bit of a dumping ground for random registers, that feels unlikely,
>> but perhaps it's possible.
>
> For all I can see it is. At least for the registers the kernel is likely to
> use.
But that's ("At least for the registers the kernel is likely to use")
not how compatible values are defined. We need to explicitly look at all
the registers and actively decide that it really is compatible in order
to mark it so. If we don't want to do that, it's best just to use a
separate compatible value for each SoC, and add a couple more entries
into the match table.
--
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 v7 3/5] misc: fuse: Add efuse driver for Tegra
On 06/05/2014 04:09 PM, Peter De Schrijver wrote:
> On Thu, Jun 05, 2014 at 08:37:26PM +0200, Stephen Warren wrote:
>> On 06/05/2014 07:09 AM, Peter De Schrijver wrote:
>>> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
>>>
>>> Signed-off-by: Peter De Schrijver
>>> ---
>>> Documentation/ABI/testing/sysfs-driver-tegra-fuse | 11 +
>>> drivers/misc/fuse/Makefile|1 +
>>> drivers/misc/fuse/tegra/Makefile |7 +
>>> drivers/misc/fuse/tegra/fuse-tegra.c | 250 +
>>
>> I wonder if we shouldn't put this into drivers/soc/tegra?
>>
>>> diff --git a/drivers/misc/fuse/tegra/fuse-tegra.c
>>> b/drivers/misc/fuse/tegra/fuse-tegra.c
>>
>>> +void __init tegra_init_fuse(void)
>>> +{
>>> + struct device_node *np;
>>> + u32 id;
>>> + void __iomem *car_base;
>>> +
>>> + np = of_find_matching_node(NULL, apbmisc_match);
>>> + apbmisc_base = of_iomap(np, 0);
>>> + if (!apbmisc_base) {
>>> + pr_warn("ioremap tegra apbmisc failed. using %08x instead\n",
>>> + APBMISC_BASE);
>>> + apbmisc_base = ioremap(APBMISC_BASE, APBMISC_SIZE);
>>> + }
>>> +
>>> + id = tegra_read_chipid();
>>> + tegra_chip_id = (id >> 8) & 0xff;
>>
>> So there's a fallback using APBMIS_BASE above if the node is missing, so
>> those last 2 lines always happen. However, if any of the following fail:
>>
>>> + strapping_base = of_iomap(np, 0);
>> ...
>>> + np = of_find_matching_node(NULL, tegra_fuse_match);
>> ...
>>> + np = of_find_matching_node(NULL, car_match);
>>
>> Then this doesn't get executed:
>>
>>> + tegra_get_revision(id);
>>
>> Isn't that important?
>
> No. It's only used to populate /sys/devices/soc0/revision. I don't think
> that's particularly important.
But it's a feature that works today. Why should we break it?
>> I guess that can't run if the lookup for tegra_fuse_match isn't
>> successful, since that tegra_get_revision may call
>> tegra20_spare_fuse_early() which uses fuse_base which is set up in
>> response to succesfully calling on of those node lookups. Isn't a
>> fallback needed there too?
>
> tegra20_spare_fuse_early() will not be called if fuse_base is NULL.
Oh yes. We can at least call the function then even if the fuses can't
be mapped.
But to avoid regressions, we should simply make sure the fuses can be
mapped.
>> I'm also a bit concerned that the driver probes, rather than the early
>> function tegra_init_fuse(), are doing things like setting up the speedo
>> data initialization, randomness addition, etc. For one, those won't
>> happen any more unless the DT nodes are present, and secondly,
>> triggering all those from driver probe rather than a function that's
>> called from the machine descriptor makes guaranteeing the timing
>> problematic.
>
> Today there are no users of the speedo ID in upstream.
Well, except people reading kernel log messages. Accurate speedo-related
log messages have help pin-point a problem or two in the past.
> Looking at chromeos
> the users of the speedo ID are: CPU dvfs, GPU dvfs and sdhci. The last 2 also
> need regulators and therefor will need to support deferred probing anyway.
> CPU dvfs isn't critical at all, we don't care when it gets initialized. So
> deferred probe is fine.
What condition will those modules/drivers use to defer their probe?
> sdhci needs this for faster modes I guess which will also need extra DT
> properties looking at the chromeos driver. The others definitely will need
> an updated DT. For randomness I haven't seen any appreciable difference in
> when
> the 'random: nonblocking pool is initialized' message appears between having
> the randomness addition or not. Most likely the bulk of the randomness comes
> from serial interrupts rather than the fuse data. So I don't think the move to
> a driver probe will cause any problem. Nor do I think the lack of an updated
> DT will cause problems.
But what advantage do we have by actively changing it?
--
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: Change in security maintainer for a few weeks
On Thu, Jun 05, 2014 at 08:55:13PM +0200, Serge E. Hallyn wrote: > Quoting Greg KH (gre...@linuxfoundation.org): > > On Thu, Jun 05, 2014 at 02:38:25PM -0400, Josh Boyer wrote: > > > On Thu, Jun 5, 2014 at 2:30 PM, Greg KH > > > wrote: > > > > Hi all, > > > > > > > > James has had to step back from doing kernel work for a few weeks, so > > > > I've offered to step up and handle the security patches to get shuttled > > > > to Linus for merging for a while. > > > > > > > > I'll take his git tree on kernel.org and push those to Linus for > > > > 3.16-rc1, as those look like they have had proper testing in linux-next. > > > > > > > > But there only seems to be 14 patches in there. Are there pending > > > > patches that people have been sending and need to get in besides those? > > > > > > Serge seems to have already done this? > > > > > > https://lkml.org/lkml/2014/6/4/350 > > > > Ah, that's good, but wasn't sent to the linux-security-module list where > > I would have noticed it :( > > > > The patches also don't seem to have ended up in Linus's tree either > > yet... > > > > Serge, are you going to be doing this in replacement of James for a > > while? > > I don't mind, but I definately don't mind if you do. In the past with > planned vacations James has asked me to babysit the tree, so I just > wanted to make sure it didn't get neglected. But he did not ask me, > I'm just an interloper. That's great, I wasn't aware of this. Feel free to keep doing this and taking over for now. As you already have a kernel.org account, and have done it in the past, it only makes sense for you to continue. But next time, cc: the subsystem mailing list :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Change in security maintainer for a few weeks
On Thu, Jun 05, 2014 at 06:39:09PM -0400, Paul Moore wrote: > On Thursday, June 05, 2014 11:59:11 PM Jiri Kosina wrote: > > On Thu, 5 Jun 2014, Greg KH wrote: > > > James has had to step back from doing kernel work for a few weeks, so > > > I've offered to step up and handle the security patches to get shuttled > > > to Linus for merging for a while. > > > > As exactly this (working with active contributors to help co-maintain the > > subsystem) has been brought at the ksummit maling list, I am just curious > > whether noone else actively working in that area was willing to step up? > > > > $ ./scripts/get_maintainer.pl --git -f security/ > > James Morris (supporter:SECURITY SUBSYSTEM) > >... > > > > If not, then I think this can be shown as a prime example why the problem > > of "non-substituability" of many maintainers is actually real. > > Once several of us became aware that James was stepping away for a few weeks > (I should mention this was not a planned absence and took most of us by > surprise) we had a brief discussion off-list and several of us did offer to > "step-up"; Serge had already created a repo and since he had pushed patches > while James was away in the past it seemed a reasonable approach this time > around. That's great, as the communication around this has not been very much (an non-existant on the subsystem mailing list) I was not aware of it. If Serge wants to do this, and as he has been the stand-in for James in the past, I have _no_ objection to this at all. Serge, feel free to resend your patches to Linus if he doesn't pick them up in a few days, with the information that you are doing this in James's absence for a while. So, that was easy, I don't have to do this at all, great. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 07/22] Replace the XIP page fault handler with the DAX page fault handler
On Wed, 2014-05-21 at 14:35 -0600, Toshi Kani wrote:
> On Sun, 2014-03-23 at 15:08 -0400, Matthew Wilcox wrote:
> :
> > +static int do_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
> > + get_block_t get_block)
> > +{
> :
> > + error = dax_get_pfn(inode, , );
> > + if (error > 0)
> > + error = vm_insert_mixed(vma, vaddr, pfn);
> > + mutex_unlock(>i_mmap_mutex);
> > +
> > + if (page) {
> > + delete_from_page_cache(page);
> > + unmap_mapping_range(mapping, vmf->pgoff << PAGE_SHIFT,
> > + PAGE_CACHE_SIZE, 0);
> > + unlock_page(page);
> > + page_cache_release(page);
>
> Hi Matthew,
>
> I am seeing a problem in this code path, where it deletes a page cache
> page mapped to a hole. Sometimes, page->_mapcount is 0, not -1, which
> leads __delete_from_page_cache(), called from delete_from_page_cache(),
> to hit the following BUG_ON.
>
> BUG_ON(page_mapped(page))
>
> I suppose such page has a shared mapping. Does this code need to take
> care of replacing shared mappings in such case?
Hi Matthew,
The following change works in my environment. What do you think?
Thanks,
-Toshi
---
fs/dax.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/dax.c b/fs/dax.c
index 2d6b4bc..046c6d6 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
int dax_clear_blocks(struct inode *inode, sector_t block, long size)
{
@@ -385,6 +386,8 @@ static int do_dax_fault(struct vm_area_struct *vma,
struct vm_fault *vmf,
mutex_unlock(>i_mmap_mutex);
if (page) {
+ if (page_mapped(page))
+ try_to_unmap(page, TTU_UNMAP|TTU_IGNORE_ACCESS);
delete_from_page_cache(page);
unmap_mapping_range(mapping, vmf->pgoff << PAGE_SHIFT,
PAGE_CACHE_SIZE, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
regarding use of various cmpxchg* API
Hi Peter, Ingo, I see that in the drivers there are the following types of cmpxchg API: __cmpxchg64() atomic_cmpxchg() atomic64_cmpxchg() cmpxchg() atomic_long_cmpxchg() cmpxchg_local() local_cmpxchg()(in kernel/events/ring_buffer.c) this_cpu_cmpxchg() Since cmpxchg() internally handles the width, do you think it makes sense to replace the above uses of cmpxchg with the document API (cmpxchg, atomic_cmpxchg, cmpxchg_local)? I am willing to do this and wanted to know if it something you think is worth pursuing. Regards, Pranith -- 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] net: phy: fix sparse warning in fixed.c
From: Konrad Zapalowicz Date: Thu, 5 Jun 2014 20:27:42 +0200 > This commit fixes the following sparse warning: > > drivers/net/phy/fixed.c:207 > - warning: symbol 'fixed_phy_del' was not declared. > Should it be static? > > by adding symbol definition to the phy_fixed.h API file. It is ok to do > because the function in question is an exported symbol. > > Signed-off-by: Konrad Zapalowicz Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Change in security maintainer for a few weeks
On Thursday, June 05, 2014 11:59:11 PM Jiri Kosina wrote: > On Thu, 5 Jun 2014, Greg KH wrote: > > James has had to step back from doing kernel work for a few weeks, so > > I've offered to step up and handle the security patches to get shuttled > > to Linus for merging for a while. > > As exactly this (working with active contributors to help co-maintain the > subsystem) has been brought at the ksummit maling list, I am just curious > whether noone else actively working in that area was willing to step up? > > $ ./scripts/get_maintainer.pl --git -f security/ > James Morris (supporter:SECURITY SUBSYSTEM) >... > > If not, then I think this can be shown as a prime example why the problem > of "non-substituability" of many maintainers is actually real. Once several of us became aware that James was stepping away for a few weeks (I should mention this was not a planned absence and took most of us by surprise) we had a brief discussion off-list and several of us did offer to "step-up"; Serge had already created a repo and since he had pushed patches while James was away in the past it seemed a reasonable approach this time around. -- 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/
[PATCH ftrace/core 0/3] ftrace: Fix three small bugs
Hi Steven, I found three small bugs for current ftrace/core, so I fixed those. Would you apply these patches? Thanks! --- Yoshihiro YUNOMAE (3): trace/event: Return error if ftrace_trace_arrays is empty list trace/kprobes: Avoid self tests if tracing is disabled on boot up trace: Fix memory leak when new instance creation failed kernel/trace/trace.c| 23 ++- kernel/trace/trace.h|3 +++ kernel/trace/trace_events.c | 13 + kernel/trace/trace_kprobe.c |3 +++ 4 files changed, 33 insertions(+), 9 deletions(-) -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.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/
[PATCH ftrace/core 3/3] trace: Fix memory leak when new instance creation failed
Current new_instance_create() implements just two fail paths for four
allocation operations. So, it can induce memory leak if new instance
creation failed. This patch fixes it by defining all fail paths and
freeing allocated memories appropriately.
Signed-off-by: Yoshihiro YUNOMAE
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
---
kernel/trace/trace.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 473eb68..bbd86d2 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6277,7 +6277,7 @@ static int new_instance_create(const char *name)
goto out_free_tr;
if (!alloc_cpumask_var(>tracing_cpumask, GFP_KERNEL))
- goto out_free_tr;
+ goto out_free_tr_name;
cpumask_copy(tr->tracing_cpumask, cpu_all_mask);
@@ -6291,16 +6291,16 @@ static int new_instance_create(const char *name)
INIT_LIST_HEAD(>events);
if (allocate_trace_buffers(tr, trace_buf_size) < 0)
- goto out_free_tr;
+ goto out_free_cpumask_var;
tr->dir = debugfs_create_dir(name, trace_instance_dir);
if (!tr->dir)
- goto out_free_tr;
+ goto out_free_trace_buffers;
ret = event_trace_add_tracer(tr->dir, tr);
if (ret) {
debugfs_remove_recursive(tr->dir);
- goto out_free_tr;
+ goto out_free_trace_buffers;
}
init_tracer_debugfs(tr, tr->dir);
@@ -6311,18 +6311,23 @@ static int new_instance_create(const char *name)
return 0;
- out_free_tr:
- if (tr->trace_buffer.buffer)
- ring_buffer_free(tr->trace_buffer.buffer);
+ out_free_trace_buffers:
+ ring_buffer_free(tr->trace_buffer.buffer);
+ free_percpu(tr->trace_buffer.data);
+#ifdef CONFIG_TRACER_MAX_TRACE
+ ring_buffer_free(tr->max_buffer.buffer);
+ free_percpu(tr->max_buffer.data);
+#endif
+ out_free_cpumask_var:
free_cpumask_var(tr->tracing_cpumask);
+ out_free_tr_name:
kfree(tr->name);
+ out_free_tr:
kfree(tr);
-
out_unlock:
mutex_unlock(_types_lock);
return ret;
-
}
static int instance_delete(const char *name)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH ftrace/core 1/3] trace/event: Return error if ftrace_trace_arrays is empty list
ftrace_trace_arrays links global_trace.list. However, global_trace is not added
to ftrace_trace_arrays if trace_alloc_buffers() failed. As the result,
ftrace_trace_arrays becomes empty list. If ftrace_trace_arrays is empty list,
current top_trace_array() returns invalid pointer. As the result, the kernel
can induce memory corruption or panic.
Current implementation does not check whether ftrace_trace_arrays is empty
list or not. So, in this patch, if ftrace_trace_arrays is empty list,
top_trace_array() returns NULL. Moreover, this patch makes all functions calling
top_trace_array() handle it appropriately.
Signed-off-by: Yoshihiro YUNOMAE
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
---
kernel/trace/trace.h|3 +++
kernel/trace/trace_events.c | 13 +
2 files changed, 16 insertions(+)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 217207a..9e82551 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -252,6 +252,9 @@ static inline struct trace_array *top_trace_array(void)
{
struct trace_array *tr;
+ if (list_empty(ftrace_trace_arrays.prev))
+ return NULL;
+
tr = list_entry(ftrace_trace_arrays.prev,
typeof(*tr), list);
WARN_ON(!(tr->flags & TRACE_ARRAY_FL_GLOBAL));
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 3ddfd8f..1349870 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -574,6 +574,9 @@ int trace_set_clr_event(const char *system, const char
*event, int set)
{
struct trace_array *tr = top_trace_array();
+ if (!tr)
+ return -ENODEV;
+
return __ftrace_set_clr_event(tr, NULL, system, event, set);
}
EXPORT_SYMBOL_GPL(trace_set_clr_event);
@@ -2065,6 +2068,9 @@ event_enable_func(struct ftrace_hash *hash,
bool enable;
int ret;
+ if (!tr)
+ return -ENODEV;
+
/* hash funcs only work with set_ftrace_filter */
if (!enabled || !param)
return -EINVAL;
@@ -2396,6 +2402,9 @@ static __init int event_trace_enable(void)
char *token;
int ret;
+ if (!tr)
+ return -ENODEV;
+
for_each_event(iter, __start_ftrace_events, __stop_ftrace_events) {
call = *iter;
@@ -2442,6 +2451,8 @@ static __init int event_trace_init(void)
int ret;
tr = top_trace_array();
+ if (!tr)
+ return -ENODEV;
d_tracer = tracing_init_dentry();
if (!d_tracer)
@@ -2535,6 +2546,8 @@ static __init void event_trace_self_tests(void)
int ret;
tr = top_trace_array();
+ if (!tr)
+ return -ENODEV;
pr_info("Running tests on trace events:\n");
--
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 ftrace/core 2/3] trace/kprobes: Avoid self tests if tracing is disabled on boot up
If tracing is disabled on boot up, the kernel should not execute self tests.
In this patch, the kernel checks whether tracing is disabled or not
before executing self tests.
Signed-off-by: Yoshihiro YUNOMAE
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Masami Hiramatsu
Cc: linux-kernel@vger.kernel.org
---
kernel/trace/trace_kprobe.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 903ae28..ef2fba1 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1377,6 +1377,9 @@ static __init int kprobe_trace_self_tests_init(void)
struct trace_kprobe *tk;
struct ftrace_event_file *file;
+ if (tracing_is_disabled())
+ return -ENODEV;
+
target = kprobe_trace_selftest_target;
pr_info("Testing kprobe tracing: ");
--
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 v1 1/1] Add kernel parameter for kernel version
On Thu, 5 Jun 2014, eric ernst wrote: > We have a need to keep a single product binary (kernel) across multiple > android devices. A subset of these platforms are looking for extra versioning > information appended to it, accessible via /proc/version. Rather than build > multiple otherwise identical kernels with only this extended versioning as > differentiation, we are looking to make this a command line parameter. > Understandable if there isn't enough value-add for the community in this > patch, but I figured I'd give the patch a shot, as we need this functionality > locally. Thanks. Unrecognized parameters on the kernel command line are disregarded, so your platforms should be able to parse /proc/cmdline for version_addendum=foo already. -- 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 v1 1/1] Add kernel parameter for kernel version
On 06/05/2014 03:15 PM, eric ernst wrote: > > On 14-06-05 03:16 PM, Andrew Morton wrote: >> On Thu, 5 Jun 2014 15:09:17 -0700 eric.er...@linux.intel.com wrote: >> >>> Create a kernel cmdline parameter, "version_addendum", which can be >>> used to add text to the kernel version that is reported from >>> /proc/version. >> why? > We have a need to keep a single product binary (kernel) across multiple > android devices. A subset of these platforms are looking for extra > versioning information appended to it, accessible via /proc/version. Rather > than build multiple otherwise identical kernels with only this extended > versioning as differentiation, we are looking to make this a command line > parameter. Understandable if there isn't enough value-add for the community > in this patch, but I figured I'd give the patch a shot, as we need this > functionality locally. Thanks. Please use a newline character every 70-72 characters instead of assuming that all email programs will break that extra long line up into a readable format. (mine does not.) What software needs to know the version info? how early does it run? Could it get the version info from 'uname -r' instead of from /proc/version? thanks, -- ~Randy -- 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] clk: exynos5420: Remove aclk66_peric from the clock tree description
On 05.06.2014 22:35, Doug Anderson wrote: > The "aclk66_peric" clock is a gate clock with a whole bunch of gates > underneath it. This big gate isn't very useful to include in our > clock tree. If any of the children need to be turned on then the big > gate will need to be on anyway. ...and there are plenty of other "big > gates" that aren't described in our clock tree, some of which shut off > collections of clocks that have no relationship in the hierarchy so > are hard to model. > > "aclk66_peric" is causing earlyprintk problems since it gets disabled > as part of the boot process, so let's just remove it. > > Strangely (and for no good reason) this clock is exported as part of > the common clock bindings. Remove it since there are no in-kernel > device trees using it and no reason anyone out of tree should refer to > it either. > > Signed-off-by: Doug Anderson > --- > Changes in v3: > - Now just remove aclk66_peric from the tree as suggested by Tomasz. > > Changes in v2: > - Use GATE_A and clk_get(). Save the clock for putting later. > - Return 0 from exynos5420_clk_late_init(). > > drivers/clk/samsung/clk-exynos5420.c | 85 > ++ > include/dt-bindings/clock/exynos5420.h | 1 - > 2 files changed, 55 insertions(+), 31 deletions(-) > Mike, I can take this patch to my tree as a fix for 3.16-rc, or if still possible and you don't mind, feel free to apply it directly with my ACK: Acked-by: Tomasz Figa Best regards, Tomasz -- 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] stmmac: extend DMA initialization delay to 2.5 seconds
From: Alexey Brodkin Date: Thu, 5 Jun 2014 16:58:00 +0400 > On some platforms existing 100 msecond delay is not enough for DMA block to > recover after reset. This is because MAC DMA waits for all PHY input clocks > to present and depending on the board reset bit deassertion may take much > longer than previously used 100 milliseconds > > I have a board that requires more than 2 seconds for DMA to zero "reset" bit. > If for other boards it's still not long enough this value should be extended > once again. > > In the same change I convert "mdelay" to "msleep" to make CPU available for > other processes during DMA init delay which is especially useful in case of > delay for a few seconds. > > Signed-off-by: Alexey Brodkin This will not work, you cannot sleep with spinlocks held, and this code is absolutely called in such a context. For example stmmac_resume() --> stmmac_hw_setup() -> stmmac_init_dma_engine(). stmmac_resume() holds priv->lock over all of these operations, and even has interrupts disabled. -- 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] hwmon: add support for Sensirion SHTC1 sensor
From: Tomas Pop
Add support for Sensirion SHTC1 and compatible temperature and humidity
sensors.
Signed-off-by: Tomas Pop
---
This is a fourth version of the driver, we inlcuded suggested corrections,
i.e., hwmon_dev field is removed from shtc1 structure, correct variable is
tested in probe function and we use DEVICE_ATTR_RO instead of DEVICE_ATTR.
Patch was generated against v3.14.4 (the version we used for testing of
driver functionality), but it can be applied smoothly to v3.15-rc8.
Documentation/hwmon/shtc1 | 43 ++
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/shtc1.c | 251
include/linux/platform_data/shtc1.h | 23
5 files changed, 328 insertions(+)
create mode 100644 Documentation/hwmon/shtc1
create mode 100644 drivers/hwmon/shtc1.c
create mode 100644 include/linux/platform_data/shtc1.h
diff --git a/Documentation/hwmon/shtc1 b/Documentation/hwmon/shtc1
new file mode 100644
index 000..da16ed6
--- /dev/null
+++ b/Documentation/hwmon/shtc1
@@ -0,0 +1,43 @@
+Kernel driver shtc1
+===
+
+Supported chips:
+ * Sensirion SHTC1
+Prefix: 'shtc1'
+Addresses scanned: none
+Datasheet: http://www.sensirion.com/file/datasheet_shtc1
+
+ * Sensirion SHTW1
+Prefix: 'shtw1'
+Addresses scanned: none
+Datasheet: Not publicly available
+
+Author:
+ Johannes Winkelmann
+
+Description
+---
+
+This driver implements support for the Sensirion SHTC1 chip, a humidity and
+temperature sensor. Temperature is measured in degrees celsius, relative
+humidity is expressed as a percentage. Driver can be used as well for SHTW1
+chip, which has the same electrical interface.
+
+The device communicates with the I2C protocol. All sensors are set to I2C
+address 0x70. See Documentation/i2c/instantiating-devices for methods to
+instantiate the device.
+
+There are two options configurable by means of shtc1_platform_data:
+1. blocking (pull the I2C clock line down while performing the measurement) or
+ non-blocking mode. Blocking mode will guarantee the fastest result but
+ the I2C bus will be busy during that time. By default, non-blocking mode
+ is used. Make sure clock-stretching works properly on your device if you
+ want to use blocking mode.
+2. high or low accuracy. High accuracy is used by default and using it is
+ strongly recommended.
+
+sysfs-Interface
+---
+
+temp1_input - temperature input
+humidity1_input - humidity input
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 193c496..7f56ae1 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1047,6 +1047,16 @@ config SENSORS_SHT21
This driver can also be built as a module. If so, the module
will be called sht21.
+config SENSORS_SHTC1
+ tristate "Sensiron humidity and temperature sensors. SHTC1 and compat."
+ depends on I2C
+ help
+ If you say yes here you get support for the Sensiron SHTC1 and SHTW1
+ humidity and temperature sensors.
+
+ This driver can also be built as a module. If so, the module
+ will be called shtc1.
+
config SENSORS_S3C
tristate "Samsung built-in ADC"
depends on S3C_ADC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index a06e078..311932f 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
obj-$(CONFIG_SENSORS_SCH5636) += sch5636.o
obj-$(CONFIG_SENSORS_SHT15)+= sht15.o
obj-$(CONFIG_SENSORS_SHT21)+= sht21.o
+obj-$(CONFIG_SENSORS_SHTC1)+= shtc1.o
obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o
obj-$(CONFIG_SENSORS_SMM665) += smm665.o
obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o
diff --git a/drivers/hwmon/shtc1.c b/drivers/hwmon/shtc1.c
new file mode 100644
index 000..430a066
--- /dev/null
+++ b/drivers/hwmon/shtc1.c
@@ -0,0 +1,251 @@
+/* Sensirion SHTC1 humidity and temperature sensor driver
+ *
+ * Copyright (C) 2014 Sensirion AG, Switzerland
+ * Author: Johannes Winkelmann
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* commands (high precision mode) */
+static const unsigned char shtc1_cmd_measure_blocking_hpm[]= { 0x7C, 0xA2
};
+static const unsigned char shtc1_cmd_measure_nonblocking_hpm[] = { 0x78, 0x66
};
+
+/*
[PATCH 1/1] use documented cmpxchg api
use the documented atomic_cmpxchg instead of __cmpxchg64 This kills the last user of said API in drivers code. Signed-off-by: Pranith Kumar --- drivers/iommu/intel-iommu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 6bb3277..270113f 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -293,7 +293,7 @@ static inline u64 dma_pte_addr(struct dma_pte *pte) return pte->val & VTD_PAGE_MASK; #else /* Must have a full atomic 64-bit read */ - return __cmpxchg64(>val, 0ULL, 0ULL) & VTD_PAGE_MASK; + return atomic_cmpxchg(>val, 0ULL, 0ULL) & VTD_PAGE_MASK; #endif } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v6 17/20] vfio: add local lock in virqfd instead of depending on VFIO PCI
On Thu, 2014-06-05 at 19:03 +0200, Antonios Motakis wrote:
> Sharing the same spinlock with the VFIO bus driver is not necessary for
> the virqfd code, so remove that dependency.
I like the idea of consolidating this code, but I need more
justification for why the use of the lock here is independent of the bus
driver and why it's ok to move from a per-device lock to a global lock.
Thanks,
Alex
>
> Signed-off-by: Antonios Motakis
> ---
> drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
> drivers/vfio/virqfd.c | 24 +---
> include/linux/vfio.h | 3 +--
> 3 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
> b/drivers/vfio/pci/vfio_pci_intrs.c
> index 3f909bb..e56c814 100644
> --- a/drivers/vfio/pci/vfio_pci_intrs.c
> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> @@ -226,8 +226,8 @@ static int vfio_intx_set_signal(struct vfio_pci_device
> *vdev, int fd)
> static void vfio_intx_disable(struct vfio_pci_device *vdev)
> {
> vfio_intx_set_signal(vdev, -1);
> - virqfd_disable(vdev, >ctx[0].unmask);
> - virqfd_disable(vdev, >ctx[0].mask);
> + virqfd_disable(>ctx[0].unmask);
> + virqfd_disable(>ctx[0].mask);
> vdev->irq_type = VFIO_PCI_NUM_IRQS;
> vdev->num_ctx = 0;
> kfree(vdev->ctx);
> @@ -377,8 +377,8 @@ static void vfio_msi_disable(struct vfio_pci_device
> *vdev, bool msix)
> vfio_msi_set_block(vdev, 0, vdev->num_ctx, NULL, msix);
>
> for (i = 0; i < vdev->num_ctx; i++) {
> - virqfd_disable(vdev, >ctx[i].unmask);
> - virqfd_disable(vdev, >ctx[i].mask);
> + virqfd_disable(>ctx[i].unmask);
> + virqfd_disable(>ctx[i].mask);
> }
>
> if (msix) {
> @@ -415,7 +415,7 @@ static int vfio_pci_set_intx_unmask(struct
> vfio_pci_device *vdev,
>vfio_send_intx_eventfd, NULL,
>>ctx[0].unmask, fd);
>
> - virqfd_disable(vdev, >ctx[0].unmask);
> + virqfd_disable(>ctx[0].unmask);
> }
>
> return 0;
> diff --git a/drivers/vfio/virqfd.c b/drivers/vfio/virqfd.c
> index 9cf2842..4528450 100644
> --- a/drivers/vfio/virqfd.c
> +++ b/drivers/vfio/virqfd.c
> @@ -17,6 +17,7 @@
> #include "pci/vfio_pci_private.h"
>
> static struct workqueue_struct *vfio_irqfd_cleanup_wq;
> +static spinlock_t lock;
>
> int __init vfio_pci_virqfd_init(void)
> {
> @@ -25,6 +26,8 @@ int __init vfio_pci_virqfd_init(void)
> if (!vfio_irqfd_cleanup_wq)
> return -ENOMEM;
>
> + spin_lock_init();
> +
> return 0;
> }
>
> @@ -53,21 +56,21 @@ static int virqfd_wakeup(wait_queue_t *wait, unsigned
> mode, int sync, void *key)
>
> if (flags & POLLHUP) {
> unsigned long flags;
> - spin_lock_irqsave(>vdev->irqlock, flags);
> + spin_lock_irqsave(, flags);
>
> /*
>* The eventfd is closing, if the virqfd has not yet been
>* queued for release, as determined by testing whether the
> - * vdev pointer to it is still valid, queue it now. As
> + * virqfd pointer to it is still valid, queue it now. As
>* with kvm irqfds, we know we won't race against the virqfd
> - * going away because we hold wqh->lock to get here.
> + * going away because we hold the lock to get here.
>*/
> if (*(virqfd->pvirqfd) == virqfd) {
> *(virqfd->pvirqfd) = NULL;
> virqfd_deactivate(virqfd);
> }
>
> - spin_unlock_irqrestore(>vdev->irqlock, flags);
> + spin_unlock_irqrestore(, flags);
> }
>
> return 0;
> @@ -143,16 +146,16 @@ int virqfd_enable(struct vfio_pci_device *vdev,
>* we update the pointer to the virqfd under lock to avoid
>* pushing multiple jobs to release the same virqfd.
>*/
> - spin_lock_irq(>irqlock);
> + spin_lock_irq();
>
> if (*pvirqfd) {
> - spin_unlock_irq(>irqlock);
> + spin_unlock_irq();
> ret = -EBUSY;
> goto err_busy;
> }
> *pvirqfd = virqfd;
>
> - spin_unlock_irq(>irqlock);
> + spin_unlock_irq();
>
> /*
>* Install our own custom wake-up handling so we are notified via
> @@ -189,19 +192,18 @@ err_fd:
> return ret;
> }
>
> -void virqfd_disable(struct vfio_pci_device *vdev,
> -struct virqfd **pvirqfd)
> +void virqfd_disable(struct virqfd **pvirqfd)
> {
> unsigned long flags;
>
> - spin_lock_irqsave(>irqlock, flags);
> + spin_lock_irqsave(, flags);
>
> if (*pvirqfd) {
> virqfd_deactivate(*pvirqfd);
> *pvirqfd = NULL;
> }
>
> - spin_unlock_irqrestore(>irqlock, flags);
> +
