date:20050315


* Christoph Lameter [EMAIL PROTECTED] wrote:

 The following patch removes the magic in the timer_list structure
 (Andrew suggested that we may not need it anymore) and replaces it
 with two u8 variables that give us some additional state of the timer

The 'remove the magic' observation is not a 'backdoor' to introduce new
fields 'for free'. So please dont mix the two things into one patch.

 +   u8 running; /* function is currently executing */
 +   u8 shutdown;/* do not schedule this timer */

it may as well be cleaner to do the timer-base_running thing after all,
and to do this in __run_timers():

timer-base = NULL;
timer-base_running = base;

note that we cannot clear -base_running in __run_timers() [we dont own
any access to the timer anymore, it may be kfree()d, etc.], so
del_timer_sync() has to make sure that the timer-base_running info is
not stale - it is a hint only. But it looks doable, and it should solve
the NUMA scalability problem.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.11-bk10: ATA trouble

2005-03-15 Thread Prakash Punnoor

Hi,

today I got into some major trouble with the disk. nothing worked anymore and
I had to reboot with magic-sysrq. This was found in the log:

Mar 15 10:27:20 tachyon ATA: abnormal status 0xD0 on port 0xF0806087
Mar 15 10:27:20 tachyon ATA: abnormal status 0xD0 on port 0xF0806087
Mar 15 10:27:20 tachyon ATA: abnormal status 0xD0 on port 0xF0806087
Mar 15 10:27:50 tachyon ata1: command 0x35 timeout, stat 0x50 host_stat 0x61

What does it mean? I rebooted the machine now and everything is fine again. I
never had above problem before.

Here dmesg output and .config:

Linux version 2.6.11-bk10 ([EMAIL PROTECTED]) (gcc-Version 4.0.0-beta20050312
(Gentoo Linux 4.0.0_beta20050312)) #17 Mon Mar 14 21:24:58 CET 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f400 (usable)
 BIOS-e820: 0009f400 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 3fff (usable)
 BIOS-e820: 3fff - 3fff3000 (ACPI NVS)
 BIOS-e820: 3fff3000 - 4000 (ACPI data)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820:  - 0001 (reserved)
1023MB LOWMEM available.
On node 0 totalpages: 262128
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 258032 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
ACPI: RSDP (v000 Nvidia) @ 0x000f6b00
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff3000
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff3040
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff79c0
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010d) @ 0x
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000 (gap: 4000:bec0)
Built 1 zonelists
Kernel command line: root=/dev/md1 tsc quiet elevator=cfq hdb=none sdb=none
idle=halt acpi_skip_timer_override psmouse.rate=200 vga=0x51A video=mtrr,ypan
splash=verbose,theme:own
ide_setup: hdb=none
using halt in idle threads.
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2205.234 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1032848k/1048512k available (3254k kernel code, 14992k reserved, 1130k
data, 188k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4358.14 BogoMIPS (lpj=2179072)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff c1c3fbff  
  
CPU: After vendor identify, caps: 0383fbff c1c3fbff   
 
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1c3fbff  0020 
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm)  stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=0 pin2=-1
checking if image is initramfs... it is
Freeing initrd memory: 359k freed
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050211
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: nForce2 C1 Halt Disconnect fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link

RFC: CANbus subsytem for 2.6 kernel (char or netdev)

2005-03-15 Thread Andrey Volkov

Hello, all
I look through code of exist CANbus drivers, and have, may be strange, 
next question:

Anyone could told me, why everyone, who wrote CANbus driver (peak, 
kvaser etc) always use char dev, but not netdev for it? May be exist 
some global pitfall, which I couldn't see, which prevent to use netdev?

--
Regards
Andrey Volkov.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory


* Andrew Morton [EMAIL PROTECTED] wrote:

 Adrian Bunk [EMAIL PROTECTED] wrote:
 
  My point is simply:
  
   The help text for an option you need only under very specific 
   circumstances shouldn't sound as if this option was nearly was 
   mandatory.
 
 I think the sort of sell-your-cycles service which this patch enables is a
 neat idea, and one which is worth supporting, especially as the kernel
 patch is so tiny.  So we want as many machines as possible to support it. 
 So people don't need a special kernel just to join in.
 
 Others may disagree, although nobody has.
 
 And the patch is tiny.

see my earlier counter-arguments in the thread starting at:

  http://marc.theaimsgroup.com/?l=linux-kernelm=110630922022462w=2

end result of the thread: seccomp is completely unnecessary code-bloat
and can be equivalently implemented via ptrace. I cannot believe this
made it into -BK ...

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

what is actually syncronized update of filesystem

2005-03-15 Thread Somenath Ghosh

sir,
   i will give a presentation on j.f.s. . i read that at the time of 
asynchronous update the update of transactions are made maintaining an 
ordering, but i read that it is not so simple if the updation is 
synchronous. and i also don't know how the situation is handled.
  i request to inform me about that syncrhonous update so that i can get 
understand what the actual problem is and how the situation is handled.

 somenath

Somenath Ghosh
Chennai Mathematical Institute
14, Sathyapuri street, West Mambalam.
Ph. 044-2474-7328, 
Other E-mail adresses:= [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory


we at a minimum need the patch below.

Ingo

Signed-off-by: Ingo Molnar [EMAIL PROTECTED]

--- linux/arch/i386/Kconfig.orig
+++ linux/arch/i386/Kconfig
@@ -909,7 +909,6 @@ config REGPARM
 config SECCOMP
bool Enable seccomp to safely compute untrusted bytecode
depends on PROC_FS
-   default y
help
  This kernel feature is useful for number crunching applications
  that may need to compute untrusted bytecode during their
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Intel Ethernet PRO 100

2005-03-15 Thread shafa.hidee

Hi All,
Where we can find specs for writing driver for Intel PRO 100 card.


Regards
Shafahidee



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: nvidia fb licensing issue.

2005-03-15 Thread Dave Airlie


On Sun, 13 Mar 2005, Jon Smirl wrote:

 All of the files in drivers/char/drm really should have an explicit
 dual MIT/GPL license on them too. The DRM project has been taking
 patches back into DRM from LKML without making it clear that DRM is
 MIT licensed. It might be construed that doing this has made DRM GPL
 without that being the intention.

They all have explicit MIT licenses on them, these files are only
dual-licensed by the fact that they are shipped with the kernel, but they
are MIT licensed and I would consider any changes to them to be MIT
licensed unless someone explicitly states it..

Similiar to the reiser notice on top of those files.. I think MIT license
is explicit enough...

Some files are GPL licensed like drm_sysfs as it is obivously derived from
GPL code,

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

drm lockups since 2.6.11-bk2

2005-03-15 Thread Dave Airlie


Hi all,
Andrew Clayton reported lockups on the dri list issues since -bk2
and bug 4337 on bugzilla.kernel.org looks like it might be the same
thing..

This leads me to think the AGP multi-bridge patches are at fault... (for
once my laziness in merging late instead of early gave a good gap in the
patches...)

I'm offline in sense of I can write this mail and respond but have not
access to a Linux system, my bitkeeper trees, ssh keys for anywhere of
interest.. and am in the wrong country, it'll be the 23rd/24th before I am
back at my desks...

I might get time to do a code review, my main worry is that all the
problems reported with those patches in -mm made it into the patchset that
went into Linus.. mainly things like forgetting to memset certain
structures to 0 and sillies like that...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

x86: spin_unlock(), spin_unlock_irq() others are out of line ?

2005-03-15 Thread Eric Dumazet

Hi all
I noticed that in current linux kernel versions (2.6.11), some basic 
functions are out of line (not inlined)

Example of a call to spin_unlock(somelock)
c01069fa:   b8 e8 7b 35 c0  mov$0xc0357be8,%eax
c01069ff:   e8 3c e4 1f 00  call   c0304e40 _spin_unlock
c0304e40 _spin_unlock:
c0304e40:   c6 00 01movb   $0x1,(%eax)
c0304e43:   c3  ret
Same problem for _write_unlock(), _read_unlock(), _spin_unlock_irq(), ...
That seems odd, and I fail to see the reason for that. (It's OK for 
complex functions, but not for very short ones...)

Is it a regression, or is it needed ?
configuration :
- SMP
- Processor family (Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon)
- No Generic x86 support
Thank you
Eric Dumazet
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with 2.6.11-bk[3456]

2005-03-15 Thread Dave Airlie

 Got a problem here with the last few Linus -bk releases.
 
 2.6.11-bk2 is running fine.
 
 2.6.11-bk3 - 2.6.11-bk6 has the following problem:
 
 Everything is fine while the machine is booting. However as soon as X
 starts up the screen goes blank as normal but stays blank, no gdm login
 screen and the hard disk and floppy drive lights are on continuously.
 The machine is now locked up solid and needs a hard reset.
 
 I tried a serial console but get nothing after the kernel messages and
 the agetty login.
 
 The machine is question is an UP Athlon 1800+ XP with 768MB RAM, the
 graphics card is an AGP ATI Radeon 9200SE using the kernel AGP/DRM
 drivers and the Xorg radeon driver.
 
 It's running FC3.
 
 I've put 2.6.11-bk2 and 2.6.11-bk6 config's, dmesg's and an lspc -vv up
 on the web.
 
 http://digital-domain.net/kernel/2.6.11-bk2.config
 http://digital-domain.net/kernel/2.6.11-bk6.config
 http://digital-domain.net/kernel/2.6.11-bk2.dmesg
 http://digital-domain.net/kernel/2.6.11-bk6.dmesg
 http://digital-domain.net/kernel/lspci-vv
 
 When looking at this the other day I did get a message on the serial
 console after X started and the machine locked, about uhci host
 controller being disabled or something. Unfortunately I didn't make a
 note of it and didn't get it today for when I was preparing this report.
 
 Looking at the two dmesg's there is some difference in the usb messages.
 
 Anyway, thanks for your time and if you need any more info just let me
 know.

This is the same problem as i just mailed everyone about.. more
information here...

Dave.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Jonathan Sambrook

Xen, UML, VM, VMware, separate computers
http://linux-vserver.org/ would also seem to be an excellent match.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with 2.6.11-bk[3456]

2005-03-15 Thread Andrew Clayton

On Tue, 2005-03-15 at 10:50 +, Dave Airlie wrote:
  Got a problem here with the last few Linus -bk releases.
  
  2.6.11-bk2 is running fine.
  
  2.6.11-bk3 - 2.6.11-bk6 has the following problem:
  
  Everything is fine while the machine is booting. However as soon as X
  starts up the screen goes blank as normal but stays blank, no gdm login
  screen and the hard disk and floppy drive lights are on continuously.
  The machine is now locked up solid and needs a hard reset.
  

2.6.11-bk10 is a slight improvement in that the machine isn't completely
dead and I can ctrl+alt+delete it...

 This is the same problem as i just mailed everyone about.. more
 information here...
 
 Dave.
 

Cheers,

Andrew


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] I8K driver facelift

2005-03-15 Thread Giuseppe Bilotta

 According to your patch, the C840 has 2 temp sensors. I'll have to figure
 out what the second one is (prob either the GPU or the disk drive?)

If it runs over 40 C easily it's probably the GPU :)

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swsusp_restore crap

2005-03-15 Thread Pavel Machek

On Út 15-03-05 14:31:56, Benjamin Herrenschmidt wrote:
 On Tue, 2005-03-15 at 14:24 +1100, Benjamin Herrenschmidt wrote:
  Hi Pavel !
  
  Please kill that swsusp_restore() call that itself calls
  flush_tlb_global(), it's junk. First, the flush_tlb_global() thing is
  arch specific, and that's all swsusp_restore() does. Then, the asm just
  calls this before returning to C code, so it makes no sense to have a
  hook there. The x86 asm can have it's own call to some arch stuff if it
  wants or just do the tlb flush in asm...
 
 Better, here is a patch... (note: flush_tlb_global() is an x86'ism,
 doesn't exist on ppc, thus breaks compile, and that has nothing to do in
 the generic code imho, it should be clearly defined as the
 responsibility of the asm code).

