r it some of your zero-initialized
variables won't be zero initialized at all.
In the linked message, set_brk is passed elf_bss so its actual
arguments are set_brk (0xa3801, 0x000a4ec8). It should map one
page. 0xa3801 should be an already mapped page, and clear_user should
succeed in clearing i
, set_brk is passed elf_bss so its actual
arguments are set_brk (0xa3801, 0x000a4ec8). It should map one
page. 0xa3801 should be an already mapped page, and clear_user should
succeed in clearing it.
--
Daniel Jacobowitz
CodeSourcery
--
To unsubscribe from this list: send the line unsubscribe linux
vax - but don't quote
me on that, I had to guess from the configure script.
--
Daniel Jacobowitz
CodeSourcery
-
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/majordom
on that, I had to guess from the configure script.
--
Daniel Jacobowitz
CodeSourcery
-
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
he kernel is fixed,
verify it, and then probably adjust the GDB test to pass on either
patched or unpatched kernels.
--
Daniel Jacobowitz
CodeSourcery
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
is fixed,
verify it, and then probably adjust the GDB test to pass on either
patched or unpatched kernels.
--
Daniel Jacobowitz
CodeSourcery
-
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
e->i_nlink == 0;
>
> - /* If it hasn't been written to, don't write it out */
> - if (!vma->anon_vma)
> + /* If it is executable and hasn't been written to,
> + * don't write it out.
> + */
> + if ((vma->vm_flags & VM_EXEC) && !
From: Daniel Jacobowitz <[EMAIL PROTECTED]>
Do not implement CLONE_PARENT_SETTID until we know that clone will succeed.
If we do it too early NPTL's data structures temporarily reference a
non-existant TID.
Signed-off-by: Daniel Jacobowitz <[EMAIL PROTECTED]>
---
On Tue, Sep 26, 2
From: Daniel Jacobowitz [EMAIL PROTECTED]
Do not implement CLONE_PARENT_SETTID until we know that clone will succeed.
If we do it too early NPTL's data structures temporarily reference a
non-existant TID.
Signed-off-by: Daniel Jacobowitz [EMAIL PROTECTED]
---
On Tue, Sep 26, 2006 at 08:59:15PM
it out */
- if (!vma-anon_vma)
+ /* If it is executable and hasn't been written to,
+ * don't write it out.
+ */
+ if ((vma-vm_flags VM_EXEC) !vma-anon_vma)
return 0;
return 1;
--
Daniel Jacobowitz
CodeSourcery
-
To unsubscribe from
nd this _seems_ to fix it too:
>
> taskset -p 1 `ps axo comm,pid|awk '$1=="X"{print $2}'`
>
> I haven't seen this problem on the console.
This is probably the same problem as the earlier one you reported. If
you take a look at bugzilla, you'll see that the normal manif
haven't seen this problem on the console.
This is probably the same problem as the earlier one you reported. If
you take a look at bugzilla, you'll see that the normal manifestation
is messed up key repeat rates...
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send
> 15 251 + 0 = 251
> 16 147 + 1 = 148 <==
> 17 0 + 252 = 252
Hmm, very interesting.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
Hmm, very interesting.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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
I'd expect, although there are still a handful of
kernel-related failures (vsyscall related?).
Signed-off-by: Daniel Jacobowitz <[EMAIL PROTECTED]>
diff -r -p -u z/linux-2.6.11/arch/x86_64/ia32/ptrace32.c
linux-2.6.11/arch/x86_64/ia32/ptrace32.c
--- linux-2.6.12.3.orig/arch/x86_64/ia32/ptra
I'd expect, although there are still a handful of
kernel-related failures (vsyscall related?).
Signed-off-by: Daniel Jacobowitz [EMAIL PROTECTED]
diff -r -p -u z/linux-2.6.11/arch/x86_64/ia32/ptrace32.c
linux-2.6.11/arch/x86_64/ia32/ptrace32.c
--- linux-2.6.12.3.orig/arch/x86_64/ia32/ptrace32.c
done
something clever to the value of %ebp.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
match that of i386 kernels.
Wouldn't this to botch a debugger which supported both backtracing and
PTRACE_SYSCALL, when stopped in a syscall? We have unwind information
for the VDSO and it's not going to tell us that the kernel has done
something clever to the value of %ebp.
--
Daniel
37MB worth of patch-code ? I would expect something about
> 2MB but 40MB ?
Try interdiff -p1?
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
?
Try interdiff -p1?
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
> *word* size...
While true, this is easily fixable. There is even an interface
precedent on OpenBSD (and possibly other platforms as well).
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Even with hundreds of kilobytes of patch, I have trouble imagining this
takes a substantial amount of time.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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
mprotect in a debugged
process, also.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
of patch, I have trouble imagining this
takes a substantial amount of time.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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
...
While true, this is easily fixable. There is even an interface
precedent on OpenBSD (and possibly other platforms as well).
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
emon is running) makes no
> sense, does it?
That argument doesn't make much sense to me. But we're at the end of
my useful contributions to this discussion; I'm going to be quiet now
and hope some folks who know more about filesystems have more useful
responses.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To
group/other? Sure, it
makes your tarfs a little less mapped onto the tar file. But that's
one of the recurring objections to implementing archivers as
filesystems: the ownership in the archive is _not_ relevant to the
mounted copy.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from th
eems not unreasonable - provided the
> administrator can delete the directory (which is possible with
> detachable mount points).
Because then they could mount over /tmp. "and (is not sticky || is
owned by the user)" may be more appropriate.
--
Daniel Jacobowitz
CodeSourcery, LLC
l need to know anything about this? Why can't
the userspace library present the permissions appropriately to the
kernel? I'm going to be pretty confused if I see a mode 666 file that
I can't even read. So will various programs.
Except for the allow_root bits, I think that having userspace handle
n think of plenty of uses for this.
> 4) Access should not be further restricted for the owner of the
> mount, even if permission bits, uid or gid would suggest
> otherwise
Similar questions.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line &quo
for this.
4) Access should not be further restricted for the owner of the
mount, even if permission bits, uid or gid would suggest
otherwise
Similar questions.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
would cover both objections.
Does this answer your questions?
More or less.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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
the
administrator can delete the directory (which is possible with
detachable mount points).
Because then they could mount over /tmp. and (is not sticky || is
owned by the user) may be more appropriate.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line
: the ownership in the archive is _not_ relevant to the
mounted copy.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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
doesn't make much sense to me. But we're at the end of
my useful contributions to this discussion; I'm going to be quiet now
and hope some folks who know more about filesystems have more useful
responses.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line
_REBOOT_CMD_RESTART.
LINUX_REBOOT_CMD_CAD_OFF
(RB_DISABLE_CAD, 0). CAD is disabled. This means that the CAD
keystroke will cause a SIGINT signal to be sent to init
(process 1), whereupon this process may decide upon a
proper action
My impression is that the MIPS story isn't so simple, because the
architecture only offers very weak coherency guarantees. Most of the
SMP implementations offer strong coherency in practice, but at least
one (RM9000) doesn't.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: sen
, but at least
one (RM9000) doesn't.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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
keystroke will cause a SIGINT signal to be sent to init
(process 1), whereupon this process may decide upon a
proper action (maybe: kill all processes, sync, reboot).
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line unsubscribe
the "if (!card)" can not be
reached without passing through "card->amplifier", and a pointer which
is dereferenced can not be NULL in a valid program.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
with -O0, it will oops.
The thing GCC is most likely to do with this code is discard the NULL
check entirely and leave only the oops; the if (!card) can not be
reached without passing through card-amplifier, and a pointer which
is dereferenced can not be NULL in a valid program.
--
Daniel
open. Hmm, server is x86_64 2.6.7, client is 2.6.10
MIPS. I should upgrade them and see if that helps.
Unfortunately I haven't found any smaller testcases than installing an
entire root FS.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line "u
On Sun, Mar 13, 2005 at 03:42:29PM -0500, Trond Myklebust wrote:
> su den 13.03.2005 Klokka 15:04 (-0500) skreiv Daniel Jacobowitz:
>
> > I can't find any documentation about this, but it seems like the same
> > problem that has been causing me headaches lately; when I repl
acro, which is called
> before the ptrace stop for whatever signal results from whatever kind of
> fault in that instruction (or asynchronous signal). With that, the
> handle_signal check is still needed only for the case of PTRACE_SINGLESTEP
> with a handled signal.
>
>
> T
erver side of an nfsroot, the client has a couple of
variously wrong reads before it sees the new files. If it breaks NFS
so badly, why is it the default for the Linux NFS server?
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
that has been causing me headaches lately; when I replace glibc
from the server side of an nfsroot, the client has a couple of
variously wrong reads before it sees the new files. If it breaks NFS
so badly, why is it the default for the Linux NFS server?
--
Daniel Jacobowitz
CodeSourcery, LLC
results from whatever kind of
fault in that instruction (or asynchronous signal). With that, the
handle_signal check is still needed only for the case of PTRACE_SINGLESTEP
with a handled signal.
Thanks,
Roland
Thanks, looks right to me!
--
Daniel Jacobowitz
CodeSourcery, LLC
On Sun, Mar 13, 2005 at 03:42:29PM -0500, Trond Myklebust wrote:
su den 13.03.2005 Klokka 15:04 (-0500) skreiv Daniel Jacobowitz:
I can't find any documentation about this, but it seems like the same
problem that has been causing me headaches lately; when I replace glibc
from the server
is x86_64 2.6.7, client is 2.6.10
MIPS. I should upgrade them and see if that helps.
Unfortunately I haven't found any smaller testcases than installing an
entire root FS.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
's flavor, but no writing is ever
> possible to the fixmap page.
Blech. I assume that there is no way to map a normal VMA over top of
the fixed page, for a particular process? This makes debugging the
vsyscall DSO a real pain.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe fro
that there is no way to map a normal VMA over top of
the fixed page, for a particular process? This makes debugging the
vsyscall DSO a real pain.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
about, but it was KFAIL before the change too.
That is an inability to set breakpoints in the vsyscall page. Andrew
told me (last May, wow) that he thought this worked in Fedora, but I
haven't seen any signs of the code. It would certainly be a Good Thing
if it is possible!
>
--
Da
, it occurs because a bogus TF bit was saved
to the signal context. I like keeping solutions close to their
problems. But that's just aesthetic.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
l context. Otherwise, TF will be incorrectly restored by
sigreturn.
Signed-off-by: Daniel Jacobowitz <[EMAIL PROTECTED]>
= arch/i386/kernel/signal.c 1.53 vs edited =
--- 1.53/arch/i386/kernel/signal.c 2005-01-31 01:20:14 -05:00
+++ edited/arch/i386/kernel/signal.c2005-03-06
On Sun, Mar 06, 2005 at 02:38:41PM -0500, Daniel Jacobowitz wrote:
> The reason this happens is that when the inferior hits a breakpoint, the
> first thing GDB will do is remove the breakpoint, single-step past it, and
> reinsert it. So GDB does a PTRACE_SINGLESTEP, and the kerne
ow when we restore the trap bit in sigreturn
whether it was set by ptrace or by the application (possibly including by
the signal handler).
Andrew, serious kudos for GDB's sigstep.exp, which uncovered this problem
(through a much more complicated test - I may add the smaller one).
--
Daniel
).
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
On Sun, Mar 06, 2005 at 02:38:41PM -0500, Daniel Jacobowitz wrote:
The reason this happens is that when the inferior hits a breakpoint, the
first thing GDB will do is remove the breakpoint, single-step past it, and
reinsert it. So GDB does a PTRACE_SINGLESTEP, and the kernel invokes
by
sigreturn.
Signed-off-by: Daniel Jacobowitz [EMAIL PROTECTED]
= arch/i386/kernel/signal.c 1.53 vs edited =
--- 1.53/arch/i386/kernel/signal.c 2005-01-31 01:20:14 -05:00
+++ edited/arch/i386/kernel/signal.c2005-03-06 15:36:41 -05:00
@@ -277,6 +277,18 @@
{
int tmp, err = 0
equivalent to the one I just posted for this testcase.
I think mine is more correct; the problem doesn't occur because the
debugger cancelled a signal, it occurs because a bogus TF bit was saved
to the signal context. I like keeping solutions close to their
problems. But that's just aesthetic.
--
Daniel
) that he thought this worked in Fedora, but I
haven't seen any signs of the code. It would certainly be a Good Thing
if it is possible!
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
pers who are using tools with this
patch applied already. Also, I anticipate the release of binutils 2.16
including the fix in about a month.
> And yes, the toolchain peoples point of view is "fix the kernel".
Huh? Obviously the kernel isn't broken, unless you're talking abou
a month.
And yes, the toolchain peoples point of view is fix the kernel.
Huh? Obviously the kernel isn't broken, unless you're talking about
the kallsyms checks now.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
t sysn32_waitid.
Ralf, I'll let you sort it out :-)
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
:-)
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
ot;);
return 1;
}
size_t len2 = fpathconf (fds[1], _PC_PIPE_BUF);
size_t page_size = sysconf (_SC_PAGESIZE);
len2 = (len2 < page_size ? page_size : len2) + 1 + 1;
char *mem2 = malloc (len2);
pthread_create (, NULL, tf, fds);
write (fds[1], mem2, len2);
return 0;
}
[/snip]
);
return 0;
}
[/snip]
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
e why this is a problem - the kernel probably assumes
that any segment with MemSiz > FileSiz will be writable. Certainly
it's a bit weird for the app to request unwritable zeroed pages.
clear_user's probably not the right way to provide the extra zeroing.
--
Daniel Jacobowitz
CodeSourcery, LL
that any segment with MemSiz FileSiz will be writable. Certainly
it's a bit weird for the app to request unwritable zeroed pages.
clear_user's probably not the right way to provide the extra zeroing.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line
clearing the BSS fail? Are the program headers bogus?
(readelf -l).
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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.ht
? Are the program headers bogus?
(readelf -l).
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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
it fell down like this on a constant basis.
You might want to take a look at 'xcvs', by Jun Sun. It's much more
reliable and does everything I used to use cvsps for. And generally
faster too.
--
Daniel Jacobowitz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
basis.
You might want to take a look at 'xcvs', by Jun Sun. It's much more
reliable and does everything I used to use cvsps for. And generally
faster too.
--
Daniel Jacobowitz
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
suppose you could change this with chrpath,
> but why bother? What if you want to test out two versions of relative
> libraries side by side?
You might want to take a look at Richard's suggestion again. The
string '$ORIGIN' gets hardcoded into the binary and handled by the
dynamic link
to ptrace()
> that remedies the situation.
This has since been done in 2.5.x; see PTRACE_EVENT_FORK. GDB even
uses it nowadays. I'm not sure if strace does.
--
Daniel Jacobowitz
-
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/
have little confidence in its security to prevent
children from escaping a ptrace() jail, so I added a feature to ptrace()
that remedies the situation.
This has since been done in 2.5.x; see PTRACE_EVENT_FORK. GDB even
uses it nowadays. I'm not sure if strace does.
--
Daniel Jacobowitz
by side?
You might want to take a look at Richard's suggestion again. The
string '$ORIGIN' gets hardcoded into the binary and handled by the
dynamic linker.
But really, RPATH is a good solution to almost no problems.
--
Daniel Jacobowitz
-
To unsubscribe from this list: send the line unsubscribe
return;
+ }
+ }
+#endif
if (!(pcicmd & PCI_COMMAND_IO)) { /* is device disabled? */
/*
* PnP BIOS was *supposed* to have set this device up for us,
Dan
/\ /
79 matches
Mail list logo
