gcc-3.4.0 sez:

init/do_mounts_rd.c:309: warning: conflicting types for built-in function 'malloc'

From: Hugh Dickins <hugh@veritas.com>

Stas Sergeev <stsp@aknet.ru> wrote:

   mprotect() fails to merge VMAs because one VMA can end up with
   VM_ACCOUNT flag set, and another without that flag.  That makes several
   apps of mine to malfuncate.


Great find!  Someone has got their test the wrong way round.  Since that
VM_MAYACCT macro is being used in one place only, and just hiding what it's
actually about, fold it into its callsite.

David Mosberger asked that this be backed out:

"I do not believe that flushing the TLB before migration is be the right thing
to do on ia64 machines which support global TLB purges (i.e., all but SGI's
machines)."

It was of huge benefit for the SGI machines, so work is ongoing.

Switch all users of MSEC[S]_TO_JIFFIES and JIFFIES_TO_MSEC[S] over to use
jiffies_to_msecs() and msecs_to_jiffies().  Withdraw MSECS_TO_JIFFIES() and
JIFFIES_TO_MSECS() from the kernel API.

Remove various private implementations of msecs_to_jiffies() and
jiffies_to_msecs().

There are various uppercase versions which should be consolidated.

From: Ingo Molnar <mingo@elte.hu>

We have various different implementations of MSEC[S]_TO_JIFFIES and
JIFFIES_TO_MSEC[S].  We recently had a compile-time clash in USB.

Fix all that up.

- The SCTP version was very inefficient.  Hopefully this version is accurate
  enough.

- Optimise for the HZ=100 and HZ=1000 cases

- This version does round-up, so sleep(9 milliseconds) works OK on 100HZ.

- We still have lots of jiffies_to_msec and msec_to_jiffies implementations.

From: William Lee Irwin III <wli@holomorphy.com>

  Optimize the cases where HZ is a divisor of 1000 or vice-versa in
  JIFFIES_TO_MSECS() and MSECS_TO_JIFFIES() by allowing the nonvanishing(!)
  integral ratios to appear as a parenthesized expressions eligible for
  constant folding optimizations.

