Page MenuHomeFreeBSD
Feed Advanced Search

Sun, Aug 9

jah retitled D26010: kenv: avoid sleepable alloc for integer tunables from kenv: avoid sleepable malloc for integer tunables to kenv: avoid sleepable alloc for integer tunables.
Sun, Aug 9, 8:30 AM
jah retitled D26010: kenv: avoid sleepable alloc for integer tunables from kern_environment: avoid sleepable malloc for integer tunables, switch to rmlock to kenv: avoid sleepable malloc for integer tunables, switch to rmlock.
Sun, Aug 9, 8:27 AM
jah retitled D26010: kenv: avoid sleepable alloc for integer tunables from kenv: avoid sleepable malloc for integer tunables, switch to rmlock to kenv: avoid sleepable malloc for integer tunables.
Sun, Aug 9, 8:27 AM
jah updated the diff for D26010: kenv: avoid sleepable alloc for integer tunables.

Factor locking/unlocking into kenv_acquire() and kenv_release(), and use them for some light cleanup

Sun, Aug 9, 8:23 AM
jah updated the summary of D26010: kenv: avoid sleepable alloc for integer tunables.
Sun, Aug 9, 4:37 AM
jah updated the diff for D26010: kenv: avoid sleepable alloc for integer tunables.

Return kenv_lock to a mutex

Sun, Aug 9, 4:37 AM
jah added a comment to D26010: kenv: avoid sleepable alloc for integer tunables.
In D26010#576845, @mjg wrote:

The statement was that rmlocks distribute the lock per-CPU which means increased memory use. There are cases where this is perfectly warranted of course, I just doubt this one qualifies.

kenv should almost never be used past boot and even then I highly doubt the lock is contended enough to warrant any non-trivial changes. There may be offenders which keep re-reading the same value when they could do it once, but I don't think they are worth tracking down either. I do suspect there are nice wins to get like avoiding memory alloc (which also happen to fix bugs), but past that I would suggest not messing with the area.

In my opinion justifying this particular conversion would require a real world workload running into the problem which happens to not abuse the interface (like aforementioned re-reads of the same stuff), but I doubt there is something legitimate like this out there. However, I'm not going to stand in the way.

Sun, Aug 9, 2:15 AM
jah added a comment to D26010: kenv: avoid sleepable alloc for integer tunables.
In D26010#576843, @mjg wrote:

Is kenv frequently used to begin with? rm lock would add memory use per-cpu, so arguably it would be a pessimization. I also suspect we may be able to get away without any locks to begin with with some trickery.

Either way, I think the change to strtok in place is a good idea and an equivalent should be done for other routines if applicable.

That said, can you please open a separate review for the locking change and only keep the actual bugfix here?

Sun, Aug 9, 1:34 AM
jah added reviewers for D26010: kenv: avoid sleepable alloc for integer tunables: sjg, kevans, mjg.
Sun, Aug 9, 1:08 AM
jah requested review of D26010: kenv: avoid sleepable alloc for integer tunables.
Sun, Aug 9, 1:03 AM

Sun, Aug 2

jah closed D25564: vt(4): CONS_HISTORY/CONS_CLRHIST should operate on issuing terminal.
Sun, Aug 2, 8:18 PM
jah committed rS363784: vt(4): CONS_HISTORY/CONS_CLRHIST should operate on issuing terminal.
vt(4): CONS_HISTORY/CONS_CLRHIST should operate on issuing terminal
Sun, Aug 2, 8:18 PM

Sun, Jul 19

jah added a comment to D25564: vt(4): CONS_HISTORY/CONS_CLRHIST should operate on issuing terminal.

ping

Sun, Jul 19, 8:41 AM

Jul 4 2020

jah requested review of D25564: vt(4): CONS_HISTORY/CONS_CLRHIST should operate on issuing terminal.
Jul 4 2020, 10:22 PM

Jun 3 2020

jah added inline comments to D25107: Remove unnecessary WITNESS check in x86 bounce_bus_dmamem_alloc().
Jun 3 2020, 2:31 AM
jah committed rS361741: Remove unnecessary WITNESS check in x86 bus_dma.
Remove unnecessary WITNESS check in x86 bus_dma
Jun 3 2020, 12:16 AM
jah closed D25107: Remove unnecessary WITNESS check in x86 bounce_bus_dmamem_alloc().
Jun 3 2020, 12:16 AM
jah updated the diff for D25107: Remove unnecessary WITNESS check in x86 bounce_bus_dmamem_alloc().

