from:"John"

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=b0e7358bf8b9791aaaf38807c841953946b88785

commit b0e7358bf8b9791aaaf38807c841953946b88785
Author: John Baldwin 
AuthorDate: 2024-06-06 21:47:04 +
Commit: John Baldwin 
CommitDate: 2024-06-06 21:48:38 +

cryptocheck: Don't treat OpenSSL errors as fatal

Abort the current test but keep running additional tests if OpenSSL
reports an error during a test.  This matches the behavior for other
tests such as an error from OCF.

Reviewed by:markj
Sponsored by:   AFRL, DARPA
Differential Revision:  https://reviews.freebsd.org/D45279
---
 tools/tools/crypto/cryptocheck.c | 322 ++-
 1 file changed, 220 insertions(+), 102 deletions(-)

diff --git a/tools/tools/crypto/cryptocheck.c b/tools/tools/crypto/cryptocheck.c
index ef3e225e94f6..6506671455ac 100644
--- a/tools/tools/crypto/cryptocheck.c
+++ b/tools/tools/crypto/cryptocheck.c
@@ -537,7 +537,7 @@ ocf_hash(const struct alg *alg, const char *buffer, size_t 
size, char *digest,
return (true);
 }
 
-static void
+static bool
 openssl_hash(const struct alg *alg, const EVP_MD *md, const void *buffer,
 size_t size, void *digest_out, unsigned *digest_sz_out)
 {
@@ -564,11 +564,12 @@ openssl_hash(const struct alg *alg, const EVP_MD *md, 
const void *buffer,
goto err_out;
 
EVP_MD_CTX_destroy(mdctx);
-   return;
+   return (true);
 
 err_out:
-   errx(1, "OpenSSL %s HASH failed%s: %s", alg->name, errs,
+   warnx("OpenSSL %s HASH failed%s: %s", alg->name, errs,
ERR_error_string(ERR_get_error(), NULL));
+   return (false);
 }
 
 static void
@@ -590,7 +591,8 @@ run_hash_test(const struct alg *alg, size_t size)
 
/* OpenSSL HASH. */
digest_len = sizeof(control_digest);
-   openssl_hash(alg, md, buffer, size, control_digest, _len);
+   if (!openssl_hash(alg, md, buffer, size, control_digest, _len))
+   goto out;
 
/* cryptodev HASH. */
if (!ocf_hash(alg, buffer, size, test_digest, ))
@@ -671,9 +673,11 @@ run_hmac_test(const struct alg *alg, size_t size)
/* OpenSSL HMAC. */
digest_len = sizeof(control_digest);
if (HMAC(md, key, key_len, (u_char *)buffer, size,
-   (u_char *)control_digest, _len) == NULL)
-   errx(1, "OpenSSL %s (%zu) HMAC failed: %s", alg->name,
+   (u_char *)control_digest, _len) == NULL) {
+   warnx("OpenSSL %s (%zu) HMAC failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   goto out;
+   }
 
/* cryptodev HMAC. */
if (!ocf_hmac(alg, buffer, size, key, key_len, test_digest, ))
@@ -700,7 +704,7 @@ out:
free(key);
 }
 
-static void
+static bool
 openssl_cipher(const struct alg *alg, const EVP_CIPHER *cipher, const char 
*key,
 const char *iv, const char *input, char *output, size_t size, int enc)
 {
@@ -708,27 +712,42 @@ openssl_cipher(const struct alg *alg, const EVP_CIPHER 
*cipher, const char *key,
int outl, total;
 
ctx = EVP_CIPHER_CTX_new();
-   if (ctx == NULL)
-   errx(1, "OpenSSL %s (%zu) ctx new failed: %s", alg->name,
+   if (ctx == NULL) {
+   warnx("OpenSSL %s (%zu) ctx new failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   return (false);
+   }
if (EVP_CipherInit_ex(ctx, cipher, NULL, (const u_char *)key,
-   (const u_char *)iv, enc) != 1)
-   errx(1, "OpenSSL %s (%zu) ctx init failed: %s", alg->name,
+   (const u_char *)iv, enc) != 1) {
+   warnx("OpenSSL %s (%zu) ctx init failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   goto error;
+   }
EVP_CIPHER_CTX_set_padding(ctx, 0);
if (EVP_CipherUpdate(ctx, (u_char *)output, ,
-   (const u_char *)input, size) != 1)
-   errx(1, "OpenSSL %s (%zu) cipher update failed: %s", alg->name,
+   (const u_char *)input, size) != 1) {
+   warnx("OpenSSL %s (%zu) cipher update failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   goto error;
+   }
total = outl;
-   if (EVP_CipherFinal_ex(ctx, (u_char *)output + outl, ) != 1)
-   errx(1, "OpenSSL %s (%zu) cipher final failed: %s", alg->name,
+   if (EVP_CipherFinal_ex(ctx, (u_char *)output + outl, ) != 1) {
+   warnx("OpenSSL %s (%zu) cipher final failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   goto error;
+   }
total +

git: b0e7358bf8b9 - main - cryptocheck: Don't treat OpenSSL errors as fatal

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=b0e7358bf8b9791aaaf38807c841953946b88785

commit b0e7358bf8b9791aaaf38807c841953946b88785
Author: John Baldwin 
AuthorDate: 2024-06-06 21:47:04 +
Commit: John Baldwin 
CommitDate: 2024-06-06 21:48:38 +

cryptocheck: Don't treat OpenSSL errors as fatal

Abort the current test but keep running additional tests if OpenSSL
reports an error during a test.  This matches the behavior for other
tests such as an error from OCF.

Reviewed by:markj
Sponsored by:   AFRL, DARPA
Differential Revision:  https://reviews.freebsd.org/D45279
---
 tools/tools/crypto/cryptocheck.c | 322 ++-
 1 file changed, 220 insertions(+), 102 deletions(-)

diff --git a/tools/tools/crypto/cryptocheck.c b/tools/tools/crypto/cryptocheck.c
index ef3e225e94f6..6506671455ac 100644
--- a/tools/tools/crypto/cryptocheck.c
+++ b/tools/tools/crypto/cryptocheck.c
@@ -537,7 +537,7 @@ ocf_hash(const struct alg *alg, const char *buffer, size_t 
size, char *digest,
return (true);
 }
 
-static void
+static bool
 openssl_hash(const struct alg *alg, const EVP_MD *md, const void *buffer,
 size_t size, void *digest_out, unsigned *digest_sz_out)
 {
@@ -564,11 +564,12 @@ openssl_hash(const struct alg *alg, const EVP_MD *md, 
const void *buffer,
goto err_out;
 
EVP_MD_CTX_destroy(mdctx);
-   return;
+   return (true);
 
 err_out:
-   errx(1, "OpenSSL %s HASH failed%s: %s", alg->name, errs,
+   warnx("OpenSSL %s HASH failed%s: %s", alg->name, errs,
ERR_error_string(ERR_get_error(), NULL));
+   return (false);
 }
 
 static void
@@ -590,7 +591,8 @@ run_hash_test(const struct alg *alg, size_t size)
 
/* OpenSSL HASH. */
digest_len = sizeof(control_digest);
-   openssl_hash(alg, md, buffer, size, control_digest, _len);
+   if (!openssl_hash(alg, md, buffer, size, control_digest, _len))
+   goto out;
 
/* cryptodev HASH. */
if (!ocf_hash(alg, buffer, size, test_digest, ))
@@ -671,9 +673,11 @@ run_hmac_test(const struct alg *alg, size_t size)
/* OpenSSL HMAC. */
digest_len = sizeof(control_digest);
if (HMAC(md, key, key_len, (u_char *)buffer, size,
-   (u_char *)control_digest, _len) == NULL)
-   errx(1, "OpenSSL %s (%zu) HMAC failed: %s", alg->name,
+   (u_char *)control_digest, _len) == NULL) {
+   warnx("OpenSSL %s (%zu) HMAC failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   goto out;
+   }
 
/* cryptodev HMAC. */
if (!ocf_hmac(alg, buffer, size, key, key_len, test_digest, ))
@@ -700,7 +704,7 @@ out:
free(key);
 }
 
-static void
+static bool
 openssl_cipher(const struct alg *alg, const EVP_CIPHER *cipher, const char 
*key,
 const char *iv, const char *input, char *output, size_t size, int enc)
 {
@@ -708,27 +712,42 @@ openssl_cipher(const struct alg *alg, const EVP_CIPHER 
*cipher, const char *key,
int outl, total;
 
ctx = EVP_CIPHER_CTX_new();
-   if (ctx == NULL)
-   errx(1, "OpenSSL %s (%zu) ctx new failed: %s", alg->name,
+   if (ctx == NULL) {
+   warnx("OpenSSL %s (%zu) ctx new failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   return (false);
+   }
if (EVP_CipherInit_ex(ctx, cipher, NULL, (const u_char *)key,
-   (const u_char *)iv, enc) != 1)
-   errx(1, "OpenSSL %s (%zu) ctx init failed: %s", alg->name,
+   (const u_char *)iv, enc) != 1) {
+   warnx("OpenSSL %s (%zu) ctx init failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   goto error;
+   }
EVP_CIPHER_CTX_set_padding(ctx, 0);
if (EVP_CipherUpdate(ctx, (u_char *)output, ,
-   (const u_char *)input, size) != 1)
-   errx(1, "OpenSSL %s (%zu) cipher update failed: %s", alg->name,
+   (const u_char *)input, size) != 1) {
+   warnx("OpenSSL %s (%zu) cipher update failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   goto error;
+   }
total = outl;
-   if (EVP_CipherFinal_ex(ctx, (u_char *)output + outl, ) != 1)
-   errx(1, "OpenSSL %s (%zu) cipher final failed: %s", alg->name,
+   if (EVP_CipherFinal_ex(ctx, (u_char *)output + outl, ) != 1) {
+   warnx("OpenSSL %s (%zu) cipher final failed: %s", alg->name,
size, ERR_error_string(ERR_get_error(), NULL));
+   goto error;
+   }
total +

git: a2c88e0d47ac - main - git-arc: Use a helper function to fetch boolean config variables

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=a2c88e0d47acb1a33016cbb7a821465fa1e357a6

commit a2c88e0d47acb1a33016cbb7a821465fa1e357a6
Author: John Baldwin 
AuthorDate: 2024-06-06 21:45:30 +
Commit: John Baldwin 
CommitDate: 2024-06-06 21:45:30 +

git-arc: Use a helper function to fetch boolean config variables

Requested by:   markj
Reviewed by:imp
Differential Revision:  https://reviews.freebsd.org/D45104
---
 tools/tools/git/git-arc.sh | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/tools/tools/git/git-arc.sh b/tools/tools/git/git-arc.sh
index e8da1f1ed32a..e9398a60d2f7 100644
--- a/tools/tools/git/git-arc.sh
+++ b/tools/tools/git/git-arc.sh
@@ -147,6 +147,16 @@ __EOF__
 exit 1
 }
 
+#
+# Fetch the value of a boolean config variable ($1) and return true
+# (0) if the variable is true.  The default value to use if the
+# variable is not set is passed in $2.
+#
+get_bool_config()
+{
+test "$(git config --bool --get $1 2>/dev/null || echo $2)" != "false"
+}
+
 #
 # Filter the output of call-conduit to remove the warnings that are generated
 # for some installations where openssl module is mysteriously installed twice 
so
@@ -378,7 +388,7 @@ gitarc__create()
 
 list=
 prev=""
-if [ "$(git config --bool --get arc.list 2>/dev/null || echo false)" != 
"false" ]; then
+if get_bool_config arc.list false; then
 list=1
 fi
 doprompt=1
@@ -672,7 +682,7 @@ gitarc__update()
 local commit commits diff doprompt have_msg list o msg
 
 list=
-if [ "$(git config --bool --get arc.list 2>/dev/null || echo false)" != 
"false" ]; then
+if get_bool_config arc.list false; then
 list=1
 fi
 doprompt=1
@@ -727,7 +737,7 @@ gitarc__update()
 set -e
 
 ASSUME_YES=
-if [ "$(git config --bool --get arc.assume-yes 2>/dev/null || echo false)" != 
"false" ]; then
+if get_bool_config arc.assume-yes false; then
 ASSUME_YES=1
 fi
 
@@ -801,7 +811,7 @@ list|patch)
 ;;
 esac
 
-if [ "$(git config --bool --get arc.browse 2>/dev/null || echo false)" != 
"false" ]; then
+if get_bool_config arc.browse false; then
 BROWSE=--browse
 fi

git: a2c88e0d47ac - main - git-arc: Use a helper function to fetch boolean config variables

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=a2c88e0d47acb1a33016cbb7a821465fa1e357a6

commit a2c88e0d47acb1a33016cbb7a821465fa1e357a6
Author: John Baldwin 
AuthorDate: 2024-06-06 21:45:30 +
Commit: John Baldwin 
CommitDate: 2024-06-06 21:45:30 +

git-arc: Use a helper function to fetch boolean config variables

Requested by:   markj
Reviewed by:imp
Differential Revision:  https://reviews.freebsd.org/D45104
---
 tools/tools/git/git-arc.sh | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/tools/tools/git/git-arc.sh b/tools/tools/git/git-arc.sh
index e8da1f1ed32a..e9398a60d2f7 100644
--- a/tools/tools/git/git-arc.sh
+++ b/tools/tools/git/git-arc.sh
@@ -147,6 +147,16 @@ __EOF__
 exit 1
 }
 
+#
+# Fetch the value of a boolean config variable ($1) and return true
+# (0) if the variable is true.  The default value to use if the
+# variable is not set is passed in $2.
+#
+get_bool_config()
+{
+test "$(git config --bool --get $1 2>/dev/null || echo $2)" != "false"
+}
+
 #
 # Filter the output of call-conduit to remove the warnings that are generated
 # for some installations where openssl module is mysteriously installed twice 
so
@@ -378,7 +388,7 @@ gitarc__create()
 
 list=
 prev=""
-if [ "$(git config --bool --get arc.list 2>/dev/null || echo false)" != 
"false" ]; then
+if get_bool_config arc.list false; then
 list=1
 fi
 doprompt=1
@@ -672,7 +682,7 @@ gitarc__update()
 local commit commits diff doprompt have_msg list o msg
 
 list=
-if [ "$(git config --bool --get arc.list 2>/dev/null || echo false)" != 
"false" ]; then
+if get_bool_config arc.list false; then
 list=1
 fi
 doprompt=1
@@ -727,7 +737,7 @@ gitarc__update()
 set -e
 
 ASSUME_YES=
-if [ "$(git config --bool --get arc.assume-yes 2>/dev/null || echo false)" != 
"false" ]; then
+if get_bool_config arc.assume-yes false; then
 ASSUME_YES=1
 fi
 
@@ -801,7 +811,7 @@ list|patch)
 ;;
 esac
 
-if [ "$(git config --bool --get arc.browse 2>/dev/null || echo false)" != 
"false" ]; then
+if get_bool_config arc.browse false; then
 BROWSE=--browse
 fi

Re: [gpfsug-discuss] No space left on device, but plenty of quota space for inodes and blocks

2024-06-06 Thread Maloney, John Daniel

Are you seeing the issues across the whole file system or in certain areas?  
That sounds like inode exhaustion to me (and based on it not being block 
exhaustion as you’ve demonstrated).

What does a “df -i /cluster” show you?  Or if this is only in a certain area 
you can “cd” into that directory and run a “df -i .”

You may need to allocate more inodes to an independent inode fileset somewhere. 
 Especially with something as old as 4.2.3 you won’t have auto-inode expansion 
for the filesets.

Best,

J.D. Maloney
Lead HPC Storage Engineer | Storage Enabling Technologies Group
National Center for Supercomputing Applications (NCSA)

From: gpfsug-discuss  on behalf of Rob 
Kudyba 
Date: Thursday, June 6, 2024 at 3:50 PM
To: gpfsug-discuss@gpfsug.org 
Subject: [gpfsug-discuss] No space left on device, but plenty of quota space 
for inodes and blocks
Running GPFS 4.2.3 on a DDN GridScaler and users are getting the No space left 
on device message when trying to write to a file. In /var/adm/ras/mmfs.log the 
only recent errors are this:

2024-06-06_15:51:22.311-0400: mmcommon getContactNodes cluster failed. Return 
code -1.
2024-06-06_15:51:22.311-0400: The previous error was detected on node x.x.x.x 
(headnode).
2024-06-06_15:53:25.088-0400: mmcommon getContactNodes cluster failed. Return 
code -1.
2024-06-06_15:53:25.088-0400: The previous error was detected on node x.x.x.x 
(headnode).

according to 
https://www.ibm.com/docs/en/storage-scale/5.1.9?topic=messages-6027-615

Check the preceding messages, and consult the earlier chapters of this 
document. A frequent cause for such errors is lack of space in /var.

We have plenty of space left.

 /usr/lpp/mmfs/bin/mmlsdisk cluster
disk driver   sector failure holdsholds 
   storage
name type   size   group metadata data  status
availability pool
  -- ---  - - 
 
S01_MDT200_1 nsd4096 200 Yes  Noready up
   system
S01_MDT201_1 nsd4096 201 Yes  Noready up
   system
S01_DAT0001_1 nsd4096 100 No   Yes   ready up   
data1
S01_DAT0002_1 nsd4096 101 No   Yes   ready up   
data1
S01_DAT0003_1 nsd4096 100 No   Yes   ready up   
data1
S01_DAT0004_1 nsd4096 101 No   Yes   ready up   
data1
S01_DAT0005_1 nsd4096 100 No   Yes   ready up   
data1
S01_DAT0006_1 nsd4096 101 No   Yes   ready up   
data1
S01_DAT0007_1 nsd4096 100 No   Yes   ready up   
data1

 /usr/lpp/mmfs/bin/mmdf headnode
diskdisk size  failure holdsholds  free KB  
   free KB
namein KBgroup metadata datain full blocks  
  in fragments
--- -   -  
---
Disks in storage pool: system (Maximum disk size allowed is 14 TB)
S01_MDT200_1   1862270976  200 Yes  No969134848 ( 52%)  
 2948720 ( 0%)
S01_MDT201_1   1862270976  201 Yes  No969126144 ( 52%)  
 2957424 ( 0%)
-  
---
(pool total)   37245419521938260992 ( 52%)  
 5906144 ( 0%)

Disks in storage pool: data1 (Maximum disk size allowed is 578 TB)
S01_DAT0007_1 77510737920  100 No   Yes 21080752128 ( 27%) 
897723392 ( 1%)
S01_DAT0005_1 77510737920  100 No   Yes 14507212800 ( 19%) 
949412160 ( 1%)
S01_DAT0001_1 77510737920  100 No   Yes 14503620608 ( 19%) 
951327680 ( 1%)
S01_DAT0003_1 77510737920  100 No   Yes 14509205504 ( 19%) 
949340544 ( 1%)
S01_DAT0002_1 77510737920  101 No   Yes 14504585216 ( 19%) 
948377536 ( 1%)
S01_DAT0004_1 77510737920  101 No   Yes 14503647232 ( 19%) 
952892480 ( 1%)
S01_DAT0006_1 77510737920  101 No   Yes 14504486912 ( 19%) 
949072512 ( 1%)
-  
---
(pool total) 542575165440  108113510400 ( 20%)
6598146304 ( 1%)

=  
===
(data)   542575165440  108113510400 ( 20%)
6598146304 ( 1%)
(metadata) 37245419521938260992 ( 52%)  
 5906144 ( 0%)

[valgrind] [Bug 487862] memcheck does not believe that bytes on new pages are Defined by brk() system call

2024-06-06 Thread John Reiser

https://bugs.kde.org/show_bug.cgi?id=487862

--- Comment #2 from John Reiser  ---
(In reply to Paul Floyd from comment #1)
> brk() is fairly old, removed from posix accordingly to the Linux manpage.
> Increasingly I see it getting removed from platforms.

In this case "old" means good, well-documented, well-debugged, reliable.
Please name explicitly some platforms which are removing brk(), and their
typical usage environments.

The brk() system call has been present in most *nix-like systems since 1970,
which is more than 50 years.  brk() is present in Linux today, and Linux
has a strong policy and implementation record for backwards compatibility
of system calls; brk() will not disappear from Linux anytime soon.

brk() is particularly useful during process startup when a call to malloc()
might not yet be supported;.  A programming language runtime can
use brk() via an inline system call.  See _dl_early_allocate() in glibc, for
example.

brk() and sbrk() enable an easy implementation of  mark() and release()
for Pascal run-time support.

brk() is quite handy for use by other in-process emulators, which must
deal with arbitrary mmap() anyway.  For instance, qemu relies on brk() and
sbrk().

brk() is multi-thread safe and async-signal safe without requiring
any user-mode locks.  It can be used safely in a signal handler.
Thread managers may rely on brk() regardless of the implementation of malloc().

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v2]

2024-06-06 Thread John Hendrikx

On Thu, 6 Jun 2024 15:35:07 GMT, Andy Goryachev  wrote:

>> CTGlyphLayout is not common code. It is mac only (so no need to mention mac)
>
> I see, PrismFontFactory:164 getNativeFactoryName().
> It would be nice to place platform-specific code in a package bearing the 
> platform name, or at least mention this in a class-level comment, but I guess 
> it's too late.
> 
> It means the scope is already limited to macOS, we are good.

I'm having some doubts about the solution still.  It is mentioned that this 
problem can occur in text containing both LTR and RTL text together, however, 
as far as I can see, a `TextRun` never contains a mix of text directions.  Can 
you clarify this?

Also in RTL text, I'm guessing "trailing" spaces are in fact what we call 
leading spaces in LTR text, ie. trailing spaces in a RTL text sample would be: 
`  قطة`

I'm guessing that CT (Core Text) returns the positions of all the trailing 
spaces as negative values, not just the first, and the first glyph (seen from 
the left) with an offset of 0.  Since the CT framework can also handle 
alignments, but FX is not making use of this, I think all calculations are done 
with the standard left alignment. It would make sense for spaces that "fall 
off" the left end (because they're "trailing") to have negative values.  
Similarly, if you did LTR text for `cat  ` with a right alignment, all glyphs 
would have negative values, except the two trailing spaces that would have 
positive values.

So I'm curious to see what happens if you have more than one trailing space 
(eg. ` قطة`) and what `CTRunGetPositions` returns then.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1630186928

Bug#1071117: fccexam: update question pool and URL

2024-06-06 Thread John Nogatch

On Tue, May 14, 2024 at 4:57 PM Austen, Jeffrey  wrote:
> Package: fccexam
> Version: 1.0.7-1.1
...
> Please update the question pool. Element 7 has changed. ...
> The URL in the package description should be updated ...

fccexam 1.0.8 is available at:
https://launchpad.net/~jnogatch/+archive/ubuntu/fccexam

This version includes the updates that you requested.

-John AC6SL

Re: [MlMt] Key binding selector for "Edit Tags"?

2024-06-06 Thread John Cooper

Tariq Magdon-Ismail wrote (at 11:39 AM on Thursday, June 6, 2024):

>>> I'd like to create a multi-stroke key binding for "Edit Tags" but couldn't 
>>> find any obvious selector here: 
>>> https://manual.mailmate-app.com/key_binding_selectors.html. Is there one 
>>> for this action?

On 6 Jun 2024, at 12:00, John Cooper wrote:

>> I use "t" and because it doesn't appear in my personal custom key bindings 
>> file, I think it must be built in. Have you tried it? Or do you need to use 
>> another key binding for some reason?
>>
Tariq Magdon-Ismail wrote (at 12:12 PM on Thursday, June 6, 2024):

> I have defined 't' as a multi-stroke binding that toggles tags. For example, 
> 'tp' would toggle the tag "pinned", 'tf' would toggle "focus" etc. I'd like 
> to define 'tt' to move focus to the tags editor. I could assign a shortcut in 
> the Tags preference pane, but that will only let me bind to a single stroke 
> key combination.

I'm not sure how that could be implemented without disabling the single-stroke 
binding, since the first "t" in the "tt" combo would be interpreted as "Edit 
Tag," as the default seems to be. One solution would be to disable the 
conflicting single-stroke bindings using a custom bindings file, and implement 
the double-stroke bindings with a third-party keyboard shortcuts manager such 
as Keyboard Maestro. I don't know of any MailMate-internal solution.
___
mailmate mailing list
Unsubscribe: https://lists.freron.com/listinfo/mailmate

Re: [MlMt] Key binding selector for "Edit Tags"?

2024-06-06 Thread John Cooper

Tariq Magdon-Ismail wrote (at 11:39 AM on Thursday, June 6, 2024):

> I'd like to create a multi-stroke key binding for "Edit Tags" but couldn't 
> find any obvious selector here: 
> https://manual.mailmate-app.com/key_binding_selectors.html. Is there one for 
> this action?

I use "t" and because it doesn't appear in my personal custom key bindings 
file, I think it must be built in. Have you tried it? Or do you need to use 
another key binding for some reason?
___
mailmate mailing list
Unsubscribe: https://lists.freron.com/listinfo/mailmate

[Bug 2068024] Re: race_sched in ubuntu_stress_smoke_test will cause kernel panic on 6.8 with Azure Standard_A2_v2 instance

2024-06-06 Thread John Cabaj

The problematic commit appears to be:

2227a957e1d5b1941be4e4207879ec74f4bb37f8: "sched/eevdf: Sort the rbtree
by virtual deadline"


Looking at further options right now.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068024

Title:
  race_sched in ubuntu_stress_smoke_test will cause kernel panic on 6.8
  with Azure Standard_A2_v2 instance

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2068024/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[sage-release] Re: Sage 10.4.beta8 released

2024-06-06 Thread John H Palmieri

This issue with "convert" has already been reported, with a proposed fix, 
at https://github.com/sagemath/sage/pull/38135.

  

On Wednesday, June 5, 2024 at 6:32:15 PM UTC-7 John H Palmieri wrote:

> I don't think I've seen this failure before:
>
> sage -t --long --random-seed=214696321465302976857414484526305325295 
> src/sage/plot/plot3d/tachyon.py
> **
> File "src/sage/plot/plot3d/tachyon.py", line 126, in 
> sage.plot.plot3d.tachyon
> Failed example:
> r2 = os.system('convert '+fname_png+' '+fname_ppm)# optional -- 
> ImageMagick
> Expected nothing
> Got:
> WARNING: The convert command is deprecated in IMv7, use "magick"
> 
> **
> 1 item had failures:
>1 of  63 in sage.plot.plot3d.tachyon
> [402 tests, 1 failure, 20.75 s]
> --
> sage -t --long --random-seed=214696321465302976857414484526305325295 
> src/sage/plot/plot3d/tachyon.py  # 1 doctest failed
>
> On Sunday, June 2, 2024 at 2:03:52 AM UTC-7 Volker Braun wrote:
>
>> As always, you can get the latest beta version from the "develop" git 
>> branch. Alternatively, the self-contained source tarball is at 
>> http://www.sagemath.org/download-latest.html
>>
>> e5f42fac703 (tag: 10.4.beta8, github/develop) Updated SageMath version to 
>> 10.4.beta8
>> 973a7e3600d gh-38121: Make "[source]" link to develop branch on github
>> c86c2bde5b4 gh-38111: GH Actions: Fix upload of macOS wheels to PyPI
>> af781fa7125 gh-38110: Update `conway_polynomials`, 
>> `database_cubic_hecke`, `database_knotinfo`, `matroid_database`
>> 71848f52ad6 gh-38105: Fixing the index set of a rank 1 Cartan matrix
>> 2d4f69a2b2e gh-38104: `sage.coding`: Update `# needs`
>> e1b22690db4 gh-38100: Remove nitpick_patch_config function
>> bbce0cd59e5 gh-38099: Remove deprecated global imports
>> da885cffce5 gh-38095: `src/sage/algebras/steenrod/all.py`: Use 
>> lazy_import, remove deprecated global import
>> dfb90d07be2 gh-38093: add doc on egf_to_ogf and inverse
>> c4507b93a52 gh-38092: `doc`: Update `help()` outputs
>> 1a68b7ce6f3 gh-38091: Fix doctest when the optional benzene is installed
>> aa8e10f80e6 gh-38090: CI Build: Split test-long into multiple jobs, 
>> repair Coverage.py upload
>> 3d1a66e303c gh-38087: Still add rpath to our own libstdc++, in case we 
>> built our own toolchain
>> 5d923d3a2f9 gh-38086: `all*.py` files: Use 'del lazy_import', 'del 
>> install_doc'
>> 284280a7dc5 gh-38082: CI fix: broken livedoc
>> 5958e5fe795 gh-38081: Fix sage.symbolic feature after libs/pynac removal
>> 013066dfe22 gh-38080: fixing superfluous empty lines in libs folder
>> 8b3363c760a gh-38079: fix pep8 E302 in algebras and categories (scripted)
>> dc4cde1c6ce gh-38078: remove inheritance from Algebra in FreeAlgebras
>> 57cbfc4f7c1 gh-38074: `sage.combinat`: Modularization fixes (imports), 
>> update `# needs`
>> 27c9f11cd9f gh-38071: `sage.categories`: Update `# needs`, use block tags
>> f264dbac987 gh-38070: Add skew Hadamard matrix of order 1588
>> f4fe2cc5cd1 gh-38069: docstrings: Change single dash to double dash after 
>> input variables
>> 2423da6dc87 gh-38068: Correct developer guide's function template
>> 98bea40602f gh-38067: `.ci/write-dockerfile.sh`: Quoting fix for 
>> `unminimize`
>> 2f38eae4130 gh-38066: `sage.geometry`: Modularization fixes (imports), `# 
>> needs`
>> 1c2bd539d47 gh-38065: `sage.graphs`: Doctest cosmetics
>> af423917cf6 gh-38061: `sage.rings`: Modularization fixes (imports)
>> 6328dda9e66 gh-38060: `sage.rings`: Modularization fixes for singular
>> 156f8e1eb41 gh-38059: `sage.ext.fast_callable`: Docstring cosmetics
>> 7597786d602 gh-38056: `SetSystem`: Minor change to accommodate set input
>> 9a17b344ea3 gh-38054: new iterators over the partitions of an integer
>> 306e6a62047 gh-38039: configure.ac: Check symlinks in the source tree
>> a965249ea01 gh-38035: `sage.modular`: Deprecate `is_...` functions
>> 296fbe07e58 gh-38032: `sage.combinat.finite_state_machine`: Deprecate 
>> `is_...` functions
>> 986989a227d gh-38029: Fix interaction of # 32-bit / # 64-bit tag with 
>> block-scoped doctest tags
>> efc613a76d2 gh-38026: Do not create `spkg-*.log`, `spkg-*.time` files
>> 2e4039c6da3 gh-38009: `build/pkgs/ecl`: Update to 24.5.10
>> 833274e512f gh-37999: Fix broken pytest integration (including CI failure 
>> in `src/conftest_test.py`)
>> 1bc90500cd6 gh-37988: CI Build: Re

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)


https://github.com/rjmccall commented:

I was hoping that you might push this down into the target code — if you make 
`emitVoidPtrVAArg` return an `RValue`, that'll handle about half of the 
targets.  Most of the rest will just need an `EmitLoadOfLValue` at the end.  
MIPS (which is the target with the weird unpromotion logic) calls 
`emitVoidPtrVAArg`, so it will just need to do its unpromotion on the scalar 
value, which it should be able to do without creating a temporary.

But this works as a first pass if you think that's too much to ask.

https://github.com/llvm/llvm-project/pull/94635
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)



@@ -5988,12 +5988,29 @@ CGCallee 
CGCallee::prepareConcreteCallee(CodeGenFunction ) const {
 
 /* VarArg handling */
 
-Address CodeGenFunction::EmitVAArg(VAArgExpr *VE, Address ) {
-  VAListAddr = VE->isMicrosoftABI()
- ? EmitMSVAListRef(VE->getSubExpr())
- : EmitVAListRef(VE->getSubExpr());
+RValue CodeGenFunction::EmitVAArg(VAArgExpr *VE, Address ) {
+  VAListAddr = VE->isMicrosoftABI() ? EmitMSVAListRef(VE->getSubExpr())
+: EmitVAListRef(VE->getSubExpr());
   QualType Ty = VE->getType();
+  Address ResAddr = Address::invalid();
   if (VE->isMicrosoftABI())
-return CGM.getTypes().getABIInfo().EmitMSVAArg(*this, VAListAddr, Ty);
-  return CGM.getTypes().getABIInfo().EmitVAArg(*this, VAListAddr, Ty);
+ResAddr = CGM.getTypes().getABIInfo().EmitMSVAArg(*this, VAListAddr, Ty);
+  else
+ResAddr = CGM.getTypes().getABIInfo().EmitVAArg(*this, VAListAddr, Ty);
+
+  switch (getEvaluationKind(VE->getType())) {
+  case TEK_Scalar: {
+llvm::Value *Load = Builder.CreateLoad(ResAddr);
+return RValue::get(Load);
+  }
+  case TEK_Complex: {
+llvm::Value *Load = Builder.CreateLoad(ResAddr);
+llvm::Value *Real = Builder.CreateExtractValue(Load, 0);
+llvm::Value *Imag = Builder.CreateExtractValue(Load, 1);
+return RValue::getComplex(std::make_pair(Real, Imag));

rjmccall wrote:

There's an `EmitLoadOfComplex` you can use here.  You'll just need to 
`MakeAddrLValue` first.

https://github.com/llvm/llvm-project/pull/94635
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)



@@ -1328,15 +1328,15 @@ void AggExprEmitter::VisitChooseExpr(const ChooseExpr 
*CE) {
 
 void AggExprEmitter::VisitVAArgExpr(VAArgExpr *VE) {
   Address ArgValue = Address::invalid();
-  Address ArgPtr = CGF.EmitVAArg(VE, ArgValue);
+  RValue ArgPtr = CGF.EmitVAArg(VE, ArgValue);
 
   // If EmitVAArg fails, emit an error.
-  if (!ArgPtr.isValid()) {
+  if (!ArgValue.isValid()) {
 CGF.ErrorUnsupported(VE, "aggregate va_arg expression");
 return;
   }
 
-  EmitFinalDestCopy(VE->getType(), CGF.MakeAddrLValue(ArgPtr, VE->getType()));
+  EmitFinalDestCopy(VE->getType(), ArgPtr);

rjmccall wrote:

It would be more standard here to pass the dest slot down.

https://github.com/llvm/llvm-project/pull/94635
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)


https://github.com/rjmccall edited 
https://github.com/llvm/llvm-project/pull/94635
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Historical QMP schema

2024-06-06 Thread John Snow

Adding upstream because I think there's little reason to keep this
discussion off-list.

The context of this mailing thread is that we are discussing how we might
want to store and record historical QMP API interface information such that
we can programmatically answer questions like "when was X command
introduced?", but possibly also to generate changelog QMP reports for
auditing QMP changes for each version during the release candidate window.

On Thu, Jun 6, 2024 at 6:25 AM Victor Toso  wrote:

> Hi John!
>
> On Wed, Jun 05, 2024 at 11:47:53AM GMT, John Snow wrote:
> > Hi,
> >
> > as part of my project to modernize QMP documentation I recently
> > forked the QAPI generator and modded it to be able to read
> > historical QAPI schema going all the way back to v1.0.
> >
> > We want to be able to use this ability to generate accurate
> > "since:" data for the docs.
>
> :)
>
> > My question for you is: do you have any input or preferences
> > for the format of "output" or "compiled" schemata?
>
> Not sure if I understand 'output' & 'compiled' reference here.
>

The idea is that even though I can modify the schema parser to cope with
historical versions of the schema, we should re-save the schema into a
unified format so that the gross hacks and kludges made to support old
versions in my forked QAPI parser don't need to be kept in-tree. In theory,
we only need to parse each historical schema precisely once.

(And then we'll only need to parse each new schema going forward with the
version of the QAPI parser that's already in-tree.)

Importantly, old versions of the schema aren't contained *entirely* within
the schema. Here's a timeline:

v0.12.0: QMP first introduced. Events are hardcoded, commands are defined
in qemu-monitor.hx. query commands are hard-coded in monitor.c.
v0.14.0: qemu-monitor.hx is forked into qmp-commands.hx and hmp-commands.hx
v1.0: First version which features qapi-schema.json; all query commands are
qapified but most other commands are not.
v1.1.0: A very large chunk of commands are QAPIfied.
v1.3.0: Most commands are now QAPIfied, but there are 2-3 remaining.
v2.1.0: events are now fully qapified; most are now defined in
qapi/events.json
v2.8.0: The remaining commands are fully qapified; qmp-commands.hx is
removed.

So what I mean by "compiled" schema is parsing historical revisions of the
schema, including descriptive schema definitions for items not-yet-qapified
(but nonetheless remain available in that version), and writing that
curated information back out to disk (and checking into qemu.git) for later
reference.

There are multiple choices for this output format:

(A) Just output in native qapi-schema format, just choose the "latest
version".
(B) Choose some other arbitrary format.
(C) Some secret, third thing.

I don't like the native qapi schema idea, for a few reasons:
- It changes over time
- It does not support nested structures except by reference, but
- Type names are not meant to API visible
- Detecting data changes in nested, shared types is difficult

In my prototype thus far, I have used a JSON-Schema based format with a
type definition library that catalogues all of the command arg / command
return / event data types with *all fields* fully dereferenced and inlined,
except where impossible due to cyclical/recursive references (PCI and
BlockStats come to mind.)

A benefit of this "compilation" is that all commands have their arguments
and return values described solely by type (and for enums, values) and not
by type name - fully removing non-API information from the "compiled"
version.

A downside is that this is yet-another-format that differs from the
existing format that requires someone knowledgeable to manipulate in case
there are errors found in it, or worse - we decide to change or upgrade the
format in some way to support a new feature in the future and we must
yet-again revise our catalogue of historical schemata.

>
> My preference is for this metadata to be there when the generator
> parses the schema. It could another external metadata file, but
> available to the generator.
>

Yes, ideally...

I'm thinking that I'd like to include a qapi/history/ directory which
contains a record of all compiled historical schemata, and the generator
can parse the directory and load up them all up - and then compile a quick
lookup table that is able to answer basic questions about the data.

i.e. "when was X [command/event] first introduced?"

"when was Command.arguments.key first introduced / incompatibly modified?"

The syntax/API for how to ask the QAPISchema object these questions remains
unpondered, as does the question "how do we report 'since' information in
the rendered QMP documentation HTML for nested objects that we begrudgingly
refer to only by

Re: June PUG is up

2024-06-06 Thread John Sessoms





On 6/5/2024 8:05 AM, Ralf R Radermacher wrote:

Am 05.06.24 um 13:33 schrieb Brian Walters:

Enjoy the (disappointingly small) gallery here:


Not for want of trying. I've scrolled through years and years of photos 
and haven't been able to find anything 'abstract'. So, hats off to those 
who have found something to contribute.


Special kudos to Ann and Henk.

Ralf



I had several, but none taken with Pentax camera or lens. (I've had a 
couple of canon point 'n shoot digitals.)


--
Vivere in aeternum aut mori conatur

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Re: [PATCH v5 0/3] Fix MCE handling on AMD hosts

2024-06-06 Thread John Allen

On Thu, Jun 06, 2024 at 11:09:05AM +0200, Paolo Bonzini wrote:
> Queued, thanks.  I added a note to the commit message in the third patch:

Thanks, Paolo!

> 
> By the time the MCE reaches the guest, the overflow has been handled
> by the host and has not caused a shutdown, so include the bit 
> unconditionally.

I'm not sure I understand this additional comment. Is this talking about
the case where the host gets an overflow? If so, yes, if the host has
overflow recovery supported, it should handle the overflow and won't
require any overflow recovery on the part of the guest. For clarity, it
may be nice to prefix the above statement with something like:
"In the case of a host overflow, ..."

If we're going to bring up the host overflow case, it may be worth
clarifying further that host overflows should not propagate to the guest
and this patch is specifically intended to allow the guest to handle
overflows in the MCEs that are injected from qemu.

> 
> Advertising of SUCCOR and OVERFLOW_RECOV in KVM would still be nice. :)

Sure, I will send a series for this.

Thanks,
John

[clang] [llvm] [DebugInfo] Change handling of structured bindings of bitfields (PR #94632)

2024-06-06 Thread John Brawn via cfe-commits


https://github.com/john-brawn-arm created 
https://github.com/llvm/llvm-project/pull/94632

Currently we use DW_OP_plus_uconst to handle the bitfield offset and handle the 
bitfield size by choosing a type size that matches, but this doesn't work if 
either offset or size aren't byte-aligned. Extracting the bits using 
DW_OP_LLVM_extract_bits means we can handle any kind of offset or size.

TODO: test signed type, nonzero StorageOffset, oversized bitfield

>From 7b0ac402bcebd905fd669bb6de2e39209fadda09 Mon Sep 17 00:00:00 2001
From: John Brawn 
Date: Wed, 29 May 2024 10:38:28 +0100
Subject: [PATCH 1/5] [DebugInfo] Add DW_OP_LLVM_extract_bits

This operation extracts a number of bits at a given offset and sign or
zero extends them, which is done by emitting it as a left shift
followed by a right shift.

This is being added for use in clang for C++ structured bindings of
bitfields that have offset or size that aren't a byte multiple. A new
operation is being added, instead of shifts being used directly, as it
makes correctly handling it in optimisations (which will be done in a
later patch) much easier.
---
 llvm/docs/LangRef.rst |  7 ++
 llvm/include/llvm/BinaryFormat/Dwarf.h|  1 +
 llvm/lib/BinaryFormat/Dwarf.cpp   |  3 +
 .../CodeGen/AsmPrinter/DwarfExpression.cpp| 32 ++
 llvm/lib/IR/AsmWriter.cpp |  4 +
 llvm/lib/IR/DebugInfoMetadata.cpp |  3 +
 .../DebugInfo/X86/DW_OP_LLVM_extract_bits.ll  | 99 +++
 7 files changed, 149 insertions(+)
 create mode 100644 llvm/test/DebugInfo/X86/DW_OP_LLVM_extract_bits.ll

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index c58f7f7140e47..7b4e91d09f342 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -6312,6 +6312,13 @@ The current supported opcode vocabulary is limited:
   (``16`` and ``DW_ATE_signed`` here, respectively) to which the top of the
   expression stack is to be converted. Maps into a ``DW_OP_convert`` operation
   that references a base type constructed from the supplied values.
+- ``DW_OP_LLVM_extract_bits, 16, 8, DW_ATE_signed`` specifies the offset, size,
+  and encoding (``16``, ``8``, and ``DW_ATE_signed`` here, respectively) of 
bits
+  that are to be extracted from the value at the top of the expression stack.
+  If the top of the expression stack is a memory location then these bits are
+  extracted from the value pointed to by that memory location. Maps into a
+  ``DW_OP_shl`` followed by ``DW_OP_shr`` or ``DW_OP_shra`` (depending on
+  encoding).
 - ``DW_OP_LLVM_tag_offset, tag_offset`` specifies that a memory tag should be
   optionally applied to the pointer. The memory tag is derived from the
   given tag offset in an implementation-defined manner.
diff --git a/llvm/include/llvm/BinaryFormat/Dwarf.h 
b/llvm/include/llvm/BinaryFormat/Dwarf.h
index 74c4d6ff3a716..7ae265484be58 100644
--- a/llvm/include/llvm/BinaryFormat/Dwarf.h
+++ b/llvm/include/llvm/BinaryFormat/Dwarf.h
@@ -144,6 +144,7 @@ enum LocationAtom {
   DW_OP_LLVM_entry_value = 0x1003,  ///< Only used in LLVM metadata.
   DW_OP_LLVM_implicit_pointer = 0x1004, ///< Only used in LLVM metadata.
   DW_OP_LLVM_arg = 0x1005,  ///< Only used in LLVM metadata.
+  DW_OP_LLVM_extract_bits = 0x1006, ///< Only used in LLVM metadata.
 };
 
 enum LlvmUserLocationAtom {
diff --git a/llvm/lib/BinaryFormat/Dwarf.cpp b/llvm/lib/BinaryFormat/Dwarf.cpp
index 7324266172684..d9668dffabec6 100644
--- a/llvm/lib/BinaryFormat/Dwarf.cpp
+++ b/llvm/lib/BinaryFormat/Dwarf.cpp
@@ -155,6 +155,8 @@ StringRef llvm::dwarf::OperationEncodingString(unsigned 
Encoding) {
 return "DW_OP_LLVM_implicit_pointer";
   case DW_OP_LLVM_arg:
 return "DW_OP_LLVM_arg";
+  case DW_OP_LLVM_extract_bits:
+return "DW_OP_LLVM_extract_bits";
   }
 }
 
@@ -169,6 +171,7 @@ unsigned llvm::dwarf::getOperationEncoding(StringRef 
OperationEncodingString) {
   .Case("DW_OP_LLVM_entry_value", DW_OP_LLVM_entry_value)
   .Case("DW_OP_LLVM_implicit_pointer", DW_OP_LLVM_implicit_pointer)
   .Case("DW_OP_LLVM_arg", DW_OP_LLVM_arg)
+  .Case("DW_OP_LLVM_extract_bits", DW_OP_LLVM_extract_bits)
   .Default(0);
 }
 
diff --git a/llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp 
b/llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp
index a74d43897d45b..87beeb7d6bc9a 100644
--- a/llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp
@@ -18,6 +18,7 @@
 #include "llvm/CodeGen/Register.h"
 #include "llvm/CodeGen/TargetRegisterInfo.h"
 #include "llvm/IR/DataLayout.h"
+#include "llvm/MC/MCAsmInfo.h"
 #include "llvm/Support/ErrorHandling.h"
 #include 
 
@@ -546,6 +547,37 @@ bool DwarfExpression::addExpression(
   LocationKind = Unknown;
   return true;
 }
+case dwarf::DW_OP_LLVM_extract_bits:

[Callers] Resources for Callers - Dance Instructions

2024-06-06 Thread John Sweeney via Contra Callers

Hi all,

  In response to some recent requests I have set up a page that
provides links to sites that provide instructions for dances, or videos or
animations.

 

  The page is http://contrafusion.co.uk/CallerResources.html. It
covers all genres of English and American dances.

 

  I would love to add more resources to this page.  Please let
me know the Web site addresses of any recommendations that you have.

 

  Please let me know if you have a Web site with multiple
dances, with full instructions.

 

  I will add as many as I can that look relevant.

 

  Thanks for your help.

 

Happy dancing,

   John   



John Sweeney, Dancer, England   j...@modernjive.com 01233 625 362 & 07802
940 574

http://www.contrafusion.co.uk for Dancing in Kent


 

 

___
Contra Callers mailing list -- contracallers@lists.sharedweight.net
To unsubscribe send an email to contracallers-le...@lists.sharedweight.net

[TLS]Re: Curve-popularity data?

2024-06-06 Thread John Mattsson

Hubert Kario wrote:
>Because NIST is a trend-setter, many other compliance organisations reuse 
>those curves
>(French ANSSI, German BSI, Japanese IPA, etc.).

I think IETF is also a very strong trend-setter among governments. Other 
governments follow NIST when they think NIST is doing a good job or when NIST 
algorithms is what is available on the market. They do the same with CFRG 
algorithms.

Dutch NCSC recommends secp384r1, secp256r1, curve448, and curve25519
https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1

French ANSSI recommends NIST P-curves but also approves X25519 X448 and 
Brainpool
file:///Users/emanjon/Downloads/anssi-guide-recommandations_de_securite_relatives_a_tls-v1.2.pdf

Japanese IPA recommends both P-256 and X25519
https://www.ipa.go.jp/security/crypto/guideline/gmcbt8005ufv-att/ipa-cryptrec-gl-3001-3.0.1.pdf

German BSI recommends Brainpool and writes that NIST P-curves can be used if 
Brainpool curves are not available.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile=6

China recommends SM2 and Russia recommends GOST.

Government recommendations are not always suitable for industry. For military 
and government use cases performance and monetary costs are low priority. For 
many industry use cases performance and monetary costs are very important 
priorities that also affect security. If ephemeral key exchange is slow, the 
answer is often to use less ephemeral key exchange instead of decreasing 
performance.

I think it would make sense to make both P-256 and X25519 MTI. I think forcing 
any key shares in CH is wrong. I also think registering hybrids as code points 
is wrong. If TLS did the right thing like IKEv2 we would just need to register 
ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as “groups” and everybody would be 
happy because there favorite standalone of hybrid would be supported. If the 
Web want to use a single hybrid I think that should be discussed in W3C.

Cheers,
John Preuß Mattsson

From: Hubert Kario 
Date: Thursday, 6 June 2024 at 12:37
To: D. J. Bernstein 
Cc: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?
On Wednesday, 5 June 2024 22:00:44 CEST, D. J. Bernstein wrote:
> Andrei Popov writes:
>> I support this change, willing to implement it in the Windows TLS
>> stack. We have thousands of customers concerned about increased
>> latencies due to the enablement of TLS 1.3. The services they connect
>> to require NIST curves and HRR is required to get TLS clients to send
>> appropriate key shares.
>
> To clarify, when you say "require NIST curves", do you mean "require
> conformance with NIST SP 800-56A"?

really depends on the deployment, some just want to use SP 800-56A curves,
some need actual, real, to the letter, legal compliance with FIPS 140-2 or
FIPS 140-3.

> In other words, will another curve be allowed once it's added to NIST
> SP 800-56A? Maybe faster: would the short-term problem be addressed if
> we can convince NIST to announce that it will consider X25519 and X448
> for a revision of SP 800-56A, and doesn't intend to enforce conformance
> of cryptographic modules with SP 800-56A until the revisions are done?

Short-term problem won't be solved like that for everybody. For
deployments that require FIPS compliance, the implementation itself needs
to be certified. At this moment there's no way to get it certified, so we
are at least 2-3 years away from a certified implementation of x25519
being available even if NIST marked x25519 as approved tomorrow.

> Or are you saying that, independently of NIST's decisions, the services
> in question are for some reason specifically requiring what's typically
> called the "NIST curves", namely the fifteen NSA curves that NIST
> standardized? Or the subset of those that NIST hasn't deprecated yet?

Because NIST is a trend-setter, many other compliance organisations
reuse those curves (French ANSSI, German BSI, Japanese IPA, etc.).
Similarly
Common Criteria certifications, while they're international, they're
similarly
heavily influenced by what NIST and NSA recommends. All of them will have
a lot of inertia.

And to address what John Mattsson wrote in a separate email: yes, IETF is
international and should not be bound by particular government requirements
for IETF standards to be actually usable in practice, they do need to
take into account what governmental bodies require. What gets published
by IETF can be superset of what govs want.

So, while I'd love to see x25519 in governmental standards, I think it's
better to spend energy making sure that we deploy ML-KEM as soon as
possible,
in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256
and
P-384).

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Cry

Re: Donald Trump, convicted felon

2024-06-06 Thread John Clark

On Wed, Jun 5, 2024 at 12:17 PM PGC  wrote:

*> I think embracing more direct, brutal honesty could really help.*
>

*I think it's a lot more complicated than that. Although no previous
American politician has lied virtually every time he opens his mouth as
Trump has, all politicians lie and they do it for one simple reason, it
works. I realize that way back in 1976 when Jimmy Carter was running for
president. Carter said in a Playboy interview that although he had never
cheated on his wife, "I've looked at many women with lust and thus
committed adultery many times in my heart.” The conservative religious
right was OUTRAGED by his statement. They wanted him to say "I've never had
the slightest urge to even look at any woman other than my wife regardless
of how beautiful she was" even though if he had done so they would have
known he was lying through his teeth. Carter made the mistake of telling
the truth and was severely punished for it, he almost lost the election as
a result. Convicted felon Donald Trump is amoral and monumentally stupid
but he never made Carter's mistake.*

*A mob of mindless Trump accolades like it when their leader lies to them
even when they know for a fact that he's lying, provided it's a pretty lie
that reinforces their prejudices and illogical reasoning. If Trump ever
shut off the spew of lies emanating from his mouth like water through a
fire hose his movement would collapse in a matter of days. *

John K ClarkSee what's on my new list at  Extropolis
<https://groups.google.com/g/extropolis>
tjd

By now it should be clear to everybody that Convicted Felon Trump never
built a wall and never made Mexico pay for it, and he never wanted to drain
the swamp, he wanted to own the swamp. And about 1.1 million Americans died
during Trump's watch due to his INCREDIBLE bungling of Covid, a pandemic he
publicly belittled, claiming the Democrats were over blowing the crucial
importance of itjust to make him unpopular, while at the exact same time
privately expressing very deep concern about the epidemic. The convicted
felon also dispensed quack medical advice about how to deal with the
pandemic, advice that was LETHAL. Even Donald Trump's most avid followers
know all this but they just don't care, I don't pretend to have a theory to
explain this phenomenon, but the evidence is overwhelming that the
phenomenon exists.

That's what I'm talking about! Your directness here is what the Biden PR
Team could benefit from. If only his PR team had someone like you to liven
things up a bit!

 > *Biden should Town Hall as much as he can*

If you want to win a Town Hall debate logic will not help you very much,
you need to appeal to base emotions, perhaps that's why Biden is not very
good at them.

I think embracing more direct, brutal honesty could really help. Biden
should adopt a more straightforward tone, directly addressing issues with
candor. This could resonate deeply with voters who crave authenticity. And,
as you point out, logic alone doesn’t win Town Halls. Biden needs to appeal
to base emotions—speak about hope, fear, pride, resilience, and expose the
child princess KFC toddler for what he is. A guy alleging deep state
conspiracies with Justice Department etc. while stating the ambition to
retaliate using it. And although sharing personal stories and real-life
impacts of his policies can create a more emotional connection, we need a
scene in a debate where Biden throws some ketchup or dip onto Trump's suit,
stating "your welcome. You're gonna need it later for when you're back on
the couch." Bring him a Big Mac and ask how dare he question American
greatness.

*>Emphasize America's role as a global leader and a beacon of hope and
democracy. Contrast this with the isolationist and divisive rhetoric of
Trump.*

There is one thing that Biden should've done on the first day of his
administration, something that would not only have helped him politically
it would also have been the right thing to do, and that is legalize
marijuana. And I say that despite the fact that I have never smoked even
one marijuana cigarette.

Regarding the marijuana legalization timing, the delay does make the
administration seem more focused on election cycles rather than principle.
Biden should address this head-on, perhaps with a bit of humor: “I know it
took us a while to light up this issue, but better late than never, right?”
Acknowledging this mistake with humility can go a long way: “We should have
acted on this sooner. Legalizing marijuana is not just about politics—it’s
about justice, health, and economic opportunity.”

Biden could use positive patriotism to counter Trump’s divisive rhetoric.
Biden can say e.g., “Patriotism isn’t about hate—it’s about love for our
country and all its people and not just some of its people. Facing the
threats of today's world, we cannot afford dvision.” He should articulate a
bold vision for the future that in

[frameworks-kconfig] [Bug 422529] Put config files inside a kde subdirectory in ~/.config, ~/.local/share, and ~/.cache

2024-06-06 Thread John

https://bugs.kde.org/show_bug.cgi?id=422529

John  changed:

   What|Removed |Added

 CC||johnmaveric...@mail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [PATCH 04/23] scsi: initialize scsi midlayer limits before allocating the queue

2024-06-06 Thread John Garry






diff --git a/drivers/ata/pata_macio.c b/drivers/ata/pata_macio.c
index 817838e2f70e..3cb455a32d92 100644
--- a/drivers/ata/pata_macio.c
+++ b/drivers/ata/pata_macio.c
@@ -915,10 +915,13 @@ static const struct scsi_host_template pata_macio_sht = {
.sg_tablesize   = MAX_DCMDS,
/* We may not need that strict one */
.dma_boundary   = ATA_DMA_BOUNDARY,
-   /* Not sure what the real max is but we know it's less than 64K, let's
-* use 64K minus 256
+   /*
+* The SCSI core requires the segment size to cover at least a page, so
+* for 64K page size kernels this must be at least 64K. However the
+* hardware can't handle 64K, so pata_macio_qc_prep() will split large
+* requests.
 */
-   .max_segment_size   = MAX_DBDMA_SEG,
+   .max_segment_size   = SZ_64K,
.device_configure   = pata_macio_device_configure,
.sdev_groups= ata_common_sdev_groups,
.can_queue  = ATA_DEF_QUEUE,



Feel free to add:
Reviewed-by: John Garry

[TLS]Re: [EXT] Re: Is NIST actually prohibiting X25519?

2024-06-06 Thread John Mattsson

I agree with Richard that there is too much focus on NIST in this thread. The 
strength with IETF is that IETF does not follow any specific national 
regulation. It is impossible to follow all national regulations. That IETF uses 
a lot of of NIST algorithms is not because IETF has to, but because NIST 
algorithms typically are very good and selected in many yaer open projects with 
leading cryptographers from around the world. Similar to how X25519 and X448 
was selected by CFRG.

Cheers,
John

From: Blumenthal, Uri - 0553 - MITLL 
Date: Thursday, 6 June 2024 at 02:24
To: Richard Barnes , tls@ietf.org 
Subject: [TLS]Re: [EXT] Re: Is NIST actually prohibiting X25519?
NIST cannot prohibit a curve, or an algorithm. But they may not approve it – 
and for customers that require approved technology and algorithms, it would 
prevent them from using anything that’s not explicitly approved.

--
V/R,
Uri

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare

From: Richard Barnes 
Date: Wednesday, June 5, 2024 at 20:20
To: tls@ietf.org 
Subject: [EXT] [TLS]Re: Is NIST actually prohibiting X25519?
As with the earlier thread, this message is off-topic for this list.   
Regardless of what NIST does, the TLS protocol does and will support a variety 
of curves. On Wed, Jun 5, 2024 at 20: 14 D. J. Bernstein  
wrote: Andrei
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
As with the earlier thread, this message is off-topic for this list.

Regardless of what NIST does, the TLS protocol does and will support a variety 
of curves.

On Wed, Jun 5, 2024 at 20:14 D. J. Bernstein 
mailto:d...@cr.yp.to>> wrote:
Andrei Popov writes:
> This is a complicated compliance question. I'm not qualified to
> comment on this option.

I think it's worth investigating, considering the following NIST quote:

   Their associated key agreement schemes, X25519 and X448, will be
   considered for inclusion in a subsequent revision to SP 800-56A.  The
   CMVP does not intend to enforce compliance with SP 800-56A until
   these revisions are complete.

https://web.archive.org/web/20200810165057/https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices<https://web.archive.org/web/20200810165057/https:/csrc.nist.gov/projects/cryptographic-module-validation-program/notices>

Does anyone have any documents showing that NIST has reneged on the
above announcement? Possibilities:

   * Yes: then I'd appreciate a pointer so that concerned members of the
 community can tell NIST what they think about this and, hopefully,
 get NIST to change course.

   * No: then the announcement and consistent handling of this by NIST
 would be another reason for IETF to not be dragged down by the
 current limitations of NIST SP 800-56A.

If nobody has ever tried asking NIST to approve an X25519 solution as
per the above announcement, surely that would be a useful experiment,
creating a path towards simplifying subsequent TLS WG discussions.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[Bug 2064363] Re: thunderbird snap on live systems "already running" but not responsive

2024-06-06 Thread John Johansen

> Am I correct in understanding, the Thunderbird snap does not allow
profiles to set paths to locations outside the snap confinement? And if
so, is that something specific to running a live system or is it
something any Lubuntu 24.04 installation is now stymied by?

it is a property of the snap, regardless of whether it is on a live system, 
ubuntu, Lubuntu, kubuntu, ...
There is work on going to address this but it is not currently available

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064363

Title:
  thunderbird snap on live systems "already running" but not responsive

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2064363/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064363] Re: thunderbird snap on live systems "already running" but not responsive

2024-06-05 Thread John Johansen

Sigh, that should be Unfortunately snap doesn't currently have ...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064363

Title:
  thunderbird snap on live systems "already running" but not responsive

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2064363/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064363] Re: thunderbird snap on live systems "already running" but not responsive

2024-06-05 Thread John Johansen

> I'm sorry, would you mind elaborating? profiles.ini allows
configuration of where each profile stores emails, so what are the
consequences of my doing that? I used it, and the same PATH variable,
prior to 24.04 without problem.

that will direct thunderbird to access your emails stored at the location 
  /media/lubuntu/drive/hq/email/thunderbird/certainprofilegoeshere

which explains why your dmesg contains denials like
  [39889.472715] audit: type=1400 audit(1714429239.953:352): apparmor="DENIED" 
operation="open" class="file" profile="snap.thunderbird.thunderbird" 
name="/media/lubuntu/drive/hq/email/thunderbird/awesomenough/.parentlock" 
pid=72158 comm="thunderbird-bin" requested_mask="wc" denied_mask="wc" 
fsuid=1000 ouid=1000

which was my comment about being at a loss as to why thunderbird is
trying to access

```
/media/lubuntu/drive/hq/email/thunderbird/awesomenough/.parentlock
/media/lubuntu/drive/hq/email/thunderbird/awesomenough/lock
```


The consequences of doing that are that the snap confinement for thunderbird 
doesn't give it access to that location. The thunderbird deb is installing the 
thunderbird snap, you can read more about it at the following link 
https://www.omgubuntu.co.uk/2024/02/thunderbird-snap-in-ubuntu-24-04

For the chrome snap I would have to see the dmesg output to be sure but
it could be a similar issue.

So how to address this. Unfortunately doesn't currently have a mechanism
to allow the user to override its confinement. You can manually update
the generated apparmor profile but snap will regenerate it and throw
your custom rules away the next time it refreshes the application.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064363

Title:
  thunderbird snap on live systems "already running" but not responsive

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2064363/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [blink-dev] Intent to Extend Experiment: Cookie Deprecation Label

2024-06-05 Thread John Delaney

Thanks Mike. I should have included this in the original email, but the
initial I2E for this feature needed 3 LGTMs as it was a non-standard
experiment. Does this extension also require 3?

Thanks again!

On Thu, Jun 6, 2024 at 1:00 AM Mike Taylor  wrote:

> LGTM to extend one more milestone (M126).
> On 6/5/24 11:57 PM, John Delaney wrote:
>
> We would like to extend the Cookie Deprecation Label experimental feature
> being used for Chrome Facilitated Testing.  This feature previously
> received approval to run through the end of M125 (ending roughly June 10,
> 2024).  The Facilitated Testing period, however, is scheduled to run
> through June 30, 2024.
>
> Therefore, we would like to extend Cookie Deprecation Labels for another
> milestone through M126.
>
> Contact emails
>
> johni...@chromium.org, wanderv...@chromium.org, lin...@chromium.org
>
> Explainer
>
>
> https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
>
> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing
>
> Summary
>
> To prepare for the third-party cookie deprecation, it is important to
> understand the full impact of Chrome’s planned transition from third-party
> cookies to the Privacy Sandbox Ads APIs.
>
> This experiment exposes a temporary set of APIs which provide access to
> browser-determined treatment and control groups to support opt-in server
> side testing of the third-party cookie deprecation.
>
> We are exploring ways to address ecosystem feedback that we should
> continue supporting labels after 30 June.  We expect to provide more
> information soon.
>
>
>
> Link to “Intent to Experiment” blink-dev discussion
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ
>
>
>
> Goals for experimentation
>
> The goal of this experiment is to allow adtechs to evaluate the impact of
> third party cookie phase out through opt-in server side testing. We expect
> partners to run experiments downstream from the browser provided treatment
> and control groups.
>
> Experimental timeline
>
> Previously the feature was approved until M125.  We'd like to extend the
> experiment by one milestone to M126 so that we can continue to support the
> Chrome Facilitated Testing period until June 30, 2024. Any experimentation
> after June 30 will be covered by another Intent.
>
> Any risks when the experiment finishes?
>
> Minimal.  The feature is designed in a way that websites must feature
> detect for the web API. This feature is also only available for a subset of
> users.
>
> Reason this experiment is being extended
>
> This feature is necessary to support the ongoing Chrome Facilitated
> Testing effort
> <https://developers.google.com/privacy-sandbox/relevance/setup/web/chrome-facilitated-testing>.
> The Facilitated Testing period is scheduled to complete on June 30, 2024
> which is slightly beyond our previous approval for the feature.  Therefore
> we are requesting to extend the experimental feature access to M126.
>
> Ongoing technical constraints
>
> None
>
> Will this feature be supported on all five Blink platforms supported by
> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
>
> No, not supported on webview.
>
> Link to entry on the feature dashboard
>
> https://chromestatus.com/feature/5189079788683264
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc8339ee-9996-43cf-b3ec-451f01f9e64cn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc8339ee-9996-43cf-b3ec-451f01f9e64cn%40chromium.org?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALW6VLxNAds_fQvc1yGprSq%2BsK8zu%2Bt4O-M1KLOemzDuO1QtZg%40mail.gmail.com.

Re: [Discuss] Debian 12 in the Cloud

2024-06-05 Thread John Hall

Oh my ! It almost sounds like acceptance !

Despite all the naysayers on this list most times it comes up systemctl and
journalctl have become my friends.
 The reason why it's part of so many distributions is that it works. It's
well documented and consistently modular.   I've had problems with
fedora,rhel,  Manjiro and ubuntu over the last 12 years since systemd was
part of the linux distros and and more than one circumstance where I had to
hack to get the system stared up.  None of the problems have been with
systemd. I can remember having plenty of udev troubles back before it was
part of systemd and zero afterward. It seems systemd is a decent kernel
partner not only for loading all the demons and userspace services, also
hot loading all the hardware drivers with udev. Of course some heavy
lifting to get the system started happens before systemd starts.

Maybe one day systemd will add a boot loader. 

I am not making excuses for security issues that should not have happened
and find the criticisms fascinating but systemd for me is just there now.

Sincerely,
John

On Tue, Jun 4, 2024 at 3:59 PM Rich Pieri  wrote:

> On Tue, 4 Jun 2024 09:59:25 -0700
> Kent Borg  wrote:
>
> > On 6/4/24 07:07, Rich Pieri wrote:
> > > Lennart Poettering's take:
> > > http://0pointer.de/blog/projects/systemd.html
> > > http://0pointer.de/blog/projects/why.html
> >
> > Very interesting, thank you. Those point out to me that I should have
> > more sympathy for systemd, they tackled a hard problem
>
> And despite all of the problems systemd has? It largely succeeded.
>
> Which is why distribution maintainers *love* systemd to pieces. It
> solves those problems so that they don't have to do it themselves, and
> does so more or less consistently across different distributions.
>
> upstart didn't so much fail as Canonical decided to embrace systemd
> instead. And I don't blame them for that decision: much more cost
> effective letting Red Hat do all that heavy lifting.
>
> --
> \m/ (--) \m/
> ___
> Discuss mailing list
> Discuss@driftwood.blu.org
> https://driftwood.blu.org/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@driftwood.blu.org
https://driftwood.blu.org/mailman/listinfo/discuss

Re: [PATCH] dma-buf/heaps: Correct the types of fd_flags and heap_flags

2024-06-05 Thread John Stultz

On Wed, Jun 5, 2024 at 7:02 PM Barry Song <21cn...@gmail.com> wrote:
>
> From: Barry Song 
>
> dma_heap_allocation_data defines the UAPI as follows:
>
>  struct dma_heap_allocation_data {
> __u64 len;
> __u32 fd;
> __u32 fd_flags;
> __u64 heap_flags;
>  };
>
> But dma heaps are casting both fd_flags and heap_flags into
> unsigned long. This patch makes dma heaps - cma heap and
> system heap have consistent types with UAPI.
>
> Signed-off-by: Barry Song 

Thanks for submitting this additional cleanup!

Acked-by: John Stultz

[sage-release] Re: Sage 10.4.beta8 released

2024-06-05 Thread John H Palmieri

I don't think I've seen this failure before:

sage -t --long --random-seed=214696321465302976857414484526305325295 
src/sage/plot/plot3d/tachyon.py
**
File "src/sage/plot/plot3d/tachyon.py", line 126, in 
sage.plot.plot3d.tachyon
Failed example:
r2 = os.system('convert '+fname_png+' '+fname_ppm)# optional -- 
ImageMagick
Expected nothing
Got:
WARNING: The convert command is deprecated in IMv7, use "magick"

**
1 item had failures:
   1 of  63 in sage.plot.plot3d.tachyon
[402 tests, 1 failure, 20.75 s]
--
sage -t --long --random-seed=214696321465302976857414484526305325295 
src/sage/plot/plot3d/tachyon.py  # 1 doctest failed

On Sunday, June 2, 2024 at 2:03:52 AM UTC-7 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
> e5f42fac703 (tag: 10.4.beta8, github/develop) Updated SageMath version to 
> 10.4.beta8
> 973a7e3600d gh-38121: Make "[source]" link to develop branch on github
> c86c2bde5b4 gh-38111: GH Actions: Fix upload of macOS wheels to PyPI
> af781fa7125 gh-38110: Update `conway_polynomials`, `database_cubic_hecke`, 
> `database_knotinfo`, `matroid_database`
> 71848f52ad6 gh-38105: Fixing the index set of a rank 1 Cartan matrix
> 2d4f69a2b2e gh-38104: `sage.coding`: Update `# needs`
> e1b22690db4 gh-38100: Remove nitpick_patch_config function
> bbce0cd59e5 gh-38099: Remove deprecated global imports
> da885cffce5 gh-38095: `src/sage/algebras/steenrod/all.py`: Use 
> lazy_import, remove deprecated global import
> dfb90d07be2 gh-38093: add doc on egf_to_ogf and inverse
> c4507b93a52 gh-38092: `doc`: Update `help()` outputs
> 1a68b7ce6f3 gh-38091: Fix doctest when the optional benzene is installed
> aa8e10f80e6 gh-38090: CI Build: Split test-long into multiple jobs, 
> repair Coverage.py upload
> 3d1a66e303c gh-38087: Still add rpath to our own libstdc++, in case we 
> built our own toolchain
> 5d923d3a2f9 gh-38086: `all*.py` files: Use 'del lazy_import', 'del 
> install_doc'
> 284280a7dc5 gh-38082: CI fix: broken livedoc
> 5958e5fe795 gh-38081: Fix sage.symbolic feature after libs/pynac removal
> 013066dfe22 gh-38080: fixing superfluous empty lines in libs folder
> 8b3363c760a gh-38079: fix pep8 E302 in algebras and categories (scripted)
> dc4cde1c6ce gh-38078: remove inheritance from Algebra in FreeAlgebras
> 57cbfc4f7c1 gh-38074: `sage.combinat`: Modularization fixes (imports), 
> update `# needs`
> 27c9f11cd9f gh-38071: `sage.categories`: Update `# needs`, use block tags
> f264dbac987 gh-38070: Add skew Hadamard matrix of order 1588
> f4fe2cc5cd1 gh-38069: docstrings: Change single dash to double dash after 
> input variables
> 2423da6dc87 gh-38068: Correct developer guide's function template
> 98bea40602f gh-38067: `.ci/write-dockerfile.sh`: Quoting fix for 
> `unminimize`
> 2f38eae4130 gh-38066: `sage.geometry`: Modularization fixes (imports), `# 
> needs`
> 1c2bd539d47 gh-38065: `sage.graphs`: Doctest cosmetics
> af423917cf6 gh-38061: `sage.rings`: Modularization fixes (imports)
> 6328dda9e66 gh-38060: `sage.rings`: Modularization fixes for singular
> 156f8e1eb41 gh-38059: `sage.ext.fast_callable`: Docstring cosmetics
> 7597786d602 gh-38056: `SetSystem`: Minor change to accommodate set input
> 9a17b344ea3 gh-38054: new iterators over the partitions of an integer
> 306e6a62047 gh-38039: configure.ac: Check symlinks in the source tree
> a965249ea01 gh-38035: `sage.modular`: Deprecate `is_...` functions
> 296fbe07e58 gh-38032: `sage.combinat.finite_state_machine`: Deprecate 
> `is_...` functions
> 986989a227d gh-38029: Fix interaction of # 32-bit / # 64-bit tag with 
> block-scoped doctest tags
> efc613a76d2 gh-38026: Do not create `spkg-*.log`, `spkg-*.time` files
> 2e4039c6da3 gh-38009: `build/pkgs/ecl`: Update to 24.5.10
> 833274e512f gh-37999: Fix broken pytest integration (including CI failure 
> in `src/conftest_test.py`)
> 1bc90500cd6 gh-37988: CI Build: Replace use of `sage -t --new`
> 7daf84c9b84 gh-37931: libatomic_ops: Update to 7.8.2
> 82ab5870f92 gh-37919: Upgrades and configure fixes for macOS arm64
> e926e6467a1 gh-37912: Filter "RuntimeWarning: networkx backend defined 
> more than once for networkx"
> 5af1f8afb74 gh-37866: LPDictionary: Make it safe to copy dictionaries
> 2d5477e8e55 gh-37857: Replace special handling of optional extensions 
> (bliss, coxeter3, )
> 1e38432bcfb gh-37848: Implement all G(r,p,m) complex reflection groups
> 515e272989c gh-36538: Implement Drinfeld modular forms
> 77323e28f7c (tag: 10.4.beta7) Updated SageMath version to 10.4.beta7
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop

Re: [TV orNotTV] Rob Schneider removed from Regina stage during controversial show

2024-06-05 Thread John Edwards

On Wed, Jun 5, 2024 at 8:50 PM Doug Eastick  wrote:

> Somebody that booked him for a fundraiser must not have been aware of his
> personality.
>
>
>
> Rob Schneider removed from Regina stage during controversial show (msn.com)
> <https://www.msn.com/en-ca/entertainment/tv/rob-schneider-removed-from-regina-stage-during-controversial-show/ar-BB1nHcmp?ocid=msedgdhp=HCTS=a5c219f19768407b986ea4095d542ec5=10>
>

That makes sense, since the last 30 years haven’t happened to Saskatchewan.

John

>
> <https://www.msn.com/en-ca/entertainment/tv/rob-schneider-removed-from-regina-stage-during-controversial-show/ar-BB1nHcmp?ocid=msedgdhp=HCTS=a5c219f19768407b986ea4095d542ec5=10>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TVorNotTV" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tvornottv+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tvornottv/CAJLXtMK2WFmQ6ua3C8KABGQhycnAqEzrNuV3%2B%3D8rBk%2Bc1yp-YQ%40mail.gmail.com.

Re: [GRN] Caneco does anyone know what this translates to

2024-06-05 Thread John de Figueiredo

Victor,“The mixed-race mestizo boys were… racist in Portuguese-held Goa”Do you believe that the so-called “mestizos” (with all due respect, I consider this a racist term, hence the quotation marks)were racists throughout the 451 years of Portuguese rule in Goa?JM de Figueiredo Sent from my iPhoneOn Jun 5, 2024, at 7:42 PM, 'Victor Rangel-ribeiro' via Goa-Research-Net  wrote:
Dear Sonia, I was growing up in Goa in those days, and do not agree that the term 'caneco' was used by the Portuguese to identify a class of people who washed their posteriors after defecating; it was just a racist slur. The mixed race mestizo boys were as racist in Portuguese-held Goa as the Anglo-Indians were in "British India". Attitudes changed after Independence, but they changed very very slowly.Warmest regards,Victor





On Wednesday, June 5, 2024 at 12:56:23 PM EDT, Sonia Gomes  wrote:



Thank you very much Tino. For years my Aunt who was in Liceu was insulted by the mestico boys. They said, ' bonita esta caneca' because she was beautiful. She never knew the meaning. In fact no one did. This is brilliant and fits in. Thank you very much. 
On Wed, 5 Jun, 2024, 8:30 pm Tino de Sa,  wrote:I think that 'caneco' arose from the fact that Goan Catholics, in spite of having adopted Portuguese ways in many respects, chose to ignore the use of toilet paper and preferred to use mugs of water to clean themselves.The Portuguese found this amusing - people wearing western clothes, speaking Portuguese, culturally Portuguese in many ways - but using mugs of water after they defecated.Hence the derogatory nickname.TinoOn Wed, Jun 5, 2024 at 1:08 AM Frederick Noronha  wrote:Just a reminder on what the earlier discussion on this issue said  (in case anyone is interested). Via Goanet:[Goanet] Canecos   Carvalho[Goanet] Canecos   Gabriel de Figueiredo[Goanet] Canecos   Carvalho[Goanet] Canecos   Antonio Menezes[Goanet] Canecos   Alfred de Tavares[Goanet] Canecos   Roland Francis[Goanet] Canecos   Alfred de Tavares[Goanet] Canecos   Victor Rangel-Ribeiro[Goanet] Canecos   Carvalho[Goanet] Canecos   Gabriel de Figueiredo[Goanet] Canecos   Santosh Helekar[Goanet] Canecos   Gilbert Lawrence[Goanet] Canecos   Carvalho[Goanet] Canecos   Gilbert Lawrence[Goanet] Canecos   Monica Reis[Goanet] Canecos   Bernado Colaco[Goanet] Canecos   Carvalho[Goanet] Canecos   Gabe Menezes[Goanet] Canecos   Venantius Pinto[Goanet] Canecos   Gilbert Lawrence[Goanet] Canecos   Mario Goveia[Goanet] Canecos   Gabe Menezes[Goanet] Canecos   Con Menezes[Goanet] Canecos and other racial slurs   Carvalho[Goanet] Canecos   Antonio Menezes[Goanet] Canecos   Victor Rangel-Ribeiro[Goanet-News] Goanet highlights: Who or what is a caneco? (Selma Carvalho)Goanet News Sun, 19 Jul 2009 04:11:54 -0700Goanet highlights by Selma Carvalho

One of the interesting discussion on Goanet has been about the word
“canecos”. The Portuguese used this word, often as a racial slur, for
Catholic Goans but opinions were divided as to its actual meaning.
Here are some of the more interesting viewpoints shared by Goanet
members.Gabriel de Figueiredo:
http://lists.goanet.org/pipermail/goanet-goanet.org/2009-July/179875.html

Bernado Colaco:
http://lists.goanet.org/pipermail/goanet-goanet.org/2009-July/179941.html

Monica Reis of the Indo-Portuguese Art Research Project:
http://lists.goanet.org/pipermail/goanet-goanet.org/2009-July/179934.html

Con Menezes:
http://lists.goanet.org/pipermail/goanet-goanet.org/2009-July/180027.html

Although a consensus was not reached on its actual meaning, there is a
strong possibility that it is a corruption of the word “canarims,” the
old Portuguese word for people of the Konkan coast. The fact that in
Africa, only Catholic Goans were called “canecos” and not the
Africans, leads credence to this theory.On Wed, 5 Jun 2024 at 00:08, 'Carvalho' via Goa-Research-Net  wrote:Dear members,I have for many years been trying to find out the exact meaning of this slur that was used for Goans by the Portuguese 'caneco.' About a decade ago we had an interesting discussion on Goanet about this but nothing conclusive was arrived at. The word itself means mug, but how and why was it used as a slur.Any imput appreciated.Thank you,selma



-- 
You received this message because you are subscribed to the Google Groups "Goa-Research-Net" group.
To unsubscribe from this group and stop receiving emails from it, send an email to goa-research-net+unsubscr...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/goa-research-net/264764771.921553.1717512033254%40mail.yahoo.com.




-- 
You received this message because you are subscribed to the Google Groups "Goa-Research-Net" group.
To unsubscribe from this group and

Re: [ofiwg] Clarification of definition of FI_THREAD_DOMAIN

2024-06-05 Thread Byrne, John (Labs)

The sentence beginning "Since uncontended locks FI_THREAD_SAFE..." should read 
"Since uncontended locks aren't very expensive, FI_THREAD_SAFE..."

From: ofiwg  On Behalf Of Byrne, John 
(Labs)
Sent: Wednesday, June 5, 2024 4:24 PM
To: Xiong, Jianxin ; ofiwg@lists.openfabrics.org
Subject: Re: [ofiwg] Clarification of definition of FI_THREAD_DOMAIN

Thanks. I couldn't find a statement to that effect and every time I read about 
FI_THREAD_DOMAIN, I just kept assuming a single domain with multiple endpoints 
and thinking what a horrible idea that would be. Since uncontended locks 
FI_THREAD_SAFE is certainly the simplest way to go assuming the only frequently 
used locks are on the endpoint and completion paths. If you have a MR Cache and 
are actively using it, then its locking gets annoying as things scale up, 
though.

John

From: Xiong, Jianxin mailto:jianxin.xi...@intel.com>>
Sent: Wednesday, June 5, 2024 3:35 PM
To: Byrne, John (Labs) mailto:john.l.by...@hpe.com>>; 
ofiwg@lists.openfabrics.org<mailto:ofiwg@lists.openfabrics.org>
Subject: RE: Clarification of definition of FI_THREAD_DOMAIN

Your understanding is correct.  The recommendation is based on how feasible to 
have a lockless implementation in the providers. That also matches with how 
middleware like MPI is doing today.

Does FI_THREAD_COMPLETION fits better with the multi-threaded RMA use case? It 
is recommended for scalable endpoints because that's when this threading model 
is more likely supported by the provider.  But using that with regular endpoint 
is totally fine if available.

For simplicity at the user end, maybe just go with FI_THREAD_SAFE.

-Jianxin

From: ofiwg 
mailto:ofiwg-boun...@lists.openfabrics.org>>
 On Behalf Of Byrne, John (Labs)
Sent: Wednesday, June 5, 2024 10:10 AM
To: ofiwg@lists.openfabrics.org<mailto:ofiwg@lists.openfabrics.org>
Subject: [ofiwg] Clarification of definition of FI_THREAD_DOMAIN

FI_THREAD_DOMAIN
A domain serialization model requires applications to serialize access to all 
objects belonging to a domain.

My immediate take on this definition is that if I am multi-threading I have to 
have a single lock that I use to access any object belonging to a fi_domain 
instance; which seems like a terrible idea for multi-threading. However, in 
Jianxin's 2.0 API update at the workshop 
https://www.openfabrics.org/wp-content/uploads/2024-workshop/2024-workshop-presentations/session-1.pdf<https://www.openfabrics.org/wp-content/uploads/2024-workshop/2024-workshop-presentations/session-1.pdf>,
 it says: "Recommend FI_THREAD_DOMAIN for multi-thread app with regular 
endpoint."  If my interpretation of the meaning of FI_THREAD_DOMAIN is correct, 
then the only way this makes sense to me is for the expectation to be that a 
unique fi_domain instance and endpoint be created for each thread. Is this 
correct or is there something I'm misunderstanding? If it is correct, then 
there are some painful implications for multi-threading RMA.

Thanks,

John Byrne

___
ofiwg mailing list
ofiwg@lists.openfabrics.org
https://lists.openfabrics.org/mailman/listinfo/ofiwg

Re: [ofiwg] Clarification of definition of FI_THREAD_DOMAIN

2024-06-05 Thread Byrne, John (Labs)

Thanks. I couldn't find a statement to that effect and every time I read about 
FI_THREAD_DOMAIN, I just kept assuming a single domain with multiple endpoints 
and thinking what a horrible idea that would be. Since uncontended locks 
FI_THREAD_SAFE is certainly the simplest way to go assuming the only frequently 
used locks are on the endpoint and completion paths. If you have a MR Cache and 
are actively using it, then its locking gets annoying as things scale up, 
though.

John

From: Xiong, Jianxin 
Sent: Wednesday, June 5, 2024 3:35 PM
To: Byrne, John (Labs) ; ofiwg@lists.openfabrics.org
Subject: RE: Clarification of definition of FI_THREAD_DOMAIN

Your understanding is correct.  The recommendation is based on how feasible to 
have a lockless implementation in the providers. That also matches with how 
middleware like MPI is doing today.

Does FI_THREAD_COMPLETION fits better with the multi-threaded RMA use case? It 
is recommended for scalable endpoints because that's when this threading model 
is more likely supported by the provider.  But using that with regular endpoint 
is totally fine if available.

For simplicity at the user end, maybe just go with FI_THREAD_SAFE.

-Jianxin

From: ofiwg 
mailto:ofiwg-boun...@lists.openfabrics.org>>
 On Behalf Of Byrne, John (Labs)
Sent: Wednesday, June 5, 2024 10:10 AM
To: ofiwg@lists.openfabrics.org<mailto:ofiwg@lists.openfabrics.org>
Subject: [ofiwg] Clarification of definition of FI_THREAD_DOMAIN

FI_THREAD_DOMAIN
A domain serialization model requires applications to serialize access to all 
objects belonging to a domain.

My immediate take on this definition is that if I am multi-threading I have to 
have a single lock that I use to access any object belonging to a fi_domain 
instance; which seems like a terrible idea for multi-threading. However, in 
Jianxin's 2.0 API update at the workshop 
https://www.openfabrics.org/wp-content/uploads/2024-workshop/2024-workshop-presentations/session-1.pdf<https://www.openfabrics.org/wp-content/uploads/2024-workshop/2024-workshop-presentations/session-1.pdf>,
 it says: "Recommend FI_THREAD_DOMAIN for multi-thread app with regular 
endpoint."  If my interpretation of the meaning of FI_THREAD_DOMAIN is correct, 
then the only way this makes sense to me is for the expectation to be that a 
unique fi_domain instance and endpoint be created for each thread. Is this 
correct or is there something I'm misunderstanding? If it is correct, then 
there are some painful implications for multi-threading RMA.

Thanks,

John Byrne


___
ofiwg mailing list
ofiwg@lists.openfabrics.org
https://lists.openfabrics.org/mailman/listinfo/ofiwg

Re: June PUG is up

2024-06-05 Thread John Francis

On Thu, Jun 06, 2024 at 12:42:39AM +0200, Ralf R Radermacher wrote:
> Am 06.06.24 um 00:09 schrieb John Francis:
> > Maybe it's time to add a section to the PUG for images created with 
> > non-Pentax
> > gear. Or maybe it isn't - I don't know hom many other non-Pentax using 
> > PDMLers
> > are still around.
> 
> What keeps you from posting photos shot while you were using Pentax gear?
> 
> I haven't been able to take any new photos for the last two years and my
> days as a 'picture taking' photographer are over but I still have tens of
> thousands of RAW and scanned analog photos to sift through and quite a few
> to publish.

Nothing stops me from posting old photographs - I shoot significantly less
than some people here, so I've got every digital image I took available.
(And boxes of slides, negatives, etc., very few of which have been scanned).
But that doesn't help me get to be a better photographer. I sometimes used
the PUG topic as a way to prompt myself out of my comfort zone and try some
shots I'd never have thought of myself. Much of the time it didn't result
in anything I wanted to show anybody else, but there were occasions when I
came up with something I was pleased with, and even a few times when I ended
up with an image I felt was worth submitting.

--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

[Bug 2068024] Re: race_sched in ubuntu_stress_smoke_test will cause kernel panic on 6.8 with Azure Standard_A2_v2 instance

2024-06-05 Thread John Cabaj

Mainline build using v6.7 works as well. Proceeding bisect between 6.7
and 6.8

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068024

Title:
  race_sched in ubuntu_stress_smoke_test will cause kernel panic on 6.8
  with Azure Standard_A2_v2 instance

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2068024/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: June PUG is up

2024-06-05 Thread John Francis

On Wed, Jun 05, 2024 at 09:33:55PM +1000, Brian Walters wrote:
> G'day all
> 
> Enjoy the (disappointingly small) gallery here:
> 
> http://pug.komkon.org/

Unfortunately I suspect the number of contributors will continue to decline.

It's been 2 1/2 years since I picked up a Pentax (except for yesterday when
I charged up the K5 and checked that it still appeared to be in working order).

I was never a frequent contributor to the PUG, but during that time there have 
been a few galleries where I would have been tempted to submit something.
I know I'm not the only PDMLer who has, for various reasons, switched to a
different brand. I may be using an Olympus now, but I still think of myself
as a PDMLer; I haven't even looked for an Olympus User's Group I could join.

Maybe it's time to add a section to the PUG for images created with non-Pentax
gear. Or maybe it isn't - I don't know hom many other non-Pentax using PDMLers
are still around.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Re: 41dfea24eec panics during ata attach on ESXi VM


On 6/5/24 4:35 AM, Yuri Pankov wrote:

After updating to 41dfea24eec (GENERIC-NODEBUG), ESXi VM started to
panic while attaching atapci children.  I was unable to grab original
boot panic data ("keyboard" dead), but was able to boot with
hint.ata.0.disabled=1, hint.ata.1.disabled=1, and `devctl enable ata0`
reproduced the issue:

ata0:  at channel 0 on atapci0


This should be fixed now by commit 56b822a17cde5940909633c50623d463191a7852.
Sorry for the breakage.

--
John Baldwin

git: f46d4971b5af - main - nvmf: Handle shutdowns more gracefully

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=f46d4971b5afdfecef3ae5979d7c96e9817aedee

commit f46d4971b5afdfecef3ae5979d7c96e9817aedee
Author: John Baldwin 
AuthorDate: 2024-06-05 19:59:28 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:59:28 +

nvmf: Handle shutdowns more gracefully

If an association is disconnected during a clean shutdown, abort all
pending and future I/O requests with an error to avoid hangs either due
to filesystem unmounts or a stuck GEOM event.

If an association is connected during a clean shutdown, gracefully
disconnect from the remote controller and close the open queues.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45462
---
 sys/dev/nvmf/host/nvmf.c | 71 ++--
 sys/dev/nvmf/host/nvmf_ns.c  | 27 +++--
 sys/dev/nvmf/host/nvmf_sim.c | 16 --
 sys/dev/nvmf/host/nvmf_var.h |  7 +
 4 files changed, 114 insertions(+), 7 deletions(-)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index c309836ed8a8..47cdbe7e47fd 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -8,12 +8,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +33,8 @@ SYSCTL_BOOL(_kern_nvmf, OID_AUTO, fail_on_disconnection, 
CTLFLAG_RWTUN,
 MALLOC_DEFINE(M_NVMF, "nvmf", "NVMe over Fabrics host");
 
 static voidnvmf_disconnect_task(void *arg, int pending);
+static voidnvmf_shutdown_pre_sync(void *arg, int howto);
+static voidnvmf_shutdown_post_sync(void *arg, int howto);
 
 void
 nvmf_complete(void *arg, const struct nvme_completion *cqe)
@@ -528,6 +532,11 @@ nvmf_attach(device_t dev)
goto out;
}
 
+   sc->shutdown_pre_sync_eh = EVENTHANDLER_REGISTER(shutdown_pre_sync,
+   nvmf_shutdown_pre_sync, sc, SHUTDOWN_PRI_FIRST);
+   sc->shutdown_post_sync_eh = EVENTHANDLER_REGISTER(shutdown_post_sync,
+   nvmf_shutdown_post_sync, sc, SHUTDOWN_PRI_FIRST);
+
return (0);
 out:
if (sc->ns != NULL) {
@@ -698,6 +707,62 @@ out:
return (error);
 }
 
+static void
+nvmf_shutdown_pre_sync(void *arg, int howto)
+{
+   struct nvmf_softc *sc = arg;
+
+   if ((howto & RB_NOSYNC) != 0 || SCHEDULER_STOPPED())
+   return;
+
+   /*
+* If this association is disconnected, abort any pending
+* requests with an error to permit filesystems to unmount
+* without hanging.
+*/
+   sx_xlock(>connection_lock);
+   if (sc->admin != NULL || sc->detaching) {
+   sx_xunlock(>connection_lock);
+   return;
+   }
+
+   for (u_int i = 0; i < sc->cdata->nn; i++) {
+   if (sc->ns[i] != NULL)
+   nvmf_shutdown_ns(sc->ns[i]);
+   }
+   nvmf_shutdown_sim(sc);
+   sx_xunlock(>connection_lock);
+}
+
+static void
+nvmf_shutdown_post_sync(void *arg, int howto)
+{
+   struct nvmf_softc *sc = arg;
+
+   if ((howto & RB_NOSYNC) != 0 || SCHEDULER_STOPPED())
+   return;
+
+   /*
+* If this association is connected, disconnect gracefully.
+*/
+   sx_xlock(>connection_lock);
+   if (sc->admin == NULL || sc->detaching) {
+   sx_xunlock(>connection_lock);
+   return;
+   }
+
+   callout_drain(>ka_tx_timer);
+   callout_drain(>ka_rx_timer);
+
+   nvmf_shutdown_controller(sc);
+   for (u_int i = 0; i < sc->num_io_queues; i++) {
+   nvmf_destroy_qp(sc->io[i]);
+   }
+   nvmf_destroy_qp(sc->admin);
+   sc->admin = NULL;
+   sx_xunlock(>connection_lock);
+}
+
 static int
 nvmf_detach(device_t dev)
 {
@@ -710,6 +775,9 @@ nvmf_detach(device_t dev)
sc->detaching = true;
sx_xunlock(>connection_lock);
 
+   EVENTHANDLER_DEREGISTER(shutdown_pre_sync, sc->shutdown_pre_sync_eh);
+   EVENTHANDLER_DEREGISTER(shutdown_pre_sync, sc->shutdown_post_sync_eh);
+
nvmf_destroy_sim(sc);
for (i = 0; i < sc->cdata->nn; i++) {
if (sc->ns[i] != NULL)
@@ -1006,9 +1074,6 @@ static device_method_t nvmf_methods[] = {
DEVMETHOD(device_probe, nvmf_probe),
DEVMETHOD(device_attach,nvmf_attach),
DEVMETHOD(device_detach,nvmf_detach),
-#if 0
-   DEVMETHOD(device_shutdown,  nvmf_shutdown),
-#endif
DEVMETHOD_END
 };
 
diff --git a/sys/dev/nvmf/host/nvmf_ns.c b/sys/dev/nvmf/host/nvmf_ns.c
index 8381cc4aec54..87cb4fa68001 100644
--- a/sys/dev/nvmf/host/nvmf_ns.c
+++ b/sys/dev/nvmf/host/nvmf_ns.c
@@ -29,6 +29,7 @@ struct nvmf_namespace {
u_int   flags;
ui

git: aacaeeee8ecd - main - nvmf: Permit failing I/O requests while disconnected

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=aaca8ecd7084a33b2d8e140aad37b3b0eddc

commit aaca8ecd7084a33b2d8e140aad37b3b0eddc
Author: John Baldwin 
AuthorDate: 2024-06-05 19:54:15 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:59:07 +

nvmf: Permit failing I/O requests while disconnected

Add a kern.nvmf.fail_on_disconnection sysctl similar to the
kern.iscsi.fail_on_disconnection sysctl.  This causes pending I/O
requests to fail with an error if an association is disconnected
instead of requeueing to be retried once the association is
reconnected.  As with iSCSI, the default is to queue and retry
operations.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45308
---
 share/man/man4/nvmf.4| 24 +++-
 sys/dev/nvmf/host/nvmf.c |  5 +
 sys/dev/nvmf/host/nvmf_ns.c  | 25 -
 sys/dev/nvmf/host/nvmf_sim.c | 10 --
 sys/dev/nvmf/host/nvmf_var.h |  3 +++
 5 files changed, 59 insertions(+), 8 deletions(-)

diff --git a/share/man/man4/nvmf.4 b/share/man/man4/nvmf.4
index 8afbb4d9daaf..298365acefa9 100644
--- a/share/man/man4/nvmf.4
+++ b/share/man/man4/nvmf.4
@@ -3,7 +3,7 @@
 .\"
 .\" Copyright (c) 2024 Chelsio Communications, Inc.
 .\"
-.Dd May 2, 2024
+.Dd June 5, 2024
 .Dt NVMF 4
 .Os
 .Sh NAME
@@ -65,6 +65,28 @@ disk driver.
 Associations require a supported transport such as
 .Xr nvmf_tcp 4
 for associations using TCP/IP.
+.Sh SYSCTL VARIABLES
+The following variables are available as both
+.Xr sysctl 8
+variables and
+.Xr loader 8
+tunables:
+.Bl -tag -width indent
+.It Va kern.nvmf.fail_on_disconnection
+Determines the behavior when an association's connection is interrupted.
+By default, input/output operations are suspended while a host is disconnected.
+This includes operations pending at the time the association's connection was
+interrupted as well as new requests submitted while the host is disconnected.
+Once a new association is established, suspended I/O requests are retried.
+When set to 1, input/output operations fail with
+.Er EIO
+while a host is disconnected and
+.Xr nda 4
+peripherals are destroyed after the first failed I/O request.
+Note that any destroyed
+.Xr nda 4
+peripherals will be recreated after a new association is established.
+.El
 .Sh SEE ALSO
 .Xr nda 4 ,
 .Xr nvme 4 ,
diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index 9684170c1de9..c309836ed8a8 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,10 @@
 
 static struct cdevsw nvmf_cdevsw;
 
+bool nvmf_fail_disconnect = false;
+SYSCTL_BOOL(_kern_nvmf, OID_AUTO, fail_on_disconnection, CTLFLAG_RWTUN,
+_fail_disconnect, 0, "Fail I/O requests on connection failure");
+
 MALLOC_DEFINE(M_NVMF, "nvmf", "NVMe over Fabrics host");
 
 static voidnvmf_disconnect_task(void *arg, int pending);
diff --git a/sys/dev/nvmf/host/nvmf_ns.c b/sys/dev/nvmf/host/nvmf_ns.c
index 0727ca960a57..8381cc4aec54 100644
--- a/sys/dev/nvmf/host/nvmf_ns.c
+++ b/sys/dev/nvmf/host/nvmf_ns.c
@@ -84,13 +84,22 @@ nvmf_ns_biodone(struct bio *bio)
ns = bio->bio_dev->si_drv1;
 
/* If a request is aborted, resubmit or queue it for resubmission. */
-   if (bio->bio_error == ECONNABORTED) {
+   if (bio->bio_error == ECONNABORTED && !nvmf_fail_disconnect) {
bio->bio_error = 0;
bio->bio_driver2 = 0;
mtx_lock(>lock);
if (ns->disconnected) {
-   TAILQ_INSERT_TAIL(>pending_bios, bio, bio_queue);
-   mtx_unlock(>lock);
+   if (nvmf_fail_disconnect) {
+   mtx_unlock(>lock);
+   bio->bio_error = ECONNABORTED;
+   bio->bio_flags |= BIO_ERROR;
+   bio->bio_resid = bio->bio_bcount;
+   biodone(bio);
+   } else {
+   TAILQ_INSERT_TAIL(>pending_bios, bio,
+   bio_queue);
+   mtx_unlock(>lock);
+   }
} else {
mtx_unlock(>lock);
nvmf_ns_strategy(bio);
@@ -163,6 +172,7 @@ nvmf_ns_submit_bio(struct nvmf_namespace *ns, struct bio 
*bio)
struct nvme_dsm_range *dsm_range;
struct memdesc mem;
uint64_t lba, lba_count;
+   int error;
 
dsm_range = NULL;
memset(, 0, sizeof(cmd));
@@ -201,10 +211,15 @@ nvmf_ns_submit_bio(struct nvmf_namespace *ns, struct bio 
*bio)
 
mtx_l

git: aacaeeee8ecd - main - nvmf: Permit failing I/O requests while disconnected

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=aaca8ecd7084a33b2d8e140aad37b3b0eddc

commit aaca8ecd7084a33b2d8e140aad37b3b0eddc
Author: John Baldwin 
AuthorDate: 2024-06-05 19:54:15 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:59:07 +

nvmf: Permit failing I/O requests while disconnected

Add a kern.nvmf.fail_on_disconnection sysctl similar to the
kern.iscsi.fail_on_disconnection sysctl.  This causes pending I/O
requests to fail with an error if an association is disconnected
instead of requeueing to be retried once the association is
reconnected.  As with iSCSI, the default is to queue and retry
operations.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45308
---
 share/man/man4/nvmf.4| 24 +++-
 sys/dev/nvmf/host/nvmf.c |  5 +
 sys/dev/nvmf/host/nvmf_ns.c  | 25 -
 sys/dev/nvmf/host/nvmf_sim.c | 10 --
 sys/dev/nvmf/host/nvmf_var.h |  3 +++
 5 files changed, 59 insertions(+), 8 deletions(-)

diff --git a/share/man/man4/nvmf.4 b/share/man/man4/nvmf.4
index 8afbb4d9daaf..298365acefa9 100644
--- a/share/man/man4/nvmf.4
+++ b/share/man/man4/nvmf.4
@@ -3,7 +3,7 @@
 .\"
 .\" Copyright (c) 2024 Chelsio Communications, Inc.
 .\"
-.Dd May 2, 2024
+.Dd June 5, 2024
 .Dt NVMF 4
 .Os
 .Sh NAME
@@ -65,6 +65,28 @@ disk driver.
 Associations require a supported transport such as
 .Xr nvmf_tcp 4
 for associations using TCP/IP.
+.Sh SYSCTL VARIABLES
+The following variables are available as both
+.Xr sysctl 8
+variables and
+.Xr loader 8
+tunables:
+.Bl -tag -width indent
+.It Va kern.nvmf.fail_on_disconnection
+Determines the behavior when an association's connection is interrupted.
+By default, input/output operations are suspended while a host is disconnected.
+This includes operations pending at the time the association's connection was
+interrupted as well as new requests submitted while the host is disconnected.
+Once a new association is established, suspended I/O requests are retried.
+When set to 1, input/output operations fail with
+.Er EIO
+while a host is disconnected and
+.Xr nda 4
+peripherals are destroyed after the first failed I/O request.
+Note that any destroyed
+.Xr nda 4
+peripherals will be recreated after a new association is established.
+.El
 .Sh SEE ALSO
 .Xr nda 4 ,
 .Xr nvme 4 ,
diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index 9684170c1de9..c309836ed8a8 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,10 @@
 
 static struct cdevsw nvmf_cdevsw;
 
+bool nvmf_fail_disconnect = false;
+SYSCTL_BOOL(_kern_nvmf, OID_AUTO, fail_on_disconnection, CTLFLAG_RWTUN,
+_fail_disconnect, 0, "Fail I/O requests on connection failure");
+
 MALLOC_DEFINE(M_NVMF, "nvmf", "NVMe over Fabrics host");
 
 static voidnvmf_disconnect_task(void *arg, int pending);
diff --git a/sys/dev/nvmf/host/nvmf_ns.c b/sys/dev/nvmf/host/nvmf_ns.c
index 0727ca960a57..8381cc4aec54 100644
--- a/sys/dev/nvmf/host/nvmf_ns.c
+++ b/sys/dev/nvmf/host/nvmf_ns.c
@@ -84,13 +84,22 @@ nvmf_ns_biodone(struct bio *bio)
ns = bio->bio_dev->si_drv1;
 
/* If a request is aborted, resubmit or queue it for resubmission. */
-   if (bio->bio_error == ECONNABORTED) {
+   if (bio->bio_error == ECONNABORTED && !nvmf_fail_disconnect) {
bio->bio_error = 0;
bio->bio_driver2 = 0;
mtx_lock(>lock);
if (ns->disconnected) {
-   TAILQ_INSERT_TAIL(>pending_bios, bio, bio_queue);
-   mtx_unlock(>lock);
+   if (nvmf_fail_disconnect) {
+   mtx_unlock(>lock);
+   bio->bio_error = ECONNABORTED;
+   bio->bio_flags |= BIO_ERROR;
+   bio->bio_resid = bio->bio_bcount;
+   biodone(bio);
+   } else {
+   TAILQ_INSERT_TAIL(>pending_bios, bio,
+   bio_queue);
+   mtx_unlock(>lock);
+   }
} else {
mtx_unlock(>lock);
nvmf_ns_strategy(bio);
@@ -163,6 +172,7 @@ nvmf_ns_submit_bio(struct nvmf_namespace *ns, struct bio 
*bio)
struct nvme_dsm_range *dsm_range;
struct memdesc mem;
uint64_t lba, lba_count;
+   int error;
 
dsm_range = NULL;
memset(, 0, sizeof(cmd));
@@ -201,10 +211,15 @@ nvmf_ns_submit_bio(struct nvmf_namespace *ns, struct bio 
*bio)
 
mtx_l

git: f46d4971b5af - main - nvmf: Handle shutdowns more gracefully

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=f46d4971b5afdfecef3ae5979d7c96e9817aedee

commit f46d4971b5afdfecef3ae5979d7c96e9817aedee
Author: John Baldwin 
AuthorDate: 2024-06-05 19:59:28 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:59:28 +

nvmf: Handle shutdowns more gracefully

If an association is disconnected during a clean shutdown, abort all
pending and future I/O requests with an error to avoid hangs either due
to filesystem unmounts or a stuck GEOM event.

If an association is connected during a clean shutdown, gracefully
disconnect from the remote controller and close the open queues.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45462
---
 sys/dev/nvmf/host/nvmf.c | 71 ++--
 sys/dev/nvmf/host/nvmf_ns.c  | 27 +++--
 sys/dev/nvmf/host/nvmf_sim.c | 16 --
 sys/dev/nvmf/host/nvmf_var.h |  7 +
 4 files changed, 114 insertions(+), 7 deletions(-)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index c309836ed8a8..47cdbe7e47fd 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -8,12 +8,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +33,8 @@ SYSCTL_BOOL(_kern_nvmf, OID_AUTO, fail_on_disconnection, 
CTLFLAG_RWTUN,
 MALLOC_DEFINE(M_NVMF, "nvmf", "NVMe over Fabrics host");
 
 static voidnvmf_disconnect_task(void *arg, int pending);
+static voidnvmf_shutdown_pre_sync(void *arg, int howto);
+static voidnvmf_shutdown_post_sync(void *arg, int howto);
 
 void
 nvmf_complete(void *arg, const struct nvme_completion *cqe)
@@ -528,6 +532,11 @@ nvmf_attach(device_t dev)
goto out;
}
 
+   sc->shutdown_pre_sync_eh = EVENTHANDLER_REGISTER(shutdown_pre_sync,
+   nvmf_shutdown_pre_sync, sc, SHUTDOWN_PRI_FIRST);
+   sc->shutdown_post_sync_eh = EVENTHANDLER_REGISTER(shutdown_post_sync,
+   nvmf_shutdown_post_sync, sc, SHUTDOWN_PRI_FIRST);
+
return (0);
 out:
if (sc->ns != NULL) {
@@ -698,6 +707,62 @@ out:
return (error);
 }
 
+static void
+nvmf_shutdown_pre_sync(void *arg, int howto)
+{
+   struct nvmf_softc *sc = arg;
+
+   if ((howto & RB_NOSYNC) != 0 || SCHEDULER_STOPPED())
+   return;
+
+   /*
+* If this association is disconnected, abort any pending
+* requests with an error to permit filesystems to unmount
+* without hanging.
+*/
+   sx_xlock(>connection_lock);
+   if (sc->admin != NULL || sc->detaching) {
+   sx_xunlock(>connection_lock);
+   return;
+   }
+
+   for (u_int i = 0; i < sc->cdata->nn; i++) {
+   if (sc->ns[i] != NULL)
+   nvmf_shutdown_ns(sc->ns[i]);
+   }
+   nvmf_shutdown_sim(sc);
+   sx_xunlock(>connection_lock);
+}
+
+static void
+nvmf_shutdown_post_sync(void *arg, int howto)
+{
+   struct nvmf_softc *sc = arg;
+
+   if ((howto & RB_NOSYNC) != 0 || SCHEDULER_STOPPED())
+   return;
+
+   /*
+* If this association is connected, disconnect gracefully.
+*/
+   sx_xlock(>connection_lock);
+   if (sc->admin == NULL || sc->detaching) {
+   sx_xunlock(>connection_lock);
+   return;
+   }
+
+   callout_drain(>ka_tx_timer);
+   callout_drain(>ka_rx_timer);
+
+   nvmf_shutdown_controller(sc);
+   for (u_int i = 0; i < sc->num_io_queues; i++) {
+   nvmf_destroy_qp(sc->io[i]);
+   }
+   nvmf_destroy_qp(sc->admin);
+   sc->admin = NULL;
+   sx_xunlock(>connection_lock);
+}
+
 static int
 nvmf_detach(device_t dev)
 {
@@ -710,6 +775,9 @@ nvmf_detach(device_t dev)
sc->detaching = true;
sx_xunlock(>connection_lock);
 
+   EVENTHANDLER_DEREGISTER(shutdown_pre_sync, sc->shutdown_pre_sync_eh);
+   EVENTHANDLER_DEREGISTER(shutdown_pre_sync, sc->shutdown_post_sync_eh);
+
nvmf_destroy_sim(sc);
for (i = 0; i < sc->cdata->nn; i++) {
if (sc->ns[i] != NULL)
@@ -1006,9 +1074,6 @@ static device_method_t nvmf_methods[] = {
DEVMETHOD(device_probe, nvmf_probe),
DEVMETHOD(device_attach,nvmf_attach),
DEVMETHOD(device_detach,nvmf_detach),
-#if 0
-   DEVMETHOD(device_shutdown,  nvmf_shutdown),
-#endif
DEVMETHOD_END
 };
 
diff --git a/sys/dev/nvmf/host/nvmf_ns.c b/sys/dev/nvmf/host/nvmf_ns.c
index 8381cc4aec54..87cb4fa68001 100644
--- a/sys/dev/nvmf/host/nvmf_ns.c
+++ b/sys/dev/nvmf/host/nvmf_ns.c
@@ -29,6 +29,7 @@ struct nvmf_namespace {
u_int   flags;
ui

git: e140f85dc194 - main - nvmf: Rescan namespaces after reconnecting

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=e140f85dc1941ecdfb35f49f0d7f97b24e2a54ea

commit e140f85dc1941ecdfb35f49f0d7f97b24e2a54ea
Author: John Baldwin 
AuthorDate: 2024-06-05 19:53:08 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:53:08 +

nvmf: Rescan namespaces after reconnecting

While a host was disconnected from a remote controller, namespaces
might have been added, removed, or altered properties.  Rescan the
namespaces after reconnecting to detect any such changes.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45461
---
 sys/dev/nvmf/host/nvmf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index 1e7fce42b2a3..9684170c1de9 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -685,6 +685,8 @@ nvmf_reconnect_host(struct nvmf_softc *sc, struct 
nvmf_handoff_host *hh)
nvmf_reconnect_ns(sc->ns[i]);
}
nvmf_reconnect_sim(sc);
+
+   nvmf_rescan_all_ns(sc);
 out:
sx_xunlock(>connection_lock);
nvmf_free_ivars();

git: e140f85dc194 - main - nvmf: Rescan namespaces after reconnecting

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=e140f85dc1941ecdfb35f49f0d7f97b24e2a54ea

commit e140f85dc1941ecdfb35f49f0d7f97b24e2a54ea
Author: John Baldwin 
AuthorDate: 2024-06-05 19:53:08 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:53:08 +

nvmf: Rescan namespaces after reconnecting

While a host was disconnected from a remote controller, namespaces
might have been added, removed, or altered properties.  Rescan the
namespaces after reconnecting to detect any such changes.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45461
---
 sys/dev/nvmf/host/nvmf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index 1e7fce42b2a3..9684170c1de9 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -685,6 +685,8 @@ nvmf_reconnect_host(struct nvmf_softc *sc, struct 
nvmf_handoff_host *hh)
nvmf_reconnect_ns(sc->ns[i]);
}
nvmf_reconnect_sim(sc);
+
+   nvmf_rescan_all_ns(sc);
 out:
sx_xunlock(>connection_lock);
nvmf_free_ivars();

git: f6d434f110fd - main - nvmf: Rescan all namespaces if the changed NS log page is too large

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=f6d434f110fd95e346f18fb09a6f91f36b528d2d

commit f6d434f110fd95e346f18fb09a6f91f36b528d2d
Author: John Baldwin 
AuthorDate: 2024-06-05 19:52:43 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:52:43 +

nvmf: Rescan all namespaces if the changed NS log page is too large

Previously this just punted with a warning message.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45460
---
 sys/dev/nvmf/host/nvmf.c | 49 
 sys/dev/nvmf/host/nvmf_aer.c |  2 +-
 sys/dev/nvmf/host/nvmf_var.h |  1 +
 3 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index 086df5f637c9..1e7fce42b2a3 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -804,6 +804,55 @@ nvmf_rescan_ns(struct nvmf_softc *sc, uint32_t nsid)
free(data, M_NVMF);
 }
 
+static void
+nvmf_purge_namespaces(struct nvmf_softc *sc, uint32_t first_nsid,
+uint32_t next_valid_nsid)
+{
+   struct nvmf_namespace *ns;
+
+   for (uint32_t nsid = first_nsid; nsid < next_valid_nsid; nsid++)
+   {
+   /* XXX: Needs locking around sc->ns[]. */
+   ns = sc->ns[nsid - 1];
+   if (ns != NULL) {
+   nvmf_destroy_ns(ns);
+   sc->ns[nsid - 1] = NULL;
+
+   nvmf_sim_rescan_ns(sc, nsid);
+   }
+   }
+}
+
+static bool
+nvmf_rescan_ns_cb(struct nvmf_softc *sc, uint32_t nsid,
+const struct nvme_namespace_data *data, void *arg)
+{
+   uint32_t *last_nsid = arg;
+
+   /* Check for any gaps prior to this namespace. */
+   nvmf_purge_namespaces(sc, *last_nsid + 1, nsid);
+   *last_nsid = nsid;
+
+   nvmf_rescan_ns_1(sc, nsid, data);
+   return (true);
+}
+
+void
+nvmf_rescan_all_ns(struct nvmf_softc *sc)
+{
+   uint32_t last_nsid;
+
+   last_nsid = 0;
+   if (!nvmf_scan_active_namespaces(sc, nvmf_rescan_ns_cb, _nsid))
+   return;
+
+   /*
+* Check for any namespace devices after the last active
+* namespace.
+*/
+   nvmf_purge_namespaces(sc, last_nsid + 1, sc->cdata->nn + 1);
+}
+
 int
 nvmf_passthrough_cmd(struct nvmf_softc *sc, struct nvme_pt_command *pt,
 bool admin)
diff --git a/sys/dev/nvmf/host/nvmf_aer.c b/sys/dev/nvmf/host/nvmf_aer.c
index 4c950f1518d0..2f7f177d0421 100644
--- a/sys/dev/nvmf/host/nvmf_aer.c
+++ b/sys/dev/nvmf/host/nvmf_aer.c
@@ -62,7 +62,7 @@ nvmf_handle_changed_namespaces(struct nvmf_softc *sc,
 * probably just rescan the entire set of namespaces.
 */
if (ns_list->ns[0] == 0x) {
-   device_printf(sc->dev, "too many changed namespaces\n");
+   nvmf_rescan_all_ns(sc);
return;
}
 
diff --git a/sys/dev/nvmf/host/nvmf_var.h b/sys/dev/nvmf/host/nvmf_var.h
index e0f6d33d2a73..2fa0216baab8 100644
--- a/sys/dev/nvmf/host/nvmf_var.h
+++ b/sys/dev/nvmf/host/nvmf_var.h
@@ -148,6 +148,7 @@ int nvmf_init_ivars(struct nvmf_ivars *ivars, struct 
nvmf_handoff_host *hh);
 void   nvmf_free_ivars(struct nvmf_ivars *ivars);
 void   nvmf_disconnect(struct nvmf_softc *sc);
 void   nvmf_rescan_ns(struct nvmf_softc *sc, uint32_t nsid);
+void   nvmf_rescan_all_ns(struct nvmf_softc *sc);
 intnvmf_passthrough_cmd(struct nvmf_softc *sc, struct nvme_pt_command *pt,
 bool admin);

git: f6d434f110fd - main - nvmf: Rescan all namespaces if the changed NS log page is too large

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=f6d434f110fd95e346f18fb09a6f91f36b528d2d

commit f6d434f110fd95e346f18fb09a6f91f36b528d2d
Author: John Baldwin 
AuthorDate: 2024-06-05 19:52:43 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:52:43 +

nvmf: Rescan all namespaces if the changed NS log page is too large

Previously this just punted with a warning message.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45460
---
 sys/dev/nvmf/host/nvmf.c | 49 
 sys/dev/nvmf/host/nvmf_aer.c |  2 +-
 sys/dev/nvmf/host/nvmf_var.h |  1 +
 3 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index 086df5f637c9..1e7fce42b2a3 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -804,6 +804,55 @@ nvmf_rescan_ns(struct nvmf_softc *sc, uint32_t nsid)
free(data, M_NVMF);
 }
 
+static void
+nvmf_purge_namespaces(struct nvmf_softc *sc, uint32_t first_nsid,
+uint32_t next_valid_nsid)
+{
+   struct nvmf_namespace *ns;
+
+   for (uint32_t nsid = first_nsid; nsid < next_valid_nsid; nsid++)
+   {
+   /* XXX: Needs locking around sc->ns[]. */
+   ns = sc->ns[nsid - 1];
+   if (ns != NULL) {
+   nvmf_destroy_ns(ns);
+   sc->ns[nsid - 1] = NULL;
+
+   nvmf_sim_rescan_ns(sc, nsid);
+   }
+   }
+}
+
+static bool
+nvmf_rescan_ns_cb(struct nvmf_softc *sc, uint32_t nsid,
+const struct nvme_namespace_data *data, void *arg)
+{
+   uint32_t *last_nsid = arg;
+
+   /* Check for any gaps prior to this namespace. */
+   nvmf_purge_namespaces(sc, *last_nsid + 1, nsid);
+   *last_nsid = nsid;
+
+   nvmf_rescan_ns_1(sc, nsid, data);
+   return (true);
+}
+
+void
+nvmf_rescan_all_ns(struct nvmf_softc *sc)
+{
+   uint32_t last_nsid;
+
+   last_nsid = 0;
+   if (!nvmf_scan_active_namespaces(sc, nvmf_rescan_ns_cb, _nsid))
+   return;
+
+   /*
+* Check for any namespace devices after the last active
+* namespace.
+*/
+   nvmf_purge_namespaces(sc, last_nsid + 1, sc->cdata->nn + 1);
+}
+
 int
 nvmf_passthrough_cmd(struct nvmf_softc *sc, struct nvme_pt_command *pt,
 bool admin)
diff --git a/sys/dev/nvmf/host/nvmf_aer.c b/sys/dev/nvmf/host/nvmf_aer.c
index 4c950f1518d0..2f7f177d0421 100644
--- a/sys/dev/nvmf/host/nvmf_aer.c
+++ b/sys/dev/nvmf/host/nvmf_aer.c
@@ -62,7 +62,7 @@ nvmf_handle_changed_namespaces(struct nvmf_softc *sc,
 * probably just rescan the entire set of namespaces.
 */
if (ns_list->ns[0] == 0x) {
-   device_printf(sc->dev, "too many changed namespaces\n");
+   nvmf_rescan_all_ns(sc);
return;
}
 
diff --git a/sys/dev/nvmf/host/nvmf_var.h b/sys/dev/nvmf/host/nvmf_var.h
index e0f6d33d2a73..2fa0216baab8 100644
--- a/sys/dev/nvmf/host/nvmf_var.h
+++ b/sys/dev/nvmf/host/nvmf_var.h
@@ -148,6 +148,7 @@ int nvmf_init_ivars(struct nvmf_ivars *ivars, struct 
nvmf_handoff_host *hh);
 void   nvmf_free_ivars(struct nvmf_ivars *ivars);
 void   nvmf_disconnect(struct nvmf_softc *sc);
 void   nvmf_rescan_ns(struct nvmf_softc *sc, uint32_t nsid);
+void   nvmf_rescan_all_ns(struct nvmf_softc *sc);
 intnvmf_passthrough_cmd(struct nvmf_softc *sc, struct nvme_pt_command *pt,
 bool admin);

git: 8a082ca89fc0 - main - nvmf: Factor out most of nvmf_rescan_ns into a helper routine

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=8a082ca89fc007850b302f4eead2f9b6eb2ccbe0

commit 8a082ca89fc007850b302f4eead2f9b6eb2ccbe0
Author: John Baldwin 
AuthorDate: 2024-06-05 19:52:24 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:52:24 +

nvmf: Factor out most of nvmf_rescan_ns into a helper routine

This function accepts a namespace ID and associated namespace data
from IDENTIFY and takes care of updating nvmeXnY and ndaZ.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45459
---
 sys/dev/nvmf/host/nvmf.c | 52 
 1 file changed, 30 insertions(+), 22 deletions(-)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index df07d70b6c86..086df5f637c9 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -733,12 +733,40 @@ nvmf_detach(device_t dev)
return (0);
 }
 
+static void
+nvmf_rescan_ns_1(struct nvmf_softc *sc, uint32_t nsid,
+const struct nvme_namespace_data *data)
+{
+   struct nvmf_namespace *ns;
+
+   /* XXX: Needs locking around sc->ns[]. */
+   ns = sc->ns[nsid - 1];
+   if (data->nsze == 0) {
+   /* XXX: Needs locking */
+   if (ns != NULL) {
+   nvmf_destroy_ns(ns);
+   sc->ns[nsid - 1] = NULL;
+   }
+   } else {
+   /* XXX: Needs locking */
+   if (ns == NULL) {
+   sc->ns[nsid - 1] = nvmf_init_ns(sc, nsid, data);
+   } else {
+   if (!nvmf_update_ns(ns, data)) {
+   nvmf_destroy_ns(ns);
+   sc->ns[nsid - 1] = NULL;
+   }
+   }
+   }
+
+   nvmf_sim_rescan_ns(sc, nsid);
+}
+
 void
 nvmf_rescan_ns(struct nvmf_softc *sc, uint32_t nsid)
 {
struct nvmf_completion_status status;
struct nvme_namespace_data *data;
-   struct nvmf_namespace *ns;
 
data = malloc(sizeof(*data), M_NVMF, M_WAITOK);
 
@@ -771,29 +799,9 @@ nvmf_rescan_ns(struct nvmf_softc *sc, uint32_t nsid)
 
nvme_namespace_data_swapbytes(data);
 
-   /* XXX: Needs locking around sc->ns[]. */
-   ns = sc->ns[nsid - 1];
-   if (data->nsze == 0) {
-   /* XXX: Needs locking */
-   if (ns != NULL) {
-   nvmf_destroy_ns(ns);
-   sc->ns[nsid - 1] = NULL;
-   }
-   } else {
-   /* XXX: Needs locking */
-   if (ns == NULL) {
-   sc->ns[nsid - 1] = nvmf_init_ns(sc, nsid, data);
-   } else {
-   if (!nvmf_update_ns(ns, data)) {
-   nvmf_destroy_ns(ns);
-   sc->ns[nsid - 1] = NULL;
-   }
-   }
-   }
+   nvmf_rescan_ns_1(sc, nsid, data);
 
free(data, M_NVMF);
-
-   nvmf_sim_rescan_ns(sc, nsid);
 }
 
 int

git: 8a082ca89fc0 - main - nvmf: Factor out most of nvmf_rescan_ns into a helper routine

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=8a082ca89fc007850b302f4eead2f9b6eb2ccbe0

commit 8a082ca89fc007850b302f4eead2f9b6eb2ccbe0
Author: John Baldwin 
AuthorDate: 2024-06-05 19:52:24 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:52:24 +

nvmf: Factor out most of nvmf_rescan_ns into a helper routine

This function accepts a namespace ID and associated namespace data
from IDENTIFY and takes care of updating nvmeXnY and ndaZ.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45459
---
 sys/dev/nvmf/host/nvmf.c | 52 
 1 file changed, 30 insertions(+), 22 deletions(-)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index df07d70b6c86..086df5f637c9 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -733,12 +733,40 @@ nvmf_detach(device_t dev)
return (0);
 }
 
+static void
+nvmf_rescan_ns_1(struct nvmf_softc *sc, uint32_t nsid,
+const struct nvme_namespace_data *data)
+{
+   struct nvmf_namespace *ns;
+
+   /* XXX: Needs locking around sc->ns[]. */
+   ns = sc->ns[nsid - 1];
+   if (data->nsze == 0) {
+   /* XXX: Needs locking */
+   if (ns != NULL) {
+   nvmf_destroy_ns(ns);
+   sc->ns[nsid - 1] = NULL;
+   }
+   } else {
+   /* XXX: Needs locking */
+   if (ns == NULL) {
+   sc->ns[nsid - 1] = nvmf_init_ns(sc, nsid, data);
+   } else {
+   if (!nvmf_update_ns(ns, data)) {
+   nvmf_destroy_ns(ns);
+   sc->ns[nsid - 1] = NULL;
+   }
+   }
+   }
+
+   nvmf_sim_rescan_ns(sc, nsid);
+}
+
 void
 nvmf_rescan_ns(struct nvmf_softc *sc, uint32_t nsid)
 {
struct nvmf_completion_status status;
struct nvme_namespace_data *data;
-   struct nvmf_namespace *ns;
 
data = malloc(sizeof(*data), M_NVMF, M_WAITOK);
 
@@ -771,29 +799,9 @@ nvmf_rescan_ns(struct nvmf_softc *sc, uint32_t nsid)
 
nvme_namespace_data_swapbytes(data);
 
-   /* XXX: Needs locking around sc->ns[]. */
-   ns = sc->ns[nsid - 1];
-   if (data->nsze == 0) {
-   /* XXX: Needs locking */
-   if (ns != NULL) {
-   nvmf_destroy_ns(ns);
-   sc->ns[nsid - 1] = NULL;
-   }
-   } else {
-   /* XXX: Needs locking */
-   if (ns == NULL) {
-   sc->ns[nsid - 1] = nvmf_init_ns(sc, nsid, data);
-   } else {
-   if (!nvmf_update_ns(ns, data)) {
-   nvmf_destroy_ns(ns);
-   sc->ns[nsid - 1] = NULL;
-   }
-   }
-   }
+   nvmf_rescan_ns_1(sc, nsid, data);
 
free(data, M_NVMF);
-
-   nvmf_sim_rescan_ns(sc, nsid);
 }
 
 int

git: 02ddb305cc6d - main - nvmf: Refactor nvmf_add_namespaces to be more generic

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=02ddb305cc6d7fc3964e33985ae89501b99bb05b

commit 02ddb305cc6d7fc3964e33985ae89501b99bb05b
Author: John Baldwin 
AuthorDate: 2024-06-05 19:51:56 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:51:56 +

nvmf: Refactor nvmf_add_namespaces to be more generic

Rename to nvmf_scan_active_namespaces and accept an additional
callback function and callback argument.  The callback is invoked on
each active namespace enumerated by the active namespace list from the
IDENTIFY command.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45458
---
 sys/dev/nvmf/host/nvmf.c | 74 ++--
 1 file changed, 47 insertions(+), 27 deletions(-)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index e43d438aaa8c..df07d70b6c86 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -295,9 +295,13 @@ nvmf_establish_connection(struct nvmf_softc *sc, struct 
nvmf_ivars *ivars)
return (0);
 }
 
+typedef bool nvmf_scan_active_ns_cb(struct nvmf_softc *, uint32_t,
+const struct nvme_namespace_data *, void *);
+
 static bool
-nvmf_scan_nslist(struct nvmf_softc *sc, struct nvme_ns_list *nslist,
-struct nvme_namespace_data *data, uint32_t *nsidp)
+nvmf_scan_active_nslist(struct nvmf_softc *sc, struct nvme_ns_list *nslist,
+struct nvme_namespace_data *data, uint32_t *nsidp,
+nvmf_scan_active_ns_cb *cb, void *cb_arg)
 {
struct nvmf_completion_status status;
uint32_t nsid;
@@ -333,13 +337,6 @@ nvmf_scan_nslist(struct nvmf_softc *sc, struct 
nvme_ns_list *nslist,
return (true);
}
 
-   if (sc->ns[nsid - 1] != NULL) {
-   device_printf(sc->dev,
-   "duplicate namespace %u in active namespace list\n",
-   nsid);
-   return (false);
-   }
-
nvmf_status_init();
nvmf_status_wait_io();
if (!nvmf_cmd_identify_namespace(sc, nsid, data, nvmf_complete,
@@ -365,21 +362,9 @@ nvmf_scan_nslist(struct nvmf_softc *sc, struct 
nvme_ns_list *nslist,
return (false);
}
 
-   /*
-* As in nvme_ns_construct, a size of zero indicates an
-* invalid namespace.
-*/
nvme_namespace_data_swapbytes(data);
-   if (data->nsze == 0) {
-   device_printf(sc->dev,
-   "ignoring active namespace %u with zero size\n",
-   nsid);
-   continue;
-   }
-
-   sc->ns[nsid - 1] = nvmf_init_ns(sc, nsid, data);
-
-   nvmf_sim_rescan_ns(sc, nsid);
+   if (!cb(sc, nsid, data, cb_arg))
+   return (false);
}
 
MPASS(nsid == nslist->ns[nitems(nslist->ns) - 1] && nsid != 0);
@@ -392,22 +377,22 @@ nvmf_scan_nslist(struct nvmf_softc *sc, struct 
nvme_ns_list *nslist,
 }
 
 static bool
-nvmf_add_namespaces(struct nvmf_softc *sc)
+nvmf_scan_active_namespaces(struct nvmf_softc *sc, nvmf_scan_active_ns_cb *cb,
+void *cb_arg)
 {
struct nvme_namespace_data *data;
struct nvme_ns_list *nslist;
uint32_t nsid;
bool retval;
 
-   sc->ns = mallocarray(sc->cdata->nn, sizeof(*sc->ns), M_NVMF,
-   M_WAITOK | M_ZERO);
nslist = malloc(sizeof(*nslist), M_NVMF, M_WAITOK);
data = malloc(sizeof(*data), M_NVMF, M_WAITOK);
 
nsid = 0;
retval = true;
for (;;) {
-   if (!nvmf_scan_nslist(sc, nslist, data, )) {
+   if (!nvmf_scan_active_nslist(sc, nslist, data, , cb,
+   cb_arg)) {
retval = false;
break;
}
@@ -420,6 +405,41 @@ nvmf_add_namespaces(struct nvmf_softc *sc)
return (retval);
 }
 
+static bool
+nvmf_add_ns(struct nvmf_softc *sc, uint32_t nsid,
+const struct nvme_namespace_data *data, void *arg __unused)
+{
+   if (sc->ns[nsid - 1] != NULL) {
+   device_printf(sc->dev,
+   "duplicate namespace %u in active namespace list\n",
+   nsid);
+   return (false);
+   }
+
+   /*
+* As in nvme_ns_construct, a size of zero indicates an
+* invalid namespace.
+*/
+   if (data->nsze == 0) {
+   device_printf(sc->dev,
+   "ignoring active namespace %u with zero size\n", nsid);
+   return (true);
+   }
+
+   sc->ns[nsid - 1] = nvmf_init_ns(sc, nsid, data);
+
+   nvmf_sim_rescan_n

git: bed59baba2ca - main - nvmf: Pass const pointers to namespace data to nvmf_*_ns

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=bed59baba2caaf0bbbee3fed378e469b915e8a15

commit bed59baba2caaf0bbbee3fed378e469b915e8a15
Author: John Baldwin 
AuthorDate: 2024-06-05 19:51:37 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:51:37 +

nvmf: Pass const pointers to namespace data to nvmf_*_ns

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45457
---
 sys/dev/nvmf/host/nvmf_ns.c  | 5 +++--
 sys/dev/nvmf/host/nvmf_var.h | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/sys/dev/nvmf/host/nvmf_ns.c b/sys/dev/nvmf/host/nvmf_ns.c
index 30acbe815dbe..0727ca960a57 100644
--- a/sys/dev/nvmf/host/nvmf_ns.c
+++ b/sys/dev/nvmf/host/nvmf_ns.c
@@ -313,7 +313,7 @@ static struct cdevsw nvmf_ns_cdevsw = {
 
 struct nvmf_namespace *
 nvmf_init_ns(struct nvmf_softc *sc, uint32_t id,
-struct nvme_namespace_data *data)
+const struct nvme_namespace_data *data)
 {
struct make_dev_args mda;
struct nvmf_namespace *ns;
@@ -454,7 +454,8 @@ nvmf_destroy_ns(struct nvmf_namespace *ns)
 }
 
 bool
-nvmf_update_ns(struct nvmf_namespace *ns, struct nvme_namespace_data *data)
+nvmf_update_ns(struct nvmf_namespace *ns,
+const struct nvme_namespace_data *data)
 {
uint8_t lbads, lbaf;
 
diff --git a/sys/dev/nvmf/host/nvmf_var.h b/sys/dev/nvmf/host/nvmf_var.h
index 64525851631e..e0f6d33d2a73 100644
--- a/sys/dev/nvmf/host/nvmf_var.h
+++ b/sys/dev/nvmf/host/nvmf_var.h
@@ -180,12 +180,12 @@ void  nvmf_ctl_unload(void);
 
 /* nvmf_ns.c */
 struct nvmf_namespace *nvmf_init_ns(struct nvmf_softc *sc, uint32_t id,
-struct nvme_namespace_data *data);
+const struct nvme_namespace_data *data);
 void   nvmf_disconnect_ns(struct nvmf_namespace *ns);
 void   nvmf_reconnect_ns(struct nvmf_namespace *ns);
 void   nvmf_destroy_ns(struct nvmf_namespace *ns);
 bool   nvmf_update_ns(struct nvmf_namespace *ns,
-struct nvme_namespace_data *data);
+const struct nvme_namespace_data *data);
 
 /* nvmf_qpair.c */
 struct nvmf_host_qpair *nvmf_init_qp(struct nvmf_softc *sc,

git: 02ddb305cc6d - main - nvmf: Refactor nvmf_add_namespaces to be more generic

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=02ddb305cc6d7fc3964e33985ae89501b99bb05b

commit 02ddb305cc6d7fc3964e33985ae89501b99bb05b
Author: John Baldwin 
AuthorDate: 2024-06-05 19:51:56 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:51:56 +

nvmf: Refactor nvmf_add_namespaces to be more generic

Rename to nvmf_scan_active_namespaces and accept an additional
callback function and callback argument.  The callback is invoked on
each active namespace enumerated by the active namespace list from the
IDENTIFY command.

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45458
---
 sys/dev/nvmf/host/nvmf.c | 74 ++--
 1 file changed, 47 insertions(+), 27 deletions(-)

diff --git a/sys/dev/nvmf/host/nvmf.c b/sys/dev/nvmf/host/nvmf.c
index e43d438aaa8c..df07d70b6c86 100644
--- a/sys/dev/nvmf/host/nvmf.c
+++ b/sys/dev/nvmf/host/nvmf.c
@@ -295,9 +295,13 @@ nvmf_establish_connection(struct nvmf_softc *sc, struct 
nvmf_ivars *ivars)
return (0);
 }
 
+typedef bool nvmf_scan_active_ns_cb(struct nvmf_softc *, uint32_t,
+const struct nvme_namespace_data *, void *);
+
 static bool
-nvmf_scan_nslist(struct nvmf_softc *sc, struct nvme_ns_list *nslist,
-struct nvme_namespace_data *data, uint32_t *nsidp)
+nvmf_scan_active_nslist(struct nvmf_softc *sc, struct nvme_ns_list *nslist,
+struct nvme_namespace_data *data, uint32_t *nsidp,
+nvmf_scan_active_ns_cb *cb, void *cb_arg)
 {
struct nvmf_completion_status status;
uint32_t nsid;
@@ -333,13 +337,6 @@ nvmf_scan_nslist(struct nvmf_softc *sc, struct 
nvme_ns_list *nslist,
return (true);
}
 
-   if (sc->ns[nsid - 1] != NULL) {
-   device_printf(sc->dev,
-   "duplicate namespace %u in active namespace list\n",
-   nsid);
-   return (false);
-   }
-
nvmf_status_init();
nvmf_status_wait_io();
if (!nvmf_cmd_identify_namespace(sc, nsid, data, nvmf_complete,
@@ -365,21 +362,9 @@ nvmf_scan_nslist(struct nvmf_softc *sc, struct 
nvme_ns_list *nslist,
return (false);
}
 
-   /*
-* As in nvme_ns_construct, a size of zero indicates an
-* invalid namespace.
-*/
nvme_namespace_data_swapbytes(data);
-   if (data->nsze == 0) {
-   device_printf(sc->dev,
-   "ignoring active namespace %u with zero size\n",
-   nsid);
-   continue;
-   }
-
-   sc->ns[nsid - 1] = nvmf_init_ns(sc, nsid, data);
-
-   nvmf_sim_rescan_ns(sc, nsid);
+   if (!cb(sc, nsid, data, cb_arg))
+   return (false);
}
 
MPASS(nsid == nslist->ns[nitems(nslist->ns) - 1] && nsid != 0);
@@ -392,22 +377,22 @@ nvmf_scan_nslist(struct nvmf_softc *sc, struct 
nvme_ns_list *nslist,
 }
 
 static bool
-nvmf_add_namespaces(struct nvmf_softc *sc)
+nvmf_scan_active_namespaces(struct nvmf_softc *sc, nvmf_scan_active_ns_cb *cb,
+void *cb_arg)
 {
struct nvme_namespace_data *data;
struct nvme_ns_list *nslist;
uint32_t nsid;
bool retval;
 
-   sc->ns = mallocarray(sc->cdata->nn, sizeof(*sc->ns), M_NVMF,
-   M_WAITOK | M_ZERO);
nslist = malloc(sizeof(*nslist), M_NVMF, M_WAITOK);
data = malloc(sizeof(*data), M_NVMF, M_WAITOK);
 
nsid = 0;
retval = true;
for (;;) {
-   if (!nvmf_scan_nslist(sc, nslist, data, )) {
+   if (!nvmf_scan_active_nslist(sc, nslist, data, , cb,
+   cb_arg)) {
retval = false;
break;
}
@@ -420,6 +405,41 @@ nvmf_add_namespaces(struct nvmf_softc *sc)
return (retval);
 }
 
+static bool
+nvmf_add_ns(struct nvmf_softc *sc, uint32_t nsid,
+const struct nvme_namespace_data *data, void *arg __unused)
+{
+   if (sc->ns[nsid - 1] != NULL) {
+   device_printf(sc->dev,
+   "duplicate namespace %u in active namespace list\n",
+   nsid);
+   return (false);
+   }
+
+   /*
+* As in nvme_ns_construct, a size of zero indicates an
+* invalid namespace.
+*/
+   if (data->nsze == 0) {
+   device_printf(sc->dev,
+   "ignoring active namespace %u with zero size\n", nsid);
+   return (true);
+   }
+
+   sc->ns[nsid - 1] = nvmf_init_ns(sc, nsid, data);
+
+   nvmf_sim_rescan_n

git: bed59baba2ca - main - nvmf: Pass const pointers to namespace data to nvmf_*_ns

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=bed59baba2caaf0bbbee3fed378e469b915e8a15

commit bed59baba2caaf0bbbee3fed378e469b915e8a15
Author: John Baldwin 
AuthorDate: 2024-06-05 19:51:37 +
Commit: John Baldwin 
CommitDate: 2024-06-05 19:51:37 +

nvmf: Pass const pointers to namespace data to nvmf_*_ns

Reviewed by:imp
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D45457
---
 sys/dev/nvmf/host/nvmf_ns.c  | 5 +++--
 sys/dev/nvmf/host/nvmf_var.h | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/sys/dev/nvmf/host/nvmf_ns.c b/sys/dev/nvmf/host/nvmf_ns.c
index 30acbe815dbe..0727ca960a57 100644
--- a/sys/dev/nvmf/host/nvmf_ns.c
+++ b/sys/dev/nvmf/host/nvmf_ns.c
@@ -313,7 +313,7 @@ static struct cdevsw nvmf_ns_cdevsw = {
 
 struct nvmf_namespace *
 nvmf_init_ns(struct nvmf_softc *sc, uint32_t id,
-struct nvme_namespace_data *data)
+const struct nvme_namespace_data *data)
 {
struct make_dev_args mda;
struct nvmf_namespace *ns;
@@ -454,7 +454,8 @@ nvmf_destroy_ns(struct nvmf_namespace *ns)
 }
 
 bool
-nvmf_update_ns(struct nvmf_namespace *ns, struct nvme_namespace_data *data)
+nvmf_update_ns(struct nvmf_namespace *ns,
+const struct nvme_namespace_data *data)
 {
uint8_t lbads, lbaf;
 
diff --git a/sys/dev/nvmf/host/nvmf_var.h b/sys/dev/nvmf/host/nvmf_var.h
index 64525851631e..e0f6d33d2a73 100644
--- a/sys/dev/nvmf/host/nvmf_var.h
+++ b/sys/dev/nvmf/host/nvmf_var.h
@@ -180,12 +180,12 @@ void  nvmf_ctl_unload(void);
 
 /* nvmf_ns.c */
 struct nvmf_namespace *nvmf_init_ns(struct nvmf_softc *sc, uint32_t id,
-struct nvme_namespace_data *data);
+const struct nvme_namespace_data *data);
 void   nvmf_disconnect_ns(struct nvmf_namespace *ns);
 void   nvmf_reconnect_ns(struct nvmf_namespace *ns);
 void   nvmf_destroy_ns(struct nvmf_namespace *ns);
 bool   nvmf_update_ns(struct nvmf_namespace *ns,
-struct nvme_namespace_data *data);
+const struct nvme_namespace_data *data);
 
 /* nvmf_qpair.c */
 struct nvmf_host_qpair *nvmf_init_qp(struct nvmf_softc *sc,

[docker-dev] Re: WHERE TO BUY MAGIC MUSHROOM GUMMIES ONLINE

2024-06-05 Thread JOHN BRYIAN

 Psilocybin Gummies - Mushroom Gummy Cubes 3.5g online | Buy Psilocybin 
Gummies 100% Fast And Discreet Shipping
westparkpsychedlics.com
https//:westparkpsychedlics.com
Worldwide
Buy Magic Mushrooms Online | Psychedelics For Sale USA | Mushroom Chocolate 
Bars Online https//:westparkpsychedlics.com
https//:westparkpsychedlics.com
Buy Xanax 2mg bars, Hydrocodone, Diazepam, Dilaudid, Oxycotin, Roxycodone, 
Suboxone, Subutex, Klonpin, Soma, Ritalin
Buy microdosing psychedelics online | Buy magic mushrooms gummies online | 
buy dmt carts online usa
DMT for Sale | Order DMT Cartridges Online | Buy DMT Online | WHere to Buy 
DMT in Australia
https//:westparkpsychedlics.com
https//:westparkpsychedlics.com
NN DMT for Sale | Order DMT Cartridges Online | Buy DMT Online Europe | 
WHere to Buy DMT Near Me |Buy DMT USA
https//:westparkpsychedlics.com
https//:westparkpsychedlics.com


Your best online shop to get plantimum quality microdosing psychedelics 
products online, pain,anxiety pills, and research
https//:westparkpsychedlics.com
chemicals.
Be 100% assured about the quality and genuineness of the product.
https//:westparkpsychedlics.com
Buy DMT .5ml Purecybin 


On Wednesday, June 5, 2024 at 12:10:41 PM UTC-7 jamb...@gmail.com wrote:

> Psilocybin Gummies - Mushroom Gummy Cubes 3.5g online | Buy Psilocybin 
> Gummies 100% Fast And Discreet Shipping
> westparkpsychedlics.com
> https//:westparkpsychedlics.com
> Worldwide
> Buy Magic Mushrooms Online | Psychedelics For Sale USA | Mushroom 
> Chocolate Bars Online https//:westparkpsychedlics.com
> https//:westparkpsychedlics.com
> Buy Xanax 2mg bars, Hydrocodone, Diazepam, Dilaudid, Oxycotin, Roxycodone, 
> Suboxone, Subutex, Klonpin, Soma, Ritalin
> Buy microdosing psychedelics online | Buy magic mushrooms gummies online | 
> buy dmt carts online usa
> DMT for Sale | Order DMT Cartridges Online | Buy DMT Online | WHere to Buy 
> DMT in Australia
> https//:westparkpsychedlics.com
> https//:westparkpsychedlics.com
> NN DMT for Sale | Order DMT Cartridges Online | Buy DMT Online Europe | 
> WHere to Buy DMT Near Me |Buy DMT USA
> https//:westparkpsychedlics.com
> https//:westparkpsychedlics.com
>
>
> Your best online shop to get plantimum quality microdosing psychedelics 
> products online, pain,anxiety pills, and research
> https//:westparkpsychedlics.com
> chemicals.
> Be 100% assured about the quality and genuineness of the product.
> https//:westparkpsychedlics.com
> Buy DMT .5ml Purecybin 
>
> On Monday, June 3, 2024 at 10:10:31 AM UTC-7 baylorwi...@gmail.com wrote:
>
>>  Your best online shop to get platinum quality microdosing psychedelics 
>> products online, pain,anxiety pills, and research chemicals.
>> Be 100% assured about the quality and genuineness of the product, and you 
>> will also be able to buy quality psychedelics products at a fair price.
>>
>> Dmt For Sale Your best online shop to get platinum quality microdosing 
>> psychedelics products online, pain,anxiety pills, and research chemicals.
>> Be 100% assured about the quality and genuineness of the product, and you 
>> will also be able to buy quality psychedelics products at a fair price.
>> : https://www.t :  
>> 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/
>> : 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/
>> .me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/ 
>> 
>>
>> Dmt For Sale
>> Xannax For Sale 
>> Disposables For Sale
>> Shatter For Sale 
>> Wax For Sale
>> Mushroom For Sale 
>> Chocolate bars For Sale 
>> Edibles For Sale : 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/
>>
>> Vape pens For Sale : 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/
>> : 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/
>>
>> Adderall For Sale 
>> M30 For Sale 
>> Coke For Sale 
>> Gummies For Sale 
>> Hash For Sale 
>> Pre-Rolls For Sale 
>> Exotic Buds For Sale 
>>
>> Shop Now  : 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/
>> : 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/
>> : 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-online/
>> : 
>> https://www.t.me/Ricko_swavy8/product/buy-dmt-1ml-purecybin-700mg-dmt-onlin
>>
>> On Friday, May 31, 2024 at 2:46:20 PM UTC-7 dwnm...@gmail.com wrote:
>>
>>>
>>> Great Taste – A chocolate bar that makes you trip your face off. How 
>>> could that not be the dream?
>>> Clean High – We formulated this chocolate bar to produce a clean high 
>>> that won’t leave you crashing after the initial peak. shroom chocolate
>>> True Psychedelic Experience -Just cause it doesn’t taste like mushrooms 
>>> doesn’t mean it’s not mushrooms. You

Re: [RBW] Re: Riv Rider Recipes

2024-06-05 Thread John Rinker

Here's a quick, easy and delicious camp dish that I call 'Cowboy Chili'. It 
works best if you pass through a town late in the day and are not riding 
much further as there's canned goods.

1 can of black beans
1 can of sweet corn kernels
1 can of chopped tomatoes (fire-roasted from Trader Joes!)
1 large onion
Chopped garlic to taste (lots!)
Black pepper to taste
Salt to taste
Cumin to taste (lots!)

Dice onions and fry in oil until carmelized. Add fresh garlic, salt and 
pepper.
Add beans, corn and tomatoes. Stir in cumin.
Stew for 5-10 min.

Serve with avocado, tortillas, chips, or whatever keeps your canoe straight.

Serves 2, or leftovers for breakfast



Cheers, John



On Wednesday, June 5, 2024 at 12:17:01 PM UTC-7 Patrick Moore wrote:

> 1. Indian dal on the cheap and easy. Boil red or orange or yellow (brown 
> rather earthy for my taste) in 3X water until soft.
>
> Cook about 1.5X long grain rice with a bit of cardamom seed.
>
> In small skillet or saucepan heat as much oil as you like to "wet" the 
> lentil and rice mixture, and  with some and or all of: garlic, coriander, 
> cumin, red pepper, bay leaf, ginger, asafoetida, ... sizzle for 30 seconds 
> or so and pour over lentils and rice. Salt to taste.
>
> Augment with full fat yogurt, Indian mango pickle, British sweet chutney. 
> Or, augment with raita in place of plain fat yogurt: 1 lg cucumber peeled 
> and grated, 2 c full fat yogurt, big handfull of chopped fresh mint, tsp 
> ground cumin: mix all and enjoy.
>
> I often add the oil and spices to the cooking lentils with chopped onion 
> sautted and diced spinach (I use frozen because I don't like to clean and 
> prep vegetables; and the nutrition is at least as good) for a sort of 
> lentil stew. 
>
> 2. New Mexico pinto beans.
>
> 2 c dried pinto beans -- soak over night and cook in pressure cooker for 
> ~1 hour including cooldown or for 24 hours at least in crockpot on low.
>
> 1 large chopped onion sauteed with garlic, cumin, oregano, red pepper, add 
> beans and can of chopped or crushed tomatoes and chopped spinach or Kale.
>
> Salt to taste.
>
> Eat with flour tortillas or rice or add potatoes: dice and nuke ~2 med 
> potatoes until done, add to above.
>
> 3. Cheese spaghetti: An adult's mac + cheese. Cook 8 oz dry spaghetti, 
> save water, met combo of butter and olive oil in skillet, sautee garlic (I 
> get quart chopped garlic at Costco), add cooked spaghetti and ~1 c pasta 
> water, bring to boil, add 1/2 c parmesan or romano and 1/2 
> non-parmesan/romano -- I use Costco 5 lb shredded Mexican mix but anything 
> will do. Add salt and black pepper to taste. 
>
> Recipe also calls for 2 tbsp cream cheese and 2/3 c heavy cream but that's 
> disgusting; add a bit more cheese instead.
>
>
> 4. Grilled salmon: farmed or fresh fillets. Dribble with plenty of lemon 
> juice and layer with fresh dill, salt, pepper; wrap in tinfoil; grill.
>
> Then there are tatie scones and champ and the garlic spaghetti (sautee 
> lots of garlic in olive oil, spread over cooked spaghetti, add salt, red 
> pepper, black pepper to taste; better have some veg on the side) that my 
> daughter used to love on Wed and Fri fast day evenings -- but you can dress 
> it up with Parmesan or Romano for other days, home-made baked fries 
> (daughter got scrambled eggs and home made *deep fried* fries for school 
> day breakfasts), home made mac and cheese (damn Annie's!), lazy man's 
> pseudo Thai curry on rice, Julia Child's very easy french bread (tho' v 
> long waits for rising), etc etc etc.
>
> Patrick Moore, who will probably make pseudo baked fries*  and eat with 
> green peas (frozen, nuked, olive oil and salt and pepper) this evening -- 
> Wed, fast day, in ABQ, NM.
>
> *Almost as good as deep fried, a lot cleaner, and a hellofalot better than 
> frozen fries. Slice potatoes into fingers and roll around in olive oil. 
> Rinse well and pat dry. Nuke until tender. Line baking sheet with tinfoil. 
> Liberally add more olive oil. Grill pretty high and close, watch so don't 
> burn, turn when top brown. I've used red, white, and Idaho potatoes; all 
> good.
>
> Patrick "and cook oat groats in a crockpot" Moore (who twice held the 
> office of Chief Cook 40 years ago while living with bunch of guys, and in 
> one case was voted out of office, but who learned that if you take a whole 
> frozen but gutted and cleaned chicken, rip off the cling wrapt and foam 
> packaging, place in cold oven, turn to 350*, and leave for 3 hours, you end 
> up with moist, tender, and very bland meat).
>
>
>
> On Wed, Jun 5, 2024 at 10:17 AM Coco Menk  wrote:
>
>> bumping this thread to see if there are any new contributors this Spring 
>> :) 
>>
>&

[Bug 2068024] Re: race_sched in ubuntu_stress_smoke_test will cause kernel panic on 6.8 with Azure Standard_A2_v2 instance

2024-06-05 Thread John Cabaj

noble:linux-azure 6.6.0-1001 works, so this was introduced somewhere in
6.8. Bisecting futher...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068024

Title:
  race_sched in ubuntu_stress_smoke_test will cause kernel panic on 6.8
  with Azure Standard_A2_v2 instance

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2068024/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-06-05 Thread John McCall via cfe-commits



@@ -118,6 +124,37 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, 
bool ForBitField) {
   return R;
 }
 
+bool CodeGenTypes::LLVMTypeLayoutMatchesAST(QualType ASTTy,
+llvm::Type *LLVMTy) {
+  CharUnits ASTSize = Context.getTypeSizeInChars(ASTTy);
+  CharUnits LLVMSize =
+  CharUnits::fromQuantity(getDataLayout().getTypeAllocSize(LLVMTy));
+  return ASTSize == LLVMSize;
+}
+
+llvm::Type *CodeGenTypes::convertTypeForLoadStore(QualType T,
+  llvm::Type *LLVMTy) {
+  if (!LLVMTy)
+LLVMTy = ConvertType(T);
+
+  if (!T->isBitIntType() && LLVMTy->isIntegerTy(1))
+return llvm::IntegerType::get(getLLVMContext(),
+  (unsigned)Context.getTypeSize(T));
+
+  if (T->isBitIntType()) {
+llvm::Type *R = ConvertType(T);
+if (!LLVMTypeLayoutMatchesAST(T, R))
+  return llvm::Type::getIntNTy(
+  getLLVMContext(), Context.getTypeSizeInChars(T).getQuantity() * 8);

rjmccall wrote:

We could literally use `[N x i8]` as the allocation type of every single type 
and save ourselves a lot of grief.  It's nicer to generate more semantic types 
when we can, though; it produces IR that's easier to both read and test.

https://github.com/llvm/llvm-project/pull/91364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[ofiwg] Clarification of definition of FI_THREAD_DOMAIN

2024-06-05 Thread Byrne, John (Labs)

FI_THREAD_DOMAIN
A domain serialization model requires applications to serialize access to all 
objects belonging to a domain.

My immediate take on this definition is that if I am multi-threading I have to 
have a single lock that I use to access any object belonging to a fi_domain 
instance; which seems like a terrible idea for multi-threading. However, in 
Jianxin's 2.0 API update at the workshop 
https://www.openfabrics.org/wp-content/uploads/2024-workshop/2024-workshop-presentations/session-1.pdf,
 it says: "Recommend FI_THREAD_DOMAIN for multi-thread app with regular 
endpoint."  If my interpretation of the meaning of FI_THREAD_DOMAIN is correct, 
then the only way this makes sense to me is for the expectation to be that a 
unique fi_domain instance and endpoint be created for each thread. Is this 
correct or is there something I'm misunderstanding? If it is correct, then 
there are some painful implications for multi-threading RMA.

Thanks,

John Byrne

___
ofiwg mailing list
ofiwg@lists.openfabrics.org
https://lists.openfabrics.org/mailman/listinfo/ofiwg

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

>On the other hand, I was at a recent conference, and asked an NSA 
>representative (William Layton, >Cryptographic Solutions Technical Director) 
>about “hybrid crypto”, and he responded that the NSA >was “ambivalent” (his 
>word); that they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted 
>>on hybrid crypto, they’d go along.

That is my understanding as well, but they seem to take a hard stand on 
non-FIPS-validated algorithms. My understanding is that a non-FIPS-validated 
standalone ML-KEM-1024 would not be CNSA 1.0 and not CNSA 2.0 compliant. A 
FIPS-validated P-384 + non-FIPS-validated ML-KEM-1024 would to my understanding 
be CNSA 1.0 compliant. My feeling is that a FIPS-validated P-384 + 
non-FIPS-validated ML-KEM-1024 would be preferred over continuing with 
standalone P-384 for several years, but I think only NSA can answer this.

Cheers,
John

From: Scott Fluhrer (sfluhrer) 
Date: Wednesday, 5 June 2024 at 18:50
To: John Mattsson , Watson Ladd 
, Andrei Popov 
Cc: Blumenthal, Uri - 0553 - MITLL , tls@ietf.org 

Subject: RE: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On the other hand, I was at a recent conference, and asked an NSA 
representative (William Layton, Cryptographic Solutions Technical Director) 
about “hybrid crypto”, and he responded that the NSA was “ambivalent” (his 
word); that they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted 
on hybrid crypto, they’d go along.

Hence, I don’t believe that CNSA 2.0 is taking quite as hard of a stand as the 
summary states…

From: John Mattsson 
Sent: Wednesday, June 5, 2024 11:52 AM
To: Watson Ladd ; Andrei Popov 

Cc: Blumenthal, Uri - 0553 - MITLL ; Scott Fluhrer (sfluhrer) 
; tls@ietf.org
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

>I really do not understand this argument, given that the DoD has explicitly 
>said they aren't doing that.

I think it is a bit unclear what CNSA 2.0 says:
- They say that CNSA 2.0 compliant browsers need to support ML-KEM-1024 by 2025.
- The also say that “NSA does not approve using pre-standardized or 
non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes)”.

I don’t see how you can combine fulfill both of these if estimates for when 
FIPS compliant implementations will be ready. My five cents would be that 
P-384+ML-KEM-1024 is CNSA 1.0 compliant until ML-KEM gets FIPS validated and 
then it becomes CNSA 2.0 compliant.

https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
Cheers,
John

From: Watson Ladd mailto:watsonbl...@gmail.com>>
Date: Wednesday, 5 June 2024 at 17:39
To: Andrei Popov mailto:andrei.po...@microsoft.com>>
Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>, 
Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>, John 
Mattsson mailto:john.matts...@ericsson.com>>, 
tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov
mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
 wrote:
>
> This is my understanding too, and I believe a lot of deployments limited to 
> P384 will want to use a P384-based hybrid, at least “in transition”. The 
> duration of this transition could be years…

I really do not understand this argument, given that the DoD has
explicitly said they aren't doing that.

>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>
> Sent: Wednesday, June 5, 2024 7:59 AM
> To: Scott Fluhrer (sfluhrer) 
> mailto:sfluhrer=40cisco@dmarc.ietf.org>>;
>  John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>;
>  tls@ietf.org<mailto:tls@ietf.org>
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256.
>
>
>
> CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But 
> there’s a “transition period”, during which P-384 could presumably be used.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> From: Scott Fluhrer (sfluhrer) 
> mailto:sfluhrer=40cisco@dmarc.ietf.org>>
> Date: Wednesday, June 5, 2024 at 09:54
> To: John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
>  tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
> Subject: [EXT] [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
> If we’re talking about CNSA, well CNSA 2. 0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft… From: John Mattsson  dmarc. ietf. org>
>
> ZjQcmQRYFpfptBannerStart
>
> This Message Is From an E

git: 56b822a17cde - main - pci: Only add special VF handling for direct children in bus methods

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=56b822a17cde5940909633c50623d463191a7852

commit 56b822a17cde5940909633c50623d463191a7852
Author: John Baldwin 
AuthorDate: 2024-06-05 16:50:05 +
Commit: John Baldwin 
CommitDate: 2024-06-05 16:50:05 +

pci: Only add special VF handling for direct children in bus methods

For activate/deactivate resource, use a more standard check at the
start of the function since the addition of the PCI_IOV code made this
more complex.  For the three recently added methods, just add the
typical check at the beginning that I missed.

This wasn't always fatal as if your system only had PCI device_t's as
children of PCI bus devices it would happen to work ok, but if you
have a non-PCI child device (e.g. an ATA channel) then dereferencing
ivars for non-direct-children could fault.

Reported by:Cirrus-CI (via emaste)
Reviewed by:emaste
Fixes:  871b33ad65ba pci: Consistently use pci_vf_* for 
suballocated VF memory resources
Differential Revision:  https://reviews.freebsd.org/D45499
---
 sys/dev/pci/pci.c | 55 +++
 1 file changed, 35 insertions(+), 20 deletions(-)

diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
index 2093d6a8b5ef..9661cfd19db7 100644
--- a/sys/dev/pci/pci.c
+++ b/sys/dev/pci/pci.c
@@ -5695,6 +5695,9 @@ pci_activate_resource(device_t dev, device_t child, 
struct resource *r)
struct pci_devinfo *dinfo;
int error, rid, type;
 
+   if (device_get_parent(child) != dev)
+   return (bus_generic_activate_resource(dev, child, r));
+
dinfo = device_get_ivars(child);
 #ifdef PCI_IOV
if (dinfo->cfg.flags & PCICFG_VF) {
@@ -5716,20 +5719,20 @@ pci_activate_resource(device_t dev, device_t child, 
struct resource *r)
if (error)
return (error);
 
+   rid = rman_get_rid(r);
+   type = rman_get_type(r);
+
+   /* Device ROMs need their decoding explicitly enabled. */
+   if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
+   pci_write_bar(child, pci_find_bar(child, rid),
+   rman_get_start(r) | PCIM_BIOS_ENABLE);
+
/* Enable decoding in the command register when activating BARs. */
-   if (device_get_parent(child) == dev) {
-   /* Device ROMs need their decoding explicitly enabled. */
-   rid = rman_get_rid(r);
-   type = rman_get_type(r);
-   if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
-   pci_write_bar(child, pci_find_bar(child, rid),
-   rman_get_start(r) | PCIM_BIOS_ENABLE);
-   switch (type) {
-   case SYS_RES_IOPORT:
-   case SYS_RES_MEMORY:
-   error = PCI_ENABLE_IO(dev, child, type);
-   break;
-   }
+   switch (type) {
+   case SYS_RES_IOPORT:
+   case SYS_RES_MEMORY:
+   error = PCI_ENABLE_IO(dev, child, type);
+   break;
}
return (error);
 }
@@ -5740,6 +5743,9 @@ pci_deactivate_resource(device_t dev, device_t child, 
struct resource *r)
struct pci_devinfo *dinfo;
int error, rid, type;
 
+   if (device_get_parent(child) != dev)
+   return (bus_generic_deactivate_resource(dev, child, r));
+
dinfo = device_get_ivars(child);
 #ifdef PCI_IOV
if (dinfo->cfg.flags & PCICFG_VF) {
@@ -5762,13 +5768,11 @@ pci_deactivate_resource(device_t dev, device_t child, 
struct resource *r)
return (error);
 
/* Disable decoding for device ROMs. */
-   if (device_get_parent(child) == dev) {
-   rid = rman_get_rid(r);
-   type = rman_get_type(r);
-   if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
-   pci_write_bar(child, pci_find_bar(child, rid),
-   rman_get_start(r));
-   }
+   rid = rman_get_rid(r);
+   type = rman_get_type(r);
+   if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
+   pci_write_bar(child, pci_find_bar(child, rid),
+   rman_get_start(r));
return (0);
 }
 
@@ -5779,6 +5783,10 @@ pci_adjust_resource(device_t dev, device_t child, struct 
resource *r,
 {
struct pci_devinfo *dinfo;
 
+   if (device_get_parent(child) != dev)
+   return (bus_generic_adjust_resource(dev, child, r, start,
+   end));
+
dinfo = device_get_ivars(child);
if (dinfo->cfg.flags & PCICFG_VF) {
switch (rman_get_type(r)) {
@@ -5802,6 +5810,10 @@ pci_map_resource(device_t dev, device_t child, struct 
resource *r,
 {
struct pci_devinfo *dinfo;
 
+   if (device_get_parent(child) != dev)
+

git: 56b822a17cde - main - pci: Only add special VF handling for direct children in bus methods

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=56b822a17cde5940909633c50623d463191a7852

commit 56b822a17cde5940909633c50623d463191a7852
Author: John Baldwin 
AuthorDate: 2024-06-05 16:50:05 +
Commit: John Baldwin 
CommitDate: 2024-06-05 16:50:05 +

pci: Only add special VF handling for direct children in bus methods

For activate/deactivate resource, use a more standard check at the
start of the function since the addition of the PCI_IOV code made this
more complex.  For the three recently added methods, just add the
typical check at the beginning that I missed.

This wasn't always fatal as if your system only had PCI device_t's as
children of PCI bus devices it would happen to work ok, but if you
have a non-PCI child device (e.g. an ATA channel) then dereferencing
ivars for non-direct-children could fault.

Reported by:Cirrus-CI (via emaste)
Reviewed by:emaste
Fixes:  871b33ad65ba pci: Consistently use pci_vf_* for 
suballocated VF memory resources
Differential Revision:  https://reviews.freebsd.org/D45499
---
 sys/dev/pci/pci.c | 55 +++
 1 file changed, 35 insertions(+), 20 deletions(-)

diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
index 2093d6a8b5ef..9661cfd19db7 100644
--- a/sys/dev/pci/pci.c
+++ b/sys/dev/pci/pci.c
@@ -5695,6 +5695,9 @@ pci_activate_resource(device_t dev, device_t child, 
struct resource *r)
struct pci_devinfo *dinfo;
int error, rid, type;
 
+   if (device_get_parent(child) != dev)
+   return (bus_generic_activate_resource(dev, child, r));
+
dinfo = device_get_ivars(child);
 #ifdef PCI_IOV
if (dinfo->cfg.flags & PCICFG_VF) {
@@ -5716,20 +5719,20 @@ pci_activate_resource(device_t dev, device_t child, 
struct resource *r)
if (error)
return (error);
 
+   rid = rman_get_rid(r);
+   type = rman_get_type(r);
+
+   /* Device ROMs need their decoding explicitly enabled. */
+   if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
+   pci_write_bar(child, pci_find_bar(child, rid),
+   rman_get_start(r) | PCIM_BIOS_ENABLE);
+
/* Enable decoding in the command register when activating BARs. */
-   if (device_get_parent(child) == dev) {
-   /* Device ROMs need their decoding explicitly enabled. */
-   rid = rman_get_rid(r);
-   type = rman_get_type(r);
-   if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
-   pci_write_bar(child, pci_find_bar(child, rid),
-   rman_get_start(r) | PCIM_BIOS_ENABLE);
-   switch (type) {
-   case SYS_RES_IOPORT:
-   case SYS_RES_MEMORY:
-   error = PCI_ENABLE_IO(dev, child, type);
-   break;
-   }
+   switch (type) {
+   case SYS_RES_IOPORT:
+   case SYS_RES_MEMORY:
+   error = PCI_ENABLE_IO(dev, child, type);
+   break;
}
return (error);
 }
@@ -5740,6 +5743,9 @@ pci_deactivate_resource(device_t dev, device_t child, 
struct resource *r)
struct pci_devinfo *dinfo;
int error, rid, type;
 
+   if (device_get_parent(child) != dev)
+   return (bus_generic_deactivate_resource(dev, child, r));
+
dinfo = device_get_ivars(child);
 #ifdef PCI_IOV
if (dinfo->cfg.flags & PCICFG_VF) {
@@ -5762,13 +5768,11 @@ pci_deactivate_resource(device_t dev, device_t child, 
struct resource *r)
return (error);
 
/* Disable decoding for device ROMs. */
-   if (device_get_parent(child) == dev) {
-   rid = rman_get_rid(r);
-   type = rman_get_type(r);
-   if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
-   pci_write_bar(child, pci_find_bar(child, rid),
-   rman_get_start(r));
-   }
+   rid = rman_get_rid(r);
+   type = rman_get_type(r);
+   if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
+   pci_write_bar(child, pci_find_bar(child, rid),
+   rman_get_start(r));
return (0);
 }
 
@@ -5779,6 +5783,10 @@ pci_adjust_resource(device_t dev, device_t child, struct 
resource *r,
 {
struct pci_devinfo *dinfo;
 
+   if (device_get_parent(child) != dev)
+   return (bus_generic_adjust_resource(dev, child, r, start,
+   end));
+
dinfo = device_get_ivars(child);
if (dinfo->cfg.flags & PCICFG_VF) {
switch (rman_get_type(r)) {
@@ -5802,6 +5810,10 @@ pci_map_resource(device_t dev, device_t child, struct 
resource *r,
 {
struct pci_devinfo *dinfo;
 
+   if (device_get_parent(child) != dev)
+

[jira] [Commented] (MNG-8131) Property replacement in dependency pom no longer works

2024-06-05 Thread John Neffenger (Jira)



[ 
https://issues.apache.org/jira/browse/MNG-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852488#comment-17852488
 ] 

John Neffenger commented on MNG-8131:
-

Thank you, Tamás. Your fix shown in the [new logging 
output|https://gist.github.com/cstamas/288a773459ef026e1500699b7a109451] looks 
great!

> Property replacement in dependency pom no longer works
> --
>
> Key: MNG-8131
> URL: https://issues.apache.org/jira/browse/MNG-8131
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.9.7
> Environment: macOS 14.5 (23F79)
>Reporter: Taylor Smock
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> h1. The problem:{{{}{}}}
> Classifiers in dependency poms are no longer replaced (either due to 
> performing profile activation of a parent pom of the dependency, or not 
> performing replacement of a property).{{{}{}}}
> Steps to reproduce (from [https://openjfx.io/openjfx-docs/#maven] )
>  # {{m{{{}vn archetype:generate
> -DarchetypeGroupId=org.openjfx 
> -DarchetypeArtifactId=javafx-archetype-simple -DarchetypeVersion=0.0.3 
> -DgroupId=org.openjfx -DartifactId=sample -Dversion=1.0.0 
> -Djavafx-version=22.0.1{}
>  # {{{}mvn compile{{{}{}}}[INFO] Scanning for projects...{}}}{{{}[INFO] 
> {}}}{{{}[INFO] -< org.openjfx:sample 
> >-{}}}{{{}[INFO] Building sample 1.0.0{}}}{{{}[INFO]  
>  from pom.xml{}}}{{{}[INFO] [ jar 
> ]-{}}}{{{}Downloading from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.pom{}}}{{{}Downloaded
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.pom
>  (908 B at 1.9 kB/s){}}}{{{}Downloading from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom{}}}{{{}Downloaded
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom
>  (8.4 kB at 165 kB/s){}}}{{{}Downloading from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.pom{}}}{{{}Downloaded
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.pom
>  (904 B at 21 kB/s){}}}{{{}Downloading from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.pom{}}}{{{}Downloaded
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.pom
>  (749 B at 17 kB/s){}}}{{{}Downloading from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.jar{}}}{{{}Downloaded
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.jar
>  (306 B at 6.8 kB/s){}}}{{{}Downloading from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloading
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.jar{}}}{{{}Downloading
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloading
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.jar{}}}{{{}Downloading
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloaded
>  from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.jar
>  (302 B at 2.4 kB/s){}}}{{{}Downloaded from central: 
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.jar
>  (306 B at 2.4 kB/s){}}}{{{}[INFO] 
> {}}}{{{}[INFO]
>  BUILD FAILURE{}}}{{{}[INFO] 
> {}}}{{{}[INFO]
>  Total time:  1.378 s{}}}{{{}[INFO] Finished at: 
> 2024-05-28T10:23:05-06:00{}}}{{{}[INFO] 
> {}}}{{{}[ERROR]
>  Failed to execute goal on project sample: Could not resolve dependencies for 
> project org.openjfx:sample:jar:1.0.0: The following artifa

[blink-dev] Intent to Extend Experiment: Cookie Deprecation Label

2024-06-05 Thread John Delaney

We would like to extend the Cookie Deprecation Label experimental feature
being used for Chrome Facilitated Testing. This feature previously
received approval to run through the end of M125 (ending roughly June 10,
2024). The Facilitated Testing period, however, is scheduled to run
through June 30, 2024.

Therefore, we would like to extend Cookie Deprecation Labels for another
milestone through M126.

Contact emails

johni...@chromium.org, wanderv...@chromium.org, lin...@chromium.org

Explainer

https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md

https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing

Summary

To prepare for the third-party cookie deprecation, it is important to
understand the full impact of Chrome’s planned transition from third-party
cookies to the Privacy Sandbox Ads APIs.

This experiment exposes a temporary set of APIs which provide access to
browser-determined treatment and control groups to support opt-in server
side testing of the third-party cookie deprecation.

We are exploring ways to address ecosystem feedback that we should continue
supporting labels after 30 June. We expect to provide more information
soon.

Link to “Intent to Experiment” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ

Goals for experimentation

The goal of this experiment is to allow adtechs to evaluate the impact of
third party cookie phase out through opt-in server side testing. We expect
partners to run experiments downstream from the browser provided treatment
and control groups.

Experimental timeline

Previously the feature was approved until M125. We'd like to extend the
experiment by one milestone to M126 so that we can continue to support the
Chrome Facilitated Testing period until June 30, 2024. Any experimentation
after June 30 will be covered by another Intent.

Any risks when the experiment finishes?

Minimal. The feature is designed in a way that websites must feature
detect for the web API. This feature is also only available for a subset of
users.

Reason this experiment is being extended

This feature is necessary to support the ongoing Chrome Facilitated Testing
effort
.

The Facilitated Testing period is scheduled to complete on June 30, 2024
which is slightly beyond our previous approval for the feature. Therefore
we are requesting to extend the experimental feature access to M126.

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms supported by
Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

No, not supported on webview.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5189079788683264

--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc8339ee-9996-43cf-b3ec-451f01f9e64cn%40chromium.org.

[TLS]Re: Curve-popularity data?

My interpretation is the same as EKR. Chrome’s behavior seems compliant to me. 
I also think Chrome’s behavior makes sense and I think Chrome should continue 
doing that. The server’s Peter talk about do on the other hand not follow the 
implementation guidance in Appendix C.

C.3.  
Implementation Pitfalls

   Implementation experience has shown that certain parts of earlier TLS

   specifications are not easy to understand and have been a source of

   interoperability and security problems.  Many of these areas have

   been clarified in this document, but this appendix contains a short

   list of the most important things that require special attention from

   implementors.

   ...

   -  As a server, do you send a HelloRetryRequest to clients which
  support a compatible (EC)DHE group but do not predict it in the
  "key_share" extension?  As a client, do you correctly handle a
  HelloRetryRequest from the server?

From: Eric Rescorla 
Date: Wednesday, 5 June 2024 at 15:44
To: Peter Gutmann 
Cc: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?

On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>> wrote:
Nick Harper mailto:i...@nharper.org>> writes:

>I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves
>be present in the key_share extension if that extension is non-empty.

Just because it's possible to rules-lawyer your way around something doesn't
make it valid (I also see nothing in the spec saying a TLS 1.3 implementation
can't reformat your hard drive, for example, so presumably that's OK too).
The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
keyex in its client hello, making it a noncompliant TLS 1.3 implementation.

I don't believe this analysis is correct. You state:

As Nick notes, RFC 8446 explicitly permits the extension to be empty, so
it clearly cannot be the case that mere failure to provide an MTI key_share
in CH makes an implementation noncompliant, contra your statement above.

The only question at hand is whether the specification permits you to send
a non-empty key_shares field that excludes the MTI. However, the specification
*also* permits you to send a subset of supported groups:

   the same order.  However, the values MAY be a non-contiguous subset
   of the "supported_groups" extension and MAY omit the most preferred
   groups.  Such a situation could arise if the most preferred groups

I think the best reading of this text is that you are free to send *any*
subset of the supported groups, whether it includes the MTI or not.

The requirement in S 9.1 is merely that the application "support
key exchange with secp256r1", which Chrome does: it's in "supported_groups"
and (presumably) works if the server sends an HRR. Given the above
more explicit text about "key_shares", I don't think it's reasonable to
infer that MTI requires more than this.

This isn't to say anything about whether this is the best implementation choice,
which is a distinct question from what the specification requires.

-Ekr

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[Bug 2067897] Re: Ubuntu 24.04 does not install resolvconf uses systemd-resolved instead which is broken

2024-06-05 Thread John Orr

Thanks for creating the bug, and your input :)

I agree with all your comments (though can't speak for your last message, I'm 
not getting strongswan-starter for some reason and I don't know anything about 
ansible) - but
1. I'm assuming we shouldn't need to edit /etc/strongswan.d/charon/resolve.conf 
? We used not to.
2. Sometimes I'm connected over wifi, and sometimes over ethernet, and I'd like 
it to work for both, without editing the file.
3. A colleague suggested adding an extra interface, eg
sudo ip link add vpn type dummy
and putting "vpn" in as the interface name in that config file.  Perhaps 
something like that could be done via hook scripts - but I'm hoping Tobias 
might have the answer!

Thanks for confirming the same behaviour!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067897

Title:
  Ubuntu 24.04 does not install resolvconf uses systemd-resolved instead
  which is broken

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2067897/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[TLS]Re: [EXTERNAL] Curve-popularity data?

Hubert Kario wrote:
>1. P-256 with OpenSSL 3.1.1 on my machine is quite literally over 20 times 
>faster than P-384

Yes, P-384 is a bit unoptimized. That will change in newer versions. But still 
much slower than P-256 which in turn is much slower than X25519 (which is 
slightly slower than ML-KEM).
https://sthbrx.github.io/blog/2023/08/07/going-out-on-a-limb-efficient-elliptic-curve-arithmetic-in-openssl/

>2. While NIST FIPS 186-5 includes Ed25519 as an approved algorithm, it does 
>not include X25519 as an approved algorithm.

Yes, that is a shame. I don’t think NIST ever gave any reasoning behind this.

>3. we're likely years before we will get first FIPS certified ML-KEM 
>implementation

Yes

>so I expect that most regular servers will use x25519+ML-KEM, the ones
>that have a requirement for FIPS compliance will have to use P-256+ML-KEM,
>and the ones that have Common Critera requirements will have to use
>P-384+ML-KEM.

I assume servers with Common Critera requirements would likely want to use 
P-384+ML-KEM-1024.

I would also very much like X25519+ML-KEM-512 for use cases where message size 
matters. ML-KEM-512 public keys are smaller than ML-KEM-768 which means that 
you can fit X25519+ML-KEM-512 in a single packet without fragmentation. I have 
quite high trust in ML-KEM from a theoretical perspective. The margin to known 
attacks is large. I don’t have much trust in implementations. Early 
implementations might have both bugs and significant side-channel leakage. I 
think implementation aspects is the main reason to do hybrid.

Cheers,
John

From: Hubert Kario 
Date: Wednesday, 5 June 2024 at 13:20
To: Stephen Farrell 
Cc: John Mattsson , tls@ietf.org 
Subject: Re: [TLS] [EXTERNAL] Curve-popularity data?
On Wednesday, 5 June 2024 09:19:51 CEST, Stephen Farrell wrote:
>
> On 05/06/2024 06:56, John Mattsson wrote:
>> I think P-384 is the most required of the NIST P-curves.
>
> I've heard that some. Oddly, I use a test server that only supports
> p384 as a way to trigger HRR when testing ECH, which seems to work for
> most clients who test with my servers, so I wonder if, when using a
> hybrid KEM, we're heading to a world where one large set of clients
> emit x25519 and x25519+pq and another large set emit p256 and p384+pq?
>
> I guess if that meant there wasn't a real need for much use of p256+pq
> that might be a small saving and worth documenting somewhere even if
> we do define a codepoint for p256+pq.

1. P-256 with OpenSSL 3.1.1 on my machine is quite literally over 20
   times faster than P-384
2. While NIST FIPS 186-5 includes Ed25519 as an approved algorithm,
   it does not include X25519 as an approved algorithm.
3. we're likely years before we will get first FIPS certified ML-KEM
   implementation

so I expect that most regular servers will use x25519+ML-KEM, the ones
that have a requirement for FIPS compliance will have to use P-256+ML-KEM,
and the ones that have Common Critera requirements will have to use
P-384+ML-KEM.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: 
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb70f391217844d5e8cc308dc855179ec%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638531832177835328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=grHoVU8T5RN6n6a0GnVYun63svZhKjSqLu10AH%2BQc0E%3D=0<http://www.cz.redhat.com/>
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Re: Donald Trump, convicted felon

2024-06-05 Thread John Clark

On Tue, Jun 4, 2024 at 8:34 PM PGC  wrote:

*> John, the idea is not for Biden to "become Trump" by emulating his
> behavior, but rather to understand and leverage the appeal of outsider
> narratives, mavericks, [...] He could directly challenge whether Trump
> actually managed to "drain the swamp" as he promised and use specific
> examples where Trump failed to deliver on his promises, *
>

By now it should be clear to everybody that Convicted Felon Trump never
built a wall and never made Mexico pay for it, and he never wanted to drain
the swamp, he wanted to own the swamp. And about 1.1 million Americans died
during Trump's watch due to his INCREDIBLE bungling of Covid, a pandemic he
publicly belittled, claiming the Democrats were over blowing the crucial
importance of itjust to make him unpopular, while at the exact same time
privately expressing very deep concern about the epidemic. The convicted
felon also dispensed quack medical advice about how to deal with the
pandemic, advice that was LETHAL. Even Donald Trump's most avid followers
know all this but they just don't care, I don't pretend to have a theory to
explain this phenomenon, but the evidence is overwhelming that the
phenomenon exists.

 > *Biden should Town Hall as much as he can*

If you want to win a Town Hall debate logic will not help you very much,
you need to appeal to base emotions, perhaps that's why Biden is not very
good at them.

*>Emphasize America's role as a global leader and a beacon of hope and
> democracy. Contrast this with the isolationist and divisive rhetoric of
> Trump.*
>

There is one thing that Biden should've done on the first day of his
administration, something that would not only have helped him politically
it would also have been the right thing to do, and that is legalize
marijuana. And I say that despite the fact that I have never smoked even
one marijuana cigarette.

  John K ClarkSee what's on my new list at  Extropolis
<https://groups.google.com/g/extropolis>
mws

-- 
You received this message because you are subscribed to the Google Groups 
"Everything List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to everything-list+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/everything-list/CAJPayv3s5nFnTsvuk1njENG8bcQLRBtRyfFhfT5yHU2sDBAXhg%40mail.gmail.com.

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

It appears that Tobias Fiebig via mailop  said:
>Moin,
>> In this case, if DKIM validators correctly rejected the invalid
>> signatures, this mistake would have been caught and fixed more
>> quickly.
>So, back to the initial question: Would it make sense if i'd file a bug
>against rspamd?

Sure.  See Viktor's note about where MIME encoding is allowed.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

It appears that Tobias Fiebig via mailop  said:
>Well, that would then be rspamd and the python email parser; Question
>is whether that would qualify as a bug, i.e., 'should not validate'; My
>understanding would be more in a 'be liberal in what you accept and
>conservative and what you send'-sense, though; I.e., even though not
>technically allowed no harm in validating.

That's a common misunderstanding of the robustness principle. You
should be liberal in what you accept *when the spec is ambiguous.*
Other than that you should be prepared for people to send you any
arbitrary garbage so you can reject it.

In this case, if DKIM validators correctly rejected the invalid
signatures, this mistake would have been caught and fixed more
quickly.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com

It appears that Slavko via mailop  said:
>Do you want to tell, that if d= and/or s= tags contains 
>internationalized domain name/label, it must be in A-label (ASCII 
>encoded) form? Or how it is supposed to be handled please?

See RFC 8616.  That is precisely what it is about.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

2024-06-05 Thread John R Levine via mailop


On Wed, 5 Jun 2024, Tobias Fiebig wrote:

If you're not sending SMTPUTF8 mail, the DKIM signature headers
should be ASCII with no encoding needed. But if you are ending
SMTPUTF8 mail, you can put UTF-8 directly in the header and it
doesn't need any futher encoding either.


Yeah, even more odd, the actual data did not contain any UTF-8 anyway.
Meta now also fixed this.


Can you give an example of the signature headers that caused a
problem? They just sound wrong.


See attached. dkimpy/dkimverify failed on the original mail with:


I wouldn't verify that either.  It's just wrong.  You're not allowed to 
MIME encode strings in a DKIM-Signature header.*


Unfortunately there is a lot of badly written mail processing code that 
tries to be helpful by MIME encoding headers without checking whether the 
headers allow it.



My understanding, though, is that encoding _should_ be permissible
here, as it would be needed, e.g., when receiving a message from a
server with SMTPUTF8 which then must be forwarded via a server that
does not support it.


Nope.  You cannot downgrade a SMTUTF8 message to an ASCII message.  The 
experimental versions of EAI tried to do that and it never worked so they 
took it out of the standards track EAI RFCs.


You can wrap one as a message/global MIME part and send it as an 
attachment, but you can't "translate" the message..


R's,
John

* - I'm pretty sure that if you asked the author of RFC 8616, he'd say the 
same thing.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[Isbg] Maximizing Your Academic Potential with Expert Assignment Help

2024-06-05 Thread John Smith

Academic life can be challenging, with tight deadlines, complex subjects, and 
the constant pressure to perform well. At Assignment Guru, we specialize in 
providing personalized assistance in various subjects, including math, law, 
nursing, and CIPD. Our team of experts offers tailored support to help you 
understand difficult concepts, manage your time effectively, and ultimately 
improve your grades. Many UK students have successfully boosted their academic 
performance with our help. Join them and let’s work together to achieve your 
academic goals.

Explore more : https://www.assignmentguru.co.uk/
___
Isbg mailing list -- isbg@python.org
To unsubscribe send an email to isbg-le...@python.org
https://mail.python.org/mailman3/lists/isbg.python.org/
Member address: arch...@mail-archive.com

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

According to Tobias Fiebig via mailop :
>Moin,
>
>to share some closure on this with the rest of the list; What was
>ultimately the issue was an RFC8616 based DKIM-Signature header, i.e.,
>containing UTF-8 encoded fields (in this case, even though there were
>no non-ascii characters in them). ...

If you're not sending SMTPUTF8 mail, the DKIM signature headers should
be ASCII with no encoding needed.  But if you are ending SMTPUTF8 mail,
you can put UTF-8 directly in the header and it doesn't need any futher
encoding either.

Can you give an example of the signature headers that caused a problem?  They
just sound wrong.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to ensure ownership from a Microsoft email?

It appears that Cyril - ImprovMX via mailop  said:
>Now, I wonder. Can I trust Microsoft that if they send an email on behalf of 
>aotearoa.energy, they initially
>validated the ownership or is there a way to bypass that?


tl;dr It's self service with, as far as I can tell, no validation at all.

In my experience, mail from whatever.onmicrosoft.com is overwhelmingly phishes 
and spam.  Anyone with
a real business should be using their own domain to send mail from MS 365 
rather than an onmicrosoft one.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[Bug 2067897] Re: Ubuntu 24.04 does not install resolvconf uses systemd-resolved instead which is broken

2024-06-05 Thread John Orr

I'm still digging on this one - the error 
Activation via systemd failed for unit 'dbus-org.freedesktop.network1.service': 
Unit dbus-org.freedesktop.network1.service not found
seems to be related, for me, to the networkd service not starting properly - 
not sure why:

#: john@j4lt:/etc/strongswan.d ; sudo systemctl status systemd-networkd.service 
[sudo] password for john: 
○ systemd-networkd.service - Network Configuration
 Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; 
preset: enabled)
 Active: inactive (dead)
TriggeredBy: ○ systemd-networkd.socket
   Docs: man:systemd-networkd.service(8)
 man:org.freedesktop.network1(5)

But that can be resolved by 
sudo systemctl restart systemd-networkd.service

But then the error changes to 
[IKE] installing DNS server 172.18.1.3 via resolvconf
[IKE] resolvconf: Dropped protocol specifier '.ipsec' from 'lo.ipsec'. Using 
'lo' (ifindex=1).
[IKE] resolvconf: Failed to set DNS configuration: Link lo is loopback device.
[IKE] adding DNS server failed

which probably makes sense.  I might ask Tobias, the maintainer of
Strongswan, about this - and the fact Ubuntu seems to use lo as the
loopback interface, which conflicts, seemingly, with strongswan using
lo.ipsec, and dropping the .ipsec

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067897

Title:
  Ubuntu 24.04 does not install resolvconf uses systemd-resolved instead
  which is broken

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2067897/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

Andrei Popov wrote:
>CNSA requires P384, so we’ll also need a hybrid that includes this EC.
Yes, I am not sure about the statement that P-256 is required. The requirement 
for FIPS in the next few years should be one of the NIST P-curves. I think 
P-384 is the most required of the NIST P-curves.

Scott Fluhrer wrote:
>I believe that it is unreasonable to expect that a single combination would 
>satisfy everyone’s needs.

Yes, that is completely unreasonable. TLS is MUCH larger than the Web. There 
will clearly be registrations for combinations of most current curves 
(P-curves, X-curves, Brainpool, SM, GOST) with most PQC KEMs (ML-KEM, BIKE/HQC, 
Classic McEliece, FrodoKEM, future Isogeny? (Isogenies was the hottest topic at 
Eurocrypt this year) ). European countries say that hybrids will be a must for 
a long-time.

Cheers,
John

From: Andrei Popov 
Date: Wednesday, 5 June 2024 at 07:24
To: Eric Rescorla , Stephen Farrell 
Cc: tls@ietf.org 
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
CNSA<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF>
 requires P384, so we’ll also need a hybrid that includes this EC.

Cheers,

Andrei

From: Eric Rescorla 
Sent: Monday, June 3, 2024 12:53 PM
To: Stephen Farrell 
Cc: Loganaden Velvindron ; Andrei Popov 
; Salz, Rich ; tls@ietf.org
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>> wrote:

I'm afraid I have no measurements to offer, but...

On 03/06/2024 19:05, Eric Rescorla wrote:
> The question is rather what the minimum set of algorithms we need is. My
>   point is that that has to include P-256. It may well be the case that
> it needs to also include X25519.

Yep, the entirely obvious answer here is we'll end up defining at least
x25519+PQ and p256+PQ. Arguing for one but not the other (in the TLS
WG) seems pretty pointless to me. (That said, the measurements offered
are as always interesting, so the discussion is less pointless than
the argument:-)

Yes, this seems correct to me.

-Ekr

Cheers,
S.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[Bug 2067897] Re: Ubuntu 24.04 does not install resolvconf uses systemd-resolved instead which is broken

2024-06-05 Thread John Orr

@Marukus, it's just a file I created (in my home directory, but could be
anywhere you've got write permissions) to hold the info I wanted to push
into resolvconf.  I took the nameservers out of the output of swanctl -
and added some search paths as examples (so that I can type "ssh blah"
and have it find blah.servers.mydomain.com, for example).

Note that this workaround adds DNS servers to whichever interface you
assign them to - so when you log off your vpn, you may wish to disable
your networking, then re-enable it, so as to fix your DNS servers.

Alternatively, there may be a better way - stay tuned

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067897

Title:
  Ubuntu 24.04 does not install resolvconf uses systemd-resolved instead
  which is broken

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2067897/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: git: 871b33ad65ba - main - pci: Consistently use pci_vf_* for suballocated VF memory resources


On 6/4/24 8:00 PM, Jessica Clarke wrote:

On 5 Jun 2024, at 00:52, John Baldwin  wrote:


The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=871b33ad65baf07c92cce120a4fc1978c2ed7b3b

commit 871b33ad65baf07c92cce120a4fc1978c2ed7b3b
Author: John Baldwin 
AuthorDate: 2024-06-04 23:51:37 +
Commit: John Baldwin 
CommitDate: 2024-06-04 23:51:37 +

pci: Consistently use pci_vf_* for suballocated VF memory resources

Some of the bus resource methods were passing these up to the parent
which triggered rman mismatch assertions in INVARIANTS kernels.

Reported by:kp
Reviewed by:imp
Tested by:  kp (earlier version)
Differential Revision:  https://reviews.freebsd.org/D45406
---
sys/dev/pci/pci.c | 118 ++--
sys/dev/pci/pci_iov.c | 151 ++
sys/dev/pci/pci_private.h |  19 ++
3 files changed, 284 insertions(+), 4 deletions(-)

diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
index 2cb8b4ce9fcc..2093d6a8b5ef 100644
--- a/sys/dev/pci/pci.c
+++ b/sys/dev/pci/pci.c
@@ -164,10 +164,18 @@ static device_method_t pci_methods[] = {
DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
DEVMETHOD(bus_delete_resource, pci_delete_resource),
DEVMETHOD(bus_alloc_resource, pci_alloc_resource),
+#ifdef PCI_IOV
+ DEVMETHOD(bus_adjust_resource, pci_adjust_resource),
+#else
DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
+#endif
DEVMETHOD(bus_release_resource, pci_release_resource),
DEVMETHOD(bus_activate_resource, pci_activate_resource),
DEVMETHOD(bus_deactivate_resource, pci_deactivate_resource),
+#ifdef PCI_IOV
+ DEVMETHOD(bus_map_resource, pci_map_resource),
+ DEVMETHOD(bus_unmap_resource, pci_unmap_resource),
+#endif
DEVMETHOD(bus_child_deleted, pci_child_deleted),
DEVMETHOD(bus_child_detached, pci_child_detached),
DEVMETHOD(bus_child_pnpinfo, pci_child_pnpinfo_method),


Would it make sense to instead #ifdef parts of the body of
pci_adjust_resource rather than switching which function you’re using
in the first place? I feel that is generally easier to understand, as
there’s less conditionality, and it’s more easily extensible if any
other special cases come along.


Hmm, I could do that I guess.  These aren't hot paths so the
extra jump to a tail call in the #ifndef case isn't that bad, and it
probably is a bit more readable.

In related news, you should really land your patches to enable
NEW_PCIB and PCI_RES_BUS by default (and remove the !NEW_PCIB
code). :)

--
John Baldwin

Re: git: 871b33ad65ba - main - pci: Consistently use pci_vf_* for suballocated VF memory resources


On 6/4/24 8:00 PM, Jessica Clarke wrote:

On 5 Jun 2024, at 00:52, John Baldwin  wrote:


The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=871b33ad65baf07c92cce120a4fc1978c2ed7b3b

commit 871b33ad65baf07c92cce120a4fc1978c2ed7b3b
Author: John Baldwin 
AuthorDate: 2024-06-04 23:51:37 +
Commit: John Baldwin 
CommitDate: 2024-06-04 23:51:37 +

pci: Consistently use pci_vf_* for suballocated VF memory resources

Some of the bus resource methods were passing these up to the parent
which triggered rman mismatch assertions in INVARIANTS kernels.

Reported by:kp
Reviewed by:imp
Tested by:  kp (earlier version)
Differential Revision:  https://reviews.freebsd.org/D45406
---
sys/dev/pci/pci.c | 118 ++--
sys/dev/pci/pci_iov.c | 151 ++
sys/dev/pci/pci_private.h |  19 ++
3 files changed, 284 insertions(+), 4 deletions(-)

diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
index 2cb8b4ce9fcc..2093d6a8b5ef 100644
--- a/sys/dev/pci/pci.c
+++ b/sys/dev/pci/pci.c
@@ -164,10 +164,18 @@ static device_method_t pci_methods[] = {
DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
DEVMETHOD(bus_delete_resource, pci_delete_resource),
DEVMETHOD(bus_alloc_resource, pci_alloc_resource),
+#ifdef PCI_IOV
+ DEVMETHOD(bus_adjust_resource, pci_adjust_resource),
+#else
DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
+#endif
DEVMETHOD(bus_release_resource, pci_release_resource),
DEVMETHOD(bus_activate_resource, pci_activate_resource),
DEVMETHOD(bus_deactivate_resource, pci_deactivate_resource),
+#ifdef PCI_IOV
+ DEVMETHOD(bus_map_resource, pci_map_resource),
+ DEVMETHOD(bus_unmap_resource, pci_unmap_resource),
+#endif
DEVMETHOD(bus_child_deleted, pci_child_deleted),
DEVMETHOD(bus_child_detached, pci_child_detached),
DEVMETHOD(bus_child_pnpinfo, pci_child_pnpinfo_method),


Would it make sense to instead #ifdef parts of the body of
pci_adjust_resource rather than switching which function you’re using
in the first place? I feel that is generally easier to understand, as
there’s less conditionality, and it’s more easily extensible if any
other special cases come along.


Hmm, I could do that I guess.  These aren't hot paths so the
extra jump to a tail call in the #ifndef case isn't that bad, and it
probably is a bit more readable.

In related news, you should really land your patches to enable
NEW_PCIB and PCI_RES_BUS by default (and remove the !NEW_PCIB
code). :)

--
John Baldwin

git: 871b33ad65ba - main - pci: Consistently use pci_vf_* for suballocated VF memory resources

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=871b33ad65baf07c92cce120a4fc1978c2ed7b3b

commit 871b33ad65baf07c92cce120a4fc1978c2ed7b3b
Author: John Baldwin 
AuthorDate: 2024-06-04 23:51:37 +
Commit: John Baldwin 
CommitDate: 2024-06-04 23:51:37 +

pci: Consistently use pci_vf_* for suballocated VF memory resources

Some of the bus resource methods were passing these up to the parent
which triggered rman mismatch assertions in INVARIANTS kernels.

Reported by:kp
Reviewed by:imp
Tested by:  kp (earlier version)
Differential Revision:  https://reviews.freebsd.org/D45406
---
 sys/dev/pci/pci.c | 118 ++--
 sys/dev/pci/pci_iov.c | 151 ++
 sys/dev/pci/pci_private.h |  19 ++
 3 files changed, 284 insertions(+), 4 deletions(-)

diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
index 2cb8b4ce9fcc..2093d6a8b5ef 100644
--- a/sys/dev/pci/pci.c
+++ b/sys/dev/pci/pci.c
@@ -164,10 +164,18 @@ static device_method_t pci_methods[] = {
DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
DEVMETHOD(bus_delete_resource,  pci_delete_resource),
DEVMETHOD(bus_alloc_resource,   pci_alloc_resource),
+#ifdef PCI_IOV
+   DEVMETHOD(bus_adjust_resource,  pci_adjust_resource),
+#else
DEVMETHOD(bus_adjust_resource,  bus_generic_adjust_resource),
+#endif
DEVMETHOD(bus_release_resource, pci_release_resource),
DEVMETHOD(bus_activate_resource, pci_activate_resource),
DEVMETHOD(bus_deactivate_resource, pci_deactivate_resource),
+#ifdef PCI_IOV
+   DEVMETHOD(bus_map_resource, pci_map_resource),
+   DEVMETHOD(bus_unmap_resource,   pci_unmap_resource),
+#endif
DEVMETHOD(bus_child_deleted,pci_child_deleted),
DEVMETHOD(bus_child_detached,   pci_child_detached),
DEVMETHOD(bus_child_pnpinfo,pci_child_pnpinfo_method),
@@ -5687,14 +5695,30 @@ pci_activate_resource(device_t dev, device_t child, 
struct resource *r)
struct pci_devinfo *dinfo;
int error, rid, type;
 
-   error = bus_generic_activate_resource(dev, child, r);
+   dinfo = device_get_ivars(child);
+#ifdef PCI_IOV
+   if (dinfo->cfg.flags & PCICFG_VF) {
+   switch (rman_get_type(r)) {
+   /* VFs can't have I/O BARs. */
+   case SYS_RES_IOPORT:
+   error = EINVAL;
+   break;
+   case SYS_RES_MEMORY:
+   error = pci_vf_activate_mem_resource(dev, child, r);
+   break;
+   default:
+   error = bus_generic_activate_resource(dev, child, r);
+   break;
+   }
+   } else
+#endif
+   error = bus_generic_activate_resource(dev, child, r);
if (error)
return (error);
 
/* Enable decoding in the command register when activating BARs. */
if (device_get_parent(child) == dev) {
/* Device ROMs need their decoding explicitly enabled. */
-   dinfo = device_get_ivars(child);
rid = rman_get_rid(r);
type = rman_get_type(r);
if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
@@ -5716,13 +5740,29 @@ pci_deactivate_resource(device_t dev, device_t child, 
struct resource *r)
struct pci_devinfo *dinfo;
int error, rid, type;
 
-   error = bus_generic_deactivate_resource(dev, child, r);
+   dinfo = device_get_ivars(child);
+#ifdef PCI_IOV
+   if (dinfo->cfg.flags & PCICFG_VF) {
+   switch (rman_get_type(r)) {
+   /* VFs can't have I/O BARs. */
+   case SYS_RES_IOPORT:
+   error = EINVAL;
+   break;
+   case SYS_RES_MEMORY:
+   error = pci_vf_deactivate_mem_resource(dev, child, r);
+   break;
+   default:
+   error = bus_generic_deactivate_resource(dev, child, r);
+   break;
+   }
+   } else
+#endif
+   error = bus_generic_deactivate_resource(dev, child, r);
if (error)
return (error);
 
/* Disable decoding for device ROMs. */
if (device_get_parent(child) == dev) {
-   dinfo = device_get_ivars(child);
rid = rman_get_rid(r);
type = rman_get_type(r);
if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
@@ -5732,6 +5772,76 @@ pci_deactivate_resource(device_t dev, device_t child, 
struct resource *r)
return (0);
 }
 
+#ifdef PCI_IOV
+int
+pci_adjust_resource(device_t dev, device_t child, struct resource *r,
+rman_res_t start, rman_res_t end)
+{
+   struct pci_devinfo *dinfo;
+
+

git: 871b33ad65ba - main - pci: Consistently use pci_vf_* for suballocated VF memory resources

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=871b33ad65baf07c92cce120a4fc1978c2ed7b3b

commit 871b33ad65baf07c92cce120a4fc1978c2ed7b3b
Author: John Baldwin 
AuthorDate: 2024-06-04 23:51:37 +
Commit: John Baldwin 
CommitDate: 2024-06-04 23:51:37 +

pci: Consistently use pci_vf_* for suballocated VF memory resources

Some of the bus resource methods were passing these up to the parent
which triggered rman mismatch assertions in INVARIANTS kernels.

Reported by:kp
Reviewed by:imp
Tested by:  kp (earlier version)
Differential Revision:  https://reviews.freebsd.org/D45406
---
 sys/dev/pci/pci.c | 118 ++--
 sys/dev/pci/pci_iov.c | 151 ++
 sys/dev/pci/pci_private.h |  19 ++
 3 files changed, 284 insertions(+), 4 deletions(-)

diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
index 2cb8b4ce9fcc..2093d6a8b5ef 100644
--- a/sys/dev/pci/pci.c
+++ b/sys/dev/pci/pci.c
@@ -164,10 +164,18 @@ static device_method_t pci_methods[] = {
DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
DEVMETHOD(bus_delete_resource,  pci_delete_resource),
DEVMETHOD(bus_alloc_resource,   pci_alloc_resource),
+#ifdef PCI_IOV
+   DEVMETHOD(bus_adjust_resource,  pci_adjust_resource),
+#else
DEVMETHOD(bus_adjust_resource,  bus_generic_adjust_resource),
+#endif
DEVMETHOD(bus_release_resource, pci_release_resource),
DEVMETHOD(bus_activate_resource, pci_activate_resource),
DEVMETHOD(bus_deactivate_resource, pci_deactivate_resource),
+#ifdef PCI_IOV
+   DEVMETHOD(bus_map_resource, pci_map_resource),
+   DEVMETHOD(bus_unmap_resource,   pci_unmap_resource),
+#endif
DEVMETHOD(bus_child_deleted,pci_child_deleted),
DEVMETHOD(bus_child_detached,   pci_child_detached),
DEVMETHOD(bus_child_pnpinfo,pci_child_pnpinfo_method),
@@ -5687,14 +5695,30 @@ pci_activate_resource(device_t dev, device_t child, 
struct resource *r)
struct pci_devinfo *dinfo;
int error, rid, type;
 
-   error = bus_generic_activate_resource(dev, child, r);
+   dinfo = device_get_ivars(child);
+#ifdef PCI_IOV
+   if (dinfo->cfg.flags & PCICFG_VF) {
+   switch (rman_get_type(r)) {
+   /* VFs can't have I/O BARs. */
+   case SYS_RES_IOPORT:
+   error = EINVAL;
+   break;
+   case SYS_RES_MEMORY:
+   error = pci_vf_activate_mem_resource(dev, child, r);
+   break;
+   default:
+   error = bus_generic_activate_resource(dev, child, r);
+   break;
+   }
+   } else
+#endif
+   error = bus_generic_activate_resource(dev, child, r);
if (error)
return (error);
 
/* Enable decoding in the command register when activating BARs. */
if (device_get_parent(child) == dev) {
/* Device ROMs need their decoding explicitly enabled. */
-   dinfo = device_get_ivars(child);
rid = rman_get_rid(r);
type = rman_get_type(r);
if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
@@ -5716,13 +5740,29 @@ pci_deactivate_resource(device_t dev, device_t child, 
struct resource *r)
struct pci_devinfo *dinfo;
int error, rid, type;
 
-   error = bus_generic_deactivate_resource(dev, child, r);
+   dinfo = device_get_ivars(child);
+#ifdef PCI_IOV
+   if (dinfo->cfg.flags & PCICFG_VF) {
+   switch (rman_get_type(r)) {
+   /* VFs can't have I/O BARs. */
+   case SYS_RES_IOPORT:
+   error = EINVAL;
+   break;
+   case SYS_RES_MEMORY:
+   error = pci_vf_deactivate_mem_resource(dev, child, r);
+   break;
+   default:
+   error = bus_generic_deactivate_resource(dev, child, r);
+   break;
+   }
+   } else
+#endif
+   error = bus_generic_deactivate_resource(dev, child, r);
if (error)
return (error);
 
/* Disable decoding for device ROMs. */
if (device_get_parent(child) == dev) {
-   dinfo = device_get_ivars(child);
rid = rman_get_rid(r);
type = rman_get_type(r);
if (type == SYS_RES_MEMORY && PCIR_IS_BIOS(>cfg, rid))
@@ -5732,6 +5772,76 @@ pci_deactivate_resource(device_t dev, device_t child, 
struct resource *r)
return (0);
 }
 
+#ifdef PCI_IOV
+int
+pci_adjust_resource(device_t dev, device_t child, struct resource *r,
+rman_res_t start, rman_res_t end)
+{
+   struct pci_devinfo *dinfo;
+
+

git: 98056127ddfa - main - acpi/pci/vmd: Fix a nit with nested resource mapping requests

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=98056127ddfa36720bcf46edc09843c867784bcb

commit 98056127ddfa36720bcf46edc09843c867784bcb
Author: John Baldwin 
AuthorDate: 2024-06-04 23:50:56 +
Commit: John Baldwin 
CommitDate: 2024-06-04 23:51:14 +

acpi/pci/vmd: Fix a nit with nested resource mapping requests

Some bus drivers use rmans to suballocate resources to child devices.
When the driver for a child device requests a mapping for a
suballocated resource, the bus driver translates this into a mapping
request for a suitable subrange of the original resource the bus
driver allocated from its parent.  This nested mapping request should
look like any other resource mapping request being made by the bus
device (i.e. as if the bus device had called bus_map_resource() or
bus_alloc_resource() with RF_ACTIVE).

I had slightly flubbed this last bit though since the direct use of
bus_generic_map/unmap_resource passed up the original child device
(second argument to the underlying kobj interface).  While this is
currently harmless, it is not strictly correct as the resource being
mapped is owned by the bus device, not the child and can break for
other bus drivers in the future.

Instead, use bus_map/unmap_resource for the nested request where the
requesting device is now the bus device that owns the parent resource.

Reviewed by:imp
Fixes:  0e1246e33461 acpi: Cleanup handling of suballocated 
resources
Fixes:  b377ff8110e3 pcib: Refine handling of resources allocated 
from bridge windows
Fixes:  d79b6b8ec267 pci_host_generic: Don't rewrite resource start 
address for translation
Fixes:  d714e73f7895 vmd: Use bus_generic_rman_* for PCI bus and 
memory resources
Differential Revision:  https://reviews.freebsd.org/D45433
---
 sys/dev/acpica/acpi.c  | 17 ++---
 sys/dev/pci/pci_host_generic.c | 16 
 sys/dev/pci/pci_pci.c  | 16 +---
 sys/dev/vmd/vmd.c  |  9 +
 4 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index ad1af9373fb7..24d7027f165d 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -1651,19 +1651,22 @@ acpi_map_resource(device_t bus, device_t child, struct 
resource *r,
 
args.offset = start - rman_get_start(sysres);
args.length = length;
-   return (bus_generic_map_resource(bus, child, sysres, , map));
+   return (bus_map_resource(bus, sysres, , map));
 }
 
 static int
 acpi_unmap_resource(device_t bus, device_t child, struct resource *r,
 struct resource_map *map)
 {
-   if (acpi_is_resource_managed(bus, r)) {
-   r = acpi_managed_resource(bus, r);
-   if (r == NULL)
-   return (ENOENT);
-   }
-   return (bus_generic_unmap_resource(bus, child, r, map));
+   struct resource *sysres;
+
+   if (!acpi_is_resource_managed(bus, r))
+   return (bus_generic_unmap_resource(bus, child, r, map));
+
+   sysres = acpi_managed_resource(bus, r);
+   if (sysres == NULL)
+   return (ENOENT);
+   return (bus_unmap_resource(bus, sysres, map));
 }
 
 /* Allocate an IO port or memory resource, given its GAS. */
diff --git a/sys/dev/pci/pci_host_generic.c b/sys/dev/pci/pci_host_generic.c
index 82ed51460621..d97a7597df25 100644
--- a/sys/dev/pci/pci_host_generic.c
+++ b/sys/dev/pci/pci_host_generic.c
@@ -646,7 +646,7 @@ generic_pcie_map_resource(device_t dev, device_t child, 
struct resource *r,
 
args.offset = start - range->pci_base;
args.length = length;
-   return (bus_generic_map_resource(dev, child, range->res, , map));
+   return (bus_map_resource(dev, range->res, , map));
 }
 
 static int
@@ -664,16 +664,16 @@ generic_pcie_unmap_resource(device_t dev, device_t child, 
struct resource *r,
 #endif
case SYS_RES_IOPORT:
case SYS_RES_MEMORY:
-   range = generic_pcie_containing_range(dev, type,
-   rman_get_start(r), rman_get_end(r));
-   if (range == NULL || range->res == NULL)
-   return (ENOENT);
-   r = range->res;
break;
default:
-   break;
+   return (bus_generic_unmap_resource(dev, child, r, argsp, map));
}
-   return (bus_generic_unmap_resource(dev, child, r, map));
+
+   range = generic_pcie_containing_range(dev, type, rman_get_start(r),
+   rman_get_end(r));
+   if (range == NULL || range->res == NULL)
+   return (ENOENT);
+   return (bus_unmap_resource(dev, range->res, map));
 }
 
 static bus_dma_tag_t
diff --git a/sys/dev/pci/pci_pci.c b/sys/dev/pci/pci_pci.c
index 35062d67050e..40b22c9802c4 100644
--- a/sys/dev/pci/pc

git: 98056127ddfa - main - acpi/pci/vmd: Fix a nit with nested resource mapping requests

The branch main has been updated by jhb:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=98056127ddfa36720bcf46edc09843c867784bcb

commit 98056127ddfa36720bcf46edc09843c867784bcb
Author: John Baldwin 
AuthorDate: 2024-06-04 23:50:56 +
Commit: John Baldwin 
CommitDate: 2024-06-04 23:51:14 +

acpi/pci/vmd: Fix a nit with nested resource mapping requests

Some bus drivers use rmans to suballocate resources to child devices.
When the driver for a child device requests a mapping for a
suballocated resource, the bus driver translates this into a mapping
request for a suitable subrange of the original resource the bus
driver allocated from its parent.  This nested mapping request should
look like any other resource mapping request being made by the bus
device (i.e. as if the bus device had called bus_map_resource() or
bus_alloc_resource() with RF_ACTIVE).

I had slightly flubbed this last bit though since the direct use of
bus_generic_map/unmap_resource passed up the original child device
(second argument to the underlying kobj interface).  While this is
currently harmless, it is not strictly correct as the resource being
mapped is owned by the bus device, not the child and can break for
other bus drivers in the future.

Instead, use bus_map/unmap_resource for the nested request where the
requesting device is now the bus device that owns the parent resource.

Reviewed by:imp
Fixes:  0e1246e33461 acpi: Cleanup handling of suballocated 
resources
Fixes:  b377ff8110e3 pcib: Refine handling of resources allocated 
from bridge windows
Fixes:  d79b6b8ec267 pci_host_generic: Don't rewrite resource start 
address for translation
Fixes:  d714e73f7895 vmd: Use bus_generic_rman_* for PCI bus and 
memory resources
Differential Revision:  https://reviews.freebsd.org/D45433
---
 sys/dev/acpica/acpi.c  | 17 ++---
 sys/dev/pci/pci_host_generic.c | 16 
 sys/dev/pci/pci_pci.c  | 16 +---
 sys/dev/vmd/vmd.c  |  9 +
 4 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index ad1af9373fb7..24d7027f165d 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -1651,19 +1651,22 @@ acpi_map_resource(device_t bus, device_t child, struct 
resource *r,
 
args.offset = start - rman_get_start(sysres);
args.length = length;
-   return (bus_generic_map_resource(bus, child, sysres, , map));
+   return (bus_map_resource(bus, sysres, , map));
 }
 
 static int
 acpi_unmap_resource(device_t bus, device_t child, struct resource *r,
 struct resource_map *map)
 {
-   if (acpi_is_resource_managed(bus, r)) {
-   r = acpi_managed_resource(bus, r);
-   if (r == NULL)
-   return (ENOENT);
-   }
-   return (bus_generic_unmap_resource(bus, child, r, map));
+   struct resource *sysres;
+
+   if (!acpi_is_resource_managed(bus, r))
+   return (bus_generic_unmap_resource(bus, child, r, map));
+
+   sysres = acpi_managed_resource(bus, r);
+   if (sysres == NULL)
+   return (ENOENT);
+   return (bus_unmap_resource(bus, sysres, map));
 }
 
 /* Allocate an IO port or memory resource, given its GAS. */
diff --git a/sys/dev/pci/pci_host_generic.c b/sys/dev/pci/pci_host_generic.c
index 82ed51460621..d97a7597df25 100644
--- a/sys/dev/pci/pci_host_generic.c
+++ b/sys/dev/pci/pci_host_generic.c
@@ -646,7 +646,7 @@ generic_pcie_map_resource(device_t dev, device_t child, 
struct resource *r,
 
args.offset = start - range->pci_base;
args.length = length;
-   return (bus_generic_map_resource(dev, child, range->res, , map));
+   return (bus_map_resource(dev, range->res, , map));
 }
 
 static int
@@ -664,16 +664,16 @@ generic_pcie_unmap_resource(device_t dev, device_t child, 
struct resource *r,
 #endif
case SYS_RES_IOPORT:
case SYS_RES_MEMORY:
-   range = generic_pcie_containing_range(dev, type,
-   rman_get_start(r), rman_get_end(r));
-   if (range == NULL || range->res == NULL)
-   return (ENOENT);
-   r = range->res;
break;
default:
-   break;
+   return (bus_generic_unmap_resource(dev, child, r, argsp, map));
}
-   return (bus_generic_unmap_resource(dev, child, r, map));
+
+   range = generic_pcie_containing_range(dev, type, rman_get_start(r),
+   rman_get_end(r));
+   if (range == NULL || range->res == NULL)
+   return (ENOENT);
+   return (bus_unmap_resource(dev, range->res, map));
 }
 
 static bus_dma_tag_t
diff --git a/sys/dev/pci/pci_pci.c b/sys/dev/pci/pci_pci.c
index 35062d67050e..40b22c9802c4 100644
--- a/sys/dev/pci/pc

Re: git: dcb65c5a94d4 - main - csh: Remove hardlink /.cshrc


On 5/29/24 3:57 AM, Emmanuel Vadot wrote:

The branch main has been updated by manu:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=dcb65c5a94d4c622b1d486847dc20488f59974e7

commit dcb65c5a94d4c622b1d486847dc20488f59974e7
Author: Emmanuel Vadot 
AuthorDate: 2024-05-27 13:12:18 +
Commit: Emmanuel Vadot 
CommitDate: 2024-05-29 07:56:58 +

 csh: Remove hardlink /.cshrc
 
 Remove this historical artifact.

 csh will try to use /.csrch if the user has no home directory defined which
 is rather unlikely (To be exact if the concatenation of $HOME and "/.cshrc"
 fail which is the same thing).
 
 Also, with this change pkg will happily handle 3way merge for /root/.cshrc
 
 Differential Revision:  https://reviews.freebsd.org/D45382

 Reviewed by:emaste, imp
 Sponsored by:   Beckhoff Automation GmbH & Co. KG


FWIW, this happens anytime you use /bin/csh as root's shell and boot into
single user mode.  Similar to /.profile being used for single user mode if
root's shell is /bin/sh.  Given we've changed the default shell for root,
then it's fine to do this change, but that probably should have been noted
in the commit log (in part to serve as a reminder so we don't remove the
links for sh).

--
John Baldwin

Re: git: dcb65c5a94d4 - main - csh: Remove hardlink /.cshrc


On 5/29/24 3:57 AM, Emmanuel Vadot wrote:

The branch main has been updated by manu:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=dcb65c5a94d4c622b1d486847dc20488f59974e7

commit dcb65c5a94d4c622b1d486847dc20488f59974e7
Author: Emmanuel Vadot 
AuthorDate: 2024-05-27 13:12:18 +
Commit: Emmanuel Vadot 
CommitDate: 2024-05-29 07:56:58 +

 csh: Remove hardlink /.cshrc
 
 Remove this historical artifact.

 csh will try to use /.csrch if the user has no home directory defined which
 is rather unlikely (To be exact if the concatenation of $HOME and "/.cshrc"
 fail which is the same thing).
 
 Also, with this change pkg will happily handle 3way merge for /root/.cshrc
 
 Differential Revision:  https://reviews.freebsd.org/D45382

 Reviewed by:emaste, imp
 Sponsored by:   Beckhoff Automation GmbH & Co. KG


FWIW, this happens anytime you use /bin/csh as root's shell and boot into
single user mode.  Similar to /.profile being used for single user mode if
root's shell is /bin/sh.  Given we've changed the default shell for root,
then it's fine to do this change, but that probably should have been noted
in the commit log (in part to serve as a reminder so we don't remove the
links for sh).

--
John Baldwin

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

2024-06-04 Thread John Hixson

> 
> Thank you for the message. I'm glad someone has the courage to take the
> plunge. Smbfs is still very important to me. In a heterogeneous environment
> it is still the most common way to share data between systems.
> Are you planning the final version as a kernel module, or will the final
> version be via FUSE? I have had bad experiences with FUSE in the past with
> stability and performance.

The final version will be a kernel module. It  will also be BSD
licensed. I am not an expert at the VFS layer so I want to get the stack
ironed out in FUSE before moving it into kernel space.

- John


signature.asc
Description: PGP signature

Re: git: 1c45a62a2f66 - main - qlnxe: Fix multiple locking issues


On 5/28/24 2:43 AM, Kevin Bowling wrote:

The branch main has been updated by kbowling:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=1c45a62a2f667b45ec10a92ad58ff5a34e68b569

commit 1c45a62a2f667b45ec10a92ad58ff5a34e68b569
Author: Keith Reynolds 
AuthorDate: 2024-05-28 06:41:05 +
Commit: Kevin Bowling 
CommitDate: 2024-05-28 06:41:05 +

 qlnxe: Fix multiple locking issues
 
 Multiple issues are reported with WITNESS and code inspection of the

 locking and lock initialization.
 
 PR: 278084

 MFC after:  1 week
---
  sys/dev/qlnx/qlnxe/bcm_osal.h  |  8 +++
  sys/dev/qlnx/qlnxe/ecore.h |  1 +
  sys/dev/qlnx/qlnxe/ecore_mcp.c | 48 +-
  sys/dev/qlnx/qlnxe/ecore_mcp.h |  6 +++---
  sys/dev/qlnx/qlnxe/qlnx_def.h  |  2 +-
  sys/dev/qlnx/qlnxe/qlnx_os.c   |  9 
  sys/dev/qlnx/qlnxe/qlnx_os.h   |  4 ++--
  7 files changed, 40 insertions(+), 38 deletions(-)

diff --git a/sys/dev/qlnx/qlnxe/bcm_osal.h b/sys/dev/qlnx/qlnxe/bcm_osal.h
index 5d940d3272d6..c820532c9e0a 100644
--- a/sys/dev/qlnx/qlnxe/bcm_osal.h
+++ b/sys/dev/qlnx/qlnxe/bcm_osal.h
@@ -72,7 +72,7 @@ extern void qlnx_dma_free_coherent(void *ecore_dev, void 
*v_addr,
  bus_addr_t phys, uint32_t size);
  
  extern void qlnx_link_update(void *p_hwfn);

-extern void qlnx_barrier(void *p_hwfn);
+extern void qlnx_barrier(void *p_dev);
  
  extern void *qlnx_zalloc(uint32_t size);
  
@@ -213,14 +213,14 @@ typedef struct osal_list_t

  #define OSAL_SPIN_LOCK_ALLOC(p_hwfn, mutex)
  #define OSAL_SPIN_LOCK_DEALLOC(mutex) mtx_destroy(mutex)
  #define OSAL_SPIN_LOCK_INIT(lock) {\
-   mtx_init(lock, __func__, MTX_NETWORK_LOCK, MTX_SPIN); \
+   mtx_init(lock, __func__, "OSAL spin lock", MTX_SPIN); \
}
  


Do you really need MTX_SPIN here?  Device drivers rarely need spin locks.
The equivalent to a Linux spin lock in drivers is generally a MTX_DEF
mutex.

--
John Baldwin

Re: git: 1c45a62a2f66 - main - qlnxe: Fix multiple locking issues


On 5/28/24 2:43 AM, Kevin Bowling wrote:

The branch main has been updated by kbowling:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=1c45a62a2f667b45ec10a92ad58ff5a34e68b569

commit 1c45a62a2f667b45ec10a92ad58ff5a34e68b569
Author: Keith Reynolds 
AuthorDate: 2024-05-28 06:41:05 +
Commit: Kevin Bowling 
CommitDate: 2024-05-28 06:41:05 +

 qlnxe: Fix multiple locking issues
 
 Multiple issues are reported with WITNESS and code inspection of the

 locking and lock initialization.
 
 PR: 278084

 MFC after:  1 week
---
  sys/dev/qlnx/qlnxe/bcm_osal.h  |  8 +++
  sys/dev/qlnx/qlnxe/ecore.h |  1 +
  sys/dev/qlnx/qlnxe/ecore_mcp.c | 48 +-
  sys/dev/qlnx/qlnxe/ecore_mcp.h |  6 +++---
  sys/dev/qlnx/qlnxe/qlnx_def.h  |  2 +-
  sys/dev/qlnx/qlnxe/qlnx_os.c   |  9 
  sys/dev/qlnx/qlnxe/qlnx_os.h   |  4 ++--
  7 files changed, 40 insertions(+), 38 deletions(-)

diff --git a/sys/dev/qlnx/qlnxe/bcm_osal.h b/sys/dev/qlnx/qlnxe/bcm_osal.h
index 5d940d3272d6..c820532c9e0a 100644
--- a/sys/dev/qlnx/qlnxe/bcm_osal.h
+++ b/sys/dev/qlnx/qlnxe/bcm_osal.h
@@ -72,7 +72,7 @@ extern void qlnx_dma_free_coherent(void *ecore_dev, void 
*v_addr,
  bus_addr_t phys, uint32_t size);
  
  extern void qlnx_link_update(void *p_hwfn);

-extern void qlnx_barrier(void *p_hwfn);
+extern void qlnx_barrier(void *p_dev);
  
  extern void *qlnx_zalloc(uint32_t size);
  
@@ -213,14 +213,14 @@ typedef struct osal_list_t

  #define OSAL_SPIN_LOCK_ALLOC(p_hwfn, mutex)
  #define OSAL_SPIN_LOCK_DEALLOC(mutex) mtx_destroy(mutex)
  #define OSAL_SPIN_LOCK_INIT(lock) {\
-   mtx_init(lock, __func__, MTX_NETWORK_LOCK, MTX_SPIN); \
+   mtx_init(lock, __func__, "OSAL spin lock", MTX_SPIN); \
}
  


Do you really need MTX_SPIN here?  Device drivers rarely need spin locks.
The equivalent to a Linux spin lock in drivers is generally a MTX_DEF
mutex.

--
John Baldwin

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

2024-06-04 Thread John Hixson

On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote:
> On 16/06/2022 15:56, Rick Macklem wrote:
> > Miroslav Lachman <000.f...@quip.cz> wrote:
> > > On 24/01/2022 16:13, Rick Macklem wrote:
> > > 
> > [...]
> > > 
> > > > So, I think Mark and Yuri are correct and looking at up to date
> > > > Illumos sources is the next step.
> > > > (As I mentioned, porting the Apple sources is beyond what I am
> > > >willing to attempt.)
> > > > 
> > > > rick
> > > 
> > > Hello Rick,
> > > I would like to ask you I there is some progress with porting newer
> > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
> > > possibility where to start porting?
> > Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date
> > and I agree that it should be easier than the Apple stuff to port into
> > FreeBSD.  I don't think it is "straightforward" as someone involved
> > with Illumos said, due to the big differences in VFS/locking, but...
> > 
> > Having said the above, I have not done much yet. I've been cleaning up
> > NFS stuff, although I am nearly done with that now.
> > I do plan on starting to work on it soon, but have no idea if/when I
> > will have something that might be useful for others.
> 
> I'm glad to hear that.
> 
> > > We have more and more problems with current state of mount_smbfs. I
> > > would be really glad if "somebody" can do the heroic work of
> > > implementing SMBv2 in FreeBSD.
> > > Maybe it's time to start some fundraising for sponsoring this work?
> > Well, funding isn't an issue for me (I'm just a retired guy who does this
> > stuff as a hobby). However, if there is someone else who is capable of
> > doing it if they are funded, I have no problem with that.
> > I could either help them, or simply stick with working on NFS and leave
> > SMBv23 to them.
> > 
> > Sorry, but I cannot report real progress on this as yet, rick
> 
> No need to sorry. I really appreciate your endless work on NFS and that you
> still have kind of interest to try porting SMBv2/3.
> Unfortunately I don't know anybody else trying to do this tremendous work.
> 

I am working on a from scratch implementation of smbfs. I do not have
any kind of time estimate since it is in my spare time. I chose this
route after spending considerable time looking at Apple and Solaris
implementations and wanting something without all of the legacy 1.0
crap. I do have a very minimal working FUSE version at this point, but
there is much to do, and even more to abide by the various
specifications.

I just thought I'd share in case anyone is interested.

- John


signature.asc
Description: PGP signature

Re: [PATCH v3] ima: Avoid blocking in RCU read-side critical section

2024-06-04 Thread John Johansen


On 5/6/24 18:25, GUO Zihua wrote:

A panic happens in ima_match_policy:

BUG: unable to handle kernel NULL pointer dereference at 0010
PGD 42f873067 P4D 0
Oops:  [#1] SMP NOPTI
CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
RIP: 0010:ima_match_policy+0x84/0x450
Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 
48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 
41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
RAX:  RBX:  RCX: 0200
RDX: ad8dc7c0 RSI: 24924925 RDI: ff3e27850dea2000
RBP:  R08:  R09: abfce739
R10: ff3e27810cc42400 R11:  R12: ff3e2781825ef970
R13: ff3e2785 R14: 000c R15: 0001
FS:  7f5195b51740() GS:ff3e278b12d4() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0010 CR3: 000626d24002 CR4: 00361ee0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  ima_get_action+0x22/0x30
  process_measurement+0xb0/0x830
  ? page_add_file_rmap+0x15/0x170
  ? alloc_set_pte+0x269/0x4c0
  ? prep_new_page+0x81/0x140
  ? simple_xattr_get+0x75/0xa0
  ? selinux_file_open+0x9d/0xf0
  ima_file_check+0x64/0x90
  path_openat+0x571/0x1720
  do_filp_open+0x9b/0x110
  ? page_counter_try_charge+0x57/0xc0
  ? files_cgroup_alloc_fd+0x38/0x60
  ? __alloc_fd+0xd4/0x250
  ? do_sys_open+0x1bd/0x250
  do_sys_open+0x1bd/0x250
  do_syscall_64+0x5d/0x1d0
  entry_SYSCALL_64_after_hwframe+0x65/0xca

Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by
ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a
RCU read-side critical section which contains kmalloc with GFP_KERNEL.
This implies a possible sleep and violates limitations of RCU read-side
critical sections on non-PREEMPT systems.

Sleeping within RCU read-side critical section might cause
synchronize_rcu() returning early and break RCU protection, allowing a
UAF to happen.

The root cause of this issue could be described as follows:
|   Thread A|   Thread B|
|   |ima_match_policy   |
|   |  rcu_read_lock|
|ima_lsm_update_rule|   |
|  synchronize_rcu  |   |
|   |kmalloc(GFP_KERNEL)|
|   |  sleep|
==> synchronize_rcu returns early
|  kfree(entry) |   |
|   |entry = entry->next|
==> UAF happens and entry now becomes NULL (or could be anything).
|   |entry->action   |
==> Accessing entry might cause panic.

To fix this issue, we are converting all kmalloc that is called within
RCU read-side critical section to use GFP_ATOMIC.

Fixes: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()")
Cc: sta...@vger.kernel.org
Signed-off-by: GUO Zihua 


this looks fine
Acked-by: John Johansen 


---

v3:
   ima_lsm_copy_rule takes a GFP flag as input as well.
v2:
   Changed the audit_rule_init security hook to accept a new GFP flag, as
per Stephen's suggestion.

---
  include/linux/lsm_hook_defs.h   |  2 +-
  include/linux/security.h|  5 +++--
  kernel/auditfilter.c|  5 +++--
  security/apparmor/audit.c   |  6 +++---
  security/apparmor/include/audit.h   |  2 +-
  security/integrity/ima/ima_policy.c | 15 +--
  security/security.c |  6 --
  security/selinux/include/audit.h|  4 +++-
  security/selinux/ss/services.c  |  5 +++--
  security/smack/smack_lsm.c  |  3 ++-
  10 files changed, 32 insertions(+), 21 deletions(-)

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 334e00efbde4..7e539f6f8c67 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -412,7 +412,7 @@ LSM_HOOK(void, LSM_RET_VOID, key_post_create_or_update, 
struct key *keyring,
  
  #ifdef CONFIG_AUDIT

  LSM_HOOK(int, 0, audit_rule_init, u32 field, u32 op, char *rulestr,
-void **lsmrule)
+void **lsmrule, gfp_t gfp)
  LSM_HOOK(int, 0, audit_rule_known, struct audit_krule *krule)
  LSM_HOOK(int, 0, audit_rule_match, u32 secid, u32 field, u32 op, void 
*lsmrule)
  LSM_HOOK(void, LSM_RET_VOID, audit_rule_free, void *lsmrule)
diff --git a/include/linux/security.h b/include/linux/security.h
index 41a8f667bdfa..5122e3ad83b1 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -2048,7 +2048,8 @@ static inline void 
security_key_post_create_or_update(struct key *keyring,
  
  #ifdef CONFIG_AUDIT

  #ifdef CONFIG_SECURIT

Re: [PATCH 50/52] pa: New hook implementation pa_c_mode_for_floating_type

2024-06-04 Thread John David Anglin

1306,3 +1306,9 @@ do {  
 \
  /* An integer expression for the size in bits of the largest integer machine
 mode that should actually be used.  We allow pairs of registers.  */
  #define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
+
+/* Define these macros as default for all subtargets, add PA_ prefix
+   as {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE get poisoned.  */
+#define PA_FLOAT_TYPE_SIZE BITS_PER_WORD
+#define PA_DOUBLE_TYPE_SIZE (BITS_PER_WORD * 2)
+#define PA_LONG_DOUBLE_TYPE_SIZE (BITS_PER_WORD * 2)



--
John David Anglin  dave.ang...@bell.net

Re: gcc behavior of init priority of .ctors and .dtors section