Re: UDF madness

[Al Viro]

On Wed, Jan 26, 2005 at 08:11:41PM -0800, Andrew Morton wrote:
> Yes, me too.  generic_shutdown_super() takes lock_super().  And udf uses
> lock_super for protecting its block allocation data strutures.  Trivial
> deadlock on unmount.
> 
> Filesystems really shouldn't be using lock_super() for internal purposes,
> and the main filesystems have been taught to not do that any more, but UDF
> is a holdout.
> 
> It seems that this deadlock was introduced on Jan 5 by the "udf: fix
> reservation discarding" patch which added the udf_discard_prealloc() call
> into udf_clear_inode().  The below dopey patch prevents the deadlock, but
> perhaps we can think of something more appealing.  Ideally, use a new lock
> altogether?

AFAICS, we probably could kill lock_super() in generic_shutdown_super().

Note that all callers of lock_super() in VFS hold ->s_umount and
generic_shutdown_super() is called with ->s_umount held exclusively.
And internal fs code doing it at that point == guaranteed deadlock like
UDF one, unless we abuse it as synchronization mechanism for per-fs kernel
thread.
Note that fs users of file_fsync() are definitely not going to be
involved into contention here - they need opened file => held active
reference to superblock.
So we are left only with fs-internal asynchronous callers of
lock_super().  UDF, UFS, sysv, hpfs and ext2 are out of question - they
don't have async callers of that sort.  ext3... maybe, I'm not familiar
with resize code in there.  In any case, that'd better be fixed in
ext3 if such abuse exists.

I really wonder if we need lock_super() in VFS callers - or at all,
since fs-internal stuff would better be handled by fs-private sempahores.
The only real use is to give exclusion between VFS-triggered ->write_super()
and fs-internal uses (in a handful of filesystems).  Could as well use
fs-private semaphore and grab/release it in ->write_super() of that fs...
Another suspect is ->s_flags protection - that one is going to get messy
as hell, since lock_super() is certainly not held in many places that change
->s_flags...
-
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: [BUG] 2.6.11-rc2 ALSA

[Jaroslav Kysela]

On Wed, 26 Jan 2005, Andrew Morton wrote:

> Hello list,
> after upgrading to 2.6.11-rc2 my soundcard doesn't work anymore:
> 
> I get this message during initialization of ALSA:
> 
> /usr/sbin/alsactl: set_control:805: warning: name mismatch (External 
> Amplifier/Headphone Jack Sense) for control #26
> 
> The soundcard is integrated on my thinkpad centrino notebook (R50), lspci 
> reports this:
> 
> Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
> AC'97 Audio Controller (rev 01)
> 
> If I boot back to 2.6.10 the PCM control has the volume set to zero, but 
> readjusting it to a normal value brings everything back to normal.

It's probably already fixed in our CVS and ALSA BK tree:

=
revision 1.69
date: 2005/01/17 13:47:20;  author: tiwai;  state: Exp;  lines: +14 -2
Summary: Fix silent output on some machines with AD1981x codecs

Fixed the default state of "Headphone Jack Sense" switch on AD1981x
codecs.  Setting this on affects the output of some machines (e.g.
Thindpads).

The default value is set on only hardwares which are known to work.
=

Jaroslav

-
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
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/

[ALSA PATCH] Intel HDA driver

[Jaroslav Kysela]

Linus, please do a

  bk pull http://linux-sound.bkbits.net/linux-sound

The GNU patch is available at:

  ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-bk-2005-01-26.patch.gz

Additional notes:

  - added Intel HDA driver (Azalia) - snd-hda-intel module
  - added support for compat/unlocked f_ops ioctl callbacks
  - removed obsolete sound/core/ioctl32 code
  - other small fixes

The pull command will update the following files:

 sound/core/ioctl32/Makefile  |   11 
 sound/core/ioctl32/hwdep32.c |   73 
 sound/core/ioctl32/ioctl32.c |  433 --
 sound/core/ioctl32/ioctl32.h |  102 
 sound/core/ioctl32/pcm32.c   |  464 --
 sound/core/ioctl32/rawmidi32.c   |   91 
 sound/core/ioctl32/seq32.c   |  116 
 sound/core/ioctl32/timer32.c |  105 
 Documentation/sound/alsa/ALSA-Configuration.txt  |   33 
 Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl |   29 
 Documentation/sound/alsa/VIA82xx-mixer.txt   |8 
 Documentation/sound/alsa/hda_codec.txt   |  299 +
 include/sound/ak4117.h   |6 
 include/sound/control.h  |7 
 include/sound/hwdep.h|1 
 sound/core/Kconfig   |   14 
 sound/core/Makefile  |1 
 sound/core/control.c |  176 -
 sound/core/control_compat.c  |  412 ++
 sound/core/hwdep.c   |   25 
 sound/core/hwdep_compat.c|   77 
 sound/core/init.c|2 
 sound/core/ioctl32/ioctl32.c |5 
 sound/core/ioctl32/pcm32.c   |3 
 sound/core/memory.c  |4 
 sound/core/oss/mixer_oss.c   |   21 
 sound/core/oss/pcm_oss.c |   22 
 sound/core/pcm.c |2 
 sound/core/pcm_compat.c  |  513 +++
 sound/core/pcm_memory.c  |2 
 sound/core/pcm_native.c  |   37 
 sound/core/rawmidi.c |   34 
 sound/core/rawmidi_compat.c  |  120 
 sound/core/seq/oss/seq_oss.c |   21 
 sound/core/seq/oss/seq_oss_midi.c|2 
 sound/core/seq/oss/seq_oss_synth.c   |2 
 sound/core/seq/seq_clientmgr.c   |   20 
 sound/core/seq/seq_compat.c  |  137 
 sound/core/seq/seq_queue.c   |2 
 sound/core/sound.c   |4 
 sound/core/timer.c   |   25 
 sound/core/timer_compat.c|  119 
 sound/drivers/vx/vx_core.c   |   13 
 sound/drivers/vx/vx_hwdep.c  |1 
 sound/isa/gus/gus_pcm.c  |1 
 sound/isa/gus/gus_reset.c|7 
 sound/isa/sb/emu8000.c   |4 
 sound/isa/wavefront/wavefront_synth.c|1 
 sound/pci/Kconfig|   12 
 sound/pci/Makefile   |1 
 sound/pci/ac97/ac97_codec.c  |   73 
 sound/pci/ac97/ac97_local.h  |6 
 sound/pci/ac97/ac97_patch.c  |   26 
 sound/pci/atiixp.c   |6 
 sound/pci/atiixp_modem.c |   23 
 sound/pci/hda/Makefile   |7 
 sound/pci/hda/hda_codec.c| 1731 +++
 sound/pci/hda/hda_codec.h|  602 +++
 sound/pci/hda/hda_generic.c  |  898 +
 sound/pci/hda/hda_intel.c| 1455 +
 sound/pci/hda/hda_local.h|  159 +
 sound/pci/hda/hda_patch.h|   14 
 sound/pci/hda/hda_proc.c |  298 +
 sound/pci/hda/patch_cmedia.c |  614 +++
 sound/pci/hda/patch_realtek.c  

Re: /proc parent _root == NULL?

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



[EMAIL PROTECTED] wrote:
> On Thu, 27 Jan 2005 01:51:05 EST, John Richard Moser said:
> 
> 
>>mmm.  I'd thought about that actually-- for modules to get a whack at
>>this they'd have to be compiled in.  Loaded as modules would break the
>>security.
> 
> 
> And that, my friends, is *exactly* why SELinux can't be built as a module ;)

:) So far my little grkernsec module hasn't hit any bumps like that;
though so far I haven't copied much of spender's code.  I'm sure the
chroot() restrictions will easily be make for a loadable module.

At this point, I should be making more important design decisions.  For
example, why am I still doing this?  Isn't there something better for me
to do than clone LSM and GrSecurity, attempt (*cough*) to improve on the
original designs, and then harass kernel devs about problems I'm having
with things that are just meant to be toys for me anyway?


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+JuehDd4aOud5P8RAg+WAJ451ls4FIMG0wm/r3pa/dPpcasRugCeP5j9
be2STVV+vC2B1ScYYQNmMY0=
=IjCv
-END PGP SIGNATURE-
-
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 patch] kernel-api.sgml references removed file net_init.c

[David S. Miller]

On Mon, 24 Jan 2005 20:36:24 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:

> This patch by Jesper Juhl is still required in 2.6.11-rc2-mm1.

Applied, thanks for reposting Adrian.
-
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: confguring grub to load new kernel

[Andy liu]

[EMAIL PROTECTED] wrote:
Hi,
I just compiled kernel 2.6.10 and now wondering how to make the grub to
load the newkernel.
The grub.conf file is configured as:
#boot=/dev/hda
default=1
timeout=10
splashimage=(hd0,5)/boot/grub/splash.xpm.gz
title Red Hat Linux (2.4.20-8)
   root (hd0,5)
   kernel /boot/vmlinuz-2.4.20-8 ro root=LABEL=/
   initrd /boot/initrd-2.4.20-8.img
title DOS
   rootnoverify (hd0,0)
   chainloader +1
   
   
How should I change the configuration?

sudhir

mail2web - Check your email from the web at
http://mail2web.com/ .
-
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/
 

by the way,have you update your module utility?
kernel module format has changed in linux 2.6,so do not forget to update 
insmod lsmod modprobe...
-
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-rc2] kernel BUG at fs/reiserfs/prints.c:362

[Sergey S. Kostyliov]

Hello all,

Here is a BUG() I've just hited on quota enabled reiserfs disk.

[EMAIL PROTECTED] rathamahata $ mount | grep /dev/sdb2
/dev/sdb2 on /var/www type reiserfs 
(rw,noatime,nodiratime,data=writeback,grpquota,usrquota)
[EMAIL PROTECTED] rathamahata $

REISERFS: panic (device sdb2): journal_begin called without kernel lock held
[ cut here ]
kernel BUG at fs/reiserfs/prints.c:362!
invalid operand:  [#1]
PREEMPT SMP
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010296   (2.6.11-rc2)
EIP is at reiserfs_panic+0x4b/0x80
eax: 0050   ebx: c02b75b2   ecx: f7fe4270   edx: f1034e38
esi: f7543600   edi: f7543770   ebp: 00f2   esp: f1034e34
ds: 007b   es: 007b   ss: 0068
Process qmail-local (pid: 10803, threadinfo=f1034000 task=cc440a60)
Stack: c02bbb00 f7543770 c03b89c0 f7543600 f1034ecc f89af000 c01a8a0e f7543600
   c02bcf20 c02b7db8 c01ac186 f74b66c0 00f2 f1034ecc c0167403 f74b6900
   c02f2740 fff4 f74b6960 00295e98 c01679dc 00295e98 f74b6090 f74b66c0
Call Trace:
 [] reiserfs_check_lock_depth+0x2e/0x30
 [] do_journal_begin_r+0x26/0x2d0
 [] d_alloc+0x133/0x180
 [] __d_lookup+0x11c/0x130
 [] journal_begin+0x61/0xf0
 [] reiserfs_dquot_initialize+0x25/0x60
 [] link_path_walk+0x48d/0xd20
 [] permission+0x76/0xa0
 [] vfs_create+0xc8/0x110
 [] open_namei+0x57f/0x5d0
 [] filp_open+0x2d/0x60
 [] get_unused_fd+0x94/0xc0
 [] getname+0x67/0xb0
 [] sys_open+0x3c/0x80
 [] sysenter_past_esp+0x52/0x75
Code: 8d be 70 01 00 00 e8 a5 fd ff ff c7 04 24 00 bb 2b c0 85 f6 89 d8 0f 45 
c7 ba c0 893b c0 89 54 24 08 89 44 24 04 e8 25 9d f7 ff <0f> 0b 6a 01 1a 7b 2b 
c0 c7 04 24 40 bb 2b c0 85 f6 be c0 89 3b
 <0>REISERFS: panic (device sdb2): journal_begin called without kernel lock held
[ cut here ]

-- 
Sergey S. Kostyliov <[EMAIL PROTECTED]>
Jabber ID: [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: how to check the validity of a running daemon on Linux

[Valdis . Kletnieks]

On Thu, 27 Jan 2005 15:33:49 +1300, ych43 said:

>   Does anybody know how to check the validity of a deamon. which runs on 
> Linux 
> -platform host . This daemon can save some information in a log file of the 
> host. I mean that if an attacker compromises this host and gets root access, 
> he can replace this daemon with a rogue version. Therfefore, the information 
> saved on the log file is incorrect. So how can I check the validity of the 
> daemon to show this  daemon is correct version and not a rogue version. So I 
> trust the information saved on the host.

If you trust your kernel, there's several ways:

1) There's Tripwire and Aide (http://aide.sf.net) for cronjob-style checking
of your system.

2) There's the DigSig patches, and Fedora kernels have a 'modsign' patch, both 
of
which use digital signatures checked at exec() time to prevent tampering.  I
haven't checked whether either of those will detect the case of subverting the
daemon by means of code that's actually in some libshared.so rather than
modifying the daemon binary itself.

If you don't trust your kernel (for instance, if you suspect that the attacker
has loaded a kernel module that hides his activities - building your kernel
without module support does *NOT*, repeat *NOT* stop this attack), your only
choice is to boot from known trusted media (a CD-based rescue disk or Knoppix
or similar) and compare the binary that's on your system to a "known good"
copy on the CD.

This of course requires that you trust your system BIOS.  If you don't trust
that, you're on your own.  I hear tin foil is on sale down at the local market 
;)


pgpzLoArcGpuK.pgp
Description: PGP signature

Re: confguring grub to load new kernel

[Valdis . Kletnieks]

On Thu, 27 Jan 2005 12:43:34 +0530, Sabarinathan said:

> Put this entry in your grub.conf file
> 
> title Red Hat Linux  (2.6.10)
> root (hd0,5)
> kernel /boot/vmlinuz-2.6.10 ro root=LABEL=/ rhgb quiet
> initrd /boot/initrd-2.6.10.img

And *DONT* remove this one:

> >title Red Hat Linux (2.4.20-8)
> >root (hd0,5)
> >kernel /boot/vmlinuz-2.4.20-8 ro root=LABEL=/
> >initrd /boot/initrd-2.4.20-8.img

So if you screwed up your 2.6.10 (did you remember to upgrade to
module-init-tools, and udev if you need it, and any other userspace
upgrades you need?) you can boot back to 2.4 easily and fix what you broke
or failed to upgrade


pgpoP4JXilkFJ.pgp
Description: PGP signature

Re: Deadlock in serial driver 2.6.x

[Andrew Morton]

Martin Kögler <[EMAIL PROTECTED]> wrote:
>
> I noticed with different kernel versions (a 2.6.5 FC2 Kernel, a 2.6.7 Knoppix 
> Kernel
>  and 2.6.10 FC2 and FC3 Kernels (which have no patches for the serial 
> driver)), that it 
>  is possible for a normal user, which has rw access to /dev/ttySx, to hang a 
> computer.
>  To exploit it, there must be a device on the other end on the serial line, 
> which sends 
>  some data.
> 
>  I tested it on a i686 machine.
> 
>  At http://www.auto.tuwien.ac.at/~mkoegler/linux/serial_oops.c , I have an 
> example programm,
>  which exploits the problem (/dev/ttyS0 is hardcoded as serial device).
> 
>  To trigger the problem, connect two computers with a null modem cable and 
> send some
>  characters to the programm (The baud rate at the other computer seems to be 
> not important).
> 
>  With SMP-Kernels, the computer stops responding.
>  Kernels without SMP print a panic message before they stop working, eg:
>  Kernel panic - not syncing: drivers/serial/serial_core.c:103: 
> spin_lock(drivers/serial/serial_core.c:c04055e0) already locked  by 
> drivers/serial/8250.c/1170
> 
>  Photos of a panic messages of a FC3 2.6.10-1.741_FC3 Kernel are available at 
>  http://www.auto.tuwien.ac.at/~mkoegler/linux .
> 
>  What the programm does:
>  It sets the low latency mode, then waiting, until a certain state of the 
> handshake 
>  lines is reached, then it sends a bytes and waits for a byte. Then it 
> changes the 
>  handshake lines again and the process starts again.

Yes, I get a similar deadlock:

 [] show_regs+0x11f/0x12c
 [] sysrq_handle_showregs+0x10/0x18
 [] __handle_sysrq+0x76/0x120  
 [] handle_sysrq+0x1d/0x24   
 [] kbd_keycode+0x105/0x2c8
 [] kbd_event+0x84/0xbc
 [] input_event+0x398/0x3bc
 [] atkbd_report_key+0x3e/0x64
 [] atkbd_interrupt+0x46b/0x4e8
 [] serio_interrupt+0x39/0x69  
 [] i8042_interrupt+0x1f7/0x20c
 [] handle_IRQ_event+0x2d/0x64 
 [] __do_IRQ+0xf7/0x154   
 [] do_IRQ+0x1e/0x34   
 [] common_interrupt+0x1a/0x20
 [] uart_start+0x19/0x34  
 [] uart_flush_chars+0xc/0x10
 [] n_tty_receive_buf+0x104d/0x10f8
 [] flush_to_ldisc+0xe1/0xf4   
 [] tty_flip_buffer_push+0x15/0x34
 [] receive_chars+0x1fc/0x210 
 [] serial8250_interrupt+0x63/0xe0
 [] handle_IRQ_event+0x2d/0x64
 [] __do_IRQ+0xf7/0x154   
 [] do_IRQ+0x1e/0x34   
 [] common_interrupt+0x1a/0x20

(For some reason the NMI watchdog isn't triggering here, and it's still
taking interrupts).

  serial8250_interrupt() takes uart_8250_port.port.lock
  ->serial8250_handle_port
->receive_chars
  ->tty_flip_buffer_push (->low_latency is true)
->flush_to_ldisc
  ->n_tty_receive_buf

(this takes tty->read_lock inside uart_8250_port.port.lock. Is
 this ranking correct?)

->uart_flush_chars
  ->uart_start

Does spin_lock_irqsave(>lock, flags);


Looks like low-latency mode is busted.

-
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/

[ppc] 2.6.10: undefined symbols in modules.

[PaweÅ Sikora]

Hi,

During kernel build I get these link errors:

(...)
  Building modules, stage 2.
  MODPOST
*** Warning: "vgacon_remap_base" [drivers/video/vga16fb.ko] undefined!
*** Warning: "isa_virt_to_bus" [drivers/mmc/wbsd.ko] undefined!
*** Warning: "pci_get_legacy_ide_irq" [drivers/ide/pci/amd74xx.ko] undefined!
(...)

Regards,
PaweÅ.

-- 
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

   #define say(x) lie(x)
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-0.102
# Wed Jan 26 13:44:42 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor
#
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_E500 is not set
CONFIG_ALTIVEC=y
CONFIG_TAU=y
# CONFIG_TAU_INT is not set
# CONFIG_TAU_AVERAGE is not set
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_PROC_INTF=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=m
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_24_API is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_PMAC=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_PPC601_SYNC_FIX is not set
CONFIG_PM=y
CONFIG_PPC_STD_MMU=y

#
# Platform options
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_APUS is not set
# CONFIG_WILLOW is not set
# CONFIG_PCORE is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_EV64260 is not set
# CONFIG_SPRUCE is not set
# CONFIG_LOPEC is not set
# CONFIG_MCPN765 is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
# CONFIG_SANDPOINT is not set
# CONFIG_ADIR is not set
# CONFIG_K2 is not set
# CONFIG_PAL4 is not set
# CONFIG_GEMINI is not set
# CONFIG_EST8260 is not set
# CONFIG_SBC82xx is not set
# CONFIG_SBS8260 is not set
# CONFIG_RPX8260 is not set
# CONFIG_TQM8260 is not set
# CONFIG_ADS8272 is not set
# CONFIG_LITE5200 is not set
CONFIG_PPC_CHRP=y
CONFIG_PPC_PMAC=y
CONFIG_PPC_PREP=y
CONFIG_PPC_OF=y
CONFIG_PPCBUG_NVRAM=y
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
CONFIG_HIGHMEM=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_PREP_RESIDUAL is not set
# CONFIG_CMDLINE_BOOL is not set

#
# Bus options
#
# CONFIG_ISA is not set
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y

#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
# CONFIG_PCMCIA_OBSOLETE is not set
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_TCIC=m

#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set

#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE=0x3000
CONFIG_KERNEL_START=0xc000
CONFIG_TASK_SIZE=0x8000
CONFIG_BOOT_LOAD=0x0080

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CONCAT=m
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
CONFIG_INFTL=m

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 

Re: confguring grub to load new kernel

[Sabarinathan]

Hi,
Put this entry in your grub.conf file
title Red Hat Linux  (2.6.10)
   root (hd0,5)
   kernel /boot/vmlinuz-2.6.10 ro root=LABEL=/ rhgb quiet
   initrd /boot/initrd-2.6.10.img
[EMAIL PROTECTED] wrote:
Hi,
I just compiled kernel 2.6.10 and now wondering how to make the grub to
load the newkernel.
The grub.conf file is configured as:
#boot=/dev/hda
default=1
timeout=10
splashimage=(hd0,5)/boot/grub/splash.xpm.gz
title Red Hat Linux (2.4.20-8)
   root (hd0,5)
   kernel /boot/vmlinuz-2.4.20-8 ro root=LABEL=/
   initrd /boot/initrd-2.4.20-8.img
