PATCH: Fix SVM MSR indexes for 32bit kernel
Hi,
MSR index is 32bit not 64bit. All other MSR indexes are defined
without the ULL suffix. Otherwise, you will get
[EMAIL PROTECTED] tmp]$ cat foo.c
typedef unsigned long long u64;
int is_disabled(void)
{
u64 vm_cr;
do { unsigned long l__,h__; __asm__ __volatile__("rdmsr" : "=a" (l__),
"=d" (h__) : "c" (0xc0010114ULL)); vm_cr = l__; vm_cr |=
((u64)h__<<32); } while(0);
if (vm_cr & (1 << 4))
return 1;
return 0;
}
[EMAIL PROTECTED] tmp]$ gcc -m32 -S foo.c
foo.c: In function â_disabledâfoo.c:7: error: impossible register
constraint in âmâoo.c:12: confused by earlier errors, bailing out
[EMAIL PROTECTED] tmp]$
on 32bit. This patch removes the ULL suffix in SVM MSR indexes.
H.J.
--- linux-2.6.21.i686/drivers/kvm/svm.h.msr 2007-06-28 22:42:12.0
-0700
+++ linux-2.6.21.i686/drivers/kvm/svm.h 2007-06-29 08:03:09.0 -0700
@@ -175,8 +175,8 @@ struct __attribute__ ((__packed__)) vmcb
#define SVM_CPUID_FUNC 0x800a
#define MSR_EFER_SVME_MASK (1ULL << 12)
-#define MSR_VM_CR 0xc0010114ULL
-#define MSR_VM_HSAVE_PA 0xc0010117ULL
+#define MSR_VM_CR 0xc0010114
+#define MSR_VM_HSAVE_PA 0xc0010117
#define SVM_VM_CR_SVM_DISABLE 4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH: Fix SVM MSR indexes for 32bit kernel
Hi,
MSR index is 32bit not 64bit. All other MSR indexes are defined
without the ULL suffix. Otherwise, you will get
[EMAIL PROTECTED] tmp]$ cat foo.c
typedef unsigned long long u64;
int is_disabled(void)
{
u64 vm_cr;
do { unsigned long l__,h__; __asm__ __volatile__(rdmsr : =a (l__),
=d (h__) : c (0xc0010114ULL)); vm_cr = l__; vm_cr |=
((u64)h__32); } while(0);
if (vm_cr (1 4))
return 1;
return 0;
}
[EMAIL PROTECTED] tmp]$ gcc -m32 -S foo.c
foo.c: In function â_disabledâfoo.c:7: error: impossible register
constraint in âmâoo.c:12: confused by earlier errors, bailing out
[EMAIL PROTECTED] tmp]$
on 32bit. This patch removes the ULL suffix in SVM MSR indexes.
H.J.
--- linux-2.6.21.i686/drivers/kvm/svm.h.msr 2007-06-28 22:42:12.0
-0700
+++ linux-2.6.21.i686/drivers/kvm/svm.h 2007-06-29 08:03:09.0 -0700
@@ -175,8 +175,8 @@ struct __attribute__ ((__packed__)) vmcb
#define SVM_CPUID_FUNC 0x800a
#define MSR_EFER_SVME_MASK (1ULL 12)
-#define MSR_VM_CR 0xc0010114ULL
-#define MSR_VM_HSAVE_PA 0xc0010117ULL
+#define MSR_VM_CR 0xc0010114
+#define MSR_VM_HSAVE_PA 0xc0010117
#define SVM_VM_CR_SVM_DISABLE 4
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Change x86 prefix order
On Wed, Dec 06, 2006 at 06:52:39PM +0100, Mikael Pettersson wrote: > > If hardware x86 decoders (i.e., Intel or AMD processors) > get measurably faster with the new order, that would be > a good reason to change it. I was told that AMD processors had no preferences and Intel processors preferred the proposed order. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Change x86 prefix order
On Wed, Dec 06, 2006 at 08:43:17AM -0800, Randy Dunlap wrote: > On Tue, 5 Dec 2006 23:00:14 -0800 H. J. Lu wrote: > > > On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and > > LOCKREP_PREFIX isn't fixed. Currently, gas generates > > > > LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX > > > > I will check in a patch: > > > > http://sourceware.org/ml/binutils/2006-12/msg00054.html > > > > tomorrow and change gas to generate > > > > SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX > > Hi, > Could you provide a "why" for this in addition to the > "what", please? LOCKREP_PREFIX is also used as SIMD prefix. DATA_PREFIX can be used as either SIMD prefix or data size prefix for SIMD instructions. The new order SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX will make SIMD prefixes close to SIMD opcode. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Change x86 prefix order
On Wed, Dec 06, 2006 at 08:43:17AM -0800, Randy Dunlap wrote: On Tue, 5 Dec 2006 23:00:14 -0800 H. J. Lu wrote: On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and LOCKREP_PREFIX isn't fixed. Currently, gas generates LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX I will check in a patch: http://sourceware.org/ml/binutils/2006-12/msg00054.html tomorrow and change gas to generate SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX Hi, Could you provide a why for this in addition to the what, please? LOCKREP_PREFIX is also used as SIMD prefix. DATA_PREFIX can be used as either SIMD prefix or data size prefix for SIMD instructions. The new order SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX will make SIMD prefixes close to SIMD opcode. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Change x86 prefix order
On Wed, Dec 06, 2006 at 06:52:39PM +0100, Mikael Pettersson wrote: If hardware x86 decoders (i.e., Intel or AMD processors) get measurably faster with the new order, that would be a good reason to change it. I was told that AMD processors had no preferences and Intel processors preferred the proposed order. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Change x86 prefix order
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and LOCKREP_PREFIX isn't fixed. Currently, gas generates LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX I will check in a patch: http://sourceware.org/ml/binutils/2006-12/msg00054.html tomorrow and change gas to generate SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Change x86 prefix order
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and LOCKREP_PREFIX isn't fixed. Currently, gas generates LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX I will check in a patch: http://sourceware.org/ml/binutils/2006-12/msg00054.html tomorrow and change gas to generate SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm2 doesn't compile on xtensa
On Wed, Aug 24, 2005 at 01:10:35PM +0200, Adrian Bunk wrote:
> auxiliary-vector-cleanups.patch broke compilation on the xtensa
> architecture because it doesn't add an asm/auxvec.h on this
> architecture.
>
This added asm-frv/auxvec.h and asm-xtensa/auxvec.h.
H.J.
---
--- linux/include/asm-alpha/auxvec.h.auxv 2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-alpha/auxvec.h2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,24 @@
+#ifndef __ASM_ALPHA_AUXVEC_H
+#define __ASM_ALPHA_AUXVEC_H
+
+/* Reserve these numbers for any future use of a VDSO. */
+#if 0
+#define AT_SYSINFO 32
+#define AT_SYSINFO_EHDR33
+#endif
+
+/* More complete cache descriptions than AT_[DIU]CACHEBSIZE. If the
+ value is -1, then the cache doesn't exist. Otherwise:
+
+ bit 0-3: Cache set-associativity; 0 means fully associative.
+ bit 4-7: Log2 of cacheline size.
+ bit 8-31: Size of the entire cache >> 8.
+ bit 32-63: Reserved.
+*/
+
+#define AT_L1I_CACHESHAPE 34
+#define AT_L1D_CACHESHAPE 35
+#define AT_L2_CACHESHAPE 36
+#define AT_L3_CACHESHAPE 37
+
+#endif /* __ASM_ALPHA_AUXVEC_H */
--- linux/include/asm-alpha/elf.h.auxv 2005-03-01 23:38:09.0 -0800
+++ linux/include/asm-alpha/elf.h 2005-08-24 09:03:39.0 -0700
@@ -1,6 +1,8 @@
#ifndef __ASM_ALPHA_ELF_H
#define __ASM_ALPHA_ELF_H
+#include
+
/* Special values for the st_other field in the symbol table. */
#define STO_ALPHA_NOPV 0x80
@@ -142,26 +144,6 @@ extern int dump_elf_task_fp(elf_fpreg_t
: amask (AMASK_CIX) ? "ev6" : "ev67"); \
})
-/* Reserve these numbers for any future use of a VDSO. */
-#if 0
-#define AT_SYSINFO 32
-#define AT_SYSINFO_EHDR33
-#endif
-
-/* More complete cache descriptions than AT_[DIU]CACHEBSIZE. If the
- value is -1, then the cache doesn't exist. Otherwise:
-
- bit 0-3: Cache set-associativity; 0 means fully associative.
- bit 4-7: Log2 of cacheline size.
- bit 8-31: Size of the entire cache >> 8.
- bit 32-63: Reserved.
-*/
-
-#define AT_L1I_CACHESHAPE 34
-#define AT_L1D_CACHESHAPE 35
-#define AT_L2_CACHESHAPE 36
-#define AT_L3_CACHESHAPE 37
-
#ifdef __KERNEL__
#define SET_PERSONALITY(EX, IBCS2) \
--- linux/include/asm-arm/auxvec.h.auxv 2005-08-24 09:03:39.0 -0700
+++ linux/include/asm-arm/auxvec.h 2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMARM_AUXVEC_H
+#define __ASMARM_AUXVEC_H
+
+#endif
--- linux/include/asm-arm26/auxvec.h.auxv 2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-arm26/auxvec.h2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMARM_AUXVEC_H
+#define __ASMARM_AUXVEC_H
+
+#endif
--- linux/include/asm-cris/auxvec.h.auxv2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-cris/auxvec.h 2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMCRIS_AUXVEC_H
+#define __ASMCRIS_AUXVEC_H
+
+#endif
--- linux/include/asm-frv/auxvec.h.auxv 2005-08-24 09:05:17.0 -0700
+++ linux/include/asm-frv/auxvec.h 2005-08-24 09:05:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __FRV_AUXVEC_H
+#define __FRV_AUXVEC_H
+
+#endif
--- linux/include/asm-h8300/auxvec.h.auxv 2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-h8300/auxvec.h2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMH8300_AUXVEC_H
+#define __ASMH8300_AUXVEC_H
+
+#endif
--- linux/include/asm-i386/auxvec.h.auxv2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-i386/auxvec.h 2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,11 @@
+#ifndef __ASMi386_AUXVEC_H
+#define __ASMi386_AUXVEC_H
+
+/*
+ * Architecture-neutral AT_ values in 0-17, leave some room
+ * for more of them, start the x86-specific ones at 32.
+ */
+#define AT_SYSINFO 32
+#define AT_SYSINFO_EHDR33
+
+#endif
--- linux/include/asm-i386/elf.h.auxv 2005-03-01 23:38:13.0 -0800
+++ linux/include/asm-i386/elf.h2005-08-24 09:03:39.0 -0700
@@ -9,6 +9,7 @@
#include
#include
#include /* for savesegment */
+#include
#include
@@ -109,13 +110,6 @@ typedef struct user_fxsr_struct elf_fpxr
#define ELF_PLATFORM (system_utsname.machine)
-/*
- * Architecture-neutral AT_ values in 0-17, leave some room
- * for more of them, start the x86-specific ones at 32.
- */
-#define AT_SYSINFO 32
-#define AT_SYSINFO_EHDR33
-
#ifdef __KERNEL__
#define SET_PERSONALITY(ex, ibcs2) do { } while (0)
--- linux/include/asm-ia64/auxvec.h.auxv2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-ia64/auxvec.h 2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,11 @@
+#ifndef _ASM_IA64_AUXVEC_H
+#define _ASM_IA64_AUXVEC_H
+
+/*
+ * Architecture-neutral AT_ values are in the range 0-17. Leave some room for
more of
+ * them,
Re: 2.6.13-rc6-mm2 doesn't compile on xtensa
On Wed, Aug 24, 2005 at 01:10:35PM +0200, Adrian Bunk wrote:
auxiliary-vector-cleanups.patch broke compilation on the xtensa
architecture because it doesn't add an asm/auxvec.h on this
architecture.
This added asm-frv/auxvec.h and asm-xtensa/auxvec.h.
H.J.
---
--- linux/include/asm-alpha/auxvec.h.auxv 2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-alpha/auxvec.h2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,24 @@
+#ifndef __ASM_ALPHA_AUXVEC_H
+#define __ASM_ALPHA_AUXVEC_H
+
+/* Reserve these numbers for any future use of a VDSO. */
+#if 0
+#define AT_SYSINFO 32
+#define AT_SYSINFO_EHDR33
+#endif
+
+/* More complete cache descriptions than AT_[DIU]CACHEBSIZE. If the
+ value is -1, then the cache doesn't exist. Otherwise:
+
+ bit 0-3: Cache set-associativity; 0 means fully associative.
+ bit 4-7: Log2 of cacheline size.
+ bit 8-31: Size of the entire cache 8.
+ bit 32-63: Reserved.
+*/
+
+#define AT_L1I_CACHESHAPE 34
+#define AT_L1D_CACHESHAPE 35
+#define AT_L2_CACHESHAPE 36
+#define AT_L3_CACHESHAPE 37
+
+#endif /* __ASM_ALPHA_AUXVEC_H */
--- linux/include/asm-alpha/elf.h.auxv 2005-03-01 23:38:09.0 -0800
+++ linux/include/asm-alpha/elf.h 2005-08-24 09:03:39.0 -0700
@@ -1,6 +1,8 @@
#ifndef __ASM_ALPHA_ELF_H
#define __ASM_ALPHA_ELF_H
+#include asm/auxvec.h
+
/* Special values for the st_other field in the symbol table. */
#define STO_ALPHA_NOPV 0x80
@@ -142,26 +144,6 @@ extern int dump_elf_task_fp(elf_fpreg_t
: amask (AMASK_CIX) ? ev6 : ev67); \
})
-/* Reserve these numbers for any future use of a VDSO. */
-#if 0
-#define AT_SYSINFO 32
-#define AT_SYSINFO_EHDR33
-#endif
-
-/* More complete cache descriptions than AT_[DIU]CACHEBSIZE. If the
- value is -1, then the cache doesn't exist. Otherwise:
-
- bit 0-3: Cache set-associativity; 0 means fully associative.
- bit 4-7: Log2 of cacheline size.
- bit 8-31: Size of the entire cache 8.
- bit 32-63: Reserved.
-*/
-
-#define AT_L1I_CACHESHAPE 34
-#define AT_L1D_CACHESHAPE 35
-#define AT_L2_CACHESHAPE 36
-#define AT_L3_CACHESHAPE 37
-
#ifdef __KERNEL__
#define SET_PERSONALITY(EX, IBCS2) \
--- linux/include/asm-arm/auxvec.h.auxv 2005-08-24 09:03:39.0 -0700
+++ linux/include/asm-arm/auxvec.h 2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMARM_AUXVEC_H
+#define __ASMARM_AUXVEC_H
+
+#endif
--- linux/include/asm-arm26/auxvec.h.auxv 2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-arm26/auxvec.h2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMARM_AUXVEC_H
+#define __ASMARM_AUXVEC_H
+
+#endif
--- linux/include/asm-cris/auxvec.h.auxv2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-cris/auxvec.h 2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMCRIS_AUXVEC_H
+#define __ASMCRIS_AUXVEC_H
+
+#endif
--- linux/include/asm-frv/auxvec.h.auxv 2005-08-24 09:05:17.0 -0700
+++ linux/include/asm-frv/auxvec.h 2005-08-24 09:05:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __FRV_AUXVEC_H
+#define __FRV_AUXVEC_H
+
+#endif
--- linux/include/asm-h8300/auxvec.h.auxv 2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-h8300/auxvec.h2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMH8300_AUXVEC_H
+#define __ASMH8300_AUXVEC_H
+
+#endif
--- linux/include/asm-i386/auxvec.h.auxv2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-i386/auxvec.h 2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,11 @@
+#ifndef __ASMi386_AUXVEC_H
+#define __ASMi386_AUXVEC_H
+
+/*
+ * Architecture-neutral AT_ values in 0-17, leave some room
+ * for more of them, start the x86-specific ones at 32.
+ */
+#define AT_SYSINFO 32
+#define AT_SYSINFO_EHDR33
+
+#endif
--- linux/include/asm-i386/elf.h.auxv 2005-03-01 23:38:13.0 -0800
+++ linux/include/asm-i386/elf.h2005-08-24 09:03:39.0 -0700
@@ -9,6 +9,7 @@
#include asm/user.h
#include asm/processor.h
#include asm/system.h/* for savesegment */
+#include asm/auxvec.h
#include linux/utsname.h
@@ -109,13 +110,6 @@ typedef struct user_fxsr_struct elf_fpxr
#define ELF_PLATFORM (system_utsname.machine)
-/*
- * Architecture-neutral AT_ values in 0-17, leave some room
- * for more of them, start the x86-specific ones at 32.
- */
-#define AT_SYSINFO 32
-#define AT_SYSINFO_EHDR33
-
#ifdef __KERNEL__
#define SET_PERSONALITY(ex, ibcs2) do { } while (0)
--- linux/include/asm-ia64/auxvec.h.auxv2005-08-24 09:03:39.0
-0700
+++ linux/include/asm-ia64/auxvec.h 2005-08-24 09:03:39.0 -0700
@@ -0,0 +1,11 @@
+#ifndef _ASM_IA64_AUXVEC_H
+#define _ASM_IA64_AUXVEC_H
+
+/*
+ * Architecture-neutral AT_ values
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
On Tue, Jul 26, 2005 at 10:06:37PM -0700, Andrew Morton wrote: > "H. J. Lu" <[EMAIL PROTECTED]> wrote: > > > > On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote: > > > "H. J. Lu" <[EMAIL PROTECTED]> wrote: > > > > > > > > My patch breaks x86_64 build. This patch will fix x86_64 build. I am > > > > also enclosing the updated full patch. > > > > > > It now breaks ppc64 > > > > > > include/asm/elf.h: In function `dump_task_regs': > > > include/asm/elf.h:177: error: dereferencing pointer to incomplete type > > > > > > That's because pt_regs isn't known, because sched.h is including elf.h > > > before pt_regs gets defined. This is a pretty fragile area I'm afraid. > > > > Should we creat a new header file like auxvector.h? Auxiliary isn't > > ELF specific anyway. > > That would work. How about this patch? H.J. --- linux/include/asm-alpha/auxvec.h.auxv 2005-07-27 11:34:19.226937310 -0700 +++ linux/include/asm-alpha/auxvec.h2005-07-27 11:34:19.227937145 -0700 @@ -0,0 +1,24 @@ +#ifndef __ASM_ALPHA_AUXVEC_H +#define __ASM_ALPHA_AUXVEC_H + +/* Reserve these numbers for any future use of a VDSO. */ +#if 0 +#define AT_SYSINFO 32 +#define AT_SYSINFO_EHDR33 +#endif + +/* More complete cache descriptions than AT_[DIU]CACHEBSIZE. If the + value is -1, then the cache doesn't exist. Otherwise: + + bit 0-3: Cache set-associativity; 0 means fully associative. + bit 4-7: Log2 of cacheline size. + bit 8-31: Size of the entire cache >> 8. + bit 32-63: Reserved. +*/ + +#define AT_L1I_CACHESHAPE 34 +#define AT_L1D_CACHESHAPE 35 +#define AT_L2_CACHESHAPE 36 +#define AT_L3_CACHESHAPE 37 + +#endif /* __ASM_ALPHA_AUXVEC_H */ --- linux/include/asm-alpha/elf.h.auxv 2005-03-01 23:38:09.0 -0800 +++ linux/include/asm-alpha/elf.h 2005-07-27 11:34:19.227937145 -0700 @@ -1,6 +1,8 @@ #ifndef __ASM_ALPHA_ELF_H #define __ASM_ALPHA_ELF_H +#include + /* Special values for the st_other field in the symbol table. */ #define STO_ALPHA_NOPV 0x80 @@ -142,26 +144,6 @@ extern int dump_elf_task_fp(elf_fpreg_t : amask (AMASK_CIX) ? "ev6" : "ev67"); \ }) -/* Reserve these numbers for any future use of a VDSO. */ -#if 0 -#define AT_SYSINFO 32 -#define AT_SYSINFO_EHDR33 -#endif - -/* More complete cache descriptions than AT_[DIU]CACHEBSIZE. If the - value is -1, then the cache doesn't exist. Otherwise: - - bit 0-3: Cache set-associativity; 0 means fully associative. - bit 4-7: Log2 of cacheline size. - bit 8-31: Size of the entire cache >> 8. - bit 32-63: Reserved. -*/ - -#define AT_L1I_CACHESHAPE 34 -#define AT_L1D_CACHESHAPE 35 -#define AT_L2_CACHESHAPE 36 -#define AT_L3_CACHESHAPE 37 - #ifdef __KERNEL__ #define SET_PERSONALITY(EX, IBCS2) \ --- linux/include/asm-arm/auxvec.h.auxv 2005-07-27 11:34:19.228936980 -0700 +++ linux/include/asm-arm/auxvec.h 2005-07-27 11:34:19.228936980 -0700 @@ -0,0 +1,4 @@ +#ifndef __ASMARM_AUXVEC_H +#define __ASMARM_AUXVEC_H + +#endif --- linux/include/asm-arm26/auxvec.h.auxv 2005-07-27 11:34:19.229936815 -0700 +++ linux/include/asm-arm26/auxvec.h2005-07-27 11:34:19.229936815 -0700 @@ -0,0 +1,4 @@ +#ifndef __ASMARM_AUXVEC_H +#define __ASMARM_AUXVEC_H + +#endif --- linux/include/asm-cris/auxvec.h.auxv2005-07-27 11:34:19.229936815 -0700 +++ linux/include/asm-cris/auxvec.h 2005-07-27 11:34:19.229936815 -0700 @@ -0,0 +1,4 @@ +#ifndef __ASMCRIS_AUXVEC_H +#define __ASMCRIS_AUXVEC_H + +#endif --- linux/include/asm-h8300/auxvec.h.auxv 2005-07-27 11:34:19.230936650 -0700 +++ linux/include/asm-h8300/auxvec.h2005-07-27 11:34:19.230936650 -0700 @@ -0,0 +1,4 @@ +#ifndef __ASMH8300_AUXVEC_H +#define __ASMH8300_AUXVEC_H + +#endif --- linux/include/asm-i386/auxvec.h.auxv2005-07-27 11:34:19.230936650 -0700 +++ linux/include/asm-i386/auxvec.h 2005-07-27 11:34:19.230936650 -0700 @@ -0,0 +1,11 @@ +#ifndef __ASMi386_AUXVEC_H +#define __ASMi386_AUXVEC_H + +/* + * Architecture-neutral AT_ values in 0-17, leave some room + * for more of them, start the x86-specific ones at 32. + */ +#define AT_SYSINFO 32 +#define AT_SYSINFO_EHDR33 + +#endif --- linux/include/asm-i386/elf.h.auxv 2005-03-01 23:38:13.0 -0800 +++ linux/include/asm-i386/elf.h2005-07-27 11:36:26.558940660 -0700 @@ -9,6 +9,7 @@ #include #include #include /* for savesegment */ +#include #include @@ -109,13 +110,6 @@ typedef struct user_fxsr_struct elf_fpxr #define ELF_PLATFORM (system_utsname.machine) -/* - * Architecture-neutral AT_ values in 0-17, leave so
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
On Tue, Jul 26, 2005 at 10:06:37PM -0700, Andrew Morton wrote:
H. J. Lu [EMAIL PROTECTED] wrote:
On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote:
H. J. Lu [EMAIL PROTECTED] wrote:
My patch breaks x86_64 build. This patch will fix x86_64 build. I am
also enclosing the updated full patch.
It now breaks ppc64
include/asm/elf.h: In function `dump_task_regs':
include/asm/elf.h:177: error: dereferencing pointer to incomplete type
That's because pt_regs isn't known, because sched.h is including elf.h
before pt_regs gets defined. This is a pretty fragile area I'm afraid.
Should we creat a new header file like auxvector.h? Auxiliary isn't
ELF specific anyway.
That would work.
How about this patch?
H.J.
--- linux/include/asm-alpha/auxvec.h.auxv 2005-07-27 11:34:19.226937310
-0700
+++ linux/include/asm-alpha/auxvec.h2005-07-27 11:34:19.227937145 -0700
@@ -0,0 +1,24 @@
+#ifndef __ASM_ALPHA_AUXVEC_H
+#define __ASM_ALPHA_AUXVEC_H
+
+/* Reserve these numbers for any future use of a VDSO. */
+#if 0
+#define AT_SYSINFO 32
+#define AT_SYSINFO_EHDR33
+#endif
+
+/* More complete cache descriptions than AT_[DIU]CACHEBSIZE. If the
+ value is -1, then the cache doesn't exist. Otherwise:
+
+ bit 0-3: Cache set-associativity; 0 means fully associative.
+ bit 4-7: Log2 of cacheline size.
+ bit 8-31: Size of the entire cache 8.
+ bit 32-63: Reserved.
+*/
+
+#define AT_L1I_CACHESHAPE 34
+#define AT_L1D_CACHESHAPE 35
+#define AT_L2_CACHESHAPE 36
+#define AT_L3_CACHESHAPE 37
+
+#endif /* __ASM_ALPHA_AUXVEC_H */
--- linux/include/asm-alpha/elf.h.auxv 2005-03-01 23:38:09.0 -0800
+++ linux/include/asm-alpha/elf.h 2005-07-27 11:34:19.227937145 -0700
@@ -1,6 +1,8 @@
#ifndef __ASM_ALPHA_ELF_H
#define __ASM_ALPHA_ELF_H
+#include asm/auxvec.h
+
/* Special values for the st_other field in the symbol table. */
#define STO_ALPHA_NOPV 0x80
@@ -142,26 +144,6 @@ extern int dump_elf_task_fp(elf_fpreg_t
: amask (AMASK_CIX) ? ev6 : ev67); \
})
-/* Reserve these numbers for any future use of a VDSO. */
-#if 0
-#define AT_SYSINFO 32
-#define AT_SYSINFO_EHDR33
-#endif
-
-/* More complete cache descriptions than AT_[DIU]CACHEBSIZE. If the
- value is -1, then the cache doesn't exist. Otherwise:
-
- bit 0-3: Cache set-associativity; 0 means fully associative.
- bit 4-7: Log2 of cacheline size.
- bit 8-31: Size of the entire cache 8.
- bit 32-63: Reserved.
-*/
-
-#define AT_L1I_CACHESHAPE 34
-#define AT_L1D_CACHESHAPE 35
-#define AT_L2_CACHESHAPE 36
-#define AT_L3_CACHESHAPE 37
-
#ifdef __KERNEL__
#define SET_PERSONALITY(EX, IBCS2) \
--- linux/include/asm-arm/auxvec.h.auxv 2005-07-27 11:34:19.228936980 -0700
+++ linux/include/asm-arm/auxvec.h 2005-07-27 11:34:19.228936980 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMARM_AUXVEC_H
+#define __ASMARM_AUXVEC_H
+
+#endif
--- linux/include/asm-arm26/auxvec.h.auxv 2005-07-27 11:34:19.229936815
-0700
+++ linux/include/asm-arm26/auxvec.h2005-07-27 11:34:19.229936815 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMARM_AUXVEC_H
+#define __ASMARM_AUXVEC_H
+
+#endif
--- linux/include/asm-cris/auxvec.h.auxv2005-07-27 11:34:19.229936815
-0700
+++ linux/include/asm-cris/auxvec.h 2005-07-27 11:34:19.229936815 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMCRIS_AUXVEC_H
+#define __ASMCRIS_AUXVEC_H
+
+#endif
--- linux/include/asm-h8300/auxvec.h.auxv 2005-07-27 11:34:19.230936650
-0700
+++ linux/include/asm-h8300/auxvec.h2005-07-27 11:34:19.230936650 -0700
@@ -0,0 +1,4 @@
+#ifndef __ASMH8300_AUXVEC_H
+#define __ASMH8300_AUXVEC_H
+
+#endif
--- linux/include/asm-i386/auxvec.h.auxv2005-07-27 11:34:19.230936650
-0700
+++ linux/include/asm-i386/auxvec.h 2005-07-27 11:34:19.230936650 -0700
@@ -0,0 +1,11 @@
+#ifndef __ASMi386_AUXVEC_H
+#define __ASMi386_AUXVEC_H
+
+/*
+ * Architecture-neutral AT_ values in 0-17, leave some room
+ * for more of them, start the x86-specific ones at 32.
+ */
+#define AT_SYSINFO 32
+#define AT_SYSINFO_EHDR33
+
+#endif
--- linux/include/asm-i386/elf.h.auxv 2005-03-01 23:38:13.0 -0800
+++ linux/include/asm-i386/elf.h2005-07-27 11:36:26.558940660 -0700
@@ -9,6 +9,7 @@
#include asm/user.h
#include asm/processor.h
#include asm/system.h/* for savesegment */
+#include asm/auxvec.h
#include linux/utsname.h
@@ -109,13 +110,6 @@ typedef struct user_fxsr_struct elf_fpxr
#define ELF_PLATFORM (system_utsname.machine)
-/*
- * Architecture-neutral AT_ values in 0-17, leave some room
- * for more of them, start the x86-specific ones at 32.
- */
-#define AT_SYSINFO 32
-#define AT_SYSINFO_EHDR33
-
#ifdef __KERNEL__
#define SET_PERSONALITY(ex, ibcs2) do { } while
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote: > "H. J. Lu" <[EMAIL PROTECTED]> wrote: > > > > My patch breaks x86_64 build. This patch will fix x86_64 build. I am > > also enclosing the updated full patch. > > It now breaks ppc64 > > include/asm/elf.h: In function `dump_task_regs': > include/asm/elf.h:177: error: dereferencing pointer to incomplete type > > That's because pt_regs isn't known, because sched.h is including elf.h > before pt_regs gets defined. This is a pretty fragile area I'm afraid. Should we creat a new header file like auxvector.h? Auxiliary isn't ELF specific anyway. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
On Tue, Jul 26, 2005 at 02:46:20PM -0700, [EMAIL PROTECTED] wrote:
>
> The patch titled
>
> Define auxiliary vector size, AT_VECTOR_SIZE
>
> has been added to the -mm tree. Its filename is
>
> define-auxiliary-vector-size-at_vector_size.patch
>
> Patches currently in -mm which might be from [EMAIL PROTECTED] are
>
> define-auxiliary-vector-size-at_vector_size.patch
>
>
My patch breaks x86_64 build. This patch will fix x86_64 build. I am
also enclosing the updated full patch.
H.J.
--- linux/arch/x86_64/ia32/ia32_binfmt.c.auxv 2005-07-08 11:50:04.0
-0700
+++ linux/arch/x86_64/ia32/ia32_binfmt.c2005-07-26 16:13:58.312017331
-0700
@@ -9,6 +9,7 @@
#include
#include
#include
+#define __ASM_X86_64_ELF_H 1
#include
#include
#include
@@ -181,10 +182,7 @@ struct elf_prpsinfo
#define user user32
-#define __ASM_X86_64_ELF_H 1
#define elf_read_implies_exec(ex, have_pt_gnu_stack) (!(have_pt_gnu_stack))
-//#include
-#include
typedef struct user_i387_ia32_struct elf_fpregset_t;
typedef struct user32_fxsr_struct elf_fpxregset_t;
--- linux/arch/x86_64/ia32/ia32_binfmt.c.auxv 2005-07-08 11:50:04.0
-0700
+++ linux/arch/x86_64/ia32/ia32_binfmt.c2005-07-26 16:13:58.312017331
-0700
@@ -9,6 +9,7 @@
#include
#include
#include
+#define __ASM_X86_64_ELF_H 1
#include
#include
#include
@@ -181,10 +182,7 @@ struct elf_prpsinfo
#define user user32
-#define __ASM_X86_64_ELF_H 1
#define elf_read_implies_exec(ex, have_pt_gnu_stack) (!(have_pt_gnu_stack))
-//#include
-#include
typedef struct user_i387_ia32_struct elf_fpregset_t;
typedef struct user32_fxsr_struct elf_fpxregset_t;
--- linux/include/linux/elf.h.auxv 2005-03-01 23:37:49.0 -0800
+++ linux/include/linux/elf.h 2005-07-26 16:13:24.185651900 -0700
@@ -181,6 +181,8 @@ typedef __s64 Elf64_Sxword;
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_VECTOR_SIZE 42 /* Size of auxiliary table. */
+
typedef struct dynamic{
Elf32_Sword d_tag;
union{
--- linux/include/linux/sched.h.auxv2005-07-08 11:50:09.0 -0700
+++ linux/include/linux/sched.h 2005-07-26 16:13:24.204648764 -0700
@@ -35,6 +35,8 @@
#include
#include
+#include /* For AT_VECTOR_SIZE */
+
struct exec_domain;
/*
@@ -243,7 +245,7 @@ struct mm_struct {
mm_counter_t _rss;
mm_counter_t _anon_rss;
- unsigned long saved_auxv[42]; /* for /proc/PID/auxv */
+ unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */
unsigned dumpable:1;
cpumask_t cpu_vm_mask;
PATCH: Define auxiliary vector size, AT_VECTOR_SIZE
The size of auxiliary vector is fixed at 42 in linux/sched.h. But
it isn't very obvious when looking at linux/elf.h. This patch adds
AT_VECTOR_SIZE so that we can change it if necessary when a new
vector is added.
H.J.
--- linux/include/linux/elf.h.auxv 2004-10-18 14:53:22.0 -0700
+++ linux/include/linux/elf.h 2005-07-26 10:39:26.0 -0700
@@ -178,6 +178,8 @@ typedef __s64 Elf64_Sxword;
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_VECTOR_SIZE 42 /* Size of auxiliary table. */
+
typedef struct dynamic{
Elf32_Sword d_tag;
union{
--- linux/include/linux/sched.h.auxv2005-07-19 09:01:33.0 -0700
+++ linux/include/linux/sched.h 2005-07-26 10:41:08.0 -0700
@@ -30,6 +30,8 @@
#include
#include
+#include /* For AT_VECTOR_SIZE */
+
struct exec_domain;
extern int exec_shield;
extern int exec_shield_randomize;
@@ -238,7 +240,7 @@ struct mm_struct {
unsigned long rss, anon_rss, total_vm, locked_vm, shared_vm;
unsigned long exec_vm, stack_vm, reserved_vm, def_flags;
- unsigned long saved_auxv[42]; /* for /proc/PID/auxv */
+ unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */
unsigned dumpable:2;
cpumask_t cpu_vm_mask;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH: Define auxiliary vector size, AT_VECTOR_SIZE
The size of auxiliary vector is fixed at 42 in linux/sched.h. But
it isn't very obvious when looking at linux/elf.h. This patch adds
AT_VECTOR_SIZE so that we can change it if necessary when a new
vector is added.
H.J.
--- linux/include/linux/elf.h.auxv 2004-10-18 14:53:22.0 -0700
+++ linux/include/linux/elf.h 2005-07-26 10:39:26.0 -0700
@@ -178,6 +178,8 @@ typedef __s64 Elf64_Sxword;
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_VECTOR_SIZE 42 /* Size of auxiliary table. */
+
typedef struct dynamic{
Elf32_Sword d_tag;
union{
--- linux/include/linux/sched.h.auxv2005-07-19 09:01:33.0 -0700
+++ linux/include/linux/sched.h 2005-07-26 10:41:08.0 -0700
@@ -30,6 +30,8 @@
#include linux/pid.h
#include linux/percpu.h
+#include linux/elf.h /* For AT_VECTOR_SIZE */
+
struct exec_domain;
extern int exec_shield;
extern int exec_shield_randomize;
@@ -238,7 +240,7 @@ struct mm_struct {
unsigned long rss, anon_rss, total_vm, locked_vm, shared_vm;
unsigned long exec_vm, stack_vm, reserved_vm, def_flags;
- unsigned long saved_auxv[42]; /* for /proc/PID/auxv */
+ unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */
unsigned dumpable:2;
cpumask_t cpu_vm_mask;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
On Tue, Jul 26, 2005 at 02:46:20PM -0700, [EMAIL PROTECTED] wrote:
The patch titled
Define auxiliary vector size, AT_VECTOR_SIZE
has been added to the -mm tree. Its filename is
define-auxiliary-vector-size-at_vector_size.patch
Patches currently in -mm which might be from [EMAIL PROTECTED] are
define-auxiliary-vector-size-at_vector_size.patch
My patch breaks x86_64 build. This patch will fix x86_64 build. I am
also enclosing the updated full patch.
H.J.
--- linux/arch/x86_64/ia32/ia32_binfmt.c.auxv 2005-07-08 11:50:04.0
-0700
+++ linux/arch/x86_64/ia32/ia32_binfmt.c2005-07-26 16:13:58.312017331
-0700
@@ -9,6 +9,7 @@
#include linux/config.h
#include linux/stddef.h
#include linux/rwsem.h
+#define __ASM_X86_64_ELF_H 1
#include linux/sched.h
#include linux/compat.h
#include linux/string.h
@@ -181,10 +182,7 @@ struct elf_prpsinfo
#define user user32
-#define __ASM_X86_64_ELF_H 1
#define elf_read_implies_exec(ex, have_pt_gnu_stack) (!(have_pt_gnu_stack))
-//#include asm/ia32.h
-#include linux/elf.h
typedef struct user_i387_ia32_struct elf_fpregset_t;
typedef struct user32_fxsr_struct elf_fpxregset_t;
--- linux/arch/x86_64/ia32/ia32_binfmt.c.auxv 2005-07-08 11:50:04.0
-0700
+++ linux/arch/x86_64/ia32/ia32_binfmt.c2005-07-26 16:13:58.312017331
-0700
@@ -9,6 +9,7 @@
#include linux/config.h
#include linux/stddef.h
#include linux/rwsem.h
+#define __ASM_X86_64_ELF_H 1
#include linux/sched.h
#include linux/compat.h
#include linux/string.h
@@ -181,10 +182,7 @@ struct elf_prpsinfo
#define user user32
-#define __ASM_X86_64_ELF_H 1
#define elf_read_implies_exec(ex, have_pt_gnu_stack) (!(have_pt_gnu_stack))
-//#include asm/ia32.h
-#include linux/elf.h
typedef struct user_i387_ia32_struct elf_fpregset_t;
typedef struct user32_fxsr_struct elf_fpxregset_t;
--- linux/include/linux/elf.h.auxv 2005-03-01 23:37:49.0 -0800
+++ linux/include/linux/elf.h 2005-07-26 16:13:24.185651900 -0700
@@ -181,6 +181,8 @@ typedef __s64 Elf64_Sxword;
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_VECTOR_SIZE 42 /* Size of auxiliary table. */
+
typedef struct dynamic{
Elf32_Sword d_tag;
union{
--- linux/include/linux/sched.h.auxv2005-07-08 11:50:09.0 -0700
+++ linux/include/linux/sched.h 2005-07-26 16:13:24.204648764 -0700
@@ -35,6 +35,8 @@
#include linux/topology.h
#include linux/seccomp.h
+#include linux/elf.h /* For AT_VECTOR_SIZE */
+
struct exec_domain;
/*
@@ -243,7 +245,7 @@ struct mm_struct {
mm_counter_t _rss;
mm_counter_t _anon_rss;
- unsigned long saved_auxv[42]; /* for /proc/PID/auxv */
+ unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */
unsigned dumpable:1;
cpumask_t cpu_vm_mask;
Re: define-auxiliary-vector-size-at_vector_size.patch added to -mm tree
On Tue, Jul 26, 2005 at 09:53:23PM -0700, Andrew Morton wrote: H. J. Lu [EMAIL PROTECTED] wrote: My patch breaks x86_64 build. This patch will fix x86_64 build. I am also enclosing the updated full patch. It now breaks ppc64 include/asm/elf.h: In function `dump_task_regs': include/asm/elf.h:177: error: dereferencing pointer to incomplete type That's because pt_regs isn't known, because sched.h is including elf.h before pt_regs gets defined. This is a pretty fragile area I'm afraid. Should we creat a new header file like auxvector.h? Auxiliary isn't ELF specific anyway. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Thu, Mar 31, 2005 at 02:57:57AM +0200, Pau Aliagas wrote: > On Wed, 30 Mar 2005, H. J. Lu wrote: > > >>>That is what the assembler generates, and should have generated, for > >>>"movw %ds,(%eax)" since Nov. 4, 2004. > >> > >>Could this be the reason for the reported slowdown in the last six months? > > > >Can you elaborate? > > There's an unexplained slowdown of kernel 2.6 detailed in this thread: > http://kerneltrap.org/node/4940 > It is dated as "November 13, 2002 - 13:58". The assembler change was made on Nov. 4, 2004. I don't think they are related at all. > I don't want at all to justify it with the change you talk about in gas, > but maybe it is worth to check if it has anything to do with it. The > slowdown happened in this last six months. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Thu, Mar 31, 2005 at 12:18:55AM +0200, Pau Aliagas wrote: > On Wed, 30 Mar 2005, H. J. Lu wrote: > > >On Wed, Mar 30, 2005 at 07:57:28AM -0800, Linus Torvalds wrote: > > >>>There is no such an instruction of "movl %ds,(%eax)". The old assembler > >>>accepts it and turns it into "movw %ds,(%eax)". > >> > >>I disagree. Violently. As does the old assembler, which does not turn > >>"mov" into "movw" as you say. AT ALL. > > > >I should have made myself clear. By "movw %ds,(%eax)", I meant: > > > > 8c 18 movw %ds,(%eax) > > > >That is what the assembler generates, and should have generated, for > >"movw %ds,(%eax)" since Nov. 4, 2004. > > Could this be the reason for the reported slowdown in the last six months? > Can you elaborate? H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Wed, Mar 30, 2005 at 11:23:25AM -0500, linux-os wrote: > > So if there are any "movw (mem), %ds" and > "movw %ds, (mem)" in the code. The sizeof(mem) > needs to be 32-bits and the 'w' needs to be removed. > Otherwise, we are wasting CPU cycles and/or fooling > ourselves. GAS needs to continue to generate whatever > it was fed, with appropriate diagnostics if it > is fed the wrong stuff. FYI, gas hasn't generated 0x66 on "movw (%eax),%ds" for a long time and started doing it on "movw %ds,(%eax)" since Nov. 4, 2004. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Wed, Mar 30, 2005 at 07:57:28AM -0800, Linus Torvalds wrote: > > [ binutils and libc back in the discussion - I don't know why they got > dropped ] Removing glibc since it accesses segment register with proper instructions. > > On Tue, 29 Mar 2005, H. J. Lu wrote: > > > > There is no such an instruction of "movl %ds,(%eax)". The old assembler > > accepts it and turns it into "movw %ds,(%eax)". > > I disagree. Violently. As does the old assembler, which does not turn > "mov" into "movw" as you say. AT ALL. I should have made myself clear. By "movw %ds,(%eax)", I meant: 8c 18 movw %ds,(%eax) That is what the assembler generates, and should have generated, for "movw %ds,(%eax)" since Nov. 4, 2004. > > A "movw" has a 0x66 prefix. The assembler agree with me. Plain logic > agrees with me. Being consistent _also_ agrees with me (it's the same damn > instruction to move to a register, for chrissake!) This is a bug in asssembler and has been fixed on Nov. 4, 2004. If you want the 0x66 prefix for "movw %ds,(%eax)", you need to use "word movw %ds,(%eax)" with the new assembler. > > The fact is, every single "mov" instruction takes the size hint, and it > HAS MEANING, even if the meaning is only about performance, not about > semantics. In other words, yes, in the specific case of "mov segment to > memory", it ends up being only a performance hit, but as such IT DOES HAVE > MEANING. And in fact, even if it didn't end up having any meaning at all, > it's still a good idea as just a consistency issue. Accessing segment register is a very special case. It has been treated differently by gas. Try "movw (%eax),%ds" with your gas. Gas doesn't generate 0x66. The "movw %ds,(%eax)" bug was fixed last year. > If you think people should use just "mov", then fine, let people use I only suggested "mov" for old assemblers. > "mov". That's their choice - the same way you can write just "or $5,%eax" > and gas will pick the 32-bit version based on the register name, yes, you > should be able to write just "mov %fs,mem", and gas will pick whatever > version using its heuristics for the size (in this case the 32-bit, since > it does the same thing and is smaller and faster). > > And "mov" has always worked. The kernel just doesn't use it much, because > the kernel - for good historical reasons - doesn't trust gas to pick sizes > of instructions automagically. > > And the fact that it is obvious that gas _should_ pick the 32-bit format > of the instruction when you do not specify a size does NOT MEAN that it's > wrong to specify the size explicitly. > > And your arguments that there is no semantic difference between the 16-bit > and the 32-bit version IS MEANINGLESS. An assembler shouldn't care. This For segment register access, there is no 16-bit nor 32-bit version. There is only one version. > is not an argument about semantic difference. This is an argument over a > user wanting to make the size explicit, to DOCUMENT it. Are you suggesting that gas should put back 0x66 for both "movw %ds,(%eax)" and "movw (%eax),%ds"? > > The fact is, if users use "movl" and "movw" explicitly (and the kernel has > traditionally been _very_ careful to use all instruction sizes explicitly, > partly exactly because gas itself has been very happy-go-lucky about > them), then that is a GOOD THING. It means that the instruction is > well-defined to somebody who knows the x86 instruction set, and he never > needs to worry or use "objdump" to see if gas was being stupid and > generated the 16-bit version. Allowing "movl %ds,(%eax)" has a possibilty that people assume it will update 32bit memory location. That is how this issue was uncovered. If you really don't like "mov %ds,(%eax)" and want to support the old assembler, I can write a kernel patch to check asssembler to use "movl" for the old asssembler and "movw" for the new assembler. BTW, to report problems with assembler, there is http://www.sourceware.org/bugzilla/ Or I can be reached at [EMAIL PROTECTED] H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Wed, Mar 30, 2005 at 07:57:28AM -0800, Linus Torvalds wrote: [ binutils and libc back in the discussion - I don't know why they got dropped ] Removing glibc since it accesses segment register with proper instructions. On Tue, 29 Mar 2005, H. J. Lu wrote: There is no such an instruction of movl %ds,(%eax). The old assembler accepts it and turns it into movw %ds,(%eax). I disagree. Violently. As does the old assembler, which does not turn mov into movw as you say. AT ALL. I should have made myself clear. By movw %ds,(%eax), I meant: 8c 18 movw %ds,(%eax) That is what the assembler generates, and should have generated, for movw %ds,(%eax) since Nov. 4, 2004. A movw has a 0x66 prefix. The assembler agree with me. Plain logic agrees with me. Being consistent _also_ agrees with me (it's the same damn instruction to move to a register, for chrissake!) This is a bug in asssembler and has been fixed on Nov. 4, 2004. If you want the 0x66 prefix for movw %ds,(%eax), you need to use word movw %ds,(%eax) with the new assembler. The fact is, every single mov instruction takes the size hint, and it HAS MEANING, even if the meaning is only about performance, not about semantics. In other words, yes, in the specific case of mov segment to memory, it ends up being only a performance hit, but as such IT DOES HAVE MEANING. And in fact, even if it didn't end up having any meaning at all, it's still a good idea as just a consistency issue. Accessing segment register is a very special case. It has been treated differently by gas. Try movw (%eax),%ds with your gas. Gas doesn't generate 0x66. The movw %ds,(%eax) bug was fixed last year. If you think people should use just mov, then fine, let people use I only suggested mov for old assemblers. mov. That's their choice - the same way you can write just or $5,%eax and gas will pick the 32-bit version based on the register name, yes, you should be able to write just mov %fs,mem, and gas will pick whatever version using its heuristics for the size (in this case the 32-bit, since it does the same thing and is smaller and faster). And mov has always worked. The kernel just doesn't use it much, because the kernel - for good historical reasons - doesn't trust gas to pick sizes of instructions automagically. And the fact that it is obvious that gas _should_ pick the 32-bit format of the instruction when you do not specify a size does NOT MEAN that it's wrong to specify the size explicitly. And your arguments that there is no semantic difference between the 16-bit and the 32-bit version IS MEANINGLESS. An assembler shouldn't care. This For segment register access, there is no 16-bit nor 32-bit version. There is only one version. is not an argument about semantic difference. This is an argument over a user wanting to make the size explicit, to DOCUMENT it. Are you suggesting that gas should put back 0x66 for both movw %ds,(%eax) and movw (%eax),%ds? The fact is, if users use movl and movw explicitly (and the kernel has traditionally been _very_ careful to use all instruction sizes explicitly, partly exactly because gas itself has been very happy-go-lucky about them), then that is a GOOD THING. It means that the instruction is well-defined to somebody who knows the x86 instruction set, and he never needs to worry or use objdump to see if gas was being stupid and generated the 16-bit version. Allowing movl %ds,(%eax) has a possibilty that people assume it will update 32bit memory location. That is how this issue was uncovered. If you really don't like mov %ds,(%eax) and want to support the old assembler, I can write a kernel patch to check asssembler to use movl for the old asssembler and movw for the new assembler. BTW, to report problems with assembler, there is http://www.sourceware.org/bugzilla/ Or I can be reached at [EMAIL PROTECTED] H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Wed, Mar 30, 2005 at 11:23:25AM -0500, linux-os wrote: So if there are any movw (mem), %ds and movw %ds, (mem) in the code. The sizeof(mem) needs to be 32-bits and the 'w' needs to be removed. Otherwise, we are wasting CPU cycles and/or fooling ourselves. GAS needs to continue to generate whatever it was fed, with appropriate diagnostics if it is fed the wrong stuff. FYI, gas hasn't generated 0x66 on movw (%eax),%ds for a long time and started doing it on movw %ds,(%eax) since Nov. 4, 2004. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Thu, Mar 31, 2005 at 12:18:55AM +0200, Pau Aliagas wrote: On Wed, 30 Mar 2005, H. J. Lu wrote: On Wed, Mar 30, 2005 at 07:57:28AM -0800, Linus Torvalds wrote: There is no such an instruction of movl %ds,(%eax). The old assembler accepts it and turns it into movw %ds,(%eax). I disagree. Violently. As does the old assembler, which does not turn mov into movw as you say. AT ALL. I should have made myself clear. By movw %ds,(%eax), I meant: 8c 18 movw %ds,(%eax) That is what the assembler generates, and should have generated, for movw %ds,(%eax) since Nov. 4, 2004. Could this be the reason for the reported slowdown in the last six months? Can you elaborate? H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Thu, Mar 31, 2005 at 02:57:57AM +0200, Pau Aliagas wrote: On Wed, 30 Mar 2005, H. J. Lu wrote: That is what the assembler generates, and should have generated, for movw %ds,(%eax) since Nov. 4, 2004. Could this be the reason for the reported slowdown in the last six months? Can you elaborate? There's an unexplained slowdown of kernel 2.6 detailed in this thread: http://kerneltrap.org/node/4940 It is dated as November 13, 2002 - 13:58. The assembler change was made on Nov. 4, 2004. I don't think they are related at all. I don't want at all to justify it with the change you talk about in gas, but maybe it is worth to check if it has anything to do with it. The slowdown happened in this last six months. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Tue, Mar 29, 2005 at 06:44:18PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 29 Mar 2005, H. J. Lu wrote:
> >
> > > the smaller and faster version do not want to just rely on gas
> > > automatically getting it right, especially since gas has historically been
> > > very very bad at getting things right.
> >
> > We are fixing those issues in assembler. If people run into problems
> > like that with gas, they can report them. They will be fixed.
>
> It's fine if gas fixes things. It's not fine if gas breaks things that
> used to work, for no really good reason.
>
> > > What is the advantage of not allowing "movl %ds,mem"? Really? Especially
> > > since I suspect the kernel is pretty much the only one who does this, and
> > > the kernel really does do it on purpose. The kernel explicitly wants the
> > > 32-bit version, knowing that the upper bits are undefined.
> > >
> >
> > Kernel has
> >
> > unsigned gsindex;
> > asm volatile("movl %%gs,%0" : "=g" (gsindex));
>
> Ok, that's a real x86-64 bug, it seems. Andi, please fix, preferably by
> just making the "g" be a "r".
>
> However, your argument isn't very valid, since:
>
> > The new assembler will make sure that it won't happen.
>
> Not true, since the suggestion was just to change all segment "movl"
> things to "mov", at which point the same old bug is still there, and the
> assembler didn't really help us at all.
The new assembler won't accept
movl %gs,128(%rsp)
It makes it harder to generate binary code user doesn't tend. FWIW,
what I suggested are in
http://sourceware.org/ml/binutils/2005-03/msg00873.html
Thera are things like
- asm volatile("movl %%fs,%0" : "=g" (fsindex));
+ asm volatile("movl %%fs,%0" : "=r" (fsindex));
>
> See the problem? You're not actually protecting anything. The change just
> makes it _harder_ to make sizes explicit, and suddenly we have to trust an
> assembler to be clever about sizes, when that assembler historically has
> definitely _not_ been very clever about them at all.
>
There is no such an instruction of "movl %ds,(%eax)". The old assembler
accepts it and turns it into "movw %ds,(%eax)". It won't catch problems
like
unsigned fsindex;
asm volatile("movl %%fs,%0" : "=m" (fsindex));
The "movw %ds,(%eax)" bug was fixed in binutils 2.15.94.0.1. Gas no
longer generates 0x66 for it. If you find gas preventing you from doing
what the hardware supports, I will be happy to fix it.
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Tue, Mar 29, 2005 at 04:30:01PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 28 Mar 2005, Andi Kleen wrote:
> >
> > "H. J. Lu" <[EMAIL PROTECTED]> writes:
> > > The new assembler will disallow them since those instructions with
> > > memory operand will only use the first 16bits. If the memory operand
> > > is 16bit, you won't see any problems. But if the memory destinatin
> > > is 32bit, the upper 16bits may have random values. The new assembler
> >
> > Does it really have random values on existing x86 hardware?
>
> The upper bits are not written at all, so it's not random.
>
> > If it is a only a "theoretical" problem that does not happen
> > in practice I would advise to not do the change.
>
> My preference too. The reason we use "movl" is because we really do want
> the 32-bit versions, since they are faster. It's a conscious choice. In
> contrast "movw" generates bigger and slower code on all assemblers out
> there, and "mov" doesn't make it clear which one it is. Is it the slow
> one, or the fast one?
"mov" shouldn't generate the 0x66 prefix, at least with the assembler
since binutils 2.14.90.0.4 20030523. The assembler in CVS won't generate
0x66 for "movw" either.
> Now, those versions of gas may be so old that nobody cares, but the
> explicit size still is a GOOD THING. The size DOES MATTER. People who want
Suggesting "mov" instead of "movw" is for the existing assemblers. Or
kernel can check assembler version to decide if "movw" should be used.
I can verify the first Linux assembler which won't generate 0x66 for
"movw".
> the smaller and faster version do not want to just rely on gas
> automatically getting it right, especially since gas has historically been
> very very bad at getting things right.
We are fixing those issues in assembler. If people run into problems
like that with gas, they can report them. They will be fixed.
>
> What is the advantage of not allowing "movl %ds,mem"? Really? Especially
> since I suspect the kernel is pretty much the only one who does this, and
> the kernel really does do it on purpose. The kernel explicitly wants the
> 32-bit version, knowing that the upper bits are undefined.
>
Kernel has
unsigned gsindex;
asm volatile("movl %%gs,%0" : "=g" (gsindex));
...
if (gsindex)
It is OK if gcc never generates memory access like
movl %gs,0x128(%rsp)
Otherwise, the upper bits in gsindex are undefined. The new
assembler will make sure that it won't happen.
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH: i386/x86_64 segment register access update
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. I am enclosing patches for 2.4 and 2.6 kernels
here. The resulting kernel binaries should be unchanged as before, with
old and new assemblers, if gcc never generates memory access for
unsigned gsindex;
asm volatile("movl %%gs,%0" : "=g" (gsindex));
If gcc does generate memory access for the code above, the upper bits
in gsindex are undefined and the new assembler doesn't allow it.
H.J.
--- linux/arch/i386/kernel/apm.c.seg2005-03-27 13:10:45.0 -0800
+++ linux/arch/i386/kernel/apm.c2005-03-28 10:30:24.0 -0800
@@ -327,7 +327,7 @@ extern int (*console_blank_hook)(int);
* Save a segment register away
*/
#define savesegment(seg, where) \
- __asm__ __volatile__("movl %%" #seg ",%0" : "=m" (where))
+ __asm__ __volatile__("mov %%" #seg ",%0" : "=m" (where))
/*
* Maximum number of events stored
@@ -553,7 +553,7 @@ static inline void apm_restore_cpus(unsi
#ifdef APM_ZERO_SEGS
# define APM_DECL_SEGS \
- unsigned int saved_fs; unsigned int saved_gs;
+ unsigned short saved_fs; unsigned short saved_gs;
# define APM_DO_SAVE_SEGS \
savesegment(fs, saved_fs); savesegment(gs, saved_gs)
# define APM_DO_ZERO_SEGS \
--- linux/arch/i386/kernel/process.c.seg2005-03-27 13:10:45.0
-0800
+++ linux/arch/i386/kernel/process.c2005-03-28 10:30:24.0 -0800
@@ -544,7 +544,7 @@ void release_thread(struct task_struct *
* Save a segment.
*/
#define savesegment(seg,value) \
- asm volatile("movl %%" #seg ",%0":"=m" (*(int *)&(value)))
+ asm volatile("mov %%" #seg ",%0":"=m" (value))
int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
unsigned long unused,
@@ -661,8 +661,8 @@ void fastcall __switch_to(struct task_st
* Save away %fs and %gs. No need to save %es and %ds, as
* those are always kernel segments while inside the kernel.
*/
- asm volatile("movl %%fs,%0":"=m" (*(int *)>fs));
- asm volatile("movl %%gs,%0":"=m" (*(int *)>gs));
+ asm volatile("mov %%fs,%0":"=m" (prev->fs));
+ asm volatile("mov %%gs,%0":"=m" (prev->gs));
/*
* Restore %fs and %gs.
--- linux/arch/x86_64/kernel/process.c.seg 2005-03-27 13:10:51.0
-0800
+++ linux/arch/x86_64/kernel/process.c 2005-03-28 11:16:57.0 -0800
@@ -527,10 +527,10 @@ int copy_thread(int nr, unsigned long cl
p->thread.fs = me->thread.fs;
p->thread.gs = me->thread.gs;
- asm("movl %%gs,%0" : "=m" (p->thread.gsindex));
- asm("movl %%fs,%0" : "=m" (p->thread.fsindex));
- asm("movl %%es,%0" : "=m" (p->thread.es));
- asm("movl %%ds,%0" : "=m" (p->thread.ds));
+ asm("mov %%gs,%0" : "=m" (p->thread.gsindex));
+ asm("mov %%fs,%0" : "=m" (p->thread.fsindex));
+ asm("mov %%es,%0" : "=m" (p->thread.es));
+ asm("mov %%ds,%0" : "=m" (p->thread.ds));
unlazy_fpu(current);
p->thread.i387 = current->thread.i387;
@@ -575,11 +575,11 @@ struct task_struct *__switch_to(struct t
/*
* Switch DS and ES.
*/
- asm volatile("movl %%es,%0" : "=m" (prev->es));
+ asm volatile("mov %%es,%0" : "=m" (prev->es));
if (unlikely(next->es | prev->es))
loadsegment(es, next->es);
- asm volatile ("movl %%ds,%0" : "=m" (prev->ds));
+ asm volatile ("mov %%ds,%0" : "=m" (prev->ds));
if (unlikely(next->ds | prev->ds))
loadsegment(ds, next->ds);
@@ -588,7 +588,7 @@ struct task_struct *__switch_to(struct t
*/
{
unsigned fsindex;
- asm volatile("movl %%fs,%0" : "=g" (fsindex));
+ asm volatile("movl %%fs,%0" : "=r" (fsindex));
/* segment register != 0 always requires a reload.
also reload when it has changed.
when prev process used 64bit base always reload
@@ -609,7 +609,7 @@ struct task_struct *__switch_to(struct t
}
{
unsigned gsindex;
- asm volatile("movl %%gs,%0" : "=g" (gsindex));
+ asm volatile("movl %%gs,%0" : "=r" (gsindex));
if (unlikely((gsindex | next->gsindex) || prev->gs)) {
load_gs_index(next->gsindex);
if
PATCH: i386/x86_64 segment register access update
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. I am enclosing patches for 2.4 and 2.6 kernels
here. The resulting kernel binaries should be unchanged as before, with
old and new assemblers, if gcc never generates memory access for
unsigned gsindex;
asm volatile(movl %%gs,%0 : =g (gsindex));
If gcc does generate memory access for the code above, the upper bits
in gsindex are undefined and the new assembler doesn't allow it.
H.J.
--- linux/arch/i386/kernel/apm.c.seg2005-03-27 13:10:45.0 -0800
+++ linux/arch/i386/kernel/apm.c2005-03-28 10:30:24.0 -0800
@@ -327,7 +327,7 @@ extern int (*console_blank_hook)(int);
* Save a segment register away
*/
#define savesegment(seg, where) \
- __asm__ __volatile__(movl %% #seg ,%0 : =m (where))
+ __asm__ __volatile__(mov %% #seg ,%0 : =m (where))
/*
* Maximum number of events stored
@@ -553,7 +553,7 @@ static inline void apm_restore_cpus(unsi
#ifdef APM_ZERO_SEGS
# define APM_DECL_SEGS \
- unsigned int saved_fs; unsigned int saved_gs;
+ unsigned short saved_fs; unsigned short saved_gs;
# define APM_DO_SAVE_SEGS \
savesegment(fs, saved_fs); savesegment(gs, saved_gs)
# define APM_DO_ZERO_SEGS \
--- linux/arch/i386/kernel/process.c.seg2005-03-27 13:10:45.0
-0800
+++ linux/arch/i386/kernel/process.c2005-03-28 10:30:24.0 -0800
@@ -544,7 +544,7 @@ void release_thread(struct task_struct *
* Save a segment.
*/
#define savesegment(seg,value) \
- asm volatile(movl %% #seg ,%0:=m (*(int *)(value)))
+ asm volatile(mov %% #seg ,%0:=m (value))
int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
unsigned long unused,
@@ -661,8 +661,8 @@ void fastcall __switch_to(struct task_st
* Save away %fs and %gs. No need to save %es and %ds, as
* those are always kernel segments while inside the kernel.
*/
- asm volatile(movl %%fs,%0:=m (*(int *)prev-fs));
- asm volatile(movl %%gs,%0:=m (*(int *)prev-gs));
+ asm volatile(mov %%fs,%0:=m (prev-fs));
+ asm volatile(mov %%gs,%0:=m (prev-gs));
/*
* Restore %fs and %gs.
--- linux/arch/x86_64/kernel/process.c.seg 2005-03-27 13:10:51.0
-0800
+++ linux/arch/x86_64/kernel/process.c 2005-03-28 11:16:57.0 -0800
@@ -527,10 +527,10 @@ int copy_thread(int nr, unsigned long cl
p-thread.fs = me-thread.fs;
p-thread.gs = me-thread.gs;
- asm(movl %%gs,%0 : =m (p-thread.gsindex));
- asm(movl %%fs,%0 : =m (p-thread.fsindex));
- asm(movl %%es,%0 : =m (p-thread.es));
- asm(movl %%ds,%0 : =m (p-thread.ds));
+ asm(mov %%gs,%0 : =m (p-thread.gsindex));
+ asm(mov %%fs,%0 : =m (p-thread.fsindex));
+ asm(mov %%es,%0 : =m (p-thread.es));
+ asm(mov %%ds,%0 : =m (p-thread.ds));
unlazy_fpu(current);
p-thread.i387 = current-thread.i387;
@@ -575,11 +575,11 @@ struct task_struct *__switch_to(struct t
/*
* Switch DS and ES.
*/
- asm volatile(movl %%es,%0 : =m (prev-es));
+ asm volatile(mov %%es,%0 : =m (prev-es));
if (unlikely(next-es | prev-es))
loadsegment(es, next-es);
- asm volatile (movl %%ds,%0 : =m (prev-ds));
+ asm volatile (mov %%ds,%0 : =m (prev-ds));
if (unlikely(next-ds | prev-ds))
loadsegment(ds, next-ds);
@@ -588,7 +588,7 @@ struct task_struct *__switch_to(struct t
*/
{
unsigned fsindex;
- asm volatile(movl %%fs,%0 : =g (fsindex));
+ asm volatile(movl %%fs,%0 : =r (fsindex));
/* segment register != 0 always requires a reload.
also reload when it has changed.
when prev process used 64bit base always reload
@@ -609,7 +609,7 @@ struct task_struct *__switch_to(struct t
}
{
unsigned gsindex;
- asm volatile(movl %%gs,%0 : =g (gsindex));
+ asm volatile(movl %%gs,%0 : =r (gsindex));
if (unlikely((gsindex | next-gsindex) || prev-gs)) {
load_gs_index(next-gsindex);
if (gsindex)
--- linux/include/asm-i386/system.h.seg 2005-03-27 15:33:12.0 -0800
+++ linux/include/asm-i386/system.h 2005-03-28
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Tue, Mar 29, 2005 at 04:30:01PM -0800, Linus Torvalds wrote: On Mon, 28 Mar 2005, Andi Kleen wrote: H. J. Lu [EMAIL PROTECTED] writes: The new assembler will disallow them since those instructions with memory operand will only use the first 16bits. If the memory operand is 16bit, you won't see any problems. But if the memory destinatin is 32bit, the upper 16bits may have random values. The new assembler Does it really have random values on existing x86 hardware? The upper bits are not written at all, so it's not random. If it is a only a theoretical problem that does not happen in practice I would advise to not do the change. My preference too. The reason we use movl is because we really do want the 32-bit versions, since they are faster. It's a conscious choice. In contrast movw generates bigger and slower code on all assemblers out there, and mov doesn't make it clear which one it is. Is it the slow one, or the fast one? mov shouldn't generate the 0x66 prefix, at least with the assembler since binutils 2.14.90.0.4 20030523. The assembler in CVS won't generate 0x66 for movw either. Now, those versions of gas may be so old that nobody cares, but the explicit size still is a GOOD THING. The size DOES MATTER. People who want Suggesting mov instead of movw is for the existing assemblers. Or kernel can check assembler version to decide if movw should be used. I can verify the first Linux assembler which won't generate 0x66 for movw. the smaller and faster version do not want to just rely on gas automatically getting it right, especially since gas has historically been very very bad at getting things right. We are fixing those issues in assembler. If people run into problems like that with gas, they can report them. They will be fixed. What is the advantage of not allowing movl %ds,mem? Really? Especially since I suspect the kernel is pretty much the only one who does this, and the kernel really does do it on purpose. The kernel explicitly wants the 32-bit version, knowing that the upper bits are undefined. Kernel has unsigned gsindex; asm volatile(movl %%gs,%0 : =g (gsindex)); ... if (gsindex) It is OK if gcc never generates memory access like movl %gs,0x128(%rsp) Otherwise, the upper bits in gsindex are undefined. The new assembler will make sure that it won't happen. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Tue, Mar 29, 2005 at 06:44:18PM -0800, Linus Torvalds wrote: On Tue, 29 Mar 2005, H. J. Lu wrote: the smaller and faster version do not want to just rely on gas automatically getting it right, especially since gas has historically been very very bad at getting things right. We are fixing those issues in assembler. If people run into problems like that with gas, they can report them. They will be fixed. It's fine if gas fixes things. It's not fine if gas breaks things that used to work, for no really good reason. What is the advantage of not allowing movl %ds,mem? Really? Especially since I suspect the kernel is pretty much the only one who does this, and the kernel really does do it on purpose. The kernel explicitly wants the 32-bit version, knowing that the upper bits are undefined. Kernel has unsigned gsindex; asm volatile(movl %%gs,%0 : =g (gsindex)); Ok, that's a real x86-64 bug, it seems. Andi, please fix, preferably by just making the g be a r. However, your argument isn't very valid, since: The new assembler will make sure that it won't happen. Not true, since the suggestion was just to change all segment movl things to mov, at which point the same old bug is still there, and the assembler didn't really help us at all. The new assembler won't accept movl %gs,128(%rsp) It makes it harder to generate binary code user doesn't tend. FWIW, what I suggested are in http://sourceware.org/ml/binutils/2005-03/msg00873.html Thera are things like - asm volatile(movl %%fs,%0 : =g (fsindex)); + asm volatile(movl %%fs,%0 : =r (fsindex)); See the problem? You're not actually protecting anything. The change just makes it _harder_ to make sizes explicit, and suddenly we have to trust an assembler to be clever about sizes, when that assembler historically has definitely _not_ been very clever about them at all. There is no such an instruction of movl %ds,(%eax). The old assembler accepts it and turns it into movw %ds,(%eax). It won't catch problems like unsigned fsindex; asm volatile(movl %%fs,%0 : =m (fsindex)); The movw %ds,(%eax) bug was fixed in binutils 2.15.94.0.1. Gas no longer generates 0x66 for it. If you find gas preventing you from doing what the hardware supports, I will be happy to fix it. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Mon, Mar 28, 2005 at 09:46:00AM -0800, H. J. Lu wrote: > On Mon, Mar 28, 2005 at 05:47:06PM +0200, Andi Kleen wrote: > > "H. J. Lu" <[EMAIL PROTECTED]> writes: > > > The new assembler will disallow them since those instructions with > > > memory operand will only use the first 16bits. If the memory operand > > > is 16bit, you won't see any problems. But if the memory destinatin > > > is 32bit, the upper 16bits may have random values. The new assembler > > > > Does it really have random values on existing x86 hardware? > > The x86 hardwares will only change the first 16bits. The rest bits > are unchanged. A simple test program can verify that. > > > > > If it is a only a "theoretical" problem that does not happen > > in practice I would advise to not do the change. > > > > It depends on what the initial value in the upper bits is. The > assembler in CVS generates the same binary code as > > movw %ds,(%eax) > > for > > movl %ds,(%eax) > > But the previous assemblers will generate > > 66 8c 18 movw %ds,(%eax) > > for > > movw %ds,(%eax) > > This bug has been fixed for a while. I guess that may be why Linux > kernel uses > > movl %ds,(%eax) It turns out that both old and new assemblers will generate 0: 8c 18 movw %ds,(%eax) for mov %ds,(%eax) So kernel can use "mov" instead of "movl" and the binary output will be the same. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Mon, Mar 28, 2005 at 05:47:06PM +0200, Andi Kleen wrote: > "H. J. Lu" <[EMAIL PROTECTED]> writes: > > The new assembler will disallow them since those instructions with > > memory operand will only use the first 16bits. If the memory operand > > is 16bit, you won't see any problems. But if the memory destinatin > > is 32bit, the upper 16bits may have random values. The new assembler > > Does it really have random values on existing x86 hardware? The x86 hardwares will only change the first 16bits. The rest bits are unchanged. A simple test program can verify that. > > If it is a only a "theoretical" problem that does not happen > in practice I would advise to not do the change. > It depends on what the initial value in the upper bits is. The assembler in CVS generates the same binary code as movw %ds,(%eax) for movl %ds,(%eax) But the previous assemblers will generate 66 8c 18 movw %ds,(%eax) for movw %ds,(%eax) This bug has been fixed for a while. I guess that may be why Linux kernel uses movl %ds,(%eax) H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Mon, Mar 28, 2005 at 05:47:06PM +0200, Andi Kleen wrote: H. J. Lu [EMAIL PROTECTED] writes: The new assembler will disallow them since those instructions with memory operand will only use the first 16bits. If the memory operand is 16bit, you won't see any problems. But if the memory destinatin is 32bit, the upper 16bits may have random values. The new assembler Does it really have random values on existing x86 hardware? The x86 hardwares will only change the first 16bits. The rest bits are unchanged. A simple test program can verify that. If it is a only a theoretical problem that does not happen in practice I would advise to not do the change. It depends on what the initial value in the upper bits is. The assembler in CVS generates the same binary code as movw %ds,(%eax) for movl %ds,(%eax) But the previous assemblers will generate 66 8c 18 movw %ds,(%eax) for movw %ds,(%eax) This bug has been fixed for a while. I guess that may be why Linux kernel uses movl %ds,(%eax) H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
On Mon, Mar 28, 2005 at 09:46:00AM -0800, H. J. Lu wrote: On Mon, Mar 28, 2005 at 05:47:06PM +0200, Andi Kleen wrote: H. J. Lu [EMAIL PROTECTED] writes: The new assembler will disallow them since those instructions with memory operand will only use the first 16bits. If the memory operand is 16bit, you won't see any problems. But if the memory destinatin is 32bit, the upper 16bits may have random values. The new assembler Does it really have random values on existing x86 hardware? The x86 hardwares will only change the first 16bits. The rest bits are unchanged. A simple test program can verify that. If it is a only a theoretical problem that does not happen in practice I would advise to not do the change. It depends on what the initial value in the upper bits is. The assembler in CVS generates the same binary code as movw %ds,(%eax) for movl %ds,(%eax) But the previous assemblers will generate 66 8c 18 movw %ds,(%eax) for movw %ds,(%eax) This bug has been fixed for a while. I guess that may be why Linux kernel uses movl %ds,(%eax) It turns out that both old and new assemblers will generate 0: 8c 18 movw %ds,(%eax) for mov %ds,(%eax) So kernel can use mov instead of movl and the binary output will be the same. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
It turns out that 2.4 kernel has
arch/i386/kernel/process.c: asm volatile("movl %%" #seg ",%0":"=m" (*(int
*)&(value)))
arch/i386/kernel/process.c: asm volatile("movl %%fs,%0":"=m" (*(int
*)>fs));
arch/i386/kernel/process.c: asm volatile("movl %%gs,%0":"=m" (*(int
*)>gs));
arch/x86_64/kernel/process.c: asm("movl %%gs,%0" : "=m" (p->thread.gsindex));
arch/x86_64/kernel/process.c: asm("movl %%fs,%0" : "=m" (p->thread.fsindex));
arch/x86_64/kernel/process.c: asm("movl %%es,%0" : "=m" (p->thread.es));
arch/x86_64/kernel/process.c: asm("movl %%ds,%0" : "=m" (p->thread.ds));
arch/x86_64/kernel/process.c: asm volatile("movl %%es,%0" : "=m" (prev->es));
arch/x86_64/kernel/process.c: asm volatile ("movl %%ds,%0" : "=m" (prev->ds));
2.6 kernel has
arch/i386/kernel/process.c: asm volatile("movl %%fs,%0":"=m" (*(int
*)>fs));
arch/i386/kernel/process.c: asm volatile("movl %%gs,%0":"=m" (*(int
*)>gs));
arch/x86_64/kernel/process.c: asm("movl %%gs,%0" : "=m" (p->thread.gsindex));
arch/x86_64/kernel/process.c: asm("movl %%fs,%0" : "=m" (p->thread.fsindex));
arch/x86_64/kernel/process.c: asm("movl %%es,%0" : "=m" (p->thread.es));
arch/x86_64/kernel/process.c: asm("movl %%ds,%0" : "=m" (p->thread.ds));
arch/x86_64/kernel/process.c: asm volatile("movl %%es,%0" : "=m" (prev->es));
arch/x86_64/kernel/process.c: asm volatile ("movl %%ds,%0" : "=m" (prev->ds));
arch/x86_64/kernel/process.c: asm volatile("movl %%fs,%0" : "=g"
(fsindex));
arch/x86_64/kernel/process.c: asm volatile("movl %%gs,%0" : "=g"
(gsindex));
The new assembler will disallow them since those instructions with
memory operand will only use the first 16bits. If the memory operand
is 16bit, you won't see any problems. But if the memory destinatin
is 32bit, the upper 16bits may have random values. The new assembler
will force people to use
mov (%eax),%ds
movw (%eax),%ds
movw %ds,(%eax)
mov %ds,(%eax)
Will it be a big problem for kernel people?
BTW, I haven't checked glibc yet. It may have similar issues.
H.J.
---
On Fri, Mar 25, 2005 at 06:05:06PM -0800, H. J. Lu wrote:
> X86 segment register access is a special. We can move between a segment
> register and a 16/32/64bit general-purpose register. But we can only
> move between a segment register and a 16bit memory address. The current
> assembler allows "movl (%eax),%ds", but doesn't allow "movq %rax,%ds".
> The disassembler display "movl (%eax),%ds". This patch tries to fix
> those.
>
>
> H.J.
>
> gas/testsuite/
>
> 2005-03-25 H.J. Lu <[EMAIL PROTECTED]>
>
> * gas/i386/i386.exp: Run segment and inval-seg for i386. Run
> x86-64-segment and x86-64-inval-seg for x86-64.
>
> * gas/i386/intel.d: Expect movw for moving between memory and
> segment register.
> * gas/i386/naked.d: Likewise.
> * gas/i386/opcode.d: Likewise.
> * gas/i386/x86-64-opcode.d: Likewise.
>
> * gas/i386/opcode.s: Use movw for moving between memory and
> segment register.
> * gas/i386/x86-64-opcode.s: Likewise.
>
> * : Likewise.
>
> * gas/i386/inval-seg.l: New.
> * gas/i386/inval-seg.s: New.
> * gas/i386/segment.l: New.
> * gas/i386/segment.s: New.
> * gas/i386/x86-64-inval-seg.l: New.
> * gas/i386/x86-64-inval-seg.s: New.
> * gas/i386/x86-64-segment.l: New.
> * gas/i386/x86-64-segment.s: New.
>
> include/opcode/
>
> 2005-03-25 H.J. Lu <[EMAIL PROTECTED]>
>
> * i386.h (i386_optab): Don't allow the `l' suffix for moving
> moving between memory and segment register. Allow movq for
> moving between general-purpose register and segment register.
>
> opcodes/
>
> 2005-03-25 H.J. Lu <[EMAIL PROTECTED]>
>
> * i386-dis.c (SEG_Fixup): New.
> (Sv): New.
> (dis386): Use "Sv" for 0x8c and 0x8e.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)
It turns out that 2.4 kernel has arch/i386/kernel/process.c: asm volatile(movl %% #seg ,%0:=m (*(int *)(value))) arch/i386/kernel/process.c: asm volatile(movl %%fs,%0:=m (*(int *)prev-fs)); arch/i386/kernel/process.c: asm volatile(movl %%gs,%0:=m (*(int *)prev-gs)); arch/x86_64/kernel/process.c: asm(movl %%gs,%0 : =m (p-thread.gsindex)); arch/x86_64/kernel/process.c: asm(movl %%fs,%0 : =m (p-thread.fsindex)); arch/x86_64/kernel/process.c: asm(movl %%es,%0 : =m (p-thread.es)); arch/x86_64/kernel/process.c: asm(movl %%ds,%0 : =m (p-thread.ds)); arch/x86_64/kernel/process.c: asm volatile(movl %%es,%0 : =m (prev-es)); arch/x86_64/kernel/process.c: asm volatile (movl %%ds,%0 : =m (prev-ds)); 2.6 kernel has arch/i386/kernel/process.c: asm volatile(movl %%fs,%0:=m (*(int *)prev-fs)); arch/i386/kernel/process.c: asm volatile(movl %%gs,%0:=m (*(int *)prev-gs)); arch/x86_64/kernel/process.c: asm(movl %%gs,%0 : =m (p-thread.gsindex)); arch/x86_64/kernel/process.c: asm(movl %%fs,%0 : =m (p-thread.fsindex)); arch/x86_64/kernel/process.c: asm(movl %%es,%0 : =m (p-thread.es)); arch/x86_64/kernel/process.c: asm(movl %%ds,%0 : =m (p-thread.ds)); arch/x86_64/kernel/process.c: asm volatile(movl %%es,%0 : =m (prev-es)); arch/x86_64/kernel/process.c: asm volatile (movl %%ds,%0 : =m (prev-ds)); arch/x86_64/kernel/process.c: asm volatile(movl %%fs,%0 : =g (fsindex)); arch/x86_64/kernel/process.c: asm volatile(movl %%gs,%0 : =g (gsindex)); The new assembler will disallow them since those instructions with memory operand will only use the first 16bits. If the memory operand is 16bit, you won't see any problems. But if the memory destinatin is 32bit, the upper 16bits may have random values. The new assembler will force people to use mov (%eax),%ds movw (%eax),%ds movw %ds,(%eax) mov %ds,(%eax) Will it be a big problem for kernel people? BTW, I haven't checked glibc yet. It may have similar issues. H.J. --- On Fri, Mar 25, 2005 at 06:05:06PM -0800, H. J. Lu wrote: X86 segment register access is a special. We can move between a segment register and a 16/32/64bit general-purpose register. But we can only move between a segment register and a 16bit memory address. The current assembler allows movl (%eax),%ds, but doesn't allow movq %rax,%ds. The disassembler display movl (%eax),%ds. This patch tries to fix those. H.J. gas/testsuite/ 2005-03-25 H.J. Lu [EMAIL PROTECTED] * gas/i386/i386.exp: Run segment and inval-seg for i386. Run x86-64-segment and x86-64-inval-seg for x86-64. * gas/i386/intel.d: Expect movw for moving between memory and segment register. * gas/i386/naked.d: Likewise. * gas/i386/opcode.d: Likewise. * gas/i386/x86-64-opcode.d: Likewise. * gas/i386/opcode.s: Use movw for moving between memory and segment register. * gas/i386/x86-64-opcode.s: Likewise. * : Likewise. * gas/i386/inval-seg.l: New. * gas/i386/inval-seg.s: New. * gas/i386/segment.l: New. * gas/i386/segment.s: New. * gas/i386/x86-64-inval-seg.l: New. * gas/i386/x86-64-inval-seg.s: New. * gas/i386/x86-64-segment.l: New. * gas/i386/x86-64-segment.s: New. include/opcode/ 2005-03-25 H.J. Lu [EMAIL PROTECTED] * i386.h (i386_optab): Don't allow the `l' suffix for moving moving between memory and segment register. Allow movq for moving between general-purpose register and segment register. opcodes/ 2005-03-25 H.J. Lu [EMAIL PROTECTED] * i386-dis.c (SEG_Fixup): New. (Sv): New. (dis386): Use Sv for 0x8c and 0x8e. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: export linux_logo_bw for hgafb.c
On Wed, May 16, 2001 at 03:41:40PM +0200, Geert Uytterhoeven wrote:
> On Tue, 15 May 2001, H . J . Lu wrote:
> > Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which
> > can be compiled as a module. But linux_logo_bw is not exported.
> >
>
> linux_logo_bw is __initdata.
>
How about this patch?
H.J.
---
--- linux-2.4.4-ac9/drivers/video/fbcon.c.logo Wed May 16 09:40:33 2001
+++ linux-2.4.4-ac9/drivers/video/fbcon.c Wed May 16 09:41:12 2001
@@ -97,6 +97,7 @@
#include
#endif
#define INCLUDE_LINUX_LOGO_DATA
+#define INCLUDE_LINUX_LOGOBW
#include
#include
--- linux-2.4.4-ac9/include/linux/linux_logo.h.logo Wed May 16 09:20:41 2001
+++ linux-2.4.4-ac9/include/linux/linux_logo.h Wed May 16 09:23:17 2001
@@ -912,93 +912,6 @@ unsigned char linux_logo[] __initdata =
#endif /* !__HAVE_ARCH_LINUX_LOGO */
-#ifndef __HAVE_ARCH_LINUX_LOGOBW
-
-unsigned char linux_logo_bw[] __initdata = {
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xf0, 0x0f, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xcf, 0xf3, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xbf, 0xfc, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0x7f, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfe, 0xff, 0xff, 0xbf, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xf3, 0xdf, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xf7, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xff, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x9f, 0x87, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x0f, 0x03, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x67, 0x33, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xe7, 0x79, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xf7, 0x79, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xf9, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x60, 0x3b, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x89, 0x07, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x00, 0x03, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x00, 0x0d, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x80, 0x33, 0xfd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xc0, 0xc3, 0xfd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0x0d, 0xdd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x40, 0x31, 0xee, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xf7, 0x20, 0xc1, 0xee, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xf7, 0x1f, 0x00, 0xff, 0x7f, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xef, 0x00, 0x00, 0x7f, 0xbf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xee, 0x00, 0x00, 0x7f, 0xbf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xde, 0x00, 0x00, 0x7f, 0xdf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xbc, 0x00, 0x00, 0x3f, 0xef, 0xff, 0xff,
-0xff, 0xff, 0xff, 0x7c, 0x00, 0x00, 0x3f, 0xf7, 0xff, 0xff,
-0xff, 0xff, 0xff, 0x7c, 0x00, 0x00, 0x1f, 0xf7, 0xff, 0xff,
-0xff, 0xff, 0xfe, 0xff, 0x1c, 0x07, 0xdf, 0xfb, 0xff, 0xff,
-0xff, 0xff, 0xfd, 0xfc, 0x08, 0x0f, 0xef, 0xfd, 0xff, 0xff,
-0xff, 0xff, 0xfd, 0xf8, 0x00, 0x01, 0xef, 0xfd, 0xff, 0xff,
-0xff, 0xff, 0xfb, 0xf0, 0x00, 0x00, 0x7f, 0xfe, 0xff, 0xff,
-0xff, 0xff, 0xfb, 0xe0, 0x00, 0x00, 0x1f, 0xfe, 0xff, 0xff,
-0xff, 0xff, 0xf7, 0xe0, 0x00, 0x00, 0x07, 0xbf, 0x7f, 0xff,
-0xff, 0xff, 0xf7, 0xc0, 0x00, 0x00, 0x03, 0xbf, 0x7f, 0xff,
-0xff, 0xff, 0xef, 0xc0, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xef, 0x80, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x03, 0x03, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x02, 0xfd, 0xdf, 0xff,
-0xff, 0xff, 0xa3, 0x80, 0x00, 0x00, 0x1f, 0xff, 0xdf, 0xff,
-0xff, 0xff, 0xc1, 0xc0, 0x00, 0x00, 0x11, 0xff, 0x3f, 0xff,
-0xff, 0xff, 0x80, 0xe0, 0x00, 0x00, 0x21, 0xfe, 0x3f, 0xff,
-0xff, 0xff, 0x00, 0x70, 0x00, 0x00, 0x21, 0xfc, 0x3f, 0xff,
-0xff, 0xfe, 0x00, 0x3c, 0x00, 0x00, 0x20, 0xf8, 0x3f, 0xff,
-0xff, 0xf0, 0x00, 0x3e, 0x00, 0x00, 0x20, 0x00, 0x3f, 0xff,
-0xff, 0xc0, 0x00, 0x1f, 0x00, 0x00, 0x20, 0x00, 0x3f, 0xff,
-0xff, 0xc0, 0x00, 0x1f, 0x80, 0x00, 0x20, 0x00, 0x1f, 0xff,
-
Re: Bad udelay usage in drivers/net/aironet4500_card.c
On Wed, May 16, 2001 at 05:33:12AM -0700, Jalaja Devi wrote: > Hi! > Could you please tell me how you fixed the udelay > problem. cuz, I am encountering the same problem in my > driver. > I am not a kernel expert. You should ask it on the kernel mailing list. > Thanks for your time, > Jalaja > > > In 2.4.4, drivers/net/aironet4500_card.c has > > > # grep udelay linux/drivers/net/aironet4500_card.c > udelay(1000); > udelay(100); > udelay(10); > udelay(10); > udelay(20); > udelay(25); > udelay(1); > udelay(1); > udelay(1000); > udelay(1000); > udelay(1); > > > But on ia32, you cannot use more than 2 for udelay > (). You will get > undefined symbol, __bad_udelay. > > > > > __ > Do You Yahoo!? > Yahoo! Auctions - buy the things you want at great prices > http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bad udelay usage in drivers/net/aironet4500_card.c
On Wed, May 16, 2001 at 05:33:12AM -0700, Jalaja Devi wrote: Hi! Could you please tell me how you fixed the udelay problem. cuz, I am encountering the same problem in my driver. I am not a kernel expert. You should ask it on the kernel mailing list. Thanks for your time, Jalaja In 2.4.4, drivers/net/aironet4500_card.c has # grep udelay linux/drivers/net/aironet4500_card.c udelay(1000); udelay(100); udelay(10); udelay(10); udelay(20); udelay(25); udelay(1); udelay(1); udelay(1000); udelay(1000); udelay(1); But on ia32, you cannot use more than 2 for udelay (). You will get undefined symbol, __bad_udelay. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: export linux_logo_bw for hgafb.c
On Wed, May 16, 2001 at 03:41:40PM +0200, Geert Uytterhoeven wrote:
On Tue, 15 May 2001, H . J . Lu wrote:
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which
can be compiled as a module. But linux_logo_bw is not exported.
linux_logo_bw is __initdata.
How about this patch?
H.J.
---
--- linux-2.4.4-ac9/drivers/video/fbcon.c.logo Wed May 16 09:40:33 2001
+++ linux-2.4.4-ac9/drivers/video/fbcon.c Wed May 16 09:41:12 2001
@@ -97,6 +97,7 @@
#include asm/io.h
#endif
#define INCLUDE_LINUX_LOGO_DATA
+#define INCLUDE_LINUX_LOGOBW
#include asm/linux_logo.h
#include video/fbcon.h
--- linux-2.4.4-ac9/include/linux/linux_logo.h.logo Wed May 16 09:20:41 2001
+++ linux-2.4.4-ac9/include/linux/linux_logo.h Wed May 16 09:23:17 2001
@@ -912,93 +912,6 @@ unsigned char linux_logo[] __initdata =
#endif /* !__HAVE_ARCH_LINUX_LOGO */
-#ifndef __HAVE_ARCH_LINUX_LOGOBW
-
-unsigned char linux_logo_bw[] __initdata = {
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xf0, 0x0f, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xcf, 0xf3, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xbf, 0xfc, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0x7f, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfe, 0xff, 0xff, 0xbf, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xf3, 0xdf, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xf7, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfd, 0xff, 0xff, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xef, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xff, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x9f, 0x87, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x0f, 0x03, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x67, 0x33, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xe7, 0x79, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xf7, 0x79, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0xf9, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x60, 0x3b, 0xf7, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x89, 0x07, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x00, 0x03, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x00, 0x0d, 0xfb, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x80, 0x33, 0xfd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xc0, 0xc3, 0xfd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0xff, 0x0d, 0xdd, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xfb, 0x40, 0x31, 0xee, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xf7, 0x20, 0xc1, 0xee, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xf7, 0x1f, 0x00, 0xff, 0x7f, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xef, 0x00, 0x00, 0x7f, 0xbf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xee, 0x00, 0x00, 0x7f, 0xbf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xde, 0x00, 0x00, 0x7f, 0xdf, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xbc, 0x00, 0x00, 0x3f, 0xef, 0xff, 0xff,
-0xff, 0xff, 0xff, 0x7c, 0x00, 0x00, 0x3f, 0xf7, 0xff, 0xff,
-0xff, 0xff, 0xff, 0x7c, 0x00, 0x00, 0x1f, 0xf7, 0xff, 0xff,
-0xff, 0xff, 0xfe, 0xff, 0x1c, 0x07, 0xdf, 0xfb, 0xff, 0xff,
-0xff, 0xff, 0xfd, 0xfc, 0x08, 0x0f, 0xef, 0xfd, 0xff, 0xff,
-0xff, 0xff, 0xfd, 0xf8, 0x00, 0x01, 0xef, 0xfd, 0xff, 0xff,
-0xff, 0xff, 0xfb, 0xf0, 0x00, 0x00, 0x7f, 0xfe, 0xff, 0xff,
-0xff, 0xff, 0xfb, 0xe0, 0x00, 0x00, 0x1f, 0xfe, 0xff, 0xff,
-0xff, 0xff, 0xf7, 0xe0, 0x00, 0x00, 0x07, 0xbf, 0x7f, 0xff,
-0xff, 0xff, 0xf7, 0xc0, 0x00, 0x00, 0x03, 0xbf, 0x7f, 0xff,
-0xff, 0xff, 0xef, 0xc0, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xef, 0x80, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x03, 0xdf, 0xbf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xdf, 0x80, 0x00, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x01, 0xef, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x03, 0x03, 0xdf, 0xff,
-0xff, 0xff, 0xbf, 0x00, 0x20, 0x00, 0x02, 0xfd, 0xdf, 0xff,
-0xff, 0xff, 0xa3, 0x80, 0x00, 0x00, 0x1f, 0xff, 0xdf, 0xff,
-0xff, 0xff, 0xc1, 0xc0, 0x00, 0x00, 0x11, 0xff, 0x3f, 0xff,
-0xff, 0xff, 0x80, 0xe0, 0x00, 0x00, 0x21, 0xfe, 0x3f, 0xff,
-0xff, 0xff, 0x00, 0x70, 0x00, 0x00, 0x21, 0xfc, 0x3f, 0xff,
-0xff, 0xfe, 0x00, 0x3c, 0x00, 0x00, 0x20, 0xf8, 0x3f, 0xff,
-0xff, 0xf0, 0x00, 0x3e, 0x00, 0x00, 0x20, 0x00, 0x3f, 0xff,
-0xff, 0xc0, 0x00, 0x1f, 0x00, 0x00, 0x20, 0x00, 0x3f, 0xff,
-0xff, 0xc0, 0x00, 0x1f, 0x80, 0x00, 0x20, 0x00, 0x1f, 0xff
PATCH: export linux_logo_bw for hgafb.c
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which can be compiled as a module. But linux_logo_bw is not exported. H.J. --- --- linux-2.4.4-ac9/drivers/video/fbcon.c.mod Tue May 15 15:39:17 2001 +++ linux-2.4.4-ac9/drivers/video/fbcon.c Tue May 15 15:40:18 2001 @@ -2495,3 +2495,4 @@ EXPORT_SYMBOL(fbcon_redraw_bmove); EXPORT_SYMBOL(fbcon_redraw_clear); EXPORT_SYMBOL(fbcon_dummy); EXPORT_SYMBOL(fb_con); +EXPORT_SYMBOL(linux_logo_bw); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bad udelay usage in drivers/net/aironet4500_card.c
In 2.4.4, drivers/net/aironet4500_card.c has # grep udelay linux/drivers/net/aironet4500_card.c udelay(1000); udelay(100); udelay(10); udelay(10); udelay(20); udelay(25); udelay(1); udelay(1); udelay(1000); udelay(1000); udelay(1); But on ia32, you cannot use more than 2 for udelay (). You will get undefined symbol, __bad_udelay. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Enable IP PNP for 2.4.4-ac8
> > The clean way to handle it, and I'll take a look it to have > root=/dev/nfs (and the rdev equivalent) to set ip=on if it isn't Yes. > already. The current 2.4.4 behavior of root=/dev/hda3 doing ip > autoconfig when the code is compiled into the kernel is just bad. Agreed. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bad udelay usage in drivers/net/aironet4500_card.c
In 2.4.4, drivers/net/aironet4500_card.c has # grep udelay linux/drivers/net/aironet4500_card.c udelay(1000); udelay(100); udelay(10); udelay(10); udelay(20); udelay(25); udelay(1); udelay(1); udelay(1000); udelay(1000); udelay(1); But on ia32, you cannot use more than 2 for udelay (). You will get undefined symbol, __bad_udelay. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: export linux_logo_bw for hgafb.c
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which can be compiled as a module. But linux_logo_bw is not exported. H.J. --- --- linux-2.4.4-ac9/drivers/video/fbcon.c.mod Tue May 15 15:39:17 2001 +++ linux-2.4.4-ac9/drivers/video/fbcon.c Tue May 15 15:40:18 2001 @@ -2495,3 +2495,4 @@ EXPORT_SYMBOL(fbcon_redraw_bmove); EXPORT_SYMBOL(fbcon_redraw_clear); EXPORT_SYMBOL(fbcon_dummy); EXPORT_SYMBOL(fb_con); +EXPORT_SYMBOL(linux_logo_bw); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Enable IP PNP for 2.4.4-ac8
The clean way to handle it, and I'll take a look it to have root=/dev/nfs (and the rdev equivalent) to set ip=on if it isn't Yes. already. The current 2.4.4 behavior of root=/dev/hda3 doing ip autoconfig when the code is compiled into the kernel is just bad. Agreed. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.4.ac9: BOOTP/DHCP
On Mon, May 14, 2001 at 12:02:48PM -0700, H . J . Lu wrote:
>
> BTW, I cannot select both CONFIG_IP_PNP_DHCP and CONFIG_IP_PNP_BOOTP.
> BOOTP doesn' work even if I pass "ip=bootp" to kernel. I will take
> a look.
>
>
Here is a patch. We should do DHCP iff it is enabled.
H.J.
--- linux-2.4.4-ac9/net/ipv4/ipconfig.c.autoMon May 14 12:18:18 2001
+++ linux-2.4.4-ac9/net/ipv4/ipconfig.c Mon May 14 12:52:51 2001
@@ -816,61 +816,63 @@ static int __init ic_bootp_recv(struct s
u8 *ext;
#ifdef IPCONFIG_DHCP
+ if (ic_proto_enabled & IC_USE_DHCP) {
- u32 server_id = INADDR_NONE;
- int mt = 0;
+ u32 server_id = INADDR_NONE;
+ int mt = 0;
- ext = >exten[4];
- while (ext < end && *ext != 0xff) {
- u8 *opt = ext++;
- if (*opt == 0) /* Padding */
- continue;
- ext += *ext + 1;
- if (ext >= end)
- break;
- switch (*opt) {
- case 53:/* Message type */
- if (opt[1])
- mt = opt[2];
- break;
- case 54:/* Server ID (IP address) */
- if (opt[1] >= 4)
- memcpy(_id, opt + 2, 4);
- break;
+ ext = >exten[4];
+ while (ext < end && *ext != 0xff) {
+ u8 *opt = ext++;
+ if (*opt == 0) /* Padding */
+ continue;
+ ext += *ext + 1;
+ if (ext >= end)
+ break;
+ switch (*opt) {
+ case 53:/* Message type */
+ if (opt[1])
+ mt = opt[2];
+ break;
+ case 54:/* Server ID (IP address) */
+ if (opt[1] >= 4)
+ memcpy(_id, opt + 2, 4);
+ break;
+ }
}
- }
#ifdef IPCONFIG_DEBUG
- printk("DHCP: Got message type %d\n", mt);
+ printk("DHCP: Got message type %d\n", mt);
#endif
- switch (mt) {
- case DHCPOFFER:
- /* While in the process of accepting one offer,
- ignore all others. */
- if (ic_myaddr != INADDR_NONE)
- goto drop;
- /* Let's accept that offer. */
- ic_myaddr = b->your_ip;
- ic_servaddr = server_id;
+ switch (mt) {
+ case DHCPOFFER:
+ /* While in the process of accepting one offer,
+ ignore all others. */
+ if (ic_myaddr != INADDR_NONE)
+ goto drop;
+ /* Let's accept that offer. */
+ ic_myaddr = b->your_ip;
+ ic_servaddr = server_id;
#ifdef IPCONFIG_DEBUG
- printk("DHCP: Offered address %u.%u.%u.%u",
NIPQUAD(ic_myaddr));
- printk(" by server %u.%u.%u.%u\n", NIPQUAD(ic_servaddr));
+ printk("DHCP: Offered address %u.%u.%u.%u",
+NIPQUAD(ic_myaddr));
+ printk(" by server %u.%u.%u.%u\n",
+NIPQUAD(ic_servaddr));
#endif
- break;
+ break;
- case DHCPACK:
- /* Yeah! */
- break;
-
- default:
- /* Urque. Forget it*/
- ic_myaddr = INADDR_NONE;
- ic_servaddr = INADDR_NONE;
- goto drop;
- }
+ case DHCPACK:
+ /* Yeah! */
+ break;
+
+ default:
+ /* Urque. Forget it*/
+ ic_myaddr = INADDR_NONE;
+ ic_servaddr = INADDR_NONE;
+ goto drop;
+
Re: PATCH 2.4.4.ac9: Tulip net driver fixes
On Mon, May 14, 2001 at 02:36:05PM -0400, Jeff Garzik wrote: > Mads Martin Jørgensen wrote: > > > > * H . J . Lu <[EMAIL PROTECTED]> [May 14. 2001 11:22]: > > > On Sat, May 12, 2001 at 03:25:34PM -0400, Jeff Garzik wrote: > > > > Attached is a patch against 2.4.4-ac8 which includes several fixes to > > > > the Tulip driver. This should fix the reported PNIC problems, as well > > > > as problems with forcing media on MII phys and several other bugs. > > > > > > Your patch doesn't apply to 2.4.4-ac8 cleanly: > > > > No, I noticed that too. But the 1.1.6 from > > http://sourceforge.net/projects/tulip/ works fine here. > > Attached is a patch against 2.4.4-ac9 which includes the changes found > in tulip-devel 1.1.6... (tulip-devel is sort of a misnomer; right now > it's really just a staging and testing point for fixes which go straight > into the tulip-stable series) > THANKS. It works! BTW, I cannot select both CONFIG_IP_PNP_DHCP and CONFIG_IP_PNP_BOOTP. BOOTP doesn' work even if I pass "ip=bootp" to kernel. I will take a look. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.4.ac8: Tulip net driver fixes
On Sat, May 12, 2001 at 03:25:34PM -0400, Jeff Garzik wrote: > Attached is a patch against 2.4.4-ac8 which includes several fixes to > the Tulip driver. This should fix the reported PNIC problems, as well > as problems with forcing media on MII phys and several other bugs. > Your patch doesn't apply to 2.4.4-ac8 cleanly: patching file drivers/net/tulip/ChangeLog Hunk #1 FAILED at 1. Hunk #2 succeeded at 104 (offset -35 lines). 1 out of 3 hunks FAILED -- saving rejects to file drivers/net/tulip/ChangeLog.rej patching file drivers/net/tulip/media.c Hunk #2 succeeded at 409 (offset -2 lines). Hunk #3 succeeded at 444 (offset 2 lines). Hunk #4 succeeded at 455 (offset -2 lines). patching file drivers/net/tulip/tulip.h Hunk #1 succeeded at 382 (offset -22 lines). patching file drivers/net/tulip/tulip_core.c Hunk #1 FAILED at 24. Hunk #2 succeeded at 160 (offset -2 lines). Hunk #4 succeeded at 885 (offset -2 lines). Hunk #5 FAILED at 1169. Hunk #6 succeeded at 1432 (offset -82 lines). Hunk #7 FAILED at 1442. Hunk #8 succeeded at 1612 (offset -22 lines). 3 out of 8 hunks FAILED -- saving rejects to file drivers/net/tulip/tulip_core.c.rej I tried 2.4.4-ac9. It has the same problem. The kernel IP config still doesn't work. But the user space DHCP works fine. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.4.ac8: Tulip net driver fixes
On Sat, May 12, 2001 at 03:25:34PM -0400, Jeff Garzik wrote: Attached is a patch against 2.4.4-ac8 which includes several fixes to the Tulip driver. This should fix the reported PNIC problems, as well as problems with forcing media on MII phys and several other bugs. Your patch doesn't apply to 2.4.4-ac8 cleanly: patching file drivers/net/tulip/ChangeLog Hunk #1 FAILED at 1. Hunk #2 succeeded at 104 (offset -35 lines). 1 out of 3 hunks FAILED -- saving rejects to file drivers/net/tulip/ChangeLog.rej patching file drivers/net/tulip/media.c Hunk #2 succeeded at 409 (offset -2 lines). Hunk #3 succeeded at 444 (offset 2 lines). Hunk #4 succeeded at 455 (offset -2 lines). patching file drivers/net/tulip/tulip.h Hunk #1 succeeded at 382 (offset -22 lines). patching file drivers/net/tulip/tulip_core.c Hunk #1 FAILED at 24. Hunk #2 succeeded at 160 (offset -2 lines). Hunk #4 succeeded at 885 (offset -2 lines). Hunk #5 FAILED at 1169. Hunk #6 succeeded at 1432 (offset -82 lines). Hunk #7 FAILED at 1442. Hunk #8 succeeded at 1612 (offset -22 lines). 3 out of 8 hunks FAILED -- saving rejects to file drivers/net/tulip/tulip_core.c.rej I tried 2.4.4-ac9. It has the same problem. The kernel IP config still doesn't work. But the user space DHCP works fine. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.4.ac9: Tulip net driver fixes
On Mon, May 14, 2001 at 02:36:05PM -0400, Jeff Garzik wrote: Mads Martin Jørgensen wrote: * H . J . Lu [EMAIL PROTECTED] [May 14. 2001 11:22]: On Sat, May 12, 2001 at 03:25:34PM -0400, Jeff Garzik wrote: Attached is a patch against 2.4.4-ac8 which includes several fixes to the Tulip driver. This should fix the reported PNIC problems, as well as problems with forcing media on MII phys and several other bugs. Your patch doesn't apply to 2.4.4-ac8 cleanly: No, I noticed that too. But the 1.1.6 from http://sourceforge.net/projects/tulip/ works fine here. Attached is a patch against 2.4.4-ac9 which includes the changes found in tulip-devel 1.1.6... (tulip-devel is sort of a misnomer; right now it's really just a staging and testing point for fixes which go straight into the tulip-stable series) THANKS. It works! BTW, I cannot select both CONFIG_IP_PNP_DHCP and CONFIG_IP_PNP_BOOTP. BOOTP doesn' work even if I pass ip=bootp to kernel. I will take a look. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.4.ac9: BOOTP/DHCP
On Mon, May 14, 2001 at 12:02:48PM -0700, H . J . Lu wrote:
BTW, I cannot select both CONFIG_IP_PNP_DHCP and CONFIG_IP_PNP_BOOTP.
BOOTP doesn' work even if I pass ip=bootp to kernel. I will take
a look.
Here is a patch. We should do DHCP iff it is enabled.
H.J.
--- linux-2.4.4-ac9/net/ipv4/ipconfig.c.autoMon May 14 12:18:18 2001
+++ linux-2.4.4-ac9/net/ipv4/ipconfig.c Mon May 14 12:52:51 2001
@@ -816,61 +816,63 @@ static int __init ic_bootp_recv(struct s
u8 *ext;
#ifdef IPCONFIG_DHCP
+ if (ic_proto_enabled IC_USE_DHCP) {
- u32 server_id = INADDR_NONE;
- int mt = 0;
+ u32 server_id = INADDR_NONE;
+ int mt = 0;
- ext = b-exten[4];
- while (ext end *ext != 0xff) {
- u8 *opt = ext++;
- if (*opt == 0) /* Padding */
- continue;
- ext += *ext + 1;
- if (ext = end)
- break;
- switch (*opt) {
- case 53:/* Message type */
- if (opt[1])
- mt = opt[2];
- break;
- case 54:/* Server ID (IP address) */
- if (opt[1] = 4)
- memcpy(server_id, opt + 2, 4);
- break;
+ ext = b-exten[4];
+ while (ext end *ext != 0xff) {
+ u8 *opt = ext++;
+ if (*opt == 0) /* Padding */
+ continue;
+ ext += *ext + 1;
+ if (ext = end)
+ break;
+ switch (*opt) {
+ case 53:/* Message type */
+ if (opt[1])
+ mt = opt[2];
+ break;
+ case 54:/* Server ID (IP address) */
+ if (opt[1] = 4)
+ memcpy(server_id, opt + 2, 4);
+ break;
+ }
}
- }
#ifdef IPCONFIG_DEBUG
- printk(DHCP: Got message type %d\n, mt);
+ printk(DHCP: Got message type %d\n, mt);
#endif
- switch (mt) {
- case DHCPOFFER:
- /* While in the process of accepting one offer,
- ignore all others. */
- if (ic_myaddr != INADDR_NONE)
- goto drop;
- /* Let's accept that offer. */
- ic_myaddr = b-your_ip;
- ic_servaddr = server_id;
+ switch (mt) {
+ case DHCPOFFER:
+ /* While in the process of accepting one offer,
+ ignore all others. */
+ if (ic_myaddr != INADDR_NONE)
+ goto drop;
+ /* Let's accept that offer. */
+ ic_myaddr = b-your_ip;
+ ic_servaddr = server_id;
#ifdef IPCONFIG_DEBUG
- printk(DHCP: Offered address %u.%u.%u.%u,
NIPQUAD(ic_myaddr));
- printk( by server %u.%u.%u.%u\n, NIPQUAD(ic_servaddr));
+ printk(DHCP: Offered address %u.%u.%u.%u,
+NIPQUAD(ic_myaddr));
+ printk( by server %u.%u.%u.%u\n,
+NIPQUAD(ic_servaddr));
#endif
- break;
+ break;
- case DHCPACK:
- /* Yeah! */
- break;
-
- default:
- /* Urque. Forget it*/
- ic_myaddr = INADDR_NONE;
- ic_servaddr = INADDR_NONE;
- goto drop;
- }
+ case DHCPACK:
+ /* Yeah! */
+ break;
+
+ default:
+ /* Urque. Forget it*/
+ ic_myaddr = INADDR_NONE;
+ ic_servaddr = INADDR_NONE;
+ goto drop;
+ }
- ic_dhcp_msgtype = mt;
+ ic_dhcp_msgtype = mt;
+ }
#endif /* IPCONFIG_DHCP */
-
To unsubscribe from
Re: PATCH: Enable IP PNP for 2.4.4-ac8
On Sun, May 13, 2001 at 07:24:31PM -0600, Eric W. Biederman wrote: > > I agree it isn't intuitive, and if nfsroot=xxx is specified it should > probably turn on if there is missing information. > > But if you have to select the command line anyway > > Mostly I like the situation where I can compile it in and turn it on > when I need it, instead of having to do thing differently if it is > compiled in or not. > In fact, I like the idea. But passing nfsroot=xxx to kernel doesn't imply "ip=on" is very annoying. My setup worked fine with 2.4.4. It took me a while to figure out why it didn't work with 2.4.4-ac8. > > Have you tried > > ramdisk on diskless alpha, arm, m68k, mips, ppc, sh, sparc, booting > > over network? > > First the booting situation on linux with respect to multiple platform > sucks. We pass parameters in weird ways on every platform. The command > line is the only thing that stays mostly the same. I'm looking at what > it takes to clean that up, so we can have multiplatform bootloaders. I don't think we have total control over how to boot over network on all platforms. On some platforms, you may only load kernel over the network and run from it. > > I have implemented what it takes to attach a ramdisk, and if you can > boot an arbitrary kernel it isn't hard to have a program that attaches > a ramdisk. > > Now although I believe this is the right direction to go, you will > notice I ported the dhcp IP auto configuration from 2.2.19 to to 2.4.x > Buying a little more time to get this working. Thanks. I appreciate it. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Enable IP PNP for 2.4.4-ac8
On Sun, May 13, 2001 at 01:24:18PM -0600, Eric W. Biederman wrote: > "H . J . Lu" <[EMAIL PROTECTED]> writes: > > > It doesn't make any senses. When I specify CONFIG_IP_PNP and > > BOOTP/DHCP, I want a kernel with IP config using BOOTP/DHCP. I would > > expect IP config is turned for BOOTP/DHCP by default. You can turn > > it off by passing "ip=off" to kernel. Did I miss something? > > Since you have to set the command line anyway ip=dhcp is no extra > burden and it lets you use the same kernel to boot of the harddrive etc. Why do I have to set "ip=dhcp"? If I have selected CONFIG_IP_PNP and DHCP in my kernel configuration, should it be on by default? > > > > This same situation exists for 2.2.18 & 2.2.19 as well. > > > > > > The only way to get long term stability out of this is to write > > > a user space client, you can put in a ramdisk. One of these days... > > > > It doesn't work with diskless machines which don't support ramdisk > > during boot. > > I don't believe that is a real world situation. > > I boot diskless all of time and supporting a ramdisk is trivial. You > just a have a program that slaps a kernel a ramdisk, and some command > line arguments into a single image, along with a touch of adapter code > to set the kernel parameters correctly and then boot that. Let me guess. Your diskless machines are mostly x86. Have you tried ramdisk on diskless alpha, arm, m68k, mips, ppc, sh, sparc, booting over network? H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Enable IP PNP for 2.4.4-ac8
On Sun, May 13, 2001 at 01:24:18PM -0600, Eric W. Biederman wrote: H . J . Lu [EMAIL PROTECTED] writes: It doesn't make any senses. When I specify CONFIG_IP_PNP and BOOTP/DHCP, I want a kernel with IP config using BOOTP/DHCP. I would expect IP config is turned for BOOTP/DHCP by default. You can turn it off by passing ip=off to kernel. Did I miss something? Since you have to set the command line anyway ip=dhcp is no extra burden and it lets you use the same kernel to boot of the harddrive etc. Why do I have to set ip=dhcp? If I have selected CONFIG_IP_PNP and DHCP in my kernel configuration, should it be on by default? This same situation exists for 2.2.18 2.2.19 as well. The only way to get long term stability out of this is to write a user space client, you can put in a ramdisk. One of these days... It doesn't work with diskless machines which don't support ramdisk during boot. I don't believe that is a real world situation. I boot diskless all of time and supporting a ramdisk is trivial. You just a have a program that slaps a kernel a ramdisk, and some command line arguments into a single image, along with a touch of adapter code to set the kernel parameters correctly and then boot that. Let me guess. Your diskless machines are mostly x86. Have you tried ramdisk on diskless alpha, arm, m68k, mips, ppc, sh, sparc, booting over network? H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Enable IP PNP for 2.4.4-ac8
On Sun, May 13, 2001 at 07:24:31PM -0600, Eric W. Biederman wrote: I agree it isn't intuitive, and if nfsroot=xxx is specified it should probably turn on if there is missing information. But if you have to select the command line anyway Mostly I like the situation where I can compile it in and turn it on when I need it, instead of having to do thing differently if it is compiled in or not. In fact, I like the idea. But passing nfsroot=xxx to kernel doesn't imply ip=on is very annoying. My setup worked fine with 2.4.4. It took me a while to figure out why it didn't work with 2.4.4-ac8. Have you tried ramdisk on diskless alpha, arm, m68k, mips, ppc, sh, sparc, booting over network? First the booting situation on linux with respect to multiple platform sucks. We pass parameters in weird ways on every platform. The command line is the only thing that stays mostly the same. I'm looking at what it takes to clean that up, so we can have multiplatform bootloaders. I don't think we have total control over how to boot over network on all platforms. On some platforms, you may only load kernel over the network and run from it. I have implemented what it takes to attach a ramdisk, and if you can boot an arbitrary kernel it isn't hard to have a program that attaches a ramdisk. Now although I believe this is the right direction to go, you will notice I ported the dhcp IP auto configuration from 2.2.19 to to 2.4.x Buying a little more time to get this working. Thanks. I appreciate it. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC rev 32
The tulip driver in 2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC rev 32 in the NetGear FA310TX REV-D2. It sends BOOTP request and times out. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Enable IP PNP for 2.4.4-ac8
On Fri, May 11, 2001 at 04:28:05PM -0700, David S. Miller wrote: > > H . J . Lu writes: > > 2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is > > defined. Here is a patch. > > It doesn't make any sense to enable this unless parameters are > given to the kernel via the kernel command line or from firmware > settings. >From Configure.help: IP: kernel level autoconfiguration CONFIG_IP_PNP This enables automatic configuration of IP addresses of devices and of the routing table during kernel boot, based on either information supplied on the kernel command line or by BOOTP or RARP protocols. You need to say Y only for diskless machines requiring network access to boot (in which case you want to say Y to "Root file system on NFS" as well), because all other machines configure the network in their startup scripts. It works fine for 2.4.4. However, in 2.4.4-ac8, even if I select CONFIG_IP_PNP, I have to pass ip= to kernel, in addition to nfsroot=x.x.x.x:/foo/bar. With 2.4.4, I can just pass nfsroot=x.x.x.x:/foo/bar to kernel. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: Enable IP PNP for 2.4.4-ac8
2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is defined. Here is a patch. H.J. --- --- linux-2.4.4-ac8/net/ipv4/ipconfig.c.autoFri May 11 14:02:32 2001 +++ linux-2.4.4-ac8/net/ipv4/ipconfig.c Fri May 11 15:26:25 2001 @@ -100,7 +100,11 @@ */ int ic_set_manually __initdata = 0;/* IPconfig parameters set manually */ +#if defined(CONFIG_IP_PNP) +int ic_enable __initdata = 1; /* IP config enabled? */ +#else int ic_enable __initdata = 0; /* IP config enabled? */ +#endif /* Protocol choice */ int ic_proto_enabled __initdata = 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch for 2.4.4-ac7
This should fix http://boudicca.tux.org/hypermail/linux-kernel/this-week/0901.html H.J. --- linux-2.4.4-ac7/mm/filemap.c.module Fri May 11 13:32:20 2001 +++ linux-2.4.4-ac7/mm/filemap.cFri May 11 13:33:03 2001 @@ -9,6 +9,8 @@ * most "normal" filesystems (but you don't /have/ to use this: * the NFS filesystem used to do this differently, for example) */ +#include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch for 2.4.4-ac7
This should fix http://boudicca.tux.org/hypermail/linux-kernel/this-week/0901.html H.J. --- linux-2.4.4-ac7/mm/filemap.c.module Fri May 11 13:32:20 2001 +++ linux-2.4.4-ac7/mm/filemap.cFri May 11 13:33:03 2001 @@ -9,6 +9,8 @@ * most normal filesystems (but you don't /have/ to use this: * the NFS filesystem used to do this differently, for example) */ +#include linux/config.h +#include linux/module.h #include linux/slab.h #include linux/shm.h #include linux/mman.h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: Enable IP PNP for 2.4.4-ac8
2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is defined. Here is a patch. H.J. --- --- linux-2.4.4-ac8/net/ipv4/ipconfig.c.autoFri May 11 14:02:32 2001 +++ linux-2.4.4-ac8/net/ipv4/ipconfig.c Fri May 11 15:26:25 2001 @@ -100,7 +100,11 @@ */ int ic_set_manually __initdata = 0;/* IPconfig parameters set manually */ +#if defined(CONFIG_IP_PNP) +int ic_enable __initdata = 1; /* IP config enabled? */ +#else int ic_enable __initdata = 0; /* IP config enabled? */ +#endif /* Protocol choice */ int ic_proto_enabled __initdata = 0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC rev 32
The tulip driver in 2.4.4-ac8 doesn't work with Lite-On 82c168 PNIC rev 32 in the NetGear FA310TX REV-D2. It sends BOOTP request and times out. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Enable IP PNP for 2.4.4-ac8
On Fri, May 11, 2001 at 04:28:05PM -0700, David S. Miller wrote: H . J . Lu writes: 2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is defined. Here is a patch. It doesn't make any sense to enable this unless parameters are given to the kernel via the kernel command line or from firmware settings. From Configure.help: IP: kernel level autoconfiguration CONFIG_IP_PNP This enables automatic configuration of IP addresses of devices and of the routing table during kernel boot, based on either information supplied on the kernel command line or by BOOTP or RARP protocols. You need to say Y only for diskless machines requiring network access to boot (in which case you want to say Y to Root file system on NFS as well), because all other machines configure the network in their startup scripts. It works fine for 2.4.4. However, in 2.4.4-ac8, even if I select CONFIG_IP_PNP, I have to pass ip= to kernel, in addition to nfsroot=x.x.x.x:/foo/bar. With 2.4.4, I can just pass nfsroot=x.x.x.x:/foo/bar to kernel. H.J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] New files on read only NFS mount
On Mon, Mar 12, 2001 at 03:56:20PM +0100, Trond Myklebust wrote: > > " " == Chris Jensen <[EMAIL PROTECTED]> writes: > > >> Details please, the minimum info required being 'which kernel > >> is your client running'? > >> > > > Oh yeah, whoops, sorry The server is a 586 and the client is > > 686. They're both using nfs-utils 0.2.1, under linux 2.4.0 > > with NFS v3 enabled, with glibc 2.2.1 The pertinent line in > > /etc/exports is / 192.168.0.1(rw,no_root_squash) > > How does the following patch work out? > I can duplicate the problem and this patch fixes it. Thanks. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] New files on read only NFS mount
On Mon, Mar 12, 2001 at 03:56:20PM +0100, Trond Myklebust wrote: " " == Chris Jensen [EMAIL PROTECTED] writes: Details please, the minimum info required being 'which kernel is your client running'? Oh yeah, whoops, sorry The server is a 586 and the client is 686. They're both using nfs-utils 0.2.1, under linux 2.4.0 with NFS v3 enabled, with glibc 2.2.1 The pertinent line in /etc/exports is / 192.168.0.1(rw,no_root_squash) How does the following patch work out? I can duplicate the problem and this patch fixes it. Thanks. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Tue, Feb 27, 2001 at 03:04:32PM -0800, H . J . Lu wrote: > > entry->prev_cookie = entry->cookie; > > - p = xdr_decode_hyper(p, >cookie); > > + p = xdr_decode_hyper(p, cookie); > > + entry->cookie = nfs_transform_cookie64(cookie); > > I don't understand this. As far as I can tell, "cookie" is not > initialized at all. Even if it is initialized, what does > > p = xdr_decode_hyper(p, cookie); > Trond, I think you missed p = xdr_decode_hyper(p, ); ^ Yes, it does seem to work. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
>
> The above fixes should ensure that all cookies taking values between 0
> and (2^32-1) on the NFS server are preserved through the 32-bit VFS
> interface, and are accepted by glibc as valid entries. It should also
> work fine with existing 64-bit architectures.
>
> Please could people give this a try, and report if it fixes the
> problems.
Have you tried it against a Linux NFS V3 server? When I log in
with my home directory mounted from a Linux NFS V3 server, I
got kernel oops when I do
# cat /proc/mounts
I think the problem may be cookie transform thing.
> --- linux-2.4.2-fh_align/fs/nfs/nfs3xdr.c Fri Feb 9 20:29:44 2001
> +++ linux-2.4.2-dir/fs/nfs/nfs3xdr.c Thu Feb 22 10:47:49 2001
> @@ -523,6 +523,13 @@
> return 0;
> }
>
> +/* Hack to sign-extending 32-bit cookies */
> +static inline
> +u64 nfs_transform_cookie64(u64 cookie)
> +{
> + return (cookie & 0x8000) ? (cookie ^ 0x) : cookie;
> +}
> +
> /*
> * Encode arguments to readdir call
> */
> @@ -533,7 +540,7 @@
> int buflen, replen;
>
> p = xdr_encode_fhandle(p, args->fh);
> - p = xdr_encode_hyper(p, args->cookie);
> + p = xdr_encode_hyper(p, nfs_transform_cookie64(args->cookie));
> *p++ = args->verf[0];
> *p++ = args->verf[1];
> if (args->plus) {
> @@ -635,6 +642,7 @@
> nfs3_decode_dirent(u32 *p, struct nfs_entry *entry, int plus)
> {
> struct nfs_entry old = *entry;
> + u64 cookie;
>
> if (!*p++) {
> if (!*p)
> @@ -648,7 +656,8 @@
> entry->name = (const char *) p;
> p += XDR_QUADLEN(entry->len);
> entry->prev_cookie = entry->cookie;
> - p = xdr_decode_hyper(p, >cookie);
> + p = xdr_decode_hyper(p, cookie);
> + entry->cookie = nfs_transform_cookie64(cookie);
I don't understand this. As far as I can tell, "cookie" is not
initialized at all. Even if it is initialized, what does
p = xdr_decode_hyper(p, cookie);
do?
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
The above fixes should ensure that all cookies taking values between 0
and (2^32-1) on the NFS server are preserved through the 32-bit VFS
interface, and are accepted by glibc as valid entries. It should also
work fine with existing 64-bit architectures.
Please could people give this a try, and report if it fixes the
problems.
Have you tried it against a Linux NFS V3 server? When I log in
with my home directory mounted from a Linux NFS V3 server, I
got kernel oops when I do
# cat /proc/mounts
I think the problem may be cookie transform thing.
--- linux-2.4.2-fh_align/fs/nfs/nfs3xdr.c Fri Feb 9 20:29:44 2001
+++ linux-2.4.2-dir/fs/nfs/nfs3xdr.c Thu Feb 22 10:47:49 2001
@@ -523,6 +523,13 @@
return 0;
}
+/* Hack to sign-extending 32-bit cookies */
+static inline
+u64 nfs_transform_cookie64(u64 cookie)
+{
+ return (cookie 0x8000) ? (cookie ^ 0x) : cookie;
+}
+
/*
* Encode arguments to readdir call
*/
@@ -533,7 +540,7 @@
int buflen, replen;
p = xdr_encode_fhandle(p, args-fh);
- p = xdr_encode_hyper(p, args-cookie);
+ p = xdr_encode_hyper(p, nfs_transform_cookie64(args-cookie));
*p++ = args-verf[0];
*p++ = args-verf[1];
if (args-plus) {
@@ -635,6 +642,7 @@
nfs3_decode_dirent(u32 *p, struct nfs_entry *entry, int plus)
{
struct nfs_entry old = *entry;
+ u64 cookie;
if (!*p++) {
if (!*p)
@@ -648,7 +656,8 @@
entry-name = (const char *) p;
p += XDR_QUADLEN(entry-len);
entry-prev_cookie = entry-cookie;
- p = xdr_decode_hyper(p, entry-cookie);
+ p = xdr_decode_hyper(p, cookie);
+ entry-cookie = nfs_transform_cookie64(cookie);
I don't understand this. As far as I can tell, "cookie" is not
initialized at all. Even if it is initialized, what does
p = xdr_decode_hyper(p, cookie);
do?
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Tue, Feb 27, 2001 at 03:04:32PM -0800, H . J . Lu wrote: entry-prev_cookie = entry-cookie; - p = xdr_decode_hyper(p, entry-cookie); + p = xdr_decode_hyper(p, cookie); + entry-cookie = nfs_transform_cookie64(cookie); I don't understand this. As far as I can tell, "cookie" is not initialized at all. Even if it is initialized, what does p = xdr_decode_hyper(p, cookie); Trond, I think you missed p = xdr_decode_hyper(p, cookie); ^ Yes, it does seem to work. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Tue, Feb 27, 2001 at 07:57:36AM +0100, Trond Myklebust wrote: > >>>>> " " == H J Lu <[EMAIL PROTECTED]> writes: > > > I don't know how it will work with real 64bit cookies on a > > 32bit host for NFS V3 since you truncate it into 32bit during > > sign extension. > > It won't for the moment, but that's a problem with the readdir() API > which uses the 32-bit off_t rather than loff_t for the filldir() I noticed that also. > interface. The reason I added an extra truncation for the value of > file->f_pos (which is used to fill the d_off field only for the last > dirent) was for consistency with this interface. > > I do have a patch to change the format of filldir too, but it'll > probably have to wait until Linux 2.5. > I much prefer to have a new getdents system call which will also return d_type so that the 32 bit function in glibc can use this new getdents instead of getdents64. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote: > > Hi, > > After having tried to thrash out what exactly is the kernel > interface for telldir/seekdir w.r.t. the existence of negative offsets > with the glibc people, I've finally found a way to work within the > current scheme. > > The problem at hand is that we currently would like to support the > existence of directory cookies that take unsigned 32-bit values in > NFSv2, unsigned 64-bit values in NFSv3. > > Given that most NFSv3 servers can/do use 32-bit cookies for > compatibility with 32-bit systems, we would like to be able to pass > this type of cookie back up to userland for use by the 32-bit > interface. > However the interface chosen both in glibc and partly in the kernel > itself assumes all cookies are 32-bit signed values. Thus you have to > find a way to cope with the kernel and glibc sign extending (almost) > all cookies which have bit 31 set. > > The following patch therefore does 3 things: > >- Patch linux/fs/readdir.c so that file->f_pos is copied into the > dirent64 structure with sign extension. This is for consistency > with the behaviour of filldir64. > >- Patch NFSv2 xdr routines so that 32-bit cookies get extended to > take 64-bit signed values (as opposed to unsigned values) for > consistency with the fact that (l|)off_t are both signed. > >- Patch NFSv3 xdr routines with a hack that mimics sign extension > on those cookies which are truly 32-bit unsigned. > To do this we use the transformation > > (cookie & 0x8000) ? cookie ^ 0x : cookie; > > Note that this a transformation has no effect on true 64-bit > cookies because it is reversible. > >- Make a special version of 'lseek()' for NFS directories that > returns 0 if the offset used was negative (rather than returning > the offset itself). This avoids userland misinterpreting the > return value as an error. > > The above fixes should ensure that all cookies taking values between 0 > and (2^32-1) on the NFS server are preserved through the 32-bit VFS > interface, and are accepted by glibc as valid entries. It should also > work fine with existing 64-bit architectures. > > Please could people give this a try, and report if it fixes the > problems. > I don't know how it will work with real 64bit cookies on a 32bit host for NFS V3 since you truncate it into 32bit during sign extension. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote: Hi, After having tried to thrash out what exactly is the kernel interface for telldir/seekdir w.r.t. the existence of negative offsets with the glibc people, I've finally found a way to work within the current scheme. The problem at hand is that we currently would like to support the existence of directory cookies that take unsigned 32-bit values in NFSv2, unsigned 64-bit values in NFSv3. Given that most NFSv3 servers can/do use 32-bit cookies for compatibility with 32-bit systems, we would like to be able to pass this type of cookie back up to userland for use by the 32-bit interface. However the interface chosen both in glibc and partly in the kernel itself assumes all cookies are 32-bit signed values. Thus you have to find a way to cope with the kernel and glibc sign extending (almost) all cookies which have bit 31 set. The following patch therefore does 3 things: - Patch linux/fs/readdir.c so that file-f_pos is copied into the dirent64 structure with sign extension. This is for consistency with the behaviour of filldir64. - Patch NFSv2 xdr routines so that 32-bit cookies get extended to take 64-bit signed values (as opposed to unsigned values) for consistency with the fact that (l|)off_t are both signed. - Patch NFSv3 xdr routines with a hack that mimics sign extension on those cookies which are truly 32-bit unsigned. To do this we use the transformation (cookie 0x8000) ? cookie ^ 0x : cookie; Note that this a transformation has no effect on true 64-bit cookies because it is reversible. - Make a special version of 'lseek()' for NFS directories that returns 0 if the offset used was negative (rather than returning the offset itself). This avoids userland misinterpreting the return value as an error. The above fixes should ensure that all cookies taking values between 0 and (2^32-1) on the NFS server are preserved through the 32-bit VFS interface, and are accepted by glibc as valid entries. It should also work fine with existing 64-bit architectures. Please could people give this a try, and report if it fixes the problems. I don't know how it will work with real 64bit cookies on a 32bit host for NFS V3 since you truncate it into 32bit during sign extension. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Tue, Feb 27, 2001 at 07:57:36AM +0100, Trond Myklebust wrote: " " == H J Lu [EMAIL PROTECTED] writes: I don't know how it will work with real 64bit cookies on a 32bit host for NFS V3 since you truncate it into 32bit during sign extension. It won't for the moment, but that's a problem with the readdir() API which uses the 32-bit off_t rather than loff_t for the filldir() I noticed that also. interface. The reason I added an extra truncation for the value of file-f_pos (which is used to fill the d_off field only for the last dirent) was for consistency with this interface. I do have a patch to change the format of filldir too, but it'll probably have to wait until Linux 2.5. I much prefer to have a new getdents system call which will also return d_type so that the 32 bit function in glibc can use this new getdents instead of getdents64. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A NFS/LFS patch for kernel 2.4.0
Here is a patch for kernel 2.4.0. Without it, kernel 2.4.0 won't pass
the Connectathon Testsuite.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/lockd/clntproc.c.lfs Sun Dec 3 18:01:01 2000
+++ linux/fs/lockd/clntproc.c Thu Jan 25 14:58:42 2001
@@ -142,7 +142,8 @@ nlmclnt_proc(struct inode *inode, int cm
/* If we're cleaning up locks because the process is exiting,
* perform the RPC call asynchronously. */
- if ((cmd == F_SETLK || cmd == F_SETLKW)
+ if ((cmd == F_SETLK || cmd == F_SETLKW
+|| cmd == F_SETLK64 || cmd == F_SETLKW64)
&& fl->fl_type == F_UNLCK
&& (current->flags & PF_EXITING)) {
sigfillset(>blocked); /* Mask all signals */
@@ -166,13 +167,15 @@ nlmclnt_proc(struct inode *inode, int cm
/* Set up the argument struct */
nlmclnt_setlockargs(call, fl);
- if (cmd == F_GETLK) {
+ if (cmd == F_GETLK || cmd == F_GETLK64) {
status = nlmclnt_test(call, fl);
- } else if ((cmd == F_SETLK || cmd == F_SETLKW)
+ } else if ((cmd == F_SETLK || cmd == F_SETLKW
+ || cmd == F_SETLK64 || cmd == F_SETLKW64)
&& fl->fl_type == F_UNLCK) {
status = nlmclnt_unlock(call, fl);
- } else if (cmd == F_SETLK || cmd == F_SETLKW) {
- call->a_args.block = (cmd == F_SETLKW)? 1 : 0;
+ } else if (cmd == F_SETLK || cmd == F_SETLKW
+ || cmd == F_SETLK64 || cmd == F_SETLKW64) {
+ call->a_args.block = (cmd == F_SETLKW) || cmd == F_SETLKW64? 1 : 0;
status = nlmclnt_lock(call, fl);
} else {
status = -EINVAL;
--- linux/fs/locks.c.lfsSun Dec 3 10:24:07 2000
+++ linux/fs/locks.cThu Jan 25 15:12:31 2001
@@ -257,7 +257,7 @@ static int assign_type(struct file_lock
static int flock_to_posix_lock(struct file *filp, struct file_lock *fl,
struct flock *l)
{
- loff_t start;
+ off_t start, end;
switch (l->l_whence) {
case 0: /*SEEK_SET*/
@@ -270,17 +270,16 @@ static int flock_to_posix_lock(struct fi
start = filp->f_dentry->d_inode->i_size;
break;
default:
- return (0);
+ return -EINVAL;
}
if (((start += l->l_start) < 0) || (l->l_len < 0))
- return (0);
- fl->fl_end = start + l->l_len - 1;
- if (l->l_len > 0 && fl->fl_end < 0)
- return (0);
- if (fl->fl_end > OFFT_OFFSET_MAX)
- return 0;
+ return -EINVAL;
+ end = start + l->l_len - 1;
+ if (l->l_len > 0 && end < 0)
+ return -EOVERFLOW;
fl->fl_start = start; /* we record the absolute position */
+ fl->fl_end = end;
if (l->l_len == 0)
fl->fl_end = OFFSET_MAX;
@@ -292,7 +291,7 @@ static int flock_to_posix_lock(struct fi
fl->fl_insert = NULL;
fl->fl_remove = NULL;
- return (assign_type(fl, l->l_type) == 0);
+ return assign_type(fl, l->l_type);
}
#if BITS_PER_LONG == 32
@@ -312,14 +311,14 @@ static int flock64_to_posix_lock(struct
start = filp->f_dentry->d_inode->i_size;
break;
default:
- return (0);
+ return -EINVAL;
}
if (((start += l->l_start) < 0) || (l->l_len < 0))
- return (0);
+ return -EINVAL;
fl->fl_end = start + l->l_len - 1;
if (l->l_len > 0 && fl->fl_end < 0)
- return (0);
+ return -EOVERFLOW;
fl->fl_start = start; /* we record the absolute position */
if (l->l_len == 0)
fl->fl_end = OFFSET_MAX;
@@ -339,10 +338,10 @@ static int flock64_to_posix_lock(struct
fl->fl_type = l->l_type;
break;
default:
- return (0);
+ return -EINVAL;
}
- return (1);
+ return (0);
}
#endif
@@ -1352,8 +1351,8 @@ int fcntl_getlk(unsigned int fd, struct
if (!filp)
goto out;
- error = -EINVAL;
- if (!flock_to_posix_lock(filp, _lock, ))
+ error = flock_to_posix_lock(filp, _lock, );
+ if (error)
goto out_putf;
if (filp->f_op && filp->f_op->lock) {
@@ -1442,8 +1441,8 @@ int fcntl_setlk(unsigned int fd, unsigne
}
}
- error = -EINVAL;
- if (!flock_to_posix_lock(filp, file_lock, ))
+ error = flock_to_posix_lock(filp, file_lock, );
+ if (error)
goto out_putf;
error = -EBADF;
@@ -1517,8 +1516,8 @@ int fcntl_getlk64(unsigned int fd, struc
if (!filp)
goto out;
- error = -EINVAL;
- if (!flock64_to_posix_lock(filp, _lock, ))
+ error = flock64_to_posix_lock(filp, _lock, );
+ if (error)
goto
A NFS/LFS patch for kernel 2.4.0
Here is a patch for kernel 2.4.0. Without it, kernel 2.4.0 won't pass
the Connectathon Testsuite.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/lockd/clntproc.c.lfs Sun Dec 3 18:01:01 2000
+++ linux/fs/lockd/clntproc.c Thu Jan 25 14:58:42 2001
@@ -142,7 +142,8 @@ nlmclnt_proc(struct inode *inode, int cm
/* If we're cleaning up locks because the process is exiting,
* perform the RPC call asynchronously. */
- if ((cmd == F_SETLK || cmd == F_SETLKW)
+ if ((cmd == F_SETLK || cmd == F_SETLKW
+|| cmd == F_SETLK64 || cmd == F_SETLKW64)
fl-fl_type == F_UNLCK
(current-flags PF_EXITING)) {
sigfillset(current-blocked); /* Mask all signals */
@@ -166,13 +167,15 @@ nlmclnt_proc(struct inode *inode, int cm
/* Set up the argument struct */
nlmclnt_setlockargs(call, fl);
- if (cmd == F_GETLK) {
+ if (cmd == F_GETLK || cmd == F_GETLK64) {
status = nlmclnt_test(call, fl);
- } else if ((cmd == F_SETLK || cmd == F_SETLKW)
+ } else if ((cmd == F_SETLK || cmd == F_SETLKW
+ || cmd == F_SETLK64 || cmd == F_SETLKW64)
fl-fl_type == F_UNLCK) {
status = nlmclnt_unlock(call, fl);
- } else if (cmd == F_SETLK || cmd == F_SETLKW) {
- call-a_args.block = (cmd == F_SETLKW)? 1 : 0;
+ } else if (cmd == F_SETLK || cmd == F_SETLKW
+ || cmd == F_SETLK64 || cmd == F_SETLKW64) {
+ call-a_args.block = (cmd == F_SETLKW) || cmd == F_SETLKW64? 1 : 0;
status = nlmclnt_lock(call, fl);
} else {
status = -EINVAL;
--- linux/fs/locks.c.lfsSun Dec 3 10:24:07 2000
+++ linux/fs/locks.cThu Jan 25 15:12:31 2001
@@ -257,7 +257,7 @@ static int assign_type(struct file_lock
static int flock_to_posix_lock(struct file *filp, struct file_lock *fl,
struct flock *l)
{
- loff_t start;
+ off_t start, end;
switch (l-l_whence) {
case 0: /*SEEK_SET*/
@@ -270,17 +270,16 @@ static int flock_to_posix_lock(struct fi
start = filp-f_dentry-d_inode-i_size;
break;
default:
- return (0);
+ return -EINVAL;
}
if (((start += l-l_start) 0) || (l-l_len 0))
- return (0);
- fl-fl_end = start + l-l_len - 1;
- if (l-l_len 0 fl-fl_end 0)
- return (0);
- if (fl-fl_end OFFT_OFFSET_MAX)
- return 0;
+ return -EINVAL;
+ end = start + l-l_len - 1;
+ if (l-l_len 0 end 0)
+ return -EOVERFLOW;
fl-fl_start = start; /* we record the absolute position */
+ fl-fl_end = end;
if (l-l_len == 0)
fl-fl_end = OFFSET_MAX;
@@ -292,7 +291,7 @@ static int flock_to_posix_lock(struct fi
fl-fl_insert = NULL;
fl-fl_remove = NULL;
- return (assign_type(fl, l-l_type) == 0);
+ return assign_type(fl, l-l_type);
}
#if BITS_PER_LONG == 32
@@ -312,14 +311,14 @@ static int flock64_to_posix_lock(struct
start = filp-f_dentry-d_inode-i_size;
break;
default:
- return (0);
+ return -EINVAL;
}
if (((start += l-l_start) 0) || (l-l_len 0))
- return (0);
+ return -EINVAL;
fl-fl_end = start + l-l_len - 1;
if (l-l_len 0 fl-fl_end 0)
- return (0);
+ return -EOVERFLOW;
fl-fl_start = start; /* we record the absolute position */
if (l-l_len == 0)
fl-fl_end = OFFSET_MAX;
@@ -339,10 +338,10 @@ static int flock64_to_posix_lock(struct
fl-fl_type = l-l_type;
break;
default:
- return (0);
+ return -EINVAL;
}
- return (1);
+ return (0);
}
#endif
@@ -1352,8 +1351,8 @@ int fcntl_getlk(unsigned int fd, struct
if (!filp)
goto out;
- error = -EINVAL;
- if (!flock_to_posix_lock(filp, file_lock, flock))
+ error = flock_to_posix_lock(filp, file_lock, flock);
+ if (error)
goto out_putf;
if (filp-f_op filp-f_op-lock) {
@@ -1442,8 +1441,8 @@ int fcntl_setlk(unsigned int fd, unsigne
}
}
- error = -EINVAL;
- if (!flock_to_posix_lock(filp, file_lock, flock))
+ error = flock_to_posix_lock(filp, file_lock, flock);
+ if (error)
goto out_putf;
error = -EBADF;
@@ -1517,8 +1516,8 @@ int fcntl_getlk64(unsigned int fd, struc
if (!filp)
goto out;
- error = -EINVAL;
- if (!flock64_to_posix_lock(filp, file_lock, flock))
+ error = flock64_to_posix_lock(filp, file_lock, flock);
+ if (error)
goto out_putf;
Re: [NFS] [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18)
On Mon, Jan 22, 2001 at 03:36:38PM -0800, H . J . Lu wrote: > On Tue, Jan 23, 2001 at 12:00:29AM +0100, Trond Myklebust wrote: > > >>>>> " " == H J Lu <[EMAIL PROTECTED]> writes: > > > > > I got a report which indicates it may not be a good idea, > > > especially for UDP. Suppose you have a lousy LAN or NFS UDP > > > server for whatever reason, some NFS/UDP packets may get lost > > > very easily while a ping request may get through. In that case, > > > the rpc ping may slow down the NFS client over UDP > > > significantly. > > > > Hi HJ, > > > > Could you clarify this? Don't forget that we only send the ping after > > a major timeout (usually after 3 or more resends). > > > > IOW: If the ping gets through, then it'll have cost us 1 RPC request, > > which is hardly a major contribution when talking about timescales of > > the order of 5 seconds which is what that major timeout will have cost > > (Don't forget that RPC timeout values increase geometrically). > > > > Michael Kriss <[EMAIL PROTECTED]> is having this problem. I think this > problem may be very specific to his network setup. I couldn't duplicate > his problem. My guess is for his case, every ping sent is a loss of > a potential working retry packet. He is using Solaris NFS sever with > Linux client. I had an impression that packets from Solaris NFS server > was dropped quite often. I don't know what happened. > I believe it is a false alarm. It turned out that the interface was not in the full duplex mode. After turning on autonego on switch, everything seems fine now. Sorry for that. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18)
On Mon, Jan 22, 2001 at 03:36:38PM -0800, H . J . Lu wrote: On Tue, Jan 23, 2001 at 12:00:29AM +0100, Trond Myklebust wrote: " " == H J Lu [EMAIL PROTECTED] writes: I got a report which indicates it may not be a good idea, especially for UDP. Suppose you have a lousy LAN or NFS UDP server for whatever reason, some NFS/UDP packets may get lost very easily while a ping request may get through. In that case, the rpc ping may slow down the NFS client over UDP significantly. Hi HJ, Could you clarify this? Don't forget that we only send the ping after a major timeout (usually after 3 or more resends). IOW: If the ping gets through, then it'll have cost us 1 RPC request, which is hardly a major contribution when talking about timescales of the order of 5 seconds which is what that major timeout will have cost (Don't forget that RPC timeout values increase geometrically). Michael Kriss [EMAIL PROTECTED] is having this problem. I think this problem may be very specific to his network setup. I couldn't duplicate his problem. My guess is for his case, every ping sent is a loss of a potential working retry packet. He is using Solaris NFS sever with Linux client. I had an impression that packets from Solaris NFS server was dropped quite often. I don't know what happened. I believe it is a false alarm. It turned out that the interface was not in the full duplex mode. After turning on autonego on switch, everything seems fine now. Sorry for that. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18)
On Tue, Jan 23, 2001 at 12:00:29AM +0100, Trond Myklebust wrote: > >>>>> " " == H J Lu <[EMAIL PROTECTED]> writes: > > > I got a report which indicates it may not be a good idea, > > especially for UDP. Suppose you have a lousy LAN or NFS UDP > > server for whatever reason, some NFS/UDP packets may get lost > > very easily while a ping request may get through. In that case, > > the rpc ping may slow down the NFS client over UDP > > significantly. > > Hi HJ, > > Could you clarify this? Don't forget that we only send the ping after > a major timeout (usually after 3 or more resends). > > IOW: If the ping gets through, then it'll have cost us 1 RPC request, > which is hardly a major contribution when talking about timescales of > the order of 5 seconds which is what that major timeout will have cost > (Don't forget that RPC timeout values increase geometrically). > Michael Kriss <[EMAIL PROTECTED]> is having this problem. I think this problem may be very specific to his network setup. I couldn't duplicate his problem. My guess is for his case, every ping sent is a loss of a potential working retry packet. He is using Solaris NFS sever with Linux client. I had an impression that packets from Solaris NFS server was dropped quite often. I don't know what happened. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18)
On Thu, Dec 14, 2000 at 03:16:36PM +0100, Trond Myklebust wrote: > > Hi, > >One of the things we've been lacking in the Linux implementation of > RPC is the 'ping' routine. The latter is used on most *NIX > implementations in order to test whether or not the RPC server is > alive. To do so, it simply calls procedure-0 (the NULL procedure), > which is always set up to return the value 0 and therefore acts more > or less like the icmp 'ping'. > > The appended patch implements such a routine, and uses it to improve > our congestion control, by allowing the entire set of pending requests > to inquire whether or not the server is alive, and then to sleep for 5 > seconds before retrying. This is done if and only if we get a major > RPC timeout and we see that the client Van Jacobson congestion control > can no longer throttle back the number of pending requests. > > This is more accurate than the current system of just retrying each > request, and waiting for 5 seconds if icmp fails, because the ping > directly tests whether the server is up and responding to > requests. Furthermore, unlike the retried requests, the packet length > of a ping request is always short, so we don't fall prone to issues of > udp fragmentation messing up the test. Finally, because all pending > requests are made to wait on a single ping rather than bombarding the > server with retries, it avoids further congestion to the network. I got a report which indicates it may not be a good idea, especially for UDP. Suppose you have a lousy LAN or NFS UDP server for whatever reason, some NFS/UDP packets may get lost very easily while a ping request may get through. In that case, the rpc ping may slow down the NFS client over UDP significantly. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18)
On Thu, Dec 14, 2000 at 03:16:36PM +0100, Trond Myklebust wrote: Hi, One of the things we've been lacking in the Linux implementation of RPC is the 'ping' routine. The latter is used on most *NIX implementations in order to test whether or not the RPC server is alive. To do so, it simply calls procedure-0 (the NULL procedure), which is always set up to return the value 0 and therefore acts more or less like the icmp 'ping'. The appended patch implements such a routine, and uses it to improve our congestion control, by allowing the entire set of pending requests to inquire whether or not the server is alive, and then to sleep for 5 seconds before retrying. This is done if and only if we get a major RPC timeout and we see that the client Van Jacobson congestion control can no longer throttle back the number of pending requests. This is more accurate than the current system of just retrying each request, and waiting for 5 seconds if icmp fails, because the ping directly tests whether the server is up and responding to requests. Furthermore, unlike the retried requests, the packet length of a ping request is always short, so we don't fall prone to issues of udp fragmentation messing up the test. Finally, because all pending requests are made to wait on a single ping rather than bombarding the server with retries, it avoids further congestion to the network. I got a report which indicates it may not be a good idea, especially for UDP. Suppose you have a lousy LAN or NFS UDP server for whatever reason, some NFS/UDP packets may get lost very easily while a ping request may get through. In that case, the rpc ping may slow down the NFS client over UDP significantly. H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [CFT] Improved RPC congestion handling for 2.4.0 (and 2.2.18)
On Tue, Jan 23, 2001 at 12:00:29AM +0100, Trond Myklebust wrote: " " == H J Lu [EMAIL PROTECTED] writes: I got a report which indicates it may not be a good idea, especially for UDP. Suppose you have a lousy LAN or NFS UDP server for whatever reason, some NFS/UDP packets may get lost very easily while a ping request may get through. In that case, the rpc ping may slow down the NFS client over UDP significantly. Hi HJ, Could you clarify this? Don't forget that we only send the ping after a major timeout (usually after 3 or more resends). IOW: If the ping gets through, then it'll have cost us 1 RPC request, which is hardly a major contribution when talking about timescales of the order of 5 seconds which is what that major timeout will have cost (Don't forget that RPC timeout values increase geometrically). Michael Kriss [EMAIL PROTECTED] is having this problem. I think this problem may be very specific to his network setup. I couldn't duplicate his problem. My guess is for his case, every ping sent is a loss of a potential working retry packet. He is using Solaris NFS sever with Linux client. I had an impression that packets from Solaris NFS server was dropped quite often. I don't know what happened. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lseek patch for 2.2.18pre23
2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks
for proc. Here is a patch.
BTW, ext2 2.4-test10 is ok.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.cThu Nov 23 21:54:58 2000
@@ -120,6 +120,8 @@ static long long ext2_file_lseek(
case 1:
offset += file->f_pos;
}
+ if (offset < 0)
+ return -EINVAL;
if (((unsigned long long) offset >> 32) != 0) {
#if BITS_PER_LONG < 64
return -EINVAL;
--- linux/fs/proc/mem.c.lseek Tue Jan 4 10:12:23 2000
+++ linux/fs/proc/mem.c Sat Nov 18 17:19:28 2000
@@ -196,14 +196,17 @@ static long long mem_lseek(struct file *
{
switch (orig) {
case 0:
- file->f_pos = offset;
- return file->f_pos;
+ break;
case 1:
- file->f_pos += offset;
- return file->f_pos;
+ offset += file->f_pos;
+ break;
default:
return -EINVAL;
}
+ if (offset < 0)
+ return -EINVAL;
+ file->f_pos = offset;
+ return offset;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
lseek patch for 2.2.18pre23
2.2.18pre23 allows lseek to negative offsets in ext2 and has no checks
for proc. Here is a patch.
BTW, ext2 2.4-test10 is ok.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.cThu Nov 23 21:54:58 2000
@@ -120,6 +120,8 @@ static long long ext2_file_lseek(
case 1:
offset += file-f_pos;
}
+ if (offset 0)
+ return -EINVAL;
if (((unsigned long long) offset 32) != 0) {
#if BITS_PER_LONG 64
return -EINVAL;
--- linux/fs/proc/mem.c.lseek Tue Jan 4 10:12:23 2000
+++ linux/fs/proc/mem.c Sat Nov 18 17:19:28 2000
@@ -196,14 +196,17 @@ static long long mem_lseek(struct file *
{
switch (orig) {
case 0:
- file-f_pos = offset;
- return file-f_pos;
+ break;
case 1:
- file-f_pos += offset;
- return file-f_pos;
+ offset += file-f_pos;
+ break;
default:
return -EINVAL;
}
+ if (offset 0)
+ return -EINVAL;
+ file-f_pos = offset;
+ return offset;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: lseek/llseek allows the negative offset
On Sun, Nov 19, 2000 at 04:07:04AM +0100, Andrea Arcangeli wrote:
> On Sat, Nov 18, 2000 at 05:20:34PM -0800, H . J . Lu wrote:
> > Try this again 2.2.18pre21. It works for me.
> >
> >
> > --
> > H.J. Lu ([EMAIL PROTECTED])
> > ---
> > --- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
> > +++ linux/fs/ext2/file.cSat Nov 18 17:19:28 2000
> > @@ -120,6 +120,8 @@ static long long ext2_file_lseek(
> > case 1:
> > offset += file->f_pos;
> > }
> > + if (offset < 0)
> > + return -EINVAL;
> > if (((unsigned long long) offset >> 32) != 0) {
> > #if BITS_PER_LONG < 64
> > return -EINVAL;
>
> It's not enough for 2.2.x (and you left the `>> 32' nosense check).
>
It works for me on ia32. offset is a long long in 2.2.18pre21 on ia32.
I don't see anything wrong for
if (offset < 0)
return -EINVAL;
I got:
lseek(3, 4294967295, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294967294, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294967293, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294967292, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294967291, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 2147483647, SEEK_CUR) = -1 EOVERFLOW (Value too large for defined
data type)
lseek(3, 2147483647, SEEK_CUR) = -1 EOVERFLOW (Value too large for defined
data type)
_llseek(3, 18446744073709551614, 0xb980, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294867296, SEEK_SET) = -1 EINVAL (Invalid argument)
My kernel has LFS patch.
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: lseek/llseek allows the negative offset
On Sun, Nov 19, 2000 at 01:45:12AM +0100, Andrea Arcangeli wrote:
> On Sat, Nov 18, 2000 at 07:25:42PM +0100, Andrea Arcangeli wrote:
> > I fixed it this way:
>
> fix is plain wrong, it's still possible to have lseek return -1 -2 -3 -4
> even when it should return -EINVAL.
>
Try this again 2.2.18pre21. It works for me.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.cSat Nov 18 17:19:28 2000
@@ -120,6 +120,8 @@ static long long ext2_file_lseek(
case 1:
offset += file->f_pos;
}
+ if (offset < 0)
+ return -EINVAL;
if (((unsigned long long) offset >> 32) != 0) {
#if BITS_PER_LONG < 64
return -EINVAL;
--- linux/fs/proc/mem.c.lseek Tue Jan 4 10:12:23 2000
+++ linux/fs/proc/mem.c Sat Nov 18 17:19:28 2000
@@ -196,14 +196,17 @@ static long long mem_lseek(struct file *
{
switch (orig) {
case 0:
- file->f_pos = offset;
- return file->f_pos;
+ break;
case 1:
- file->f_pos += offset;
- return file->f_pos;
+ offset += file->f_pos;
+ break;
default:
return -EINVAL;
}
+ if (offset < 0)
+ return -EINVAL;
+ file->f_pos = offset;
+ return offset;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: lseek/llseek allows the negative offset
On Sat, Nov 18, 2000 at 07:25:42PM +0100, Andrea Arcangeli wrote:
> On Fri, Nov 17, 2000 at 04:09:00PM -0800, H . J . Lu wrote:
> > On Fri, Nov 17, 2000 at 03:59:13PM -0800, H . J . Lu wrote:
> > > # gcc x.c
> > > # ./a.out
> > > lseek on -10: -10
> > > write: File too large
> > >
> > > Should kernel allow negative offsets for lseek/llseek?
> > >
> > >
> >
> > Never mind. I was running the wrong kernel.
>
> With 2.2.18pre21aa2 this little proggy:
>
> main()
> {
> int fd = creat("x", 0600);
> lseek(fd, 0x8000, 0);
> }
>
> get confused this way:
>
> lseek(3, 2147483648, SEEK_SET) = -1 ERRNO_0 (Success)
> _exit(-2147483648) = ?
>
> I fixed it this way:
>
> diff -urN 2.2.18pre21/fs/read_write.c lseek/fs/read_write.c
> --- 2.2.18pre21/fs/read_write.c Tue Sep 5 02:28:49 2000
> +++ lseek/fs/read_write.c Sat Nov 18 18:42:55 2000
> @@ -53,6 +53,10 @@
> struct dentry * dentry;
> struct inode * inode;
>
> + retval = -EINVAL;
> + if (offset < 0)
> + goto out_nolock;
> +
offset shouldn't be < 0 to begin with. There may be a bug somewhere
else. In my case,
if (offset < 0)
return -EINVAL;
is missing from those FS lseek functions.
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: lseek/llseek allows the negative offset
On Sun, Nov 19, 2000 at 01:45:12AM +0100, Andrea Arcangeli wrote:
On Sat, Nov 18, 2000 at 07:25:42PM +0100, Andrea Arcangeli wrote:
I fixed it this way:
fix is plain wrong, it's still possible to have lseek return -1 -2 -3 -4
even when it should return -EINVAL.
Try this again 2.2.18pre21. It works for me.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.cSat Nov 18 17:19:28 2000
@@ -120,6 +120,8 @@ static long long ext2_file_lseek(
case 1:
offset += file-f_pos;
}
+ if (offset 0)
+ return -EINVAL;
if (((unsigned long long) offset 32) != 0) {
#if BITS_PER_LONG 64
return -EINVAL;
--- linux/fs/proc/mem.c.lseek Tue Jan 4 10:12:23 2000
+++ linux/fs/proc/mem.c Sat Nov 18 17:19:28 2000
@@ -196,14 +196,17 @@ static long long mem_lseek(struct file *
{
switch (orig) {
case 0:
- file-f_pos = offset;
- return file-f_pos;
+ break;
case 1:
- file-f_pos += offset;
- return file-f_pos;
+ offset += file-f_pos;
+ break;
default:
return -EINVAL;
}
+ if (offset 0)
+ return -EINVAL;
+ file-f_pos = offset;
+ return offset;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: lseek/llseek allows the negative offset
On Sun, Nov 19, 2000 at 04:07:04AM +0100, Andrea Arcangeli wrote:
On Sat, Nov 18, 2000 at 05:20:34PM -0800, H . J . Lu wrote:
Try this again 2.2.18pre21. It works for me.
--
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/ext2/file.c.lseek Sat Nov 18 17:18:49 2000
+++ linux/fs/ext2/file.cSat Nov 18 17:19:28 2000
@@ -120,6 +120,8 @@ static long long ext2_file_lseek(
case 1:
offset += file-f_pos;
}
+ if (offset 0)
+ return -EINVAL;
if (((unsigned long long) offset 32) != 0) {
#if BITS_PER_LONG 64
return -EINVAL;
It's not enough for 2.2.x (and you left the ` 32' nosense check).
It works for me on ia32. offset is a long long in 2.2.18pre21 on ia32.
I don't see anything wrong for
if (offset 0)
return -EINVAL;
I got:
lseek(3, 4294967295, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294967294, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294967293, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294967292, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294967291, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 2147483647, SEEK_CUR) = -1 EOVERFLOW (Value too large for defined
data type)
lseek(3, 2147483647, SEEK_CUR) = -1 EOVERFLOW (Value too large for defined
data type)
_llseek(3, 18446744073709551614, 0xb980, SEEK_SET) = -1 EINVAL (Invalid argument)
lseek(3, 4294867296, SEEK_SET) = -1 EINVAL (Invalid argument)
My kernel has LFS patch.
H.J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
lseek/llseek allows the negative offset
# gcc x.c
# ./a.out
lseek on -10: -10
write: File too large
Should kernel allow negative offsets for lseek/llseek?
--
H.J. Lu ([EMAIL PROTECTED])
---
#include
#include
#include
extern loff_t llseek (int fd, loff_t offset, int whence);
int
main ()
{
int fd = open ("/tmp/foo.out", O_CREAT | O_RDWR, 0600);
off_t res, pos;
loff_t lres, lpos;
char buffer [] = "negative offset";
if (fd < 0)
{
perror ("open");
return 1;
}
pos = -10;
res = lseek (fd, pos, SEEK_SET);
if (res == (off_t) -1L)
{
perror ("lseek");
close (fd);
return 1;
}
printf ("lseek on %ld: %ld\n", pos, res);
if (write (fd, buffer, sizeof (buffer)) != sizeof (buffer))
{
perror ("write");
close (fd);
return 1;
}
lpos = -10LL;
lres = llseek (fd, lpos, SEEK_SET);
if (lres == (loff_t) -1L)
{
perror ("llseek");
close (fd);
return 1;
}
printf ("llseek on %lld: %lld\n", lpos, lres);
if (write (fd, buffer, sizeof (buffer)) != sizeof (buffer))
{
perror ("write");
close (fd);
return 1;
}
close (fd);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
lseek/llseek allows the negative offset
# gcc x.c
# ./a.out
lseek on -10: -10
write: File too large
Should kernel allow negative offsets for lseek/llseek?
--
H.J. Lu ([EMAIL PROTECTED])
---
#include fcntl.h
#include unistd.h
#include stdio.h
extern loff_t llseek (int fd, loff_t offset, int whence);
int
main ()
{
int fd = open ("/tmp/foo.out", O_CREAT | O_RDWR, 0600);
off_t res, pos;
loff_t lres, lpos;
char buffer [] = "negative offset";
if (fd 0)
{
perror ("open");
return 1;
}
pos = -10;
res = lseek (fd, pos, SEEK_SET);
if (res == (off_t) -1L)
{
perror ("lseek");
close (fd);
return 1;
}
printf ("lseek on %ld: %ld\n", pos, res);
if (write (fd, buffer, sizeof (buffer)) != sizeof (buffer))
{
perror ("write");
close (fd);
return 1;
}
lpos = -10LL;
lres = llseek (fd, lpos, SEEK_SET);
if (lres == (loff_t) -1L)
{
perror ("llseek");
close (fd);
return 1;
}
printf ("llseek on %lld: %lld\n", lpos, lres);
if (write (fd, buffer, sizeof (buffer)) != sizeof (buffer))
{
perror ("write");
close (fd);
return 1;
}
close (fd);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] PROBLEM: 2.2.18pre17 nfs - mount/showmount failed
On Mon, Nov 13, 2000 at 05:58:37AM -0800, [EMAIL PROTECTED] wrote: > > Red Hat 6.2 > server running 2.2.18pre17 and nfs-utils 0.2 When you have a NFS problem, the best thing you can do is to check if your nfs-utils is up to date before you report it. BTW, the current one is 0.2.1. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] PROBLEM: 2.2.18pre17 nfs - mount/showmount failed
On Mon, Nov 13, 2000 at 05:58:37AM -0800, [EMAIL PROTECTED] wrote: Red Hat 6.2 server running 2.2.18pre17 and nfs-utils 0.2 When you have a NFS problem, the best thing you can do is to check if your nfs-utils is up to date before you report it. BTW, the current one is 0.2.1. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
