public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH container] fix: cloning a locked container creates an empty config
Date: Wed, 15 Jun 2022 10:11:56 +0200	[thread overview]
Message-ID: <1655280267.gyaahrizk0.astroid@nora.none> (raw)
In-Reply-To: <e888c58f-415f-9a7c-2150-df54d0e98768@proxmox.com>

On June 14, 2022 3:43 pm, Daniel Tschlatscher wrote:
> 
> 
> On 6/14/22 14:51, Fabian Grünbichler wrote:
>> On June 14, 2022 2:22 pm, Daniel Tschlatscher wrote:
>>> When an attempt was made to clone a locked container the API would
>>> correctly present the error 'CT is locked (disk)' but create the
>>> config files for the new container anyway and then abort.
>>>
>>> The fix is to simply check whether the CT config is locked before
>>> creating the configs for the new container.
>> 
>> is there a reason for not just moving it to the start of the eval block 
>> to avoid the same problem being re-introduced in the future? any error 
>> occuring inside the eval block will then trigger a cleanup..
>> 
> 
> When an error occurs and the cleanup is triggered, the cleanup tries to
> release the lock again.
> 
> Moving the set_lock function into the eval block would create a problem
> here:
> If the lock was created by another process (and if it is a 'disk' lock)
> set_lock would emit an error and the lock would be incorrectly released
> by this process, which did not originally acquire it.

my suggestion was not to move it *into* the eval block, but next to the 
*start* of the eval block, like so:

	my $newconf = {};
	my $mountpoints = {};
	my $fullclone = {};
	my $vollist = [];
	my $running;

	my $src_conf = PVE::LXC::Config->set_lock($vmid, 'disk');

	$running = PVE::LXC::check_running($vmid) || 0;

	my $full = extract_param($param, 'full');
	if (!defined($full)) {
	    $full = !PVE::LXC::Config->is_template($src_conf);
	}

	my $lock_and_reload = sub {
	    my ($vmid, $code) = @_;
	    return PVE::LXC::Config->lock_config($vmid, sub {
		my $conf = PVE::LXC::Config->load_config($vmid);
		die "Lost 'create' config lock, aborting.\n"
		    if !PVE::LXC::Config->has_lock($conf, 'create');
		return $code->($conf);
	    });
	};

	PVE::LXC::Config->create_and_lock_config($newid, 0);
	PVE::Firewall::clone_vmfw_conf($vmid, $newid);

  # error handling for this block will cleanup configs
	eval {
	    die "parameter 'storage' not allowed for linked clones\n"
		if defined($storage) && !$full;


to reduce the chances of re-introducing the bug by adding potentially 
failing calls between create_and_lock_config and the eval block. and now 
that I took a second look I realized that clone_vm_fw_conf is exactly 
such a call, and should therefore be moved into the eval ;)

> 
>>>
>>> Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
>>> ---
>>>  src/PVE/API2/LXC.pm | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
>>> index 64724cb..e1b4cd3 100644
>>> --- a/src/PVE/API2/LXC.pm
>>> +++ b/src/PVE/API2/LXC.pm
>>> @@ -1461,9 +1461,6 @@ __PACKAGE__->register_method({
>>>  	my $vollist = [];
>>>  	my $running;
>>>  
>>> -	PVE::LXC::Config->create_and_lock_config($newid, 0);
>>> -	PVE::Firewall::clone_vmfw_conf($vmid, $newid);
>>> -
>>>  	my $lock_and_reload = sub {
>>>  	    my ($vmid, $code) = @_;
>>>  	    return PVE::LXC::Config->lock_config($vmid, sub {
>>> @@ -1477,6 +1474,9 @@ __PACKAGE__->register_method({
>>>  
>>>  	my $src_conf = PVE::LXC::Config->set_lock($vmid, 'disk');
>>>  
>>> +	PVE::LXC::Config->create_and_lock_config($newid, 0);
>>> +	PVE::Firewall::clone_vmfw_conf($vmid, $newid);
>>> +
>>>  	$running = PVE::LXC::check_running($vmid) || 0;
>>>  
>>>  	my $full = extract_param($param, 'full');
>>> -- 
>>> 2.30.2
>>>
>>>
>>>
>>> _______________________________________________
>>> pve-devel mailing list
>>> pve-devel@lists.proxmox.com
>>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>>
>>>
>>>
>> 
>> 
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> 
>> 
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 




      reply	other threads:[~2022-06-15  8:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14 12:22 Daniel Tschlatscher
2022-06-14 12:51 ` Fabian Grünbichler
2022-06-14 13:43   ` Daniel Tschlatscher
2022-06-15  8:11     ` Fabian Grünbichler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1655280267.gyaahrizk0.astroid@nora.none \
    --to=f.gruenbichler@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal