profile
viewpoint
John Starks jstarks @Microsoft Microsoft OS engineering lead for containers, virtualization, WSL

microsoft/WSL 8695

Issues found on WSL

microsoft/Docker.DotNet 1052

:whale: .NET (C#) Client Library for Docker API

microsoft/go-winio 389

Win32 IO-related utilities for Go

jstarks/npiperelay 145

npiperelay allows you to access Windows named pipes from WSL

Azure/go-ansiterm 50

Go package for ANSI terminal emulation in Windows

jstarks/containerd 0

An open and reliable container runtime

jstarks/curl 0

A command line tool and library for transferring data with URL syntax, supporting HTTP, HTTPS, FTP, FTPS, GOPHER, TFTP, SCP, SFTP, SMB, TELNET, DICT, LDAP, LDAPS, FILE, IMAP, SMTP, POP3, RTSP and RTMP. libcurl offers a myriad of powerful features

jstarks/diskspd 0

DISKSPD is a storage load generator / performance test tool from the Windows/Windows Server and Cloud Server Infrastructure Engineering teams

jstarks/distribution 0

The Docker toolset to pack, ship, store, and deliver content

jstarks/docker 0

Docker - the open-source application container engine

fork jstarks/rfcs

RFCs for changes to Rust

https://rust-lang.github.io/rfcs/

fork in 17 days

issue closedrust-lang/rustfmt

newline_style = "Unix" has no effect for unchanged files

I have a project where many files have Windows line endings. I set newline_style to Unix and ran cargo fmt, expecting the files to be reformatted, but they are not unless there is some other non-line-ending change being made.

Interestingly, the opposite is not true: if I explicitly set newline_style to Windows, then any Unix-formatted files are rewritten even if there is no other reformatting to do.

To repro this:

cargo init
git add .
cargo fmt -- --config newline_style=Windows
git diff # see that src/main.rs has been reformatted with Windows line endings
git add -u
cargo fmt -- --config newline_style=Unix
git diff # see that there are no changes--src/main.rs still has Windows line endings

closed time in 2 months

jstarks

issue commentrust-lang/rustfmt

newline_style = "Unix" has no effect for unchanged files

Ah ha, you're right, confirmed. Closing. Thanks!

jstarks

comment created time in 2 months

issue commentrust-lang/rustfmt

newline_style = "Unix" has no effect for unchanged files

Oops, sorry. This repros with both: rustfmt 1.4.8-stable (afb1ee1c 2019-09-08) and: rustfmt 1.4.9-nightly (33e36670 2019-10-07)

jstarks

comment created time in 2 months

issue openedrust-lang/rustfmt

newline_style = "Unix" has no effect for unchanged files

I have a project where many files have Windows line endings. I set newline_style to Unix and ran cargo fmt, expecting the files to be reformatted, but they are not unless there is some other non-line-ending change being made.

Interestingly, the opposite is not true: if I explicitly set newline_style to Windows, then any Unix-formatted files are rewritten even if there is no other reformatting to do.

To repro this:

cargo init
git add .
cargo fmt -- --config newline_style=Windows
git diff # see that src/main.rs has been reformatted with Windows line endings
git add -u
cargo fmt -- --config newline_style=Unix
git diff # see that there are no changes--src/main.rs still has Windows line endings

created time in 2 months

issue commentgolang/go

runtime: revert Windows change to boot-time timers

I think it's disrespectful to brush this issue off as bikeshedding. I don't mind if you clear the release blocking tag (I didn't add it), but discussing the technical merits of a bug fix that you implemented is anything but bikeshedding.

networkimprov

comment created time in 2 months

issue commentgolang/go

runtime: revert Windows change to boot-time timers

I'm going to double check my Windows 8 claim--it may have been Windows 7 (which would make sense because that's when QueryUnbiasedInterruptTime was introduced). I'll ask someone down the hall who has worked on the Windows timer infrastructure when I get a chance.

In any case, before the change to the Go runtime, Go programs inherited the system timer behavior. As far as I know, there was never a case before Go 1.13.3 that Go attempted to force a BOOTTIME-style timer behavior on Windows (or on Linux).

So yes, this change was a breaking change to Go timer semantics on Windows. I'm certainly sympathetic that WireGuard needs a solution here, but there is other Go software out there too.

networkimprov

comment created time in 2 months

issue commentgolang/go

runtime: revert Windows change to boot-time timers

This was a breaking change in a bug fix release that introduces inconsistent behavior between operating systems. There is clearly no consensus that this is the right change for Linux or the change would have been made already.

It's very strange to me that this is considered an acceptable approach to the evolution of the Go runtime.

networkimprov

comment created time in 2 months

issue commentgolang/go

proposal: syscall: define Windows O_ALLOW_DELETE for use in os.OpenFile

@rsc I think there is some miscommunication--I agree with you and others that #32088 is the wrong choice for Go at this point. This is a change from my original position. I am advocating for this proposal, which is to add a flag to easily allow developers to easily opt into FILE_SHARE_DELETE in code that relies on this behavior and is intended to be cross platform.

Also regardless I think "Microsoft requested" is a weird way to put things, since I am not the Go representative for Microsoft in any mutually agreed capacity (if such a position can or should even exist). I am an engineering lead on the Windows Base team (kernel, file systems, virtualization). My team maintains and contributes to open source container-related components, hence my interest in Go.

I think you've convinced me to update my bio :).

rsc

comment created time in 2 months

push eventjstarks/hcsshim

Kevin Parsons

commit sha 5da84009fc11cf71f09c788a335e5c3a7676dc0e

Add CimFS package Signed-off-by: Kevin Parsons <kevpar@microsoft.com>

view details

John Starks

commit sha 241dce04d687d0198792320dc50eb2a1ada23d32

Move CimFS package into CIM package

view details

John Starks

commit sha fd450cbb7bb69f22ca53ef5ec0396b5a7b8f295e

cim: More tweaks

view details

John Starks

commit sha f15b0dd36aea4466ffa7eb67f3177a20c667d080

cim: Add writer errors

view details

John Starks

commit sha eee0a5f2580dbb1e2e409e6616fdea2a19eaa92f

cim: Add delta to WCI layer converter

view details

push time in 2 months

issue commentgolang/go

runtime: revert Windows change to boot-time timers

@DmitriyMV , right now, with this change, we are inconsistent between Linux and Windows, and inconsistent between different Windows devices (connected standby vs. classic sleep). That inconsistency seems like the worst possible situation to be in.

networkimprov

comment created time in 2 months

issue commentgolang/go

runtime: revert Windows change to boot-time timers

I can find some time to make the change that Alex originally prototyped if no one else is available. But in the meantime, a patch release of Go has regressed programs running in containers, so should we consider reverting this and then apply a more appropriate change later?

It's impossible to implement WireGuard securely if timers don't take into account sleep time.

CL 191957 fixes this problem. If we revert the CL and replace it with QueryUnbiasedInterruptTime, the problem will reappear.

As I understand it, Go on Linux has the same behavior as Go on Windows used to have before this change. WireGuard is specialized software and may have to work around this in both Windows and Linux.

I also think the fix in CL 191957 is incomplete--AFAIK, PowerRegisterSuspendResumeNotification only provides notifications for machines transitioning across classic sleep states, not when machines enter connected standby (which is used instead of sleep in some newer devices). In these cases, you will still see a difference between (biased) interrupt time and WaitForSingleObject's relative timers, so WireGuard presumably will still run into problems.

The right fix for WireGuard may be to offer a new kind of timer that uses absolute (wall clock) timeouts on Windows, which is affected by changes to system UTC time (NTP or otherwise) but not by sleep states. If that's insufficient, I can help investigate if there are other options that might be appropriate.

Also using QueryUnbiasedInterruptTime will make nanotime implementation about 2 times slower. See #31528 (comment) for details.

If slowing nanotime down from 2ns to 4ns is problematic, we can look at whether the internal definition of QueryUnbiasedInterruptTime is stable enough to inline into Go's runtime (which is what was done for the current version of nanotime: it was apparently cloned from QueryInterruptTime). I'd really like to avoid this, though, because the current definition relies on a private export from ntdll to the kernel that is not part of the external API or ABI.

networkimprov

comment created time in 2 months

Pull request review commentmicrosoft/hcsshim

Fix race condition in legacy process stdio code

 func (process *Process) Close() (err error) { 		return nil 	} +	process.stdioLock.Lock()+	defer process.stdioLock.Unlock()

No don't do that. :)

kevpar

comment created time in 2 months

Pull request review commentmicrosoft/hcsshim

Fix race condition in legacy process stdio code

 func (process *Process) Close() (err error) { 		return nil 	} +	process.stdioLock.Lock()+	defer process.stdioLock.Unlock()

Ditto elsewhere that we're not concerned about early returns...

kevpar

comment created time in 2 months

Pull request review commentmicrosoft/hcsshim

Fix race condition in legacy process stdio code

 func (process *Process) Close() (err error) { 		return nil 	} +	process.stdioLock.Lock()+	defer process.stdioLock.Unlock()

Since there's other stuff in this function, it's probably better to unlock just after the if blocks.

kevpar

comment created time in 2 months

Pull request review commentmicrosoft/hcsshim

Fix race condition in legacy process stdio code

 func (process *Process) StdioLegacy() (_ io.WriteCloser, _ io.ReadCloser, _ io.R 		return nil, nil, nil, makeProcessError(process, operation, ErrAlreadyClosed, nil) 	} +	if process.stdin != nil && process.stdout != nil && process.stderr != nil {

And I guess there's a problem where if Docker asks for no std handles, this will still fall through unnecessary, possibly leading to the same race condition we are trying to fix.

Maybe cleaner to add a bool and check that.

kevpar

comment created time in 2 months

Pull request review commentmicrosoft/hcsshim

Fix race condition in legacy process stdio code

 func (process *Process) StdioLegacy() (_ io.WriteCloser, _ io.ReadCloser, _ io.R 		return nil, nil, nil, makeProcessError(process, operation, ErrAlreadyClosed, nil) 	} +	if process.stdin != nil && process.stdout != nil && process.stderr != nil {+		in, out, err := process.stdin, process.stdout, process.stderr+		process.stdin, process.stdout, process.stderr = nil, nil, nil

Is there any kind of lock we should take here?

kevpar

comment created time in 2 months

Pull request review commentmicrosoft/hcsshim

Fix race condition in legacy process stdio code

 func (process *Process) StdioLegacy() (_ io.WriteCloser, _ io.ReadCloser, _ io.R 		return nil, nil, nil, makeProcessError(process, operation, ErrAlreadyClosed, nil) 	} +	if process.stdin != nil && process.stdout != nil && process.stderr != nil {

Not positive, but I think there can be cases where only some of these are set (e.g. if Docker does not request stdin). So maybe these should be ||.

kevpar

comment created time in 2 months

issue commentgolang/go

proposal: syscall: define Windows O_ALLOW_DELETE for use in os.OpenFile

It seems to me that there are three camps:

  1. People who want some way to use os.OpenFile but opt into FILE_SHARE_DELETE semantics. They do not want to fork os.OpenFile for this purpose. They want ordinary cross-platform Go code to be able to pass this flag without third-party packages. For them, adding O_ALLOW_DELETE (ideally with it defined to be 0 on non-Windows platforms) is a good proposal.
  2. People who want all opens on Windows to pass FILE_SHARE_DELETE. They don't want to have to change open code. They propose to change behavior for all Go programs and have asked for examples of Go programs that would be affected negatively by such a change. At least one such person wants this to be a runtime opt-in.
  3. People who have no interest in passing FILE_SHARE_DELETE in cross-platform Go code. They don't want any behavior change, and they do not want additional flags to os.OpenFile. They point out that passing this flag can already be achieved by calling syscall.CreateFile, and that passing this flag does not eliminate all cases where an open file cannot be deleted (especially on older Windows versions).

Those in camp 1 would like to see this proposal accepted. Those in camp 2 would like to see #32088 reopened and accepted. Those in camp 3 would like both proposals rejected.

I am against #32088. I have been convinced that such a breaking change could negatively affect existing Go programs, which violates the Go compatibility guarantees. It's unfortunate that Go 1.0 did not always pass FILE_SHARE_DELETE, but here we are. I have always agreed that making it a runtime opt-in would be a mistake.

However, I am in support of this proposal. I do not see why adding an additional O_ flag would be controversial. It seems to me that exposing this capability this will help reduce Windows-specific code in software written in Go, and will make it easier to fix some existing POSIX-oriented Go code to work on Windows. That seems valuable to me.

rsc

comment created time in 2 months

push eventjstarks/hcsshim

John Starks

commit sha 225a953c31de94107bfe02da9d03533cd611e31d

cim: Rename cim.go to reader.go

view details

push time in 3 months

push eventjstarks/hcsshim

John Starks

commit sha 4a3f09478667f06f7f209576273f4ee172bf5e85

cim: Rename Cim to Reader

view details

push time in 3 months

push eventjstarks/hcsshim

John Starks

commit sha 3898240b988816ef1dbc8edc555bd1e5763a0cc4

cim: Cleanup, improve error codes

view details

John Starks

commit sha 453216518fa328c42397b22eaccd41638cf0a46b

cim: Add docs

view details

push time in 3 months

push eventjstarks/hcsshim

John Starks

commit sha 15eed9c21b85eafab37576a00b7a89c9a7999a06

cim: Remove FileID export

view details

John Starks

commit sha 9d6f1d95b6bde0c344a7b483474190c9731bd352

cim: Stream support, cimtool, fixes

view details

push time in 3 months

push eventjstarks/hcsshim

John Starks

commit sha 656f1b699ae071d8f39d3755663250e17d2b8759

cim: Improve perf

view details

John Starks

commit sha efe083c0eb7f6ac56af6c929af7ee8552a6fe213

cim: Cache inodes

view details

John Starks

commit sha c802f89444808e97b943c1bf3fbded218a8732d6

cim: Tweak comment

view details

push time in 3 months

push eventjstarks/hcsshim

John Starks

commit sha f55fac873c79b547de71a9a6a8686e1343615aaa

Some fixes

view details

John Starks

commit sha 810a23b874a8c5bee7a52ee7b854d58685285fe6

cim: Add working Open API

view details

push time in 3 months

issue commentgolang/go

runtime: "fatal error: PowerRegisterSuspendResumeNotification failure" when running in Windows docker containers

We can look into whether this could be supported in a future version of Windows containers. I think it would be reasonable to ignore failure in this case.

The bigger question to me is whether the change that introduced this regression was the right one at all. The Windows kernel team changed timer behavior in Windows 8 to stop advancing relative timeouts on wake. Otherwise when you open your laptop lid, every timer in the system goes off all at once and you get a bunch of unpredictable errors. Software is generally written to assume that local processes will make forward progress over reasonable time periods, and if they don't then something is wrong. When the machine is asleep, this assumption is violated. By making relative timers behave like threads, so that they both run together or they both don't, the illusion is maintained. You can claim these programs are buggy, but they obviously exist. Watchdog timers are well-known constructs.

This was a conscious design decision in Windows, and so it's disappointing to see the Go runtime second guess this several years later in a bug fix.

As far as behavior on Linux, there is clearly no consensus in issue #24595, which discusses this same problem. And indeed you can see that the CLOCK_MONOTONIC/CLOCK_BOOTTIME convergence was reverted in the kernel exactly because of the reason we stopped advancing time in Windows: random code has random failures due to timeouts. See https://lkml.org/lkml/2018/4/26/929 for a brief justification.

But despite the lack of consensus on Linux, for some reason the change in Windows behavior was merged already.

I think the change that introduced this should be reverted and the original proposal to use QueryUnbiasedInterruptTime (to match the behavior of WaitForSingleObject) should be adopted.

@mpx @networkimprov @ianlancetaylor seemed interested in this topic from the other issue.

KnicKnic

comment created time in 3 months

create barnchjstarks/hcsshim

branch : cim

created branch time in 3 months

pull request commentmoby/moby

Windows: Only set VERSION_QUAD if unset

LGTM

cpuguy83

comment created time in 3 months

Pull request review commentmicrosoft/opengcs

add ability to read runc log for errors in runc commands

 func (r *runcRuntime) processExists(pid int) bool { 	_, err := os.Stat(filepath.Join("/proc", strconv.Itoa(pid))) 	return !os.IsNotExist(err) }++func getRuncLogError(logPath string) interface{} {+	reader, err := os.OpenFile(logPath, syscall.O_RDONLY, 0644)+	if err != nil {+		return nil+	}+	defer reader.Close()++	var lastErr interface{}+	dec := json.NewDecoder(reader)+	for {+		var out map[string]interface{}

It's interesting to me that we're unmarshaling the JSON into a map instead of into a struct like we did in hcsshim when handling the same case... Is there a reason for this?

katiewasnothere

comment created time in 3 months

issue commentgolang/go

os: file open+write+close blocks subsequent Open() with "sharing violation"

I was able to repro this. We're looking into it internally.

networkimprov

comment created time in 3 months

issue commentgolang/go

os: file open+write+close blocks subsequent Open() with "sharing violation"

I'll try to get a repro on OneDrive and report the issue internally.

networkimprov

comment created time in 3 months

issue commentgolang/go

os: file open+write+close blocks subsequent Open() with "sharing violation"

Interesting. Are you trying this on a path that is backed up by OneDrive?

networkimprov

comment created time in 3 months

issue commentgolang/go

os: file open+write+close blocks subsequent Open() with "sharing violation"

In the past I have seen antivirus software keep files open for analysis after the file has been closed, blocking subsequent opens. I do not know whether Norton Lifelock has this problem. It would be interesting to temporarily disable all such security software on the machine (this can be difficult!) and try the repro again. If it stops reproing, then the best course of action would be to report the issue to Symantec.

If it continues to repro, I would suggest looking for any other atypical driver software in the file system stack. Try running fltmc.exe to see if there are any interesting file system filters installed, for example--compare the result to a stock Windows installation.

In any case, I don't think there's any evidence of a Go bug here, and it seems inappropriate for Go to try to work around reliability issues with basic file system APIs. These bugs need to be fixed in the components that are at fault.

networkimprov

comment created time in 3 months

Pull request review commentmicrosoft/opengcs

add ability to read runc log for errors in runc commands

 func (r *runcRuntime) CreateContainer(id string, bundlePath string, stdioSet *st // CreateContainer. func (c *container) Start() error { 	logPath := c.r.getLogPath(c.id)-	cmd := exec.Command("runc", "--log", logPath, "start", c.id)+	cmd := exec.Command("runc", "--log", logPath, "--log-format", "json", "start", c.id)

Would be nice to make a helper for this (exec.Command("runc", "--log", logPath, "--log-format", "json", args...))

katiewasnothere

comment created time in 3 months

issue commentgolang/go

os, syscall: CreateFile() needs FILE_SHARE_*

Except for ReadLink, they should work, yes.

networkimprov

comment created time in 3 months

issue commentgolang/go

os, syscall: CreateFile() needs FILE_SHARE_*

Although this is not documented well (that I can find), Windows will ignore the share flags if the requested access does not include FILE_READ_DATA, FILE_WRITE_DATA, FILE_EXECUTE, or DELETE. The only case that you've pointed out above is the one in ReadLink, which specifies GENERIC_READ (which is translated internally to FILE_GENERIC_READ, which includes FILE_READ_DATA).

And to fix ReadLink, you can probably just remove GENERIC_READ and replace it with 0 or READ_FILE_ATTRIBUTES--according to my reading of the Windows code, issuing FSCTL_GET_REPARSE_POINT does not require any special permissions on the file. And indeed, internally we generally pass 0 or READ_FILE_ATTRIBUTES when opening files for the purpose of issuing this FSCTL.

Having said all that, adding these share flags in these cases certainly doesn't hurt either--it just isn't necessary to fix any functional bug.

networkimprov

comment created time in 3 months

issue commentgolang/go

os: Stat() blocks concurrent Open() with "sharing violation"

stat calls CreateFile in a fallback path since apparently there are cases where GetFileAttributesEx fails.

networkimprov

comment created time in 3 months

issue commentgolang/go

os: Stat() blocks concurrent Open() with "sharing violation"

I let it run overnight with no repro.

networkimprov

comment created time in 3 months

issue commentgolang/go

os: Stat() blocks concurrent Open() with "sharing violation"

I'm unable to reproduce this on the latest version of Windows 10 with Go 1.13.1 (I should probably update...).

@networkimprov, do you have third-party antivirus software installed?

networkimprov

comment created time in 3 months

issue commentmicrosoft/terminal

Writing random output to console output handle fails with no last error set

Although there's also a call to _RemoveInvalidSequences before that, which presumably should remove any invalid UTF-8 sequences.

benhillis

comment created time in 3 months

issue commentmicrosoft/terminal

Writing random output to console output handle fails with no last error set

Should _InvolvedParse just stop passing MB_ERR_INVALID_CHARS to MultiByteToWideChar?

benhillis

comment created time in 3 months

issue commentgolang/go

internal/syscall/windows/registry: TestWalkFullRegistry failing on windows-amd64-longtest

Thanks for pointing this out; I can report these internally. But I think you'll have to keep your ignore list around, since it seems unlikely that we would backport fixes for these bugs.

bradfitz

comment created time in 3 months

issue commentmoby/moby

The recent Windows update breaks symlink handling on a Docker volume

Looking into this...

db4

comment created time in 3 months

issue commentgolang/go

syscall: windows doesn't allow read-only directories

There is no such document that I am aware of.

I don't think you want to try to do anything automatic with ACLs. You're unlikely to come up with a policy that will make everyone happy.

zx2c4

comment created time in 3 months

pull request commentmicrosoft/hcsshim

wclayer: Work around Windows bug when expanding sandbox size

Can we merge this? Can someone work to get this integrated into Moby?

jstarks

comment created time in 3 months

issue commentmicrosoft/hcsshim

Revert #718 when Windows 19H1 has expand sandbox fix

#718 for reference

jstarks

comment created time in 3 months

PR closed microsoft/hcsshim

Add osversion 18362

I have downloaded the ISO files for Windows 10 1903 and Windows Server, version 1903 and found version 18362 in docker info output. It's time to add it to the list of osversions.

+4 -0

1 comment

1 changed file

StefanScherer

pr closed time in 3 months

pull request commentmicrosoft/hcsshim

Add osversion 18362

This was added as V19H1 in an unrelated PR.

StefanScherer

comment created time in 3 months

push eventjstarks/hcsshim

Sebastiaan van Stijn

commit sha 92cb5b6976045984f6f746ca62c37ba952d37cae

Enhancement: add osversion.Build() utility Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

view details

John Howard

commit sha 2226e083fc390003ae5aa8325c3c92789afa0e7a

Merge pull request #569 from thaJeztah/add_build_function Enhancement: add osversion.Build() utility

view details

John Starks

commit sha 741b914f1849708bf7fd9a3c0a4cf729597b8503

internal/hcs: Improve process stdio lifetime To better support the external bridge, associate the stdio handles with the owning process and close them when the process object is closed.

view details

John Starks

commit sha 0dcdb44b887a6a528ca916a8eac85104efca39ff

shimdiag: New tool to diagnose runhcs shims Currently this tool allows listing running shims and execing a process in the shim's associated utility VM.

view details

John Starks

commit sha 40e0b86ace8a904c599158c97f7a0870103716ff

Replace linuxkit's hvsock support with go-winio's This fixes some race conditions when Close is called concurrently with other operations.

view details

John Starks

commit sha c5f1ca9ee8bd64317296ff0ce30002dfe013baa1

Merge pull request #576 from jstarks/hvsock Replace linuxkit's hvsock support with go-winio's

view details

John Starks

commit sha f072d47a533cf2dcdc8aedd12d415206e775ef3c

Merge pull request #572 from jstarks/stdio internal/hcs: Improve process stdio lifetime

view details

John Starks

commit sha 8c442edd4f71f556f7cd6c1b346c36fd57354b61

Merge pull request #575 from jstarks/shimdiag shimdiag: New tool to diagnose runhcs shims

view details

John Starks

commit sha f2a4e6f63ac499a3518df5ab2fc6b00259564fd8

shim: Fix build break

view details

John Starks

commit sha e38f6590af69e45ff38af046b7bf4d395e3e1142

Merge pull request #579 from jstarks/fix_build shim: Fix build break

view details

Justin Terry (VM)

commit sha 20158f49bf79623d48228d82a093e8c447a58f84

Fix shimdiag Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>

view details

John Starks

commit sha ad87c9209ca3465af1cf59c399a31d228b8d7558

shimdiag: Add stacks command to dump stacks

view details

Justin

commit sha 0d86597ce55f24b735815d0152362ef33f7985ec

Merge pull request #580 from Microsoft/shimdiag_fix Fix shimdiag

view details

Justin

commit sha 58f8f4bd40f183ca7697fc978e9f3b4cac9a7a8c

Merge pull request #578 from jstarks/shimdiag_stacks shimdiag: Add stacks command to dump stacks

view details

Sebastiaan van Stijn

commit sha ef775b6a90143374b7d5d99ed8e44a512e3cd162

Fix Windows Server version for RS4 in comment Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

view details

Justin Terry (VM)

commit sha 6fc80f50d764c1a621900d54f6eaeb298a75473f

Fix bug in documentation for UVM processor.limit Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>

view details

Justin Terry (VM)

commit sha 76d1d3a4dec488088c437c5b98f4916d1fa4e641

Move to golang 1.12.4 Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>

view details

Justin

commit sha 965235930020a817a95c5bc76ef51fe9c71c84a7

Merge pull request #585 from Microsoft/golang_1_12_4 Move to golang 1.12.4

view details

Justin

commit sha 41f3a0988b5e2321658612e19301c60a4d895bf0

Merge pull request #584 from Microsoft/processor_limit_doc_fix Fix bug in documentation for UVM processor.limit

view details

John Starks

commit sha c853b9ac561f8a4620ae69713bbbbc86d28c0260

hcs: Fail operations when the HCS service crashes If the HCS service crashes, then all processes and compute systems get notified of this. The code was previously ignoring this notification, meaning outstanding waits would never be satisfied. Now the notification causes all pending waits to complete with an error.

view details

push time in 3 months

push eventjstarks/hcsshim

John Starks

commit sha 823c83612a5e11222adfd4fb167a753d2a7eac50

osversion: Add version for 19H1

view details

John Starks

commit sha 164f6a773d063a500616fd6d13404ffc357540b7

wclayer: Work around Windows bug when expanding sandbox size This change works around a bug in Windows where a sandbox VHDX that has been resized cannot be successfully mounted. This is due to a failure in the path that resizes the NTFS volume inside the VHDX during the sandbox mount process. To work around this, manually expand the volume in the wclayer package just after making the call to expand the VHDX. This change hurts the performance of the resize operation on affected Windows hosts (19H1 and prerelease versions of Vb) and should be reverted once the Windows bug has been fixed and is widely deployed.

view details

push time in 3 months

PR opened microsoft/hcsshim

wclayer: Work around Windows bug when expanding sandbox size

This change works around a bug in Windows where a sandbox VHDX that has been resized cannot be successfully mounted. This is due to a failure in the path that resizes the NTFS volume inside the VHDX during the sandbox mount process. To work around this, manually expand the volume in the wclayer package just after making the call to expand the VHDX.

This change hurts the performance of the resize operation on affected Windows hosts (19H1 and prerelease versions of Vb) and should be reverted once the Windows bug has been fixed and is widely deployed.

This should provide a workaround for #708.

+179 -0

0 comment

3 changed files

pr created time in 3 months

create barnchjstarks/hcsshim

branch : workaround_expandlayer

created branch time in 3 months

issue commentmicrosoft/terminal

Feature Request: wt.exe supports command line arguments (profile, command, directory, etc.)

It's not just a tradition, it's encoded in the getopt family of functions, which are available in libc basically everywhere but Windows.

In Windows we use a version of getopt for wsl's option parsing. It might be useful to do the same (e.g. grab a copy of getopt from musl libc) so that things like -- (to separate options from non-option arguments) work in a predictable fashion.

fcharlie

comment created time in 3 months

Pull request review commentmicrosoft/opengcs

Create Containers and GCS cgroups on GCS startup

 func main() { 		bridgeOut = bridgeCon 	} +	// Setup the UVM cgroups to protect against a workload taking all available

Seems like a reasonable start. Maybe add some command line parameters to configure the sizes, though, so that we can adjust this from the host.

jterry75

comment created time in 4 months

Pull request review commentmicrosoft/hcsshim

Shorten Shutdown and Terminate timeout to 30 seconds

 func (c *Container) Shutdown(ctx context.Context) (err error) { 	defer func() { oc.SetSpanStatus(span, err) }() 	span.AddAttributes(trace.StringAttribute("cid", c.id)) +	ctx, cancel := context.WithTimeout(ctx, 30*time.Second)

Why not make this change in the caller, or in shutdown()?

Alternatively, should we have changed the global timeout on the bridge, either in the package or in the caller to the package? We already have a mechanism to terminate the bridge entirely if a synchronous RPC does not return in a certain time.

jterry75

comment created time in 4 months

issue commentgolang/go

proposal: syscall: define Windows O_ALLOW_DELETE for use in os.OpenFile

The motivation of this as well as the original proposal was to make it easier for Go software authors to write code that works cross-platform. We need to pass FILE_SHARE_DELETE to make Windows behave more like POSIX with respect to file deletion. There is general agreement that we cannot make this the default without regressing existing behavior, but the desire to have a clean, simple solution persists.

Any solution that requires extra dependencies, _windows.go files, build tags, etc. deviates from the goal of writing common code everywhere. I know from experience that it will be much easier to convince a random developer to add O_ALLOW_DELETE to their calls to os.OpenFile than to convince them to pull in an additional dependency with a custom fork of os.OpenFile, or to add Windows-specific .go files, just to get Windows to behave like everyone else.

I like the idea of putting a Windows-specific open routine in x/sys/windows to easily expose the wealth of CreateFile functionality! It would be great if we didn't have to replicate the complexity of calling syscall.CreateFile everywhere that needs Windows-specific functionality.

But I also think FILE_SHARE_DELETE is a special case worthy of inclusion in os.OpenFile, since it changes Windows behavior to be closer to all the other operating systems Go supports. I can't immediately think of any other CreateFile flags that do that.

rsc

comment created time in 4 months

issue commentgolang/go

x/sys/windows: API break in SecurityAttributes struct

Is there an official position on the compatibility guarantees for x/sys/windows? This is the second breaking change I've been made aware of in the last week.

pete-woods

comment created time in 4 months

PR closed microsoft/go-winio

Adapt to the API renewal of golang.org/x/sys/windows

Why I made this PR

There was a destructive API change in golang/x/sys module. It made it unable to build a module that depends on both this module and newer golang/x/sys. Resolve #161

  • Reference: https://github.com/golang/sys/commit/2dccfee4fd3e23e10ba17b9d696cf2388c28764b
+4 -6

3 comments

3 changed files

uztbt

pr closed time in 4 months

pull request commentmicrosoft/go-winio

Adapt to the API renewal of golang.org/x/sys/windows

The change in x/sys/windows was reverted: https://github.com/golang/sys/commit/855e68c8590b0d6a9d08863d2982eb8aeddd98d3. So this PR is no longer necessary.

Thanks for the contribution!

uztbt

comment created time in 4 months

pull request commentmicrosoft/go-winio

Move to upstream Sddl/SecurityAttribute functions

We should leave the existing functions but have them call through to the windows package (and only if the semantics are exactly the same).

zx2c4

comment created time in 4 months

pull request commentmicrosoft/go-winio

Adapt to the API renewal of golang.org/x/sys/windows

I'm pushing to get this reverted from x/sys/windows. Let's hold this change in the meantime.

uztbt

comment created time in 4 months

CommitCommentEvent

issue commentmicrosoft/hcsshim

docker build freeze at exportLayer phase

I think we need to understand why os.RemoveAll is not returning. What version of Go is this?

tardyp

comment created time in 4 months

PR opened microsoft/opengcs

init: Close entropy-related fds

This is what happens when I don't code for 6 weeks. :)

+3 -0

0 comment

1 changed file

pr created time in 5 months

create barnchjstarks/opengcs

branch : entropy_fix

created branch time in 5 months

more