- 29 Apr, 2008 39 commits
-
-
Adrian Bunk authored
cont_expand_zero() can become static. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Adrian Bunk authored
Remove the obsolete and no longer used generic_commit_write(). Signed-off-by:
-
Adrian Bunk authored
Every file should include the headers containing the prototypes for its global functions (in this case for sys_timerfd_*()). Signed-off-by:
-
Adrian Bunk authored
16 kB is often no longer enough for a normal boot of an UP system. And even less when people e.g. use suspend. 17 seems to be a more reasonable default for current kernels on current hardware (it's just the default, anyone who is memory limited can still lower it). Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Adrian Bunk authored
Make the following needlessly global functions static: - __put_ioctx() - lookup_ioctx() - io_submit_one() Signed-off-by:
-
Adrian Bunk authored
Make the following needlessly global functions static: - drop_pagecache() - drop_slab() Signed-off-by:
-
Adrian Bunk authored
Make the following needlessly global functions static: - writeback_acquire() - writeback_release() Signed-off-by:
-
Adrian Bunk authored
Make the needlessly global vfs_ioctl() static. Signed-off-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Adrian Bunk authored
Make the needlessly global __put_super() static. Signed-off-by:
-
Adrian Bunk authored
Move the extern declarations of several structs to vxfs_extern.h Signed-off-by:
-
Adrian Bunk authored
Add proper extern declarations for two structs in fs/hfsplus/hfsplus_fs.h Signed-off-by:
-
Adrian Bunk authored
- internal.h shouldn't duplicate the extern declaration for ramfs_file_operations already in include/linux/ramfs.h - file-mmu.c needs two #include's for seeing the extern declarations of it's global struct's Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: WARNING: vmlinux.o(.text+0xc60): Section mismatch in reference from the function kvm_init() to the function .cpuinit.text:register_cpu_notifier() WARNING: vmlinux.o(.text+0x33869a): Section mismatch in reference from the function xfs_icsb_init_counters() to the function .cpuinit.text:register_cpu_notifier() WARNING: vmlinux.o(.text+0x5556a1): Section mismatch in reference from the function acpi_processor_install_hotplug_notify() to the function .cpuinit.text:register_cpu_notifier() WARNING: vmlinux.o(.text+0xfe6b28): Section mismatch in reference from the function cpufreq_register_driver() to the function .cpuinit.text:register_cpu_notifier() register_cpu_notifier() are only really defined when HOTPLUG_CPU is enabled. So references to the function are OK. Annotate it with __ref so we do not get warnings from callers and do not get warnings for the functions/data used by register_cpu_notifier(). Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Gautham R Shenoy <ego@in.ibm.com> Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: WARNING: vmlinux.o(.text+0x75c8d): Section mismatch in reference from the function take_cpu_down() to the variable .cpuinit.data:cpu_chain WARNING: vmlinux.o(.text+0x75d2a): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain WARNING: vmlinux.o(.text+0x75d4d): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain WARNING: vmlinux.o(.text+0x75de4): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain WARNING: vmlinux.o(.text+0x75e33): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain cpu_down is only used from code surrounded by HOTPLUG_CPU so any references to __cpuinit is OK. Add a few __ref to tech modpost to ignore the references. This is just papering over the fact that the cpu hotplug code is fragile with respect to use of HOTPLUG_CPU and in many cases rely on __cpuinit to get rid of code when HOTPLUG_CPU is not enabled. For now this is the least invasive change. Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: WARNING: vmlinux.o(.text+0x75f4e): Section mismatch in reference from the function unregister_cpu_notifier() to the variable .cpuinit.data:cpu_chain We know that unregister_cpu_notifier is using HOTPLUG_CPU stuff - so ignore these references. Annotating unregister_cpu_notifier had been another option but this caused far more warnings since not all callers were annotated __cpuinit. Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: WARNING: vmlinux.o(.data+0x5020): Section mismatch in reference from the variable cpu_vsyscall_notifier_nb.12876 to the function .cpuinit.text:cpu_vsyscall_notifier() WARNING: vmlinux.o(.data+0x9ce0): Section mismatch in reference from the variable profile_cpu_callback_nb.17654 to the function .devinit.text:profile_cpu_callback() WARNING: vmlinux.o(.data+0xd380): Section mismatch in reference from the variable workqueue_cpu_callback_nb.15004 to the function .devinit.text:workqueue_cpu_callback() WARNING: vmlinux.o(.data+0x11d00): Section mismatch in reference from the variable relay_hotcpu_callback_nb.19626 to the function .cpuinit.text:relay_hotcpu_callback() WARNING: vmlinux.o(.data+0x12970): Section mismatch in reference from the variable cpu_callback_nb.24694 to the function .devinit.text:cpu_callback() WARNING: vmlinux.o(.data+0x3fee0): Section mismatch in reference from the variable percpu_counter_hotcpu_callback_nb.10903 to the function .cpuinit.text:percpu_counter_hotcpu_callback() WARNING: vmlinux.o(.data+0x74ce0): Section mismatch in reference from the variable topology_cpu_callback_nb.12506 to the function .cpuinit.text:topology_cpu_callback() Functions used as argument are by definition only used in HOTPLUG_CPU situations so thay are annotated __cpuinit. Annotate the static variable used by hotcpu_register with __cpuinitdata to match this definition. Signed-off-by:
-
Harvey Harrison authored
Use link as the variable name to avoid shadowing the arg. fs/befs/linuxvfs.c:492:8: warning: symbol 'p' shadows an earlier one fs/befs/linuxvfs.c:488:77: originally declared here Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Cc: "Sergey S. Kostyliov" <rathamahata@php4.ru> Signed-off-by:
-
Harvey Harrison authored
coda_unlink, coda_rmdir, coda_readdir can all be static, the forward declarations already were. Signed-off-by:
-
Sripathi Kodi authored
Add the RUSAGE_THREAD option for the getrusage system call. This is essentially Roland's patch from http://lkml.org/lkml/2008/1/18/589, but the line about RUSAGE_LWP line has been removed, as suggested by Ulrich and Christoph. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Sripathi Kodi <sripathik@in.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Michael Kerrisk <mtk.manpages@googlemail.com> Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by:
-
Harvey Harrison authored
fs/adfs/dir_f.c:126:4: warning: do-while statement is not a compound statement Signed-off-by:
-
Nur Hussein authored
The kernel is sent to tainted within the warn_on_slowpath() function, and whenever a warning occurs the new taint flag 'W' is set. This is useful to know if a warning occurred before a BUG by preserving the warning as a flag in the taint state. This does not work on architectures where WARN_ON has its own definition. These archs are: 1. s390 2. superh 3. avr32 4. parisc The maintainers of these architectures have been added in the Cc: list in this email to alert them to the situation. The documentation in oops-tracing.txt has been updated to include the new flag. Signed-off-by:
Nur Hussein <nurhussein@gmail.com> Cc: Arjan van de Ven <arjan@infradead.org> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Ilpo Järvinen authored
They're defined later on in the same file with bodies and nothing in between needs them. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Reviewed-by:
Pekka Enberg <penberg@cs.helsinki.fi> Acked-by:
Jan Harkes <jaharkes@cs.cmu.edu> Signed-off-by:
-
Eric Dumazet authored
BITS_PER_LONG is a signed value (32 or 64) DIV_ROUND_UP(nr, BITS_PER_LONG) performs signed arithmetic if "nr" is signed too. Converting BITS_TO_LONGS(nr) to DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) makes sure compiler can perform a right shift, even if "nr" is a signed value, instead of an expensive integer divide. Applying this patch saves 141 bytes on x86 when CONFIG_CC_OPTIMIZE_FOR_SIZE=y and speedup bitmap operations. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
Davide Libenzi authored
Epoll calls rb_set_parent(n, n) to initialize the rb-tree node, but rb_set_parent() accesses node's pointer in its code. This creates a warning in kmemcheck (reported by Vegard Nossum) about an uninitialized memory access. The warning is harmless since the following rb-tree node insert is going to overwrite the node data. In any case I think it's better to not have that happening at all, and fix it by simplifying the code to get rid of a few lines that became superfluous after the previous epoll changes. Signed-off-by:
Davide Libenzi <davidel@xmailserver.org> Cc: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by:
-
Arjan van de Ven authored
Make /dev/kmem a config option; /dev/kmem is VERY rarely used, and when used, it's generally for no good (rootkits tend to be the most common users). With this config option, users have the choice to disable /dev/kmem, saving some size as well. A patch to disable /dev/kmem has been in the Fedora and RHEL kernels for 4+ years now without any known problems or legit users of /dev/kmem. [akpm@linux-foundation.org: make CONFIG_DEVKMEM default to y] Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Nishanth Aravamudan authored
Add __GFP_REPEAT to hugepage allocations. Do so to not necessitate userspace putting pressure on the VM by repeated echo's into /proc/sys/vm/nr_hugepages to grow the pool. With the previous patch to allow for large-order __GFP_REPEAT attempts to loop for a bit (as opposed to indefinitely), this increases the likelihood of getting hugepages when the system experiences (or recently experienced) load. Mel tested the patchset on an x86_32 laptop. With the patches, it was easier to use the proc interface to grow the hugepage pool. The following is the output of a script that grows the pool as much as possible running on 2.6.25-rc9. Allocating hugepages test ------------------------- Disabling OOM Killer for current test process Starting page count: 0 Attempt 1: 57 pages Progress made with 57 pages Attempt 2: 73 pages Progress made with 16 pages Attempt 3: 74 pages Progress made with 1 pages Attempt 4: 75 pages Progress made with 1 pages Attempt 5: 77 pages Progress made with 2 pages 77 pages was the most it allocated but it took 5 attempts from userspace to get it. With the 3 patches in this series applied, Allocating hugepages test ------------------------- Disabling OOM Killer for current test process Starting page count: 0 Attempt 1: 75 pages Progress made with 75 pages Attempt 2: 76 pages Progress made with 1 pages Attempt 3: 79 pages Progress made with 3 pages And 79 pages was the most it got. Your patches were able to allocate the bulk of possible pages on the first attempt. Signed-off-by:
Nishanth Aravamudan <nacc@us.ibm.com> Cc: Andy Whitcroft <apw@shadowen.org> Tested-by:
Mel Gorman <mel@csn.ul.ie> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Nishanth Aravamudan authored
Because of page order checks in __alloc_pages(), hugepage (and similarly large order) allocations will not retry unless explicitly marked __GFP_REPEAT. However, the current retry logic is nearly an infinite loop (or until reclaim does no progress whatsoever). For these costly allocations, that seems like overkill and could potentially never terminate. Mel observed that allowing current __GFP_REPEAT semantics for hugepage allocations essentially killed the system. I believe this is because we may continue to reclaim small orders of pages all over, but never have enough to satisfy the hugepage allocation request. This is clearly only a problem for large order allocations, of which hugepages are the most obvious (to me). Modify try_to_free_pages() to indicate how many pages were reclaimed. Use that information in __alloc_pages() to eventually fail a large __GFP_REPEAT allocation when we've reclaimed an order of pages equal to or greater than the allocation's order. This relies on lumpy reclaim functioning as advertised. Due to fragmentation, lumpy reclaim may not be able to free up the order needed in one invocation, so multiple iterations may be requred. In other words, the more fragmented memory is, the more retry attempts __GFP_REPEAT will make (particularly for higher order allocations). This changes the semantics of __GFP_REPEAT subtly, but *only* for allocations > PAGE_ALLOC_COSTLY_ORDER. With this patch, for those size allocations, we will try up to some point (at least 1<<order reclaimed pages), rather than forever (which is the case for allocations <= PAGE_ALLOC_COSTLY_ORDER). This change improves the /proc/sys/vm/nr_hugepages interface with a follow-on patch that makes pool allocations use __GFP_REPEAT. Rather than administrators repeatedly echo'ing a particular value into the sysctl, and forcing reclaim into action manually, this change allows for the sysctl to attempt a reasonable effort itself. Similarly, dynamic pool growth should be more successful under load, as lumpy reclaim can try to free up pages, rather than failing right away. Choosing to reclaim only up to the order of the requested allocation strikes a balance between not failing hugepage allocations and returning to the caller when it's unlikely to every succeed. Because of lumpy reclaim, if we have freed the order requested, hopefully it has been in big chunks and those chunks will allow our allocation to succeed. If that isn't the case after freeing up the current order, I don't think it is likely to succeed in the future, although it is possible given a particular fragmentation pattern. Signed-off-by:
-
Nishanth Aravamudan authored
The definition and use of __GFP_REPEAT, __GFP_NOFAIL and __GFP_NORETRY in the core VM have somewhat differing comments as to their actual semantics. Annoyingly, the flags definition has inline and header comments, which might be interpreted as not being equivalent. Just add references to the header comments in the inline ones so they don't go out of sync in the future. In their use in __alloc_pages() clarify that the current implementation treats low-order allocations and __GFP_REPEAT allocations as distinct cases. To clarify, the flags' semantics are: __GFP_NORETRY means try no harder than one run through __alloc_pages __GFP_REPEAT means __GFP_NOFAIL __GFP_NOFAIL means repeat forever order <= PAGE_ALLOC_COSTLY_ORDER means __GFP_NOFAIL Signed-off-by:
-
KAMEZAWA Hiroyuki authored
usemap must be initialized only when pfn is within zone. If not, it corrupts memory. And this patch also reduces the number of calls to set_pageblock_migratetype() from (pfn & (pageblock_nr_pages -1) to !(pfn & (pageblock_nr_pages-1) it should be called once per pageblock. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
drivers/media/video/v4l2-common.c:719:16: warning: Using plain integer as NULL pointer drivers/media/video/au0828/au0828-dvb.c:122:19: warning: Using plain integer as NULL pointer drivers/media/video/ivtv/ivtv-yuv.c:1101:22: warning: Using plain integer as NULL pointer drivers/media/video/ivtv/ivtv-yuv.c:1102:23: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-audio.c:78:39: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-video-v4l.c:84:39: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-v4l2.c:1264:9: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-context.c:197:28: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c:126:39: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-dvb.c:133:32: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-dvb.c:145:31: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-dvb.c:177:55: warning: Using plain integer as NULL pointer drivers/media/video/videobuf-core.c:100:9: warning: Using plain integer as NULL pointer Signed-off-by:
-
Harvey Harrison authored
drivers/scsi/aic7xxx/aic7770_osm.c:53:58: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:355:47: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:372:55: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:997:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1003:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1165:46: warning: Using plain integer as NULL pointer drivers/scsi/fdomain.c:1446:40: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:1650:51: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:3171:42: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:5732:52: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8189:31: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8225:34: warning: Using plain integer as NULL pointer drivers/scsi/dpt_i2o.c:156:32: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:954:42: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:1104:18: warning: Using plain integer as NULL pointer Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: (35 commits) siimage: coding style cleanup (take 2) ide-cd: clean up cdrom_analyze_sense_data() ide-cd: fix test unsigned var < 0 ide: add TSSTcorp CDDVDW SH-S202H to ivb_list[] piix: add Asus Eee 701 controller to short cable list ARM: always select HAVE_IDE remove the broken ETRAX_IDE driver ide: remove ->dma_prdtable field from ide_hwif_t ide: remove ->dma_vendor{1,3} fields from ide_hwif_t scc_pata: add ->dma_host_set and ->dma_start methods ide: skip "VLB sync" if host uses MMIO ide: add ide_pad_transfer() helper ide: remove ->INW and ->OUTW methods ide: use IDE I/O helpers directly in ide_tf_{load,read}() ns87415: add ->tf_read method scc_pata: add ->tf_{load,read} methods ide-h8300: add ->tf_{load,read} methods ide-cris: add ->tf_{load,read} methods ide: add ->tf_load and ->tf_read methods ide: move ide_tf_{load,read} to ide-iops.c ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuildLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild: kconfig: add named choice group kconfig: fix choice dependency check kconifg: 'select' considered less evil dontdiff: ignore timeconst.h dontdiff: add modules.order kbuild: fix unportability in gen_initramfs_list.sh kbuild: fix help output to show correct arch kbuild: show defconfig subdirs in make help kconfig: reversed borderlines in inputbox
-
Harvey Harrison authored
drivers/atm/nicstar.c:418:25: warning: Using plain integer as NULL pointer drivers/char/drm/r128_cce.c:820:25: warning: Using plain integer as NULL pointer drivers/char/tty_io.c:1183:10: warning: Using plain integer as NULL pointer Signed-off-by:
-
Harvey Harrison authored
mm/hugetlb.c:207:11: warning: Using plain integer as NULL pointer Signed-off-by:
-
Harvey Harrison authored
kernel/cpuset.c:1268:52: warning: Using plain integer as NULL pointer kernel/pid_namespace.c:95:24: warning: Using plain integer as NULL pointer Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Harvey Harrison authored
init/do_mounts_rd.c:215:13: warning: Using plain integer as NULL pointer init/do_mounts_md.c:136:45: warning: Using plain integer as NULL pointer Signed-off-by:
-
- 28 Apr, 2008 1 commit
-
-
Sergei Shtylyov authored
Fix 18 errors and several warnings given by checkpatch.pl: - use of C99 // comments; - trailing whitespace; - 'switch' and 'case' not at the same indentation level; - no space before the open parenthesis of the 'if' and 'switch' statements; - space between function name and open parenthesis (though I have introduced such warnins in some places since the code looks prettier with the spaces); - including <asm/io.h> instead of <linux/io.h>; - line over 80 characters. In addition to these changes, also do the following: - make the arrays in sil_set_pio_mode() 'static', and make the arrays in sil_set_dma_mode() 'static const'; - change the string of the 'if' statements into the 'switch' statement in sil_pata_udma_filter(); - drop the needless '==' operators from the 'if' statements where a condition is a mere bit test; - remove needless initializer for the 'tmp' variable in init_chipset_siimage(); - beautify groups of the variable initializers and assignment operators; - add new line after variable definitions; - remove new line between the comment and the statements it refers to; - remove needless curly braces and parentheses; - fix typos, capitalize acronyms, etc. in the comments... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
