[GIT PULL] /dev/random fixes for 3.16
The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab: Linux 3.16-rc5 (2014-07-13 14:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/random_for_linus_stable for you to fetch changes up to 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc: random: check for increase of entropy_count because of signed conversion (2014-07-19 01:42:13 -0400) Fix a BUG splat found by trinity. Hannes Frederic Sowa (1): random: check for increase of entropy_count because of signed conversion drivers/char/random.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) -- 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] random: check for increase of entropy_count because of signed conversion
On Sat, Jul 19, 2014 at 01:35:48AM +0200, Hannes Frederic Sowa wrote:
> > + nfrac = ibytes << (ENTROPY_SHIFT + 3);
> > + if (entropy_count < 0) {
>
> Minor nit: maybe also add an unlikely() here?
Yep, done.
> > + if ((unsigned) entropy_count > nfrac)
>
> (unsigned) -> (size_t)
>
> size_t could also be (unsigned long) so the plain (unsigned) is
> misleading.
Good point, done.
> (Maybe I wouldn't have done the cast at all, as we compile the kernel
> with -Wno-sign-compare and we have the < 0 check right above, but I
> don't have a strong opinion on that.)
I also wanted to shut up other static code checkers like Coverity. :-)
> > + nbytes = min_t(size_t, nbytes, INT_MAX >> ENTROPY_SHIFT);
>
> Hmm, not sure, nfracs unit is 1/8 bits, so don't we have to limit nbytes
> to INT_MAX >> (ENTROPY_SHIFT + 3) here?
Good catch, done.
> And if we want to be even more correct here, we could switch from
> INT_MAX to SIZE_MAX, as we do all nfrac calculations in the size_t
> domain.
The main reason why I used INT_MAX was as a further safety check to
protect the:
entropy_count -= nfrac;
calculation, since nfrac is size_t and entropy_count is int.
In fact I think this online change ("nbytes = min_t(size_t, nbytes,
INT_MAX >> (ENTROPY_SHIFT + 3));") would have been enough to fix the
problem all by itself, but the other changes results in code which is
cleaner and easier to understand, and I'm a firm believer in multiple
layers of protection. :-)
Cheers,
- Ted
commit 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc
Author: Hannes Frederic Sowa
Date: Fri Jul 18 17:26:41 2014 -0400
random: check for increase of entropy_count because of signed conversion
The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
actually increase entropy_count if during assignment of the unsigned
expression on the RHS (mind the -=) we reduce the value modulo
2^width(int) and assign it to entropy_count. Trinity found this.
[ Commit modified by tytso to add an additional safety check for a
negative entropy_count -- which should never happen, and to also add
an additional paranoia check to prevent overly large count values to
be passed into urandom_read(). ]
Reported-by: Dave Jones
Signed-off-by: Hannes Frederic Sowa
Signed-off-by: Theodore Ts'o
Cc: sta...@vger.kernel.org
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0a7ac0a..71529e1 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -641,7 +641,7 @@ retry:
} while (unlikely(entropy_count < pool_size-2 && pnfrac));
}
- if (entropy_count < 0) {
+ if (unlikely(entropy_count < 0)) {
pr_warn("random: negative entropy/overflow: pool %s count %d\n",
r->name, entropy_count);
WARN_ON(1);
@@ -981,7 +981,7 @@ static size_t account(struct entropy_store *r, size_t
nbytes, int min,
int reserved)
{
int entropy_count, orig;
- size_t ibytes;
+ size_t ibytes, nfrac;
BUG_ON(r->entropy_count > r->poolinfo->poolfracbits);
@@ -999,7 +999,17 @@ retry:
}
if (ibytes < min)
ibytes = 0;
- if ((entropy_count -= ibytes << (ENTROPY_SHIFT + 3)) < 0)
+
+ if (unlikely(entropy_count < 0)) {
+ pr_warn("random: negative entropy count: pool %s count %d\n",
+ r->name, entropy_count);
+ WARN_ON(1);
+ entropy_count = 0;
+ }
+ nfrac = ibytes << (ENTROPY_SHIFT + 3);
+ if ((size_t) entropy_count > nfrac)
+ entropy_count -= nfrac;
+ else
entropy_count = 0;
if (cmpxchg(>entropy_count, orig, entropy_count) != orig)
@@ -1376,6 +1386,7 @@ urandom_read(struct file *file, char __user *buf, size_t
nbytes, loff_t *ppos)
"with %d bits of entropy available\n",
current->comm, nonblocking_pool.entropy_total);
+ nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
ret = extract_entropy_user(_pool, buf, nbytes);
trace_urandom_read(8 * nbytes, ENTROPY_BITS(_pool),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARM: SoC fixes for 3.16-rc
Hi Linus, The following changes since commit cacadb4ff969a82628d47db87b5a531be466b134: Merge tag 'samsung-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes (2014-07-12 21:19:21 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to 9637f30e6b7bc394c08fa9d27d63622f141142e9: ARM: EXYNOS: Fix core ID used by platsmp and hotplug code (2014-07-18 17:12:57 -0700) ARM: SoC fixes for 3.16-rc A smaller set of fixes this week, and all regression fixes: - a handful of issues fixed on at91 with common clock conversion - a set of fixes for Marvell mvebu (SMP, coherency, PM) - a clock fix for i.MX6Q. - ... and a SMP/hotplug fix for Exynos Bo Shen (1): ARM: at91: at91sam9x5: correct typo error for ohci clock Boris BREZILLON (2): ARM: at91/dt: fix usb0 clocks definition in sam9n12 dtsi ARM: at91/dt: add missing clocks property to pwm node in sam9x5.dtsi Ezequiel Garcia (1): ARM: mvebu: Fix coherency bus notifiers by using separate notifiers Gregory CLEMENT (1): ARM: mvebu: Fix the operand list in the inline asm of armada_370_xp_pmsu_idle_enter Lucas Stach (1): ARM: clk-imx6q: parent lvds_sel input from upstream clock gates Olof Johansson (3): Merge tag 'mvebu-fixes-3.16-3' of git://git.infradead.org/linux-mvebu into fixes Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixes Merge tag 'imx-fixes-3.16-2' of git://git.kernel.org/.../shawnguo/linux into fixes Thomas Petazzoni (1): ARM: mvebu: fix SMP boot for Armada 38x and Armada 375 Z1 in big endian Tomasz Figa (1): ARM: EXYNOS: Fix core ID used by platsmp and hotplug code arch/arm/boot/dts/at91sam9n12.dtsi | 2 +- arch/arm/boot/dts/at91sam9x5.dtsi | 4 ++-- arch/arm/mach-exynos/hotplug.c | 10 ++ arch/arm/mach-exynos/platsmp.c | 34 +++--- arch/arm/mach-imx/clk-imx6q.c | 4 ++-- arch/arm/mach-mvebu/coherency.c| 6 +- arch/arm/mach-mvebu/headsmp-a9.S | 9 - arch/arm/mach-mvebu/pmsu.c | 10 +- 8 files changed, 48 insertions(+), 31 deletions(-) -- 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] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()
在 2014年7月19日，上午2:21，Rajesh Borundia 写道： >> -Original Message- >> From: Ethan Zhao [mailto:ethan.z...@oracle.com] >> Sent: Friday, July 18, 2014 9:13 AM >> To: Manish Chopra; Sony Chacko; Rajesh Borundia; netdev >> Cc: linux-kernel; ethan.ker...@gmail.com; Ethan Zhao >> Subject: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool >> get_ethtool_stats() >> >> netxen driver has implemented netxen_nic_get_ethtool_stats() interface, >> but it doesn't collect stats.rxdropped in driver, so we will get different >> rx_dropped statistic information while using ifconfig and ethtool. >> this patch fills stats.rxdropped field with data from net core with >> dev_get_stats() just as ixgbe driver did for some of its stats. > > I think ethtool stats are adapter specific. Driver does not maintain > rx_dropped stats and we also don't get it from adapter. I am not > sure if ethtool stats should match ifconfig stats as ifconfig also > adds net core stats to adapter stats. I held the same point as yours before I read more drivers implementation under Ethernet dir, in fact there is no specification/convention that ethtool info is adapter Specific. All information output by ethtool is based on the information name itself, One fact we want this patch is netxen defined 'rx dropped' field but output nothing. > > If ethtool stats should report same values as ifconfig stats then > we may also need to fix tx_dropped statistics. > at least, tx dropped output information... Thanks, Ethan > Thanks, > Rajesh -- 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] parisc: Remove FIXME comment
On Sat, Jul 19, 2014 at 1:20 AM, James Bottomley wrote: > On Fri, 2014-07-18 at 22:25 -0400, Nick Krause wrote: >> On Fri, Jul 18, 2014 at 5:03 PM, James Bottomley >> wrote: >> > On Fri, 2014-07-18 at 16:37 -0400, Nicholas Krause wrote: >> >> The comment for size of frame not being needed is incorrect , the >> >> function called needs this parameter. >> > >> > Actually, that's not correct. The point of the FIXME is that fram_size >> > is only used in a debug print and could be eliminated since the >> > internals of the function excluding the debugging statements don't use >> > it. >> > >> > James >> > >> > >> >> So I need to need a patch removing the parameter from the function >> and this part of the code? > > Well, no, I'm not sure there's any action to take. The FIXME reminds us > that there's no actual use of the frame size in the function body except > for the debugging prints. The parameter could be removed if everyone > who debugs the kernel agrees either to remove the debug code or remove > the frame pointer from the prints, but it's probably not worth bothering > about, which is why it's still there. > > James > > Ok then , seems its going through I can however write some comments to explain this if needed. Cheers Nick -- 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] parisc: Remove FIXME comment
On Fri, 2014-07-18 at 22:25 -0400, Nick Krause wrote: > On Fri, Jul 18, 2014 at 5:03 PM, James Bottomley > wrote: > > On Fri, 2014-07-18 at 16:37 -0400, Nicholas Krause wrote: > >> The comment for size of frame not being needed is incorrect , the > >> function called needs this parameter. > > > > Actually, that's not correct. The point of the FIXME is that fram_size > > is only used in a debug print and could be eliminated since the > > internals of the function excluding the debugging statements don't use > > it. > > > > James > > > > > > So I need to need a patch removing the parameter from the function > and this part of the code? Well, no, I'm not sure there's any action to take. The FIXME reminds us that there's no actual use of the frame size in the function body except for the debugging prints. The parameter could be removed if everyone who debugs the kernel agrees either to remove the debug code or remove the frame pointer from the prints, but it's probably not worth bothering about, which is why it's still there. James -- 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] mips: Remove uneeded line in cmp_smp_finish
This patch removes a unneeded line from this file as stated by the
fix me in this file.
Signed-off-by: Nicholas Krause
---
arch/mips/kernel/smp-cmp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/mips/kernel/smp-cmp.c b/arch/mips/kernel/smp-cmp.c
index fc8a515..61bfa20 100644
--- a/arch/mips/kernel/smp-cmp.c
+++ b/arch/mips/kernel/smp-cmp.c
@@ -60,8 +60,6 @@ static void cmp_smp_finish(void)
{
pr_debug("SMPCMP: CPU%d: %s\n", smp_processor_id(), __func__);
- /* CDFIXME: remove this? */
- write_c0_compare(read_c0_count() + (8 * mips_hpt_frequency / HZ));
#ifdef CONFIG_MIPS_MT_FPAFF
/* If we have an FPU, enroll ourselves in the FPU-full mask */
--
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/
3.14.12 and option_instat_callback with 3G DONGLE
Since upgrading from 3.12.24 kernel to 3.14.10, and today, .12 kernel log and dmesg are flooded with constant messages option1 ttyUSB0: option_instat_callback: error -2 The device still works, it sends and receives SMS's as well, I tried setting verbose usb debug to see if it offers any more explanations, but it shows nothing more. The device is Huawei E160, but is identified as (and always has been) an E620 ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem Did somthing break between 3.12 and 3.14? Rather annoying at how fast and large kernel.log is geting. -- 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] sched_clock: Track monotonic raw clock
On Fri, Jul 18, 2014 at 06:43:39PM +0100, Pawel Moll wrote: > > This code definitely needs more work and testing (I'm not 100% > sure if the Kp and Ki I've picked for the proportional and > integral terms are universal), I wouldn't bet on it. > but for now wanted to see > if this approach makes any sense whatsoever. You are reading sched_clock and mono-raw together every so often. Really stupid question: Why not just place that information into the trace buffer and let user space do the clock correction? ... > + /* Tune the cyc_to_ns formula */ > + mult_adj = sign * (error >> 2) + (cd.error_int >> 2); So Kp = Ki = 0.25? And did you say that the sample rate is 10/second? I guess that, while this works well on your machine, it might not always do so, depending on the mono-raw clock. Probably Kp/i need to be tunable to a particular system. Even better would be to leave this out of the kernel altogether. 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: How to automate checkpatch && get_maintainers && git send-email of commits range?
> Hi Steve > > Why not share your quilt skills, say by adding a file in the Document > directory? > > Hillf > -- > 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/ I agree with hillf here this may be of use to other developers on the lkml and you should write a file in the Document dictionary. Nick -- 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: How to automate checkpatch && get_maintainers && git send-email of commits range?
On Sat, Jul 19, 2014 at 9:31 AM, Steven Rostedt wrote: > On Fri, Jul 18, 2014 at 06:22:15PM -0400, Theodore Ts'o wrote: >> >> And then think very hard about which patches people need to see in >> order to be able to evaluate a patch. For example, if you have patch >> 1 out of a series which adds a new function, and then patches 2 >> through 1000 modify a thousand different drivers to use that new >> function, if you use an automated get_maintainers.pl script to send >> each patch to just the maintainer, then the device driver maintainer >> might not see patch #1 which is critical context to understanding the >> patch that you want to make to his driver. And then you will have >> several hundred very angry and annoyed developers wondering why you >> sent them patch 345/1000, with no other context, and wondering what >> the heck they are supposed to do with the email that you have just >> launched into their inbox. > > I'm still stuck in the old stone/quilt age, where I use quilt mail to > send my patch bombs. Although, I have scripts that pulls my patches out > from git with format-patch, and then creates a quilt queue from them. > I do this for that very reason that I want to review all patches before > I hit send, and quilt mail is very basic and sends what I tell it. > I still a bit gun shy from using git sendmail as I never got that to > work (note, the last time I tried, it was still doing the staircase > threads with patches by default). > > I'm still content with quilt, but the one thing I don't care about it > is that all Cc'd on the 0/1000 patch gets Cc'd on all patches. I wish > there was a way to tell quilt that they should only get Cc'd on the > cover patch and no more, unless the patch has them Cc'd. The reason this > bothers me is that I tend to do exactly what you stated above. I will > just Cc patch 345/1000 to someone with no context of what that patch > is. > > I figured people would do the same thing that I do when I get that 345th > patch. As I'm subscribed to LKML, I will just go into my lkml folder and > search for that patch and see how that thread applies to me with full > context. I'm assuming that's what others may do too. > Hi Steve Why not share your quilt skills, say by adding a file in the Document directory? Hillf -- 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] ARM: add IPI tracepoints
On Fri, 18 Jul 2014 22:55:12 -0400 (EDT) Nicolas Pitre wrote: > Any comments / ACKs on the other patches? I'd like to see 1/4 to 3/4 > (and your patch) merged upstream during the next window. 4/4 is up for > debate. You can add my Acked-by for patches 1,2 and 3, after the clean up of the #ifdefs there. I still don't like the fact that you need to add the #undef in patch 4. I'm looking at other ways to fix that. I tried to do a few different clean ups in the tracing infrastructure, but it seems that it may be required. The other method I may try is to move the #undefs into the ipi.h header itself. I'll play more with this on Monday. -- 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/
Hello
Hi friend, hope you are fine, My name is Benita Sayyed, I am lonely, tender, caring, faithful and honest girl, I am ready to give all my care, love, attention and devotion.I promise to send my recent pictures and tell you more about myself. Regards. Benita Sayyed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/1] rcu: Consolidate kthread launches
Hi Paul,
I looked at why my previous change removing checks for
rcu_scheduler_fully_active failed to boot.
The reason is that rcu_init() is called earlier than rest_init() from within
which the early_init() is being called. rcu_init() calls rcu_cpu_notify() which
in turn calls rcu_spawn_all_nocb_kthread().
This patch does the following:
* since we are launching other threads now from rcu_spawn_gp_kthread() rename it
to rcu_spawn_kthreads()
* move nocb kthread launches on cpu hotplug to rcu_prepare_kthreads(), the name
is generic so thre is no need to rename ;)
* check whether CPU is a no-CB CPU before calling rcu_spawn_all_nocb_kthreads()
on that CPU
I've got the KVM rcutorture setup running and verified these changes.
Side note: we should probably change the trace comment for rcu_cpu_notify()
which says it is for Hotplug :)
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c| 8
kernel/rcu/tree_plugin.h | 19 ---
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 72e0b1f..2866464 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3451,7 +3451,6 @@ static int rcu_cpu_notify(struct notifier_block *self,
case CPU_UP_PREPARE_FROZEN:
rcu_prepare_cpu(cpu);
rcu_prepare_kthreads(cpu);
- rcu_spawn_all_nocb_kthreads(cpu);
break;
case CPU_ONLINE:
case CPU_DOWN_FAILED:
@@ -3499,9 +3498,10 @@ static int rcu_pm_notify(struct notifier_block *self,
}
/*
- * Spawn the kthreads that handle each RCU flavor's grace periods.
+ * Spawn the kthreads that handle each RCU flavor's grace periods
+ * and the no-CB and boost kthreads.
*/
-static int __init rcu_spawn_gp_kthread(void)
+static int __init rcu_spawn_kthreads(void)
{
unsigned long flags;
struct rcu_node *rnp;
@@ -3521,7 +3521,7 @@ static int __init rcu_spawn_gp_kthread(void)
rcu_spawn_boost_kthreads();
return 0;
}
-early_initcall(rcu_spawn_gp_kthread);
+early_initcall(rcu_spawn_kthreads);
/*
* This function is invoked towards the end of the scheduler's initialization
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index eaa32e4..42e113b 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1339,7 +1339,7 @@ static int rcu_spawn_one_boost_kthread(struct rcu_state
*rsp,
if (_preempt_state != rsp)
return 0;
- if (!rcu_scheduler_fully_active || rnp->qsmaskinit == 0)
+ if (rnp->qsmaskinit == 0)
return 0;
rsp->boost = 1;
@@ -1486,9 +1486,14 @@ static void rcu_prepare_kthreads(int cpu)
struct rcu_data *rdp = per_cpu_ptr(rcu_state_p->rda, cpu);
struct rcu_node *rnp = rdp->mynode;
+ if (!rcu_scheduler_fully_active)
+ return;
+
/* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
- if (rcu_scheduler_fully_active)
- (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+ (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
+
+ if (rcu_is_nocb_cpu(cpu))
+ rcu_spawn_all_nocb_kthreads(cpu);
}
#else /* #ifdef CONFIG_RCU_BOOST */
@@ -2507,9 +2512,8 @@ static void rcu_spawn_all_nocb_kthreads(int cpu)
{
struct rcu_state *rsp;
- if (rcu_scheduler_fully_active)
- for_each_rcu_flavor(rsp)
- rcu_spawn_one_nocb_kthread(rsp, cpu);
+ for_each_rcu_flavor(rsp)
+ rcu_spawn_one_nocb_kthread(rsp, cpu);
}
/*
@@ -2523,7 +2527,8 @@ static void __init rcu_spawn_nocb_kthreads(void)
int cpu;
for_each_online_cpu(cpu)
- rcu_spawn_all_nocb_kthreads(cpu);
+ if (rcu_is_nocb_cpu(cpu))
+ rcu_spawn_all_nocb_kthreads(cpu);
}
/* How many follower CPU IDs per leader? Default of -1 for sqrt(nr_cpu_ids).
*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: add IPI tracepoints
On Fri, 18 Jul 2014, Steven Rostedt wrote:
> On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
> Nicolas Pitre wrote:
>
> >
> > Here's the patch I have at the head of the series now, with the above
> > ugliness changed to an unconditional __tracepoint_string attribute.
> >
>
> I was thinking of something like this. Feel free to add this to your
> series.
OK. Same end result, but much clearer. Thanks.
Any comments / ACKs on the other patches? I'd like to see 1/4 to 3/4
(and your patch) merged upstream during the next window. 4/4 is up for
debate.
> -- Steve
>
> From: Steven Rostedt
> Subject: [PATCH] tracing: Do not do anything special with tracepoint_string
> when tracing is disabled
>
> When CONFIG_TRACING is not enabled, there's no reason to save the trace
> strings either by the linker or as a static variable that can be
> referenced later. Simply pass back the string that is given to
> tracepoint_string().
>
> Signed-off-by: Steven Rostedt
> ---
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index cff3106..b296363 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -574,6 +574,7 @@ do {
> \
> __trace_printk(ip, fmt, ##args);\
> } while (0)
>
> +#ifdef CONFIG_TRACING
> /**
> * tracepoint_string - register constant persistent string to trace system
> * @str - a constant persistent string that will be referenced in tracepoints
> @@ -607,6 +608,15 @@ do {
> \
> ___tp_str; \
> })
> #define __tracepoint_string __attribute__((section("__tracepoint_str")))
> +#else
> +/*
> + * tracepoint_string() is used to save the string address for userspace
> + * tracing tools. When tracing isn't configured, there's no need to save
> + * anything.
> + */
> +# define tracepoint_string(str) str
> +# define __tracepoint_string
> +#endif
>
> #ifdef CONFIG_PERF_EVENTS
> struct perf_event;
>
>
--
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] usb-core: Remove Fix mes in file hcd.c
On Fri, Jul 18, 2014 at 10:45 PM, Nick Krause wrote: > Sorry didn't run spell check. I will resend this patch with the > correct information > as needed. Thanks for the advice, Sasha. > > Cheers Nick > > On Fri, Jul 18, 2014 at 10:36 PM, Sasha Levin wrote: >> On 07/18/2014 01:34 PM, Nicholas Krause wrote: >>> I am removing two fix mes in this file as after dicussing then it seems >>> there is no reason to check against Null for usb_device as it can never >>> be NULL and this is check is therefore not needed. >>> >>> Signed-off-by: Nicholas Krause >> >> Please explain exactly why it's not needed, why it can never be NULL, and >> what prevents it from being NULL. >> >> "after dicussing" (do you run spellcheck on your mails?) won't mean anything >> to someone looking at this commit in a year. >> >> Your commit message also mentions usb_device which has nothing to do with >> your patch. >> >> >> Thanks, >> Sasha Sasha , Greg seems to have signed it off. Cheers Nick -- 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] usb-core: Remove Fix mes in file hcd.c
Sorry didn't run spell check. I will resend this patch with the correct information as needed. Thanks for the advice, Sasha. Cheers Nick On Fri, Jul 18, 2014 at 10:36 PM, Sasha Levin wrote: > On 07/18/2014 01:34 PM, Nicholas Krause wrote: >> I am removing two fix mes in this file as after dicussing then it seems >> there is no reason to check against Null for usb_device as it can never >> be NULL and this is check is therefore not needed. >> >> Signed-off-by: Nicholas Krause > > Please explain exactly why it's not needed, why it can never be NULL, and > what prevents it from being NULL. > > "after dicussing" (do you run spellcheck on your mails?) won't mean anything > to someone looking at this commit in a year. > > Your commit message also mentions usb_device which has nothing to do with > your patch. > > > 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: [PATCH 3.12 000/170] 3.12.25-stable review
At Fri, 18 Jul 2014 06:47:32 -0700, Guenter Roeck wrote: > > On 07/18/2014 05:16 AM, Jiri Slaby wrote: > > On 07/18/2014 02:12 PM, Jiri Slaby wrote: > >> This is the start of the stable review cycle for the 3.12.25 release. > >> There are 170 patches in this series, all will be posted as a response > >> to this one. If anyone has any issues with these being applied, please > >> let me know. > >> > >> Responses should be made by Sun Jul 20 12:11:21 2014 > > > > Oh, this should have been two *workdays*, i.e. the deadline is Jul 22. > > > > Build results: > total: 137 pass: 137 fail: 0 > > Qemu tests all passed. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter > Plus, it passed my test too. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- 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] usb-core: Remove Fix mes in file hcd.c
On 07/18/2014 01:34 PM, Nicholas Krause wrote: > I am removing two fix mes in this file as after dicussing then it seems > there is no reason to check against Null for usb_device as it can never > be NULL and this is check is therefore not needed. > > Signed-off-by: Nicholas Krause Please explain exactly why it's not needed, why it can never be NULL, and what prevents it from being NULL. "after dicussing" (do you run spellcheck on your mails?) won't mean anything to someone looking at this commit in a year. Your commit message also mentions usb_device which has nothing to do with your patch. 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: [PATCH] parisc: Remove FIXME comment
On Fri, Jul 18, 2014 at 5:03 PM, James Bottomley wrote: > On Fri, 2014-07-18 at 16:37 -0400, Nicholas Krause wrote: >> The comment for size of frame not being needed is incorrect , the >> function called needs this parameter. > > Actually, that's not correct. The point of the FIXME is that fram_size > is only used in a debug print and could be eliminated since the > internals of the function excluding the debugging statements don't use > it. > > James > > So I need to need a patch removing the parameter from the function and this part of the code? Cheers Nick -- 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: Build Errors when building usb directory
On Fri, Jul 18, 2014 at 7:29 PM, Randy Dunlap wrote: > On 07/18/2014 12:59 PM, Nick Krause wrote: >> On Fri, Jul 18, 2014 at 2:10 PM, Randy Dunlap wrote: >>> On 07/18/2014 10:45 AM, Nick Krause wrote: Hey Greg and others, When I built the usb directory today to check a patch I am also sending to. I seem to hitting a few compiler errors and a lot of warnings. I am going to attach a file of my log of this build. Cheers Nick >>> >>> Hi, >>> >>> What command(s) did you use to build the usb directory? >>> >>> thanks, >>> -- >>> ~Randy >> I used make M=drivers/usb to build it. >> Cheers Nick > > > I'm not seeing any of these warnings, but I am testing 3.16-rc5. > > Nick, are you using a current git tree? If so, which one? > You should always specify what kernel it is that you are testing. > > > -- > ~Randy This is the lastest commit idea on my tree,f83971912231fe5390d2357442b6c25bb8076d9b. Cheers Nick -- 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] kbuild: add support to generate LLVM bitcode files
Allows kbuild to generate LLVM bitcode files with the .ll extension when building with Clang. # c code CC=clang make kernel/pid.ll # asm code CC=clang make arch/arm/kernel/calls.ll Signed-off-by: Vinícius Tinti Signed-off-by: Behan Webster --- Makefile | 7 +++ scripts/Makefile.build | 18 ++ 2 files changed, 25 insertions(+) diff --git a/Makefile b/Makefile index f3c543d..4eb0d14 100644 --- a/Makefile +++ b/Makefile @@ -1484,6 +1484,13 @@ endif %.symtypes: %.c prepare scripts FORCE $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@) +ifeq ($(COMPILER),clang) +%.ll: %.c prepare scripts FORCE + $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@) +%.ll: %.S prepare scripts FORCE + $(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@) +endif + # Modules /: prepare scripts FORCE $(cmd_crmodverdir) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index bf3e677..9ea19d6 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -174,6 +174,14 @@ cmd_cc_symtypes_c = \ $(obj)/%.symtypes : $(src)/%.c FORCE $(call cmd,cc_symtypes_c) +ifeq ($(COMPILER),clang) +quiet_cmd_cc_ll_c = CC $(quiet_modtag) $@ +cmd_cc_ll_c = $(CC) $(c_flags) $(DISABLE_LTO) -fverbose-asm -emit-llvm -S -o $@ $< + +$(obj)/%.ll: $(src)/%.c FORCE + $(call if_changed_dep,cc_ll_c) +endif + # C (.c) files # The C file is compiled and updated dependency information is generated. # (See cmd_cc_o_c + relevant part of rule_cc_o_c) @@ -315,6 +323,16 @@ quiet_cmd_asn1_compiler = ASN.1 $@ $(obj)/%-asn1.c $(obj)/%-asn1.h: $(src)/%.asn1 $(objtree)/scripts/asn1_compiler $(call cmd,asn1_compiler) +# LLVM bitcode +# --- +ifeq ($(COMPILER),clang) +quiet_cmd_as_ll_S = CPP $(quiet_modtag) $@ +cmd_as_ll_S = $(CPP) $(a_flags) -o $@ $< + +$(obj)/%.ll: $(src)/%.S FORCE + $(call if_changed_dep,as_ll_S) +endif + # Build the compiled-in targets # --- -- 2.0.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: How to automate checkpatch && get_maintainers && git send-email of commits range?
On Fri, Jul 18, 2014 at 06:22:15PM -0400, Theodore Ts'o wrote: > > And then think very hard about which patches people need to see in > order to be able to evaluate a patch. For example, if you have patch > 1 out of a series which adds a new function, and then patches 2 > through 1000 modify a thousand different drivers to use that new > function, if you use an automated get_maintainers.pl script to send > each patch to just the maintainer, then the device driver maintainer > might not see patch #1 which is critical context to understanding the > patch that you want to make to his driver. And then you will have > several hundred very angry and annoyed developers wondering why you > sent them patch 345/1000, with no other context, and wondering what > the heck they are supposed to do with the email that you have just > launched into their inbox. I'm still stuck in the old stone/quilt age, where I use quilt mail to send my patch bombs. Although, I have scripts that pulls my patches out from git with format-patch, and then creates a quilt queue from them. I do this for that very reason that I want to review all patches before I hit send, and quilt mail is very basic and sends what I tell it. I still a bit gun shy from using git sendmail as I never got that to work (note, the last time I tried, it was still doing the staircase threads with patches by default). I'm still content with quilt, but the one thing I don't care about it is that all Cc'd on the 0/1000 patch gets Cc'd on all patches. I wish there was a way to tell quilt that they should only get Cc'd on the cover patch and no more, unless the patch has them Cc'd. The reason this bothers me is that I tend to do exactly what you stated above. I will just Cc patch 345/1000 to someone with no context of what that patch is. I figured people would do the same thing that I do when I get that 345th patch. As I'm subscribed to LKML, I will just go into my lkml folder and search for that patch and see how that thread applies to me with full context. I'm assuming that's what others may do too. -- 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 1/1] dmaengine: pl330: Check if the DMA descriptor is NULL
Commit 6079d38 ("dmaengine: pl330: Remove useless xfer_cb indirection")
removed the __callback() function which created an unnecessary level of
indirection to execute the tranfer callback .xfer_cb
Unfortunately the commit also changed the semantics slightly since that
function used to check if the request was not NULL before attempting to
execute the callback function. Not checking this could lead to a kernel
NULL pointer dereference error.
Signed-off-by: Javier Martinez Canillas
---
drivers/dma/pl330.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index bc5878a..a55d754 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1441,9 +1441,14 @@ xfer_exit:
static void dma_pl330_rqcb(struct dma_pl330_desc *desc, enum pl330_op_err err)
{
- struct dma_pl330_chan *pch = desc->pchan;
+ struct dma_pl330_chan *pch;
unsigned long flags;
+ if (!desc)
+ return;
+
+ pch = desc->pchan;
+
/* If desc aborted */
if (!pch)
return;
--
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/
Updated PEBS patchkit for IVB-Haswell
This addresses all earlier comments. Especially perf mem report for mem-stores now works correctly again. The Haswell PEBS list unfortunately isn't simple anymore to report all the mem_op flags correctly, but at least it's more correct than before. Also fixed a bug. Hopefully should be ready for merge now. -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/
[PATCH 1/3] perf, x86: Revamp PEBS event selection
From: Andi Kleen
The basic idea is that it does not make sense to list all PEBS
events individually. The list is very long, sometimes outdated
and the hardware doesn't need it. If an event does not support
PEBS it will just not count, there is no security issue.
We need to only list events that something special, like
supporting load or store addresses.
This vastly simplifies the PEBS event selection. It also
speeds up the scheduling because the scheduler doesn't
have to walk as many constraints.
Bugs fixed:
- We do not allow setting forbidden flags with PEBS anymore
(SDM 18.9.4), except for the special cycle event.
This is done using a new constraint macro that also
matches on the event flags.
- Correct DataLA and load/store/na flags reporting on Haswell
[Requires a followon patch]
- We did not allow all PEBS events on Haswell:
We were missing some valid subevents in d1-d2 (MEM_LOAD_UOPS_RETIRED.*,
MEM_LOAD_UOPS_RETIRED_L3_HIT_RETIRED.*)
This includes the changes proposed by Stephane earlier and obsoletes
his patchkit (except for some changes on pre Sandy Bridge/Silvermont
CPUs)
I only did Sandy Bridge and Silvermont and later so far, mostly because these
are the parts I could directly confirm the hardware behavior with hardware
architects. Also I do not believe the older CPUs have any
missing events in their PEBS list, so there's no pressing
need to change them.
I did not implement the flag proposed by Peter to allow
setting forbidden flags. If really needed this could
be implemented on to of this patch.
Cc: eran...@google.com
v2: Fix broken store events on SNB/IVB (Stephane Eranian)
v3: More fixes. Rename some arguments (Stephane Eranian)
v4: List most Haswell events individually again to report
memory operation type correctly.
Add new flags to describe load/store/na for datala.
Update description.
Signed-off-by: Andi Kleen
---
arch/x86/include/asm/perf_event.h | 8 +++
arch/x86/kernel/cpu/perf_event.h | 48 --
arch/x86/kernel/cpu/perf_event_intel_ds.c | 107 ++
3 files changed, 85 insertions(+), 78 deletions(-)
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index 8249df4..8dfc9fd 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -51,6 +51,14 @@
ARCH_PERFMON_EVENTSEL_EDGE | \
ARCH_PERFMON_EVENTSEL_INV | \
ARCH_PERFMON_EVENTSEL_CMASK)
+#define X86_ALL_EVENT_FLAGS\
+ (ARCH_PERFMON_EVENTSEL_EDGE | \
+ARCH_PERFMON_EVENTSEL_INV |\
+ARCH_PERFMON_EVENTSEL_CMASK | \
+ARCH_PERFMON_EVENTSEL_ANY |\
+ARCH_PERFMON_EVENTSEL_PIN_CONTROL |\
+HSW_IN_TX |\
+HSW_IN_TX_CHECKPOINTED)
#define AMD64_RAW_EVENT_MASK \
(X86_RAW_EVENT_MASK | \
AMD64_EVENTSEL_EVENT)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index a22a34e9..e1b526d 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -77,8 +77,10 @@ struct event_constraint {
*/
#define PERF_X86_EVENT_PEBS_LDLAT 0x1 /* ld+ldlat data address sampling */
#define PERF_X86_EVENT_PEBS_ST 0x2 /* st data address sampling */
-#define PERF_X86_EVENT_PEBS_ST_HSW 0x4 /* haswell style st data sampling */
+#define PERF_X86_EVENT_PEBS_ST_HSW 0x4 /* haswell style datala, store */
#define PERF_X86_EVENT_COMMITTED 0x8 /* event passed commit_txn */
+#define PERF_X86_EVENT_PEBS_LD_HSW 0x10 /* haswell style datala, load */
+#define PERF_X86_EVENT_PEBS_NA_HSW 0x20 /* haswell style datala, unknown */
struct amd_nb {
int nb_id; /* NorthBridge id */
@@ -262,18 +264,52 @@ struct cpu_hw_events {
EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK)
#define INTEL_PLD_CONSTRAINT(c, n) \
- __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \
+ __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_LDLAT)
#define INTEL_PST_CONSTRAINT(c, n) \
- __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \
+ __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST)
-/* DataLA version of store sampling without extra enable bit. */
-#define INTEL_PST_HSW_CONSTRAINT(c, n) \
- __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \
+/* Event constraint, but match on all event flags too. */
+#define INTEL_FLAGS_EVENT_CONSTRAINT(c, n) \
+ EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS)
+
+/* Check only flags, but allow all event/umask */
+#define INTEL_ALL_EVENT_CONSTRAINT(code, n)\
+ EVENT_CONSTRAINT(code, n, X86_ALL_EVENT_FLAGS)
+
+/* Check flags and event code, and set the HSW store flag */
+#define
[PATCH 2/3] perf, x86: Don't mark DataLA addresses as store
From: Andi Kleen
Haswell supports reporting the data address for a range
of PEBS events, including:
UOPS_RETIRED.ALL
MEM_UOPS_RETIRED.STLB_MISS_LOADS
MEM_UOPS_RETIRED.STLB_MISS_STORES
MEM_UOPS_RETIRED.LOCK_LOADS
MEM_UOPS_RETIRED.SPLIT_LOADS
MEM_UOPS_RETIRED.SPLIT_STORES
MEM_UOPS_RETIRED.ALL_LOADS
MEM_UOPS_RETIRED.ALL_STORES
MEM_LOAD_UOPS_RETIRED.L1_HIT
MEM_LOAD_UOPS_RETIRED.L2_HIT
MEM_LOAD_UOPS_RETIRED.L3_HIT
MEM_LOAD_UOPS_RETIRED.L1_MISS
MEM_LOAD_UOPS_RETIRED.L2_MISS
MEM_LOAD_UOPS_RETIRED.L3_MISS
MEM_LOAD_UOPS_RETIRED.HIT_LFB
MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_MISS
MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_HIT
MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_HITM
MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_NONE
MEM_LOAD_UOPS_L3_MISS_RETIRED.LOCAL_DRAM
This facility was already enabled earlier with the original Haswell
perf changes.
However these addresses were always reports as stores by perf, which is wrong,
as they could be loads or NA too.
This patch uses the load/store/na flags added earlier to report the correct
operation based on the event type. For some events this is NA.
v2: Supports load/stores/na again instead of marking everything NA
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/perf_event_intel_ds.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index d0c3c2d..cafb24f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -108,13 +108,19 @@ static u64 precise_store_data(u64 status)
return val;
}
-static u64 precise_store_data_hsw(struct perf_event *event, u64 status)
+static u64 precise_store_data_hsw(struct perf_event *event, u64 status,
+ unsigned flags)
{
union perf_mem_data_src dse;
u64 cfg = event->hw.config & INTEL_ARCH_EVENT_MASK;
dse.val = 0;
- dse.mem_op = PERF_MEM_OP_STORE;
+ if (flags & PERF_X86_EVENT_PEBS_LD_HSW)
+ dse.mem_op = PERF_MEM_OP_LOAD;
+ else if (flags & PERF_X86_EVENT_PEBS_ST_HSW)
+ dse.mem_op = PERF_MEM_OP_STORE;
+ else
+ dse.mem_op = PERF_MEM_OP_NA;
dse.mem_lvl = PERF_MEM_LVL_NA;
/*
@@ -866,7 +872,8 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
PERF_X86_EVENT_PEBS_LD_HSW|
PERF_X86_EVENT_PEBS_NA_HSW))
data.data_src.val =
- precise_store_data_hsw(event,
pebs->dse);
+ precise_store_data_hsw(event, pebs->dse,
+ event->hw.flags);
else
data.data_src.val =
precise_store_data(pebs->dse);
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] perf, x86: Fix haswell mem hierarchy flags reporting
From: Andi Kleen
This fixes a bug introduced with
commit 722e76e60f2775c21b087ff12c5e678cf0ebcaaf
Author: Stephane Eranian
Date: Thu May 15 17:56:44 2014 +0200
fix Haswell precise store data source encoding
When returning early we need to return the complete value of the
memory hierarchy, not just the mem_lvl. Otherwise any load/store/na
flags set early get lost.
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/perf_event_intel_ds.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index cafb24f..7f7b117 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -121,7 +121,6 @@ static u64 precise_store_data_hsw(struct perf_event *event,
u64 status,
dse.mem_op = PERF_MEM_OP_STORE;
else
dse.mem_op = PERF_MEM_OP_NA;
- dse.mem_lvl = PERF_MEM_LVL_NA;
/*
* L1 info only valid for following events:
@@ -131,8 +130,10 @@ static u64 precise_store_data_hsw(struct perf_event
*event, u64 status,
* MEM_UOPS_RETIRED.SPLIT_STORES
* MEM_UOPS_RETIRED.ALL_STORES
*/
- if (cfg != 0x12d0 && cfg != 0x22d0 && cfg != 0x42d0 && cfg != 0x82d0)
- return dse.mem_lvl;
+ if (cfg != 0x12d0 && cfg != 0x22d0 && cfg != 0x42d0 && cfg != 0x82d0) {
+ dse.mem_lvl = PERF_MEM_LVL_NA;
+ return dse.val;
+ }
if (status & 1)
dse.mem_lvl = PERF_MEM_LVL_L1 | PERF_MEM_LVL_HIT;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf, x86: Don't mark DataLA addresses as store
On Tue, Jul 15, 2014 at 12:49:43AM +0200, Stephane Eranian wrote: > On Tue, Jul 15, 2014 at 12:39 AM, Andi Kleen wrote: > >> I have a problem with this patch. > >> > >> It makes: perf mem -t store rec record OP_NA for the store. > >> It was recording OP_STORE before. > >> > >> I think we need to keep LD/ST info. This is useful for analysis > >> especially if we collect loads/stores simultaneously. > >> > >> Was working before for the mem-loads, mem-stores events. > > > > Ok. Would it be enough if it only worked for "mem-stores" and not > > all PEBS events? > > > Ok, do that at a minimum. I fixed it now. However it turned out that "perf mem report" actually not report mem_op, only mem_lvl. You may want to fix that separately. -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 1/1] rcu: Fix build failure
On Fri, Jul 18, 2014 at 01:30:52PM -0400, Pranith Kumar wrote:
> Hi Paul,
>
> While running the kvm rcutorture test scripts, I encountered a build failure
> caused by
>
> Commit 918179699e4a ("rcu: Don't keep timekeeping CPU tick running for
> non-nohz_full= CPUs")
>
> This commit fixes the failure. This is on top of paul/rcu/dev.
>
> Signed-off-by: Pranith Kumar
> ---
> kernel/rcu/tree_plugin.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 5591276..eaa32e4 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -2795,7 +2795,7 @@ static void rcu_sysidle_exit(struct rcu_dynticks *rdtp,
> int irq)
>* CPU to keep a tick on our behalf. We assume that the timekeeping
>* CPU is also a nohz_full= CPU.
>*/
> - if (!tick_nohz_full_cpu(cpu))
> + if (!tick_nohz_full_cpu(smp_processor_id()))
Good catch, but please see 770d957e (rcu: Don't keep timekeeping CPU
tick running for non-nohz_full= CPUs). ;-)
Thanx, Paul
> return;
>
> /* Update system-idle state: We are clearly no longer fully idle! */
> --
> 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/
--
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 04/10] nohz: Appropriate timekeeper kick on sysidle break
When a CPU wakes up from idle and finds out that the timekeeper is
sleeping, we need to kick it such that it switches from dynticks to
periodic mode to maintain its timekeeping duty on behalf of the newly
awoken CPU.
However we aren't using the right API for that. rcu_kick_nohz_cpu() is
aimed at waking full dynticks CPUs and not the timekeeper.
Moreover the timekeeper must perform a new dynticks cycle to check the
new sysidle state and restart the tick if necessary. A simple call
to irq_exit() isn't enough.
wake_up_nohz_cpu() is a good fit for that job because it pulls the
target out of the idle loop and restart the tick. Then if no other
task waits for the CPU, it will reenter the idle loop and then the
new sysidle state will be visible and well handled.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/rcu/tree_plugin.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 395c14d..b65da1a 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2494,7 +2494,7 @@ void rcu_sysidle_force_exit(void)
oldstate, RCU_SYSIDLE_NOT);
if (oldstate == newoldstate &&
oldstate == RCU_SYSIDLE_FULL_NOTED) {
- rcu_kick_nohz_cpu(tick_do_timer_cpu);
+ wake_up_nohz_cpu(tick_do_timer_cpu);
return; /* We cleared it, done! */
}
oldstate = newoldstate;
--
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 10/10] nohz: Warn on illegal timekeeper switch in nohz full
In full dynticks idle mode, the timekeeper should never be set to another
CPU than 0.
Lets enforce that through a dedicated mutator.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-common.c | 9 -
kernel/time/tick-internal.h | 7 +++
kernel/time/tick-sched.c| 7 +++
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index cb57bce..72ccaf2 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -180,9 +180,9 @@ static void tick_setup_device(struct tick_device *td,
*/
if (tick_do_timer_cpu == TICK_DO_TIMER_BOOT) {
if (tick_nohz_full_enabled())
- tick_do_timer_cpu = TICK_DO_TIMER_DEFAULT;
+ tick_do_timer_cpu_set(TICK_DO_TIMER_DEFAULT);
else
- tick_do_timer_cpu = cpu;
+ tick_do_timer_cpu_set(cpu);
tick_next_period = ktime_get();
tick_period = ktime_set(0, NSEC_PER_SEC / HZ);
}
@@ -341,9 +341,8 @@ void tick_handover_do_timer(int *cpup)
{
if (*cpup == tick_do_timer_cpu) {
int cpu = cpumask_first(cpu_online_mask);
-
- tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
- TICK_DO_TIMER_NONE;
+ tick_do_timer_cpu_set((cpu < nr_cpu_ids) ? cpu :
+ TICK_DO_TIMER_NONE);
}
}
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index 6b592a8..eadfd89 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -23,6 +23,13 @@ extern void tick_setup_periodic(struct clock_event_device
*dev, int broadcast);
extern void tick_handle_periodic(struct clock_event_device *dev);
extern void tick_check_new_device(struct clock_event_device *dev);
extern void tick_handover_do_timer(int *cpup);
+
+static inline void tick_do_timer_cpu_set(int cpu)
+{
+ WARN_ON_ONCE(tick_nohz_full_enabled() && cpu != TICK_DO_TIMER_DEFAULT);
+ tick_do_timer_cpu = cpu;
+}
+
extern void tick_shutdown(unsigned int *cpup);
extern void tick_suspend(void);
extern void tick_resume(void);
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 845aaff..3b5102a 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -123,7 +123,7 @@ static void tick_sched_do_timer(ktime_t now)
*/
if (unlikely(tick_do_timer_cpu == TICK_DO_TIMER_NONE)
&& !tick_nohz_full_cpu(cpu))
- tick_do_timer_cpu = cpu;
+ tick_do_timer_cpu_set(cpu);
#endif
/* Check, if the jiffies need an update */
@@ -550,7 +550,7 @@ static u64 timekeeping_deferment(struct tick_sched *ts, int
cpu)
ts->do_timer_last = 1;
/* In full dynticks mode, CPU 0 always keeps the duty */
if (!tick_nohz_full_enabled())
- tick_do_timer_cpu = TICK_DO_TIMER_NONE;
+ tick_do_timer_cpu_set(TICK_DO_TIMER_NONE);
} else if (ts->do_timer_last) {
if (tick_do_timer_cpu == TICK_DO_TIMER_NONE)
time_delta = timekeeping_max_deferment();
@@ -600,7 +600,6 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
/* Schedule the tick, if we are at least one jiffie off */
if ((long)delta_jiffies >= 1) {
u64 time_delta = timekeeping_deferment(ts, cpu);
-
#ifdef CONFIG_NO_HZ_FULL
if (!ts->inidle) {
time_delta = min(time_delta,
@@ -717,7 +716,7 @@ static bool can_stop_idle_tick(int cpu, struct tick_sched
*ts)
*/
if (unlikely(!cpu_online(cpu))) {
if (cpu == tick_do_timer_cpu)
- tick_do_timer_cpu = TICK_DO_TIMER_NONE;
+ tick_do_timer_cpu_set(TICK_DO_TIMER_NONE);
return false;
}
--
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 05/10] smp: Fast path check on IPI list
When we enqueue a remote irq work, we trigger the same IPI as those
raised by smp_call_function_*() family.
So when we receive such IPI, we check both irq_work and smp_call_function
queues. Thus if we trigger a remote irq work, we'll likely find the
smp_call_function queue empty unless we collide with concurrent enqueuers
but the probability is low.
Meanwhile, checking the smp_call_function queue can be costly because
we use llist_del_all() which relies on cmpxchg().
We can reduce this overhead by doing a fast path check with llist_empty().
Given the implicit IPI ordering:
EnqueuerDequeuer
-
llist_add(csd, queue) get_IPI() {
send_IPI() if (llist_empty(queue)
...
When the IPI is sent, we are guaranteed that the IPI receiver will
see the new csd.
So lets do the fast path check to optimize non smp_call_function() related
jobs.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/smp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index a1812d1..34378d4 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -184,11 +184,19 @@ static int generic_exec_single(int cpu, struct
call_single_data *csd,
*/
void generic_smp_call_function_single_interrupt(void)
{
+ struct llist_head *head = &__get_cpu_var(call_single_queue);
struct llist_node *entry;
struct call_single_data *csd, *csd_next;
static bool warned;
- entry = llist_del_all(&__get_cpu_var(call_single_queue));
+ /*
+* Fast check: in case of irq work remote queue, the IPI list
+* is likely empty. We can spare the expensive llist_del_all().
+*/
+ if (llist_empty(head))
+ goto irq_work;
+
+ entry = llist_del_all(head);
entry = llist_reverse_order(entry);
/*
@@ -212,6 +220,7 @@ void generic_smp_call_function_single_interrupt(void)
csd_unlock(csd);
}
+irq_work:
/*
* Handle irq works queued remotely by irq_work_queue_on().
* Smp functions above are typically synchronous so they
--
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 02/10] nohz: Kick full dynticks timer targets with an empty IPI
While we enqueue a new timer on a dynticks target, we must send it an
IPI so that it reschedules the next tick accordingly.
Now all we need for that is to run irq_exit() on the target. Hence
an empty IRQ is way enough. We don't need to run tick_nohz_full_check()
and all the overhead that comes with the several cmpxchg() necessary for
irq work list and state progress.
So lets use a void irq work instead.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7f3063c..f3e48b8 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -693,7 +693,7 @@ static bool wake_up_full_nohz_cpu(int cpu)
if (tick_nohz_full_cpu(cpu)) {
if (cpu != smp_processor_id() ||
tick_nohz_tick_stopped())
- tick_nohz_full_kick_cpu(cpu);
+ irq_work_void_on(cpu);
return true;
}
--
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/
[GIT PULL] x86 fixes for v3.16-rc6
Hi Linus,
A couple of key fixes and a few less critical ones. The main ones
are:
1. to add a .bss section to the PE/COFF headers when building with EFI
stub.
2. to invoke the correct paravirt magic when building the espfix page
tables.
Unfortunately both of these areas also have at least one additional
fix each still in thie pipeline, but which are not yet ready to push.
The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus
for you to fetch changes up to d3f44fbabe55132832e152606365adb640296378:
x86: Remove unused variable "polling" (2014-07-16 12:58:47 +0200)
Ard Biesheuvel (1):
efi/arm64: efistub: remove local copy of linux_banner
Boris Ostrovsky (1):
x86/espfix/xen: Fix allocation of pages for paravirt page tables
Catalin Marinas (1):
efi: fdt: Do not report an error during boot if UEFI is not available
H. Peter Anvin (1):
Merge tag 'efi-urgent' into x86/urgent
Michael Brown (1):
x86/efi: Include a .bss section within the PE/COFF headers
Paul Bolle (1):
x86: Remove unused variable "polling"
arch/arm64/kernel/efi-stub.c | 2 --
arch/x86/boot/header.S | 26 ++
arch/x86/boot/tools/build.c | 38 ++
arch/x86/kernel/apm_32.c | 1 -
arch/x86/kernel/espfix_64.c | 5 ++---
drivers/firmware/efi/efi.c | 22 +++---
drivers/firmware/efi/fdt.c | 10 --
7 files changed, 69 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
index 60e98a639ac5..e786e6cdc400 100644
--- a/arch/arm64/kernel/efi-stub.c
+++ b/arch/arm64/kernel/efi-stub.c
@@ -12,8 +12,6 @@
#include
#include
#include
-#include
-#include
/*
* AArch64 requires the DTB to be 8-byte aligned in the first 512MiB from
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 84c223479e3c..7a6d43a554d7 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -91,10 +91,9 @@ bs_die:
.section ".bsdata", "a"
bugger_off_msg:
- .ascii "Direct floppy boot is not supported. "
- .ascii "Use a boot loader program instead.\r\n"
+ .ascii "Use a boot loader.\r\n"
.ascii "\n"
- .ascii "Remove disk and press any key to reboot ...\r\n"
+ .ascii "Remove disk and press any key to reboot...\r\n"
.byte 0
#ifdef CONFIG_EFI_STUB
@@ -108,7 +107,7 @@ coff_header:
#else
.word 0x8664 # x86-64
#endif
- .word 3 # nr_sections
+ .word 4 # nr_sections
.long 0 # TimeDateStamp
.long 0 # PointerToSymbolTable
.long 1 # NumberOfSymbols
@@ -250,6 +249,25 @@ section_table:
.word 0 # NumberOfLineNumbers
.long 0x60500020 # Characteristics (section
flags)
+ #
+ # The offset & size fields are filled in by build.c.
+ #
+ .ascii ".bss"
+ .byte 0
+ .byte 0
+ .byte 0
+ .byte 0
+ .long 0
+ .long 0x0
+ .long 0 # Size of initialized data
+ # on disk
+ .long 0x0
+ .long 0 # PointerToRelocations
+ .long 0 # PointerToLineNumbers
+ .word 0 # NumberOfRelocations
+ .word 0 # NumberOfLineNumbers
+ .long 0xc880 # Characteristics (section
flags)
+
#endif /* CONFIG_EFI_STUB */
# Kernel attributes; used by setup. This is part 1 of the
diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c
index 1a2f2121cada..a7661c430cd9 100644
--- a/arch/x86/boot/tools/build.c
+++ b/arch/x86/boot/tools/build.c
@@ -143,7 +143,7 @@ static void usage(void)
#ifdef CONFIG_EFI_STUB
-static void update_pecoff_section_header(char *section_name, u32 offset, u32
size)
+static void update_pecoff_section_header_fields(char *section_name, u32 vma,
u32 size, u32 datasz, u32 offset)
{
unsigned int pe_header;
unsigned short num_sections;
@@ -164,10 +164,10 @@ static void update_pecoff_section_header(char
*section_name, u32 offset, u32 siz
put_unaligned_le32(size, section + 0x8);
/* section header vma field */
- put_unaligned_le32(offset, section + 0xc);
+ put_unaligned_le32(vma, section + 0xc);
[PATCH 08/10] nohz: Fetch timekeeping max deferment only for timekeeper
We fetch it unconditionally from the tick stop code whereas only
the timekeeper, or the CPU that carried that duty last, needs it.
Fetching the timekeeping max deferment should be lightweight but it
still involves a few read side barriers and a seqcount that may well
be cache cold for non-timekeepers.
So lets spare it when possible by inverting the way we handle timekeeper
deferment state machine.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-sched.c | 57 ++--
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 2ea2143..bcba79d 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -529,6 +529,36 @@ u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time)
}
EXPORT_SYMBOL_GPL(get_cpu_iowait_time_us);
+/*
+ * If this cpu is the one which updates jiffies, then
+ * give up the assignment and let it be taken by the
+ * cpu which runs the tick timer next, which might be
+ * this cpu as well. If we don't drop this here the
+ * jiffies might be stale and do_timer() never
+ * invoked. Keep track of the fact that it was the one
+ * which had the do_timer() duty last. If this cpu is
+ * the one which had the do_timer() duty last, we
+ * limit the sleep time to the timekeeping max deferement
+ * value. Otherwise we can sleep as long as we want.
+ */
+static u64 timekeeping_deferment(struct tick_sched *ts, int cpu)
+{
+ u64 time_delta = KTIME_MAX;
+
+ if (tick_do_timer_cpu == cpu) {
+ time_delta = timekeeping_max_deferment();
+ tick_do_timer_cpu = TICK_DO_TIMER_NONE;
+ ts->do_timer_last = 1;
+ } else if (ts->do_timer_last) {
+ if (tick_do_timer_cpu == TICK_DO_TIMER_NONE)
+ time_delta = timekeeping_max_deferment();
+ else
+ ts->do_timer_last = 0;
+ }
+
+ return time_delta;
+}
+
static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
ktime_t now, int cpu)
{
@@ -536,9 +566,6 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
ktime_t last_update, expires, ret = { .tv64 = 0 };
unsigned long rcu_delta_jiffies;
struct clock_event_device *dev = __get_cpu_var(tick_cpu_device).evtdev;
- u64 time_delta;
-
- time_delta = timekeeping_max_deferment();
/* Read jiffies and the time when jiffies were updated last */
do {
@@ -570,29 +597,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
/* Schedule the tick, if we are at least one jiffie off */
if ((long)delta_jiffies >= 1) {
-
- /*
-* If this cpu is the one which updates jiffies, then
-* give up the assignment and let it be taken by the
-* cpu which runs the tick timer next, which might be
-* this cpu as well. If we don't drop this here the
-* jiffies might be stale and do_timer() never
-* invoked. Keep track of the fact that it was the one
-* which had the do_timer() duty last. If this cpu is
-* the one which had the do_timer() duty last, we
-* limit the sleep time to the timekeeping
-* max_deferement value which we retrieved
-* above. Otherwise we can sleep as long as we want.
-*/
- if (cpu == tick_do_timer_cpu) {
- tick_do_timer_cpu = TICK_DO_TIMER_NONE;
- ts->do_timer_last = 1;
- } else if (tick_do_timer_cpu != TICK_DO_TIMER_NONE) {
- time_delta = KTIME_MAX;
- ts->do_timer_last = 0;
- } else if (!ts->do_timer_last) {
- time_delta = KTIME_MAX;
- }
+ u64 time_delta = timekeeping_deferment(ts, cpu);
#ifdef CONFIG_NO_HZ_FULL
if (!ts->inidle) {
--
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 07/10] nohz: Enforce timekeeping on CPU 0
The timekeeper gets initialized to the value of the CPU where the
first clockevent device is setup. This works well because the timekeeper
can be any online CPU in most configs.
Full dynticks has its own requirement though and needs the timekeeper
to always be 0. And this requirement seem to accomodate pretty well with
the above described boot timekeeper setting because the first clockevent
device happens to be initialized, most of the time, on the boot CPU
(which should be CPU 0).
However there is no mention of such a guarantee anywhere. This assumption
might well be defeated on some corner case now or in the future.
So lets wipe out the FUD and force tick_do_timer_cpu to CPU 0 on boot
when full dynticks is used.
This way we can even remove some corner case code that handled scenarios
where all clockevent devices were setup on full dynticks CPUs.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-common.c | 6 +++---
kernel/time/tick-sched.c | 6 --
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 0a0608e..cb57bce 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -179,10 +179,10 @@ static void tick_setup_device(struct tick_device *td,
* this cpu:
*/
if (tick_do_timer_cpu == TICK_DO_TIMER_BOOT) {
- if (!tick_nohz_full_cpu(cpu))
- tick_do_timer_cpu = cpu;
+ if (tick_nohz_full_enabled())
+ tick_do_timer_cpu = TICK_DO_TIMER_DEFAULT;
else
- tick_do_timer_cpu = TICK_DO_TIMER_NONE;
+ tick_do_timer_cpu = cpu;
tick_next_period = ktime_get();
tick_period = ktime_set(0, NSEC_PER_SEC / HZ);
}
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 3d63944..2ea2143 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -741,12 +741,6 @@ static bool can_stop_idle_tick(int cpu, struct tick_sched
*ts)
*/
if (tick_do_timer_cpu == cpu)
return false;
- /*
-* Boot safety: make sure the timekeeping duty has been
-* assigned before entering dyntick-idle mode,
-*/
- if (tick_do_timer_cpu == TICK_DO_TIMER_NONE)
- return false;
}
return true;
--
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 06/10] nohz: Define meaningful symbol for nohz full timekeeper
The nohz full timekeeper is always CPU 0. Lets add it to the list of special tick_do_timer_cpu symbols for more self explanatory code. Cc: Ingo Molnar Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Viresh Kumar Signed-off-by: Frederic Weisbecker --- kernel/time/tick-internal.h | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h index 7ab92b1..6b592a8 100644 --- a/kernel/time/tick-internal.h +++ b/kernel/time/tick-internal.h @@ -10,6 +10,7 @@ extern seqlock_t jiffies_lock; #ifdef CONFIG_GENERIC_CLOCKEVENTS_BUILD +#define TICK_DO_TIMER_DEFAULT 0 #define TICK_DO_TIMER_NONE -1 #define TICK_DO_TIMER_BOOT -2 -- 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 03/10] rcu: Kick full dynticks CPU on extended grace period with a void IRQ
When a full dynticks CPU stays for too long in the kernel, it may fail
to report quiescent states due to it missing ticks and therefore it can
delay the completion of grace periods.
A way to solve this is to send an IPI to the incriminated CPU such that
it can check rcu_needs_cpu() and reschedule some ticks accordingly to
poll again on quiescent states reports.
This is what we try to achieve while calling rcu_kick_nohz_cpu() but it
has no effect because we trigger a scheduler IPI which is actually a
no-op when not used for scheduler internal purpose, ie: it doesn't call
irq_exit() when not used for remote wakeup or other specifics.
No need to tweak the scheduler IPI further though. Lets keep it clean
of external noise and use an empty IPI instead. We hereby get sure that
we will call irq_exit() on the target without much overhead nor added
noise on scheduler fast path.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/rcu/tree_plugin.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index cbc2c45..395c14d 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2401,14 +2401,16 @@ static bool init_nocb_callback_list(struct rcu_data
*rdp)
* off. RCU will be paying attention to this CPU because it is in the
* kernel, but the CPU cannot be guaranteed to be executing the RCU state
* machine because the scheduling-clock tick has been disabled. Therefore,
- * if an adaptive-ticks CPU is failing to respond to the current grace
- * period and has not be idle from an RCU perspective, kick it.
+ * if an full dynticks CPU is failing to respond to the current grace
+ * period and has not be idle from an RCU perspective, kick it with a
+ * void IRQ so that it can check that RCU needs its tick from rcu_needs_cpu()
+ * on irq exit.
*/
static void rcu_kick_nohz_cpu(int cpu)
{
#ifdef CONFIG_NO_HZ_FULL
if (tick_nohz_full_cpu(cpu))
- smp_send_reschedule(cpu);
+ irq_work_void_on(cpu);
#endif /* #ifdef CONFIG_NO_HZ_FULL */
}
--
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 09/10] nohz: Switch nohz full timekeeper to dynticks idle on top of sysidle detection
In full dynticks, the CPU 0 carries the timekeeping duty on behalf
of all other CPUs in the system. This way full dynticks are left
undisturbed on this regard.
Of course this prevents CPU 0 from entering in dynticks idle mode
because any CPU may need uptodate timekeeping at any time.
Theoretically though, we could put CPU 0 in dynticks idle mode once we
are sure that all other CPUs are dynticks idle as well. Then when a
CPU wakes up and finds the timekeeper idle, it would send an IPI to
wake it up on its duty.
Such a machine state needs to take care of all the races in the way, make
sure that CPU 0 is neither stuck accidentally to sleep for ever, nor
stuck in periodic mode when it could sleep. Also given the amount of
shared data this involves and their access frequency, this must be built
on top of lockless low-overhead state machine.
This is what sysidle provides. The feature is ready for a while, we
were just waiting for the nohz susbsystem to support it. And we just
reached that state.
So lets defer the last call for CPU 0 to enter in dynticks idle to when
we find a full system idle state. And lets wake it up when its duty is
needed.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-sched.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index bcba79d..845aaff 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -547,8 +547,10 @@ static u64 timekeeping_deferment(struct tick_sched *ts,
int cpu)
if (tick_do_timer_cpu == cpu) {
time_delta = timekeeping_max_deferment();
- tick_do_timer_cpu = TICK_DO_TIMER_NONE;
ts->do_timer_last = 1;
+ /* In full dynticks mode, CPU 0 always keeps the duty */
+ if (!tick_nohz_full_enabled())
+ tick_do_timer_cpu = TICK_DO_TIMER_NONE;
} else if (ts->do_timer_last) {
if (tick_do_timer_cpu == TICK_DO_TIMER_NONE)
time_delta = timekeeping_max_deferment();
@@ -745,7 +747,7 @@ static bool can_stop_idle_tick(int cpu, struct tick_sched
*ts)
* if there are full dynticks CPUs around
*/
if (tick_do_timer_cpu == cpu)
- return false;
+ return rcu_sys_is_idle();
}
return true;
--
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/
[RFC PATCH 00/10] nohz: Support sysidle (and some more cleanups)
Currently when nohz full is active, the CPU 0 handles timekeeping on behalf of all other CPUs. This prevents it from ever entering in dynticks idle mode. This patchset uses the RCU sysidle feature to allow that. The CPU 0 can know safely when to sleep and when to wake up, the sysidle code determines that and takes care of races along the way. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git nohz/sysidle Thanks, Frederic --- Frederic Weisbecker (10): irq_work: Introduce void irq work nohz: Kick full dynticks timer targets with an empty IPI rcu: Kick full dynticks CPU on extended grace period with a void IRQ nohz: Appropriate timekeeper kick on sysidle break smp: Fast path check on IPI list nohz: Define meaningful symbol for nohz full timekeeper nohz: Enforce timekeeping on CPU 0 nohz: Fetch timekeeping max deferment only for timekeeper nohz: Switch nohz full timekeeper to dynticks idle on top of sysidle detection nohz: Warn on illegal timekeeper switch in nohz full include/linux/irq_work.h| 1 + kernel/irq_work.c | 21 + kernel/rcu/tree_plugin.h| 10 --- kernel/sched/core.c | 2 +- kernel/smp.c| 11 ++- kernel/time/tick-common.c | 11 --- kernel/time/tick-internal.h | 8 + kernel/time/tick-sched.c| 72 ++--- 8 files changed, 88 insertions(+), 48 deletions(-) -- 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 01/10] irq_work: Introduce void irq work
Being able to trigger an empty IPI appears to be useless in the first
place. Yet it is expected to be very useful for callers who just need
to execute irq_enter() or irq_exit() to a remote target.
More precisely this is going to be useful for the nohz subsystem which
often needs a remote CPU to reschedule its tick when some state changed
and require periodicity for any reason. Similar cases have been handled
with random IPIs until now. But they surely bring unwanted overhead
all along since they are all dedicated for specific tasks.
Triggering an irq work/smp_call_function IPI should be enough to solve
that. If competing and spurious IPIs become a problem, we can still
optimize that later.
Cc: Ingo Molnar
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/irq_work.h | 1 +
kernel/irq_work.c| 21 +
2 files changed, 22 insertions(+)
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index bf9422c..b2ad065 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -36,6 +36,7 @@ bool irq_work_queue(struct irq_work *work);
#ifdef CONFIG_SMP
bool irq_work_queue_on(struct irq_work *work, int cpu);
+void irq_work_void_on(int cpu);
#endif
void irq_work_run(void);
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 4b0a890..36b7fb2 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -81,6 +81,27 @@ bool irq_work_queue_on(struct irq_work *work, int cpu)
return true;
}
EXPORT_SYMBOL_GPL(irq_work_queue_on);
+
+/**
+ * irq_work_void_on(): Run a void IRQ on the target
+ * @cpu: The cpu to run the IRQ on
+ *
+ * Run a void IRQ for its own sake on the target. It's generally
+ * useful for callers which want to run irq_enter() or irq_exit()
+ * on a remote CPU.
+ */
+void irq_work_void_on(int cpu)
+{
+ /*
+* NOTE: we could optimize that and spare some IPIs
+* after checking that raised_list isn't empty before raising.
+* This can't be done properly without cmpxchg() though so
+* it may make things worse after all. But lets leave that
+* possibility open in case people report such issue in the
+* future.
+*/
+ arch_send_call_function_single_ipi(cpu);
+}
#endif
/* Enqueue the irq work @work on the current CPU */
--
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] sched_clock: Avoid corrupting hrtimer tree during suspend
On 07/18/2014 04:24 PM, Stephen Boyd wrote: > On 07/18/14 15:42, John Stultz wrote: >> If its a regression (and needs -stable backports) it needs to go in via >> tip/timers/urgent, and not via the regular merge window. >> >> Whats the additional risk -stable wise for canceling the timer during >> suspend and starting it back up during resume? >> > I'd say close to zero given that we'd only be making the timer run a > little bit later and we have slack in there already. Here's that version. Ok, thanks. I'll try to do a closer review it and get it queued. Is there anyone who might be able to validate this and provide a Tested-by: ? thanks -john -- 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] PM / devfreq: Add possible_frequencies device attribute
Some devices use freq_table instead of OPP. For those devices, the
available_frequencies sysfs file shows up empty. So, add a
possible_frequencies attribute/syfs file that list all the possible
frequencies.
For devices that use OPP, the output of this file will match
available_frequencies. It may change in the future to show all OPP
frequencies -- even the disabled ones.
Signed-off-by: Saravana Kannan
---
Documentation/ABI/testing/sysfs-class-devfreq | 15 +++
drivers/devfreq/devfreq.c | 26 ++
2 files changed, 41 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-devfreq
b/Documentation/ABI/testing/sysfs-class-devfreq
index ee39aca..a461e67 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -72,6 +72,21 @@ Description:
This is a snapshot of available frequencies and not limited
by the min/max frequency restrictions.
+What: /sys/class/devfreq/.../possible_frequencies
+Date: July 2014
+Contact: Saravana Kannan
+Description:
+ The /sys/class/devfreq/.../possible_frequencies shows
+ the possible frequencies of the corresponding devfreq object.
+ This is a snapshot of possible frequencies and not limited by
+ the min/max frequency restrictions. Unlike
+ available_frequencies, this is also does not require the
+ devfreq device to use OPP for listing its possible
+ frequencies. When OPP is used, this behaves the same way as
+ available_frequencies. It maybe improved in the future to
+ list all possible OPP frequencies even if some of them are
+ disabled at run-time.
+
What: /sys/class/devfreq/.../available_governors
Date: October 2012
Contact: Nishanth Menon
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 9f90369..65eed38 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -994,6 +994,31 @@ static ssize_t available_frequencies_show(struct device *d,
}
static DEVICE_ATTR_RO(available_frequencies);
+static ssize_t possible_frequencies_show(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct devfreq *df = to_devfreq(d);
+ unsigned int i = 0;
+ ssize_t count = 0;
+
+ if (!df->profile->freq_table)
+ return available_frequencies_show(d, attr, buf);
+
+ for (i = 0; i < df->profile->max_state; i++)
+ count += scnprintf([count], (PAGE_SIZE - count - 2),
+ "%u ", df->profile->freq_table[i]);
+
+ /* Truncate the trailing space */
+ if (count)
+ count--;
+
+ count += sprintf([count], "\n");
+
+ return count;
+}
+static DEVICE_ATTR_RO(possible_frequencies);
+
static ssize_t trans_stat_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1041,6 +1066,7 @@ static struct attribute *devfreq_attrs[] = {
_attr_available_governors.attr,
_attr_cur_freq.attr,
_attr_available_frequencies.attr,
+ _attr_possible_frequencies.attr,
_attr_target_freq.attr,
_attr_polling_interval.attr,
_attr_min_freq.attr,
--
1.8.2.1
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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] kbuild: devtest - new make target for build all and run tests
On 07/18/2014 05:29 PM, Sam Ravnborg wrote: On Fri, Jul 18, 2014 at 02:44:34PM -0600, Shuah Khan wrote: Add a new devtest make target to enable developer testing. This new target does full build (make all) and then runs selftests. Signed-off-by: Shuah Khan --- Makefile | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Makefile b/Makefile index f3c543d..1ef3128 100644 --- a/Makefile +++ b/Makefile @@ -1034,6 +1034,14 @@ headers_check: headers_install $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) HDRCHECK=1 # --- +# Kernel devtest + +PHONY += devtest +devtest: + make all + make -C tools/testing/selftests run_tests The name "devtest" does not give any hints that we are actually running the suite of selftest programs. Is it so because the plan is to extend devtest to cover more than just selftest? If not please fix it so it is logical for the user what happens - in other words name is selftest or something like that. Yes the intent is to cover more than just selftests in the future. That is why the target is called devtest. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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/6] PM / Hibernate: Create a Radix-Tree to store memory bitmap
On Friday, July 18, 2014 01:57:18 PM Joerg Roedel wrote:
> From: Joerg Roedel
>
> This patch adds the code to allocate and build the radix
> tree to store the memory bitmap. The old data structure is
> left in place until the radix tree implementation is
> finished.
>
> Signed-off-by: Joerg Roedel
> ---
> kernel/power/snapshot.c | 224
> +++-
> 1 file changed, 223 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index 1ea328a..d0f11ec 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -248,11 +248,24 @@ static void *chain_alloc(struct chain_allocator *ca,
> unsigned int size)
> * information is stored (in the form of a block of bitmap)
> * It also contains the pfns that correspond to the start and end of
> * the represented memory area.
> + *
> + * The memory bitmap is organized as a radix tree to guarantee fast random
> + * access to the bits. There is one radix tree for each zone (as returned
> + * from create_mem_extents).
> + *
> + * One radix tree is represented by one struct mem_zone_bm_rtree. There are
> + * two linked lists for the nodes of the tree, one for the inner nodes and
> + * one for the leave nodes. The linked leave nodes are used for fast linear
> + * access of the memory bitmap.
> + *
> + * The struct rtree_node represents one node of the radix tree.
> */
>
> #define BM_END_OF_MAP(~0UL)
>
> #define BM_BITS_PER_BLOCK(PAGE_SIZE * BITS_PER_BYTE)
> +#define BM_BLOCK_SHIFT (PAGE_SHIFT + 3)
> +#define BM_BLOCK_MASK((1UL << BM_BLOCK_SHIFT) - 1)
>
> struct bm_block {
> struct list_head hook; /* hook into a list of bitmap blocks */
> @@ -266,6 +279,31 @@ static inline unsigned long bm_block_bits(struct
> bm_block *bb)
> return bb->end_pfn - bb->start_pfn;
> }
>
> +/*
> + * struct rtree_node is a wrapper struct to link the nodes
> + * of the rtree together for easy linear iteration over
> + * bits and easy freeing
> + */
> +struct rtree_node {
> + struct list_head list;
> + unsigned long *data;
> +};
> +
> +/*
> + * struct mem_zone_bm_rtree represents a bitmap used for one
> + * populated memory zone.
> + */
> +struct mem_zone_bm_rtree {
> + struct list_head list; /* Link Zones together */
> + struct list_head nodes; /* Radix Tree inner nodes */
> + struct list_head leaves;/* Radix Tree leaves */
> + unsigned long start_pfn;/* Zone start page frame */
> + unsigned long end_pfn; /* Zone end page frame + 1 */
> + struct rtree_node *rtree; /* Radix Tree Root */
> + int levels; /* Number of Radix Tree Levels */
> + unsigned int blocks;/* Number of Bitmap Blocks */
> +};
> +
> /* strcut bm_position is used for browsing memory bitmaps */
>
> struct bm_position {
> @@ -274,6 +312,7 @@ struct bm_position {
> };
>
> struct memory_bitmap {
> + struct list_head zones;
> struct list_head blocks;/* list of bitmap blocks */
> struct linked_page *p_list; /* list of pages used to store zone
>* bitmap objects and bitmap block
> @@ -284,6 +323,167 @@ struct memory_bitmap {
>
> /* Functions that operate on memory bitmaps */
>
> +#define BM_ENTRIES_PER_LEVEL (PAGE_SIZE / sizeof(unsigned long))
> +#if BITS_PER_LONG == 32
> +#define BM_RTREE_LEVEL_SHIFT (PAGE_SHIFT - 2)
> +#else
> +#define BM_RTREE_LEVEL_SHIFT (PAGE_SHIFT - 3)
> +#endif
> +#define BM_RTREE_LEVEL_MASK ((1UL << BM_RTREE_LEVEL_SHIFT) - 1)
> +
> +/*
> + * alloc_rtree_node - Allocate a new node and add it to the radix
> + * tree.
Please make this a single line.
> + *
> + * This function is used to allocate inner nodes as well as the
> + * leave nodes of the radix tree. It also adds the node to the
> + * corresponding linked list passed in by the *list parameter.
> + */
> +static struct rtree_node *alloc_rtree_node(gfp_t gfp_mask, int safe_needed,
> +struct chain_allocator *ca,
> +struct list_head *list)
> +{
> + struct rtree_node *node;
> +
> + node = chain_alloc(ca, sizeof(struct rtree_node));
> + if (!node)
> + return NULL;
> +
> + node->data = get_image_page(gfp_mask, safe_needed);
> + if (!node->data)
> + return NULL;
> +
> + list_add_tail(>list, list);
> +
> + return node;
> +}
> +
> +/*
> + * add_rtree_block - Add a new leave node to the radix tree
> + *
> + * The leave nodes need to be allocated in order to keep the leaves
> + * linked list in order. This is guaranteed by the zone->blocks
> + * counter.
> + */
> +static int add_rtree_block(struct mem_zone_bm_rtree *zone, gfp_t gfp_mask,
> +
Re: [PATCH] random: check for increase of entropy_count because of signed conversion
Hi,
On Fr, 2014-07-18 at 18:07 -0400, Theodore Ts'o wrote:
> From: Hannes Frederic Sowa
>
> The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
> actually increase entropy_count if during assignment of the unsigned
> expression on the RHS (mind the -=) we reduce the value modulo
> 2^width(int) and assign it to entropy_count. Trinity found this.
>
> [ Commit modified by tytso to add an additional safety check for a
> negative entropy_count -- which should never happen, and to also add
> an additional paranoia check to prevent overly large count values to
> be passed into urandom_read(). ]
>
> Reported-by: Dave Jones
> Cc: Greg Price
> Signed-off-by: Hannes Frederic Sowa
> Signed-off-by: Theodore Ts'o
> ---
> drivers/char/random.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 0a7ac0a..003f744 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -641,7 +641,7 @@ retry:
> } while (unlikely(entropy_count < pool_size-2 && pnfrac));
> }
>
> - if (entropy_count < 0) {
> + if (unlikely(entropy_count < 0)) {
> pr_warn("random: negative entropy/overflow: pool %s count %d\n",
> r->name, entropy_count);
> WARN_ON(1);
> @@ -981,7 +981,7 @@ static size_t account(struct entropy_store *r, size_t
> nbytes, int min,
> int reserved)
> {
> int entropy_count, orig;
> - size_t ibytes;
> + size_t ibytes, nfrac;
>
> BUG_ON(r->entropy_count > r->poolinfo->poolfracbits);
>
> @@ -999,7 +999,17 @@ retry:
> }
> if (ibytes < min)
> ibytes = 0;
> - if ((entropy_count -= ibytes << (ENTROPY_SHIFT + 3)) < 0)
> +
> + nfrac = ibytes << (ENTROPY_SHIFT + 3);
> + if (entropy_count < 0) {
Minor nit: maybe also add an unlikely() here?
> + pr_warn("random: negative entropy count: pool %s count %d\n",
> + r->name, entropy_count);
> + WARN_ON(1);
> + entropy_count = 0;
> + }
> + if ((unsigned) entropy_count > nfrac)
(unsigned) -> (size_t)
size_t could also be (unsigned long) so the plain (unsigned) is
misleading.
(Maybe I wouldn't have done the cast at all, as we compile the kernel
with -Wno-sign-compare and we have the < 0 check right above, but I
don't have a strong opinion on that.)
> + entropy_count -= nfrac;
> + else
> entropy_count = 0;
>
> if (cmpxchg(>entropy_count, orig, entropy_count) != orig)
> @@ -1376,6 +1386,7 @@ urandom_read(struct file *file, char __user *buf,
> size_t nbytes, loff_t *ppos)
> "with %d bits of entropy available\n",
> current->comm, nonblocking_pool.entropy_total);
>
> + nbytes = min_t(size_t, nbytes, INT_MAX >> ENTROPY_SHIFT);
Hmm, not sure, nfracs unit is 1/8 bits, so don't we have to limit nbytes
to INT_MAX >> (ENTROPY_SHIFT + 3) here?
And if we want to be even more correct here, we could switch from
INT_MAX to SIZE_MAX, as we do all nfrac calculations in the size_t
domain.
Maximum read/write size is SSIZE_MAX, so we don't need to care about
that, but if a user on a 64 bit machine requests INT_MAX bytes, we only
account/extract INT_MAX >> (ENTROPY_SHIFT + 3) bytes and cause a partial
read, though we actually could calulcate a correct nfrac for INT_MAX.
Because we don't have such large poolfragbits pools we would still
always end up with 0 while still allowing larger buffers to fill.
Hm, I just see that we should leave the INT_MAX limit just because of
the tracepoint.
Good catch,
Hannes
> ret = extract_entropy_user(_pool, buf, nbytes);
>
> trace_urandom_read(8 * nbytes, ENTROPY_BITS(_pool),
--
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: Build Errors when building usb directory
On 07/18/2014 12:59 PM, Nick Krause wrote: > On Fri, Jul 18, 2014 at 2:10 PM, Randy Dunlap wrote: >> On 07/18/2014 10:45 AM, Nick Krause wrote: >>> Hey Greg and others, >>> When I built the usb directory today to check a patch I am also >>> sending to. I seem to hitting >>> a few compiler errors and a lot of warnings. I am going to attach a >>> file of my log of this build. >>> Cheers Nick >>> >> >> Hi, >> >> What command(s) did you use to build the usb directory? >> >> thanks, >> -- >> ~Randy > I used make M=drivers/usb to build it. > Cheers Nick I'm not seeing any of these warnings, but I am testing 3.16-rc5. Nick, are you using a current git tree? If so, which one? You should always specify what kernel it is that you are testing. -- ~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 27/31] tile: Use this_cpu_ptr() for hardware counters
Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 29/31] avr32: Replace __get_cpu_var with __this_cpu_write
On Fri, Jun 20, 2014 at 02:31:44PM -0500, Christoph Lameter wrote: > Replace the single use of __get_cpu_var in avr32 with > __this_cpu_write. > > Cc: Haavard Skinnemoen > Acked-by: Hans-Christian Egtvedt > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 26/31] tile: Replace __get_cpu_var uses
Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 28/31] blackfin: Replace __get_cpu_var uses
Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 24/31] alpha: Replace __get_cpu_var
Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 23/31] ia64: Replace __get_cpu_var uses
Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 22/31] s390: cio driver &__get_cpu_var replacements
Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/31] s390: Replace __get_cpu_var uses
Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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] kbuild: devtest - new make target for build all and run tests
On Fri, Jul 18, 2014 at 02:44:34PM -0600, Shuah Khan wrote: > Add a new devtest make target to enable developer testing. This > new target does full build (make all) and then runs selftests. > > Signed-off-by: Shuah Khan > --- > Makefile | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Makefile b/Makefile > index f3c543d..1ef3128 100644 > --- a/Makefile > +++ b/Makefile > @@ -1034,6 +1034,14 @@ headers_check: headers_install > $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) > HDRCHECK=1 > > # --- > +# Kernel devtest > + > +PHONY += devtest > +devtest: > + make all > + make -C tools/testing/selftests run_tests The name "devtest" does not give any hints that we are actually running the suite of selftest programs. Is it so because the plan is to extend devtest to cover more than just selftest? If not please fix it so it is logical for the user what happens - in other words name is selftest or something like that. Sam -- 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 19/31] MIPS: Replace __get_cpu_var uses in FPU emulator.
On Fri, Jun 20, 2014 at 02:31:34PM -0500, Christoph Lameter wrote: > > From: David Daney > > The use of __this_cpu_inc() requires a fundamental integer type, so > change the type of all the counters to unsigned long, which is the > same width they were before, but not wrapped in local_t. > > Signed-off-by: David Daney > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 20/31] mips: Replace __get_cpu_var uses
Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 18/31] arm: Replace __this_cpu_ptr with raw_cpu_ptr
On Fri, Jun 20, 2014 at 02:31:33PM -0500, Christoph Lameter wrote: > __this_cpu_ptr is being phased out. So replace with raw_cpu_ptr. > > Cc: Russell King > Cc: Catalin Marinas > CC: Will Deacon > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 17/31] uv: Replace __get_cpu_var
On Fri, Jun 20, 2014 at 02:31:32PM -0500, Christoph Lameter wrote: > Use __this_cpu_read instead. > > Cc: Hedi Berriche > Cc: Mike Travis > Cc: Dimitri Sivanich > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 15/31] irqchips: Replace __this_cpu_ptr uses
On Fri, Jun 20, 2014 at 02:31:30PM -0500, Christoph Lameter wrote: > [ARM specific] > > These are generally replaced with raw_cpu_ptr. However, in > gic_get_percpu_base() we immediately dereference the pointer. This is > equivalent to a raw_cpu_read. So use that operation there. > > Cc: nicolas.pi...@linaro.org > Cc: Russell King > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 12/31] md: Replace __this_cpu_ptr with raw_cpu_ptr
On Fri, Jun 20, 2014 at 02:31:27PM -0500, Christoph Lameter wrote: > __this_cpu_ptr is being phased out. > > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 13/31] metag: Replace __get_cpu_var uses for address calculation
On Fri, Jun 20, 2014 at 02:31:28PM -0500, Christoph Lameter wrote: > Replace __get_cpu_var uses for address calculation with this_cpu_ptr(). > > Acked-by: James Hogan > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 14/31] drivers/net/ethernet/tile: __get_cpu_var call introduced in 3.14
On Fri, Jun 20, 2014 at 02:31:29PM -0500, Christoph Lameter wrote: > Another case was merged for 3.14-rc1 > > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 11/31] net: Replace get_cpu_var through this_cpu_ptr
On Fri, Jun 20, 2014 at 02:31:26PM -0500, Christoph Lameter wrote: > Replace uses of get_cpu_var for address calculation through this_cpu_ptr. > > Cc: net...@vger.kernel.org > Cc: Eric Dumazet > Acked-by: David S. Miller > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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: Power-managing devices that are not of interest at some point in time
On Friday, July 18, 2014 04:16:50 PM Dmitry Torokhov wrote: > On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote: > > On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote: > > > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote: > > > > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote: > > > > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote: > > > > > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote: > > > > > > > On Fri, 18 Jul 2014, Patrik Fimml wrote: > > > > > > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: > > > > > [cut] > > > > > > > > > > > > > I'm not sure what the appropriate action for a video camera is > > > > > > > > anyway. > > > > > > > > Should it go away completely, including its device? Should it be > > > > > > > > there, > > > > > > > > but certainly not be the default choice when there is an > > > > > > > > external > > > > > > > > camera? I'm thinking along the lines of some application's > > > > > > > > settings > > > > > > > > dialog here, where it might be desirable to still be able to > > > > > > > > select > > > > > > > > the > > > > > > > > internal camera for future recordings. > > > > > > > > > > > > > > > > Of course, userspace could still decide simply not to > > > > > > > > quiesce|deactivate|inhibit the device if that was desired. > > > > > > > > > > > > > > There's some question about how much of userspace needs to get > > > > > > > involved. Just the daemon that manages these configuration > > > > > > > changes, or > > > > > > > other programs as well? I guess that's not really our problem... > > > > > > > > > > > > We need to provide means of implementing policy; the policy itself > > > > > > is not > > > > > > really our concern ;) > > > > > > > > > > > > > In the end, it sounds like you're suggesting a new pair of PM > > > > > > > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and > > > > > > > ->uninhibit(). Plus an optional (?) sysfs interface for invoking > > > > > > > the > > > > > > > callbacks. > > > > > > > > > > > > We do need sysfs interface so that userspace can talk to the devices > > > > > > in > > > > > > question; and we also need to make sure that PM core is aware of the > > > > > > new > > > > > > callbacks and provides guarantees about their interactions with > > > > > > system- > > > > > > and > > > > > > runtime-PM callbacks so that individual drivers do not have to sort > > > > > > it out > > > > > > on their own. > > > > > > > > > > A step back, please. > > > > > > > > > > I have no idea why those need to be PM callbacks. > > > > > > > > > > What you need really seems to be a way to tell a driver "ignore input > > > > > from > > > > > this device from now on as it is most likely bogus". A natural > > > > > reaction of > > > > > the driver to that might be to stop processing input from the device > > > > > and > > > > > then runtime suspend it (and prevent it from generating remote wakeup > > > > > as > > > > > that may be bogus as well), but I don't see why the PM core needs to > > > > > be > > > > > involved in that at all. > > > > > > > > So that we do not need to handle cases like: > > > > > > > > - I am already in idle state and request comes to inhibit, what do I do > > > > (in > > > > > > > driver) or: > > > I'm not sure why being "suspended" or not matters here. The PM core > > > doesn't know what physical state the device is in anyway and the driver > > > or subsystem (or another layer such as ACPI) has to track that. > > > > > > Also it seems that it should be perfectly fine to ignore input from the > > > device without suspending it as well as it is perfectly fine to be > > > suspended while you are generally not ignoring the input (just because > > > there is no input at the moment, for example). > > > > > > Yes, it make sense to suspend the device when you know you'll ignore input > > > going forward, but then if the real goal is to prevent bogus input from > > > reaching applications, then this isn't a power management problem even. > > > > The area where it must interact with power management is wakeup, both remote > > wakeup at run time and wakeup from system suspend. In particular, there's > > the question whether or not a device ignoring its input should be regarded > > as a wakeup source. > > I'd say no. > > Anyway, even though it is very tempting to declare inhibit a "deeper" state > of > runtime suspend maybe you are right and inhibit should really be separate > from > PM and drivers would have to sort out all the possible state permutations. > > Considering input devices: > > input_open(): check if device is inhibited, if so do nothing. Otherwise try > waking up itself and parent (via pm_runtime_get_sync() on itself), this will > power up the device. Do additional configuration if needed. > > input_close(): check if device is inhibited, if not do pm_runtime_put (_sync? > to make sure we power off
Re: [PATCH 10/31] watchdog: Replace __raw_get_cpu_var uses
On Fri, Jun 20, 2014 at 02:31:25PM -0500, Christoph Lameter wrote: > Most of these are the uses of &__raw_get_cpu_var for address calculation. > > touch_softlockup_watchdog_sync() uses __raw_get_cpu_var to write to > per cpu variables. Use __this_cpu_write instead. > > Cc: Wim Van Sebroeck > Cc: linux-watch...@vger.kernel.org > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 08/31] drivers/clocksource: Replace __get_cpu_var used for address calculation
On Fri, Jun 20, 2014 at 02:31:23PM -0500, Christoph Lameter wrote: > Replace __get_cpu_var used for address calculation with this_cpu_ptr. > > Acked-by: James Hogan > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 09/31] drivers/net/ethernet/tile: Replace __get_cpu_var uses for address calculation
On Fri, Jun 20, 2014 at 02:31:24PM -0500, Christoph Lameter wrote: > Replace with this_cpu_ptr. > > Acked-by: Chris Metcalf > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 05/31] drivers/char/random: Replace __get_cpu_var uses
On Fri, Jun 20, 2014 at 02:31:20PM -0500, Christoph Lameter wrote: > A single case of using __get_cpu_var for address calculation. > > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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/31] drivers/oprofile: Replace __get_cpu_var uses for address calculation
On Fri, Jun 20, 2014 at 02:31:22PM -0500, Christoph Lameter wrote: > Replace the uses of __get_cpu_var for address calculation with this_cpu_ptr. > > Cc: Robert Richter > Cc: oprofile-l...@lists.sf.net > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 06/31] drivers/cpuidle: Replace __get_cpu_var uses for address calculation
On Fri, Jun 20, 2014 at 02:31:21PM -0500, Christoph Lameter wrote: > All of these are for address calculation. Replace with > this_cpu_ptr(). > > Cc: Daniel Lezcano > Cc: linux...@vger.kernel.org > Acked-by: Rafael J. Wysocki > [cpufreq changes] > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 04/31] block: Replace __this_cpu_ptr with raw_cpu_ptr
On Fri, Jun 20, 2014 at 02:31:19PM -0500, Christoph Lameter wrote: > __this_cpu_ptr is being phased out use raw_cpu_ptr instead which was > introduced in 3.15-rc1. > > Cc: Jens Axboe > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 03/31] scheduler: Replace __get_cpu_var with this_cpu_ptr
On Fri, Jun 20, 2014 at 02:31:18PM -0500, Christoph Lameter wrote: > Convert all uses of __get_cpu_var for address calculation to use > this_cpu_ptr instead. > > Cc: Peter Zijlstra > Acked-by: Ingo Molnar > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. If this patch should be routed differently, please holler. Thanks. -- tejun -- 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 01/31] kernel misc: Replace __get_cpu_var uses
On Fri, Jun 20, 2014 at 02:31:16PM -0500, Christoph Lameter wrote: > Replace uses of __get_cpu_var for address calculation with this_cpu_ptr. > > Cc: a...@linux-foundation.org > Signed-off-by: Christoph Lameter Applied to wq/for-3.17-consistent-ops. Thanks. -- tejun -- 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 13/19] ARM: s5pv210: move debug-macro.S into the common space
Hi Kukjin, On 18.07.2014 21:38, Kukjin Kim wrote: > On 07/16/14 09:56, Tomasz Figa wrote: >> On 16.07.2014 02:53, Kukjin Kim wrote: >>> Kukjin Kim wrote: On 07/05/14 02:48, Tomasz Figa wrote: > Move debug-macro.S from mach/include to include/debug where > all other common debug macros are. > > Signed-off-by: Tomasz Figa > --- >arch/arm/Kconfig.debug | 12 +-- >arch/arm/include/debug/s5pv210.S | 34 > >arch/arm/mach-s5pv210/include/mach/debug-macro.S | 41 > >3 files changed, 44 insertions(+), 43 deletions(-) >create mode 100644 arch/arm/include/debug/s5pv210.S >delete mode 100644 arch/arm/mach-s5pv210/include/mach/debug-macro.S >>> >>> [...] >>> Tomasz, I couldn't apply this one from this your series because of conflict with others. Can you please respin this one? >>> One more note, since I didn't apply this, there is a build breakage for >>> s5pv210_defconfig now... >>> >>> arch/arm/kernel/debug.S:24:33: fatal error: mach/debug-macro.S: No >>> such file or directory >>> compilation terminated. >>> make[2]: *** [arch/arm/kernel/debug.o] Error 1 >>> make[1]: *** [arch/arm/kernel] Error 2 >>> make[1]: *** Waiting for unfinished jobs >> >> Hmm? Are you sure previous patches applied correctly? I have tested this >> series patch by patch on all affected configs and it built fine back >> then. Maybe some conflict, I'll see tomorrow. >> > Tomasz, I've applied this whole series including this again. Can you > please check my branch before sending pull-request to arm-soc for 3.17? Thanks for applying this. A quick look through the patches didn't reveal any issues. s5pv210_defconfig builds fine too. I don't have any s5pv210-based board at home, though, so I can't do anything else than compile testing until Tuesday. 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/linux-next] Documentation:Docbook: Fix file locations in gadget.tmpl
Hi Felipe, On Fri, 18 Jul 2014 10:42:32 -0500 Felipe Balbi wrote: > > already in my tree, should be in linux-next already. If not today, > tomorrow. Well, Monday (logical tomorrow :-)) -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
On 07/18/14 15:42, John Stultz wrote:
> If its a regression (and needs -stable backports) it needs to go in via
> tip/timers/urgent, and not via the regular merge window.
>
> Whats the additional risk -stable wise for canceling the timer during
> suspend and starting it back up during resume?
>
I'd say close to zero given that we'd only be making the timer run a
little bit later and we have slack in there already. Here's that version.
8<-
Subject: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
During suspend we call sched_clock_poll() to update the epoch and
accumulated time and reprogram the sched_clock_timer to fire
before the next wrap-around time. Unfortunately,
sched_clock_poll() doesn't restart the timer, instead it relies
on the hrtimer layer to do that and during suspend we aren't
calling that function from the hrtimer layer. Instead, we're
reprogramming the expires time while the hrtimer is enqueued,
which can cause the hrtimer tree to be corrupted. Furthermore, we
restart the timer during suspend but we update the epoch during
resume which seems counter-intuitive.
Let's fix this by saving the accumulated state and canceling the
timer during suspend. On resume we can update the epoch and
restart the timer similar to what we would do if we were starting
the clock for the first time.
Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer"
Signed-off-by: Stephen Boyd
---
kernel/time/sched_clock.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 445106d2c729..01d2d15aa662 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -191,7 +191,8 @@ void __init sched_clock_postinit(void)
static int sched_clock_suspend(void)
{
- sched_clock_poll(_clock_timer);
+ update_sched_clock();
+ hrtimer_cancel(_clock_timer);
cd.suspended = true;
return 0;
}
@@ -199,6 +200,7 @@ static int sched_clock_suspend(void)
static void sched_clock_resume(void)
{
cd.epoch_cyc = read_sched_clock();
+ hrtimer_start(_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
cd.suspended = false;
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: android: Fixed missing blank line
On Fri, Jul 18, 2014 at 10:17:54AM +0530, Sanjeev Sharma wrote:
> This patch will add an blank line after
> declaration reported by checkpatch.pl script.
>
> Signed-off-by: Sanjeev Sharma
> ---
> drivers/staging/android/sw_sync.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/android/sw_sync.c
> b/drivers/staging/android/sw_sync.c
> index a76db3f..863d4b1 100644
> --- a/drivers/staging/android/sw_sync.c
> +++ b/drivers/staging/android/sw_sync.c
> @@ -97,6 +97,7 @@ static void sw_sync_pt_value_str(struct sync_pt *sync_pt,
> char *str, int size)
> {
> struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
> +
> snprintf(str, size, "%d", pt->value);
> }
>
> @@ -156,6 +157,7 @@ static int sw_sync_open(struct inode *inode, struct file
> *file)
> static int sw_sync_release(struct inode *inode, struct file *file)
> {
> struct sw_sync_timeline *obj = file->private_data;
> +
> sync_timeline_destroy(>obj);
> return 0;
> }
I already applied a previous version of this patch, with your gmail
address :(
--
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: Power-managing devices that are not of interest at some point in time
On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote: > On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote: > > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote: > > > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote: > > > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote: > > > > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote: > > > > > > On Fri, 18 Jul 2014, Patrik Fimml wrote: > > > > > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: > > > > [cut] > > > > > > > > > > > I'm not sure what the appropriate action for a video camera is > > > > > > > anyway. > > > > > > > Should it go away completely, including its device? Should it be > > > > > > > there, > > > > > > > but certainly not be the default choice when there is an > > > > > > > external > > > > > > > camera? I'm thinking along the lines of some application's > > > > > > > settings > > > > > > > dialog here, where it might be desirable to still be able to > > > > > > > select > > > > > > > the > > > > > > > internal camera for future recordings. > > > > > > > > > > > > > > Of course, userspace could still decide simply not to > > > > > > > quiesce|deactivate|inhibit the device if that was desired. > > > > > > > > > > > > There's some question about how much of userspace needs to get > > > > > > involved. Just the daemon that manages these configuration > > > > > > changes, or > > > > > > other programs as well? I guess that's not really our problem... > > > > > > > > > > We need to provide means of implementing policy; the policy itself > > > > > is not > > > > > really our concern ;) > > > > > > > > > > > In the end, it sounds like you're suggesting a new pair of PM > > > > > > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and > > > > > > ->uninhibit(). Plus an optional (?) sysfs interface for invoking > > > > > > the > > > > > > callbacks. > > > > > > > > > > We do need sysfs interface so that userspace can talk to the devices > > > > > in > > > > > question; and we also need to make sure that PM core is aware of the > > > > > new > > > > > callbacks and provides guarantees about their interactions with > > > > > system- > > > > > and > > > > > runtime-PM callbacks so that individual drivers do not have to sort > > > > > it out > > > > > on their own. > > > > > > > > A step back, please. > > > > > > > > I have no idea why those need to be PM callbacks. > > > > > > > > What you need really seems to be a way to tell a driver "ignore input > > > > from > > > > this device from now on as it is most likely bogus". A natural > > > > reaction of > > > > the driver to that might be to stop processing input from the device > > > > and > > > > then runtime suspend it (and prevent it from generating remote wakeup > > > > as > > > > that may be bogus as well), but I don't see why the PM core needs to > > > > be > > > > involved in that at all. > > > > > > So that we do not need to handle cases like: > > > > > > - I am already in idle state and request comes to inhibit, what do I do > > > (in > > > > > driver) or: > > I'm not sure why being "suspended" or not matters here. The PM core > > doesn't know what physical state the device is in anyway and the driver > > or subsystem (or another layer such as ACPI) has to track that. > > > > Also it seems that it should be perfectly fine to ignore input from the > > device without suspending it as well as it is perfectly fine to be > > suspended while you are generally not ignoring the input (just because > > there is no input at the moment, for example). > > > > Yes, it make sense to suspend the device when you know you'll ignore input > > going forward, but then if the real goal is to prevent bogus input from > > reaching applications, then this isn't a power management problem even. > > The area where it must interact with power management is wakeup, both remote > wakeup at run time and wakeup from system suspend. In particular, there's > the question whether or not a device ignoring its input should be regarded > as a wakeup source. I'd say no. Anyway, even though it is very tempting to declare inhibit a "deeper" state of runtime suspend maybe you are right and inhibit should really be separate from PM and drivers would have to sort out all the possible state permutations. Considering input devices: input_open(): check if device is inhibited, if so do nothing. Otherwise try waking up itself and parent (via pm_runtime_get_sync() on itself), this will power up the device. Do additional configuration if needed. input_close(): check if device is inhibited, if not do pm_runtime_put (_sync? to make sure we power off properly and not leave device up and running? or should we power down manually not waiting for runtime PM)? inhibit(): check if device is opened, if opened do pm_runtime_put_sync(). uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime PM bring up the device.
Re: [PATCH] Staging: vt6655: apply kernel coding style to wCommandTimerWait function
On Fri, Jul 18, 2014 at 09:35:13PM +0300, Igor Bezukh wrote: > Since there is a lot of stuff that need to be changed in order to meet the > kernel > coding style in wcmd.c file, I've decided to fix function-per-patch. > The following changes were made in vCommandTimerWait function: > > - Camel case change: >- MSecond ---> msec >- hDdeviceContext ---> private >- pDevice ---> priv > - Removed redundant return > - Removed redndant comment > > In future patches, I will also change the function name itself. A better way to do this, that is easier to review, is to do, on a per-file basis, one thing, like "remove redundant return", or "remove unneeded comments". Having to review all of these changes at once, even for something as "small" as a single function, is much harder than making sure you only do one thing, and do it all at once. So, can you break it up in this way instead? 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 1/2] Staging: comedi: adl_pci9118: commenting style issue fixed
On Fri, Jul 18, 2014 at 11:13:07PM +0300, Sam Asadi wrote:
> A 'quoted string split across lines' issue fixed, while a better use of
> language applied to the comment.
>
> Signed-off-by: Sam Asadi
> ---
> drivers/staging/comedi/drivers/adl_pci9118.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
> b/drivers/staging/comedi/drivers/adl_pci9118.c
> index 93bd9ee..7365f31 100644
> --- a/drivers/staging/comedi/drivers/adl_pci9118.c
> +++ b/drivers/staging/comedi/drivers/adl_pci9118.c
> @@ -418,8 +418,7 @@ static int check_channel_list(struct comedi_device *dev,
> if ((CR_RANGE(chanlist[i]) < PCI9118_BIPOLAR_RANGES) !=
> (bipolar)) {
> comedi_error(dev,
> - "Bipolar and unipolar ranges "
> - "can't be mixtured!");
> + "Bipolar and unipolar ranges can't
> be mixed!");
What tree did you refresh this against? My staging-next branch of
staging.git on git.kernel.org does not have comedi_error() anymore in it
:(
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 25/25] ipack: Replace DEFINE_PCI_DEVICE_TABLE macro use
On Fri, Jul 18, 2014 at 05:59:16PM +0200, Samuel Iglesias Gonsálvez wrote:
> On Fri, 2014-07-18 at 17:27 +0200, Benoit Taine wrote:
> > We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to
> > meet
> > kernel coding style guidelines. This issue was reported by checkpatch.
> >
> > Signed-off-by: Benoit Taine
> >
> > ---
> > Tested by compilation without errors.
> >
> > drivers/ipack/carriers/tpci200.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/ipack/carriers/tpci200.c
> > b/drivers/ipack/carriers/tpci200.c
> > index c276fde..de5e321 100644
> > --- a/drivers/ipack/carriers/tpci200.c
> > +++ b/drivers/ipack/carriers/tpci200.c
> > @@ -618,7 +618,7 @@ static void tpci200_pci_remove(struct pci_dev *dev)
> > __tpci200_pci_remove(tpci200);
> > }
> >
> > -static DEFINE_PCI_DEVICE_TABLE(tpci200_idtable) = {
> > +static const struct pci_device_id tpci200_idtable[] = {
> > { TPCI200_VENDOR_ID, TPCI200_DEVICE_ID, TPCI200_SUBVENDOR_ID,
> > TPCI200_SUBDEVICE_ID },
> > { 0, },
> >
> >
>
> Acked-by: Samuel Iglesias Gonsalvez
>
> Greg, Would you mind picking this patch through your char-misc tree?
Will do, 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 1/1 V2] workqueue: unfold start_worker() into create_worker()
Sorry about the delay. On Wed, Jul 16, 2014 at 09:28:55AM +0800, Lai Jiangshan wrote: > On 07/14/2014 12:05 PM, Lai Jiangshan wrote: > > Simply unfold the code of start_worker() into create_worker() and > > remove the original start_worker() and create_and_start_worker(). > > > > The only trade-off is the introduced overhead that the pool->lock > > is released and re-grabbed after the newly worker is started. > > The overhead is acceptable since the manager is slow path. > > Hi, TJ > > Will you accept this trade-off and the patch? > If so, I will rebase this patch without any dependence on other patch. Yeap, that's fine. Thanks! -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] workqueue: remove the argument @wakeup from worker_set_flags()
On Fri, Jul 18, 2014 at 06:38:26PM -0400, Tejun Heo wrote: > On Wed, Jul 16, 2014 at 06:09:59PM +0800, Lai Jiangshan wrote: > > worker_set_flags() doesn't necessarily wake next worker and the @wakeup > > can be removed, the caller can use the following conbination instead > > when needed: > > > > worker_set_flags(); > > if (need_more_worker(pool)) > > wake_up_worker(pool); > > Hmmm, yeah, there were more places where worker_set_flags() was used > but it does seem excessive now. > > > @@ -2045,7 +2032,7 @@ __acquires(>lock) > > * management. They're the scheduler's responsibility. > > */ > > if (unlikely(cpu_intensive)) > > - worker_set_flags(worker, WORKER_CPU_INTENSIVE, true); > > + worker_set_flags(worker, WORKER_CPU_INTENSIVE); > > But let's do this separately. Please drop the previous patch and > perform need_more_worker() test explicitly after setting > CPU_INTENSIVE. So, we can do it together at need_more_workers() but let's please explain how different cases would behave there. Thanks. -- tejun -- 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] workqueue: remove unneeded test before wake up next worker
On Fri, Jul 18, 2014 at 06:05:14PM -0400, Tejun Heo wrote: > On Wed, Jul 16, 2014 at 06:09:58PM +0800, Lai Jiangshan wrote: > > In this code: > > if ((worker->flags & WORKER_UNBOUND) && need_more_worker(pool)) > > wake_up_worker(pool); > > > > the first test is unneeded. Even the first test is removed, it doesn't > > affect > > the wake-up logic when WORKER_UNBOUND. And it will not introduce any useless > > wake-up when !WORKER_UNBOUND since the nr_running >= 1 except only one case. > > It will introduce useless/redundant wake-up when cpu_intensive, but this > > case is rare and next patch will also remove this redundant wake-up. > > > > Signed-off-by: Lai Jiangshan > > --- > > kernel/workqueue.c |7 ++- > > 1 files changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > > index f8d54c1..6d11b9a 100644 > > --- a/kernel/workqueue.c > > +++ b/kernel/workqueue.c > > @@ -2047,11 +2047,8 @@ __acquires(>lock) > > if (unlikely(cpu_intensive)) > > worker_set_flags(worker, WORKER_CPU_INTENSIVE, true); > > > > - /* > > -* Unbound pool isn't concurrency managed and work items should be > > -* executed ASAP. Wake up another worker if necessary. > > -*/ > > - if ((worker->flags & WORKER_UNBOUND) && need_more_worker(pool)) > > + /* Wake up another worker if necessary. */ > > + if (need_more_worker(pool)) > > wake_up_worker(pool); > > What does this buy us? Sure, it may achieve about the same operation > but it's a lot more confusing. need_more_worker() is specifically for > concurrency management. Applying it to unmanaged workers could lead > to okay behavior but conflating the two to save one test on worker > flags doesn't seem like a good trade-off to me. I take this back. We do guarantee that need_more_worker() returns %true for unbound pools and make use of that fact but I'd like it to retain the comment about unbound pools. Thanks. -- tejun -- 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] ARM: Don't oops when userspace executes kgdb break instructions.
Don't break into kgdb when userspace executes the kernel break instructions
(KGDB_BREAKINST and KGDB_COMPILED_BREAK). The kernel will oops in
kgdb_handle_exception.
Signed-off-by: Omar Sandoval
---
The following program will immediately cause a kernel oops:
.globl _start
_start:
udf #65006 @ KGDB_BREAKINST
arch/arm/kernel/kgdb.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index 778c2f7..a74b53c 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -160,12 +160,16 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs,
unsigned int instr)
static struct undef_hook kgdb_brkpt_hook = {
.instr_mask = 0x,
.instr_val = KGDB_BREAKINST,
+ .cpsr_mask = MODE_MASK,
+ .cpsr_val = SVC_MODE,
.fn = kgdb_brk_fn
};
static struct undef_hook kgdb_compiled_brkpt_hook = {
.instr_mask = 0x,
.instr_val = KGDB_COMPILED_BREAK,
+ .cpsr_mask = MODE_MASK,
+ .cpsr_val = SVC_MODE,
.fn = kgdb_compiled_brk_fn
};
--
2.0.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] workqueue: detach rescuer from pool until the last
Hello, On Wed, Jul 16, 2014 at 02:56:50PM +0800, Lai Jiangshan wrote: > @@ -2300,11 +2300,6 @@ repeat: > move_linked_works(work, scheduled, ); > > process_scheduled_works(rescuer); > - spin_unlock_irq(>lock); > - > - worker_detach_from_pool(rescuer, pool); > - > - spin_lock_irq(>lock); > > /* >* Put the reference grabbed by send_mayday(). @pool won't > @@ -2322,8 +2317,11 @@ repeat: > wake_up_worker(pool); > > rescuer->pool = NULL; > - spin_unlock(>lock); > - spin_lock(_mayday_lock); > + spin_unlock_irq(>lock); > + > + worker_detach_from_pool(rescuer, pool); > + > + spin_lock_irq(_mayday_lock); Can you please also update the comment above put_pwq() and explain above detach that @pool will stay around till detach is complete? Thanks. -- tejun -- 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: How to automate checkpatch && get_maintainers && git send-email of commits range?
On Fri, 2014-07-18 at 15:47 -0700, Joe Perches wrote: > On Fri, 2014-07-18 at 18:22 -0400, Theodore Ts'o wrote: > > and get_maintainers.pl. > I think checkpatch Umm, make that get_maintainer... > is pretty good about cc'ing mostly the > right folk by default. -- 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] Boot hang with 939f04bec printk: enable interrupts before calling console_trylock_for_printk()
On Thu, Jul 17, 2014 at 10:31:37AM +0200, Jan Kara wrote: > On Wed 16-07-14 23:34:08, Andreas Bombe wrote: > > On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote: > > > On Sun 29-06-14 00:50:50, Andreas Bombe wrote: > > > > None of the post 3.15 kernel boot for me. They all hang at the GRUB > > > > screen telling me it loaded and started the kernel, but the kernel > > > > itself stops before it prints anything (or even replaces the GRUB > > > > background graphics). > > > > > > > > I bisected it down to 939f04bec1a4ef6ba4370b0f34b01decc844b1b1 "printk: > > > > enable interrupts before calling console_trylock_for_printk()". > > > > Reverting that patch on the latest kernel (git 24b414d5a7) allows me to > > > > boot normally. I fixed the conflict in the revert by leaving in the "if > > > > (in_sched) return printed_len;". > > > > > > > > I have the "early printk via the EFI framebuffer" option enabled, > > > > disabling it made no difference however. > > > Thanks for report. I've been on vacation so I'm replying with a delay. I > > > believe this is one of the issues where this patch just uncovers > > > underlying > > > problem - I belive lockdep tries to report some locking issue in console > > > driver code (this patch increased lockdep coverage of console driver code) > > > however we are holding some locks in printk code which make lockdep > > > deadlock. Can you try running with the attached patch? > > > > EUNABLE > > > > You forgot to attach a patch. > Bah, sorry. Attaching now. I don't see anything in /sys/kernel/debug/tracing/trace_pipe or .../trace (besides the header) with your patch applied. In case you meant to test it with the problematic printk change, I also tried with the revert reverted. That still hangs as before without any error report to see. I checked the kernel logs and there is also no lockdep report anywhere. I get the "trace_printk() being used" notice but nothing else of interest around there. Though the notice should mean trace_printk() was used at least once? -- 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: How to automate checkpatch && get_maintainers && git send-email of commits range?
On Fri, 2014-07-18 at 18:22 -0400, Theodore Ts'o wrote: > On Fri, Jul 18, 2014 at 05:38:30PM +0300, Andrey Utkin wrote: > > Is there script for automated checkpatch.pl && get_maintainers.pl && > > git send-email for range of commits? I see none. Would it be welcome > > to submit such one to kernel tree? > > Too much automation can be a really bad thing. You **really** want to > sanity check the output of checkpatch.pl True. checkpatch should not be used on existing commits. checkpatch should be used prior to committing. > and get_maintainers.pl. I think checkpatch is pretty good about cc'ing mostly the right folk by default. Where it's not adequate is when some particular bit of code was written by someone not the maintainer and that writer should also be copied on a patch. Many different command-line options exist for get_maintainer. Perhaps too many. --git-blame can be used with patches to also list the author of any modified commit. Using that option can take a fairly long while to run though. > Their output is not always correct, and some amount of human common > sense is required. True. Experience is more of a benefit than common sense here. > And then think very hard about which patches people need to see in > order to be able to evaluate a patch. For example, if you have patch > 1 out of a series which adds a new function, and then patches 2 > through 1000 modify a thousand different drivers to use that new > function, if you use an automated get_maintainers.pl script to send > each patch to just the maintainer, then the device driver maintainer > might not see patch #1 which is critical context to understanding the > patch that you want to make to his driver. And then you will have > several hundred very angry and annoyed developers wondering why you > sent them patch 345/1000, with no other context, and wondering what > the heck they are supposed to do with the email that you have just > launched into their inbox. There is no good solution to this problem. You can't cc the world on patch 1/n (vger rejects emails with too many recipients) and cc just the maintainers on x/n. One solution is to send the 0/n and 1/n patches to all the email lists that are cc'd on any single patch of large patch series. A better solution might be to send _only_ the 1/n patch to lkml and to someone like Andrew Morton with an explanation as to why it's useful, wait for it to be applied, then send the large patch series during the next release cycle. > There's a reason why many developers cordially hate these scripts; > it's too easy to misuse them, Yup, though cordial can be a misdescription for some of those developers... I hope everyone enjoys their weekends... -- 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] workqueue: wake regular worker if need_more_worker() when rescuer leave the pool
On Wed, Jul 16, 2014 at 02:56:36PM +0800, Lai Jiangshan wrote: > We don't need to wake up regular worker when nr_running==1, > so need_more_worker() is sufficient here. > > And need_more_worker() gives us better readability due to the name of > "keep_working()" implies the rescuer should keep working now but > the rescuer is actually leaving. > > Signed-off-by: Lai Jiangshan Applied to wq/for-3.17. Thanks. -- tejun -- 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_clock: Avoid corrupting hrtimer tree during suspend
On 07/18/2014 03:38 PM, Stephen Boyd wrote: > On 07/18/14 15:25, John Stultz wrote: >> On 07/18/2014 03:09 PM, Stephen Boyd wrote: >>> During suspend we call sched_clock_poll() to update the epoch and >>> accumulated time and reprogram the sched_clock_timer to fire >>> before the next wrap-around time. Unfortunately, >>> sched_clock_poll() doesn't restart the timer, instead it relies >>> on the hrtimer layer to do that and during suspend we aren't >>> calling that function from the hrtimer layer. Instead, we're >>> reprogramming the expires time while the hrtimer is enqueued, >>> which can cause the hrtimer tree to be corrupted. Fix this >>> problem by updating the state via update_sched_clock() and >>> properly restarting the timer via hrtimer_start(). >>> >>> Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer" >>> Signed-off-by: Stephen Boyd >>> --- >>> >>> I also wonder if we should be restarting the timer during resume >>> instead of suspend given that the resume path modifies the epoch. >>> At that point timers can't run because interrupts are disabled and >>> we don't really care if the timer fires earlier than it's supposed >>> to anyway because it's just there to avoid rollover events, but >>> does it seem better to do it that way? I didn't send that version >>> because this patch is to fix the code intention, but I'm curious >>> if anyone else feels like it should be changed. >> Yea, starting the timer on suspend seems unintuitive to me. >> >> Is this something you were hoping to get in for 3.17 or is this a urgent >> 3.16 item? > Ok I'll send a follow up patch to cancel during suspend and start during > resume, unless you want that to be part of this fix? It's a regression > back to v3.13 so I would think it's urgent, although I haven't seen any > reports on the mailing list, just reports on some of our android kernels. If its a regression (and needs -stable backports) it needs to go in via tip/timers/urgent, and not via the regular merge window. Whats the additional risk -stable wise for canceling the timer during suspend and starting it back up during resume? thanks -john -- 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] sched_clock: Track monotonic raw clock
On Fri, Jul 18, 2014 at 10:22:50PM +0200, Peter Zijlstra wrote: > So the generic stuff seems optimized for 32bit arch, short clocks and > seems to hard assume the clock is globally consistent. > > The x86 sched_clock code is optimized for 64bit, has a full 64bit clock > and cannot ever assume the thing is globally consistent (until Intel/AMD > stop making the TSC register writable -- including, and maybe > especially, for SMM). > > There is just not much that overlaps there. So something that might be usable for all of us would be the 'abstracted' control loop. So the problem is, given a Set Point (CLOCK_MONOTONIC_RAW), a Process Variable (sched_clock) compute a Control Output (multiplier). If that were implemented with an interface like: struct sched_clock_cl; /* Control Loop state */ /** * sched_clock_cl_init - intialize the control loop */ extern void sched_clock_cl_init(struct sched_clock_cl *sccl, u32 mult, u32 shift); /** * sched_clock_cl_update - compute a new multiplier for sched_clock * @sccl - pointer to control loop state structure * @sp - current set-point, aka. CLOCK_MONOTONIC_RAW * @pv - current process-variable, aka. sched_clock() */ extern u32 sched_clock_cl_update(struct sched_clock_cl *sccl, u64 sp, u64 pv); That way I can run one per-cpu and try and keep each individual CPU synced up to CLOCK_MONOTONIC_RAW, thereby also providing some inter-cpu guarantee (due to max error bounds on the control loop, etc..). And you can run a single instance for the generic sched_clock code, since that's globally consistent. And we'd all still be using the same control loop logic. Now, I already mentioned max error bounds, and I've not yet looked at your actual control loop, but that is something to keep in mind, we want something that's limited. If we can do this (and I'm fairly sure we can) we can in fact kill some rather ugly code. pgpiIgBVsre2E.pgp Description: PGP signature
Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
On 07/18/14 15:25, John Stultz wrote: > On 07/18/2014 03:09 PM, Stephen Boyd wrote: >> During suspend we call sched_clock_poll() to update the epoch and >> accumulated time and reprogram the sched_clock_timer to fire >> before the next wrap-around time. Unfortunately, >> sched_clock_poll() doesn't restart the timer, instead it relies >> on the hrtimer layer to do that and during suspend we aren't >> calling that function from the hrtimer layer. Instead, we're >> reprogramming the expires time while the hrtimer is enqueued, >> which can cause the hrtimer tree to be corrupted. Fix this >> problem by updating the state via update_sched_clock() and >> properly restarting the timer via hrtimer_start(). >> >> Fixes: a08ca5d1089d "sched_clock: Use an hrtimer instead of timer" >> Signed-off-by: Stephen Boyd >> --- >> >> I also wonder if we should be restarting the timer during resume >> instead of suspend given that the resume path modifies the epoch. >> At that point timers can't run because interrupts are disabled and >> we don't really care if the timer fires earlier than it's supposed >> to anyway because it's just there to avoid rollover events, but >> does it seem better to do it that way? I didn't send that version >> because this patch is to fix the code intention, but I'm curious >> if anyone else feels like it should be changed. > Yea, starting the timer on suspend seems unintuitive to me. > > Is this something you were hoping to get in for 3.17 or is this a urgent > 3.16 item? Ok I'll send a follow up patch to cancel during suspend and start during resume, unless you want that to be part of this fix? It's a regression back to v3.13 so I would think it's urgent, although I haven't seen any reports on the mailing list, just reports on some of our android kernels. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] workqueue: remove the argument @wakeup from worker_set_flags()
On Wed, Jul 16, 2014 at 06:09:59PM +0800, Lai Jiangshan wrote: > worker_set_flags() doesn't necessarily wake next worker and the @wakeup > can be removed, the caller can use the following conbination instead > when needed: > > worker_set_flags(); > if (need_more_worker(pool)) > wake_up_worker(pool); Hmmm, yeah, there were more places where worker_set_flags() was used but it does seem excessive now. > @@ -2045,7 +2032,7 @@ __acquires(>lock) >* management. They're the scheduler's responsibility. >*/ > if (unlikely(cpu_intensive)) > - worker_set_flags(worker, WORKER_CPU_INTENSIVE, true); > + worker_set_flags(worker, WORKER_CPU_INTENSIVE); But let's do this separately. Please drop the previous patch and perform need_more_worker() test explicitly after setting CPU_INTENSIVE. Thanks. -- tejun -- 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: Power-managing devices that are not of interest at some point in time
On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote: > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote: > > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote: > > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote: > > > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote: > > > > > On Fri, 18 Jul 2014, Patrik Fimml wrote: > > > > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote: > > > [cut] > > > > > > > > > I'm not sure what the appropriate action for a video camera is > > > > > > anyway. > > > > > > Should it go away completely, including its device? Should it be > > > > > > there, > > > > > > but certainly not be the default choice when there is an external > > > > > > camera? I'm thinking along the lines of some application's settings > > > > > > dialog here, where it might be desirable to still be able to select > > > > > > the > > > > > > internal camera for future recordings. > > > > > > > > > > > > Of course, userspace could still decide simply not to > > > > > > quiesce|deactivate|inhibit the device if that was desired. > > > > > > > > > > There's some question about how much of userspace needs to get > > > > > involved. Just the daemon that manages these configuration changes, > > > > > or > > > > > other programs as well? I guess that's not really our problem... > > > > > > > > We need to provide means of implementing policy; the policy itself is > > > > not > > > > really our concern ;) > > > > > > > > > In the end, it sounds like you're suggesting a new pair of PM > > > > > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and > > > > > ->uninhibit(). Plus an optional (?) sysfs interface for invoking the > > > > > callbacks. > > > > > > > > We do need sysfs interface so that userspace can talk to the devices in > > > > question; and we also need to make sure that PM core is aware of the new > > > > callbacks and provides guarantees about their interactions with system- > > > > and > > > > runtime-PM callbacks so that individual drivers do not have to sort it > > > > out > > > > on their own. > > > > > > A step back, please. > > > > > > I have no idea why those need to be PM callbacks. > > > > > > What you need really seems to be a way to tell a driver "ignore input from > > > this device from now on as it is most likely bogus". A natural reaction > > > of > > > the driver to that might be to stop processing input from the device and > > > then runtime suspend it (and prevent it from generating remote wakeup as > > > that may be bogus as well), but I don't see why the PM core needs to be > > > involved in that at all. > > > > So that we do not need to handle cases like: > > > > - I am already in idle state and request comes to inhibit, what do I do (in > > driver) or: > > I'm not sure why being "suspended" or not matters here. The PM core doesn't > know what physical state the device is in anyway and the driver or subsystem > (or another layer such as ACPI) has to track that. > > Also it seems that it should be perfectly fine to ignore input from the device > without suspending it as well as it is perfectly fine to be suspended while > you are generally not ignoring the input (just because there is no input at > the moment, for example). > > Yes, it make sense to suspend the device when you know you'll ignore input > going > forward, but then if the real goal is to prevent bogus input from reaching > applications, then this isn't a power management problem even. The area where it must interact with power management is wakeup, both remote wakeup at run time and wakeup from system suspend. In particular, there's the question whether or not a device ignoring its input should be regarded as a wakeup source. Rafael -- 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 8/7] seccomp: Document two-phase seccomp and arch-provided seccomp_data
The description of how arches should implement seccomp filters was still strictly correct, but it failed to describe the newly available optimizations. Signed-off-by: Andy Lutomirski --- I lost this somehow. Here it as an an extra patch. If I end up sending a v3, I'll fold it in. arch/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index 0eae9df..05d7a8a 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -323,6 +323,17 @@ config HAVE_ARCH_SECCOMP_FILTER results in the system call being skipped immediately. - seccomp syscall wired up + For best performance, an arch should use seccomp_phase1 and + seccomp_phase2 directly. It should call seccomp_phase1 for all + syscalls if TIF_SECCOMP is set, but seccomp_phase1 does not + need to be called from a ptrace-safe context. It must then + call seccomp_phase2 if seccomp_phase1 returns anything other + than SECCOMP_PHASE1_OK or SECCOMP_PHASE1_SKIP. + + As an additional optimization, an arch may provide seccomp_data + directly to seccomp_phase1; this avoids multiple calls + to the syscall_xyz helpers for every syscall. + config SECCOMP_FILTER def_bool y depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/7] seccomp: Allow arch code to provide seccomp_data
On Fri, Jul 18, 2014 at 3:16 PM, Kees Cook wrote: > On Fri, Jul 18, 2014 at 2:18 PM, Andy Lutomirski wrote: >> populate_seccomp_data is expensive: it works by inspecting >> task_pt_regs and various other bits to piece together all the >> information, and it's does so in multiple partially redundant steps. >> >> Arch-specific code in the syscall entry path can do much better. >> >> Admittedly this adds a bit of additional room for error, but the >> speedup should be worth it. > > I still think we should gain either a note in the > HAVE_ARCH_SECCOMP_FILTER help text in arch/Kconfig, or possibly a new > section in Documentation/prctl/seccomp.txt (or similar) on how do > implement filter support for an architecture, that mentions the > arch-supplied seccomp_data and how two-phase can be done. I would have sworn I did that. I distinctly remember typing that text. I must have failed to commit it. I'll send a followup patch. --Andy > > -Kees > > -- > Kees Cook > Chrome OS Security -- Andy Lutomirski AMA Capital Management, LLC -- 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/