x86-64 needs this, too Otherwise it looks okay.



 --
 
 This patch removes the quite x86-specific swsusp_restore() hook from the
 generic swsusp code and moves it to arch/i386. This also fixes build on
 ppc with swsusp enabled.
 
 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
 
 Index: linux-work/arch/i386/power/swsusp.S
 ===
 --- linux-work.orig/arch/i386/power/swsusp.S  2005-03-15 11:56:17.0 
 +1100
 +++ linux-work/arch/i386/power/swsusp.S   2005-03-15 14:29:09.0 
 +1100
 @@ -58,5 +58,5 @@
   movl saved_context_edi, %edi
  
   pushl saved_context_eflags ; popfl
 - call swsusp_restore
 + call __swsusp_flush_tlb
   ret
 Index: linux-work/arch/i386/power/cpu.c
 ===
 --- linux-work.orig/arch/i386/power/cpu.c 2005-03-15 11:56:17.0 
 +1100
 +++ linux-work/arch/i386/power/cpu.c  2005-03-15 14:28:26.0 +1100
 @@ -147,6 +147,15 @@
   __restore_processor_state(saved_context);
  }
  
 +asmlinkage int __swsusp_flush_tlb(void)
 +{
 + BUG_ON (nr_copy_pages_check != nr_copy_pages);
 + 
 + /* Even mappings of global things (vmalloc) need to be fixed */
 + __flush_tlb_global();
 + return 0;
 +}
 +
  /* Needed by apm.c */
  EXPORT_SYMBOL(save_processor_state);
  EXPORT_SYMBOL(restore_processor_state);
 Index: linux-work/kernel/power/swsusp.c
 ===
 --- linux-work.orig/kernel/power/swsusp.c 2005-03-15 12:00:13.0 
 +1100
 +++ linux-work/kernel/power/swsusp.c  2005-03-15 14:29:19.0 +1100
 @@ -907,15 +907,6 @@
  }
  
  
 -asmlinkage int swsusp_restore(void)
 -{
 - BUG_ON (nr_copy_pages_check != nr_copy_pages);
 - 
 - /* Even mappings of global things (vmalloc) need to be fixed */
 - __flush_tlb_global();
 - return 0;
 -}
 -
  int swsusp_resume(void)
  {
   int error;
 

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: CANbus subsytem for 2.6 kernel (char or netdev)

2005-03-15 Thread Benedikt Spranger


 Anyone could told me, why everyone, who wrote CANbus driver (peak, 
 kvaser etc) always use char dev, but not netdev for it? May be exist 
 some global pitfall, which I couldn't see, which prevent to use netdev?

Maybe you try out:
http://www.linutronix.de/data/linux-2.6.11-can.diff

Bene

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: nvidia fb licensing issue.

2005-03-15 Thread Arjan van de Ven

On Tue, 2005-03-15 at 10:32 +, Dave Airlie wrote:
 On Sun, 13 Mar 2005, Jon Smirl wrote:
 
  All of the files in drivers/char/drm really should have an explicit
  dual MIT/GPL license on them too. The DRM project has been taking
  patches back into DRM from LKML without making it clear that DRM is
  MIT licensed. It might be construed that doing this has made DRM GPL
  without that being the intention.
 
 They all have explicit MIT licenses on them, these files are only
 dual-licensed by the fact that they are shipped with the kernel, but they
 are MIT licensed and I would consider any changes to them to be MIT
 licensed unless someone explicitly states it..

this is actually a bit of a legal iffy point here. People submit patches
to the kernel (which is GPL). In addition, while patches to gpl code are
gpl (by the gpl derived works clause), the MIT license has no such
requirement or even assumption on derived works so it's all quite iffy.
I strongly suggest you put the dual license header in those files to get
rid of the ambiguity..  as you said it's not really a big deal in that
the code already is dual licensed in effect; please consider making it
explicit, it solves a lot of ambiguity.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory


* Ingo Molnar [EMAIL PROTECTED] wrote:

 see my earlier counter-arguments in the thread starting at:
 
   http://marc.theaimsgroup.com/?l=linux-kernelm=110630922022462w=2
 
 end result of the thread: seccomp is completely unnecessary code-bloat
 and can be equivalently implemented via ptrace. I cannot believe this
 made it into -BK ...

let me moderate my initial reaction somewhat:

the point i see in seccomp is that while it cannot be trusted right now
(not because of any known factor but simply because it doesnt have
enough review, yet), it might at a certain point (in many years) become
more trustable than TRACE_SYSCALLS.

It doesnt use a 'server' process to control syscall execution,
everything is enforced by the kernel. It is also intentionally simple,
and hence maybe even provably secure from a Comp-Sci POV. (assuming
sys_read()/sys_write() and hardware-irq processing itself is secure,
which quite likely wont be provable in the foreseeable future).

Also, while the technological arguments i raised in support of ptrace
are true, ptrace has a perception issue: it is perceived as insecure -
even if PTRACE_TRACE itself is not affected. And when building trust in
a processing platform, perception is just as important as raw security.

this combination of arguments i think tips the balance in favor of
seccomp, but still, i hate the fact that the anti-ptrace sentiment was
used as a vehicle to get this feature into the kernel.

technical comment: seccomp goes outside the audit/selinux framework,
which i believe is a bug. Andrea?

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ACPI] Re: Call for help: list of machines with working S3

2005-03-15 Thread Nigel Cunningham

Hi.

On Tue, 2005-03-15 at 19:10, Li Shaohua wrote:
 Hi,
 On Mon, 2005-03-14 at 16:00, Pavel Machek wrote:
  Hi!
  
 * MySQL (hinders the actual suspension process and kicks the pc
  back to 
   where it was)
  
  Try this patch...
  Pavel
  
  --- clean/kernel/signal.c   2005-02-03 22:27:26.0 +0100
  +++ linux/kernel/signal.c   2005-02-03 22:28:19.0 +0100
  @@ -,6 +,7 @@
  ret = -EINTR;
  }
   
  +   try_to_freeze(1);
  return ret;
   }
 I also encounter a similar issue. syslogd can't be stopped. It's waiting
 for kjournald to flush some works but kjournald is stopped first. Looks
 like the kernel thread should be stopped later than user thread just
 like Nigel's suspend2 patch does.

Pavel, do you have any kernel/power/process.c changes in? If not, I'll
submit those refrigerator changes.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-15 Thread Steven Rostedt



I've realized that my previous patch had too many problems with the way
the journaling system works.  So I went back to my first approach but
added the journal_head lock as one global lock to keep the buffer head
size smaller. I only added the state lock to the buffer head. I've tested
this for some time now, and it works well (for the test at least). I'll
recompile it with PREEMPT_DESKTOP to see if that works too.


-- Steve



diff -ur linux-2.6.11-final-V0.7.40-00.orig/fs/buffer.c 
linux-2.6.11-final-V0.7.40-00/fs/buffer.c
--- linux-2.6.11-final-V0.7.40-00.orig/fs/buffer.c  2005-03-02 
02:38:10.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/fs/buffer.c   2005-03-15 03:41:15.0 
-0500
@@ -3003,6 +3003,9 @@
preempt_disable();
__get_cpu_var(bh_accounting).nr++;
recalc_bh_state();
+#ifdef CONFIG_PREEMPT_RT
+   spin_lock_init(ret-b_jstate_lock);
+#endif
preempt_enable();
}
return ret;
diff -ur linux-2.6.11-final-V0.7.40-00.orig/fs/jbd/journal.c 
linux-2.6.11-final-V0.7.40-00/fs/jbd/journal.c
--- linux-2.6.11-final-V0.7.40-00.orig/fs/jbd/journal.c 2005-03-02 
02:37:49.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/fs/jbd/journal.c  2005-03-15 
03:49:10.0 -0500
@@ -82,6 +82,8 @@

 static int journal_convert_superblock_v1(journal_t *, journal_superblock_t *);

+spinlock_t journal_head_lock = SPIN_LOCK_UNLOCKED;
+
 /*
  * Helper function used to manage commit timeouts
  */
diff -ur linux-2.6.11-final-V0.7.40-00.orig/include/linux/buffer_head.h 
linux-2.6.11-final-V0.7.40-00/include/linux/buffer_head.h
--- linux-2.6.11-final-V0.7.40-00.orig/include/linux/buffer_head.h  
2005-03-02 02:37:45.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/include/linux/buffer_head.h   2005-03-15 
03:42:22.0 -0500
@@ -62,6 +62,13 @@
bh_end_io_t *b_end_io;  /* I/O completion */
void *b_private;/* reserved for b_end_io */
struct list_head b_assoc_buffers; /* associated with another mapping */
+
+#ifdef CONFIG_PREEMPT_RT
+   /*
+* Fixme: This should be in the journal code.
+*/
+   spinlock_t b_jstate_lock;   /* lock for journal state. */
+#endif
 };

 /*
diff -ur linux-2.6.11-final-V0.7.40-00.orig/include/linux/jbd.h 
linux-2.6.11-final-V0.7.40-00/include/linux/jbd.h
--- linux-2.6.11-final-V0.7.40-00.orig/include/linux/jbd.h  2005-03-02 
02:38:19.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/include/linux/jbd.h   2005-03-15 
03:45:33.0 -0500
@@ -314,6 +314,13 @@
 TAS_BUFFER_FNS(RevokeValid, revokevalid)
 BUFFER_FNS(Freed, freed)

+#ifdef CONFIG_PREEMPT_RT
+extern spinlock_t journal_head_lock;
+#define PICK_SPIN_LOCK(otype,bit,name) spin_##otype(bh-b_##name##_lock)
+#else
+#define PICK_SPIN_LOCK(otype,bit,name) bit_spin_##otype(bit,bh-b_state);
+#endif
+
 static inline struct buffer_head *jh2bh(struct journal_head *jh)
 {
return jh-b_bh;
@@ -326,24 +333,36 @@

 static inline void jbd_lock_bh_state(struct buffer_head *bh)
 {
-   bit_spin_lock(BH_State, bh-b_state);
+   PICK_SPIN_LOCK(lock,BH_State,jstate);
 }

 static inline int jbd_trylock_bh_state(struct buffer_head *bh)
 {
-   return bit_spin_trylock(BH_State, bh-b_state);
+   return PICK_SPIN_LOCK(trylock,BH_State,jstate);
 }

 static inline int jbd_is_locked_bh_state(struct buffer_head *bh)
 {
-   return bit_spin_is_locked(BH_State, bh-b_state);
+   return PICK_SPIN_LOCK(is_locked,BH_State,jstate);
 }

 static inline void jbd_unlock_bh_state(struct buffer_head *bh)
 {
-   bit_spin_unlock(BH_State, bh-b_state);
+   PICK_SPIN_LOCK(unlock,BH_State,jstate);
+}
+#undef PICK_SPIN_LOCK
+
+#ifdef CONFIG_PREEMPT_RT
+static inline void jbd_lock_bh_journal_head(struct buffer_head *bh)
+{
+   spin_lock(journal_head_lock);
 }

+static inline void jbd_unlock_bh_journal_head(struct buffer_head *bh)
+{
+   spin_unlock(journal_head_lock);
+}
+#else /* !CONFIG_PREEMPT_RT */
 static inline void jbd_lock_bh_journal_head(struct buffer_head *bh)
 {
bit_spin_lock(BH_JournalHead, bh-b_state);
@@ -353,6 +372,7 @@
 {
bit_spin_unlock(BH_JournalHead, bh-b_state);
 }
+#endif /* CONFIG_PREEMPT_RT */

 struct jbd_revoke_table_s;

diff -ur linux-2.6.11-final-V0.7.40-00.orig/include/linux/spinlock.h 
linux-2.6.11-final-V0.7.40-00/include/linux/spinlock.h
--- linux-2.6.11-final-V0.7.40-00.orig/include/linux/spinlock.h 2005-03-14 
06:00:54.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/include/linux/spinlock.h  2005-03-15 
03:40:31.0 -0500
@@ -774,6 +774,10 @@
 }))


+#ifndef CONFIG_PREEMPT_RT
+
+/* These are just plain evil! */
+
 /*
  *  bit-based spin_lock()
  *
@@ -789,10 +793,15 @@
 * busywait with less bus contention for a good time to
 * attempt to acquire the lock bit.
 */
-#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) || 
defined(CONFIG_PREEMPT)
-   while

Re: swsusp_restore crap

2005-03-15 Thread Rafael J. Wysocki

Hi,

On Tuesday, 15 of March 2005 12:03, Pavel Machek wrote:
 On t 15-03-05 14:31:56, Benjamin Herrenschmidt wrote:
  On Tue, 2005-03-15 at 14:24 +1100, Benjamin Herrenschmidt wrote:
   Hi Pavel !
   
   Please kill that swsusp_restore() call that itself calls
   flush_tlb_global(), it's junk. First, the flush_tlb_global() thing is
   arch specific, and that's all swsusp_restore() does. Then, the asm just
   calls this before returning to C code, so it makes no sense to have a
   hook there. The x86 asm can have it's own call to some arch stuff if it
   wants or just do the tlb flush in asm...
  
  Better, here is a patch... (note: flush_tlb_global() is an x86'ism,
  doesn't exist on ppc, thus breaks compile, and that has nothing to do in
  the generic code imho, it should be clearly defined as the
  responsibility of the asm code).
 
 x86-64 needs this, too Otherwise it looks okay.

It breaks compilation on i386 either, because nr_copy_pages_check
is static in swsusp.c.  May I propose the following patch instead (tested on
x86-64 and i386)?

Greets,
Rafael

Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]

diff -Nrup linux-2.6.11-bk10-a/arch/i386/power/cpu.c 
linux-2.6.11-bk10-b/arch/i386/power/cpu.c
--- linux-2.6.11-bk10-a/arch/i386/power/cpu.c   2005-03-15 09:20:53.0 
+0100
+++ linux-2.6.11-bk10-b/arch/i386/power/cpu.c   2005-03-15 12:16:57.0 
+0100
@@ -147,6 +147,15 @@ void restore_processor_state(void)
__restore_processor_state(saved_context);
 }
 
+asmlinkage int __swsusp_flush_tlb(void)
+{
+   swsusp_restore_check();
+
+   /* Even mappings of global things (vmalloc) need to be fixed */
+   __flush_tlb_global();
+   return 0;
+}
+
 /* Needed by apm.c */
 EXPORT_SYMBOL(save_processor_state);
 EXPORT_SYMBOL(restore_processor_state);
diff -Nrup linux-2.6.11-bk10-a/arch/i386/power/swsusp.S 
linux-2.6.11-bk10-b/arch/i386/power/swsusp.S
--- linux-2.6.11-bk10-a/arch/i386/power/swsusp.S2005-03-15 
09:20:53.0 +0100
+++ linux-2.6.11-bk10-b/arch/i386/power/swsusp.S2005-03-15 
12:16:28.0 +0100
@@ -58,5 +58,6 @@ done:
movl saved_context_edi, %edi
 
pushl saved_context_eflags ; popfl
-   call swsusp_restore
+
+   call__swsusp_flush_tlb
ret
diff -Nrup linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend_asm.S 
linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend_asm.S
--- linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend_asm.S2005-03-15 
09:20:53.0 +0100
+++ linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend_asm.S2005-03-15 
12:14:47.0 +0100
@@ -89,5 +89,6 @@ done:
movq saved_context_r14(%rip), %r14
movq saved_context_r15(%rip), %r15
pushq saved_context_eflags(%rip) ; popfq
-   callswsusp_restore
+
+   call__swsusp_flush_tlb
ret
diff -Nrup linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend.c 
linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend.c
--- linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend.c2005-03-02 
08:38:09.0 +0100
+++ linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend.c2005-03-15 
12:15:25.0 +0100
@@ -154,4 +154,11 @@ void fix_processor_context(void)
 
 }
 
