On 4/23/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:
Hi Paul,
In [patch 3/7] Containers (V8): Add generic multi-subsystem API to
containers, you have forcefully enabled interrupt in
container_init_subsys() with spin_unlock_irq() which breaks on PPC64.
> +static void container_init_su
On 4/23/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:
>
> config CONTAINERS
> - bool "Container support"
> - help
> - This option will let you create and manage process containers,
> - which can be used to aggregate multiple processes, e.g. for
> - the purposes
Karel Zak <[EMAIL PROTECTED]> writes:
> On Fri, Apr 20, 2007 at 12:25:32PM +0200, Miklos Szeredi wrote:
>> The following extra security measures are taken for unprivileged
>> mounts:
>>
>> - usermounts are limited by a sysctl tunable
>> - force "nosuid,nodev" mount options on the created mount
On Fri, Apr 20, 2007 at 12:25:32PM +0200, Miklos Szeredi wrote:
> The following extra security measures are taken for unprivileged
> mounts:
>
> - usermounts are limited by a sysctl tunable
> - force "nosuid,nodev" mount options on the created mount
The original userspace "user=" solution also
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Sure, I'll grep for cancel_delayed_work(). But unless I missed something,
> > this change should be completely transparent for all users. Otherwise, it
> > is buggy.
>
> I guess you will have to make sure that cance
On Tue, Apr 24 2007, Jens Axboe wrote:
> On Tue, Apr 24 2007, Jens Axboe wrote:
> > - if (key != CFQ_KEY_ASYNC)
> > + if (!is_sync)
> > cfq_mark_cfqq_idle_window(cfqq);
> > + else
> > + cfq_mark_cfqq_sync(cfqq);
>
> Woops, should
On Tue, Apr 24 2007, Jens Axboe wrote:
> - if (key != CFQ_KEY_ASYNC)
> + if (!is_sync)
> cfq_mark_cfqq_idle_window(cfqq);
> + else
> + cfq_mark_cfqq_sync(cfqq);
Woops, should be
if (is_sync) {
cf
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Sure, I'll grep for cancel_delayed_work(). But unless I missed something,
> this change should be completely transparent for all users. Otherwise, it
> is buggy.
I guess you will have to make sure that cancel_delayed_work() is always
followed by a flush
> - it is a rb-tree
Vasily, this is still not against the CFQ branch, I get tons of rejects:
[EMAIL PROTECTED]:/src/linux-2.6-block $ patch -p1 --dry-run < ~/foo
[...]
10 out of 27 hunks FAILED -- saving rejects to file
block/cfq-iosched.c.rej
If you don't want to use the git tree, t
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Great. I'll send the s/del_timer_sync/del_timer/ patch.
>
> I didn't say I necessarily agreed that this was a good idea. I just meant
> that
> I agree that it will waste CPU. You must still audit all uses of
> ca
atch -p1 --dry-run < ~/foo
> [...]
> 10 out of 27 hunks FAILED -- saving rejects to file
> block/cfq-iosched.c.rej
>
> If you don't want to use the git tree, then just grab
>
> http://brick.kernel.dk/snaps/cfq-update-20070424
>
> and apply it to 2.6.21-rc7-gi
On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> This patch modifies the startup of eehd to use kthread_run
> not a combination of kernel_thread and daemonize. Making
> the code slightly simpler and more maintainable.
For the pa
On Tue, Apr 24, 2007 at 11:38:53AM +1000, Benjamin Herrenschmidt wrote:
> > The only reason for using threads here is to get the error recovery
> > out of an interrupt context (where errors may be detected), and then,
> > an hour later, decrement a counter (which is how we limit these to
> > 6 per
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > > The current code uses del_timer_sync(). It will also return 0. However,
> > > it will spin waiting for timer->function() to complete. So we are just
> > > wasting CPU.
> >
> > That's my objection to using cancel_delayed_work() as it stands, although
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > The current code uses del_timer_sync(). It will also return 0. However, it
> > will spin waiting for timer->function() to complete. So we are just wasting
> > CPU.
>
> That's my objection to using cancel_delayed_wor
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Let's look at (2). cancel_delayed_work() (on top of del_timer()) returns 0,
> and this is correct, we failed to cancel the timer, and we don't know whether
> work->func() finished, or not.
Yes.
> The current code uses del_timer_sync(). It will also retu
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > > > We only care when del_timer() returns true. In that case, if the timer
> > > > function still runs (possible for single-threaded wqs), it has already
> > > > passed __queue_work().
> > >
> > > Why do you assume
From: Vasily Tarasov <[EMAIL PROTECTED]>
cfq hash is no more necessary. We always can get cfqq from io context.
cfq_get_io_context_noalloc() function is introduced, because we don't want to
allocate cic on merging and checking may_queue.
In order to identify sync queue we've used hash key = CFQ_K
Pavel Emelianov wrote:
Implement try_to_free_pages_in_container() to free the
pages in container that has run out of memory.
The scan_control->isolate_pages() function isolates the
container pages only.
Pavel,
I've just started playing around with these patches, I preferred
the approach of v
On Tue, 24 Apr 2007 15:00:42 +1000,
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> Like anything else, modules should have separated the entrypoints for
>
> - Initiating a removal request
> - Releasing the module
>
> The former is use did "rmmod", can unregister things from subsystems,
>
Pavel Emelianov wrote:
Balbir Singh wrote:
Pavel Emelianov wrote:
Implement try_to_free_pages_in_container() to free the
pages in container that has run out of memory.
The scan_control->isolate_pages() function isolates the
container pages only.
Pavel,
I've just started playing around with
On Sun, Apr 22, 2007 at 01:31:55PM +0100, Christoph Hellwig wrote:
> On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
> > From: Eric W. Biederman <[EMAIL PROTECTED]>
> >
> > This patch modifies the startup of eehd to use kthread_run
> > not a combination of kernel_thread and daem
On Sun, 22 Apr 2007, Christoph Hellwig wrote:
> On Thu, Apr 19, 2007 at 12:55:29AM -0600, Eric W. Biederman wrote:
> > From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
> >
> > kthread_run replaces the kernel_thread and daemonize calls
> > during thread startup.
> >
> > Calls to signal_pen
Jes Sorensen wrote:
>
> Russ/Dean/Robin - could one of you provide some feedback to this one
> please.
Dean's on vacation for a couple days and will test it when he gets back.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc [EMAIL PROTECTED]
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > > We only care when del_timer() returns true. In that case, if the timer
> > > function still runs (possible for single-threaded wqs), it has already
> > > passed __queue_work().
> >
> > Why do you assume that?
Sorry, I should have been more clear. I
On Tue, Apr 24, 2007 at 03:08:57PM +0200, Jan Engelhardt wrote:
> >I don't think having to parallel APIs is a good idea, people will
> >get utterly confused which one to use. Better always grab a reference
> >in kthread_create and drop it in kthread_stop. For normal thread
> >no change in behavio
On Tue, Apr 24 2007, Vasily Tarasov wrote:
> From: Vasily Tarasov <[EMAIL PROTECTED]>
>
> cfq hash is no more necessary. We always can get cfqq from io context.
> cfq_get_io_context_noalloc() function is introduced, because we don't want to
> allocate cic on merging and checking may_queue.
> In o
On Apr 23 2007 12:25, Christoph Hellwig wrote:
>On Sun, Apr 22, 2007 at 09:12:55PM -0600, Eric W. Biederman wrote:
>>
>> This patch implements the kthread helper functions kthread_start
>> and kthread_end which make it simple to support a kernel thread
>> that may decided to exit on it's own befo
>> From: Vasily Tarasov <[EMAIL PROTECTED]>
>>
>> cfq hash is no more necessary. We always can get cfqq from io context.
>> cfq_get_io_context_noalloc() function is introduced, because we don't want
>> to
>> allocate cic on merging and checking may_queue.
>> In order to identify sync queue we've
From: Vasily Tarasov <[EMAIL PROTECTED]>
cfq hash is no more necessary. We always can get cfqq from io context.
cfq_get_io_context_noalloc() function is introduced, because we don't want to
allocate cic on merging and checking may_queue.
In order to identify sync queue we've used hash key = CFQ_K
Balbir Singh wrote:
> Pavel Emelianov wrote:
>> Balbir Singh wrote:
>>> Pavel Emelianov wrote:
Implement try_to_free_pages_in_container() to free the
pages in container that has run out of memory.
The scan_control->isolate_pages() function isolates the
container pages only.
On Tue, Apr 24, 2007 at 01:10:23PM +0400, Alexey Dobriyan wrote:
> ยน But I see whole can of other bugs! I think they were already lurking
> but weren't easily reproducable without hitting double-free first.
> FWIW, it's
> BUG_ON(!list_empty(&tsk->ptracees));
mmm, pretty easily reproduced
Balbir Singh wrote:
> Pavel Emelianov wrote:
>> Implement try_to_free_pages_in_container() to free the
>> pages in container that has run out of memory.
>>
>> The scan_control->isolate_pages() function isolates the
>> container pages only.
>>
>
> Pavel,
>
> I've just started playing around with t
The following patch fixes double free manifesting itself as crash in
__rcu_process_callbasks():
http://marc.info/?l=linux-kernel&m=117518764517017&w=2
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229112
The problem is with check_dead_utrace() conditionally scheduling
"struct utrace" for fr
On Tue, Apr 24, 2007 at 03:55:06PM +1000, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > The first question is obviously, is this really something we want?
> > spawning kernel thread on demand without reaping them properly seems
> > quite dangerous.
>
> What specifically has to be done t
35 matches
Mail list logo
