Prev: oom: give current access to memory reserves if it has been killed
Next: patch iwlwifi-silence-tfds_in_queue-message.patch added to 2.6.32-stable tree
From: David Rientjes on 1 Apr 2010 04:40
On Thu, 1 Apr 2010, Oleg Nesterov wrote:

> > That doesn't work for depraceted_mode (sic), you'd need to test for
> > OOM_ADJUST_MIN and OOM_ADJUST_MAX in that case.
>
> Yes, probably "if (depraceted_mode)" should do more checks, I didn't try
> to verify that MIN/MAX are correctly converted. I showed this code to explain
> what I mean.
>

Ok, please cc me on the patch, it will be good to get rid of the duplicate
code and remove oom_adj from struct signal_struct.

> > There have been efforts to reuse as much of this code as possible for
> > other sysctl handlers as well, you might be better off looking for
>
> David, sorry ;) Right now I'd better try to stop the overloading of
> ->siglock. And, I'd like to shrink struct_signal if possible, but this
> is minor.
>

Do we need ->siglock? Why can't we just do

struct sighand_struct *sighand;
struct signal_struct *sig;

rcu_read_lock();
sighand = rcu_dereference(task->sighand);
if (!sighand) {
rcu_read_unlock();
return;
}
sig = task->signal;

... load/store to sig ...

rcu_read_unlock();

instead?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Oleg Nesterov on 1 Apr 2010 13:10
On 04/01, David Rientjes wrote:
>
> On Thu, 1 Apr 2010, Oleg Nesterov wrote:
>
> > > That doesn't work for depraceted_mode (sic), you'd need to test for
> > > OOM_ADJUST_MIN and OOM_ADJUST_MAX in that case.
> >
> > Yes, probably "if (depraceted_mode)" should do more checks, I didn't try
> > to verify that MIN/MAX are correctly converted. I showed this code to explain
> > what I mean.
> >
>
> Ok, please cc me on the patch, it will be good to get rid of the duplicate
> code and remove oom_adj from struct signal_struct.

OK, great, will do tomorrow.

> Do we need ->siglock? Why can't we just do
>
> struct sighand_struct *sighand;
> struct signal_struct *sig;
>
> rcu_read_lock();
> sighand = rcu_dereference(task->sighand);
> if (!sighand) {
> rcu_read_unlock();
> return;
> }
> sig = task->signal;
>
> ... load/store to sig ...
>
> rcu_read_unlock();

No.

Before signals-make-task_struct-signal-immutable-refcountable.patch (actually,
series of patches), this can't work. ->signal is not protected by rcu, and
->sighand != NULL doesn't mean ->signal != NULL.

(yes, thread_group_cputime() is wrong too, but currently it is never called
lockless).

After signals-make-task_struct-signal-immutable-refcountable.patch, we do not
need any checks at all, it is always safe to use ->signal.


But. Unless we kill signal->oom_adj, we have another reason for ->siglock,
we can't update both oom_adj and oom_score_adj atomically, and if we race
with another thread they can be inconsistent wrt each other. Yes, oom_adj
is not actually used, except we report it back to user-space, but still.

So, I am going to send 2 patches. The first one factors out the code
in base.c and kills signal->oom_adj, the next one removes ->siglock.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Rientjes on 1 Apr 2010 15:10
On Thu, 1 Apr 2010, Oleg Nesterov wrote:

> But. Unless we kill signal->oom_adj, we have another reason for ->siglock,
> we can't update both oom_adj and oom_score_adj atomically, and if we race
> with another thread they can be inconsistent wrt each other. Yes, oom_adj
> is not actually used, except we report it back to user-space, but still.
>
> So, I am going to send 2 patches. The first one factors out the code
> in base.c and kills signal->oom_adj, the next one removes ->siglock.
>

Great, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: oom: give current access to memory reserves if it has been killed
Next: patch iwlwifi-silence-tfds_in_queue-message.patch added to 2.6.32-stable tree