+int __swsusp_flush_tlb(void)
+{
+   swsusp_restore_check();
 
+   /* Even mappings of global things (vmalloc) need to be fixed */
+   __flush_tlb_global();
+   return 0;
+}
diff -Nrup linux-2.6.11-bk10-a/include/linux/suspend.h 
linux-2.6.11-bk10-b/include/linux/suspend.h
--- linux-2.6.11-bk10-a/include/linux/suspend.h 2005-03-15 09:21:23.0 
+0100
+++ linux-2.6.11-bk10-b/include/linux/suspend.h 2005-03-15 12:20:06.0 
+0100
@@ -68,6 +68,8 @@ static inline void disable_nonboot_cpus(
 static inline void enable_nonboot_cpus(void) {}
 #endif
 
+void swsusp_restore_check(void);
+
 void save_processor_state(void);
 void restore_processor_state(void);
 struct saved_context;
diff -Nrup linux-2.6.11-bk10-a/kernel/power/swsusp.c 
linux-2.6.11-bk10-b/kernel/power/swsusp.c
--- linux-2.6.11-bk10-a/kernel/power/swsusp.c   2005-03-15 09:21:23.0 
+0100
+++ linux-2.6.11-bk10-b/kernel/power/swsusp.c   2005-03-15 12:18:36.0 
+0100
@@ -906,14 +906,9 @@ int swsusp_suspend(void)
return error;
 }
 
-
-asmlinkage int swsusp_restore(void)
+void swsusp_restore_check(void)
 {
BUG_ON (nr_copy_pages_check != nr_copy_pages);
-   
-   /* Even mappings of global things (vmalloc) need to be fixed */
-   __flush_tlb_global();
-   return 0;
 }
 
 int swsusp_resume(void)

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: CANbus subsytem for 2.6 kernel (char or netdev)

2005-03-15 Thread Andrey Volkov

Hi Benedikt,
Yes, thanks, very close to what about I thinking :),
but are you measure overhead of netdev (it disturb me)?
Andrey
Benedikt Spranger wrote:
Anyone could told me, why everyone, who wrote CANbus driver (peak, 
kvaser etc) always use char dev, but not netdev for it? May be exist 
some global pitfall, which I couldn't see, which prevent to use netdev?

Maybe you try out:
http://www.linutronix.de/data/linux-2.6.11-can.diff
Bene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01


* Steven Rostedt [EMAIL PROTECTED] wrote:

 I've realized that my previous patch had too many problems with the
 way the journaling system works.  So I went back to my first approach
 but added the journal_head lock as one global lock to keep the buffer
 head size smaller. I only added the state lock to the buffer head.
 I've tested this for some time now, and it works well (for the test at
 least). I'll recompile it with PREEMPT_DESKTOP to see if that works
 too.

good progress - but the global lock may be a scalability worry on
upstream though. Would it be possible to just mirror much of the current
lock logic, but with spinlocks instead of bitlocks? And there should be
no #ifdefs on PREEMPT_RT.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swsusp_restore crap

2005-03-15 Thread Pavel Machek

Hi!

Please kill that swsusp_restore() call that itself calls
flush_tlb_global(), it's junk. First, the flush_tlb_global() thing is
arch specific, and that's all swsusp_restore() does. Then, the asm just
calls this before returning to C code, so it makes no sense to have a
hook there. The x86 asm can have it's own call to some arch stuff if it
wants or just do the tlb flush in asm...
   
   Better, here is a patch... (note: flush_tlb_global() is an x86'ism,
   doesn't exist on ppc, thus breaks compile, and that has nothing to do in
   the generic code imho, it should be clearly defined as the
   responsibility of the asm code).
  
  x86-64 needs this, too Otherwise it looks okay.
 
 It breaks compilation on i386 either, because nr_copy_pages_check
 is static in swsusp.c.  May I propose the following patch instead (tested on
 x86-64 and i386)?


 +asmlinkage int __swsusp_flush_tlb(void)
 +{
 + swsusp_restore_check();

Someone will certainly forget this one, and it is probably
nicer/easier to just move BUG_ON into swsusp_suspend(), just after
restore_processor_state() or something like that...
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ACPI] Re: Call for help: list of machines with working S3

2005-03-15 Thread Pavel Machek

Hi!


  * MySQL (hinders the actual suspension process and kicks the pc
   back to 
where it was)
   
   Try this patch...
   Pavel
   
   --- clean/kernel/signal.c   2005-02-03 22:27:26.0 +0100
   +++ linux/kernel/signal.c   2005-02-03 22:28:19.0 +0100
   @@ -,6 +,7 @@
   ret = -EINTR;
   }

   +   try_to_freeze(1);
   return ret;
}
  I also encounter a similar issue. syslogd can't be stopped. It's waiting
  for kjournald to flush some works but kjournald is stopped first. Looks
  like the kernel thread should be stopped later than user thread just
  like Nigel's suspend2 patch does.
 
 Pavel, do you have any kernel/power/process.c changes in? If not, I'll
 submit those refrigerator changes.

No, process.c was left unchanged for quite a long time.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

enabling IOAPIC on C3 processor?

2005-03-15 Thread jerome lacoste

I have a VIA Epia M1 board that crashes very badly (and pretty
often, especially when using DMA). I want to fix that.

Serial console + magic SysRQ didn't help so I am going the nmi
watchdog way. But in order to have nmi watchdog I need APIC, right?

The C3 processor seems to support IOAPIC.
(http://www.via.com.tw/en/products/processors/c3/specs.jsp)

But:
- I don't see anything in the BIOS related to APIC. 
- grep APIC /lib/modules/`uname -r`/build/.config shows me that all
APIC options are 'y'.
- dmesg | grep APIC tells me no local APIC present or hardware disabled.
- adding lapic kernel parameter doesn't change that. 
- and of course, nmi_watchdog=1 or 2 gives me NMI count 0 in /proc/interrupts.

Did I miss something when it comes to enabling IOAPIC support on C3 processor?

Note: I also see a lot an increasing ERR count in /proc/interrupts,
especially when I put my box in conditions that make it also more
unstable (i.e. sending files on the network while using the PVR-350
using mythtv). Not sure if it is related.

Jerome

[EMAIL PROTECTED]:~$ dmesg | grep APIC
No local APIC present or hardware disabled
mapped APIC to d000 (013c1000)

[EMAIL PROTECTED]:~$ grep APIC /lib/modules/`uname -r`/build/.config 
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y

Grub options
[...]
kernel  /vmlinuz-2.6.11-medios1 root=/dev/hda1 ro 
console=ttyS0,57600n8 console=tty0 nmi_watchdog=1 lapic
[...]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] kill drivers/cdrom/mcd.c

As described in my patch that marked this obsolete driver as BROKEN,
this patch completely removes it.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 Documentation/cdrom/mcd  |4 
 Documentation/cdrom/mcdx |   17 
 drivers/cdrom/Kconfig|   56 -
 drivers/cdrom/Makefile   |1 
 drivers/cdrom/mcd.c  | 1565 ---
 drivers/cdrom/mcd.h  |  106 --
 6 files changed, 6 insertions(+), 1743 deletions(-)

--- linux-2.6.11-mm3-full/drivers/cdrom/Kconfig.old 2005-03-15 
04:14:03.0 +0100
+++ linux-2.6.11-mm3-full/drivers/cdrom/Kconfig 2005-03-15 04:20:07.0 
+0100
@@ -103,60 +103,14 @@
  To compile this driver as a module, choose M here: the
  module will be called sbpcd.
 
-config MCD
-   tristate Mitsumi (standard) [no XA/Multisession] CDROM support
-   depends on CD_NO_IDESCSI  BROKEN
-   ---help---
- This is the older of the two drivers for the older Mitsumi models
- LU-005, FX-001 and FX-001D. This is not the right driver for the
- FX-001DE and the triple or quad speed models (all these are
- IDE/ATAPI models). Please also the file
- file:Documentation/cdrom/mcd.
-
- With the old LU-005 model, the whole drive chassis slides out for cd
- insertion. The FX-xxx models use a motorized tray type mechanism.
- Note that this driver does not support XA or MultiSession CDs
- (PhotoCDs). There is a new driver (next question) which can do
- this. If you want that one, say N here.
-
- If you say Y here, you should also say Y or M to ISO 9660 CD-ROM
- file system support below, because that's the file system used on
- CD-ROMs.
-
- To compile this driver as a module, choose M here: the
- module will be called mcd.
-
-config MCD_IRQ
-   int MCD IRQ
-   depends on MCD
-   default 11
-   help
- This allows you to specify the default value of the IRQ used by the
- driver. This setting can be overridden by passing the mcd=
- parameter to the kernel at boot time (or at module load time if you
- said M to Standard Mitsumi CD-ROM support).
-
-config MCD_BASE
-   hex MCD I/O base
-   depends on MCD
-   default 300
-   help
- This allows you to specify the default value of the I/O base address
- used by the driver. This setting can be overridden by passing the
- mcd= parameter to the kernel at boot time (or at module load time
- if you said M to Standard Mitsumi CD-ROM support).
-
 config MCDX
-   tristate Mitsumi [XA/MultiSession] CDROM support
+   tristate Mitsumi CDROM support
depends on CD_NO_IDESCSI
---help---
- Use this driver if you want to be able to read XA or MultiSession
- CDs (PhotoCDs) as well as ordinary CDs with your Mitsumi LU-005,
- FX-001 or FX-001D CD-ROM drive. In addition, this driver uses much
- less kernel memory than the old one, if that is a concern. This
- driver is able to support more than one drive, but each drive needs
- a separate interface card. Please read the file
- file:Documentation/cdrom/mcdx.
+ Use this driver if you want to be able to use your Mitsumi LU-005,
+ FX-001 or FX-001D CD-ROM drive.
+
+ Please read the file file:Documentation/cdrom/mcdx.
 
  If you say Y here, you should also say Y or M to ISO 9660 CD-ROM
  file system support below, because that's the file system used on
--- linux-2.6.11-mm3-full/drivers/cdrom/Makefile.old2005-03-15 
04:14:34.0 +0100
+++ linux-2.6.11-mm3-full/drivers/cdrom/Makefile2005-03-15 
04:14:43.0 +0100
@@ -15,7 +15,6 @@
 obj-$(CONFIG_CM206)+= cm206.o  cdrom.o
 obj-$(CONFIG_GSCD) += gscd.o
 obj-$(CONFIG_ISP16_CDI)+= isp16.o
-obj-$(CONFIG_MCD)  += mcd.ocdrom.o
 obj-$(CONFIG_MCDX) += mcdx.o   cdrom.o
 obj-$(CONFIG_OPTCD)+= optcd.o
 obj-$(CONFIG_SBPCD)+= sbpcd.o  cdrom.o
