Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: liu.yun@linux.dev, kirill.shutemov@linux.intel.com
Cc: x86@kernel.org, linux-coco@lists.linux.dev,
	Jackie Liu <liuyun01@kylinos.cn>
Subject: Re: [PATCH] virt/tdx: Enhance tdx-guest driver with improved memory management
Date: Sun, 9 Mar 2025 16:55:53 -0700	[thread overview]
Message-ID: <62586df1-fa54-44ef-bb74-3557ffa194fc@intel.com> (raw)
In-Reply-To: <20250309140426.281868-1-liu.yun@linux.dev>

On 3/9/25 07:04, liu.yun@linux.dev wrote:
> From: Jackie Liu <liuyun01@kylinos.cn>
> 
> This patch refines the tdx-guest driver by introducing better memory
> management and error handling practices. The use of the `__free` attribute
> ensures that allocated memory for `reportdata` and `tdreport` is
> automatically freed, reducing the risk of memory leaks. Additionally,
> the manual mutex lock/unlock has been replaced with `scoped_cond_guard`
> to ensure proper mutex handling and simplify the code.
> 
> Error handling has been streamlined by returning directly on failure,
> eliminating unnecessary `goto` statements. These changes not only
> enhance the robustness of the driver but also improve its readability
> and maintainability.

Thanks for the patch.

But, no, sorry, we're not going to take patches like this. If you're
refactoring the code for _other_ reasons and want to convert over to the
new fancy stuff, go ahead.

But, we're not going to introduce bugs (and this kind of rework *WILL*
have bugs), make everyone else's code harder to merge, and clutter up
the history just to move to the newest shiny thing.

I'd much rather folks spend their time reviewing code or fixing bugs
than just churning code around.

Also, if anyone _does_ make code to use these new locks, *PLEASE* don't
do it this way:

> +	scoped_cond_guard(mutex_intr, return -EINTR, &quote_lock) {
> +		int ret;
> +		u8 *buf;
> +		struct tdx_quote_buf *quote_buf = quote_data;
> +		struct tsm_desc *desc = &report->desc;
> +		u64 err;

Indentation matters. Increasing the indenting on the whole function
makes it less readable. Don't do it like that ^.

I feel the need to reiterate: please don't send patches like this.
Please tell your friends.

      reply	other threads:[~2025-03-09 23:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-09 14:04 [PATCH] virt/tdx: Enhance tdx-guest driver with improved memory management liu.yun
2025-03-09 23:55 ` Dave Hansen [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=62586df1-fa54-44ef-bb74-3557ffa194fc@intel.com \
    --to=dave.hansen@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=liu.yun@linux.dev \
    --cc=liuyun01@kylinos.cn \
    --cc=x86@kernel.org \
    /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