qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4] linux-user: Add close_range() syscall
@ 2022-10-24 20:43 Helge Deller
  2022-10-24 22:39 ` Richard Henderson
  0 siblings, 1 reply; 5+ messages in thread
From: Helge Deller @ 2022-10-24 20:43 UTC (permalink / raw)
  To: Laurent Vivier, qemu-devel; +Cc: Helge Deller

Signed-off-by: Helge Deller <deller@gmx.de>
---
Changes:
v4: Fix check for arg2
v3: fd_trans_unregister() only called if close_range() doesn't fail
v2: consider CLOSE_RANGE_CLOEXEC flag

diff --git a/linux-user/strace.list b/linux-user/strace.list
index 3df2184580..cd995e5d56 100644
--- a/linux-user/strace.list
+++ b/linux-user/strace.list
@@ -103,6 +103,9 @@
 #ifdef TARGET_NR_close
 { TARGET_NR_close, "close" , "%s(%d)", NULL, NULL },
 #endif
+#ifdef TARGET_NR_close_range
+{ TARGET_NR_close_range, "close_range" , "%s(%u,%u,%u)", NULL, NULL },
+#endif
 #ifdef TARGET_NR_connect
 { TARGET_NR_connect, "connect" , "%s(%d,%#x,%d)", NULL, NULL },
 #endif
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 12195d4e99..984039f928 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -339,6 +339,13 @@ _syscall3(int,sys_syslog,int,type,char*,bufp,int,len)
 #ifdef __NR_exit_group
 _syscall1(int,exit_group,int,error_code)
 #endif
+#if defined(__NR_close_range) && defined(TARGET_NR_close_range)
+#define __NR_sys_close_range __NR_close_range
+_syscall3(int,sys_close_range,int,first,int,last,int,flags)
+#ifndef CLOSE_RANGE_CLOEXEC
+#define CLOSE_RANGE_CLOEXEC     (1U << 2)
+#endif
+#endif
 #if defined(__NR_futex)
 _syscall6(int,sys_futex,int *,uaddr,int,op,int,val,
           const struct timespec *,timeout,int *,uaddr2,int,val3)
@@ -8735,6 +8742,24 @@ static abi_long do_syscall1(CPUArchState *cpu_env, int num, abi_long arg1,
     case TARGET_NR_close:
         fd_trans_unregister(arg1);
         return get_errno(close(arg1));
+#if defined(__NR_close_range) && defined(TARGET_NR_close_range)
+    case TARGET_NR_close_range:
+        ret = get_errno(sys_close_range(arg1, arg2, arg3));
+        if (ret == 0 && !(arg3 & CLOSE_RANGE_CLOEXEC)) {
+            abi_long fd;
+            abi_long maxfd = arg2;
+
+            if ((sizeof(abi_long) == 4 && arg2 == (abi_long)0x7FFFFFFFUL) ||
+                (sizeof(abi_long) == 8 && arg2 == (abi_long)0x7FFFFFFFFFFFFFFFULL)) {
+                maxfd = target_fd_max;
+            }
+
+            for (fd = arg1; fd < maxfd; fd++) {
+                fd_trans_unregister(fd);
+            }
+        }
+        return ret;
+#endif

     case TARGET_NR_brk:
         return do_brk(arg1);


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v4] linux-user: Add close_range() syscall
  2022-10-24 20:43 [PATCH v4] linux-user: Add close_range() syscall Helge Deller
@ 2022-10-24 22:39 ` Richard Henderson
  2022-10-25  1:39   ` Helge Deller
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Henderson @ 2022-10-24 22:39 UTC (permalink / raw)
  To: Helge Deller, Laurent Vivier, qemu-devel

On 10/25/22 06:43, Helge Deller wrote:
> +            abi_long maxfd = arg2;
> +
> +            if ((sizeof(abi_long) == 4 && arg2 == (abi_long)0x7FFFFFFFUL) ||
> +                (sizeof(abi_long) == 8 && arg2 == (abi_long)0x7FFFFFFFFFFFFFFFULL)) {
> +                maxfd = target_fd_max;
> +            }
> +
> +            for (fd = arg1; fd < maxfd; fd++) {

Why do we need explicit checks for INT32/64_MAX?  If the guest passes 
0x7FFFFFFFFFFFFFFEULL, do we really need to iterate over all of those impossible values?

I should think some expression involving MIN() is in order.


r~


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v4] linux-user: Add close_range() syscall
  2022-10-24 22:39 ` Richard Henderson
@ 2022-10-25  1:39   ` Helge Deller
  2022-10-25  2:15     ` Helge Deller
  2022-10-25  2:20     ` Richard Henderson
  0 siblings, 2 replies; 5+ messages in thread
From: Helge Deller @ 2022-10-25  1:39 UTC (permalink / raw)
  To: Richard Henderson, Laurent Vivier, qemu-devel

On 10/25/22 00:39, Richard Henderson wrote:
> On 10/25/22 06:43, Helge Deller wrote:
>> +            abi_long maxfd = arg2;
>> +
>> +            if ((sizeof(abi_long) == 4 && arg2 == (abi_long)0x7FFFFFFFUL) ||
>> +                (sizeof(abi_long) == 8 && arg2 == (abi_long)0x7FFFFFFFFFFFFFFFULL)) {
>> +                maxfd = target_fd_max;
>> +            }
>> +
>> +            for (fd = arg1; fd < maxfd; fd++) {
>
> Why do we need explicit checks for INT32/64_MAX?
> If the guest passes 0x7FFFFFFFFFFFFFFEULL,

A 32-bit guest (on a 64bit host) will pass 0x7FFFFFFFUL...

> do we really need to iterate over all of those impossible values?

The compiler will optimize one of those checks away, so it's effectively
just one expression.

> I should think some expression involving MIN() is in order.

Helge


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v4] linux-user: Add close_range() syscall
  2022-10-25  1:39   ` Helge Deller
@ 2022-10-25  2:15     ` Helge Deller
  2022-10-25  2:20     ` Richard Henderson
  1 sibling, 0 replies; 5+ messages in thread
From: Helge Deller @ 2022-10-25  2:15 UTC (permalink / raw)
  To: Richard Henderson, Laurent Vivier, qemu-devel

On 10/25/22 03:39, Helge Deller wrote:
> On 10/25/22 00:39, Richard Henderson wrote:
>> On 10/25/22 06:43, Helge Deller wrote:
>>> +            abi_long maxfd = arg2;
>>> +
>>> +            if ((sizeof(abi_long) == 4 && arg2 == (abi_long)0x7FFFFFFFUL) ||
>>> +                (sizeof(abi_long) == 8 && arg2 == (abi_long)0x7FFFFFFFFFFFFFFFULL)) {
>>> +                maxfd = target_fd_max;
>>> +            }
>>> +
>>> +            for (fd = arg1; fd < maxfd; fd++) {
>>
>> Why do we need explicit checks for INT32/64_MAX?
>> If the guest passes 0x7FFFFFFFFFFFFFFEULL,
>
> A 32-bit guest (on a 64bit host) will pass 0x7FFFFFFFUL...
>
>> do we really need to iterate over all of those impossible values?
>
> The compiler will optimize one of those checks away, so it's effectively
> just one expression.

My above comments are correct, but....

>> I should think some expression involving MIN() is in order.

that's even better.

Will resend v5 patch.

Helge


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v4] linux-user: Add close_range() syscall
  2022-10-25  1:39   ` Helge Deller
  2022-10-25  2:15     ` Helge Deller
@ 2022-10-25  2:20     ` Richard Henderson
  1 sibling, 0 replies; 5+ messages in thread
From: Richard Henderson @ 2022-10-25  2:20 UTC (permalink / raw)
  To: Helge Deller, Laurent Vivier, qemu-devel

On 10/25/22 11:39, Helge Deller wrote:
> On 10/25/22 00:39, Richard Henderson wrote:
>> On 10/25/22 06:43, Helge Deller wrote:
>>> +            abi_long maxfd = arg2;
>>> +
>>> +            if ((sizeof(abi_long) == 4 && arg2 == (abi_long)0x7FFFFFFFUL) ||
>>> +                (sizeof(abi_long) == 8 && arg2 == (abi_long)0x7FFFFFFFFFFFFFFFULL)) {
>>> +                maxfd = target_fd_max;
>>> +            }
>>> +
>>> +            for (fd = arg1; fd < maxfd; fd++) {
>>
>> Why do we need explicit checks for INT32/64_MAX?
>> If the guest passes 0x7FFFFFFFFFFFFFFEULL,
> 
> A 32-bit guest (on a 64bit host) will pass 0x7FFFFFFFUL...
> 
>> do we really need to iterate over all of those impossible values?
> 
> The compiler will optimize one of those checks away, so it's effectively
> just one expression.

By impossible values, I mean all descriptors above target_fd_max.
The compiler will most certainly not optimize the number of loop iterations.


r~



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-10-25  2:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-24 20:43 [PATCH v4] linux-user: Add close_range() syscall Helge Deller
2022-10-24 22:39 ` Richard Henderson
2022-10-25  1:39   ` Helge Deller
2022-10-25  2:15     ` Helge Deller
2022-10-25  2:20     ` Richard Henderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).