Good point about the path resolution.  In theory there is the possibility that the content of / is not cached and so finding /sys could block.

In practice I highly doubt it, since / is pounded on continuously (even assuming it's not explicitly cached permanently---Gwendal would you know?)

For the rest of the path, I am not sure but most likely /sys does not use inodes on the disk.  I'll need to check this.

For the file itself, there is no blocking.  Open/read/close are implemented as functions which do very little computation and return without the possibility of blocking.  (This is true for most if not all /sys entries, including those in chromeos-low_mem).

Thanks for the detail, Luigi.  If we can confirm that resolving paths under
/sys is non-blocking then I would suggest that we add an explicit helper
function in //base, which prefixes a supplied path with '/sys/kernel/' and
applies ScopedAllowBlocking internally, so that any future call-sites can
use /sys/kernel paths and not have to add further exceptions to the
ScopedAllowBlocking rules.

Yes I confirm that sysfs is implemented by kernelfs and all directories are in RAM.

There is a theoretical possibility of blocking on reading /, but when I ask other  kernel folks if this can happen, they just laugh at me.  So I think this is "proof by humiliation" that it won't happen :)  ("proof by ridicule"?)

Maybe you can change the subject of this bug to reflect the proposed change in #2.

Mmm I shouldn't have said that they laugh "at me".  They really don't.  They just laugh.  We're a bunch of really fun-loving folks.  http://dilbert.com/strip/1991-09-27

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot