linux-kernel - Re: [ckrm-tech] [PATCH 4/13] BC: context handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45655D3E.5020702@openvz.org>
Date:	Thu, 23 Nov 2006 11:35:10 +0300
From:	Pavel Emelianov <xemul@...nvz.org>
To:	Paul Menage <menage@...gle.com>
CC:	Kirill Korotaev <dev@...ru>, Andrew Morton <akpm@...l.org>,
	ckrm-tech@...ts.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	matthltc@...ibm.com, hch@...radead.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>, oleg@...sign.ru,
	devel@...nvz.org, xemul@...nvz.org
Subject: Re: [ckrm-tech] [PATCH 4/13] BC: context handling

Paul Menage wrote:
> On 11/9/06, Kirill Korotaev <dev@...ru> wrote:
>> +
>> +int bc_task_move(int pid, struct beancounter *bc, int whole)
>> +{
> 
> ...
> 
>> +
>> +       down_write(&mm->mmap_sem);
>> +       err = stop_machine_run(do_set_bcid, &data, NR_CPUS);
>> +       up_write(&mm->mmap_sem);
> 
> Isn't this a little heavyweight for moving a task into/between
> beancounters?

It's a main reason we were against moving arbitrary task.

We need to track the situation when we change beancounter on
task that is currently handles an interrupt and thus set a
temporary BC as exec one. I see no other way that keeps pair
set_exec_bc()/get_exec_bc() lock-less.

The problem is even larger than I've described. set_exec_bc()
is used widely in OpenVZ beancounters to set temporary context
e.g. for skb handling. Thus we need some safe way to "catch"
the task in a "safe" place. In OpenVZ we solve this by moving
only current into beancounter. In this patch set we have to
move arbitrary task and thus - such complication.

I repeat - we can do this w/o stop_machine, but this would
require locking in set_exec_bc()/get_exec_bc() but it's too
bad. Moving tasks happens rarely but setting context is a
very common operation (e.g. in each interrupt).

We can do the following:

  if (tsk == current)
      /* fast way */
      tsk->exec_bc = bc;
  else
      /* slow way */
      stop_machine_run(...);

What do you think?

> Paul
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/