se disabled.
I wonder how easily we could make a kconfig option for an "all except"
or "none except" config? Such an option would read a minimal config
snippet containing only specific options, and then act like
allyesconfig/allmodconfig/allnoconfig as long as doing so doesn't
change anything from the minimal config snippet.
- Josh Triplett
On Tue, Dec 04, 2018 at 02:09:42PM -0800, tip-bot for Paul E. McKenney wrote:
> --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> @@ -39,9 +39,22 @@ mkdir $T
>
> cat > $T/init << '__EOF___'
> #!/bin/sh
> +# Run in userspace a f
On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> > On Tue, Dec 04, 2018 at 02:09:42PM -0800, tip-bot for Paul E. McKenney
> > wrote:
> > > --- a/tools/testing/selftests/rcutorture/bin/mkini
On Wed, Dec 05, 2018 at 04:08:09PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> > On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > > On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> >
to make it
> > easy to see how many instances there are, replacing the earlier wall of
> > 'a' characters.
> >
> > Reported-by: Josh Triplett
> > Signed-off-by: Paul E. McKenney
> >
> > diff --git a/tools/testing/selftests/rc
On August 17, 2018 1:39:35 PM PDT, Andrew Morton
wrote:
>On Fri, 17 Aug 2018 12:10:35 +0200 Rasmus Villemoes
> wrote:
>
>> Appararently, it's possible to have a non-trivial TU include a few
>headers,
>> including linux/build_bug.h, without ending up with linux/types.h. So
>> the 0day bot sent me
On Fri, Dec 14, 2018 at 09:03:11AM -0800, Sean Christopherson wrote:
> On Fri, Dec 14, 2018 at 07:38:30AM -0800, Sean Christopherson wrote:
> > On Fri, Dec 14, 2018 at 07:12:04AM -0800, Sean Christopherson wrote:
> > > On Fri, Dec 14, 2018 at 09:55:49AM +, Jethro Beekman wrote:
> > > > On 2018-
On Sun, Dec 09, 2018 at 09:06:00PM +0100, Pavel Machek wrote:
...
> > > > The default permissions for the device are 600.
> > >
> > > Good. This does not belong to non-root.
> >
> > There are entirely legitimate use cases for using this as an
> > unprivileged user. However, that'll be up to syste
On Mon, Dec 10, 2018 at 09:27:04AM +0100, Pavel Machek wrote:
> On Sun 2018-12-09 23:47:17, Josh Triplett wrote:
> > On Sun, Dec 09, 2018 at 09:06:00PM +0100, Pavel Machek wrote:
> > ...
> > > > > > The default permissions for the device are 600.
> > > &g
On Mon, Dec 10, 2018 at 03:21:37PM -0800, Sean Christopherson wrote:
> At that point I realized it's a hell of a lot easier to simply provide
> an IOCTL via /dev/sgx that allows userspace to register a per-process
> ENCLU exception handler. At a high level, the basic idea is the same
> as the vDSO
On Mon, Oct 08, 2018 at 02:15:25PM -0400, Chris Mason wrote:
> On 6 Oct 2018, at 17:37, James Bottomley wrote:
> > Significant concern has been expressed about the responsibilities
> > outlined in
> > the enforcement clause of the new code of conduct. Since there is
> > concern
> > that this becom
On Mon, Oct 08, 2018 at 04:23:57PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Oct 2018 08:30:20 -0700
> James Bottomley escreveu:
>
> > On Mon, 2018-10-08 at 08:20 -0700, Josh Triplett wrote:
> > > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> > > The current code of conduct has an ambiguity in the it considers
> > &g
On Wed, Oct 10, 2018 at 01:55:04PM -0700, Frank Rowand wrote:
> On 10/07/18 01:51, Geert Uytterhoeven wrote:
> > Providing an explicit list of discrimination factors may give the false
> > impression that discrimination based on other unlisted factors would be
> > allowed.
> >
> > Avoid any ambigu
On Wed, Oct 17, 2018 at 09:19:01AM +0200, Geert Uytterhoeven wrote:
> Providing an explicit list of discrimination factors may give the false
> impression that discrimination based on other unlisted factors would be
> allowed.
This impression is, in fact, false, as has already been discussed
elsew
On Wed, Oct 17, 2018 at 11:31:35AM +0200, Geert Uytterhoeven wrote:
> Hi Josh,
>
> Thanks for your comments!
>
> On Wed, Oct 17, 2018 at 11:13 AM Josh Triplett wrote:
> > On Wed, Oct 17, 2018 at 09:19:01AM +0200, Geert Uytterhoeven wrote:
> > > Providing an e
On Wed, Oct 17, 2018 at 06:32:36AM -0700, Guenter Roeck wrote:
> One could consider adding something like "discrimination factors such as",
> or maybe "or any other discrimination factors not listed here" to the
> original text. Or a simple "regardless of, for example, ...".
These sound like perfe
On Wed, Oct 17, 2018 at 08:49:15AM -0700, James Bottomley wrote:
> On Wed, 2018-10-17 at 08:21 -0700, Josh Triplett wrote:
> > People in underrepresented and commonly marginalized groups,
> > especially those more commonly overlooked, don't always know if a
> > g
On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> Every now and then a project is born, and they decide to use Linux's
> kconfig to enable configuration of their project. As it stands we *know*
> kconfig is now used in at least over 12 different projects [0]. I myself
> added kcon
On Thu, Oct 04, 2018 at 01:39:50PM -0700, Luis Chamberlain wrote:
> On Thu, Oct 04, 2018 at 01:09:00PM -0700, Josh Triplett wrote:
> > On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> > > Every now and then a project is born, and they decide to use Linux&
On Sun, Oct 07, 2018 at 10:51:02AM +0200, Geert Uytterhoeven wrote:
> Providing an explicit list of discrimination factors may give the false
> impression that discrimination based on other unlisted factors would be
> allowed.
>
> Avoid any ambiguity by removing the list, to ensure "a harassment-f
On Sun, Oct 07, 2018 at 08:18:26PM +0300, Laurent Pinchart wrote:
> Hi Josh,
>
> On Sunday, 7 October 2018 14:35:14 EEST Josh Triplett wrote:
> > On Sun, Oct 07, 2018 at 10:51:02AM +0200, Geert Uytterhoeven wrote:
> > > Providing an explicit list of discrimination fa
On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> The current code of conduct has an ambiguity in the it considers publishing
> private information such as email addresses unacceptable behaviour. Since
> the Linux kernel collects and publishes email addresses as part of the patch
On Mon, Oct 08, 2018 at 04:42:47PM +0100, Alan Cox wrote:
> > In any case, this is not the appropriate place for such patches, any
> > more than it's the place for patches to the GPL.
>
> I disagree. We had the GPLv2 or GPLv3 discussion on the kernel mailing
> list. The syscall clarification was d
On Thu, Nov 01, 2018 at 09:45:44AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> > Not when that document started out effectively saying, in an elaborate
> > way, "code > people".
>
> Interesting.
>
> I
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> On Sun, Oct 21 2018, Josh Triplett wrote:
>
> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> I call on you, Greg:
> >> - to abandon this divisive attempt to impose a "
On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
> On Wed, Oct 24 2018, Josh Triplett wrote:
>
> > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> >> On Sun, Oct 21 2018, Josh Triplett wrote:
> >>
> >> > On Mon, Oct 22, 2018 at 08
On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> I call on you, Greg:
> - to abandon this divisive attempt to impose a "Code of Conduct"
> - to revert 8a104f8b5867c68
> - to return to your core competence of building a great team around
>a great kernel
>
> #Isupportreversion
>
On Mon, Oct 22, 2018 at 09:16:20PM -0700, Joe Perches wrote:
> On Mon, 2018-10-22 at 22:10 +0100, Greg Kroah-Hartman wrote:
> > On Sat, Oct 20, 2018 at 01:15:14PM -0700, James Bottomley wrote:
> > > This is the series of patches which has been discussed on both ksummit-
> > > discuss and linux-kern
mation script
test-suite documentation
Sample test-suite test cases
Dan Sheridan (2):
Improved graph generation using subgraph clusters for functions
Add gvpr-based post-processing for graphs
Josh Triplett (118):
Fix website and reposito
chine.
> > +*/
>
> I don't think we want to try to struggle along like that. This thread is a
> piece of core infrastructure: if we couldn't start it then just panic
> rather than trying to run the kernel in unknown and untested regions of
> operation.
In th
clarify kvmconfig is for kvm
> x86, arm, platform, xen, kconfig: add xen defconfig helper
For both:
Reviewed-by: Josh Triplett
> arch/x86/configs/xen.config | 6 ++
> kernel/configs/xen.config | 32
> scripts/kconfig/Makefile| 7 ++-
>
On Tue, Dec 09, 2014 at 03:35:37PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> We'll be adding options for xen as well.
>
> Cc: Josh Triplett
> Cc: Borislav Petkov
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Michal Marek
&g
+linux-sparse
On Fri, Jan 02, 2015 at 09:51:25AM -0500, Murali Karicheri wrote:
> On 12/16/2014 01:23 PM, Murali Karicheri wrote:
> >netdev maintainers,
> >
> >I got a comment to address CHECK warning and wondering how to address
> >'warning: testing a 'safe expression' which appears when using
>
obvious patch
combined with a few selects.
The code looks good to me. Assuming it compiles on x86, with tinyconfig
and with allyesconfig minus SRCU (and whatever requires it), this seems
reasonable.
Thanks for working on this!
- Josh Triplett
> v2:
> - handle cpufreq, devfreq and notifier
se for testing purposes, but I don't think it makes sense
for the final patch. I'd suggest making it a completely automatic
symbol with no title.
> >
> >>> +def_bool n
You already say "bool" above, and "default n" is the default default, so
yo
erfd_settime;
even if it only accepts CLOCK_REALTIME and CLOCK_MONOTONIC, if it needs
extending in the future, it'd be painful to have to remap new CLOCK_*
constants into the EPOLL_FL_* namespace. (I do think dropping timeouts
in favor of timerfds makes things more nicely orthogonal, but epoll_wa
change / fix anything.
Easy enough to get it back out of version control if so.
- 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 Mon, Jan 12, 2015 at 04:24:00PM +0800, Fam Zheng wrote:
> On Thu, 01/08 21:21, Josh Triplett wrote:
> > On Fri, Jan 09, 2015 at 12:49:08PM +0800, Fam Zheng wrote:
> > > On Thu, 01/08 18:24, Andy Lutomirski wrote:
> > > > On Thu, Jan 8, 2015 at 5:52 PM, Fam Zheng
On Sat, Mar 21, 2015 at 01:00:13PM -0400, Sanidhya Kashyap wrote:
> Checking for ENOMEM even for new_opts in reiserfs_remount function as
> there is a possibility of nothing being allocated.
You don't need to add a new label; kfree(NULL) is a no-op.
> Signed-off-by: Sanidhya Kashyap
> ---
> fs/
On Sun, Mar 22, 2015 at 08:12:46PM -0400, Sanidhya Kashyap wrote:
> On Sat, Mar 21, 2015 at 1:15 PM, Josh Triplett wrote:
> > On Sat, Mar 21, 2015 at 01:00:13PM -0400, Sanidhya Kashyap wrote:
> >> Checking for ENOMEM even for new_opts in reiserfs_remount function as
> >>
On Mon, Apr 06, 2015 at 05:30:35PM +0900, Sergey Senozhatsky wrote:
> On (03/15/15 01:00), Josh Triplett wrote:
> [..]
> > +
> > +/* Handle the CLONE_FD case for copy_process. */
> > +int clonefd_do_clone(u64 clone_flags, struct task_struct *p,
> > +st
ersial
and have acks. I'd like to go ahead and submit these two so that other
architectures can begin building on top of this and opting into
HAVE_COPY_THREAD_TLS. However, I'm also happy to wait and send these through
the next merge window (along with v3 of clone4) if anyone would
re the C argument to sys_clone in favor of the pt_regs captured at
kernel entry, and thus will be unable to introduce new versions of the
clone syscall.
Signed-off-by: Josh Triplett
Signed-off-by: Thiago Macieira
Acked-by: Andy Lutomirski
---
arch/Kconfig | 7 ++
include/l
For 32-bit userspace on a 64-bit kernel, this requires modifying
stub32_clone to actually swap the appropriate arguments to match
CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for tls
broken.
Signed-off-by: Josh Triplett
Signed-off-by: Thiago Macieira
Acked-by: Andy Lutomirski
atch adding your comment on top
of the two-patch series I just sent?
Thanks,
Josh Triplett
> --Andy
>
> >
> > Signed-off-by: Denys Vlasenko
> > CC: Linus Torvalds
> > CC: Steven Rostedt
> > CC: Ingo Molnar
> > CC: Borislav Petkov
> > CC: "H. Pe
On Wed, Apr 22, 2015 at 11:22:02AM -0700, Linus Torvalds wrote:
> On Wed, Apr 22, 2015 at 10:10 AM, Josh Triplett wrote:
> >
> > I do think my two-patch HAVE_COPY_THREAD_TLS series should go in fixing
> > this
>
> Ugh, I absolutely detesrt that patch.
>
>
On Thu, Apr 23, 2015 at 08:24:38AM +0200, Ingo Molnar wrote:
> * Josh Triplett wrote:
> > On Wed, Apr 22, 2015 at 11:22:02AM -0700, Linus Torvalds wrote:
> > > On Wed, Apr 22, 2015 at 10:10 AM, Josh Triplett
> > > wrote:
> > > >
> > > > I do th
hen include any necessary
disambiguating flags/IDs/etc. No need for them to match the current
clonefd_info structure if userspace has opted into a new version.
- 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/
the 16 byte jump target optimization suggestion
> > really worth this price? The patch below boots fine and I've not
> > measured any noticeable slowdown, but I've not tried hard.
>
> Good point, adding Josh Triplett on CC. I suspect that he might be
> interested.
the obtuseness 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
t
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-bit&q
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 Wed, Feb 28, 2018 at 01:32:37AM +, Luis R. Rodriguez wrote:
> On Tue, Feb 27, 2018 at 03:18:15PM -0800, Kees Cook wrote:
> > On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez
> > wrote:
> > > Since we now have knobs to twiddle what used to be set on kernel
> > > configurations we can buil
On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote:
> On Wed, Feb 28, 2018 at 01:07:23AM -0800, Josh Triplett wrote:
> > On Wed, Feb 28, 2018 at 01:32:37AM +, Luis R. Rodriguez wrote:
> > > On Tue, Feb 27, 2018 at 03:18:15PM -0800, Kees Cook wrote:
> >
On Thu, Mar 01, 2018 at 12:38:16AM +, Luis R. Rodriguez wrote:
> On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote:
> > On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote:
> > > So for folks who enable CONFIG_FW_LOADER=y, they'd now be f
On Mon, Apr 30, 2018 at 02:31:30PM +1000, NeilBrown wrote:
> list_for_each_entry_from_rcu() is an RCU version of
> list_for_each_entry_from(). It walks a linked list under rcu
> protection, from a given start point.
>
> It is similar to list_for_each_entry_continue_rcu() but starts *at*
> the giv
On Tue, May 15, 2018 at 07:11:08AM -0700, Nadav Amit wrote:
> GCC considers the number of statements in inlined assembly blocks,
> according to new-lines and semicolons, as an indication to the cost of
> the block in time and space. This data is distorted by the kernel code,
> which puts informatio
On Tue, May 15, 2018 at 02:53:52PM -0700, Nadav Amit wrote:
> Josh Triplett wrote:
>
> > On Tue, May 15, 2018 at 07:11:08AM -0700, Nadav Amit wrote:
> >> GCC considers the number of statements in inlined assembly blocks,
> >> according to new-lines and semicolons, a
On April 10, 2019 3:58:55 PM PDT, Kees Cook wrote:
>On Wed, Apr 10, 2019 at 3:42 PM Sinan Kaya wrote:
>>
>> We can't seem to have a kernel with CONFIG_EXPERT set but
>> CONFIG_DEBUG_KERNEL unset these days.
>>
>> While some of the features under the CONFIG_EXPERT require
>> CONFIG_DEBUG_KERNEL, i
On April 10, 2019 4:24:18 PM PDT, Kees Cook wrote:
>On Wed, Apr 10, 2019 at 4:22 PM Josh Triplett
>wrote:
>>
>> On April 10, 2019 3:58:55 PM PDT, Kees Cook
>wrote:
>> >On Wed, Apr 10, 2019 at 3:42 PM Sinan Kaya wrote:
>> >>
>> >> We
On Wed, May 20, 2020 at 02:26:38PM -0400, Daniel Jordan wrote:
> Please review and test, and thanks to Alex, Andrew, Josh, and Pavel for
> their feedback in the last version.
I re-tested v2:
Tested-by: Josh Triplett
[0.231435] node 1 initialised, 24189223 pages in 32ms
[0.236718
ss to return
EWOULDBLOCK?
This would make it easier to use pidfd in some non-blocking event loops.
- Josh Triplett
On Tue, Aug 11, 2020 at 10:10:45PM +0200, Christian Brauner wrote:
> On Tue, Aug 11, 2020 at 11:12:36AM -0700, Josh Triplett wrote:
> > As far as I can tell, O_NONBLOCK has no effect on a pidfd. When calling
> > waitid on a pidfd for a running process, it always blocks unless
On July 31, 2020 11:53:08 PM PDT, Christoph Hellwig wrote:
>[note: private reply now to start a flame fest with the usual suspects]
[You still CCed LKML.]
>On Fri, Jul 31, 2020 at 01:11:46PM -0700, j...@joshtriplett.org wrote:
>> Christoph Hellwig wrote:
>> > we've had a bug in our resolution of
uld be nice for this, but they're hard to share reliably;
the above mechanism to accumulate entries from a file in the repo seems
simpler. I can imagine other possibilities.)
Does something like this seem potentially reasonable, and worth doing to
help people avoid future catastrophic data loss?
- Josh Triplett
On Fri, Mar 05, 2021 at 10:10:05AM -0800, Junio C Hamano wrote:
> Christian Couder writes:
>
> >> (git notes would be nice for this, but they're hard to share reliably;
> >> the above mechanism to accumulate entries from a file in the repo seems
> >> simpler. I can imagine other possibilities.)
>
On Fri, Apr 16, 2021 at 12:27:39PM +0800, Boqun Feng wrote:
> Josh, I think it's good if we can connect to the people working on Rust
> memoryg model, I think the right person is Ralf Jung and the right place
> is https://github.com/rust-lang/unsafe-code-guidelines, but you
> cerntainly know better
On Wed, Apr 14, 2021 at 01:21:52PM -0700, Linus Torvalds wrote:
> On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote:
> >
> > There's a philosophical point to be discussed here which you're skating
> > right over! Should rust-in-the-linux-kernel provide the same memory
> > allocation APIs as th
The creation path of the NBD device respects max_part and only scans for
partitions if max_part is not 0. However, some other code paths ignore
max_part, and unconditionally scan for partitions. Add a check for
max_part on each partition scan.
Signed-off-by: Josh Triplett
---
Caught this when
593 --593
Signed-off-by: Josh Triplett
---
arch/x86/kernel/cpu/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 7fd54f0..64038d8 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b
: Josh Triplett
---
arch/x86/Kconfig | 12 +++
arch/x86/boot/Makefile| 5 ++-
arch/x86/boot/cpu.c | 68 +++
arch/x86/include/asm/cpufeature.h | 13
arch/x86/kernel/cpu/Makefile | 5 ++-
arch/x86/kernel
itional on CONFIG_BUG, and map them all to the passthrough WARN_ON
when !CONFIG_BUG.
This saves 4.4k on a minimized configuration (smaller than
allnoconfig), and 20.6k with defconfig plus CONFIG_BUG=n.
Signed-off-by: Josh Triplett
---
diff's presentation here is not the easiest for reviewing purpos
d things, just don't include them if
> not needed.
Fixed in v2.
- 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.h
cro generating two printk arguments. Doing so in v2;
hope that isn't too ugly...
- 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-inf
593 --593
Signed-off-by: Josh Triplett
---
v2: no changes to patch 1.
arch/x86/kernel/cpu/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 7fd54f0..64038d8 100644
--- a/arch
: Josh Triplett
---
v2: Incorporate feedback from H. Peter Anvin:
- Remove unnecessary ifdefs.
- Print numeric feature flags in word:bit form.
arch/x86/Kconfig | 12 +++
arch/x86/boot/cpu.c | 68 +++
arch/x86/include/asm
s.
Signed-off-by: Josh Triplett
Acked-by: Borislav Petkov
---
Documentation/SubmittingPatches | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c74e73c..53e6590 100644
--- a/Documentation/Submitt
escription from git's SubmittingPatches.
Signed-off-by: Josh Triplett
Acked-by: Borislav Petkov
---
Documentation/SubmittingPatches | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 26b1e31..c74e73c 100644
---
Most of the mechanical portions of SubmittingPatches exist to help patch
submitters replicate the output of git. Mention this explicitly, both
as a reminder that git will help with this process, and as signposting to
let git users know what they can safely skip.
Signed-off-by: Josh Triplett
On Sat, Feb 22, 2014 at 09:49:36PM +0100, Borislav Petkov wrote:
> On Sat, Feb 22, 2014 at 11:57:10AM -0800, Josh Triplett wrote:
> > diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
> > index 6ec6bb6..29207f6 100644
> > --- a/arch/x86/boot/cpu.c
> > +++ b/arch/
593 --593
Signed-off-by: Josh Triplett
---
v2,v3: no changes from v1 for this patch
arch/x86/kernel/cpu/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 7fd54f0..64038d8 100644
: Josh Triplett
---
v3: Fix build issue for clean builds, introduced in v2.
v2: Incorporate feedback from H. Peter Anvin:
- Remove unnecessary ifdefs.
- Print numeric feature flags in word:bit form.
arch/x86/Kconfig | 12 +++
arch/x86/boot/Makefile| 7
On Sat, Feb 22, 2014 at 01:18:14PM -0800, H. Peter Anvin wrote:
> On February 22, 2014 1:00:39 PM PST, Josh Triplett
> wrote:
> >On Sat, Feb 22, 2014 at 09:49:36PM +0100, Borislav Petkov wrote:
> >> On Sat, Feb 22, 2014 at 11:57:10AM -0800, Josh Triplett wrote:
> >>
On Sat, Feb 22, 2014 at 01:56:54PM -0800, Randy Dunlap wrote:
> On 02/22/2014 12:12 PM, Josh Triplett wrote:
> > SubmittingPatches already mentions referencing bugs fixed by a commit,
> > but doesn't mention citing relevant mailing list discussions. Add a
> > note to
On Sat, Feb 22, 2014 at 01:54:49PM -0800, Randy Dunlap wrote:
> On 02/22/2014 11:23 AM, Josh Triplett wrote:
>
> Hi Josh,
>
> If you redo these patches, please make while(0) not look like a
> function call, i.e., use while (0) instead.
Good catch. Fixing in v2.
- J
On Sat, Feb 22, 2014 at 02:31:20PM -0800, Josh Triplett wrote:
> On Sat, Feb 22, 2014 at 01:54:49PM -0800, Randy Dunlap wrote:
> > On 02/22/2014 11:23 AM, Josh Triplett wrote:
> >
> > Hi Josh,
> >
> > If you redo these patches, please make while(0) not look li
On Sun, Feb 23, 2014 at 09:56:56AM -0800, H. Peter Anvin wrote:
> On 02/22/2014 01:36 PM, Josh Triplett wrote:
> >
> > No, even after removing the ifdefs around the build rules as you
> > suggested (and v3's fixes for the resulting build issues, notably
On Sun, Feb 23, 2014 at 01:44:20PM -0800, H. Peter Anvin wrote:
> On 02/23/2014 01:32 PM, Josh Triplett wrote:
> >
> > Because, in order to un-break the build, v3 wraps an ifdef around that
> > dependency, to prevent building cpustr.h. Otherwise, the rule for
> >
t;allnoconfig_y", used on
symbols which only exist to hide other symbols. Set it on
CONFIG_EMBEDDED (which then selects CONFIG_EXPERT). allnoconfig will
then disable all the symbols hidden behind those.
Signed-off-by: Josh Triplett
---
Documentation/kbuild/kconfig-langua
On Mon, Feb 24, 2014 at 09:02:35AM +0100, Arnd Bergmann wrote:
> On Saturday 22 February 2014, Josh Triplett wrote:
> > When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
> > condition argument; however, WARN_ON_ONCE and family still have
> > condit
On Mon, Feb 24, 2014 at 03:17:58PM -0800, Andrew Morton wrote:
> On Mon, 24 Feb 2014 09:02:35 +0100 Arnd Bergmann wrote:
>
> > On Saturday 22 February 2014, Josh Triplett wrote:
> > > When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
> > &g
On Tue, Feb 25, 2014 at 01:09:25PM -0800, Andrew Morton wrote:
> On Sun, 23 Feb 2014 18:20:26 -0800 Josh Triplett
> wrote:
> > "make allnoconfig" exists to ease testing of minimal configurations.
> > Documentation/SubmitChecklist includes a note to test with allno
itional on CONFIG_BUG, and add definitions for !CONFIG_BUG that map
to the passthrough versions of WARN and WARN_ON.
This saves 4.4k on a minimized configuration (smaller than
allnoconfig), and 20.6k with defconfig plus CONFIG_BUG=n.
Signed-off-by: Josh Triplett
---
v2: Incorporate feedback from Arnd Berg
Reported-by: Randy Dunlap
Signed-off-by: Josh Triplett
---
include/asm-generic/bug.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7ecd398..2d54d8d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm
summary:
add/remove: 2/7 grow/shrink: 34/57 up/down: 475/-1233 (-758)
Signed-off-by: Josh Triplett
---
include/asm-generic/bug.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 653c44a..5f69248 100644
--- a/include
include/asm-generic/bug.h defines BUG_ON to call BUG() if CONFIG_BUG=y,
or as a no-op if !CONFIG_BUG. However, BUG() is already a no-op if
!CONFIG_BUG, making this pointless. Use a common definition that always
calls BUG().
This does not change the compiled code at all.
Signed-off-by: Josh
The stub version of WARN for !CONFIG_BUG completely ignored its format
string and subsequent arguments; make it check them instead, using
no_printk.
Reported-by: Arnd Bergmann
Signed-off-by: Josh Triplett
---
include/asm-generic/bug.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include
with just "make allnoconfig" rather
than manually turning off other options (like PRINTK) that select
IRQ_WORK. (One of the goals of that commit: get those options more
widely used and build-tested.)
The following (untested) patch *should* fix this:
- 8< -
>From 36a5b6c8729
arch/ia64/kernel/unaligned.c uses tty_write_message to print an
unaligned access exception to the TTY of the current user process.
Enable TTY to prevent a build error.
Signed-off-by: Josh Triplett
---
Not tested, but this *should* fix the build error with CONFIG_TTY=n.
Minimal fix, on the basis
501 - 600 of 1376 matches
Mail list logo
