Page MenuHomeFreeBSD

fsck_ufs: fix background fsck in preen mode
ClosedPublic

Authored by rew on Jun 23 2021, 10:26 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 8, 10:06 PM
Unknown Object (File)
Fri, Nov 8, 7:16 PM
Unknown Object (File)
Fri, Nov 8, 3:32 PM
Unknown Object (File)
Fri, Nov 8, 12:22 PM
Unknown Object (File)
Fri, Nov 8, 5:46 AM
Unknown Object (File)
Fri, Nov 8, 2:09 AM
Unknown Object (File)
Tue, Nov 5, 10:33 AM
Unknown Object (File)
Sat, Oct 26, 6:34 AM

Details

Summary

Background checks are only allowed for mounted filesystems - don't try
to open the device for writing if the device is mounted.

The setup() routine initializes fswritefd and already handles the above
condition.

It appears that fswritefd is unused before the setup()
routine, so I think we can just remove it here.

While here, remove a debugging printf that's commented out.

PR: 256746
Fixes: 5cc52631b3b88dfc36d8049dc8bece8573c5f9af

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

rew requested review of this revision.Jun 23 2021, 10:26 PM

As far as I can tell, gjournal_check assumes fswritefd is already open, so this is no good.

This revision now requires changes to proceed.Jun 24 2021, 5:51 AM

yea, you're right - sbdirty() uses fswritefd. Thanks for pointing it out.

  • open the device for writing if the background flag is not set.

The whole handling of fsreadfd and fswritefd makes me itch. They are opened and closed at random places, and some places test for them being < 0, but they are not statically initialized to -1 nor set to -1 when closed. I would honestly not be surprised if there were some weird combination of options that caused data blocks to be written to stdin rather than the disk.

Not to mention that fsreadfd can be opened as many as three times, with the descriptor leaked twice; this is pretty harmless, but it shows to what extent the code is a mess.

Not to mention that fsreadfd can be opened as many as three times, with the descriptor leaked twice;

I count four, leaked once - where's the second one?
open(fsreadfd) called @ Line 276, 296, 343 (sbin/fsck_ffs/main.c) and Line 130 (sbin/fsck_ffs/setup.c).
@line 276, is a block of code that opens fsreadfd, closes it, and exits.
@line 296, these ones could be leaked here, I'll update the revision to address that.
@line 343, opens fsreadfd and either exits or closes fsreadfd and continues on.

@line 130 (sbin/fsck_ffs/setup.c): fsreadfd is opened by setup() until program exit.

I count two times where fswritefd is opened;
Line 298 (sbin/fsck_ffs/main.c): fswritefd could be leaked here, I'll update the revision.
Line 175 (sbin/fsck_ffs/setup.c): fswritefd is opened by setup() and used till program exit

Maybe it'd be nice if the read/write fd's were handled by libufs, but then again maybe not - I couldn't say without studying the code a bit more.

Maybe it'd be nice if the read/write fd's were handled by libufs, but then again maybe not - I couldn't say without studying the code a bit more.

There was an earlier attempt to use libufs in fsck, but fsck needs more capabilities than libufs supports, sofsck now just handles all the I/O itself.

Close fsreadfd and fswritefd file descriptors even when not checking a
gjournaled filesystem (as they'll be opened again when needed).

Latest change looks good.

This revision was not accepted when it landed; it landed in state Needs Review.Jul 11 2021, 8:58 PM
This revision was automatically updated to reflect the committed changes.