lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 14 Aug 2008 10:39:45 -0700 From: "Yinghai Lu" <yhlu.kernel@...il.com> To: "David Witbrodt" <dawitbro@...global.net> Cc: "Bill Fink" <billfink@...dspring.com>, linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, "Peter Zijlstra" <peterz@...radead.org>, "Thomas Gleixner" <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, netdev <netdev@...r.kernel.org> Subject: Re: HPET regression in 2.6.26 versus 2.6.25 -- revert for 2.6.26-rc1 failed On Thu, Aug 14, 2008 at 5:03 AM, David Witbrodt <dawitbro@...global.net> wrote: > > >> > I'm not sure Yinghai's revert patch is completely equivalent to >> > a revert of the original problematic commit, by a side-by-side >> > comparison of the original commit with his recent revert patch, >> > but then I don't really know that code at all. >> > >> > In the original code there was a section (in e820_reserve_resources()): >> > >> > #ifdef CONFIG_KEXEC >> > if (crashk_res.start != crashk_res.end) >> > request_resource(res, &crashk_res); >> > #endif >> > >> > If you don't have CONFIG_KEXEC defined in your .config, which is >> > probably the case, then you would never request a crashk_res resource. >> > But in the code after the original commit, it unconditionally calls >> > (in reserve_crashkernel()): >> > >> > crashk_res.start = crash_base; >> > crashk_res.end = crash_base + crash_size - 1; >> > insert_resource(&iomem_resource, &crashk_res); >> > >> > And after Yinghai's revert patch it still does (in reserve_crashkernel()): >> > >> > crashk_res.start = crash_base; >> > crashk_res.end = crash_base + crash_size - 1; >> > crashk_res_ptr = &crashk_res; >> > >> > and (in setup_arch()): >> > >> > num_res = 3; >> > if (crashk_res_ptr) { >> > res_kernel[num_res] = crashk_res_ptr; >> > num_res++; >> > } >> > e820_reserve_resources(res_kernel, num_res); >> > >> > then (in e820_reserve_resources()): >> > >> > for (j = 0; j < nr_res_k; j++) { >> > if (!res_kernel[j]) >> > continue; >> > request_resource(res, res_kernel[j]); >> > } >> > >> > which for j == 3 is: >> > >> > request_resource(res, &crashk_res); >> > >> > Now it would appear that the new: >> > >> > insert_resource(&iomem_resource, &crashk_res); >> > >> > or new: >> > >> > request_resource(res, &crashk_res); >> > >> > should be noops. But if for any reason crash_size is not zero, >> > then there could be a difference. I have no idea if this is at all >> > significant, but I thought I'd point it out just in case. >> >> why oops ? > > I think he meant no-op's. > > >> if not valid crash kernel size etc is input, crashk_res_ptr will be null >> >> > if (crashk_res_ptr) { >> > res_kernel[num_res] = crashk_res_ptr; >> > num_res++; >> > } >> >> it that is not appended to res_kernel... > > So your patch code protects against problem that Bill is mentioning > without using "#ifdef CONFIG_KEXEC", right Yinghai? can you try enable kexec and kdump in you .config. it should works. my .config have config_kexec > Some experiments I did last night may render these questions moot, though. > My problem is very specific to the hardware on two of my machines, and it > has something to do with setting up the system resources that > insert_resource() touches. please try to bisect on current tree. and every time apply the revert patch... YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists