FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2023-11-27T05:23:58Z 2023-11-27T05:23:58Z Warner Losh imp@FreeBSD.org 2023-11-24T07:45:36Z urn:sha1:0b8224d1cc9dc6c9778ba04a75b2c8d47e5d7481 We've ifdef'd out the copyright strings for some time now. Go ahead and remove the ifdefs. Plus whatever other detritis was left over from other recent removals. These copyright strings are present in the comments and are largely from CSRG's attempt at adding their copyright to every binary file (which modern interpretations of the license doesn't require). Sponsored by: Netflix 2023-11-27T05:23:29Z Warner Losh imp@FreeBSD.org 2023-11-23T17:21:37Z urn:sha1:51e16cb8fc536913f490ac6bc9c17e92ebd0411b Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl script. Sponsored by: Netflix 2023-09-25T14:54:56Z John Baldwin jhb@FreeBSD.org 2023-09-25T14:54:56Z urn:sha1:eba230afba4932f02a1ca44efc797cf7499a5cb0 These do not use __FBSDID but instead use bare char arrays. Reviewed by: imp, emaste Differential Revision: https://reviews.freebsd.org/D41957 2022-07-31T05:51:38Z Kirk McKusick mckusick@FreeBSD.org 2022-07-31T05:44:01Z urn:sha1:b21582ee03ec1394e08173e276df311979856e54 Rather than trying to shoehorn flags into the requested superblock address, create a separate flags parameter to the ffs_sbget() function in sys/ufs/ffs/ffs_subr.c. The ffs_sbget() function is used both in the kernel and in user-level utilities through export to the sbget() function in the libufs(3) library (see sbget(3) for details). The kernel uses ffs_sbget() when mounting UFS filesystems, in the glabel(8) and gjournal(8) GEOM utilities, and in the standalone library used when booting the system from a UFS root filesystem. The ffs_sbget() function reads the superblock located at the byte offset specified by its sblockloc parameter. The value UFS_STDSB may be specified for sblockloc to request that the standard location for the superblock be read. The two existing options are now flags: UFS_NOHASHFAIL will note if the check hash is wrong but will still return the superblock. This is used by the bootstrap code to give the system a chance to come up so that fsck can be run to correct the problem. UFS_NOMSG indicates that superblock inconsistency error messages should not be printed. It is used by programs like fsck that want to print their own error message and programs like glabel(8) that just want to know if a UFS filesystem exists on a partition. One additional flag is added: UFS_NOCSUM causes only the superblock itself to be returned, but does not read in any auxiliary data structures like the cylinder group summary information. It is used by clients like glabel(8) that just want to check for possible filesystem types. Using UFS_NOCSUM skips the superblock checks for csum data which allows superblocks that have corrupted csum data to be read and used. The validate_sblock() function checks that the superblock has not been corrupted in a way that can crash or hang the system. Unless the UFS_NOMSG flag is specified, it will print out any errors that it finds. Prior to this commit, validate_sblock() returned as soon as it found an inconsistency so would print at most one message. It now does all its checks so when UFS_NOMSG has not been specified will print out everything that it finds inconsistent. Sponsored by: The FreeBSD Foundation 2021-02-21T09:38:21Z Konstantin Belousov kib@FreeBSD.org 2021-02-18T13:43:58Z urn:sha1:d485c77f203fb0f4cdc08dea5ff81631b51d8809 Make sys/buf.h, sys/pipe.h, sys/fs/devfs/devfs*.h headers usable in userspace, assuming that the consumer has an idea what it is for. Unhide more material from sys/mount.h and sys/ufs/ufs/inode.h, sys/ufs/ufs/ufsmount.h for consumption of userspace tools, with the same caveat. Remove unacceptable hack from usr.sbin/makefs which relied on sys/buf.h being unusable in userspace, where it override struct buf with its own definition. Instead, provide struct m_buf and struct m_vnode and adapt code to use local variants. Reviewed by: mckusick Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D28679 2020-04-04T00:56:56Z Kirk McKusick mckusick@FreeBSD.org 2020-04-04T00:56:56Z urn:sha1:33ceb489d33e71b81adbd12bded321ad4486e42a utilities so that they will compile with -fno-common. Started by: Kyle Evans (kevans) Reviewed by: Kyle Evans (kevans) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D24210 2018-12-06T00:09:39Z Kirk McKusick mckusick@FreeBSD.org 2018-12-06T00:09:39Z urn:sha1:fb14e73cb4062d7272ce6183d748adedd868906b superblock has a check-hash error, an error message noting the superblock check-hash failure is printed and the mount fails. The administrator then runs fsck to repair the filesystem and when successful, the filesystem can once again be mounted. This approach fails if the filesystem in question is a root filesystem from which you are trying to boot. Here, the loader fails when trying to access the filesystem to get the kernel to boot. So it is necessary to allow the loader to ignore the superblock check-hash error and make a best effort to read the kernel. The filesystem may be suffiently corrupted that the read attempt fails, but there is no harm in trying since the loader makes no attempt to write to the filesystem. Once the kernel is loaded and starts to run, it attempts to mount its root filesystem. Once again, failure means that it breaks to its prompt to ask where to get its root filesystem. Unless you have an alternate root filesystem, you are stuck. Since the root filesystem is initially mounted read-only, it is safe to make an attempt to mount the root filesystem with the failed superblock check-hash. Thus, when asked to mount a root filesystem with a failed superblock check-hash, the kernel prints a warning message that the root filesystem superblock check-hash needs repair, but notes that it is ignoring the error and proceeding. It does mark the filesystem as needing an fsck which prevents it from being enabled for writing until fsck has been run on it. The net effect is that the reboot fails to single user, but at least at that point the administrator has the tools at hand to fix the problem. Reported by: Rick Macklem (rmacklem@) Discussed with: Warner Losh (imp@) Sponsored by: Netflix 2018-11-14T00:21:52Z Kirk McKusick mckusick@FreeBSD.org 2018-11-14T00:21:52Z urn:sha1:07436eeb490ec89202b2d484afca4eadf348cb88 Pointy-hat to: mckusick 2018-11-13T23:44:27Z Gleb Smirnoff glebius@FreeBSD.org 2018-11-13T23:44:27Z urn:sha1:d4f7db47642344bc7b746a9571d08b0fb4d8c9dd 2018-06-11T20:38:30Z Warner Losh imp@FreeBSD.org 2018-06-11T20:38:30Z urn:sha1:37d6a8f458ffe2e20f646b8c59b6c45a0a5d13ab The size limits came from a flawed understanding of dump records. The real issue was that dump was bogusly interpreting c_count sometimes. r334978 fixes that.