(lfs_curseg/lfs_nextseg in the superblock) using the wrong units.
These fields are for whatever reason the start addresses of segments
(measured in frags) rather than the segment numbers 0..n.
This only apparently affects dumping from a mounted fs; however, it
trashes the fs.
I would really, really like to have a static analysis tool that can
keep track of the units things are measured in, since fs code is full
of conversion macros and the macros are named inscrutable things like
"sntod" whose letters don't necessarily even correspond to the units
they convert. It is surprising that more of these are not wrong.
in blocks instead of frags, so use lfs_blkstofrags to correct it.
This code was instead multiplying by the block size divided by
DEV_BSIZE to get the number of disk blocks rather than the number of
frags. (I gather that originally these were the same, but they're not
necessarily any more.)
VFS_SYNC does not consider whether we are performing a force unmount or not,
and therefore it can wait for a while if the filesytstem is misbehaving.
Removing VFS_SYNC before VFS_UNMOUNT on forced unmount fixes the problem.
This should not cause harm as the VFS_SYNC seems just useless.
As noted by Chuck Silvers in
http://mail-index.netbsd.org/tech-kern/2015/07/13/msg019156.html
- Nothing seems to prevent vnodes from getting dirty again after VFS_SYNC call.
- Filesystems do flush data through vflush() in VFS_UNMOUNT anyway.
As a consequence, the VFS_SYNC call in do_unmount() could probably be
completely removed. But since such a change is quite dangerous, we just
remove it in the case of forced unmounts, which are situations where
the risk of data loss is known to the operator.
Substitution commands might contain a newline in the replacement pattern
(escaped with a backslash before it), causing patch's understanding of
the state the ed child process is in to diverge from reality. This can
lead to patch unwillingly feeding '!' (execute shell command) lines to
ed. Finding out how to do this is left as an exercise to the reader.
XXX: pullup-7
- don't confuse between ELF flags and proc flags. Introduce the proc-
specific P_PAX_ASLR, P_PAX_MPROTECT and P_PAX_GUARD flags.
- introduce pax_setup_elf_flags(), which takes as argument the PaX flag
of the ELF PaX note section, and which sets the proc flag as
appropriate. Also introduce a couple of other functions used for that
purpose.
- modify pax_aslr_active(), and all the other similar pieces of code, so
that it checks the proc flag directly, without extra ELF computation
In addition to making PaX clearer, the combination of these changes fixes
the following bug: if a non-PaX'ed process is launched, and then someone
sets security.pax.{aslr,mprotect,segvguard}.global=1, the process becomes
PaX'ed while its address space hasn't been randomized, which is not likely
to be a good idea.
Now, only the proc flag is checked at runtime, which means the process's
PaX status won't be altered during the execution.
Also:
- declare PAX_DPRINTF, makes it more readable
- fix a typo in exec_elf.h
dholland