ebied...@xmission.com (Eric W. Biederman) writes:
> I am going to stop there. I believe there are more issues in the code.
> I am relieved that I am not seeing the loss of some of the security
> hooks that I thought I saw last time I looked at the code.
Bah. Now I see the missing secu
ebied...@xmission.com (Eric W. Biederman) writes:
> I am going to stop there. I believe there are more issues in the code.
> I am relieved that I am not seeing the loss of some of the security
> hooks that I thought I saw last time I looked at the code.
Bah. Now I see the missing secu
Al Viro writes:
> mount API series from David Howells. Last cycle's objections
> had been of the "I'd do it differently" variety and with no such
> differently done variants having ever materialized over several
> cycles...
Absolutely not.
My objections fundamentally is that I can find
Al Viro writes:
> mount API series from David Howells. Last cycle's objections
> had been of the "I'd do it differently" variety and with no such
> differently done variants having ever materialized over several
> cycles...
Absolutely not.
My objections fundamentally is that I can find
Christian Brauner writes:
> On Tue, Oct 30, 2018 at 12:12 PM Daniel Colascione wrote:
>>
>> On Tue, Oct 30, 2018 at 11:04 AM, Christian Brauner
>> wrote:
>> > On Tue, Oct 30, 2018 at 11:48 AM Daniel Colascione
>> > wrote:
>> >>
>> >> Why not?
>> >>
>> >> Does your proposed API allow for a
Christian Brauner writes:
> On Tue, Oct 30, 2018 at 12:12 PM Daniel Colascione wrote:
>>
>> On Tue, Oct 30, 2018 at 11:04 AM, Christian Brauner
>> wrote:
>> > On Tue, Oct 30, 2018 at 11:48 AM Daniel Colascione
>> > wrote:
>> >>
>> >> Why not?
>> >>
>> >> Does your proposed API allow for a
Aleksa Sarai writes:
> On 2018-10-29, Daniel Colascione wrote:
>> Add a simple proc-based kill interface. To use /proc/pid/kill, just
>> write the signal number in base-10 ASCII to the kill file of the
>> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>>
>> Semantically,
Aleksa Sarai writes:
> On 2018-10-29, Daniel Colascione wrote:
>> Add a simple proc-based kill interface. To use /proc/pid/kill, just
>> write the signal number in base-10 ASCII to the kill file of the
>> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>>
>> Semantically,
Daniel Colascione writes:
> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> write the signal number in base-10 ASCII to the kill file of the
> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> Semantically, /proc/pid/kill works like kill(2), except that the
>
Daniel Colascione writes:
> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> write the signal number in base-10 ASCII to the kill file of the
> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> Semantically, /proc/pid/kill works like kill(2), except that the
>
s controlled by CAP_SYS_NICE inside a
> namespace, it should also be able to adjust timerslack_ns.
Acked-by: "Eric W. Biederman"
I don't see any fundamental probess with how the processes user
namespace is being accessed. You can race with setns
and that may result in a descendent user name
s controlled by CAP_SYS_NICE inside a
> namespace, it should also be able to adjust timerslack_ns.
Acked-by: "Eric W. Biederman"
I don't see any fundamental probess with how the processes user
namespace is being accessed. You can race with setns
and that may result in a descendent user name
Thomas Gleixner writes:
> Andrei,
>
> On Sat, 20 Oct 2018, Andrei Vagin wrote:
>> When a container is migrated to another host, we have to restore its
>> monotonic and boottime clocks, but we still expect that the container
>> will continue using the host real-time clock.
>>
>> Before stating
Thomas Gleixner writes:
> Andrei,
>
> On Sat, 20 Oct 2018, Andrei Vagin wrote:
>> When a container is migrated to another host, we have to restore its
>> monotonic and boottime clocks, but we still expect that the container
>> will continue using the host real-time clock.
>>
>> Before stating
Jann Horn writes:
> On Wed, Oct 24, 2018 at 3:30 PM Eric W. Biederman
> wrote:
>> Enke Chen writes:
>> > For simplicity and consistency, this patch provides an implementation
>> > for signal-based fault notification prior to the coredump of a child
>
Jann Horn writes:
> On Wed, Oct 24, 2018 at 3:30 PM Eric W. Biederman
> wrote:
>> Enke Chen writes:
>> > For simplicity and consistency, this patch provides an implementation
>> > for signal-based fault notification prior to the coredump of a child
>
bmgor...@google.com writes:
> From: Benjamin Gordon
>
> Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
> in its effective capability set, but the current check looks in the root
> namespace instead of the process' user namespace. Since a process is
> allowed to do other
bmgor...@google.com writes:
> From: Benjamin Gordon
>
> Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
> in its effective capability set, but the current check looks in the root
> namespace instead of the process' user namespace. Since a process is
> allowed to do other
Florian Fainelli writes:
> Some software such as perf makes unconditional use of the special
> [vectors] page which is only provided when CONFIG_KUSER_HELPERS is
> enabled in the kernel.
>
> Facilitate the debugging of such situations by printing a debug message
> to the kernel log showing the
Florian Fainelli writes:
> Some software such as perf makes unconditional use of the special
> [vectors] page which is only provided when CONFIG_KUSER_HELPERS is
> enabled in the kernel.
>
> Facilitate the debugging of such situations by printing a debug message
> to the kernel log showing the
Enke Chen writes:
> Hi, Eric:
>
> Thanks for your comments. Please see my replies inline.
>
> On 10/24/18 6:29 AM, Eric W. Biederman wrote:
>> Enke Chen writes:
>>
>>> For simplicity and consistency, this patch provides an implementation
>>&
Enke Chen writes:
> Hi, Eric:
>
> Thanks for your comments. Please see my replies inline.
>
> On 10/24/18 6:29 AM, Eric W. Biederman wrote:
>> Enke Chen writes:
>>
>>> For simplicity and consistency, this patch provides an implementation
>>&
Enke Chen writes:
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> be used by an application to express its interest and to
Enke Chen writes:
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> be used by an application to express its interest and to
ves a conflict from removing a unnecessary pkey parameter
on the siginfo side and a some small refactoring on the x86 side.
Eric W. Biederman (80):
signal: Always ignore SIGKILL and SIGSTOP sent to the global init
signal: Properly deliver SIGILL from uprobes
signal: Properly deli
ves a conflict from removing a unnecessary pkey parameter
on the siginfo side and a some small refactoring on the x86 side.
Eric W. Biederman (80):
signal: Always ignore SIGKILL and SIGSTOP sent to the global init
signal: Properly deliver SIGILL from uprobes
signal: Properly deli
"Paul E. McKenney" writes:
> On Sat, Oct 20, 2018 at 04:18:37PM -0400, Alan Stern wrote:
>> On Sat, 20 Oct 2018, Paul E. McKenney wrote:
>>
>> > The second (informal) litmus test has a more interesting Linux-kernel
>> > counterpart:
>> >
>> >void t1_interrupt(void)
>> >{
>> >
"Paul E. McKenney" writes:
> On Sat, Oct 20, 2018 at 04:18:37PM -0400, Alan Stern wrote:
>> On Sat, 20 Oct 2018, Paul E. McKenney wrote:
>>
>> > The second (informal) litmus test has a more interesting Linux-kernel
>> > counterpart:
>> >
>> >void t1_interrupt(void)
>> >{
>> >
David Howells writes:
> From: Al Viro
>
> Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be
> attached by move_mount(2).
>
> If by the time of final fput() of OPEN_TREE_CLONE-opened file its tree is
> not detached anymore, it won't be dissolved. move_mount(2) is adjusted
>
David Howells writes:
> From: Al Viro
>
> Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be
> attached by move_mount(2).
>
> If by the time of final fput() of OPEN_TREE_CLONE-opened file its tree is
> not detached anymore, it won't be dissolved. move_mount(2) is adjusted
>
David Howells writes:
> From: Al Viro
>
> open_tree(dfd, pathname, flags)
>
> Returns an O_PATH-opened file descriptor or an error.
> dfd and pathname specify the location to open, in usual
> fashion (see e.g. fstatat(2)). flags should be an OR of
> some of the following:
> *
David Howells writes:
> From: Al Viro
>
> open_tree(dfd, pathname, flags)
>
> Returns an O_PATH-opened file descriptor or an error.
> dfd and pathname specify the location to open, in usual
> fashion (see e.g. fstatat(2)). flags should be an OR of
> some of the following:
> *
David Howells writes:
> Eric W. Biederman wrote:
>
>> Davids check will work for bind mounts as well. It just won't work it
>> just won't work for files or subdirectories of some mountpoint.
>
> Bind mounts have to be done with open_tree() and move_mount(). Yo
David Howells writes:
> Eric W. Biederman wrote:
>
>> Davids check will work for bind mounts as well. It just won't work it
>> just won't work for files or subdirectories of some mountpoint.
>
> Bind mounts have to be done with open_tree() and move_mount(). Yo
Alan Jenkins writes:
> On 17/10/2018 14:20, David Howells wrote:
>> David Howells wrote:
>>
>>> I should probably check that the picked point is actually a mountpoint.
>> The root of the mount object at the path specified, that is, perhaps with
>> something like the attached.
>>
>> David
>
>
>
Alan Jenkins writes:
> On 17/10/2018 14:20, David Howells wrote:
>> David Howells wrote:
>>
>>> I should probably check that the picked point is actually a mountpoint.
>> The root of the mount object at the path specified, that is, perhaps with
>> something like the attached.
>>
>> David
>
>
>
Christian Brauner writes:
> proc_get_long() is a funny function. It uses simple_strtoul() and for a
> good reason. proc_get_long() wants to always succeed the parse and return
> the maybe incorrect value and the trailing characters to check against a
> pre-defined list of acceptable trailing
Christian Brauner writes:
> proc_get_long() is a funny function. It uses simple_strtoul() and for a
> good reason. proc_get_long() wants to always succeed the parse and return
> the maybe incorrect value and the trailing characters to check against a
> pre-defined list of acceptable trailing
Enke Chen writes:
> Hi, Eric:
>
> On 10/15/18 4:28 PM, Eric W. Biederman wrote:
>> With that said I think the best solution would be to figure out how to
>> allow the coredump to run in parallel with the usual exit signal, and
>> exit code reaping of the pr
Enke Chen writes:
> Hi, Eric:
>
> On 10/15/18 4:28 PM, Eric W. Biederman wrote:
>> With that said I think the best solution would be to figure out how to
>> allow the coredump to run in parallel with the usual exit signal, and
>> exit code reaping of the pr
Oleg Nesterov writes:
> On 10/15, Enke Chen wrote:
>>
>> > I don't understand why we need valid_predump_signal() at all.
>>
>> Most of the signals have well-defined semantics, and would not be appropriate
>> for this purpose.
>
> you are going to change the rules anyway.
I will just add that
Oleg Nesterov writes:
> On 10/15, Enke Chen wrote:
>>
>> > I don't understand why we need valid_predump_signal() at all.
>>
>> Most of the signals have well-defined semantics, and would not be appropriate
>> for this purpose.
>
> you are going to change the rules anyway.
I will just add that
Enke Chen writes:
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> be used by an application to express its interest and to
Enke Chen writes:
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> be used by an application to express its interest and to
Jann Horn writes:
> On Mon, Oct 15, 2018 at 7:10 PM wrote:
>> @@ -1281,7 +1285,7 @@ static int userns_install(struct nsproxy *nsproxy,
>> struct ns_common *ns)
>> return -ENOMEM;
>>
>> put_user_ns(cred->user_ns);
>> - set_cred_user_ns(cred, get_user_ns(user_ns));
Jann Horn writes:
> On Mon, Oct 15, 2018 at 7:10 PM wrote:
>> @@ -1281,7 +1285,7 @@ static int userns_install(struct nsproxy *nsproxy,
>> struct ns_common *ns)
>> return -ENOMEM;
>>
>> put_user_ns(cred->user_ns);
>> - set_cred_user_ns(cred, get_user_ns(user_ns));
Have you considered using pivot_root to drop all of the pieces of the
filesystem you don't want to be visible? That should be a much better
solution overall.
It is must a matter of:
mount --bind /path/you/would/chroot/to
pivot_root /path/you/would/chroot/to /put/old
umount -l /put/old
You
Have you considered using pivot_root to drop all of the pieces of the
filesystem you don't want to be visible? That should be a much better
solution overall.
It is must a matter of:
mount --bind /path/you/would/chroot/to
pivot_root /path/you/would/chroot/to /put/old
umount -l /put/old
You
Stephen Rothwell writes:
> Hi all,
>
> On Mon, 15 Oct 2018 15:11:59 +1100 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the userns tree got a conflict in:
>>
>> arch/x86/mm/fault.c
>>
>> between commit:
>>
>> 164477c2331b ("x86/mm: Clarify hardware vs. software
Stephen Rothwell writes:
> Hi all,
>
> On Mon, 15 Oct 2018 15:11:59 +1100 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the userns tree got a conflict in:
>>
>> arch/x86/mm/fault.c
>>
>> between commit:
>>
>> 164477c2331b ("x86/mm: Clarify hardware vs. software
tip-bot for Dave Hansen writes:
> Commit-ID: aa37c51b9421d66f7931c5fdcb9ce80c450974be
> Gitweb:
> https://git.kernel.org/tip/aa37c51b9421d66f7931c5fdcb9ce80c450974be
> Author: Dave Hansen
> AuthorDate: Fri, 28 Sep 2018 09:02:23 -0700
> Committer: Peter Zijlstra
> CommitDate: Tue, 9
tip-bot for Dave Hansen writes:
> Commit-ID: aa37c51b9421d66f7931c5fdcb9ce80c450974be
> Gitweb:
> https://git.kernel.org/tip/aa37c51b9421d66f7931c5fdcb9ce80c450974be
> Author: Dave Hansen
> AuthorDate: Fri, 28 Sep 2018 09:02:23 -0700
> Committer: Peter Zijlstra
> CommitDate: Tue, 9
branch where these
fixes exist was tested.
I have not problem with that sequence of events it is just a little
surprising.
If I have not read this test report correctly please let me know.
Eric
> commit 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0
> Author: Eric W. Biederman
>
branch where these
fixes exist was tested.
I have not problem with that sequence of events it is just a little
surprising.
If I have not read this test report correctly please let me know.
Eric
> commit 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0
> Author: Eric W. Biederman
>
David Howells writes:
> Okay, this appears to fix the cycle-creation problem.
>
> It could probably be improved by comparing sequence numbers as Alan suggests,
> but I need to work out how to get at that.
It should just be a matter of replacing the test
"if (p->mnt.mnt_sb->s_type == )" with "if
David Howells writes:
> Okay, this appears to fix the cycle-creation problem.
>
> It could probably be improved by comparing sequence numbers as Alan suggests,
> but I need to work out how to get at that.
It should just be a matter of replacing the test
"if (p->mnt.mnt_sb->s_type == )" with "if
ebied...@xmission.com (Eric W. Biederman) writes:
> Sean Christopherson writes:
>
>> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
>>> ebied...@xmission.com (Eric W. Biederman) writes:
>>>
>>> > So I am flummoxed. I a
ebied...@xmission.com (Eric W. Biederman) writes:
> Sean Christopherson writes:
>
>> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
>>> ebied...@xmission.com (Eric W. Biederman) writes:
>>>
>>> > So I am flummoxed. I a
Sean Christopherson writes:
> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> > So I am flummoxed. I am reading through the code and I don't see
>> > anything that could trigger
Sean Christopherson writes:
> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> > So I am flummoxed. I am reading through the code and I don't see
>> > anything that could trigger
James Bottomley writes:
> Resend to show accumulated tags and also to add a third patch listing
> the TAB as the reporting point as a few people seem to want. If it
> gets the same level of support, I'll send it in with the other two.
There is also:
> Our Responsibilities
>
James Bottomley writes:
> Resend to show accumulated tags and also to add a third patch listing
> the TAB as the reporting point as a few people seem to want. If it
> gets the same level of support, I'll send it in with the other two.
There is also:
> Our Responsibilities
>
ption clause for email addresses ordinarily collected by
> the project to correct this ambiguity.
Acked-by: "Eric W. Biederman"
>
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Acked-by: Geert Uytterhoeven
> Acked-by: Shuah Khan
> Acked-by:
ption clause for email addresses ordinarily collected by
> the project to correct this ambiguity.
Acked-by: "Eric W. Biederman"
>
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Acked-by: Geert Uytterhoeven
> Acked-by: Shuah Khan
> Acked-by:
ebied...@xmission.com (Eric W. Biederman) writes:
> So I am flummoxed. I am reading through the code and I don't see
> anything that could trigger this, and when I ran the supplied reproducer
> it did not reproduce for me.
Even more so. With my tool chain the line that reports th
ebied...@xmission.com (Eric W. Biederman) writes:
> So I am flummoxed. I am reading through the code and I don't see
> anything that could trigger this, and when I ran the supplied reproducer
> it did not reproduce for me.
Even more so. With my tool chain the line that reports th
to work.
Eric
kernel test robot writes:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
> commit 4ce5f9c9e7546915c559ffae594e6d73f918db00
> Autho
to work.
Eric
kernel test robot writes:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
> commit 4ce5f9c9e7546915c559ffae594e6d73f918db00
> Autho
l sets the si_signo field to the value specified
>in sig, so that the receiver of the signal can also obtain the signal
>number via that field.
>
> On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
>>
>> If there is some application that call
l sets the si_signo field to the value specified
>in sig, so that the receiver of the signal can also obtain the signal
>number via that field.
>
> On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
>>
>> If there is some application that call
Andrei Vagin writes:
> On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
>> The kernel needs to validate that the contents of struct siginfo make
>> sense as siginfo is copied into the kernel, so that the proper union
>> members can be put in the
Andrei Vagin writes:
> On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
>> The kernel needs to validate that the contents of struct siginfo make
>> sense as siginfo is copied into the kernel, so that the proper union
>> members can be put in the
Andrei Vagin writes:
> On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
>> The kernel needs to validate that the contents of struct siginfo make
>> sense as siginfo is copied into the kernel, so that the proper union
>> members can be put in the
Andrei Vagin writes:
> On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
>> The kernel needs to validate that the contents of struct siginfo make
>> sense as siginfo is copied into the kernel, so that the proper union
>> members can be put in the
Pavel Snajdr writes:
>
> We started our organization (vpsFree.org) on top of OpenVZ patch set and are
> now
> working to get vanilla up to the task of replacing the venerable 2.6.32-based
> OpenVZ 6 Linux-like thing. The new Code of Conduct is a guarantee for us, that
> we won't be laughed out
Pavel Snajdr writes:
>
> We started our organization (vpsFree.org) on top of OpenVZ patch set and are
> now
> working to get vanilla up to the task of replacing the venerable 2.6.32-based
> OpenVZ 6 Linux-like thing. The new Code of Conduct is a guarantee for us, that
> we won't be laughed out
Stephen Rothwell writes:
> Hi Eric,
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> kernel/signal.c
>
> between commit:
>
> 49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use
> __kernel_timespec")
>
> from the y2038 tree and commit:
>
> ae7795bc6187
Stephen Rothwell writes:
> Hi Eric,
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> kernel/signal.c
>
> between commit:
>
> 49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use
> __kernel_timespec")
>
> from the y2038 tree and commit:
>
> ae7795bc6187
Thomas Gleixner writes:
> On Wed, 3 Oct 2018, Eric W. Biederman wrote:
>> Direct access to hardware/drivers and not through an abstraction like
>> the vfs (an abstraction over block devices) can legitimately be handled
>> by hotplug events. I unplug one keyboard I plug
Thomas Gleixner writes:
> On Wed, 3 Oct 2018, Eric W. Biederman wrote:
>> Direct access to hardware/drivers and not through an abstraction like
>> the vfs (an abstraction over block devices) can legitimately be handled
>> by hotplug events. I unplug one keyboard I plug
Laurent Vivier writes:
> This patch allows to have a different binftm_misc configuration
> in each container we mount binfmt_misc filesystem with mount namespace
> enabled.
>
> A container started without the CLONE_NEWNS will use the host binfmt_misc
> configuration, otherwise the container
Laurent Vivier writes:
> This patch allows to have a different binftm_misc configuration
> in each container we mount binfmt_misc filesystem with mount namespace
> enabled.
>
> A container started without the CLONE_NEWNS will use the host binfmt_misc
> configuration, otherwise the container
Thomas Gleixner writes:
> On Tue, 2 Oct 2018, Arnd Bergmann wrote:
>> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote:
>> >
>> > On Mon, 1 Oct 2018, Eric W. Biederman wrote:
>> > > In the context of process migration there is a simpler subproblem th
Thomas Gleixner writes:
> On Tue, 2 Oct 2018, Arnd Bergmann wrote:
>> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote:
>> >
>> > On Mon, 1 Oct 2018, Eric W. Biederman wrote:
>> > > In the context of process migration there is a simpler subproblem th
In the context of process migration there is a simpler subproblem that I
think it is worth exploring if we can do something about.
For a cluster of machines all running with synchronized
clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
machines. Not having a matching
In the context of process migration there is a simpler subproblem that I
think it is worth exploring if we can do something about.
For a cluster of machines all running with synchronized
clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
machines. Not having a matching
Thomas Gleixner writes:
> Eric,
>
> On Fri, 28 Sep 2018, Eric W. Biederman wrote:
>> Thomas Gleixner writes:
>> > On Wed, 26 Sep 2018, Eric W. Biederman wrote:
>> >> At the same time using the techniques from the nohz work and a little
>> >>
Thomas Gleixner writes:
> Eric,
>
> On Fri, 28 Sep 2018, Eric W. Biederman wrote:
>> Thomas Gleixner writes:
>> > On Wed, 26 Sep 2018, Eric W. Biederman wrote:
>> >> At the same time using the techniques from the nohz work and a little
>> >>
Laurent Vivier writes:
> Le 01/10/2018 à 09:21, Eric W. Biederman a écrit :
>> Andy Lutomirski writes:
>>
>>> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier wrote:
>>>>
>>>> This series introduces a new namespace for binfmt_misc.
>>>&g
Laurent Vivier writes:
> Le 01/10/2018 à 09:21, Eric W. Biederman a écrit :
>> Andy Lutomirski writes:
>>
>>> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier wrote:
>>>>
>>>> This series introduces a new namespace for binfmt_misc.
>>>&g
Andy Lutomirski writes:
> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier wrote:
>>
>> This series introduces a new namespace for binfmt_misc.
>>
>
> This seems conceptually quite reasonable, but I'm wondering if the
> number of namespace types is getting out of hand given the current
> API.
Andy Lutomirski writes:
> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier wrote:
>>
>> This series introduces a new namespace for binfmt_misc.
>>
>
> This seems conceptually quite reasonable, but I'm wondering if the
> number of namespace types is getting out of hand given the current
> API.
Thomas Gleixner writes:
> On Wed, 26 Sep 2018, Eric W. Biederman wrote:
>> Reading the code the calling sequence there is:
>> tick_sched_do_timer
>>tick_do_update_jiffies64
>> update_wall_time
>> timekeeping_advance
>>
Thomas Gleixner writes:
> On Wed, 26 Sep 2018, Eric W. Biederman wrote:
>> Reading the code the calling sequence there is:
>> tick_sched_do_timer
>>tick_do_update_jiffies64
>> update_wall_time
>> timekeeping_advance
>>
Guo Ren writes:
> --- /dev/null
> +++ b/arch/csky/abiv2/fpu.c
> +void fpu_fpe(struct pt_regs * regs)
> +{
> + int sig;
> + unsigned int fesr;
> + siginfo_t info;
> +
> + fesr = mfcr("cr<2, 2>");
> +
> + if(fesr & FPE_ILLE){
> + info.si_code = ILL_ILLOPC;
> +
Guo Ren writes:
> --- /dev/null
> +++ b/arch/csky/abiv2/fpu.c
> +void fpu_fpe(struct pt_regs * regs)
> +{
> + int sig;
> + unsigned int fesr;
> + siginfo_t info;
> +
> + fesr = mfcr("cr<2, 2>");
> +
> + if(fesr & FPE_ILLE){
> + info.si_code = ILL_ILLOPC;
> +
Jarkko Sakkinen writes:
> From: Sean Christopherson
>
> Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the
> error code. The PF_SGX bit is set if and only if the #PF is detected
> by the Enclave Page Cache Map (EPCM), which is consulted only after
> an access walks the kernel's
Jarkko Sakkinen writes:
> From: Sean Christopherson
>
> Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the
> error code. The PF_SGX bit is set if and only if the #PF is detected
> by the Enclave Page Cache Map (EPCM), which is consulted only after
> an access walks the kernel's
Jarkko Sakkinen writes:
> From: Sean Christopherson
>
> The SGX Enclave Page Cache Map (EPCM) is a hardware-managed table
> that enforces accesses to an enclave's EPC page in addition to the
> software-managed kernel page tables, i.e. the effective permissions
> for an EPC page are a logical
Jarkko Sakkinen writes:
> From: Sean Christopherson
>
> The SGX Enclave Page Cache Map (EPCM) is a hardware-managed table
> that enforces accesses to an enclave's EPC page in addition to the
> software-managed kernel page tables, i.e. the effective permissions
> for an EPC page are a logical
801 - 900 of 10702 matches
Mail list logo
