Kernel Traffic #258 For 18 Apr 2004

I am very proud to announce this because it fixes several of security bugs including the last mremap() bug, the longer known hashing exploit possibility in the network stack and /dev/rtc leakage.

I encourage all 2.2 kernel users to update.

Please send me all fixes/patches/etc. I've forgotton for 2.2.27-pre/rc inclusion.

MontaVista Software has developed a new filesystem targeted for embedded systems that we would like to have considered for inclusion in 2.6 or 2.7. It is called the Protected and Persistent RAM Special Filesystem (PRAMFS). It was originally developed for three major consumer electronics companies for use in their smart cell phones and other consumer devices.

An intro to PRAMFS along with a technical specification is at the SourceForge project web page at http://pramfs.sourceforge.net/. A patch for 2.6.3 has been released at the SF project site.

PRAMFS can be tested on a desktop by reserving some portion of physical memory with "mem=". For example, a machine with 512M could reserve the top 32M with "mem=480M". PRAMFS would then be mounted with:

mount -t pramfs -o physaddr=0x1e000000,init=0x2000000 none /mnt/pramfs

I don't really like having two implementations of same code in kernel. There are two ways to deal with it:

• remove pmdisk from kernel

  • its easy

• remove swsusp from kernel, rename pmdisk to swsusp, fix all bugs that were fixed in swsusp but not in pmdisk

  • people seem to like pmdisk code more
  • will need some testing in -mm series

Which one do you prefer? I can do both...

2.6 is allegedly the stable kernel series, so if swsusp is the more stable code base at this point, my vote would be to keep swsusp and remove pmdisk from the kernel. If someone wants to maintain a separate BK-tree that contains pmdisk renamed to swsusp and fix all the bugs, that's great. On the other hand, there are a group of people of are busy doing something very similar with swsusp2, and that effort seems to have a fair number of people working on the patch and testing it.

So if we can somehow go from *three* idependent software suspend implementations implementations to something less than three, and increase the testing and effort devoting to remaining software suspend code bases, this would be a good thing.

Pavel, what do you think of the swsusp2 patch, BTW? My biggest complaint about it is that since it's maintained outside of the kernel, it's constantly behind about 0.75 revisions behind the latest 2.6 release. The feature set of swsusp2, if they can ever get it completely bugfree(tm) is certainly impressive.

It also has the advantage of working extremely reliably on 2.4 (and a large part of the code base is shared, so that's a significant data point). I couldn't get it to crash or do anything bad for months now, and I'm doing at least several suspend/resumes a day on my laptop.

Also, thanks to the excellent compression feature, suspend/resume times are very short and in fact competitive with suspend-to-ram schemes.

I think it's better not to mix personal preferences (such as the escape-to-abort thing) with technical discussions. On a practical level, swsusp2 is the only implementation which works reliably, does its job very well, and has a responsive maintainer willing to fix problems as they arise.

It may have problems, rough edges, whatever, but keeping out of tree is more or less a guarantee that none of us will look & fix them ;)

If it gets upstream, I'll gladly finish the pmac support for it that I quickly hacked recently for pmdisk as a proof of concept and help figure out some of the remaining problems. I don't feel like doing that with an out-of-tree project.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4/2.6.4-mm2/

• Added the new per-address_space block unplugging code. This is designed to reduce the locking contention against the global plug list's lock and it also allows us to avoid unplugging all the queues in the machine when we want just a single queue to kick off its I/O.
• Reiserfs updates: mainly new features.
• Some significant NFS client enhancements: reads smaller than PAGE_SIZE are no longer synchronous, support for smaller-than-PAGE_SIZE reads, etc.

I've made a few changes to the BK/Web service on BK/Bits. There are some cosmetic changes but the substantial changes are as follows:

• Traditional diff -Nur style patches served as text/plain. You can now wget your favorite patch. I fully expect that the BK users in the kernel will start including URLs to the patches as part of the submission process. For the BK users, the URL you want is

  bk changes -r+ -nd'http://$proj.bkbits.net/$repo/gnupatch@:MD5KEY:'

  where you fill in $proj and $repo and this assumes that you want to include a pointer to the most recent changeset.

