On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote:
I'm not sure if coexistence of .ctors and .init_array sections should result
in
denial of module, but I for sure know nothing about this :). Could you maybe
privide one example of the weird thing?
They shouldn't exist unless
On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
> > > v2: - reuse mod->ctors for .init_array section for modules, because gcc
> > > uses
> > > .ctors or .init_array, but not both at the same time
> > >
> > > Signed-off-by: Frantisek Hrbata
> >
> > Might be nice to
On Fri, Sep 06, 2013 at 10:24:13AM -0400, Steven Rostedt wrote:
>
> Is it really safe to load modules that were compiled with different
> options?
Certainly not, offsets can change based on config options.
> Sounds like a failure in the install scripts to me.
>
Definitely a bug in those
Commit-ID: 41817815666e4a6f302dad1fea47cbe64cc45e40
Gitweb: http://git.kernel.org/tip/41817815666e4a6f302dad1fea47cbe64cc45e40
Author: Kyle McMartin
AuthorDate: Thu, 5 Sep 2013 10:29:47 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 5 Sep 2013 16:18:46 -0300
perf trace
Commit-ID: 41817815666e4a6f302dad1fea47cbe64cc45e40
Gitweb: http://git.kernel.org/tip/41817815666e4a6f302dad1fea47cbe64cc45e40
Author: Kyle McMartin k...@redhat.com
AuthorDate: Thu, 5 Sep 2013 10:29:47 -0400
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Thu, 5 Sep 2013
On Fri, Sep 06, 2013 at 10:24:13AM -0400, Steven Rostedt wrote:
Is it really safe to load modules that were compiled with different
options?
Certainly not, offsets can change based on config options.
Sounds like a failure in the install scripts to me.
Definitely a bug in those scripts,
On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
v2: - reuse mod-ctors for .init_array section for modules, because gcc
uses
.ctors or .init_array, but not both at the same time
Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
Might be nice to document
On Thu, Sep 05, 2013 at 09:01:59AM -0700, James Bottomley wrote:
> > +EXPORT_SYMBOL_GPL(flush_cache_page);
>
> This is an internal API: no architecture exports this. Whoever is
> trying to use it needs to use the correct API, so this is the wrong
> patch.
>
I suspect it's
From: Kyle McMartin
MAP_32BIT is defined only on x86... this means perf fails to build on
all other platforms.
Signed-off-by: Kyle McMartin
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -100,7 +100,9 @@ static size_t syscall_arg__scnprintf_mmap_flags(char *bf,
size_t
From: Kyle McMartin k...@redhat.com
MAP_32BIT is defined only on x86... this means perf fails to build on
all other platforms.
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -100,7 +100,9 @@ static size_t
On Thu, Sep 05, 2013 at 09:01:59AM -0700, James Bottomley wrote:
+EXPORT_SYMBOL_GPL(flush_cache_page);
This is an internal API: no architecture exports this. Whoever is
trying to use it needs to use the correct API, so this is the wrong
patch.
I suspect it's copy_{to,from}_user_page
Provide a vdso_install target in the arm64 Makefile, as other architectures
with a vdso do.
Signed-off-by: Kyle McMartin
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -60,6 +60,10 @@ zinstall install: vmlinux
dtbs: scripts
$(Q)$(MAKE) $(build)=$(boot)/dts dtbs
+PHONY
Provide a vdso_install target in the arm64 Makefile, as other architectures
with a vdso do.
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -60,6 +60,10 @@ zinstall install: vmlinux
dtbs: scripts
$(Q)$(MAKE) $(build)=$(boot)/dts dtbs
On Thu, Jun 06, 2013 at 07:41:57PM +0200, Michal Marek wrote:
> Dne 6.6.2013 19:05, Kyle McMartin napsal(a):
> > While using make V=1 to test some things, I noticed on our builders that
> > headers_install was failing because the argument list to /bin/sh was too
> >
/sh: Argument list too long
make[2]: ***
[/home/kyle/A(lots of times)/linux/usr/include/linux/.install]
Error 127
make[1]: *** [linux] Error 2
make: *** [headers_install] Error 2
Signed-off-by: Kyle McMartin
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -59,6 +59,8
/sh: Argument list too long
make[2]: ***
[/home/kyle/A(lots of times)/linux/usr/include/linux/.install]
Error 127
make[1]: *** [linux] Error 2
make: *** [headers_install] Error 2
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
On Thu, Jun 06, 2013 at 07:41:57PM +0200, Michal Marek wrote:
Dne 6.6.2013 19:05, Kyle McMartin napsal(a):
While using make V=1 to test some things, I noticed on our builders that
headers_install was failing because the argument list to /bin/sh was too
long. Working around it is slightly
On Mon, Jun 03, 2013 at 09:55:31AM -0700, Greg KH wrote:
> On Mon, Jun 03, 2013 at 09:38:26AM -0400, Kyle McMartin wrote:
> > This reverts commit cfcec52e9781f08948c6eb98198d65c45be75a70.
> >
> > This regresses a longstanding behaviour on X86 systems, which end up with
> &
in order to bisect across it.
Please revert, we can work on solving this for ARM platforms in a less
disruptive way.
Signed-off-by: Kyle McMartin
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2755,7 +2755,7 @@ static void __init serial8250_isa_init_ports
in order to bisect across it.
Please revert, we can work on solving this for ARM platforms in a less
disruptive way.
Signed-off-by: Kyle McMartin k...@mcmartin.ca
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2755,7 +2755,7 @@ static void __init
On Mon, Jun 03, 2013 at 09:55:31AM -0700, Greg KH wrote:
On Mon, Jun 03, 2013 at 09:38:26AM -0400, Kyle McMartin wrote:
This reverts commit cfcec52e9781f08948c6eb98198d65c45be75a70.
This regresses a longstanding behaviour on X86 systems, which end up with
PCI serial ports moving between
lo,
initialized to zero, and length checked in the bootloader. It's also
only 256+4 bytes compared to the 1024 bytes set aside for
boot_command_line.
That said, it's harmless to use strlcpy here, and obviously (more)
correct. Thanks!
Acked-by: Kyle McMartin
--
To unsubscribe from this list
to zero, and length checked in the bootloader. It's also
only 256+4 bytes compared to the 1024 bytes set aside for
boot_command_line.
That said, it's harmless to use strlcpy here, and obviously (more)
correct. Thanks!
Acked-by: Kyle McMartin k...@mcmartin.ca
--
To unsubscribe from this list: send
check_unmap+0x407/0x8a0()
Signed-off-by: Kyle McMartin
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -832,7 +832,17 @@ int ioat_dma_self_test(struct ioatdma_device *device)
}
dma_src = dma_map_single(dev, src, IOAT_TEST_SIZE, DMA_TO_DEVICE
kcore_vmalloc is in fs/proc/kcore.c and kcore_mem is unused across
the tree. Noticed while grepping the tree for some other kcore stuff.
(score looks pretty unmaintained to me.)
Signed-off-by: Kyle McMartin
--- a/arch/score/mm/init.c
+++ b/arch/score/mm/init.c
@@ -41,8 +41,6 @@
unsigned long
kcore_vmalloc is in fs/proc/kcore.c and kcore_mem is unused across
the tree. Noticed while grepping the tree for some other kcore stuff.
(score looks pretty unmaintained to me.)
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/arch/score/mm/init.c
+++ b/arch/score/mm/init.c
@@ -41,8 +41,6
check_unmap+0x407/0x8a0()
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -832,7 +832,17 @@ int ioat_dma_self_test(struct ioatdma_device *device)
}
dma_src = dma_map_single(dev, src, IOAT_TEST_SIZE, DMA_TO_DEVICE
htmldocs will fail, because device-drivers.tmpl references the
non-existant file 8250.c (which got renamed to 8250_core.c)
Signed-off-by: Kyle McMartin
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
htmldocs will fail, because device-drivers.tmpl references the
non-existant file 8250.c (which got renamed to 8250_core.c)
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -227,7 +227,7 @@ X!Isound
On Wed, Mar 27, 2013 at 11:03:26AM -0400, Josh Boyer wrote:
> On Mon, Mar 18, 2013 at 5:32 PM, Matthew Garrett
> wrote:
> > Any hardware that can potentially generate DMA has to be locked down from
> > userspace in order to avoid it being possible for an attacker to cause
> > arbitrary kernel
On Wed, Mar 27, 2013 at 11:03:26AM -0400, Josh Boyer wrote:
On Mon, Mar 18, 2013 at 5:32 PM, Matthew Garrett
matthew.garr...@nebula.com wrote:
Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to cause
On Wed, Feb 06, 2013 at 06:45:45PM +0100, Stephan Mueller wrote:
> Unfortunately there has already something terrible happened: an
> additional piece of code loaded into the FIPS 140-2 module could not be
> loaded because a self test failed. This is a terrible accident in FIPS
> 140-2 speak. :-)
>
On Wed, Feb 06, 2013 at 09:02:46AM +0100, Stephan Mueller wrote:
> On 05.02.2013 23:58:30, +0100, Kyle McMartin wrote:
>
> Hi Kyle,
>
Thanks for the review, Stephan.
> Just reading this paragraph, there is one missing puzzle piece: the
> *entire* kernel crypto API must shut
On Wed, Feb 06, 2013 at 09:02:46AM +0100, Stephan Mueller wrote:
On 05.02.2013 23:58:30, +0100, Kyle McMartin k...@redhat.com wrote:
Hi Kyle,
Thanks for the review, Stephan.
Just reading this paragraph, there is one missing puzzle piece: the
*entire* kernel crypto API must shut down
On Wed, Feb 06, 2013 at 06:45:45PM +0100, Stephan Mueller wrote:
Unfortunately there has already something terrible happened: an
additional piece of code loaded into the FIPS 140-2 module could not be
loaded because a self test failed. This is a terrible accident in FIPS
140-2 speak. :-)
of the other cases.
Checking in crypto_check_alg and crypto_register_template seems to hit
the callpoints as far as I can see.
Signed-off-by: Kyle McMartin
---
rusty,
How about something like this? It keeps the FIPS mess in the
crypto/fips.c file (aside from something that goes away entirely
of the other cases.
Checking in crypto_check_alg and crypto_register_template seems to hit
the callpoints as far as I can see.
Signed-off-by: Kyle McMartin k...@redhat.com
---
rusty,
How about something like this? It keeps the FIPS mess in the
crypto/fips.c file (aside from something that goes away
On Fri, Jan 25, 2013 at 10:06:01AM +1030, Rusty Russell wrote:
> Kyle McMartin writes:
> > After thinking about it a while, this seems like the best way to solve
> > the problem, although it does still kind of offend my delicate
> > sensibilities...
>
> You're
CONFIG_EXPERT doesn't really make sense, and hides it unintentionally.
Remove superfluous "default n" pointed out by Ingo as well.
Signed-off-by: Kyle McMartin
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -243,8 +243,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
On Thu, Jan 24, 2013 at 02:06:10PM -0500, Kyle McMartin wrote:
> + if (err < 0 && fips_enabled && !get_modinfo(info, "crypto_fips"))
Sigh, that should be get_modinfo(...)
if (err < 0 && fips_enabled && get_modinfo(info, "cry
...
Seems to build and work with both values of CONFIG_CRYPTO_FIPS.
Thoughts?
Signed-off-by: Kyle McMartin
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2459,8 +2459,10 @@ static int module_sig_check(struct load_info *info)
return 0;
}
- /* Not having
On Wed, Jan 23, 2013 at 04:18:32PM +0100, Stephan Mueller wrote:
> 3. in the cipher initialization code of the crypto API (i.e. the one
> behind crypto_register_alg()), you check the signature check flag --
> panic the kernel when the flag shows that the signature check failed
>
> This way you
On Wed, Jan 23, 2013 at 04:18:32PM +0100, Stephan Mueller wrote:
3. in the cipher initialization code of the crypto API (i.e. the one
behind crypto_register_alg()), you check the signature check flag --
panic the kernel when the flag shows that the signature check failed
This way you limit
...
Seems to build and work with both values of CONFIG_CRYPTO_FIPS.
Thoughts?
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2459,8 +2459,10 @@ static int module_sig_check(struct load_info *info)
return 0
On Thu, Jan 24, 2013 at 02:06:10PM -0500, Kyle McMartin wrote:
+ if (err 0 fips_enabled !get_modinfo(info, crypto_fips))
Sigh, that should be get_modinfo(...)
if (err 0 fips_enabled get_modinfo(info, crypto_fips))
Thinko when converting from flagging things as nocrypto
CONFIG_EXPERT doesn't really make sense, and hides it unintentionally.
Remove superfluous default n pointed out by Ingo as well.
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -243,8 +243,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
On Fri, Jan 25, 2013 at 10:06:01AM +1030, Rusty Russell wrote:
Kyle McMartin k...@redhat.com writes:
After thinking about it a while, this seems like the best way to solve
the problem, although it does still kind of offend my delicate
sensibilities...
You're far too polite. This patch
CONFIG_EXPERT is a bit silly a place for this, and hides it
unnecessarily. CONFIG_DEBUG_KERNEL makes much more sense.
Signed-off-by: Kyle McMartin
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -243,7 +243,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
default 1
s mode. (This also
matches the behaviour by Red Hat Enterprise Linux 6.)
Things which need to deny module loading such as secure boot already set
sig_enforce, so there's no issue here.
Reported-by: Jan Stancek
Signed-off-by: Kyle McMartin
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2460,11 +246
the behaviour by Red Hat Enterprise Linux 6.)
Things which need to deny module loading such as secure boot already set
sig_enforce, so there's no issue here.
Reported-by: Jan Stancek jstan...@redhat.com
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/kernel/module.c
+++ b/kernel/module.c
CONFIG_EXPERT is a bit silly a place for this, and hides it
unnecessarily. CONFIG_DEBUG_KERNEL makes much more sense.
Signed-off-by: Kyle McMartin k...@redhat.com
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -243,7 +243,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
default 1
On Tue, Nov 27, 2012 at 12:16:31PM +, Mark Rutland wrote:
> Signed-off-by: Mark Rutland
> Cc: Arnaldo Carvalho de Melo
> Cc: David Howells
> Cc: Deng-Cheng Zhu
> Cc: Ingo Molnar
> Cc: Kyle McMartin
Looks obviously right.
Acked-by: Kyle McMartin
> Cc: Martin Sc
McMartin k...@mcmartin.ca
Looks obviously right.
Acked-by: Kyle McMartin k...@mcmartin.ca
Cc: Martin Schwidefsky schwidef...@de.ibm.com
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Tony Luck tony.l...@intel.com
Cc: Will Deacon will.dea...@arm.com
On Wed, Feb 20, 2008 at 02:25:02PM -0800, [EMAIL PROTECTED] wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> Subject: PCI: remove parisc consumer of the pci global_list
>
Thanks for finding this, both of you. Probably saves me some heartaches
for
lguest uses asm-offsets to generate ... offsets, obviously, for use
in the lguest switcher code. When the hypervisor code is built as a
module though, the asm offsets it needs won't be generated since
CONFIG_LGUEST will be undefined.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
--
lguest uses asm-offsets to generate ... offsets, obviously, for use
in the lguest switcher code. When the hypervisor code is built as a
module though, the asm offsets it needs won't be generated since
CONFIG_LGUEST will be undefined.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
diff --git
On Wed, Feb 20, 2008 at 02:25:02PM -0800, [EMAIL PROTECTED] wrote:
This is a note to let you know that I've just added the patch titled
Subject: PCI: remove parisc consumer of the pci global_list
Thanks for finding this, both of you. Probably saves me some heartaches
for 2.6.26-rc1.
On Mon, Feb 18, 2008 at 11:32:58AM +0100, rubisher wrote:
> > On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
> > >
> >
> > Can I get your Signed-off-by for this, Joel? (I assume you are Joel :)
> >
> Yes the previous account seems to be a bit old and look more and more like a
> gc; I
On Mon, Feb 18, 2008 at 11:32:58AM +0100, rubisher wrote:
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
Can I get your Signed-off-by for this, Joel? (I assume you are Joel :)
Yes the previous account seems to be a bit old and look more and more like a
gc; I so take the
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
>
Can I get your Signed-off-by for this, Joel? (I assume you are Joel :)
cheers, Kyle
> - some lake of changes of kset to kobj:
> --- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
> +
> +++
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
Can I get your Signed-off-by for this, Joel? (I assume you are Joel :)
cheers, Kyle
- some lake of changes of kset to kobj:
--- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
+
+++
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
> - some lake of changes of kset to kobj:
thanks, i don't build this driver, somehow it made its way out of my
configs. patch looks correct though. applied.
> --- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
On Wed, Feb 13, 2008 at 07:49:12AM +0100, rubisher wrote:
> --- include/asm-parisc/pgtable.h.Orig 2007-10-22 08:19:20.0 +
> +++ include/asm-parisc/pgtable.h 2008-02-12 16:28:36.0 +
> +extern void *vmalloc_start;
> +#define PCXL_DMA_MAP_SIZE (8*1024*1024)
> +#define
On Wed, Feb 13, 2008 at 07:49:12AM +0100, rubisher wrote:
--- include/asm-parisc/pgtable.h.Orig 2007-10-22 08:19:20.0 +
+++ include/asm-parisc/pgtable.h 2008-02-12 16:28:36.0 +
+extern void *vmalloc_start;
+#define PCXL_DMA_MAP_SIZE (8*1024*1024)
+#define
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
- some lake of changes of kset to kobj:
thanks, i don't build this driver, somehow it made its way out of my
configs. patch looks correct though. applied.
--- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
On Mon, Feb 11, 2008 at 05:23:33PM +0100, Roel Kluin wrote:
>
How about just doing something like this:
diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index 9448d4e..63f9b7f 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -409,7 +409,7 @@
On Mon, Feb 11, 2008 at 07:56:10PM +0100, Roel Kluin wrote:
> +/*
> + * dma_alloc_noncoherent is a fallback for boxes PA7200 and below which
> + * cannot allocate coherent memory.
> + */
> static void *pa11_dma_alloc_noncoherent(struct device *dev, size_t size,
>
On Mon, Feb 11, 2008 at 05:23:33PM +0100, Roel Kluin wrote:
How about just doing something like this:
diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index 9448d4e..63f9b7f 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -409,7 +409,7 @@
On Mon, Feb 11, 2008 at 07:56:10PM +0100, Roel Kluin wrote:
+/*
+ * dma_alloc_noncoherent is a fallback for boxes PA7200 and below which
+ * cannot allocate coherent memory.
+ */
static void *pa11_dma_alloc_noncoherent(struct device *dev, size_t size,
On Thu, Feb 07, 2008 at 03:33:07PM -0800, Christoph Lameter wrote:
> On Thu, 7 Feb 2008, Kyle McMartin wrote:
>
> > yes, it's in my batch of fixes.
>
> So I do not have to worry about it?
>
haha no. i don't expect people to have to untangle the mess of includes
that
On Fri, Feb 08, 2008 at 01:12:32AM +0200, Adrian Bunk wrote:
> Commit 9e2779fa281cfda13ac060753d674bbcaa23367e broke parisc:
>
> <-- snip -->
>
> ...
> CC arch/parisc/kernel/asm-offsets.s
> In file included from include/asm/pgtable.h:13,
> from
On Fri, Feb 08, 2008 at 01:12:32AM +0200, Adrian Bunk wrote:
Commit 9e2779fa281cfda13ac060753d674bbcaa23367e broke parisc:
-- snip --
...
CC arch/parisc/kernel/asm-offsets.s
In file included from include/asm/pgtable.h:13,
from
On Thu, Feb 07, 2008 at 03:33:07PM -0800, Christoph Lameter wrote:
On Thu, 7 Feb 2008, Kyle McMartin wrote:
yes, it's in my batch of fixes.
big sigh of relief So I do not have to worry about it?
haha no. i don't expect people to have to untangle the mess of includes
that is asm-parisc
clared identifier is
reported only once
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
--- a/scripts/kconfig/conf.c2008-01-17 15:45:59.0 -0800
+++ b/scripts/kconfig/conf.c2008-01-18 10:01:54.0 -0800
@@ -3,6 +3,8 @@
* Released under the terms of the
identifier is
reported only once
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
--- a/scripts/kconfig/conf.c2008-01-17 15:45:59.0 -0800
+++ b/scripts/kconfig/conf.c2008-01-18 10:01:54.0 -0800
@@ -3,6 +3,8 @@
* Released under the terms of the GNU GPL v2.0.
*/
+#include
On Fri, Jan 18, 2008 at 06:53:53AM +0100, Andi Kleen wrote:
> One problem that we had in the past is that some simulators
> only implement the absolutely minimum feature set and you
> might have well broken one of these with this.
Yeah, true. Please ignore the patch folks.
cheers, Kyle
--
To
as constants via the
> REQUIRED_MASK macros.
>
PSE, PGE, XMM, XMM2, and FXSR are defined as required features, and
will be optimized to a constant at compile time. Remove their redundant
definitions.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
--- a/include/asm-x86/cpufeature
On Fri, Jan 18, 2008 at 12:02:05AM -0500, H. Peter Anvin wrote:
>
Meh. Waste of my time, you've already done it, but the patch wasn't on
linux-kernel, so I didn't notice.
--Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
uest & xen paravirt enabled, and
x86_64. Boot tested on x86_64.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
include/asm-x86/alternative.h| 169 +-
include/asm-x86/alternative_32.h | 154 --
include/asm-x86/alt
Hopefully nobody will be stupid enough to implement a cpu without
it. Frankly, it seems safe enough given we already require SSE2.
This means the compiler can optimise away "if (!cpu_has_clflush)"
blocks.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
include/asm-x86
On Thu, Jan 17, 2008 at 09:03:17PM -0500, H. Peter Anvin wrote:
> The #ifdef is bogus. If it's required, it should go into
> asm-x86/required_features.h and then cpu_has_clflush is static; otherwise
> it's just plain wrong.
>
I have no objection to making cpu_has_clflush constant on x86_64.
i915_flush_ttm was unconditionally executing a clflush instruction
to (obviously) flush the cache. Instead, check if the cpu supports
clflush, and if not, fall back to calling wbinvd to flush the entire
cache.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
--- a/drivers/char/drm/i915_bu
i915_flush_ttm was unconditionally executing a clflush instruction
to (obviously) flush the cache. Instead, check if the cpu supports
clflush, and if not, fall back to calling wbinvd to flush the entire
cache.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
--- a/drivers/char/drm/i915_buffer.c
On Thu, Jan 17, 2008 at 09:03:17PM -0500, H. Peter Anvin wrote:
The #ifdef is bogus. If it's required, it should go into
asm-x86/required_features.h and then cpu_has_clflush is static; otherwise
it's just plain wrong.
I have no objection to making cpu_has_clflush constant on x86_64. The
Hopefully nobody will be stupid enough to implement a cpu without
it. Frankly, it seems safe enough given we already require SSE2.
This means the compiler can optimise away if (!cpu_has_clflush)
blocks.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
include/asm-x86/cpufeature_64.h
enabled, and
x86_64. Boot tested on x86_64.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
include/asm-x86/alternative.h| 169 +-
include/asm-x86/alternative_32.h | 154 --
include/asm-x86/alternative_64.h | 159
On Fri, Jan 18, 2008 at 12:02:05AM -0500, H. Peter Anvin wrote:
Meh. Waste of my time, you've already done it, but the patch wasn't on
linux-kernel, so I didn't notice.
--Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
the
REQUIRED_MASK macros.
PSE, PGE, XMM, XMM2, and FXSR are defined as required features, and
will be optimized to a constant at compile time. Remove their redundant
definitions.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
--- a/include/asm-x86/cpufeature.h
+++ b/include/asm-x86
On Fri, Jan 18, 2008 at 06:53:53AM +0100, Andi Kleen wrote:
One problem that we had in the past is that some simulators
only implement the absolutely minimum feature set and you
might have well broken one of these with this.
Yeah, true. Please ignore the patch folks.
cheers, Kyle
--
To
On Wed, Jan 16, 2008 at 11:57:54PM +0100, Jan Engelhardt wrote:
>
> On Jan 16 2008 17:20, Kyle McMartin wrote:
> >On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote:
> >> parent a9f7faa5fd229a65747f02ab0f2d45ee35856760
> >> commit
On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote:
> parent a9f7faa5fd229a65747f02ab0f2d45ee35856760
> commit
^- did you just make that up? ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote:
parent a9f7faa5fd229a65747f02ab0f2d45ee35856760
commit
^- did you just make that up? ;-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Wed, Jan 16, 2008 at 11:57:54PM +0100, Jan Engelhardt wrote:
On Jan 16 2008 17:20, Kyle McMartin wrote:
On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote:
parent a9f7faa5fd229a65747f02ab0f2d45ee35856760
commit
^- did you just make
On Tue, Jan 15, 2008 at 06:48:35PM -0800, Harvey Harrison wrote:
> +#ifdef CONFIG_X86_F00F_BUG
> +void do_invalid_op(struct pt_regs *, unsigned long);
> +#endif
> +
> +static int is_f00f_bug(struct pt_regs *regs, unsigned long address)
> +{
> +#ifdef CONFIG_X86_F00F_BUG
> + unsigned long nr;
fails to check if it actually received a
dev argument though, so if you don't pass a device, we get a nice
segfault.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
diff -Nur btrfs-progs-0.10/btrfsck.c btrfs-progs-0.10-kyle/btrfsck.c
--- btrfs-progs-0.10/btrfsck.c 2008-01-15 10:
if it actually received a
dev argument though, so if you don't pass a device, we get a nice
segfault.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
diff -Nur btrfs-progs-0.10/btrfsck.c btrfs-progs-0.10-kyle/btrfsck.c
--- btrfs-progs-0.10/btrfsck.c 2008-01-15 10:33:32.0 -0500
+++ btrfs
On Tue, Jan 15, 2008 at 06:48:35PM -0800, Harvey Harrison wrote:
+#ifdef CONFIG_X86_F00F_BUG
+void do_invalid_op(struct pt_regs *, unsigned long);
+#endif
+
+static int is_f00f_bug(struct pt_regs *regs, unsigned long address)
+{
+#ifdef CONFIG_X86_F00F_BUG
+ unsigned long nr;
You can
On Tue, Jan 08, 2008 at 10:28:04PM +1100, Rusty Russell wrote:
> De-mutex more symbol lookup paths in the module code
>
> Kyle McMartin reports sysrq_timer_list_show() can hit the module
> mutex; these paths don't need to though, since we long ago changed all
> the module li
On Tue, Jan 08, 2008 at 10:28:04PM +1100, Rusty Russell wrote:
De-mutex more symbol lookup paths in the module code
Kyle McMartin reports sysrq_timer_list_show() can hit the module
mutex; these paths don't need to though, since we long ago changed all
the module list manipulation to occur
]
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index de60e1e..09bb030 100644
--- a/drivers/char/sysrq.c
+++ b/drivers/char/sysrq.c
@@ -159,10 +159,16 @@ static struct sysrq_key_op sysrq_sync_op = {
.enabl
101 - 200 of 403 matches
Mail list logo