title DOS
   rootnoverify (hd0,0)
   chainloader +1
   
   
How should I change the configuration?

sudhir

mail2web - Check your email from the web at
http://mail2web.com/ .
-
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/
 


--
Regards
Sabarinathan.A 
Trustix Os Programmer
Comodo India - "Invent ² Secure"
Temple Towers, Chennai
Mobile: 98403 66039

Registered Linux User: #376656



-
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: /proc parent _root == NULL?

[Valdis . Kletnieks]

On Thu, 27 Jan 2005 01:51:05 EST, John Richard Moser said:

> mmm.  I'd thought about that actually-- for modules to get a whack at
> this they'd have to be compiled in.  Loaded as modules would break the
> security.

And that, my friends, is *exactly* why SELinux can't be built as a module ;)


pgpmnYP6IsBRb.pgp
Description: PGP signature

dmesg command output

[cranium2003]

Hello,
  How to get max output from dmesg command.I have
inserted a lot debug messages to check kernel trace
and now want to get nearly all output from dmesg since
linux startup.Is that possible? or at least can
anybody help to have dmesg give max output. On my RH9
i386 arch i got 16kb output from dmesg. how to
increase it?
reagrds,
cranium.




__ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 
-
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: How to add/drop SCSI drives from within the driver?

['Patrick Mansfield']

[moving to hotplug list ...]

On Wed, Jan 26, 2005 at 06:23:16PM -0500, Mukker, Atul wrote:

> Or more likely, by placing our agent in /etc/dev.d directory. Unfortunately,
> there seems be not a consensus here as well. On system has "default" and
> "net" directories and other has "block", "input", "net", "tty"?

Those are all kernel subsystem names, and as such all are supported
directory structures for udev, the part that is distro specific is that
they supply different scripts.

There won't be any "scsi" devices since they have no dev (the upper level
drivers have them); sg shows up as scsi_generic. sd is block.

You will still have to figure out via sysfs if you want to run your agent
even for subsystem block (i.e. figure out the host/driver type, I assume
you don't want to run it on hd or standard scsi disk drives).

I don't know why this is an issue for "new" devices, this should be a
problem for you when they first show up; existing and new devs should be
handled the same way.

-- Patrick Mansfield
-
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] add AMD NS 5535 support

[Dan Malek]

Hi Marcelo.
This patch for 2.4 adds support for the AMD / National
Semiconductor CS5535 chip set.  Provided by AMD
as part of the Geode support.
Signed-off-by:  Dan Malek <[EMAIL PROTECTED]>



amdns_5535.patch
Description: Binary data

Re: /proc parent _root == NULL?

[Valdis . Kletnieks]

On Thu, 27 Jan 2005 01:40:12 EST, [EMAIL PROTECTED] said:

> You may want to use a properly timed initcall() to create a callback that
> happens after proc_misc_init() happens, but before userspace gets going, and
> walk through the /proc tree at that time and cache info on the files you care
> about, so you don't have to re-walk /proc every time permission() gets called

Blarg.

The proper time to walk the /proc filesystem and cache such info, is, of
course, in the ->sp_post_addmount() LSM hook.  Check @mnt and @mountpoint_nd to
see if it's /proc, and if so, go snarf all the info you need to make your tests
fast..

Not sure if you'd need to redo your cache in sp_post_remount(), for the odd case
where /proc gets remounted



pgpxDYSMS8sse.pgp
Description: PGP signature

[PATCH] add AMD Geode processor support

[Dan Malek]

Hi Marcelo!
Here is a patch for 2.4 that adds the basic AMD Geode GX2/GX3
and GX1/SC1200 support.  This patch updates configuration
scripts, defconfig, and setup files.
Signed-off-by: Dan Malek <[EMAIL PROTECTED]>


geode_x86.patch
Description: Binary data

Re: /proc parent _root == NULL?

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



[EMAIL PROTECTED] wrote:
> On Wed, 26 Jan 2005 22:35:18 EST, John Richard Moser said:
> 
> 
>>This particular problem pertains to proc_misc.c and trying to create a
>>hook for some grsecurity protections that alter the modes on certain
>>/proc entries.  The chunk of the patch I'm trying to immitate is:
> 
> 
>>+#ifdef CONFIG_GRKERNSEC_PROC_ADD
>>+   create_seq_entry("cpuinfo", gr_mode, _cpuinfo_operations);
>>+#else
>>create_seq_entry("cpuinfo", 0, _cpuinfo_operations);
>>+#endif
> 
> 
> An alternate way to approach this - leave the permissions alone here.
> 
> And then use the security_ops->inode_permission() hook to do something like:
> 
>   if ((inode == cpuinfo) && (current->fsuid))
>return -EPERM;
> 
> Writing the proper tests for whether it's the inode you want and whether to
> give the request the kiss-of-death are left as an excersize for the 
> programmer.. ;)
> 
> You may want to use a properly timed initcall() to create a callback that
> happens after proc_misc_init() happens, but before userspace gets going, and
> walk through the /proc tree at that time and cache info on the files you care
> about, so you don't have to re-walk /proc every time permission() gets 
> called

mmm.  I'd thought about that actually-- for modules to get a whack at
this they'd have to be compiled in.  Loaded as modules would break the
security.

Perhaps both.  I could give modules a "Hook" that gave them a crack at
/proc on load, as well as put a hook in *read**read**read**read*
proc_permission()?  (I wrote one there already!  :)

Also, before it expires

http://rafb.net/paste/results/tZ5Jp878.html

Nice for a simple learning excercise huh?  Modules aren't aware of
stacking, and there's no mandatory dummy code (a la security/dummy.c);
but each hook calls a function that does a loop (based on a C99 variadic
macro) through things, so the lack of a dummy module is kind of offset.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+I9ZhDd4aOud5P8RAvDyAJ9m7KLA9+KzLg2colO3uhRXaxzOXACfQekQ
eHDZYuZ33Qtbz9q0fgaUhmw=
=k7kW
-END PGP SIGNATURE-
-
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: critical bugs in md raid5

[pcg]

On Thu, Jan 27, 2005 at 06:11:34AM +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Marc Lehmann <[EMAIL PROTECTED]> writes:
> >
> > The summary seems to be that the linux raid driver only protects your data
> > as long as all disks are fine and the machine never crashes.
> 
> "as long as the machine never crashes". That's correct. If you think

Thanks for your thoughts, btw :)

I forgot to mention that even if data is known to be lost it's much better
to return, say, EIO to higher levels than to completely shut down the
device (after all, this is no differnce to what other block devices behave).

Also, it's still likely that some old error can be repaired, as the broken
non-parity block might be old. This is probably better to be handled in
userspace, though, with special tools. But for them it might be vital to
get the correct disk index, to be able to detect the stripe layout.

It's usually much faster to repair and verify, as opposed to format and
restore, of course.

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
-
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: /proc parent _root == NULL?

[Valdis . Kletnieks]

On Wed, 26 Jan 2005 22:35:18 EST, John Richard Moser said:

> This particular problem pertains to proc_misc.c and trying to create a
> hook for some grsecurity protections that alter the modes on certain
> /proc entries.  The chunk of the patch I'm trying to immitate is:

> +#ifdef CONFIG_GRKERNSEC_PROC_ADD
> +   create_seq_entry("cpuinfo", gr_mode, _cpuinfo_operations);
> +#else
> create_seq_entry("cpuinfo", 0, _cpuinfo_operations);
> +#endif

An alternate way to approach this - leave the permissions alone here.

And then use the security_ops->inode_permission() hook to do something like:

if ((inode == cpuinfo) && (current->fsuid))
 return -EPERM;

Writing the proper tests for whether it's the inode you want and whether to
give the request the kiss-of-death are left as an excersize for the 
programmer.. ;)

You may want to use a properly timed initcall() to create a callback that
happens after proc_misc_init() happens, but before userspace gets going, and
walk through the /proc tree at that time and cache info on the files you care
about, so you don't have to re-walk /proc every time permission() gets 
called


pgpbUiHxJ6hPa.pgp
Description: PGP signature

Re: Bug in 2.4.26 in mm/filemap.c when using RLIMIT_RSS

[Ake]

On Wed, Jan 26, 2005 at 12:49:04PM -0200, Marcelo Tosatti wrote:
> > There is also a misinformative comment in fs/proc/array.c
> > in proc_pid_stat where it says
> > mm ? mm->rss : 0, /* you might want to shift this left 3 */
> > the number 3 should probably be PAGE_SHIFT-10.

Don't forget the comment (it's still there in 2.6) :-)

> Amazing that this has never been noticed before - I bet not many people use 
> RSS 
> limits with madvise().

Neither do we. :-)

I just found it when trying to figure out if the kernel actually used
any of the rlimits and if so how.
(Trying to make PBS work correctly)

> This transform the rlimit in pages before the comparison, can you please test
> it.
> 
> --- a/mm/filemap.c.orig   2004-11-17 09:54:22.0 -0200
> +++ b/mm/filemap.c2005-01-26 15:21:10.614842296 -0200
> @@ -2609,6 +2609,9 @@
>   error = -EIO;
>   rlim_rss = current->rlim ?  current->rlim[RLIMIT_RSS].rlim_cur :
>   LONG_MAX; /* default: see resource.h */
> +
> + rlim_rss = (rlim_rss & PAGE_MASK) >> PAGE_SHIFT;
> +
>   if ((vma->vm_mm->rss + (end - start)) > rlim_rss)
>   return error;

Since we don't use it i can't really test it, but a visual inspection is
good enough in this simple case. And since this is the only place in 2.4
that RLIMIT_RSS is used, the problem is solved.

BTW do you know if there is any plans for 2.6++ to actually use
RLIMIT_RSS? I saw a hint in that direction in mm/thrash.c
grab_swap_token but it is commented out and only skeleton code...

I'm asking since the above code piece has been removed.

-- 
Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
Internet: [EMAIL PROTECTED] Phone: +46 90 7866134 Fax: +46 90 7866126
Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se
-
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: critical bugs in md raid5

[Marc Lehmann]

On Thu, Jan 27, 2005 at 06:11:34AM +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Marc Lehmann <[EMAIL PROTECTED]> writes:
> > The summary seems to be that the linux raid driver only protects your data
> > as long as all disks are fine and the machine never crashes.
> 
> "as long as the machine never crashes". That's correct. If you think
> about how RAID 5 works there is no way around it. When a write to 

I disagree. When not working in degraded mode, it's absolutely reasonable
to e.g. use only the non-parity data. A crash with raid5 is in no way
different to a crash without raid5 then: either the old data is on the
disk, the new data is on the disk, or you had some catastrophic disk event
and no data is on the disk.

The case I reported was not a catastrophic failure: either the old or new
data was on the disk, and the filesystem journaling (which is ext3) will
take care of it. Even if the parity information is not in sync, either old or
new data is on the disk.

> a single stripe is interrupted (machine crash) and you lose a disk
> during the recovery a lot of data (even unrelated to the data just written)
> is lost.

