FreeBSD source tree https://cgit-dev.freebsd.org/src-test/atom?h=main 2020-11-28T12:12:51Z 2020-11-28T12:12:51Z Konstantin Belousov kib@FreeBSD.org 2020-11-28T12:12:51Z urn:sha1:cd8537910406e68d4719136a5b0cf6d23bb1b23b Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys. Make b_pages[] array in struct buf flexible. Size b_pages[] for buffer cache buffers exactly to atop(maxbcachebuf) (currently it is sized to atop(MAXPHYS)), and b_pages[] for pbufs is sized to atop(maxphys) + 1. The +1 for pbufs allow several pbuf consumers, among them vmapbuf(), to use unaligned buffers still sized to maxphys, esp. when such buffers come from userspace (*). Overall, we save significant amount of otherwise wasted memory in b_pages[] for buffer cache buffers, while bumping MAXPHYS to desired high value. Eliminate all direct uses of the MAXPHYS constant in kernel and driver sources, except a place which initialize maxphys. Some random (and arguably weird) uses of MAXPHYS, e.g. in linuxolator, are converted straight. Some drivers, which use MAXPHYS to size embeded structures, get private MAXPHYS-like constant; their convertion is out of scope for this work. Changes to cam/, dev/ahci, dev/ata, dev/mpr, dev/mpt, dev/mvs, dev/siis, where either submitted by, or based on changes by mav. Suggested by: mav (*) Reviewed by: imp, mav, imp, mckusick, scottl (intermediate versions) Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D27225 2020-11-05T20:52:49Z Konstantin Belousov kib@FreeBSD.org 2020-11-05T20:52:49Z urn:sha1:f10845877e962a7dcdc4cf9b9614bdfcdac46d59 This ensures that no writes are pending in memory, either metadata or user data, but not including dirty pages not yet converted to fs writes. Only filesystems declared local are suspended. Note that this does not guarantee absence of the metadata errors or leaks if resume is not done: for instance, on UFS unlinked but opened inodes are leaked and require fsck to gc. Reviewed by: markj Discussed with: imp Tested by: imp (previous version), pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D27054 2020-09-08T23:38:49Z Konstantin Belousov kib@FreeBSD.org 2020-09-08T23:38:49Z urn:sha1:fbf2a778760f24565eab950ced3e2ad1df4cf844 Future changes would require additional initialization of OBJT_PHYS objects, and vm_object_allocate() is not suitable for it. Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D24652 2020-09-01T21:45:08Z Mateusz Guzik mjg@FreeBSD.org 2020-09-01T21:45:08Z urn:sha1:6c7cae4a73b883ec0410e882bb56622c3090592c 2020-08-19T02:51:17Z Mateusz Guzik mjg@FreeBSD.org 2020-08-19T02:51:17Z urn:sha1:7ad2a82da2b51b8c803c82a460e513f58f5a1737 Most consumers pass NULL. 2020-06-10T22:30:32Z Konstantin Belousov kib@FreeBSD.org 2020-06-10T22:30:32Z urn:sha1:4149c6a3ecd5526a6819443c8cfd17cc77bcbb3a It seems that second call does not add any useful state change for all implemented timecounters. Discussed with: bde Sponsored by: The FreeBSD Foundation MFC after: 3 weeks 2020-05-28T08:20:16Z Roger Pau Monné royger@FreeBSD.org 2020-05-28T08:20:16Z urn:sha1:06592d60f00c39a465454df203fcabbdefadb57f If there's no data to read from xenstore short-circuit xctrl_on_watch_event to return early, there's no reason to continue since the lack of data would prevent matching against any known event type. Sponsored by: Citrix Systems R&D MFC with: r352925 MFC after: 1 week 2020-05-28T08:19:13Z Roger Pau Monné royger@FreeBSD.org 2020-05-28T08:19:13Z urn:sha1:3e7df58df20ce49994edd2be2be0e2bce991c177 The correct type to use to represent disk sectors is blkif_sector_t (which is an uint64_t underneath). This avoid truncation of the disk size calculation when resizing on i386, as otherwise the calculation of d_mediasize in xbd_connect is truncated to the size of unsigned long, which is 32bits on i386. Note this issue didn't affect amd64, because the size of unsigned long is 64bits there. Sponsored by: Citrix Systems R&D MFC after: 1 week 2020-05-20T11:01:10Z Roger Pau Monné royger@FreeBSD.org 2020-05-20T11:01:10Z urn:sha1:b5ba8a0f32b1094f172699abf9bf70779a2158d5 Fix returning from xenstore device with locks held, which triggers the following panic: # cat /dev/xen/xenstore ^C userret: returning with the following locks held: exclusive sx evtchn_ringc_sx (evtchn_ringc_sx) r = 0 (0xfffff8000650be40) locked @ /usr/src/sys/dev/xen/evtchn/evtchn_dev.c:262 Note this is not a security issue since access to the device is limited to root by default. Sponsored by: Citrix Systems R&D MFC after: 1 week 2020-04-17T18:34:49Z Kyle Evans kevans@FreeBSD.org 2020-04-17T18:34:49Z urn:sha1:23d5326823c740f2ddcd3268216d0a59b374457c A later change, currently being iterated on in D24459, will in-fact change the lock type to an sx so that TTY drivers can sleep on it if they need to. Committing this ahead of time to make the review in question a little more palatable. tty_lock_assert() is unfortunately still needed for now in two places to make sure that the tty lock has not been recursed upon, for those scenarios where it's supplied by the TTY driver and possibly a mutex that is allowed to recurse. Suggested by: markj