All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] x86/boot/compressed/64: Set up GOT for paging_prepare() and cleanup_trampoline()
Date: Sun, 13 May 2018 23:03:56 +0300	[thread overview]
Message-ID: <20180513200356.2a4si345f76j2leb@black.fi.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1805132019490.1582@nanos.tec.linutronix.de>

On Sun, May 13, 2018 at 06:55:46PM +0000, Thomas Gleixner wrote:
> On Thu, 10 May 2018, Kirill A. Shutemov wrote:
> 
> > +	/*
> > +	 * paging_prepare() and cleanup_trampoline() below can have GOT
> > +	 * references. Adjust the table with address we are running at.
> > +	 */
> > +
> > +	/* The GOP was not adjusted before */
> 
> GOP == EFI speak for Graphics Output Protocol. What the heck? 

I was not aware about Graphics Output Protocol.
> 
> > +	xorq	%rax, %rax
> 
> And this clearing of RAX is related to this because? Sure you need it for
> adjust_got() but adding a comment to that is too much asked for, right?

Huh? The comment just above the line describes why it's needed.

> > +	/* Calculate the address the binary is loaded at. */
> > +	call	1f
> > +1:	popq	%rdi
> > +	subq	$1b, %rdi
> > +
> > +	call	adjust_gop
> > +
> >  	/*
> >  	 * At this point we are in long mode with 4-level paging enabled,
> >  	 * but we might want to enable 5-level paging or vice versa.
> > @@ -381,6 +396,24 @@ trampoline_return:
> >  	pushq	$0
> >  	popfq
> >  
> > +	/*
> > +	 * Previously we've adjusted the GOT with address the binary was
> > +	 * loaded at. Now we need to re-adjust for relocation address.
> > +	 */
> 
> Breaking up those comments makes it more readable, right?

Yes, I think so.

The first comment is for the whole block of code below. The second is the
comment for the first step.

> > +	/*
> > +	 * Calculate the address the binary is loaded at.
> > +	 * This address was used to adjust the table before and we need to
> > +	 * undo the change.
> > +	 */
> > +	call	1f
> > +1:	popq	%rax
> > +	subq	$1b, %rax
> > +
> > +	/* The new adjustment is relocation address */
> 
>   is the relocation address
> 
> > +	movq	%rbx, %rdi
> > +	call	adjust_gop
> > +
> >  /*
> >   * Copy the compressed kernel to the end of our buffer
> >   * where decompression in place becomes safe.
> > @@ -481,19 +514,6 @@ relocated:
> >  	shrq	$3, %rcx
> >  	rep	stosq
> >  
> > -/*
> > - * Adjust our own GOT
> > - */
> > -	leaq	_got(%rip), %rdx
> > -	leaq	_egot(%rip), %rcx
> > -1:
> > -	cmpq	%rcx, %rdx
> > -	jae	2f
> > -	addq	%rbx, (%rdx)
> > -	addq	$8, %rdx
> > -	jmp	1b
> > -2:
> > -	
> >  /*
> >   * Do the extraction, and jump to the new kernel..
> >   */
> > @@ -512,6 +532,26 @@ relocated:
> >   */
> >  	jmp	*%rax
> >  
> > +/*
> > + * Adjust global offest table
> 
> offest? 
> 
> > + *
> > + * RAX is previous adjustment of the table to undo (0 if it's the first time we touch GOP).
> 
>   is the previous
> 
> And there is no reason to make that line overly long.
> 
> > + * RDI is the new adjustment to apply.
> > + */
> > +adjust_gop:
> > +	/* Walk through the GOT adding the address to the entries */
> > +	leaq	_got(%rip), %rdx
> > +	leaq	_egot(%rip), %rcx
> > +1:
> > +	cmpq	%rcx, %rdx
> > +	jae	2f
> > +	subq	%rax, (%rdx)	/* Undo previous adjustment */
> > +	addq	%rdi, (%rdx)	/* Apply the new adjustment */
> > +	addq	$8, %rdx
> > +	jmp	1b
> > +2:
> > +	ret
> 
> I'm really tired of your carelessness. The amount of half baken stuff you
> submit is way above the tolerance level by now. I asked you several times
> to be more careful, but you simply do not care at all. Get your act
> together finally.

I don't think it's fair.

Yes, I have hard time write correctly, even in my native languages.
I'm blind to mistakes I do. I'm sorry about them.

But I do care about bugs in my code and I do my best addressing them.
It took a lot of effort to find root cause of the bug and your statement
about my carelessness doesn't match my assessment.

Have a nice day.

-- 
 Kirill A. Shutemov

  reply	other threads:[~2018-05-13 20:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10 17:38 [PATCH for v4.17 0/2] Fix two crashes in decomression code Kirill A. Shutemov
2018-05-10 17:38 ` [PATCH 1/2] x86/boot/compressed/64: Set up GOT for paging_prepare() and cleanup_trampoline() Kirill A. Shutemov
2018-05-13 18:55   ` Thomas Gleixner
2018-05-13 20:03     ` Kirill A. Shutemov [this message]
2018-05-13 21:30       ` Thomas Gleixner
2018-05-10 17:38 ` [PATCH 2/2] x86/boot/compressed/64: Fix moving page table out of trampoline memory Kirill A. Shutemov
2018-05-13 18:56   ` Thomas Gleixner
2018-05-13 20:05     ` Kirill A. Shutemov

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=20180513200356.2a4si345f76j2leb@black.fi.intel.com \
    --to=kirill.shutemov@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.