ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: "Dmitry V. Levin" <ldv@altlinux.org>
To: ALT Devel discussion list <devel@lists.altlinux.org>
Subject: Re: [devel] [git update] packages/rpm-utils: heads/master
Date: Sun, 18 Mar 2007 22:31:36 +0300
Message-ID: <20070318193136.GA3820@nomad.office.altlinux.org> (raw)
In-Reply-To: <20070313155104.738CD42C093E@ssh.git.local.altlinux.org>

[-- 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 --]

       reply	other threads:[~2007-03-18 19:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-18 19:31 ` Dmitry V. Levin [this message]
2007-03-18 19:52   ` Alexey Tourbin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070318193136.GA3820@nomad.office.altlinux.org \
    --to=ldv@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git