On 09/16/2013 06:16 PM, Peter Hurley wrote:
> On 09/15/2013 11:50 AM, Oleg Nesterov wrote:
>> Starting from v3.10 (probably f91e2590 "tty: Signal foreground
>> group processes in hangup") disassociate_ctty() sends SIGCONT
>> if tty && on_exit. This breaks LSB test-suite, in particular
>> test8 in _
On 01/16/2013 04:45 PM, David Miller wrote:
> From: Ben Hutchings
> Date: Wed, 16 Jan 2013 15:47:12 +
>
>> On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
>>> Cong Wang wrote:
(Cc'ing some glibc developers...)
Hello,
In glibc source file inet/netinet/in.h
ble so you can use
the linux specific code to define __USE_KERNEL_DEFS based on
the _UAPI_* macro definition and use those to cull in.h.
- glibc was missing IPPROTO_MH, added here.
glibc/
2012-01-16 Carlos O'Donell
* sysdeps/unix/sysv/linux/bits/in.h
[_UAPI_LINUX_IN
On 01/16/2013 10:22 PM, YOSHIFUJI Hideaki wrote:
> Carlos O'Donell wrote:
>> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
>> index f79c372..a2b16a5 100644
>> --- a/include/uapi/linux/in6.h
>> +++ b/include/uapi/linux/in6.h
>> @@ -23,6 +23
On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger wrote:
> On Wednesday 16 January 2013 22:15:38 David Miller wrote:
>> From: Carlos O'Donell
>> Date: Wed, 16 Jan 2013 21:15:03 -0500
>>
>> > +/* If a glibc-based userspace has already included in.h, then we wil
On 01/18/2013 05:44 AM, Pedro Alves wrote:
> On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
>> On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger wrote:
>>> On Wednesday 16 January 2013 22:15:38 David Miller wrote:
>>>> From: Carlos O'Donell
&g
On Fri, Jan 18, 2013 at 9:36 AM, Pedro Alves wrote:
> On 01/18/2013 02:24 PM, YOSHIFUJI Hideaki wrote:
>
> It's simple enough to move all of the __GLIBC__ uses into libc-compat.h,
> then you control userspace libc coordination from one file.
How about just deciding on a single ma
On 01/09/2013 04:09 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
>>> I'm suggesting that the string returned by get_extended_error_info()
>>> ought to be the audit record the system call would gen
On 10/13/2017 02:36 PM, Mathieu Desnoyers wrote:
> I also spoke to Carlos O'Donell from glibc about it, and he was very
> excited about the possible use of rseq for malloc speedup/memory usage
> improvement. But again, I don't see a project like glibc starting to
> use a sys
On 11/14/18 1:47 PM, Joseph Myers wrote:
> On Wed, 14 Nov 2018, Daniel Colascione wrote:
>
>> A good demonstration of a new commitment to pragmatism would be
>> merging the trivial wrappers for gettid(2).
>
> I support the addition of gettid (for use with those syscalls that take
> tids, and wit
On 11/15/18 12:08 PM, Theodore Y. Ts'o wrote:
> On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote:
>> On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
>>
>>> That's great. But is it or is it not true (either de jure or de
>>> facto) that "a single active glibc developer" can block a system
On 11/10/18 2:58 PM, Vlastimil Babka wrote:
> On 11/10/18 8:20 PM, Greg KH wrote:
>> On Sat, Nov 10, 2018 at 10:52:06AM -0800, Daniel Colascione wrote:
>>> Now that glibc is basically not adding any new system call wrappers,
>>
>> Why are they not doing that anymore?
>
> FYI just noticed there's a
On 11/10/18 2:20 PM, Greg KH wrote:
> Also, what about the basic work of making sure our uapi header files can
> actually be used untouched by a libc? That isn't the case these days as
> the bionic maintainers like to keep reminding me. That might be a good
> thing to do _before_ trying to add ne
On 11/12/18 11:43 AM, Joseph Myers wrote:
> On Sun, 11 Nov 2018, Florian Weimer wrote:
>
>> People may have disappeared from glibc development who have objected to
>> gettid. I thought this was the case with strlcpy/strlcat, but it was
>> not.
>
> Well, I know of two main people who were objecti
On 11/14/18 6:58 AM, Szabolcs Nagy wrote:
> an actual proposal in the thread that i think is
> worth considering is to make the linux syscall
> design process involve libc devs so the c api is
> designed together with the syscall abi.
Right, I see at least 2 actionable items:
* "The Checklist" wh
On 12/10/18 11:27 AM, Jonathan Corbet wrote:
> On Sat, 8 Dec 2018 20:38:56 -0800
> Randy Dunlap wrote:
>
>> On 11/12/18 8:08 AM, Jonathan Corbet wrote:
>>> On Sun, 11 Nov 2018 18:36:30 -0800
>>> Greg KH wrote:
>>>
We should have a checklist. That's a great idea. Now to find someone
>>>
On 01/24/2015 02:20 PM, Thomas Gleixner wrote:
> On Sat, 24 Jan 2015, Daniel Church wrote:
>
>> POSIX.1-2001 specification of timer_getoverrun() supports constant
>> DELAYTIMER_MAX which prevents overflow and caps overrun count. Exposes
>> delaytimer_max value to userland via /proc/sys/kernel/del
On 01/24/2015 12:48 PM, Daniel Church wrote:
> +#define DELAYTIMER_MAX_DEFAULT 100
Why did you chose 1 million?
Have you reviewed what constant userspace, particularly glibc, is using?
Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On 3/27/19 5:16 AM, Martin Schwidefsky wrote:
On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
Mathieu Desnoyers wrote:
+++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h
[...]
+
+/* Signature required before each abort handler code. */
+#define RSEQ_SIG 0x53053053
Why not a s390 specific value here?
On 4/8/19 3:20 PM, Tulio Magno Quites Machado Filho wrote:
Carlos O'Donell writes:
On 4/5/19 5:16 AM, Florian Weimer wrote:
* Carlos O'Donell:
It is valuable that it be a trap, particularly for constant pools because
it means that a jump into the constant pool will trap.
Sorr
On 4/9/19 9:58 AM, Tulio Magno Quites Machado Filho wrote:
Alan Modra writes:
Yes, looks fine to me, except that in VLE mode (do we care?)
".long 0x0fe50553" disassembles as
0: 0f e5 se_cmphl r5,r30
2: 05 53 se_mullw r3,r5
No illegal/trap/privileged insn there.
".
On Fri, May 15, 2020 at 1:50 PM Carlos O'Donell wrote:
> This isn't fixed because this is the older code in pthread_mutex_lock
> which we haven't ported to futex-internal.h yet, otherwise we would abort
> the process.
I filed this upstream as a QoI issue so I don'
On 11/6/20 7:47 PM, Thomas Gleixner wrote:
> On Thu, Nov 05 2020 at 12:25, Carlos O'Donell wrote:
>> On 10/30/20 9:38 PM, Thomas Gleixner wrote:
>> If kata grows up quickly perhaps this entire problem becomes solved, but
>> until
>> then I continue to ha
On 11/19/20 7:14 PM, Thomas Gleixner wrote:
> I hope you are aware that the time namespace offsets have to be set
> _before_ the process starts and can't be changed afterwards,
> i.e. settime() is not an option.
I not interested in settime(). I saw Petr's request and forwarded it on
here to furthe
On 11/25/20 7:17 PM, Thomas Gleixner wrote:
> Carlos, Petr,
>
> On Wed, Nov 25 2020 at 15:37, Carlos O'Donell wrote:
>> On 11/19/20 7:14 PM, Thomas Gleixner wrote:
>>> So from my point of view asking for distorted time still _is_ a request
>>> for ponies.
>
On 1/15/21 4:10 PM, Chang S. Bae via Libc-alpha wrote:
> Historically, signal.h defines MINSIGSTKSZ (2KB) and SIGSTKSZ (8KB), for
> use by all architectures with sigaltstack(2). Over time, the hardware state
> size grew, but these constants did not evolve. Today, literal use of these
> constants on
On 07/23/2014 02:21 PM, Jeff Layton wrote:
> From: Jeff Layton
Thanks for resending. Sorry for the delay.
Your use of 3 different emails caused me to miss the recent
resends. That's my fault and tied to the way I'm tracking
everything from patchwork using the first email you used.
I am assuming
On 05/14/2014 07:11 PM, Thomas Gleixner wrote:
> On Wed, 14 May 2014, Carlos O'Donell wrote:
>> On 05/14/2014 05:22 AM, Peter Zijlstra wrote:
>>>>> I believe the thinking goes that if we get to here, then the lock is in an
>>>>> inconsistent state (be
On 05/14/2014 06:28 AM, Thomas Gleixner wrote:
> On Wed, 14 May 2014, Peter Zijlstra wrote:
>> On Wed, May 14, 2014 at 11:53:44AM +0200, Thomas Gleixner wrote:
What error would we return?
This particular case is a serious error for which we have no good error
code
to retur
On 05/15/2014 04:07 AM, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 05:17:35PM -0400, Carlos O'Donell wrote:
>>> No, its perfectly fine to have a lock sequence abort with -EDEADLK.
>>> Userspace should release its locks and re-attempt.
>>
>> I agre
On 05/15/2014 04:25 AM, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 04:59:58PM -0400, Carlos O'Donell wrote:
>> I will make my personal opinion clear:
>>
>> - Internal defects should raise immediate assertions.
>>
>> - Real problems like resource a
On 05/12/2014 11:54 PM, Darren Hart wrote:
> On Mon, May 12, 2014 at 08:45:32PM -, Thomas Gleixner wrote:
>> Dave reported recently that the trinity syscall fuzzer triggers a
>> warning in the rtmutex code via the futex syscall.
>>
>> It took me quite a while to understand the issue, until I wa
On 05/13/2014 05:08 AM, Thomas Gleixner wrote:
> On Mon, 12 May 2014, Darren Hart wrote:
>> On Mon, May 12, 2014 at 08:45:32PM -, Thomas Gleixner wrote:
>>>strace tells me:
>>>
>>>futex(0x600e00, FUTEX_LOCK_PI_PRIVATE, 1) = -1 EINVAL (Invalid argument)
>>>
>>>but the return value of
On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote:
>> However, unless I'm sorely mistaken, the larger problem is that glibc
>> removed the futex() call entirely, so these man pages don't describe
>
> I don't think futex() ever was in glibc--that's by design, and
> completely understandable
On 05/14/2014 05:22 AM, Peter Zijlstra wrote:
>>> I believe the thinking goes that if we get to here, then the lock is in an
>>> inconsistent state (between kernel and userspace). I don't have an answer
>>> for
>>> why pausing forever would be preferable to returning an error however...
>>
>> What
On 05/14/2014 06:26 AM, Thomas Gleixner wrote:
> On Wed, 14 May 2014, Carlos O'Donell wrote:
>> On 05/13/2014 05:08 AM, Thomas Gleixner wrote:
>>> So anything else than ESRCH and EDEADLK is ignored and then the thing
>>> happily returns 0 at the end. Unlock is the
On 05/14/2014 07:34 PM, Thomas Gleixner wrote:
> On Wed, 14 May 2014, Carlos O'Donell wrote:
>
>> On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote:
>>>> However, unless I'm sorely mistaken, the larger problem is that glibc
>>>> removed the f
On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
>> There are other syscalls like gettid() that have a:
>> NOTE: There is no glibc wrapper for this system call; see NOTES.
>
> Yes, can we finally fix th
On 05/15/2014 09:49 AM, Michael Kerrisk (man-pages) wrote:
> On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra wrote:
>> On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
>>> On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
>>>> On Wed, May 14, 2014 a
On 05/14/2014 08:28 PM, H. Peter Anvin wrote:
> On 05/14/2014 01:56 PM, Davidlohr Bueso wrote:
>>>
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe
>>>
>>> I don't think futex() ever was in glibc--th
On 02/06/2014 06:10 AM, Jan Moskyto Matejka wrote:
> Commit cfd280c91253 ("net: sync some IP headers with glibc") changed a set of
> define's to an enum (with no explanation why) which introduced a bug
> in module mip6 where aliases are generated using the IPPROTO_* defines;
> mip6 doesn't load if
On 05/15/2014 04:19 PM, Michael Kerrisk (man-pages) wrote:
> On 05/15/2014 04:14 PM, Thomas Gleixner wrote:
>> On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote:
>>> And that universe would love to have your documentation of
>>> FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-),
>>
>> I give you alm
On Mon, Dec 1, 2014 at 4:35 PM, Geert Uytterhoeven wrote:
> On Mon, Dec 1, 2014 at 9:52 PM, Max Filippov wrote:
>> On Mon, Dec 1, 2014 at 11:43 PM, Chen Gang wrote:
>>> At present, kernel supports madvise(MADV_FREE), so can benefit to all
>>> related architectures (can grep MADV_WILLNEED or MADV
On 04/03/2016 07:30 AM, Linus Torvalds wrote:
> On Sun, Apr 3, 2016 at 6:16 AM, Ingo Molnar wrote:
>>
>> So an ABI distinction and offloading the decision to every single
>> application that
>> wants to use it and hardcode it into actual application source code via an
>> ABI is
>> pretty much th
On 9/11/19 2:26 PM, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
>> +#ifdef SHARED
>> + if (rtld_active ())
>> +{
>> + /* Register rseq ABI to the kernel. */
>> + (void) rseq_register_current_thread ();
>> +}
>> +#else
>
> I think this will need *another* check for the inne
On 9/11/19 3:08 PM, Florian Weimer wrote:
> * Carlos O'Donell:
>
>> It would be easier to merge the patch set if it were just an unconditional
>> registration like we do for set_robust_list().
>
> Note that this depends on the in-tree system call numbers list, w
On 4/2/19 2:02 AM, Michael Ellerman wrote:
Mathieu Desnoyers writes:
Hi Carlos,
- On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote:
...
[...]
+++ b/sysdeps/unix/sysv/linux/powerpc/bits/rseq.h
[...]
+/* Signature required before each abort handler
On 4/2/19 3:08 AM, Florian Weimer wrote:
* Michael Ellerman:
I'm a bit vague on what we're trying to do here.
But it seems like you want some sort of "eye catcher" prior to the branch?
That value is a valid instruction on current CPUs (rlwimi.
r5,r24,6,1,9), and even if it wasn't it could bec
On 3/25/19 11:54 AM, Mathieu Desnoyers wrote:
Hi Carlos,
- On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote:
[...]
I took care of all your comments for an upcoming round of patches, except the
following that remain open (see answer inline). I'm ad
On 4/5/19 5:16 AM, Florian Weimer wrote:
* Carlos O'Donell:
It is valuable that it be a trap, particularly for constant pools because
it means that a jump into the constant pool will trap.
Sorry, I don't understand why this matters in this context. Would you
please elaborate?
On 6/6/19 7:57 AM, Florian Weimer wrote:
> Let me ask the key question again: Does it matter if code observes the
> rseq area first without kernel support, and then with kernel support?
> If we don't expect any problems immediately, we do not need to worry
> much about the constructor ordering righ
This patch is based on glibc-2.29. The rseq(2) system call was merged
into Linux 4.18.
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC: Joseph Myers
CC: Szabolcs Nagy
CC: Thomas Gleixner
CC: Ben Maurer
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: B
, but is blocked on patch 1/4
being reworked.
Reviewed-by: Carlos O'Donell
glibc sched_getcpu(): 13.7 ns (baseline)
glibc sched_getcpu() using rseq: 2.5 ns (speedup: 5.5x)
inline load cpuid from __rseq_abi TLS: 0.8 ns (speedup: 17.1x)
Signed-off-by: Ma
On 12/26/2016 09:24 PM, Kirill A. Shutemov wrote:
> On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote:
>> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov
>> wrote:
>>> This patch introduces new rlimit resource to manage maximum virtual
>>> address available to userspace to map.
>
On 03/07/2017 07:31 AM, Sodagudi Prasad wrote:
> uapi structs epoll_data are more opaque than user space expects.
> kernel have defined as __u64 instead of the union epoll_data. Because
> of this libc have redefined struct epoll_event with union data
> member.
We do the same in glibc.
> https://a
On 11/11/2016 07:08 AM, Felix Janda wrote:
> Currently, libc-compat.h detects inclusion of specific glibc headers,
> and defines corresponding _UAPI_DEF_* macros, which in turn are used in
> uapi headers to prevent definition of conflicting structures/constants.
> There is no such detection for oth
On 03/08/2017 07:46 AM, David Woodhouse wrote:
> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote:
>> Currently, libc-compat.h detects inclusion of specific glibc headers,
>> and defines corresponding _UAPI_DEF_* macros, which in turn are used in
>> uapi headers to prevent definition of conflic
On 03/07/2017 12:59 PM, Greg KH wrote:
> On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote:
>> I don't know anyone else who is working on this problem. Though I
>> have a vested interested in it as a glibc maintainer, since it would
>> be nice t
On 03/08/2017 11:25 AM, Rich Felker wrote:
> On Wed, Mar 08, 2017 at 10:53:00AM -0500, Carlos O'Donell wrote:
>> On 11/11/2016 07:08 AM, Felix Janda wrote:
>>> Currently, libc-compat.h detects inclusion of specific glibc headers,
>>> and defines corresponding _UAPI
On 03/08/2017 07:14 PM, Szabolcs Nagy wrote:
> * Carlos O'Donell [2017-03-08 10:53:00 -0500]:
>> On 11/11/2016 07:08 AM, Felix Janda wrote:
>>> fixes the following compiler errors when is included
>>> after musl :
>>>
>>> ./linux/in6.h:32:8: er
On Thu, Mar 2, 2017 at 10:48 AM, Dmitry V. Levin wrote:
> On Thu, Mar 02, 2017 at 10:22:18AM -0500, Carlos O'Donell wrote:
>> On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote:
>> > On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote:
>> >> Include (gu
On Fri, Mar 3, 2017 at 8:23 PM, Carlos O'Donell wrote:
> On Thu, Mar 2, 2017 at 10:48 AM, Dmitry V. Levin wrote:
>> On Thu, Mar 02, 2017 at 10:22:18AM -0500, Carlos O'Donell wrote:
>>> On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote:
>>> > On Sun,
On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote:
> On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote:
>> Include (guarded by #ifndef __KERNEL__) to fix asm/signal.h
>> userspace compilation errors like this:
>>
>> /usr/include/asm/signal.h:126:2: error: unknown type name 'size_t'
>>
On 08/26/2016 10:55 AM, Florian Weimer wrote:
> On 08/25/2016 06:15 PM, James Bottomley wrote:
>> On Sun, 2016-08-21 at 21:01 -0700, Josh Max wrote:
>>> This patch allows binfmt_misc to select the interpeter for
>>> arbitrary binaries by comparing a specified registered keyword
>>> with the value o
On 7/2/20 10:46 AM, Florian Weimer wrote:
> * Mathieu Desnoyers via Libc-alpha:
>
>> Register rseq TLS for each thread (including main), and unregister for
>> each thread (excluding main). "rseq" stands for Restartable Sequences.
>>
>> See the rseq(2) man page proposed here:
>> https://lkml.org
On 7/7/20 8:06 AM, Mathieu Desnoyers wrote:
> - On Jul 7, 2020, at 7:32 AM, Florian Weimer f...@deneb.enyo.de wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Those are very good points. One possibility we have would be to let
>>> glibc do the rseq registration without the RSEQ_FLAG_RELIABLE_CPU_ID
>>>
On 5/15/20 12:27 PM, Peter Zijlstra wrote:
> On Fri, May 15, 2020 at 06:36:47PM +0300, Konstantin Khlebnikov wrote:
>> Userspace implementations of mutexes (including glibc) in some cases
>> retries operation without checking error code from syscall futex.
>> This is good for performance because mo
On 10/30/20 11:10 AM, Thomas Gleixner via Libc-alpha wrote:
> On Fri, Oct 30 2020 at 10:02, Zack Weinberg wrote:
>> On Fri, Oct 30, 2020 at 9:57 AM Cyril Hrubis wrote:
According to patch description [1] and time_namespaces documentation
[2] the CLOCK_REALTIME is not supported (for now?)
On 10/30/20 4:06 PM, Thomas Gleixner wrote:
> On Fri, Oct 30 2020 at 12:58, Carlos O'Donell wrote:
>> I expect that more requests for further time isolation will happen
>> given the utility of this in containers.
>
> There was a lengthy discussion about this and the
On 10/30/20 9:38 PM, Thomas Gleixner wrote:
> Coming back to your test coverage argument. I really don't see a problem
> with the requirement of having qemu installed in order to run 'make
> check'.
Cost. It's is cheaper and easier to maintain and deploy containers.
A full VM requires maintaining
On 7/13/20 11:03 PM, Mathieu Desnoyers wrote:
> Recent discussion led to a solution for extending struct rseq. This is
> an implementation of the proposed solution.
>
> Now is a good time to agree on this scheme before the release of glibc
> 2.32, just in case there are small details to fix on the
On 7/14/20 9:19 AM, Mathieu Desnoyers wrote:
> Is there an arch-agnostic way to get the thread pointer from user-space code
> ? That
> would be needed by all rseq critical section implementations.
Yes, and no. We have void *__builtin_thread_pointer (void), but
few architectures implement the buil
On 7/15/20 9:02 AM, Mathieu Desnoyers wrote:
> At this point, the main question I would like answered is whether
> it would be acceptable to increase the size and alignment of
> the __rseq_abi symbol (which will be exposed by glibc) between
> e.g. glibc 2.32 and 2.33. If it's not possible, then we
On 7/16/20 4:30 PM, Gabriel Krisman Bertazi wrote:
> Christian Brauner writes:
>
>> On Thu, Jul 16, 2020 at 01:25:43PM -0700, Kees Cook wrote:
>>> On Thu, Jul 16, 2020 at 10:22:34PM +0200, Christian Brauner wrote:
On Thu, Jul 16, 2020 at 01:04:38PM -0700, Kees Cook wrote:
> On Thu, Jul 1
On 11/06/2016 05:39 PM, Dmitry Vyukov wrote:
> Hello,
>
> This is notes from the discussion we had at Linux Plumbers this week
> regarding providing a formal description of system calls (user API).
>
> The idea come up in the context of syzkaller, syscall fuzzer, which
> has descriptions for 1000
On 04/25/2017 02:37 AM, Hauke Mehrtens wrote:
>
>
> On 03/08/2017 01:46 PM, David Woodhouse wrote:
>> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote:
>>> Currently, libc-compat.h detects inclusion of specific glibc headers,
>>> and defines corresponding _UAPI_DEF_* macros, which in turn are
On 04/25/2017 02:45 AM, Hauke Mehrtens wrote:
> On 03/08/2017 05:39 PM, Carlos O'Donell wrote:
>> Any header needing compat with a libc includes libc-compat.h (per the
>> documented way the model works). With this patch any included linux kernel
>> header that also in
On 08/09/2017 05:24 PM, H.J. Lu wrote:
> On Wed, Aug 9, 2017 at 1:32 PM, Kostya Serebryany wrote:
I believe this would only be an output bit, but I'm not sure how it
would be wired into binutils. Kostya, do you know any details about
how AddressSanitizer might be able to create
On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> Containers are a userspace concept. The kernel knows nothing of them.
I am looking at this RFC from a userspace perspective, particularly from
the loader's point of view and the unshare syscall and the semantics that
arise from the use of it.
A
79 matches
Mail list logo
