[bug #48946] exec server can't properly load binaries without a memory manager object

[Samuel Thibault]

Update of bug #48946 (project hurd):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Indeed, thanks!


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48946] exec server can't properly load binaries without a memory manager object

[Brent Baccala]

URL:
  

 Summary: exec server can't properly load binaries without a
memory manager object
 Project: The GNU Hurd
Submitted by: baccala
Submitted on: Tue 30 Aug 2016 01:46:17 AM GMT
Category: Hurd Servers
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Reproducibility: Every Time
  Size (loc): None
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

When exec'ing a file, the exec server attempts to obtain a memory object to
the file with io_map, and then maps this object into the new task's memory
space.  If this fails, it then attempts to fall back on reading the file
normally, then copying the data into the new task's memory space.

Both of these cases need to respect the 'anywhere' flag, which indicates that
a memory mapping can be placed anywhere in the new task's address space and
that the kernel will return the address actually used.

The fallback code currently does not handle 'anywhere' mappings correctly; it
discards the new address and attempts to use the old one, which prevents
successful execution of the binary.

The attached patch fixes the fallback code.




___

File Attachments:


---
Date: Tue 30 Aug 2016 01:46:17 AM GMT  Name: exec.patch  Size: 3kB   By:
baccala



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/