netdev - Re: HPET regression in 2.6.26 versus 2.6.25 -- revert for 2.6.26-rc1 failed

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080814060433.684c4fe5.billfink@mindspring.com>
Date:	Thu, 14 Aug 2008 06:04:33 -0400
From:	Bill Fink <billfink@...dspring.com>
To:	David Witbrodt <dawitbro@...global.net>
Cc:	Yinghai Lu <yhlu.kernel@...il.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

Hi David,

On Wed, 13 Aug 2008, David Witbrodt wrote:

> [Yinghai, please note that I did not request a patch to revert the
> problem commit.  I was merely experimenting -- on my own time, so
> you folks would not have to bother -- to see if I could make it
> work.  I should have made that more clear!  Having said that, I am
> glad to test changes of any kind on my machine:  reverts, code for
> debugging or info, experiments, etc.]

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.

						-Bill
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html