user/sven/linux.git/drivers/char/ipmi, branch v2.6.16.20

[PATCH] Open IPMI BT overflow

2006-04-24T16:56:04Z

I was looking into random driver code and found a suspicious looking memcpy() in drivers/char/ipmi/ipmi_bt_sm.c on 2.6.17-rc1: if ((size < 2) || (size > IPMI_MAX_MSG_LENGTH)) return -1; ... memcpy(bt->write_data + 3, data + 1, size - 1); where sizeof bt->write_data is IPMI_MAX_MSG_LENGTH. It looks like the memcpy would overflow by 2 bytes if size == IPMI_MAX_MSG_LENGTH. A patch attached to limit size to (IPMI_MAX_LENGTH - 2). Cc: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] IPMI: fix issues reported by Coverity in ipmi_msghandler.c

2006-02-03T16:32:11Z

While looking to the report by Coverity in ipmi, I came across the following issue: The IPMI message handler relies on two defines which are the same -one in include/linux/ipmi.h #define IPMI_NUM_CHANNELS 0x10 and one in drivers/char/ipmi/ipmi_msghandler. #define IPMI_MAX_CHANNELS 16 These are used interchangeably in ipmi_msghandler.c, but since the array addr->channels[] is of size IPMI_MAX_CHANNELS, I have made a patch that uses IPMI_MAX_CHANNELS for all the checks for the array index. NOTE: You could probably remove the line that defines IPMI_NUM_CHANNELS from ipmi.h, or move IPMI_MAX_CHANNELS to ipmi.h Signed-off-by: Jayachandran C. Cc: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ipmi: mem_{in,out}[bwl] => intf_mem_{in,out}[bwl]

2006-02-03T16:32:09Z

On mips: drivers/char/ipmi/ipmi_si_intf.c:1274: error: conflicting types for 'mem_inb' include/asm/io.h:436: error: previous definition of 'mem_inb' was here Don't look at line 436 unless you really know what you're doing. Move those static functions out of more or less generic namespace. Signed-off-by: Alexey "## should be banned" Dobriyan Acked-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] IPMI: remove invalid acpi register spacing check

2006-02-01T16:53:11Z

At the 2.6.12 timeframe ipmi_si_intf.c was patched to provide default register spacings in try_init_acpi() if the register spacing was set to zero, similar to code in other routines. Unfortunately, another patch was simultaneously added that exits early from try_init_acpi() if the register spacings are set to zero, circumventing the new defaults. This patch removes the early exit code and some incorrect comments that aren't present in other common code snippets. Signed-off-by: Rocky Craig Signed-off-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ipmi: use CONFIG_DMI instead of CONFIG_X86

2006-01-12T02:42:13Z

With Andi Kleen's x86_64 patch to use DMI, and my ia64 to use DMI, there is now a new CONFIG_DMI option which takes the place of CONFIG_X86 to denote the availability of the DMI functions. Make the IPMI driver use CONFIG_DMI instead. Tested on ia64 2.6.15 kernel plus the previous patch, on a Dell PowerEdge 7250 Itanium2 server, and it now autodetects the IPMI KCS driver as expected. Signed-off-by: Matt Domsch Acked-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ipmi: fix compile errors with PROC_FS=n

2006-01-10T16:01:25Z

... CC [M] drivers/char/ipmi/ipmi_msghandler.o drivers/char/ipmi/ipmi_msghandler.c:3301: `proc_ipmi_root' undeclared here (not in a function) drivers/char/ipmi/ipmi_msghandler.c:3301: initializer element is not constant drivers/char/ipmi/ipmi_msghandler.c:3301: (near initialization for `__ksymtab_proc_ipmi_root.value') drivers/char/ipmi/ipmi_msghandler.c:1535: warning: `ipmb_file_read_proc' defined but not used drivers/char/ipmi/ipmi_msghandler.c:1551: warning: `version_file_read_proc' defined but not used drivers/char/ipmi/ipmi_msghandler.c:1561: warning: `stat_file_read_proc' defined but not used ... CC [M] drivers/char/ipmi/ipmi_poweroff.o drivers/char/ipmi/ipmi_poweroff.c: In function `ipmi_poweroff_init': drivers/char/ipmi/ipmi_poweroff.c:616: warning: implicit declaration of function `unregister_sysctl_table' drivers/char/ipmi/ipmi_poweroff.c:616: `ipmi_table_header' undeclared (first use in this function) drivers/char/ipmi/ipmi_poweroff.c:616: (Each undeclared identifier is reported only once drivers/char/ipmi/ipmi_poweroff.c:616: for each function it appears in.) Signed-off-by: Adrian Bunk Cc: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] fix remaining list_for_each_safe_rcu in -mm (take 2)

2006-01-06T16:33:58Z

I missed a use of list_for_each_rcu_safe() in -mm tree. Here is an updated patch to fix it. This time tested on a machine that actually uses IPMI... (Thanks to Serge Hallyn for spotting this.) Signed-off-by: "Paul E. McKenney" Cc: Corey Minyard Cc: Matt Domsch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] IPMI oops fix

2005-12-15T22:22:45Z

While doing some testing I discovered that if the BIOS on a board does not properly setup the DMI information it leads to a panic in the IPMI code. The panic is due to dereferencing a pointer which is not initialized. The pointer is initialized in port_setup() and/or mem_setup() and used in init_one_smi() and cleanup_one_si(), however if either port_setup() or mem_setup() return ENODEV the pointer does not get initialized. Signed-off-by: Paolo Galtieri Acked-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ipmi: fix panic generator ID

2005-12-12T16:57:45Z

The IPMI specifcation says the generator ID is 0x20, but that is for bits 7-1. Bit 0 is set to specify it is a software event. The correct value is 0x41. Without this fix, panic events written into the System Event Log appear to come from an "unknown" generator, rather than from the kernel. Signed-off-by: Jordan Hargrave Signed-off-by: Matt Domsch Acked-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ipmi: missing NULL test for kthread

2005-11-18T15:49:45Z

On IPMI systems with BT interfaces, we don't start the kernel thread, so smi_info->thread is NULL. Test for NULL when stopping the thread, because kthread_stop() doesn't, and an oops ensues otherwise. Signed-off-by: Matt Domsch Acked-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds