Hi Alex,
Le 18/12/2020 11:12, Alejandro Colomar (man-pages) a écrit :
Linux 5.10 has been recently released.
Do you have any updates for this patch?
Yes, I have a v3 in preparation, with _CLOEXEC and a code example. I'll
wrap it up today.
Regards,
Stephen
Hi Stephen,
Linux 5.10 has been recently released.
Do you have any updates for this patch?
Thanks,
Alex
On 12/12/20 6:58 PM, Alejandro Colomar (man-pages) wrote:
> Hi Christian,
>
> Makes sense to me.
>
> Thanks,
>
> Alex
>
> On 12/12/20 1:14 PM, Christian Brauner wrote:
>> On Thu, Dec 10,
Hi Christian,
Makes sense to me.
Thanks,
Alex
On 12/12/20 1:14 PM, Christian Brauner wrote:
> On Thu, Dec 10, 2020 at 03:36:42PM +0100, Alejandro Colomar (man-pages) wrote:
>> Hi Christian,
>
> Hi Alex,
>
>>
>> Thanks for confirming that behavior. Seems reasonable.
>>
>> I was wondering...
On Thu, Dec 10, 2020 at 03:36:42PM +0100, Alejandro Colomar (man-pages) wrote:
> Hi Christian,
Hi Alex,
>
> Thanks for confirming that behavior. Seems reasonable.
>
> I was wondering...
> If this call is equivalent to unshare(2)+{close(2) in a loop},
> shouldn't it fail for the same reasons
On 12/9/20 10:47 AM, Alejandro Colomar (man-pages) wrote:
>>> +descriptors in
>>> +.B /proc/self/fd/
>
> By reading proc.5, I think this should s/.B/.I/, right mtk?
>
>>> +and calling
>>> +.BR close (2)
>>> +on each one.
>>> +.BR close_range ()
>>> +can take care of this without requiring
>>>
Hi Christian,
Thanks for confirming that behavior. Seems reasonable.
I was wondering...
If this call is equivalent to unshare(2)+{close(2) in a loop},
shouldn't it fail for the same reasons those syscalls can fail?
What about the following errors?:
>From unshare(2):
EPERM The calling
On Wed, Dec 09, 2020 at 11:44:22AM +0100, Alejandro Colomar (man-pages) wrote:
> Hey Christian,
>
> I have a question for you below.
>
> Thanks,
Hey Alex,
Sure!
>
> Alex
>
> On 12/9/20 10:58 AM, Christian Brauner wrote:
> > On Tue, Dec 08, 2020 at 10:51:33PM +0100, Stephen Kitt wrote:
> >>
Hey Christian,
I have a question for you below.
Thanks,
Alex
On 12/9/20 10:58 AM, Christian Brauner wrote:
> On Tue, Dec 08, 2020 at 10:51:33PM +0100, Stephen Kitt wrote:
>> This documents close_range(2) based on information in
>> 278a5fbaed89dacd04e9d052f4594ffd0e0585de and
>>
Le 09/12/2020 10:40, Christian Brauner a écrit :
On Wed, Dec 09, 2020 at 09:50:38AM +0100, Michael Kerrisk (man-pages)
wrote:
> +.PP
> +.I flags
> +can be set to
> +.B CLOSE_RANGE_UNSHARE
> +to unshare the range of file descriptors from any other processes,
> +.I instead
> +of closing them.
On Tue, Dec 08, 2020 at 10:51:33PM +0100, Stephen Kitt wrote:
> This documents close_range(2) based on information in
> 278a5fbaed89dacd04e9d052f4594ffd0e0585de and
> 60997c3d45d9a67daf01c56d805ae4fec37e0bd8.
>
> Signed-off-by: Stephen Kitt
> ---
Hey Stephen,
Thanks for working on this that's
Hello Stephen and Michael,
Thanks for the page!
A few more comments below.
Thanks,
Alex
On 12/9/20 9:50 AM, Michael Kerrisk (man-pages) wrote:
> Hello Stephen
>
> Thank you for writing this page! Some comments/questions below.
>
> On Tue, 8 Dec 2020 at 22:51, Stephen Kitt wrote:
>>
>> This
On Wed, Dec 09, 2020 at 09:50:38AM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Stephen
>
> Thank you for writing this page! Some comments/questions below.
>
> On Tue, 8 Dec 2020 at 22:51, Stephen Kitt wrote:
> >
> > This documents close_range(2) based on information in
> >
Hello Stephen
Thank you for writing this page! Some comments/questions below.
On Tue, 8 Dec 2020 at 22:51, Stephen Kitt wrote:
>
> This documents close_range(2) based on information in
> 278a5fbaed89dacd04e9d052f4594ffd0e0585de and
> 60997c3d45d9a67daf01c56d805ae4fec37e0bd8.
(Thanks for noting
This documents close_range(2) based on information in
278a5fbaed89dacd04e9d052f4594ffd0e0585de and
60997c3d45d9a67daf01c56d805ae4fec37e0bd8.
Signed-off-by: Stephen Kitt
---
man2/close_range.2 | 112 +
1 file changed, 112 insertions(+)
create mode
14 matches
Mail list logo
