Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-03-07 Thread Roland McGrath 
> On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote:
> > > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
> > > and [5] is also needed.
> >
> > It's not.  The utrace_regset for the debugregs already has that behavior
> > for those two words, so mapping all 8 uarea words to the regset is fine.
> 
> Sorry, I don't get it. Choosing segment from x86_64_uarea is done before
> calling regset->set and regset->get as well as before zero-filling. No
> segment for u_debugreg[4] and [5] means -EIO before segment handlers
> will have a chance to be called.
> 
> Do you want to consolidate these two?
> 
> {offsetof(struct user, u_debugreg[0]), offsetof(struct user, 
> u_debugreg[4]), 3, 0},
> {offsetof(struct user, u_debugreg[6]), offsetof(struct user, 
> u_debugreg[8]), 3, 6 * sizeof(long)},

Oops!  I was misremembering what was in x86_64_uarea when I wrote that.
I've indeed fixed it to match what I thought it was:

{offsetof(struct user, u_debugreg[0]),
 offsetof(struct user, u_debugreg[8]), 3, 0},


Thanks,
Roland
-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-03-07 Thread Roland McGrath 
 On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote:
   Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
   and [5] is also needed.
 
  It's not.  The utrace_regset for the debugregs already has that behavior
  for those two words, so mapping all 8 uarea words to the regset is fine.
 
 Sorry, I don't get it. Choosing segment from x86_64_uarea is done before
 calling regset-set and regset-get as well as before zero-filling. No
 segment for u_debugreg[4] and [5] means -EIO before segment handlers
 will have a chance to be called.
 
 Do you want to consolidate these two?
 
 {offsetof(struct user, u_debugreg[0]), offsetof(struct user, 
 u_debugreg[4]), 3, 0},
 {offsetof(struct user, u_debugreg[6]), offsetof(struct user, 
 u_debugreg[8]), 3, 6 * sizeof(long)},

Oops!  I was misremembering what was in x86_64_uarea when I wrote that.
I've indeed fixed it to match what I thought it was:

{offsetof(struct user, u_debugreg[0]),
 offsetof(struct user, u_debugreg[8]), 3, 0},


Thanks,
Roland
-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-21 Thread Alexey Dobriyan 
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote:
> > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
> > and [5] is also needed.
>
> It's not.  The utrace_regset for the debugregs already has that behavior
> for those two words, so mapping all 8 uarea words to the regset is fine.

Sorry, I don't get it. Choosing segment from x86_64_uarea is done before
calling regset->set and regset->get as well as before zero-filling. No
segment for u_debugreg[4] and [5] means -EIO before segment handlers
will have a chance to be called.

Do you want to consolidate these two?

{offsetof(struct user, u_debugreg[0]), offsetof(struct user, 
u_debugreg[4]), 3, 0},
{offsetof(struct user, u_debugreg[6]), offsetof(struct user, 
u_debugreg[8]), 3, 6 * sizeof(long)},

-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-21 Thread Alexey Dobriyan 
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote:
  Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
  and [5] is also needed.

 It's not.  The utrace_regset for the debugregs already has that behavior
 for those two words, so mapping all 8 uarea words to the regset is fine.

Sorry, I don't get it. Choosing segment from x86_64_uarea is done before
calling regset-set and regset-get as well as before zero-filling. No
segment for u_debugreg[4] and [5] means -EIO before segment handlers
will have a chance to be called.

Do you want to consolidate these two?

{offsetof(struct user, u_debugreg[0]), offsetof(struct user, 
u_debugreg[4]), 3, 0},
{offsetof(struct user, u_debugreg[6]), offsetof(struct user, 
u_debugreg[8]), 3, 6 * sizeof(long)},

-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-17 Thread Roland McGrath 
> Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
> and [5] is also needed.

It's not.  The utrace_regset for the debugregs already has that behavior
for those two words, so mapping all 8 uarea words to the regset is fine.


Thanks,
Roland
-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-17 Thread Roland McGrath 
 Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
 and [5] is also needed.

It's not.  The utrace_regset for the debugregs already has that behavior
for those two words, so mapping all 8 uarea words to the regset is fine.


