Greg Ungerer writes:
> On 1/5/20 5:07 am, Eric W. Biederman wrote:
>> Linus Torvalds writes:
>>
>>> On Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote:
>>
>>>>> Most of that file goes back to pre-git days. And most of the commits
>>>>>
Linus Torvalds writes:
> On Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote:
>> > Most of that file goes back to pre-git days. And most of the commits
>> > since are not so much about binfmt_flat, as they are about cleanups or
>> > changes elsewhere where binfmt_flat was just a victim.
>>
>>
tns. I don't understand the
justification for this.
Is it your intention to use the reduced permissions that you get
when you install a user namespace?
Why do you want to use the reduced permissions when installing multiple
namespaces at once?
Eric
> Cc: Eric W. Biederman
> Cc: Serge Hall
David Hildenbrand writes:
> On 30.04.20 18:33, Eric W. Biederman wrote:
>> David Hildenbrand writes:
>>
>>> On 30.04.20 17:38, Eric W. Biederman wrote:
>>>> David Hildenbrand writes:
>>>>
>>>>> Some devices/drivers that add memo
David Hildenbrand writes:
> On 30.04.20 17:38, Eric W. Biederman wrote:
>> David Hildenbrand writes:
>>
>>> Some devices/drivers that add memory via add_memory() and friends (e.g.,
>>> dax/kmem, but also virtio-mem in the future) don't want to create en
; If there is no entry, it will simply return with -EINVAL.
>
> [1]
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
You know what this justification is rubbish, and I have previously
explained why it is rubbish.
Nacked-by: "Eric W. Biederman"
@nanos.tec.linutronix.de/
Ref: 33ab0fec3352 ("posix-timers: Consolidate posix_cpu_clock_get()")
Ref: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task")
Signed-off-by: "Eric W. Biederman"
---
kernel/time/posix-cpu-timers.c | 75 ++--
Taking a clock and returning a pid_type is a more general and
a superset of taking a timer and returning a pid_type.
Perform this generalization so that future changes may use
this code on clocks as well as timers.
Signed-off-by: "Eric W. Biederman"
---
kernel/time/posix-cpu-ti
Now that the code stores of pid references it is no longer necessary
or desirable to take a reference on task_struct in __get_task_for_clock.
Instead extend the scope of rcu_read_lock and remove the reference
counting on struct task_struct entirely.
Signed-off-by: "Eric W. Bied
| 102 ++---
1 file changed, 45 insertions(+), 57 deletions(-)
Suggested-by: Oleg Nesterov
Signed-off-by: "Eric W. Biederman"
---
The changes can also be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
proc-testing
After the introduction of exchange_tids has_group_leader_pid is
equivalent to thread_group_leader. After the last couple of cleanups
has_group_leader_pid has no more callers.
So remove the now unused and redundant has_group_leader_pid.
Signed-off-by: "Eric W. Biederman"
---
inc
to
be the thread_group_leader.
This is also the last user of has_group_leader_pid so removing this check
will allow has_group_leader_pid to be removed.
So remove the "BUG_ON(has_group_leader_pid)" that will never fire.
Signed-off-by: "Eric W. Biederman"
---
fs/exec.c | 1
Now that both !thread paths through lookup_task call
thread_group_leader, unify them into the single test at the end of
lookup_task.
This unification just makes it clear what is happening in the gettime
special case of lookup_task.
Signed-off-by: "Eric W. Biederman"
---
kernel/
not a task")
Ref: c0deae8c9587 ("posix-cpu-timers: Rcu_read_lock/unlock protect
find_task_by_vpid call")
Signed-off-by: "Eric W. Biederman"
---
kernel/time/posix-cpu-timers.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/time/posix-cpu-timer
to lookup_task that performs that unifies
to code paths that become identical when has_group_leader_pid went
away.
Eric W. Biederman (4):
posix-cpu-timer: Tidy up group_leader logic in lookup_task
posix-cpu-timer: Unify the now redundant code in lookup_task
exec: Remove BUG_ON
Linus Torvalds writes:
> On Tue, Apr 28, 2020 at 5:20 AM Eric W. Biederman
> wrote:
>>
>> In short I don't think this change will introduce any regressions.
>
> I think the series looks fine.
Mind if I translate that into
Acked-by: Linus Torvalds
on the patches?
Eric
Oleg Nesterov writes:
> On 04/28, Eric W. Biederman wrote:
>>
>> In short I don't think this change will introduce any regressions.
>>
>> Eric W. Biederman (2):
>> rculist: Add hlists_swap_heads_rcu
>> proc: Ensure we see the exit of each proc
Linus Torvalds writes:
> On Tue, Apr 28, 2020 at 5:20 AM Eric W. Biederman
> wrote:
>>
>> In short I don't think this change will introduce any regressions.
>
> I think the series looks fine, but I also think the long explanation
> (that I snipped in this reply)
ld hack, so this should be safe to merge
now.
Fixes: 48e6484d4902 ("[PATCH] proc: Rewrite the proc dentry flush on exit
optimization").
Signed-off-by: Eric W. Biederman
---
fs/exec.c | 5 +
include/linux/pid.h | 1 +
kernel/pid.c| 19 +++
3 files chan
. This is
exactly what is needed for exchanging the pids of two tasks.
Only consideration of correctness of the code has been given,
as the caller is expected to be a slowpath.
Signed-off-by: "Eric W. Biederman"
---
include/linux/rculist.h | 21 +
1 file changed, 21 insertion
before it makes any changes of this
kind the race can not happen.
In short I don't think this change will introduce any regressions.
Eric W. Biederman (2):
rculist: Add hlists_swap_heads_rcu
proc: Ensure we see the exit of each process tid exactly once
fs/exec.c |
"Michael Kerrisk (man-pages)" writes:
> Hello Eric,
>
> Thank you. I was hoping you might jump in on this thread.
>
> Please see below.
>
> On 10/9/19 10:46 AM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" writes:
>>
>
"Michael Kerrisk (man-pages)" writes:
> Hello Philipp,
>
> My apologies that it has taken a while to reply. (I had been hoping
> and waiting that a few more people might weigh in on this thread.)
>
> On 9/23/19 3:42 PM, Philipp Wendler wrote:
>> Hello Michael,
>>
>> Am 23.09.19 um 14:04 schrieb
"Michael Kerrisk (man-pages)" writes:
> On 10/8/19 9:40 PM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" writes:
>>
>>> Hello Eric,
>>>
>>>>>> Creating of a mount namespace in a user namespace automatically
"Michael Kerrisk (man-pages)" writes:
> Hello Eric,
>
Creating of a mount namespace in a user namespace automatically does
'mount("", "/", MS_SLAVE | MS_REC, NULL);' if the starting mount
namespace was not created in that user namespace. AKA creating
a mount namespace in a
"Michael Kerrisk (man-pages)" writes:
> Hello Eric,
>
> On 9/30/19 2:42 PM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" writes:
>>
>>> Hello Eric,
>>>
>>> A ping on my question below. Could you take a look plea
Arnd Bergmann writes:
> On Wed, Oct 2, 2019 at 12:54 AM Eric W. Biederman
> wrote:
>> arch/arm/configs/lpc32xx_defconfig:CONFIG_SYSCTL_SYSCALL=y
>> arch/arm/configs/moxart_defconfig:CONFIG_SYSCTL_SYSCALL=y
>
> Ancient hardware, but still in active use. These tend t
Arnd Bergmann writes:
> On Wed, Oct 2, 2019 at 12:54 AM Eric W. Biederman
> wrote:
>> Kees Cook writes:
>> > On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote:
>> >
>> > I think you can actually take this further and remove (or at least
&
Kees Cook writes:
> On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote:
>>
>> This system call has been deprecated almost since it was introduced, and
>> in a survey of the linux distributions I can no longer find any of them
>> that enable CONFI
"Michael Kerrisk (man-pages)" writes:
> Hello Eric,
>
> A ping on my question below. Could you take a look please?
>
> Thanks,
>
> Michael
>
> The concern from our conversation at the container mini-summit was that
> there is a pathology if in your initial mount namespace all of the
Alun Evans writes:
> On Fri 27 Sep '19 at 07:46 ebied...@xmission.com (Eric W. Biederman) wrote:
>>
>> Alun Evans writes:
>>
>>> Hi Eric,
>>>
>>>
>>> On Tue, 19 Feb 2019, Eric W. Biederman wrote:
>>>>
>>>>
Alun Evans writes:
> Hi Eric,
>
>
> On Tue, 19 Feb 2019, Eric W. Biederman wrote:
>>
>> David Howells writes:
>>
>> > Provide a system call to open a socket inside of a container, using that
>> > container's network namespace. This allows
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 5311a98fef7d0dc2e8040ae0e18f5568d6d1dd5a
Gitweb:
https://git.kernel.org/tip/5311a98fef7d0dc2e8040ae0e18f5568d6d1dd5a
Author:Eric W. Biederman
AuthorDate:Sat, 14 Sep 2019 07:35:02 -05:00
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 0ff7b2cfbae36ebcd216c6a5ad7f8534eebeaee2
Gitweb:
https://git.kernel.org/tip/0ff7b2cfbae36ebcd216c6a5ad7f8534eebeaee2
Author:Eric W. Biederman
AuthorDate:Sat, 14 Sep 2019 07:33:58 -05:00
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 3fbd7ee285b2bbc6eebd15a3c8786d9776a402a8
Gitweb:
https://git.kernel.org/tip/3fbd7ee285b2bbc6eebd15a3c8786d9776a402a8
Author:Eric W. Biederman
AuthorDate:Sat, 14 Sep 2019 07:33:34 -05:00
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 154abafc68bfb7c2ef2ad5308a3b2de8968c3f61
Gitweb:
https://git.kernel.org/tip/154abafc68bfb7c2ef2ad5308a3b2de8968c3f61
Author:Eric W. Biederman
AuthorDate:Sat, 14 Sep 2019 07:34:30 -05:00
Frederic Weisbecker writes:
> On Sat, Sep 14, 2019 at 07:35:02AM -0500, Eric W. Biederman wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 69015b7c28da..668262806942 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @
Peter Zijlstra writes:
> On Tue, Sep 17, 2019 at 12:38:04PM -0500, Eric W. Biederman wrote:
>> Linus Torvalds writes:
>
>> > Can anybody see anything wrong with the series? Because I'd love to
>> > have it for 5.4,
>>
>> Peter,
>>
>> I
Jann Horn writes:
> On Fri, Sep 20, 2019 at 4:37 PM Andy Lutomirski wrote:
>> It has no effect any more, so remove it. We can revert this if
>> there is some user code that expects to be able to set this sysctl.
>>
>> Signed-off-by: Andy Lutomirski
>> ---
>> drivers/char/random.c | 18
Ingo Molnar writes:
> * Eric W. Biederman wrote:
>
>> Ingo Molnar writes:
>>
>> > - Split it into finer grained steps (3 instead of 2 patches per
>> >movement), for easier review and bisection testing:
>> >
>> > toplevel: Move
Ingo Molnar writes:
> - Split it into finer grained steps (3 instead of 2 patches per
>movement), for easier review and bisection testing:
>
> toplevel: Move ipc/ to kernel/ipc/: move the files
> toplevel: Move ipc/ to kernel/ipc/: adjust the build system
> toplevel: Move
"Michael Kerrisk (man-pages)" writes:
> Hello Christian and all,
>
> Below, I have the rendered version of the current draft of
> the pidfd_send_signal(2) manual page that I have written.
> The page source can be found in a Git branch at:
>
Michal,
Thinking about this I have a hunch about what changed. I think at some
point we changed from 4k to 8k kernel stacks. So I suspect if your
client is seeing a lower threads-max it is because the size of the
kernel data structures increased.
Eric
good reason to stop new threads to be created even when
> below this limit.
>
> Fixes: 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
> Cc: stable
> Signed-off-by: Michal Hocko
Reviewed-by: "Eric W. Biederman"
> ---
> kernel/fork.c | 4 ++--
>
Heinrich Schuchardt writes:
> Did this patch when applied to the customer's kernel solve any problem?
>
> WebSphere MQ is a messaging application. If it hits the current limits
> of threads-max, there is a bug in the software or in the way that it has
> been set up at the customer. Instead of
Michal Hocko writes:
> On Tue 17-09-19 12:26:18, Eric W. Biederman wrote:
>> Michal Hocko writes:
>>
>> > On Tue 17-09-19 17:28:02, Heinrich Schuchardt wrote:
>> >>
>> >> On 9/17/19 12:03 PM, Michal Hocko wrote:
>> >> > Hi,
&
Lennart Poettering writes:
> On Di, 17.09.19 09:23, Linus Torvalds (torva...@linux-foundation.org) wrote:
>
>> On Tue, Sep 17, 2019 at 9:08 AM Lennart Poettering
>> wrote:
>> >
>> > Here's what I'd propose:
>>
>> So I think this is ok, but I have another proposal. Before I post that
>> one,
Linus Torvalds writes:
> On Sat, Sep 14, 2019 at 5:30 AM Eric W. Biederman
> wrote:
>>
>> I have reworked these patches one more time to make it clear that the
>> first 3 patches only fix task_struct so that it experiences a rcu grace
>> period after it leaves
Michal Hocko writes:
> On Tue 17-09-19 17:28:02, Heinrich Schuchardt wrote:
>>
>> On 9/17/19 12:03 PM, Michal Hocko wrote:
>> > Hi,
>> > I have just stumbled over 16db3d3f1170 ("kernel/sysctl.c: threads-max
>> > observe limits") and I am really wondering what is the motivation behind
>> > the
Russell King - ARM Linux admin writes:
> On Fri, Sep 06, 2019 at 04:17:59PM +0100, Russell King - ARM Linux admin
> wrote:
>> On Mon, Sep 02, 2019 at 12:36:56PM -0500, Eric W. Biederman wrote:
>> > Russell King - ARM Linux admin writes:
>> >
>> > >
ebied...@xmission.com (Eric W. Biederman) writes:
> "Paul E. McKenney" writes:
>
>> So this looks good in and of itself, but I still do not see what prevents
>> the unfortunate sequence of events called out in my previous email.
>> On the other hand, if ->r
"Michael Kerrisk (man-pages)" writes:
> Hello Eric,
>
> On 9/11/19 1:06 AM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" writes:
>>
>>> Hello Christian,
>>>
>>>>> All: I plan to add the following text t
"Paul E. McKenney" writes:
> So this looks good in and of itself, but I still do not see what prevents
> the unfortunate sequence of events called out in my previous email.
> On the other hand, if ->rcu and ->rcu_users were not allocated on top
> of each other by a union, I would be happy to
()")
Signed-off-by: "Eric W. Biederman"
---
include/linux/rcuwait.h| 20 +++-
include/linux/sched/task.h | 1 -
kernel/exit.c | 67 --
kernel/sched/fair.c| 2 +-
kernel/sched/membarrier.c | 4 +--
5 files changed,
, despite the
assignment of rq->curr in __schedule() ot using rcu_assign_pointer.
Link:
https://lore.kernel.org/r/20190903200603.gw2...@hirez.programming.kicks-ass.net
Signed-off-by: "Eric W. Biederman"
---
kernel/sched/core.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(
is required.
Inspired-by: Linus Torvalds
Inspired-by: Oleg Nesterov
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched.h | 5 -
include/linux/sched/task.h | 1 +
kernel/exit.c | 7 ++-
kernel/fork.c | 7 +++
4 files changed, 14 insert
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 11 +++
kernel/sched/core.c | 2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9f04741d5c70..7a74ade4e7d6 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -900,
()")
Signed-off-by: "Eric W. Biederman"
---
include/linux/rcuwait.h| 20 +++-
include/linux/sched/task.h | 1 -
kernel/exit.c | 67 --
kernel/sched/fair.c| 2 +-
kernel/sched/membarrier.c | 4 +--
5 files changed,
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 11 +++
kernel/sched/core.c | 2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9f04741d5c70..7a74ade4e7d6 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -900,
is required.
Inspired-by: Linus Torvalds
Inspired-by: Oleg Nesterov
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched.h | 5 -
include/linux/sched/task.h | 1 +
kernel/exit.c | 7 ++-
kernel/fork.c | 7 +++
4 files changed, 14 insert
anity by the caller.
>
> Fixes: 7f192e3cd316 ("fork: add clone3")
> Reported-by: Oleg Nesterov
> Signed-off-by: Eugene Syromiatnikov
Acked-by: "Eric W. Biederman"
> ---
> kernel/fork.c | 12
> 1 file changed, 12 insertions(+)
>
> diff -
"Michael Kerrisk (man-pages)" writes:
> Hello Christian,
>
>>> All: I plan to add the following text to the manual page:
>>>
>>>new_root and put_old may be the same directory. In particular,
>>>the following sequence allows a pivot-root operation without need‐
>>>ing
"Michael Kerrisk (man-pages)" writes:
> Hello Eric,
>
> Thanks for chiming in; I should have thought to CC you at the start. I
> have a question or two, below.
>
> On Mon, 9 Sep 2019 at 12:40, Eric W. Biederman wrote:
>>
>> "Michael Kerris
Peter Zijlstra writes:
> On Thu, Sep 05, 2019 at 03:02:49PM -0500, Eric W. Biederman wrote:
>> Paul, what is the purpose of the barrier in rcu_assign_pointer?
>>
>> My intuition says it is the assignment half of rcu_dereference, and that
>> anything that rcu_deref
"Michael Kerrisk (man-pages)" writes:
> Hello Philipp,
>
> On Tue, 6 Aug 2019 at 10:12, Philipp Wendler wrote:
>>
>> Hello Michael, hello Aleksa,
>>
>> Am 05.08.19 um 14:29 schrieb Michael Kerrisk (man-pages):
>>
>> > On 8/5/19 12:36 PM, Aleksa Sarai wrote:
>> >> On 2019-08-01, Michael Kerrisk
"Paul E. McKenney" writes:
> On Tue, Sep 03, 2019 at 10:06:03PM +0200, Peter Zijlstra wrote:
>> On Tue, Sep 03, 2019 at 12:18:47PM -0700, Linus Torvalds wrote:
>> > Now, if you can point to some particular field where that ordering
>> > makes sense for the particular case of "make it active on
Sasha Levin writes:
> On Tue, Sep 03, 2019 at 11:49:16AM -0500, Eric W. Biederman wrote:
>>Sasha Levin writes:
>>
>>> From: "Eric W. Biederman"
>>>
>>> [ Upstream commit 15773ae938d8d93d982461990bebad6e1d7a1830 ]
>>
>>
Linus Torvalds writes:
> On Tue, Sep 3, 2019 at 9:45 AM Eric W. Biederman
> wrote:
>>
>> So with a big fat comment explaining why it is safe we could potentially
>> use RCU_INIT_POINTER. I currently don't see where the appropriate
>> barriers are s
Sasha Levin writes:
> From: "Eric W. Biederman"
>
> [ Upstream commit 15773ae938d8d93d982461990bebad6e1d7a1830 ]
To the best of my knowledge this is just a clean up, no changes in
behavior are present.
The only reason I can see to backport this is so that later fixes could
Peter Zijlstra writes:
> On Tue, Sep 03, 2019 at 09:41:17AM +0200, Peter Zijlstra wrote:
>> On Mon, Sep 02, 2019 at 11:52:01PM -0500, Eric W. Biederman wrote:
>>
>> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> > index 2b037f195473..8029584073
interval.
Cc: Davidlohr Bueso
Cc: Peter Zijlstra (Intel)
Cc: Oleg Nesterov
Ref: 8f95c90ceb54 ("sched/wait, RCU: Introduce rcuwait machinery")
Ref: 150593bf8693 ("sched/api: Introduce task_rcu_dereference() and
try_get_task_struct()")
Signed-off-by: "Eric W. Biede
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 11 +++
kernel/sched/core.c | 7 ---
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9f04741d5c70..7a74ade4e7d6 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -900,
is required.
Inspired-by: Linus Torvalds
Inspired-by: Oleg Nesterov
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched.h | 5 -
include/linux/sched/task.h | 1 +
kernel/exit.c | 7 ++-
kernel/fork.c | 7 +++
4 files changed, 14 insert
the merge
window opens.
Oleg do you have any issues with this code?
Eric W. Biederman (3):
task: Add a count of task rcu users
task: RCU protect tasks on the runqueue
task: Clean house now that tasks on the runqueue are rcu protected
include/linux/rcuwait.h| 20
Russell King - ARM Linux admin writes:
> On Fri, Aug 30, 2019 at 04:02:48PM -0500, Eric W. Biederman wrote:
>> Russell King - ARM Linux admin writes:
>>
>> > On Fri, Aug 30, 2019 at 02:45:36PM -0500, Eric W. Biederman wrote:
>> >> Russell King - ARM Linux
Oleg Nesterov writes:
> On 08/30, Eric W. Biederman wrote:
>>
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -182,6 +182,24 @@ static void delayed_put_task_struct(struct rcu_head
>> *rhp)
>> put_task_struct(tsk);
>> }
>>
>
Russell King - ARM Linux admin writes:
> On Fri, Aug 30, 2019 at 02:45:36PM -0500, Eric W. Biederman wrote:
>> Russell King - ARM Linux admin writes:
>>
>> > On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
>> >> The function do_alignment ca
Russell King - ARM Linux admin writes:
> On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
>> The function do_alignment can handle misaligned address for user and
>> kernel space. If it is a userspace access, do_alignment may fail on
>> a low-memory situation, because page faults
it is possible
that by the time do_dead_task is called the rcu grace period is up.
Which is the problem the users of task_rcu_dereference are fighting.
They are performing an rcu walk on the set of cups in task_numa_migrate
and in the userspace membarrier system calls.
For a short while we the rcu delay in
ebied...@xmission.com (Eric W. Biederman) writes:
> Michal Suchanek writes:
>
>> 64bit !COMPAT does not build because the llseek syscall is in the
>> tables.
>
> Do I read this right you have a 128 bit offset to llseek on ppc64?
>
> Looking at the signature it
Michal Suchanek writes:
> 64bit !COMPAT does not build because the llseek syscall is in the
> tables.
Do I read this right you have a 128 bit offset to llseek on ppc64?
Looking at the signature it does not appear to make sense to build this
function on any 64bit platform.
Perhaps the proper
of signals somewhat necessary for these kernel threads. Perhaps someday
we can cleanup those interfaces and remove allow_kernel_signal. If not
allow_kernel_signal is pretty trivial and clearly documents what is
going on so I don't think we will mind carrying it.
Eric W. Biederman (1):
signal: Allow
;signal: Remove task parameter from force_sig")
Signed-off-by: "Eric W. Biederman"
---
drivers/block/drbd/drbd_main.c | 2 ++
fs/cifs/connect.c | 2 +-
include/linux/signal.h | 15 ++-
kernel/signal.c| 5 +
4 files changed, 2
Al Viro writes:
> On Fri, Jul 26, 2019 at 07:46:18PM -0500, Eric W. Biederman wrote:
>
>> If someone had bothered to actually look at how I was proposing to clean
>> things up before the new mount api we would already have that. Sigh.
>>
>> You should be able t
y old patch against the pre
new mount api code.
I am running at undependable speed due to the new baby so it is probably
better for someone else to forward port this, but I will attempt it
otherwise.
Eric
From: "Eric W. Biederman"
Date: Wed, 21 Nov 2018 11:17:01 -0600
Subject: [PATCH]
Christian Brauner writes:
> On Thu, Jul 25, 2019 at 07:46:50AM -0500, Eric W. Biederman wrote:
>> Linus Torvalds writes:
>>
>> > On Wed, Jul 24, 2019 at 7:47 AM Christian Brauner
>> > wrote:
>> >>
>> >> The code here uses a struct w
Christian Brauner writes:
> On Thu, Jul 25, 2019 at 01:43:59PM +0200, Oleg Nesterov wrote:
>> Or. We can change wait_consider_task() to not clear ->notask_error if
>> WXXX and the child is PF_WAIT_PID.
>>
>> This way you can "safely" use wait() without WNOHANG, it won't block if
>> all the
Linus Torvalds writes:
> On Wed, Jul 24, 2019 at 7:47 AM Christian Brauner
> wrote:
>>
>> This adds the pidfd_wait() syscall.
>
> I despise this patch.
>
> Why can't this just be a new P_PIDFD flag, and then use
> "waitid(P_PIDFD, pidfd, ...);"
>
> Yes, yes, yes, I realize that "pidfd" is of
Linus Torvalds writes:
> On Wed, Jul 24, 2019 at 7:47 AM Christian Brauner
> wrote:
>>
>> The code here uses a struct waitid_info to catch basic information about
>> process exit including the pid, uid, status, and signal that caused the
>> process to exit. This information is then stuffed
Steve French writes:
> Very easy to see what caused the regression with this global change:
>
> mount (which launches "cifsd" thread to read the socket)
> umount (which kills the "cifsd" thread)
> rmmod (rmmod now fails since "cifsd" thread is still active)
>
> mount launches a thread to read
s_req_poolp, length + cifs_min_rcv);
>>
>> set_freezable();
>> + sigfillset();
>> + sigdelset(, SIGKILL);
>> + sigprocmask(SIG_BLOCK, , );
>> while (server->tcpStatus != CifsExiting) {
>> if (try_to_freeze())
>>
58042fabc5ae7e6a99066a210bc0e
> fs/proc: simplify and clarify get_mm_cmdline() function
>
> Signed-off-by: Alexey Dobriyan
Given that this fixes a regression and a bug.
Acked-by: "Eric W. Biederman"
> ---
>
> Cc lists
>
> fs/proc/base.c | 198
>
.
This set of changes fixes the remaining abusers of force_sig and
carefully rips out the task parameter from force_sig and friends making
this kind of error almost impossible in the future.
Eric W. Biederman (27):
signal/usb: Replace kill_pid_info_as_cred with kill_pid_usb_asyncio
signal
Dmitry Torokhov writes:
> Hi Christian,
>
> On Sun, Apr 29, 2018 at 3:45 AM Christian Brauner
> wrote:
>>
>> commit 07e98962fa77 ("kobject: Send hotplug events in all network
>> namespaces")
>>abhishe...@google.com
>> enabled sending hotplug events into all network namespaces back in 2010.
>>
Arnd Bergmann writes:
> On Fri, Jun 14, 2019 at 4:07 PM David Ahern wrote:
>> On 6/14/19 8:01 AM, Arnd Bergmann wrote:
>> > On Wed, Jun 12, 2019 at 9:41 AM Randy Dunlap wrote:
>> >> On 6/11/19 5:08 PM, Matteo Croce wrote:
>> >
>> > It clearly shouldn't select PROC_SYSCTL, but I think it should
Christian Brauner writes:
> On Thu, Jun 13, 2019 at 04:59:24PM -0500, Eric W. Biederman wrote:
>> Miklos Szeredi writes:
>>
>> > On Thu, Jun 13, 2019 at 8:35 PM Eric W. Biederman
>> > wrote:
>> >>
>> >> Christian Brauner writes:
>
Miklos Szeredi writes:
> On Thu, Jun 13, 2019 at 8:35 PM Eric W. Biederman
> wrote:
>>
>> Christian Brauner writes:
>>
>> > On Wed, Jun 12, 2019 at 06:00:39PM -1000, Linus Torvalds wrote:
>> >> On Wed, Jun 12, 2019 at 12:54 PM Christian Brau
Christian Brauner writes:
> On Wed, Jun 12, 2019 at 06:00:39PM -1000, Linus Torvalds wrote:
>> On Wed, Jun 12, 2019 at 12:54 PM Christian Brauner
>> wrote:
>> >
>> > The commit changes the internal logic to lock mounts when propagating
>> > mounts (user+)mount namespaces and - I believe -
1041,6 @@ static inline bool bad_area_access_from_pkeys(unsigned
>> long error_code,
>> force_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb);
>> return;
>> }
>> -#endif
>> force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *)
David Laight writes:
> From: Oleg Nesterov
>> Sent: 12 June 2019 14:46
>> On 06/11, David Laight wrote:
>> >
>> > If I have an application that has a loop with a pselect call that
>> > enables SIGINT (without a handler) and, for whatever reason,
>> > one of the fd is always 'ready' then I'd
501 - 600 of 10702 matches
Mail list logo
