From 08a102c3c418635d83c4bbbdd19e5bb6237ae836 Mon Sep 17 00:00:00 2001 From: marcel Date: Sat, 30 Mar 2002 01:36:03 +0000 Subject: Don't blindly dereference f->f_devdata as if it's always a pointer to an efi_devdesc structure. When we're netbooting, f->f_devdata holds the address of the network socket variable. Dereferencing this caused some very unpredictable behaviour, including proper functioning. So, as a sanity check, we first make sure f->f_dev points to our own devsw. If not, the open will fail before we use f->f_devdata. This solves the netboot hangs I invariably got whenever I used the latest toolchain to compile the EFI loader. --- sys/boot/efi/libefi/efifs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'sys/boot') diff --git a/sys/boot/efi/libefi/efifs.c b/sys/boot/efi/libefi/efifs.c index e459881..767ce64 100644 --- a/sys/boot/efi/libefi/efifs.c +++ b/sys/boot/efi/libefi/efifs.c @@ -48,7 +48,12 @@ efifs_open(const char *upath, struct open_file *f) CHAR16 *cp; CHAR16 *path; - if (!dev->d_handle) + /* + * We cannot blindly assume that f->f_devdata points to a + * efi_devdesc structure. Before we dereference 'dev', make + * sure that the underlying device is ours. + */ + if (f->f_dev != &efifs_dev || dev->d_handle == NULL) return ENOENT; status = BS->HandleProtocol(dev->d_handle, &sfsid, (VOID **)&sfs); -- cgit v1.1