1. 30 Oct, 2007 1 commit
  2. 29 Oct, 2007 1 commit
  3. 19 Oct, 2007 8 commits
    • Pavel Emelyanov's avatar
      Use helpers to obtain task pid in printks · ba25f9dc
      Pavel Emelyanov authored
      
      The task_struct->pid member is going to be deprecated, so start
      using the helpers (task_pid_nr/task_pid_vnr/task_pid_nr_ns) in
      the kernel.
      
      The first thing to start with is the pid, printed to dmesg - in
      this case we may safely use task_pid_nr(). Besides, printks produce
      more (much more) than a half of all the explicit pid usage.
      
      [akpm@linux-foundation.org: git-drm went and changed lots of stuff]
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ba25f9dc
    • Pavel Emelyanov's avatar
      Isolate some explicit usage of task->tgid · bac0abd6
      Pavel Emelyanov authored
      
      With pid namespaces this field is now dangerous to use explicitly, so hide
      it behind the helpers.
      
      Also the pid and pgrp fields o task_struct and signal_struct are to be
      deprecated.  Unfortunately this patch cannot be sent right now as this
      leads to tons of warnings, so start isolating them, and deprecate later.
      
      Actually the p->tgid == pid has to be changed to has_group_leader_pid(),
      but Oleg pointed out that in case of posix cpu timers this is the same, and
      thread_group_leader() is more preferable.
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Acked-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bac0abd6
    • Pavel Emelyanov's avatar
      Uninline find_task_by_xxx set of functions · 228ebcbe
      Pavel Emelyanov authored
      
      The find_task_by_something is a set of macros are used to find task by pid
      depending on what kind of pid is proposed - global or virtual one.  All of
      them are wrappers above the most generic one - find_task_by_pid_type_ns() -
      and just substitute some args for it.
      
      It turned out, that dereferencing the current->nsproxy->pid_ns construction
      and pushing one more argument on the stack inline cause kernel text size to
      grow.
      
      This patch moves all this stuff out-of-line into kernel/pid.c.  Together
      with the next patch it saves a bit less than 400 bytes from the .text
      section.
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Paul Menage <menage@google.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      228ebcbe
    • Pavel Emelyanov's avatar
      pid namespaces: changes to show virtual ids to user · b488893a
      Pavel Emelyanov authored
      
      This is the largest patch in the set. Make all (I hope) the places where
      the pid is shown to or get from user operate on the virtual pids.
      
      The idea is:
       - all in-kernel data structures must store either struct pid itself
         or the pid's global nr, obtained with pid_nr() call;
       - when seeking the task from kernel code with the stored id one
         should use find_task_by_pid() call that works with global pids;
       - when showing pid's numerical value to the user the virtual one
         should be used, but however when one shows task's pid outside this
         task's namespace the global one is to be used;
       - when getting the pid from userspace one need to consider this as
         the virtual one and use appropriate task/pid-searching functions.
      
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: nuther build fix]
      [akpm@linux-foundation.org: yet nuther build fix]
      [akpm@linux-foundation.org: remove unneeded casts]
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@openvz.org>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Paul Menage <menage@google.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b488893a
    • Sukadev Bhattiprolu's avatar
      pid namespaces: allow signalling cgroup-init · 0fbc26a6
      Sukadev Bhattiprolu authored
      
      Only the global-init process must be special - any other cgroup-init
      process must be killable to prevent run-away processes in the system.
      
      TODO: 	Ideally we should allow killing the cgroup-init only from parent
      	cgroup and prevent it being killed from within the cgroup.
      	But that is a more complex change and will be addressed by a follow-on
      	patch. For now allow the cgroup-init to be terminated by any process
      	with sufficient privileges.
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@us.ibm.com>
      Acked-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0fbc26a6
    • Serge E. Hallyn's avatar
      pid namespaces: define is_global_init() and is_container_init() · b460cbc5
      Serge E. Hallyn authored
      
      is_init() is an ambiguous name for the pid==1 check.  Split it into
      is_global_init() and is_container_init().
      
      A cgroup init has it's tsk->pid == 1.
      
      A global init also has it's tsk->pid == 1 and it's active pid namespace
      is the init_pid_ns.  But rather than check the active pid namespace,
      compare the task structure with 'init_pid_ns.child_reaper', which is
      initialized during boot to the /sbin/init process and never changes.
      
      Changelog:
      
      	2.6.22-rc4-mm2-pidns1:
      	- Use 'init_pid_ns.child_reaper' to determine if a given task is the
      	  global init (/sbin/init) process. This would improve performance
      	  and remove dependence on the task_pid().
      
      	2.6.21-mm2-pidns2:
      
      	- [Sukadev Bhattiprolu] Changed is_container_init() calls in {powerpc,
      	  ppc,avr32}/traps.c for the _exception() call to is_global_init().
      	  This way, we kill only the cgroup if the cgroup's init has a
      	  bug rather than force a kernel panic.
      
      [akpm@linux-foundation.org: fix comment]
      [sukadev@us.ibm.com: Use is_global_init() in arch/m32r/mm/fault.c]
      [bunk@stusta.de: kernel/pid.c: remove unused exports]
      [sukadev@us.ibm.com: Fix capability.c to work with threaded init]
      Signed-off-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@us.ibm.com>
      Acked-by: default avatarPavel Emelianov <xemul@openvz.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Herbert Poetzel <herbert@13thfloor.at>
      Cc: Kirill Korotaev <dev@sw.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b460cbc5
    • Sukadev Bhattiprolu's avatar
      pid namespaces: rename child_reaper() function · 88f21d81
      Sukadev Bhattiprolu authored
      
      Rename the child_reaper() function to task_child_reaper() to be similar to
      other task_* functions and to distinguish the function from 'struct
      pid_namspace.child_reaper'.
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Pavel Emelianov <xemul@openvz.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Serge Hallyn <serue@us.ibm.com>
      Cc: Herbert Poetzel <herbert@13thfloor.at>
      Cc: Kirill Korotaev <dev@sw.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      88f21d81
    • Pavel Emelianov's avatar
      pid namespaces: round up the API · a47afb0f
      Pavel Emelianov authored
      
      The set of functions process_session, task_session, process_group and
      task_pgrp is confusing, as the names can be mixed with each other when looking
      at the code for a long time.
      
      The proposals are to
      * equip the functions that return the integer with _nr suffix to
        represent that fact,
      * and to make all functions work with task (not process) by making
        the common prefix of the same name.
      
      For monotony the routines signal_session() and set_signal_session() are
      replaced with task_session_nr() and set_task_session(), especially since they
      are only used with the explicit task->signal dereference.
      Signed-off-by: default avatarPavel Emelianov <xemul@openvz.org>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a47afb0f
  4. 18 Oct, 2007 1 commit
  5. 17 Oct, 2007 4 commits
  6. 07 Oct, 2007 1 commit
  7. 20 Sep, 2007 1 commit
    • Davide Libenzi's avatar
      signalfd simplification · b8fceee1
      Davide Libenzi authored
      
      This simplifies signalfd code, by avoiding it to remain attached to the
      sighand during its lifetime.
      
      In this way, the signalfd remain attached to the sighand only during
      poll(2) (and select and epoll) and read(2).  This also allows to remove
      all the custom "tsk == current" checks in kernel/signal.c, since
      dequeue_signal() will only be called by "current".
      
      I think this is also what Ben was suggesting time ago.
      
      The external effect of this, is that a thread can extract only its own
      private signals and the group ones.  I think this is an acceptable
      behaviour, in that those are the signals the thread would be able to
      fetch w/out signalfd.
      Signed-off-by: default avatarDavide Libenzi <davidel@xmailserver.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b8fceee1
  8. 31 Aug, 2007 1 commit
    • Oleg Nesterov's avatar
      sigqueue_free: fix the race with collect_signal() · 60187d27
      Oleg Nesterov authored
      Spotted by taoyue <yue.tao@windriver.com> and Jeremy Katz <jeremy.katz@windriver.com>.
      
      collect_signal:				sigqueue_free:
      
      	list_del_init(&first->list);
      						if (!list_empty(&q->list)) {
      							// not taken
      						}
      						q->flags &= ~SIGQUEUE_PREALLOC;
      
      	__sigqueue_free(first);			__sigqueue_free(q);
      
      Now, __sigqueue_free() is called twice on the same "struct sigqueue" with the
      obviously bad implications.
      
      In particular, this double free breaks the array_cache->avail logic, so the
      same sigqueue could be "allocated" twice, and the bug can manifest itself via
      the "impossible" BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free/send_sigqueue.
      
      Hopefully this can explain these mysterious bug-reports, see
      
      	http://marc.info/?t=118766926500003
      	http://marc.info/?t=118466273000005
      
      
      
      Alexey Dobriyan reports this patch makes the difference for the testcase, but
      nobody has an access to the application which opened the problems originally.
      
      Also, this patch removes tasklist lock/unlock, ->siglock is enough.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: taoyue <yue.tao@windriver.com>
      Cc: Jeremy Katz <jeremy.katz@windriver.com>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Alexey Dobriyan <adobriyan@sw.ru>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      60187d27
  9. 23 Aug, 2007 1 commit
    • Oleg Nesterov's avatar
      signalfd: fix interaction with posix-timers · 834d216e
      Oleg Nesterov authored
      
      dequeue_signal:
      
      	if (__SI_TIMER) {
      		spin_unlock(&tsk->sighand->siglock);
      		do_schedule_next_timer(info);
      		spin_lock(&tsk->sighand->siglock);
      	}
      
      Unless tsk == curent, this is absolutely unsafe: nothing prevents tsk from
      exiting. If signalfd was passed to another process, do_schedule_next_timer()
      is just wrong.
      
      Add yet another "tsk == current" check into dequeue_signal().
      
      This patch fixes an oopsable bug, but breaks the scheduling of posix timers
      if the shared __SI_TIMER signal was fetched via signalfd attached to another
      sub-thread. Mostly fixed by the next patch.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      834d216e
  10. 03 Aug, 2007 1 commit
  11. 22 Jul, 2007 1 commit
    • Masoud Asgharifard Sharbiani's avatar
      x86: i386-show-unhandled-signals-v3 · abd4f750
      Masoud Asgharifard Sharbiani authored
      
      This patch makes the i386 behave the same way that x86_64 does when a
      segfault happens.  A line gets printed to the kernel log so that tools
      that need to check for failures can behave more uniformly between
      debug.show_unhandled_signals sysctl variable to 0 (or by doing echo 0 >
      /proc/sys/debug/exception-trace)
      
      Also, all of the lines being printed are now using printk_ratelimit() to
      deny the ability of DoS from a local user with a program like the
      following:
      
      main()
      {
             while (1)
                     if (!fork()) *(int *)0 = 0;
      }
      
      This new revision also includes the fix that Andrew did which got rid of
      new sysctl that was added to the system in earlier versions of this.
      Also, 'show-unhandled-signals' sysctl has been renamed back to the old
      'exception-trace' to avoid breakage of people's scripts.
      
      AK: Enabling by default for i386 will be likely controversal, but let's see what happens
      AK: Really folks, before complaining just fix your segfaults
      AK: I bet this will find a lot of silent issues
      Signed-off-by: default avatarMasoud Sharbiani <masouds@google.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      [ Personally, I've found the complaints useful on x86-64, so I'm all for
        this. That said, I wonder if we could do it more prettily..   -Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      abd4f750
  12. 16 Jul, 2007 1 commit
  13. 18 Jun, 2007 1 commit
  14. 07 Jun, 2007 1 commit
    • Roland McGrath's avatar
      Restrict clearing TIF_SIGPENDING · b74d0deb
      Roland McGrath authored
      
      This patch should get a few birds.  It prevents sigaction calls from
      clearing TIF_SIGPENDING in other threads, which could leak -ERESTART*.
      And It fixes ptrace_stop not to clear it, which done at the syscall exit
      stop could leak -ERESTART*.  It probably removes the harm from signalfd,
      at least assuming it never calls dequeue_signal on kernel threads that
      might have used block_all_signals.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b74d0deb
  15. 24 May, 2007 1 commit
    • Roland McGrath's avatar
      recalc_sigpending_tsk fixes · 7bb44ade
      Roland McGrath authored
      
      Steve Hawkes discovered a problem where recalc_sigpending_tsk was called in
      do_sigaction but no signal_wake_up call was made, preventing later signals
      from waking up blocked threads with TIF_SIGPENDING already set.
      
      In fact, the few other calls to recalc_sigpending_tsk outside the signals
      code are also subject to this problem in other race conditions.
      
      This change makes recalc_sigpending_tsk private to the signals code.  It
      changes the outside calls, as well as do_sigaction, to use the new
      recalc_sigpending_and_wake instead.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Cc: <Steve.Hawkes@motorola.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7bb44ade
  16. 11 May, 2007 2 commits
    • Davide Libenzi's avatar
      signal/timer/event: signalfd core · fba2afaa
      Davide Libenzi authored
      This patch series implements the new signalfd() system call.
      
      I took part of the original Linus code (and you know how badly it can be
      broken :), and I added even more breakage ;) Signals are fetched from the same
      signal queue used by the process, so signalfd will compete with standard
      kernel delivery in dequeue_signal().  If you want to reliably fetch signals on
      the signalfd file, you need to block them with sigprocmask(SIG_BLOCK).  This
      seems to be working fine on my Dual Opteron machine.  I made a quick test
      program for it:
      
      http://www.xmailserver.org/signafd-test.c
      
      
      
      The signalfd() system call implements signal delivery into a file descriptor
      receiver.  The signalfd file descriptor if created with the following API:
      
      int signalfd(int ufd, const sigset_t *mask, size_t masksize);
      
      The "ufd" parameter allows to change an existing signalfd sigmask, w/out going
      to close/create cycle (Linus idea).  Use "ufd" == -1 if you want a brand new
      signalfd file.
      
      The "mask" allows to specify the signal mask of signals that we are interested
      in.  The "masksize" parameter is the size of "mask".
      
      The signalfd fd supports the poll(2) and read(2) system calls.  The poll(2)
      will return POLLIN when signals are available to be dequeued.  As a direct
      consequence of supporting the Linux poll subsystem, the signalfd fd can use
      used together with epoll(2) too.
      
      The read(2) system call will return a "struct signalfd_siginfo" structure in
      the userspace supplied buffer.  The return value is the number of bytes copied
      in the supplied buffer, or -1 in case of error.  The read(2) call can also
      return 0, in case the sighand structure to which the signalfd was attached,
      has been orphaned.  The O_NONBLOCK flag is also supported, and read(2) will
      return -EAGAIN in case no signal is available.
      
      If the size of the buffer passed to read(2) is lower than sizeof(struct
      signalfd_siginfo), -EINVAL is returned.  A read from the signalfd can also
      return -ERESTARTSYS in case a signal hits the process.  The format of the
      struct signalfd_siginfo is, and the valid fields depends of the (->code &
      __SI_MASK) value, in the same way a struct siginfo would:
      
      struct signalfd_siginfo {
      	__u32 signo;	/* si_signo */
      	__s32 err;	/* si_errno */
      	__s32 code;	/* si_code */
      	__u32 pid;	/* si_pid */
      	__u32 uid;	/* si_uid */
      	__s32 fd;	/* si_fd */
      	__u32 tid;	/* si_fd */
      	__u32 band;	/* si_band */
      	__u32 overrun;	/* si_overrun */
      	__u32 trapno;	/* si_trapno */
      	__s32 status;	/* si_status */
      	__s32 svint;	/* si_int */
      	__u64 svptr;	/* si_ptr */
      	__u64 utime;	/* si_utime */
      	__u64 stime;	/* si_stime */
      	__u64 addr;	/* si_addr */
      };
      
      [akpm@linux-foundation.org: fix signalfd_copyinfo() on i386]
      Signed-off-by: default avatarDavide Libenzi <davidel@xmailserver.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fba2afaa
    • Amy Griffis's avatar
      [PATCH] audit signal recipients · e54dc243
      Amy Griffis authored
      
      When auditing syscalls that send signals, log the pid and security
      context for each target process. Optimize the data collection by
      adding a counter for signal-related rules, and avoiding allocating an
      aux struct unless we have more than one target process. For process
      groups, collect pid/context data in blocks of 16. Move the
      audit_signal_info() hook up in check_kill_permission() so we audit
      attempts where permission is denied.
      Signed-off-by: default avatarAmy Griffis <amy.griffis@hp.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      e54dc243
  17. 09 May, 2007 3 commits
  18. 08 May, 2007 1 commit
  19. 07 May, 2007 1 commit
  20. 17 Feb, 2007 1 commit
  21. 16 Feb, 2007 1 commit
  22. 12 Feb, 2007 3 commits
  23. 11 Feb, 2007 2 commits
  24. 13 Dec, 2006 1 commit
    • Rafael J. Wysocki's avatar
      [PATCH] PM: Fix freezing of stopped tasks · 3df494a3
      Rafael J. Wysocki authored
      
      Currently, if a task is stopped (ie.  it's in the TASK_STOPPED state), it
      is considered by the freezer as unfreezeable.  However, there may be a race
      between the freezer and the delivery of the continuation signal to the task
      resulting in the task running after we have finished freezing the other
      tasks.  This, in turn, may lead to undesirable effects up to and including
      data corruption.
      
      To prevent this from happening we first need to make the freezer consider
      stopped tasks as freezeable.  For this purpose we need to make freezeable()
      stop returning 0 for these tasks and we need to force them to enter the
      refrigerator.  However, if there's no continuation signal in the meantime,
      the stopped tasks should remain stopped after all processes have been
      thawed, so we need to send an additional SIGSTOP to each of them before
      waking it up.
      
      Also, a stopped task that has just been woken up should first check if
      there's a freezing request for it and go to the refrigerator if that's the
      case.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3df494a3