Use gbincore_unlocked for unprotected incore()

[cem]

Test Plan

Trivial follow-up to D25782.

[markj]

Hmm. There is one use of incore() which modifies the returned buf, in indir_trunc(). The comment right after states that some lock is held, but I can't see what it is. How does the update to the dependency list get synchronized?

[cem]

In D25790#571304, @markj wrote:

Hmm. There is one use of incore() which modifies the returned buf, in indir_trunc(). The comment right after states that some lock is held, but I can't see what it is. How does the update to the dependency list get synchronized?

I think they are synchronized under the global ump mutex in UFS, but I don't know. I don't think this revision changes that, though.

[markj]

In D25790#571313, @cem wrote:

In D25790#571304, @markj wrote:

Hmm. There is one use of incore() which modifies the returned buf, in indir_trunc(). The comment right after states that some lock is held, but I can't see what it is. How does the update to the dependency list get synchronized?

I think they are synchronized under the global ump mutex in UFS, but I don't know.

The per-mountpoint softdep lock is not held there (it is acquired a few lines below), and I don't think the mountpoint lock is either.

I don't think this revision changes that, though.

Indeed, just trying to understand if there is a bug here.

[cem]

In D25790#571333, @markj wrote:

In D25790#571313, @cem wrote:

I think they are synchronized under the global ump mutex in UFS, but I don't know.

The per-mountpoint softdep lock is not held there (it is acquired a few lines below), and I don't think the mountpoint lock is either.

Right; it looked like (in my quick scan) that we intentionally dropped the lock to run indir_trunc(). But my guess was/is any synchronization needed on the datastructure is performed under that lock before it is dropped. I don't really know SU that well.