89dd10b06e
There is a race condition in pkg/archive when using `cmd.Start` for pigz and xz where the `*bufio.Reader` could be returned to the pool while the command is still writing to it, and then picked up and used by a new command. The command is wrapped in a `CommandContext` where the process will be killed when the context is cancelled, however this is not instantaneous, so there's a brief window while the command is still running but the `*bufio.Reader` was already returned to the pool. wrapReadCloser calls `cancel()`, and then `readBuf.Close()` which eventually returns the buffer to the pool. However, because cmdStream runs `cmd.Wait` in a go routine that we never wait for to finish, it is not safe to return the reader to the pool yet. We need to ensure we wait for `cmd.Wait` to finish! Signed-off-by: Stephen Benjamin <stephen@redhat.com> |
||
|---|---|---|
| .. | ||
| aaparser | ||
| archive | ||
| authorization | ||
| broadcaster | ||
| capabilities | ||
| chrootarchive | ||
| containerfs | ||
| devicemapper | ||
| directory | ||
| discovery | ||
| dmesg | ||
| filenotify | ||
| fileutils | ||
| fsutils | ||
| homedir | ||
| idtools | ||
| ioutils | ||
| jsonmessage | ||
| locker | ||
| longpath | ||
| loopback | ||
| mount | ||
| namesgenerator | ||
| parsers | ||
| pidfile | ||
| platform | ||
| plugingetter | ||
| plugins | ||
| pools | ||
| progress | ||
| pubsub | ||
| reexec | ||
| signal | ||
| stdcopy | ||
| streamformatter | ||
| stringid | ||
| symlink | ||
| sysinfo | ||
| system | ||
| tailfile | ||
| tarsum | ||
| term | ||
| truncindex | ||
| urlutil | ||
| useragent | ||
| README.md | ||
pkg/ is a collection of utility packages used by the Moby project without being specific to its internals.
Utility packages are kept separate from the moby core codebase to keep it as small and concise as possible. If some utilities grow larger and their APIs stabilize, they may be moved to their own repository under the Moby organization, to facilitate re-use by other projects. However that is not the priority.
The directory pkg is named after the same directory in the camlistore project. Since Brad is a core
Go maintainer, we thought it made sense to copy his methods for organizing Go code :) Thanks Brad!
Because utility packages are small and neatly separated from the rest of the codebase, they are a good place to start for aspiring maintainers and contributors. Get in touch if you want to help maintain them!