- 31 Jul, 2006 40 commits
-
-
Badari Pulavarty authored
For files other than IFREG, nobh option doesn't make sense. Modifications to them are journalled and needs buffer heads to do that. Without this patch, we get kernel oops in page_buffers(). Signed-off-by:
Badari Pulavarty <pbadari@us.ibm.com> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Josh Triplett authored
kernel/timer.c defines a (per-cpu) pointer to tvec_base_t, but initializes it using { &a_tvec_base_t }, which sparse warns about; change this to just &a_tvec_base_t. Signed-off-by:Josh Triplett <josh@freedesktop.org> Signed-off-by:
-
Josh Triplett authored
Commit 7b2fd697427e73c81d5fa659efd91bd07d303b0e in the historical GIT tree stopped calling the readdir member of a file_operations struct with the big kernel lock held, and fixed up all the readdir functions to do their own locking. However, that change added calls to unlock_kernel() in vxfs_readdir, but no call to lock_kernel(). Fix this by adding a call to lock_kernel(). Signed-off-by:
-
Thomas Horsley authored
I spent a long time the other day trying to examine an initrd image on a fedora core 5 system because the initrd.txt file is apparently obsolete. Here is a patch which I hope will reduce future confusion for others. Signed-off-by:
Thomas Horsley <tom.horsley@ccur.com> Signed-off-by:
-
Ingo Molnar authored
Clean up ipc/msg.c to conform to Documentation/CodingStyle. (before it was an inconsistent hodepodge of various coding styles) Verified that the before/after .o's are identical. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Miklos Szeredi authored
Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Miklos Szeredi authored
It is entirely possible (though rare) that jiffies half-wraps around, while a dentry/inode remains in the cache. This could mean that the dentry/inode is not invalidated for another half wraparound-time. To get around this problem, use 64-bit jiffies. The only problem with this is that dentry->d_time is 32 bits on 32-bit archs. So use d_fsdata as the high 32 bits. This is an ugly hack, but far simpler, than having to allocate private data just for this purpose. Since 64-bit jiffies can be assumed never to wrap around, simple comparison can be used, and a zero time value can represent "invalid". Signed-off-by:
-
Miklos Szeredi authored
An attribute and entry timeout of zero should mean, that the entity is invalidated immediately after the operation. Previously invalidation only happened at the next clock tick. Reported and tested by Craig Davies. Signed-off-by:
-
Markus Armbruster authored
CFA needs to be adjusted upwards for push, and downwards for pop. arch/i386/kernel/entry.S gets it wrong in one place. Signed-off-by:
Markus Armbruster <armbru@redhat.com> Acked-by:
Jan Beulich <jbeulich@novell.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
Roland McGrath authored
The latest toolchains can produce a new ELF section in DSOs and dynamically-linked executables. The new section ".gnu.hash" replaces ".hash", and allows for more efficient runtime symbol lookups by the dynamic linker. The new ld option --hash-style={sysv|gnu|both} controls whether to produce the old ".hash", the new ".gnu.hash", or both. In some new systems such as Fedora Core 6, gcc by default passes --hash-style=gnu to the linker, so that a standard invocation of "gcc -shared" results in producing a DSO with only ".gnu.hash". The new ".gnu.hash" sections need to be dealt with the same way as ".hash" sections in all respects; only the dynamic linker cares about their contents. To work with older dynamic linkers (i.e. preexisting releases of glibc), a binary must have the old ".hash" section. The --hash-style=both option produces binaries that a new dynamic linker can use more efficiently, but an old dynamic linker can still handle. The new section runs afoul of the custom linker scripts used to build vDSO images for the kernel. On ia64, the failure mode for this is a boot-time panic because the vDSO's PT_IA_64_UNWIND segment winds up ill-formed. This patch addresses the problem in two ways. First, it mentions ".gnu.hash" in all the linker scripts alongside ".hash". This produces correct vDSO images with --hash-style=sysv (or old tools), with --hash-style=gnu, or with --hash-style=both. Second, it passes the --hash-style=sysv option when building the vDSO images, so that ".gnu.hash" is not actually produced. This is the most conservative choice for compatibility with any old userland. There is some concern that some ancient glibc builds (though not any known old production system) might choke on --hash-style=both binaries. The optimizations provided by the new style of hash section do not really matter for a DSO with a tiny number of symbols, as the vDSO has. If someone wants to use =gnu or =both for their vDSO builds and worry less about that compatibility, just change the option and the linker script changes will make any choice work fine. Signed-off-by:Roland McGrath <roland@redhat.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Jeff Dike <jdike@addtoit.com> Cc: Andi Kleen <ak@muc.de> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Michael Buesch authored
The geode hwrng leaks an iomapped resource, if hwrng_register() fails. This fixes it. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Michael Buesch authored
The intel hwrng leaks an iomapped resource, if hwrng_register() failes. This fixes it. Signed-off-by:
-
Rolf Eike Beer authored
kmem_cache_alloc() was documented twice, but kmem_cache_zalloc() never. Fix this obvious typo to get things right. Signed-off-by:
Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by:
-
Steven Rostedt authored
In order to prevent Doc Rot, this patch adds a reference to the design document for rtmutex.c in rtmutex.c. So when someone needs to update or change the design of that file they will know that a document actually exists that explains the design (helping them change it), and hopefully that they will update the document if they too change the design. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Acked-by:
-
Uwe Zeisberger authored
There is currently no affected user in the tree, but usage is less surprising that way. Signed-off-by:
Uwe Zeisberger <Uwe_Zeisberger@digi.com> Signed-off-by:
-
Tim Chen authored
The recent changes from irqtrace feature has added overheads to local_bh_disable and local_bh_enable that reduces UDP performance across x86_64 and IA64, even though IA64 does not support the irqtrace feature. Patch in question is [PATCH]lockdep: irqtrace subsystem, core http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=c ommit;h=de30a2b3 Prior to this patch, local_bh_disable was a short macro. Now it is a function which calls __local_bh_disable with added irq flags save and restore. The irq flags save and restore were also added to local_bh_enable, probably for injecting the trace irqs code. This overhead is on the generic code path across all architectures. On a IA_64 test machine (Itanium-2 1.6 GHz) running a benchmark like netperf's UDP streaming test, the added overhead results in a drop of 3% in throughput, as udp_sendmsg calls the local_bh_enable/disable several times. Other workloads that have heavy usages of local_bh_enable/disable could also be affected. The patch ideally should not have affected IA-64 performance as it does not have IRQ tracing support. A significant portion of the overhead is in the added irq flags save and restore, which I think is not needed if IRQ tracing is unused. A suggested patch is attached below that recovers the lost performance. However, the "ifdef"s in the patch are a bit ugly. Signed-off-by:
Tim Chen <tim.c.chen@intel.com> Acked-by:
-
Pete Zaitcev authored
Change "Thrid" into "Third", and realign similarly to other entries. Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Cc: <device@lanana.org> Signed-off-by:
-
Josh Triplett authored
Signed-off-by:
-
Josh Triplett authored
ufs_symlink, in one of its error paths, calls unlock_kernel without ever having called lock_kernel(); fix this by creating and jumping to a new label out_notlocked rather than the out label used after calling lock_kernel(). Signed-off-by:
-
Josh Triplett authored
The EFS filesystem does not have an entry in MAINTAINERS; add one, giving the EFS filesystem and listing the status as Orphan, per the note on that page saying "I'm no longer actively maintaining EFS". Signed-off-by:
-
Josh Triplett authored
If efs_symlink_readpage hits the -ENAMETOOLONG error path, it will call unlock_kernel without ever having called lock_kernel(); fix this by creating and jumping to a new label fail_notlocked rather than the fail label used after calling lock_kernel(). Signed-off-by:
-
Josh Triplett authored
Commit 398c53a757702e1e3a7a2c24860c7ad26acb53ed (in the historical GIT tree) moved the lock_kernel() in coda_open after the allocation of a coda_file_info struct, but left an unlock_kernel() in the allocation failure error path; remove it. Signed-off-by:
Jan Harkes <jaharkes@cs.cmu.edu> Signed-off-by:
-
Ondrej Zary authored
swsusp is unable to suspend my machine (DTK FortisPro TOP-5A notebook) with kernel 2.6.17.5 because it's unable to suspend PNP device 00:16 (mouse). The problem is in PNP BIOS. pnp_bus_suspend() calls pnp_stop_dev() for the device if the device can be disabled according to pnp_can_disable(). The problem is that pnpbios_disable_resources() returns -EPERM if the device is not dynamic (!pnpbios_is_dynamic()) but insert_device() happily sets PNP_DISABLE capability/flag even if the device is not dynamic. So we try to disable non-dynamic devices which will fail. This patch prevents insert_device() from setting PNP_DISABLE if the device is not dynamic and fixes suspend on my system. Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
Arjan van de Ven authored
This is a real deadlock, a nice complex one: (warning: long explanation follows so that Andrew can have a complete patch description) it's an ABCDA deadlock: A iprune_mutex B inode->inotify_mutex C ih->mutex D dev->ev_mutex The AB relationship comes straight from invalidate_inodes() int invalidate_inodes(struct super_block * sb) { int busy; LIST_HEAD(throw_away); mutex_lock(&iprune_mutex); spin_lock(&inode_lock); inotify_unmount_inodes(&sb->s_inodes); where inotify_umount_inodes() takes the mutex_lock(&inode->inotify_mutex); The BC relationship comes directly from inotify_find_update_watch(): s32 inotify_find_update_watch(struct inotify_handle *ih, struct inode *inode, u32 mask) { ... mutex_lock(&inode->inotify_mutex); mutex_lock(&ih->mutex); The CD relationship comes from inotify_rm_wd: inotify_rm_wd does mutex_lock(&inode->inotify_mutex); mutex_lock(&ih->mutex) and then calls inotify_remove_watch_locked() which calls notify_dev_queue_event() which does mutex_lock(&dev->ev_mutex); (this strictly is a BCD relationship) The DA relationship comes from the most interesting part: [<ffffffff8022d9f2>] shrink_icache_memory+0x42/0x270 [<ffffffff80240dc4>] shrink_slab+0x11d/0x1c9 [<ffffffff802b5104>] try_to_free_pages+0x187/0x244 [<ffffffff8020efed>] __alloc_pages+0x1cd/0x2e0 [<ffffffff8025e1f8>] cache_alloc_refill+0x3f8/0x821 [<ffffffff8020a5e5>] kmem_cache_alloc+0x85/0xcb [<ffffffff802db027>] kernel_event+0x2e/0x122 [<ffffffff8021d61c>] inotify_dev_queue_event+0xcc/0x140 inotify_dev_queue_event schedules a kernel_event which does a kmem_cache_alloc( , GFP_KERNEL) which may try to shrink slabs, including the inode cache .. which then takes iprune_mutex. And voila, there is an AB, a BC, a CD relationship (even a direct BCD), and also now a DA relationship -> a circular type AB-BA deadlock but involving 4 locks. The solution is simple: kernel_event() is NOT allowed to use GFP_KERNEL, but must use GFP_NOFS to not cause recursion into the VFS. Signed-off-by:Arjan van de Ven <arjan@linux.intel.com> Acked-by:
Robert Love <rml@novell.com> Signed-off-by:
-
Steven Rostedt authored
Since I didn't know about the linux-mm mailing list until I spammed all those that had their names anywhere in the mm directory, I'm sending this patch to add the linux-mm mailing list to the MAINTAINERS file. Also, since mm is so broad, it doesn't have a single person to maintain it, and thus no maintainer is listed. I also left the status as Maintained, since it obviously is. Signed-off-by:
-
Heiko Carstens authored
Initialize init task's pi_waiters plist. Otherwise cpu hotplug of cpu 0 might crash, since rt_mutex_getprio() accesses an uninitialized list head. call chain which led to crash: take_cpu_down sched_idle_next __setscheduler rt_mutex_getprio Using PLIST_HEAD_INIT in the INIT_TASK macro doesn't work unfortunately, since the pi_waiters member is only conditionally present. Cc: Arjan van de Ven <arjan@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Olaf Hering authored
Hide the video drivers for onboard graphics found in early PCI PowerMacs in Apple G5 config files. drivers/built-in.o: In function `.platinumfb_probe': platinumfb.c:(.text+0x377a0): undefined reference to `.nvram_read_byte' platinumfb.c:(.text+0x37830): undefined reference to `.nvram_read_byte' drivers/built-in.o: In function `.control_init': controlfb.c:(.init.text+0x1938): undefined reference to `.nvram_read_byte' controlfb.c:(.init.text+0x1968): undefined reference to `.nvram_read_byte' drivers/built-in.o: In function `.valkyriefb_init': (.init.text+0x2300): undefined reference to `.nvram_read_byte' drivers/built-in.o:(.init.text+0x239c): more undefined references to `.nvram_read_byte' follow Signed-off-by:
Olaf Hering <olh@suse.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Olaf Hering authored
Enable mac partition table support per default also for a powermac config. Signed-off-by:
-
Daniel Ritz authored
Values displayed when by cardctl config are horribly wrong for 16bit cards. this fixes it up by not using memcpy() since source and target struct are very different. Signed-off-by:
Daniel Ritz <daniel.ritz@gmx.ch> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Daniel Ritz authored
the p_dev == NULL checks are wrong. the called functions handle a NULL p_dev on their own. w/o this patch output of cardcctl status and cardctl config is broken for cardbus cards or when the slot is empty. Signed-off-by:
-
Frederik Deweerdt authored
WARNING: drivers/video/console/mdacon.o - Section mismatch: reference to .init.text: from .text between 'mdacon_startup' (at offset 0x123) and 'mdacon_init' WARNING: drivers/video/console/mdacon.o - Section mismatch: reference to .init.text: from .text between 'mdacon_startup' (at offset 0x18b) and 'mdacon_init' Signed-off-by:
-
Brent Casavant authored
The SGI IOC4 IDE device always shares an interrupt with other devices which are part of IOC4. As such, IDEPCI_SHARE_IRQ should always be enabled when BLK_DEV_SGIIOC4 is enabled. Signed-off-by:
Brent Casavant <bcasavan@sgi.com> Signed-off-by:
-
Randy Dunlap authored
A few cleanups to SubmittingPatches: - mention SubmitChecklist - remove mention of my simple patch script tools - remove last-updated line Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Rolf Eike Beer authored
kernel/workqueue.c was omitted from generating kernel documentation. This adds a new section "Workqueues and Kevents" and adds documentation for some of the functions. Some functions in this file already had DocBook-style comments, now they finally become visible. Signed-off-by:
-
Randy Dunlap authored
Clean up kernel-doc comments in drivers/pci/search.c (line sizes and typos). Enable that source file in DocBook/kernel-api.tmpl. Signed-off-by:
-
Randy Dunlap authored
Ignore __devinit in function definitions so that kernel-doc won't fail on them. Signed-off-by:
-
Randy Dunlap authored
insert_resource() was unexported, so kernel-doc needs to be told to search kernel/resource.c for internal functions instead of exported functions so that it won't report an error. Signed-off-by:
-
Jim Houston authored
In cond_resched_lock() it calls __resched_legal() before dropping the spin lock. __resched_legal() will always finds the preempt_count non-zero and will prevent the call to __cond_resched(). The attached patch adds a parameter to __resched_legal() with the expected preempt_count value. Cc: Ingo Molnar <mingo@elte.hu> Cc: <stable@kernel.org> Signed-off-by:
-
Steven Rostedt authored
We have #define INDEX(N) (base->timer_jiffies >> (TVR_BITS + N * TVN_BITS)) & TVN_MASK and it's used via list = varray[i + 1]->vec + (INDEX(i + 1)); So, due to underparenthesisation, this INDEX(i+1) is now a ... (TVR_BITS + i + 1 * TVN_BITS)) ... So this bugfix changes behaviour. It worked before by sheer luck: "If i was anything but 0, it was broken. But this was only used by s390 and arm. Since it was for the next interrupt, could that next interrupt be a problem (going into the second cascade)? But it was probably seldom wrong. That is, this would fail if the next interrupt was in the second cascade, and was wrapped. Which may never of happened. Also if it did happen, it would have just missed the interrupt. If an interrupt was missed, and no one was there to miss it, was it really missed :-)" Signed-off-by:
-
Chandra Seetharaman authored
Use hotplug version of register_cpu_notifier in late init functions. Signed-off-by:
Chandra Seetharaman <sekharan@us.ibm.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
