On Tue, Oct 06, 2015 at 10:01:01AM -0700, Paul E. McKenney wrote:
> On Tue, Oct 06, 2015 at 09:44:45AM -0700, Josh Triplett wrote:
> > On Tue, Oct 06, 2015 at 09:13:39AM -0700, Paul E. McKenney wrote:
> > > From: Boqun Feng <boqun.f...@gmail.com>
> > >
>
On Tue, Oct 06, 2015 at 10:36:46AM -0700, Paul E. McKenney wrote:
> On Tue, Oct 06, 2015 at 10:18:39AM -0700, Josh Triplett wrote:
> > On Tue, Oct 06, 2015 at 09:13:42AM -0700, Paul E. McKenney wrote:
> > > Currently, __srcu_read_lock() cannot be invoked from restricted
> >
terov.
>
> 13. Cleanup the CONFIG_PROVE_RCU checks, courtesy of Oleg Nesterov.
For all 13:
Reviewed-by: Josh Triplett <j...@joshtriplett.org>
Regarding the rcu_sync infrastructure: odd that an atomic read
on the reader proves ligher weight than
rcu_read_lock()/rcu_read_unlo
On Tue, Oct 06, 2015 at 09:13:41AM -0700, Paul E. McKenney wrote:
> This commit makes the RCU CPU stall warning message print online/offline
> indications immediately after the CPU number. A "?" indicates global
> offline, a "," global online, and a "!" indicates RCU believes that the
> CPU is
.edu/amatveev/RLU_SOSP2015.pdf
>
> 12. Remove deprecated rcu_lockdep_assert().
(And a patch 13 not mentioned here.)
I responded to patches 4, 6, and 10 with feedback; for the rest (and for
those with the issues addressed):
Reviewed-by: Josh Triplett <j...@joshtriplett.org>
--
To unsubsc
> 3.Update whatisRCU() to show rcu_dereference_protected(),
> courtesy of Jason A. Donenfeld.
>
> 4.Catch up list of torture_type options.
>
> 5.Add lockless_dereference() to memory-barriers.txt.
For all five:
Reviewed-by: Josh Triplett <j...@joshtriplet
eview of rcu_torture_cleanup and the cur_ops->init()
functions to verify that the dire comment about not using "goto unwind"
doesn't actually apply (rcu_torture_cleanup *seems* to handle lack of
init), this seems fine.
Reviewed-by: Josh Triplett <j...@joshtriplett.org>
> kernel/rcu/
On Tue, Oct 06, 2015 at 10:31:52AM -0700, Paul E. McKenney wrote:
> On Tue, Oct 06, 2015 at 10:21:28AM -0700, Josh Triplett wrote:
> > On Tue, Oct 06, 2015 at 09:13:45AM -0700, Paul E. McKenney wrote:
> > > This commit adds an rcu_pointer_handoff() that is intended to mark
>
t; 3.Forgive non-plural arguments.
>
> 4.Fix module unwind when bad torture_type specified to locktorture.
For all four:
Reviewed-by: Josh Triplett <j...@joshtriplett.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Tue, Oct 06, 2015 at 09:13:42AM -0700, Paul E. McKenney wrote:
> Currently, __srcu_read_lock() cannot be invoked from restricted
> environments because it contains calls to preempt_disable() and
> preempt_enable(), both of which can invoke lockdep, which is a bad
> idea in some restricted
I'll be present in-person at Kernel Summit for the election.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sat, Oct 03, 2015 at 02:11:57PM +, Mathieu Desnoyers wrote:
> - On Oct 3, 2015, at 12:38 AM, dvhart dvh...@infradead.org wrote:
>
> > On Mon, Sep 28, 2015 at 03:16:53AM +, Mathieu Desnoyers wrote:
> >> - On Sep 27, 2015, at 10:10 PM, Wang Long long.wangl...@huawei.com
> >>
On Sat, Oct 03, 2015 at 02:11:57PM +, Mathieu Desnoyers wrote:
> - On Oct 3, 2015, at 12:38 AM, dvhart dvh...@infradead.org wrote:
>
> > On Mon, Sep 28, 2015 at 03:16:53AM +, Mathieu Desnoyers wrote:
> >> - On Sep 27, 2015, at 10:10 PM, Wang Long long.wangl...@huawei.com
> >>
On Tue, Sep 15, 2015 at 12:42:00PM +0300, Kirill A. Shutemov wrote:
> On Mon, Sep 14, 2015 at 10:19:19PM -0700, Josh Triplett wrote:
> > On Tue, Sep 15, 2015 at 03:23:58AM +0300, Kirill A. Shutemov wrote:
> > > On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
On Tue, Sep 15, 2015 at 12:42:00PM +0300, Kirill A. Shutemov wrote:
> On Mon, Sep 14, 2015 at 10:19:19PM -0700, Josh Triplett wrote:
> > On Tue, Sep 15, 2015 at 03:23:58AM +0300, Kirill A. Shutemov wrote:
> > > On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote:
without user separation (for instance, without CONFIG_MULTIUSER)
can reasonably use MAP_UNINITIALIZED.
> P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
> mailing list on why it was allowed.
That's what the config option *and* explicit flag are for; there are
more th
without user separation (for instance, without CONFIG_MULTIUSER)
can reasonably use MAP_UNINITIALIZED.
> P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig
> mailing list on why it was allowed.
That's what the config option *and* explicit flag are for; there are
more th
96b54a2 (""Tree RCU": scalable
> classic RCU implementation") since it is not needed here either.
>
> We leave some tags like MODULE_AUTHOR for documentation purposes.
>
> Cc: "Paul E. McKenney"
> Cc: Josh Triplett
> Cc: Steven Rostedt
> Cc: Mathi
either.
We leave some tags like MODULE_AUTHOR for documentation purposes.
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Josh Triplett j...@joshtriplett.org
Cc: Steven Rostedt rost...@goodmis.org
Cc: Mathieu Desnoyers mathieu.desnoy...@efficios.com
Cc: Lai Jiangshan jiangshan
On Wed, Aug 12, 2015 at 05:55:19PM -0700, Kees Cook wrote:
> Most modern systems can run with vsyscall=none. In an effort to provide
> a way for build-time defaults to lack legacy settings, this adds a new
> CONFIG to select the type of vsyscall mapping to use, similar to the
> existing "vsyscall"
On Wed, Aug 12, 2015 at 05:55:19PM -0700, Kees Cook wrote:
Most modern systems can run with vsyscall=none. In an effort to provide
a way for build-time defaults to lack legacy settings, this adds a new
CONFIG to select the type of vsyscall mapping to use, similar to the
existing vsyscall
On Fri, Jul 31, 2015 at 09:56:46PM -0700, H. Peter Anvin wrote:
> On 07/31/2015 09:32 PM, Josh Triplett wrote:
> >
> > Sure, agreed. But I really hope we don't create new kernel ABIs that
> > involve constructs like that.
> >
>
> It's worth noting I have pushe
On Fri, Jul 31, 2015 at 09:56:46PM -0700, H. Peter Anvin wrote:
On 07/31/2015 09:32 PM, Josh Triplett wrote:
Sure, agreed. But I really hope we don't create new kernel ABIs that
involve constructs like that.
It's worth noting I have pushed for auto-marshalling in general for a
long
from_user and
> > copy_param_struct on appropriate sets of __user parameters identified as
> > such in a structured text file seems quite sufficient. (Plus
> > automatically generating syscalls.h from that.)
>
> If a param struct does the trick, then I agree. It's when you start
>
d-off-by: David Drysdale
> Reviewed-by: Michael Kerrisk
> Reviewed-by: Eric B Munson
> Reviewed-by: Kees Cook
> Reviewed-by: Randy Dunlap
Other than the change to the mention of capabilities, this now looks
ready to me. With that item fixed:
Reviewed-by: Josh Triplett
> Doc
On Fri, Jul 31, 2015 at 10:48:32AM +0100, David Drysdale wrote:
> On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett wrote:
> > On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
> >> Add a document describing the process of adding a new system call,
> >> inc
syscalls.h from that.)
If a param struct does the trick, then I agree. It's when you start
having lists and other variable-size stuff that it gets messier.
Sure, agreed. But I really hope we don't create new kernel ABIs that
involve constructs like that.
- Josh Triplett
--
To unsubscribe from
On Fri, Jul 31, 2015 at 10:48:32AM +0100, David Drysdale wrote:
On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
Add a document describing the process of adding a new system call,
including the need
. With that item fixed:
Reviewed-by: Josh Triplett j...@joshtriplett.org
Documentation/adding-syscalls.txt | 531
++
1 file changed, 531 insertions(+)
create mode 100644 Documentation/adding-syscalls.txt
diff --git a/Documentation/adding-syscalls.txt
On Thu, Jul 30, 2015 at 06:02:34PM -0700, Josh Triplett wrote:
> On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
> > On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett
> > wrote:
> > > On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
> > >>
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
> On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett wrote:
> > On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
> >> I like this, it's a good description of both options. I'm still biased
> >> about t
On Thu, Jul 30, 2015 at 06:33:41PM +0200, Sebastian Andrzej Siewior wrote:
> On 07/29/2015 06:41 PM, Josh Triplett wrote:
>
> >> This is correct. However I miss the point of saving the image in the
> >> first place. From what I see is that I have now 272 KiB in memory w
tampered with).
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
> Add a document describing the process of adding a new system call,
> including the need for a flags argument for future compatibility, and
> covering 32-bit/64-bit concerns (albeit in an x86-centric way).
>
> Signed-off-by: David
you don't need param_4, don't use the version
of the structure that has param_4. That also means the kernel doesn't
need to copy and read those values. Either approach works, though.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, Jul 30, 2015 at 08:13:41AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 30, 2015 at 02:49:55PM +0200, Peter Zijlstra wrote:
> > On Fri, Jul 17, 2015 at 04:29:07PM -0700, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney"
> > >
> > > The CONFIG_RCU_CPU_STALL_INFO has been default-y
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
I like this, it's a good description of both options. I'm still biased
about the approach: I
On Thu, Jul 30, 2015 at 06:02:34PM -0700, Josh Triplett wrote:
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett j...@joshtriplett.org
wrote:
On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
I like this, it's a good
with).
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
means the kernel doesn't
need to copy and read those values. Either approach works, though.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 30, 2015 at 08:13:41AM -0700, Paul E. McKenney wrote:
On Thu, Jul 30, 2015 at 02:49:55PM +0200, Peter Zijlstra wrote:
On Fri, Jul 17, 2015 at 04:29:07PM -0700, Paul E. McKenney wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
The CONFIG_RCU_CPU_STALL_INFO has been
On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
Add a document describing the process of adding a new system call,
including the need for a flags argument for future compatibility, and
covering 32-bit/64-bit concerns (albeit in an x86-centric way).
Signed-off-by: David
On Thu, Jul 30, 2015 at 06:33:41PM +0200, Sebastian Andrzej Siewior wrote:
On 07/29/2015 06:41 PM, Josh Triplett wrote:
This is correct. However I miss the point of saving the image in the
first place. From what I see is that I have now 272 KiB in memory which
are never used again
place after a kexec, unless we have some way to know that it's
> > actually valid.
>
> So you assume that the information from ACPI is always correct then?
> The pointer is correct, the information it points to is no longer.
>
> If we run always under EFI then it looks like
on kexec entry. This hint is set via setup_data / SETUP_EFI
since commit 1fec053369 (x86/efi: Pass necessary EFI data for kexec
via setup_data). So maybe we could use this to check if we run under
kexec or not.
That sounds like a sensible fix; don't try to parse the BGRT if
efi_setup.
- Josh Triplett
that
was one of the cases they covered. While that might be possible to
reduce, it doesn't sound like it can go away entirely. :)
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
like it can go away entirely. :)
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sat, Jul 25, 2015 at 02:24:02PM -0700, Davidlohr Bueso wrote:
> On Sat, 2015-07-25 at 12:47 -0700, Josh Triplett wrote:
> > I certainly agree that it doesn't make sense to make all architectures
> > select SRCU, if an unremovable core kernel feature uses SRCU. If
> > poss
in,
though.
Is there any chance at all of the shrinker mechanism becoming optional?
At first glance, it seems reasonably separate from the rest of mm, in
that if it didn't exist and shrinking didn't happen, the rest of mm
still works. If that happened, MM_SHRINKER could select SRCU.
If that's n
On Sat, Jul 25, 2015 at 02:24:02PM -0700, Davidlohr Bueso wrote:
On Sat, 2015-07-25 at 12:47 -0700, Josh Triplett wrote:
I certainly agree that it doesn't make sense to make all architectures
select SRCU, if an unremovable core kernel feature uses SRCU. If
possible, I'd really like
symbol MM_SHRINKER that's always y and does select SRCU, to preserve
SRCU's modularity for the moment while not forcing every architecture to
select it.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
pass non-zero, the pointer must be valid or you
get -EFAULT (or an actual segfault).
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
= 0 if
thread_local_abi = null?
saving a branch doesn't seem like a good reason to do that; however,
it *is* the convention across other calls: if you pass 0, the pointer
is ignored, but if you pass non-zero, the pointer must be valid or you
get -EFAULT (or an actual segfault).
- Josh Triplett
The LKML archives once present at
http://lkml.iu.edu/hypermail/linux/kernel/index.html seem to be down;
http://lkml.iu.edu/hypermail/ appears empty. Does anyone know what
happened to it?
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
The LKML archives once present at
http://lkml.iu.edu/hypermail/linux/kernel/index.html seem to be down;
http://lkml.iu.edu/hypermail/ appears empty. Does anyone know what
happened to it?
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Tue, Jun 30, 2015 at 08:37:01PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 30, 2015 at 05:42:14PM -0700, Josh Triplett wrote:
> > On Tue, Jun 30, 2015 at 05:15:58PM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
&
On Tue, Jun 30, 2015 at 08:37:01PM -0700, Paul E. McKenney wrote:
On Tue, Jun 30, 2015 at 05:42:14PM -0700, Josh Triplett wrote:
On Tue, Jun 30, 2015 at 05:15:58PM -0700, Paul E. McKenney wrote:
On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
On Tue, Jun 30, 2015
en again, perhaps the more relevant concern would be why drivers use
> > expedited grace periods in the first place.
>
> Networking uses expedited grace periods when RTNL is held to reduce
> contention on that lock.
Wait, what? Why is anything using traditional (non-S) RCU while
is held?
Several other places have used it to minimize
user-visible grace-period slowdown. But there are probably places that
would be better served doing something different. That is after all
the common case for most synchronization primitives. ;-)
Sounds likely. :)
- Josh Triplett
btuseness of the error message?
Agreed. Can you reproduce this with a preprocessed file ("make
kernel/rcu/rcutorture.i" first), and then provide that file in a bug
report to GCC?
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
report to GCC?
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Jun 04, 2015 at 12:07:31PM +0200, Denys Vlasenko wrote:
> On 06/03/2015 06:38 PM, Josh Triplett wrote:
> > On Wed, Jun 03, 2015 at 03:58:50PM +0200, Denys Vlasenko wrote:
> >> Really swap arguments #4 and #5 in stub32_clone instead of "optimizing"
> &
On Thu, Jun 04, 2015 at 12:07:31PM +0200, Denys Vlasenko wrote:
On 06/03/2015 06:38 PM, Josh Triplett wrote:
On Wed, Jun 03, 2015 at 03:58:50PM +0200, Denys Vlasenko wrote:
Really swap arguments #4 and #5 in stub32_clone instead of optimizing
it into a move.
Yes, tls_val is currently
le or two on an expensive syscall like
> clone() is way below noise floor, and this optimization is simply not worth
> the obfuscation of logic.
[...]
> This is a resend.
>
> There was a patch by Josh Triplett
> "x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bi
like
clone() is way below noise floor, and this optimization is simply not worth
the obfuscation of logic.
[...]
This is a resend.
There was a patch by Josh Triplett
x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit
sent on May 11,
which does the same thing as part of a bigger
On Mon, May 25, 2015 at 09:29:51PM +, James Bottomley wrote:
> On Mon, 2015-05-25 at 12:29 -0700, Josh Triplett wrote:
> > On Mon, May 25, 2015 at 07:07:14PM +, James Bottomley wrote:
> > > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > > > On M
On Mon, May 25, 2015 at 07:07:14PM +, James Bottomley wrote:
> On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
> > > On Fri, 2015-05-22 at 14:43 -0700, j...@joshtriplett.org wrote:
> > > >
On Mon, May 25, 2015 at 08:25:35PM +0200, Paul Bolle wrote:
> On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > I don't mean cyclic dependencies (for which Kconfig should just report
> > an error, ideally including the full list of symbols forming the cycle).
> >
&g
r than having to look at the list of
dependencies of a symbol, search for that symbol, remember the path the
search showed, and browse there manually.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
On Mon, May 25, 2015 at 08:25:35PM +0200, Paul Bolle wrote:
On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
I don't mean cyclic dependencies (for which Kconfig should just report
an error, ideally including the full list of symbols forming the cycle).
I mean that Kconfig should
On Mon, May 25, 2015 at 07:07:14PM +, James Bottomley wrote:
On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
On Fri, 2015-05-22 at 14:43 -0700, j...@joshtriplett.org wrote:
Ideally, someone should teach Kconfig
of
dependencies of a symbol, search for that symbol, remember the path the
search showed, and browse there manually.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Mon, May 25, 2015 at 09:29:51PM +, James Bottomley wrote:
On Mon, 2015-05-25 at 12:29 -0700, Josh Triplett wrote:
On Mon, May 25, 2015 at 07:07:14PM +, James Bottomley wrote:
On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
On Mon, May 25, 2015 at 12:55:17PM +0200, Paul
ink ideally we should have *every* visible Kconfig option
always pulled in by "depends on" rather than "select", with visibility
and recursion handled by smarter tools. That said, meddle not in the
internals of Kconfig, for it has many unshorn yaks (and yaccs).
- Josh Trip
tools. That said, meddle not in the
internals of Kconfig, for it has many unshorn yaks (and yaccs).
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
getcpu() for "lock; cmpxchg"
> we reach of speedup of 5.4x for load-store+tls-cache vs
> "lock; cmpxchg"+vdso-getcpu.
>
> I'm sending this out to trigger discussion, and hopefully to see
> Paul and Andrew's patches being posted publicly at some point, so
a flags argument.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
d as a short-term workaround until that
change goes into the Debian kernel.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
goes into the Debian kernel.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ubtle data corruptors tend to be highly timing
> depend, and very hard to find. Sometimes these bugs can hang around
> for years before they are found and fixed. The flip side is that
> fortunately, they tend to strike very rarely.
...lucky me.
> It's also why I'm very
> grateful for
. :-)
Indeed.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sun, May 17, 2015 at 07:34:29AM +0200, Ingo Molnar wrote:
>
> * Josh Triplett wrote:
>
> > On Mon, Sep 17, 2001 at 07:00:00AM +, Ingo Molnar wrote:
> > > * Denys Vlasenko wrote:
> > > > > What do you guys think about this? I think we should ser
On Sun, May 17, 2015 at 07:34:29AM +0200, Ingo Molnar wrote:
* Josh Triplett j...@joshtriplett.org wrote:
On Mon, Sep 17, 2001 at 07:00:00AM +, Ingo Molnar wrote:
* Denys Vlasenko dvlas...@redhat.com wrote:
What do you guys think about this? I think we should seriously
sidered including -falign-labels=1 as well? Does that make
a difference on top of the other three.
Finally, it looks like -Os already implies all four of those, as well
as a few others, so unfortunately the code size benefits don't actually
apply to the tiniest kernels, which already eff
like -Os already implies all four of those, as well
as a few others, so unfortunately the code size benefits don't actually
apply to the tiniest kernels, which already effectively incorporate this
change. Oh well.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux
me thing as "if" but for visibility expressions rather than
dependencies. Every symbol in a "showif expr ... endif" block
effectively has "if expr" added to its prompt.
Signed-off-by: Josh Triplett
Acked-by: Paul E. McKenney
---
scripts/kconfig/menu.c
Use the new showif construct to simplify the expert menu. Now, making a
symbol no longer invisible when !EXPERT requires moving it out of the
EXPERT menu, which makes it more difficult to break the EXPERT menu.
Signed-off-by: Josh Triplett
Acked-by: Paul E. McKenney
---
init/Kconfig.expert
Before making changes to the parser, regenerate the parser with current
Bison to avoid mixing those changes with those produced by updating
Bison.
Signed-off-by: Josh Triplett
---
scripts/kconfig/zconf.tab.c_shipped | 1244 ---
1 file changed, 561 insertions
init/Kconfig.expert, to make this harder to do accidentally, and to
break up the exceedingly long init/Kconfig a bit.
Signed-off-by: Josh Triplett
---
init/Kconfig| 232 +---
init/Kconfig.expert | 231
_TRACING
kernels, make it more configurable")
Signed-off-by: Josh Triplett
---
init/Kconfig | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index dc24dec..e2f16f1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1341,6 +13
a patch series that does exactly that, compiling out the syscalls
as well as the underlying architecture-specific infrastructure. (Saves
quite a bit of space, too.)
It still needs some more detailed x86 architecture review. Peter, Ingo?
Would you be interested in taking (an updated version of) tha
On Thu, May 14, 2015 at 12:16:15PM +0200, Ingo Molnar wrote:
>
> * Josh Triplett wrote:
>
> > On Wed, May 13, 2015 at 09:27:57AM -0700, Josh Triplett wrote:
> >
> > > How likely is this to get out of date? Are people going to
> > > remembe
this harder to do accidentally, and to
break up the exceedingly long init/Kconfig a bit.
Signed-off-by: Josh Triplett j...@joshtriplett.org
---
init/Kconfig| 232 +---
init/Kconfig.expert | 231
Use the new showif construct to simplify the expert menu. Now, making a
symbol no longer invisible when !EXPERT requires moving it out of the
EXPERT menu, which makes it more difficult to break the EXPERT menu.
Signed-off-by: Josh Triplett j...@joshtriplett.org
Acked-by: Paul E. McKenney paul
Before making changes to the parser, regenerate the parser with current
Bison to avoid mixing those changes with those produced by updating
Bison.
Signed-off-by: Josh Triplett j...@joshtriplett.org
---
scripts/kconfig/zconf.tab.c_shipped | 1244 ---
1 file changed
... endif block
effectively has if expr added to its prompt.
Signed-off-by: Josh Triplett j...@joshtriplett.org
Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
scripts/kconfig/menu.c | 4 +-
scripts/kconfig/zconf.gperf | 1 +
scripts/kconfig
configurable)
Signed-off-by: Josh Triplett j...@joshtriplett.org
---
init/Kconfig | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index dc24dec..e2f16f1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1341,6 +1341,16 @@ config
On Thu, May 14, 2015 at 12:16:15PM +0200, Ingo Molnar wrote:
* Josh Triplett j...@joshtriplett.org wrote:
On Wed, May 13, 2015 at 09:27:57AM -0700, Josh Triplett wrote:
How likely is this to get out of date? Are people going to
remember to patch this when they add a feature
as well as the underlying architecture-specific infrastructure. (Saves
quite a bit of space, too.)
It still needs some more detailed x86 architecture review. Peter, Ingo?
Would you be interested in taking (an updated version of) that patch
series for the next merge window?
- Josh Triplett
ERT requires moving it out of the
EXPERT menu, which makes it more difficult to break the EXPERT menu.
Signed-off-by: Josh Triplett
---
init/Kconfig.expert | 44 +--
scripts/kconfig/menu.c | 4 +-
scripts/kconfig/zconf.gperf |
501 - 600 of 2693 matches
Mail list logo
