- 17 Oct, 2006 29 commits
-
-
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:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
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:
Alan Cox <alan@redhat.com> Signed-off-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:
Ingo Molnar <mingo@elte.hu> Acked-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:
Neil Brown <neilb@suse.de> Acked-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:
Akinbou Mita <akinobu.mita@gmail.com> 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:
-
john stultz authored
Avoid possible PIT livelock issues seen on SMP systems (and reported by Andi), by not allowing it as a clocksource on SMP boxes. However, since the PIT may no longer be present, we have to properly handle the cases where SMP systems have TSC skew and fall back from the TSC. Since the PIT isn't there, it would "fall back" to the TSC again. So this changes the jiffies rating to 1, and the TSC-bad rating value to 0. Thus you will get the following behavior priority on i386 systems: tsc [if present & stable] hpet [if present] cyclone [if present] acpi_pm [if present] pit [if UP] jiffies Rather then the current more complicated: tsc [if present & stable] hpet [if present] cyclone [if present] acpi_pm [if present] pit [if cpus < 4] tsc [if present & unstable] jiffies Signed-off-by:
John Stultz <johnstul@us.ibm.com> Cc: Andi Kleen <ak@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Pierre Ossman authored
I will be taking over after Russell King as the new maintainer of the MMC layer. Signed-off-by:
Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Ingo Molnar authored
In general, lockdep warnings are intended to be non-fatal, so I have put in various practical limits on internal data structure failure modes. We haven't had a /single/ lockdep-internal crash ever since lockdep went upstream [the unwinder crashes are outside of lockdep], and that's largely due to the good internal checks it does. Recursion within the dependency graph is currently limited to 20, that's probably not enough on some many-CPU boxes - this patch doubles it to 40. I have written the lockdep functions to have as small stackframes as possible, so 40 should be OK too. (The practical recursion limit should be somewhere between 100 and 200 entries. If we hit that then I'll change the algorithm to be iteration-based. Graph walking logic is so easy to program via recursion, so i'd like to keep recursion as long as possible.) Signed-off-by:
-
Paul Fulghum authored
Remove reference to PAGE_SIZE that causes errors if PAGE_SIZE != 4096 Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Signed-off-by:
-
Brent Casavant authored
The SGI PCI-RT card, based on the SGI IOC4 chip, will be made available on Altix XE (x86_64) platforms in the near future. As such it is now a misnomer for the IOC4 base device driver to live under drivers/sn, and would complicate builds for non-SN2. This patch moves the IOC4 base driver code from drivers/sn to drivers/misc, and updates the associated Makefiles and Kconfig files to allow building on non-SN2 configs. Due to the resulting change in link order, it is now necessary to use late_initcall() for IOC4 subdriver initialization. [akpm@osdl.org: __udivdi3 fix] [akpm@osdl.org: fix default in Kconfig] Acked-by:
Pat Gefre <pfg@sgi.com> Acked-by:
Jeremy Higdon <jeremy@sgi.com> Signed-off-by:
Brent Casavant <bcasavan@sgi.com> Signed-off-by:
-
Brent Casavant authored
The SGI PCI-RT card, based on the SGI IOC4 chip, will be made available on Altix XE (x86_64) platforms in the near future. As such dependencies on SN2-specific features and config dependencies need to be removed. This patch updates the Kconfig files to remove the config dependency, and updates the IOC4 bus speed detection routine to use universally available time interfaces instead of mmtimer. Signed-off-by:
-
- 16 Oct, 2006 11 commits
-
-
Geert Uytterhoeven authored
The telecom clock driver for MPBL0010 ATCA SBC depends on X86 Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Mark Gross <mark.gross@intel.com> Signed-off-by:
-
Randy Dunlap authored
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7371 sys_epoll_pwait needs to be listed as a conditional (weak) entry point for CONFIG_EPOLL=n. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: (25 commits) [Bluetooth] Use work queue to trigger URB submission [Bluetooth] Add locking for bt_proto array manipulation [Bluetooth] Check if DLC is still attached to the TTY [Bluetooth] Fix reference count when connection lookup fails [Bluetooth] Disconnect HID interrupt channel first [Bluetooth] Support concurrent connect requests [Bluetooth] Make use of virtual devices tree [Bluetooth] Handle return values from driver core functions [Bluetooth] Fix compat ioctl for BNEP, CMTP and HIDP [IPV6] sit: Add missing MODULE_LICENSE [IPV6]: Remove bogus WARN_ON in Proxy-NA handling. [IPv6] rules: Use RT6_LOOKUP_F_HAS_SADDR and fix source based selectors [XFRM]: Fix xfrm_state_num going negative. [NET]: reduce sizeof(struct inet_peer), cleanup, change in peer_check_expire() NetLabel: the CIPSOv4 passthrough mapping does not pass categories correctly NetLabel: better error handling involving mls_export_cat() NetLabel: only deref the CIPSOv4 standard map fields when using standard mapping [BRIDGE]: flush forwarding table when device carrier off [NETFILTER]: ctnetlink: Remove debugging messages [NETFILTER]: Update MAINTAINERS entry ...
-
David Howells authored
Use inc/dec_preempt_count() rather than preempt_enable/disable() and manually add in the compiler barriers that were provided by the latter. This makes FRV consistent with other archs. Furthermore, the compiler barrier effects are now there unconditionally - at least as far as preemption is concerned - because we don't want the compiler moving memory accesses out of the section of code in which the mapping is in force - in effect the kmap_atomic() must imply a LOCK-class barrier and the kunmap_atomic() must imply an UNLOCK-class barrier to the compiler. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Andrey Mirkin authored
It is known that 2 LSI Logic MegaRAID SATA RAID Controllers (150-4 and 150-6) don't support 64-bit DMA. Unfortunately currently this check is wrong and driver sets 64-bit DMA mode for these devices. Signed-off-by:
Andrey Mirkin <amirkin@sw.ru> Acked-by:
Vasily Averin <vvs@sw.ru> Signed-off-by:
-
Alan Cox authored
Without this the user can feed in bogus values and get very bogus results. Security impact is minimal as this ioctl isn't available to unpriviledged processes anyway. Reported to the l/k list and found with an auditing tool. Signed-off-by:
-
Alan Cox authored
Found by an analysis tool and reported to the list. Fix is simple enough Signed-off-by:
-
Marcel Holtmann authored
The bcm203x firmware loading driver uses a timer to trigger the URB submission. It is better to use a work queue instead. Signed-off-by:Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The bt_proto array needs to be protected by some kind of locking to prevent a race condition between bt_sock_create and bt_sock_register. And in addition all calls to sk_alloc need to be made GFP_ATOMIC now. Signed-off-by:
Masatake YAMATO <jet@gyve.org> Signed-off-by:
Frederik Deweerdt <frederik.deweerdt@gmail.com> Signed-off-by:
-
Marcel Holtmann authored
If the DLC device is no longer attached to the TTY device, then it makes no sense to go through with changing the termios settings. Signed-off-by: -
Marcel Holtmann authored
When the connection lookup for the device structure fails, the reference count for the HCI device needs to be decremented. Signed-off-by:
-
