From: Sam Ravnborg [EMAIL PROTECTED]
Following section mismatch warnings were reported by Andrey Borzenkov:
WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to
.init.text:amd_init_mtrr from .text between 'mtrr_bp_init' (at offset 0x967a)
and 'mtrr_attrib_to_str'
WARNING:
From: Nigel Cunningham [EMAIL PROTECTED]
Signed-off-by: Nigel Cunningham [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Rafael J. Wysocki [EMAIL PROTECTED]
Cc: Pavel Machek [EMAIL PROTECTED]
Acked-by: Linus
From: Andrew Morton [EMAIL PROTECTED]
Prevent stuff like this:
mm/vmalloc.c: In function 'unmap_kernel_range':
mm/vmalloc.c:75: warning: unused variable 'start'
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
From: Alan Stern [EMAIL PROTECTED]
This patch (as921) adds code to the show_regs() routine in i386 and x86_64
to print the contents of the debug registers along with all the others.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
Signed-off-by: Andi
From: Venki Pallipadi [EMAIL PROTECTED]
This helps to reduce the frequency at which the CPU must be taken out of a
lower-power state.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Acked-by: Tim Hockin [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL
From: Eric W. Biederman [EMAIL PROTECTED]
On x86_64 kernel, level triggered irq migration gets initiated in the
context of that interrupt(after executing the irq handler) and following
steps are followed to do the irq migration.
1. mask IOAPIC RTE entry; // write to IOAPIC RTE
2. EOI;
From: Adrian Bunk [EMAIL PROTECTED]
The Rise CPUs were only very short-lived, and there are no reports of
anyone both owning one and running Linux on it.
Googling for the printk string CPU: Rise iDragon didn't find any dmesg
available online.
If it turns out that against all expectations there
Linus,
Please pull from the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus
to get the following changes:
Avi Kivity (3):
KVM: MMU: Store nx bit for large page shadows
KVM: Fix memory slot management functions for guest smp
KVM: x86
Hello everyone!
Rule Set Based Access Control (RSBAC) 1.3.5 has been released for both
Linux kernels 2.4.34.5 and 2.6.22.1.
You can download the new version from http://www.rsbac.org
RSBAC is one of the leading access control systems for the Linux
kernel with a good selection of access control
qemu testing and booting test machines with i386 kernels wasn't very successfull
with recent git kernels. I got either BUGs because of failing sysfs
initialization
or oopses in kmalloc, but no user land.
I bisected it down to this commit.
To reproduce: try to boot a 386 defconfig kernel,
jffs2 can not return correct free space amount.
I checked jffs2_statfs, there is problem.
avail = c-dirty_size + c-free_size;
if (avail c-sector_size * c-resv_blocks_write)
avail -= c-sector_size * c-resv_blocks_write;
else
avail = 0;
But
* Olaf Kirch [EMAIL PROTECTED] wrote:
-You say that netconsole output continues to trickle after
the network gets wedged. This could be caused by the
e1000 watchdog, which triggers a NIC interrupt to ensure
rx ring is cleaned. I assume that this triggers the
From: TAKADA Yoshihito [EMAIL PROTECTED]
Subject: Re: i386: pata_cs5520 does not work
Date: Thu, 19 Jul 2007 02:20:39 +0900
Hi. I found it return from cs5520_init_one();
devm_request_irq() is failed.
rc = devm_request_irq(pdev-dev, irq[ap-port_no],
ata_interrupt, 0, DRV_NAME, host);
* Ingo Molnar [EMAIL PROTECTED] wrote:
the e1000 in this laptop is historically pretty robust. The only
problem i ever had with it were some rx/tx hw-engine latency problems
[pings from the outside took up to 1 second to propagate] that were
quickly fixed by the e1000 driver guys. Maybe
On 2007.07.19 11:55:06 +0200, Andi Kleen wrote:
From: [** iso-8859-1 charset **] Bj�rnSteinbrink [EMAIL PROTECTED]
The Intel PerfMon NMI watchdog was using the generic reservation
function which always reserves the first performance counter. But the
watchdog actually uses the second
On Thu, Jul 19, 2007 at 11:55:19AM +0200, Andi Kleen wrote:
From: Ravikiran G Thirumalai [EMAIL PROTECTED]
Too many remote cpu references due to /proc/stat.
On x86_64, with newer kernel versions, kstat_irqs is a bit of a problem.
On every call to kstat_irqs, the process brings in per-cpu
* Andi Kleen [EMAIL PROTECTED] wrote:
- int len = cpumask_scnprintf(page, count, irq_desc[(long)data].affinity);
+ struct irq_desc *desc = irq_desc + (long)data;
+ cpumask_t *mask = desc-affinity;
+ int len;
+#ifdef CONFIG_GENERIC_PENDING_IRQ
+ if (desc-status
On 2007.07.19 11:55:05 +0200, Andi Kleen wrote:
From: [** iso-8859-1 charset **] Bj�rnSteinbrink [EMAIL PROTECTED]
The performance counter allocator relies on the nmi watchdog being
probed, so we have to do that even if the watchdog is not enabled.
Are you going to revert your fixes to the
Hello Duncan,
Do you have any news regarding my case of slow transfers via
Speedtouch USB modem on linux ?
--
Regards,
MK
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi Andi,
On Thursday 19 July 2007 11:25, Andi Kleen wrote:
On Thursday 19 July 2007 10:52:48 Juergen Beisert wrote:
On Thursday 19 July 2007 10:22, Andi Kleen wrote:
Wow, that's a really cool bug; nice work! Don't forget to update
arch/i386/kernel/cpu/mtrr/state.c, though; it uses
On Thursday 19 July 2007 12:01, Ingo Molnar wrote:
Calling initcall 0xc0603f55: netpoll_init+0x0/0x39()
initcall 0xc0603f55: netpoll_init+0x0/0x39() returned 0.
initcall 0xc0603f55 ran for 0 msecs: netpoll_init+0x0/0x39()
Calling initcall 0xc0604257: netlink_proto_init+0x0/0x12a()
NET:
Googling for the printk string CPU: Rise iDragon didn't find any dmesg
available online.
If it turns out that against all expectations there are actually users
reverting this patch would be easy.
This patch will make the kernel images smaller by a few bytes for all
i386 users.
Why
On Thursday 19 July 2007 12:21:49 Christoph Hellwig wrote:
On Thu, Jul 19, 2007 at 11:55:19AM +0200, Andi Kleen wrote:
From: Ravikiran G Thirumalai [EMAIL PROTECTED]
Too many remote cpu references due to /proc/stat.
On x86_64, with newer kernel versions, kstat_irqs is a bit of a
On Thursday 19 July 2007 12:24:05 Björn Steinbrink wrote:
On 2007.07.19 11:55:05 +0200, Andi Kleen wrote:
From: [** iso-8859-1 charset **] Bj�rnSteinbrink [EMAIL PROTECTED]
The performance counter allocator relies on the nmi watchdog being
probed, so we have to do that even if the
On Thursday 19 July 2007 12:21:45 Björn Steinbrink wrote:
On 2007.07.19 11:55:06 +0200, Andi Kleen wrote:
From: [** iso-8859-1 charset **] Bj�rnSteinbrink [EMAIL PROTECTED]
The Intel PerfMon NMI watchdog was using the generic reservation
function which always reserves the first
* Olaf Kirch [EMAIL PROTECTED] wrote:
On Thursday 19 July 2007 12:01, Ingo Molnar wrote:
Calling initcall 0xc0603f55: netpoll_init+0x0/0x39()
initcall 0xc0603f55: netpoll_init+0x0/0x39() returned 0.
initcall 0xc0603f55 ran for 0 msecs: netpoll_init+0x0/0x39()
Calling initcall
This patch introduces a cpu time clock for s390 (only ticking
if the virtual cpu is running) and bases the s390 implementation
of sched_clock() on it.
The times lice length on a virtual cpu can be anything
between the calculated time slice and zero. In reality
this doesn't seem to be problem,
On Thu, Jul 19, 2007 at 11:45:29AM +0100, Alan Cox wrote:
Googling for the printk string CPU: Rise iDragon didn't find any dmesg
available online.
If it turns out that against all expectations there are actually users
reverting this patch would be easy.
This patch will make the
On Thu, Jul 19, 2007 at 10:23:59AM +0100, Alan Cox wrote:
Still don't follow. How is exceeds stack space but less likely to be
noticed safer.
Statistically speaking it clearly is. The reason is probably that the
irq theoretical issue happens only on large boxes with lots of
reentrant irqs. Not
On Thu, Jul 19, 2007 at 12:41:28PM +0200, Andi Kleen wrote:
On Thursday 19 July 2007 12:21:49 Christoph Hellwig wrote:
On Thu, Jul 19, 2007 at 11:55:19AM +0200, Andi Kleen wrote:
From: Ravikiran G Thirumalai [EMAIL PROTECTED]
Too many remote cpu references due to /proc/stat.
On
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Olaf Kirch [EMAIL PROTECTED] wrote:
On Thursday 19 July 2007 12:01, Ingo Molnar wrote:
Calling initcall 0xc0603f55: netpoll_init+0x0/0x39()
initcall 0xc0603f55: netpoll_init+0x0/0x39() returned 0.
initcall 0xc0603f55 ran for 0 msecs:
- It's not only code, it also bloats everyone's kernel image.
Its a miniscule piece of code that is discarded on boot. Yes it might
make the image 100 bytes longer, but have you priced a 160GB disk
recently. I don't think 100 bytes of disk and 0 of memory really is worth
saving for any risk at
Hi Andi,
On 7/19/07, Andi Kleen [EMAIL PROTECTED] wrote:
Call a function on a target CPU but do the right thing when
we're already on that CPU. That's the main difference from
smp_call_function_single
which does the wrong thing in this case (erroring out)
I think this is no longer the case,
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
steve walks warily down the street with the brim pulled way down low
...
diff --git a/fs/ncpfs/ncplib_kernel.c b/fs/ncpfs/ncplib_kernel.c
index 551e0ba..df6d60b 100644
--- a/fs/ncpfs/ncplib_kernel.c
+++ b/fs/ncpfs/ncplib_kernel.c
@@
On Thu, 19 Jul 2007, Karel Zak wrote:
On Wed, Jul 18, 2007 at 04:33:12PM -0400, Robert P. J. Day wrote:
On Wed, 18 Jul 2007, Jiri Slaby wrote:
Robert P. J. Day napsal(a):
given that the entire contents of include/linux/tty.h is contained
within an #ifdef __KERNEL__, it seems
On Wed, Jul 18, 2007 at 08:37:25PM -0500, Matt Mackall wrote:
Turn on irqstacks when using 8k stacks
Indeed.
Detect when usage with 8k stacks would overrun a 4k stack when doing
our stack switch and do a WARN_ONCE
Fix up the damn bugs
I don't think they're necessarily bugs. IMHO the
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
what subsystem would something like this belong to?
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 691a174..fd67da8 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -5,6 +5,10 @@
* 'tty.h' defines some
Hi Andrew,
On Wed, 18 Jul 2007, Andrew Morton wrote:
+struct ps3flash_private {
+ struct mutex mutex; /* Bounce buffer mutex */
+};
+#define ps3flash_priv(dev) ((dev)-sbd.core.driver_data)
bzzzt!
Same defense as ps3rom ;-)
+static loff_t ps3flash_llseek(struct file
Currently, CONFIG_X86_CMPXCHG64 both enables boot-time checking of
the cmpxchg64b feature and enables compilation of the set_64bit() family.
Since the option is dependent on PAE, and since KVM depends on set_64bit(),
this effectively disables KVM on i386 nopae.
Simplify by removing the config
Hello,
on current git head I see this new warning caused by commit
c70df74376c1e29a04e07e23dd3f4c384d6166dd
...
MODPOST vmlinux
WARNING: arch/i386/kernel/built-in.o(.text+0xc290): Section mismatch:
reference to .init.data:cpu_llc_id (between 'set_cpu_sibling_map' and
'initialize_secondary')
Rok Markovic wrote:
Hi
I would like to ask what could be a problem or how could I start
debuging it.
My board is cm-x270 from compulab and it successfully boot until it should
start init from busysbox. I get the folowing report.
environment:
pxa270
128Mb RAM
network boot
gcc 3.4.5 softfloat
I don't think they're necessarily bugs. IMHO the WARN_ON is better off
at 7k level like it is today with the current STACK_WARN. 4k for a
stack for common code really is small. I doubt you're going to find
You want the limit settable. On a production system you want to set the
limit to
On Jul 19 2007 02:01, Jacob A wrote:
How can a device driver go over the list of all the files that are open on a
specific inode instance?
pseudo-code:
task_list_lock;
for each process; do
lock_fdtable;
for each filedescriptor; do
do_something(fd-file_ptr);
koan wrote:
Are you sure about that chunk size? In you initial posting you show
/proc/mdstat reporting:
md2 : active raid5 sdc3[2] sda3[0] sdb3[1]
780083968 blocks level 5, 128k chunk, algorithm 2 [3/3] [UUU]
Which would seem to state a 128K chunk, and thus with a 4k block size
you
Andi Kleen [EMAIL PROTECTED] writes:
Don't need 16 byte alignment because kernel doesn't use SSE2
...
cflags-y += -maccumulate-outgoing-args
+cflags-y += -mpreferred-stack-boundary=4
From gcc manpage:
-mpreferred-stack-boundary=num
Attempt to keep the stack boundary
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
Fine with me. Thanks.
Acked-by: Petr Vandrovec [EMAIL PROTECTED]
---
steve walks warily down the street with the brim pulled way down low
...
diff --git a/fs/ncpfs/ncplib_kernel.c b/fs/ncpfs/ncplib_kernel.c
On Thu, 19 Jul 2007 11:36:31 +0200 (CEST),
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
We have a probe thread that checks for new storage devices and adds them to
the
bus with ps3_system_bus_device_register(), which calls device_register().
I guess the actual bus probe() routine gets
KAMEZAWA Hiroyuki wrote:
Then, what should I do more for fixing this SIGILL problem ?
-Kame
I can think of a relatively cheap solution:
New pages are allocated with the bit PG_arch_1 off, see
page_cache_read() ... prep_new_page(), i.e. the I-cache is
not coherent with the D-cache.
On Thursday 19 July 2007 13:13:40 Alan Cox wrote:
- It's not only code, it also bloats everyone's kernel image.
Its a miniscule piece of code that is discarded on boot. Yes it might
make the image 100 bytes longer, but have you priced a 160GB disk
recently. I don't think 100 bytes of disk
On Thursday 19 July 2007 13:50:20 Serge Belyshev wrote:
So -mpreferred-stack-boundary=4 is the default and to align stack
to 8 bytes you want -mpreferred-stack-boundary=3, not 4, IIUC.
Fixed thanks
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
But probably you should just drop this ... with smp_call_function_single's
new semantics, I don't see this function growing any users.
The new sched-clock uses it, but i'll update it to use smp_call_function_single
Thanks
-Andi
-
To unsubscribe from this list: send the line unsubscribe
On Thu, 19 Jul 2007, Cornelia Huck wrote:
On Thu, 19 Jul 2007 11:36:31 +0200 (CEST),
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
We have a probe thread that checks for new storage devices and adds them to
the
bus with ps3_system_bus_device_register(), which calls device_register().
Hi,
In latest kernel, we can't use panic_notifier_list if kdump is enabled.
panic_notifier_list is very useful function for debug, failover, etc...
So this patch adds a control file /proc/sys/kernel/dump_after_notifier
and resolves a problem users can not use both kdump and panic_notifier_list
Back to do_no_page():
if the new PTE includes the exec bit and PG_arch_1 is set,
the page has to be flushed from the I-cache before the PTE is
made globally visible.
Sorry, I wanted to say:
if the new PTE includes the exec bit and PG_arch_1 is NOT set
Thanks,
Zoltan
-
To unsubscribe from
On 7/19/07, Andi Kleen [EMAIL PROTECTED] wrote:
It is not fully softirq safe anyways.
Ack
[ sorry, I remember having promised to send such a patch myself
some time ago, but just forgot about it ... ]
Can't do a WARN_ON unfortunately because it could trigger in the
panic case.
But this is
Trying to compile todays git with modular AFS and gcc 4.1.3 prerelease
in Debian unstable (gcc version 4.1.3 20070629 (prerelease) (Debian
4.1.2-13)):
CC [M] fs/afs/flock.o
fs/afs/flock.c: In function 'afs_do_getlk':
fs/afs/flock.c:459: error: void value not ignored as it ought to be
On Thursday 19 July 2007 14:16:48 Satyam Sharma wrote:
Can't do a WARN_ON unfortunately because it could trigger in the
panic case.
But this is not true at all. This function doesn't come anywhere
on the panic codepath.
You're wrong.
-Andi
-
To unsubscribe from this list: send the
Quoting Christian Ehrhardt ([EMAIL PROTECTED]):
On Wed, Jul 18, 2007 at 06:35:03PM -0700, Andrew Morton wrote:
On Sat, 14 Jul 2007 12:37:01 -0400 (EDT)
James Morris [EMAIL PROTECTED] wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not
I like this approach much better, just one small note (I think I
had the same mistake in my changes initially):
@@ -202,7 +209,7 @@ static void alternatives_smp_lock(u8 **s
continue;
if (*ptr text_end)
continue;
- **ptr =
On Thu, 19 Jul 2007 15:19:40 +0300 (EEST),
Meelis Roos [EMAIL PROTECTED] wrote:
Trying to compile todays git with modular AFS and gcc 4.1.3 prerelease
in Debian unstable (gcc version 4.1.3 20070629 (prerelease) (Debian
4.1.2-13)):
CC [M] fs/afs/flock.o
fs/afs/flock.c: In function
On Thu, 19 Jul 2007, Serge E. Hallyn wrote:
If we could get a few (non-afilliated :) people who work with
customers in the security field to tell us whether this is being
used, that would be very helpful. Not sure how to get that.
The mainline kernel does not cater to out of tree code.
Or
Identical handlers of PTRACE_DETACH go into ptrace_request().
Not touching compat code.
Not touching archs that don't call ptrace_request.
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
arch/alpha/kernel/ptrace.c |4
arch/arm/kernel/ptrace.c |4
On Thursday 19 July 2007 14:25:59 Jan Beulich wrote:
I like this approach much better, just one small note (I think I
had the same mistake in my changes initially):
@@ -202,7 +209,7 @@ static void alternatives_smp_lock(u8 **s
continue;
if (*ptr text_end)
Mike Rapoport wrote:
I think you have conflict between PXA serial and 8250 drivers. Make sure
you use only one of them.
If you need to use PCMCIA serial cards, please see
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-July/040604.html
Thanks, I already fixed my problem. You
Quoting James Morris ([EMAIL PROTECTED]):
On Thu, 19 Jul 2007, Serge E. Hallyn wrote:
If we could get a few (non-afilliated :) people who work with
customers in the security field to tell us whether this is being
used, that would be very helpful. Not sure how to get that.
The mainline
On Thu, Jul 19, 2007 at 02:35:56PM +0200, Cornelia Huck wrote:
On Thu, 19 Jul 2007 15:19:40 +0300 (EEST),
Meelis Roos [EMAIL PROTECTED] wrote:
Trying to compile todays git with modular AFS and gcc 4.1.3 prerelease
in Debian unstable (gcc version 4.1.3 20070629 (prerelease) (Debian
On Thu, 19 Jul 2007 14:13:33 +0200 (CEST),
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
Any chance this will change? I already added a mutex to ps3disk to protect
against this.
Probably not in the near future. A mutex looks like a good idea though,
since one never knows (and the driver core
Gabriel C wrote:
Hello ,
I noticed on current git this warning in net/ipv4/inetpeer.c
Yeah, I have no idea why the gcc people thought that this was
something worth warning about. Especially since explicitly
checking for != NULL silences the warning again.
[IPV4]: Fix inetpeer gcc-4.2
Hello ,
I noticed on current git this warning in net/ipv4/inetpeer.c
...
CC net/ipv4/inetpeer.o
net/ipv4/inetpeer.c: In function 'unlink_from_pool':
net/ipv4/inetpeer.c:297: warning: the address of 'stack' will always
evaluate as 'true'
net/ipv4/inetpeer.c:297: warning: the address of
On Thursday 19 July 2007 12:58, Ingo Molnar wrote:
i.e. it's the classic 'eth0 got stuck somehow' tx/rx state machine
hickup symptoms, with no other bad symptoms such as lockups or crashes.
Duh, I found it.
The e1000 poll routine does this to leave polling mode.
This kvm release introduces guest smp. I've tested 4-way Linux (64-bit
and 32-bit) and 2-way Windows XP. A kernel build on 2-way 64-bit Linux
is 40% faster that on a uniprocessor guest. Expect performance to
improve as the in-kernel apic work is merged and as we tune kvm for smp.
Changes
Eugene Teo [EMAIL PROTECTED] wrote:
posix_test_lock() returns void, so there is no need to test the return value.
Checking fl-fl_type for F_UNLCK instead.
Yep, thanks. Andrew Morton already has a patch for this.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
just curious -- under kernel hacking, there is the option
UNUSED_SYMBOLS to Enable unused/obsolete exported symbols using
EXPORT_UNUSED_SYMBOL[_GPL]. reads the help text (in part):
This option is provided temporarily to provide a transition period in
case some external kernel module needs one
On Thursday 19 July 2007 14:52, Olaf Kirch wrote:
On Thursday 19 July 2007 12:58, Ingo Molnar wrote:
i.e. it's the classic 'eth0 got stuck somehow' tx/rx state machine
hickup symptoms, with no other bad symptoms such as lockups or crashes.
Duh, I found it.
The following patch should
On 7/19/07, James Morris [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Serge E. Hallyn wrote:
If we could get a few (non-afilliated :) people who work with
customers in the security field to tell us whether this is being
used, that would be very helpful. Not sure how to get that.
The
Andrew Morton [EMAIL PROTECTED] writes:
So I queued this, and then another patch to revert it so that the
x86_64-clockevents conversion would apply. But I was unable to locate the
corresponding bug in the post-x86_64-clockevents tree. Did it get fixed by
other means in there?
Yes, the
On Thu, 19 Jul 2007, Serge E. Hallyn wrote:
It's already pretty clear.
I doubt anyone not on lkml or linux-security-module has heard of this.
So we'll see.
(I was, obviously, talking about end-users)
If distributions are shipping binary modules and other out of tree code to
their
Hi all
max_debt is used in ext2's find_group_orlov . In ext4's
find_group_orlov, max_debt is only computed, but not used. I wonder
whether it's a typo, Can anyone give me a answer? The kernel source I
read is 2.6.22.
Thanks in advance.
Best Regards
YZ
-
To unsubscribe from
Juergen Beisert [EMAIL PROTECTED] writes:
Hi Andi,
On Thursday 19 July 2007 11:25, Andi Kleen wrote:
On Thursday 19 July 2007 10:52:48 Juergen Beisert wrote:
On Thursday 19 July 2007 10:22, Andi Kleen wrote:
Wow, that's a really cool bug; nice work! Don't forget to update
On Thu, 19 Jul 2007, Jim Kovaric wrote:
IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a
loadable module,
which is an out of tree module, and registers itself as a security
module during the TAMOS startup
process. It also requires that SElinux be disabled
Please
On Thu, 19 Jul 2007 14:05:06 +0200
Zoltan Menyhart [EMAIL PROTECTED] wrote:
KAMEZAWA Hiroyuki wrote:
Then, what should I do more for fixing this SIGILL problem ?
-Kame
I can think of a relatively cheap solution:
Maybe I should take performance numbers with the patch.
But is it too
Please distinguish between cater to and support. If the kernel
didn't worry about supporting out-of-tree code, then why would there
be loadable module at all?
Memory usage, flexibility, debugging.
Module support was not added for external modules.
-
To unsubscribe from this list: send the
Patrick McHardy wrote:
Gabriel C wrote:
Hello ,
I noticed on current git this warning in net/ipv4/inetpeer.c
Yeah, I have no idea why the gcc people thought that this was
something worth warning about. Especially since explicitly
checking for != NULL silences the warning again.
On Thu, Jul 19, 2007 at 07:56:53AM -0500, Scott Preece wrote:
On 7/19/07, James Morris [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Serge E. Hallyn wrote:
If we could get a few (non-afilliated :) people who work with
customers in the security field to tell us whether this is being
used,
On Thu, Jul 19, 2007 at 12:23:24PM +0300, Avi Kivity wrote:
No, it means disallowing pci devices that use shared irqs, and allowing
pci devices that use non-shared irqs.
Most machiens I see today have almost no chance of having PCI devices
without shared IRQs. This probably means any
On Thu, 19 Jul 2007, James Morris wrote:
On Thu, 19 Jul 2007, Jim Kovaric wrote:
IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a
loadable module,
which is an out of tree module, and registers itself as a security
module during the TAMOS startup
process. It
On Thu, Jul 19, 2007 at 12:27:43AM +0200, Jesper Juhl wrote:
Greetings,
There's a memory leak in fs/dlm/member.c::dlm_add_member().
If dlm_node_weight(ls-ls_name, nodeid) returns 0, then
we'll return without freeing the memory allocated to the (at
that point yet unused) 'memb'.
This
Patrick McHardy [EMAIL PROTECTED] writes:
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
From a user perspective:
I'm not sure promiscous mode is related to the problem.
Tcpdump without promiscous mode makes perfect sense.
I
On 7/19/07, Alan Cox [EMAIL PROTECTED] wrote:
Please distinguish between cater to and support. If the kernel
didn't worry about supporting out-of-tree code, then why would there
be loadable module at all?
Memory usage, flexibility, debugging.
Module support was not added for external
On Thu, 19 Jul 2007 22:01:18 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007 14:05:06 +0200
Zoltan Menyhart [EMAIL PROTECTED] wrote:
KAMEZAWA Hiroyuki wrote:
Then, what should I do more for fixing this SIGILL problem ?
-Kame
I can think of a relatively
Quoting James Morris ([EMAIL PROTECTED]):
On Thu, 19 Jul 2007, Serge E. Hallyn wrote:
It's already pretty clear.
I doubt anyone not on lkml or linux-security-module has heard of this.
So we'll see.
(I was, obviously, talking about end-users)
If distributions are shipping
Lennart Sorensen wrote:
On Thu, Jul 19, 2007 at 12:23:24PM +0300, Avi Kivity wrote:
No, it means disallowing pci devices that use shared irqs, and allowing
pci devices that use non-shared irqs.
Most machiens I see today have almost no chance of having PCI devices
without shared IRQs.
Linus Torvalds [EMAIL PROTECTED] writes:
So let's make a new rule:
We absolutely NEVER add things like must_check unless not checking
causes a real and obvious SECURITY ISSUE.
Oh, come on, almost every kernel bug is a potential security issue.
IMHO, if the function can only fail due to
Hi Andi,
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Hallo,
I had some second thoughts about the text patching of DEBUG_RODATA kernels
using change_page_attr(). Change_page_attr is intrusive and slow and using
a separate mapping is a little more gentle. I came up with this patch.
For your
Alan Cox [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007 03:33:58 +0200
Andrea Arcangeli [EMAIL PROTECTED] wrote:
8K stacks without IRQ stacks are not safer so I don't understand your
comment ?
Ouch, see the reports about 4k stack crashes. I agree they're not
safe w/o irq stacks (like on
Jeff Garzik [EMAIL PROTECTED] writes:
My overall goal is killing useless warnings
that continually obscure real ones.
Precisely, the goal should be to make must_check (and similar things)
warn only in real cases.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe
On Thu, 19 Jul 2007 15:28:46 +0200
Krzysztof Halasa [EMAIL PROTECTED] wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
From a user perspective:
I'm not sure promiscous
Ewww you plan to run this in SMP ? So you actually go byte
by byte changing pieces of instructions non atomically and doing
non-Intel's errata friendly XMC. You are really looking for trouble
there :) Two distinct errors can occur:
In this case it is ok because this only happens
[repost to linux-kernel because I messed up the email address first time]
- Controversal change: extend the unhandled signals logging to i386
* all flames to Masoud Asgharifard Sharbiani [EMAIL PROTECTED] please
- NUMA fallback handling for AMD Fam10h/11h (Joachim Deguara)
- Second try at
From: Adrian Bunk [EMAIL PROTECTED]
pgd_{c,d}tor() can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
arch/i386/mm/pgtable.c |6 +++---
1 file changed, 3 insertions(+), 3
901 - 1000 of 1493 matches
Mail list logo
