Re: [devel] [git update] packages/rpm-utils: heads/master

Re: [devel] [git update] packages/rpm-utils: heads/master

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

Hi,

On Tue, Mar 13, 2007 at 06:51:04PM +0300, Alexey M. Tourbin wrote:
> Update of /people/at/packages/rpm-utils.git
> 
> Changes statistics since `0.9.3-alt1-17-g38cd1bc' follows:
>  rpm-utils/filereq |   34 +++++++++++++++++++++++++---------
>  1 files changed, 25 insertions(+), 9 deletions(-)
> 
[...]
>     filereq: changed weak/strong access logic
>     
>     Now that we have strace_files which is dumb, we can add some logic to filereq.
>     Let us look at system calls that access files.
>     
>     $ grep -w TF strace/linux/x86_64/*
>     strace/linux/x86_64/syscallent.h:       { 3,    TD|TF,  sys_open,               "open"          },  /* 2 */
[48 entries skipped]
>     strace/linux/x86_64/syscallent.h:       { 3,    TD|TF,  sys_faccessat,          "faccessat"     }, /* 269 */
>     
>     I discriminate a few types of system calls that produce file-level dependencies:
>     
>     1) Strong system calls: open and execve.  They access file data and follow
>     symbolic links.  Thus, for symbolic links, we must also output the file it
>     points to.
>     
>     2) Weak system calls: stat and access.  They follow symbolic links but do not
>     access file content.  Provided that rpm packages do not have broken symbolic
>     links, these system calls do not require special handling of symbolic links.
>     
>     3) Yet weaker system calls: lstat and readlink.  It is not obvious whether
>     these system calls should produce any (essential) file-level dependencies,
>     so I leave them out, at least for now.  Please let me know if they really should.
>     I mean I need a real-world counterexample.
>     
>     4) link and symlink, which can produce file-level dependencies in very
>     pathological cases: it is possible to link e.g. `ln /bin/cat $PWD/cat' and then
>     use $PWD/cat.  But it is possible to bypass buildreq even easier:
>     
>     $ /usr/share/buildreqs/strace_files sh -c 'cd /bin && ./cat /dev/null' |grep cat
>     $
>     
>     So I think that we should not resolve very pathological cases until we can resolve
>     less pathological cases.  I leave leave link and symlink out.
>     
>     5) Directory system calls like chdir or mkdir.  Since filereq probably should
>     not output directories, I leave these system calls out.
>     
>     6) Unrelated system calls.
>     
>     That said, I am going to consider only the following system calls:
>     1) Strong system calls -- open and execve.
>     2) Weak system calls -- stat and access.
>     Note that I actually grep them by prefix to allow stat64 or something.

ptrace(2) is expensive tool.  If strace TF selector is not optimal for
our needs, then we could consider implementing new strace selector, e.g.
TB (trace=buildreq).

>     Now it is possible that stat and access will produce more unrelated
>     dependencies than they can add useful dependencies.  I added debugging
>     output to show the list of files that have been accessed only with stat
>     or access, but not with open or execve; so that we can analyze whether
>     stat and access yield something useful at all (and maybe remove them later).
>     
>     Also split output in two portions: the list of files from system calls
>     and list of files obtained with readlink.  Now we can visually discriminate
>     between the two (but the list is still unique).

Let's try.  I added your name to rpm-utils uploaders list.

P.S.  If we decide to patch strace, this discussion may help me to
explain Roland why we need new selector.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [git update] packages/rpm-utils: heads/master

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Sun, Mar 18, 2007 at 10:31:36PM +0300, Dmitry V. Levin wrote:
> >     That said, I am going to consider only the following system calls:
> >     1) Strong system calls -- open and execve.
> >     2) Weak system calls -- stat and access.
> >     Note that I actually grep them by prefix to allow stat64 or something.
> 
> ptrace(2) is expensive tool.  If strace TF selector is not optimal for
> our needs, then we could consider implementing new strace selector, e.g.
> TB (trace=buildreq).

We can always pass to strace(1) the exact list of system calls we want.
So there's no essential need for new strace selectors.  The only thing
that stopped me from implementing --trace=open,execve,... argument for
/usr/share/buildreqs/strace_files is that actually I would have to deal
with stat/stat64 difference somehow.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]