Fix another typo

Jun 3 2020, 12:05 AM

Jun 2 2020

jah added inline comments to D25107: Remove unnecessary WITNESS check in x86 bounce_bus_dmamem_alloc().
Jun 2 2020, 11:58 PM
jah requested review of D25107: Remove unnecessary WITNESS check in x86 bounce_bus_dmamem_alloc().
Jun 2 2020, 10:18 PM
jah updated the diff for D25107: Remove unnecessary WITNESS check in x86 bounce_bus_dmamem_alloc().

Remove another unnecessary WITNESS check in the shared x86 bus_dma_tag_create()
implementation. Both DMAR and bounce implementations use
common_bus_dma_tag_create(), which allocates the tag with M_NOWAIT.

Jun 2 2020, 9:42 PM
jah added reviewers for D25107: Remove unnecessary WITNESS check in x86 bounce_bus_dmamem_alloc(): cem, kib.
Jun 2 2020, 8:19 PM
jah added inline comments to D10729: Cleanup MD pollution of MI busdma header.
Jun 2 2020, 7:17 PM
jah committed rS361719: vt(4): reset scrollback and cursor position after clearing history buffer.
vt(4): reset scrollback and cursor position after clearing history buffer
Jun 2 2020, 1:22 AM
jah closed D25079: vt(4): reset scrollback and cursor position after clearing history buffer.
Jun 2 2020, 1:22 AM

May 31 2020

jah updated the diff for D25079: vt(4): reset scrollback and cursor position after clearing history buffer.

Light cleanup of cursor position handling

May 31 2020, 2:05 AM
jah updated the diff for D25079: vt(4): reset scrollback and cursor position after clearing history buffer.

Ensure the visible rect is invalidated on CONS_CLRHIST

May 31 2020, 12:28 AM

May 30 2020

jah added inline comments to D25079: vt(4): reset scrollback and cursor position after clearing history buffer.
May 30 2020, 11:56 PM
jah added a reviewer for D25079: vt(4): reset scrollback and cursor position after clearing history buffer: emaste.
May 30 2020, 9:30 PM
jah requested review of D25079: vt(4): reset scrollback and cursor position after clearing history buffer.
May 30 2020, 9:29 PM

May 28 2020

jah closed D24815: vt(4): Add support for `vidcontrol -C'.
May 28 2020, 9:22 PM
jah committed rS361601: vt(4): Add support for `vidcontrol -C'.
vt(4): Add support for `vidcontrol -C'
May 28 2020, 9:22 PM
jah added a comment to D24815: vt(4): Add support for `vidcontrol -C'.

LGTM

I noticed one nit - after clearing history you can press Scroll Lock and scroll up through the cleared history buffer, while we probably want to reset that as well. However, I'd suggest that you commit this now and we can address that in a followup. I also did not check how sc(4) behaves with respect to this.

May 28 2020, 9:01 PM

May 23 2020

jah added a comment to D24815: vt(4): Add support for `vidcontrol -C'.

I will try this out shortly

May 23 2020, 7:54 PM

May 12 2020

jah updated the summary of D24815: vt(4): Add support for `vidcontrol -C'.
May 12 2020, 5:25 AM
jah added a reviewer for D24815: vt(4): Add support for `vidcontrol -C': emaste.
May 12 2020, 5:22 AM
jah requested review of D24815: vt(4): Add support for `vidcontrol -C'.
May 12 2020, 5:21 AM

Apr 27 2020

jah committed rS360368: MFC r359815: config(8): use sbuf to manage line buffers.
MFC r359815: config(8): use sbuf to manage line buffers
Apr 27 2020, 5:35 AM

Apr 12 2020

jah closed D24373: config(8): use sbuf to manage line buffers.
Apr 12 2020, 2:42 AM
jah committed rS359815: config(8): use sbuf to manage line buffers.
config(8): use sbuf to manage line buffers
Apr 12 2020, 2:42 AM

Apr 11 2020

jah added a comment to D24373: config(8): use sbuf to manage line buffers.
In D24373#536140, @imp wrote:

This looks fine, but given the age of config. It feels a bit like effort might be better spent on a rewrite

