[Passes] Add new runCodeGenPipeline abstraction
This is intended to replace this logic in clang/flang other frontends
which currently write essentially the same thing.
Reviewers: arsenm, nikic, aengelke
Pull Request: https://github.com/llvm/llvm-project/pull/220305
Round trip a real file through a provisioned bucket
The boto3 test put a few bytes and read them back, which proves the
grants and nothing about the bucket middleware provisioned. A 5 MiB
file goes up and comes down through the transfer manager byte for
byte, once as a single put and once as three parts, and lands in the
data directory as the uploader's own file while the side tree beside
it stays the daemon's. The ETag says which path the bytes took. The
checksum stance is stated in the client rather than inherited from
whatever botocore is installed.
Ask the S3 daemon whether a reload took
The daemon used to say only in the journal whether a reload went in
force, so middleware predicted the answer from a copy of which keys
hold to a restart, diffing the files it had just rendered against the
ones before. It also carried the listen address to the daemon through
a systemd drop in, reloading systemd before every start and restart,
and rendered a PAM stack of its own for the account gate.
The daemon now answers over its control socket, takes its listen
addresses from the configuration and gates accounts through the
truenas-unix stack middleware already renders. So render_and_apply
renders and asks. reloading is done, restart means service.control
RESTART, invalid is a CallError carrying the daemon's text with the
running deployment left in force, and draining or no socket means the
next start reads the files. The key lists, the text diff, the drop in
renderer and its etc entry, the daemon reload hooks, the PAM template
and its etc entry are gone. bindip renders as [server] listen and may
name up to eight addresses now that the daemon binds them all.
[2 lines not shown]
Add the S3 service and its buckets to the API
Expose the truenas_s3 daemon through the s3 and sharing.s3 namespaces.
s3 is the global configuration (listen address, port, certificate,
region, log level, audit defaults and the grants that apply to every
bucket) and sharing.s3 is the bucket, a share like entity with its
access grants embedded so a grant can never outlive its bucket.
sharing.s3.create always creates the dataset through
zfs.resource.create_impl with every property the on disk format
requires stated explicitly, and refuses one that already exists. The
objects live in the dataset's data directory, which is created owned by
the bucket owner with an inheritable NFSv4 ACL every grantee satisfies.
The daemon publishes every write under the requester's own uid with no
capability to bypass the check, so an open ACL there is what leaves the
S3 grants as the only gate. The dataset root above it stays root owned
since it holds the version history. Deleting a bucket only deregisters
it and the dataset delete path deregisters through the attachment
delegate.
[12 lines not shown]
Delete a local account's S3 access keys with it
A key left behind by user.delete sat in the table with no account,
read USER_MISSING and could only be cleaned up by hand. Deleting the
account now deletes every key bound to its datastore id, then the
credentials file is re rendered as before. USER_MISSING keeps its
meaning for directory accounts, which are bound by SID and never pass
through user.delete, and the test that covered the local case now
simulates an unresolved SID instead.
ZTS: fix mkbusy kill/pgrep race in zfs_destroy_001_pos, _005_neg
Both tests killed their accumulated mkbusy pidlist and then immediately
asserted "log_mustnot pgrep -fl mkbusy". That check is racy: kill(2)
only queues the signal, so the target still has to be scheduled to take
it, and it then lingers as a zombie until init reaps it. mkbusy
daemonizes, so the test shell is not its parent and cannot wait(2) for
it -- and pgrep lists the process for that whole window, zombie
included.
Add kill_mkbusy() to zfs_destroy_common.kshlib: kill the pidlist, poll
kill -0 for each pid until it is gone (up to 5s per pid), and only then
run the "no mkbusy anywhere" leak check the tests already had. Scoping
the wait to the pids we killed keeps the leak check meaningful -- a
stale mkbusy from elsewhere is still reported, rather than silently
absorbed by a global wait loop -- and names the offending pid when a
kill really does fail to take.
Convert all 5 call sites in the two tests. The leak check now runs
[10 lines not shown]
dnode: fix heap-use-after-free in dnode_rele_and_unlock()
The ZFS_DEBUG-only assert in dnode_rele_and_unlock() dereferenced dnh,
the dnode's handle, after mutex_exit(&dn->dn_mtx), below the comment
stating "dnode could get destroyed at this point, so don't use it
anymore".
For an objset's special dnodes that is a real use-after-free. They have
no dnode block (dn_dbuf == NULL), so nothing pins their handle; it is
embedded in the objset_t. Only dn_nodnholds orders a release against
teardown, and this function is what signals it: on the last hold it
broadcasts and drops dn_mtx, freeing dnode_special_close() to destroy
that handle and, via dmu_objset_evict_done(), the objset it lives in.
The assert then reads it.
Read the zrlock ownership before dropping dn_mtx instead, where dn_mtx
still blocks dnode_special_close() and, for an ordinary dnode, the
reference from dbuf_add_ref(db, dnh) is not yet released.
[5 lines not shown]
www/nginx-devel: Update to 1.31.5
Changes with nginx 1.31.5 02 Sep
2026
*) Feature: control API.
*) Feature: predicate locations.
*) Feature: the ngx_http_json_module.
*) Feature: the "client_body_early_read" directive.
*) Bugfix: use-after-free might occur in a worker process if
proxying
with buffering was used and an error occurred while sending the
response to an HTTP/2 client.
*) Bugfix: a worker process might not exit or "accept4() failed (9:
[13 lines not shown]
[VPlan][Predicator] Preserve some uniform control flow
Implements "Partial Control-Flow Linearization" by Simon Moll and
Sebastian Hack.
That should allow implementation of an alternative to
https://github.com/llvm/llvm-project/pull/141900 based on this
functionality (see BOSCC in the paper).
Linux: drop cached pages in zfs_rezget()
After zfs rollback (or zfs recv -F) of a mounted dataset,
zfs_resume_fs() calls zfs_rezget() for every surviving znode. On Linux
it reloads the SA attributes but never touches the inode's page cache.
A file whose object number, generation and size are unchanged but whose
data blocks differ keeps serving pre-rollback data from pages that were
resident (the file had been mmap()ed) and later refreshed by
update_pages() from a write(). Both mappedread() and mmap() return the
stale pages; reading through .zfs/snapshot is correct, so the on-disk
data is fine.
The FreeBSD port handles this by calling vn_pages_remove_valid() at the
start of zfs_rezget(). Do the equivalent on Linux with
truncate_inode_pages() before reloading the znode, so pages are dropped
on the error paths as well. Dirty pages are discarded on purpose: their
content belongs to the state being rolled back, and writeback is blocked
on z_teardown_lock during suspend/resume anyway. Live mappings are
unmapped and fault the correct data back in through zfs_getpage().
[4 lines not shown]
unit/btree: test the negative cases
Introduce the two negative tests, insert_duplicate and remove_missing,
from tests/zfs-tests/cmd/btree_test.c to the unit tests.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #19009
subr_physmem_test: add tests for two edge-cases
Help validate my assertion that "physmem will never report empty
ranges". Part of this is covered by the existing tests, which check the
merging of adjacent/overlapping regions. The other part is to ensure
that addition of zero-sized ranges is ignored.
The physmem implementation also includes logic to ignore the first
physical page of memory (physical addresses 0 to PAGE_SIZE-1). Add a
second test case for this.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D45914
(cherry picked from commit 1b5ec2e466ee100161017ae2618f91829310f1d6)
g_eli: better handling of absent/disabled CPUs
Checking hlt_cpus_mask is a no-op, and the mask will be removed in the
next commit. However, we can use the more recent CPU_ABSENT() macro to
check the status.
Reviewed by: olce
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58157
(cherry picked from commit 63d4f044225d1bb86767759b18c0ae63b25a9c03)
smp: remove unused hlt_cpus_mask
It is a relic, apparently once populated by a machdep.hlt_cpus sysctl.
The sysctl was removed, and ULE has never honored this mask. It is now
safe to remove.
Remove the mask, and its few remaining references in: sched_4bsd(4),
hwpmc(4), and hwt(4).
Reviewed by: olce, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58158
(cherry picked from commit df0aca0d73064a1a199dbae3857012951f96cf2d)
sched/lapic: remove sched_do_timer_accounting()
The check is always true, especially after the removal of hlt_cpus_mask
from sched_4bsd.
Reviewed by: olce, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58159
(cherry picked from commit 01f165c68103df22cebe26d410c1d4a0e5fae377)
g_eli: disambiguate CPU-bound worker creation
This makes an effort to clarify and correct the intent of the code,
which is to either:
1. Create one software crypto worker thread for each CPU, to be pinned
later
2. Create the number of threads requested by the kern.geom.eli.threads
tunable
This is as described in geli(8).
If a CPU were somehow* absent, it should be skipped, but not in the
second case when creating a set number of threads.
To achieve this cleanly and correctly:
- split worker creation logic into a helper function
- keep the loops separate
- debug message for absent CPUs is dropped
[17 lines not shown]
libkern.h: remove HAVE_INLINE_* macros
The final consumer of this was OpenZFS, fixed in ffaea0831973 (thanks
mav@). That change has been present in all active OpenZFS release
branches for at least 6 months. These can finally be retired.
Reviewed by: mav
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55201
(cherry picked from commit 76f14217f6051df414e435c3388d3f4bb388cc22)
