Lua bootloader #1

grandao · 2017-04-06T15:33:42Z

Hi, here are some changes to move the lua src in the right place and to make it compile.

bsdimp · 2017-04-06T17:41:46Z

Go ahead and rebase this patch to my branch. I'll be rebasing / curating the changes here in a bit.

FreeBSD's DTS contained only one PL050 node and driver considered it to be PS/2 keyboard. In reality PL050 is a PS/2 port that pushes bytes to/from the periphers connected to it. New DTS contains two nodes and QEMU emulates keyboard connected to port #0 and mouse connected to port #1. Since there is no way to say what's connected to port by checking DTS we hardcode this knowledge in the driver: it assumes keyboard on port #0 and ignores port #1 altogether. Also QEMU defaults emulated keyboard to scan code set 2 while driver used to work with scan code set 1 so when initializing driver make sure keyboard is switched to scan code set 1

In the absense of a more specific handler for TRAP_CAP (generated by ENOTCAPABLE or ECAPMODE while in capability mode) treat it as a trace trap. Example usage (testing the bug in PR219173): % proccontrol -m trapcap lldb usr.bin/hexdump/obj/hexdump -- -Cv -s 1 /bin/ls ... (lldb) run Process 12980 launching Process 12980 launched: '.../usr.bin/hexdump/obj/hexdump' (x86_64) Process 12980 stopped * thread #1, stop reason = trace frame #0: 0x0000004b80c65f1a libc.so.7`__sys_lseek + 10 ... In the future we should have LLDB control the trapcap procctl itself (as it does with ASLR), as well as report a specific stop reason. This change eliminates an assertion failure from LLDB for now.

(or peel off the band-aid, whatever floats your boat) This addresses two separate issues: 1.) Nothing within bsdgrep actually knew whether it cared about line numbers or not. 2.) The file layer knew nothing about the context in which it was being called. #1 is only important when we're *not* processing line-by-line. #2 is debatably a good idea; the parsing context is only handy because that's where we store current offset information and, as of this commit, whether or not it needs to be line-aware.

