1. 30 4月, 2014 3 次提交
  2. 29 4月, 2014 8 次提交
  3. 28 4月, 2014 20 次提交
  4. 27 4月, 2014 6 次提交
  5. 26 4月, 2014 3 次提交
    • P
      seccomp: add shmctl(), mlock(), and munlock() to the syscall whitelist · e3f9bb01
      Paul Moore 提交于
      Additional testing reveals that PulseAudio requires shmctl() and the
      mlock()/munlock() syscalls on some systems/configurations.  As before,
      on systems that do require these syscalls, the problem can be seen with
      the following command line:
      
        # qemu -monitor stdio  -sandbox on \
               -device intel-hda -device hda-duplex
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Signed-off-by: NEduardo Otubo <otubo@linux.vnet.ibm.com>
      e3f9bb01
    • F
      seccomp: add timerfd_create and timerfd_settime to the whitelist · 84397618
      Felix Geyer 提交于
      libusb calls timerfd_create() and timerfd_settime() when it's built with
      timerfd support.
      
      Command to reproduce:
      
             -device usb-host,hostbus=1,hostaddr=3,id=hostdev0
      
      Log messages:
      
      audit(1390730418.924:135): auid=4294967295 uid=121 gid=103 ses=4294967295
                                 pid=5232 comm="qemu-system-x86" sig=31 syscall=283
                                 compat=0 ip=0x7f2b0f4e96a7 code=0x0
      audit(1390733100.580:142): auid=4294967295 uid=121 gid=103 ses=4294967295
                                 pid=16909 comm="qemu-system-x86" sig=31 syscall=286
                                 compat=0 ip=0x7f03513a06da code=0x0
      
      Reading a few hundred MB from a USB drive on x86_64 shows this syscall distribution.
      Therefore the timerfd_settime priority is set to 242.
      
          calls  syscall
       --------- ----------------
         5303600 write
         2240554 read
         2167030 ppoll
         2134828 ioctl
          704023 timerfd_settime
          689105 poll
           83122 futex
             803 writev
             476 rt_sigprocmask
             287 recvmsg
             178 brk
      Signed-off-by: NFelix Geyer <debfx@fobos.de>
      Signed-off-by: NEduardo Otubo <otubo@linux.vnet.ibm.com>
      84397618
    • M
      iscsi: Don't use error_is_set() to suppress additional errors · 172fc4dd
      Markus Armbruster 提交于
      Using error_is_set(errp) that way can sweep programming errors under
      the carpet when we get called incorrectly with an error set.
      
      Commit 24d3bd67 added a broken error path to iscsi_do_inquiry(): it
      first calls error_setg(), then jumps to the preexisting error label,
      where error_setg() gets called again, triggering an assertion failure.
      
      Commit cbee81f6 fixed this by guarding the second error_setg() with an
      error_is_set().
      
      Replace this fix by a simpler and safer one: jump right behind the
      second error_setg().
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      172fc4dd