- 13 Oct, 2006 38 commits
-
-
Hidetoshi Seto authored
Following function can drops d_count twice against one reference by lookup_one_len. <SOURCE> /** * sysfs_update_file - update the modified timestamp on an object attribute. * @kobj: object we're acting for. * @attr: attribute descriptor. */ int sysfs_update_file(struct kobject * kobj, const struct attribute * attr) { struct dentry * dir = kobj->dentry; struct dentry * victim; int res = -ENOENT; mutex_lock(&dir->d_inode->i_mutex); victim = lookup_one_len(attr->name, dir, strlen(attr->name)); if (!IS_ERR(victim)) { /* make sure dentry is really there */ if (victim->d_inode && (victim->d_parent->d_inode == dir->d_inode)) { victim->d_inode->i_mtime = CURRENT_TIME; fsnotify_modify(victim); /** * Drop reference from initial sysfs_get_dentry(). */ dput(victim); res = 0; } else d_drop(victim); /** * Drop the reference acquired from sysfs_get_dentry() above. */ dput(victim); } mutex_unlock(&dir->d_inode->i_mutex); return res; } </SOURCE> PCI-hotplug (drivers/pci/hotplug/pci_hotplug_core.c) is only user of this function. I confirmed that dentry of /sys/bus/pci/slots/XXX/* have negative d_count value. This patch removes unnecessary dput(). Signed-off-by:Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Arnd Bergmann authored
Ulrich Weigand found a bug with the current version of the asm-powerpc/ptrace.h that prevents building at least the SPU target version of gdb, since some ptrace opcodes are not defined. The problem seems to have originated in the merging of 32 and 64 bit versions of that file, the problem is that some opcodes are only valid on 64 bit kernels, but are also used by 32 bit programs, so they can't depends on the __powerpc64__ symbol. Signed-off-by:
Arnd Bergmann <arnd.bergmann@de.ibm.com> Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
David Woodhouse authored
It's not used by anything user-visible, and it make g++ unhappy. Signed-off-by:
-
David Woodhouse authored
This fixes most of the issues with exported headers on CRIS, although we do still need to deal with the asm/arch symlink. Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
David Woodhouse authored
For architectures which don't have the include/asm-$(ARCH)/Kbuild file, like ARM26, UM, etc. Signed-off-by:
-
David Woodhouse authored
No need for UML to export headers for userspace to build against. Signed-off-by:
-
David Woodhouse authored
We ought to be able to use ARM headers; no need for special ARM26 version. Signed-off-by:
-
David Woodhouse authored
Just clean up asm/page.h Signed-off-by:
-
David Woodhouse authored
Just clean up asm/page.h Signed-off-by:
-
David Woodhouse authored
Mostly removing files which have no business being used in userspace. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Woodhouse authored
> asm-m32r/page.h requires asm-generic/memory_model.h, which does not exist > asm-m32r/ptrace.h requires asm/m32r.h, which does not exist > asm-m32r/signal.h requires linux/linkage.h, which does not exist > asm-m32r/unistd.h requires asm/syscall.h, which does not exist > asm-m32r/user.h requires asm/processor.h, which does not exist Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Paul Mundt authored
Cleanup for user headers, as noted: asm-sh64/page.h requires asm-generic/memory_model.h, which does not exist in exported headers asm-sh64/shmparam.h requires asm/cache.h, which does not exist in exported headers asm-sh64/signal.h requires asm/processor.h, which does not exist in exported headers asm-sh64/user.h requires asm/processor.h, which does not exist in exported headers Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Paul Mundt authored
Cleanup for user headers, as noted: asm-sh/page.h requires asm-generic/memory_model.h, which does not exist in exported headers asm-sh/ptrace.h requires asm/ubc.h, which does not exist in exported headers Signed-off-by:
-
David Woodhouse authored
Sanitise the ARM headers exported to userspace. Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
Stephen Hemminger authored
This makes the id table match the current netdev upstream tree. From: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: -
Stephen Hemminger authored
The sky2 driver will hang if transmit flow control is enabled and it receives a pause frame. The pause frame gets partially processed by hardware but never makes it through to the correct logic. This patch made it into 2.6.17 stable, but never got accepted for 2.6.18, so it will have to go into 2.6.18.1 See also: http://bugzilla.kernel.org/show_bug.cgi?id=6839Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Jeff Garzik authored
inside #if 0'd code, but it bugged me. Really, we should probably just delete the driver. Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Jeff Garzik authored
The last minute fix submitted by the author fixed a bug, but broke the driver build. Noticed by Al Viro, since I can't build on said platform. Signed-off-by:
-
Christoph Lameter authored
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0ff38490c836dc379ff7ec45b10a15a662f4e5f6 Currently one can enable slab reclaim by setting an explicit option in /proc/sys/vm/zone_reclaim_mode. Slab reclaim is then used as a final option if the freeing of unmapped file backed pages is not enough to free enough pages to allow a local allocation. However, that means that the slab can grow excessively and that most memory of a node may be used by slabs. We have had a case where a machine with 46GB of memory was using 40-42GB for slab. Zone reclaim was effective in dealing with pagecache pages. However, slab reclaim was only done during global reclaim (which is a bit rare on NUMA systems). This patch implements slab reclaim during zone reclaim. Zone reclaim occurs if there is a danger of an off node allocation. At that point we 1. Shrink the per node page cache if the number of pagecache pages is more than min_unmapped_ratio percent of pages in a zone. 2. Shrink the slab cache if the number of the nodes reclaimable slab pages (patch depends on earlier one that implements that counter) are more than min_slab_ratio (a new /proc/sys/vm tunable). The shrinking of the slab cache is a bit problematic since it is not node specific. So we simply calculate what point in the slab we want to reach (current per node slab use minus the number of pages that neeed to be allocated) and then repeately run the global reclaim until that is unsuccessful or we have reached the limit. I hope we will have zone based slab reclaim at some point which will make that easier. The default for the min_slab_ratio is 5% Also remove the slab option from /proc/sys/vm/zone_reclaim_mode. [akpm@osdl.org: cleanups] Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Christoph Lameter authored
The scheduler will stop load balancing if the most busy processor contains processes pinned via processor affinity. The scheduler currently only does one search for busiest cpu. If it cannot pull any tasks away from the busiest cpu because they were pinned then the scheduler goes into a corner and sulks leaving the idle processors idle. F.e. If you have processor 0 busy running four tasks pinned via taskset, there are none on processor 1 and one just started two processes on processor 2 then the scheduler will not move one of the two processes away from processor 2. This patch fixes that issue by forcing the scheduler to come out of its corner and retrying the load balancing by considering other processors for load balancing. This patch was originally developed by John Hawkes and discussed at http://marc.theaimsgroup.com/?l=linux-kernel&m=113901368523205&w=2. I have removed extraneous material and gone back to equipping struct rq with the cpu the queue is associated with since this makes the patch much easier and it is likely that others in the future will have the same difficulty of figuring out which processor owns which runqueue. The overhead added through these patches is a single word on the stack if the kernel is configured to support 32 cpus or less (32 bit). For 32 bit environments the maximum number of cpus that can be configued is 255 which would result in the use of 32 bytes additional on the stack. On IA64 up to 1k cpus can be configured which will result in the use of 128 additional bytes on the stack. The maximum additional cache footprint is one cacheline. Typically memory use will be much less than a cacheline and the additional cpumask will be placed on the stack in a cacheline that already contains other local variable. Signed-off-by:
-
Jan Kara authored
Original commit code assumes, that when a buffer on BJ_SyncData list is locked, it is being written to disk. But this is not true and hence it can lead to a potential data loss on crash. Also the code didn't count with the fact that journal_dirty_data() can steal buffers from committing transaction and hence could write buffers that no longer belong to the committing transaction. Finally it could possibly happen that we tried writing out one buffer several times. The patch below tries to solve these problems by a complete rewrite of the data commit code. We go through buffers on t_sync_datalist, lock buffers needing write out and store them in an array. Buffers are also immediately refiled to BJ_Locked list or unfiled (if the write out is completed). When the array is full or we have to block on buffer lock, we submit all accumulated buffers for IO. [suitable for 2.6.18.x around the 2.6.19-rc2 timeframe] Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by:
-
Takashi Iwai authored
ALSA: Fix initiailization of user-space controls Fix an assertion when accessing a user-defined control due to lack of initialization (appears only when CONFIG_SND_DEBUg is enabled). ALSA sound/core/control.c:660: BUG? (info->access == 0) Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Tony Lindgren authored
Allows compiling g_ether in and fixes a typo with MUSB_HDRC Signed-off-by:
Tony Lindgren <tony@atomide.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Jack Morgenstein authored
The SM LID used to send traps to is incorrectly set to port LID. This is a regression from 2.6.17 -- after a PortInfo MAD is received, no traps are sent to the SM LID. The traps go to the loopback interface instead, and are dropped there. The SM LID should be taken from the sm_lid of the PortInfo response. The bug was introduced by commit 12bbb2b7: IB/mthca: Add client reregister event generation Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Martin Schwidefsky authored
[S390] user readable uninitialised kernel memory. A user space program can read uninitialised kernel memory by appending to a file from a bad address and then reading the result back. The cause is the copy_from_user function that does not clear the remaining bytes of the kernel buffer after it got a fault on the user space address. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Daniel Drake authored
The vendor driver chooses this value based on an ifndef ASIC, and ASIC is never defined. Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Mike Isely authored
Currently it is not understood how to properly control the horizontal capture resolution on 24xxx devices. The pvrusb2 driver is doing everything it should (pass resolution paramter(s) to cx2341x and cx25840 modules) but for some reason the result is corrupted video if any resolution other than 720 is used. This patch causes the driver to only permit a horizontal resolution of 720 to be used on 24xxx devices. Even if the app requests something else, the driver will force the resolution back to 720. This patch still allows full control of the resolution for 29xxx devices. Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Mike Isely authored
The pvrusb2 driver needs to call video_devdata() in order to correctly transform a file pointer into a video_device pointer. Unfortunately the prototype for this function has been marked V4L1-only and there's no official substitute that I can find for V4L2. Adding to the mystery is that the implementation for this function exists whether or not V4L1 compatibility has been selected. The upshot of all this is that we get a compilation warning here about a missing prototype but the code links OK. This fix solves the warning by copying the prototype into the source file that is using it. Yes this is a hack, but it's a safe one for 2.6.18 (any alternative would be much more intrusive). A better solution should be forthcoming for the next kernel. Signed-off-by:
-
Mike Isely authored
The CONFIG_VIDEO_PVRUSB2_24XXX is not nearly as "experimental" as the description suggests. So refine the description to better match reality. Signed-off-by:
-
Mike Isely authored
There is a mutex ordering problem between the pvrusb2 driver and the v4l core. Two different pathways take mutexes in opposing orders and this (under rare circumstances) can cause a deadlock. The two mutexes in question are videodev_lock in the v4l core and device_lock inside the pvrusb2 driver. The device_lock instance in the driver protects a private global array of context pointers which had been implemented in advance of v4l core changes which eliminate the video_set_drvdata() and video_get_drvdata() functions. This patch restores the use of video_get_drvdata() and video_set_drvdata(), eliminating the need for the array and the mutex. (This is actually a patch to restore the previous implementation.) We can do this for 2.6.18 since those functions are in fact still present. A better (and larger) solution will be done for later kernels. Signed-off-by:
-
Yeasah Pell authored
The cx24109 datasheet says: "NOTE: if A=0, then N=N+1" The current code is the result of a misinterpretation of the datasheet to mean exactly the opposite of the requirement -- The actual value of N is 1 greater than the value written when A is 0, so 1 needs to be *subtracted* from it to compensate. Signed-off-by:
Yeasah Pell <yeasah@schwide.net> Signed-off-by:
Steven Toth <stoth@hauppauge.com> Signed-off-by:
-
Hans Verkuil authored
The msp3430G and msp3435G models cannot do Automatic Standard Detection, so these should be forced to BTSC. These chips are early production versions for the msp34xxG series and are quite rare. The workaround for kernel 2.6.18 is to use 'standard=32' as msp3400 module option. Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Jeff Dike authored
don't know if the following is already queued, it fixes an ARCH=um build failure, evidence here: http://marc.theaimsgroup.com/?l=linux-kernel&m=115875912525137&w=2 and following thread. Cc-ing uml maintainers and I hope I didn't follow too many Submitting-patches rules... The patch is taken from: http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.18/patches/no-syscallx Since the syscallx macros seem to be under threat, this patch stops using them, using syscall instead. Acked-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
This should make sure that, for UML, host's configuration files are not considered, which avoids various pains to the user. Our dependency are such that the obtained Kconfig will be valid and will lead to successful compilation - however they cannot prevent an user from disabling any boot device, and if an option is not set in the read .config (say /boot/config-XXX), with make menuconfig ARCH=um, it is not set. This always disables UBD and all console I/O channels, which leads to non-working UML kernels, so this bothers users - especially now, since it will happen on almost every machine (/boot/config-`uname -r` exists almost on every machine). It can be workarounded with make defconfig ARCH=um, but it is non-obvious and can be avoided, so please _do_ merge this patch. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Acked-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Enable compilation of x86_64 crypto code;, and add the needed constant to make the code compile again (that macro was added to i386 asm-offsets between 2.6.17 and 2.6.18, in 6c2bb98b). Signed-off-by:
-
Patrick McHardy authored
The move of qdisc destruction to a rcu callback broke locking in the entire qdisc layer by invalidating previously valid assumptions about the context in which changes to the qdisc tree occur. The two assumptions were: - since changes only happen in process context, read_lock doesn't need bottem half protection. Now invalid since destruction of inner qdiscs, classifiers, actions and estimators happens in the RCU callback unless they're manually deleted, resulting in dead-locks when read_lock in process context is interrupted by write_lock_bh in bottem half context. - since changes only happen under the RTNL, no additional locking is necessary for data not used during packet processing (f.e. u32_list). Again, since destruction now happens in the RCU callback, this assumption is not valid anymore, causing races while using this data, which can result in corruption or use-after-free. Instead of "fixing" this by disabling bottem halfs everywhere and adding new locks/refcounting, this patch makes these assumptions valid again by moving destruction back to process context. Since only the dev->qdisc pointer is protected by RCU, but ->enqueue and the qdisc tree are still protected by dev->qdisc_lock, destruction of the tree can be performed immediately and only the final free needs to happen in the rcu callback to make sure dev_queue_xmit doesn't access already freed memory. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
- 20 Sep, 2006 2 commits
-
-
Linus Torvalds authored
Ahoy, all land-lubbers, test me out right smartly! Signed-off-by: -
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [IPV4] fib_trie: missing ntohl() when calling fib_semantic_match() [NETFILTER]: xt_quota: add missing module aliases [ATM]: [he] don't hold the device lock when upcalling
-