…2832, r332850-r332852, r332856, r332858, r332876, r333351, r334803, r334806-r334809, r334821, r334837, r334889, r335188, r351769, r352691 r320414: Expect :mmap_eof_not_eol to fail It relies on a jemalloc feature (opt.redzone) no longer available after r319971. r328559: Remove t_grep:mmap_eof_not_eol test The test was marked as an expected failure in r320414 after r319971's import of a newer jemalloc removed an essential feature (opt.redzone) for reproducing the behavior it was testing. Since then, no way has been found or demonstrated to reliably test the behavior, so remove the test. r332805: bsdgrep: Split match processing out of procfile procfile is getting kind of hairy, and it's not going to get better as we correct some more bits that assume we process one line at a time. r332806: bsdgrep: Clean up procmatches a little bit r332809: bsdgrep: Add some TODOs for future work on operating on chunks r332832: bsdgrep: Break procmatches down a little bit more Split the matching and non-matching cases out into their own functions to reduce future complexity. As the name implies, procmatches will eventually process more than one match itself in the future. r332850: bsdgrep: Some light cleanup There's no point checking for a bunch of file modes if we're not a practicing believer of DIR_SKIP or DEV_SKIP. This also reduces some style violations that were particularly ugly looking when browsing through. r332851: bsdgrep: More trivial cleanup/style cleanup We can avoid branching for these easily reduced patterns r332852: bsdgrep: if chain => switch This makes some of this a little easier to follow (in my opinion). r332856: bsdgrep: Fix --include/--exclude ordering issues Prior to r332851: * --exclude always win out over --include * --exclude-dir always wins out over --include-dir r332851 broke that behavior, resulting in: * First of --exclude, --include wins * First of --exclude-dir, --include-dir wins As it turns out, both behaviors are wrong by modern grep standards- the latest rule wins. e.g.: `grep --exclude foo --include foo 'thing' foo` foo is included `grep --include foo --exclude foo 'thing' foo` foo is excluded As tested with GNU grep 3.1. This commit makes bsdgrep follow this behavior. r332858: bsdgrep: Use grep_strdup instead of grep_malloc+strcpy r332876: bsdgrep: Fix build failure WITHOUT_LZMA (incorrect bracket placement) r333351: bsdgrep: Allow "-" to be passed to -f to mean "standard input" A version of this patch was originally sent to me by se@, matching behavior from newer versions of GNU grep. While there have been some differences of opinion on whether stdin should be closed or not after depleting it in process of -f, I've opted to leave stdin open and just let the later matching stuff fail and result in a no-match. I'm not married to the current behavior- it was generally chosen since we are adopting this in particular from GNU grep, and I would like to stay consistent without a strong argument to the contrary. The current behavior isn't technically wrong, it's just fairly unfriendly to the developer-user of grep that may not realize their usage is trivially invalid. r334803: netbsd-tests: grep(1): Add test for -c flag Someone might be inclined to accidentally break this. someone might have written said test because they broke it locally. r334806: bsdgrep(1): Do some less dirty things with return types Neither procfile nor grep_tree return anything meaningful to their callers. None of the callers actually care about how many lines were matched in all of the files they processed; it's all about "did anything match?" This is generally just a light refactoring to remind me of what actually matters as I'm rewriting these bits to care less about 'stuff'. r334807: bsdgrep(1): whoops, garbage collect the now write-only variable r334808: bsdgrep(1): Don't initialize fts_flags twice Admittedly, this is a clang-scan complaint... but it wasn't wrong. fts_flags is initialized by all cases in the switch(), which should be fairly obvious. Annotate this anyways. r334809: netbsd-tests: bsdgrep(1): Add a test for -m, too r334821: bsdgrep(1): Slooowly peel away the chunky onion (or peel off the band-aid, whatever floats your boat) This addresses two separate issues: 1.) Nothing within bsdgrep actually knew whether it cared about line numbers or not. 2.) The file layer knew nothing about the context in which it was being called. #1 is only important when we're *not* processing line-by-line. #2 is debatably a good idea; the parsing context is only handy because that's where we store current offset information and, as of this commit, whether or not it needs to be line-aware. r334837: bsdgrep(1): Evict character sequence that moved in r334889: bsdgrep(1): Some more int -> bool conversions and name changes Again motivated by upcoming work to rewrite a bunch of this- single-letter variable names and slightly misleading variable names ("lastmatches" to indicate that the last matched) are not helpful. r335188: bsdgrep(1): Remove redundant initialization; unconditionally assigned later r351769: bsdgrep(1): add some basic tests for some GNU Extension support These will be expanded later as I come up with good test cases; for now, these seem to be enough to trigger bugs in base gnugrep and expose missing features in bsdgrep. r352691: bsdgrep(1): various fixes of empty pattern/exit code/-c behavior When an empty pattern is encountered in the pattern list, I had previously broken bsdgrep to count that as a "match all" and ignore any other patterns in the list. This commit rectifies that mistake, among others: - The -v flag semantics were not quite right; lines matched should have been counted differently based on whether the -v flag was set or not. procline now definitively returns whether it's matched or not, and interpreting that result has been kicked up a level. - Empty patterns with the -x flag was broken similarly to empty patterns with the -w flag. The former is a whole-line match and should be more strict, only matching blank lines. No -x and no -w will will match the empty string at the beginning of each line. - The exit code with -L was broken, w.r.t. modern grep. Modern grap will exit(0) if any file that didn't match was output, so our interpretation was simply backwards. The new interpretation makes sense to me. Tests updated and added to try and catch some of this. This misbehavior was found by autoconf while fixing ports found in PR 229925 expecting either a more sane or a more GNU-like sed.

This and the follow-up routing-related changes target to remove or reduce `struct rt_addrinfo` usage and use recently-landed nhop(9) KPI instead. Traditionally `rt_addrinfo` structure has been used to propagate all necessary information between the protocol/rtsock and a routing layer. Many functions inside routing subsystem uses it internally. However, using this structure became somewhat complicated, as there are too many ways of specifying a single state and verifying data consistency is hard. For example, arerouting flgs consistent with mask/gateway sockaddr pointers? Is mask really a host mask? Are sockaddr "valid" (e.g. properly zeroed, masked, have proper length)? Are they mutable? Is the suggested interface specified by the interface index embedded into the sockadd_dl gateway, or passed as RTAX_IFP parameter, or directly provided by rti_ifp or it needs to be derived from the ifa? These (and other similar) questions have to be considered every time when a function has `rt_addrinfo` pointer as an argument. The new approach is to bring more control back to the protocols and construct the desired routing objects themselves - in the end, it's the protocol/subsystem who knows the desired outcome. This specific diff changes the following: * add explicit basic low-level radix operations: add_route() (renamed from add_route_nhop()) delete_route() (factored from change_route_nhop()) change_route() (renamed from change_route_nhop) * remove "info" parameter from change_route_conditional() as a part of reducing rt_addrinfo usage in the internal KPIs * add lookup_prefix_rt() wrapper for doing re-lookups after RIB lock/unlock Differential Revision: https://reviews.freebsd.org/D36070 MFC after: 2 weeks