This is not what I described, in fact, I haven't lost any data, despite
having had a number of such problems (I did verify that afterwards, and
found no differences. Maybe this is luck, but it seems to happen in the
majority of cases, and I ahd a similar problem at least 5 or 6 times
because I didn't encounter the bug I reported).

> But that's nothing inherent in Linux RAID5. It's a generic problem.
> Pretty much all Software RAID5 implementations have it.

Indeed, but I think linux' behaviour is especially poor. For example, the
renumbering of the devices or the strange rebuild-restart behaviour (which
is definitely a bug) will make recovery unnecessarily complicated.

> RAID-1 helps a bit, because you either get the old or the new data,
> but not some corruption.

You don't get any magical corruption with RAID5 either... the data contents
will either be old, or new. The differnce is that you cannot trust parity.

> In practice even old data can be a big
> problem though (e.g. when file system metadata is affected)

Of course, but that's supposed to be worked around by using a journaling
file system, right?

> Morale: if you really care about your data backup very often and
> use RAID-1 or get an expensive hardware RAID with battery backup
> (all the cheap "hardware RAIDs" are equally useless for this) 

Yes, I am thinking of that for some time now, but always had a problem
because the affordable ones have low performance. But given linux'
effective slower-than-a-single-disk performance it shouldn't be hard to
beat nowadays.

There is, however, at least the resyncing with only 4 out of 5 disks, that
is doubtlessly a bug somewhere.

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
-
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-rc2-mm1 strange messages

[Norbert Preining]

On Mit, 26 Jan 2005, Len Brown wrote:
> > Can you please add this?
> > 
> > --- 25/arch/i386/mm/ioremap.c~iounmap-debugging 2005-01-25
> > 10:26:29.448809152 -0800
> > +++ 25-akpm/arch/i386/mm/ioremap.c  2005-01-25 10:27:07.054092280
> > -0800
> > @@ -233,7 +233,8 @@ void iounmap(volatile void __iomem *addr
> > return; 
> > p = remove_vm_area((void *) (PAGE_MASK & (unsigned long
> > __force) addr));
> > if (!p) { 
> > -   printk("__iounmap: bad address %p\n", addr);
> > +   printk("iounmap: bad address %p\n", addr);
> > +   dump_stack();
> > return;
> > }
> >  
> > _
> > 
> 
> Better yet, can you please add this?
> 
> http://lkml.org/lkml/2005/1/3/136

I only get hands on the laptop today noon, but then I will immediately
recompile ...

Best wishes

Norbert

---
Norbert Preining  Technische Universität Wien
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
SCRABSTER (n.)
One of those dogs which has it off on your leg during tea.
--- Douglas Adams, The Meaning of Liff
-
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: i8042 access timings

[Jaco Kroon]

Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with i8042.debug 
and acpi=off.
I made an alternative plan.  I applied a custom patch that gives me far less
output and prevents scrolling and gets what I hope is what is required.
With acpi=on I get the following output:
i8042_init()
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
i8042_allocate_kbd_port()
i8042_port_register()
With acpi=off I get this:
i8042_init()
i8042: ACPI detection disabled
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux:  passed
i8042_check_mux()
i8042_enable_mux_mode()
i8042_flush()
i8042_open(): mux_version==19
i8042.c: Detected active multiplexing controller, rev 1.9.
i8042_enable_mux_ports()
i8042_allocate_mux_port()
i8042_port_register()
Ok, some explanation is probably in order, I just put a printk(KERN_INFO 
"function_name()\n" at the top of practically every function and then I 
filled up i8042_check_aux() because that is where the error is detected. 
 In the first case (the interesting one) these lines pop up:

i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
Which indicates (as far as my understanding goes) that the command times 
out, as such the param value stays the same (ready for re-use in the 
second command).  The second commands succeeds but does not return one 
of the expected (0x00, 0xff, 0xfa) values, instead it returns the value 
as expected by the first command (0xa5).  The last value on both lines 
is the return value.  From the second snippet:

i8042_flush()
i8042_check_aux:  passed
Indicates that the outer test passed first time round, ie, exit code 0 
and return param of 0xa5.  What I have done to get mine working with 
acpi=on is applied the following patch (apologies if mozilla breaks this):

==
--- linux-2.6.10/drivers/input/serio/i8042.c2004-12-24 
23:33:52.0 +0200
+++ linux-2.6.10-patched/drivers/input/serio/i8042.c2005-01-24 
21:44:33.790291480 +0200
@@ -595,7 +595,7 @@
  */

if (i8042_command(, I8042_CMD_AUX_TEST)
-   || (param && param != 0xfa && param != 0xff))
+   || (param && param != 0xfa  && param != 0xa5 && 
param != 0xff))
return -1;
}

==
Which I don't think is the proper solution, more likely the problem lies 
in the i8042_command function.  Unfortunately I don't have time right 
now to add more debug code (to possibly only issue those dbg statements 
upto a certain point in order to reduce the amount of output).

> As I remember with acpi=off i8042 detects multplexer MUX with four ports!
> I tried to make a hack for mux detection, but mux was detected and 
touchpad
> was not:(
Yes.  This seems correct, however the touchoad worked "perfectly" for me 
when I booted with acpi=off.

Dmitry,
 did you see this one?
Since everything but the I8042_CMD_AUX_LOOP/AUX_TEST thing apparently
works, this is not the case of ACPI setting the wrong ports or something 
fundamental like that. It looks like some state of the keyboard controller 
just disables the loopback command and/or the AUX_TEST command.

Might the "no KBD" case be something similar?
I'm probably a bit off here, but what "no KBD" case?  On these 
particular notebooks we both had to compile in specifically USB1.1 
support in order to have keyboard support, but since I want USB support 
in any case this is not a problem for me (although I would love to know 
what caused this).

Sebastian, can you make your hack also print out what the errors were (in 
particular, was it "i8042_command()" that failed, or was it that the 
return value was different from the expected ones, and if so - what?)
I hope my debug did exactly that.
From the orriginal mail sent to me by Sebastian:
In method:
 i8042_check_aux
There is:
param = 0x5a;
   if (i8042_command(, I8042_CMD_AUX_LOOP) || param != 0xa5) 
{

/*
* External connection test - filters out AT-soldered PS/2 i8042's
* 0x00 - no error, 0x01-0x03 - clock/data stuck, 0xff - general error
* 0xfa - no error on some notebooks which ignore the spec
* Because it's common for chipsets to return error on perfectly 
functioning
* AUX ports, we test for this only when the LOOP command failed.
*/

   if (i8042_command(, I8042_CMD_AUX_TEST)
   || (param && param != 0xfa && param != 0xff))
   return -1;
   }
I have commented the line with return -1.
I know that this solution is very stupid, but works fine.
I use 

Re: 2.6.11-rc2-mm1

[William Lee Irwin III]

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.

autofs has exploded far, far beyond complete nonfunctionality, where
in prior 2.6.x it was not quite so blatantly a doorstop preventing all
logins on the machine, and, in fact, multiuser mode altogether.

Whoever's responsible, prepare to be flamed to a crisp the likes of
which has never been witnessed before by observers of solar probes, nor
conceived of by the most visionary and imaginative of eschatologists.


-- wli
-
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/

ppc 8260 ethernet driver fails to put port into promiscuous or mu lticast modes

[Eyal Ofer-R55413]

hello,

1. the function in the ppc 8260 ethernet driver that's suppose to put the 
interface into promiscuous or multicast modes contains a 'return' statement 
immediately at the beginning. this prevents running an 8260-based system as a 
bridge for example. the 'return' statement is not indented, and there's no 
comment to explain it. it is unclear if it was forgotten there by the writer or 
whether it serves some functional role (improve performance for other modes of 
operations, cover up for untested code later, etc.). removing it does not seem 
to hurt the operation of the system though. unless there's a known use for this 
'return', i would like to suggest the following patch (demonstrated here for 
2.4.22):


--- fcc_enet.c.orig Thu Jan 27 07:56:35 2005
+++ fcc_enet.c  Thu Jan 27 07:57:00 2005
@@ -1080,7 +1080,6 @@
 
cep = (struct fcc_enet_private *)dev->priv;
 
-return;
/* Get pointer to FCC area in parameter RAM.
*/
ep = (fcc_enet_t *)dev->base_addr;



problem persists ever since the driver's introduction into the 2.4.0-test9-pre2 
kernel and up to it's latest version in 2.6.10

path to problem:
early 2.4.x and all 2.6.x:
arch/ppc/8260_io/fcc_enet.c
later 2.4.2x (at least 2.4.26 and on):
arc/ppc/cpm_io/fcc_enet.c

problem in function: set_multicast_list()


2. please CC me personally on answer as i'm not a subscriber on the lkml.


best regards,
ofer eyal


-
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/

Government Grants Available

[Canadian Books]

<2 6  B e l l e v u e>


 


The   is now
available. This guide contains more than 2600 listings
of grants and loans offered by both the federal and 
provincial governments. It also includes foundations and 
associations.

The  
is also available for the United States.

Our publication is sold for $69.95

To order please call:  <4 5 0 - 2 2 4 - 9 2 7 5>






This message is sent to you in compliance with the Federal CAN-Spam Bill
and the Electronic Commerce (EC Directive) Regulations of 2004. This is a
commercial email which includes an unsubscribe method for remove processing
as mandated by law. Footer also includes the sender's information.

Quantum International
5985 S. University Dr. #138
Davie, Florida 33328

To be excluded from future mailings, please reply to this email with "rem"
in the subject line.



-
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/

confguring grub to load new kernel

[[EMAIL PROTECTED]]

Hi,

I just compiled kernel 2.6.10 and now wondering how to make the grub to
load the newkernel.

The grub.conf file is configured as:

#boot=/dev/hda
default=1
timeout=10
splashimage=(hd0,5)/boot/grub/splash.xpm.gz
title Red Hat Linux (2.4.20-8)
root (hd0,5)
kernel /boot/vmlinuz-2.4.20-8 ro root=LABEL=/
initrd /boot/initrd-2.4.20-8.img
title DOS
rootnoverify (hd0,0)
chainloader +1


How should I change the configuration?

sudhir


mail2web - Check your email from the web at
http://mail2web.com/ .


-
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, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Nick Piggin]

On Wed, 2005-01-26 at 23:15 -0600, Jack O'Quin wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> 

> > But the important elements are lost. The standard provides a
> > deterministic scheduling order, and a deterministic scheduling
> > latency 
> 
> Where does the standard actually say this?  All I found was the
> reference[1] in my previous note.  It talks about queue management,
> but not scheduling latency.  The scheduling order is only defined to
> be deterministic within the SCHED_FIFO class.  Ingo's patch actually
> conforms to this requirement fully, AFAICT.
> 
>  [1] http://www.opengroup.org/onlinepubs/007908799/xsh/realtime.html
> 
> I'm not trying to be a "standards lawyer" about this, and I can see
> your point of view.  But, we should clearly distinguish what is
> *required* by POSIX from what we feel to be good engineering practice.
> Both are important.

Yes I see what you mean. And in fact it does say that scheduling
of SCHED_OTHER tasks with SCHED_FIFO and SCHED_RR tasks is
implementation specific, however that must be within the framework
of their queued scheduler specification.

And in Linux, sched_get_priority_max() and sched_get_priority_min()
for SCHED_OTHER tasks are both 0, which is below the minimum RT
policy's minimum priority. So in that case, the standard is broken
by the patch.

> 
> > (of course this doesn't mean a great deal for Linux, but I think
> > we're good enough for a lot of soft-rt applications now).
> 
> Absolutely.  And getting noticeably better these days.
> 
> >> If I understand Ingo's proposal correctly, setting RLIMIT_RT_CPU to
> >> zero and then requesting SCHED_FIFO (with CAP_SYS_NICE) yields exactly
> >> the former behavior.  This will probably be the default setting.
> >
> > Oh yes, and that would surely have to be the only sane default
> > setting. But I then ask, why put this complexity into the kernel
> > in the first place? And is the cost of significantly breaking the
> > API and lying to userspace acceptable?
> 
> Well, this extremely long discussion started with a request on behalf
> of a large group of audio developers and users for a way to gain
> realtime scheduling privileges without running as root.
> 
> Several kernel developers felt that would be unacceptable, because of
> the Denial of Service implications.  We argued that the owner of a
> Digital Audio Workstation should be free to lock up his CPU any time
> he wants.  But, no one would listen.  We were told that we didn't
> really know what we needed, and were asking the wrong question.  That
> was very discouraging.  It looked like LKML was going to ignore our
> needs for yet another year.
> 
> Had I been in charge, I would have adopted our silly little RT-LSM
> patch, declared victory, and moved on to other matters.  But, I'm not
> responsible for this particular kernel.  (Thank you, God!)  So, I am
> willing to defer to the prejudices of those who are.  But, the limit
> of my deference is reached when they refuse to meet my needs.
> 
> When Con and Ingo started floating scheduler proposals, I tried to
> help them produce something useful.  I think they have succeeded.
> 
> Is this the easiest way to meet our needs?  No way.  But it's not bad,
> and I think it will work.  In some ways, it's actually better than our
> original RT-LSM proposal.  Ingo's scheduler patch is not very large.
> 

I have sympathy for you. I'm just observing that if we add the
simple rlimit first, this solves your (and this large group of
audio developers') particular problem. In fact, this will be the
_quickest_ path to get your requirement into the kernel, too.

At which point, there doesn't appear to be a need for more
complexity (which is what us kernel developers would like to hear!).

And I still maintain that it is stupid to run two unrelated (ie.
neither has knowledge of the other) realtime systems on the same
computer. One or both could easily break. So I agree with your point
that we needn't have to make realtime scheduling "nice" for a multi
user situation.

> >> The main point of discussion is: exactly what resource should it
> >> limit?  Arjan and Chris proposed to limit priority.  Ingo proposed to
> >> limit the percentage of each CPU available for realtime threads
> >> (collectively).  Either would meet our minimum needs (AFAICT).
> >
> > I think the priority limit is the better way, because the % CPU
> > available to real time threads approach essentially gives you no
> > realtime scheduling at all.
> 
> Setting RLIMIT_RT_CPU to 100% gives exactly what you are asking for.
> 

But now I have no control over priorities. So root cannot be
guaranteed to have its highest-priority watchdog run.

> In fact, I will probably lower it to 98%, taking advantage of the
> scheduler's ability to throttle runaway threads.  Locking up the CPU
> is not a big problem in my life, but it can be annoying when it does
> occur.  The JACK watchdog does not catch every bug we see during
> development.
> 

We've got 

Re: don't let mmap allocate down to zero

[William Lee Irwin III]

On Wed, Jan 26, 2005 at 09:09:27PM -0800, William Lee Irwin III wrote:
>> There's a long discussion here, in which no one appears to have noticed
>> that SHLIB_BASE does not exist in mainline. Is anyone else awake here?

On Thu, Jan 27, 2005 at 12:18:56AM -0500, Dave Jones wrote:
> It's an exec-shield'ism. Rik likely was working off a Red Hat/Fedora
> kernel tree.

It does change things in a substantial way. Namely, the lower address
space boundary doesn't exist in mainline at all, and so its enforcement
requires introduction. Furthermore, mainline must concern itself with
all Linux-supported architectures (not distro-supported architectures),
not just ia32/x86-64, so there is also FIRST_USER_PGD_NR to take into
account as opposed to pulling magic ia32/x86-64 -specific numbers out
of a hat and splattering them all over core code. Not that you had
anything to do with any of this.


-- wli
-
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: don't let mmap allocate down to zero

[Dave Jones]

On Wed, Jan 26, 2005 at 09:09:27PM -0800, William Lee Irwin III wrote:
 > On Wed, Jan 26, 2005 at 11:18:08AM -0500, Rik van Riel wrote:
 > >> With some programs the 2.6 kernel can end up allocating memory
 > >> at address zero, for a non-MAP_FIXED mmap call!  This causes
 > >> problems with some programs and is generally rude to do. This
 > >> simple patch fixes the problem in my tests.
 > >> Make sure that we don't allocate memory all the way down to zero,
 > >> so the NULL pointer never gets covered up with anonymous memory
 > >> and we don't end up violating the C standard.
 > >> Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
 > 
 > On Wed, Jan 26, 2005 at 09:25:38AM -0800, William Lee Irwin III wrote:
 > > SHLIB_BASE does not appear to be present in 2.6.9; perhaps something
 > > else is going on.
 > > I think we are better off:
 > >(a) checking for hitting zero explicitly as opposed to
 > >enforcing a randomly-chosen lower limit for addresses
 > >(b) enforcing vma allocation above FIRST_USER_PGD_NR*PGDIR_SIZE,
 > >to which SHLIB_BASE bears no relation.
 > 
 > There's a long discussion here, in which no one appears to have noticed
 > that SHLIB_BASE does not exist in mainline. Is anyone else awake here?

It's an exec-shield'ism. Rik likely was working off a Red Hat/Fedora kernel 
tree.

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, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Jack O'Quin]

Nick Piggin <[EMAIL PROTECTED]> writes:

> On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>> 
>> > I'm a bit concerned about this kind of policy and breakage of
>> > userspace APIs going into the kernel. I mean, if an app is
>> > succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
>> > scheduler does something else, that could be undesirable in some
>> > situations.
>> 
>> True.  It's similar to running out of CPU bandwidth, but not quite.
>> 
>> AFAICT, the new behavior still meets the letter of the standard[1].
>> Whether it meets the spirit of the standard is debatable.  My own
>> feeling is that it probably does, and that making SCHED_FIFO somewhat
>> less powerful but much easier to access is a reasonable tradeoff.
>
> I don't think it does. The process with the highest priority
> must run first, regardless of anything else.
>
> You could say "it is similar to running out of CPU bandwidth", or
> "it is like running on a CPU that is 80% the speed". And it may be
> similar in terms of total throughput.

I also said, "but not quite".  The differences are noticeable, but I
believe they are manageable.  I could still be convinced otherwise,
however, by a sufficiently persuasive argument.  ;-)  

I don't claim to know about every realtime system.

> But the important elements are lost. The standard provides a
> deterministic scheduling order, and a deterministic scheduling
> latency 

Where does the standard actually say this?  All I found was the
reference[1] in my previous note.  It talks about queue management,
but not scheduling latency.  The scheduling order is only defined to
be deterministic within the SCHED_FIFO class.  Ingo's patch actually
conforms to this requirement fully, AFAICT.

 [1] http://www.opengroup.org/onlinepubs/007908799/xsh/realtime.html

I'm not trying to be a "standards lawyer" about this, and I can see
your point of view.  But, we should clearly distinguish what is
*required* by POSIX from what we feel to be good engineering practice.
Both are important.

> (of course this doesn't mean a great deal for Linux, but I think
> we're good enough for a lot of soft-rt applications now).

Absolutely.  And getting noticeably better these days.

>> If I understand Ingo's proposal correctly, setting RLIMIT_RT_CPU to
>> zero and then requesting SCHED_FIFO (with CAP_SYS_NICE) yields exactly
>> the former behavior.  This will probably be the default setting.
>
> Oh yes, and that would surely have to be the only sane default
> setting. But I then ask, why put this complexity into the kernel
> in the first place? And is the cost of significantly breaking the
> API and lying to userspace acceptable?

Well, this extremely long discussion started with a request on behalf
of a large group of audio developers and users for a way to gain
realtime scheduling privileges without running as root.

Several kernel developers felt that would be unacceptable, because of
the Denial of Service implications.  We argued that the owner of a
Digital Audio Workstation should be free to lock up his CPU any time
he wants.  But, no one would listen.  We were told that we didn't
really know what we needed, and were asking the wrong question.  That
was very discouraging.  It looked like LKML was going to ignore our
needs for yet another year.

Had I been in charge, I would have adopted our silly little RT-LSM
patch, declared victory, and moved on to other matters.  But, I'm not
responsible for this particular kernel.  (Thank you, God!)  So, I am
willing to defer to the prejudices of those who are.  But, the limit
of my deference is reached when they refuse to meet my needs.

When Con and Ingo started floating scheduler proposals, I tried to
help them produce something useful.  I think they have succeeded.

Is this the easiest way to meet our needs?  No way.  But it's not bad,
and I think it will work.  In some ways, it's actually better than our
original RT-LSM proposal.  Ingo's scheduler patch is not very large.

>> The main point of discussion is: exactly what resource should it
>> limit?  Arjan and Chris proposed to limit priority.  Ingo proposed to
>> limit the percentage of each CPU available for realtime threads
>> (collectively).  Either would meet our minimum needs (AFAICT).
>
> I think the priority limit is the better way, because the % CPU
> available to real time threads approach essentially gives you no
> realtime scheduling at all.

Setting RLIMIT_RT_CPU to 100% gives exactly what you are asking for.

In fact, I will probably lower it to 98%, taking advantage of the
scheduler's ability to throttle runaway threads.  Locking up the CPU
is not a big problem in my life, but it can be annoying when it does
occur.  The JACK watchdog does not catch every bug we see during
development.

> By limiting priority, you can at least construct userspace solutions
> to managing RT threads.

I think I can do it either way.  

Further, I believe distributions will 

Re: critical bugs in md raid5

[Andi Kleen]

Marc Lehmann <[EMAIL PROTECTED]> writes:
>
> The summary seems to be that the linux raid driver only protects your data
> as long as all disks are fine and the machine never crashes.

"as long as the machine never crashes". That's correct. If you think
about how RAID 5 works there is no way around it. When a write to 
a single stripe is interrupted (machine crash) and you lose a disk
during the recovery a lot of data (even unrelated to the data just written)
is lost. That is because there is no way to figure out what part
of the data on the stripe belonged to the old and what part to 
the new write.

But that's nothing inherent in Linux RAID5. It's a generic problem.
Pretty much all Software RAID5 implementations have it.

The only way around it is to journal all writes, to make stripe
updates atomic, but in general that's too slow unless you have a
battery backed up journal device. 

There are some tricks to avoid this (e.g. always write to a new disk
location and update an disk index atomically), but they tend to be
heavily patented and are slower too. They also go far beyond RAID-5
(use disk space less efficiently etc.)  and typically need support
from the file system to be efficient.

RAID-1 helps a bit, because you either get the old or the new data,
but not some corruption. In practice even old data can be a big
problem though (e.g. when file system metadata is affected)

Morale: if you really care about your data backup very often and
use RAID-1 or get an expensive hardware RAID with battery backup
(all the cheap "hardware RAIDs" are equally useless for this) 

-Andi
-
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: don't let mmap allocate down to zero

[William Lee Irwin III]

On Wed, Jan 26, 2005 at 11:18:08AM -0500, Rik van Riel wrote:
>> With some programs the 2.6 kernel can end up allocating memory
>> at address zero, for a non-MAP_FIXED mmap call!  This causes
>> problems with some programs and is generally rude to do. This
>> simple patch fixes the problem in my tests.
>> Make sure that we don't allocate memory all the way down to zero,
>> so the NULL pointer never gets covered up with anonymous memory
>> and we don't end up violating the C standard.
>> Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>

On Wed, Jan 26, 2005 at 09:25:38AM -0800, William Lee Irwin III wrote:
> SHLIB_BASE does not appear to be present in 2.6.9; perhaps something
> else is going on.
> I think we are better off:
>   (a) checking for hitting zero explicitly as opposed to
>   enforcing a randomly-chosen lower limit for addresses
>   (b) enforcing vma allocation above FIRST_USER_PGD_NR*PGDIR_SIZE,
>   to which SHLIB_BASE bears no relation.

There's a long discussion here, in which no one appears to have noticed
that SHLIB_BASE does not exist in mainline. Is anyone else awake here?


-- wli
-
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: Possible bug in keyboard.c (2.6.10)

[Dmitry Torokhov]

On Wednesday 26 January 2005 22:16, Sasa Stevanovic wrote:
> Hi,
> 
> I had some problems with my laptop's onetouch keys and it eventually led me 
> to 
> keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others).  There may be 
> a bug in the file, please read below.
> 
> Well, actually, when all omnibook/messages/setkeycodes/hotkeys/xev/showkey 
> etc 
> stuff is stripped off, what remains is that x86_keycodes array has only first 
> 240 members initialized, while remaining 16 are set to 0 due to [256]:
> 
> static unsigned short x86_keycodes[256] = {  };
> 
> (For my scenario, workaround was possible.)
> 
> I am not sure if this is a bug or not; it worked in 2.4.18 without 
> workaround. 
> Might be that someone wanted to prevent reading invalid memory.  There are 
> many versions of the file/array definition found on the web, none of which 
> has 
> a comment about this.
> 

>From Vojetch Pavilk:
> I'm sorry, but X only understands the RAW PS/2 protocol, and that one
>  can only transport keycodes up to 240.
>  
>  For keycodes above 240, XFree86 would either need to use the MediumRAW
>  mode, or use event devices for parsing the keyboard.
http://www.ussg.iu.edu/hypermail/linux/kernel/0406.0/0544.html

You still did not describe what kind of problems you are having with your
keys.

-- 
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: UDF madness

[Andrew Morton]

Attila Body <[EMAIL PROTECTED]> wrote:
>
> I've spent some time (2 weekwnds) on this issue, while I was able to
>  realize that not the packet-writing but the UDF driver is broken
> 
>  here is the recipie to reproduve the issue:
> 
>  dd if=/dev/zer of=udf.img bs=1024k count=3000
>  mkudffs udf.img
>  mount -o loop udf.img /mnt/tmp
>  cd /mnt/tmp
>  tar xjvf /usr/src/linux-2.6.11-rc2
>  cd /
>  umount /mnt/tmp
> 
>  On the end I get a never ending umount process in D state. sysreq-T
>  tells the following about the umount process:
> 
> 
> 
>  umountD C03F93E0 0  5848   5655 (NOTLB)
>  c797dd68 00200082 ca674560 c03f93e0 0040  c81e327c 000c 
> 000ae62d 925f0dc0 000f43e3 ca674560 ca6746b0 c797c000 cebf184c
>  00200282 
> ca674560 c02ea6e0 cebf1854 0001 ca674560 c01170c0 cebf1854
>  cebf1854 
>  Call Trace:
>   [] __down+0x90/0x110
>   [] default_wake_function+0x0/0x20
>   [] __mark_inode_dirty+0xd1/0x1c0
>   [] __down_failed+0x7/0xc
>   [] .text.lock.balloc+0x8/0x128 [udf]
>   [] udf_write_aext+0xf7/0x170 [udf]
>   [] udf_free_blocks+0xcc/0x100 [udf]
>   [] extent_trunc+0x124/0x180 [udf]
>   [] udf_discard_prealloc+0x225/0x2e0 [udf]
>   [] udf_clear_inode+0x41/0x50 [udf]
>   [] clear_inode+0xde/0x120
>   [] dispose_list+0x3f/0xb0
>   [] invalidate_inodes+0x62/0x90
>   [] generic_shutdown_super+0x5d/0x140

Yes, me too.  generic_shutdown_super() takes lock_super().  And udf uses
lock_super for protecting its block allocation data strutures.  Trivial
deadlock on unmount.

Filesystems really shouldn't be using lock_super() for internal purposes,
and the main filesystems have been taught to not do that any more, but UDF
is a holdout.

It seems that this deadlock was introduced on Jan 5 by the "udf: fix
reservation discarding" patch which added the udf_discard_prealloc() call
into udf_clear_inode().  The below dopey patch prevents the deadlock, but
perhaps we can think of something more appealing.  Ideally, use a new lock
altogether?

(I had UDF deadlock on me once during the untar.  That was a multi-process
lockup and is probably due to a lock ranking bug.  Will poke at that a bit
further).


--- 25/fs/udf/balloc.c~udf-umount-deadlock-fix  2005-01-26 19:45:38.351735200 
-0800
+++ 25-akpm/fs/udf/balloc.c 2005-01-26 19:50:35.951493160 -0800
@@ -155,8 +155,17 @@ static void udf_bitmap_free_blocks(struc
unsigned long i;
int bitmap_nr;
unsigned long overflow;
+   int took_lock_super = 0;
+
+   if (sb->s_flags & MS_ACTIVE) {
+   /*
+* On the umount path, generic_shutdown_super() holds
+* lock_super for us
+*/
+   lock_super(sb);
+   took_lock_super = 1;
+   }
 
-   lock_super(sb);
if (bloc.logicalBlockNum < 0 ||
(bloc.logicalBlockNum + count) > UDF_SB_PARTLEN(sb, 
bloc.partitionReferenceNum))
{
@@ -215,7 +224,8 @@ error_return:
sb->s_dirt = 1;
if (UDF_SB_LVIDBH(sb))
mark_buffer_dirty(UDF_SB_LVIDBH(sb));
-   unlock_super(sb);
+   if (took_lock_super)
+   unlock_super(sb);
return;
 }
 
_

-
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] Fix large allocation in nfsd init

[Neil Brown]

On Thursday January 27, [EMAIL PROTECTED] wrote:
> 
> Hi,
> 
> I just added an NFS mount to a ppc64 box that had been up for a while.
> This required inserting the nfsd module. Unfortunately it failed:  
> 
> modprobe: page allocation failure. order:5, mode:0xd0
> Trace:
> [c00ba0f8] alloc_pages_current+0xc0/0xe4
> [c00941fc] __get_free_pages+0x54/0x1e0
> [d046f7d8] nfsd_cache_init+0x54/0x1a4 [nfsd]
> [d04782cc] init_nfsd+0x30/0x2564 [nfsd]
> [c0084bec] sys_init_module+0x23c/0x5ac
> [c001045c] ret_from_syscall_1+0x0/0xa4
> nfsd: cannot allocate 98304 bytes for reply cache
> 
> An order 5 allocation. Replace it with a vmalloc.

Given that the purpose of this order-5 allocation is to provide
storage for 1024 "struct svc_cacherep" structs, it would seem that a
better approach would be to just do 1024 kmallocs.

I'll try to knock a patch together in next week sometime.

Thanks,

NeilBrown
-
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/

critical bugs in md raid5

[Marc Lehmann]

Hi,

I want to report a number of problems in the current raid5 code, some of
which are pretty annoying, some of which require a superblock reformat.

Here's my setup:

- dual AMD opteron with 64-bit kernel, 2.6.10/2.6.8.1
- 5 raid disks, 4 standard ide on hda..hdd, one sata-device
  (that setup gives a much higher performance than putting every device
  on it's own ide port).

First, the really bad ones (happened with 2.6.10):

Today, I had a crash that required a hard reset. After the next start, the
raid started to rebuild as expected (and, as usually, at 5 times the speed
that I get when reading from the raid array, but that's an old problem
that I had on 2.4, too).

I only remember that I had all all five disks with an up-to-date sign
[U] during the whole rebuild, which made sense to me, as the data
should be up-to-date, despite the raid being out-of-sync. I rebooted
during the time, at around 46%. After the next reboot, resyncing properly
continued.

Then the rebuild finished:

   md: md0: sync done.

*immediately* after that line, I got an ide error:

   hda: dma_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
   hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=312581110, 
high=18, low=10591222, sector=312580370
   ide: failed opcode was: unknown
   end_request: I/O error, dev hda, sector 312580370

I did verify that the disk block indeed was unreadable. The raid did react:

   raid5: Disk failure on hda1, disabling device. Operation continuing on 4 
devices
   RAID5 conf printout:
--- rd:5 wd:4 fd:1
disk 0, o:0, dev:hda1
disk 1, o:1, dev:sda1
disk 2, o:1, dev:hdd1
disk 3, o:1, dev:hdc1
disk 4, o:1, dev:hdb1
   RAID5 conf printout:
--- rd:5 wd:4 fd:1
disk 1, o:1, dev:sda1
disk 2, o:1, dev:hdd1
disk 3, o:1, dev:hdc1
disk 4, o:1, dev:hdb1

Interestingly, it immediately started to rebuild the array, with only for
disks (/proc/mdstat showed hda1 as F (faulty)):

   .<6>md: syncing RAID array md0
   md: minimum _guaranteed_ reconstruction speed: 0 KB/sec/disc.
   md: using maximum available idle IO bandwith (but not more than 9 KB/sec)
   for reconstruction.
   md: using 128k window, over a total of 156290816 blocks.
   md: resuming recovery of md0 from checkpoint.

Indeed, /proc/mdstat showed that it had 46% (last checkpoint) already in
sync, while at the same time only showing 4 disks.

I did:

   raidhotremove /dev/md0 /dev/hda1

which worked (rebuild continued, though), then

   raidhotadd /dev/md0 /dev/hda1

which worked (rebuilt continued, though). I then decided to reboot.

After the reboot, I no longer had a raid, because the array was dirty and
degraded.

This is an important bug, IMHO, as it required me to manually mdadm -C the
array, which I am fairly proficient with, but it's still rather risky,
because of the following issues:

Sometimes, when the machine crashes, it seems that a dirty array is just
as unsafe as a degraded array: when the rebuild starts and hits a bad
block somewhere on the disks it chose to read from (bad blocks are very
common during hard crashes, as the disk might not have time to properly
write the block), it will mark the disk as faulty. Unfortunately, as the
array seems to be in some artifical degraded mode, it seems to think yet
another disk is faulty, and then stop working, as it thinks it has lost
two disks - reformat required.

Then, the reformat might be more difficult than necessary, as, of course,
you need to know the "index" numbers of your disks, I mean these numbers:

   md0 : active raid5 hda1[5] sda1[1] hdd1[2] hdc1[3] hdb1[4]

mdadm can be made to print the same numbers. Unfortunately, neither mkraid
nor mdadm have any waay of working with disk indices that are outside the
normal range (i.e. only 0..4 are valid on my 5 disk-array when building,
but every raid failure will give the disks a different number, which is in
no relation to the original order).

That means that every replacement disk will need paper and pencil work, as
the required data is not readily available with user-level commands.

In one case, I ahd two unavailable disks (generated by the problem above)
with indices 5 and 6. Simple guesswork (formatting the array superblocks
in degraded mode - not a very documented thing, readonly-mount, retry
with different order) gave me the correct order, but it's a tedious and
error-prone task.  I'd say many admins might just format the superblocks
in non-degraded mode, and when they detect a problem, it'S already too
late because the sync has already started (although it could be that a
sync will not damage the disks in any way, after all, it's simple xor).

The summary seems to be that the linux raid driver only protects your data
as long as all disks are fine and the machine never crashes.

The last annoying issue is not a bug per se, and has been reported in much
larger detail earlier: my array can rebuild at a top speed of 165MB/s, but
dd or other tools never read more 

[PATCH] Fix large allocation in nfsd init

[Anton Blanchard]

Hi,

I just added an NFS mount to a ppc64 box that had been up for a while.
This required inserting the nfsd module. Unfortunately it failed:  

modprobe: page allocation failure. order:5, mode:0xd0
Trace:
[c00ba0f8] alloc_pages_current+0xc0/0xe4
[c00941fc] __get_free_pages+0x54/0x1e0
[d046f7d8] nfsd_cache_init+0x54/0x1a4 [nfsd]
[d04782cc] init_nfsd+0x30/0x2564 [nfsd]
[c0084bec] sys_init_module+0x23c/0x5ac
[c001045c] ret_from_syscall_1+0x0/0xa4
nfsd: cannot allocate 98304 bytes for reply cache

An order 5 allocation. Replace it with a vmalloc.

Anton

Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>

diff -puN fs/nfsd/nfscache.c~fix_nfsd_allocation fs/nfsd/nfscache.c
--- foobar2/fs/nfsd/nfscache.c~fix_nfsd_allocation  2005-01-27 
13:56:14.248445552 +1100
+++ foobar2-anton/fs/nfsd/nfscache.c2005-01-27 14:22:52.764642869 +1100
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -56,14 +57,10 @@ nfsd_cache_init(void)
struct svc_cacherep *rp;
struct nfscache_head*rh;
size_t  i;
-   unsigned long   order;
-
 
i = CACHESIZE * sizeof (struct svc_cacherep);
-   for (order = 0; (PAGE_SIZE << order) < i; order++)
-   ;
-   nfscache = (struct svc_cacherep *)
-   __get_free_pages(GFP_KERNEL, order);
+
+   nfscache = vmalloc(i);
if (!nfscache) {
printk (KERN_ERR "nfsd: cannot allocate %Zd bytes for reply 
cache\n", i);
return;
@@ -73,7 +70,7 @@ nfsd_cache_init(void)
i = HASHSIZE * sizeof (struct nfscache_head);
hash_list = kmalloc (i, GFP_KERNEL);
if (!hash_list) {
-   free_pages ((unsigned long)nfscache, order);
+   vfree(nfscache);
nfscache = NULL;
printk (KERN_ERR "nfsd: cannot allocate %Zd bytes for hash 
list\n", i);
return;
@@ -102,8 +99,6 @@ void
 nfsd_cache_shutdown(void)
 {
struct svc_cacherep *rp;
-   size_t  i;
-   unsigned long   order;
 
for (rp = lru_head; rp; rp = rp->c_lru_next) {
if (rp->c_state == RC_DONE && rp->c_type == RC_REPLBUFF)
@@ -112,10 +107,7 @@ nfsd_cache_shutdown(void)
 
cache_disabled = 1;
 
-   i = CACHESIZE * sizeof (struct svc_cacherep);
-   for (order = 0; (PAGE_SIZE << order) < i; order++)
-   ;
-   free_pages ((unsigned long)nfscache, order);
+   vfree(nfscache);
nfscache = NULL;
kfree (hash_list);
hash_list = NULL;
_
-
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: /proc parent _root == NULL?

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Al Viro wrote:
> On Wed, Jan 26, 2005 at 09:33:48PM -0500, John Richard Moser wrote:
> 
>>create_proc_entry("kmsg", S_IRUSR, _root);
>>
>>So this is asking for proc_root to be filled?
>>
>>create_proc_entry("kcore", S_IRUSR, NULL);
>>
>>And this is just saying to shove it in proc's root?
> 
> 
> NULL is equivalent to _root in that context; moreover, it's better
> style - drivers really shouldn't be refering to what is procfs-private
> object.
> 
> 
>>I'm trying to locate a specific proc entry, using this lovely piece of
>>code I ripped off:
> 
> 
> That's not something allowed outside of procfs code - lifetime rules
> alone make that a Very Bad Idea(tm).  If that's just debugging - OK,
> but if your code really uses that stuff, I want details on the intended
> use.  In that case your design is almost certainly asking for trouble.
> 

I'm trying to implement parts of grsecurity on top of a framework
similar to LSM (i.e. ripoff) that I wrote as an academic endeavor to
find out how stuff works and get some real-life kernel coding experience.

This particular problem pertains to proc_misc.c and trying to create a
hook for some grsecurity protections that alter the modes on certain
/proc entries.  The chunk of the patch I'm trying to immitate is:


diff -urNp linux-2.6.10/fs/proc/proc_misc.c linux-2.6.10/fs/proc/proc_misc.c
- --- linux-2.6.10/fs/proc/proc_misc.c2004-12-24 16:34:00 -0500
+++ linux-2.6.10/fs/proc/proc_misc.c2005-01-08 15:53:52 -0500
@@ -582,6 +582,8 @@ static void create_seq_entry(char *name,
 void __init proc_misc_init(void)
 {
struct proc_dir_entry *entry;
+   int gr_mode = 0;
+
static struct {
char *name;
int (*read_proc)(char*,char**,off_t,int,int*,void*);
@@ -596,9 +598,13 @@ void __init proc_misc_init(void)
 #ifdef CONFIG_STRAM_PROC
{"stram",   stram_read_proc},
 #endif
+#ifndef CONFIG_GRKERNSEC_PROC_ADD
{"devices", devices_read_proc},
+#endif
{"filesystems", filesystems_read_proc},
+#ifndef CONFIG_GRKERNSEC_PROC_ADD
{"cmdline", cmdline_read_proc},
+#endif
{"locks",   locks_read_proc},
{"execdomains", execdomains_read_proc},
{NULL,}
@@ -606,27 +612,45 @@ void __init proc_misc_init(void)
for (p = simple_ones; p->name; p++)
create_proc_read_entry(p->name, 0, NULL, p->read_proc,
NULL);

+#ifdef CONFIG_GRKERNSEC_PROC_USER
+   gr_mode = S_IRUSR;
+#elif CONFIG_GRKERNSEC_PROC_USERGROUP
+   gr_mode = S_IRUSR | S_IRGRP;
+#endif
+#ifdef CONFIG_GRKERNSEC_PROC_ADD
+   create_proc_read_entry("devices", gr_mode, NULL,
_read_proc, NULL);
+   create_proc_read_entry("cmdline", gr_mode, NULL,
_read_proc, NULL);
+#endif
+
proc_symlink("mounts", NULL, "self/mounts");

/* And now for trickier ones */
entry = create_proc_entry("kmsg", S_IRUSR, _root);
if (entry)
entry->proc_fops = _kmsg_operations;
+#ifdef CONFIG_GRKERNSEC_PROC_ADD
+   create_seq_entry("cpuinfo", gr_mode, _cpuinfo_operations);
+#else
create_seq_entry("cpuinfo", 0, _cpuinfo_operations);
+#endif
create_seq_entry("partitions", 0, _partitions_operations);
create_seq_entry("stat", 0, _stat_operations);
create_seq_entry("interrupts", 0, _interrupts_operations);
+#ifdef CONFIG_GRKERNSEC_PROC_ADD
+
create_seq_entry("slabinfo",S_IWUSR|gr_mode,_slabinfo_operations);
+#else

create_seq_entry("slabinfo",S_IWUSR|S_IRUGO,_slabinfo_operations);
+#endif
create_seq_entry("buddyinfo",S_IRUGO,
_file_operations);
create_seq_entry("vmstat",S_IRUGO, _vmstat_file_operations);
create_seq_entry("diskstats", 0, _diskstats_operations);
 #ifdef CONFIG_MODULES
- -   create_seq_entry("modules", 0, _modules_operations);
+   create_seq_entry("modules", gr_mode, _modules_operations);
 #endif
 #ifdef CONFIG_SCHEDSTATS
create_seq_entry("schedstat", 0, _schedstat_operations);
 #endif
- -#ifdef CONFIG_PROC_KCORE
+#if defined(CONFIG_PROC_KCORE) && !defined(CONFIG_GRKERNSEC_PROC_ADD)
proc_root_kcore = create_proc_entry("kcore", S_IRUSR, NULL);
if (proc_root_kcore) {
proc_root_kcore->proc_fops = _kcore_operations;


The above I've been trying to create a security hook for to test out.
I've learned much already, like that breaking proc breaks your system
and causes panics.  :)

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+GF1hDd4aOud5P8RAvwKAJ9nPyuifIDloGyNGwNMuCfGvXMKswCgkIHE
kCr8U80DJJWfRSVJTZbXaMs=
=MDiz
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL 

RFC: assert_spin_locked() for 2.6

[Herbert Poetzl]

Greetings!

overcautious programming will kill your kernel ;)

ever thought about checking a spin_lock or even
asserting that it must be held (maybe just for
spinlock debugging?) ...

there are several checks present in the kernel
where somebody does a variation on the following:

  BUG_ON(!spin_is_locked(_lock));
  
so what's wrong about that? nothing, unless you
compile the code with CONFIG_DEBUG_SPINLOCK but 
without CONFIG_SMP ... in which case the BUG()
will kill your kernel ...

maybe it's not advised to make such assertions, 
but here is a solution which works for me ...
(compile tested for sh, x86_64 and x86, boot/run
tested for x86 only)

comments?

best,
Herbert

;
; define the new assert_spin_locked() macro and make
; sure that it does the proper checks regardless of
; CONFIG_SMP
;
diff -NurpP --minimal linux-2.6.11-rc2/include/linux/spinlock.h 
linux-2.6.11-rc2-spin/include/linux/spinlock.h
--- linux-2.6.11-rc2/include/linux/spinlock.h   2005-01-22 15:08:01 +0100
+++ linux-2.6.11-rc2-spin/include/linux/spinlock.h  2005-01-27 02:34:54 
+0100
@@ -38,6 +38,8 @@
  * If CONFIG_SMP is set, pull in the _raw_* definitions
  */
 #ifdef CONFIG_SMP
+
+#define assert_spin_locked(x)  BUG_ON(!spin_is_locked(x))
 #include 
 
 int __lockfunc _spin_trylock(spinlock_t *lock);
@@ -145,6 +147,14 @@ typedef struct {
0; \
})
 
+/* with debugging, assert_spin_locked() on UP does check
+ * the lock value properly */
+#define assert_spin_locked(x) \
+   ({ \
+   CHECK_LOCK(x); \
+   BUG_ON(!(x)->lock); \
+   })
+
 /* without debugging, spin_trylock on UP always says
  * TRUE. --> printk if already locked. */
 #define _raw_spin_trylock(x) \
@@ -201,6 +211,7 @@ typedef struct {
 #define spin_lock_init(lock)   do { (void)(lock); } while(0)
 #define _raw_spin_lock(lock)   do { (void)(lock); } while(0)
 #define spin_is_locked(lock)   ((void)(lock), 0)
+#define assert_spin_locked(lock)   do { (void)(lock); } while(0)
 #define _raw_spin_trylock(lock)(((void)(lock), 1))
 #define spin_unlock_wait(lock) (void)(lock)
 #define _raw_spin_unlock(lock) do { (void)(lock); } while(0)


diff -NurpP --minimal linux-2.6.11-rc2/arch/s390/mm/extmem.c 
linux-2.6.11-rc2-spin/arch/s390/mm/extmem.c
--- linux-2.6.11-rc2/arch/s390/mm/extmem.c  2005-01-22 15:07:31 +0100
+++ linux-2.6.11-rc2-spin/arch/s390/mm/extmem.c 2005-01-27 01:30:24 +0100
@@ -117,7 +117,7 @@ segment_by_name (char *name)
struct list_head *l;
struct dcss_segment *tmp, *retval = NULL;
 
-   BUG_ON (!spin_is_locked(_lock));
+   assert_spin_locked(_lock);
dcss_mkname (name, dcss_name);
list_for_each (l, _list) {
tmp = list_entry (l, struct dcss_segment, list);
@@ -271,7 +271,7 @@ segment_overlaps_others (struct dcss_seg
struct list_head *l;
struct dcss_segment *tmp;
 
-   BUG_ON (!spin_is_locked(_lock));
+   assert_spin_locked(_lock);
list_for_each(l, _list) {
tmp = list_entry(l, struct dcss_segment, list);
if ((tmp->start_addr >> 20) > (seg->end >> 20))
diff -NurpP --minimal linux-2.6.11-rc2/drivers/md/raid5.c 
linux-2.6.11-rc2-spin/drivers/md/raid5.c
--- linux-2.6.11-rc2/drivers/md/raid5.c 2005-01-22 15:07:37 +0100
+++ linux-2.6.11-rc2-spin/drivers/md/raid5.c2005-01-27 01:31:13 +0100
@@ -56,7 +56,7 @@
 #define RAID5_DEBUG0
 #define RAID5_PARANOIA 1
 #if RAID5_PARANOIA && defined(CONFIG_SMP)
-# define CHECK_DEVLOCK() if (!spin_is_locked(>device_lock)) BUG()
+# define CHECK_DEVLOCK() assert_spin_locked(>device_lock)
 #else
 # define CHECK_DEVLOCK()
 #endif
diff -NurpP --minimal linux-2.6.11-rc2/drivers/md/raid6main.c 
linux-2.6.11-rc2-spin/drivers/md/raid6main.c
--- linux-2.6.11-rc2/drivers/md/raid6main.c 2005-01-22 15:07:37 +0100
+++ linux-2.6.11-rc2-spin/drivers/md/raid6main.c2005-01-27 01:31:35 
+0100
@@ -62,7 +62,7 @@
 #define RAID6_PARANOIA 1   /* Check spinlocks */
 #define RAID6_DUMPSTATE 0  /* Include stripe cache state in /proc/mdstat */
 #if RAID6_PARANOIA && defined(CONFIG_SMP)
-# define CHECK_DEVLOCK() if (!spin_is_locked(>device_lock)) BUG()
+# define CHECK_DEVLOCK() assert_spin_locked(>device_lock)
 #else
 # define CHECK_DEVLOCK()
 #endif
diff -NurpP --minimal linux-2.6.11-rc2/drivers/media/common/saa7146_fops.c 
linux-2.6.11-rc2-spin/drivers/media/common/saa7146_fops.c
--- linux-2.6.11-rc2/drivers/media/common/saa7146_fops.c2004-12-25 
01:54:55 +0100
+++ linux-2.6.11-rc2-spin/drivers/media/common/saa7146_fops.c   2005-01-27 
01:32:35 +0100
@@ -73,9 +73,7 @@ int saa7146_buffer_queue(struct saa7146_
 struct saa7146_dmaqueue *q,
 struct saa7146_buf *buf)
 {
-#ifdef DEBUG_SPINLOCKS
-   BUG_ON(!spin_is_locked(>slock));
-#endif
+   assert_spin_locked(>slock);
DEB_EE(("dev:%p, dmaq:%p, buf:%p\n", dev, q, buf));
 
BUG_ON(!q);
@@ -96,9 +94,7 @@ void 

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Nick Piggin]

On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> 
> > I'm a bit concerned about this kind of policy and breakage of
> > userspace APIs going into the kernel. I mean, if an app is
> > succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
> > scheduler does something else, that could be undesirable in some
> > situations.
> 
> True.  It's similar to running out of CPU bandwidth, but not quite.
> 
> AFAICT, the new behavior still meets the letter of the standard[1].
> Whether it meets the spirit of the standard is debatable.  My own
> feeling is that it probably does, and that making SCHED_FIFO somewhat
> less powerful but much easier to access is a reasonable tradeoff.

I don't think it does. The process with the highest priority
must run first, regardless of anything else.

You could say "it is similar to running out of CPU bandwidth", or
"it is like running on a CPU that is 80% the speed". And it may be
similar in terms of total throughput.

But the important elements are lost. The standard provides a
deterministic scheduling order, and a deterministic scheduling
latency (of course this doesn't mean a great deal for Linux, but
I think we're good enough for a lot of soft-rt applications now).

> 
>  [1] http://www.opengroup.org/onlinepubs/007908799/xsh/realtime.html
> 
> If I understand Ingo's proposal correctly, setting RLIMIT_RT_CPU to
> zero and then requesting SCHED_FIFO (with CAP_SYS_NICE) yields exactly
> the former behavior.  This will probably be the default setting.
> 

Oh yes, and that would surely have to be the only sane default
setting. But I then ask, why put this complexity into the kernel
in the first place? And is the cost of significantly breaking the
API and lying to userspace acceptable?

> > Secondly, I think we should agree upon and get the basic rlimit
> > support in ASAP, so the userspace aspect can be firmed up a bit
> > for people like Paul and Jack (this wouldn't preclude further
> > work from happening in the scheduler afterwards).
> 
> I don't sense much opposition to adding rlimit support for realtime
> scheduling.  I personally don't think it a very good way to manage
> this problem.  But, it certainly can be made to work.
> 
> The main point of discussion is: exactly what resource should it
> limit?  Arjan and Chris proposed to limit priority.  Ingo proposed to
> limit the percentage of each CPU available for realtime threads
> (collectively).  Either would meet our minimum needs (AFAICT).
> 

I think the priority limit is the better way, because the % CPU
available to real time threads approach essentially gives you no
realtime scheduling at all.

By limiting priority, you can at least construct userspace solutions
to managing RT threads.

> But, they are not identical, and the best choice depends at least
> partly on the outcome of Ingo's scheduler experiments.  I doubt that
> anyone wants to add both (though it could come down to that, I
> suppose).
> 
> > And finally, with rlimit support, is there any reason why lockup
> > detection and correction can't go into userspace? Even RT
> > throttling could probably be done in a userspace daemon.
> 
> It can.  But, doing it in the kernel is more efficient, and probably
> more reliable.

Possibly. But the people who want a solution seem to be in a very
small minority, and I'm not sure how much you care about efficiency.




-
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: don't let mmap allocate down to zero

[Sytse Wielinga]

On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
> 
> >With some programs the 2.6 kernel can end up allocating memory
> >at address zero, for a non-MAP_FIXED mmap call!  This causes
> >problems with some programs and is generally rude to do. This
> >simple patch fixes the problem in my tests.
> 
> Does this mean that we can't mmap the screen regen buffer at
> 0x000b8000 anymore?

If you would have looked inside mmap.c, you would have seen that his check
is executed *after* trying for a specific address if it was given. Mmapping
0x000b8000 should still work. I don't know if this patch was very clean (it
probably isn't) but what it's supposed to do is only fail if no specific
address has been given to it.

> How do I look at the real-mode interrupt table starting at
> offset 0? You know that the return value of mmap is to be
> checked for MAP_FAILED, not for NULL, don't you?
> 
> What 'C' standard do you refer to? Seg-faults on null pointers
> have nothing to do with the 'C' standard and everything to
> do with the platform.

Oh come on. Every normal program checks whether a variable has been allocated
or not by comparing it to NULL. I have no knowledge of the internals of glibc
though, and wouldn't know whether this should be handled inside the kernel or
if having it checked in glibc and userspace programs that use mmap directly
should be enough, but AFAIK every C coder assumes that NULL pointers point to
nothing.

Sytse
-
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: [Bug 4081] New: OpenOffice crashes while starting due to a threading error

[Parag Warudkar]

Stephen Hemminger wrote:
On my laptop with Fedora Core 3, OpenOffice 1.0.1, 1.0.4 and the pre 2.0 version
all work fine running 2.6.10-FCxx kernel but get a SEGV when running on 
2.6.11-rc1 or 2.6.11-rc2
Any hints?
 

Works fine here -  FC3-x86 on Athlon64 and 2.6.11-rc2 stock. Both  OO.o 
1.1.3 and latest M69 run fine.

-
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/

Lousing interrupt with Geode

[Xose Manuel Fernandez Lorenzo]

I have a IAC-H553 Board with a NS Geode Low-Power CPU:

Working around Cyrix MediaGX virtual DMA bugs.
Enable Memory-Write-back mode on Cyrix/NSC processor.
Enable Memory access reorder on Cyrix/NSC processor.
Enable Incrementor on Cyrix/NSC processor.
CPU: After all inits, caps: 00808131 00818131  0001
CPU: Cyrix Geode(TM) Integrated Processor by National Semi stepping 02
Checking 'hlt' instruction... OK.

with a chipset CS5530A Geode.

I have also a Digital Input Output card, and I have develop a board to
generate an interrupt when and input change.

This has been working under MS-DOS properly, but in Linux i lose some
interrupt (I do not get my isr routine called and in /proc/interrupts
the counter do not increment). 

If I use the same Digital Input Output card whit another CPU and linux
everithing work property.

Have someone find the same problem with Geode?

I use the kernel 2.6.5 from debian with Preemtive.

I am nos suscribe to the kernel list, so please response also to my
email.

Thanks in advance


-
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/

Possible bug in keyboard.c (2.6.10)

[Sasa Stevanovic]

Hi,
I had some problems with my laptop's onetouch keys and it eventually led me to 
keyboard.c file from 2.6.10 kernel (Vojtech Pavlik and others).  There may be 
a bug in the file, please read below.

Well, actually, when all omnibook/messages/setkeycodes/hotkeys/xev/showkey etc 
stuff is stripped off, what remains is that x86_keycodes array has only first 
240 members initialized, while remaining 16 are set to 0 due to [256]:

static unsigned short x86_keycodes[256] = {  };
(For my scenario, workaround was possible.)
I am not sure if this is a bug or not; it worked in 2.4.18 without workaround. 
Might be that someone wanted to prevent reading invalid memory.  There are 
many versions of the file/array definition found on the web, none of which has 
a comment about this.

Please also use my email address <[EMAIL PROTECTED]> if you respond 
to this.  I am a member but not sure for how long (depends on number of 
messages/day).

Thanks,
Sasa
-
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: /proc parent _root == NULL?

[Al Viro]

On Wed, Jan 26, 2005 at 09:33:48PM -0500, John Richard Moser wrote:
> create_proc_entry("kmsg", S_IRUSR, _root);
> 
> So this is asking for proc_root to be filled?
> 
> create_proc_entry("kcore", S_IRUSR, NULL);
> 
> And this is just saying to shove it in proc's root?

NULL is equivalent to _root in that context; moreover, it's better
style - drivers really shouldn't be refering to what is procfs-private
object.

> I'm trying to locate a specific proc entry, using this lovely piece of
> code I ripped off:

That's not something allowed outside of procfs code - lifetime rules
alone make that a Very Bad Idea(tm).  If that's just debugging - OK,
but if your code really uses that stuff, I want details on the intended
use.  In that case your design is almost certainly asking for trouble.
-
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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7

[Jack O'Quin]

Cal <[EMAIL PROTECTED]> writes:

> Consideringthe amount and rate of work in progress, this may well be
> no longer be pertinent, but I'm consistently getting an oops running
> the basic jack_test3.2 with rt-limit-2.6.11-rc2-D7 on SMP (P3 993 x
> 2). The oops and jacktest log are at
>   .

I notice that JACK's call to mlockall() is failing.  This is one
difference between your system and mine (plus, my machine is UP).  

As an experiment, you might try testing with `ulimit -l unlimited'.
-- 
  joq

-
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/3] TIGLUSB Cleanups

[Greg KH]

On Wed, Jan 26, 2005 at 06:01:28PM +0100, Mikkel Krautz wrote:
> On Wed, 26 Jan 2005 08:57:07 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 26, 2005 at 05:48:19PM +0100, Mikkel Krautz wrote:
> > > On Wed, 26 Jan 2005 08:40:10 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Use a different email client, or attach the patches as plain text.
> > > >
> > > > Good luck,
> > > >
> > > > greg k-h
> > > >
> > >
> > > Alright, they're attached this time.
> > > I hope this'll do for now. :-)
> > 
> > Nope, please break them out into the three pieces, in three different
> > emails like you did before so I can apply them all properly.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Should I add "[RESEND]" or something simmilar to the subjects, so they
> can be easily distinguished from the original ones?

Nah, just send them again, I can distinguish them by the fact that they
can actually be applied :)

thanks,

greg k-h
-
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: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

[Eric W. Biederman]

Right now I am very frustrated with reviewing any of the crashdump
patches.  When I make comments usually things change just enough that
what I said is addressed but things are addressed very much at
a surface level.  Which means that if I think any kind of substantial
change is needed the only way I seem to be able to communicate
that is by actually implementing it myself.

Code that works today is great it does manages the job of requirements
capture.   But just throwing code together when you are dealing
with fundamental interface boundaries is not a good way to build
a sustainable design.  And with the crashdump code I want an
interface that is at least as simple and as stable as the syscall
interface.

At the very least if a patch is just a snapshot of your development
process up for comment and you are going to continue on making
headway please say as much.  If I know the code is quite possibly
going to change in some pretty fundamental ways I can stop worrying
about it.  This patch is certainly nothing I would want for more
than a couple of day hack, in my personal development tree.

I will try once again...

There is evil intermingling and false dependency sharing between
the dying kernel and the crash capture kernel in this patch, and
virtually all of the code is unnecessary.  I have already addressed
why.

Vivek Goyal <[EMAIL PROTECTED]> writes:

> On Fri, 2005-01-21 at 16:43, Eric W. Biederman wrote:
> > On deeper review your patch as it stands is incomplete.  In particular
> > you don't provide a way to either hardcode or dynamically set
> > the area you are attempt to reserve to hold the backup region.
> 
> Well. Here is the new patch. This one steals the 640k from top of memory
> region reserved for crash kernel. 
> 
> A new command line parameter (crashbackup=) has been introduced for
> crash dump kernels. This parameter specifies the location of backup
> region from where to retrieve the backup data.

What is wrong with user space doing all of the extra space
reservation?

Could you send this fairly obvious kexec fix, as a separate patch? 

> diff -puN include/linux/kexec.h~crashdump-x86-reserve-640k-memory
> include/linux/kexec.h
> 
> --- linux-2.6.11-rc1/include/linux/kexec.h~crashdump-x86-reserve-640k-memory
> 2005-01-22 14:16:27.0 +0530
> 
> +++ linux-2.6.11-rc1-root/include/linux/kexec.h 2005-01-22 14:16:27.0
> +0530
> 
> @@ -79,7 +79,7 @@ struct kimage {
>   unsigned long control_page;
>  
>   /* Flags to indicate special processing */
> - int type : 1;
> + unsigned int type : 1;
>  #define KEXEC_TYPE_DEFAULT 0
>  #define KEXEC_TYPE_CRASH   1
>  };

Eric
-
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: [Ext2-devel] [PATCH] JBD: journal_release_buffer()

[Stephen C. Tweedie]

Hi,

On Tue, 2005-01-25 at 19:30, Alex Tomas wrote:

>  >> journal_dirty_metadata(handle, bh)
>  >> {
>  >> transaction->t_reserved--;
>  >> handle->h_buffer_credits--;
>  >> if (jh->b_tcount > 0) {
>  >> /* modifed, no need to track it any more */
>  >>  transaction-> t_outstanding_credits++;
>  >>jh-> b_tcount = -1;
>  >>  }
>  >> }
> 
>  SCT> Actually, the whole thing can be wrapped in if (jh->b_tcount > 0) {}, I
>  SCT> think.

> the idea is:
> 1) the sooner we drop reservation, the higher probability to cover many
>changes by single transaction

But that's exactly why we _don't_ want to do this.  You're dropping the
reservation, but remember, we return unused handle credits to the
transaction at the end of the handle's life.

So normally, when you are, for example, appending 4k at a time to a
large file, the first handle in a new transaction gets charged for the
indirect/bitmap updates.  But subsequent ones do not, so as the later
handles end, they return their credits to the transaction.  That allows
large numbers of handles to update the same buffers in the same
transaction.

But by reducing handle->h_buffer_credits early, even if the bh is
already modified in the current transaction, you are preventing the
return of those credits back to the transaction.  Effectively, each
modification of the same bh in the same transaction is being accounted
for separately, so you're charging the transaction multiple times for a
bh which is only going to be journaled once.  That's going to cause the
transaction to be closed early, as our accounting will tell us that the
transaction is full even when it has only a few buffers modified.

> 1) having h_buffer_credits being decremented for each modification
>could help us to debug handle overflow situations
> 
>  SCT> If we do that, do we in fact need t_reserved at all?
> 
> hmm. if t_outstanding_credits holds number of modified buffers,
> then we need sum of all running h_buffer_credits to protect
> from transaction overflow. t_reserved is sum of h_buffer_credits.

Why can't we just maintain t_outstanding_credits for this?  Define that
as the sum of all credits either promised or consumed by any handles.

On journal_start(), t_outstanding_credits += blocks;

On journal_dirty_metadata(), 
{
if (jb->b_tcount > 0) {
/* a promised credit has turned into a consumed one */
handle->h_buffer_credits--;
jh->b_tcount = -1;
}
}

On journal_stop(), any remaining handle credits are promised but
unconsumed; simply return them: 
transaction->t_outstanding_credits -= handle->h_buffer_credits;

As before journal_release_buffer() doesn't have to do anything about
credits because we're only releasing buffers if they have not been
charged for yet.

--Stephen

-
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/3] TIGLUSB Cleanups

[Mikkel Krautz]

This removes the TIGLUSB-maintainers from hte MAINTAINERS-file.
Signed-off-by: Mikkel Krautz <[EMAIL PROTECTED]>
---
MAINTAINERS |7 ---
1 files changed, 7 deletions(-)
--- clean/MAINTAINERS
+++ dirty/MAINTAINERS
@@ -2178,13 +2178,6 @@
M:[EMAIL PROTECTED]
S:Maintained
-TI GRAPH LINK USB (SilverLink) CABLE DRIVER
-P:Romain Lievin
-M:[EMAIL PROTECTED]
-P:Julien Blache
-M:[EMAIL PROTECTED]
-S:Maintained
-
TI PARALLEL LINK CABLE DRIVER
P: Romain Lievin
M: [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: don't let mmap allocate down to zero

[William Lee Irwin III]

On Wed, Jan 26, 2005 at 11:18:08AM -0500, Rik van Riel wrote:
> With some programs the 2.6 kernel can end up allocating memory
> at address zero, for a non-MAP_FIXED mmap call!  This causes
> problems with some programs and is generally rude to do. This
> simple patch fixes the problem in my tests.
> Make sure that we don't allocate memory all the way down to zero,
> so the NULL pointer never gets covered up with anonymous memory
> and we don't end up violating the C standard.
> Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>

SHLIB_BASE does not appear to be present in 2.6.9; perhaps something
else is going on.

I think we are better off:
(a) checking for hitting zero explicitly as opposed to
enforcing a randomly-chosen lower limit for addresses
(b) enforcing vma allocation above FIRST_USER_PGD_NR*PGDIR_SIZE,
to which SHLIB_BASE bears no relation.


-- wli
-
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 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien) - Resubmit #2

[Shawn Starr]

Here is the corrected fix, yeah that didn't make
sense.   
3AM isn't a good time to send patches I guess :-)

 --- Greg KH <[EMAIL PROTECTED]> wrote: 
> On Wed, Jan 26, 2005 at 02:57:35AM -0500, Shawn
> Starr wrote:
> >  static inline unsigned char FAN_TO_REG(unsigned
> rpm, unsigned div)
> >  {
> > -   if (rpm == 0)
> > +   if (rpm <= 0)
> 
> As was pointed out, this doesn't make any sense.
> 
> Care to redo the patch?
> 
> thanks,
> 
> greg k-h
>  

lm80-fixup-2.diff
Description: lm80-fixup-2.diff

[PATCH 3/3] TIGLUSB Cleanups

[Mikkel Krautz]

This removes the TIGLUSB-documentation, silverlink.txt.
Signed-off-by: Mikkel Krautz <[EMAIL PROTECTED]>
---

 silverlink.txt |   78 -
 1 files changed, 78 deletions(-)

--- clean/Documentation/usb/silverlink.txt
+++ dirty/Documentation/usb/silverlink.txt
@@ -1,78 +0,0 @@
--
-Readme for Linux device driver for the Texas Instruments SilverLink cable
-and direct USB cable provided by some TI's handhelds.
--
-
-Author: Romain Liévin & Julien Blache
-Homepage: http://lpg.ticalc.org/prj_usb
-
-INTRODUCTION:
-
-This is a driver for the TI-GRAPH LINK USB (aka SilverLink) cable, a cable 
-designed by TI for connecting their TI8x/9x calculators to a computer 
-(PC or Mac usually). It has been extended to support the USB port offered by
-some latest TI handhelds (TI84+ and TI89 Titanium).
-
-If you need more information, please visit the 'SilverLink drivers' homepage 
-at the above URL.
-
-WHAT YOU NEED:
-
-A TI calculator of course and a program capable to communicate with your 
-calculator.
-TiLP will work for sure (since I am his developer !). yal92 may be able to use
-it by changing tidev for tiglusb (may require some hacking...).
-
-HOW TO USE IT:
-
-You must have first compiled USB support, support for your specific USB host
-controller (UHCI or OHCI).
-
-Next, (as root) from your appropriate modules directory (lib/modules/2.5.XX):
-
-   insmod usb/usbcore.o
-   insmod usb/usb-uhci.oinsmod usb/ohci-hcd.o
-   insmod tiglusb.o
-
-If it is not already there (it usually is), create the device:
-
-   mknod /dev/tiglusb0 c 115 16
-
-You will have to set permissions on this device to allow you to read/write
-from it:
-
-   chmod 666 /dev/tiglusb0
-   
-Now you are ready to run a linking program such as TiLP. Be sure to configure 
-it properly (RTFM).
-   
-MODULE PARAMETERS:
-
-  You can set these with:  insmod tiglusb NAME=VALUE
-  There is currently no way to set these on a per-cable basis.
-
-  NAME: timeout
-  TYPE: integer
-  DEFAULT: 15
-  DESC: Timeout value in tenth of seconds. If no data is available once this 
-   time has expired then the driver will return with a timeout error.
-
-QUIRKS:
-
-The following problem seems to be specific to the link cable since it appears 
-on all platforms (Linux, Windows, Mac OS-X). 
-
-In some very particular cases, the driver returns with success but
-without any data. The application should retry a read operation at least once.
-
-HOW TO CONTACT US:
-
-You can email me at [EMAIL PROTECTED] Please prefix the subject line
-with "TIGLUSB: " so that I am certain to notice your message.
-You can also mail JB at [EMAIL PROTECTED]: he has written the first release of 
-this driver but he better knows the Mac OS-X driver.
-
-CREDITS:
-
-The code is based on dabusb.c, printer.c and scanner.c !
-The driver has been developed independently of Texas Instruments Inc.

Re: 2.6.11-rc2-mm1

[Evgeniy Polyakov]

On Wed, 2005-01-26 at 11:55 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > > <[EMAIL PROTECTED]> wrote:
> > > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > > > <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > Each superio chip has the same logical devices inside.
> > > > > > With your approach we will have following schema:
> > > > > >
> > > > > > bus:
> > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > > > >
> > > > > > Each logical device driver (for existing superio schema)
> > > > > > is about(more than) 150 lines of code.
> > > > > > With your approach above example will be 150*6*4 +
> > > > > > 4*superio_chip_driver_size bytes
> > > > > > of the code.
> > > > >
> > > > > ? Let's count again, shall we? Suppose we have:
> > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > > > have 6 superio interface drivers - gpio, acb, etc...
> > > > > It is exactly the same as your cheme size-wise.
> > > > >
> > > > > There is no need to many-to-many relationship. Each chip is bound to
> > > > > only one chip driver which registers several interfaces. Each
> > > > > interface is bound to only one interface driver. Interface driver is
> > > > > not chip specific, it knows how to run a specific interface (gpio,
> > > > > temp) and relies on chip driver to properly manage access to the
> > > > > hardware. Each combination of inetrface + interface driver produce one
> > > > > class_device (call it sio, serio, whatever). Class device provides
> > > > > unified view of the interface to the userspace.
> > > > >
> > > > > What am I missing?
> > > >
> > > > Since each logical device does not know who use it, it can not be,
> > > > for example, removed optimally.
> > > > You need to run through whole superio device set to find those one that
> > > > has reference to logical device being removed.
> > >
> > > What do you mean by removing optimally? Consider teher 2 scenarios:
> > >  - you unload logical device driver which knows all the logical
> > > devices (interfaces) it is bound to and it releases those devices.
> > 
> > It does not know chip drivers, which reference it.
> 
> Of course it does, every logical device has one parent. Individual
> GPIO pins are not spread across your motherboard. Every one of them
> lives on some chip. They can all be driven by the same driver but they
> are different devices. It is like all your IDE drives are driven by
> the same driver but (unless LVM which is diffrent layer comes to play)
> they are still different drives.

No, there is no "parent".
Each logical device is "shared" between several superio chips.
It is presented design.
More below.

> > We need to scan all superio chips to find that.
> > 
> > > - you unload chip driver which knows what logical devices it has
> > > registered and removes them. Logical devices in turn unbind themselves
> > > from the logical drivers thay are bound to (only one for each device
> > > and they have link).
> > > Seems pretty clean to me.
> > 
> > Yes, since there is sc->ldev relation.
> > 
> > > > And situation become much worse, when we have so called logical device
> > > > clones -
> > > > it is virtual logical device that emulates standard one, but inside
> > > > performs
> > > > in a different way. Clone creates inside superio device(for example such
> > > > device
> > > > can live at different address).
> > > > When you do not have ldev->sc relation, you must traverse through each
> > > > logical device
> > > > in each superio chip to find clones.
> > > > Thus you will need to traverse through each superio chip,
> > > > then through each logical device it references, just to remove one
> > > > logical device.
> > >
> > > I am confused and need a concrete example. I would think that cases
> > > such as these should not require eny special handling, hardware access
> > > should be hidden from logical drivers by the chip driver. Or if only
> > > difference is the port address then it probably should be set by the
> > > chip driver as attribute of logical device.
> > 
> > Consider sc.c and GPIO logical device in SC1100 (scx driver).
> > 
> >/*
> > * SuperIO core is registering logical device.
> > * SuperIO chip knows where it must live.
> > * If logical device being registered lives at the different 
> > 

Re: don't let mmap allocate down to zero

[Chris Friesen]

linux-os wrote:
Does this mean that we can't mmap the screen regen buffer at
0x000b8000 anymore?
How do I look at the real-mode interrupt table starting at
offset 0? You know that the return value of mmap is to be
checked for MAP_FAILED, not for NULL, don't you?
Can't you still map those physical addresses to other virtual addresses?
What 'C' standard do you refer to? Seg-faults on null pointers
have nothing to do with the 'C' standard and everything to
do with the platform.
I believe the ISO/IEC 9899:1999 C Standard explicitly states that 
dereferencing a null pointer with the unary * operator results in 
undefined behavior.

Chris
-
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 19/34]: include/jiffies: add usecs_to_jiffies() function

[Nishanth Aravamudan]

On Tue, Jan 25, 2005 at 06:51:00PM -0800, Andrew Morton wrote:
> Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
> >
> > Please consider applying.
> > 
> >  Description: Add a usecs_to_jiffies() function.
> 
> Please cc linux-kernel on things which aren't utterly trivial?

Sorry, Andrew, I actually meant to, but forgot to change the CC line. Sorry for
the noise directly to you.

-Nish

Description: Add a usecs_to_jiffies() function. This will be used in one of my
subsequent patches. With the potential for dynamic HZ values much higher than
1000, we may need to consider times as small as usecs in terms of jiffies.
We have msecs_to_jiffies(), jiffies_to_msecs() and jiffies_to_usecs(), but no
usecs_to_jiffies(). Please check my math.

Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>

--- 2.6.11-rc2-kj-v/include/linux/jiffies.h 2005-01-24 09:34:19.0 
-0800
+++ 2.6.11-rc2-kj/include/linux/jiffies.h   2005-01-25 13:01:56.0 
-0800
@@ -287,6 +287,19 @@ static inline unsigned long msecs_to_jif
 #endif
 }
 
+static inline unsigned long usecs_to_jiffies(const unsigned int u)
+{
+   if (u > jiffies_to_usecs(MAX_JIFFY_OFFSET))
+   return MAX_JIFFY_OFFSET;
+#if HZ <= 1000 && !(1000 % HZ)
+   return (u + (100 / HZ) - 1000) / (100 / HZ);
+#elif HZ > 1000 && !(HZ % 1000)
+   return u * (HZ / 100);
+#else
+   return (u * HZ + 99) / 100;
+#endif
+}
+
 /*
  * The TICK_NSEC - 1 rounds up the value to the next resolution.  Note
  * that a remainder subtract here would not do the right thing as the
-
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 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien) - Resubmit

[Aurélien Jarno]

Greg KH wrote:
On Wed, Jan 26, 2005 at 02:57:35AM -0500, Shawn Starr wrote:
static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
{
-   if (rpm == 0)
+   if (rpm <= 0)

As was pointed out, this doesn't make any sense.
Care to redo the patch?
Please note that the problem is not present in the lm78 patch as the 
argument is of type int.

Aurelien
--
  .''`.  Aurelien Jarno   GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.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: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[David Mosberger]

> On Wed, 26 Jan 2005 08:52:12 -0800 (PST), Christoph Lameter <[EMAIL 
> PROTECTED]> said:

  Christoph> On Wed, 26 Jan 2005, Martin Schwidefsky wrote:
  >> Why not add an if at the start of gettimeofday to check when the
  >> last ntp updates has been done and if it has been too long since
  >> the last time then call ntp_scale ? That way the update isn't
  >> done on every call to gettimeofday and we don't depend on the
  >> regular timer tick.

  Christoph> Because ia64 does not support calling arbitrary C
  Christoph> functions in fastcalls.

However, it can fall back on a heavy-weight syscall easily.  We
already do that on a number of occasions, e.g., if we find a spinlock
already taken.  I think it would be OK to have gettimeofday
occasionally fall back on the heavy-weight version to do NTP magic.

--david
-
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] FUSE - fix hard link operation

[Miklos Szeredi]

Andrew,

This patch fixes a bug in link, where the wrong inode number was
passed to userspace as the link source.

Needs update to fuse library to 2.2-pre6 as well.

Please apply.

Thanks,
Miklos

Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>

diff -rup linux-2.6.11-rc2-mm1/fs/fuse/dir.c linux-fuse/fs/fuse/dir.c
--- linux-2.6.11-rc2-mm1/fs/fuse/dir.c  2005-01-26 18:30:47.0 +0100
+++ linux-fuse/fs/fuse/dir.c2005-01-26 18:18:58.0 +0100
@@ -360,9 +360,9 @@ static int fuse_link(struct dentry *entr
return -ERESTARTNOINTR;
 
memset(, 0, sizeof(inarg));
-   inarg.newdir = get_node_id(newdir);
+   inarg.oldnodeid = get_node_id(inode);
req->in.h.opcode = FUSE_LINK;
-   req->inode2 = newdir;
+   req->inode2 = inode;
req->in.numargs = 2;
req->in.args[0].size = sizeof(inarg);
req->in.args[0].value = 
diff -rup linux-2.6.11-rc2-mm1/include/linux/fuse.h 
linux-fuse/include/linux/fuse.h
--- linux-2.6.11-rc2-mm1/include/linux/fuse.h   2005-01-26 18:30:53.0 
+0100
+++ linux-fuse/include/linux/fuse.h 2005-01-26 18:18:58.0 +0100
@@ -133,7 +133,7 @@ struct fuse_rename_in {
 };
 
 struct fuse_link_in {
-   __u64   newdir;
+   __u64   oldnodeid;
 };
 
 struct fuse_setattr_in {
-
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: don't let mmap allocate down to zero

[Rik van Riel]

On Wed, 26 Jan 2005, linux-os wrote:
Wrong! A returned value of 0 is perfectly correct for mmap()
when mapping a fixed address. The attached code shows it working
  
The code that is patched is only run in case of a non-MAP_FIXED
mmap() call...
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
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] unexport register_cpu and unregister_cpu

[Keshavamurthy Anil S]

On Wed, Jan 26, 2005 at 12:55:47AM -0600, Nathan Lynch wrote:
> http://linus.bkbits.net:8080/linux-2.5/[EMAIL 
> PROTECTED]|src/|src/drivers|src/drivers/base|related/drivers/base/cpu.c
> 
> This changeset introduced exports for register_cpu and unregister_cpu
> right after 2.6.10.  As far as I can tell these are not called from any
> code which can be built as a module, and I can't think of a good reason
> why any out of tree code would use them.  Unless I've missed something,
> can we remove them before 2.6.11?

No this is not correct. ACPI processor.ko driver which supports
physical CPU hotplug needs register_cpu() and unregister_cpu() functions
for dynamically hotadd/hotremove support of the processors.

Please see drivers/acpi/processor_core.c  
acpi_processor_hotadd_init() -> arch_register_cpu() ->
->register_cpu().

-Anil


-
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, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Jack O'Quin]

Nick Piggin <[EMAIL PROTECTED]> writes:

> I'm a bit concerned about this kind of policy and breakage of
> userspace APIs going into the kernel. I mean, if an app is
> succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
> scheduler does something else, that could be undesirable in some
> situations.

True.  It's similar to running out of CPU bandwidth, but not quite.

AFAICT, the new behavior still meets the letter of the standard[1].
Whether it meets the spirit of the standard is debatable.  My own
feeling is that it probably does, and that making SCHED_FIFO somewhat
less powerful but much easier to access is a reasonable tradeoff.

 [1] http://www.opengroup.org/onlinepubs/007908799/xsh/realtime.html

If I understand Ingo's proposal correctly, setting RLIMIT_RT_CPU to
zero and then requesting SCHED_FIFO (with CAP_SYS_NICE) yields exactly
the former behavior.  This will probably be the default setting.

> Secondly, I think we should agree upon and get the basic rlimit
> support in ASAP, so the userspace aspect can be firmed up a bit
> for people like Paul and Jack (this wouldn't preclude further
> work from happening in the scheduler afterwards).

I don't sense much opposition to adding rlimit support for realtime
scheduling.  I personally don't think it a very good way to manage
this problem.  But, it certainly can be made to work.

The main point of discussion is: exactly what resource should it
limit?  Arjan and Chris proposed to limit priority.  Ingo proposed to
limit the percentage of each CPU available for realtime threads
(collectively).  Either would meet our minimum needs (AFAICT).

But, they are not identical, and the best choice depends at least
partly on the outcome of Ingo's scheduler experiments.  I doubt that
anyone wants to add both (though it could come down to that, I
suppose).

> And finally, with rlimit support, is there any reason why lockup
> detection and correction can't go into userspace? Even RT
> throttling could probably be done in a userspace daemon.

It can.  But, doing it in the kernel is more efficient, and probably
more reliable.
-- 
  joq
-
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: /proc parent _root == NULL?

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Randy.Dunlap wrote:
> John Richard Moser wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> proc_misc_init() has both these lines in it:
>>
>> entry = create_proc_entry("kmsg", S_IRUSR, _root);
>> proc_root_kcore = create_proc_entry("kcore", S_IRUSR, NULL);
>>
>> Both entries show up in /proc, as /proc/kmsg and /proc/kcore.  So I ask,
>> as I can't see after several minutes of examination, what's the
>> difference?  Why is NULL used for some and _root used for others?
>>
>> I'm looking at 2.6.10
> 
> 
> create_proc_entry() passes  to proc_create().
> See proc_create():
> ...
> This is an error path:
> if (!(*parent) && xlate_proc_name(name, parent, ) != 0)
> goto out;
> but xlate_proc_name() searches for a /proc/ and returns the
> all-but-final-part-of-name *parent (hope that makes some sense,
> see the comments above the function), so it returns _root.
> 
> HTH.  If not, fire back.

create_proc_entry("kmsg", S_IRUSR, _root);

So this is asking for proc_root to be filled?

create_proc_entry("kcore", S_IRUSR, NULL);

And this is just saying to shove it in proc's root?


I'm trying to locate a specific proc entry, using this lovely piece of
code I ripped off:

/*
 * Find a proc entry
 * Duplicated from remove_proc_entry()
 */
struct proc_dir_entry **get_proc_entry(const char *name, struct
proc_dir_entry *parent) {
struct proc_dir_entry **p;
const char *fn = name;
int len;
if (!parent && xlate_proc_name(name, , ) != 0)
goto out;
len = strlen(fn);
for (p = >subdir; *p; p=&(*p)->next ) {
if (!proc_match(len, fn, *p))
continue;
return p;
}
out:
return NULL;
}


And I'm trying to figure out if, say, /proc/devices would be found by...

get_proc_entry("devices",NULL);
- -OR-
get_proc_entry("devices",_root);

Oh well.  I'll figure it out eventually.  :)  I've already caused my
kernel to not boot :) figured it out too, it was that very function
above; I replaced a chunk of remove_proc_entry() with a modified version
of that and I'd busted it horribly so it didn't work.  Just more things
to remind me that I know not what it is I do.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+FMLhDd4aOud5P8RAp1XAJ9j+ezlZgYuXpTmeaNSlQcC3xkb+ACaAjA8
D3NEZH4Drey2nuMCXZwK6sE=
=o5P7
-END PGP SIGNATURE-
-
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 check the validity of a running daemon on Linux

[ych43]

Hi,
  Does anybody know how to check the validity of a deamon. which runs on Linux 
-platform host . This daemon can save some information in a log file of the 
host. I mean that if an attacker compromises this host and gets root access, 
he can replace this daemon with a rogue version. Therfefore, the information 
saved on the log file is incorrect. So how can I check the validity of the 
daemon to show this  daemon is correct version and not a rogue version. So I 
trust the information saved on the host.
  Cheers


-
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-rc2-mm1

[Dmitry Torokhov]

On Wed, 26 Jan 2005 20:39:36 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-26 at 11:55 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
> > <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > > > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > > > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > > Each superio chip has the same logical devices inside.
> > > > > > > With your approach we will have following schema:
> > > > > > >
> > > > > > > bus:
> > > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > >
> > > > > > > Each logical device driver (for existing superio schema)
> > > > > > > is about(more than) 150 lines of code.
> > > > > > > With your approach above example will be 150*6*4 +
> > > > > > > 4*superio_chip_driver_size bytes
> > > > > > > of the code.
> > > > > >
> > > > > > ? Let's count again, shall we? Suppose we have:
> > > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > > > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > > > > have 6 superio interface drivers - gpio, acb, etc...
> > > > > > It is exactly the same as your cheme size-wise.
> > > > > >
> > > > > > There is no need to many-to-many relationship. Each chip is bound to
> > > > > > only one chip driver which registers several interfaces. Each
> > > > > > interface is bound to only one interface driver. Interface driver is
> > > > > > not chip specific, it knows how to run a specific interface (gpio,
> > > > > > temp) and relies on chip driver to properly manage access to the
> > > > > > hardware. Each combination of inetrface + interface driver produce 
> > > > > > one
> > > > > > class_device (call it sio, serio, whatever). Class device provides
> > > > > > unified view of the interface to the userspace.
> > > > > >
> > > > > > What am I missing?
> > > > >
> > > > > Since each logical device does not know who use it, it can not be,
> > > > > for example, removed optimally.
> > > > > You need to run through whole superio device set to find those one 
> > > > > that
> > > > > has reference to logical device being removed.
> > > >
> > > > What do you mean by removing optimally? Consider teher 2 scenarios:
> > > >  - you unload logical device driver which knows all the logical
> > > > devices (interfaces) it is bound to and it releases those devices.
> > >
> > > It does not know chip drivers, which reference it.
> >
> > Of course it does, every logical device has one parent. Individual
> > GPIO pins are not spread across your motherboard. Every one of them
> > lives on some chip. They can all be driven by the same driver but they
> > are different devices. It is like all your IDE drives are driven by
> > the same driver but (unless LVM which is diffrent layer comes to play)
> > they are still different drives.
> 
> No, there is no "parent".
> Each logical device is "shared" between several superio chips.
> It is presented design.

Ok, I presume that userspace although you saying that logical device
is "shared" between chips different GPIO pins still visible to
userspace as separate entities (correct me if I am wrong). That means
that you chose in your implementation not to abstract out individual
parts of SuperIO container as individual devices and instead have
several logical drivers bound directly to a same chip. And that is why
you need n-m relationship and inability to fit to the driver model and
potential issues with power management. Instead of this

  / 
  -  - 
 \ 

you need this

/ - 
 -  - 
\  - 

This will decouple chip drivers from the logical drivers.

I argue that present design is sub-optimal and will hurt in the long run.

> 
> > > We need to scan all superio chips to find that.
> > >
> > > > - you unload chip driver which knows what logical devices it has
> > > > registered and removes them. Logical devices in turn unbind themselves
> > > > from the logical drivers thay are bound to (only one for each device
> > > > and they have link).
> > > > Seems pretty clean to me.
> > >
> > > Yes, since there is sc->ldev relation.
> > >
> > > > > And situation become much worse, when we have so called logical device
> > > > > clones -
> > > > > it is virtual logical device that emulates 

Re: i8042 access timings

[Dmitry Torokhov]

On Wed, 26 Jan 2005 12:05:47 -0500 (EST), linux-os
<[EMAIL PROTECTED]> wrote:
> On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
> 
> > On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 
> > wrote:
> >> On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> >>> @@ -213,7 +217,10 @@
> >>>   if (!retval)
> >>>   for (i = 0; i < ((command >> 8) & 0xf); i++) {
> >>>   if ((retval = i8042_wait_read())) break;
> >>> - if (i8042_read_status() & I8042_STR_AUXDATA)
> >>> + udelay(I8042_STR_DELAY);
> >>> + str = i8042_read_status();
> >> []
> >>> + udelay(I8042_DATA_DELAY);
> >>> + if (str & I8042_STR_AUXDATA)
> >>>   param[i] = ~i8042_read_data();
> >>>   else
> >>>   param[i] = i8042_read_data();
> >>
> >> We may as well drop the negation. It's a bad way to signal the data came
> >> from the AUX port. Then we don't need the extra status read and can just
> >> proceed to read the data, since IMO we don't need to wait inbetween,
> >> even according to the IBM spec.
> >
> > Do you remember why it has been done to begin with?
> >
> > --
> > Dmitry
> 
> 
> The only time you need any delay at all is after you have send
...

Thank you Richard for this thorough explanation of IO access but I was
actually asking why we wanted to invert AUX data.

-- 
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: don't let mmap allocate down to zero

[Olivier Galibert]

On Wed, Jan 26, 2005 at 01:20:53PM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Olivier Galibert wrote:
> >Given that the man page itself says that unless you're using MAP_FIXED
> >start is only a hint and you should use 0 if you don't care things can
> >get real annoying real fast.  Imagine if you want to mmap a <4K file
> >and mmap then returns 0, i.e. NULL, as the mapping address as you
> >asked.  It's illegal from the point of view of susv3[1] and it's real
> >annoying in a C/C++ program.
> 
> mmap() can (will) return 0 if you use 0 as the hint and use MAP_FIXED
> at 0. That's the reason why one does NOT check for NULL with mmap() but
> for MAP_FAILED (which on this system is (void *)-1.

All the paragraph was under an obvious "when you do not use MAP_FIXED"
precondition.  The patch is not supposed to change anything to the
MAP_FIXED case.  Malloc does not use MAP_FIXED.  Usual file mmaping
as an alternative to read() does not use MAP_FIXED.

  OG.
-
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-rc2/ext3 quota allocation bug on error path ...

[Andreas Gruenbacher]

Hello,

On Sat, 2005-01-22 at 16:50, Herbert Poetzl wrote:
> --- ./fs/ext3/xattr.c.orig2005-01-22 15:07:50 +0100
> +++ ./fs/ext3/xattr.c 2005-01-22 16:45:09 +0100
> @@ -773,7 +773,7 @@ inserted:
>   error = ext3_journal_get_write_access(handle,
> new_bh);
>   if (error)
> - goto cleanup;
> + goto cleanup_dquot;
>   lock_buffer(new_bh);
>   BHDR(new_bh)->h_refcount = cpu_to_le32(1 +
>   le32_to_cpu(BHDR(new_bh)->h_refcount));
> @@ -783,7 +783,7 @@ inserted:
>   error = ext3_journal_dirty_metadata(handle,
>   new_bh);
>   if (error)
> - goto cleanup;
> + goto cleanup_dquot;
>   }
>   mb_cache_entry_release(ce);
>   ce = NULL;
> @@ -844,6 +844,10 @@ cleanup:
>  
>   return error;
>  
> +cleanup_dquot:
> + DQUOT_FREE_BLOCK(inode, 1);
> + goto cleanup;
> +
>  bad_block:
>   ext3_error(inode->i_sb, __FUNCTION__,
>  "inode %ld: bad block %d", inode->i_ino,

looks good. Can this please be added?

THanks,
-- 
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX GMBH

-
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: don't let mmap allocate down to zero

[linux-os]

On Wed, 26 Jan 2005, Bryn Reeves wrote:
On Wed, 2005-01-26 at 17:34, Chris Friesen wrote:
linux-os wrote:
Does this mean that we can't mmap the screen regen buffer at
0x000b8000 anymore?
How do I look at the real-mode interrupt table starting at
offset 0? You know that the return value of mmap is to be
checked for MAP_FAILED, not for NULL, don't you?
Can't you still map those physical addresses to other virtual addresses?
I think that's the case. The 0 address as refered to here is only for
the user virtual address space.
What 'C' standard do you refer to? Seg-faults on null pointers
have nothing to do with the 'C' standard and everything to
do with the platform.
I believe the ISO/IEC 9899:1999 C Standard explicitly states that
dereferencing a null pointer with the unary * operator results in
undefined behavior.
Exactly. Undefined. VAX/UNIX allowed assignment to null pointers. BUT
it's now such a commonly held assumption that a null pointer is not
valid that things will break if this is changed. Doesn't glibc malloc
use mmap for small allocations? From the man page:
Wrong! A returned value of 0 is perfectly correct for mmap()
when mapping a fixed address. The attached code shows it working
perfectly while returning NULL, that event being put on the
terminal.
Any kernel changes that break this code are wrong. There are
many 'C' runtime library functions that signal a problem (or
should signal a problem) by returning NULL. That is, however,
the documented behavior of those procedures. Even malloc()
which __should__ show a failure to allocate by returning NULL,
doesn't work that way because the allocation never fails
(even if you are out of memory) as long as the user address
space hasn't been corrupted by the user (overwriting buffers).
The seg-fault you get when you de-reference a pointer to NULL
is caused by the kernel. You are attempting to access memory
that has not been mapped into your address space. Once that
memory gets mmap()ed, you will no longer get a seg-fault.
Again, the seg-fault has nothing to do with 'C'. It's an
implementation behavior that can be changed with mmap().
[SNIPPED...]
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define xxDEBUG

#if !defined(PAGE_SIZE)
#define PAGE_SIZE 0x1000
#endif
#if !defined(PAGE_MASK)
#define PAGE_MASK ~(PAGE_SIZE - 1)
#endif
#if !defined(MAP_FAILED)
#define MAP_FAILED (void *) -1
#endif
#define UL unsigned long

#define ERRORS \
{ fprintf(stderr, errmsg, __LINE__,\
  __FILE__, errno, strerror(errno));\
  exit(EXIT_FAILURE); }

#ifdef DEBUG
#define DEB(f) (f)
#else
#define DEB(f)
#endif

static const char errmsg[]="Error at line %d, file %s (%d) [%s]\n";
static const char mapfile[]="/dev/mem";
#define PROT (PROT_READ|PROT_WRITE)
#define FLAGS (MAP_FIXED|MAP_SHARED)
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*/
/*
 *  This writes a 'debug-like' dump out the screen. It always writes
 *  16 lines of 16 characters. It returns the last address displayed.
 */
static off_t dump(off_t addr);

static off_t dump(off_t addr)
{
size_t i, j;
int fd;
caddr_t mem;
off_t next;
unsigned char c, *buf;

next = addr; 
addr &= PAGE_MASK;
if((fd = open(mapfile, O_RDWR)) < 0)
ERRORS;

if((mem = mmap((caddr_t)addr, PAGE_SIZE * 2, PROT, FLAGS, fd, addr)) == 
MAP_FAILED)
{
(void)close(fd);
fprintf(stderr, "\tCan't map address %08lX\n", (UL) addr);
return (off_t)mem;
} 


printf("mmap returned %p  (0x%08x)\n", mem, (size_t) mem);

buf = (unsigned char *) next;
DEB(fprintf(stderr, "Mapped address = 0x%lx\n", addr));
DEB(fprintf(stderr, "Buffer address = %p\n", buf));

for(i=0; i< 0x10; i++)
{
fprintf(stdout, "\n%08lX ", (UL) next);
next += 0x10;
for(j=0; j< 0x10; j++)
fprintf(stdout, "%02X ", (unsigned int) *buf++);
buf -= 0x10;
for(j=0; j<0x10; j++)
{
c = *buf++;
if((c < (unsigned char) ' ') || (c > (unsigned char) 'z'))
c = (unsigned char) '.';
fprintf(stdout, "%c", c);
}
}
fprintf(stdout, "\n");
(void)fflush(stdout);
(void)close(fd);
if(munmap(mem, PAGE_SIZE)< 0)
ERRORS;
return next;
}

void usage(char *cp)
{
fprintf(stderr, "Usage\n%s  [end address]\n", cp);
exit(EXIT_FAILURE);
}

int main(int args, char *argv[])
{
off_t addr;
off_t end;

if(args < 2)
usage(argv[0]);
end = 0;
if(sscanf(argv[1], "%lx", ) != 1)
usage(argv[0]);
if(argv[2] != NULL)
(void)sscanf(argv[2], "%lx", );
do {
if((addr = dump(addr)) == 0x)
break;

Re: [PATCH 2.6.11-rc2] modules: add version and srcversion to sysfs

[Rusty Russell]

On Wed, 2005-01-26 at 14:32 +, Paulo Marques wrote:
> Matt Domsch wrote:
> > [...]
> >  
> > +static char *strdup(const char *str)
...
> Actually, I've just grep'ed the entire tree and there are about 7 
> similar implementations all over the place:

Wow, I'd never noticed.  Linus, please apply 8)

Rusty.
Name: kstrdup
Author: Neil Brown, Rusty Russell and Robert Love
Status: Trivial

Everyone loves reimplementing strdup.  Give them a kstrdup.

Index: linux-2.6.11-rc2-bk4-Misc/include/linux/string.h
===
--- linux-2.6.11-rc2-bk4-Misc.orig/include/linux/string.h   2004-05-10 
15:13:54.0 +1000
+++ linux-2.6.11-rc2-bk4-Misc/include/linux/string.h2005-01-27 
13:08:30.042035568 +1100
@@ -88,6 +88,8 @@
 extern void * memchr(const void *,int,__kernel_size_t);
 #endif
 
+extern char *kstrdup(const char *s, int gfp);
+
 #ifdef __cplusplus
 }
 #endif
Index: linux-2.6.11-rc2-bk4-Misc/lib/string.c
===
--- linux-2.6.11-rc2-bk4-Misc.orig/lib/string.c 2005-01-27 11:26:15.0 
+1100
+++ linux-2.6.11-rc2-bk4-Misc/lib/string.c  2005-01-27 13:08:30.080029792 
+1100
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifndef __HAVE_ARCH_STRNICMP
 /**
@@ -599,3 +600,19 @@
 }
 EXPORT_SYMBOL(memchr);
 #endif
+
+/*
+ * kstrdup - allocate space for and copy an existing string
+ *
+ * @s: the string to duplicate
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ */
+char *kstrdup(const char *s, int gfp)
+{
+   char *buf = kmalloc(strlen(s)+1, gfp);
+   if (buf)
+   strcpy(buf, s);
+   return buf;
+}
+
+EXPORT_SYMBOL(kstrdup);

-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

-
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-rc2-mm1: SuperIO scx200 breakage

[Evgeniy Polyakov]

On Wed, 26 Jan 2005 19:19:41 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:

> On Wed, Jan 26, 2005 at 07:38:48PM +0300, Evgeniy Polyakov wrote:
> >...
> > Btw, where was comments about w1, kernel connector and acrypto? 
> > They were presented several times in lkml and all are completely new
> > subsystems.
> > Should I stop developing just because I did not get comments?
> >...
> 
> I sent you comments regarding w1 two months ago regarding:
> - the unneeded dscore -> ds9490r rename in the Makefile
> - completely unused EXPORT_SYMBOL's (that seem to be still unused today)
> 
> Being honest, I have to admit that your reactions didn't sound as if you 
> were waiting for comments.
> 
> > Thank you.

I greatly appreciate your comments, and they were addressed.
Part of exported symbols are unexported, patch is just waiting to be sent,
but I do not agree with dscore rename. I just do not understand it's advantage.

> cu
> Adrian
> 
> -- 
> 
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed


Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt
-
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] oprofile: falling back on timer interrupt mode

[Olaf Hering]

 On Wed, Jan 26, Linux Kernel Mailing List wrote:

> ChangeSet 1.2038, 2005/01/25 20:31:01-08:00, [EMAIL PROTECTED]
> 
>   [PATCH] oprofile: falling back on timer interrupt mode

> 
>  arch/alpha/oprofile/common.c |6 --
>  arch/arm/oprofile/common.c   |7 +--
>  arch/arm/oprofile/init.c |8 ++--
>  arch/i386/oprofile/init.c|4 +++-
>  arch/ia64/oprofile/init.c|8 ++--
>  arch/m32r/oprofile/init.c|3 ++-
>  arch/parisc/oprofile/init.c  |3 ++-
>  arch/ppc64/oprofile/common.c |6 --
>  arch/s390/oprofile/init.c|3 ++-
>  arch/sh/oprofile/op_model_null.c |3 ++-
>  arch/sparc64/oprofile/init.c |3 ++-
>  drivers/oprofile/oprof.c |6 +++---
>  include/linux/oprofile.h |2 +-
>  13 files changed, 42 insertions(+), 20 deletions(-)

This misses arch/ppc

-
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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7

[Jack O'Quin]

Cal <[EMAIL PROTECTED]> writes:

> Jack O'Quin wrote:
>> I notice that JACK's call to mlockall() is failing.  This is one
>> difference between your system and mine (plus, my machine is UP).
>> As an experiment, you might try testing with `ulimit -l unlimited'.
>
> I went for the panic retraction on the first report when I saw the
> failures in the log.  With ulimit -l unlimited, jack seems
> happier. Before the change, ulimit -l showed 32.
>
> At what feels like approaching the end of the run, it still goes clunk
> totally so, dead and gone!
>
> 
>
> I'll re-read the mails that have gone by, and think about the next step.

You seem to have eliminated the mlock() failure as the cause of this
crash.  It should not have caused it anyway, but it *was* one
noticeable difference between your tests and mine.  Since
do_page_fault() appears in the backtrace, that is useful to know.

The other big difference is SMP.  What happens if you build a UP
kernel and run it on your SMP machine?
-- 
  joq
-
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 1/1] uml: Kconfig_arch little cleanup (to merge before 2.6.11)

[blaisorblade]

arch/um/Kconfig_arch is actually a symlink, so
* Remove it from the tree.
* Make sure it is removed during make mrproper.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---

 linux-2.6.11-paolo/arch/um/Makefile |8 ++--
 linux-2.6.11/arch/um/Kconfig_arch   |   16 
 2 files changed, 6 insertions(+), 18 deletions(-)

diff -L arch/um/Kconfig_arch -puN arch/um/Kconfig_arch~uml-quick-fix-Makefile 
/dev/null
--- linux-2.6.11/arch/um/Kconfig_arch
+++ /dev/null   2005-01-24 17:16:49.498209144 +0100
@@ -1,16 +0,0 @@
-config 64_BIT
-   bool
-   default n
-
-config TOP_ADDR
-   hex
-   default 0xc000 if !HOST_2G_2G
-   default 0x8000 if HOST_2G_2G
-
-config 3_LEVEL_PGTABLES
-   bool "Three-level pagetables"
-   default n
-   help
-   Three-level pagetables will let UML have more than 4G of physical
-   memory.  All the memory that can't be mapped directly will be treated
-   as high memory.
diff -puN arch/um/Makefile~uml-quick-fix-Makefile arch/um/Makefile
--- linux-2.6.11/arch/um/Makefile~uml-quick-fix-Makefile2005-01-26 
19:58:50.149680728 +0100
+++ linux-2.6.11-paolo/arch/um/Makefile 2005-01-26 19:58:50.152680272 +0100
@@ -20,8 +20,11 @@ SYMLINK_HEADERS := archparam.h system.h 
arch-signal.h module.h vm-flags.h
 SYMLINK_HEADERS := $(foreach 
header,$(SYMLINK_HEADERS),include/asm-um/$(header))
 
-# The "os" symlink is only used by arch/um/include/os.h, which includes
+# XXX: The "os" symlink is only used by arch/um/include/os.h, which includes
 # ../os/include/file.h
+#
+# These are cleaned up during mrproper. Please DO NOT fix it again, this is
+# the Correct Thing(tm) to do!
 ARCH_SYMLINKS = include/asm-um/arch $(ARCH_DIR)/include/sysdep $(ARCH_DIR)/os \
$(SYMLINK_HEADERS) $(ARCH_DIR)/include/uml-config.h
 
@@ -134,7 +137,8 @@ CLEAN_FILES += linux x.i gmon.out $(ARCH
$(GEN_HEADERS) $(ARCH_DIR)/include/skas_ptregs.h
 
 MRPROPER_FILES += $(SYMLINK_HEADERS) $(ARCH_SYMLINKS) \
-   $(addprefix $(ARCH_DIR)/kernel/,$(KERN_SYMLINKS)) $(ARCH_DIR)/os
+   $(addprefix $(ARCH_DIR)/kernel/,$(KERN_SYMLINKS)) $(ARCH_DIR)/os \
+   $(ARCH_DIR)/Kconfig_arch
 
 archclean:
$(Q)$(MAKE) $(clean)=$(ARCH_DIR)/util
_
-
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: don't let mmap allocate down to zero

[linux-os]

On Wed, 26 Jan 2005, Rik van Riel wrote:
On Wed, 26 Jan 2005, linux-os wrote:
Wrong! A returned value of 0 is perfectly correct for mmap()
when mapping a fixed address. The attached code shows it working
 
The code that is patched is only run in case of a non-MAP_FIXED
mmap() call...
That's good then. I needed to make sure. Lots of embedded stuff
peeks and pokes at ix86 low-memory physical addresses.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: don't let mmap allocate down to zero

[linux-os]

On Wed, 26 Jan 2005, Olivier Galibert wrote:
On Wed, Jan 26, 2005 at 01:20:53PM -0500, linux-os wrote:
On Wed, 26 Jan 2005, Olivier Galibert wrote:
Given that the man page itself says that unless you're using MAP_FIXED
start is only a hint and you should use 0 if you don't care things can
get real annoying real fast.  Imagine if you want to mmap a <4K file
and mmap then returns 0, i.e. NULL, as the mapping address as you
asked.  It's illegal from the point of view of susv3[1] and it's real
annoying in a C/C++ program.
mmap() can (will) return 0 if you use 0 as the hint and use MAP_FIXED
at 0. That's the reason why one does NOT check for NULL with mmap() but
for MAP_FAILED (which on this system is (void *)-1.
All the paragraph was under an obvious "when you do not use MAP_FIXED"
precondition.  The patch is not supposed to change anything to the
MAP_FIXED case.  Malloc does not use MAP_FIXED.  Usual file mmaping
as an alternative to read() does not use MAP_FIXED.
 OG.
Okay. That's fine.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: don't let mmap allocate down to zero

[Chris Friesen]

Bryn Reeves wrote:
RETURN VALUE
  For calloc() and malloc(), the value returned is a pointer to the
  allocated  memory,  which  is suitably aligned for any kind of
  variable, or NULL if the request fails.
This could get pretty confusing if NULL was a valid address...
Internally the library can use mmap().  Presumably they will map a 
MAP_FAILED return code from mmap() to a NULL return code in malloc().

Chris
-
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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7

[Cal]

Jack O'Quin wrote:
You seem to have eliminated the mlock() failure as the cause of this
crash.  It should not have caused it anyway, but it *was* one
noticeable difference between your tests and mine.  Since
do_page_fault() appears in the backtrace, that is useful to know.
The other big difference is SMP.  What happens if you build a UP
kernel and run it on your SMP machine?
Sorry for the delay, some sleep required. A build without SMP also 
fails, with multiple oops.
  .

cheers, Cal
(NetEase AntiSpam+ at mail.edu.cn has been bouncing someone's copy)
-
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: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

[Andrew Morton]

[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> There is evil intermingling and false dependency sharing between
>  the dying kernel and the crash capture kernel in this patch,

yikes!  I'll drop it from -mm while we have a rethink.
-
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-rc2-mm1: SuperIO scx200 breakage

[Jean Delvare]

[Voluntarily skipping a large part of the discussion so as to stop
wasting everyone's time and focus on the one technical point I am
interested in.]

Hi Evgeniy,

> As I saw from different documentation - logical devices itself are the
> same.
> 
> And it is the same for superio standard.
> 
> For example sc1100 and pc87366 superio chips have the same logical
> inside, although different logical device set.
> 
> (...)
> 
> Not only access.
> Logic inside superio chip is submitted to superio standard.
> I designed(at least tried to) superio subsistem
> that it can handle all differencies using per device callbacks.

I would like to ensure that we agree on what is common to all Super-I/O
chips (as per Intel's LPC specification).

1* Super-I/O are accessed at I/O addresses 0x2e+0x2f or alternate
addresses 0x4e+0x4f.

2* These addresses give access to a 256 byte addressing space.

3* Super-I/O chips are divided in logical devices, which can be selected
by writing its id to 0x07. What each logical device does is not
standardized (depends of the chip).

4* Range 0x00-0x2f is common to all logical devices, while range
0x30-0xff is logical-device specific.

5* Range 0x20-0x2f contains chip-wide identification and configuration
registers. Definition of these registers is not standardized.

6* 0x31 controls the activation of each logical device, 0x60-0x63 its
base address, 0x70-0x73 its interrupts. Definition of these registers is
standardized.

7* Range 0xf0-0xff contains logical device-specific configuration
registers. Definition of these registers is not standardized.

And that's about it. The way each logical device works (how registers
are mapped from the base address) is completely chip-specific.

Do we agree on all this, or did I miss somthing? I would like to make
sure that, when you refer to sharing as much code as possible between
the various Super-I/O chips, you really mean the organization of logical
devices within the Super-I/O (selection, retrieval of base address and
interrupt configuration) and not the logical devices themselves.

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.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: thoughts on kernel security issues

[Olaf Hering]

 On Wed, Jan 26, Linus Torvalds wrote:

> The biggest part of that is having nice interfaces. If you have good 
> interfaces, bugs are less likely to be problematic. For example, the 
> "seq_file" interfaces for /proc were written to clean up a lot of common 
> mistakes, so that the actual low-level code would be much simpler and not 
> have to worry about things like buffer sizes and page boundaries. I don't 
> know/remember if it actually fixed any security issues, but I'm confident 
> it made them less likely, just by making it _easier_ to write code that 
> doesn't have silly bounds problems.

And, did that nice interface help at all? No, it did not.
Noone made seqfile mandatory in 2.6.
Now we have a few nice big patches to carry around because every driver
author had its own proc implementation. Well done...

-
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] unexport register_cpu and unregister_cpu

[Nathan Lynch]

On Wed, 2005-01-26 at 10:22 -0800, Keshavamurthy Anil S wrote:
> On Wed, Jan 26, 2005 at 12:55:47AM -0600, Nathan Lynch wrote:
> > http://linus.bkbits.net:8080/linux-2.5/[EMAIL 
> > PROTECTED]|src/|src/drivers|src/drivers/base|related/drivers/base/cpu.c
> > 
> > This changeset introduced exports for register_cpu and unregister_cpu
> > right after 2.6.10.  As far as I can tell these are not called from any
> > code which can be built as a module, and I can't think of a good reason
> > why any out of tree code would use them.  Unless I've missed something,
> > can we remove them before 2.6.11?
> 
>   No this is not correct. ACPI processor.ko driver which supports
> physical CPU hotplug needs register_cpu() and unregister_cpu() functions
> for dynamically hotadd/hotremove support of the processors.

I do not understand your objection.  The processor module does not call
the interfaces in question directly.  They are called only from arch
setup code (e.g. arch/ia64/kernel/topology.c) which is never built as a
module.

> Please see drivers/acpi/processor_core.c  
>   acpi_processor_hotadd_init() -> arch_register_cpu() ->
>   ->register_cpu().

Sure -- the arch_register_cpu and arch_unregister_cpu symbols need to be
exported for this use (and they are).  Exporting register_cpu and
unregister_cpu is unnecessary.

I double-checked an ia64 build with CONFIG_ACPI_HOTPLUG_CPU=y and
CONFIG_ACPI_PROCESSOR=m and saw no errors or warnings caused by the
change...

Nathan

-
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: don't let mmap allocate down to zero

[Chris Friesen]

linux-os wrote:
The seg-fault you get when you de-reference a pointer to NULL
is caused by the kernel. You are attempting to access memory
that has not been mapped into your address space. Once that
memory gets mmap()ed, you will no longer get a seg-fault.
Again, the seg-fault has nothing to do with 'C'. It's an
implementation behavior that can be changed with mmap().
The segfault *does* have something to do with C.  The standard says that 
the result of dereferencing a NULL pointer is *undefined*.  Not 
implementation-defined, but undefined.  Anything relying on 
dereferencing NULL pointers is not valid C code.

Chris
-
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: [BUG] Onboard Ethernet Pro 100 on a SMP box: a very strange errors

[Chris Leech]

On Wed, 26 Jan 2005 07:37:49 +0500, Denis Zaitsev <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 25, 2005 at 11:19:11PM +0200, Denis Vlasenko wrote:
> >
> > Something corrupts packets. It can be sending NIC, switch in the middle,
> > or receiving NIC.
> 
> Changing the receiving card closes the question.  Doesn't it matter?

Take a look at this technical advisory for the STL2 board, I'm fairly
sure this is your issue.
http://support.intel.com/support/motherboards/server/sb/CS-010790.htm

IP fragmented packets as part of an NFS file transfer are improperly
being identified as TCO management packets and are being routed to the
BMC.  The fix is to upgrade the BMC firmware.

Updated BMC firmware and BIOS images for this board are available at
http://support.intel.com/support/motherboards/server/STL2/sb/CS-007118.htm

- Chris
-
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-rc2-mm1: SuperIO scx200 breakage

[Christoph Hellwig]

On Wed, Jan 26, 2005 at 01:12:34PM +, Russell King wrote:
> On Wed, Jan 26, 2005 at 10:14:34AM +, Christoph Hellwig wrote:
> > That's simply not true.  The amount of patches submitted is extremly
> > huge and the reviewers don't have time to look at everythning.
> > 
> > If no one replies it simply means no one has looked at it in enough
> > detail to comment yet.
> 
> How do people get to know this?  Grape vines and crystal balls are
> inherently unreliable.

If someone had looked and considered it good he'd have replied and
said that.  Simple ACK/NACK scheme - if neither returns consider it
lost.

> So, if the community has a problem with enough time to review patches,
> the community must get more (good) patch reviewers.  We can't go around
> blaming the patch submitters for a community failing.

Absolutely.  I think the major problem is that no one pays people for
doing reviews so this is purely a spare-time job.  And that spare time
is limited due to real life issues for most people.

-
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: thoughts on kernel security issues

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


[]

Did any of you actually READ the link I put?  How the heck did we get
the navy into this?


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9+5+hDd4aOud5P8RAnrJAKCAGRMebZP3EX1pvqxhWInQVQgGVQCfbu2f
XxZez57GG7z66bhlQTOX0M0=
=fcXP
-END PGP SIGNATURE-
-
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: thoughts on kernel security issues

[Linus Torvalds]

On Wed, 26 Jan 2005, Olaf Hering wrote:
> 
> And, did that nice interface help at all? No, it did not.
> Noone made seqfile mandatory in 2.6.

Sure it helped. We didn't make it mandatory, but new stuff ends up being 
written with it, and old stuff _does_ end up being converted to it.

> Now we have a few nice big patches to carry around because every driver
> author had its own proc implementation. Well done...

Details, please?

Linus
-
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][I2C] Marvell mv64xxx i2c driver

[Jean Delvare]

Hi Mark,

> Marvell makes a line of host bridge for PPC and MIPS systems.  On
> those  bridges is an i2c controller.  This patch adds the driver for
> that i2c  controller.
> 
> Please let me know if you see any problems with this patch.

I do not feel qualified for a full review of this code. However, I
noticed the following minor issues:

> +config I2C_MV64XXX
> + tristate "Marvell mv64xxx I2C Controller"
> + depends on I2C && MV64X60

&& EXPERIMENTAL?

> diff -Nru a/include/linux/i2c-id.h b/include/linux/i2c-id.h
> --- a/include/linux/i2c-id.h  2005-01-25 18:15:24 -07:00
> +++ b/include/linux/i2c-id.h  2005-01-25 18:15:24 -07:00
> @@ -200,6 +200,7 @@
>  
>  #define I2C_ALGO_SIBYTE 0x15 /* Broadcom SiByte SOCs */
>  #define I2C_ALGO_SGI 0x16/* SGI algorithm*/
> +#define I2C_ALGO_MV64XXX 0x17   /* Marvell mv64xxx i2c ctlr */

0x17 is reserved within the legacy i2c project for an USB algorithm,
and 0x18 for virtual busses. Could you please use 0x19 instead,
so as to avoid future collisions?

> -#define MV64340_I2C_SLAVE_ADDR  0xc000
> -#define MV64340_I2C_EXTENDED_SLAVE_ADDR 0xc010
> -#define MV64340_I2C_DATA0xc004
> -#define MV64340_I2C_CONTROL 0xc008
> -#define MV64340_I2C_STATUS_BAUDE_RATE   0xc00C
> -#define MV64340_I2C_SOFT_RESET  0xc01c
> +#define  MV64XXX_I2C_CTLR_NAME   
> "mv64xxx i2c"
> +#define MV64XXX_I2C_OFFSET   0xc000
> +#define MV64XXX_I2C_REG_BLOCK_SIZE   0x0020

You have a tab instead of space before MV64XXX_I2C_CTLR_NAME, it seems.
Also, you want to align the numerical values using only tabs, no space.

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.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: thoughts on kernel security issues

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Sytse Wielinga wrote:
> On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> 
>>That being said, you should also consider (unless somebody forgot to
>>tell me something) that it takes two source trees to make a split-out
>>patch.  The author also has to chew down everything but the feature he
>>wants to split out.  I could probably log 10,000 man-hours splitting up
>>GrSecurity.  :)
> 
> 
> I'd try out Andrew's patch scripts if I were you. If you're making a patch to
> the kernel, you'd best keep it in separate patches from the beginning, and
> that's exactly what those scripts are very useful for.
> 
> 
>>>It's also a lot easier to find the (inevitable) bugs. Either you already 
>>>have a clue ("try reverting that one patch") or you can do things like 
>>>binary searching. The bugs introduced a patch often have very little to do 
>>>with the thing a patch fixes - exactly because the patch _fixes_ 
>>>something, it's been tested with that particular problem, and the new 
>>>problem it introduces is usually orthogonal.
>>
>>true. Very very true.
>>
>>With things like Gr, there's like a million features.  Normally the
>>first step I take is "Disable it all".  If it still breaks, THEN THERE'S
>>A PROBLEM.  If it works, then the binary searching begins.
> 
> 
> So how do you think you would do a binary search within big patches, if it
> would take you 10,000 man-hours to split up the patch? Disabling a lot of
> small patches is easy, disabling a part of a big one takes a lot more work.
> 

'make menuconfig' is not a lot more work wtf


[*] Grsecurity
  Security Level (Custom)  --->
  Address Space Protection  --->
  Role Based Access Control Options  --->
  Filesystem Protections  --->
  Kernel Auditing  --->
  Executable Protections  --->
  Network Protections  --->
  Sysctl support  --->
  Logging Options  --->

?? Address Space Protection ??
 [ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port
 [ ] Disable privileged I/O
 [*] Remove addresses from /proc//[maps|stat]
 [*] Deter exploit bruteforcing
 [*] Hide kernel symbols

Need I continue?  There's some 30 or 40 more options I could show.  If
you can't use your enter, left, right, up, y, n, and ? keys, you're
crippled and won't be able to patch and unpatch crap either.

> 
>>>Which is why lots of small patches usually have _different_ bug behaviour
>>>than the patch they fix. To go back to the A+B fix: the bug they fix may
>>>be fixed only by the _combination_ of the patch, but the bug they cause is
>>>often an artifact of _one_ of the patches.
>>>
>>
>>Wasn't talking about bugfixes, see above.
> 
> 
> Oh, so you're saying that security fixes don't cause bugs? Great world you 
> live
> in, then...
> 

I didn't say that.  I said I wasn't talking about bugfix patches.  I
wasn't talking about "mremap(0,0) gives you root," I was talking about
"preventing following links under X conditions breaks nothing legitimate
but deadstops /tmp races" or "properly setting CPU protections for
PROT_EXEC stops code injection" or "ASLR stops ret2libc attacks."

If you people ever bothered to read what I say, you wouldn't continually
say stupid shit like  You get milk from cows  wtf idiot
chocolate milk doens't come from chocolate cows

> 
>>>IOW, splitting the patches up makes them
>>> - easier to merge
>>> - easier to verify
>>> - easier to debug
>>>
>>>and combining them has _zero_ advantages (whatever bug the combined patch
>>>fix _will_ be fixed by the series of individual patches too - even if the
>>>splitting was buggy in some respect, you are pretty much guaranteed of
>>>this, since the bug you were trying to fix is the _one_ thing you are
>>>really testing for). 
>>
>>Lots of work to split up a patch though.
> 
> 
> See above.
> 
> Sytse
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9+/zhDd4aOud5P8RAsZzAJ4rUryqsKc1OcfT4Nwc1m/lJtePPwCfXMWx
fEoc1nSxOfEzjJNZRDx6qYQ=
=NYJe
-END PGP SIGNATURE-
-
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-rc2-mm1: SuperIO scx200 breakage

[Evgeniy Polyakov]

On Wed, 26 Jan 2005 20:20:27 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:

> [Voluntarily skipping a large part of the discussion so as to stop
> wasting everyone's time and focus on the one technical point I am
> interested in.]
> 
> Hi Evgeniy,
> 
> > As I saw from different documentation - logical devices itself are the
> > same.
> > 
> > And it is the same for superio standard.
> > 
> > For example sc1100 and pc87366 superio chips have the same logical
> > inside, although different logical device set.
> > 
> > (...)
> > 
> > Not only access.
> > Logic inside superio chip is submitted to superio standard.
> > I designed(at least tried to) superio subsistem
> > that it can handle all differencies using per device callbacks.
> 
> I would like to ensure that we agree on what is common to all Super-I/O
> chips (as per Intel's LPC specification).
> 
> 1* Super-I/O are accessed at I/O addresses 0x2e+0x2f or alternate
> addresses 0x4e+0x4f.
> 
> 2* These addresses give access to a 256 byte addressing space.
> 
> 3* Super-I/O chips are divided in logical devices, which can be selected
> by writing its id to 0x07. What each logical device does is not
> standardized (depends of the chip).
> 
> 4* Range 0x00-0x2f is common to all logical devices, while range
> 0x30-0xff is logical-device specific.
> 
> 5* Range 0x20-0x2f contains chip-wide identification and configuration
> registers. Definition of these registers is not standardized.
> 
> 6* 0x31 controls the activation of each logical device, 0x60-0x63 its
> base address, 0x70-0x73 its interrupts. Definition of these registers is
> standardized.
> 
> 7* Range 0xf0-0xff contains logical device-specific configuration
> registers. Definition of these registers is not standardized.
> 
> And that's about it. The way each logical device works (how registers
> are mapped from the base address) is completely chip-specific.
> 
> Do we agree on all this, or did I miss somthing? I would like to make
> sure that, when you refer to sharing as much code as possible between
> the various Super-I/O chips, you really mean the organization of logical
> devices within the Super-I/O (selection, retrieval of base address and
> interrupt configuration) and not the logical devices themselves.

You are absolutely right, I just want to add following note:

Most of the logical devices inside superio chips has standardized access 
methods.
One just need base address and index, that is all.
For such devices all infrastructure already exists in the provided superio core.
One just need to provide one logical device driver for it(like sc_gpio.c).

But, sometimes it really can be the situation, when logical device is not
obeyed to rules in the existing logical device driver(like GPIO in sc1100, 
which is
not superio logical device but is fitted design quite well), for such
cases there is also infrastructure in superio driver. For example scx.c -
it has it's own private GPIO logical device, which is "cloned" from the
"standard"(described in sc_gpio.c) logical device(clones actully have 
almost nothing in common).

Situation with device cloning is very unlikely according to various superio
chips I saw and read datasheets.
 
> Thanks,
> -- 
> Jean Delvare
> http://khali.linux-fr.org/


Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt
-
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: thoughts on kernel security issues

[Olaf Hering]

 On Wed, Jan 26, Linus Torvalds wrote:

> 
> 
> On Wed, 26 Jan 2005, Olaf Hering wrote:
> > 
> > And, did that nice interface help at all? No, it did not.
> > Noone made seqfile mandatory in 2.6.
> 
> Sure it helped. We didn't make it mandatory, but new stuff ends up being 
> written with it, and old stuff _does_ end up being converted to it.

2.5 was the right time to enforce it.

> > Now we have a few nice big patches to carry around because every driver
> > author had its own proc implementation. Well done...
> 
> Details, please?

You did it this way:
http://linux.bkbits.net:8080/linux-2.5/[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: /proc parent _root == NULL?

[Randy.Dunlap]

John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
proc_misc_init() has both these lines in it:
entry = create_proc_entry("kmsg", S_IRUSR, _root);
proc_root_kcore = create_proc_entry("kcore", S_IRUSR, NULL);
Both entries show up in /proc, as /proc/kmsg and /proc/kcore.  So I ask,
as I can't see after several minutes of examination, what's the
difference?  Why is NULL used for some and _root used for others?
I'm looking at 2.6.10
create_proc_entry() passes  to proc_create().
See proc_create():
...
This is an error path:
	if (!(*parent) && xlate_proc_name(name, parent, ) != 0)
		goto out;
but xlate_proc_name() searches for a /proc/ and returns the 
all-but-final-part-of-name *parent (hope that makes some sense,
see the comments above the function), so it returns _root.

HTH.  If not, fire back.
--
~Randy
-
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: thoughts on kernel security issues

[Sytse Wielinga]

On Wed, Jan 26, 2005 at 02:31:00PM -0500, John Richard Moser wrote:
> Sytse Wielinga wrote:
> > On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> >[...]
> >>true. Very very true.
> >>
> >>With things like Gr, there's like a million features.  Normally the
> >>first step I take is "Disable it all".  If it still breaks, THEN THERE'S
> >>A PROBLEM.  If it works, then the binary searching begins.
> > 
> > 
> > So how do you think you would do a binary search within big patches, if it
> > would take you 10,000 man-hours to split up the patch? Disabling a lot of
> > small patches is easy, disabling a part of a big one takes a lot more work.
> 
> 'make menuconfig' is not a lot more work wtf
> 
> 
> [*] Grsecurity
>   Security Level (Custom)  --->
>   Address Space Protection  --->
>   Role Based Access Control Options  --->
>   Filesystem Protections  --->
>   Kernel Auditing  --->
>   Executable Protections  --->
>   Network Protections  --->
>   Sysctl support  --->
>   Logging Options  --->
> 
> ?? Address Space Protection ??
>  [ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port
>  [ ] Disable privileged I/O
>  [*] Remove addresses from /proc//[maps|stat]
>  [*] Deter exploit bruteforcing
>  [*] Hide kernel symbols
> 
> Need I continue?  There's some 30 or 40 more options I could show.  If
> you can't use your enter, left, right, up, y, n, and ? keys, you're
> crippled and won't be able to patch and unpatch crap either.

Granted, in some patches you can disable certain features by turning off config
options. Even though it's much less convenient and you might miss out on some
parts because bugs may be introduced that aren't disabled by any option and
even if you find the option that triggers the bug, you still may have lots of
code to check because the option enables a large piece of code, and will have
to work with the entire patch instead of just a small one, in the case of a
well-written patch it's mostly very inconvenient. It still is a good habit to
split out the work you do into small parts though. 

> >>>Which is why lots of small patches usually have _different_ bug behaviour
> >>>than the patch they fix. To go back to the A+B fix: the bug they fix may
> >>>be fixed only by the _combination_ of the patch, but the bug they cause is
> >>>often an artifact of _one_ of the patches.
> >>>
> >>
> >>Wasn't talking about bugfixes, see above.
> > 
> > 
> > Oh, so you're saying that security fixes don't cause bugs? Great world you 
> > live
> > in, then...
> > 
> 
> I didn't say that.  I said I wasn't talking about bugfix patches.  I
> wasn't talking about "mremap(0,0) gives you root," I was talking about
> "preventing following links under X conditions breaks nothing legitimate
> but deadstops /tmp races" or "properly setting CPU protections for
> PROT_EXEC stops code injection" or "ASLR stops ret2libc attacks."
> 
> If you people ever bothered to read what I say, you wouldn't continually
> say stupid shit like  You get milk from cows  wtf idiot
> chocolate milk doens't come from chocolate cows

I'm sorry about the rant. Besides, your comment ('Wasn't talking about
bugfixes') makes some sense, too. You were actually talking about two patches
though, which close two closely related holes. Linus was talking about the
possible bugs caused by either one of these two patches, which may be totally
unrelated to the thing they try to fix.

Sytse
-
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: don't let mmap allocate down to zero

[Arjan van de Ven]

On Wed, 2005-01-26 at 11:38 -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
> 
> > With some programs the 2.6 kernel can end up allocating memory
> > at address zero, for a non-MAP_FIXED mmap call!  This causes
> > problems with some programs and is generally rude to do. This
> > simple patch fixes the problem in my tests.
> 
> Does this mean that we can't mmap the screen regen buffer at
> 0x000b8000 anymore?

you're confusing virtual and physical addresses



-
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: inotify-0.18-rml-4: Oops

[pHilipp Zabel]

Hi!

Here 2.6.11-rc2 did this, too. (inotify.patch from 2.6.11-rc2-mm1):

On Fri, 21 Jan 2005 00:12:51 +0100, Juerg Billeter <[EMAIL PROTECTED]> wrote:
> I reproducibly get the following Oops as soon as I start using inotify
> with gamin and/or beagle. This happens with linux 2.6.10-as1 + inotify
> 0.18-rml-4 on multiple x86 machines.

Unable to handle kernel NULL pointer dereference at virtual address 0008
printing eip:
c020342f
*pde = 
Oops:  [#1]
PREEMPT
Modules linked in: af_packet radeon drm ipv6 rfcomm hidp l2cap pcmcia
binfmt_misc thermal processor button battery ac ohci1394 ieee1394
yenta_socket rsrc_nonstatic pcmcia_core 3c59x mii snd_intel8x0
snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd
soundcore snd_page_alloc hci_usb bluetooth uhci_hcd usbcore intel_agp
agpgart evdev ide_cd cdrom unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010287   (2.6.11-rc2)
EIP is at inotify_dev_queue_event+0x6f/0x180
eax:    ebx: 0800   ecx:    edx: e97364a8
esi: e960f308   edi: 0800   ebp: e960f300   esp: df1d5ec0
ds: 007b   es: 007b   ss: 0068
Process evolution-2.0 (pid: 4276, threadinfo=df1d4000 task=e380c020)
Stack: df1d4000  ce4f1e88  e97364a8 df1d4000 e97364a8 
  0800 c0203aba  ce4f1e88 e5a24670  e5a24670 81a4
  ce4f1e24 c015b244 ce4f1e88 df1d5f64 ce4f1e24 e5a24670 0242 c015b9e0
Call Trace:
[] inotify_inode_queue_event+0x4a/0x80
[] vfs_create+0x94/0xe0
[] open_namei+0x570/0x5c0
[] filp_open+0x2d/0x60
[] get_unused_fd+0x50/0xc0
[] getname+0x67/0xb0
[] sys_open+0x3d/0xb0
[] syscall_call+0x7/0xb
Code: 0f 87 b6 00 00 00 0f 84 c4 00 00 00 81 fb 00 20 00 00 74 38 81
fb 00 80 00 00 74 30 8b 54 24 10 89 df 8b 42 08 8b 80 0c 01 00 00 <8b>
70 08 21 f7 85 ff 0f 84 84 00 00 00 81 fb 00 80 00 00 74 0c
<6>note: evolution-2.0[4276] exited with preempt_count 1
Unable to handle kernel NULL pointer dereference at virtual address 0008
c020342f
*pde = 
Oops:  [#1]
CPU:0
EIP:0060:[]Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010287   (2.6.11-rc2)
eax:    ebx: 0800   ecx:    edx: e97364a8
esi: e960f308   edi: 0800   ebp: e960f300   esp: df1d5ec0
ds: 007b   es: 007b   ss: 0068
Stack: df1d4000  ce4f1e88  e97364a8 df1d4000 e97364a8 
  0800 c0203aba  ce4f1e88 e5a24670  e5a24670 81a4
  ce4f1e24 c015b244 ce4f1e88 df1d5f64 ce4f1e24 e5a24670 0242 c015b9e0
Call Trace:
[] inotify_inode_queue_event+0x4a/0x80
[] vfs_create+0x94/0xe0
[] open_namei+0x570/0x5c0
[] filp_open+0x2d/0x60
[] get_unused_fd+0x50/0xc0
[] getname+0x67/0xb0
[] sys_open+0x3d/0xb0
[] syscall_call+0x7/0xb
Code: 0f 87 b6 00 00 00 0f 84 c4 00 00 00 81 fb 00 20 00 00 74 38 81
fb 00 80 00 00 74 30 8b 54 24 10 89 df 8b 42 08 8b 80 0c 01 00 00 <8b>
70 08 21 f7 85 ff 0f 84 84 00 00 00 81 fb 00 80 00 00 74 0c

>>EIP; c020342f<=

>>edx; e97364a8 
>>esi; e960f308 
>>ebp; e960f300 
>>esp; df1d5ec0 

Trace; c0203aba 
Trace; c015b244 
Trace; c015b9e0 
Trace; c014c3ed 
Trace; c014c6a0 
Trace; c0159817 
Trace; c014c7cd 
Trace; c0102fb7 

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code;  c0203404 
 <_EIP>:
Code;  c0203404 
  0:   0f 87 b6 00 00 00 ja bc <_EIP+0xbc>
Code;  c020340a 
  6:   0f 84 c4 00 00 00 je d0 <_EIP+0xd0>
Code;  c0203410 
  c:   81 fb 00 20 00 00 cmp$0x2000,%ebx
Code;  c0203416 
 12:   74 38 je 4c <_EIP+0x4c>
Code;  c0203418 
 14:   81 fb 00 80 00 00 cmp$0x8000,%ebx
Code;  c020341e 
 1a:   74 30 je 4c <_EIP+0x4c>
Code;  c0203420 
 1c:   8b 54 24 10   mov0x10(%esp),%edx
Code;  c0203424 
 20:   89 df mov%ebx,%edi
Code;  c0203426 
 22:   8b 42 08  mov0x8(%edx),%eax
Code;  c0203429 
 25:   8b 80 0c 01 00 00 mov0x10c(%eax),%eax

This decode from eip onwards should be reliable

Code;  c020342f 
 <_EIP>:
Code;  c020342f<=
  0:   8b 70 08  mov0x8(%eax),%esi   <=
Code;  c0203432 
  3:   21 f7 and%esi,%edi
Code;  c0203434 
  5:   85 ff test   %edi,%edi
Code;  c0203436 
  7:   0f 84 84 00 00 00 je 91 <_EIP+0x91>
Code;  c020343c 
  d:   81 fb 00 80 00 00 cmp$0x8000,%ebx
Code;  c0203442 
 13:   74 0c je 21 <_EIP+0x21>

greetings
pHilipp
-
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: don't let mmap allocate down to zero

[Andy Isaacson]

On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
> >With some programs the 2.6 kernel can end up allocating memory
> >at address zero, for a non-MAP_FIXED mmap call!  This causes
> >problems with some programs and is generally rude to do. This
> >simple patch fixes the problem in my tests.
> 
> Does this mean that we can't mmap the screen regen buffer at
> 0x000b8000 anymore?

That would be a MAP_FIXED call, so not affected by this change.

> How do I look at the real-mode interrupt table starting at
> offset 0? You know that the return value of mmap is to be
> checked for MAP_FAILED, not for NULL, don't you?

All MAP_FIXED, too.

> What 'C' standard do you refer to? Seg-faults on null pointers
> have nothing to do with the 'C' standard and everything to
> do with the platform.

Obviously having malloc() return NULL for a successful allocation would
be a bad thing, no?  That's precisely what could happen if an anonymous
allocation got mapped at 0x0.

> >+#define SHLIB_BASE 0x00111000

Any particular thoughts as to how large a window should be reserved?
SHLIB_BASE is a bit more than 1MB, which is fairly small in the grand
scheme of things, but I guess I don't see why you'd reserve more than
PAGE_SIZE (or maybe PAGE_SIZE*2, though I can't actually articulate why
that seems like a good idea).

FWIW, mmap(2) also will return NULL if length==0.  That sure did confuse
me the first time I noticed.

-andy
-
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-rc2-mm1 strange messages

[Len Brown]

On Tue, 2005-01-25 at 13:28, Andrew Morton wrote:
> Norbert Preining <[EMAIL PROTECTED]> wrote:
> >
> > ACPI: DSDT (v001 ACER   IBIS 0x20020930 MSFT 0x010e) @
> 0x
> >  Built 1 zonelists
> >  __iounmap: bad address c00fffd9
> 
> Can you please add this?
> 
> --- 25/arch/i386/mm/ioremap.c~iounmap-debugging 2005-01-25
> 10:26:29.448809152 -0800
> +++ 25-akpm/arch/i386/mm/ioremap.c  2005-01-25 10:27:07.054092280
> -0800
> @@ -233,7 +233,8 @@ void iounmap(volatile void __iomem *addr
> return; 
> p = remove_vm_area((void *) (PAGE_MASK & (unsigned long
> __force) addr));
> if (!p) { 
> -   printk("__iounmap: bad address %p\n", addr);
> +   printk("iounmap: bad address %p\n", addr);
> +   dump_stack();
> return;
> }
>  
> _
> 

Better yet, can you please add this?

http://lkml.org/lkml/2005/1/3/136


-
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/