Thanks,
Roland
-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-15 Thread Alexey Dobriyan 
On Tue, Feb 13, 2007 at 04:05:30PM +0300, Alexey Dobriyan wrote:
> On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
> > > 2. The following proggie renders box unusable in ~10 seconds (but not
> > >mainline kernel where Ctrl+C will kill process).
> >
> > I haven't been able to reproduce this so far on my test machine.  I got
> > bored after about 10 minutes ("passed: 11920").  The machine remains
> > responsive and the test dies immediately on hitting C-c.  I'll try it on
> > some other machines.  It would help to know what kind of unusable (crashy,
> > leaky, wedgey?).
> 
> This is fresh pull 2.6.20-ec2f9d1331f658433411c58077871e1eef4ee1b4 with
> linux-2.6.20-current-utrace.patch slapped on top (without rejects)
> utrace is on and ptrace is on too.
> 
> the behaviour is
> 
>   $ expl_ptratt
>   passed: 10
>   passed: 20
>   ...
>   passed: [always different number, but in several seconds]
>   [pause]
>   [OOM killer wakes up steadily killing processes ]
>   [messages scroll away   ]
> 
> I'll turn more debugging options now.
> 
> Just in case, .config:

Turning preempt off makes OOM-killings dissapear.

> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> # CONFIG_PREEMPT is not set
> # CONFIG_X86_UP_APIC is not set

-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-15 Thread Alexey Dobriyan 
On Tue, Feb 13, 2007 at 04:05:30PM +0300, Alexey Dobriyan wrote:
 On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
   2. The following proggie renders box unusable in ~10 seconds (but not
  mainline kernel where Ctrl+C will kill process).
 
  I haven't been able to reproduce this so far on my test machine.  I got
  bored after about 10 minutes (passed: 11920).  The machine remains
  responsive and the test dies immediately on hitting C-c.  I'll try it on
  some other machines.  It would help to know what kind of unusable (crashy,
  leaky, wedgey?).
 
 This is fresh pull 2.6.20-ec2f9d1331f658433411c58077871e1eef4ee1b4 with
 linux-2.6.20-current-utrace.patch slapped on top (without rejects)
 utrace is on and ptrace is on too.
 
 the behaviour is
 
   $ expl_ptratt
   passed: 10
   passed: 20
   ...
   passed: [always different number, but in several seconds]
   [pause]
   [OOM killer wakes up steadily killing processes ]
   [messages scroll away   ]
 
 I'll turn more debugging options now.
 
 Just in case, .config:

Turning preempt off makes OOM-killings dissapear.

 # CONFIG_PREEMPT_NONE is not set
 CONFIG_PREEMPT_VOLUNTARY=y
 # CONFIG_PREEMPT is not set
 # CONFIG_X86_UP_APIC is not set

-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-13 Thread Alexey Dobriyan 
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
> > We're aware of two regressions compared to mainline if ptrace is utrace:
>
> Thanks very much for bringing these to my attention.
>
> > 1) zero holes for PTRACE_PEEKUSR vanished.
>
> I've fixed this in the current patches.

Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
and [5] is also needed.

