[Bug 245870] panic during startup of squid inside jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245870
--- Comment #3 from Thomas von Dein ---
(In reply to Mark Johnston from comment #2)
Hello Mark,
> From frame 11 could you run:
>
> (kgdb) p *so
> (kgdb) p *so->so_listen
> (kgdb) p *so->so_listen->sol_accept_filter
Yes:
(kgdb) f 11
#11 0x80cf1ebc in soisconnected (so=0xf8108ede7368) at
/usr/src/sys/kern/uipc_socket.c:3775
3775ret =
head->sol_accept_filter->accf_callback(so,
(kgdb) p *so
$1 = {so_lock = {lock_object = {lo_name = 0x81386dc0 "socket", lo_flags
= 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 18446735281986889184},
so_count = 0, so_rdsel = {si_tdlist = {tqh_first = 0x0,
tqh_last = 0x0}, si_note = {kl_list = {slh_first = 0x0}, kl_lock =
0x80ceb1c0 , kl_unlock = 0x80ceb240
, kl_assert_locked = 0x80ceb2a0
,
kl_assert_unlocked = 0x80ceb2b0 ,
kl_lockarg = 0xf8108ede7368, kl_autodestroy = 0}, si_mtx = 0x0}, so_wrsel =
{si_tdlist = {tqh_first = 0x0, tqh_last = 0x0}, si_note = {kl_list = {
slh_first = 0x0}, kl_lock = 0x80ceb2c0 ,
kl_unlock = 0x80ceb340 , kl_assert_locked =
0x80ceb3a0 ,
kl_assert_unlocked = 0x80ceb3b0 ,
kl_lockarg = 0xf8108ede7368, kl_autodestroy = 0}, si_mtx = 0x0}, so_type =
1, so_options = 4, so_linger = 0, so_state = 259,
so_pcb = 0xf801f21e7988, so_vnet = 0xf81080019b40, so_proto =
0x81b581b0 , so_timeo = 0, so_error = 0, so_sigio = 0x0,
so_cred = 0xf8012cd3ee00, so_label = 0x0, so_gencnt = 23888,
so_emuldata = 0x0, so_dtor = 0x0, osd = {osd_nslots = 0, osd_slots = 0x0,
osd_next = {le_next = 0x0, le_prev = 0x0}}, so_fibnum = 0, so_user_cookie = 0,
so_ts_clock = 0, so_max_pacing_rate = 0, {{so_rcv = {sb_mtx = {
lock_object = {lo_name = 0x813e98c0 "so_rcv", lo_flags =
16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 18446735281986889184},
sb_sx = {lock_object = {lo_name = 0x81435c38 "so_rcv_sx",
lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 1},
sb_sel = 0xf8108ede7390, sb_state = 0, sb_mb = 0x0, sb_mbtail = 0x0,
sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_fnrdy = 0x0, sb_sndptroff = 0,
sb_acc = 0, sb_ccc = 0, sb_hiwat = 1049740, sb_mbcnt = 0, sb_mcnt = 0,
sb_ccnt = 0, sb_mbmax = 8397920, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0,
sb_flags = 2080, sb_upcall = 0x826e3000, sb_upcallarg = 0x0,
sb_aiojobq = {tqh_first = 0x0, tqh_last = 0xf8108ede7580},
sb_aiotask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0,
ta_func = 0x80cc7800 , ta_context = 0xf8108ede7368}},
so_snd = {sb_mtx = {lock_object = {lo_name = 0x813fbdb7 "so_snd",
lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, sb_sx =
{lock_object = {lo_name = 0x8145a998 "so_snd_sx",
lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 1},
sb_sel = 0xf8108ede73e0, sb_state = 0, sb_mb = 0x0, sb_mbtail = 0x0,
sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_fnrdy = 0x0, sb_sndptroff = 0,
sb_acc = 0, sb_ccc = 0, sb_hiwat = 1049740, sb_mbcnt = 0, sb_mcnt = 0,
sb_ccnt = 0, sb_mbmax = 8397920, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0,
sb_flags = 2048, sb_upcall = 0x0, sb_upcallarg = 0x0, sb_aiojobq = {
tqh_first = 0x0, tqh_last = 0xf8108ede7670}, sb_aiotask =
{ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func =
0x80cc8080 , ta_context = 0xf8108ede7368}}, so_list = {
tqe_next = 0x0, tqe_prev = 0xf8011cb60828}, so_listen =
0xf8011cb606d0, so_qstate = SQ_INCOMP, so_peerlabel = 0x0, so_oobmark = 0},
{sol_incomp = {tqh_first = 0x813e98c0, tqh_last = 0x103},
sol_comp = {tqh_first = 0x0, tqh_last = 0xf801047e65e0}, sol_qlen =
2168675384, sol_incqlen = 4294967295, sol_qlimit = 36896768, sol_accept_filter
= 0x0, sol_accept_filter_arg = 0x1,
sol_accept_filter_str = 0xf8108ede7390 "", sol_upcall = 0x0,
sol_upcallarg = 0x0, sol_sbrcv_lowat = 0, sol_sbsnd_lowat = 0, sol_sbrcv_hiwat
= 0, sol_sbsnd_hiwat = 0, sol_sbrcv_flags = 0, sol_sbsnd_flags = 0,
sol_sbrcv_timeo = 0, sol_sbsnd_timeo = 0}}}
(kgdb) p *so->so_listen
$2 = {so_lock = {lock_object = {lo_name = 0x81386dc0 "socket", lo_flags
= 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 18446735281986889184},
so_count = 2, so_rdsel = {si_tdlist = {tqh_first = 0x0,
tqh_last = 0x0}, si_note = {kl_list = {slh_first = 0xf810a58bd780},
kl_lock = 0x80ceb1c0 , kl_unlock = 0x80ceb240
,
kl_assert_locked = 0x80ceb2a0 ,
kl_assert_unlocked = 0x80ceb2b0 , kl_lockarg
= 0xf8011cb606d0, kl_autodestroy = 0}, si_mtx = 0x0}, so_wrsel = {
si_tdlist = {tqh_first = 0x0, tqh_last = 0x0}, si_note = {kl_list =
{slh_first = 0x0}, kl_lock = 0x80ceb2c0 , kl_unlock =
0x80ceb340 ,
kl_assert_locked = 0x80ceb3a0 ,
k
[Bug 245817] sendto() can return ENOTCONN on SOCK_STREAM unix socket, which is not documented
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245817 --- Comment #5 from commit-h...@freebsd.org --- A commit references this bug: Author: markj Date: Mon May 4 12:27:46 UTC 2020 New revision: 360627 URL: https://svnweb.freebsd.org/changeset/base/360627 Log: MFC r360384: Document handling of connection-mode sockets by sendto(2). PR: 245817 Changes: _U stable/12/ stable/12/lib/libc/sys/send.2 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 245817] sendto() can return ENOTCONN on SOCK_STREAM unix socket, which is not documented
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245817 Mark Johnston changed: What|Removed |Added Resolution|--- |FIXED Assignee|b...@freebsd.org|ma...@freebsd.org Status|In Progress |Closed --- Comment #6 from Mark Johnston --- Thanks for the report. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 245894] ixl(4) does not support more than 255 VLANs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245894 ncrog...@gmail.com changed: What|Removed |Added CC||ncrog...@gmail.com Keywords||IntelNetworking -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 245894] ixl(4) does not support more than 255 VLANs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245894 --- Comment #2 from ncrog...@gmail.com --- (In reply to ncrogers from comment #0) I meant that the Linux driver appears to automatically ENABLE promisc mode... -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246182] Kernel panic with sendfile() on ext2fs mounted filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246182
Bug ID: 246182
Summary: Kernel panic with sendfile() on ext2fs mounted
filesystems
Product: Base System
Version: 12.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: seg...@go-beyond.org
sendfile() with ext2fs can cause a kernel panic.
Tested on 12.1-RELEASE with x86_64 and ARMv7.
Steps:
1. Mount a filesystem with ext2fs.
2. open() a file under the mount point. Bigger files seem to work best, like
1GiB or so.
3. sendfile() that filedescriptor to the socket of your choice (127.0.0.1 on
some listening port that won't disconnect is fine, like nc -l 1234 >
/dev/null).
It seems to be kind of random for when the kernel panics, but it happens
inevitably. I've had it take anywhere from a second to maybe 10-20. Data
speed seems to have an effect, but maybe it's just the total amount
transferred. I'm not sure.
A web server like nginx that gives access to files mounted with ext2fs can
trigger this if it's setup to use sendfile (I think most are). Or any user
with access to an ext2fs mounted partition can trigger it. Does not have
to be ran as root.
I don't know if this can be skillfully exploited to give something more
interesting than a kernel panic or not.
Sample code to help with testing:
#include
#include
#include
#include
#include
#include
#include
#include
#include
char *self;
#define destinationPort 1234
int main(int argc, char **argv) {
self=argv[0];
if (argc != 2) {
fprintf(stderr, "Usage: %s \n", self);
return(2);
}
int srcfp = open(argv[1], O_RDONLY);
if (srcfp < 0) {
perror("open");
return(1);
}
int destinationSocket;
if ((destinationSocket = socket(PF_INET, SOCK_STREAM, 0)) < 0) {
perror("socket");
return(1);
}
struct sockaddr_in sa;
bzero(&sa, sizeof(sa));
sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
sa.sin_family = AF_INET;
sa.sin_port = htons(destinationPort);
if (connect(destinationSocket, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
perror("connect");
return(1);
}
if (sendfile(srcfp, destinationSocket, 0, 0, NULL, 0, 0) != 0) {
perror("sendfile");
return(1);
}
close(srcfp);
close(destinationSocket);
return(0);
}
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246182] Kernel panic with sendfile() on ext2fs mounted filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246182 --- Comment #1 from Teran McKinney --- Is it possible that this is related to bug #238700? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246182] Kernel panic with sendfile() on ext2fs mounted filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246182 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #2 from Konstantin Belousov --- Show the panic. Also might be useful to test with HEAD kernel, where a lot of fixes for sendfile(2) were done. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246182] Kernel panic with sendfile() on ext2fs mounted filesystems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246182 --- Comment #3 from Teran McKinney --- Thanks for replying. I have only had this happen with EXT2, EXT3, or EXT4. No other filesystem I've tested. FFS, ZFS, and are fine, likely FAT as well. This is from a Beagleboard. I believe x86_64 gives similar Translation Fault panics. root@generic:~ # ./sendfiler /mnt/FreeBSD-12.1-RELEASE-arm-armv7-BEAGLEBONE.img.xz Fatal kernel mode data abort: 'Translation Fault (L2)' on read trapframe: 0xc22c7970 FSR=0007, FAR=0042, spsr=8013 r0 =c6554000, r1 =c1915694, r2 =0022, r3 =bff195d0 r4 =, r5 =, r6 =0022, r7 =bff19600 r8 =0412, r9 =c0758c00, r10=0020, r11=c22c7a20 r12=bff195d8, ssp=c22c7a04, slr=c08bf85c, pc =c060400c panic: Fatal abort cpuid = 0 time = 1572586114 Uptime: 1h32m49s Automatic reboot in 15 seconds - press a key on the console to abort -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246190] manpage of certctl(8) contains from "first appeared" message
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246190 Bug ID: 246190 Summary: manpage of certctl(8) contains from "first appeared" message Product: Base System Version: 12.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: michael.osi...@siemens.com The manpage says: certctl first appeared in FreeBSD 12.0 In a 12.1-RELEASE jail: > # freebsd-version > 12.1-RELEASE > root@deblndw011x1j:~ > # certctl > -bash: certctl: Kommando nicht gefunden. The claim 12.0 is wrong. I assume that this will land in 12.2-RELEASE. Please update the manpage accordingly. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246191] installer prompts for (to be overwritten disk's) geli password
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246191 Bug ID: 246191 Summary: installer prompts for (to be overwritten disk's) geli password Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ema...@freebsd.org April 30 2020 -CURRENT snapshot installer image. I have a test machine which has encrypted-root-on-ZFS from a previous run of the same installer; I intend to overwrite this partition. When the install USB stick boots it prompts: Consoles: EFI console GELI Passphrase for disk1p3: _ Putting in the passphrase lets the installer proceed as usual. However, if I do not enter the correct passphrase I get: GELI Passphrase for disk1p3: _ Calculating GELI Decryption Key for disk1p3: 1323855 iterations... Bad GELI key: bad password? GELI Passphrase for disk1p3: _ Calculating GELI Decryption Key for disk1p3: 1323855 iterations... Bad GELI key: bad password? GELI Passphrase for disk1p3: _ Calculating GELI Decryption Key for disk1p3: 1323855 iterations... Bad GELI key: bad password? [some loader.efi boot messages omitted] Setting currdev to disk1p3: GELI Passphrase for disk1p3: Calculating GELI Decryption Key for disk1p3: 1323855 iterations... Bad GELI key: bad password? GELI Passphrase for disk1p3: _ Calculating GELI Decryption Key for disk1p3: 1323855 iterations... Bad GELI key: bad password? GELI Passphrase for disk1p3: _ Calculating GELI Decryption Key for disk1p3: 1323855 iterations... Bad GELI key: bad password? [repeated many times] Failed to find bootable partition If I don't know the existing passphrase I'm unable to reinstall. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246192] installer does not allow user to enter WiFi details if no networks found
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246192 Bug ID: 246192 Summary: installer does not allow user to enter WiFi details if no networks found Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ema...@freebsd.org If no wireless networks are found the installer prompts No wireless networks were found. Rescan? < Yes > < No > "No" returns to the network interface list; there is no way to enter WiFi details (for example, if connecting to a hidden SSID). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246117] Setting hw.psm.elantech.touchpad_off to 1 also disables trackpoint on t480s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246117 Vladimir Kondratyev changed: What|Removed |Added Assignee|b...@freebsd.org|w...@freebsd.org CC||w...@freebsd.org Status|New |In Progress --- Comment #1 from Vladimir Kondratyev --- Created attachment 214130 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=214130&action=edit psm.patch Try attached patch -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246118] hw.psm.elantech.min_pressure no longer works
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246118 Vladimir Kondratyev changed: What|Removed |Added CC||w...@freebsd.org --- Comment #1 from Vladimir Kondratyev --- hw.psm.elantech.min_pressure was never a feature of elantech driver. It worked incidentally due to some codepaths shared with synaptics touchpad support. Since switching to evdev by default in r360126 elan part of psm does not use built-in gesture processor so hw.psm.elantech.min_pressure is not working anymore. Could you achieve your goals through other means e.g. with libinput's "Disable While Typing" property? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246201] /etc/fstab "failok" option should apply to fsck as well as mount
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246201 Bug ID: 246201 Summary: /etc/fstab "failok" option should apply to fsck as well as mount Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: freebsd-bugzi...@thismonkey.com When the /etc/fstab option "failok" is configured for a UFS device which may, at times, be missing, boot still fails (drops into single-user mode). This is because fsck also runs against /etc/fstab, and considers the missing device to be a failure condition. fsck should be patched to also continue, possibly returning a different return code. Bug 163668 fixed the missing device issue in mount, but fsck was never taken into account (that I can see). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246206] dev/sound: SNDCTL_SYSINFO does not report PCM_CAP_VIRTUAL
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246206 Bug ID: 246206 Summary: dev/sound: SNDCTL_SYSINFO does not report PCM_CAP_VIRTUAL Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: kevinz5...@gmail.com Attachment #214136 text/plain mime type: Created attachment 214136 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=214136&action=edit Demonstration of issue In sys/soundcard.h, PCM_CAP_VIRTUAL is documented as "Virtual device": # define PCM_CAP_VIRTUAL 0x0004 /* Virtual device */ When SNDCTL_AUDIOINFO is called on /dev/mixer, no virtual devices have have PCM_CAP_VIRTUAL set. This means, apart from being smart, consumers of the OSS4 API can't tell virtual devices from real devices. This leads to a confusing choice in, say, audio programs that allow selection of vchans. A short example program that demonstrates the issue is attached. Example output on my computer is: $ clang vpctest.c -o vpctest $ ./vpctest dev /dev/dsp0.p0virtual 0 dev /dev/dsp0.vp0 virtual 0 dev /dev/dsp0.vp1 virtual 0 dev /dev/dsp0.r0virtual 0 dev /dev/dsp0.vr0 virtual 0 dev /dev/dsp0.vr1 virtual 0 The vp* and vr* devices are virtual, but PCM_CAP_VIRTUAL is not set. The root cause of this issue appears to be in dev/sound/pcm/dsp.c: ai->caps = PCM_CAP_REALTIME | PCM_CAP_MMAP | PCM_CAP_TRIGGER | CHANNEL_GETCAPS(ch) ((ch->direction == PCMDIR_PLAY) ? PCM_CAP_OUTPUT : PCM_CAP_INPUT); Most notably, PCM_CAP_VIRTUAL is never set. Further, the channel capabilities queried earlier: caps = chn_getcaps(ch); Do not appear to be used, either. I suggest that virtual channels return PCM_CAP_VIRTUAL in vchan_getcaps() (dev/sound/pcm/vchan.c), and then channel capabilities get OR'ed into ai->caps. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246207] [geom] geli livelocks during panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246207
Bug ID: 246207
Summary: [geom] geli livelocks during panic
Product: Base System
Version: 12.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: asom...@freebsd.org
Some geli-using machines I administer occasionally panic. When they do, they
sometimes dump core but often don't. When they don't, they simply hang after
printing the stack trace, but before printing the uptime.
I've traced the problem to geli's shutdown_pre_sync event handler. It tries to
destroy each geli device. We can't simply skip that step if a panic is
underway; erasing the keys is necessary to prevent warm-boot attacks. The
problem lies in the following lines.
g_eli_destroy:
sc->sc_flags |= G_ELI_FLAG_DESTROY;
wakeup(sc);
/*
* Wait for kernel threads self destruction.
*/
while (!LIST_EMPTY(&sc->sc_workers)) {
msleep(&sc->sc_workers, &sc->sc_queue_mtx, PRIBIO,
"geli:destroy", 0);
}
_sleep:
if (SCHEDULER_STOPPED_TD(td)) {
if (lock != NULL && priority & PDROP)
class->lc_unlock(lock);
return (0);
}
As you can see, if the scheduler is stopped for the current thread (which it
will be during a panic), then msleep does nothing, cause g_eli_destroy to loop
indefinitely. The obvious solution, which I haven't yet tested, would be to
skip that section in g_eli_destroy when the scheduler is stopped. What I don't
understand is why g_eli_destroy _ever_ works during a panic. Perhaps it has
something to do with the allocation of worker threads among cores? Perhaps it
only succeeds when all worker threads happen to be on different cores? I find
that unlikely though, because these servers have thousands of worker threads.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246208] dev/sound: SNDCTL_DSP_GETPLAYVOL does not work on vchans
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246208 Bug ID: 246208 Summary: dev/sound: SNDCTL_DSP_GETPLAYVOL does not work on vchans Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: kevinz5...@gmail.com The ioctl SNDCTL_DSP_GETPLAYVOL gets the volume of the given device, see: http://manuals.opensound.com/developer/SNDCTL_DSP_GETPLAYVOL.html This ioctl works on clone devices (e.g. /dev/dsp, /dev/dsp0, /dev/dsp0) but returns EINVAL for vchan devices (e.g. /dev/dsp0.vp0). It seems to me that this ioctl should work on vchans as well, for example, to query the volume on virtual channels. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246207] [geom] geli livelocks during panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246207 Mark Linimon changed: What|Removed |Added Keywords||panic Assignee|b...@freebsd.org|g...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246206] dev/sound: SNDCTL_SYSINFO does not report PCM_CAP_VIRTUAL
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246206 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|multime...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 242907] There are some typos in the sourcefiles
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242907 Gordon Bergling changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Gordon Bergling --- The Netflix copyright statements were corrected by the recent updates to RACK and BBR. The misc. corrections for the typos were committed a while ago, but this PR wasn't mentioned. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246215] [rtld] fails for i386 on amd64 if auxv does not contain PAGESIZES
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246215 Bug ID: 246215 Summary: [rtld] fails for i386 on amd64 if auxv does not contain PAGESIZES Product: Base System Version: 12.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: pa...@free.fr I came across this issue whilst working on getting Valgrind to work. When Valgrind runs, the guest application is loaded by Valgrind rather than the usual FreeBSD mechanisms. Thus Valgrind will synthesize an auxv, mmap rtld and run the rtld text in Valgrind's JIT compiled virtual CPU. However, to avoid memory space issues between the host and the guest, Valgrind does not provide auxv entries that contain pointers. This includes PAGESIZES. Normally rtld obtains the pagesizes from auxv, but it has fallback code to use syscalls. This works OK for an amd64 exe on an amd64 kernel and i386 on i386. But there is a problem for i386 on amd64. The i386 application will see MAXPAGESLEN as 3 from the amd64 headers. But the i386 kernel sees this as only 2 [I might have gotten this the wrong way around]. The sysctl copy out code sees this discrepancy and sets ENOMEM and the application terminates without finishing the execution of rtld. (I analysed all this with dtrace and looking at the source code, I don't know how to use gdb/lldb to step through rtld code). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
