quired for a multicast bind.
>
> Signed-off-by: Kees Cook
> Cc: Evgeniy Polyakov
> Cc: Matt Helsley
> Cc: sta...@vger.kernel.org
> ---
> drivers/connector/cn_proc.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/connector/cn_proc.c b/d
On Thu, Oct 25, 2012 at 12:23:24PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Pat,
>
>
> >> I suppose that I have a concern that goes in the other direction. Is
> >> there not some other solution possible that doesn't require the use of
> >> EPOLLONESHOT? It seems overly restrictive to requir
On Thu, Oct 18, 2012 at 05:01:53PM -0700, Tejun Heo wrote:
> I probably have chosen the wrong word. I mean that it's a hierarchy
> management feature implemented at the wrong layer. If we want to
> provide cgroup migration locking, it should be implemented at the
> cgroup core layer as a contro
On Thu, Oct 18, 2012 at 03:35:17PM -0700, Tejun Heo wrote:
> Hello, Matt.
>
> On Thu, Oct 18, 2012 at 03:21:55PM -0700, Matt Helsley wrote:
> > > Hmmm? Nothing prevents kthreads from being moved around. We only
> > > recently added the restriction to prevent migration
On Thu, Oct 18, 2012 at 02:14:34PM -0700, Tejun Heo wrote:
> Hello, Matt.
>
> On Wed, Oct 17, 2012 at 12:16:06PM -0700, Matt Helsley wrote:
> > > * Unfreezable kernel tasks don't prevent a cgroup from transitioning
> > > into FROZEN from FREEZING. There&#
userspace code may
have relied on this feature.
Will this work for the CRIU folks? With this patch one of the tasks being
checkpointed could become thawed simply by some other process writing
the pid into a different cgroup's tasks file. In contrast, with the
current code they'd hav
Hi Andrew,
nommu configurations will not compile because the "mm" variable does not
exist. Replace usage of the mm variable and the empty vma->vm_mm field
with correct mm pointers.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
Cc: Mike Frysinger <[EMAIL PROTECTED]>
---
on is best?
Cheers,
-Matt Helsley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sat, 2008-02-16 at 07:12 -0500, Mike Frysinger wrote:
> On Feb 6, 2008 8:44 PM, Matt Helsley <[EMAIL PROTECTED]> wrote:
> > The kernel implements readlink of /proc/pid/exe by getting the file from the
> > first executable VMA. Then the path to the file is reconstructed
er of
VM_EXECUTABLE VMAs and drop the new reference when the last one is unmapped.
This avoids pinning the mounted filesystem.
Andrew, these are the updates I promised. Please consider this patch for
inclusion in -mm.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL
x27;t
expect the "quirk" and breaks because of it. Frankly,
given /proc/pid/exe's output in the non-stacking case, I can't see how
its output in the stacking case we're discussing could be considered
anything but buggy.
Cheers,
-Matt Helsley
--
To unsubscribe from th
p;m=120141116911711
>
> So this (the old vma could be removed before we create the new mapping)
> means that the patch above has another problem: if we are remapping the
> whole VM_EXECUTABLE vma, removed_exe_file_vma() can clear ->exe_file
> while it shouldn't (Matt Helsley cc
p;m=120141116911711
>
> So this (the old vma could be removed before we create the new mapping)
> means that the patch above has another problem: if we are remapping the
> whole VM_EXECUTABLE vma, removed_exe_file_vma() can clear ->exe_file
> while it shouldn't (Matt Helsley cc
mpilation when CONFIG_PROC_FS is not defined
b) struct file leak when CONFIG_PROC_FS is not defined
2 - reuse mmap semaphore
3 - move the mm initialization bits in the exec path to close the window
where userspace could see a "NULL" exe_file.
I will post each after it passes te
On Tue, 2008-01-29 at 14:36 +0300, Oleg Nesterov wrote:
> s/mm-commits/lkml/
>
> On 01/28, Matt Helsley wrote:
> >
> > On Sun, 2008-01-27 at 19:25 +0300, Oleg Nesterov wrote:
> > >
> > > Why? Linux doesn't allow sys_mmap(MAP_EXECUTABLE), so any VM_EXE
On Sat, 2008-01-26 at 22:03 -0800, Andrew Morton wrote:
> > On Wed, 23 Jan 2008 10:29:37 -0800 Matt Helsley <[EMAIL PROTECTED]> wrote:
> >
> > Andrew, please consider this patch for inclusion in -mm.
> >
> > ...
> >
>
> Can't say that we
s not
> generally possible.
>
> Jan
Odd. Last I checked I thought I saw a bunch of calls in do_exit() that
could sleep. Only in certain sections and at the end did it appear to
prevent sleeping.
Sorry for the late reply.
Cheers,
-Matt Helsley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the new reference on
exit or when the last such VMA is unmapped. This avoids pinning the filesystem.
A minor added benefit of this approach is we no longer need separate code to
offer this symlink on mmu-less systems.
Andrew, please consider this patch for inclusion in -mm.
Signed-off-by: Matt
On Tue, 2008-01-15 at 10:06 +0100, Nadia Derbey wrote:
> I'm realizing that I wrote Andrew's address wrong. So please if ever
> you're answering in this thread correct his address by hand.
> Sorry for that!
> Now if you find it more convenient that I start a new thread with the
> right address,
others,
> > >> so we already had a few a few attempts at similar things. The first one
> > >> is from SGI and called PAGG (http://oss.sgi.com/projects/pagg/) and also
> > >> includes allocating per-task data for it's users. Then also from SGI
> &g
(http://oss.sgi.com/projects/pagg/) and also
> includes allocating per-task data for it's users. Then also from SGI
> there has been a simplified version called pnotify that's also available
> from the website above.
>
> Later Matt Helsley had something called "Task Wa
Agreed. I believe Nadia's "min(IPCMNI, max(MSGMNI,...))" line should
take care of this since IPCMNI (32767) > MSGMNI and MSGMNI (16) is what
the kernel was previously giving.
> It's a bit of a concern that a change like this can cause an application to
> work OK on machine
On Thu, 2007-11-01 at 12:25 -0700, Andrew Morton wrote:
> On Wed, 31 Oct 2007 20:35:09 -0700
> Matt Helsley <[EMAIL PROTECTED]> wrote:
>
> > +++ linux-2.6.23/include/linux/sched.h
> > @@ -430,10 +430,13 @@ struct mm_struct {
> > struct complet
not the restart exectuable.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
fs/proc/base.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
Index: linux-2.6.23/fs/proc/
tart loader is designed to map the executable in rather than
use the exec system call.
If there are no objections to the direction of the patches I plan on making
the series acceptable for eventual inclusion.
Cheers,
-Matt Helsley
-
To unsubscribe from this list: send the line "unsubscri
g to the file. To maintain them I'll
probably need to increment the count in split_vma() and decrement the count in
vma_merge().
Alternative ideas on how to fix this would certainly be very nice to
hear since I've not been able to think of anything better and I'm not e
/pid/exe ops.
Unfortunately we can't entirely avoid using the mmap semaphore because we need
to drop the exe file reference when the VMA mapping the executable file does --
otherwise we'd pin mounted filesystems until all applications executed from
them exitted.
Signed-off-by: Matt Helsl
On Fri, 2007-07-13 at 03:07 +0100, Al Viro wrote:
> On Thu, Jul 12, 2007 at 07:00:12PM -0700, Matt Helsley wrote:
> > This patch avoids holding the mmap semaphore while walking VMAs in response
> > to
> > programs which read or follow the /proc//exe symlink. This also
>
On Thu, 2007-07-12 at 19:21 -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2007 19:00:12 -0700 Matt Helsley <[EMAIL PROTECTED]> wrote:
>
> > This patch avoids holding the mmap semaphore while walking VMAs in response
> > to
> > programs which read or follow the
task
struct, and increased code in fork, exec, and exit paths.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
Changelog:
Hold task_lock() while using task->exe_file. With this change I haven't
been able to reproduce Chris Wright's Oops report:
h
task
struct, and increased code in fork, exec, and exit paths.
Changes:
Clear exe_file field in exit path
Use task_lock() to protect exe_file between write and read paths
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
fs/exec.c |7 +--
fs/proc/base.c
On Fri, 2007-06-01 at 17:31 -0500, Serge E. Hallyn wrote:
> Quoting Matt Helsley ([EMAIL PROTECTED]):
> > On Wed, 2007-05-30 at 13:09 -0500, Serge E. Hallyn wrote:
> > > Quoting Matt Helsley ([EMAIL PROTECTED]):
> > > > This patch avoids holding the mmap s
48 8b 40 30 48 85 c0
> 74
> [ 110.363381] RIP [] d_path+0x1a/0x117
> [ 110.365386] RSP
> [ 110.366720] CR2: 0088
Hmm, at first blush this does appear to be related to the bug Serge
pointed out. I'm not certain though, so I'll see if I can spot/produce
an
On Wed, 2007-05-30 at 13:09 -0500, Serge E. Hallyn wrote:
> Quoting Matt Helsley ([EMAIL PROTECTED]):
> > This patch avoids holding the mmap semaphore while walking VMAs in response
> > to
> > programs which read or follow the /proc//exe symlink. This also
> > all
and increased code in
fork, exec, and exit paths.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
Compiled and passed simple tests for regressions when patched against a 2.6.20
and 2.6.22-rc2-mm1 kernel.
fs/exec.c |5 +++--
fs/proc/base.c| 20 ++
d Andrew Morton about this time last year. That led to my suggestion
of "Resource Groups". Unless they've changed their minds...
> Do any of those sound remotely close? If not, your turn :)
I'll butt in here: task groups? task sets? confuselets? ;)
Cheers,
-Matt Helsl
erience instruction cache misses -- whether the functions
are inlined, adjacent, or not -- since the fork happens relatively
infrequently and other instructions are likely to push fork-related
instructions out.
Cheers,
-Matt Helsley
-
To unsubscribe from this list: send the line "un
On Mon, 2006-12-18 at 13:44 +0800, Zhang, Yanmin wrote:
> On Thu, 2006-12-14 at 16:07 -0800, Matt Helsley wrote:
> > plain text document attachment (task-watchers-v2)
> > Associate function calls with significant events in a task's lifetime much
> > like
> > we ha
On Fri, 2006-12-15 at 09:34 +0100, Christoph Hellwig wrote:
> On Thu, Dec 14, 2006 at 04:07:55PM -0800, Matt Helsley wrote:
> > Associate function calls with significant events in a task's lifetime much
> > like
> > we handle kernel and module init/exit functions
On Fri, 2006-12-15 at 09:34 +0100, Christoph Hellwig wrote:
> On Thu, Dec 14, 2006 at 04:07:55PM -0800, Matt Helsley wrote:
> > Associate function calls with significant events in a task's lifetime much
> > like
> > we handle kernel and module init/exit functions
Make the semaphore undo code use a task watcher instead of hooking into
copy_process() and do_exit() directly.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
include/linux/sem.h | 17 -
ipc/sem.c | 12
kernel/exit.c |2 --
kernel/
Register a task watcher for cpusets instead of hooking into
copy_process() and do_exit() directly.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
Cc: Paul Jackson <[EMAIL PROTECTED]>
---
include/linux/cpuset.h |4
kernel/cpuset.c| 11 +--
kernel/exit.c
Register a NUMA mempolicy task watcher instead of hooking into
copy_process() and do_exit() directly.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
kernel/exit.c |4
kernel/fork.c | 15 +--
mm/mempolicy.c | 25 +
3 files chang
Register a task watcher for lockdep instead of hooking into copy_process().
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
kernel/fork.c|5 -
kernel/lockdep.c | 11 +++
2 files changed, 11 insertions(+), 5 deletions(-)
Index: linux-2.6.19/kernel/
Make the Process events connector use task watchers instead of hooking the
paths it's interested in.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
drivers/connector/cn_proc.c | 51 +++-
fs/exec.c |1
include/linu
Register an irq-flag-tracing task watcher instead of hooking into
copy_process().
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
kernel/fork.c | 19 ---
kernel/irq/handle.c | 24
2 files changed, 24 insertions(+), 19 deletions(-)
ffers no measurable performance impact.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc: Steve Grubb <[EMAIL PROTECTED]>
Cc: linux-audit@redhat.com
---
include/linux/audit.h |4
kernel/auditsc.c |9 ++---
kernel/exit.c
Prefetch the entire array of function pointers.
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
---
kernel/task_watchers.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.19/kernel/task_watchers.c
===
--- linux-
Make the keyring code use a task watcher to initialize and free per-task data.
NOTE:
We can't make copy_thread_group_keys() in copy_signal() a task watcher because
it needs the task's signal field (struct signal_struct).
Signed-off-by: Matt Helsley <[EMAIL PROTECTED]>
Cc: David
(+2.6%)
So the patch series now actually improves performance a little.
All the numbers from the tests are available if anyone wishes to analyze them
independently.
Please consider for inclusion in -mm.
Cheers,
-Matt Helsley
-
To unsubscribe from this list: send the line "unsubscribe lin
s interface for measuring fork and exit rates
which can be used to calculate the overhead of the task watcher infrastructure.
Subsequent patches will make use of task watchers to simplify fork, exit,
and many of the system calls that set [er][ug]ids.
Signed-off-by: Matt Helsley <[EMAIL PROT
On Mon, 2006-12-11 at 17:50 -0800, David Miller wrote:
> From: Pete Zaitcev <[EMAIL PROTECTED]>
> Date: Mon, 11 Dec 2006 17:29:07 -0800
>
> > On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley <[EMAIL PROTECTED]> wrote:
> >
> > > I'm shocked
d access errors
> per process.
>
> Here, we just adjust how the variables are declared and use memcopy to
> avoid the error messages.
>
> Signed-off-by: Erik Jacobson <[EMAIL PROTECTED]>
Acked-by: Matt Helsley <[EMAIL
looks like its loading and
storying 8 bytes at a time for the memcpy().
> It seems rather strange that memcpy gets optimized this way. I could
> not have foreseen it. Still, it was worth a try, even if putting 32
> extra bytes on stack and running memcpy on them does not seem too
> one
particular connector (Evgeniy
Polyakov wrote the generic connector code). In the past I've given my
patches to Andrew Morton and requested inclusion in -mm -- that may be
the best route (Andrew?). I'd be happy to Ack a patch implementing
Pete's suggestion.
Cheers,
-Matt Helsle
201 - 255 of 255 matches
Mail list logo
