The last things through the 2.6.26 merge window [LWN.net]

By Jonathan Corbet
May 5, 2008

About 500 changesets were merged after the publication of the first and second 2.6.26 merge window summaries. The merge window is now closed; here is the final set of changes which got in:

New drivers for Solarflare Communications Solarstorm SFC4000 controller-based Ethernet controllers, Hauppauge HVR-1600 TV tuner cards, ISP 1760 USB host controllers, Cypress c67x00 OTG controllers, and Intel PXA 27x USB controllers.
8Kb stacks are, once again, the default for the x86 architecture. "Out-of-memory situations are less problematic than silent and hard to debug stack corruption."
The klist type now has the usual-form macros for declaration and initialization: DEFINE_KLIST() and KLIST_INIT(). Two new functions (klist_add_after() and klist_add_before()) can be used to add entries to a klist in a specific position.
As had been planned, struct class_device has been removed from the driver core, along with all of the associated infrastructure. Classes are now implemented with an ordinary struct device.
kmap_atomic_to_page() is no longer exported to modules.
There are some new generic functions for performing 64-bit integer division in the kernel:
```
    u64 div_u64(u64 dividend, u32 divisor);
    u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder);
    s64 div_s64(s64 dividend, s32 divisor)
    s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder);
```
Unlike do_div(), these functions are explicit about whether signed or unsigned math is being done. The x86-specific div_long_long_rem() has been removed in favor of these new functions.
There is a new string function:
```
     bool sysfs_streq(const char *s1, const char *s2);
```
It compares the two strings while ignoring an optional trailing newline.

The prototype for i2c probe() methods has changed:

     int (*probe)(struct i2c_client *client, 
                  const struct i2c_device_id *id);

The new id argument supports i2c device name aliasing.

There is a new configuration (MODULE_FORCE_LOAD) which controls whether the loading of modules can be forced if the kernel thinks something is not right; it defaults to "no."

(Log in to post comments)

The last things through the 2.6.26 merge window

Posted May 8, 2008 9:25 UTC (Thu) by johill (subscriber, #25196) [Link]

I'd think that the function isn't all that generic, when would you want to use it (outside of
the sysfs braindamage)? Sure, its definition might sound generic, but I wouldn't think you
should use it often anyway.

The last things through the 2.6.26 merge window

Posted May 8, 2008 15:16 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

Hmm... It seems like removing optional trailing newlines early ought to be more general and
robust.  After all, perl has had chomp() for what, a decade or more?

The last things through the 2.6.26 merge window

Posted May 8, 2008 16:37 UTC (Thu) by bronson (subscriber, #4806) [Link]

As of this year, I think chop is 20 years old (+/- 1 year).  So this is what the future looks
like...  not very impressive.  I thought we'd all be using CORBA-connected dataflow languages
by now!

The last things through the 2.6.26 merge window

Posted May 8, 2008 16:47 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

Well, there's chop() and there's chomp().  Methinks chomp() is more appropriate to handle
optional newlines.  :-)

4k/8k stacks

Posted May 8, 2008 23:12 UTC (Thu) by kbob (guest, #1770) [Link]

I'm asking this from a position of ignorance -- I haven't looked at kernel code in a long
time.  But wouldn't it be possible to allocate 4k stacks with guard pages between them, thus
(a) saving memory and (b) generating a loud exception on stack overflow?

Or is there some kind of overhead in leaving holes into the kernel address space that I'm not
aware of?

4k/8k stacks

Posted May 9, 2008 0:48 UTC (Fri) by jmspeex (subscriber, #51639) [Link]

I believe we're talking non-virtual memory, so an overflow would just end up on the next
physical page with no way to detect it. Or maybe I'm just talking through my ass (I'm not a
kernel dev).

4k/8k stacks

Posted May 9, 2008 0:57 UTC (Fri) by corbet (editor, #1) [Link]

All memory is virtual memory when the kernel is running. But kernel-space addresses are a sort of special case, in that they are mapped as one big page using a single page table entry. So it's not possible to insert inaccessible guard pages after the kernel stacks - at least, not without dropping the big mapping, which would have a significant performance cost.

4k/8k stacks

Posted May 15, 2008 11:37 UTC (Thu) by cras (guest, #7000) [Link]

Maybe a small (32bit?) canary at the end of the stack would help a bit? Although if an
overflow 
happens I guess by the time it's noticed the kernel might have crashed already.

4k/8k stacks

Posted May 15, 2008 14:01 UTC (Thu) by mcortese (guest, #52099) [Link]

Kernel address space maps 1-to-1 to physical memory (at least for less than 1 GiB of RAM). The argument is 1 page vs. 2 pages of stack. Having just 1 page of stack plus 1 guard page just doesn't save anything.