Simplify epair_clone_create() and epair_clone_destroy() by factoring out epair softc allocation / desctruction and interface setup/teardown into separate functions. Reviewed By: kp, zlei.huang_gmail.com Differential Revision: https://reviews.freebsd.org/D36614 MFC after: 2 weeks

Before this patch, in zfs_domount, if zfs_root or d_make_root fails, we leave zfsvfs != NULL. This will lead to execution of the error handling `if` statement at the `out` label, and hence to a call to dmu_objset_disown and zfsvfs_free. However, zfs_umount, which we call upon failure of zfs_root and d_make_root already does dmu_objset_disown and zfsvfs_free. I suppose this patch rather adds to the brittleness of this part of the code base, but I don't want to invest more time in this right now. To add a regression test, we'd need some kind of fault injection facility for zfs_root or d_make_root, which doesn't exist right now. And even then, I think that regression test would be too closely tied to the implementation. To repro the double-disown / double-free, do the following: 1. patch zfs_root to always return an error 2. mount a ZFS filesystem Here's the stack trace you would see then: VERIFY3(ds->ds_owner == tag) failed (0000000000000000 == ffff9142361e8000) PANIC at dsl_dataset.c:1003:dsl_dataset_disown() Showing stack for process 28332 CPU: 2 PID: 28332 Comm: zpool Tainted: G O 5.10.103-1.nutanix.el7.x86_64 #1 Call Trace: dump_stack+0x74/0x92 spl_dumpstack+0x29/0x2b [spl] spl_panic+0xd4/0xfc [spl] dsl_dataset_disown+0xe9/0x150 [zfs] dmu_objset_disown+0xd6/0x150 [zfs] zfs_domount+0x17b/0x4b0 [zfs] zpl_mount+0x174/0x220 [zfs] legacy_get_tree+0x2b/0x50 vfs_get_tree+0x2a/0xc0 path_mount+0x2fa/0xa70 do_mount+0x7c/0xa0 __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x38/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reviewed-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Co-authored-by: Christian Schwarz <christian.schwarz@nutanix.com> Signed-off-by: Christian Schwarz <christian.schwarz@nutanix.com> Closes #14025

* Add ifc_find_cloner() * Rename current ifc_find_cloner() to ifc_find_cloner_in_vnet() * Add ifc_find_cloner_match() This change simplifies the code a bit and reduces the diff to the netlink interface cloners merge (D39032). Reviewed by: glebius, kp Differential Revision: https://reviews.freebsd.org/D39046 MFC after: 2 weeks

Under certain loads, the following panic is hit: panic: page fault KDB: stack backtrace: #0 0xffffffff805db025 at kdb_backtrace+0x65 #1 0xffffffff8058e86f at vpanic+0x17f #2 0xffffffff8058e6e3 at panic+0x43 #3 0xffffffff808adc15 at trap_fatal+0x385 #4 0xffffffff808adc6f at trap_pfault+0x4f #5 0xffffffff80886da8 at calltrap+0x8 #6 0xffffffff80669186 at vgonel+0x186 #7 0xffffffff80669841 at vgone+0x31 #8 0xffffffff8065806d at vfs_hash_insert+0x26d #9 0xffffffff81a39069 at sfs_vgetx+0x149 #10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 #11 0xffffffff8065a28c at lookup+0x45c #12 0xffffffff806594b9 at namei+0x259 #13 0xffffffff80676a33 at kern_statat+0xf3 #14 0xffffffff8067712f at sys_fstatat+0x2f #15 0xffffffff808ae50c at amd64_syscall+0x10c freebsd#16 0xffffffff808876bb at fast_syscall_common+0xf8 The page fault occurs because vgonel() will call VOP_CLOSE() for active vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While here, define vop_open for consistency. After adding the necessary vop, the bug progresses to the following panic: panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1) cpuid = 17 KDB: stack backtrace: #0 0xffffffff805e29c5 at kdb_backtrace+0x65 #1 0xffffffff8059620f at vpanic+0x17f #2 0xffffffff81a27f4a at spl_panic+0x3a #3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40 #4 0xffffffff8066fdee at vinactivef+0xde #5 0xffffffff80670b8a at vgonel+0x1ea #6 0xffffffff806711e1 at vgone+0x31 #7 0xffffffff8065fa0d at vfs_hash_insert+0x26d #8 0xffffffff81a39069 at sfs_vgetx+0x149 #9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 #10 0xffffffff80661c2c at lookup+0x45c #11 0xffffffff80660e59 at namei+0x259 #12 0xffffffff8067e3d3 at kern_statat+0xf3 #13 0xffffffff8067eacf at sys_fstatat+0x2f #14 0xffffffff808b5ecc at amd64_syscall+0x10c #15 0xffffffff8088f07b at fast_syscall_common+0xf8 This is caused by a race condition that can occur when allocating a new vnode and adding that vnode to the vfs hash. If the newly created vnode loses the race when being inserted into the vfs hash, it will not be recycled as its usecount is greater than zero, hitting the above assertion. Fix this by dropping the assertion. FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700 Reviewed-by: Andriy Gapon <avg@FreeBSD.org> Reviewed-by: Mateusz Guzik <mjguzik@gmail.com> Reviewed-by: Alek Pinchuk <apinchuk@axcient.com> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Signed-off-by: Rob Wing <rob.wing@klarasystems.com> Co-authored-by: Rob Wing <rob.wing@klarasystems.com> Submitted-by: Klara, Inc. Sponsored-by: rsync.net Closes #14501

