linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
	Lai Jiangshan <jiangshan.ljs@antgroup.com>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH V5 3/7] x86/entry: Move PUSH_AND_CLEAR_REGS out of error_entry()
Date: Wed, 13 Apr 2022 10:39:01 +0200	[thread overview]
Message-ID: <YlaMJehKIxXM/Aui@zn.tnic> (raw)
In-Reply-To: <CAJhGHyC7KUj=s+w+isBewdL7iyUyEm4h++rWRoz2zBc0zAD2gw@mail.gmail.com>

On Wed, Apr 13, 2022 at 11:48:21AM +0800, Lai Jiangshan wrote:
> I meant the real .entry.text size is unchanged.  No matter what
> the complied .entry.text size is, 5.5k before the patch, or 8.2k
> after the patch, the size of .entry.text in the kernel is always 2M.

Yes, unless the bloat I'm talking about above continues and then it
becomes 4M. So we need to be careful.

> I will follow your instructions and add an extra ASM function.

Thx.

> And maybe add this to the changelog:
> 
> A function call is added for every interrupt or exception, but it

I think you need to read submitting-patches.rst again:

"Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour."

In your case:

"Add a function call..."

> is a low-level asm function call and actually, only a "call" and a
> "ret" instructions are added.

CALL, RET - all x86 insns in caps.

> It will enable error_entry() to be

It will allow for sync_regs() to be converted to C...

> C code that can use inlined sync_regs() and save a C function call
> which will reduce more instructions in return.
> 
> I'm also waiting for reviews for other patches and I'm not going to
> send this new code too soon since I don't want to send a new revision
> with only this patch updated.

Again, submitting-patches.rst:

"After you have submitted your change, be patient and wait.  Reviewers are
busy people and may not get to your patch right away.

...

You should receive comments within a week or so; if that does not
happen, make sure that you have sent your patches to the right place.
Wait for a minimum of one week before resubmitting or pinging reviewers
- possibly longer during busy times like merge windows"

So you send, wait for feedback, incorporate it and resend after a week,
but not earlier.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2022-04-13  8:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 12:15 [PATCH V5 0/7] x86/entry: Clean up entry code Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 1/7] x86/traps: Move pt_regs only in fixup_bad_iret() Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 2/7] x86/entry: Switch the stack after error_entry() returns Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 3/7] x86/entry: Move PUSH_AND_CLEAR_REGS out of error_entry() Lai Jiangshan
2022-04-12 13:26   ` Borislav Petkov
2022-04-12 13:52     ` Lai Jiangshan
2022-04-12 14:30       ` Borislav Petkov
2022-04-13  3:48         ` Lai Jiangshan
2022-04-13  8:39           ` Borislav Petkov [this message]
2022-04-12 12:15 ` [PATCH V5 4/7] x86/entry: Move cld to the start of idtentry macro Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 5/7] x86/entry: Don't call error_entry() for XENPV Lai Jiangshan
2022-04-20 16:32   ` Borislav Petkov
2022-04-12 12:15 ` [PATCH V5 6/7] x86/entry: Convert SWAPGS to swapgs and remove the definition of SWAPGS Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 7/7] x86/entry: Use idtentry macro for entry_INT80_compat Lai Jiangshan
2022-04-25 10:24   ` Thomas Gleixner
2022-04-25 13:25     ` Lai Jiangshan

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=YlaMJehKIxXM/Aui@zn.tnic \
    --to=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jiangshan.ljs@antgroup.com \
    --cc=jiangshanlai@gmail.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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;
as well as URLs for NNTP newsgroup(s).