• Bookmarkable changeset and patch links. When you navigate to a changeset you'll see a link that says "Bookmarkable link". If you click on that you'll see the URL change from cset@1.1234 to cset@<MD5KEY>. If you use the latter in your mail messages to your friends that URL will always work; the first one won't.
• Added sorting to the stats page, now you can see who is busy faster. The definition of "recent" on the stats page is the last 3 months.
• fixed searching (it works, it's still slow on large trees)
• cleaned up some bugs in the advertising (we're looking for people so I stuck ads up on the web pages).

Check it out at http://www.bkbits.net and let me know if you find a bug.

Hey thats cool, I know I will use this often to slurp down patches of interest.

<obligitory request for yet more stuff which is almost certain to piss you off since you just gave me yet-another-something-for-free>

I'm curious if you might consider adding a diff -Nur style patch vs the last tagged version? I often go to:
http://www.kernel.org/pub/linux/kernel/v2.4/testing/cset/
and
http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/

to obtain this sortof a patch, for example when I want to submit a patch that is relevant to the current kernel tree, rather than 1000 patches behind. Sadly, these are often rather out of touch with reality. Check out for example the 2.4 one, which has been stuck since March 8th. :-(

Right now I can go to, for example:
http://linux.bkbits.net:8080/linux-2.4/ChangeSet@1.1326..?nav=index.html|tags
and see the list of patches, and thanks to your latest update, I can now click on each patch one-by-one to suck down a diff. I would sure love to be able to obtain the lot as cumulative patch of everything after the last tagged version.

I do not know if that is something you might consider, if doing so suites your business model, if doing so would make unreasonable demands on your donated bandwidth, cpu power, etc, etc, etc. But such a thing would certainly come in handy, if you felt so inclined.

Of course, an alternative solution would be for someone to fix the kernel.org testing/cset/ scripts to not get wedged...

This is most profitably done outside of bkbits -- the kernel.org URLs you point to should work (there's no reason they can't be made to go) and it's hard to see the payoff to bkbits to providing it internally.

Gotta remember, bkbits is more than just kernel stuff. We're probably not going to add code that is only useful to the kernel project.

The stuff larry added this weekend, by comparison, is stuff that makes our lives better and has a payoff for us and our customers, while simultaneously making life better for bkbits users. Win-win. (Or is that win-win-win?)

is there any way in Linux to do proper fsync(), which makes sure data is written to the disk.

Currently on IDE devices one can see, fsync() only flushes data to the drive cache which is not enough for ACID guaranties database server must give.

There is solution just to disable drive write cache, but it seems to slowdown performance way to much.

I would be also happy enough with some global kernel option which would enable drive cache flush on fsync :)

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc1/2.6.5-rc1-mm2/

• Dropped the early-x86-cpu-detection patches, as these appear to be the source of recent early-crash problems.
• Several fixes against the new writeback code.
• Several fixes against the new block unplugging code.

Attached is the latest libata patch against 2.6.x mainline. Although not 100% of content, most of this patch resolves around getting Silicon Image into better shape. As I mentioned in my last post, this patch affects all libata users, so plenty of testing is requested.

Silicon Image-related changes:

• Only set/clear the BMDMA bits we care about (got a report last night this fixed 3114 for him)
• mask all SATA interrupts
• after determining drive speed, write that information to a special SII register Data Transfer Mode
• (style) make port base address setup a loop, shortening the code and making the code more readable
• limit SII to UDMA5 (reading info on FreeBSD lists and source code scared me about chip errata), mainly related to PATA->SATA bridges.

Here goes the fifth -pre of 2.4.26.

It includes a number of USB bugfixes/updates, SCSI driver/stack fixes from Doug Ledford, another ACPI update, amongst others.

This is probably the last -pre of 2.4.26 series.

Ever since 2.4.25, when compiling it in to any RedHat 7.3 machine, the following appears in dmesg:

attempt to access beyond end of device
03:02: rw=0, want=1020128, limit=1020127

I traced this to the mount version that ships with RedHat 7.3 (mount-2.11n). Upgrading mount to a newer version gets rid of the messages, but I am unsure as to whether or not the errors are really going away. Do you have any comments/suggestions concerning this issue?

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/2.6.5-rc2-mm1/

• Dave Jones's agpgart and cpufreq trees will henceforth be included in -mm kernels.
• Various speedups, cleanups and fixes to the writeback, ext2 and ext3 code.
• The usual bunch of random fixes

OSS will stay in 2.6 (2.6 is a stable kernel series) but it will most likely be removed in 2.7.

I wouldn't spend time to fix deprecated warnings in OSS code, such cleanups are wasted time for code that will most likely be removed in 2.7.

The real issue with removing OSS from a stable kernel is that a kernel update should not break existing system software (at least compliant software). As of early 2.6 it seemed that you had to update to the ALSA mixer and {something I don't remember} if you used the OSS emulation. I just used OSS and it worked. Based on only two systems, so it may not apply.

Stable and install new sound software don't seem to mix well. I suggest that the current course is a good one, keep both systems in the stable kernel.

find attached a patch to parse the elf binaries for a PT_GNU_STACK section to set the stack non-executable if possible. Most parts have been shamelessly stolen from Ingo Molnar's more ambitious stackshield http://people.redhat.com/mingo/exec-shield/exec-shield-2.6.4-C9

The toolchain has meainwhile support for marking the binaries with a PT_GNU_STACK section with ot without x bit as needed.

If no such section is found, we leave the stack to whatever the arch defaults to. If there is one, we explicitly disabled the VM_EXEC bit if no x bit is found, otherwise explicitly enable.

I believe this part should be merged into official mainstream kernels. Ingo, what do you think?

This patch propagates the PT_GNU_STACK setting into the vma flags, allowing the architecture to set the stack permissions non-executable if the architecture chooses to do that, yes?

Which architectures are currently making their pre-page execute permissions depend upon VM_EXEC? Would additional arch patches be needed for this?

This may not get past Linus of course. It doesn't even get past me with that magical undocumented -1/0/+1 value of the executable_stack argument. Please replace that with a proper, commented, #defined-or-enumerated value, thanks.