Apr 11 2020, 9:20 PM
jah retitled D24373: config(8): use sbuf to manage line buffers from config(8): use sbuf to manage line buffersPR: 245476 to config(8): use sbuf to manage line buffers.
Apr 11 2020, 8:40 PM
jah retitled D24373: config(8): use sbuf to manage line buffers from config(8): use sbuf to manage line buffers PR: 245476 to config(8): use sbuf to manage line buffersPR: 245476.
Apr 11 2020, 8:39 PM
jah created D24373: config(8): use sbuf to manage line buffers.
Apr 11 2020, 8:39 PM
jah committed rS359794: MFC r359501: deadlkres: include thread name in panic messages.
MFC r359501: deadlkres: include thread name in panic messages
Apr 11 2020, 5:13 AM

Apr 9 2020

jah accepted D24332: Handle disconnected sockets in uipc_ready()..
Apr 9 2020, 7:08 AM

Apr 8 2020

jah added inline comments to D24332: Handle disconnected sockets in uipc_ready()..
Apr 8 2020, 3:39 AM

Apr 4 2020

jah committed rS359628: mac_policy: Remove mac_policy_sx.
mac_policy: Remove mac_policy_sx
Apr 4 2020, 4:03 AM
jah closed D24283: mac_framework: Remove apparently-superfluous sxlock.
Apr 4 2020, 4:03 AM

Apr 3 2020

jah created D24283: mac_framework: Remove apparently-superfluous sxlock.
Apr 3 2020, 11:09 PM

Apr 1 2020

jah closed D24235: deadlkres: include thread name in panic messages.
Apr 1 2020, 4:51 AM
jah committed rS359501: deadlkres: include thread name in panic messages.
deadlkres: include thread name in panic messages
Apr 1 2020, 4:51 AM

Mar 31 2020

jah added reviewers for D24235: deadlkres: include thread name in panic messages: markj, jeff.
Mar 31 2020, 4:06 AM
jah created D24235: deadlkres: include thread name in panic messages.
Mar 31 2020, 4:06 AM

Jan 25 2020

jah committed rS357110: Implement cycle-detecting garbage collector for AF_UNIX sockets.
Implement cycle-detecting garbage collector for AF_UNIX sockets
Jan 25 2020, 8:57 AM
jah closed D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.
Jan 25 2020, 8:57 AM

Jan 16 2020

jah updated the diff for D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.

More review feedback

Jan 16 2020, 7:27 AM

Jan 15 2020

jah added inline comments to D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.
Jan 15 2020, 6:17 PM

Jan 14 2020

jah updated the diff for D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.

Code review feedback from markj

Jan 14 2020, 6:11 PM

Jan 13 2020

jah added inline comments to D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.
Jan 13 2020, 6:36 PM
jah added inline comments to D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.
Jan 13 2020, 5:13 PM
jah updated subscribers of D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.

This mostly looks right to me. Would you be willing to add some basic regression tests for the garbage collector to tests/sys/kern/unix_passfd_test.c?

Jan 13 2020, 4:51 PM
jah updated the diff for D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.

Replace assignment of unp_gcflag with KASSERT

Jan 13 2020, 6:15 AM

Jan 12 2020

jah added inline comments to D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.
Jan 12 2020, 7:49 PM
jah added a reviewer for D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets: jan.kokemueller_gmail.com.
Jan 12 2020, 5:06 AM
jah added reviewers for D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets: kib, markj, glebius.
Jan 12 2020, 5:03 AM
jah created D23142: Implement cycle-detecting garbage collector for AF_UNIX sockets.
Jan 12 2020, 4:58 AM

Sep 17 2019

jah committed rS352434: mips: move support for temporary mappings above KSEG0 to per-CPU data.
mips: move support for temporary mappings above KSEG0 to per-CPU data
Sep 17 2019, 3:39 AM
jah closed D18593: mips32: move support for temporary mappings above KSEG0 to per-CPU data.
Sep 17 2019, 3:39 AM

Sep 15 2019

jah added a comment to D18593: mips32: move support for temporary mappings above KSEG0 to per-CPU data.

Any objections to me submitting this as-is? I got sucked into $work for the last few months, but I did take some time to re-test just now to make sure this hasn't bit-rotted. I'd like to get this in and then look at some of the cache/busdma stuff.

Sep 15 2019, 4:33 AM

May 26 2019

jah added a comment to D18593: mips32: move support for temporary mappings above KSEG0 to per-CPU data.
In D18593#440598, @jah wrote:

But it also looks like, on all MIPS configurations, we're reserving TLB entry 0 for KSTACK_TLB_ENTRY. But I don't see any evidence that we're using that TLB slot currently: there's no call to tlb_insert_wired() on that slot that I can find. It also seems like a single TLB entry might not be sufficient for that, depending on the combination of PAGE_SIZE and KSTACK_PAGES.
Can that TLB entry be repurposed, or are we still using it somewhere I've missed?

