| commit | 0131aeb3c742cfdb109f63716123e8324b2a481e | [log] [tgz] |
|---|---|---|
| author | Barret Rhoden <brho@cs.berkeley.edu> | Mon Apr 08 09:19:16 2019 -0400 |
| committer | Barret Rhoden <brho@cs.berkeley.edu> | Mon Apr 08 09:48:36 2019 -0400 |
| tree | 3e613d45f7a706cf5bfcf4ee0a254c8b83102614 | |
| parent | 26e4d0b9a3ef64c609f7ac331984aaea9f9b799f [diff] |
Fix refcounting problem in walk_symlink() The old code would double-close 'symlink' if it ever got into the "walk succeeded but we were still on a symlink" case. Recall that walk_symlink() either walks all the way, or not at all. If the old code (deleted) failed, we were supposed to close symlink. However, there was a case where walk_symlink would fail, but it would also close the chan passed in: when the sub-walk succeeded, but walk_symlink() still failed. How could that fail? With a symlink loop. If that sounds confusing, it's because it is. There are actually two spots of recursion, which might not even have been clear to me when I wrote this. The main recursive path is walk -> walk_symlink -> walk -> walk_symlink. We normally never got to the "walk succeeded, then call walk_symlink" (deleted). We usually only called walk_symlink() from *within* walk itself. You could trigger this situation with a no_follow symlink (rename/remove, flags Aremove, flags no_follow). Syzkaller basically did this: ln -s x x rename x/x whatever So we were walking the first x, had no_follow set, so walk -> walk_symlink for the first x. Since there were more names in the main/outer namec, we'd get past the first no_follow. Then that second walk() would be for "../x", where no_follow would kick in, since there were no longer any names left. That walk_symlink() would return the syml passed in, which appeared to walk to be a success (which it was). Anyway, this was calling the buggy post-successful-walk() part of walk_symlink(). The first fix I had was to only cclose(symlink) when that interior walk_symlink() succeeded. Although that fixed the bug (walk_symlink either succeeds xor closes, so don't close on success), the real problem was having that code at all. If walk() lands on a symlink, walk itself should try to deal with it (by calling walk_symlink()). If walk returns (success or failure), we should consider the walking of that symlink to be done, one way or another. If it is no_follow, we might be on a symlink (if last in the path). If it was a mount_point, we could be on a symlink too. That whole "we're still on a symlink, let's walk it again" was busted, and it would break when we had no_follow set globally and tried to follow a legit intermediate symlink that had more than one link to follow (but not 8 - the max). And it was confusing. Hopefully this code makes a little more sense - esp when realizing that walk() sorts out symlinks by calling walk_symlink(). walk_symlink() shouldn't call itself, but it can call walk(). Up to 8 times. Reported-by: syzbot+9eec51df84779065d6de@syzkaller.appspotmail.com Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
Akaros is an open source, GPL-licensed operating system for manycore architectures. Its goal is to provide better support for parallel and high-performance applications in the datacenter. Unlike traditional OSs, which limit access to certain resources (such as cores), Akaros provides native support for application-directed resource management and 100% isolation from other jobs running on the system.
Although not yet integrated as such, it is designed to operate as a low-level node OS with a higher-level Cluster OS, such as Mesos, governing how resources are shared amongst applications running on each node. Its system call API and “Many Core Process” abstraction better match the requirements of a Cluster OS, eliminating many of the obstacles faced by other systems when trying to isolate simultaneously running processes. Moreover, Akaros’s resource provisioning interfaces allow for node-local decisions to be made that enforce the resource allocations set up by a Cluster OS. This can be used to simplify global allocation decisions, reduce network communication, and ultimately promote more efficient sharing of resources. There is limited support for such functionality on existing operating systems.
Akaros is still very young, but preliminary results show that processes running on Akaros have an order of magnitude less noise than on Linux, as well as fewer periodic signals, resulting in better CPU isolation. Additionally, its non-traditional threading model has been shown to outperform the Linux NPTL across a number of representative application workloads. This includes a 3.4x faster thread context switch time, competitive performance for the NAS parallel benchmark suite, and a 6% increase in throughput over nginx for a simple thread-based webserver we wrote. We are actively working on expanding Akaros's capabilities even further.
Visit us at akaros.org
Instructions on installation and getting started with Akaros can be found in GETTING_STARTED.md
Our current documentation is very lacking, but it is slowly getting better over time. Most documentation is typically available in the Documentation/ directory. However, many of these documents are outdated, and some general cleanup is definitely in order.
Send an email to akaros+subscribe@googlegroups.com.
Or visit our google group and click “Join Group”
Create a new issue here.
brho hangs out (usually alone) in #akaros on irc.freenode.net. The other devs may pop in every now and then.
Instructions on contributing can be found in Documentation/Contributing.md.
The Akaros repository contains a mix of code from different projects across a few top-level directories. The kernel is in kern/, userspace libraries are in user/, and a variety of tools can be found in tools/, including the toolchain.
The Akaros kernel is licensed under the GNU General Public License, version 2. Our kernel is made up of code from a number of other systems. Anything written for the Akaros kernel is licensed “GPLv2 or later”. However, other code, such as from Linux and Plan 9, are licensed GPLv2, without the “or later” clause. There is also code from BSD, Xen, JOS, and Plan 9 derivatives. As a whole, the kernel is licensed GPLv2.
Note that the Plan 9 code that is a part of Akaros is also licensed under the Lucent Public License. The University of California, Berkeley, has been authorised by Alcatel-Lucent to release all Plan 9 software previously governed by the Lucent Public License, Version 1.02 under the GNU General Public License, Version 2. Akaros derives its Plan 9 code from this UCB release. For more information, see LICENSE-plan9 or here.
Our user code is likewise from a mix of sources. All code written for Akaros, such as user/parlib/, is licensed under the GNU LGPLv2.1, or later. Plan 9 libraries, including user/iplib and user/ndblib are licensed under the LGPLv2.1, but without the “or later”. See each library for details.
Likewise, tools/ is a collection of various code. All of our contributions to existing code bases, such as GCC, glibc, and busybox, are licensed under their respective projects' licenses.