1. 19 Apr, 2006 2 commits
  2. 18 Apr, 2006 2 commits
    • Linus Torvalds's avatar
      x86: be careful about tailcall breakage for sys_open[at] too · 385910f2
      Linus Torvalds authored
      Came up through a quick grep for other cases similar to the ftruncate()
      one in commit 0a489cb3
      
      .
      
      Also, add a comment, so that people who read the code understand why we
      do what looks like a no-op.
      
      (Again, this won't actually matter to any sane user, since libc will
      save and restore the register gcc stomps on, but it's still wrong to
      stomp on it)
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      385910f2
    • Linus Torvalds's avatar
      x86: don't allow tail-calls in sys_ftruncate[64]() · 0a489cb3
      Linus Torvalds authored
      
      
      Gcc thinks it owns the incoming argument stack, but that's not true for
      "asmlinkage" functions, and it corrupts the caller-set-up argument stack
      when it pushes the third argument onto the stack.  Which can result in
      %ebx getting corrupted in user space.
      
      Now, normally nobody sane would ever notice, since libc will save and
      restore %ebx anyway over the system call, but it's still wrong.
      
      I'd much rather have "asmlinkage" tell gcc directly that it doesn't own
      the stack, but no such attribute exists, so we're stuck with our hacky
      manual "prevent_tail_call()" macro once more (we've had the same issue
      before with sys_waitpid() and sys_wait4()).
      
      Thanks to Hans-Werner Hilse <hilse@sub.uni-goettingen.de> for reporting
      the issue and testing the fix.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0a489cb3
  3. 17 Apr, 2006 2 commits
  4. 14 Apr, 2006 3 commits
    • Kay Sievers's avatar
      [PATCH] BLOCK: delay all uevents until partition table is scanned · d4d7e5df
      Kay Sievers authored
      
      
      [BLOCK] delay all uevents until partition table is scanned
      
      Here we delay the annoucement of all block device events until the
      disk's partition table is scanned and all partition devices are already
      created and sysfs is populated.
      
      We have a bunch of old bugs for removable storage handling where we
      probe successfully for a filesystem on the raw disk, but at the
      same time the kernel recognizes a partition table and creates partition
      devices.
      Currently there is no sane way to tell if partitions will show up or not
      at the time the disk device is announced to userspace. With the delayed
      events we can simply skip any probe for a filesystem on the raw disk when
      we find already present partitions.
      Signed-off-by: default avatarKay Sievers <kay.sievers@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d4d7e5df
    • NeilBrown's avatar
      [PATCH] sysfs: Allow sysfs attribute files to be pollable · 4508a7a7
      NeilBrown authored
      
      
      It works like this:
        Open the file
        Read all the contents.
        Call poll requesting POLLERR or POLLPRI (so select/exceptfds works)
        When poll returns,
           close the file and go to top of loop.
         or lseek to start of file and go back to the 'read'.
      
      Events are signaled by an object manager calling
         sysfs_notify(kobj, dir, attr);
      
      If the dir is non-NULL, it is used to find a subdirectory which
      contains the attribute (presumably created by sysfs_create_group).
      
      This has a cost of one int  per attribute, one wait_queuehead per kobject,
      one int per open file.
      
      The name "sysfs_notify" may be confused with the inotify
      functionality.  Maybe it would be nice to support inotify for sysfs
      attributes as well?
      
      This patch also uses sysfs_notify to allow /sys/block/md*/md/sync_action
      to be pollable
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4508a7a7
    • Eric W. Biederman's avatar
      [PATCH] de_thread: Don't change our parents and ptrace flags. · c06511d1
      Eric W. Biederman authored
      
      
      This is two distinct changes.
       - Not changing our real parents.
       - Not changing our ptrace parents.
      
      Not changing our real parents is trivially correct because both tasks
      have the same real parents as they are part of a thread group.  Now that
      we demote the leader to a thread there is no longer any reason to change
      it's parentage.
      
      Not changing our ptrace parents is a user visible change if someone
      looks hard enough.  I don't think user space applications will care or
      even notice.
      
      In the practical and I think common case a debugger will have attached
      to all of the threads using the same ptrace flags.  From my quick skim
      of strace and gdb that appears to be the case.  Which if true means
      debuggers will not notice a change.
      
      Before this point we have already generated a ptrace event in do_exit
      that reports the leaders pid has died so de_thread is visible to a
      debugger.  Which means attempting to hide this case by copying flags
      around appears excessive.
      
      By not doing anything it avoids all of the weird locking issues between
      de_thread and ptrace attach, and removes one case from consideration for
      fixing the ptrace locking.
      
      This only addresses Oleg's first concern with ptrace_attach, that of the
      problems caused by reparenting.  Oleg's second concern is essentially a
      race between ptrace_attach and release_task that causes an oops when we
      get to force_sig_specific.  There is nothing special about de_thread
      with respect to that race.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c06511d1
  5. 11 Apr, 2006 31 commits