Cleanup compiler warnings in preparation to set Wextra and remove WARNS?=2 Differential Revision: https://reviews.freebsd.org/D40238 MFC after: 2 weeks

Avoid locking issues when if_allmulti() calls the driver's if_ioctl, because that may acquire sleepable locks (while we hold a non-sleepable rwlock). Fortunately there's no pressing need to hold the mroute lock while we do this, so we can postpone the call slightly, until after we've released the lock. This avoids the following WITNESS warning (with iflib drivers): lock order reversal: (sleepable after non-sleepable) 1st 0xffffffff82f64960 IPv4 multicast forwarding (IPv4 multicast forwarding, rw) @ /usr/src/sys/netinet/ip_mroute.c:1050 2nd 0xfffff8000480f180 iflib ctx lock (iflib ctx lock, sx) @ /usr/src/sys/net/iflib.c:4525 lock order IPv4 multicast forwarding -> iflib ctx lock attempted at: #0 0xffffffff80bbd6ce at witness_checkorder+0xbbe #1 0xffffffff80b56d10 at _sx_xlock+0x60 #2 0xffffffff80c9ce5c at iflib_if_ioctl+0x2dc #3 0xffffffff80c7c395 at if_setflag+0xe5 #4 0xffffffff82f60a0e at del_vif_locked+0x9e #5 0xffffffff82f5f0d5 at X_ip_mrouter_set+0x265 #6 0xffffffff80bfd402 at sosetopt+0xc2 #7 0xffffffff80c02105 at kern_setsockopt+0xa5 #8 0xffffffff80c02054 at sys_setsockopt+0x24 #9 0xffffffff81046be8 at amd64_syscall+0x138 #10 0xffffffff8101930b at fast_syscall_common+0xf8 See also: https://redmine.pfsense.org/issues/12079 Reviewed by: mjg Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D41209

Specifically, altering the console list with conscontrol has some weird behavior: 1. If you remove the first configured console, /dev/console will become unconfigured 2. Any console added becomes the /dev/console In a multicons situation, #1 is clearly a bug and #2 is perhaps slightly less clear. If we have ttyu0, ttyv0, then it seems obvious that one would want ttyv0 to take over the console if ttyu0 is removed. If we add ttyu0 back in, then it's debatable whether it should take over the console or not. Fix it now to make the /dev/console selection more FIFO-ish, with respect to how conscontrol affects it. A `primary` verb for conscontrol(8) might be a good addition.

grandao added 2 commits April 6, 2017 11:00

Move lua src to the right place

7387bc8

Fix liblua build

53e071f

bsdimp merged this pull request into bsdimp:lua-bootloader Apr 6, 2017

bsdimp pushed a commit that referenced this pull request May 24, 2023

ifconfig: cleanup warnings #1

44cd85d

Cleanup compiler warnings in preparation to set Wextra and remove WARNS?=2 Differential Revision: https://reviews.freebsd.org/D40238 MFC after: 2 weeks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Lua bootloader #1

Lua bootloader #1

grandao commented Apr 6, 2017

bsdimp commented Apr 6, 2017

Lua bootloader #1

Lua bootloader #1

Conversation

grandao commented Apr 6, 2017

bsdimp commented Apr 6, 2017