- 20 Oct, 2006 40 commits
-
-
Al Viro authored
on-the-wire data is big-endian [in large part pulled from Alexey's patch] Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Trond Myklebust <trond.myklebust@fys.uio.no> Acked-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Al Viro authored
on-the-wire data is big-endian [in large part pulled from Alexey's patch] Signed-off-by:
-
Al Viro authored
on-the-wire data is big-endian [in large part pulled from Alexey's patch] Signed-off-by:
-
Al Viro authored
on-the-wire data is big-endian [in large part pulled from Alexey's patch] Signed-off-by:
-
Al Viro authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Al Viro authored
svc_procfunc instances return __be32, not int Signed-off-by:
-
Al Viro authored
a) ERR_PTR(nfserr_something) is a bad idea; IS_ERR() will be false for it. b) mixing nfserr_.... with -EOPNOTSUPP is even worse idea. nfsd4_path() does both; caller expects to get NFS protocol error out it if anything goes wrong, but if it does we either do not notice (see (a)) or get host-endian negative (see (b)). IOW, that's a case when we can't use ERR_PTR() to return error, even though we return a pointer in case of success. Signed-off-by:
-
Chuck Lever authored
Yes, this actually passed tests the way it was. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Chuck Lever authored
When submitting a request to a fast portmapper (such as the local rpcbind daemon), the request can complete before the parent task is even queued up on xprt->binding. Fix this by queuing before submitting the rpcbind request. Test plan: Connectathon locking test with UDP. Signed-off-by:
-
Chuck Lever authored
Coverity spotted a superfluous error check in nfs4_open_revalidate(). Remove it. Coverity: #cid 847 Test plan: Code inspection; another pass through Coverity. Signed-off-by:
-
Chuck Lever authored
The "!inode" check in __nfs_revalidate_inode() occurs well after the first time it is dereferenced, so get rid of it. Coverity: #cid 1372, 1373 Test plan: Code review; recheck with Coverity. Signed-off-by:
-
Chuck Lever authored
The original code confused a zero return code from pagevec_add() as success. Test plan: None. Signed-off-by:
-
Trond Myklebust authored
If invalidate_inode_pages2() fails, then it should in principle just be because the current process was signalled. In that case, we just want to ensure that the inode's page cache remains marked as invalid. Also add a helper to allow the O_DIRECT code to simply mark the page cache as invalid once it is finished writing, instead of calling invalidate_inode_pages2() itself. Signed-off-by:
-
Trond Myklebust authored
The change in semantics for nfs_find_client() introduced by David breaks the NFSv4 callback channel. Also, replace another completely broken BUG_ON() in nfs_find_client(). In initialised clients, clp->cl_cons_state == 0, and callers of that function should in any case never want to see clients that are uninitialised. Signed-off-by:
-
J. Bruce Fields authored
David forgot to do this. I'm not sure if this is the right place to put it.... Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Trond Myklebust authored
If the RPC call tanked, we should not be checking the return value of data->res.verf->committed, since it is unlikely to even be initialised. Signed-off-by:
-
Trond Myklebust authored
Fix two bugs: - nfs_inode_remove_request will call nfs_clear_request, so we cannot reference req->wb_page after it. Move the call to dec_zone_page_state so that it occurs while req->wb_page is still valid. - Calling nfs_clear_page_writeback is unnecessary since the radix tree tags will have been cleared by the call to nfs_inode_remove_request. Replace with a simple call to nfs_unlock_request. Signed-off-by:
-
Trond Myklebust authored
Duh. addr.sin_port should be in network byte order. Signed-off-by:
-
David Howells authored
Make sure all dentries refs are released before calling kill_anon_super() so that the assumption that generic_shutdown_super() can completely destroy the dentry tree for there will be no external references holds true. What was being done in the put_super() superblock op, is now done in the kill_sb() filesystem op instead, prior to calling kill_anon_super(). The call to shrink_dcache_sb() is removed as it is redundant since shrink_dcache_for_umount() will now be called after the cleanup routine. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Ian Kent <raven@themaw.net> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Randy Dunlap authored
GENERIC_ACL shouldn't be under Network File Systems (which made it depend on NET) as far as I can tell. Having it there and having many (FS) config symbols disabled gives this (which the patch fixes): mm/built-in.o: In function `shmem_check_acl': shmem_acl.c:(.text.shmem_check_acl+0x33): undefined reference to `posix_acl_permission' fs/built-in.o: In function `generic_acl_get': (.text.generic_acl_get+0x30): undefined reference to `posix_acl_to_xattr' fs/built-in.o: In function `generic_acl_set': (.text.generic_acl_set+0x75): undefined reference to `posix_acl_from_xattr' fs/built-in.o: In function `generic_acl_set': (.text.generic_acl_set+0x94): undefined reference to `posix_acl_valid' fs/built-in.o: In function `generic_acl_set': (.text.generic_acl_set+0xc1): undefined reference to `posix_acl_equiv_mode' fs/built-in.o: In function `generic_acl_init': (.text.generic_acl_init+0x7a): undefined reference to `posix_acl_clone' fs/built-in.o: In function `generic_acl_init': (.text.generic_acl_init+0xb4): undefined reference to `posix_acl_clone' fs/built-in.o: In function `generic_acl_init': (.text.generic_acl_init+0xc8): undefined reference to `posix_acl_create_masq' fs/built-in.o: In function `generic_acl_chmod': (.text.generic_acl_chmod+0x49): undefined reference to `posix_acl_clone' fs/built-in.o: In function `generic_acl_chmod': (.text.generic_acl_chmod+0x76): undefined reference to `posix_acl_chmod_masq' Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Acked-by:
Andreas Gruenbacher <agruen@suse.de> Signed-off-by:
-
Randy Dunlap authored
If CONFIG_PROC_FS=n: kernel/sysctl.c:148: warning: 'proc_do_cad_pid' used but never defined kernel/built-in.o:(.data+0x1228): undefined reference to `proc_do_cad_pid' make: *** [.tmp_vmlinux1] Error 1 Signed-off-by:
-
Ralf Baechle authored
In most cases the return value of WARN_ON() is ignored. If the generic definition for the !CONFIG_BUG case is used this will result in a warning: CC kernel/sched.o In file included from include/linux/bio.h:25, from include/linux/blkdev.h:14, from kernel/sched.c:39: include/linux/ioprio.h: In function âtask_ioprioâ: include/linux/ioprio.h:50: warning: statement with no effect kernel/sched.c: In function âcontext_switchâ: kernel/sched.c:1834: warning: statement with no effect Signed-off-by:Ralf Baechle <ralf@linux-mips.org> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@redhat.com> Cc: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by:
-
Alexey Dobriyan authored
Despite mm.h is not being exported header, it does contain one thing which is part of userspace ABI -- value disabling OOM killer for given process. So, a) create and export include/linux/oom.h b) move OOM_DISABLE define there. c) turn bounding values of /proc/$PID/oom_adj into defines and export them too. Note: mass __KERNEL__ removal will be done later. Signed-off-by:
-
Yasunori Goto authored
I wrote a patch to avoid redundant memory hot-add call at boot time. This was cause of strange fail message of memory hotplug like "ACPI: add_memory failed". Memory is recognized by early boot code with EFI/E820. But, if DSDT describes memory devices for them, then hot-add code is called for already recognized memory, and it shows fail messages with -EEXIST. So, sys admin will misunderstand this message as something wrong by it. This patch avoids them by preventing redundant hot-add call until completion of driver initialization. [akpm@osdl.org: cleanups] Signed-off-by:
Yasunori Goto <y-goto@jp.fujitsu.com> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by:
-
Yasunori Goto authored
I suppose this message seems quite useless except debugging. It just shows "Hotplug Mem Device". System admin can't know anything by this message. So, I would like to change it to KERN_DEBUG. Signed-off-by:
-
Borislav Petkov authored
Signed-off-by:
Borislav Petkov <petkov@math.uni-muenster.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Ingo Molnar authored
Re-add the set_irq_chip_and_handler() prototype, it's still widely used. Signed-off-by:
-
Darrick J. Wong authored
This patch breaks C-state discovery on my IBM IntelliStation Z30 because the return value of acpi_processor_get_power_info_fadt is not assigned to "result" in the case that acpi_processor_get_power_info_cst returns -ENODEV. Thus, if ACPI provides C-state data via the FADT and not _CST (as is the case on this machine), we incorrectly exit the function with -ENODEV after reading the FADT. The attached patch sets the value of result so that we don't exit early. Signed-off-by:
Darrick J. Wong <djwong@us.ibm.com> Acked-by:
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> Acked-by:
"Brown, Len" <len.brown@intel.com> Signed-off-by:
-
Randy Dunlap authored
Fix typo (repeated) in serial Kconfig. Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
When enabling the mmapper driver I got warnings because this "const" miscdevice structure is passed to function as non-const pointer; unlike struct tty_operations, however, I verified that misc_{de,}register _do_ modify their parameter, so this const attribute must be removed. Since the purpose of the change was to guarantee that no lock was needed, add a comment to prove this differently. Signed-off-by:Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Silence useless warning about undefined symbol in Kconfig. Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Freeing the stack is left uselessly to the caller of run_helper in some cases - this is taken from run_helper_thread, but here it is useless, so no caller needs it and the only place where this happens has a potential leak - in case of error neither run_helper() nor xterm_open() call free_stack(). At this point passing a pointer is not needed - the stack pointer should be passed directly, but this change is not done here. 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. Given the existence of options, it could be interesting to implement (additionally) "option required" - with it, Kconfig will refuse reading a .config file (from wherever it comes) if the given option is not set. With this, one could mark with it the option characteristic of the given architecture (it was an old proposal of Roman Zippel, when I pointed out our problem): config UML option required default y However this should be further discussed: *) for x86, it must support constructs like: ==arch/i386/Kconfig== config 64BIT option required default n where Kconfig must require that CONFIG_64BIT is disabled or not present in the read .config. *) do we want to do such checks only for the starting defconfig or also for .config? Which leads to: *) I may want to port a x86_64 .config to x86 and viceversa, or even among more different archs. Should that be allowed, and in which measure (the user may force skipping the check for a .config or it is only given a warning by default)? Cc: Roman Zippel <zippel@linux-m68k.org> Cc: <kbuild-devel@lists.sourceforge.net> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
CONFIG_MODE_TT does not work there, the UML_ prefixed version must be used - this causes a link-time failure when CONFIG_MODE_TT is enabled (i.e. always here, never by Jeff). Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Fix coding conventions violations is arch/um/os-Linux/helper.c. Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
user.h is too generic a header name. I've split out allocation routines from it. Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
I happened to notice that this code is a leftover and it should be removed - since there are sporadical efforts to revive the PPC port doing such cleanups is not useless. Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Fix cut'n'paste typo - &a and &b are used in other examples, in this one the doc uses &u and &v. Signed-off-by:
-
Jeff Dike authored
arch/um/sys-x86_64/ptrace.c:20:1: warning: "SC_SS" redefined In file included from arch/um/include/sysdep/ptrace.h:18, from include/asm/ptrace-generic.h:12, from include/asm/ptrace.h:15, from arch/um/sys-x86_64/ptrace.c:8: arch/um/include/sysdep/sc.h:38:1: warning: this is the location of the previous definition arch/um/sys-x86_64/ptrace.c: In function 'putreg': arch/um/sys-x86_64/ptrace.c:63: warning: implicit declaration of function 'SC_FS_BASE' arch/um/sys-x86_64/ptrace.c:63: error: invalid lvalue in unary '&' arch/um/sys-x86_64/ptrace.c:63: warning: implicit declaration of function 'SC_GS_BASE' arch/um/sys-x86_64/ptrace.c:63: error: invalid lvalue in unary '&' arch/um/sys-x86_64/ptrace.c: In function 'getreg': arch/um/sys-x86_64/ptrace.c:101: error: invalid lvalue in unary '&' arch/um/sys-x86_64/ptrace.c:101: error: invalid lvalue in unary '&' I'd have to say that the fix for this, for now, is this: Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
