[PATCH 5/5] Add a 00-INDEX file to Documentation/watchdog/
Add a 00-INDEX file to Documentation/watchdog/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- 00-INDEX | 10 ++ 1 file changed, 10 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/watchdog/00-INDEX 2007-08-12 00:06:01.0 +0200 @@ -0,0 +1,10 @@ +00-INDEX + - this file. +pcwd-watchdog.txt + - documentation for Berkshire Products PC Watchdog ISA cards. +src/ + - directory holding watchdog related example programs. +watchdog-api.txt + - description of the Linux Watchdog driver API. +wdt.txt + - description of the Watchdog Timer Interfaces for Linux. - 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 4/5] Add a 00-INDEX file to Documentation/telephony/
Add a 00-INDEX file to Documentation/telephony/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- 00-INDEX |4 1 file changed, 4 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/telephony/00-INDEX 2007-08-11 23:55:54.0 +0200 @@ -0,0 +1,4 @@ +00-INDEX + - this file. +ixj.txt + - document describing the Quicknet drivers. - 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 3/5] Add a 00-INDEX file to Documentation/sysctl/
Add a 00-INDEX file to Documentation/sysctl/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- 00-INDEX | 16 1 file changed, 16 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/sysctl/00-INDEX 2007-08-11 23:52:50.0 +0200 @@ -0,0 +1,16 @@ +00-INDEX + - this file. +README + - general information about /proc/sys/ sysctl files. +abi.txt + - documentation for /proc/sys/abi/*. +ctl_unnumbered.txt + - explanation of why one should not add new binary sysctl numbers. +fs.txt + - documentation for /proc/sys/fs/*. +kernel.txt + - documentation for /proc/sys/kernel/*. +sunrpc.txt + - documentation for /proc/sys/sunrpc/*. +vm.txt + - documentation for /proc/sys/vm/*. - 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/5] Add a 00-INDEX file to Documentation/mips/
Add a 00-INDEX file to Documentation/mips/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- 00-INDEX |8 1 file changed, 8 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/mips/00-INDEX 2007-08-11 22:56:26.0 +0200 @@ -0,0 +1,8 @@ +00-INDEX + - this file. +AU1xxx_IDE.README + - README for MIPS AU1XXX IDE driver. +GT64120.README + - README for dir with info on MIPS boards using GT-64120 or GT-64120A. +time.README + - README for MIPS time services. - 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 0/5] Add some missing Documentation/*/00-INDEX files
Hi, Rob Landley is trying to organize Linux kernel documentation. One thing he is doing is generating index.html files based on our 00-INDEX files in the Documentation directory. He has met with a small problem however, since not all subdirectories inside Documentation contain such a file, nor are all the files that do exist up to date, his index.html files turn up rather incomplete. In a reply to a recent post to linux-doc, where Rob also posted his script for generating the index.html files, I offered to help out with that situation and create (at least some of) the missing 00-INDEX files. These patches represent the first five files I've created. The reason I'm not submitting more files at this time is simply that I want to get some feedback before wasting too much time creating these files if it turns out that for some reason they are not wanted. This is also the reason why I'm cross posting to LKML at this time, since I suspect that not very many people currently read linux-doc. So please do the ACK/NACK/Merge dance with these patches and let me know if more are wanted or not. :-) Kind regards, Jesper Juhl <[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/
[PATCH 1/5] Add a 00-INDEX file to Documentation/auxdisplay/
Add a 00-INDEX file to Documentation/auxdisplay/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- 00-INDEX |8 1 file changed, 8 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/auxdisplay/00-INDEX 2007-08-11 23:58:49.0 +0200 @@ -0,0 +1,8 @@ +00-INDEX + - this file. +cfag12864b + - documentation for the cfag12864b LCD driver. +cfag12864b-example.c + - cfag12864b LCD userspace example program. +ks0108 + - documentation for the ks0108 LCD controller driver. - 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/
Unexpected busfree in Message-in phase
, 66MHz, medium devsel, latency 32, IRQ 11 Memory at febfe000 (32-bit, non-prefetchable) [size=4K] 00:13.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Unknown device 5237 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 3 Memory at febfd000 (32-bit, non-prefetchable) [size=4K] 00:13.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Unknown device 5237 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11 Memory at febfc000 (32-bit, non-prefetchable) [size=4K] 00:13.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: ASRock Incorporation Unknown device 5239 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19 Memory at febff800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 03:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3] (rev a3) (prog-if 00 [VGA]) Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 21 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (32-bit, prefetchable) [size=64M] Memory at d7e8 (32-bit, prefetchable) [size=512K] [virtual] Expansion ROM at fe9f [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 04:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) Subsystem: Creative Labs SBLive! 5.1 eMicro 28028 Flags: bus master, medium devsel, latency 32, IRQ 22 I/O ports at d880 [size=32] Capabilities: [dc] Power Management version 1 04:05.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a) Subsystem: Creative Labs Gameport Joystick Flags: bus master, medium devsel, latency 32 I/O ports at dc00 [size=8] Capabilities: [dc] Power Management version 1 04:06.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) Subsystem: Adaptec 29160N Ultra160 SCSI Controller Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18 BIST result: 00 I/O ports at d400 [disabled] [size=256] Memory at feaff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at 8800 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 04:07.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 42) Subsystem: D-Link System Inc DFE-530TX rev B Flags: bus master, medium devsel, latency 32, IRQ 20 I/O ports at d000 [size=256] Memory at feafec00 (32-bit, non-prefetchable) [size=256] Expansion ROM at 8802 [disabled] [size=64K] Capabilities: [40] Power Management version 2 If you need anything else (like my .config etc), just ask. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/
Unexpected busfree in Message-in phase
, 66MHz, medium devsel, latency 32, IRQ 11 Memory at febfe000 (32-bit, non-prefetchable) [size=4K] 00:13.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Unknown device 5237 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 3 Memory at febfd000 (32-bit, non-prefetchable) [size=4K] 00:13.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Unknown device 5237 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11 Memory at febfc000 (32-bit, non-prefetchable) [size=4K] 00:13.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: ASRock Incorporation Unknown device 5239 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19 Memory at febff800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 03:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3] (rev a3) (prog-if 00 [VGA]) Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 21 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (32-bit, prefetchable) [size=64M] Memory at d7e8 (32-bit, prefetchable) [size=512K] [virtual] Expansion ROM at fe9f [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 04:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) Subsystem: Creative Labs SBLive! 5.1 eMicro 28028 Flags: bus master, medium devsel, latency 32, IRQ 22 I/O ports at d880 [size=32] Capabilities: [dc] Power Management version 1 04:05.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a) Subsystem: Creative Labs Gameport Joystick Flags: bus master, medium devsel, latency 32 I/O ports at dc00 [size=8] Capabilities: [dc] Power Management version 1 04:06.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) Subsystem: Adaptec 29160N Ultra160 SCSI Controller Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18 BIST result: 00 I/O ports at d400 [disabled] [size=256] Memory at feaff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at 8800 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 04:07.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 42) Subsystem: D-Link System Inc DFE-530TX rev B Flags: bus master, medium devsel, latency 32, IRQ 20 I/O ports at d000 [size=256] Memory at feafec00 (32-bit, non-prefetchable) [size=256] Expansion ROM at 8802 [disabled] [size=64K] Capabilities: [40] Power Management version 2 If you need anything else (like my .config etc), just ask. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 0/5] Add some missing Documentation/*/00-INDEX files
Hi, Rob Landley is trying to organize Linux kernel documentation. One thing he is doing is generating index.html files based on our 00-INDEX files in the Documentation directory. He has met with a small problem however, since not all subdirectories inside Documentation contain such a file, nor are all the files that do exist up to date, his index.html files turn up rather incomplete. In a reply to a recent post to linux-doc, where Rob also posted his script for generating the index.html files, I offered to help out with that situation and create (at least some of) the missing 00-INDEX files. These patches represent the first five files I've created. The reason I'm not submitting more files at this time is simply that I want to get some feedback before wasting too much time creating these files if it turns out that for some reason they are not wanted. This is also the reason why I'm cross posting to LKML at this time, since I suspect that not very many people currently read linux-doc. So please do the ACK/NACK/Merge dance with these patches and let me know if more are wanted or not. :-) Kind regards, Jesper Juhl [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/
[PATCH 1/5] Add a 00-INDEX file to Documentation/auxdisplay/
Add a 00-INDEX file to Documentation/auxdisplay/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- 00-INDEX |8 1 file changed, 8 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/auxdisplay/00-INDEX 2007-08-11 23:58:49.0 +0200 @@ -0,0 +1,8 @@ +00-INDEX + - this file. +cfag12864b + - documentation for the cfag12864b LCD driver. +cfag12864b-example.c + - cfag12864b LCD userspace example program. +ks0108 + - documentation for the ks0108 LCD controller driver. - 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/5] Add a 00-INDEX file to Documentation/mips/
Add a 00-INDEX file to Documentation/mips/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- 00-INDEX |8 1 file changed, 8 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/mips/00-INDEX 2007-08-11 22:56:26.0 +0200 @@ -0,0 +1,8 @@ +00-INDEX + - this file. +AU1xxx_IDE.README + - README for MIPS AU1XXX IDE driver. +GT64120.README + - README for dir with info on MIPS boards using GT-64120 or GT-64120A. +time.README + - README for MIPS time services. - 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 3/5] Add a 00-INDEX file to Documentation/sysctl/
Add a 00-INDEX file to Documentation/sysctl/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- 00-INDEX | 16 1 file changed, 16 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/sysctl/00-INDEX 2007-08-11 23:52:50.0 +0200 @@ -0,0 +1,16 @@ +00-INDEX + - this file. +README + - general information about /proc/sys/ sysctl files. +abi.txt + - documentation for /proc/sys/abi/*. +ctl_unnumbered.txt + - explanation of why one should not add new binary sysctl numbers. +fs.txt + - documentation for /proc/sys/fs/*. +kernel.txt + - documentation for /proc/sys/kernel/*. +sunrpc.txt + - documentation for /proc/sys/sunrpc/*. +vm.txt + - documentation for /proc/sys/vm/*. - 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 4/5] Add a 00-INDEX file to Documentation/telephony/
Add a 00-INDEX file to Documentation/telephony/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- 00-INDEX |4 1 file changed, 4 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/telephony/00-INDEX 2007-08-11 23:55:54.0 +0200 @@ -0,0 +1,4 @@ +00-INDEX + - this file. +ixj.txt + - document describing the Quicknet drivers. - 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 5/5] Add a 00-INDEX file to Documentation/watchdog/
Add a 00-INDEX file to Documentation/watchdog/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- 00-INDEX | 10 ++ 1 file changed, 10 insertions(+) --- /dev/null 2005-11-21 04:22:37.0 +0100 +++ linux-2.6/Documentation/watchdog/00-INDEX 2007-08-12 00:06:01.0 +0200 @@ -0,0 +1,10 @@ +00-INDEX + - this file. +pcwd-watchdog.txt + - documentation for Berkshire Products PC Watchdog ISA cards. +src/ + - directory holding watchdog related example programs. +watchdog-api.txt + - description of the Linux Watchdog driver API. +wdt.txt + - description of the Watchdog Timer Interfaces for Linux. - 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/
Build failure in advansys driver - error: implicit declaration of function 'to_pci_dev'
Trying to build current Linus git tree (head at ac07860264bd2b18834d3fa3be47032115524cea) using the attached config file (generated by 'make randconfig') the build fails for me with : ... CC drivers/scsi/advansys.o drivers/scsi/advansys.c:794:2: warning: #warning this driver is still not properly converted to the DMA API drivers/scsi/advansys.c: In function 'advansys_board_found': drivers/scsi/advansys.c:17781: error: implicit declaration of function 'to_pci_dev' drivers/scsi/advansys.c:17781: warning: pointer/integer type mismatch in conditional expression drivers/scsi/advansys.c:17788: warning: unused variable 'pci_memory_address' drivers/scsi/advansys.c:17781: warning: unused variable 'pdev' make[2]: *** [drivers/scsi/advansys.o] Error 1 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 This is on a Slackware Linux 12.0 system with the following environment : $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux dragon 2.6.22-g1db6178c #1 SMP PREEMPT Sat Jul 14 04:10:50 CEST 2007 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils Binutils util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 jfsutils 1.1.11 reiserfsprogs 3.6.19 xfsprogs 2.8.16 pcmciautils014 quota-tools3.13. PPP2.4.4 Linux C Library2.5 Dynamic linker (ldd) 2.5 Linux C++ Library 6.0.8 Procps 3.2.7 Net-tools 1.60 Kbd1.12 oprofile 0.9.2 Sh-utils 6.9 udev 111 Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss lp snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec nvidia ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem agpgart sg snd_hwdep evdev ehci_hcd via_rhine k8temp I've also attached a complete build log. If you need any further details, just ask. Kind regards, Jesper Juhl config.24.gz Description: GNU Zip compressed data build.log.24.gz Description: GNU Zip compressed data
mtd: build failure - error: implicit declaration of function 'cfi_interleave'
Trying to build current Linus git tree (head at ac07860264bd2b18834d3fa3be47032115524cea) using the attached config file (generated by 'make randconfig') the build fails for me with : ... CC drivers/mtd/rfd_ftl.o CC drivers/mtd/chips/chipreg.o CC drivers/mtd/chips/cfi_probe.o In file included from drivers/mtd/chips/cfi_probe.c:19: include/linux/mtd/cfi.h: In function 'cfi_build_cmd': include/linux/mtd/cfi.h:293: error: implicit declaration of function 'cfi_interleave' make[3]: *** [drivers/mtd/chips/cfi_probe.o] Error 1 make[2]: *** [drivers/mtd/chips] Error 2 make[1]: *** [drivers/mtd] Error 2 make: *** [drivers] Error 2 This is on a Slackware Linux 12.0 system with the following environment : $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux dragon 2.6.22-g1db6178c #1 SMP PREEMPT Sat Jul 14 04:10:50 CEST 2007 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils Binutils util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 jfsutils 1.1.11 reiserfsprogs 3.6.19 xfsprogs 2.8.16 pcmciautils014 quota-tools3.13. PPP2.4.4 Linux C Library2.5 Dynamic linker (ldd) 2.5 Linux C++ Library 6.0.8 Procps 3.2.7 Net-tools 1.60 Kbd1.12 oprofile 0.9.2 Sh-utils 6.9 udev 111 Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss lp snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec nvidia ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem agpgart sg snd_hwdep evdev ehci_hcd via_rhine k8temp I've also attached a complete build log. If you need any further details, just ask. Kind regards, Jesper Juhl build.log.55.gz Description: GNU Zip compressed data config.55.gz Description: GNU Zip compressed data
mtd: build failure in drivers/mtd/chips/chipreg.c / include/linux/mtd/map.h
Trying to build current Linus git tree (head at ac07860264bd2b18834d3fa3be47032115524cea) using the attached config file (generated by 'make randconfig') the build fails for me with : ... CC drivers/mtd/chips/chipreg.o In file included from drivers/mtd/chips/chipreg.c:13: include/linux/mtd/map.h:128:2: error: #error No bus width supported. What's the point? In file included from drivers/mtd/chips/chipreg.c:13: include/linux/mtd/map.h:162: error: 'MAX_MAP_BANKWIDTH' undeclared here (not in a function) include/linux/mtd/map.h: In function 'map_word_equal': include/linux/mtd/map.h:249: error: implicit declaration of function 'map_words' include/linux/mtd/map.h: In function 'map_word_load': include/linux/mtd/map.h:316: error: implicit declaration of function 'map_bankwidth_is_large' include/linux/mtd/map.h: In function 'map_word_ff': include/linux/mtd/map.h:355: error: implicit declaration of function 'map_bankwidth' make[3]: *** [drivers/mtd/chips/chipreg.o] Error 1 make[2]: *** [drivers/mtd/chips] Error 2 make[1]: *** [drivers/mtd] Error 2 make: *** [drivers] Error 2 This is on a Slackware Linux 12.0 system with the following environment : $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux dragon 2.6.22-g1db6178c #1 SMP PREEMPT Sat Jul 14 04:10:50 CEST 2007 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils Binutils util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 jfsutils 1.1.11 reiserfsprogs 3.6.19 xfsprogs 2.8.16 pcmciautils014 quota-tools3.13. PPP2.4.4 Linux C Library2.5 Dynamic linker (ldd) 2.5 Linux C++ Library 6.0.8 Procps 3.2.7 Net-tools 1.60 Kbd1.12 oprofile 0.9.2 Sh-utils 6.9 udev 111 Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss lp snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec nvidia ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem agpgart sg snd_hwdep evdev ehci_hcd via_rhine k8temp I've also attached a complete build log. If you need any further details, just ask. Kind regards, Jesper Juhl config.70.gz Description: GNU Zip compressed data build.log.70.gz Description: GNU Zip compressed data
cciss: warning: right shift count = width of type
Hi,
I've been building some randconfig kernels lately and I've noticed
this in a few builds :
drivers/block/cciss.c:2614: warning: right shift count = width of type
drivers/block/cciss.c:2615: warning: right shift count = width of type
drivers/block/cciss.c:2616: warning: right shift count = width of type
The code in question is this :
static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c-Request.CDB[2]= (start_blk 56) 0xff;//MSB
c-Request.CDB[3]= (start_blk 48) 0xff;
c-Request.CDB[4]= (start_blk 40) 0xff;
...
}
The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...
So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those
56, 48 40 bit shifts, since they are indeed wider than the type
in the !CONFIG_LBD on a 32bit arch case.
I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.
By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea
Kind regards,
Jesper Juhl
-
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: cciss: warning: right shift count = width of type
(whoops, forgot to add maintainer to Cc - now added)
On 12/08/07, Jesper Juhl [EMAIL PROTECTED] wrote:
Hi,
I've been building some randconfig kernels lately and I've noticed
this in a few builds :
drivers/block/cciss.c:2614: warning: right shift count = width of type
drivers/block/cciss.c:2615: warning: right shift count = width of type
drivers/block/cciss.c:2616: warning: right shift count = width of type
The code in question is this :
static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c-Request.CDB[2]= (start_blk 56) 0xff;//MSB
c-Request.CDB[3]= (start_blk 48) 0xff;
c-Request.CDB[4]= (start_blk 40) 0xff;
...
}
The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...
So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those
56, 48 40 bit shifts, since they are indeed wider than the type
in the !CONFIG_LBD on a 32bit arch case.
I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.
By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea
Kind regards,
Jesper Juhl
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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/
Are we properly prepared to handle 3 Socket setups?
Hi, This may be a little off topic, but I think it's interresting enough to warrent a single mail. I just saw a news article (http://www.theinquirer.net/?article=41610) about a 3 Socket Opteron motherboard and couldn't help but wonder if we are prepared to deal with such a beast, so I thought I'd inform everyone :-) I'm guessing equipping such a board with 3 single core CPU's could show up some interresting corner cases in schedular code and elsewhere, I'll bet we have some assumptions somewhere about nr_of_cpus being an even number... In any case it would be an interresting box to test on, so for those of you employed by big business with the cash to purchase a test box, it would at least be an interresting one to add to the mix :) Anyway, just wanted to give everyone a heads-up, bye bye... -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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: Are we properly prepared to handle 3 Socket setups?
On 12/08/07, Rene Herman [EMAIL PROTECTED] wrote: On 08/12/2007 03:08 AM, Jesper Juhl wrote: This may be a little off topic, but I think it's interresting enough to warrent a single mail. I just saw a news article (http://www.theinquirer.net/?article=41610) about a 3 Socket Opteron motherboard and couldn't help but wonder if we are prepared to deal with such a beast, so I thought I'd inform everyone :-) I'm guessing equipping such a board with 3 single core CPU's could show up some interresting corner cases in schedular code and elsewhere, I'll bet we have some assumptions somewhere about nr_of_cpus being an even number... I would hope the N=1 case will have flushed out enough of those... :-| Hehe, true, but I was thinking more of nr_of_cpus is an odd number 1. :-) Just thinking of having to divide things by 3 makes me worry ;-) ... -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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: Kernel oops report
(this one looks like it should go to netdev as well - added to Cc) On 10/08/07, Sinisa Segvic <[EMAIL PROTECTED]> wrote: > Hi, > > I've just got a kernel oops. > > http://lxr.linux.no/source/Documentation/oops-tracing.txt > seems to suggest that oops reports are welcome at this address. > > Cheers, > > Sinisa > > $ uname -a > Linux PCs129.EMT.tugraz.at 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC > 2007 i686 GNU/Linux > > > > [326735.692443] BUG: unable to handle kernel NULL pointer dereference > at virtual address 001b > [326735.692454] printing eip: > [326735.692457] c015f581 > [326735.692458] *pde = > [326735.692463] Oops: [#1] > [326735.692466] Modules linked in: nls_cp437 isofs udf binfmt_misc > rfcomm l2cap bluetooth nfs lockd sunrpc xt_limit xt_tcpudp > iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT > nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state > nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppdev radeon > drm cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand > freq_table cpufreq_conservative tc1100_wmi pcc_acpi dev_acpi sony_acpi > video sbs i2c_ec dock button battery container ac asus_acpi backlight > ipv6 fuse lp snd_cmipci gameport snd_pcm_oss snd_mixer_oss snd_pcm > snd_page_alloc snd_opl3_lib snd_hwdep snd_mpu401_uart snd_seq_dummy > snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event i2c_viapro > parport_pc parport pcspkr psmouse i2c_core snd_seq snd_timer > snd_seq_device rtc via_ircc snd irda soundcore crc_ccitt serio_raw > via_agp agpgart shpchp pci_hotplug af_packet evdev tsdev ext3 jbd > mbcache ide_cd cdrom ide_disk ata_generic libata scsi_mod via82cxxx > 8139too floppy 8139cp mii generic ohci1394 ieee1394 ehci_hcd uhci_hcd > usbcore raid10 raid456 xor raid1 raid0 multipath linear md_mod thermal > processor fan dm_mod fbcon tileblit font bitblit softcursor vesafb > capability commoncap > [326735.692550] CPU:0 > [326735.692552] EIP:0060:[]Not tainted VLI > [326735.692553] EFLAGS: 00210082 (2.6.20-16-386 #2) > [326735.692565] EIP is at kfree+0x41/0x80 > [326735.692568] eax: 4080 ebx: 001b ecx: dfffb3c4 edx: c11ce340 > [326735.692572] esi: ce71ac00 edi: 00200286 ebp: cb2d64a0 esp: d0e4bdd8 > [326735.692575] ds: 007b es: 007b ss: 0068 > [326735.692579] Process firefox-bin (pid: 6763, ti=d0e4a000 > task=cf56c590 task.ti=d0e4a000) > [326735.692582] Stack: cb2d64a0 d0e4bedc d0e4bea0 c02701f8 0020 > c02d0c4d c026d39d > [326735.692589]d032bc80 d032bdc0 cb2d64d0 d032bcd4 d0e4bea0 > cf12d8c0 0020 0001 > [326735.692596]0001 ffa1 d0e4be80 1302 > > [326735.692601] Call Trace: > [326735.692608] [] kfree_skbmem+0x8/0x80 > [326735.692619] [] unix_stream_recvmsg+0x1ad/0x540 > [326735.692627] [] sock_alloc_send_skb+0x16d/0x1c0 > [326735.692659] [] current_fs_time+0x46/0x50 > [326735.692670] [] sock_aio_read+0x11f/0x130 > [326735.692679] [] pipe_write+0x22b/0x470 > [326735.692706] [] do_sync_read+0xd5/0x120 > [326735.692729] [] autoremove_wake_function+0x0/0x50 > [326735.692746] [] hrtimer_run_queues+0xf2/0x120 > [326735.692754] [] unix_ioctl+0x89/0xc0 > [326735.692771] [] vfs_read+0x17c/0x190 > [326735.692782] [] sys_read+0x41/0x70 > [326735.692793] [] sysenter_past_esp+0x69/0xa9 > [326735.692817] === > [326735.692819] Code: 05 00 00 00 00 8d 96 00 00 00 40 89 c7 c1 ea 0c > c1 e2 05 03 15 80 ba 44 c0 8b 02 f6 c4 40 75 2b 8b 02 84 c0 79 37 8b > 4a 18 8b 19 <8b> 03 3b 43 04 73 1e 89 74 83 10 83 c0 01 89 03 89 f8 50 > 9d 8d > [326735.692843] EIP: [] kfree+0x41/0x80 SS:ESP 0068:d0e4bdd8 > [326735.692849] - 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: Kernel oops report
(this one looks like it should go to netdev as well - added to Cc) On 10/08/07, Sinisa Segvic [EMAIL PROTECTED] wrote: Hi, I've just got a kernel oops. http://lxr.linux.no/source/Documentation/oops-tracing.txt seems to suggest that oops reports are welcome at this address. Cheers, Sinisa $ uname -a Linux PCs129.EMT.tugraz.at 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux [326735.692443] BUG: unable to handle kernel NULL pointer dereference at virtual address 001b [326735.692454] printing eip: [326735.692457] c015f581 [326735.692458] *pde = [326735.692463] Oops: [#1] [326735.692466] Modules linked in: nls_cp437 isofs udf binfmt_misc rfcomm l2cap bluetooth nfs lockd sunrpc xt_limit xt_tcpudp iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppdev radeon drm cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative tc1100_wmi pcc_acpi dev_acpi sony_acpi video sbs i2c_ec dock button battery container ac asus_acpi backlight ipv6 fuse lp snd_cmipci gameport snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_opl3_lib snd_hwdep snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event i2c_viapro parport_pc parport pcspkr psmouse i2c_core snd_seq snd_timer snd_seq_device rtc via_ircc snd irda soundcore crc_ccitt serio_raw via_agp agpgart shpchp pci_hotplug af_packet evdev tsdev ext3 jbd mbcache ide_cd cdrom ide_disk ata_generic libata scsi_mod via82cxxx 8139too floppy 8139cp mii generic ohci1394 ieee1394 ehci_hcd uhci_hcd usbcore raid10 raid456 xor raid1 raid0 multipath linear md_mod thermal processor fan dm_mod fbcon tileblit font bitblit softcursor vesafb capability commoncap [326735.692550] CPU:0 [326735.692552] EIP:0060:[c015f581]Not tainted VLI [326735.692553] EFLAGS: 00210082 (2.6.20-16-386 #2) [326735.692565] EIP is at kfree+0x41/0x80 [326735.692568] eax: 4080 ebx: 001b ecx: dfffb3c4 edx: c11ce340 [326735.692572] esi: ce71ac00 edi: 00200286 ebp: cb2d64a0 esp: d0e4bdd8 [326735.692575] ds: 007b es: 007b ss: 0068 [326735.692579] Process firefox-bin (pid: 6763, ti=d0e4a000 task=cf56c590 task.ti=d0e4a000) [326735.692582] Stack: cb2d64a0 d0e4bedc d0e4bea0 c02701f8 0020 c02d0c4d c026d39d [326735.692589]d032bc80 d032bdc0 cb2d64d0 d032bcd4 d0e4bea0 cf12d8c0 0020 0001 [326735.692596]0001 ffa1 d0e4be80 1302 [326735.692601] Call Trace: [326735.692608] [c02701f8] kfree_skbmem+0x8/0x80 [326735.692619] [c02d0c4d] unix_stream_recvmsg+0x1ad/0x540 [326735.692627] [c026d39d] sock_alloc_send_skb+0x16d/0x1c0 [326735.692659] [c011fad6] current_fs_time+0x46/0x50 [326735.692670] [c026a37f] sock_aio_read+0x11f/0x130 [326735.692679] [c0168f2b] pipe_write+0x22b/0x470 [326735.692706] [c0162ce5] do_sync_read+0xd5/0x120 [326735.692729] [c012ded0] autoremove_wake_function+0x0/0x50 [326735.692746] [c0130a72] hrtimer_run_queues+0xf2/0x120 [326735.692754] [c02cfb79] unix_ioctl+0x89/0xc0 [326735.692771] [c016375c] vfs_read+0x17c/0x190 [326735.692782] [c0163b11] sys_read+0x41/0x70 [326735.692793] [c0102fc0] sysenter_past_esp+0x69/0xa9 [326735.692817] === [326735.692819] Code: 05 00 00 00 00 8d 96 00 00 00 40 89 c7 c1 ea 0c c1 e2 05 03 15 80 ba 44 c0 8b 02 f6 c4 40 75 2b 8b 02 84 c0 79 37 8b 4a 18 8b 19 8b 03 3b 43 04 73 1e 89 74 83 10 83 c0 01 89 03 89 f8 50 9d 8d [326735.692843] EIP: [c015f581] kfree+0x41/0x80 SS:ESP 0068:d0e4bdd8 [326735.692849] - 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] Fix a memory leak in em28xx_usb_probe()
EHLO,
If, in em28xx_usb_probe() the memory allocation
dev->alt_max_pkt_size = kmalloc(32*
dev->num_alt,GFP_KERNEL);
fails, then we'll bail out and return -ENOMEM.
The problem is that in that case we don't free the storage allocated
to 'dev', thus causing a memory leak.
This patch fixes the leak by freeing 'dev' before we return -ENOMEM.
This fixes Coverity bug #647.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/media/video/em28xx/em28xx-video.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-video.c
b/drivers/media/video/em28xx/em28xx-video.c
index 2c7b158..40307f3 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -1772,6 +1772,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
if (dev->alt_max_pkt_size == NULL) {
em28xx_errdev("out of memory!\n");
em28xx_devused&=~(1<http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc2-mm1
On 09/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote: ... > - If there's a patch in here which you think should be in 2.6.23 but I do > not have it designated in that way, please be sure to let me know. ... Well, if you want to clean up your patch queue a bit then I have a few suggestions for some patches of mine that are currently in -mm that you could push to Linus. They are not really important, so if you'd rather keep them around in -mm until the next merge window then that's fine by me, but they should be safe to push and would get cut down on the number of patches you track a bit :-) This fix was already merged for the ati side of things, this is an identical fix for the amd side of things - I see no reason why we shouldn't get this fix into 2.6.23 as well : fix-use-after-free--double-free-bug-in-amd_create_gatt_pages--amd_free_gatt_pages.patch This patch only changes the output of the script when run without arguments, so as far as building the kernel goes it can't cause any regressions and it's a clear improvement over what we currently have, so might as well get it out of your queue and upstream : improve-scripts-gcc-versionsh-output-a-bit-when-called-without-args.patch When people use scripts/ver_linux in bugreports we want correct info - currently we often print wrong info for the binutils version. This patch doesn't hurt existing working scenarios but does fix a few broken ones, might as well get that merged, it's a clear fix : scripts-ver_linux-correct-printing-of-binutils-version.patch These should all be trivially correct since they just remove duplicate #include's of the same header into a .c file outside any #ifdef and similar magic, so they should be quite safe to push. Also, I haven't seen anything but ACK's in response to them (when I've seen a response), and a few of my similar patches have already been merged : powerpc-clean-out-a-bunch-of-duplicate-includes.patch clean-up-duplicate-includes-in-drivers-input.patch clean-up-duplicate-includes-in-drivers-net.patch clean-up-duplicate-includes-in-drivers-atm.patch clean-up-duplicate-includes-in-net-atm.patch clean-up-duplicate-includes-in-net-ipv4.patch clean-up-duplicate-includes-in-net-ipv6.patch clean-up-duplicate-includes-in-net-sched.patch clean-up-duplicate-includes-in-net-sunrpc.patch clean-up-duplicate-includes-in-net-tipc.patch clean-up-duplicate-includes-in-net-xfrm.patch clean-up-duplicate-includes-in-include-linux-nfs_fsh.patch clean-up-duplicate-includes-in-fs-ntfs.patch clean-up-duplicate-includes-in-drivers-scsi.patch clean-up-duplicate-includes-in-drivers-block.patch clean-up-duplicate-includes-in-arch-i386-xen.patch clean-up-duplicate-includes-in-include-linux-memory_hotplugh.patch clean-up-duplicate-includes-in-mm.patch clean-up-duplicate-includes-in-drivers-char.patch clean-up-duplicate-includes-in-drivers-w1.patch clean-up-duplicate-includes-in-fs.patch clean-up-duplicate-includes-in-fs-ecryptfs.patch clean-up-duplicate-includes-in-kernel.patch clean-up-duplicate-includes-in-drivers-spi.patch clean-up-duplicate-includes-in-documentation.patch -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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: Documentation files in html format?
On 09/08/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > Since the network device documentation needs a rewrite, I was thinking > of using basic html format instead of just plain text. But since this would > be starting an new precedent for kernel documentation, some it seemed > like a worthwhile topic for discussion. > > Advantages of html: > * basic formatting like lists, italics, etc - List item 1 - List item 2 - List item 3 /italic text/ *bold text* _underlined text_ > * easier to integrate into other places and retain formatting Hmm, I'm not sure I agree, generally plain tet integrates easily into everything, html not so. As for formatting, you usually always have to tweak that by hand anyway, might as well leave it as plain text.. > * ability to link documents and to external sources easier How is http://kernel.org/;>kernel.org easier to handle than plain http://kernel.org/ ? > > Downsides: > * can become too formatted and unclear Yup. > * accessibility and translation issues? Those exist whatever format you pick. > * even more style issues Indeed. I for one vote for just keeping things as plain text, it's so much easier work with - grep, sed, awk etc... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] Emulex FC HBA driver: fix overflow of statically allocated array
Hi,
The Coverity checker noticed that we may overrun a statically allocated
array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
The case is this; In 'struct lpfc_hba' we have
#define LPFC_MAX_HBQS 4
...
struct lpfc_hba {
...
struct hbq_s hbqs[LPFC_MAX_HBQS];
...
};
But then in lpfc_sli_hbqbuf_find() we have this code
hbqno = tag >> 16;
if (hbqno > LPFC_MAX_HBQS)
return NULL;
if 'hbqno' ends up as exactely 4, then we won't return, and then this
list_for_each_entry(d_buf, >hbqs[hbqno].hbq_buffer_list, list) {
will cause an overflow of the statically allocated array at index 4,
since the valid indices are only 0-3.
I propose this patch, that simply changes the 'hbqno > LPFC_MAX_HBQS'
into 'hbqno >= LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/scsi/lpfc/lpfc_sli.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index ce5ff2b..e5337ad 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -675,7 +675,7 @@ lpfc_sli_hbqbuf_find(struct lpfc_hba *phba, uint32_t tag)
uint32_t hbqno;
hbqno = tag >> 16;
- if (hbqno > LPFC_MAX_HBQS)
+ if (hbqno >= LPFC_MAX_HBQS)
return NULL;
list_for_each_entry(d_buf, >hbqs[hbqno].hbq_buffer_list, list) {
-
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/3] UIO: Documentation
On 09/08/07, Greg KH <[EMAIL PROTECTED]> wrote: > On Thu, Aug 09, 2007 at 01:03:39AM +0200, Jesper Juhl wrote: > > > > > I think the only way to avoid it is to not provide something like UIO. > > Problem is, things like UIO provide a real solution for a wide range of > different types of devices. Like the one provided in the kernel right > now, and a bunch of others that I am currently discussing with different > manufacturers (think high-speed DSPs that just want to give userspace > direct access to the card and have the kernel get the hell out of the > way so data can be read and processed as fast as possible.) > Please understand that I'm not saying UIO isn't potentially useful, nor am I saying that it won't potentially give us support for a bunch of new hardware. All I'm trying to say is that, to me at least, it is trying to buy us those new drivers in a way that encourages creating those drivers as closed source software- *that* is all I'm having issues with - that is what I think is a step backwards - something that may give us a short-term gain but will make us lose out long-term. > And also realize that some types of systems have been doing this very > same kind of kernel/userspace interface for many years, namely X :) > That something has been going on for years doesn't in itself make it a good argument for that model. ;-) > As for the legalities of using closed source userspace code with the UIO > interface, consult a lawyer if you have questions, and be sure to bring > up Alan's comments about derivative works :) > I'm not arguing against closed source applications in userspace. That is of course OK. What I'm arguing about is a kernel interface that encourages closed source (userspace) *drivers*. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/3] UIO: Documentation
On 09/08/07, Greg KH [EMAIL PROTECTED] wrote: On Thu, Aug 09, 2007 at 01:03:39AM +0200, Jesper Juhl wrote: I think the only way to avoid it is to not provide something like UIO. Problem is, things like UIO provide a real solution for a wide range of different types of devices. Like the one provided in the kernel right now, and a bunch of others that I am currently discussing with different manufacturers (think high-speed DSPs that just want to give userspace direct access to the card and have the kernel get the hell out of the way so data can be read and processed as fast as possible.) Please understand that I'm not saying UIO isn't potentially useful, nor am I saying that it won't potentially give us support for a bunch of new hardware. All I'm trying to say is that, to me at least, it is trying to buy us those new drivers in a way that encourages creating those drivers as closed source software- *that* is all I'm having issues with - that is what I think is a step backwards - something that may give us a short-term gain but will make us lose out long-term. And also realize that some types of systems have been doing this very same kind of kernel/userspace interface for many years, namely X :) That something has been going on for years doesn't in itself make it a good argument for that model. ;-) As for the legalities of using closed source userspace code with the UIO interface, consult a lawyer if you have questions, and be sure to bring up Alan's comments about derivative works :) I'm not arguing against closed source applications in userspace. That is of course OK. What I'm arguing about is a kernel interface that encourages closed source (userspace) *drivers*. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] Emulex FC HBA driver: fix overflow of statically allocated array
Hi,
The Coverity checker noticed that we may overrun a statically allocated
array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
The case is this; In 'struct lpfc_hba' we have
#define LPFC_MAX_HBQS 4
...
struct lpfc_hba {
...
struct hbq_s hbqs[LPFC_MAX_HBQS];
...
};
But then in lpfc_sli_hbqbuf_find() we have this code
hbqno = tag 16;
if (hbqno LPFC_MAX_HBQS)
return NULL;
if 'hbqno' ends up as exactely 4, then we won't return, and then this
list_for_each_entry(d_buf, phba-hbqs[hbqno].hbq_buffer_list, list) {
will cause an overflow of the statically allocated array at index 4,
since the valid indices are only 0-3.
I propose this patch, that simply changes the 'hbqno LPFC_MAX_HBQS'
into 'hbqno = LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/lpfc/lpfc_sli.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index ce5ff2b..e5337ad 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -675,7 +675,7 @@ lpfc_sli_hbqbuf_find(struct lpfc_hba *phba, uint32_t tag)
uint32_t hbqno;
hbqno = tag 16;
- if (hbqno LPFC_MAX_HBQS)
+ if (hbqno = LPFC_MAX_HBQS)
return NULL;
list_for_each_entry(d_buf, phba-hbqs[hbqno].hbq_buffer_list, list) {
-
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: Documentation files in html format?
On 09/08/07, Stephen Hemminger [EMAIL PROTECTED] wrote: Since the network device documentation needs a rewrite, I was thinking of using basic html format instead of just plain text. But since this would be starting an new precedent for kernel documentation, some it seemed like a worthwhile topic for discussion. Advantages of html: * basic formatting like lists, italics, etc - List item 1 - List item 2 - List item 3 /italic text/ *bold text* _underlined text_ * easier to integrate into other places and retain formatting Hmm, I'm not sure I agree, generally plain tet integrates easily into everything, html not so. As for formatting, you usually always have to tweak that by hand anyway, might as well leave it as plain text.. * ability to link documents and to external sources easier How is a href=http://kernel.org/;kernel.org/a easier to handle than plain http://kernel.org/ ? Downsides: * can become too formatted and unclear Yup. * accessibility and translation issues? Those exist whatever format you pick. * even more style issues Indeed. I for one vote for just keeping things as plain text, it's so much easier work with - grep, sed, awk etc... -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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.23-rc2-mm1
On 09/08/07, Andrew Morton [EMAIL PROTECTED] wrote: ... - If there's a patch in here which you think should be in 2.6.23 but I do not have it designated in that way, please be sure to let me know. ... Well, if you want to clean up your patch queue a bit then I have a few suggestions for some patches of mine that are currently in -mm that you could push to Linus. They are not really important, so if you'd rather keep them around in -mm until the next merge window then that's fine by me, but they should be safe to push and would get cut down on the number of patches you track a bit :-) This fix was already merged for the ati side of things, this is an identical fix for the amd side of things - I see no reason why we shouldn't get this fix into 2.6.23 as well : fix-use-after-free--double-free-bug-in-amd_create_gatt_pages--amd_free_gatt_pages.patch This patch only changes the output of the script when run without arguments, so as far as building the kernel goes it can't cause any regressions and it's a clear improvement over what we currently have, so might as well get it out of your queue and upstream : improve-scripts-gcc-versionsh-output-a-bit-when-called-without-args.patch When people use scripts/ver_linux in bugreports we want correct info - currently we often print wrong info for the binutils version. This patch doesn't hurt existing working scenarios but does fix a few broken ones, might as well get that merged, it's a clear fix : scripts-ver_linux-correct-printing-of-binutils-version.patch These should all be trivially correct since they just remove duplicate #include's of the same header into a .c file outside any #ifdef and similar magic, so they should be quite safe to push. Also, I haven't seen anything but ACK's in response to them (when I've seen a response), and a few of my similar patches have already been merged : powerpc-clean-out-a-bunch-of-duplicate-includes.patch clean-up-duplicate-includes-in-drivers-input.patch clean-up-duplicate-includes-in-drivers-net.patch clean-up-duplicate-includes-in-drivers-atm.patch clean-up-duplicate-includes-in-net-atm.patch clean-up-duplicate-includes-in-net-ipv4.patch clean-up-duplicate-includes-in-net-ipv6.patch clean-up-duplicate-includes-in-net-sched.patch clean-up-duplicate-includes-in-net-sunrpc.patch clean-up-duplicate-includes-in-net-tipc.patch clean-up-duplicate-includes-in-net-xfrm.patch clean-up-duplicate-includes-in-include-linux-nfs_fsh.patch clean-up-duplicate-includes-in-fs-ntfs.patch clean-up-duplicate-includes-in-drivers-scsi.patch clean-up-duplicate-includes-in-drivers-block.patch clean-up-duplicate-includes-in-arch-i386-xen.patch clean-up-duplicate-includes-in-include-linux-memory_hotplugh.patch clean-up-duplicate-includes-in-mm.patch clean-up-duplicate-includes-in-drivers-char.patch clean-up-duplicate-includes-in-drivers-w1.patch clean-up-duplicate-includes-in-fs.patch clean-up-duplicate-includes-in-fs-ecryptfs.patch clean-up-duplicate-includes-in-kernel.patch clean-up-duplicate-includes-in-drivers-spi.patch clean-up-duplicate-includes-in-documentation.patch -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] Fix a memory leak in em28xx_usb_probe()
EHLO,
If, in em28xx_usb_probe() the memory allocation
dev-alt_max_pkt_size = kmalloc(32*
dev-num_alt,GFP_KERNEL);
fails, then we'll bail out and return -ENOMEM.
The problem is that in that case we don't free the storage allocated
to 'dev', thus causing a memory leak.
This patch fixes the leak by freeing 'dev' before we return -ENOMEM.
This fixes Coverity bug #647.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/media/video/em28xx/em28xx-video.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-video.c
b/drivers/media/video/em28xx/em28xx-video.c
index 2c7b158..40307f3 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -1772,6 +1772,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
if (dev-alt_max_pkt_size == NULL) {
em28xx_errdev(out of memory!\n);
em28xx_devused=~(1nr);
+ kfree(dev);
return -ENOMEM;
}
-
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] make atomic_t volatile on all architectures
On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote: > Jesper Juhl wrote: > > On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote: > >> From: Chris Snook <[EMAIL PROTECTED]> > >> > >> Some architectures currently do not declare the contents of an atomic_t to > >> be > >> volatile. This causes confusion since atomic_read() might not actually > >> read > >> anything if an optimizing compiler re-uses a value stored in a register, > >> which > >> can break code that loops until something external changes the value of an > >> atomic_t. Avoiding such bugs requires using barrier(), which causes > >> re-loads > >> of all registers used in the loop, thus hurting performance instead of > >> helping > >> it, particularly on architectures where it's unnecessary. Since we > >> generally > >> want to re-read the contents of an atomic variable on every access anyway, > >> let's standardize the behavior across all architectures and avoid the > >> performance and correctness problems of requiring the use of barrier() in > >> loops that expect atomic_t variables to change externally. This is > >> relevant > >> even on non-smp architectures, since drivers may use atomic operations in > >> interrupt handlers. > >> > >> Signed-off-by: Chris Snook <[EMAIL PROTECTED]> > >> > > > > Hmm, I thought we were trying to move away from volatile since it is > > very weakly defined and towards explicit barriers and locks... > > Points to --> Documentation/volatile-considered-harmful.txt > > This is a special case. I had a feeling it might be. > Usually, the use of volatile is just lazy. In > this case, it's probably necessary on at least some architectures, so we > can't remove it everywhere unless we want to rewrite atomic.h completely > in inline assembler for several architectures, and painstakingly verify > all that work. Sounds quite unpleasant and actively harmful - keeping stuff in plain readable C makes it easier to handle by most people. > I would hope it's obvious that having consistent > behavior on all architectures, or even at all compiler optimization > levels within an architecture, can be agreed to be good. Agreed, consistency is good. > Additionally, > atomic_t variables are a rare exception, in that we pretty much always > want to work with the latest value in RAM on every access. Making this > atomic will allow us to remove a bunch of barriers which do nothing but > slow things down on most architectures. > I believe you meant to say "volatile" and not "atomic" above. But yes, if volatile is sufficiently defined to ensure it does what we want in this case and using it means we can actually speed up the kernel, then it does indeed sound reasonable. Especially since it's confined to the implementation of atomic_t which most people shouldn't be looking at anyway (but simply use) and when using an atomic_t it's pretty reasonable to expect that it doesn't need any additional locking or barriers since it's supposed to be *atomic*. > I agree that the use of atomic_t in .c files is generally bad, but in > certain special cases, hiding it inside defined data types may be worth > the slight impurity, just as we sometimes tolerate lines longer than 80 > columns when "fixing" it makes things unreadable. > Can't argue with that. It seems you've thought it through. I just wanted to be sure that this approach was actually the one that makes the most sense, and you've convinced me of that :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] make atomic_t volatile on all architectures
On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote: > From: Chris Snook <[EMAIL PROTECTED]> > > Some architectures currently do not declare the contents of an atomic_t to be > volatile. This causes confusion since atomic_read() might not actually read > anything if an optimizing compiler re-uses a value stored in a register, which > can break code that loops until something external changes the value of an > atomic_t. Avoiding such bugs requires using barrier(), which causes re-loads > of all registers used in the loop, thus hurting performance instead of helping > it, particularly on architectures where it's unnecessary. Since we generally > want to re-read the contents of an atomic variable on every access anyway, > let's standardize the behavior across all architectures and avoid the > performance and correctness problems of requiring the use of barrier() in > loops that expect atomic_t variables to change externally. This is relevant > even on non-smp architectures, since drivers may use atomic operations in > interrupt handlers. > > Signed-off-by: Chris Snook <[EMAIL PROTECTED]> > Hmm, I thought we were trying to move away from volatile since it is very weakly defined and towards explicit barriers and locks... Points to --> Documentation/volatile-considered-harmful.txt -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/3] UIO: Documentation
On 09/08/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Wed, 08 Aug 2007 23:36:00 +0200, Jesper Juhl said: > > > Do we really want this? > > > > In my oppinion we run the risk here of encouraging behaviour akin to > > what NVidia is doing - release a small kernel "glue" module and then > > keep the driver proper in a binary blob (in userspace, but still a > > binary blob). > > If the company goes out of business and take their driver source with > > them then users are left with a useless, un-debugable, un-maintainable > > binary blob. > > Don't we instead want to encourage/pressure people to release specs > > and/or source code for their hardware/drivers so open, modifiable > > drivers can be written? > > > > This opens the door for people to start writing closed drivers. In the > > long run that seems to me like a bad deal for our users. > > On the other hand, given that we've always said that closed-source stuff in > userspace is OK, the only way to not let *that* horse out of the barn is to > not merge UIO at all. > Exactely. > If you have UIO in the kernel talking to stuff in userspace, you're going to > have to deal with closed-source stuff at the userspace end of the pipe. > Naturally. I just wanted to get people to think about whether or not this is something that we are willing to accept for device drivers - I guess it is since UIO is already merged - I just think it's a potential step back in terms of encouraging open source drivers for Linux, that's all. > Unless somebody can come up with some great feat of sophistry to avoid that? > I think the only way to avoid it is to not provide something like UIO. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/3] UIO: Documentation
On 19/07/2007, Greg Kroah-Hartman <[EMAIL PROTECTED]> wrote: > From: Hans J. Koch <[EMAIL PROTECTED]> > > Documentation for the UIO interface > ... > +If you use UIO for your card's driver, here's what you get: > + ... > + > + if you need to keep some parts of your driver closed source, > + you can do so without violating the GPL license on the kernel. > + > + > + ... Do we really want this? In my oppinion we run the risk here of encouraging behaviour akin to what NVidia is doing - release a small kernel "glue" module and then keep the driver proper in a binary blob (in userspace, but still a binary blob). If the company goes out of business and take their driver source with them then users are left with a useless, un-debugable, un-maintainable binary blob. Don't we instead want to encourage/pressure people to release specs and/or source code for their hardware/drivers so open, modifiable drivers can be written? This opens the door for people to start writing closed drivers. In the long run that seems to me like a bad deal for our users. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] Fix format specifier in Documentation/vm/slabinfo.c
Hi,
There's a little problem in Documentation/vm/slabinfo.c
The code is using "%d" in a printf() call to print an 'unsigned long'.
This patch corrects it to use "%lu" instead.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
Documentation/vm/slabinfo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/vm/slabinfo.c b/Documentation/vm/slabinfo.c
index d4f21ff..1af7bd5 100644
--- a/Documentation/vm/slabinfo.c
+++ b/Documentation/vm/slabinfo.c
@@ -396,7 +396,7 @@ void report(struct slabinfo *s)
if (strcmp(s->name, "*") == 0)
return;
- printf("\nSlabcache: %-20s Aliases: %2d Order : %2d Objects: %d\n",
+ printf("\nSlabcache: %-20s Aliases: %2d Order : %2d Objects: %lu\n",
s->name, s->aliases, s->order, s->objects);
if (s->hwcache_align)
printf("** Hardware cacheline aligned\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix format specifier in Documentation/vm/slabinfo.c
Hi, There's a little problem in Documentation/vm/slabinfo.c The code is using %d in a printf() call to print an 'unsigned long'. This patch corrects it to use %lu instead. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- Documentation/vm/slabinfo.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/vm/slabinfo.c b/Documentation/vm/slabinfo.c index d4f21ff..1af7bd5 100644 --- a/Documentation/vm/slabinfo.c +++ b/Documentation/vm/slabinfo.c @@ -396,7 +396,7 @@ void report(struct slabinfo *s) if (strcmp(s-name, *) == 0) return; - printf(\nSlabcache: %-20s Aliases: %2d Order : %2d Objects: %d\n, + printf(\nSlabcache: %-20s Aliases: %2d Order : %2d Objects: %lu\n, s-name, s-aliases, s-order, s-objects); if (s-hwcache_align) printf(** Hardware cacheline aligned\n); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
On 19/07/2007, Greg Kroah-Hartman [EMAIL PROTECTED] wrote: From: Hans J. Koch [EMAIL PROTECTED] Documentation for the UIO interface ... +paraIf you use UIO for your card's driver, here's what you get:/para + ... +listitem + paraif you need to keep some parts of your driver closed source, + you can do so without violating the GPL license on the kernel./para +/listitem +/itemizedlist + ... Do we really want this? In my oppinion we run the risk here of encouraging behaviour akin to what NVidia is doing - release a small kernel glue module and then keep the driver proper in a binary blob (in userspace, but still a binary blob). If the company goes out of business and take their driver source with them then users are left with a useless, un-debugable, un-maintainable binary blob. Don't we instead want to encourage/pressure people to release specs and/or source code for their hardware/drivers so open, modifiable drivers can be written? This opens the door for people to start writing closed drivers. In the long run that seems to me like a bad deal for our users. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/3] UIO: Documentation
On 09/08/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 08 Aug 2007 23:36:00 +0200, Jesper Juhl said: Do we really want this? In my oppinion we run the risk here of encouraging behaviour akin to what NVidia is doing - release a small kernel glue module and then keep the driver proper in a binary blob (in userspace, but still a binary blob). If the company goes out of business and take their driver source with them then users are left with a useless, un-debugable, un-maintainable binary blob. Don't we instead want to encourage/pressure people to release specs and/or source code for their hardware/drivers so open, modifiable drivers can be written? This opens the door for people to start writing closed drivers. In the long run that seems to me like a bad deal for our users. On the other hand, given that we've always said that closed-source stuff in userspace is OK, the only way to not let *that* horse out of the barn is to not merge UIO at all. Exactely. If you have UIO in the kernel talking to stuff in userspace, you're going to have to deal with closed-source stuff at the userspace end of the pipe. Naturally. I just wanted to get people to think about whether or not this is something that we are willing to accept for device drivers - I guess it is since UIO is already merged - I just think it's a potential step back in terms of encouraging open source drivers for Linux, that's all. Unless somebody can come up with some great feat of sophistry to avoid that? I think the only way to avoid it is to not provide something like UIO. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] make atomic_t volatile on all architectures
On 09/08/2007, Chris Snook [EMAIL PROTECTED] wrote: From: Chris Snook [EMAIL PROTECTED] Some architectures currently do not declare the contents of an atomic_t to be volatile. This causes confusion since atomic_read() might not actually read anything if an optimizing compiler re-uses a value stored in a register, which can break code that loops until something external changes the value of an atomic_t. Avoiding such bugs requires using barrier(), which causes re-loads of all registers used in the loop, thus hurting performance instead of helping it, particularly on architectures where it's unnecessary. Since we generally want to re-read the contents of an atomic variable on every access anyway, let's standardize the behavior across all architectures and avoid the performance and correctness problems of requiring the use of barrier() in loops that expect atomic_t variables to change externally. This is relevant even on non-smp architectures, since drivers may use atomic operations in interrupt handlers. Signed-off-by: Chris Snook [EMAIL PROTECTED] Hmm, I thought we were trying to move away from volatile since it is very weakly defined and towards explicit barriers and locks... Points to -- Documentation/volatile-considered-harmful.txt -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] make atomic_t volatile on all architectures
On 09/08/2007, Chris Snook [EMAIL PROTECTED] wrote: Jesper Juhl wrote: On 09/08/2007, Chris Snook [EMAIL PROTECTED] wrote: From: Chris Snook [EMAIL PROTECTED] Some architectures currently do not declare the contents of an atomic_t to be volatile. This causes confusion since atomic_read() might not actually read anything if an optimizing compiler re-uses a value stored in a register, which can break code that loops until something external changes the value of an atomic_t. Avoiding such bugs requires using barrier(), which causes re-loads of all registers used in the loop, thus hurting performance instead of helping it, particularly on architectures where it's unnecessary. Since we generally want to re-read the contents of an atomic variable on every access anyway, let's standardize the behavior across all architectures and avoid the performance and correctness problems of requiring the use of barrier() in loops that expect atomic_t variables to change externally. This is relevant even on non-smp architectures, since drivers may use atomic operations in interrupt handlers. Signed-off-by: Chris Snook [EMAIL PROTECTED] Hmm, I thought we were trying to move away from volatile since it is very weakly defined and towards explicit barriers and locks... Points to -- Documentation/volatile-considered-harmful.txt This is a special case. I had a feeling it might be. Usually, the use of volatile is just lazy. In this case, it's probably necessary on at least some architectures, so we can't remove it everywhere unless we want to rewrite atomic.h completely in inline assembler for several architectures, and painstakingly verify all that work. Sounds quite unpleasant and actively harmful - keeping stuff in plain readable C makes it easier to handle by most people. I would hope it's obvious that having consistent behavior on all architectures, or even at all compiler optimization levels within an architecture, can be agreed to be good. Agreed, consistency is good. Additionally, atomic_t variables are a rare exception, in that we pretty much always want to work with the latest value in RAM on every access. Making this atomic will allow us to remove a bunch of barriers which do nothing but slow things down on most architectures. I believe you meant to say volatile and not atomic above. But yes, if volatile is sufficiently defined to ensure it does what we want in this case and using it means we can actually speed up the kernel, then it does indeed sound reasonable. Especially since it's confined to the implementation of atomic_t which most people shouldn't be looking at anyway (but simply use) and when using an atomic_t it's pretty reasonable to expect that it doesn't need any additional locking or barriers since it's supposed to be *atomic*. I agree that the use of atomic_t in .c files is generally bad, but in certain special cases, hiding it inside defined data types may be worth the slight impurity, just as we sometimes tolerate lines longer than 80 columns when fixing it makes things unreadable. Can't argue with that. It seems you've thought it through. I just wanted to be sure that this approach was actually the one that makes the most sense, and you've convinced me of that :-) -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][RESEND] Semi-pointless NULL test in uli526x driver
On 07/08/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Jesper Juhl wrote:
> > (resending previously submitted patch from 16/7-2007 22:40)
> >
> >
> > Hi,
> >
> > In drivers/net/tulip/uli526x.c::uli526x_interrupt() there's a test
> > of the function argument 'void *dev_id' against NULL. But that
> > test is pretty pointless, since if ever 'dev_id' is NULL we'll
> > already have crashed inside "netdev_priv(dev)".
> >
> > I don't think dev_id can ever actually be NULL, so the whole block
> > inside "if (!dev) {" could probably just go away. But I guess
> > there's a good reason someone put that ULI526X_DBUG() in there - and
> > if 'dev_id' /can/ actually be NULL then it's nice to have and in
> > that case this patch actually fixes a possible crash (hence the
> > version number update).
> > So I guess that in this case we should just move the
> > "db = netdev_priv(dev)" assignment past that NULL test. That's what
> > this patch does.
> >
> > Found by the Coverity checker.
> > Compile tested.
> >
> >
> > PS. Please keep me on Cc when replying.
> >
> >
> > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
>
> Just remove the dev==NULL test...
>
Hmm, it would seem there's some disagreement about that :
On 04/08/07, Kyle McMartin <[EMAIL PROTECTED]> wrote:
...
>
> It *can* be null, in the case of another handler being registered on the
> same irq number, passing NULL for the cookie.
>
> Ack. Will apply.
>
> Regards,
> Kyle
>
I'll let you and Kyle fight it out :-)
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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][RESEND] fix a potential NULL pointer deref in XFS on failed mount.
On 06/08/07, David Chinner <[EMAIL PROTECTED]> wrote: > On Sat, Aug 04, 2007 at 08:30:21PM +0200, Jesper Juhl wrote: > > Back in 2006 (2006-10-31 to be specific, reposted on 2006-11-16), I > > submitted a patch to fix a potential NULL pointer deref in XFS on > > failed mount. > > Already checked into xfs-dev tree. Will go to next mainline merge. > > http://oss.sgi.com/archives/xfs/2007-08/msg00030.html > Ok. Thanks a lot for the feedback David. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][RESEND] fix a potential NULL pointer deref in XFS on failed mount.
On 06/08/07, David Chinner [EMAIL PROTECTED] wrote: On Sat, Aug 04, 2007 at 08:30:21PM +0200, Jesper Juhl wrote: Back in 2006 (2006-10-31 to be specific, reposted on 2006-11-16), I submitted a patch to fix a potential NULL pointer deref in XFS on failed mount. Already checked into xfs-dev tree. Will go to next mainline merge. http://oss.sgi.com/archives/xfs/2007-08/msg00030.html Ok. Thanks a lot for the feedback David. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][RESEND] Semi-pointless NULL test in uli526x driver
On 07/08/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Jesper Juhl wrote:
(resending previously submitted patch from 16/7-2007 22:40)
Hi,
In drivers/net/tulip/uli526x.c::uli526x_interrupt() there's a test
of the function argument 'void *dev_id' against NULL. But that
test is pretty pointless, since if ever 'dev_id' is NULL we'll
already have crashed inside netdev_priv(dev).
I don't think dev_id can ever actually be NULL, so the whole block
inside if (!dev) { could probably just go away. But I guess
there's a good reason someone put that ULI526X_DBUG() in there - and
if 'dev_id' /can/ actually be NULL then it's nice to have and in
that case this patch actually fixes a possible crash (hence the
version number update).
So I guess that in this case we should just move the
db = netdev_priv(dev) assignment past that NULL test. That's what
this patch does.
Found by the Coverity checker.
Compile tested.
PS. Please keep me on Cc when replying.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
Just remove the dev==NULL test...
Hmm, it would seem there's some disagreement about that :
On 04/08/07, Kyle McMartin [EMAIL PROTECTED] wrote:
...
It *can* be null, in the case of another handler being registered on the
same irq number, passing NULL for the cookie.
Ack. Will apply.
Regards,
Kyle
I'll let you and Kyle fight it out :-)
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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][RESEND] Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function
On Sunday 05 August 2007 17:42:31 Justin T. Gibbs wrote:
> All of this logic was simplified back in '05 in the BSD drivers by adding
> this to the top of the function:
>
> u_int dummy_column;
>
> if (cur_column == NULL) {
> dummy_column = 0;
> cur_column = _column;
> }
>
> and then stripping out the cur_column == NULL checks in the routine.
>
Thank you for that info.
James, if that sounds like a better way to deal with it to you, then
here's a patch to implement it.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/scsi/aic7xxx/aic7xxx_core.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic7xxx_core.c
b/drivers/scsi/aic7xxx/aic7xxx_core.c
index 75733b0..d1f3f25 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_core.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_core.c
@@ -6529,8 +6529,14 @@ ahc_print_register(ahc_reg_parse_entry_t *table, u_int
num_entries,
{
int printed;
u_int printed_mask;
+ u_int dummy_column;
- if (cur_column != NULL && *cur_column >= wrap_point) {
+ if (!cur_column) {
+ dummy_column = 0;
+ cur_column = _column;
+ }
+
+ if (*cur_column >= wrap_point) {
printf("\n");
*cur_column = 0;
}
@@ -6565,8 +6571,7 @@ ahc_print_register(ahc_reg_parse_entry_t *table, u_int
num_entries,
printed += printf(") ");
else
printed += printf(" ");
- if (cur_column != NULL)
- *cur_column += printed;
+ *cur_column += printed;
return (printed);
}
-
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][RESEND] Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function
On 04/08/07, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-08-04 at 20:30 +0200, Jesper Juhl wrote:
> > (resend of patch previously submitted on 28-Jul-2007 23:06)
> >
> >
> > Ehlo,
> >
> > The Coverity checker noticed that we have a potential NULL pointer
> > deref in drivers/scsi/aic7xxx/aic7xxx_core.c::ahc_print_register().
> > This patch handles it by adding the same test against NULL that is
> > used elsewhere in the same function.
>
> It's on my list of things to look at ... but not very high. I suspect
> it actually isn't triggerable, but if you can tell me how, it will save
> me from looking.
>
Here's what Coverity reported :
...
6525int
6526ahc_print_register(ahc_reg_parse_entry_t *table, u_int num_entries,
6527 const char *name, u_int address, u_int value,
6528 u_int *cur_column, u_int wrap_point)
6529{
6530int printed;
6531u_int printed_mask;
6532
Event var_compare_op: Added "cur_column" due to comparison "cur_column != 0"
Also see events: [var_deref_op]
At conditional (1): "cur_column != 0" taking false path
6533if (cur_column != NULL && *cur_column >= wrap_point) {
6534printf("\n");
6535*cur_column = 0;
6536}
6537printed = printf("%s[0x%x]", name, value);
At conditional (2): "table == 0" taking true path
6538if (table == NULL) {
6539printed += printf(" ");
Event var_deref_op: Variable "cur_column" tracked as NULL was dereferenced.
Also see events: [var_compare_op]
6540*cur_column += printed;
6541return (printed);
6542}
...
So it requires a NULL 'table' and a != NULL 'cur_column' to trigger.
Whether or not that's actually possible I'm not sure, but it seems
safer to guard against it :)
By the way; if this can actually be triggered, then
ahd_print_register() has the same problem.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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][RESEND] efficeon-agp leaks 'struct agp_bridge_data' in error paths of agp_efficeon_probe()
On 05/08/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Jesper Juhl wrote: > > (This is a resend of a patch originally submitted on 24-Jul-2007 00:14) > > > > > > Ok, this is something the coverity checker found (CID: 1813). > > I'm not at all intimate with this code, so I'm not sure if this > > attempt at a fix is correct (but at least it compiles). > > > > Please look it over and NACK if bad or merge if good ;-) > > > > Looks sensible to me. > Good. Thank you for taking a look. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][RESEND] efficeon-agp leaks 'struct agp_bridge_data' in error paths of agp_efficeon_probe()
On 05/08/07, H. Peter Anvin [EMAIL PROTECTED] wrote: Jesper Juhl wrote: (This is a resend of a patch originally submitted on 24-Jul-2007 00:14) Ok, this is something the coverity checker found (CID: 1813). I'm not at all intimate with this code, so I'm not sure if this attempt at a fix is correct (but at least it compiles). Please look it over and NACK if bad or merge if good ;-) Looks sensible to me. Good. Thank you for taking a look. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][RESEND] Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function
On Sunday 05 August 2007 17:42:31 Justin T. Gibbs wrote:
All of this logic was simplified back in '05 in the BSD drivers by adding
this to the top of the function:
u_int dummy_column;
if (cur_column == NULL) {
dummy_column = 0;
cur_column = dummy_column;
}
and then stripping out the cur_column == NULL checks in the routine.
Thank you for that info.
James, if that sounds like a better way to deal with it to you, then
here's a patch to implement it.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/aic7xxx/aic7xxx_core.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic7xxx_core.c
b/drivers/scsi/aic7xxx/aic7xxx_core.c
index 75733b0..d1f3f25 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_core.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_core.c
@@ -6529,8 +6529,14 @@ ahc_print_register(ahc_reg_parse_entry_t *table, u_int
num_entries,
{
int printed;
u_int printed_mask;
+ u_int dummy_column;
- if (cur_column != NULL *cur_column = wrap_point) {
+ if (!cur_column) {
+ dummy_column = 0;
+ cur_column = dummy_column;
+ }
+
+ if (*cur_column = wrap_point) {
printf(\n);
*cur_column = 0;
}
@@ -6565,8 +6571,7 @@ ahc_print_register(ahc_reg_parse_entry_t *table, u_int
num_entries,
printed += printf() );
else
printed += printf( );
- if (cur_column != NULL)
- *cur_column += printed;
+ *cur_column += printed;
return (printed);
}
-
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][RESEND] Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function
On 04/08/07, James Bottomley [EMAIL PROTECTED] wrote:
On Sat, 2007-08-04 at 20:30 +0200, Jesper Juhl wrote:
(resend of patch previously submitted on 28-Jul-2007 23:06)
Ehlo,
The Coverity checker noticed that we have a potential NULL pointer
deref in drivers/scsi/aic7xxx/aic7xxx_core.c::ahc_print_register().
This patch handles it by adding the same test against NULL that is
used elsewhere in the same function.
It's on my list of things to look at ... but not very high. I suspect
it actually isn't triggerable, but if you can tell me how, it will save
me from looking.
Here's what Coverity reported :
...
6525int
6526ahc_print_register(ahc_reg_parse_entry_t *table, u_int num_entries,
6527 const char *name, u_int address, u_int value,
6528 u_int *cur_column, u_int wrap_point)
6529{
6530int printed;
6531u_int printed_mask;
6532
Event var_compare_op: Added cur_column due to comparison cur_column != 0
Also see events: [var_deref_op]
At conditional (1): cur_column != 0 taking false path
6533if (cur_column != NULL *cur_column = wrap_point) {
6534printf(\n);
6535*cur_column = 0;
6536}
6537printed = printf(%s[0x%x], name, value);
At conditional (2): table == 0 taking true path
6538if (table == NULL) {
6539printed += printf( );
Event var_deref_op: Variable cur_column tracked as NULL was dereferenced.
Also see events: [var_compare_op]
6540*cur_column += printed;
6541return (printed);
6542}
...
So it requires a NULL 'table' and a != NULL 'cur_column' to trigger.
Whether or not that's actually possible I'm not sure, but it seems
safer to guard against it :)
By the way; if this can actually be triggered, then
ahd_print_register() has the same problem.
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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 1/2] Group architecture Documentation under Documentation/arch.
On 04/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > On Saturday 04 August 2007 2:07:31 pm Jesper Juhl wrote: > > On 04/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > > > Amiga part Acked-by: Geert Uytterhoeven <[EMAIL PROTECTED]> > > > > > > Move architecture-specific Documentation into a common subdirectory. > > > > ... > > > > I have only one complaint; I don't see an update to Documentation/00-INDEX > > I now have at least three. (I missed blackfin, which wasn't there last time I > did this.) > I'm not talking about Documentation//00-INDEX, but the 00-INDEX file in the top-level Documentation directory. Or am I misunderstanding you? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/2] Group multiport serial card documentation under Documentation/serial
On 04/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > Acked-by: Randy Dunlap <[EMAIL PROTECTED]> > > -- > > Equivalent to: > > git-mv sx.txt stallion.txt specialix.txt rocket.txt riscom8.txt \ > computone.txt hayes-esp.txt moxa-smartio serial > > Again, just confirmed it still applies. > > diff --git a/Documentation/computone.txt b/Documentation/serial/computone.txt > similarity index 100% > rename from Documentation/computone.txt > rename to Documentation/serial/computone.txt > diff --git a/Documentation/hayes-esp.txt b/Documentation/serial/hayes-esp.txt > similarity index 100% > rename from Documentation/hayes-esp.txt > rename to Documentation/serial/hayes-esp.txt > diff --git a/Documentation/moxa-smartio b/Documentation/serial/moxa-smartio > similarity index 100% > rename from Documentation/moxa-smartio > rename to Documentation/serial/moxa-smartio > diff --git a/Documentation/riscom8.txt b/Documentation/serial/riscom8.txt > similarity index 100% > rename from Documentation/riscom8.txt > rename to Documentation/serial/riscom8.txt > diff --git a/Documentation/rocket.txt b/Documentation/serial/rocket.txt > similarity index 100% > rename from Documentation/rocket.txt > rename to Documentation/serial/rocket.txt > diff --git a/Documentation/specialix.txt b/Documentation/serial/specialix.txt > similarity index 100% > rename from Documentation/specialix.txt > rename to Documentation/serial/specialix.txt > diff --git a/Documentation/stallion.txt b/Documentation/serial/stallion.txt > similarity index 100% > rename from Documentation/stallion.txt > rename to Documentation/serial/stallion.txt > diff --git a/Documentation/sx.txt b/Documentation/serial/sx.txt > similarity index 100% > rename from Documentation/sx.txt > rename to Documentation/serial/sx.txt Again I have to point out that you are neglecting to update Documentation/00-INDEX -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 1/2] Group architecture Documentation under Documentation/arch.
On 04/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > Amiga part Acked-by: Geert Uytterhoeven <[EMAIL PROTECTED]> > > Move architecture-specific Documentation into a common subdirectory. > ... I have only one complaint; I don't see an update to Documentation/00-INDEX -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][RESEND] Clarify the GPL version of contributions by Jesper Juhl in CREDITS
On 04/08/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Sat, Aug 04, 2007 at 08:31:32PM +0200, Jesper Juhl wrote: > > (resending trivial patch, originally from 18/6-2007 02:33) > > > > > > Just to make things clear in the light of recent discussions about > > licensing. > > Stuff I contribute to the Linux kernel are licensed under the terms of the > > GPL version 2. > > This really doesn't elong into CREDITS. If you're not good enough with > the general GPLv2 stance add additional diclaimers to the files you've > made changes to (in an extent that is copyrightable) > Ok, I can live with that. I just got paranoid after all the recent GVLv2 vs GPLv3 flamewars and though it would be best to just add some explicit note somewhere and couldn't find a more appropriate place than CREDITS to do so. Feel free to drop this patch... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] Documentation/make/headers_install.txt
On 04/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > From: Rob Landley <[EMAIL PROTECTED]> > > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > > Some documentation for "make headers_install". > > --- > > Earlier discussion was at http://lkml.org/lkml/2007/6/22/7 and I > believe I've responded to all of David's comments. > > --- /dev/null 2007-04-23 10:59:00.0 -0500 > +++ linux-2.6/Documentation/make/headers_install.txt2007-08-04 > 13:04:51.0 -0500 > @@ -0,0 +1,46 @@ > +Exporting kernel headers for use by userspace > += > + > +The "make headers_install" command exports the kernel's header files in a > +form suitable for use by userspace programs. > + > +The linux kernel's exported header files describe the API for user space > +programs attempting to use kernel services. These kernel header files are > +used by the system's C library (such as glibc or uClibc) to define available > +system calls, as well as constants and structures to be used with these > +system calls. The C library's header files include the kernel header files > +from the "linux" subdirectory. The system's libc headers are usually > +installed at the default location /usr/include and the kernel headers in > +subdirectories under that (most notably /usr/include/linux and > +/usr/include/asm). > + > +Kernel headers are backwards compatible, but not forwards compatible. This Perhaps change the text "are backwards compatible" into "try very hard to be backwards compatible" ... ? > +means that a program built against a C library using older kernel headers > +should run on a newer kernel (although it may not have access to new > +features), but a program built against newer kernel headers may not work on > an > +older kernel. > + > +The "make headers_install" command can be run in the top level directory of > the > +kernel source code (or using a standard out-of-tree build). It takes two > +optional arguments: > + > + make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr/include > + > +ARCH indicates which architecture to produce headers for, and defaults to the > +current architecture. The linux/asm directory of the exported kernel headers > +is platform-specific, to see a complete list of supported architectures use > +the command: how about s/"the command"/"the following command from inside a kernel source tree"/ ? > + > + ls -d include/asm-* | sed 's/.*-//' > + > +INSTALL_HDR_PATH indicates where to install the headers. It defaults to > +"./usr/include". > + > +The command "make headers_install_all" exports headers for all architectures > +simultaneously. (This is mostly of interest to distribution maintainers, > +who create an architecture-independent tarball from the resulting include > +directory.) Remember to provide the appropriate linux/asm directory via "mv" > +or "ln -s" before building a C library with headers exported this way. > + > +The kernel header export infrastructure is maintained by David Woodhouse > +<[EMAIL PROTECTED]>. > Overall, looks good. Acked by: Jesper Juhl <[EMAIL PROTECTED]> -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][RESEND][ISDN] Guard against a potential NULL pointer dereference in old_capi_manufacturer()
(first send: Monday 25 June 2007, resending due to no response) (resending again on August 8'th, 2007) In drivers/isdn/capi/kcapi.c::old_capi_manufacturer(), if the call to get_capi_ctr_by_nr(ldef.contr); in line 823 returns NULL, then we'll be dereferencing a NULL pointer in the very next line. (Found by Coverity checker as bug #402) Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/isdn/capi/kcapi.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/isdn/capi/kcapi.c b/drivers/isdn/capi/kcapi.c index 3ed34f7..3f9e962 100644 --- a/drivers/isdn/capi/kcapi.c +++ b/drivers/isdn/capi/kcapi.c @@ -821,6 +821,8 @@ static int old_capi_manufacturer(unsigned int cmd, void __user *data) return -EFAULT; } card = get_capi_ctr_by_nr(ldef.contr); + if (!card) + return -EINVAL; card = capi_ctr_get(card); if (!card) return -ESRCH; - 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][RESEND][pnp] Avoid a small unlikely memory leak in proc_read_escd()
(Resending patch originally submitted on 20/7-2007 23:41)
Hi,
There's a small and unlikely memory leak in
drivers/pnp/pnpbios/proc.c::proc_read_escd(). It's inside a sanity
check, so it probably won't trigger often (if at all), however it
*is* a potential leak and it's easy to avoid, so let's just fix it :)
While I was in there I also broke a oneline 'if' statement into two
lines - seemed too trivial a changee to warrent a seperate patch.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/pnp/pnpbios/proc.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/pnp/pnpbios/proc.c b/drivers/pnp/pnpbios/proc.c
index 8027073..f77b8c4 100644
--- a/drivers/pnp/pnpbios/proc.c
+++ b/drivers/pnp/pnpbios/proc.c
@@ -88,7 +88,8 @@ static int proc_read_escd(char *buf, char **start, off_t pos,
}
tmpbuf = kzalloc(escd.escd_size, GFP_KERNEL);
- if (!tmpbuf) return -ENOMEM;
+ if (!tmpbuf)
+ return -ENOMEM;
if (pnp_bios_read_escd(tmpbuf, escd.nv_storage_base)) {
kfree(tmpbuf);
@@ -100,6 +101,7 @@ static int proc_read_escd(char *buf, char **start, off_t
pos,
/* sanity check */
if (escd_size > MAX_SANE_ESCD_SIZE) {
printk(KERN_ERR "PnPBIOS: proc_read_escd: ESCD size reported by
BIOS read_escd call is too great\n");
+ kfree(tmpbuf);
return -EFBIG;
}
-
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][RESEND] Semi-pointless NULL test in uli526x driver
(resending previously submitted patch from 16/7-2007 22:40)
Hi,
In drivers/net/tulip/uli526x.c::uli526x_interrupt() there's a test
of the function argument 'void *dev_id' against NULL. But that
test is pretty pointless, since if ever 'dev_id' is NULL we'll
already have crashed inside "netdev_priv(dev)".
I don't think dev_id can ever actually be NULL, so the whole block
inside "if (!dev) {" could probably just go away. But I guess
there's a good reason someone put that ULI526X_DBUG() in there - and
if 'dev_id' /can/ actually be NULL then it's nice to have and in
that case this patch actually fixes a possible crash (hence the
version number update).
So I guess that in this case we should just move the
"db = netdev_priv(dev)" assignment past that NULL test. That's what
this patch does.
Found by the Coverity checker.
Compile tested.
PS. Please keep me on Cc when replying.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/net/tulip/uli526x.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index ca2548e..3df2376 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -13,8 +13,8 @@
*/
#define DRV_NAME "uli526x"
-#define DRV_VERSION"0.9.3"
-#define DRV_RELDATE"2005-7-29"
+#define DRV_VERSION"0.9.4"
+#define DRV_RELDATE"2007-7-16"
#include
@@ -662,7 +662,7 @@ static int uli526x_stop(struct net_device *dev)
static irqreturn_t uli526x_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
- struct uli526x_board_info *db = netdev_priv(dev);
+ struct uli526x_board_info *db;
unsigned long ioaddr = dev->base_addr;
unsigned long flags;
@@ -670,6 +670,7 @@ static irqreturn_t uli526x_interrupt(int irq, void *dev_id)
ULI526X_DBUG(1, "uli526x_interrupt() without DEVICE arg", 0);
return IRQ_NONE;
}
+ db = netdev_priv(dev);
spin_lock_irqsave(>lock, flags);
outl(0, ioaddr + DCR7);
-
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][RESEND][Trivial] Documentation: sysrq, description of 'h' slightly inaccurate
(Resending a patch from 21 May 2007 that never got any response) Hello, In Documentation/sysrq.txt, the description of 'h' says that any key not listed *above* will generate help. That's obviously not true since all the keys listed below 'h' will do what they are described to do, not display help. So change the text so that it says that any key not listed in the table will generate help, which is what really happens. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- Documentation/sysrq.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index ba328f2..865b271 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt @@ -1,6 +1,6 @@ Linux Magic System Request Key Hacks Documentation for sysrq.c -Last update: 2007-MAR-14 +Last update: 2007-AUG-04 * What is the magic SysRq key? ~~~ @@ -78,7 +78,7 @@ On all - write a character to /proc/sysrq-trigger. e.g.: 'g'- Used by kgdb on ppc and sh platforms. 'h' - Will display help (actually any other key than those listed - above will display help. but 'h' is easy to remember :-) + here will display help. but 'h' is easy to remember :-) 'i' - Send a SIGKILL to all processes, except for init. - 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][RESEND] Clarify the GPL version of contributions by Jesper Juhl in CREDITS
(resending trivial patch, originally from 18/6-2007 02:33) Just to make things clear in the light of recent discussions about licensing. Stuff I contribute to the Linux kernel are licensed under the terms of the GPL version 2. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- CREDITS |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/CREDITS b/CREDITS index 273d72b..4a56f2a 100644 --- a/CREDITS +++ b/CREDITS @@ -1639,6 +1639,7 @@ N: Jesper Juhl E: [EMAIL PROTECTED] D: Various fixes, cleanups and minor features all over the tree. D: Wrote initial version of the hdaps driver (since passed on to others). +D: All contributions are licensed under the terms of the GPL version 2. S: Lemnosvej 1, 3.tv S: 2300 Copenhagen S. S: Denmark - 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][RESEND][ISDN] fix possible NULL deref on low memory condition in capidrv.c::send_message()
(first send: Monday 25 June 2007, resending due to no response)
(resending again since there has still been no response)
If we fail to allocate an skb in
drivers/isdn/capi/capidrv.c::send_message(), then we'll end up
dereferencing a NULL pointer.
Since out of memory conditions are not unheard of, I believe it
is better to print a error message and just return rather than
bring down the whole kernel.
Sure, doing this may upset some application, but that's still
better than crashing the whole system.
(ps. please Cc me on replies from the isdn4linux list since I'm not subscribed
there)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/isdn/capi/capidrv.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index 23b6f7b..476012b 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -506,9 +506,14 @@ static void send_message(capidrv_contr * card, _cmsg *
cmsg)
{
struct sk_buff *skb;
size_t len;
+
capi_cmsg2message(cmsg, cmsg->buf);
len = CAPIMSG_LEN(cmsg->buf);
skb = alloc_skb(len, GFP_ATOMIC);
+ if (!skb) {
+ printk(KERN_ERR "capidrv::send_message: can't allocate mem\n");
+ return;
+ }
memcpy(skb_put(skb, len), cmsg->buf, len);
if (capi20_put_message(, skb) != CAPI_NOERROR)
kfree_skb(skb);
-
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][RESEND][silly] Reduce size of the xterm-linux.xpm image by 12 bytes.
Ok, this is a bit silly (but also a little fun) :-)
In Documentation/ we have the xterm-linux.xpm image.
Now an XPM image is more or less C code, so I thought it would
be fun to look at it like that and put on the CodingStyle and
space use glasses.
I made two changes, none of which change the actual image.
1) I removed two lines that just had empty comments.
2) I brought the 'image_name' declaration into line with how
we commonly write arrays and pointers.
This saves us an astonishing 12 bytes on the file size ;-)
That's a little less data for every future Linux kernel source
user to download - that can't be bad.
Ok, ok, so it does have the drawback of being 99,999% churn and
you could argue that it'll clutter the git history. So if you
don't apply it I won't hate you (too much) ;-)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
diff --git a/Documentation/xterm-linux.xpm b/Documentation/xterm-linux.xpm
index f469c1a..93cb180 100644
--- a/Documentation/xterm-linux.xpm
+++ b/Documentation/xterm-linux.xpm
@@ -9,10 +9,8 @@
/** Swiss Federal Institute of Technology **/
/** Central Computing Service **/
/*/
-static char * image_name [] = {
-/**/
+static char *image_name[] = {
"64 38 8 1",
-/**/
" s mask c none",
". c gray70",
"X c gray85",
-
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][RESEND] improve scripts/gcc-version.sh output a bit when called without args
(Resend of patch from 7 May 2007 17:18:00)
Currently, if you call scripts/gcc-version.sh without arguments it will
generate this output :
$ sh scripts/gcc-version.sh
scripts/gcc-version.sh: line 12: [: =: unary operator expected
scripts/gcc-version.sh: line 16: -E: command not found
scripts/gcc-version.sh: line 17: -E: command not found
Not too pretty. I believe this is an improvement :
$ sh scripts/gcc-version.sh
Error: No compiler specified.
Usage:
scripts/gcc-version.sh
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
scripts/gcc-version.sh |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/scripts/gcc-version.sh b/scripts/gcc-version.sh
index 8a1d187..a5121a6 100644
--- a/scripts/gcc-version.sh
+++ b/scripts/gcc-version.sh
@@ -9,10 +9,16 @@
# gcc-2.95.3, `030301' for gcc-3.3.1, etc.
#
-if [ $1 = "-p" ] ; then with_patchlevel=1; shift; fi
+if [[ $1 = "-p" ]] ; then with_patchlevel=1; shift; fi
compiler="$*"
+if [ ${#compiler} -eq 0 ]; then
+ echo "Error: No compiler specified."
+ echo -e "Usage:\n\t$0 "
+ exit 1
+fi
+
MAJOR=$(echo __GNUC__ | $compiler -E -xc - | tail -n 1)
MINOR=$(echo __GNUC_MINOR__ | $compiler -E -xc - | tail -n 1)
if [ "x$with_patchlevel" != "x" ] ; then
-
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][RESEND] Avoid possible NULL pointer deref in 3c359 driver
(Resending old patch originally submitted at 1/7-2007 02:19)
In xl_freemem(), if dev_if is NULL, the line
struct xl_private *xl_priv =(struct xl_private *)dev->priv;
will cause a NULL pointer dereference. However, if we move
that assignment below the 'if' statement that tests for a NULL
'dev', then that NULL deref can never happen.
It never hurts to be safe :-)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index e22a3f5..671f4da 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -1044,15 +1044,17 @@ static void xl_freemem(struct net_device *dev)
static irqreturn_t xl_interrupt(int irq, void *dev_id)
{
struct net_device *dev = (struct net_device *)dev_id;
- struct xl_private *xl_priv =(struct xl_private *)dev->priv;
- u8 __iomem * xl_mmio = xl_priv->xl_mmio ;
- u16 intstatus, macstatus ;
+ struct xl_private *xl_priv;
+ u8 __iomem * xl_mmio;
+ u16 intstatus, macstatus;
if (!dev) {
- printk(KERN_WARNING "Device structure dead, aaa !\n") ;
+ printk(KERN_WARNING "3c359: Device structure dead, aaa!\n");
return IRQ_NONE;
}
+ xl_priv = (struct xl_private *)dev->priv;
+ xl_mmio = xl_priv->xl_mmio;
intstatus = readw(xl_mmio + MMIO_INTSTATUS) ;
if (!(intstatus & 1)) /* We didn't generate the interrupt */
-
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][RESEND][Trivial] fix tiny spelling error in comment in cfi_cmdset_0001.c
(resending old patch from 5/7-2007 02:18) Trivial fix of a spelling error in a comment in cfi_cmdset_0001.c s/ships/chips/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/mtd/chips/cfi_cmdset_0001.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c index 2f19fa7..c266ebc 100644 --- a/drivers/mtd/chips/cfi_cmdset_0001.c +++ b/drivers/mtd/chips/cfi_cmdset_0001.c @@ -526,7 +526,7 @@ static int cfi_intelext_partition_fixup(struct mtd_info *mtd, struct cfi_pri_intelext *extp = cfi->cmdset_priv; /* -* Probing of multi-partition flash ships. +* Probing of multi-partition flash chips. * * To support multiple partitions when available, we simply arrange * for each of them to have their own flchip structure even if they - 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][RESEND] au88x0: mem leak fix in snd_vortex_create()
(resend of patch previously submitted on 04-Aug-2007 02:09) Hi, In sound/pci/au88x0/au88x0.c::snd_vortex_create() : The Coverity checker found that if we allocate storage for 'chip' but then leave via the regions_out: label, then we end up leaking the storage allocated for 'chip'. I believe simply freeing 'chip' before the "return err;" line is all we need to fix this, but please double-check me :) Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Acked-by: Rene Herman <[EMAIL PROTECTED]> --- diff --git a/sound/pci/au88x0/au88x0.c b/sound/pci/au88x0/au88x0.c index 5ec1b6f..f70286a 100644 --- a/sound/pci/au88x0/au88x0.c +++ b/sound/pci/au88x0/au88x0.c @@ -232,6 +232,7 @@ snd_vortex_create(struct snd_card *card, struct pci_dev *pci, vortex_t ** rchip) pci_disable_device(chip->pci_dev); //FIXME: this not the right place to unregister the gameport vortex_gameport_unregister(chip); + kfree(chip); return err; } - 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][RESEND] fix a potential NULL pointer deref in XFS on failed mount.
Back in 2006 (2006-10-31 to be specific, reposted on 2006-11-16), I
submitted a patch to fix a potential NULL pointer deref in XFS on
failed mount.
The patch drew some comments and it turned out that my initial
approach to a fix was wrong.
David Chinner kindly offered some tips on how to implement a proper
fix, and on 2006-11-20 I submitted a revised fix. This patch,
unfortunately, didn't draw any comments, nor did it ever get merged
anywhere.
I believe that now sufficient time has passed to warrent a repost.
And now, on August 4, 2007 - yet another resend.
it would really be nice if this patch could either get merged or,
if it is wrong for some reason, get an explicit NACK. Come on people,
what's it going to be?
The Coverity checker spotted (as bug #346) a potential problem in XFS.
The problem is that if, in xfs_mount(), this code triggers:
...
if (!mp->m_logdev_targp)
goto error0;
...
Then we'll end up calling xfs_unmountfs_close() with a NULL
'mp->m_logdev_targp'.
This in turn will result in a call to xfs_free_buftarg() with its 'btp'
argument == NULL. xfs_free_buftarg() dereferences 'btp' leading to
a NULL pointer dereference and crash.
I think this can happen, since the fatal call to xfs_free_buftarg()
happens when 'm_logdev_targp != m_ddev_targp' and due to a check of
'm_ddev_targp' against NULL in xfs_mount() (and subsequent return if it is
NULL) the two will never both be NULL when we hit the error0 label from
the two lines cited above.
This patch fixes the issue by checking mp->m_logdev_targp against NULL
in xfs_unmountfs_close() and doing the proper xfs_blkdev_put(logdev);
and xfs_blkdev_put(rtdev); on (!mp->m_rtdev_targp) in xfs_mount().
Compile tested.
Comments and feedback welcome.
Please consider merging.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
fs/xfs/xfs_mount.c |2 +-
fs/xfs/xfs_vfsops.c | 10 --
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index a66b398..215e041 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1275,7 +1275,7 @@ xfs_unmountfs(xfs_mount_t *mp, struct cred *cr)
void
xfs_unmountfs_close(xfs_mount_t *mp, struct cred *cr)
{
- if (mp->m_logdev_targp != mp->m_ddev_targp)
+ if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp)
xfs_free_buftarg(mp->m_logdev_targp, 1);
if (mp->m_rtdev_targp)
xfs_free_buftarg(mp->m_rtdev_targp, 1);
diff --git a/fs/xfs/xfs_vfsops.c b/fs/xfs/xfs_vfsops.c
index 11f5ea2..6d4bc5d 100644
--- a/fs/xfs/xfs_vfsops.c
+++ b/fs/xfs/xfs_vfsops.c
@@ -482,13 +482,19 @@ xfs_mount(
}
if (rtdev) {
mp->m_rtdev_targp = xfs_alloc_buftarg(rtdev, 1);
- if (!mp->m_rtdev_targp)
+ if (!mp->m_rtdev_targp) {
+ xfs_blkdev_put(logdev);
+ xfs_blkdev_put(rtdev);
goto error0;
+ }
}
mp->m_logdev_targp = (logdev && logdev != ddev) ?
xfs_alloc_buftarg(logdev, 1) : mp->m_ddev_targp;
- if (!mp->m_logdev_targp)
+ if (!mp->m_logdev_targp) {
+ xfs_blkdev_put(logdev);
+ xfs_blkdev_put(rtdev);
goto error0;
+ }
/*
* Setup flags based on mount(2) options and then the superblock
-
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/
Resending a bunch of old(ish) patches
Hi Andrew, I just went through my mailbox and found a bunch of old patches that never got any comments (or at the very least never got applied). I would hate to see the work I did creating them go to waste, so I'm going to resend them all to you and Cc all the original recipients and then I hope that you'll give them a (hopefully temporary) home in -mm :-) They are all pretty trivial and shouldn't take you long to review. Kind regards, Jesper Juhl <[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/
[PATCH][RESEND] Fix several memory leaks in cr_backlight_probe() - take2
This is a resend of a patch I originally submitted on 23/7-2007 23:32.
That patch was an updated version of one originally submitted on 21-Jul-2007
00:56.
The original patch made a brief appearance in -mm, but was dropped
due to concerns raised by Richard Purdie that it didn't fix all issues.
Here are Richard's comments:
> The problems you've spotted are valid however the error paths are still
> broken both before and after this patch since there is no call to
> backlight_device_unregister() and/or lcd_device_unregister() in the
> probe function.
>
The following patch fixes the same problems as the original and also
tries to fix the stuff that Richard pointed out.
Hopefully this time it is perfect :-)
Here's the new version of the patch :
After fixing the too small memory allocation in cr_backlight_probe()
from drivers/video/backlight/cr_bllcd.c
(commit e3bbb3f05339de438faf54124f25c92e6fe4ac2e) I noticed that the
Coverity checker also thought there were a few memory leaks in there.
I took a closer look and confirmed that there were indeed several
leaks.
At the start of the function we allocate storage for a
'struct cr_panel' and store the pointer in a variable named 'crp'.
Then we call pci_get_device() and pci_read_config_byte() and if
either of them fail we return without freeing the memory allocated
for the 'struct cr_panel'. These two leaks are easy to fix since we
don't even use 'crp' for anything up to this point, so I simply
moved the allocation further down in the function so it only happens
just before we actually need it.
A bit further down we call backlight_device_register() and store the
result in 'crp->cr_backlight_device'. In case of error we return
'crp->cr_backlight_device' from the function, thus leaking 'crp'
itself. The same thing happens with the call to lcd_device_register().
To fix these two leaks I declare two new pointers to hold the return
values, so that in case of error we can return the pointer (as before)
but without leaking 'crp'.
This version of the patch also adds missing
backlight_device_unregister() / lcd_device_unregister() / pci_dev_put()
calls to error paths.
Thanks to Richard Purdie <[EMAIL PROTECTED]> for noticing.
Please consider merging.
Note: Due to lack of hardware the patch has only been compile tested.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/video/backlight/cr_bllcd.c | 35 ---
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/video/backlight/cr_bllcd.c
b/drivers/video/backlight/cr_bllcd.c
index b7904da..92e201e 100644
--- a/drivers/video/backlight/cr_bllcd.c
+++ b/drivers/video/backlight/cr_bllcd.c
@@ -171,13 +171,11 @@ static struct lcd_ops cr_lcd_ops = {
static int cr_backlight_probe(struct platform_device *pdev)
{
+ struct backlight_device *bdp;
+ struct lcd_device *ldp;
struct cr_panel *crp;
u8 dev_en;
- crp = kzalloc(sizeof(*crp), GFP_KERNEL);
- if (crp == NULL)
- return -ENOMEM;
-
lpc_dev = pci_get_device(PCI_VENDOR_ID_INTEL,
CRVML_DEVICE_LPC, NULL);
if (!lpc_dev) {
@@ -193,27 +191,34 @@ static int cr_backlight_probe(struct platform_device
*pdev)
return -ENODEV;
}
- crp->cr_backlight_device = backlight_device_register("cr-backlight",
->dev, NULL,
-_backlight_ops);
- if (IS_ERR(crp->cr_backlight_device)) {
+ bdp = backlight_device_register("cr-backlight",
+ >dev, NULL, _backlight_ops);
+ if (IS_ERR(bdp)) {
pci_dev_put(lpc_dev);
- return PTR_ERR(crp->cr_backlight_device);
+ return PTR_ERR(bdp);
}
- crp->cr_lcd_device = lcd_device_register("cr-lcd",
- >dev, NULL,
- _lcd_ops);
-
- if (IS_ERR(crp->cr_lcd_device)) {
+ ldp = lcd_device_register("cr-lcd", >dev, NULL, _lcd_ops);
+ if (IS_ERR(ldp)) {
+ backlight_device_unregister(bdp);
pci_dev_put(lpc_dev);
- return PTR_ERR(crp->cr_backlight_device);
+ return PTR_ERR(bdp);
}
pci_read_config_dword(lpc_dev, CRVML_REG_GPIOBAR,
_bar);
gpio_bar &= ~0x3F;
+ crp = kzalloc(sizeof(*crp), GFP_KERNEL);
+ if (!crp) {
+ lcd_device_unregister(ldp);
+ backlight_device_unregister(bdp);
+ pci_dev_put(lpc_dev);
+ return -ENOMEM;
+ }
+
+ crp->cr_backlight_device = bdp;
+ crp->cr_lcd_device = ldp;
crp->cr_b
Re: [PATCH][ACPI] Let's not gamble that a possible double free will never happen in asus_hotk_get_info()
On 03/08/07, Len Brown <[EMAIL PROTECTED]> wrote: > On Saturday 28 July 2007 18:45, Jesper Juhl wrote: > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > > --- > > > > drivers/acpi/asus_acpi.c | 1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c > > index 9c4bd22..86fd142 100644 > > --- a/drivers/acpi/asus_acpi.c > > +++ b/drivers/acpi/asus_acpi.c > > @@ -1192,6 +1192,7 @@ static int asus_hotk_get_info(void) > > break; > > default: > > kfree(model); > > +model = NULL; > > break; > > } > > } > > applied. > > coverity didn't find the bug below this code however. > we can also leak model in the path that returns OK. > Whoops, I should have spotted that. I assume you've now fixed that locally? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][ACPI] Let's not gamble that a possible double free will never happen in asus_hotk_get_info()
On 03/08/07, Len Brown [EMAIL PROTECTED] wrote: On Saturday 28 July 2007 18:45, Jesper Juhl wrote: Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- drivers/acpi/asus_acpi.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c index 9c4bd22..86fd142 100644 --- a/drivers/acpi/asus_acpi.c +++ b/drivers/acpi/asus_acpi.c @@ -1192,6 +1192,7 @@ static int asus_hotk_get_info(void) break; default: kfree(model); +model = NULL; break; } } applied. coverity didn't find the bug below this code however. we can also leak model in the path that returns OK. Whoops, I should have spotted that. I assume you've now fixed that locally? -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/
Resending a bunch of old(ish) patches
Hi Andrew, I just went through my mailbox and found a bunch of old patches that never got any comments (or at the very least never got applied). I would hate to see the work I did creating them go to waste, so I'm going to resend them all to you and Cc all the original recipients and then I hope that you'll give them a (hopefully temporary) home in -mm :-) They are all pretty trivial and shouldn't take you long to review. Kind regards, Jesper Juhl [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/
[PATCH][RESEND] Fix several memory leaks in cr_backlight_probe() - take2
This is a resend of a patch I originally submitted on 23/7-2007 23:32.
That patch was an updated version of one originally submitted on 21-Jul-2007
00:56.
The original patch made a brief appearance in -mm, but was dropped
due to concerns raised by Richard Purdie that it didn't fix all issues.
Here are Richard's comments:
The problems you've spotted are valid however the error paths are still
broken both before and after this patch since there is no call to
backlight_device_unregister() and/or lcd_device_unregister() in the
probe function.
The following patch fixes the same problems as the original and also
tries to fix the stuff that Richard pointed out.
Hopefully this time it is perfect :-)
Here's the new version of the patch :
After fixing the too small memory allocation in cr_backlight_probe()
from drivers/video/backlight/cr_bllcd.c
(commit e3bbb3f05339de438faf54124f25c92e6fe4ac2e) I noticed that the
Coverity checker also thought there were a few memory leaks in there.
I took a closer look and confirmed that there were indeed several
leaks.
At the start of the function we allocate storage for a
'struct cr_panel' and store the pointer in a variable named 'crp'.
Then we call pci_get_device() and pci_read_config_byte() and if
either of them fail we return without freeing the memory allocated
for the 'struct cr_panel'. These two leaks are easy to fix since we
don't even use 'crp' for anything up to this point, so I simply
moved the allocation further down in the function so it only happens
just before we actually need it.
A bit further down we call backlight_device_register() and store the
result in 'crp-cr_backlight_device'. In case of error we return
'crp-cr_backlight_device' from the function, thus leaking 'crp'
itself. The same thing happens with the call to lcd_device_register().
To fix these two leaks I declare two new pointers to hold the return
values, so that in case of error we can return the pointer (as before)
but without leaking 'crp'.
This version of the patch also adds missing
backlight_device_unregister() / lcd_device_unregister() / pci_dev_put()
calls to error paths.
Thanks to Richard Purdie [EMAIL PROTECTED] for noticing.
Please consider merging.
Note: Due to lack of hardware the patch has only been compile tested.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/video/backlight/cr_bllcd.c | 35 ---
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/video/backlight/cr_bllcd.c
b/drivers/video/backlight/cr_bllcd.c
index b7904da..92e201e 100644
--- a/drivers/video/backlight/cr_bllcd.c
+++ b/drivers/video/backlight/cr_bllcd.c
@@ -171,13 +171,11 @@ static struct lcd_ops cr_lcd_ops = {
static int cr_backlight_probe(struct platform_device *pdev)
{
+ struct backlight_device *bdp;
+ struct lcd_device *ldp;
struct cr_panel *crp;
u8 dev_en;
- crp = kzalloc(sizeof(*crp), GFP_KERNEL);
- if (crp == NULL)
- return -ENOMEM;
-
lpc_dev = pci_get_device(PCI_VENDOR_ID_INTEL,
CRVML_DEVICE_LPC, NULL);
if (!lpc_dev) {
@@ -193,27 +191,34 @@ static int cr_backlight_probe(struct platform_device
*pdev)
return -ENODEV;
}
- crp-cr_backlight_device = backlight_device_register(cr-backlight,
-pdev-dev, NULL,
-cr_backlight_ops);
- if (IS_ERR(crp-cr_backlight_device)) {
+ bdp = backlight_device_register(cr-backlight,
+ pdev-dev, NULL, cr_backlight_ops);
+ if (IS_ERR(bdp)) {
pci_dev_put(lpc_dev);
- return PTR_ERR(crp-cr_backlight_device);
+ return PTR_ERR(bdp);
}
- crp-cr_lcd_device = lcd_device_register(cr-lcd,
- pdev-dev, NULL,
- cr_lcd_ops);
-
- if (IS_ERR(crp-cr_lcd_device)) {
+ ldp = lcd_device_register(cr-lcd, pdev-dev, NULL, cr_lcd_ops);
+ if (IS_ERR(ldp)) {
+ backlight_device_unregister(bdp);
pci_dev_put(lpc_dev);
- return PTR_ERR(crp-cr_backlight_device);
+ return PTR_ERR(bdp);
}
pci_read_config_dword(lpc_dev, CRVML_REG_GPIOBAR,
gpio_bar);
gpio_bar = ~0x3F;
+ crp = kzalloc(sizeof(*crp), GFP_KERNEL);
+ if (!crp) {
+ lcd_device_unregister(ldp);
+ backlight_device_unregister(bdp);
+ pci_dev_put(lpc_dev);
+ return -ENOMEM;
+ }
+
+ crp-cr_backlight_device = bdp;
+ crp-cr_lcd_device = ldp;
crp-cr_backlight_device-props.power = FB_BLANK_UNBLANK;
crp-cr_backlight_device-props.brightness = 0;
crp
[PATCH][RESEND] fix a potential NULL pointer deref in XFS on failed mount.
Back in 2006 (2006-10-31 to be specific, reposted on 2006-11-16), I
submitted a patch to fix a potential NULL pointer deref in XFS on
failed mount.
The patch drew some comments and it turned out that my initial
approach to a fix was wrong.
David Chinner kindly offered some tips on how to implement a proper
fix, and on 2006-11-20 I submitted a revised fix. This patch,
unfortunately, didn't draw any comments, nor did it ever get merged
anywhere.
I believe that now sufficient time has passed to warrent a repost.
And now, on August 4, 2007 - yet another resend.
it would really be nice if this patch could either get merged or,
if it is wrong for some reason, get an explicit NACK. Come on people,
what's it going to be?
The Coverity checker spotted (as bug #346) a potential problem in XFS.
The problem is that if, in xfs_mount(), this code triggers:
...
if (!mp-m_logdev_targp)
goto error0;
...
Then we'll end up calling xfs_unmountfs_close() with a NULL
'mp-m_logdev_targp'.
This in turn will result in a call to xfs_free_buftarg() with its 'btp'
argument == NULL. xfs_free_buftarg() dereferences 'btp' leading to
a NULL pointer dereference and crash.
I think this can happen, since the fatal call to xfs_free_buftarg()
happens when 'm_logdev_targp != m_ddev_targp' and due to a check of
'm_ddev_targp' against NULL in xfs_mount() (and subsequent return if it is
NULL) the two will never both be NULL when we hit the error0 label from
the two lines cited above.
This patch fixes the issue by checking mp-m_logdev_targp against NULL
in xfs_unmountfs_close() and doing the proper xfs_blkdev_put(logdev);
and xfs_blkdev_put(rtdev); on (!mp-m_rtdev_targp) in xfs_mount().
Compile tested.
Comments and feedback welcome.
Please consider merging.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
fs/xfs/xfs_mount.c |2 +-
fs/xfs/xfs_vfsops.c | 10 --
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index a66b398..215e041 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1275,7 +1275,7 @@ xfs_unmountfs(xfs_mount_t *mp, struct cred *cr)
void
xfs_unmountfs_close(xfs_mount_t *mp, struct cred *cr)
{
- if (mp-m_logdev_targp != mp-m_ddev_targp)
+ if (mp-m_logdev_targp mp-m_logdev_targp != mp-m_ddev_targp)
xfs_free_buftarg(mp-m_logdev_targp, 1);
if (mp-m_rtdev_targp)
xfs_free_buftarg(mp-m_rtdev_targp, 1);
diff --git a/fs/xfs/xfs_vfsops.c b/fs/xfs/xfs_vfsops.c
index 11f5ea2..6d4bc5d 100644
--- a/fs/xfs/xfs_vfsops.c
+++ b/fs/xfs/xfs_vfsops.c
@@ -482,13 +482,19 @@ xfs_mount(
}
if (rtdev) {
mp-m_rtdev_targp = xfs_alloc_buftarg(rtdev, 1);
- if (!mp-m_rtdev_targp)
+ if (!mp-m_rtdev_targp) {
+ xfs_blkdev_put(logdev);
+ xfs_blkdev_put(rtdev);
goto error0;
+ }
}
mp-m_logdev_targp = (logdev logdev != ddev) ?
xfs_alloc_buftarg(logdev, 1) : mp-m_ddev_targp;
- if (!mp-m_logdev_targp)
+ if (!mp-m_logdev_targp) {
+ xfs_blkdev_put(logdev);
+ xfs_blkdev_put(rtdev);
goto error0;
+ }
/*
* Setup flags based on mount(2) options and then the superblock
-
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][RESEND] au88x0: mem leak fix in snd_vortex_create()
(resend of patch previously submitted on 04-Aug-2007 02:09) Hi, In sound/pci/au88x0/au88x0.c::snd_vortex_create() : The Coverity checker found that if we allocate storage for 'chip' but then leave via the regions_out: label, then we end up leaking the storage allocated for 'chip'. I believe simply freeing 'chip' before the return err; line is all we need to fix this, but please double-check me :) Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Acked-by: Rene Herman [EMAIL PROTECTED] --- diff --git a/sound/pci/au88x0/au88x0.c b/sound/pci/au88x0/au88x0.c index 5ec1b6f..f70286a 100644 --- a/sound/pci/au88x0/au88x0.c +++ b/sound/pci/au88x0/au88x0.c @@ -232,6 +232,7 @@ snd_vortex_create(struct snd_card *card, struct pci_dev *pci, vortex_t ** rchip) pci_disable_device(chip-pci_dev); //FIXME: this not the right place to unregister the gameport vortex_gameport_unregister(chip); + kfree(chip); return err; } - 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][RESEND] improve scripts/gcc-version.sh output a bit when called without args
(Resend of patch from 7 May 2007 17:18:00)
Currently, if you call scripts/gcc-version.sh without arguments it will
generate this output :
$ sh scripts/gcc-version.sh
scripts/gcc-version.sh: line 12: [: =: unary operator expected
scripts/gcc-version.sh: line 16: -E: command not found
scripts/gcc-version.sh: line 17: -E: command not found
Not too pretty. I believe this is an improvement :
$ sh scripts/gcc-version.sh
Error: No compiler specified.
Usage:
scripts/gcc-version.sh gcc-command
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
scripts/gcc-version.sh |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/scripts/gcc-version.sh b/scripts/gcc-version.sh
index 8a1d187..a5121a6 100644
--- a/scripts/gcc-version.sh
+++ b/scripts/gcc-version.sh
@@ -9,10 +9,16 @@
# gcc-2.95.3, `030301' for gcc-3.3.1, etc.
#
-if [ $1 = -p ] ; then with_patchlevel=1; shift; fi
+if [[ $1 = -p ]] ; then with_patchlevel=1; shift; fi
compiler=$*
+if [ ${#compiler} -eq 0 ]; then
+ echo Error: No compiler specified.
+ echo -e Usage:\n\t$0 gcc-command
+ exit 1
+fi
+
MAJOR=$(echo __GNUC__ | $compiler -E -xc - | tail -n 1)
MINOR=$(echo __GNUC_MINOR__ | $compiler -E -xc - | tail -n 1)
if [ x$with_patchlevel != x ] ; then
-
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][RESEND] Avoid possible NULL pointer deref in 3c359 driver
(Resending old patch originally submitted at 1/7-2007 02:19)
In xl_freemem(), if dev_if is NULL, the line
struct xl_private *xl_priv =(struct xl_private *)dev-priv;
will cause a NULL pointer dereference. However, if we move
that assignment below the 'if' statement that tests for a NULL
'dev', then that NULL deref can never happen.
It never hurts to be safe :-)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index e22a3f5..671f4da 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -1044,15 +1044,17 @@ static void xl_freemem(struct net_device *dev)
static irqreturn_t xl_interrupt(int irq, void *dev_id)
{
struct net_device *dev = (struct net_device *)dev_id;
- struct xl_private *xl_priv =(struct xl_private *)dev-priv;
- u8 __iomem * xl_mmio = xl_priv-xl_mmio ;
- u16 intstatus, macstatus ;
+ struct xl_private *xl_priv;
+ u8 __iomem * xl_mmio;
+ u16 intstatus, macstatus;
if (!dev) {
- printk(KERN_WARNING Device structure dead, aaa !\n) ;
+ printk(KERN_WARNING 3c359: Device structure dead, aaa!\n);
return IRQ_NONE;
}
+ xl_priv = (struct xl_private *)dev-priv;
+ xl_mmio = xl_priv-xl_mmio;
intstatus = readw(xl_mmio + MMIO_INTSTATUS) ;
if (!(intstatus 1)) /* We didn't generate the interrupt */
-
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][RESEND][Trivial] fix tiny spelling error in comment in cfi_cmdset_0001.c
(resending old patch from 5/7-2007 02:18) Trivial fix of a spelling error in a comment in cfi_cmdset_0001.c s/ships/chips/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- drivers/mtd/chips/cfi_cmdset_0001.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c index 2f19fa7..c266ebc 100644 --- a/drivers/mtd/chips/cfi_cmdset_0001.c +++ b/drivers/mtd/chips/cfi_cmdset_0001.c @@ -526,7 +526,7 @@ static int cfi_intelext_partition_fixup(struct mtd_info *mtd, struct cfi_pri_intelext *extp = cfi-cmdset_priv; /* -* Probing of multi-partition flash ships. +* Probing of multi-partition flash chips. * * To support multiple partitions when available, we simply arrange * for each of them to have their own flchip structure even if they - 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][RESEND][silly] Reduce size of the xterm-linux.xpm image by 12 bytes.
Ok, this is a bit silly (but also a little fun) :-)
In Documentation/ we have the xterm-linux.xpm image.
Now an XPM image is more or less C code, so I thought it would
be fun to look at it like that and put on the CodingStyle and
space use glasses.
I made two changes, none of which change the actual image.
1) I removed two lines that just had empty comments.
2) I brought the 'image_name' declaration into line with how
we commonly write arrays and pointers.
This saves us an astonishing 12 bytes on the file size ;-)
That's a little less data for every future Linux kernel source
user to download - that can't be bad.
Ok, ok, so it does have the drawback of being 99,999% churn and
you could argue that it'll clutter the git history. So if you
don't apply it I won't hate you (too much) ;-)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
diff --git a/Documentation/xterm-linux.xpm b/Documentation/xterm-linux.xpm
index f469c1a..93cb180 100644
--- a/Documentation/xterm-linux.xpm
+++ b/Documentation/xterm-linux.xpm
@@ -9,10 +9,8 @@
/** Swiss Federal Institute of Technology **/
/** Central Computing Service **/
/*/
-static char * image_name [] = {
-/**/
+static char *image_name[] = {
64 38 8 1,
-/**/
s mask c none,
. c gray70,
X c gray85,
-
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][RESEND][Trivial] Documentation: sysrq, description of 'h' slightly inaccurate
(Resending a patch from 21 May 2007 that never got any response) Hello, In Documentation/sysrq.txt, the description of 'h' says that any key not listed *above* will generate help. That's obviously not true since all the keys listed below 'h' will do what they are described to do, not display help. So change the text so that it says that any key not listed in the table will generate help, which is what really happens. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- Documentation/sysrq.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index ba328f2..865b271 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt @@ -1,6 +1,6 @@ Linux Magic System Request Key Hacks Documentation for sysrq.c -Last update: 2007-MAR-14 +Last update: 2007-AUG-04 * What is the magic SysRq key? ~~~ @@ -78,7 +78,7 @@ On all - write a character to /proc/sysrq-trigger. e.g.: 'g'- Used by kgdb on ppc and sh platforms. 'h' - Will display help (actually any other key than those listed - above will display help. but 'h' is easy to remember :-) + here will display help. but 'h' is easy to remember :-) 'i' - Send a SIGKILL to all processes, except for init. - 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][RESEND] Clarify the GPL version of contributions by Jesper Juhl in CREDITS
(resending trivial patch, originally from 18/6-2007 02:33) Just to make things clear in the light of recent discussions about licensing. Stuff I contribute to the Linux kernel are licensed under the terms of the GPL version 2. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- CREDITS |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/CREDITS b/CREDITS index 273d72b..4a56f2a 100644 --- a/CREDITS +++ b/CREDITS @@ -1639,6 +1639,7 @@ N: Jesper Juhl E: [EMAIL PROTECTED] D: Various fixes, cleanups and minor features all over the tree. D: Wrote initial version of the hdaps driver (since passed on to others). +D: All contributions are licensed under the terms of the GPL version 2. S: Lemnosvej 1, 3.tv S: 2300 Copenhagen S. S: Denmark - 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][RESEND][ISDN] fix possible NULL deref on low memory condition in capidrv.c::send_message()
(first send: Monday 25 June 2007, resending due to no response)
(resending again since there has still been no response)
If we fail to allocate an skb in
drivers/isdn/capi/capidrv.c::send_message(), then we'll end up
dereferencing a NULL pointer.
Since out of memory conditions are not unheard of, I believe it
is better to print a error message and just return rather than
bring down the whole kernel.
Sure, doing this may upset some application, but that's still
better than crashing the whole system.
(ps. please Cc me on replies from the isdn4linux list since I'm not subscribed
there)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/isdn/capi/capidrv.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index 23b6f7b..476012b 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -506,9 +506,14 @@ static void send_message(capidrv_contr * card, _cmsg *
cmsg)
{
struct sk_buff *skb;
size_t len;
+
capi_cmsg2message(cmsg, cmsg-buf);
len = CAPIMSG_LEN(cmsg-buf);
skb = alloc_skb(len, GFP_ATOMIC);
+ if (!skb) {
+ printk(KERN_ERR capidrv::send_message: can't allocate mem\n);
+ return;
+ }
memcpy(skb_put(skb, len), cmsg-buf, len);
if (capi20_put_message(global.ap, skb) != CAPI_NOERROR)
kfree_skb(skb);
-
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][RESEND][ISDN] Guard against a potential NULL pointer dereference in old_capi_manufacturer()
(first send: Monday 25 June 2007, resending due to no response) (resending again on August 8'th, 2007) In drivers/isdn/capi/kcapi.c::old_capi_manufacturer(), if the call to get_capi_ctr_by_nr(ldef.contr); in line 823 returns NULL, then we'll be dereferencing a NULL pointer in the very next line. (Found by Coverity checker as bug #402) Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- drivers/isdn/capi/kcapi.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/isdn/capi/kcapi.c b/drivers/isdn/capi/kcapi.c index 3ed34f7..3f9e962 100644 --- a/drivers/isdn/capi/kcapi.c +++ b/drivers/isdn/capi/kcapi.c @@ -821,6 +821,8 @@ static int old_capi_manufacturer(unsigned int cmd, void __user *data) return -EFAULT; } card = get_capi_ctr_by_nr(ldef.contr); + if (!card) + return -EINVAL; card = capi_ctr_get(card); if (!card) return -ESRCH; - 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][RESEND][pnp] Avoid a small unlikely memory leak in proc_read_escd()
(Resending patch originally submitted on 20/7-2007 23:41)
Hi,
There's a small and unlikely memory leak in
drivers/pnp/pnpbios/proc.c::proc_read_escd(). It's inside a sanity
check, so it probably won't trigger often (if at all), however it
*is* a potential leak and it's easy to avoid, so let's just fix it :)
While I was in there I also broke a oneline 'if' statement into two
lines - seemed too trivial a changee to warrent a seperate patch.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/pnp/pnpbios/proc.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/pnp/pnpbios/proc.c b/drivers/pnp/pnpbios/proc.c
index 8027073..f77b8c4 100644
--- a/drivers/pnp/pnpbios/proc.c
+++ b/drivers/pnp/pnpbios/proc.c
@@ -88,7 +88,8 @@ static int proc_read_escd(char *buf, char **start, off_t pos,
}
tmpbuf = kzalloc(escd.escd_size, GFP_KERNEL);
- if (!tmpbuf) return -ENOMEM;
+ if (!tmpbuf)
+ return -ENOMEM;
if (pnp_bios_read_escd(tmpbuf, escd.nv_storage_base)) {
kfree(tmpbuf);
@@ -100,6 +101,7 @@ static int proc_read_escd(char *buf, char **start, off_t
pos,
/* sanity check */
if (escd_size MAX_SANE_ESCD_SIZE) {
printk(KERN_ERR PnPBIOS: proc_read_escd: ESCD size reported by
BIOS read_escd call is too great\n);
+ kfree(tmpbuf);
return -EFBIG;
}
-
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][RESEND] Semi-pointless NULL test in uli526x driver
(resending previously submitted patch from 16/7-2007 22:40)
Hi,
In drivers/net/tulip/uli526x.c::uli526x_interrupt() there's a test
of the function argument 'void *dev_id' against NULL. But that
test is pretty pointless, since if ever 'dev_id' is NULL we'll
already have crashed inside netdev_priv(dev).
I don't think dev_id can ever actually be NULL, so the whole block
inside if (!dev) { could probably just go away. But I guess
there's a good reason someone put that ULI526X_DBUG() in there - and
if 'dev_id' /can/ actually be NULL then it's nice to have and in
that case this patch actually fixes a possible crash (hence the
version number update).
So I guess that in this case we should just move the
db = netdev_priv(dev) assignment past that NULL test. That's what
this patch does.
Found by the Coverity checker.
Compile tested.
PS. Please keep me on Cc when replying.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/net/tulip/uli526x.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index ca2548e..3df2376 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -13,8 +13,8 @@
*/
#define DRV_NAME uli526x
-#define DRV_VERSION0.9.3
-#define DRV_RELDATE2005-7-29
+#define DRV_VERSION0.9.4
+#define DRV_RELDATE2007-7-16
#include linux/module.h
@@ -662,7 +662,7 @@ static int uli526x_stop(struct net_device *dev)
static irqreturn_t uli526x_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
- struct uli526x_board_info *db = netdev_priv(dev);
+ struct uli526x_board_info *db;
unsigned long ioaddr = dev-base_addr;
unsigned long flags;
@@ -670,6 +670,7 @@ static irqreturn_t uli526x_interrupt(int irq, void *dev_id)
ULI526X_DBUG(1, uli526x_interrupt() without DEVICE arg, 0);
return IRQ_NONE;
}
+ db = netdev_priv(dev);
spin_lock_irqsave(db-lock, flags);
outl(0, ioaddr + DCR7);
-
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] Documentation/make/headers_install.txt
On 04/08/07, Rob Landley [EMAIL PROTECTED] wrote: From: Rob Landley [EMAIL PROTECTED] Signed-off-by: Rob Landley [EMAIL PROTECTED] Some documentation for make headers_install. --- Earlier discussion was at http://lkml.org/lkml/2007/6/22/7 and I believe I've responded to all of David's comments. --- /dev/null 2007-04-23 10:59:00.0 -0500 +++ linux-2.6/Documentation/make/headers_install.txt2007-08-04 13:04:51.0 -0500 @@ -0,0 +1,46 @@ +Exporting kernel headers for use by userspace += + +The make headers_install command exports the kernel's header files in a +form suitable for use by userspace programs. + +The linux kernel's exported header files describe the API for user space +programs attempting to use kernel services. These kernel header files are +used by the system's C library (such as glibc or uClibc) to define available +system calls, as well as constants and structures to be used with these +system calls. The C library's header files include the kernel header files +from the linux subdirectory. The system's libc headers are usually +installed at the default location /usr/include and the kernel headers in +subdirectories under that (most notably /usr/include/linux and +/usr/include/asm). + +Kernel headers are backwards compatible, but not forwards compatible. This Perhaps change the text are backwards compatible into try very hard to be backwards compatible ... ? +means that a program built against a C library using older kernel headers +should run on a newer kernel (although it may not have access to new +features), but a program built against newer kernel headers may not work on an +older kernel. + +The make headers_install command can be run in the top level directory of the +kernel source code (or using a standard out-of-tree build). It takes two +optional arguments: + + make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr/include + +ARCH indicates which architecture to produce headers for, and defaults to the +current architecture. The linux/asm directory of the exported kernel headers +is platform-specific, to see a complete list of supported architectures use +the command: how about s/the command/the following command from inside a kernel source tree/ ? + + ls -d include/asm-* | sed 's/.*-//' + +INSTALL_HDR_PATH indicates where to install the headers. It defaults to +./usr/include. + +The command make headers_install_all exports headers for all architectures +simultaneously. (This is mostly of interest to distribution maintainers, +who create an architecture-independent tarball from the resulting include +directory.) Remember to provide the appropriate linux/asm directory via mv +or ln -s before building a C library with headers exported this way. + +The kernel header export infrastructure is maintained by David Woodhouse +[EMAIL PROTECTED]. Overall, looks good. Acked by: Jesper Juhl [EMAIL PROTECTED] -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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][RESEND] Clarify the GPL version of contributions by Jesper Juhl in CREDITS
On 04/08/07, Christoph Hellwig [EMAIL PROTECTED] wrote: On Sat, Aug 04, 2007 at 08:31:32PM +0200, Jesper Juhl wrote: (resending trivial patch, originally from 18/6-2007 02:33) Just to make things clear in the light of recent discussions about licensing. Stuff I contribute to the Linux kernel are licensed under the terms of the GPL version 2. This really doesn't elong into CREDITS. If you're not good enough with the general GPLv2 stance add additional diclaimers to the files you've made changes to (in an extent that is copyrightable) Ok, I can live with that. I just got paranoid after all the recent GVLv2 vs GPLv3 flamewars and though it would be best to just add some explicit note somewhere and couldn't find a more appropriate place than CREDITS to do so. Feel free to drop this patch... -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 1/2] Group architecture Documentation under Documentation/arch.
On 04/08/07, Rob Landley [EMAIL PROTECTED] wrote: Signed-off-by: Rob Landley [EMAIL PROTECTED] Amiga part Acked-by: Geert Uytterhoeven [EMAIL PROTECTED] Move architecture-specific Documentation into a common subdirectory. ... I have only one complaint; I don't see an update to Documentation/00-INDEX -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/2] Group multiport serial card documentation under Documentation/serial
On 04/08/07, Rob Landley [EMAIL PROTECTED] wrote: Signed-off-by: Rob Landley [EMAIL PROTECTED] Acked-by: Randy Dunlap [EMAIL PROTECTED] -- Equivalent to: git-mv sx.txt stallion.txt specialix.txt rocket.txt riscom8.txt \ computone.txt hayes-esp.txt moxa-smartio serial Again, just confirmed it still applies. diff --git a/Documentation/computone.txt b/Documentation/serial/computone.txt similarity index 100% rename from Documentation/computone.txt rename to Documentation/serial/computone.txt diff --git a/Documentation/hayes-esp.txt b/Documentation/serial/hayes-esp.txt similarity index 100% rename from Documentation/hayes-esp.txt rename to Documentation/serial/hayes-esp.txt diff --git a/Documentation/moxa-smartio b/Documentation/serial/moxa-smartio similarity index 100% rename from Documentation/moxa-smartio rename to Documentation/serial/moxa-smartio diff --git a/Documentation/riscom8.txt b/Documentation/serial/riscom8.txt similarity index 100% rename from Documentation/riscom8.txt rename to Documentation/serial/riscom8.txt diff --git a/Documentation/rocket.txt b/Documentation/serial/rocket.txt similarity index 100% rename from Documentation/rocket.txt rename to Documentation/serial/rocket.txt diff --git a/Documentation/specialix.txt b/Documentation/serial/specialix.txt similarity index 100% rename from Documentation/specialix.txt rename to Documentation/serial/specialix.txt diff --git a/Documentation/stallion.txt b/Documentation/serial/stallion.txt similarity index 100% rename from Documentation/stallion.txt rename to Documentation/serial/stallion.txt diff --git a/Documentation/sx.txt b/Documentation/serial/sx.txt similarity index 100% rename from Documentation/sx.txt rename to Documentation/serial/sx.txt Again I have to point out that you are neglecting to update Documentation/00-INDEX -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 1/2] Group architecture Documentation under Documentation/arch.
On 04/08/07, Rob Landley [EMAIL PROTECTED] wrote: On Saturday 04 August 2007 2:07:31 pm Jesper Juhl wrote: On 04/08/07, Rob Landley [EMAIL PROTECTED] wrote: Signed-off-by: Rob Landley [EMAIL PROTECTED] Amiga part Acked-by: Geert Uytterhoeven [EMAIL PROTECTED] Move architecture-specific Documentation into a common subdirectory. ... I have only one complaint; I don't see an update to Documentation/00-INDEX I now have at least three. (I missed blackfin, which wasn't there last time I did this.) I'm not talking about Documentation/arch/00-INDEX, but the 00-INDEX file in the top-level Documentation directory. Or am I misunderstanding you? -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: snd-au8830: dead after software suspend
On 04/08/07, Gert Robben <[EMAIL PROTECTED]> wrote: > Robert Hancock wrote: > > Have you reported this to the ALSA people? > No, I thought this might as well be something for PCI or PM people, and > I expected some ALSA people are also reading this list. > If not, where else should I report this exactly? > alsa-devel would seem to be a good starting point - see http://www.alsa-project.org/mailing-lists.php Also, the author of the driver, Manuel Jander <[EMAIL PROTECTED]>, would probably be a good person to add to Cc. And keeping LKML on Cc while sending to above people usually never hurts :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] au88x0: mem leak fix in snd_vortex_create()
Hi, In sound/pci/au88x0/au88x0.c::snd_vortex_create() : The Coverity checker found that if we allocate storage for 'chip' but then leave via the regions_out: label, then we end up leaking the storage allocated for 'chip'. I believe simply freeing 'chip' before the "return err;" line is all we need to fix this, but please double-check me :) Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/sound/pci/au88x0/au88x0.c b/sound/pci/au88x0/au88x0.c index 5ec1b6f..f70286a 100644 --- a/sound/pci/au88x0/au88x0.c +++ b/sound/pci/au88x0/au88x0.c @@ -232,6 +232,7 @@ snd_vortex_create(struct snd_card *card, struct pci_dev *pci, vortex_t ** rchip) pci_disable_device(chip->pci_dev); //FIXME: this not the right place to unregister the gameport vortex_gameport_unregister(chip); + kfree(chip); return err; } - 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] UBI: Don't use signed int as array index before testing if it is negative
Hi,
I can't find anything guaranteeing that 'ubi_num' cannot be <0 in
drivers/mtd/ubi/kapi.c::ubi_open_volume(), and in fact the code
even tests for that and errors out if so. Unfortunately the test
for "ubi_num < 0" happens after we've already used 'ubi_num' as
an array index - bad thing to do if it is negative.
This patch moves the test earlier in the function and then moves
the indexing using that variable after the check. A bit safer :-)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/mtd/ubi/kapi.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index 4a458e8..5130e54 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -99,16 +99,21 @@ struct ubi_volume_desc *ubi_open_volume(int ubi_num, int
vol_id, int mode)
{
int err;
struct ubi_volume_desc *desc;
- struct ubi_device *ubi = ubi_devices[ubi_num];
+ struct ubi_device *ubi;
struct ubi_volume *vol;
dbg_msg("open device %d volume %d, mode %d", ubi_num, vol_id, mode);
err = -ENODEV;
+ if (ubi_num < 0)
+ return ERR_PTR(err);
+
+ ubi = ubi_devices[ubi_num];
+
if (!try_module_get(THIS_MODULE))
return ERR_PTR(err);
- if (ubi_num < 0 || ubi_num >= UBI_MAX_DEVICES || !ubi)
+ if (ubi_num >= UBI_MAX_DEVICES || !ubi)
goto out_put;
err = -EINVAL;
-
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] UBI: Don't use signed int as array index before testing if it is negative
Hi,
I can't find anything guaranteeing that 'ubi_num' cannot be 0 in
drivers/mtd/ubi/kapi.c::ubi_open_volume(), and in fact the code
even tests for that and errors out if so. Unfortunately the test
for ubi_num 0 happens after we've already used 'ubi_num' as
an array index - bad thing to do if it is negative.
This patch moves the test earlier in the function and then moves
the indexing using that variable after the check. A bit safer :-)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/mtd/ubi/kapi.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index 4a458e8..5130e54 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -99,16 +99,21 @@ struct ubi_volume_desc *ubi_open_volume(int ubi_num, int
vol_id, int mode)
{
int err;
struct ubi_volume_desc *desc;
- struct ubi_device *ubi = ubi_devices[ubi_num];
+ struct ubi_device *ubi;
struct ubi_volume *vol;
dbg_msg(open device %d volume %d, mode %d, ubi_num, vol_id, mode);
err = -ENODEV;
+ if (ubi_num 0)
+ return ERR_PTR(err);
+
+ ubi = ubi_devices[ubi_num];
+
if (!try_module_get(THIS_MODULE))
return ERR_PTR(err);
- if (ubi_num 0 || ubi_num = UBI_MAX_DEVICES || !ubi)
+ if (ubi_num = UBI_MAX_DEVICES || !ubi)
goto out_put;
err = -EINVAL;
-
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] au88x0: mem leak fix in snd_vortex_create()
Hi, In sound/pci/au88x0/au88x0.c::snd_vortex_create() : The Coverity checker found that if we allocate storage for 'chip' but then leave via the regions_out: label, then we end up leaking the storage allocated for 'chip'. I believe simply freeing 'chip' before the return err; line is all we need to fix this, but please double-check me :) Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/sound/pci/au88x0/au88x0.c b/sound/pci/au88x0/au88x0.c index 5ec1b6f..f70286a 100644 --- a/sound/pci/au88x0/au88x0.c +++ b/sound/pci/au88x0/au88x0.c @@ -232,6 +232,7 @@ snd_vortex_create(struct snd_card *card, struct pci_dev *pci, vortex_t ** rchip) pci_disable_device(chip-pci_dev); //FIXME: this not the right place to unregister the gameport vortex_gameport_unregister(chip); + kfree(chip); return err; } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: snd-au8830: dead after software suspend
On 04/08/07, Gert Robben [EMAIL PROTECTED] wrote: Robert Hancock wrote: Have you reported this to the ALSA people? No, I thought this might as well be something for PCI or PM people, and I expected some ALSA people are also reading this list. If not, where else should I report this exactly? alsa-devel would seem to be a good starting point - see http://www.alsa-project.org/mailing-lists.php Also, the author of the driver, Manuel Jander [EMAIL PROTECTED], would probably be a good person to add to Cc. And keeping LKML on Cc while sending to above people usually never hurts :-) -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 two potential mem leaks in MPT Fusion (mpt_attach())
On 03/08/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 3 Aug 2007 01:10:02 +0200 > "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > > > > > So, where do we go from here? > > > > > > Where I said ;) Add a new __GFP_ flag which suppresses the warning, add > > > that flag to known-to-be-OK callsites, such as mempool_alloc(). > > > > > Ok, I'll try to play around with this some more, try to filter out > > false positives and see what I'm left with (if anything - I'm pretty > > limited hardware-wise, so I can only test a small subset of drivers, > > archs etc) - I'll keep you informed, but expect a few days to pass > > before I have any news... > > Make it a once-off thing for now, so the warning will disable itself after > it has triggered once. That will prevent the debug feature from making > anyone's kernel unusable. > Ok, I'll do that :-) Just be a little patient. I'm doing this in my spare time and I do have a real job/life to attend to, so I'll be playing with this in the little free time I have over the next couple of days. I'll get something done, but don't expect it until a few days have passed :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/
