LWN.net Logo

The 2.6.39 merge window concludes

By Jonathan Corbet
March 29, 2011
There have been just over 2,200 non-merge changesets pulled into the mainline since the second installment in this series; that makes 8,757 total changes for this development cycle. The 2.6.39 merge window is now closed, so the feature set for this kernel development cycle should be complete. User-visible changes merged in the final part of the merge window include:

  • Beginning user namespace support has been merged. User namespaces are a sort of container where processes can safely be given root access within the container without being able to affect the rest of the system. Full container support is a long-term project, but the user namespace patches get the kernel one step closer.

  • It is now possible for a suitably privileged process to write to a processes /proc/pid/mem file.

  • The "group isolation" tunable for the CFQ I/O scheduler has been removed; group isolation is always provided now that the performance issues associated with that mode have been fixed.

  • There is a new "mtdswap" block device which allows swapping directly to memory technology devices.

  • New hardware support includes:

    • Processors and systems: Samsung Laptop SABI interfaces, WMI Hotkeys for Dell All-In-One series, Intel Medfield platform thermal sensors, and Asus Notebook WMI interfaces.

    • Miscellaneous: MSM chipset SMD packet ports, Texas Instruments TWL4030 hardware monitoring controllers, ST-Ericsson AB8500 voltage monitors, Maxim Semiconductor MAX8997/8966 PMICs, Maxim 8997/8966 regulators, Texas Instruments TPS61050/61052 boost converters, Ricoh R5C592 card readers, and OLPC XO-1.5 ebook switches.

    • Video4Linux: Technisat USB2.0 DVB-S/S2 receivers, Silicionfile NOON010PC30 CIF camera sensors, DiBcom 9000 tuners, 3com homeconnect "ViCam" cameras, OmniVision OV9740 sensors, ST Microelectronics STV0367 demodulators, OMAP3 camera controllers, Divio NW80x-based camera controllers, and ITE Tech IT8712/IT8512 infrared transceivers.

Changes visible to kernel developers include:

  • The dma64_addr_t type is no longer used in the kernel; it has been removed.

  • The videobuf framework in the Video4Linux2 subsystem has been replaced by a newer "videobuf2" version.

  • The media controller subsystem, intended to allow the system to export information about the topology of complex media subsystems to user space, has been merged.

  • printk() and friends have a new "%pB" format specifier which prints a backtrace symbol and its offset.

  • The m68k and m68knommu architectures have been merged in the kernel source tree.

  • A support library for BCH (Bose-Chaudhuri-Hocquenghem) encoding and decoding has been added.

  • Some low-level interrupt-related functions have changed names:

    OldNew
    get_irq_chip()irq_get_chip()
    get_irq_chip_data()irq_get_chip_data()
    get_irq_msi()irq_get_msi_desc()
    irq_data_get_irq_data() irq_data_get_irq_handler_data()
    set_irq_chained_handler() irq_set_chained_handler()
    set_irq_chip()irq_set_chip()
    set_irq_chip_and_handler_name() irq_set_chip_and_handler_name()
    set_irq_data()irq_set_handler_data()
    set_irq_handler()irq_set_handler()
    set_irq_nested_thread() irq_set_nested_thread()
    set_irq_noprobe()irq_set_noprobe()
    set_irq_type()irq_set_irq_type()
    set_irq_wake()irq_set_irq_wake()

    The prototypes for these functions are otherwise unchanged.

The 2.6.39 kernel now goes into the stabilization phase of the development cycle. If the usual pattern holds, we can expect to see on the order of 2000 fixes merged between now and the final release, which is likely to happen in early June.


(Log in to post comments)

The 2.6.39 merge window concludes

Posted Mar 31, 2011 7:12 UTC (Thu) by tcourbon (subscriber, #60669) [Link]

It may be a trivial question, but does the inclusion of "Samsung Laptop SABI interface" means that I will be able to use the Fn-key of my Samsung N210 ? I failed at founding what device are involved with that SABI thing.

The 2.6.39 merge window concludes

Posted Mar 31, 2011 8:52 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link]

The 2.6.39 merge window concludes

Posted Mar 31, 2011 17:23 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]

Did the Btrfs Raid 5/6 code make it in? My understanding is that it was mostly ready but I didn't see it in a quick look through the full changelog?

