Date: Sat, 2 Sep 2023 21:38:07 -0600 From: Warner Losh <imp@bsdimp.com> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Is there any plan for ZFS and timerfd updates on stable/14? Message-ID: <CANCZdfrDeR4txwLv%2BCkB7S_igqJkO2Cu3%2BMoJudGXgS=TnTVzA@mail.gmail.com> In-Reply-To: <20230903123028.4ffceb705824f86d2efc21e3@dec.sakura.ne.jp> References: <20230903123028.4ffceb705824f86d2efc21e3@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000ed779406046c1f25 Content-Type: text/plain; charset="UTF-8" On Sat, Sep 2, 2023, 9:30 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. > Yes. The timerfd ones are being finalized. I plan on committing them Tuesday after the long weekend. Warner Is there any plan to do so? At least, existing deadlocks should be > considered as SHOW-STOPPER and resolved. > > 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> > > --000000000000ed779406046c1f25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Sat, Sep 2, 2023, 9:30 PM Tomoaki AOKI <<a href= =3D"mailto:junchoon@dec.sakura.ne.jp">junchoon@dec.sakura.ne.jp</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex">Hi.<br> <br> There are discussions about deadlocks issue of ZFS on freebsd-current<br> ML, starting from [1] last month.<br> IIRC, at least some fixes (candidates?) are merged to main, but not yet<br> to stable/14.<br> <br> Upcoming (aleready released? or still rc3?) OpenZFS 2.2-release seems<br> to have most of them. So my 1st question is "Is there any plan to<br> import vendor/openzfs/zfs-2.2-release into stable/14 BEFORE BRANCHING<br> releng/14?<br> <br> And one more. timerfd is added at last-minutes BEFORE stable/14 is<br> branched, and already have not-yet-MFC'ed fixes [2], [3], [4] and<br> Differential revision D41600 on Phablicator [5] related to memory leaks<br> and locks. <br> Additionally, splitting out lib32 part to proper place is proposed<br> as D41640 [6].=C2=A0 Both [5] and [6] are accepted but not yet landed.<br> Also, D41641 [7] proposes namespace pollution adjustments. This can be<br> optional?<br> <br> Memory leaks and improper locks can lead system to security issues or<br> deadlocks, so it would be benefical if landed and MFC'ed BEFORE<br> releng/14 branches.<br></blockquote></div></div><div dir=3D"auto"><br></div= ><div dir=3D"auto">Yes. The timerfd ones are being finalized.=C2=A0 I plan = on committing them Tuesday after the long weekend.</div><div dir=3D"auto"><= br></div><div dir=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir= =3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Is there any plan to do so? At least, existing deadlocks should be<br> considered as SHOW-STOPPER and resolved.<br> <br> I myself am bitten by several deadlocks on poudriere full builds after<br> upgrading base from stable/13 to stable/14, finally finished with<br> increasing kern.maxvnodes after powercycle on each deadlock and<br> continue.<br> <br> <br> Thanks in advance!<br> <br> [1]<br> <a href=3D"https://lists.freebsd.org/archives/freebsd-current/2023-August/0= 04162.html" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.f= reebsd.org/archives/freebsd-current/2023-August/004162.html</a><br> <br> [2]<br> <a href=3D"https://cgit.freebsd.org/src/commit/?id=3D02f534b57f84d6f4f97c33= 7b05b383c8b3aaf18c" rel=3D"noreferrer noreferrer" target=3D"_blank">https:/= /cgit.freebsd.org/src/commit/?id=3D02f534b57f84d6f4f97c337b05b383c8b3aaf18c= </a><br> <br> [3]<br> <a href=3D"https://cgit.freebsd.org/src/commit/?id=3D5eab523053db79b4bd4f92= 6c7d7ac04444d9c1da" rel=3D"noreferrer noreferrer" target=3D"_blank">https:/= /cgit.freebsd.org/src/commit/?id=3D5eab523053db79b4bd4f926c7d7ac04444d9c1da= </a><br> <br> [4]<br> <a href=3D"https://cgit.freebsd.org/src/commit/?id=3Df4296cfb409a48de00bfa6= 0e76f686c2b031876f" rel=3D"noreferrer noreferrer" target=3D"_blank">https:/= /cgit.freebsd.org/src/commit/?id=3Df4296cfb409a48de00bfa60e76f686c2b031876f= </a><br> <br> [5] <a href=3D"https://reviews.freebsd.org/D41600" rel=3D"noreferrer norefe= rrer" target=3D"_blank">https://reviews.freebsd.org/D41600</a><br>; <br> [6] <a href=3D"https://reviews.freebsd.org/D41640" rel=3D"noreferrer norefe= rrer" target=3D"_blank">https://reviews.freebsd.org/D41640</a><br>; <br> [7] <a href=3D"https://reviews.freebsd.org/D41641" rel=3D"noreferrer norefe= rrer" target=3D"_blank">https://reviews.freebsd.org/D41641</a><br>; <br> -- <br> Tomoaki AOKI=C2=A0 =C2=A0 <<a href=3D"mailto:junchoon@dec.sakura.ne.jp" = target=3D"_blank" rel=3D"noreferrer">junchoon@dec.sakura.ne.jp</a>><br> <br> </blockquote></div></div></div> --000000000000ed779406046c1f25--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrDeR4txwLv%2BCkB7S_igqJkO2Cu3%2BMoJudGXgS=TnTVzA>