Re: svn commit: r367695 - in head/sys: kern sys
On Fri, Nov 20, 2020 at 3:00 AM John Baldwin wrote: > On 11/18/20 8:52 PM, Mark Johnston wrote: > > There are some technical issues around Phabricator that would need to be > > ironed out before this is really doable. For me, the main one is that > > email notifications are all-or-nothing: I would very much like to be > > able to get email for each new review without automatically being > > subscribed. > > That would indeed be interesting. In all of the Projects I've worked > with using GH or e-mail, it does seem to be all-or-nothing if you are > on the notify list. > > Hmm, looks like you can create a Herald rule to do this btw. Let's > see if this works: > > https://reviews.freebsd.org/H138 Hmm, this reminds me there is an item on my TODO list: complete the setup of dev-reviews@ list: https://lists.freebsd.org/mailman/listinfo/dev-reviews The purpose of it is exactly to let people (only) subscribe to the newly created review. And thanks for your rule and I just realized there is a "mailing list" type of Phabricator user, Let's see if this works: https://reviews.freebsd.org/H139 Best, Li-Wen ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r367695 - in head/sys: kern sys
On 11/18/20 8:52 PM, Mark Johnston wrote: > On Wed, Nov 18, 2020 at 03:37:36PM -0800, John Baldwin wrote: >> On 11/18/20 2:16 PM, Mateusz Guzik wrote: >>> On 11/17/20, John Baldwin wrote: On 11/14/20 11:22 AM, Mateusz Guzik wrote: >>> Interested parties can check the consumer (also seen in the diff) to >>> see this is for consistency. I don't think any comments are warranted >>> in the header. >> >> I did read the consumer, and there didn't seem tremendous value in the >> extra line there. >> These changes would benefit from review. >>> >>> I don't think it's feasible to ask for review for everything lest it >>> degardes to rubber stamping and I don't think this change warranted >>> it, regardless of the cosmetic issues which can always show up. >> >> That is not consistent with the direction the project is moving. If you >> check the commit logs of other high-volume committers such as markj@, >> kib@, or myself, you will find that a substantial number of those commits >> are reviewed (typically in phabricator) without preventing us from >> making useful progress. Also, while the previous core did not mandate >> reviews, we moved closer to it when the Pre-Commit Review chapter was >> added to the Committer's Guide: >> >> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html >> >> In the related thread on developers@ we indicated that while weren't yet >> making pre-commit review mandatory, we collectively want to move in that >> direction. > > With regard to the future direction of src development, I would propose > a middle ground. Most, if not all, changes should get a Phabricator > review. There should be some minimum period between creation of that > review and a commit. The developer should make some effort to cc active > committers to the code. Some areas of the tree will have stricter > rules, but in general absence of feedback means that it's ok to commit. > Exceptions might apply to build fixes, etc.. This still imposes some > friction on the development process, but I have trouble seeing why > someone's contibution might be gated on their ability to commit at a > moment's notice. Mmm, I think I agree fully with this, and that perhaps the terminology is not clear as different folks have different perceptions of what "mandatory reviews" means perhaps. I know that some projects I work with have a fully "mandatory" requirement (OpenSSL seems to), and others have some exceptions (the "obvious" rule in FSF projects like GDB which the note in the committers guide does include a variant of). It is true though that in practice sometimes changes just time out due to lack of review (the OCF refactor is one of those in which I was able to get some partial review of some pieces or some of the concepts, but not the change as a whole). I do think we want to be in a place where we do at least seek review for most changes with an understanding that a change can "timeout" on review and be merged without always having review approval. > There are some technical issues around Phabricator that would need to be > ironed out before this is really doable. For me, the main one is that > email notifications are all-or-nothing: I would very much like to be > able to get email for each new review without automatically being > subscribed. That would indeed be interesting. In all of the Projects I've worked with using GH or e-mail, it does seem to be all-or-nothing if you are on the notify list. Hmm, looks like you can create a Herald rule to do this btw. Let's see if this works: https://reviews.freebsd.org/H138 -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r367695 - in head/sys: kern sys
On Wed, Nov 18, 2020 at 03:37:36PM -0800, John Baldwin wrote: > On 11/18/20 2:16 PM, Mateusz Guzik wrote: > > On 11/17/20, John Baldwin wrote: > >> On 11/14/20 11:22 AM, Mateusz Guzik wrote: > > Interested parties can check the consumer (also seen in the diff) to > > see this is for consistency. I don't think any comments are warranted > > in the header. > > I did read the consumer, and there didn't seem tremendous value in the > extra line there. > > >> These changes would benefit from review. > >> > > > > I don't think it's feasible to ask for review for everything lest it > > degardes to rubber stamping and I don't think this change warranted > > it, regardless of the cosmetic issues which can always show up. > > That is not consistent with the direction the project is moving. If you > check the commit logs of other high-volume committers such as markj@, > kib@, or myself, you will find that a substantial number of those commits > are reviewed (typically in phabricator) without preventing us from > making useful progress. Also, while the previous core did not mandate > reviews, we moved closer to it when the Pre-Commit Review chapter was > added to the Committer's Guide: > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html > > In the related thread on developers@ we indicated that while weren't yet > making pre-commit review mandatory, we collectively want to move in that > direction. So, I personally don't really like the idea of mandatory reviews. It's a drag, especially for volunteers. It works ok in areas that have active maintainers, but lots of FreeBSD does not. For instance, pretty much every change to sys/vm gets a review, but only by convention. It's not perfect, and in particular it discourages me from making some changes both because getting review is a hassle and because I don't want to spam other VM developers (especially volunteers) with minor things. If all changes require some sort of sign-off, even if it's effectively rubber-stamping, I fear it'll discourage a lot of small, worthwhile contributions while also burning out reviewers. Meanwhile, we had issues for a long time where changes to the CSPRNG code were blocked for lack of review, and we have some problems with the LOCALBASE changes despite review. For better or worse, FreeBSD has no sole technical authority to direct development. More than many other projects, we rely on consensus and more broadly the ability of developers to engage with each other even when their communication styles differ. Since Phabricator was introduced it's been a lot easier to get feedback on patches, and non-committers have a better vehicle to propose patches. No edict was needed for that. On the other hand, FCP doesn't seem to have been successful. I suspect that mailing lists are sufficient for the same purpose that FCP is for; if someone doesn't care to socialize some changes on the lists, it's unlikely that they'll do so in a FCP, and because FreeBSD has no one who can really mandate development process, FCP doesn't buy us much. I tried adding RELNOTES so that it's easier for us to advertise our work to users; it's worked so-so, and I suspect that a lot of developers don't care about advertising their work or just don't know about RELNOTES. Our development processes end up being largely dictated by social norms, which are influenced by the most prolific committers. Mateusz is making a lot of commits to the kernel without any review. Most other committers would try to get a review for similar changes. For what it's worth I personally trust Mateusz to make well-reasoned changes, and to own his bugs. He does regularly ask for review and testing and I don't spend as much time as I should on his reviews. The problem, though, is the default assumption that most changes are not worth reviewing at all because they're small, mechanical, no one cares, whatever. It's worth soliciting review if only so that at least one other person has an idea of what's changing in the tree, because there _will_ come a time when it helps that person make changes of their own, or find a bug. Even if a reviewer doesn't deeply understand a diff, they might suggest stylistic changes that make the code more readable, or comment on related code in a way that's useful later. Similarly, verbose commit logs can seem pointless but are a huge help down the road. I know this is a common observation but it comes up all the time for me. With regard to the future direction of src development, I would propose a middle ground. Most, if not all, changes should get a Phabricator review. There should be some minimum period between creation of that review and a commit. The developer should make some effort to cc active committers to the code. Some areas of the tree will have stricter rules, but in general absence of feedback means that it's ok to commit. Exceptions might apply to build fixes, etc.. This still imposes som
Re: svn commit: r367695 - in head/sys: kern sys
On 11/19/20, John Baldwin wrote: > On 11/18/20 2:16 PM, Mateusz Guzik wrote: >> On 11/17/20, John Baldwin wrote: >>> On 11/14/20 11:22 AM, Mateusz Guzik wrote: >> Interested parties can check the consumer (also seen in the diff) to >> see this is for consistency. I don't think any comments are warranted >> in the header. > > I did read the consumer, and there didn't seem tremendous value in the > extra line there. > One thing to note is that there are more thing to batch than currently implemented, meaning the established pattern is going get more users. With everyone implementing the same routines, even if nops, it is pretty clear what's going on. In contrast if random calls are missing the reader is left wondering if there is a bug. Either way I see no reason to either comment add a comment in the header nor to remove the nop func. >>> These changes would benefit from review. >>> >> >> I don't think it's feasible to ask for review for everything lest it >> degardes to rubber stamping and I don't think this change warranted >> it, regardless of the cosmetic issues which can always show up. > > That is not consistent with the direction the project is moving. If you > check the commit logs of other high-volume committers such as markj@, > kib@, or myself, you will find that a substantial number of those commits > are reviewed (typically in phabricator) without preventing us from > making useful progress. Also, while the previous core did not mandate > reviews, we moved closer to it when the Pre-Commit Review chapter was > added to the Committer's Guide: > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html > > In the related thread on developers@ we indicated that while weren't yet > making pre-commit review mandatory, we collectively want to move in that > direction. > If you exclude bite-size commits, you will see I am getting reviews for thing which are outside of my work area or which include design choices. Past that other people keep committing without reviews anyway. That said, it may be this patch indeed should have been reviewed, but as it is I don't think this is the case. -- Mateusz Guzik ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r367695 - in head/sys: kern sys
On Wed, 2020-11-18 at 15:37 -0800, John Baldwin wrote: > On 11/18/20 2:16 PM, Mateusz Guzik wrote: > > On 11/17/20, John Baldwin wrote: > > > On 11/14/20 11:22 AM, Mateusz Guzik wrote: > > > > Interested parties can check the consumer (also seen in the diff) > > to > > see this is for consistency. I don't think any comments are > > warranted > > in the header. > > I did read the consumer, and there didn't seem tremendous value in > the > extra line there. > > > > These changes would benefit from review. > > > > > > > I don't think it's feasible to ask for review for everything lest > > it > > degardes to rubber stamping and I don't think this change warranted > > it, regardless of the cosmetic issues which can always show up. > > That is not consistent with the direction the project is moving. If > you > check the commit logs of other high-volume committers such as markj@, > kib@, or myself, you will find that a substantial number of those > commits > are reviewed (typically in phabricator) without preventing us from > making useful progress. Also, while the previous core did not > mandate > reviews, we moved closer to it when the Pre-Commit Review chapter was > added to the Committer's Guide: > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html > > In the related thread on developers@ we indicated that while weren't > yet > making pre-commit review mandatory, we collectively want to move in > that > direction. > Yeah, the direction the project is moving is to drive away the few remaining prolific contributors with policies that take all the satisfaction out of working on freebsd. There's a reason I've gone from being in the top ten commiters list in 2019 to having around a dozen commits in 2020. (Harrison Bergeron lives, it seems, but the world has so many more Diana Moon Glampers to counter with.) -- Ian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r367695 - in head/sys: kern sys
On 11/18/20 2:16 PM, Mateusz Guzik wrote: > On 11/17/20, John Baldwin wrote: >> On 11/14/20 11:22 AM, Mateusz Guzik wrote: > Interested parties can check the consumer (also seen in the diff) to > see this is for consistency. I don't think any comments are warranted > in the header. I did read the consumer, and there didn't seem tremendous value in the extra line there. >> These changes would benefit from review. >> > > I don't think it's feasible to ask for review for everything lest it > degardes to rubber stamping and I don't think this change warranted > it, regardless of the cosmetic issues which can always show up. That is not consistent with the direction the project is moving. If you check the commit logs of other high-volume committers such as markj@, kib@, or myself, you will find that a substantial number of those commits are reviewed (typically in phabricator) without preventing us from making useful progress. Also, while the previous core did not mandate reviews, we moved closer to it when the Pre-Commit Review chapter was added to the Committer's Guide: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pre-commit-review.html In the related thread on developers@ we indicated that while weren't yet making pre-commit review mandatory, we collectively want to move in that direction. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r367695 - in head/sys: kern sys
On 11/17/20, John Baldwin wrote:
> On 11/14/20 11:22 AM, Mateusz Guzik wrote:
>> Author: mjg
>> Date: Sat Nov 14 19:22:02 2020
>> New Revision: 367695
>> URL: https://svnweb.freebsd.org/changeset/base/367695
>>
>> Log:
>> thread: batch credential freeing
>>
>> Modified:
>> head/sys/kern/kern_prot.c
>> head/sys/kern/kern_thread.c
>> head/sys/sys/ucred.h
>>
>> Modified: head/sys/kern/kern_prot.c
>> ==
>> --- head/sys/kern/kern_prot.cSat Nov 14 19:21:46 2020
>> (r367694)
>> +++ head/sys/kern/kern_prot.cSat Nov 14 19:22:02 2020
>> (r367695)
>> @@ -2007,6 +2071,17 @@ crfree(struct ucred *cr)
>> mtx_unlock(&cr->cr_mtx);
>> return;
>> }
>> +crfree_final(cr);
>> +}
>> +
>> +static void
>> +crfree_final(struct ucred *cr)
>> +{
>> +
>> +KASSERT(cr->cr_users == 0, ("%s: users %d not == 0 on cred %p",
>> +__func__, cr->cr_users, cr));
>> +KASSERT(cr->cr_ref == 0, ("%s: ref %d not == 0 on cred %p",
>> +__func__, cr->cr_ref, cr));
>> /*
>
> Please add blank lines before comments. It's in style(9) and I've noticed
> a pattern in your changes of not including them.
>
Ok.
>> Modified: head/sys/sys/ucred.h
>> ==
>> --- head/sys/sys/ucred.h Sat Nov 14 19:21:46 2020(r367694)
>> +++ head/sys/sys/ucred.h Sat Nov 14 19:22:02 2020(r367695)
>> @@ -114,6 +114,28 @@ struct xucred {
>> struct proc;
>> struct thread;
>>
>> +struct credbatch {
>> +struct ucred *cred;
>> +int users;
>> +int ref;
>> +};
>> +
>> +static inline void
>> +credbatch_prep(struct credbatch *crb)
>> +{
>> +crb->cred = NULL;
>> +crb->users = 0;
>> +crb->ref = 0;
>> +}
>> +voidcredbatch_add(struct credbatch *crb, struct thread *td);
>> +static inline void
>> +credbatch_process(struct credbatch *crb)
>> +{
>> +
>> +}
>> +voidcredbatch_add(struct credbatch *crb, struct thread *td);
>> +voidcredbatch_final(struct credbatch *crb);
>> +
>
> Do not mix prototypes and inlines, especially without spaces
> around the prototype in the middle. Also, the kernel uses __inline
> rather than inline (for better or for worse).
The kernel has a huge mix of inline and __inline, to the point where
my impression was that __inline is obsolete.
> Better would be:
>
> static __inline void
> credbatch_prep()
> {
> ...
> }
>
> static __inline void
> credbatch_process()
> {
> ...
> }
>
> void credbatch_add();
> void credbatch_final();
>
I disagree. The current header order follows how these routines are used.
> It seems you just have a duplicate credbatch_add() in fact.
>
Indeed, I'll whack it.
> Also, why have an empty inline function?
>
Interested parties can check the consumer (also seen in the diff) to
see this is for consistency. I don't think any comments are warranted
in the header.
> These changes would benefit from review.
>
I don't think it's feasible to ask for review for everything lest it
degardes to rubber stamping and I don't think this change warranted
it, regardless of the cosmetic issues which can always show up.
> --
> John Baldwin
>
--
Mateusz Guzik
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r367695 - in head/sys: kern sys
On 11/14/20 11:22 AM, Mateusz Guzik wrote:
> Author: mjg
> Date: Sat Nov 14 19:22:02 2020
> New Revision: 367695
> URL: https://svnweb.freebsd.org/changeset/base/367695
>
> Log:
> thread: batch credential freeing
>
> Modified:
> head/sys/kern/kern_prot.c
> head/sys/kern/kern_thread.c
> head/sys/sys/ucred.h
>
> Modified: head/sys/kern/kern_prot.c
> ==
> --- head/sys/kern/kern_prot.c Sat Nov 14 19:21:46 2020(r367694)
> +++ head/sys/kern/kern_prot.c Sat Nov 14 19:22:02 2020(r367695)
> @@ -2007,6 +2071,17 @@ crfree(struct ucred *cr)
> mtx_unlock(&cr->cr_mtx);
> return;
> }
> + crfree_final(cr);
> +}
> +
> +static void
> +crfree_final(struct ucred *cr)
> +{
> +
> + KASSERT(cr->cr_users == 0, ("%s: users %d not == 0 on cred %p",
> + __func__, cr->cr_users, cr));
> + KASSERT(cr->cr_ref == 0, ("%s: ref %d not == 0 on cred %p",
> + __func__, cr->cr_ref, cr));
> /*
Please add blank lines before comments. It's in style(9) and I've noticed
a pattern in your changes of not including them.
> Modified: head/sys/sys/ucred.h
> ==
> --- head/sys/sys/ucred.h Sat Nov 14 19:21:46 2020(r367694)
> +++ head/sys/sys/ucred.h Sat Nov 14 19:22:02 2020(r367695)
> @@ -114,6 +114,28 @@ struct xucred {
> struct proc;
> struct thread;
>
> +struct credbatch {
> + struct ucred *cred;
> + int users;
> + int ref;
> +};
> +
> +static inline void
> +credbatch_prep(struct credbatch *crb)
> +{
> + crb->cred = NULL;
> + crb->users = 0;
> + crb->ref = 0;
> +}
> +void credbatch_add(struct credbatch *crb, struct thread *td);
> +static inline void
> +credbatch_process(struct credbatch *crb)
> +{
> +
> +}
> +void credbatch_add(struct credbatch *crb, struct thread *td);
> +void credbatch_final(struct credbatch *crb);
> +
Do not mix prototypes and inlines, especially without spaces
around the prototype in the middle. Also, the kernel uses __inline
rather than inline (for better or for worse). Better would be:
static __inline void
credbatch_prep()
{
...
}
static __inline void
credbatch_process()
{
...
}
void credbatch_add();
void credbatch_final();
It seems you just have a duplicate credbatch_add() in fact.
Also, why have an empty inline function?
These changes would benefit from review.
--
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r367695 - in head/sys: kern sys
Author: mjg
Date: Sat Nov 14 19:22:02 2020
New Revision: 367695
URL: https://svnweb.freebsd.org/changeset/base/367695
Log:
thread: batch credential freeing
Modified:
head/sys/kern/kern_prot.c
head/sys/kern/kern_thread.c
head/sys/sys/ucred.h
Modified: head/sys/kern/kern_prot.c
==
--- head/sys/kern/kern_prot.c Sat Nov 14 19:21:46 2020(r367694)
+++ head/sys/kern/kern_prot.c Sat Nov 14 19:22:02 2020(r367695)
@@ -86,6 +86,7 @@ static MALLOC_DEFINE(M_CRED, "cred", "credentials");
SYSCTL_NODE(_security, OID_AUTO, bsd, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,
"BSD security policy");
+static void crfree_final(struct ucred *cr);
static void crsetgroups_locked(struct ucred *cr, int ngrp,
gid_t *groups);
@@ -1902,6 +1903,31 @@ crunuse(struct thread *td)
return (crold);
}
+static void
+crunusebatch(struct ucred *cr, int users, int ref)
+{
+
+ KASSERT(users > 0, ("%s: passed users %d not > 0 ; cred %p",
+ __func__, users, cr));
+ mtx_lock(&cr->cr_mtx);
+ KASSERT(cr->cr_users >= users, ("%s: users %d not > %d on cred %p",
+ __func__, cr->cr_users, users, cr));
+ cr->cr_users -= users;
+ cr->cr_ref += ref;
+ cr->cr_ref -= users;
+ if (cr->cr_users > 0) {
+ mtx_unlock(&cr->cr_mtx);
+ return;
+ }
+ KASSERT(cr->cr_ref >= 0, ("%s: ref %d not >= 0 on cred %p",
+ __func__, cr->cr_ref, cr));
+ if (cr->cr_ref > 0) {
+ mtx_unlock(&cr->cr_mtx);
+ return;
+ }
+ crfree_final(cr);
+}
+
void
crcowfree(struct thread *td)
{
@@ -1935,6 +1961,44 @@ crcowsync(void)
}
/*
+ * Batching.
+ */
+void
+credbatch_add(struct credbatch *crb, struct thread *td)
+{
+ struct ucred *cr;
+
+ MPASS(td->td_realucred != NULL);
+ MPASS(td->td_realucred == td->td_ucred);
+ MPASS(td->td_state == TDS_INACTIVE);
+ cr = td->td_realucred;
+ KASSERT(cr->cr_users > 0, ("%s: users %d not > 0 on cred %p",
+ __func__, cr->cr_users, cr));
+ if (crb->cred != cr) {
+ if (crb->users > 0) {
+ MPASS(crb->cred != NULL);
+ crunusebatch(crb->cred, crb->users, crb->ref);
+ crb->users = 0;
+ crb->ref = 0;
+ }
+ }
+ crb->cred = cr;
+ crb->users++;
+ crb->ref += td->td_ucredref;
+ td->td_ucredref = 0;
+ td->td_realucred = NULL;
+}
+
+void
+credbatch_final(struct credbatch *crb)
+{
+
+ MPASS(crb->cred != NULL);
+ MPASS(crb->users > 0);
+ crunusebatch(crb->cred, crb->users, crb->ref);
+}
+
+/*
* Allocate a zeroed cred structure.
*/
struct ucred *
@@ -2007,6 +2071,17 @@ crfree(struct ucred *cr)
mtx_unlock(&cr->cr_mtx);
return;
}
+ crfree_final(cr);
+}
+
+static void
+crfree_final(struct ucred *cr)
+{
+
+ KASSERT(cr->cr_users == 0, ("%s: users %d not == 0 on cred %p",
+ __func__, cr->cr_users, cr));
+ KASSERT(cr->cr_ref == 0, ("%s: ref %d not == 0 on cred %p",
+ __func__, cr->cr_ref, cr));
/*
* Some callers of crget(), such as nfs_statfs(), allocate a temporary
* credential, but don't allocate a uidinfo structure.
Modified: head/sys/kern/kern_thread.c
==
--- head/sys/kern/kern_thread.c Sat Nov 14 19:21:46 2020(r367694)
+++ head/sys/kern/kern_thread.c Sat Nov 14 19:22:02 2020(r367695)
@@ -536,6 +536,7 @@ thread_reap(void)
{
struct thread *itd, *ntd;
struct tidbatch tidbatch;
+ struct credbatch credbatch;
int tdcount;
struct plimit *lim;
int limcount;
@@ -553,6 +554,7 @@ thread_reap(void)
return;
tidbatch_prep(&tidbatch);
+ credbatch_prep(&credbatch);
tdcount = 0;
lim = NULL;
limcount = 0;
@@ -560,8 +562,7 @@ thread_reap(void)
ntd = itd->td_zombie;
EVENTHANDLER_DIRECT_INVOKE(thread_dtor, itd);
tidbatch_add(&tidbatch, itd);
- MPASS(itd->td_realucred != NULL);
- crcowfree(itd);
+ credbatch_add(&credbatch, itd);
MPASS(itd->td_limit != NULL);
if (lim != itd->td_limit) {
if (limcount != 0) {
@@ -573,6 +574,7 @@ thread_reap(void)
limcount++;
thread_free_batched(itd);
tidbatch_process(&tidbatch);
+ credbatch_process(&credbatch);
tdcount++;
if (tdcount == 32) {
thread_count_sub(tdcount);
@@ -582,6 +584,7 @@ thread_reap(void)
}
tidbatch_final(&tidbatch);
+ credbatch_final(&credbatch);
if (tdcount != 0) {
