Kyle Evans added the comment:
Sure, sounds good to me. The original theory (IIRC, I've slept many times since
then :-)) was that we already know first/last are valid and there are no other
defined errors, so 'other errors' must be because close_range has started
percolating up something
Change by Kyle Evans :
--
pull_requests: +21651
pull_request: https://github.com/python/cpython/pull/22680
___
Python tracker
<https://bugs.python.org/issue40
Change by Kyle Evans :
--
pull_requests: +21646
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/22672
___
Python tracker
<https://bugs.python.org/issu
Kyle Evans added the comment:
Excellent, thank you.
--
___
Python tracker
<https://bugs.python.org/issue40422>
___
___
Python-bugs-list mailing list
Unsub
Kyle Evans added the comment:
Would you like that on a distinct issue, or is it ok to reuse this BPO since
it's a location improvement of an API just introduced?
I've got a local branch now that:
1. moves the suppress IPH stuff into _Py_closerange
2. moves the definition into Python
Change by Kyle Evans :
--
nosy: +kevans
nosy_count: 8.0 -> 9.0
pull_requests: +21629
pull_request: https://github.com/python/cpython/pull/22651
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Evans :
--
nosy: +kevans
nosy_count: 28.0 -> 29.0
pull_requests: +21627
pull_request: https://github.com/python/cpython/pull/22651
___
Python tracker
<https://bugs.python.org/iss
Change by Kyle Evans :
--
nosy: +kevans
nosy_count: 8.0 -> 9.0
pull_requests: +21628
pull_request: https://github.com/python/cpython/pull/22651
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Evans :
--
pull_requests: +21624
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22651
___
Python tracker
<https://bugs.python.org/issu
Kyle Evans added the comment:
Ah, I will fix this and then submit a PR, thanks... hopefully it returns ENOSYS.
--
nosy: +kevans
___
Python tracker
<https://bugs.python.org/issue40
Kyle Evans added the comment:
Hey koobs,
Can you confirm that this is fine now after I implemented SHM_GROW_ON_WRITE?
--
___
Python tracker
<https://bugs.python.org/issue41
Kyle Evans added the comment:
I can confirm that neither 12 nor 11 will be getting memfd_create; file sealing
is a little more complicated to MFC, and I don't want to provide memfd_create
in a place where it can't be paired with file sealing in case applications
assume they come hand
Kyle Evans added the comment:
Ah, sorry, I meant to update this- I submitted our fix for review a day or two
ago, got approval for commit and will poke koobs to rebuild the FreeBSD
-CURRENT buildbot with it after that.
--
___
Python tracker
Kyle Evans added the comment:
Ah, now that I'm more awake, I see the problem- the write is unsuccessful
because I haven't yet implemented grow-on-write. None of the consumers that I
had found relied on it, instead choosing to ftruncate() it to the size they
need before operating on it.
I
Kyle Evans added the comment:
(Transcription error beyond the bogus os.exit() :-))
--
___
Python tracker
<https://bugs.python.org/issue41013>
___
___
Python-bug
Kyle Evans added the comment:
I think it's too early to look at this, I'll circle back another time. :-) I
got a minute and extracted the relevant test, but I guess there must have been
some fundamental transcription error:
import os
fd = os.memfd_create("Hi", os.MFD_CLOEXEC)
i
Kyle Evans added the comment:
Interesting; I don't quite have time to look at the moment, but what is the
test doing that it's ultimately timing out?
Our memfd_create is assumed to be compatible, with the exception that we don't
yet support HUGETLB (but there are patches in progress
New submission from Kyle Evans :
This is dependent on issue40422; the diff on top of that (PR19075) looks like
the attached. Effectively, close_range(2) should be preferred at all times if
it's available, otherwise we'll use closefrom(2) if available with a fallback
to fdwalk(3) or plain old
Change by Kyle Evans :
--
keywords: +patch
nosy: +kevans
nosy_count: 1.0 -> 2.0
pull_requests: +19075
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19754
___
Python tracker
<https://bugs.python.org/i
New submission from Kyle Evans :
Such an API can be used for both os.closerange and subprocess, re-using much of
os_closerange_impl. Pull request enroute.
--
components: C API
messages: 367530
nosy: kevans91
priority: normal
severity: normal
status: open
title: Light refactor: create
Kyle Evans added the comment:
I'll be preparing a patch for our posix_spawn's signal handling.
My mistake in my setuid assessment was pointed out to me- it doesn't seem like
a highly likely attack vector, but it is indeed possible.
If the child errored out, they will indeed be properly
Kyle Evans added the comment:
On Wed, Jan 16, 2019 at 5:47 PM Alexey Izbyshev wrote:
> > Hi,
>
> > As a disclaimer, I'm a FreeBSD developer interested in making sure we're
> > doing the right thing here. =)
>
> > May I ask what the above assessment is base
Kyle Evans added the comment:
> * On FreeBSD, if setting posix_spawn() "attributes" or execute posix_spawn()
> "file actions" fails, posix_spawn() succeed but the child process exits
> immediately with exit code 127 without trying to call execv(). If execv()
&
23 matches
Mail list logo
