testing 65c1a81f6ad628240445ba24d888d25b2fd69c1e:
alpha: ok
arm: ok
hppa: ok
ia64: ok
ppc: ok
ppc64: hangs hard when tracing forks
s390: my system is down atm ...
sh: ok
sparc: build failure
hth
-mike
signature.asc
Description: This is a digitally signed message part.
--
你好
我司可优惠代办贸促会证明书,等各类CIQ证书,CO产地证.普惠证(FA,FE,
FF,亚太,中巴)等各类清关证书。提供大小核销单（出口报关单）.厂家可合作 退税单‘贴息单
代理商检 ， 深圳进出口报关等业务
如有业务需要可来电咨询：张先生（业务经理）
联系电话：0755--25420177手机：13686868548
QQ：122062143 邮箱：szyongdongjia...@163.com
* syscall.c (trace_syscall_entering): Check for sys_exit instead of
SYS_exit to handle exit_group(2) as well as _exit(2).
---
Before the fix:
$ strace -e exit_group -e raw=all /bin/true
exit_group(0
After the fix:
$ strace -e exit_group -e raw=all /bin/true
exit_group(0)
* syscall.c (known_scno): Do not check for native_scno field on
platforms that support only one personality.
---
native_scno was implemented for platforms with multiple personalities.
On platforms that support only one personality,
tcp->scno + NR_SYSCALL_BASE is already native.
native_scno is curr
The (known_scno(tcp) == __NR_exit_group) check introduced along with
native_scno makes that specific IA64 test redundant.
--- a/process.c
+++ b/process.c
@@ -443,18 +443,11 @@ struct tcb *tcp;
}
int
-internal_exit(tcp)
-struct tcb *tcp;
+internal_exit(struct tcb *tcp)
{
if (entering(t
> For my use cases, it's acceptable to expect the user to enter a
> canonical path and expect the program to open the file with a
> canonical path. I expect that there are other common use cases where
> that's not acceptable.
That seems fine enough to start out with, and worry about more later.
I
> Is /proc/$pid/cwd less reliable than /proc/$pid/fd/$fd?
No, they all use the same mechanism. What those report are from the
perspective of the readlink caller, i.e. strace's view of the filesystem
rather than the tracee's. (I'm not entirely sure how that interacts
with per-process mount points
On 2011-02-18, Roland McGrath wrote:
>> We could canonicalize absolute pathname arguments.
>> We even could canonicalize relative pathname arguments using
>> /proc/$pid/cwd.
>> But I'm not sure now whether we really need this or not.
>
> Given per-process mount namespace, this could be error prone
On 2011-02-18, Dmitry V. Levin wrote:
> On Fri, Feb 18, 2011 at 05:03:38PM +, Grant Edwards wrote:
> [...]
>> Do we still need to do something to deal with the symlink vs.
>> canonical question for syscalls like stat()?
>
> We could canonicalize absolute pathname arguments. We even could
> can
On Fri, Feb 18, 2011 at 02:49:54PM -0800, Roland McGrath wrote:
> > We could canonicalize absolute pathname arguments.
> > We even could canonicalize relative pathname arguments using
> > /proc/$pid/cwd.
> > But I'm not sure now whether we really need this or not.
>
> Given per-process mount names
On 2011-02-18, Dmitry V. Levin wrote:
> On Fri, Feb 18, 2011 at 05:25:30PM +, Grant Edwards wrote:
> [...]
>> > I agree that the fd's returned from open() and creat() should be
>> > checked for a match.
>>
>> However, I now see that checking the file descriptors returned by a
>> system call i
> We could canonicalize absolute pathname arguments.
> We even could canonicalize relative pathname arguments using
> /proc/$pid/cwd.
> But I'm not sure now whether we really need this or not.
Given per-process mount namespace, this could be error prone.
At least, it takes extra care to consider /
On Fri, Feb 18, 2011 at 05:03:38PM +, Grant Edwards wrote:
[...]
> Do we still need to do something to deal with the symlink vs.
> canonical question for syscalls like stat()?
We could canonicalize absolute pathname arguments.
We even could canonicalize relative pathname arguments using
/proc/
On 2011-02-18, Dmitry V. Levin wrote:
>> I'm going to work on checking the fd's referred in the args to the
>> poll/select calls.
>
> OK
>
>> Are there other calls in that list that have
>> path/fd arguments that should be tested?
>
> printargs is used to handle a few syscalls that have no indi
On Fri, Feb 18, 2011 at 05:25:30PM +, Grant Edwards wrote:
[...]
> > I agree that the fd's returned from open() and creat() should be
> > checked for a match.
>
> However, I now see that checking the file descriptors returned by a
> system call is problematic. When the check is done in
> trac
On Fri, Feb 18, 2011 at 04:20:24PM +, Grant Edwards wrote:
[...]
> if (s->sys_func == printargs ||
> s->sys_func == sys_pipe ||
> s->sys_func == sys_pipe2 ||
> s->sys_func == sys_eventfd2 ||
> s->sys_func == sys_eventfd ||
> s->sys_func == sys_inotify_init1
On 2011-02-18, Grant Edwards wrote:
> On 2011-02-18, Grant Edwards wrote:
>
>>> I'm not sure that we can ignore all cases where syscalls return file
>>> descriptor as their return value.
>>
>> That wasn't my intent, and I don't think that's what the code does.
>>
>> I meant to ignore system calls
On 2011-02-18, Grant Edwards wrote:
>> I'm not sure that we can ignore all cases where syscalls return file
>> descriptor as their return value.
>
> That wasn't my intent, and I don't think that's what the code does.
>
> I meant to ignore system calls who returned file descriptors (and
> therefor
On 2011-02-18, Dmitry V. Levin wrote:
> On Thu, Feb 17, 2011 at 11:29:27AM -0600, Grant Edwards wrote:
>> I've re-written the path display/trace features. Attached is a
>> snapshot of the diffs against the current git HEAD. Changes since the
>> first version I posted follow:
>
> Thanks a lot. N
19 matches
Mail list logo