From: me

  Use typesafe inlines for the jiffies-to-millisecond conversion functions.

  This means that milliseconds officially takes the type `unsigned int'.
  All current callers seem to be OK with that.

  Drivers need to be fixed up to use this instead of their private versions.

From: Nick Piggin <nickpiggin@yahoo.com.au>

this_rq_lock does a local_irq_disable, and sched_yield() needs to undo that.

This has been there for nearly two years.  See bugzilla #1403

vmscan.c does, in two places:

	spin_lock(zone->lru_lock)
	page = lru_to_page(&zone->inactive_list);
	if (page_count(page) == 0) {
		/* erk, it's being freed by __page_cache_release() or
		 * release_pages()
		 */
		put_it_back_on_the_lru();

	} else {

	--> window 1 <--

		page_cache_get(page);
		put_in_on_private_list();
	}
	spin_unlock(zone->lru_lock)

	use_the_private_list();

	page_cache_release(page);



whereas __page_cache_release() and release_pages() do:

	if (put_page_testzero(page)) {

	--> window 2 <--

		spin_lock(lru->lock);
		if (page_count(page) == 0) {
			remove_it_from_the_lru();
			really_free_the_page()
		}
		spin_unlock(zone->lru_lock)
	}


The race occurs if the vmscan.c path sees page_count()==1 and then the
page_cache_release() path happens in that few-instruction "window 1" before
vmscan's page_cache_get().

The page_cache_release() path does put_page_testzero(), which returns true.
Then this CPU takes an interrupt...

The vmscan.c path then does page_cache_get(), taking the refcount to one.
Then it uses the page and does page_cache_release(), taking the refcount to
zero and the page is really freed.

Now, the CPU running page_cache_release() returns from the interrupt, takes
the LRU lock, sees the page still has a refcount of zero and frees it again.
Boom.


The patch fixes this by closing "window 1".  We provide a
"get_page_testone()" which grabs a ref on the page and returns true if the
refcount was previously zero.  If that happens the vmscan.c code simply drops
the page's refcount again and leaves the page on the LRU.

All this happens under the zone->lru_lock, which is also taken by
__page_cache_release() and release_pages(), so the vmscan code knows that the
page has not been returned to the page allocator yet.


In terms of implementation, the page counts are now offset by one: a free page
has page->_count of -1.  This is so that we can use atomic_add_negative() and
atomic_inc_and_test() to provide put_page_testzero() and get_page_testone().

The macros hide all of this so the public interpretation of page_count() and
set_page_count() remains unaltered.

The compiler can usually constant-fold the offsetting of page->count.  This
patch increases an x86 SMP kernel's text by 32 bytes.

The patch renames page->count to page->_count to break callers who aren't
using the macros.

This patch requires that the architecture implement atomic_add_negative().  It
is currently present on

	arm
	arm26
	i386
	ia64
	mips
	ppc
	s390
	v850
	x86_64

ppc implements this as

#define atomic_add_negative(a, v)	(atomic_add_return((a), (v)) < 0)

and atomic_add_return() is implemented on

	alpha
	cris
	h8300
	ia64
	m68knommu
	mips
	parisc
	ppc
	ppc
	ppc64
	s390
	sh
	sparc
	v850

so we're looking pretty good.

From: David Mosberger <davidm@napali.hpl.hp.com>

From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>

It seems atomic_inc_and_test() is missing on alpha.

It's easy to do when the arch provides atomic_inc_return().

Lots of architectures have atomic_add_return() and no atomic_add_negative().

We can implement the latter in terms of the former.

I'm about to change the meaning (and name) of page->count.  Go through and fix
up all those places which are open-coding references to it.

into redhat.com:/spare/repo/net-drivers-2.6

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into kroah.com:/home/greg/linux/BK/driver-2.6

into kroah.com:/home/greg/linux/BK/i2c-2.6

Forgot to include this with my original patch a few weeks ago...

Jean Delvare <khali@linux-fr.org> writes:
> So I'd suggest that you simply use the standard exit sequence in the
> it87 driver (the second one in your current patch). A patch for the 2.4
> driver would be appreciated as well.

OK.  I've attached a new version of the patch against linux-2.6.6.
I'll send a patch against current lm_sensors CVS removing the extra
exit command in a separate mail.

Greg KH <greg@kroah.com> writes:
> On Wed, May 12, 2004 at 04:38:03PM +0200, Bj?rn Mork wrote:
>> +	if (!it87_find(&addr)) {
>> +		printk("it87.o: new ISA address: 0x%04x\n", addr);
>
> That printk is wrong (no KERN_ level, or dev_printk() style use).
> Please fix it in your next revision of this patch.

Errh, I just added it to document my sloppyness.  It was never meant
to be in the patch I sent you.  Sorry.  Removed in the attached patch.
The style of these drivers seem to be "just working, making no noise"
so I assume informational printk's are unwanted.

This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus).
In order to add this support I needed to patch pci_ids.h with the SMBus
DID's.  To keep things orginized I renumbered the ICH6 and ESB entries
in pci_ids.h.  I then patched the piix IDE and i810 audio drivers to
reflect the updated #define's.  I also removed an error from irq.c;
there was a reference to a 6300ESB DID that does not exist.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

I needed this to get an APM + UHCI config to behave on resume.
Applies against your BK of last night ... OHCI and EHCI do
some of this manually, they could be simplified later.

o The following patch cleans up sysfs_rename_dir(). It now checks the
  return code of kobject_set_name() and propagates the error code to its
  callers. Because of this there are changes in the following two APIs. Both
  return int instead of void.

int sysfs_rename_dir(struct kobject * kobj, const char *new_name)
int kobject_rename(struct kobject * kobj, char *new_name)

[note, I changed this a bit to be nicer on the system log, greg k-h]

Prakash K. Cheemplavam wrote:
> David Brownell wrote:
>
>>> There appear lines like

> >>> usb usb2: string descriptor 0 read error: -108

>>> bug or feature? They weren't there with 2.6.6-mm1. I have no usb2.0
>>> stuff to actually test. My usb1 stuff seems to work though.
>>
>> Bug; minor, since the only real symptom seems to be messages like
>> that.  Ignore them for now, I'll make a patch soonish.
>
> Ok, good. Thanks for the explanation of what is going on, though I don't
> can make too much out of it. ;-)

The short version is:  it's missing this patch.

It also could hide real bugs, and that's not good.  And the name
implies that a reference is grabbed, and that's not true at all.

If this is hiding real problems, we need to find them.

Pretty useless stuff.  If this was hiding anything real, we need to find out.

Following patch merges the support for Keyspan UPR-112 USB serial adapter
from 2.4 to 2.6.

Also fix up some of the other printk() calls to be dev_* calls.