Re: Is there any plan for ZFS and timerfd updates on stable/14?
Date: Sun, 17 Sep 2023 15:09:13 UTC
Hello AOKI-san Thanks for keeping on top of this issue. I had some, but not all of these, staged in my testing tree. Testing worked on it a while ago. I've gone ahead and pushed that branch just now. I've staged the rest of these and will push them after some light testing. My usual workflow is disrupted by travel to EuroBSDcon 2023 and having too much fun here seeing old friends. Please let me know if there's anything else. There is one test regression that needs to be sorted out to get back to where we were before my push. I hope to have that done by the end of next week since I'm taking a few days off after the conference to see a little of Portugal. Warner On Sun, Sep 17, 2023 at 1:39 AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote: > On Sun, 3 Sep 2023 13:33:28 +0900 > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote: > > > On Sat, 2 Sep 2023 22:47:53 -0500 > > Jake Freeland <jake@technologyfriends.net> wrote: > > > > > On Sat, Sep 2, 2023 at 10:40 PM Warner Losh <imp@bsdimp.com> wrote: > > > > > > > > > > > > > > > On Sat, Sep 2, 2023, 9:36 PM Jake Freeland < > jake@technologyfriends.net> > > > > wrote: > > > > > > > >> On Sat, Sep 2, 2023 at 10:31 PM Tomoaki AOKI < > junchoon@dec.sakura.ne.jp> > > > >> wrote: > > > >> > > > >>> Hi. > > > >>> > > > >>> There are discussions about deadlocks issue of ZFS on > freebsd-current > > > >>> ML, starting from [1] last month. > > > >>> IIRC, at least some fixes (candidates?) are merged to main, but > not yet > > > >>> to stable/14. > > > >>> > > > >>> Upcoming (aleready released? or still rc3?) OpenZFS 2.2-release > seems > > > >>> to have most of them. So my 1st question is "Is there any plan to > > > >>> import vendor/openzfs/zfs-2.2-release into stable/14 BEFORE > BRANCHING > > > >>> releng/14? > > > >>> > > > >>> And one more. timerfd is added at last-minutes BEFORE stable/14 is > > > >>> branched, and already have not-yet-MFC'ed fixes [2], [3], [4] and > > > >>> Differential revision D41600 on Phablicator [5] related to memory > leaks > > > >>> and locks. > > > >>> Additionally, splitting out lib32 part to proper place is proposed > > > >>> as D41640 [6]. Both [5] and [6] are accepted but not yet landed. > > > >>> Also, D41641 [7] proposes namespace pollution adjustments. This > can be > > > >>> optional? > > > >>> > > > >>> Memory leaks and improper locks can lead system to security issues > or > > > >>> deadlocks, so it would be benefical if landed and MFC'ed BEFORE > > > >>> releng/14 branches. > > > >>> > > > >>> Is there any plan to do so? At least, existing deadlocks should be > > > >>> considered as SHOW-STOPPER and resolved. > > > >>> > > > >> > > > >> The plan is to get all of those patches in before releng/14.0, I > believe. > > > >> > > > >> What are your thoughts, Warner? > > > >> > > > > > > > > Sounds like the reviews are done or nearly so. I've not had time to > look > > > > closely to be sure... I'd planned on making time Tuesday morning. > > > > > > > > > > Yes. All reviews are good to go. > > > > > > Jake Freeland > > > > Glad to know. Thanks! > > Looking forward to see them landed / MFC'ed before releng/14 branches. > > > > Regards. > > > > > > > > > > > > > > > > Warner > > > > > > > > > > > >> Thanks, > > > >> Jake Freeland > > > >> > > > >> > > > >>> > > > >>> I myself am bitten by several deadlocks on poudriere full builds > after > > > >>> upgrading base from stable/13 to stable/14, finally finished with > > > >>> increasing kern.maxvnodes after powercycle on each deadlock and > > > >>> continue. > > > >>> > > > >>> > > > >>> Thanks in advance! > > > >>> > > > >>> [1] > > > >>> > > > >>> > https://lists.freebsd.org/archives/freebsd-current/2023-August/004162.html > > > >>> > > > >>> [2] > > > >>> > > > >>> > https://cgit.freebsd.org/src/commit/?id=02f534b57f84d6f4f97c337b05b383c8b3aaf18c > > > >>> > > > >>> [3] > > > >>> > > > >>> > https://cgit.freebsd.org/src/commit/?id=5eab523053db79b4bd4f926c7d7ac04444d9c1da > > > >>> > > > >>> [4] > > > >>> > > > >>> > https://cgit.freebsd.org/src/commit/?id=f4296cfb409a48de00bfa60e76f686c2b031876f > > > >>> > > > >>> [5] https://reviews.freebsd.org/D41600 > > > >>> > > > >>> [6] https://reviews.freebsd.org/D41640 > > > >>> > > > >>> [7] https://reviews.freebsd.org/D41641 > > > >>> > > > >>> -- > > > >>> Tomoaki AOKI <junchoon@dec.sakura.ne.jp> > > > > -- > > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> > > Hi. Thanks for your hard work on it. > > I could confirm commits to main as below, but they are not yet > MFC'ed/MFS'/ed. > It would be nice these commits to be incorporated at worst on first RC. > Any plans for MFC and following MFS? > > commit 02f534b57f84d6f4f97c337b05b383c8b3aaf18c > timerfd: fix up a memory leak and missing locking > > commit 5eab523053db79b4bd4f926c7d7ac04444d9c1da > timerfd: compute fflags before calling falloc > > commit f4296cfb409a48de00bfa60e76f686c2b031876f > timerfd: convert timerfd_list_lock from sx to mtx > > commit a1f506156c4db885d3cc177c93e9c8a28d535d30 > timerfd: Define a locking regime > > commit 918966a27479b4fb7c4c8999c4926d83c2c081e5 > timerfd: Relocate 32-bit compat code > > commit fb5daae920bae84e3eec8175bf9e46304c3b2ae6 > timerfd: Namespace pollution adjustments > > > Note that first 3 commits are authord/committed by mjg@. > These are all I could confirm landed with commit histories of > sys/kern/sys_timerfd.c and sys/sys/timerfd.c, excluding > already-in-stable/14 one. > > I've found a related commit to sys/compat/linux/linux_event.c but > intentionally excluded it, as it's already MFC'ed and MFS'ed. > > And I found another request on dev-commits-src-main ML archive [1], > without any reply. > > Attached is the hand-merged patch to cherry pick them to stable/14, > created before last 3 commits landed on main. HTH. > > [1] > > https://lists.freebsd.org/archives/dev-commits-src-main/2023-September/018407.html > > Regards. > > -- > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> >