--- a/arch/x86_64/kernel/ptrace.c
+++ b/arch/x86_64/kernel/ptrace.c
@@ -687,6 +687,8 @@ EXPORT_SYMBOL_GPL(utrace_x86_64_native);
 #ifdef CONFIG_PTRACE
 static const struct ptrace_layout_segment x86_64_uarea[] = {
{0, sizeof(struct user_regs_struct), 0, 0},
+   {sizeof(struct user_regs_struct),
+offsetof(struct user, u_debugreg[0]), -1, 0},
{offsetof(struct user, u_debugreg[0]),
 offsetof(struct user, u_debugreg[4]), 3, 0},
{offsetof(struct user, u_debugreg[6]),

-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-13 Thread Alexey Dobriyan 
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
> > 2. The following proggie renders box unusable in ~10 seconds (but not
> >mainline kernel where Ctrl+C will kill process).
>
> I haven't been able to reproduce this so far on my test machine.  I got
> bored after about 10 minutes ("passed: 11920").  The machine remains
> responsive and the test dies immediately on hitting C-c.  I'll try it on
> some other machines.  It would help to know what kind of unusable (crashy,
> leaky, wedgey?).

This is fresh pull 2.6.20-ec2f9d1331f658433411c58077871e1eef4ee1b4 with
linux-2.6.20-current-utrace.patch slapped on top (without rejects)
utrace is on and ptrace is on too.

the behaviour is

$ expl_ptratt
passed: 10
passed: 20
...
passed: [always different number, but in several seconds]
[pause]
[OOM killer wakes up steadily killing processes ]
[messages scroll away   ]

I'll turn more debugging options now.

Just in case, .config:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20
# Tue Feb 13 15:28:38 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_IPC_NS=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
CONFIG_UTS_NS=y
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Process debugging support
#
CONFIG_UTRACE=y
CONFIG_PTRACE=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-13 Thread Alexey Dobriyan 
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
  2. The following proggie renders box unusable in ~10 seconds (but not
 mainline kernel where Ctrl+C will kill process).

 I haven't been able to reproduce this so far on my test machine.  I got
 bored after about 10 minutes (passed: 11920).  The machine remains
 responsive and the test dies immediately on hitting C-c.  I'll try it on
 some other machines.  It would help to know what kind of unusable (crashy,
 leaky, wedgey?).

This is fresh pull 2.6.20-ec2f9d1331f658433411c58077871e1eef4ee1b4 with
linux-2.6.20-current-utrace.patch slapped on top (without rejects)
utrace is on and ptrace is on too.

the behaviour is

$ expl_ptratt
passed: 10
passed: 20
...
passed: [always different number, but in several seconds]
[pause]
[OOM killer wakes up steadily killing processes ]
[messages scroll away   ]

I'll turn more debugging options now.

Just in case, .config:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20
# Tue Feb 13 15:28:38 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_IPC_NS=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
CONFIG_UTS_NS=y
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Process debugging support
#
CONFIG_UTRACE=y
CONFIG_PTRACE=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=cfq

#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
# CONFIG_EDD

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-13 Thread Alexey Dobriyan 
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
  We're aware of two regressions compared to mainline if ptrace is utrace:

 Thanks very much for bringing these to my attention.

  1) zero holes for PTRACE_PEEKUSR vanished.

 I've fixed this in the current patches.

Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
and [5] is also needed.

--- a/arch/x86_64/kernel/ptrace.c
+++ b/arch/x86_64/kernel/ptrace.c
@@ -687,6 +687,8 @@ EXPORT_SYMBOL_GPL(utrace_x86_64_native);
 #ifdef CONFIG_PTRACE
 static const struct ptrace_layout_segment x86_64_uarea[] = {
{0, sizeof(struct user_regs_struct), 0, 0},
+   {sizeof(struct user_regs_struct),
+offsetof(struct user, u_debugreg[0]), -1, 0},
{offsetof(struct user, u_debugreg[0]),
 offsetof(struct user, u_debugreg[4]), 3, 0},
{offsetof(struct user, u_debugreg[6]),

-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-12 Thread Roland McGrath 
> We're aware of two regressions compared to mainline if ptrace is utrace:

Thanks very much for bringing these to my attention.

> 1) zero holes for PTRACE_PEEKUSR vanished.

I've fixed this in the current patches.

> 2. The following proggie renders box unusable in ~10 seconds (but not
>mainline kernel where Ctrl+C will kill process).

I haven't been able to reproduce this so far on my test machine.  I got
bored after about 10 minutes ("passed: 11920").  The machine remains
responsive and the test dies immediately on hitting C-c.  I'll try it on
some other machines.  It would help to know what kind of unusable (crashy,
leaky, wedgey?).


Thanks,
Roland
-
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/

utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-12 Thread Alexey Dobriyan 
> utrace-utrace-tracehook.patch
> utrace-utrace-tracehook-ia64.patch
> utrace-utrace-tracehook-sparc64.patch
> utrace-utrace-tracehook-s390.patch
> utrace-utrace-regset.patch
> utrace-utrace-regset-ia64.patch
> utrace-utrace-regset-sparc64.patch
> utrace-utrace-regset-s390.patch
> utrace-utrace-core.patch
> utrace-utrace-ptrace-compat.patch
> utrace-utrace-ptrace-compat-ia64.patch
> utrace-utrace-ptrace-compat-sparc64.patch
> utrace-utrace-ptrace-compat-s390.patch

>  utrace just got added to -mm.

We're aware of two regressions compared to mainline if ptrace is utrace:


1) zero holes for PTRACE_PEEKUSR vanished.

  strace(1) when sees unknown syscall, does something like:

for (i = 0; i < MAX_ARGS; i++)
if (ptrace(PTRACE_PEEKUSR, i * 4, ...) < 0)
return -1;

  since THREAD_SIZE is 17 on x86 which is less that MAX_ARGS (32 on
  x86), you'll get -EIO(utrace) or 0(ptrace) when i=0.

  No new syscalls stracing for developers.

Proposed patch:

--- a/arch/i386/kernel/ptrace.c
+++ b/arch/i386/kernel/ptrace.c
@@ -728,6 +728,7 @@ EXPORT_SYMBOL_GPL(utrace_i386_native);
 #ifdef CONFIG_PTRACE
 static const struct ptrace_layout_segment i386_uarea[] = {
{0, FRAME_SIZE*4, 0, 0},
+   {FRAME_SIZE*4, offsetof(struct user, u_debugreg[0]), -1, 0},
{offsetof(struct user, u_debugreg[0]),
 offsetof(struct user, u_debugreg[8]), 4, 0},
{0, 0, -1, 0}


Looks like x86_64 also needs zero holes added, haven't checked in runtime.

---

2. The following proggie renders box unusable in ~10 seconds (but not
   mainline kernel where Ctrl+C will kill process).


#include 
#include 
#include 
#include 
#include 

static void *thread_func(void *arg)
{
execl("/proc/self/exe", NULL);
return NULL;
}

int main(int argc, const char *argv[])
{
pthread_t thread;
int pid, n;

if (argv[0] && (pid = fork()))
for (n = 1; /*n < 100*/; ++n) {
ptrace(PTRACE_ATTACH, pid, NULL, 0);
ptrace(PTRACE_DETACH, pid, NULL, 0);
if (!(n % 10))
printf("passed: %d\n", n);
}

if (pthread_create(, NULL, thread_func, NULL))
perror("pthread_create");

while (1)
pause();
return 1;
}

-
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/

utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-12 Thread Alexey Dobriyan 
 utrace-utrace-tracehook.patch
 utrace-utrace-tracehook-ia64.patch
 utrace-utrace-tracehook-sparc64.patch
 utrace-utrace-tracehook-s390.patch
 utrace-utrace-regset.patch
 utrace-utrace-regset-ia64.patch
 utrace-utrace-regset-sparc64.patch
 utrace-utrace-regset-s390.patch
 utrace-utrace-core.patch
 utrace-utrace-ptrace-compat.patch
 utrace-utrace-ptrace-compat-ia64.patch
 utrace-utrace-ptrace-compat-sparc64.patch
 utrace-utrace-ptrace-compat-s390.patch

  utrace just got added to -mm.

We're aware of two regressions compared to mainline if ptrace is utrace:


1) zero holes for PTRACE_PEEKUSR vanished.

  strace(1) when sees unknown syscall, does something like:

for (i = 0; i  MAX_ARGS; i++)
if (ptrace(PTRACE_PEEKUSR, i * 4, ...)  0)
return -1;

  since THREAD_SIZE is 17 on x86 which is less that MAX_ARGS (32 on
  x86), you'll get -EIO(utrace) or 0(ptrace) when i=0.

  No new syscalls stracing for developers.

Proposed patch:

--- a/arch/i386/kernel/ptrace.c
+++ b/arch/i386/kernel/ptrace.c
@@ -728,6 +728,7 @@ EXPORT_SYMBOL_GPL(utrace_i386_native);
 #ifdef CONFIG_PTRACE
 static const struct ptrace_layout_segment i386_uarea[] = {
{0, FRAME_SIZE*4, 0, 0},
+   {FRAME_SIZE*4, offsetof(struct user, u_debugreg[0]), -1, 0},
{offsetof(struct user, u_debugreg[0]),
 offsetof(struct user, u_debugreg[8]), 4, 0},
{0, 0, -1, 0}


Looks like x86_64 also needs zero holes added, haven't checked in runtime.

---

2. The following proggie renders box unusable in ~10 seconds (but not
   mainline kernel where Ctrl+C will kill process).


#include stdio.h
#include unistd.h
#include pthread.h
#include sys/ptrace.h
#include signal.h

static void *thread_func(void *arg)
{
execl(/proc/self/exe, NULL);
return NULL;
}

int main(int argc, const char *argv[])
{
pthread_t thread;
int pid, n;

if (argv[0]  (pid = fork()))
for (n = 1; /*n  100*/; ++n) {
ptrace(PTRACE_ATTACH, pid, NULL, 0);
ptrace(PTRACE_DETACH, pid, NULL, 0);
if (!(n % 10))
printf(passed: %d\n, n);
}

if (pthread_create(thread, NULL, thread_func, NULL))
perror(pthread_create);

while (1)
pause();
return 1;
}

-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-12 Thread Roland McGrath 
 We're aware of two regressions compared to mainline if ptrace is utrace:

Thanks very much for bringing these to my attention.

 1) zero holes for PTRACE_PEEKUSR vanished.

I've fixed this in the current patches.

 2. The following proggie renders box unusable in ~10 seconds (but not
mainline kernel where Ctrl+C will kill process).

I haven't been able to reproduce this so far on my test machine.  I got
bored after about 10 minutes (passed: 11920).  The machine remains
responsive and the test dies immediately on hitting C-c.  I'll try it on
some other machines.  It would help to know what kind of unusable (crashy,
leaky, wedgey?).


Thanks,
Roland
-
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/