--- linux-2.6.11-mm3-full/Documentation/cdrom/mcdx.old  2005-03-15 
04:21:07.0 +0100
+++ linux-2.6.11-mm3-full/Documentation/cdrom/mcdx  2005-03-15 
04:21:40.0 +0100
@@ -1,16 +1,3 @@
-This is a first attempt to create an `improved' driver for the Mitsumi drives.
-It is able to live together with mcd.c, if you have at least two Mitsumi
-drives: each driver can use its own drive.
-
-To allow this coexistence as long as mcdx.c is not a superset of mcd.c,
-this driver has to use its own device files. We use MAJOR 20 for it. So,
-you have to do
-
- # mknod /dev/mcdx0 b 20 0
- # mknod /dev/mcdx1 b 20 1
-
-and so on, one entry for each drive to support, once.
-
 If you are using the driver as a module, you can specify your ports and IRQs
 like
 
@@ -25,9 +12,7 @@
 ordinary CDs;
 o   supports up to 5 drives (of

[2.6 patch] fix bridge - ATM compile error

This patch fixes the following compile error with CONFIG_BRIDGE=y and 
CONFIG_ATM_LANE=m:

--  snip  --

...
  LD  .tmp_vmlinux1
net/built-in.o(.init.text+0x3ad1): In function `br_init':
: undefined reference to `br_fdb_get_hook'
net/built-in.o(.init.text+0x3adb): In function `br_init':
: undefined reference to `br_fdb_put_hook'
net/built-in.o(.exit.text+0xa2): In function `br_deinit':
: undefined reference to `br_fdb_get_hook'
net/built-in.o(.exit.text+0xac): In function `br_deinit':
: undefined reference to `br_fdb_put_hook'
make: *** [.tmp_vmlinux1] Error 1

--  snip  --

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 net/bridge/br.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.11-mm3-modular/net/bridge/br.c.old2005-03-15 
03:23:10.0 +0100
+++ linux-2.6.11-mm3-modular/net/bridge/br.c2005-03-15 03:24:05.0 
+0100
@@ -22,7 +22,7 @@
 
 #include br_private.h
 
-#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE)
+#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE)  
defined(MODULE))
 #include ../atm/lec.h
 #endif
 
@@ -39,7 +39,7 @@
brioctl_set(br_ioctl_deviceless_stub);
br_handle_frame_hook = br_handle_frame;
 
-#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE)
+#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE)  
defined(MODULE))
br_fdb_get_hook = br_fdb_get;
br_fdb_put_hook = br_fdb_put;
 #endif
@@ -60,7 +60,7 @@
 
synchronize_net();
 
-#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE)
+#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE)  
defined(MODULE))
br_fdb_get_hook = NULL;
br_fdb_put_hook = NULL;
 #endif

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-mm3 mouse oddity

2005-03-15 Thread Helge Hafting

2.6.11-mm1 and earlier: mouse appear as /dev/input/mouse0
2.6.11-mm3: mouse appear as /dev/input/mouse1
No big problem, one change to xorg.conf and I got the mouse back.
I guess it wasn't supposed to change like that though?
This is a mouse connected to the ps2 port, also appearing as /dev/psaux
Helge Hafting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] net/802/fc.c: remove fc_type_trans

On Mon, Mar 14, 2005 at 09:49:40PM -0800, David S. Miller wrote:
 On Sun, 6 Mar 2005 21:57:54 +0100
 Adrian Bunk [EMAIL PROTECTED] wrote:
 
  The only user of fc_type_trans (drivers/net/fc/iph5526.c) is BROKEN in 
  2.6 and removed in -mm.
  
  Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
 That driver isn't in Linus's tree any longer either.  Just delete
 the thing altogether instead of #if 0'ing it.
...

Updated patch:


--  snip  --


The only user of fc_type_trans (drivers/net/fc/iph5526.c) is removed in 
Linus' tree.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 include/linux/fcdevice.h |2 --
 net/802/fc.c |   34 --
 2 files changed, 36 deletions(-)

--- linux-2.6.11-mm1-full/include/linux/fcdevice.h.old  2005-03-06 
21:40:36.0 +0100
+++ linux-2.6.11-mm1-full/include/linux/fcdevice.h  2005-03-06 
21:41:07.0 +0100
@@ -24,12 +24,10 @@
 #define _LINUX_FCDEVICE_H
 
 
 #include linux/if_fc.h
 
 #ifdef __KERNEL__
-extern unsigned short  fc_type_trans(struct sk_buff *skb, struct net_device 
*dev); 
-
 extern struct net_device *alloc_fcdev(int sizeof_priv);
 #endif
 
 #endif /* _LINUX_FCDEVICE_H */
--- linux-2.6.11-mm3-full/net/802/fc.c.old  2005-03-15 13:02:13.0 
+0100
+++ linux-2.6.11-mm3-full/net/802/fc.c  2005-03-15 13:02:34.0 +0100
@@ -97,40 +97,6 @@
 #endif
 }
 
-unsigned short
-fc_type_trans(struct sk_buff *skb, struct net_device *dev)
-{
-   struct fch_hdr *fch = (struct fch_hdr *)skb-data;
-   struct fcllc *fcllc;
-
-   skb-mac.raw = skb-data;
-   fcllc = (struct fcllc *)(skb-data + sizeof (struct fch_hdr) + 2);
-   skb_pull(skb, sizeof (struct fch_hdr) + 2);
-
-   if (*fch-daddr  1) {
-   if (!memcmp(fch-daddr, dev-broadcast, FC_ALEN))
-   skb-pkt_type = PACKET_BROADCAST;
-   else
-   skb-pkt_type = PACKET_MULTICAST;
-   } else if (dev-flags  IFF_PROMISC) {
-   if (memcmp(fch-daddr, dev-dev_addr, FC_ALEN))
-   skb-pkt_type = PACKET_OTHERHOST;
-   }
-
-   /*
-* Strip the SNAP header from ARP packets since we don't pass
-* them through to the 802.2/SNAP layers.
-*/
-   if (fcllc-dsap == EXTENDED_SAP 
-   (fcllc-ethertype == ntohs(ETH_P_IP) ||
-fcllc-ethertype == ntohs(ETH_P_ARP))) {
-   skb_pull(skb, sizeof (struct fcllc));
-   return fcllc-ethertype;
-   }
-
-   return ntohs(ETH_P_802_2);
-}
-
 static void fc_setup(struct net_device *dev)
 {
dev-hard_header= fc_header;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.11-mm3: BUG: atomic counter underflow at: rpcauth_destroy

2005-03-15 Thread Martin Zwickel

Hi there!

I got some atomic counter underflows in the nfs code:

Mar 14 17:19:15 phoebee rpc.statd[6890]: Received erroneous SM_UNMON request
 from phoebee for 192.168.0.1
Mar 14 17:19:15 phoebee BUG: atomic counter underflow at:
Mar 14 17:19:15 phoebee [c03b51d1] rpcauth_destroy+0x41/0x50
Mar 14 17:19:15 phoebee [c03afcac] rpc_destroy_client+0x9c/0xf0
Mar 14 17:19:15 phoebee [c03b4698] rpc_free+0x18/0x40
Mar 14 17:19:15 phoebee [c03b49ad] rpc_release_task+0xad/0x120
Mar 14 17:19:15 phoebee [c03b4563] __rpc_execute+0x2e3/0x360
Mar 14 17:19:15 phoebee [c03b1580] xprt_init_autodisconnect+0x0/0xd0
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03af9e7] rpc_create_client+0x167/0x240
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03afefa] rpc_call_sync+0x5a/0xa0
Mar 14 17:19:15 phoebee [c0203874] nsm_mon_unmon+0xb4/0xe0
Mar 14 17:19:15 phoebee [c0203936] nsm_unmonitor+0x26/0x70
Mar 14 17:19:15 phoebee [c02007e8] nlm_gc_hosts+0x168/0x190
Mar 14 17:19:15 phoebee [c0200056] nlm_lookup_host+0x46/0x270
Mar 14 17:19:15 phoebee [c01fffd1] nlmclnt_lookup_host+0x11/0x20
Mar 14 17:19:15 phoebee [c01ff1da] nlmclnt_proc+0x4a/0x310
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c034955e] kernel_sendmsg+0x2e/0x40
Mar 14 17:19:15 phoebee [c03bb029] xdr_sendpages+0xc9/0x270
Mar 14 17:19:15 phoebee [c013a11c] mempool_free+0x4c/0xa0
Mar 14 17:19:15 phoebee [c03afd4b] rpc_release_client+0x4b/0x90
Mar 14 17:19:15 phoebee [c03b49a6] rpc_release_task+0xa6/0x120
Mar 14 17:19:15 phoebee [c03b4563] __rpc_execute+0x2e3/0x360
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03aff05] rpc_call_sync+0x65/0xa0
Mar 14 17:19:15 phoebee [c01cbe93] nfs3_rpc_wrapper+0x63/0x70
Mar 14 17:19:15 phoebee [c01cc113] nfs3_proc_setattr+0x93/0xd0
Mar 14 17:19:15 phoebee [c01ca38c] nfs_scan_commit+0x2c/0x70
Mar 14 17:19:15 phoebee [c01c3500] nfs_setattr+0xd0/0x1c0
Mar 14 17:19:15 phoebee [c013642c] __filemap_fdatawrite_range+0xbc/0xc0
Mar 14 17:19:15 phoebee [c01ca38c] nfs_scan_commit+0x2c/0x70
Mar 14 17:19:15 phoebee [c01cbc6f] nfs_commit_inode+0x3f/0xc0
Mar 14 17:19:15 phoebee [c01cbd44] nfs_sync_inode+0x54/0x70
Mar 14 17:19:15 phoebee [c01c1e37] do_setlk+0x77/0x170
Mar 14 17:19:15 phoebee [c01c1f30] nfs_lock+0x0/0x130
Mar 14 17:19:15 phoebee [c016947b] fcntl_setlk64+0x25b/0x2b0
Mar 14 17:19:15 phoebee [c0169e4e] dput+0x1e/0x250
Mar 14 17:19:15 phoebee [c0160790] path_release+0x10/0x60
Mar 14 17:19:15 phoebee [c01528a9] sys_chown+0x49/0x50
Mar 14 17:19:15 phoebee [c0164e74] sys_fcntl64+0x44/0x90
Mar 14 17:19:15 phoebee [c0103071] syscall_call+0x7/0xb
Mar 14 17:19:15 phoebee BUG: atomic counter underflow at:
Mar 14 17:19:15 phoebee [c03b51d1] rpcauth_destroy+0x41/0x50
Mar 14 17:19:15 phoebee [c03afcac] rpc_destroy_client+0x9c/0xf0
Mar 14 17:19:15 phoebee [c03b4698] rpc_free+0x18/0x40
Mar 14 17:19:15 phoebee [c03b49ad] rpc_release_task+0xad/0x120
Mar 14 17:19:15 phoebee [c03b4563] __rpc_execute+0x2e3/0x360
Mar 14 17:19:15 phoebee [c03b1580] xprt_init_autodisconnect+0x0/0xd0
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03af9e7] rpc_create_client+0x167/0x240
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03afefa] rpc_call_sync+0x5a/0xa0
Mar 14 17:19:15 phoebee [c0203874] nsm_mon_unmon+0xb4/0xe0
Mar 14 17:19:15 phoebee [c028118f] extract_entropy+0x4f/0xa0
Mar 14 17:19:15 phoebee [c02038c6] nsm_monitor+0x26/0x70
Mar 14 17:19:15 phoebee [c01ffa9b] nlmclnt_lock+0x2b/0xd0
Mar 14 17:19:15 phoebee [c01ff397] nlmclnt_proc+0x207/0x310
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c01c1e37] do_setlk+0x77/0x170
Mar 14 17:19:15 phoebee [c01c1f30] nfs_lock+0x0/0x130
Mar 14 17:19:15 phoebee [c016947b] fcntl_setlk64+0x25b/0x2b0
Mar 14 17:19:15 phoebee [c0169e4e] dput+0x1e/0x250
Mar 14 17:19:15 phoebee [c0160790] path_release+0x10/0x60
Mar 14 17:19:15 phoebee [c01528a9] sys_chown+0x49/0x50
Mar 14 17:19:15 phoebee [c0164e74] sys_fcntl64+0x44/0x90
Mar 14 17:19:15 phoebee [c0103071] syscall_call+0x7/0xb


Regardless of the erroneous SM_UNMON request, the atomic counter
should not underflow ;)


Regards,
Martin

-- 
MyExcuse:
The kernel license has expired

Martin Zwickel [EMAIL PROTECTED]
Research  Development

TechnoTrend AG http://www.technotrend.de


pgpjIB6KQ4Gc8.pgp
Description: PGP signature

Re: enabling IOAPIC on C3 processor?

jerome lacoste writes:
  I have a VIA Epia M1 board that crashes very badly (and pretty
  often, especially when using DMA). I want to fix that.
  
  Serial console + magic SysRQ didn't help so I am going the nmi
  watchdog way. But in order to have nmi watchdog I need APIC, right?
  
  The C3 processor seems to support IOAPIC.
  (http://www.via.com.tw/en/products/processors/c3/specs.jsp)
  
  But:
  - I don't see anything in the BIOS related to APIC. 
  - grep APIC /lib/modules/`uname -r`/build/.config shows me that all
  APIC options are 'y'.
  - dmesg | grep APIC tells me no local APIC present or hardware disabled.
  - adding lapic kernel parameter doesn't change that. 
  - and of course, nmi_watchdog=1 or 2 gives me NMI count 0 in 
  /proc/interrupts.
  
  Did I miss something when it comes to enabling IOAPIC support on C3 
  processor?

Unless you have a pre-release engineering part for a future product,
then your C3 has no local APIC, and hence no I/O APIC functionality.

I know some C3 specs pages list I/O APIC support, but if you look in
the datasheets for current products you find zero APIC support.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: enabling IOAPIC on C3 processor? (how to investigate hangs without nmi watchdog)

2005-03-15 Thread jerome lacoste

On Tue, 15 Mar 2005 13:34:55 +0100, Mikael Pettersson [EMAIL PROTECTED] wrote:
 jerome lacoste writes:
   I have a VIA Epia M1 board that crashes very badly (and pretty
   often, especially when using DMA). I want to fix that.
  
   Serial console + magic SysRQ didn't help so I am going the nmi
   watchdog way. But in order to have nmi watchdog I need APIC, right?
  
   The C3 processor seems to support IOAPIC.
   (http://www.via.com.tw/en/products/processors/c3/specs.jsp)
  
   But:
   - I don't see anything in the BIOS related to APIC.
   - grep APIC /lib/modules/`uname -r`/build/.config shows me that all
   APIC options are 'y'.
   - dmesg | grep APIC tells me no local APIC present or hardware disabled.
   - adding lapic kernel parameter doesn't change that.
   - and of course, nmi_watchdog=1 or 2 gives me NMI count 0 in 
 /proc/interrupts.
  
   Did I miss something when it comes to enabling IOAPIC support on C3 
 processor?
 
 Unless you have a pre-release engineering part for a future product,
 then your C3 has no local APIC, and hence no I/O APIC functionality.
 
 I know some C3 specs pages list I/O APIC support, but if you look in
 the datasheets for current products you find zero APIC support.

My board is 2 years old (May 2003).

I've checked the specs [2] and they say (page 17 out of 83)
APIC will be available in future steppings.  Yeah right...

Mine is stepping 1 according to /proc/cpuinfo.

So if I don't have APIC, that means I cannot use nmi_watchdog to
investigate the problem, right?

Do I have any alternative to investigate this hang or should I just
give up and smash my board?

Cheers,

Jerome

[2] http://www.via.com.tw/en/downloads/datasheets/processors/c3_nehemiah.zip
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch trivial] as-iosched fix path to Documentation

2005-03-15 Thread maximilian attems

On Tue, 15 Mar 2005, Adrian Bunk wrote:

 On Thu, Mar 10, 2005 at 12:42:23AM +0100, maximilian attems wrote:
 
  From: Klaus Ita [EMAIL PROTECTED]
  
  subject says all, patch still applies.
 ...
 
 Fix is already in -mm for some time.
 
 cu
 Adrian

yup saw it lately. great.
thanks for your mail.

--
maks

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: enabling IOAPIC on C3 processor? (how to investigate hangs without nmi watchdog)

jerome lacoste writes:
  So if I don't have APIC, that means I cannot use nmi_watchdog to
  investigate the problem, right?

Correct.

  Do I have any alternative to investigate this hang or should I just
  give up and smash my board?

I can't help you with that one.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Andrea Arcangeli

On Tue, Mar 15, 2005 at 12:27:12PM +0100, Ingo Molnar wrote:
 this combination of arguments i think tips the balance in favor of
 seccomp, but still, i hate the fact that the anti-ptrace sentiment was
 used as a vehicle to get this feature into the kernel.

Why should I use excuses to get this feature into the kernel if this
wasn't the best way to reach my goal? Do you think I'm shooting myself
in the foot and that I'd be better off using ptrace?

One other reason of using seccomp that you didn't mention is how simple
it is for me to code everything using seccomp (and this also makes me
much more confortable about its security, regardless of ptrace). Seccomp
is an arch indipendent API, ptrace is not.

It's not just the security of ptrace that is less desiderable, but it's
also the API itself that is much less desiderable, since it's so
lowlevel.

 which quite likely wont be provable in the foreseeable future).

Please mention a _single_ bug that could allow you to escape the seccomp
jail in linux since 2.4.0 on x86 and x86-64 (and with escape I don't
mean sniffing data with mmx not being backwards compatible, or f00f DoS,
I mean executing code into the host as user nobody). I'm not aware of a
_single_ seccomp bug that could allow you to escape the seccomp jail
since 2.4.0 and probably much earlier.

Either you answer the above or you may want to stop spreading FUD about
seccomp (and in turn about Cpushare security).

You know that a seccomp security bug is guaranteed to be a _major_
security bug for linux at large, not just for Cpushare, so I don't see
why you claim it's not provable to be secure, since what you're really
saying is that it's not provable that Linux is secure in multiuser
environment.

Personally I'm very confortable that linux security is ok in
read/write/signal/exit syscalls/irqs. At least as far as the software is
concerned.

It's not like there was no auditing, since those code paths are the most
heavily executed and if people go search into mremap is not because they
wouldn't get any benefit in exploiting read(2) or write(2) instead of
mremap. They look into mremap because they didn't find anything
expoitable in read/write.

There have been positive comments from people about seccomp not just for
my private project, so perhaps it will be used by others too.

In large grid environments security is important too, not just for
Cpushare. In a large grid environment if one of those nodes is
compromised by one user during his computations, this user may see and
alter the results for the other computations of the other users and at
least Cpushare is designed to detect and react to those conditions since
the first place.

Infact once I add trusted computing to Cpushare, it might become more
secure and reliable than a supercomputer for rent that is missing the
trusted computing in the hardware.

 technical comment: seccomp goes outside the audit/selinux framework,
 which i believe is a bug. Andrea?

I intentionally left it out of audit/selinux. To the less dependencies
it has on other parts of the kernel and the simpler it is, the better
IMHO. Seccomp should be fixed in stone, people shouldn't go hack on it
every day.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-15 Thread Steven Rostedt



On Tue, 15 Mar 2005, Ingo Molnar wrote:


 * Steven Rostedt [EMAIL PROTECTED] wrote:

  I've realized that my previous patch had too many problems with the
  way the journaling system works.  So I went back to my first approach
  but added the journal_head lock as one global lock to keep the buffer
  head size smaller. I only added the state lock to the buffer head.
  I've tested this for some time now, and it works well (for the test at
  least). I'll recompile it with PREEMPT_DESKTOP to see if that works
  too.

 good progress - but the global lock may be a scalability worry on
 upstream though. Would it be possible to just mirror much of the current
 lock logic, but with spinlocks instead of bitlocks? And there should be
 no #ifdefs on PREEMPT_RT.


The first patch I had just converted the bit spinlocks to spinlocks but I
thought that adding two spinlocks was too much for every buffer head, even
if it wasn't in the ext3 file system. The journal head spinlock is just
used to add and remove the journal heads from the buffer heads, so I'm not
sure how much contention is on them. I only have a dual smp system, so I
can't test the system on large number of CPUs. What do you think, should
we sacrafice memory for speed?

What should we use instead of #ifdef PREEMPT_RT? Or should we just keep it
the same for both.  Since this fix is only to fix spinlocks that schedule,
I figured that it would be better not to waste the memory of those not
using PREEMPT_RT.  Should I use the opposite PREEMPT_DESKTOP?

Thanks,

-- Steve

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Repeatable IDE Oops for 2.6.11 (ide-scsi vs ide-cdrom)

2005-03-15 Thread Alan Cox

On Maw, 2005-03-15 at 08:19, Bartlomiej Zolnierkiewicz wrote:
 On Mon, 14 Mar 2005, Alan Cox wrote:
 Locking is fixed in ide-dev-2.6 tree
 (at the moment seem to be dropped from -mm?).

Excellent - I'm looking forward to dropping the -ac IDE locking patches 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-15 Thread Kenan Esau

Here is a new version of the patch:
- minimal changes
- reintroduced DMI-probing

I had a look at the synaptic-sources to see how the pass-through-mode is
implemented. We'll see if something similar to this also works with the
lifebook.

I received a request from a user who has a Panasonic CF-29. It also
seems to have the same Touchscreen hardware like the lifebook. But it
doesn't seem to work as expected. Can someone get hold of a CF-29 and
test the psmouse-patch with it?
diff -X dontdiff -Naur linux-2.6.11.3/drivers/input/mouse/lifebook.c linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.c
--- linux-2.6.11.3/drivers/input/mouse/lifebook.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.c	2005-03-15 10:04:34.0 +0100
@@ -0,0 +1,126 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik [EMAIL PROTECTED]
+ * Copyright (c) 2005 Kenan Esau [EMAIL PROTECTED]
+ *
+ * TouchScreen detection, absolute mode setting and packet layout is taken from
+ * Harald Hoyer's description of the device.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/input.h
+#include linux/serio.h
+#include linux/libps2.h
+#include linux/dmi.h
+
+#include psmouse.h
+#include lifebook.h
+
+static int max_y = 1024;
+
+
+static struct dmi_system_id lifebook_dmi_table[] = {
+   {
+   .ident = Fujitsu Siemens Lifebook B-Sereis,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, LIFEBOOK B Series),
+   },
+   },
+   { }
+};
+
+
+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+	unsigned char *packet = psmouse-packet;
+	struct input_dev *dev = psmouse-dev;
+
+	if ( psmouse-pktcnt != 3 )
+		return PSMOUSE_GOOD_DATA;
+
+	input_regs(dev, regs);
+
+	/* calculate X and Y */
+	if ((packet[0]  0x08) == 0x00) {
+		input_report_abs(dev, ABS_X,
+ (packet[1] | ((packet[0]  0x30)  4)));
+		input_report_abs(dev, ABS_Y,
+ max_y - (packet[2] | ((packet[0]  0xC0)  2)));
+	} else {
+		input_report_rel(dev, REL_X, 
+((packet[0]  0x10) ? packet[1]-256 : packet[1]));
+		input_report_rel(dev, REL_Y, 
+(- (int)((packet[0]  0x20) ? packet[2]-256 : packet[2])));
+	}
+
+	input_report_key(dev, BTN_LEFT, packet[0]  0x01);
+	input_report_key(dev, BTN_RIGHT, packet[0]  0x02);
+	input_report_key(dev, BTN_TOUCH, packet[0]  0x04);
+
+	input_sync(dev);
+
+	return PSMOUSE_FULL_PACKET;
+}
+
+static int lifebook_initialize(struct psmouse *psmouse)
+{
+	struct ps2dev *ps2dev = psmouse-ps2dev;
+	unsigned char param;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;
+
+	/* 
+	   Enable absolute output -- ps2_command fails always but if
+	   you leave this call out the touchsreen will never send
+	   absolute coordinates
+	*/ 
+	param = 0x07;
+	ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
+
+	psmouse-set_rate(psmouse, psmouse-rate);
+	psmouse-set_resolution(psmouse, psmouse-resolution);
+	
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE))
+		return -1;
+
+	return 0;
+}
+
+static void lifebook_disconnect(struct psmouse *psmouse)
+{
+	psmouse_reset(psmouse);
+}
+
+int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto, 
+int set_properties)
+{
+if (!dmi_check_system(lifebook_dmi_table)  
+(max_proto != PSMOUSE_LIFEBOOK) )
+return -1;
+
+	if (set_properties) {
+		psmouse-vendor = Fujitsu Lifebook;
+		psmouse-name = TouchScreen;
+		psmouse-dev.evbit[0] = BIT(EV_ABS) | BIT(EV_KEY) | BIT(EV_REL);
+		psmouse-dev.keybit[LONG(BTN_LEFT)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) | BIT(BTN_RIGHT);
+		psmouse-dev.keybit[LONG(BTN_TOUCH)] = BIT(BTN_TOUCH);
+		psmouse-dev.relbit[0] = BIT(REL_X) | BIT(REL_Y);
+		input_set_abs_params(psmouse-dev, ABS_X, 0, 1024, 0, 0);
+		input_set_abs_params(psmouse-dev, ABS_Y, 0, 1024, 0, 0);
+
+		psmouse-protocol_handler = lifebook_process_byte;
+		psmouse-disconnect = lifebook_disconnect;
+		psmouse-reconnect  = lifebook_initialize;
+		psmouse-pktsize = 3;
+	}
+
+return lifebook_initialize(psmouse);
+}
diff -X dontdiff -Naur linux-2.6.11.3/drivers/input/mouse/lifebook.h linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.h
--- linux-2.6.11.3/drivers/input/mouse/lifebook.h	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.h	2005-03-14 10:01:57.0 +0100
@@ -0,0 +1,17 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.

Re: swsusp_restore crap

2005-03-15 Thread Benjamin Herrenschmidt


 It breaks compilation on i386 either, because nr_copy_pages_check
 is static in swsusp.c.  May I propose the following patch instead (tested on
 x86-64 and i386)?
 
 Greets,
 Rafael
 
 Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
 
 diff -Nrup linux-2.6.11-bk10-a/arch/i386/power/cpu.c 
 linux-2.6.11-bk10-b/arch/i386/power/cpu.c
 --- linux-2.6.11-bk10-a/arch/i386/power/cpu.c 2005-03-15 09:20:53.0 
 +0100
 +++ linux-2.6.11-bk10-b/arch/i386/power/cpu.c 2005-03-15 12:16:57.0 
 +0100
 @@ -147,6 +147,15 @@ void restore_processor_state(void)
   __restore_processor_state(saved_context);
  }
  
 +asmlinkage int __swsusp_flush_tlb(void)
 +{
 + swsusp_restore_check();
 +

Do we really need that check there ? Can't it be moved elsewhere ?

Ben.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bad pgd/pmd in latest BK on ia64

2005-03-15 Thread Martin Hicks


On Mon, Mar 14, 2005 at 02:34:42PM -0800, David S. Miller wrote:
 On Mon, 14 Mar 2005 14:06:09 -0800
 Luck, Tony [EMAIL PROTECTED] wrote:
 
  Trying to boot a build of the latest BK on ia64 I see
  a series of messages like this:
  
  mm/memory.c:99: bad pgd e001feba4000.
  mm/memory.c:99: bad pgd e001febac000.
  mm/memory.c:99: bad pgd e001febc0d10.
 
 Things are similarly busted on sparc64 for me as well.
 Things instantly reboot right after the kernel tries
 to open an initial console.

It's also busted on ia64 in 2.6.11-mm3 if that narrows thing down.

mh

-- 
Martin Hicks   ||   Silicon Graphics Inc.   ||   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swsusp_restore crap

2005-03-15 Thread Benjamin Herrenschmidt


 
  +asmlinkage int __swsusp_flush_tlb(void)
  +{
  +   swsusp_restore_check();
 
 Someone will certainly forget this one, and it is probably
 nicer/easier to just move BUG_ON into swsusp_suspend(), just after
 restore_processor_state() or something like that...

Agreed.

Ben.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11)

2005-03-15 Thread Alan Cox

On Maw, 2005-03-15 at 04:32, Lee Revell wrote:
 This seems sufficient for the simplest devices, that just have an
 IRQ_PENDING and an IRQ_ACK register.  But what about a device like the
 emu10k1 where you have a half loop and loop interrupt for each of 64
 channels, plus about 10 other interrupt sources?  The IPR just tells you
 there's a channel loop interrupt pending, in order to properly ACK it
 you need to set a bit in one of 4 registers depending on whether it's a
 loop or half loop interrupt, and whether the channel is 0-31 or 32-64.

Do we need to solve it for all such devices in one go and can we write
custom code for the hard cases. Peter solved the simple unshared-IRQ
case. I'd like to solve the simple shared IRQ cases too (because X can
use this).

I'm wondering where the right line is ?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01


* Steven Rostedt [EMAIL PROTECTED] wrote:

  good progress - but the global lock may be a scalability worry on
  upstream though. Would it be possible to just mirror much of the current
  lock logic, but with spinlocks instead of bitlocks? And there should be
  no #ifdefs on PREEMPT_RT.
 
 The first patch I had just converted the bit spinlocks to spinlocks
 but I thought that adding two spinlocks was too much for every buffer
 head, even if it wasn't in the ext3 file system. The journal head
 spinlock is just used to add and remove the journal heads from the
 buffer heads, so I'm not sure how much contention is on them. I only
 have a dual smp system, so I can't test the system on large number of
 CPUs. What do you think, should we sacrafice memory for speed?

there are two bad effects of global spinlocks: 1) contention 2)
cacheline bouncing. It's #2 that would affect this spinlock. While i'm
not sure this would show up in usual benchmarks, we should rather err on
the side of more scalability. Two spinlocks are just two more machine
words on most architectures, so i dont think it matters all that much,
while it removes a major wart - as long as the two extra locks are for
ext3 buffer-heads only.

 What should we use instead of #ifdef PREEMPT_RT? Or should we just
 keep it the same for both.  Since this fix is only to fix spinlocks
 that schedule, I figured that it would be better not to waste the
 memory of those not using PREEMPT_RT.  Should I use the opposite
 PREEMPT_DESKTOP?

i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
would simplify things, besides making PREEMPT_RT simpler as well. The
memory overhead is not a big issue i believe. (8 more bytes per ext3 bh,
on x86)

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

how to read gateways ips from routing table in module?

2005-03-15 Thread cranium2003

Hello,
 I require a kernel module that will print
gateway IP addresses in routing table as well as it
should not print Gateways that appear to be the same
interface ip addresses of that linux machine.
 e.g. If my eth1 is 172.16.x.x and if same
appear in routing table for any entry having
172.16.x.x as Gateway then it should not appear in
output.
regards,
cranium




__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] w6692 eliminate bad section references

2005-03-15 Thread maximilian attems

On Mon, 14 Mar 2005, Randy.Dunlap wrote:

 maximilian attems wrote:
 Fix w6692 section references:
   convert __initdata to __devinitdata.
 
 Error: ./drivers/isdn/hisax/w6692.o .text refers to 002f R_386_32
 .init.data
 
 I think the correct fix is to make W6692Version() be __init ...
 What do you think of that?
 
 -- 
 ~Randy

thanks a lot for your review!
you are right much better, added __init to W6692Version().

#Signed-off-by: maximilian attems [EMAIL PROTECTED]

diff -pruN -X dontdiff linux-2.6.11-bk8/drivers/isdn/hisax/w6692.c
linux-2.6.11-bk8-max/drivers/isdn/hisax/w6692.c
--- linux-2.6.11-bk8/drivers/isdn/hisax/w6692.c 2005-03-02 08:38:25.0 
+0100
+++ linux-2.6.11-bk8-max/drivers/isdn/hisax/w6692.c 2005-03-15 
14:01:14.0 +0100
@@ -49,7 +49,7 @@ static char *W6692Ver[] __initdata =
 {W6692 V00, W6692 V01, W6692 V10,
  W6692 V11};
 
-static void
+static void __init
 W6692Version(struct IsdnCardState *cs, char *s)
 {
int val;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] reduce __deprecated spew

2005-03-15 Thread Josh Boyer

On Tue, 2005-03-15 at 08:16 +0100, Arjan van de Ven wrote:
  (The intermodule_register and pm_register stuff has been hanging around for
  so long that one wonders if we need sterner stimuli, not lesser).
 
 intermodule can just about go (one user left).. we could start by making
 the intermodule.c file only build when that one user is selected (that
 user is a corner case) to avoid others from accidentally starting to use
 it again ...

It might be a corner case on PCs, but MTD used quite heavily in embedded
environments.  Perhaps it's time it just got fixed.  I remember seeing a
patch from Rusty a while ago that was a first run at doing this.  Is
that still hanging around somewhere?

josh

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-mm3 breaks compile of drivers/char/esp.c

2005-03-15 Thread Alan Cox

On Maw, 2005-03-15 at 04:33, Andrew Morton wrote:
 --- 25/include/linux/hayesesp.h~esp-build-fix 2005-03-14 20:31:18.0 
 -0800
 +++ 25-akpm/include/linux/hayesesp.h  2005-03-14 20:31:30.0 -0800
 @@ -77,6 +77,7 @@ struct hayes_esp_config {
  
  struct esp_struct {
   int magic;
 + spinlock_t  lock;
   int port;
   int irq;
   int flags;  /* defined in tty.h */

 I didn't pick this up because ESPSERIAL is still BROKEN_ON_SMP.  Alan,
 should we remove that now?

I think so yes. Needs a bit more testing to be totally sure

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ocf-linux-20050315 - Asynchronous Crypto support for linux

2005-03-15 Thread David McCullough


Hi all,

The latest release of ocf-linux (20050315) is available for download
from the project page:

http://ocf-linux.sourceforge.net/

This release includes the following changes:

* Hifn PLL bug fixes
* Makefile fixes for 2.6 builds
* 2.6.11 and 2.4.29 patches
* cleanups for x86 builds

OCF-Linux is a Linux port of the OpenBSD/FreeBSD Cryptographic Framework
(OCF). This port aims to bring full asynchronous HW/SW crypto
acceleration to the Linux kernel and applications running under Linux.
Results have shown improvements of up to 7 times that of software crypto
for bulk crypto throughput using OpenSSL.

At this point in time OCF-Linux provides acceleration for OpenSSL,
OpenSSH (scp, ssh, ...) and also supports the BSD crypto testing
applications. It can accelerate DES, 3DES, AES, MD5, SHA, and Public Key
operations with plans to include Random Number generators and more. This
project is being actively developed as a high performance crypto
solution for embedded devices but also applies equally well to any linux
based server or desktop.

Cheers,
Davidm

-- 
David McCullough, [EMAIL PROTECTED]  Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security   Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Capabilities across execve

2005-03-15 Thread Alexander Nyberg

  This makes it possible for a root-task to pass capabilities to
  nonroot-task across execve. The root-task needs to change it's
  cap_inheritable mask and set prctl(PR_SET_KEEPCAPS, 1) to pass on
  capabilities. 
 
 This overloads keepcaps, which could surprise to existing users.

current-keep_capabilities is set to 0 at each execve, however the
inheritable mask is passed on and therefor also the allowed effective +
permitted. I think this is very necessery if there's ever going to be a
real use of it. It's not worth anything getting a shell with every
capability if every new process you run afterwards will have its
capabilities dropped. If we do like this it will only be useful in
special circumstances when wanting to run _one_ application with some
special capability. The scope can be much more general. How about having
users that can run all the way CAP_SYS_NICE, would give every audio man
his realtime applications. This is certainly possible with capabilities
across execve and pam_cap (using a few caps myself right now).

  At execve time the capabilities will be passed on to the new
  nonroot-task and any non-inheritable effective and permitted
  capabilities will be masked out.
  The effective capability of the new nonroot-task will be set to the
  maximum permitted.
 
 What happens to eff on setuid() to non-root 

If KEEPCAPS is set the permitted and inheritable capabilities are still
there, the effective capabilities are cleared either way. 

 or restore to uid 0?

Full capabilities restored.

 What happens if you exec a setuid-root binary, 

Sets full permitted  effective, inheritable left as is.
This means that if the setuid-root binary does an execve to another
program cap_inheritable will take effect and the capabilities will be
the same as before calling the setuid-root binary. I doubt this is
common scenario however.

 or a setuid-nonroot binary?

capabilities unchanged

 How about ptrace?

I'll look into this part, but I don't see it changing anything here
right now. 

However I'm sure there are cases I've missed and I'm looking for them
right now. This patch is going to need a few good eyes.

 Here's the tests I use.

I've looked at some cases in this test suite but as It doesn't say much
more than begin test 37 I have no idea of how to parse the output.

Updated patch.

= security/commoncap.c 1.15 vs edited =
--- 1.15/security/commoncap.c   2005-01-11 02:29:23 +01:00
+++ edited/security/commoncap.c 2005-03-15 14:45:36 +01:00
@@ -111,13 +111,19 @@ void cap_capset_set (struct task_struct 
 
 int cap_bprm_set_security (struct linux_binprm *bprm)
 {
-   /* Copied from fs/exec.c:prepare_binprm. */
-
-   /* We don't have VFS support for capabilities yet */
-   cap_clear (bprm-cap_inheritable);
-   cap_clear (bprm-cap_permitted);
-   cap_clear (bprm-cap_effective);
+   struct task_struct *p = current;
 
+   /*
+* Mask out the non-inheritable capabilities.
+* Note: init has a zero mask of cap_inheritable, so a root-task will 
not
+* pass on any capabilities unless explicitly told to do so. If a 
non-zero
+* inheritable mask is passed to a positive uid task it will then pass 
on 
+* its inheritable mask to all children unless told otherwise.
+*/
+   bprm-cap_permitted = cap_intersect(p-cap_permitted, 
p-cap_inheritable);
+   bprm-cap_effective = cap_intersect(p-cap_effective, 
p-cap_inheritable);
+   bprm-cap_inheritable = p-cap_inheritable;
+   
/*  To support inheritance of root-permissions and suid-root
 *  executables under compatibility mode, we raise all three
 *  capability sets for the file.
@@ -127,7 +133,7 @@ int cap_bprm_set_security (struct linux_
 */
 
if (!issecure (SECURE_NOROOT)) {
-   if (bprm-e_uid == 0 || current-uid == 0) {
+   if (bprm-e_uid == 0 || p-uid == 0) {
cap_set_full (bprm-cap_inheritable);
cap_set_full (bprm-cap_permitted);
}
@@ -139,13 +145,9 @@ int cap_bprm_set_security (struct linux_
 
 void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
 {
-   /* Derived from fs/exec.c:compute_creds. */
-   kernel_cap_t new_permitted, working;
+   kernel_cap_t new_permitted;
 
new_permitted = cap_intersect (bprm-cap_permitted, cap_bset);
-   working = cap_intersect (bprm-cap_inheritable,
-current-cap_inheritable);
-   new_permitted = cap_combine (new_permitted, working);
 
if (bprm-e_uid != current-uid || bprm-e_gid != current-gid ||
!cap_issubset (new_permitted, current-cap_permitted)) {
@@ -166,14 +168,15 @@ void cap_bprm_apply_creds (struct linux_
current-suid = current-euid = current-fsuid = bprm-e_uid;
current-sgid = current-egid = current-fsgid = bprm-e_gid;
 
-   /* For init, we want to retain the capabilities set
-* in the

Re: Repeatable IDE Oops for 2.6.11 (ide-scsi vs ide-cdrom)

2005-03-15 Thread Bartlomiej Zolnierkiewicz

On Tue, 15 Mar 2005, Alan Cox wrote:
On Maw, 2005-03-15 at 08:19, Bartlomiej Zolnierkiewicz wrote:
On Mon, 14 Mar 2005, Alan Cox wrote:
Locking is fixed in ide-dev-2.6 tree
(at the moment seem to be dropped from -mm?).
Excellent - I'm looking forward to dropping the -ac IDE locking patches
There is still one thing TODO:
* fixing device drivers to refcount driver specific /proc/ide/ entries
  (infrastructure is in-place now)
so don't drop your locking patches yet. :-)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-15 Thread Steven Rostedt



On Tue, 15 Mar 2005, Ingo Molnar wrote:


 * Steven Rostedt [EMAIL PROTECTED] wrote:


  What should we use instead of #ifdef PREEMPT_RT? Or should we just
  keep it the same for both.  Since this fix is only to fix spinlocks
  that schedule, I figured that it would be better not to waste the
  memory of those not using PREEMPT_RT.  Should I use the opposite
  PREEMPT_DESKTOP?

 i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
 would simplify things, besides making PREEMPT_RT simpler as well. The
 memory overhead is not a big issue i believe. (8 more bytes per ext3 bh,
 on x86)


The problem here is that it's not ext3 bh's only. They're still the normal
buffer head.  The problem arrises because the ext3 journal head is
allocated within these bit spin locks. I tried to monkey with putting the
locks in the journal heads and have checks to see when to free them, but
it wasn't that simple. I started having problems with some of the freeing
transactions, I might have assumed too much.

I'll give it one more try to get it into the journal heads, but after
that, (if I fail) I'll let someone who understands the ext3 system better
handle this.

-- Steve

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][2.6.11] drivers/char/isicom.c gcc4 fix

Fix two array-of-incomplete-type errors from gcc4 in isicom.c.

/Mikael

--- linux-2.6.11/drivers/char/isicom.c.~1~  2005-03-02 19:24:15.0 
+0100
+++ linux-2.6.11/drivers/char/isicom.c  2005-03-15 11:37:03.0 +0100
@@ -151,9 +151,6 @@ MODULE_DEVICE_TABLE(pci, isicom_pci_tbl)
 static int prev_card = 3;  /*  start servicing isi_card[0] */
 static struct tty_driver *isicom_normal;
 
-static struct isi_board isi_card[BOARD_COUNT];
-static struct isi_port  isi_ports[PORT_COUNT];
-
 static struct timer_list tx;
 static char re_schedule = 1;
 #ifdef ISICOM_DEBUG
@@ -210,6 +207,9 @@ struct  isi_port {
int xmit_cnt;
 };
 
+static struct isi_board isi_card[BOARD_COUNT];
+static struct isi_port  isi_ports[PORT_COUNT];
+
 /*
  * Locking functions for card level locking. We need to own both
  * the kernel lock for the card and have the card in a position that
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][2.6.11] drivers/net/arcnet/arcnet.c gcc4 fixes

Fix

drivers/net/arcnet/arcnet.c: In function 'release_arcbuf':
drivers/net/arcnet/arcnet.c:256: warning: operation on 'i' may be undefined
drivers/net/arcnet/arcnet.c: In function 'get_arcbuf':
drivers/net/arcnet/arcnet.c:292: warning: operation on 'i' may be undefined

warnings from gcc4 in arcnet.c.

/Mikael

--- linux-2.6.11/drivers/net/arcnet/arcnet.c.~1~2005-03-02 
19:24:16.0 +0100
+++ linux-2.6.11/drivers/net/arcnet/arcnet.c2005-03-15 14:32:49.0 
+0100
@@ -253,7 +253,7 @@ static void release_arcbuf(struct net_de
BUGLVL(D_DURING) {
BUGMSG(D_DURING, release_arcbuf: freed #%d; buffer queue is 
now: ,
   bufnum);
-   for (i = lp-next_buf; i != lp-first_free_buf; i = ++i % 5)
+   for (i = lp-next_buf; i != lp-first_free_buf; i = (i+1) % 5)
BUGMSG2(D_DURING, #%d , lp-buf_queue[i]);
BUGMSG2(D_DURING, \n);
}
@@ -289,7 +289,7 @@ static int get_arcbuf(struct net_device 
 
BUGLVL(D_DURING) {
BUGMSG(D_DURING, get_arcbuf: got #%d; buffer queue is now: , 
buf);
-   for (i = lp-next_buf; i != lp-first_free_buf; i = ++i % 5)
+   for (i = lp-next_buf; i != lp-first_free_buf; i = (i+1) % 5)
BUGMSG2(D_DURING, #%d , lp-buf_queue[i]);
BUGMSG2(D_DURING, \n);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] blockdev: fix for racing mount/umount

2005-03-15 Thread Jeff Mahoney

This patch is another take at fixing the race between mount and umount
resetting the blocksize and causing buffer errors, infinite loops in
__getblk_slow, and possibly other undiscovered effects.

It adds possible flags to bd_claim such that the caller can request
exclusive access and/or wait until the device becomes available. Since bd_claim
already allows/denies access based on the holder, the BD_EXCL flag operates
under the assumption that all callers of bd_claim for a particular holder will
use the flag. This is currently true. BD_WAIT places the request on a wait
queue until access can be granted. It uses a global wait queue, which isn't a
contention point since bd_claim/bd_release both operate under the global
bdev_lock anyway.

Filesystems (via get_sb_bdev) now use BD_EXCL|BD_WAIT to ensure the previous
mount has completely shut down and closed the device before re-opening it
for a new mount. 

It's ugly, and I'm open to suggestions, but it seems to be the only way to
stop this race reliably.

Signed-off-by: Jeff Mahoney [EMAIL PROTECTED]

diff -ruNpX dontdiff linux-2.6.11/fs/block_dev.c linux-2.6.11.bs/fs/block_dev.c
--- linux-2.6.11/fs/block_dev.c 2005-03-14 21:25:20.0 -0500
+++ linux-2.6.11.bs/fs/block_dev.c  2005-03-14 22:17:16.0 -0500
@@ -238,6 +238,7 @@ static int block_fsync(struct file *filp
  */
 
 static  __cacheline_aligned_in_smp DEFINE_SPINLOCK(bdev_lock);
+static DECLARE_WAIT_QUEUE_HEAD(bdev_wq);
 static kmem_cache_t * bdev_cachep;
 
 static struct inode *bdev_alloc_inode(struct super_block *sb)
@@ -443,20 +444,33 @@ void bd_forget(struct inode *inode)
spin_unlock(bdev_lock);
 }
 
-int bd_claim(struct block_device *bdev, void *holder)
+/*
+ * flags:
+ * BD_NONE: No special behavior.
+ * BD_EXCL: Must have sole access to device, even if holder is the same.
+ *  This is really enforced by the holder always using BD_EXCL.
+ * BD_WAIT: Wait until access is available before returning.
+ */
+int __bd_claim(struct block_device *bdev, void *holder, int flags)
 {
int res;
+   DEFINE_WAIT (wait);
+
+retry:
spin_lock(bdev_lock);
+   prepare_to_wait (bdev_wq, wait, TASK_UNINTERRUPTIBLE);
 
/* first decide result */
-   if (bdev-bd_holder == holder)
+   if (bdev-bd_holder == holder) {
res = 0; /* already a holder */
-   else if (bdev-bd_holder != NULL)
+   if (flags  BD_EXCL)
+   res = -EBUSY;
+   } else if (bdev-bd_holder != NULL)
res = -EBUSY;/* held by someone else */
else if (bdev-bd_contains == bdev)
res = 0; /* is a whole device which isn't held */
 
-   else if (bdev-bd_contains-bd_holder == bd_claim)
+   else if (bdev-bd_contains-bd_holder == __bd_claim)
res = 0; /* is a partition of a device that is being 
partitioned */
else if (bdev-bd_contains-bd_holder != NULL)
res = -EBUSY;/* is a partition of a held device */
@@ -470,15 +484,21 @@ int bd_claim(struct block_device *bdev, 
 * be set to bd_claim before being set to holder
 */
bdev-bd_contains-bd_holders ++;
-   bdev-bd_contains-bd_holder = bd_claim;
+   bdev-bd_contains-bd_holder = __bd_claim;
bdev-bd_holders++;
bdev-bd_holder = holder;
+   } else if (flags  BD_WAIT) {
+   spin_unlock (bdev_lock);
+   schedule();
+   goto retry;
}
+
+   finish_wait (bdev_wq, wait);
spin_unlock(bdev_lock);
return res;
 }
 
-EXPORT_SYMBOL(bd_claim);
+EXPORT_SYMBOL(__bd_claim);
 
 void bd_release(struct block_device *bdev)
 {
@@ -488,6 +508,7 @@ void bd_release(struct block_device *bde
if (!--bdev-bd_holders)
bdev-bd_holder = NULL;
spin_unlock(bdev_lock);
+   wake_up_all (bdev_wq);
 }
 
 EXPORT_SYMBOL(bd_release);
@@ -876,7 +897,8 @@ fail:
  * Open the blockdevice described by the special file at @path, claim it
  * for the @holder.
  */
-struct block_device *open_bdev_excl(const char *path, int flags, void *holder)
+struct block_device *__open_bdev_excl(const char *path, int flags,
+  void *holder, int bdflags)
 {
struct block_device *bdev;
mode_t mode = FMODE_READ;
@@ -894,7 +916,7 @@ struct block_device *open_bdev_excl(cons
error = -EACCES;
if (!(flags  MS_RDONLY)  bdev_read_only(bdev))
goto blkdev_put;
-   error = bd_claim(bdev, holder);
+   error = __bd_claim(bdev, holder, bdflags);
if (error)
goto blkdev_put;
 
@@ -905,7 +927,7 @@ blkdev_put:
return ERR_PTR(error);
 }
 
-EXPORT_SYMBOL(open_bdev_excl);
+EXPORT_SYMBOL(__open_bdev_excl);
 
 /**
  * close_bdev_excl  -  release a blockdevice openen by open_bdev_excl()
diff -ruNpX dontdiff linux-2.6.11/fs/super.c

Re: Intel Ethernet PRO 100

2005-03-15 Thread Laurent CARON

shafa.hidee wrote:
Hi All,
   Where we can find specs for writing driver for Intel PRO 100 card.
Regards
Shafahidee
 

already supported.
isn't it?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-mm3 mouse oddity

2005-03-15 Thread Dmitry Torokhov

On Tue, 15 Mar 2005 13:25:12 +0100, Helge Hafting
[EMAIL PROTECTED] wrote:
 2.6.11-mm1 and earlier: mouse appear as /dev/input/mouse0
 2.6.11-mm3: mouse appear as /dev/input/mouse1
 
 No big problem, one change to xorg.conf and I got the mouse back.
 I guess it wasn't supposed to change like that though?


Vojtech activated scroll handling in keyboard code by default so now
your keyboard is mapped to the mouse0 and the mouse moved to mouse1.

Vojtech, is is possible to detect whether a keyboard has scroll
wheel(s) by its ID?

 This is a mouse connected to the ps2 port, also appearing as /dev/psaux
 

I'd recommend using /dev/input/mice unless you want to _exclude_ some
of your input devices. It will get data from all you mice at once and
is always available.

-- 
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Bodo Eggert

(snipped the CC list - hope that's ok)

On Mon, 14 Mar 2005, Albert Cahalan wrote:
 On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
  On Mon, 14 Mar 2005, Albert Cahalan wrote:
   On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:

  NACK, the admin (and with the new inherited capabilities all users with 
  cap_???_override) can see all processes. Only users who don't need to know
  won't see the other user's processes.
 
 Capabilities are too broken for most people to use.

That's being fixed, the new semantics will allow a wrapper.

   Note that the admin hopefully does not normally run as root.
  
  su1 and sudo exist.
 
 This is a pain.

mv ps ps.bin # -+ or just ln -s /usr/bin/us1 ~admin/bin/ps instead
ln -s su1 ps # /
echo $'\nask never\nalias ps /bin/ps\nallow admin prefix ps'  /etc/su1.priv
# ore use * instead of admin, if all users are supposed to see everyone.

Or use the sysctl I described. It won't hurt more than the originally 
suggested flag, and it's much more powerfull.

 Now every user will need sudo access,
 and the sudoers file will have to disable requesting
 passwords so that scripts will work without hassle.

Is sudo _that_ bad? Seems it was a good decision to avoid sudo.

   Even if the admin were not running as a normal user, it is
   expected that normal users can keep tabs on each other.
   The admin may be sleeping. Social pressure is important to
   prevent one user from sucking up all the memory and CPU time.
  
  Privacy is important, too. Imagine each user can see the CEO (or the
  admin) executing ee nakedgirl.jpg.
 
 Obviously, he likes to have users see him do this.
 He'd use a private machine if he wanted privacy.

UNIX and linux are supposed to be a multi-user-systems unlike Win98.
Information leakage is usurally considered {\HUGE BAD}, and some security 
models demand closing all information leakages from privileged users to 
less privileged users. Restricted proc is one more step towards secure 
systems, unless you're depending on peer review.

 Note: I'm the procps (ps, top, w, etc.) maintainer.
 
 Probably I'd have to make /bin/ps run setuid root
 to deal with this. (minor changes needed) The same
 goes for /usr/bin/top, which I know is currently
 unsafe and difficult to fix.
  
  I used unpatched procps 3.1.11, and it worked for me, except pstree.
 
 It does not work correctly.
 
 Look, patches with this feature are called rootkits.
 Think of the headlines: Linux now with built-in rootkit.

Using another PC will hide the processes. Therefore using another PC is 
like using a rootkit. NOT.

Maybe you'll want to print a note about inaccessible proc entries, but 
that's a different issue.

Why do ps and top need to be setuid root to deal with a resticted 
/proc? 
What information in /proc/pid needs to be available to any and 
all 
users?
   
   Anything provided by traditional UNIX and BSD systems
   should be available.
  
  e.g. the buffer overflow in sendmail? Or all the open relays? :)
  
  The demands to security and privacy have increased. Linux should be able 
  to provide the requested privacy.
 
 This really isn't about security.

Information leakage is a security aspect.

 Privacy may be undesirable.

May. That's why I suggested the min/max sysctl.

 With privacy comes anti-social behavior.

With anti-social behavior comes the admin and his LART.

BTW: If the users want to be anti-social, they'll just rename setiathome 
to something like -bash or soffice.

 Supposing that the
 users do get privacy, perhaps because the have paid for it:

Vservers,
 Xen, UML, VM, VMware, separate computers
 
 Going with separate computers is best.

If you like wasting space and energy. If the user's demands don't exceed 
one percent of a historic PC, there is no point in buying more hardware.

 Don't forget to use
 network traffic control to keep users from being able to
 detect the network activity of other users.

Like that:?

$ netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
/proc/net/tcp: Permission denied

   Users who want privacy can get their
   own computer. So, these need to work:
   
   ps [...]
   w
   top
  
  Works as intended. Only pstree breaks, if init isn't visible.
 
 They work like they do with a rootkit installed.
 Traditional behavior has been broken.

They are as broken as finger or ls are if the home directory is chmodded.
-- 
Top 100 things you don't want the sysadmin to say:
13. Ooohh, lovely, it runs SVR4
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PPC64 iSeries: cleanup viopath

2005-03-15 Thread Hollis Blanchard

On Mar 14, 2005, at 9:34 PM, Stephen Rothwell wrote:
Since you brought this file to my attention, I figured I might as well 
do
some simple cleanups.  This patch does:
	- single bit int bitfields are a bit suspect and Anndrew pointed
	  out recently that they are probably slower to access than ints

--- linus/arch/ppc64/kernel/viopath.c	2005-03-13 04:07:42.0 
+1100
+++ linus-cleanup.1/arch/ppc64/kernel/viopath.c	2005-03-15 
14:02:48.0 +1100
@@ -56,8 +57,8 @@
  * But this allows for other support in the future.
  */
 static struct viopathStatus {
-	int isOpen:1;		/* Did we open the path?*/
-	int isActive:1;		/* Do we have a mon msg outstanding */
+	int isOpen;		/* Did we open the path?*/
+	int isActive;		/* Do we have a mon msg outstanding */
 	int users[VIO_MAX_SUBTYPES];
 	HvLpInstanceId mSourceInst;
 	HvLpInstanceId mTargetInst;
Why not use a byte instead of a full int (reordering the members for 
alignment)?

--
Hollis Blanchard
IBM Linux Technology Center
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-mm3 mouse oddity

2005-03-15 Thread Vojtech Pavlik

On Tue, Mar 15, 2005 at 09:25:45AM -0500, Dmitry Torokhov wrote:

 Vojtech activated scroll handling in keyboard code by default so now
 your keyboard is mapped to the mouse0 and the mouse moved to mouse1.
 
 Vojtech, is is possible to detect whether a keyboard has scroll
 wheel(s) by its ID?

If it were, I'd already have used it.

  This is a mouse connected to the ps2 port, also appearing as /dev/psaux
 
 I'd recommend using /dev/input/mice unless you want to _exclude_ some
 of your input devices. It will get data from all you mice at once and
 is always available.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drm lockups since 2.6.11-bk2

2005-03-15 Thread Dave Jones

On Tue, Mar 15, 2005 at 10:38:30AM +, Dave Airlie wrote:
  
  Hi all,
   Andrew Clayton reported lockups on the dri list issues since -bk2
  and bug 4337 on bugzilla.kernel.org looks like it might be the same
  thing..
  
  This leads me to think the AGP multi-bridge patches are at fault... (for
  once my laziness in merging late instead of early gave a good gap in the
  patches...)
  
  I'm offline in sense of I can write this mail and respond but have not
  access to a Linux system, my bitkeeper trees, ssh keys for anywhere of
  interest.. and am in the wrong country, it'll be the 23rd/24th before I am
  back at my desks...
  
  I might get time to do a code review, my main worry is that all the
  problems reported with those patches in -mm made it into the patchset that
  went into Linus.. mainly things like forgetting to memset certain
  structures to 0 and sillies like that...

I saw one report where the recent drm security hole fix broke dri
for one user.  Whilst it seems an isolated incident, could this have
more impact than we first realised ?

Worse case scenario we can drop out the multi-bridge support for now
if it needs work. Mike left SGI now, so we'll need to find someone else
with access to a Prism to make sure it still works correctly on a
real multi-gart system.

Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] net/bluetooth/rfcomm/core.: make a variable static

This patch makes a needlessly global variable static.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-mm3-full/net/bluetooth/rfcomm/core.c.old   2005-03-15 
13:21:50.0 +0100
+++ linux-2.6.11-mm3-full/net/bluetooth/rfcomm/core.c   2005-03-15 
13:22:03.0 +0100
@@ -68,7 +68,7 @@
 #define rfcomm_lock()  down(rfcomm_sem);
 #define rfcomm_unlock()up(rfcomm_sem);
 
-unsigned long rfcomm_event;
+static unsigned long rfcomm_event;
 
 static LIST_HEAD(session_list);
 static atomic_t terminate, running;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: enabling IOAPIC on C3 processor? (how to investigate hangs without nmi watchdog)

2005-03-15 Thread Dave Jones

On Tue, Mar 15, 2005 at 01:52:47PM +0100, jerome lacoste wrote:

  Do I have any alternative to investigate this hang or should I just
  give up and smash my board?

If you have the longhaul cpufreq driver enabled, turn it off.
It's currently broken for some reason, and I've not had time to
figure out why.

Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory


* Andrea Arcangeli [EMAIL PROTECTED] wrote:

  technical comment: seccomp goes outside the audit/selinux framework,
  which i believe is a bug. Andrea?
 
 I intentionally left it out of audit/selinux. To the less dependencies
 it has on other parts of the kernel and the simpler it is, the better
 IMHO. Seccomp should be fixed in stone, people shouldn't go hack on it
 every day.

let me put it another way: this is a security hole. seccomp is now a way
to evade the auditing of read/write syscalls done to an opened file. 
Please fix this.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swsusp_restore crap

2005-03-15 Thread Rafael J. Wysocki

Hi,

On Tuesday, 15 of March 2005 13:02, Pavel Machek wrote:
 Hi!
 
 Please kill that swsusp_restore() call that itself calls
 flush_tlb_global(), it's junk. First, the flush_tlb_global() thing is
 arch specific, and that's all swsusp_restore() does. Then, the asm 
 just
 calls this before returning to C code, so it makes no sense to have a
 hook there. The x86 asm can have it's own call to some arch stuff if 
 it
 wants or just do the tlb flush in asm...

Better, here is a patch... (note: flush_tlb_global() is an x86'ism,
doesn't exist on ppc, thus breaks compile, and that has nothing to do in
the generic code imho, it should be clearly defined as the
responsibility of the asm code).
   
   x86-64 needs this, too Otherwise it looks okay.
  
  It breaks compilation on i386 either, because nr_copy_pages_check
  is static in swsusp.c.  May I propose the following patch instead (tested on
  x86-64 and i386)?
 
 
  +asmlinkage int __swsusp_flush_tlb(void)
  +{
  +   swsusp_restore_check();
 
 Someone will certainly forget this one, and it is probably
 nicer/easier to just move BUG_ON into swsusp_suspend(), just after
 restore_processor_state() or something like that...

... in which case __swsusp_flush_tlb() would only contain a call to
__flush_tlb_global(), but this is a macro on both x86-64 and i386, so we can
drop the __swsusp_flush_tlb() altogether and do it in assembly (before the
GPRs are restored, perhaps).  Patch follows.

Greets,
Rafael


Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]

diff -Nrup linux-2.6.11-bk10-a/arch/i386/power/swsusp.S 
linux-2.6.11-bk10-b/arch/i386/power/swsusp.S
--- linux-2.6.11-bk10-a/arch/i386/power/swsusp.S2005-03-15 
09:20:53.0 +0100
+++ linux-2.6.11-bk10-b/arch/i386/power/swsusp.S2005-03-15 
15:37:25.0 +0100
@@ -51,6 +51,15 @@ copy_loop:
.p2align 4,,7
 
 done:
+   /* Flush TLB, including global things (vmalloc) */
+   movlmmu_cr4_features, %eax
+   movl%eax, %edx
+   andl$~(17), %edx;  # PGE
+   movl%edx, %cr4;  # turn off PGE
+   movl%cr3, %ecx;  # flush TLB
+   movl%ecx, %cr3
+   movl%eax, %cr4;  # turn PGE back on
+
movl saved_context_esp, %esp
movl saved_context_ebp, %ebp
movl saved_context_ebx, %ebx
@@ -58,5 +67,5 @@ done:
movl saved_context_edi, %edi
 
pushl saved_context_eflags ; popfl
-   call swsusp_restore
+
ret
diff -Nrup linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend_asm.S 
linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend_asm.S
--- linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend_asm.S2005-03-15 
09:20:53.0 +0100
+++ linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend_asm.S2005-03-15 
15:36:29.0 +0100
@@ -69,6 +69,14 @@ loop:
movqpbe_next(%rdx), %rdx
jmp loop
 done:
+   /* Flush TLB, including global things (vmalloc) */
+   movq%rax, %rdx;  # mmu_cr4_features(%rip)
+   andq$~(17), %rdx;  # PGE
+   movq%rdx, %cr4;  # turn off PGE
+   movq%cr3, %rcx;  # flush TLB
+   movq%rcx, %cr3
+   movq%rax, %cr4;  # turn PGE back on
+
movl$24, %eax
movl%eax, %ds
 
@@ -89,5 +97,5 @@ done:
movq saved_context_r14(%rip), %r14
movq saved_context_r15(%rip), %r15
pushq saved_context_eflags(%rip) ; popfq
-   callswsusp_restore
+
ret
diff -Nrup linux-2.6.11-bk10-a/kernel/power/swsusp.c 
linux-2.6.11-bk10-b/kernel/power/swsusp.c
--- linux-2.6.11-bk10-a/kernel/power/swsusp.c   2005-03-15 09:21:23.0 
+0100
+++ linux-2.6.11-bk10-b/kernel/power/swsusp.c   2005-03-15 15:35:44.0 
+0100
@@ -900,22 +900,13 @@ int swsusp_suspend(void)
error = swsusp_arch_suspend();
/* Restore control flow magically appears here */
restore_processor_state();
+   BUG_ON (nr_copy_pages_check != nr_copy_pages);
restore_highmem();
device_power_up();
local_irq_enable();
return error;
 }
 
-
-asmlinkage int swsusp_restore(void)
-{
-   BUG_ON (nr_copy_pages_check != nr_copy_pages);
-   
-   /* Even mappings of global things (vmalloc) need to be fixed */
-   __flush_tlb_global();
-   return 0;
-}
-
 int swsusp_resume(void)
 {
int error;

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] sparsemem intro patches

2005-03-15 Thread Martin J. Bligh

The following four patches provide the last needed changes before the
introduction of sparsemem. For a more complete description of what this
will do, please see this patch:

http://www.sr71.net/patches/2.6.11/2.6.11-bk7-mhp1/broken-out/B-sparse-150-sparsemem.patch

I don't know what to think about this. Can you describe sparsemem a little
further, differentiate it from discontigmem and tell us why we want one?
Is it for memory hotplug? If so, how does it support hotplug?

To which architectures is this useful, and what is the attitude of the
relevant maintenance teams?

This isn't just for hotplug by any means. Andy wrote it to get rid of a whole
bunch of different problems, roughly based on some previous work by Dan Phillips
and Dave McCracken (I've added a cc to the actual authors of these patches).
This is the major part of what used to be called CONFIG_NONLINEAR, which we
discussed at last year's kernel summit, and people were pretty enthusiastic
about.

Quoting from the above patch:

Sparsemem replaces DISCONTIGMEM when enabled, and it is hoped that
it can eventually become a complete replacement.
...
This patch introduces CONFIG_FLATMEM. It is used in almost all
cases where there used to be an #ifndef DISCONTIG, because
SPARSEMEM and DISCONTIGMEM often have to compile out the same areas
of code.

Would I be right to worry about increasing complexity, decreased
maintainability and generally increasing mayhem?

Not really - it cleans up the current mess where discontigmem means, and
is used for, two distinct things: 1. the memory is significantly non-contig
in the physical layout. 2. NUMA support.

It also allows us to support discontiguous memory *within* a NUMA node, which
is important for some systems - we can scrap the added complexity of ia64s
vmemmap stuff, for instance.

Whatever your opinions are on mem hotplug, I think we want CONFIG_SPARSEMEM
to clean up the existing mess of discontig - with or without hotplug. I've
wanted this for a very long time, and was dicussing it with Andy at OLS last
year; he came up with a much better, cleaner way to implement it than I had.

It also makes a lot of sense as a foundation for hotplug, which multiple
people seem to want for virtualization stuff.

Anyway, that's what I want it for ;-)

If a competent kernel developer who is not familiar with how all this code
hangs together wishes to acquaint himself with it, what steps should he
take?

Andy, can you explain that further? Maybe also worth checking these are the
correct version of your patches.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[2.6 patch] net/ipv4/inetpeer.c: make a struct static

This patch makes a needlessly global struct static.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-mm3-full/net/ipv4/inetpeer.c.old   2005-03-15 
13:29:32.0 +0100
+++ linux-2.6.11-mm3-full/net/ipv4/inetpeer.c   2005-03-15 13:30:13.0 
+0100
@@ -92,9 +92,9 @@
 int inet_peer_minttl = 120 * HZ;   /* TTL under high load: 120 sec */
 int inet_peer_maxttl = 10 * 60 * HZ;   /* usual time to live: 10 min */
 
+static struct inet_peer *inet_peer_unused_head;
 /* Exported for inet_putpeer inline function.  */
-struct inet_peer *inet_peer_unused_head,
-   **inet_peer_unused_tailp = inet_peer_unused_head;
+struct inet_peer **inet_peer_unused_tailp = inet_peer_unused_head;
 DEFINE_SPINLOCK(inet_peer_unused_lock);
 #define PEER_MAX_CLEANUP_WORK 30
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] net/ipv6/ndisc.c: make a function static

This patch makes a needlessly global function static.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-mm3-full/net/ipv6/ndisc.c.old  2005-03-15 13:33:29.0 
+0100
+++ linux-2.6.11-mm3-full/net/ipv6/ndisc.c  2005-03-15 13:34:03.0 
+0100
@@ -1594,10 +1594,11 @@
return ret;
 }
 
-int ndisc_ifinfo_sysctl_strategy(ctl_table *ctl, int __user *name, int nlen,
-void __user *oldval, size_t __user *oldlenp,
-void __user *newval, size_t newlen,
-void **context)
+static int ndisc_ifinfo_sysctl_strategy(ctl_table *ctl, int __user *name,
+   int nlen, void __user *oldval,
+   size_t __user *oldlenp,
+   void __user *newval, size_t newlen,
+   void **context)
 {
struct net_device *dev = ctl-extra1;
struct inet6_dev *idev;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] net/core/pktgen.c: make a function static

pktgen_xmit is already inline but not static.

This doesn't make much sense - especially since there's no external user 
of this function.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-mm3-full/net/core/pktgen.c.old 2005-03-15 13:25:04.0 
+0100
+++ linux-2.6.11-mm3-full/net/core/pktgen.c 2005-03-15 13:25:20.0 
+0100
@@ -2587,7 +2587,7 @@
 thread_unlock();
 }
 
-__inline__ void pktgen_xmit(struct pktgen_dev *pkt_dev)
+static inline void pktgen_xmit(struct pktgen_dev *pkt_dev)
 {
struct net_device *odev = NULL;
__u64 idle_start = 0;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Andrea Arcangeli

On Tue, Mar 15, 2005 at 03:44:28PM +0100, Ingo Molnar wrote:
 let me put it another way: this is a security hole. seccomp is now a way
 to evade the auditing of read/write syscalls done to an opened file. 
 Please fix this.

This is not true, the auditing of read/write will work fine on the
seccomp task too. I guess you overlooked something in the code.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory


* Andrea Arcangeli [EMAIL PROTECTED] wrote:

 This is not true, the auditing of read/write will work fine on the
 seccomp task too. I guess you overlooked something in the code.

yeah, you are right - it's there. You are driving seccomp off
do_syscall_trace(), which does audit_syscall_entry().

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] seccomp: don't say it was more or less mandatory


* Andrea Arcangeli [EMAIL PROTECTED] wrote:

  which quite likely wont be provable in the foreseeable future).
 
 Please mention a _single_ bug that could allow you to escape the
 seccomp jail in linux since 2.4.0 on x86 and x86-64 (and with escape I
 don't mean sniffing data with mmx not being backwards compatible, or
 f00f DoS, I mean executing code into the host as user nobody). I'm not
 aware of a _single_ seccomp bug that could allow you to escape the
 seccomp jail since 2.4.0 and probably much earlier.

ugh? Where do i claim any such thing?

while we are at it, please mention a single ptrace bug in the same
timeframe that could allow a bytecode 'client' to escape a ptrace
TRACE_SYSCALL jail at will.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.11-mm3: megaraid_sas.c: stack usage