May 26 2019, 4:32 AM

May 25 2019

jah added a comment to D18593: mips32: move support for temporary mappings above KSEG0 to per-CPU data.

I don't have any exceptionally helpful comments; the code looks fine, but I haven't given it the review it deserves.

  1. I don't think very much about 32-bit MIPS, unfortunately.
  2. If you're interested in MALTA, why not use MALTA64? If there's an actual hardware platform you care about, it'd be useful to know which one that is.
  3. The general approach of a reusable mapping for this kind of bounce buffering is a good one. Really, you could have a per-thread reusable mapping wired into the TLB for this use, and just update the wiring. That way the update path would be quicker, no TLBL/TLBS/TLBRefill. I never understood the sysmap_lmem code very well because (see point 1 above), but that's how I'd approach it.
  4. I would encourage allocating pairs of virtual pages even if you end up wasting one or more, to avoid even possibly splitting the TLB entry for one of these with something else.
  5. I agree we should get rid of 32-bit SMP on MIPS barring something really disruptive entering the marketplace. (This seems vanishingly unlikely, much as MIPS seems to be vanishing. People who would have accidentally used MIPS are all using ARM, and people who would have intentionally sought out MIPS are using RISC-V instead.)
  6. It's almost 110% certain that the cache handling is not totally right. I don't think very much these days about how to make it right, and it's a subject that requires nontrivial thought given VIVT vs. VIPT. If you're deep into reading about this stuff and have all of it paged in, I'd encourage taking a swing at auditing all of mips/mips for places that caching could be made correct, and giving it a try. You're unlikely to make it worse :)

Thanks for doing this, this is stuff that needs to be happen and looks to be good work!

May 25 2019, 9:11 PM

Apr 28 2019

jah committed rP500299: multimedia/cx88: update to 1.5.3; fixes build with clang 8.0.
multimedia/cx88: update to 1.5.3; fixes build with clang 8.0
Apr 28 2019, 9:03 AM

Apr 7 2019

jah committed rS346020: MFC r345741:.
MFC r345741:
Apr 7 2019, 7:08 PM
jah committed rS346019: MFC r345741:.
MFC r345741:
Apr 7 2019, 7:02 PM

Mar 30 2019

jah committed rS345741: freebsd32: fix padding of computed control message length for recvmsg().
freebsd32: fix padding of computed control message length for recvmsg()
Mar 30 2019, 11:44 PM
jah closed D19768: freebsd32: fix padding of computed control message length for recvmsg().
Mar 30 2019, 11:44 PM
jah added a reviewer for D19768: freebsd32: fix padding of computed control message length for recvmsg(): markj.
Mar 30 2019, 11:22 PM
jah created D19768: freebsd32: fix padding of computed control message length for recvmsg().
Mar 30 2019, 11:21 PM

Mar 17 2019

jah committed rS345240: MFC r344562:.
MFC r344562:
Mar 17 2019, 6:05 AM

Mar 5 2019

jah committed rS344792: MFC r344561:.
MFC r344561:
Mar 5 2019, 8:33 AM

Feb 26 2019

jah committed rS344562: FFS: allow sendfile(2) to work with block sizes greater than the page size.
FFS: allow sendfile(2) to work with block sizes greater than the page size
Feb 26 2019, 4:56 AM
jah closed D19340: FFS: allow sendfile(2) to work with block sizes greater than the page size.
Feb 26 2019, 4:56 AM
jah committed rS344561: Fix incorrect assertion in vnode_pager_generic_getpages().
Fix incorrect assertion in vnode_pager_generic_getpages()
Feb 26 2019, 4:50 AM

Feb 25 2019

jah added reviewers for D19340: FFS: allow sendfile(2) to work with block sizes greater than the page size: kib, glebius.
Feb 25 2019, 4:43 AM
jah created D19340: FFS: allow sendfile(2) to work with block sizes greater than the page size.
Feb 25 2019, 4:42 AM

Feb 21 2019

jah committed rS344422: MFC r343827:.
MFC r343827:
Feb 21 2019, 6:40 AM

Feb 6 2019

jah committed rS343827: r341692 changed cap_syslog(3) to preserve the stdio descriptors inherited.
r341692 changed cap_syslog(3) to preserve the stdio descriptors inherited
Feb 6 2019, 4:36 AM
jah closed D18989: Allow stdio access to be revoked from casper services.
Feb 6 2019, 4:36 AM

