From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8EK5-0003aD-CZ for qemu-devel@nongnu.org; Tue, 28 Jan 2014 14:27:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8EJv-0003Pt-No for qemu-devel@nongnu.org; Tue, 28 Jan 2014 14:27:49 -0500 Received: from e24smtp05.br.ibm.com ([32.104.18.26]:43231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8EJv-0003Ph-BV for qemu-devel@nongnu.org; Tue, 28 Jan 2014 14:27:39 -0500 Received: from /spool/local by e24smtp05.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 28 Jan 2014 17:27:36 -0200 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by d24dlp02.br.ibm.com (Postfix) with ESMTP id 0648D1DC005D for ; Tue, 28 Jan 2014 14:27:34 -0500 (EST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.8.31.93]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0SJReWx4509776 for ; Tue, 28 Jan 2014 17:27:41 -0200 Received: from d24av02.br.ibm.com (localhost [127.0.0.1]) by d24av02.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s0SJRXna015300 for ; Tue, 28 Jan 2014 17:27:33 -0200 Message-ID: <52E8049A.9080405@linux.vnet.ibm.com> Date: Tue, 28 Jan 2014 17:27:22 -0200 From: Eduardo Otubo MIME-Version: 1.0 References: <52E4FDC4.3050204@fobos.de> <52E7AA08.5040909@linux.vnet.ibm.com> <52E7F102.2080804@fobos.de> In-Reply-To: <52E7F102.2080804@fobos.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] seccomp: add timerfd_create and timerfd_settime to the whitelist List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Felix Geyer Cc: qemu-devel@nongnu.org On 01/28/2014 04:03 PM, Felix Geyer wrote: > On 28.01.2014 14:00, Eduardo Otubo wrote: >> On 01/26/2014 10:21 AM, Felix Geyer wrote: >>> libusb calls timerfd_create() and timerfd_settime() when it's built with >>> timerfd support. >>> >>> Command to reproduce: >>> >>> qemu -sandbox on -monitor stdio -device piix3-usb-uhci,id=usb >>> -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 >>> >>> Signed-off-by: Felix Geyer >>> --- >>> qemu-seccomp.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/qemu-seccomp.c b/qemu-seccomp.c >>> index caa926e..2705468 100644 >>> --- a/qemu-seccomp.c >>> +++ b/qemu-seccomp.c >>> @@ -225,7 +225,9 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] = { >>> { SCMP_SYS(fchmod), 240 }, >>> { SCMP_SYS(shmget), 240 }, >>> { SCMP_SYS(shmat), 240 }, >>> - { SCMP_SYS(shmdt), 240 } >>> + { SCMP_SYS(shmdt), 240 }, >>> + { SCMP_SYS(timerfd_create), 240 }, >>> + { SCMP_SYS(timerfd_settime), 240 } >> >> Did you deliberately set the priority to 240? Or did you run any sort of benchmark (strace) to >> find this value? >> >> Regards, > > Not really, sorry. > > I've now done a benchmark on x86_64, copying a few hundred MB from a USB drive: > > 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 > > timerfd_create is basically only called once so it can have the lowest priority. > timerfd_settime should probably have priority around 242. Fair enough. Please send another patch fixing the priority values and I'll ACK. I usually send pull requests at Friday EOD. So if you need anything to be pull-requested until this Friday, please send so we can discuss and ACK until there. Thanks for the contribution :) -- Eduardo Otubo IBM Linux Technology Center