- 07 Jun, 2005 12 commits
-
-
Trond Myklebust authored
We should never apply a lookup intent to anything other than the last path component in an open(), create() or access() call. Introduce the helper nfs_lookup_check_intent() which always returns zero if LOOKUP_CONTINUE or LOOKUP_PARENT are set, and returns the intent flags if we're on the last component of the lookup. By doing so, we fix a bug in open(O_EXCL), where we may end up optimizing away a real lookup of the parent directory. Problem noticed by Linda Dunaphant <linda.dunaphant@ccur.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Bjorn Helgaas authored
At least some VIA chipsets require the fixup even in IO-APIC mode. This was found and debugged with the patient assistance of Stian Jordet <liste@jordet.nu> on an Asus CUV266-DLS motherboard. Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Vojtech Pavlik authored
This patch disables the scroll feature on AT keyboards by default, because it causes the numbers of mouse devices to shift, breaking user setups. Signed-off-by:
Vojtech Pavlik <vojtech@suse.cz> Signed-off-by:
-
Eugene Surovegin authored
Add a definition for PPC 405EP which was lost somehow during 2.4 -> 2.6 transition. Recent change to arch/ppc/kernel/misc.S ("Fix incorrect CPU_FTR fixup usage for unified caches") triggered this bug and 405EP boards don't boot anymore. Signed-off-by:Eugene Surovegin <ebs@ebshome.net> Signed-off-by:
-
Matthew Dobson authored
In file included from arch/i386/kernel/smp.c:235: include/asm-i386/mach-numaq/mach_ipi.h:4: warning: `send_IPI_mask_sequence' declared inline after its definition Signed-off-by:
-
David Mosberger authored
[AGPGART] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0). As mentioned earlier, the current check_bridge_mode() code assumes that AGP bridges are PCI devices. This isn't always true. Definitely not for HP zx1 chipset and the same seems to be the case for SGI's AGP bridge. The patch below fixes the problem by picking up the AGP_MODE_3_0 bit from bridge->mode. I feel like I may be missing something, since I can't see any reason why check_bridge_mode() wasn't doing that in the first place. According to the AGP 3.0 specs, the AGP_MODE_3_0 bit is determined during the hardware reset and cannot be changed, so it seems to me it should be safe to pick it up from bridge->mode. With the patch applied, I can definitely use AGP acceleration both with AGP 2.0 and AGP 3.0 (one with an Nvidia card, the other with an ATI FireGL card). Unless someone spots a problem, please apply this patch so 3d acceleration can work on zx1 boxes again. This makes AGP work again on machines with an AGP bridge that isn't a PCI device. Signed-off-by:
David Mosberger-Tang <davidm@hpl.hp.com> Signed-off-by:
Dave Jones <davej@redhat.com>
-
Keir Fraser authored
When Linux is running on the Xen virtual machine monitor, physical addresses are virtualised and cannot be directly referenced by the AGP GART. This patch fixes the GART driver for Xen by adding a layer of abstraction between physical addresses and 'GART addresses'. Architecture-specific functions are also defined for allocating and freeing the GATT. Xen requires this to ensure that table really is contiguous from the point of view of the GART. These extra interface functions are defined as 'no-ops' for all existing architectures that use the GART driver. Signed-off-by:
Keir Fraser <keir@xensource.com> Signed-off-by:
-
Michael Werner authored
[PATCH] sgi-agp: fixes a problem with accessing GART memory in sgi_tioca_insert_memory and sgi_tioca_remove_memory This patch fixes a problem with accessing GART memory in sgi_tioca_insert_memory and sgi_tioca_remove_memory. sgi-agp.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) Signed-off-by:
Mike Werner <werner@sgi.com> Signed-off-by:
-
Alan Hourihane authored
Attached is a small patch for i945G support against 2.6.11.11. From: Alan Hourihane <alanh@fairlite.demon.co.uk> Signed-off-by: -
David Mosberger authored
I'm not sure why this issue is suddenly showing, but without this patchlet, the zx1 config won't compile anymore (e.g., to see the compilation-error, look for "***" in [1]). [1] http://www.gelato.unsw.edu.au/kerncomp/results//2005-06-06-17-00/zx1_defconfig-log.htmlSigned-off-by:
-
Tom Rini authored
On ppc32, <asm/sigcontext.h> uses __user, but doesn't directly include <linux/compiler.h>. This adds that in. Without this, glibc will not compile. Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Signed-off-by:
-
- 06 Jun, 2005 28 commits
-
-
-
-
David S. Miller authored
Signed-off-by:David S. Miller <davem@davemloft.net>
-
Michael Chan authored
On some 5701 devices with older bootcode, the LED configuration bits in SRAM may be invalid with value zero. The fix is to check for invalid bits (0) and default to PHY 1 mode. Incorrect LED mode will lead to error in programming the PHY. Thanks to Grant Grundler for debugging the problem. >From Grant: | In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting | programmed and how to determine what to program into LED_CTRL. The new | code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write | to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was | saying MODE_MAC (0x0) and that doesn't work. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Michael Chan authored
Signed-off-by:
-
John W. Linville authored
Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
David S. Miller authored
It was checking the "GET" function pointer instead of the "SET" one. Looks like a cut&paste error :-) Signed-off-by: -
Yoshinori Sato authored
Make sure that binfmt_flat passes the correct flags into do_mmap(). nommu's validate_mmap_request() will simple return -EINVAL if we try and pass it a flags value of zero. Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
-
Al Viro authored
__do_follow_link() passes potentially worng vfsmount to touch_atime(). It matters only in (currently impossible) case of symlink mounted on something, but it's trivial to fix and that actually makes more sense. Signed-off-by:
Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by:
-
Al Viro authored
Cosmetical cleanups - __follow_mount() calls in __link_path_walk() absorbed into do_lookup(). Obviously equivalent transformation. Signed-off-by:
-
Al Viro authored
follow_mount() made void, reordered dput()/mntput() in it. follow_dotdot() switched from struct vfmount ** + struct dentry ** to struct nameidata *; callers updated. Equivalent transformation + fix for too-early-mntput() race. Signed-off-by:
-
Al Viro authored
Conditional mntput() moved into __do_follow_link(). There it collapses with unconditional mntget() on the same sucker, closing another too-early-mntput() race. Signed-off-by:
-
Al Viro authored
Getting rid of sloppy logics: a) in do_follow_link() we have the wrong vfsmount dropped if our symlink had been mounted on something. Currently it worls only because we never get such situation (modulo filesystem playing dirty tricks on us). And it obfuscates already convoluted logics... b) same goes for open_namei(). c) in __link_path_walk() we have another "it should never happen" sloppiness - out_dput: there does double-free on underlying vfsmount and leaks the covering one if we hit it just after crossing a mountpoint. Again, wrong vfsmount getting dropped. d) another too-early-mntput() race - in do_follow_mount() we need to postpone conditional mntput(path->mnt) until after dput(path->dentry). Again, this one happens only in it-currently-never-happens-unless-some-fs-plays-dirty scenario... Signed-off-by:
-
Al Viro authored
shifted conditional mntput() into do_follow_link() - all callers were doing the same thing. Obviously equivalent transformation. Signed-off-by:
-
Al Viro authored
In open_namei() exit_dput: we have mntput() done in the wrong order - if nd->mnt != path.mnt we end up doing mntput(nd->mnt); nd->mnt = path.mnt; dput(nd->dentry); mntput(nd->mnt); which drops nd->dentry too late. Fixed by having path.mnt go first. That allows to switch O_NOFOLLOW under if (__follow_mount(...)) back to exit_dput, while we are at it. Fix for early-mntput() race + equivalent transformation. Signed-off-by:
-
Al Viro authored
In open_namei() we take mntput(nd->mnt);nd->mnt=path.mnt; out of the if (__follow_mount(...)), making it conditional on nd->mnt != path.mnt instead. Then we shift the result downstream. Equivalent transformations. Signed-off-by:
-
Al Viro authored
shifted conditional mntput() calls in __link_path_walk() downstream. Obviously equivalent transformation. Signed-off-by:
-
Al Viro authored
In open_namei(), __follow_down() loop turned into __follow_mount(). Instead of if we are on a mountpoint dentry if O_NOFOLLOW checks fail drop path.dentry drop nd return do equivalent of follow_mount(&path.mnt, &path.dentry) nd->mnt = path.mnt we do if __follow_mount(path) had, indeed, traversed mountpoint /* now both nd->mnt and path.mnt are pinned down */ if O_NOFOLLOW checks fail drop path.dentry drop path.mnt drop nd return mntput(nd->mnt) nd->mnt = path.mnt Now __follow_down() can be folded into follow_down() - no other callers left. We need to reorder dput()/mntput() there - same problem as in follow_mount(). Equivalent transformation + fix for a bug in O_NOFOLLOW handling - we used to get -ELOOP if we had the same fs mounted on /foo and /bar, had something bound on /bar/baz and tried to open /foo/baz with O_NOFOLLOW. And fix of too-early-mntput() race in follow_down() Signed-off-by:
-
Al Viro authored
New helper: __follow_mount(struct path *path). Same as follow_mount(), except that we do *not* do mntput() after the first lookup_mnt(). IOW, original path->mnt stays pinned down. We also take care to do dput() before mntput() in the loop body (follow_mount() also needs that reordering, but that will be done later in the series). The following are equivalent, assuming that path.mnt == x: (1) follow_mount(&path.mnt, &path.dentry) (2) __follow_mount(&path); if (path->mnt != x) mntput(x); (3) if (__follow_mount(&path)) mntput(x); Callers of follow_mount() in __link_path_walk() converted to (2). Equivalent transformation + fix for too-late-mntput() race in __follow_mount() loop. Signed-off-by:
-
Al Viro authored
In open_namei() we never use path.mnt or path.dentry after exit: or ok:. Assignment of path.dentry in case of LAST_BIND is dead code and only obfuscates already convoluted function; assignment of path.mnt after __do_follow_link() can be moved down to the place where we set path.dentry. Obviously equivalent transformations, just to clean the air a bit in that region. Signed-off-by:
-
Al Viro authored
The first argument of __do_follow_link() switched to struct path * (__do_follow_link(path->dentry, ...) -> __do_follow_link(path, ...)). All callers have the same calls of mntget() right before and dput()/mntput() right after __do_follow_link(); these calls have been moved inside. Obviously equivalent transformations. Signed-off-by:
-
Al Viro authored
mntget(path->mnt) in do_follow_link() moved down to right before the __do_follow_link() call and rigth after loop: resp. dput()+mntput() on non-ELOOP branch moved up to right after __do_follow_link() call. resulting loop: mntget(path->mnt); path_release(nd); dput(path->mnt); mntput(path->mnt); replaced with equivalent dput(path->mnt); path_release(nd); Equivalent transformations - the reason why we have that mntget() is that __do_follow_link() can drop a reference to nd->mnt and that's what holds path->mnt. So that call can happen at any point prior to __do_follow_link() touching nd->mnt. The rest is obvious. NOTE: current tree relies on symlinks *never* being mounted on anything. It's not hard to get rid of that assumption (actually, that will come for free later in the series). For now we are just not making the situation worse than it is. Signed-off-by:
-
Al Viro authored
fix for too early mntput() in open_namei() - we pin path.mnt down for the duration of __do_follow_link(). Otherwise we could get the fs where our symlink lived unmounted while we were in __do_follow_link(). That would end up with dentry of symlink staying pinned down through the fs shutdown. Signed-off-by:
-
Al Viro authored
path.mnt in open_namei() set to mirror nd->mnt. nd->mnt is set in 3 places in that function - path_lookup() in the beginning, __follow_down() loop after do_last: and __do_follow_link() call after do_link:. We set path.mnt to nd->mnt after path_lookup() and __do_follow_link(). In __follow_down() loop we use &path.mnt instead of &nd->mnt and set nd->mnt to path.mnt immediately after that loop. Obviously equivalent transformation. Signed-off-by:
-
Al Viro authored
Replaced struct dentry *dentry in namei with struct path path. All uses of dentry replaced with path.dentry there. Obviously equivalent transformation. Signed-off-by:
-
Al Viro authored
All callers of do_follow_link() do mntget() right before it and dput()+mntput() right after. These calls are moved inside do_follow_link() now. Obviously equivalent transformation. Signed-off-by:
-
Al Viro authored
OK, here comes a patch series that hopefully should close all too-early-mntput() races in fs/namei.c. Entire area is convoluted as hell, so I'm splitting that series into _very_ small chunks. Patches alread in the tree close only (very wide) races in following symlinks (see "busy inodes after umount" thread some time ago). Unfortunately, quite a few narrower races of the same nature were not closed. Hopefully this should take care of all of them. Signed-off-by:
-
Kumar Gala authored
Runtime feature support for unified caches was testing a userland feature flag (PPC_FEATURE_UNIFIED_CACHE) instead of a cpu feature flag (CPU_FTR_SPLIT_ID_CACHE). Luckily the current defined bit mask for cpu features and userland features do not overlap so this only causes an issue on machines with a unified cache, which is extremely rare on PPC today. Signed-off-by:
Kumar Gala <kumar.gala@freescale.com> Signed-off-by:
-