Feb 3 2019

jah updated the diff for D18989: Allow stdio access to be revoked from casper services.

Designate ignored return values

Feb 3 2019, 6:16 PM
jah added inline comments to D18989: Allow stdio access to be revoked from casper services.
Feb 3 2019, 5:53 PM
jah updated the diff for D18989: Allow stdio access to be revoked from casper services.

Avoid reassigning stderr if the dup of the existing descriptor failed

Feb 3 2019, 7:45 AM

Feb 2 2019

jah updated the diff for D18989: Allow stdio access to be revoked from casper services.

Simplify openlog() control flow, only dup existing stderr if LOG_PERROR
isn't already in use.

Feb 2 2019, 8:19 PM
jah updated the summary of D18989: Allow stdio access to be revoked from casper services.
Feb 2 2019, 7:08 PM
jah updated the diff for D18989: Allow stdio access to be revoked from casper services.

Remove cap_close_stdio() and pass stderr within cap_syslog

Feb 2 2019, 7:03 PM
jah added a comment to D18989: Allow stdio access to be revoked from casper services.
In D18989#407047, @jah wrote:
In D18989#406689, @jah wrote:

I do have one concern with that approach, namely that it's specific to cap_syslog. One of the reasons I started with cap_close_stdio() was that it could be applied to other services that might run into this problem in the future. Do you guys see any added value in an approach like that, or would you prefer that it always be handled in a service-specific way?

I do think cap_close_stdio() would be worth having, but I don't find this particular example particularly compelling... cap_syslog only needs the standard streams if LOG_PERROR is specified, and in this case it's not. We don't have many examples of casper services which request STDIO, so I'm a bit concerned about generalizing from too few examples. That said, I don't object to this patch and am ok with it going in if @oshogbo is ok with it.

BTW, @oshogbo, why does cap_fileargs request the STDIO descriptors? I can't see how they're used.

How about we go forward with your stderr-passing idea for now, and implement something like cap_close_stdio() if/when it ends up being needed? Since passing stderr keeps things completely within cap_syslog, it also has the near-term advantage of not needing a shlib minor version bump or a manpage edit.

That sounds good to me, thanks.

Feb 2 2019, 6:18 PM

Jan 31 2019

jah added a comment to D18989: Allow stdio access to be revoked from casper services.
In D18989#406689, @jah wrote:

I do have one concern with that approach, namely that it's specific to cap_syslog. One of the reasons I started with cap_close_stdio() was that it could be applied to other services that might run into this problem in the future. Do you guys see any added value in an approach like that, or would you prefer that it always be handled in a service-specific way?

I do think cap_close_stdio() would be worth having, but I don't find this particular example particularly compelling... cap_syslog only needs the standard streams if LOG_PERROR is specified, and in this case it's not. We don't have many examples of casper services which request STDIO, so I'm a bit concerned about generalizing from too few examples. That said, I don't object to this patch and am ok with it going in if @oshogbo is ok with it.

BTW, @oshogbo, why does cap_fileargs request the STDIO descriptors? I can't see how they're used.

Jan 31 2019, 5:47 AM

Jan 30 2019

jah added a comment to D18989: Allow stdio access to be revoked from casper services.

Sorry for the delay in looking at this.

This approach should work, but I'm not crazy about it: every cap_syslog consumer needs to consider whether this problem affects them, and add this extra API call if so. Another quick solution would be to revert r341692 and change savecore(8) to not use cap_syslog: it is not a daemon and is quite unlikely to be affected by the problem (reconnecting to syslogd upon an error) which motivates cap_syslog in the first place. All it really needs to do is call openlog(3) before entering capability mode, which it already does.

A more robust solution might be to revert r341692 and instead change cap_openlog(LOG_PERROR) to pass the caller's STDERR_FILENO descriptor to the cap_syslog service. The service can dup() the received descriptor onto STDERR_FILENO, and then I believe cap_syslog(3) will do the right thing. Some care would be needed to ensure that the cap_syslog process doesn't allocate STDERR_FILENO for some other purpose.

Jan 30 2019, 7:16 AM

Jan 27 2019

jah added inline comments to D18989: Allow stdio access to be revoked from casper services.
Jan 27 2019, 7:25 PM
jah added inline comments to D18989: Allow stdio access to be revoked from casper services.
Jan 27 2019, 7:01 PM