* Re: [PATCH] Fix CONFIG_PARAVIRT for 2.6.19-rc5-mm1
From: Andi Kleen @ 2006-11-09 7:12 UTC (permalink / raw)
To: virtualization; +Cc: Andrew Morton, Andi Kleen, Chris Wright
In-Reply-To: <1163034102.15681.6.camel@localhost.localdomain>
On Thursday 09 November 2006 02:01, Rusty Russell wrote:
> OK, at least two patches got dropped on the way from the mm tree to
> Andi's tree: the desc.h cleanup, and the processor.h rearrangement.
Can you please resend the patchkit with these patches included?
(and any further changes folded in into the respective patches)
Thanks,
-Andi
^ permalink raw reply
* [U-Boot-Users] AT91 Kernel oops when loading kernel from dataflash.
From: Ulf Samuelsson @ 2006-11-09 7:02 UTC (permalink / raw)
To: u-boot
In-Reply-To: <200611081945.36688.rss@barracuda.es>
Ra?l S?nchez Siles wrote:
> Hello all:
>
> This is the first time I write to the list, and I appreciate the
> big help it gives us users.
>
> We're using an AT91RM9200 based board called Portux920T. We have
> now a quite stable kernel and u-boot configuration which I attach. We
> manage to include a dataflash inside the portux board and get it to
> work. At least almost, please read on.
>
> When doing big transfers in memory (10M), we have some kernel
> oopses(see panic.log.zip attached). The oops comes up in the function
> __wake_up_common in the file kernel/sched.c
>
> The steps to reproduce this are the following:
>
> 1- Start the first bootloader (used the binary provided by atmel).
> 2- Make the first bootloader start u-boot(1.1.6).
> 3- U-boot downloads kernel(2.6.18) from _dataflash_ into RAM.
> 4- Rest of booting till shell prompt.
> 5- Execute for example: dd if=/dev/zero of=/root/borrar bs=1k
> count=10k 6- Oops!
You do not say that you are loading a ramdisk.
Do you have the file system in dataflash?
If not, I do not see how this can be influenced by the dd command...
If it is, then the 4 MB flash seems small for a 10 MB copy!
I can see two scenarios where the dataflash can cause problems.
1) The dataflash blocksize is not 1024 bytes, it is 1056 bytes
2) You are running the dataflash > 5 Mbps
The PDC of the SPI must not be starved of bus cycles,
or you are in trouble unless the H/W manages chipselect through GP I/O.
I would try
$ dd if=/dev/zero of=/root/borrar bs=1056 count=10k
to start with, abnd if this works, start digging.
>
> If we substitute step 3 for U-boot downloads kernel from _parallel
> flash_ into RAM, the Oops won't happen.
>
> The kernel has been patched with the latest maxim(2.6.18) patchset
> for the AT91RM9200 microcontroller. The u-boot configuration is also
> attached (portux920T.h).
>
> We have also tried using different first stage bootloaders we could
> find. Even we compile it ourselves using the RAM initialisation code
> taken from the u-boot. We also have tested several toolchains, from
> emdebian to the one provided by portux.
>
> We have 64MB Ram and we have tried using 64MB 32bit wide and 32MB
> 16bit wide. Flash and Dataflash are both 4MB.
> We will much appreciated whatever info or test that could take out
> from this works but... situation. Thank you very much.
>
> Regards,
>
>
>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services,
>> security? Get stuff done quickly with pre-integrated technology to
>> make your job easier Download IBM WebSphere Application Server
>> v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>
>
>> _______________________________________________
>> U-Boot-Users mailing list
>> U-Boot-Users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM: +46 (706) 22 44 57
Tel: +46 (8) 441 54 22
Fax: +46 (8) 441 54 29
Mail: Box 2033 174 02 Sundbyberg
Visit: Kavalleriv?gen 24
174 58 Sundbyberg'
Sweden
^ permalink raw reply
* Re: [DECnet] Don't clear memory twice.
From: David Miller @ 2006-11-09 7:02 UTC (permalink / raw)
To: ralf; +Cc: netdev, SteveW
In-Reply-To: <20061108154506.GA20057@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 8 Nov 2006 15:45:07 +0000
> When dn_neigh.c was converted from kmalloc to kzalloc in commit
> 0da974f4f303a6842516b764507e3c0a03f41e5a it was missed that
> dn_neigh_seq_open was actually clearing the allocation twice was
> missed.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks a lot Ralf.
^ permalink raw reply
* Re: [PATCH 2/3] mlsxfrm: Various fixes
From: James Morris @ 2006-11-09 7:02 UTC (permalink / raw)
To: Paul Moore; +Cc: vyekkirala, netdev, selinux, sds
In-Reply-To: <4552CD3B.40809@hp.com>
On Thu, 9 Nov 2006, Paul Moore wrote:
> It sounds like you have an idea of how you would like to see this implemented,
> can you give me a rough outline? Is this the partitioned SECMARK field you
> talked about earlier?
No, just the fact that you are in the same kernel address space and can
readily access the security context of the peer.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 2/3] mlsxfrm: Various fixes
From: James Morris @ 2006-11-09 7:02 UTC (permalink / raw)
To: Paul Moore; +Cc: vyekkirala, netdev, selinux, sds
In-Reply-To: <4552CD3B.40809@hp.com>
On Thu, 9 Nov 2006, Paul Moore wrote:
> It sounds like you have an idea of how you would like to see this implemented,
> can you give me a rough outline? Is this the partitioned SECMARK field you
> talked about earlier?
No, just the fact that you are in the same kernel address space and can
readily access the security context of the peer.
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [patch] fix up generic csum_ipv6_magic function prototype
From: David Miller @ 2006-11-09 7:00 UTC (permalink / raw)
To: kenneth.w.chen; +Cc: akpm, jgarzik, linux-kernel, netdev
In-Reply-To: <000301c703a3$0eedb340$ff0da8c0@amr.corp.intel.com>
From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Date: Wed, 8 Nov 2006 18:02:06 -0800
> The generic version of csum_ipv6_magic has the len argument declared as
> __u16, while most arch dependent version declare it as __u32. After
> looking at the call site of this function, I come up to a conclusion
> that __u32 is a better match with the actual usage.
>
> Hence, patch to change argument type for greater consistency.
>
> Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Architecture implementations such as the ones for m32r and parisc have
the same problem, so "for consistency" please fix them up as well.
Thanks a lot.
^ permalink raw reply
* Re: 2.6.19-rc5 x86_64 irq 22: nobody cared
From: Adrian Bunk @ 2006-11-09 6:49 UTC (permalink / raw)
To: Olivier Nicolas, Stephen Hemminger, Takashi Iwai, Jaroslav Kysela
Cc: linux-kernel, alsa-devel, gregkh, linux-pci, len.brown,
linux-acpi, Eric W. Biederman, Andrew Morton, Linus Torvalds
In-Reply-To: <4551D12D.4010304@trollprod.org>
On Wed, Nov 08, 2006 at 01:44:29PM +0100, Olivier Nicolas wrote:
> Hi,
Hi Olivier,
> 2.6.19-rc5 does not boot properly, I have tried pci=routeirq, irpoll
> without success.
>
> Full details (.config, dmesg, /proc/interrupts) are in
> http://olivn.trollprod.org/2.6.19-rc5-irq.tar.gz
thanks for your report!
I might be wrong, but looking at the dmesg:
- irq 22 is the hda_intel IRQ
- the "irq 22: nobody cared" is immediately before the
"hda_intel: No response from codec, disabling MSI..."
- in the routeirq case, the hda_intel IRQ as well as the
IRQ in the error message change to 21
So it might be related to the hda_intel MSI check.
If this was a wrong guess, other interesting messages in the dmesg are:
<-- snip -->
...
PCI: Using MMCONFIG at f0000000
PCI: No mmconfig possible on device 00:18
...
PCI: Setting latency timer of device 0000:00:03.0 to 64
pcie_portdrv_probe->Dev[02fd:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:03.0:pcie00]
Allocate Port Service[0000:00:03.0:pcie03]
PCI: Setting latency timer of device 0000:00:04.0 to 64
pcie_portdrv_probe->Dev[02fb:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:04.0:pcie00]
Allocate Port Service[0000:00:04.0:pcie03]
PCI: Setting latency timer of device 0000:00:12.0 to 64
pcie_portdrv_probe->Dev[0376:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:12.0:pcie00]
Allocate Port Service[0000:00:12.0:pcie03]
PCI: Setting latency timer of device 0000:00:14.0 to 64
pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:14.0:pcie00]
Allocate Port Service[0000:00:14.0:pcie03]
PCI: Setting latency timer of device 0000:00:16.0 to 64
pcie_portdrv_probe->Dev[0375:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:16.0:pcie00]
Allocate Port Service[0000:00:16.0:pcie03]
PCI: Setting latency timer of device 0000:00:17.0 to 64
pcie_portdrv_probe->Dev[0377:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:17.0:pcie00]
Allocate Port Service[0000:00:17.0:pcie03]
...
<-- snip -->
> Olivier
>
> System: ASUS M2N32-SLI, AMD64 X2 Dual Core 4600
>
>
> kernel 2.6.9-rc5
>
> irq 22: nobody cared (try booting with the "irqpoll" option)
>
> Call Trace:
> <IRQ> [<ffffffff80259055>] __report_bad_irq+0x35/0x90
> [<ffffffff802592d3>] note_interrupt+0x223/0x280
> [<ffffffff80259d41>] handle_fasteoi_irq+0xb1/0xf0
> [<ffffffff8020b17c>] call_softirq+0x1c/0x30
> [<ffffffff8020d1ba>] do_IRQ+0x8a/0xe0
> [<ffffffff8020a571>] ret_from_intr+0x0/0xa
> <EOI>
> handlers:
> [<ffffffff8807f150>] (nv_generic_interrupt+0x0/0xc0 [sata_nv])
> Disabling IRQ #22
>
>
> CPU0 CPU1
> 0: 223 45540 IO-APIC-edge timer
> 1: 1 402 IO-APIC-edge i8042
> 6: 1 4 IO-APIC-edge floppy
> 8: 0 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 0 103 IO-APIC-edge i8042
> 14: 7 140 IO-APIC-edge ide0
> 16: 0 0 IO-APIC-fasteoi libata
> 17: 0 10 IO-APIC-fasteoi bttv0
> 20: 0 20 IO-APIC-fasteoi ehci_hcd:usb1
> 21: 0 0 IO-APIC-fasteoi libata
> 22: 214 99786 IO-APIC-fasteoi libata, HDA Intel
> 23: 76 6230 IO-APIC-fasteoi libata, ohci_hcd:usb2
> 308: 5 3169 PCI-MSI-edge eth1
> 309: 0 10 PCI-MSI-edge eth1
> 310: 0 44 PCI-MSI-edge eth1
> 311: 1 3193 PCI-MSI-edge eth0
> 312: 0 0 PCI-MSI-edge eth0
> 313: 0 1 PCI-MSI-edge eth0
> NMI: 64 68
> LOC: 45716 45691
> ERR: 0
>
>
>
> kernel 2.6.19-rc5 with pci=routeirq
>
> irq 21: nobody cared (try booting with the "irqpoll" option)
>
> Call Trace:
> <IRQ> [<ffffffff80259055>] __report_bad_irq+0x35/0x90
> [<ffffffff802592d3>] note_interrupt+0x223/0x280
> [<ffffffff80259d41>] handle_fasteoi_irq+0xb1/0xf0
> [<ffffffff8020b17c>] call_softirq+0x1c/0x30
> [<ffffffff8020d1ba>] do_IRQ+0x8a/0xe0
> [<ffffffff802092f0>] default_idle+0x0/0x50
> [<ffffffff8020a571>] ret_from_intr+0x0/0xa
> <EOI> [<ffffffff80209319>] default_idle+0x29/0x50
> [<ffffffff8020939b>] cpu_idle+0x5b/0x80
> [<ffffffff8050039c>] start_secondary+0x50c/0x520
>
> handlers:
> [<ffffffff880e6fd0>] (usb_hcd_irq+0x0/0x60 [usbcore])
> Disabling IRQ #21
>
> CPU0 CPU1
> 0: 214 24856 IO-APIC-edge timer
> 1: 0 359 IO-APIC-edge i8042
> 6: 0 5 IO-APIC-edge floppy
> 8: 0 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-fasteoi acpi
> 12: 0 103 IO-APIC-edge i8042
> 14: 0 128 IO-APIC-edge ide0
> 16: 0 0 IO-APIC-fasteoi libata
> 17: 1 2 IO-APIC-fasteoi bttv0
> 20: 22 6469 IO-APIC-fasteoi libata
> 21: 11 99989 IO-APIC-fasteoi ehci_hcd:usb2, HDA Intel
> 22: 0 1 IO-APIC-fasteoi libata, ohci_hcd:usb1
> 23: 0 0 IO-APIC-fasteoi libata
> 308: 8 2378 PCI-MSI-edge eth1
> 309: 0 9 PCI-MSI-edge eth1
> 310: 0 9 PCI-MSI-edge eth1
> 311: 4 2401 PCI-MSI-edge eth0
> 312: 0 0 PCI-MSI-edge eth0
> 313: 0 1 PCI-MSI-edge eth0
> NMI: 74 47
> LOC: 25024 24991
> ERR: 0
>
>
>
> kernel 2.6.19-rc5 with irqpoll
>
> Hang during boot
> (See screenshot in http://olivn.trollprod.org/2.6.19-rc5-irq.tar.gz)
>
>
>
> kernel 2.6.18 (works without any problem)
>
> CPU0 CPU1
> 0: 1590 998089 IO-APIC-edge timer
> 1: 2 657 IO-APIC-edge i8042
> 6: 0 5 IO-APIC-edge floppy
> 8: 0 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-level acpi
> 12: 194 59353 IO-APIC-edge i8042
> 14: 13 6381 IO-APIC-edge ide0
> 50: 0 0 IO-APIC-level libata
> 58: 0 0 IO-APIC-level libata
> 66: 109 181425 IO-APIC-level libata, nvidia
> 74: 41 963 IO-APIC-level ehci_hcd:usb1, HDA Intel
> 82: 4 6 IO-APIC-level bttv0
> 90: 0 0 PCI-MSI-X eth0
> 98: 3 0 PCI-MSI-X eth0
> 106: 212234 0 PCI-MSI-X eth0
> 114: 532 0 PCI-MSI-X eth1
> 122: 445 0 PCI-MSI-X eth1
> 130: 212217 0 PCI-MSI-X eth1
> 233: 73 23009 IO-APIC-level libata, ohci_hcd:usb2
> NMI: 99 104
> LOC: 999684 999664
> ERR: 0
> MIS: 0
^ permalink raw reply
* Re: A proposal; making 2.6.20 a bugfix only version.
From: Arjan van de Ven @ 2006-11-09 6:48 UTC (permalink / raw)
To: Diego Calleja
Cc: Jesper Juhl, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, Adrian Bunk
In-Reply-To: <20061109002802.f61804fa.diegocg@gmail.com>
On Thu, 2006-11-09 at 00:28 +0100, Diego Calleja wrote:
> El Wed, 08 Nov 2006 23:22:11 +0100,
> Arjan van de Ven <arjan@infradead.org> escribió:
>
> > > There are many parts of the kernel that are not documented.
> >
> > this is where the OSDL Documentation Person will help a lot; a full time
> > person.
>
> Maybe it's just me, but wouldn't be this fixed by just asking developers
> to document their code?
it's a matter of skills. Someone can be awesome at coding a feature but
his english and writing skills may be waaaaay down there.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
^ permalink raw reply
* Re: [patch 9/9] net: uninline xfrm_selector_match()
From: David Miller @ 2006-11-09 6:46 UTC (permalink / raw)
To: akpm; +Cc: netdev, acme
In-Reply-To: <200611090351.kA93pBEl003702@shell0.pdx.osdl.net>
From: akpm@osdl.org
Date: Wed, 08 Nov 2006 19:51:10 -0800
> From: Andrew Morton <akpm@osdl.org>
>
> Six callsites, huge.
>
> Cc: Arnaldo Carvalho de Melo <acme@mandriva.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
Applied, thanks Andrew.
^ permalink raw reply
* Re: Jiffies wraparound is not treated in the schedstats
From: Balbir Singh @ 2006-11-09 6:45 UTC (permalink / raw)
To: balbir; +Cc: Mauricio Lin, linux-kernel
In-Reply-To: <4552CAD9.1080603@in.ibm.com>
Balbir Singh wrote:
>
> hmm.. jiffies wrapped around in sched_info_depart()? I've never seen
> that happen.
I meant beyond the edge of the boundary twice or more. One overflow is handled
as explained in the previous mail.
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs
^ permalink raw reply
* Re: [patch 4/9] lockdep: annotate sk_lock nesting in AF_BLUETOOTH
From: David Miller @ 2006-11-09 6:44 UTC (permalink / raw)
To: akpm; +Cc: netdev, a.p.zijlstra, marcel
In-Reply-To: <200611090351.kA93p5R3003687@shell0.pdx.osdl.net>
From: akpm@osdl.org
Date: Wed, 08 Nov 2006 19:51:05 -0800
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.18-1.2726.fc6 #1
> ---------------------------------------------
> hidd/2271 is trying to acquire lock:
> (sk_lock-AF_BLUETOOTH){--..}, at: [<f8d16241>] bt_accept_dequeue+0x26/0xc6
> [bluetooth]
>
> but task is already holding lock:
> (sk_lock-AF_BLUETOOTH){--..}, at: [<f8bce088>] l2cap_sock_accept+0x41/0x11e [l2cap]
>
> other info that might help us debug this:
> 1 lock held by hidd/2271:
> #0: (sk_lock-AF_BLUETOOTH){--..}, at: [<f8bce088>]
> l2cap_sock_accept+0x41/0x11e [l2cap]
>
> stack backtrace:
> [<c04051ed>] show_trace_log_lvl+0x58/0x16a
> [<c04057fa>] show_trace+0xd/0x10
> [<c0405913>] dump_stack+0x19/0x1b
> [<c043b7dc>] __lock_acquire+0x6ea/0x90d
> [<c043bf70>] lock_acquire+0x4b/0x6b
> [<c05b203b>] lock_sock+0xac/0xbc
> [<f8d16241>] bt_accept_dequeue+0x26/0xc6 [bluetooth]
> [<f8bce129>] l2cap_sock_accept+0xe2/0x11e [l2cap]
> [<c05b142e>] sys_accept+0xd8/0x179
> [<c05b1576>] sys_socketcall+0xa7/0x186
> [<c0403fb7>] syscall_call+0x7/0xb
>
> classical case of nesting; bt_accept_dequeue() locks the children of the object
> locked by l2cap_sock_accept().
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
Applied, thanks.
^ permalink raw reply
* RE: iptables + ROUTE
From: Seferovic Edvin @ 2006-11-09 6:44 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20061109054042.267180@gmx.net>
Hi,
I am not sure, but you are probably missing the extra module from
patch-o-matic-ng...
http://www.netfilter.org/projects/patch-o-matic/pom-extra.html#pom-extra-ROU
TE
E:S
-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Mato Vidovic
Sent: Donnerstag, 09. November 2006 06:41
To: netfilter@lists.netfilter.org
Subject: iptables + ROUTE
Hi,
I am new in iptables world - and after reading many discussions and studying
iptables manpages etc. I am
still missing a piece of puzzle to solve the following problem.
I have a need to perform TOS based traffic routing.
That means I have two interfaces (say eth0 and eth1) to backbone and I need
to route the real-time critical
IP traffic over eth1 and the remaining IP traffic over eth0.
After a lot of experimenting I came to the conclusion that something like
the following would do:
# iptables -t mangle -A POSTROUTING -m tos --tos 16 -j ROUTE --oif eth1
# iptables -t mangle -A POSTROUTING -m tos --tos !16 -j ROUTE --oif eth0
Unfortunately the Linux box says:
"No chain/target/match by that name"
The kernel I use is 2.6.18, iptables version is the last debian stable
version 1.2.11.
Any idea what is wrong here (am I missing something in the configuration, or
a library, or am I completely wrong maybe.)?
Thanks for any help.
Br.
Mato
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [patch 5/9] bnep endianness bug: filtering by packet type
From: David Miller @ 2006-11-09 6:43 UTC (permalink / raw)
To: akpm; +Cc: netdev, viro, marcel, viro
In-Reply-To: <200611090351.kA93p7gO003690@shell0.pdx.osdl.net>
From: akpm@osdl.org
Date: Wed, 08 Nov 2006 19:51:07 -0800
> From: Al Viro <viro@ftp.linux.org.uk>
>
> <= and => don't work well on net-endian...
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
Also already in my net-2.6.20 tree
^ permalink raw reply
* Re: [patch 6/9] bnep endianness annotations
From: David Miller @ 2006-11-09 6:43 UTC (permalink / raw)
To: akpm; +Cc: netdev, viro, marcel, viro
In-Reply-To: <200611090351.kA93p8d0003693@shell0.pdx.osdl.net>
From: akpm@osdl.org
Date: Wed, 08 Nov 2006 19:51:08 -0800
> From: Al Viro <viro@ftp.linux.org.uk>
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
Also already in my net-2.6.20 tree
^ permalink raw reply
* Re: [patch 8/9] rfcomm endianness bug: param_mask is little-endian on the wire
From: David Miller @ 2006-11-09 6:43 UTC (permalink / raw)
To: akpm; +Cc: netdev, viro, marcel, viro
In-Reply-To: <200611090351.kA93pApj003699@shell0.pdx.osdl.net>
From: akpm@osdl.org
Date: Wed, 08 Nov 2006 19:51:10 -0800
> From: Al Viro <viro@ftp.linux.org.uk>
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
Also already in my net-2.6.20 tree.
^ permalink raw reply
* Re: [patch 7/9] rfcomm endianness annotations
From: David Miller @ 2006-11-09 6:43 UTC (permalink / raw)
To: akpm; +Cc: netdev, viro, marcel, viro
In-Reply-To: <200611090351.kA93p9hK003696@shell0.pdx.osdl.net>
From: akpm@osdl.org
Date: Wed, 08 Nov 2006 19:51:09 -0800
> From: Al Viro <viro@ftp.linux.org.uk>
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
This one is in my net-2.6.20 GIT tree already.
^ permalink raw reply
* Re: [PATCH 0/3] labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]
From: David Miller @ 2006-11-09 6:42 UTC (permalink / raw)
To: jmorris; +Cc: vyekkirala, netdev, selinux, sds
In-Reply-To: <Pine.LNX.4.64.0611090124570.11016@d.namei>
From: James Morris <jmorris@namei.org>
Date: Thu, 9 Nov 2006 01:30:05 -0500 (EST)
> I think this should be aimed at 2.6.20, because we are at the last or
> second-last -rc currently, and I don't think these fixes are urgent enough
> to justify the risk at this stage. Also, I think this code needs more
> testing, and more general progress towards code completion.
This is the way I feel too.
^ permalink raw reply
* Re: 2.6.19-rc5 breaks klogd 1.4.1
From: Andrew Morton @ 2006-11-09 6:41 UTC (permalink / raw)
To: John Wendel; +Cc: Linux Kernel
In-Reply-To: <4552BB55.9090400@comcast.net>
On Wed, 08 Nov 2006 21:23:33 -0800
John Wendel <jwendel10@comcast.net> wrote:
> Just installed -rc5, system very slow, noticed klogd in a tight loop
> doing a "read". -rc4 is OK.
>
> Sorry, I have printk configured off, so I don't have any logs.
>
Please run
strace -p $(pidof klogd)
^ permalink raw reply
* Re: [parisc-linux] LBA PCI : avoid crash when pluging a pcmcia bridge
From: Grant Grundler @ 2006-11-09 6:40 UTC (permalink / raw)
To: Guy Martin; +Cc: parisc-linux
In-Reply-To: <20061108150706.bb658b27.gmsoft@tuxicoman.be>
On Wed, Nov 08, 2006 at 03:07:06PM +0100, Guy Martin wrote:
> Hi All,
>
> Referencing this thread about a crash when there is a pcmcia bridge plugged in a C3600 :
> http://lists.parisc-linux.org/pipermail/parisc-linux/2006-October/030312.html
>
> This small patch avoid a crash at boot time.
>
> It's certainly not perfect as it would be better to fix
> pci_scan_bus_parented() which returns NULL but at least
> it makes the box booting.
Guy,
This is exactly why I won't apply this patch.
Not many people are plugging PCMCIA bridges into parisc boxen.
Those that do can tweak this by hand if they really insist on
installing something that causes the kernel to crash.
> Thanks for applying or fixing this in a better way :)
I should have a bit of time next week to look at this
and one other parisc problem...but I first need to test the recipe
that willy posted last week for updating existing git source trees.
thanks for your patience and gentle reminder,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: [PATCH 2/3] mlsxfrm: Various fixes
From: Paul Moore @ 2006-11-09 6:39 UTC (permalink / raw)
To: James Morris; +Cc: vyekkirala, netdev, selinux, sds
In-Reply-To: <Pine.LNX.4.64.0611090109120.10907@d.namei>
James Morris wrote:
> On Wed, 8 Nov 2006, Paul Moore wrote:
>
>>James Morris wrote:
>>
>>>On Wed, 8 Nov 2006, Paul Moore wrote:
>>>
>>>>1. Functionality is available right now, no additional kernel changes needed
>>>>2. No special handling for localhost, I tend to like the idea of having
>>>>consistent behavior for all addresses/interfaces
>>>
>>>I don't agree. SO_PEERSEC should always just work for loopback, just like
>>>with Unix sockets.
>>
>>My main concern is that we would have "special" behavior for a single IP address
>> and that this behavior wouldn't be subject to the same labeled networking
>>configuration/management methods as the rest of the address space.
>
> It's a very special case, and loopack networking has lots of special case
> handling because of this. It's nearly zero cost to have this work, and
> then you get full SELinux control over local IP communications.
It sounds like you have an idea of how you would like to see this implemented,
can you give me a rough outline? Is this the partitioned SECMARK field you
talked about earlier?
I'm asking because the only localhost SO_PEERSEC mechanism that I have seen that
didn't require explicit packet labeling was the secid approach which I think we
gave up on ...
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [PATCH 2/3] mlsxfrm: Various fixes
From: Paul Moore @ 2006-11-09 6:39 UTC (permalink / raw)
To: James Morris; +Cc: vyekkirala, netdev, selinux, sds
In-Reply-To: <Pine.LNX.4.64.0611090109120.10907@d.namei>
James Morris wrote:
> On Wed, 8 Nov 2006, Paul Moore wrote:
>
>>James Morris wrote:
>>
>>>On Wed, 8 Nov 2006, Paul Moore wrote:
>>>
>>>>1. Functionality is available right now, no additional kernel changes needed
>>>>2. No special handling for localhost, I tend to like the idea of having
>>>>consistent behavior for all addresses/interfaces
>>>
>>>I don't agree. SO_PEERSEC should always just work for loopback, just like
>>>with Unix sockets.
>>
>>My main concern is that we would have "special" behavior for a single IP address
>> and that this behavior wouldn't be subject to the same labeled networking
>>configuration/management methods as the rest of the address space.
>
> It's a very special case, and loopack networking has lots of special case
> handling because of this. It's nearly zero cost to have this work, and
> then you get full SELinux control over local IP communications.
It sounds like you have an idea of how you would like to see this implemented,
can you give me a rough outline? Is this the partitioned SECMARK field you
talked about earlier?
I'm asking because the only localhost SO_PEERSEC mechanism that I have seen that
didn't require explicit packet labeling was the secid approach which I think we
gave up on ...
--
paul moore
linux security @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [PATCH 2.6.19 2/4] ehca: hcp_phyp.c: correct page mapping in 64k page mode
From: Paul Mackerras @ 2006-11-09 6:36 UTC (permalink / raw)
To: Christoph Raisch
Cc: linuxppc-dev, Roland Dreier, linux-kernel, openib-general
In-Reply-To: <OF60EFC2CD.F8FB1D23-ONC1257220.00315F90-C1257220.0038B8E3@de.ibm.com>
Christoph Raisch writes:
> ioremap maps 4k pages on 4k kernels and on 64k pages on 64k kernels. So far
> the theory.
>
> This is true for memory.
And for I/O. :) ioremap updates the (Linux) page tables that map the
vmalloc/ioremap area, and that is at page granularity. So there is in
fact no difference in the end result in the page tables whether you
ask to map a small amount inside a page, or the whole page.
> On POWER the ebus memory is mapped by H_ENTER.
> The hypervisor checks for 4k page size on H_ENTER, reason see above.
The next part of the story is that the low-level MMU code on System-P
(pSeries) machines only does the H_ENTER when you access an I/O
mapping. It does H_ENTER for 4k pages for non-cacheable mappings,
and it only does the H_ENTER for the 4k subpages of a 64k page that
the kernel actually accesses.
So Roland is correct in his comment about how ioremap is called.
Regards,
Paul.
^ permalink raw reply
* Re: Jiffies wraparound is not treated in the schedstats
From: Balbir Singh @ 2006-11-09 6:29 UTC (permalink / raw)
To: Mauricio Lin; +Cc: linux-kernel
In-Reply-To: <3f250c710611081005v5fcf3236qfb10b47bab1ada5f@mail.gmail.com>
Mauricio Lin wrote:
> Hi Balbir,
>
> Do you know why in the sched_info_arrive() and sched_info_depart()
> functions the calculation of delta_jiffies does not use the time_after
> or time_before macro to prevent the miscalculation when jiffies
> overflow?
>
> For instance the delta_jiffies variable is simply calculated as:
>
> delta_jiffies = now - t->sched_info.last_queued;
>
> Do not you think the more logical way should be
>
> if (time_after(now, t->sched_info.last_queued))
> delta_jiffies = now - t->sched_info.last_queued;
> else
> delta_jiffies = (MAX_JIFFIES - t->sched_info.last_queued) + now
>
What's MAX_JIFFIES? Is it MAX_ULONG? jiffies is unsigned long
so you'll have to be careful with unsigned long arithmetic.
Consider that now is 5 and t->sched_info.last_queued is 10.
On my system
perl -e '{printf("%lu\n", -5 + (1<<32) - 1);}'
4294967291
perl -e '{printf("%lu\n", -5 );}'
4294967291
> I have included more variables to measure some issues of schedule in
> the kernel (following schedstat idea) and I noticed that jiffies
> wraparound has led to wrong values, since the user space tool when
> collecting the values is producing negative values.
>
hmm.. jiffies wrapped around in sched_info_depart()? I've never seen
that happen. Could you post the additions and user space tool to look at?
What additional features are you planning to measure in the scheduler?
> Any comments?
>
> Can I provide a patch for that?
>
Please feel free to provide patches, this is open source!!
> BR,
>
> Mauricio Lin.
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs
^ permalink raw reply
* Re: [PATCH 0/3] labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]
From: James Morris @ 2006-11-09 6:30 UTC (permalink / raw)
To: Venkat Yekkirala; +Cc: netdev, selinux, Stephen Smalley
In-Reply-To: <45526241.10805@trustedcs.com>
On Wed, 8 Nov 2006, Venkat Yekkirala wrote:
> This patchset is against davem's net-2.6.git. Please apply to 2.6.19.
>
> The following are the changes since the previous post of this patchset:
>
> 1. Separate BUG_ON usage per Eric's suggestion.
>
> 2. Replace security_sid_compare with a simple sid compare check per
> a suggestion from Paul/Stephen.
Applied to:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-net-2.6.20.git
I think this should be aimed at 2.6.20, because we are at the last or
second-last -rc currently, and I don't think these fixes are urgent enough
to justify the risk at this stage. Also, I think this code needs more
testing, and more general progress towards code completion.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 0/3] labeled-ipsec: Repost patchset with updates [Originally: mlsxfrm: Various Fixes]
From: James Morris @ 2006-11-09 6:30 UTC (permalink / raw)
To: Venkat Yekkirala; +Cc: netdev, selinux, Stephen Smalley
In-Reply-To: <45526241.10805@trustedcs.com>
On Wed, 8 Nov 2006, Venkat Yekkirala wrote:
> This patchset is against davem's net-2.6.git. Please apply to 2.6.19.
>
> The following are the changes since the previous post of this patchset:
>
> 1. Separate BUG_ON usage per Eric's suggestion.
>
> 2. Replace security_sid_compare with a simple sid compare check per
> a suggestion from Paul/Stephen.
Applied to:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-net-2.6.20.git
I think this should be aimed at 2.6.20, because we are at the last or
second-last -rc currently, and I don't think these fixes are urgent enough
to justify the risk at this stage. Also, I think this code needs more
testing, and more general progress towards code completion.
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.