|Og dreams of kernels||Greg KH||2 years 34 weeks ago|
|Re: Old IPSEC bug||Theo de Raadt||2 years 18 weeks ago|
|Re: Allegations regarding OpenBSD IPSEC||Rod Whitworth||2 years 18 weeks ago|
|Re: Allegations regarding OpenBSD IPSEC||Jason L. Wright||2 years 18 weeks ago|
|Re: Allegations regarding OpenBSD IPSEC||Bob Beck||2 years 18 weeks ago|
|Allegations regarding OpenBSD IPSEC||Theo de Raadt||2 years 18 weeks ago|
"'Good enough' is never good enough ;) What is the ideal implementation? Let's implement that."
"I'd like to get a first round of review on my AXFS filesystem," began Jared Hulbert, describing his new Advanced XIP File System for Linux. XIP stands for eXecute-In-Place. The new filesystem received quite a bit of positive feedback. Jared offered the following description:
"This is a simple read only compressed filesystem like Squashfs and cramfs. AXFS is special because it also allows for execute-in-place of your applications. It is a major improvement over the cramfs XIP patches that have been floating around for ages. The biggest improvement is in the way AXFS allows for each page to be XIP or not. First, a user collects information about which pages are accessed on a compressed image for each mmap()ed region from /proc/axfs/volume0. That 'profile' is used as an input to the image builder. The resulting image has only the relevant pages uncompressed and XIP. The result is smaller memory sizes and faster launches."
"The C standard will eventually support concurrency (they are working on it), and it will almost inevitably be a horrible pile of stinking sh*t, and we'll continue to use the gcc inline asms instead, but then the gcc people will ignore our complaints when they break the compiler, and say that we should use the stinking pile-of-sh*t ones that are built in.
"The latest feature release GIT 1.6.0 is available at the usual places," began Git maintainer, Junio Hamano, announcing the latest stable release of the distributed version control system originally written by Linus Torvalds. Among the current changes, Junio noted, "with the default Makefile settings, most of the programs are now installed outside your $PATH, except for 'git', 'gitk' and some server side programs that need to be accessible for technical reasons." He continued, "by default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4. Pack idx files are using version 2 that allows larger packs and added robustness thanks to its CRC checking, introduced in v1.5.2 and v18.104.22.168." Julio highlighted several other changes, including the addition of a '.sample' extension to the default trigger scripts to be sure they don't execute in a default install, and the removal of the 'stupid' merge strategy. Other changes include:
"Git-gui learned to stage changes per-line; Reduced excessive inlining to shrink size of the 'git' binary; When an object is corrupt in a pack, the object became unusable even when the same object is available in a loose form, we now try harder to fall back to these redundant objects when able; performance of 'git-blame -C -C' operation is vastly improved; even more documentation pages are now accessible via 'man' and 'git help'; longstanding latency issue with bash completion script has been addressed; pager. configuration variable can be used to enable/disable the default paging behaviour per command; git-cvsserver learned to respond to 'cvs co -c'; 'git-diff -p' learned to grab a better hunk header lines in BibTex, Pascal/Delphi, and Ruby files and also pays attention to chapter and part boundary in TeX documents; error codes from gitweb are made more descriptive where possible, rather than '403 forbidden' as we used to issue everywhere; git-merge has been reimplemented in C."
"The delta cache was really a huge hack that just turned out rather successful. It's been hacked on further since (to do some half-way reasonable replacement with _another_ hack by adding an LRU on top of it), but it really is very hacky indeed."
A recent discussion on the Linux Kernel mailing list noted that threaded 64-bit applications suffer a drastic slowdown in pthread_create performance when stack utilization goes above 4GB. Ingo Molnar offered an explanation of the problem, "unfortunately MAP_32BIT use in 64-bit apps for stacks was apparently created without foresight about what would happen in the MM when thread stacks exhaust 4GB. The problem is that MAP_32BIT is used both as a performance hack for 64-bit apps and as an ABI compat mechanism for 32-bit apps. So we cannot just start disregarding MAP_32BIT in the kernel - we'd break 32-bit compat apps and/or compat 32-bit libraries." The original report noted that once the shared stack goes above 4GB in size, thread creation can take as long as 10 milliseconds, a slowdown described as "quite unacceptable".
Ingo created a patch introducing a new MAP_STACK flag for glibc to be used instead of MAP_32BIT and avoid imposing the 32-bit performance limitation on threaded 64-bit applications. He noted, "glibc can switch to this new flag straight away - it will be ignored by the kernel." The new flag was quickly merged upstream, and changes were planned for glibc.
"If web browsers, office suites and mail clients on Windows have certain kinds of vulnerabilities, it is safe to assume that the same programs on Linux will have similar problems."
"It is about time to take a step back and describe what I have been implementing," began Daniel Phillips, referring to his new Tux3 filesystem. He provided a simple ASCII diagram that detailed the filesystem's hierarchical structure, describing each of the elements. About one he noted, "the volume table is a new addition not central to the goals of Tux3, but a nice feature to have given that it comes nearly for free. One Tux3 volume can have an arbitrary number of separate filesystems tucked inside it, indexed by a simple integer parameter at mount time. People say they like this idea and it imposes no significant complexity, so it goes in." Daniel continued:
"Each volume has a metablock pointing at the forward log chain for the volume, a version table that describes the hierarchical relationship between versions (snapshots), an atime table to take care of that horrid legacy Unix feature, and an inode table containing files and attributes of files. [...] Versioning takes place in three places, versioned pointers in the atime btree, versioned extents in a file data btree and versioned attributes in the inode table. [...] Notice the absence of a journal, the functionality of which is provided by forward log elements that I described in the Hammer thread (and will eventually write a separate post about)."
"Any benchmark is going to be a benchmark of the OS as much as it is going to be a benchmark of the filesystem. It's pretty hard to separate the two. ZFS is best tested on Open Solaris. UFS is best tested on FreeBSD, EXT3 is best tested on Linux, and HAMMER of course is best tested on DragonFly."
New functionality has been enabled that allows logged-in users to highlight interesting mailing list discussions. This new feature has been provided out of necessity, as I'm finding myself with insufficient time of late for keeping up with the many mailing lists I track to post articles on KernelTrap. My goal is to inspire you to participate more in the process, occasionally clicking the new up-arrow on mailing list messages that you find interesting and worthy of attention. In the upcoming weeks, improved interfaces will be provided for navigating other people's votes, and for filtering on only the mailing lists you're interested in. Future KernelTrap stories and quotes will be selected from those that are highlighted by this voting process.
"History is a one way street, and you might as well have the fs known the way it is so that people remember 'reiser oh wasn't he the guy who..' - unless you are trying to market the fs I guess."
"Things really _have_ calmed down, and hopefully we've also resolved a lot of the regressions in -rc3," began Linus Torvalds, announcing the 2.6.27-rc3 Linux kernel. He noted that much of the patch size was from the inclusion of the new ath9k wireless driver, with much of the rest of the patch size due to the renaming of many arch include files in the ARM, AVR32 and m68lnommu architectures. Linus continued:
"All the small changes are where the regression fixes are, and other random improvements. And they're all over. The ShortLog (appended) probably gives a taste of it."
"Security is not an absolute. Just as the terrorists win if it can induce the White House to shred the constitution and force us all to live in a constant state of fear, it is also pointless to induce people to install software that horrifically slows down their server so badly that you can't get anything done."
Mikulas Patocka announced new patches introducing snapshot merging for the Linux kernel's logical volume manager. He explained, "snapshot merging allows you to merge snapshot content back into the original device. The most useful use for this feature is the possibility to rollback [the] state of the whole computer after [a] failed package upgrade, [or an] administrator's error". The patches are for the 2.6.26 kernel, with device mapper 1.02.27 and LVM2.2.02.39.
Mikulas noted that there are three types of merges supported,
--onactivate. The default merge method is
--nameorigin, which can merge a snapshot into the origin volume, which can be mounted at any time after the merge starts. The
--namesnapshot method merges into a snapshot, which can then be mounted. And the
--onactive method schedules a merge to happen the next time the volume is activated, such as during a reboot. Mikulas noted, "this implementation of snapshot merging is meant to be stable, report any possible bugs to me."