public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Brown <mbrown@fensystems.co.uk>
To: "Mantas Mikulėnas" <grawity@gmail.com>,
	"Matt Fleming" <matt@console-pimps.org>
Cc: Yinghai Lu <yinghai@kernel.org>,
	Matt Fleming <matt.fleming@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-efi@vger.kernel.org
Subject: Re: Loading initrd above 4G causes freeze on boot
Date: Wed, 20 Aug 2014 20:53:45 +0100	[thread overview]
Message-ID: <53F4FCC9.1030405@fensystems.co.uk> (raw)
In-Reply-To: <CAPWNY8V_gFutOcow5rBUSz2updGzf4hkQ98qBZ9WRGkb_sA2jA@mail.gmail.com>

On 20/08/14 20:05, Mantas Mikulėnas wrote:
> On Wed, Aug 20, 2014 at 8:05 PM, Matt Fleming <matt@console-pimps.org> wrote:
>> On Wed, 13 Aug, at 07:44:49PM, Matt Fleming wrote:
>>>
>>> At this point, I think modifying the max address is the best way to
>>> debug this further, and figure out what address causes the hang.
>>
>> Mantas, did you manage to get to the bottom of this issue?
>
> I experimented with some things (like setting chunk size to a few kB
> to see if it hangs earlier or only at the very end; etc.), and finally
> found out that it stops freezing if I pad the initrd file to a
> multiple of 512 bytes :/ That is, 5684268 bytes will freeze, 5684736
> bytes will not.
>
> ...In other words, seems like it cannot read chunks that aren't
> multiples of 512 into a location above 4 GB. Or something like that...

I haven't been following this thread closely, but that immediately 
sounds like a problem within the EFI_DISK_IO_PROTOCOL implementation 
(which is responsible for handling smaller-than-block-sized reads). 
Looking at the EDK2 implementation in 
MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIo.c, the memory management 
does appear to be somewhat inventive.  In particular, there's a frequent 
pattern in DiskIoCreateSubtaskList() equivalent to:

   if ( blocking_io ) {
      buffer = some_static_buffer;
   } else {
      buffer = malloc ( len );
      if ( ! buffer )
         goto single_shared_error_label;
   }
   ... do not record whether or not buffer was dynamically allocated ...
   ... use buffer as part of an asynchronous I/O operation ...
   ... eventually choose whether or not to free buffer, and hope the 
choice is correct ...

It's not at all obvious that memory is freed correctly, especially under 
some of the error paths within that code.

I can't immediately see anything that should fail with a pointer above 
4G, but I wouldn't be surprised to find a path that causes a double free 
or similar error.

Apologies if I've missed something critical earlier in the thread, 
making my ramblings are totally irrelevant.

Michael

  reply	other threads:[~2014-08-20 19:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-09 14:23 Loading initrd above 4G causes freeze on boot Mantas Mikulėnas
2014-08-09 16:44 ` Yinghai Lu
2014-08-09 19:23   ` Matt Fleming
2014-08-09 22:45     ` Mantas Mikulėnas
2014-08-10  5:55       ` Yinghai Lu
2014-08-10 18:43         ` Mantas Mikulėnas
2014-08-13 14:02           ` Matt Fleming
2014-08-13 16:38             ` Mantas Mikulėnas
2014-08-13 18:44               ` Matt Fleming
2014-08-20 17:05                 ` Matt Fleming
2014-08-20 19:05                   ` Mantas Mikulėnas
2014-08-20 19:53                     ` Michael Brown [this message]
2014-08-20 20:30                       ` Matt Fleming
2014-08-21 20:23                         ` [edk2] " Laszlo Ersek
2014-08-22 14:24 ` Harald Hoyer
2014-08-22 14:43   ` Mantas Mikulėnas
2014-08-24 19:19     ` Mantas Mikulėnas
2014-08-25 10:55       ` Matt Fleming
2014-08-25 11:08         ` Mantas Mikulėnas
2014-08-25 12:53           ` Matt Fleming
2014-08-25 18:22             ` Yinghai Lu

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=53F4FCC9.1030405@fensystems.co.uk \
    --to=mbrown@fensystems.co.uk \
    --cc=grawity@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matt@console-pimps.org \
    --cc=yinghai@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