I don't suppose we know if there's a single hanging read task (In which case, I'd blame the platform, unless some FileStream::Context consumer is reading an absurd amount of data at once) or multiple reads?

Unfortunately, this is just a utility class with a number of consumers.  There's only one ChromeOS-specific consumer (chromeos/dbus/pipe_reader.cc), but no way to tell if that's the relevant consumer here.

Re #2: Looking at the other threads in one of the reports, there is definitely a thread actively in Bus::ProcessAllIncomingDataIfAny(), which would hint at DBus pipe reader being the issue here.

CCing dbus owners, for potential dbus connection, per comments #2 and #3, though I'm certainly not convinced that's the responsible consumer here.  That having been said, tearing down network requests, and the network stack itself, should stop all network-stack activity, unless we're blocked on a single long read (In which case, the OS is probably to blame, unless we're reading from a particularly funky stream source).

Removing myself as an owner - I have no idea how to investigate ChromeOS crashes without a repro or a useful stack trace, and I don't consider a shutdown hang worth dropping everything to learn how to use ChromeOS crash dumps.

Re #4: No problem; thanks!

Probably, we should convert all PipeReader users to use base::TaskShutdownBehavior::CONTINUE_ON_SHUTDOWN to avoid blocking the shutdown.

Another possible option is modifying net::FileStream to abort the read() syscall when the FileStream object is destructed.

Moving this to OS>Systems (for lack of a better place to put these DBus calls)

From the //net peanut gallery, CONTINUE_ON_SHUTDOWN seems more sensible for this case, although we could revisit the abort if we found it comes up in other contexts. That's just a large-enough change that I'd be uncomfortable making it without having a lot of cross-platform stability monitoring for regressions, and I'm not sure folks have the bandwidth or drive for that :)

CONTINUE_ON_SHUTDOWN usually seems like a good idea to me too. :-P

PipeReader is used by DebugDaemonClient and LorgnetteManagerClient, both also in //chromeos/dbus. I'm not familiar with this code, but both of the classes look like they're already using CONTINUE_ON_SHUTDOWN in conjunction with PipeReader:

debug_daemon_client.cc:

 48 class PipeReaderWrapper : public base::SupportsWeakPtr<PipeReaderWrapper> {
 49  public:
 50   explicit PipeReaderWrapper(const DebugDaemonClient::GetLogsCallback& callback)
 51       : pipe_reader_(base::CreateTaskRunnerWithTraits(
 52             {base::MayBlock(),
 53              base::TaskShutdownBehavior::CONTINUE_ON_SHUTDOWN})),
 54         callback_(callback) {}

lorgnette_manager_client.cc:

 99     // Creates a pipe to read the scan data from the D-Bus service.
100     // Returns a write-side FD.
101     base::ScopedFD Start() {
102       DCHECK(!pipe_reader_.get());
103       DCHECK(!data_.has_value());
104       pipe_reader_ = std::make_unique<chromeos::PipeReader>(
105           base::CreateTaskRunnerWithTraits(
106               {base::MayBlock(),
107                base::TaskShutdownBehavior::CONTINUE_ON_SHUTDOWN}));

Hrm...So assume that's respected, I guess that PipeReaders aren't the issue.  Strange that this is only really showing up on ChromeOS.

Probably, the same thing is happening on all platforms, but reported only on Chrome OS?
AFAIK Chrome OS is the only platform which reports unsafe shutdown to the crash server.

We've been getting alerts on shutdown hangs on Windows in UDPSocketWin::SetDiffServCodePoint, which happens on the IOThread, at least.