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 --]
next parent 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