The 2.6.39 merge window concludes

Posted Apr 7, 2011 11:56 UTC (Thu) by csamuel (✭ supporter ✭, #2624) [Link]

I've seen no evidence of the RAID5/6 patches on the btrfs mailing list for some time now, so I wouldn't hold my breath for now. I've seen rumours that Chris Mason wants to merge the code once he's got a working btrfsck out there, but even that has been due RSN for a while.

user namespace and uid namespace

Posted Apr 1, 2011 1:19 UTC (Fri) by mfedyk (guest, #55303) [Link]

I'd like to point out that we had/have the uid namespace that went in around 2.6.27, which given the existence of user namespace, apparently didn't cover capabilities within the uid namespace (ie, leaving capabilities global to all namespaces).

I haven't been following this part of the namespace progression so I can only surmise what happened to the uid namespace.

Are there two namespaces now, uid and user with user ns being a superset of uid ns? Or was uid ns extended to cover capabilities within uid ns and renamed to user ns?

Now let me quote from the linked article (http://lwn.net/Articles/420624/):

> The user that creates the namespace will have all capabilities in that namespace, not just the set of capabilities they have in the parent. Essentially, the creator has the privileges of the root user in any namespace he or she creates.

Now since LXC doesn't have OpenVZ's simfs that lets you create a mountpoint based on any arbitrary directory, if you leave an unmodified distro in a container and you haven't used a separate filesystem (or btrfs subvolume), that distro can remount the host's filesystem as read-only (which typically happens just at the end of a halt or reboot inside the container).

One current workaround for this is to disable the CAP_SYS_ADMIN (or VXC_SECURE_MOUNT in Linux VServer[1]) capability. Since the allowed capabilities are reset fully open upon the creation of a new user namespace, how do you limit child namespaces from causing trouble on your host system and share a filesystem with LXC?

OpenVZ is great in this respect because you can have one filesystem with many containers on it without needing to use image files and loop mounts or lvm.

1. http://linux-vserver.org/Capabilities_and_Flags#Context_C...

user namespace and uid namespace

Posted Apr 3, 2011 11:02 UTC (Sun) by ebiederm (subscriber, #35028) [Link]

The uid/user namespace that went in around 2.6.27 is the same one under discussion. Unfortunately the implementation was massively incomplete and did not handle the case of where anything from different user namespaces were mixed.

In particular the user namespace is still moving in the direction of converting all of the checks from simple uid equality to comparing the tuple of usernamespace and uid.

The specific question about remounting a filesystem, the filesystem of piece of the permission checks has yet to be updated.

The reason getting a full set of capabilities will be harmless is because it is actually equivalent to dropping all capabilties. The capabilities will only apply to objects and namespaces created after you create the user namespace. So once properly implemented you simply won't be able to do anything dangerous but you will be able to use facilities that today are root only, only because suid root applications could be spoofed.

Eric

mtdswap?

Posted Apr 1, 2011 14:51 UTC (Fri) by knobunc (subscriber, #4678) [Link]

Does the mtdswap mean that I can have a swap device on a SD card (e.g. in an Android phone)? And how does it differ from the normal swap stuff?

The patch adds the following conf help:

  Provides volatile block device driver on top of mtd partition
  suitable for swapping.  The mapping of written blocks is not saved.
  The driver provides wear leveling by storing erase counter into the
  OOB.

mtdswap?

Posted Apr 2, 2011 15:35 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

No, you cannot treat an SD card as an MTD. The flash translation layer is implemented on the card itself and there is no (standard) way to bypass this.

mtdswap?

Posted Apr 2, 2011 17:48 UTC (Sat) by knobunc (subscriber, #4678) [Link]

Ah, rats. Thanks for the info.

mtdswap?

Posted Apr 3, 2011 1:20 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

But why can't you use the SD card for swapping already? The whole point of that flash translation layer in the SD card is so Linux wouldn't need special code like this. Doesn't the SD card look to Linux like a disk drive?

I would be afraid to swap to an SD card because of the wear. These products are sold for things like storing photographs -- applications where a heavy user would be unlikely to write to the same block even twice in a day. Swapping would probably wear one out pretty quickly, with a pretty nasty failure mode.

Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds