- Oct 17, 2006
-
-
Neil Brown authored
The use of blocking notifier by _cpu_up and _cpu_down in cpu.c has two problem. 1/ An interaction with the workqueue notifier causes lockdep to spit a warning. 2/ A notifier could conceivable be added or removed while _cpu_up or _cpu_down are in process. As each notifier is called twice (prepare then commit/abort) this could be unhealthy. To fix to we simply take cpu_add_remove_lock while adding or removing notifiers to/from the list. This makes the 'blocking' usage unnecessary as all accesses to cpu_chain are now protected by cpu_add_remove_lock. So change "blocking" to "raw" in all relevant places. This fixes 1. Credit: Andrew Morton Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> (reporter) Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Peter Zijlstra authored
BUG: warning at kernel/rtmutex-debug.c:125/rt_mutex_debug_task_free() (Not tainted) [<c04051e3>] show_trace_log_lvl+0x58/0x16a [<c04057f0>] show_trace+0xd/0x10 [<c0405900>] dump_stack+0x19/0x1b [<c043f03d>] rt_mutex_debug_task_free+0x35/0x6a [<c04224c0>] free_task+0x15/0x24 [<c042378c>] copy_process+0x12bd/0x1324 [<c0423835>] do_fork+0x42/0x113 [<c04021dd>] sys_fork+0x19/0x1b [<c0403fb7>] syscall_call+0x7/0xb In copy_process(), dup_task_struct() also duplicates the ->pi_lock, ->pi_waiters and ->pi_blocked_on members. rt_mutex_debug_task_free() called from free_task() validates these members. However free_task() can be invoked before these members are reset for the new task. Move the initialization code before the first bail that can hit free_task(). Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Aneesh Kumar K.V authored
Add functions defined using ENTRY macro to the tags file. Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Greg Banks authored
Some people want to do crazy things like pass multiple directories as the value of $(SUBDIRS) or $M. Mostly this kinda works, except that Makefile.modpost constructs a modpost commandline which fails modpost's argument parsing. This patch fixes that little wrinkle. Signed-off-by:
Greg Banks <gnb@melbourne.sgi.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Akinobu Mita authored
Make epca fail on initialization failure instead of panic. Cc: "Digi International, Inc" <Eng.Linux@digi.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Alan Cox <alan@redhat.com> Acked-by:
Scott Kilau <scottk@digi.com> Signed-off-by:
-
Akinobu Mita authored
If RAM disk driver initialization fails due to blk_alloc_queue() faulure, the gendisk structs stored in rd_disks[] will not be freed completely. This patch resolves that memory leak case by doing alloc_disk() and blk_alloc_queue() at the same time. Signed-off-by:
-
Peter Zijlstra authored
Lockdep doesn't like to enable interrupts when they are enabled already. BUG: warning at kernel/lockdep.c:1814/trace_hardirqs_on() (Not tainted) [<c04051ed>] show_trace_log_lvl+0x58/0x16a [<c04057fa>] show_trace+0xd/0x10 [<c0405913>] dump_stack+0x19/0x1b [<c043abfb>] trace_hardirqs_on+0xa2/0x11e [<c041463c>] apm_bios_call_simple+0xcd/0xfd [<c0415242>] apm+0x92/0x5b1 [<c0402005>] kernel_thread_helper+0x5/0xb DWARF2 unwinder stuck at kernel_thread_helper+0x5/0xb Leftover inexact backtrace: [<c04057fa>] show_trace+0xd/0x10 [<c0405913>] dump_stack+0x19/0x1b [<c043abfb>] trace_hardirqs_on+0xa2/0x11e [<c041463c>] apm_bios_call_simple+0xcd/0xfd [<c0415242>] apm+0x92/0x5b1 [<c0402005>] kernel_thread_helper+0x5/0xb Signed-off-by:
-
Jeff Garzik authored
With 64-bit resources on 32-bit platforms, the resource address might be larger than a void*. Fix printk to work regardless of resource size. Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Jeff Garzik authored
Handle errors thrown in disk_sysfs_symlinks(), and propagate back to caller. The callers and associated functions don't do a real good job of handling kobject errors anyway (add_partition, register_disk, rescan_partitions), so this should do until something better comes along. Signed-off-by:
-
Jeff Garzik authored
Signed-off-by:
-
Jeff Garzik authored
Signed-off-by:
-
Jan Kara authored
When IO error happens on metadata buffer, buffer is freed from memory and later fsync() is called, filesystems like ext2 fail to report EIO. We solve the problem by introducing a pointer to associated address space into the buffer_head. When a buffer is removed from a list of metadata buffers associated with an address space, IO error is transferred from the buffer to the address space, so that fsync can later report it. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
NeilBrown authored
It is possible for the ->fopen callback from lockd into nfsd to find that an answer cannot be given straight away (an upcall is needed) and so the request has to be 'dropped', to be retried later. That error status is not currently propagated back. So: Change nlm_fopen to return nlm error codes (rather than a private protocol) and define a new nlm_drop_reply code. Cause nlm_drop_reply to cause the rpc request to get rpc_drop_reply when this error comes back. Cause svc_process to drop a request which returns a status of rpc_drop_reply. [akpm@osdl.org: fix warning storm] Cc: Marc Eshel <eshel@almaden.ibm.com> Signed-off-by:
-
NeilBrown authored
When an nfs server shuts down, lockd needs to release all the locks even though the client still holds them. It should therefore not 'unmonitor' the clients, so that the files in nfs/sm will still be there when the nfs server restarts, so that those clients will be told to reclaim their locks. However the hosts are fully unmonitored, so statd may well remove the files. lockd has a test for 'sm_sticky' and avoid the unmonitor call if it is set, but it is currently not set. So set it when tearing down lockd. Signed-off-by:
-
J. Bruce Fields authored
Coverity noticed that the error handling code in the NFSv4 callback client sets cb->cb_client to NULL, then calls rpc_shutdown_client with the NULL pointer. Coverity: #cid 1397 Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
J. Bruce Fields authored
We weren't actually checking for SHARE_ACCESS_WRITE, with the result that the owner could open a non-writeable file for write! Continue to allow DENY_WRITE only with write access. Thanks to Jim Rees for reporting the bug. Signed-off-by:
-
J. Bruce Fields authored
If a client creates a file using an open which sets the mode to 000, or if a chmod changes permissions after a file is opened, then situations may arise where an NFS client knows that some IO is permitted (because a process holds the file open), but the NFS server does not (because it doesn't know about the open, and only sees that the IO conflicts with the current mode of the file). As a hack to solve this problem, NFS servers normally allow the owner to override permissions on IO. The client can still enforce correct permissions-checking on open by performing an explicit access check. In NFSv4 the client can rely on the explicit on-the-wire open instead of an access check. Therefore we should not be allowing the owner to override permissions on an over-the-wire open! However, we should still allow the owner to override permissions in the case where the client is claiming an open that it already made either before a reboot, or while it was holding a delegation. Thanks to Jim Rees for reporting the bug. Signed-off-by:
-
Miklos Szeredi authored
There's no locking for ->d_revalidate, so fuse_dentry_revalidate() should use dget_parent() instead of simply dereferencing ->d_parent. Due to topology changes in the directory tree the parent could become negative or be destroyed while being used. There hasn't been any reports about this yet. Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Miklos Szeredi authored
Fuse considered it an error (EIO) if lookup returned a directory inode, to which a dentry already refered. This is because directory aliases are not allowed. But in a network filesystem this could happen legitimately, if a directory is moved on a remote client. This patch attempts to relax the restriction by trying to first evict the offending alias from the cache. If this fails, it still returns an error (EBUSY). A rarer situation is if an mkdir races with an indenpendent lookup, which finds the newly created directory already moved. In this situation the mkdir should return success, but that would be incorrect, since the dentry cannot be instantiated, so return EBUSY. Previously checking for a directory alias and instantiation of the dentry weren't done atomically in lookup/mkdir, hence two such calls racing with each other could create aliased directories. To prevent this introduce a new per-connection mutex: fuse_conn->inst_mutex, which is taken for instantiations with a directory inode. Signed-off-by:
-
Miklos Szeredi authored
Fix a spurious BUG in an unlikely race, where at least three parallel lookups return the same inode, but with different file type. This has not yet been observed in real life. Allowing unlimited retries could delay fuse_iget() indefinitely, but this is really for the broken userspace filesystem to worry about. Signed-off-by:
-
Miklos Szeredi authored
An inode could be returned by independent parallel lookups, in this case an update of the lookup counter could be lost resulting in a memory leak in userspace. Signed-off-by:
-
Miklos Szeredi authored
Unless someone reads the documentation for write_seqcount_{begin,end} it is not obvious, that i_size_write() needs locking. Especially, that lack of such locking can result in a system hang. Signed-off-by: -
Miklos Szeredi authored
Fuse didn't always call i_size_write() with i_mutex held which caused rare hangs on SMP/32bit. This bug has been present since fuse-2.2, well before being merged into mainline. The simplest solution is to protect i_size_write() with the per-connection spinlock. Using i_mutex for this purpose would require some restructuring of the code and I'm not even sure it's always safe to acquire i_mutex in all places i_size needs to be set. Since most of vmtruncate is already duplicated for other reasons, duplicate the remaining part as well, making all i_size_write() calls internal to fuse. Using i_size_write() was unnecessary in fuse_init_inode(), since this function is only called on a newly created locked inode. Reported by a few people over the years, but special thanks to Dana Henriksen who was persistent enough in helping me debug it. Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by:
-
Ingo Molnar authored
Introduce desc->name and eliminate the handle_irq_name() hack. Add set_irq_chip_and_handler_name() to set the flow type and name at once. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Matthew Wilcox <willy@debian.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by:
-
David Woodhouse authored
Fix this: make[3]: *** No rule to make target `/mnt/md0/devel/linux-git/include/linux/version.h', needed by `/mnt/md0/devel/linux-git-obj/usr/include/linux/version.h'. Stop. make[2]: *** [linux] Error 2 make[1]: *** [headers_install] Error 2 Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Adrian Bunk authored
Correct the following bugs introduced by commit 67cc0161 : - remove one remaining and now incorrect baud_table[] usage - "baud +=" is no longer correct The former bug was spotted by the Coverity checker. Rolf Eike Beer spotted a bug in the initial version of my patch. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Andrew Morton authored
My fancy new swsusp IO code had a big memory leak. It's somewhat invisible because the whole mem_map[] gets overwritten after resume, but it can cause us to get low on memory during the actual suspend process. Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Andrew Morton authored
drivers/acpi/processor_idle.c:1112: warning: 'smp_callback' defined but not used Cc: Len Brown <lenb@kernel.org> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by:
-
Andrew Morton authored
A recent change to the vmalloc() code accidentally resulted in us passing __GFP_ZERO into the slab allocator. But we only wanted __GFP_ZERO for the actual pages whcih are being vmalloc()ed, and passing __GFP_ZERO into slab is not a rational thing to ask for. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Francisco Larramendi authored
Fix October-only BCD-to-binary conversion bug: 0x08 -> 7 0x09 -> 8 0x10 -> 15 (!) 0x11 -> 19 Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7361 Cc: Raphael Assenat <raph@raphnet.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@kernel.org> Signed-off-by:
-
Evgeniy Polyakov authored
Remove dependency of w1 subsytem from connector, only w1_con must depend on it. With attached patch applied to vanilla 2.6.19-git things works fine. Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: <dmb@pochta.ru> Cc: Greg KH <greg@kroah.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Cc: Adrian Bunk <bunk@stusta.de> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
David M. Grimes authored
We need to encode a decode the 'file' part of a handle. We simply use the inode number and generation number to construct the filehandle. The generation number is the time when the file was created. As inode numbers cycle through the full 32 bits before being reused, there is no real chance of the same inum being allocated to different files in the same second so this is suitably unique. Using time-of-day rather than e.g. jiffies makes it less likely that the same filehandle can be created after a reboot. In order to be able to decode a filehandle we need to be able to lookup by inum, which means that the inode needs to be added to the inode hash table (tmpfs doesn't currently hash inodes as there is never a need to lookup by inum). To avoid overhead when not exporting, we only hash an inode when it is first exported. This requires a lock to ensure it isn't hashed twice. This code is separate from the patch posted in June06 from Atal Shargorodsky which provided the same functionality, but does borrow slightly from it. Locking comment: Most filesystems that hash their inodes do so at the point where the 'struct inode' is initialised, and that has suitable locking (I_NEW). Here in shmem, we are hashing the inode later, the first time we need an NFS file handle for it. We no longer have I_NEW to ensure only one thread tries to add it to the hash table. Cc: Atal Shargorodsky <atal@codefidence.com> Cc: Gilad Ben-Yossef <gilad@codefidence.com> Signed-off-by:
David M. Grimes <dgrimes@navisite.com> Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Andrew Morton authored
This library function should be in obj-y and not in lib-y. But when we do that it clashes unpleasantly with the assembly-language implementation in the ia64 architecture. Instead of trying to fix it all up, just remove the generic carta_random32 in the expectation that the recently-made-generic random32() will suffice. If/when perfmon is migrated to random32, ia64's private carta_random32 implementation can also be removed. Cc: Stephane Eranian <eranian@hpl.hp.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
-
Stephen Hemminger authored
Make net_random() more widely available by calling it random32 akpm: hopefully this will permit the removal of carta_random32. That needs confirmation from Stephane - this code looks somewhat more computationally expensive, and has a different (ie: callee-stateful) interface. [akpm@osdl.org: lots of build fixes, cleanups] Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Stephane Eranian <eranian@hpl.hp.com> Signed-off-by:
-
Andrew Morton authored
Actually, the decimal representation of a 32-bit signed number can take 12 bytes, including the \0. And then some code adds a \n as well, so let's give it 13 bytes. Signed-off-by:
-
Thomas Gleixner authored
The integer divisions in the timer accounting code can round the result down to 0. Adding 0 is without effect and the signal delivery stops. Clamp the division result to minimum 1 to avoid this. Problem was reported by Seongbae Park <spark@google.com>, who provided also an inital patch. Roland sayeth: I have had some more time to think about the problem, and to reproduce it using Toyo's test case. For the record, if my understanding of the problem is correct, this happens only in one very particular case. First, the expiry time has to be so soon that in cputime_t units (usually 1s/HZ ticks) it's < nthreads so the division yields zero. Second, it only affects each thread that is so new that its CPU time accumulation is zero so now+0 is still zero and ->it_*_expires winds up staying zero. For the VIRT and PROF clocks when cputime_t is tick granularity (or the SCHED clock on configurations where sched_clock's value only advances on clock ticks), this is not hard to arrange with new threads starting up and blocking before they accumulate a whole tick of CPU time. That's what happens in Toyo's test case. Note that in general it is fine for that division to round down to zero, and set each thread's expiry time to its "now" time. The problem only arises with thread's whose "now" value is still zero, so that now+0 winds up 0 and is interpreted as "not set" instead of ">= now". So it would be a sufficient and more precise fix to just use max(ticks, 1) inside the loop when setting each it_*_expires value. But, it does no harm to round the division up to one and always advance every thread's expiry time. If the thread didn't already fire timers for the expiry time of "now", there is no expectation that it will do so before the next tick anyway. So I followed Thomas's patch in lifting the max out of the loops. This patch also covers the reload cases, which are harder to write a test for (and I didn't try). I've tested it with Toyo's case and it fixes that. [toyoa@mvista.com: fix: min_t -> max_t] Signed-off-by:
Roland McGrath <roland@redhat.com> Cc: Daniel Walker <dwalker@mvista.com> Cc: Toyo Abe <toyoa@mvista.com> Cc: john stultz <johnstul@us.ibm.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Seongbae Park <spark@google.com> Cc: Peter Mattis <pmattis@google.com> Cc: Rohit Seth <rohitseth@google.com> Cc: Martin Bligh <mbligh@google.com> Cc: <stable@kernel.org> Signed-off-by:
-
Akinobu Mita authored
I have seen mdadm oops after successfully unloading md module. This patch privents from unloading md module while mdadm is polling /proc/mdstat. Cc: Neil Brown <neilb@suse.de> Signed-off-by:
-
Andrew Morton authored
If remove_mapping() failed to remove the page from its mapping, don't go and mark it not uptodate! Makes kernel go dead. (Actually, I don't think the ClearPageUptodate is needed there at all). Says Nick Piggin: "Right, it isn't needed because at this point the page is guaranteed by remove_mapping to have no references (except us) and cannot pick up any new ones because it is removed from pagecache. We can delete it." Signed-off-by:Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Dave Kleikamp authored
This is Eric Sesterhenn's jbd patch applied to jbd2. Commit: 41716c7c His words: Since commit d1807793 we dereference a NULL pointer. Coverity id #1432. We set journal to NULL, and use it directly afterwards. Signed-off-by:
Dave Kleikamp <shaggy@austin.ibm.com> Cc: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by:
-
