limit the number of open knet_handle to UINT8_MAX for now.
UINT8_MAX requires approx 20GB of RAM only for init and more
than 1024 fds (tune your ulimit as necessary) without taking
into account fds required for links
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
loopback: Only allow 1 link to localhost if loopback is used.
If loopback is configured as a link transport to localhost then
no other transport makes sense and could actually cause
duplicate packets to be received. So now it's enforced and tested.
KNET_TRANSPORT_LOOPBACK is a transport designed for
high-speed communication internal to the local node. Data
packets are copied directly from the sendfd to the
receiving fd. The calling program must make sure that
data is removed from the receiving fd in a timely manner.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com> Reviewed-by: Fabio M. Di Nitto <fdinitto@redhat.com>
Jan Pokorný [Mon, 31 Jul 2017 10:53:29 +0000 (12:53 +0200)]
[init] service file: drop no longer available ControlGroup= option
Support for that was dropped in systemd 205[1]. To be able to get RT
priority regardless of the runtime control groups (Linux-specific),
there's a precedent solution for corosync[2], should it be needed.
Jan Pokorný [Fri, 28 Jul 2017 14:11:33 +0000 (16:11 +0200)]
[build] release.mk: reflect current release publishing practice
Core author(s) had previous affiliation with project hosting on
fedorahosted.org, but since the sunset of that hosting[1], it's no
longer an option.
Unfortunately, publish-by-scp convenience of fedorahosted.org won't fly
with GitHub that insists on the (primarily REST) API to get things
automated, so update "publish" recipe to that effect, providing some
hints on possible adaption of the process.
Also, turn "git push --tags" to a bit safer "git push --follow-tags"
for good measure.
Jan Pokorný [Fri, 28 Jul 2017 12:51:20 +0000 (14:51 +0200)]
[build] release.mk: move soft guard for no GPG key up the supply chain
It also means the missing key specification is now a hard error when
ASCII armored files are to be created (directly or by other rules).
Leveraging the previous commit, it is now unnecessary to guard against
release mode not being requested, so this guard is dropped completely
in the transition, allowing for the full-fledged (incl. GPG signing)
release delivery testing without mangling with in-tree tags.
To allow "sign" target to (possibly eventually) become the implicit goal
even if "gpgsignkey" variable is explicitly unspecified, make it depend
on $(deliverables).
Previously, generating custom versioned tarballs without requiring
a "release" (which comprises also tagging hence in turn making the
implied version match the required one as desired) would not allow
to test the release routines thoroughly incl. GPG signing.
Unfortunately, allowing for a temporary tag is prone to accidentally
slipping it to the distributed tree, so that should rather be avoided
Now it can.
Another step to blur the boundaries between whether "release" is
specified or not is to make checksums file generated unconditionally.
Also both pre-existing and the newly created (per the above scenario)
"overhead" files arising from make/release.mk are git-ignored properly.
...especially in case we want to easily switch to signing also
particular archives, which may be a reasonable expectation from some
downstream/distro maintainers (as demonstrated with the libqb's
example[1] where this changeset was picked from a followup PR[2],
respectively its adaptation for fence-agents[3]).
Since this commit, such a change is a matter of only swapping
a prerequisities specification for "sign" target per the commented
out suggestion.
For that to work reliably even after such a change, for the complete
dependency backtrack, though, a pre-existing issue with parallelized
work on the prerequisites needs to be fixed first. The (currently
hypothetical) problem is "tarballs" (phony) target missing in the
linearized supply chain for the signed tarballs, as opposed to supply
chain for the checksums file that can be worked on in an (unordered!)
interleave with the work on these signed tarballs. Hence fix this
(currently hypothetical) race condition by stretching "tarballs" target
as progress barrier (using it as a prerequisite) uniformly for all
the deliverables that are going to be signed (as opposed to the
currently only "sha256" target). And when at it, make "deliverables"
variable list them conveniently (along with reformatting definitions
of other variables for uniformity).
Jan Friesse [Fri, 30 Jun 2017 15:38:48 +0000 (17:38 +0200)]
[nsscrypto] Use different method to import key
PK11_ImportSymKey doesn't work when FIPS is enabled because NSS is
targeting to FIPS Level 2 where loading of unencrypted symmetric
key is prohibited.
FIPS Level 2 is hard to achieve without breaking compatibility so patch
implements "workaround" to make NSS behave like FIPS Level 1
(where is allowed to load unencrypted symmetric key).
Workaround is about using temporal key to encrypt corosync authkey in
memory and then to unwrap it into valid NSS key.
Also when FIPS is enabled, it's not currently (nss 3.30.2) possible to
unwrap key larger than 256 bytes.
previous to the introduction of detailed link stats, the values
contained in the status structure would hardly change over time
making a rdlock more than enough to get the right data.
Now that the values are updated constantly, we need to remove
the window of thread X writing values and thread Y to read them
while being written.
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
This patch also includes an ABI change to knet_link_get_status()
(as well as returning a load of stats) that should allow us to
add more stats at a later stage without ballooning memory use
with pads or crashing earlier-linked programs with structure
overwrites.
libknet: Add 'flags' parameter to knet_link_[gs]et_config()
I have at least 1 flag planned but I'm sure there's plenty of scope
for more. Also trying to get the API changes out of the way ready
for the cluster summit in September.
[libknet] Unlock the global lock if logging pipe is full.
If a write to the logging pipe fails (eg it's busy
waiting on something else, I've seen this in corosync
at shutdown) then we must unlock the global_rwlock
or we'll never get out of this alive.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com> Reviewed-by: Fabio M. Di Nitto <fdinitto@redhat.com>